Пользователь
0,0
рейтинг
2 декабря 2008 в 11:34

Разработка → Разметка. Transitional vs Strict

Речь в статье пойдет о такой, казалось бы изжеваной и изъезженой теме, как валидация веб-документа по одной из DTD-схем, которые в свою очередь определяются с помощью DOCTYPE.

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

В последнее время, многие редакторы и CMS'ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.

Перед тем как перейти к самой сути вопроса давайте вспомним что такое Transitional схема. Она была создана как переходная, для облегчения перехода от HTML3.2 к HTML4, сохраняя унаследованые элементы и атрибуты.

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

Современная веб-разработка зиждется на трех китах — разметка (html/xhtml/xml), оформление (css) и функционал с эффектами (javascript). Причем акцент здесь приходится на четкое разделение между ними. Разметка является логическим разделением документа на семантические, смысловые составляющие. Стилевые правила, вынесеные в отдельный файл(ы), отвечают за оформление документа относительно устройств отображения. Скрипты, отвечающие за взаимодействие между документом и пользователем, а так же за эффекты, также вынесены в отдельные файлы. Смешение всех этих компонентов в одном документе считается моветоном и заметно усложняет жизнь веб-разработчика и порядочно увеличивает время загрузки и отображения документа браузером.

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

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

А что же собственно делать?



Использовать Strict DTD — строгую, однозначную схему валидации документа, которая как раз создана для того чтобы отделить содержимое от стилей и скриптов. Как это сделать? Очень просто. В следующем вашем проекте просто поменяйте DOCTYPE на один из этих:

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


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


Кстати, W3C однозначно рекомендует использовать Strict.

«This is the HTML 4.01 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.»


Чего вы лишаетесь, переходя на строгую схему валидации:



Список запрещеных элементов: applet, basefont, center, dir, font, iframe, isindex, menu, noframes, s, strike, u

Список запрещеных атрибутов:
  • Атрибут alink запрещен для body
  • Атрибут background запрещен для body
  • Атрибут bgcolor запрещен для body, table, td, th, tr
  • Атрибут border запрещен для img, object, но может быть использован в table
  • Атрибут clear запрещен для br
  • Атрибут language запрещен для script
  • Атрибут link запрещен для body
  • Атрибут name запрещен для form, img, но может быть использован в a, button, input, map, meta, object, param, select, textarea
  • Атрибут noshade запрещен для hr
  • Атрибут nowrap запрещен для td, th
  • Атрибут start запрещен для ol
  • Атрибут target запрещен для a, area, base, form, link
  • Атрибут text запрещен для body
  • Атрибут type запрещен для li, ol, ul, но может быть использован в a, button, input, link, object, param, script, style
  • Атрибут value запрещен для li, но может быть использован в button, input, option, param
  • Атрибут vlink запрещен для body


Структурные изменения: элементы a, abbr, acronym, b, bdo, big, br, button, cite, code, dfn, em, i, img, input, kbd, label, map, object, q, samp, select, small, span, strong, sub, sup, textarea, tt, var и текст не могут быть дочерними для blockquote, body, form, noscript. Другими словами — элементы blockquote, body, form, noscript могут иметь только блочные элементы в дочерних элементах первого уровня.

Отказ от атрибута target="_blank" для ссылок. Во-первых, указывать пользователю на то, как и где открывать ссылку — не красиво. Во-вторых, если необходимо, это можно сделать простым способом и продвинутым.

Что вы приобретаете?


  • Хорошо структурированую разметку
  • Четкое отделение содержимого от оформления
  • Возможность более быстрой и легкой работы и поддержки кода
  • Дисциплину в написании кода
  • Респект и уважуху ;)


Когда стоит использвать Transitional? Тут есть два основных момента. Переходная схема хороша, когда вы работаете с большим количеством чужого кода, поменять который не представляется возможным. Хороший пример — большинство CMS. В большинстве случаев невозможно изменить их код, не залезая в ядро, что автоматически исключает возможность обновлений.

