Pull to refresh

Comments 515

Ничего не понимаю в хтмле, но диалоговые окна/вертикальные закладки в первых версиях OS/2 были прекрасны.
А еще интерфейс в старинной OS/2 требовал на порядки меньше ресурсов CPU и памяти.
Современные технологии построения интерфейсов всегда успевают за железом. Если железо стало работать быстрее, то сделаем сложную технологию интерфейсов, которая заставит его тормозить.
UFO just landed and posted this here
По сравнению с html очевидно.
Могу привести пример: HTML диалоги в Visual Studio. Типа AddEvent Handler, Add Member Variable (C++). Нечто глючное и тормозящее, время от времени вылетающее и вешающее саму студию (хотя возможно там тормозят не сами диалоги а то что до них, но не суть). Самое главное — непонятно ради чего все это.

Сама идея документов, описываемых в простом текстовом формате с иерархическими тегами (xml) весьма не плоха. Взять тот же fb2 — «чистая разметка без форматирования» — отличный формат. Плохо все то, что конкретно в вебе вокруг html действительно наслоилось много лишнего.
UFO just landed and posted this here
UFO just landed and posted this here
> Взять тот же fb2 — «чистая разметка без форматирования»
О да. Когда про HTML5 говорили что наконец-то начался «семантический веб», беглого взгляда на него хватило чтоб понять, что в этом смысле ему далеко до казалось бы нестандартного и «доморощенного» формата FB2, и что W3C вместо готового результата выдали очередной неудобоваримый полуфабрикат.
UFO just landed and posted this here
Я бы сказал, что сейчас они еще более полезны. У меня все основные вертиклаьными сделаны…
У меня, например, с одного стороны панель задач, с другой — вкладки браузера, так что ничего избыточного. Главное — за пользователя не решать.
Кстати там стандартный контрол поддерживал и вертикальные и горизонтальные закладки одновременно — в рамках одного блокнота, причем разные страницы вертикальной развертки могли, естественно, иметь свои собственные горизонтальные закладки.
Меня они абсолютно не впечатляют. Особенно толстая кипа «страниц».
Если б все было так просто, профессии «Верстальщик» не существовало бы.
Вы намекаете, что все это усложнение с css3 и html это заговор верстальщиков, боящихся потерять свою нужность?:)
Скорее это от того, что стандарт разрабатывали верстальщики или люди, которые напрямую слушали верстальщиков. :) И получилось по принципу Форда, который сказал, что если бы он спросил потребителя что тому нужно, то тот ответил бы, что нужна всего лишь более быстрая лошадь.
Скорее всего из-за того что браузеры до настоящего времени эти стандарты реализовывали криво и вообще забивали на них, отсюда и пошли шаманства когда в стандарте написано что отсутп работает так а в ie он работает иначе.
Главноая проблема html css в том что код написанный одинаково работает по разному в разных браузерах.
UFO just landed and posted this here
Скорее «Верстальщики» занимались бы своим делом и были бы на порядок производительны при:
— при наличии разумного языка разметки
— мощных средств визуализации (включая анимацию и 3D)
— поддержки связывания с внешним источником данных (шаблонизация и binding)
— удобного инструмента для верстки и отображения результата на лету
(sarcasm)Поздравляю, вы изобрели Флешь :)(/sarcasm)
UFO just landed and posted this here
Только не нужно забывать о том, что текстовая HTML/CSS верстка динамична в отличие от результата выдаваемого редактором. Даже самую простенькую анимацию интерфейса в визуальном редакторе делать тот еще геморрой, а на CSS3 это элементарно. Ну и столб из изменяющихся по высоте и количеству блоков с элементами управления тоже не так легко сделать в большинстве таких редакторов. Да и представьте, сколько мышекликанья потребуется, чтобы сверстать в таком редакторе страничку подобную этой статье на хабре.
Я думаю, что анимацию интерфейса во Flash все-таки проще делать, чем CSS3. А что касается растягивающихся по высоте элементов, то полностью визуальный (полный 100% WYSIWYG) MS Word решает эту проблему не хуже HTML примерно с ~1986 года.
Просто анимацию — проще, а анимацию динамического интерфейса — не совсем, в конце концов скорее всего придется писать код.
А MS Word еще хуже HTML в этом плане, так как документы с такой «сложной» разметкой типа пары столбцов с растягивающимися элементами могут открываться непредсказуемо в последующих версиях ms word, не смотря на декларируемую совместимость. Да и динамически добавлять в этот столбец блоки через VBA будет тем еще извращением.
Так и на CSS3 нельзя реализовать по-настоящему динамический интерфейс — придется писать код (на JS как минимум). Что касается MS Word, то не знаю на что Вы опираетесь, обвиняя их в несовместимости. Вот сейчас я, для примера, открыл документы ITU-T по телекоммуникационным стандартам, сделанные в Word-е в 1995 году – более ранних файлов сходу не нашел. Там много таблиц, схем и т.п. Открылось и читается отлично. И при этом пагинация не поплыла в Word 2010.
Да, код писать придется, но это будет гораздо проще, чем в том же флексе, который предназначен для обычных десктопных интерфейсов.
Насчет workd, таблицы и схемы это совсем другое дело, особенно схемы мало относятся к разметке, это же просто картинки фактически. Я говорил про разбиение на колонки, ужимание их, стили.
Со стилями и колонками в Word-е как раз все отлично, а вот в CSS любой версии проблемы. Сейчас, в 2012 году, невозможно кросс-браузерно сверстать мульти-колоночный текст с картинками и списками, не прибегая к разным извращениям и не освоив CSS далеко за пределами «продвинутого юзера». И еще хочется чтобы завтра под новой версией браузера ничего не слетело… Казалось бы простая задача — но в Word-е так сверстать намного проще. :)
Сейчас, в 2012 году, невозможно кросс-браузерно сверстать мульти-колоночный текст с картинками и списками, не прибегая к разным извращениям и не освоив CSS далеко за пределами «продвинутого юзера».

Здесь проблемою является, прежде всего, не окончившееся употребление браузера Internet Explorer версии ниже 10 — а вот все остальные браузеры, по данным caniuse.com, обладают, как минимум, частичною поддержкою многоколоночной вёрстки.
Отлично в word это пока работает, а если перестанет нормально открываться, то единственный выход снести всю разметку и сделать заново.
А насчет CSS, в 2012 году тоже часть doc документов криво открывается в openoffice и google docs, и что? А сайты с горем пополам можно было смотреть 7 лет назад даже на простом мобильнике, для других интерфейсов такой кроссплатформенности нет до сих пор.
тогда был WAP, а там я слышал другая структура документа.
да че, в 2005 на продвинутых моделях уже была поддержка XHTML. хотя WML доминировал, да. забавная была штука.
а с bootstrap можно и не быть гением верстки.
UFO just landed and posted this here
Для меня Bootstrap стал панацеей — я ничего не понимаю в современном CSS, а заставить выглядеть свой сайт хотя бы более или менее адекватно очень хотелось.
boostrap не для верстки, а для того, чтобы ваш прототип или страничка не была подобна ужасу во плоти и без грима. Это как заготовка инструментов. Например, когда на кухне готовлю я, то у меня срач по всему столу, а все продукты лежат в одной кучи. А когда готовит моя девушка, то это можно показывать по телевизору в кулинарном шоу: все по тарелочкам, помыто и порезано специальными примочками, а не как я, все одним ножом.
Про кухню. Как со скоростью дела? :)
Меня ужасают процессы которые потребляют больше времени, чем их пользование.
Блюдо, которое надо варить три часа, даже при всей его вкусности вызовет у меня досаду: готовил три часа, а съел за 10 минут.
Ну это понятно. Я исключил из рациона все меню, которые надо делать больше 20 минут :) Правда, есть блюда что готовить надо 5 минут, а потом еще 30 минут в духовке. Но это не в счет. 5 работы, за работу, вернулся, а там и обед готов :)

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

Интересно как у вас там дела :)
Мы разные блюда готовим. У меня суп с грибами и фаршом, готов через 30 минут после старта. В смысле есть уже можно. Тут ну никак за мной не угнатся. Я какую-нибудь пиццу, я уже просто не умею делать, так что даже не замерить.
Как человек, владеющий ээээ… обеими парадигмами готовки :) Выскажу своё мнение.

