SelenIT
Expert-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Не уверен, сейчас пробежался по истории CSS3 Selectors — ограничение простым селектором там было с самого начала. По логике, :not(x,y) — лишь «сахарок» для :not(x):not(y), так что ограничение легко обходится и роялит лишь при борьбе за каждый байт, как в css1k.com (при экспериментах с которым я тот глюк и поймал ☺). Ну и, да, расхождение между jQuery и чистым CSS запутывает.
-
Потому что отступы строчных элементов не схлопываются. Элементы p, h1, div и т.п. — блочные (а вообще схлопывание бывает у любых элементов с display:block, кроме особых случаев, оговоренных в спецификации). Зачем так сделано — см. здесь после «отчего так».
-
Я сам удивился, до этого вопроса не задумывался о таких нюансах Кстати, году в 2011-м у меня был глюк, что в какой-то из актуальных тогда Опер внезапно сработал селектор наподобие :not(.class1, .class2). Вот нашел еще более ранее упоминание подобного для Fx3. Году в прошлом-позапрошлом пытался воспроизвести — не получилось, сейчас попробовал через browserstack — аналогично. Что это было, глюк моего склероза или загадка истории? Увы... Но это поправимо!
-
По спецификации селекторов 3-го уровня, аргументом для :not может быть только простой селектор, т.е. что-то одно из селекторов по тегу, классу, псевдоклассу, атрибуту, ID либо звездочка, в кол-ве 1 шт. А тег с атрибутом — уже не простой селектор, а последовательность из 2-х простых селекторов. Там же написано, что это определение изменено по сравнению с CSS2.1, где такая последовательность считалась бы простым селектором. Возможно, учебник основан на старом черновике спецификации. С точки зрения нынешнего состояния дел, в нем ошибка. Возможно, в недалеком будущем это опять изменится.
-
afdw, это вы не путайте . Как раз свойство по вашей ссылке не относится к теме, а вот это (оно же в спецификации) очень даже относится .
-
Много кто спрашивал про нестандартное обтекание текста
SelenIT replied to Galaxy's question in HTML Coding
Это всё, конечно, очень бла-ародно, ну а как, всё-таки, делать такое обтекание на практике? IE9(8)+ чтобы и все дела, как обычно. На ум приходит только дедовский метод. Кто дока в SVG, там (через foreign object-ы всякие и т.п.) нет стандартного варианта попроще? -
Простейший случай: резиновая ширина, фиксированные padding-и. Можно, конечно, width: calc(XX% - YYpx), но у box-sizing браузерная поддержка шире.
-
Это часть микроданных. В данном случае он говорит, что картинка, скорее всего, является логотипом продукта, бренда, места или организации.
-
Это две разные темы Вторая относится к ископаемым IE (7-) и лишь косвенно задевает первую. Еще призрак haslayout-а по ночам приходит к новым браузерам в виде хаков а-ля -xxx-backface-visibility:hidden и transform:translateZ(0), но это уже третья тема)
-
Приколы c PIE в ie8. Ослик сошел с ума, или что?
SelenIT replied to ya_verstaka's question in HTML Coding
Не отстой — изящная деградация. Пусть в старых ослах картинка будет квадратной, зато слайдер будет летать, не дожидаясь, пока левый скрипт навтыкает посторонних VML-тегов где успеет (если скрипт слайдера меняет DOM динамически, логично, что успеет не везде). От угловатых картинок ни один юзер ископаемого барахла не умрет, а вот от невменяемых скриптовых тормозов с глюками может и разозлиться... Если же заказчик требует попиксельного соответствия везде... тогда сочувствую. Как вариант, можно сделать скругленную рамку картинкой и наложить на каждый слайд с помощью фильтра AlphaImageLoader (только для IE8) или псевдоэлементом с absolute. -
Почему в сафари блок с текстом не занял всю ширину
SelenIT replied to Anna Zharova's question in HTML Coding
Имхо, на сафари под Win можно смело плюнуть, как в свое время на IE под Mac . Куда важнее мобильный Сафари (iPad и всё такое), у меня в 7.1.1 адекватно смотрятся все варианты, кроме первого. упд: скриншот с айпада -
Конвертер шрифтобелки по умолчанию любит «подправлять» вертикальные метрики шрифтов. Поэкспериментируйте с галочками в разделе «Rendering» и особенно «x-height matching» (пусть Джорджии и соответствует) в экспертном режиме генератора. Но вообще с Джорджией я бы так не заморачивался, а просто предусмотрел для тех нуля целых чуть десятых процента, где ее нет, минимально неразваливающийся вид с другим шрифтом с засечками (который там может оказаться serif по умолчанию). P.S. А что, белка принимает Джорджию, она уже не закопирайчена?
-
Вот здесь рекомендуют для подобной ситуации указывать в meta viewport конкретно ту ширину, под которую дизайн оптимизирован, в данном случае, видимо, 760px. А вообще с этой метой какая-то уличная магия
-
Мобильные браузеры по умолчанию раскидывают элементы относительно «виртуального вьюпорта» (в iOS он соответствует окну шириной 980px, в андроидном браузере — 800px, в мобильных Операх, кажется, 850, подробнее — у PPK в «сказе о двух вьюпортах»), который потом зумится до фактической ширины экрана. Это можно изменить с помощью <meta name="viewport">. Pixel ratio, насколько я в курсе, на размер виртуального вьюпорта не влияет.
-
Еще в свое время была занятная пара статей: http://css-tricks.com/myth-busting-css-animations-vs-javascript/ и http://christianheilmann.com/2014/01/13/myth-busting-mythbusted/. Во второй, кстати, неплохой ответ на вопрос топика.
-
Серебряной пули нет, всё зависит от задачи. Если верстается промо, с подгонкой надписей под графику и т.п., альтернативы пикселям немного. Если контент и под новые браузеры — удобно задать основной размер (для HTML) в пикселях, а дальше от него плясать rem-ами. Аналогично бывает удобно делать масштабируемые виджеты (кнопки и т.п.) с размерами в em-ах — тогда их размер будет подстраиваться под контекст в зависимости от размера текста родителя. Завязывать всё на em-ы, как по мне, быстро превращается в мучение из-за неудобных дробей, но опять же — надо смотреть по ситуации.
-
Хабрапост по ссылке про em-ы в медиавыражениях, а не для размера текста. Сами тексты в современных браузерах, насколько мне известно, зумятся одинаково независимо от единиц (это только в IE6 были проблемы с зумом px).
-
Это бордер. Но по необязательному алгоритму из спеки он должен был наполовину выступать за габариты самой таблицы, как бы в область маргина (при border-collapse:collapse). А может, и не должен был — сейчас посмотрел раздел 17.6.2, там речь идет о «row width», а не «table width»… ох и запутанная эта спека! Еще раз спасибо за стимул разобраться в этом массаракше
-
Бывало, когда синтаксис модуля CSS менялся до неузнаваемости (напр. у флексбоксов), тогда да, старые свойства с префиксом уходили в историю, а новые без префикса записывались совсем по-другому. Чтобы такое случилось со свойством без префикса, не припоминаю (было, что word-wrap с какого-то перепоя переименовали в overflow-wrap, но старое имя даже в спецификации официально оставили как допустимый синоним, так что поддержка в браузерах тоже сохранилась)...
-
Ячейка не может. А у таблицы, да, по тому алгоритму из спеки, который браузеры не обязаны соблюдать (и не соблюдают) — теоретически должны были выпадать. Кстати, у меня в Fx в примере наблюдается забавный баг — вертикальные border-ы между ячейками при 100%-ном масштабе на пиксель отстают от верхнего, при любой их толщине, большей 1px. Ох и намудрили спекописцы/браузероделы с этими таблицами, ох и намудрили...
-
В новом синтаксисе оно и должно быть, но только в нём. Странно, что добавлялка префиксов не скорректировала запись для старого синтаксиса, хотя для совсем старого -webkit-варианта, вроде, справилась…
-
…и не дадут почти никакого толку, т.к. старые префикснутые реализации не поймут записи с «to». Ох, сырая фича, недоделанная!
-
Вопрос, конечно, интересный Вообще раздел про таблицы в CSS2.1 написан так, что черт ногу об голову сломит. В п. 17.5.2.1 (ширина при table-layout:fixed) говорится, что Алгоритм из 10.3.3 как раз предписывает вписать блок в ширину контейнера. С другой стороны, при автоматическом алгоритме (п. 17.5.2.2), В общем, анархия — мать порядка, как нередко бывает у W3C. Хорошо, что браузеры хотя бы оглядываются друг на друга и мало-мальски приводят это нерегламентированное поведение к какому-то общему знаменателю. А вообще реальное поведение таблиц — хорошая тема для исследования, будет чем заняться на досуге...
-
А просто min-width для ячейки недостаточно?
-
Firefox время от времени убирает поддержку -moz-префикса для свойств, которые достаточно давно (5-10 версий подряд) поддерживаются без префикса. Судя по отсутствию надписи «[Prefixed version still accepted]» для свойств в списке, они уже отменены.Хром тоже грозился отменить старые -webkit-свойства, но примеров я пока не знаю.