Seleckis.lv :: журнал Никиты Селецкого » xhtml/xml http://seleckis.lv Tue, 08 Feb 2011 13:52:50 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Вёрстка в Латвии: Вчера. Сегодня! Завтра? http://seleckis.lv/journal/research/vyorstka-v-latvii-vchera-segodnya-zavtra http://seleckis.lv/journal/research/vyorstka-v-latvii-vchera-segodnya-zavtra#comments Thu, 27 May 2010 15:31:55 +0000 Никита http://seleckis.lv/?p=1835 Версия моего выступления на Web Standards Days Riga 2010 вызвавшего неоднозначную реакцию.

Много было регистраций работников различных дизайн студий, компаний занимающихся разносторонней веб-разработкой, банков, министерств, фрилансеров и просто интересующихся. Я не зря добавил в форму регистрации поле для адреса сайта. Те люди, что собрались на конференцию, скромно говоря, флагманы, пионеры латвийской веб-разработки. Поэтому не грех было покопаться в их работах и попробовать понять, что же всё-таки у нас происходит с текущим использованием технологий?

Статистика вещь интересная, но только если она связанна с интересными темами. Мне было интересно заняться небольшим статистическим анализом, результатами которого я с вами сейчас поделюсь. Конечно в дебри я не полез, из-за большой лени, но то, чего успел накопать хватает достаточно, чтобы составить небольшую рекомендацию, с чего стоит начать осовременивать свою вёрстку.

Вчера

Итак, что же можно назвать «вчера»?

  • ASCII кодировка
  • Не использование DOCTYPE
  • DOCTYPE с указанием спецификации
  • Валидация ради валидации

Список можно продолжить, но мне лениво.

Кодировка

Для начала рассмотрим какие кодировки использовались на проанализированных сайтах.

Здесь всё замечательно, почти на всех сайтов используется кодировка utf-8. Это проще, чем подбирать для каждого языка свою. Здесь могу только посоветовать, тем 7 %, кто остался переходить на uft-8. Больше говорить не о чем.

DOCTYPE

Многие до сих пор не понимают значения доктайпа. Для того, чтобы это понять, нужно сначала обратиться к истории. Ну долго копаться в ней не будем, единственно упомянем, что существует два режима отображения веб-страницы — Standards Mode  и Quirks Mode,  ну так исторически сложилось. Первый — это режим отображения согласно веб-стандартам W3C, второй — режим поддержки старых сайтов, написанных в 90-е годы. Чем конкретно они отличаются читайте на W3C или в Википедии, ищите в Гугле… информации полно, но я на этом зацикливаться не буду. (Ну там ещё есть almost standards, который от standards почти не отличается)

Если вы не пишете доктайп, то включается Quirks Mode. Если пишете — Standards Mode. Но есть исключения:

  • Internet Explorer воспринимает декларацию HTML 4.0 и старее как Quirks Mode.
  • В случае с XHTML по правилам требуется xml-декларация. И её фактически никогда не пишут, поскольку из-за неё IE6 переключается в Quirks Mode.
  • Опера вообще не поддерживает Quirks Mode. Даже без DOCTYPE страница рендерится в Standards Mode.

Более подробные нюансы о QuirksMode можно почитать в Википедии.

Итог: Чтоб избежать проблем нужно использовать DOCTYPE обязательно.

DOCTYPE с указанием спецификации или валидация ради валидации

Теперь посмотрим как у нас обстоят дела с доктайпами на латвийских сайтах.

Великолепно! 68 % указывают XHTML  декларацию. А теперь проверим, проходят ли они валидацию?

Внимание, вопрос! Зачем для сайтов указывать доктайпы со спецификацией, если валидацию они не проходят?

Если почитать спецификацию XHTML, то такой документ по сути должен передаваться в формате application/xhtml+xml. Это можно сказать «чистый» XHTML. Правильный. Мы все любим правильность и я в том числе, поэтому большинство сайтов написаны в формате XHTML. Там и правильные закрывающие теги и правильная вложенность и дубрирующееся написание значения атрибутов-флагов.

А на самом деле все передают такой документ в формате text/html. Почему? Во-первых многие не знают, что он должен передаваться как application, а во-вторых — незачем! Чаще всего модульные технологии расширения, для которых был создан XHTML, не используются. Ни прстранства имён, ни MathML, ни семантическая вёрстка через RDF и другие крутые вещи не нужны для создния веб-сайтов и сервисов.

Так зачем же мы пишем такой сложный Доктайп? И при чём он у всех такой разный. Он вам не нужен такой! Напишите его проще. Вот так:

<!DOCTYPE html>

Дело в том, что именно по этой части DOCTYPE браузер определяет, переходить ли ему в режим Standards Mode или нет. Указание дальнейшей спецификации и соответствующего адреса браузеру не нужно, он прекрасно справится. Спецификация нужна только для валидатора. Тем более что данная декларация, вот именно в таком виде уже включена в стандарт HTML 5 и тупые ошибки вы сможете определить W3C-валидатором.

