Дизайн текста 4: Ссылки, del, ins, дополнительные элементы
Ссылки
С «древних времён» ссылки выделялись подчёркиванием. Ну так уж повелось. С тех пор, люди на столько привыкли к этому, что каждый раз, как видят подчёркнутый текст, сразу пытаются его ткнуть. И если ожидаемый результат не произошёл, то пользователь чувствует себя обманутым.
Ни в коем случае не используйте подчёркивание в качестве декоративного оформления каких либо элементов кроме ссылок.
Ссылки обязательно должны чем-то отличаться от основного текста, пользователь должен сразу понять, что этот текст кликабелен. Отличаются они как правило цветом и подчёркиванием. Если цвет, одно из основных отличий ссылок, то подчёркивание применять не обязательно. К цвету можно так же добавить полужирное начертание, но не стоит злоупотреблять. Например, в больших статьях, ссылки не должны сильно контрастировать с основным текстом ни по цвету, ни по начертанию, иначе они, как бельмо на глазу, будут только мешать восприятию информации. Опять же, полужирным начертанием выделяются основные ключевые моменты в тексте, если все ссылки жирно выделять, то это вызовет некоторое непонимание в расставленных акцентах.
Удалённое и добавленное содержимое
Элементы <del> и <ins> существуют для указания в тексте удалённого и обновлённого содержимого.
Меня однажды спросили: а зачем это нужно? Почему нельзя просто удалить текст и вместо него написать новый? Эти элементы используются для того, чтобы явно указать изменения в тексте. Пример скидок самый простой:
Картофель — 0,80 0,79 €.
В результате получаем: Картофель — 0,80 0,79 €.
Похожий пример приводится во всех учебниках и здесь есть один минус — элемент >ins> по-умолчанию оформляется подчёркнутым начертанием, что является недопустимым и это нужно исправлять с помощью CSS. Один из удачных способов выделения этих элементов — задание фонового цвета. Для удалённого текста — красного оттенка, для добавленного — зелёного. Возможен и другой вариант: удалённый текст — более приглушённого цвета, чем основной текст, а добавленный — полужирным.
Не многие знают, что эти элементы по рекомендации W3C допустимо использоваться как элементы блочного уровня, заключая в них другие блочные элементы.
Дополнительные строчные элементы
Вообще, в тексте может быть достаточно много различных строчных элементов (code, samp, var, kbd, tt и другие), которые могут отличаться от основного текста, не только начертанием, но гарнитурой и даже размером шрифта.
Существует достаточно много способов отформатировать специфический элемент в тексте не изменяя его гарнитуры. Например, по-умолчанию элемент <code>, который предназначен для отображения исходного кода программы, имеет моноширинный шрифт. Так как <code> является строчным элементом, то он может быть вставлен в строку среди текста. Если шрифт текста отличается от <code>, то появляется неприятный контраст гарнитур.
Рекомендуется все строчные элементы используемые среди текста отображать той же гарнитурой и тем же размером кегля, что и у основного текста. Если нужно выделить, то рекомендую воспользоваться стандартными средствами для изменения начертания (font-style, font-weight, font-variant), цветом, цветом фона, границами элемента. Но ни в коем случае не менять гарнитуру.
Форматирование в редакторах
Текстовые редакторы в современных CMS системах дают возможность отформатировать текст по нашему вкусу. И это очень плохо. Почему? Ну представьте себе, что вы создали дизайн сайта, настроили отображение основных элементов текста, а администратор сайта, при размещении материала стал злоупотреблять возможностями текстового редактора: покрасил текст в розовый цвет, добавил синий фоновый цвет, увеличил шрифт, сделал его наклонным и центрированным. Ужас!
Предлагаю общим умом составить список элементов контента уместных для отображения на веб-сайтах и которым необходимо особое форматирование. Но элементы, нужно выбирать по их смысловому значению, а не визуальному.
К примеру, если смотреть на TinyMCE:
- Термины и их значения, список вопросов и ответов — принцип одинаковый (текстовые редакторы ими пренебрегают);
- Сноски — как в Википедии. Можно использовать вместе с элементом <dfn> для обозначения терминов. Возле термина ставится номер сноски (<sup>), а внизу страницы помещается строка с описанием термина или пояснением какого-то момента в тексте;
- Примечания, дополнения, определения. Важные и довольно часто необходимые элементы, которые можно оформлять в виде плашек или помещаться в рамки;
- Важные примечания, дополнения, определения. Возможно каждому элементу можно задавать уровень важности и от этого будет выбираться оформление;
- Содержание статьи, например в виде списка «якорей», генерируемый автоматически по количеству заголовков в тексте;
- Предусмотреть варианты вставки иллюстраций, видео и аудио материалов с определёнными размерами, расположением и отступами;
- Правильное оформление цитат, удалённого и обновлённого содержимого со всеми необходимыми атрибутами.
- Эпиграф
От чего следует отказаться в WYSIWYG-редакторах:
- Подчёркивание (underline);
- Горизонтальное выравнивание (text-align);
- Выбор гарнитуры (font-family);
- Выбор кегля (font-size);
- Отступ/Выступ (indent/outdent);
- Выравнивание, размеры, качество, отступы, цвета фона и рамок иллюстраций и других медиа-файлов;
- Выбор цвета шрифта и фона;
- Смайлики (они допустимы только в переписке);
- Изменение размеров и цвета горизонтального разделителя;
- Слои (div { position: absolute });
- Любое изменение стилей
Любое оформление должно быть спроектировано, нарисовано дизайнером и записано верстальщиком в CSS файл. В редакторе должен быть выбор классов и элементов по их смысловому значению. Администратор вообще не должен задумываться о том, как это будет выглядеть.
Жду предложений по дополнению списков.
]]>Tod]]>ИМХО, решение ограничить пользователя весьма спорное. Ведь в документе Word никто не запрещает использовать выделение цветом только потому, что это может показаться некрасивым. А подобные редакторы как раз и направлены на то, чтобы дать пользователю максимальную свободу по управлению собственным сайтом. Ведь владелец ресурса имеет все права на его изменение как ему вздумается. А то, что кому-то это не нравится – так на вкус и цвет…
»]]>Никита]]>И зачем тогда владелец сайта заказывал дизайн сайта у какой-либо студии? Чтобы потом его испортить? И не путайте логику с оформлением, Ворд предназначен для оформления документов. Это инструмент, который может быть использован для любого вида документов. На сайте же один дизайн для содержимого определённой тематики и администратор не должен касаться оформления.
»]]>Tod]]>Вопрос очень спорный и зависит, я думаю, от 2-х вещей: предназначения сайта и его владельца, то есть лично я был бы против столь строгих ограничений. Более того текстовые редактор должен иметь возможность работы в режиме НТМЛ.
»Что же касается “испорченного дизайна”, то это право заказчика. Человек его приобретает и становится полноправным владельцем, поэтому может делать что ему угодно. Точно также изготовители ferrari могут запретить менять цвет машины, потому что для такой тачки подходит “только красный”. Тут проблема в другом – администраторе. Если он не умеет пользоваться предоставленным ему инструментом, то текстовый редактор тут не причем.
]]>Никита]]>Речь идёт о любых публикациях: новости, блоги, статьи, информация о компании, её деятельности, видах услуг и т. п.
> Что же касается “испорченного дизайна”, то это право заказчика. Человек его приобретает и становится полноправным владельцем, поэтому может делать что ему угодно.
Вот из-за такого отношения в интернете полно таких сайтов. Компания заказала сайт, ей нарисовали красивый дизайн, а текст предоставили редактировать самим. Получается, что на разных страницах разные размеры шрифта, разные цвета ссылок, встречается даже текст набранный прописными буквами.
> Если он не умеет пользоваться предоставленным ему инструментом, то текстовый редактор тут не причем.
Это бывает чаще всего. Поэтому редактору нужно предоставить оговорённый спектр возможностей оформления, но основываясь на логику.
В идеале, размещением и оформлением информации на сайте должна заниматься дизайн-студия выполнившая заказ. Заказчик должен только давать материал.
»]]>Tod]]>Боюсь мы дальше вообще перейдем к какому-то уж слишком глобальному обсуждению:) Изначально система управления сайтом должна содержать какое-то базовое оформление (стиль) для ссылок, списков, таблиц и т.п. Это правильно. Но если я хочу что-то изменить, мне требуется такая возможность. Ограничение не спасет, если редактор сайта не умеет работать. Повторюсь, что проблема не в инструменте. Испортить можно что угодно, если относиться к работе халатно.
Редактора нужно не ограничивать, а учить. Я думаю даже с обделенным набором возможностей неквалифицированный работник все равно сможет испортить оформление сайта. Даже простым копированием текста из Word.
Если говорить о том, что текст должна наполнять студия – запросто! Только это будет стоить денег. Исходя из личного опыта работы в этой сфере, не каждый готов на это потратиться, вообще многие считаю, что все сделать очень просто и платить тут вообще не за что. А потом получаются подобные сайты) Хотя это не самый плохой пример.
Собственно заказчик тоже играет роль. Есть много примеров, когда клиенты вносили изменения в дизайн просто ужасные, но как говорится его слово закон. И тут не поспоришь, разве что Лебедев может себе такое позволить. Это, конечно, относительно правильный ход, но не всегда уместный. Разбрасываться клиентами не считаю разумным.
»]]>Никита]]>> о если я хочу что-то изменить, мне требуется такая возможность.
Обращаемся к студии, которая создавала сайт и составялем договор на модификацию.
> Редактора нужно не ограничивать, а учить.
Если для этой цели существует лицо, которое занимается наполнением сайта и получает за это зарплату — его нужно учить, согласен. Если наполнением занимается секретутка — нужно ограничивать.
Каждый должен заниматься своим делом. Предприниматель — делать деньги, секретутка — работать с бумагами, профессиональный редактор — администрировать сайт.
Разбрасываться клиентами и не нужно, но нужно уметь убедить клиента в необходимости ограничения, принятие в штат профессионального редактора или доверять размещение материала студии. Этим должны заниматься менеджеры студии.
»]]>Андрей]]>Вы забыли про ссылки и заголовки.
»]]>Никита]]>Андрей, ссылки и заголовки в редакторах есть.
»]]>Tod]]>Если секретутка не может набрать текст в текстовом редакторе, то я не знаю что она вообще в жизни может. БОльшая часть клиентов наших нормально ориентируется в редакторе типо3 (я читал, что ты знаком с этой системой:), хотя там иногда не все так просто.
»“Договор на модификацию” звучит как “дополнительное выбивание денег” это я чисто для себя определяю:) Ты недооцениваешь многих секретуток:)
]]>Никита]]>Секретутка может набрать текст, но как она это сделает? Я видел документы многих фирм. Если они в этих документах списки обозначают дефисами или звёздочками, а номера прописывают вручную, то как они оформят текст на сайте?
TYPO3 — это не редактор, это CMF, а редакторы в нём (самые лучшие) — htmlAreaRTE и TinyRTE. Вот в этой системе мне нравится как легко можно убрать лишние кнопочки в редакторе для любой группы пользователей. Именно эту систему я могу поставить в пример, как лучшее решение для создания и использования различного рода элементов о которых я писал в этой статье.
»]]>Андрей]]>А я считаю, что в большинстве случаев визуальный редактор клиенту не требуются, ведь намного более понятны для секретутки, отделенные от содержания поля для введения заголовка страницы или вставки изображений, а термины, списки, сноски не всегда будут использоваться.
»]]>Tod]]>Ну собственно я в курсе что такое TYPO3:) Имел ввиду именно редакторы.
»Научить делать списки минутное дело особенно для таких классных текстовых редакторов:)
Если уж очень сильно хочется ограничить возможности администратора или пользователя системы, то лучше сделать разграничение прав редактирование – “для тупых”, “продвинутые”, “супер мастер”:)
]]>daedmen]]>Вот правильно очень пишешь про WYSIWYG-редакторы в CMSах, я вобще давно с пеной у рта доказываю что они там нафиг сдались, там нужен только набор шаблонов сделанных одновременно с остальным дизайном, в которые уже вбиваются данные нужные, и это гораздо более юзабельно.
»]]>Tod]]>daedmen, это нифига не юзабельно. Текст на сайте нельзя загнать в рамки определенные. Текст это не “заголовок” + “пару абзацей предложений”, а гораздо большее. Даже эпиграф не добавить, потому что “выравнивания вправо быть не должно”. Интересно, кстати, было бы увидеть результаты опроса относительно этих редакторов кто как смотрит на их применение со стороны разработчиков и пользователей.
»]]>Никита]]>Tod, разграничения естественно нужны.
Никто не предлагает загнать в рамки, даже если и загнать, то рамки будут очень широки.
Вот ты пишешь, что эпиграф нельзя добавить, ну так я же и предлагаю составить список элементов для размещения на сайте. Дизайнер оформит их как нужно. Спасибо за эпиграф, добавлю в список.
Опять же если разрешить выключку, то администратор сайта может сделать эпиграф по центру, по правой стороне, по левой и по формату. Ну и что за винегрет получится?
»]]>Tod]]>Не ну если администратор не понимает что такое эпиграф, то ведь это не проблема владельца сайта. В общем, все это смахивает уже на “холивор”:) Каждый делает по своему. Подводя итог лично от себя, могу сказать – если на сайте что-то получается не красиво, то виной этом не текстовый редактор, а кривые руки контент-менеджера.
»]]>Никита]]>Tod, если он не понимает что такое эпиграф, то ему не поможет ни стандартный редактор, ни такой о котором говорю я.
Прав, насчёт кривых рук. Но с помощью шаблонного форматирования можно было бы руки хоть немного поправить.
»]]>Tod]]>Это не исправит кривых рук, лишь ограничит их действия. Но как по мне проще найти толкового контент-менеджера и не париться. Не зря говорят “скупой платит дважды”:)
»]]>Артём Курапов]]>Ребят, ведь кроме font-style и font-size в tinymce ещё можно задавать и конкретные стили. Я как раз этой темой со своей админкой занимаюсь (Никита, взял твой CSS reset кстати), с WYSIWYG могу сказать что в действительности для использования нужно не более двух рядов кнопок, остальное просто балласт.
А шрифты это надо смотреть для чего это надо. Я помню как-то хотел оформить с их помощью внутренности таблицы, налепил, посмотрел в исходный код и ужаснулся. Потом просто дописал стили к внутренностям ячеек и заголовков таблицы статьи и стало легче.
С другой стороны тэг code активно использую, хотя его мало где советуют или советуют вкупе с тэгом pre, что помоему чуть излишне. Я думаю в админке должны быть более лёгкие диалоговые окошки для добавления цитат (blockquote, cite), кода (code), определений (dl) и тп.
»]]>Никита]]>Артём Курапов, именно так я и делаю, выбираю стили в выпадающем меню редактора. Именно для этого я и призываю вас помозговать относительно стандартных стилей, которые можно было бы добавить. Просто повесить те же классы на кнопочки — было бы удобнее.
для тех же таблиц, лучше делать шаблоны с классами
code строчный тэг, а pre — блочный, да ещё и с сохранением форматирования, поэтому его и используют. Просто, если бы был тэг блочного уровня специально для исходников, например <source> и работал бы он также как pre (т. е. сохранял форматирование), то использовали бы его. А так, народу просто лень для того же тэга <code> написать три строчки в CSS:
»code {
display: block;
white-space: pre;
font-family: monospace;
}
]]>rotor]]>>От чего следует отказаться в WYSIWYG-редакторах..
От WYSIWYG-редакторов и секретуток, которые по совместительству являются контент-редакторами
Вопрос на самом деле оч сложный и спорный, но среднестатистический юзер, который дорвался до клавы способен наворотить такого, о чем бы ты никогда заранее и не додумался. Тут нужны подопытные добровольцы, чтобы предусмотреть и залатать все дыры. А насчет ограничений при разработке дизайна (читай прописанных заранее стилей для текста) – часто клиенты приходят в ярость когда не могут что-то самостоятельно поправить на свой вкус, и начинаются звонки и гневные письма типа “почему это я тут не могу написать большими красными буквами на этом зеленом фоне?!”. Не все люди адекватны в своих желаниях…
P.S. Пост оч понравился. Полезно и наводит на мысли, но есть много причин почему в каждом конкретном случае все это малореализуемо.
»]]>Никита]]>rotor, если бы с клиентами работали грамотные менеджеры, то таких проблем небыло бы. Нужно клиента убедить, что это не ограничение, а привилегия! Дизайнер за вас уже постарался и создал кучу стилей, это большой прибольшой плюс! Вам всего лишь нужно пометить текст конкретным стилем и он сам отформатируется как надо!
»]]>Мир CSS» Blog Archive » Дизайн текста 4]]>[...] Читаем [...]
»]]>rotor]]>>если бы с клиентами работали грамотные менеджеры, то таких проблем небыло бы
Полностью согласен. Беда в том, что менеджеры больше заинтересованы как сорвать денег с клиента и мало что понимают в веб-технологиях.
»]]>Vladimir]]>> А так, народу просто лень для того же тэга <code> написать три строчки в CSS:
А смысл? Зачем делать инлайновый элемент блочным? Может быть, у pre “недостаточно семантичное” название, но на мой взгляд, pre больше здесь подходит.
> Не все люди адекватны в своих желаниях…
Согласен… На мой взгляд, стоит предоставлять два режима – минимальный (в котором ничего лишнего) и экспертный (со всеме наворотами, которые заказчик может использвать на свой страх и риск).
Всё равно рано или поздно появляется необходимость применить какой-нибудь другой стиль (которого могло и не быть в начальной спецификации), и если заказчик не сможет это сделать, у службы техподдержки появится лишняя головная боль.
Я согласен с мнением, что заказчик вправе творить все, что угодно. Тем более, что он за это деньги заплатил.
»]]>Никита]]>> А смысл? Зачем делать инлайновый элемент блочным? Может быть, у pre “недостаточно семантичное” название, но на мой взгляд, pre больше здесь подходит.
А почему бы не сделать? Ключевое здесь «на мой взгляд». Аргументируйте.
Конечно он в праве, но воспитывать их тоже надо.
»]]>Vladimir]]>> А почему бы не сделать?
Почему бы нет? Ну нет, так нет
> Аргументируйте.
Пожалуйста. На мой взгляд (опять же), страница должна быть одинаково доступной (в плане usability и accessinility) при выключенных JS, картинках, CSS (и их комбинации). В принципе, это даже логично: JavaScript призван задавать поведенческую модель, CSS предназначен для презентации (оформления), роль (X)HTML – представление документа с отражением смысловой (не презентационной) нагрузки его состоавляющих. Если мы будем использовать CSS для превращения строчного элемента в блочный, при выключенном CSS, согласитесь, это будет смотреться не очень. Тем более, что мы заново изобретаем велосипед, ибо стандартные средства (X)HTML нам уже предоставляют такой элемент.
Я еще не пробовал, но было бы интересно посмотреть на документ с блочным элементом code в lynx’е. А так же было бы интересно натравить на оба варианта скринридер (кстати, здесь разница может быть очень сильно заметна – например, на слух мы нормально воспримем 2*2=4 (это code), а вот какой-нибудь контурный интеграл (pre) на слух просто так не воспринимается).
Встречное предложение: зачем использовать div (span), если можно использовать span style=”display: block” (div style=”display: inline”)? На *мой* взгляд, это *почти* то же самое что и code vs pre (отличия есть, но для первого приближения сойдет).
Extrema linea: а почему бы не использовать для верстки только div и span (ладно, иногда table для таблиц и ol/ul для списков)? Теряется семантика? Но это же можно компенсировать семантически корректными (множественными) именами классов и id
Согласен, экстремизм, но тем не менее…
»]]>Никита]]>Vladimir, выключенный CSS — единственный адекватный аргумент, причём только в том случае, если сайт разрабатывается и для браузеров нечитающих CSS (покажите мне человека который пользуется такими браузерами и я буду горько плакать, жалея этого человека).
Если говорить о XHTML как о языке, роль которого «представление документа с отражением смысловой (не презентационной) нагрузки его состоавляющих», то почему вы предлагаете использовать <pre> для кода, когда есть <code>? Ссылаясь на визуальное отличие этих двух тэгов, а не смысловое, вы сами себе противоречите.
Когда нужно, чтобы визуально <span> стал блочным элементом, то используют display: block;, что в этом плохого? По смыслу span — это не division, у span более узкий смысл.
Чувствую в себе силы написать новый пост об XHTML и его странностях.
»]]>Vladimir]]>Их всего два, и оба адекватны, причем второй аргумент основан на спецификации HTML и ее рекомендациях.
Отнюдь, ибо это элементы разных масштабов. Визуальное отличие здесь вытекает именно из смысла элемента. И оно существенно для агента/бота, не рассматривающего презентационные аспекты.
Вообще, если прочитать спецификацию, то там указывается, что pre – это элемент уровня параграфа (т.е. блочный), в то время как code – элемент, придающий смысловую (структурную) информацию части фразы.
Это примерно как blockquote и q – соответствующим CSS их можно сделать практически идентичными по внешнему виду (то есть то, что мы сейчас имеем с code и pre), но при этом изначально спецификацией предполагалось, что q – для коротких цитат, а blockquote – для длинных
Возвращаясь к математике: в тексте допустимо привести короткую простую формулу (строчный элемент), но в то же время более-менее сложные формулы приводятся отдельно (блочные элементы).
Другое отличие – в SGML-определении элементов.
На самом деле, у них один и тот же смысл во всем, кроме одного единственного момента, который Вы переопределяете, ставя display: block:
А смысловая разница между ними такая же, как между анонимным блочным и строчным элементом. И div, и span являются групирующими (grouping) элементами, но не разделяющими (dividing).
В общем, подводя итог вышесказанному, всё зависит от того, с какой колокольни смотреть.
Счастливый, Вы, видимо, на медленном диалапе/GPRS не сидели… Сначала загрузится страница, и уж пока браузер все стили к ней применит…
Или сидит админ в шелле с мобилки, нужно ему что-то срочно погуглить, что он будет использовать? Что-нибудь lynx-ообразное – неоднократно видел.
Третий пример – Google cache. Если на stylesheet была относительная ссылка, stylesheet рискует не попасть в кэш Гугла/МСН. Соответственно, считайте, что стилей на странице нет.
»]]>Никита]]>Vladimir, элемент pre расшифровывается как preformatted text. Здесь опять же идёт намёк на визуальную особенность элемента. Что идёт в противоречие с самой сутью XHTML.
> Это примерно как blockquote и q
Blockquote и q — почти одинаковые по смыслу элементы. А pre и code — совершенно разные.
> These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content
С этим я тоже не согласен. В любом случае, span будет всегда в div. div засовывать в span — никакого смысла. Этим можно руководствоваться при вёрстке веб-страницы. div — структура, span — группировка строчных элементов.
> Вы, видимо, на медленном диалапе/GPRS
на dialup-е не сидел (вы в каком веке/деревне живёте).
gprs пользуюсь, но с отключенными картинками. CSS все современные и популярные мобильные браузеры понимают, тем более что под них есть специальный тип media.
Админу не повезёт, это правда. А все современные CMS ставят абсолютные ссылки на все внутренние ресурсы.
В данном и конкретном случае выход один — <pre><code> … </code></pre>
»]]>Vladimir]]>> Vladimir, элемент pre расшифровывается как preformatted text. Здесь опять же идёт намёк на визуальную особенность элемента. Что идёт в противоречие с самой сутью XHTML.
Ну я говорил, что название у него не семантичное… Я бы сказал, это наследие прошлого… И ведь в отличии от презентационных элементов, pre не deprecated и существует в XHTML 1.1.
> В данном и конкретном случае выход один — <pre><code> … </code></pre>
Тем более, что оно даже работает нормально и спецификации не противоречит. Кстати, надо взять на заметку.
С этим соглашусь
> С этим я тоже не согласен.
В любом случае, так утверждает спецификация
> В любом случае, span будет всегда в div. div засовывать в span — никакого смысла.
Тем более, что это невалидно. Точно так же code может быть в pre, а наоборот – никак. Аналогично с q и blockquote.
> div — структура
Структура, да. Они оба структурные элементы. Но кроме определения группы элементов и создания блока, div никакой семантической нагрузки не несет. span определяет группу строчных элементов, и кроме этого тоже никакой более семантической нагрузки не несет.
> на dialup-е не сидел (вы в каком веке/деревне живёте).
Грубо говоря, 1.5 метра трафика – $1.
Иногда приходится, когда провайдеру плохо (выбор небольшой, увы) – выхожу в Интернет через GPRS-модем, а это ну в лучшем случае 4 кБ/с
> А все современные CMS ставят абсолютные ссылки на все внутренние ресурсы.
Далеко не все
Тот же WordPress со своей дефолтной конфигурацией TinyMCE имеет тенденцию к формированию относительных ссылок. А будет ли CSS абсолютным/относительным – зависит от автора темы и использования тэга base.
»]]>Данила]]>Сударь вы совершенно правы! как говорят, все что может быть понято и сделано не так, обязательно будет сделано и понято не так.
Я в системе управления использую редактор где нельзя менять цвет размер и гарнитуру шрифта, при верстке текста оперировать предполпгается заголовками первого второго уровня, стронг, подчеркивание правда есть, все это есеесьно через цсс, можно соответственно еще необходимые классы прописать ну там цытаты и проч,
так вот пресловутые пользователи даже при таком скуднром наборе умеют наворотить такого что сводит на нет мои усилия, естественно рекомендации по верстке текста никто и не читает, блять все и так умные (звиняйте вырвалость)
да еще у мну редактор инлайновый, то ись видно сразу как это все на страничке то будет,
так что я бы не только все ограничил, но еще бы и чтобы током било когда оператор контента что нить не так сделат, условный рефлекс чтобы вырабатывался
P.S все что может быть сделано не так, будет понято и сделано так
»]]>Обзор №6, май 2008 – Design For Masters]]>[...] упорно движется к идеалу плеера. Типографика Дизайн текста 4: Ссылки, del, ins, дополнительные элементы Никита предлагает ограничить возможности WYSIWYG [...]
»]]>Seleckis.lv :: журнал Никиты Селецкого » » Дизайн текста 3.5: Вложенные списки, графические маркеры]]>[...] Продолжение: Ссылки, del, ins, дополнительные элементы Дата: 09.04.2008 » Комментарии (11) Категории: CSS | Usability | Web‑дизайн Поместить пост в закладки » [...]
»