troll
-
Posts
142 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Calendar
Store
Everything posted by troll
-
Смысл в разделении содержания и оформления. Когда надписи можно пересчитать по пальцам, то, возможно, вписать их в нужном регистре в документ на самом деле будет проще, но как быть, если вдруг понадобится оставить заглавной только первую букву? А если таких надписей несколько сотен? А если они хранятся в БД?
-
Я думаю, изображения следовало бы оформить средствами CSS. В вашей верстке получается, если понадобится вставить новую картинку, придется руками дорисовывать к ней поля и рамку. Надписи сплошными заглавными буквами я бы тоже через CSS сделал (через text-transform, как вариант) там, где это возможно. Форма поиска не работает.
-
К .hlink ul li a можно применить display: block, например.
-
А чем, позвольте узнать, не устроил display: inline-table или тот же float?
-
Это делается с помощью media queries. Удобство пользования, по-моему, только повышается, так как сайт нормально отображается на самых разных устройствах и разрешениях. А графика будет прыгать лишь при изменении размеров области просмотра, что в обычных условиях, согласитесь, происходит довольно редко.
-
Я имел в виду, что header не нужен для единственного заголовка, а про hgroup все верно вы написали.
-
Поправляю: http://html5doctor.com/avoiding-common-html5-mistakes/
-
По-моему, оба header'а в этом коде лишние.
-
Неплохо бы использовать заголовки разных уровней вместо того, чтобы вставлять все подряд в h1.
-
Он там не совсем однородный, при увеличении это видно более явно. Хотя может и в самом деле стоило без картинки сделать, если на глаз разницы нет?
-
Akaciya, спасибо за критику, попридираться даже нужно) Извините, я не понял, что это значит. Не могли бы вы пояснить подробнее? Вообще-то должны, конечно, но на макете их только 2 варианта, и я подумал, что будет не очень хорошо, если при наведении они будут становиться такими же, как активные. Я где-то читал (вроде бы в книге Влада Мержевича), что экономия достигается небольшая (по сравнению с картинкой шириной 15px), зато при скролле могут проявляться подтормаживания. Хотя для растягиваемых по горизонтали фонов это не актуально, наверное. Нет, хотел сделать колонки одинаковой высоты.
-
Прошу оценить верстку. Исходный материал - этот макет. Интересует информация про любые ошибки, кроме проблем отображения в IE6 и на больших разрешениях. Особенно хотелось бы узнать, почему различается ширина слоя content-wrapper в Opera и всех остальных браузерах, и как это исправить.
-
По-моему, в HTML5 у каждого раздела может быть собственный заголовок, поэтому не важно, сколько их в документе вообще. hgroup используется для группировки заголовков, соответственно, нет нужды его применять, если внутрь планируется поместить единственный элемент, так как группировать в таком случае просто-напросто нечего.
-
В первом варианте image.gif должен находиться на уровень выше в структуре каталогов, чем файл, в котором указывается данное правило. Во втором случае и файл с правилом, и изображение должны располагаться в одной папке. Вот здесь расписано подробнее. Кстати, почему второй вариант не должен проходить валидацию? Ведь кавычки с точки зрения спецификации опциональны?
-
Чтобы зафиксировать фон относительно области просмотра, используйте background-attachment: fixed и позиционируйте как вам заблагорассудится с помощью background-position (например, background-position: center).
-
Вы определитесь с шириной, 40px или 100%. Если 40px, можно так сделать: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="ru" xml:lang="ru"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>1</title> <style type="text/css"> .photo-block { position: relative; } .photo-prev, .photo-next { position: absolute; width: 40px; top: 0; bottom: 0; background: #000; color: white; } .photo-prev { left: 0; } .photo-next { right: 0; text-align: right;} .photo {margin: 0 40px 0; } </style> </head> <body> <div class="content"> <div class="photo-block"> <div class="photo-prev">«</div> <div class="photo-next">»</div> <div class="photo"><img src="5.png" /><div class="photo-title">photo 3</div></div> </div> </div> </body> </html>
-
Я не утверждал, что флоат может абсолютно позиционироваться. А то, что он выпадает из потока, написано в спецификации CSS 2.1, перевод отрывка которой и линк на оригинал приведены в сообщении #22. По ссылкам в вашем предыдущем посте находятся устаревшие или неполные тексты, поэтому части сведений там просто нет. Где найти актуальный русский вариант, я, к сожалению, не знаю. Кажется, я наконец-то понял ход ваших рассуждений. Хотя на практике поведение блоков и выглядит так, как вы описали, тем не менее, абсолютно позиционированным в спецификации называется только элемент, к которому применяется свойство position со значением abolute (или fixed). Потомки же его абсолютно позиционированными не считаются (с точки зрения терминологии). Надеюсь, таким образом, смысл, заложенный в утверждении стал яснее.
-
Правда? Ваши слова прямо противоречат спецификации, вы не находите?
-
JIyHa, вы неверно истолковали этот отрывок. position: absolute устанавливает float в none, из чего следует, что плавающий элемент не может быть позиционирован абсолютно. Корневой элемент - это html в HTML.
-
JIyHa, не все так однозначно. Надеюсь, вы простите мне кривости перевода: Источник
-
Да, стоит признать, я выразился неточно. Соседние элементы, конечно, влияют на положение флоатов, а вот каким образом и где этот момент разъясняется в спецификации... Внятные ответы на данные вопросы (главным образом на последний) пока, по-моему, не были сформулированы. Мнения разделились) Я лично склонен согласиться с вами, хотя бы потому, что флоаты в обычных обстоятельствах не оказывают влияния на следующие за ними блочные боксы нормального потока. Безусловно, для меня он обладает наивысшим авторитетом, но, к сожалению, не всегда знания позволяют полностью вникнуть в формулировки. Поэтому и прошу помощи сведущих людей на этом форуме.
-
И флоаты, и абсолюты выпадают из потока. Если это не так, приведите, пожалуйста, ссылку на авторитетный печатный источник или спецификацию, где об этом говорится. И то, что флоаты должны учитывать положение соседних элементов тоже, пожалуйста, подтвердите чем-либо, кроме собственных слов, если вас не затруднит. Не то чтобы я вам не верю, просто хочется получить четкую и цельную модель взаимодействия блоков, а не решето с кучей оговорок и допущений.
-
Я не понял) Пусть верхний блок в потоке, так ведь флоат-то - нет. Следовательно, на него должны действовать не обычные правила, а особые, отдельно определенные в спецификации. В частности, там указано 4 правила, управляющих вертикальным размещением: верх флоата не должен быть выше верха контейнера, верха предшествующих блоков, строк и флоатов, а также должен быть расположен максимально высоко с учетом указанных ограничений. Нигде не сказано (по крайней мере я не увидел), что верх флоата должен быть ниже низа предшествующего блока.
-
Именно во время чтения книги Мейера и возник вопрос, заданный в данном топике) Насколько я понял, флоат в описанном случае размещается так, как будто его родителем является анонимный блочный бокс. Поскольку кроме флоата, который вне потока, в боксе ничего нет, он должен иметь нулевую высоту и подпадать под правило о collapsed through margins. Но до меня так и не дошло, как это правило в действительности работает.
-
Болтается на каком расстоянии от блоков? Почему именно на таком? Повторюсь, меня интересует не взаимное расположение в каком-то конкретном случае (пример я привел просто чтобы было понятнее, о чем идет речь), а принцип размещения блоков.