Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 515
Ничего не понимаю в хтмле, но диалоговые окна/вертикальные закладки в первых версиях OS/2 были прекрасны.
А еще интерфейс в старинной OS/2 требовал на порядки меньше ресурсов CPU и памяти.
Современные технологии построения интерфейсов всегда успевают за железом. Если железо стало работать быстрее, то сделаем сложную технологию интерфейсов, которая заставит его тормозить.
Современные технологии построения интерфейсов всегда успевают за железом. Если железо стало работать быстрее, то сделаем сложную технологию интерфейсов, которая заставит его тормозить.
По сравнению с html очевидно.
Могу привести пример: HTML диалоги в Visual Studio. Типа AddEvent Handler, Add Member Variable (C++). Нечто глючное и тормозящее, время от времени вылетающее и вешающее саму студию (хотя возможно там тормозят не сами диалоги а то что до них, но не суть). Самое главное — непонятно ради чего все это.
Сама идея документов, описываемых в простом текстовом формате с иерархическими тегами (xml) весьма не плоха. Взять тот же fb2 — «чистая разметка без форматирования» — отличный формат. Плохо все то, что конкретно в вебе вокруг html действительно наслоилось много лишнего.
Могу привести пример: HTML диалоги в Visual Studio. Типа AddEvent Handler, Add Member Variable (C++). Нечто глючное и тормозящее, время от времени вылетающее и вешающее саму студию (хотя возможно там тормозят не сами диалоги а то что до них, но не суть). Самое главное — непонятно ради чего все это.
Сама идея документов, описываемых в простом текстовом формате с иерархическими тегами (xml) весьма не плоха. Взять тот же fb2 — «чистая разметка без форматирования» — отличный формат. Плохо все то, что конкретно в вебе вокруг html действительно наслоилось много лишнего.
> Взять тот же fb2 — «чистая разметка без форматирования»
О да. Когда про HTML5 говорили что наконец-то начался «семантический веб», беглого взгляда на него хватило чтоб понять, что в этом смысле ему далеко до казалось бы нестандартного и «доморощенного» формата FB2, и что W3C вместо готового результата выдали очередной неудобоваримый полуфабрикат.
О да. Когда про HTML5 говорили что наконец-то начался «семантический веб», беглого взгляда на него хватило чтоб понять, что в этом смысле ему далеко до казалось бы нестандартного и «доморощенного» формата FB2, и что W3C вместо готового результата выдали очередной неудобоваримый полуфабрикат.
Я бы сказал, что сейчас они еще более полезны. У меня все основные вертиклаьными сделаны…
У меня, например, с одного стороны панель задач, с другой — вкладки браузера, так что ничего избыточного. Главное — за пользователя не решать.
Кстати там стандартный контрол поддерживал и вертикальные и горизонтальные закладки одновременно — в рамках одного блокнота, причем разные страницы вертикальной развертки могли, естественно, иметь свои собственные горизонтальные закладки.
Меня они абсолютно не впечатляют. Особенно толстая кипа «страниц».
Если б все было так просто, профессии «Верстальщик» не существовало бы.
Вы намекаете, что все это усложнение с css3 и html это заговор верстальщиков, боящихся потерять свою нужность?:)
Скорее это от того, что стандарт разрабатывали верстальщики или люди, которые напрямую слушали верстальщиков. :) И получилось по принципу Форда, который сказал, что если бы он спросил потребителя что тому нужно, то тот ответил бы, что нужна всего лишь более быстрая лошадь.
Скорее всего из-за того что браузеры до настоящего времени эти стандарты реализовывали криво и вообще забивали на них, отсюда и пошли шаманства когда в стандарте написано что отсутп работает так а в ie он работает иначе.
Главноая проблема html css в том что код написанный одинаково работает по разному в разных браузерах.
Главноая проблема html css в том что код написанный одинаково работает по разному в разных браузерах.
Скорее «Верстальщики» занимались бы своим делом и были бы на порядок производительны при:
— при наличии разумного языка разметки
— мощных средств визуализации (включая анимацию и 3D)
— поддержки связывания с внешним источником данных (шаблонизация и binding)
— удобного инструмента для верстки и отображения результата на лету
— при наличии разумного языка разметки
— мощных средств визуализации (включая анимацию и 3D)
— поддержки связывания с внешним источником данных (шаблонизация и binding)
— удобного инструмента для верстки и отображения результата на лету
Только не нужно забывать о том, что текстовая HTML/CSS верстка динамична в отличие от результата выдаваемого редактором. Даже самую простенькую анимацию интерфейса в визуальном редакторе делать тот еще геморрой, а на CSS3 это элементарно. Ну и столб из изменяющихся по высоте и количеству блоков с элементами управления тоже не так легко сделать в большинстве таких редакторов. Да и представьте, сколько мышекликанья потребуется, чтобы сверстать в таком редакторе страничку подобную этой статье на хабре.
Я думаю, что анимацию интерфейса во Flash все-таки проще делать, чем CSS3. А что касается растягивающихся по высоте элементов, то полностью визуальный (полный 100% WYSIWYG) MS Word решает эту проблему не хуже HTML примерно с ~1986 года.
Просто анимацию — проще, а анимацию динамического интерфейса — не совсем, в конце концов скорее всего придется писать код.
А MS Word еще хуже HTML в этом плане, так как документы с такой «сложной» разметкой типа пары столбцов с растягивающимися элементами могут открываться непредсказуемо в последующих версиях ms word, не смотря на декларируемую совместимость. Да и динамически добавлять в этот столбец блоки через VBA будет тем еще извращением.
А MS Word еще хуже HTML в этом плане, так как документы с такой «сложной» разметкой типа пары столбцов с растягивающимися элементами могут открываться непредсказуемо в последующих версиях ms word, не смотря на декларируемую совместимость. Да и динамически добавлять в этот столбец блоки через VBA будет тем еще извращением.
Так и на CSS3 нельзя реализовать по-настоящему динамический интерфейс — придется писать код (на JS как минимум). Что касается MS Word, то не знаю на что Вы опираетесь, обвиняя их в несовместимости. Вот сейчас я, для примера, открыл документы ITU-T по телекоммуникационным стандартам, сделанные в Word-е в 1995 году – более ранних файлов сходу не нашел. Там много таблиц, схем и т.п. Открылось и читается отлично. И при этом пагинация не поплыла в Word 2010.
Да, код писать придется, но это будет гораздо проще, чем в том же флексе, который предназначен для обычных десктопных интерфейсов.
Насчет workd, таблицы и схемы это совсем другое дело, особенно схемы мало относятся к разметке, это же просто картинки фактически. Я говорил про разбиение на колонки, ужимание их, стили.
Насчет workd, таблицы и схемы это совсем другое дело, особенно схемы мало относятся к разметке, это же просто картинки фактически. Я говорил про разбиение на колонки, ужимание их, стили.
Со стилями и колонками в Word-е как раз все отлично, а вот в CSS любой версии проблемы. Сейчас, в 2012 году, невозможно кросс-браузерно сверстать мульти-колоночный текст с картинками и списками, не прибегая к разным извращениям и не освоив CSS далеко за пределами «продвинутого юзера». И еще хочется чтобы завтра под новой версией браузера ничего не слетело… Казалось бы простая задача — но в Word-е так сверстать намного проще. :)
Сейчас, в 2012 году, невозможно кросс-браузерно сверстать мульти-колоночный текст с картинками и списками, не прибегая к разным извращениям и не освоив CSS далеко за пределами «продвинутого юзера».
Здесь проблемою является, прежде всего, не окончившееся употребление браузера Internet Explorer версии ниже 10 — а вот все остальные браузеры, по данным caniuse.com, обладают, как минимум, частичною поддержкою многоколоночной вёрстки.
Отлично в word это пока работает, а если перестанет нормально открываться, то единственный выход снести всю разметку и сделать заново.
А насчет CSS, в 2012 году тоже часть doc документов криво открывается в openoffice и google docs, и что? А сайты с горем пополам можно было смотреть 7 лет назад даже на простом мобильнике, для других интерфейсов такой кроссплатформенности нет до сих пор.
А насчет CSS, в 2012 году тоже часть doc документов криво открывается в openoffice и google docs, и что? А сайты с горем пополам можно было смотреть 7 лет назад даже на простом мобильнике, для других интерфейсов такой кроссплатформенности нет до сих пор.
а с bootstrap можно и не быть гением верстки.
boostrap не для верстки, а для того, чтобы ваш прототип или страничка не была подобна ужасу во плоти и без грима. Это как заготовка инструментов. Например, когда на кухне готовлю я, то у меня срач по всему столу, а все продукты лежат в одной кучи. А когда готовит моя девушка, то это можно показывать по телевизору в кулинарном шоу: все по тарелочкам, помыто и порезано специальными примочками, а не как я, все одним ножом.
Про кухню. Как со скоростью дела? :)
Меня ужасают процессы которые потребляют больше времени, чем их пользование.
Блюдо, которое надо варить три часа, даже при всей его вкусности вызовет у меня досаду: готовил три часа, а съел за 10 минут.
Блюдо, которое надо варить три часа, даже при всей его вкусности вызовет у меня досаду: готовил три часа, а съел за 10 минут.
Ну это понятно. Я исключил из рациона все меню, которые надо делать больше 20 минут :) Правда, есть блюда что готовить надо 5 минут, а потом еще 30 минут в духовке. Но это не в счет. 5 работы, за работу, вернулся, а там и обед готов :)
А вот кто готовит быстрее. Красиво то по тарелочкам это одно, а скорость техпроцесса. Я когда готовлю у меня мусорник посреди кухни стоит :) Некрасиво, зато очень шустро порезел овощи, ошметки с доски ножом хлоп в урну. Помидорчики хлоп в суп. Некрасиво, но быстро.
Интересно как у вас там дела :)
А вот кто готовит быстрее. Красиво то по тарелочкам это одно, а скорость техпроцесса. Я когда готовлю у меня мусорник посреди кухни стоит :) Некрасиво, зато очень шустро порезел овощи, ошметки с доски ножом хлоп в урну. Помидорчики хлоп в суп. Некрасиво, но быстро.
Интересно как у вас там дела :)
Мы разные блюда готовим. У меня суп с грибами и фаршом, готов через 30 минут после старта. В смысле есть уже можно. Тут ну никак за мной не угнатся. Я какую-нибудь пиццу, я уже просто не умею делать, так что даже не замерить.
Как человек, владеющий ээээ… обеими парадигмами готовки :) Выскажу своё мнение.
Чаще всего получается, что «красиво» (когда «все по тарелочкам») получается быстрее. Но! Не всегда для этого есть условия :)
Ну а то, что есть вещи, которые методикой «всё в кучу» просто вообще не приготовишь, выведем за скобки. Нет, конечно абстрактный «суп с грибами и фаршем» — можно валить в кучу, хуже не станет. Но как только, допустим, поставим на плиту вок (просто самый наглядный пример — все обжаривается по 30-40 секунд и в строго определенной последовательности), тут уж хочешь не хочешь — придется заранее разложить по тарелочкам. Резать, сбрасывая «ошметки в урну», а «помидорчики в суп» будет просто некогда :)
Чаще всего получается, что «красиво» (когда «все по тарелочкам») получается быстрее. Но! Не всегда для этого есть условия :)
Ну а то, что есть вещи, которые методикой «всё в кучу» просто вообще не приготовишь, выведем за скобки. Нет, конечно абстрактный «суп с грибами и фаршем» — можно валить в кучу, хуже не станет. Но как только, допустим, поставим на плиту вок (просто самый наглядный пример — все обжаривается по 30-40 секунд и в строго определенной последовательности), тут уж хочешь не хочешь — придется заранее разложить по тарелочкам. Резать, сбрасывая «ошметки в урну», а «помидорчики в суп» будет просто некогда :)
Думал я один такой :)
>> и не освоив CSS далеко за пределами «продвинутого юзера».
И что в этом не правильного?
>> Сейчас, в 2012 году, невозможно кросс-браузерно сверстать мульти-колоночный текст с картинками и списками, не прибегая к разным извращениям
Все это делается легко. Подавляющую часть вещей делается, вообще, не заглядывая в другие браузеры кроме основного. При условии прямых рук, но даже если произойдет то что вы описали в топики, то это все равно не отменит прямых рук.
И что в этом не правильного?
>> Сейчас, в 2012 году, невозможно кросс-браузерно сверстать мульти-колоночный текст с картинками и списками, не прибегая к разным извращениям
Все это делается легко. Подавляющую часть вещей делается, вообще, не заглядывая в другие браузеры кроме основного. При условии прямых рук, но даже если произойдет то что вы описали в топики, то это все равно не отменит прямых рук.
Ладно, приведу пример. Увеличьте высоту поля для ввода текста в 2 раза, или анимируйте вылетание картинки адрес которой не известен на этапе разработки.
var tf:TextField = this.getChildByName('textfield') as TextField;
tf.height *= 2;
Ну или если код не писать — просто потянуть за квардратик такой, когда элемент выделяешь.
А про картинку не понял. Как вы анимируете картинку в HTML, если вы её адрес не знаете? Так же поставите заглушку как и в случае с Flash. Немножко не тот пример.
Увеличение высоты поля, я имел в виду анимацию. Анимацировать в css3 можно просто элемент класса, который задавать картинке.
Для анимирования динамически создаваемых элементов существуют специальные библиотеки. Что не можно сделать в визуальном редакторе, всегда можно реализовать при помощи кода.
Код писали выше, флеш с самого начала был «заточен» под анимации. И графическая часть — его сильная сторона. И что важно — он кроссплатформенный, и не надо писать хаки для конкретных браузеров.
Код писали выше, флеш с самого начала был «заточен» под анимации. И графическая часть — его сильная сторона. И что важно — он кроссплатформенный, и не надо писать хаки для конкретных браузеров.
Для этого для флэш-платформы был придуман Flex framework и MXML, который позволяет верстать интерфейс приложения на подобие вёрстки HTML-страниц.
Вы Flash Catalyst не пробовали :-)
Ладно еще процессор, но пока поисковики не научатся нормально нидексировать flash — flash мертвая технология.
Flash сам такое же нагромождение хаков, как и HTML/CSS. Все же, первоначальное его предназначение — анимация, а не интерактивные приложения.
Только вот разработчики Flash все таки вовремя спохватились, и начали менять идеологию. Сравните ActionScript 3 старыми версиями. Разница почти как между Shell-скриптом и Java.
В HTML/CSS никакого улучшения идеологии я не вижу. Просто добавляют новые фичи и пытаются узаконить хаки
В HTML/CSS никакого улучшения идеологии я не вижу. Просто добавляют новые фичи и пытаются узаконить хаки
Приведите, пожалуйста, пример «нагромождения хаков» во флэше
Я бы не противопоставлял Flash и HTML\CSS. У них разное предназначение и они скорее дополняют друг друга. Для HTML\CSS стОит — контент, для Flash — интерактивные и графические «плюшки», например 3D.
Нет смысла писать, например, страницу регистрации на флеше или игрушку на HTML5. Можно, конечно, но зачем, если другая технология позволяет это делать быстрее и качественней?
Нет смысла писать, например, страницу регистрации на флеше или игрушку на HTML5. Можно, конечно, но зачем, если другая технология позволяет это делать быстрее и качественней?
К сожалению, при современном развитии HTML/CSS, верстка в визуальных редакторах является дилетантством.
Если бы в HTML/CSS была хорошая идеология, то дизайнер и верстальщик это была бы одна профессия и все бы версталось на 95% в визуальном редакторе.
Если бы в HTML/CSS была хорошая идеология, то дизайнер и верстальщик это была бы одна профессия и все бы версталось на 95% в визуальном редакторе.
«Верстка» в HTML/CSS как раз-таки является дилетантством по сравнению с настоящей, издательской версткой. Которая делается сейчас практически на 100% в визуальных редакторах, за исключением разве что TeX занимающего определенную нишу, и после которого доводку часто тоже делают в визуальных редакторах.
Я что-то упустил момент, когда в книгах/газетах появилась резиновая верстка. Когда все размеры заранее известны, то можно и в редакторах навалять. Проблемы вылазят, когда сайт должен подстраиваться под размеры дисплея.
Когда все размеры известны, то результат выглядит как psd макет :)
В любом без исключения современном издательском пакете можно поменять размер страницы и вообще полностью перестроить макет и он сам сделает новую пагинацию и корректно разместит все элементы, исправит нумерацию и так далее, при этом даже сноски и врезки не улетят на другие страницы. Как раз-таки именно в CSS пришлось бы серьезно помучиться, чтобы элементы сохраняли разумное расположение, при резком изменении количества колонок, например.
Представил себе газеты с различной шириной.
А вы точно в теме разбираетесь, а то я все читаю ваши комментарии и диву даюсь. Нет, ну ладно, над некоторыми тезисами можно подумать, но вот то, что вы сейчас сказали. Вы хоть пробовали? И газету и верстку…
Конечно издательская верстка книг (особенно научных) и журналов предъявляет гораздо больше требований, чем верстка web-страниц. Вы вообще понимаете сами что пишите? Хотите поспорить утверждая обратное, что будто бы верстка текста на страницах сайтов более сложная задача, чем верстка, допустим, научной статьи для журнала – с оглавлениями, тезаурусами, выносками, сносками, врезками, списками литературы, авто-нумерацией всего этого и так далее? Но при этом всю подобную верстку давно делают в интерактивных пакетах, а не ручной разметкой. Исключение, как я сказал, это TeX.
Вы сравниваете разные вещи. Как уже было сказано где-то в комментариях верстка это «поток». И неправильно переносить метафоры из типографского дела в веб.
Вы хотите сказать, что кроссбраузерная адаптирующаяся к устройству вывода вёрстка научной статьи для сайта с оглавлениями, тезаурусами, выносками, сносками, врезками, списками литературы, авто-нумерацией всего этого и так далее проще, чем для печатного журнала? Она по определению не может быть проще, потому что при нажатии кнопки «печать» в браузере должно выйти то же самое что при нажатии кнопки «печать» в издательском пакете. Но нужно предусмотреть и кучу других юзкейсов.
В теории — да, но на практике в web-е в 99.9% вообще нет никаких тезаурусов, выносок и сносок с авто нумерацией, потому, что тогда верстка каждой статьи будет стоить слишком дорого для издателя (собственников сайта), ведь для этого придется нанимать супер-классного знатока CSS и выделять ему много времени. Поэтому если хотят выложить именно классно сверстанный материал такого уровня – то просто аттачат PDF в подавляющем большинстве случаев. :)
Если бы язык разметки был по-настоящему современным, сделанным from the scratch именно под полноценную верстку, а не исторически наслоенным и изначально заточенным под показ табличек хоть как-нибудь, то и верстать на нем было бы на порядок проще.
Но главное к нему бы быстро сделали мощные визуальные средства создания контента. Сейчас же если даже ты сделаешь полноценный издательский пакет, то выгрузить из него содержимое в HTML/CSS, а не в PDF — это сверхсложная задача.
Даже Word, над которым работают годами супер-классные инженеры и юзабелисты Microsoft, не умеет даже свою разметку, более слабую чем в специализированных издательских пакетах, выгружать в сеть так, чтобы затем ничего ни на что не наползало и все features верстки поддерживались бы. Потому, что не хватает выразительности и гибкости в CSS для выгрузки нормально сверстанного даже в word-е документа.
Если бы язык разметки был по-настоящему современным, сделанным from the scratch именно под полноценную верстку, а не исторически наслоенным и изначально заточенным под показ табличек хоть как-нибудь, то и верстать на нем было бы на порядок проще.
Но главное к нему бы быстро сделали мощные визуальные средства создания контента. Сейчас же если даже ты сделаешь полноценный издательский пакет, то выгрузить из него содержимое в HTML/CSS, а не в PDF — это сверхсложная задача.
Даже Word, над которым работают годами супер-классные инженеры и юзабелисты Microsoft, не умеет даже свою разметку, более слабую чем в специализированных издательских пакетах, выгружать в сеть так, чтобы затем ничего ни на что не наползало и все features верстки поддерживались бы. Потому, что не хватает выразительности и гибкости в CSS для выгрузки нормально сверстанного даже в word-е документа.
Интересно, почему именно этот комментарий так отчаянно минусуют? Кто-то хочет сказать, что издательская верстка для книг и журналов проще, чем убогий CSS + HTML? :)
Минусуют не по принципу проще/не проще. Вы упустили из виду главные концептуальные отличия веб-верстки от издательской:
1. веб-верстка должна быть адаптивной, т.е. подстраиваться под размеры дисплея.
2. Потребителю поставляется исходник верстки, а не конечный результат, т.е. отрендеренная страница.
1. веб-верстка должна быть адаптивной, т.е. подстраиваться под размеры дисплея.
2. Потребителю поставляется исходник верстки, а не конечный результат, т.е. отрендеренная страница.
Любой издательский пакет так же решает проблему новой пагинации при изменении макета или длины текста. И они решают ее в гораздо более сложной постановке — с правильным переносом сносок, врезок, выносок и т.п., с перенумерацией — заметьте — изменение номеров меняет количество и длину символов, влияет на кернинг и т.п. — то есть идет изменение длины параграфа и т.п. Плюс уже когда макет готов вдруг может потребоваться внести мелкую правку без тотальной ре-пагинации и так далее. И все эти задачи решают визуальные редакторы. Уверяю Вас, в плане «резиновости» верстки они далеко, на порядок опережают по возможностям CSS.
Ок, убедили. А что по второму пункту? Как будете решать проблему компактности исходного кода? Как будете это все рендерить на мобильных девайсах?
По второму пункту в CSS по стандарту нет ни наследования, ни шаблонов, ни макросов. Нет возможности четко ссылаться на свойства других элементов или иначе связывать их друг с другом. Попробуйте, например, сделать верстку в три колонки, при которой правая и левая колонки имеют одинаковую высоту в зависимости от их содержимого. Для этого придется лезть в HTML и плодить там бессмысленные семантически div-ы.
Да и где оно там есть — в разработках комитета в виде модулей CSS4, которые еще даже самим комитетом не приняты? Пройдет еще 5 лет прежде чем это будет поддержано большинством браузеров.
Дело в том, что сама архитектура слишком комплексна и в то же время мутно описана, поэтому в полной мере реализовать ее крайне тяжело даже самым лучшим инженерам в командах разработки браузеров.
Поэтому imho утопия ожидать, что на этой архитектуре когда-нибудь движки стабилизируются настолько, чтобы одинаково отрисовать одну и ту же страницу.
Я считаю, что стандарт должен быть определен так четко и ясно, чтобы любая его имплементация давала бы bit exact изображение на экране при условии использования одинаковых шрифтов.
Потому, что сайт должен выглядеть так, как задумал дизайнер компании-разработчика, а не так, как его вздумалось нарисовать какому-то терминальному софту.
Если бы это было так, то на порядок бы упростилась разработка современных веб-два-нольных сайтов, которые предъявляют побольше требований к качеству UI, чем просто сайты-визитки.
Дело в том, что сама архитектура слишком комплексна и в то же время мутно описана, поэтому в полной мере реализовать ее крайне тяжело даже самым лучшим инженерам в командах разработки браузеров.
Поэтому imho утопия ожидать, что на этой архитектуре когда-нибудь движки стабилизируются настолько, чтобы одинаково отрисовать одну и ту же страницу.
Я считаю, что стандарт должен быть определен так четко и ясно, чтобы любая его имплементация давала бы bit exact изображение на экране при условии использования одинаковых шрифтов.
Потому, что сайт должен выглядеть так, как задумал дизайнер компании-разработчика, а не так, как его вздумалось нарисовать какому-то терминальному софту.
Если бы это было так, то на порядок бы упростилась разработка современных веб-два-нольных сайтов, которые предъявляют побольше требований к качеству UI, чем просто сайты-визитки.
Ну хрен знает, не видел я еще PDF-документа, который бы реально подстраивался под разную ширину экрана. Вот я читаю журналы под андроид, портированные с айпада. Знаете как оно подстраивается под 16:9? Черными полосками по краям! А если я нехочу смотреть журнал в горизонтальном положении, а в вертикальном (так удобнее держать) то интерактивный журнал вместо страниц выдает надпись «Поверните Айпад».
В общем не видел я этих чудес резиновости. Покажите пример что-ли.
В общем не видел я этих чудес резиновости. Покажите пример что-ли.
В том-то и дело что проще. Сверстайте даже небольшую статью, чтоб при распечатке из браузера или издательского пакета (пускай даже Ворда) она выглядела хоть примерно одинаково. Почему-то мне кажется, что с HTML/CSS вы куда больше промучаетесь
Я делаю нормальные, полноценные веб-приложения на JS/HTML/CSS, делаю я их как под IE6 так и под современные браузеры. И я бы не сказал, что использую просто неимоверное кол-во хаков, но, да приходится делать иногда делать отдельные стили для IE6-8. По поводу Flex это фактически тот же самый набор технологий Flash/XML/CSS, и разметка там кстати еще страшнее чем HTML. Единственный плюс — не нужно думать о кроссбраузерности. По поводу разработки Flex приложений, последний раз когда я это делал, Flex Builder, был страшно тормозной, и делать в нем серьезные приложения в визуальном редакторе было достаточно проблематично, даже на по тем временам неплохим Core 2 Duo и 2Гб памяти. Да и походу вы, видимо, не сталкивались с переработкой тем для Flex приложений.
И это я уже не говорю о том, что в недалеком будущем, ie8 останется в основном в корпоративном секторе.
И я поздравляю вас! Ваше будущее уже наступило 10 лет назад — Dreamweaver.
По поводу почему приложения делают для моб. платформ нативными, как минимум можно отметить — монетизация, офлайн режим, наличие различных контроллеров ввода.
И это я уже не говорю о том, что в недалеком будущем, ie8 останется в основном в корпоративном секторе.
И я поздравляю вас! Ваше будущее уже наступило 10 лет назад — Dreamweaver.
По поводу почему приложения делают для моб. платформ нативными, как минимум можно отметить — монетизация, офлайн режим, наличие различных контроллеров ввода.
А когда Вы в последний раз использовали Flex Builder?
Вроде я пользовался второй и немного третей версией. Про неплохой я имею ввиду для программирования.
С тех пор много чего изменилось. Flex 3 допиливали. Во Flex 4 скин для компонент задаётся отдельными классами, таким образом, внешний вид полностью отделили от логики.
Ну а Flex 2, и в правду, был ещё тот цирк.
Ну а Flex 2, и в правду, был ещё тот цирк.
Ясно. Кстати, насколько я понял adobe прекратил поддержку Flex и Air?
Поддержку AIR прекратили только для десктопных линуксов, Андроида это не касается.
Flex SDK передали Apache Software Foundation. Уже Flex 3 был под мозиловской лицензией. Будут делать ребрендинг. При этом сам Adobe продолжает его развивать, по крайней мере, адобовская команда продолжает коммитить, и Flex доступен для скачивания с ресурсов Адоба. А от Flash Builder-а Adobe не отказывался.
Flex SDK передали Apache Software Foundation. Уже Flex 3 был под мозиловской лицензией. Будут делать ребрендинг. При этом сам Adobe продолжает его развивать, по крайней мере, адобовская команда продолжает коммитить, и Flex доступен для скачивания с ресурсов Адоба. А от Flash Builder-а Adobe не отказывался.
Вроде я пользовался второй и немного третей версией. Про неплохой я имею ввиду для программирования.
Нет, я бы предпочел концепцию «сайт как база данных».
Мне пофиг на красивости, на дизайн и на форматирование. Чем меньше верстки — тем лучше. Обожаю старые сайты американских университетов, которые сделаны на самом древнем html.
Мне нужно чтобы была семантика, и чтобы все это можно было удобно скачать без дурацких баннеров и прочей креативщины. Скачать чистую информацию и положить в личную базу данных. Или даже запустить своего личного поискового робота, который сам найдет то что мне может быть интересно и разложит по полочкам. Вот:)
Мне пофиг на красивости, на дизайн и на форматирование. Чем меньше верстки — тем лучше. Обожаю старые сайты американских университетов, которые сделаны на самом древнем html.
Мне нужно чтобы была семантика, и чтобы все это можно было удобно скачать без дурацких баннеров и прочей креативщины. Скачать чистую информацию и положить в личную базу данных. Или даже запустить своего личного поискового робота, который сам найдет то что мне может быть интересно и разложит по полочкам. Вот:)
Это не вопрос технологии. Это вопрос востребованности контента и его оплаты. Указанные страницы прекрасно можно создавать и в наше время. Без баннеров и прочей креативщины. Только кто будет платить разработчикам и авторам? Меценаты что-то не находятся.
Хотя я вот хочу создать подобный проект. Но там своя область в виде филологи и лингвистики которые будут интересны только тем, кому интересны эти области.
Хотя я вот хочу создать подобный проект. Но там своя область в виде филологи и лингвистики которые будут интересны только тем, кому интересны эти области.
Э… дрюг а как же банЭры показывать? Это же деньги, братюня — ты таких вредных вещей больше не думай, да?
> нормальное, полноценное приложение
Не имею ничего против flash, но удобство его элементов (например, ссылки и полосы прокрутки) хуже, чем у стандартных. Множество раз встречал отсутствие прокрутки колесиком мышки. Хотя можно возразить, что это вина программиста, но в html такой проблемы попросту нету.
Не имею ничего против flash, но удобство его элементов (например, ссылки и полосы прокрутки) хуже, чем у стандартных. Множество раз встречал отсутствие прокрутки колесиком мышки. Хотя можно возразить, что это вина программиста, но в html такой проблемы попросту нету.
Попытки создать язык/платформу с визуальным редактором в котором «сможет каждая домохозяйка программировать» предпринимались очень давно. И безуспешно. И приводило это в итоге к дефициту специалистов в отрасли. Так что нет, не нужно нам этого.
Каждый должен заниматься своим дело. Инструмент который облегчает работу с кодом (не важно каким) должен быть. Но какая-то визуальная хрень где, теоретически, можно написать приложение… нет. Хватит уже наступать на одни и теже грабли.
Каждый должен заниматься своим дело. Инструмент который облегчает работу с кодом (не важно каким) должен быть. Но какая-то визуальная хрень где, теоретически, можно написать приложение… нет. Хватит уже наступать на одни и теже грабли.
О боги! Ну так сделайте визуальный редактор для HTML5+CSS3. Вы думаете в коде новоизобретённого языка будет меньше костылей?
Понятно, что в отличии от полноценного десктопного приложения, у веб-разработчиков нет выбора — только HTML, CSS и JS, но для меня, как для веб-разработчика, пусть и при наличии этих самых костылей, вряд найдётся инструмент удобнее, чем созданный веб-разработчиками для веб-разработчиков.
Понятно, что в отличии от полноценного десктопного приложения, у веб-разработчиков нет выбора — только HTML, CSS и JS, но для меня, как для веб-разработчика, пусть и при наличии этих самых костылей, вряд найдётся инструмент удобнее, чем созданный веб-разработчиками для веб-разработчиков.
Нужен какой-нибудь мощный и гибкий Two Step View фреймворк.
Согласен с автором. HTML должен умереть. Даешь вектор! Даешь SVG и канву.
И еще HTTP должен умереть! Эта этой идеологии запрос-ответ уже больше 30 лет. Он тоже приводит к хакам, извращениям и шаманствам, когда надо сделать что нибудь чуть сложнее чем считать небольшие данные по небольшому запросу.
Ага и квантовые компьютеры с батарейками на термоядерном синтезе!
Это семантически бессмысленные и нечитаемые другими программистами конструкции.
Это наблюдение справедливо. Открыв код страницы
Но без подобных вещей невозможно сверстать современныйвеб-два-нольный сайт.
В справедливости этого помысла я не очень уверен. Насколько я помню, в Twitter Bootstrap извращений не так много.
> в Twitter Bootstrap извращений не так много.
Но они есть.
Но они есть.
Может быть там и меньше извращений, но это потому, что они очень далеки от детальности проработки (даже чисто визуальной) приведенного в посте интерфейса блокнота из OS/2, а это интерфейс двадцатилетней давности… Тогда еще не было (как Вы помните) даже аппаратной акселерации градиентных заливок или наложений в графических картах, прозрачности и т.п. Тем не менее, старый добрый интерфейс в сравнении даже с лучшими образцами современных web-интерфейсов смотрится как эталон совершенства и usability.
Тот, кто действительно с таким уровнем проработки воспроизведет его кроссбраузерно на CSS/HTML/JS, сможет продавать библиотеку за сотни долларов другим разработчикам, или его компанию за неплохие (не говорю, что очень большие – но не плохие) деньги купит FB или Google. :)
Тот, кто действительно с таким уровнем проработки воспроизведет его кроссбраузерно на 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, js, php и т.д. страдать или изобретать велосипеды, а можно жить с этим и даже зарабатывать на этом деньги.
Это я все к тому, что html и css никуда не денется, каким бы плохим/хорошим он не был.
А php то сюда зачем относить? Многие люди вполне успешно используют адекватные языки типа python/ruby/java/c# для веб-like вещей.
Насколько я понимаю изначально был простой текстовый статический HTML, в который позже начали добавлять формы, интерактивность и пр. Т.е. делать из языка для разметки статьи в Web, язык для web-приложений, что и дало нам столько костылей в сопуствующих станадартах. Нужно было разрабатывать отдельный язык под новые потребности, а не «улучшать» то, что было.
Насчёт своих языков разметки — есть XAML, но он по разным причинам пока не получил такого же распространения как существующие разметочные языки.
Насчёт своих языков разметки — есть XAML, но он по разным причинам пока не получил такого же распространения как существующие разметочные языки.
Боюсь что «пока не получил распространения» это уже посметрно
Кто знает. Возможности этого языка разметки значительно превышают HTML. Не XAML, так какой-то другой язык с похожими принципами когда-нибудь, возможно, заменит HTML.
Хотя, мне кажется, в HTML будут и дальше копировать новые костыли, а старые будут отмирать. И в итоге мы получим совсем другой язык. Как это было с эволюцией JS, или того же ActionScript.
Хотя, мне кажется, в HTML будут и дальше копировать новые костыли, а старые будут отмирать. И в итоге мы получим совсем другой язык. Как это было с эволюцией JS, или того же ActionScript.
Я отношусь ко XAML как к итогу применения Корпорацией Microsoft принципа NIH («not invented here») к языку XUL, придуманному Фондом Мозиллы несколькими годами ранее почти для совершенно той же цели — для декларативного описания интерфейсов при помощи XML.
Кстати, один из XML-подобных языков, на которых, к слову, написан наш Apache Openmeetings, — это OpenLaszlo (названный так, если кто не знает, в честь кота Ласло).
OpenLaszlo компилируется и во Flash, и в HTML5. Конечно, если вы поработаете с ним немного, заметите и недостатки. Но если вам что-то не нравится в этом языке (мы бы хотели чуть более хорошую поддержку HTML5) — присылайте патч и улучшайте. Это же свободный проект.
OpenLaszlo компилируется и во Flash, и в HTML5. Конечно, если вы поработаете с ним немного, заметите и недостатки. Но если вам что-то не нравится в этом языке (мы бы хотели чуть более хорошую поддержку HTML5) — присылайте патч и улучшайте. Это же свободный проект.
Немного полистал документацию по OpenLaszlo. Поддержки html5 не нашел, но нашел поддержку dhtml (java + html), и Flash… Пардон, но по-моемому «те же яйца, только в профиль». Или я не там или так смотрю?
Ну там все на layouts. Я даже вводную статью по лазле писал здесь на хабре.
Если сравнивать с яйцами, то тогда яйца — это flex.
А с каких это пор DHTML стал HTML + Java? Википедия кагбе намекает, что это HTML + JavaScript + CSS + DOM.
У лазлы немного идеология другая. И, как по мне, верстать там гораздо легче.
XML в языках разметки это злоЪ, лучше уж QML допилить для веба. Впрочем, он уже прекрасно для него подходит :)
html, css уже прочно сидят в web. И так просто перейти на что-то новое не получится.
Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS. В результате кто-то из вас придумает мощную и кристально ясную замену этому историческому наслоению хаков.По-моему, в результате такого подхода появится куча конкурентоспособных языков, каждый из которых верстальщикам придётся изучить, чтобы зарабатывать на хлеб. Разве это лучше, чем знать тот же HTML?
Дело в том, что сама потребность в 75% верстальщиков отпадет, если будет разработан семантически чистый, читаемый язык разметки. Если к нему добавить еще и визуальный редактор, то отпадет необходимость в 99% верстальщиков.
а щас он какой? не симантически чистый?
используте его как симантически чистый, а красоту наводите с помощью CSS.
используте его как симантически чистый, а красоту наводите с помощью CSS.
Сейчас в HTML нужно вставлять div-ы просто для того, чтобы затем можно было бы правильно все сверстать. Я уж не говорю о эмиссии лишних элементов ради разных теней и круглых углов у квадратов не поддерживаемых в IE.
> Я уж не говорю о эмиссии лишних элементов ради разных теней и круглых углов у квадратов не поддерживаемых в IE.
Progressive еnhancement, например
Progressive еnhancement, например
Дико сомневаюсь, что только с помощью CSS можно навести любую красоту, не трогая произвольную логическую разметку. Даже если иметь в виду только последние релизы популярных браузеров.
Знать css и html всё равно придётся, но используя надстройки над ними (изучение которых много усилий не потребует) можно здорово повысить свою производительность и читаемость получаемого кода.
Подобные вещи уже существуют — slim (или haml) и sass (или less) и вовсю используются в определённых кругах.
Подобные вещи уже существуют — slim (или haml) и sass (или less) и вовсю используются в определённых кругах.
Существует 14 конкурирующих стандартов
— Это нелепо! нам надо изобрести один универсальный стандарт, который покроет все возможные случаи.
— Точно!
Вскоре: Существует 15 конкурирующих стандартов
— Это нелепо! нам надо изобрести один универсальный стандарт, который покроет все возможные случаи.
— Точно!
Вскоре: Существует 15 конкурирующих стандартов
Не так давно Николас Закаш говорил, что порабы уже отказаться от стремления сделать сайт одинаково отображающимся во всех браузерах, включая устаревшие, приводя в пример развитие телевещания: там никто не пытается показать цветную картинку на чернобелом телевизоре, там все вещают как могут, а дальше уже ваше дело — обновлять вам телевизор или смотреть показывается.
Если бы не подход эмулирования недостающих функций, то возможно архитектура несколько была бы чище. Правда остается факт, без которого бурное развитие веб технологий был бы не возможно: внедрение еще нестандартизированного и не принятого другими разработчиками браузеров набора технологий. Что тоже вносит свою долю бардака в архитектуру.
Если бы не подход эмулирования недостающих функций, то возможно архитектура несколько была бы чище. Правда остается факт, без которого бурное развитие веб технологий был бы не возможно: внедрение еще нестандартизированного и не принятого другими разработчиками браузеров набора технологий. Что тоже вносит свою долю бардака в архитектуру.
А теперь объясните заказчику почему его сайт отображается как «чернобелый» у клиента, хотя может отображаться как цветной.
Возможно, все наладится, когда браузеры будут обновляться незаметно от пользователя и не нужно будет заботиться об устаревших браузерах. Chrome с самого начала такой (он и занимает первое место по России), FF пришел к этому на 12 версии, IE должен будет обновляться через Microsoft Update — хотя, это и не так хорошо как система Chrome и FF. Вот Опера пока, вроде бы, не хвастается ничем подобным.
Верстальщики не одобряют этот пост
Вся статья построена на одном большом передёргивании.
Совершенно согласен, что, вследствие некорректной реализации стандартов в старых браузерах, приходится писать разные хакие, которые несемантичны и засоряют код.
Однако, какое это отношение имеет к декларируемой «бессистемности в архитектуре», позвольте спросить? Не приведено ни единого аргумента в пользу этого рассуждения, кроме странного замечания про img и ol.
Нет уж, позвольте, HTML/CSS, неважно какой версии, архитектурно выстроен прекрасно. С чего автор вдруг предлагает искать ему замену?
Мощную замену историческому наложению хаков придумать невозможно, пока не умрут старые браузеры. Абсолютно непонятно, зачем нужно придумывать новые языки разметки, если можно спокойно писать на HTML5/CSS3 и транслировать его в HTML/CSS для старых браузеров.
В общем, классическая подмена понятий.
Современная web-технология, основанная на CSS/HTML (включая даже HTML5/CSS3) – это апофеоз бессистемности в архитектуре и фрагментации. Бессистемность в начальном дизайне и последующее наложение на нее фрагментации из-за несовместимых реализаций в браузерах породили каскады хаков для латания дыр.
Совершенно согласен, что, вследствие некорректной реализации стандартов в старых браузерах, приходится писать разные хакие, которые несемантичны и засоряют код.
Однако, какое это отношение имеет к декларируемой «бессистемности в архитектуре», позвольте спросить? Не приведено ни единого аргумента в пользу этого рассуждения, кроме странного замечания про img и ol.
Нет уж, позвольте, HTML/CSS, неважно какой версии, архитектурно выстроен прекрасно. С чего автор вдруг предлагает искать ему замену?
Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS. В результате кто-то из вас придумает мощную и кристально ясную замену этому историческому наслоению хаков.
Мощную замену историческому наложению хаков придумать невозможно, пока не умрут старые браузеры. Абсолютно непонятно, зачем нужно придумывать новые языки разметки, если можно спокойно писать на HTML5/CSS3 и транслировать его в HTML/CSS для старых браузеров.
В общем, классическая подмена понятий.
HTML будет лаконичным в любом случае. С нынешними стандартами, есть целая куча возомжностей, чтобы следовать парадигме: HTML — содержимое, CSS — отображение, и писать чистый и семантический HTML без оглядки на дизайн.
С CSS немного посложнее, там отсутствуют переменные, переиспользование правил и т.п., и в оригинале он не будет таким чистым. Но есть решения, в виде LESS или SASS.
С CSS немного посложнее, там отсутствуют переменные, переиспользование правил и т.п., и в оригинале он не будет таким чистым. Но есть решения, в виде LESS или SASS.
HTML — содержимое, CSS — отображение, и писать чистый и семантический HTML без оглядки на дизайн
Покажите мне сайт с нетривиальным дизайном, в котором нет <div class="wrapper">…
Нетривиальный, как и wrapper — понятия растяжимые. Введение wrapper'а на текущем уровне CSS в 100% случаев значит либо кривые руки, либо неправильное понимание структуры содержания.
Нет, не означает. Дело даже не в внешнем виде, а скажем масштабируемости и управляемости. Цели знаете, они разные бывают.
Ну приведите пример, где без wrapper'a не обойтись, при этом он совершенно ничего не значит с точки зрения содержания?
Всегда можно без чего-то обойтись. Например, машина вполне может обойтись без корпуса. Начинка и сиденья, но зачем без него обходится, если с ним легче. Wrap'ом многие злоупотребляют, да.
У меня есть сайдбар, в нем три блока с одинаковыми отступами и оформлением (например, полоса под каждым блоком и тень), но разным содержанием, например, опрос, новости, и баннер. Я могу сделать так: div.someblock.banner, но сделаю так: div.sidebarBlock>div.banner. Во-первых это интуитивнее, во-вторых, если я могу легко управлять содержимым sidebarBlock, например, добавить текстовые блоки, да, вообще, что-угодно и код при этом будет очень аккуратный.
Игнорировать подобное, это как если бы вы программировали без функций или классов. Можно, но зачем?
У меня есть сайдбар, в нем три блока с одинаковыми отступами и оформлением (например, полоса под каждым блоком и тень), но разным содержанием, например, опрос, новости, и баннер. Я могу сделать так: div.someblock.banner, но сделаю так: div.sidebarBlock>div.banner. Во-первых это интуитивнее, во-вторых, если я могу легко управлять содержимым sidebarBlock, например, добавить текстовые блоки, да, вообще, что-угодно и код при этом будет очень аккуратный.
Игнорировать подобное, это как если бы вы программировали без функций или классов. Можно, но зачем?
Забавно: мы говорим об одном и том же. Вы привели пример, когда с точки зрения содержания (иными словами структуры, или логики) wrapper имеет смысл, и этот смысл вы передали через класс .sidebarBlock. Я говорю о врапперах, созданных с целью создания выравнивания по центру, к примеру, или оформления тени, или создания каких-то прочих визуальных эффектов.
Неужели в современных браузерах можно добиться любого взаимного расположения блоков не трогая HTML? Скажем содержимое одного блока (сайдбара) расположить вокруг другого (контента), когда в HTML эти блоки на одном уровне.
Вокруг? Вы об этом?
Хоть это и пахнет с точки зрения типографики, мне тоже интересно было, как это сделать в html. Думаю, это что-то близкое к заполнению формы текстом в svg.
Но скажите, как тут враппер поможет?
Хоть это и пахнет с точки зрения типографики, мне тоже интересно было, как это сделать в html. Думаю, это что-то близкое к заполнению формы текстом в svg.
Но скажите, как тут враппер поможет?
Что-то вроде. А не поможет обернуть оба блока враппером, один разместить относительно, другой абсолютно, а содержание второго флоатить часть влево, часть вправо? Что-то такое помню мелькало в голове, когда коммент писал :)
Да нет, к сожалению, решение не подойдет: тут проблема глубже — предложения-то идут «сквозь» рисунок.
Я не специалист в этом деле, но тут просто иначе работает алгоритм размещения текста. Он его размещает не по прямоугольной форме, а по кастомной «векторной».
Можно было-бы искусственно вставлять пробелы в места размещения прямоугольника, образуя прямоугольник. Но это был бы уже жестокий костыль, хотя методически верный.
Я не специалист в этом деле, но тут просто иначе работает алгоритм размещения текста. Он его размещает не по прямоугольной форме, а по кастомной «векторной».
Можно было-бы искусственно вставлять пробелы в места размещения прямоугольника, образуя прямоугольник. Но это был бы уже жестокий костыль, хотя методически верный.
Ах, да. Пример.
Хаха, теперь с введением новых тегов HTML5 «врапперы» стали узаконенной «семантикой»: footer, header, section и т. п. :) Под врапперами я имел в виду любые элементы, которые вы никогда бы не написали, если бы не нужно было стилизовать страницу. Вот канонический пример из кода приведённой страницы:
Вёрстка чистая, мне нравится. Но сути дела это не меняет.
<div class="container">. Этот блок существует только для того, чтобы наложить на него стиль. Это не содержимое, не семантика, это — кусок стиля. Если вам понадобится другой дизайн, то «контейнер» может спокойно понадобиться в другом месте, а необходимость в этом отпадёт.Вёрстка чистая, мне нравится. Но сути дела это не меняет.
В этой частности вы неправы. В этой верстке я сначала полностью без стилизации, только по смыслу писал html, затем стилизовал то, что написал. .container значит страницу, его можно было назвать .page, или .content — как хотите, визуально он несет смысл.
Но в целом вы правы — пока что есть еще вещи, неудобные для стилизации, например, выравнивание блока по правому краю так, чтобы он и высоту имел, и левый блок занимал все свободное место. Но благо это не требует wrapper'а.
В целом я помню только один случай неизбежности wrapper'a, и именно этот (jsfiddle — нужно ресайзить высоту блока). Но даже тут .widget-body имеет смысл.
Но в целом вы правы — пока что есть еще вещи, неудобные для стилизации, например, выравнивание блока по правому краю так, чтобы он и высоту имел, и левый блок занимал все свободное место. Но благо это не требует wrapper'а.
В целом я помню только один случай неизбежности wrapper'a, и именно этот (jsfiddle — нужно ресайзить высоту блока). Но даже тут .widget-body имеет смысл.
Конечно.
Я вот недавно делал top-books.info и забил на IE. Вполне лаконичный код, никаких избыточностей. Я с огромным удвольствием верстал.
А это я ещё всяких HTML5-ых плюшек не использовал.
Я вот недавно делал top-books.info и забил на IE. Вполне лаконичный код, никаких избыточностей. Я с огромным удвольствием верстал.
А это я ещё всяких HTML5-ых плюшек не использовал.
Аминь. В своих проектах смог полностью отказаться от html и css заменив их javascript'ом, тем самым дав себе возможность создавать обёртки для различных хаков, и в итоге писать чистый и понятный код.
Хотя на самостоятельный язык разметки это разумеется не тянет. Просто украшение существующего бардака.
Хотя на самостоятельный язык разметки это разумеется не тянет. Просто украшение существующего бардака.
Можете показать 1 из ваших проектов?
Присоединяюсь к вопросу.
как пример, можно зайти на мой сайт tenphi.com/
или сразу открыть файл tenphi.com/scripts.js и посмотреть его с конца (там идет код приложения).
там есть немного мусора вроде socket.io, это всё потому, сайт временно запущен в dev-режиме.
там есть и styles.css но он сгенерирован, можно в скриптах найти этот код, в dev-режиме он не вырезается.
или сразу открыть файл tenphi.com/scripts.js и посмотреть его с конца (там идет код приложения).
там есть немного мусора вроде socket.io, это всё потому, сайт временно запущен в dev-режиме.
там есть и styles.css но он сгенерирован, можно в скриптах найти этот код, в dev-режиме он не вырезается.
На сайте tenphi.com уже куча ляпов в вёрстке, которые точно вызовут баги и проблемы производительности в будующем, это учитывая что на сайте кроме меню и оформления статьи еще ничего нету.
Такую страницу правильно сверстать займёт едва ли пол часа, сколько времени на неё портатили вы? Про проблемы с поддержкой кода в будующем вообще молчу.
Такую страницу правильно сверстать займёт едва ли пол часа, сколько времени на неё портатили вы? Про проблемы с поддержкой кода в будующем вообще молчу.
ну саму верстку? полчаса — час… не помню… там же верстать то нечего можно сказать.
основную часть времени я потратил на переключение страниц без перезагрузки. плюс еще с помощью socket.io реализовал моментальную подгрузку всех изменений без перезагрузки страницы. это у меня такой маленький полигон для идей.
то что есть ошибки… это уже вероятно моя вина, а не технологии. буду признателен если вы мне укажите на них с помощью PM.
основную часть времени я потратил на переключение страниц без перезагрузки. плюс еще с помощью socket.io реализовал моментальную подгрузку всех изменений без перезагрузки страницы. это у меня такой маленький полигон для идей.
то что есть ошибки… это уже вероятно моя вина, а не технологии. буду признателен если вы мне укажите на них с помощью PM.
Если уж делаете современный ajax-сайт, ознакомьтесь с AJAX crawling scheme.
я с ней ознакомлен уже давно, но зачем оно мне?
мои шаблоны умеют собираться как на сервере (nodejs) так и на клиенте, в итоге поисковику отдаётся html страницы содержащей ссылки на другие страницы. когда он переходит по этим ссылкам, то ему отдаётся содержимое уже другой страницы. это уже проверено и это работает. в этом кстати большой плюс моего подхода.
или быть может я неправильно вас понял?
мои шаблоны умеют собираться как на сервере (nodejs) так и на клиенте, в итоге поисковику отдаётся html страницы содержащей ссылки на другие страницы. когда он переходит по этим ссылкам, то ему отдаётся содержимое уже другой страницы. это уже проверено и это работает. в этом кстати большой плюс моего подхода.
или быть может я неправильно вас понял?
смог полностью отказаться от html и css заменив их javascript'ом, тем самым дав себе возможность создавать обёртки для различных хаков, и в итоге писать чистый и понятный кодПолный отказ от HTML? Лолшто?
'/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 как язык разметки.
в примере можно всё заменить на другие конструкции типа ['Header', 'Text of header'] предварительно создав обёртку. в итоге получится чтото совсем новое.
ну и разумеется свободная параметризация для шаблонов. в HTML такого нету.
хотя что я вам объясняю, вам же не интересно.
уже сильно жалею что дал ссылку, в следующий раз буду использовать для этого PM.
в примере можно всё заменить на другие конструкции типа ['Header', 'Text of header'] предварительно создав обёртку. в итоге получится чтото совсем новое.
ну и разумеется свободная параметризация для шаблонов. в HTML такого нету.
хотя что я вам объясняю, вам же не интересно.
уже сильно жалею что дал ссылку, в следующий раз буду использовать для этого PM.
Ваш метод — не что-то новое, подобное «избавление от HTML» используется в библиотеках типа ExtJS. Правда там мощнее и, соответственно, пропорционально ужаснее.
У вас же это HTML на S-выражениях =)
И судя по тому, что вы пишете про другие конструкции — вы на пути к реализации половины Лиспа.
Не пробовали на нем писать?
И судя по тому, что вы пишете про другие конструкции — вы на пути к реализации половины Лиспа.
Не пробовали на нем писать?
Оно рабочее, но оно страшное :)
Проблема в том, что html до сих пор разрабатывается с использованием метафор страниц, газетных статей и тому подобного. Пока вы остаетесь при верстке в рамках тех же метафор — все работает.
Но если вы хотите сверстать интерфейс, а не статью, то наступает полная…
Но если вы хотите сверстать интерфейс, а не статью, то наступает полная…
Да, но в этом-то как раз и проблема — сейчас любой более-менее серьезный веб-проект — это «интерфейс», а не «газета».
Именно. Сравните с XAML тем же. Вроде бы тот же самый xml-based, но насколько все проще. Потому что метафоры изначально именно интерфейсные.
Точно. Ну, как XAML (.NET), так и MXML (Flex) изначально для этого создавались и в них _изначально_ все необходимое для разметки лэйаутов. То есть, даже ничего придумывать не нужно — все «из коробки».
Самое интересное — в них тоже есть CSS (собственно, CSS в MXML и ресурсы для XAML). То есть, стили, то «как оформлено» хранится отдельно от того, «что оформлено». Там стили используются строго по назначению — именно оформить что-то визуально. Структура же, вложенность, позиционирование, лэйауты и прочее сделаны НЕ через стили. Для позиционирования и разметки изначально есть необходимые семантические элементы.
И это, на мой взгляд, самый большой недостаток CSS и HTML — если файл стиля убрать — страница потеряет не только цвета, оформление и красивости — порушится сама структура документа.
То есть, по сути, верно — HTML и CSS реально «не подходит» для интерфейсов. Но нет выбора.
Самое интересное — в них тоже есть CSS (собственно, CSS в MXML и ресурсы для XAML). То есть, стили, то «как оформлено» хранится отдельно от того, «что оформлено». Там стили используются строго по назначению — именно оформить что-то визуально. Структура же, вложенность, позиционирование, лэйауты и прочее сделаны НЕ через стили. Для позиционирования и разметки изначально есть необходимые семантические элементы.
И это, на мой взгляд, самый большой недостаток CSS и HTML — если файл стиля убрать — страница потеряет не только цвета, оформление и красивости — порушится сама структура документа.
То есть, по сути, верно — HTML и CSS реально «не подходит» для интерфейсов. Но нет выбора.
Позиционирование и лэйоты разве не относятся к визуальному оформлению? Хотя бы потому что на разных размера экрана и/или разных устройствах вывода они могут быть совершенно разными.
Да, я тоже уже думаю над этим. Для таких современных фич как поддержка множества девайсов, responsive-дизайна, итд, нельзя зажать все рамками элементов отдельно выбранного представления. И у меня нет ответа «как нужно». CSS, как ни крути, тоже не выглядит идеальным местом для этого. Но, пожалуй, лучше HTML-элемента с фиксированной layout-семантикой.
Да и при верстке статьи наступает полная <censored> если нужно сверстать ее в несколько колонок, с картинками и списками, и чтобы все правильно обтекалось текстом и картинки не улетали хз куда. Даже для таких элементарных целей потребуется знание CSS и его особенностей в разных браузерах за пределами того, что может изучить даже продвинутый пользователь. И этого не поддерживают в полной мере визуальные web-редакторы, даже Google Docs слаб в стилях и средне-сложной верстке в режиме статьи. Хотя он – шедевр HTML/CS и JavaScript-программирования.
Колонки недоработаны, согласен.
Особенно по сравнению с разного рода tex и word, которые используют те же метафоры и аналогичную структуры.
Особенно по сравнению с разного рода tex и word, которые используют те же метафоры и аналогичную структуры.
А действительно ли нужны колонки на экране?
Я понимаю зачем они в газете — ширина колонки выбрана так, чтобы ее можно было читать вертикально методами скорочтения. Так же это помогает складывать ее достаточно компактно и читать в транспорте. Если не будет рядом несколько колонок, то газету придется «прокручивать» — переворачивать и по-всякому складывать, чтобы дочитать колонку до конца.
А на экране это зачем? Достаточно менять ширину экрана и каждый читает так как ему удобнее. Прокрутка никаких проблем не представляет.
Я понимаю зачем они в газете — ширина колонки выбрана так, чтобы ее можно было читать вертикально методами скорочтения. Так же это помогает складывать ее достаточно компактно и читать в транспорте. Если не будет рядом несколько колонок, то газету придется «прокручивать» — переворачивать и по-всякому складывать, чтобы дочитать колонку до конца.
А на экране это зачем? Достаточно менять ширину экрана и каждый читает так как ему удобнее. Прокрутка никаких проблем не представляет.
Нужны. Просто забейте свою первую фразу в гугл, он вам много чего расскажет словами порой весьма авторитетных людей.
А при чтении с экрана скорочтение не нужно? Да и просто при чтении на большом широком экране сложно глазами водить с левого края на правый и обратно, по двум колонка (с пагинацией) было бы проще.
В HTML/CSS все не так уж плохо. В верстке для современных браузеров картина значительно лучше того, чем приходилось заниматься лет 5-7 назад.
Но хаки — да, не поспоришь совершенно. И это благодаря тому, что до сих пор (2012!!!) отсутствуют человеческие layout'ы. Заметьте, абсолютное большинство хаков — для того, чтобы создать тот или иной лэйаут. Это бесит немыслимо, ибо многое в итоге делается через жопу и все равно где-то, да валится.
Но хаки — да, не поспоришь совершенно. И это благодаря тому, что до сих пор (2012!!!) отсутствуют человеческие layout'ы. Заметьте, абсолютное большинство хаков — для того, чтобы создать тот или иной лэйаут. Это бесит немыслимо, ибо многое в итоге делается через жопу и все равно где-то, да валится.
И испытывающий какой-то колоссальный баттхёрт
Ну, баттхерт то при использовании указанных в топике технологий, испытывают все :)
Не верстаете сложных интерфейсов? :)
Вообще, это был легкий и непринужденный сарказм, со смайликом в конце предложения, все как положено. А вы начали придираться к словам. Ежу понятно, что во многих случаях никакого особого баттхерта и не будет. Однако, технология неидеальна, и все это понимают. А я тут, почему-то, строю Кэпа, отвечая на ваш комментарий :)
По-моему, его испытывают все, кто пытается в первый раз сверстать трехколоночную вёрстку с прибитым футером.
Столкнувшись перед этим, к примеру, с .NET (а именно — часть .NET, которая обеспечивает создание интерфейсов), а после с HTML/CSS я действительно испытываю дикий баттхерт.
Особенно дикий баттхерт я испытываю, когда вижу, что приложение типа «на все браузера», скроллится вниз, а внизу — пустое место.
Еще более дикий баттхерт я испытываю, видя объем потребляемого ОЗУ.
Особенно дикий баттхерт я испытываю, когда вижу, что приложение типа «на все браузера», скроллится вниз, а внизу — пустое место.
Еще более дикий баттхерт я испытываю, видя объем потребляемого ОЗУ.
А можно поставить всем по Silverlight'у
Во первых Moonlight, во-вторых html же поддерживают и не обламываются.
Вы почему то к IE цифру приписали, а к ML не приписали. Без этого аналогия не получилась?
«молодому» HTML до даже до moonlight такими темпами расти ещё лет 20. Непонятно только зачем растить HTML до SL, если можно просто взять SL.
«молодому» HTML до даже до moonlight такими темпами расти ещё лет 20. Непонятно только зачем растить HTML до SL, если можно просто взять SL.
Вы, кажется, забыли прочитать коммент, на который отвечаете. Я вам даже ссылку дам — habrahabr.ru/post/143342/?reply_to=4805348#comment_4805060
Моя вина, не полностью ответил. Да всем, да на и линукс, да и на айпады, да будут поддерживать. Теперь нормуль?
Десятки лет служения человечеству в ИТ далеко не всегда достоинство, как правило оно означает ещё и груз обратной совместимости, ту самую логику процесса. И, да, бессистемность видна особенно при понимании логики. Когда из языка (или другого инструмента) пытаются сделать то, для чего он предназначался, пытаясь сохранить обратную совместимость тогда результат видится бессистемным.
HTML вроде позиционировался как язык логической разметки гипертекста. Было ли системным введением в него элементов визуального оформления? PHP был создан как шаблонизатор, плавно перетекший в процедурный язык для веба — системно ли введение в него элементов ЯП общего назначения, ООП, ФП?
То что логика процесса ясна, совсем не гарантирует хороший результат. Особенно когда логика близка к «и рыбку съесть, и ...».
HTML вроде позиционировался как язык логической разметки гипертекста. Было ли системным введением в него элементов визуального оформления? PHP был создан как шаблонизатор, плавно перетекший в процедурный язык для веба — системно ли введение в него элементов ЯП общего назначения, ООП, ФП?
То что логика процесса ясна, совсем не гарантирует хороший результат. Особенно когда логика близка к «и рыбку съесть, и ...».
Есть MS Word в котором без обучения в специальных школах любая девушка-секретарь легко и непринужденно за день сверстает статью. Так сверстает, как специально обученный CSS-верстальщик будет верстать неделю. И был dialog editor OS/2 20 лет назад в котором за 10 минут можно было визуально сконструировать вот тот блокнот в «резиновой» верстке, а в CSS его будут верстать и программировать на JS несколько месяцев, а может он превратится для кого-то в многолетний проект.
Если уж на то пошло — одна страница макета средней сложности верстается максимум за 4-8 часов времени. Без аврала и прочего.
А вот WYSIWYG и прочее — это уже не верстка, а так — как на Юкозе «сайт сделать».
А вот WYSIWYG и прочее — это уже не верстка, а так — как на Юкозе «сайт сделать».
А. Ну конечно.
Я-то про то, что даже весьма средненького уровня верстальщик может сверстать среднего уровня макет за один рабочий день. Так что сложность верстки весьма преувеличена. Равно как и «хаки и прочая ересь», зачастую они нужны только когда нужно сделать что-то из ряд вон выходящее.
Я-то про то, что даже весьма средненького уровня верстальщик может сверстать среднего уровня макет за один рабочий день. Так что сложность верстки весьма преувеличена. Равно как и «хаки и прочая ересь», зачастую они нужны только когда нужно сделать что-то из ряд вон выходящее.
Отрицательные поля/отступы входят в инструментарий средненького верстальщика или это всё же хаки?
Входят. Сложного в этом ничего нет, только проблема в верстке с отрицательными отступами и полями разобраться другому. Правда сейчас во всех браузерах есть инструментарий для отладки, так что понять чевойкуда уплывает можно, но все равно времени на разбор тратится больше. Именно поэтому не люблю доверстывать за другими.
Вот я к хакам отношу как раз то, с чем сложно разобраться другому. Когда вижу цифру -1000, то пытаюсь понять откуда она, почему именно -1000, а не -100500 или не -999. Комментарии к таким цифрам встречаются крайне редко (по-моему у верстальщиков с культурой комментирования ещё хуже, чем у программистов). А главное не только в чужой, но и в своей через полгода не всегда разберешься, если скопипастил откуда-то с «гугла», а из-за спешки (потому как сроки горят раз довёл до того, что гуглить пришлось) не закомментил.
ну конечна, вёрстка таблицы «пробелами», все с ней знакомы)
У word-а это получается (неплохо, хотя и с непреемлемыми глюками при сложной разметке) именно потому, что он использует свою модель всего — в том числе и внутренней разметки, а в CSS/HTML он только транслирует ее на финальном этапе записи. Если же редактор пишут сразу в расчете и в привязке к CSS/HTML, то получаются такие убогие (с точки зрения глючности работы и возможностей верстки) вещи, как CKEditor или TinyMCE. :)
Вы слишком хорошего мнения о девушках-секретаршах. До сих пор встречаю такие прелести, как центрирование текстов пробелами, абзацные отступы из тех же пробелов или табуляцией, неумение пользоваться даже самыми базовыми свойствами программы, о которой в резюме написано «свободное владение». О использовании стилей я вообще промолчу.
По поводу же трудностей CSS-верстальщика, вы сильно преувеличиваете. Сверстать статью в ворде и сделать этот же текстовый блок средствами CSS по времени различается не сильно. А если при этом пользоваться сторонними средствами (а не одним notepad.exe) — так и быстрее. Разница есть, но она в подходах.
По поводу же трудностей CSS-верстальщика, вы сильно преувеличиваете. Сверстать статью в ворде и сделать этот же текстовый блок средствами CSS по времени различается не сильно. А если при этом пользоваться сторонними средствами (а не одним notepad.exe) — так и быстрее. Разница есть, но она в подходах.
> которые делаются не потому, что без них никак, а потому, что они позволяют повысить кроссбраузерность
В большинстве случаев это и называется «без них никак».
В большинстве случаев это и называется «без них никак».
Валидатор? Он потерял смысл. В современном HTML(5) могут быть чёрт знает какие элементы и атрибуты.
Валидатор может помочь найти какие-то откровенные глюки, но часто он совершенно бесполезен. Например, я до сих пор не понимаю, зачем нужны жёсткие ограничения на вложенность элементов. С его точки зрения:
<span><div></div></span> — нельзя
<div style="display: inline"><span style="display: block"></span></div> — можно
Ну так внутри inline-блока, нельзя встраивать блочные, нужно использовать inline-block. Кроме того у HTML в браузерах есть некоторые особенности, например нельзя делать абзац в абзаце <p> — парсер браузера х просто вычистит. А например Chrome запрещает вложенные <form>, и вычищает их, тогда как другие браузеры — нет.
Пля. Ну это как вложенность «ВАЗ-2115» в «Печку ВАЗ-2115» и «Печка ВАЗ-2115» в «ВАЗ-2115».
Кстати, по-моему, самая большая проблема HTML/CSS как раз в том, что CSS задает «какие-то там» боксы. По моему, слишком многое отдано на откуп CSS. Хоть бери и держи в проектах по 2 набора CSS — один для структуры, другой — для, собственно, оформления. Для первого в идеале, конечно, нужны просто однозначные семантические элементы разметки (вместо безликого div).
Ммм, ну о том и речь.
На примере, лэйаутов — я бы предпочел тэги <vbox>, <hbox> с установленным по-умолчанию display: box и соответствующим box-orientation, <grid>, и так далее — то есть, элементы, изначально имеющие правильную семантику, чем кучу div-ов с необходимостью указывать это в CSS.
В идеале, при отключении CSS элементы не должны терять позицию. То есть, глядя только на HTML должно быть понятно, как будут расположены эти элементы.
P.S. Основа должна бы быть понятна без чтения спецификаций для такой распространенной технологии.
На примере, лэйаутов — я бы предпочел тэги <vbox>, <hbox> с установленным по-умолчанию display: box и соответствующим box-orientation, <grid>, и так далее — то есть, элементы, изначально имеющие правильную семантику, чем кучу div-ов с необходимостью указывать это в CSS.
В идеале, при отключении CSS элементы не должны терять позицию. То есть, глядя только на HTML должно быть понятно, как будут расположены эти элементы.
P.S. Основа должна бы быть понятна без чтения спецификаций для такой распространенной технологии.
HTML идеологически appearance agnostic язык, потому как служит для разметки структуры документа. Чтобы было понятно, как всё будет выглядеть из разметки нужно использовать соответствующий язык, с блекджеком и вбоксами :)
XUL вам в руки, например. Даже трансляторы есть в HTML/CSS, например в Ample SDK. Даже XBL можно юзать с помощью XBL.js
XUL вам в руки, например. Даже трансляторы есть в HTML/CSS, например в Ample SDK. Даже XBL можно юзать с помощью XBL.js
Ну, поскольку сейчас HTML используется для того, для чего не приспособен, по сути, то вполне себе правильное направление развития — становиться приспособленным для того, для чего его юзают.
Поменялось само значение термина документ, если хотите. Так что vbox, hbox в html смотрелись бы очень даже правильно.
Поменялось само значение термина документ, если хотите. Так что vbox, hbox в html смотрелись бы очень даже правильно.
Хотя, в этом что-то есть: «HTML идеологически appearance agnostic язык». Даже разные устройства могут показывать что-то по разному. Хотя vbox, hbox не кажутся мне такими уж особыми нарушениями. Тыща вложенных дивов ли не нарушение изначально заложенных идей. Спорная тема, впрочем.
То есть, глядя только на HTML должно быть понятно, как будут расположены эти элементы.
Я вот жду, не дождусь, когда будет наоборот. Когда глядя только на HTML я вообще не смогу строить хоть каких-то предположений о расположенности элементов. Естественно обфускацию не рассматриваю :) Хотя, скорее, я рассматриваю задачу с другой стороны — чтобы разрабатывая сервер-сайд мне не нужно было смотреть дизайн вообще, чтобы HTML писал я, не заботясь о визуальном отображении, а CSS писал верстальщик, причём не по моему HTML, а по дизайну. Всё взаимодействие которое нам с ним нужно должно заключаться в соглашениях об именованиях. Чтобы стандарт HTML был написан так, что исключал несемантическое использование тегов и не предоставлял выбор использовать div class=«nav» или nav.
Вряд ли это достижимо, но наличие, например, XSLT не оставляет надежды.
Я вот жду, не дождусь, когда будет наоборот. Когда глядя только на HTML я вообще не смогу строить хоть каких-то предположений о расположенности элементов. Естественно обфускацию не рассматриваю :) Хотя, скорее, я рассматриваю задачу с другой стороны — чтобы разрабатывая сервер-сайд мне не нужно было смотреть дизайн вообще, чтобы HTML писал я, не заботясь о визуальном отображении, а CSS писал верстальщик, причём не по моему HTML, а по дизайну. Всё взаимодействие которое нам с ним нужно должно заключаться в соглашениях об именованиях. Чтобы стандарт HTML был написан так, что исключал несемантическое использование тегов и не предоставлял выбор использовать div class=«nav» или nav.
Вряд ли это достижимо, но наличие, например, XSLT не оставляет надежды.
«То есть, глядя только на HTML должно быть понятно, как будут расположены эти элементы.» — я откажусь от этой идеи, верно, так никуда не годится.
Ну, XSLT — всего лишь один из шаблонизаторов. Не хотелось бы, чтобы он стал мейнстримом, он тяжеловесный — заметьте, на сервер-сайде в итоге юзают что угодно — Razor, Haml, orb, другие шаблонизаторы, и только очень редко — XSLT. Плюс он существует уже давно, но задачу «простой разметки» не решает. Благо точек взаимодействия разработчиков-верстальщиков-дизайнеров много и без того.
P.S. Вообще бездумно возвращать «какой-нибудь 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».
Вот хочется подобного от 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.
Поэтому я и про XSLT я не сразу понял мысль. Я понимаю, на входе, по сути, чистые данные в виде XML. Про тяжеловесность XSLT я не просто так упомянул, ибо на сервере, пока мы «доберемся» до XSLT — у нас уже есть View-Model на выходе из контроллера, которая и представляет собой данные. Два раза обрабатывать данные, превращая их в 2 разных представления, двух разных уровней абстракции очень не хочется. И, как ни крути, не хотелось бы, чтобы и HTML стал «чисто данными», мне кажется это не нужно — у него уже есть свой контекст, свое назначение. Т.е., на мой взгляд, не нужно превращать HTML в XML.
В итоге получаем две крайности — с одной стороны HTML может знать слишком много о конкретном представлении, а с другой — риск стать слишком обезличенным, быть чисто «данными». Одно недостаточно гибко, другое — слишком абстрактно. В итоге, HTML балансирует где-то посередине. Вопрос в том — где он должен быть, и тут — хрен его знает :) Но хотелось бы чего-то оптимального.
Ну, HTML превращать в XML («чисто данные») мне тоже бы не хотелось. Хотя… Но главные претензии у меня к CSS, именно раскладки и выражения. Причём средств типа LESS/SASS или, скажем, генерации CSS средствами PHP недостаточно, они сильно облегчают поддержку, а вот собственно вёрстку, по-моему, не очень. И выражения я бы даже поставил на первое место, хотя бы возможность ссылаться на произвольный селектор, что-то вроде:
Таким образом можно решить бОльшую часть проблем с раскладками наверное. Да и к XML с чисто данными такой CSS будет гораздо проще применять, чтоб получить что-то осмысленное :)
.sidebar.right {
position: absolute;
left: value('#content[right]');
margin: 20px;
}
Таким образом можно решить бОльшую часть проблем с раскладками наверное. Да и к XML с чисто данными такой CSS будет гораздо проще применять, чтоб получить что-то осмысленное :)
Верстаю годы и годы — и бурчу постоянно, что HTML это язык, не приспособленный для верстки страниц.
Зато все к нему привыкли — пусть уж будет. И мне работа найдется.
Зато все к нему привыкли — пусть уж будет. И мне работа найдется.
WPF или уж JavaFX. Всё уже придумано.
«Что вы, собственно, предлагаете?» Приведите какой-нибудь язык разметки с трансляцией в HTML-CSS
Ну, например, XUL + Ample SDK.
Уважаемый автор! С моей точки зрения, оценка CSS/HTML представления страниц — есть величина не только субъективная, но и сравнительная.
И теперь мой к Вам вопрос: с чем Вы предлагаете сравнивать? Какие у нас есть альтернативы, по сравнению с которыми мы могли бы назвать данные технологии сравнительно бесполезными, либо сравнительно полезными?
К примеру, ВАЗ 2106 следует оценивать не только по неким характеристикам, но и сравнительно. Когда у меня не было никакой машины, и ВАЗ решал мне массу проблем (разумеется, создавая массу новых). Но при этом всём, был сравнительно полезным. Когда у меня появилась иномарка, те же задачи стали решаться с гораздо меньшим количеством проблем. ВАЗ 2106 стал сравнительно бесполезен и был продан.
Мы же взрослые люди, уважаемый автор. Давайте исходить из реальности.
Вы считаете что HTML/CSS — плохи?
Предлагайте альтернативы. Давайте их обсуждать.
Причём обсуждать в реальном комплексе проблем, связанных с необходимостью менять инфраструктуру крупными корпорациями и т.д.
И теперь мой к Вам вопрос: с чем Вы предлагаете сравнивать? Какие у нас есть альтернативы, по сравнению с которыми мы могли бы назвать данные технологии сравнительно бесполезными, либо сравнительно полезными?
К примеру, ВАЗ 2106 следует оценивать не только по неким характеристикам, но и сравнительно. Когда у меня не было никакой машины, и ВАЗ решал мне массу проблем (разумеется, создавая массу новых). Но при этом всём, был сравнительно полезным. Когда у меня появилась иномарка, те же задачи стали решаться с гораздо меньшим количеством проблем. ВАЗ 2106 стал сравнительно бесполезен и был продан.
Мы же взрослые люди, уважаемый автор. Давайте исходить из реальности.
Вы считаете что HTML/CSS — плохи?
Предлагайте альтернативы. Давайте их обсуждать.
Причём обсуждать в реальном комплексе проблем, связанных с необходимостью менять инфраструктуру крупными корпорациями и т.д.
Это как были лошади, а нужно было придумать что-то лучше. Придумали автомобили. Нельзя ведь было сказать — давайте придумаем автомобили. Была задача сделать что-то (!) другое. Так и тут — нужно что-то другое, более лучшее, ага.
Альтернатив нет, но идея автора правильна — использовать html/css как loosy рендерер более стройного языка разметки, в котором например трехколоночная верстка делается только одним и очевидным способом.
призыв придумывать свои языки разметки улыбнул… :)
сколько времени пройдёт пока будет изобретён, оттестирован, доведён до идеала новый язык разметки и ещё сколько, чтобы он был внедрён повсеместно во всех браузерах? вы считаете что все разработчики браузеров будут придерживаться новой спецификации?
или также призовёте свой браузер написать с блекджеком? :)
как по мне так, на данный момент не нужно ничего нового изобретать в глобальных масштабах, нужно придти к единому знаменателю и в дальнейшем развивать те инструменты которые имеются…
сколько времени пройдёт пока будет изобретён, оттестирован, доведён до идеала новый язык разметки и ещё сколько, чтобы он был внедрён повсеместно во всех браузерах? вы считаете что все разработчики браузеров будут придерживаться новой спецификации?
или также призовёте свой браузер написать с блекджеком? :)
как по мне так, на данный момент не нужно ничего нового изобретать в глобальных масштабах, нужно придти к единому знаменателю и в дальнейшем развивать те инструменты которые имеются…
Согласен с автором, но вопрос в другом: а есть ли смысл заменять Html/css?
Да, вёрстка это не просто соеденил два кубика и сайт готов, нужно ещё напильником выточить каждый кубик и суперклеем промазать.
Но в данном случае эволюция — это лучше чем революция.
HTML5 более структурирован чем HTML4, новые браузеры всё больше технологий поддерживают. И со временем, когда утихнет война браузеров (да когда же она уже утихнет то!), то выпиливать кубики придёться меньше, а клей и вовсем будет не нужен.
Да, вёрстка это не просто соеденил два кубика и сайт готов, нужно ещё напильником выточить каждый кубик и суперклеем промазать.
Но в данном случае эволюция — это лучше чем революция.
HTML5 более структурирован чем HTML4, новые браузеры всё больше технологий поддерживают. И со временем, когда утихнет война браузеров (да когда же она уже утихнет то!), то выпиливать кубики придёться меньше, а клей и вовсем будет не нужен.
Совершенно непонятно о чём пост. Автор ругает одну из самых кроссплатформенных языков разметки, аргументируя это, мол «шаманство, хаки и ересь», а в замен ничего не предлагает.
Честно говоря я тоже в своё время думал, что вот было бы неплохо вместо HTML конструировать сайты в нечто подобном, как «визуальный редактор форм в Delphi». Потом я изучил flash, сделал несколько сайтов, и познал все сложности задавать все объекты абсолютными координатами. И тогда я понял, что вся мощь HTML в потоке. Если человек напишет коммент, увеличив при этом высоту колонки — ничего не случится, тогда как во flash для этого приходится писать скрипты, чтобы делать динамическое подстраивание размеров UI.
Да у HTML/CSS есть недостатки, но эти недостатки вызваны скорее необходимостью поддержки всякого хлама, и различной реализацией стандартов в разных браузерах. Но извините какая ещё технология позволяет открыть веб-сайт на компьютере, мобильнике, телевизоре, игровой приставке, причём с любой ОС (пусть и с различиями, но всё же)? HTML/CSS очень и очень кроссплатформен, недаром многие чисто десктопные приложение переносятся в Веб…
Честно говоря я тоже в своё время думал, что вот было бы неплохо вместо HTML конструировать сайты в нечто подобном, как «визуальный редактор форм в Delphi». Потом я изучил flash, сделал несколько сайтов, и познал все сложности задавать все объекты абсолютными координатами. И тогда я понял, что вся мощь HTML в потоке. Если человек напишет коммент, увеличив при этом высоту колонки — ничего не случится, тогда как во flash для этого приходится писать скрипты, чтобы делать динамическое подстраивание размеров UI.
Да у HTML/CSS есть недостатки, но эти недостатки вызваны скорее необходимостью поддержки всякого хлама, и различной реализацией стандартов в разных браузерах. Но извините какая ещё технология позволяет открыть веб-сайт на компьютере, мобильнике, телевизоре, игровой приставке, причём с любой ОС (пусть и с различиями, но всё же)? HTML/CSS очень и очень кроссплатформен, недаром многие чисто десктопные приложение переносятся в Веб…
Есть такая штука, называется layout manager. Она отлично подходит для разработки интерфейсов. Существует много хороших библиотек, позволяющих таким образом разрабатывать десктопные интерфейсы. Конструктор форм Delphi, который не поддерживает layouts, конечно же, не идет ни в какое сравнение ни с HTML, ни с нормальными интерфейсными библиотеками.
Я и не спорю, я не понимаю, почему автора не устраивает Flexible Box Layout Module в HTML5. Да сейчас пока применять его не совсем невозможно, из-за этого иногда приходится писать костыли, но, извините, пройдёт лет 5-10 и технология войдёт, это лучше чем выкинуть HTML совсем, и переписать браузеры на всех устройствах.
Есть такое правило. Никакая критика и указание на ошибки какой либо научной теории не изменят ее главенствующего положения. Уничтожить ее может лишь только более продвинутая (читай, объясняющая больше фактов) новая теория.
Для таких вещей на флэш-платформе придумали Flex и MXML. Задаёте размеры компонент в процентах и всё масштабируется автоматически.
А те же слои и их менеджеры в Java swing или QtGUIFramework легко читаемые и понимаемые?
Flash'у точно отказать, ActionScript ещё та поделка…
WYSIWYG редакторы для HTML+CSS, как и построители GUI в указанных мною примерах вообще УГ. Кодить надо ручками.
Flash'у точно отказать, ActionScript ещё та поделка…
WYSIWYG редакторы для HTML+CSS, как и построители GUI в указанных мною примерах вообще УГ. Кодить надо ручками.
> И заметьте, на мобильниках нет IE 6, 7 и 8 :) и порожденных ими проблем. Но делают приложения, а не сайты.
мне кажется это потому, что они могут работать быстрей вебстраниц через браузер на мобильном телефоне. На моем андроиде стоят стандартный браузер и опера и у каждого есть своя степень тупизны, так что и там не все гладко. А послушать музыку вконтакте мне проще через отдельное приложение.
мне кажется это потому, что они могут работать быстрей вебстраниц через браузер на мобильном телефоне. На моем андроиде стоят стандартный браузер и опера и у каждого есть своя степень тупизны, так что и там не все гладко. А послушать музыку вконтакте мне проще через отдельное приложение.
Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS. В результате кто-то из вас придумает мощную и кристально ясную замену этому историческому наслоению хаков.
Это а-ля ExtJS что ли? Когда на JavaScript пишутся невменяемые простыни-конфиги, которые невменяемой библиотекой преобразуются в невменяемый код HTML, стилизованный невменяемым CSS, когда страницы не работают при отключенном JS, когда одной лишней запятой в конфиге достаточно, чтобы страница перестала работать, когда ни одна IDE на свете не поддерживает полноценные подсветку и автодополнение кода, когда разборки с отображением элемента превращаются в многочасовую отладку JS кода, когда страница умудряется тормозить на самом быстром соверменном компьютере в самом современном и оптимизированном браузере?
НЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕТ!!!
Простите, наболело.
Понимаю Вашу позицию, но что касается отключенного JS — то кого это волнует в современном мире? С отключенным JS уже невозможно воспользоваться virtually ни одним сайтом Интернета представляющим хоть какой-то интерес.
А ничего, что без JS не работает gmail, google docs, etc, а так же куча программистских и прочих новомодных сайтов, таких, как упомянутая уже здесь Асана и прочие, социальные сети тоже или не работают, или показывают нефункциональные страницы и т.п. В чем может быть смысл отключения JS? Только чтобы подавить попапы?
Недоверие. Я, например, тоже не вполне понимаю, зачем мне включенный JS, чтобы отобразить информацию?
Да, у того же gmail есть «упрощенная HTML-версия», которая вполне работает без JS.
Да, у того же gmail есть «упрощенная HTML-версия», которая вполне работает без JS.
Да, так-то можно, если занести Google и т.п. в “белый список”. Но без включенного JS невозможно оценить новый сайт со сложным интерфейсом. Вот Вы приходите на сайт новой профессиональной системы, или пользователь заходит на страницу неизвестного ему сайта типа социальной сети (для примера), а JS у него выключен (так как этот сайт пока еще не в “белом списке”) – и что получится в результате? Или ругань, что для этого сайта принципиально нужен JS (и придется его включить, чтобы незаслуженно не отказываться от классного сайта). Либо, второй вариант – вы не сможете оценить удобство интерфейсов этого сайта. При этом для его разработчиков добавляется большая головная боль в виде поддержки клиентов с выключенным JS.
Не все же сайты чисто информационные, есть и такие, где интерфейс и его удобство имеют решающее значение.
Что касается шпионов, то тогда нужно еще и куки запрещать все, что еще больше принесет головной боли разработчикам сайтов. Ведь куки используются не только для шпионажа.
Не все же сайты чисто информационные, есть и такие, где интерфейс и его удобство имеют решающее значение.
Что касается шпионов, то тогда нужно еще и куки запрещать все, что еще больше принесет головной боли разработчикам сайтов. Ведь куки используются не только для шпионажа.
Кого волнует то что с выключенным монитором нельзя сайт прочитать?
У меня выключен монитор, и, если я не могу прочитать сайт — я просто ухожу, без волнений и переживаний.
Как то так
У меня выключен монитор, и, если я не могу прочитать сайт — я просто ухожу, без волнений и переживаний.
Как то так
Делать отдельный интерфейс для 0.1% программистов которые из принципиальных соображений отключают JS это просто очень дорого. Кроме того, есть множество систем, которые отличает от конкурентов именно удачный, продуманный, эргономичный интерфейс. Как Вы же отметили, невозможно реализовать такой интерфейс со всей его динамикой без JS. К тому же JS приходится использовать как “костыль” для фиксации дыр CSS/HTML, например, чтобы навести правильные углы и тени у боксов под IE не последней версии. Поэтому поддержка интерфейса без JS выливается зачастую в отдельный сложный таск. И как это ни прискорбно, но чисто с точки зрения бизнеса для небольшой (а то и для большой) фирмы легче отказаться от 0.1% пользователей-программистов с выключенным JS. Ну конечно я считаю что их все равно нужно заманивать на сайт, так как поддержка community очень важна – но я думаю для этого рационально правильней использовать рекламный текс со скриншотами того что он увидит, когда включит JS. :) А не параллельную разработку еще одного упрощенного, но полнофункционального интерфейса.
С точки зрения бизнеса проще вести разработку и поддержку максимально простого интерфейса. Чем меньше JS, нестандартных CSS и других наворотов — тем лучше. Проще (и дешевле) разработать, проще (и дешевле) отладить.
При этом автоматически (и почти бесплатно) решается проблема поддержки пользователей с экзотическими браузерами — максимально простые и устоявшиеся технологии поддерживаются всюду.
При этом автоматически (и почти бесплатно) решается проблема поддержки пользователей с экзотическими браузерами — максимально простые и устоявшиеся технологии поддерживаются всюду.
Например, есть большая «простыня» профайла пользователя. Когда включен JS она разбита на табы и имеет расползающиеся, по умолчанию свернутые секции. Когда JS нет, это будет ужасающей длины форма. Или же придется вообще разносить ее секции на разные страницы. Теряется до нуля вся usability в любом случае. И спрашивается — ради чего все это? Ради того, что некоторые пользователи ходят по порно-сайтам выключив JS, а затем ленятся включить его обратно?
Какая именно практическая потребность у Вас лично работать с сайтом без JS? Ну да, есть начальное может быть недоверие. Хотя обычно люди не ходят на какие попало URL-ы. Но дальше-то какой смысл себя мучить лишая современного динамического интерфейса? Я понимаю, что для сайтов-визиток можно с помощью jQuery решить проблему. Но для мало-мальски серьезного web 2.0 сайта на 100% избавится от JS это целый отдельный мини-проект.
Какая именно практическая потребность у Вас лично работать с сайтом без JS? Ну да, есть начальное может быть недоверие. Хотя обычно люди не ходят на какие попало URL-ы. Но дальше-то какой смысл себя мучить лишая современного динамического интерфейса? Я понимаю, что для сайтов-визиток можно с помощью jQuery решить проблему. Но для мало-мальски серьезного web 2.0 сайта на 100% избавится от JS это целый отдельный мини-проект.
Я слабо представляю себе как можно сделать сайт полностью недоступным без javascript. Имеется в виду генерация DOM на javascript?
Безусловно, делать сайт фактически без контента в HTML — глупо, но негодовать что что-то не работает без яваскрипта потому что такой плохой разработчик забыл сделать функционал для этого случая — нельзя.
Вот даже на хабре вы не сможете изменить рейтинг комментария без javascript. Можно было бы задать URL иконке явным образом и при включенном javascript делать свое действие и блокировать переход по URL, но зачем?
Я не сторонник сферический сайтов в вакууме без HTML но и не сторонник негодующих с выключенным javascript.
Безусловно, делать сайт фактически без контента в HTML — глупо, но негодовать что что-то не работает без яваскрипта потому что такой плохой разработчик забыл сделать функционал для этого случая — нельзя.
Вот даже на хабре вы не сможете изменить рейтинг комментария без javascript. Можно было бы задать URL иконке явным образом и при включенном javascript делать свое действие и блокировать переход по URL, но зачем?
Я не сторонник сферический сайтов в вакууме без HTML но и не сторонник негодующих с выключенным javascript.
Просто из принципа работать в современном браузере без JS это что-то сродни мазохизму. На любителя. :) Этак ведь можно на JS не останавливаться и пойти дальше. Можете отключить CSS, сайты будут загружаться еще быстрее. Потом куки выключить — ничего, что каждый раз заново пароль вводить. В том числе и сессионные — для полной секьюрности. Затем можно убрать все картинки — через них кстати тоже бывают эксплойты. После этого развивая тему можно выключить встроенные в браузер стили и везде поставить одинаковый фонт courier 12 кегля. И вернуться, таким образом, на 42 года назад в прошлое. Зато какая скорость загрузки страниц-то будет! :) И баннеры все снесет.
Будете смеяться… но…
Уведомления о получении новых сообщений в почте или социальной сети… пока пользователь читает другую страницу или вообще свернул браузер. Не просто так звуковое сопровождение используется.
Уведомления о получении новых сообщений в почте или социальной сети… пока пользователь читает другую страницу или вообще свернул браузер. Не просто так звуковое сопровождение используется.
google.com работает.
возьмите GWT на вооружение, и все ваши аргументы канут в нибытие
Ну какбэ да, геморрой. Но если заказчик говорит — нада IE6. Нада так нада. В два раза дороже. Лучше CSS/HTML все равно пока ничего не придумали. Придумают — надкусим и даже попробуем. Было бы все так херово — давно бы что-нибудь придумали.
Вот это и вызывает негодование программиста, воспитанного в классической программерской школе :)
Если бы все писалось на C++ (просто предположим), то в первую очередь поддерживалась бы наиболее слабая из целевых систем так как более совершенные системы «съедят» такое приложение без проблем. С HTML и CSS получилась абсурдная с точки зрения проектирования ПО ситуация — делаем нечто в соответствии с последними тенденциями, а потом скулим, ноем, повышаем стоимость работ потому что заказчик хочет чего-то БОЛЕЕ ПРОСТОГО! Странно, не так ли?
Если бы все писалось на C++ (просто предположим), то в первую очередь поддерживалась бы наиболее слабая из целевых систем так как более совершенные системы «съедят» такое приложение без проблем. С HTML и CSS получилась абсурдная с точки зрения проектирования ПО ситуация — делаем нечто в соответствии с последними тенденциями, а потом скулим, ноем, повышаем стоимость работ потому что заказчик хочет чего-то БОЛЕЕ ПРОСТОГО! Странно, не так ли?
Не так. Это как если заказчик требует писать программу под DOS на голом Си, а не под современную ОС на C++ с фреймворками и либами, аргументируя это тем, что у некоторых его клиентов ещё оригинальные IBM PC с CGA-мониторами. А программа должна работать и на современных и соответствовать современным требованиям к UI.
Старые браузеры не просто более слабые, они, если можно так выразиться, более низкоуровневые, там где сейчас достаточно одной «высокоуровневой» строчки только в CSS (типа border-radius), для старых браузеров нужно писать десять в HTML и 20 в CSS, да ещё рисовать картинки в фотошопе.
Старые браузеры не просто более слабые, они, если можно так выразиться, более низкоуровневые, там где сейчас достаточно одной «высокоуровневой» строчки только в CSS (типа border-radius), для старых браузеров нужно писать десять в HTML и 20 в CSS, да ещё рисовать картинки в фотошопе.
Писать под DOS — вполне нормальное требование заказчика. Если ему это нужно — имеет право заказать разработку. Требование писать на чистом C — тоже вполне нормальное, если заказчик сможет обосновать выбор технологии. В противном случае ему стоит доверить выбор технологии исполнителю. Но вот если исполнитель начнет выть, что ему влом поддерживать целевую ОС (то ли дело строчка кода на современнов фреймворке), то такого сполнителя надо в шею гнать — он не способен эффективно решить поставленную задачу. Не можешь — не берись, а не городи огород хаков, оправдываясь тем, что что-то устарело.
Ну а программеры, которые припахивают пару-тройку фреймворков прочих понтов просто потому, что «не прикольно» тег BUTTON для кнопоки использовать (конечно круче, если это будет десять DIV и страница CSS) — это отдельная песня. А примени они тег BUTTON — и нет проблемы с кроссбраузерностью. Модный фреймворк не применили, облом, зато заказчик быстро получил полностью кроссбраурерное решение.
Ну а программеры, которые припахивают пару-тройку фреймворков прочих понтов просто потому, что «не прикольно» тег BUTTON для кнопоки использовать (конечно круче, если это будет десять DIV и страница CSS) — это отдельная песня. А примени они тег BUTTON — и нет проблемы с кроссбраузерностью. Модный фреймворк не применили, облом, зато заказчик быстро получил полностью кроссбраурерное решение.
С другой стороны, приложение, большую часть которого составляют интерфейсы, с высокоуровневым фреймворком, да ещё визуальными средствами проектирования, пишется, как правило, куда быстрее «нативного». И не про «ныть» речь, а про увеличение стоимости разработки из-за увеличения её трудоемкости в связи с жёсткими требования заказчика на выбор инструмента, потребляемых ресурсов, списка поддерживаемых платформ и т. п.
Опять же, если на макете нарисована «весёлая» кнопка, которая, допустим, в ИЕ6 делается как раз десятком дивов, страницей CSS (да ещё двумя страницами JS), а в остальных браузерах применением свойства (условно) button-image, то вполне разумно сказать заказчику, что дороже будет стоить поддержка ИЕ6 (или дешевле без ИЕ6, без разницы).
Опять же, если на макете нарисована «весёлая» кнопка, которая, допустим, в ИЕ6 делается как раз десятком дивов, страницей CSS (да ещё двумя страницами JS), а в остальных браузерах применением свойства (условно) button-image, то вполне разумно сказать заказчику, что дороже будет стоить поддержка ИЕ6 (или дешевле без ИЕ6, без разницы).
Табличная верстка работает всюду и верстальщик, который в угоду моде будет верстать «дивами», получит в свой адрес «ай-ай-ай», так как своей погоней за модой создает компании и заказчику проблемы :) Аналогичные слова в свой адрес услышит верстальщик, который будет изображать кнопку не кнопкой или, в крайнем случае, картинкой, а «дивами». Опять же потому, что создает всем проблемы. Не знаю как в вашей деятельности, а в моей сложно заранее сказать, какой браузер будет стоять у клиента. Причем это может быть как последний писк технологий, так и суровый антиквариат. Приходится рассчитывать на худшее, а значит, чем проще — тем лучше :)
Всем сложно (кроме интранет приложений разве что). Но вообще мы отклонились. Смысл в том, что если поддержка какого-то дизайнерского изыска в устаревших браузерах сильно сложнее, чем в современных (что вставлять какой-то костыль типа условных комментариев, что верстать таблицами, там где проще дивами), то это будет стоить дороже, если заказчик настаивает на поддержке устаревших браузеров.
Поддержка сложнее ровно до тех пор, пока верстильщик пытается поддержать одновременно И устаревший И современный браузеры. Использование ТОЛЬКО устоявшейся технологий (и никаких хаков/условий/комментариев) решает проблему — отображается корректно в ЛЮБОМ браузере. Стоимость разработки и количество проблем резко падают.
Просто надо верстальщику и программеру целевой браузер поставить на рабочее место :)
Просто надо верстальщику и программеру целевой браузер поставить на рабочее место :)
Тут есть опасность, что если сейчас писать код рассчитывая только на браузеры десятилетней давности, то через пару лет он перестанет работать в современных на тот момент — сначала что-нибудь объявят depricated, а потом вообще уберут. Да и просто когда устаревший браузер наконец-то умрёт, то код будет выглядеть излишне. И работать будет скорее всего медленнее «нативного».
Ну и кроме того, практически по определению, кода для устаревших браузеров нужно писать больше, причём писать не на автопилоте, а думать как бы извратиться, сделав те же закругленные уголки у блока и наклонный градиент у его фона одновременно. Больше кода — больше себестоимость. То есть по любому разработка и поддержка устаревших браузеров (и автоматом современных) будет дороже, чем только современных.
Ну и кроме того, практически по определению, кода для устаревших браузеров нужно писать больше, причём писать не на автопилоте, а думать как бы извратиться, сделав те же закругленные уголки у блока и наклонный градиент у его фона одновременно. Больше кода — больше себестоимость. То есть по любому разработка и поддержка устаревших браузеров (и автоматом современных) будет дороже, чем только современных.
Почему простой и легкий (в том числе для понимания человеком) код будет работать медленне? :)
Не говоря уж о том, что использование JS необходимо минимизировать чтобы не нагружать клиентскую сторону. А то о производительности на клиентскойзабывают в таком количестве случаев, что становится непонятно — о чем думали вообще?
В примере с уголками скругленными извращаться не надо — таблица решает вопрос на ура. Просто надо читать СТАНДАРТ, а не черновики.
О! Принятый стандарт CSS 2.1 ничего не знает про border-radius? Правильно, не используем. В черновики лучше и не заглядывать.
Да и вообще проблема сильно преувеличена — мода на скругденные уголки как пришла, так и уйдет, а совместимость останется :)
Не говоря уж о том, что использование JS необходимо минимизировать чтобы не нагружать клиентскую сторону. А то о производительности на клиентскойзабывают в таком количестве случаев, что становится непонятно — о чем думали вообще?
В примере с уголками скругленными извращаться не надо — таблица решает вопрос на ура. Просто надо читать СТАНДАРТ, а не черновики.
О! Принятый стандарт CSS 2.1 ничего не знает про border-radius? Правильно, не используем. В черновики лучше и не заглядывать.
Да и вообще проблема сильно преувеличена — мода на скругденные уголки как пришла, так и уйдет, а совместимость останется :)
Ой ли, простой и лёгкий? Те же уголки — вложенную таблицу 3х3 делать? Вы действительно считаете, что это проще, чем одна строчка в css?
А раскладка типа:
10% 45% 45%
10% 30% 30% 30%
10% 22,5% 22,5% 22,5% 22,5%
(10% — единый вертикальный блок)
потребует создания таблицы 5х13 с кучей объединений ячеек по вертикали и горизонтали? Это легко читаемо?
А раскладка типа:
10% 45% 45%
10% 30% 30% 30%
10% 22,5% 22,5% 22,5% 22,5%
(10% — единый вертикальный блок)
потребует создания таблицы 5х13 с кучей объединений ячеек по вертикали и горизонтали? Это легко читаемо?
Давайте уже заканчивать этот спор :)
Я решаю для себя и разрабатываемых продуктов простую задачу — минимум проблем с совместимостью, потому что работать нужно на «всем, что шевелится» :)
И сказать клиенту «переустановите браузер» нельзя — это просто минус клиент, минус большой проект и минус работа для верстальщика (нет проекта — и верстать нечего).
Поэтому в интересах верстальщика не гоняться за модой, а верстать надежно. Пусть он сразу скажет, что скругленные уголки не катят, но сверстает так, чтобы работало везде и не тратит время на гонки за модой («никто так теперь не верстает...» и так далее).
Я решаю для себя и разрабатываемых продуктов простую задачу — минимум проблем с совместимостью, потому что работать нужно на «всем, что шевелится» :)
И сказать клиенту «переустановите браузер» нельзя — это просто минус клиент, минус большой проект и минус работа для верстальщика (нет проекта — и верстать нечего).
Поэтому в интересах верстальщика не гоняться за модой, а верстать надежно. Пусть он сразу скажет, что скругленные уголки не катят, но сверстает так, чтобы работало везде и не тратит время на гонки за модой («никто так теперь не верстает...» и так далее).
все серьезные компании делают нативные приложения для мобильных телефонов, а не предлагают своим пользователям открывать их сайт в браузере.
Нативные приложения хороши в основном тем, что их можно продвигать через магазины приложений. Ссылку даже на самый лучший мобильный веб-сайт в App Store не поставишь. В то же время куча мобильных приложений (или контролов в приложениях) рендерятся через HTML/CSS и затем оборачиваются в нативный код — и вы можете об этом даже и не подозревать. И этот подход абсолютно правилен — декларативный язык разметки всегда будет более удобен для описания интерфейсов и их поведений, чем любой язык алгоритмический. А всякие CSS-хаки — это просто временные способы обхода ограничений/багов движков рендеринга. Это болезни, связанные с бурным ростом, а не со стагнацией. Уйдут одни хаки, появятся другие (возможно, в меньшем количестве). Сами технологии тут не причем.
Это не HTML кривой. Браузеры его просто обрабатывают неправильно. )))
А всякие CSS-хаки — это просто временные способы обхода ограничений/багов движков рендеринга.
А способами обхода недостатков самого CSS разве не являются некоторые хаки?
А способами обхода недостатков самого CSS разве не являются некоторые хаки?
Какие фундаментальные недостатки CSS надо обходить хаками? Т.е. есть что-то, что нельзя исправить добавлением новых CSS-свойств при явной на то потребности рынка?
Весьма слабую динамичность прежде всего, включая ссылки на свойства других элементов и вообще выражения, переменные и т. п. Это если говорить именно о том, что введением новых свойств не обойти, для чего необходимы фундаментальные изменения.
А так прежде всего имел в виду субъективно весьма ограниченную модель позиционирования. Она хороша для потока, но сколь-нибудь нелинейное отображение (читай — сколь-нибудь сложный интерфейс) верстается не тривиально — все эти обтекания и отрицательные отступы и поля хотя бы, не говоря о частой необходимости дополнительных элементов html (врапперов, заглушек и т. п.).
А так прежде всего имел в виду субъективно весьма ограниченную модель позиционирования. Она хороша для потока, но сколь-нибудь нелинейное отображение (читай — сколь-нибудь сложный интерфейс) верстается не тривиально — все эти обтекания и отрицательные отступы и поля хотя бы, не говоря о частой необходимости дополнительных элементов html (врапперов, заглушек и т. п.).
Для всего есть свои инструменты. CSS — декларативное описание состояний. Для динамики и реакций на события существует JavaScript. CSS — не silver bullet, и не надо пытаться решать на нем задачи, для которых он не предназначается. К HTML же у вас нет претензий, что в нем переменных нет?
Про модель позиционирования тоже позволю себе не согласиться. По-моему, все весьма органично. Есть контейнеры, которые при необходимости можно позиционировать как абсолютно, так и относительно, внутри могут быть другие контейнеры, которые можно позиционировать абсолютно внутри родителя — это абсолютно нормальная модель. позволяющая идти от общего к частному, и ничего плохого в отрицательных отступах нет.
Да, иногда хочется большей гибкости, каких-то новых фишек, типа более удобного задания размеров для «резиновых» интерфейсов, но это ведь не заложенное в CSS фундаментальное ограничение, так? В новых спецификациях и в новых версиях браузеров появятся новые средства выражения, при этом принципы CSS могут вполне остаться неизменными.
Насчет переменных и динамичности CSS есть мнение, что они могут принести больше зла, чем пользы: www.w3.org/People/Bos/CSS-variables
Мне тоже не кажется, что CSS нужно притягивать за уши к языкам программирования. При необходимости все эти вещи легко делаются на другом уровне (на уровне собственно языка программирования), будь то JavaScript или, например, PHP.
Про модель позиционирования тоже позволю себе не согласиться. По-моему, все весьма органично. Есть контейнеры, которые при необходимости можно позиционировать как абсолютно, так и относительно, внутри могут быть другие контейнеры, которые можно позиционировать абсолютно внутри родителя — это абсолютно нормальная модель. позволяющая идти от общего к частному, и ничего плохого в отрицательных отступах нет.
Да, иногда хочется большей гибкости, каких-то новых фишек, типа более удобного задания размеров для «резиновых» интерфейсов, но это ведь не заложенное в CSS фундаментальное ограничение, так? В новых спецификациях и в новых версиях браузеров появятся новые средства выражения, при этом принципы CSS могут вполне остаться неизменными.
Насчет переменных и динамичности CSS есть мнение, что они могут принести больше зла, чем пользы: www.w3.org/People/Bos/CSS-variables
Мне тоже не кажется, что CSS нужно притягивать за уши к языкам программирования. При необходимости все эти вещи легко делаются на другом уровне (на уровне собственно языка программирования), будь то JavaScript или, например, PHP.
Когда-то были, когда width тля таблиц и «распорок» задавал в HTML :).
При первом рассмотрении, да, вроде вполне логично, но вот сталкиваясь с практическими задачами начинаются проблемы, от того, что логическое (и логичное) разделение блоков средствами HTML очень плохо вписывается в визуальный поток CSS. Типичный пример: меню, контент, хидер, два сайдбара, футер — блоки одного уровня, и именно в таком порядке по-моему естественно их располагать, прежде всего для клиентов, которые о CSS толком не знают иливизуальные излишества дизайнерские находки их не сильно интересуют в виду ограниченности размеров экрана. Для традиционной «табличной» вёрстки поток отрисовки должен очен сильно скакать относительно «потока» блоков в HTML, а если ещё есть требования вроде того, что сайдбары и контент должны быть одной высоты, иметь повторяющийся по вертикали фон (разный для всех трех колонок), футер должен быть прибит к низу окна, если общей высоты не хватает чтобы заполнить его и т. п.
В общем нет сейчас в связке HTML+CSS настоящей независимости данных и их представления. Чем больше разнятся «поток» html и визуальный поток, тем большехаков неочевидных способов вёрстки нужно использовать. И я не уверен, что любую желаемую визуальную компоновку на сетке, скажем, 3х3 можно получить из произвольного набора девяти HTML блоков одного уровня в случае нефиксированных высот и ширин. Про ситуацию когда блоки логически объединены родительским, а должны быть визуально разделены в раскладке вообще молчу. А если модифицировать HTML под желаемую раскладку, то тогда теряется одно из главных преимуществ отделения данных от представления — возможность заменить представление не трогая данные.
При первом рассмотрении, да, вроде вполне логично, но вот сталкиваясь с практическими задачами начинаются проблемы, от того, что логическое (и логичное) разделение блоков средствами HTML очень плохо вписывается в визуальный поток CSS. Типичный пример: меню, контент, хидер, два сайдбара, футер — блоки одного уровня, и именно в таком порядке по-моему естественно их располагать, прежде всего для клиентов, которые о CSS толком не знают или
В общем нет сейчас в связке HTML+CSS настоящей независимости данных и их представления. Чем больше разнятся «поток» html и визуальный поток, тем больше
наброс засчитан!
альтернатива, правда, дана не просто плохая, а… некоммерческая (а, значит, нежизненная — такова уж обсуждаемая область).
альтернатива, правда, дана не просто плохая, а… некоммерческая (а, значит, нежизненная — такова уж обсуждаемая область).
Но делают приложения, а не сайты.
Делают по совсем другой причине. Потому что есть xxxStore, в котором достаточно нажать кнопку, и всё будет установлено. Это — ещё один канал продвижения, а другой, через браузер, просто не знают многие зашедшие. Яркий пример — вчерашняя статья про приложение для asana.com, для сайта которого есть мобильный интерфейс через браузер, но приложение пользовалось большим спросом.
Автора нынешней статьи понять можно — такое мнение часто имеют те, кто незнаком с вёрсткой и его, естественно, раздражает много исторически сложенных правил. Простота — хорошая цель, но направление, к которому призывает автор — легко догаадаться, что делает положение ещё хуже. Вместо 5-7 браузерных систем вёрстки, блоее-менее похожих, автор предлагает создать 700 непохожих систем без обратной совместимости (традиционная вёрстка не будет переводиться в личную систему программиста), а прямая совместимость будет с ошибками, в которых разбираться будет только автор.
Подобным грешат 90% шаблонизаторов для HTML — вместо следования языку разметки, который знают верстальшики, придумывают ещё один (да, и каждый — свой!) язык-надстройку над JS или JSON. Иногда без этого не обойтись, если используют над своим языком XSLT-преобразования, например, тогда и свой язык должен быть XML-совместимым. В остальных случаях — это увеличение сложности, начинающееся, как всегда, с малого. Примерно как с вики.
Определенно статью писал неопытный человек. Достаточно грамотно написать код и любая заморочка будет сделана с первого раза. Я не спорю есть не мало всяких хитростей для решения задачек по сложнее, я думаю это в любом языке программирования присутствует, без этого никак. И все же зерно правды есть в этой статье, язык усложняется, страшно представить на сколько он усложнится еще в будущем. Помню когда стала популярна блочная верстка, мне было не по себе от нее, я думал я никогда ее не пойму, ну со временем въехал и стало все получаться. А Если что то и менять то кардинально, создавать абсолютно новую технологию, внедряя какие то существующие элементы, как вот выше говорили про вектор.
Чтобы лучше понять статью сделайте простой эксперимент — сверстайте блокнотик, приведенный в примере на CSS/HTML/JavaScript. Заставьте закладки прирастать к разным страницам, добейтесть чтоьбы все это листалось и чтобы было «резиновым». Посмотрите, сколько времени это заняло у Вас. 20 лет назад я делал такие блокнотики примерно за 10-15 минут в визуальном редакторе. Конечно, инженеры IBM перед этим вложили в них пару человеко-лет. Но web-технологиям уже больше лет, чем OS/2 и в браузеры вложено гораздо больше сотен человеко-лет и миллиардов долларов. Однако сделать такой блокнот или что-то близко похожее просто невозможно, если ты не программист и не хочешь превратить это в свой мини-проект.
Не вопрос что-то сделать одной компании, посмотрите на тот же flash, который вырос из обычный анимации, до сложных приложений. С HTML вышла просто печальная история, что пока на рынке в 200x доминировал IE, никто HTML особо не развивал. Но в последнее время тенденция поменялась, в качестве доказательства посмотрите как быстро за последние годы выросли очки у браузеров в html5test.com
Такой блокнотик делается за пару часов. Потратив ещё пару часов, можно написать код, который можно удобно повторно использовать. И написание следующего блокнота будет занимать те же самые 10-15 минут.
Предлагаю Вам попробовать :) Думаю, что Вам в последующих проекта пригодится, и за несколько сотен долларов продавать будете другим разработчикам. Только сделайте за пару часов по-настоящему – не жалкое подобие, а вот прямо такой или лучший функционал и визуальное оформление. Без PNG в подложке, естественно. Кроссбраузерно хотя бы на уровне минус 1 версия от текущей.
Если Вы про пример с OS/2, то создать такой блокнот, действительно, не проблема. Я бы взял на это день-два, включая тестирование по браузерам (предыдущий комментатор, наверное, не учёл, что без JS тут не обойтись, 2 часа — это только вёрстка в 1 браузере, часов 6-8 — совместимость с остальными). У тех, кто не знает вёрстку, действительно, будут проблемы с кроссбраузерностью из-за висящих закладок. Но делание за 15 минут на инструменте, который, очевидно, был заточен на подобные форматы страниц — некорректно. К примеру, попробуйте в той же ОС/2 изменить условия задачи. За сколько получится запрограммировать современные традиционные табы 2012 года? Не удивлюсь, если в разумные сроки не получится вообще или придётся писать на Си или другом доступном в системе языке.
И уж скорее всего, у Вас не получится за 15 минут запрограммировать этот блокнотик без тех глюков, которые видны на рисунке (нижние табы не прикреплены к своим уровням страниц, второй по уровню таб «Country» не имеет перемычки со своей страницей) — нужно залезать в движок и искать причину глюков там. А если не можем забраться в движок, то делать что?… Хаки. Те самые хаки, против которых Вы так эмоционально выступали :).
Нет, там нет глюков, все pixel-perfect – посмотрите под увеличением. :) Закладки до текущей активной специально привешивались именно к основанию блокнота, а не каждая к своей странице — потому, что так блокнот лучше воспринимался пользователем. Большинство людей смущало два ряда спадающих закладок – это путает и мешает быстро “схватывать” глазами текущую активную закладку.
почти все серьезные компании делают нативные приложения для мобильных телефонов, а не предлагают своим пользователям открывать их сайт в браузере
вовсе нет. во-первых, приложение даёт большую функциональность, нежели сайт: работа оффлайн, обработка больших объёмов данных, например. во-вторых, мобильные приложения — это тренд.
Ужасно визуально шумит нагромождение границ «листов книги».
HTML (CSS, JS) — кроссплатформенно-кроссбраузерный, у каждого производителя интерпретатора/рендерера свои недоработки, свои баги, свои бизнес-цели, как следствие появляются эксперементальные фичи и латки, подхватываемые разработчиками для достижения своих целей. В условиях столь жёсткой конкуренции, этого вряд ли можно избежать. Я вообще удивляюсь, как им всем удаётся это, особенно учитывая обратную совместимость на много лет назад (пусть и не всегда полную). Даже если целиком поменять язык, придумать что-то идеализованное-новое и заставить всех переделать на это свои продукты, я думаю, что всё равно через несколько лет всё скатится в такой же хаос. В целом, на данный момент, HTML (CSS, JS) не плох, мне приятно с ним работать (если не оглядываться на IE8 и младшие версии, которые сейчас уже почти не заказывают), и я не хотел бы снова писать интерфейсы на Delphi, как много лет назад.
Одна из проблем HTML, это его мнимая простота — каждый, кто прочел о паре свойств может сверстать простой сайтик. Ту же трёх-колоночную разметку можно сверстать кучей способов, и даже если вы где то ошиблись, вы сразу об этом не поймёте, браузеры обучены исправлению ошибок в разметке. Если вы не укажите <body>, браузер сам его подставит, и потом, когда вы открываете сайт в другом браузере, которые не прощает ошибки (тот же ИЕ), у вас всё ломается.
То есть из за недостаточной строгости, порог вхождения в разработку HTML очень низкий, можно сверстать совершенно космическую конструкцию, всё будет работать в новых браузерах, а потом обвешивах всё хаками что бы это работало в ИЕ6, а можно сразу сверстать хорошую, прочную конструкцию, которая сразу будет везде хорошо работать.
Естественно, даже хорошо разбираясь в специфике HTML, придётся делать непонятные с виду хаки для не стандартных, но где такого нету? Не тривиальные задачи будут всегда, а в HTML их будет всегда много, учитывая специфику и кроссплатформенность веб технологий.
К чему я веду — если вы не разбираетесь в какой то технологии, не надо закидывать её помидорами, и жаловаться что технология работает «не по вашему». Оставьте работу тем, кто понимает её и легко с ней работает.
Вы бы еще предложили дизайн рисовать и стоить удобные интерфейсы 2умя строчками кода.
То есть из за недостаточной строгости, порог вхождения в разработку HTML очень низкий, можно сверстать совершенно космическую конструкцию, всё будет работать в новых браузерах, а потом обвешивах всё хаками что бы это работало в ИЕ6, а можно сразу сверстать хорошую, прочную конструкцию, которая сразу будет везде хорошо работать.
Естественно, даже хорошо разбираясь в специфике HTML, придётся делать непонятные с виду хаки для не стандартных, но где такого нету? Не тривиальные задачи будут всегда, а в HTML их будет всегда много, учитывая специфику и кроссплатформенность веб технологий.
К чему я веду — если вы не разбираетесь в какой то технологии, не надо закидывать её помидорами, и жаловаться что технология работает «не по вашему». Оставьте работу тем, кто понимает её и легко с ней работает.
Вы бы еще предложили дизайн рисовать и стоить удобные интерфейсы 2умя строчками кода.
И для автомобильных компьютеров, и для банкоматов, и для АСУ ТП…
Потому что развелась куча «веб-программистов», которые потом идут в другие области
Проблема в том, что они пытаюсь применить знакомые технологии там, где для этого есть нативные более удобные инструменты
Возьмите интерфейсы любых трех популярных сайтов, повторите их в любом «нативном более удобном инструменте»
Уверен, что будет легче, чем повторить интерфейс VS 2010/Idea 11/Eclipse, например, на HTML
Уверен что вы не понимаете о чем говорите.
Уверен, что это вы как раз не понимаете, о чем говорите
> VS 2010/Idea 11/Eclipse
Какой смысл повторять интерфейсы-клоны, похожие один на другой как браться близнецы? «менюшка — грид лэйаут — попап — пучек диалогов»…
Достаточно повторить один из них.
Нативные инструменты дают вам возможность сворганить еще один «близнец», не более того. Для IDE, почтовых клиентов, блокнотиков еще как-то пойдет. Для чего-то большего…?
Тот же HTML/CSS разнообразнее и дает в разы больше возможностей.
Какой смысл повторять интерфейсы-клоны, похожие один на другой как браться близнецы? «менюшка — грид лэйаут — попап — пучек диалогов»…
Достаточно повторить один из них.
Нативные инструменты дают вам возможность сворганить еще один «близнец», не более того. Для IDE, почтовых клиентов, блокнотиков еще как-то пойдет. Для чего-то большего…?
Тот же HTML/CSS разнообразнее и дает в разы больше возможностей.
Я же говорю, вы не понимаете, о чем говорите. Я привел эти приложения просто как примеры достаточно сложных интерфейсов.
Ок, насчет однообразия, даю наводку: например, посмотрите, что можно сделать на XAML (WPF/Silverlight)
Ок, насчет однообразия, даю наводку: например, посмотрите, что можно сделать на XAML (WPF/Silverlight)
WPF/Silverligth — сильно платформозависимые технологии, жестко завязанные на технологии и инструменты одной компании.
К тому же весьма молодые, что как бы намекает что они в принципе не могли заменить HTML/CSS, как «нативные более удобные инструменты» (разве что в ваших бурных фантазия).
К слову, Silverlight как часть WPF — очередная попытка Microsoft устранить фатальный недостаток Flash, а теперь и HTML5, Microsoft известен своим инвестирование в свои «уникальные» разработки (тот же J# можно вспомнить). Так что как и все предыдущие попытки есть сомнения насчет того насколько жизнеспособна данная «альтернатива».
Так что не аргумент. Хотелось бы все же увидеть список тех нативных инструментов, покажете?
К тому же весьма молодые, что как бы намекает что они в принципе не могли заменить HTML/CSS, как «нативные более удобные инструменты» (разве что в ваших бурных фантазия).
К слову, Silverlight как часть WPF — очередная попытка Microsoft устранить фатальный недостаток Flash, а теперь и HTML5, Microsoft известен своим инвестирование в свои «уникальные» разработки (тот же J# можно вспомнить). Так что как и все предыдущие попытки есть сомнения насчет того насколько жизнеспособна данная «альтернатива».
Так что не аргумент. Хотелось бы все же увидеть список тех нативных инструментов, покажете?
> WPF/Silverligth — сильно платформозависимые технологии, жестко завязанные на технологии и инструменты одной компании.
Расскажите это разработчикам Moonlight, вот они удивяться.
К слову, Silverlight — это не часть WPF.
Расскажите это разработчикам Moonlight, вот они удивяться.
К слову, Silverlight — это не часть WPF.
А чему должны удивиться разработчики Moonligth? O_o
Тому, что оригинальный Silverligth (к слову, правильно называть Microsoft Silverligth) платформозависим? Так они об этом знают, и работают на Moonligth отчасти поэтому…
К тому же Moonligth это лишь реализация для Linux Microsoft Silverligth, а не одно и то же. Читайте описание проекта (http://www.go-mono.com/moonlight/).
Вы ведь в курсе что Moonligth отстает от Microsoft Silverligth, Mono серьезно отстает от .NET, есть гора проблем совместимости?… Или для красного словца все так кроссплатформено и красиво?
Тому, что оригинальный Silverligth (к слову, правильно называть Microsoft Silverligth) платформозависим? Так они об этом знают, и работают на Moonligth отчасти поэтому…
К тому же Moonligth это лишь реализация для Linux Microsoft Silverligth, а не одно и то же. Читайте описание проекта (http://www.go-mono.com/moonlight/).
Вы ведь в курсе что Moonligth отстает от Microsoft Silverligth, Mono серьезно отстает от .NET, есть гора проблем совместимости?… Или для красного словца все так кроссплатформено и красиво?
WPF/Silverligth — сильно платформозависимые технологии, жестко завязанные на технологии и инструменты одной компании.
«нативном более удобном инструменте»
Всё, больше еды нет.
Пусть меня заминусуют, но автор вероятно пишет на С++ и особо не разбирается в проблемах HTML и СSS.
Проблема 1: пользователи, которые не обновляют свой софт (самая основная проблема, надо же дать всем пользователям возможность видеть нормальную картирку, попробуйте запустить апликушку, писанную под виндоус95 на виндоус7, интересно, будет ли она работать? маловероятно)
Проблема 2: существует 100500 браузеров, и все они не особо стремились поддерживать стандарты, а вводили свои «фичи» (кажется, это относится к категории браузерных войн)
Ну и основное, что Вы не учли при написании топика — динамику развития любой технологии, а в случае с HTML и CSS то, что скорость их развития намного выше, чем скорость развития браузеров, пользователей, разработчиков…
Проблема 1: пользователи, которые не обновляют свой софт (самая основная проблема, надо же дать всем пользователям возможность видеть нормальную картирку, попробуйте запустить апликушку, писанную под виндоус95 на виндоус7, интересно, будет ли она работать? маловероятно)
Проблема 2: существует 100500 браузеров, и все они не особо стремились поддерживать стандарты, а вводили свои «фичи» (кажется, это относится к категории браузерных войн)
Ну и основное, что Вы не учли при написании топика — динамику развития любой технологии, а в случае с HTML и CSS то, что скорость их развития намного выше, чем скорость развития браузеров, пользователей, разработчиков…
попробуйте запустить апликушку, писанную под виндоус95 на виндоус7, интересно, будет ли она работать?
Будет. У меня таких прог достаточное количество, и все они работают включением режима совместимости и/или выключением Аэро. А Reversi из Windows 2 (87 год, ага) так и просто так запускается
Со стороны программиста на C++ должно быть хорошо видно, что люди используют технологии не по назначению.
HTML придумали для разметки текста, CSS — для внешнего оформления. Потом люди догадались, что невидимые таблицы позволяют текст и графику красиво разместить, потом кто-то закричал, что нефиг использовать таблицы для чего-то кроме размещения цифр… и понеслось… нет таблицам, все верстаем на DIV, делать круглые уголки самим влом, применяем CSS 3 (пофигу, что как стандарт он так и не принят)… мешанина полная и активное «меряние» длиной CSS вместо старых добрых таблиц, которые даже Linx отобразит нормально. Сами себе придумали проблему и активно с ней борятся.
Если уж приходится использовать инструменты не по делу (ну нет в HTML тега TABULATOR для вкладки, например), то как минимум стоит количество извращений минимизировать.
HTML придумали для разметки текста, CSS — для внешнего оформления. Потом люди догадались, что невидимые таблицы позволяют текст и графику красиво разместить, потом кто-то закричал, что нефиг использовать таблицы для чего-то кроме размещения цифр… и понеслось… нет таблицам, все верстаем на DIV, делать круглые уголки самим влом, применяем CSS 3 (пофигу, что как стандарт он так и не принят)… мешанина полная и активное «меряние» длиной CSS вместо старых добрых таблиц, которые даже Linx отобразит нормально. Сами себе придумали проблему и активно с ней борятся.
Если уж приходится использовать инструменты не по делу (ну нет в HTML тега TABULATOR для вкладки, например), то как минимум стоит количество извращений минимизировать.
нет таблицам, все верстаем на DIV, делать круглые уголки самим влом, применяем CSS 3 (пофигу, что как стандарт он так и не принят)
Посмотрите обновления. Уже давненько принято в стандарт.
Да у них там само понятие стандарта на CSS так расплылось после 2.1, что просто последнюю актуальную версию извлечь уже совсем не просто :(
Тем не менее, программист на C++ хорошо знает, что такое обеспечение совместимости с машинами разных пльзователей, работа под разными ОС и в разных окружениях. Со стороны разработчика обычного ПО все эти пляски вокруг кроссбразуерности (напридумывать как можно больше хаков вместо использования одного простого решения) — в самом деле изврат. Людей учат разрабатывать с наименьшими усилиями как для программиста так и для машины, на которой будет код выполняться.
P.S. Оптимизация по производительности — это вообще отдельный разговор. Немногие web-разработчики хоть как-то над этим задумываются.
Тем не менее, программист на C++ хорошо знает, что такое обеспечение совместимости с машинами разных пльзователей, работа под разными ОС и в разных окружениях. Со стороны разработчика обычного ПО все эти пляски вокруг кроссбразуерности (напридумывать как можно больше хаков вместо использования одного простого решения) — в самом деле изврат. Людей учат разрабатывать с наименьшими усилиями как для программиста так и для машины, на которой будет код выполняться.
P.S. Оптимизация по производительности — это вообще отдельный разговор. Немногие web-разработчики хоть как-то над этим задумываются.
Именно эту страницу я и имел в виду.
Сравните со спецификацией CSS 2.1: http://www.w3.org/TR/CSS21/. Тут подробно все описано, можно скачать к себе и работать как со справочником. А для корректного применения технологии именно такая документация и нужна. А то начинается беганье по форумам и выискивание хака за хаком вместо работы с оригинальным источником.
Сравните со спецификацией CSS 2.1: http://www.w3.org/TR/CSS21/. Тут подробно все описано, можно скачать к себе и работать как со справочником. А для корректного применения технологии именно такая документация и нужна. А то начинается беганье по форумам и выискивание хака за хаком вместо работы с оригинальным источником.
Чет какое то нытье сплошное. Аргументы очень слабы.
> Верстка серьезного сайта с использованием CSS/HTML – это современное шаманство, приемы которого передаются “от отца к сыну”.
Да так можно про что-угодно сказать, про любой язык программирование. При этом никто не мешает конкретно вам разобраться, как работает конкретное шаманство.
> Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS.
Лол, а в чем тогда профит, если надо транслировтаь? Уже давно есть туча фреймворков, берите сенчю, делайте подобные на ваших скринах интерфейсы практически без html-кода. Тому, кто сможет че то транслировать через html+js+css не нужно будет писать свой язык) html итак вполне себе логичный язык. То что вы где то увидели пару отрицательных значений свойств — это ни о чем не говорит.
> что почти все серьезные компании делают нативные приложения для мобильных телефонов
Вот совсем не в ХТМЛе дело, а в том, что через браузер смотреть не очень то удобно. Разумеется, нативное приложение может легко получить данные о дисплее, пропорциях, ориентации. + нет лишний неудобной прослойки «броузер». + нельзя сохранить страницу как приложение (ток в айфоне). У кого денег много и большая аудитория — конечно делают программульки под кадую платформу.
А еще скоро заработают css columns (ну или не очень скоро, но заработают) и все станет гораздо проще.
Вообще, html — это естественная цена универсальности. А как вы хотели? Зато работает достаточно сносно на любых устройствах.
> Верстка серьезного сайта с использованием CSS/HTML – это современное шаманство, приемы которого передаются “от отца к сыну”.
Да так можно про что-угодно сказать, про любой язык программирование. При этом никто не мешает конкретно вам разобраться, как работает конкретное шаманство.
> Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS.
Лол, а в чем тогда профит, если надо транслировтаь? Уже давно есть туча фреймворков, берите сенчю, делайте подобные на ваших скринах интерфейсы практически без html-кода. Тому, кто сможет че то транслировать через html+js+css не нужно будет писать свой язык) html итак вполне себе логичный язык. То что вы где то увидели пару отрицательных значений свойств — это ни о чем не говорит.
> что почти все серьезные компании делают нативные приложения для мобильных телефонов
Вот совсем не в ХТМЛе дело, а в том, что через браузер смотреть не очень то удобно. Разумеется, нативное приложение может легко получить данные о дисплее, пропорциях, ориентации. + нет лишний неудобной прослойки «броузер». + нельзя сохранить страницу как приложение (ток в айфоне). У кого денег много и большая аудитория — конечно делают программульки под кадую платформу.
А еще скоро заработают css columns (ну или не очень скоро, но заработают) и все станет гораздо проще.
Вообще, html — это естественная цена универсальности. А как вы хотели? Зато работает достаточно сносно на любых устройствах.
Ого-го сколько неграмотности в одном посте.
HTML создан для разработки документов. Если вы делаете с помощью HTML — это не HTML неправильны, а вы делаете что-то не так. Понятно, что в вебе других вариантов нет, но это не значит, что HTML — плохой.
Модель отображения браузера тоже заточена под документы — она очень логична и совершенно одинакова во всех браузерах (за исключением мелких багов браузеров).
Одна мысль верная — делаете приложения, то для более удобной разработки нужно создать подходящий уровень абстракции или совсем свою модель, которую транслировать в HTML и CSS.
Это не проблемы существующих технологий — это ваши проблемы
HTML создан для разработки документов. Если вы делаете с помощью HTML — это не HTML неправильны, а вы делаете что-то не так. Понятно, что в вебе других вариантов нет, но это не значит, что HTML — плохой.
Модель отображения браузера тоже заточена под документы — она очень логична и совершенно одинакова во всех браузерах (за исключением мелких багов браузеров).
Одна мысль верная — делаете приложения, то для более удобной разработки нужно создать подходящий уровень абстракции или совсем свою модель, которую транслировать в HTML и CSS.
Это не проблемы существующих технологий — это ваши проблемы
*Если вы делаете с помощью HTML приложения — это не HTML неправильный
Вы совершенно правы — это не HTML плохой. Это просто HTML-я недостаточно в том виде, в каком он есть. И его нужно развивать. Для удобной разработки интерфейсов достаточно будет уже реализации flex-box и grid.
И наши проблемы — это следствие проблем существующих технологий и сложившейся ситуации. Но это не проблема HTML/CSS как языков разметки/стиля — они отличные, просто современные требования вышли за рамки современной же реализации.
И наши проблемы — это следствие проблем существующих технологий и сложившейся ситуации. Но это не проблема HTML/CSS как языков разметки/стиля — они отличные, просто современные требования вышли за рамки современной же реализации.
Я не пойму что люди хотят от языка разметки? Построение Rich UI аля десктопных пользовательских интерфейсов?
Главное преимущество HTML, из-за которого его и обвешивают плюшками уже сколько лет — это индексируемость поисковиками. Никому не нужен форум/офсайт/ и т.п. с великолепным интерфейсом, который никто не найдет. Проще навесить анимацию/оформление к индексируемому тексту. Пока не появятся и обретут популярность более совершенные способы поиска информации, чем полнотестовый поиск, html останется как минимум в качестве зеркала.
Ещё плюс html — легкая интеграция рекламы. Куда хочешь — туда и воткнул. Баннеры, фреймы, попапы… А реклама, как ни крути, — основной спонсор большинства сайтов. Опять же, пока крупнейшие рекламодатели не начнут поддерживать новый стандарт интерфейса, каким бы он ни был, поезд никуда не поедет.
Ещё плюс html — легкая интеграция рекламы. Куда хочешь — туда и воткнул. Баннеры, фреймы, попапы… А реклама, как ни крути, — основной спонсор большинства сайтов. Опять же, пока крупнейшие рекламодатели не начнут поддерживать новый стандарт интерфейса, каким бы он ни был, поезд никуда не поедет.
Простите, но это какая-то фигня. Вы говорите «хаки»! Хаки — временное решение.
Встроенный в ОС элемент с вкладками? А попробуйте его настроить под свои требования. Простой пример — вам надо добавить иконки на каждую вкладку. А во встроенном элементе это не предусмотрено. Или раскрасить их по разному. Не дай вам бог если захотите выделить что-либо формой. C помощью html и css это элементарно.
html + css эталон гибкости. И это гигантский плюс для разработки интерфейсов.
Что касается мобильных приложений — зачастую это еще и маркетинговый ход. Установить в телефон пользователя свой лого.
Встроенный в ОС элемент с вкладками? А попробуйте его настроить под свои требования. Простой пример — вам надо добавить иконки на каждую вкладку. А во встроенном элементе это не предусмотрено. Или раскрасить их по разному. Не дай вам бог если захотите выделить что-либо формой. C помощью html и css это элементарно.
html + css эталон гибкости. И это гигантский плюс для разработки интерфейсов.
Что касается мобильных приложений — зачастую это еще и маркетинговый ход. Установить в телефон пользователя свой лого.
И да, конечно бывает сложно понять что такое
Особенно зная что такого значения у свойства overflow нет.
overflow: none;Особенно зная что такого значения у свойства overflow нет.
Нужно понимать, что HTML/CSS и средства разработки десктопных приложений — это разные инструменты.
Когда я начал разрабатывать веб-приложения, после Delphi было похожее ощущение, что всё это (особенно JS) кривое нагромождение хаков, не предназначенных для разработки приложений. Но потом втянулся и привык. Недавно что-то делал в Delphi, и мне в некоторых местах не хватало гибкости CSS.
Когда я начал разрабатывать веб-приложения, после Delphi было похожее ощущение, что всё это (особенно JS) кривое нагромождение хаков, не предназначенных для разработки приложений. Но потом втянулся и привык. Недавно что-то делал в Delphi, и мне в некоторых местах не хватало гибкости CSS.
>Нужно понимать, что HTML/CSS и средства разработки десктопных приложений — это разные инструменты.
Спешу огорчить — http://www.appleinsider.com/articles/11/06/01/microsoft_demonstrates_windows_8_with_html5_apps.htmlю
Спешу огорчить — http://www.appleinsider.com/articles/11/06/01/microsoft_demonstrates_windows_8_with_html5_apps.htmlю
Ого, насколько грамотный троллинг нынче на Хабре )
>Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS.
Ну ASP.NET, к примеру, и имеет свою надстойку над HTML.
Ну ASP.NET, к примеру, и имеет свою надстойку над HTML.
Принимая во внимание все аргументы, стоит признать, что HTML, как язык описания представления страницы, является устаревшим и не соответствует нынешним реалиям.
HTML отлично подходит для верстки документов (для чего он и был изначально создан), причем под документом я понимаю любую страницу, в которой контент преобладает над оформлением. Как известно, CSS был придуман, чтобы как-то облагородить голый HTML, добавив гибкие возможности по оформлению и позиционированию элементов. На тот момент это был хороший выход из положения, но в наше время, в эпоху расцвета web-приложений и просто сайтов с богатой функциональностью, нам требуются интерфейсы, а не документы. Для создания интерфейсов HTML никогда не был предназначен, поэтому то, что делает google со своими gmail, docs и т.д. и можно считать в некотором роде шаманством и магией.
Я сам всегда завидовал тем же deplhi программистам, которым для создания интерфейса для простого приложения требовалось несколько минут, чтобы настроить лейаут и раскидать кнопочки и другие элементы по форме. Мне потребуется несколько часов, чтобы создать что то похожее, но для веба. Да, я не верстальщик. Да, HTML дает куда большую гибкость. Но, черт возьми, я просто хочу сделать тупой интерфейс, который просто будет работать одинаково во всех браузерах. Неужели я прошу многого?
Отчасти эту проблему решают инструменты, вроде sencha, jquery ui и twi bootstrap. Но не один из них не подходит на роль комплексного решения.
Мне очень жаль, что Flex, который, на мой взгляд, является идеальным решением, не прижился в современном вебе :(
HTML отлично подходит для верстки документов (для чего он и был изначально создан), причем под документом я понимаю любую страницу, в которой контент преобладает над оформлением. Как известно, CSS был придуман, чтобы как-то облагородить голый HTML, добавив гибкие возможности по оформлению и позиционированию элементов. На тот момент это был хороший выход из положения, но в наше время, в эпоху расцвета web-приложений и просто сайтов с богатой функциональностью, нам требуются интерфейсы, а не документы. Для создания интерфейсов HTML никогда не был предназначен, поэтому то, что делает google со своими gmail, docs и т.д. и можно считать в некотором роде шаманством и магией.
Я сам всегда завидовал тем же deplhi программистам, которым для создания интерфейса для простого приложения требовалось несколько минут, чтобы настроить лейаут и раскидать кнопочки и другие элементы по форме. Мне потребуется несколько часов, чтобы создать что то похожее, но для веба. Да, я не верстальщик. Да, HTML дает куда большую гибкость. Но, черт возьми, я просто хочу сделать тупой интерфейс, который просто будет работать одинаково во всех браузерах. Неужели я прошу многого?
Отчасти эту проблему решают инструменты, вроде sencha, jquery ui и twi bootstrap. Но не один из них не подходит на роль комплексного решения.
Мне очень жаль, что Flex, который, на мой взгляд, является идеальным решением, не прижился в современном вебе :(
Ну так используйте абсолютно любой WYSIWYG html редактор, и тоже сможете создать за 15 минут простое оформление, которое будет работать во всех браузерах.
Так и пишите на deplhi, что ж вы в веб то лезете со своей «библией».
> Я сам всегда завидовал тем же deplhi программистам, которым для создания интерфейса для простого приложения требовалось несколько минут
А про то получается такой же УГ как на скрине ос/2 не важно? Как минимум, прогер может использовать таблицы рас ему нужно по-быстрому накидать, потом прийдёт верстальщики сделает всё красиво. Или же поставить dreamweaver и сделать это всё визуально.
Я бы программистам вообще бы запретил заниматься вёрсткой, дизайном и расстановкой элементов. Им это противопоказано, что и вызывает такие вот статьи.
> Я сам всегда завидовал тем же deplhi программистам, которым для создания интерфейса для простого приложения требовалось несколько минут
А про то получается такой же УГ как на скрине ос/2 не важно? Как минимум, прогер может использовать таблицы рас ему нужно по-быстрому накидать, потом прийдёт верстальщики сделает всё красиво. Или же поставить dreamweaver и сделать это всё визуально.
Я бы программистам вообще бы запретил заниматься вёрсткой, дизайном и расстановкой элементов. Им это противопоказано, что и вызывает такие вот статьи.
Первый и самый главный вопрос, который возник в голове, это — не хотите, не используйте. Хотите — пишите свой, под свою конкретную задачу, не понимаю. Ну разве можно пинать устоявшийся годами (простите за такое грубое сравнение, разницу я знаю и прошу не судить) язык программирования, на котором пишут миллионы и результаты труда которого используют (не побоюсь) миллиарды? Если у вас возникла проблема — решайте ее сами. Никогда этого не понимал.
Это первое. Второе — вы наверняка понимаете, что этот язык разметки универсален и может использоваться (и используется) абсолютно везде, где только может возникнуть необходимость. Разве эта универсальность не может быть почвой для тех самых погрешностей, которые мешают сегодня вам жить? Да, хаки — это беда, проблема. Но на это стоит посмотреть с другой стороны — насколько часто бывают ситуации при разметке, из которых не выкрутиться хотя бы теми же хаками?
Вообще, призывать — всегда самый последний вариант. Первое, что нужно сделать, — это предложить, указать и показать. Разве не так?
Это первое. Второе — вы наверняка понимаете, что этот язык разметки универсален и может использоваться (и используется) абсолютно везде, где только может возникнуть необходимость. Разве эта универсальность не может быть почвой для тех самых погрешностей, которые мешают сегодня вам жить? Да, хаки — это беда, проблема. Но на это стоит посмотреть с другой стороны — насколько часто бывают ситуации при разметке, из которых не выкрутиться хотя бы теми же хаками?
Вообще, призывать — всегда самый последний вариант. Первое, что нужно сделать, — это предложить, указать и показать. Разве не так?
Что-то в этом есть. Часто возникают мысли о системных просчётах (даже не о просчётах, а о консервативности HTML и CSS, ведь авторы не знали как будет развиваться сеть через 20 лет). Многие не задумываются, а ведь браузер превратился в закрытую песочницу, ограничения которой не позволяют многих вещей. Я был бы счастлив написать front-end процедуру, например, на Python. Или вернуть клиенту скомпилированную программу, что дало бы дополнительные возможности для творчества. Задачи, которые выполняет вычислительная техника, уже давно немыслимы без доступа к интернету, но разработчики ещё не успели до конца прочувствовать новый этап. Необходима не программа (браузер), а целый framework (или даже их семейство), интегрированный в ОС и расширяющий границы и возможности сетевой песочницы. OpenID интеграция с устройством могла бы позволить входить как в само устройство, так и авторизацию на другие ресурсы. Коснулся сенсорного экрана и зарегистрировался в интернет-магазине или на сайте. Друзей, фотки и другую персональную информацию необходимо также выносить за пределы структур соц. сетей в персональный аккаунт (это как смена операторов сотовой связи без смены самого номера, довольно очевидная полезная фича, дающая пользователю преимущество и удобство, а операторам мотивацию сражаться тарифами или интерфейсами применительно к соц. сетям). Да, технических проблем много: безопасность, целостность и т.д., но это не повод чтобы этим не заниматься. Довольно сумбурно, но основной идейный вектор, надеюсь, сумел донести. Не судите слишком строго)
Читал-читал, но так и не понял, почему сравнивается язык разметки (читай, язык программирования) и элементы интерфейса ОС?
Давайте сравним интерфейс Виндовс и ОС\2 — это будет корректно. Или HTML 5 и HTML 1.
А так получается, сравниваем язык С# и автомобиль. И говорим, что на С# далеко не уедешь… Странно. Или я что-то недопонимаю?
Давайте сравним интерфейс Виндовс и ОС\2 — это будет корректно. Или HTML 5 и HTML 1.
А так получается, сравниваем язык С# и автомобиль. И говорим, что на С# далеко не уедешь… Странно. Или я что-то недопонимаю?
Почему никто не предложил вернуться к BBS? :) Я всех призываю перейти на модемы и пользоваться только BBS, ведь только на BBS живет дух старой школы.
Очень хороший пример крутости использования HTML, только чтобы это понять нужно запустить приложение на другой OS. Ладно бы ещё JAVA приложение привели в качестве примера, они хоть кромплатформенные и везде выглядят одинаково плохо без таких же костылей.
Похоже автор не пробовал сам делать UI элементы, тогда бы знал сколько там костылей.
Похоже автор не пробовал сам делать UI элементы, тогда бы знал сколько там костылей.
похоже на рассуждения на школьной скамье, вы еще про трансформеров или динозавров на хабр напишите
Как программист С++, который таки иногда прибегает к js и юзает такие технологии, как QML. Хочу полностью согласится со статьей. В итоге HTML5+CSS3+бла бла бла так и остался нагромождением хаков и костылей. Нет в нем той нужной стройности. От того и возникают сложности с написанием полноценной реализации всех стандартов. они раздутые просто до невозможности. Одно и тоже можно сделать тысячью способами.
ЗЫ
Таки html удобен для обычной верстки статей хотя не настолько как mediawiki и т.д. Но делать на нем полноценные приложения — лучше я застрелюсь сразу!
ЗЫ
Таки html удобен для обычной верстки статей хотя не настолько как mediawiki и т.д. Но делать на нем полноценные приложения — лучше я застрелюсь сразу!
По крайней мере html (как подмножество SGML), как очень простая сущность, завоевало большую популярность, чем что-либо из ныне существующего. Прежде всего своей простотой, нетребовательностью к ресурсам как клиента так и сервера, в том числе и канала передачи. И создавался язык прежде всего для передачи plain-текста, ну разве что нужно было размечать отдельные его части. В этом плане html справлялся, справляется и будет справляться дальше.
Ну а если вам нужны полноценные приложения — тут-то и придут на помощь инструменты более высокого уровня. Хотя, как мне видится, снова получится очередная технология ради технологии.
Ну а если вам нужны полноценные приложения — тут-то и придут на помощь инструменты более высокого уровня. Хотя, как мне видится, снова получится очередная технология ради технологии.
Ну так html по сути тот же самый xml, только для браузеров.
а что автор конкретно предлагает?
Ну например взять qml и написать для него реализацию, работающую через js поверх canvas'а или лучше WebGL и писать уже на ней.
Шарперы могут попробовать сделать реализацию XAML поверх этого дела, ну а мозилловцы XUL свой могут сэмулировать.
Или вообще придумать новый способ с нуля и сделать его транслятор в эту тучу костылей с учетом проблем каждого конкретного браузера.
Шарперы могут попробовать сделать реализацию XAML поверх этого дела, ну а мозилловцы XUL свой могут сэмулировать.
Или вообще придумать новый способ с нуля и сделать его транслятор в эту тучу костылей с учетом проблем каждого конкретного браузера.
Хорошая пятничная сралка.
Браузер — это и есть приложение. Как тот же флеш.
Как те же так называемые нативные мобильные приложения, которые у каждой мобилки свои и из-за этого они вымрут, и останется только html+js+css, ибо за этим будущее, это универсально.
Браузер — это и есть приложение. Как тот же флеш.
Как те же так называемые нативные мобильные приложения, которые у каждой мобилки свои и из-за этого они вымрут, и останется только html+js+css, ибо за этим будущее, это универсально.
Плохой музыкант пеняет на инструмент.
Даже самый лучший музыкант в мире изрядно помучается, если ему дадут плохой и не подходящий для этого инструмент, не находите? Никто же всерьёз не играет, например, рок-соло на балалайке. Тандем html+js+css ненамного универсальнее той же Джавы. К тому же очень серьёзно проигрывает в производительности
Мое мнение что автору просто лень изучать чужую разработку и хочется чего то своего.
Я искренне люблю html, это же прекрасный набор инструментов, да если нужна какая то неведомая хрень всегда есть canvas, а тут и WebGL подтягивается.
Незнание и нежелание учиться это не недостаток технологии.
P.S. Автору в упрек и это без JS, 20 минут.
Я искренне люблю html, это же прекрасный набор инструментов, да если нужна какая то неведомая хрень всегда есть canvas, а тут и WebGL подтягивается.
Незнание и нежелание учиться это не недостаток технологии.
P.S. Автору в упрек и это без JS, 20 минут.
position: absolute;
right:-161px;
width:150px;
Некоторые вещи, в общем-то, особо подчеркивают причину баттхерта автора топика.
P.S. Отсутствие нормальных семантических лэйаутов и чрезмерная роль CSS в формировании визуальной структуры документа — тут учись, не учись, пока действительно неидеально все. Нет выбора, к сожалению.
Что же в приведенном коде так вас напугало, позиция блика или ширина? Это же базовые свойства.
А «роль CSS в формировании визуальной структуры документа» это вы о чем, можно подробнее?
А «роль CSS в формировании визуальной структуры документа» это вы о чем, можно подробнее?
.notepad__page .notepad__page__caption{ top:1em; }
.notepad__page+.notepad__page .notepad__page__caption{ top:3.5em; }
.notepad__page+.notepad__page+.notepad__page .notepad__page__caption{ top:6em; }
.notepad__page+.notepad__page+.notepad__page+.notepad__page .notepad__page__caption{ top:8.5em; }
.notepad__page+.notepad__page+.notepad__page+.notepad__page+.notepad__page .notepad__page__caption{ top:11em; }
это прекрасно.
.notepad__page+.notepad__page .notepad__page__caption{ top:3.5em; }
.notepad__page+.notepad__page+.notepad__page .notepad__page__caption{ top:6em; }
.notepad__page+.notepad__page+.notepad__page+.notepad__page .notepad__page__caption{ top:8.5em; }
.notepad__page+.notepad__page+.notepad__page+.notepad__page+.notepad__page .notepad__page__caption{ top:11em; }
это прекрасно.
Про роль CSS спорный вопрос, не обращайте внимания. А в примере смутило абсолютное позиционирование и отрицательные смещения, чтобы добиться требуемого результата — то есть, по сути то, о чем и говорит автор топика (если отбросить все эмоции и сентименты). Должно решиться нормальной реализацией модели layout-ов.
Приведенный за эталон интерфейс OS/2 — унылое говно.
Большинство интерфейсов нативных приложений — похожи один на другой, и тоже УГ. Та малая часть, которая не УГ создается несоразмерными усилиями.
Статья — бред.
Большинство интерфейсов нативных приложений — похожи один на другой, и тоже УГ. Та малая часть, которая не УГ создается несоразмерными усилиями.
Статья — бред.
По-моему это просто крик души. У меня тоже такое часто бывает, когда приходится придумывать очередной костыль. После этого говоришь себе: «В следующий раз я сделаю все правильнее!». Но все равно не получается и приходится опять придумывать костыли. Правда об этом в массу кричать не особо хочется :)
> Придумывайте свои языки разметки и если нужно транслируйте их в HTML + CSS.
Так их же полно! haml, slim, less, sass+compass. Особенно связка slim + sass нравится, куда уж удобнее.
Сделал разметку в slim:
Скопировал ее в sass-файл. Потом уже в sass добавил свойства, в slim дописал чем это заполняться будет. Да, копи-паст присутствует, но ведь все равно удобно и «семантично» :)
P.S. Лучше пост был призывом поставить всем на сайты библиотеку, типа этой
Так их же полно! haml, slim, less, sass+compass. Особенно связка slim + sass нравится, куда уж удобнее.
Сделал разметку в slim:
.news
.title
.content
Скопировал ее в sass-файл. Потом уже в sass добавил свойства, в slim дописал чем это заполняться будет. Да, копи-паст присутствует, но ведь все равно удобно и «семантично» :)
P.S. Лучше пост был призывом поставить всем на сайты библиотеку, типа этой
Бред пишете.
Не должен web die.
Наоборот, html + css идеально подходят для интерактивной полиграфии.
Если у вас нет лучшей альтернативы — не имеете права критиковать.
Идите тогда на Марш Несогласных, или к Навальному на митинг, и там стойте в маске Гая Фокса с транспарантом «Вебъ долженъ уйти! Вебъ уходи!».
А эти «нативные приложения» ваши хвалёные — достаточно взглянуть на их код, сравнить этот код с html + css + js и больше не возвращаться к теме «нативных приложений»
Не должен web die.
Наоборот, html + css идеально подходят для интерактивной полиграфии.
Если у вас нет лучшей альтернативы — не имеете права критиковать.
Идите тогда на Марш Несогласных, или к Навальному на митинг, и там стойте в маске Гая Фокса с транспарантом «Вебъ долженъ уйти! Вебъ уходи!».
А эти «нативные приложения» ваши хвалёные — достаточно взглянуть на их код, сравнить этот код с html + css + js и больше не возвращаться к теме «нативных приложений»
Не вижу связи между «HTML/CSS-это плохо» и «веб must die». Помоему «веб» — это понятие, которое несколько шире, чем язык разметки. Мне, например, видятся в будущем тонны красивых формочек и прочих штучек, нарисованных с помощью JS прямо на Canvas (и, предположим, выглядящих как в OS/2, AmigaOS или, скажем, Unity). Единственное ограничение — «а как же Google?», но это вопрос решаемый в перспективе.
И кто мешает прямо сейчас написать прототип такого интерфейса? Да никто)
И кто мешает прямо сейчас написать прототип такого интерфейса? Да никто)
Будущее совсем близко, вот вам unity :)
А насчет гугла — не зря же он рекламирует хром по первому каналу. Способствует переходу пользователей на нормальный браузер (нормальный = не ИЕ6-7, не закидывайте ананасами пользователи фаерфокса, оперы и т.д.).
А насчет гугла — не зря же он рекламирует хром по первому каналу. Способствует переходу пользователей на нормальный браузер (нормальный = не ИЕ6-7, не закидывайте ананасами пользователи фаерфокса, оперы и т.д.).
Признаюсь честно. В университете я довольно неплохо учусь. Довольно неплохо(для университетского, разумеется, курса) понимаю в программировании. Пусть нас и мало чему учили там, начинали с делфи, заканчивали сишарпом, писали абстрактные машины, шифр фано, и тому подобные весёлости.
В данный момент стараюсь освоить С++/QT, в поте лица стараюсь полностью постичь дзен указателей (о коих разумеется не поведали на парах C#) и всякие хитрости адресной арифметики.
Но почему-то HTML/CSS я стараюсь обходить за тридевять земель. Не знаю. Есть что-то отталкивающее, пугающее. Я даже объяснить не могу, просто боюсь даже начинать. Нет, не потому что я боюсь выучить что-то новое для себя, это я как раз не боюсь, и даже люблю. Но вот HTML и CSS это для меня просто ад. Предпочту отдать деньги студии какой-нибудь, где мне сделают сайт, чем пытаться лезть в эту воронку. Я даже не могу сам себе объяснить природу этого явления. Из ряда вон.
В данный момент стараюсь освоить С++/QT, в поте лица стараюсь полностью постичь дзен указателей (о коих разумеется не поведали на парах C#) и всякие хитрости адресной арифметики.
Но почему-то HTML/CSS я стараюсь обходить за тридевять земель. Не знаю. Есть что-то отталкивающее, пугающее. Я даже объяснить не могу, просто боюсь даже начинать. Нет, не потому что я боюсь выучить что-то новое для себя, это я как раз не боюсь, и даже люблю. Но вот HTML и CSS это для меня просто ад. Предпочту отдать деньги студии какой-нибудь, где мне сделают сайт, чем пытаться лезть в эту воронку. Я даже не могу сам себе объяснить природу этого явления. Из ряда вон.
Да ничего страшного или странного, просто вы по натуре программист-системщик или программист-прикладник. Для того, чтобы писать под веб, нужен определённый настрой, желание и склад ума, что ли. Главное для Вас сейчас — понять, что без веба Вы никуда дальше не продвинетесь, мир вокруг Сети крутится и чем дальше, тем глубже.
Поэтому чем раньше Вы переборете своё «нихачу» и начнёте внедряться в эти технологии, тем светлее мне видится Ваше будущее.
Поэтому чем раньше Вы переборете своё «нихачу» и начнёте внедряться в эти технологии, тем светлее мне видится Ваше будущее.
Можно работать с вебом (и в вебе), но без HTML/CSS — разделение труда, фреймворки и всё такое.
Но вообще я человека понимаю — хотя сам уже не первый десяток лет периодически пишу на HTML & co., но делаю это без всякой охоты, через «не хочу» и «не могу». Основная причина — не получается разделять содержание от оформления, прежде всего разметку логических блоков от их визуальной раскладки. То есть пишу сначала чистый html, а потом начинаю его «пачкать», чтобы обеспечить нужное расположение и размер. С фиксированной вёрсткой ещё более-менее, а вот резиновая или, как сейчас модно, адаптивная…
Но вообще я человека понимаю — хотя сам уже не первый десяток лет периодически пишу на HTML & co., но делаю это без всякой охоты, через «не хочу» и «не могу». Основная причина — не получается разделять содержание от оформления, прежде всего разметку логических блоков от их визуальной раскладки. То есть пишу сначала чистый html, а потом начинаю его «пачкать», чтобы обеспечить нужное расположение и размер. С фиксированной вёрсткой ещё более-менее, а вот резиновая или, как сейчас модно, адаптивная…
Забавно, у меня, например, абсолютно противоположная ситуация.
HTML/CSS как-то легко «дался» и на мой взгляд весьма удобен. Но С (с плюсами и без), Delphi и так далее, для меня ад.
Так что тут, наверное, разница в складе ума, а не в средствах.
HTML/CSS как-то легко «дался» и на мой взгляд весьма удобен. Но С (с плюсами и без), Delphi и так далее, для меня ад.
Так что тут, наверное, разница в складе ума, а не в средствах.
Каждому свое, не люблю C(++) как раз из-за указателей которые в каждой бочке затычка. Я понимаю как они работают, но мне кажется что это слишком низкий уровень абстракции чтобы писать таким образом что-то кроме системного ПО. Python, Ruby — выбор мой.
А что в них сложного то? Если указывает на 0, то обьект удален, где создал обьект через new в том же классе его и изволь удалить!
Плюс пара умных указателей и разработка уже ничем не отличается от шарпов и явы.
Плюс пара умных указателей и разработка уже ничем не отличается от шарпов и явы.
Очередной программист профан залез в HTML\CSS и обосрался.
> Косвенное подтверждает данную оценку и тот факт, что почти все серьезные компании делают нативные приложения для мобильных телефонов, а не предлагают своим пользователям открывать их сайт в браузере
m.vk.com/
m.yandex.ru/
m.facebook.com/
www.google.com/mobile/
us.m.yahoo.com/
Причём сайты предоставляют широкий функционал. На своём проекте делал мобильную версию, за месяц сделал, работая примерно по паре часов в день над ним.
И с этой точки зрения автор показал себя не далёким и совершенно не компетентным в данном вопросе. Нативные приложения делают для того, чтобы вливаться в архитектуру ос. Использовать API, такие как уведомления, синхронизация контактов, натив код, open gl и тп. Нативные приложения зачастую выполняют более специфическую роль, к которой требуется доступ к общей архитектуре ос. Например, заглушить музыку в приложении, когда поступает входящий звонок. Тот же самый «тихий режим», когда приложение может быть закрыто (в пуше) и выводить уведомления о приходе сообщений. А если смотреть на тенденцию, то можно заметить, что html/css проникает и в разработку тех самым нативных приложений. Тот же Windows 8 взять хотя бы.
> Часто web-программисты и верстальщики применяя чей-то чужой прием даже не имеют в голове четкой модели, почему оно работает так, а не иначе.
На словах «Часто web-программисты» надо было и остановится, по тому что хорошему верстальщику чужие примеры уже не нужны.
> Открыв любой серьезный CSS-файл, например, написанный в Google или FB, увидишь в нем отрицательные границы элементов
Большие компании не застрахованы от того, что там могут работать люди, не должного уровня знаний. И это касается не только html / css. Тоже самое может быть и с любым другим языком программирования, на котором пишет специалист низкого уровня. Мало что ли делают говно кода в php, js, с? Зачастую хаки в цсс точно такой же говнокод. И связано это может быть либо из-за скудных знаний либо из-за не хватки времени и сроков сдачи. Второе чаще.
> Косвенное подтверждает данную оценку и тот факт, что почти все серьезные компании делают нативные приложения для мобильных телефонов, а не предлагают своим пользователям открывать их сайт в браузере
m.vk.com/
m.yandex.ru/
m.facebook.com/
www.google.com/mobile/
us.m.yahoo.com/
Причём сайты предоставляют широкий функционал. На своём проекте делал мобильную версию, за месяц сделал, работая примерно по паре часов в день над ним.
И с этой точки зрения автор показал себя не далёким и совершенно не компетентным в данном вопросе. Нативные приложения делают для того, чтобы вливаться в архитектуру ос. Использовать API, такие как уведомления, синхронизация контактов, натив код, open gl и тп. Нативные приложения зачастую выполняют более специфическую роль, к которой требуется доступ к общей архитектуре ос. Например, заглушить музыку в приложении, когда поступает входящий звонок. Тот же самый «тихий режим», когда приложение может быть закрыто (в пуше) и выводить уведомления о приходе сообщений. А если смотреть на тенденцию, то можно заметить, что html/css проникает и в разработку тех самым нативных приложений. Тот же Windows 8 взять хотя бы.
> Часто web-программисты и верстальщики применяя чей-то чужой прием даже не имеют в голове четкой модели, почему оно работает так, а не иначе.
На словах «Часто web-программисты» надо было и остановится, по тому что хорошему верстальщику чужие примеры уже не нужны.
> Открыв любой серьезный CSS-файл, например, написанный в Google или FB, увидишь в нем отрицательные границы элементов
Большие компании не застрахованы от того, что там могут работать люди, не должного уровня знаний. И это касается не только html / css. Тоже самое может быть и с любым другим языком программирования, на котором пишет специалист низкого уровня. Мало что ли делают говно кода в php, js, с? Зачастую хаки в цсс точно такой же говнокод. И связано это может быть либо из-за скудных знаний либо из-за не хватки времени и сроков сдачи. Второе чаще.
Те кто делают SASS/LESS/etc чтобы хоть как-то скрасить убожество CSS наверное тоже просто «не разобрались и обосрались».
Я бы так не написал, если бы автор статьи не начал в грубой форме показывать свою не компетентность в вопросах который он априори описывает как действительность. Эти моменты я описал выше.
> Те кто делают SASS/LESS/etc чтобы хоть как-то скрасить убожество CSS наверное тоже просто «не разобрались и обосрались».
НА пхп, жс любом другом языке разве нет фреймворков, библиотек, сред разработки?
> Те кто делают SASS/LESS/etc чтобы хоть как-то скрасить убожество CSS наверное тоже просто «не разобрались и обосрались».
НА пхп, жс любом другом языке разве нет фреймворков, библиотек, сред разработки?
> НА пхп, жс любом другом языке разве нет фреймворков, библиотек, сред разработки?
Конечно есть. Но возможность писать функции, менять значения переменных — это базовые вещи, спецификация языка. CSS же просто плюет на принцип DRY, исправляется это SASS'ом, с его переменными, миксинами, функциями.
Конечно есть. Но возможность писать функции, менять значения переменных — это базовые вещи, спецификация языка. CSS же просто плюет на принцип DRY, исправляется это SASS'ом, с его переменными, миксинами, функциями.
Это с точки зрения программиста, но цсс это просто набор правил а не полноценный язык. Но в целом я с вами полностью согласен в этом вопросе. Однако CSS3 отчасти уже решает эту проблему, хотя и не так, как хотелось бы.
habrahabr.ru/post/141920/
habrahabr.ru/post/141920/
На самом деле идеальным вариантом по времени/качеству будет что-то такое:
Один браузер, один стадарт, это просто идеальный мир утопия, все были бы довольны. Но в текущей модели ведения бизнеса, либо внутри такой компании начнут отдельные группы тянуть одеяло на себе, после чего часть команды отсоединится делать свой вариант браузера, либо другая мелкая компания будет постоянно подавать иски в антимонопольный комитет тем самым прессуя монополиста, либо сам монополист осознавая своё положение перестанет активно вносить улучшения в продукт под девизом того, что продукт будет в любом случае приносить деньги, так как нет альтернатив.
Ваша предпосылка бессистемности неверна (проверьте свойства системности хоть на стандарте HTML 4 1999-го года).
А следовательно, все ваше дальнейшее рассуждение бессмысленно.
А следовательно, все ваше дальнейшее рассуждение бессмысленно.
как верстальщик говорю, не понравился пост…
Для создания новой семантики разметки, языка для интерфейсов должны быть:
1. геометрические примитивы
2. примитивы текста
3. средства управления очередностью отрисовки, вывода на экран
4. примитивы истории
5. примитивы объектов БД
6. примитивы объектов для ООП
7. контейнеры для любых других объектов
8. точки входа для встраивания любых популярных языков, пусть будет JS, на котором можно было бы дописать всё что угодно
9. примитивы встроенных системных объектов
10. примитивы клиент — серверного взаимодействия и сервер-клиентного с подключаемыми модулями для любых систем обмена информацией
либо
1. единая среда компиляции, по сути виртуальная машина, для любых интерфейсов
2. возможность взаимодействия с периферийными устройствами
3. куча профильных фреймворков
в итоге:
— второй вариант лучше, но он в итоге приведет к тому же самому, что сейчас имеем.
— значит лучше первый, но даже Майкрософты взяли курс на ХТМЛ5, хотя у них были свои Windows Presentation Foundation и др. средства разработки интрефейсов, где было много всего полезного
— значит всё же первый лучше, но задача будет состоять из:
1. создания стандартов
2. создания кроссплатформенного браузера
3. внедрения, да так, чтобы не задохнулось всё это. самая сложная задача.
1. геометрические примитивы
2. примитивы текста
3. средства управления очередностью отрисовки, вывода на экран
4. примитивы истории
5. примитивы объектов БД
6. примитивы объектов для ООП
7. контейнеры для любых других объектов
8. точки входа для встраивания любых популярных языков, пусть будет JS, на котором можно было бы дописать всё что угодно
9. примитивы встроенных системных объектов
10. примитивы клиент — серверного взаимодействия и сервер-клиентного с подключаемыми модулями для любых систем обмена информацией
либо
1. единая среда компиляции, по сути виртуальная машина, для любых интерфейсов
2. возможность взаимодействия с периферийными устройствами
3. куча профильных фреймворков
в итоге:
— второй вариант лучше, но он в итоге приведет к тому же самому, что сейчас имеем.
— значит лучше первый, но даже Майкрософты взяли курс на ХТМЛ5, хотя у них были свои Windows Presentation Foundation и др. средства разработки интрефейсов, где было много всего полезного
— значит всё же первый лучше, но задача будет состоять из:
1. создания стандартов
2. создания кроссплатформенного браузера
3. внедрения, да так, чтобы не задохнулось всё это. самая сложная задача.
Не думаю, что корректно сравнивать HTML/CSS c элементами интерфейса OS/2. Так как элементы управления на HTML/CSS обладают безграничными возможностями кастомизации. Майкрософт попыталась сделать более структурированный язык разметки XAML, и получилась довольно громоздкая и сложная вещь. Не спорю, что постоянные хаки для HTML/CSS бесят, но тут большинство проблем создают конкретные реалицаии в браузерах.
> элементы управления на HTML/CSS обладают безграничными возможностями кастомизации
А так, например, можно?
А так, например, можно?
Основной тезис, кажется, верен: для создания Rich UI в Web нельзя обойтись только двумя языками — HTML да CSS.
Но вывод отсюда надо делать именно тот, который ужé сделали, можно сказать, миллионы разработчиков и пользователей: используйте JavaScript!
Но вывод отсюда надо делать именно тот, который ужé сделали, можно сказать, миллионы разработчиков и пользователей: используйте JavaScript!
Лично мне: начав с веба (html / css / javascript), переключившись на десктопные программы (и либы — WinAPI там, Qt, Cocoa, etc), сложно понять, как всё расположить с абсолютными координатами. И потом следить за изменением размеров там… В html / css однозначно легче.
Сочувствую тебе, друг. Ты дошел до конца и прочитал все комментарии, но так и не понял, должен умереть html или нет.
Чушь какая-то. Прекрасно делают и мобильные версии и мобильные приложения работающие в браузере. И никаких геморов с маркетами и сторами.
И вообще — стыдно таким взрослым ребятам бояться тэгов
Автор, тебе пора на пенсию! Выдохся.
Ну и конечно же просто боится верстать, ведь это так сложно, проще мышкой раставить кнопки, это ж понятно.
Ностальгий дело гиблое, иногда она даже может призводить к регрессу.
Поэтому призываю всех серьезных программистов вообще не кодировать в них ничего напрямую и даже не использовать близкие к ним по семантике фреймворки.
А я призываю, от таких людей отстранятся. Я не верстальщик, но против тех который прет против прогрессирующих тенологий, которые зарекомендовали себя и выполняют свою функцию по максимуму.
Многие забывают/не знают о таких гранях как технология и реализация технологии. Если осел глучит, то это не значит что текст html страницы и сss кода занимающий несколько байт, грузит систему. А если в плане юзабилит и поддержки — так они вообще идеальны (я не считаю отдельные случаи).
Ну и конечно же просто боится верстать, ведь это так сложно, проще мышкой раставить кнопки, это ж понятно.
Ностальгий дело гиблое, иногда она даже может призводить к регрессу.
Поэтому призываю всех серьезных программистов вообще не кодировать в них ничего напрямую и даже не использовать близкие к ним по семантике фреймворки.
А я призываю, от таких людей отстранятся. Я не верстальщик, но против тех который прет против прогрессирующих тенологий, которые зарекомендовали себя и выполняют свою функцию по максимуму.
Многие забывают/не знают о таких гранях как технология и реализация технологии. Если осел глучит, то это не значит что текст html страницы и сss кода занимающий несколько байт, грузит систему. А если в плане юзабилит и поддержки — так они вообще идеальны (я не считаю отдельные случаи).
Тут дело в том, что не доведена до ума технология (стандарты), не смотря на хорошую концепцию. CSS не решает до конца задачу отделения данных от их представления, ведь при вёрстке приходится писать html-код с оглядкой на возможности css (вернее на отсутствии желаемых).
Собственно то, что html пишет верстальщик (или фронтендер) говорит о том, что сама технология не совершенна. В идеальном мире верстальщик писал бы только css, а фронтендер добавлял бы динамику с помощью js. html остался бы на долю серверсайдщиков, выдавая логически размеченные данные по текстовому ТЗ не глядя на макет, как сейчас выдается xml или json.
Собственно то, что html пишет верстальщик (или фронтендер) говорит о том, что сама технология не совершенна. В идеальном мире верстальщик писал бы только css, а фронтендер добавлял бы динамику с помощью js. html остался бы на долю серверсайдщиков, выдавая логически размеченные данные по текстовому ТЗ не глядя на макет, как сейчас выдается xml или json.
Большинство знакомых профессиональных кодеров шаманы, и никогда не проникли в мир ИТ из полиграфии или других ветвей дизайна, если бы это не было шаманством. Вёрстка — решение технико-эстетических ребусов и подражание мастерам (кто учился в художественных школах, понимает фишку), ознакомленность с тем (посвященность), какие школы и гуру существуют. Это как раз то, что нужно для ощущения того, что твоя деятельность подлинно творческая, а решения авторские. Это кошмар для программистов, но дверь в этот мир для тех, кто иначе бы и не дёрнулся в эту сторону. Хорошо это или плохо, не знаю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Web must die