Re: Art steps down - thank you for everything

2016-01-28 Thread 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...

2015-10-28 Thread Dimitri Glazkov
I am available on all of those days. Will also be happy to help with
logistics.

:DG<


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

2015-10-28 Thread Dimitri Glazkov
Won't it rain though?

:DG<

On Wed, Oct 28, 2015 at 5:47 PM, Chris Wilson <cwi...@google.com> 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 <o...@pettay.fi>
>> *Cc:* Chaals McCathie Nevile <cha...@yandex-team.ru>; 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: TPAC Topic: Using ES2015 Modules in HTML

2015-10-16 Thread 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

2015-09-10 Thread 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

2015-07-07 Thread 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, cha...@yandex-team.ru 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 ann...@annevk.nl:
  On Thu, Jul 2, 2015 at 8:56 AM, Ryosuke Niwa rn...@apple.com 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=

2015-06-13 Thread 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?

2015-06-11 Thread 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=

2015-06-09 Thread Dimitri Glazkov
On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl 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

2015-06-05 Thread Dimitri Glazkov
On Sun, May 17, 2015 at 1:54 AM, Maciej Stachowiak m...@apple.com 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?

2015-05-21 Thread 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 dglaz...@google.com
 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 slot name=some-slot-name rather than
 content-slot=some-slot-name and content slot=some-slot-name.


 --
 https://annevankesteren.nl/



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

2015-05-19 Thread Dimitri Glazkov
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola d...@domenic.me 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. summary or li or option) act as dumb containers.
 This was reinforced by the examples in the proposal, which use div
 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?

2015-05-18 Thread Dimitri Glazkov
On Fri, May 15, 2015 at 4:58 PM, Scott Miles sjmi...@google.com 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?

2015-05-18 Thread Dimitri Glazkov
On Mon, May 18, 2015 at 6:48 PM, Hayato Ito hay...@chromium.org wrote:

 My preference in v1:

 1. select (strongly preferred). okay to rename it if we have a better
 name. e.g. content select=xxx ==  slot select=xxx
 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?

2015-05-18 Thread Dimitri Glazkov
On Mon, May 18, 2015 at 8:18 PM, Hayato Ito hay...@chromium.org 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?

2015-05-15 Thread Dimitri Glazkov
On Fri, May 15, 2015 at 5:45 PM, Scott Miles sjmi...@google.com 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

2015-05-13 Thread 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: Shadow DOM: state of the distribution API

