25 января 2012 :Феерические глупости

Комментарии:

• #1

  SelenIT

  26.01.2012 14:34:42

  Здравствуйте, Елена! Спасибо за грамотный разбор ситуации, но хотелось бы уточнить пару моментов:
  1) Верно ли я понял, что браузеры не нарушают спецификации, потому что спецификация фактически ни к чему их не обязывает?

  UAs are not required to implement this algorithm to determine the table layout in the case that 'table-layout' is 'auto'; they can use any other algorithm even if it results in different behavior.

  2) Нормально ли поведение Хрома по части высоты, а не ширины таблицы/ячейки? И соблюдает ли Хром спецификацию вот в этом случае (хоть это слегка оффтопик к статье)?

  И в защиту хабралюдей хочу сказать, что border-spacing - вообще очень редко используемое свойство (т.к. IE6-7 успели "отучить" от него вебмастеров). На практике обычно требуется именно обнулить дефолтный двухпиксельный зазор, и на практике единственное кроссбраузерное решение этой задачи на CSS - как раз включить collapsing. Отсюда и тянется невольное убеждение о связи между этими вещами. Конечно, нежелания читать спеку это не извиняет, здесь я с вами солидарен :)

  Ну и насчет различий между платформами... в теории вы полностью правы, но, как говорится, "в теории нет разницы между теорией и практикой, а на практике она огромна" :). Понятно, что такого не может быть, но, как говорит народная мудрость, "раз в год и палка стреляет" - ни одна система, особенно зависящая от человеческого фактора, не застрахована от самых глупых ошибок... :)

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

• #2

  Елена Лунная

  26.01.2012 15:40:55

  Привет. Знала что вы это прочтёте =)
  1) Именно. Таблицы прелестны тем, что они всячески подстраиваются под контент, и применять их следует не для жёсткой разметки страницы, а для плавающих табличных данных. Ныняшняя спецификация даёт очень большую свободу браузерам. В w3c планируется отдельный модуль (они сейчас всё модулями делают) относительно таблиц:
  http://www.w3.org/Style/CSS/specs.en.html#tables
  Пока нет даже самого сырого черновика не выложено.
  Цитата абсолютно верная. Она касается стиля table-layout:auto; (который стоит по умолчанию. Во время написания статьи я так же скачала пример, и поставила принудительно fixed. Особо ничего не изменилось. Согласно спецификации даже в случае fixed - браузеры отображают всё правильно. Но в этом случае доказать это чуть сложнее.  Основная суть - в том что свойство width для таблицы или ячейки - трактуется как минимальная ширина, а не как абсолютная.
  Касательно режима Fixed - там сказано примерно то, что ширина таблицы - является приоритетной (чтобы вёрстка не ломалась, логично же), поэтому в случае с указанием ширины таблицы в примере с хабра - она превалирует над шириной ячейки.  Но во всех случаях она безусловно должна принимать в расчёт ширину ячеек. Например если вы сделаете таблицу шириной 100% и в ней две ячейки в ряд шириной 30px и 70px, то таблица будет растягиваться на всю ширину, а ячейки будут занимать примерно 30% и 70% всей ширины. Как-то так.
  Касательно высоты - там написано

  CSS 2.1 does not define how extra space is distributed when the 'height' property causes the table to be taller than it otherwise would be. 

  2) Я посмотрела ещё раз описанный в начале топика пример. Самое главное - когда всё очевидно. Чтобы было очевидно - не надо использовать border:1px, надо использовать border:30px ! =)
  Вот тест http://usabili.ru/labs/browser_bugs/chrome_winner.html
  Из него видно, что хром показывает display:table элементы - лучше всех.  По спецификации - 100% таблицы с учётом границ не может занимать больше 100% доступного пространства. Если имелся ввиду какой-то другой баг - присылайте, с удовольствием посмотрю.

  3) border-spacing - довольно хорошо отображался в ie6-7 (светлая им память). Вот возьмём например коллегу Ростислава Чебыкина, он в своих книжках писал и в 2004 и в 2008 о том как заменять невалидные атрибуты cellpadding и cellspacing, рекомендуя именно border-spacing. И всё замечательно работало.

  4) В технологии экрана не поддерживающим мультитач (ряд резистивных экранов например), зум был неудобен, только и всего =), а уж когда стилусом тыкать, или вообще управлять зумом с клавиатуры - всё совсем плохо было.
  Дефолтный браузер андроида - не сжимает текстовую информацию до ширины страницы. Он сжимает её примерно до 850 css пикселей, затем несколько раз делает reflow страницы чтобы всё встало красиво, а потом зумит страницу до размера экрана.  Подробнее, настоятельно рекомендую читать блог Питера Паула Коха (quirksmode.org) он последний год про мобилы пишет, и dev.opera.com там тоже бывает интересное.
  Я сама почти весь последний год активно читаю про всякие штуки типа target-densitydpi=device-dpi и делаю вот такие тесты:
  http://usabili.ru/labs/browser_tests/resolution.php
  чтобы посмотреть что и как в браузерах андроида и iOS
  Пишите ещё.
  

