Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Dominic Cooney
On Thu, May 7, 2015 at 4:43 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
 justinfagn...@google.com wrote:
  How are you supposed to tell if one of your ancestors was removed?

 Is that a hook builtin elements have today?


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

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/ContainerNode.cppsq=package:chromiumtype=csl=834rcl=1430970612

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

There are similar hooks and uses for insertion.

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



 --
 https://annevankesteren.nl/




Re: Making ARIA and native HTML play better together

2015-05-07 Thread Bruce Lawson
On 7 May 2015 at 06:43, Steve Faulkner faulkner.st...@gmail.com wrote:
 On another thread recent thread, leonie and chaals [3] talked about adding
 behaviours to ARIA.

this makes sense, but (unless I'm inventing nonsense because I'm mad,
which is definitely possible), doesn't this describe the current
behaviour in many UAs anyway? (Or is the aim to record current
practice and mandate it in a spec?)

bruce



Re: Shadow DOM: state of the distribution API

2015-05-07 Thread Hayato Ito
I'm happy to implement some of these proposals in blink to compare the
performance when the time comes, if I or other guys can afford to do.

On Thu, May 7, 2015 at 1:20 PM Hayato Ito hay...@chromium.org wrote:

 I'm wondering how we should estimate the performance impact of these
 proposals.

 In the era of Web Components, I expect that one page has 1k Web
 Components. The page must work without any significant noticeable
 performance regression, compared to a page which doesn't use Web
 Components. That's our bottom line.

 In the current distribution model, I expect we can achieve this goal,
 thanks to the lazy evaluation of distribution.

 Is there any plan how we should evaluate these proposals in terms of
 performance primitives?


 On Thu, May 7, 2015 at 7:53 AM Ryosuke Niwa rn...@apple.com wrote:


  On May 6, 2015, at 2:39 PM, Elliott Sprehn espr...@chromium.org
 wrote:
 
  The 3 proposal is what the houdini effort is already researching for
 custom style/layout/paint. I don't think it's acceptable to make all usage
 of Shadow DOM break when used with libraries that read layout information
 today, ie. offsetTop must work. I also don't think it's acceptable to
 introduce new synchronous hooks and promote n^2 churn in the distribution.

 Sorry, I don't follow. If we're making offsetTop to synchronously return
 the correct value, then authors can easily write code that performs in
 Ω(n^2) by obtaining the value of offsetTop between adding/removing direct
 children of a shadow host.  On the other hand, if we're trying to prevent
 O(n^2) behavior, then we should be adding API to asynchronously retrieve
 layout information.

 - R. Niwa





Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Anne van Kesteren
On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
justinfagn...@google.com wrote:
 How are you supposed to tell if one of your ancestors was removed?

Is that a hook builtin elements have today?


-- 
https://annevankesteren.nl/



Re: Making ARIA and native HTML play better together

2015-05-07 Thread Anne van Kesteren
On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
 Currently ARIA does not do this stuff AFAIK.

Correct. ARIA only exposes strings to AT. We could maybe make it do
more, once we understand what more means, which is basically figuring
out HTML as Custom Elements...


-- 
https://annevankesteren.nl/



Re: Custom Elements: is=

2015-05-07 Thread Anne van Kesteren
On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com wrote:
 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.

I think it is worth worrying about, but I don't think it's worth
holding up a minimal v1 of Custom Elements for. The way to get
agreement among all parties is to do less. And then take baby steps
from.

The way I look at this is that currently you have nothing, since only
Chrome ships this. There's a chance to get three more browsers if you
make some concessions on the warts. And then hopefully we can iterate
from there in a more cooperative fashion.

(The thread Steve shared about ARIA seemed like an equivalent effort
by the way, to expose some of the semantics of native elements through
simple attributes.)


-- 
https://annevankesteren.nl/



Re: Making ARIA and native HTML play better together

2015-05-07 Thread Domenic Denicola
From: Anne van Kesteren ann...@annevk.nl

 On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner faulkner.st...@gmail.com 
 wrote:
 Currently ARIA does not do this stuff AFAIK.

 Correct. ARIA only exposes strings to AT. We could maybe make it do more, 
 once we understand what more means, which is basically figuring out HTML as 
 Custom Elements...

These are my thoughts as well. The proposal seems nice as a convenient way to 
get a given bundle of behaviors. But we *really* need to stop considering these 
roles as atomic, and instead break them down into what they really mean.

