Web Components Viewpoint from the Microsoft Guy

2015-04-24 Thread Travis Leithead
Like Mozilla and Apple [1] [2], I would also like to briefly lay out my 
viewpoint on Web Components in advance of the face-to-face meeting.

I love the work that has been done thus far on the web components specs, and 
while Microsoft has not yet begun development of these features [3] I know they 
support the use cases and are excited to see the success that early 
implementations have had. As has been said, I also feel that there are some 
rough edges among the present set of web components specifications. I also 
believe that some important additional features are necessary to complete the 
web components usage and development experience for web developers. Finally, 
I'm also a fan of simplification where appropriate, both in terms of helping 
facilitate quicker interoperability, as well as making an implementations 
easier :-)

I make reference to some proposals below (special thanks to Arron Eichols for 
helping me navigate the weird waters of CSS). I want to emphasize that these 
are primarily Arron and I's own work and should not be considered an official 
Microsoft proposal. 

The following views are organized by spec. They cover the breadth of web 
component features. At the face-to-face meeting, our shared goal is to 
primarily resolve issues in Shadow DOM--the rest of this viewpoint is provided 
for reference and in case the scope of the meeting is expanded ;-)

--Shadow DOM---

Open vs. closed
* I think that both types of shadow doms should be available in the platform, 
but believe that developers asking for a closed shadow dom often want more 
strict encapsulation [4] than simply closing off access to the shadowRoot. I'm 
not sure whether it makes sense to have 1) a simple closed shadow root as 
well as 2) a fully encapsulated closed shadow root in the platform. Similar to 
Apple's isolated imports and Mozilla's isolated Shadow DOM ideas, I'd like 
to propose isolated custom elements [5], but think such a feature is additive 
and doesn't need to block progress of any of the existing specs.

Generational Shadow DOMs
* I support Apple's proposal to simplify this concept in favor of some form of 
named slots.

Imperative Distribution API
* I'm in favor of pursing this, but don't feel it needs to block progress.

Event Retargeting
* I believe that for open Shadow DOM's this isn't necessary. I think some form 
of event retargeting is necessary for a closed component.

Declarative Syntax
* I support Mozilla's idea for a straightforward Shadow DOM declarative syntax 
to help with serialization and parsing scenarios. We don't think this blocks 
progress on the current spec.

--Custom Elements

Construction
* I support synchronous or the almost-synchronous construction options for 
their simplicity and rationality.

Inheritance
* I don't object to inheritance from any arbitrary element--though I've heard 
that many developers expect to inherit _behavior_ and element _semantics_ 
(e.g., Accessibility behaviors) as well, and that this might lead to failed 
expectations.

--Styling/CSS---

Default Styles
* Both Microsoft internal and external customers have told me they need the 
ability to style components (not necessarily just those that might have a 
Shadow DOM) with default styles that can be overridden by author styles. I 
offer a proposal to support this [6].

Shadow Piercing
* I believe that the correct platform technique for achieving style isolation 
is through Shadow DOM, and that it might be necessary to have the shadow 
piercing combinator. I'm interested in exploring other ideas that may obviate 
the need for the combinator. *If* the shadow piercing combinator is retained as 
currently defined, then it should be tempered with the ability for component 
authors to control which styles it can affect. Such a feature might look like a 
new general technique for styling control [7] which limits the capability of 
the shadow dom piercing combinator. The proposal could also be used to open up 
styling control to iframes using the combinator in order to help fix the 
current iframe[seamless] situation.

--Template--

Databinding
* I think it is still premature to standardize any particular data-binding 
syntax on top of the template element. There is a thriving set of existing 
JavaScript-based data-binding libraries and there doesn't appear to be a 
particular dominant technique.

--HTML Imports

link[rel=import]
* I would like to focus our efforts on developing and understanding the ES6 
module loader before pursuing an implementation of this spec.

-Travis

[1] http://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0225.html
[3] https://status.modern.ie/?term=web%20components
[4] 

