Тестировать это автоматически сложно, поскольку используя новые семантические элементы Вы вкладываете смысл в свою разметку. Так же как только человек может проверить, является ли предложение осмысленным (и то не всегда — то, что одному покажется осмысленным, другому может показаться полным бредом).
Выше была приведена ссылка на статью о document outline, там в конце есть ссылки на outliner'ы. С их помощью Вы можете посмотреть на схему своего документа и оценить, насколько точно она передает его структуру.
Нет, я как раз про новые теги. Их назначение описывается в спецификации, которую верстальщики редко читают, руководствуясь при верстке только своими собственными соображениями о назначении элементов.
Рассмотрим такой пример:
Профессор X изобрел *чудо-штуку*, приложил к ней инструкцию и раздал бесплатно всем людям. Люди поленились прочитать инструкцию и начали во всю пользоваться этой чудо-штукой, что привело к печальным последствиям. Кто виноват?
В нашем случае, никаких печальных последний, конечно, не произойдет (ну разве что какой-нибудь другой верстальщик приверженец веб-стандартов поругает), но ситуация похожая. Люди получили в свое распоряжение новый стандарт разметки страниц (которым их никто, конечно же, не заставляет пользоваться) и спецификацию к нему, которая описывает, что для каких целей применять (с определенной долей свободы).
Да, увы, я заметил её только после публикации этой статьи (RSS фид обновился только спустя несколько часов).
Если хабрасообщество решит, что эта статья не нужна, я, так и быть, уберу ее в черновики.
Это рекомендации по наполнению Вашей разметки смыслом. Цель всех этих шаманств — более подробно описать документ и его содержимое. В дальнейшем это может быть использовано поисковиками или специальными устройствами для людей с ограниченными способностями, например.
Ваша разметка будет по-прежнему работать, даже если она составлена из одних дивов, но возможность извлечения дополнительной метаинформации будет сильно ограничена.
На мой взгляд, заменять фигуру на иллюстрацию не лучший шаг, т.к.
В <figure> может быть заключено видео, аудио, графики (в SVG, например), цитата, таблица, блок кода, стихотворение или любая комбинация перечисленного.
И если график или видео еще можно посчитать иллюстрацией, то вот аудиозапись или блок кода — вряд ли.
Сегодня в RSS ленте наткнулся на запись о socketstream:
SocketStream is a new full stack web framework built around the Single-page Application paradigm. It embraces websockets, in-memory datastores (Redis), and client-side rendering to provide an ultra-responsive experience that will amaze your users.
В статье мелькает свойство upload xhr объекта, которое, между тем, является полезным при мониторинге прогресса запроса.
Это самое свойство — ссылка на соответствующий экземпляр XMLHttpRequestUpload, которому можно назначить обработчики на следующие события: onloadstart, onprogress, onabort, onerror, onload, ontimeout, onloadend.
Насчет разработчиков согласен.
Людей, действительно хорошо разбирающихся в JS, мало. Отчасти это вызвано тем, что сложные client-side приложения приходится разрабатывать куда реже, чем серверные. Также Дуглас Крокфорд, например, заявляет, что не видел ни одной приличной книги по JS за исключением The Definitive Guide от Дэвида Флэнагана. Ну и в целом отсутствие привычной модели ООП (c классами и интерфейсами) тоже играет свою роль.
В php, JavaScript можно искать function имяФункции — тоже попадете на определение (Правда, в JS возможно еще придется поискать имяФункции: function и имяФункции = function).
А вот в C++ / Java такое уже не пройдет.
Если шрифт моноширинный (а как можно работать с кодом, используя пропорциональные шрифты, я не представляю), то я не вижу причин чему-либо разъехаться.
Вам за это не доплачивают, а платят. Работодатель по-умолчанию желает получить код, который можно будет в дальнейшем поддерживать с минимальными затратами. Если же ему достаточно «чтобы работало и подешевле» — так и скажите ему, что из [«быстро», «дешево», «качественно»] можно выбрать только 2 пункта.
Впрочем, это всего лишь мое мнение, и я не хочу навязывать его Вам. Но на месте потенциального работодателя я бы не стал с Вами связываться.
Потому что Вы пишете код не для себя, не для компилятора, а для людей. Для людей, которые будут в дальнейшем с ним работать. С большой долей вероятности Вы не будете его вечно поддерживать, и когда-нибудь эта обязанность перейдет к другому человеку.
Впрочем, это, конечно, зависит от специфики проекта, но в общем случае одни люди уходят — на их место приходят другие.
Выше была приведена ссылка на статью о document outline, там в конце есть ссылки на outliner'ы. С их помощью Вы можете посмотреть на схему своего документа и оценить, насколько точно она передает его структуру.
Профессор X изобрел *чудо-штуку*, приложил к ней инструкцию и раздал бесплатно всем людям. Люди поленились прочитать инструкцию и начали во всю пользоваться этой чудо-штукой, что привело к печальным последствиям. Кто виноват?
В нашем случае, никаких печальных последний, конечно, не произойдет (ну разве что какой-нибудь другой верстальщик приверженец веб-стандартов поругает), но ситуация похожая. Люди получили в свое распоряжение новый стандарт разметки страниц (которым их никто, конечно же, не заставляет пользоваться) и спецификацию к нему, которая описывает, что для каких целей применять (с определенной долей свободы).
Если хабрасообщество решит, что эта статья не нужна, я, так и быть, уберу ее в черновики.
Ваша разметка будет по-прежнему работать, даже если она составлена из одних дивов, но возможность извлечения дополнительной метаинформации будет сильно ограничена.
Думаю, стоит ознакомиться.
Это самое свойство — ссылка на соответствующий экземпляр XMLHttpRequestUpload, которому можно назначить обработчики на следующие события: onloadstart, onprogress, onabort, onerror, onload, ontimeout, onloadend.
Вот последнее писькомерство и дает.
Людей, действительно хорошо разбирающихся в JS, мало. Отчасти это вызвано тем, что сложные client-side приложения приходится разрабатывать куда реже, чем серверные. Также Дуглас Крокфорд, например, заявляет, что не видел ни одной приличной книги по JS за исключением The Definitive Guide от Дэвида Флэнагана. Ну и в целом отсутствие привычной модели ООП (c классами и интерфейсами) тоже играет свою роль.
JavaScript — Самый недооцененный язык в мире (несколько старовата, но тем не менее)
А вот в C++ / Java такое уже не пройдет.
Впрочем, это всего лишь мое мнение, и я не хочу навязывать его Вам. Но на месте потенциального работодателя я бы не стал с Вами связываться.
Впрочем, это, конечно, зависит от специфики проекта, но в общем случае одни люди уходят — на их место приходят другие.