Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 190
Что-то я уже читал похожее, только другими словами.
Знаете мне этот топик очень нравится, но как показало исследование все плюют на стандарты с большой колокольни.
99% сайтов в сети не проходят валидацию на стандарты.
Поэтому вы смелый человек ;)
Я вас поддерживаю на пути «стандартизации» web-a своим голосом.
:)
99% сайтов в сети не проходят валидацию на стандарты.
Поэтому вы смелый человек ;)
Я вас поддерживаю на пути «стандартизации» web-a своим голосом.
:)
Не смотрите на других. Делайте по стандартам.
«Хочешь изменить мир — начни с себя»
«Хочешь изменить мир — начни с себя»
спасибо, конечно, но у меня вопросы
в чем тут состоит моя смелость? при чем тут валидация? надеюсь, вы знаете разницу между xhtml и html?
PS: минус вам поставил не я
в чем тут состоит моя смелость? при чем тут валидация? надеюсь, вы знаете разницу между xhtml и html?
PS: минус вам поставил не я
Если не будет стандартов — будут опять появляться ослики на которых будут плеваться.
Почему смелый? Да потому, что очень много людей как оказалось «не поддерживают» стандарты. Плюс вы сами знаете процент сайтов, которые плевали на стандарты. Поэтому как говорится, тот кто в меньшинстве, тот должен быть смелым :)))
Минус вам тоже не я поставил :)
Почему смелый? Да потому, что очень много людей как оказалось «не поддерживают» стандарты. Плюс вы сами знаете процент сайтов, которые плевали на стандарты. Поэтому как говорится, тот кто в меньшинстве, тот должен быть смелым :)))
Минус вам тоже не я поставил :)
Стандарты ни при чем. Если вместо 20 строчек javascript'a и последнующий валидацией submit'a на серверной стороне после ввода login\password вам нужно будет всего лишь описать input'ы как web form, то этим и будут пользоваться. А стандартами пренебрегают потому что следование им, по-хорошему, не влияет на посещаемость\прибыль )
p.s. imho
p.s. imho
Знаете, иногда влияет.
Особенно когда клиент это ощущает на себе, просто тот кто плюют на стандарты, обычно не очень придерживается и проверки того как работает сайт и как влияют ошибки на поведение клиентов.
Я уже писал по этому поводу. Например opera натыкаясь на ошибки начинает загружать сайт заново, так как её рендер рисует сразу. Хорошо, когда быстрый канал, вы даже не заметите. А если «проседающий» и медленный. habr например на opera и слабом канале невозможно читать.
Кстати.
Китайские автомобили тоже ездят ;)
И наверняка дают прибыль «конструкторам»
Мы что китайцы?
Особенно когда клиент это ощущает на себе, просто тот кто плюют на стандарты, обычно не очень придерживается и проверки того как работает сайт и как влияют ошибки на поведение клиентов.
Я уже писал по этому поводу. Например opera натыкаясь на ошибки начинает загружать сайт заново, так как её рендер рисует сразу. Хорошо, когда быстрый канал, вы даже не заметите. А если «проседающий» и медленный. habr например на opera и слабом канале невозможно читать.
Кстати.
Китайские автомобили тоже ездят ;)
И наверняка дают прибыль «конструкторам»
Мы что китайцы?
Валидация со стороны сервера будет всегда. Потому что злостных хакеров никто не отменял.
Насчет валидации с js — как насчет собственных валидаторов (например, валидный IP)? Будем делать на js и регистрировать через API? Тогда от 20 строк останется 10, что по большому счету не меняет смысла, т.к. нам все равно придется делать самим. + все больше валидаторов нестандартных форм работают через аякс. Это уже вообще не имеет отношения к стандарту html.
Насчет валидации с js — как насчет собственных валидаторов (например, валидный IP)? Будем делать на js и регистрировать через API? Тогда от 20 строк останется 10, что по большому счету не меняет смысла, т.к. нам все равно придется делать самим. + все больше валидаторов нестандартных форм работают через аякс. Это уже вообще не имеет отношения к стандарту html.
Вы хоть сами поняли, что написали?
Я вам подскажу — бред
Я вам подскажу — бред
Что именно вы посчитали бредом? Если html5 предоставит нам 5-10-25 предустановок валидатора, все равно будет мало. Это упростит работу программерам на простых формах, не более.
PS Я не против новых стандартов, я за то, чтобы стандарты вносили востребованные фичи.
PS Я не против новых стандартов, я за то, чтобы стандарты вносили востребованные фичи.
данные атрибуты (required и email) в дальнейшем могут быть полезны еще тем что, если введут их поддержку в CSS можно будет ими соответственно манипулировать, задавать однообразные стили
это первое что пришло в голову, правда надеюсь атрибуты сделают все же xhtml-совместимыми
это первое что пришло в голову, правда надеюсь атрибуты сделают все же xhtml-совместимыми
Не обижайтесь. Ok. Например.
>Валидация со стороны сервера будет всегда
Это как понимать? И т.п. по тексту.
Может я не понял, что вы хотели сказать. (такое бывает)
Так вы все же за стандарты ;)?
>Валидация со стороны сервера будет всегда
Это как понимать? И т.п. по тексту.
Может я не понял, что вы хотели сказать. (такое бывает)
Так вы все же за стандарты ;)?
Валидация на сервере будет всегда, не смотря на любое количество валидаторов. Это я к этой фразе:
>> Если вместо 20 строчек javascript'a и последнующий валидацией submit'a на серверной стороне после ввода login\password вам нужно будет всего лишь описать input'ы как web form, то этим и будут пользоваться.
С серверной стороны все равно придется проверять корректность, т.к. никто не застрахован от хакеров, которые составят запрос ручками и сделают с вашим ресурсом что-то нехорошее :)
Далее, такие валидаторы задают поведение вебприложения, не зависящее от разработчика (по крайней мере, в статье ничего об управлении поведением не сказано). Кастомизацию этого поведения все равно придется делать вручную. Все это дает очень небольшой выигрыш по сравнению с чистым яваскриптом. То есть, фича не шибко актуальная, а шуму вокруг нее…
>> Если вместо 20 строчек javascript'a и последнующий валидацией submit'a на серверной стороне после ввода login\password вам нужно будет всего лишь описать input'ы как web form, то этим и будут пользоваться.
С серверной стороны все равно придется проверять корректность, т.к. никто не застрахован от хакеров, которые составят запрос ручками и сделают с вашим ресурсом что-то нехорошее :)
Далее, такие валидаторы задают поведение вебприложения, не зависящее от разработчика (по крайней мере, в статье ничего об управлении поведением не сказано). Кастомизацию этого поведения все равно придется делать вручную. Все это дает очень небольшой выигрыш по сравнению с чистым яваскриптом. То есть, фича не шибко актуальная, а шуму вокруг нее…
вероятно, имелось ввибду «должна быть»
ибо )))
ибо протокол HTTP никто пока не меняет, а значит невалидные данные всегда можно подсунуть ручками ;-)
ибо )))
ибо протокол HTTP никто пока не меняет, а значит невалидные данные всегда можно подсунуть ручками ;-)
Неплохо бы ввести в эти формы нового HTML-а поддержку регулярных выражений. Что-нибудь в духе:
<input name='username' type='text' pattern='^([A-z0-9\_]){3,16}$' />
Рано или поздно лень доведет раз-ов и до этого…
Но до тех пор, чувствую, состарюсь )))
:)
Кушай витамины и доживешь, а то и переживешь.
Кушай витамины и доживешь, а то и переживешь.
caniuse.com/#feat=input-pattern — как поживаете, как Ваша старость? :)
ну конечно, и будет вызываться стандартное убогое алерт-окно. имхо здесь они должны дополнительно внедрить способ перегрузки функций валидации или способ назначения существующего дива/блока вместо стандартного окна. Ну в идеальном случае должен появиться тег <alert-window> со всеми нужными под-блоками типа header>title|right|left, content>right|left,footer>right/left, и чтобы это все добро можно было управлять из css…
мысль пошла дальше…
имхо: в html5 не помешало бы внедрить систему переопределения вида этих стандартных диалоговых окошек и перегрузки функция для их обслуживания.
мысль пошла дальше…
имхо: в html5 не помешало бы внедрить систему переопределения вида этих стандартных диалоговых окошек и перегрузки функция для их обслуживания.
Как обычно, понеслось, стадное явление.
Вот сами видите, как народ относится к стандартам.
Комментарии я думаю излишни.
А вы говорите про что-то большее.
Вот сами видите, как народ относится к стандартам.
Комментарии я думаю излишни.
А вы говорите про что-то большее.
Посмотрел я на свои комменты в топике и понял — опять начало попахивать троллями.
А говорят троллей не бывает :)
А говорят троллей не бывает :)
Народ так относится не к стандартам, а к излишнему фанатизму, который вы отношении этих самых стандартов проявляете. Я вот тоже люблю стандарты, но не люблю фанатизм.
Знаете, если не проявлять, как вы называете фанатизм, то все может покатится к анархии. И что мы наблюдаем. Ведь не секрет, 90% сайтов в сети мягко говоря оставляет желать лучшего.
Давайте посмотрим например со стороны автопроизводителей.
Китайцы, плюют на все креш-тесты и стандарты iso в угоду прибыли.
Какое сейчас отношение к китайским машинам.
Это еще не все.
А теперь представьте начнут плевать на стандарты mercedes, bmw, audi и т.п.
Сколько будет трагедий в мире?
Это конечно гиперболическое сравнение, но все может подойти к тому.
Уже и до web докатывается. Например не соблюдение стандартов может привести к утечкам важных данных и т.п. что может тоже привести к трагедиям.
Люди по натуре своей беспечные существа, даже животные гораздо осторожнее.
Я тоже не люблю фанатиков.
Иногда просто надо быть немного фанатом.
Я честно говоря не понимаю, почему люди так «ополчились» против стандартов в web.
Я уже писал. Пассажир садится в Боинг и командир корабля им обьявляет. Что из самолет не соответствует стандартом, зато будет лететь очень быстро.
А люди у нас очень беспечные. Могут спокойно купить китайскую подделку, которая не проходит не одного креш теста и продажа запрещена в евросоюзе, думая — авось пронесет.
Давайте посмотрим например со стороны автопроизводителей.
Китайцы, плюют на все креш-тесты и стандарты iso в угоду прибыли.
Какое сейчас отношение к китайским машинам.
Это еще не все.
А теперь представьте начнут плевать на стандарты mercedes, bmw, audi и т.п.
Сколько будет трагедий в мире?
Это конечно гиперболическое сравнение, но все может подойти к тому.
Уже и до web докатывается. Например не соблюдение стандартов может привести к утечкам важных данных и т.п. что может тоже привести к трагедиям.
Люди по натуре своей беспечные существа, даже животные гораздо осторожнее.
Я тоже не люблю фанатиков.
Иногда просто надо быть немного фанатом.
Я честно говоря не понимаю, почему люди так «ополчились» против стандартов в web.
Я уже писал. Пассажир садится в Боинг и командир корабля им обьявляет. Что из самолет не соответствует стандартом, зато будет лететь очень быстро.
А люди у нас очень беспечные. Могут спокойно купить китайскую подделку, которая не проходит не одного креш теста и продажа запрещена в евросоюзе, думая — авось пронесет.
Вот вы сами и обозначили проблему: корень в беспечности, а несоблюдение стандартов — это лишь следствие. А теперь подумайте, можете ли вы с этим что-то сделать. Ваши словесные тирады, как видите, не очень-то убеждают людей.
Ну скажем так — больше половины минусов это от троллей. Вторая треть — это люди не вдумывались в коммент, ставя стадно минус.
А те кто читает, все же анализируя мое мнение, может и согласится.
Я прекрасно знаю, что есть пару людей, которые имея виртуальную армию троллей меня мягко сказать недолюбливает. Видя мой зелененький квадратик, ставят сразу минус не раздумывая.
Это детство.
А те кто читает, все же анализируя мое мнение, может и согласится.
Я прекрасно знаю, что есть пару людей, которые имея виртуальную армию троллей меня мягко сказать недолюбливает. Видя мой зелененький квадратик, ставят сразу минус не раздумывая.
Это детство.
Не, всё-таки не поняли. :)
Минусуют за троллинг Вас. Ваш первый комментарий — типичная попытка разжечь холивар.
Это и называется троллингом.
Минусуют за троллинг Вас. Ваш первый комментарий — типичная попытка разжечь холивар.
Это и называется троллингом.
И в мыслях не было.
Холивар, боливар, посмотрите — почти каждый топик это своего рода холивар.
Все наше общение это сплошной холивар.
Любой коммент можно назвать ходиваром ;) Только такое количество минусов я видел, только тогда когда кто-то кого-то «посылает» :) а я ни кого не оскорблял.
А не троллинг ли, когда в течении 5 минут — все комменты, и не только в этом топике, получают кучу минусов? Даже самые «безобидные».
Холивар, боливар, посмотрите — почти каждый топик это своего рода холивар.
Все наше общение это сплошной холивар.
Любой коммент можно назвать ходиваром ;) Только такое количество минусов я видел, только тогда когда кто-то кого-то «посылает» :) а я ни кого не оскорблял.
А не троллинг ли, когда в течении 5 минут — все комменты, и не только в этом топике, получают кучу минусов? Даже самые «безобидные».
Если моя словесная тирада, хоть одного человека переубедит, значит не зря писал, я же не кого не оскорбляю (как, кстати, обычно делают фанаты) :)
о да, добавили несколько новых элементов… но решили ли проблему? новых элементов будет также нехватать. новые валидаторы будут вести себя не так как надо (например, как поведёт себя required поле, если ввести в него неразрывный пробел?). новые аудио-видео плееры не дадут того богатства возможностей, что уже есть во флеше (рекомендации, реклама, постпроцессинг, пермалинк), а потому не будут востребованы. канва? да, замечательно, но при чём тут html?
к чему это я? а, xml рулит ^_^ и очень жаль, что разработчики браузеров (и в особенности мелкософт) не стремятся к развитию *расширяемого* языка разметки, предпочитая ему гору частных решений в виде html5.
к чему это я? а, xml рулит ^_^ и очень жаль, что разработчики браузеров (и в особенности мелкософт) не стремятся к развитию *расширяемого* языка разметки, предпочитая ему гору частных решений в виде html5.
Меня немного смущают эти теги для «облегчения вёрстки». А что если у меня навигация сбоку, какой тег в какой вкладывать, nav в aside или наоборот? Или применять только один из них…
вложите один в другой, делов-то :)
Видимо, тэги всё же определяют функцию, а не расположение, поэтому тэг навигации можно располагать хоть сверху, хоть сбоку.
А не надо их вкладывать. Они одного уровня.
они не столько для облегчения верстки, сколько для структурирования информации на странице (из топика: "Для примера, внешняя система, такая как поисковой бот, может более точно определять какой контент на web-странице более важен.")
в текущей версии HTML сложно точно отличить содержание страницы от всего остального
в текущей версии HTML сложно точно отличить содержание страницы от всего остального
Все нововведения просто потрясающи. Меньше проблем с валидацией, семантическая верстка… Веб 3.0 не за горами, господаю
Судя по приведенным примерам кода — HTML 5 предполагается быть XML-валидным?
Про «canvas» — думаю, ввиду развития Flash и Silverlight — у него нет большого будущего. Ибо, скажем, Flash — это уже готовая графическая подсистема, движок, набор инструментов, при этом с хорошими возможностями интеграции, а canvas — это просто «холст», для которого даже графический движок нужно создавать, чтобы им пользоваться.
А вообще забавно, на самом деле, как же долго формируются такие стандарты. Мне кажется, что не исключено, что ко времени выхода HTML 5 как Recommendation будет так, что «разнообразный web-контент все больше выходит за рамки его возможностей».
Про «canvas» — думаю, ввиду развития Flash и Silverlight — у него нет большого будущего. Ибо, скажем, Flash — это уже готовая графическая подсистема, движок, набор инструментов, при этом с хорошими возможностями интеграции, а canvas — это просто «холст», для которого даже графический движок нужно создавать, чтобы им пользоваться.
А вообще забавно, на самом деле, как же долго формируются такие стандарты. Мне кажется, что не исключено, что ко времени выхода HTML 5 как Recommendation будет так, что «разнообразный web-контент все больше выходит за рамки его возможностей».
canvas — это нативный инструмент, который будет легко использовать не покупая/запуская дополнительный софт, изучая дополнительные языки
не спорю, силенок у него меньше, но и цели, вероятно, другие. Для многих небольших задач вполне подойдет. Предсказываю его повсеместное использование.
не спорю, силенок у него меньше, но и цели, вероятно, другие. Для многих небольших задач вполне подойдет. Предсказываю его повсеместное использование.
И чем canvas принципиально лучше существующего SVG?
мне кажется они могут жить вместе и не мешать друг другу
Тем что он уже поддерживается Firefox и Google Chrome в отличии к сожалению от SVG.
Да, принципиальной разницы нет, походу… но с другой стороны, IE клал на SVG и будет класть, т.к. с коммерческой точки зрения стандарт не очень интересен (типа, Silverlight и Flash красифше, а значит нужнее пользователю)… а если эти возможности станут частью стандарта HTML от W3C, то может быть, не будут так игнорировать…
Пожалуй, соглашусь насчет «многих небольших задач».
А насчет того, что реально будет — ничего не остается, чем дожить и посмотреть.
А насчет того, что реально будет — ничего не остается, чем дожить и посмотреть.
вот уже готовые примеры того, на что способен canvas сегодня
www.pixastic.com/lib/
www.pixastic.com/lib/
В XML нет булевских атрибутов, таких как приведённые required и email, так что о XML-валидности говорить не приходится (но пока спецификация в стадии разработки, теоретически можно на что-либо ещё повлиять).
Да, точно. Но по спецификации html 4, насколько я знаю, не нужно закрывающего слэша в элементах типа input, это «фича» xhtml, разве нет?
Думаю, проблема надуманна. На данный момент аттрибут disabled, к примеру, записывается так:
HTML: xHTML: />
HTML: xHTML: />
Кстати, приведенные примеры невалидных «аттрибутов» в статье не имеют место быть. Т.к. на самом деле email это значение атрибута type
dev.w3.org/html5/spec/Overview.html#e-mail-state
Считаю будущий формат будет xhtml, поддержка html будет только в целях совместимости:
For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML (referred to as XHTML5), and one using a custom format inspired by SGML (referred to as HTML5).
dev.w3.org/html5/spec/Overview.html#e-mail-state
Считаю будущий формат будет xhtml, поддержка html будет только в целях совместимости:
For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML (referred to as XHTML5), and one using a custom format inspired by SGML (referred to as HTML5).
ваша ссылка датирована 20 декабря, может быть в ней как раз и обновили механизм этих атрибутов
увы, в предыдущей версии draft описания input я не нашел
увы, в предыдущей версии draft описания input я не нашел
Тогда ваша ссылка на «последню версию HTML 5» (June 2008) не тянет, и актуальность статьи месяцев на шесть устарела.
если дадите мне ссылку на более актуальную статью, то я постараюсь перевести и ее
Я не в коей мере не против хороших переведенных статей! У вас очень хорошо получается.
Просто обсуждение некоторых вещей в комментариях не имеет смысла, за отсутствием объектов обсуждения :)
Приглашаю всех желающих ознакомится с последними правками спецификации по адресу
dev.w3.org/html5/spec/Overview.html
Просто обсуждение некоторых вещей в комментариях не имеет смысла, за отсутствием объектов обсуждения :)
Приглашаю всех желающих ознакомится с последними правками спецификации по адресу
dev.w3.org/html5/spec/Overview.html
Зачем нужен тяжелый, выборочно неотключаемый флеш, если можно просто бросать SVG в канвас и радоваться жизни?
Посмотрите, сколько современных веб-приложений обходится без «флеша» — чтобы не привязывать пользователя к технологии, поддержка которой может отсутствовать на конкретном ПК. Я думаю, будет очень полезна для программ типа GMail или Google Maps, для многочисленных виджетов и прочих веб-приблуд. Ведь наверняка с новым объектом визуальный интерфейс сможет стать быстрее и функциональнее, чем сейчас. Да и проще разработчикам будет — «готовую графическую платформу» знать еще нужно, чтобы на ней сообразить что-то стоящее. Иначе зачем столько времени уделяется проработке этого «бесперспективного» объекта?
Наоборот, канвас скорее будет очень популярным.
Просто из-за того что контент в флеше и силверлайте не индексируется поисковиками. А иметь анимацию хочется.
Просто из-за того что контент в флеше и силверлайте не индексируется поисковиками. А иметь анимацию хочется.
Забавно, что хабрахабр неочень валидный :)
Поэтому он так и работает
Сдаётся мне, W3C отстаёт от реалий всё сильнее… Правят бал основные разработчики браузеров, так что ждём инфы о том, когда они договорятся о вышеуказанных вкусностях, и можно будет применять :)
Просто W3C хочет всех «померить» ;)
Ведь каждый хочет протолкнуть свой стандарт.
Ведь каждый хочет протолкнуть свой стандарт.
Сорри, от слова «мир» :)
Опечатка.
Опечатка.
Ага, и если эти пацифисты не ускорятся, мы продолжим использовать в разработке веб-страниц целый ворох разнообразных и часто взаимозаменяемых технологий…
Согласен, но стандартизация, это как политика.
Человечество тоже долго шло к стандартизации, но придя к ней поняло, что стандарты уберегают много жизней.
Как это относится к web вы скажите.
Отвечу. Разработчик, делающий и соответствующий стандартам (и вся компания) в меньшей степени рискует потерять важные личные данные, которые могут привести к трагедии. Да, да именно к трагедии.
Человечество тоже долго шло к стандартизации, но придя к ней поняло, что стандарты уберегают много жизней.
Как это относится к web вы скажите.
Отвечу. Разработчик, делающий и соответствующий стандартам (и вся компания) в меньшей степени рискует потерять важные личные данные, которые могут привести к трагедии. Да, да именно к трагедии.
Вы упираете на преимущество в безопасности, с этим совершенно согласен. Но это только одна сторона, как насчёт удобства и быстродействия? Здесь стандарты отстают сильно, соблюдать разумный баланс, варьируя пропорции в зависимости от потребности в защите?
Насчет скорости я уже писал
Удобства? :)) Что может быть удобнее стандартов (по собственному опыту) ;)
Просто надо пару раз попробовать верстать по стандартам :) Потом вряд ли захотите по другому
Удобства? :)) Что может быть удобнее стандартов (по собственному опыту) ;)
Просто надо пару раз попробовать верстать по стандартам :) Потом вряд ли захотите по другому
Основные разработчики браузеров входят в W3C и вносят свои предложения в развитие стандартов: www.w3.org/Consortium/Member/List
Ведь даже IE 8 сейчас намного более соответствует стандартам, чем предыдущие версии.
Но создание стандартов всегда идет после появления новых технологий, а поэтому обречено отставать.
Ведь даже IE 8 сейчас намного более соответствует стандартам, чем предыдущие версии.
Но создание стандартов всегда идет после появления новых технологий, а поэтому обречено отставать.
Безусловно, но не настолько же? Число 2012 у многих, думаю, вызвало недоумение :)
С этим полностью согласен :(
Остается надеяться тут только на сознательность разработчиков браузеров. Ведь даже сейчас новыми браузерами поддерживаются некоторые фишки, которые только появятся в будущем в стандартах, но уже есть в Working Draft от W3C. А появление новых браузеров как и война среди существующих нам поможет :)
Остается надеяться тут только на сознательность разработчиков браузеров. Ведь даже сейчас новыми браузерами поддерживаются некоторые фишки, которые только появятся в будущем в стандартах, но уже есть в Working Draft от W3C. А появление новых браузеров как и война среди существующих нам поможет :)
Тэг собирается предоставлять унифицированный доступ к видеопотокам. Однако, в каждом браузере будет свой плеер (со своим интерфейсом), насчет универсальных кодеков тоже будут вестись споры, потом — как насчет работы с видеопотоком из js? Как, например, сделать аналог плеера youtube? Будет ли API и какой он будет мощности? Все мутно и неясно.
Неужто уже можно сделать блок со скруглёнными углами без лишнего геморроя и картинок? =)
Когда они озаботятся инструментом, куда более важным для веб-приложений — интеграцию с веб-службами. Пока что все работает на костылях — аякс-запросы разрешены только к хосту, с которого загружен js файл, к сторонним сервисам приходится соединяться флешем или с помощью костылей на iframe (которые xhtml невалидны, если не изменяет память). А так что-то вида
<service link=«url...» params=«params...»/>
даст нам, скажем, DOM-элемент, к которому можно обратиться через js, но и сам он может что-нибудь показать, если js отключен.
Кстати, в html5 кажется анонсировали постоянное хранилище для фваскрипта. Что то его среди фич нет…
<service link=«url...» params=«params...»/>
даст нам, скажем, DOM-элемент, к которому можно обратиться через js, но и сам он может что-нибудь показать, если js отключен.
Кстати, в html5 кажется анонсировали постоянное хранилище для фваскрипта. Что то его среди фич нет…
XDomainRequest уже реализован, к примеру в ie8b2
он соответствует открытому стандарту W3C Access Control for Cross-Site Requests
www.w3.org/TR/access-control/
DOM Storage тоже реализован в FF c версии 2
https://developer.mozilla.org/En/DOM/Storage
и в IE8b2
msdn.microsoft.com/en-us/library/cc197062(VS.85).aspx
он соответствует открытому стандарту W3C Access Control for Cross-Site Requests
www.w3.org/TR/access-control/
DOM Storage тоже реализован в FF c версии 2
https://developer.mozilla.org/En/DOM/Storage
и в IE8b2
msdn.microsoft.com/en-us/library/cc197062(VS.85).aspx
Лично меня больше всего интересует, что из всего этого html5-богатства планирует хоть как-то поддерживать наша любимая фирма microsoft, в своем лучшем изделии ie!
Первые 4 буквы :)
ИМХО, Майкрософт уже поняли свою ошибку и в последних версиях своего браузера они все больше и больше следуют стандартам.
Майкрософт последние лет пять вообще «лапочки» :-D
Все же поняли.
Просто не было конкуренции. Монополизм — это как анархия.
А меня до сих пор не понимают :) Все мои комменты про стандарты — опустили в минуса.
Просто не было конкуренции. Монополизм — это как анархия.
А меня до сих пор не понимают :) Все мои комменты про стандарты — опустили в минуса.
Согласен с монополизмом :)
Но вот насчет стандартов не совсем. В данный момент стандарты W3C не успевают за развитием Web'a и это плохо, поэтому я полностью согласен с этим утверждением — habrahabr.ru/blogs/webdev/47443/#comment_1218133
Но вот насчет стандартов не совсем. В данный момент стандарты W3C не успевают за развитием Web'a и это плохо, поэтому я полностью согласен с этим утверждением — habrahabr.ru/blogs/webdev/47443/#comment_1218133
Потому у них и проблемы со стандартами, что их не берут на всякие мероприятия W3C. А остальные ржут в кулачок, когда Microsoft выпускает новый IE, а там в тот же день находят несоответствия стандартам. :)
Извините, может не по теме, но статью прочитать не смог из-за огромного числа орфографических и синтаксических ошибок, даже в названии. Перефразируя — статья не проходит валидацию. Правильный русский язык — тоже своего рода стандарт, который, по моему мнению, приоритетнее html5)
вы бы, вместо метафор, привели конкретные ошибки
я их сразу же поправлю
я их сразу же поправлю
ок, пишу в лс
«4. Элемент позволяет изменять изображение налету»
Вот например «на лету», лучше «налету».
Вот например «на лету», лучше «налету».
да не только орфографические:
<p> — это абзац, параграфом в русском языке называют несколько другую сущность, как правило состоящую из нескольких абзацев.
Что касается Rich Internet Applications — надо было самому хоть раз пройти по приведённой ссылке и увидеть русский аналог в Википедии: «Насыщенные Интернет-приложения»
<p> — это абзац, параграфом в русском языке называют несколько другую сущность, как правило состоящую из нескольких абзацев.
Что касается Rich Internet Applications — надо было самому хоть раз пройти по приведённой ссылке и увидеть русский аналог в Википедии: «Насыщенные Интернет-приложения»
Спасибо, отличная статья, очень интересно было читать. Теперь буду ждать с нетерпением HTML5
ждать осталось не долго, ещё лет 10…
Интересно вот что.
1. Если содержимое элемента article более важно, нежели nav и всех прочих, не начнут ли граждане, также известные как поисковые оптимизаторы, пихать все в один этот article, забивая на nav и прочее?
2. Весьма странной выглядит концепция «атрибутов» required и email (как и всех аналогичных атрибутов). По сути, это не атрибуты, это флаги, и куда более логичным смотрелось бы options=«required, email».
3. «contenteditable» вообще странно само по себе.
1. Если содержимое элемента article более важно, нежели nav и всех прочих, не начнут ли граждане, также известные как поисковые оптимизаторы, пихать все в один этот article, забивая на nav и прочее?
2. Весьма странной выглядит концепция «атрибутов» required и email (как и всех аналогичных атрибутов). По сути, это не атрибуты, это флаги, и куда более логичным смотрелось бы options=«required, email».
3. «contenteditable» вообще странно само по себе.
Очень интересно.
Особенно про, при таком раскладе дел, появится возможность создавать инфографику на сайтах. Простенькую, но удобную.
Особенно про, при таком раскладе дел, появится возможность создавать инфографику на сайтах. Простенькую, но удобную.
Впечатление от нововведений неоднозначное. С одной стороны, есть прогрессивные шаги, например, валидация форм или тег video. С другой — введение новых тегов, реальная необходимость которых лично для меня неочевидна.
В первую очередь вызывают недоумение доводы за введение тегов, описывающих функциональную логику документа. Доводы, приведённые автором статьи (не перевода) слишком слабы, чтобы лично я ощутил, что мне их действительно не хватает.
Забота о людях с ограниченными возможностями? Для этого уже есть атрибут media, который позволяет создавать специальные стили для тех же голосовых браузеров. Зачем браузеру знать, что навигация именно здесь? Непонятно, что это даст пользователям. Вырезать рекламу, игнорируя тег aside? Напихают в тег article. Если я использую для создания навигации список UL, зачем мне обрамлять его дополнительным тегом? Явная избыточность, бритвы Оккама нет разработчиков HTML5 :-)
Поисковым ботам такие теги не нужны — они и без них достаточно хорошо справляются, выделяя значимый текст в документе. Невольно вспоминаются метатеги description и keywords, которые предназначались ботам и которыми лет 8-10 назад не пытался злоупотреблять только ленивый. В результате поисковики отказались принимать во внимание их содержимое.
В первую очередь вызывают недоумение доводы за введение тегов, описывающих функциональную логику документа. Доводы, приведённые автором статьи (не перевода) слишком слабы, чтобы лично я ощутил, что мне их действительно не хватает.
Забота о людях с ограниченными возможностями? Для этого уже есть атрибут media, который позволяет создавать специальные стили для тех же голосовых браузеров. Зачем браузеру знать, что навигация именно здесь? Непонятно, что это даст пользователям. Вырезать рекламу, игнорируя тег aside? Напихают в тег article. Если я использую для создания навигации список UL, зачем мне обрамлять его дополнительным тегом? Явная избыточность, бритвы Оккама нет разработчиков HTML5 :-)
Поисковым ботам такие теги не нужны — они и без них достаточно хорошо справляются, выделяя значимый текст в документе. Невольно вспоминаются метатеги description и keywords, которые предназначались ботам и которыми лет 8-10 назад не пытался злоупотреблять только ленивый. В результате поисковики отказались принимать во внимание их содержимое.
по поводу введения тегов: похоже что html двигается от языка верстки к более семантическому языку, в котором уже мало простых элементов верстки которые используются к примеру в типографике: параграф, блок, текст. В этом плане вполне закономерно появление footer, header, article, nav, dialog, mark, progress и прочих.
что это даст? трудно сказать, но хотя бы не нужно будет создавать CSS-классы .header или .footer, а просто использовать стандартные html элементы.
вполне возможно, что браузеры научаться переходить в отображение режима article-only или типа того
однако можно посмотреть на все с другой стороны и сказать, что все это включаю только для того, чтобы хоть что-то включить и налепить цифру 5 :) впрочем, я думаю, через пяток лет после распространения 5 версии вопросов «а оно надо?» уже не возникнет, ненужные элементы отомрут, нужные будут использоваться повсеместно, тогда и посмотрим :)
что это даст? трудно сказать, но хотя бы не нужно будет создавать CSS-классы .header или .footer, а просто использовать стандартные html элементы.
вполне возможно, что браузеры научаться переходить в отображение режима article-only или типа того
однако можно посмотреть на все с другой стороны и сказать, что все это включаю только для того, чтобы хоть что-то включить и налепить цифру 5 :) впрочем, я думаю, через пяток лет после распространения 5 версии вопросов «а оно надо?» уже не возникнет, ненужные элементы отомрут, нужные будут использоваться повсеместно, тогда и посмотрим :)
Вот не соглашусь, что <footer > — семантическая вёрстка. В примерах, кстати, для «copyright information» по семантике больше бы подошёл, почему-то забытый <address>
Колонтитул подразумевает вполне определённое содержание. Традиционный web-footer под определение колонтитула не попадает. <address> я упомянул исключительно в контексте примеров. Какие-нибудь счётчики/информеры в нём размещать нелогично.
Видел немало сайтов, где вся эта «куча инфрмации» не в «подвале», а справа. Я к тому, что предлагаемый тег описывает не определённое содержание, а определённое расположение, что семантикой сложно назвать.
Видел немало сайтов, где вся эта «куча инфрмации» не в «подвале», а справа. Я к тому, что предлагаемый тег описывает не определённое содержание, а определённое расположение, что семантикой сложно назвать.
Лично я не понимаю, чем тег footer лучше div.footer. Какой смысл множить сущности без надобности?
это вопрос метаинформации: нужна она или нет
по мне так, пусть будет, возможно web станет лучше если все сайты будут содержать footer, header и nav
*которые я смогу отключить через adblockplus :)
по мне так, пусть будет, возможно web станет лучше если все сайты будут содержать footer, header и nav
*которые я смогу отключить через adblockplus :)
разве вы не знакомы с извращениями как верстальщики пытаются прикрепить footer к нижнему краю окна. Надеюсь извращениями такого рода не придется больше заниматься при использовании блока footer
Когда я впервые услышал об HTML5 мне эта затея сразу же не понравилась. Почему? Потому что менять надо не язык, а подход. В w3c считают, что они приспосабливают HTML под новые потребности, в то время как надо приспосабливать его под возможность появления новых потребностей в принципе. Как уже сказали выше — HTML5 это частное решение. Почти сразу же его будет недостаточно и люди будут искать workaround-ы.
А делать, с моей точки зрения, нужно следующее:
1. Структура документа — это xml.
2. Свойства xml-элементов и их поведение — это некий гибрид dtd, css и js. Например, можно было бы определить, что элемент <title> внутри элемента <head> имеет свойство display: none а этот же элемент внутри элемента <article> должен быть display: inline и вести себя как ссылка (то есть кликаться и редиректить).
3. Ну и внешний вид по прежнему фигачить через css.
Собрав все три пункта вместе мы получаем уже высокого уровня «парсер» языка разметки. Штука в том, что таких парсеров можно сделать сколько угодно, под любые нужды. И возможно будет несколько самых популярных. Но только при таком раскладе победит не то, что вам навяжут в w3с, а то что будет наиболее востребованно. И ждать нужно будет не 5-10 лет — с описанным подходом ваш HTML5 можно уже хоть сейчас реализовывать.
А делать, с моей точки зрения, нужно следующее:
1. Структура документа — это xml.
2. Свойства xml-элементов и их поведение — это некий гибрид dtd, css и js. Например, можно было бы определить, что элемент <title> внутри элемента <head> имеет свойство display: none а этот же элемент внутри элемента <article> должен быть display: inline и вести себя как ссылка (то есть кликаться и редиректить).
3. Ну и внешний вид по прежнему фигачить через css.
Собрав все три пункта вместе мы получаем уже высокого уровня «парсер» языка разметки. Штука в том, что таких парсеров можно сделать сколько угодно, под любые нужды. И возможно будет несколько самых популярных. Но только при таком раскладе победит не то, что вам навяжут в w3с, а то что будет наиболее востребованно. И ждать нужно будет не 5-10 лет — с описанным подходом ваш HTML5 можно уже хоть сейчас реализовывать.
Не уверен, но вы похоже XHTML 2.0 имеете ввиду? Он основан на тех же глобальных идеях — начать «с чистого листа» и избавить от современный веб от «груза прошлого», т.е. разбить стандарт на несколько слоев, добавить систему модульных расширений стандарта, чтобы в итоге добиться более строгого отделения контента и структуры документа от его представлений.
Это можно сказать классическая проблема «эволюция vs революция», но вся соль в том современный веб — это уже миллиарды страниц сверстанных в классическом html, миллионы людей которые его знают и так или иначе умеют на нем верстать, тысячи программных инструментов для работы с ним и систем которые его используют, сотни сопутствующих или производных технологий и весь этот мир одним махом не изменить. К тому же многие не готовы что либо менять и переучиватся, им и того что есть сейчас хватает с головой.
Имхо XHTML 2 — это долгосрочная стратегия, а HTML 5 — «тактические маневры», чтобы решить сегодняшние насущные потребности и срочно закрыть «дырки», которые текущие стандарты не охватывают. Вся проблема в том, что в этом случае стандарт всегда будет в роли догоняющего — т.е. фиксировать уже сложившиеся реалии. К примеру взять тег video — все уже и так активно используют flash video, и не факт что коммьюнити активно будет пользоваться этой фичой, с учетом факта, что поддержка различными браузерами врядли будет реализована одновременно и с 100% одинаковыми возможностями (например форматы/кодеки/потоковое видео over http и т.п.).
Ссылка в тему XHTML 2 vs. HTML 5.
Это можно сказать классическая проблема «эволюция vs революция», но вся соль в том современный веб — это уже миллиарды страниц сверстанных в классическом html, миллионы людей которые его знают и так или иначе умеют на нем верстать, тысячи программных инструментов для работы с ним и систем которые его используют, сотни сопутствующих или производных технологий и весь этот мир одним махом не изменить. К тому же многие не готовы что либо менять и переучиватся, им и того что есть сейчас хватает с головой.
Имхо XHTML 2 — это долгосрочная стратегия, а HTML 5 — «тактические маневры», чтобы решить сегодняшние насущные потребности и срочно закрыть «дырки», которые текущие стандарты не охватывают. Вся проблема в том, что в этом случае стандарт всегда будет в роли догоняющего — т.е. фиксировать уже сложившиеся реалии. К примеру взять тег video — все уже и так активно используют flash video, и не факт что коммьюнити активно будет пользоваться этой фичой, с учетом факта, что поддержка различными браузерами врядли будет реализована одновременно и с 100% одинаковыми возможностями (например форматы/кодеки/потоковое видео over http и т.п.).
Ссылка в тему XHTML 2 vs. HTML 5.
я вот только непонимаю. если я буду использовать элементы html5 сейчас, то какой мне доктайп указывать? ведь неправильно если браузер будет отображать элементы html5 при доктайпе html4 или xhtml1.x
никакой:
www.w3.org/QA/2008/09/fixing-html-with-html5.html
а, если нужно что бы был ну совсем правильный доктайп при XHTML расширяйте его
enumerate.ru/art/how_to_dtd
например, вот так расширяется xhtml до поддержки элемента embed:
wiki.svg.org/SVG_and_HTML
ну и кстати валидатор уже сейчас валидирует html 5
validator.w3.org/
www.w3.org/QA/2008/09/fixing-html-with-html5.html
а, если нужно что бы был ну совсем правильный доктайп при XHTML расширяйте его
enumerate.ru/art/how_to_dtd
например, вот так расширяется xhtml до поддержки элемента embed:
<!DOCTYPE html PUBLIC "-_W3C_DTD XHTML 1.0 Strict_EN"
"www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" [
<!ELEMENT embed EMPTY>
<!ATTLIST embed
src CDATA #REQUIRED
width CDATA #IMPLIED
height CDATA #IMPLIED>
<!ENTITY % inline
"embed | a | %special; | %fontstyle; | %phrase; | %inline.forms;">]>wiki.svg.org/SVG_and_HTML
ну и кстати валидатор уже сейчас валидирует html 5
validator.w3.org/
браузер не валидатор — да, но всёже с разными доктайпами нужные браузеры по-разному рендерят страницы. тут опять же во мне играет борьба за семантику.
афайк. ие при использовании xml парсера не только смотрит на дтд, но ещё и очень сильно ругается.
мозилла также имеет как минимум рудиментарную поддержку оного (сущности, например, весьма активно используются в её коде).
мозилла также имеет как минимум рудиментарную поддержку оного (сущности, например, весьма активно используются в её коде).
Насчёт новых разметочных элементов: header, nav, article, aside и footer.
Я как-то проводил тест ещё год или два назад (да-да, ещё два года назад всё это было) на возможность использования этих новых элементов в практической вёрстке. Не все браузеры позволяли стилизовать новые элементы, возможно новые элементы не попадали даже в DOM. Так, что, прежде чем использовать это на практике, надо дождаться смерти некоторых версий браузеров. ;)
Я как-то проводил тест ещё год или два назад (да-да, ещё два года назад всё это было) на возможность использования этих новых элементов в практической вёрстке. Не все браузеры позволяли стилизовать новые элементы, возможно новые элементы не попадали даже в DOM. Так, что, прежде чем использовать это на практике, надо дождаться смерти некоторых версий браузеров. ;)
если бы погуглил — нашёл бы воркэраунд. сверху я кидал ссылку, где упомянут он и не только…
вопрос некорректно поставлен
потому что он приемлим
хотя, возможно, вы хотели спросить, почему бы не отказаться от HTML и сделать web полностью XML-валидным. В такой постановке вопроса уже кроется ответ: потому что web невалиден.
На мой взгляд, отсутсвие строгих требований в HTML в итоге пошло на пользу web и способствовало его распространению. Я всеми руками за XHTML strict, но не признать заслуги простого HTML я не могу.
Ждать когда наступит эра валидного web не имеет смысла, по моему это и является той причиной по которой HTML продолджает свое развивитие. И кстати, приносит неплохие плоды: video, canvas, dom storage — это все только на пользу.
потому что он приемлим
хотя, возможно, вы хотели спросить, почему бы не отказаться от HTML и сделать web полностью XML-валидным. В такой постановке вопроса уже кроется ответ: потому что web невалиден.
На мой взгляд, отсутсвие строгих требований в HTML в итоге пошло на пользу web и способствовало его распространению. Я всеми руками за XHTML strict, но не признать заслуги простого HTML я не могу.
Ждать когда наступит эра валидного web не имеет смысла, по моему это и является той причиной по которой HTML продолджает свое развивитие. И кстати, приносит неплохие плоды: video, canvas, dom storage — это все только на пользу.
* минус вам поставил не я
Спасибо за перевод.
Что-то много зелёных кубиков в комментах.
Что-то много зелёных кубиков в комментах.
Куда больше интересного ждет нас в CSS 3 ^_^
не вижу ничего дельного в этом хламе. и простите, а разве теги хэдер, футер и другие не является тем самым представлением которое всё последнее время усердно пытаются засунуть в ксс? чем так плох див с соответсвующим классом?
Ещё раз выскажу мысль о том, что HTML морально устарел ещё в начале века. И появление HTML 5, который как-то совсем не стыкуется с XHTML только увеличивает хаос.
Будущее за браузерами, которые одновременно являются виртуальными машинами.
Будущее за браузерами, которые одновременно являются виртуальными машинами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HTML 5: пять вещей вызывающих особый интерес