Re: Telecon / meeting on first week of April for Web Components

[Dimitri Glazkov]

I am game, per usual.

:DG<

On Mon, Mar 14, 2016 at 4:55 PM, Ryosuke Niwa  wrote:

> Hi all,
>
> We've been making a good progress on shadow DOM and custom elements API
> but there seems to be a lot of open questions still.  I've asked a couple
> of people involved in the discussion, and there seems to be an interest for
> having another tele-conference or an in-person meeting.
>
> Can we schedule one in the second week of April (April 4th through 8th)?
>
> - R. Niwa
>
>
>

Re: Art steps down - thank you for everything

[Dimitri Glazkov]

+1

:DG<

On Thu, Jan 28, 2016 at 7:45 AM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:

> Hi folks,
>
> as you may have noticed, Art has resigned as a co-chair of the Web
> Platform group. He began chairing the Web Application Formats group about a
> decade ago, became the leading co-chair when it merged with Web APIs to
> become the Web Apps working group, and was instrumental in making the
> transition from Web Apps to the Web Platform Group. (He also chaired
> various other W3C groups in that time).
>
> I've been very privileged to work with Art on the webapps group for so
> many years - as many of you know, without him it would have been a much
> poorer group, and run much less smoothly. He did a great deal of work for
> the group throughout his time as co-chair, efficiently, reliably, and
> quietly.
>
> Now we are three co-chairs, we will work between us to fill Art's shoes.
> It won't be easy.
>
> Thanks Art for everything you've done for the group for so long.
>
> Good luck, and I hope to see you around.
>
> Chaals
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  cha...@yandex-team.ru - - - Find more at http://yandex.com
>
>

Re: [Web Components] proposing a f2f...

[Dimitri Glazkov]

Won't it rain though?

:DG<

On Wed, Oct 28, 2015 at 5:47 PM, Chris Wilson  wrote:

> Or host in Seattle.  :)
>
> On Thu, Oct 29, 2015 at 9:20 AM, Travis Leithead <
> travis.leith...@microsoft.com> wrote:
>
>> I would prefer a late January date so as to allow me to arrange travel.
>> Otherwise, I’m happy to attend remotely anytime.
>>
>>
>>
>> *From:* Dimitri Glazkov [mailto:dglaz...@google.com]
>> *Sent:* Thursday, October 29, 2015 2:52 AM
>> *To:* Olli Pettay 
>> *Cc:* Chaals McCathie Nevile ; public-webapps WG <
>> public-webapps@w3.org>
>> *Subject:* Re: [Web Components] proposing a f2f...
>>
>>
>>
>> I am available on all of those days. Will also be happy to help with
>> logistics.
>>
>>
>>
>> :DG<
>>
>
>

Re: [Web Components] proposing a f2f...

[Dimitri Glazkov]

I am available on all of those days. Will also be happy to help with
logistics.

:DG<

Re: TPAC Topic: Using ES2015 Modules in HTML

[Dimitri Glazkov]

Also keenly interested in moving this forward.

:DG<

On Fri, Oct 16, 2015 at 2:45 AM, Anne van Kesteren  wrote:

> On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa  wrote:
> > Can we discuss how we can integrate ES2015 modules into HTML on Tuesday,
> > October 27th at TPAC?
>
> Pretty sure Tuesday has been reserved for service workers discussion.
>
>
> --
> https://annevankesteren.nl/
>
>

Shadow DOM Styling Meeting on September 18, 2015

[Dimitri Glazkov]

Folks,

Now that the Shadow DOM v1 implementations had started in a few browsers,
we need a quick get-together to iron out implementation specifics around
Shadow DOM styling and reconcile any remaining shifts (if any) in CSS
Scoping spec due to Shadow DOM v1.

To do this, we're going to meet on September 18, 2015 (that's next Friday)
and work together for a couple of hours. Think of this is as a working
session, rather than a full-blown day-long W3C meeting.

The details are here:
https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting

Apologies for the short notice.

:DG<

Re: Components F2F

[Dimitri Glazkov]

Hi folks!

I just updated the meeting wiki [1] with the meeting location information.
tl;dr: it's the same room that we had in April.

[1]: https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting

:DG<


On Thu, Jul 2, 2015 at 6:01 AM,  wrote:

> Google had offered to host the meeting, and I believe they are on it.
>
> Obviously, offers to share the hosting effort are welcome in general. I
> haven't checked but agree that based on last time 22 might be squeezing it.
>
> cheers
>
> 02.07.2015, 09:11, "Anne van Kesteren" :
> > On Thu, Jul 2, 2015 at 8:56 AM, Ryosuke Niwa  wrote:
> >>  Is Google hosting this meeting as well? Alternatively, would other
> browser vendors (e.g. Mozilla) willing to host it this time?
> >
> > If we decide quickly it seems I can reserve a room at Mozilla for 18
> > people in SF, maybe 22 in MTV. Not sure that's big enough judging from
> > last meeting, but I don't have the details.
> >
> >>  I'm supposed to write up a document that summaries what we've agreed
> thus far. I've been busy with other stuff lately but will try to post it
> before the meeting.
> >
> > Excellent!
> >
> > --
> > https://annevankesteren.nl/
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com
>
>

Re: Custom Elements: is=""

[Dimitri Glazkov]

Folks,

I agree with Anne that we've been having a somewhat circular re-discovery
of the pros/cons here. I believe that the best way to address this is to
capture all of these points in one doc -- this would be a just a little
extra work for the current participants, but super awesome for the future
folk.

For example, Domenic started such a doc for another custom elements
contentious bit:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.
Please help break the cycle of re-discovery :)

:DG<

Writing spec algorithms in ES6?

[Dimitri Glazkov]

Folks,

Many specs nowadays opt for a more imperative method of expressing
normative requirements, and using algorithms. For example, both HTML and
DOM spec do the "run following steps" list that looks a lot like
pseudocode, and the Web components specs use their own flavor of
prose-pseudo-code.

I wonder if it would be good the pseudo-code would actually be ES6, with
comments where needed?

I noticed that the CSS Color Module Level 4 actually does this, and it
seems pretty nice:
http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor

WDYT?

:DG<

Re: Custom Elements: is=""

[Dimitri Glazkov]

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren  wrote:

>
> > - v1 sets the stage for people to develop habits and expectations about
> how
> > custom elements work. New features tend to be slowly adopted, by both
> > browser vendors and (partly as a consequence) developers, so even if we
> do
> > come up with something for v2, it will be even longer before it becomes
> > mainstream (and as I mentioned earlier we will still be stuck with code
> > written to v1 for much longer again).
>
> I don't see how it will be longer. is="" is not getting acceptance
> as-is. So all this would result in is not getting custom elements
> across browsers until v2 is done.
>

I sort of assumes that the reason for this discussion is to get everyone on
the same page regarding type extension and hope to arrive at better
acceptance.

Arguing that something isn't getting acceptance when the purpose of
discussion is attempting to gain the said acceptance seems a bit circular.

Other than that, please do continue this conversation! :)

:DG<

Re: [components] Isolated Imports and Foreign Custom Elements

[Dimitri Glazkov]

On Sun, May 17, 2015 at 1:54 AM, Maciej Stachowiak  wrote:

>
> (Replying to slightly old thread.)
>
> >
> > Another thing that might be nice is that if these elements are that
> > much isolated, perhaps we can consider allowing them to be renamed
> > them as well, similar to what module systems allow you to do.
>
> An earlier version of my proposal had support for arbitrary renaming at
> import time. However, Ryosuke convinced me that the syntax was confusing,
> and that importing with a different prefix would always be sufficient to
> resolve namespace collisions. That’s what the proposed prefix attribute is
> for. Thus, you can import "abc-button" as "xyz-button" but arbitrary other
> renames are not supported. This relies on the requirement that custom
> element names must contain a hyphen, and the convention that the bit before
> the hyphen is often treated as a namespace prefix. If there are good use
> cases for arbitrary renames, it’s probably not too hard to support them.
>

(replying to a now even more older thread)

FWIW, I like both of the approaches and would like to figure out a way to
move forward with these. I personally slightly prefer the isolated imports
approach a bit better, because some of the sugar in it (like
prefix-renaming) is actually something the non-isolated imports might use
as well.

:DG<

Re: [webcomponents] How about let's go with slots?

[Dimitri Glazkov]

On Thu, May 21, 2015 at 10:22 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

> This works for me too.
>
> And I like the proposed new bikeshed-ed names Anne suggests below.
>

SG. Started a proposal stub here:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md

:DG<


>
> -Original Message-
> From: Anne van Kesteren [mailto:ann...@annevk.nl]
> Sent: Wednesday, May 20, 2015 9:10 PM
> To: Dimitri Glazkov
> Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Leithead; Maciej
> Stachowiak; Arron Eicholz; public-webapps
> Subject: Re: [webcomponents] How about let's go with slots?
>
> On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov 
> wrote:
> > Given that all vendors agreed that "C" can wait until v2, we could
> > just focus on concretizing the "slots" proposal and then put a lid on
> > Shadow DOM v1.
> >
> > What do you think, folks?
>
> This probably works for Mozilla. It would be good to see the proposed
> processing model and its implications for an eventual imperative API.
> It's somewhat troubling we don't agree on synchronous vs
> when-layout-or-event-dispatch-happens.
>
> Also, I suggest we bikeshed the markup in the direction of
> slot=some-slot-name and  rather than
> content-slot=some-slot-name and .
>
>
> --
> https://annevankesteren.nl/
>

Re: [webcomponents] How about let's go with slots?

[Dimitri Glazkov]

On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola  wrote:
>
> I think this model you cite Polymer using is different from what HTML
> normally does, which is why it was confusing to me. In HTML the "insertion
> point tags" (e.g.  or  or ) act as dumb containers.
> This was reinforced by the examples in the proposal, which use  content-slot=""> with the div being a clear dumb container. You cannot
> replace them with your own choice of container and have things still work.
>

Not sure what you mean by "Polymer model". When we have custom elements,
the assumption of dumb containers simply goes out of the window.

:DG<

Re: [webcomponents] How about let's go with slots?

[Dimitri Glazkov]

On Mon, May 18, 2015 at 8:18 PM, Hayato Ito  wrote:
>
> Thank you! I'm afraid that we don't have enough discussion about the pros
> and cons between "select nodes using a selector" and "select nodes by a
> fixed id using attribute".
>

BTW, here's one bit of research I'd done:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md

:DG<

Re: [webcomponents] How about let's go with slots?

[Dimitri Glazkov]

On Mon, May 18, 2015 at 6:48 PM, Hayato Ito  wrote:

> My preference in v1:
>
> 1. select (strongly preferred). okay to rename it if we have a better
> name. e.g.  ==>  
> 2. select + content-slot
> 3. content-slot
>
> I was assuming that "content-slot" is one of required parts in the
> "Multiple Templates" proposal and "Imperative APIs".
> Both, "Multiple Templates" and "Imperative APIs" are deferred to v2. There
> is still no convincing proposal about how these are interacted in the
> future.
>

Those were never conjoined that much. Slots and multiple templates are part
of the same proposal, but they are largely independent pieces. As for slots
being a prerequisite for imperative APIs, I only remember it being
mentioned in the sense that any flavor of declarative API should be
implementable by the imperative API.


>
> I'd like to see a concrete proposal which explains all together in v2. For
> v1, I don't see any strong reason to replace the current select.
>

Is the situation where no other vendors are willing to implement the
current select not a strong reason?


> I am not fan of bedding something which is unclear.
>
> Could someone summarize the pros and cons of content-slot, compared to
> select?
> For me, cons are much bigger than pros in v1. I don't want to miss
> anything.
>

That's a good request. I'll work on the comparison, including Domenic's
request to outline the constant-timeliness.

:DG<

Re: [webcomponents] How about let's go with slots?

[Dimitri Glazkov]

On Fri, May 15, 2015 at 4:58 PM, Scott Miles  wrote:

> Polymer really wants Shadow DOM natively, and we think the `slot` proposal
> can work, so maybe let's avoid blocking on design of an imperative API
> (which we still should make in the long run).
>
> As our entire stack is built on Web Components, the Polymer team is highly
> motivated to assist browser implementers come to agreement on a Shadow DOM
> specification. Specifically, as authors of the `webcomponents-js`
> polyfills, and more than one Shadow DOM shim, we are keenly aware of how
> difficult Shadow DOM is to simulate without true native support.
>
> I believe we are in general agreement with the implementers that an
> imperative API, especially one that cleanly explains platform behavior, is
> an ideal end point for Shadow DOM distribution. However, as has been
> discussed at length, it’s likely that a proper imperative API is blocked on
> other still-to-mature technologies. For this reason, we would like for the
> working group to focus on writing the spec for the declarative `slot`
> proposal [1]. We're happy to participate in the process.
>
> [1]:
> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points
>

It sounds like we are no longer in disagreement on the "F. Slots Proposal"
item from the April 2015 Meeting (
https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting), so we don't
need to block it on the "C. The imperative distribution API" item.

Given that all vendors agreed that "C" can wait until v2, we could just
focus on concretizing the "slots" proposal and then put a lid on Shadow DOM
v1.

What do you think, folks?

:DG<

Re: [webcomponents] How about let's go with slots?

[Dimitri Glazkov]

On Fri, May 15, 2015 at 5:45 PM, Scott Miles  wrote:

> >> How does it work for redistribution
>
> We've done some investigation and think it can work.
>

Note that distributions work just fine with slots. The only thing that
doesn't is partial redistributions, and we haven't been able to find a
scenario that's a blocker:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md

Please, if you can think of one, let's look at it.

:DG<

Re: Shadow DOM: state of the distribution API