Хорошо, допустим вы такой упрямый и всё равно считаете, что будете верстать в XHTML и указывать соответствующий доктайп, просто потому, что так правильней и можно проверить в валидаторе ту самую паранойю «disabled=”disabled”». Но на какой стадии вы это делаете? На стадии девелопинга! Так на продакшен-сервере, то он вам зачем?! Вот то-то и оно…

Холивар про «em vs. px» напишу чуть позже.

]]> http://seleckis.lv/journal/research/vyorstka-v-latvii-vchera-segodnya-zavtra/feed 12 Выхлоп: HTML должен быть… http://seleckis.lv/journal/research/vyihlop-html-dolzhen-byit http://seleckis.lv/journal/research/vyihlop-html-dolzhen-byit#comments Wed, 09 Jul 2008 21:37:07 +0000 Никита http://seleckis.lv/journal/research/vyihlop-html-dolzhen-byit …основанным на логике. Да, это первое и самое главное. В принципе, это главное предназначение было описано еще в SGML.

Принцип логики нарушил ещё Папа вэба — Тим Бернерс-Ли, который в своём первом драфте накидал кучу визуальных тэгов. Shame on you, Tim! Хорошо хоть, исправляешься. Я неожиданно удивился изменениям в XHTML 2.0:

  1. Элемент <blockcode>, которого всем так не хватает, на замену тупой конструкции <pre><code> … </code></pre>
  2. Элемент <l>. Для обработки строк, незаменимая вещь. Опять же избавляемся от мусорного <br />
  3. Элемент <separator> взамен <hr />. Человечное и логичное название.
  4. Ну про <section> уже все успели написать и раскритиковать, но я поддерживаю это нововведение. Мне, например, не удобно постоянно следить за уровнем заголовков. Я бы предпочёл автоматизировать этот процесс наподобие нумерованных списков.
  5. Очень не хватало группировки терминов и значений. Именно из-за отсутствия такой возможности в статье о позиционировании картинок в галерее приходилось в качестве группирующего элемента использовать сам элемент <dl>, что было не логично и неудобно для восприятия.
  6. <nl> — это, насколько я понимаю в замен устаревшему <menu>. Насчёт обязательного присутствия элемента <label> я не согласен. Почему у меня не может быть навигации без заголовка? Тем более получается конфликт с одноимённым элементом в формах.
  7. Супер-пупер вещь — href в любых элементах! Сколько мучений с тем, что в тэг <a> не допустимо засовывать блочные тэги!
  8. Логичный атрибут edit вместо элементов <ins>, <del>, с дополнительными значениями. Похоже на свойства файла.
  9. Почти отказ от элемента <img>. Атрибуты src, usemap, ismap, shape, coords можно добавить для любого элемента, содержимое которого заменится на картинку переданную в src. Причём в src может быть не только картинка, но и любое другое содержимое, любой mime‑контент. Но чтобы это корректно работало, нужно указать тип содержимого в srctype. <img> в свою очередь стал парным тэгом, а содержимое его выступает в качестве альтернативного текста.
  10. <handler> вместо <script>. Зачем? Неужели <handle> семантически точнее, чем <script>? Опять же предлагается прямо в нём писать javascript. Да ещё и модуль XML событий добавили! А как же «Васька — отдельно, сосиски — отдельно»?
  11. Атрибут media во всех элементах. Т. е. можно сразу определить в элементе для какого девайса его показывать. Удобно когда нужно сделать страницу корректно отображаемую на мобильнике или печатаемую на принтере. Например, для мобильных браузеров не поддерживающие CSS это очень кстати. Хотя, к тому времени, когда XHTML 2.0 станет общеиспользуемым, у нас не останется таких мобильников.
  12. Элемент meta превратился в парный тэг. Логично. Информации много, её надо куда-то девать. В content всё не умещается.
  13. Нагородили огород с <link>. Народ cite толком не использует, а они ещё хотят писать дополнительные элементы <link> и <meta> для указания источника, языка, автора…
  14. Указание внешнего источника стилей расширено xml-ным способом, через элемент <?xml-stylesheet?>
  15. Нет объяснения, зачем к id добавили ещё xml:id. Видимо по той же причине что и xml:lang. Да, но зачем вообще явно указывать namespace?
  16. Отличнейший атрибут role. Любым приложениям, а так же поисковикам, можно будет рассказывать о предназначении того или иного элемента.

Сырой документ. Много недописанного, в том числе XForms. Но в целом «верной дорогой идёте, товарищи!» Но идти вы так будете очень долго.

Что мы имеем сейчас?

Самые непопулярные браузеры имеют самые быстрые темпы развития и поддержку новых технологий. Хочу обратить ваше внимание на тот факт, что браузеры Opera, Firefox и Safari поддерживают несуществующие тэги. Любой вами придуманный тэг (в HTML, а не в XML) является по‑умолчанию строчным, но его внешний вид можно настроить с помощью CSS как угодно.

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

Каким я вижу HTML?

XML + CSS. Разработчик не должен ограничиваться тем количеством элементов, что допускает спецификация. Он должен иметь возможность использовать любое название элемента. А любой элемент, в свою очередь может быть описан с помощью CSS.

Любые специфические элементы (элементы форм, внедряемые объекты, мета‑информация) нужно переводить в атрибуты и иметь возможность задавать их любым элементам.

