Comments 19
Что-то ваш скрипт в Хроме не работает.
Ubuntu 12.04, Chrome 24.0.1312.52
Ubuntu 12.04, Chrome 24.0.1312.52
Ответ был приведён в подразделе «Вопросы и ответы» в первом же вопросе.
Когда ж я уже научусь сначала читать…
Дабы окончательно искупить свою невнимательность, вот вам совет как заставить скрипт работать в хроме.
Уберите дефолтное значение аргумента в первой строке. В JS они не предусмотрены.
Было:
Стало:
Уберите дефолтное значение аргумента в первой строке. В JS они не предусмотрены.
Было:
jsiedit_fn_sample_habr_parse = function(elem, keep_format = false)
Стало:
jsiedit_fn_sample_habr_parse = function(elem, keep_format)
Я добавлю, чтобы в js присваивать какие-то значения по-умолчанию для функций, достачтоно написать:
первыми строчками в функции. Не бойтесь, JS не будет ругаться, если передается недостаточно параметров. ваш код превратиться в такой:
paramN = paramN || "default value";
первыми строчками в функции. Не бойтесь, JS не будет ругаться, если передается недостаточно параметров. ваш код превратиться в такой:
jsiedit_fn_sample_habr_parse = function(elem, keep_format)
{
keep_format = keep_format || false;
…
}
> Ситуацию усугублял ещё запрет на изменение размеров формы ввода.
Это — потому что в коде сайта в all.css, строка 62, стоит:
Такое давно работает, например, в ZenComment, потому что неудобства ощущались всегда и давно, а на сайте не спешат исправлять. В результате, с юзерстилем любые поля ввода могут растягиваться по вертикали.
А в скрипте HabrAjax в июле 2012 немного похимичено, и добавлен авторост полей ввода (статья на Хабре), после чего забыта даже необходимость растягивания любого из полей ввода на Хабре.
А по теме, получившийся редактор нельзя называть WYSIWYM — это просто редактор фрагментов с предпросмотром. Что, конечно, не умаляет его достижения. Как и редактор Хабра с предпросмотром — не WYSIWYG, хотя предпросмотр — в HTML. Смотрим определение — ru.wikipedia.org/wiki/WYSIWYM «WYSIWYM — сокращение от англоязычного What You See Is What You Mean (То, что ты видишь, есть то, что ты имеешь в виду)». От WYSIWYG отличается тем, что «G» ориентирован на одно представление текста, конкретную ширину, шрифт, а «M» кодируется более абстрактно, через теги. Но просмотр может вполне быть и в формате WYSIWYG, как это видно на демо одного распространённого редактора.
Почему-то ещё был упомянут Markdown, но не реализован. Идея ввода текстов на Хабр через вики-разметку высказывалась в статье о последнем обновлении Хабра. Ей дали 9 плюсов — habrahabr.ru/company/tm/blog/116840/#comment_5641111 (а латексу — 13). Поэтому, поддержка найдётся. Другое дело, что она может оказаться пассивной. Вот, для себя не вижу необходимости в разметке, мне полностью хватает кнопок над полем ввода, которые модифицируются скриптом HabrAjax (есть спойлер, Font, иной ввод Script и т.д.). И всё, для Хабра это покрывает 100% потребностей. Для других мест — скорее, может пригодиться; говорят, что на Западе Markdown более распространён.
Далее, что сказать по реализации? Мы получили редактор фрагментов, в котором приходится вручную вводить теги.
*) было бы гораздо удобнее увидеть над полем ввода те же самые кнопочки, к которым привыкли в полях ввода комментариев или статей;
*) потом создаётся запрос на обновление, всё передёргивается, прокручивается наверх — часть удобств теряется, к которым стремились. Хорошо бы отключить встроенную на сайте прокрутку;
*) даже без прокрутки получили сильно завязанный на коды сайта редактор. Без этого никуда, но для поддержки скрипта это тоже неудобство;
*) использование собственного предпросмотра — выдаёт не совсем аутентичный вид фрагмента, потому что не пропускается через сервер. Альтернатива — только задействовать предпросмотр сайта, потом поймать коллбек этого предпросмотра — ещё большее залезание в код. Тогда без проблем увидим не только фичи, но и баги генератора страниц (например, <img src="..." align="center/>).
Всё это, конечно, неизбежно — или залезать в код сайта, или пользоваться чем-то попроще. Например, при правке статей я приспособился использовать Ctrl-C — Ctrl-F — Ctrl-V — Enter — Enter, чтобы попасть на участок поля ввода с тем же фрагментом. Если учесть что скриптом поле ввода у меня разворачивается на 80% высоты окна, оказывается достаточно удобно и без головной боли поддержки и правки чужого кода.
Однако, в HabrAjax есть многое для того, чтобы собрать редактор фрагментов с кнопками, с контекстной кнопкой по выделению, которая там уже есть и заготовлена для отметки ошибок, и выполняет ещё несколько ролей. Более того, там даже поле ввода для редактирования выделенного фрагмента уже есть (см. эту страницу, там иллюстрации: spmbt.kodingen.com/habrahabr/habrAjax/habraQuotes-support.htm ). Если бы я делал его, то на основе HabrAjax. Если будет нужно, могу помочь прикрутить его в виде плагина, который вызывается контекстной кнопкой из установленного HabrAjax.
Это — потому что в коде сайта в all.css, строка 62, стоит:
textarea {
resize: none;
}textarea {
resize: vertical !important;
}Такое давно работает, например, в ZenComment, потому что неудобства ощущались всегда и давно, а на сайте не спешат исправлять. В результате, с юзерстилем любые поля ввода могут растягиваться по вертикали.
А в скрипте HabrAjax в июле 2012 немного похимичено, и добавлен авторост полей ввода (статья на Хабре), после чего забыта даже необходимость растягивания любого из полей ввода на Хабре.
А по теме, получившийся редактор нельзя называть WYSIWYM — это просто редактор фрагментов с предпросмотром. Что, конечно, не умаляет его достижения. Как и редактор Хабра с предпросмотром — не WYSIWYG, хотя предпросмотр — в HTML. Смотрим определение — ru.wikipedia.org/wiki/WYSIWYM «WYSIWYM — сокращение от англоязычного What You See Is What You Mean (То, что ты видишь, есть то, что ты имеешь в виду)». От WYSIWYG отличается тем, что «G» ориентирован на одно представление текста, конкретную ширину, шрифт, а «M» кодируется более абстрактно, через теги. Но просмотр может вполне быть и в формате WYSIWYG, как это видно на демо одного распространённого редактора.
Почему-то ещё был упомянут Markdown, но не реализован. Идея ввода текстов на Хабр через вики-разметку высказывалась в статье о последнем обновлении Хабра. Ей дали 9 плюсов — habrahabr.ru/company/tm/blog/116840/#comment_5641111 (а латексу — 13). Поэтому, поддержка найдётся. Другое дело, что она может оказаться пассивной. Вот, для себя не вижу необходимости в разметке, мне полностью хватает кнопок над полем ввода, которые модифицируются скриптом HabrAjax (есть спойлер, Font, иной ввод Script и т.д.). И всё, для Хабра это покрывает 100% потребностей. Для других мест — скорее, может пригодиться; говорят, что на Западе Markdown более распространён.
Далее, что сказать по реализации? Мы получили редактор фрагментов, в котором приходится вручную вводить теги.
*) было бы гораздо удобнее увидеть над полем ввода те же самые кнопочки, к которым привыкли в полях ввода комментариев или статей;
*) потом создаётся запрос на обновление, всё передёргивается, прокручивается наверх — часть удобств теряется, к которым стремились. Хорошо бы отключить встроенную на сайте прокрутку;
*) даже без прокрутки получили сильно завязанный на коды сайта редактор. Без этого никуда, но для поддержки скрипта это тоже неудобство;
*) использование собственного предпросмотра — выдаёт не совсем аутентичный вид фрагмента, потому что не пропускается через сервер. Альтернатива — только задействовать предпросмотр сайта, потом поймать коллбек этого предпросмотра — ещё большее залезание в код. Тогда без проблем увидим не только фичи, но и баги генератора страниц (например, <img src="..." align="center/>).
Всё это, конечно, неизбежно — или залезать в код сайта, или пользоваться чем-то попроще. Например, при правке статей я приспособился использовать Ctrl-C — Ctrl-F — Ctrl-V — Enter — Enter, чтобы попасть на участок поля ввода с тем же фрагментом. Если учесть что скриптом поле ввода у меня разворачивается на 80% высоты окна, оказывается достаточно удобно и без головной боли поддержки и правки чужого кода.
Однако, в HabrAjax есть многое для того, чтобы собрать редактор фрагментов с кнопками, с контекстной кнопкой по выделению, которая там уже есть и заготовлена для отметки ошибок, и выполняет ещё несколько ролей. Более того, там даже поле ввода для редактирования выделенного фрагмента уже есть (см. эту страницу, там иллюстрации: spmbt.kodingen.com/habrahabr/habrAjax/habraQuotes-support.htm ). Если бы я делал его, то на основе HabrAjax. Если будет нужно, могу помочь прикрутить его в виде плагина, который вызывается контекстной кнопкой из установленного HabrAjax.
UFO just landed and posted this here
Что касается понятий WYSIWYM и WYSIWYG, то моё мнение следующее:
а) Если говорить про внутреннее представление, то у WYSIWYM оно непосредственно используется (или может использоваться) для редактирования. У WYSIWYG оно носит технический характер.
б) Если говорить про редакторы, то WYSIWYG позволяет редактировать в представлении максимально близком к итовому. У WYSIWYM обычно текстовый вид.
Вы можете использовать WYSIWYG редактор для создания HTML страниц, но при необходимости можно открыть и plaintext редактор для изменения HTML уже как WYSIWYM. Хотя может показаться, что в HTML всё жёстко задано, но возможность перекрыть любые стили своими (например, через внешний CSS файл) приводит к тому, что даже WYSIWYG редактор не обеспечивает точности представления.
Подскажите, если знаете готовый WYSIWYM редактор фрагментов, который позволяет пользователю самому выбирать фрагменты для редактирования. Мне найти не удалось.
а) Если говорить про внутреннее представление, то у WYSIWYM оно непосредственно используется (или может использоваться) для редактирования. У WYSIWYG оно носит технический характер.
б) Если говорить про редакторы, то WYSIWYG позволяет редактировать в представлении максимально близком к итовому. У WYSIWYM обычно текстовый вид.
Вы можете использовать WYSIWYG редактор для создания HTML страниц, но при необходимости можно открыть и plaintext редактор для изменения HTML уже как WYSIWYM. Хотя может показаться, что в HTML всё жёстко задано, но возможность перекрыть любые стили своими (например, через внешний CSS файл) приводит к тому, что даже WYSIWYG редактор не обеспечивает точности представления.
Почему-то ещё был упомянут Markdown, но не реализован.
Далее, что сказать по реализации? Мы получили редактор фрагментов, в котором приходится вручную вводить теги.Реализация — это лишь proof-of-concept идеи. Суть идеи в возможности видеть итоговое представление и точечно изменять отдельные фрагменты с помощью подходящего языка разметки.
Подскажите, если знаете готовый WYSIWYM редактор фрагментов, который позволяет пользователю самому выбирать фрагменты для редактирования. Мне найти не удалось.
> У WYSIWYM обычно текстовый вид.
По демо Wymeditor (1) я этого не заметил. Может быть, мало искал, но сложилось впечатление, что стараются в таких редакторах делать WYSIWYG-оболочку.
(Может быть, сделать 2 таба (HTML — VIEW) и кнопку Save рядом?)
> Подскажите, если знаете готовый WYSIWYM… выбирать фрагменты для редактирования
Не знаю, и не искал таких. Ведь редактировани фрагмента — это чисто ручная работа над конкретной реализацией движка. Как раз то, что Вы сделали. Любой редактор для этого подойдёт, если прикрутить превью фрагмента HTML.
Wymeditor — это исключение. Посмотрите, например, на обычные textarea в phpBB и Wikipedia (MediaWiki).
Что касается редактирования, то попробуйте отредактировать большую страницу Wikipedia, наполненную различными ссылками и сносками. Только возможность редактирования отдельных разделов немного спасает от переизбытка тэгов. Может быть, конечно, всем нравится преодолевать трудности, но мне более симпатична идея редактирования выделенного пользователем фрагмента.
Что касается редактирования, то попробуйте отредактировать большую страницу Wikipedia, наполненную различными ссылками и сносками. Только возможность редактирования отдельных разделов немного спасает от переизбытка тэгов. Может быть, конечно, всем нравится преодолевать трудности, но мне более симпатична идея редактирования выделенного пользователем фрагмента.
Лучше бы в Хабре сделали поддержку markdown.
Вы не пробовали JSHint'ом, там, проверить свой код, тесты написать?
В ходе тестирования искал ошибки и следил за чистотой консоли. Пока это был лишь пример.
Сейчас прогнал через JSHint. Основные предупреждения связаны с «Expected '===' and instead saw '=='.».
Жаль, конечно, что никто не прокомментировал саму идею, а всё сводилось лишь к скрипту. Но кто-то заинтересовался, поэтому движение в этом направлении продолжу и буду писать по мере продвижения.
Сейчас прогнал через JSHint. Основные предупреждения связаны с «Expected '===' and instead saw '=='.».
Жаль, конечно, что никто не прокомментировал саму идею, а всё сводилось лишь к скрипту. Но кто-то заинтересовался, поэтому движение в этом направлении продолжу и буду писать по мере продвижения.
Мне просто не понравилось решение. С т. з. юзабилити, довольно неудобно выделять код, нажимать редактировать, потом сохранять. Во-первых, это слишком много действий, во-вторых это создает лишний режим.
Сама предпосылка вида
вызывает вопрос. Зачем вам код? Вы заметку пишете или код?
Прежде чем бросаться с места в обрыв, я бы сидел и думал над сценариями и вариантами реализации, чтобы быть совершенно уверенным в решении.
Поэтому я просто поделился с вами абсолютно верными методиками гарантии качества продукта.
И кстати, вы очень многословны для такой мелочи – ощущение, что текста написали больше, чем кода. Надо понимать, что будет людям интересно читать.
Сама предпосылка вида
представление отделено от кода
вызывает вопрос. Зачем вам код? Вы заметку пишете или код?
Прежде чем бросаться с места в обрыв, я бы сидел и думал над сценариями и вариантами реализации, чтобы быть совершенно уверенным в решении.
Поэтому я просто поделился с вами абсолютно верными методиками гарантии качества продукта.
И кстати, вы очень многословны для такой мелочи – ощущение, что текста написали больше, чем кода. Надо понимать, что будет людям интересно читать.
Мне просто не понравилось решение. С т. з. юзабилити, довольно неудобно выделять код, нажимать редактировать, потом сохранять. Во-первых, это слишком много действий, во-вторых это создает лишний режим.Не вполне понял по поводу выделения кода.
У нас есть текстовый редактор (без представления), который поддерживает тэги. Можно редактировать в нём. Но когда текста много, то делать это неудобно, поэтому предлагается перейти в режим просмотра и там редактировать уже выборочно.
WYSIWYG редакторы подходят для небольших документов, особенно, когда текст только набирается или форматируется. Сложность редактирования структуры и текста в больших документах заметно возрастают и не всегда очевидно, каким образом можно что-то исправить. Например, часто для исправления текста в Word приходится копировать его в Notepad++, после чего вставлять обратно и там форматировать.
В качестве примера приведу математические формулы. Сравните их ввод и подготовку к печати в Word по сравнению с LaTeX.
Прежде чем бросаться с места в обрыв, я бы сидел и думал над сценариями и вариантами реализации, чтобы быть совершенно уверенным в решении.Можете что-нибудь предложить в качестве решения задачи онлайн редактирования большого (страниц 10-15) отформатированного текста на основе тэгов? WYSIWYG аналоги Google Docs не подходят, поскольку не расширяемы и отсутствует возможность редактирования внутреннего представления.
Поэтому я просто поделился с вами абсолютно верными методиками гарантии качества продукта.Не вполне понял, где приведены сами методики, хотя сочетание «абсолютно верными» меня уже немного испугало. За JSHint спасибо.
Не вполне понял, где приведены сами методики
Методика простая – используйте grunt, там есть все необходимые инструменты.
Можете что-нибудь предложить в качестве решения задачи онлайн редактирования большого (страниц 10-15) отформатированного текста на основе тэгов?
Конкретных идей у меня нет (не размышлял на эту тему), но предложенный вариант и вообще ход мыслей, основанный на том, что обязательно должны быть режимы представления и кода – не нравится. Если честно, не до конца понял, чем вам ворд для больших документов не подошел. Я в режиме структуры без проблем делал 150-страничный дисер. Поясните пожалуйста подробнее, в чем у вас возникла сложность с вордом?
Есть соображения, что должен быть хороший инструмент распознавания ввода, возможно общепринятая простая нотация для этого ввода. В случае, если режимы кода/отображения исключительно необходимы, то надо делать что-то безрежимное, как пример latex, или тот-же annotated source в backbone/underscore, где видно сразу обе части и происходит синхронное выделение фрагментов.
Grunt посмотрел, надо будет настроить, спасибо.
В Word возникают проблемы с форматированием, когда не ясно, откуда оно берётся. Чаще всего проблема с удалением пустых строк. Когда при удалении меняется формат предыдущего параграфа. Не всегда очевидно, каким образом его сохранить. Другая проблема с работой с распозанным текстом, когда задаётся различное число колонок, позиционирование и т.п. Если документ изначально создаю сам, то тут всё намного проще.
Идея с параллельным представлением кода и результата нравится, но как опция.
В Word возникают проблемы с форматированием, когда не ясно, откуда оно берётся. Чаще всего проблема с удалением пустых строк. Когда при удалении меняется формат предыдущего параграфа. Не всегда очевидно, каким образом его сохранить. Другая проблема с работой с распозанным текстом, когда задаётся различное число колонок, позиционирование и т.п. Если документ изначально создаю сам, то тут всё намного проще.
Идея с параллельным представлением кода и результата нравится, но как опция.
Sign up to leave a comment.
jsiedit: идея и создание удобного подключаемого WYSIWYM редактора с примером для Хабрахабра