Чаще всего получается, что «красиво» (когда «все по тарелочкам») получается быстрее. Но! Не всегда для этого есть условия :)

Ну а то, что есть вещи, которые методикой «всё в кучу» просто вообще не приготовишь, выведем за скобки. Нет, конечно абстрактный «суп с грибами и фаршем» — можно валить в кучу, хуже не станет. Но как только, допустим, поставим на плиту вок (просто самый наглядный пример — все обжаривается по 30-40 секунд и в строго определенной последовательности), тут уж хочешь не хочешь — придется заранее разложить по тарелочкам. Резать, сбрасывая «ошметки в урну», а «помидорчики в суп» будет просто некогда :)
Так точно, на каждое блюдо свой техпроцесс. Вопрос в том как его вылизать и сделать супер быстрым.
Думал я один такой :)
>> и не освоив CSS далеко за пределами «продвинутого юзера».
И что в этом не правильного?

>> Сейчас, в 2012 году, невозможно кросс-браузерно сверстать мульти-колоночный текст с картинками и списками, не прибегая к разным извращениям

Все это делается легко. Подавляющую часть вещей делается, вообще, не заглядывая в другие браузеры кроме основного. При условии прямых рук, но даже если произойдет то что вы описали в топики, то это все равно не отменит прямых рук.
UFO just landed and posted this here
Ладно, приведу пример. Увеличьте высоту поля для ввода текста в 2 раза, или анимируйте вылетание картинки адрес которой не известен на этапе разработки.
var tf:TextField = this.getChildByName('textfield') as TextField;
tf.height *= 2;

Ну или если код не писать — просто потянуть за квардратик такой, когда элемент выделяешь.
А про картинку не понял. Как вы анимируете картинку в HTML, если вы её адрес не знаете? Так же поставите заглушку как и в случае с Flash. Немножко не тот пример.
Увеличение высоты поля, я имел в виду анимацию. Анимацировать в css3 можно просто элемент класса, который задавать картинке.
Для анимирования динамически создаваемых элементов существуют специальные библиотеки. Что не можно сделать в визуальном редакторе, всегда можно реализовать при помощи кода.

Код писали выше, флеш с самого начала был «заточен» под анимации. И графическая часть — его сильная сторона. И что важно — он кроссплатформенный, и не надо писать хаки для конкретных браузеров.
зачем сторонние библиотеки когда есть класс Tween?
Для этого для флэш-платформы был придуман Flex framework и MXML, который позволяет верстать интерфейс приложения на подобие вёрстки HTML-страниц.
для html был придуман twitter bootstrap, который тоже значительно все упрощает и ускоряет.
эээ, тормозните. Придумано было и до того. Для административных страниц бутстрап — почти панацея. Для остального — нет.
для html был придуман css.
Вы Flash Catalyst не пробовали :-)
Ладно еще процессор, но пока поисковики не научатся нормально нидексировать flash — flash мертвая технология.
Google индексирует flash (по крайней мере частично).
Flash сам такое же нагромождение хаков, как и HTML/CSS. Все же, первоначальное его предназначение — анимация, а не интерактивные приложения.
UFO just landed and posted this here
Только вот разработчики Flash все таки вовремя спохватились, и начали менять идеологию. Сравните ActionScript 3 старыми версиями. Разница почти как между Shell-скриптом и Java.

В HTML/CSS никакого улучшения идеологии я не вижу. Просто добавляют новые фичи и пытаются узаконить хаки
Приведите, пожалуйста, пример «нагромождения хаков» во флэше
Мисье наверное про разработку приложений в самой среде Adobe Flash.
Flex с виду вполне адекватная прослойка, работающая поверх плеера.
Я бы не противопоставлял Flash и HTML\CSS. У них разное предназначение и они скорее дополняют друг друга. Для HTML\CSS стОит — контент, для Flash — интерактивные и графические «плюшки», например 3D.
Нет смысла писать, например, страницу регистрации на флеше или игрушку на HTML5. Можно, конечно, но зачем, если другая технология позволяет это делать быстрее и качественней?
В том-то и дело, что дополнять друг друга они давно перестали и их области применения с каждым годом всё больше пересекаются.
К сожалению, при современном развитии HTML/CSS, верстка в визуальных редакторах является дилетантством.
Если бы в HTML/CSS была хорошая идеология, то дизайнер и верстальщик это была бы одна профессия и все бы версталось на 95% в визуальном редакторе.
«Верстка» в HTML/CSS как раз-таки является дилетантством по сравнению с настоящей, издательской версткой. Которая делается сейчас практически на 100% в визуальных редакторах, за исключением разве что TeX занимающего определенную нишу, и после которого доводку часто тоже делают в визуальных редакторах.
Я что-то упустил момент, когда в книгах/газетах появилась резиновая верстка. Когда все размеры заранее известны, то можно и в редакторах навалять. Проблемы вылазят, когда сайт должен подстраиваться под размеры дисплея.
Когда все размеры известны, то результат выглядит как psd макет :)
UFO just landed and posted this here
В любом без исключения современном издательском пакете можно поменять размер страницы и вообще полностью перестроить макет и он сам сделает новую пагинацию и корректно разместит все элементы, исправит нумерацию и так далее, при этом даже сноски и врезки не улетят на другие страницы. Как раз-таки именно в CSS пришлось бы серьезно помучиться, чтобы элементы сохраняли разумное расположение, при резком изменении количества колонок, например.
Если, конечно, перенос станиц делался не «ентером».
Представил себе газеты с различной шириной.
А вы точно в теме разбираетесь, а то я все читаю ваши комментарии и диву даюсь. Нет, ну ладно, над некоторыми тезисами можно подумать, но вот то, что вы сейчас сказали. Вы хоть пробовали? И газету и верстку…
Конечно издательская верстка книг (особенно научных) и журналов предъявляет гораздо больше требований, чем верстка web-страниц. Вы вообще понимаете сами что пишите? Хотите поспорить утверждая обратное, что будто бы верстка текста на страницах сайтов более сложная задача, чем верстка, допустим, научной статьи для журнала – с оглавлениями, тезаурусами, выносками, сносками, врезками, списками литературы, авто-нумерацией всего этого и так далее? Но при этом всю подобную верстку давно делают в интерактивных пакетах, а не ручной разметкой. Исключение, как я сказал, это TeX.
Вы сравниваете разные вещи. Как уже было сказано где-то в комментариях верстка это «поток». И неправильно переносить метафоры из типографского дела в веб.
Вы хотите сказать, что кроссбраузерная адаптирующаяся к устройству вывода вёрстка научной статьи для сайта с оглавлениями, тезаурусами, выносками, сносками, врезками, списками литературы, авто-нумерацией всего этого и так далее проще, чем для печатного журнала? Она по определению не может быть проще, потому что при нажатии кнопки «печать» в браузере должно выйти то же самое что при нажатии кнопки «печать» в издательском пакете. Но нужно предусмотреть и кучу других юзкейсов.
В теории — да, но на практике в web-е в 99.9% вообще нет никаких тезаурусов, выносок и сносок с авто нумерацией, потому, что тогда верстка каждой статьи будет стоить слишком дорого для издателя (собственников сайта), ведь для этого придется нанимать супер-классного знатока CSS и выделять ему много времени. Поэтому если хотят выложить именно классно сверстанный материал такого уровня – то просто аттачат PDF в подавляющем большинстве случаев. :)

Если бы язык разметки был по-настоящему современным, сделанным from the scratch именно под полноценную верстку, а не исторически наслоенным и изначально заточенным под показ табличек хоть как-нибудь, то и верстать на нем было бы на порядок проще.

Но главное к нему бы быстро сделали мощные визуальные средства создания контента. Сейчас же если даже ты сделаешь полноценный издательский пакет, то выгрузить из него содержимое в HTML/CSS, а не в PDF — это сверхсложная задача.