[Dimitri Glazkov]

I did a quick experiment around distribution timing:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Distribution-Timing-Experiment.md.
Hope you find it helpful.

:DG<

Re: Custom Elements: is=""

[Dimitri Glazkov]

It might be good to document these on the wiki? Would be lost otherwise.

:DG<

On Wed, May 6, 2015 at 11:53 AM, Elliott Sprehn 
wrote:

> Removing this breaks several use cases of which there's no alternative
> currently:
>
>
> https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-action.html
>
> https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-button.html
>
> where you want to hook into the focus, tab navigation, and action behavior
> in the browser. For example links unfocus in some browsers after unclicking
> them. We also don't have a facility to be focusable but not have a tab
> index currently.
>
>
> On Wed, May 6, 2015 at 9:59 AM, Alice Boxhall  wrote:
>
>>
>>
>> On Wed, May 6, 2015 at 8:33 AM, Anne van Kesteren 
>> wrote:
>>
>>> On Wed, May 6, 2015 at 4:46 PM, Léonie Watson 
>>> wrote:
>>> > My understanding is that sub-classing would give us the accessibility
>>> inheritance we were hoping is= would provide. Apologies if I've missed it
>>> somewhere obvious, but is there any information/detail about the proposed
>>> sub-classing feature available anywhere?
>>>
>>> It should fall out of figuring out HTML as Custom Elements. Apart from
>>> styling which I think we can solve independently to some extent that's
>>> the big elephant in the room.
>>>
>>
>> As I see it there are two problems which is= could conceivably solve,
>> which seem to be being conflated:
>> - providing access to capabilities which so far only native elements have
>> (roles not captured by ARIA, forms behaviour, etc)
>> - allowing re-use of the bundled complete set of behaviours captured in
>> each element in the platform (what is focusable, what keyboard interactions
>> work, what happens on mobile vs. desktop, what semantic values are exposed
>> - essentially everything required in the HTML specs for that particular
>> element)
>>
>> A solution to the first problem I agree should fall out of the HTML as
>> custom elements effort.
>>
>> The second is the one I'm more concerned about falling off the radar:
>> when using a native , you can be reasonably certain that it will
>> adhere to the HTML spec in behaviour; when using an , you only
>> have the reputation of the custom element vendor to give you any sort of
>> guarantee about behaviour, and it could regress at any time.
>>
>> I definitely acknowledge is= may not be the ideal solution to the latter
>> problem - it definitely has some holes in it, especially when you start
>> adding author shadow roots to things - but I think it does have potential.
>> I'd really like to be convinced that we either have a reasonable
>> alternative solution, or that it's not worth worrying about.
>>
>
>

[webcomponents]: Minutae -- moved proposals from wiki to /proposals

[Dimitri Glazkov]

Folks,

To alleviate the limitations of the github wiki (can't submit PRs easily,
etc.), we are moving to a slightly different, more streamlined (awesomer!)
model: the /proposal directory:

https://github.com/w3c/webcomponents/blob/gh-pages/proposals/

It's basically the same as the wiki, but now you can contribute with the
traditional fork/pull model.

:DG<

Re: Custom Elements: Upgrade et al

[Dimitri Glazkov]

On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola  wrote:

> Can you explain how you envision cloning to work a bit more? Somehow there
> will be instances of these elements which are not created by their
> constructors?
>
>
Also, how is it in any way similar to  how  or  work? I am
pretty sure both of those are constructed during cloning.

:DG<

Re: Custom Elements: insert/remove callbacks

[Dimitri Glazkov]

On Wed, May 6, 2015 at 6:45 AM, Anne van Kesteren  wrote:

> Open issues are kept track of here:
>
>   https://wiki.whatwg.org/wiki/Custom_Elements
>
> This has come up before, but it came up again at the Extensible Web
> Summit so raising hopefully for the last time.
>
> The DOM has insert/remove primitives for nodes. Custom Elements uses
> "insertion into a document" and "removal from a document" which are
> quite a bit different and higher level. Why should we have different
> primitives here?
>

This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866.

The way I remember it, the argument went like this: the most common use
case for this callback is to react to element becoming part of the main
document (the rough approximation of a nebulous concept "am I useful on the
screen?"), and making these callbacks be invoked in other cases may just be
noise for devs.

:DG<

Re: Shadow DOM: state of the distribution API

[Dimitri Glazkov]

On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren  wrote:

> It seems we have three contenders for the distribution API.
>
> 1) Synchronous, no flattening of . A host element's shadow
> tree has a set of slots each exposed as a single  element to
> the outside. Host elements nested inside that shadow tree can only
> reuse slots from the outermost host element.
>
> 2) Synchronous, flattening of . Any host element nested
> inside a shadow tree can get anything that is being distributed.
> (Distributed  elements are unwrapped and not distributed
> as-is.)
>
> 3) Lazy. A distinct global (similar to the isolated Shadow DOM story)
> is responsible for distribution so it cannot observe when distribution
> actually happens.
>
> The argument for 1 is that there are no (good?) use cases for 2 and
> that descendants can be distributed, not just children. The argument
> for 2 is that it can be used to implement  and
>  without much difficulty. The argument for 3 is that
> distribution is a layout concept (despite also impacting non-UI events
> and DOM APIs).
>
> (1/2 also require something akin "nanotask" mutation observers.)
>
> As I said elsewhere it's not clear to me we should couple DOM and
> layout. The composed tree is distinct from the render tree. It's also
> not clear to me what 3 would look like. No concrete proposal has been
> made. What is clear to me given the experience with service workers is
> that introducing a new global environment is not simple and would
> likely set us back another couple of years.
>
> That leaves 1/2 and although Ryosuke and Tab have taken sides, neither
> has really backed up their story. I tried to explore 1 in
> https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0474.html
> but that did not get much traction. So... trying again.
>


To complement this email, here's the in-depth (and work-in-progress)
discussion of this:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md

Re: Shadow DOM Imperative API proposal #1 vs

[Dimitri Glazkov]

Thanks Wilson and Anne!

One interesting thing I noticed is that the algo relies on
candidate.distributedNodes already being correctly populated by the nesting
shadow tree. Does that mean that we'd need to ensure the correct order of
invoking distribution among the nesting trees? Or maybe mutation observers
already help you do that?

:DG<

On Fri, May 1, 2015 at 8:15 AM, Anne van Kesteren  wrote:

> Wilson Page attempted to implement  (with microtask
> observers as a timing solution for the time being) to see whether that
> proposal was workable:
>
>   https://gist.github.com/wilsonpage/d5520bd8d22327633e33
>
> Compared to how  is implemented in #2 this looks
> rather jarring and we're not even sure whether it's correct.
>
> If someone could confirm whether it's correct or provide a complete
> solution I'd like to add it to the overall proposal page so that the
> proposals can be more easily compared:
>
>
> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Imperative-API-for-Node-Distribution-in-Shadow-DOM.md
>
> We should also provide a  implementation for the various
> solutions to see whether they can meet that proposal. Though I think
> as  was originally proposed the solution with #1 would
> get equally complex due to having to do recursive unwrapping of
>  elements in script. And the solution with #2 would be
> equally simple.
>
> (I updated that page quite significantly by the way to clarify #1 a
> bit, make #2 more readable, and also added some alternative solutions
> to the timing problem.)
>
>
> --
> https://annevankesteren.nl/
>
>

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Dimitri Glazkov]

On Wed, Apr 29, 2015 at 5:59 PM, Ryosuke Niwa  wrote:

>
> > On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov 
> wrote:
> >
> > On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa  wrote:
> >> I've updated the gist to reflect the discussion so far:
> >> https://gist.github.com/rniwa/2f14588926e1a11c65d3
> >>
> >> Please leave a comment if I missed anything.
> >
> > Thank you for doing this. There are a couple of unescaped tags in
> https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency,
> I think?
> >
> > Any chance you could move it to the Web Components wiki? That way, we
> could all collaborate.
>
> Sure, what's the preferred work flow? Fork and push a PR?
>

Actually, we might need to figure this out first. Github Wiki is not
super-friendly to fork/push-PR model. But I do like your idea. Maybe just
an .md page in a repo?


>
> - R. Niwa.
>
>

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Dimitri Glazkov]

On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa  wrote:

> I've updated the gist to reflect the discussion so far:
> https://gist.github.com/rniwa/2f14588926e1a11c65d3
>
> Please leave a comment if I missed anything.
>

Thank you for doing this. There are a couple of unescaped tags in
https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency,
I think?

Any chance you could move it to the Web Components wiki? That way, we could
all collaborate.

:DG<

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

[Dimitri Glazkov]

On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa  wrote:

> One thing that worries me about the `distribute` callback approach (a.k.a.
> Anne's approach) is that it bakes distribution algorithm into the platform
> without us having thoroughly studied how subclassing will be done upfront.
>
> Mozilla tried to solve this problem with XBS, and they seem to think what
> they have isn't really great. Google has spent multiple years working on
> this problem but they come around to say their solution, multiple
> generations of shadow DOM, may not be as great as they thought it would be.
> Given that, I'm quite terrified of making the same mistake in spec'ing how
> distribution works and later regretting it.
>

At least the way I understand it, multiple shadow roots per element and
distributions are largely orthogonal bits of machinery that solve largely
orthogonal problems.

:DG<

Re: Nice version Re: Minutes of Shadow DOM meeting

[Dimitri Glazkov]

Will do.

:DG<

On Sun, Apr 26, 2015 at 2:08 AM,  wrote:

> Attached here is a clean version, which will be archived.
>
> Note that there was a lot of sidechat in IRC it is unclear how much of
> that everyone in the room was aware of. I hope the minutes are a pretty
> accurate record now, but if people feel otherwise I hope they say so.
>
> I'll link this version to the meeting page in the wiki:
> https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting
>
> Dimitri, can you please forward the link to attendees who are not members
> of webapps?
>
> cheers
>
> 26.04.2015, 00:14, "cha...@yandex-team.ru" :
> > 25.04.2015, 14:45, "Bjoern Hoehrmann" :
> >>  * cha...@yandex-team.ru wrote:
> >>>  We'll post a summary - there is most of one at
> >>>
> https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0
> >>  Perhaps a document in some kind of open format would be a better medium
> >>  than some proprietary application with unclear stability policies that
> >>  does not work in my browser.
> >>>  The minutes (thanks to Taylor Savage fora  great scribing job) are at
> >>>  http://www.w3.org/2015/04/25-webapps-minutes.html
> >>  That contains just a few lines. Looks like the decade-old UTC day
> change
> >>  bug is still plaguing the minutes generation tool.
> >
> > Sigh. Well, alternatively it is the decades-old scribe forgetting to do
> the thing right… I'll put together the minutes and repost them shortly.
> >
> > I've attached a rough version but I'll need to do some more cleaning
> because I made a mess halfway through. The content is there and legible at
> least…
> >>  --
> >>  Björn Höhrmann · mailto:bjo...@hoehrmann.de ·
> http://bjoern.hoehrmann.de
> >>  D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 ·
> http://www.bjoernsworld.de
> >
> > cheers
> >
> > --
> > Charles McCathie Nevile - web standards - CTO Office, Yandex
> > cha...@yandex-team.ru - - - Find more at http://yandex.com
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: [components] Apple's consolidated feedback on Web Components

[Dimitri Glazkov]

Thank you for writing this up, Maciej. Looking forward to the F2F.

:DG<

On Wed, Apr 22, 2015 at 11:19 PM, Maciej Stachowiak  wrote:

>
> > On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak  wrote:
> >
> >
> > Hi everyone,
> >
> > In preparation for Fridays’ face-to-face, a number of us at Apple
> (including me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor
>
> I forgot to mention that Gavin Barraclough also contributed to this
> discussion. We also incorporated past feedback from others on the team.
>
>  - Maciej
>

Re: Proposal for changes to manage Shadow DOM content distribution

[Dimitri Glazkov]

FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
proposal.

It reduces the implementation complexity: all of the selector-checking
logic in
http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
is replaced with (what effectively is) a map lookup.

While some loss of flexibility is a cost, I think it's worth considering
this trade-off, especially if it is a sticking point for implementers who
are looking to reduce the overall cost of Shadow DOM implementation.

In fact, if we reach cross-vendor agreement and decide to go with the
slot-based approach, we probably should avoid adding extra sugar around
element names and attribute values as slot indicators, and instead double
down on developing a good imperative API that overcomes the loss of
flexibility.

:DG<

Re: Proposal for changes to manage Shadow DOM content distribution

[Dimitri Glazkov]

On Tue, Apr 21, 2015 at 9:43 PM, Daniel Freedman  wrote:

> Hi Ryosuke,
>
> I want to start by thanking you, Ted, and Jan for taking the time to make
> this proposal.
>
> I read through the proposal, and had a quick question about how
> redistribution should work with this slot concept.
> I created a quick  example that would take two date
> inputs (start date and end date) and distribute them through the example
> , but I found myself stuck.
> I can't name the two date inputs with the same slot or they will end up in
> only one of the  content elements, but 
> only takes inputs with slot "inputElement".
>
> How should this work?
>
> I drafted a quick gist to illustrate this:
> https://gist.github.com/azakus/676590eb4d5b07b94428
>

Maybe there could be something like a simple routing scheme for these cases?
https://gist.github.com/dglazkov/7d6acd4c205a58054a7c

:DG<

Re: [webcomponents]: Let's reach consensus on Shadow DOM

[Dimitri Glazkov]

On Sun, Feb 8, 2015 at 10:17 AM, Ryosuke Niwa  wrote:

> One more thing. I think it's nice to have a new comprehensive list of use
> cases participants have come up over the years on the same document since
> the wiki page is quite outdated.
>

I spent the last couple of weeks working on this. Here's what I have so far:

https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples
https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Refresher

I am still updating the examples. Any help in finishing this is appreciated.

:DG<

Re: Mozilla and the Shadow DOM

[Dimitri Glazkov]

Updated https://www.w3.org/Bugs/Public/show_bug.cgi?id=28446 with the
latest, to keep the history in bug.

:DG<

On Thu, Apr 16, 2015 at 7:52 AM, Dimitri Glazkov 
wrote:

> On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page  wrote:
>
>> This is an interesting approach that didn't occur to me! Similar to
>> Anne's concerns, this would require you to have more knowledge of the
>> internals of the super-class component. If you own both components then
>> this is fine.
>>
>
> Yes, the main problem here is the degree of separation between creator and
> consumer of the base component. The higher the degree, the less inclined
> the creator will be to expose innards of the shadow tree to the consumer.
>
> Multiple shadow roots solves the same problem as shadow trees (provides a
> composition contract), but along the inheritance chain.
>
> For example, multiple shadow roots make sense:
>
> * if you are a maker of UI library that's strongly rooted in inheritance
> and intend to for your base components to be used directly;
>
> * if you are hoping to inherit from components with closed shadow trees.
>
>
>> Also if this means we can remove a complex piece from the spec to help
>> reach consensus, great! :)
>>
>
> Whatever it takes.
>
> :DG<
>

Re: Mozilla and the Shadow DOM

[Dimitri Glazkov]

On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page  wrote:

> This is an interesting approach that didn't occur to me! Similar to Anne's
> concerns, this would require you to have more knowledge of the internals of
> the super-class component. If you own both components then this is fine.
>

Yes, the main problem here is the degree of separation between creator and
consumer of the base component. The higher the degree, the less inclined
the creator will be to expose innards of the shadow tree to the consumer.

Multiple shadow roots solves the same problem as shadow trees (provides a
composition contract), but along the inheritance chain.

For example, multiple shadow roots make sense:

* if you are a maker of UI library that's strongly rooted in inheritance
and intend to for your base components to be used directly;

* if you are hoping to inherit from components with closed shadow trees.


> Also if this means we can remove a complex piece from the spec to help
> reach consensus, great! :)
>

