SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Как разместить горизонтальную прокрутку сверху?
SelenIT replied to wildhind's question in HTML Coding
Вот так подойдет? -
Никаких сенсаций, всё по старинке... хотя на этом фоне позиционирование интеграции с SVG при text/html как мегафичи HTML5 тоже несколько умиляет .
-
Можно и не рассчитывать: left: 50%; margin-left: -<толщина_левого_бордера>px;
-
В FF9 и Опере 11.6 — работает. В IE9, к сожалению, по Back не переходит (плюс, изловчившись, после клика по Back можно открыть 2 вкладки одновременно — явный баг). Можно и из одного + экспрешны для старых IE. И еще один фончик добавить через :first-letter. А конкретно в IE (5+) круглые углы можно и вообще без CSS сделать Кстати, забавно, что text-overflow:ellipsis в IE6 тоже работает... такие вот у W3C теперь инновации
-
Чисто к элементу и правда одну, но с псевдоэлементами — уже минимум 5
-
С первым просто, со вторым — согласен с rash, с третьим тоже просто. Имхо, сильнее удивляют "открытия" в старом добром CSS 2.1 (например, сколько разных фоновых картинок можно применить для одного элемента?).
-
А зачем другие доктайпы? Вообще, "самозакрывающиеся" теги — "фишка" XML, и только XML. XML-парсеры понимают их так, как задумано, HTML-браузеры не понимают этих слешей вообще и просто игнорируют, поэтому в обоих случаях всё хорошо. Но W3C-шный валидатор для HTML4.x основан на полноценном SGML-парсере, а там этот слеш имеет совсем другое значение. Поэтому при заявленном доктайпе HTML4.x слеши ведут как минимум к неоднозначности. К счастью, у браузеров не полноценные SGML-парсеры, а упрощенные. А HTML5 по сути стандартизирует то, что в браузерах, поэтому ему эти слеши официально "по барабану"
-
Ох, рискуете... Впрочем, формулировку я уточнил, пост подправил. Не в любом случае они обязательны. Но вреда от них уж точно не бывает, а польза бывает при любом стандарте. То ему не место в (x)HTML-валидаторе
-
Для него, родимого. И для IE5 (ветка с document.body вместо document.documentElement). А по сабжу — скорее всего, это вообще не от сайта зависит, а от браузера. Так работает т.н. "адаптивный зум". В большинстве актуальных браузеров это по умолчанию, но слепо полагаться на это не стоит...
-
В чем совместимость-то? У IE при нормальном доктайпе уже 10 лет боксовая модель адекватна (если вынести за скобки странности хзлейаута). А такой дикости, как влияние на ширину вертикальных паддингов/бордеров, сколько себя помню (где-то с IE4.01), даже в нем не водилось...
-
Валидировать PHP-исходник — то же, что пробовать сырой котлетный фарш (не переперчен ли) оценивать качество котлет по вкусу сырого фарша. Валидируйте результат работы скрипта, который выдается браузеру. Хотя кавычки, да, нужны в любом случае
-
Хм, до сего дня я был уверен, что паддинги для таблицы должны игнорироваться, но в спеке про них написано "Applies to: all elements except table-row-group, table-header-group, table-footer-group, table-row, table-column-group and table-column", сама таблица в списке отсутствует, значит, к ней должны применяться. Но вертикальные паддинги бордеры и ширина уж точно пересекаться не должны...
-
В целом да, замещаемые элементы — вещь в себе. У браузеров бывают маленькие хитрости, помогающие их укротить (напр., псевдоэл-т ::-moz-focus-inner в мозилловых), но возня с ними еще та. Теоретически, с button-ами должно быть проще, на практике проблемы с ними почти те же...
-
У меня ширина верхнего блока на 20px больше, чем нижнего (16.0.912.63 m, Win 7 Pro 32b).
-
Насколько помню, Опера принимает только целое число пикселей.
-
Похоже, баг. Недавно на форуме уже всплывала похожая проблема, только там источником лишней ширины почему-то был верхний бордер. С паддингом, видимо, аналогично. Надо репортить, пусть фиксят... Upd. нашел свой пример, подтверждающий наличие проблемы с бордером: http://jsfiddle.net/6X42L/ (можно поменять толщину верхнего бордера и увидеть, как это тут же отражается на ширине, вопреки всякой логике, да и правый-левый бордеры действуют на ширину не так, как везде).
-
Насколько я понимаю, речь про php-шную функцию nl2br? С версии 5.3, как написано в доке, у нее есть опциональный второй параметр, по какому стандарту вставлять бряки. А вообще — используйте практичный доктайп <!DOCTYPE html> и абстрагируйтесь от всякой второстепенной синтаксической шелухи, лучше сосредоточьтесь на структуре и логике.
-
Имхо, можно, если в меру, последовательно и со вкусом.
-
Вовсе не обязательно. Обходится применением спрайтов. А вот в случае JS — только отдельным прелоадером.
-
Имхо, проще всего сделать такое на jQuery через .animate('height'), как-то так. А вообще новые браузеры и не такое умеют на чистом CSS...
-
font-family: 'стандартный шрифт', 'свой шрифт'
SelenIT replied to Cypher76's question in HTML Coding
По-моему, с теперешней распространенностью этих Калибрей (80-83% на виндах и 30-40% на маках) можно и не мучиться с вставкой их через @font-face (и потенциальными проблемами с лицензией), а просто поставить, например, font-family: Calibri, Candara, Segoe, "Segoe UI", Optima, Arial, sans-serif;(отсюда) или, на крайняк, собрать что-то подобное здесь. Без Калибрей, скорее всего, сидят бедолаги под XP на архаичном железе, им важнее прочитать хоть что-то, чем ждать загрузки немаленького шрифта... -
Моя версия, что бордер берется из-за неспособности Оперы сделать границу ячейки "кусочной" (возможно, издержки оптимизации). Поскольку в "пограничном конфликте" разделительной ячейки с верхними побеждает "1px solid #000" (т.к. none "слабее всех"), Опере приходится всю верхнюю границу разделительной ячейки делать такой. Баг ли это, затрудняюсь ответить. В спеке я правил разруливания "пограничных конфликтов" для заколспаненных ячеек не нашел, так что оперная трактовка, хоть и нелогична с точки зрения здравого смысла, вроде как никаких писаных правил не нарушает. Может, плохо смотрел... Впрочем, поведение Оперы при colspan="6" стыкуется с этой версией только если принять, что роль играет самая правая из соседних с заколспаненной ячейкой ячейка сверху (если у нее граница не задана, как в варианте без колспана, или самой "соседки сверху" нет, как при избыточном колспане, тогда и заколспаненной ячейке граница не задается). Тогда, видимо, всё-таки баг, потому что по спеке должна "заруливать" самая левая Лучший способ лечения для данного случая, имхо, предложил mishka. В идеальном мире я бы, наверное, вообще от этих распорочных tr-ок отказался (уж больно они напоминают бряки вместо абзацев, как-нибудь так (и в Опере, кстати, работает, и даже в IE8, но на этот раз вебкиты, сволочи, отвалились)...
-
В данном случае проблема не в регистре, а в глобальных переменных по каждому ID (которые IE заводит всегда, а FF — только в quirks mode, ЕМНИП). Правильно — document.getElementById('c1').style.display = ''; и далее по аналогии.
-
Отступы у параграфов — айс. Но параграфы (точнее, абзацы по-нашему), добавленные только для придания чему-то отступа (а не потому, что в них "законченная мысль") — не айс. Как и <blockquote> для горизонтального отступа, например. В X(HT)ML DOM строится строго по написанному, без "неявных" открытий/закрытий. А такая конструкция, хоть и невалидна, но веллформна, поэтому ошибки с "желтым экраном" не будет.
-
Насколько я понял, тут проблема в том, что height фиксирует высоту всех пунктов верхнего уровня — в т.ч. тех, у которых есть подпункты. И в итоге эти подпункты наезжают на нижестоящие главные пункты. Может, вместо height попробовать min-height использовать?
