SelenIT

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

Зато можно представить (и, к сожалению, не так редко увидеть в реальном вебе) несемантичое использование тех же ссылок вместо input type="button" и т.п. (не для связи ресурсов, а для "управления интерактивными функциями"). Как правило, исключительно из-за того, что их стилизовать легче... Ок, достаточно резонно. Конкретно про алфавит: сугубо имхо, у голого алфавита семантики нет никакой, поэтому отображаем как проще. Хоть картинкой (особенно если алфавит какой-нибудь экзотический, типа клингонского ). А алфавитный указатель - всё-таки упорядоченный список (отношение "до/после" значимо для поиска). Возможно, двухуровневый (буква — слова на эту букву).

В теории, можно было бы -webkit-text-stroke'ом попробовать сымитировать. Но я попробовал - с любой толщиной обводки бяка получается (1px слишком жирно, при .3px обводка местами противно отстает от заливки почти на пиксель). Кстати, я не понял, David Hyatt реально считал такое поведение тени не багом, но фичей? ОН УПРЛС? Мне предложение Брэда Кемпера кажется самым логичным. Всё-таки заливка контура текста - это явно foreground, а не back-, чисто по здравому смыслу.

Это одна сторона веба. Но есть и другая, не менее важная — интерфейс веб-приложений (панельки, кнопочки, формы для ввода, переключатели, ползунки и т.п.). Голыми ссылками этого не выразить. А большинство современных страниц представляют собой взрывную смесь из того и другого. Разве это не синонимы? К тому же алфавит редко используется сам по себе (разве что как иллюстрация), обычно он — часть алфавитного указателя. А про календарь, да, холивор давний и ядрёный. Лично я за таблицу

На тему якобы важности возраста в вебе очень хорошо мотивирует вот этот товарищ. Начал «заниматься сайтами» где-то в середине «нулевых» , сейчас ему 67 . А сколько нетривиальных вещей навыдумывал!

Точнее, особенность цифр, имхо.

Для новых браузеров можно попробовать задать размер в единицах vw.

В случае сплошного фона можно и как-то так. А если допустима изящная деградация для IE9-10, то, имхо, это вполне себе кейс для border-image...

CSS-фильтры такое умеют (правда, пока, к сожалению, только в -webkit-виде, со всеми вытекающими). И фильтры в самом SVG.

1. Текст есть, хоть и невидимый — переносы строк между тегами (при display:inline-block они воспринимаются как пробелы между словами). Обнуление размера шрифта у контейнера делает их невидимыми. 2. Это делает ul началом отсчета для псевдоэлементов, рисующих гориз. границы. Их left и right отсчитываются от него. А top, поскольку не задан, считается от границы li (если координата при absolute не указана, элемент помещается по этой координате туда, где он находился бы без absolute). 3, 4. Если задать relative для каждого 4-го li, то началом отсчета для его псевдоэлемента будет не ul, а он сам. И не получится привязать left и right псевдоэлемента к контейнеру.

Грубо говоря, border-spacing — это и есть заменитель margin-ов для ячеек. Если рисовать разделители псевдиками, то всё упирается в достаточное место для обоих отступов и правильное позиционирование самой линии (напр.), если рисовать бордерами, то единственный вариант — играть с padding-ами ячеек. Палка о двух концах. Да, это единственный способ убрать cellspacing через CSS в IE7-. Но это ощутимо меняет логику форматирования таблицы, в частности, ломая возможность задавать ячейкам border-radius и тени. Я бы ставил это не по умолчанию для всего, а строго где нужно (напр. для строгой минималистичной таблицы с однопиксельной сеткой).

Можно нарисовать линии псевдоэлементами каждого 4-го блока (исключая IE8-), наподобие такого (выше предложили почти то же самое ) Чтобы сказать что-то более определенное, желательно уточнить задачу (откуда этот список берется, можно ли разбить его на несколько, добавить классы и т.п.) Так и должно быть. padding — это внутренний отступ (в отличие от margin).

Потому что в новой спеке, возможно (там черт ногу сломит в формулировках, надо разбираться, но по крайней мере судя по Content Model-и table) требование наличия tbody в table (независимо от наличия его в разметке) не безусловно. В HTML 4 (но не в XHTML 1) оно было безусловным, отсутствие TBODY в DOM было однозначным багом реализации. Сейчас — без бутылки не разберешься

Это как? Сверху и снизу от чего до чего? От разделительной линии до соседних строк?

Ух ты, так это, похоже, не старые, а как раз новые! Надо перечитать алгоритм парсинга HTML5 для этого случая. По крайней мере, Content model у table теперь допускает tr без обертки (раньше это только в XHTML было возможно). Получается, да, полагаться больше нельзя (и мой любимый пример превосходства HTML над XHTML протух).

По спеке, влияние relative на внутренние элементы таблиц не определено, и браузеры этим нагло пользуются. Но в Fx и Хроме можно так (пользуясь тем, что неуказанные координаты абсолюта воспринимаются такими, какими были бы при static). Вот IE, бяка, упорно отказывается применять к псевдикам tr-ок display, отличный от table-cell (с table-cell работает). Поэтому для него приходится делать так. Картинка применяется не ко всей tr-ке, а к каждой td-шке отдельно (только в вебкитных, в явное нарушение спеки CSS2.1). Как в примерах выше — подойдет?

Насколько старые? NS4 или что-то поактуальнее?

Это вебкито-блинковая проблема. Да, она всё еще актуальна.

Почему? Поддерживает. Только нужно учитывать, что они появятся либо в дополнительных «виртуальных ячейках», либо сами (при соотв. display) превратятся в такие ячейки — ничего, кроме ячеек, в tr-ках жить не может. border-spacing (padding ячеек в общем-то ни при чем). Навскидку, возможность скопировать в Excel чем-то более удобным, чем сплошная куча текста? В перспективе — еще и нативную сортировку... Что есть, то есть. Но если не гнаться за пиксельперфекционизмом, осуществимо достаточно многое.

Для страницы с типом text/html — насколько мне известно, да. Так же как html и body. Но лучше всё же писать скрипты так, чтобы они не зависели от конкретной структуры вложенности (насколько это возможно).

А уже можно масштабировать и позиционировать цвета? Или эффекты — отдельно от масштабирования картинки, к которой эффект применен?

Ну-ка, ну-ка, а где у нас такое бывает? Уж не в графических ли редакторах, т.е. при создании картинок? И вообще, руки прочь от масштабирования градиентов через background-size, (не)повторения через background-repeat и позиционирования через background-position! Считать градиент особым случаем картинки (прямоугольником, раскрашенным по опред. алгоритму) — удобная и полезная абстракция. А вот полезность введения новой сущности «хитрые операции над цветами», вдобавок к имеющимся цветам и картинкам, как минимум еще нуждается в доказательстве.

Но называть градиент цветом еще более странно В конце концов, если уж называют картиной (даже без уменьшительного суффикса!) вот это: то что помешает назвать картинкой вот это? Тем более CSS-градиенты вчистую портированы из SVG, а SVG — хоть и векторно-декларативные, но всё же явные картинки...

Есть плагин, который по первым набранным цифрам «угадывает» страну и при дальнейшем наборе подставляет маску конкретно для нее (см. предпоследнее поле на демо-странице). Возможно, для среднего сайта и оверкилл, конечно...

С точки зрения спецификации — картинка. И, по логике, его можно использовать в любых свойствах, понимающих тип значения image (напр. background-image, border-image или list-style-image). Но не тип color (background-color: linear-gradient... не работает и не должен).