SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Еще кроссбраузерный вариант — через Canvas. А для старых IE, если надо — filter:gray.
-
В каком музее вы нашли такой старинный доктайп? Используйте тот доктайп, который будут подразумевать браузеры, которым вашу страницу отображать, а остальные пусть себе лежат в музее. И сразу пропадут сбивающие с толку ошибки по поводу слешей в <link> (на самом деле это не ошибка), непонятки по поводу скрипта в <head> (на самом деле он там вполне может быть), зато появится множество однотипных ошибок про отсутствующие alt у картинок и <input type="image"> (в принципе, с этим тоже можно жить, но лучше исправить — поисковики и пользователи с ограниченными возможностями скажут спасибо), жалобы на устаревшие атрибуты (опять же — не смертельно, но некрасиво, лучше перенести это в CSS), а также, что важнее, неправильное вложение тегов (всё, что кроме li, внутри ul — вынести из ul наружу), архаичный тег <font> (заменить на <span> с классом и описать класс в CSS) и, наконец, парочка просто незакрытых тегов (хотя, возможно, после исправления ошибок вложенности «само пройдет»). А нестандартный яндксовский <noindex>...</noindex> можно смело заменить на эквивалентный комментарий <!--noindex-->...<!--/noindex-->
-
Исторически IE обводил картинки в ссылках рамкой, чтобы сделать очевидной их кликабельность. Технически это самый обычный бордер, убирается заданием img { border:0; }. В IE11 этой рамки уже нет по умолчанию, как в др. браузерах.
-
Размер букв практически всегда меньше размера шрифта. По традиции, тянущейся с металлического типографского набора, размером шрифта считается размер площадки, на которой, кроме самой буквы, могут размещаться всевозможные диакритические знаки типа кружочков и крышечек и т.п. Вот здесь чуть подробнее.
-
А что и как вы измеряете? Размер самих букв?
-
CSS - текст в блоке - отступ сверху (всегда на 1px > других браузеров)
SelenIT replied to jackjay's question in HTML Coding
Во-первых, желательно поставить доктайп, всё-таки в стандартном режиме браузеры меньше самовольничают, чем в Quirks mode. Во-вторых, можно поиграться с дробными размерами для шрифта и подобрать значение, которое большинство округлит одинаково. Но на самом деле рендеринг шрифтов всегда различается между браузерами/платформами, и если даже найдется решение/хак для существующих платформ, всегда может появиться новая, где опять будет чуть-чуть по-другому. Поэтому такие погрешности считаются приемлемыми даже при самых жестких требованиях к пиксельперфектности. -
Точнее, для любого HTML (1-5). В X(HT)ML нет неявного закрытия по построению языка, но работает это только при полноценном XML-парсинге (application/xhtml+xml и т.п.). При text/html де-факто всё равно будет неявное закрытие.
-
Неа. Не была бы <li> может встретиться в <ol> . И минимальная (на последнюю единичку), но всё же разница в специфичности. Блочные и строчные были в HTML4, и это было ошибкой. В HTML5 есть потоковые, фразовые, интерактивные и т.п., но вообще у каждого своя Content model. Случай с <p> - самый явный пример, почему делить элементы в HTML на блочные и строчные плохо.
-
Правильно ли использовать атрибуты width="100%" height="auto" для изображений?
SelenIT replied to tester2014's question in HTML Coding
Вообще говоря, width в процентах для картинок именно что запрещена: Поэтому width=100% для картинки всё же невалидно. Другое дело, что браузеры всё равно обязаны такое понимать, поэтому работать должно. Но, действительно, зачем, что мешает назначить класс? -
Вообще, по некоторому размышлению, напрашивается-таки картинка + SVG-маска.
-
Вроде ж абсолюты в ячейках не пахали только в фоксе, и с прошлой версии это исправили?
-
Почему нельзя? Давным-давно я делал вот такой страшный изврат, как раз с таблицами для IE7-, конечно, мусор в разметке дикий, но в новых браузерах DOM чистая...
-
Если просто перекрыть картинкой с прозрачным углом, вверху карты под этим углом будет некликабельно-нетягабельная область, с точки зрения юзеров сильно смахивающая на баг... А кто у нас, кроме опера-в-мини, не поддерживает 2d transform, хотя бы с префиксом? Даже в IE5.5-8 было хоть через заднее кирильцо, но реализовано (хотя кому сегодня это нужно).
-
Можно прогрессивно улучшаться до них. Например, есть старая реализация грида на инлайн-блоках/флоатах, с кучей сопутствующих хаков. Задаем контейнеру display:flex, и, если браузер его понимает, все хаки по волшебству становятся не нужны (для подстраховки можно подпереться @supports(flex-flow) {...}, как в моем старом примере, но необязательно). Такой эволюционный переход на флексбоксы делает, в частности, проект Pure CSS Grids (наследник YUI CSS Grids). Сейчас там флексбоксы для вебкитов и IE10, но со следующего релиза (0.6) будет по умолчанию уже для всех.
-
Префиксы фтопку. Есть только одни флексбоксы - последние, они же стандартные. Для старья в 99% случаев как раз прокатит фолбэк на CSS-таблицы/инлайн-блоки/флоаты, будет и проще, и быстрее
-
Полагаю, dataType:"html" сбивает обработчик с толку и мешает распознать и распарсить json. Его можно просто убрать.
-
Не стоит так категорично. Если по дизайну на широком экране табличка, а на узком какй-нибудь опенклоуз, то нормально дивами эмулировать табличку. Так одно другому не противоречит. Если это только представление для одного из вариантов дизайна, то эти данные не такие уж и табличные. А если нужда заставит, для маленьких экранов можно и td { display:block; } задать с сопутствующими украшательствами (а-ля пример №3), мобильные браузеры поймут. Вообще с приходом флексбоксов, которые и быстрее, и универсальнее, и в семантику не вмешиваются даже по пьяни, реально нужных ниш для CSS-таблиц и впрямь осталось немного. Разве что как аварийный fallback для тех же флексбоксов и как альтернативный хак для создания блочного контекста...
-
Имхо, достаточно дать форме поиска clear: right, чтобы она опустилась под контакты, а не цеплялась за их угол (демка на базе примера Galaxy).
-
Как по мне, на вид всё очень симпатично, все требования выполнены, придраться можно разве что к жестко ограниченному количеству "хаотичных поворотов" (хоть в условии кол-во картинок и фиксировано, но мало ли. Можно еще добавить небольшой разброс transform-origin (это как раз даст небольшие "хаотические сдвиги"), причем "зациклить" его с шагом, некратным шагу зацикливания углов поворота (по "принципу цикады"). Еще можно по тому же принципу комбинировать повороты внешних и внутренних контейнеров.
-
Уже гораздо лучше. То, что "почти", имхо, можно подлечить свойством clip. А зачем абсолютно позиционированные элементы двигать margin-ами?
-
Из браузерных стилей по умолчанию для ul. Обнулите ему padding.
-
Только лучше брать не screen.width/height, а document.documentElement.clientWidth/clientHeight, потому что 1) окно браузера не обязательно раскрыто на весь экран, особенно когда он большой, и 2) на retina- и им подобных экранах с высокой плотностью пикселей screen.width/height меряется в аппаратных пикселях, а нам нужны CSS-пиксели (подробнее - http://www.quirksmode.org/mobile/viewports.html, есть перевод).
-
Имхо, строить долгосрочные прогнозы для веба — неблагодарное дело. Вот, в конце 90-х вебу предрекали скорую трехмеризацию и слияние с виртуальной реальностью, радовались первым ласточкам типа VRML — и где теперь этот трехмерный веб? В начале нулевых предвещали «вот-вот» наступление «интернета вещей», эру холодильников и микроволновок, самостоятельно скачивающих рецепты и заказывающих продукты, воспевали простоту и универсальность XHTML как платформы для этого светлого будущего — а вместо этого пришли лайки с инстаграммами. А вот прихода экранов в бешеные тыщи пикселей и дохренадцатиядерных процессоров в мобилках, вкупе с геопривязкой и кучей датчиков «обычной реальности», по-моему, не прредсказывал никто — и потенциал этих штуковин, на мое имхо, еще в полной мере не раскрыт (правда, и с поддержкой соотв. API мобильными браузерами еще не всё радужно, но это как раз быстро меняется). Так что нужно просто следить за новинками, экспериментировать, улавливать «веяние времени» (и пытаться задавать моду, а не плестись за ней), а также прощупыать разные ниши — и всё будет нормально еще долгие годы. Эх, если б я сам умел всё вышесказанное..:•)
-
Нет светящихся обводок у рамок. Нет ободков полупрозрачного фона вокруг листалок кадров. В Фоксе кадры съехали вверх до упора в край блока. Фон в шапке рябит (видимо, пережат). Внизу в kinoruletka.ru пропущена буква и маловат отступ между текстом и линиями.
-
HTML/CSS выравнивание строки выше центра на несколько px. Как сделать четко посредине?
SelenIT replied to YariG's question in HTML Coding
Какой браузер и ОС? У меня в Win7 в Фоксе 32 и Хроме 37, а также в мобильном Сафари на iOS 7 (айпад-мини) и андроид-браузере 4.0 в обоих штатных масштабах (переключаемых двойным тапом) всё ровно, выпендривается только IE9, ну и андроид-браузер на некоторых нестандартных масштабах. Вообще, боюсь, проблема действительно задротская и универсального решения не имеет. Рендеринг шрифтов - та вещь, в которой между браузерами и платформами всегда будут разбежки, свои нюансы антиалайзинга, хинтинга и т.п., неизбежные при них ошибки округления (положение базовой линии шрифта и границ кегельных площадок определяют метрики шрифта типа *Ascent и *Descent, которые почти всегда оказываются нецелыми) - крошечная часть общего несовершенства мира, с которой, скорее всего, придется смириться. Но если перфекционизм прямо мешает уснуть, можно, что называется, "поиграть со шрифтами" и их размерами и опытным путем подобрать комбинации, наиболее удачные для целевых платформ. В т.ч. с дробными размерами (напр. у меня IE9 исправился при замене 16px на 16.3px, при этом все остальные, вроде, не поломались).
