Поддерживаю. Да, и предложение сделать что-то с отображением листингов — тоже. Блог Webdev уже появился, так что подсветка кода — вполне насущный вопрос :-).
Opera Software ASA держит генеральную линию. Открытый сайт вполне соответствует духу движения «Open the Web», поддерживаемого Opera т.к. призван помочь разработчикам делать их работу более профессионально (упор на кроссбраузерность и соблюдение вебстандартов).
Как вы уже наверное знаете, одной из главных новинок FF2 стала возможность осуществлять проверку орфографии при наборе сообщений в веб-формах.
Стоило ли вообще огород городить? Эту «фичу» едва ли можно назвать такой уж необходимой. Вместо добавления новых функциональных возможнстей не лучше ли было довести до ума имеющиеся?
Строго говоря, это как раз знакомый и понятный браузерам код, в настоящее время имеющий мало кому понятный дополнительный смысл :-). Mozilla Firefox, а так же Flock уже понимают, но при наличии соответствующего расширения.
Технология сейчас как раз на том этапе, когда рост контента опережает рост возможностей обработать этот контент программными средствами. Поживём — увидим, что из всего этого выйдет.
Но предпочел бы иметь файлы в другом формате, со ссылками на них их файлов XHTML.
Это и сейчас можно делать, как вы понимаете. Всё-таки это немного другая опера.
Или как в XML - рассматривать их как внедренный объект чужого неизвестного формата.
Ахиллесова пята — неизвестный формат. Теряется предсказуемость и единообразие. Микроформаты тем и хороши, что они «известно что». Да и городить ли для решения микрозадачи какой-то особый формат, когда можно обойтись миниатюрным решением — микроформатом?
Вообще, если не трудно, поясните вашу позицию чуть подробнее — очень интересно.
Вдогонку хотел бы ещё добавить, что сама разметка внутри микроформата стремится быть максимально точной с точки зрения спецификации XHTML, т.е. максимально использовать описательные возможности элементов языка в рамках этих же элементов. Не вводятся новые элементы и пространства имён, как следствие — современный парк браузеров работает с таким кодом как XHTML-кодом, знакомым и понятным.
Так это не другой формат, в том-то всё и дело! :-)
Вы понимаете под «уже форматированным файлом» обычный (X)HTML документ, я полагаю? Если да, то внутри него микроформат не будет чем-то инородным. Микроформаты — своего рода особые правила семантического описания информации посредсвтом имеющихся в XHTML элементов и атрибутов (типа class, rel). Т.е. обычный поток XHTML кода содержит в себе участок такого же кода, имеющий только один отличительный признак от соседних (назовём их служебными) тегов и атрибутов — он несёт внутри себя ещё информацию об информации. Которая, в свою очередь, не привносит в код чего-то такого, чего нет в спецификации Консорциума W3C.
Теперь давайте вспомним старую затею с XML, как языком разметки всего и вся: одна из концепций его использования в Сети в своё время была очень популярна — многие полагали, что в будущем (примерно вот сегодня, сейчас) можно будет напрямую кормить браузеру свой XML код, элементы которого написаны под какие-то конкретные задачи описания информации. Однако так ничего и не вышло. XML живёт и здравствует, но в другой ипостаси. А потребность осталась.
Микроформаты — попытка решить старую задачу новыми методами и имеющимся инструментарием минуя «проблему Вавилонской башни» (тот гипотетический случай, когда клиенты перестали бы понимать свалившиеся на них мегатонны пользовательских XML элементов).
Хочу добавить ещё вот что: в авторитетных западных сетевых изданиях и блогах, специализирующихся на вёрстке, уже давно витает идея о необходимости унифицирования наиболее ходовых наименований для идентификаторов (id), классов (class) и т.п. — всего того, с чем приходится иметь дело верстальщикам. Микроформаты косвенно обязаны своим появлением ещё и этому стремлению. Стремление к порядку.
Контент, размеченный унифицированным образом, отлично вписывается в концепцию новомодных социальных сервисов — его удобно гонять между разными сайтами (формат представления один и тот же, все участники обмена поймут) и т.п. Да и в целом порядка поболе будет.
Внедрение микроформатов уже началось в Сети (достаточно вспомнить сервисы Yahoo!), плюс, многие CMS и даже Dreamweaver уже могут создавать микроформатированный контент (некоторый софт требует плагины). Почему бы и Рунету не включиться в это движение?
Ну, в данном случае они поступили весьма гуманно. А семёрка ещё на шаг-другой приблизилась к некоему единообразию в обработке кода страниц. Чуть больше порядка, пусть и ценою в 6 лет.
P.S. Где-то я уже этот текст читал.
Стоило ли вообще огород городить? Эту «фичу» едва ли можно назвать такой уж необходимой. Вместо добавления новых функциональных возможнстей не лучше ли было довести до ума имеющиеся?
Помимо Opera этот тест проходит как минимум Safari.
Фоксоводам: без стрельбы — люблю и уважаю и O и FF, но пользуюсь всё же O. :-)
Весьма странное утвреждение.
Технология сейчас как раз на том этапе, когда рост контента опережает рост возможностей обработать этот контент программными средствами. Поживём — увидим, что из всего этого выйдет.
P.S. Спасибо за комментарии. Было интересно.
Это и сейчас можно делать, как вы понимаете. Всё-таки это немного другая опера.
Или как в XML - рассматривать их как внедренный объект чужого неизвестного формата.
Ахиллесова пята — неизвестный формат. Теряется предсказуемость и единообразие. Микроформаты тем и хороши, что они «известно что». Да и городить ли для решения микрозадачи какой-то особый формат, когда можно обойтись миниатюрным решением — микроформатом?
Вообще, если не трудно, поясните вашу позицию чуть подробнее — очень интересно.
С другой стороны уже сейчас технически возможно обрабатывать микроформатированный контент (живая масса которого в Сети неуклонно растёт) так, как это нужно людям: «information in them can be extracted by software and indexed, searched for, saved, cross-referenced or combined.».
Вы понимаете под «уже форматированным файлом» обычный (X)HTML документ, я полагаю? Если да, то внутри него микроформат не будет чем-то инородным. Микроформаты — своего рода особые правила семантического описания информации посредсвтом имеющихся в XHTML элементов и атрибутов (типа class, rel). Т.е. обычный поток XHTML кода содержит в себе участок такого же кода, имеющий только один отличительный признак от соседних (назовём их служебными) тегов и атрибутов — он несёт внутри себя ещё информацию об информации. Которая, в свою очередь, не привносит в код чего-то такого, чего нет в спецификации Консорциума W3C.
Теперь давайте вспомним старую затею с XML, как языком разметки всего и вся: одна из концепций его использования в Сети в своё время была очень популярна — многие полагали, что в будущем (примерно вот сегодня, сейчас) можно будет напрямую кормить браузеру свой XML код, элементы которого написаны под какие-то конкретные задачи описания информации. Однако так ничего и не вышло. XML живёт и здравствует, но в другой ипостаси. А потребность осталась.
Микроформаты — попытка решить старую задачу новыми методами и имеющимся инструментарием минуя «проблему Вавилонской башни» (тот гипотетический случай, когда клиенты перестали бы понимать свалившиеся на них мегатонны пользовательских XML элементов).
Хочу добавить ещё вот что: в авторитетных западных сетевых изданиях и блогах, специализирующихся на вёрстке, уже давно витает идея о необходимости унифицирования наиболее ходовых наименований для идентификаторов (id), классов (class) и т.п. — всего того, с чем приходится иметь дело верстальщикам. Микроформаты косвенно обязаны своим появлением ещё и этому стремлению. Стремление к порядку.
Внедрение микроформатов уже началось в Сети (достаточно вспомнить сервисы Yahoo!), плюс, многие CMS и даже Dreamweaver уже могут создавать микроформатированный контент (некоторый софт требует плагины). Почему бы и Рунету не включиться в это движение?