• #3

  Елена Лунная

  26.01.2012 16:03:37

  Ух ты, автор топика хабра прочитал мою статью (первый абзац видимо). И ничего не понял =). Epic win!

• #4

  SelenIT

  26.01.2012 16:53:05

  Елена, спасибо за ответ! Но я всё-таки позанудствую:

  2)

  ... По спецификации - 100% таблицы с учётом границ не может занимать больше 100% доступного пространства.

  Вот здесь загвоздка. В п. 17.6.1 спеки (визуальная модель таблицы с раздельными бордерами) английским по белому читаю:

  The width of the table is the distance from the left inner padding edge to the right inner padding edge (including the border spacing but excluding padding and border).

  Если эта width of the table - не то, чему должно приравниваться заданное значение, то где же то?..
  Хотя мой вопрос был больше про высоту:) А пример с форума htmlbook.ru, где оказалось, что на ширину таблиц в Хроме влияют вертикальные бордеры и паддинги, я привел исключительно для иллюстрации, что далеко не всегда он такой winner...

  3) Могу я увидеть хоть один пример? Гуглежка "border-spacing Чебыкин" дала мне только эту статью (посвященную выходу IE8), где Ростислав пишет прямо противоположное...

  Для таблиц добавились ... и border-spacing. Это свойство позволяет увеличить зазор между ячейками таблицы, для чего раньше применяли атрибут cellspacing. Чтобы убрать этот зазор, грамотные люди давным-давно пишут border-collapse, а вот, наоборот, увеличить его через CSS было невозможно в прежних версиях IE.

  4) Точно! Именно у PPK я это и прочитал, спасибо за подсказку!

  The significant exception here is Android WebKit, which actually reduces the size of text-containing elements so that they fit on the screen. This is absolutely brilliant, and I feel all other browsers should copy this behaviour.

  Это подтверждает опыт в лице моего старенького Хуавея с экраном 320х240, и я полностью согласен с Петером-Паулем: this is absolutely brilliant! :)

