SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Доктайп нужен, самый короткий <!DOCTYPE html>, с ним поведение браузеров гораздо единообразнее. А вот масштабировать картинки с текстом (задавать им ширину в процентах) — очень плохая идея. Что вообще мешает делать меню текстом, подложив фон-градиент под всю полосу? И еще пустяк — дробные проценты для ширины до сих пор не понимает Опера.
-
Имхо, что-то из этого ряда (они до некоторой степени взаимозаменяемы). Очень модный шрифт в сезоне 2010/2011, по моим наблюдениям
-
Новые браузеры умеют рисовать box-shadow:inset..., им картинка вообще не нужна, имхо. А для старых IE действительно можно сделать одну картинку-рамку (из фонового цвета по краям в полную прозрачность в центре) и положить ее поверх целевой картинки через filter:alphaImageLoader с параметром <чего-то там> scale...
-
100 чего, копать-насыпать? И если окно 80% — половина излишка разве не 10% будет? P.S.:
-
Если ширина картинки и блока фиксирована, можно еще сделать через inline-block, типа такого.
-
А вот он очень даже причем . В чистейшем виде (один из самых неочевидных случаев).
-
ceil100, а что общего у отступов и бордеров?
-
Интуиция (здравый смысл) и стандарты CSS1-2 редко идут рядом А его никто и не поминал
-
Во втором варианте используется плагин для jQ. И вы буквально так и пишете — "YourForm"?
-
Тогда, как вариант — таки задать text-align: right всему, а первых 4 обернуть в общий контейнер и ему задать float:left Мможно и пятому float. Но в старых браузерах (типа FF3 и его современников), насколько помню, такие элементы имели обыкновение "подныривать" под строчку...
-
http://softwaremaniacs.org/blog/2005/09/05/css-layout-flow-margins/
-
Зависит от специфики проекта. Главных проблем с новыми структурным тегами две — старые браузеры воспринимают их как аналог <span>, а IE ниже 9-го стилизует только после применения JS-костыля. Поэтому для информационных сайтов, рассчитанных на максимальную доступность — пожалуй, и вправду лучше не надо. А если функциональность сайта так или иначе всё равно завязана на JS — то почему бы и не применить. И всегда есть временный компромисс, предложенный Майком Робинсоном — использовать новые теги чисто для логического деления документа (как в старину комменты а-ля <!-- Here goes the footer --> и т.п.), а визуальный каркас строить по-старинке на дивах. Кстати, с мобильными браузерами парадоксально проблем меньше (сейчас там преобладают браузеры на новых движках). А type для скриптов и стилей просто не обязателен (отсутствие равносильно дефолтным значениям "text/javascript" и "text/css" соотв-но). На мой взгляд, если без чего-то можно обойтись без вреда для дела — лучше обойтись, но если кто-то привык всегда указывать "ради порядка" — это тоже правильно. Новый стандарт стремится фокусироваться на логической структуре, а не нюансах оформления кода.
-
HTML5 — это продолжение и расширение как HTML4.01, так и XHTML1.x. Собственно, они и раньше различались по сути только синтаксисом, а в HTML5 "синтаксис — ничто, семантика — всё", и их пути снова сошлись. При text/html равно правильны оба синтаксиса. И application/xhtml+xml в HTML5 сохранен (причем доктайп там вообще не нужен!). Больше того, новые браузеры (Хром 7+, FF4+, вот-вот выходящая Опера 12) вообще не знают никакого другого HTML, кроме HTML5 (без разницы, что там где в доктайпе написано). Так что, независимо от формального утверждения стандарта академической тусовкой, индустрия в целом выбор сделала. Единственная проблема — валидация. Небольшие "косметические" изменения в спеке еще бывают, допустимые значения атрибутов добавляют/удаляют (теги — имхо, уже вряд ли), поэтому вчера валидная страница может завтра стать вдруг чуть-чуть невалидной. Но это касается новых экспериментальных вещей, то, что уже работает в >2 браузерах, работать вряд ли перестанет. А вообще новый стандарт специально построен так, что валидная страница XHTML 1.0 Strict, скорее всего, также будет валидной HTML5-страницей (с точностью до доктайпа и пары-тройки атрибутов). Только с HTML5 можно не бояться, что валидация идет по одним правилам, а реальный разбор в браузерах — по совсем другим.
-
В CSS 2.1 есть такая фишка. Но IE7 (и ниже) как всегда.
-
Расширение важно только при открытии файла локально, на хостинге всё определяется настройками сервера. В PHP можно выдавать любой Content-type из самого скрипта, при любом расширении, с которым php на данном сервере вообще работает (вот пара примеров кода). Только надо ли это всё на самом деле, если использование главных преимуществ XHTML (интеграция с др. неймспейсами и т.п.), насколько я понимаю, не планируется?
-
Ой, трехэтажный релатив во всю площадь, да еще z-индексы взад-вперед скачут... имхо, да, здесь оно излишне. Ну и, имхо, чем меньше площадь, занятая под спецэффекты (пусть даже их основная масса в итоге остается "за кадром"), тем быстрее и надежнее. Не стоит множить сущности без крайней необходимости, как завещал дядька Оккам
-
По факту (и абстрагируясь от мелочей) — да.
-
Очень рекомендую вот этот цикл статей (несмотря на их приличный возраст, почти всё актуально, с этой статьей для полноты картины). И еще у Transitional-доктайпов при text/html есть подводный камень — они включают в браузерах "почти стандартный" режим (вместо стандартного), что, в частности, чревато глюками с inline-block в Опере.
-
Не обязательно "псевдо". Какие-нибудь рекламные плашки, на которые должны частично налезать другие элементы... заголовки типа той раириной бабочки, в конце концов . А "выше со статьями" — сорри, кажется, я вообще не в теме, это где именно?
-
Знаю железные грабли — body в FF2 (и ниже) . Но они вроде как уже несколько лет неактуальны. Основания для настороженности всё равно есть. Вон я недавно пытался оптимизировать заголовок-ленту, сэкономив один псевдоэлемент — везде ожидаемо, а в IE8 сюрприз (в обратную сторону — не хочет, бяка, "нырять" под фон родителя). Ну и вообще z-ы такие ребята капризные, особенно когда position у предка по ходу редактирования может быть то static, то relative, то absolute — везде свои нюансы, и это еще не считая "особенностей" IE7 . Для основного контента блока я бы не ставил без крайней на то необходимости. А для вспомогательных элементов, когда проблемные браузеры отсекаются по др. критериям (напр. фактом неподдержки теней), а охваченные отображают единообразно и в соответствии со спекой — отчего бы и не поюзать, в порядке "прогрессивного улучшения"?
-
Формально по спеке это допустимо (хотя и не сильно желательно, только на правах вынужденного разумного компромисса). Практически вопрос скорее такой: "Нужен ли index'у.html доктайп <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0... и далее по тексту?" — и он, как правило, риторический
-
А мне идея насчет тени понравилась! Как насчет такого варианта? Текст выделяется везде, включая IE9. Для IE8, по идее, можно допилить через filter:glow в кондкомах, а еще более старые обойдутся...
-
Мета ни при чем, она может влиять только на кодировку (и то если перед ней <title> не затесался). На режим парсинга влияет только серверный заголовок ответа (определяется настройками сервера, в PHP можно явно добавить с помощьью ф-ции header, в др. серверных языках есть свои аналоги), еще до отправки разметки браузеру. При открытии файла локально играет роль расширение (.xhtml обычно открывается по XML-правилам). Но в 99% случаев это не нужно, т.к. IE8 и ниже полноценного XHTML не понимают, совсем. Приходится либо выдавать разный Content-type в зависимости от заголовков запроса (в первую очередь Accept) и гарантировать, чтобы код был валиден как XHTML и хотя бы приемлем как HTML (впридачу к валидатору самому следить за соблюдением "приложения C", чтобы не было никаких <div /> и т.п.), либо вовсе отказываться от XHTML. Всё равно самые "вкусные" его преимущества не оправдались, а самые значимые понемногу влились и в HTML5...
-
В теории, для этих целей есть специально обученный символ , он же ­ или U+00AD ("мягкий перенос", "мягкий дефис"). Правда, не все браузеры адекватно обрабатывают этот символ при копировании в буфер (у С. Чикуёнка в комментах пробегало, что есть различие между обработкой мненмоники и чисто юникодного символа, кому-нибудь другому я бы не поверил, но тут... видно, придется экспериментировать). Есть еще вот такой остроумный подход (черточки там пририсовываются стилями ко всем слогам, кроме последних, но при отсутствии переноса закрываются следущим слогом). А чтобы просто вставить место для разрыва длинной сплошной строки, достаточно пустого <span> с display:inline-block.
-
Формально это никаких правил не нарушает. Просто валидаторы — достаточно тупые программы, и, как хорошо заметил когда-то создатель AdBlock-а для FF, Когда на заборе (или в доктайпе) написано "X-что-то-там" — это еще не значит, что за забором (в браузере) будет именно это "X", пардон за каламбур . При Content-type: text/html любой контент для браузеров превращается в обычный HTML — будь он хоть трижды веллформным по XML, валидным по DTD и конформным по содержанию. Кстати, легендарная HTML-совместимость в XHTML 1.0 по факту держалась на честном слове и на том, что все браузеры плохо поддерживали SGML (а значит, и HTML4.x!)