Второй момент — использование iframe. Если вы используете в своих проектах iframe, то он не оставляет вам выбора. Используте Transitional.

Дабы облегчить себе переход от переходной схемы к строгой во время разметки документа думайте о том, для чего нужен тот или иной элемент, а не о том как он будет выглядеть.
Денис @CurlyBrace
карма
170,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • +9
    Отличная статья. Еще бы про отличия w3c стандартов, на русском
  • +2
    Просто спасибо :)
  • +4
    Современная веб-разработка зиждется на трех китах...


    а вот за это описание респект. четко ясно и понятно. часто приходится объяснять, теперь будет проще.
    • +1
      Клиенту чтоли обьяснять? Мне кажется — что ему пофиг, ему важен конечный результат. Хотя если упомятуть, что сайт сделан по стандартам — клиенту это понравится. :)
      • +1
        нет, не клиенту.
        молодым разработчикам, которые пока что мало что знают.
      • +1
        Ну почему сразу заказчику? Можно объяснять младшим кодерам. Ну или студентам на предмете веб-технологий и веб-разработки
  • –1
    Респект вам и уважуха )
  • 0
    А ещё почему-то теряется возможность записать onLoad=«func();» внутри body. Или я в чем-то не прав?
    • –1
      только кавычки такие — "
    • +4
      потому что это необходимо писать в js коде:
      $(«body»).bind(«load», function(){})
      • +1
        Вся проблема в том, что с каждой страницы (в моём случае) надо в функцию отправлять индивидуальный параметр.
        • +1
          Это в принципе можно решить присвоением id для каждой страницы.
        • +1
          вставьте кусок js кода в страницу в тегах <script> или определяйте параметр по каким-либо другим признакам на странице
        • 0
          может стоит добавить этот параметр при формировании html как аттрибут элемента и при регистрации события $(«body»).bind(«load», function(){}) находить его селектором )
      • +1
        Поправьте меня, если я неправ, но по-моему, в данном примере используется jQuery.

        Быть может лучше в этом случае писать так:

        $(function(){...});

        Анонимная функция будет вызвана сразу, как только будет полностью загружено DOM-дерево (но ДО загрузки картинок и прочих элементов)
      • 0
        а без jQuery?
    • 0
      У меня тоже была такая проблема. Но вот в jQuery это как-то обходится. Советую посмотреть исходники, если это вам интерестно.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        хорошая практика переносить обработчики событий в js код%)
  • 0
    Кстати, есть одна интересная статья Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8, хоть она и не про валидацию, но рассказывает о взгляде на doctype как на механизм управления рендерингом в браузерах.
    • +3
      DOCTYPE в контексте X-UA-Compatible — отдельная тема, которая еще надолго не оставит нас безработными ;)
    • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    А что за ошибка валидации?

    <script language=«JavaScript»>
    there is no attribute «LANGUAGE».
    • +8
      обычно пишут <script type=«text/javascript»>
      • –1
        Опередили )
    • +3
      Нет такого атрибута как language. Вот так правильно:

      <script type="text/javascript" src="bla.js"></script>
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Ну я, собственно, в статье об этом написал )
  • +1
    Мне в html 5 больше всего нравится doctype.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Есть еще один плюс в указании полного DOCTYPE. Пытливый верстальщик сможет взять из него адрес DTD-схемы и заглянуть в нее. Много становится понятнее, когда видишь по какому принципу работает валидация.

        А я бы вобще заставлял наизусть схемы заучивать ))
        • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Не согласен. Некоторые вещи IE6 обрабатывает по-разному, в зависимости от доктайпа.
        • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    iframe на самом деле приходится использовать довольно часто — при перекрытии select-ов в ие6.
    он-то конечно дописывается джаваскриптом, но как в таком случае доктайп на него повлияет?
    • 0
      А вы и дописывайте iframe ТОЛЬКО для IE6, карму это не портит :)
      • +1
        дык так и делаю.
      • –1
        Простите убогого. А для остальных какой выход? =/
        • 0
          Для остальных используйте DIV. SELECT только в IE6 (и меньше) «особенный» и просвечивается сквозь вышестоящие блоки.
  • –4
    Статья полезная, но все равно считал и буду считать что Strict это зло, так как верстать и делать динамические кроссбраузерные интерфейсы в тех ограничениях которые он накладывает лишний геморой для разработчика. Тут хотябы идентичной работы во всех браузерах добиться бы а не следить за атрибутами и валидацией.
    • +8
      Предположу, что у производителей автомобилей марки ВАЗ такое же мнение — лишь бы ездила по всем дорогам более-менее одинаково, а остальное — геморой для разработчика.
      • –8
        В каком году был придуман стандарт HTML4? А XHTML?
        Если есть желание работать по устаревшим правилам это ваше право, но стандарты придумывают те кому не хватает той или иной функциональности в браузерах или же тем кому надоело подставлять костыли под разные браузеры. Делаете сайты а-ля www.w3.org/ пожалуйста, но если я хочу от браузера большего и в нем такая возможность есть, хоть и не по стандарту то я ей воспользуюсь.
        • +7
          да! бегущая строка это именно тот функционал которого не хватает!
          извиняюсь за сарказм, но действительно не понимаю что такого есть в браузерах и нет в стандарте что действительно необходимо. пример приведете?
          • 0
            Еще IE 5.5 поддерживал работу с XML, теперь это уже стандарт де факто. в FF есть XUL но конкретного шага в сторону webforms пока нет, хотя в HTML 5 добавляют input-ы типа range,date,email,url. Да и думаю большинство нужных CSS атрибутов -moz появится в CSS3.
          • 0
            iframe? сами же написали ниже :)
            overflow или overflow-x\overflow-y в ie 6 плохо дружит с доктайпами, хотя тут я не уверен.
            • –1
              iframe мне нужен только для того что бы компенсировать несовместимость IE и с другими браузерами :) да и в этом случае ни о каком XHTML Strict речи не идет потому как IE6 его не поддерживает.
              мне всегда хватало overflow: auto; возможно что причина в том что я не верстальщик и занимаюсь этим редко… тут ситуация похожая на target="_blank" имхо.

              А вот связи между XML, XUL, HTML5, CSS и Transitional vs Strict не уловил.
        • +1
          А я так и не понял, чем вам не нравится www.w3.org/. Не объясните?
      • 0
        Стоит заметить, что присутствие или отсутствие стандартов не влияет на качество. Оно вообще мало на что влияет, пожалуй, тока на цвет фавиконки в валидаторе, да и это исправимо :)

        Топорный html это, по сути, тот же стандарт, только очень старый и нынче не модный.
        • +2
          Примерно так и есть, качества можно добиться и так и так. Стандарты необходимо знать и их придерживаться, я отлично знаю все места где код у меня не валиден, но я при этом знаю что только таким способом я мог решить ту или иную проблему.

          Тут вопрос как раз разработчика стоит ли тратить время на получение этой кнопки или же на развитие функциональности.
          • –4
            Я стараюсь больше придерживать синтаксису языка и делать код максимально логичным\симантичным.

            Однажды в качестве эксперимента дописал доктайп и в ужасе увидел, что все валидно :) но трехколоночный резиновый блочный макет разлетелся в разные стороны, как от взрыва гранаты, при том в каждом браузере по разному. Вздохну, убрал доктайп, добавил условие в виде
            if (strpos($_SERVER['HTTP_USER_AGENT'], 'Validator') // ]:->
            и успокоился :)
            • 0
              простите, что поправляю, но уж очень режет глаза — семантичным
    • +1
      Буквально сейчас заканчиваю кросбраузерный веб интерфейс в Strict который выглядит везде одинаково приятно :) Проблемы были только с IE6 потому как он xhtml(а у меня именно он) не поддерживает…
  • +5
    Добавлю что вместо IFRAME можно использовать OBJECT и тогда нету необходимости в transitional DTD.

    <object data="YourURI.here" type="text/html" height="100%" width="100%"></object>


    За статью спасибо.
    • +2
      Озадачивался этим вопросом. почему то ен получилось заставить работать в IE(хотел сделать трюк с ajax и кнопками back & forward в IE). это моя проблема или же это не возможно?
      • 0
        Честно говоря я не знаю. Уже забыл когда мне iframe нужен был в работе. Но если это не работает в IE то я не удивлён ;)
        • 0
          Мне вот тоже iframe нужен был только для того что бы в IE заработала навигация при изменении hash в адресе, но с object у меня ничего неполучилось. Может есть какой то хак что бы заставить IE работать с object так же как и с iframe, но поняв что это будет хак ради хака я решил что можно обойтись и без этих кнопочек :)
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Совершенно верно. Я не учел что именно из-за содержимого IFRAME доступного через JS он ещё и нужен бывает в верстке.
        В таком случае можно только для IE добавить IFRAME через условные комментарии и всё равно использовать в работе Strict :)
  • +6
    Ребята, не поверите, я только что реально понял разницу между Transitional и Strict. Спасибо за список ограничений, да и за статью в целом!
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      В Блокноте пишете небось? :)
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          еще есть SciTE, может вам понравится
        • +1
          Я PHP Expert Editor юзал, пока не познал NuSphere PHPEd.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Строго говоря, такие вещи лучше контролировать через CSS 3 со счётчиками и генерируемым содержимым.

      Но да — убрать, не оставив альтернативы — это жестоко.
      • +2
        Эм, счетчики и генерируемое содержимое это CSS2.1
        • 0
          Гм. Пардон, попутал. Велик соблазн называть то, что мало где реализовано и почти не используется принадлежащим к CSS 3.

          https://developer.mozilla.org/En/CSS_Counters
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Стандарты создают не для исправления багов, а для того что бы они не появлялись.
      • НЛО прилетело и опубликовало эту надпись здесь
        • –2
          ещё раз: object сделан не для того что бы реализовать нереализованную в браузерах ajax отправку файлов. в object может находиться swf, svg и т.д. Вы хотите в картинку форму отправить?
          • НЛО прилетело и опубликовало эту надпись здесь
            • –1
              если хотите ответы я вам их оглашу, хотя вы и сами это наверняка знаете. невозможно. невозможно.
              только вот проблема не в html.

              каким образом загрузка файла связана с (x)html? кроме того что и то и другое работает в контексте браузера я связи не вижу.

              имхо именно из-за такого подхода стандарты в таком плачевном состоянии. не нужно путать назначения технологий и возлагать надежды на то что в html реализуют костыль к функционалу javascript.
              • НЛО прилетело и опубликовало эту надпись здесь
                • –2
                  stdout и C — системный язык программирования…
                  DOM с которым имеет дело JS не привязан к html. JS и HTML никак не влияют друг на друга. Хотие я вам покажу SVG картинку с JS которая работает в браузере с подобной DOM и не содержит ни капли HTML? в ней совсем нет возможности отправить файл но это не проблема SVG или HTML.
                  • –2
                    целиком и полностью поддерживаю!
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  html это язык разметки и он ничего не отсылает. в случае не ajax запросов, файлы отсылает браузер и прекрасно с этим справляется.

                  Проблемы возникают при использовании ajax запросов с вложенным файлом(тут работает JavaScript). По соображениям безопасности JS не имеет доступа к файловой системе пользователя и соответственно не может отправить файл ajax запросом. Но, раз такая возможность была бы очень удобной, разработчики стали придумывать костыли с нестандартным использованием сторонних объектов (iframe, flash).

                  Если бы вместо того, чтобы остановиться на этом хак разработчики постарались бы в стандарт JS ввести доступ к файлам выбранным в input[@type='file'] то сейчас никаких вопросов и обвинений не возникало бы.

                  Теперь же, когда упразднили элемент Iframe и сделали более универсальный object(с задачей для которой создавался iframe он справляется), старые костыли перестали работать, ну и виноват в этом конечно же w3c.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      В конце концов всё через сетевую карту идет, ну вы же понимаете что я говорил о том что при не ajax этот процесс автоматизирован и не контролируем.

                      Ещё раз: в OBJECT можно постить мультипарт форму?

                      ветка началась с обсуждения этого вопроса. а вот на счет атрибута target у ссылок и форм я уже отписался в другой ветке.
                      Про появление XmlHTTPRequest в качестве ActiveX расширения я знаю. Тут в отличии от своего обычного мнения по поводу IE не могу не согласиться что это было весьма хорошее нововведение, как и VML позже превратившийся в SVG как и поддержка XSLT (в IE она была реализована первой). Есть конечно и другие мысли о некоторых нововведениях но на эту тему не считаю нужным холиварить.

                      Я пытаюсь отстоять мнение о том, что стандарты это не плохо и то, что в XHTML Strict не работает хак это проблема/вина тех кто его использует а не тех кто усовершенствовал стандарт. Тут вы согласитесь?
                      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Селект в ослике в любом случае перекрывается JS-генерируемым iframe'мом, так что костыли за аргумент не принимаются )
  • +11
    статья хороша тем что направляет разработчиков в правильную сторону.
    но в реальных проектах использовать strict можно лишь там, где вы на 99% уверены, что контент-манагер не вобъёт в визиг текст из word'a, а сайт будите поддерживать только вы и никто другой.

    есть несколько проблем связанных с повсеместным использованием strict, главная из них (упрощённо) — что strict это как показы мод от кутюр — клёва, но тяжело в реальности.
    * контент-менеджеры могут вбить всё что угодно. и ваш сайт, который был-бы валиден в transitional не будет валиден в strict.
    * затрудняется поддержка сторонними разработчиками. target — неработает, iframe — неработает, и т.п. Вам будет икаться :)
    * поиск обходных путей это замедляет разработку, а это — потеря денег. При этом реальной (финансовой) пользы strict почти не приносит (почти — кроме понтов, хотя хороший понт — дороже денег).

    Что вы приобретаете?
    * Хорошо структурированую разметку

    разметка зависит не от doctype, а от того откуда руки растут.
    можно писать ультра-семантично и в transitional.

    Четкое отделение содержимого от оформления

    аналогично

    Возможность более быстрой и легкой работы и поддержки кода

    реализовывание обходными путями функционала непредусмотренного в strict скорости явно не прибавляет.
    а уж как такой код «поддержат» джуниоры — страшно думать.

    Дисциплину в написании кода
    Респект и уважуху ;)

    это да, это есть.
    но всё можно красиво сделать и в transitional.

    Теперь немного в зашиту, чтоб не подумали что я против прогресса :)
    Т.к. по-сути единственная радость от strict — понты, я предлагаю ставить strict только на морде сайта.
    1. Она как правило идёт отдельным шаблоном
    2. Весь её код обычно или генерируется скриптами или статичен, а не редактируется из админки.
    3. Сорцы смотрят как правило морды.

    Такие дела :)
    • 0
      да уж, если бы поменяв одну строчку можно было бы приобрести всё то что написал автор, это была бы сказка)
    • +1
      ах, да — вот ещё одна мелочь — в transitional одиночная картинка вставленная в ячейку таблицы не генерирует контейннер строки. ну простыми словами — в strict вокруг картинки в ячейки таблицы появятся отступы. Вот тут подробнее: https://developer.mozilla.org/en/Images,_Tables,_and_Mysterious_Gaps

      Это конечно олд-скул и мало кому интерестно, но при редизайне старых сайтов полезно знать.
      Хотя проблему легко вылечить сделав картинку блочным элементом.
  • 0
    элементы… не могут быть дочерними для blockquote, body, form, noscript

    body? или может имелось в виду tbody?
    • 0
      Имелось в виду то что было написано.
      • 0
        Прошу прощения, невнимательно прочитал. Речь то шла только о дочках первого уровня.
        • 0
          Ну да, иначе бы веба не было ))
  • 0
    Я не понимаю — чем W3C не угодил атрибут «target» у ссылок?
    • 0
      тоже для меня всегда оставалось загадкой. Хотя в принципе не особо обломно, но «осадок остался»
    • 0
      а тем что это мешает пользователю. если я просматриваю сайт, то я должен решать где я его буду просматривать. допустим разного рода сайты с желтыми новостями злоупотребляют target'ом и каждая следующая страница открывается в новом окне, мне(как пользователю) этого не хочется. а если я сам желаю открыть в ссылку в новм окне то я могу этого легко достичь привычным нажатием колесика мыши(ну если кому удобнее то правой кнопкой мыши и выборум пункта меню). суть в том что не всё нужно решать за пользователя
      • 0
        Кстати в HTML5 target возвращается.
        • 0
          К сожалению пока не нашел времени посмотреть пока неактуальны html5. Если он действительно возвращается то мне так же становится неясна логика :) Можете объяснить?
          • 0
            Теряюсь в догадках. Сначала отменили как deprecated. Теперь возвращают…
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Тебе действительно хочется не закрывать теги (есть и такие персонажи) или всё же иметь больше возможностей? (это ещё можно понять)
      • +2
        С другой стороны есть варианты, когда немного подумать за пользователя полезно.
        Например, есть форма, состоящая из 20 полей, которую юзер внимательно заполнил. В конце стоит ссылка на пользовательское соглашение, или на другую информацию, которая не помещается на текущей странице. Если юзер нажмет на ссылку и страница откроется в этом же окне (табе), все введенные данные пропадут. Вот здесь было бы нелишним обезопасить пользователя от случайного сброса данных.
        Еще как вариант можно рассмотреть страничку, на которой проигрывается видео или аудио. Тогда при открытии ссылки в том же окне проигрыш прервется, что не есть юзер-френдли.
        Бесспорно, все описанные выше кейсы можно обойти с помощью того же джаваскрипта. Я лишь хотел выразить свое личное мнение, что атрибут target заслуживает право на жизнь, и что юзабилити — это золотая середина между подходами, когда все продумано за пользователя и когда пользователь все решает сам.
  • +1
    Я лично использую стрикт, потому что он переключает браузеры в правильный режим, да и при валидации по идее должно больше косяков выявляться (не все конечно критичны, просто что бы иметь ввиду). Реальных мега преимуществ у стрикта не видно. Разве что
    # Дисциплину в написании кода
    ну и понтануться можно что в стрикт верстаешь :>
  • +1
    статья отличная, автору, однозначный как он выразился респект и уважуха, но дико извиняюсь: убирети слово «залазив». Оно ужасно, его нет в русском языке.
    • +1
      как впрочем и слова «убирети» :) в моем посте :)
    • 0
      Спасибо за поправку, сейчас прочитал и ужаснулся ))
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Я с вами согласен, но считаю что многим разработчикам валидация, в первую очередь, нужна как инструмент для самоконтроля, дисциплины написания кода и четкого понимания того, что они делают. Потому что дать свободу написания кода человеку, который осознает что он делает — это одно, а дать свободу начинающему разработчику — совсем другое.

      В сложившейся ситуации важно воспитать дух, а инструменты подтянутся.
      • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    по поводу открытия ссылок в новом окне…
    я не разработчик, обычный юзер, который немножко зная html, просто наваял несколько страничек себе, под разные нужы.

    Однажды возникла идея сделать себе небольшой каталог ссылок, именно в виде отдельного сайта-странички на коротком домене (закладки не вариант, ибо нужен доступ с любого компьютера; сервисы социальных закладок не нравятся рекламой/дизайном/прочим мусором). Ну вот такая маленькая прихоть. Естественно, у всей этой штуковины пользователь один. Я. Ну и ещё знакомых я посылаю туда, которые вечно спрашивают «а где качать порно?», «а музыку брать где?» и т.п.

    Естественно, мне нужно было всё открывать в новом окне, но на многих сайтах, где поднимался этот вопрос, почти все хором твердили: «пользователь сам должен решать, где и что ему открывать!». Была поставлена задача, а люди, вместо советов, высказывали мнение о неправильной задаче впринципе.

    Ну, блин, я наконец-то нашёл гениальное по своей извращённости [base target="_blank"], которое надо прописать в head страницы. И, вы знаете, мир не взорвался, меня не съел динозавр, как в том комиксе, всё заработало так, как мне надо.

    Может, вы знаете валидный способ одной командой/строчкой открывать все ссылки в новом окне — подскажите.

    P.S. кстати, где-то кто-то обмолвился, что такая функция будет реализована в css3, значит это кому-нибудь нужно)
  • +3
    Честно говоря, я привык действовать по-другому:

    — Ставлю максимально строгий доктайп
    — Бодаюсь, чтобы соответствовать ему
    — Если не получается, скатываюсь на Transitional

    А на картинке какая-то неваляшка-мутант :)
    • 0
      Вадим, давай как на духу — часто у тебя не получается? )
      • +1
        Если правила разработки находятся под моим контролем — почти всегда.
        Если я всего лишь один из исполнителей, то редко.

        Какнадуху :)
  • 0
    все просто и лаконично — пятерка.
    CurlyBrace, добавлю свое решение по поводу «Отказ от атрибута target="_blank" для ссылок.»л:
    <a href="http://example.com" onclick="this.target='_blank'">link</a>
    
  • 0
    Выше уже говорили про использование iframe в хаках для IE. В качестве выхода предлагали генерировать iframe с помощью Javascript или заключать в условные комментарии. Но есть же ещё один, более распространённый пример использования iframe: создание его для отсылки в него формы, для использования асинхронной загрузки файлов. ясное дело, что это не отражается на валидации документа, так как iframe создаётся через DOM, но является ли это корректным? :)
  • 0
    Дисциплина это конечно хорошо, но реальных преимуществ Strict перед Transitional не вижу (понты перед коллегами не в счет). Даже наоборот, в быстро развивающемся проекте с 90% user-generated контентом стриктовый доктайп приносит только неудобства.
  • 0
    С радостью бы юзал Стрикт, но у нас CMS на ASP… там в коде после body сразу form… внутри которой вся вёрстка…
    сколько не спрашивал программеров, говорят по другому никак, ничем помочь не могут… (
    • 0
      А в чём проблема? Вставьте один большой div, в него всё остальное :)
      Правда я не верстальщик, я просто программист в конторе, у которой тоже CMS на ASP.NET… И наша вёрстка использует strict.
      На самом деле я не заморачиваюсь валидацией, а с точки зрения стремления к идеалу меня больше беспокоят ошибки типа:

      Error Line 239, Column 50: value of attribute «ID» invalid: "_" cannot start a name.
      …type=«hidden» name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTEyOTM1ODU0

      И тому подобные… А элементы эти генерит сам asp.
      • 0
        Использование форму в теле кода — это аналог Windows Forms.
        «Сближает программирование настольных приложений с программированием web-приложений».

        Поэтому там
        <_body_>
        <_form id=«Form1» runat=«server»>
        <_/form>
        <_/body_>

        (подчёркивания я выдумал)
        • 0
          использование form на все тело страницы — это прежде всего «долбо%бизм» как тут ни крути.
  • 0
    С радостью бы юзал Стрикт, но у нас CMS на ASP

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

    Я вот действительно не понимаю, чем им не угодил ифрейм и таргет, остается только динамически JS-ом добавлять, хотя про ссылки это имхо перебор.

    Автору спасибо за полезную информацию, а господину maxlapshin за информацию к размышлению и логичный вопрос.
  • 0
    Ещё есть:
    DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" «www.w3.org/TR/html4/frameset.dtd»

    This declares the document to be HTML 4.01 Frameset. HTML 4 Frameset is a variant of HTML 4 Transitional for documents that use frames.

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