Кстати говоря, проверить, работает ли приложение офлайн (через appCache) из js можно через window.navigator.onLine. Удобно, если на основе этого надо по-разному инициализировать модель, к примеру, использовать Backbone.sync для localStorage или для сервера.
Траффик, да, но с другой стороны, можно устраивать потоковое вещание совершенно на любом сайте, где можно ставить гифку. Типа тут, в комментах хабра =)
Как раз недавно думал, без каких языков программирования моя жизнь прошла бы лучше, эффективней. Делфи/паскаль первым пришел на ум — если бы вместо него в универе преподавали сразу Си, Си++, Питон или Эрланг, там, то в голове было бы меньше мусора и больше полезных навыков и привычек. Нет в нем совершенно никаких конкурентных преимуществ.
Отлично, раз мы ударились в цитаты, не будем приводить случайные интерпретации и первые попавшиеся левые источники, а посмотрим в первую инстанцию (откуда, в общем я и взял свое утверждение), где в первом-же абзаце:
This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup.
Из данного описания без особых усердий можно извлечь, что назначение семантики сего стандарта в применении к assistive technologies — т. е. для девайсов и программ, отличных от браузеров, но способных открывать веб-страницы, для людей с ограниченными возможностями.
Впрочем, любой нормальный разработчик и без стандартов знает, что значит accessibility и имеет для себя привычку узнавать смысл аббревиатур.
Мне лень вдаваться в детали о ролях, разнице семантик, требовании HTML5 для ARIA и прочем — ваше незнание очевидно, в стандартах все написано. А судя по тому, что карму вы уже попусту задели, вы не заинтересованы в знаниях/обмене опытом/положительном исходе дискуссии.
Как я и сказал вначале — вы не разобрались в фактах и выставили себя тем, кого же и осуждаете в статье.
Мне тут больше нечего сказать, можно завершить.
Вы спутали теплое с мягким. ARIA — это Acessible RIA, т.е. средства для обогащения сайта разметкой для людей с ограниченными возможностями. Роли в данном случае предназначены для указания назначения элементов в контексте невозможности воспринимать полноценное представление.
К семантике разметки это имеет весьма косвенное назначение.
Простите, но то, что вы не различаете HTML5, SVG или CSS, но уверены в том, что там куча засад, то говорить тут не о чем.
Перетаскивание — правомерный и полезный элемент взаимодействия в GUI, долгое время бывший несправедливо исключенным из веб-стандартов. Ему место там, где и прочим элементам взаимодействия — т. е. в веб-стандарте.
Я реализовывал функционал перетаскивания. Пробовал и jQuery.UI.draggable, расширял и jQuery.UI.mouse, в итоге пришел к своему полноценному велосипеду. Да, у него есть баг по невозможности срабатывания ondragover у дочернего элемента. Вот простейший пример.
По сравнению с написанием js-кода для этих-же целей, нативный drag-n-drop наименее костыльное и наиболее целостное решение.
Если читать документацию, когда делаете это взаимодействие, то сложностей с отладкой не возникает. У меня, по крайней мере, не возникало.
А если бы вы привели пару примеров, в чем HTML5 идиотский, было-бы очень здорово.
Только вам стоит не путать HTML5 и группу CSS3. В частности, браузерные префиксы "-moz-" не относятся к HTML5.
Объективный факт в том, что продвижение стандартов W3C зависит от скорости реализации фич браузерами, см. статусы стандартов, а не от самого W3C. В частности, для продвижения стандарта Candidate Recommendation требуется две независимых неэкспериментальных реализации.
В действительности W3C на годы опережает развитие браузеров, вы можете в этом убедиться сами, посмотрев на список стандартов CSS3, к примеру.
Медлительность, о которой все говорят, связана с нежеланием производителей браузеров развивать и внедрять новые фичи по «сырым» стандартам, что тормозит принятие и развитие этих стандартов. В то время как проприетарные мелочные фичи раздуваются до невероятной важности, в результате приводя к смешным обвинениям W3C в медлительности.
Поэтому однозначно и категорично обвинять W3C в медлительности — значит не разобраться до конца в фактах.
Насчет twitter bootstrap — можно отметить, что на практике это нелогичный, довольно громоздкий и неудобный хипстерский фреймворк, который необходимо изучать каждый раз перед тем, как начать использовать, и предоставляет он лишь и в точности то, что есть в демке, и даже немного менее, а шаг влево или вправо — пиши код, бле*ть.
Только вот насчет W3C вы сами подверглись модной тенденции осуждать его в медлительности, так и не разобравшись в фактах.
Момент в том, что слепок отстает от актуального состояния дел на много месяцев вперед, а не назад, и это задача браузеров — догонять стандарт w3c, это их надо обвинять в тормознутости, а не w3c, как сейчас происходит.
Насчет зол — нужно брать наиболее стабильный и устоявшийся стандарт/технологию, позволяющую решить текущую задачу наиболее правильно. К примеру, делать табличную верстку некорректно, но это лучше, чем поддерживать сырой flex-grid.
В качестве внутренней конвенции для производителей браузеров — согласен. Но в конечном итоге необходима проверка и закрепление всяких новаций серьезным прикладным стандартом, которым можно руководствоваться в разработке.
Повторюсь, больше волнует не то, что какие-то новомодные браузерные фичи не вошли в стандарт,- без них всегда можно обойтись, а то, что уже существующий стандарт полностью не реализован браузерами — это создает более значительные сложности при разработке. Именно это вызывает недоумение от обвинений W3C в медлительности.
window.navigator.onLine. Удобно, если на основе этого надо по-разному инициализировать модель, к примеру, использовать Backbone.sync для localStorage или для сервера.Из данного описания без особых усердий можно извлечь, что назначение семантики сего стандарта в применении к assistive technologies — т. е. для девайсов и программ, отличных от браузеров, но способных открывать веб-страницы, для людей с ограниченными возможностями.
Впрочем, любой нормальный разработчик и без стандартов знает, что значит accessibility и имеет для себя привычку узнавать смысл аббревиатур.
Мне лень вдаваться в детали о ролях, разнице семантик, требовании HTML5 для ARIA и прочем — ваше незнание очевидно, в стандартах все написано. А судя по тому, что карму вы уже попусту задели, вы не заинтересованы в знаниях/обмене опытом/положительном исходе дискуссии.
Как я и сказал вначале — вы не разобрались в фактах и выставили себя тем, кого же и осуждаете в статье.
Мне тут больше нечего сказать, можно завершить.
К семантике разметки это имеет весьма косвенное назначение.
Простите, но то, что вы не различаете HTML5, SVG или CSS, но уверены в том, что там куча засад, то говорить тут не о чем.
Я реализовывал функционал перетаскивания. Пробовал и jQuery.UI.draggable, расширял и jQuery.UI.mouse, в итоге пришел к своему полноценному велосипеду. Да, у него есть баг по невозможности срабатывания ondragover у дочернего элемента. Вот простейший пример.
По сравнению с написанием js-кода для этих-же целей, нативный drag-n-drop наименее костыльное и наиболее целостное решение.
Если читать документацию, когда делаете это взаимодействие, то сложностей с отладкой не возникает. У меня, по крайней мере, не возникало.
Только вам стоит не путать HTML5 и группу CSS3. В частности, браузерные префиксы "-moz-" не относятся к HTML5.
В действительности W3C на годы опережает развитие браузеров, вы можете в этом убедиться сами, посмотрев на список стандартов CSS3, к примеру.
Медлительность, о которой все говорят, связана с нежеланием производителей браузеров развивать и внедрять новые фичи по «сырым» стандартам, что тормозит принятие и развитие этих стандартов. В то время как проприетарные мелочные фичи раздуваются до невероятной важности, в результате приводя к смешным обвинениям W3C в медлительности.
Поэтому однозначно и категорично обвинять W3C в медлительности — значит не разобраться до конца в фактах.
Только вот насчет W3C вы сами подверглись модной тенденции осуждать его в медлительности, так и не разобравшись в фактах.
В целом тогда становится понятна позиция Хиксона.
Насчет зол — нужно брать наиболее стабильный и устоявшийся стандарт/технологию, позволяющую решить текущую задачу наиболее правильно. К примеру, делать табличную верстку некорректно, но это лучше, чем поддерживать сырой flex-grid.
Повторюсь, больше волнует не то, что какие-то новомодные браузерные фичи не вошли в стандарт,- без них всегда можно обойтись, а то, что уже существующий стандарт полностью не реализован браузерами — это создает более значительные сложности при разработке. Именно это вызывает недоумение от обвинений W3C в медлительности.