[whatwg] style='' on every element

Re: http://krijnhoetmer.nl/irc-logs/whatwg/20070503

First, I hope that we are in agreement that the following are realities:
  * Browsers will have to support style='' on every element.
  * When you make something a critical mass of authors really want to  
do non-conforming because it is bad, the authors find worse  
workarounds that are not caught by checkers. Case study: target=''  
vs. window.open().
  * <font> with a transparent content model is not backwards- 
compatible with existing Gecko text/html parsing.
  * When a conformance definition outlaws something that works and  
that a critical mass of authors want to do, the respect for the  
conformance definition as a whole is diluted.
  * Defining two conformance levels (ideal and realistic) doesn't  
eradicate the difference of realistic and idealistic. Case study:  
Strict and Transitional.
  * The way <font style=''> has been currently drafted is a political  
failure, because instead of attaching the stigma of <font> to  
style='' it has attached the stigma of <font> to HTML5.
  * As implemented, style='' doesn't provide for media query-scoped  
styling.

> # # [19:40] <Hixie> hsivonen: so, my requirements for the <font>/ 
> style="" thing is that style="" not be allowed everywhere, since  
> that encourages media-specific markup.

<font style=''> does not address this problem at all technically. If  
anything, it makes things worse for compat with legacy Gecko. In  
addition, the political facet of not encouraging seems to be failing  
spectacularly.

> # # [19:41] <Hixie> hsivonen: however, i acknowledge that we have  
> to deal with WYSIWYG UAs that don't have any proven-usable way to  
> encode author intent

Agreed.

> # # [19:41] <Hixie> hsivonen: i'm open to suggestions, but putting  
> style="" everywhere only deals with the use case of one of the  
> camps involved in the discussion

The camp opposing presentational features consists of authors who  
want to legislate what other authors can do. That's not a use case.

Specific consumer use cases could legitimize forbidding authors from  
doing something that breaks the consumer use cases, but on the Web  
prohibitions need to come with incentives in order to work.

> # # [19:44] * zcorpan thinks that disallowing style="" on any  
> element results in not using any other element than <font>, thus  
> resulting in even worse media independence
> # # [19:45] <zcorpan> e.g. instead of <h1 style> wysiwyg tools  
> would just emit <font style>

Agreed.

> # # [19:50] <Hixie> wysiwyg tools can use the new embedded <style>  
> and IDs or classes with <div>s and <p>s

This would break backwards compat from the point of view of the tools  
and would also complicate the tools.

> # # [19:51] <Hixie> the thing is wysiwyg tools are a unique case,  
> and what we allow for wysiwyg tools shouldn't apply to templates,  
> hand-written content, etc

I suggest we deal with this by using conformance checker warnings as  
opposed to errors. More at the end of this message.

> # # [19:53] <zcorpan> Hixie: the result will be that those who hand- 
> write templates will add the <meta> to claim that they are wysiwyg.  
> so they can use style="" and pass validation
> # # [19:53] <zcorpan> q.v. transitional doctype and target=""
> # # [19:53] <zcorpan> *or* they will come up with uglier hacks
> # # [19:53] <zcorpan> q.v. adding target="" with javascript
> # # [19:56] <zcorpan> so if we find that we need to allow something  
> for wysiwyg, it has to be conforming for anyone (yet we can  
> discourage or say that authors SHOULD NOT do it or whatever, but  
> trying to force them not to will lead to the same path as target=""  
> situation today, i think)
> # # [19:59] <zcorpan> or say that it isn't conforming but say that  
> wysiwyg tools can emit it anyway
> # # [20:00] <zcorpan> what i'm saying is that the wysiwyg meta tag  
> is the new transitional doctype

Exactly!

> # # [20:22] <othermaciej> zcorpan: isolating the use of purely  
> presentational inline markup seems to have some value

I agree that the ability to isolate style='' is a desirable  
conformance checker feature. Some authors (including myself) want to  
catch and purge unrequested style='' generated by WebKit, Nvu, OOo,  
etc. in order to avoid interference with deliberate styling.

> # # [20:25] <Hixie> the problem with style="" is that it encourages  
> thinking in a media-specific way

I think you are reversing causality here.

