Re: customized built-in element questions

[Dominic Cooney]

On Sun, Aug 21, 2016 at 12:02 PM, Mark Giffin  wrote:

> I have two questions I cannot seem to find the answer to in the Custom
> Elements spec,
> https://www.w3.org/TR/2016/WD-custom-elements-20160721/
>
> 1. Can I use the is= syntax for more than one customized built-in element,
> like ?


No.

It's an interesting possibility, but there's a practical problem with it,
which is: What prototype does the button get? big-button's, or red-button's?

If you write that today, what happens is the whole value is treated as a
potential name. There are lots of ways to create elements, but take create
an element for a token
,
which is used by parsing, for example. Step 3 takes the value of the entire
attribute but since "big-button red-button" isn't a valid name (it contains
a space) step 4 will never find a matching definition.

2. Is the is= syntax for using a customized built-in element likely to be
> deprecated sometime soon? I have heard only rumors.
>

I work on Chrome. Here are our plans at the moment:

- We have implemented the "autonomous custom elements" parts of this spec
(that is the  part, not the is="..." part); you can try it
today by enabling Experimental Web Platform Features in chrome://flags in
Chrome 54 or later. Feedback  welcome.
- We are debating whether to ship this now; you can follow the process
 in this
thread

.
- We implemented an earlier version of this spec, including "is". It uses
document.registerElement to define custom elements. We plan to remove this,
but we have a process for that too
 and we
probably can't remove it this year.
- We are implementing the "new" is="..." stuff right now. You should be
able to play with it behind a flag in a couple of months.


> Thanks,
> Mark
>

Re: [Custom Elements] Should I write v1 Custom Elements in a way backwards compatible with v0 API?

[Dominic Cooney]

I implemented custom elements in Chrome (twice.) This looks reasonable to
me.

The exact timing of createdCallback and constructor running, and errors
around element creation, are different. If authors stick to the
restrictions of custom elements "v1" they should be fine, because they're
more restrictive than v0.

On Sun, Aug 21, 2016 at 11:13 AM, /#!/JoePea  wrote:

> Due to the renaming of some class methods (attached/detached to
> connected/disconnected) and removal of createdCallback in favor of
> constructors (which is a good thing!), I find myself writing my
> WebComponent base class (class-factory mixin) as follows.
>
> My question is, should I be doing what I'm doing, or do you recommend
> something else? Note that the attached/detachedCallback methods simply call
> the connected/disconnectedCallback methods, and also note what I've done
> with `createdCallback` and the `constructor` due to the differences between
> v0 and v1. Subclasses of my WebComponent base class still use
> `createdCallback` rather than a constructor in order to be backwards
> compatible.
>
> The code is as follows, with parts removed for brevity in order to show
> just the parts dealing with the v0/v1 APIs directly and how backwards
> compatibility is maintained:
>
> // Very very stupid hack needed for Safari in order for us to be able
> to extend
> // the HTMLElement class. See:
> // https://github.com/google/traceur-compiler/issues/1709
> if (typeof window.HTMLElement != 'function') {
> const _HTMLElement = function HTMLElement(){}
> _HTMLElement.prototype = window.HTMLElement.prototype
> window.HTMLElement = _HTMLElement
> }
>
> // XXX: Maybe we can improve by clearing items after X amount of time?
> const classCache = new Map
>
> function hasHTMLElementPrototype(constructor) {
> if (!constructor) return false
> if (constructor === HTMLElement) return true
> else return hasHTMLElementPrototype(constructor.prototype)
> }
>

I'm not sure this is right. Would it be simpler anyway to just say
constructor && (constructor === HTMLElement || constructor.prototype
instanceof HTMLElement)?


