Чего я ждал от HTML5 и CSS3

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

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

    Возникает резонный вопрос, куда делись все те люди, которые разрабатывали стандарты 10 лет назад? Куда делись инновации? Почему w3c создает стандарт, который, по некоторым меркам, уже устарел?

    Давайте разберемся.


    HTML5


    Одними из самых непонятных мне тегов являются del и ins. Они грязным хаком прошли по всей структуре языка, имея при этом весьма сомнительную пользую. Попытки перенести логику офисных документов на веб-страницу закончатся полным фиаско. Почему? Да очень просто! Если вам нужно получить историю изменений документа, то сделать это можно внешними программами, не перенося этот функционал внутрь языка. История правок нужна менее чем одной сотой доле процента пользователей, все остальные спокойно довольствуются текущей актуальной версией данных на момент поиска информации. Парсинг кода с учетом этих двух «замечательных» тегов будет сплошным негативом, потому что нарушается стройность и логичность языка, его предсказуемость.

    Второй прикол, это попытка всунуть в HTML вещи, которые нельзя было туда добавлять ни в коем случае. Это атрибуты contenteditable, draggable и прочие интерактивы. Это должно быть вынесено в CSS, DOM, куда угодно, только не в HTML. Это интерактивы, а не разметка. Интерактив должен быть управляемым, и для управления есть замечательный JS и великолепный CSS. Писать эти атрибуты прямо в HTML — очень сильно попахивает HTML образца версии 3.2.

    Третий прикол, это жалкие попытки структурировать документ, путем введения дополнительных структурных элементов. Это просто цирк какой-то. За эти слова в меня будут кидаться тапками, но, надеюсь, ряд людей поймет, почему я так говорю. Отойдем от этой темы в сторону и порассуждаем о том, зачем же нужен HTML. А нужен он для того, чтобы сделать разметку некой информации. На данный момент времени разметка включает не только контент, но и дизайнерские изыски. Итак, у нас есть мухи отдельно (структуры, которые нужны для оформительских целей), и котлеты отдельно (непосредственно сам контент). Для контента HTML подходит на ура, а вот с дизайнерскими изысками большие проблемы. Да и с логическими структурами страницы тоже проблемы. У одного на сайте меню, сайдбар и контент, а у второго — шапка с главным меню, второстепенное меню, два сайдбара слева и справа, рекламный бокс, список товаров и прочее. Как их подружить? Да легко! Нужно всего лишь позволить придумывать свои теги! XML для оформления страницы, HTML — для оформления контента. Почему бы сразу не использовать XML? С ним будет больше сложностей для поисковиков. На рынке есть удачное решение проблем поиска при такой структуре документов — микроформаты. Создав, например, атрибут behavior, который будет содержать описание поведения элемента, можно спокойно рассказывать поисковым системам где и что у тебя организовано.

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

    Вот мы и подошли плавно к теме CSS3

    CSS3


    Продолжим тему веб-форм. Рынок веб-интерфейсов ожидает контроллируемую стилизацию полей ввода. На практике это означает, что я хочу из любого элемента сделать любое поле ввода. Я хочу сделать чекбокс со своим собственным дизайном, хочу сделать селектбокс со своим оформлением, каждую опцию создавать из своей собственной XML-структуры и так далее. Что мы видим в рабочем варианте спецификации? А ничего.

    Темплейты отображения (Template Layout) сперва меня вдохновили, потом, после моделирования реальных ситуаций, я понял, что это работать не будет вообще. Если контент статичен, то такой подход работать будет. Но как только появляется динамика…
    Возьмем вполне нормальную ситуацию: у нас есть четыре блока, которые, в зависимости от ширины контента или окна браузера, должны выстраиваться друг за другом, и занимать или одну строку, или две, три, четыре строчки. Обычные float'ы. Все, коллапс, ведь темплейт не описывает поведение блока и перемещение его в случае, если он не влазит в некое пространство. Позиция блока в темплейте четко зафиксирована, адаптивную верстку делать будет крайне затруднительно. А это требует рынок, а это сейчас делается при помощи костылей. Кроме этого не совсем понятно, как при изменении DOM дерева, блок, у которого прописана четкая позиция в темплейте на странице, будет себя вести. Но это никого не волнует, мы из веб-страничек делаем журнальную верстку. Я писал про это Д. Барону, но эффект нулевой.

    Вернемся еще к одной очень важной вещи, под названием точка отсчета. Точка отсчета на данный момент времени выбрана одна — левый верхний угол. Рассчет позиции того же фона ведется именно из этого места. Но в мире существуют не только те, кто читает слева направо, а еще и те, кто читает справа налево, сверху вниз и так далее. Теперь попробуйте без костылей сделать мультиязыковый дизайн. А решение проблемы у всех под носом — нужно всего лишь изменить точку отсчета, и позиция фона для жителей Саудовской Аравии, чудным образом осталась бы неизменной, например 10px 10px, и находилась бы в верхнем правом углу, ровно на данное смещение. Развивая идею с точкой отсчета, можно обнаружить более управляемый контроль позиции абсолютных элементов, контроль трансформации объектов и много полезного. Но этого я не нашел в спецификации.

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

    UPD: Огромное спасибо всем за позитивную и негативную карму!
    UPD2: Изменил абзац про темплейты отображения

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 178

      +15
      Вертикальное позиционирование без извращений и pivot points для позиционированных элементов тоже бы не помешали, а то конструкции типа left: 50%, margin-left: -50% слегка напрягают…
      • UFO just landed and posted this here
          0
          Поработайте с DOM деревом с учетом del и ins, и поймете в чем претензия. Мало того, вы знаете хоть одну систему, которая использует данные теги? Лично я не видел ни одной.

          По поводу contenteditable, draggable. Им самое место в css.

          Во поводу div'ов вместо конкретных тегов. Да, конечно же, можно так использовать, но читабельность такого кода ниже, чем чистый XML. Работа с DOM сложнее. Шанс на ошибку валидации выше. Попробуйте хоть раз поработать с XML в качестве оформления страниц, поймете разницу.

          Шаблонная разметка не учитывает современные тенденции. Разместить все по шаблону не есть плохо. Плохо то, что это только статика. Да, и если я перенесу какой-то блок с одного места дерева DOM, в другое, он визуально поменяет свою позицию, если у него будет стоять position: a?

          • UFO just landed and posted this here
              +5
              А в чём претензия, сказать не можете? Зачем с ними только работать в динамике, ума не приложу. Они предназначены для отображения каких-то изменений, например, между разными версиями документа. Откуда там динамика?
              Хоть одну систему знаю. Да и сам использовал для внутренних инструментов сайта.

              Конечно могу. Эти два тега имеют двоякую суть, могут быть блочными или строчными. Это вроде бы не проблема, но любой CSS, который будет учитывать позицию элемента в дереве, должен учитывать и этот элемент. Например, если у вас есть :first-child>b, то когда вы первый контейнер обернете в ins, наступит коллапс. Если скрипт обходил детей ноды, и там всегда предполагался какой-то один элемент, то с учетом del/ins все может поломаться, и придется использовать другие варианты работы с деревом, которые могут быть не самыми быстрыми в реализации.

              А это с какой ещё стати? Это поведение, а не отображение. Вы ещё скажите, что каким-нибудь атрибутам вроде onclick место в CSS.

              А чем position: fixed не поведение? Вот в чем разница? position: draggable — аналогичное свойство. Псевдоклассами управляем состояние наведения на таргет, DOM будет работать так же как и сейчас.

              Шанс ошибки валидации, говорите, выше? А что вам говорит бизнес, когда сайт не работает (страница вообще не отображается) из-за ошибки в XML из-за какого-нибудь неэкранированного амперсанда? А современные методы DOM (например, querySelector и др.) вполне способны справится.

              Выше шанс. Пропустить div проще, чем пропустить отсутствие четко именованного тега. Доказанный факт. Валидацию XML проще сделать перед публикацией, чем валидацию HTML.

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

              Конечно отрицаю, потому что если изначально технология не справилась с современными задачами, то дальше пойдут или хаки, или полное переписывание спецификации в данном вопросе. Это будет ад для разработчиков браузеров и для веб-разработчиков. Если лопата не поможет быстро перекопать 1 гектар земли, то любые нанопокрытия, улучшенные формы для снижения трения и другие примочки не исправят ситуацию. Нужно заведомо более гибкое решение, чтобы не было потом как с menu, то его отменяют, то обратно возвращают.
                +5
                > если у вас есть :first-child>b, то когда вы первый контейнер обернете в ins, наступит коллапс
                span, i/em туда же?
                • UFO just landed and posted this here
                    +1
                    Скорее всего у нас разные подходы к пониманию того, что такое HTML, CSS, DOM. Для меня это не статические вещи, это некая живая абстракция, которая может мутировать, видоизменяться под конкретные условия, выполнять вполне конкретные задачи, решать поставленные цели. Это как инструмент. Я никогда не беру в рассчет тот факт, что некий веб-документ является статической сущностью, для меня это некий живой организм, в котором постоянно происходят процессы изменения, развития и так далее. Эти изменения вызваны модификацией кода разработчиком, либо модификацией некой части документа пользователем, либо работой некоего скрипта. Это другой уровень абстракции, который использует не частности, а общие принципы взаимодействия структур. Это тяжело без подготовки описать словами.
                    • UFO just landed and posted this here
                        0
                        Спецификация, которая не учитывает этого, может стать проблемой развития отрасли в целом. Цель какая? Попытаться сделать что-то новое? Или может исправить проблемы старого? Или предугадать проблемы будущего, и сделать то, что будет актуально завтра?
                      0
                      мне как-то рассказали как разграничить HTML и CSS. Так вот: то что нужно браузеру для слепых должно быть в HTML, а всё остальное в CSS. Если придерживаться этой точки зрения, то contentEditable должен быть в HTML, а draggable в CSS.
                      • UFO just landed and posted this here
                          0
                          Я только про HTML и CSS говорил (как отделить структуру от представления). JS где был там и остаётся. И onMouseMove в том числе.
                          –1
                          > Так вот: то что нужно браузеру для слепых должно быть в HTML, а всё остальное в CSS.
                          Короче, всё в CSS?
                            0
                            драгабла вообще нигде быть не должно %-) объект должен быть перемещаемым когда на него вешают обаботчик события. если обработчик не задан — не перемещаем.

                            также как, лапка над элементом должна появляться когда объект реагирует на клик (это ссылка, кнопка или задан обработчик). иначе — лапки быть не должно. и задаваться это должно отнюдь не в css
                              0
                              В этом что-то есть. Но хочется контроля над всем.
                                0
                                а поменять вид курсора можно было бы через псевдоэлемент:

                                .snippet:clickable:cursor { content: url( '/img/hand.png' ); left: -4px }

                                абсолютный контроль

                      0
                      >> По поводу contenteditable, draggable. Им самое место в css.

                      ??!

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

                      Ну а если генерить XML не как текст, а как XML, используя DOM или какой-нибудь потоковый генератор?
                        0
                        Поствалидация XML, перед публикацией в веб, решает эту проблему. Генерировать код программой не особо выгодно, так как трудно интегрировать с темплейт-системами, труднее поддерживать код, изменять его.
                          0
                          Какая разница, кто матюгнётся: сервер на этапе поствалидации или браузер? А то, что темплейт-системы генерируют текст, а не XML — это очень прискорбно.
                            0
                            Был бы аппаратный XML процессор, было бы легче. На данном этапе работать со строками гораздо дешевле по ресурсам.
                              +1
                              А с чего это шаблонизатор, выдающий XML, должен быть тяжелее текстового шаблонизатора? Ведь всё отличие XML-ного шаблонизатора в том, что на входе он потребует well-formed XML-документ, а на выходе заэкранирует что нужно. В текстовом шаблонизаторе на выходе получится тот же код, но за правильностью исходного шаблона с точки зрения XML и за экранирование вывода отвечает программист, а не шаблонизатор.
                                0
                                Потому что работа с объектами в памяти сложнее, чем работа со строками в памяти. К примеру, XSLT преобразование в php примерно в 4 раза медленнее, чем аналогичный функционал на Smarty.
                                  0
                                  Строка в памяти — это и есть объект. Про XSLT-преобразование речи никто и не ведёт. XSLT, помимо низкой производительности, плох ещё и тем, что исходные данные для него задаются в XML. Вот если шаблонизатор в качестве исходных данных принимает объекты, то он же сможет дёргать их методы или передавать их методам других объектам (или, например, статическим методам некоторых классов). При этом никто не мешает скомпилировать XML-шаблон непосредственно в код виртуальной машины соотв. языка (если язык такое позволяет). Кстати, надо сказать, что PHP проблемы с XSLT ещё и в том, что при каждом запросе надо компилировать сам XSLT-шаблон, тогда как в других языка достаточно скомпилировать шаблон при старте сервера.
                                    0
                                    XML-нода в памяти не простой объект, а DOM-нода со всеми вытекающими. Но, я вашу мысль понял. Надо над ней подумать, в этом есть свои плюсы.
                                      0
                                      XSLT, помимо низкой производительности, плох ещё и тем, что исходные данные для него задаются в XML.

                                      Это как-то вашим собственным опытом подтверждено или же просто подпеваете народным мифам? :-)
                                      Имея качественную обёртку, есть ли принципиальная разница — передавать данные в шаблонизатор через ассоциативный массив или же DOM? Да, может это займёт не 1, а целых 2-3 строчки кода… А если данные для шаблонизатора структурированы чуть сложнее, чем одноуровневый список?
                                        0
                                        Не, ну никто конечно не мешает через какой-нибудь механизм привязки данных к XML вроде JAXB данные для XSLT подгонять. Но ради чего, если проще работать с шаблонизатором, который сразу данные в виде объектов принимает? Тем более, что есть ряд удобств в именно таком подходе. Что если, например, у нас есть строки в camelCase и нужно проставить подчёркивание между словами? В XSLT геморрой. В случае с объектами мы просто пишем метод, выполняющий соответствующее преобразование и дёргаем его из шаблона. Ну и моя личная практика показывает: XSLT тяжёлый. Вообще, я пришёл к убеждению, что не следует пихать XSLT во все дыры, как это делают некоторые. Ибо не только медленно, но и неудобно. Кстати, пример, когда XSLT мне показался ну очень неуместным (и жутко прожорливым) — Sandcastle
                                          0
                                          Вот странно, почему когда заходит речь об XSLT — в первую очередь начинают вспоминать Java и всё с ней связанное, будто это чуть ли не единственная среда, в которой можно им пользоваться. Не отсюда ли растут ноги мифа о «тормознутости» XSLT?
                                          Что если, например, у нас есть строки в camelCase и нужно проставить подчёркивание между словами? В XSLT геморрой.

                                          Мне кажется, это далеко не самая востребованная функция в «шаблонизаторах», если уж зашёл разговор о способах вывода: сразу HTML или XML+преобразование. :)
                                          В конце концов первостепенная цель — привести данные к конечной структуре, а не полностью отказаться от написания преобразующего кода, перенеся его на плечи шаблона, лишь бы побольше дешёвой магии.

                                          Про Sandcastle ничего не могу сказать, не приходилось иметь дело.

                                          Ну и моя личная практика показывает: XSLT тяжёлый.

                                          А моя личная практика показывает: XSLT почти везде показывает себя лучше, чем традиционные костыли на интерпретируемых языках, работает нисколько не медленее (хотя, конечно, можно как s0rr0w бессмысленно попугать мифическими шаблонами весом в мегабайты), удобен, гибок и поддерживается кучей платформ. Profit.

                                          Одна из немногих адекватных статей в пользу XSLT, на мой взгляд: blog.umi-cms.ru/sergej2/reabilitaciya_xmlxslt_tehnologij/
                                          Реальных примеров, конечно, не хватает.
                                            0
                                            Мне кажется, это далеко не самая востребованная функция в «шаблонизаторах»

                                            Тем не менее, когда всё-таки нужно что-то подобное, с XSLT приходится использовать костыли. Да и необходимость генерить XML, чтобы подать его на вход XSLT-шаблону несколько удручает. Ибо в случае даже с JAXB необходимо прописывать XML-схему и аннотации. Конечно, можно придумать свой костыль для простенького преобразования объектов в XML, но зачем, когда можно и без этого?
                                            Вот странно, почему когда заходит речь об XSLT — в первую очередь начинают вспоминать Java и всё с ней связанное, будто это чуть ли не единственная среда, в которой можно им пользоваться.

                                            Да нет, как раз более популярным в вебе является PHP, потому и про XSLT говорят, наверное, в контексте PHP. Так вот: в Java (Ruby, Python, C#) как раз с производительностью XSLT несколько лучше, ибо можно при старте сервера скомпилировать XSLT, а не парсить его каждый раз при HTTP-запросе. XSLT в Java и PHP теоретически может работать одинаково, т.к. скорее всего и там и там дёргается нативная реализация XSLT (хотя, возможно, в Java XSLT-процессор написан на Java, но от этого хуже не становится). Вот только если насчёт Java я уверен, что Java-код работает не медленее XSLT-процессора, то от PHP можно ждать чего угодно.

                                            XSLT почти везде показывает себя лучше, чем традиционные костыли на интерпретируемых языках

                                            А кто говорит про интерпретируемые? Я например, говорю больше про Java и .NET. Так вот там производительность шаблонизатора без XSLT должна быть выше, ибо в конечном итоге все сводится к нативным инструкция процессора, которые не работают с DOM-деревом в памяти, а сразу выводят текст. Ах да, им ещё не надо парсить входной XML.
                                            Одна из немногих адекватных статей в пользу XSLT, на мой взгляд: blog.umi-cms.ru/sergej2/reabilitaciya_xmlxslt_tehnologij/

                                            А ничего адекватного в статье нет. Только лозунги. И сравнение со Smarty в кривых руках. Ну например:
                                            Правка XSLT шаблона не предполагает вмешательства в бизнес-логику и анализ структуры связей, которые могли бы использоваться в шаблоне будь он на Smarty.

                                            Правда? Чего бы это вдруг шаблонизатор начал вмешиваться в бизнес-логику? А как XSLT от этого спасает? Во втором случае я вижу единственный вариант: в бизнес-логику лезет не сам шаблон, а некий слой, который вытаскивает данные и преобразует в XML. Для этого слоя даже есть название: presenter в паттерне MVP. Так вот если не устраивает MVC, то может стоит перейти на MVP? И в случае шаблонизатора без XSLT всё отличие presenter'а будет заключаться в том, что он просто вытащит данные, а не будет ещё преобразовывать их в XML.
                                      0
                                      К примеру, XSLT преобразование в php примерно в 4 раза медленнее, чем аналогичный функционал на Smarty.

                                      Пруф-линком не поделитесь? А то что-то сомнения большие одолевают.
                                        0
                                        Не могу, собственные тесты. Объем базового XML — примерно пару мегабайт. Преобразование XML в RTF.
                                          0
                                          Что ж, было весьма ожидаемо. Вспомнили бы сразу тогда и WordML… :-D
                                          Только как это соотносится с возможностями традиционных шаблонизаторов, построенных поверх PHP? С помощью Smarty вы тоже RTF создаёте семь раз на дню?

                                          Не встретил на Хабре пока ещё ни единой контр-позиции с чёткими доказательствами, чем же XSLT так страшен и тормознут. Всё как один уповают на некогда услышанный миф. И, как оказалось, в большинстве своём хаящие даже представления не имеют, как создать простейший лаконичный XSL шаблон для преобразования и подготавливать для него данные.
                                            0
                                            Давайте сделаем проще. Берем некий XML, с какого-нибудь сервиса, вы делаете свое преобразование при помощи XSLT, я — свое на смарти. Меряем скорость. Идет?
                                              0
                                              Вам пример с XML был совершенно несопоставим. Теперь пытаетесь отыграться хоть в чём-то?
                                              Извините, моё время мне пока дороже. И применение XSLT где бы то ни было его точно не отнимает, по сравнению с остальными многочисленными костылями-велосипедами.
                                              Если вам настолько принципиальны разницы в производительности (а всё остальное, стало быть, не имеет значения?) — тестируйте и поделитесь результатами на Хабре. А мы обсудим. :)
                                                0
                                                Обсудите? Да вы же не поверите ни одной моей цифре, потому что я буду по вашему мнению предвзят. :)
                                              0
                                              0
                                              Свежие данные. Переписывание парсера с XML->XSL->RTF на XML->Smarty->RTF дало прирост примерно раз в 10 на документах страниц под 200. Исходный XML тупой что двери, тексты да пара табличек.
                                          +1
                                          покажи тесты
                                            0
                                            Тестировалось на живом продукте. Показать не смогу.
                                              0
                                              да я уже понял, что вы не умеете готовить %-)
                              –1
                              Согласен, на HTML5 возлагают слишком большие надежды, пока его допилят до финальной версии и он станет поддерживатся большинством браузеров, скорее всего у рынка будут уже другие требования.
                              Перенесите, кстати, в тематический блог, этому место на главной.
                                +1
                                Перенес. Я осваиваюсь только, еще не все изучил.
                                –1
                                > Нужно всего лишь позволить придумывать свои теги! XML для оформления страницы, HTML — для оформления контента. Почему бы сразу не использовать XML?
                                  +1
                                  Ну так кто не дает? Откройте для себя XSLT ;)

                                  p.s. Сорри, что в 2 коммента — ктрл-ентер случайно нажал.
                                    +1
                                    XML — вольное изложение темы. Какие теги придумаешь, какую структуру создашь, то и твое. HTML — жестко очерченные рамки и названия. Если использовать только XML, то поисковые системы сойдут с ума. Потому что один назвал заголовок HEADER_LEVEL_ONE, а второй — H1. Как догадаться, что это одно и то же? Поэтому я и смешиваю два разных языка, выбирая для разных задач лучшее.

                                    XSLT не решает эту проблему.
                                      0
                                      Он и не должен ее решать. Просто автор сетовал, что нельзя придумать свои теги. А я о том и писал, что если придумывать их «свои», то пропадает семантический подтекст HTML (ну или для полной корректности сравнения возьмем XHTML). Однако если очень уж хочется свое придумать — можно взять базой XML, и через XSLT транслировать его в HTML для браузеров и поисковиков.
                                        +1
                                        Это дорого по ресурсам, и нисколько не эффективно. Зачем что-то делать два раза, если можно сделать один? Да и работать с CSS, DOM в XML будет в разы легче и проще. Попробовав раз, трудно от этого сладкого запретного плода отказаться.
                                          0
                                          Ну… гзип по ресурсам гораздо дороже, но все-таки его пользуют там где нужно :) Так что это не показатель. К тому же не факт, какие еще ресурсы будут дороже: xml может быть меньше по размеру, а xsl трансляцию можно делать у клиента. В общем, всему свое применение ;)
                                            0
                                            Это в разработке дорого. Делать сначала XML, потом получать при помощи трансформаций HTML, а JS-скрипты должны работать все равно с HTML, CSS туда же. И чего мы таким образом получим? Где упрощение или улучшение?
                                              0
                                              Это в разработке дорого

                                              Предпочитаете дёшево и сердито — PHP и HTML в одну кучу? :))

                                              Скрипты всяко имеют дело с DOM, а не конкретно с HTML. :)
                                                0
                                                Кто сказал, что PHP и HTML надо в одну кучу? Скрипты будут иметь дело с HTML документом, а не XML.
                                          0
                                          на тему семантики: habrahabr.ru/blogs/css/96426/
                                          а вообще, xml — это просто синтаксис и на его основе существует множество _стандартных_ языков: xhtml, mathml, atom, foaf, vcard… и некоторые из них _уже_ понимают поисковики.
                                      • UFO just landed and posted this here
                                          0
                                          Открою вам секрет, что custom tags в ИЕ поддерживаются с версии 5.0 или 5.5, точно не помню. Ищите в инете это ключевое слово. Там все не безоблачно, но использовать в проектах можно.
                                            +1
                                            Открою вам секрет, эти кастом теги без хаков не потдерживают стили.
                                              0
                                              Поддерживают. Даже пример на сайте MS есть.
                                                0
                                                Можно ссылку? Мои експерименты показывают обратное.
                                                    0
                                                    Спасибо, это реально полезная инфа. Итересно что этот способ работает во всех браузерах.

                                                    Я ессно имел ввиду теги типа Tag. Такая штука потдерживается всеми браузерами за исключением ИЕ.
                                                      0
                                                      Есть сразу предупреждение, этот способ нельзя использовать при динамике или в больших документах. ИЕ начинает впадать в кому. С чем это связано, еще не изучил, но написал письмо в MS. Буду ждать ответа.
                                                        0
                                                        не замечал такого, хотя использую постоянно
                                                          0
                                                          Объем страницы? Скажем так, вы переключаете display у дерева, примерно на 2к нод?
                                                            0
                                                            ие и при меньших количествах может в кому впадать %-) и кастомные тэги тут ни при чём
                                            0
                                            от header вместо div#header никто с ума не сойдёт, кроме разве что ff2 ;-)
                                        +5
                                        > Веб разработкой я занимаюсь давно, и помню еще IE3 и NN4.xx.
                                        > Начало разработки спецификаций HTML5 и CSS3 уже не вызывала у меня щенячьего восторга и бурной радости, а воспринималась как вполне эволюционное событие.

                                        Может быть вы просто повзрослели? ;)
                                          +1
                                          Все может быть… :)
                                          0
                                          Возьмем вполне нормальную ситуацию: у нас есть четыре блока, которые, в зависимости от ширины контента или окна браузера, должны выстраиваться друг за другом, и занимать или одну строку, или две, три, четыре строчки.

                                          Существует достаточно простое, но не совсем очевидное решение — использование inline-block (подробнее)
                                            0
                                            У которого есть основное ограничение: внутри инлайн блока не должно быть блочных элементов.
                                            • UFO just landed and posted this here
                                                0
                                                Найдите в спецификации указание на этот факт, что внутри инлайн-блока можно использовать блоки. Мне это не удалось, может плохо искал.
                                                • UFO just landed and posted this here
                                                  • UFO just landed and posted this here
                                                      0
                                                      Вот что написано про блоки в CSS3

                                                      A block-level box is a box that has a used value for ‘display’ of ‘block’, ‘list-item’, ‘table’, ‘table-*’ (i.e., all table boxes) or <template>. A block-level element is an element all of whose top-level non-anonymous boxes are block-level.

                                                      An inline-level box is a box that has a used value for ‘display’ of ‘inline’, ‘inline-block’, ‘inline-table’ or ‘ruby’.

                                                      В описании блочных элементов отсутствует inline-block, поэтому дуализм этого типа, я думаю, не может применяться в чистом виде как отдельная сущность.
                                                      • UFO just landed and posted this here
                                                          0
                                                          Согласен.
                                                    0
                                                    Ну не совсем и всеми вытекающими. Например, в фф2 и опере <10 в инлайн блоках абсолютное позиционирование с заданными координатами не работает. Ну допустим ладно фф2, но у оперы то нативный инлайн-блок.
                                                    • UFO just landed and posted this here
                                                        0
                                                        Да, немного напутал спеки и практику :)
                                                        0
                                                        с position:static и не должно работать
                                                          0
                                                          Причём здесь статик? Я про абсолютное говорил.
                                                            0
                                                            абсолютное внутри статика?
                                                              0
                                                              рилейтива само собой) про статик вроде бы речи вообще не шло) речь шла про то, что в инлайн блоках (с рилейтивом) в опере < 9.5 не работают абсолютно спозиционированные элементы с чётко заданными координатами.
                                                  +3
                                                  Я вот когда смотрю на семантическую состоявляющую ШТМЛ5, становится смешно. Это ж надо было сделать нерасширябельный словарь. О чем думали? Это же тупик. Никаких отличий от HTML4.
                                                    +10
                                                    When people say «i want to extend HTML in arbitrary, private, and probably proprietary ways,» the appropriate answer is «fuck you»
                                                    — Mark Pilgrim, krijnhoetmer.nl/irc-logs/whatwg/20091205#l-330
                                                      +1
                                                      Это никак не относится к словарю семантики. Почитайте про микроформаты. Вам должно стать более понятно, зачем необходим расширяемый словарь.
                                                        0
                                                        определитесь: вы хотите писать новые теги или нет?
                                                        если да, то Марк уже ответил выше
                                                        если нет, то почитайте про microdata и полюбите html5
                                                          0
                                                          Да я хочу писать новые теги, если есть тег nav, я хочу иметь тег hCard. А Микродата это то что я свободно сделаю в HTML4 при помощи класов. В чем нововведение? За что любить?
                                                            0
                                                            тогда перечитайте ответ Марка и посмотрите, сколько людей с ним согласны
                                                              –1
                                                              не читайте ослов — не будете баранами %-)
                                                    –9
                                                    Меня вот реально бесит, что в CSS нужно указывать браузер… К чему эта лабуда из неймспейсов -moz, -opera, -webkit раздувающая файл?! Похоже на костыли к ещё не сломанным ногам…
                                                      +6
                                                      Это не нужно делать, это можно делать для работы с экспериментальными свойствами, поддержка которых в будущих версиях браузера может: а) исчезнуть б) измениться в) очень сильно измениться.

                                                      Opera, IE9, Chrome, Safari — последние версии этих браузеров уже поддерживают некоторые свойства без префиксов в ответ на устаканившуюся спецификацию.
                                                      • UFO just landed and posted this here
                                                          0
                                                          На практике 100% работает ТОЛЬКО с префиксами нейспейсов. Даже базовый opacity. Приходиться делать проекты для web/wap и если web работает на ура, то с мобильными устройствами всё гораздо хуже.
                                                          • UFO just landed and posted this here
                                                              0
                                                              Мне как то display не сильно актуален, но для вас может шоком, что есть люди ( в основном на WM6 устройствах) которые используют fennec и любят пообщаться с тех.поддержкой…
                                                              0
                                                              100% работает ТОЛЬКО с префиксами нейспейсов. Даже базовый opacity

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

                                                              И это никакие не неймспейсы, даже близко не лежат.
                                                            +1
                                                            Это временная реализация свойств, которая похожа то, что описано в спецификации CSS3, но не удовлетворяет всем требованиям спецификации. Со временем их заменяют оригинальные свойства без префиксов.
                                                              0
                                                              Нет ничего более постоянного, чем временное. CSS3 уже используют, пусть не так широко, но уже не только энтузиасты. А так как далеко не все обновляют браузеры, то тянется длинный шлейф версий работающих только с префиксом и быстро он не исчезнет — а ля ie6…
                                                                0
                                                                Ну а ждать долгие годы, пока окончательно не утвердят спецификацию и только потом начинать реализовывать свойство — это, пожалуй, еще хуже.
                                                              0
                                                              Не стоит забывать теория!=практика…
                                                              +17
                                                              …порассуждаем о том, зачем же нужен HTML. А нужен он для того, чтобы сделать разметку некой информации

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

                                                              А вообще — вброс профессиональный получился.

                                                              По мне, сколько бы ни было недостатков в новых семействах технологий, этот путь развития гораздо лучше, чем Flash-AIR-Silverlight-безумие. И ребятам из WHAT WG и W3C нужно ставить памятники.
                                                                –6
                                                                А чем вам не нравится Silverlight?
                                                                • UFO just landed and posted this here
                                                                    –7
                                                                    Аргументирую — 1 технология для веба с широким набором устройств.

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

                                                                    Странно, но мне тоже нет. Интерфейс должен быть заточен под конкретное устройство, т.е. каждый форм-фактор требует индивидуального подхода.

                                                                    ЗЫ. Silverlight — может нравится хотя бы тем, что на десктопе — это производительная (HTML5 даже рядом не валялся), бесплатная, удобная, кроссплатформенная технология как для десктопов, так и для веба. 90% ваших пользователей смогут использовать богатые возможности, остальным 10% можно скормить поделку на JS/HTML.

                                                                    Учите матчасть.
                                                                    • UFO just landed and posted this here
                                                                        –13
                                                                        Symbian — есть. WP7 — есть. Остальные подтянутся.

                                                                        На десктопе — Windows 90%, OSX остальные 10% (самые быстрые Опера и Хром — это 1% от этих 10%), о каком линуксе на десктопах вы говорили? Истого получаем, если нужен десктоп — берем Silverlight и голова не болит.

                                                                        Если нужны мобильники — берем SL для WP7/Nokia, остальным даем JS/HTML. Ну или мудрим что-нить нативное, полюбому лучше HTML5 будет.

                                                                        Таким образом, на десктопе 99% кроссплатформенность, на мобилах — ждем полгода.

                                                                        Может SL удобный? Блин, да HTML со браузером там рядом не валялся. Ембедим полностраничнще SL/oob приложение, забываем весь геморой с HTML/CSS/браузером. По правой кнопке свое меню, без всякого браузерного хлама.

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

                                                                        Проблемы с SEO, так робот.тхт никто не отменял, не помогает — RTFM.

                                                                        Бесплатная? Конечно, качаем VS.NET express edition. Или у вас Windows нет? Ааа, голодаете… На детях экономите, нехорошо…

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

                                                                        Весь мир в зависимости от Microsoft уже 25 лет и ничего, живет себе, пользуется, деньги зарабатывает.

                                                                        Откуда паранойя? Совковое прошлое?

                                                                        Избавьтесь от предрассудков насчет продукции Microsoft, никому вы не нужны со своей наркозависимостью.
                                                                        • UFO just landed and posted this here
                                                                            –7
                                                                            Не знаю, кто куда бежит, но седьмерка продается на ура.

                                                                            SL на десктопе установлен на 65% машин. (см. riastats.com)

                                                                            Установить SL плагин — не сложнее любого другого из сотни ваших браузерных плагинов.

                                                                            Избавляться от flash — это разумно, устаревшая технология. Но HTML5 нету даже на 65% десктопов и в ближайшие 2 года не будет (пока выйдет 9-ка, пока его все поставят).

                                                                            И никакого выбора — ДА!

                                                                            Выбор — это бред сивой кобылы. Лучше одна IDE, но отличная, чем 10 — но говёных. Лучше один язык — отличный, чем 10 — на любителя. Лучше один фреймворк, но сделанный с умом, чем куча третьесортного хлама.

                                                                            Посмотрите на iPhone — там есть выбор? Или нормальные нативные приложения сделаные на XCode (то еще фуфло), или поделки на HTML, которые и приложениями трудно назвать, веб-странички разве что.

                                                                            Откуда такая аллергия на Windows? Что есть такого полезного в (вписать по своему усмотрению), чего нет в Windows?

                                                                            Отзывы о WP7 — самые положительные. Проще iPhone — это даже лучше…
                                                                              +1
                                                                              SL на десктопе установлен на 65% маши

                                                                              Статистика — очень интересная штука, вот у меня номинально установлен Silverlight, но примеры с сайта MS я посмотреть не могу, просит обновления :)
                                                                              • UFO just landed and posted this here
                                                                                  +2
                                                                                  Зря спорите. Люди, капсулированные в мир MS, редко понимают смысл в других технологиях.
                                                                                  • UFO just landed and posted this here
                                                                                      0
                                                                                      Профессионалы веба не смогут работать с технологиями MS, так как там нужно или все переписать наново, или забыть про кастомизацию и понимание того, как же это все работает.
                                                                                  0
                                                                                  меньше слов – больше дела: сколько у тебя сайтов на Сильверлайте сделано? сколько они принесли денег? а сколько сейчас пользователей у WP7? сколько тебе денег принесли приложения написанные для WP7?
                                                                                +2
                                                                                У меня лицензионный Windows 7, и на нем нет Silverlight. И, скорее всего, никогда не будет. Как и у большинства. ;)
                                                                                  –2
                                                                                  У меня лицензионный Windows 7 и на нем уже есть Silverlight. Как у большинства :)
                                                                                    +1
                                                                                    Скрипач не нужен. :)

                                                                                    PS И много раз вам приходилось им пользоваться?
                                                                                    • UFO just landed and posted this here
                                                                                        0
                                                                                        IE9 требует обновления системы. Это не всегда по карману корпоративным клиентам. Домашние пользователи не всегда захотят переходить на более медленную OS ради одной программы. Быстрее всего будет заменен браузер на альтернативный.
                                                                                        • UFO just landed and posted this here
                                                                                            0
                                                                                            Корпоративные пользователи не перейдут быстро на IE9, а это невеселая новость для тех, кто разрабатывает продукты, ориентированные на корпоративный сектор.
                                                                                    0
                                                                                    Сколько корпоративных продуктов на SL вы знаете? Не поделок на коленках, а реальных корпоративных продуктов?
                                                                                      –3
                                                                                      Microsoft Office 2010. Мало?
                                                                                        0
                                                                                        «Сперва добейся»?
                                                                                        –1
                                                                                        WP7 — есть

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

                                                                                        OSX остальные 10%

                                                                                        Под OS X можно установить Silverlight, да, но, если я не путаю, то в стандарте он там толи не установлен, толи в комплекте дается старая версия. Сейчас я зашел в галерею примеров Silverlight на сайте MS и меня просят установить обновление плагина — далеко не самое элегантное решение. Устанавливать что-то дополнительное ради непонятно чего? Нет, спасибо.
                                                                                          +1
                                                                                          >Бесплатная? Конечно, качаем VS.NET express edition. Или у вас Windows нет? Ааа, голодаете… На детях экономите, нехорошо…

                                                                                          Смотрю на свой макбук по «нереально завышеной цене и переплатой за бренд» и не понимаю о чем вы. SL это Windows-only и разработка там тольео на Windows-only. (не нада тут про iOS SDK, CocoaTouch не претендует на то, что претендует SL) И разве express edition позволяет создавать коммерческие продукты? И зачем мне этот ваш виндовз?
                                                                                          >Symbian — есть. WP7 — есть. Остальные подтянутся.

                                                                                          Угу, сейчас все все бросят и будут делать.

                                                                                          p.s.
                                                                                          покормил :3
                                                                                          0
                                                                                          Перечисленные проблемы — это не проблемы Silverlight, а проблемы политики MS и сложившейся инфраструктуры. Как технология Silvelight гораздо продвинутее.
                                                                                            0
                                                                                            Symbian — нет, RIM — нет, Android — нет, Apple — нет.

                                                                                            Это не минусы технологии как таковой, а минусы политики MS.
                                                                                            Может она удобная? Тоже нет, в отличие от HTML5 это чуждый браузеру элемент со всеми вытекающими последствиями: фокус на странице и фокус на приложении разные, текст и там, и там одновременно не выделишь, по правой кнопке не будет меню браузера.
                                                                                            Удобство для разработчика? Проблемы с SEO и с той же чужеродностью.
                                                                                            А что, уже rich internet application, написанные на extjs (или как его теперь переименовали) с этим эффективно борются? Лично моё впечатление, что там с данным моментом не меньше граблей. Особенно радует пляска с бубном вокруг контекстного меню, которое в опере вообще никак нельзя переопределить, а нужно (ну очень нужно в каких-нибудь WYSIWYG-редакторах). И чего это хлопцы из W3C никак не придумают механизм для встраивания своих пунктов меню в контекстное меню «агента пользователя»?
                                                                                            Бесплатная? Нет, чтобы посмотреть надо купить Windows или переплачивать за Мак.

                                                                                            Дык, всё же документировано и стандартизировано. Никто не мешает взять и написать свою реализацию. Вон, чуваки из Novel замутили свою с блэк-джеком. Правда, мешает политика самих MS и политика других компаний в отношении продукции MS, ведь за еду никто не будет писать реализацию, а спонсировать не хотят. Кстати, сюда же и вопросы про удобство разработчика. Есть VS, очень хорошая но платная, есть SharpDevelop, которая недо-IDE (но всё равно, значительно удобнее, чем Eclipse/Netbeans/ещё-что-нибудь для JS). Никто не мешает написать свою IDE, как это сделано в случае с Java. Но ведь не пишут. А кто виноват? Может, хомячки, возглавляемые W3C, которые везде пихают свой любимый HTML+CSS+JS, и даже не пытаются смотреть по сторонам и делать мир лучше?
                                                                                              0
                                                                                              А бесплатная редакция VS чем вас не устраивает?
                                                                                        0
                                                                                        Тем, что это закрытый плагин к браузеру, одна из тупиковых ветвей развития интернета.
                                                                                          0
                                                                                          Где же он закрытый? А тупиковая весть развития «интернета» — это как раз веб в его нынешнем состоянии, ибо убог и по своим возможностям и жутко медлителен, и вообще, как бы не очень подходит для построения rich internet application, ибо по сути своей был придуман для описания гипертекста.
                                                                                          • UFO just landed and posted this here
                                                                                              0
                                                                                              Ну что же, у Silverlight очевидные преимущества перед HTML+CSS+JS. Это и производительность, и гораздо более мощный и выразительный язык, и, как следствие, лучшая поддержка со стороны IDE, и огромный функционал, доступный в .NET Framework. Например, видели WPF? Куда какому-нибудь Sencha до него по возможностям? Или ещё пример: 21 век на дворе, а W3C только начинает возиться с web sockets, когда в принципе и Java-апплеты, и Flash и Silverlight могут нормально общаться с сервером. Ну пройдёт ещё 10 лет и устареет последний браузер, не поддерживающий web sockets. А в «закрытых плагинах к браузеру» всё реализовано уже давно, но не кошерноЪ, как говорят мужики.
                                                                                              • UFO just landed and posted this here
                                                                                                  0
                                                                                                  Преимущества кратко озвучены. Подробнее см. на просторах интернета. А что значит «сильверлайта нет»? Сокеты нужны в RIA. Собтвенно, мне всегда казалось, что сильверлайт для них и предназначен. Или я ошибался?

                                                                                                  Я тут как раз воюю с противниками «закрытых плагинов к браузеру». Ну для любителей открытых плагинов к браузеру есть Java Applets. А так, ну да, есть во флеше аналог web sockets, уже давно работающий на старых браузерах. Ну есть он и в сильверлайте. Только вот сильверлайт технически попродвинутее будет. А так да на безрыбье HTML5 и рак Flash — рыба.

                                                                                                  На современных машинах? А ничего, что есть немалый такой контингент пользователей, юзающих IE6 и IE7, который хвалёный HTML5 не поддерживают? И они даже не могут посмотреть видео/послушать музыку без «закрытых плагинов для браузера». То же и с сокетами. Пока пошевелится w3c, пока разработчики наваяют/протестируют, пока все перейдут на IE9… Вот вам и прогресс, вот вам и развитие интернета.
                                                                                                  • UFO just landed and posted this here
                                                                                                      0
                                                                                                      Увы, это не те преимущества, которые нужны.

                                                                                                      А какие нужны? Работа на всех устройствах? Ну так и HTML4 прекрасно работает на многих устройствах. Зачем нам ещё какие-то HTML5 и плагины?
                                                                                                      Плагины к браузеру сами по себе ущербны своей чужеродностью, небезопасностью

                                                                                                      Что значит «чужеродность» и чем она ущербна? Дыры в безопасности могут быть и в браузере.
                                                                                                      IE6 и IE7 — это старьё и занимает от силы треть. Силверлайта нет на гораздо большем числе машин.

                                                                                                      Сильверлайт реализован в виде плагина, и его потому нетрудно скачать и установить, будучи даже полным профаном (в последнее время подобная операция делается в два клика). При этом пользователь кликнет куда надо, ибо у него будет красоваться сообщение c просьбой установить. Установка браузера для человека неискушённого — задача более нетривиальная.
                                                                                                      HTML уже есть на телефонах и любых компьютерах в более-менее приличном виде.

                                                                                                      А это «более-менее приличный вид» — это уровень цветных буковок. К тому времени, как в нём появится функционал, имеющийся в Silverlight, или хотя бы в JavaFX и Flash, может да, Silverlight успеет достаточно распространиться.
                                                                                                      • UFO just landed and posted this here
                                                                                        +2
                                                                                        Вброс отличный. Хабраюзеры плюсуют просто за вброс, даже не думая о том, как, например, поместить contenteditable во (внимание!) DOM, как это предлагает автор. DOM, которая про отображение ничего не знает.

                                                                                        Несуразностей вообще полная статья, но фраза «где инновации, зачем нам новый стандарт, когда он уже устарел» действует на молодых людей как тряпка на быка. Ведь они то знают — все что было сделано до того, как он об этом узнал — устарело ;)
                                                                                          –1
                                                                                          А что, собственно, вас смущает? Давайте говорить предметно, и без вырезания отдельных фраз.
                                                                                            +3
                                                                                            Меня смущает ваша невнятная аргументация, несвязность текста и позиция «Да несогласен я!» (- Простите, с Энгельсом или Каутским? — Да с обоими! (с) Собачье сердце). Аргументация гиперэмоциональна и несодержательна. Приходится еле-еле догадываться что вы там хотели сказать.
                                                                                            у нас есть четыре блока, которые, в зависимости от ширины контента или окна браузера, должны выстраиваться друг за другом, и занимать или одну строку, или две, три, четыре строчки. Обычные float'ы. Все, коллапс.

                                                                                            Вы описали стандартный float:left и совершенно не объяснили толком, что там за коллапс у вас с ними возник. И только путем долгого вчитывания стало понятно, что вы либо торопились, либо некорректно объяснили, что хотели не просто float:left, а интеллектуальный флоат (да и это только мои догадки). Но зато КОЛЛАПС не забыли!

                                                                                            От разметки тут же прыгаете к дизайну. Я верю, что вам очень надо было вкрутить CSS3 к статье, но это не повод обсирать хорошие идея с веб-формами. Как бы по-вашему рынок не требовал кастомных чекбоксов, стандартный элемент «календарь» он требует на два порядка сильнее.

                                                                                            Да и с del ins — совершенно очевидно зачем были сделаны эти теги. Даже на Хабре постоянно можно увидеть надпись в топике update: спасибо за карму, перенес в тематический блог. А вы говорите что это надо какому-то там мифическому васе пол-сотых-процента. Стандарт описания изменений user-generated контента напрашивается со всей очевидностью.

                                                                                            Из всей статьи относительно полно и беспристрастно лишь абзац с точкой отсчёта (идея действительно не нова), тем не менее совершенно не ясно зачем на этом фоне делать истерику. Или по-вашему все так просто — ха, перевернём ось икс и ура? Не думая как изменится поведение верстки. Подумайте об одном float:left.
                                                                                              –1
                                                                                              Вы описали стандартный float:left и совершенно не объяснили толком, что там за коллапс у вас с ними возник

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

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

                                                                                              Веб-формы нужны, важны, и моя основная мысль была не про это. Вот есть замечательный атрибут placeholder. Идея — супер. А как его стилизовать? Или второй вопрос, что делает progress элемент в формах? Его хоть кто-то сможет заполнить и отправить на сервер? Почему нельзя было сделать option обычным block-level элементом, чтобы можно было создавать свои структуры, например текст + краткое описание? Где combo-box, так называемый, который сейчас все реализуют вручную?

                                                                                              Да и с del ins — совершенно очевидно зачем были сделаны эти теги

                                                                                              Да, очевидно. Но их эффект стремится к нулю. Многие теги были сделаны с явными целями, но это не изменяет их полезность.

                                                                                              Я новичок тут, не привык еще и не освоился.
                                                                                                0
                                                                                                Послушайте уважаемый. Вы там можете себе вообразить что угодно, но вы объясняете непонятно, говорю вам как пользователь вашего контента.
                                                                                                Темплейты отображения помогут создать некую ячеиструю структуру, которая позволит дизайнерам расставлять блоки в

                                                                                                1. почему
                                                                                                2. этого
                                                                                                3. нет
                                                                                                4. в статье?

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

                                                                                                Я новичок тут, не привык еще и не освоился.

                                                                                                При чем тут это? Объясняйте свою позицию с толком и расстановкой. Просто непонятно ничего и сумбурно. Ясно что есть критика, а в чем суть критики — ускользает как песок сквозь пальцы.

                                                                                                Вот читаю я
                                                                                                вообще непонятен механизм перестановки блоков в DOM-дереве (динамика и приложения), когда блок имеет строго указанную позицию в отображении

                                                                                                И не понимаю как связана позиция в отображении и позиция в дом дереве. И посл о непонятности механизма лично для меня остается темнотой.

                                                                                                Может я, конечно, туплю, из-за того что сижу на море в отпуске, но вот ответьте на последний этот вопрос: как связана позиция в отображении и позиция в дом дереве? Учитывая то, что в дом дереве блок может быть как в начале так и в конце, а в отображении быть тоже где угодно.
                                                                                                  +1
                                                                                                  1. почему этого нет в статье?
                                                                                                  Вы придумали себе какой-то там термин и решили что все его знают? Почему я должен угадывать?

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

                                                                                                  И не понимаю как связана позиция в отображении и позиция в дом дереве. И посл о непонятности механизма лично для меня остается темнотой.

                                                                                                  В текущей спецификации CSS2 есть только ряд элементов, которые выпадают из общего потока (normal flow). Для элементов, которые находятся в потоке, порядок их отображения ровно такой, как и в тексте документа. При применении технологии темплейтов отображения, которая описана в CSS3, блоку можно присваивать позицию в некой заведомо составленной сетке, где он будет отображаться.
                                                                                                  Примеры можно посмотреть тут www.w3.org/TR/2010/WD-css3-layout-20100429/

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

                                                                                                  Так понятнее?

                                                                                                    0
                                                                                                    Да. Спасибо за ответ и время. Так понятнее. Мне следовало сразу понять, что расчет шел на тех, кто серьезно знаком со спеками.
                                                                                                      0
                                                                                                      p.s. Я давних web-разработчик. Поэтому вопросы мои не на пустом месте. Мне действительно было непонятно и интересно в чем суть критики.

                                                                                                      Вам не кажется что темплейты смешивают DOM и CSS в кучу? Или вы считаете что так было бы лучше?
                                                                                                        0
                                                                                                        Три технологии уже давно тесно завязаны друг на друга. Чистый HTML почти никому не интересен, интересен тот продукт, который при помощи него можно сделать. w3c декларировала при старте разработки HTML5, что основное внимание будет уделено веб-приложениям. Но на практике оказывается все далеко не так. Добавили фактически то, что уже используется на рынке и реализовано в браузерах. А принципиально нового почти ничего не сделали.

                                                                                                        Темплейты в данном виде в спецификации — чистое статическое отображение. Веб-приложения требуют интерактива и динамики, расположение элементов должно быть контроллируемым. А этого нет. Я, лично, ожидал большего.
                                                                                                      • UFO just landed and posted this here
                                                                                                          0
                                                                                                          Это не решает проблему. Помимо изменений позиции в DOM дереве придется дополнительно еще и контроллировать слоты. А не всегда это получится.
                                                                                                          • UFO just landed and posted this here
                                                                                                              0
                                                                                                              Разговор как раз не странный, а в духе данной статьи. Да, я согласен, что для каждой задачи нужно использовать подходящую технологию. Вернее старый добрый CSS2.1 :)
                                                                                                          0
                                                                                                          Простите, что лезу в середину дискуссии, но уж очень интересно:
                                                                                                          Я так понимаю, что при использовании вот этих самых темплейтов отображения, если мы хотим, скажем, взять элемент, перенести его в другое место и дропнуть в другое место, то рассчитанный под нынешние реалии скрипт D'n'D не справится, потому что если элемент был, скажем first-child, а стал nth-child, это ничего не изменит, потому что ему четко задано расположение?
                                                                                                          Но тогда вроде бы проблема решается простейшим апдейтом данного скрипта с тем, чтобы он не только положение элемента в DOM менял, но и слегка правил его css (скажем, другой класс присваивал ему и соседям). В чем сложность? Или я не так все понял?
                                                                                                            0
                                                                                                            Все верно. Сложность в том, что вместо одного простого действия с предсказуемым результатом, вам придется делать два действия с непредсказуемым результатом. Почему непредсказуемый? У вас строго размечена страница. Но вам нужно перенести это блок, скажем, между двумя позициями. В какой слот нужно переносить элемент? Создавать на лету слоты и новый темплейт? Это не облегчение работы, а серьезное усложнение.
                                                                                                              +1
                                                                                                              невозможность в пятнашках переложить на свободное место любую фишку — это серьёзное усложнение :—)

                                                                                                              template layout — это возможность, а не требование. не надо использовать его в ситуациях, для которых он не предназначен. откуда в приложении, использующем template layout, возможность вставки элемента между позициями layout'a?
                                                                                                                0
                                                                                                                Напомню, что frames тоже были возмножностью, а не требованием. И что потом получилось?
                                                                                              +4
                                                                                              Это просто замечательно, что появляется куча специализированных полей ввода. И не стоит сетовать, что у input[type=number] не задашь рисунок на кнопках — не надо.
                                                                                              Не понимаю, откуда такая мания менять вид стандартных элементов управления. Хром, Опера и Файрфокс рисуют замечательные поля ввода, да еще их вид и от темы оформления системы зависит. Старайтесь не трогать то, что уже отлично сделано до вас. На Хабре был пост о том, как дизайнеры меняют цвет в инпутах на веселенький синий, а потом у всех людей с темным UI этот синий на темном фоне не виден.
                                                                                              В принципе, это относится не только к оформлению веб-страниц, но и написанию UI.
                                                                                              PS. Я очень рад, что шаловливые ручки дизайнеров редко доходят до чекбоксов, потому что в Linux Mint очень красивые чекбоксы.
                                                                                                +2
                                                                                                редактируемость контента — совершенно семантическое свойство этого самого контента, поэтому contentEditable самое место в html. возможность таскать контент по странице — это аспект поведения приложения, поэтому draggable место не в html, а в js.
                                                                                                  –1
                                                                                                  Не согласен. Редактируемость является одним из поведенческих свойств контента и зависит от медиа-типа и устройства вывода. Почему разбивку страниц для принтера вынесли в CSS, а редактирование занесли в HTML? Это свойство не влияет на семантику ни коим образом. В CSS3 начали вводить понятие behavior, но еще не до конца сформировалось понимание того, что это должно быть. Например, свойство формы disabled считаю тоже чистым поведенческим свойством, наравне с :hover.
                                                                                                    0
                                                                                                    разбивка на страницы — это представление.
                                                                                                    изменяемость контента — это логика самого содержания, это семантика.
                                                                                                    конкретные механизмы изменения контента — это поведение, зависящее от медиа-типа и устройства.

                                                                                                    два одинаковых документа, в первом из которых некий фрагмент редактируем, а во втором — нет, — это разные документы. семантически разные.
                                                                                                      0
                                                                                                      Изменяемость контента — это поведение, а не содержание. Это надстройка над семантикой, но не семантика.

                                                                                                      Семантика (фр. sémantique от др.-греч. σημαντικός — обозначающий), также семасиология — наука о понимании (значении) определённых знаков, последовательностей символов и других условных обозначений

                                                                                                      Изменяемость контента не изменяет смысл самого тега, а меняет всего лишь его поведение на определенном типе устройств. Акроним как был акронимом, так и останется, суть его не изменится вне зависимости от того, может его редактировать пользователь, или нет.
                                                                                                        0
                                                                                                        …именно поэтому contentEditable — это атрибут, а не тэг.

                                                                                                        скажите, в чём, на ваш взгляд, семантическая разница между span contentEditable=«true» и input? или между div contentEditable=«true» и textarea?
                                                                                                          0
                                                                                                          А я и не говорил, что он должен быть тегом. Ему самое место в CSS.

                                                                                                          Разница очень большая. TEXTAREA и INPUT имеют свой вполне четкий смысл. А SPAN и DIV безлики по задумке авторов. Одинаковость их поведения не значит семантическую одинаковость.

                                                                                                          Вот скажите, это нормальный код?

                                                                                                          b { font-weight: normal; font-style: italic }
                                                                                                          i { font-weight: bold; font-style: normal }

                                                                                                  –2
                                                                                                  люблю топики, где большинство комментариев длинные и обстоятельные:)
                                                                                                  сразу видно — собрались люди грамотные, разбирающиеся:)
                                                                                                    0
                                                                                                    А я жду, когда в браузеры научаться растягивать фоновое изображение, как это делает HTMLayout (5 пункт). Одним свойством можно разом заменить и скруглённые углы, и тени, и оформление границ.
                                                                                                      0
                                                                                                      Не стоит заменять, стоит дополнять. Если вам понадобится бокс с закругленными углами, то нужно будет картинку рисовать. А если понадобится поиграться цветом, то придется снова же изменять картинку. Обычный бордер удобнее. Но мысль не лишена смысла, так как это позволит спокойно создавать множественные эффекты и довести технологию текстурирования до ума.
                                                                                                        0
                                                                                                        В том-то и дело, что выше упомянутые свойства хороши по отдельности. А растяжением фонового изображения можно добиться такого оформления, что обзавидуется даже матёрый дизайнер )

                                                                                                        «Замену» я подразумевал в применении, а не ради исключения имеющихся свойств.

                                                                                                        HTMLayout ещё много чего может. Когда я делал верстку под него, было ощущение, что мне развязали руки, до этого момента связанные. Не хватало только Javascript'а в нём.
                                                                                                      • UFO just landed and posted this here
                                                                                                          0
                                                                                                          Но не для фона. Непонятно, почему для фона такое не сделали.
                                                                                                        –1
                                                                                                        На пост главы W3C выдвигаю кандидатуру автора!
                                                                                                          0
                                                                                                          Не хотите переехать в Симферополь и работать в Яндексе разработчиком интерфейсов?
                                                                                                            0
                                                                                                            Спасибо за предложение, но у меня есть отличное место работы, на котором я делаю то, что мне нравится.
                                                                                                              0
                                                                                                              совратитель х) распеделённые команды всё-таки не рулят?
                                                                                                                0
                                                                                                                Нет. Передача знаний по воздуху наиболее эфективна.
                                                                                                                  +1
                                                                                                                  между нами же есть трубопровод ;-) вдуваете знания там, выдуваете тут %-) и неужели в москве/питере нет толковых аккумуляторов симферопольских знаний? х)
                                                                                                                    0
                                                                                                                    их и в Симфи-то не много =)

                                                                                                            Only users with full accounts can post comments. Log in, please.