In other words, I want to explain the button behavior as something like:

- Default-focusable
- Activatable with certain key commands
- Announced by AT as a button

and then I want to be able to apply any of these abilities (or others like 
them) to any given custom element. Once we have these lower-level primitives 
we'll be in a much better place.



Re: Making ARIA and native HTML play better together

2015-05-07 Thread Steve Faulkner
On 7 May 2015 at 07:53, Bruce Lawson bru...@opera.com wrote:

 this makes sense, but (unless I'm inventing nonsense because I'm mad,
 which is definitely possible), doesn't this describe the current
 behaviour in many UAs anyway?


Currently ARIA does not do this stuff AFAIK. There is some limited keyboard
behaviour mapping for role=button in a few AT's.

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/


RfC: Subresource Integrity; deadline May 26

2015-05-07 Thread Arthur Barstow
The WebAppSec community requests review of Subresource Integrity 
http://w3c.github.io/webappsec/specs/subresourceintegrity/, specifically:


[[
Fetch Integration
Privacy and Security Considerations
CORS interactions
Future Considerations regarding broader integration into other HTML elements
Extensibility
]]

If you have any feedback, please send it to public-webappsec @ w3.org 
([archive]), using a [SRI] Subject: prefix, by May 26.


-Thanks, AB

[archive] https://lists.w3.org/Archives/Public/public-webappsec/

 Forwarded Message 
Subject:Subresource Integrity - review requested
Resent-Date:Thu, 07 May 2015 19:33:16 +
Resent-From:public-review-annou...@w3.org
Date:   Thu, 7 May 2015 19:30:48 +
From:   Brad Hill hillb...@fb.com
To: public-review-annou...@w3.org public-review-annou...@w3.org



Hello,

The Web Application Security Working Group requests review of the following 
specification before 2015-05-26:

   Subresource Integrity
   http://w3c.github.io/webappsec/specs/subresourceintegrity/

The group requests feedback via public-webapp...@w3.org with [SRI] in subject 
line

This specification defines a mechanism by which user agents may verify that a fetched resource has 
been delivered without unexpected manipulation.  Specifically, this version uses hashed metadata 
annotations delivered as a new integrity attribute of the script and link 
tags.

Level 1 is intended as a minimum viable release, targeting what the group 
believes to be a few high-value use cases with the most manageable requirements, in order 
to learn how such a mechanism will interact with the large scale architecture of the Web, 
before proceeding to additional features and scenario targets.

The group has specifically asked for feedback on the following:


Fetch Integration
Privacy and Security Considerations
CORS interactions
Future Considerations regarding broader integration into other HTML elements
Extensibility


Sincerely,

Brad Hill
Co-chair, WebAppSec WG






Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Boris Zbarsky

On 5/7/15 3:43 AM, Anne van Kesteren wrote:

On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
justinfagn...@google.com wrote:

How are you supposed to tell if one of your ancestors was removed?


Is that a hook builtin elements have today?


In Gecko, yes.  The set of hooks Gecko builtin elements have today is, 
effectively:


1)  This element used to not have a parent and now does.
2)  This element has an ancestor that used to not have a parent and now
does.
3)  This element used to have a a parent and now does not.
4)  This element has an ancestor that used to have a parent and
now does not.

-Boris



Re: Making ARIA and native HTML play better together

2015-05-07 Thread Patrick H. Lauke

On 07/05/2015 08:59, Domenic Denicola wrote:
...

These are my thoughts as well. The proposal seems nice as a
convenient way to get a given bundle of behaviors. But we *really*
need to stop considering these roles as atomic, and instead break
them down into what they really mean.

In other words, I want to explain the button behavior as something
like:

- Default-focusable - Activatable with certain key commands -
Announced by AT as a button

and then I want to be able to apply any of these abilities (or others
like them) to any given custom element. Once we have these
lower-level primitives we'll be in a much better place.


Isn't that, in a way, what we currently have already?

- default focusable: add tabindex=0
- activatable with certain key commands: define key command handlers 
yourself in JS

- announced by AT as a button: role=button

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke



Stability of Widget DigSig