Whatever it takes.

:DG<

Re: [Imports] Considering imperative HTML imports?

[Dimitri Glazkov]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319

On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn 
wrote:

>
>
> On Wed, Apr 15, 2015 at 9: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.
>>
>
> We did consider this, I think there's still a proposal for an imperative
> document.import(url) => Promise API. The major advantage of the declarative
> approach is that the browser can fetch the entire import tree and even
> start tokenizing on a background thread without ever running any script.
>
> - E
>

Re: [Imports] Considering imperative HTML imports?

[Dimitri Glazkov]

Imports bug tree:
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20683&hide_resolved=1

On Thu, Apr 16, 2015 at 7:27 AM, Dimitri Glazkov 
wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319
>
> On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn 
> wrote:
>
>>
>>
>> On Wed, Apr 15, 2015 at 9: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.
>>>
>>
>> We did consider this, I think there's still a proposal for an imperative
>> document.import(url) => Promise API. The major advantage of the declarative
>> approach is that the browser can fetch the entire import tree and even
>> start tokenizing on a background thread without ever running any script.
>>
>> - E
>>
>
>

Re: Mozilla and the Shadow DOM

[Dimitri Glazkov]

On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren  wrote:

> On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov 
> wrote:
> > Thanks for the feedback! While the iron is hot I went ahead and
> > created/updated bugs in the tracker.
>
> A problem I have with this approach is that with Shadow DOM (and maybe
> Web Components in general) there's a lot of open bugs. Of those bugs
> it's not at all clear which the editors plan on addressing. Which
> makes it harder to plan for us.
>

This seems like something we can fix by bug triage. Both Hayato and I
periodically garden the bug tree (
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978&hide_resolved=1
).

The process works as follows:

1) The bug tree is broken by categories of work, with each category being a
meta bug (title prefixed with [meta]).

2) As new bugs are filed, they end up at the bottom of the tree

3) Periodically, we triage these bugs at the bottom and mark them as
blocking meta bugs.

4) Those meta bugs that no longer have blocking bugs are closed as fixed.

To make it easier for you to track Mozilla-related bugs, we need to create
a meta bug, like I did a while back for custom elements:
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20684&hide_resolved=0

Here's the new bug for Shadow DOM:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28491. I started added
things I know as blocking to it, please feel free to add those that I
missed.


>
> Also, a point that I forgot to make in my initial email is that
> Polymer makes it rather hard for us to ship any part of Web Components
> without all the other parts (and in the manner that Chrome implemented
> the features):
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1107662


I am sure Polymer folks will be super-happy to help. Let's continue
discussion on your bug.

:DG<

Re: Are web components *seriously* not namespaced?

[Dimitri Glazkov]

On Thu, Apr 9, 2015 at 9:04 AM, Rahly  wrote:

>
>
> On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle  wrote:
>
>> Tab,
>>
>> I spend the vast majority of my time anymore in RDF-land, where
>> namespaces actually make sense (I'm not going to argue on the XML use of
>> namespaces - they are, agreed, ugly and complex). I know that when I've
>> been at Balisage or any of the W3 confabs, the issue of namespaces ex-XML
>> has been hotly debated, and many, many potential solutions proposed.
>> Regardless, I do think that there is a very real need for namespaces in the
>> general sense, if only as a way of being able to assert conceptual domain
>> scope and to avoid collisions ( is the prototypical example here).
>>
>>
> Although they are ugly, they did do one thing correct, and that was to
> place the burden of namespace resolution and use on the final document
> creator.  I think that namespace/prefix should be defined by the web page
> designer and not the component library designer. This allows end users of
> the component the ability to resolve the conflicts, instead of filing a bug
> report and a component designer has to fix all namespace resolutions.
>
> As a component designer, I'd like the ability to develop with a single
>  instead of .
>

This is a problem I would like solve as well.


>
> I definitely prefer the prefix solution as it "looks" cleaner in the end
> product.  document.registerElement should warn/error if the end product tag
> is already in use, that's for sure.
>

It already does:
http://w3c.github.io/webcomponents/spec/custom/#dfn-definition-construction-algorithm

:DG<

Re: Mozilla and the Shadow DOM

[Dimitri Glazkov]

Thanks for the feedback! While the iron is hot I went ahead and
created/updated bugs in the tracker.

On Tue, Apr 7, 2015 at 11:17 PM, Anne van Kesteren  wrote:

> We have done some brainstorming internally around what we want out of
> Shadow DOM and components in general, between those working on Gaia
> (Firefox OS applications) and those working on Platform (Gecko). We
> hope to be able to discuss this at the meeting later this month and
> also at the Extensible Web Summit that precedes it. And of course on
> this list, happy to answer any questions.
>
> For custom elements https://wiki.whatwg.org/wiki/Custom_Elements is
> still an accurate summary of where we are at. For shadow DOM I wrote
> this summary:
>
> * Layout containment. We hope that evolving
> http://dev.w3.org/csswg/css-containment/ further could allow for some
> interesting optimizations and hopefully something akin to element
> queries or a resize event down the road. (This is basically a feature
> of  that components lack.)
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28440

>
> * Declarative shadow DOM. Mostly for performance it would be nice if
> the composed tree could be serialized and cached. That way first
> render only requires HTML and CSS with JavaScript kicking in at the
> end. We reasoned it might not be too hard to add something like
>  given our experience with . The only difference
> would be that  itself would also not be appended to the
> tree and that the DocumentFragment nee ShadowRoot is associated with
> "its parent".
>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28441


>
> * Isolated shadow DOM. This is the idea of having a "DOM worker" so
> that instead of ten s with ten globals you can have one global
> with ten somethings. This would give applications more parallelization
> opportunities and would hopefully enable a large number of companies
> from moving away of the practice of using cross-origin 

Re: [Shadow] URL-based shadows?

[Dimitri Glazkov]

On Wed, Mar 18, 2015 at 2:35 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  I think ‘Worker’ threw me off at first J.
>
>
>
> My original use case was to make the current model of loading components
> more “local”, as AFAIK, these components can only presently be loaded by
> code you trust, e.g., via some script library somewhere imported via a
> 

Re: [Shadow] URL-based shadows?

[Dimitri Glazkov]

On Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren  wrote:

> On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov 
> wrote:
> >
> https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1
>
> That seems really cool. I'm not sure worker is the right terminology
> since at the moment worker sort of implies there's no node tree
> available due to the complexity that would give. But an isolated
> global for a set of reusable components that are mixed into the
> document seems roughly in line with what we have with  et al
> today.
>

Agree.

:DG<

Re: [Shadow] URL-based shadows?

[Dimitri Glazkov]

On Fri, Mar 13, 2015 at 12:57 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Ah, thanks Dimitri.
>
>
>  After reading that, I'm also receiving it rather "coolly". It's a very
> interesting idea, but as it relates to web components, its errs strongly on
> the side of isolation to the degree that the component would be more
> isolated than an iframe today; at least in same-domain, non-sandboxed
> iframes, you can directly access the document via the contentWindow
> property if desired; furthermore styling of this DOMWorker thing which is
> running in a separate thread would be complex to say the least from an
> implementation standpoint. I definitely want to stay firmly on the same
> thread for Shadow DOMs [image: 😊].
>
Threads don't necessarily come into play here. The proposal doesn't mention
it, but Elliott specifically wanted to stay on the same thread. This is not
technically a "worker", more like an "isolator". But anyway -- it does
sound different from your idea, which I captured into
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28211.

:DG<

Re: [Shadow] URL-based shadows?

[Dimitri Glazkov]

... found it:
https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1

:DG<

On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov 
wrote:

> Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly
> received (can't remember the details).
>
> :DG<
>
> On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead <
> travis.leith...@microsoft.com> wrote:
>
>>  Dimitri et al.,
>>
>>
>>
>>Has the idea of loading/parsing a Shadow DOM directly from a URL been
>> discussed already? (e.g., a sort-of “micro-import” or an import that parses
>> its document directly into the ShadowRoot container?) I’m curious to know
>> if there’s some obvious flaw that I’m missing.
>>
>>
>>
>> element.createShadowRoot(“path to my component”);
>>
>>
>>
>>   This is an idea around building components from the “inside out”, and
>> using the URL as the basis for script-level access control to the Shadow
>> contents.
>>
>>
>>
>>   Thoughts?
>>
>
>

Re: [Shadow] URL-based shadows?

[Dimitri Glazkov]

Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly
received (can't remember the details).

:DG<

On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Dimitri et al.,
>
>
>
>Has the idea of loading/parsing a Shadow DOM directly from a URL been
> discussed already? (e.g., a sort-of “micro-import” or an import that parses
> its document directly into the ShadowRoot container?) I’m curious to know
> if there’s some obvious flaw that I’m missing.
>
>
>
> element.createShadowRoot(“path to my component”);
>
>
>
>   This is an idea around building components from the “inside out”, and
> using the URL as the basis for script-level access control to the Shadow
> contents.
>
>
>
>   Thoughts?
>

Re: template namespace attribute proposal

[Dimitri Glazkov]

On Thu, Mar 12, 2015 at 4:13 AM, Robin Berjon  wrote:

> On 12/03/2015 11:07 , Anne van Kesteren wrote:
>
>> On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh  wrote:
>>
>>> What are your thoughts on this idea?
>>>
>>
>> I think it would be more natural (HTML-parser-wise) if we
>> special-cased SVG elements, similar to how e.g. table elements are
>> special-cased today. A lot of -parsing logic is set up so
>> that things work without special effort.
>>
>
Love this idea.


>
> Or even go the extra mile and just slurp all SVG elements into the HTML
> namespace. There are a few name clashes, but we ought to be able to iron
> those out.
>
> And ditto MathML.


Not sure what the timeline would look like for this work. I guess this
would depend on whether there's existing content counting on namespaces
being different?

:DG<

Re: Extending HTMLCanvasElement in Custom Element issue

[Dimitri Glazkov]

There could be more details there, but here's the summary of the problem:
https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements

:DG<

On Wed, Mar 11, 2015 at 7:17 AM, Халитов Кирилл  wrote:

> Hello. My issue is described there
> 
>  .
>
> But I did not solve its fully. Why can not I create a pure custom canvas
> element with a full functionality like in my example code?
>
> --
> *С уважением*
> *Кирилл Халитов*
>

Re: Custom elements: synchronous constructors and cloning

[Dimitri Glazkov]

Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28092 to add more data
to the informative content around the normative statement that makes this
happen.

On Tue, Feb 24, 2015 at 7:39 AM, Dimitri Glazkov 
wrote:

>
>
> On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren 
> wrote:
>
>> On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov 
>> wrote:
>> > Wait, what do you mean by "that is what custom elements provide for
>> today.."
>> >
>> > The entire pattern of template-stamping depends on the fact that custom
>> > elements aren't broken when cloning/importing.
>>
>> There's no hook for cloning, is there? Or is the created callback
>> supposed to be invoked? (If it is, that's missing from the
>> specification.)
>>
>
> There's no special hook for cloning, no. But the created callback is
> definitely invoked when cloning. The spec simply says that it's queued
> whenever an element is created.
>
>
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>
>

Re: Custom elements: synchronous constructors and cloning

[Dimitri Glazkov]

On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren  wrote:

> On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov 
> wrote:
> > Wait, what do you mean by "that is what custom elements provide for
> today.."
> >
> > The entire pattern of template-stamping depends on the fact that custom
> > elements aren't broken when cloning/importing.
>
> There's no hook for cloning, is there? Or is the created callback
> supposed to be invoked? (If it is, that's missing from the
> specification.)
>

There's no special hook for cloning, no. But the created callback is
definitely invoked when cloning. The spec simply says that it's queued
whenever an element is created.


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

Re: Custom elements: synchronous constructors and cloning

[Dimitri Glazkov]

On Tue, Feb 24, 2015 at 12:14 AM, Anne van Kesteren 
wrote:

> On Mon, Feb 23, 2015 at 11:58 PM, Ryosuke Niwa  wrote:
> > In that regard, perhaps what we need another option (although 4 might be
> a developer friendly superset of this):
> > 5) Don't do anything.  Custom elements will be broken upon cloning if
> there are internal states other than attributes just like cloning a canvas
> element will lose its context.
>
> Putting state in a known place as with 3 also seems okay. Although if
> anything throws there you would have to catch and ignore it. But yes,
> perhaps 5 is a good start as that is what custom elements provide for
> today...
>

Wait, what do you mean by "that is what custom elements provide for today.."

The entire pattern of template-stamping depends on the fact that custom
elements aren't broken when cloning/importing.

:DG<

Re: Web Components F2F in April 2015

[Dimitri Glazkov]

On Fri, Feb 20, 2015 at 1:08 PM, Dimitri Glazkov 
wrote:

>
>> Working on it now. Will report back shortly.
>>
>
> The location at the Google Mountain View campus. Will update as soon as I
> have the room/building info.
>

Location: Google Mountain View Campus.

Sorry grammar bad.


>
>
>>
>> :DG<
>>
>
>

Re: Web Components F2F in April 2015

[Dimitri Glazkov]

On Thu, Feb 19, 2015 at 8:03 AM, Dimitri Glazkov 
wrote:

> On Thu, Feb 19, 2015 at 5:28 AM, Arthur Barstow 
> wrote:
>
>>
>> When will you be able to confirm the location? Regardless, I think we
>> should consider the meeting as confirmed.
>>
>
> Working on it now. Will report back shortly.
>

The location at the Google Mountain View campus. Will update as soon as I
have the room/building info.


>
> :DG<
>

Re: Web Components F2F in April 2015

[Dimitri Glazkov]

On Thu, Feb 19, 2015 at 5:28 AM, Arthur Barstow 
wrote:

>
> When will you be able to confirm the location? Regardless, I think we
> should consider the meeting as confirmed.
>

Working on it now. Will report back shortly.

:DG<

Web Components F2F in April 2015

[Dimitri Glazkov]

Folks,

Following Art's suggestion [1], I propose a Web Components-specific F2F
with with the primary goal of reaching consensus on the Shadow DOM
contentious bits [2].

When: Friday, April 24, 2015
Where: Google San Francisco or Mountain View (to be confirmed)
What: a one-day meeting

Tentative agenda:

1) Go over the contentious bits, discuss pros/cons
2) Brainstorm/present ideas on changes to current spec
3) Decide on changes to current spec
4) If we have time left, review custom elements bits [3]