2015-05-06 Thread Dimitri Glazkov
On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote:

 It seems we have three contenders for the distribution API.

 1) Synchronous, no flattening of content. A host element's shadow
 tree has a set of slots each exposed as a single content element to
 the outside. Host elements nested inside that shadow tree can only
 reuse slots from the outermost host element.

 2) Synchronous, flattening of content. Any host element nested
 inside a shadow tree can get anything that is being distributed.
 (Distributed content 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 content select and
 content slot 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: Custom Elements: insert/remove callbacks

2015-05-06 Thread Dimitri Glazkov
On Wed, May 6, 2015 at 6:45 AM, Anne van Kesteren ann...@annevk.nl 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: Custom Elements: is=

2015-05-06 Thread 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 espr...@chromium.org
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 aboxh...@google.com wrote:



 On Wed, May 6, 2015 at 8:33 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Wed, May 6, 2015 at 4:46 PM, Léonie Watson lwat...@paciellogroup.com
 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 button, you can be reasonably certain that it will
 adhere to the HTML spec in behaviour; when using an x-button, 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

2015-05-06 Thread 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

2015-05-06 Thread Dimitri Glazkov
On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola d...@domenic.me 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 canvas or input work? I am
pretty sure both of those are constructed during cloning.

:DG


Re: Shadow DOM Imperative API proposal #1 vs content select/slot

2015-05-01 Thread 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 ann...@annevk.nl wrote:

 Wilson Page attempted to implement content select (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 content select 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 content slot implementation for the various
 solutions to see whether they can meet that proposal. Though I think
 as content slot was originally proposed the solution with #1 would
 get equally complex due to having to do recursive unwrapping of
 content 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: Nice version Re: Minutes of Shadow DOM meeting

2015-04-29 Thread Dimitri Glazkov
Will do.

:DG

On Sun, Apr 26, 2015 at 2:08 AM, cha...@yandex-team.ru 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 cha...@yandex-team.ru:
  25.04.2015, 14:45, Bjoern Hoehrmann derhoe...@gmx.net:
   * 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: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-29 Thread Dimitri Glazkov
On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com 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: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-29 Thread Dimitri Glazkov
On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com 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)

2015-04-29 Thread Dimitri Glazkov
On Wed, Apr 29, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov dglaz...@google.com
 wrote:
 
  On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com 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: [components] Apple's consolidated feedback on Web Components

2015-04-23 Thread 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 m...@apple.com wrote:


  On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak m...@apple.com 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

2015-04-22 Thread 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

2015-04-21 Thread Dimitri Glazkov
On Tue, Apr 21, 2015 at 9:43 PM, Daniel Freedman dfre...@google.com 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 date-range-combo-box example that would take two date
 inputs (start date and end date) and distribute them through the example
 date-combo-box, 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 date-combo-box content elements, but date-combo-box
 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

2015-04-20 Thread Dimitri Glazkov
On Sun, Feb 8, 2015 at 10:17 AM, Ryosuke Niwa rn...@apple.com 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

2015-04-16 Thread Dimitri Glazkov
On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com 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

2015-04-16 Thread 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 dglaz...@google.com
wrote:

 On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com 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?

2015-04-16 Thread Dimitri Glazkov
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319

On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn espr...@chromium.org
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:

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

2015-04-16 Thread Dimitri Glazkov
Imports bug tree:
https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20683hide_resolved=1

On Thu, Apr 16, 2015 at 7:27 AM, Dimitri Glazkov dglaz...@google.com
wrote:

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

 On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn espr...@chromium.org
 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:

   PromiseDocument 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

2015-04-14 Thread Dimitri Glazkov
On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com
 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=14978hide_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=20684hide_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?

2015-04-09 Thread Dimitri Glazkov
On Thu, Apr 9, 2015 at 9:04 AM, Rahly hungry.ra...@gmail.com wrote:



 On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle kurt.ca...@gmail.com 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 (div 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
 panel instead of my-really-long-hopefully-not-conflicting-panel.


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: [Shadow] URL-based shadows?

2015-03-18 Thread 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
 script tag, or by way of link rel=import which pulls in same-origin or
 CORS-approved cross-origin content.



 I hadn’t considered cross-domain components, which is another interesting
 use-case, I agree.



 The bit of magic in this proposal that improves on the iframe experience
 is the SharedWorker-like single instance across related components.



 Generally speaking, is cross-origin components something that we should be
 looking to address? The strong isolation is a good model, but very
 restrictive and not that far-different from iframes IMO. I also can’t help
 thinking how the discussion of closed vs. open component access relates to
 cross-origin (or not) components.


I think it's worth trying. And it's the only custom controls use case
from the original list that we didn't yet address:
http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Custom_Controls

We can discuss the priority of this relative to other use cases.

:DG


Re: [Shadow] URL-based shadows?

2015-03-16 Thread Dimitri Glazkov
On Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov dglaz...@google.com
 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 input et al
 today.


Agree.

:DG


Re: [Shadow] URL-based shadows?

2015-03-13 Thread 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 dglaz...@google.com
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?

2015-03-13 Thread 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: template namespace attribute proposal

2015-03-12 Thread Dimitri Glazkov
On Thu, Mar 12, 2015 at 4:13 AM, Robin Berjon ro...@w3.org wrote:

 On 12/03/2015 11:07 , Anne van Kesteren wrote:

 On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com 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 template-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: [Shadow] URL-based shadows?

2015-03-12 Thread 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: Extending HTMLCanvasElement in Custom Element issue

2015-03-11 Thread 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, Халитов Кирилл voro...@gmail.com wrote:

 Hello. My issue is described there
 http://stackoverflow.com/questions/28985426/extending-htmlcanvaselement-in-custom-element-issue
  .

 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

2015-02-24 Thread Dimitri Glazkov
On Tue, Feb 24, 2015 at 12:14 AM, Anne van Kesteren ann...@annevk.nl
wrote:

 On Mon, Feb 23, 2015 at 11:58 PM, Ryosuke Niwa rn...@apple.com 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: Custom elements: synchronous constructors and cloning

2015-02-24 Thread 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 dglaz...@google.com
wrote:



 On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com
 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

2015-02-24 Thread Dimitri Glazkov
On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com
 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: Web Components F2F in April 2015

2015-02-20 Thread Dimitri Glazkov
On Fri, Feb 20, 2015 at 1:08 PM, Dimitri Glazkov dglaz...@google.com
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

2015-02-19 Thread Dimitri Glazkov
On Thu, Feb 19, 2015 at 5:28 AM, Arthur Barstow art.bars...@gmail.com
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

2015-02-18 Thread 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 dialog from HTML import

2015-02-18 Thread Dimitri Glazkov
Can you file a spec bug?

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

:DG

On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen ash...@scirra.com wrote:

 I filed crbug.com/458799 for Chrome recently since showing a dialog
 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 dialog. 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 dialog in a
 HTML import has the invisible HTML import document as the node document of
 the dialog. 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)

2015-02-12 Thread 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 rn...@apple.com wrote:


 On Feb 12, 2015, at 4:50 AM, Steve Faulkner faulkner.st...@gmail.com
 wrote:


 On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl 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

2015-02-06 Thread 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?

2015-02-06 Thread Dimitri Glazkov
On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow art.bars...@gmail.com
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

2015-02-05 Thread Dimitri Glazkov
On Thu, Feb 5, 2015 at 10:11 AM, Dimitri Glazkov dglaz...@google.com
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

2015-02-05 Thread Dimitri Glazkov
On Thu, Feb 5, 2015 at 10:52 AM, Marc Fawzi marc.fa...@gmail.com 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

2015-02-05 Thread Dimitri Glazkov
On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi 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

2015-02-05 Thread Dimitri Glazkov
On Thu, Feb 5, 2015 at 9:41 AM, Dimitri Glazkov dglaz...@google.com wrote:



 On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi 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

2015-02-04 Thread Dimitri Glazkov
On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 
  On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi 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: Shadow tree style isolation primitive

2015-02-03 Thread Dimitri Glazkov
Not trying to barge in, just sprinkling data...

On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell bkard...@gmail.com wrote:



 On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi 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

2015-02-02 Thread 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*]

