SelenIT

Насколько я понял, canvas там используется для графики как таковой, а map — для создания интерактивных областей сложной формы. Вот здесь нечто подобное, но без библиотек и с достаточно подробным пошаговым разъяснением.

Была прикольная страничка с наглядным сравнением полусотни скриптов такого типа, сейчас у меня сайт почему-то не открывается, но кэш Гугла помнит всё.

Как раз в новом jQuery есть delay().

Логично. Спасибо за еще одно возможное применение префикса!

1) Чем мотивирован именно такой нейминг? 2) То, что первая ф-ция с дефолтным ALength=10 в тестдрайве дает 9, а не 10 октоторпов — баг или фича? (FF 3.6.11, WinXP) Дальше не смотрел, сорри.

Чтобы не налезало, в CSS вообще ничего писать не надо. А вот что такое можно было написать, чтоб оно налезло... советую проверить position и margin-ы.

В IE вместо opacity работает filter:alpha. Не без издержек.

Спасибо за подсказки! Действительно, хотя на страничке "Introduction to Filters..." написано, что на страничке самого свойства -ms-filter однозначно написано, что оно всего лишь Получается, в реальной жизни префикс и впрямь лишний, а что там было в бетах, представляет лишь исторический интерес. Вопрос решен, спасибо!P.S. Попутно узнал для себя еще одну занятную вещь... Получается, "новомодные" фильтры с progid: вообще не нужны — мало того, что писать больше, еще и размеры распирают, добавляя неразберихи...

Точно помню, что какая-то бета IE8 отказывалась понимать старый синтаксис фильтров (нарушающий нормы CSS), приходилось дублировать их -ms-filter:"тем же самым". Сейчас с удивлением вижу, что на моей машине IE8 прекрасно понимает и добрый старый невалидный синтаксис. Это мой IE8 глючит или его вообще тихо пофиксили и -ms-наворот теперь остался не у дел?

Можно с его line-height поиграть (если текст заведомо однострочный). Или задать ему display:inline-block + паддинги. А нельзя в этой же динамической выдавалке делать проверку содержимого и добавлять еще один класс впридачу?

Еще: нет доктайпа, а без него любой IE превращается в тыкву IE5.5. Таблицу нельзя вкладывать в <p>, браузеры могут интерпретировать это по-разному. <br>-ки не предназначены для создания отступов, для этого есть margin/padding. Ну и мелочь, но полезная на будущее — надо приучаться писать CSS в едином стиле (регистр и пр.), лучше в нижнем регистре и с использованием сокращенных записей — самому будет проще ориентироваться...

Я не согласен. Вещь действительно удобная, а в новых браузерах для нее предусмотрен целый нативный метод. Аргумент — строка, в строке может быть почти что угодно. Подозреваю, что проблемы в IE как раз с id-ами — именно из-за неявного создания глобалок (сам не сталкивался, т.к. дефисами в id не пользуюсь)...

Если ориентироваться на статус рекомендации, то и CSS2.1 пока не дано (она еще только кандидат). Если кандидаты рассматривать, то даны еще и CSS Color, Media Queries, CSS Multi-column Layout, Selectors Level 3, CSS Marquee, CSS Namespaces, CSS3 Basic User Interface и CSS3 Ruby — у всего этого добра (хоть оно и CSS3) степень готовности как минимум не ниже, чем у CSS2.1. Transitional-доктайпы лично я не рекомендую, с ними бывают непредсказуемости в отображении (напр., inline-block странно ведет себя в IE8 и Опере). Сугубо имхо, уж лучше не совсем валидный Strict (с пояснением каждой невалидности в проектной документации), но стабильный и предсказуемый в браузерах (свойство transitional-доктайпов включать "полустандартный" режим в браузерах закреплено стандартом HTML5, поэтому это, увы, уже не исправится). Но каждый вправе выбирать себе грабли по собственному вкусу Увы, есть. С точки зрения валидатора — Strict запрещает теги и атрибуты, признанные в 1998-2000 годах "устаревшими" (iframe, target для a, start для ol и т.п.) и требует явного блочного контейнера для любого текста, Transitional многие из них разрешает и допускает "голый" текст в body и form. С точки зрения браузера — при Strict-доктайпе включается самый строгий режим отображения, на который браузер способен, при Transitional — "полустрогий" (главное отличие в поведении картинок в ячейках таблиц, но на практике, случается, вылезают сюрпризы и в других местах). С доктайпом HTML5 (<!doctype html>) и режим строгий, и полезные теги разрешены (как правило), но нужно постоянно следить за изменениями самой спеки и уровня поддержки ее браузерами.

Про метод хорошо написано здесь. Сервис — первое, что нагуглилось по запросу "data url generator", сказать о нем пока могу только "кажется, работает"