I stubbed out the basics in
https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting
:DG<

[1]:
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0407.html
[2]: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits
[3]: https://wiki.whatwg.org/wiki/Custom_Elements

Re: Showing from HTML import

[Dimitri Glazkov]

Can you file a spec bug?

https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=&blocked=20683&short_desc=%5Bimports%5D%3A%20&product=WebAppsWG&import=import%20Model

:DG<

On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen  wrote:

> I filed crbug.com/458799 for Chrome recently since showing a 
> defined in a HTML import did not work as I thought it should. I can't
> compare to any other browsers since right now AFAIK Chrome is the only
> browser shipping both HTML imports and . There seemed to be some
> confusion from the browser developers over what the spec says ought to
> happen.
>
> It sounds like the current spec says that showing a dialog marks the "node
> document" of the dialog as being blocked. I would imagine a  in a
> HTML import has the invisible HTML import document as the node document of
> the . Therefore it never appears on-screen (in the main document)
> when you call showModal(), but still throws if you try to open it twice.
>
> It can be worked around with JS: the dialog element can be detached from
> its current document and appended to the main document, and then
> showModal() works as expected.
>
> I think the spec may need to be altered. I think it's an obvious use case
> that a web component may want to show a dialog, and naturally that dialog
> will be defined in one of the web component's HTML imports. As it stands
> though the dialog will never appear unless the JS hack is used. I can also
> foresee that a large codebase making use of lots of dialogs ends up with
> loads of dialogs appended to the main document, instead of leaving them in
> the components where they came from.
>
> Not sure how this would be specified though - perhaps the dialog should be
> attached to the main document in showModal(), then re-inserted where it
> came from in close()? Sounds like a bit of a hack in itself...
>
> Ashley
>
>

Re: Base Template (Was Re: Minimum viable custom elements)

[Dimitri Glazkov]

Ryosuke, Jan,

It might be useful for you two folks to work through Jan's Shadow DOM
composition/inheritance insight (use cases?) together and see how they
could be resolved without having multiple shadow roots per element. I would
love to take advantage of all the work you both have done thinking about
this problem separately.

:DG<

On Thu, Feb 12, 2015 at 9:46 AM, Ryosuke Niwa  wrote:

>
> On Feb 12, 2015, at 4:50 AM, Steve Faulkner 
> wrote:
>
>
> On 12 February 2015 at 10:58, Anne van Kesteren  wrote:
>
>> which is a very different problem from what you want to solve, no?
>
>
> The problem I think needs solving for minimum viable custom elements is
> reducing reliance on bolt-on accessibility. From the example provided
> http://janmiksovsky.github.io/base-template/ it appears that in this
> instance it does achieve that end.
>
> I don't know whether this will extend to other UI controls or whether it
> is a practical solution, which is why I brought it to the list for
> discussion.
>
>
> Again, this proposal or subclassing problem is nothing to do with custom
> elements but all do with shadow DOM.
>
> Ironically, I've pointed out the exact same problem explained in this page
> last April and proposed to change the way shadow DOM works to solve it:
> https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html
>
> - R. Niwa
>
>

[webcomponents]: Let's reach consensus on Shadow DOM

[Dimitri Glazkov]

Folks,

I wrote a long email, replying to each point where I agreed/differed with
Ryosuke, and then deleted it, realizing I wasn't being productive.

So instead, I decided to start summarizing the contentious bits of the
current Shadow DOM spec:
https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits

We are at a point where there are hard choices to be made. But with the 4+
history of the adventure, it's nearly impossible for everyone to recall or
catch up on discussions and relevant insight.

With this doc, I am hoping we'll get on the same page and make way.

:DG<

Re: Are web components *seriously* not namespaced?

[Dimitri Glazkov]

On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow 
wrote:
>
>
> Dimitri - if someone wants to provide input (f.ex. requirements ) for this
> API, should they add them to the above bug (or do you recommend else)?
>

Yep. That's a good place.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 10:11 AM, Dimitri Glazkov 
wrote:

> ... Hanging "but"?! Oh lordy. Oooh, let me turn this into a contemplative
> sidebar opportunity.
>
> Shadow DOM and Web Components seem to have what I call the "Unicorn
> Syndrome". There's a set of specs that works, proven by at least one
> browser implementation and the use in the wild. It's got warts
> (compromises) and some of those warts are quite ugly. Those warts weren't
> there in the beginning -- they are a result of a hard, multi-year slog of
> trying to make a complete system that doesn't fall over in edge cases, and
> compromising. A lot.
>
> So there's a temptation to make new proposals (unicorns) that are
> wart-free, but incomplete or not well-thought-out. Don't get me wrong. I
> like new ideas. What I would like to avoid is judging a workhorse against a
> unicorn. Armed with your imagination, unicorn will always win.
>

I shouldn't have sent this. It was uncool of me. My bad. Please accept my
apologies.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 2:53 PM, Ryosuke Niwa  wrote:

>
> On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov  wrote:
>
> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay  wrote:
>
>> On 02/05/2015 02:24 AM, Dimitri Glazkov wrote:
>>>
>>> However, I would like to first understand if that is the problem that
>>> the group wants to solve. It is unclear from this conversation.
>>>
>>
>> Yes. The marketing speech for shadow DOM has changed over time from "do
>> everything possible, make things awesome" to "explain the platform"
>> to the current "enable easier composition".
>> So it is not very clear to me what even the authors of the spec always
>> want, this said with all the kindness :)
>>
>
> I appreciate the affirmation, the kindness, and the smiley. Though since
> this is public forum, I have to add a few things:
>
> 1) The original "Component Model" (as it was known back then) charter from
> 2011 clearly includes easier composition as one of its main goals, as
> illustrated by https://wiki.whatwg.org/wiki/Component_Model and
> https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we
> definitively solved at huge chunk of these problems. For example, Polymer
> is a clear illustration that
> https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager  is
> nearly 100% solved and there are now examples in the wild of most of these
> use cases solved with Web Components. There's still lots of work to do, of
> course. But
>
> 2) Refining terminology and the way to describe problem space is a natural
> part of working on solutions for that problem space. Calling it "marketing"
> is just not helpful.
>
>
> I agree his wording was a bit harsh.  But let me try to explain where Olli
> is coming from because I do sympathize with what he's saying here.
>

Let's do it.


> For example, at the WebApps F2F meeting last spring, you mentioned that
> explaining builtin element is a goal of web components.
>

Yep. I would like to emphasize that "explaining the platform" is not a
self-goal. It's a constraint, which helps guiding the thinking about new
primitives and behaviors. Relying on builtin elements to inform discovery
of Shadow DOM was a real thing. I hope you remember me going through that
huge refactoring in WebKit.



> Yet, the web components as spec'ed today doesn't explain any builtin
> elements due to its lack of strong encapsulation.
>

There are two distinct concepts mixed in here:

1) the type 2 encapsulation. There's no barrier for this to happen. There's
broad agreement that we should do it, and even recent work by hayato on
outlining specific places where the "open" and "closed" modes differ. The
research he provided shows that it's a fixed set of changes (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775), enabled by a flag as
we discussed at the spring session.

2) the actual, honest-to-goodness security boundary (isolation) that
builtins enjoy thanks to the C++/JS bindings layer. This is a much more
difficult problem, but something we definitely want to tackle at some point
in the future. Maybe Realms are the answer.


> And insertion points, which is a huge source of complexity, is only needed
> to explain details and summary elements.
>

For builtins, yes. For general composition problem, they are essential.


> The ability to attach multiple generations of shadow DOM to a single host
> element, which is another source of an enormous complexity, is not required
> to explain any builtin HTML elements at all as far as I know.
>

This is true. Multiple roots per element is an extension that enables
reasoning about subclassing in terms of DOM. You are definitely overstating
the complexity. It's not that difficult -- just a list of pointers instead
of one pointer.


>  So it appears that there is a precedence in adding features to Web
> components that are not needed for builtin elements but desirable for other
> use cases.
>

This is where my intro sentence is useful. Explaining builtins is not a
self-goal. We browser developers don't _need_ to explain the platform for
any other purpose other than extracting useful primitives for web
developers.


>  Yet, you (Google representatives as the collective) in the past argued
> that you didn't want to add support for imperative API for selecting
> distributed elements because that can't explain builtin elements even
> though we've listed a few use cases that can't be adequately addressed
> unless we have an imperative API.
>

The distribution discussion terminated early because the people who were
interested in solving this problem withdrew from it. I even o

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 10:52 AM, Marc Fawzi  wrote:

> Following this thread because there is real need for what is being
> discussed.
>
> However, until that need is satisfied, here is what we're thinking to
> achieve style encapsulation, using current-world technologies, and I'm
> hoping you would point out any problems you see with doing it this way.
>
> 1. We build components that render DOM elements, e.g. via React or
> something like that.
> 2. We write or generate a stylesheet per component and name the .css file
> same as component name, and convert it from CSS to a named subtree (e.g.
> CSS.componentName.styles: { ... }) in a global JSON structure (build time)
> 3. The components consume style rules from that data structure at run time
> and convert them to inline styles on the elements they render. The inline
> styles are injected and rewritten based on component state. We use CSS3
> transitions rather than style tweening.
> 4. For @keyframes, we create a style element in the document and namespace
> them like component-name-keyframe-name.
>
> Not using this list as a Stackoverflow substitute. My purpose here is to
> show one way of achieving style isolation without Web Components, Shadow
> DOM, etc, and figure out whether the web needs anything more than we
> already have.
>

This sounds pretty neat and similar to thing that Christopher Chedeau
presented in his "CSS in your JS" talk (http://vimeo.com/116209150). I
can't think of a better example of the Web Platform (and CSS in particular)
completely failing the developer. I admire your and Christopher's
desperation and persistence to stay successful within the constraints of
the existing system.

FWIW, with Shadow DOM, you simply don't need any of these build steps or
factorings. Just write your styles in your component.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 9:41 AM, Dimitri Glazkov  wrote:

>
>
> On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay  wrote:
>
>> On 02/05/2015 02:24 AM, Dimitri Glazkov wrote:
>>
>>
>>> However, I would like to first understand if that is the problem that
>>> the group wants to solve. It is unclear from this conversation.
>>>
>>
>> Yes. The marketing speech for shadow DOM has changed over time from "do
>> everything possible, make things awesome" to "explain the platform"
>> to the current "enable easier composition".
>> So it is not very clear to me what even the authors of the spec always
>> want, this said with all the kindness :)
>>
>
> I appreciate the affirmation, the kindness, and the smiley. Though since
> this is public forum, I have to add a few things:
>
> 1) The original "Component Model" (as it was known back then) charter from
> 2011 clearly includes easier composition as one of its main goals, as
> illustrated by https://wiki.whatwg.org/wiki/Component_Model and
> https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we
> definitively solved at huge chunk of these problems. For example, Polymer
> is a clear illustration that
> https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager  is
> nearly 100% solved and there are now examples in the wild of most of these
> use cases solved with Web Components. There's still lots of work to do, of
> course. But
>