2015-02-02 Thread Dimitri Glazkov
On Mon, Feb 2, 2015 at 6:03 AM, Arthur Barstow art.bars...@gmail.com
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

2015-01-29 Thread Dimitri Glazkov
One additional point, unrelated to accessibility: is also enables
piggybacking to special parser behavior of existing elements. For example,
I can extend template or link.

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 bru...@opera.com wrote:

 On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
 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
 input type=radio is=luscious-radio 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

2015-01-16 Thread Dimitri Glazkov
On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com 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: Custom element design with ES6 classes and Element constructors

2015-01-15 Thread 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

2015-01-15 Thread Dimitri Glazkov
No argument that callbacks are also a useful new addition.

:DG


Re: Custom element design with ES6 classes and Element constructors

2015-01-15 Thread Dimitri Glazkov
On Thu, Jan 15, 2015 at 2:37 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wyc...@gmail.com 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: Custom element design with ES6 classes and Element constructors

2015-01-15 Thread 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

2015-01-15 Thread Dimitri Glazkov
On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren ann...@annevk.nl 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: Minimum viable custom elements

2015-01-14 Thread 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

2015-01-14 Thread Dimitri Glazkov
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579

On Wed, Jan 14, 2015 at 11:11 AM, Domenic Denicola d...@domenic.me 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

2015-01-14 Thread Dimitri Glazkov
On Mon, Jan 12, 2015 at 9:11 PM, Boris Zbarsky bzbar...@mit.edu 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

2015-01-09 Thread 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 ann...@annevk.nl wrote:

 On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com 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

2015-01-09 Thread 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 dglaz...@google.com 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 ann...@annevk.nl
 wrote:

 On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com 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

2015-01-08 Thread Dimitri Glazkov
On Thu, Jan 8, 2015 at 7:56 AM, Anne van Kesteren ann...@annevk.nl 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

2015-01-06 Thread Dimitri Glazkov
On Tue, Jan 6, 2015 at 10:38 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Jan 6, 2015 at 7:06 PM, Dimitri Glazkov dglaz...@google.com
 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

2015-01-06 Thread Dimitri Glazkov
On Tue, Jan 6, 2015 at 10:59 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Jan 6, 2015 at 7:54 PM, Dimitri Glazkov dglaz...@google.com
 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: pull request on custom elements spec

2015-01-06 Thread Dimitri Glazkov
Thanks! Merged.

:DG

On Tue, Jan 6, 2015 at 1:46 AM, Steve Faulkner faulkner.st...@gmail.com
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