2015-05-07 Thread Andrew Twigger
ATSC and CEA are developing standards that include the ability to download
digital signed applications.  Their current specifications reference the W3C
Recommendation for XML Digital Signature for Widgets (18 April 2013).
However, the associated Widgets Digital Signature Namespace
(http://www.w3.org/ns/widgets-digsig/) contains a statement that
Implementers should be aware that this document is not stable. which has
raised questions as to the stability and suitability of referencing Widget
DigSig.  The alternative would be to reference XAdES with the C and T forms
to allow for the inclusion of timestamp and certificate revocation
information which are not included in Widget DigSig.

I would be pleased to receive any information regarding the stability of
Widget DigSig and whether referencing XAdES would provide a better
alternative.

Thank-you,

Andrew Twigger



Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Elliott Sprehn
On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org
 wrote:
  That actually seems pretty similar to what we have, ours is in the form
 of:
 
  Node#insertedInto(Node insertionPoint)
  Node#removedFrom(Node insertionPoint)
 
  where insertionPoint is the ancestor in the tree where a connection was
  added or removed which may be arbitrarily far up the ancestor chain. From
  that you can figure out all the cases Boris is describing.

 Cool. So maybe the DOM specification needs to be updated to have that
 model and we should expose that as low-level hook to web developers.


We'd consider adding a new MutationObserver type, we'd prefer not to add
any more tree mutation callbacks. Anything you can do with those you can do
with an ancestorChanged record type and takeRecords().

- E


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

2015-05-07 Thread Hayato Ito
Ryosuke, could you file a bug for the spec if you find an uncomfortable
part in the spec?
I want to understand exactly what you are trying to improve.

On Fri, May 8, 2015 at 2:21 AM Ryosuke Niwa rn...@apple.com wrote:


  On May 6, 2015, at 11:10 PM, Elliott Sprehn espr...@chromium.org
 wrote:
 
  On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl
 wrote:
  On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote:
   I'm saying:
   - Composed tree is related with CSS.
   - Node distribution should be considered as a part of style concept.
 
  Right, I think Ryosuke and I simply disagree with that assessment. CSS
  operates on the composed tree (and forms a render tree from it).
  Events operate on the composed tree. Selection operates on the
  composed tree (likely, we haven't discussed this much).
 
  Selection operates on the render tree. The current selection API is
 (completely) busted for modern apps, and a new one is needed that's based
 around layout. Flexbox w/ order, positioned objects, distributions, grid,
 none of them work with the DOM based API.

 Please state your presumptions like that before making a statement such as
 composed street is a style concept.

 Now, even if selection were to operate on the CSS box tree, of which I
 will not express my opinion of, event path is still not a style concept.
 If you're proposing to make it a style concept, then I just need to object
 to that.

 - R. Niwa




Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Anne van Kesteren
On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org wrote:
 That actually seems pretty similar to what we have, ours is in the form of:

 Node#insertedInto(Node insertionPoint)
 Node#removedFrom(Node insertionPoint)

 where insertionPoint is the ancestor in the tree where a connection was
 added or removed which may be arbitrarily far up the ancestor chain. From
 that you can figure out all the cases Boris is describing.

Cool. So maybe the DOM specification needs to be updated to have that
model and we should expose that as low-level hook to web developers.


-- 
https://annevankesteren.nl/



Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Elliott Sprehn
On Thu, May 7, 2015 at 10:24 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:
  In Gecko, yes.  The set of hooks Gecko builtin elements have today is,
  effectively:
 
  1)  This element used to not have a parent and now does.
  2)  This element has an ancestor that used to not have a parent and now
  does.
  3)  This element used to have a a parent and now does not.
  4)  This element has an ancestor that used to have a parent and
  now does not.

 So that is more granular than what Dominic said Chrome has. I wonder
 why there's a difference. Normally at the low-level things are pretty
 close (or have a difference like linked list vs array).


That actually seems pretty similar to what we have, ours is in the form of:

Node#insertedInto(Node insertionPoint)
Node#removedFrom(Node insertionPoint)

where insertionPoint is the ancestor in the tree where a connection was
added or removed which may be arbitrarily far up the ancestor chain. From
that you can figure out all the cases Boris is describing.

- E


Re: Permissions API vs local APIs

2015-05-07 Thread Miguel Garcia
Is there a timeline for the permission API in Mozilla?

