Я в системе управления использую редактор где нельзя менять цвет размер и гарнитуру шрифта, при верстке текста оперировать предполпгается заголовками первого второго уровня, стронг, подчеркивание правда есть, все это есеесьно через цсс, можно соответственно еще необходимые классы прописать ну там цытаты и проч,

так вот пресловутые пользователи даже при таком скуднром наборе умеют наворотить такого что сводит на нет мои усилия, естественно рекомендации по верстке текста никто и не читает, блять все и так умные (звиняйте вырвалость)

да еще у мну редактор инлайновый, то ись видно сразу как это все на страничке то будет,

так что я бы не только все ограничил, но еще бы и чтобы током било когда оператор контента что нить не так сделат, условный рефлекс чтобы вырабатывался

P.S все что может быть сделано не так, будет понято и сделано так

Ну я говорил, что название у него не семантичное… Я бы сказал, это наследие прошлого… И ведь в отличии от презентационных элементов, pre не deprecated и существует в XHTML 1.1.

> В данном и конкретном случае выход один — <pre><code> … </code></pre>
С этим соглашусь Тем более, что оно даже работает нормально и спецификации не противоречит. Кстати, надо взять на заметку.

> С этим я тоже не согласен.
В любом случае, так утверждает спецификация

> В любом случае, span будет всегда в div. div засовывать в span — никакого смысла.
Тем более, что это невалидно. Точно так же code может быть в pre, а наоборот – никак. Аналогично с q и blockquote.

> div — структура
Структура, да. Они оба структурные элементы. Но кроме определения группы элементов и создания блока, div никакой семантической нагрузки не несет. span определяет группу строчных элементов, и кроме этого тоже никакой более семантической нагрузки не несет.

> на dialup-е не сидел (вы в каком веке/деревне живёте).
Иногда приходится, когда провайдеру плохо (выбор небольшой, увы) – выхожу в Интернет через GPRS-модем, а это ну в лучшем случае 4 кБ/с Грубо говоря, 1.5 метра трафика – $1.

> А все современные CMS ставят абсолютные ссылки на все внутренние ресурсы.

Далеко не все Тот же WordPress со своей дефолтной конфигурацией TinyMCE имеет тенденцию к формированию относительных ссылок. А будет ли CSS абсолютным/относительным – зависит от автора темы и использования тэга base.

> Это примерно как 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, выключенный CSS — единственный адекватный аргумент

Их всего два, и оба адекватны, причем второй аргумент основан на спецификации HTML и ее рекомендациях.

Ссылаясь на визуальное отличие этих двух тэгов, а не смысловое, вы сами себе противоречите.

Отнюдь, ибо это элементы разных масштабов. Визуальное отличие здесь вытекает именно из смысла элемента. И оно существенно для агента/бота, не рассматривающего презентационные аспекты.

Вообще, если прочитать спецификацию, то там указывается, что pre – это элемент уровня параграфа (т.е. блочный), в то время как code – элемент, придающий смысловую (структурную) информацию части фразы.

Это примерно как blockquote и q – соответствующим CSS их можно сделать практически идентичными по внешнему виду (то есть то, что мы сейчас имеем с code и pre), но при этом изначально спецификацией предполагалось, что q – для коротких цитат, а blockquote – для длинных

Возвращаясь к математике: в тексте допустимо привести короткую простую формулу (строчный элемент), но в то же время более-менее сложные формулы приводятся отдельно (блочные элементы).

Style sheets provide the means to specify the rendering of arbitrary elements, including whether an element is rendered as block or inline. In some cases, such as an inline style for list elements, this may be appropriate, but generally speaking, authors are discouraged from overriding the conventional interpretation of HTML elements in this way.

Другое отличие – в SGML-определении элементов.

По смыслу span — это не division, у span более узкий смысл.

На самом деле, у них один и тот же смысл во всем, кроме одного единственного момента, который Вы переопределяете, ставя display: block:

These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content

А смысловая разница между ними такая же, как между анонимным блочным и строчным элементом. И div, и span являются групирующими (grouping) элементами, но не разделяющими (dividing).

В общем, подводя итог вышесказанному, всё зависит от того, с какой колокольни смотреть.

покажите мне человека который пользуется такими браузерами и я буду горько плакать, жалея этого человека

Счастливый, Вы, видимо, на медленном диалапе/GPRS не сидели… Сначала загрузится страница, и уж пока браузер все стили к ней применит…

Или сидит админ в шелле с мобилки, нужно ему что-то срочно погуглить, что он будет использовать? Что-нибудь lynx-ообразное – неоднократно видел.

Третий пример – Google cache. Если на stylesheet была относительная ссылка, stylesheet рискует не попасть в кэш Гугла/МСН. Соответственно, считайте, что стилей на странице нет.

Если говорить о XHTML как о языке, роль которого «представление документа с отражением смысловой (не презентационной) нагрузки его состоавляющих», то почему вы предлагаете использовать <pre> для кода, когда есть <code>? Ссылаясь на визуальное отличие этих двух тэгов, а не смысловое, вы сами себе противоречите.

Когда нужно, чтобы визуально <span> стал блочным элементом, то используют display: block;, что в этом плохого? По смыслу span — это не division, у span более узкий смысл.

Чувствую в себе силы написать новый пост об XHTML и его странностях.

> Аргументируйте.

Пожалуйста. На мой взгляд (опять же), страница должна быть одинаково доступной (в плане 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 Согласен, экстремизм, но тем не менее…

Конечно он в праве, но воспитывать их тоже надо.

> Не все люди адекватны в своих желаниях…
Согласен… На мой взгляд, стоит предоставлять два режима – минимальный (в котором ничего лишнего) и экспертный (со всеме наворотами, которые заказчик может использвать на свой страх и риск).

Всё равно рано или поздно появляется необходимость применить какой-нибудь другой стиль (которого могло и не быть в начальной спецификации), и если заказчик не сможет это сделать, у службы техподдержки появится лишняя головная боль.

Я согласен с мнением, что заказчик вправе творить все, что угодно. Тем более, что он за это деньги заплатил.