Comments 109
Если для себя, то уберите под кат и закройте запись.
И нет проблем.
И нет проблем.
кто бы что б ни говорил. СПАСИБО большое
display: inline-block; — не понимают только FF1.5 и FF2.?.. (вместо знака вопроса — неизвестное число)
конечно, стремлюсь к кроссбраузерности. Но в данном случае, увы, использую просто display: inline;…
А все потому-что я такой плохой. Ну привык я, что пользователи, знающие что такое Firefox или Opera обновят свой браузер… а рабочее время на все эти дела (IE6+O9.6x+FF3) не очень получается тратить, хотя ужасно интересно найти между ними компромисс…
Но я принял для себя стандарт… может он и плохой, но меня не подвел…
конечно, стремлюсь к кроссбраузерности. Но в данном случае, увы, использую просто display: inline;…
А все потому-что я такой плохой. Ну привык я, что пользователи, знающие что такое Firefox или Opera обновят свой браузер… а рабочее время на все эти дела (IE6+O9.6x+FF3) не очень получается тратить, хотя ужасно интересно найти между ними компромисс…
Но я принял для себя стандарт… может он и плохой, но меня не подвел…
UFO just landed and posted this here
Всегда приятно решить задачу без использования таблиц и с минимальными издержками. Стандарты это хорошо, но уж если выбирать между табличной разметкой и немного нестандартным CSS, я выберу второе.
С минимальными издержками это как раз таблица.
а решите завтро сделать вертикальное меню, и все перевёрствовать
Вы часто разбирались с чужими сайтами сверстанными таблицами???
Таблицы в html для того что бы выводить информацию соответствующего содержания. Вы то возможно и помните где какую таблицу с каким идентификатором используете, а вот для других людей верстка в DIV-ах будет выглядеть естественнее, понятнее (ну не пустое это слово семантика!!!).
К тому же, верстка DIV-ми проще. Это ведь охренеть можно потом прилаживать табличное горизонтальное меню к телу сайта, если оно (тело) имеет боковые границы. Возможно что сейчас это проблемы нет, но когда-то я тратил на это время и нервы. :(
Таблицы в html для того что бы выводить информацию соответствующего содержания. Вы то возможно и помните где какую таблицу с каким идентификатором используете, а вот для других людей верстка в DIV-ах будет выглядеть естественнее, понятнее (ну не пустое это слово семантика!!!).
К тому же, верстка DIV-ми проще. Это ведь охренеть можно потом прилаживать табличное горизонтальное меню к телу сайта, если оно (тело) имеет боковые границы. Возможно что сейчас это проблемы нет, но когда-то я тратил на это время и нервы. :(
А как сочетаются div и непустое слово «семантика»?
UFO just landed and posted this here
Эм… Кажется вы написали скрипт-автоотвечалку на комментарии в которых встречаются слова «div» и «семантика».
Хорошо поясню еще раз. Верстка таблицами была оправдана когда:
1) по-другому просто нельзя было сделать
2) все стили были прописаны непосредственно в html документе
Не знаю как вас, но меня таблицы в чужих документах вводят в некоторый ступор. В лучшем случае верстальщик назначает элементам таблицы, которые имеют исключительно визуальное назначение, понятные идентификаторы отражающие цель использования этого элемента. В худшем случае верстальщик-оптимизатор добавляет к этим элементам класс из 2-х букв. С учетом того, что таблица используется не только для визуального оформления (в ней так же содержаться тексты, картинки и т.д.) часто бывает сложно понять где и для чего верстальщик использует элементы таблицы (тут у него просто пустая строка или это строка с каким-нибудь красивым визуальным разделителем? это пустая ячейка, которая заполнена в следующей строке или это контейнер для какого-нибудь элемента дизайна?).
Уверяю вас — я не тупой! Просто откройте чужой документ с табличной версткой и попробуйте разобраться в нем без inspect html. А теперь представьте, что вам в этом документе не пару слов с картинкой поменять, а сделать что-нибудь посерьезнее.
Разобраться иногда бывает достаточно сложно, но главное, сколько времени из-за этого отнимает плевая работа.
С DIV-ой версткой разбираться проще. Ну типо не надо представлять себе всегда всю структуру целиком, если код семантичный, то тексты все равно оформляются соответствующими тегами и DIV-ы выступают только в роди контейнеров. К тому же, верстая сайт таблицей вы из-за красивого хедера можете ввести таблицу из 12 колонок, когда сам контент потребует от 2 до 4, вот и появятся пустые элементами с разными colspan в которых кому-то потом придется разбираться.
DIV-ая верста более понятная, более естественная поэтому и «сочетается div и не пустое слово сематика».
Возможно вас покоробил мой тон? Уверяю вас, я не фанат блочной верстки, я — фанат быстро и качественно выполненной работы, за которую платят деньги. Именно по этому я и напирал на слово НЕПУСТОЕ.
Хорошо поясню еще раз. Верстка таблицами была оправдана когда:
1) по-другому просто нельзя было сделать
2) все стили были прописаны непосредственно в html документе
Не знаю как вас, но меня таблицы в чужих документах вводят в некоторый ступор. В лучшем случае верстальщик назначает элементам таблицы, которые имеют исключительно визуальное назначение, понятные идентификаторы отражающие цель использования этого элемента. В худшем случае верстальщик-оптимизатор добавляет к этим элементам класс из 2-х букв. С учетом того, что таблица используется не только для визуального оформления (в ней так же содержаться тексты, картинки и т.д.) часто бывает сложно понять где и для чего верстальщик использует элементы таблицы (тут у него просто пустая строка или это строка с каким-нибудь красивым визуальным разделителем? это пустая ячейка, которая заполнена в следующей строке или это контейнер для какого-нибудь элемента дизайна?).
Уверяю вас — я не тупой! Просто откройте чужой документ с табличной версткой и попробуйте разобраться в нем без inspect html. А теперь представьте, что вам в этом документе не пару слов с картинкой поменять, а сделать что-нибудь посерьезнее.
Разобраться иногда бывает достаточно сложно, но главное, сколько времени из-за этого отнимает плевая работа.
С DIV-ой версткой разбираться проще. Ну типо не надо представлять себе всегда всю структуру целиком, если код семантичный, то тексты все равно оформляются соответствующими тегами и DIV-ы выступают только в роди контейнеров. К тому же, верстая сайт таблицей вы из-за красивого хедера можете ввести таблицу из 12 колонок, когда сам контент потребует от 2 до 4, вот и появятся пустые элементами с разными colspan в которых кому-то потом придется разбираться.
DIV-ая верста более понятная, более естественная поэтому и «сочетается div и не пустое слово сематика».
Возможно вас покоробил мой тон? Уверяю вас, я не фанат блочной верстки, я — фанат быстро и качественно выполненной работы, за которую платят деньги. Именно по этому я и напирал на слово НЕПУСТОЕ.
Поддержка такого кода будет исключительно занимательным процессом. А это — существенная часть издержек.
Как раз таки у таблицы квадратные колёса из-за несемантичности.
Семантичность эфемерна.
Проходящая или несуществующая? Первой она врядли будет — из модной, но практически бесполезной фичи семантичность превратится в один из неотъемлемых частей веб-документов.
Привет!
Я против холиварсов, но здесь, кроме навигации, есть и другое применение: вывод картинок, например. Мне их не всегда удобно выводить таблицами. То же самое с навигацией и другими объектами.
Так что предлагаю всем верстать так, кому как удобнее и интереснее.
А семантичоесть — она да, скорее эфемерна.
Тут, как всегда, всё зависит от задачи.
Я против холиварсов, но здесь, кроме навигации, есть и другое применение: вывод картинок, например. Мне их не всегда удобно выводить таблицами. То же самое с навигацией и другими объектами.
Так что предлагаю всем верстать так, кому как удобнее и интереснее.
А семантичоесть — она да, скорее эфемерна.
Тут, как всегда, всё зависит от задачи.
Кто вам такое сказал? Таблица — это семантичный код. Читайте Зельдмана.
Таблица семантична для табличных данных. Для списков есть ul/ol.
А что есть для меню?
Смотря что из себя представляет меню. Обычно это список, но, например, таблица стоимостей различных продуктов со ссылками на их описание — меню-таблица. Но использовать таблицу для списков — или незнание (CSS), или нежелание знать, или просто «надоело париться с этими селекторами и прочей лабуденью». По себе знаю.
Допустим. А если надо сверстать меню, которое еще и будет на несколько строчек разделяться при растяге страницы? Кажется тут таблицы облажаются…
Гады, заминусовали последнего рыцаря табличной верстки!
а display:-moz-inline-grid; хорошо себя ведёт? не праказничает если туда разные всякие блоки вставить? с float, например?
UFO just landed and posted this here
Что вы думаете об этом способе? www.mauzon.com/?p=87 (кроме того, что там 2 «лишних» дива-обертки).
UFO just landed and posted this here
Думаю те кто пользуется FF уже давно скачал FF3. Кстати интересна статистика на этот счет. Особенно процент FF2.
Да никто и не говорил, что способ идеально подходит для меню. До опытов с динамическим меня я даже не доходил :)
В принципе, я искал решение для группы картинок, которые должны центрироваться внутри родителя и без проблем переноситься на другую строку, если не вписываются по ширине в оставшееся пространство.
В принципе, я искал решение для группы картинок, которые должны центрироваться внутри родителя и без проблем переноситься на другую строку, если не вписываются по ширине в оставшееся пространство.
Коммент для общественности по поводу @-moz-document. Мозилла предлагает собственный @-rule преимущественно для user style sheets. Использовать это правило для Mozilla specific CSS — интересное решение.
По поводу того, что CSS невалиден могу сказать так — валидация кода нужна для выявления потенциальных ошибок, узких мест. Валидатор — не искусственный интеллект, и он не может знать, что какой-то браузер создал собственное решение для обхода своих же недостатков. Однако это свое решение не узкое место (почти) и не ошибка. Так что к невалидности в таких случаях можно относиться демократично.
По поводу того, что CSS невалиден могу сказать так — валидация кода нужна для выявления потенциальных ошибок, узких мест. Валидатор — не искусственный интеллект, и он не может знать, что какой-то браузер создал собственное решение для обхода своих же недостатков. Однако это свое решение не узкое место (почти) и не ошибка. Так что к невалидности в таких случаях можно относиться демократично.
еще одно но
если нужно будет задать ширину*высоту для элементов списка — она не будет работать в ИЕ — так как элементы обозначены как inline
если нужно будет задать ширину*высоту для элементов списка — она не будет работать в ИЕ — так как элементы обозначены как inline
В MSIE isplay: inline ведёт себя как inline-block.
как бы я хотел чтобы так оно и было :) но к сожалению это не так.
Вот наглядный пример того о чем я говорю:
Вот наглядный пример того о чем я говорю:
- hello
- hello
извиняюсь, поспешил написать… вот он, пример:
<ul>
<li style="display:inline;width:200px;background:#9C6">hello</li>
<li style="display:inline-block;width:200px;background:#6CF">hello</li>
</ul>
<ul>
<li style="display:inline;width:200px;background:#9C6">hello</li>
<li style="display:inline-block;width:200px;background:#6CF">hello</li>
</ul>
Да, но при условии, что у элемента врублен hasLayout
UFO just landed and posted this here
Что сложного, заменить float:left; на display:inline;? И стоят эти стили в одном месте. И результат почти один и тот же… Только inline дает больше возможностей в расположении. Любой верстальщик должен это знать!
Че-то больно вы дохрена кода ненужного наворотили. Достаточно написать:
И для IE:
#content LI {
display:-moz-inline-grid;
display:inline-block;
margin:0 -2px;
vertical-align:top;
}
И для IE:
<!--[if lte IE 7]>
<style type="text/css">
#content LI {
display:inline;
margin:0;
}
</style>
<![endif]-->
тогда уже вот так:
#content LI {
display:-moz-inline-grid;
display:inline-block;
margin:0 -2px;
vertical-align:top;
}
* html #content LI {display:inline;margin:0;}
#content LI {
display:-moz-inline-grid;
display:inline-block;
margin:0 -2px;
vertical-align:top;
}
* html #content LI {display:inline;margin:0;}
Да это все из-за двух пиксельного отступа между строчными блоками. Просто хотелось чтоб без него :)
Так и будет без него. (Кстати, для IE еще не мешало бы hasLayout врубить, а то некоторые блочные свойства не будут работать).
Я с недавних пор пользуюсь JS скриптом что посоветовал тут на хабре один парень — этот JS идентифицирует броузер и операционную систему и добавляет соответствующий класс для тега body, оказалось невероятно гибко и удобно. Если ранее нужно было делать отдельно файл стилей для ие, как то их цеплять, правила что там как исключения прописывали были оторваны от основного файла что все осложняло в последующем редактировании, поиске правил и все такое.
Сейчас у меня все проблемы ушли. Можно прописать правило для любого браузера используя лишь уникальный класс.
Пример:
div#header {
height: 93px;
position: relative;
background: red;
}
.win.ie6 div#header {
height: 94px;
}
Сейчас у меня все проблемы ушли. Можно прописать правило для любого браузера используя лишь уникальный класс.
Пример:
div#header {
height: 93px;
position: relative;
background: red;
}
.win.ie6 div#header {
height: 94px;
}
Ага, а потом вырубить JS и ужаснуться. Нет уж, только CC.
UFO just landed and posted this here
Я живу в реальном мире, где до сих пор самый распространенный браузер IE, самое распространенное разрешение экрана — 1024x768, и где до сих пор существуют тысячи пользователей с выключенным JS. И мне важно, чтобы сайт нормально функционировал как с JS так и без него. А фиксить визуальное отображение элементов при помощи JS, когда есть альтернативный способ без JS, вообще считаю глупостью. Особенно таким способом, когда браузер определяется путем парсинга свойства userAgent.
Это не должно мешать продумывать «пути отступления».
Половина сайтов захлебнется моментально еще и из-за глупости разрабов, которые забыли, например, к зааяксенным добавить прямые ссылки на отдельные страницы — но это издевательство, особенно, учитывая то, что не всегда дожидаешься загрузки монструозных js-ов. А еще есть NoScript — для параноиков безопасности.
Половина сайтов захлебнется моментально еще и из-за глупости разрабов, которые забыли, например, к зааяксенным добавить прямые ссылки на отдельные страницы — но это издевательство, особенно, учитывая то, что не всегда дожидаешься загрузки монструозных js-ов. А еще есть NoScript — для параноиков безопасности.
ну если так мыслить то и картинки нужно отключить, и моник ЧБ 10''. Я лично пока еще не встречал людей отключающих JS. 99% всех пользователей не знают что это такое даже.
Потому я не переживаю.
Потому я не переживаю.
ставить js-script в body — неэстетично, а если добавлять свойство восле загрузки в dom — появляются прыжки. Тоже некрасиво. Ну и вообще лишнее это.
О, мои CSS-хаки пошли в народ :)
UFO just landed and posted this here
На первый взгляд ничем не отличается от этого:
www.brunildo.org/test/ImgThumbIB.html
www.brunildo.org/test/ImgThumbIB.html
UFO just landed and posted this here
ну-да, я не совсем верную ссылку дал. Вот соседняя: www.brunildo.org/test/ImgThumbIBL.html
Должно работать везде.
Должно работать везде.
Метод Токмакова можно улучшить, если клиринг использовать не :after {content:'' и т.д.} а overflow:auto для блока, относительно которого центрируешь. Хотя один лишний див все-таки остается, да.
<style type="text/css">
.align_center {
position: relative;
width: 100%;
overflow:auto;
}
.align_center_to_left {
position: relative;
right: 50%;
float: right;
}
.align_center_to_right {
position: relative;
z-index: 1;
right: -50%;
}
</style>
<div class="align_center" style="border: 1px dashed red; color: red;">
Выравниваем относительно этого блока.
<div class="align_center_to_left">
<div class="align_center_to_right" style="margin: 1em 0; border: 1px dashed green; color: green;">
Ширина блока зависит от размера надписи.
</div>
</div>
</div>
habrahabr.ru/blogs/css/49756/#comment_1306540 «метод Токмакова»
а ссылка на сам метод есть в теле поста какбэ
Еще, автор, если Вам не сложно, может быть обновите пост с наиболее интересными вариантами, предложенными в комментариях?
Firefox 2.0.0.20 users offered a free upgrade!
Earlier this month, Mozilla offered an update for all Firefox 2.0.0.20 users — a free upgrade to Firefox 3.0.5, the very latest and best browser from Mozilla offering more speed, requiring less memory, and providing the safest and easiest web browsing experience available.
Firefox 2 users last received a “major update” in December, prior to the final release of Firefox 2. As of this point, Mozilla will no longer be actively issuing security and stability updates to Firefox 2. Additionally, Firefox 2 will no longer have Phishing Protection as of January 20.
We strongly recommend that our users upgrade to Firefox 3.
поэтому думаю насчет ff2 заморачиваться более не стоит!
Earlier this month, Mozilla offered an update for all Firefox 2.0.0.20 users — a free upgrade to Firefox 3.0.5, the very latest and best browser from Mozilla offering more speed, requiring less memory, and providing the safest and easiest web browsing experience available.
Firefox 2 users last received a “major update” in December, prior to the final release of Firefox 2. As of this point, Mozilla will no longer be actively issuing security and stability updates to Firefox 2. Additionally, Firefox 2 will no longer have Phishing Protection as of January 20.
We strongly recommend that our users upgrade to Firefox 3.
поэтому думаю насчет ff2 заморачиваться более не стоит!
Firefox'a 2 осталось всего 3 процента. Я думаю, не стоит и заморачиваться. Тем более, эти -moz-inline-ххххх подглючивают неплохо так.
попробовал ваш вариант… в моём случае он не подошёл… как-то странно себя повели элементы внутри этого -moz-inline-grid. мне больше по душе -moz-inline-box, он более предсказуем и ближе к inline-block, как мне кажется… использую его не только для меню. всё это, конечно, ИМХО…
с -moz-inline-xxx ситуация такая, что нужно просто перебирать возможные значения (-moz-inline-grid, -moz-inline-stack, -moz-inline-box), они ведут себя по разному. Но, по моим наблюдениям, лучше всего себя ведет -moz-inline-stack. Также не мешает заключить то, что в элементе с -moz-inline-xxx в какой-нибудь блочный элемент, чаще всего это исправляет многие баги.
Вот решение основанное на display:table-cell для нормальных и display:inline с hasLayout для инвалидов;
Сегодня использовал в проекте; Работает в фф2/3, сафари3, опера 9.5, ие6/7, больше не тестил;
Сегодня использовал в проекте; Работает в фф2/3, сафари3, опера 9.5, ие6/7, больше не тестил;
<style type="text/css">
#header {
background:black;
font-size:1.4em;
}
#header a {
color:#fff;
}
#header div {
margin:0 auto;
display:table;
}
#mainmenu,#languages {
display:table-cell;
list-style:none;
}
#mainmenu li, #languages li {
float:left;
margin-left:0.3em;
}
</style>
<!--[if lt IE 8]>
<style type="text/css" media="all">
#header div {/* block with centered inline-blocks elements */
display: block;
text-align:center;
}
#mainmenu, #languages {/* setting blocks to be "inline-blocks" (display:inline with hasLayout)*/
display:inline;
zoom:1;
}
</style>
<![endif]-->
<div id="header">
<div>
<ul id="mainmenu">
<li>
<a href="#">Download</a>
</li>
<li>
<a href="#">Cashier</a>
</li>
<li>
<a href="#">About Us</a>
</li>
</ul>
<ul id="languages">
<li>
<a href="#">English</a>
</li>
<li>
<a href="#">FRANÇAIS</a>
</li>
<li>
<a href="#">Deutsch</a>
</li>
<li>
<a href="#">ESPAŇOL</a>
</li>
</ul>
</div>
</div>
Sign up to leave a comment.
Горизонтальное меню без float