Даже Word, над которым работают годами супер-классные инженеры и юзабелисты Microsoft, не умеет даже свою разметку, более слабую чем в специализированных издательских пакетах, выгружать в сеть так, чтобы затем ничего ни на что не наползало и все features верстки поддерживались бы. Потому, что не хватает выразительности и гибкости в CSS для выгрузки нормально сверстанного даже в word-е документа.
Может, просто потому что ворд не предназначен для создания веб-страниц?)
Интересно, почему именно этот комментарий так отчаянно минусуют? Кто-то хочет сказать, что издательская верстка для книг и журналов проще, чем убогий CSS + HTML? :)
Минусуют не по принципу проще/не проще. Вы упустили из виду главные концептуальные отличия веб-верстки от издательской:
1. веб-верстка должна быть адаптивной, т.е. подстраиваться под размеры дисплея.
2. Потребителю поставляется исходник верстки, а не конечный результат, т.е. отрендеренная страница.
Любой издательский пакет так же решает проблему новой пагинации при изменении макета или длины текста. И они решают ее в гораздо более сложной постановке — с правильным переносом сносок, врезок, выносок и т.п., с перенумерацией — заметьте — изменение номеров меняет количество и длину символов, влияет на кернинг и т.п. — то есть идет изменение длины параграфа и т.п. Плюс уже когда макет готов вдруг может потребоваться внести мелкую правку без тотальной ре-пагинации и так далее. И все эти задачи решают визуальные редакторы. Уверяю Вас, в плане «резиновости» верстки они далеко, на порядок опережают по возможностям CSS.
Ок, убедили. А что по второму пункту? Как будете решать проблему компактности исходного кода? Как будете это все рендерить на мобильных девайсах?
По второму пункту в CSS по стандарту нет ни наследования, ни шаблонов, ни макросов. Нет возможности четко ссылаться на свойства других элементов или иначе связывать их друг с другом. Попробуйте, например, сделать верстку в три колонки, при которой правая и левая колонки имеют одинаковую высоту в зависимости от их содержимого. Для этого придется лезть в HTML и плодить там бессмысленные семантически div-ы.
UFO just landed and posted this here
Да и где оно там есть — в разработках комитета в виде модулей CSS4, которые еще даже самим комитетом не приняты? Пройдет еще 5 лет прежде чем это будет поддержано большинством браузеров.

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

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

Я считаю, что стандарт должен быть определен так четко и ясно, чтобы любая его имплементация давала бы bit exact изображение на экране при условии использования одинаковых шрифтов.

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

Если бы это было так, то на порядок бы упростилась разработка современных веб-два-нольных сайтов, которые предъявляют побольше требований к качеству UI, чем просто сайты-визитки.
UFO just landed and posted this here
Дизайнер должен подготовить несколько вариантов макета и/или описать трансформации раскладки/элементов (вплоть до полного удаления со страницы) при изменении области вывода и/или возможностей устройства (цветность в частности)?
Ну хрен знает, не видел я еще PDF-документа, который бы реально подстраивался под разную ширину экрана. Вот я читаю журналы под андроид, портированные с айпада. Знаете как оно подстраивается под 16:9? Черными полосками по краям! А если я нехочу смотреть журнал в горизонтальном положении, а в вертикальном (так удобнее держать) то интерактивный журнал вместо страниц выдает надпись «Поверните Айпад».

В общем не видел я этих чудес резиновости. Покажите пример что-ли.
UFO just landed and posted this here
Ну так в редакторе оно заново генерируется под новую ширину. О какой мульти экранности вообще может идти речь тогда? Просто процесс переверстывания автоматизирован в программе.
Так и в браузере оно заново генерируется под новую ширину тоже, это можно даже визуально на экране видеть. :)
UFO just landed and posted this here
В том-то и дело что проще. Сверстайте даже небольшую статью, чтоб при распечатке из браузера или издательского пакета (пускай даже Ворда) она выглядела хоть примерно одинаково. Почему-то мне кажется, что с HTML/CSS вы куда больше промучаетесь
Я делаю нормальные, полноценные веб-приложения на JS/HTML/CSS, делаю я их как под IE6 так и под современные браузеры. И я бы не сказал, что использую просто неимоверное кол-во хаков, но, да приходится делать иногда делать отдельные стили для IE6-8. По поводу Flex это фактически тот же самый набор технологий Flash/XML/CSS, и разметка там кстати еще страшнее чем HTML. Единственный плюс — не нужно думать о кроссбраузерности. По поводу разработки Flex приложений, последний раз когда я это делал, Flex Builder, был страшно тормозной, и делать в нем серьезные приложения в визуальном редакторе было достаточно проблематично, даже на по тем временам неплохим Core 2 Duo и 2Гб памяти. Да и походу вы, видимо, не сталкивались с переработкой тем для Flex приложений.
И это я уже не говорю о том, что в недалеком будущем, ie8 останется в основном в корпоративном секторе.

И я поздравляю вас! Ваше будущее уже наступило 10 лет назад — Dreamweaver.

По поводу почему приложения делают для моб. платформ нативными, как минимум можно отметить — монетизация, офлайн режим, наличие различных контроллеров ввода.
А когда Вы в последний раз использовали Flex Builder?
Вроде я пользовался второй и немного третей версией. Про неплохой я имею ввиду для программирования.
С тех пор много чего изменилось. Flex 3 допиливали. Во Flex 4 скин для компонент задаётся отдельными классами, таким образом, внешний вид полностью отделили от логики.
Ну а Flex 2, и в правду, был ещё тот цирк.
Ясно. Кстати, насколько я понял adobe прекратил поддержку Flex и Air?
Поддержку AIR прекратили только для десктопных линуксов, Андроида это не касается.
Flex SDK передали Apache Software Foundation. Уже Flex 3 был под мозиловской лицензией. Будут делать ребрендинг. При этом сам Adobe продолжает его развивать, по крайней мере, адобовская команда продолжает коммитить, и Flex доступен для скачивания с ресурсов Адоба. А от Flash Builder-а Adobe не отказывался.
Вроде я пользовался второй и немного третей версией. Про неплохой я имею ввиду для программирования.
Нет, я бы предпочел концепцию «сайт как база данных».
Мне пофиг на красивости, на дизайн и на форматирование. Чем меньше верстки — тем лучше. Обожаю старые сайты американских университетов, которые сделаны на самом древнем html.
Мне нужно чтобы была семантика, и чтобы все это можно было удобно скачать без дурацких баннеров и прочей креативщины. Скачать чистую информацию и положить в личную базу данных. Или даже запустить своего личного поискового робота, который сам найдет то что мне может быть интересно и разложит по полочкам. Вот:)
Это не вопрос технологии. Это вопрос востребованности контента и его оплаты. Указанные страницы прекрасно можно создавать и в наше время. Без баннеров и прочей креативщины. Только кто будет платить разработчикам и авторам? Меценаты что-то не находятся.

Хотя я вот хочу создать подобный проект. Но там своя область в виде филологи и лингвистики которые будут интересны только тем, кому интересны эти области.
Э… дрюг а как же банЭры показывать? Это же деньги, братюня — ты таких вредных вещей больше не думай, да?
> нормальное, полноценное приложение
Не имею ничего против flash, но удобство его элементов (например, ссылки и полосы прокрутки) хуже, чем у стандартных. Множество раз встречал отсутствие прокрутки колесиком мышки. Хотя можно возразить, что это вина программиста, но в html такой проблемы попросту нету.
Попытки создать язык/платформу с визуальным редактором в котором «сможет каждая домохозяйка программировать» предпринимались очень давно. И безуспешно. И приводило это в итоге к дефициту специалистов в отрасли. Так что нет, не нужно нам этого.

Каждый должен заниматься своим дело. Инструмент который облегчает работу с кодом (не важно каким) должен быть. Но какая-то визуальная хрень где, теоретически, можно написать приложение… нет. Хватит уже наступать на одни и теже грабли.
О боги! Ну так сделайте визуальный редактор для HTML5+CSS3. Вы думаете в коде новоизобретённого языка будет меньше костылей?

Понятно, что в отличии от полноценного десктопного приложения, у веб-разработчиков нет выбора — только HTML, CSS и JS, но для меня, как для веб-разработчика, пусть и при наличии этих самых костылей, вряд найдётся инструмент удобнее, чем созданный веб-разработчиками для веб-разработчиков.
Нужен какой-нибудь мощный и гибкий Two Step View фреймворк.
Согласен с автором. HTML должен умереть. Даешь вектор! Даешь SVG и канву.
И еще HTTP должен умереть! Эта этой идеологии запрос-ответ уже больше 30 лет. Он тоже приводит к хакам, извращениям и шаманствам, когда надо сделать что нибудь чуть сложнее чем считать небольшие данные по небольшому запросу.
Например? Изначально правильные технологии не надо заменять, над ними можно надстраивать — а в основе HTML заложено «HTML является языком логической разметки гипертекста, а посему отображение отдаётся на откуп каждому браузеру» (из спецификации HTML 1.0). Таке дела, малята.
Недостатки http привели к появлению spdy, например. Или передаче картинок, которые режутся в браузере (по сути спрайты для оформления)
Ага и квантовые компьютеры с батарейками на термоядерном синтезе!
Это семантически бессмысленные и нечитаемые другими программистами конструкции.