On Wed, May 6, 2015 at 5:58 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 6, 2015 at 6:34 PM, Miguel Garcia migu...@chromium.org
 wrote:
  Notifications has it (as a property instead of a method which is a pain).

 Notifications is a special snowflake though since it has a
 requestPermission() method too which no other API that requires
 permission (e.g. geolocation, fullscreen, pointer lock) has today. The
 Notifications API predates a general Permissions API but is otherwise
 largely identical.


  I think that once the permissions API has shipped in both Mozilla and
 Chrome
  we should get future APIs to use it exclusively. Push seems to be a bit
  border line given the timeline so I think we should just implement in
 both
  places.

 Given that Doug seems okay with shipping this as part of the
 Permissions API (which won't wait until 2017, at least not the query()
 part) I'm led to the opposite conclusion.


 --
 https://annevankesteren.nl/



Re: Permissions API vs local APIs

2015-05-07 Thread Miguel Garcia
Agreed, I think we need a backwards compatible solution until the
permission API gets some traction but once Mozilla ships it I think new
APIs should just use the permission API.

On Wed, May 6, 2015 at 10:59 AM, Michael van Ouwerkerk 
mvanouwerk...@google.com wrote:



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

 On Wed, May 6, 2015 at 12:32 AM, Mike West mk...@google.com wrote:
  I agree with Jonas. Extending the permission API to give developers a
 single
  place to check with a single consistent style seems like the right way
 to
  go.

 Yet others at Google are pushing the expose them twice strategy...
 Perhaps because the Permissions API is not yet ready?


 Yes, we wanted to ensure this is in the Push API because that seems to
 have more implementation momentum from browser vendors than the Permissions
 API. We didn't want developers to do hacky things in the meantime. I agree
 that once the Permissions API has critical mass, that should be the single
 place for checking permissions.

 Regards,

 Michael




 --
 https://annevankesteren.nl/





Re: Permissions API vs local APIs

2015-05-07 Thread Miguel Garcia
Notifications has it (as a property instead of a method which is a pain).

I think that once the permissions API has shipped in both Mozilla and
Chrome we should get future APIs to use it exclusively. Push seems to be a
bit border line given the timeline so I think we should just implement in
both places.

On Wed, May 6, 2015 at 5:00 PM, Doug Turner do...@mozilla.com wrote:

 The way I would look at this is based on timeframe — if we’re not
 implementing the Permissions API until 2017 or something, i’d just leave
 the functionality in the PushAPI spec.  If the Permission API is right
 around the corner, I would remove it form the PushAPI spec.

 Do any other APIs have a permission check function in their interface?
 Geo doesn’t (which shares a similar permission model).





  On May 6, 2015, at 8:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
  On Wed, May 6, 2015 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote:
  I think Mozilla would be fine with taking the permission API as a
  dependency and implement that at the same time. Implementing the
  permission API should be fairly trivial for us.
 
  But we should verify this with the people actually working on the push
 API.
 
  On Wed, May 6, 2015 at 10:59 AM, Michael van Ouwerkerk
  mvanouwerk...@google.com wrote:
  Yes, we wanted to ensure this is in the Push API because that seems to
  have more implementation momentum from browser vendors than the
 Permissions
  API. We didn't want developers to do hacky things in the meantime. I
 agree
  that once the Permissions API has critical mass, that should be the
 single
  place for checking permissions.
 
  Martin, Doug?
 
 
  --
  https://annevankesteren.nl/




You update XMLHttpRequest has a bug

2015-05-07 Thread ????????
$(obj).load('***.php');) can't run well,because it make my web music lose  
voice.


test url:http://www.wuover.com

20254EA1@06F63601.969B4855
Description: Binary data


Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Anne van Kesteren
On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 In Gecko, yes.  The set of hooks Gecko builtin elements have today is,
 effectively:

 1)  This element used to not have a parent and now does.
 2)  This element has an ancestor that used to not have a parent and now
 does.
 3)  This element used to have a a parent and now does not.
 4)  This element has an ancestor that used to have a parent and
 now does not.

So that is more granular than what Dominic said Chrome has. I wonder
why there's a difference. Normally at the low-level things are pretty
close (or have a difference like linked list vs array).


-- 
https://annevankesteren.nl/



Re: Making ARIA and native HTML play better together

2015-05-07 Thread Patrick H. Lauke

On 07/05/2015 08:02, Steve Faulkner wrote:


On 7 May 2015 at 07:53, Bruce Lawson bru...@opera.com
mailto:bru...@opera.com wrote:

