W3C home > Mailing lists > Public > www-html@w3.org > January 2003

Re: XHTML 2.0 considered harmful

From: Chris Mannall <chris.mannall@hecubagames.com>
Date: Wed, 15 Jan 2003 16:40:51 +0000
Message-ID: <3E258F13.6000809@hecubagames.com>
To: www-html@w3.org

Mikko Rantalainen wrote:
> 
>  It seems that those who prefer br over l are the same ones that
> want to keep the style attribute. This far, every example for the need 
> of br and/or style attribute has only demonstrated that the author of 
> that specific example hasn't really understood semantic markup.
> 
> If you feel that you have to use br or style attribute try to think for 
> a second what's the reason you "need" those. Think about *why* you're 
> trying to achieve the line break or specific styling, not *what* you're 
> trying to achieve.

Okay, here's another problem with removing the style attribute that has 
been bothering me for a while, but I've only now rustled up enough 
motivation to voice it.

[1] Load an XHTML document into an HTML DOM representation.
[2] Grab hold of an element with e.g. document.getElementById("foo")
[3] Alter that element's style with e.g. element.style.width = "20px"
[4] Serialize the document IN ITS CURRENT STATE.
[5] Noticing the problem yet?

What are we expecting the application to do at this point? Previously, I 
would consider the answer to be obvious - when it comes to 
serialization, the element's style attribute can be written out as 
appropriate to preserve the styling. But now there's no style attribute. 
Instead, the application could simply create a style rule with an id 
selector - but where does it put it? In an inline stylesheet is a 
perfectly reasonable answer, but still carries a problem in that the 
stylesheet could be deleted and the element's styling altered as a 
result. This is contrary to the expected behaviour of element.style - it 
implies that the styling is being attached to *the element itself*, and 
thus can only be modified by further calls to element.style. 
Alternatively, there could be a non-deletable stylesheet for such 
purposes that doesn't appear in the stylesheets collection, but then 
someone's going to have to talk to the DOM chaps to get *their* spec 
change to reflect this.

To those preparing to retort with either [a] "that's a DOM issue" or [b] 
"the HTML DOM isn't meant to be used with XHTML", I reply thusly:

[a] Get over it, and start looking at XHTML, CSS, DOM et al as pieces of 
the *same puzzle*. Working Groups failing to communicate with other 
Working Groups is what brought us the XLink/HLink debacle.

[b] Good point, but if this means I have to use the generic XML DOM 
mechanisms for modifying stylesheets just to frob a single element's 
style, well, count me out. I'll stick with XHTML 1.0 and my nice 
easy-to-use element.style, thank-ye-kindly.


- Chris Mannall.
Received on Wednesday, 15 January 2003 11:47:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:54 GMT