W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: HTML element content models vs. components

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 28 Sep 2011 09:22:33 -0700
Message-ID: <4E8349C9.3080306@jumis.com>
To: Roland Steiner <rolandsteiner@chromium.org>
CC: WebApps WG <public-webapps@w3.org>, Dimitri Glazkov <dglazkov@chromium.org>, Dominic Cooney <dominicc@chromium.org>, Ian Hickson <ian@hixie.ch>
On 9/27/2011 11:39 PM, Roland Steiner wrote:
> Expanding on the general web component discussion, one area that 
> hasn't been touched on AFAIK is how components fit within the content 
> model of HTML elements.
> Take for example a list 
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-ul-element): 
>
>
> <ol> and <ul> have "Zero or more <li> elements" as content model, 
> while <li> is specified to only be usable within <ol>, <ul> and <menu>.
>
> Now it is not inconceivable that someone would like to create a 
> component <x-li> that acts as a list item, but expands on it. In order 
> to allow this, the content model for <ol>, <ul>, <menu> would need to 
> be changed to accomodate this. I can see this happening in a few ways:
>
>
> A.) allow elements derived from a certain element to always take their 
> place within element content models.
>
> In this case, only components whose host element is derived from <li> 
> would be allowed within <ol>, <ul>, <menu>, whether or not it is 
> rendered (q.v. the "Should the shadow host element be rendered?" 
> thread on this ML).
>
>
> B.) allow all components within all elements.
>
> While quite broad, this may be necessary in case the host element 
> isn't rendered and perhaps derivation isn't used. Presumably the 
> shadow DOM in this case contains one - or even several - <li> elements 
> as topmost elements in the tree.
>
>
> C.) Just don't allow components to be used in places that have a 
> special content model.
>
>
> Thoughts?

Consider the CSS content model: we can easily override the model of 
various tags.
Then consider ARIA role types, where we can easily override the 
semantics of various tags.

I'm a big fan of using appropriate tag names, but I'm not convinced that 
HTML should restrict CSS or ARIA.
The HTML5 editor has repeatedly tried to enforce option C, restricting 
components in the DOM tree in relation to ARIA and HTML Canvas.

Why bother over-specifying? Why remove that flexibility?

HTML tag names are fantastic, I'm not saying lets just toss HTML, but I 
don't think HTML is the top of the hierarchy.
We have ARIA for semantics, CSS for display and DOM for serialization.


-Charles
Received on Wednesday, 28 September 2011 16:22:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT