Re: [Custom Elements] Not requiring hyphens in names.
On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren wrote: > On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote: > > I really believe that we should be allowed to name our elements with any > > name we wish, and that they should override native elements (that is > future > > proof), and that overriding should be on some type of encapsulated basis > > (for example, override within a shadow root and it won't affect other > code > > outside the shadow root). > > I don't think anyone disagrees with that in principle, but in practice > that would require refactoring huge amounts of code which will > basically not happen anytime soon. Better to iterate in smaller steps. > The implied key point here is that we can relax restrictions in the future, but it's difficult-to-impossible to tighten restrictions. > > -- > https://annevankesteren.nl/ > >
Re: Callback when an event handler has been added to a custom element
On Fri, Nov 6, 2015 at 12:44 PM, Olli Pettay wrote: > On 11/06/2015 09:28 PM, Justin Fagnani wrote: > >> You can also override addEventListener/removeEventListener on your >> element. My concern with that, and possibly an event listener change >> callback, is >> that it only works reliably for non-bubbling events. >> > How even with those? One could just add capturing event listener higher up > in the tree. > Good point. I forgot that capturing works with non-bubbling events :( > You need to override addEventListener on EventTarget, and also relevant > onfoo EventHandler setters on Window and Document and *Element prototypes, > but unfortunately even that doesn't catch onfoo content attributes ( onclick="doSomething">). But one could use MutationObserver then to > observe changes to DOM. > > > -Olli > > > >> On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead < >> travis.leith...@microsoft.com <mailto:travis.leith...@microsoft.com>> >> wrote: >> >> Interesting. Alternatively, you can add .onwhatever handlers, as well >> as define your own overload of addEventListener (which will be called >> instead of the EventTarget.addEventListener method). That way you can >> capture all attempts at setting events on your element. >> >> -Original Message- >> From: Mitar [mailto:mmi...@gmail.com <mailto:mmi...@gmail.com>] >> Sent: Thursday, November 5, 2015 4:05 PM >> To: public-webapps > public-webapps@w3.org>> >> Subject: Callback when an event handler has been added to a custom >> element >> >> Hi! >> >> We are using message ports to communicate with our logic and are >> wrapping the API into a custom element. The issue is that we would like to >> call >> start on a message port only after user has registered an event >> handler on the custom element instance. But it seems there is no way to get >> a >> callback when an event handler is added. >> >> So I am suggesting that there should be a callback every time an >> event listener is added to a custom element (and possibly one when removed). >> >> >> Mitar >> >> -- >> http://mitar.tnode.com/ >> https://twitter.com/mitar_m >> >> >> >
Re: Callback when an event handler has been added to a custom element
You can also override addEventListener/removeEventListener on your element. My concern with that, and possibly an event listener change callback, is that it only works reliably for non-bubbling events. On Thu, Nov 5, 2015 at 4:16 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Interesting. Alternatively, you can add .onwhatever handlers, as well as > define your own overload of addEventListener (which will be called instead > of the EventTarget.addEventListener method). That way you can capture all > attempts at setting events on your element. > > -Original Message- > From: Mitar [mailto:mmi...@gmail.com] > Sent: Thursday, November 5, 2015 4:05 PM > To: public-webapps > Subject: Callback when an event handler has been added to a custom element > > Hi! > > We are using message ports to communicate with our logic and are wrapping > the API into a custom element. The issue is that we would like to call > start on a message port only after user has registered an event handler on > the custom element instance. But it seems there is no way to get a callback > when an event handler is added. > > So I am suggesting that there should be a callback every time an event > listener is added to a custom element (and possibly one when removed). > > > Mitar > > -- > http://mitar.tnode.com/ > https://twitter.com/mitar_m > >
Re: Custom Elements: is=""
We also have an extension of form which collects values from both native and custom inputs. On Thu, Jun 11, 2015 at 1:41 PM, Joshua Peek wrote: > GitHub has been using tag extensions in a few places for progressive > enhancement. Form and button elements have been the most useful things > to extend the behavior of. "is=" syntax aside, I do agree extending > complex native element prototypes in general has alot of associated > undefined behavior. If "is=" is going to be dropped, we'll probably > revert back to annotating these elements with special class names or > data- attributes and avoid custom elements for these use cases. > > On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall wrote: > > > > On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren > wrote: > >> > >> On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall > >> wrote: > >> > - In the time between v1 and v2 (however long that ends up being) we > are > >> > left without any way to solve this problem, assuming we don't come up > >> > with > >> > something else for v1. If developers start using custom elements where > >> > they > >> > would previously have used a native element, this could well result > in a > >> > regression in accessibility for the web as a whole for this period, > and > >> > we > >> > will be stuck with the legacy of code written during this period for > >> > much > >> > longer as well. > >> > >> I don't see how it is a regression compared to the current situation. > > > > > > Exactly: this describes the current situation, which I think is > > unsatisfactory. > > > >> > - I realise that to some extent developers already aren't using native > >> > elements, in part because of the styling issues we've discussed which > >> > also > >> > affect is=. My concern here is that custom elements will further > >> > legitimise > >> > this habit, which we've been making some recent progress in changing - > >> > we > >> > stand to backslide on that effort. Having is= would allow us to roll > it > >> > into > >> > the "use native elements where possible" message rather than diluting > it > >> > with "unless you're using a custom element in which case here's a > >> > checklist > >> > which you're not going to look at of everything it should do" until we > >> > come > >> > up with an alternative. > >> > >> Most examples of custom elements to date are not actually with is="", > >> simply because custom tag names are much more appealing. The > >> ergonomics don't back up the message. > > > > > > Polymer have a whole suite of elements which use is=: > > https://elements.polymer-project.org/browse?package=gold-elements > > > > When you refer to "ergonomics", are you talking purely about the syntax? > Or > > about the set of issues involved in using native elements compared to > (lower > > case c) custom elements: essentially, whether or not you're ceding some > > control over styling and behaviour to the browser? > > > >> > - v1 sets the stage for people to develop habits and expectations > about > >> > how > >> > custom elements work. New features tend to be slowly adopted, by both > >> > browser vendors and (partly as a consequence) developers, so even if > we > >> > do > >> > come up with something for v2, it will be even longer before it > becomes > >> > mainstream (and as I mentioned earlier we will still be stuck with > code > >> > written to v1 for much longer again). > >> > >> I don't see how it will be longer. is="" is not getting acceptance > >> as-is. So all this would result in is not getting custom elements > >> across browsers until v2 is done. > > > > > > I think Dimitri responded to this better than I could. > > > >> > >> > Here's where we differ, because: > >> > - I don't think it's a wart. I've given this a great deal of thought > and > >> > I > >> > keep ending up back at the current syntax when I try to think of > >> > reasonable > >> > alternatives, even assuming we could magically fix all the > >> > implementation > >> > issues with any alternative proposal. > >> > >> I think if we figured out how the behavior of current elements is > >> composed and how to address the styling problem we'd be much closer to > >> an agreement. And I think everyone agrees those need to be solved, so > >> I'm a bit lost as to why we don't focus on those. > > > > > > I agree that those problems need to be solved (in particular, the styling > > issue also comes into play when using is=), but I think that these are > > multiple pieces of the same puzzle. > > > > The primitives are critical for creating novel types of elements, which > > won't be able to benefit from type extensions in any case. Styling is > > critical for getting people to use native elements with or without type > > extensions. > > > > Allowing developers to extend native types means that users benefit from > not > > relying on custom element developers who just want to create a button > with > > some fancy rendering (beyond what can be achieved using CSS alone), or > > custom behaviour, r
Re: Custom Elements: is=""
On Jun 9, 2015 8:45 AM, "Dimitri Glazkov" wrote: > > On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren wrote: >> >> >> > - v1 sets the stage for people to develop habits and expectations about how >> > custom elements work. New features tend to be slowly adopted, by both >> > browser vendors and (partly as a consequence) developers, so even if we do >> > come up with something for v2, it will be even longer before it becomes >> > mainstream (and as I mentioned earlier we will still be stuck with code >> > written to v1 for much longer again). >> >> I don't see how it will be longer. is="" is not getting acceptance >> as-is. So all this would result in is not getting custom elements >> across browsers until v2 is done. > > > I sort of assumes that the reason for this discussion is to get everyone on the same page regarding type extension and hope to arrive at better acceptance. > > Arguing that something isn't getting acceptance when the purpose of discussion is attempting to gain the said acceptance seems a bit circular. > > Other than that, please do continue this conversation! :) I'll also note that a large fraction of Polymer elements and Polymer using pages, thus a large fraction of existing custom elements and use, uses is=, via and
Re: Custom Elements: is=""
And I'm still concerned that removing is= would severely harm the cases where you need access to special parsing behavior like and
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola wrote: > In case it wasn't clear, named slots vs. tag names is purely a bikeshed > color (but an important one, in the "syntax is UI" sense). None of the > details of how the proposal works change at all. > They're not equivalent, because any element can have the right content-slot value, but with tag names, only one (or maybe N) names would be supported. > If you already knew that but still prefer content-slot attributes, then I > guess we just disagree. But it wasn't clear. > I greatly prefer select, but this is a compromise to enable progress. > > From: Elliott Sprehn > Sent: Monday, May 18, 21:03 > Subject: Re: [webcomponents] How about let's go with slots? > To: Justin Fagnani > Cc: Philip Walton, Domenic Denicola, Daniel Freedman, Dimitri Glazkov, > Scott Miles, Ryosuke Niwa, Edward O'Connor, Anne van Kesteren, Travis > Leithead, Maciej Stachowiak, Arron Eicholz, Alex Russell, public-webapps > > I'd like this API to stay simple for v1 and support only named slots and > not tag names. I believe we can explain what does with the > imperative API in v2. > > On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani > wrote: > > On Mon, May 18, 2015 at 4:58 PM, Philip Walton > wrote: > > Pardon my question if this has been discussed elsewhere, but it's not > clear from my reading of the "slots" proposal whether they would be allowed > to target elements that are not direct children of the component. > > I believe the with the `select` attribute this was implicitly required > because only compound selectors were supported (i.e. no child or descendent > combinators) [1]. > > I think the actually issue is that you might have fights over who gets > to redistribute an element. Given > > > > > > > > > > > > If both my-el-1 and my-el-2 have "foo" slots, who wins? What if the winner > by whatever rules adds a clashing slot name in a future update? > > I mentioned in this in Imperative API thread, but I think the least > surprising way forward for distributing non-children is to allow nodes to > cooperate on distribution, so a element could send its distributed nodes to > an ancestor: > https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html > > > > > Would named slots be able to target elements farther down in the tree? > > > > [1] > http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select > > > > >
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 4:58 PM, Philip Walton wrote: > Pardon my question if this has been discussed elsewhere, but it's not > clear from my reading of the "slots" proposal whether they would be allowed > to target elements that are not direct children of the component. > > I believe the with the `select` attribute this was implicitly required > because only compound selectors were supported (i.e. no child or descendent > combinators) [1]. > I think the actually issue is that you might have fights over who gets to redistribute an element. Given If both my-el-1 and my-el-2 have "foo" slots, who wins? What if the winner by whatever rules adds a clashing slot name in a future update? I mentioned in this in Imperative API thread, but I think the least surprising way forward for distributing non-children is to allow nodes to cooperate on distribution, so a element could send its distributed nodes to an ancestor: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html > > Would named slots be able to target elements farther down in the tree? > > [1] > http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select >
Re: [webcomponents] How about let's go with slots?
Like we pointed out in the previous thread, adding enough special cases to slots leads to select. At this point we're much more interested in agreeing on something rather than nothing. On Mon, May 18, 2015 at 3:58 PM, Domenic Denicola wrote: > I was thinking opposed. I don’t see any reason to invent two ways to do > the same thing. > > If we do support content-slot then I think we should allow content-slot="summary">.. and a few others. > >
Re: Custom Elements: is=""
On Fri, May 8, 2015 at 1:10 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Yes, I think you are understanding correctly, and it appears this would > be a side-effect J. You have the same problem with two implementations of > x-button though the pool of custom element names is going to be larger. > > > > Do you think this will be a problem in practice? > Definitely. Custom element names will hopefully fall into self-organized namespaces, for instance the Polymer team is putting out element collections, like iron-* and paper-* and we very well might have both iron-button and paper-button. There would be no chance for that with native element extensions without is="". > > > *From:* Justin Fagnani [mailto:justinfagn...@google.com] > *Sent:* Friday, May 8, 2015 1:06 PM > *To:* Travis Leithead > *Cc:* Ryosuke Niwa; Anne van Kesteren; WebApps WG > *Subject:* Re: Custom Elements: is="" > > > > If I'm understanding your proposal correctly, wouldn't this limit any > document to have a single subclass per native element? > > > > How would you express: > > > > Me > > You > > > > -Justin > > > > On Fri, May 8, 2015 at 12:56 PM, Travis Leithead < > travis.leith...@microsoft.com> wrote: > > The 'is' attribute is only a declarative marker; it's the indicator that > the native element has a [potential] custom prototype and hierarchy, right? > > I don't mean to drudge up past history and decisions already laid to rest, > but if subclassing native elements is a good compromise until we get to the > underlying behaviors that make up native HTML elements, why should we limit > registerElement to hyphenated custom element names? > > In other words, why not simplify by: > 1. Allow any localName to be used by registerElement. (This would imply > the HTML namespace by default; we can later add registerElementNS if needed > :) > 2. Drop the 'extends' member from the ElementRegistrationOptions > dictionary. > > With this simplification, serializing elements wouldn't include any sign > that they are 'customized' in any way (as is done with 'is' today). I don't > see this as a problem, since web devs today can already do this, but > without the help of the parser. > > It always seemed weird to me that 'prototype' of > ElementRegistrationOptions can inherit from anything (including null), and > be completely disassociated from the localName provided in 'extends'. > > If we drop support for 'is' in v1, then we can consider later bringing > back subclassing in v2 without introducing 'extends' in the > ElementRegistrationOptions or the 'is' attribute. > > If we opt to keep the feature, I'd like to see it simplified as described > above. > > (In general: I'd also like to see a 'constructor' property added > automatically to the prototype so that you can always get to the native > constructor function from script even if you don't save the return value of > registerElement.) > > > > > On May 6, 2015, at 6:25 AM, Anne van Kesteren wrote: > > > > Open issues are kept track of here: > > > > https://wiki.whatwg.org/wiki/Custom_Elements > > > > I think we reached rough consensus at the Extensible Web Summit that > > is="" does not do much, even for accessibility. Accessibility is > > something we need to tackle low-level by figuring out how builtin > > elements work: > > > > https://github.com/domenic/html-as-custom-elements > > > > And we need to tackle it high-level by making it easier to style > > builtin elements: > > > > http://dev.w3.org/csswg/css-forms/ > > > > And if the parser functionality provided by is="" is of great value, > > we should consider parsing elements with a hyphen in them differently. > > Similar to how
Re: Custom Elements: is=""
If I'm understanding your proposal correctly, wouldn't this limit any document to have a single subclass per native element? How would you express: Me You -Justin On Fri, May 8, 2015 at 12:56 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > The 'is' attribute is only a declarative marker; it's the indicator that > the native element has a [potential] custom prototype and hierarchy, right? > > I don't mean to drudge up past history and decisions already laid to rest, > but if subclassing native elements is a good compromise until we get to the > underlying behaviors that make up native HTML elements, why should we limit > registerElement to hyphenated custom element names? > > In other words, why not simplify by: > 1. Allow any localName to be used by registerElement. (This would imply > the HTML namespace by default; we can later add registerElementNS if needed > :) > 2. Drop the 'extends' member from the ElementRegistrationOptions > dictionary. > > With this simplification, serializing elements wouldn't include any sign > that they are 'customized' in any way (as is done with 'is' today). I don't > see this as a problem, since web devs today can already do this, but > without the help of the parser. > > It always seemed weird to me that 'prototype' of > ElementRegistrationOptions can inherit from anything (including null), and > be completely disassociated from the localName provided in 'extends'. > > If we drop support for 'is' in v1, then we can consider later bringing > back subclassing in v2 without introducing 'extends' in the > ElementRegistrationOptions or the 'is' attribute. > > If we opt to keep the feature, I'd like to see it simplified as described > above. > > (In general: I'd also like to see a 'constructor' property added > automatically to the prototype so that you can always get to the native > constructor function from script even if you don't save the return value of > registerElement.) > > > > On May 6, 2015, at 6:25 AM, Anne van Kesteren wrote: > > > > Open issues are kept track of here: > > > > https://wiki.whatwg.org/wiki/Custom_Elements > > > > I think we reached rough consensus at the Extensible Web Summit that > > is="" does not do much, even for accessibility. Accessibility is > > something we need to tackle low-level by figuring out how builtin > > elements work: > > > > https://github.com/domenic/html-as-custom-elements > > > > And we need to tackle it high-level by making it easier to style > > builtin elements: > > > > http://dev.w3.org/csswg/css-forms/ > > > > And if the parser functionality provided by is="" is of great value, > > we should consider parsing elements with a hyphen in them differently. > > Similar to how
Re: Custom Elements: insert/remove callbacks
On Wed, May 6, 2015 at 8:25 AM, Anne van Kesteren wrote: > On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov > wrote: > > This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866. > > > > The way I remember it, the argument went like this: the most common use > case > > for this callback is to react to element becoming part of the main > document > > (the rough approximation of a nebulous concept "am I useful on the > > screen?"), and making these callbacks be invoked in other cases may just > be > > noise for devs. > > I see. We know from HTML that a change of parent element might be > significant, e.g. with or the element. I'm > inclined to make a proposal here that we change these callbacks to be > the primitives the DOM offers rather than these higher-level > callbacks. > How are you supposed to tell if one of your ancestors was removed? > > > -- > https://annevankesteren.nl/ > >
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Here's one case of redistribution: https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122 Any time you see inside a custom element it's potentially redistribution. Here there's on that is (line 122), and one that could be (line 116), and one that definitely isn't (line 106). I personally think that Hayato's analogy to function parameters is very motivating. Arguing from use-cases at this point is going to miss many things because so far we've focused on the most simple of components, are having to rewrite them for Polymer 0.8, and haven't seen the variety and complexity of cases that will evolve naturally from the community. General expressiveness is extremely important when you don't have an option to work around it - redistribution is one of these cases. Cheers, Justin On Wed, Apr 29, 2015 at 4:57 PM, Tab Atkins Jr. wrote: > On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa wrote: > >> On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. > wrote: > >> On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov > wrote: > >>> On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa wrote: > One thing that worries me about the `distribute` callback approach > (a.k.a. > Anne's approach) is that it bakes distribution algorithm into the > platform > without us having thoroughly studied how subclassing will be done > upfront. > > Mozilla tried to solve this problem with XBS, and they seem to think > what > they have isn't really great. Google has spent multiple years working > on > this problem but they come around to say their solution, multiple > generations of shadow DOM, may not be as great as they thought it > would be. > Given that, I'm quite terrified of making the same mistake in > spec'ing how > distribution works and later regretting it. > >>> > >>> At least the way I understand it, multiple shadow roots per element and > >>> distributions are largely orthogonal bits of machinery that solve > largely > >>> orthogonal problems. > >> > >> Yes. Distribution is mainly about making composition of components > >> work seamlessly, so you can easily pass elements from your light dom > >> into some components you're using inside your shadow dom. Without > >> distribution, you're stuck with either: > > > > As I clarified my point in another email, neither I nor anyone else is > questioning the value of the first-degree of node distribution from the > "light" DOM into insertion points of a shadow DOM. What I'm questioning is > the value of the capability to selectively re-distribute those nodes in a > tree with nested shadow DOMs. > > > >> * components have to be explicitly written with the expectation of > >> being composed into other components, writing their own >> select> *to target the elements of the outer shadow*, which > >> is also extremely terribad. > > > > Could you give me a concrete use case in which such inspection of > content elements in the light DOM is required without multiple generations > of shadow DOM? In all the use cases I've studied without multiple > generations of shadow DOM, none required the ability to filter nodes inside > a content element. > > > >> Distribution makes composition *work*, in a fundamental way. Without > it, you simply don't have the ability to use components inside of > components except in special cases. > > > > Could you give us a concrete example in which selective re-distribution > of nodes are required? That'll settle this discussion/question altogether. > > I'll let a Polymer person provide a concrete example, as they're the > ones that originally brought up redistribution and convinced us it was > needed, but imagine literally any component that uses more than one > (so you can't get away with just distributing the > element itself), being used inside of some other component that wants > to pass some of its light-dom children to the nested component. > > Without redistribution, you can only nest components (using one > component inside the shadow dom of another) if you either provide > contents directly to the nested component (no ) or the nested > component only has a single distribution point in its own shadow. > > ~TJ >
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Tue, Apr 28, 2015 at 4:32 PM, Ryosuke Niwa wrote: > On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. wrote: > > On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. > wrote: > > On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: > > On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: > IMO, the appeal of this proposal is that it's a small change to the > current spec and avoids changing user expectations about the state of the > dom and can explain the two declarative proposals for distribution. > > It seems like with this API, we’d have to make O(n^k) calls where n is the > number of distribution candidates and k is the number of insertion points, > and that’s bad. Or am I misunderstanding your design? > > > I think you've understood the proposed design. As you noted, the cost is > actually O(n*k). In our use cases, k is generally very small. > > > I don't think we want to introduce O(nk) algorithm. Pretty much every > browser optimization we implement these days are removing O(n^2) algorithms > in the favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because > we can't even theoretically optimize it away. > > > You're aware, obviously, that O(n^2) is a far different beast than > O(nk). If k is generally small, which it is, O(nk) is basically just > O(n) with a constant factor applied. > > > To make it clear: I'm not trying to troll Ryosuke here. > > He argued that we don't want to add new O(n^2) algorithms if we can > help it, and that we prefer O(n). (Uncontroversial.) > > He then further said that an O(nk) algorithm is sufficiently close to > O(n^2) that he'd similarly like to avoid it. I'm trying to > reiterate/expand on Steve's message here, that the k value in question > is usually very small, relative to the value of n, so in practice this > O(nk) is more similar to O(n) than O(n^2), and Ryosuke's aversion to > new O(n^2) algorithms may be mistargeted here. > > > Thanks for clarification. Just as Justin pointed out [1], one of the most > important use case of imperative API is to dynamically insert as many > insertion points as needed to wrap each distributed node. In such a use > case, this algorithm DOES result in O(n^2). > I think I said it was a possibility opened by an imperative API, but I thought it would be very rare (as will be any modification of the shadow root in the distribution callback). I think that accomplishing decoration by inserting an insertion point per distributed node is probably a degenerate case and it would be better if we supported decoration, but that seems like a v2+ type feature. -Justin > > In fact, it could even result in O(n^3) behavior depending on how we spec > it. If the user code had dynamically inserted insertion points one by one > and UA invoked this callback function for each insertion point and each > node. If we didn't, then author needs a mechanism to let UA know that the > condition by which insertion points select a node has changed and it needs > to re-distribute all the nodes again. > > - R. Niwa > > [1] > https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html > >
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Mon, Apr 27, 2015 at 1:01 AM, Anne van Kesteren wrote: > On Mon, Apr 27, 2015 at 9:25 AM, Justin Fagnani > wrote: > > I really don't think the platform needs to do anything to support > > subclassing since it can be done so easily at the library level now that > > multiple generations of shadow roots are gone. As long as a subclass and > > base class can cooperate to produce a single shadow root with insertion > > points, the platform doesn't need to know how they did it. > > So a) this is only if they cooperate In reality, base and sub class are going to have to cooperate. There's no style or dom isolation between the two anymore, and lifecycle callbacks, templating, and data binding already make them pretty entangled. > and the superclass does not want > to keep its tree and distribution logic hidden A separate hidden tree per class sounds very much like multiple generations of shadow trees, and we just killed that... This is one of my concerns about the inheritance part of the slots proposal: it appeared to give new significance to tags which essentially turn them into multiple shadow roots, just without the style isolation. > and b) if we want to > eventually add declarative functionality we'll need to explain it > somehow. Seems better that we know upfront how that will work. > I think this is a case where the frameworks would lead and the platform, if it ever decided to, could integrate the best approach - much like data binding. I imagine that frameworks will create declarative forms of distribution and template inheritance that work something like the current system, or the slots proposal (or other template systems with inheritance like Jinja). I don't even think a platform-based solution won't be any faster in the common case because the frameworks can pre-compute the concrete template (including distribution points and bindings) from the entire inheritance hierarchy up front, and stamp out the same thing per instance. Cheers, Justin > > -- > https://annevankesteren.nl/ >
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren wrote: > On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa wrote: > > One major drawback of this API is computing insertionList is expensive > > because we'd have to either (where n is the number of nodes in the shadow > > DOM): > > > > Maintain an ordered list of insertion points, which results in O(n) > > algorithm to run whenever a content element is inserted or removed. > I don't expect shadow roots to be modified that much. We certainly don't see it now, though the imperative API opens up some new possibilities like calculating a grouping of child nodes and generating a tag per group, or even generating a tag per child to perform decoration. I still think those would be very rare cases. > > Lazily compute the ordered list of insertion points when `distribute` > > callback is about to get called in O(n). > > The alternative is not exposing it and letting developers get hold of > the slots. The rationale for letting the browser do it is because you > need the slots either way and the browser should be able to optimize > better. > > > > If we wanted to allow non-direct child descendent (e.g. grand child > node) of > > the host to be distributed, then we'd also need O(m) algorithm where m is > > the number of under the host element. It might be okay to carry on the > > current restraint that only direct child of shadow host can be > distributed > > into insertion points but I can't think of a good reason as to why such a > > restriction is desirable. > The main reason is that you know that only a direct parent of a node can distribute it. Otherwise any ancestor could distribute a node, and in addition to probably being confusing and fragile, you have to define who wins when multiple ancestors try to. There are cases where you really want to group element logically by one tree structure and visually by another, like tabs. I think an alternative approach to distributing arbitrary descendants would be to see if nodes can cooperate on distribution so that a node could pass its direct children to another node's insertion point. The direct child restriction would still be there, so you always know who's responsible, but you can get the same effect as distributing descendants for a cooperating sets of elements. > So you mean that we'd turn distributionList into a subtree? I.e. you > can pass all descendants of a host element to add()? I remember Yehuda > making the point that this was desirable to him. > > The other thing I would like to explore is what an API would look like > that does the subclassing as well. Even though we deferred that to v2 > I got the impression talking to some folks after the meeting that > there might be more common ground than I thought. > I really don't think the platform needs to do anything to support subclassing since it can be done so easily at the library level now that multiple generations of shadow roots are gone. As long as a subclass and base class can cooperate to produce a single shadow root with insertion points, the platform doesn't need to know how they did it. Cheers, Justin > As for the points before about mutation observers. I kind of like just > having distribute() for v1 since it allows maximum flexibility. I > would be okay with having an option that is either optin or optout > that does the observing automatically, though I guess if we move from > children to descendants that gets more expensive. > > > -- > https://annevankesteren.nl/ > >
Re: Proposal for changes to manage Shadow DOM content distribution
On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky 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. > I understand this motivation and think it's a great point that hasn't (yet) received enough attention... But I think we would give up to much user ergonomics in exchange for it under this proposal. I think we can relatively easily add the ability to redirect nodes into distribution points of base classes to the existing system which gives some control to authors on how to select nodes for distribution. > 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): > > > > Physics Department > > > > > If an instance of this page then says > > > Faculty > > I know you mistakenly used a tag rather than content-slot here, but I think it shows my point: this here (using header tags) might be the better API, and I feel that the element author should be able to offer it instead of forcing users to add "content-slot" attributes everywhere. I think this proposal targets custom element subclassers at the expense of custom element users. Yes, subclassers might need fine-grained control over routing children and distributed nodes into base class distribution points. But should end-users have to use the same API surface for that? For custom elements to be successful we don't just need to appeal to element authors, but in turn to their users. Cheers, Justin 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 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: > > > > > Physics Department > > > > > > 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. > > –Jan > > On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. wrote: > > On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa wrote: > > On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. wrote: > > On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa wrote: > > On Apr 22, 2015, at 8:52 AM, Domenic Denicola wrote: > > Between content-slot-specified slots, attribute-specified slots, > element-named slots, and everything-else-slots, we're now in a weird place > where we've reinvented a micro-language with some, but not all, of the > power > of CSS selectors. Is adding a new micro-language to the web platform worth > helping implementers avoid the complexity of implementing CSS selector > matching in this context? > > > I don't think mapping an attribute value to a slot is achievable with a > content element with select attribute. > > > > > > No. That's not what I'm talking here. I'm talking about putting the > attribute value into the insertion point in [1] [2] [3], not distributing > an > element based on an attribute value. > > > Oh, interesting. That appears to be a complete non-sequitur, tho, as > no one has asked for anything like that. It's *certainly* irrelevant > as a response to the text you quoted. > > On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. wrote: > > On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa wrote: > > I don't think defining a slot based on an attribute value is something we'd > like to sup
Re: Proposal for changes to manage Shadow DOM content distribution
On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa wrote: > > On Apr 22, 2015, at 10:16 AM, Justin Fagnani > wrote: > > > > On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa wrote: > >> >> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani >> wrote: >> > >> > I do want the ability to redirect distributed nodes into a holes in the >> base template, so that part is welcome to me. However, my first reaction to >> the slot idea is that forcing users to add the content-slot attribute on >> children significantly impairs the DOM API surface area of custom elements. >> > >> > For the single-level distribution case, how is this different from >> except that content select can >> distribute based on features of the children that might already exist, like >> tag names or an attribute? >> >> At the conceptual level, they're equivalent. However, we didn't find the >> extra flexibility of using CSS selectors compelling as we mentioned in our >> proposal [1]. >> > > I personally would like to see more power, especially positional > selectors. Some components would be better off selecting their first child, > rather than requiring a class. > > > What are concrete use cases that require such flexibility? > Require is a strong word :) but the case I recently experienced was a panel with a header. It always expects one child for the header and the rest for content. There are several ways to do this, and one would be to select the first child into one distribution point and the rest into another. Another way is to use attributes, classes or a specific set of tag names. The key for me here is that you give the custom element author a choice on how to shape their API. > > [1] See points 3 and 4 in >> https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec > > > Point 4 is interesting, because unless I'm missing something (which could > be!) it's incorrect. You can create selectors with :not() that exclude the > content selectors that come after in document order. I would rewrite the > example as: > > > > > > > > Our point wasn't so much that it's not achievable. With enough hackeries > and "techniques", we can. The problem is the developer ergonomics of > content element with select attribute with common real world use cases. > For example, the above code is a lot more verbose and less intuitive than > > > > > > > > This is true, but it's a trade off for custom element *authoring* brevity vs custom element *use* brevity (and authoring expressiveness). I'd personally rather optimize for custom element user ergonomics, and give custom element authors the power to make their elements easy and convenient. Continuing this example I would actually make the selectors more complex because we have these nice semantic elements in html5: Which is more work for the CE author, but allows this for the user: Title ... ... ... Cheers, Justin - R. Niwa > >
Re: Proposal for changes to manage Shadow DOM content distribution
Another technique I've seen used is compound selectors, which could be used to migrate from one selector to another while preserving backwards compatibility, or to provide some nice default distributions that are also accessible via a class or attribute (ie, select="header, .header"). Could slots have multiple names to support something like this? On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani wrote: > > > On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa wrote: > >> >> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani >> wrote: >> > >> > I do want the ability to redirect distributed nodes into a holes in the >> base template, so that part is welcome to me. However, my first reaction to >> the slot idea is that forcing users to add the content-slot attribute on >> children significantly impairs the DOM API surface area of custom elements. >> > >> > For the single-level distribution case, how is this different from >> except that content select can >> distribute based on features of the children that might already exist, like >> tag names or an attribute? >> >> At the conceptual level, they're equivalent. However, we didn't find the >> extra flexibility of using CSS selectors compelling as we mentioned in our >> proposal [1]. >> > > I personally would like to see more power, especially positional > selectors. Some components would be better off selecting their first child, > rather than requiring a class. > >> >> [1] See points 3 and 4 in >> https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec > > > Point 4 is interesting, because unless I'm missing something (which could > be!) it's incorrect. You can create selectors with :not() that exclude the > content selectors that come after in document order. I would rewrite the > example as: > > > > > > > > Cheers, > Justin > > >> >> >> - R. Niwa >> >> >
Re: Proposal for changes to manage Shadow DOM content distribution
On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa wrote: > > > On Apr 21, 2015, at 10:23 PM, Justin Fagnani > wrote: > > > > I do want the ability to redirect distributed nodes into a holes in the > base template, so that part is welcome to me. However, my first reaction to > the slot idea is that forcing users to add the content-slot attribute on > children significantly impairs the DOM API surface area of custom elements. > > > > For the single-level distribution case, how is this different from > except that content select can > distribute based on features of the children that might already exist, like > tag names or an attribute? > > At the conceptual level, they're equivalent. However, we didn't find the > extra flexibility of using CSS selectors compelling as we mentioned in our > proposal [1]. > I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. > > [1] See points 3 and 4 in > https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: Cheers, Justin > > > - R. Niwa > >
Re: Proposal for changes to manage Shadow DOM content distribution
I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? Cheers, Justin On Tue, Apr 21, 2015 at 9:57 PM, Ryosuke Niwa wrote: > > On Apr 21, 2015, at 9:43 PM, Daniel Freedman wrote: > > Hi Ryosuke, > > I want to start by thanking you, Ted, and Jan for taking the time to make > this proposal. > > I read through the proposal, and had a quick question about how > redistribution should work with this slot concept. > I created a quick example that would take two date > inputs (start date and end date) and distribute them through the example > , but I found myself stuck. > I can't name the two date inputs with the same slot or they will end up in > only one of the content elements, but > only takes inputs with slot "inputElement". > > How should this work? > > I drafted a quick gist to illustrate this: > https://gist.github.com/azakus/676590eb4d5b07b94428 > > > > > > > > > > > > > > > > > > > > > > > Am I right in assuming that you want to "re-distribute" (1) into (3)'s and > (2) into (4)'s inputElements? If so, I'd imagine one possible syntax is as > follows: > > > > > > > > > > > > > > Here, the content elements are both creating slots and fulfilling slots. > > - R. Niwa > > On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa wrote: > >> Hi all, >> >> Following WebApps discussion last year [1] and earlier this year [2] >> about template transclusions and inheritance in shadow DOM, Jan Miksovsky >> at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had >> a meeting where we came up with changes to the way shadow DOM distributes >> nodes to better fit real world use cases. >> >> After studying various real world use of web component APIs as well as >> exiting GUI frameworks, we noticed that selector based node distribution as >> currently spec'ed doesn't address common use cases and the extra >> flexibility CSS selectors offers isn't needed in practice. Instead, we >> propose named insertion "slots" that could be filled with the contents in >> the original DOM as well as contents in subclasses. Because the proposal >> uses the same slot filling mechanism for content distributions and >> inheritance transclusions, it eliminates the need for multiple shadow >> roots. >> >> Please take a look at our proposal at >> https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution >> >> [1] >> https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html >> [2] >> https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html >> >> > >
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> > From: Justin Fagnani [mailto:justinfagn...@google.com]
> >> Elements expose this “shadow node list” via APIs that are very similar
> to
> >> existing node list management, e.g., appendShadowChild(),
> insertShadowBefore(),
> >> removeShadowChild(), replaceShadowChild(), shadowChildren[],
> shadowChildNodes[].
> >
> >This part seems like a big step back to me. Shadow roots being actual
> nodes means
> >that existing code and knowledge work against them.
>
> "existing code and knowledge work against them" -- I'm not sure you
> understood correctly.
>
No, I think I understood :)
ShadorRoot extends DocumentFragment, and thus Node and has all the API yo
would expect like querySelector(), qsA(), childNodes(), textContent,
appendChild(), cloneNode(), insertBefore(), etc... You can pass a
ShadowRoot to any API expecting a node. For instance, deep traversal though
shadow trees only requires updating normal traversal to crawl into shadows,
it doesn't require teaching it a multitude of shadow*() methods.
> Nodes in the "shadow child list" wouldn't show up in the childNodes list,
> nor in any of the
> node traversal APIs (e.g., not visible to qSA, nextSibling,
> previousSibling, children, childNodes,
> ect.
>
> Trivially speaking, if you wanted to hide two divs that implement a "stack
> panel" and have some
> element render it, you'd just do:
> element.appendShadowChild(document.createElement('div'))
> element.appendShadowChild(document.createElement('div'))
>
> Those divs would not be discoverable by any traditional DOM APIs (they
> would now be on the
> "shadow side"), and the only way to see/use them would be to use the new
> element.shadowChildren
> collection.
>
As in the current API where the only way to see shadow children is by
accessing a shadow root. Your examples become:
element.shadowRoot.appendChild(document.createElement('div'))
element.shadowRoot.appendChild(document.createElement('div'))
Or things like: function writeDivSoup(container){...}, which will work as
writeDivSoup(element.shadowRoot)
> But perhaps I'm misunderstanding your point.
>
> >The API surface that you'd have to duplicate with shadow*() methods would
> be quite large.
>
> That's true. Actually, I think the list above is probably about it.
>
querySelector(), find() and friends are important. Plus, speaking of find()
what about additions to Node and DocumentFragment in the future? Do you
keep just adding things like queryShadowSelector() and shadowFind()?
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Thu, Mar 26, 2015 at 10:53 AM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Hi folks, > > > > Today’s ShadowDOM model is designed around only adding shadow roots to > element in the ‘light side’. I assume this is intentional, but was hoping > someone could describe why this design was chosen? Or said another way, if > there was an imperative API to _*remove*_ a shadow DOM, would that > symmetry be bad? > > > > In full transparency, I’m thinking about potential solutions for a > simplified shadow dom, and it occurs to me that it can’t get much simpler > than the following: > > ·Elements only [ever] have one “shadow side” which is essentially > a secondary child node list. Whenever anything’s in this list the Element > renders that content instead of its “light” children. (Or maybe there’s a > switch to tell the element which side to render: light or dark?) > > ·Elements expose this “shadow node list” via APIs that are very > similar to existing node list management, e.g., appendShadowChild(), > insertShadowBefore(), removeShadowChild(), replaceShadowChild(), > shadowChildren[], shadowChildNodes[]. > This part seems like a big step back to me. Shadow roots being actual nodes means that existing code and knowledge work against them. The API surface that you'd have to duplicate with shadow*() methods would be quite large. ·No special Event swizzling, no security boundary, no alternate > script engine, no intermediate shadow root object, etc. This minimalist > approach only provides node ‘hiding’ and potentially an alternate rendering > path. > > ·Another feature could then provide the stronger “component” > boundary, specifically the javascript global scope isolation. This > delineation may more closely match the division we are seeing between the > “React-like” scenarios and more robust component-kitchen-style custom > element deployments. > > > > >
Range.getClientRanges()?
When using Ranges to try to navigate content, I'm finding that it would be useful to be able to decompose a Range in sub-Ranges that correspond to the rects returned from getClientRects(). In particular, this would make it easier to find line-breaks. Thoughts? Cheers, Justin