Единственное, что можно допустить, это разделение невидимого контента, предназначенного для браузера (head), от отображаемого пользователю контента (body).

Убрать возможность добавлять скрипты и стили непосредственно в HTML‑документ. Только выносные.

Проблемы

Я не говорю о такой глобальной проблеме, как убеждение производителей браузеров в использовании такого метода. И так понятно, что их прошибить сложно. У них бизнес-план расписан на несколько лет вперёд.

Есть ещё одна — браузеры не поддерживающие CSS не имея чёткого представления о том, как должен отображаться тот или иной придуманный разработчиком элемент, отобразит всё содержимое всех элементов в виде сплошного одноразмерного текста без какого-либо форматирования.

Выхода два:

  1. оставить совместимость с существующим HTML;
  2. стандартизировать понятие «браузер», как программу отображающую содержимое размеченное HTML‑тэгами и стилизованное CSS‑описанием. Любые нестандартные проявления встречать свистом и недовольным улюлюканьем.

Второй вариант предпочтительней.

Жду гневные комментарии, господа верстальщики-гуру!

]]> http://seleckis.lv/journal/research/vyihlop-html-dolzhen-byit/feed 26 Стандарты, говорите..? http://seleckis.lv/journal/research/standartyi-govorite http://seleckis.lv/journal/research/standartyi-govorite#comments Wed, 02 Jul 2008 21:39:05 +0000 Никита http://seleckis.lv/journal/research/standartyi-govorite

Народ кричит: «Стандарты! Стандарты!» И я вместе с ними иногда покрикиваю. Причём если возникает вопрос «Почему?», то за ним незамедлительно следует ответ: «Так написано в Спецификации X(HTML) такой-то, такой-то». И дают сразу ссылку на вышеназванный документ, который читают полностью только самые дотошные зануды, а в основном все просматривают только описания конкретных элементов. «А-а-а! Ну тогда ладно…» — Вопрошатай оценил «бесценность» научного документа и возгордился тем, что смог его «асилить».

Из последней статьи о Дизайне текста, а особенно из комментариев я понял, что большинство тех, кто больше всех кричит о стандартах не понимают зачем они нужны, а значит используют возможности браузеров в вёрстке неэффективно.

Производители браузеров никогда не придут к единому консенсусу в отношении стандартов, у каждого есть своё собственное мнение о развитии веба и каждый будет гнуть свою линию. Опять же любая программа написана человеком и будет содержать множество ошибок. Даже самый первый программный код, который программисты пишут для вывода «hello world» содержит грамматические ошибки, что говорить о дальнейшем. Где грамматические, там и логические. Поэтому, каждый уважающий себя браузер всё равно имеет множество багов, которые «отличают» его от остальных.

Предположим, я напишу html и css по всем стандартам, т. е. буду использовать только те тэги, которые разрешены для использования спецификацией.

Вот тэги, которые я бы использовал часто:

<a>, <blockquote>, <body>, <br>, <cite>, <code>, <dd>, <div>, <dl>, <dt>, <em>, <form>, <h1> to <h6>, <head>, <html>, <img>, <input>, <label>, <li>, <link>, <meta>, <ol>, <option>, <p>, <script>, <object>, <param>, <select>, <span>, <strong>, <style>, <table>, <td>, <textarea>, <th>, <title>, <tr>, <ul>.

А эти я бы использовал очень редко или вообще не использовал бы:

<abbr>, <acronym>, <address>, <applet>, <area>, <b>, <base>, <basefont>, <bdo>, <big>, <button>, <caption>, <center>, <col>, <colgroup>, <del>, <dir>, <dfn>, <fieldset>, <font>, <frame>, <frameset>, <hr>, <i>, <iframe>, <ins>, <isindex>, <kbd>, <legend>, <map>, <menu>, <noframes>, <noscript>, <optgroup>, <pre>, <q>, <s>, <samp>, <small>, <strike>, <sub>, <sup>, <tbody>, <tfoot>, <thead>, <tt>, <u>, <var>, <xmp>.>

Одни тэги запрещены спецификацией, другие редко когда нужны, третьи вообще не нужны.

Если всё делать по стандартам, то скажите мне пожалуйста, зачем существуют выше перечисленные элементы? Они часто используются? Только не надо тыкать меня носом в спецификацию с объяснением. Эти объяснения надуманы. Чем руководствовался консорциум создавая это бодягу, но не подумав, например, о блочном варианте code? Почему нет <nobr>? Он мне нужен чаще, чем <sub>, <sup>, <del> или <ins>.

Опять же, одинаково отображается во всех браузерах наверное только половина первого списка.

Больше всего ругаются на IE. Да, это самый дырявый браузер. Но и под него можно подстроиться. Хватить канючить, пора работать. IE6 существует уже столько лет, что давно все его баги описаны и решения обхода известны. Многим просто лень гуглить.

Я сейчас не буду затрагивать тему CSS, только HTML. Если существует различный рендеринг в различных браузерах, то не нужно на это ругаться, это надо использовать. Особенно касается элементов форм. Их отображение зависит не только от браузеров, но зачастую и от операционных систем. Если хотите, то можете городить тучу кода на JavaScript для замены селекта. Я же буду использовать тот, что даёт конкретный браузер или операционная система.

Чем больше я занимаюсь вёрсткой, тем больше убеждаюсь: стандарты — в топку! Может бросить верстать?

]]> http://seleckis.lv/journal/research/standartyi-govorite/feed 51 5 советов верстальщику http://seleckis.lv/journal/css/5-sovetov-verstalschiku http://seleckis.lv/journal/css/5-sovetov-verstalschiku#comments Thu, 15 May 2008 10:02:06 +0000 Никита http://seleckis.lv/journal/css/5-sovetov-verstalschiku Стартуем эстафету среди специалистов по вёрстке!

Условия:

  • Речь идёт о html/xhtml/css вёрстке.
  • Передавать эстафету нужно другому блоггеру только в том случае, если вы уверены, что он действительно в этом разбирается.
  • Не используйте в качестве советов элементарные правила html/xhtml/css.
  • Особенно приветствуются хитрости исправляющие баги в IE без использования хаков.
  • Мало рассказать о каком-либо баге. Нужно предложить решение.

Итак, мои советы:

  1. Используй таблицы не для вёрстки страницы, а только для отображения таблицы с данными. Все возможные способы вёрстки документа доступны нам при использовании div-ной вёрстки. Div-ная вёрстка наиболее логична и лаконична.
  2. При использовании padding-top у внешнего элемента и margin-top у внутреннего, в IE срабатывает только свойство с наибольшим значением. Используй или только margin, или только padding, или делай отступы с использованием дополнительного контейнера.
  3. Не используй для элементов такие свойства CSS вместе: 
    ... {
	float: left;
	width: ... ;
	margin-left: ... ;
}

    или

    ... {
	float: right;
	width: ... ;
	margin-right: ... ;
}

    в этом случае IE6 будет увеличивать отступ (margin-left, margin-right) в два раза.
    Используй padding для внешнего контейнера, чтобы сдвинуть элемент. Или добавь ещё один контейнер и сдвигай его с помощью margin.

  4. Если хочешь чтобы пользователь IE6 мог изменять размеры шрифта на странице, то для определения размера шрифта следует использовать относительные единицы измерения: em и %.
  5. Чтобы не было проблем с языками все файлы сохраняй в кодировке UTF-8. Обязательно указывай кодировку в соответствующем meta-теге и для всех подключаемых файлов (например подключенных с помощью элементов <script>, <link>).

Эстафету передаю:

]]> http://seleckis.lv/journal/css/5-sovetov-verstalschiku/feed 36 Дизайн текста 3: Списки http://seleckis.lv/journal/web-dizayn/dizayn-teksta-3-spiski http://seleckis.lv/journal/web-dizayn/dizayn-teksta-3-spiski#comments Fri, 28 Mar 2008 14:52:45 +0000 Никита http://www.seleckis.lv/journal/web-dizayn/dizayn-teksta-3-spiski Списки бывают упорядоченные (<ol>) и неупорядоченные (<ul>). Упорядоченные, обычно, отображаются с нумерованным арабскими цифрами маркером. Неупорядоченные могут быть с маркерами вида: закрашенный кружочек, незакрашенный кружочек, закрашенный квадратик (как вижу, так и называю) или любой другой рисунок.

Начнём, с того, что уясним, что же такое список. Проведём аналогию с рукописным текстом. Если в тексте имеется перечисление, то это можно назвать списком. Причём если последовательность перечисленных элементов не зависит от какого-то определённого логического порядка, то этот список является неупорядоченным. Если же от перестановки перечисленных элементов ломается смысл, то такой список называется упорядоченным.

Отображение списка в несколько строк предназначено для более удобного и наглядного восприятия. Для списка слегка меняются правила орфографии и пунктуации, но не на столько кардинально. Знаки препинания должны ставиться так, как-будто бы этот список написан в предложении в одну строчку:

Отступ от левого края текстового блока до маркера лучше всего задать немного большим, чем высота строки. Отступ от маркера до текста в списке можно оставить по-умолчанию, а можно слегка увеличить.

Упорядоченный список больше подходит для текста технической направленности. Но можно и художественный текст представить в виде упорядоченного списка, только придётся его привести к более строгому виду.

XHTML 1.0 запрещает использование списков внутри абзаца (<p>). На мой взгляд, это является нелогичным. В упомянутых примерах списки относятся к абзацам с началом текста. Если бы список был самостоятельной логической единицей текста, то его логично отделять от абзацев. Но он может быть также продолжением предложения. Для обозначения визуального отношения списка к абзацу следует использовать отрицательные отступы сверху, чтобы убрать лишний отступ от абзаца.

Следует подумать и решить, какой из списков будет чаще использоваться. Самостоятельный или как продолжение предложения? В результате мозгоштурма у вас в CSS-файле появится один из классов: standalone или relative (можно назвать и по-другому, не возбраняется). Соответственно, если элемент <ul> будет использоваться для списков относящихся к предложению, то для класса standalone следует убрать сверху отрицательный отступ. Или наоборот.