2015-01-06 Thread Dimitri Glazkov
On Tue, Jan 6, 2015 at 9:56 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Jan 6, 2015 at 6:13 PM, Dimitri Glazkov dglaz...@google.com
 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: ES6 and upgrading custom elements

2015-01-06 Thread 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 ann...@annevk.nl 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

2014-12-08 Thread Dimitri Glazkov
On Sat, Dec 6, 2014 at 7:34 AM, Arthur Barstow art.bars...@gmail.com
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

2014-11-18 Thread Dimitri Glazkov
On Sun, Nov 16, 2014 at 8:30 PM, Robert O'Callahan rob...@ocallahan.org
wrote:

 On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov dglaz...@google.com
 wrote:

 On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan rob...@ocallahan.org
 wrote:

 On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov dglaz...@google.com
 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 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.


 These frameworks do not fit very well into the scope of my problem
 statement; I don't see them

Re: New approach to activities/intents

2014-11-11 Thread Dimitri Glazkov
On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich bren...@secure.meer.net
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

2014-11-11 Thread Dimitri Glazkov
On Tue, Nov 11, 2014 at 12:28 PM, Robert O'Callahan rob...@ocallahan.org
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: Bringing APIs for experimental hardware/software to the Web

2014-11-11 Thread Dimitri Glazkov
On Tue, Nov 11, 2014 at 3:01 PM, Robert O'Callahan rob...@ocallahan.org
wrote:

 On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov dglaz...@google.com
 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

2014-11-10 Thread Dimitri Glazkov
On Mon, Nov 10, 2014 at 9:57 AM, Boris Zbarsky bzbar...@mit.edu 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

2014-11-10 Thread Dimitri Glazkov
On Mon, Nov 10, 2014 at 5:33 PM, Brendan Eich bren...@secure.meer.net
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 ann...@annevk.nl
 mailto:ann...@annevk.nl wrote:

 On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov
 dglaz...@google.com 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 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

Re: New approach to activities/intents

2014-11-10 Thread Dimitri Glazkov
On Mon, Nov 10, 2014 at 3:14 PM, Domenic Denicola d...@domenic.me 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=falseloop=falsedelayms=3000slide=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

2014-11-07 Thread 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 mou...@lamouri.fr 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]

2014-10-24 Thread 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


[webcomponents]: Telcon on as-needed basis from now on

2014-06-09 Thread Dimitri Glazkov
Howdy, Web Appey folks!

Last week's telcon was super-exciting. I was the only participant. If
not for Hayato-san who stayed up late and tried to keep up my spirits,
it would've been a total tree falling in the forest.

I think it might be best to flip the regular bit to off for now,
and only use this time slot when we have other participants. Thus,
consider the weekly call cancelled unless there's an announcement
otherwise.

Another idea Hayato-san and I discussed is moving it to Tokyo-friendly
timezone, so that him and I could just use as a weekly spec
coordination call, rather than office hours-style arrangement.

:DG



[webcomponents]: Semi-regular telcon tomorrow

2014-06-02 Thread Dimitri Glazkov
We will be having our second Web Components telcon tomorrow (June 3).
If you'd like to suggest specific agenda items, please reply to this
mail.

Potential agenda items:
* Understanding Shadow DOM theming problem, brainstorming primitives,
maybe even filing bugs (who knows!).
* Reduce the frequency of the call to once in 2 weeks (once a month?)

