W3C home > Mailing lists > Public > www-html@w3.org > February 2000

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

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Sun, 20 Feb 2000 19:04:28 -0800
Message-Id: <200002210305.WAA06863@tux.w3.org>
To: Jelks Cabaniss <jelks@jelks.nu>, www-html@w3.org
>From: "Jelks Cabaniss" <jelks@jelks.nu>
>Date: Sun, Feb 20, 2000, 6:29 PM
> Inline and embedded styling have problems, but to put them in the legacy
> with FONT and frames -- at least at this point in time -- is, IMO, a stretch.

It's far worse than a stretch.

Some of us consider the STYLE attribute to be _perfectly valid_ (IMO since it
is part of a *REC* and it has proven its use by being *widely implemented* and
*widely used*, it is far more VALID than the myriad x*** pipe dreams being
dreamt up on the altar of purity).

> Especially since "XML Packaging" doesn't even show up as a blip on the radar
> screen.  Until that exists (*if* it ever exists),


> documents should be able to
> be shipped with rendering suggestions *in the instance*.
> The problem, as we all know, is a tendency toward the "div + span + inline
> styling = the new RTF" paradigm -- only DIVs, SPANs; no semantics.

agreed that that is a learning phase that many go through when first learning
the power of styling.

> Granted,
> that's an abuse.

that particular use may be an abuse, but there are many many legitimate
practical uses.  the amaya example mentioned previously is but one of them.

> But even as abused it's light years ahead of FONT, CENTER, and
> tag soup.

far far ahead.  and better for *usability* too, since CSS styling provides the
user a mechanism to override with a user style sheet, which plain default HTML
(or any markup for that matter) rendering does *not*.

> The modularization work is fantastic.  I'd hate to see it ignored by the tool
> vendors *and* the developers because inline/embedded styling was sacrificed
> prematurely on the altar of pure separation of content and presentation.

separation of content and presentation (and script and transform etc. etc.) is
*good* thing to *enable* and *encourage*, but not to *enforce*.  premature
deprecation will only offend and insult those authors and implementors who
have understand the proper time to use linked style sheets vs. inline style
sheets vs. inline styles.

and you're right about the ignoring part.  any technology or specification
which fails to be useful to the target customer *deserves* to be ignored.

spec writers should learn to *listen* to the customer or else suffer the same
fate of so many previous technologies/specs which were too "high-minded".

and speaking of listening, how many _professional web authors/designers_ have
posted to this list asking to *keep* the STYLE attribute?  i've seen several.

how many have asked for it to be removed / relegated to legacy because it
never should have existed in the first place?  don't hold your breath.

Murray Altheim wrote:
>> If you want to build a DTD using the Legacy module, you're welcome to
>> do so. The HTML WG position is that we are trying to be good web citizens,
>> and 1.1 therefore removes deprecated features

and in exactly which REC has the STYLE attribute been deprecated?  certainly
not in HTML4.

>> and those we feel are
>> counter to i18n, WAI, and other interoperability goals.

that's funny.  the i18n and WAI people that I work with see nothing wrong with
the STYLE attribute and in fact find it quite useful.

and if you want to talk WG positions, both the CSS&FP and SVG WGs prefer to
keep the STYLE attribute.  the "good web citizen" thing to do would be to keep
the STYLE attribute in the STYLE module as requested by these WGs.

> Two questions:
>  1) Was there consensus in the HTML WG on this?

as the Microsoft alternate representative to the HTML wg, I can tell you that
*we* certainly strongly disagree with removal and/or deprecation of the STYLE
attribute.  of course maybe I was late to the conversation.

>  2) Has the issue been "escalated"?

no idea.  see above note about technology being ignored.

Received on Sunday, 20 February 2000 22:05:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:53 UTC