SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Первый вариант в других браузерах точно ничего странного не создает? Второй вариант обязательно проверьте в DOM-инспекторе, может быть сюрприз (какой элемент будет родительским для style?). По теме — вот на SO пишут, что иногда проблему решает один пробел в <!-- [if...
-
Не совсем так: сначала идет присвоение, а потом проверяется его результат. При первом заходе в цикл 1 < 10 == true, поэтому cnt присваивается значение true, внутри цикла cnt++ неявно преобразует true в 1 и на выходе из цикла cnt == 2. При втором заходе 2 < 10 — всё равно true, поэтому дальше эта история повторяется бесконечно.
-
Помгите реализовать рамку заголовка средствами html и css
SelenIT replied to gap's question in HTML Coding
С центрированием, насколько мне известно, не (по крайней мере, без уличной магии). Без центрирования, видимо, можно, но капризно, негибко и, простите за выражение, несемантично.. -
Помгите реализовать рамку заголовка средствами html и css
SelenIT replied to gap's question in HTML Coding
Для новых браузеров достаточно 1 блока. -
Имхо, на практике достаточно .rotate-45 { /* для ios7 safari/android browser */ -webkit-transform: rotate(-45deg); /* для IE9 */ -ms-transform: rotate(-45deg); /* для всех остальных, включая Оперу 12.1 */ transform: rotate(-45deg);}.ie_lt9 .rotate-45 { /* для реально ископаемых ИЕ... оно точно того стоит? */ /* если да, то надо спрятать от IE9, т.к. он понимает и фильтры, и -ms-transform */ filter: progid:DXImageTransform.Microsoft.Matrix(M11=0.7071067811865476, M12=0.7071067811865475, M21=-0.7071067811865475, M22=0.7071067811865476,sizingMethod='auto expand');}
-
Это не соответствует действительности. В основе jsfiddle — банальный iframe, в котором отображается обычная html-страница с <!DOCTYPE html>, в которую в <style>, <script> и <body> соответственно динамически подставлен код из соотв. панелей редактора. Это легко увидеть по F12.
-
А jsfiddle разве не в браузерах работает? Может, имелось в виду "как без доктайпа"?
-
Происходит неочевидная особенность стандарта CSS. Пока доктайпа нет, браузер работает в режиме угадывателя мыслей (например, считает, что любые значения без единиц измерения заданы в пикселях, что цвета типа "fff", без "#" — это нормальный способ их указания, что если он IE, даже 10-й, то градиенты, закругления и тени сайту всё равно не понадобятся, и т.д.). В том числе он "додумывает" за автора, что 100% высоты — это 100% высоты окна (как выясняется, нередко угадывает). Но когда доктайп стоит, браузер обязан соблюдать стандарты. По которым для значений height в процентах сказано следующее: Таким образом, чтобы проценты для высоты заработали, "height: 100%" должно быть задано всей цепочке предков таблицы — включая html и body. Так что тут уместнее ругаться на «чертов стандарт CSS». Впрочем, в новых браузерах можно обойтись без цепочки 100%, задав элементу height:100vh вместо 100%. И еще, зачем растягивать на всю высоту окна таблицу?
-
Почему Mozilla FireFox отображает шрифты шире чем все остальные браузеры
SelenIT replied to Special One's question in HTML Coding
Но невозможно пересадить всех пользователей на линукс -
Почему Mozilla FireFox отображает шрифты шире чем все остальные браузеры
SelenIT replied to Special One's question in HTML Coding
К сожалению, это не возможно. Более того, рендеринг шрифтов может отличаться в пределах одного браузера на разных версиях ОС и при разных настройках, т.к. рендеринг шрифтов часто отдается на откуп системным библиотекам. Но к счастью, это не нужно. Веб — не полиграфия, его сила как раз в том, чтобы пользователь мог получить контент в том виде, как удобнее и привычнее ему (включая размер, тип сглаживания, кернинг/хинтинг и т.п.). Поэтому разный рендеринг шрифтов на разных платформах — не баг веба, а фича, и это просто нужно учитывать, оставляя небольшой запас, чтобы ничего не сломалось, даже если шрифт окажется чуть крупнее. Особо попиксельно-критичные надписи для промо можно делать картинками (в т.ч. векторными), но реально это нужно хорошо если в 0,01% случаев. -
Section — тематический раздел чего-то (страницы, статьи, другого раздела...). Aside — особая разновидность тематического раздела, сразу показывающая, что относится к остальным разделам лишь косвенно, является чем-то дополнительным (ARIA role: complementary) и, например, скринридер может по умолчанию ее пропускать и зачитывать лишь по явному требованию. Но ничто не мешает такому дополнительному разделу иметь свои тематические подразделы.
-
Не всё, что говорят/делают т.н. «все», правильно Преимущества семантики бывают достаточно ощутимы в доступности и функциональности страницы при наличии каких-либо технических или физических ограничений (невозможность пользования мышкой/указателем, необходимость взаимодействовать с сайтом на слух через синтезатор речи и т.п.). Вот тут сразу чувствуется разница между полноценным <button> и всяческими <span onclick="..."> (или того хлеще <a href="javascript:...">), между role="navigation" и role="presentation", между подписями полей форм в соответствующих <label> и «просто рядом» (в запущенных случаях — в другом блоке/ячейке), и т.п. Ну а адекватное восприятие логично построенной страницы поисковиком (и, как следствие, шансы на ее более высокую «оценку» поисковиками) — приятный бонус. Ну и микроданные schema.org сбрасывать со счетов не нужно — раз сами поисковики сообща продвигают инициативу по созданию универсального словаря для описания самых употребительных на страницах вещей, значит, наверное, это кому-то нужно...
-
Не путайте семантику с SE-мантикой
-
Единого стандартного пока не предусмотрено, к сожалению. Приходится пользоваться экспериментальными костылями, которые предлагают сами браузеры. Как и со многими другими нововведениями HTML5, за которыми CSS, увы, не поспевает. Почти исчерпывающий обзор доступных браузерных костылей есть в этой статье (в частности, вот для плейсхолдера).
-
CSS на такие вещи влиять не может, он применяется к уже построенной DOM. Браузер «генерит» элементы на этапе разбора разметки, и сюрпризы в DOM — результат «сюрпризов» в ней. В данном случае это простая механическая опечатка, такие вещи как раз хорошо ловятся валидатором. Но иногда браузер «генерит» элементы абсолютно штатно и предсказуемо (напр. тегов <html>, <head>, <body> может не быть на странице и это валидно, а в итоговой DOM соотв. элементы будут). Ну а на jsFiddle роль неплохой подсказки может играть подсветка самого редактора (здесь она как раз подсветила текст, идущий после той пропущенной скобки, как атрибуты тега <a>). Единственное что эта подсветка тупая, пользуется, видимо, XML-разбором, поэтому ее правильной работы приходится «слешить» одиночные теги на XML-манер — один из крайне редких случаев, когда это дает какую-либо видимую разницу.
-
Это часть «лекарства» от выпадения float-ов и margin-ов дочерних элементов из контейнера. Описано здесь (перевод).
-
Учитывайте, что <p> — коварный тег, он неявно закрывается перед любым открывающим «блочным тегом». Так что конструкции <p>абзац</p><h3>заголовок</h3> и <p>абзац<h3>заголовок</h3> эквивалентны (и обе валидны, хотя с виду у второй закрывающие теги не сходятся!), а вот <p>абзац<h3>заголовок</h3></p> — уже ошибка («закрывающий тег для неоткрытого тега <p>» — потому что первый <p> благополучно неявно закрылся перед заголовком). И вложить <p> в <p> нельзя по той же причине. Если надо вкладывать во что-то целые абзацы и списки, используйте <div> или (по ситуации) его модные «семантичные» аналоги.
-
Спецификация говорит «можно, но (как правило) не нужно» . А для многострадальных «крошек» нынешняя версия W3C-спеки предлагает вообще лютый ад (не знаю, насколько Леони Уотсон, с подачи которой это попало в спеку, эксперт в юзабилити, но представляю себя на месте слепого юзера, которому читалка диктует: «Пропустить навигацию? Вы находитесь здесь. Список из четырех пунктов. Новый пункт: Главная. Новый пункт: Продукты...» — и мне становится не по себе). Так что «крошки» я всё-таки лучше буду делать по «живому стандарту» WHATWG — кратко, ясно и без выкрутасов (просто эти «крошки» — моя давняя больная тема, но Стив Фолкнер, к сожалению, нас с Хикси не слушал.. А что лишние nav-ы не нужны, я согласен. Я просто хотел подчеркнуть, что это не абстрактная догма, а практическое следствие из основного назначения большинства новых структурных и «околоструктурных» (main) элементов — помощь средствам доступности для пользователей с ограничениями.
-
В настолько космическом, что он приведен в самом первом примере в спецификации). Nav уместен везде, где уместны команды «пропустить навигацию/перейти к навигации» в скринридере для слепых, например. Конечно, таких мест вряд ли будут десятки, но искусственно ограничивать себя «один и только!», когда в спецификации такого ограничения нет, тоже незачем.
-
Давать старым IE упрощенную верстку для фикс. ширины 1024 (типичной для офисного антиквариата в госконторах и нетбуков — основных «месторождений» XPшки) и не беспокоиться. Единственные люди, кто в приципе захочет и сможет открыть сайт в старых IE на более приличном экране, и кто оценит ваши старания по перекраске старых ослов в сияющих единорогов — коллеги-верстальщики (ну и самые упоро... в смысле, упорные тестировщики). А реальным узникам юзерам старых IE (которые, вдобавок, работают на ископаемом же железе — иначе у них была бы более современная ОС, и скорее всего с медленной связью) куда важнее, чтобы сайт открылся быстрее и дал им возможность поскорее заполнить заветную форму, а не минуту скрипел винчестером, навешивая на свой многострадальный DOM навороты этих скриптов, и в итоге грустно крэшился(. И заказчикам, непременно желающим цветную 3D-картинку на старых ламповых ч/б-телевизорах, тоже желательно это объяснить. Если они вменяемые и заботятся о деле и пользователях, а не ненужных понтах, они поймут. А с невменяемыми заказчиками иметь дело себе дороже...
-
Article — необязательно «статья», по-английски это очень многозначное слово, которое может значить и «пункт» (в каком-то документе или перечне), и «товар», и даже просто «вещь» (почти синоним к item). Так что в article может быть что угодно, что имеет смысл само по себе (в отрыве от контекста) и может быть целиком перенесно, скажем, в RSS-фид. По нынешней спецификации, хоть виджет. А section — просто логическая группировка (то, что в пределах одной section, по смыслу связано сильнее, чем то, что за пределами), без требования «самодостаточности». Так что теоретически, имхо, и первый пример имеет право на жизнь (напр. если это страница отдельного товара в каталоге: section — раздел каталога, его header — название раздела и какая-нибудь навигация по нему, article — подробная карточка товара, footer — контакты для справок по этому разделу каталога, а aside — рекламный блок, напр., «сопутствующие товары из других разделов»). Хотя тут есть смысл подумать о main вместо section. Ну а второй пример оправдан для большой статьи в блоге или какой-нибудь википедии, с несколькими подразделами (по section-у с заголовком на каждый). Вкладывать article и section друг в друга можно в любом порядке без ограничений, сколько требует здравый смысл, но важно не терять меру. Не надо использовать их (и др. структурные теги) только для оформления (для этого есть старый добрый div). И желательно, чтобы у каждого из них был явный заголовок, одинокий section без заголовка практически всегда не нужен.
-
background и border контейнера, в котором создан контекст наложения (т.е. для которого задан position и z-index либо opacity или transform) будут ниже любого позиционированного потомка, у них z-index как бы минус бесконечность. Если не дать контейнеру создать контекст наложения (убрать у него z-index и следить, чтоб к нему случайно не применились opacity и transform), то можно «подсунуть» потомка под фон с помощью отрицательного z-index. Еще один вариант — задать нужный фон не самому контейнеру, а его псевдоэлементу с position:absolute и нужным z-index. А вообще нужно смотреть по задаче, возможно, есть выход и проще.
-
clear: right для второго блока (.news1) должен помочь.
-
Это был коммент на предполагавший, что дисплей может как-то повлиять. На самом деле что во что вкладывается прописано в спецификации и от display никак не зависит.
-
Изменение дисплея никак, никак, НИКАК не влияет на то, что во что можно вкладывать (ака Content model элемента). Если в каком-то учебнике/пособии/сайте и т.п. говорят, что можно — бегите оттуда, там хорошему не научат.
