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

Денис Зайцев:

А мне вот Андрей заявил вчера: знание css-верстки, говорите? Поставил Dreamweaver и все! =)

Иван Сагалаев:

Ну это уже вопрос целеполагания :-). Если “и все” означает “сделать, чтобы показывалось” — то Dreamweaver’а вполне хватит. Раздумывать на версткой и структурой стоит, когда от сайта хочется получить большего.

pitiful anonymous:

Иван, а большего - это чего? Все в последнее время говорят о семантической верстке, но по сути - зачем это? Чем для поискового бота различаются smth и smth + span {color: red; background: inherit} ? Или здесь есть какая-то разница для пользователя, который такую страницу просматривать будет? В общем: какая разница, как верстать, если основным потребителям контента (пользователям и поисковикам) нет особой разницы? (Конечно, я не рассматриваю совсем клинические случаи)

Иван Сагалаев:

Большего — это прежде всего структурный HTML. Не просто “дивная верстка”, получающаяся заменой всех тегов на <div class="">, а именно разделение структуры и оформления. Именно эту теорию я излагал в первой статье учебника, плюсы там не только (и не столько) для поисковиков. После части про верстку CSS’ом, через одну статью, я напишу про то, чем на практике различается CSS-верстка от “дивной”.

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

Иван Сагалаев:

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

Это, кстати, не только вопрос структурного HTML’а. Когда на своей прошлой работе попытался продвинуть начальству идею заворачинвания сайта в мобильник, мне тут же сказали: “это невозможно, потому что туда не влезут наши банеры”. Вот, где основная проблема-то :-)

pitiful anonymous:

Понятно, будем ждать :) Впрочем, лично мне удобнее смотреть на код <font face=red> и сразу понимать, какого цвета будет данный инлайн-элемент, чем лезть в css и смотреть на дерево. А определять на каждый чих классы как-то несподручно… Ладно, будем ждать статью :)

Иван Сагалаев:

Так я ж совершенно не иронизирую, когда говорю, что если надо, чтобы просто показывалось, это нормально. HTML 3.2 — язык визуальной верстки страниц, и он никуда не денется. Если вам не нужны те плюсы, которые предлагает HTML 4.01, и вы хорошо владеете другим инструментом, пользуйтесь им. Или Flash’ем. Или даже PDF’ом. Инструмент должен подходить под задачу, а модные тенденции — это уже потом :-).

Я не затрагиваю этого вопроса в “Учебнике”, потому что он просто весь целиком посвящен 4-му структурному HTML’у. Хотя, может, и надо было…

pitiful anonymous:

А по поводу существующего веба Вы сами очень правильно говорили: не нужны никому устройства, не умеющие просматривать существующий веб. И пока создание сайта так дешево (а если самому, так и вовсе бесплатно), никакого улучшения не предвидится. Да даже если и дорого - Вы видели код, который пишет студия Лебедева?:) А стремление к следованию стандартам… Веб-сообщество стремится, но я не думаю, что заказчики ходят по блогам веб-девелоперов :)

Иван Сагалаев:

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

Уходя из аллегорий, я думаю, это будет развиваться так:

  1. Сейчас Опера и Gecko предпринимают титанические усилия для того, чтобы программно заставить текущие сайты влезать в портативный экран (это вот этот шаг с миллионом куриц).
  2. Это должно слегка развить спрос, чтобы интернетом с мобильников стало пользоваться заметное число клиентов, чтобы веб-авторы стали обращать на них внимание.
  3. А поскольку автоматическое впихивание живых сайтов местами всегда будет выглядеть кривовато, то веб-авторы захочется это улучшить (ведь уже будет дял кого).
  4. И вот тогда они начнут искать и найдут такую вещь, как “мобильный CSS”, которым они смогут поскрывать лишние банеры, расставить колонки в одну длинную колбасу и т.д.

Мне думается, что процесс уже пошел.

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

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

