Ещё не начали появляться редакторы на Flex/Silverlight/...? Насколько это возможно? Это я спрашиваю потому что в обычных WYSIWYG редакторах очень много проблем и тормозов из-за различий в браузерах и трудностей с манипуляцией редактируемым текстом из javascript.
А ты видел что-нибудь похожее на code editor? Чтобы задавать ключевый слова и названия функций, а он уже при печатании текста юзером автоматически раскрашивал.
MS>А ты видел что-нибудь похожее на code editor? Чтобы задавать ключевый слова и названия функций, а он уже при печатании текста юзером автоматически раскрашивал.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Mamut, Вы писали:
M>>Большая таблица, сравнивающая онлайновый WYSIWIG редакторы — как бесплатные так и коммерческие
M>>http://www.geniisoft.com/showcase.nsf/WebEditors
А>Ещё не начали появляться редакторы на Flex/Silverlight/...? Насколько это возможно? Это я спрашиваю потому что в обычных WYSIWYG редакторах очень много проблем и тормозов из-за различий в браузерах и трудностей с манипуляцией редактируемым текстом из javascript.
Здравствуйте, Mika Soukhov, Вы писали:
M>>Большая таблица, сравнивающая онлайновый WYSIWIG редакторы — как бесплатные так и коммерческие M>>http://www.geniisoft.com/showcase.nsf/WebEditors MS>А ты видел что-нибудь похожее на code editor? Чтобы задавать ключевый слова и названия функций, а он уже при печатании текста юзером автоматически раскрашивал.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Здравствуйте, anonymous, Вы писали:
A>>Есть редактор JavaScript: http://marijn.haverbeke.nl/highlight/, и его описание: http://marijn.haverbeke.nl/highlight/story.html. (Сейчас сервер почему-то не доступен, пользуйтесь кешем поисковых машин.) MS>А на что там смотреть, если гугл через кеш не отдает скрипты?
Здравствуйте, anonymous, Вы писали:
MS>>А на что там смотреть, если гугл через кеш не отдает скрипты?
A>На описание, может сам захочешь подобное сделать.
Сравнение редакторов только с одной, зачастую не самой существенной стороны. Или наличие кнопки для "акроним" столь существенно?
В целом поверхностно .
Все, что здесь сказано, может и будет использоваться против меня.
По моему, типичные недостатки редакторов (исчезание ctrl+z, тормоза, проблемы со вставкой, нестандартный код, разное поведение в разных браузерах) происходит из-за использования javascript и API браузеров. Но только что посмотрел в список в теме выше — там есть редакторы, которые устанавливаются в виде плагина к браузеру (например, XStandard). По идее, это должно решить те проблемы (судя по фичам XStandard, это так). Может, пора забыть про чисто javascript редакторы? Хотя в таких местах, как форум, требовать установки плагина неразумно, но туда, ИМХО, лучше подойдёт обычный BB-код.
Я предложил добавить в html5 элемент <richtext> (вместо этого изврата с contenteditable).
... If you take a look through the list you will find that almost all of them designed to edit only HTML fragments and not a full page editors.
Pure content WYSIWYG editors are used in:
— blog (article) editors;
— wiki and other forms of CMS;
— online e-mail clients;
These use cases cover 80%-95% of all WYSIWYG editing needs. So I think it makes sense to introduce special input element <richtext> or <htmlarea> rather than trying to define undefineable that appears to be that @contenteditable (as a UI mode) and its interaction with scripts and styles.
I see such <richtext> as an input element with API simple as possible:
<richtext attributes>
...initial html content...
</richtext>
There are just two attributes:
— tools="id"
is an ID of toolbar — element that contains buttons like
"B", "I", "H1", "H2", etc. These buttons are bound to internal
"registers" of the editor and styleable by the author of the
host page. Such toolbar binding shall not require scripting to
operate. Binding can be made by using @command attribute of
tool[bar] buttons. See example below.
— content-styles="url.css"
is an url of style sheet that contains list of style
declarations. This list contains only simple "tag" selectors
and is used for:
a) styling the editing content;
b) definition of HTML elements that are allowed to be used
in this instance of the editor.
We can define minimal list of commands that conforming UA
shall support plus optional extended set.
flat DOM --------------------------
Such <richtext> shall use so called "flat DOM" so
there cannot be:
1) nested <div>s;
2) <li> is a kind of <p> — can contain only text and spans.
3) nested tables;
4) only two levels of spans are allowed — so called
background and foreground spans;
5) there are no <font> and <span> elements inside the editor.
content submission -----------------------
Richtext submits data as html text in the same way as <textarea>.
I think that the <richtext> shall allow <img/> to be inserted
in the document from clipboard (from local machine).
Submission of such images shall be done together with document.
I am thinking either about special <data> container that have named <item>s with base64 encoded image data or by using <img src="data:..">.
----------------------------
Goal is to have input element that can handle "as-is" major number of cases and is easy to use by developers and by user.
Т.е. идея иметь более меннее стандартный <richtext> который по submit посылает свой html (или некий wiki markup) на сервер вместе с images — как одно целое.
При этом стилирование toolbar — это дело host page. Toolbar может вообще кстати отсутствовать. Я делаю сейчас имплементацию такого <richtext> для htmlayot/sciter и в принципе практически все можно редактировать без toolbar и всю интеграцию в страницу можно делать вообще без scripting. binding of tool buttons c функциями внутри сугубо декларативное.
Вот примерно так:
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Я предложил добавить в html5 элемент <richtext> (вместо этого изврата с contenteditable).
A>И что ответили?
А ничего. Тишина.
Народ озабочен например обсуждением встраивания SQLite в HTML5. Т.е. как я понимаю HTML5 как документ будет еще содержать дефинцию SQL flavor используемый в SQLite. HTML5 будет как я понимаю выглядеть как новогодняя ёлка в дурдоме "Ромашка".
A>>И что ответили?
CS>А ничего. Тишина. CS>Народ озабочен например обсуждением встраивания SQLite в HTML5. Т.е. как я понимаю HTML5 как документ будет еще содержать дефинцию SQL flavor используемый в SQLite. HTML5 будет как я понимаю выглядеть как новогодняя ёлка в дурдоме "Ромашка".
Такая же проблема, как в w3c? Народ максимально удален от чаяний веб-разработчиков?
Здравствуйте, Mamut, Вы писали:
A>>>И что ответили?
CS>>А ничего. Тишина. CS>>Народ озабочен например обсуждением встраивания SQLite в HTML5. Т.е. как я понимаю HTML5 как документ будет еще содержать дефинцию SQL flavor используемый в SQLite. HTML5 будет как я понимаю выглядеть как новогодняя ёлка в дурдоме "Ромашка".
M>Такая же проблема, как в w3c? Народ максимально удален от чаяний веб-разработчиков?
Там эта.. "смешались в кучу кони, люди"... обсуждается и в what wg и в html wg @ w3c.
sqlite как я понимаю двигают люди из google gears. И я не понимаю зачем. Ну сделали же они свои gears. Зачем их в станадарт то встраивать? Года через два — да, можно глянуть на статистику использования и тогда уже решать...
Здравствуйте, c-smile, Вы писали:
CS>sqlite как я понимаю двигают люди из google gears. И я не понимаю зачем. Ну сделали же они свои gears. Зачем их в станадарт то встраивать? Года через два — да, можно глянуть на статистику использования и тогда уже решать...
Дык, чтобы непосредственно на "статистику использования" и повлиять. А как же иначе.
Здравствуйте, akasoft, Вы писали:
CS>>sqlite как я понимаю двигают люди из google gears. И я не понимаю зачем. Ну сделали же они свои gears. Зачем их в станадарт то встраивать? Года через два — да, можно глянуть на статистику использования и тогда уже решать...
A>Дык, чтобы непосредственно на "статистику использования" и повлиять. А как же иначе.
Я не понял в чем проблема-то. У тех use cases где нужны эти gears определенный круг пользователей которые могут нажать на линк Install Google Gears. Я вообще не понимаю как например Microsoft будет SQLite внутрь IE встраивать. Я так понимаю что они приделают
свой MSSQL движок со своим SQL. Что имхо гораздо хуже чем Gears от Google c SQLite на всех платформах.
А вообще я предлагал сделать простой persistence того же типа что и в sciter.
В DOM добавляем document.persistent.root объект и browser персистит (на диске) все JS object видимые по ссылкам от этого root.
Если надо SQL потом на это дерево то вот есть http://code.google.com/p/trimpath/wiki/TrimQuery которе можно напустить на этот root.
И делов-то. Предложил я это дело (document.persistent.root) на whatwg и тишина...
Здравствуйте, c-smile, Вы писали:
CS>Я не понял в чем проблема-то. У тех use cases где нужны эти gears определенный круг пользователей которые могут нажать на линк Install Google Gears. Я вообще не понимаю как например Microsoft будет SQLite внутрь IE встраивать. Я так понимаю что они приделают CS>свой MSSQL движок со своим SQL. Что имхо гораздо хуже чем Gears от Google c SQLite на всех платформах.
Я так понимаю, что Product Manager MSIE просто положит с прибором на этот аспект HTML5, благо подобный опыт у них имеется. А в отличие от научников, у МС очень адекватное восприятие потребностей целевой аудитории. В итоге, комитет занимается проектом, который гарантированно умер еще до рождения.
CS>А вообще я предлагал сделать простой persistence того же типа что и в sciter. CS>В DOM добавляем document.persistent.root объект и browser персистит (на диске) все JS object видимые по ссылкам от этого root. CS>Если надо SQL потом на это дерево то вот есть http://code.google.com/p/trimpath/wiki/TrimQuery которе можно напустить на этот root. CS>И делов-то. Предложил я это дело (document.persistent.root) на whatwg и тишина...
Я бы вообще всех этих воркгрупцев уволил, а оставил одного тебя.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
.