• #5

  Елена Лунная

  26.01.2012 17:43:36

  Там в оригинальном топике http://habrahabr.ru/blogs/css/136960/ пользователь lashtal нашёл правильную цитату:

  «However, in HTML and XHTML1, the width of the element is the distance from the left border edge to the right border edge.», т.е. ширина (и высота) таблиц считается по умолчанию вместе с бордерами. (это еще со времен HTML3: «The default table width is the space between the current left and right margins.»)
  И далее: «In CSS3 this peculiar requirement will be defined… бла бла». Т.е. точное поведение таблиц с box-sizing еще не определено в css3.
  www.w3.org/TR/CSS2/tables.html#borders
  

  3) К сожалению Ростислав перед новым годом переехал с жж на блоггер, и зачем-то удалил свои прошлые дневники, это очень обидно. Открыв книжку и прочитав, весь смысл я свожу к тому что border-collapse убирает совсем задор, а border-spacing - увеличивает.  Так что видимо моя ссылка была не точна, виновата.
  Но я могу сказать почему я использую именно border-spacing. Дело в том что по спецификации, свойство border-radius не применяется к ячейкам таблицы, в случае если у таблицы стоит border-collapse:collapse . Поэтому если хочется делать такие простые эффекты как технику однопиксельного подчёркивания  (не помню как по английски, но пример можно посмотреть тут http://usabili.ru/news_imgs/141/table_cell_rounded_border.png ) то приходится использовать именно border-spacing.

  4) да, именно про это я и говорю. Возможно вам также будут интересна статья http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/ ну и для тех кто его не читал но читает этот комментарий, рекомендую первую статью серии http://www.quirksmode.org/mobile/viewports.html .

• #6

  SelenIT

  26.01.2012 18:18:11

  Давайте всё-таки разберем эту цитату из спеки целиком. Согласны ли вы, что в ней утверждается следующее:

  • Ширина табличного элемента (т.е. любого элемента с display:table или inline-table) - это ширина его content-box'а (который включает в себя внешние зазоры вокруг ячеек, но не включает padding и тем более border самого табличного элемента), т.е. используется единая боксовая модель CSS1-2;
    
  • В (X)HTML шириной элемента TABLE (и только этого элемента!) по историческим причинам считается ширина его border-box'а (включающего и padding, и border).
    

  Вы согласны, что эти параграфы являются взаимоисключающими?
  Варианты трактовки этого я вижу следующие:

  • В CSS во всех случаях применяется модель content-box. Второй абзац - исключительно для сравнения и говорит о том, что в рамках CSS2.1 нельзя описать дефолтное поведение таблиц в HTML (напр., по аналогии с этим). Лично я сперва понял это так, как сейчас понимаю - неверно.
    
  • Для всех элементов с табличным display, кроме самого TABLE, применяется модель content-box, для TABLE - в порядке исторически сложившегося исключения, border-box (не описанная в текущей спеке, но описанная в другой). Тогда получается, что в вашем примере как раз Хром облажался (принял правило за исключение), а остальные браузеры правы. На данный момент - самая логичная для меня версия.
    
  • Ваша трактовка, что "element TABLE" (именно элемент, создваемый тегом table, а не абстрактный "table element"!) во втором абзаце нужно трактовать расширительно как "table element", на мой взгляд, слишком произвольна и натянута (уж простите:).
    

  Ну и по п. 4 - триста пардонов, но это как раз я сказал, а вы, насколько я понял, уверяли, что андроидный браузер так не делает :). Впрочем, если мы говорили об одном и том же, просто не поняли друг друга - ничего страшного, бывает ;). Главное, что мы с PPK сходимся в том, что это поведение для устройств с маленькими экранами очень удобно :)
  

• #7

  SelenIT

  26.01.2012 18:19:38

  P.S. Спасибо за ссылки про мобильный браузинг!
  

