rash
User-
Posts
1,953 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Calendar
Store
Everything posted by rash
-
Псевдоклассы в inline-стиле оформить не получится.
-
Ну дело на мой взгляд не столько в качественном мануале, сколько в понимании природы и назначения тех или иных элементов. Использовать блоки для расположения элементов, а таблицы - для представления табличных данных это как забивать гвозди молотком и выкручивать шурупы отверткой - то есть это использование инструментов по назначению. Цитирую спецификацию: То есть эти элементы позволяют обобщенно организовывать структуру документа. Действительно, у нас пока нет специальных тегов для "шапки", боковой панели и "подвала". Поэтому мы можем использовать для этих целей универсальные средства. Таблица же должна содержать структурированную информацию. Разметка областей страницы структурированной информацией не является. Далее. Если мы используем для разметки блоки, то мы при желании (ну да, все не так легко как звучит) можем изменить их положение на странице, внеся изменения только в стили. Например, можем горизонтальное меню навигации под шапкой превратить в боковую панель. При этом изменения одного файла отразятся на оформлении всех необходимых страниц, что облегчает поддержку. Плюс ко всему, если браузер не применяет стили (некоторые виды браузеров обязаны их игнорировать), то контент пойдет на странице "потоком", а значит будет одинаково доступен на любом устройстве, от наладонника до проектора. Можно найти и другие преимущества использования блоков для разметки и таблиц для представления данных, но все они достигаются благодаря тому, что элементы применяются по назначению. Да, к сожалению бывают достаточно сложные макеты, где намного легче и быстрее разместить все в одной каркасной таблице, но в любом случае без крайней необходимости этого лучше избегать.
-
При сайтостроении используется и то и то - div - для разметки, table - для таблиц. Не потому, что меня так научили, а потому, что это правильно.
-
HTML Strict. При всех преимуществах XHTML, большинство из них пока не работают. Как известно, doctype в браузере влияет только на режим рендеринга. Режим парсинга переключается в зависимости от заголовка Content-Type. Если же всенародному браузеру IE передать заголовок application/xhtml+xml, то он отобразит дерево документа, а не сам документ в отформатированном виде, потому что XHTML-парсера в нем просто нет. Из-за этого другие браузеры воспользоваться преимуществами более быстрого и эффективного парсинга не могут. Тем более, что если строго следовать спецификации, браузер не должен отображать страницу, содержащую ошибки. То есть невозможно будет отобразить документ, пока он не будет загружен полностью. Идем дальше. Браузер пользуется HTML-парсером для XHTML-документа, в связи с чем вместо валидного XHTML он видит невалидный HTML! Проверьте сами - возьмите угодный валидатору XHTML-документ, измените у него доктайп на соответствующий HTML, чтобы заставить валидатор воспользоваться соответствующими правилами парсинга, и скормите документ снова. Посчитайте ошибки :-) Таким образом использовать XHTML следует только если вам действительно реально необходимы преимущества XML, например, вы собираетесь обрабатывать его как XML на сервере (хотя этому могут помешать нередкие ошибки, случайно вносимые серверными скриптами или пользователями, принимающими участие в наполнении). Или, например, если вы используете микроформаты, которые требуют XML-ности документа.
-
А по-моему человечнее писать "завтра", чем три цифры, которые еще нужно мысленно сопоставлять с текущей датой.
-
Мне только телнет в голову и пришел, но не слишком удобно, надо заметить -)
-
Браузер должен верить HTTP-заголовку, что и делает. Мета-тег должен вступать в силу только если сервер вообще не передает кодировку в заголовке. P.S: homm, а чем можно удобно посмотреть HTTP-заголовки?
-
Вот это и плохо - эти отступы должны быть, если изображения выравниваются так, как это положено по спецификации. То есть это не проблема, а нормальное поведение.
-
Просто меня немного смутило, что был задан этот вопрос. Ведь можно было сначала попробовать изменить код, а потом спросить, почему это помогает, а не поможет ли это вообще :-) Да, только в IE указание XML-декларации мешает переключению режима рендеринга в зависимости от doctype.
-
Да можно, можно, если нужно. Правда действительно контролировать списки со сложным оформлением может быть затруднительно. p { margin: 0; padding: 0; } браузеры воспримут нормально.
-
Дело в том, что изображение - это строчный элемент (inline), поэтому выравнивается в тексте он по правилам текста - то есть по базовой линии. Таким образом остается место, которое в тексте предусмотрено, например, для подстрочных элементов букв (у, р, ф...). Блочные элементы этого места не резервируют. В принципе, проблема также решается указанием vertical-align: bottom, эффект тот же, но установить блочное отображение иногда просто удобнее.
-
А я не согласен. Точнее, контролировать, конечно, можно, но незачем. Если вам нужно несколько ссылок на странице с нестандартным подчеркиванием/типом подчеркивания/цветом подчеркивания/толщиной подчеркивания - укажите класс для них. Существенно менять оформление по-умолчанию не нужно. Или если очень уж хочется заняться чем-нибудь бесполезным - указывайте класс для ссылок с изображениями.
-
так border-то не у img а у самой ссылки <a>...
-
Использовать underline - вот выход. С чем связаны рекомендации использовать border? Ну или задавать ссылкам-изображениям отдельный класс, что не так удобно.
-
Да, это поможет.
-
Тормозами как минимум.
-
Подсказываю - не делайте этого. Зачем наряжать сайт как клоуна?
-
Не мешайте посетителю пользоваться страницей.
-
Уберите XML-декларацию. <?xml version="1.0" encoding="windows-1251"?>
-
Не надо так категорично :-) А тем более, если лабораторная - то любят проверять умение работать с фреймами судя по всему только потому, что фреймы вообще существуют. Хорошо это или плохо - никого не интересует.
-
Да все вроде уже давно поняли -)
-
Выполняю верстку макетов в соответствии с вашими требованиями. HTML/XHTML + CSS. Высокая скорость не гарантируется (не основное занятие), недорого. Обращаться в личном сообщении на форуме или по электропочте w.smmurf(at)gmail.com
-
2 Кб - абсурд. Зачем нужна отдельная страница, если а ней будет 2 Кб информации (даже без разметки).
-
На мой взгляд имеет существенное значение, презентационный ли сайт рассмартивается, или информационный. Презентационный промо-сайт может весить до 5-7 Мб, его задача - привлечь внимание. Информационный же, на мой взгляд, чем меньше - тем лучше. Его задача - предоставить информацию. Быстро и доступно.