... Hanging "but"?! Oh lordy. Oooh, let me turn this into a contemplative
sidebar opportunity.

Shadow DOM and Web Components seem to have what I call the "Unicorn
Syndrome". There's a set of specs that works, proven by at least one
browser implementation and the use in the wild. It's got warts
(compromises) and some of those warts are quite ugly. Those warts weren't
there in the beginning -- they are a result of a hard, multi-year slog of
trying to make a complete system that doesn't fall over in edge cases, and
compromising. A lot.

So there's a temptation to make new proposals (unicorns) that are
wart-free, but incomplete or not well-thought-out. Don't get me wrong. I
like new ideas. What I would like to avoid is judging a workhorse against a
unicorn. Armed with your imagination, unicorn will always win.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay  wrote:

> On 02/05/2015 02:24 AM, Dimitri Glazkov wrote:
>
>
>> However, I would like to first understand if that is the problem that the
>> group wants to solve. It is unclear from this conversation.
>>
>
> Yes. The marketing speech for shadow DOM has changed over time from "do
> everything possible, make things awesome" to "explain the platform"
> to the current "enable easier composition".
> So it is not very clear to me what even the authors of the spec always
> want, this said with all the kindness :)
>

I appreciate the affirmation, the kindness, and the smiley. Though since
this is public forum, I have to add a few things:

1) The original "Component Model" (as it was known back then) charter from
2011 clearly includes easier composition as one of its main goals, as
illustrated by https://wiki.whatwg.org/wiki/Component_Model and
https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we
definitively solved at huge chunk of these problems. For example, Polymer
is a clear illustration that
https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager  is
nearly 100% solved and there are now examples in the wild of most of these
use cases solved with Web Components. There's still lots of work to do, of
course. But

2) Refining terminology and the way to describe problem space is a natural
part of working on solutions for that problem space. Calling it "marketing"
is just not helpful.


> Personally I think composition piece itself doesn't legitimate the
> complexity of shadow DOM.
>

I accept this as a personal opinion, not a fact.


> Though, it is not clear what composition means to different people. Is the
> need for insertion points part of
> composition? In my mind it might not be. It is part of the stronger
> encapsulation where
> one has hidden DOM between a parent node and a child node.
>

For example, this is clearly where you haven't thought through the problem
space. Sure, you don't need insertion points for simple hierarchical
composition. But as soon as you get to the Layout Manager use case (not to
belabor a 4-year old doc), you run into the need for insertion points. Take
https://www.polymer-project.org/docs/elements/layout-elements.html, as
examples in the wild.


> Is event retargeting part of composition?


This one is something I am eager to explore. Event retargeting came
directly from trying to address the goal of explaining the native controls,
and it might be something we could separate from the pure composition
primitive.


> That said, I think we should aim for something stronger than just enabling
> easier composition.
> The end goal could go as far as let pages to implement their own form
> controls. And to make that
> all less error prone for the users of such components requires
> encapsulation.
>

Again, I accept this as a personal opinion, but I would like to push back
on this. Stronger encapsulation comes with its own host of problems for
developers. Before taking this as a fact, I encourage first exploring the
trade-offs and trying to prototype/build/tool/test components. I've done
it. I've learned the lesson.


> So, start with composition but keep the requirements for the proper
> encapsulation in mind by not introducing
> syntaxes or APIs which might make implementing encapsulation harder.
>

Agreed.

>
>
> Are there cases where encapsulation and composition contradicts? I guess
> that depends on the definition of those both.


Yes.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa  wrote:

>
> > On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr.  wrote:
> >
> > On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay  wrote:
> >> Why do we need shadow DOM (or something similar) at all if we expose it
> >> easily to the outside world.
> >> One could even now just require that elements in "components" in a web
> page
> >> have class="component", and then
> >> .component could be used as >>>. Sure, it would require :not(.component)
> >> usage too.
> >> And from DOM APIs side one could easily implement filtering for the
> contents
> >> of "components" using small script libraries.
> >
> > Aa;erlhas;dlgpasodifapsldikjf;
> >
> > I keep hearing this kind of sentiment pop up, and I'm like, have you
> > ever done serious webdev?  I know a lot of browser devs haven't, and I
> > don't know if you have or not, but this is the sort of thing that is
> > plain as day if you have.
>
> That sounds rather demeaning and insulting [1].  public-webapps, or a
> mailing list of any W3C working group, isn't an appropriate forum to rant.
>

+1.


> However, the use case we're talking here is multiple teams working on a
> single website potentially stepping on each other's toes; implying the
> enormous size of the entity working on the website.  I have a hard time
> imagining that any organization of that scale to not have a sever-side or
> pre-deployment build step for the website at which point they can add a
> preprocessing step to modify all selectors.  e.g. even a website I worked
> on with only four other people had a build step before we could deploy it.
>

The need to modify selectors on the server side is highly symptomatic of
the composition problem remaining unsolved. This processing is not due to
the burning desire of the developers to munge their selectors, but rather
due to their inability to reason about the composition of styles, and
having to rely on out-of-band composition.

For all the criticism Shadow DOM receives, it is currently the only
solution that solves this problem. As I mentioned before, I am very open to
using Shadow DOM to extract a simpler primitive that is more focused on
solving the style composition problem in-band.

However, I would like to first understand if that is the problem that the
group wants to solve. It is unclear from this conversation.

:DG<

Re: Are web components *seriously* not namespaced?

[Dimitri Glazkov]

The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578

The registry API hasn't been spec'd yet.

:DG<

On Wed, Feb 4, 2015 at 1:31 PM, Glen  wrote:

> I know I'm rather late to the party, but I've been doing a lot of reading
> lately about web components and related technologies, and the one thing
> that confounds me is the fact that web components appear not to have any
> "real" namespacing.
>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>
> Regards,
>
> Glen.
>
>

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

Not trying to barge in, just sprinkling data...

On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell  wrote:

>
>
> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay  wrote:
>
>> On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
>>
>>> Brian recently posted what looks like an excellent framing of the
>>> composition problem:
>>>
>>> https://briankardell.wordpress.com/2015/01/14/
>>> friendly-fire-the-fog-of-dom/
>>>
>>> This is the problem we solved with Shadow DOM and the problem I would
>>> like to see solved with the primitive being discussed on this thread.
>>>
>>>
>>
>> random comments about that blog post.
>
>
>
>> [snip]
>> We need to be able to select mount nodes explicitly, and perhaps
>> explicitly say that all such nodes should be selected.
>> So, maybe, deep(mountName) and deep(*)
>>
>> Is there a reason you couldn't do that with normal CSS techniques, no
> additional combinator?  something like /mount/[id=foo] ?
>

That's ::shadow in the scoping spec:
http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement


>
>
> [snip]
>
>> "It still needs to be possible from the hosting page to say “Yes, I mean
>> all buttons should be blue”"
>> I disagree with that. It can very well be possible that some component
>> really must control the colors itself. Say, it uses
>> buttons to indicate if traffic light is red or green. Making both those
>> buttons suddenly blue would break the whole concept of the
>> component.
>>
>
This is still possible, and works in a predictable way with today's styling
machinery. Use inline styles on the button that you want to be green/red
inside of the scope, and no /deep/ or /mount/ or >>> will be able to affect
it: http://jsbin.com/juyeziwaqo/1/edit?html,css,js,output ... unless the
war progressed to the stage where "!important" is used as hammer.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

Brian recently posted what looks like an excellent framing of the
composition problem:

https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/

This is the problem we solved with Shadow DOM and the problem I would like
to see solved with the primitive being discussed on this thread.

:DG<

Re: Toward more productive f2f meetings [Was:Re: Feedback needed for April 2015 face-to-face location by *January 27, 2015*]

[Dimitri Glazkov]

On Mon, Feb 2, 2015 at 6:03 AM, Arthur Barstow 
wrote:
>
> Instead of a centralized broadly scoped f2f meeting, perhaps it would be
> more useful to have topic-specific meetings located at or near the critical
> mass of active contributors, and only have such a meeting if the editors
> and key contributors commit to participate. For example, a Web Components
> meeting (as was done in 2013), an Editing and Selection meeting, etc.
>

I like this idea.

:DG<

Re: Minimum viable custom elements

[Dimitri Glazkov]

One additional point, unrelated to accessibility: "is" also enables
piggybacking to special parser behavior of existing elements. For example,
I can extend  or .

Here are some examples:

http://jsbin.com/xuheb/3/edit?html,output

https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/

:DG<

On Thu, Jan 29, 2015 at 7:33 AM, Bruce Lawson  wrote:

> On 29 January 2015 at 14:54, Steve Faulkner 
> wrote:
> > I think being able to extend existing elements has potential value to
> > developers far beyond accessibility (it just so happens that
> accessibility
> > is helped a lot by re-use of existing HTML features.)
>
> I agree with everything Steve has said about accessibility. Extending
> existing elements also gives us progressive enhancement potential.
>
> Try https://rawgit.com/alice/web-components-demos/master/index.html in
> Safari or IE. The second column isn't functional because it's using
> brand new custom elements. The first column loses the web componenty
> sparkles but remains functional because it extends existing HTML
> elements.
>
> There's a similar story with Opera Mini, which is used by at least
> 250m people (and another potential 100m transitioning on Microsoft
> feature phones) because of its proxy architecture.
>
> Like Steve, I've no particularly affection (or enmity) towards the
>  syntax. But I'd like to know,
> if it's dropped, how progressive enhancement can be achieved so we
> don't lock out users of browsers that don't have web components
> capabilities, JavaScript disabled or proxy browsers. If there is a
> concrete plan, please point me to it. If there isn't, it's
> irresponsible to drop a method that we can see working in the example
> above with nothing else to replace it.
>
> I also have a niggling worry that this may affect the uptake of web
> components. When I led a dev team for a large UK legal site, there's
> absolutely no way we could have used a technology that was
> non-functional in older/proxy browsers.
>
> bruce
>
>

Re: Minimum viable custom elements

[Dimitri Glazkov]

On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa  wrote:

>
> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov  wrote:
> On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa  wrote:
>>
>> When an author imports a ES6 module, we don't create a fake object which
>> gets resolved later by rewriting its prototype.
>>
>
> These are two completely different things, right? In one situation, you
> are dealing with HTML Parser and blocking thereof. In another, there's no
> such concern.
>
>
> How are they different at all?  I have a hard time understanding how
> differentiating DOM objects from other ES6 builtins will fit your stated
> design goal to explain the Web platform.
>

... because DOM objects are not the ES6 built-ins?


>
> If we are implementing the HTML parser as well as the entire DOM in
> JavaScript, why wouldn't we just use constructors to create DOM nodes?
>

I feel like we're walking in circles at this point.

It's pretty safe to say that we're years away from being able to implement
HTML parser and the entire DOM in JS. Even then, time-shifted callbacks (or
similar write-barrier-style abstraction) still make sense. The JS that
implements the parser or DOM may desire to run the custom elements JS code
only in certain places (see Mutation Events -> Mutation Observers).


>
> If your concern is that it would block the rendering of the page,
>

No, it is not.


>
> If your concern is that authors must wait until other scripts that define
> custom elements are loaded even after DOMContentLoaded is fired,
>

No, it is not.

Let me repeat and extend what I said earlier in the thread. In the world
where we have non-blocking scripts and HTML parser that yields, upgrades
are a performance/ergonomics primitive.

With upgrades, the non-blocking script could execute during a yield,
register elements, and keep on going. The chunk of html that was parsed
previously will upgrade, and the chunk that hasn't yet parsed will start
queueing callbacks. The developer does not need to care about the timing of
registration. From their perspective, the order of callbacks will be the
same.

Without upgrades, you as a developer are highly incentivized to reduce the
amount of html after your non-blocking script, because you need to wait
until the doc parsed completely until you can sensibly run the script.

This is what's happening today, as evidenced by most frameworks moving away
from using HTML Parser as anything but script bootstrapping device, and
relying on imperative tree construction. And in that world, upgrades are
useless -- but so is HTML. And eventually, DOM.

:DG<

Re: Minimum viable custom elements

[Dimitri Glazkov]

On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa  wrote:

