[Bug 28579] [Shadow]:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28579 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED CC||hay...@chromium.org Resolution|--- |FIXED Assignee|dglaz...@chromium.org |hay...@chromium.org --- Comment #1 from Hayato Ito hay...@chromium.org --- Thanks! That's my intention. Fixed at: https://github.com/w3c/webcomponents/commit/936d85ba5948623451a5a415ca757457d24172c0 -- You are receiving this mail because: You are on the CC list for the bug.
Re: Inheritance Model for Shadow DOM Revisited
Thanks, let me update my understanding: - There is no use cases which shadow as function can't support, but content slot can support. - The purpose of the proposal is to remove an *extra* syntax. There is no other goals. - There is no reason to consider content slot proposal if we have a use case which this *extra* syntax can achieve. I'm also feeling that several topic are mixed in the proposal, Imperative APIs, Multiple Templates and content slot, which makes me hard to understand the goal of each. Can I assume that the proposal is trying to remove content select, not only from such a multiple templates, but also from everywhere? On Thu, Apr 30, 2015 at 4:18 PM Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 9:17 PM, Hayato Ito hay...@chromium.org wrote: Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which shadow as function can't support, but content slot can support. - there are use cases which shadow as function can support, but content slot can't support. I disagree. What shadow as function provides is an extra syntax by which authors can choose elements. That's not a use case. A use case is a solution for a concrete user scenario such as building a social network button. - shadow as function is more expressive than content slot Again, I disagree. - content slot is trying to achieve something by removing expressiveness from web developers, instead of trusting them. I still don't understand fully what the proposal is trying to achieve. I've never heard such a complain, content select is too expressive and easy to be misused. Please remove it, from web developers. I think any good APIs could be potentially wrongly used by a web developer. But that shouldn't be a reason that we can remove a expressive API from web developers who can use it correctly and get benefits from the expressiveness. Now let me make an analogous comparison between C++ and assembly language. - There is no use cases which assembly can't support, but C++ can support. - There are use cases which assembly can support, but C++ can't support. - Assembly language is more expressive than C++. - C++ is trying to achieve something by removing expressiveness from programmers, instead of trusting them. Does that mean we should all be coding in assembly? Certainly not. For a more relevant analogy, one could construct the entire document using JavaScript without using HTML at all since DOM API exposed to JavaScript can construct the set of trees which is a strict superset of what HTML tree building algorithm can generate. Yet, we don't see that happening even in the top tier Web apps just because DOM API is more expressive. The vast majority of Web apps still use plenty of templates and declarative formats to construct DOM for simplicity and clarity even though imperative alternatives are strictly more powerful. Why did we abandon XHTML2.0? It was certainly more expressive. Why not SGML? It's a lot more expressive than XML. You can re-define special character as you'd like. Because expressiveness is not necessary the most desirable characteristics of anything by itself. The shape of a solution we need depends on the kind of problems we're solving. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Apr 29, 2015, at 9:17 PM, Hayato Ito hay...@chromium.org wrote: Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which shadow as function can't support, but content slot can support. - there are use cases which shadow as function can support, but content slot can't support. I disagree. What shadow as function provides is an extra syntax by which authors can choose elements. That's not a use case. A use case is a solution for a concrete user scenario such as building a social network button. - shadow as function is more expressive than content slot Again, I disagree. - content slot is trying to achieve something by removing expressiveness from web developers, instead of trusting them. I still don't understand fully what the proposal is trying to achieve. I've never heard such a complain, content select is too expressive and easy to be misused. Please remove it, from web developers. I think any good APIs could be potentially wrongly used by a web developer. But that shouldn't be a reason that we can remove a expressive API from web developers who can use it correctly and get benefits from the expressiveness. Now let me make an analogous comparison between C++ and assembly language. - There is no use cases which assembly can't support, but C++ can support. - There are use cases which assembly can support, but C++ can't support. - Assembly language is more expressive than C++. - C++ is trying to achieve something by removing expressiveness from programmers, instead of trusting them. Does that mean we should all be coding in assembly? Certainly not. For a more relevant analogy, one could construct the entire document using JavaScript without using HTML at all since DOM API exposed to JavaScript can construct the set of trees which is a strict superset of what HTML tree building algorithm can generate. Yet, we don't see that happening even in the top tier Web apps just because DOM API is more expressive. The vast majority of Web apps still use plenty of templates and declarative formats to construct DOM for simplicity and clarity even though imperative alternatives are strictly more powerful. Why did we abandon XHTML2.0? It was certainly more expressive. Why not SGML? It's a lot more expressive than XML. You can re-define special character as you'd like. Because expressiveness is not necessary the most desirable characteristics of anything by itself. The shape of a solution we need depends on the kind of problems we're solving. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 1:47 AM, Hayato Ito hay...@chromium.org wrote: Thanks, let me update my understanding: - There is no use cases which shadow as function can't support, but content slot can support. - The purpose of the proposal is to remove an *extra* syntax. There is no other goals. - There is no reason to consider content slot proposal if we have a use case which this *extra* syntax can achieve. That's not at all what I'm saying. As far as we (Apple) are concerned, shadow as a function as a mere proposal just as much as our content slot is a proposal since you've never convinced us that shadow as a function is a good solution for shadow DOM inheritance. Both proposals should be evaluated based on concrete use cases. And even if there are use cases for which a given proposal (either shadow as a function or named slot) doesn't adequately address, there are multiple options to consider: 1. Reject the use case because it's not important 2. Defer the use case for future extensions 3. Modify the proposal as needed 4. Reject the proposal because above options are not viable I'm also feeling that several topic are mixed in the proposal, Imperative APIs, Multiple Templates and content slot, which makes me hard to understand the goal of each. Can I assume that the proposal is trying to remove content select, not only from such a multiple templates, but also from everywhere? As I understand the situation, the last F2F's resolution is to remove content select entirely. That's not a proposal but rather the tentative consensus of the working group. If you'd like, we can initiate a formal CfC process to reach a consensus on this matter although I highly doubt the outcome will be different given the attendees of the meeting. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote: I’m writing any kind of component that creates a shadow DOM, I’d just keep references to all my insertion points instead of querying them each time I need to distribute nodes. I guess that is true if you know you're not going to modify your insertion points or shadow tree. I would be happy to update the gist to exclude this parameter and instead use something like shadow.querySelector(content) somewhere. It doesn't seem important. Another important use case to consider is adding insertion points given the list of nodes to distribute. For example, you may want to “wrap” each node you distribute by an element. That requires the component author to know the number of nodes to distribute upfront and then dynamically create as many insertion points as needed. That seems doable. So you mean that we'd turn distributionList into a subtree? Consider table-chart component which coverts a table element into a chart with each column represented as a line graph in the chart. The user of this component will wrap a regular table element with table-chart element to construct a shadow DOM: ```html table-chart table ... td data-value=“253” data-delta=5253 ± 5/td ... /table /table-chart ``` Now, suppose I wanted to show a tooltip with the value in the chart. One obvious way to accomplish this would be distributing the td corresponding to the currently selected point into the tooltip. But this requires us allowing non-direct child nodes to be distributed. So if we did that, distributionList would become distributionRoot. And whenever add() is invoked any node that is not a descendant of distributionRoot or is a descendant of a node already add()'d would throw? It seems that would get us a bit more complexity than the current algorithm... The other thing I would like to explore is what an API would look like that does the subclassing as well. For the slot approach, we can model the act of filling a slot as if attaching a shadow root to the slot and the slot content going into the shadow DOM for both content distribution and filling of slots by subclasses. Now we can do this in either of the following two strategies: 1. Superclass wants to see a list of slot contents from subclasses. 2. Each subclass overrides previous distribution done by superclass by inspecting insertion points in the shadow DOM and modifying them as needed. With the existence of closed shadow trees, it seems like you'd want to allow for the superclass to not have to share its details with the subclass. -- https://annevankesteren.nl/
Re: Web Storage Rec errata?
Hi, On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com wrote: On 4/21/15 5:39 AM, Kostiainen, Anssi wrote: Hi, Is there a plan to publish an errata to sync the Web Storage Rec [1] with the latest? I counted 8 commits cherry picked into the Editor's Draft since Rec [2]. If no errata publication is planned, I'd expect the Rec to clearly indicate its status. Re the priority of this issue, is this mostly a truth and beauty process-type request or is this issue actually creating a problem(s)? (If the later, I would appreciate it, if you would please provide some additional context.) It was creating problems. Our QA was confused which spec was the authoritative one, and wrote tests (additional ones, on top of the w-p-t tests) against the Rec spec. These tests failed since Blink is compliant with the latest, not the Rec. More context at: https://crosswalk-project.org/jira/browse/XWALK-3527 The main thing blocking the publication of errata is a commitment from someone to actually do the work. I also think Ian's automatic push of commits from the WHATWG version of Web Storage to [2] was stopped a long time ago so there could be additional changes to be considered, and the totality of changes could include normative changes. Did you check for these later changes? No, I just observed the ED has evolved since the Rec publication. There may be additional changes in the LS that haven't been picked up to the ED. If you, or anyone else, would like to help with this effort, that would be great. (If it would be helpful, we could create a new webstorage repo under github/w3c/, work on the errata in that repo and redirect the CVS-backed errata document to the new repo.) I can ask if our QA would be interested in contributing. Personally, I think putting errata in a separate file - as opposed to putting changes directly into [1] - is mostly make work and fails the principle of least surprise. However, I think the consortium's various processes preclude us from doing what I consider is the right thing. The best way would be to ensure TR reflects what is broadly implemented. If that does not work out due to process reasons, then a visible note at the top pointing to the authoritative spec would be the second best option. That failing, the errata. Thanks, -Anssi [1]http://www.w3.org/TR/webstorage/ [2]http://dev.w3.org/cvsweb/html5/webstorage/Overview.html
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Thu, Apr 30, 2015 at 2:30 PM, Domenic Denicola d...@domenic.me wrote: Can someone point me to the part of the spec that is problematic? That is, where is the line that says UAs may run this algorithm at any time? I am not sure what to Ctrl+F for. At the end of section 3.4 it states If any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result. which basically means you can't make use of a dirty tree. Secondly, could someone produce a code snippet that would cause such interop problems, given the current spec? var x = new Event(eventType) someNodeThatIsDistributed.addEventListener(eventType, e = console.log(e.path)) someNodeThatIsDistributed.dispatchEvent(ev); Finally, assuming we have such an example, would there be a way to tighten the spec language such that we don't need to specify e.g. when style recalculation happens, but instead specify constraints? Like offsetTop must always reflect the redistributions or something. That is what the specification currently does and what prevents us from defining an imperative API. For an imperative API it is imperative (mahaha) that we get the timing with respect to tasks right. (Or as per my proposal, leave timing up to developers.) -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Thu, Apr 30, 2015 at 3:05 PM, Hayato Ito hay...@chromium.org wrote: That's the exactly intended behavior in the current spec. The timing of distribution is not observable. Right, but you can synchronously observe whether something is distributed. The combination of those two things coupled with us not wanting to introduce new synchronous mutation observers is what creates problems for an imperative API. So if we want an imperative API we need to make a tradeoff. Do we care about offsetTop et al or do we care about microtask-based mutation observers? I'm inclined to think we care more about the latter, but the gist I put forward takes a position on neither and leaves it up to web developers when they want to distribute (if at all). -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Tue, Apr 28, 2015 at 12:31 AM, Hayato Ito hay...@chromium.org wrote: I think there are a lot of user operations where distribution must be updated before returning the meaningful result synchronously. Unless distribution result is correctly updated, users would take the dirty result. For example: - element.offsetWidth: Style resolution requires distribution. We must update distribution, if it's dirty, before calculation offsetWidth synchronously. - event dispatching: event path requires distribution because it needs a composed tree. Can the current HTML/DOM specs are rich enough to explain the timing when the imperative APIs should be run in these cases? The imperative API I proposed leaves the timing up to whenever distribute() is invoked by the developer. Currently at best that can be done from mutation observers. And I think that's fine for v1. element.offsetWidth et al are bad APIs that we should not accommodate for. The results they return will be deterministic, but they should not cause further side effects such as distribution and therefore the results might appear incorrect I suppose depending on what point of view you have. We discussed this point at the meeting. For me, the imperative APIs for distribution sounds very similar to the imperative APIs for style resolution. The difficulties of both problems might be similar. Only if you insist on coupling them are they similar. And only if you insist on semantics that are identical to content select. This is the very reason why content select is not acceptable as it would require solving that problem. Whereas an imperative API free of the warts of element.offsetWidth would not have to. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Tue, Apr 28, 2015 at 5:48 AM, 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. Agreed. Dimitri saying these are largely orthogonal makes me hopeful, but I would prefer to see a strawman API for it before fully committing to the distribute() design on my gist. Mozilla tried to solve this problem with XBL, and they seem to think what they have isn't really great. Actually, I think that we found we needed something. What was originally in the Shadow DOM specification was sufficient for our needs I believe, but got removed... In that regard, the first approach w/o distribution has an advantage of letting Web developer experiment with the bare minimum and try out which distribution algorithms and mechanisms work best. Except that you don't have a clear story for how to move to a declarative syntax later on. And redistribution seems somewhat essential as it mostly depends on where you put your host element whether you're subject to it. Making it immaterial where you put your host element seems important. -- https://annevankesteren.nl/
Re: Inheritance Model for Shadow DOM Revisited
On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? It'd be great to have something like this available. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Thu, Apr 30, 2015 at 2:44 PM, Domenic Denicola d...@domenic.me wrote: From: Anne van Kesteren ann...@annevk.nl var x = new Event(eventType) someNodeThatIsDistributed.addEventListener(eventType, e = console.log(e.path)) someNodeThatIsDistributed.dispatchEvent(ev); Can you explain in a bit more detail why this causes interop problems? What browsers would give different results for this code? What would those results be? This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. And that's not necessarily problematic, but it is problematic if you want to do an imperative API as I tried to explain in the bit you did not quote back. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Thu, Apr 30, 2015 at 9:54 PM Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 30, 2015 at 2:44 PM, Domenic Denicola d...@domenic.me wrote: From: Anne van Kesteren ann...@annevk.nl var x = new Event(eventType) someNodeThatIsDistributed.addEventListener(eventType, e = console.log(e.path)) someNodeThatIsDistributed.dispatchEvent(ev); Can you explain in a bit more detail why this causes interop problems? What browsers would give different results for this code? What would those results be? This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. That's the exactly intended behavior in the current spec. The timing of distribution is not observable. That enables UA to optimize the distribution calc. We can delay the calculation of the distribution as possible as we can. We don't need to calc distribution every time when a mutation occurs. If you find any interop issue in the current spec about distribution, please file a bug with a concrete example. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 30, 2015, at 5:12 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote: The other thing I would like to explore is what an API would look like that does the subclassing as well. For the slot approach, we can model the act of filling a slot as if attaching a shadow root to the slot and the slot content going into the shadow DOM for both content distribution and filling of slots by subclasses. Now we can do this in either of the following two strategies: 1. Superclass wants to see a list of slot contents from subclasses. 2. Each subclass overrides previous distribution done by superclass by inspecting insertion points in the shadow DOM and modifying them as needed. With the existence of closed shadow trees, it seems like you'd want to allow for the superclass to not have to share its details with the subclass. Neither approach needs to expose internals of superclass' shadow DOM. In 1, what superclass seems is a list of proxies of slot contents subclasses provided. In 2, what subclass sees is a list of wrappers of overridable insertion points superclass defined. I can't think of an inheritance model in any programming language in which overridable pieces are unknown to subclasses. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 30, 2015, at 5:12 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote: I’m writing any kind of component that creates a shadow DOM, I’d just keep references to all my insertion points instead of querying them each time I need to distribute nodes. I guess that is true if you know you're not going to modify your insertion points or shadow tree. I would be happy to update the gist to exclude this parameter and instead use something like shadow.querySelector(content) somewhere. It doesn't seem important. FYI, I've summarized everything we've discussed so far in https://gist.github.com/rniwa/2f14588926e1a11c65d3. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote: This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. And that's not necessarily problematic, OK. So the claim that the current spec cannot be interoperably implemented is false? (Not that I am a huge fan of content select, but I want to make sure we have our arguments against it lined up and on solid footing.) but it is problematic if you want to do an imperative API as I tried to explain in the bit you did not quote back. Sure, let's dig in to that claim now. Again, this is mostly clarifying probing. Let's say we had an imperative API. As far as I understand from the gist, one of the problems is when do we invoke the distributedCallback. If we use MutationObserve time, then inconsistent states can be observed, etc. Why can't we say that this distributedCallback must be invoked at the same time that the current spec updates the distribution result? Since it sounds like there is no interop problem with this timing, I don't understand why this wouldn't be an option. There will be an interop problem. Consider a following example: ```js someNode = ~ myButton.appendChild(someNode); // (1) absolutelyPositionElement.offsetTop; // (2) ``` Now suppose absolutelyPositionElement.offsetTop is a some element that's in a disjoint subtree of the document. Heck, it could even in a separate iframe. In some UAs, (2) will trigger style resolution and update of the layout. Because UAs can't tell redistribution of myButton can affect (2), such UAs will update the distribution per spec text that says the distribution result must be updated before any _use_ of the distribution result. Yet in other UAs, `offsetTop` may have been cached and UA might be smart enough to detect that (1) doesn't affect the result of `absolutelyPositionElement.offsetTop` because they're in a different parts of the tree and they're independent for the purpose of style resolution and layout. In such UAs, (2) does not trigger redistribution because it does not use the distribution result in order to compute this value. In general, there are thousands of other DOM and CSS OM APIs that may or may not _use_ the distribution result depending on implementations. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? We object on the basis that shadow as a function is fundamentally backwards way of doing the inheritance. If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView. It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView. That's has-a relationship which is appropriate for composition. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa rn...@apple.com wrote: ... The return value of (2) is the same in either case. There is no observable difference. No interop issue. Please file a bug for the spec with a concrete example if you can find a observable difference due to the lazy-evaluation of the distribution. The problem isn't so much that the current shadow DOM specification has an interop issue because what we're talking here, as the thread title clearly communicates, is the imperative API for node distribution, which doesn't exist in the current specification. In particular, invoking user code at the timing specified in section 3.4 which states if any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result introduces a new interoperability issue because before any use of the distribution result is implementation dependent. e.g. element.offsetTop may or not may use the distribution result depending on UA. Furthermore, it's undesirable to precisely spec this since doing so will impose a serious limitation on what UAs could optimize in the future. element.offsetTop must use the distribution result, there's no way to know what your style is without computing your distribution. This isn't any different than getComputedStyle(...).color needing to flush style, or getBoundingClientRect() needing to flush layout. Distribution is about computing who your parent and siblings are in the box tree, and where your should inherit your style from. Doing it lazy is not going to be any worse in terms of interop than defining new properties that depend on style. - E
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 30, 2015, at 9:25 PM, Elliott Sprehn espr...@chromium.org wrote: On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa rn...@apple.com wrote: ... The return value of (2) is the same in either case. There is no observable difference. No interop issue. Please file a bug for the spec with a concrete example if you can find a observable difference due to the lazy-evaluation of the distribution. The problem isn't so much that the current shadow DOM specification has an interop issue because what we're talking here, as the thread title clearly communicates, is the imperative API for node distribution, which doesn't exist in the current specification. In particular, invoking user code at the timing specified in section 3.4 which states if any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result introduces a new interoperability issue because before any use of the distribution result is implementation dependent. e.g. element.offsetTop may or not may use the distribution result depending on UA. Furthermore, it's undesirable to precisely spec this since doing so will impose a serious limitation on what UAs could optimize in the future. element.offsetTop must use the distribution result, there's no way to know what your style is without computing your distribution. This isn't any different than getComputedStyle(...).color needing to flush style, or getBoundingClientRect() needing to flush layout. That is true only if the distribution of a given node can affect the style of element. There are cases in which UAs can deduce that such is not the case and optimize the style recalculation away. e.g. two elements belonging two different documents. Another example will be element.isContentEditable. Under certain circumstances WebKit needs to resolve styles in order to determine the value of this function which, then, uses the distribution result. Distribution is about computing who your parent and siblings are in the box tree, and where your should inherit your style from. Doing it lazy is not going to be any worse in terms of interop than defining new properties that depend on style. The problem is that different engines have different mechanism to deduce style dependencies between elements. - R. Niwa
Re: :host pseudo-class
On Thu, Apr 30, 2015 at 10:25 PM, Anne van Kesteren ann...@annevk.nl
wrote:
...
My problem is not with the ability to address the host element, but by
addressing it through a pseudo-class, which has so far only been used
for matching elements in the tree that have a particular internal
slot.
I don't understand what distinction you're trying to draw here. Can
you elaborate?
A pseudo-class selector is like a class selector. You match an element
based on a particular trait it has. Your suggestion for :host()
however is to make it match an element that cannot otherwise be
matched. That's vastly different semantics
That's still true if you use ::host, what is the thing on the left hand
side the ::host lives on? I'm not aware of any pseudo element that's not
connected to another element such that you couldn't write {thing}::pseudo.
- E
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 30, 2015, at 9:01 PM, Hayato Ito hay...@chromium.org wrote: Thanks, however, we're talking about https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0442.html. Ah, I think there was some miscommunication there. I don't think anyone is claiming that the current spec results in interop issues. The currently spec'ed timing is only problematic when we try to invoke an author-defined callback at that moment. If we never added an imperative API or an imperative API we add don't invoke user code at the currently spec'ed timing, we don't have any interop problem. - R. Niwa
Re: :host pseudo-class
On Fri, May 1, 2015 at 2:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Pseudo-elements are things that aren't DOM elements, but are created by Selectors for the purpose of CSS to act like elements. That's not true for e.g. ::-webkit-slider-thumb as I already indicated. Sure it is. input type=range has no children, and the shadow tree is sealed, so the fact that a shadow tree even exists is hidden from DOM. As far as CSS is capable of discerning, there is no thumb element, so the pseudo-element makes sense. That seems rather arbitrary. To the browser it is a DOM element and to CSS it is too. E.g. at the global level CSS will have to reason about what it means to override the element's existing styles. My problem is not with the ability to address the host element, but by addressing it through a pseudo-class, which has so far only been used for matching elements in the tree that have a particular internal slot. I don't understand what distinction you're trying to draw here. Can you elaborate? A pseudo-class selector is like a class selector. You match an element based on a particular trait it has. Your suggestion for :host() however is to make it match an element that cannot otherwise be matched. That's vastly different semantics -- https://annevankesteren.nl/
Re: :host pseudo-class
On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn espr...@chromium.org wrote:
That's still true if you use ::host, what is the thing on the left hand side
the ::host lives on? I'm not aware of any pseudo element that's not
connected to another element such that you couldn't write {thing}::pseudo.
::selection? But maybe you're right and the whole
pseudo-class/pseudo-element distinction is rather meaningless. But at
least pseudo-class til date made some sense.
--
https://annevankesteren.nl/
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 2:44 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 2:29 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? We object on the basis that shadow as a function is fundamentally backwards way of doing the inheritance. If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView. It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView. That's has-a relationship which is appropriate for composition. Is there really a hard need for inheritance over composition? Won't composition ability + an imperative API that allows you to properly delegate to the stuff you contain be just fine for a v1? Per resolutions in F2F last Friday, this is a discussion for v2 since we're definitely not adding multiple generations of shadow DOM in v1. However, we should have a sound plan for inheritance in v2 and make sure our imperative API is forward compatible with it. So the goal here is to come up with some plan for inheritance so that we can be confident that our inheritance API is not completely busted. Sorry, I meant to say our *imperative* API is not completely busted. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote: This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. And that's not necessarily problematic, OK. So the claim that the current spec cannot be interoperably implemented is false? (Not that I am a huge fan of content select, but I want to make sure we have our arguments against it lined up and on solid footing.) but it is problematic if you want to do an imperative API as I tried to explain in the bit you did not quote back. Sure, let's dig in to that claim now. Again, this is mostly clarifying probing. Let's say we had an imperative API. As far as I understand from the gist, one of the problems is when do we invoke the distributedCallback. If we use MutationObserve time, then inconsistent states can be observed, etc. Why can't we say that this distributedCallback must be invoked at the same time that the current spec updates the distribution result? Since it sounds like there is no interop problem with this timing, I don't understand why this wouldn't be an option. There will be an interop problem. Consider a following example: The return value of (2) is the same in either case. There is no observable difference. No interop issue. Please file a bug for the spec with a concrete example if you can find a observable difference due to the lazy-evaluation of the distribution. ```js someNode = ~ myButton.appendChild(someNode); // (1) absolutelyPositionElement.offsetTop; // (2) ``` Now suppose absolutelyPositionElement.offsetTop is a some element that's in a disjoint subtree of the document. Heck, it could even in a separate iframe. In some UAs, (2) will trigger style resolution and update of the layout. Because UAs can't tell redistribution of myButton can affect (2), such UAs will update the distribution per spec text that says the distribution result must be updated before any _use_ of the distribution result. Yet in other UAs, `offsetTop` may have been cached and UA might be smart enough to detect that (1) doesn't affect the result of `absolutelyPositionElement.offsetTop` because they're in a different parts of the tree and they're independent for the purpose of style resolution and layout. In such UAs, (2) does not trigger redistribution because it does not use the distribution result in order to compute this value. In general, there are thousands of other DOM and CSS OM APIs that may or may not _use_ the distribution result depending on implementations. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 30, 2015, at 8:17 PM, Hayato Ito hay...@chromium.org wrote: On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote: This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. And that's not necessarily problematic, OK. So the claim that the current spec cannot be interoperably implemented is false? (Not that I am a huge fan of content select, but I want to make sure we have our arguments against it lined up and on solid footing.) but it is problematic if you want to do an imperative API as I tried to explain in the bit you did not quote back. Sure, let's dig in to that claim now. Again, this is mostly clarifying probing. Let's say we had an imperative API. As far as I understand from the gist, one of the problems is when do we invoke the distributedCallback. If we use MutationObserve time, then inconsistent states can be observed, etc. Why can't we say that this distributedCallback must be invoked at the same time that the current spec updates the distribution result? Since it sounds like there is no interop problem with this timing, I don't understand why this wouldn't be an option. There will be an interop problem. Consider a following example: The return value of (2) is the same in either case. There is no observable difference. No interop issue. Please file a bug for the spec with a concrete example if you can find a observable difference due to the lazy-evaluation of the distribution. The problem isn't so much that the current shadow DOM specification has an interop issue because what we're talking here, as the thread title clearly communicates, is the imperative API for node distribution, which doesn't exist in the current specification. In particular, invoking user code at the timing specified in section 3.4 which states if any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result introduces a new interoperability issue because before any use of the distribution result is implementation dependent. e.g. element.offsetTop may or not may use the distribution result depending on UA. Furthermore, it's undesirable to precisely spec this since doing so will impose a serious limitation on what UAs could optimize in the future. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Thanks, however, we're talking about https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0442.html. On Fri, May 1, 2015 at 12:57 PM Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 8:17 PM, Hayato Ito hay...@chromium.org wrote: On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote: This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. And that's not necessarily problematic, OK. So the claim that the current spec cannot be interoperably implemented is false? (Not that I am a huge fan of content select, but I want to make sure we have our arguments against it lined up and on solid footing.) but it is problematic if you want to do an imperative API as I tried to explain in the bit you did not quote back. Sure, let's dig in to that claim now. Again, this is mostly clarifying probing. Let's say we had an imperative API. As far as I understand from the gist, one of the problems is when do we invoke the distributedCallback. If we use MutationObserve time, then inconsistent states can be observed, etc. Why can't we say that this distributedCallback must be invoked at the same time that the current spec updates the distribution result? Since it sounds like there is no interop problem with this timing, I don't understand why this wouldn't be an option. There will be an interop problem. Consider a following example: The return value of (2) is the same in either case. There is no observable difference. No interop issue. Please file a bug for the spec with a concrete example if you can find a observable difference due to the lazy-evaluation of the distribution. The problem isn't so much that the current shadow DOM specification has an interop issue because what we're talking here, as the thread title clearly communicates, is the imperative API for node distribution, which doesn't exist in the current specification. In particular, invoking user code at the timing specified in section 3.4 which states if any condition which affects the distribution result changes, the distribution result must be updated before any use of the distribution result introduces a new interoperability issue because before any use of the distribution result is implementation dependent. e.g. element.offsetTop may or not may use the distribution result depending on UA. Furthermore, it's undesirable to precisely spec this since doing so will impose a serious limitation on what UAs could optimize in the future. - R. Niwa
Re: :host pseudo-class
On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Pseudo-elements are things that aren't DOM elements, but are created by Selectors for the purpose of CSS to act like elements. That's not true for e.g. ::-webkit-slider-thumb as I already indicated. Sure it is. input type=range has no children, and the shadow tree is sealed, so the fact that a shadow tree even exists is hidden from DOM. As far as CSS is capable of discerning, there is no thumb element, so the pseudo-element makes sense. The host element is a real DOM element. It just has special selection behavior from inside its own shadow root, for practical reasons: there are good use-cases for being able to style your host, but also a lot for *not* doing so, and so mixing the host into the normal set of elements leads to a large risk of accidentally selecting the host. This is particularly true for things like class selectors; since the *user* of the component is the one that controls what classes/etc are set on the host element, it's very plausible that a class used inside the shadow root for internal purposes could accidentally collide with one used by the outer page for something completely different, and cause unintentional styling issues. Making the host element present in the shadow tree, but featureless save for the :host and :host-context() pseudo-classes, was the compromise that satisfies all of the use-cases adequately. My problem is not with the ability to address the host element, but by addressing it through a pseudo-class, which has so far only been used for matching elements in the tree that have a particular internal slot. I don't understand what distinction you're trying to draw here. Can you elaborate? It's possible we could change how we define the concept of pseudo-element so that it can sometimes refer to real elements that just aren't ordinarily accessible, but I'm not sure that's necessary or desirable at the moment. Well, it would for instance open up the possibility of using :host in the light tree to match elements that are host elements. That's just a naming-collision thing. We can come up with a different name for either has a shadow tree or is the host element of the current shadow tree; it's just that right now, the latter has claimed the name :host. I certainly don't want to create both a pseudo-class and pseudo-element with the same name if I can help it (or at least, not ones that refer to similar things); the distinction between pseudo-classes and pseudo-elements in most author's minds is already tenuous. (Definitely not helped by the legacy :before/etc syntax.) ~TJ
Re: Inheritance Model for Shadow DOM Revisited
On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? We object on the basis that shadow as a function is fundamentally backwards way of doing the inheritance. If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView. It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView. That's has-a relationship which is appropriate for composition. - R. Niwa Is there really a hard need for inheritance over composition? Won't composition ability + an imperative API that allows you to properly delegate to the stuff you contain be just fine for a v1? -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? To start off, I can think of three major ways by which subclass wants to interact with its superclass: 1. Replace what superclass shows entirely by its own content - e.g. grab the device context and draw everything by yourself. 2. Override parts of superclass' content - e.g. subclass overrides virtual functions superclass provided to draw parts of the component/view. 3. Fill holes superclass provided - e.g. subclass implements abstract virtual functions superclass defined to delegate the work. - R. Niwa
[Bug 28587] New: [Shadow]: Inheritance Model for Shadow DOM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28587 Bug ID: 28587 Summary: [Shadow]: Inheritance Model for Shadow DOM Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: hay...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 Let me file a bug so that we can track the progress about Inheritance Model for Shadow DOM. See the relevant discussion: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0371.html -- You are receiving this mail because: You are on the CC list for the bug.
Re: Inheritance Model for Shadow DOM Revisited
Filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28587. On Fri, May 1, 2015 at 1:16 AM Hayato Ito hay...@chromium.org wrote: Thanks Anne, I agree that it would be great to have something like this. I think it's too early for us to judge something because we don't have a well defined Imperative API as of now. Let's re-open this issue after we can see how an Imperative API goes. I'll file a bug for the spec about this inheritance challenge so that we can continue the discussion in the bugzilla. On Thu, Apr 30, 2015 at 8:43 PM Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? It'd be great to have something like this available. -- https://annevankesteren.nl/
