Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
Как-то туго читается. Хотя в целом весьма интересно. Спасибо.
В принципе, механизм расширения заложен в SGML и в XML. Не совсем понятно, захотят ли поддерживать эти механизмы авторы браузеров. С другой стороны, лично я сильно сомневаюсь и в том, что развитие HTML ведёт в светлое будущее.
На мой взгляд, HTML 5 больше напоминает очередное улучшение парового двигателя, когда рядом уже вовсю работает бензиновый или электрический.
На мой взгляд, HTML 5 больше напоминает очередное улучшение парового двигателя, когда рядом уже вовсю работает бензиновый или электрический.
На мой взгляд, HTML 5 больше напоминает очередное улучшение парового двигателя, когда рядом уже вовсю работает бензиновый или электрический.
Если я правильно понял автора статьи, и если придерживаться ваших терминов, туда пытаются добавить функции бензинового и электрического, с возможностью расширения до… ммм ядерного например :)
Мне кажется, идти надо совсем в другую сторону. Не смотря на все «улучшения» в HTML, на базе него всё ещё невозможно сделать P2P-решение. Любое такое решение может выглядеть, как P2P, но на самом деле по сути остаётся клиент-серверным.
Это как пример.
Точно так же, нельзя существенно изменить интерфейс. Да собственно, чтобы на мелочи не размениваться, сразу обобщу: до декстопных приложений, как до луны раком. Даже если что-то и можно сделать, приходиться писать немало javascript-кода.
Мне видится, что решение с Java-аплетами могло изменить ситуацию, но не изменило. Тем не менее, JVM сейчас гораздо более продвинутое решение, тем более open source. Но пока непонятно, будет ли кардинальный переход в эту сторону, и если будет, то когда.
Это как пример.
Точно так же, нельзя существенно изменить интерфейс. Да собственно, чтобы на мелочи не размениваться, сразу обобщу: до декстопных приложений, как до луны раком. Даже если что-то и можно сделать, приходиться писать немало javascript-кода.
Мне видится, что решение с Java-аплетами могло изменить ситуацию, но не изменило. Тем не менее, JVM сейчас гораздо более продвинутое решение, тем более open source. Но пока непонятно, будет ли кардинальный переход в эту сторону, и если будет, то когда.
Минуснул. Вы своими апплетами и кастомными кнопками делаете уродливыми мои интернеты.
Не понял, за что минуснули. Я держался в рамках обсуждения, высказывал мнение. Выскажите своё мнение, которое тоже можно обсудить.
Или минус на хабре уже ставится за несогласие с чужой позицией?
Или минус на хабре уже ставится за несогласие с чужой позицией?
Понимаете, HTML и HTTP проектируется с учетом того, что эти технологии будут использованы на абсолютно разном железе. Поэтому одна из основных задач w3c — это не придумать в новом стандарте как можно больше новых «рюшечек», которые бы дали креативным ребятам простор для творчества, а придумать гибкую систему, которая бы позволяла пользоваться www из консоли, из графического браузера, со смартфона со слабым процом, с гпс-навигатора, со стиральной машинки, через колонки (для слепых людей) наконец.
Далее. P2P — это хорошо, но далеко не всегда, и зачем вы его приплели к HTML, я понятия не имею. Как вы собираетесь сделать P2P решение «на базе HTML»? Хотя, кажется, я понял, что вы имеете ввиду. Вы хотите, чтобы HTML передавался посредством какого-нибудь P2P-протокола. С этим нет никаких проблем, уже есть децентрализованые сети с шифроваными каналами. Названия не помню, но гугль вам в помощь.
Третее, самое важное. Флэш, ява, эктивх, сильверлайт и прочая байда нужна КРАЙНЕ редко. Крайне! Редко! Я ебал в рот интерактив, звуки, мигающие кнопачки, летающие облачка и прочую дрянь. На данный момент флеш чаще всего нужен для аудио и видео плееров, но HTML5 обещает исправить ситуацию (в нем будут специальные теги, по которым браузер будет вставлять нативный контрол). Я молюсь своим богам, чтобы когда-нибудь вся эта проприетарная закрытая хрень исчезла вовсе.
Четвертое. По поводу «изменить интерфейс». Я считаю мудаками всех тех дизайнеров, которым не нравятся «стандарнтые» скроллбары, кнопки, чекбоксы, селекты и пр. Если я вижу, что мои любимые убунтовские кнопки заменяют на плод чьего-то больного воображения, я сатанею. Если у дизайнера рождается «оригинальное творческое решение», и он хочет заменить мой любимый серенький скролбарчик, к которому я привык, на котором работает колесо мыши, хоткеи и пр. на оранжево-зеленую дрянь, которая и на скроллбар вовсе непохожа, то я шлю ему лучи профессиональной импотенции. А если он подключает для этого своего скроллбара флеш-плеер, то таких лучей летит в 2 раза больше.
Дизайнер, блядь, должен работать в рамках технологии. В HTML не зря так «тяжело изменить интерфейс». Кнопки (и другие элементы интерфейса) должны рисоваться такими же, как и в нативном ГУИ операционки. Это повышает юзабилити и об этом пишут все известные юзабилити-специалисты со времен Якоба Нильсена. Если дизайнер заявляет, что серенькая кнопка рушит цветовой баланс его макета, то это значит, что херовый макет получился. Правильный дизайнер, рисуя макет, помнит, что кнопка (чекбокс, текстовое поле) у клиента может быть отрисована как угодно, и он не в праве менять ее внешний вид.
Конечно, существуют исключения. В основном это контролы, для которых в HTML не предусмотрено нативных реализации (автокомплит, календарь и пр.), но HTML5 и эту проблему решает.
У меня все.
Далее. P2P — это хорошо, но далеко не всегда, и зачем вы его приплели к HTML, я понятия не имею. Как вы собираетесь сделать P2P решение «на базе HTML»? Хотя, кажется, я понял, что вы имеете ввиду. Вы хотите, чтобы HTML передавался посредством какого-нибудь P2P-протокола. С этим нет никаких проблем, уже есть децентрализованые сети с шифроваными каналами. Названия не помню, но гугль вам в помощь.
Третее, самое важное. Флэш, ява, эктивх, сильверлайт и прочая байда нужна КРАЙНЕ редко. Крайне! Редко! Я ебал в рот интерактив, звуки, мигающие кнопачки, летающие облачка и прочую дрянь. На данный момент флеш чаще всего нужен для аудио и видео плееров, но HTML5 обещает исправить ситуацию (в нем будут специальные теги, по которым браузер будет вставлять нативный контрол). Я молюсь своим богам, чтобы когда-нибудь вся эта проприетарная закрытая хрень исчезла вовсе.
Четвертое. По поводу «изменить интерфейс». Я считаю мудаками всех тех дизайнеров, которым не нравятся «стандарнтые» скроллбары, кнопки, чекбоксы, селекты и пр. Если я вижу, что мои любимые убунтовские кнопки заменяют на плод чьего-то больного воображения, я сатанею. Если у дизайнера рождается «оригинальное творческое решение», и он хочет заменить мой любимый серенький скролбарчик, к которому я привык, на котором работает колесо мыши, хоткеи и пр. на оранжево-зеленую дрянь, которая и на скроллбар вовсе непохожа, то я шлю ему лучи профессиональной импотенции. А если он подключает для этого своего скроллбара флеш-плеер, то таких лучей летит в 2 раза больше.
Дизайнер, блядь, должен работать в рамках технологии. В HTML не зря так «тяжело изменить интерфейс». Кнопки (и другие элементы интерфейса) должны рисоваться такими же, как и в нативном ГУИ операционки. Это повышает юзабилити и об этом пишут все известные юзабилити-специалисты со времен Якоба Нильсена. Если дизайнер заявляет, что серенькая кнопка рушит цветовой баланс его макета, то это значит, что херовый макет получился. Правильный дизайнер, рисуя макет, помнит, что кнопка (чекбокс, текстовое поле) у клиента может быть отрисована как угодно, и он не в праве менять ее внешний вид.
Конечно, существуют исключения. В основном это контролы, для которых в HTML не предусмотрено нативных реализации (автокомплит, календарь и пр.), но HTML5 и эту проблему решает.
У меня все.
эмоционально, но со многим согласен
Вы поймите, что для всего этого не нужно изобретать HTML 5, XHTML и CSS3. Все (как вы говорите), блядь, основные возможности были уже в HTML 4.0. Если не надо ничего нового, это понятно, и пора остановиться.
Если надо (а к этому всё и идёт), то полумеры не решают проблемы. Не решают.
P.S. Про P2P это было чисто в качестве примера. Вот как раз сейчас придумываю проект, где P2P был бы очень кстати. Но нет такой возможности. Клиент должен обязательно обратиться к серверу, а уж сервер может интеллектуально перенаправить запрос на другой сервер в другом дата-центре. Пока единственное средство распределения это round robin DNS, больше ничего нет.
Если надо (а к этому всё и идёт), то полумеры не решают проблемы. Не решают.
P.S. Про P2P это было чисто в качестве примера. Вот как раз сейчас придумываю проект, где P2P был бы очень кстати. Но нет такой возможности. Клиент должен обязательно обратиться к серверу, а уж сервер может интеллектуально перенаправить запрос на другой сервер в другом дата-центре. Пока единственное средство распределения это round robin DNS, больше ничего нет.
Все правильно.
Но вы забываете, что здесь обсуждается именно семантика HTML.
Но вы забываете, что здесь обсуждается именно семантика HTML.
Товарищи, это какой-то пиздец. Столько минусов за простое высказывание нестандартного мнения?
Если на хабре такой контингент, без интереса к обсуждению технологий, без работы фантазии, то я не знаю, что тут делать программисту. :(
Большое желание возникло с хабра уходить. :(
Если на хабре такой контингент, без интереса к обсуждению технологий, без работы фантазии, то я не знаю, что тут делать программисту. :(
Большое желание возникло с хабра уходить. :(
Ничего-ничего. Так всегда было и будет.
Будем помалкивать и продвигать свои идеи без лишнего шумка.
Не сцать! :)
Будем помалкивать и продвигать свои идеи без лишнего шумка.
Не сцать! :)
Удивительные вещи творятся. Если и пришлось чему-нибудь научиться за всё время работы, так это тому, что наши знания весьма скоротечны — каждые 3-5 лет нужно себя вытягивать из накатанных технологий, и изучать новое.
Выходит, интерес к новым технологиям и идеям — это профессиональный навык. Странно во времена Google Docs слышать «это всё нам не нужно».
Выходит, интерес к новым технологиям и идеям — это профессиональный навык. Странно во времена Google Docs слышать «это всё нам не нужно».
Жаль только что производители броузеров не особо то и смотрят на стандарты.
Все равно какой нибудь IE прикрутит у себя «Фичу» описанную и работающую только в нем, а другие повторят ее но используя свои тэги. и пошло поехало.
Как по мне то должен действовать международный закон который бы регулировал эти вопросы.
Все равно какой нибудь IE прикрутит у себя «Фичу» описанную и работающую только в нем, а другие повторят ее но используя свои тэги. и пошло поехало.
Как по мне то должен действовать международный закон который бы регулировал эти вопросы.
Ага, с уголовной ответственностью. =)
А если школьник написал свой браузер на паскале, его тоже?
думаю чтобы всем было хорошо, всех браузерописателей пересадить на 1 открытый движок рендеринга и обработки кода. тогда все новое будет появляться во всех браузерах одновременно и не нужно тестить в 10ти браузерах, а чтобы не застаивалось у пользователя — во всех браузерах авто-апдейт по тихому, например как в ff
думаю чтобы всем было хорошо, всех браузерописателей пересадить на 1 открытый движок рендеринга и обработки кода. тогда все новое будет появляться во всех браузерах одновременно и не нужно тестить в 10ти браузерах, а чтобы не застаивалось у пользователя — во всех браузерах авто-апдейт по тихому, например как в ff
По законам РФ — уголовную ответственность человек несет с 14 лет:
1. 0-14 лет — сажаем родителей, что б не подпускали своих детей к написанию броузеров
2. 14-18 — в колонию
3. 18-и более — на зону или расстрел
:)
1. 0-14 лет — сажаем родителей, что б не подпускали своих детей к написанию броузеров
2. 14-18 — в колонию
3. 18-и более — на зону или расстрел
:)
Плохой вариант, так как открытый движок может быть хуже или мделенней (или просток ак ФФ есть больше памяти). Лучше уж хороший закрытый.
Можно и с уголовной.
Для начала можно просто высылать разработчикам полосатую робу, для предупреждения.
Для начала можно просто высылать разработчикам полосатую робу, для предупреждения.
с уголовной — не с уголовной, а с административной вполне уже начинают работать подобные законы ;)
Как по мне то должен действовать международный закон который бы регулировал эти вопросы.
Ну так что за кривой программный код броузеров расстреливать? Не, я то не против, особенно по отношению к некоторым.
Но, как вы написали «фича», это же не нарушает стандарты, это «бонус» от создателей броузера, не нужно это копировать. А вот кривость обработки кода — это вопрос открытый
Давно всем разработчикам надо собраться и написать письмо в общество по защите прав человека.
Сколько можно терпеть издевательства от производителей браузеров? Точнее производителя. Браузера.
Сколько можно терпеть издевательства от производителей браузеров? Точнее производителя. Браузера.
возможно, я чего-то не понял… но я не увидел никаких преимуществ у предложенного автором статьи подхода по сравнению с XML :/
«Зачем мы изобретать эти новые элементы?»
«добавление этих элементов мы увеличим семантику HTML».
Выглядит, как перевод Stylus'ом или Promt'ом.
«добавление этих элементов мы увеличим семантику HTML».
Выглядит, как перевод Stylus'ом или Promt'ом.
автор переведённого поста не в теме
во-первых, он не знает про то, что ие начинает нормально стилить любые элементы после яваскриптового вызова, например, document.createElement('section')
во-вторых, он не знает, для чего делается html 5: в первую очередь для того, чтобы огромная масса существующих сайтов разной степени кривости обрабатывалась браузерами одинаково
во-первых, он не знает про то, что ие начинает нормально стилить любые элементы после яваскриптового вызова, например, document.createElement('section')
во-вторых, он не знает, для чего делается html 5: в первую очередь для того, чтобы огромная масса существующих сайтов разной степени кривости обрабатывалась браузерами одинаково
Немного не по теме, но все же. Если будет возможность я буду использовать XHTML 2, вместо HTML 5. Меня, например, пугают элементы nav, footer и т.п. и ввергает в ступор возможность не закрывать теги (насколько я помню, в HTML 5 это разрашено). Если же говорит о большей привлекательности для поисковых роботов, то я не вижу особого преимущества тега nav перед sitemap (отдельной xml-картой сайта).
Надо идти ещё дальше. :) Я тут выше отписывал про аплеты, но не развернул. В чём проблема аплетов с самого начала была? В том что это совершенно отдельная сущность на странице. По большому счёту, страница отдельно, аплет отдельно.
В то же время, смотрим, куда движется CSS. В каждой версии добавляют визуальные возможности, сейчас речь идёт о тенях и разноцветных рамках. При всём при этом предлагается лишь фиксированный набор обновлений: если я хочу, например, чтобы выводился только контур букв, я могу сделать это только в фотошопе.
Вот если бы браузер и виртуальная машина были вместе в одном флаконе, можно было бы писать код, например на Java, и привязывать его к элементам на странице, так, как это делает CSS:
В то же время, смотрим, куда движется CSS. В каждой версии добавляют визуальные возможности, сейчас речь идёт о тенях и разноцветных рамках. При всём при этом предлагается лишь фиксированный набор обновлений: если я хочу, например, чтобы выводился только контур букв, я могу сделать это только в фотошопе.
Вот если бы браузер и виртуальная машина были вместе в одном флаконе, можно было бы писать код, например на Java, и привязывать его к элементам на странице, так, как это делает CSS:
#navigation
{
drawOutline(innerText);
}
А вы не думали, что не на каждом клиенте можно гонять ява-машину?
В том то и дело, что уже на каждом. Когда ява встроена в мобильные телефоны ниже среднего, это уже не знак, это симптом. :)
С другой стороны, если речь вести именно об интеграции, то эта проблема решаема. Наверное. :)
Собственно, я не могу похвататься готовым решением, я просто вижу тенденцию. Производители сайтов хотят функциональности десктопных клиентов. А разработчики стандаров, вместо того, чтобы решить проблему кардинально раз и навсегда, двигаются по капле в год.
С другой стороны, если речь вести именно об интеграции, то эта проблема решаема. Наверное. :)
Собственно, я не могу похвататься готовым решением, я просто вижу тенденцию. Производители сайтов хотят функциональности десктопных клиентов. А разработчики стандаров, вместо того, чтобы решить проблему кардинально раз и навсегда, двигаются по капле в год.
Ознакомился. Пока несколько напрягает XML-синтаксис программ. :)
Байт код хорош производительностью и тем, что писать можно на разных языках программирования.
И пока не совсем понятны возможности. Вот недавно на хабре пробегала статья про интеллектуальный (liquid) ресайз картинок, когда растягиваются/сжимаются незначимые детали, а значимые остаются неизменными. Предположим, разработчик Ivan Smirnoff сделал такую библитеку. А мы в разделе head пишем что-то вроде include, и затем назначаем элементам img с классом liquid именно такой ресайз. Хотелось бы чего-то такого. :)
Байт код хорош производительностью и тем, что писать можно на разных языках программирования.
И пока не совсем понятны возможности. Вот недавно на хабре пробегала статья про интеллектуальный (liquid) ресайз картинок, когда растягиваются/сжимаются незначимые детали, а значимые остаются неизменными. Предположим, разработчик Ivan Smirnoff сделал такую библитеку. А мы в разделе head пишем что-то вроде include, и затем назначаем элементам img с классом liquid именно такой ресайз. Хотелось бы чего-то такого. :)
> В то же время, смотрим, куда движется CSS. В каждой версии добавляют визуальные возможности, сейчас речь идёт о тенях и разноцветных рамках.
Нас всех спасет декларативное программирование.
Тот же CSS можно заменить реактивным программированием, а потом добавить сахару, чтобы дизайнерам поменьше думать.
Нас всех спасет декларативное программирование.
Тот же CSS можно заменить реактивным программированием, а потом добавить сахару, чтобы дизайнерам поменьше думать.
role уже используется в htmlayout. там же есть такие свойства селекторов css, о поддержке которых остальными браузерами остается лишь мечтать.
html — стандарт для представления информации. И именно в сторону качественного улучшения механизмов представления движется HTML 5. Некоторым (в том числе автору статьи) иногда кажется, что это движение слишком мягкое, осторожное, медленное… не революционное, наконец. Но только им не хватает чего-то, чтобы понять, что этот как раз и вызвано наличием немалого опыта (HTML <= 4.1, XHTML), заботой о совместимостях любого уровня и направления, просто на порядки другой глубиной понимания проблемы — не ограниченной высплывшей откуда-то семантикой. Вам кажется, что никаких других целей, кроме расширяемости семантики HTML 5 не преследует? Сочувствую.
А вот расширяемый (и в первую очередь с т.з. семантики) формат данных есть и с успехом используется теми, кому это в самом деле необходимо. И имя ему, как ни странно, XML. Для связи второго с первым есть, как минимум, XSLT.
Извините, если где резковато, но статья и многие ваши комментарии при её обсуждении сформировали у меня именно такой эмоциональный фон для комментария.
А вот расширяемый (и в первую очередь с т.з. семантики) формат данных есть и с успехом используется теми, кому это в самом деле необходимо. И имя ему, как ни странно, XML. Для связи второго с первым есть, как минимум, XSLT.
Извините, если где резковато, но статья и многие ваши комментарии при её обсуждении сформировали у меня именно такой эмоциональный фон для комментария.
Вам кажется, что вы умнее и опытнее автора статьи? Тогда почему я не видел ваших статей на A List Apart?
все умные и опытные люди обязаны что-нибудь написать для этого сайта на буржуйском языке?
Нет, но это для меня показатель уровня автора.
К сожалению Джон не может, в силу языкового барьера, вам ответить. Прежде чем выступать с комментариями, прочитайте ответ автора в обсуждении статьи: www.alistapart.com/comments/semanticsinhtml5?page=7#65
Было бы, конечно, неплохо перевести это и прикрепить к самой статье, но я плохой переводчик.
К сожалению Джон не может, в силу языкового барьера, вам ответить. Прежде чем выступать с комментариями, прочитайте ответ автора в обсуждении статьи: www.alistapart.com/comments/semanticsinhtml5?page=7#65
Было бы, конечно, неплохо перевести это и прикрепить к самой статье, но я плохой переводчик.
не, показатель уровня автора в том, что он нигде не указал, что это перевод…
так и знал, что где-то в тексте есть приписка мелким шрифтом, чтобы никто не заметил…
Это не приписка и не в тексте.
Зачем писать в тексте, что это статья того то, от туда то. При написании поста есть специальные поля.
Зачем писать в тексте, что это статья того то, от туда то. При написании поста есть специальные поля.
так и представляю себе: юзер в приступе сомнений водит мышью по всем контролам на странице в поисках заветного тайтла «автор оригинала»…
Кому надо, найдут, вернее они и так знают, а кому пох… ну тут не о чем разговаривать.
я кажется начинаю понимать, почему такие аффтары как ты предпочитают публиковать свои переводы на хабре… можно кому угодно дать ссылку на свою ленту и пришедшие на неё читатели будут уверены, что все эти умные слова написаны тобой, а не каким-то дятькой из буржуиндии.
а кому надо… (а кому надо _искать_?) — того всегда можно ткнуть носом в последнюю страницу книги, где мелким шрифтом написано имя реального автора, а надпись «автор оригинала» проявляется только при поднесении бумаги к огню…
а кому надо… (а кому надо _искать_?) — того всегда можно ткнуть носом в последнюю страницу книги, где мелким шрифтом написано имя реального автора, а надпись «автор оригинала» проявляется только при поднесении бумаги к огню…
>Вам кажется, что вы умнее и опытнее автора статьи?
>Тогда почему я не видел ваших статей на A List Apart?
Простите, обсуждать статьи авторов A List Apart нельзя вообще или только на хабре?
Я что-то пропустил?
>Тогда почему я не видел ваших статей на A List Apart?
Простите, обсуждать статьи авторов A List Apart нельзя вообще или только на хабре?
Я что-то пропустил?
кстати, расследование убийства хтмл скоро подойдёт к концу ;-) d-o-b.ru/?article:kill.html
мне кажется к тому времени когда html 5 будет использоваться повсеместно и в полную силу ie6 уже отомрет, так что нету смысла брать его в расчет…
проблема html5 — это проблема IE6 :)
проблема развития интернета, форматов, возможностей дизайна, безопасности пользователей — проблема IE6.
я бы на месте людей, заинтересованных во введении новых единых форматов, вел активную пропаганду отказа от IE6. а лучше — вообще от IE.
проблема развития интернета, форматов, возможностей дизайна, безопасности пользователей — проблема IE6.
я бы на месте людей, заинтересованных во введении новых единых форматов, вел активную пропаганду отказа от IE6. а лучше — вообще от IE.
в html5, для каждого сайта должна быть своя либа тегов и атрибутов (по необходимости), в которой бы указывалось браузеру, как обрабатывать неизвестные ему теги/атрибуты — мне кажется решается проблема статьи…
некоторые теги конечно стоит объявить стандартными, но постоянного гоняться за новым не получится, вот эта либа будет играть роль таких стандартов. Более ужившиеся, заносить в какую-то базу, где можно будет их постоянно черпать :) как делает виста/вин7 сейчас
а вообще вода в ступе, это всё уже обсуждалось… разложение ИЕ6 ускорилось заметно!
некоторые теги конечно стоит объявить стандартными, но постоянного гоняться за новым не получится, вот эта либа будет играть роль таких стандартов. Более ужившиеся, заносить в какую-то базу, где можно будет их постоянно черпать :) как делает виста/вин7 сейчас
а вообще вода в ступе, это всё уже обсуждалось… разложение ИЕ6 ускорилось заметно!
с abbr действительно глупость получилась.
но что мешает нам использоват другой элемент, например var или вообще span?
спека не запрещает, а что operator не понимает hcalendar без abbr — так это проблемы hcalendar, т.к. по спеке обязан.
парсер понимает замечательно.
но что мешает нам использоват другой элемент, например var или вообще span?
спека не запрещает, а что operator не понимает hcalendar без abbr — так это проблемы hcalendar, т.к. по спеке обязан.
парсер понимает замечательно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Семантика в HTML 5