SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Полагаю, да. Мы даже вроде не так давно похожий пример разбирали)
-
И чем это поможет голосовым браузерам? Даст эффект эха (и то лишь если юзер сам попросит)? Поисковикам тоже не поможет, ибо вызывает лишь тошноту. P.S. Старая, но по-прежнему актуальная тема про title ссылок
-
Тупыми поисковиками (к счастью, вымершими) не будет, продвинутыми, вероятно, будет, но плохо. Гугл рекомендует делать вот так.
-
По той странице, приличная часть ошибок просто по невнимательности (вроде пропущенных закрывающих кавычек у атрибутов). Еще валидатору не нравятся амперсанды в URLах ссылок и путей к картинкам, нужно записывать их как &. Элемент <link> по ошибке забрался в body вместо head (HTML5 допускает это, но в особом случае, здесь не тот случай). Еще у картинок не проставлены alt-ы (опять же, в исключительных случаях можно, но здесь не тот случай), зато у многих тегов стоят ископаемые, ненужные атрибуты (language у скрипта, border у картинки и т.п.). И name у ссылки не нужен — во-первых, он тоже устарел, во-вторых, очень редко ссылка сама является еще и якорем. Якоря, если они нужны, делаются через id любого элемента. А вот itemid, похоже, попал туда действительно по ошибке. Никакой осмысленной микроразметки (структурированных данных), частью которой он мог бы быть, я не наблюдаю (и специальный инструмент Гугла для этого — тоже). Если этот атрибут используется скриптом, то лучше, да, заменить его на data-itemid (и подправить сам скрипт соотв-но) — чтобы не сбивать с толку роботов поисковиков и т.п., которые могут считать его частью структурированных данных, по какой-то причине потерявшихся.
-
В префикснутых вариантах как раз "to" не нужен. Строчка с -ms-префиксом тоже не нужна, IE9 всё равно не поймет, релиз IE10 понимает без префикса с "to" (по стандарту), а бетами IE10 нормальные люди не пользуются. Да и -moz-строчка тоже не сильно нужна сейчас — много ли осталось Фоксов ниже 17-го, когда уже вышел 26-й? На практике сегодня достаточно двух строчек: background: -webkit-linear-gradient( bottom, #dedede, #fff); /* Safari 6-, в т.ч. мобильные */ background: linear-gradient( to top, #dedede, #fff); /* стандарт W3C, все новые браузеры */
-
В IE для кнопок почему-то нужно явно указывать overflow:visible. Тоже недавно на это напарывался. Видимо, баг.
-
:last-child не поддерживает только IE8-, доля которого в сумме в Рунете меньше 5%. Может, и... ладно бы с ним?
-
Тупо убирать — не выход. Надо 1) определиться с задачей, 2) выбрать правильный инструмент для решения задачи, 3) решить задачу. Зачем-то ведь вы эти атрибуты ставили (для какого-то JS-плагина или еще чего-то)? Значит, скорее всего они зачем-то нужны. И удалять их, чтобы пройти формальную валидацию по устаревшей схеме — всё равно, что отрезать себе ногу, чтобы иметь право сидеть на местах для инвалидов в метро Вообще, современные браузеры разбирают страницы именно по HTML5-правилам (независимо от доктайпа), так что если с HTML5-доктайпом валидатор показывает много ошибок — это в любом случае нехорошо. Нужно разбираться с причиной, а не прятаться от нее за более удобный (для валидатора, но не для работы) доктайп. Можно увидеть саму проблемную страницу?
-
По спецификации, эти свойства вроде как помечены как readonly, но наверняка можно напрямую поменять значение атрибута через setAttribute (как минимум, для SVGшки, заинлайненной прямо в страницу). Правда, честно признаюсь, до сих пор самому такого делать не доводилось. Плюс есть возможность анимировать эти вещи средствами самого SVG.
-
Можно выкрутиться через несколько вложенных оберток с overflow:hidden и разной трансформацией поворота (http://kizu.ru/fun/polygons/). Но если там огромная картинка — может быть напряжно для рендерера. Лучше на SVG.
-
Поменять доктайп на <!DOCTYPE html>, в котором эти атрибуты есть. Но вообще подозрительно, если из всех микроданных есть только itemid, без itemprop и т.п. Можно увидеть проблемную страницу?
-
Есть (правда, у W3C — в отдельной спецификации для микроданных) Понимают-то любые, но валидатор, да, признает их законными только при html5-доктайпе. Как и itemid. Впрочем, другие доктайпы на сегодняшний день и не нужны (за исключением редчайших лабораторных примеров). А переходные доктайпы — вообще ископаемый пережиток (под «переходом», для которого их вводили, имелся в виду от HTML3.2 к HTML4!) и просто потенциальные грабли (т.к. с ними страницы рисуются не в полностью стандартном, а в «полустандартном» режиме, т.е. по факту с узаконенными глюками!).
-
Горизонтальное выравнивание блочных элементов
SelenIT replied to FRUTALITY's question in HTML Coding
Зачем? Речь же идет о частной задаче — выстраивании блоков в ряд по горизонтали, разве нет? Для современных браузеров вполне хватает display: table для контейнера и display: table-cell для «ячеек». Из неупомянутых ранее минусов — невозможность абсолютного позиционирования относительно таких «ячеек» (как и относительно обычных, впрочем), частично решается вложенными обертками. Сложность поддержки для CSS-таблиц, флоатов и инлайн-блоков, имхо, сопоставима. Всё-таки ни один из трех способов не предназначен напрямую для выстраивания блоков (если на то пошло, CSS-таблицы приспособлены больше других), отсюда необходимость тех или иных хаков (для флоатов — клирфиксы, для инлайн-блоков — обнуление пробелов, и т.п.). Сами по себе, тем более в последней редакции спеки — именно что подарок. Вещь одного порядка с гридами, если не круче (смотря для каких задач, конечно). Но браузеры, увы... как всегда. Вот хорошая статья о них с примерами. -
Горизонтальное выравнивание блочных элементов
SelenIT replied to FRUTALITY's question in HTML Coding
6. (уже упомянули) «Не очень старые не очень добрые CSS-таблицы», в смысле display:table для контейнера и display:table-cell для элементов (плюсы те же, что у нормальных таблиц, но без ущерба для семантики, стандартный CSS2.1, главный минус — неподдержка в IE7-). 7. Модные, но с непростой судьбой флексбоксы (плюсы: специально разработаны для этой задачи, поддерживаются в том или ином виде во всех браузерах, кроме IE9- и Оперы-мини, минусы: в разных браузерах поддерживаются очень разные версии спеки, нужен зоопарк префиксов и разных синтаксисов, реализация старой спеки достаточно тормозная). Немного не так. Такой блок внутри ведет себя как обычный блок, причем с отдельным контекстом форматирования (из него не выпадают float-ы и margin-ы потомков), но сам снаружи живет в инлайновом контексте, т.е. ведет себя как слово или картинка в тексте, подчиняясь св-вам text-align, vertical-align и т.п. Поэтому и пробелы между тегами для него учитываются. А ширина у него по умолчанию подстраивается по ширине контента, как и у float-а. -
Чаще покидает ненадолго через год-два, но через три-пять-десять понемногу возвращается
-
Это исправит время, когда пользователи Оперы обновятся на новую ветку (которая похожа на Хром). До этого, боюсь, никак. см. следующий ответ.
-
Судя по всему, действительно это не исправить: http://my.opera.com/community/forums/topic.dml?id=236866 Но это всё же явно не последняя версия Оперы, а лишь последняя на движке Presto. Новые версии Оперы используют движок Хромиума и ведут себя аналогично Хрому и Яндекс-браузеру, без всяких рамок.
-
У box-shadow, благодаря всем 4-м параметрам, возможностей гораздо больше, чем у border и (тем более) outline вместе взятых. Фактически, множественными тенями можно рисовать буквально попиксельно (первый нагугленный пример). Конечно, злоупотреблять не стоит.
-
В моем понимании, четкость — это нечто, обратно пропорциональное размытию (нулевое размытие == полная четкость).
-
Для четкости 3-й параметр. 4-й — выступ тени за контур. А их сочетание, кроме прочего, бывает полезно для рисования многоцветных рамок
-
Там одна тень, а я имел в виду две разные: http://jsfiddle.net/cJ8MV/23/
-
Если забить на Windows-нетбуки (где при 1024 почти с гарантией будут оба скролла) и считать гориз. скролл на мобилках нормальным делом, то, пожалуй, да. Но я бы всё же ориентировался на 980 (дефолтный размер виртуального вьюпорта в iOS + отсутствие проблем при 1024 на винде в одном флаконе). Еще лучше бы, конечно, на 800 (дефолтный виртуальный вьюпорт у андроидов), но это уж по желанию. Подробности про два вьюпорта на мобильниках и их размеры в классической статье PPK http://quirksmode.org/mobile/viewports2.html
-
Штуки три-четыре модулей CSS3 — уже стандарт (какой-то модуль стал стандартом в один день с CSS2.1).
-
Вот эта схема? На каком языке вы ее читали?