Заметьте, отступы мы поставили одинаковые, что сверху, что снизу, а визуально список чуть ближе к нижнему абзацу. Всё из-за того, что маркеры списков вертикально центрированы по строчным буквам. Кроме того, близость к следующему абзацу добавляет подчёркивание, если в списке присутствуют ссылки. Исправить ситуацию можно добавив снизу расстояние в два—три пикселя.

С упорядоченными списками дело обстоит лучше, поскольку в качестве маркеров используются цифры, высота которых, как правило, равна высоте прописной буквы.

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

Казалось бы, какие мелочи! А эти мелочи, всё равно чувствуются. В ряде однотипных элементов сдвиньте один из них хоть на пиксель — пользователь может и не увидит, но почувствует дискомфорт. Человеческий глаз на много чувствительней, чем вы думаете. Небольшой дисбаланс в общем ровном ряду элементов раздражает глаз и заставляет обращать на него внимание. В большинстве случаев, это выглядит не как контраст, а как небрежность.

Пример вёрстки упомянутых в статье элементов

Продолжение: Вложенные списки, графические маркеры

]]> http://seleckis.lv/journal/web-dizayn/dizayn-teksta-3-spiski/feed 13 Дизайн текста 2: Цитаты http://seleckis.lv/journal/web-dizayn/dizayn-teksta-2-tsitatyi http://seleckis.lv/journal/web-dizayn/dizayn-teksta-2-tsitatyi#comments Wed, 19 Mar 2008 23:31:07 +0000 Никита http://www.seleckis.lv/journal/web-dizayn/dizayn-teksta-2-tsitatyi Продолжение темы «Дизайн текста».

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

Цитаты

Существует три вида элементов, отвечающих за размещение цитат на веб-странице:

  • <blockquote> — блок цитаты. Блочный элемент, как правило используемый для публикации большого объёма цитируемого текста;
  • <cite> — источник цитаты;
  • <q> — короткая цитата.

В основном используют только <blockquote> для вывода целого блока цитируемого текста. Источник этой большой или короткой строчной (<q>) цитаты если и указывают, то только не в элементе <cite>. Может по незнанию, может по непониманию. Но не используют. А зря.

Элементы <q> и <cite> не такие сложные в понимании и использовании, чтобы их не любить. А какой оригинальный внешний вид можно порой им придать! Опять же если бы все веб-разработчики соблюдали стандарты семантической вёрстки, гораздо проще можно было бы настраивать поиск по этим элементам.

Блок цитаты традиционно отображается со втяжкой, источник цитаты — курсивом, а элемент <q> помещает текст в кавычки, которые на самом деле не правильные типографские кавычки, а «программистские». Поэтому нужно не забывать прописывать нечто подобное:

/* для русского и латышского языка */
q:before { content: "«" }	q:after  { content: "»" }

q q:before { content: "„" }	q q:after  { content: "“" }
blockquote q:before { content: "„" }	blockquote q:after  { content: "“" } 
/* для английского языка */
q:before { content: "“" }	q:after  { content: "”" }
q q:before { content: "‘" }	q q:after  { content: "’" }
blockquote q:before { content: "‘" }	blockquote q:after  { content: "’" } 

Короткая цитата и блок цитаты выглядят обычным текстом. Оба варианта цитаты уместнее всего выглядели бы написанные курсивом, поскольку цитату можно рассматривать как прямую речь, а прямая речь часто выделяется курсивом имитируя рукописный шрифт.

Источник цитаты, не обязательно должен отображаться курсивом, чаще всего в качестве указания источника используется ссылка. Так вот следует ссылку помещать в элемент <cite> и соответственно форматировать так, чтобы было понятно, что это ссылка. Можно слегка изменить, чтобы источник цитаты как-то отличался от обычной ссылки.

В случае, если источник цитаты не опубликован в интернете, его следует выделить особым способом, например, добавить пунктирное подчёркивание, добавить подсказку (tooltip) с разъяснением, где конкретно взят источник, слегка изменить цвет или даже сделать его жирным, но курсив будет неуместен.

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

Пример вёрстки упомянутых в статье элементов

Продолжение: Списки

]]> http://seleckis.lv/journal/web-dizayn/dizayn-teksta-2-tsitatyi/feed 10 Позиционирование картинок для галереи http://seleckis.lv/journal/css/pozitsionirovanie-kartinok-dlya-galerei http://seleckis.lv/journal/css/pozitsionirovanie-kartinok-dlya-galerei#comments Wed, 30 Jan 2008 10:45:23 +0000 Никита http://www.seleckis.lv/journal/css/pozitsionirovanie-kartinok-dlya-galerei При просмотре тумбнейлов изображений картинки выстраиваются в таблицу с определённым количеством колонок и строк. Если вёрстка решается с помощью таблицы, то приходится программировать на стороне сервера её разметку, а так же добавлять лишние строчки кода для определения количества фотографий на последней странице, и писать скрипт таким образом, чтобы ячейки таблицы не пропадали. Никому не нужная работа.

Решать такие вопросы проще с помощью CSS. Т. е. для разметки картинок для галереи следует использовать предназначенные для этого тэги и размечать их положение и вид с помощью CSS.