> /**
>  * Creates a WebComponent base class dynamically, depending on which
>  * HTMLElement class you want it to extend from. Extend from
> WebComponent when
>  * making a new Custom Element class.
>  *
>  * @example
>  * import WebComponent from './WebComponent'
>  * class AwesomeButton extends WebComponent(HTMLButtonElement) { ... }
>  *
>  * @param {Function} elementClass The class that the generated
> WebComponent
>  * base class will extend from.
>  */
> export default
> function WebComponentMixin(elementClass) {
> if (!elementClass) elementClass = HTMLElement
>
> if (!hasHTMLElementPrototype(elementClass)) {
> throw new TypeError(
> 'The argument to WebComponentMixin must be a constructor
> that extends from or is HTMLElement.'
> )
> }
>
> // if a base class that extends the given `elementClass` has
> already been
> // created, return it.
> if (classCache.has(elementClass))
> return classCache.get(elementClass)
>
> // otherwise, create it.
> class WebComponent extends elementClass {
>
> // constructor() is used in v1 Custom Elements instead of
> // createdCallback() as in v0.
> constructor() {
> super()
>
> // If the following is true, then we know the user should
> be using
> // `document.registerElement()` to define an element from
> this class.
> // `document.registerElement()` creates a new constructor,
> so if the
> // constructor here is being called then that means the
> user is not
> // instantiating a DOM HTMLElement as expected because it
> is required
> // that the constructor returned from
> `document.registerElement` be used
> // instead (this is a flaw of Custom Elements v0 which is
> fixed in v1
> // where class constructors can be used directly).
> if (document.registerElement && !customElements.define) {
>
> // TODO: link to docs.
> throw new Error(`
> You cannot instantiate this class directly without
> first registering it
> with \`document.registerElement(...)\`. See an
> example at http://
> `)
>
> }
>
> // Throw an error if no Custom Elements API exists.
> if (!document.registerElement && !customElements.define) {
>
> // TODO: link to docs.
> throw new Error(`
> Your browser does not support the Custom Elements
> API. You'll
> n

Re: Custom elements backing swap proposal

[Dominic Cooney]

On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa  wrote:

>
> > On Oct 24, 2015, at 9:55 AM, Elliott Sprehn 
> wrote:
> >
> > I've been thinking about ways to make custom elements violate the
> consistency principle less often and had a pretty awesome idea recently.
> >
> > Unfortunately I won't be at TPAC, but I'd like to discuss this idea in
> person. Can we setup a custom element discussion later in the year?
>
> Certainly. I won't be back in the states until 11/8 and both Blink and
> WebKit are having their contributor's meetings in the following week so how
> about the week of November 16th?
>
> If not, the first and the second weeks of December also works.
>
> > The current  "synchronous in the parser" model doesn’t feel good to me
> because cloneNode() and upgrades are still async,
>
> I've been making a prototype of custom elements API in which cloneNode and
> all other internal construction of elements are sync so only upgrading is
> async in our design.
>
> > and I fear other things (ex. parser in editing, innerHTML) may need to
> be as well.
>
> Not in our design.
>
> > So, while we've covered up the inconsistent state of the element in one
> place (parser), we've left it to be a surprise in the others which seems
> worse than just always being async. This led me to a crazy idea that would
> get us consistency between all these cases:
> >
> > What if we use a different pimpl object (C++ implementation object) when
> running the constructor, and then move the children/shadows and attributes
> after the fact? This element can be reused (as implementation detail), and
> any attempt to append it to another element would throw.
>
> This is not the first time this (or a similar) idea has been brought up.
>
> The problem with this approach is that authors can still find the old
> non-temporary "pimpl" (where did this term come from?) via
> querySelectorAll, getElementsByTagName, etc... because it's still in the
> document. (If it's not in the document, then we would have the iframe
> reloading problem)
>

I agree this is a problem.
document.querySelector('some-creating-custom-element').parentNode being
null is surprising.

esprehn, could your proposal be spec'ed equivalently by saying that the
APIs which look up the tree (parentNode, etc.) return null during "creation
time"?


> And when the constructors or unrelated code invoked by the constructor
> access the old "pimpl", we have two options:
>
> 1. Use the same wrapper as the one we're creating.  This is weird because
> the element as perceived by other DOM APIs such as querySelectorAll and the
> actual object behaves differently.
>
> 2. Create a new wrapper. But what are we going to do this with new wrapper
> when we swap back "pimpl" after calling the constructor?  Also, this would
> mean that the identify of elements will change.
>
> There is yet another alternative: make all other DOM APIs behave as if
> these pre-construction custom elements don't exist. However, that is a much
> tricker thing to implement (especially if you didn't want to worsen the
> performance) than making all construction sync at least in WebKit.
>
> - R. Niwa
>
>
>

Re: Custom Elements: "createdCallback" & cloning

[Dominic Cooney]

On Mon, Jul 13, 2015 at 4:32 AM, Olli Pettay  wrote:

> On 07/12/2015 08:09 PM, Anne van Kesteren wrote:
>
>> On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney 
>> wrote:
>>
>>> I think the most important question here, though, is not constructors or
>>> prototype swizzling.
>>>
>>
>> I guess that depends on what you want to enable. If you want to
>> recreate existing elements in terms of Custom Elements, you need
>> private state.
>>
>
Yes. I am trying to interpret this in the context of the esdiscuss thread
you linked. I'm not sure I understand the problem with private state,
actually. Private state is allocated for DOM wrappers in Chromium today
(like Gecko), including Custom Elements; it's not a problem. DOM wrapper
creation is controlled by the UA, which can arrange for allocating the
slots.

Is there a plan for author classes to be able to have private state or
something?


>>  - Progressive Enhancement. The author can write more things in markup and
>>> present them while loading definitions asynchronously. Unlike progressive
>>> enhancement by finding and replacing nodes in the tree, prototype
>>> swizzling
>>> means that the author is free to detach a subtree, do a setTimeout, and
>>> reattach it without worrying whether the definition was registered in the
>>> interim.
>>>
>>
>> How does this not result in the same issues we see with FOUC? It seems
>> rather problematic for the user to be able to interact with components
>> that do not actually work, but I might be missing things.
>>
>
Although you mention FOUC, this isn't the same as FOUC because the
component can be styled (particularly with :unresolved). But as you go on
to mention, there is the question of interactivity. Here are my
observations:

- In some cases, the user may not care that the component is briefly not
interactive. For example, have you noticed that the GitHub "3 days ago"
labels don't have their definitions briefly?

- In some cases, the author can continue to use things like onclick
attributes to provide some fallback interactivity.

- In the majority of cases, you have to ask what's better. Is it better to
have some presentation (like an :unresolved rule showing a loading spinner,
maybe with animated transitions to the interactive state) with the page
scrollable and other things interactive, or a blank page blocked on
definitions?

 - Fewer (no?) complications with parsing and cloning. Prototype swizzling
>>> makes it possible to decouple constructing the tree, allocating the
>>> wrapper,
>>> and running Custom Element initialization. For example, if you have a
>>> Custom
>>> Element in Chromium that does not have a createdCallback, we don't
>>> actually
>>> allocate its wrapper until it's touched (like any Element.) But it would
>>> not
>>> be possible to distinguish whether a user-provided constructor is trivial
>>> and needs "this."
>>>
>>
>> True true.
>>
>>
>>  Could you share a list of things that use the cloning algorithm?
>>>
>>
>> In the DOM specification a heavy user is ranges. In turn, selection
>> heavily depends upon ranges. Which brings us to editing operations
>> such as cut & copy. None of those algorithms anticipate the DOM
>> changing around under them. (Though perhaps as long as mutation events
>> are still supported there are some corner cases there, though the
>> level of support of those varies.)
>>
>
Thanks. I can understand how editing and Range.cloneContents would use
cloning. How is it relevant that Range is depended on by Selection?
Selection may delete things but it does not clone them.


> In Gecko printing also clones the tree and definitely does not expect
>> that to have side effects.
>>
>
> Well, this printing case would just clone the final flattened tree without
> the original document knowing any cloning happened.
> (scripts aren't suppose to run in Gecko's static clone documents, which
> print preview on linux and Windows and printing use)
>
>
> If one needs a special DOM tree for printing, beforeprint event should be
> used to modify the DOM.
>
>
>
>  Note that this would break with prototype
>> swizzling too. Or at least you'd get a less pretty page when
>> printing...
>>
>>
>>  What do you mean by mode switch?
>>>
>>
>> That during cloning certain DOM operations cease to function, basically.
>>
>
This sounds interesting; it may even be useful for authors to be able to
assert that between two points they did not modify the DOM.

Re: Custom Elements: "createdCallback" & cloning

[Dominic Cooney]

On Thu, Jul 2, 2015 at 4:05 PM, Anne van Kesteren  wrote:

> In the interest of moving forward I tried to more seriously consider
> Dmitry's approach. Based on es-discussion discussion
> https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors
> it seems likely new JavaScript features (such as private state) will
> be tied to object creation. This makes the prototype-swizzling design
> even less appealing, in my opinion.
>

Ironically this is a minor reason that Chromium preferred prototype
swizzling to "blessing" author-provided constructors:

When allocating JavaScript objects to wrap DOM objects ("wrappers"),
Chromium adds extra internal space to hold the address of the corresponding
C++ object. (V8 calls this "extra internal space" mechanism an "Internal
Field"
.)
This is efficient (the space is accessed by offset; they don't have names
like properties do) and private (this mechanism is ancient--it predates
symbols--and is inaccessible to JavaScript because the space has no name
and is separate to how properties are stored.)

Because Custom Elements did not change how wrappers were allocated, Custom
Elements wrappers in Chromium continue to have the necessary extra storage
space. Because the Custom Element constructor was controlled by the user
agent, we could ensure that it used the same mechanism for allocating
wrappers.

We can't do that with a user-provided constructor, because V8 has already
allocated the object (for "this") by the time the constructor starts to
run. Any solution in this space may force Chromium to allocate an
additional object with the extra space. This may not be a disaster because,
first, generational GC makes allocating lots of short-lived objects
relatively cheap; and second, like Objective-C, JavaScript allows
constructors to return a different object (and my understanding is that
doing this in an ES6 constructor effectively sets "this".) But it is a bit
gross.

Around summer 2012? 2013? I experimented with using a Symbol-like thing
(which V8 calls Hidden Fields) to store the pointer to the C++ object on
Custom Element wrappers in Chromium. (So those wrappers had a different
shape to most element wrappers.) We felt this design was not feasible
because it was slower to access, made the objects larger, and complicated
Chromium's DOM bindings which now needed to fall back to checking for this
property.

I think the most important question here, though, is not constructors or
prototype swizzling. It's whether elements created before a definition is
available get enlivened with the definition when it is available. I don't
like prototype swizzling, but I do like what it lets us do:

- Progressive Enhancement. The author can write more things in markup and
present them while loading definitions asynchronously. Unlike progressive
enhancement by finding and replacing nodes in the tree, prototype swizzling
means that the author is free to detach a subtree, do a setTimeout, and
reattach it without worrying whether the definition was registered in the
interim.

- Fewer (no?) complications with parsing and cloning. Prototype swizzling
makes it possible to decouple constructing the tree, allocating the
wrapper, and running Custom Element initialization. For example, if you
have a Custom Element in Chromium that does not have a createdCallback, we
don't actually allocate its wrapper until it's touched (like any Element.)
But it would not be possible to distinguish whether a user-provided
constructor is trivial and needs "this."

It's a tradeoff. There are definite disadvantages to the current
specification; prototype swizzling is one of them. Not sure if that
background is useful...


> Meanwhile, I have not made much progress on the cloning question. As
> Domenic pointed out, that would also either require
> prototype-swizzling or invoking the constructor, there's not really a
> third way. I guess for that to work cloneNode() and various editing
> operations would have to become resilient against JavaScript executing
> in the middle of them,


Could you share a list of things that use the cloning algorithm?


> something that has caused (is causing?) us a
> ton of headaches with mutation events. (Or the alternative, have some
> kind of mode switch for the DOM which is similarly a large
> undertaking.)
>

What do you mean by mode switch?


> Not sure what to do now :-/
>
>
> --
> https://annevankesteren.nl/
>
>

Re: Custom Elements: is=""

[Dominic Cooney]

On Thu, Jul 2, 2015 at 3:59 PM, Ryosuke Niwa  wrote:

>
> > On Jun 13, 2015, at 4:49 PM, Léonie Watson 
> wrote:
> >
> > From: Bruce Lawson [mailto:bru...@opera.com]
> > Sent: 13 June 2015 16:34
> >
> > On 13 June 2015 at 15:30, Léonie Watson 
> wrote:
> >> why not use the extends= syntax you mentioned?
> >>
> >> Push
> >
> > because browsers that don't know about web components wouldn't pay any
> attention to , and render "Push" as plain text.
> >
> > Of course! I should have thought of that.
>
> That's not entirely true.  If the implementation of my-button, let us call
> it MyButtonElement had the prototype that extends HTMLButtonElement, then
> the browser can set role=button just fine.


Excuse the intrusion, but I'm slightly confused by at least one point.
Maybe you could help me clear it up. It's related to what you term "the
implementation of my-button". What is that? Is it something defined by the
web author (how?) or the user agent?

Sincerely,

Dominic

Re: Custom Elements: insert/remove callbacks

[Dominic Cooney]

On Thu, May 7, 2015 at 4:43 PM, Anne van Kesteren  wrote:

> On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
>  wrote:
> > How are you supposed to tell if one of your ancestors was removed?
>
> Is that a hook builtin elements have today?


Blink's built-in elements' hook is "inserted into"/"removed from document",
including via an ancestor being manipulated as you can see here
(this--Node::removedFrom--is the "removed" case):

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/ContainerNode.cpp&sq=package:chromium&type=cs&l=834&rcl=1430970612

This is overridden 68 times by various kinds of nodes including many
elements. What it's used for varies; one example is the HTMLMarqueeElement
that stops a callback that's driving its animation. If you were trying to
implement MARQUEE as a Custom Element, you'd want this callback to call
clearTimeout, cancelAnimationFrame, or whatever.

There are similar hooks and uses for insertion.

The HTML spec itself points to a lot of uses for this; when it switches on
things being "in a document"  and
something needs to be done/updated/etc. to implement that effect.


>
> --
> https://annevankesteren.nl/
>
>

Re: [Imports] Considering imperative HTML imports?

[Dominic Cooney]

On Thu, Apr 16, 2015 at 1:37 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Was an imperative form of HTML imports already considered? E.g., the
> following springs to mind:
>
>   Promise importDocument(DOMString url);
>
>
>
> I was thinking about Worker’s importScripts(DOMString… urls), and the
> above seems like a nice related corollary.
>

One big difference, I'm assuming, is whether it's asynchronous. Returning a
Promise kind of implies that importDocument may be/is asynchronous.

The trend seems to be away from adding synchronous APIs, but then you can't
express  (ie no 'async') using this API. I
think the declarative, script-blocking element is more palatable than a
synchronous method because the UA can process it when there's no user
script running.

Dominic

Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

[Dominic Cooney]

On Fri, Mar 27, 2015 at 2:53 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Hi folks,
>
>
>
> Today’s ShadowDOM model is designed around only adding shadow roots to
> element in the ‘light side’. I assume this is intentional, but was hoping
> someone could describe why this design was chosen? Or said another way, if
> there was an imperative API to _*remove*_ a shadow DOM, would that
> symmetry be bad?
>
>
>
> In full transparency, I’m thinking about potential solutions for a
> simplified shadow dom,
>

Could you share some background on how we should gauge simplicity? What you
have sketched here is less expressive than Shadow DOM (for example, it
can't do what the  element does.) That's not necessarily good or
bad, but it depends on what you're aiming for.


> and it occurs to me that it can’t get much simpler than the following:
>
> ·Elements only [ever] have one “shadow side” which is essentially
> a secondary child node list. Whenever anything’s in this list the Element
> renders that content instead of its “light” children. (Or maybe there’s a
> switch to tell the element which side to render: light or dark?)
>
> ·Elements expose this “shadow node list” via APIs that are very
> similar to existing node list management, e.g., appendShadowChild(),
> insertShadowBefore(), removeShadowChild(), replaceShadowChild(),
> shadowChildren[], shadowChildNodes[].
>
> ·No special Event swizzling, no security boundary, no alternate
> script engine, no intermediate shadow root object,  etc. This minimalist
> approach only provides node ‘hiding’ and potentially an alternate rendering
> path.
>
Along these lines, an ancient debate was whether the boundary of the
component was just "inside" the host element or just outside it (so,
imagine a 1:1 swap of element for its shadow twin element.) But whether
this is simplified or not is a very complex question.

>  ·Another feature could then provide the stronger “component”
> boundary, specifically the javascript global scope isolation. This
> delineation may more closely match the division we are seeing between the
> “React-like” scenarios and more robust component-kitchen-style custom
> element deployments.
>
>
>
>
>

Re: CustomElement: Type extension on custom tag

[Dominic Cooney]

Hi Joshua,

I implemented Custom Elements in Chrome.

In the definition construction algorithm
,
step 8.2, it says:

"If BASE does not exist or is an interface for a custom element, set ERROR
to InvalidName and stop."

In this case, BASE is the x-button and it is an interface for a Custom
Element. I think this is the case you're hitting. I think Chrome roughly
matches the spec in this case.

It's another question whether the spec could be changed to allow this. As
an implementer, I would need to know if/what order each of the callbacks
for x-button and x-submit-button were called in when something happened to
an x-submit-button. There are also interesting cases like what happens if
the x-submit-button is registered before the x-button, and whether other
things are possible like type extensions that extend other type extensions.

In short, step 8.2 avoids a lot of potential complexity by limiting what
you can do with Custom Elements in this specific way.

Dominic

On Fri, Oct 17, 2014 at 7:36 AM, Joshua Peek  wrote:

> Is it legal to register a type extension on top of an existing custom tag?
>
>   
>
>   var ButtonPrototype = Object.create(HTMLElement.prototype)
>   document.registerElement("x-button", {prototype: ButtonPrototype})
>
>   var SubmitButtonPrototype = Object.create(ButtonPrototype)
>   document.registerElement("x-submit-button", {extends: "x-button",
> prototype: SubmitButtonPrototype})
>
>
> Chrome's native registerElement doesn't seem to like this. It throws
> the following error.
>
>   DOMException: Failed to execute 'registerElement' on 'Document':
> Registration failed for type 'x-submit-button'. The tag name specified
> in 'extends' is a custom element name. Use inheritance instead.
>
>
> The current Custom Element spec doesn't say any specific about this
> situation. Is Chrome wrong? Or is this something the spec should
> explicitly disallow?
>
>

Re: Custom-elements: document.registerPolyfillElement ?

[Dominic Cooney]

On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir  wrote:

>  I was looking to make a genuine polyfill for  (not just a shim),
> and I found Polymer's CustomElements helpful, but realized too late that
> the spec required "x-" prefixes.
>
> I still feel like it would be useful to have a means for polyfills to be
> built according to well-recognized semantics via a standard extension
> mechanism.
>

It is possible to do this using a "type extension". For example:

document.register('x-polyfill-dialog', {prototype: ..., extends: 'dialog'})

This produces a type extension of the HTMLUnknownElement with the tag name
"dialog" in browsers that don't support dialog, and a type extension of the
HTMLDialogElement of ones that do.

The only wrinkle is that markup must use .

Your polyfill can degrade gracefully in whichever way you decide. For
example, you could detect HTMLDialogElement and not register the Custom
Element, in which case the markup will create unresolved type extensions of
HTMLDialogElement that get the browser's native dialog. Or you could go
ahead and register your polyfill anyway, in which case your prototype
object would hide the browser's HTMLDialogElement prototype. Or you could
do something dynamic inbetween.

HTH,

Dominic

Re: Custom element callbacks timing

[Dominic Cooney]

My understanding is that these callbacks can be invoked at roughly two
points in time:

The first one is when the browser is about to return to script. An example
is:


x.setAttribute('a', 'b');
// before here
...


If x is a Custom Element with an attributeChangedCallback, setAttribute
will queue an attributeChangedCallback; when returning to script x's
callback queue will be processed. Of course there are APIs, like setting
innerHTML, which can queue work for >>1 element.

The second one is when performing a microtask checkpoint. An example is:



If X-A has a Custom Element definition, the parser will queue an upgrade
step. At the next microtask checkpoint that element's callback queue will
be processed.

If you're having a discussion about callbacks in the context of microtasks,
that latter case, plus Mutation Observers, are probably of interest to you.

HTH,

Dominic


On Wed, Jan 29, 2014 at 7:41 AM, Anne van Kesteren  wrote:

> Can someone explain me, ideally in terms of examples, when these
> callbacks are invoked:
>
> http://w3c.github.io/webcomponents/spec/custom/#enqueuing-and-invoking-callbacks
> Are these different from microtasks? The way the specification reads
> at the moment suggests they are. If that is the case I'd prefer we
> have some more high-level discussion about introducing a new point
> when we want to call callbacks for DOM methods.
>
>
> --
> http://annevankesteren.nl/
>
>


-- 
Email SLA  •
Google+

Re: Custom form elements (was Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax))

[Dominic Cooney]

On Fri, Dec 13, 2013 at 5:59 PM, Maciej Stachowiak  wrote:

>
> On Dec 7, 2013, at 4:38 PM, Dominic Cooney  wrote:
>
>
>>
> Built-in HTML elements have lots of hooks to modify their behaviour (for
> example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
> Java class which has private and public final members, but no protected or
> public non-final ones.
>
> If someone were to make proposals about adding more hooks to the web
> platform to enable more subtyping use cases (for example, a protocol for
> participating in form submission) I would look forward to working with them
> on those proposals.
>
>
> Let's say you have the ability to define a custom element inheriting from
> a form element, but completely replace its rendering and behavior with
> custom shadow DOM.
>
> Is that actually sufficient to participate correctly in form submission?
>

I think subtypes of HTMLInputElement with Shadow DOM can participate in
form submission by stuffing the value to submit into the "base" input
element by setting value.


> I don't think it is. In particular, I don't see how a custom element could
> inherit from HTMLInputElement, fully support the interface, and correctly
> submit a value that is specified via a completely custom mechanism.
>

You are correct; a Custom Element could not implement HTMLInputElement
without heavily relying on the built-in HTMLInputElement. Participating in
a limited way by setting HTMLInputElement.value will work, but providing
hooks into the form submission process would enable more use cases.


> Also, even if it worked, inheriting from HTMLInputElement is a
> particularly clunky approach to participating in form submission. To
> actually correctly support the interface, you need your component to
> support every input type. But that is way overkill if you only want to
> replace a single kind of input, or define a new type of your own. The more
> convenient approach would be to ignore type-switching and as a consequence
> make a "subclass" that does not respect the Liskov Substituton Principle
> and is therefore bad OO.
>

I think HTMLInputElement is poorly designed; it effectively changes its
type in response to changes in the type attribute. So marrying anything
"classy" onto that will get messy.

If there was a protocol for participating in form submission, new form
input types could have different tags, just as SELECT is distinct from
INPUT.


> I think giving custom elements a specific API for participating in form
> submission, to enable defining new kinds of form elements, would be a
> better approach to this problem and ultimately easier to use. It is also
> much more relevant as a way to "explain how the way the Web platform
> works". Built-in form elements participate in form submission by having
> special hooks to participate in form submission, not by inheriting from
> other form elements.
>

I agree.
<http://goto.google.com/dc-email-sla>

Re: [custom elements] Improving the name of document.register()

[Dominic Cooney]

On Fri, Dec 13, 2013 at 5:44 PM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:

> I also really like defineElement. I am not sure that it is easy to
> understand what it actually means to "register an element", where as
> defining an element is pretty clear.
>
> Kenneth
>
> On Fri, Dec 13, 2013 at 9:40 AM, Maciej Stachowiak  wrote:
> >
> > Thanks, Google folks, for considering a name to document.register.
> Though a
> > small change, I think it will be a nice improvement to code clarity.
> >
> > Since we're bikeshedding, let me add a few more notes in favor of
> > defineElement for consideration:
> >
> > ...
> >
> > 2) registerElement sounds kind of like it would take an instance of
> Element
> > and register it for some purpose. defineElement sounds more like it is
> > introducing a new kind of element, rather than registering a concrete
> > instance of an element..
>

I find all of Maciej's points persuasive, but particularly this one (#2).

Given that Ted, Maciej, Ryosuke and Kenneth all expressed some degree of
preference for defineElement over registerElement, it should be seriously
considered.

Brian, Scott, what do you think of "defineElement"? There were some doubts
expressed about whether "define" reflects the imperative aspects of the
API, but at least "define" arguably has a more imperative flavor than
"declare".

I'd also like to hear what other vendors or developers think.

Dominic

Re: [custom elements] Improving the name of document.register()

[Dominic Cooney]

On Fri, Dec 13, 2013 at 2:29 AM, Brian Kardell  wrote:

>
> On Dec 11, 2013 11:48 PM, "Ryosuke Niwa"  wrote:
> >
> >
> > On Dec 11, 2013, at 6:46 PM, Dominic Cooney  wrote:
> >
> ...
> >>> El 11/12/2013 21:10, "Edward O'Connor"  escribió:
> >>>
> >>>> Hi,
> >>>>
> >>>> The name "register" is very generic and could mean practically
> anything.
> >>>> We need to adopt a name for document.register() that makes its purpose
> >>>> clear to authors looking to use custom elements or those reading
> someone
> >>>> else's code that makes use of custom elements.
> >>
> >> I think the method should be called registerElement, for these reasons:
> >>
> >> - It's more descriptive about the purpose of the method than just
> "register."
> >> - It's not too verbose; it doesn't have any redundant part.
> >> - It's nicely parallel to registerProtocolHandler.
> >
> >
> > I'd still refer declareElement (or defineElement) since registerElement
> sounds as if we're registering an instance of element with something.
>  Define and declare also match SGML/XML terminologies.
> >
> > - R. Niwa
> >
>
> Define/declare seem a little confusing because we are in the imperative
> space where these have somewhat different connotations.  It really does
> seem to me that conceptually we are registering (connecting the definition)
> with the parser or something.  For whatever that comment is worth.
>
While there's no consensus, I think this thread expresses a slightly
stronger preference for registerElement than other proposals. I have filed
this bug suggesting registerElement.

<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24087>

Dominic

Re: [custom elements] Improving the name of document.register()

[Dominic Cooney]

On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com wrote:

> I have seen registerProtocolHandler() and it's being discused
> registerServiceWorker(). I believe registerElementDefinition() or
> registerCustomElement() could help to keep going on this path.
>
> Send from my Samsung Galaxy Note II
> El 11/12/2013 21:10, "Edward O'Connor"  escribió:
>
> Hi,
>>
>> The name "register" is very generic and could mean practically anything.
>> We need to adopt a name for document.register() that makes its purpose
>> clear to authors looking to use custom elements or those reading someone
>> else's code that makes use of custom elements.
>>
>
I support this proposal.


> Here are some ideas:
>>
>> document.defineElement()
>> document.declareElement()
>> document.registerElementDefinition()
>> document.defineCustomElement()
>> document.declareCustomElement()
>> document.registerCustomElementDefinition()
>>
>> I like document.defineCustomElement() the most, but
>> document.defineElement() also works for me if people think
>> document.defineCustomElement() is too long.
>>
>>
I think the method should be called registerElement, for these reasons:

- It's more descriptive about the purpose of the method than just
"register."
- It's not too verbose; it doesn't have any redundant part.
- It's nicely parallel to registerProtocolHandler.

If I had to pick from the list Ted suggested, I think defineElement is the
best of that bunch and also an improvement over just "register". It doesn't
line up with registerProtocolHandler, but there's some poetry to
defineElement/createElement.


>> Ted
>>
>> P.S. Sorry for the bikeshedding. I really believe we can improve the
>> name of this function to make its purpose clear.
>
>
I searched for bugs on this and found none; I expect this was discussed but
I can't find a mail thread about it. The naming of register is something
that's been on my mind so thanks for bringing it up.

Dominic

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Dominic Cooney]

On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa  wrote:

> On Dec 8, 2013, at 4:42 PM, Dominic Cooney  wrote:
>
> On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa  wrote:
>>
>> On Dec 7, 2013, at 4:38 PM, Dominic Cooney  wrote:
>>
>> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa  wrote:
>>
>>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita  wrote:
>>> > On inheritance around HTMLElement family, there seems to be a
>>> confusion between interface side inheritance and implementation side
>>> inheritance.
>>>
>>> Right.  Differentiating the two is very important.
>>>
>>> > For Custom Elements, the inheritance is not only about interface, but
>>> also about implementation. The implementation is more complex and flux in
>>> detail, thus worth being shared between different elements. Actually, the
>>> implementation of built-in HTML elements, which are usually done in C++,
>>> uses inheritance heavily, at least Blink and (I believe) WebKit.
>>>
>>> The reason we can use inheritance heavily is because we have control
>>> over both parent and child classes, and there are careful distinctions
>>> between public, protected, and private member functions and member
>>> variables in those classes.
>>>
>>> Unfortunately, custom elements can't easily inherit from these builtin
>>> HTML elements because builtin elements do not provide "protected"
>>> functions, and they don't expose necessary hooks to override internal
>>> member functions to modify behaviors.
>>>
>>
>> Built-in HTML elements have lots of hooks to modify their behaviour (for
>> example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
>> Java class which has private and public final members, but no protected or
>> public non-final ones.
>>
>> If someone were to make proposals about adding more hooks to the web
>> platform to enable more subtyping use cases (for example, a protocol for
>> participating in form submission) I would look forward to working with them
>> on those proposals.
>>
>>
>> <http://goto.google.com/dc-email-sla>
>>
>> The problem here is that until such hooks are well defined, inheriting
>> from builtin elements doesn't make any sense. So let's not support that
>> until such proposal is made and implemented.
>>
>
> You assert that inheriting from built-in elements does not make any sense.
> You seem to base this on the claim that hooks (the example being form
> submission protocol hooks) are not well defined. Whether hooks are well
> defined or not doesn't sufficiently support your assertion, because:
>
> 1. Not all subtyping relies on hooks. For example, subtyping a built-in
> element can add additional API to it. This may make sense. For example, a
> social network "endorse" button has a number of additional properties. Yet
> it is (or could be) a button.
>
>
> If the only use case was to add new JavaScript property, then we wouldn't
> need custom elements at all.  Authors could already do this by simply
> adding properties on builtin elements.
>

If you do this on the Interface Prototype Object of a built-in element, the
API will appear on all elements of that type. So that is not a feasible
solution for many use cases.

If you try to do this on a per-instance basis, that means you have to track
instances. As I pointed out here: <
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0893.html>
that is very difficult for the author to do correctly. Custom Elements puts
the responsibility for this in the UA which has full knowledge of when
elements are being created.


> As for the social "endorse" button, I've never seen a popular SNS share
> buttons implemented using HTML button elements; most of them add their own
> DOM to add icons, etc...
>

This is why it is important to be able to subtype built-in elements. Some
authors prefer buttons to be s because of the better default
handling by accessibility technology.

Tangentially, this is also why it is important to be able to add Shadow DOM
to built-in elements. It should be possible to elaborate the UI of a button
but still get the benefits of encapsulated styles, encapsulation from
accidental access through casual DOM walking or simple CSS selectors, etc.

> 2. The premise that hooks are not defined is also incorrect. Many hooks
> are already defined. Here is one example: the INPUT element has input and
> change events and a value property. These are sufficient to observe, filter
> and change the value of the INPUT element.
>
>
> This can't possib

Re: [webcomponents] Decoupling Custom Elements and Shadow DOM (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Dominic Cooney]

On Fri, Dec 6, 2013 at 12:49 PM, Ryosuke Niwa  wrote:

> On Dec 5, 2013, at 7:32 PM, Scott Miles  wrote:
> > >> We don't think decoupling custom elements and shadow DOM completely
> is useful given that most important and natural use cases of custom
> elements involve the use of shadow DOM.
> >
> > Separating concerns is always useful, especially when it involves
> contentious standards.
> >
> > I also would like to point out that Mozilla's X-Tags/Brick custom
> elements library is built entirely without Shadow DOM.
>
> Could you elaborate on what value does document.register add in that
> world?  Web developers could use mutation observers to manipulate elements
> of a given name and add a bunch of properties already.


Custom Elements adds a lot of value over Mutation Observers. Mutation
Observers are great, but for other things. A couple of the benefits are:

Instances get callbacks/the right prototype more eagerly than they do with
Mutation Observers. If element authors follow local discipline, they end up
with a composition of elements that is consistent. This makes it easier to
create more robust applications. Technically, more eager callbacks (more
eager than typical uses of Mutation Observers, but less eager than Custom
Elements) are possible with Mutation Observers through takeRecords. However
it turns out this is infeasible because developers end up cargo-culting
takeRecords. (It doesn't work? Add a call to the thing that flushes changes
with takeRecords! Something else broke? ...)

It is easier to get consistent availability of the element than it is with
Mutation Observers. For example, Custom Elements are upgraded even if the
element instance is not in the document. With Mutation Observers this is
extremely difficult because it requires registering observers as subtrees
are disconnected... and modifications including disconnections may have
happened in the interim. With Custom Elements, the responsibility of
understanding how operations affect elements lies with the UA, which has
comprehensive knowledge of this now and into the future, and not with the
author.


> > >> creating shadow DOM when an optional parameter is specified will give
> us a way to constrain the scope of shadow DOM
> >
> > As Dimitri mentioned, we very much wanted to use this approach
> ourselves, but we determined it was naive given: (1) the complexities it
> introduces for inheritance and (2) the flexibility end-users required for
> manipulating templates and shadow roots.
>
> We get that and we're not objecting to giving that ability to expert
> developers but why should average web developers pay the price?
> i.e. Why should they be forced to use libraries and frameworks to do the
> simplest thing in the world?
>
> We're also not convinced that attaching a shadow DOM to a builtin element
> is a valid use case.  All use cases that of binding a shadow DOM to a
> builtin element that are remotely useful involves decorator; i.e. binding
> via style resolution.
>
> Replacing the appearance of form controls with shadow DOM isn't going to
> give us any accessibility benefit or forward compatibility because UA can't
> tell whether the attached shadow DOM targets a specific platform/device or
> not.  Using a subclass of HTMLInputElement is even worse because UAs can't
> hide the author-defined shadow DOM and the subclass could be overriding or
> exposing more APIs on the element so UAs can't even decide not to
> instantiate the custom element and use the regular input element.
>
> Given that, we have a hard time understanding why we ought to be blocking
> ourselves to provide a useful mechanism to scope id and CSS selectors and
> provide a "soft" encapsulation.
>
> - R. Niwa
>
>
>


-- 
Email SLA  •
Google+

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Dominic Cooney]

On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa  wrote:

>
> On Dec 7, 2013, at 4:38 PM, Dominic Cooney  wrote:
>
> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa  wrote:
>
>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita  wrote:
>> > On inheritance around HTMLElement family, there seems to be a confusion
>> between interface side inheritance and implementation side inheritance.
>>
>> Right.  Differentiating the two is very important.
>>
>> > For Custom Elements, the inheritance is not only about interface, but
>> also about implementation. The implementation is more complex and flux in
>> detail, thus worth being shared between different elements. Actually, the
>> implementation of built-in HTML elements, which are usually done in C++,
>> uses inheritance heavily, at least Blink and (I believe) WebKit.
>>
>> The reason we can use inheritance heavily is because we have control over
>> both parent and child classes, and there are careful distinctions between
>> public, protected, and private member functions and member variables in
>> those classes.
>>
>> Unfortunately, custom elements can't easily inherit from these builtin
>> HTML elements because builtin elements do not provide "protected"
>> functions, and they don't expose necessary hooks to override internal
>> member functions to modify behaviors.
>>
>
> Built-in HTML elements have lots of hooks to modify their behaviour (for
> example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
> Java class which has private and public final members, but no protected or
> public non-final ones.
>
> If someone were to make proposals about adding more hooks to the web
> platform to enable more subtyping use cases (for example, a protocol for
> participating in form submission) I would look forward to working with them
> on those proposals.
>
>
> <http://goto.google.com/dc-email-sla>
>
> The problem here is that until such hooks are well defined, inheriting
> from builtin elements doesn't make any sense. So let's not support that
> until such proposal is made and implemented.
>

You assert that inheriting from built-in elements does not make any sense.
You seem to base this on the claim that hooks (the example being form
submission protocol hooks) are not well defined. Whether hooks are well
defined or not doesn't sufficiently support your assertion, because:

1. Not all subtyping relies on hooks. For example, subtyping a built-in
element can add additional API to it. This may make sense. For example, a
social network "endorse" button has a number of additional properties. Yet
it is (or could be) a button.

2. The premise that hooks are not defined is also incorrect. Many hooks are
already defined. Here is one example: the INPUT element has input and
change events and a value property. These are sufficient to observe, filter
and change the value of the INPUT element.

In mentioning hooks, was merely observing that we could define more hooks
to enable even more use cases.


> In addition, consider how inheriting "views" work in AppKit, UIKit, .net
> and MFC. When a view T inherits from another view S, T doesn't simply put S
> into a subregion of T; S intrudes into T's view and modifies what's been
> displayed or places extra content after or before T draws itself.
>

I can not discern a specific point you are making here. You are drawing an
analogy to various UI frameworks but you have not completed the analogy. I
think if you completed the analogy it would end up being a claim about
Shadow DOM. You may have confused extending an element and having Shadow
DOM. As Rafael Weinstein points out here: <
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0883.html>,
whether an element has Shadow DOM is orthogonal to whether it is a Custom
Element or not. I also disagree with your implied argument about Shadow DOM.


> I have a hard time understanding how this bizarre mixture of inheritance
> and composition is considered as the minimal subset of features while
> adding one optional argument to document.register to eliminate the most
> common boilerplate is considered as "building a framework" and "bundling"
> orthogonal features. Where did use cases and developer ergonomics go?
>

The use cases were discussed on this list in 2010.

As for ergonomics, this is subjective, but I spent a day last week building
a Polymer app and the ergonomics were splendid. I have played with X-Tags
in the past and they're great too.

Dominic

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Dominic Cooney]

On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa  wrote:

> On Dec 5, 2013, at 10:09 PM, Hajime Morrita  wrote:
> > On inheritance around HTMLElement family, there seems to be a confusion
> between interface side inheritance and implementation side inheritance.
>
> Right.  Differentiating the two is very important.
>
> > For Custom Elements, the inheritance is not only about interface, but
> also about implementation. The implementation is more complex and flux in
> detail, thus worth being shared between different elements. Actually, the
> implementation of built-in HTML elements, which are usually done in C++,
> uses inheritance heavily, at least Blink and (I believe) WebKit.
>
> The reason we can use inheritance heavily is because we have control over
> both parent and child classes, and there are careful distinctions between
> public, protected, and private member functions and member variables in
> those classes.
>
> Unfortunately, custom elements can't easily inherit from these builtin
> HTML elements because builtin elements do not provide "protected"
> functions, and they don't expose necessary hooks to override internal
> member functions to modify behaviors.
>

Built-in HTML elements have lots of hooks to modify their behaviour (for
example, HTMLVideoElement's autoplay attribute.) The analogy is extending a
Java class which has private and public final members, but no protected or
public non-final ones.

If someone were to make proposals about adding more hooks to the web
platform to enable more subtyping use cases (for example, a protocol for
participating in form submission) I would look forward to working with them
on those proposals.


> Evidently, in the current Custom Elements specification, the interface is
> inherited but the implementation (DOM) is composed via shadow element.
>

There is a lot more to the implementation of an element than what is in its
Shadow DOM. By analogy, Blink has lots of C++ code implementing built-in
elements and relatively few of them have Shadow DOM. It is also incorrect
to think all elements have Shadow DOM.


> In fact, we've come to a conclusion that shadow element is an unnecessary
> complexity because composition is the preferred mechanism to build complex
> objects on the Web, and if someone is using inheritance, then the subclass
> should have access to the shadow DOM of the superclass directly instead of
> it being magically projected into the shadow element.  In fact, this is how
> inheritance works in other GUI frameworks such as Cocoa, .net, etc…
>
> Additionally, we don't have something like shadow element inside Blink or
> WebKit for our builtin elements.  If our goal is to explain and describe
> the existing features on the Web platform, then we sure shouldn't be
> introducing this magical mechanism.
>
> If we had a subclass that truly wanted to contain its superclass in some
> non-trivial fashion, then we should be using composition instead.  If the
> container class needed to forward some method calls and property accesses
> to the contained element, then it should just do.  And providing a
> convenient mechanism to forward method calls and property access in
> JavaScript is an orthogonal problem we should be solving anyway.
>
> - R. Niwa
>
>
>


-- 

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Dominic Cooney]

On Sat, Dec 7, 2013 at 3:44 PM, Maciej Stachowiak  wrote:

>
> On Dec 6, 2013, at 7:41 PM, Elliott Sprehn  wrote:
>
> >
> > On Thu, Dec 5, 2013 at 5:37 PM, Ryosuke Niwa  wrote:
> > Hi,
> >
> > Given that many important/natural use cases of custom elements involve
> shadow DOM,
> > can we add a flag to auto-create shadow DOM for custom elements?
> >
> > In particular, can we add "template" as the third argument to
> document.register so that
> > when a custom element is "instantiated", the specified template is
> automatically closed
> > and inserted into a shadow DOM of the custom element.
> >
> >
> > Can you explain the advantage of this? It saves one line of code:
> >
> >
> this.createShadowRoot().appendChild(document.importNode(template.contents));
> >
> > I don't see how pushing that one line down into the browser is helping
> anyone.
>
> It's not reasonable to require developers to write the above super tricky
> line of code. It involves at least four different concepts and is easy to
> get subtly wrong.
>
> For example, when I wrote my first component (after much reading of docs),
> I did this, which has at least two bugs[1]:
>
> shadow = this.createShadowRoot(this);
> shadow.appendChild(template.content.cloneNode(true));
>
> One of these bugs was copied from the Web Components Primer even.
>

I assume you are referring to the Explainer (if not, could you please
provide a link.) I am the editor of the Explainer. Please file a bug. In
some areas the Explainer is out of date.

I do not find either of those lines in the Explainer. But I could surmise
that you are referring to using cloneNode instead of importNode. No doubt
your bug will explain what you mean.


> In practice, the code delta is going to be more than one line, if you want
> to avoid polluting the global namespace.
>
> Here is my attempt at writing a trivial component with Custom Elements,
> Shadow DOM and Templates as they exist today. Note that this works in
> Chrome Canary as of a week ago with experimental web features turned on:
>
>
>
>
> I sincerely tried to minimize verbosity as much as possible, without
> introducing gratuitous namespace pollution or sacrificing clarity.
>
> Key lines:
>
> 
> 
> (function () {
> var prototype = Object.create(HTMLElement.prototype);
> var template = document.getElementById("rainbow-span-template");
>
> prototype.createdCallback = function() {
> var shadow = this.createShadowRoot(this);
> shadow.appendChild(template.content.cloneNode(true));
> }
>
> document.register("rainbow-span", {prototype: prototype});
> })();
> 
>
>
> Here is how it would look with the proposed 'template' parameter to
> document.register:
>
>
>
>
> This replaces 9 rather non-obvious non-blank lines of code with 1:
>
> 
> 
> document.register("rainbow-span", {template:
> document.getElementById("rainbow-span-template")});
> 
>
>
> Now, obviously things will get more complicated with components that do
> need to run code on creation beyond the basics. But I believe there will be
> substantial complexity savings. To make this work properly for more complex
> cases, the createCallback would need to take
>
>
> [1] (a)Forgot to var-declare shadow; (b) used cloneNode instead of
> importNode which would be wrong in case of a template from an import
> document.
>
>
>
> > Web components are part of the extensible web concept where we provide a
> minimal subset of features necessary for opinionated frameworks to build
> things on top. Supporting  in document.register is easily done in
> script, so I believe it's better left to developers as they're better at
> building frameworks than we are.
> >
> > In either case, that's something we can always add later so it shouldn't
> stand in the way of the current spec.
>
> The spec as it is makes it gratuitously complicated to create a basic
> component. As my examples above demonstrate, this would be a significant
> improvement in developer ergonomics and reduction of learning curve for a
> modest increase in implementation/spec complexity.
>
> I agree that it's important to provide the right building blocks for
> libraries. But that's not a reason to make things needlessly complicated if
> you try to code to the raw APIs. And the proposed template parameter is a
> good building block for libraries too!
>
>
> Regards,
> Maciej
>
>
>
>
>
>
>


-- 

Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Dominic Cooney]

On Sat, Dec 7, 2013 at 10:06 AM, Ryosuke Niwa  wrote:

> On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa  wrote:
>
> On Dec 6, 2013, at 1:20 AM, Brian Di Palma  wrote:
>
> On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa  wrote:
>
> On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa  wrote:
>
> On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov 
> wrote:
>
> 1) It is not friendly to ES6 classes. In fact, you can't use class syntax
> and this syntax together.
>
>
> Okay, let the author define the constructor.
>
> 3) The approach pollutes global name space with constructors. This had been
> voiced many times as unacceptable by developers.
>
>
> We can solve this problem by using JavaScript "object path" as opposed to a
> variable name.
>
> So instead of:
> 
> 
>
> We allow:
> 
> var my = {views:{MyButton: ~}};
> 
> 
> 
>
> While this requires some variable to be exposed on the global scope,
> libraries and frameworks do this already,
>
>
> Hopefully though they won't do that any longer in the ES6 module world.
> They had to be exposed on the global scope in some way otherwise they
> couldn't be used, in future that will no longer be the case.
>
>
> Are you proposing to provide some mechanism to declaratively define a
> custom element inside a module?
> How does a ES6 module end up having markup?
>
>
> I'll also point out that with our proposal to add an optional template
> argument, we could do:
>
> 
> ...
> 
> 
> (function () {
> class MyButton extends HTMLElement {
> ...
> }
> document.register('my-button', MyButton,
> document.getElementById('myButton'));
> )();
> 
>
> so authors DO have an option to hide the class entirely from the global
> scope. It's just not declarative.
>

I don't think this proposal is an improvement over the document.register in
the spec today. Whether there is an argument for a template element is
orthogonal to adding a binding to the JavaScript scope.

The existing spec for document.register does not add a binding to the
JavaScript scope. So it does not suffer the problem discussed in this
thread.


> Given that we don't want to change "this" or the global object per
> previous discussion in the working group,
>

I don't know what discussion you are specifically referring to so my next
statement is not agreeing or disagreeing with the preceding clause of this
sentence.


> I don't see how we can refer to a JS class/constructor declaratively.
>

Yes. I can't think of an example where DOM attributes do this. onclick,
etc. handlers relate to script, but they do not refer to specific objects.

This is a problem with your proposal.

I think a proposal for declarative Custom Elements must also deal with the
problems the group discovered when it last tried. They are summarized here:



Link provided for convenience, as you are no doubt aware of these.

-- 

Re: Cross Origin Web Components: Fixing iframes

[Dominic Cooney]

On Wed, Dec 4, 2013 at 11:45 AM, Ryosuke Niwa  wrote:

>
> On Nov 26, 2013, at 10:15 PM, Dominic Cooney  wrote:
>
> On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa  wrote:
>
>>
>> On Nov 27, 2013, at 8:57 AM, Dominic Cooney  wrote:
>>
>> On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa  wrote:
>>
>>> Hi,
>>>
>>> I have been having informal discussions of our earlier proposal for
>>> cross-orign use cases and declarative syntax for web components, and I
>>> realized there was a lot of confusion about our motivations and decision
>>> decisions.  So I wanted to explain why/how we came up that proposal in this
>>> email.
>>>
>>>
>>> *Problem*: A lot of websites embed SNS widgets, increasing the security
>>> surface of embedders.  The old version of techcrunch.com, for example,
>>> had 5+ social share buttons on each article.  If any one of those SNS
>>> websites got compromised, then the embedder will also get compromised.
>>>
>>
>> This is a valid problem. Does anyone have related use cases that might be
>> in-scope for this discussion?
>>
>>
>> Comment forms (e.g. DISQUS) is another important use case.
>>
>> *What if we used iframe?*
>>> What if we replaced each such instance with an iframe?  That would give
>>> us a security boundary.
>>>
>>> On the other hand, using an iframe for each social button is very
>>> expensive because each iframe loads a document, creates its own security
>>> origin, JS global object, and so forth. Initializing new script context
>>> (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a
>>> page is quite expensive.  If we had 10 articles, and each article had 5
>>> social buttons, we'll have 50 iframes, each of which needs to load
>>> megabytes of JavaScript.
>>>
>>> iframe is also heavily restricted in terms of its ability to layout
>>> itself. Comment widgets (e.g. DISQUS) for example need to stretch
>>> themselves to the height of its content.
>>>
>>> We also need a better mechanism to pass arguments and communicate with
>>> cross-origin frames than postMessage.
>>>
>>>
>>> *What if we made iframe lighter & used seamless iframe?*
>>> The cost of iframe could be reduced substantially if we cached and
>>> internally shared each page's JavaScript.  However, we still have to
>>> instantiate its own script context, document, and window objects.
>>>
>>> We can also use seamless iframe to address the comment widget use case.
>>>
>>>
>>> *What if we let each iframe create multiple "views"?*
>>> The problem with using an iframe for a cross-origin widget is that each
>>> iframe creates its own document, window, etc… even if there are multiple
>>> widgets from the same origin.  e.g. if we had a tweet button on 10
>>> different articles, we have to create its own document ,window, etc… for
>>> each tweet button.
>>>
>>> We can reduce this cost if we could share the single frame, and have it
>>> render multiple "views".  Naturally, each such view will be represented as
>>> a separate DOM tree.  In this model, a single iframe owns multiple DOM
>>> trees, each of which will be displayed at different locations in the host
>>> document.  Each such a DOM tree is inaccessible from the host document, and
>>> the host document is inaccessible from the iframe.
>>>
>>> This model dramatically reduces the cost of having multiple widgets from
>>> the same origin.  e.g. if we have 10 instances of widgets from 5 different
>>> social networks, then we'll have only 5 iframes (each of which will have 10
>>> "views") as opposed to 50 of them.
>>>
>>>
>>> *What if we provided a declarative syntax to create such a view?*
>>> Providing a better API proved to be challenging.  We could have let page
>>> authors register a custom element for each cross-origin widget but that
>>> would mean that page authors have to write a lot of script just to embed
>>> some third-party widgets.  We need some declarative syntax to let authors
>>> wrap an iframe.
>>>
>>> Furthermore, if we wanted to use the multiple-views-per-iframe, then
>>> we'll need a mechanism to declare where each instance of such a view is
>>> placed in the host document with arguments/configuration options for each
>>> view.
>

Re: Cross Origin Web Components: Fixing iframes

[Dominic Cooney]

On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa  wrote:

>
> On Nov 27, 2013, at 8:57 AM, Dominic Cooney  wrote:
>
> On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa  wrote:
>
>> Hi,
>>
>> I have been having informal discussions of our earlier proposal for
>> cross-orign use cases and declarative syntax for web components, and I
>> realized there was a lot of confusion about our motivations and decision
>> decisions.  So I wanted to explain why/how we came up that proposal in this
>> email.
>>
>>
>> *Problem*: A lot of websites embed SNS widgets, increasing the security
>> surface of embedders.  The old version of techcrunch.com, for example,
>> had 5+ social share buttons on each article.  If any one of those SNS
>> websites got compromised, then the embedder will also get compromised.
>>
>
> This is a valid problem. Does anyone have related use cases that might be
> in-scope for this discussion?
>
>
> Comment forms (e.g. DISQUS) is another important use case.
>
> *What if we used iframe?*
>> What if we replaced each such instance with an iframe?  That would give
>> us a security boundary.
>>
>> On the other hand, using an iframe for each social button is very
>> expensive because each iframe loads a document, creates its own security
>> origin, JS global object, and so forth. Initializing new script context
>> (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a
>> page is quite expensive.  If we had 10 articles, and each article had 5
>> social buttons, we'll have 50 iframes, each of which needs to load
>> megabytes of JavaScript.
>>
>> iframe is also heavily restricted in terms of its ability to layout
>> itself. Comment widgets (e.g. DISQUS) for example need to stretch
>> themselves to the height of its content.
>>
>> We also need a better mechanism to pass arguments and communicate with
>> cross-origin frames than postMessage.
>>
>>
>> *What if we made iframe lighter & used seamless iframe?*
>> The cost of iframe could be reduced substantially if we cached and
>> internally shared each page's JavaScript.  However, we still have to
>> instantiate its own script context, document, and window objects.
>>
>> We can also use seamless iframe to address the comment widget use case.
>>
>>
>> *What if we let each iframe create multiple "views"?*
>> The problem with using an iframe for a cross-origin widget is that each
>> iframe creates its own document, window, etc… even if there are multiple
>> widgets from the same origin.  e.g. if we had a tweet button on 10
>> different articles, we have to create its own document ,window, etc… for
>> each tweet button.
>>
>> We can reduce this cost if we could share the single frame, and have it
>> render multiple "views".  Naturally, each such view will be represented as
>> a separate DOM tree.  In this model, a single iframe owns multiple DOM
>> trees, each of which will be displayed at different locations in the host
>> document.  Each such a DOM tree is inaccessible from the host document, and
>> the host document is inaccessible from the iframe.
>>
>> This model dramatically reduces the cost of having multiple widgets from
>> the same origin.  e.g. if we have 10 instances of widgets from 5 different
>> social networks, then we'll have only 5 iframes (each of which will have 10
>> "views") as opposed to 50 of them.
>>
>>
>> *What if we provided a declarative syntax to create such a view?*
>> Providing a better API proved to be challenging.  We could have let page
>> authors register a custom element for each cross-origin widget but that
>> would mean that page authors have to write a lot of script just to embed
>> some third-party widgets.  We need some declarative syntax to let authors
>> wrap an iframe.
>>
>> Furthermore, if we wanted to use the multiple-views-per-iframe, then
>> we'll need a mechanism to declare where each instance of such a view is
>> placed in the host document with arguments/configuration options for each
>> view.
>>
>> A custom element seemed like a natural fit for this task but the
>> prototype/element object cannot be instantiated in the host document since
>> the cross-origin widgets' script can't run in the host document and
>> prototype objects, etc… cannot be shared between the host document and the
>> shared iframes.  So we'll need some mechanism for the shared iframe to
>> define custom element names, and have the h

Re: Cross Origin Web Components: Fixing iframes

[Dominic Cooney]

On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa  wrote:

> Hi,
>
> I have been having informal discussions of our earlier proposal for
> cross-orign use cases and declarative syntax for web components, and I
> realized there was a lot of confusion about our motivations and decision
> decisions.  So I wanted to explain why/how we came up that proposal in this
> email.
>
>
> *Problem*: A lot of websites embed SNS widgets, increasing the security
> surface of embedders.  The old version of techcrunch.com, for example,
> had 5+ social share buttons on each article.  If any one of those SNS
> websites got compromised, then the embedder will also get compromised.
>

This is a valid problem. Does anyone have related use cases that might be
in-scope for this discussion?


> *What if we used iframe?*
> What if we replaced each such instance with an iframe?  That would give us
> a security boundary.
>
> On the other hand, using an iframe for each social button is very
> expensive because each iframe loads a document, creates its own security
> origin, JS global object, and so forth. Initializing new script context
> (a.k.a. "VM", "world", "isolate", etc…) for every single SNS widget on a
> page is quite expensive.  If we had 10 articles, and each article had 5
> social buttons, we'll have 50 iframes, each of which needs to load
> megabytes of JavaScript.
>
> iframe is also heavily restricted in terms of its ability to layout
> itself. Comment widgets (e.g. DISQUS) for example need to stretch
> themselves to the height of its content.
>
> We also need a better mechanism to pass arguments and communicate with
> cross-origin frames than postMessage.
>
>
> *What if we made iframe lighter & used seamless iframe?*
> The cost of iframe could be reduced substantially if we cached and
> internally shared each page's JavaScript.  However, we still have to
> instantiate its own script context, document, and window objects.
>
> We can also use seamless iframe to address the comment widget use case.
>
>
> *What if we let each iframe create multiple "views"?*
> The problem with using an iframe for a cross-origin widget is that each
> iframe creates its own document, window, etc… even if there are multiple
> widgets from the same origin.  e.g. if we had a tweet button on 10
> different articles, we have to create its own document ,window, etc… for
> each tweet button.
>
> We can reduce this cost if we could share the single frame, and have it
> render multiple "views".  Naturally, each such view will be represented as
> a separate DOM tree.  In this model, a single iframe owns multiple DOM
> trees, each of which will be displayed at different locations in the host
> document.  Each such a DOM tree is inaccessible from the host document, and
> the host document is inaccessible from the iframe.
>
> This model dramatically reduces the cost of having multiple widgets from
> the same origin.  e.g. if we have 10 instances of widgets from 5 different
> social networks, then we'll have only 5 iframes (each of which will have 10
> "views") as opposed to 50 of them.
>
>
> *What if we provided a declarative syntax to create such a view?*
> Providing a better API proved to be challenging.  We could have let page
> authors register a custom element for each cross-origin widget but that
> would mean that page authors have to write a lot of script just to embed
> some third-party widgets.  We need some declarative syntax to let authors
> wrap an iframe.
>
> Furthermore, if we wanted to use the multiple-views-per-iframe, then we'll
> need a mechanism to declare where each instance of such a view is placed in
> the host document with arguments/configuration options for each view.
>
> A custom element seemed like a natural fit for this task but the
> prototype/element object cannot be instantiated in the host document since
> the cross-origin widgets' script can't run in the host document and
> prototype objects, etc… cannot be shared between the host document and the
> shared iframes.  So we'll need some mechanism for the shared iframe to
> define custom element names, and have the host document explicitly import
> them as needed.
>
>
> At this point, the set of features we needed looked very similar to the
> existing custom element and shadow DOM.  Each "view" of the shared iframe
> was basically a shadow DOM with a security boundary sitting between the
> host element and the shadow root.  The declarative syntax for the "view"
> was basically a declarative syntax of a custom element that happens to
> instantiate a shadow DOM with a caveat that the shadow host is inaccessible
> form the component, and the shadow DOM is inaccessible from the host
> document.  It also seemed natural for such an "shared iframe" to be loaded
> using HTML imports.
>
>
> You can think of our proposal as breaking iframe down into two pieces:
>
>1. Creating a new document/window
>2. Creating a new view
>
> I think decomposing the problem this way is a good step.

Re

Re: [webcomponents] HTML Imports

[Dominic Cooney]

On Thu, Oct 10, 2013 at 2:42 AM, Scott Miles  wrote:

> On Mon, Oct 7, 2013 at 3:24 AM, James Graham wrote:
>
>> On 06/10/13 17:25, Dimitri Glazkov wrote:
>>
>>  And, if the script is executed against the global/window object of
>>> the main document, can and should you be able to access the imported
>>> document?
>>>
>>>
>>> You can and you should. HTML Imports are effectively #include for the
>>> Web.
>>>
>>
>> Yes, that sounds like a good description of the problem :) It is rather
>> noticable that no one making programming languages today replicates the
>> #include mechanism, and I think html-imports has some of the same design
>> flaws that makes #include unpopular.
>>
>> I think authors will find it very hard to write code in an environment
>> where simple functions like document.getElementById don't actually work on
>> the document containing the script, but on some other document that they
>> can't see.
>
>
> It's true we are introducing something new, but this actually one of The
> Good Parts. Imports are not the main document, they are satellite to the
> main document. The main document maintains primacy, but your imports can
> act on it. So far, we haven't really had any problems with developers on
> this point.
>
>
>> It also seems that the design requires you to be super careful about
>> having side effects; if the author happens to have a non-idempotent action
>> in a document that is imported, then things will break in the relatively
>> uncommon case where a single document is imported more than once.
>
>
Multiple imports of the same resource don't run scripts multiple times.
Perhaps this assuages your concern?


> Can you give an example of a non-idempotent, potentially breaking action?
>
>
>> Overall it feels like html imports has been designed as an over general
>> mechanism to address certain narrow use cases and, in so doing, has handed
>> authors a footgun.
>
>
> I guess I would instead suggest that generality of HTML Imports is due to
> the group attempting to find a virtuous primitive, instead of a special
> case.
>
> For just one issue, look how much HTML becomes embedded in strings, or
> hidden as comments, or other crazy hacks. We can import (relocatable!) CSS
> and JS, why can we not import our most basic content?
>
>
>> Whilst I don't doubt it is usable by the highly competent people who are
>> working at the bleeding edge on polyfilling components, the rest of the
>> population can't be expected to understand the implemetation details that
>> seem to have led the design in this direction.
>
>
> We created polyfills not as an end-in-itself, but as a way of making it
> possible to test these concepts in the real world. The fact is, that one of
> my team's mandates is to (try to) ensure that what comes out if this
> process is actually useful for end-users. We're certainly open to criticism
> on this point (or any point!), but it's basically upside-down to assume we
> are focused on the technology more than the usability.
>
>
>> I think it would be useful to go right back to use cases here and work
>> out if we can't design something better.
>>
>
> Welcome to the discussion, we are grateful for your participation! Let's
> keep up the discussion. In particular, it would be very helpful if you
> could fill in some details on the foot-gun as described above.
>
> Thanks again,
> Scott
>
>


-- 

Re: [webcomponents] Per-type ready event for Custom Elements

[Dominic Cooney]

On Sun, Sep 29, 2013 at 9:27 AM, Daniel Buchner  wrote:

> WebComponentsReady is an event in the Polymer stack that fires when all
> known registered custom elements are ready for interaction - X-Tag has
> similar event (now just a hook into the polyfill's) called
> DOMComponentsLoaded. Being notified that all elements in source are ready
> for interaction is essential at any point in the page lifecycle when a new
> element is defined.
>
Are the definitions in the two frameworks the same? Are there any
illustrative examples of how this is used?

> This is not an X-Tag issue, it's a Web Components issue - one we need to
> address.
>
I think the promises-versus-events discussion is premature; I think first
it would be useful to discuss things like:

Whether it belongs in a spec or if it is better to handle it in frameworks
(at least for now).

What it does (in more detail.)

Related concerns (are there differences between Polymer and x-tags' events?
Is there feedback from users on these events? How are they commonly used?
How effectively can they interop? If Promises are the future, can we get
feedback from Polymer and x-tags by switching their events to use Promises?
etc.)

-- 

Re: [webcomponents] Per-type ready event for Custom Elements

[Dominic Cooney]

On Fri, Sep 27, 2013 at 2:27 PM, Daniel Buchner  wrote:

>
> We're seeing issues with custom element ready state awareness under
> various common async load patterns like AMD, CommonJS, etc. Essentially,
> when a developer brings in their definitions via one of these systems, the
> DOMComponentsLoaded/WebComponentsReady event has already fired,
>

What spec is DOMComponentsLoaded/WebComponentsReady in? I think that this
is part of x-tags and not anything under the purview of WebApps.

I see this bug, but I don't see any clear conclusions on that: <
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20189>


> leaving them with race conditions. There was previously an event that
> fired for _every_ element node when each one was ready, and it was pulled
> due to various feasibility issues (which is understandable). The proposal
> here is different: fire one event (customelementready?) when all known
> in-source elements of a type/name are parsed and ready for interaction,
> *regardless of when that occurs*.
>
> The use case here is simple:
>
> Let's say a dev defines a new custom element with document.register() 10
> minutes after the page is loaded. Unphased by the fashionably late arrival
> of a new custom element definition, the parser crawls through the in-source
> elements, augments any matching nodes, and fires a single event when
> finished with the lot of them. There would be a property on the event
> (tagName, customElementName?) to inform the developer as to what type of
> custom element was ready for interaction.
>
> Make sense? Thoughts? (do we already have this covered some other way?)
>
> - Daniel
>



-- 

Re: [webcomponents]: Shadow DOM + CSS = <3 Meeting Summary

[Dominic Cooney]

On Tue, Jun 25, 2013 at 11:24 AM, Hayato Ito  wrote:

> On Tue, Jun 25, 2013 at 7:18 AM, Dimitri Glazkov 
> wrote:
> > Dear WebAppelites,
> >
> > This past Friday, in always sunny (except when foggy) San Francisco,
> > there has been a (totally not) s3kr3t gathering of minds
> > (http://www.w3.org/wiki/Webapps/WebComponentsJune2013Meeting), where
> > the said minds ploughed through the fertile soils of existing Shadow
> > DOM styling problems, sowing wisdom in righteous exultation. And out
> > of these soils arose these delicious new fruits^H^H^H CSS primitives.
> >
> > Please try and see if they seem edible for you. I documented them as
> > changes from what's currently specified
> > (http://www.w3.org/TR/shadow-dom/).
> >
> > 1) Now More Awesome than Superman, Shadow Host can be in Two Places at
> Once.
> >
> > The host of a shadow tree matches styles both in the document (outer)
> > tree and the shadow (inner) tree. For example, in this example:
> >
> >  #host { border: 1px red solid; } 
> > 
> > 
> >var root = document.querySelector('#host').createShadowRoot();
> >var style = root.appendChild(document.createElement('style'));
> >style.textContent = '#host { padding: 20px; }';
> > 
> >
> > The div#host will be both red-bordered and nicely padded.
>
> For a shadow host which hosts multiple shadow roots, the shadow host
> can be in more than Two Places at Once, right? :)


I don't think so. Can you provide an example?

Dominic


> > 2) OMG, We Killed @host. We're bastards.
> >
> > Sorry folks, the @host at-rule died under questionable circumstances.
> > Let's not dwell on it and move on.
> >
> > 3) Long Live :host!
> >
> > ... Instead, we came up with a new pseudo-class, which does something
> > even cooler. Watch this:
> >
> > :host { ... } /* matches shadow host */
> >
> > :host() { ... } /* also matches shadow host */
> >
> > :host(div.who-mourns-for-morn) { ... } /*
> >   matches a div with class "who-mourns-for-morn" anywhere in the outer
> trees,
> >   up to and including the document tree */
> >
> > :host() /*
> >   matches an element that matches  anywhere in the
> >   outer trees (relative to this shadow tree), up to and including the
> document
> >   tree. */
> >
> > Please note that only a compound selector
> > (http://dev.w3.org/csswg/selectors4/#compound) is allowed in the
> > host's parens.
> >
> > 4) Artist Formerly Known as ::distributed, Now Less Lispy
> >
> > We also killed the parens around ::distributed and renamed to
> > ::content. See tabatkins@' clever twit about that
> > (https://twitter.com/tabatkins/status/348190487003410433). Looking for
> > allergic reactions to this particular pome.
> >
> > 5) Custom Pseudo-elements Part-y
> >
> > To avoid using "x-" prefix and unable to find anything more elegant,
> > we agreed to use a new ::part(name) syntax for custom pseudo-elements,
> > also renaming the respective attribute. In other words, instead of
> > , which is reachable from outside of the
> > shadow tree as host::x-rawr, we turned this into:
> >
> >  #host::part(rawr) { border: 1px red solid; } 
> > 
> > 
> >var root = document.querySelector('#host').createShadowRoot();
> >var div = root.appendChild(document.createElement('div'));
> >div.part = 'rawr'; // I haz red border nao.
> > 
> >
> > (I can't seem to find this discussion in the transcript. Perhaps the
> > dingo ate it?)
> >
> > There was also some scandalous experimentation with using 下 and o_O as
> > new types of combinators _just_ for the Shadow DOM. Sadly, both were
> > frowned upon by the cranky chair. You can find all of this (and more!)
> > in the minutes (http://www.w3.org/2013/06/21-webapps-minutes.html).
> >
> > All in all, a great meeting. Special thanks to all participants, the
> > awesome scribe, and the Mighty Three Dub Cee, may you flourish with a
> > million of similar focused, productive gatherings.
> >
> > :DG<
>
>
>
> --
> Hayato
>

Re: Does JS bound to need to inherit from HTMLElement?

[Dominic Cooney]

On Fri, Apr 19, 2013 at 11:55 PM, John J Barton  wrote:

>
> On Thu, Apr 18, 2013 at 11:11 PM, Dominic Cooney wrote:
>
>> On Wed, Apr 17, 2013 at 12:01 AM, John J Barton <
>> johnjbar...@johnjbarton.com> wrote:
>>
>>> I wonder if there may be a "cultural" difference involved in our
>>> different points of view. As a C++ developer I think your point of view
>>> makes a lot of sense.  As a JavaScript developer I find it puzzling.  Given
>>> a JS object I can override its value getter and add new properties
>>> operating on the object or inheriting from it.
>>>
>>
>> I'm not sure what precisely you mean by "override its value getter", but
>> if you mean define a property on the instance itself, that is an
>> antipattern in JavaScript because it bloats every instance with an
>> additional property, instead of just one additional property the prototype
>> object. It also makes further metaprogramming difficult, because there are
>> n places to hook (n=number of instances) of uncertain location, compared to
>> one place to hook (the prototype involved in the "inheritance") with a
>> discernable location (Constructor.prototype).
>>
>> I'm not sure what precisely you mean by "inheriting from it", but if you
>> mean put the DOM object on the prototype chain of a JavaScript object
>> (apologies if that is not what you meant), that is problematic too.
>> Depending on where the additional properties are defined it could have the
>> same problems I outlined in the previous paragraph. I think it has the
>> additional problem for implementations of making call sites using objects
>> set up this way appear polymorphic, interfering with polymorphic inline
>> caches.
>>
>> This is also a problem in that DOM operations stop working, for example:
>>
>> var x = document.createElement('div');
>> var y = Object.create(x);
>> y.appendChild(document.createElement('span'));
>>
>> will throw TypeError because the receiver is not a DOM object. I believe
>> this is correct per Web IDL <http://www.w3.org/TR/WebIDL/#es-operations>
>> 4.4.7 step 2.
>>
>
> I meant monkey patching the prototype.  Particular implementations of host
> objects may not allow that, which we could fix with various tradeoffs.
> I'm only suggesting to keep an open mind to alternatives. Inheritance is a
> fine technology but not always appropriate.
>
> jjb
>

Monkey-patching the prototype has some obstacles.

You can monkey-patch a well-known prototype, like HTMLDivElement.prototype;
the problem with that is that every other DIV will gain your API. And it is
a shared namespace, so your patch may collide with another.

You can monkey-patch the prototype chain of a given instance. This is
basically what Custom Elements codifies. The reason the UA needs to be
involved is there are too many places in the wild where script can observe
an element before you've had a chance to patch it.


>
>>
>>> Pre-ES6, the number of failure modes in both paths loom large. Anyone
>>> looking at the end result won't be able to tell the difference.
>>>
>>
>> If I understood the alternative approaches proposed, I think the
>> differences are observable.
>>
>>
>>> Anyway the group seems keen on inheritance so I hope it works out.
>>>
>>>
>>> On Mon, Apr 15, 2013 at 11:24 PM, Dominic Cooney wrote:
>>>
>>>> On Sat, Apr 13, 2013 at 12:03 PM, John J Barton <
>>>> johnjbar...@johnjbarton.com> wrote:
>>>>
>>>>> While I completely understand the beauty of having any JS object bound
>>>>> to an  inherit functions that make that object 'be an element',
>>>>> I'm unsure of the practical value.
>>>>>
>>>>> To me the critical relationship between the JS and the element is JS
>>>>> object access to its corresponding element instance without global
>>>>> operations. That is, no document.querySelector() must be required, because
>>>>> the result could depend upon the environment of the component instance.
>>>>>
>>>>
>>>> The critical issue to me is that there is a canonical object that
>>>> script uses to interact with the element. With ad-hoc wrapping of elements
>>>> in JavaScript, there are two objects (the "native" element wrapper provided
>>>> by the UA and the object provided by the page author) which results in
>>>> tedium at best (I did quer

Re: Does JS bound to need to inherit from HTMLElement?

[Dominic Cooney]

On Wed, Apr 17, 2013 at 12:01 AM, John J Barton  wrote:

> I wonder if there may be a "cultural" difference involved in our different
> points of view. As a C++ developer I think your point of view makes a lot
> of sense.  As a JavaScript developer I find it puzzling.  Given a JS object
> I can override its value getter and add new properties operating on the
> object or inheriting from it.
>

I'm not sure what precisely you mean by "override its value getter", but if
you mean define a property on the instance itself, that is an antipattern
in JavaScript because it bloats every instance with an additional property,
instead of just one additional property the prototype object. It also makes
further metaprogramming difficult, because there are n places to hook
(n=number of instances) of uncertain location, compared to one place to
hook (the prototype involved in the "inheritance") with a discernable
location (Constructor.prototype).

I'm not sure what precisely you mean by "inheriting from it", but if you
mean put the DOM object on the prototype chain of a JavaScript object
(apologies if that is not what you meant), that is problematic too.
Depending on where the additional properties are defined it could have the
same problems I outlined in the previous paragraph. I think it has the
additional problem for implementations of making call sites using objects
set up this way appear polymorphic, interfering with polymorphic inline
caches.

This is also a problem in that DOM operations stop working, for example:

var x = document.createElement('div');
var y = Object.create(x);
y.appendChild(document.createElement('span'));

will throw TypeError because the receiver is not a DOM object. I believe
this is correct per Web IDL <http://www.w3.org/TR/WebIDL/#es-operations>
4.4.7 step 2.


> Pre-ES6, the number of failure modes in both paths loom large. Anyone
> looking at the end result won't be able to tell the difference.
>

If I understood the alternative approaches proposed, I think the
differences are observable.


> Anyway the group seems keen on inheritance so I hope it works out.
>
>
> On Mon, Apr 15, 2013 at 11:24 PM, Dominic Cooney wrote:
>
>> On Sat, Apr 13, 2013 at 12:03 PM, John J Barton <
>> johnjbar...@johnjbarton.com> wrote:
>>
>>> While I completely understand the beauty of having any JS object bound
>>> to an  inherit functions that make that object 'be an element',
>>> I'm unsure of the practical value.
>>>
>>> To me the critical relationship between the JS and the element is JS
>>> object access to its corresponding element instance without global
>>> operations. That is, no document.querySelector() must be required, because
>>> the result could depend upon the environment of the component instance.
>>>
>>
>> The critical issue to me is that there is a canonical object that script
>> uses to interact with the element. With ad-hoc wrapping of elements in
>> JavaScript, there are two objects (the "native" element wrapper provided by
>> the UA and the object provided by the page author) which results in tedium
>> at best (I did querySelector, now I need to do some other step to find the
>> author's wrapper if it exists) and bugs at worst (the author's wrapper is
>> trying to maintain some abstraction but that is violated by direct access
>> to the native element wrapper.)
>>
>>
>>> Whether that access is through |this| is way down the list of critical
>>> issues for me. Given a reference to the element I guess I can do everything
>>> I want. In fact I believe the vast majority of the JS code used in
>>> components will never override HTMLElement operations for the same reason
>>> we rarely override Object operations.
>>>
>>
>> The Object interface is not terribly specific and mostly dedicated to
>> metaprogramming the object model, so it is not surprising that it isn't
>> heavily overridden.
>>
>> Elements are more specific so overriding their operations seems more
>> useful. If I design a new kind of form input, it's very useful to hook
>> HTMLInputElement.value to do some de/serialization and checking.
>>
>> Extending HTMLElement et al is not just about overriding methods. It is
>> also to let the component author define new properties alongside existing
>> ones, as most HTMLElement subtypes do alongside HTMLElement's existing
>> properties and methods. And to enable authors to do this in a way
>> consistent with the way the UA does it, so authors using Web Components
>> don't need to be constantly observant that some particular functionality is
>> provided by the UA and some particular functionality is provided by
>> libraries.
>>
>>
>>> So is the inheritance thing really worth the effort? It seems to
>>> complicate the component story as far as I can tell.
>>>
>>
>> I think it is worth the effort.
>>
>> --
>> <http://goto.google.com/dc-email-sla>
>>
>
>


-- 
<http://goto.google.com/dc-email-sla>

Re: Does JS bound to need to inherit from HTMLElement?

[Dominic Cooney]

On Sat, Apr 13, 2013 at 12:03 PM, John J Barton  wrote:

> While I completely understand the beauty of having any JS object bound to
> an  inherit functions that make that object 'be an element', I'm
> unsure of the practical value.
>
> To me the critical relationship between the JS and the element is JS
> object access to its corresponding element instance without global
> operations. That is, no document.querySelector() must be required, because
> the result could depend upon the environment of the component instance.
>

The critical issue to me is that there is a canonical object that script
uses to interact with the element. With ad-hoc wrapping of elements in
JavaScript, there are two objects (the "native" element wrapper provided by
the UA and the object provided by the page author) which results in tedium
at best (I did querySelector, now I need to do some other step to find the
author's wrapper if it exists) and bugs at worst (the author's wrapper is
trying to maintain some abstraction but that is violated by direct access
to the native element wrapper.)


> Whether that access is through |this| is way down the list of critical
> issues for me. Given a reference to the element I guess I can do everything
> I want. In fact I believe the vast majority of the JS code used in
> components will never override HTMLElement operations for the same reason
> we rarely override Object operations.
>

The Object interface is not terribly specific and mostly dedicated to
metaprogramming the object model, so it is not surprising that it isn't
heavily overridden.

Elements are more specific so overriding their operations seems more
useful. If I design a new kind of form input, it's very useful to hook
HTMLInputElement.value to do some de/serialization and checking.

Extending HTMLElement et al is not just about overriding methods. It is
also to let the component author define new properties alongside existing
ones, as most HTMLElement subtypes do alongside HTMLElement's existing
properties and methods. And to enable authors to do this in a way
consistent with the way the UA does it, so authors using Web Components
don't need to be constantly observant that some particular functionality is
provided by the UA and some particular functionality is provided by
libraries.


> So is the inheritance thing really worth the effort? It seems to
> complicate the component story as far as I can tell.
>

I think it is worth the effort.

-- 

Re: [webcomponents]: de-duping in HTMLImports

[Dominic Cooney]

On Thu, Apr 11, 2013 at 4:41 PM, Scott Miles  wrote:

> On Thu, Apr 11, 2013 at 12:33 AM, Angelina Fabbro <
> angelinafab...@gmail.com> wrote:
>
>> > I don't believe it's *needed* exactly, but we imagined somebody wanting
>> to import HTML, use it destructively, then import it again.
>>
>> That does sound totally crazy. Can you give an example as to what someone
>> might want to do with this? Maybe it's not totally crazy and I'm just not
>> being creative enough.
>>
>
> You have to assume some facts not in evidence, but imagine an import that
> runs script and generates content based on the current time, or some other
> dynamic. Then imagine a page injects a link tag, based on some event, to
> import the latest content.
>

Querystring parameters could be used for de-duplication-busting.
Unfortunately that will also be cache-busting.


> >>Then I guess I need this spec'd :)
>>
>> I'd rather de-duping be a nice optimization performed by the user-agent
>> and hidden from me entirely. Although, now I'm really curious about an
>> argument for opting out of de-duping.
>>
>>
> If there is no automatic de-duping then the author has to take care to
> specifically avoid duplication in various cases. Therefore, it cannot be an
> optimization, in the sense that it's not optional. It has to be required by
> the spec or you cannot rely on it.
>

I believe de-duplication should be required by the spec, since the effects
of de-duping are very visible--mutations to the imported document will be
present or not depending on whether it was de-duped or not.


> On Wed, Apr 10, 2013 at 11:56 AM, Scott Miles  wrote:
>>
>>> > Interesting. Why do you need [attribute to opt-out of deduping]?
>>>
>>> I don't believe it's *needed* exactly, but we imagined somebody wanting
>>> to import HTML, use it destructively, then import it again.
>>>
>>> That may be totally crazy. :)
>>>
>>> Scott
>>>
>>> On Wed, Apr 10, 2013 at 11:50 AM, Dimitri Glazkov 
>>> wrote:
>>>
 On Tue, Apr 9, 2013 at 11:42 AM, Scott Miles 
 wrote:
 > Duplicate fetching is not observable, but duplicate parsing and
 duplicate
 > copies are observable.
 >
 > Preventing duplicate parsing and duplicate copies allows us to use
 'imports'
 > without a secondary packaging mechanism. For example, I can load 100
 > components that each import 'base.html' without issue. Without this
 feature,
 > we would need to manage these dependencies somehow; either manually,
 via
 > some kind of build tool, or with a packaging system.

 Then I guess I need this spec'd :)

 >
 > If import de-duping is possible, then ideally there would also be an
 > attribute to opt-out.

 Interesting. Why do you need it?

 :DG<

>>>
>>>
>>
>


-- 

Re: [webcomponents]: Re-imagining shadow root as Element

[Dominic Cooney]

On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson  wrote:

> For the record I'm opposed to what you are proposoing. I don't like that
> you lose the symmetry between innerHTML and outerHTML.
>

Sorry for replying to such a cold thread.

Could you elaborate on what symmetry is being broken here? outerHTML is
innerHTML with a prefix and a suffix. In this proposal the prefix includes
. What problems are likely to result from that?

Dominic


> On Wed, Apr 10, 2013 at 4:34 PM, Scott Miles  wrote:
>
>> I made an attempt to describe how these things can be non-lossy here:
>> https://gist.github.com/sjmiles/5358120
>>
>>
>> On Wed, Apr 10, 2013 at 12:19 PM, Scott Miles  wrote:
>>
>>> input/video would have intrinsic Shadow DOM, so it would not ever be
>>> part of outerHTML.
>>>
>>> I don't have a precise way to differentiate intrinsic Shadow DOM from
>>> non-intrinsic Shadow DOM, but my rule of thumb is this: 'node.outerHTML'
>>> should produce markup that parses back into 'node' (assuming all
>>> dependencies exist).
>>>
>>>
>>> On Wed, Apr 10, 2013 at 12:15 PM, Erik Arvidsson wrote:
>>>
 Once again, how would this work for input/video?

 Are you suggesting that `createShadowRoot` behaves different than when
 you create the shadow root using markup?


 On Wed, Apr 10, 2013 at 3:11 PM, Scott Miles wrote:

> I think we all agree that node.innerHTML should not reveal node's
> ShadowDOM, ever.
>
> What I am arguing is that, if we have  element that you
> can use to install shadow DOM into an arbitrary node, like this:
>
> 
>   
> Decoration -->  <-- Decoration
>   
>   Light DOM
> 
>
>
> Then, as we agree, innerHTML is
>
> LightDOM
>
>
> but outerHTML would be
>
> 
>   
> Decoration -->  <-- Decoration
>   
>   Light DOM
> 
>
>
> I'm suggesting this outerHTML only for 'non-intrinsic' shadow DOM, by
> which I mean Shadow DOM that would never exist on a node unless you hadn't
> specifically put it there (as opposed to Shadow DOM intrinsic to a
> particular element type).
>
> With this inner/outer rule, all serialization cases I can think of
> work in a sane fashion, no lossiness.
>
> Scott
>
>
>
> On Wed, Apr 10, 2013 at 12:05 PM, Erik Arvidsson wrote:
>
>> Maybe I'm missing something but we clearly don't want to include
>>  in the general innerHTML getter case. If I implement
>> input[type=range] using custom elements + shadow DOM I don't want 
>> innerHTML
>> to show the internal guts.
>>
>>
>> On Wed, Apr 10, 2013 at 2:30 PM, Scott Miles wrote:
>>
>>> I don't see any reason why my document markup for some div should
>>> not be serializable back to how I wrote it via innerHTML. That seems 
>>> just
>>> plain bad.
>>>
>>> I hope you can take a look at what I'm saying about outerHTML. I
>>> believe at least the concept there solves all cases.
>>>
>>>
>>>
>>> On Wed, Apr 10, 2013 at 11:27 AM, Brian Kardell 
>>> wrote:
>>>

 On Apr 10, 2013 1:24 PM, "Scott Miles"  wrote:
 >
 > So, what you quoted are thoughts I already deprecated mysefl in
 this thread. :)
 >
 > If you read a bit further, see that  I realized that
  is really part of the 'outer html' of the node and not 
 the
 inner html.
 >
 Yeah sorry, connectivity issue prevented me from seeing those until
 after i sent i guess.

 > >> I think that is actually a feature, not a detriment and easily
 explainable.
 >
 > What is actually a feature? You mean that the shadow root is
 invisible to innerHTML?
 >


 Yes.

 > Yes, that's true. But without some special handling of Shadow DOM
 you get into trouble when you start using innerHTML to serialize DOM 
 into
 HTML and transfer content from A to B. Or even from A back to itself.
 >

 I think Dimiti's implication iii is actually intuitive - that is
 what I am saying... I do think that round-tripping via innerHTML would 
 be
 lossy of declarative markup used to create the instances inside the
 shadow... to get that it feels like you'd need something else which I 
 think
 he also provided/mentioned.

 Maybe I'm alone on this, but it's just sort of how I expected it to
 work all along... Already, roundtripping can differ from the original
 source, If you aren't careful this can bite you in the hind-quarters 
 but it
 is actually sensible.  Maybe I need to think about this a little 
 deeper,
 but I see nothing at this stage to make me think that the proposal and
 implicat

Re: [webcomponents]: Naming the Baby

[Dominic Cooney]

"import" sounds good.

Dominic


On Thu, Mar 28, 2013 at 6:14 AM, Steve Orvell  wrote:

> Err, yeah, thanks for pointing that out.
>
> I also like "import" or "imports."
>
> This makes sense given that the rel attribute is described as defining the
> relationship between the resource being loaded and the document (likely
> outdated spec: http://www.w3.org/TR/html401/struct/links.html#adef-rel).
>
>
> On Wed, Mar 27, 2013 at 11:50 AM, Eric Bidelman 
> wrote:
>
>> My association for HTML links is . Seems too confusing.
>>
>> FWIW, I conducted a small survey to see what the
>> broader community's mental model of this is:
>> https://plus.google.com/u/0/118075919496626375791/posts/3GYkmd4UqLC. Got
>> about 42 responses; the top 3 being:
>>
>> 1. Web Import  - 14 votes
>> 2. Web Package  - 6 votes
>> 3. Web Include  - 5 votes
>>
>> Do we foresee  loading other types of resources in the
>> future, not just ".html"? I like the idea of some sort of "import" or
>> "include", especially seeing that
>> other web developers are aligned with this lingo.
>>
>> My 0$.02
>>
>>
>>
>> On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell wrote:
>>
>>> The word "component" will be used as a synonym for a custom element.
>>> Since this spec is designed to load various html resources that may include
>>> custom element definitions, attaching the word component to this spec is
>>> just confusing.
>>>
>>> We're loading html so rel="html" is most straightforward. The name of
>>> the spec should be HTML links.
>>>
>>>
>>>
>>>
>>> On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro <
>>> angelinafab...@gmail.com> wrote:
>>>
 Just going to drop this in here for discussion. Let's try and get at
 what a just a component 'is':

 A gold-standard component:

 1. Should do one thing well
 2. Should contain all the necessary code to do that one thing (HTML,
 JS, CSS)
 3. Should be modular (and thus reusable)
 4. Should be encapsulated
 5. (Bonus) Should be as small as it can be

 I think it follows, then, that a 'web component' is software that fits
 all of these criteria, but for explicit use in the browser to build web
 applications. The tools provided - shadow DOM, custom elements etc. give
 developers tools to create web components. In the case of:

 

 I would (as mentioned before) call this a 'component include' as I
 think this description is pretty apt.

 It is true that widgets and components are synonymous, but that has
 been that way for a couple of years now at least already. Widgets,
 components, modules - they're all interchangeable depending on who you talk
 to. We've stuck with 'components' to describe things so far. Let's not
 worry about the synonyms. So far, the developers I've introduced to this
 subject understood implicitly that they could build widgets with this
 stuff, all the while I used the term 'components'.

 Cheers,

 - A

 On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles wrote:

> Forgive me if I'm perseverating, but do you imagine 'component' that
> is included to be generic HTML content, and maybe some scripts or some
> custom elements?
>
> I'm curious what is it you envision when you say 'component', to test
> my previous assertion about this word.
>
> Scott
>
>
> On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro <
> angelinafab...@gmail.com> wrote:
>
>> 'Component Include'
>>
>> 'Component Include' describes what the markup is doing, and I like
>> that a lot. The syntax is similar to including a stylesheet or a script 
>> and
>> so this name should be evocative enough for even a novice to understand
>> what is implied by it.
>>
>> - Angelina
>>
>>
>> On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles wrote:
>>
>>> Fwiw, my main concern is that for my team and for lots of other
>>> people I communicate with, 'component' is basically synonymous with 
>>> 'custom
>>> element'. In that context, 'component' referring to
>>> chunk-of-web-resources-loaded-via-link is problematic, even if it's not
>>> wrong, per se.
>>>
>>> We never complained about this before because Dimitri always wrote
>>> the examples as  (note the plural). When it 
>>> was
>>> changed to  was when the rain began.
>>>
>>> Scott
>>>
>>>
>>> On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon 
>>> wrote:
>>>
 I like the idea of "package" seems all encompassing which captures
 the requirements nicely. That or perhaps "resource", but then resource
 seems singular.

 Or perhaps "component-package" so it is obvious that it's tied to
 web components?

 -Ryan


 On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov <
 dglaz...@google.com> wrote:

> Hello f

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

[Dominic Cooney]

On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn  wrote:

>
> On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney wrote:
>
>> ...
>>
>> I think the offset{Parent, Top, Left} properties should be adjusted. This
>> means that in the above example, b.offsetParent would be  and
>> b.offsetLeft would be silently adjusted to accumulate an offset of 10px
>> from c. I think this makes sense because typical uses of offsetParent and
>> offsetLeft, etc. are used to calculate the position of one element in the
>> coordinate space of another element, and adjusting these properties to work
>> this way will mean code that naively implements this use case will continue
>> to work.
>>
>> This behavior is unfortunately slightly lossy: If the author had #c and
>> wanted to calculate the position of #b in the coordinate space of #c, they
>> will need to do some calculation to work it out "via" body. But presumably
>> a script of this nature is aware of the existence of Shadow DOM.
>>
>> The question of what to do for offset* properties across a shadow
>> boundary when the shadow *is* traversable is a vexing one. In this case
>> there is no node disclosed that you could not find anyway using
>> .shadowRoot, etc. tree walking. From that point of view it seems acceptable
>> for offsetParent to return an offsetParent inside the (traversable) shadow.
>>
>
> This seems like correct behavior. We should walk up to find a traversable
> parent and then offsetLeft/offsetTop should be relative to those.
>
> (Note in webkit this is trivial since offsetLeft, offsetTop both call
> offsetParent internally and then compute their value from it)
>
>
>>
>> On the other hand, this violates the lower-boundary encapsulation of the
>> Shadow DOM spec. This means that pages that are using traversable shadows,
>> but relying on convention (ie "don't use new properties like .shadowRoot")
>> to get the encapsulation benefits of Shadow DOM, now have to audit the
>> offsetParent property. It also means you need to have two ways of dealing
>> with offsetParent in both user agents and author scripts. So for simplicity
>> and consistency I think it makes sense to treat both traversable and
>> non-traversable shadows uniformly.
>>
>>
> I disagree with this
>

Which part?

Returning an element inside Shadow DOM in an attribute of a node outside
Shadow DOM violates lower boundary encapsulation.

If offsetParent returns an element inside traversable Shadow DOM, pages
that are using traversable shadows but relying on convention to get
encapsulation benefits will have to audit uses of the offsetParent property.

If offsetParent returns an element inside traversable Shadow DOM (but not
non-traversable Shadow DOM), there are two ways of dealing with
offsetParent in the user agent.

If offsetParent returns an element inside traversable Shadow DOM (but not
non-traversable Shadow DOM), there are two ways of dealing with
offsetParent in author scripts.

It makes sense to treat both traversable and non-traversable shadows
uniformly.


> since it means offsetParent returns a nonsensical value for elements in,
> or projected into, traversable shadow roots as it traverses all the way up
> into the main page until it's not inside a ShadowRoot anymore.
>

In what way is that nonsensical? The return value makes sense at the level
of abstraction the code calling innerParent is working at.


> offsetParent is very useful to find your positioned parent, and you're
> crippling that feature and making authors use distributedParent +
> getComputedStyle() repeatedly which is considerably more expensive.
>

What are those use cases, except finding the position of an element
relative to another element, which I think is not excessively complicated
by what I am proposing here?

Dominic

Re: [webcomponents]: Making produce DocumentFragments

[Dominic Cooney]

On Tue, Mar 19, 2013 at 1:19 AM, Dimitri Glazkov wrote:

>
> On Sun, Mar 17, 2013 at 1:46 PM, Elliott Sprehn  wrote:
>
>>
>> I'd rather like it if the spec said "the component document is a document
>> that's always in standards mode and has no children" and then the contents
>> of the component were put into a DocumentFragment.
>>
>
> Should it bother us that depending on the implementation, one document
> could be shared among all component fragments or not?
>

Yes. The spec should be prescriptive on this point.

I think that the content property should be DocumentFragment, for
consistency with template, and because document has irrelevant API.

-- 
Email SLA  •
Google+

[webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

[Dominic Cooney]

Summary: I think the Shadow DOM spec should specify how offset* properties
are handled around shadows. Further, I think "traversable" and
"non-traversable" shadows should be handled uniformly. The offsetParent
property should return the first offsetParent at the same level of shadow
as the receiver, or the document, to maintain lower-boundary encapsulation.
And the offset{Top, Left} properties should be accumulated across "skipped"
offsetParents.

Problem:

It seems the consensus is that there will be two kinds of shadows, ones
that are exposed to the page through properties such as
HTMLElement.shadowRoot, and ones that aren't [1]. The language is emerging
but for now I will refer to these as "traversable" and "non-traversable"
shadows respectively.

In both cases, there's a question of how to handle HTMLElement.offset*
 properties, particularly offsetParent. [2]

Let's talk about a specific example:


  

{#a's ShadowRoot}
  

  

In this case, the positioned ancestor of #b is #c. What should the result
of b.offsetParent be?

If the ShadowRoot is "not traversable" it is clear that b.offsetParent
should NOT be c. If it were, it would be very difficult to use
not-traversable shadows that don't accidentally leak an internal node.
(Especially when you consider that c could be a pseudo-element, and the
author could set position: relative on the element that way.)

Discussion:

I think the offset{Parent, Top, Left} properties should be adjusted. This
means that in the above example, b.offsetParent would be  and
b.offsetLeft would be silently adjusted to accumulate an offset of 10px
from c. I think this makes sense because typical uses of offsetParent and
offsetLeft, etc. are used to calculate the position of one element in the
coordinate space of another element, and adjusting these properties to work
this way will mean code that naively implements this use case will continue
to work.

This behavior is unfortunately slightly lossy: If the author had #c and
wanted to calculate the position of #b in the coordinate space of #c, they
will need to do some calculation to work it out "via" body. But presumably
a script of this nature is aware of the existence of Shadow DOM.

The question of what to do for offset* properties across a shadow boundary
when the shadow *is* traversable is a vexing one. In this case there is no
node disclosed that you could not find anyway using .shadowRoot, etc. tree
walking. From that point of view it seems acceptable for offsetParent to
return an offsetParent inside the (traversable) shadow.

On the other hand, this violates the lower-boundary encapsulation of the
Shadow DOM spec. This means that pages that are using traversable shadows,
but relying on convention (ie "don't use new properties like .shadowRoot")
to get the encapsulation benefits of Shadow DOM, now have to audit the
offsetParent property. It also means you need to have two ways of dealing
with offsetParent in both user agents and author scripts. So for simplicity
and consistency I think it makes sense to treat both traversable and
non-traversable shadows uniformly.

Dominic

[1] Thread starts here: <
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0535.html>
[2] 

Re: [webcomponents]: Making produce DocumentFragments

[Dominic Cooney]

On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov wrote:

> Here's one scenario where keeping components Documents might be a good
> idea. Suppose you just built a multi-threaded parser into your renderer
> engine, and you would like to hook it up to start loading multiple
> components in parallel. How difficult will it be for you to do this if they
> were all just DocumentFragments in the same document?
>

Given that having components be parsed in the same document complicates the
specification, complicates the implementation (for example resolving
relative resources), might threaten some optimizations (multi-threaded
parsing), and gives a benefit that authors could achieve using tools to
crunch multiple component files into one, I propose that:

Each resource is loaded in its own document.

What about the type of the Component's content attribute? Should that be
DocumentFragment or Document?

Dominic


> On Mon, Mar 11, 2013 at 4:13 PM, Dimitri Glazkov wrote:
>
>> Hi folks!
>>
>> Just had a quick discussion with Elliott and he suggested that instead of
>> building full-blown Documents, the  just make
>> DocumentFragments, just like  does.
>>
>> Looking at
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object
>>  and
>> the bunch of APIs that will never be useful on a document without a
>> browsing context, I think it's a pretty good idea. It should make also
>> components more lightweight.
>>
>> The only problem is that now I have to figure out how to specify this
>> without just flat-out stealing, err... I mean reusing, large swaths of
>> HTML5 spec. But I'll take this one for the team.
>>
>> :DG<
>>
>
>


-- 
Email SLA  •
Google+

Re: [webcomponents]: Making produce DocumentFragments

[Dominic Cooney]

On Thu, Mar 14, 2013 at 5:14 AM, Dimitri Glazkov wrote:

>
>
>
> On Tue, Mar 12, 2013 at 10:20 PM, Dominic Cooney wrote:
>
>> On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov wrote:
>>
>>> Hi folks!
>>>
>>> Just had a quick discussion with Elliott and he suggested that instead
>>> of building full-blown Documents, the  just make
>>> DocumentFragments, just like  does.
>>>
>>
>> I am confused by what you are proposing here.
>>
>> Templates "produce" document fragments in the sense that the
>> HTMLTemplateElement's content attribute is a DocumentFragment.
>>
>> On the other hand, templates use full-blown documents in the sense that
>> "the template contents owner is a document which does not have a browsing
>> context." <
>> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#definitions
>> >
>>
>>
>>> Looking at
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object
>>>  and
>>> the bunch of APIs that will never be useful on a document without a
>>> browsing context, I think it's a pretty good idea. It should make also
>>> components more lightweight.
>>>
>>
>> It you are proposing to make the Component interface's content attribute
>> a DocumentFragment, I think that is OK. It does not make the components any
>> lighter, because component.content.ownerDocument will inevitably point to
>> that other document.
>>
>> Could you provide a more specific proposal? I don't understand what
>> you're proposing here.
>>
>
> Just like in HTML templates, you don't have to have a distinct document
> for each component. They could share the same document. In fact, it might
> be nice for both templates and components to all share the same document.
>

Now I understand.

The concerns about resource resolution are tricky ones and having a
separate document sounds straighforward.

What is the plan for inline scripts in the linked file? Is it possible for
components to have a top-level 

Re: [webcomponents]: First stab at the Web Components spec

[Dominic Cooney]

On Tue, Mar 12, 2013 at 8:39 AM, Scott Miles  wrote:

> My issue is that the target of this link will not in general be an atomic
> thing like a 'component' or a 'module'. It's a carrier for resources and
> links to other resources. IMO this is one of the great strengths of this
> proposal.
>

To go on the record: I like link rel="component" and calling these
components.

Initially I was confused too; I have heard people casually refer to custom
elements as "components." But it makes sense to treat these are discrete
concepts:

Components are the units of reuse. Although they're not "atomic" they
should ideally be a usable unit which references all of its dependencies.

Custom elements are the units of instantiation. One component may contain
be comprised of many custom elements.


> For this reason, when it was rel="components" (plural) there was no
> problem for me.
>
> Having said all that, I'm not particularly up in arms about this issue.
> The name will bend to the object in the fullness of time. :)
>
> S
>
>
> On Mon, Mar 11, 2013 at 3:35 PM, Elliott Sprehn  wrote:
>
>>
>> On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton 
>> wrote:
>>
>>> Personally, I had no objection to rel="component". It's similar in
>>> usage to rel="stylesheet" in the fact that it's descriptive of what you're
>>> linking to.
>>>
>>> On the other hand, rel="include" is very broad. It could just as easily
>>> apply to a stylesheet as a Web component, and may limit the usefulness of
>>> the term if/when future rel values are introduced.
>>>
>>> (p.s. I'm new to this list and haven't read through all the previous
>>> discussions on Web components. Feel free to disregard this comment if I'm
>>> rehashing old topics)
>>>
>>>
>>>
>> +1, I like rel="component", document or include doesn't make sense.
>>
>> - E
>>
>
>


-- 
Email SLA  •
Google+

Re: [webcomponents]: Making produce DocumentFragments

[Dominic Cooney]

On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov wrote:

> Hi folks!
>
> Just had a quick discussion with Elliott and he suggested that instead of
> building full-blown Documents, the  just make
> DocumentFragments, just like  does.
>

I am confused by what you are proposing here.

Templates "produce" document fragments in the sense that the
HTMLTemplateElement's content attribute is a DocumentFragment.

On the other hand, templates use full-blown documents in the sense that
"the template contents owner is a document which does not have a browsing
context." <
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#definitions
>


> Looking at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#the-document-object
>  and
> the bunch of APIs that will never be useful on a document without a
> browsing context, I think it's a pretty good idea. It should make also
> components more lightweight.
>

It you are proposing to make the Component interface's content attribute a
DocumentFragment, I think that is OK. It does not make the components any
lighter, because component.content.ownerDocument will inevitably point to
that other document.

Could you provide a more specific proposal? I don't understand what you're
proposing here.


> The only problem is that now I have to figure out how to specify this
> without just flat-out stealing, err... I mean reusing, large swaths of
> HTML5 spec. But I'll take this one for the team.
>
> :DG<
>



-- 
Email SLA  •
Google+

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Dominic Cooney]

On Wed, Feb 27, 2013 at 4:03 AM, Boris Zbarsky  wrote:

> On 2/26/13 1:57 PM, Tab Atkins Jr. wrote:
>
>> An argument to the contrary (which you do seem to acknowledge later in
>> your message, if I'm reading correctly): if you make shadow private,
>> but allow authors to make them public on an ad-hoc basis
>>
>
> I think "ad-hoc" in this case means "per-component", not "ad-hoc method of
> exposing".  The method of exposing should be standardized no matter what; I
> think we agree on that.
>
> -Boris
>

Yes, by “ad-hoc” I meant “per-component.”

If shadows are private by default, maybe it makes sense for the spec to
have commentary about how shadows should be exposed by scripts that want to
expose them.

Alternatively, if shadows are public by default, maybe the spec should have
commentary about not breaking multiple shadows if scripts want to hide
them. (I think there are performance downsides to having public shadow DOM
and hiding it with script, but it probably does not make sense for spec
commentary to venture there.)

One more thought occurs to me: It is easier to add public shadows in a
subsequent revision of the spec than it is to take public shadows away.
Provided the message that Shadow DOM does not provide meaningful security
guarantees is understood, we could consider private Shadow DOM a
conservative initial design.

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Dominic Cooney]

On Wed, Feb 27, 2013 at 4:05 AM, Erik Arvidsson  wrote:

> Also, if shadows are public by default the API to access the shadow is
> well defined. If shadows are private by default and components decide to
> expose the shadow ad hoc then there is no standardized API.
>
See below.


> On Feb 26, 2013 1:59 PM, "Tab Atkins Jr."  wrote:
>
>> On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney 
>> wrote:
>> > Although the default provided by the spec is important, early adopters
>> are
>> > also important in shaping practice. There is apparently strong
>> conviction on
>> > both sides of the argument. If shadows are public by default, there is
>> no
>> > serious obstacle to making them private on an ad-hoc basis; if shadows
>> are
>> > private by default, there is no serious obstacle to making them public
>> on an
>> > ad-hoc basis. Maybe the spec should include non-normative commentary to
>> make
>> > web component authors aware of this choice, and then the
>> "market"/Darwinian
>> > process/etc. will decide.
>>
>> An argument to the contrary (which you do seem to acknowledge later in
>> your message, if I'm reading correctly): if you make shadow private,
>> but allow authors to make them public on an ad-hoc basis, there's no
>> way for tools to reliably access the public shadows.
>
>
Yes, that is what I intended to insinuate in this sentence:

“If shadows are private by default, it would be nice for web component
authors who want public shadows to get them in a way that is consistent and
interoperable especially in the presence of multiple shadows.”


>  This was a
>> problem earlier in the spec, when it was in exactly that state - you
>> got handed your shadow root explicitly, and could, if you wanted,
>> assign it to a public property on your own.  That meant, though, that
>> you could assign it to *any* property, so tools couldn't predict where
>> to look.
>
>

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

[Dominic Cooney]

On Tue, Feb 26, 2013 at 2:51 AM, Dimitri Glazkov wrote:

> On Mon, Feb 25, 2013 at 9:46 AM, Boris Zbarsky  wrote:
> > On 2/25/13 12:33 PM, Tab Atkins Jr. wrote:
> >>
> >> If a script is explicitly looking inside the shadows of unknown
> >> controls and checking their contents (and then failing when the
> >> unknown control has different contents than whatever it expected),
> >> something is *messed up* with that script.
> >
> >
> > I can 100% guarantee to you that such scripts will get written, will be
> > popular, and will prevent control authors from changing their
> > implementations while preserving the API...
>
> FWIW, I was most ambivalent about this change. I welcome more
> discussion. I know Elliott and Dominic had the strongest opinions on
> this.
>

I think that shadows should be "private." My main concern has been well
represented by Boris; basically, if shadows are not private by default, it
is too easy for pages to come to depend on the internal details of
components, which reduces the value of Web Components.

My thinking on this issue has evolved slightly. These points might be
useful to consider; I did not see them covered elsewhere in this thread yet:

There are a set of use cases, for example Readability, AdBlock,
accessibility tools and debugging tools, that should have access to
shadows. These use cases are mostly handled by browser extensions (or
integration into the browser in the case of debugging tools or Readability
in Safari.) As such, I don’t think these use cases are persuasive arguments
for making shadows public; extensions can have a special means of access.

I think it is preferable to chose to make shadows public, or to make them
private, to having a "mode" that components can opt into.

Although the default provided by the spec is important, early adopters are
also important in shaping practice. There is apparently strong conviction
on both sides of the argument. If shadows are public by default, there is
no serious obstacle to making them private on an ad-hoc basis; if shadows
are private by default, there is no serious obstacle to making them public
on an ad-hoc basis. Maybe the spec should include non-normative commentary
to make web component authors aware of this choice, and then the
"market"/Darwinian process/etc. will decide.

If shadows are public by default, it would be nice for web component
authors who want private shadows to get them in a way that is reasonably
efficient and is not disruptive in the presence of multiple shadows. It
would be nice if there was at least one high-quality JavaScript library
that came into wide use for this.

If shadows are private by default, it would be nice for web component
authors who want public shadows to get them in a way that is consistent and
interoperable especially in the presence of multiple shadows. It would be
nice if there was at least one high-quality JavaScript library that came
into wide use for this.

Dominic

Re: Using Shadow DOM @host rule with :scope pseudo-selector

[Dominic Cooney]

In reading [1] more closely, I see that @host rules are not matched
starting at the host element, but *specifically* to the host element.

In that sense, it does not make sense for @host to establish a context
scope, because @host { :scope { … } } is redundant at best.

Regards,

Dominic

[1] <
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule
>


On Fri, Feb 1, 2013 at 12:10 PM, Dominic Cooney  wrote:

> I wanted clarification on the meaning of @host rules [1] in combination
> with the :scope pseudo selector [2].
>
> Am I correct in assuming that if I wanted to style the host element, and
> only the host element, I could apply these features in combination this way?
>
> @host {
>   :scope {
> border: 1px solid orange;
>   }
> }
>
> I think that is awesome.
>
> It might be clearer whether these features combine in this way if the
> Shadow DOM spec mentioned @host establishing the "contextual reference
> element set" mentioned in the CSS 4 Selectors spec.
>
> Regards,
>
> Dominic
>
> [1] <
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule
> >
> [2] <http://dev.w3.org/csswg/selectors4/#scope-pseudo>
>
>
>
> --
> <http://goto.google.com/dc-email-sla>
>



-- 
Email SLA <http://goto.google.com/dc-email-sla> •
Google+<https://plus.sandbox.google.com/111762620242974506845/posts>

Using Shadow DOM @host rule with :scope pseudo-selector

[Dominic Cooney]

I wanted clarification on the meaning of @host rules [1] in combination
with the :scope pseudo selector [2].

Am I correct in assuming that if I wanted to style the host element, and
only the host element, I could apply these features in combination this way?

@host {
  :scope {
border: 1px solid orange;
  }
}

I think that is awesome.

It might be clearer whether these features combine in this way if the
Shadow DOM spec mentioned @host establishing the "contextual reference
element set" mentioned in the CSS 4 Selectors spec.

Regards,

Dominic

[1] <
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule
>
[2] 



-- 

Re: [webcomponents] Custom Components and CSS Regions

[Dominic Cooney]

On Fri, Dec 7, 2012 at 10:52 AM, Alan Stearns  wrote:

> >On 12/6/12 3:25 AM, "Dominic Cooney"  wrote:
> >
> >>On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns  wrote:
> >>
> >>...
> >>
> >>An insertion point is a  element inside a shadow DOM subtree.
> >
> >This is one kind of insertion point. There is a second kind,
> >called , which is used when multiple shadow roots are
> >applied to a given element to specify how the shadows are
> >merged for rendering.
>
> Thanks for the correction.
>
> >...
> >
> >>Insertion Points:
> >>1. Content assignment done in HTML
> >>2. One-to-one mapping of content to insertion point
> >
> >If you replace /insertion point/ with /content element/ this
> >is right for the children of a given host element in the context
> >of that host element¹s shadows but not for a document in general.
> >When there are multiple shadows and reprojection, where a node
> >is presented in the (virtual) flattened tree can depend on
> >multiple insertion points.
>
> What I mean here is that the end result is a simple mapping for each
> content element to a specific insertion point. The end result may depend
> on multiple insertion points, but there's always just one insertion point
> where each content element gets displayed. I am trying to contrast this
> with taking content and flowing it between two boxes as you can do with
> CSS Regions (my first use case below).


Yes, this is the qualitative difference.


> >>3. Content must come from insertion point shadow host
> >
> >This is incorrect in the case of reprojection.
>
> Would it be more precise to say that the content must come from somewhere
> up the parent chain? Here I'm trying to contrast between the scoped
> selectors that insertion points use and the general selectors that can
> have flow-into assignments. This fits in to my multiple source use case
> (#4) below.
>

To be precise you have to define “parent chain” very carefully, but yes –
Shadow DOM projection pulls content from a defined scope; CSS Regions have
more of a flat, global namespace going on where content is pushed into
flows and is pulled from flows.


> >...
> >
> >>4. Can assign multiple selectors to a single insertion point
> >>5. Cannot chain insertion points together
> >
> >I¹m not sure what you mean by ³chain², but reprojection and
> > make two kinds of chaining possible.
>
> By chain I mean create a fragmentation context - akin to multicolumn
> layout. The column boxes are "chained" together and content flows from one
> column to the next. In CSS Regions each region box participates in a
> region chain, and content flows from one box to another.
>

Ah, I understand now. This is right.


> >...
> >
> >>Should use Regions
> >>1. If you need to chain boxes together inside a template
> >>  (create your own multicol component)
>
> Here I'm not thinking so much of faithfully recreating multicol layout,
> but of making a custom element that contains two or more columns
> (expressed as CSS Regions). Take a simple case of displaying your content
> in two columns separated by some graphical element in the gutter between
> the columns. Which content fits in the first column depends on its height
> and width, and any overflow content in the block direction flows into the
> second column. You can do this with CSS Regions defined in your template.
> I do not think you can do this with insertion points without choosing how
> to divide the content between the columns.
>
> >>...
> >>
> >>4. If you need to pull content from multiple sources
> >>  (breaking news from two or more components)
>
>
> Consider the Shadow DOM example of the news widget separating breaking
> news into its own section. What if you had two or more of these news
> widgets (say, international and local news) and you wanted to combine the
> breaking news from each into its own widget? You could create a "news
> page" widget that contained the list of news widgets in order to get
> access to all of the breaking news content across the widget list. But
> that would require an additional wrapper in the HTML.
>
> Instead, you could just add a "breaking news" widget, assign all of the
> .breaking content to a named flow, then assign that named flow to an
> element in the "breaking news" widget. CSS Regions can pull content out of
> each custom element (or anywhere else) and redirect it to a separate
> custom element without requiring a common parent.
>
> Thanks,
>
> Alan
>
>

Re: [webcomponents] Custom Components and CSS Regions

[Dominic Cooney]

On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns  wrote:

> There are some similarities between Web Components insertion points and
> CSS Regions. Both facilities allow you to project content from one element
> into another. I'd like to compare the two when used inside custom
> components - why might you use CSS Regions inside a custom component, and
> when should you use an insertion point instead?
>
> If anything in the following analysis is incorrect, please let me know.
>

I only have a passing familiarity with CSS Regions, but I am familiar with
Web Components. I have some comments.


> An insertion point is a  element inside a shadow DOM subtree.
>

This is one kind of insertion point. There is a second kind, called
, which is used when multiple shadow roots are applied to a given
element to specify how the shadows are merged for rendering.


> These elements can have a select attribute that contains one or more
> selector fragments. When the element with a shadow DOM subtree is
> rendered, its children are distributed to the insertion points in the
> subtree. The first selector match in tree order determines where each
> piece of content is displayed.
>

This is correct, but there is more – how  is handled when an
element has multiple shadows, and how selected nodes can be reprojected
through nested shadows.


> A CSS Region displays content that has been redirected to a named flow. A
> declaration of flow-into: moves content to a named flow, then a
> declaration of flow-from: with a matching ident creates one or more
> CSS Regions that will display that content.
>
> Insertion Points:
> 1. Content assignment done in HTML
> 2. One-to-one mapping of content to insertion point
>

If you replace /insertion point/ with /content element/ this is right for
the children of a given host element in the context of that host element’s
shadows but not for a document in general. When there are multiple shadows
and reprojection, where a node is presented in the (virtual) flattened tree
can depend on multiple insertion points.


> 3. Content must come from insertion point shadow host
>

This is incorrect in the case of reprojection. Here is a specific example
of reprojection:


  

{#a's shadow root}
  


{#c's shadow root}
  


The virtual tree is

#a
  #c
#d
  #b

Note how in #c's shadow root, the content is one of #a's children via
reprojection.


> 4. Can assign multiple selectors to a single insertion point
> 5. Cannot chain insertion points together
>

I’m not sure what you mean by “chain”, but reprojection and  make
two kinds of chaining possible.


> 6. Do not require an ident to collect content for projection
>
> CSS Regions
> 1. Content assignment done in CSS
> 2. One-to-many mapping of content to CSS Regions
> 3. Content can come from anywhere in the document
> 4. Can assign multiple selectors to a named flow
> 5. Can chain CSS Regions to create a fragmentation context
> 6. Need an ident for each named flow
>
> Should use Insertion Points
> 1. For adornments to a single  element
>   (component as a wrapper)
> 2. For rearranging a single element's children
>   (breaking news example)
> And I'm sure there are many many more use cases I'm not familiar with.
>
> Should use Regions
> 1. If you need to chain boxes together inside a template
>   (create your own multicol component)
> 2. If you need to chain boxes between templates
>   (custom component as pagination template)
> 3. If you want reassignments via CSS
>   (media queries that target this or that portion of a component)
> 4. If you need to pull content from multiple sources
>   (breaking news from two or more components)
>
> I'm happy to elaborate on the CSS Regions use cases listed here, if my
> terse descriptions are not clear.
>
>
> Thanks,
>
> Alan
>
>
>

Re: Trialing Web Components

[Dominic Cooney]

On Tue, Jul 10, 2012 at 12:21 PM, Dominic Cooney wrote:

> I can comment on the status of Web Components in Chromium:
>
> - Large parts of the Shadow DOM spec are implemented, but you have to
> enable them in about:flags first (ctrl-f and search for "Shadow DOM"). More
> is available in more recent versions (for example Google Chrome Canary or
> Google Chrome dev channel.) There is some basic debugging support but that
> requires other flags – please follow up with me off list if you need more
> details on that.
>
> - Templates and custom elements are not implemented in Chromium yet. There
> are a couple of JavaScript libraries that simulate custom elements. There
> are some links here: <
> https://plus.sandbox.google.com/103330502635338602217/posts/ScerSQRQhuz>
>

Sorry, this link: <https://plus.google.com/103330502635338602217/posts>


> HTH,
>
> Dominic
>
>
> On Tue, Jul 10, 2012 at 5:38 AM, rektide  wrote:
>
>> I did! Pardon, thanks for the fixed URL.
>>
>> https://gist.github.com/3078197
>>
>> On Mon, Jul 09, 2012 at 03:21:50PM -0400, Scott González wrote:
>> >On Mon, Jul 9, 2012 at 3:09 PM, rektide <[1]rekt...@voodoowarez.com>
>> >wrote:
>> >
>> >  My attempt is at:
>> >  [2]https://gist.github.com/3078187
>> >
>> >I think you meant [3]https://gist.github.com/3078197
>>
>>
>

Re: Trialing Web Components

[Dominic Cooney]

I can comment on the status of Web Components in Chromium:

- Large parts of the Shadow DOM spec are implemented, but you have to
enable them in about:flags first (ctrl-f and search for "Shadow DOM"). More
is available in more recent versions (for example Google Chrome Canary or
Google Chrome dev channel.) There is some basic debugging support but that
requires other flags – please follow up with me off list if you need more
details on that.

- Templates and custom elements are not implemented in Chromium yet. There
are a couple of JavaScript libraries that simulate custom elements. There
are some links here: <
https://plus.sandbox.google.com/103330502635338602217/posts/ScerSQRQhuz>

HTH,

Dominic


On Tue, Jul 10, 2012 at 5:38 AM, rektide  wrote:

> I did! Pardon, thanks for the fixed URL.
>
> https://gist.github.com/3078197
>
> On Mon, Jul 09, 2012 at 03:21:50PM -0400, Scott González wrote:
> >On Mon, Jul 9, 2012 at 3:09 PM, rektide <[1]rekt...@voodoowarez.com>
> >wrote:
> >
> >  My attempt is at:
> >  [2]https://gist.github.com/3078187
> >
> >I think you meant [3]https://gist.github.com/3078197
>
>

Re: [Shadow DOM] Shadown DOM and Regions CSSOM

[Dominic Cooney]

On Thu, Jun 21, 2012 at 6:23 PM, Andrei Bucur  wrote:

> Hello,
>
> This is a cross-post from the www-style discussion list in case anyone is
> interested about this subject:
>
> Currently the CSS Regions spec doesn't mention what happens with regions
> that are part of a shadow tree. The NamedFlow interface exposes the
> getRegions API that "returns the sequence of regions in the region chain
> associated with the named flow". I suppose the CSSOM needs to be adapted
> to take into account the shadow boundaries.
>
> One way to do it is to add NamedFlow accessor APIs to the shadow root
> object, similar to what's available on the Document. The NamedFlow objects
> returned using the new API will provide access to the regions found in the
> shadow tree. The NamedFlow objects returned from the host document give
> access only to the regions above the shadow boundary.
>
> Thoughts?


That makes sense to me. It is in line with the Shadow DOM concept of
upper-boundary encapsulation and is analogous to the methods and properties
on ShadowRoot, like NodeSelector, that provide access to the encapsulated
stuff.

Dominic

Re: [Component Model] Decorator Challenges

[Dominic Cooney]

On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov wrote:

> We could explicitly prevent the decorator from ever having a state or
> being able to change it. This places a set of unorthodox (at least
> from author’s perspective) constraints on the DOM tree, created by the
> decorator. All of these constraints stem from the need to halt DOM
> changes in a decorator shadow subtree and include not allowing:
> * 

Re: State of subclassing and tag names in the component model

[Dominic Cooney]

Hi Boris,

This is my current thinking, although this blends/steals a lot of ideas
from TPAC:

There are two kinds of components—ones that are a refinement of something
in HTML, like a select element or a button; and ones that have no genuine
peer in HTML.

This is the litmus test: If you were writing this today, would you start
with a div or span? Then your component is probably the second kind.

Custom tag names have a number of downsides:

A. Markup with custom tags could actually be hard to write, because the
HTML parser will have to have permissive behavior around custom tags that
won’t match developer’s intuition of how parsing works. We could let
component authors specify a context for parsing, but that would require
them to understand the parser, which is a high bar.

B. The semantics of custom tags are weak. A UA that doesn’t run JavaScript
would have to assign them a pretty neutral meaning, at least at first. (A
page well-authored for fallback may never expose a UA to this problem
though.)

C. As you point out, existing specs, implementations, stylesheets and
libraries expect certain tag names, and custom tags break that. That is a
difficult practical problem.

Recalling the two kinds of components, I think custom tag names are a bad
fit for the first kind—the kind that have a semantic cousin in HTML. A, B
and C will be problems for these kinds of components.

For the second kind, B and C are less of a problem because the component is
something totally new. Maybe custom tag names could work for those kinds of
components.

I think the way forward is for us to work on components that use an
existing tag name, and identify the component with an attribute, for now. I
think that this is superior to custom tag names for the first kind of
component, and it can trivially be used for the second kind of
component—just use div or span as the tag name.

Dominic

On Tue, Nov 8, 2011 at 6:29 AM, Boris Zbarsky  wrote:

> All,
>
> At this I've lost track of what the current proposals are on tag names in
> the component model.  I've been thinking about this a bit, and I would like
> us to look at a particular use case: subclassing  and adding some
> behavior to it.
>
> An obvious question: Should the localName/tagName of the resulting element
> be "img" or something else?
>
> The way I see it, if it's "img" then everything should Just Work for this
> element and component binding just has to be done via an attribute.
>
> If it's something else, then as far as I can tell we would probably need
> to change various specifications to look at whatever "img" is for this
> element (not the localName anymore).  This likely includes various parts of
> HTML5, possibly selector matching for UA and maybe user stylesheets, and so
> forth.  Furthermore, the result would still not be treated as an image by
> various script libraries out there.  But maybe that's desirable?
>
> In any case, for every single place where one could consider what sort of
> element one has we would need to specify whether it's the localName that's
> being used or whatever other property evaluates to "img" or
> HTMLImageElement in this context.
>
> Is that a reasonable summary of the state of things?
>
> -Boris
>
>

Re: Component Model f2f: Actionable things

[Dominic Cooney]

On Sun, Nov 6, 2011 at 2:01 PM, Cameron McCormack  wrote:

> Would you be able to post the code from the blog post comment example?
>

Here it is what you saw, with some irrelevant parts removed. Just to set
expectations: this was already two months old, so it lags our current
thinking somewhat.

  

  
img { border: 1px solid black; margin-bottom: 1em; float: left; }
.text { margin-left: 71px; }
.holder { clear: left; margin-bottom: 1em; }
  
  
  

  

  

  
function Comment(text) {
HTMLElement.call(this); // Makes this an Element

this.textContent = text || 'Lorem impsum ...';

var shadow = new ShadowRoot(this); // Give us a Shadow
this.buildUI(shadow);
}

Comment.prototype = Object.create(HTMLElement.prototype);

Comment.prototype.constructor = Comment;

Comment.prototype.buildUI = function(shadow) {
var holder =
document.getElementById('commentTemplate').firstElementChild.cloneNode(true);
shadow.appendChild(holder);

holder.querySelector('.avatar').src = 'avatar' +
Math.floor(Math.random() * 5) + '.jpg';
};

HTMLElement.register('x-comment', Comment);

function post(text) {
var comments = document.querySelector('#comments');
comments.insertBefore(new Comment(text), comments.firstChild);
}
  

  Comments
  

  

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

[Dominic Cooney]

On Fri, Sep 30, 2011 at 12:36 PM, Ian Hickson  wrote:

> On Thu, 29 Sep 2011, Tab Atkins Jr. wrote:
> > On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney 
> wrote:
> > > OK.
> > >
> > > I understand  and  are different in the respect of
> > > automatically closing p-s.
> > >
> > > Is this a serious problem? It seems like if you want the p to be
> > > closed, you can write ; if you insist on getting the parser to
> > > close it, you can use .
> >
> > I agree that it's not a serious problem, and that it's trivial to fix
> > for yourself.  There's no legacy pain, either.
>
> 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 understand that the parsing of x-foo and div are different, but is it an
issue? The model we proposed would just use the existing parsing algorithm,
but instantiate a different kind of element for x-foo instead of
HTMLUnknownElement.

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?


> 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.? We should make binding application hinge on
that. Preferably that datum would not be mutable via DOM like the element,
so authors aren’t confused about why a particular binding is applied to an
element when they inspect that element.


> Plus, for security reasons, any bindings attached via CSS
> must be explicitly mentioned in the document's  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?


> For brevity, the attribute could be "is". So:
>
>
>...
>   
>   ...
>   
>... 
>   
>
>   
>var w = Element.create('li', { is: 'mywidget' });
>// run-time instantiation, using the new element creation API
>   
>

We definitely need declarative and imperative to be harmonized in this way.


>   
>/* a style-time instantiation; can't define a new API */
>li { binding: mywidget; }
>   
>

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


> This model still suffers from the problem of stalling page loads while
> binding files are fetched, but if we're going to require that bindings
> apply at page load, I really don't see a way around that.
>
>
>

I think it is reasonable. The choices here are FOUC or blocking, or both
(let the author decide.) I guess blocking is the lesser evil? It is simpler
for UA implementors, more predictable for authors, visually less distracting
(although slower) for users.


> As far as I can tell this has all the advantages of what Dimitri is
> proposing, and addresses all his use cases, while still addressing almost
> all the problems that I and others have raised on this thread.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

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

[Dominic Cooney]

OK.

I understand  and  are different in the respect of
automatically closing p-s.

Is this a serious problem? It seems like if you want the p to be
closed, you can write ; if you insist on getting the parser to
close it, you can use .

Dominic

On Fri, Sep 30, 2011 at 10:53 AM, Tab Atkins Jr.  wrote:
> On Thu, Sep 29, 2011 at 6:38 PM, Dominic Cooney  wrote:
>> So, to make this really explicit:
>>
>> div’s default display is block, but x-div’s default display is inline.
>>
>> Is there anything else that I missed?
>
> Not quite.   has auto-closing behavior around several of the
> existing elements.  It does not auto-close for components, though.
>
> It has nothing to do with 'display' - it's an effect of parsing.
>
> ~TJ
>

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

[Dominic Cooney]

So, to make this really explicit:

div’s default display is block, but x-div’s default display is inline.

Is there anything else that I missed?

Looking at use cases
, most of them
would like to be block, or at maybe inline-block.

One philosophical question: Are we optimizing for UAs that support
HTML5, but not the Component Model, handling pages that use the
component model? Or UAs that support HTML4 handling pages that use the
component model? I guess we are _not_ optimizing for old content,
which could in theory use tags that start with x- but not set CSS
display.

Dominic

On Fri, Sep 30, 2011 at 6:45 AM, Edward O'Connor  wrote:
>>> If you're talking about bz's second e-mail, then consider cases such as:
>>>
>>>   Foo
>>>    Bar 
>>>
>>> ...vs:
>>>
>>>   Foo
>>>    Bar 
>>
>> Can you be a bit more specific and explain the problem you're trying
>> to highlight with this example?
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1162
>
>
> Ted
>
>

Dynamic behavior attachment does not work, subtyping elements could work (Was: Re: Behavior Attachment Redux, was Re: HTML element content models vs. components)

[Dominic Cooney]

Hixie wrote:


… The pure JS side of things,
which is all that is needed for what we're talking about here, needs
nothing more than just adding a prototype, something which is not only
well-supported by all browsers, but defined in increasingly careful
detail. Interoperability is only improving here, and there seems to be no
desire to remove it -- quite the opposite, we're actively working on
making it more useful for authors.


I think you are wrong about this.

WebIDL is making it easier to add and hook methods to a specific prototype
that already exists. *Adding* a whole new link in the prototype (which is
what I guess you mean by "just adding a prototype"—happy to go into the
problems with modifying existing prototypes!) is difficult today, and Web
IDL makes it even harder. These factors are working against you:

1. Some implementations have a writable __proto__ property on objects, that
let you set its prototype. However this isn’t portable—-__proto__ is not in
ECMA-262; theres Object.getPrototypeOf but not setPrototypeOf. Messing with
individual instances isn’t particularly robust or scalable anyway, because
if an instance leaks out before you update its prototype, then confusing
bugs result.

2. Web IDL locks down interface’s prototype property—S 4.5.1 interface
object must also have a property named “prototype” with
attributes { [[Writable]]: false, [[Enumerable]]: false,
[[Configurable]]: false }—so adding a prototype object within the existing
prototype chain of interfaces is unavailable.

3. Web IDL operations and attribute getter/setters validate the this pointer
this way, eg operations—S 4.5.6 [stuff about ImplicitThis] O is the result
of calling ToObject on the this value … If O is not a platform object that
implements interface I, throw a TypeError. So adding a prototype object off
the end of an existing prototype chain is also not possible (if you want the
property accessors and operations to work!)

Hence a binding layer can not make use of this, because it does not work.

That is why we are proposing something we have been calling
HTMLElement.register.

It doesn’t rely on #1—you set up prototype chains on constructors, it
doesn’t mess with __proto__ on instances. It works with #2—you add new
prototype objects to the end of the prototype chain. ie it is subtyping, not
mixins. It works with minimal impact to #3. Attribute getters and setters
and operations continue to validate "this" they way they are speced. We just
specify Interface [[Call]] in more detail to allow HTMLElement.call(this).

Dominic

On Thu, Sep 29, 2011 at 8:02 AM, Ian Hickson  wrote:

> On Wed, 28 Sep 2011, Boris Zbarsky wrote:
> > On 9/28/11 4:02 PM, Ian Hickson wrote:
> > > I don't buy the argument that an element's API can't change.
> >
> > To be more precise, such changes are very undesirable.
> >
> > > We have many counter-examples already in the platform, for
> > > example's API can change dynamcially as it loads new plugins
> >
> > This is actually a serious problem in practice, for both implementors
> > and consumers.  The behavior here is not very interoperable outside the
> > simplest cases last I checked.
> >
> > > XBL in Mozilla causes elements to change APIs on the fly
> >
> > We consider this to have been a design mistake that complicates both
> > implementation and use.  We have absolutely no desire to perpetuate it.
>
> There are specific problems in both those cases because of interaction
> with the C++ layer, as far as I can tell. The pure JS side of things,
> which is all that is needed for what we're talking about here, needs
> nothing more than just adding a prototype, something which is not only
> well-supported by all browsers, but defined in increasingly careful
> detail. Interoperability is only improving here, and there seems to be no
> desire to remove it -- quite the opposite, we're actively working on
> making it more useful for authors.
>
> IMHO this is the kind of thing that it makes imminent sense for a binding
> layer to make use of.
>
>
> > > Furthermore, we cannot for performance reasons require that the
> > > component library be loaded before the page is parsed, since that
> > > would mean that loading an HTML page would be blocked on loading a
> > > subresource. We already have this problem with both style and scripts,
> > > and it is a performance nightmare.
> >
> > I agree that it can cause performance problems, but as you note we
> > already have this with 

Re: HTML element content models vs. components

[Dominic Cooney]

On Wed, Sep 28, 2011 at 3: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):
>  and  have "Zero or more  elements" as content model, while 
> is specified to only be usable within ,  and .
> Now it is not inconceivable that someone would like to create a component
>  that acts as a list item, but expands on it. In order to allow this,
> the content model for , ,  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  would
> be allowed within , , , 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 -  elements as topmost elements
> in the tree.
>
> C.) Just don't allow components to be used in places that have a special
> content model.

I prefer this one, because:

1. It is very simple.

2. It discourages people from using components in cases already handled by HTML.

> Thoughts?
> - Roland

Should the shadow host element be rendered? (Was: Re: Notes from a component model pow-wow)

[Dominic Cooney]

Tab: How well is display: transparent received, eg on www-style?

I have a feeling this question—whether to render the host or not—depends on
whether you are using shadow DOM with components, or with existing elements.

When you want to use shadow DOM with components, the current solution seems
OK to me—the author surrounds elements that they want replaced, eg


  
UTC
...
  


Which  lets the x-timezone-picker have a completely different API to select
if you want, works well in the fallback case, etc.

Not rendering the host element is useful when that  is the outermost
element. With the model we proposed, making the host element have minimal
impact on rendering, is tedious: You have to reset its borders, margin,
padding, positioning, zoom, display, etc. Even that is obviously not
perfect.

Not rendering the host element is more expressive, because trivially if you
want to get the behavior proposed to date, you just put another instance of
the same kind as the host in the shadow. This assumes that there is some
convenient way to to control how styles applied to the host element can be
forwarded to the shadow.

On Wed, Sep 21, 2011 at 5:44 PM, Roland Steiner wrote:

> A neat side effect of not rendering the host element (whether by "display:
> transparent", or implicitly) is that encapsulated styling of a component
> becomes trivial. I.e., one may want a component be isolated (i.e., not be
> able to access the main document by default, and vice versa), but still
> style the host element somehow. At the moment this requires 2 style-sheets:
> one to style the host element, and one to style the contents of the
> component. If the host element doesn't get a render box, only the latter
> remains, which is easy to encapsulate by putting a 

Notes from a component model pow-wow

[Dominic Cooney]

Context: Last week some Bay Area/visiting Bay Area browser hackers met
to discuss the component model
<http://wiki.whatwg.org/wiki/Component_Model> This is my unedited
transcript. I am not much of a stenographer so no doubt there are
gaps.

Cast of characters:
boris--Boris Zbarsky
dg--Dimitri Glazkov
dpc--Dominic Cooney (me)
hyatt--Dave Hyatt
jamesr--James Robinson
maciej--Maciej Stachowiak
rs--Roland Steiner
sam--Sam Weinig
sicking--Jonas Sicking
slightlyoff--Alex Russell
plus others who I failed to log--sorry

dg: wanted to implement XBL2, 2 years later, slightlyoff (dojo) had
different proposal--simple web components. 1 yr ago post to webkit-dev
about components. XBL2 seems nice because it is a written spec. What's
the shape of the problem? See whatwg wiki Component_Model (MSFT
indicated some interest at least)

GOAL: Make sure everyone understands the problem we're trying to solve.
GOAL: Get feedback on the way to solve the problem.
GOAL: Get specific ideas.

Methodology:
1. Come up with a set of use cases that capture what you want to accomplish.
2. Study use cases come up with a set of properties.
3. Design building blocks that cohere with desired properties.
... see the wiki ... Component_Model_Methodology

Our use cases: Let the things that are happening on the web already
and in web browsers already happen in a more natural fashion. A lot of
JS frameworks do a lot "wrong" (a lot of crap

sam: what is success?

dg: can accomplish the use cases. Flow from use cases to
properties. Properties are orthogonal to each other. Building blocks
satisfy properties.

use cases: layout manager, can't use components from one library in a
layout manager for another ... see the wiki
... Component_Model_Use_Cases


maciej: what happens if you attach a shadow root to an element that
has a shadow root? dg: we throw--no use cases needed multiple shadow
roots

maciej: shadow root has a constructor, but the constructor has a huge
side effect--it should be a method on element

boris+: programattically building up a shadow tree looks clunky

hyatt: if there is one thing to really look at in XBL2, it is shadow tree stuff
like basic inheritance chain and the concept of explicit children and
insertion points in the shadow tree

maciej: most use cases need a declarative template that describes how
your template is structured based on your children

sam: this is based on use cases from existing widget libraries. The
underlying problem is creating a library. Widget libraries have
imperative code, hence they are imperative. dg: it is not possible to
know until you're running what your shape can be. sicking/hyatt: form
controls or video know their shape.

dg: people will still want an imperative way to build trees--so build
the declarative version using imperative code.

boris: this relies on the component to not leak the shadow tree. It
would be easier if the script is not in the document.

hyatt: you might have script that runs on the shadow root that needs to
be structured

maciej: programmatically building can be the primitive or you could
build the template mechanism on top; if you imagine the template is
the common case, then sometimes you need the script to attach event
handlers or mutate the dom the template created. So it depends what
you think the common case is before you design your primitives.

dg: this is just like DOM--you can add methods to existing DOM tree,
you can programatically build a tree; you can declaratively build a
tree

dpc: so if you had both that would be no bad thing hyatt: but we only
see the programmatic way here

dg:  element--insertion point inside the shadow tree, content
element lets you control how the shadow tree is flattened.

maciej + apple: need to see details boris: devil is in the details

dg: constructable DOM types

sam: is this just slightlyoff's proposal on script-coord? dg: no, that
is just say new ...(), this is about making subtypes

maciej: three parts 1. create existing built-in types, 2. if you have
a custom element that is logically a subclass of some element you need
to be able to construct that as well (dg: that is the one!) either by
defining its own way of getting constructed or hooking into some
common mechanism. 3. you need that subclassing mechanism to let
elements get privileged access to it. Maybe the primitives are
designed in such a way that you don't need it, but just #2 doesn't let
you override behavior.

dg: you can do that (#2) today with swizzling the prototype chain, boris:
you can't create a subtype with a different tag name--there is no real
reason that has to be the case.

maciej: ... so you need to create something that subclasses div and
has its own tag name.

dg: garden-o-matic uses constructable DOM types. But when you get them
back out of the DOM tree, your proto is gone.

hyatt: that (subclassing) seems natural

boris: seems like a good idea, lets not rathole on the details just yet

dg: so h

Re: HTMLElement.register--giving components tag names

[Dominic Cooney]

On Sat, Sep 3, 2011 at 12:04 PM, Ian Hickson  wrote:
> On Tue, 30 Aug 2011, Dominic Cooney wrote:
>>
>> I'm proposing we add something that lets script extend the set of tag
>> names, so there is less of a bright line between elements defined in the
>> HTML spec and elements defined in script. Something like:
>>
>> HTMLElement.register('x-contacts', ContactPicker);
>
> What's the fallback behaviour for when script is disabled?

The fallback behavior is basically that you’ll author your markup
either progressively enhance. If you want to support script being
disabled, I guess you’re going to use postbacks.

Progressive enhancement:


  
Name:


  


Fallback:


  … form same as before …


In this case when the x-contacts-picker is available, it suppresses
the fallback form with shadow DOM, or even by yanking it out of the
DOM.

Since registration is imperative, components imply running script.
There’s no story yet for when you have components but no script.
Looking at the use cases, they mostly (ie except for "panel" layout
manager) want to wire up event listeners for interactivity. I think
"has components, but doesn’t have script" will not be something people
design for.

Declarative would be nice for initializing the shadow DOM in a more
succinct way, though.

One thing that isn’t worked out is that sometimes you want to write
components that present their children, but if those children don’t
coincide with your fallback content you’re SOL. I expect one pattern
that might emerge is nested subcomponents, and have CSS handle
switching:


  

…
  
  


x-rockin {
  display: none;
}

x-rockin:bound {
  display: block;
}

Shadow DOM would select and output the subcomponent to flip the switch
on the fallback content.

> I think the XBL approach is far superior here -- have authors use existing
> elements, and use XBL to augment them. For example, if you want the user
> to select a country from a map, you can use a  with a list of
> countries in  elements in the markup, but then use CSS/XBL to bind
> that  to a "component" that instead makes the  look like a
> map, with all the interactivity that implies.

That sounds appealing, but it looks really hard to implement from
where we right now. Wearing my WebKit hat, one nice property of the
above is that we either have an element we’re going to rip out of the
DOM and replace:

 (gets replaced somewhat like renameNode)

Or one that isn’t particularly rich to begin with:

 (is HTMLUnknownElement until registered; perfect
tabula rasa for a component)

Whereas in the general case we’d be fighting with suppressing parts of
the nature of the element being bound.

Similarly, one thing that simplifies shadow DOM is that it affects the
rendering of the child content of an element, but the element (as a
block or whatever) is still there. This is relatively simple to
implement because we can just switch from one list of child content to
another when shadow DOM is present. But making the replacement happen
outside the box is more complicated, because there are many more
places that would need to be aware of this switch—many things that are
data would need to be behavior/logic. It is hard to be confident that
they interact well.

There are a few other things that I like about this compared to XBL.
However I don’t want to reject every idea in XBL out of hand—parts of
it are appealing, some parts look hard, but in total it is staggering.
Some ways in which this proposal is much simpler than XBL:

inheritance—there is none. You might layer behavioral changes in a
kind of inheritance of prototype chains in JavaScript, but one bespoke
prototype is just as onerous as many from the browser’s point of view.

multiple bindings—no, only a single binding.

unbinding—there is no "unregister". (Not stated but I am guessing
re-registering the same element name does something simple—throws, or
the last one wins.) There’s no way to remove a shadow root, either.

complexity of selectors—you just get to match on the element name. So
it is very simple and static.

Dominic

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

Re: HTMLElement.register--giving components tag names

[Dominic Cooney]

On Wed, Aug 31, 2011 at 1:38 PM, Erik Arvidsson  wrote:
> On Tue, Aug 30, 2011 at 22:33, Dominic Cooney  wrote:
>
>> You will notice that this says nothing about how prototypes are wired
>> up. It should. Maybe the argument to extend should have an optional
>> second field, proto, that specifies the new methods/getters/setters
>> that ContactPicker's prototype should introduce.
>>
>> This is not a general subtyping mechanism! It is only designed for
>> setting up subtypes of HTMLElement for use with register. When
>> ECMAScript and the DOM bindings are sufficiently aligned,
>> HTMLElement.register can be opened up to accept constructors defined
>> using ordinary ECMAScript mechanisms for subtyping DOM interfaces.
>> Scripts can continue to use extend (it is pretty succinct) or
>> constructors set up their own way.
>
> Providing a prototype is important.

So here’s a refinement. I will add this to the wiki:

interface ExtensibleElement {
  object extend(ElementRegisterOptions options) raises (DOMException);
}
HTMLElement implements ExtensibleElement;
…

[Callback]
interface ExtensionElementInitializer {
  void init(HTMLElement element);  // should this have a return value,
to allow replacement?
}

dictionary ElementRegisterOptions {
  ExtensionElementInitializer init;
  object? proto;  // ECMAScript-ism?
}

Author: If options.proto is specified,
HTMLElement.prototype.isPrototypeOf(options.proto) should be true, and
options.proto should not be a platform object, nor have a platform
object on the prototype chain.

UA: If options.proto is specified, and
HTMLElement.prototype.isPrototypeOf(options.proto) is false, or
options.proto is a platform object, or options.proto has a platform
object on the prototype chain, register may throw a TYPE_ERROR.

If options.proto is not specified, the resulting constructor’s
prototype property will be HTMLElement.prototype or
HTMLElement.prototype.isPrototypeOf(<>) will be
true. This object might have been synthesized by the UA.

UA: When the constructor is invoked, (same conditions on the proto as
before) the constructor may throw a TYPE_ERROR.

> For example I can imagine UI toolkits providing their own "base class"
> that all the custom elements extend.

That is most straightforward when you have

FancyWidgetBase : HTMLElement
FancyButton : FancyWidgetBase

It does not work so well when you want FancyButton to be a
HTMLButtonElement. Then you need a factory of FancyWidgetBases that
hook one up to HTMLButtonElement, HTMLDivElement, etc.

> Also, it seems essential to allow extending other things than just 
> HTMLElement.

Wearing my author hat, that sounds appealing. Browser internals may do
things like switch on an element’s tag name. It would need to start
consulting the table of extensions when it did that in order to
realize that x-fancy-button is a button element.

Re: xdash name prefixes (was Re: Component Model Update)

[Dominic Cooney]

I think for convenience registration probably should be carried around
with the component, because:

1. It is convenient for the author using the component.

2. If the component library reuses its own abstractions, it probably
expects them to have a specific element name. Putting registration in
the hands of the author using the component jeopardizes that.

However I don’t think the imperative API is right, or at least not
enough, for these reasons: (assuming you accept that registration
happens in the component library—the death before inconvenience
premise):

1. The imperative registration API is *not* OK for confined
components, because if you run script out of the library in your
context to do the registration, you are hosed.

2. There’s no way for the author to manage conflicts or namespace pollution.

Something declarative like module imports and exports, with scoped
renaming, for registered tag names would be nice. This avoids these
two problems, and is pretty convenient (particularly if import * gets
you all of the exports by default.)

Dominic

On Wed, Aug 31, 2011 at 10:54 AM, Roland Steiner
 wrote:
> On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth  wrote:
>>
>> Doesn't it seem more likely that the third-party will do the
>> registration in whatever script you include that implements the Like
>> button, or whatever?
>
> That's just a matter of convention, no? I don't think it's unreasonable to
> frame it as "in order to use a component you need to load its source and
> register a suitable element name for it.".
> OTOH, there's nothing to prevent a package from doing the registering in one
> go. But if such a package then really leads to a clash, I'd prefer to first
> ask the authors to sort it out.
>
> Cheers,
> - Roland

HTMLElement.register--giving components tag names

[Dominic Cooney]

"Components" (see
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
what I mean) need to present an API to script. For example, a
"contacts" component might want to expose a refresh() method that
pulls new contacts from the server. Components also need to hook up
internal behavior implemented in script; a split pane might need to
hook up a mouse listener on its splitter before it can really behave
like a split pane.

In script widget libraries today (YUI, Closure, etc.) this is easy
when the widget has been created from script: when the author calls
the constructor/factory method/whatever the widget can create DOM,
hook up event listeners, set up the prototype chain however it wants,
etc.

However things get really murky when authors start to use markup,
because then the parser is creating elements that are at best only
minimally functional until they're "enhanced." So today widget
implementations need to handle enhancing an existing element;
frameworks need to detect these unenhanced elements and invoke
something to enhance them; and authors needs to debug this unholy mess
when an unenhanced element escapes and their page breaks.

Wouldn't it be nice if the browser made this problem go away?

I think HTML itself shows us how life could be better: Consider the
HTML video element. It looks like a "subtype" of HTML element, with
all of the methods and attributes a HTML element has (via the
prototype chain), and adds methods and attributes specific for doing
video. When you do document.createElement('video') you get back an
object that is ready to use. There's no step to "enhance" it. When you
do p.innerHTML = "", you get a video
player. There's no flash of unstyled content. If you clone it and
insert the copy into the DOM again, all of the playback controls are
still wired up and responsive.

I'm proposing we add something that lets script extend the set of tag
names, so there is less of a bright line between elements defined in
the HTML spec and elements defined in script. Something like:

HTMLElement.register('x-contacts', ContactPicker);

The first argument is an element name. The second is a constructor
function, whose prototype property points to an object which
introduces the API for contacts (eg a refresh method) and is wired up
to HTMLElement.prototype.

When the parser encounters , it creates an object by
calling the ContactPicker function as a constructor. The constructor
can wire up any internal state it wants, like creating DOM and
attaching event listeners. When a script later retrieves the element,
say with document.querySelector('x-contacts'), the object created
earlier with ContactPicker is what it gets back. Since the constructor
is run as the parser is creating the element, there's no time when the
unenhanced element is available to script.

My proposal pretty much ends here: The component itself is just
implemented with script, DOM and CSS. There are no special hooks for
participating in layout (just use DOM and CSS) or form submission
(just create form controls using DOM) or security (same origin policy
still applies) or networking (just use WebSockets or XHR) or anything
else. There is no magic, other than teaching the browser about the new
tag name.

I'm suggesting that all registered tag names have to start with x-.
This is to give component authors a place to build without worrying
about conflicting with future HTML specs; the HTML spec won't define
elements with names starting with x-. (Component authors may chose x-
names that conflict with each other, though.) People working on the
HTML spec can study what kinds of components are popular in the wild
and consolidate the best ideas into new HTML elements. Page authors
can decide if and when to move their pages from their bespoke x-
components to the HTML alternatives, which should be better.

Pages that have to work in older browsers can use fallback content.
(This is exactly what the HTML spec advises authors to do with the
video element, incidentally.) In newer browsers the component script
can remove or hide the fallback content.

There's the question of what to do when there is a call to
HTMLElement.register('x-contacts', …) at some point after an x-contact
element has been parsed. We have to do something that makes sense for
async scripts. I think the solution is to replace the element, and the
recent discussion on this list about renameNode is interesting and
relevant.

One practical issue with this proposal is that creating a subtype of
HTMLElement in script (ie defining the ContactPicker function in the
above example) is hard/impossible. A couple of the problems are:

- Defining a subtypes in JavaScript is hard to begin with: You need to
create a function, and maybe set its object prototype up; you need to
create a prototype object and wire its object prototype up; you might
add a constructor property to the new prototype object; and you need
to remember to call your "base type" constructor to let it do an

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

[Dominic Cooney]

On Fri, Aug 26, 2011 at 12:24 AM, Roland Steiner
 wrote:
> Unless I'm misunderstanding something, I believe this actually is - or at
> least touches upon - several questions in disguise:
> .) Do we want to allow decoration of elements that are already in the DOM
> tree?

If by "decoration" you mean "new ShadowRoot" then I think the answer
is "yes." Why would you disallow it? It throws one more obstacle in
the author’s way.

> - which is for all intents and purposes a corollary of:
> .) Do we allow calling of "new ShadowRoot" outside of an element
> constructor?

>From the DOM bindings point of view, it is very difficult to decide
when a "constructor" is running. How would you do it? Stack walking? I
don’t think any other bindings do this sort of thing.

> If no, then we don't have a problem with "dead elements", because the author
> can only declare new elements (and use encapsulation), but not meddle with
> existing ones. FWIW, I don't think there is any real use-case for calling
> "new ShadowRoot" within the constructor twice.

I take the point that if you can only call it once, and only in
constructors, then you can easily assign meaning to "new ShadowRoot(x)
where x is not an extension element." It throws. But you could just
make that restriction without all of these other restrictions on
constructors, once only, etc.

I don’t want us to confound being able to call it only once or more
than once for a given element, being able to call it for extension
elements only or built-in element types too, and being able to call it
only inside constructors or also outside of constructors.

> However, in this case we have to answer how encapsulation can address the
> stated use cases for decoration. This probably means answering:
> .) How is attribute forwarding handled from the host element to a nested
> (form) element?

+1. We should think about concrete proposals. Also: Do the use cases
need it? And if we did nothing, what would authors do in response (ie
how ugly are mutation listeners?)

> .) How can components participate in forms (and other fun)?
> ... or just leave decoration out for the time being (which I think is quite
> reasonable).

We should brainstorm other "fit" issues. What about the selection?
Does it leak shadow nodes (probably not.) So can confined scripts ever
read the selection? etc.

> OTOH, if the answer to the decorators question is "yes", then the above
> mentioned issues with multiple shadow roots arise.

I think we need to think about these issues anyway. But maybe the
multiple shadows problem is a good one to tackle early.

Dominic

Re: Component Model Update

[Dominic Cooney]

On Fri, Aug 26, 2011 at 12:42 AM, Roland Steiner
 wrote:
> On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney  wrote:
>>
>> Here is a quick first cut:
>>
>> How about use cases like these:
>>
>> - Extension that wants to inspect  and warn you
>> when you are entering you password in an insecure form (from abarth
>> earlier in the thread.)
>> - Password manager that wants to find anything that looks like a login
>> panel and decorate it/fill it.
>> - Extension that removes formatting from a page to make it easier for
>> on-screen reading.
>> - Extension that finds phone numbers in a page and embosses them with
>> links to a crank call service.
>> - Extension that replaces all ads in a page with pictures of kittens.
>> Or an extension that detects pictures of kittens and monetizes them
>> with ads.
>> - Extension that on hover looks up
>> dictionary/thesaurus/translation/urban dictionary/wikipedia/etc.
>
> This is a great list!
> As for allowing extensions to inspect the shadow DOM: unless we want to
> break isolation/confinement again, I believe this should be handled by the
> relevant browser APIs for extensions, along the lines of "shadow =
> extensions.getShadowFor(element)". If the extension shouldn't be able to
> mess with shadows, it can be blocked at this point.

Yes, I think a separate function for doing the lookup is a good idea.
It keeps the set of attributes and methods on a given DOM object the
same for pages and extensions.

Dominic

Re: Components/constructable DOM elements: mandatory tag registration?

[Dominic Cooney]

I think HTMLElement.call should throw if there’s not an associated tag name.

However exactly how that association happens, I am not sure.
JavaScript can’t rely on the 'constructor' property. Shadowing the
tagName attribute on the prototype is not ideal, because it may be
mutable and it would be confusing if it was mutated.

Alternatively we could require subtypes of some specific tag, like
HTMLDivElement, and use that tag name if there's no registered tag
name. That means the UA can't limit special casing to x- elements,
although I think that is OK.

Dominic

On Fri, Aug 26, 2011 at 1:16 AM, Roland Steiner
 wrote:
> From the discussion about "x-" prefixed names another question crossed my
> mind: Suppose an author defines a component, but doesn't register a tag
> name. AFAICT, at this point nothing prevents him from inserting such a new
> element into the DOM. E.g.:
> 
> 
>     function MyNewElement() {
>         HTMLElement.call(this);
>         // ...
>     }
>     var div = document.getElementById("div");
>     div.appendChild(new MyNewElement());
>
>     // ... Look Ma, no Element.register() call!
>
>     var text = div.innerHTML;  // <- what does this return?
> 
>
> Cheers,
> - Roland

Re: Component Model Update

[Dominic Cooney]

On Thu, Aug 25, 2011 at 5:41 PM, Olli Pettay  wrote:
> On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
>>
>> All,
>>
>> Over the last few weeks, a few folks and myself have been working on
>> fleshing out the vision for the Component Model. Here's what we've
>> done so far:
>>
>> * Created a general overview document for behavior attachment problem
>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>> * Wrote down the a set of guidelines on how we intend to tackle the
>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>> * Updated the list of use cases and desired properties for each case
>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>> * Captured the overall component model design and how it satisfies
>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>> including a handy comparison with existing relevant specs and
>> implementations
>>
>> (http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
>>
>> After of this iteration, the proposed shadow DOM API no longer
>> includes the .shadow accessor (see details here
>> http://dglazkov.github.com/component-model/dom.html). Instead, the
>> shadow DOM subtree association happens in ShadowRoot constructor:
>>
>> var element = document.createElement("div");
>> var shadow = new ShadowRoot(element); // {element} now has shadow DOM
>> subtree, and {shadow} is its root.
>> shadow.appendChild(document.createElement("p")).textContent = "weee!!';
>
>
> One thing missing is some kind of declarative way to define
> shadow trees, similar to XBL1's .
>
> It would be rather strange if one needs to explicitly construct
> shadow tree after the element is created.

Looking at the use cases, it looks like components need to run script
anyway, at least to hook up event listeners. So would it be fair to
rephrase this as: “There should be a concise way to get HTML into a
shadow tree.” ?

> (Component Model is getting closer and closer to XBL, and it is not
>  quite clear to me why XBL2 couldn't be used. It needs some
>  minor fixes, but should work otherwise.)

I feel like XBL2 doesn’t get the power-to-weight ratio right—it looks
hard to use and implement, and as this

summarizes XBL2 doesn’t mesh well with JavaScript, and doesn’t get
confinement. So this proposal looks like it made a good tradeoff…
eliminate a lot of what’s complex to use and implement in XBL2, and
focusses instead on useful capabilities like confinement.

Dimitri et al studied XBL2 in depth in designing the component model.
It is possible when you follow through with minor fixes to XBL2 you
will end up here anyway… it might be more productive to work on
fleshing out and fixing this proposal.

>> Keeping the accessor out allows for proper encapsulation and
>> confinement (better explanation of these new bits of terminology here:
>> https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
>> also simplifies the API surface.
>>
>> Please review. Feedback is welcome!
>>
>> :DG<
>>
>>
>
>
>

Re: Component Model Update

[Dominic Cooney]

Here is a quick first cut:

How about use cases like these:

- Extension that wants to inspect  and warn you
when you are entering you password in an insecure form (from abarth
earlier in the thread.)
- Password manager that wants to find anything that looks like a login
panel and decorate it/fill it.
- Extension that removes formatting from a page to make it easier for
on-screen reading.
- Extension that finds phone numbers in a page and embosses them with
links to a crank call service.
- Extension that replaces all ads in a page with pictures of kittens.
Or an extension that detects pictures of kittens and monetizes them
with ads.
- Extension that on hover looks up
dictionary/thesaurus/translation/urban dictionary/wikipedia/etc.

How does it change desired properties? The desired properties are good
for the page. Extensions can typically exercise capabilities the page
has (right?) Extensions can additionally violate encapsulation.
However the UA may bless some encapsulation as inviolate (when the
implementation uses shadow and wants to rely on nobody—not even
extensions—messing with it.) Extensions sometimes have their own
notion of confinement. I think it is OK if extensions can’t violate
confinement. There is no deep reflective API for JavaScript, so it
would not be so useful anyway?

How does it change the primitives? Extensions can detect which
elements have shadow, get the shadow root, and get the host for a
given shadow root. (In addition to creating shadow roots and any other
typical DOM manipulations an extension can do.) Do any of the above
use cases need to access the "flattened" tree? If so, maybe there
should be an API for that, because computing it in script would be
tedious.

Dominic

On Thu, Aug 25, 2011 at 1:06 PM, Dimitri Glazkov  wrote:
> On Wed, Aug 24, 2011 at 8:23 PM, John J Barton
>  wrote:
>>
>>
>> On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov 
>> wrote:
>>
>>>
>>> > Independent of our different point of view on control, shadow DOM needs
>>> > debug APIs. So much the better if these are available to extensions.
>>>
>>> Let me see if I can capture this into a feature: user scripts may have
>>> access to shadow DOM subtrees. In terms of WebKit, when run in user
>>> script worlds, the Element has an extra accessor to spelunk down the
>>> shadow DOM.
>>>
>>> Is this what you're suggesting?
>>
>> Yes. Encapsulation is good UI, not security. I want to ignore the subtree
>> "normally" but jump into the astral plane for special enlightenment.
>> XUL has such a mechanism, but I'd wish for less mystery. I spent many hours
>> trying to keep element inspection working on XUL. The API should aim to work
>> well with code designed for normal elements.
>> jjb
>
> Ok. Can you help me formulating a use case for this API, and how it
> affects desired properties, and building blocks?
>
> Anybody has an allergic reaction to something like this?
>
> :DG<
>
>>>
>>> :DG<
>>>
>>> >
>>> > jjb
>>> >
>>
>>
>

Re: Component Model Update

[Dominic Cooney]

On Thu, Aug 25, 2011 at 2:03 PM, John J Barton
 wrote:
> I'm still trying to digest this, but it seem pretty clear the 'confinement'
> is the "clear scope" thing I was asking about on es-discuss.  According to
> that discussion, this means needs to fit with the 'modules' thing on
> ecmascript. That seems to be where you are headed, but basing a new proposal
> on another new proposal is ... well I'll let you fill in the blank depending
> on how you are feeling.

Courageous?

> I guess the actual implementation of confined script evaluation would not be
> difficult (Firefox can do it now if you can get some one to explain it).
> Getting the entire 'modules' effort out? I'm thinking that could be hard.
>
> jjb

If we do the design so that good things are possible when modules
arrive, and the component model is useful for some use cases even
without hermetic confinement, then it sounds reasonable to work on
specing, implementing and getting experience with the other parts?

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

[Dominic Cooney]

On Thu, Aug 25, 2011 at 11:58 AM, Dimitri Glazkov  wrote:
> Also -- we can always try to start with just one subtree, and then
> enable multiple. Since the plumbing and the order specification are
> trivial, it's something we can easily add.
>
> :DG<

Yes. This sounds like a good plan. If we come up with use cases, we
can reevaluate in the light of new ideas. Even if new use cases prove
compelling, starting with a single shadow is probably still a good
approach anyway.

Dominic

> On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney  wrote:
>> On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov  
>> wrote:
>>> On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson  wrote:
>>>> On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov  
>>>> wrote:
>>>>> What do you think?
>>>>
>>>> +1
>>>>
>>>> It would surely allow certain use cases to be covered that are not
>>>> covered today with form control elements.
>>>>
>>>> How about not throwing on new ShadowTree(element) and just append a
>>>> new shadow root after the existing ones?
>>>
>>> That would make the order "as instantiated", which is totally fine by
>>> me. It would be good to add a use case which describes the need for
>>> this. Anyone got a good idea? Don't want to reuse Adam's autocomplete
>>> one, since HTML already provides a solution.
>>
>> +1 to finding a use case. When I try to think of one, I usually end up
>> with: I would rather do this using composition. The only benefit of
>> multiple shadows over composition is that I don’t need to forward most
>> of the API to the primary part of the composition.
>>
>> One big question for me is: Do you expect multiple shadows to be
>> designed to work together, or come from multiple independent sources
>> (like different script libraries)?
>>
>>> :DG<
>>>
>>>>
>>>> --
>>>> erik
>>>>
>>>
>>
>

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

[Dominic Cooney]

On Thu, Aug 25, 2011 at 11:57 AM, Dimitri Glazkov  wrote:
> On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney  wrote:
>> On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov  
>> wrote:
>>> On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson  wrote:
>>>> On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov  
>>>> wrote:
>>>>> What do you think?
>>>>
>>>> +1
>>>>
>>>> It would surely allow certain use cases to be covered that are not
>>>> covered today with form control elements.
>>>>
>>>> How about not throwing on new ShadowTree(element) and just append a
>>>> new shadow root after the existing ones?
>>>
>>> That would make the order "as instantiated", which is totally fine by
>>> me. It would be good to add a use case which describes the need for
>>> this. Anyone got a good idea? Don't want to reuse Adam's autocomplete
>>> one, since HTML already provides a solution.
>>
>> +1 to finding a use case. When I try to think of one, I usually end up
>> with: I would rather do this using composition. The only benefit of
>> multiple shadows over composition is that I don’t need to forward most
>> of the API to the primary part of the composition.
>>
>> One big question for me is: Do you expect multiple shadows to be
>> designed to work together, or come from multiple independent sources
>> (like different script libraries)?
>
> Can you help me understand what you mean by this? What would be a
> functional difference between the two cases you outlined?

Can I push that on the stack until we have use cases? My suspicion is
that it will be qualitatively different; if a widget library provides
a set of shadows that are designed to work together, the library can
manage the complexity of stacking them right. If the author has to get
the order right, it will be hard. But without use cases I’m not
certain—just a hunch.

I have been wracking my brain for use cases. I keep going in two circles though:

1. Sometimes you want to alter the presentation of the element. (Or at
least the element’s children—we’ve always just focussed on the
element’s children.) But sometimes you want to augment the
presentation. Imagine if  did not use shadow, and
you want to use shadow to add a very fancy tooltip. That won’t work,
because you will obliterate the text in the input element when you add
the tooltip. Why does the *first* shadow have such special semantics?

2. You describe multiple shadows as stacking up side-by-side. What
about containment? What if I could do this:

var shadowA = new ShadowRoot(someElement);
// init shadow A
var shadowB = new ShadowRoot(shadowA);
// init shadow B

then shadowB’s  could chew on the flattened tree of shadowA.
It can put things side-by-side by putting elements side-by-side with
; it can also put things inside other things by nesting
. (This doesn’t solve your order problem, though.)

>>> :DG<
>>>
>>>>
>>>> --
>>>> erik
>>>>
>>>
>>
>

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

[Dominic Cooney]

On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov  wrote:
> On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney  wrote:
>> On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov  
>> wrote:
>>> All,
>>>
>>> Adam raises an interesting question: should we allow more than one
>>> shadow DOM subtree per element?
>>>
>>> Background: per current design
>>> (http://wiki.whatwg.org/wiki/Component_Model#Encapsulation), you can
>>> only create one ShadowRoot instance per element.
>>>
>>> The reasoning behind this goes like this:
>>> * The use cases for adding an extra shadow DOM subtree for built-in
>>> elements seemed like hacks around existing limitations of the
>>> elements;
>>> * We give leverage to elements, allowing them to control whether their
>>> shadow DOM subtrees can be extended. If the element exposes its shadow
>>> subtree, then yes you can. If it don't then no you can't.
>>
>> What is the benefit of this leverage? Secure presentation of > type="file">? Sane editing model for ?
>
> No, this isn't for built-in controls. If Bob builds a Foo element, he
> may decide to give it a Foo.shadow accessor to let anyone muck with
> its shadow DOM. That's the situation I was talking about.

Got it.

Note that component authors could permit extension in a controlled way
by including an instance of a trivial component within the larger
component with simple composition, and then expose _that_ element’s
shadow root. That would permit "multiple shadows" within a component.

>>
>>> * Multiple shadow DOM subtrees introduce the problem of ordering,
>>> where the order of rendering these trees is unknowable at the time of
>>> creation, which seems like a bad thing.
>>>
>>> Folks who worked on this with me, I am sure I am missing a couple of
>>> things here -- please chime in.
>>>
>>> However, allowing multiple subtrees certainly has benefits:
>>> * No more explicit dead-list of elements that can't have a shadow DOM.
>>> You can just create another one.
>>
>> This problem could be tackled without the complexity of multiple
>> shadows by reducing the dead-list to zero, by defining how a shadow
>> would work with , , … any HTML element we hitherto
>> thought would be “dead.”
>
> How would you do that? I am curious. If input element creates a shadow
> DOM when constructed, it can't have a shadow DOM. How can we make it
> work with shadow DOM?

If we decide that the element should always be presented, then the
built-in shadow DOM could include a trivial descendant element that is
the extension point. When the script requests a shadow root for the
component, it is commuted and gets a shadow root for the extension
point.

If we decide that it is OK to suppress the presentation of the
component, then we could imagine that these elements capture a
reference to their built-in shadow root and use that. When the script
requests a shadow root for the component, the element’s shadow is
replaced. The implementation of the element continues to consult its
captured shadow.

>> Or do you mean dead-list of instances of elements, not dead-list of
>> kinds of elements?
>
> I think you lost me here -- can you explain?

There are two kinds of "dead"—dead on arrival, like ,
; elements that you know by looking at the tag name that can
not have shadow (at least in a given implementation) because it uses a
shadow.

Then there are newlydeads, like:

function FooElement() {
  // "super" initialization etc.
  // not dead here
  var shadow = new ShadowRoot(this);
  // 'this' is newly dead to extension via new ShadowRoot at this point
}

Making ,  etc support shadows means nothing is DOA;
permitting multiple shadows means there are no newlydeads
either—nothing is ever dead.

Dominic

> :DG<
>
>>
>>> * More freedom for extending elements (yes, this is the opposite of
>>> the single-tree control benefit above)
>>>
>>> Concept-wise:
>>> * Multiple shadow subtrees would just be a list.
>>> * The order of a list is established once and is unchangeable. How it
>>> is established? I have no idea.
>>> * The trees are rendered sequentially (in list order) as if they are
>>> children of the hosting element.
>>>
>>> Security-wise, I don't see any issues off hand.
>>>
>>> Plumbing-wise, adding support for multiple shadow subtrees should be
>>> fairly simple, provided that we solve the order problem.
>>>
>>> What do you think?
>>>
>>> :DG<
>>>
>>
>

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

[Dominic Cooney]

On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov  wrote:
> All,
>
> Adam raises an interesting question: should we allow more than one
> shadow DOM subtree per element?
>
> Background: per current design
> (http://wiki.whatwg.org/wiki/Component_Model#Encapsulation), you can
> only create one ShadowRoot instance per element.
>
> The reasoning behind this goes like this:
> * The use cases for adding an extra shadow DOM subtree for built-in
> elements seemed like hacks around existing limitations of the
> elements;
> * We give leverage to elements, allowing them to control whether their
> shadow DOM subtrees can be extended. If the element exposes its shadow
> subtree, then yes you can. If it don't then no you can't.

What is the benefit of this leverage? Secure presentation of ? Sane editing model for ?

> * Multiple shadow DOM subtrees introduce the problem of ordering,
> where the order of rendering these trees is unknowable at the time of
> creation, which seems like a bad thing.
>
> Folks who worked on this with me, I am sure I am missing a couple of
> things here -- please chime in.
>
> However, allowing multiple subtrees certainly has benefits:
> * No more explicit dead-list of elements that can't have a shadow DOM.
> You can just create another one.

This problem could be tackled without the complexity of multiple
shadows by reducing the dead-list to zero, by defining how a shadow
would work with , , … any HTML element we hitherto
thought would be “dead.”

Or do you mean dead-list of instances of elements, not dead-list of
kinds of elements?

> * More freedom for extending elements (yes, this is the opposite of
> the single-tree control benefit above)
>
> Concept-wise:
> * Multiple shadow subtrees would just be a list.
> * The order of a list is established once and is unchangeable. How it
> is established? I have no idea.
> * The trees are rendered sequentially (in list order) as if they are
> children of the hosting element.
>
> Security-wise, I don't see any issues off hand.
>
> Plumbing-wise, adding support for multiple shadow subtrees should be
> fairly simple, provided that we solve the order problem.
>
> What do you think?
>
> :DG<
>

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

[Dominic Cooney]

On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov  wrote:
> On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson  wrote:
>> On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov  wrote:
>>> What do you think?
>>
>> +1
>>
>> It would surely allow certain use cases to be covered that are not
>> covered today with form control elements.
>>
>> How about not throwing on new ShadowTree(element) and just append a
>> new shadow root after the existing ones?
>
> That would make the order "as instantiated", which is totally fine by
> me. It would be good to add a use case which describes the need for
> this. Anyone got a good idea? Don't want to reuse Adam's autocomplete
> one, since HTML already provides a solution.

+1 to finding a use case. When I try to think of one, I usually end up
with: I would rather do this using composition. The only benefit of
multiple shadows over composition is that I don’t need to forward most
of the API to the primary part of the composition.

One big question for me is: Do you expect multiple shadows to be
designed to work together, or come from multiple independent sources
(like different script libraries)?

> :DG<
>
>>
>> --
>> erik
>>
>

Re: Component Model Update

[Dominic Cooney]

On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov  wrote:
> On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
>> I feel somewhat like I'm walking into the middle of a movie, but I
>> have a couple questions.  Please forgive me if my questions have
>> already been answer in previous discussions.
>
> Welcome to the show!
>
>>
>> On Tue, Aug 23, 2011 at 1:40 PM, Dimitri Glazkov  
>> wrote:
>>> All,
>>>
>>> Over the last few weeks, a few folks and myself have been working on
>>> fleshing out the vision for the Component Model. Here's what we've
>>> done so far:
>>>
>>> * Created a general overview document for behavior attachment problem
>>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>>> * Wrote down the a set of guidelines on how we intend to tackle the
>>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>>> * Updated the list of use cases and desired properties for each case
>>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>>> * Captured the overall component model design and how it satisfies
>>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>>
>> This section 
>> seems to imply that components can override the traversal and
>> manipulation APIs defined by DOM Core.  Do you mean that they can
>> override the JavaScript APIs folks use for traversal and manipulation,
>> or can they override the traversal and manipulation APIs used by other
>> languages bound to the DOM and internally by specifications?
>
> I certainly didn't mean to convey either: the former as some new thing
> introduced by the Component Model, and the latter as something that is
> being attempted.
>
> All it says is that your components are DOM objects and inherit the
> DOM Core APIs. You can add your own properties and extend the API
> surface.
>
>>
>> For example, suppose we implemented the Component Model in WebKit and
>> a component overrided the nextSibling traversal API.  Would
>> Objective-C code interacting with the component (e.g., via Mac OS X's
>> Object-C API for interacting with the DOM) see the original API or the
>> override?  Similarly, for browsers such as Safari, Chrome, Firefox,
>> and Opera that provide a script-based extension mechanism, would
>> extensions interacting with these components (e.g., via isolated
>> worlds or XPCNativeWrappers) see the original API or the override?
>>
>> My sense is that you only mean that Components can shadow (and here I
>> mean shadow in the traditional Computer Science sense
>> ) the normal
>> traversal and manipulation, not that they can override it, per se.
>
> Just to reiterate, the Component Model doesn't add or change anything
> here that's not possible today.
>
> How can I make this more clear in the overview?
>
>>
>>
>> This section 
>> says "... and ensures that no information about the shadow DOM tree
>> crosses this boundary."  Surely that's an overstatement.  At a
>> minimum, I assume the shadow DOM participates in layout, so its height
>> and width is leaked.
>
> Oh you're right. I need to ratchet down the language. "Information" is
> a very heavy word.
>
>>
>>
>> ---8<---
>> var shadow2 = new ShadowRoot(this); // throws an exception.
>> --->8---
>>
>> I'm not sure I understand why that's the best design decision.  Maybe
>> this is explained elsewhere?  I link would help folks like me
>> understand better.  It looks like this design decision is tied up into
>> how http://wiki.whatwg.org/wiki/Component_Model#Composability works.
>
> Ah, good point. I need to expand on this. I'll start a thread to discuss.
>
>>
>>
>> This section 
>> says "... this also explains why you can't add shadow DOM subtrees to
>> input or details elements."  It seems unfortunate that some elements
>> will accept new ShadowRoots but others will not.  Is this an
>> implementation detail?  What's the list of elements that reject
>> ShadowRoots?
>
> As I mentioned in the section, any element that uses more than one CSS
> box and isn't specified in terms of CSS. The spec would need to have
> an explicit list.
>
>>
>> As an example, it seems entirely reasonable that you'd want to create
>> an autocomplete dropdown component for use with an input element.  It
>> seems like the natural thing to do would be to subclass the "input"
>> element and add an autocomplete dropdown as a shadow DOM.  This design
>> choice appears to preclude this use case.  Instead, I need to subclass
>> "div" or whatever and replicate the HTMLInputElement API, which seems
>> like the opposite of the "reuse existing mechanisms" design principle
>> .
>
> For what it's worth, this particular use case has grown into a list
> attribute on the input element:
> http://www.whatw

Re: Element.create(): a proposal for more convenient element creation

[Dominic Cooney]

Element.create looks neat. Three thoughts:

First, I think Element.create *and* constructors like new
HTMLDivElement(attributes, children) are both useful. Element.create is good
when you have a tag name in hand, are creating unknown elements, or are
creating elements that don’t have a specific constructor (ins/del.)

New is good when you’re creating an element “statically.” It’s succinct, and
if you misspell the name you get an exception instead of an unknown element,
for example:

Element.create('vdieo', {src: '…'}) → no error, HTMLUnknownElement that
behaves nothing like 

new HTMLVdieoElement({src: '…'}) → ReferenceError, stack trace points me to
the faulty line of code.

When the element being created is “static” I think constructors are more
readable, too:

var b = Element.create('button', {}, [
  Element.create('img', {src: 'http://…'}),
  document.createTextNode('Click me!')
]);

compared to:

var b = new HTMLButtonElement({}, [
  new Image('http://…'),
  new TextNode('Click me!')
]);

Let me briefly reiterate that I think we want *both* Element.create and
constructors; they have complementary uses.

---

Second, re: setAttribute vs setting properties, there might be types other
than functions we want to not treat as strings; for example if a UA
implements CSSOM it might be nice to be able to set a style without having
to serialize and reparse the CSSStyleDeclaration.

Can we spec whether something in the attributes hash is set via setAttribute
or via setting a property based on the IDL for that element?

Alternatively we could provide a syntax, eg '@class': 'foo' to
setAttribute('class', 'foo') and className: 'foo' to set elem.className =
'foo'.

--

Third, is the order of attributes significant for XML namespace
declarations? eg does this:



mean the same thing as



? If not, including namespaces in the attribute dictionary is fraught,
because the iteration order of properties is undefined.

Dominic

On Fri, Aug 5, 2011 at 3:22 PM, Garrett Smith wrote:

> On 8/4/11, Garrett Smith  wrote:
>
> [...]
> ser-generated function function.
> >
> > The scope of handler attributes is explained in HTML 5, though
> > incompletely:
> >
> http://dev.w3.org/html5/spec/Overview.html#event-handler-content-attributes
> > That's incomplete.
> >
> Correction: It is complete, I just misread it.
> --
> Garrett
>
>