Это наблюдение справедливо. Открыв код страницы http://www.google.com/search?q=хабр, вижу у элемента #gbs свойство «top: -999px» и не очень-то понимаю, зачем оно.

Но без подобных вещей невозможно сверстать современный веб-два-нольный сайт.

В справедливости этого помысла я не очень уверен. Насколько я помню, в Twitter Bootstrap извращений не так много.
> в Twitter Bootstrap извращений не так много.
Но они есть.
Может быть там и меньше извращений, но это потому, что они очень далеки от детальности проработки (даже чисто визуальной) приведенного в посте интерфейса блокнота из OS/2, а это интерфейс двадцатилетней давности… Тогда еще не было (как Вы помните) даже аппаратной акселерации градиентных заливок или наложений в графических картах, прозрачности и т.п. Тем не менее, старый добрый интерфейс в сравнении даже с лучшими образцами современных web-интерфейсов смотрится как эталон совершенства и usability.

Тот, кто действительно с таким уровнем проработки воспроизведет его кроссбраузерно на CSS/HTML/JS, сможет продавать библиотеку за сотни долларов другим разработчикам, или его компанию за неплохие (не говорю, что очень большие – но не плохие) деньги купит FB или Google. :)
Тот, кто действительно с таким уровнем проработки воспроизведет его кроссбраузерно на CSS/HTML/JS, сможет продавать библиотеку за сотни долларов другим разработчикам, или его компанию за неплохие (не говорю, что очень большие – но не плохие) деньги купит FB или Google. :)


Давайте так, я сделаю вам за, ну скажем, 1000$, а вы зарабатывайте на этом миллионы? Годится?
Это не мой core бизнес. По существу же спрошу – разве Вы никогда не видели сайтов, на которых продают за пару сотен просто библиотеку, делающую обычное меню на CSS/HTML, или закладки, намного более слабенькие, чем в этом блокноте? При этом у них в клиентах фирмы из Fortune-500 и положительные отзывы от их менеджмента или инженеров в рекламе. Поэтому уверен, что проработанная и кроссбраузерная реализация контрола такого уровня легко оправдает себя. О миллионе речи не идет только от одного контрола, но если за ним будет стоять framework позволяющий быстро делать подобные по уровню вещи в web – будет и миллион.
Признаюсь, не видел. Покажите, если не сложно.
Вот например просто-напросто меню. Далеко даже не блокнот. И я отлично понимаю, почему их покупают — далеко не в любой web-студии найдутся программисты, которые пропишут так качественно работу с меню сами. Поэтому не супер-требовательному сайту намного удобнее купить готовый контрол.
>> в Twitter Bootstrap извращений не так много.
Как грязи их там. Любой «широпотреб» (что либо для массового использования) страдает от извращений, кой корень кроется в желании угодить как можно большему кол-ву пользователей.
Это твоя родина, сынок.

Можно бойкотировать html, css, js, php и т.д. страдать или изобретать велосипеды, а можно жить с этим и даже зарабатывать на этом деньги.
Это я все к тому, что html и css никуда не денется, каким бы плохим/хорошим он не был.
Ну если, какая нибудь гигантская корпорация типа Google придумает новый язык разметки, и начнет его продвигать — то думаю шанс потеснить html и css есть. Но ведь требуется потеснить гигантскую инфраструктуру, одну из основ современного информационного мира!
Гугл уже придумал замену javascript-у. И что? Много вы его где увидите?
Так он же его активно не продвигает. Сам пользуется, другим дает, но не более.
А php то сюда зачем относить? Многие люди вполне успешно используют адекватные языки типа python/ruby/java/c# для веб-like вещей.
Может весельчаки которые меня минусуют обозначат свою позицию?
Насколько я понимаю изначально был простой текстовый статический HTML, в который позже начали добавлять формы, интерактивность и пр. Т.е. делать из языка для разметки статьи в Web, язык для web-приложений, что и дало нам столько костылей в сопуствующих станадартах. Нужно было разрабатывать отдельный язык под новые потребности, а не «улучшать» то, что было.

Насчёт своих языков разметки — есть XAML, но он по разным причинам пока не получил такого же распространения как существующие разметочные языки.
Боюсь что «пока не получил распространения» это уже посметрно
Кто знает. Возможности этого языка разметки значительно превышают HTML. Не XAML, так какой-то другой язык с похожими принципами когда-нибудь, возможно, заменит HTML.

Хотя, мне кажется, в HTML будут и дальше копировать новые костыли, а старые будут отмирать. И в итоге мы получим совсем другой язык. Как это было с эволюцией JS, или того же ActionScript.
Я отношусь ко XAML как к итогу применения Корпорацией Microsoft принципа NIH («not invented here») к языку XUL, придуманному Фондом Мозиллы несколькими годами ранее почти для совершенно той же цели — для декларативного описания интерфейсов при помощи XML.
Кстати, один из XML-подобных языков, на которых, к слову, написан наш Apache Openmeetings, — это OpenLaszlo (названный так, если кто не знает, в честь кота Ласло).

OpenLaszlo компилируется и во Flash, и в HTML5. Конечно, если вы поработаете с ним немного, заметите и недостатки. Но если вам что-то не нравится в этом языке (мы бы хотели чуть более хорошую поддержку HTML5) — присылайте патч и улучшайте. Это же свободный проект.
Немного полистал документацию по OpenLaszlo. Поддержки html5 не нашел, но нашел поддержку dhtml (java + html), и Flash… Пардон, но по-моемому «те же яйца, только в профиль». Или я не там или так смотрю?
Ну там все на layouts. Я даже вводную статью по лазле писал здесь на хабре.
Если сравнивать с яйцами, то тогда яйца — это flex.
А с каких это пор DHTML стал HTML + Java? Википедия кагбе намекает, что это HTML + JavaScript + CSS + DOM.
Пардон, конечно вы правы. Просто у OpenLaszlo под dhtml, если я правильно понимаю, подразумевается смесь Java+html+js (js, опять-таки, если я правильно понимаю, чисто на подхвате, для связки).
Ну Java ведь в лазло на сервере крутится под tomcat.
Я увидел яву и на клиентской стороне тоже.
У лазлы немного идеология другая. И, как по мне, верстать там гораздо легче.
XML в языках разметки это злоЪ, лучше уж QML допилить для веба. Впрочем, он уже прекрасно для него подходит :)
html, css уже прочно сидят в web. И так просто перейти на что-то новое не получится.
Это так же как бензин в авто индустрии. Есть намного более экономичные углеводородные топлива. Но вся нефтяная индустрия, двигатели, производители, заправки и т.п… Заточены именно под бензин. Так уж исторически сложилось.
Их нет. Как только такой появится, он быстро вытеснит текущий.
Инфраструктура — часть цены топлива.
Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS. В результате кто-то из вас придумает мощную и кристально ясную замену этому историческому наслоению хаков.
По-моему, в результате такого подхода появится куча конкурентоспособных языков, каждый из которых верстальщикам придётся изучить, чтобы зарабатывать на хлеб. Разве это лучше, чем знать тот же HTML?
Дело в том, что сама потребность в 75% верстальщиков отпадет, если будет разработан семантически чистый, читаемый язык разметки. Если к нему добавить еще и визуальный редактор, то отпадет необходимость в 99% верстальщиков.
а щас он какой? не симантически чистый?
используте его как симантически чистый, а красоту наводите с помощью CSS.
Сейчас в HTML нужно вставлять div-ы просто для того, чтобы затем можно было бы правильно все сверстать. Я уж не говорю о эмиссии лишних элементов ради разных теней и круглых углов у квадратов не поддерживаемых в IE.
> Я уж не говорю о эмиссии лишних элементов ради разных теней и круглых углов у квадратов не поддерживаемых в IE.