Я предлагаю не использовать тэги div с какими-то классами, а предлагаю обратить внимание на списки терминов. Пример из w3schools.com:

Coffee
Black hot drink
Milk
White cold drink

реализуется такой список таким образом:



Coffee


Black hot drink


Milk


White cold drink

Где dl — список терминов, dt — термин, dd — описание термина.

В случае с картинками для галереи предлагаю рассматривать картинку как термин, а описание картинки, как описание термина. Правильней всего было бы разметить так:



myimage1


Image 1


myimage2


Image 2


myimage3


Image 3

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





myimage1


Image 1






myimage2


Image 2






myimage3


Image 3

Теперь каждая картинка и её описание в своём контейнере. Здесь семантику можно оправдать: картинку и её описание, можем назвать списком не зависящим от других списков. Высосанное из пальца оправдание, ну да ладно…

CSS

Теперь, необходимо написать CSS. Причём задача следующая:

  1. Картинки должны быть центрированы в блоке фиксированного размера, причём картинки могут быть как портретные, так и ландшафтные;
  2. Размер внешнего блока для картинки и её описания, тоже должен быть фиксированный, поскольку описания могут быть многострочными;
  3. Высота внешнего блока должна быть фиксирована, чтобы в зависимости от количества строк в описании, не возникал разнобой в высоте блоков;
  4. Valid XHTML 1.0 Strict, valid CSS2, no JavaScript

Прокомментирую первую и самую главную задачу.

Центрирование по горизонтали и вертикали в таблицах в HTML4 решается просто: align=”center” valign=”absmiddle”. В CSS вёрстке это больной воспрос. Если с горизонтальным позиционированием всё понятно, то с вертикальным — проблемы, и проблемы конечно же только в IE. Если в нормальных браузерах, всего-то надо содержащему блоку добавить свойство display: table-cell и vertical-align: middle, то в IE такой способ не работает. Я предлагаю необычно «тупое», но эффективное решение — установить размер шрифта в блоке с картинкой равным 89% от высоты блока (например, если высота блока 150px, то размер шрифта должен быть 133.5px), а картинке задать vertical-align: middle;, т. е. позиционируем картинку по центру относительно высоты шрифта. Данный способ работает только для картинок, для блоков с контентом он не работает (для этого есть другие способы).

Привожу код с комментариями:

.imagelist * {
	margin: 0; padding: 0; /* если не применяется обнуление дефолных настроек браузера */
}
.imagelist dl{
	float: left; /* чтобы картинки шли друг за другом вряд */
	/* красота, размеры, отступы */
	border: 1px solid #CCC;
	background-color: #EEE;
	width: 210px;
	height: 250px;
	padding-left: 9px; /* из-за использования границ (borders) — 9, а не 10 */
	padding-top: 9px;
	margin-right: 20px;
	margin-bottom: 20px;
}
.imagelist dl dt{
	text-align: center; /* поскольку тэг img является строчным,
					то позиционируем его по центру таким способом */
	display: table-cell; /* вертикальное позиционирование */
	vertical-align: middle; /* для нормальных браузеров */
	font-size: 178px; /* 178px = 200 * 89%, то о чём я говорил выше (для IE) */
	line-height: 0px; /* чтобы не было лишних отступов, потому как line-height
				пропорционально увеличивается относительно размера шрифта */
	/* красота, размеры, отступы */
	background-color: white;
	border: 1px solid #DDD;
	width: 200px;
	height: 200px;
}
.imagelist dl dt img{
	vertical-align: middle; /* позиционирование картинки по вертикали  (для IE) */
}
.imagelist dl dd{
	text-align: center;
}

И ещё добавим небольшой код исправления для IE6 и ниже, которые ширину блока считают внешней а не внутренней, поэтому ширина блока не складывается с внутренним отступом (padding).

Вот что в итоге должно получиться:

Смотрите, качайте, пользуйтесь!

P.S. Число 89% получено опытным путём.

]]> http://seleckis.lv/journal/css/pozitsionirovanie-kartinok-dlya-galerei/feed 34 Почему лучше сначала изучить XHTML? http://seleckis.lv/journal/xhtml/pochemu-luchshe-snachala-izuchit-xhtml http://seleckis.lv/journal/xhtml/pochemu-luchshe-snachala-izuchit-xhtml#comments Sat, 12 Jan 2008 21:14:31 +0000 Никита http://www.seleckis.lv/journal/xhtml/pochemu-luchshe-snachala-izuchit-xhtml Уже почти два года на своих курсах я преподаю именно XHTML, причём 1.0 Strict. Почему?

На мой взгляд, нужно начинать обучение с языка разметки, который содержит правила, порой параноидального характера (как, например, disabled=”disabled”). Жёсткие правила вёрстки, как дисциплинируют процесс создания станицы, так и систематизируют сами правила, что способствует более удобному их изучению.

