Re: inline CSS (was: is anyone interested in XHTML?)

At 19:14 17.02.00 -0800, Murray Altheim wrote:
>Some people love this, some people hate this. These features are not good
>for the web community, despite spin to the contrary. IMO.

The risk with the "do this, it is good for you" style of argument is that
if the web community doesn't agree, they'll ignore you. To avoid a perfect
paper standard, you must achieve two things:

1. Web designers and developers must be convinced that it is good for them
2. They must be able to argue with their employers and clients that it is
good for them too.


Personally, I'm at two minds when it comes to the style attribute. The
aesthete mind (that thought "Is it really necessary with /three/ different
mechanisms to attach a style sheet to an HTML page??" when it read the
standards the first time) would like a firewall between the code and the
CSS (not to speak of the Javascript riff-raff). And one less attribute to
worry about is one less attribute to worry about.


From a practical view for a hand-coder inline style has considerable
advantages. Most of the style information can be handled with elements and
classes (that *must* be in a separate style sheet), but the one-off
definitions for elements with a particular definition is better done
locally. That way you can see the exceptions where they appear, and won't
have to make a manual tracking. Consider this style sheet:

h3 {color: blue;}
p.question {color: blue;}
#id23 {color: blue;}

The first two gives style rules (all heading level 3 are blue, as are all
questions), the third only tells you that somewhere there is an element
that is blue, you have to look in the code to find which one. Conversely,
when you see <p id="id23">, you have no indication that this paragraph has
a particular style, and if it has, you have to spend some time looking for
it, theoretically through a cascade of linked style sheets (though it is
unlikely that there will be a site-wide definition of "id23"-styles). 

For WYSIWYG and other visual editors, this is not much of a problem, these
editors can put the style information whereever they want to (external,
element, attribute), it is only an issue with code view.


As for bad style, there is no functional difference between 1 and 2 below.
1: <span style="bad-style">
2: <style>#some-key {bad-style;}</style> ... <span id="some-key">

Common elements should be distilled into classes instead of giving every
element formatting codes, enlightened self interest should ensure that this
will happen (more maintainable code), while removing the style attribute
will have minimal effect.

Received on Monday, 21 February 2000 16:01:20 UTC