Progressive еnhancement, например
Дико сомневаюсь, что только с помощью CSS можно навести любую красоту, не трогая произвольную логическую разметку. Даже если иметь в виду только последние релизы популярных браузеров.
может не любую, но много можно сделать с помощью CSS
Много — не спорю. Но из этого «много» многое делается не тривиально, но это ещё бог с ним. Главное, что по закону подлости когда встаёт задача темизации, да ещё с адаптацией, то зачастую не получается обойтись одним HTML, приходится для каждой темы создавать отдельный HTML.
Знать css и html всё равно придётся, но используя надстройки над ними (изучение которых много усилий не потребует) можно здорово повысить свою производительность и читаемость получаемого кода.
Подобные вещи уже существуют — slim (или haml) и sass (или less) и вовсю используются в определённых кругах.
Существует 14 конкурирующих стандартов
— Это нелепо! нам надо изобрести один универсальный стандарт, который покроет все возможные случаи.
— Точно!
Вскоре: Существует 15 конкурирующих стандартов
Это в том случае, если индустрии на самом деле не нужен единый стандарт.

С размерами винтов, например, такой проблемы давно нет (разме что метрические и имперские единицы измерения иногда конфликтуют). А все потому, что это было реальной проблемой.
Не так давно Николас Закаш говорил, что порабы уже отказаться от стремления сделать сайт одинаково отображающимся во всех браузерах, включая устаревшие, приводя в пример развитие телевещания: там никто не пытается показать цветную картинку на чернобелом телевизоре, там все вещают как могут, а дальше уже ваше дело — обновлять вам телевизор или смотреть показывается.

Если бы не подход эмулирования недостающих функций, то возможно архитектура несколько была бы чище. Правда остается факт, без которого бурное развитие веб технологий был бы не возможно: внедрение еще нестандартизированного и не принятого другими разработчиками браузеров набора технологий. Что тоже вносит свою долю бардака в архитектуру.
А теперь объясните заказчику почему его сайт отображается как «чернобелый» у клиента, хотя может отображаться как цветной.
Главное — не забыть объяснить при этом, что это будет требовать дополнительного времени и денег.
Возможно, все наладится, когда браузеры будут обновляться незаметно от пользователя и не нужно будет заботиться об устаревших браузерах. Chrome с самого начала такой (он и занимает первое место по России), FF пришел к этому на 12 версии, IE должен будет обновляться через Microsoft Update — хотя, это и не так хорошо как система Chrome и FF. Вот Опера пока, вроде бы, не хвастается ничем подобным.
Проблема IE не только и не столько в Windows Update, сколько в привязке к ОС. Пользователей XP достаточно, чтобы IE8 умирал очень-очень медленно.
Да, это, конечно же, верно. Так же как и тот факт, что в России доля лицензионных копий Windows далека от 100%, и доля пользователей Microsoft Update тесно коррелирует с ней.
Opera может похвастаться автообновлением :)
Я имел в виду, тихое обновление без ведома пользователя ) Но с Оперой никогда не было проблемы засилья старых версий, как с IE и частично с FF, у которого до сих пор большой процент версии 3.6.
UFO just landed and posted this here


Верстальщики не одобряют этот пост
Вся статья построена на одном большом передёргивании.
Современная web-технология, основанная на CSS/HTML (включая даже HTML5/CSS3) – это апофеоз бессистемности в архитектуре и фрагментации. Бессистемность в начальном дизайне и последующее наложение на нее фрагментации из-за несовместимых реализаций в браузерах породили каскады хаков для латания дыр.

Совершенно согласен, что, вследствие некорректной реализации стандартов в старых браузерах, приходится писать разные хакие, которые несемантичны и засоряют код.
Однако, какое это отношение имеет к декларируемой «бессистемности в архитектуре», позвольте спросить? Не приведено ни единого аргумента в пользу этого рассуждения, кроме странного замечания про img и ol.
Нет уж, позвольте, HTML/CSS, неважно какой версии, архитектурно выстроен прекрасно. С чего автор вдруг предлагает искать ему замену?
Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS. В результате кто-то из вас придумает мощную и кристально ясную замену этому историческому наслоению хаков.

Мощную замену историческому наложению хаков придумать невозможно, пока не умрут старые браузеры. Абсолютно непонятно, зачем нужно придумывать новые языки разметки, если можно спокойно писать на HTML5/CSS3 и транслировать его в HTML/CSS для старых браузеров.
В общем, классическая подмена понятий.
То есть вы хотите сказать, что если забить на совместимость и верстать все, скажем, под хром последней версии, то код будет лаконичным? Я не верстальщик, но мне почему-то верстка всегда и без проблем совместимости казалась каким-то колдовством.
HTML будет лаконичным в любом случае. С нынешними стандартами, есть целая куча возомжностей, чтобы следовать парадигме: HTML — содержимое, CSS — отображение, и писать чистый и семантический HTML без оглядки на дизайн.
С CSS немного посложнее, там отсутствуют переменные, переиспользование правил и т.п., и в оригинале он не будет таким чистым. Но есть решения, в виде LESS или SASS.
HTML — содержимое, CSS — отображение, и писать чистый и семантический HTML без оглядки на дизайн

Покажите мне сайт с нетривиальным дизайном, в котором нет <div class="wrapper">…
Нетривиальный, как и wrapper — понятия растяжимые. Введение wrapper'а на текущем уровне CSS в 100% случаев значит либо кривые руки, либо неправильное понимание структуры содержания.
Нет, не означает. Дело даже не в внешнем виде, а скажем масштабируемости и управляемости. Цели знаете, они разные бывают.
Ну приведите пример, где без wrapper'a не обойтись, при этом он совершенно ничего не значит с точки зрения содержания?
Всегда можно без чего-то обойтись. Например, машина вполне может обойтись без корпуса. Начинка и сиденья, но зачем без него обходится, если с ним легче. Wrap'ом многие злоупотребляют, да.

У меня есть сайдбар, в нем три блока с одинаковыми отступами и оформлением (например, полоса под каждым блоком и тень), но разным содержанием, например, опрос, новости, и баннер. Я могу сделать так: div.someblock.banner, но сделаю так: div.sidebarBlock>div.banner. Во-первых это интуитивнее, во-вторых, если я могу легко управлять содержимым sidebarBlock, например, добавить текстовые блоки, да, вообще, что-угодно и код при этом будет очень аккуратный.

Игнорировать подобное, это как если бы вы программировали без функций или классов. Можно, но зачем?
Забавно: мы говорим об одном и том же. Вы привели пример, когда с точки зрения содержания (иными словами структуры, или логики) wrapper имеет смысл, и этот смысл вы передали через класс .sidebarBlock. Я говорю о врапперах, созданных с целью создания выравнивания по центру, к примеру, или оформления тени, или создания каких-то прочих визуальных эффектов.
Неужели в современных браузерах можно добиться любого взаимного расположения блоков не трогая HTML? Скажем содержимое одного блока (сайдбара) расположить вокруг другого (контента), когда в HTML эти блоки на одном уровне.
Вокруг? Вы об этом?
image
Хоть это и пахнет с точки зрения типографики, мне тоже интересно было, как это сделать в html. Думаю, это что-то близкое к заполнению формы текстом в svg.
Но скажите, как тут враппер поможет?
Что-то вроде. А не поможет обернуть оба блока враппером, один разместить относительно, другой абсолютно, а содержание второго флоатить часть влево, часть вправо? Что-то такое помню мелькало в голове, когда коммент писал :)
Да нет, к сожалению, решение не подойдет: тут проблема глубже — предложения-то идут «сквозь» рисунок.
Я не специалист в этом деле, но тут просто иначе работает алгоритм размещения текста. Он его размещает не по прямоугольной форме, а по кастомной «векторной».
Можно было-бы искусственно вставлять пробелы в места размещения прямоугольника, образуя прямоугольник. Но это был бы уже жестокий костыль, хотя методически верный.
Хаха, теперь с введением новых тегов HTML5 «врапперы» стали узаконенной «семантикой»: footer, header, section и т. п. :) Под врапперами я имел в виду любые элементы, которые вы никогда бы не написали, если бы не нужно было стилизовать страницу. Вот канонический пример из кода приведённой страницы: <div class="container">. Этот блок существует только для того, чтобы наложить на него стиль. Это не содержимое, не семантика, это — кусок стиля. Если вам понадобится другой дизайн, то «контейнер» может спокойно понадобиться в другом месте, а необходимость в этом отпадёт.

