Re: HTML element content models vs. components

+1

What Charles said = )

On Wed, Sep 28, 2011 at 5:22 PM, Charles Pritchard <chuck@jumis.com> wrote:

> 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<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
>
>
>