SelenIT

А у ближайшего предка #content какая высота? Цепочка от html нигде не порвалась?

Мои имхи к последнему слову: 1) Если главное — взаимное расположение картинок (выше-ниже, левее-правее), неважно, догрузились они или нет, того размера или нет, а также при большой доле браузеров-динозавров в аудитории и/или вероятности использования верстки в HTML-рассылке — оправдана таблица; 2) Если главное — сами картинки (чтобы юзер смог увидеть их все, даже если зайдет с древнего мобильника с децильным экраном) — заведомо лучше блоки; 3) Если главное — попиксельное совпадение с макетом и точно-точно известно, что тут всегда будут именно эти 15 картинок именно этого размера именно с этой тенью и именно в этом порядке... то не будет ли лучшим вариантом (заведомо железобетонным и кроссбраузерным) так и вырезать их одной картинкой?

А вот так не годится?

Эх, ну на моем мониторе я четко вижу эти белые полоски и снаружи... неужели оптический обман? С уточнением, чтоб их не было, получилось почти то же самое, что выше, только на флоутах: http://jsfiddle.net/2hQ9D/6/ (зато обнулять font-size, убивая читаемость alt-текстов для случайно недогрузившихся картинок, не пришлось...) Кстати, mishka, в чем необходимость display:inline-block для img и отдельного inline для IE6? Разве img-шки не ведут себя как нужно (для этого случая) во всех браузерах (включая IE6-7) по умолчанию? Вроде убрал их — поведение не изменилось...

Насколько я понимаю табличную модель CSS, она состоит из иерархии специальных блоков, соответствующих иерархии html-таблицы (table/tbody/tr/td, в CSS это display:table/table-row-group/table-row/table-cell соотв-но). По спеке, недостающие блоки этой иерархии достраиваются неявно (т.е. если написать просто table-cell вне table-что-то, вокруг него создастся "виртуальная обертка" с table-row, вокруг нее — еще одна с table-row-group, и последняя с display:table, а если вложить display:table-cell напрямую в display:table — между ними окажутся две "виртуальные прослойки" с display:table-row-group и table-row). На практике браузеры иногда подглючивают при генерации этих оберток и прослоек (правда, чем дальше, тем меньше, но какие-то древние Оперы и FF требовали задавать прослойку с table-row явно, с тех пор у меня привычка подстраховываться...). А compatibility mode не включен случайно? В штатном режиме IE8 должен слушаться display:table(-*). Вот в режимах совместимости — увы, как и IE7-...

Нет, word-spacing и letter-spacing привязаны исключительно к font-size предка (ну и к font-family, строго говоря, но для практически всех популярных шрифтов пробел можно считать равным четверти кегля, кроме Верданы — в ней он равен трети). Менять придется только ширину родителя. Но речь-то шла о конкретной ситуации... Да и что сложнее: один раз пересчитать ширину и поправить 1 число, или менять сетку 24?5 в сетку 20?6 в "стене" из 120 картинок?

Списки и блоки-то тут причем? Карма тут испорчена исключительно у межсловных (междутеговых в данном случае) пробелов. У float-ов нет и этой проблемы (есть другая, с выпадением из потока, но это отдельный разговор). А с правильным доктайпом какие-то отступы придется гасить так или иначе: в случае таблиц — горизонтальные, под базовой линией (через display:block или vertical-align для картинок), в случае инлайн-блоков — вертикальные между элементами (при автоматической генерации кода, а галерею редко есть смысл ваять вручную, проще всего физически злополучные убрать пробелы)... Честно говоря, я увидел в примере не рамки, а разграничительные линии (?однопиксельные отступы) между картинками, и мой первый пример (тут) как раз это воспроизводил (не считая досадного бага в Хроме). Поэтому я и удивился, когда после зашел разговор о бордерах, и додумал, что нужны еще какие-то бордеры помимо этих разделительных линий... Но за недоразумение извиняюсь

Ну конечно очевидна, это ж чисто пример неограниченности фантазии . Не нравится с бордерами — вот без них... Упс. Был косячок в Хроме. Исправил (для вариантов как с бордерами, так и без).

Правильно, но никто не заставляет задавать каждой картинке все 4 бордера сразу...