Вёрстка чистая, мне нравится. Но сути дела это не меняет.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
В этой частности вы неправы. В этой верстке я сначала полностью без стилизации, только по смыслу писал html, затем стилизовал то, что написал. .container значит страницу, его можно было назвать .page, или .content — как хотите, визуально он несет смысл.
Но в целом вы правы — пока что есть еще вещи, неудобные для стилизации, например, выравнивание блока по правому краю так, чтобы он и высоту имел, и левый блок занимал все свободное место. Но благо это не требует wrapper'а.
В целом я помню только один случай неизбежности wrapper'a, и именно этот (jsfiddle — нужно ресайзить высоту блока). Но даже тут .widget-body имеет смысл.
Конечно.

Я вот недавно делал top-books.info и забил на IE. Вполне лаконичный код, никаких избыточностей. Я с огромным удвольствием верстал.

А это я ещё всяких HTML5-ых плюшек не использовал.
А что там верстать-то? Сайт с простейшей разметкой.
У 90% сайтов в интернете вёрстка не сложнее.
Любой каталог. Чем больше контента, тем сложнее верстка.
Что тут спорить. Давайте так: вы мне макет реального каталога — я вам чистую семантичную вёрстку в Хроме без единого костыля.
Я вам говорю: есть много сайтов со сложной версткой, любой с большим кол-вом контента. Вы мне говорите, что вы можете сверстать сложный сайт. Вы сильно невпопад ответили.
UFO just landed and posted this here
UFO just landed and posted this here
Аминь. В своих проектах смог полностью отказаться от html и css заменив их javascript'ом, тем самым дав себе возможность создавать обёртки для различных хаков, и в итоге писать чистый и понятный код.
Хотя на самостоятельный язык разметки это разумеется не тянет. Просто украшение существующего бардака.
Можете показать 1 из ваших проектов?
Присоединяюсь к вопросу.
как пример, можно зайти на мой сайт tenphi.com/
или сразу открыть файл tenphi.com/scripts.js и посмотреть его с конца (там идет код приложения).

там есть немного мусора вроде socket.io, это всё потому, сайт временно запущен в dev-режиме.

там есть и styles.css но он сгенерирован, можно в скриптах найти этот код, в dev-режиме он не вырезается.
На сайте tenphi.com уже куча ляпов в вёрстке, которые точно вызовут баги и проблемы производительности в будующем, это учитывая что на сайте кроме меню и оформления статьи еще ничего нету.

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

то что есть ошибки… это уже вероятно моя вина, а не технологии. буду признателен если вы мне укажите на них с помощью PM.
Если уж делаете современный ajax-сайт, ознакомьтесь с AJAX crawling scheme.
я с ней ознакомлен уже давно, но зачем оно мне?
мои шаблоны умеют собираться как на сервере (nodejs) так и на клиенте, в итоге поисковику отдаётся html страницы содержащей ссылки на другие страницы. когда он переходит по этим ссылкам, то ему отдаётся содержимое уже другой страницы. это уже проверено и это работает. в этом кстати большой плюс моего подхода.

или быть может я неправильно вас понял?
смог полностью отказаться от html и css заменив их javascript'ом, тем самым дав себе возможность создавать обёртки для различных хаков, и в итоге писать чистый и понятный код

'/projects/': {
	title: 'Tenphi\'s projects',
	content: [
		['h3', 'jQuery.Frame'],
		['p', ['App.Link', {
			url: 'http://github.com/tenphi/jquery-frame/'
		}, '']],
		['p', 'Гибкий и удобный фреймворк для библиотеки jQuery реализующий паттерн "Конечный автомат". Прост в использование, расширяем, использовался при создании данного сайта. Документация в процессе написания.'],
		['h3', 'JML'],
		['p', ['App.Link', {
			url: 'http://tenphi.github.com/jml/',
			target: '_blank'
		}]],
		['p', 'Динамический шаблонизатор на основе Javascript.'],
		['h3', 'JCSS'],
		['p', ['App.Link', {
			url: 'http://tenphi.github.com/jcss',
			target: '_blank'
		}]],
		['p', 'Динамический язык для каскадных таблиц стилей на основе Javascript.']
	],
	index: 1
},
Полный отказ от HTML? Лолшто?
спасибо, поймали… я не использую сам HTML как язык разметки.
в примере можно всё заменить на другие конструкции типа ['Header', 'Text of header'] предварительно создав обёртку. в итоге получится чтото совсем новое.
ну и разумеется свободная параметризация для шаблонов. в HTML такого нету.

хотя что я вам объясняю, вам же не интересно.

уже сильно жалею что дал ссылку, в следующий раз буду использовать для этого PM.
Ваш метод — не что-то новое, подобное «избавление от HTML» используется в библиотеках типа ExtJS. Правда там мощнее и, соответственно, пропорционально ужаснее.
Про ужаснее я бы поспорил :)
У вас же это HTML на S-выражениях =)

И судя по тому, что вы пишете про другие конструкции — вы на пути к реализации половины Лиспа.
Не пробовали на нем писать?
Оно рабочее, но оно страшное :)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Проблема в том, что html до сих пор разрабатывается с использованием метафор страниц, газетных статей и тому подобного. Пока вы остаетесь при верстке в рамках тех же метафор — все работает.

Но если вы хотите сверстать интерфейс, а не статью, то наступает полная…
Да, но в этом-то как раз и проблема — сейчас любой более-менее серьезный веб-проект — это «интерфейс», а не «газета».
Именно. Сравните с XAML тем же. Вроде бы тот же самый xml-based, но насколько все проще. Потому что метафоры изначально именно интерфейсные.
Точно. Ну, как XAML (.NET), так и MXML (Flex) изначально для этого создавались и в них _изначально_ все необходимое для разметки лэйаутов. То есть, даже ничего придумывать не нужно — все «из коробки».

Самое интересное — в них тоже есть CSS (собственно, CSS в MXML и ресурсы для XAML). То есть, стили, то «как оформлено» хранится отдельно от того, «что оформлено». Там стили используются строго по назначению — именно оформить что-то визуально. Структура же, вложенность, позиционирование, лэйауты и прочее сделаны НЕ через стили. Для позиционирования и разметки изначально есть необходимые семантические элементы.

И это, на мой взгляд, самый большой недостаток CSS и HTML — если файл стиля убрать — страница потеряет не только цвета, оформление и красивости — порушится сама структура документа.

То есть, по сути, верно — HTML и CSS реально «не подходит» для интерфейсов. Но нет выбора.
Позиционирование и лэйоты разве не относятся к визуальному оформлению? Хотя бы потому что на разных размера экрана и/или разных устройствах вывода они могут быть совершенно разными.
Да, я тоже уже думаю над этим. Для таких современных фич как поддержка множества девайсов, responsive-дизайна, итд, нельзя зажать все рамками элементов отдельно выбранного представления. И у меня нет ответа «как нужно». CSS, как ни крути, тоже не выглядит идеальным местом для этого. Но, пожалуй, лучше HTML-элемента с фиксированной layout-семантикой.
Да и при верстке статьи наступает полная <censored> если нужно сверстать ее в несколько колонок, с картинками и списками, и чтобы все правильно обтекалось текстом и картинки не улетали хз куда. Даже для таких элементарных целей потребуется знание CSS и его особенностей в разных браузерах за пределами того, что может изучить даже продвинутый пользователь. И этого не поддерживают в полной мере визуальные web-редакторы, даже Google Docs слаб в стилях и средне-сложной верстке в режиме статьи. Хотя он – шедевр HTML/CS и JavaScript-программирования.
Колонки недоработаны, согласен.

Особенно по сравнению с разного рода tex и word, которые используют те же метафоры и аналогичную структуры.
А действительно ли нужны колонки на экране?
Я понимаю зачем они в газете — ширина колонки выбрана так, чтобы ее можно было читать вертикально методами скорочтения. Так же это помогает складывать ее достаточно компактно и читать в транспорте. Если не будет рядом несколько колонок, то газету придется «прокручивать» — переворачивать и по-всякому складывать, чтобы дочитать колонку до конца.
А на экране это зачем? Достаточно менять ширину экрана и каждый читает так как ему удобнее. Прокрутка никаких проблем не представляет.
Нужны. Просто забейте свою первую фразу в гугл, он вам много чего расскажет словами порой весьма авторитетных людей.
А при чтении с экрана скорочтение не нужно? Да и просто при чтении на большом широком экране сложно глазами водить с левого края на правый и обратно, по двум колонка (с пагинацией) было бы проще.
В HTML/CSS все не так уж плохо. В верстке для современных браузеров картина значительно лучше того, чем приходилось заниматься лет 5-7 назад.

