Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Wed, Dec 4, 2013 at 10:30 AM, Ian Hickson wrote: > On Tue, 3 Dec 2013, Dimitri Glazkov wrote: > > > > > > > > Yeah, the idea is you'd bind to the scroll box to change the whole > > > > scroll UI, but you could also then override specific pseudos of the > > > > scroll box to style subparts of the default (or custom) scrollbox > > > > UI. This part was never very well developed though since the core of > > > > XBL2 was never picked up. But I think the same approach should > > > > probably still work with the newer Web components work, no? It needs > > > > to be specified and implemented... > > > > > > Web components can't define pseudo elements. So no. > > > > > > This sadly also means that you can't write a CSS which styles the > > > default UA UI if that is used, and styles an attached Shadow DOM if > > > that is used. > > > > That's simply not true. Where'd you get that? > > > > http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements > > http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ > > The key feature here isn't defining _new_ pseudo-elements, but being able > to map specific elements in the shadow tree to predefined standard > pseudo-elements, in particular, the same pseudo-elements that the standard > binding exposes. > > If such a feature is available, then the HTML spec could list which of the > standard pseudos each default binding is expected to expose, and then > authors could style subparts of standard controls easily. > FWIW, I got push back on attempting to do this from both Apple and Mozilla at the Shadow DOM CSS Meeting ( http://www.w3.org/wiki/Webapps/WebComponentsJune2013Meeting). The notes don't do justice, unfortunately ( http://www.w3.org/2013/06/21-webapps-minutes.html (search for "SLIGHTLY sympathetic"). The gist of the argument was that we should let UAs decide how they want to design controls and avoid limiting their options by standardizing behavior of pseudo-elements. :DG<
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, Dec 3, 2013 at 10:32 PM, Jonas Sicking wrote: > On Dec 3, 2013 9:39 PM, "Dimitri Glazkov" wrote: > > >> Web components can't define pseudo elements. So no. > >> > >> This sadly also means that you can't write a CSS which styles the > default > >> UA UI if that is used, and styles an attached Shadow DOM if that is > used. > > > > > > That's simply not true. Where'd you get that? > > > > http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements > > Ah, I thought that the cat and hat combinators had replaced pseudo element > support. Glad to see that is not the case. > That will probably still happen, at least in the scope of shadow DOM. Cat/hat are a much better replacement. See my (longish) explanation of the problem with custom pseudo elements here: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0454.html > However as the spec is currently written the author still couldn't write a > replacement for which supports a ::options-box pseudo element (if > that is what we agree it should be called and what the UA UI should respond > to.) > Yup. That's something that needs to be figured out. I wonder if the right approach is to explaining pseudo elements is to treat them as something that may rely on Shadow DOM, but is a different beast altogether, because they have some rather interesting quirks (look at ::backdrop, for instance). :DG<
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, Dec 3, 2013 at 9:30 PM, Jonas Sicking wrote: > On Dec 3, 2013 9:16 PM, "Ian Hickson" wrote: > > > > On Tue, 3 Dec 2013, Jonas Sicking wrote: > > > > > > > > > > Additionally, replacing the rendering rather than styling it is > > > > > hostile towards new platforms. If everyone had used Shadow-DOM to > > > > > build their own rendering for s that would have made the > > > > > transition to mobile much more painful since you'd get a tiny > custom > > > > > UIs rather than a more platform-appropriate picker. > > > > > > > > Well, there's not much that can be done about that, as far as I can > > > > tell. > > > > > > Allowing targeting parts of the built-in UI using pseudo-elements would > > > go a long way. I.e. having a ::options-box pseudo-element as well as > > > other pseodu elements for other components of common implementations. > > > > > > This way the UA could ignore the style properties that it can't > > > implement or that doesn't make sense for its UI. > > > > Yeah, agreed. Again, with XBL2, the goal was to define some default > > bindings (in abstract, not concretely) that user agents were supposed to > > default to, and those bindings would specify pseudos that specific > > subparts mapped to (XBL2 had an xbl:pseudo attribute for this). You can > > actually see the remnants of this in the HTML spec's rendering section, > > where the widgets are defined in terms of the 'binding' property. > > Defining the list of pseudo elements using a XBL2 binding or using prose is > just two was of doing the same thing. So yeah I think either would work. > > The hard part is coming IP with the list I think. > > > > > > And then there's of course the separate-but-related issue of being > > > > > able to style scrollbars, which is another reason websites create > > > > > sea-of-divs pages today. The reason this is related is that the > > > > > challenges styling form controls isn't really related to form > > > > > controls, but rather related to styling of UA-provided UI. > > > > > Scrollbars is another such UI. > > > > > > > > Right. We never developed this very far, but with XBL2 the idea was > > > > that we'd eventually let you override the binding of a '::scrollbox' > > > > pseudo, or some such. > > > > > > A scrollbar consists of multiple pieces, so you'll need more pseudo > > > elements. But yes, I think this is the right direction. > > > > Yeah, the idea is you'd bind to the scroll box to change the whole scroll > > UI, but you could also then override specific pseudos of the scroll box > to > > style subparts of the default (or custom) scrollbox UI. This part was > > never very well developed though since the core of XBL2 was never picked > > up. But I think the same approach should probably still work with the > > newer Web components work, no? It needs to be specified and > implemented... > > Web components can't define pseudo elements. So no. > > This sadly also means that you can't write a CSS which styles the default > UA UI if that is used, and styles an attached Shadow DOM if that is used. > That's simply not true. Where'd you get that? http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ :DG<
Re: [whatwg] seamless iframes and event propagation
On Fri, Jan 11, 2013 at 3:54 PM, Dimitri Glazkov wrote: > On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren wrote: >> I want you to create a list :-) Apologies for such a long delay. Dog-ate-homework, etc. Here's what WebKit does. If interface isn't mentioned, then there's nothing special going on there. Legend: * N -- no change * L -- computed lazily from target * R - computed when retargeting * X - influenced by shadow DOM changes in event dispatch process Event: type - N target - R currentTarget - R eventPhase - X bubbles - N cancelable - N timeStamp - N defaultPrevented - N srcElement == target - R returnValue - N cancelBubble - N clipboardData - N UIEvent: view - N detail - N keyCode - N charCode - N layerX - L layerY - L pageX - N pageY - N which - N MouseEvent: screenX - N screenY - N clientX - N clientY - N x - N y - N offsetX - L offsetY - L ctrlKey - N shiftKey - N altKey - N metaKey - N button - N relatedTarget - R fromElement - L toElement - L dataTransfer - N We currently don't seem to be doing anything with Touch events, but we probably should. Touch (proposed): clientX - N clientY - N screenX - N screenY - N pageX - N pageY - N target - R identifier - N :DG<
Re: [whatwg] seamless iframes and event propagation
On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren wrote: > On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov > wrote: >> Sure. Where are you seeing this list being mentioned? In Shadow DOM >> spec or in DOM Core spec? I am happy to help, just not sure what >> exactly I need to be doing :) > > I want you to create a list :-) Okay.
Re: [whatwg] seamless iframes and event propagation
On Fri, Jan 11, 2013 at 11:28 AM, Anne van Kesteren wrote: > On Fri, Jan 11, 2013 at 8:16 PM, Dimitri Glazkov > wrote: >> On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren wrote: >>> Is that the case for all non-target/relatedTarget attributes that need >>> adjustment? That they do not actually need to be adjusted but are >>> calculated on getting based on the target and its conditions at the >>> time of getting? (E.g. for touch events, the new pointer events, >>> anything else?) >> >> That's been our implementation experience. It's neat that properties >> on event objects fall cleanly into two categories: >> >> 1) properties that inform the author about the actual event dispatch >> process (target, relatedTarget) >> 2) properties that inform the author about the specifics of the event. >> >> The #1 are the ones that need adjustment for encapsulation. The #2 are >> the ones that can be either computed on demand or don't need >> adjustment. > > I'd like to have the concrete list, because in the event model all > attributes are initialized before the event is dispatched and they do > not change. That's the way init*Event() and now event constructors > work. offset* (and a few others on MouseEvent) might be special > because they were added later on and were not really standardized (I > made an attempt in CSSOM View for MouseEvent extensions but did not > cover this peculiarity). Sure. Where are you seeing this list being mentioned? In Shadow DOM spec or in DOM Core spec? I am happy to help, just not sure what exactly I need to be doing :) :DG<
Re: [whatwg] seamless iframes and event propagation
On Fri, Jan 11, 2013 at 11:14 AM, Anne van Kesteren wrote: >>> Normally with being a child of there would not be any >>> adjustment. >> >> Yup. I don't understand whether you're just agreeing with me or disagreeing >> :) >> >> With shadow trees in place, we need to let them react to events >> happening in nodes, distributed to insertion points. > > Is there any adjustment if offset* are computed on getting anyway? > (Calling it adjustment if there's no actual adjustment (they're just > relative to target) seems wrong.) Whoops, sorry -- don't understand if we're talking about adjust target/relativeTarget or offset* in the example. If the former, then yes, it's really not any sort of adjustment. Just grab the current value of target and compute on demand. :DG<
Re: [whatwg] seamless iframes and event propagation
On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren wrote: > On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov > wrote: >> Can you elaborate on this a bit more. Note, you don't need to compute >> offsetX/Y until they are actually requested (which is what WebKit does >> anyway). > > I see. That would change matters indeed. > > Is that the case for all non-target/relatedTarget attributes that need > adjustment? That they do not actually need to be adjusted but are > calculated on getting based on the target and its conditions at the > time of getting? (E.g. for touch events, the new pointer events, > anything else?) That's been our implementation experience. It's neat that properties on event objects fall cleanly into two categories: 1) properties that inform the author about the actual event dispatch process (target, relatedTarget) 2) properties that inform the author about the specifics of the event. The #1 are the ones that need adjustment for encapsulation. The #2 are the ones that can be either computed on demand or don't need adjustment. :DG<
Re: [whatwg] seamless iframes and event propagation
On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren wrote: > On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov > wrote: >> On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren wrote: >>> My bad, I actually meant if 's associated shadow tree had an >>> insertion point through which 's child, which is , would go and >>> then the event would be dispatched in 's associated shadow tree. (I >>> phrased that beyond poorly however and only tried to make up for it on >>> IRC.) >> >> Okay, so event path would be (in tree order): >> >> -- [shadow root] -> .. -> -- -- [shadow >> root] -> .. -> >> >> In this case, the adjustment happens twice, at and . > > Normally with being a child of there would not be any > adjustment. Yup. I don't understand whether you're just agreeing with me or disagreeing :) With shadow trees in place, we need to let them react to events happening in nodes, distributed to insertion points. > If as you say offsetX/offsetY would be computed at invoke > listener time, you just created an observable effect of implementing > something in terms of shadow trees. (Which might not even be > web-compatible.) Can you elaborate on this a bit more. Note, you don't need to compute offsetX/Y until they are actually requested (which is what WebKit does anyway). > I'm not sure that's desirable or even possible. > > Also, computing anything but target/relatedTarget at a point target > might not even be in the DOM anymore seems very weird and counter to > how the event model has worked thus far. I agree. That's not what I am proposing. >> As I mentioned before, it's not solely based on WebKit implementation >> experience. Microsoft had a very similar list for viewlink and they >> wanted me to look at it when I was working on this part of the spec: >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804 > > Note that IE did not have a capture phase back then. So just saying > "stopping" makes some amount of sense. With a capture phase you need > to do something else. (I filed a bug on this the other day.) Okay. :DG<
Re: [whatwg] seamless iframes and event propagation
On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren wrote: > > My bad, I actually meant if 's associated shadow tree had an > insertion point through which 's child, which is , would go and > then the event would be dispatched in 's associated shadow tree. (I > phrased that beyond poorly however and only tried to make up for it on > IRC.) Okay, so event path would be (in tree order): -- [shadow root] -> .. -> -- -- [shadow root] -> .. -> In this case, the adjustment happens twice, at and . > > 3) Also when invoking event listeners (http://dom.spec.whatwg.org/#concept-event-listener-invoke), between steps 3 and 4, we have to: a) if the type of event is MouseEvent, adjust offsetX and offsetY relative to relative target. b) If the type of event has a relatedTarget attribute (MouseEvent, FocusEvent), adjust it using http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-related-target-algorithm. >>> >>> Are you sure this happens at that point? Because at that point the DOM >>> could have completely changed due to event callbacks. >> >> That's a good point. In WebKit implementation, the tuple mentioned in >> #1 also contains relatedTarget, but I neglected to mention this in the >> spec. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20604. > > So why are offsetX and offsetY not calculated in advance? Those would > be affected by DOM manipulation in event listeners too. (If you have > all those attributes being different, would it not be easier to use a > different event object?) I think it's okay if they are affected. They carry different type of information and I would assume that the user wants to have the actual position at the moment of running their event listener, rather than some cached value. > Incidentally, was there any progress made on the magic list of events > that should not leak out of the upper boundary? Not yet, still working on it here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247 >If that list is based > on implementation experience of certain widgets in WebKit, maybe it > would be better if those widgets instead themselves took care of those > events not leaking through by having the appropriate event listeners? > Hmm, I guess that might not work for capturing... :/ As I mentioned before, it's not solely based on WebKit implementation experience. Microsoft had a very similar list for viewlink and they wanted me to look at it when I was working on this part of the spec: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804 :DG<
Re: [whatwg] seamless iframes and event propagation
On Tue, Jan 8, 2013 at 6:26 AM, Anne van Kesteren wrote: > On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov > wrote: >> Okay. Here is all the shadow DOM-related monkeypatching: >> >> 1) When dispatching events (http://dom.spec.whatwg.org/#dispatching-events), >> on step 4, the event path is built using >> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-retargeting-algorithm, >> and is actually a list of tuples, storing a relative target in addition to >> ancestor. > > If you have a tree such as -> -> -> and an > event is dispatched in 's event's target is only adjusted > on right? It does not need to be adjusted further for 's > or ? Does stand for the actual element (the shadow insertion point) or the shadow root in your diagram? I think what you're trying to ask is this... 1) For a tree -- [shadow root] -> -- [shadow root] -> (where "->" denotes child-parent relationship and "--" denotes host-root relationship) 2) if an event is dispatched on 3) where is the event target's adjusted? If that's the question, then it needs to be adjusted twice: at (the adjusted target becomes ) and at (the adjusted target becomes ). > >> 3) Also when invoking event listeners >> (http://dom.spec.whatwg.org/#concept-event-listener-invoke), between steps 3 >> and 4, we have to: >> >> a) if the type of event is MouseEvent, adjust offsetX and offsetY relative >> to relative target. >> >> b) If the type of event has a relatedTarget attribute (MouseEvent, >> FocusEvent), adjust it using >> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-related-target-algorithm. > > Are you sure this happens at that point? Because at that point the DOM > could have completely changed due to event callbacks. That's a good point. In WebKit implementation, the tuple mentioned in #1 also contains relatedTarget, but I neglected to mention this in the spec. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20604. > >> 4) The step 7 of http://dom.spec.whatwg.org/#concept-event-listener-invoke >> may actually happen more than once, since relative target and ancestor >> always equal each other whenever the node is a shadow host. > > Do you mean step 4.7? Ah, wrong link. I meant steps 7 and 8 of http://dom.spec.whatwg.org/#concept-event-dispatch, the AT_TARGET steps. > > >> 5) Finally, whenever adjusted relatedTarget and target are the same, skip >> step 9.3 of http://dom.spec.whatwg.org/#dispatching-events. The >> intent here is to not invoke event listeners on nodes where adjusting both >> relatedTarget and target resulted on them being the same node -- to prevent >> widgets sending out useless mouseovers/outs when the user is hovering inside >> of it. > > How do you know at this point what the adjusted relatedTarget is if > you change it at invoke as you said above? See above. :DG<
Re: [whatwg] Styling
On Mon, Jan 7, 2013 at 2:25 AM, Anne van Kesteren wrote: > On Sun, Jan 6, 2013 at 8:36 PM, Dimitri Glazkov wrote: >> So I wouldn't call this exactly vaporware :) > > I cannot get it to work for . Right. Here is WebKit's burn down list for all remaining elements to convert to be shadow tree-aware: https://bugs.webkit.org/showdependencytree.cgi?id=82313&hide_resolved=1 > But this is certainly interesting. It would require to be defined > in terms of > shadow trees, or not? As otherwise the triangle in Chrome's > implementation would not disappear so easily... While is indeed implemented as a shadow tree in WebKit, it does not have to be. It does, however, need to be know how to interact with shadow trees. Specifically, the element has to pretend that its composition is defined in terms of insertion points: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements-and-their-shadow-trees :DG<
Re: [whatwg] Styling
On Wed, Jan 2, 2013 at 9:10 PM, Ian Hickson wrote: > On Wed, 2 Jan 2013, Boris Zbarsky wrote: > > On 1/2/13 4:37 PM, Ian Hickson wrote: > > > Wait, Web Components isn't solving this? I thought this was one of the > > > main use cases of Web Components. > > > > [...] and it is certainly not doing: > > > > 4) Defining the browser-defined "custom" widgets using the > > capabilities of #2 such that authors can in fact style them. > > Why not? This seems like a pretty core feature. Without being able to do > this, how can anyone reliably extend an existing widget, for example? That's a good question! I am certainly interested in--and have been working on--solving these use cases. In fact, if you point your Chrome Dev/Canary to http://jsfiddle.net/nL747/, you will see that you can indeed style an existing details/summary combo just fine, using Shadow DOM (please pardon the bugs in WebKit implementation, we know they exist and are fixing them) This is possible because Shadow DOM specifies that all HTML elements must behave as if they already have an existing, UA-provided shadow tree ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements-and-their-shadow-trees), which in turn allows the author-created shadow trees to properly override (and even include) those UA-provided shadow trees. You should be able to do the same exact thing with every other element (though there's a very tricky issue with IMG, VIDEO, OBJECT, et al. about the nature of "the insides" of the actual replaced content that will need to be first resolved by CSS WG). So I wouldn't call this exactly vaporware :) The remaining interesting question is how these shadow trees are created? There are three ways: 1) Using shadow DOM API, in plain JS, as shown in the fiddle. 2) Using Custom Elements ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html), which enables authors to extend existing HTML elements to create new widgets. 3) Using Decorators ( http://www.w3.org/TR/components-intro/#decorator-section) to give new shadow trees to existing elements. Hope this helps. :DG<
Re: [whatwg] seamless iframes and event propagation
On Mon, Dec 17, 2012 at 1:48 PM, Dimitri Glazkov wrote: 5) Finally, whenever adjusted *relatedTarget* and *target* are the same, > skip step 9.3 of http://dom.spec.whatwg.org/#concept-event-listener-invoke. > The intent here is to not invoke event listeners on nodes where adjusting > both relatedTarget and target resulted on them being the same node -- to > prevent widgets sending out useless mouseovers/outs when the user is > hovering inside of it. > Correction here: the link should point to http://dom.spec.whatwg.org/#dispatching-events. > > I think that's it :) > > :DG< > >
Re: [whatwg] seamless iframes and event propagation
On Fri, Dec 14, 2012 at 12:18 PM, Anne van Kesteren wrote: What would help me is to better understand the requirements of the > shadow DOM with respect to event dispatch. To calculate the dispatch > tree, you're using the event type, right? Then at certain points > you're also making modifications to the Event object being dispatched, > correct? Is there anything else? I'd like to expose those as hooks > from the dispatch algorithm, but I'd like to make sure I'm not missing > anything. > Okay. Here is all the shadow DOM-related monkeypatching: 1) When dispatching events (http://dom.spec.whatwg.org/#dispatching-events), on step 4, the *event path* is built using http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-retargeting-algorithm, and is actually a list of tuples, storing a *relative target* in addition to *ancestor*. 2) When invoking event listeners ( http://dom.spec.whatwg.org/#concept-event-listener-invoke), on step 3, we initialize event's *currentTarget* and *target* attributes to the *relative target* for the *ancestor* on which the listeners are invoked (consulting the list of tuples computed in item 1). 3) Also when invoking event listeners ( http://dom.spec.whatwg.org/#concept-event-listener-invoke), between steps 3 and 4, we have to: a) if the type of event is *MouseEvent*, adjust offsetX and offsetY relative to *relative target*. b) If the type of event has a *relatedTarget* attribute (*MouseEvent*, * FocusEvent*), adjust it using http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-related-target-algorithm . 4) The step 7 of http://dom.spec.whatwg.org/#concept-event-listener-invokemay actually happen more than once, since *relative target* and *ancestor* always equal each other whenever the node is a shadow host. 5) Finally, whenever adjusted *relatedTarget* and *target* are the same, skip step 9.3 of http://dom.spec.whatwg.org/#concept-event-listener-invoke. The intent here is to not invoke event listeners on nodes where adjusting both relatedTarget and target resulted on them being the same node -- to prevent widgets sending out useless mouseovers/outs when the user is hovering inside of it. I think that's it :) :DG<
Re: [whatwg] seamless iframes and event propagation
On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren wrote: > On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov > wrote: > > The basic idea here is that some events, when they are dispatched in a > > shadow tree, are more likely implementation details that aren't useful > > outside of this tree. For example, if an with an image of a volume > > control loads inside of a , the author of definitely > doesn't > > want the corresponding "load" event to leak out. > > > > We could come up with some way to control this via a new API, but beware > the > > growl of complexity bear. > > It sounds though like you'd want a different approach to this. What if > I have a as my implementation detail? > Then you probably don't want the "load" events of escaping out of the shadow tree, just as the spec provides. It's an interesting question, though. Along with "load", such implementation detail may dispatch a whole bunch of other events ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents ). Most of these events--at least, following my reasoning--seem like they should just be kept in the shadow tree. I wonder if we would be better off reversing the condition and stopping ALL events, except a set of events whose meaning stays clear after retargeting (like "click"). > > This logic written down in great detail in Shadow DOM spec -- and tested > in > > an actual browser implementation. Would you consider transplanting it > into > > DOM dispatch? > > Well, eventually we might want to merge the whole DOM part of Shadow > DOM and DOM I think, but for now my proposition was that dispatch > calculates its tree in terms of asking for the event parent of a > certain even type from an object. Shadow DOM could use that concept to > define what the parent is. E.g. for a shadow root it would be the > associated element, or not if the event type is something you do not > want to leak, etc. > I think that's cool. cc' me on bug/patch, I want to review it. > > That way when specifications use the dispatch algorithm it > automatically makes sense in the Shadow DOM rather than that you have > to monkey-patch whatever Shadow DOM says on top of DOM, which is > rather bad way of writing specifications. > Yay! Moar hooks! :DG<
Re: [whatwg] seamless iframes and event propagation
On Wed, Dec 5, 2012 at 9:48 AM, Anne van Kesteren wrote: > On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov > wrote: > > Yes, the intent is that in the the events from nodes, distributed to > > insertion points should feel as if there wasn't any shadow tree around > them. > > Right, but if is inside the shadow tree (rather than distributed > into it), you do not want its load/error events to leak? (Again, it > would help if the principles behind those events were written down, > e.g. soonish will start dispatching progress events and who > knows what it might dispatch in the future. That list does not address > either if the same would apply to that element.) > The basic idea here is that some events, when they are dispatched in a shadow tree, are more likely implementation details that aren't useful outside of this tree. For example, if an with an image of a volume control loads inside of a , the author of definitely doesn't want the corresponding "load" event to leak out. We could come up with some way to control this via a new API, but beware the growl of complexity bear. > > So what I want is to tie this into the DOM's dispatch algorithm. The > dispatch algorithm somehow needs to compute the ancestor chain and the > current plan to do that is to follow an "event parent" chain (each > EventTarget would have an "event parent" which is either null or some > other object). However, it seems that is not quite enough for shadow > DOM so instead we need to determine the "event parent" of an object > algorithmically. I think we want "event parent for /event type/". So > e.g. on ShadowRoot objects the "event parent for load" would be null, > whereas for unicorn it would be its host element. > > Does that make sense? > This logic written down in great detail in Shadow DOM spec -- and tested in an actual browser implementation. Would you consider transplanting it into DOM dispatch? > > Ian, for HTML that would allow easily dealing with the load exception > on Window too. > > > -- > http://annevankesteren.nl/ >
Re: [whatwg] seamless iframes and event propagation
On Wed, Dec 5, 2012 at 3:49 AM, Anne van Kesteren wrote: > On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito wrote: > > Some kinds of events should be always stopped at the shadow boundaries. > > See > http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events-that-are-always-stopped > > It's not entirely clear to me what that means. If an ends up > interleaved in a shadow tree through a element, surely the > node tree ancestors of should still get the load event? Does the > shadow tree not want to know this too? > Yes, the intent is that in the the events from nodes, distributed to insertion points should feel as if there wasn't any shadow tree around them: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247 > Also, is input missing from that list? A short explanation along with > that list would probably be good so we know what the criteria are. > Sure, https://www.w3.org/Bugs/Public/show_bug.cgi?id=20248. I can't remember now why I left it out, but I'll find out. > > > > The Shadow DOM spec does not require adjusting mouse coodinates. I > > think every shadow trees in one document *share* the same x-y > > coodinates. > > There are coordinates relative to the target though, see: > http://dev.w3.org/csswg/cssom-view/#extensions-to-the-mouseevent-interface > > I suppose if you do not initialize those on the object but instead > compute them on getting it might work without having to adjust > matters. > Whoa, good catch. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20249 We do indeed cache/reset this value when retargeting in WebKit, but this still needs to be specified. > > > > I don't have a clear idea about what should be cloned when crossing > > boundaries. That's unclear for me. > > Okay, I guess that remains then. > For shadow DOM, we definitely don't need cloning. But it seems critical for seamless iframes. Looking forward, when we do add "isolated" to shadow trees, the shadow DOM will use this plumbing too. :DG<
Re: [whatwg] seamless iframes and event propagation
An interesting quirk here is whether the full list of event ancestors should be computed ahead of time (per http://www.w3.org/TR/dom/#dispatching-events). If yes, then it's still just like retargeting, but with issuing a new event object at the iframe boundary. If no, then two separate dispatches will work as you describe. :DG<
Re: [whatwg] seamless iframes and event propagation
On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay wrote: > > On 07/14/2012 12:38 AM, Ojan Vafai wrote: >> >> It's been pointed out to me that what I'm asking for is essentially the >> same retargeting as we do for shadow DOMs in web components, where the >> iframe is the shadow host and the document is the shadow root. This covers >> all the details of what properties need to be updated when crossing the >> document boundary. The only addition on top of that is that we need to >> convert the coordinate space of mouse events appropriately when we cross >> the boundary. > > > > What, you'd propagate mouse events to parent doc but update coordinate > related coordinates when > passing the doc boundary... that is odd. > Something in the original target document may keep a reference to the event > and then suddenly during event dispatch the > coordinate values would change. We should probably recreate an event object at each seamless frame boundary. :DG<
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, Feb 21, 2012 at 5:36 PM, Boris Zbarsky wrote: > On 2/21/12 7:35 PM, Ian Hickson wrote: >> >> On Sun, 25 Sep 2011, Boris Zbarsky wrote: >>> >>> >>> Not doing that last is actually a requirement for web compat, last I >>> looked at this. >> >> >> Do you have any links to pages that break if a form with more than one >> text field supports implicit submission? > > > Not offhand. Again, it's been a while since I looked into this, but at the > time this was being implemented in Gecko we carefully made the > two-input-no-submit case not submit. I thought that was for good reason, > but reskimming the bugs now I can't find the reason. It's been over 10 > years, so the details are a bit hazy in my mind. :( I made WebKit match this behavior a couple of years ago: https://bugs.webkit.org/show_bug.cgi?id=9756 :DG< > > >>> For those who want to mess with the spec for this behavior, >>> https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and >>> https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and >>> https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but >>> probably not sufficient) reading. >> >> >> I read those bugs, but can't see the reason why submitting a form with two >> text fields and no buttons would break the Web. Can you elaborate? > > > https://bugzilla.mozilla.org/show_bug.cgi?id=22526 is the other bug that > needs reading, but it doesn't help either. I didn't look at the various > (and somewhat numerous) duplicates of the various bugs involved... > > I suppose we could try submitting the "more than one text input, no submit > button" case and see what happens... > > -Boris
Re: [whatwg] Augmenting HTML parser to recognize new elements
On Fri, Jan 20, 2012 at 7:03 AM, Henri Sivonen wrote: > On Wed, Jan 18, 2012 at 8:19 PM, Dimitri Glazkov > wrote: >> A typical example would be specifying an insertion point (that's >> element) as child of a : >> >> >> >> >> ... >> >> >> >> >> Both and elements have similar use cases. > > This doesn't comply with the Degrade Gracefully design principle. Is > this feature so important that it's reasonable to change table parsing > (one of the annoying parts of the parsing algorithm) in a way that'd > make the modified algorithm yield significantly different results than > existing browsers? This is a good question. It is not strictly necessary to change the parsing, since one could always construct the desired tree imperatively as a workaround. However, this does lead to unpleasant surprises for those attempting to use shadow DOM insertion points declaratively. There are use cases that will require dealing with tables and other tags that have special insertion modes. A while back, Boris had mentioned replacing tables with charts (http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Table-based_Charts). Should the developer decide to still include table data somewhere in the chart, they may wish to put something like this in their shadow DOM subtree: ... No data ... Without parser modifications, they would need to build this structure using JS+DOM methods. > Have designs that don't require changes to table > parsing been explored? At one point, we considered using collapsed DOM ranges to represent insertion points. However, this sidesteps possibilities of declarative syntax and thus didn't seem viable. As the next step, I will gather some developer feedback on the degree of unpleasantness arising from parsing behavior, and document it to better understand possible opportunities for improvement. Sounds good? > >> What would be the sane way to document such changes to the HTML parser >> behavior? > > A change to the HTML spec proper *if* we decide that changes are a good idea. > > -- > Henri Sivonen > hsivo...@iki.fi > http://hsivonen.iki.fi/
Re: [whatwg] Augmenting HTML parser to recognize new elements
On Wed, Jan 18, 2012 at 2:00 PM, Adam Barth wrote: > On Wed, Jan 18, 2012 at 1:55 PM, Dimitri Glazkov > wrote: >> On Wed, Jan 18, 2012 at 1:47 PM, Adam Barth wrote: >>> On Wed, Jan 18, 2012 at 1:29 PM, Dimitri Glazkov >>> wrote: >>>> On Wed, Jan 18, 2012 at 1:14 PM, Dimitri Glazkov >>>> wrote: >>>>> Ah, that's a good question. This also must be specified. It should >>>>> depend on the parent of the element. If the parent is shadow >>>>> root or , then it should make the child of . >>>>> Otherwise, it should use foster parenting as usual. >>>> >>>> Oops, not "foster parenting", but "ignore" as you mentioned. Still >>>> getting through the details of the parsing spec. >>> >>> There's also some subtly w.r.t. the pending character tokens. >>> >>> More generally, I think we'd all be much more sane if the HTML parsing >>> algorithm was specified in the HTML living standard rather than >>> modified ad-hoc in a number of different documents. >> >> That makes sense, but how will we handle the fact that the elements in >> the algorithm aren't part of the HTML specification? > > Through the magic of legacy support, that's already the case today! > (I'm looking at you .) > > The parsing algorithm just says how to construct a DOM. You can have > all sorts of crazy futuristic/obsolete elements in the DOM. This sounds bewildering yet encouraging. Should I just attempt writing a patch against the spec and ask Hixie to review it? :DG< > > Adam > > >>>>> On Wed, Jan 18, 2012 at 10:58 AM, Ryosuke Niwa wrote: >>>>>> What if content wrapped elements ignored by the parser. e.g. >>>>>> hi >>>>>> >>>>>> What should the content element include in that case? >>>>>> >>>>>> - Ryosuke >>>>>> >>>>>> On Jan 18, 2012 10:19 AM, "Dimitri Glazkov" >>>>>> wrote: >>>>>>> >>>>>>> 'sup, Whatwg! >>>>>>> >>>>>>> The new HTML elements in the shadow DOM spec >>>>>>> (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html) >>>>>>> and the nascent HTML templates spec (see it all explained here: >>>>>>> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html) >>>>>>> require tweaking of the HTML parsing behavior -- mostly the tree >>>>>>> construction bits. >>>>>>> >>>>>>> A typical example would be specifying an insertion point (that's >>>>>>> element) as child of a : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Both and elements have similar use cases. >>>>>>> >>>>>>> What would be the sane way to document such changes to the HTML parser >>>>>>> behavior? A list of modifications to tree construction modes in each >>>>>>> respective spec? Some "generic insertion point element" clause in the >>>>>>> HTML spec? Give me ideas. >>>>>>> >>>>>>> Also -- what are the side effects of such a change? Surely, there's >>>>>>> something I am not thinking of. >>>>>>> >>>>>>> :DG<
Re: [whatwg] Augmenting HTML parser to recognize new elements
On Wed, Jan 18, 2012 at 1:47 PM, Adam Barth wrote: > On Wed, Jan 18, 2012 at 1:29 PM, Dimitri Glazkov > wrote: >> On Wed, Jan 18, 2012 at 1:14 PM, Dimitri Glazkov >> wrote: >>> Ah, that's a good question. This also must be specified. It should >>> depend on the parent of the element. If the parent is shadow >>> root or , then it should make the child of . >>> Otherwise, it should use foster parenting as usual. >> >> Oops, not "foster parenting", but "ignore" as you mentioned. Still >> getting through the details of the parsing spec. > > There's also some subtly w.r.t. the pending character tokens. > > More generally, I think we'd all be much more sane if the HTML parsing > algorithm was specified in the HTML living standard rather than > modified ad-hoc in a number of different documents. That makes sense, but how will we handle the fact that the elements in the algorithm aren't part of the HTML specification? :DG< > > Adam > > >>> On Wed, Jan 18, 2012 at 10:58 AM, Ryosuke Niwa wrote: >>>> What if content wrapped elements ignored by the parser. e.g. >>>> hi >>>> >>>> What should the content element include in that case? >>>> >>>> - Ryosuke >>>> >>>> On Jan 18, 2012 10:19 AM, "Dimitri Glazkov" wrote: >>>>> >>>>> 'sup, Whatwg! >>>>> >>>>> The new HTML elements in the shadow DOM spec >>>>> (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html) >>>>> and the nascent HTML templates spec (see it all explained here: >>>>> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html) >>>>> require tweaking of the HTML parsing behavior -- mostly the tree >>>>> construction bits. >>>>> >>>>> A typical example would be specifying an insertion point (that's >>>>> element) as child of a : >>>>> >>>>> >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> Both and elements have similar use cases. >>>>> >>>>> What would be the sane way to document such changes to the HTML parser >>>>> behavior? A list of modifications to tree construction modes in each >>>>> respective spec? Some "generic insertion point element" clause in the >>>>> HTML spec? Give me ideas. >>>>> >>>>> Also -- what are the side effects of such a change? Surely, there's >>>>> something I am not thinking of. >>>>> >>>>> :DG<
Re: [whatwg] Augmenting HTML parser to recognize new elements
On Wed, Jan 18, 2012 at 1:14 PM, Dimitri Glazkov wrote: > Ah, that's a good question. This also must be specified. It should > depend on the parent of the element. If the parent is shadow > root or , then it should make the child of . > Otherwise, it should use foster parenting as usual. Oops, not "foster parenting", but "ignore" as you mentioned. Still getting through the details of the parsing spec. > > :DG< > > On Wed, Jan 18, 2012 at 10:58 AM, Ryosuke Niwa wrote: >> What if content wrapped elements ignored by the parser. e.g. >> hi >> >> What should the content element include in that case? >> >> - Ryosuke >> >> On Jan 18, 2012 10:19 AM, "Dimitri Glazkov" wrote: >>> >>> 'sup, Whatwg! >>> >>> The new HTML elements in the shadow DOM spec >>> (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html) >>> and the nascent HTML templates spec (see it all explained here: >>> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html) >>> require tweaking of the HTML parsing behavior -- mostly the tree >>> construction bits. >>> >>> A typical example would be specifying an insertion point (that's >>> element) as child of a : >>> >>> >>> >>> >>> ... >>> >>> >>> >>> >>> Both and elements have similar use cases. >>> >>> What would be the sane way to document such changes to the HTML parser >>> behavior? A list of modifications to tree construction modes in each >>> respective spec? Some "generic insertion point element" clause in the >>> HTML spec? Give me ideas. >>> >>> Also -- what are the side effects of such a change? Surely, there's >>> something I am not thinking of. >>> >>> :DG<
Re: [whatwg] Augmenting HTML parser to recognize new elements
Ah, that's a good question. This also must be specified. It should depend on the parent of the element. If the parent is shadow root or , then it should make the child of . Otherwise, it should use foster parenting as usual. :DG< On Wed, Jan 18, 2012 at 10:58 AM, Ryosuke Niwa wrote: > What if content wrapped elements ignored by the parser. e.g. > hi > > What should the content element include in that case? > > - Ryosuke > > On Jan 18, 2012 10:19 AM, "Dimitri Glazkov" wrote: >> >> 'sup, Whatwg! >> >> The new HTML elements in the shadow DOM spec >> (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html) >> and the nascent HTML templates spec (see it all explained here: >> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html) >> require tweaking of the HTML parsing behavior -- mostly the tree >> construction bits. >> >> A typical example would be specifying an insertion point (that's >> element) as child of a : >> >> >> >> >> ... >> >> >> >> >> Both and elements have similar use cases. >> >> What would be the sane way to document such changes to the HTML parser >> behavior? A list of modifications to tree construction modes in each >> respective spec? Some "generic insertion point element" clause in the >> HTML spec? Give me ideas. >> >> Also -- what are the side effects of such a change? Surely, there's >> something I am not thinking of. >> >> :DG<
[whatwg] Augmenting HTML parser to recognize new elements
'sup, Whatwg! The new HTML elements in the shadow DOM spec (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html) and the nascent HTML templates spec (see it all explained here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html) require tweaking of the HTML parsing behavior -- mostly the tree construction bits. A typical example would be specifying an insertion point (that's element) as child of a : ... Both and elements have similar use cases. What would be the sane way to document such changes to the HTML parser behavior? A list of modifications to tree construction modes in each respective spec? Some "generic insertion point element" clause in the HTML spec? Give me ideas. Also -- what are the side effects of such a change? Surely, there's something I am not thinking of. :DG<
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
Hi folks -- I wrote a fairly comprehensive test suite to capture al this a while back: http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/implicit-submission.html Hope it helps! :DG< On Sat, Sep 24, 2011 at 1:52 PM, Ryosuke Niwa wrote: > On Sat, Sep 24, 2011 at 9:47 AM, Ryosuke Niwa wrote: >> >> WebKit's behavior is very confusing here. It does implicit submission in >> the following conditions: >> >> - One text fields >> - Two text fields >> >> > Correction. WebKit does NOT do implicit submision for two text fields when > there are no submit buttons. > > - Ryosuke >
Re: [whatwg] Selectors within
@global seems cool. Roland, WDYT? :DG<
Re: [whatwg] Selectors within
I actually really like this proposal. Let's do this. Roland, Dave, Boris -- what do y'all think? :DG< On Fri, Jun 17, 2011 at 1:04 PM, Kornel Lesiński wrote: > On Thu, 16 Jun 2011 19:32:42 +0100, Dimitri Glazkov > wrote: > >> What if we do this: >> >> 1) By default,
Re: [whatwg] Selectors within
What if we do this: 1) By default,
Re: [whatwg] Selectors within
On Thu, Jun 16, 2011 at 2:11 AM, Lachlan Hunt wrote: > On 2011-06-15 08:40, Roland Steiner wrote: >> >> According to the HMTL5 spec, selectors are not limited to children of the >> scoping element (the parent element of). For example: >> >>>>>>