5 сентября 2010 в 14:05

HTML5 для веб-дизайнеров. Часть 2: Модель HTML5 перевод

HTML5 для веб-дизайнеров

  1. Краткая история языка разметки
  2. Модель HTML5
  3. Мультимедиа
  4. Формы 2.0
  5. Семантика
  6. HTML5 и современные условия


Великая Французская революция была временем радикальных политических и социальных преобразований. Времени как такового они тоже коснулись: в определенный период своего существования Французская Республика жила по новой системе — в сутках было 10 часов по сто минут каждый. Очевидно, что она была была куда логичнее и «правильнее» привычной шестидесятеричной.

Вместе с тем, она была полным провалом. Никто ей не пользовался.

То же самое можно сказать и про XHTML 2. W3C только лишний раз доказал то, чему нас научил урок послереволюционной Франции: изменить привычки людей по приказу очень-очень трудно.


Принципы модели


Поставив себе целью избежать ошибок прошлого, WHATWG в первую очередь определила набор принципов, которым должен следовать процесс работы над HTML5. Один из ключевых: «Поддерживать то, что уже существует». Это еще одна причина почему для HTML5 нет четкой даты вступления в действие.

Тогда как XHTML 2 намеревался забить на все, что было до него, и начать по-новой, HTML5 — это надстойка для существующих спецификаций. В нем сохранилось и поддеживается многое из HTML 4.01.

Некоторые из других принципов: «Не изобретать велосипед» и «Мостить натоптанные тропы». Последний означает, что если среди веб-дизайнеров есть какой-то широко распространенный и популярный способ решать определенную проблему или задачу — даже если он не самый лучший — его следует принять во внимание и добавить в спецификацию. Можно еще сказать: «Не чинить то, что не сломано».

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

Эта философия сформулирована в принципе о «Порядке важности составляющих», который гласит: «В решении какого-либо конфликта нужно думать в первую очередь о пользователях, потом о кодерах, потом о реализаторах, потом об авторах спецификаций, потом уже о теоретической чистоте и „правильности“».

Ян Хиксон много раз обращал внимание на то, что разработчики браузеров («реализаторы») могут сильно влиять на что попадает в HTML5, а что нет. Если какой-то браузер отказывается включать поддержку определенной возможности, нет смысла добавлять ее в спецификацию, иначе та просто не будет связана с реальностью. В этом плане, согласно порядку важности составляющих, мы, веб-дизайнеры, имеем еще больше влияния. Если мы сочтем часть спецификации ненужной или неправильной и не будем ее использовать, она точно так же перестанет быть связаной с реальностью и потребует пересмотра.

Без крайностей


Разработка HTML5 сопряжена с постоянным внутренним напряжением и противоречием. С одной стороны, спецификация должна быть достаточно функциональной и мощной, чтобы стать надежной платформой для создания веб-приложений. С другой стороны, HTML5 должен быть способен поддерживать уже существующее содержимое сети, даже если там по нынешним сплошной беспорядок и месиво в коде. Если спецификация отклонится слишком сильно в одно направление, ее ждет судьба XHTML2. Если в другое — краеугольным камнем снова станут тег <font> и таблицы как средство разметки, ведь с их помощью, в конце концов, построено огромное количество существующих веб-страниц.

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

Обработка ошибок


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

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

Решение ввести стандарты для этой процедуры в HTML5 очень амбициозно. Даже если бы набор тегов и атрибутов в этой версии ничем не отличался от того, что в HTML 4.01, разработка одного только единого свода правил обработки ошибок к 2012-ому году была бы все равно что сизифов труд.

Эти правила, впрочем, будут малоинтересны веб-дизайнерам (ведь мы все пишем валидный, грамотно структурированный код, верно?), но они чрезвычайно важны для разработчиков браузеров. Тогда как все прошлые спецификации писались только для кодеров, HTML5 написан для кодеров и реализаторов. Имейте это в виду, если решите ознакомиться с ней непосредственно, — это объясняет, почему она такая безразмерно большая и включает такое количество подробностей и нюансов, что скорее походит на заметки какого-нибудь трейнспоттера, увлекающегося пересчетом содержимого личной коллекции марок во время сеанса одновременной игры в шахматы с тремя противниками.

Выкладывай, Док(тайп)


