Элемент IE contentEditable силы для создания разрывов строки на клавише Enter, не повреждая Отмену
Ваша проблема здесь:
result := int64((now-1)/blockInterval) * blockInterval
time.Now().Unix() возвращает текущее время Unix в секундах . Таким образом, для последовательных итераций time.Now().Unix() будет:
1257894001
1257894002
1257894003
Но в вашей функции вы вычитаете 1, а затем делите на десять, поэтому каждое из вышеперечисленных становится следующим, поскольку дробная часть отбрасывается .
125789400
125789400
125789400
Затем, когда вы умножаете на blockInterval (10), все они становятся:
1257894000
1257894000
1257894000
Таким образом, result заканчивается тем же. Если вы позволите ему работать дольше десяти секунд, вы увидите, что result изменится через 10 секунд:
4 ответа
Не точное решение, а другой обходной путь. Если вы используете разметку:
<div contenteditable="true">
<div>
content
</div>
<div>
Затем нажатие , введите создаст новые теги div вместо тегов p .
Удерживайте нажатой клавишу shift, когда нажимаете ввод для разрывов, не удерживайте ее для полных абзацев. Это поведение по умолчанию такое же в Firefox, учитывая спорную область, содержащую абзац: т.е.
<div contenteditable="true">
<p>If you are typing here</p>
<div>
Это может невозможно понять это правильно. Однако можно сделать так, чтобы теги выглядели как одинарные разрывы строк, удалив встроенные поля вокруг тегов абзацев с помощью CSS:
p { margin: 0; }
Недостаток этого подхода: если пользователю необходимо скопировать / вставить текст в элемент contentEditable, текст может выглядеть как одинарный внутри элемента, но через два интервала вне элемента.
Хуже того, по крайней мере в некоторых случаях IE автоматически обнаруживает двойные разрывы строк во время вставки, заменяя их тегами ; это испортит форматирование вставленного текста.
Предположительно вы собираетесь отправить редактируемый контент обратно на сервер. Следовательно, вам не должно быть никакого дела до того, есть ли у вас теги абзацев или разрывов, пока пользователь редактирует, потому что вы можете анализировать HTML перед отправкой (или на сервере, если хотите) и заменять экземпляры абзацев разрывами. Это сохраняет очередь UNDO в рабочем состоянии для пользователя, но позволяет сделать ваш HTML настолько чистым, насколько вы этого хотите.
Далее я предполагаю, что вы точно знаете, какие элементы DIV будут доступны для редактирования. Перед отправкой формы вы можете запустить каждый div contentEditable с помощью такой функции:
function cleanContentEditableDiv(div) {
var htmlString = div.innerHTML;
htmlString = htmlString.replace(/<\/p>/gim,"<br/>");
htmlString = htmlString.replace(/<p>/gim,"");
return htmlString;
}
И вы вызываете это в цикле (который перебирает все contentEditable DIV, используя массив, который я назову ceDivs), например:
ceDivs[i].contentEditable = false; // to make sure IE doesn't try to coerce the contents again
, а затем:
ceDivs[i].innerHTML = cleanContentEditableDiv(ceDivs[i]);
Улучшение этого (особенно, если вы не хотите делать это прямо во время отправки), может заключаться в очистке содержимого каждого такого div в любое другое время, когда вам нравится (onblur, что угодно) и назначении содержимое каждого ceDiv в свой собственный невидимый элемент формы для последующей отправки. При использовании в сочетании с вашим собственным предложением CSS, приведенным выше, это может сработать для вас. Он не сохраняет ваши буквальные требования к букве (т.е., он не заставляет Javascript заставить IE вести себя иначе, чем он был закодирован под крышкой, чтобы вести себя), но для всех практических целей эффект тот же. Пользователи получают то, что хотят, а вы - то, что хотите.
Пока вы занимаетесь этим, вы также можете очистить строки пробелов в IE. Если пользователь вводит несколько пробелов (как некоторые все еще делают после точек), IE вставляет не [пробел] [пробел], а [пробел], начальный символ пробела (String.fromCharCode (32)) плюс столько сущностей, сколько остались в космосе.