Re: Why the style attribute shouldn't be abandoned

First, sorry for some of the flamy arguments in my previous
letter, it was late at night and I couldn't insist.
Trying to be more constructive this time.

I wrote:
>> Note, that removing @style would mean inconsistencies
>> with current CSS spec.

Lachlan Hunt wrote:
> Please explain what that means?

I meant, that existing CSS specification teaches us how
the style attribute is part of the cascade, and when we
drop style from HTML, we also have to drop it from CSS.

But I was wrong, because we still have style attribute in
HTML5, just only the <font> element can have it.

Which brings me to this use-case:

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

This can actually be covered by the <font> element, only
that <font> requires you to have WYSIWYG signature and
you can't really say that HTML preview of PDF file was
generated by WYSIWYG editor.

Maybe we should have a COMPUTER-GENERATED signature instead?
That would cover a wider range of applications that produce
purely presentational HTML, including WYSIWYG editors.

(Computer-generated is probably bad term, because you could
also say, that any dynamic website is computer-generated.)

Thinking out loud...

The knowledge about the style attribute is ceartanly widespread.
I guess that every single CSS-introductory-book tells you,
that there are three ways to specify apply CSS rules: inline
styles, embedded stylesheets and external CSS files.
Even the best books with best intentions tell you this.
And every developer knows this attribute.

Of course, the better books tell you, that it's better not
to use it. But what I have noticed is, that the community
usually tolerates a little use of it.

But clearly the community doesn't tolerate the <font> element
any more. I think there has been enough talk about the
evilness of <font>. It has been deprecated in current HTML
spec and so on.

What signal are we giving, when we bring back the <font>
element in HTML 5 (although only allowed to WYSIWYG tools)?

And what are we going to do with the pile of CSS books, all
teaching the use of style attribute?

Wouldn't it be better to just get rid of the <font>, like
the deprecated status in HTML4 promised, and allow style
attribute for every element (maybe only in WYSIWYG context).

Additionally "font" is not really a good name choice, because
you can use it to set any style, not just typography-related

Lachlan Hunt wrote:
> So, in summary, you're argument 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.


What I mean is, that having content and style separated is
not a goal in itself. The goal is to make our code more
easily manageble. And to achieve that, we have to reduce
complexity. Just like in any other software development.

Similarly like using functions in program source code is
not the goal in itself. The goal is to make code more
manageble by reducing complexity.

Usually defining functions helps to reduce complexity,
but you should be aware of over-engineering. If you
just want to say "Hello", then it's usually better to

   print "Hello";


   function hello() {
       print "Hello";
   /* a lot of code between */

It's quite the same with CSS. If you just want to write
a single line of text in red, it's most readable to use
inline CSS:

   My favorite color is <em style="color:red">red</em>.

It's much harder to understand code like this:

   <style type="text/css">
   .fav-color {
       color: red;
   <!-- a lot of HTML in between  -->
   My favorite color is <em class="fav-color">red</em>.

What was the gain of defining a new CSS class? Nothing.
It just increased the complexity of the page.

Sure, it's a good habit to not use inline styles, but if
you just use it for rare styles in rare documents, then
I don't see anything fundamentally wrong with it.

Rene Saarsoo

Received on Saturday, 30 June 2007 15:39:59 UTC