[Bug 21387] Need to spec better support for control mapping

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21387

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/7

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 17309] It is not defined what the value of Gamepad.index should be after disconnecting the gamepad

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17309

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #12 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/5

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 21386] Should specify how to present d-pads/triggers as buttons

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21386

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/6

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 27986] Specify exact length of array returned by Navigator.getGamepads()

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27986

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/13

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 27444] Gamepad objects should have a dictionary of attributes about the controller and data source

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27444

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/12

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: Exposing structured clone as an API?

2015-04-24 Thread Robin Berjon

On 24/04/2015 02:18 , Anne van Kesteren wrote:

On Thu, Apr 23, 2015 at 3:02 PM, Ted Mielczarek t...@mozilla.com wrote:

Has anyone ever proposed exposing the structured clone algorithm directly as
an API?


There has been some talk about moving structured cloning into
ECMAScript proper and exposing the primitives. But TC39 does not seem
particularly receptive unless it comes with a way for someone to
participate in the structured cloning algorithm with custom objects.


Does this have to be any more complicated than adding a toClone() 
convention matching the ones we already have?


--
Robin Berjon - http://berjon.com/ - @robinberjon



[Bug 26203] Order in which index entries should be reused is unspecified

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26203

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/11

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 25203] [gamepad] Connected Attribute appears to serve no purpose if the Gamepad object is a snapshot

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25203

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/10

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 21434] Need to spec liveness of Gamepad objects

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #8 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/8

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 17309] It is not defined what the value of Gamepad.index should be after disconnecting the gamepad

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17309
Bug 17309 depends on bug 21434, which changed state.

Bug 21434 Summary: Need to spec liveness of Gamepad objects
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 25202] [gamepad] id property is unclear how its established

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25202

Ted Mielczarek [:ted] t...@mielczarek.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #6 from Ted Mielczarek [:ted] t...@mielczarek.org ---
Moved to https://github.com/w3c/gamepad/issues/9

-- 
You are receiving this mail because:
You are on the CC list for the bug.



PSA: publishing new WD of UI Events and D3E Keyboard specs April 28/30

2015-04-24 Thread Arthur Barstow
Thanks to Xiaoqian, the UI Events and the two D3E Keyboard Events 
code/key Values specs have been moved to Github and we plan to publish 
them next week using the following Draft WDs as the basis:


https://w3c.github.io/uievents/TR.html
https://w3c.github.io/DOM-Level-3-Events-code/TR.html
https://w3c.github.io/DOM-Level-3-Events-key/TR.html

If anyone has any major concerns about this, please reply right away. 
uievents is expected to be published on April 28 and the other two on or 
around April 30.


PRs are welcome and encouraged (the HTML validator reports a lot of 
errors for all of the ReSpec resolved versions of the specs)!


A few notes about these specs:

* The permissions of the specs' now obsolete Github repository will be 
set to read-only.


* After the open Bugzilla bugs are copied to Github Issues (or the last 
open Bugzilla bug is closed), the specs' Bugzilla component will be 
marked `Historical` and set to read-only.


Lastly, since this will be the second WD of UI Events since it was 
renamed, perhaps the (formerly DOM Level 3 Events) part of the title 
should now be removed https://github.com/w3c/uievents/issues/1. Any 
objections to that?


-Thanks, AB





Re: JSON imports?

2015-04-24 Thread Erik Isaksen
Would be nice to have this. We only have imperative ways to grab JSON (that
is verified as JSON) . This would give a built in way to grab JSON data. I
do agree with Wilson that we can do this with custom elements but I think
this is much more suited to be a native element or extension of script.

maybe :
import type=application/json src=foo.json/import

On Fri, Apr 24, 2015 at 5:54 PM Matthew Robb matthewwr...@gmail.com wrote:

 I like the idea of this. It reminds me of polymer's core-ajax component.
 On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com wrote:

 Inspired by HTML imports, can we add JSON imports too?

 ```html
 script type=application/json src=foo.json id=foo/script
 script type=application/json id=bar
 { foo: bar }
 /script
 ```

 ```js
 document.getElementById(foo).json // or whatever
 document.getElementById(bar).json
 ```




Re: Exposing structured clone as an API?

2015-04-24 Thread Brendan Eich

Step where you need to, to avoid falling over :-P.

The problems with generalized/extensible clone are clear but we have 
structured clone already. It is based on a hardcoded type-case 
statement. It could be improved a bit without trying to solve all 
possible problems, IMHO.


