Re: "fighting it out between WGs" (was: inline CSS)

At 15:25 22.02.00 -0800, Murray Altheim wrote:
>You know, most everyone I've heard from is either a past or current 
>member of the CSS working group or a Microsoft employee. 

From other postings, I presume non-W3C-members don't count. By making
people that have worked in the CSS working group inherently suspect (which
in itself is inherently suspect), even Microsoft lackeys, you are narrowing
it down to a small group of people. If you haven't worked with CSS, of
course removing the style attribute is no big deal. It will negatively
affect web designers, something people here have voiced.

>The two representatives in the HTML 
>WG from the HTML Writer's Guild (representing over 110,000 web 
>authors worldwide) have been pretty strong advocates of the decision
>made by the HTML WG to deprecate the 'style' attribute into the 
>Legacy module. 

I will be an advocate myself if you can give concrete and convincing
advantages to removing the style attribute. It shouldn't be too hard, as I
am a bit of a reductionist myself. Of course, when I do, you'll also have
the support of the 2 million Jonny-clones I have stocked in a warehouse up
north...

In particular, I'm interested in the WAI argument. (style="<badstyle>"
compared with #selector {<goodstyle>} will not do as an example)

These decisions should be relevant around...2001-2002, particularily for
non-PC devices, so there is still some time, but a couple of years is not a
long time. It is hard to teach a web designer new tricks (this makes them
exceptionally pliable, it is near impossible to teach most others a new
trick), so they would have to be convinced. Otherwise they would only be
pissed at the W3C, CSS or both. These are arguments against I can think of.

COST OF CHANGE
1. ID selectors are unreliable today. Removing style is only an option when
today's bunch of browsers are gone.
2. They would have to learn a new way of doing it. It shouldn't be too
hard, since they know .class {style}, #id {style} isn't too different. But
it is a switch from "Do *not* use #id (unreliable)" to "*Do* use #id".
3. The cost of change applies to UAs everywhere too, but this is not an
immediate concern for a designer (though it can be for a developer)

CONCEPTUAL MODEL
4. Essentially the inline style divides styles into two categories, rules
in the head or preferably in a separate style sheet, exceptions inline.
Some designers (and particularily some visual editors) are not good at
making rules, for them  everything will be an exception. Apart from
excluding them from the good parties, there is nothing you can do about
that. That they use style="" instead of selector{} is a symptom, not a cause.

Yes, there will always be exceptions. I think I am very good at making
rules, but apart from a small class of documents like aircraft manuals,
documents will have parts with unique formatting you cannot generalize into
a rule (unless you count "a rule of one", which is essentially what an ID
selector is). For particularily unruly documents, the ID selectors will
crowd out the element and attribute selectors.

CODE-BASED EDITING AND VIEWING
5. It will be harder to keep the overview when you use code-based editors,
you have to check the style sheet for every element with an ID.
6. It will be slightly harder/slower to code, as you have to do that at two
separate positions, and you must generate a unique ID. 
7. It will be harder to suss out what a page is doing through "view source"
from a browser.



As for Microsoft, it would be easier not to believe it is the evil empire
if MS Office didn't spout such evil code (I'd add MS Frontpage 97 to that,
2000 has supposedly improved). To their defence, Office imports XML as well
as exports it, but that is no excuse to make Halloween XML. The existing
(standard compliant) mechanisms are good enough to encode a Word/Excel
document, but making Word/Excel simple and accessible is a scary thought up
through the management? Anyway, removing the style tag will only split the
mess into two (the style part at the top, the rest inline). That is
assuming that Microsoft will want to comply with XHTML 2.0 (or whereever
the deprecated style actually will be obsolete or unavailable).

Received on Wednesday, 23 February 2000 03:19:53 UTC