• #8

  Елена Лунная

  26.01.2012 19:26:34

  Да. Параграфы в чём-то взаимоисключающие. Именно по этой причине мозилла до сих пор не ввела поддержку box-sizing.  Т.е. по причине того что спецификация слишком размыта и не достаточно test-case'ов для имплементации полностью.  Именно тут как обычно бывает складывается парадокс. Вендоры браузеров не всегда спешат править баги по спорной спецификации, а w3c не спешит править спорную спецификацию, ожидая поправить её основываясь на поведении браузеров. И это мы говорим об одном из разделов css2, а сколько таких случаев с html5 вообще страшно представить. Думаю из-за этого дату его рекомендации планировали к 2020 году (т.е. когда все браузеры будут отображать её одинаково и полностью).
  В данном вопросе, действительно, по спецификации правы вы.  Вариант content-box должен применяться для всех элементов включая табличные, за исключением элемента TABLE.  Здесь я действительно слишком бегло прочла спецификацию. Безусловно, во всех будущих спецификациях данное поведение конкретно за элементом <table> - закрепят в целях совместимости.
  Текущая спецификация не говорит об исключении для остальных табличных элементов, и мне очень хочется посмотреть что же в итоге попадёт в модуль tables css.
  Моё личное мнение в том, что поведение хрома самое логичное, вопреки спецификации (в ней же написано вверху что все элементы display:table должны себя вести как элементы HTML TABLE). Я считаю что единственное вообще назначение дополнительных свойств display, таких как table, table-cell и т.п. в том чтобы вебмастер мог переписать свою табличную вёрстку на дивы например; и что отображение должно быть полностью идентичным, т.е. всем элементам с display:table - должно автоматом назначаться свойство box-sizing:border-box;
  Резюмируя хочу сказать что таблицы - очень узкая вещь в современных браузерах. Верстая ими, часто приходится делать browser-sniffing, вместо feature-sniffing. У меня есть прекрасные примеры таких багов

  • http://usabili.ru/labs/browser_bugs/chrome_td_width.html - баг хрома, найденный больше года назад.
    
  • http://usabili.ru/labs/browser_bugs/opera_border_bug.php - баг оперы найденный недавно, работает во всех стабильных версиях. Вадим Макеев (pepelsbey) обещал что к релизу 12й должны поправить, ждём. Пока использую костыль через background-position для оперы.
    

  Но прогресс не стоит на месте. Браузеры постоянно улучшаются, и это радует. Старые версии браузеров - отмирают. IE-team например делать много разных и хороших testcase'ов для w3c касательно css2.1. Мозилла всячески способствует разработки новой ветки ECMAscript (6), всего полгода назад же вышла версия 5.1 и для неё есть очень много тестов, появляется поддержка strict mode где всё совсем по другому (используйте уже сейчас). Гугл вообще двигает технологию в массы (и Ян Хигсон надо сказать на гугл работает). Опера сильно развивает коммунити разработчиков, взять хоть тот же web-standarts.ru. Короче много хорошего происходит. Просто наука о том как из куска текста получить картинку на экране очень сложная и ошибки неизбежны. Кстати многие спорные вопросы рекомендую задавать в багтрекере мозиллы, там очень много авторов спецификаций w3c работает которые доходчиво объясняют.
  В общем я надеюсь что все браузеры придут таки к одинаковому поведению. Я каждый день вижу что что-то хорошее происходит и меняется и хочется сказать Ура товарищи!

• #9

  SelenIT

  26.01.2012 21:32:47

  Спасибо за ответ! Рад, что мы наконец нашли решение парадокса, а заодно сами поняли эту многострадальную спеку, надеюсь (судя по поведению 3-х браузеров из 4-х), что правильно :)

  Может быть, после таких заворотов сюжета вы смените гнев на милость и признаете, что главная мысль автора того хабратопика (которого я уважаю за полезный скрипт Sypex Dumper) о том, что

  [/quote][quote]...производители браузеров в гонке за количеством внедренных черновиков – забыли, что стандарты нужно не только поддерживать, но и поддерживать правильно и одинаково.

  не такие уже и subj? ;)

  И опять же: если спецификация написана так, что ее без пол-литры не поймешь, а даже поняв, без какой-то магии не реализуешь - может быть, как минимум, часть проблемы в самой спецификации, а не только "нежелании ее прочитать" (я вот вроде прочитал - а пока не обсудили да не поспорили, так и не понял;)?

  Но насчет "логичности" поведения Хрома я не согласен, имхо это волюнтаризм :). Вы же сами в статье верно пишете:

  [/quote][quote]Но, позвольте, ежу ведь понятно что дивы (слева) никогда не будут отображаться так же как ячейки (справа)

  т.е. признаете за разными элементами право на разные дефолтные CSS-свойства (включая box-sizing). Меня разный дефолтный box-sizing у дивов и таблиц не коробит (а вот неявная смена одного свойства при смене другого, на первый взгляд далекого - наверняка покоробила бы, если это не неизбежно, как с display при float). Главное, чтобы была возможность привести к одному знаменателю (а она есть - как минимум в теории).

  Ну и к радости по поводу перемен на браузерном фронте и всё более очевидных с каждым месяцем перспектив светлого верстального будущего присоединяюсь целиком и полностью! :)