Последнее время всё чаще в качестве "теста на семантичность" обращаюсь к дефолтным браузерным стилям. Всё-таки, как сейчас понимаю, не дураки их придумали. Если с отключенными стилями отображение чего-то в столбик с буллетами уместно (обычные меню, с натяжкой — небольшие облака тегов и т.п.), значит, и в коде списки для этого оправданы, если же нет (новости в ленте, картинки в большинстве галерей и т.п.) — то и нечего насиловать природу... А с бордерами никаких проблем — http://jsfiddle.net/RAYvE/

Самый простой пример гибкости — необходимость изменить кол-во колонок. В таблице придется передвигать </tr><tr>, в сплошной структуре не придется менять ничего, кроме одного-двух параметров в стилях... Вариант без таблиц и списков: http://jsfiddle.net/TeCcN/

А так? <div style="display:table-row"> <div style="border:1px solid;width:47px;display:table-cell;vertical-align:middle;"> <div style="display:block;background:green;width:45px;height:45px;"> </div> </div> <div style="border:1px solid;display:table-cell;vertical-align:middle;"> <a href="" style="vertical-align:middle;">sdfdsfsdf <br>fgjsd klj lk </a> </div> </div> Вся прелесть table-cell, что он позволяет ставить высоты соседних блоков в зависимость друг от друга, как у ячеек реальной таблицы. А если имитировать им ряд несвязанных таблиц (еще и плавающих впридачу), то понятно, что большого преимущества он не принесет...

В данном случае поддерживаю s0rr0w. Вертикальных связей, оправдывающих табличность, тут не найти даже с микроскопом, списочность... ну, можно притянуть за уши на таком же примерно основании, как обозвать любой текст списком составляющих его слов . А так обычный phrasing content, обычная строка инлайн-блоков (img-шки таковы по умолчанию), ограниченная по ширине. Увеличится размер картинок при той же ширине — уменьшится кол-во визуальных колонок, а смысл не изменится.

А я сегодня успешно отбил атаку зомби. Вот этого, на три буквы: КАК МНЕ ОТУЧИТЬ ICQ ЗОХВАТЫВАТЬ МОЙ ЛЮБИМЫЙ ПОИСК??? При том что сам ICQ Toolbar (доставшийся в наследство еще от предшественника по работе) я еще прошлой осенью вынес к чертовой родне. А вот от его поиска избавиться смог только сейчас. Реальный вирус какой-то оказался. Кроме шуток, влез мне в search.sqlite и прописался там раза 4 или 5, наверное (точно не считал, но не меньше трех — это точно). Только когда руками выкорчевал оттуда их все, этот неугомонный мертвец наконец утихомирился...

Или как-то так, без экспрешнов.

Метод простого перебора слишком медленный для большинства реальных задач, надо его оптимизировать изучением теории . Как минимум — просто запомнить, что html-парсеры (в отличие от XML) просто игнорируют слеши в любом месте, кроме как сразу после < (т.е. <span/> в HTML — то же, что и обычный незакрытый <span>). Кстати, JSfiddle даже сам подсвечивает теги (и форматирует код заодно), и разный цвет открывающего и "закрывающего" уже должен настораживать...

Согласен (хотя в простейшем случае, а-ля типичная форма логина, здравый смысл никак не ждет подвоха и от автоматики). Но у кнопок (и ссылок) хотя бы есть родной атрибут, куда этот табиндекс можно вставить, а у дивов (спанов, TT и пр.) нет и этого...

Это результат разбора по html5-правилам кода с "закрывающими" тегами вида <a/> и <ul/> . И еще, какого чипа-и-дейла уникальный идентификатор id="sidebar" повторяется у трех совсем разных элементов? Это как раз некритично. Хотя "закрыть, не открывая" — как-то неаккуратненько, не спорю.

Еще прямо тут в шапке над темой хороший совет:

Та же клавиатурная навигация. Довольно часто даже у меня при заполнении формы логина на автомате выходит такой паттерн: кликом ставлю фокус в поле логина, а дальше чисто клавиатура (набор - таб - набор - таб - энтер). Со штатной кнопкой проблемы не возникнет, со ссылкой на ее месте — скорей всего тоже (хотя под Оперой под вопросом), а вот с дивом вместо кнопки фокус может улететь с формы напрочь... Конечно, вернуть руку на мышку и "добить" форму кликом не проблема, но "осадок останется". Если кнопок несколько, всё еще малость нетривиальнее (у штатных кнопок есть всякие tabindex-ы c accesskey-ями, а с кастомными, насколько я могу судить, не обойтись без глобального мониторинга клавиатуры по всей странице)...