Но хаки — да, не поспоришь совершенно. И это благодаря тому, что до сих пор (2012!!!) отсутствуют человеческие layout'ы. Заметьте, абсолютное большинство хаков — для того, чтобы создать тот или иной лэйаут. Это бесит немыслимо, ибо многое в итоге делается через жопу и все равно где-то, да валится.
Зато у нас есть тени и закруглённые уголки!
Плохому танцору и яйца мешают.
Я, конечно, не спорю, что можно сделать лучше, но зачем?

В общем вы тут написали про XHTML3 какой-то.
UFO just landed and posted this here
И испытывающий какой-то колоссальный баттхёрт
Ну, баттхерт то при использовании указанных в топике технологий, испытывают все :)
Я не испытываю, что же я делаю не так?
Всякие приходится, но даже если так — под категорию «все» попадают все, а не только те, кто верстает сверхсложные интерефейсы.
Вообще, это был легкий и непринужденный сарказм, со смайликом в конце предложения, все как положено. А вы начали придираться к словам. Ежу понятно, что во многих случаях никакого особого баттхерта и не будет. Однако, технология неидеальна, и все это понимают. А я тут, почему-то, строю Кэпа, отвечая на ваш комментарий :)
Простите, видимо сарказмометр отказал.
По-моему, его испытывают все, кто пытается в первый раз сверстать трехколоночную вёрстку с прибитым футером.
UFO just landed and posted this here
Столкнувшись перед этим, к примеру, с .NET (а именно — часть .NET, которая обеспечивает создание интерфейсов), а после с HTML/CSS я действительно испытываю дикий баттхерт.
Особенно дикий баттхерт я испытываю, когда вижу, что приложение типа «на все браузера», скроллится вниз, а внизу — пустое место.
Еще более дикий баттхерт я испытываю, видя объем потребляемого ОЗУ.
UFO just landed and posted this here
UFO just landed and posted this here
А можно поставить всем по Silverlight'у
UFO just landed and posted this here
Во первых Moonlight, во-вторых html же поддерживают и не обламываются.
UFO just landed and posted this here
Вы почему то к IE цифру приписали, а к ML не приписали. Без этого аналогия не получилась?

«молодому» HTML до даже до moonlight такими темпами расти ещё лет 20. Непонятно только зачем растить HTML до SL, если можно просто взять SL.
UFO just landed and posted this here
UFO just landed and posted this here
Моя вина, не полностью ответил. Да всем, да на и линукс, да и на айпады, да будут поддерживать. Теперь нормуль?
UFO just landed and posted this here
Майкрософт сворачивает SL? И пруф покажете?
UFO just landed and posted this here
> Silverlight является стратегически важной технологией
> Естественно речь не идет об исчезновение ни Flash, ни Silverlight

В моём словаре значение слова «сворачивает» явно другое
UFO just landed and posted this here
В реальности они издревле поддерживают MacOS, запустили на Metro и местами помогают Moonlight с остальным. На iOS его не будет, но это внутренние проблемы яблокофилов.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Десятки лет служения человечеству в ИТ далеко не всегда достоинство, как правило оно означает ещё и груз обратной совместимости, ту самую логику процесса. И, да, бессистемность видна особенно при понимании логики. Когда из языка (или другого инструмента) пытаются сделать то, для чего он предназначался, пытаясь сохранить обратную совместимость тогда результат видится бессистемным.

HTML вроде позиционировался как язык логической разметки гипертекста. Было ли системным введением в него элементов визуального оформления? PHP был создан как шаблонизатор, плавно перетекший в процедурный язык для веба — системно ли введение в него элементов ЯП общего назначения, ООП, ФП?

То что логика процесса ясна, совсем не гарантирует хороший результат. Особенно когда логика близка к «и рыбку съесть, и ...».
Есть MS Word в котором без обучения в специальных школах любая девушка-секретарь легко и непринужденно за день сверстает статью. Так сверстает, как специально обученный CSS-верстальщик будет верстать неделю. И был dialog editor OS/2 20 лет назад в котором за 10 минут можно было визуально сконструировать вот тот блокнот в «резиновой» верстке, а в CSS его будут верстать и программировать на JS несколько месяцев, а может он превратится для кого-то в многолетний проект.
UFO just landed and posted this here
Если уж на то пошло — одна страница макета средней сложности верстается максимум за 4-8 часов времени. Без аврала и прочего.

А вот WYSIWYG и прочее — это уже не верстка, а так — как на Юкозе «сайт сделать».
UFO just landed and posted this here
А. Ну конечно.

Я-то про то, что даже весьма средненького уровня верстальщик может сверстать среднего уровня макет за один рабочий день. Так что сложность верстки весьма преувеличена. Равно как и «хаки и прочая ересь», зачастую они нужны только когда нужно сделать что-то из ряд вон выходящее.
Отрицательные поля/отступы входят в инструментарий средненького верстальщика или это всё же хаки?
Входят. Сложного в этом ничего нет, только проблема в верстке с отрицательными отступами и полями разобраться другому. Правда сейчас во всех браузерах есть инструментарий для отладки, так что понять чевойкуда уплывает можно, но все равно времени на разбор тратится больше. Именно поэтому не люблю доверстывать за другими.
Вот я к хакам отношу как раз то, с чем сложно разобраться другому. Когда вижу цифру -1000, то пытаюсь понять откуда она, почему именно -1000, а не -100500 или не -999. Комментарии к таким цифрам встречаются крайне редко (по-моему у верстальщиков с культурой комментирования ещё хуже, чем у программистов). А главное не только в чужой, но и в своей через полгода не всегда разберешься, если скопипастил откуда-то с «гугла», а из-за спешки (потому как сроки горят раз довёл до того, что гуглить пришлось) не закомментил.
ну конечна, вёрстка таблицы «пробелами», все с ней знакомы)
У word-а это получается (неплохо, хотя и с непреемлемыми глюками при сложной разметке) именно потому, что он использует свою модель всего — в том числе и внутренней разметки, а в CSS/HTML он только транслирует ее на финальном этапе записи. Если же редактор пишут сразу в расчете и в привязке к CSS/HTML, то получаются такие убогие (с точки зрения глючности работы и возможностей верстки) вещи, как CKEditor или TinyMCE. :)
UFO just landed and posted this here
Вы слишком хорошего мнения о девушках-секретаршах. До сих пор встречаю такие прелести, как центрирование текстов пробелами, абзацные отступы из тех же пробелов или табуляцией, неумение пользоваться даже самыми базовыми свойствами программы, о которой в резюме написано «свободное владение». О использовании стилей я вообще промолчу.

По поводу же трудностей CSS-верстальщика, вы сильно преувеличиваете. Сверстать статью в ворде и сделать этот же текстовый блок средствами CSS по времени различается не сильно. А если при этом пользоваться сторонними средствами (а не одним notepad.exe) — так и быстрее. Разница есть, но она в подходах.
> которые делаются не потому, что без них никак, а потому, что они позволяют повысить кроссбраузерность

В большинстве случаев это и называется «без них никак».
Валидатор? Он потерял смысл. В современном HTML(5) могут быть чёрт знает какие элементы и атрибуты.
UFO just landed and posted this here
UFO just landed and posted this here
Как их валидировать, если их состав не известен заранее?
UFO just landed and posted this here
Валидатор может помочь найти какие-то откровенные глюки, но часто он совершенно бесполезен. Например, я до сих пор не понимаю, зачем нужны жёсткие ограничения на вложенность элементов. С его точки зрения:

<span><div></div></span> — нельзя
<div style="display: inline"><span style="display: block"></span></div> — можно
Ну так внутри inline-блока, нельзя встраивать блочные, нужно использовать inline-block. Кроме того у HTML в браузерах есть некоторые особенности, например нельзя делать абзац в абзаце <p> — парсер браузера х просто вычистит. А например Chrome запрещает вложенные <form>, и вычищает их, тогда как другие браузеры — нет.
UFO just landed and posted this here
Извиняюсь, про form я погорячился, сейчас посмотрел — да, действительно вложенные form режутся везде. Просто однажды был такой баг, вызванный вложенным form, что везде работало, кроме chrome.
Пля. Ну это как вложенность «ВАЗ-2115» в «Печку ВАЗ-2115» и «Печка ВАЗ-2115» в «ВАЗ-2115».
UFO just landed and posted this here
Кстати, по-моему, самая большая проблема HTML/CSS как раз в том, что CSS задает «какие-то там» боксы. По моему, слишком многое отдано на откуп CSS. Хоть бери и держи в проектах по 2 набора CSS — один для структуры, другой — для, собственно, оформления. Для первого в идеале, конечно, нужны просто однозначные семантические элементы разметки (вместо безликого div).
UFO just landed and posted this here
Ммм, ну о том и речь.

