Запрет расширения блока

[x-yuri]

w3c - не браузер, на отображение страницы не влияет, поэтому его даже не рассматриваем.

не влияет? А если в текущей версии браузер не придерживается стандарта, а в следующей придерживается? Совпадение?

Остаётся только здравый смысл и браузер, вот по этим кретерям и определяем, что глюк, а что не глюк.

во-первых браузеры. И по какой тогда формуле считать, баг это или нет? Даже с одним браузером имеем два критерия
во-вторых, какой здравый смысл? Что-то могли сделать из соображений производительности, что-то из принципа наименьшего удивления, что-то сложилось исторически, что-то просто удобно. Взять ту же ширину. Как по мне, логичнее включать в ширину padding, но почему-то оно не так. Это такой глобальный баг?

ну и вообще, расклад пока такой: ты считаешь поведение ff лишенным здравого смысла, Aetae - наоборот, а я за то, чтобы во всех браузерах было одинаково

Но правда и в том, что все эти философские рассуждения проблему не решат.

определенно

[DMH]

Не один из браузеров не поддерживает w3c стандарты и вряд ли когда либо будет. Каждая команда разработчиков делает так, как считает нужным. w3c - всего лишь общие правила, как их видит сама команда w3. То, что в одной версии браузера свойство неподдерживалось, а в другой поддерживается - в этом есть заслуга w3c, не спорю, но основное решение остаётся за разработчиками. Microsoft как клали на все эти w3c, так и продолжают дальше
Насчёт здравого смысла - двойной margin в ie баг, все согласны?
Паддинг внутри элемента, соответственно должен включаться в его ширину. Если возьмёте линейку и измерите книжный шкаф, его ширина уменьшится, если книги сместить к центру или неуменьшится? Я вот про этот здравый смысл.

Желание сделать так, чтобы во всех браузерах было одинаково, хорошо, но мир не изменишь, как попыталась w3c, в итоге имеем что имеем.

Вспомнился угол наклона элементов:

-moz-transform: rotate(90deg);  /* FF 3.5+ */
-o-transform: rotate(90deg);  /* Opera 10.5 */
-webkit-transform: rotate(90deg);  /* Saf 3.1+, Chrome */
filter:  progid:DXImageTransform.Microsoft.BasicImage(rotation=3);  /* IE */

Каждый производитель как хочет, так и делает

[x-yuri]

Microsoft как клали на все эти w3c, так и продолжают дальше

они не кладут на w3c, они сами часть w3c. Они поступают исходя из своих интересов

Паддинг внутри элемента, соответственно должен включаться в его ширину. Если возьмёте линейку и измерите книжный шкаф, его ширина уменьшится, если книги сместить к центру или неуменьшится? Я вот про этот здравый смысл.

Я хотел сказать, что есть другие факторы, которые могут быть важнее здравого смысла

Кроме того, вернемся к твоим inline-блокам. Есть у нас inline-блок с текстом... по мере добавления текста он расширяется... появилась вторая строка... Почему браузер должен ужать этот inline-блок по первой строке, а не растянуть на всю ширину контейнера (текст растянул inline-блок до упора)? Во-первых, это лишние действия, а во-вторых мне здравый смысл ничего не подсказывает (а должен?)

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

[Octane]

Microsoft как клали на все эти w3c, так и продолжают дальше

А как быть, если некоторые вещи в MS были сделаны до того, как в W3C их по-своему описали? Поддерживать всё подряд, отказаться от своих, уже реализованных, технологий? VML и SVG, Behavior и XBL… MS можно ругать, за то что они практически не развивали браузер в течении нескольких лет, но к моменту своего выхода IE6 был самым современным и технологичным браузером. К примеру, в супер-крутом платном браузере Opera до 2003 не был реализован XMLHttpRequest, а в IE такая возможность появилась еще в 5-х версиях, выпущенных в прошлом веке.

-moz-transform: rotate(90deg);  /* FF 3.5+ */
-o-transform: rotate(90deg);  /* Opera 10.5 */
-webkit-transform: rotate(90deg);  /* Saf 3.1+, Chrome */
filter:  progid:DXImageTransform.Microsoft.BasicImage(rotation=3);  /* IE */

А что тут не так? Для всех браузеров, кроме IE, одинаковый синтаксис, только перед именем свойства традиционно вендорный префикс, пока не устаканилось, потом уберут, перед border-radius убрали же. А фильтр в IE появился задолго до того, как в остальных браузерах первые попытки сделать CSS-трансформации появились.

[DMH]

Поступать из своих интересов, неподдерживая стандарты - это разве не равно класть на них?
Вот в итоге и получилось, w3 сказали - фильтры зло, делайте вот так, MS в ответ - фиг вам, мы как поддерживали синтаксис фильтров, так и будем, остальное нас неволнует. Каждый свою линию гнёт, а верстальщикам сиди пиши, там filter:opacity, тут просто opacity, там html, а тут xhtml.
Что мешает MS добавить параллельно к фильтрам те же самые свойства, но уже без надписи "filter" и прочего? Можно было также давно уже создавать xhtml-страницы, но ie как всегда устроил всем засаду по сегодняшний день. На тот момент ie был лучшим браузером, но уже 10 лет прошло и сейчас вряд ли кто-нибудь думает о его первенстве. Фильтры и прочее хорошая вещь, сам бы их использовал, выбросив jquery в корзину с его спецэффектами. Но если технологию поддерживает только один браузер, то какова ей цена? Всех на один браузер ведь непересадишь и разработчиков не заставишь делать одинаково.