Доктайп (doctype, Document Type Declaration) — традиционный способ указывать тип языка разметки, который используется на данной странице.

Так выглядит доктайп для HTML 4.01:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3c.org/TR/html4/strict.dtd">


Так — для XHTML 1.0:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict //EN" "http://www.w3c.org/TR/xthml1/DTD/xhtml1-strict.dtd">


Совершенно нечитаемо для человека, но, как ни крути, эдакий способ по-своему сказать просто «Эта страница написана на HTML 4.01» или «Эта страница написана на XHTML 1.0».

Можно предположить, что для HTML5 должно быть что-нибудь подобное с цифрой пять воткнутой где-нибудь. Как ни странно, нет:

<!DOCTYPE html>


Наконец-то это можно будет выучить наизусть.

Но, блин, как это так? Тут не указан номер версии, как же мы будем обозначать последующие инкарнации HTML? Когда я впервые увидел этот новый вид доктайпа, я подумал «Что за блажь, они действительно хотят этим сказать, что это финальная версия языка разметки, после которой уже ничего никогда не будет нужно?»

На самом деле, идея проста и очень прагматична. Задача HTML5 — поддерживать существующие HTML 4.01 и XHTML 1.0 страницы, и этого доктайпа им хватит. Новые версии HTML, в свою очередь, должны будут поддерживать HTML5, оттого включать в него постоянно порядковый номер совершенно бессмысленно.

А вообще, и доктайпы сами по себе то и не так важны. Скажем, написали вы страницу с доктайпом от HTML 4.01, а потом взяли и добавили туда элементов из другой спецификации — пусть HTML 3.2, пусть HTML5, не суть. Браузер все равно никуда не денется и обработает их как умеет. Браузеры поддерживают элементы и фичи, а не доктайпы.

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

Так что единственная цель доктайпа для HTML5 — убедиться, что браузер будет обрабатывать следующий после него код, следуя стандарту. Но для валидации его наличие или отсутствие значения не имеет.

Незачем усложнять


В HTML5 упростили не только доктайп.

Если вы хотите обозначит кодировку для своей страницы, лучший способ это сделать — убедиться, что сервер отдает корректное значение в Content-Type. Чтобы быть совсем уверенным, можно воспользоваться тегом <meta>. Так это было раньше:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">


Так это в HTML5:

<meta charset="UTF-8">


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

Тегу <script> тоже вполне можно разрешить похудет. Часто в него добавляют параметр type со значением text/javascript:

<script type="text/javascript" src="file.js"></script>


Браузерам это не нужно. Они и так поймут, что код написан на JavaScript — самом популярном языке скриптов в сети (да что скрывать: единственном языке скриптов):

<script src="file.js"></script>


Точно так же нет смысла в параметре type со значением text/css, когда вы прикрепляете таблицу стилей. Можно просто написать:

<link rel="stylesheet" href="file.css">


Синтаксис: делай как привык


Некоторые языки программирования, например Python, очень требовательны к оформлению кода: даже использование пробелов в определенных ситуациях обязательно для соблюдения правил. Другие языки, скажем JavaScript, на форматирование внимания не обращают — та же отбивка начала строки пробелами никак не повлияет на код.

Если хотите разжечь лютый холивар и таким образом организовать себе веселую программу на вечер — заполните комнату программистами и произнесите слова «важны ли в коде пробелы». Не забудьте поп-корн.

Этот вопрос лежит в корне глубокой философской дилеммы: должен ли язык заставлять следовать определенному стилю оформления кода, или же можно позволить кодерам самим решать, как они его пишут?

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

До XHTML 1.0 не имело значения, пишете вы названия тегов в верхнем или нижнем регистре. Не имело значения, в кавычках ли были значения параметров или нет. Для многих элементов не важно даже было, добавили ли вы закрывающий тег или нет.

XHTML 1.0 придерживается синтаксиса XML: теги всегда в нижнем регистре, значения параметров только в кавычках, все контейнерные элементы обязательно закрываются. И одиночные тоже — перед закрывающей скобкой должен стоять слеш (<br> → <br />).

В HTML5 вы решаете сами: верхний регистр — нижний, кавычки — без кавычек, закрывающийся или нет. Как вам больше нравится.

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

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