>
> > On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov 
> wrote:
> >
> > FWIW, I think that element upgrade is sort of fundamental to the
> usefulness of custom elements. In a world where most scripts are
> non-blocking (that's hopefully the modern world we should aim for), I'll
> effectively expect to walk the tree anyway.
>
> Allowing loading scripts asynchronously, including ones that define custom
> elements, is one thing; automatically resolving script dependencies for
> custom elements is another.


What are the "script dependencies for custom elements" here?


> When an author imports a ES6 module, we don't create a fake object which
> gets resolved later by rewriting its prototype.
>

These are two completely different things, right? In one situation, you are
dealing with HTML Parser and blocking thereof. In another, there's no such
concern.

:DG<

Re: Minimum viable custom elements

[Dimitri Glazkov]

On Thu, Jan 15, 2015 at 5:29 PM, Ryosuke Niwa  wrote:

>
> The only reason you need to have the two-stage setup is because you want
> to support asynchronous upgrading of elements.  As we have repeatedly
> stated in the past, we don't support a design that involves upgrading
> elements after the element construction if it meant that we can't use ES6
> constructor in the non-upgrade case.  We'll submit a formal objection if
> necessary.
>

Could you summarize the reasons behind such a strong position?

:DG<

Re: Custom element design with ES6 classes and Element constructors

[Dimitri Glazkov]

>
>
> > We're already doing some crude namespacing with *Callback. I'd expect
> that as soon as the first iteration of Custom Elements is out, people will
> copy the *Callback style in user code.
>
> This is a powerful point that I definitely agree with. I would not be
> terribly surprised to find some library on the web already that asks you to
> create custom elements but encourages you supply a few more
> library-specific hooks with -Callback suffixes.
>
>
That makes sense. I am okay with that.

:DG<

Re: Minimum viable custom elements

[Dimitri Glazkov]

On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren  wrote:
>
>
> * I think we could iterate towards a v2 that has an aspect of
> upgrading but perhaps works a bit differently from the current setup.
> E.g. a way to include an entire subtree of custom elements with a
> fallback mechanism of sorts. Or perhaps something inspired by
> JavaScript modules.
>

Why is "Not having identity at creation-time is currently a mismatch with
the rest of the platform" a problem? Why does it all have to be consistent
across the board? Are there any other platform objects that are created by
HTML parser or a similar device?


> * Upgrading can be added, but moving from Brain transplants to a more
> normal working constructor would be impossible after the fact.
>

Why is this a problem? Is this for design purity?

:DG<

Re: Custom element design with ES6 classes and Element constructors

[Dimitri Glazkov]

On Thu, Jan 15, 2015 at 2:37 AM, Anne van Kesteren  wrote:

> On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz  wrote:
> > Can you say more about why same-identity upgrading is critical to the
> design
> > (as opposed to dom-mutation upgrading)? I asked up-thread but didn't get
> any
> > takers.
>
> I tried to summarize the various upgrade scenarios here (as well as
> the other issues):
>
>   https://wiki.whatwg.org/wiki/CustomElements


Thanks for starting this page! One thing that seems missing is Steve
Faulkner's concern about removing "is".

:DG<

Re: Minimum viable custom elements

[Dimitri Glazkov]

No argument that callbacks are also a useful new addition.

:DG<

Re: Custom element design with ES6 classes and Element constructors

[Dimitri Glazkov]

>
>
> I'm sympathetic to this but I think it is fine that DOM continues to
> define new string based property names. Anytime we add a new property
> to an existing class we run into this issue and I don't think we want
> to give up on the superior usability of string based property names.
>

I agree, FWIW.

:DG<

Re: Minimum viable custom elements

[Dimitri Glazkov]

FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively expect to
walk the tree anyway.

And if I walk the tree anyway, what's the point of custom elements in the
first place? One of the key features (at least, to me) of custom elements
was being able to harness the HTML Parser to instantiate your object tree.
If that's not going happen consistently, then I am not sure custom elements
are worth the trouble. IOW, if you're walking the tree, just do the work of
callbacks as you encounter dash-separated elements.

:DG<

Re: Minimum viable custom elements

[Dimitri Glazkov]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579

On Wed, Jan 14, 2015 at 11:11 AM, Domenic Denicola  wrote:

> From: Erik Arvidsson [mailto:a...@google.com]
>
> > I'm not sure how that is speced but in Blink we have an extended IDL
> attribute called CustomElementCallbacks which means that we are going to
> call the pending callbacks after the method/setter.
>
> If I recall this is how Anne and others were saying that it *should* be
> specced, but the spec itself is a bit more vague, leaving it as
>
> > When transitioning back from the user agent code to script, pop the
> element queue from the processing stack and invoke callbacks in that queue.
>

Re: Custom element design with ES6 classes and Element constructors

[Dimitri Glazkov]

On Wed, Jan 14, 2015 at 9:39 AM, Boris Zbarsky  wrote:

> On 1/14/15 11:52 AM, Dimitri Glazkov wrote:
>
>> Would like to point out that we're not talking about a general case
>> here. The actual proto munging in custom elements spec is minimized to a
>> pretty small set.
>>
>
> Pretty small set of which?  Possible mutations, elements, something else.


Had trouble with words here :) Something about minimizing the
impact/effect, and the next paragraph was meant to explain that.


>
>
>  Also, the current design doesn't change the prototype chain arbitrarily:
>>
>
> This is the most important point.  It's possible engines could optimize
> such proto chain insertions better than they do now.  Some feedback from
> engine implementors on how feasible that is would be good to have.
>
>  the effect is limited to inserting a sub-chain into the existing chain.
>>
>
> Is it, though?
>

Yes. I can certainly abuse the machinery to step outside of this rule, but
then I won't be creating useful/well-behaving custom elements.


> I don't see that this is always true, though I would be fine with the
> cases in which it's not true falling off performance cliffs: those would
> only happen when proto chains get munged after element registration.
>
> If we ignore those cases, it's possible JS engines could optimize this
> better than they do now.  JS engine implementor feedback would be pretty
> useful on this matter.



BTW, I agree that we should not hold on to the legacy of wrapper+object
design. That point was probably more about the second point -- the internal
slots of the base types are set at the time of instantiating.

:DG<

Re: Custom element design with ES6 classes and Element constructors

[Dimitri Glazkov]

On Mon, Jan 12, 2015 at 9:11 PM, Boris Zbarsky  wrote:

> On 1/12/15 12:20 PM, Tab Atkins Jr. wrote:
>
>> Proto munging isn't even that big of a deal.
>>
>
> That really depends.
>
> For example, dynamically changing __proto__ on something somewhat
> permanently deoptimizes that object in at least some JS engines. Whether
> that's a big deal depends on what you do with your objects.


This is true.

Would like to point out that we're not talking about a general case here.
The actual proto munging in custom elements spec is minimized to a pretty
small set.

Given that most engines use lazily created wrappers, the actual setting of
the prototype won't even need to happen unless the developer first accessed
the element, thus creating a wrapper.

Also, the current design doesn't change the prototype chain arbitrarily:
the effect is limited to inserting a sub-chain into the existing chain.
IOW:  A-E + B-C-D-E  --> A-B-C-D-E. Thus, the base type is always the same.

:DG<

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

Here's an attempt from 2012. This approach doesn't work (the "trivial
plumbing" mentioned in the doc is actually highly non-trivial), but maybe
it will give some insights to find the right a proper solution:

https://docs.google.com/document/d/1x2CBgvlXOtCde-Ui-A7K63X1v1rPPuIcN2tCZcipBzk/edit?usp=sharing

:DG<

On Fri, Jan 9, 2015 at 7:54 AM, Dimitri Glazkov  wrote:

> For the record, I am a huge fan of exploring this. I tried a couple of
> times, but was unable to extract this primitive from Shadow DOM in a clean
> way. I talked with Tab late last year about restarting this effort, so this
> is timely.
>
> :DG<
>
> On Fri, Jan 9, 2015 at 7:49 AM, Anne van Kesteren 
> wrote:
>
>> On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell  wrote:
>> > For clarity, are you suggesting you'd control the matching boundary via
>> CSS
>> > somehow or you'd need an indicator in the tree?  A new
>> element/attribute or
>> > something like a "fragment root" (sort of a shadowroot-lite)?
>>
>> I wasn't suggesting anything since I'm not sure what the best way
>> would be. It has to be some flag that eventually ends up on an element
>> so when you do selector matching you know what subtrees to ignore. If
>> you set that flag through a CSS property you'd get circular
>> dependencies, but perhaps that can be avoided somehow. Setting it
>> through an element or attribute would violate separation of style and
>> markup.
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>>
>

Re: Shadow tree style isolation primitive

[Dimitri Glazkov]

For the record, I am a huge fan of exploring this. I tried a couple of
times, but was unable to extract this primitive from Shadow DOM in a clean
way. I talked with Tab late last year about restarting this effort, so this
is timely.

:DG<

On Fri, Jan 9, 2015 at 7:49 AM, Anne van Kesteren  wrote:

> On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell  wrote:
> > For clarity, are you suggesting you'd control the matching boundary via
> CSS
> > somehow or you'd need an indicator in the tree?  A new element/attribute
> or
> > something like a "fragment root" (sort of a shadowroot-lite)?
>
> I wasn't suggesting anything since I'm not sure what the best way
> would be. It has to be some flag that eventually ends up on an element
> so when you do selector matching you know what subtrees to ignore. If
> you set that flag through a CSS property you'd get circular
> dependencies, but perhaps that can be avoided somehow. Setting it
> through an element or attribute would violate separation of style and
> markup.
>
>
> --
> https://annevankesteren.nl/
>
>

Re: Custom element lifecycle callbacks

[Dimitri Glazkov]

On Thu, Jan 8, 2015 at 7:56 AM, Anne van Kesteren  wrote:

> 1) Can we use symbols to identify these instead? That gives us a
> guarantee they won't be used for other things and makes it somewhat
> safer to put them where they are located now.
>

cc'ing a few folks I heard expressing an opinion on this.


>
> 2) For normal elements we act directly when they are cloned or
> adopted. How much interest is there in delaying what happens for
> normal elements to align them with custom elements?
>

I am interested in at least trying. I think Domenic is too.

:DG<

Re: ES6 and upgrading custom elements

[Dimitri Glazkov]

On Tue, Jan 6, 2015 at 10:59 AM, Anne van Kesteren  wrote:

> On Tue, Jan 6, 2015 at 7:54 PM, Dimitri Glazkov 
> wrote:
> > Right, that's why to create a valid custom element that subclasses
> > HTMLInputElement, you should use type extensions. With type extensions,
> the
> > HTMLInputElement is what's instantiated.
>
> But without using type extensions this will work (provided we sort out
> the other bits):
>
>   class X extends HTMLInputElement { ... }
>   document.registerElement("x-input", X)
>   var xinput = new X
>
> It seems sad to require type extensions (and therefore requiring a
> more complicated version of document.registerElement) for translating
> this into markup.
>

You shouldn't need anything more complicated:

class X extends HTMLInputElements { .. }
X.extends = "input" // additional line.
document.register("x-input", X)
var xinput = new X


>
> Having actual subclassing in JavaScript, but not for elements unless
> you use some sort of hack seems sad.
>

