Permissions API vs local APIs
Over in https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0006.html Jonas pointed out that having two APIs for doing the same thing is "nuts". We should probably decide whether we go ahead with the Permissions API or keep doing permission checks on a per-API basis. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn wrote: > We can solve this > problem by running the distribution code in a separate scripting context > with a restricted (distribution specific) API as is being discussed for > other extension points in the platform. That seems like a lot of added complexity, but yeah, that would be an option I suppose. Dimitri added something like this to the imperative API proposal page a couple of days ago. > One thing to consider here is that we very much consider distribution a > style concept. It's about computing who you inherit style from and where you > should be in the box tree. It just so happens it's also leveraged in event > dispatch too (like pointer-events). It happens asynchronously from DOM > mutation as needed just like style and reflow though. I don't really see it that way. The render tree is still computed from the composed tree. The composed tree is still a DOM tree, just composed from various other trees. In the "open" case you can access it synchronously through various APIs (e.g. >>> if we keep that for querySelector() selectors and also deepPath). -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Thu, Apr 30, 2015 at 6:22 AM, Anne van Kesteren wrote: > On Thu, Apr 30, 2015 at 3:05 PM, Hayato Ito 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). > We don't need to pick from either of those choices. We can solve this problem by running the distribution code in a separate scripting context with a restricted (distribution specific) API as is being discussed for other extension points in the platform. One thing to consider here is that we very much consider distribution a style concept. It's about computing who you inherit style from and where you should be in the box tree. It just so happens it's also leveraged in event dispatch too (like pointer-events). It happens asynchronously from DOM mutation as needed just like style and reflow though. We don't want synchronous reflow inside appendChild because it means authors would have to be very careful when mutating the DOM to avoid extra churn. Distribution is the same way, we want it async so the browser can batch the work and only distribute when the result is actually needed. In our code if you look at the very few places we update distribution explicitly: 3 event related 3 shadow dom JS api 9 style (one of these is flushing style) 1 query selector (for ::content and :host-context) And all other places where distribution wants to be updated are because we flush style (or layout) because what that caller really wanted to know was something about the rendering. - E
Re: :host pseudo-class
On Tue, May 5, 2015 at 6:52 AM, Jonas Sicking wrote: > My understanding is that the question here isn't what is being > matched, but rather what syntax to use for the selector. I.e. in both > cases the thing that the selector is matching is the DocumentFragment > which is the root of the shadow DOM. No, :host matches the host element in the light tree that holds the shadow tree. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron wrote: > On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote: >> I don't understand why :host is a pseudo-class rather than a >> pseudo-element. My mental model of a pseudo-class is that it allows >> you to match an element based on a boolean internal slot of that >> element. :host is not that since e.g. * does not match :host as I >> understand it. That seems super weird. Why not just use ::host? >> >> Copying WebApps since this affects everyone caring about Shadow DOM. > > We haven't really used (in the sense of shipping across browsers) > pseudo-elements before for things that are both tree-like (i.e., not > ::first-letter, ::first-line, or ::selection) and not leaves of the > tree. (Gecko doesn't implement any pseudo-elements that can have > other selectors to their right. I'm not sure if other engines > have.) > > I'd be a little worried about ease of implementation, and doing so > without disabling a bunch of selector-related optimizations that > we'd rather have. > > At some point we probably do want to have this sort of > pseudo-element, but it's certainly adding an additional dependency > on to this spec. My understanding is that the question here isn't what is being matched, but rather what syntax to use for the selector. I.e. in both cases the thing that the selector is matching is the DocumentFragment which is the root of the shadow DOM. If implementing :host is easier than ::host, then it seems like the implementation could always convert the pseudo-element into a pseudo-class at parse time. That should make the implementation the same other than in the parser. Though maybe the concern here is about parser complexity? / Jonas
Re: :host pseudo-class
On Tue, May 5, 2015 at 2:08 AM, Tab Atkins Jr. wrote: > On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren wrote: >> 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. > > I still don't understand what you find wrong with this. It's not that > ":host() [can] match an element that cannot otherwise be matched", > it's that the host element element is featureless, save for the > ability to match :host. (That's the definition of a featureless > element - it's allowed to specify particular things that can still > match it.) In other words, it's not :host that's magical, it's the > host element itself that's magical. So :host:hover would not work? I guess you would have to spell that :host(:hover)? Because although it does not have features, it has features inside the parenthesis? Was this concept introduced for other scenarios or just for :host? Seems like a very weird rationalization. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren wrote:
> On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn 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?
::selection has a host element. If you use it by itself it just means
you're selecting *::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.
I still don't understand what you find wrong with this. It's not that
":host() [can] match an element that cannot otherwise be matched",
it's that the host element element is featureless, save for the
ability to match :host. (That's the definition of a featureless
element - it's allowed to specify particular things that can still
match it.) In other words, it's not :host that's magical, it's the
host element itself that's magical.
~TJ
RE: [components] Isolated Imports and Foreign Custom Elements
>> (1) All of the parameters to registerElement() should really be provided by >> the cross-origin element itself. It makes no sense for prototype and extends >> to come from the hosting environment. It does makes sense for the cross-origin component to own the element name and extends that it defines, as this name may be important for its documentation and potentially sub-classing behavior. So +1 to that, though when handing that naming control to the host, the host can independently manage naming collisions. I'm just mentioning that--not suggesting that we should design for that particular use case. On the API control: One other approach I considered was to use ES6 proxies in some way, because the drawback with the property descriptor approach (if you consider it a drawback) is that you can't create cross-origin components whose elements act like DOM Collections (e.g. the behavior of 'window' or 'form' which have named property/indexed property getters). Perhaps these 'feature' of the current DOM should be discouraged in component creation, but if not, you'd need something with the flexibility of ES6 Proxies. I stuck with property descriptors in the proposal because Proxy use seems like overkill for the simple API definition scenarios (in other words, for a simple property, I don't want to have to define the proxy handler methods: has, get, deleteProperty, enumerate, ownKeys, etc. I'm not sure to what extent your two-way membrane proxy would handle this case... -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Friday, May 1, 2015 2:57 PM To: Travis Leithead Cc: Anne van Kesteren; WebApps WG Subject: Re: [components] Isolated Imports and Foreign Custom Elements Your proposal seems conceptually very similar to mine. I guess that’s a good sign! It seems the biggest difference is the foreign registration hook - whether it’s done at class registration time (registerElement) or done at import time. The reasons I did not go with class registration time are: (1) All of the parameters to registerElement() should really be provided by the cross-origin element itself. It makes no sense for prototype and extends to come from the hosting environment. (2) You need to define an elaborate protocol for the outside origin to do the “inside” of the registration operation. (3) At least in the obvious way to do it, you need one external document per custom element type. (4) It’s less aligned with regular HTML imports, which are the non-cross-origin non-isolated tool for importing a bunch of element definitions. (5) Documents referenced by can be preloaded aggressively, but loads initiated from a script parameter cannot. On these grounds, I think doing the loading at import time, and explicit import/export lists, are a simpler and cleaner solution. It sounds like you agree with some of the reasons below. I guess the other big difference is that your approach allows customizing what API is exposed, rather than proxying everything defined by the custom element instance in its own world. That is intriguing to me, but I’m not sure it’s necessary. The custom element can have truly private methods and slots by using ES6 symbols, and my proposed rule to do extended structured cloning on parameters and returns limits the risk of exposing everything. But I agree with you that if we need fine-grained API control, it’s better to do it with property descriptor-like structures than in a fully programmatic way. Regards, Maciej > On May 1, 2015, at 10:46 AM, Travis Leithead > wrote: > > If you take a look at [1], we extend the custom elements registration > mechanism so that the constructor is still available in the hosting global, > yet the implementation is defined in the isolated environment. > > An approach to solving this might address another concern I have... > > I've been thinking about the way that the APIs are created with my proposal > and the design wherein you have an explicit API to create the API signature > on the prototype (and instances) leaves a lot of room for potential issues. > For example: > * Nothing requires the isolated component to create any APIs initially > (leaving the custom element without any API until some random later time of > the isolated component's choosing). > * There is no way to know when the isolated component's APIs creation is > "done" > * The isolated component can remove APIs at any time; this is not a > pattern that user agents ever make use of and there's no use case for > it--doesn't seem appropriate to give this power to the isolated > component > > To address these problems, if you change the model to work more like what > Maciej proposed where you can have N number of custom elements defined by one > global, then in the creation of a particular custom element (specifically > it's prototype) you can specify what APIs should be defined on it in one shot > (creation time) and don't provide a
Re: [components] Isolated Imports and Foreign Custom Elements
On Sat, May 2, 2015 at 12:07 AM, Maciej Stachowiak wrote: > It’s already possible to run a constructor from another global object in the > non-cross-origin case. Okay, that makes more sense. I first read it as a suggestion we'd construct a node using a same-global constructor and then also run the foreign-global constructor and it didn't really compute. > I think it may be necessary to do an experimental implementation to work out > all the details of how the two-way isolation works. I have the feeling there's some overlap with compartments: http://andreasgal.com/2010/10/13/compartments/ Though I guess non-Gecko implementations still want to avoid going there. Another thing that might be nice is that if these elements are that much isolated, perhaps we can consider allowing them to be renamed them as well, similar to what module systems allow you to do. -- https://annevankesteren.nl/