> # # [20:25] <Hixie> imho
> # # [20:25] <Hixie> i mean we have inline <style> elements now
> # # [20:25] <Hixie> that go almost anywhere
> # # [20:25] <Hixie> and are scoped
> # # [20:25] <Hixie> why use style=""?

For backwards compat and for locality (both for humans and editors  
that need to keep track of the styles).

> # # [20:28] <Hixie> i agree that the magic <meta> thing sucks

Not necessarily as a conformance checker pragma for indicating that  
you want to suppress certain *warnings*.

> # # [20:33] <Hixie> another possibility is to allow style="" on  
> <font> and <div>, and allow them everywhere

That would give an incentive to make even less semantic markup than  
if style='' was allowed on every element.

> # # [20:33] <othermaciej> at least some strict opponents of  
> presentational markup would like to eliminate <b>, <i> and <font>,  
> but have no problem with style=""

Indeed.

> # # [20:35] <othermaciej> Hixie: I'm not sure removing style="",  
> allowing it on <font> for WYSIWYG only, and adding scoped <style>  
> addresses any actual requirements

Agreed.

> # # [20:36] <Hixie> i don't think it makes sense to make style=""  
> apply to all elements (e.g. <head>)

It is easier to make it a global attribute than trying to limit it.  
In the latter case, you may inadvertently miss some use cases (that  
implementations will support anyway). Compare with what happened with  
id on root when the old HTML 4 WG presumably thought it didn't make  
sense.

> # # [20:38] <Hixie> the argument is that there's harm merely in  
> style="" existing

It will exist in UAs no matter what.

> # # [20:39] <bewest> I think the idea that style="" is allowed on  
> everything is currently in the mindshare of many authors, whether  
> or not it's used
> # # [20:39] <Hixie> i agree
> # # [20:39] * Hixie is hoping we can change that mindshare

> # # [20:42] <Hixie> maybe we can add two levels of conformance,  
> "five star conforming html5" and "four star conforming html5",  
> where the presence of a style="" attribute causes the document to  
> drop to four stars

> # # [20:42] <bewest> be careful of slipping down the rabbit hole  
> though
> # # [20:42] <othermaciej> sounds like a slippery slope

Perhaps a conformance checker *warning* could work without causing  
silliness like making conformance depend on a WYSIWYG/four-star/ 
Transitional flag.

> # # [20:45] <bewest> we have technology for doing feature  
> detection... schematron, griddl, etc...

Or just plain SAX plus if...else.

> # # [20:46] <zcorpan> if allowing style="" anywhere for anyone is  
> not acceptable, then the next best alternative as i see it is to  
> make it non-conforming for everyone but allow wysiwyg-tools to emit  
> it anyway

> # # [20:47] <Hixie> editing tools would never accept that

Right.

> # # [20:52] <Hixie> i really thing that style="" encourages worse  
> behaviour than <style>, but i have no evidence for that.
> # # [20:52] <Hixie> so i can't really argue the case.

:-)

> # # [21:01] <zcorpan> bewest: no, most people are using tables and  
> <font color> :)

While we're at it, in reality layout tables are less bad than CSS  
positioning for achieving similar goals.

> # # [21:01] <zcorpan> my issue is, if style="" becomes non- 
> conforming, then authors who use it today and want to pass  
> conformance-checking will try to replace it with something else  
> that does the same thing
> # # [21:02] <zcorpan> if that something else is more verbose or bad  
> in other ways then i don't see the win of making it non-conforming

+1 ;-)

> # # [21:05] <bewest> zcorpan: I'm not convinced that people would  
> opt for the nasty workarounds

Cf. target='' vs. window.open().

Considering all the above, here's my concrete proposal for a solution:
  1) Make style='' a global attribute. For the purposes of document  
conformance, make it conforming on all documents regardless how they  
came to being.
  2) Include an informative paragraph about how media-dependent use  
of style='' is bad.
  3) I make the conformance checker emit a warning (at most one per  
document) that paraphrases the informative paragraph when the  
conformance checker sees a style='' attribute.
  4) I make the WYSIWYG signature suppress the warning.

  5) <font> is either made non-conforming or made a strictly inline  
element with the attribute color (to avoid <span style='color: ...'>  
cruft).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

Received on Friday, 4 May 2007 02:53:15 UTC