The type extensions is a hack, I agree :(

:DG<

Re: ES6 and upgrading custom elements

[Dimitri Glazkov]

On Tue, Jan 6, 2015 at 10:38 AM, Anne van Kesteren  wrote:

> On Tue, Jan 6, 2015 at 7:06 PM, Dimitri Glazkov 
> wrote:
> > Yes to the first question. I wasn't planning on doing anything different
> > there.
>
> It seems simple prototype munging but not actually changing identity
> will fail for all but the basic cases of subclassing. E.g. if I
> subclass an HTMLInputElement I would expect it to have an internal
> [[value]] slot of sorts, but since the element created is a plain
> HTMLElement whose prototype is munged that will not be the case.
>

Right, that's why to create a valid custom element that subclasses
HTMLInputElement, you should use type extensions. With type extensions, the
HTMLInputElement is what's instantiated.

:DG<

Re: ES6 and upgrading custom elements

[Dimitri Glazkov]

On Tue, Jan 6, 2015 at 9:56 AM, Anne van Kesteren  wrote:

> On Tue, Jan 6, 2015 at 6:13 PM, Dimitri Glazkov 
> wrote:
> > That section needs to be updated, because the ES6 spec had shifted a
> little
> > bit with regard to @@create. Filed
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27769.
>
> Yeah, there's issues in general there, such as ES6 giving up on
> explaining all of DOM :-(
>
>
> > Conceptually, when I wrote it I'd imagined that the constructor will be
> > called only when you explicitly invoke it (new FooElement...). When
> parsing
> > or upgrading, the constructor would not be called. The createdCallback
> will
> > be invoked in either case.
>
> Would you do the prototype munging that is specified in
> "createdCallback" today? (I think it would be more clear if we made
> that prototype munging part of the upgrade algorithm by the way.) How
> else would that work? Pass a reference to the old element and let the
> developer handle it?
>

Yes to the first question. I wasn't planning on doing anything different
there. And yes, I would like to fix the munging clarity as part of
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27437.

:DG<


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

Re: pull request on custom elements spec

[Dimitri Glazkov]

Thanks! Merged.

:DG<

On Tue, Jan 6, 2015 at 1:46 AM, Steve Faulkner 
wrote:

> Hi Dimitri,
>
> made quite a few tweaks to the custom element semantics section after
> feedback.
>
> Appreciate a review of the PR https://github.com/w3c/webcomponents/pull/31
>
> when you get a chance.
> --
>
> Regards
>
> SteveF
>
>

Re: ES6 and upgrading custom elements

[Dimitri Glazkov]

That section needs to be updated, because the ES6 spec had shifted a little
bit with regard to @@create. Filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27769.

Conceptually, when I wrote it I'd imagined that the constructor will be
called only when you explicitly invoke it (new FooElement...). When parsing
or upgrading, the constructor would not be called. The createdCallback will
be invoked in either case.

:DG<


On Tue, Jan 6, 2015 at 7:21 AM, Anne van Kesteren  wrote:

> It's not clear to me from
> https://w3c.github.io/webcomponents/spec/custom/#es6 how the upgrade
> works. From the pre-ES6 setup you can work out through inference that
> upgrading is supposed to mutate the prototype of the element in
> question.
>
> But it seems that mutating the prototype is not sufficient for ES6. We
> want an element created through the constructor, no? (Let's leave
> aside the question for now as to how this subclassing would work,
> that's already discussed elsewhere.)
>
>
> --
> https://annevankesteren.nl/
>
>

Re: [custom-elements] Re: web developer conformance requirements and advice in custom elements spec

[Dimitri Glazkov]

On Sat, Dec 6, 2014 at 7:34 AM, Arthur Barstow 
wrote:

> On 12/6/14 4:21 AM, Steve Faulkner wrote:
>
>> Hi all,
>>
>> looking at the custom elements spec http://w3c.github.io/
>> webcomponents/spec/custom/ i realized it includes no defined
>> requirements or advice for web developers on creation of custom elements
>> that are meaningful and expose useful semantics and behavior.
>>
>> I would like to take a stab at this, what's the best way to contribute?
>> pull requests?
>>
>
> Hi Steve,
>
> Yes, it appears you should submit a PR to [1] and I'm sure Dimitri will
> clarify if he recommends otherwise.
>

Totally. Happy to review/accept patches.


>
> BTW Dimitri - it looks like the ED has some relatively substantive changes
> since the last TR was published (October 2013) [Diff]. As such, it seems
> like the TR should be updated. WDYT?
>

Yes. I was kind of hoping to do the same trick that Hayato used for the
Shadow DOM spec, with the big red warning advising to go to the ED.


>
> -Thanks, AB
>
> [1] https://github.com/w3c/webcomponents
> [Diff] http://services.w3.org/htmldiff?doc1=http%3A%2F%
> 2Fwww.w3.org%2FTR%2F2013%2FWD-custom-elements-20131024%2F&
> doc2=http%3A%2F%2Fw3c.github.io%2Fwebcomponents%2Fspec%2Fcustom%2F
>
>
>

Re: Bringing APIs for experimental hardware/software to the Web

[Dimitri Glazkov]

On Sun, Nov 16, 2014 at 8:30 PM, Robert O'Callahan 
wrote:

> On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov 
> wrote:
>
>> On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan 
>> wrote:
>>
>>> On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov 
>>> wrote:
>>>
>>>> Nevertheless, I am optimistic. I would like to have this discussion and
>>>> hear your ideas.
>>>>
>>>
>>> OK. The following ideas are somewhat half-baked so don't judge me too
>>> harshly :-).
>>>
>>> Rapid deployment of experimental APIs in the browser clashes with our
>>> existing goals. It takes time to negotiate APIs, to create multiple
>>> interoperable implementations, to validate safety, etc. So I conclude we
>>> shouldn't bake them into the browser. Instead we could achieve most of our
>>> goals by enabling third parties to deploy experimental functionality in
>>> browser-independent, device-independent packages that can be used by ---
>>> and if necessary shipped alongside --- Web applications. To the extent we
>>> can do that, we make an end-run around the standardization problem.
>>>
>>
>> This implies that we need to first design/specify an environment
>> (execution/packaging/etc.) for this. Right? This seems like a massive
>> investment of time. Not saying it's a bad idea. Unless you have a piano
>> neatly stashed away in the bushes waiting for me to ask this question :) [
>> http://en.wikipedia.org/wiki/Grigori_Gorin]
>>
>
> This need not be a hard problem, depending on other decisions we make. It
> might be as simple as "load an IFRAME with a well-known URL at some
> vendor's Web site and exchange postMessages with it", or load a script
> directly from the vendor's Web site (which might do the IFRAME/postmessage
> thing under the hood and vend a friendlier API). We may not need to
> standardize anything specific here, although it would be good to have some
> best practices to recommend.
>

Okay. That lines up well with my thinking on the Tubes proposal.


>
>>
>>> For software, this means we need a browser-based execution environment
>>> that can run the code that implements these APIs. I think for C/C++ code,
>>> we're nearly there already. For GPU code the situation is murkier and we
>>> need to solve it (but we already need to).
>>>
>>
>> Agreed. Somewhat tangentially, would like to know your opinion on the
>> bedrock and extensible manifesto thing. It seems that primitive archeology
>> presupposes that C/C++ is ultimately brushed down to nothing.
>>
>
> I don't understand what you're saying here.
>

If you look at https://extensiblewebmanifesto.org/ and project the path
forward with those guidelines in mind, at some point, you will hit the
bedrock -- a set of platform APIs that can no longer be explained in terms
of other, more low-level APIs.

Given that, what is beneath this bedrock? To what degree will we succeed
with JS as a platform host language? Will there remain things like C++
bindings and the exotic objects that they bring along?


>
> Okay. I think I understand this part. Since USB is basically the common
>> bus for new hardware innovation anyway, we could just go down to USB and
>> build up from there.
>>
>> I have a couple of concerns:
>> 1) This means you'll effectively have to implement device drivers twice
>> -- once for host OS, once for Web platform. That seems like doubling the
>> work and lessening the chance of the developer actually going through it.
>>
>
> We ought to be able to provide glue code to ease porting, e.g. by
> emulating libusb or the Android USB interface on top of whatever Web USB
> API we provide.
>

Sounds like there's some prior art in this space:
https://developer.chrome.com/apps/app_usb and
https://wiki.mozilla.org/WebAPI/WebUSB. Interesting bit about caveats:
https://developer.chrome.com/apps/app_usb#caveats

I immediately feel ill-informed to determine whether exposing a USB API
satisfies most developer/vendor needs. Sounds like a bug for me to fix ;)


>
>
>> 2) Instilling a device-independent device driver culture seems like a
>> tough challenge. Two device vendors need to have an incentive to
>> collaborate on a driver that works for both of their nearly identical crazy
>> camera tricks. The slope here is not going to be leaning in our favor.
>>
>
> There seems to be a misunderstanding. In this context, I explicitly
> abandon the goal of having a single driver or API for diverse hardware.
>

Okay. Makes sense.


>
> It might be

Re: Bringing APIs for experimental hardware/software to the Web

[Dimitri Glazkov]

+slightlyoff, because he's probably not listening, but should :)

On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan 
wrote:

> On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov 
> wrote:
>
>> Nevertheless, I am optimistic. I would like to have this discussion and
>> hear your ideas.
>>
>
> OK. The following ideas are somewhat half-baked so don't judge me too
> harshly :-).
>
> Rapid deployment of experimental APIs in the browser clashes with our
> existing goals. It takes time to negotiate APIs, to create multiple
> interoperable implementations, to validate safety, etc. So I conclude we
> shouldn't bake them into the browser. Instead we could achieve most of our
> goals by enabling third parties to deploy experimental functionality in
> browser-independent, device-independent packages that can be used by ---
> and if necessary shipped alongside --- Web applications. To the extent we
> can do that, we make an end-run around the standardization problem.
>

This implies that we need to first design/specify an environment
(execution/packaging/etc.) for this. Right? This seems like a massive
investment of time. Not saying it's a bad idea. Unless you have a piano
neatly stashed away in the bushes waiting for me to ask this question :) [
http://en.wikipedia.org/wiki/Grigori_Gorin]


>
> For software, this means we need a browser-based execution environment
> that can run the code that implements these APIs. I think for C/C++ code,
> we're nearly there already. For GPU code the situation is murkier and we
> need to solve it (but we already need to).
>

Agreed. Somewhat tangentially, would like to know your opinion on the
bedrock and extensible manifesto thing. It seems that primitive archeology
presupposes that C/C++ is ultimately brushed down to nothing.


>
> Hardware is more challenging. I think here it makes sense to have
> low-level Web APIs for I/O, e.g. USB. So, when someone produces a
> sensor/actuator USB gadget with accompanying software, we should be able to
> compile the software for Web use, wrap an API around it that Web apps can
> use, and host it in any browser. This hits most of our goals: as long as
> the package remains available, there's compatibility; it's
> device-independent apart from the dependency on the specific gadget; and it
> works across browsers (though there's only one implementation of that
> specific component).
>

Okay. I think I understand this part. Since USB is basically the common bus
for new hardware innovation anyway, we could just go down to USB and build
up from there.

I have a couple of concerns:
1) This means you'll effectively have to implement device drivers twice --
once for host OS, once for Web platform. That seems like doubling the work
and lessening the chance of the developer actually going through it.
2) Instilling a device-independent device driver culture seems like a tough
challenge. Two device vendors need to have an incentive to collaborate on a
driver that works for both of their nearly identical crazy camera tricks.
The slope here is not going to be leaning in our favor.

It might be good to start enumerating the types of APIs we're interested in.

For example, we could take Apple's HealthKit (
https://developer.apple.com/healthkit/) and Google's Fit (
https://developers.google.com/fit/overview) as some of the things
developers might need, and see how we could deliver them.

One key result I am looking for here is adapting to fit into existing
frameworks like that, rather than building our own. Though rebuilding both
of the things from scratch for the Web platform -- however NIH -- should
still be on the table.


> Safety is a big concern with low-level hardware access. An obvious path
> would be to require some kind of trust decision for apps depending
> (indirectly) on privileged hardware access, but maybe there's a better way.
> For example, when you attach a USB device you're implicitly trusting the
> vendor already. What if the browser could extract a vendor domain name from
> the device (e.g. via a trusted registry) and granted I/O access to that
> device for packages loaded from that domain? A package could claim it
> provides a sanitized API to apps, freeing those apps from the trust
> decision requirement. When, inevitably, something goes wrong, either the
> package is patched or the browser is updated to stop trusting the package.
>

Yeah, if we go down the path of device drivers, bolting origin on to the
driver will probably need to happen very early in the process.

:DG<

Re: Bringing APIs for experimental hardware/software to the Web

[Dimitri Glazkov]

On Tue, Nov 11, 2014 at 3:01 PM, Robert O'Callahan 
wrote:

> On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov 
> wrote:
>
>> Given any capability on a modern computing device and a developer who
>> wants to use it, what is a) the acceptable delay between when this
>> capability becomes available on the web platform vs. first being available
>> on a native platform, and b) the likelihood that this capability will ever
>> be available on the web platform.
>>
>> If we're aiming at "years, not months", and "60-80%", then we're already
>> successful.
>>
>> If we're hoping to hit "weeks, not months" and "100%", we need something
>> like Tubes.
>>
>
> I don't think we should set targets for a) and b) and hit those targets no
> matter what the cost. We need to do the hard work of evaluating tradeoffs
> case by case. I assume everyone agrees that when there are no hard
> tradeoffs to make, of course we'd like to have nice things.
>
> We can have a productive discussion about how to bring APIs for
> experimental hardware and software to the Web faster. Subject changed to
> suit. Here's my problem statement:
>
> We have a set of traditional goals for the Web platform: backward
> compatibility, device independence, multiple interoperable implementations,
> long-term durability, coherence, ease of use, safety, etc. People
> frequently release new hardware and software with new capabilities that
> don't fit into existing Web APIs. Can we expose these capabilities to Web
> developers with very low delay, without violating some of our existing
> goals? If we can't, what tradeoffs are we willing to make?
>
> If this is the discussion you want to have, then I will reveal some ideas
> :-).
>

I think that's a reasonable problem statement. There are two problems with
it:

1) it makes an assumption that everyone on this forum wants very low delay
and all capabilities. I don't know if that is true, though I definitely
want to believe it.

2) it's not as focused as my formulation on actually setting a target for
ourselves, which makes me worried we'll end up in the same loosely
incoherent state we always end up.

Nevertheless, I am optimistic. I would like to have this discussion and
hear your ideas.

:DG<

Re: New approach to activities/intents

[Dimitri Glazkov]

On Tue, Nov 11, 2014 at 12:28 PM, Robert O'Callahan 
wrote:

> I still don't see how exposing an API via MessagePorts is in any way
> better than exposing an API via WebIDL. Can you describe with concrete
> examples how this makes life better for implementors or authors? I've read
> your presentation but I did not see the answer there.
>
> Furthermore I don't see any necessary connection between MessagePorts vs
> WebIDL and the issues around rapidly bringing experimental APIs to the Web.
> Are you claiming that it's quicker and easier to add MesagePort-based APIs
> to browsers than using WebIDL?
>

I would like to state explicitly that as of
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0376.html, I
withdraw the proposal of Tubes as the exact solution to the problem in lieu
of the need to first formulate a decent problem statement -- in the form of
the criteria I proposed.

:DG<

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich 
wrote:

> Dimitri Glazkov wrote:
>
>> Domenic's question still needs addressing separately, but just a quick
>> response here -- the API roc described there is different. Tubes are just
>> like talking to a worker or any MessagePort. There is no extra API surface
>> emerging from getContext-like function call.
>>
>
> Any getContext or postMessage protocol is inherently not
> object-detectable, at least not at the string-keyed level.
>
> In principal, as bz said, the tension between extensions and standards
> motivates supporting extensions, and I share your desire to support
> experimentation so long as it is consensus-oriented. We want to avoid
> overlarge jumps by one proprietor, who both risks failing to bring along
> competitors step by step, and seeming to abuse any market power it may
> possess.
>
> So we want to support extension, extensibility, in ways that don't lead to
> bad game-theoretic and real-world outcomes, e.g. ActiveX PKI in Korea.
> There's no silver bullet or algorithm to do this, but API style matters
> (object detection vs. non-detection; gentle-peoples' agreements about how
> proprietary/particular an API to try).
>
> The JS SIMD work definitely experiences this tension. Do we want a union
> of all (SSE, NEON, AVX2) vector instructions? Intersection may be too
> small, and emulation may be too slow to be worth using. The
> http://github.com/johnmccutchan/ecmascript_simd issues cover this well,
> and show good particularized thinking.
>
> To particularize without object detection is hard.
>
> In any event, IMHO native stacks are not killing the Web, nor are native
> stacks evolving willy-nilly on random and arbitrarily rapid schedules or
> via message-based API settings. Apple and Android are at most annual
> big-release OSes, e.g. I welcome counterexamples.
>
> Sorry to be skeptical. Object detection, extensible-web-manifesto
> low-level APIs, avoiding indefinitely scoped or "lifetime" proprietary
> extension mechanisms in favor of incrementalism, all seem better to me.
>
> /be
>


I would like to reframe this conversation in a slightly more layered
context. Your scepticism is appreciated, but I also would like to make sure
we're on the same page in regard to "the tension" and our collective
understanding of the situation. So, here goes.