• #10

  Елена Лунная

  26.01.2012 22:49:02

  В споре рождается истина. =)
  Проблемы в спецификации есть, и их надо решать. Это по силам любом интернет пользователю, достаточно просто послать письмо Håkon Wium Lie <howcome @opera.com>, где попросить его или его коллегу Берта Боса (Bert Bos), с которым они написали книгу  http://www.w3.org/Style/LieBos3e/.  Я думаю это будет самое разумное. Первый - автор собственно спецификации CSS, наряду с Тантеком Селиком (который не отвечает на письма) и Хикси (Который отвечает, но с задержкой в полгода =)). А второй - это собственно человек который будет разрабатывать модуль tables для w3c.  Если удасться получить какие-то ответы - я обязательно напяшу об этом.
  В хабравской статье автор приходит к отчасти правильному заключению. Т.е. я крайне не согласна, (и мы это доказали), с тем, что правильно, это одинаково. Ведь сразу видно что для ширины таблиц - отличается только файрфокс (по ряду своих причин), а не хром указаный топикстартером. А для высоты таблиц - спецификация (т.е. правильное отображение) допускает разное толкование.  И как показывают скриншоты - тут результаты делятся поровну между chrome & ie vs opera & firefox. В статье  я упрекаю автора топика не за критику браузеров, а за неупоминание спецификации, которую мы так тщательно расжевывали сегодня.
  Как говорил Морфеус - знать путь и пройти его, не одно и то же. Т.е. есть разница между тем чтобы найти несоответствие и объяснить почему оно происходит. А мы обсудили не одну а две проблемы, с хабра и с forum.htmlbook.ru, они на самом деле разные.
  Касательно гнева на милость - я конечно никого не хотела обидеть данной статьёй. Заголовок и первый параграф были выбранны нарочно провокационными! Впрочем возможно я сама повелась на провокационный заголовок хабра. Мне жаль если человек обиделся. Сделано это было потому что мне хочется полемики. А то пишу, пишу, а никто не говорит ничего, (120 человек читают через rss, кто эти люди, где они?). С друзьями подискутирую немного и всё. А ведь не так часто пишу, раз в месяц, даже реже. За последние полгода отличные статьи вышли, методологические, провокационные, в них есть где поспорить: "Биты, байты, кодировки", "Объекты, объекты, объекты", "Селекторы css4", "Ошибки авторизации".
  Прошу. =)