Details (also on https://www.w3.org/wiki/WebComponents/):

* IRC: #webapps (irc://irc.w3.org) -- please join if you participate
in the call, since logging/minuting/attendance logistics happen there

* Phone Bridge: W3C's Zakim Bridge +1.617.761.6200; PIN = 9274#; SIP
information http://www.w3.org/2006/tools/wiki/Zakim-SIP

* Time and Day:
- Tuesday: San Francisco 09:00; Boston 12:00; UTC: 16:00; Paris:
18:00; Helsinki: 19:00;
- Wednesday: Tokyo: 01:00

* Duration: 30-45 min

:DG



Re: [webcomponents]: Next weeks telcon agenda

2014-05-26 Thread Dimitri Glazkov
Since we had no topic suggestions, let's cancel the call this week.

:DG

On Fri, May 23, 2014 at 12:36 PM, Dimitri Glazkov dglaz...@google.com wrote:
 As a reminder, we have our standing meeting next week:
 https://www.w3.org/wiki/WebComponents/

 Please reply to this mail with your agenda topics. I haven't had a
 chance to work on specs this week, so I don't have any topics.

 :DG



Re: [HTML Imports] What is the imagined work flow?

2014-05-23 Thread Dimitri Glazkov
Brian,

I believe Scott enumerated all these in his initial reply, but here's
my take (I wrote parts of this in another email, my apologies to that
email's recipient for repeating myself :)

HTML Imports are primarily about dependency resolution. They allow the
web developer to think locally in terms of their dependencies. Then,
the underlying machinery builds a global dependency graph and turns it
into a tree to ensure consistent processing order.

Scripts in the imports are evaluated in this order. In addition, HTML
Imports load/apply styles to the document in the same order, which
enables a much saner way to reason about components and their effects.

For example, in Jan Miksovsky's presentation at SFHTML5 event, he shows
something very interesting
(https://www.youtube.com/watch?feature=player_detailpagev=mN7IAaRdi_k#t=8608).

He pastes

link rel=import
href=http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html;

in a jsbin and instantly gets his custom element work (modulo the
platform.js polyfill, which will eventually not be necessary). This is
super important. A typical way to do this prior to imports is:

1) Add the script src reference to the library that was used to
develop this component
2) Add the link to the stylesheets that will be used by the component
3) Add the script src reference to the component itself.
4) In the script of the component, there will probably be some strings
that are turned into DOM.
5) More than likely, there will be more links to other scripts or some
machinery to munge all these scripts into one large one.

Effectively, since there isn't a way to manage dependencies, this work
would be relegated to build tools.

With HTML Imports, Jan is able to do something for more elegant -- a
single-line solution.

This works, because HTML Imports carefully resolve the dependency tree
for him. And this dependency tree is actually non-trivial (you can
trace it with me by viewing source of
http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html):

1) The basic-autosize-textarea.html states that it has
basic-element/basic-element.html as a dependent import
2) The basic-element.html has another dependent import, polymer.html
3) polymer.html depends on polymer.js and polymer-body.html

Now that the dependency tree is understood, the HTML Imports plumbing
evaluates the scripts, according to the tree:

1) polymer.js, which among other things, defines the polymer-element
custom element
2) polymer-body.html
3) basic-element.html, which uses polymer-element to define a new
basic-element element
4) basic-autosize-textarea.html, which uses polymer-element to
extend basic-element to actually create the
basic-autosize-textarea that we will need.

All of this work is done on Jan's behalf without him needing to worry
about it. He simply states dependencies -- locally. What's even cooler
is that if anyone uses other components that rely on basic-element
or polymer-element elsewhere in the document (or its imports), the
respective imports will not be loaded twice -- the dependency
management system takes care of that.

The light bulb moment for me was realizing that I no longer need to
state up front things like I am using jquery or I am using
framework/library X at the beginning of your document. Instead, the
import lists it as a local, explicit dependency -- which (especially
with good inspector/devtools support) is a lot easier to reason about.

I think you mentioned ES6 modules vs. HTML imports. They are not in an
adversarial relationship. If anything, ES6 modules can be viewed as
one of the bedrock technologies on which the HTML imports are built --
namely the underlying underlying loading/dependency resolution
machinery. That's where we're going
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=25715).