/be

Anne van Kesteren wrote:

On Fri, Apr 24, 2015 at 3:13 PM, Joshua Belljsb...@google.com  wrote:

  If we're not dragging in the notion of extensibility, is there complication?


I would be fine with adding an API without extensibility. I was just
afraid we might step on TC39's toes, but maybe since they're not
helping out with structured clones that's okay?




Minutes of Shadow DOM meeting

2015-04-24 Thread chaals
Hi folks,

we're just cleaning up now.

We'll post a summary - there is most of one at 
https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0
 

The minutes (thanks to Taylor Savage fora  great scribing job) are at 
http://www.w3.org/2015/04/25-webapps-minutes.html

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com



Re: Exposing structured clone as an API?

2015-04-24 Thread Anne van Kesteren
On Fri, Apr 24, 2015 at 3:13 PM, Joshua Bell jsb...@google.com wrote:
 If we're not dragging in the notion of extensibility, is there complication?

I would be fine with adding an API without extensibility. I was just
afraid we might step on TC39's toes, but maybe since they're not
helping out with structured clones that's okay?


-- 
https://annevankesteren.nl/



Re: Exposing structured clone as an API?

2015-04-24 Thread Joshua Bell
It seems like the OP's intent is just to deep-copy an object. Something
like the OP's tweet... or this, which we use in some tests:

function structuredClone(o) {
return new Promise(function(resolve) {
var mc = new MessageChannel();
mc.port2.onmessage = function(e) { resolve(e.data); };
mc.port1.postMessage(o);
});
}

... but synchronous, which is fine, since the implicit
serialization/deserialization needs to be synchronous anyway.

If we're not dragging in the notion of extensibility, is there
complication?  I'm pretty sure this would be about a two line function in
Blink. That said, without being able to extend it, is it really interesting
to developers?



On Fri, Apr 24, 2015 at 2:05 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Apr 24, 2015 at 2:08 AM, Robin Berjon ro...@w3.org wrote:
  Does this have to be any more complicated than adding a toClone()
 convention
  matching the ones we already have?

 Yes, much more complicated. This does not work at all. You need
 something to serialize the object so you can transport it to another
 (isolated) global.


 --
 https://annevankesteren.nl/




Re: PSA: publishing new WD of UI Events and D3E Keyboard specs April 28/30

2015-04-24 Thread Кошмарчик
On Fri, Apr 24, 2015 at 7:26 AM, Arthur Barstow art.bars...@gmail.com
wrote:


 A few notes about these specs:

 * The permissions of the specs' now obsolete Github repository will be set
 to read-only.


s/Github/Mercurial/ ?


Re: PSA: publishing new WD of UI Events and D3E Keyboard specs April 28/30

2015-04-24 Thread Arthur Barstow

On 4/24/15 11:33 AM, Gary Kacmarcik (Кошмарчик) wrote:
On Fri, Apr 24, 2015 at 7:26 AM, Arthur Barstow art.bars...@gmail.com 
mailto:art.bars...@gmail.com wrote:



* The permissions of the specs' now obsolete Github repository
will be set to read-only.


s/Github/Mercurial/ ?


Duh; what Gary said ;-).




Re: Exposing structured clone as an API?

2015-04-24 Thread Anne van Kesteren
On Fri, Apr 24, 2015 at 2:08 AM, Robin Berjon ro...@w3.org wrote:
 Does this have to be any more complicated than adding a toClone() convention
 matching the ones we already have?

Yes, much more complicated. This does not work at all. You need
something to serialize the object so you can transport it to another
(isolated) global.


-- 
https://annevankesteren.nl/



[Bug 28558] New: [Shadow] Rename .path to .deepPath and make it hide closed shadow trees in case it is accessed from open/light DOM

2015-04-24 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28558

Bug ID: 28558
   Summary: [Shadow] Rename .path to .deepPath and make it hide