Комментарии: 6

  1. Александр Вольф

    Студия Лебедева есть инструмент изъятия денег :) И тут уже было справедливо замечено, что Лебедев и К не особо-то и гонятся за стандартами. Тут я не могу удержаться от шпильки - они тормозят приход стандартов в жизнь (такое мнение у меня сложилось о них после того, как прочитал у них заметку о DOCTYPE, в которой они сокрушались на "уродом" IE5/mac, который первый начал поддерживать стандарты).

  2. pitiful anonymous

    По поводу визуальной разметки и плюсов от html401 (я так понимаю, под плюсами Вы, Иван, понимаете возможность отделить представление от содержимого):
    Я не говорю о том, что не умею отделять, я говорю о том, что мне это видится неудобным! И, кстати, описал вполне себе реальную ситуацию, когда визуальная разметка удобна. Можно, конечно же, заменить мой font color=red на span class="red", или даже инлайн стиль определить, но, извините, это чрезмерно :) Зачем делать лишнее? Ну да ладно, не о том речь. А речь о том, что стандарты html и css слишком уж стоят далеко друг от друга, так мне видится. Хочется чистого хтмл? Строим сложные css-конструкции с наследованием и разными весами у свойств, с различными моделями позиционирования и прочим. Но тогда прежде чем сесть поправить background у маленькой стрелочки в grid'e, приходится полчаса парситьпонимать всю эту структуру. Да, можно понаписать тучу комментариев, но ведь не зря говорят, что хороший код всегда является self-documenting. И в другую крайность тоже не получится броситься комфортно - сколько сейчас в сети документов с 4 и более уровнями вложенности оформительских тегов? Много. Это усложняет задачу внесения изменений ровно в той же степени, как и сложное дерево в css.
    Иван, Вы говорите, что при разработке CSS авторы проигнорировали вертикальное позиционирование блоков потому, что при отображении документа во время загрузки нельзя точно вычислить, какая будет высота. И Вы явно отрицательно относитесь к табличным макетам, в которых все прыгает и скачет.
    Но тогда что получается? Прогрессу подходу отделения представления от содержимого нет хода? Вот взять тот же xhtml1.1, в котором большинство оформительских тегов отсутствует в DTD. Ведь, насколько я понимаю, документ не может быть признан well-formed xml до тех пор, пока не загрузится целиком? Стало быть, ни о каком incremental rendering речи и идти не может? Так я дважды подумаю, прежде чем пользователю отдавать страницу, которую он гарантированно не сможет прочитать до тех пор, пока целиком не загрузит, пусть она хоть десять раз будет по спецификации. Так это я все к тому, что хаос и разброд либо в моей голове, либо в голове разработчиков спецификаций. Надеюсь, что все-таки хаос в голове моей. Иначе будущее веба с такими спецификациями видится мне не таким уж радужным.

  3. Иван Сагалаев

    Может, лучше "на ты"? :-)

    По поводу визуальной разметки и плюсов от html401 (я так понимаю, под плюсами Вы, Иван, понимаете возможность отделить представление от содержимого):
    Я не говорю о том, что не умею отделять, я говорю о том, что мне это видится неудобным! И, кстати, описал вполне себе реальную ситуацию, когда визуальная разметка удобна. Можно, конечно же, заменить мой font color=red на span class=”red”, или даже инлайн стиль определить, но, извините, это чрезмерно :)

    Если хочется написать color=red или class="red", значит это уже не отделение оформления от содержимого. Красные буквы — это аспект того, как это будет отображаться, а не того, что этот элемент что-то представляет собой в структуре.

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

    Хочется чистого хтмл? Строим сложные css-конструкции с наследованием и разными весами у свойств, с различными моделями позиционирования и прочим. Но тогда прежде чем сесть поправить background у маленькой стрелочки в grid’e, приходится полчаса парситьпонимать всю эту структуру.

    Это обычно признак просто плохо составленного CSS. Серьезно. В нормальном стилевом файле, где id и class'ы выдаются не наобум, а по сути, где используется каскад, и где файл разложен на смысловые части, проблем с поиском одного нужного правила не возникает.

    Однако я соглашусь, что это сложно и требует практики.

    Но тогда что получается? Прогрессу подходу отделения представления от содержимого нет хода? Вот взять тот же xhtml1.1, в котором большинство оформительских тегов отсутствует в DTD

    Кстати, XHTML (и вообще XML) — это не единственный путь прогресса. Тот же HTML 5 определяет два равнозначных синтаксиса: XML'ный и HTML-совместимый.

    Ведь, насколько я понимаю, документ не может быть признан well-formed xml до тех пор, пока не загрузится целиком? Стало быть, ни о каком incremental rendering речи и идти не может?

    Не совсем, есть одна тонкость. XML действительно требует, чтобы клиент немедленно остановил парсинг, если встретит ошибку well-formed'ности. Но он не запрещает параллельно обрабатывать контент до тех пор, пока ошибка не встретилась. Больше того, один из самых распространенных методов парсинга (SAX) делает именно так: выдает клиенту события типа "элемент такой-то начался", "элемент такой-то кончился", и клиент обрабатывает все по ходу.

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

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

  4. pitiful anonymous

    Может, лучше “на ты”? :-)

    Хорошо :) Просто привык называть старших людей на "Вы" :)

    Если хочется написать color=red или class="red", значит это уже не отделение оформления от содержимого. Красные буквы — это аспект того, как это будет отображаться, а не того, что этот элемент что-то представляет собой в структуре.

    Я это прекрасно понимаю. Иван, я наверное неточно выразился - времени было немного, а написать хотелось побольше :) Я говорю о том, что мне кажется неудобным отделять оформление от содержимого. Надоело видеть абстрактный html, приправленный кое-где id (для чего? ведь частенько эти id кроме как для того, чтобы за них "зацепиться" в css, и не нужны более нигде) и иногда className'ами (которых вообще по большому счету не должно быть, раз уж мы хотим отделять содержимое от представления). Возможно, здесь дело в отсутствии грамотной среды разработчика, которая позволяла бы визуально ходить по DOM (DOM Explorer в IE/FF предоставляют удобные интерфейсы, но не предоставляют функционала редактора, к сожалению) и применять (опять же визуально) к конкретному элементу конкретное правило. Нужен цвет - пожалуйста, выбираем нужный объект, сопоставляем ему в color picker'e цвет и - вуаля - объект покрашен :). Или выбираем объект, визуально его утягиваем до требуемых размеров, и если редактор "видит", что подходит модель поплавка, он использует ее. И если бы такой редактор существовал, то проблема отделения кода от правил визуализации была бы решена. Но такой редактор не может существовать по множеству причин. Хотя бы потому, что не всегда возможно "указать" на объект в DOM посредством css без того, чтобы пришлось "зацепляться" о какой-то объект с id/className или выстраивания некоторой иерархии. А когда у элемента несколько детей, так и вообще кавардак, ну ладно там first/last-child, но когда еще появится css3 с замечательным nth-child? А самое главное, когда он начнет поддерживаться в IE? С приходом IE8? А вопрос с хаками и прочей ерундой? Это же вообще нонсенс! Иван, я не знаю, как у тебя, но у меня css ассоциируется с ассемблером - такой же на первый взгляд неявный и непонятный. Да, я согласен, можно разобраться. Можно код форматировать отступами, показывая уровни наследования, благо хоть css позволяет не выстраивать всю ветвь иерархии и умеет сам находить необходимый элемент в области видимости, заданной основным элементом правила. Я только "за" развитие css, только "за" развитие веб-технологий, постоянно трачу на изучение всех этих вещей много времени, но после красивой java, которая всей своей сутью "подводит" программиста к грамотному ООП, css, который был задуман с наметкой на ООП, кажется совершенно неуклюжим. Почему за основу нельзя было взять что-то уже проработанное? Эх, все равно сумбурно получается. Надо будет собраться, выделить как-нибудь пару часов и структурированно изложить свои мысли. Про сочленение js/css я вообще молчу! Раз уж мы работаем с одним и тем же DOM'ом, неужели нельзя было скооперироваться и разработать удобное и единое целое? В Microsoft, видимо, имели сходное с моим мнение, оттого все их htc да expression'ы. Microsoft вообще молодцы в плане веб-разработки, на текущий момент они представляют наиболее полную и серьезную платформу для веб-приложений. Да что там говорить, чтобы понять и реализовать xmlhttprequest, у FF потребовалось ушло года, у Оперы больше шести. Про MIDAS я вообще молчу, его в FF недавно стали реализовывать, а уж в Опере вообще не планируют. Слишком трудно, видимо. Ну да ладно, это я отвлекся.

    Это обычно признак просто плохо составленного CSS. Серьезно. В нормальном стилевом файле, где id и class’ы выдаются не наобум, а по сути, где используется каскад, и где файл разложен на смысловые части, проблем с поиском одного нужного правила не возникает.

    А мне и идея разделять правила по типам не понравилась :) Доколе делить-то будем? Может, все-таки производителям спецификаций стоит придумать нечто цельное?

    Однако я соглашусь, что это сложно и требует практики.

    Иван, все сложное можно понять. Вопрос в другом - есть ли выгода от этого. Веб стал таким популярным за тот малый промежуток, который есть между "выходом в сеть" и "публикацией в сети". И если прогресс будет идти не по принципу упрощения (как в программировании), соответственно, цена разработки новыми технологиями будет выше, стало быть, контента в сети меньше. Пока что веб развивается, но сайтов, идущих в ногу с прогрессом, очень мало. Грамотно шагающих - единицы. А таких, какими я бы хотел видеть сайты - нет. Даже спецификаций таких нет :) С единой структурой, где каждый элемент является объектом, имеющим свойства, собственные события и уникальное поведение. Пока что все это раскидано по html/js/css, и я не вижу ничего хорошего в том, что для освоения одной техники приходится изучать три технологии и их странное взаимодействие. А когда нет грамотной и продуманной спецификации, появляется разброд и шатание с реализацией. Тут нужен, как выражается мой друг, флагман рынка. Пусть это будет революционно новый браузер со встроенной IDE и каким-нибудь костылем, написанном на js для обратной совместимости с текущим css/js/DOM model вебом и симпатичной кнопочкой навроде Гекковской "get firefox" :)

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

    Спасибо за разъяснения по поводу XML! Но однако, я слышал, что в FF не собираются избавляться от этого :)

  5. Просто случайный читатель вашего блога

    А почему не упомянут NetFront (где про инет для кпк пишете)?
    Сейчас Опера и Gecko предпринимают титанические усилия для того, чтобы программно заставить текущие сайты влезать в портативный экран (это вот этот шаг с миллионом куриц).
    Браузер NetFront - один из популярнейших для PDA (Palm, Pocket, Symbian, MS Smartphone). В большинство кпк он предустановлен, там же, где не предустановлен - ялвятеся одной из bestselling программ (не только браузеров, рейтинг продаж можно примерно увидеть на pocketgear).

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

    Про Mozilla - скорее, как не надо делать (ну если изначально не предполагалось под пда, то потом сложно ведь будет). Почти полтора года портируют (а с какой скоростью ACCESS добавляла поддержку новых устройств в NetFront!), и даже на Pocket'ах нормальной версии нет. А та пре-альфа или пре-бета, что есть - 8 Мб (!) .exe и не выполняет даже элементарного (валится чуть что).
    Кстати, под Palm ни Оперы, ни Мозиллы нет, и не обещали.

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

    Сайты, где большая целевая аудитория - пользtable-tr-td ователи кпк, либо имеет отдельную версию (таких меньшинство), либо у них все в таблице, и вытянется в колонку (см. ниже). На баннеры там ограничения (длинных они не берут).
    И вот тогда они начнут искать и найдут такую вещь, как “мобильный CSS”, которым они смогут поскрывать лишние банеры, расставить колонки в одну длинную колбасу и т.д.
    Если вы про колонки из таблиц (table-tr-td), то NetFront уже давно умеет вытягивать колонки из таблицы и делать "одну длинную колбасу". Делает это (например на Palm) на 320х320 (и на 160х160 Treo 600) и меньших экранах, на 480х320 и более показывает таблицу как она есть (если 3 колонки, то и будет 3, возможно прокрутку добавит).
    Делается это автоматически (независимо, есть ли css или вобще никаких стилей не задано) для любой таблицы.

  6. hidded

    А почему не упомянут NetFront?

    Главный камень в огород этого браузера: он «кладёт» на декларации о существовании css для handheld-устройств, т.е. он принципиально отказывается видетьто, что ему приготовлено, и начинает «извращаться»…

    автоматически (независимо, есть ли css или вобще никаких стилей не задано) для любой таблицы.

    …делая это довольно криво.

Добавить комментарий