Неймспейсы имеют смысл только для application/xhtml+xml и валидны для него же. В validator.nu можно поставить галку "Be lax about HTTP Content-Type" и вручную выбрать XML-парсер. Только смысл валидировать страницы по одним правилам, а "на растерзание" парсерам отдавать по другим?.. Что за диковина "таблица css"?

Насколько я в курсе, не везде, да и не обязан по стандарту. По стандарту value, не завязанный на визуальную информацию, должен передавать как раз <button type="submit">, но тут нас, как обычно, преследует давнее огорченie... Имхо, то, что стандартные кнопки (как <input type="submit/reset/button">, так и аналогичные <button>) по дефолту выглядят и ведут себя (при наведении, нажатии, получении фокуса tab-ом и т.п.) как привычные юзеру кнопки его любимой среды — не баг, а мегафича, и горе-дизигнеров, которые покушаются на эту привычность ради псевдогламурных рюшечек, надо наказывать 15-ю сутками общественных работ под голым ДОСом . А главный недостаток эмуляции кнопок чем попало — то привычное и удобное поведение, которое для штатных кнопок получается само (тот же tab и т.п.), с такими заменами требует лишних и не всегда очевидных телодвижений в скриптах. Либо замена получается не такой уж полноценной. Поэтому я не согласен, что <input type="button"> — лишний элемент. Про варианты сабмит форм мои имхи таковы: <input type="submit"> — самый "железобетонный" вариант, работает везде и с любым кол-вом кнопок (когда в зависимости от нажатой кнопки форма выполняет разные действия), единственное противопоказание — дизайнерские заморочки; <button type="submit"> — в теории почти идеал, на практике в старых IE работает лишь для единственной кнопки и требует корявых хаков для стилизации в FF и вебкитных, поэтому оборачивается гемо... в смысле, потерянным временем; <input type="image"> — вообще-то сильно смахивает на пережиток старины, но на практике часто самый приемлемый компромисс между причудами дизайнера, надежностью формы и быстротой реализации. Лично мне еще нравится идея совмещения отправки с каптчей ("для отправки формы щелкните медвежонка по носу" и т.п.), тут как раз image в тему по его прямому назначению с координатами. Правда, хороших примеров реализации мне как-то не попадалось. Ну и мышкозависимость, конечно, минус... <whatever onclick="form.submit()"> — позволяет полностью ублажить дизайнера, но таит кучу подводных камней по части юзабилити. Еще мне нравится такой подход: по дефолту поставить самую тупую кнопку type="submit", а в процессе загрузки или по ondomready накрыть ее сверху гламурной кастомной. И скриптом отражать в кастомной кнопке состояние настоящей (напр., получение фокуса с клавиатуры). Тогда в идеальных условиях юзер получит привычное поведение в гламурной обертке, а в неидеальных — форму, работоспособную несмотря ни на что...

Для меня в свое время было шоком, когда мне дали макет этой страницы под 800?600 с требованием "сделать резину". На мое удивление "как тут сделать резину, это же фактически просто фотография!" дизайнер глубокомысленно ответил: "Резину можно сделать где угодно!". Правда, вариант под большое разрешение дорисовал, за что ему огромное спасибо. Ну и сверстал я, что мне оставалось...

Эх, по гордой ссылке с анонса — 404, да что ж такое-то? А ширина таблиц, как и следовало ожидать, так и вошла как в сферическом вакууме, а не как во всех существующих браузерах. Пичалько...

Про версии — http://caniuse.com/ А вообще вопрос "переходить на HTML5 или нет" даже не стоит: по новому стандарту для браузеров существует только один HTML (вне зависимости от того, что стоит у него в доктайпе и проставлены ли слеши в одиночных тегах), и постепенно все браузеры переходят на разбор его по новым правилам. Как говорится, "HTML5 is not an option" . Единственный практический вопрос — какие фичи использовать уже сейчас (возможно, подперев костылями на всякий случай), а с какими пока повременить. И ответ на него каждый находит сам с учетом специфики проекта и его аудитории...