Re: About dropping the style attribute

On 6/27/07, Alfonso Martínez de Lizarrondo <amla70@gmail.com> wrote:
>
> From my understanding, at least some part of the browser developers (I
> think that at least the Mozilla and Safari people expressed it) won't
> have a different parsing mode for documents according to the doctype,
> there might be some differences in the parsing and/or rendering, but
> nothing too drastic as that would mean more tests that have to be done
> in each mode.
>

so then both Mozilla/Gecko and Safari/WebKit will render any tag they
encounter regardless of the doctype? shoudn't a strict DOM parser
drop/ignore unrecognised tags/attributes for the current DTD?
Most fault of tag-soups and concoctions is from lenient UAs that
render whatever you throw at them, there should be some initiative to
stop this kind of behaviour.

> I would ask you or anyone else that argues for this removal to show a
> JS library that does manipulate the elements on a page changing the
> position, color, etc... without using the style attribute.

they don't change the style attribute, they change the style
*property* of a given HTMLElement. It may seem the same, but it's not.
on one hand you have element.property  and on the other you have
element.(get|set)Attribute.
last time i checked mootools, prototype and YUI they all worked as
this: element.style[property] = value;
What UAs do (at least Gecko that is where i can debug with firebug and
see a real-time representation of the DOM) is that they translate back
those properties and set them on the style attribute.

Now, Gecko at least, does this translation on a very particular way,
if you excuse me on the length of the post, I will show you how
accessing the style attribute is not the same as the property. The
following is the output of an interactive session of firebug on a page
with just a div[id=header]

>>> aa = document.getElementById('header')
<div id="header">
>>> aa.style
[]
>>> aa.getAttribute('style')
null
>>> aa.setAttribute('style', 'border: 1px solid red')
>>> aa.style
["border-top-width", "border-right-width", "border-bottom-width",
"border-left-width", "border-top-style", "border-right-style",
"border-bottom-style", "border-left-style", "border-top-color",
"border-right-color", "border-bottom-color", "border-left-color"]
>>> aa.getAttribute('style')
"border: 1px solid red;"

we see at this point that aa.style != aa.getAttribute('style') , but
what's even more interesting is that we can do the following:
>>> aa.style.borderLeftWidth = '2px'
"2px"
>>> aa.getAttribute('style')
"border-style: solid; border-color: red; border-width: 1px 1px 1px 2px;"

this shows how our carefully hand-built style attribute got completely
mangled by the browser when using scripting, redeclaring the complete
rule and rendering useless any scripting that was dependant upon the
string returned by getAttribute.
This shows also that there's big inconsistency between both methods,
and since we are trying to define a standard (HTML in this case) we
should leave style as a sole property to HTMLElement and not as an
attribute since UAs shoudn't be 'compiling' and 'decompiling' the
style (string) attribute on the go.

To quickly sumarise all this (sorry again for the length, i needed to
show a real-life example on how UAs work), element.style is an array,
while element.getAttribute('style') is a string.
setting one on them changes the other automagically, but they are not
instrinsically connected. One can just ignore the existance of the
style attribute (that means even dropping it from the DOM) and the
style propertry will (should) still work.

--
/gonchuki

Received on Wednesday, 27 June 2007 21:49:37 UTC