Итак, рассмотрим плюсы и минусы вёрстки XHTML 1.0 и сравним её с вёрсткой в HTML 4.01. Для начала вспомним, чем отличается XHTML от HTML:

  • Общий вид XHTML документа должен состоять из:
    • декларации типа документа (DOCTYPE);
    • тэга <html>, который является корневым и уникальным;
    • тэг <html> должен содержать атрибут xmlns с указанием URI адреса описания пространства имён XHTML;
    • тэг <html> должен содержать только два элемента — <head> и <body>, причём, <body> пишется после <head>;
    • тэг <head> должен содержать элемент <title> с заглавием документа.

    Пример правильного XHTML документа:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <title>Заглавие документа</title>
    </head>
    <body>
    </body>
    </html>
    Примечание:
    Иногда XHTML-документ может иметь декларацию XML перед декларацией DOCTYPE.
    <?xml version="1.0" encoding="UTF-8"?>
    Иногда элемент <html> может иметь атрибуты lang и xml:lang с указанием языка содержимого документа:
    <html xmlns="http://www.w3.org/1999/xhtml" lang="ru" xml:lang="ru">

  • Элементы должны быть с правильным вложением.
    HTML допускает:
    <b><i>Этот текст жирный и наклонный</b></i>
    XHTML допускает только:
    <b><i>Этот текст жирный и наклонный</i></b>
  • Элементы должны быть всегда закрыты.
    HTML допускает:
    <p>Первый абзац
    <p>Второй абзац
    XHTML допускает только:
    <p>Первый абзац</p>
    <p>Второй абзац</p>
  • Пустые элементы тоже должны быть закрыты.
    HTML допускает:
    Перенос строки<br>
    Следующая строка, а после неё — горизонтальная линия<hr>
    Ну, и конечно же, картинка <img src="image.gif" alt="Картинка">.
    XHTML допускает только:
    Перенос строки<br />
    Следующая строка, а после неё — горизонтальная линия<hr />
    Ну, и конечно же, картинка <img src="image.gif" alt="Картинка" />.
  • Элементы и атрибуты должны писаться строчными буквами.
    HTML допускает:
    <BODY>
    <P CLASS="my_paragraph">Абзац на блоге seleckis.lv</P>
    </BODY>
    XHTML допускает только:
    <body>
    <p class="my_paragraph">Абзац на блоге seleckis.lv</p>
    </body>
  • Значения атрибутов обязательно должны заключаться в кавычки.
    HTML допускает:
    <table width=100%>
    XHTML допускает только:
    <table width="100%">
  • Атрибуты-флаги (сокращённые атрибуты с одним возможным значением) должны писаться как обыкновенные атрибуты.
    HTML допускает:
    <option selected>Выбранный элемент в выпадающем списке</option>
    XHTML допускает только:
    <option selected="selected">Выбранный элемент в выпадающем списке</option>
  • В элементах <a>, <frame>, <img> и <map> атрибут name заменён на id.
    HTML допускает:
    <img src="image.gif" alt="Картинка" name="pic1">
    XHTML допускает только:
    <img src="image.gif" alt="Картинка" id="pic1" />
  • Атрибут lang должен дублироваться с префиксом xml:
    <div lang="lv" xml:lang="lv">Esat sveicināti!</div>

Плюсы

  1. Все тэги закрыты. Не будет путаницы с парными и одинарными тэгами.
  2. Все тэги правильно вложены. Не будет путаницы с вложением — очевидный плюс.
    Но он же и минус. В HTML можно было удобно вывернуться:
    <b>Жирный текст <i> жирный и наклонный текст</b> только наклонный текст</i>.
    В XHTML нужно писать строго, потому и чуть больше:
    <b>Жирный текст <i> жирный и наклонный текст</i></b> <i>только наклонный текст</i>.
  3. Отказ от name в пользу id считаю правильным, поскольку
    1. id короче,
    2. name имеет своё особое значение в формах
  4. Логично, что если значение атрибута содержит пробел, то оно должно писаться в кавычках. Но будет проще взять за правило и всегда писать значения атрибутов в кавычках, чтобы опять-таки не было путаницы когда их писать, а когда нет.
  5. Писать прописными буквами элементы, атрибуты и значения атрибутов, считаю таким же дурным тоном, как писать прописными буквами в чатах, на форумах и письмах, поэтому абсолютно солидарен с W3C по этому поводу.

Минусы

  1. Неудобный DOCTYPE. Я бы предпочёл параметры документа писать в элементе <html>, а адрес описания namespace объединить с адресом DOCTYPE. Да и адреса бы попроще сделать. Я бы предпочёл писать всё в тэге html и без всяких деклараций:
    <html xmlns="http://w3.org/dtd/xhtml" type="text/xhtml-strict" version="1.0" lang="ru">
  2. Зачем дублировать атрибут lang с префиксом xml: — не понятно.
  3. Атрибуты checked, readonly, disabled, selected, multiple по сути возвращают значение true или false. Так, почему же так не писать? Например:
    <option selected="true">Выбранный элемент выпадающего списка</option>
    По-умолчанию, эти атрибуты имеют значение false, поэтому можно их не писать, если не нужно обратное.
    Могу предложить другой вариант: придумать для этих значений отдельный атрибут, например — view или flag:
    <input type="text" view="disabled" />
    Если нужно написать два значения, пишем через пробел (как классы):
    <input type="checkbox" view="checked disabled" />