Once we figure out how to implement script type=module
(https://github.com/dherman/web-modules/tree/master/module-tag), it
will fit nicely into the imports story as well -- it's just one of
dependencies.

:DG

On Fri, May 23, 2014 at 9:35 AM, Brian Di Palma off...@gmail.com wrote:
 HTML Imports seems the least crucial of the Web Components specs.

 Consider that all but the most trivial of Web Components will require JS.
 JS is now getting a module system which can be used to load other
 resources ( e.g. https://github.com/systemjs/systemjs/#plugins ).
 The JS module system seems much more flexible then loading via URLs.

 I think it's fair to question if HTML Imports is even necessary.
 Are any of the current HTML Import use cases impossible to implement
 using JS modules?

 On Wed, May 21, 2014 at 8:13 AM, Scott Miles sjmi...@google.com wrote:
 Sorry, but just a bit of follow up.

 One may notice that the Web Components spec is imperative and assume that
 declarative support is not important. But as it turns out, the notion of
 using custom-elements to bootstrap declarative syntaxes allows various
 parties to 

[webcomponents]: Next weeks telcon agenda

2014-05-23 Thread Dimitri Glazkov
As a reminder, we have our standing meeting next week:
https://www.w3.org/wiki/WebComponents/

Please reply to this mail with your agenda topics. I haven't had a
chance to work on specs this week, so I don't have any topics.

:DG



Re: [webcomponents]: Inaugural telcon tomorrow

2014-05-19 Thread Dimitri Glazkov
I also made a wiki: https://www.w3.org/wiki/WebComponents/

:DG


On Mon, May 19, 2014 at 8:50 AM, Dimitri Glazkov dglaz...@google.com wrote:
 Hell,

 We will be having our first Web Components telcon tomorrow (May 20).
 If you'd like to suggest specific agenda items, please reply to this
 mail. I am putting together a wiki like the one D3E peeps have.

 Potential agenda items:
 * Custom elements spec and ES6 update* Discuss Shadow DOM survey and
 results, unscientific as they are
 (https://www.surveymonkey.com/results/SM-SQX77WF/)

 Details:

 * IRC: #webapps (irc://irc.w3.org) -- please join if you participate
 in the call, since logging/minuting/attendance logistics happen there

 * Phone Bridge: W3C's Zakim Bridge +1.617.761.6200; PIN = 9274#; SIP
 information http://www.w3.org/2006/tools/wiki/Zakim-SIP

 * Time and Day:
 - Tuesday: San Francisco 09:00; Boston 12:00; UTC: 16:00; Paris:
 18:00; Helsinki: 19:00;
 - Wednesday: Tokyo: 01:00

 * Duration: 30 min max?

 I am currently still looking for a scribe. Let me know if you can help out.

 :DG



Re: Custom Elements: 'data-' attributes

2014-05-13 Thread Dimitri Glazkov
On Tue, May 13, 2014 at 2:37 AM, Anne van Kesteren ann...@annevk.nl wrote:

 Sole had the idea of providing hooks for attributes so a component can
 say it handles them rather than the user agent. That makes a lot of
 sense to me. That way you can grab any name, even existing ones.

3 this idea, would love to hear more. It's like dinner reservations
for attributes!

:DG



Re: [webcomponents]: Regular Conference Call Survey

2014-05-12 Thread Dimitri Glazkov
I am sure you were all at the edge of your seats, in anticipation of
the results of this survey being announced. I have good news: data was
collected!

There were just 4 responses recorded. Not sure if this in itself is a
vote against of a regular call. There's one way to find out for sure
:)

In amazing coincidence, 2 of them proposed exactly the same meeting
time -- Tuesday 9am PDT. I know this doesn't work well for folks with
UTC+4, but I am tempted to start there and tweak as we go for next
(if any) instances.

So, let's try for next Tuesday, May 20. I'll announce it again
(hopefully with more details) next Monday morning.

:DG


On Thu, May 1, 2014 at 11:44 AM, Dimitri Glazkov dglaz...@google.com wrote:
 Greetings, WebApp-ateurs!

 At the last F2F, there was some positive sentiment toward setting up a
 regular conference call to discuss Web Components-related topics.

 On Art's advice, I thereby present this lovely survey that seeks to
 find a good time slot for such a conference call:

 https://docs.google.com/forms/d/1jpHhCPE_avjtRZbll7ezmZ_4yHwrBv9qijOGEQCX0RY/viewform?usp=send_form

 If you're interested in participating, please fill out this form by
 Friday, May 16, 2014.

 Thanks!

 :DG



[webcomponents]: Informal Shadow DOM Survey

2014-05-12 Thread Dimitri Glazkov
Howdy, Web-Appa-rishi,

Last week, I was looking at the Shadow DOM bugs and, sort of
impulsively, put together a quick top 10 survey that I then promptly
twittered here:

https://twitter.com/dglazkov/status/462319811326791680

I thought it might be interesting for y'alls to see the results so far:

https://www.surveymonkey.com/results/SM-SQX77WF/

:DG



Re: NetAwards 2014: The winner of Best New Technology 2014 is Web Components

2014-05-09 Thread Dimitri Glazkov
Yay team!!

On Fri, May 9, 2014 at 8:26 AM, Coralie Mercier cora...@w3.org wrote:

 Hi Team,
 DKA, public-webapps,

 A quick follow-up that the NetAwards winner for Best New Technology 2014 is
 Web Components.

 Dan Appelquist is representing the W3C in London right now and got the award
 on our behalf:
   https://twitter.com/torgo/status/464785623795376129/photo/1

 Thanks, Dan!

 Congrats WebApps WG and team involved!


 Coralie

 --
  Coralie Mercier  -  W3C Communications Team  -  http://www.w3.org
 mailto:cora...@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/




  1   2   3   4   5   >