На примере, лэйаутов — я бы предпочел тэги <vbox>, <hbox> с установленным по-умолчанию display: box и соответствующим box-orientation, <grid>, и так далее — то есть, элементы, изначально имеющие правильную семантику, чем кучу div-ов с необходимостью указывать это в CSS.

В идеале, при отключении CSS элементы не должны терять позицию. То есть, глядя только на HTML должно быть понятно, как будут расположены эти элементы.

P.S. Основа должна бы быть понятна без чтения спецификаций для такой распространенной технологии.
UFO just landed and posted this here
Я говорю не о выравнивании ячеек, а о структуре и семантике. У таблиц свои проблемы есть (кроме того, что «много тегаф» и несемантично для лэйаутов).
HTML идеологически appearance agnostic язык, потому как служит для разметки структуры документа. Чтобы было понятно, как всё будет выглядеть из разметки нужно использовать соответствующий язык, с блекджеком и вбоксами :)

XUL вам в руки, например. Даже трансляторы есть в HTML/CSS, например в Ample SDK. Даже XBL можно юзать с помощью XBL.js
Ну, поскольку сейчас HTML используется для того, для чего не приспособен, по сути, то вполне себе правильное направление развития — становиться приспособленным для того, для чего его юзают.

Поменялось само значение термина документ, если хотите. Так что vbox, hbox в html смотрелись бы очень даже правильно.
HTML никогда не изменит направления своего развития на язык разметки интерфейсов. Достаточно изучить его историю
Хотя, в этом что-то есть: «HTML идеологически appearance agnostic язык». Даже разные устройства могут показывать что-то по разному. Хотя vbox, hbox не кажутся мне такими уж особыми нарушениями. Тыща вложенных дивов ли не нарушение изначально заложенных идей. Спорная тема, впрочем.
1000 вложенных дивов делает не HTML, а разработчики ;)
За неимением альтернативы :)

Но я соглашусь, что vbox и hbox в виде элементов — все-таки плохая идея.
То есть, глядя только на HTML должно быть понятно, как будут расположены эти элементы.

Я вот жду, не дождусь, когда будет наоборот. Когда глядя только на HTML я вообще не смогу строить хоть каких-то предположений о расположенности элементов. Естественно обфускацию не рассматриваю :) Хотя, скорее, я рассматриваю задачу с другой стороны — чтобы разрабатывая сервер-сайд мне не нужно было смотреть дизайн вообще, чтобы HTML писал я, не заботясь о визуальном отображении, а CSS писал верстальщик, причём не по моему HTML, а по дизайну. Всё взаимодействие которое нам с ним нужно должно заключаться в соглашениях об именованиях. Чтобы стандарт HTML был написан так, что исключал несемантическое использование тегов и не предоставлял выбор использовать div class=«nav» или nav.

Вряд ли это достижимо, но наличие, например, XSLT не оставляет надежды.
«То есть, глядя только на HTML должно быть понятно, как будут расположены эти элементы.» — я откажусь от этой идеи, верно, так никуда не годится.

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

P.S. Вообще бездумно возвращать «какой-нибудь HTML» не получится в любом случае, ну вы это и сами понимаете. Задача сделать, чтобы было как можно проще.
Я скорее про саму идею (или следствие из неё) XSLT — есть чисто логический код, содержащий структурированные данные, и есть «стиль», содержащий полное визуальное представление. То есть в исходном XML файле вообще никаких предположений о визуализации нет, даже «дефолтного» для HTML предположения, что блоки одного уровня выводятся в порядке определения, а дочерние — внутри родительских.

Вот хочется подобного от HTML+CSS. HTML содержит чисто логическую структуру, а CSS — чисто визуальную. Дефолтную визуализацию оставить можно, конечно, но сам CSS должен быть намного гибче для этого, прежде всего в плане геометрии блоков. Пускай прямые границы блоков, но возможность динамического их расчёта типа: «левый нижний угол блока с таким-то селектором на 7 пикселей левее и на 20 ниже блока с таким-то селектором, размеры на 10 пикселей больше блока с таким-то селектором, а z-index на 1 больше блока с таким-то селектором». В общем, чтобы текстовое ТЗ на расположение блоков переводилось в CSS один к одному, а не хаками типа «этот блок HTML вложим в этот, и сделаем ему левое поле -10000px».
Согласен почти по всем статьям. Особенно вот с этой мыслью: «чтобы текстовое ТЗ на расположение блоков переводилось в CSS один к одному, а не хаками». Прямо в яблочко. Реально не хватает нормальных лэйаутов и средств «экспрессии» в CSS — по сути, то, что есть, к примеру, в LESS — должно бы быть в самом CSS.

Только есть пара ремарок по HTML.

Поэтому я и про XSLT я не сразу понял мысль. Я понимаю, на входе, по сути, чистые данные в виде XML. Про тяжеловесность XSLT я не просто так упомянул, ибо на сервере, пока мы «доберемся» до XSLT — у нас уже есть View-Model на выходе из контроллера, которая и представляет собой данные. Два раза обрабатывать данные, превращая их в 2 разных представления, двух разных уровней абстракции очень не хочется. И, как ни крути, не хотелось бы, чтобы и HTML стал «чисто данными», мне кажется это не нужно — у него уже есть свой контекст, свое назначение. Т.е., на мой взгляд, не нужно превращать HTML в XML.

В итоге получаем две крайности — с одной стороны HTML может знать слишком много о конкретном представлении, а с другой — риск стать слишком обезличенным, быть чисто «данными». Одно недостаточно гибко, другое — слишком абстрактно. В итоге, HTML балансирует где-то посередине. Вопрос в том — где он должен быть, и тут — хрен его знает :) Но хотелось бы чего-то оптимального.
Ну, HTML превращать в XML («чисто данные») мне тоже бы не хотелось. Хотя… Но главные претензии у меня к CSS, именно раскладки и выражения. Причём средств типа LESS/SASS или, скажем, генерации CSS средствами PHP недостаточно, они сильно облегчают поддержку, а вот собственно вёрстку, по-моему, не очень. И выражения я бы даже поставил на первое место, хотя бы возможность ссылаться на произвольный селектор, что-то вроде:
.sidebar.right {
  position: absolute;
  left: value('#content[right]');
  margin: 20px;
}

Таким образом можно решить бОльшую часть проблем с раскладками наверное. Да и к XML с чисто данными такой CSS будет гораздо проще применять, чтоб получить что-то осмысленное :)
Верстаю годы и годы — и бурчу постоянно, что HTML это язык, не приспособленный для верстки страниц.
Зато все к нему привыкли — пусть уж будет. И мне работа найдется.
WPF да, там XAML в качестве разметки. А для JavaFX, насколько мне известно, такой штуки нет. Классы для описания есть, но сама разметка только Java-кодом, нет?
«Что вы, собственно, предлагаете?» Приведите какой-нибудь язык разметки с трансляцией в HTML-CSS
Уважаемый автор! С моей точки зрения, оценка CSS/HTML представления страниц — есть величина не только субъективная, но и сравнительная.
И теперь мой к Вам вопрос: с чем Вы предлагаете сравнивать? Какие у нас есть альтернативы, по сравнению с которыми мы могли бы назвать данные технологии сравнительно бесполезными, либо сравнительно полезными?

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

Мы же взрослые люди, уважаемый автор. Давайте исходить из реальности.
Вы считаете что HTML/CSS — плохи?
Предлагайте альтернативы. Давайте их обсуждать.
Причём обсуждать в реальном комплексе проблем, связанных с необходимостью менять инфраструктуру крупными корпорациями и т.д.
Это как были лошади, а нужно было придумать что-то лучше. Придумали автомобили. Нельзя ведь было сказать — давайте придумаем автомобили. Была задача сделать что-то (!) другое. Так и т