К сожалению к моим «брызгам разума» никто из W3C не прислушается.

А какие плюсы и минусы вы находите в xhtml?

]]> http://seleckis.lv/journal/xhtml/pochemu-luchshe-snachala-izuchit-xhtml/feed 26 Silverlight и XML (XAML), как объектная модель приложения http://seleckis.lv/journal/cms/silverlight-i-xml-xaml-kak-ob-ektnaya-model-prilozheniya http://seleckis.lv/journal/cms/silverlight-i-xml-xaml-kak-ob-ektnaya-model-prilozheniya#comments Sun, 06 Jan 2008 10:52:01 +0000 Никита http://www.seleckis.lv/journal/texnologii/silverlight-i-xml-xaml-kak-ob-ektnaya-model-prilozheniya В прошлом году был на презентационной лекции Microsoft. Тема презентации была связана с новыми продуктами и технологиями этой компании, а точнее с Software + Service и Silverlight. На первое я опоздал, поэтому ничего сказать не могу. А второе было весьма интересно.

Зацепило

О Silverlight 1.0 говорить нечего. Тот же Flash, только элементы в приложении описаны с помощью XAML, что позволяет индексировать содержимое, и не имеет своего скрипта, а использует JavaScript. Зная, как IE обрабатывает JS можем предположить, на сколько может быть популярной эта версия.

Логично, что MS не стали оптимизировать обработку JS в своём браузере, а пошли другим путём. А точнее…

Silverlight 1.1

Эта версия может иметь программную составляющую написанную на любом .NET или web-языке (С#, Visual Basic, PHP, Ruby и др.). Т.е. получив доступ к элементам в приложении через описание XAML, можно забыть про JavaScript и писать на своём любимом языке. Потом это каким-то образом экспортируется в свой формат исполняемый маленьким фреймворком установленным на компьютере пользователя вместе с Silverlight-плагином для браузера. Я не буду вдаваться в подробности, о том как это всё работает, меня это не интересует.

Лектор озвучил плюсы:

  • Очень маленький размер файла плагина
  • Быстрая обработка видео
  • Быстрая обработка скрипта

Я не буду искать опровержений или подтверждений данным высказываниям. Скажу лишь, что для создания аналоговых часов, лектор скопировал около 200 строчек C# кода, и ещё около 100 XAML кода. Многовато что-то…

XML based structure

Так, всё-таки что же меня зацепило? А сам принцип. С принципом описания структуры элементов в XML языке и управления им через скрипт я столкнулся в TYPO3 в плагине TemplaVoila!. Плагин позволяет взять HTML шаблон, отметить на нём «горячие» тэги, дать им соответствующие уникальные имена для того, чтобы можно было ими управлять (помещать контент, настраивать внешний вид) в TypoScript.

К примеру:

  • Отметим на сайте какой-то тэг, например <div id=”sidebar”>…</div>.
  • Дадим ему уникальное имя: lib.sidebar (lib —глобальный объект содержащий внутренние объекты на странице).
  • В XML структуре запишется (причём самому ничего не надо писать): 
    
	

		Just place some content in sidebar
		
			[ ### Sidebar goes here ### ]
		
		TypoScriptObject
		div:inner
		lib.sidebar
  • А в TypoScript можем описать, какого типа это будет объект и что же он должен содержать:
    lib.sidebar = TEXT
    lib.sidebar .value = Hello, world!

Наверное, я мало изучал различные технологии, и не знаю, что такой способ описания объектной модели приложения используется давно, но ведь как, чёрт возьми, правильно.

]]> http://seleckis.lv/journal/cms/silverlight-i-xml-xaml-kak-ob-ektnaya-model-prilozheniya/feed 4 XHTML 1.1 невалидный код в официальном примере http://seleckis.lv/journal/xhtml/xhtml-1-1-nevalidnyiy-kod-v-ofitsialnom-primere http://seleckis.lv/journal/xhtml/xhtml-1-1-nevalidnyiy-kod-v-ofitsialnom-primere#comments Thu, 11 Oct 2007 21:12:29 +0000 Никита http://www.seleckis.lv/xhtml/xhtml-1-1-nevalidnyiy-kod-v-ofitsialnom-primere В официальном описании определения XHTML 1.1 есть такой пример структуры документа:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd"
xml:lang="en" >
<head>
<title>Virtual Library</title>
</head>
<body>
<p>Moved to <a href="http://example.org/">example.org</a>.</p>
</body>
</html>

Сохранив в файл index.xhtml, я решил проверить его на валидность онлайновым валидатором от W3C.

Т. е. валидатор забраковал xsi:schemaLocation=”http://www.w3.org/MarkUp/SCHEMA/xhtml11.xsd”

Если я убераю атрибут xsi:schemaLocation, то меня поздравляют с валидным кодом.

Спрашивается, как правильно? Так как написано в спецификации или как требует валидатор?

P. S. Завтра улетаю на BlogCamp, вернусь в воскресенье. Если успею, то в понедельник напишу отчёт о поездке в Киев и конференции.

]]> http://seleckis.lv/journal/xhtml/xhtml-1-1-nevalidnyiy-kod-v-ofitsialnom-primere/feed 3