this makes sense, but (unless I'm inventing nonsense because I'm mad,
which is definitely possible), doesn't this describe the current
behaviour in many UAs anyway?


Currently ARIA does not do this stuff AFAIK. There is some limited
keyboard behaviour mapping for role=button in a few AT's.


And gesture mapping in certain touchscreen/mobile ATs too - particularly 
important, as any custom keyboard handling the dev may or may not have 
implemented wouldn't work there anyway, so AT attempt to understand 
widgets based on their roles a bit more and provide built-in swipe/tap 
gestures for certain constructs.


P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke



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

2015-05-07 Thread Anne van Kesteren
On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote:
 I'm saying:
 - Composed tree is related with CSS.
 - Node distribution should be considered as a part of style concept.

Right, I think Ryosuke and I simply disagree with that assessment. CSS
operates on the composed tree (and forms a render tree from it).
Events operate on the composed tree. Selection operates on the
composed tree (likely, we haven't discussed this much). Content can be
found within the composed tree (not just the light tree, see
composition). It's a lot more than just style.


-- 
https://annevankesteren.nl/



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

2015-05-07 Thread Elliott Sprehn
On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote:
  I'm saying:
  - Composed tree is related with CSS.
  - Node distribution should be considered as a part of style concept.

 Right, I think Ryosuke and I simply disagree with that assessment. CSS
 operates on the composed tree (and forms a render tree from it).
 Events operate on the composed tree. Selection operates on the
 composed tree (likely, we haven't discussed this much).


Selection operates on the render tree. The current selection API is
(completely) busted for modern apps, and a new one is needed that's based
around layout. Flexbox w/ order, positioned objects, distributions, grid,
none of them work with the DOM based API.

- E


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

2015-05-07 Thread Hayato Ito
Yeah, we, in Google, had several discussion about how the next *Selection
APIs* should be. However we don't have any concrete proposals yet.
We are aware that we need the new APIs because the existing APIs is not
suitable.

On Thu, May 7, 2015 at 3:10 PM Elliott Sprehn espr...@chromium.org wrote:

 On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote:
  I'm saying:
  - Composed tree is related with CSS.
  - Node distribution should be considered as a part of style concept.

 Right, I think Ryosuke and I simply disagree with that assessment. CSS
 operates on the composed tree (and forms a render tree from it).
 Events operate on the composed tree. Selection operates on the
 composed tree (likely, we haven't discussed this much).


 Selection operates on the render tree. The current selection API is
 (completely) busted for modern apps, and a new one is needed that's based
 around layout. Flexbox w/ order, positioned objects, distributions, grid,
 none of them work with the DOM based API.

 - E



Re: Custom Elements: Upgrade et al

2015-05-07 Thread Ryosuke Niwa

 On May 6, 2015, at 9:48 PM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Thu, May 7, 2015 at 12:23 AM, Ryosuke Niwa rn...@apple.com wrote:
 Are you suggesting that cloning my-button will create a new instance of 
 my-button by invoking its constructor?
 
 No, I'm saying there would be another primitive operation, similar to
 the extended structured cloning proposed elsewhere, to accomplish
 cloning without side effects.

Okay. Do you have any idea / proposal as to how that would look like?  I'm 
still not fully grasping what you're proposing to do when we close a custom 
element.

- R. Niwa




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

2015-05-07 Thread Ryosuke Niwa

 On May 6, 2015, at 11:10 PM, Elliott Sprehn espr...@chromium.org wrote:
 
 On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote:
  I'm saying:
  - Composed tree is related with CSS.
  - Node distribution should be considered as a part of style concept.
 
 Right, I think Ryosuke and I simply disagree with that assessment. CSS
 operates on the composed tree (and forms a render tree from it).
 Events operate on the composed tree. Selection operates on the
 composed tree (likely, we haven't discussed this much).
 
 Selection operates on the render tree. The current selection API is 
 (completely) busted for modern apps, and a new one is needed that's based 
 around layout. Flexbox w/ order, positioned objects, distributions, grid, 
 none of them work with the DOM based API.

Please state your presumptions like that before making a statement such as 
composed street is a style concept.

Now, even if selection were to operate on the CSS box tree, of which I will not 
express my opinion of, event path is still not a style concept.  If you're 
proposing to make it a style concept, then I just need to object to that.

- R. Niwa