- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 4 Oct 2011 03:38:28 +0000 (UTC)
- To: Dominic Cooney <dominicc@google.com>, Roland Steiner <rolandsteiner@google.com>, Brian Kardell <bkardell@gmail.com>
- cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <eoconnor@apple.com>, public-webapps@w3.org
- Message-ID: <Pine.LNX.4.64.1110040315370.20981@ps20323.dreamhostps.com>
On Fri, 30 Sep 2011, Dominic Cooney wrote:
> >
> > My point was just that the parsing differences have nothing to do with
> > whether you're creating a component that inherits from HTMLElement.
> > There are parsing issues regardless of where in the DOM you are.
> > Parsing issues which disappear entirely if we simply require authors
> > to declare the bindings using a content attribute at creation time
> > rather than allowing authors to invent new tag names.
>
> I agree that the parsing of x-foo and div are different, but is it an
> issue?
Well, it is if you want to be able to binding anything but phrasing-level
elements that have no built-in semantics. But that seems rather limiting.
> > What I'm proposing based on the feedback on this thread is that we
> > have two binding mechanisms. The first is via 'binding' in CSS, and
> > that binding mechanism only binds a shadow tree, style sheet, and
> > event handlers.
>
> If I get this right, you are trading off letting the binding add API for
> letting the bindings change dynamically? What use case is served by the
> binding changing dynamically?
* Layout Manager (since the layout is something that should be
controlled primarily from CSS, and can change dynamically based on
different media queries matching or on the user changing the selected
alternative style sheet set).
* Rendering Form Controls with SVG (since the idea is to change the
style of the widget to fit the site theme, and so again the exact
rendering might change based on media queries or alternative style
sheet selections).
* 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).
> > The second is via an attribute that must be set during element
> > creation, and that one can bind a shadow tree, style sheet, event
> > handlers, and a new API; such a binding is permanent for the lifetime
> > of the element.
>
> I like this part—particularly the permanent aspect. What’s the _one_
> datum that is always present in every mode of element
> creation—parsing, document.createElement, etc.?
It doesn't matter what's available now. What matters is what we can make
available when we implement the component feature.
One feature that can be made available across both the API and the parser
is a content attribute.
> > Plus, for security reasons, any bindings attached via CSS must be
> > explicitly mentioned in the document's <head> somehow before they will
> > be allowed to run script.
>
> Can you elaborate on the security reason? An attacker can hijack the
> page through CSS+binding injection and lie in wait for an event?
http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0699.html
> I think it will be confusing for authors to have one binding (eg
> mywidget) than can be applied three ways, and one of the three ways has
> very different effects (CSS-specified bindings are dynamic, the other
> two are static; CSS bindings can’t touch API, the other two can.)
I don't mind if we use syntax in the binding definitions that make certain
bindings only usable in CSS and some only usable from the DOM.
e.g. if we define a binding with an element <binding>, it could be like:
<binding id="mywidget" kind="presentational">
<!-- defines a presentational binding, one that just changes the look
and feel but not the API; can only be bound from CSS -->
vs:
<binding id="mywidget" kind="semantic">
<!-- defines a semantic binding, one that can provide a new API but
is always bound at element creation time and can never be unbound;
can only be bound from is="" attribute at element creation time -->
Or maybe we can make a virtue out of a problem -- one issue with is="" is
that it's possible to bind something to an element that it was not
designed for, e.g. binding a widget binding that augments HTMLInputElement
to a <textarea>. So we could say:
<binding id="mywidget">
<!-- defines a presentational binding, one that just changes the look
and feel but not the API; can only be bound from CSS -->
vs:
<binding id="mywidget" for="input">
<!-- defines a semantic binding, one that can provide a new API but
is always bound at element creation time and can never be unbound;
can only be bound from is="" attribute at element creation time
and can only be bound to <input> elements -->
On Mon, 3 Oct 2011, Roland Steiner wrote:
>
> If I may briefly summarize the pros and cons of every approach
> discussed:
>
> <X-MYWIDGET>
>
> Pros:
> - element name is inherently immutable
> - can provide arbitrary API, can (but does not have to) derive from
> arbitrary HTML element
> - best performance (in instantiation, CSS selector matching)
I don't see why it would be more performant, can you elaborate on that?
> Cons:
> - accessibility only for shadow tree contents, no accessibility for host
> element unless ARIA roles are specified
> - parsing issues in special circumstances (<table>, auto-closing <p>, etc.)
I don't think <p> is a "special circumstance".
> - no/limited fallback (limited: user provides fallback as content of
> <X-MYWIDGET>, won't work in special places like within tables)
> - makes it easy to conflate semantics and representation
>
>
> <button IS=MYWIDGET>
>
> Pros:
> - fallback behavior as per HTML element
> - accessibility as per HTML element + shadow tree contents
> - binding only at creation, or immediately thereafter
> - API is that of host element, +alpha
> Cons:
> - add'l APIs ignored for accessibility
I'm not sure what this means. I would have thought the with-binding
accessibility would be at least as good as the <x-foo> case; better if you
bind to an element that already has some semantics and just augment them.
> - harder to implement: there's a window during parsing (before reading
> the button) where it's still an ordinary button, requiring binding to be
> added afterwards
I don't see why this would have to be true. In fact it could work exactly
like the x-foo approach. That's just an implementation detail.
> - immutability of 'is' attribute not immediately obvious to authors
It'll be pretty obvious when they try and it doesn't do anything. :-)
> - unclear what happens if a HTML element with intrinsic shadow DOM is
> assigned a CSS binding
We can just disallow it, as per above.
> button { BINDING: MYWIDGET; }
>
> Pros:
> - fallback behavior as if un-styled
> - accessibility
> - mutability depending on medium, etc.
> - host element stays unchanged
> Cons:
> - dynamic binding is hard to implement
It doesn't have to be. In particular, now that we have the event loop
specified we can just specify how this works asynchronously.
> - shadow DOM dependent on rendering tree (something we explicitly wanted
> to avoid)
It's dependent on the style resolution, not the rendering tree.
> - API immutable that of host element
Isn't that an advantage?
> - 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.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 4 October 2011 03:41:44 UTC