Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, 4 Oct 2011, Roland Steiner wrote:
> On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson <ian@hixie.ch> wrote:
> > 
> >  * Any case of taking an element with existing semantics (e.g. a <select>
> >   showing a list of countries) and replacing its presentation with
> >   something completely different (e.g. a map selector), where the exact
> >   binding could depend based on media queries (e.g. different UIs for
> >   tablets vs TVs) or alternative style sheet selections (e.g. the user
> >   picking a high-contrast view rather than a custom "cool" one).
> 
> Well for one we already have HTML elements that do more or less the same 
> (<select> vs. <input type=radio>, <button> vs. <input type=button>), so 
> it doesn't seem such a stretch to me to allow <select> vs. <select 
> is="mapselect">.

Granted. A more obviously gratuitous case could be buttons that are given 
new styles. For example, Google has recently changed many of its sites to 
use <div>s instead of <button>s for its buttons because it wants a special 
look for them. This means that if you disable CSS, the entire UI 
collapses. The same would happen if they all use <x-google-fancy-button>. 
However, if the pages could just use regular semantics and then had the 
style loaded in dynamically via CSS, it could look exactly as it does now 
but with no loss of semantics.


> On a second note, what you essentially seem to demand is swapping out 
> entire HTML sub-branches based on presentation.

It's not how I would describe it (I wouldn't expect the shadow trees to be 
written using HTML), but to a first approximation, sure. This is pretty 
normal in terms of what changes to rendering trees look like. Today we 
swap in one branch or another using display:none or by direct DOM 
manipulation. It's more or less equivalent.


> It is IMHO not entirely a given that it's components who have to fulfill 
> this mechanism.

I'm fine with calling it something else. My point is just that the vast 
bulk of the mechanisms you need to create new widgets and the mechanisms 
you need to style existing widgets are essentially the same. So reusing 
the same solution makes sense.


> IOW, components could be seen as a neat, simple wrapping of a complex 
> DOM structure under a single element name (or binding attribute), and 
> the task of switching out different HTML trees (whether containing 
> components or not) could be handled by another, yet-to-be-specified 
> mechanism.

So long as we don't have to reinvent the wheel twice where the two 
mechanisms are the same, that's fine by me.


> This incidentally would also solve the security issue you mentioned in 
> conjunction with CSS bindings.

How so? The security problem isn't specific to any particular solution, 
it's a generic issue of invoking script from CSS. The solution to it is 
trivial (pre-declare the bindings in the markup).


> > > <X-MYWIDGET>
> > >
> > > - best performance (in instantiation, CSS selector matching)
> >
> > I don't see why it would be more performant, can you elaborate on 
> > that?
> 
> Instantiation: for <button is=mywidget> I assumed there is a gap during 
> parsing when a <button> is instantiated, then later is expanded/replaced 
> when the "is" attribute is read.

No, I am proposing it all happens at once.


> CSS Selector matching: WebKit at least has a fast path for element 
> names, but not for attribute matches. So "button[is="mywidget"] { color: 
> red; }" would be slower than "x-mywidget { color: red; }". (The former 
> also requires up to 2 comparisons - attribute value and element name - 
> besides.)

There's no reason we couldn't also optimise for "is". So [is=mywidget] 
could be just as fast as "x-mywidget". (No need for the attribute selector 
to include the element name.)


> > button { BINDING: MYWIDGET; }
> >
> > > - shadow DOM dependent on rendering tree (something we explicitly 
> > > wanted to avoid)
> >
> > It's dependent on the style resolution, not the rendering tree.
> 
> Right, but the point still stands: We'd have a DOM tree "hanging off" 
> (be dependent on) something that isn't the DOM. This was the case 
> previously in WebKit before we started with the whole shadow DOM 
> approach, and caused a lot of headaches.

Could you elaborate? I don't see what the problems are here. We already 
have plenty of mechanisms that can introduce rendering content without the 
DOM tree being involved, e.g. ::before/::after, 'content' on elements, 
display: list-item, etc. If this is causing problems in WebKit, it seems 
like something that needs to be fixed in WebKit regardless of whether we 
explicitly support bindings or not.


> > - unclear what happens if a HTML element with (intrinsic or explicit)
> >   shadow DOM is assigned a CSS binding as well
> >
> > It doesn't have to be unclear, it just has to be defined. There are 
> > two obvious options: replace it, or augment it. XBL2 supported both.
> 
> TBH, XBL2's answer to multiple bindings felt rather hand-wavey to me - 
> it assumed that an arbitrary intrinsic order would work in all 
> circumstances, and that the various bindings wouldn't end up clobbering 
> each other on application.

I'm not arguing that XBL's solution was good; I'm arguing that your point 
above is wrong: it doesn't have to be unclear. We just have to define it.


> Specifics aside, it's also a fundamental question how to address 
> multiple applicable CSS bindings that may be mutually exclusive - e.g., 
> a layout manager component gets both a "vertical" and "horizontal" 
> layout binding from different rules.

The CSS cascade solved this in 1996. Only one value applies after the 
cascade is performed. I don't think there's a problem here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 10 October 2011 20:01:57 UTC