Лично я спокойно отношусь к такой свободе выбора в HTML5, так как уже привык самостоятельно следить за стилем кода, который пишу. Было бы здорово, впрочем, иметь для этого языка такого рода инструмент, который в мире программирования зовется «lint-tool», — программу, анализирующую разметку и указывающую на распространенные и потенциально «опасные» практики оформления кода, а также непоследовательности в стиле его написания. Это несколько отличается от валидатора, который проверят код, отталкиваясь только от доктайпа. Первый, кто сможет разработать сервис, совмещающий в себе и то и другое, определенно заслужит честь и уважение со стороны мирового сообщества веб-дизайнеров.

Мы здесь так не говорим


В прошлых версиях HTML, как только определенный элемент или параметр исключался из спецификации, он проходил через процесс «изъятия». Веб-дизайнерам рекомендовалось прекратить использовать изъятые элементы, не посылать им открытки по прадникам и вообще не упоминать их в приличной компании.

В HTML5 нет изъятых элементов или параметров, вместо них только устаревшие.

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

Так как HTML5 поставил себе задачу быть обратно-совместимым с предыдущими версиями, спецификация должно признавать ранее использовавшиеся элементы, даже если HTML5 их больше не включает. Это приводит к несколько неоднозначной ситуации, когда спецификация одновременно говорит «кодеры, не используйте эти элементы» и «браузеры, вот как эти элементы нужно рендерить …». Если бы какой-то элемент был изъят, он бы не упоминался в спецификации вообще. Но так как он просто признан устаревшим, он включен туда для браузеров.

Если вы только не занимаетесь разработкой собственного браузера, для вас нет разницы между изъятыми и устаревшими элементами — вы просто их не используете и не приглашаете в гости.

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

Разлука будет без печали

Признаны устаревшими теги: frame, frameset и noframes. По ним скучать не будут.

Устаревшим является тег acronym, что наконец-то положит конец длившимся годы холиварам и спорам. Не стоит его оплакивать, просто используйте тег abbr вместо него. И, да, я знаю разницу между аббревитурой и акронимом: акронимы — это аббревиатуры, которые произносятся целиком, как слово, а не по буквам (например, НАТО). Не каждая аббревиатура — акроним, но каждый акроним — аббревиатура, потому здесь достаточно одного тега.

Оформляющие элементы font, big и center тоже устарели, и, на самом деле, это случилось давно — еще с приходом CSS, где аналогичные эффекты можно назначать быстрее и легче. По тем же причинам, с нами больше нет параметров bgcolor, cellspasing, cellpadding и valign. Вместо них пользуйтесь CSS.

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

Подмены понятий


Элемент big устарел, но вот small — нет. Такая непоследовательность оправдывается за счет того, что значение последнего было пересмотрено. Это теперь не физическое «сделать текст мельче», а семантический «мелкий шрифт». Ну, вы поняли, — условия пользования, сноски для «звездочек» и так далее.

Понятное дело, что в 9 случаях из 10 этот «мелкий шрифт» будет действительно набран мелко; смысл в том, что роль элемента теперь более смысловая, чем оформительская.

Элемент b раньше означал просто «полужирный текст». Теперь это — «текст, стилистически выделенный из основного потока, но не несущий дополнительной смысловой значимости». Когда смысловая значимость таки присутствует, скорее подойдет strong.

Так же, элемент i теперь не означает «курсивный». Это — «произнесенный другой интонаций или с другим настроением». Опять же, без особого значения или ударения. Для того, что подчеркнуть значимость, используйте элемент em.

Эти изменения могут звучать как просто игра словами. Так и есть. Но за этим стоит конкретная задача — обеспечить независимость HTML5 от устройств, на которых он обрабатывается. Когда вы говорите «полужирный» или «курсив», эти понятия имеют смысл только в визуальном плане — когда текст выводится на экран или бумагу. Но необходимо также думать об устройствах, отображающих информацию в невизуальном формате, — например, предназначенных для чтения с экрана в помощь незрячим. Плюс, описанные изменения в определениях побуждают к лучшему понимаю и применению правил семантики, а не только визуального оформления.

…конец цитаты