• #11

  SelenIT

  27.01.2012 00:09:40

  Боюсь, что насчет исправления ошибок в CSS2.1 немножко, что называется, "поздняк метаться": из Rec. ее вряд ли откатят, а если это произойдет (как бывало с XHTML1.1, например, см. хронологию моих удивлений в этой связи:) - вряд ли это пойдет индустрии на пользу. Нам бы успеть свыкнуться с возвращением пикселей в стан абсолютных единиц..:) А вот за развитием табличного модуля 3-го уровня пронаблюдать надо, согласен. Хикси, наверное, дергать без крайней нужды не стоит, ему и в HTML5 работы выше крыши, а вот Берта надо будет "пингануть", когда в этом модуле хоть что-то начнет кристаллизовываться. Правда, по слухам, это они с Хоуконом Ли и пропихнули "вывернутую наизнанку" боксовую модель в CSS1... но, надеюсь, выводы сделали:)

  Вообще я часто жалею о том, что для CSS нет параллельной W3C сугубо прагматичной конторы, а-ля WHATWG для HTML..:)

  Проблем мы обсудили даже больше, чем две! Но выяснилось, что у Хрома с таблицами они всё-таки есть (пусть и в других местах, чем указано в хабратопике).

  А насчет желания подискутировать - очень хорошо понимаю! Сам частенько страдаю от такого зуда. Правда, чаще хожу удовлетворять его на тот же хабр и те же форумы (вот, например, какой славный холиворчик однажды вышел). Может, и вам свои статьи на хабре поанонсировать? По указанным статьям я бы с удовольствием попридирался по отдельным мелочам, но, к сожалению, не чувствую себя достаточно компетентным для этого (особенно в части магии JS), боюсь очередную порцию subj-а спороть..:) Но попробую, спасибо за приглашение!
  

• #12

  Елена Лунная

  27.01.2012 04:00:58

  Хикси кроме html5 сейчас вот срочно пишет спецификацию microformats. Но можете пока не читать подробнее. Вводную статью я напишу в ближайшие дни.
  

• #13

  SelenIT

  27.01.2012 20:54:21

  Кстати, возвращаясь к ширине табличек, хотел бы прояснить до конца. Для алгоритма Fixed я вижу в спецификации следующее:

  The width of the table is then (после определения ширины столбцов — прим. SelenITа) the greater of the value of the 'width' property for the table element and the sum of the column widths (plus cell spacing or borders).

  Я понимаю это так, что если суммарная ширина ячеек вместе с их бордерами и междуячеечными зазорами превышает заданную ширину для табличного элемента, то определять ширину таблицы должна всё-таки она — как большая из этих величин? И даже "нестандартрая" для CSS2.1 боксовая модель не поможет такой таблице "втиснуться" в заданную ширину — на ячейки ведь исключение не распространяется? Получается, по букве спеки превалирует всё-таки ячейка, и "верстку ломать можно"?

  Буду очень благодарен за окончательное разъяснение этой запутанной темы! И прошу меня извинить, если нечаянно я перебрал с провокационностью в обсуждении других ваших статей...

• #14

  Елена Лунная

  27.01.2012 23:14:16

  Подождите. Сейчас вы всех запутаете!
  По букве спеки вёрстку ломать можно например засунув заменяемый строчный элемент (<img>) в ячейку таблицы с table-layout:auto; .  =)
  С фиксированной вёрсткой всё гораздо сложнее, как я и говорила. Вот пример:
  http://usabili.ru/labs/browser_bugs/chrome_table_layout_fixed_feature.html
  Мы видим, что все браузеры (кроме хрома) - в данном случае действительно считают главной именно ширину ячейки!
  Тест http://usabili.ru/labs/browser_bugs/table_layouts.html показывает что хром форсирует для элементов display:table  значение box-sizing:border-box; видно сравнительно, и при клике.
  Это мы также выяснили ранее.
  На этом особенности заканчиваются.
  

• #15

  SelenIT

  28.01.2012 00:38:36

  Елена, милая, ну за что ж вы так? ;) Пока я ковырял ваш второй пример DOM-инспектором, гадая, почему клик во всех браузерах показывает content-box (кроме FF, где ничего не показывает:), когда сам инспектор четко пишет border-box, и вообще, откуда берутся все эти стили, если в HEAD страницы их нет... Ну зачем было прятать между скриптом и стилями спан-невидимку с тем же ID, что у таблицы? И потом, вроде ж и вы, и я несколько раз спецом отметили, что разбираем мы отображение табличек с раздельными бордерами ячеек — и нате: "border-collapse:collapse"... Ай-яй-яй! ;)

  Я чуть модифицировал ваш пример, добавив к обоим вариантам отдельно ситуацию, когда заданная ширина таблицы больше суммы ширин ячеек, и отдельно — когда меньше: http://selenit.freeoda.com/experiments/table-layout-box-sizing-width.html (по клику на любой элемент показывается его tagName, box-sizing и offsetWidth). Здесь никакого логичного объяснения поведения Хрома у меня не находится (кроме отсылки ко всё тому же багу, что проявился в примере c forum.htmlbook.ru).
  