closed shadow trees in case it is accessed from
open/light DOM
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: b...@pettay.fi
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-24 Thread Tab Atkins Jr.
On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky jan@component.kitchen wrote:
 Hi Tab,

 Thanks for your feedback!

 A primary motivation for proposing names instead of CSS selectors to control
 distribution is to enable subclassing. We think it’s important for a
 subclass to be able to override a base class insertion point. That seems
 easier to achieve with a name. It lets content insertion points behave like
 named DOM-valued component parameters that can be overridden by subclasses.

 To use an example, consider the page template component example at
 https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates.
 The image shows a page template for a large university web site. In this
 example, a base page template class defines a header slot. A university
 department wants to create a subclass of this template that partially
 populates some of the base class’ slots. In this case, it may want to add
 the department name to the header slot, then redefine an insertion point
 with the name that lets an individual page in that department add additional
 text to the header.

 The physics department page template subclass could then write something
 like this (following the proposal's syntax):

 template
   div content-slot=“header”
 Physics Department
 content slot=“header”/content
   /div
 template

 If an instance of this page then says

 physics-department-page
   headerFaculty/header
 /physics-department-page

 then the rendered result shows “Physics Department Faculty” in the base
 template header.

 This is analogous to what typical OOP languages enable when a subclass
 overrides a base class property. In such languages, the subclass simply
 defines a property with the same name as a base class property. The
 subclass’ property implementation can invoke the base class property
 implementation if it wants. The model is fairly easy to understand and
 implement, because the properties are always identified by name.

 A similar result could theoretically be achieved with CSS selectors, but the
 approach feels looser and a bit unwieldy, particularly if there are not
 rigid conventions about how the content select clauses are written.
 Assuming it were possible to reproject into a base class’ shadow — and
 that’s not actually possible today — you’d have to write something like:

 template
   shadow
 div class=“header”
   Physics Department
   content select=“.header/content
 /div
   /shadow
 /template

 So that approach could be made to work, but to me at least, feels harder,
 especially if the base class is using complex CSS selectors.

I'm not really seeing the complexity.  In particular, I'm not seeing
why content-slot/slot is easier than class/select.  For all simple
cases (class, attribute, tagname) it seems pretty much identical.
More complex selectors, like :nth-child(), might make it a bit more
difficult (as you have to match your markup to what the superclass is
expecting), but that's probably normally okay, and in problematic
cases is just because the superclass is being too clever.

On the other hand, requiring content-slot in order to place things in
anything but the default slot means you have to ugly up your markup
quite a bit.  It makes current UA-shadow-using elements, such as
details, impossible to duplicate, and makes all uses of shadow DOM
uglier and more verbose.

For example, I think tagname is a very common thing to select on.
details uses it, your fingers automatically used it before you
corrected your example, a number of Polymer examples use it, etc.
Requiring the use of header content-slot=header is adding 20
characters to the element.  A shadow-heavy page, such as some of the
Polymer examples, would have a relatively large amount of its page
weight being paid to this attribute scattered all over the place.

As Justin said, this seems to be extremely over-engineering towards
make subclass-and-reproject slightly more reliable, to the detriment
of every other case.  Subclass-and-reproject works just fine with
select='' unless the superclass's selector is too complex/specialized
to easily satisfy in your subclass's preferred markup; in the common
case of a tagname, class name, or attribute name, the two are
identical.

In return, content-slot makes the common case (just project into some
shadow) more verbose for the user, and make some cases, such as the
date-range-combo-box illustrated by Daniel earlier in the thread
https://gist.github.com/azakus/676590eb4d5b07b94428 impossible.

Overall, this feels like an over-optimization for implementation
complexity (matching content-slot to slot is easier than matching an
element to a selector) without fully considering the cost to the
author and user, which is a strong inversion of the priority of
constituencies.

~TJ



Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-24 Thread Tab Atkins Jr.
On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote:
 I find it decidedly relevant given I'm pointing out that attribute-specified
 slots Domenic mentioned isn't what you described.  Since the only venue in
 which attribute-specified slots came up are [1], [2], and [3].  We're
 DEFINITELY NOT interested in filling slots based on values of arbitrary
 attributes.

 [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
 [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
 [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html

Apologies, I'd misread [1] and didn't realize it really was talking
about projecting the value of an attribute into the content of a slot.

(Though I'm confused by the vehemence of your denial here, given that
in [2] you said you could imagine that such a feature could be easily
added.)

~TJ