Jump to content

SelenIT

Expert
  • Posts

    4,327
  • Joined

  • Last visited

  • Days Won

    140

Everything posted by SelenIT

  1. Не уверен, сейчас пробежался по истории CSS3 Selectors — ограничение простым селектором там было с самого начала. По логике, :not(x,y) — лишь «сахарок» для :not(x):not(y), так что ограничение легко обходится и роялит лишь при борьбе за каждый байт, как в css1k.com (при экспериментах с которым я тот глюк и поймал ☺). Ну и, да, расхождение между jQuery и чистым CSS запутывает.
  2. Потому что отступы строчных элементов не схлопываются. Элементы p, h1, div и т.п. — блочные (а вообще схлопывание бывает у любых элементов с display:block, кроме особых случаев, оговоренных в спецификации). Зачем так сделано — см. здесь после «отчего так».
  3. Я сам удивился, до этого вопроса не задумывался о таких нюансах Кстати, году в 2011-м у меня был глюк, что в какой-то из актуальных тогда Опер внезапно сработал селектор наподобие :not(.class1, .class2). Вот нашел еще более ранее упоминание подобного для Fx3. Году в прошлом-позапрошлом пытался воспроизвести — не получилось, сейчас попробовал через browserstack — аналогично. Что это было, глюк моего склероза или загадка истории? Увы... Но это поправимо!
  4. По спецификации селекторов 3-го уровня, аргументом для :not может быть только простой селектор, т.е. что-то одно из селекторов по тегу, классу, псевдоклассу, атрибуту, ID либо звездочка, в кол-ве 1 шт. А тег с атрибутом — уже не простой селектор, а последовательность из 2-х простых селекторов. Там же написано, что это определение изменено по сравнению с CSS2.1, где такая последовательность считалась бы простым селектором. Возможно, учебник основан на старом черновике спецификации. С точки зрения нынешнего состояния дел, в нем ошибка. Возможно, в недалеком будущем это опять изменится.
  5. afdw, это вы не путайте . Как раз свойство по вашей ссылке не относится к теме, а вот это (оно же в спецификации) очень даже относится .
  6. Это всё, конечно, очень бла-ародно, ну а как, всё-таки, делать такое обтекание на практике? IE9(8)+ чтобы и все дела, как обычно. На ум приходит только дедовский метод. Кто дока в SVG, там (через foreign object-ы всякие и т.п.) нет стандартного варианта попроще?
  7. Простейший случай: резиновая ширина, фиксированные padding-и. Можно, конечно, width: calc(XX% - YYpx), но у box-sizing браузерная поддержка шире.
  8. Это часть микроданных. В данном случае он говорит, что картинка, скорее всего, является логотипом продукта, бренда, места или организации.
  9. Это две разные темы Вторая относится к ископаемым IE (7-) и лишь косвенно задевает первую. Еще призрак haslayout-а по ночам приходит к новым браузерам в виде хаков а-ля -xxx-backface-visibility:hidden и transform:translateZ(0), но это уже третья тема)
  10. Не отстой — изящная деградация. Пусть в старых ослах картинка будет квадратной, зато слайдер будет летать, не дожидаясь, пока левый скрипт навтыкает посторонних VML-тегов где успеет (если скрипт слайдера меняет DOM динамически, логично, что успеет не везде). От угловатых картинок ни один юзер ископаемого барахла не умрет, а вот от невменяемых скриптовых тормозов с глюками может и разозлиться... Если же заказчик требует попиксельного соответствия везде... тогда сочувствую. Как вариант, можно сделать скругленную рамку картинкой и наложить на каждый слайд с помощью фильтра AlphaImageLoader (только для IE8) или псевдоэлементом с absolute.
  11. Имхо, на сафари под Win можно смело плюнуть, как в свое время на IE под Mac . Куда важнее мобильный Сафари (iPad и всё такое), у меня в 7.1.1 адекватно смотрятся все варианты, кроме первого. упд: скриншот с айпада
  12. Конвертер шрифтобелки по умолчанию любит «подправлять» вертикальные метрики шрифтов. Поэкспериментируйте с галочками в разделе «Rendering» и особенно «x-height matching» (пусть Джорджии и соответствует) в экспертном режиме генератора. Но вообще с Джорджией я бы так не заморачивался, а просто предусмотрел для тех нуля целых чуть десятых процента, где ее нет, минимально неразваливающийся вид с другим шрифтом с засечками (который там может оказаться serif по умолчанию). P.S. А что, белка принимает Джорджию, она уже не закопирайчена?
  13. Вот здесь рекомендуют для подобной ситуации указывать в meta viewport конкретно ту ширину, под которую дизайн оптимизирован, в данном случае, видимо, 760px. А вообще с этой метой какая-то уличная магия
  14. Мобильные браузеры по умолчанию раскидывают элементы относительно «виртуального вьюпорта» (в iOS он соответствует окну шириной 980px, в андроидном браузере — 800px, в мобильных Операх, кажется, 850, подробнее — у PPK в «сказе о двух вьюпортах»), который потом зумится до фактической ширины экрана. Это можно изменить с помощью <meta name="viewport">. Pixel ratio, насколько я в курсе, на размер виртуального вьюпорта не влияет.
  15. Еще в свое время была занятная пара статей: http://css-tricks.com/myth-busting-css-animations-vs-javascript/ и http://christianheilmann.com/2014/01/13/myth-busting-mythbusted/. Во второй, кстати, неплохой ответ на вопрос топика.
  16. Серебряной пули нет, всё зависит от задачи. Если верстается промо, с подгонкой надписей под графику и т.п., альтернативы пикселям немного. Если контент и под новые браузеры — удобно задать основной размер (для HTML) в пикселях, а дальше от него плясать rem-ами. Аналогично бывает удобно делать масштабируемые виджеты (кнопки и т.п.) с размерами в em-ах — тогда их размер будет подстраиваться под контекст в зависимости от размера текста родителя. Завязывать всё на em-ы, как по мне, быстро превращается в мучение из-за неудобных дробей, но опять же — надо смотреть по ситуации.
  17. Хабрапост по ссылке про em-ы в медиавыражениях, а не для размера текста. Сами тексты в современных браузерах, насколько мне известно, зумятся одинаково независимо от единиц (это только в IE6 были проблемы с зумом px).
  18. Это бордер. Но по необязательному алгоритму из спеки он должен был наполовину выступать за габариты самой таблицы, как бы в область маргина (при border-collapse:collapse). А может, и не должен был — сейчас посмотрел раздел 17.6.2, там речь идет о «row width», а не «table width»… ох и запутанная эта спека! Еще раз спасибо за стимул разобраться в этом массаракше
  19. Бывало, когда синтаксис модуля CSS менялся до неузнаваемости (напр. у флексбоксов), тогда да, старые свойства с префиксом уходили в историю, а новые без префикса записывались совсем по-другому. Чтобы такое случилось со свойством без префикса, не припоминаю (было, что word-wrap с какого-то перепоя переименовали в overflow-wrap, но старое имя даже в спецификации официально оставили как допустимый синоним, так что поддержка в браузерах тоже сохранилась)...
  20. Ячейка не может. А у таблицы, да, по тому алгоритму из спеки, который браузеры не обязаны соблюдать (и не соблюдают) — теоретически должны были выпадать. Кстати, у меня в Fx в примере наблюдается забавный баг — вертикальные border-ы между ячейками при 100%-ном масштабе на пиксель отстают от верхнего, при любой их толщине, большей 1px. Ох и намудрили спекописцы/браузероделы с этими таблицами, ох и намудрили...
  21. В новом синтаксисе оно и должно быть, но только в нём. Странно, что добавлялка префиксов не скорректировала запись для старого синтаксиса, хотя для совсем старого -webkit-варианта, вроде, справилась…
  22. …и не дадут почти никакого толку, т.к. старые префикснутые реализации не поймут записи с «to». Ох, сырая фича, недоделанная!
  23. Вопрос, конечно, интересный Вообще раздел про таблицы в CSS2.1 написан так, что черт ногу об голову сломит. В п. 17.5.2.1 (ширина при table-layout:fixed) говорится, что Алгоритм из 10.3.3 как раз предписывает вписать блок в ширину контейнера. С другой стороны, при автоматическом алгоритме (п. 17.5.2.2), В общем, анархия — мать порядка, как нередко бывает у W3C. Хорошо, что браузеры хотя бы оглядываются друг на друга и мало-мальски приводят это нерегламентированное поведение к какому-то общему знаменателю. А вообще реальное поведение таблиц — хорошая тема для исследования, будет чем заняться на досуге...
  24. А просто min-width для ячейки недостаточно?
  25. Firefox время от времени убирает поддержку -moz-префикса для свойств, которые достаточно давно (5-10 версий подряд) поддерживаются без префикса. Судя по отсутствию надписи «[Prefixed version still accepted]» для свойств в списке, они уже отменены.Хром тоже грозился отменить старые -webkit-свойства, но примеров я пока не знаю.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy