SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
line-height: 1,5; у <small> при DTD XHTML Mobile 1.0
SelenIT replied to 7ion's question in HTML Coding
А, ну так это обычная разница между стандартным режимом и квирксмодом, с <!doctype html> будет то же самое. Фокус в том, что в стандартном режиме высота строки текста определяется line-height'ом ее блочного предка (в данном случае body). Она по умолчанию 1.33 (ЕМНИП), а у <small> еще font-size уменьшен - вот и получается относительно него где-то 1.5. -
Без скриптов знаю только вариант для известной фиксированной ширины столбцов (если надо +IE7, то как-то так). За рабочий пример с col:hover сам был бы отчаянно благодарен
-
Можно "перехитрить природу": поставить right:100% левой надписи и left:100% — правой
-
line-height: 1,5; у <small> при DTD XHTML Mobile 1.0
SelenIT replied to 7ion's question in HTML Coding
Какой эффект должен быть? Высота строки определяется самым высоким ее элементом, если вокруг <small> есть обычный текст, то высота строки не станет меньше, чем у него. Мобайл или не мобайл — по идее несущественно. -
Ну, семантика и в разметке-то — вещь сильно субъективная, а уж в CSS она и вовсе призрачна. И явная обертка вокруг неявной секции (создаваемой заголоком) — для семантики скорее плюс. Вот "целый overflow" для такой пустячной задачи — пожалуй, и впрямь "из пушки по воробьям"...
-
Вот этот тест. Что значит, "Test passes if there is no red visible on the page"? С какого перепугу блок должен ужаться до нуля вместо ширины буквы? Во всех браузерах я вижу букву на красном фоне, и в меру моего понимания спеки считаю это правильным. Ошибка в тесте, что ли?
-
Вообще по сабжу хватило бы h3 { clear: left; } . Но на будущее отдельный контейнер каждого блока и впрямь не помешает. Кстати, overflow — не единственный способ создания контекста форматирования. Ну и _overflow:visible избыточен, для IE6-7 (строчка "ОНО!" именно для них) zoom достаточно.
-
Только display:table-cell. Либо position:absolute + top + bottom (при position:relative у предка). Контейнеру минимум 100% высоты окна (обычно html {height:100%} body {min-height:100%} либо html, body {height:100%} .wrapper {min-height:100%}), а футер либо абсолютно позиционируют к низу (bottom:0), либо ставят после "обертки" и отрицательным margin-top'ом заставляют "наехать" на нее. Ну и зарезервировать каким-либо способом место на высоту футера ниже контента, чтоб сам контент под футер не заползал...
-
Насколько я в курсе, для всех, кроме старых IE (IE8 — с жестким ограничением).
-
В целом да, GIF уходит. Он выигрывает на совсем малюсеньких иконках и двух-трехцветных полосках, а такие вещи сейчас всё больше уступают дорогу спрайтам. Минимизировать надо всегда. Причем и размер, и количество запросов к серверу (количество разных картинок). Конечно, в разумных рамках — тратить полдня на ужимание двух килобайт до полутора явно излишне . Но вот с 200-килобайтными (и более) дизайнерскими изысками очень даже есть смысл поэкспериментировать...
-
В новых браузерах можно как-нибудь так и даже так. В старых, да, без скрипта никак. Но хотелось бы уточнить — переключение вкладок должно идти без перезагрузки страницы?
-
<offtop> Как минимум, FF4+, Хроме 7+ и Опере 12+ И вообще другого HTML в реальном мире как бы и не бывает... </offtop>
-
Доктайп лучше ставить сразу взрослый, <!DOCTYPE html> (всё равно до валидности этой верстке далековато), но не в этом суть. А что в #top-table видны только верхние 118px контента - так это логично и естественно, вы ж сами это заказали в стр. 101-102 CSS-файла. Отлаживайте. Для начала уберите все overflow:hidden, чтобы просто увидеть контент - куда его разбросает по стандартам. И зачем столько раз height: 100%? Вообще, конечно, отлаживать это трудно - слишком много избыточного хлама. Может, самое время набраться смелости и действительно сверстать это дивами?
-
Для начала доктайп поставьте, чтобы перевести браузеры из XX века в XXI. И при беглом просмотре вашей верстки у меня сложилось впечатление, что основа у нее табличная, а роль дивов сведена к навешиванию круголков (для чего вообще-то существует border-radius)...
-
У вас по факту любой IE — пятый. Потому и не понимает элементарного. пардон, где?
-
По-моему, IE7 с его жалкими 4% аудитории по Рунету обойдется и тем, если главные пункты будут пронумерованы, а вложенные — лишь маркированы буллетами. Доступность информации от этого, имхо, не пострадает...
-
Нет там никакого канваса. Обычная элементарщина типа такой, только вместо закругления бордер-радиусом круг сделан нагромождением дивов.
-
Вот именно, что проще для кодера (как быть бедному браузеру при попытке вложить абзац в абзац, падать с ошибкой валидации или изворачиваться в узел, но строить требуемое - другой вопрос). А то многие часто HTML ругают за простоту...
-
Забавно, давно я там на первой странице не был, однако (привык, что спеки лежат в w3.org/TR/язык, сразу это и вводил...). А сейчас попробовал и в два клика (по "Web Design and Applications", потом по "HTML & CSS") попал сюда, а там справа внизу такое... Например, если ввести в "Lookup in HTML, CSS, SVG, XPath" многострадальный P (оно, кстати, подсказывает, что еще знает на эту букву), получаем буквально следующее: И клик по ссылкокнопке "Спецификация" приводит к просветлению:
-
В "беличьем" генераторе есть выборка диапазона символов. Возможно, по умолчанию оно ограничивает его латиницей и/или однобайтными символами UTF-8. Включайте галку "Expert", там, по идее, можно выбрать диапазон вручную.
-
В общем, попробую подвести промежуточные итоги беседы. Риски от опускания закрывающих тегов сводятся к следующим: для верстальщика: Трудность определения границ блока в редакторе с подсветкой; Возможные трудности при ручном преобразовании кода в XML-формат (без автоматизации); для программиста: Необходимость использовать более сложные/медленные инструменты для автоматического разбора. Вторая проблема кажется мне малоактуальной при серьезном подходе к разработке, с учетом падения популярности XHTML на фоне роста HTML5. Учитывая, что при парсинге чужих страниц этого всё равно трудно избежать, а собственные нечасто приходится парсить после вывода, последняя проблема тоже кажется мне чуть преувеличенной. Но надо смотреть по ситуации. А проблем с отображением ("верстка разлезется") от осознанного использования неявного закрытия тегов нет. Если проблемы возникают, то не из-за тегов, а из-за "человеческого фактора" (некомпететность др. разработчиков и т.п.), и точно так же возможны и при явном, но бездумном закрытии. Мораль же в этой басне такова: (не)обязательность закрытия тегов не избавляет от обязанности читать спецификации!
-
Итак, миф о "якобы неприлично низком пороге вхождения в HTML" опровергнут Правда, я не знаю, что архисложного, например, в этой таблице... и что мешает логически мыслящему человеку, увидев в ней пометку "End tag: Optional", элементарно полюбопытствовать "раз элемент закрывается не только закр. тегом, то чем еще он может закрываться?" и кликнуть по ссылке, чтобы найти ответ. Но это тема для отдельного холиво исследования...
-
Добавить right:0 (впридачу к left) для #menu li ul?
-
Последний пример не в кассу, у последнего правила тупо специфичность выше . А первый, имхо, как раз иллюстрирует мой главный тезис — лень заглянуть в спеку (посмотреть, при каких, очень четко обозначенных, условиях закрывается P) и оправдание этой лени "вредностью" и "плохим настроением" браузера ведут к проблемам и непоняткам независимо от того, закрыты теги явно или нет . Такова жизнь. А кто говорил, что будет легко? Каким бы низким порог ни был, без чтения спеки его не преодолеть, сколько слешей в <br> ни пихай...
-
Насколько я в курсе, z-index работает только для позиционированных (абс-но или отн-но) эл-тов...
