Неделю назад, мой друг и коллега Джелу спросил меня, как я отношусь к разметке Schema.org и правильно ли в целях продвижения использовать разметку для картинок которую предлагает яндекс в разделе справки — «Schema.org для Яндекс. Картинок».
Я до этого не обращала внимания что там нового у яндекса, а оказалось новый формат разметки они уже с ноября прошлого (2011) года поддерживают. А ввели его Google, Microsoft и Yahoo аж в июне. Что ж, обычные микроформаты сказала я, глянув один раз на пример. Глянув на пример второй раз я заметила что микроформаты как раз необычные. И более того, используют кажущуюся невалидной с точки зрения html разметку. Об этом я и хочу сегодня рассказать, надеюсь статья будет интересной.
Сегодня, мой друг и коллега Cavin прислал мне ссылку на статью с хабра — «Браузеры запутались в блочной модели для таблиц». Я считаю, что эта статья в полной степени показывает мои мысли о том, что в россии специалистов любого профиля очень мало.
Некий царь призвал трёх мудрецов и попросил объяснить следующий факт: «почему, если в кувшин, доверху наполненный водой, опустить рыбу, вода не выливается».
Двое мудрецов представили подробнейшее обоснование. Третий опустил в кувшин рыбу. И вода вылилась.
С наступающим, дорогие друзья!
Я так и не нашла силы побороть лень и дописать таки статью о вариантах комментариях, которую пишу уже месяца четыре. Думаю ничего страшного если она полежит у меня в запасниках ещё немного.
Сама статья бесспорно хорошая, в ней говорится вообще о том как писать быстрый код, почему селектор потомков медленный, почему селектор родителя был бы ещё медленнее, однако не говорится почему собственно есть хоть одна причина такой селектор не сделать. Да, это будет медленно. Да, всем понятно что селектор по id самый быстрый. Но в любом случае мы говорим о миллисекундах машинного времени. Обычно этим можно принебречь если сайт нагружен картинками и потоковым видео.
Собственно я бы не стала об этом писать если бы не прочитала ещё в сентябре черновик селекторов четвёртого уровня. Т. е. то, что мы будем называть CSS4.
Ссылка: http://www.w3.org/TR/2011/WD-selectors4-20110929/#overview
В самом низу указан родительский селектор: $E > F , который выбирает элемент E, родитель элемента F.
Кроме селектора родителя, конечно добавилось много других новых, клёвых селекторов, которые отнимут у Джонатана Снука ещё лишние секунды жизни.
Заключение
Безусловно, в тех проектах, в которых важна скорость работы в браузере — нет места подобным селекторам. Пример: проект, который я сейчас разрабатываю, расчитан на использования только в современных браузерах полностью исключая IE6-8, и возможно IE9 из-за их низкой скорости работы с dom; и тем не менее, в оформлении используются только селекторы id и класса; в яваскриптовом коде большинство селекторов заменены с jquery на нативные и т. п.
Т. е. каждый разработчик обязан представлять себе где и сколько времени отнимает выполнение его кода(css, js, html). Но при этом инструменты для того чтобы сделать«быстро и сразу» должны быть. Например на главной странице моего блога, менее 400 элементов в DOM, использование тормозящего селектора в данном случае вообще не будет заметно.
Сегодня мы прикрутили к блогу поиск. Сам модуль поиска в движке был, но он искал только в обычных страницах и каталоге, а по новостям не искал. Сейчас ищет - это здорово. Адрес http://usabili.ru/search/news/. Будем считать это подарком бложику на двухлетие.
А теперь собственно обещанная вам 23 февраля статья.
Сейчас я поведаю вам о технологии Opensearch, с которой я играюсь уже неделю. Эта технология позволяет для любого сайта содержащего поиск, интегрироваться в панель поиска браузера. Особенность также в том, что поиск можно не только интегрировать как саму форму, но и обозначить страницу с которой можно загружать поисковые подсказки (suggestions). Например в Firefox это выглядит так:
Здравствуйте дорогие читатели моего бложика, надеюсь среди вас есть css-профессионалы, поскольку у меня есть любопытная задача. Я обнаружила следующую реализацию свойства opacity в современных браузерах:
http://usabili.ru/labs/css_opacity_bug.html — посмотрите эту страницу, на ней видно что у абсолютно позиционированного элемента внутри с прозрачностью, не работает z-index относительно другого элемента с прозрачностью. Т. е. он оказывается под ним, и соответственно красная ссылка в нём не доступна для клика. Красная ссылка в этом примере обрабатывается так как будто имеет z-index:0 или даже меньше, хотя это не так. Причём, при убирании свойства opacity у любого из элементов, или при перемещении элемента со ссылкой из прозрачного — ссылка становится рабочей.
Всё что говорится по этому поводу в спецификации css3: «If an element with opacity less than 1 is positioned, the ‘z-index’ property applies as described in [CSS21], except that ‘auto’ is treated as ‘0’ since a new stacking context is always created. See section 9.9 and Appendix E of [CSS21] for more information on stacking contexts». В упомянутых выше ссылках я не смогла найти точного ответа. Чтобы разобраться я отправила письма Яну Хигсону (hixie), который рекомендовал задать вопрос в лист рассылки www-style@w3.org, и Дэвиду Арону (dbaron), который ответил в топике багзиллы.
Ниже я публикую ответ этой загадки (пока в непереведённом виде):
Май месяц выдался напряженным, многое сделано, а многое нет, причин почему я не писала в бложик называть не буду, придумайте их сами =). Но материалов как всегда у меня накопилось предостаточно, и, как обычно первым делом я пишу о том что сейчас актуально моим друзьям и коллегам.
В частности, полезным может оказаться один способ избавиться от дублированного контента в поисковой выдаче. Не секрет, что часто одна и та же страница оказывается проиндексирована под разными url, для того чтобы этого избежать можно использовать тег link, с атрибутом rel="canonical". Использование rel="canonical" — является более удобной альтернативой редиректам, с точки зрения поисковой оптимизации, к сожалению яндекс пока не поддерживает этот тег, но надеюсь будет понимать в скором будущем. Располагать его следует вместе с остальными в <head>, например примерно такой результат вы можете видеть если посмотрите в код текущей страницы:
Замечу, что курсивом в примере я выделила канонический урл этой страницы. Каноническим, называют url не какого-то чёткого вида, а того вида который вебмастер установил сам для себя. Важно придерживаться выбранному стилю во всём сайте. В этой статье я хочу вкратце рассказать какой канонический урл предпочитаю я, какой принят у нас в студии, и почему.
Восьмого апреля компании Мозилла, Опера и Майкрософт подали на рассмотрение в W3C спецификацию формата файла "WOFF File Format 1.0". Заявка была опубликована 19 апреля http://www.w3.org/Submission/2010/03/.
Производители браузеров и растущее количество производителей шрифтов договорились на общий формат веб-шрифтов, который завершит эру кроссбраузерной несовместимости, начавшуюся когда IE4 и Netscape 4 впервые добавили поддержку загружаемых шрифтов в 1997.
В то время, и Microsoft и Netscape разработали несовместимые друг с другом решения. Netscape поддерживал, (и в последствии отказался) формат Bitstream’s Portable Font Resource (PFR). Интернет эксплорер использовал формат Embedded Open Type (EOT).
Десять лет спустя, Apple добавила в WebKit и Safari возможность подключения сырых шрифтов, т.е. TrueType или OpenType. Firefox и Opera последовали примеру, но использование было на практике ограничено бесплатными шрифтами и специальными сервисами обфускации типа Typekit, так как производители шрифтов категорически против того, чтобы позволять их интеллектуальная собственность была размещена "как есть" на страницах. Обычно большой размер файлов и различия связанные с поддержкой HTTP компрессии у разных пользователей добавили практических проблем.
В марте 2008, Microsoft подала заявку на стандартизацию EOT в W3C. Несмотря на большое количество существующих установленных EOT-совместимых IE, большое количество разногласий помешали формату Microsoft стать стандартом шрифта для веба.
Летом прошлого года, усилиями дизайнеров Тала Леминга (Tal Leming) и Эрика ван Блокланда (Erik van Blokland), и представителя Мозиллы Джонатана Кью (Jonathan Kew), появился WOFF - открытый формат сетевого шрифта, уже содержащий в себе компрессию. Если сравнивать формат с обычным сжатым в gzip форматом TTF или OTF, новый формат не сильно отличается, однако я думаю, что изначально сжатый формат будет очень полезен тем, кто ещё не научился настраивать gzip на сайте.
Напомню что начиная с версии 3.6 файрфокс понимает этот формат, и рекомендует его для использования. В опере и эксплорере данная поддержка появится в будущих версиях.
Также файл может содержать в себе метаданные в формате XML, полезные чтобы получше узнать что это за шрифт и откуда.
Целый месяц не писала, но сегодня спешу вас порадовать товарищи, т.к. знакомый многим Эрик Мейэр (http://meyerweb.com/eric/), редактор CSS3, добавил в спецификацию CSS3, предложенные специалистами (IE-team) из майкрософт, новые атрибуты. Эти атрибуты уже долгое время используются в браузере Internet Explorer, сами разработчики рассматривают их как дополнение к CSS2.1. Вот краткий список этих атрибутов по группам.
-ms-interpolation-mode (надо сказать, что в других браузерах этот атрибут всегда принимает значение bicubic, равно как и в блоках со значением zoom: 100%;)
Сегодня, дабы провести экскурс среди коллег я бы хотела рассказать о том для чего нужен SSL, как он работает и какие типы SSL-сертификатов бывают.
Для чего нужен SSL
Итак, ни для кого не секрет что существуют злые, хитрые хакеры которые могут перехватить траффик вашего компьютера. От компьютера до веб-сервера траффик проходит через множество узлов многие из которых могут оказаться незащищёнными к "прослушке". В результате если вы предоставляете какому-то сайту личную информацию, от девичьей фамилии мужа или секретного рецепта пиццы, до мелочей вроде кредитной карты, то эта информация может попасть в третьи руки. Для того чтобы этого избежать информация шифруется, и такое соединение называется "безопасным" (secure - последняя буква в https://).
В общем хотела бы затронуть сегодня эту важную техническую особенность. Потому что когда спам попадает во «Входящие», это нормально, а вот когда важное письмо оказывается в спаме - это очень плохо, и сегодня я расскажу как этого избежать. А то так получается что из вебмастеров до сих пор никто не в курсе-то.
Сначала разберёмся, что такое спам и с каких адресов он может идти? Тут всё просто, почтовый ящик указываемый в заголовке From может отправителю:
принадлежать
не принадлежать
Вариант, когда почтовый ящик действительно принадлежит отправителю — тривиален, это тот случай когда ящик вида blabla12ac3hd@mail.ru реально зарегистрирован спамером. Т.е. после добавления письма от него в спам несколькими пользователями крупного сервиса (например gmail или яндекс) система заносит этот адрес в чёрный список и спамер вынужден регистрировать следующий ящик, а это требует распознавания капчи, что в автоматическом режиме стоит денешек.
Вариант второй, когда почтовый ящик не принадлежит отправителю — сложнее, допустим вы получили письмо от bill_gates@microsoft.com, а там реклама виагры, или предложение увеличить место на диске. Как отнестись к такому письму? Подумать что не только честными путями зарабатывает деньги известный миллиардер? Вовсе нет. Дело в том что отправитель письма может программными методами поменять почти все заголовки (поля) письма. И подписаться Билом Гейтсом или ещё кем-либо. В общем отправитель может менять всё кроме одного — записи о том кто прислал письмо. Например:
Received: from [10.33.1.79] (HELO Wizard)
by mail.ultranet.ru (CommuniGate Pro SMTP 4.3.8)
with SMTP id 153931800 for askme@usabili.ru; Thu, 01 Oct 2009 13:48:41 +0400
В процессе пересылки (роутинга) письма через различные серверы заголовки Received накапливаются, и письмо содержит информацию о всём пути следования. Например приведённый выше пример говорит о том что в какой-то момент письмо было получено сервером mail.ultranet.ru, от сервера с ip адресом 10.33.1.79. Это внутренний ip адрес, что скорее всего говорит об отправке через веб-интерфейс.
Возникает естественное желание - принимать почту только с ящиков принадлежащих отправителю. Для того чтобы определить действительно ли отправителю (его IP) принадлежит право отправлять почту от лица этого email, умные люди 4 года назад придумали механизм SPF, который с апреля 2006 года официально включён в состав описания SMTP.