• #16

  Елена Лунная

  28.01.2012 01:31:00

   Да,мой позор. я копировала пример из другого теста и случайно взяла лишнюю строчку. впрочем у меня уже 8 утра и я уже сплю. с планшета отвечаю. бордерколлапс в примере роли не играет, это очень сырой тест, например если таблице тоже задать бордер - результат будет интересный. всем этим я займусь завтра. кстати разве правильно использовать style.boxSizing? везде используют getPropertyValue
  в фф безусловно не работает мне было лень ставить костыль.
  спасибо за замечания. а то без них у меня как раз феерические глупости получаются. =)

• #17

  SelenIT

  30.01.2012 16:03:50

  Бордерколлапс влияет лишь тем, что с ним, получается, мы тестируем совсем другой раздел спеки (с которым у всех браузеров еще большие проблемы), а так всё нормально :). Насчет того, как правильно обращаться к действующему стилю — честно говоря, сам давно не разбирался, style у меня явно лишний (осталось от экспериментов — из-за того спана я не сразу понял, почему скрипт дает такой странный результат, пробовал менять его по-всякому, в итоге, когда убрал спан, это оказался первый вариант, который стал выдавать ожидаемый для меня результат:). Style в нем явно лишний, согласен (не знаю, откуда я его взял), а прямое обращение к свойству нравится мне больше, чем getPropertyValue, лишь тем, что "писать меньше". Меня больше удивил вызов getComputedStyle() у window, а не document.defaultView — не знал, что так (уже?) можно...
  

• #18

  Елена Лунная

  30.01.2012 17:06:12

  Вот как раз не знала что так https://developer.mozilla.org/en/DOM/document.defaultView можно.
  А я пользовалась вот этой https://developer.mozilla.org/en/DOM/window.getComputedStyle
  как ясно из названия она возвращает реальный текущий стиль элемента. (а не то что из свойства style). Другой объект совершенно. По хорошему к нему надо только через  getPropertyValue() обращаться.
  

• #19

  SelenIT

  30.01.2012 17:50:10

  Перечитал свой код и понял — style у меня просто имя объекта, который вернул getComputedStyle :) впредь буду именовать переменные аккуратнее!

  Почитав MDN и погуглив, вроде разобрался, что window.getComputedStyle и document.defaultView.getComputedStyle — практически одно и то же, второе чуть универсальнее (работает в FF3.6 во фреймах), но рекомендуют первое, как более современное и компактное. А вот в чем прикол .getPropertyValue(), пока не врубился совсем. Начиная с того, что MDN сам себе противоречит: в .../en/DOM/window.getComputedStyle утверждается, что

  The returned style is a CSSStyleDeclaration object

  и

  The returned object is of the same type that the object returned from the element's style property, however the two objects have different purpose.

  (т.е. ничто не мешает обращаться к свойствам текущего стиля той же точечной нотацией, что и к "подсвойствам" свойства stlye), но в .../en/Gecko_DOM_Reference/Examples написано иначе —

  getComputedStyle() returns a ComputedCSSStyleDeclaration object, whose individual style properties can be referenced with this object's getPropertyValue() method

  (правда, не написано, что only with... и не написано, что can not обращаться к ним по-другому:).

  В плюсы getPropertyValue() могу записать лишь прозрачность использования значений из CSS напрямую — без преобразования слов-с-дефисами в словаВерблюжьегоРегистра :). Но всё равно лично мне писать через точку привычнее. И работает ведь! :)