I thought about this a bit and realized that we first need to have a common
criteria to evaluate whether we even need something like Tubes. That should
be done before we get into mechanics of the solution. I apologize for
jumping the gun. And I apologize even more to poor op whose conversation we
hijacked.

So I came up with the following Capability Availability Success Criteria:

Given any capability on a modern computing device and a developer who wants
to use it, what is a) the acceptable delay between when this capability
becomes available on the web platform vs. first being available on a native
platform, and b) the likelihood that this capability will ever be available
on the web platform.

If we're aiming at "years, not months", and "60-80%", then we're already
successful.

If we're hoping to hit "weeks, not months" and "100%", we need something
like Tubes.

If it's something in between, maybe there are other options.

Setting the bar in terms of these numbers seems like a very charter-ey
thing to decide and agree upon. We should probably do that.

:DG<

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 3:14 PM, Domenic Denicola  wrote:

> From: Dimitri Glazkov [mailto:dglaz...@google.com]
>
> >> It's still not clear to me what the advantage is of creating a
> framework for designing proprietary APIs.
> >
> > If we don't do something like this as a platform, we'd be always lagging
> behind. Many new ideas start as proprietary. It takes time for these ideas
> to take shape and travel toward larger acceptance -- or die.
>
> Can you help us understand the advantages of a string-based proprietary
> APIs over a functions-and-objects proprietary APIs? We've had the latter
> for many years with vendor prefixes, so what are the advantages of putting
> them behind navigator.connect?
>

Because that's where the bedrock ends.

I tried to lay it all out in the presentation I gave at the Extensible Web
Summit (
https://docs.google.com/a/glazkov.com/presentation/d/1jqAjoU22R4A4OF6k0Eg0yru2sHz6ehXUffBhOegGEvA/pub?start=false&loop=false&delayms=3000&slide=id.g1df8b027f_015
)

At that point, I was primarily interested in figuring out what would the
lowest-level Web platform API would look like.

If we assume that every JS API is eventually explained, there will still be
some that will require going outside of the web platform. With the Tubes,
every such API eventually bottoms out at a MessagePort. The concept of C++
bindings is literally gone (with a few exceptions -- more on that later).

Since MessagePorts can vend other MessagePorts, you can easily see how the
entire access to the outside could be conceived from one primordial
MessagePort.

I was sort of excited when I stumbled onto this. But then I realized that
this scheme could also be used to explain differences between the
platforms' implementation details, as well as provide extension points.

In the world of Tubes, any API is just sugar around the MessagePorts. So,
when you say functions-and-objects APIs, the Tubes world is viewing it as
some JS that wraps MessagePorts.

It seems reasonable to start without sugar, with just raw ports, let
developers build their own, collect all the patterns, and then come up with
standards around the best patterns. In other words, the responsibility of
sugaring shifts to the userland, and the job of figuring out a good
standard becomes completely data-driven.

There are a few exceptions where Tubes fail. There are synchronous APIs and
APIs that are so performance-sensitive that it would be tough to move them
completely to the Tubes world. But I think that is okay. We can strive for
perfection, but accept squishiness.


> navigator.connect seems great just for talking to foreign service workers
> (in fact it can be the basis for a very general and powerful intents
> system). But from what I can understand it's serving two masters: talking
> to service workers built on standards that run in any browser, and also
> talking to virtual "service workers" that implement proprietary
> string-based APIs using "URLs" that only work in certain browsers. I don't
> understand how these are connected... Hope you can help me out there :)
>

The reason why I see those two as the same thing is because they are only
different in the implementation detail. If I am asking for
http://facebook.com/apis/contacts, I want to get contacts. It shouldn't
matter if they arrive as a result of a SW querying the server or the
Android's contacts provider API.

:DG<

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 5:33 PM, Brendan Eich 
wrote:

> Right.
>
> Didn't we have a problem with Canvas's string-based getContext already?
>
> http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html


Domenic's question still needs addressing separately, but just a quick
response here -- the API roc described there is different. Tubes are just
like talking to a worker or any MessagePort. There is no extra API surface
emerging from getContext-like function call.

:DG<


>
>
> /be
>
>  Domenic Denicola <mailto:d...@domenic.me>
>> November 10, 2014 at 6:14 PM
>> From: Dimitri Glazkov [mailto:dglaz...@google.com]
>>
>>
>> Can you help us understand the advantages of a string-based proprietary
>> APIs over a functions-and-objects proprietary APIs? We've had the latter
>> for many years with vendor prefixes, so what are the advantages of putting
>> them behind navigator.connect?
>>
>> navigator.connect seems great just for talking to foreign service workers
>> (in fact it can be the basis for a very general and powerful intents
>> system). But from what I can understand it's serving two masters: talking
>> to service workers built on standards that run in any browser, and also
>> talking to virtual "service workers" that implement proprietary
>> string-based APIs using "URLs" that only work in certain browsers. I don't
>> understand how these are connected... Hope you can help me out there :)
>>
>> Dimitri Glazkov <mailto:dglaz...@google.com>
>> November 10, 2014 at 12:45 PM
>> On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren > <mailto:ann...@annevk.nl>> wrote:
>>
>> On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov
>> mailto:dglaz...@google.com>> wrote:
>> > FWIW, I think we should be concentrating on something like the
>> Tubes (aka
>> > navigator.connect): https://github.com/dglazkov/tubes
>> >
>> > It is hard to impossible to get these types APIs right on the
>> first try.
>> > That's why we need to create a clearinghouse for capability
>> experiments and
>> > be data-driven in designing the right API.
>>
>> It's still not clear to me what the advantage is of creating a
>> framework for designing proprietary APIs.
>>
>>
>> If we don't do something like this as a platform, we'd be always lagging
>> behind. Many new ideas start as proprietary. It takes time for these ideas
>> to take shape and travel toward larger acceptance -- or die.  Instead of
>> shunning these ideas until they mature -- and thus effectively shut the
>> door to any innovation, we should embrace them and give them a place in the
>> platform.
>>
>> Take http://www.intel.com/content/www/us/en/architecture-and-
>> technology/realsense-overview.html as an example. It's unclear whether
>> this will lead to anything great. It's even less clear what the Web
>> platform API should look like, or whether this will every result on a
>> standard API. However, if we wait until clarity, we as a platform would
>> lose the ability to participate in the virtuous innovation cycle and, as a
>> result, lose more developer mindshare.
>>
>> FWIW, it is perfectly reasonable for us to admit that we as a platform
>> aim to always be years behind other platforms. But then we should make this
>> clear and communicate it to developers who keep trying to not give up on
>> the Web as a viable modern development platform.
>>
>> :DG<
>>
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>>
>> Anne van Kesteren <mailto:ann...@annevk.nl>
>> November 10, 2014 at 4:38 AM
>>
>> It's still not clear to me what the advantage is of creating a
>> framework for designing proprietary APIs.
>>
>>
>> Dimitri Glazkov <mailto:dglaz...@google.com>
>> November 7, 2014 at 1:01 PM
>> FWIW, I think we should be concentrating on something like the Tubes (aka
>> navigator.connect): https://github.com/dglazkov/tubes
>>
>> It is hard to impossible to get these types APIs right on the first try.
>> That's why we need to create a clearinghouse for capability experiments and
>> be data-driven in designing the right API.
>>
>> :DG<
>>
>>
>> Mounir Lamouri <mailto:mou...@lamouri.fr>
>> November 7, 2014 at 11:57 AM
>>
>> (I realise that my reply went to public-webapps instead of whatwg, not
>> sure why. I will blame

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 9:57 AM, Boris Zbarsky  wrote:

> On 11/10/14, 12:45 PM, Dimitri Glazkov wrote:
>
>> FWIW, it is perfectly reasonable for us to admit that we as a platform
>> aim to always be years behind other platforms. But then we should make
>> this clear and communicate it to developers who keep trying to not give
>> up on the Web as a viable modern development platform.
>>
>
> Why are developers using the Web as a development platform?
>
> This is a serious question.  The Web has all sorts of warts.  Why are
> people trying to use it?
>
> They're trying to use it because it has several desirable properties other
> platforms lack.  The ones that come to mind for me are ease of deployment
> (e.g. no gatekeepers) and broad availability (having a "modern" web
> browser, for some definition of "modern" is pretty hardware-independent and
> even reasonably OS-independent).  Are there other compelling reasons people
> want to use the web?
>
> Adding a framework for proprietary APIs doesn't affect ease of deployment,
> but it sure does affect broad availability.  That's fine for experiments or
> for people who are willing to restrict their audience (perhaps
> temporarily), as we've seen with early adoption of web features in the
> past.  If we go ahead and create a free-for-all of shipping proprietary
> APIs, though, I think we risk throwing the broad availability baby
> completely out with the bathwater.
>

Agreed that this is a risk and we need to be thoughtful in proceeding
forward with something like Tubes.


>
> There's a tension here, as you point out.  I'm interested in resolving it
> while keeping it clear that proprietary APIs are temporary stopgaps that
> should probably not be relied on for things that are meant to be broadly
> available.  Because a number of web developers don't seem to understand the
> latter; they figure they can just get users to switch to a different UA
> (and operating system, and hardware as needed) to use their site.  And if
> they happen to be a national government, say, they're even right, but that
> doesn't make the result good for the Web. The SSL/crypto story in South
> Korea is the failure mode here.


Agreed on the sadness of the specific story. The interesting part here is
that this scenario is unavoidable in any platform that has a third-party
extensibility story. However, if our only alternative as a platform is to
not offer any extensibility, this is also a failure mode. So we're stuck
picking the lesser of two evils.

In my mind, Tubes is a midpoint between these two extremes. The
message-passing semantics are well-defined, the lifetime expectations are
aligned with the Service Workers.

It might be a good exercise to re-traverse the SEED disaster in different
extremes and trying to find the sweet spot.

For example, I can totally see a government simply building their own
custom build of Chromium or Firefox and requiring its citizens to use it.
The Tubes might help interoperability story only if the said government
published a spec of the protocol. It is highly unlikely that the government
would come to W3C and propose a spec and wait for multiple vendors to
implement it.

:DG<

Re: New approach to activities/intents

[Dimitri Glazkov]

On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren  wrote:

> On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov 
> wrote:
> > FWIW, I think we should be concentrating on something like the Tubes (aka
> > navigator.connect): https://github.com/dglazkov/tubes
> >
> > It is hard to impossible to get these types APIs right on the first try.
> > That's why we need to create a clearinghouse for capability experiments
> and
> > be data-driven in designing the right API.
>
> It's still not clear to me what the advantage is of creating a
> framework for designing proprietary APIs.
>

If we don't do something like this as a platform, we'd be always lagging
behind. Many new ideas start as proprietary. It takes time for these ideas
to take shape and travel toward larger acceptance -- or die.  Instead of
shunning these ideas until they mature -- and thus effectively shut the
door to any innovation, we should embrace them and give them a place in the
platform.

Take
http://www.intel.com/content/www/us/en/architecture-and-technology/realsense-overview.html
as an example. It's unclear whether this will lead to anything great. It's
even less clear what the Web platform API should look like, or whether this
will every result on a standard API. However, if we wait until clarity, we
as a platform would lose the ability to participate in the virtuous
innovation cycle and, as a result, lose more developer mindshare.

FWIW, it is perfectly reasonable for us to admit that we as a platform aim
to always be years behind other platforms. But then we should make this
clear and communicate it to developers who keep trying to not give up on
the Web as a viable modern development platform.

:DG<



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

Re: New approach to activities/intents

[Dimitri Glazkov]

FWIW, I think we should be concentrating on something like the Tubes (aka
navigator.connect): https://github.com/dglazkov/tubes

It is hard to impossible to get these types APIs right on the first try.
That's why we need to create a clearinghouse for capability experiments and
be data-driven in designing the right API.

:DG<

On Fri, Nov 7, 2014 at 8:57 AM, Mounir Lamouri  wrote:

> (I realise that my reply went to public-webapps instead of whatwg, not
> sure why. I will blame my email client :))
>
> On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:
> > > Wouldn't be worth experimenting first with a list of predefined share
> > > endpoints (that you anyway might want to have) and see if the feature
> is
> > > actually something that users are looking for?
> >
> > We have something like that in Firefox Nightly. Apple ships something
> > similar in Safari. Both can be extended through proprietary APIs.
>
> I think it would be great if Mozilla could keep track of the usage of
> this feature and share that data.
>
> > > Furthermore, wouldn't
> > > that make sense to have a similar mechanism than Open Search and have a
> > > way for a website to advertise its share endpoint(s)? Maybe the
> Manifest
> > > could be a good use for that. Generally speaking, I see a lot of common
> > > aspects between Open Search and this proposal.
> >
> > Maybe. It would be even less flexible and depend even more on user
> > interface innovation from the user agent.
>
> I don't think the issue here is flexibility. It's extensibility. You
> want website to be able to advertise themselves in that list. Thus,
> websites will only try to do so if they see a benefit in doing that, in
> other words, if that feature is actually used by Firefox users.
>
> As a side note, I don't think that innovation always need to come from
> new APIs. That feature sounds like a great opportunity to innovate
> within the browser UI then iterate with an API.
>
> -- Mounir
>
>

Re: [WebComponents] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

[Dimitri Glazkov]

Here's an update on Custom Elements Spec.

Since the last TPAC:
* Added informative ES6 section:
http://w3c.github.io/webcomponents/spec/custom/#es6
* Minor bug fixes

Next 6 months:
* P1: fix bugs, identified by Mozilla folks when implementing Custom
Elements:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27017
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016
* P1: integrate with new microtask processing:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25714
* P2: other bug fixes as time permits.

:DG<