Re: Why the style attribute shouldn't be abandoned

Rene Saarsoo wrote:
> 1. Some use cases
> 
> First I think, no-one has really pointed out good
> use-cases for using inline styles.
> 
> 1.1. Tag clouds
>      <http://www.flickr.com/photos/tags/>

There are alternatives for tag clouds, which are being investigated by 
the microformats community.

http://microformats.org/wiki/tagcloud-brainstorming

> 1.2. Bar graphs
>      <http://concepts.waetech.com/bargraph/>

This is already solved using the new <meter> element.

> 1.2. Computer-generated HTML
>      The best example is Google giving you the HTML
>      version of .doc or .pdf document.

That's an interesting use case.

> 2. Everyone is using it.

Please don't make broad, unsupported claims like that.  It's not useful 
for the discussion.

> 3. It's really useful for debugging
> 
> It's clearly THE easiest ways to style a single element.
> Quick and dirty prototyping anyone?

The attribute will still be supported, and it's use in debugging, as 
opposed to a production environment, is not really a reason for it to be 
considered conforming.

> 4. @style relates to <style> as <style> relates to <link>
> 
> Let's consider <style> and <link rel="stylesheet">.
> 
> When I have a lot of documents with same visual design,
> then having <style> element with same declarations in
> each of those documents is ceartanly evil. I should use
> <link> to point to the common styles in separate file.
> 
> So, is the <style> element evil and should be dropped?
> 
> No, because when I have styles, that are specific to
> just one document, then there is no big reason to create
> extra CSS file for those styles.
> 
> Similarly with @style and <style>. If you have just
> one element in one document, that you want to style in
> a specific and unique way, then there is no logical reason
> to make up new #id or .class.

So, in summary, you're arugment is that it is sometimes more convenient 
to use style="" than it is to assign an ID or class and place styles in 
a <style> element.

> 4.1. Note, that removing @style would mean inconsistencies
>      with current CSS spec.

Please explain what that means?

> 5. What about JavaScript style property?
> 
> Even when we remove @style, the JavaScript style property
> will still have to remain. And it clearly should, because
> how else could you animate elements and do other dynamic
> stuff like that?
> 
> But having no @style while having element.style looks
> really inconsistent.

The way you have expressed that is not really a strong argument.  For 
example, we still have the following DOM APIs, without any conforming 
markup to match:

* HTMLLinkElement.charset
* HTMLMetaElement.scheme
* HTMLBodyElement.aLink, .background, .bgColor, .link, .text, .vLink
* HTMLParagraphElement.align

and many more.

However, if there really are valid use cases for element.style, then one 
reason the style attribute should be considered conforming is because 
the changes to the .style property are reflected in the style attribute 
in the DOM, and without the attribute, there would be no conforming way 
to serialise the DOM after modifying the .style property.

> 6. What about <script> and @onclick, @onmouseover, etc?
> 
> If we are going to drop @style, then we should be consistent
> and also drop all the scripting related attributes too.

Sorry, that's equivalent to Pokemon Test and it is not a valid argument.

http://en.wikipedia.org/wiki/WP:POKEMON

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Saturday, 30 June 2007 12:30:18 UTC