Значение элемента cite тоже было слегка изменено. Если раньше он означал «ссылка на источник», то теперь это — «заголовок источника». Очень часто при цитировании источником будет как раз заголовок книги, фильма или чего угодно, на что мы ссылаемся. Однако точно так же это может быть и имя человека. В HTML5, при этом, использовать личные имена внутри элемента cite противоречит спецификации.

Объясняется это так: браузеры делают содержимое тега <cite> курсивным. Заголовки работ обычно выделяются курсивом. Имена людей курсивом не выделяются. Поэтому элемент cite не должен применяться для ссылки на конкретного человека.

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

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

<a> на стероидах

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

Без сомнения, элемент a — самый важный во всем HTML. Это он превращает текст в гипертекст и делает возможным существование всемирной сети как таковой.

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

<h2><a href="/about">Обо мне</a></h2>
<p><a href="/about">Узнайте, чем я живу</a></p>

В HTML5 эти несколько элементов можно завернуть в один тег <a>:

<a href="/about">
	<h2>Обо мне</h2>
	<p>Узнайте, чем я живу</p>
</a>

Единственное ограничение: нельзя запихать внутрь <a> еще один <a>.

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

Новые игрушки: API для JavaScript


Если вам нужна документация по стилям, вы идете и читаете спецификацию для CSS. Если вам нужна документация по разметке, вы берете HTML-спецификацию. Но куда идти, если вам нужно узнать об API дя JS, таких как document.write, innerHTML и window.history? Спецификация для JavaScript посвящена программированию, вы не найдете там никаких из API браузеров.

До настоящего момента, браузеры разрабатывали свои API для JS самостоятельно, иногда поглядывая друг другу через плечо, чтобы узнать, как там делают конкуренты. HTML5 наконец-то задокументирует эти API и установит общий стандарт.

Может показаться странным, что спецификация языка разметки будет включать в себя документацию по JavaScript, но не стоит забыть, что HTML5 начинался с проекта Web Apps 1.0, а JS — неотъемлемый компонент веб-приложений.

Целые разделы спецификации посвящены новым API, предназначенным для разработки оных. UndoManager позволяет следить за чередой изменений в документе. Есть раздел, затрагивающий работу с веб-приложениями в оффлайне, используя cache manifest. Drag-n-Drop тоже подробно описан.

Как всегда, если где-то есть уже существующие реализации, спецификация скорее основывается на них, нежели чем переизобретает велосипед. Например, API для drag-n-drop в Internet Explorer существовал уже долгое время и послужил основной для того, что включено в HTML5. Стоит, впрочем, заметить, что Майкрософтские API, мягко говоря, довольно проблемны, и иногда переизобретение велосипеда может быть оправдано, особенно если все, что вы имеете, — велосипед с квадратными колесами, без седла и половиной руля.

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

Тем временем, у нас полно увлекательнейших вещей в непосредственно HTML5. И восторг по их поводу начинается уже со следующей главы.
Автор оригинала: Jeremy Keith
Arnold Sakhnov @Olhado
карма
126,0
рейтинг 0,0
iOS
Похожие публикации
Самое читаемое Разработка

Комментарии (57)

  • +5
    Радует то, что доктайп уменьшили до 15
    • +1
      до 15 символов*
      А так же, API для Javascript
      • +3
        Да вообще радует что многое сократили по длине, доктайп моя большая проблема ) ни как не могу выучить его )
        • +14
          Думаю, что его никто и не пытался учить ;) Всегда копипаст…
          • НЛО прилетело и опубликовало эту надпись здесь
            • –7
              честно — ни когда не пользовался каким то софтом для разметки, всегда все руками писал… ну само собой копипаст — сила
              • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    да что скрывать: единственном языке скриптов
    А VBscript куда делся?
    • +1
      по моим субъективным ощущениям, вбскрипт в хтмл — это большая редкость.

      вывод: с таких случаях нужно указывать название языка.
      • 0
        Редкость, но JS — не единственный язык. Я указываю на неточность в статье.
        • +5
          Это не неточность: именно факт, что, пусть другие языки и существуют, они фактически не используются (или, по крайней мере, процент их применяемости непоставим с JS), и подразумевался в этой фразе.
          • +2
            Они, конечно же, используются.

            Эта фраза понимается однозначно: что кроме JS других языков не существует.
            • 0
              Это уже к автору, фраза изначально его.
            • 0
              Если смотреть контекст, то можно понять, что автор утрировал.
        • 0
          иногда бывают и другие, например text/ruby, но тем не менее придираться к статье нету смысла — все поняли.
    • +2
      Ушел в тень истории.
    • 0
      VBscript уже где то кроме IE работает?
    • 0
      Разве VBscript поддерживается чем то кроме IE?
      • 0
        упс… не заметил предыдущего комент а:)
  • +3
    странно звучит подзаголовок «Бери это проще». видимо, перевод выражения «Take it easy», означающий «расслабься» или, в данном случае, «будь проще»)
    • –3
      В оригинале по-другому. Перевод такой сделан намеренно — влияние сленга определенных кругов. Just never mind.
      • +3
        Как бы то ни было, по-русски так не говорят.
        • +2
          Справедливо. Переписал.
    • 0
      Кажется, адекватным будет перевод «не заморачивайся».
  • –9
    Спасибо за статью. Если бы мог, поставил бы вам плюсиков.
  • –14
    Толково, возьмем на заметку. Жаль в карму плюсовать не могу…
    • –5
      Хабралюди конечно прекрасный народ, с обострённым чувством минуса в карму, не устаю удивляться.
  • 0
    Меня одного смущает, что веб-дизайнеру приписывают функции программиста и верстальщика? Веб-дизайнер, безусловно, должен следить за новыми возможностями и «фичами», но знать как, что и где кодить совершенно не обязательно. Это скорее всего дополнительный навык, но класть кодинг на плечи веб-дизайнера вот так по умолчанию не правильно. «Всё в одном» и «и рисую и кодю» скорее вернее для фриланса, и то, это не правило, а конкурентное преимущество.

    Поэтому считаю не правильным в данной статье использовать профессию веб-дизайнер, как полностью связанною с описанном в статье. Логичнее было бы использовать того же программиста или верстальщика.
    • +2
      Из предисловия:

      «[…] this book is for you—you who create web content, who mark up web pages for sense and semantics, and who design accessible interfaces and experiences».

      Функции программиста не приписываются — потому та же тема JS API затронута лишь слегка. А в той среде, для которой книга была написана, «веб-дизайнер» действительно включает в себя и понятие «верстальщик» в какой-то степени. Более того, последнее вообще так явно не выделяется в отдельную должность/профессию/whatever.
    • +1
      давно уже все это обсуждалось. рисовать красиво конечно круто, но рисовать нужно с пониманием того, как это потом будет верстаться. возможности нового html хоть и богаты, но не безграничны. так что знать хотя бы основные принципы верстки web-дизайнер обязан, иначе бедные html-кодеры.
      • 0
        Основываясь на опыте работы нашей студии, вопрос «как я это буду верстать?!?!» зависит от квалифицированности программиста. Да, порой сложно и долго, но очень многое возможно. Очень многое. Обругать дизайнер и просить всё перерисовывать гораздо проще, чем взять и сделать, а если надо то и подучить хтмл.
        • 0
          чувствуется обвинение в мой адрес. я же написал, возможности большие, но не безграничные. грамотный верстальщик сделает, но это по-моему будет лишней тратой ресурсов.
          • 0
            Обвинять я Вас не хотел, но, как я писал выше, было бы неплохо обозначить целевую аудиторию:
            — если это фрилансеры-дизайнеры, то безусловно данный навык полезное конкурентное преимущество и называть их веб-дизайнерами уместно;
            — однако, если мы говорим о профессиональных веб-дизайнерах в студиях, которые работают в команде, то присваивать им обязанности верстальщиков идёт в ущерб процессу работы.

            Вот и всё =)
            • 0
              не обижаюсь :)

              ну если это крупная студия и есть у кого спросить совета, если есть сомнения — согласен. да и на дорисовку всегда передать можно. ну а в другом случае все же нужно владеть хотя бы общими понятиями.
    • 0
      я еще в первой части статьи об этом подумал, но, честно говоря, и так понятно, что дизайн — он не только о рисовании, но и об интерфейсе и о программе в целом.
    • +1
      Это в русском языке «дизайнер» = «рисовальщик» («художник», «оформитель»). Англоязычное значение много шире.
  • +7
    В HTML5 вы решаете сами: верхний регистр — нижний, кавычки — без кавычек, закрывающийся или нет. Как вам больше нравится.

    В упор не понимаю, почему разработчики стандарта так гордятся этим плевком в сторону синтаксиса и семантики.
    • +1
      В упор не понимаю, почему многие дрочат на синтаксис и семантику? Код должен работать. А какие кодинг конвеншнс — это вопрос религии. Мы ведь не рассматриваем обфусцированный код.
      • +1
        Ума не приложу, а почему пиво отпускают литрах, а не в кубических вершках?
        • 0
          В Англии пиво отмеряют одновременно и в литрах и в пинтах и никто не заморачивается.
          Никакого политического смысла мой комментарий не несёт, самому больше нравится в лоу кэйсе. Это просто на тему кубических вершков :)
      • +1
        «Работает и ладно» – дурацкий подход. Если я буду давать переменным имена китайскими иероглифами, хранить картинке в базе в BLOB'ах, а вёрстку и логику запихну в один файл и выполню eval'ом, оно тоже будет работать.
        • 0
          вы извращенец, мсье?)
        • –1
          То, что Вы описали — eval + blob — влияет на производительность сайта, а семантика не влияет. Семантика — все равно что русский текст без заглавных букв, однако все знаки препинания на месте. Трудно вам будет читать такой текст? Поверьте мне, едва-едва сложнее.
          • 0
            То есть, если бы не влияла, то можно, да?
            • 0
              Да, можно.

              Это плохой тон из-за проблем с перформансом и иногда безопасностью, а не имиджевый плохой тон.
              • 0
                Ну не знаю, я такой код читать не хочу, и если кто-то его запретит, я ему буду благодарен.
          • 0
            Единственно кто будет рад таким вольностям — школяры и появится через несколько лет куча г*кода по типу прочитать можно но раздражает ужасно
            • 0
              Поверьте мне, школяры уже сейчас такие школяры, вне зависимости от того, любуется тред-стартер на семантику, или нет.
    • 0
      с одной стороны:
      только попробовав питон, понимаешь, как приятно читать чужой код) после этого на портянки говнокодеров от пхп даже смотреть не хочется (не в том смысле, что пхп — говно, а в смысле, что многие пхп-программисты оформляют код как попало, так уж сложилось исторически).

      с другой стороны:
      хтмл рендерится при помощи тех же питонов, пхп и джаваскриптов и было бы уже сложнее учесть при этом все отступы и пробелы.
      • 0
        Возможно неплохой практикой было бы заставлять веб-сервера отдающие контент выкидывать все пробелы между тегами, как это делается про подписывании xml, а уж нарисовать отступы в html документе браузеры и сами умеют.
  • –4
    Я очень обрадовался, когда увидел в новом релизе Ruby on Rails доктайп HTML5
    • +1
      и чо?
  • +3
    > Но необходимо также думать об устройствах, отображающих информацию в невизуальном формате, — например, предназначенных для чтения с экрана в помощь незрячим.

    > Устаревшим является тег acronym, что наконец-то положит конец длившимся годы холиварам и спорам. Не стоит его оплакивать, просто используйте тег abbr вместо него.

    и каким образом речевой браузер сможет понять, что НАТО надо произносить не по буквам?
  • +3
    Если хотите разжечь лютый холивар и таким образом организовать себе веселую программу на вечер — заполните комнату программистами и произнесите слова «важны ли в коде пробелы». Не забудьте поп-корн.

    Фигня, спорить будут только юнцы, которые никогда не поддерживали чужой код.
  • +1
    «Элемент b раньше означал просто «полужирный текст». Теперь это — «текст, стилистически выделенный из основного потока, но не несущий дополнительной смысловой значимости». Когда смысловая значимость таки присутствует, скорее подойдет strong.»
    Понятно, что автор просто разъясняет смысл тега, но само предложение у меня почему-то чётко ассоциируется с заменой «глупый» → «альтернативно-одарённый», «жирный» → «человек с альтернативным телосложением» (или как там на Западе договорились называть?)…
    • 0
      насколько мне известно, в америце жирных называют «размер плюс» :)
      долбаная «политкорректность»
  • –1
    Дизайнерам информацию нужно предоставлять ВИЗУАЛЬНО

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