-webkit- и прочее убрать то уберут, но обратной совместимости со старыми версиями уже не будет. Для Сафари X пишем просто "transform", для Сафари 3-... "-webkit-transform", хорошо придумали дополнительную работу, ещё и по версиям сортировать где чего писать.

Насчёт inline-block и float. Браузер должен был ужать основной блок по максимальной ширине внутреннего контента. Если бы я не хотел ничего ужимать, я бы просто убрал эти свойсва и блок автоматом бы растянулся на весь экран. В данном случае хоть пиши inline-block и float, хоть не пиши, результат один. inline элементы тоже себя так ведут, не вместилось второе длинное слово в экран, значит надо перенести его на вторую строку, а родительский блок растянуть до упора. Зачем? А вот фиг знает, захотелось так.

P.S. Ужатие блока в моём случае нужно для его центрирования.

[Octane]

Вот в итоге и получилось, w3 сказали - фильтры зло, делайте вот так, MS в ответ - фиг вам, мы как поддерживали синтаксис фильтров, так и будем, остальное нас неволнует. Каждый свою линию гнёт, а верстальщикам сиди пиши, там filter:opacity, тут просто opacity, там html, а тут xhtml.

Сами фильтры никому не мешают, в Fx, кстати, тоже куча своих CSS-свойств есть, со временем, возможно, и уберут, когда добавят поддержу соответствующих стандартных CSS-свойств. Не всё сразу. От Expression в CSS отказались же. В IE9 много чего наобещали сделать. Да и слепо следовать всему, что пишут в W3C глупо. Вот на Behavior в IE тоже ругались, а потом бац и в 2007 XBL написали, вдруг нужно стало.

Что мешает MS добавить параллельно к фильтрам те же самые свойства, но уже без надписи "filter" и прочего?

Ничего не мешает, уже добавляют. Я выше написал, что ругать MS нужно за то, что долго не развивали когда-то самый популярный браузер.

Можно было также давно уже создавать xhtml-страницы, но ie как всегда устроил всем засаду по сегодняшний день.

XHTML, отдаваемый как text/html, и так сносно работает в IE, а application/xml+xhtml в продакшине никому не нужен, хотя в pre-alpha версиях IE9 вроде бы уже работает.

-webkit- и прочее убрать то уберут, но обратной совместимости со старыми версиями уже не будет.

А как быть, если сам стандарта еще в черновиках, и если вдруг изменится синтаксис, как будет решать эту проблему? JavaScript сюда приплетать? Префиксы для того и сделали, что не гарантируют работу этих свойств, а разработчики используют их на свой страх и риск.

Фильтры и прочее хорошая вещь, сам бы их использовал, выбросив jquery в корзину с его спецэффектами.

брррррррр…

[DMH]

Вам брррр, а мне фильтры нравятся, хорошие спецэффекты и без всяких скриптов, но тут как говорится на вкус и цвет.

XHTML, отдаваемый как text/html,

Я вот не вижу смысла в этом, кроме насилования браузеров всякими закрывающими слешами (разбор xhtml как html). Если уж делать xhtml, то идти до конца с обязательной выдачей соответствующего заголовка. Если xhtml-парсер работает быстрее html, то почему бы и нет, а ошибки сайта исправить думаю не проблема (впрочем xhtml была благородная цель w3c, но мир под себя не изменишь).

Вобщем ждём IE9. Но самая беда в том, что у народа куча дисков с XP, Win2003 и т.д. с IE6. Если бы версии браузера чаще менялись в то время, думаю с вёрсткой под ie проблем было бы меньше, а так один только ie6 чего стоит.

[Octane]

Вам брррр, а мне фильтры нравятся, хорошие спецэффекты и без всяких скриптов, но тут как говорится на вкус и цвет.

В смысле, я начал сомневаться, что вы знаете, как работают эффекты в jQuery.

[DMH]

т.е. вам лучше качать сотни килобайт кода клиенту, чем использовать уже готовые фильтры браузера?
Эффекты в jquery схожие со сложными ie-фильтрами, работают на основе десятков килобайт js-кода. Угадал, не?
Вот примеры фильтров:
http://www.guestbook.ru/docs/filters...vealtrans.html
http://www.guestbook.ru/docs/filters/
http://www.javascriptkit.com/filters/filters.shtml
смотреть ссылки естественно в ie

[Octane]

В стандартном наборе используется только фильтр Alpha для эмуляции CSS-свойства opacity. Для остальных вещей там никакие фильтры не нужны и код одинаковый для всех браузеров.

работают на основе десятков килобайт js-кода

Необязательно, не вся анимация трудно реализуется. И необязательно для анимации использовать многокилобайтный фреймворк.