В IE6 не будет растягивать через bottom:0, top:0, expression нужен... Я имел в виду что-то вроде такого варианта: <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Test</title> <style> div { position: absolute; top: 5px; left: 40px; width: 200px; height: 150px; background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAAGXRFWHRTb2Z0d2FyZQBBZ G9iZSBJbWFnZVJlYWR5ccllPAAAABtJREFUeNpiZFjF0MBABGBiIBKMKqSOQoAAAwDrnQE+oqKVVwAAA B JRU5ErkJggg==); /* это png-картинка с заливкой цвета #00aa00 и прозрачностью 50%, которую прогнали через http://www.sveinbjorn.org/cgi-bin/dataurlmaker-cgi.pl */ /* только переносы не нужны, это форум добавил */ /* должно работать во всём новее Оперы 7.2 */ } </style> <!--[if lte IE 7]> <style> div { background: transparent; /* тут картинка не нужна, зато есть градиенты */ filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#8000aa00', endColorstr='#8000aa00'); } </style> <![endif]--> </head> <body> <p>Просто текст, обычный текст</p> <div> <p>Текстик на полупрозрачном фончике</p> </div> </body> </html>

По всем, которые имеют статус Candidate Recommendation и выше. Те, у которых статус Group Note — в игнор, это трупы. Сомнителен в плане рациональности (в 99% парсится не по тем правилам, по которым валидируется, весь раздел про HTML-совместимость приходится помнить наизусть и постоянно держать в уме). Я бы рекомендовал начинать с HTML 4.01 Strict, соблюдая хороший стиль (закрытые теги, закавыченные атрибуты и т.п.). Самый практичный, как ни парадоксально, HTML5, но с ним тоже нужно много держать в уме — что уже поддерживается, а что нет...

Им придется жить без прозрачности. К счастью, их по статистике остались считанные проценты (в основном 9-я Опера). Только IE. Градиент, потому что только он (судя по всему) понимает RGBA-нотацию де-факто.Как мегакроссбраузерный вариант — для IE Светин градиент, для остальных png-картинка

Это частный случай синтаксиса. Внутри абзаца не может быть блочностей, в т.ч. заголовков. HTML-браузеры, встретив открывающий блочный тег, попросту неявно закрывают абзац перед ним.

Есть в IE такая неприятная особенность. Для каждого ID создается незатираемая глобальная переменная, ссылающаяся на этот элемент. По ней можно обратиться к элементу без всяких getElementById и document.all, но именовать переменные (в т.ч. функции) приходится с оглядкой на это. IE8 вроде от этой беды вылечили, но в обоих его режимах совместимости бывают рецидивы. Еще те же IE любят путать ID и name (getElementById может вернуть элемент по любому из них). Верная страховка - по возможности избегать name вообще, а для элементов форм делать id и name одинаковыми (кроме радиокнопок, где это не получается).

Насколько я понял, имелось в виду, что нет такого волшебного доктайпа, с которым старые браузеры сразу начнут поддерживать новые теги, canvas api, web storage, новые типы инпутов и прочие вкусности будущего стандарта. Независимо от доктайпа браузеры понимают только то, что понимают, чтобы научить их чему-то большему, нужны скриптовые подпорки типа modernizr-а. Но с HTML5-доктайпом многие уже работающие вещи типа <input autocomplete> и собственных data-атрибутов можно смело использовать как валидные.

По логике не должны реагировать, они же индексируют не теги, а текст. Но навскидку есть опасения, что злоупотребление тегами выделения (те же <b>) может понизить вес настоящих выделений в тексте. Поэтому семантически нейтральные <div> и <span> интуитивно как-то безопаснее . Как на самом деле — сорри, не владею информацией, надо по специализированным SEO-форумам порыться...

Это полная чушь, так же, как и то, что "тег <script> запрещен", в чем легко убедиться за 5-10 сек., проверив соотв. кусок кода с галкой "validate document fragment". Другое дело, что FF-овское расширение HTML-validator (в своём дефолтном режиме, основанном на tidy, а не том, который на настоящем W3C-шном парсере c DTD-проверятором) любит смущать народ warning-ами типа "dropping empty <span>". Разницы, какое ничего использовать, имхо нет. Совсем уж пуристы могут сказать, что лучше <span> и <div> для внутритекстовых и блочных пустышек соотв-но — как семантически "стерильные". Иногда попадается аргументация за эл-ты <ins> (типа, "мы тут что-то добавили") и <del> ("это мы на самом деле удалили, оно не считается"), но имхо она притянута за уши. Сам раньше юзал <b> и <i> — и писать меньше, и они изначально оформительские, но в связи с их переопределением в HTML5 советовать такое не берусь Лично я всё-таки стараюсь сводить "оформлятскую" разметку к минимуму, где можно заменять псевдоэл-тами, то, что используется для скриптов, генерить самими же скриптами и т.п. (не всегда получается, конечно)...

Согласен, именно с ним и попутал . Но всё равно, вместо текста (понимающего текстовые стили) там получается графический объект. С @font-face еще, может быть, прошло бы...

Разве cufon понимает font-weight со товарищи? Он же, если я ничего не путаю, напрочь заменяет текст флешем... Имхо, если нужна полная попиксельная кроссбраузерность, то пока никак без замены заголовков картинками...

Для таких случаев у валидатора есть опция "Validate document fragment" Логично, там же php-вставки... Чисто формально можно добиться валидности, обернув код скрипта в CDATA-секцию. Но сугубо имхо это героическое пробивание лбом стены в метре от открытой двери: я почти уверен, что эта страница не будет отдаваться с XML-ным типом контента, а с обычным типом контента браузерам глубоко без разницы, XHTML там или обычный HTML. Смена доктайпа на <!DOCTYPE HTML> решила бы проблему куда быстрее и радикальнее. Но навязывать не стану