Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, Dec 3, 2013 at 10:32 PM, Jonas Sicking jo...@sicking.cc wrote: On Dec 3, 2013 9:39 PM, Dimitri Glazkov dglaz...@chromium.org 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 select 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 Wed, Dec 4, 2013 at 10:30 AM, Ian Hickson i...@hixie.ch 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 9:30 PM, Jonas Sicking jo...@sicking.cc wrote: On Dec 3, 2013 9:16 PM, Ian Hickson i...@hixie.ch 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 selects that would have made the transition to mobile much more painful since you'd get a tiny custom select 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 dglaz...@chromium.org wrote: On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren ann...@annevk.nl 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 Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote: My bad, I actually meant if a's associated shadow tree had an insertion point through which a's child, which is b, would go and then the event would be dispatched in b'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): a -- [shadow root] - .. - insertion point -- b -- [shadow root] - .. - c In this case, the adjustment happens twice, at b and a. 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 Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren ann...@annevk.nl wrote: My bad, I actually meant if a's associated shadow tree had an insertion point through which a's child, which is b, would go and then the event would be dispatched in b'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): a -- [shadow root] - .. - insertion point -- b -- [shadow root] - .. - c In this case, the adjustment happens twice, at b and a. Normally with b being a child of a 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 Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov dglaz...@chromium.org 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 11:14 AM, Anne van Kesteren ann...@annevk.nl wrote: Normally with b being a child of a 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:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 11, 2013 at 8:16 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren ann...@annevk.nl 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:56 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov dglaz...@chromium.org 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 Tue, Jan 8, 2013 at 6:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov dglaz...@chromium.org 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 a - shadow - b - shadow and an event is dispatched in b's shadow event's target is only adjusted on b right? It does not need to be adjusted further for a's shadow or a? Does shadow stand for the actual shadow 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 a -- [shadow root] - b -- [shadow root] - c (where - denotes child-parent relationship and -- denotes host-root relationship) 2) if an event is dispatched on c 3) where is the event target's adjusted? If that's the question, then it needs to be adjusted twice: at b (the adjusted target becomes b) and at a (the adjusted target becomes a). 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 details
On Mon, Jan 7, 2013 at 2:25 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jan 6, 2013 at 8:36 PM, Dimitri Glazkov dglaz...@chromium.org wrote: So I wouldn't call this exactly vaporware :) I cannot get it to work for select. 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=82313hide_resolved=1 But this is certainly interesting. It would require details to be defined in terms of shadow trees, or not? As otherwise the triangle in Chrome's implementation would not disappear so easily... While details 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 details
On Wed, Jan 2, 2013 at 9:10 PM, Ian Hickson i...@hixie.ch 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 details 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 dglaz...@chromium.orgwrote: 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 ann...@annevk.nlwrote: 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 ann...@annevk.nl wrote: On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov dglaz...@chromium.org 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 img with an image of a volume control loads inside of a video, the author of video 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 video as my implementation detail? Then you probably don't want the load events of video 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 ann...@annevk.nl wrote: On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov dglaz...@chromium.org 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 img 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 img will start dispatching progress events and who knows what it might dispatch in the future. That list does not address video 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 img with an image of a volume control loads inside of a video, the author of video 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 ann...@annevk.nl wrote: On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito hay...@chromium.org 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 img ends up interleaved in a shadow tree through a content element, surely the node tree ancestors of img 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 olli.pet...@helsinki.fi 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 bzbar...@mit.edu 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 hsivo...@iki.fi wrote: On Wed, Jan 18, 2012 at 8:19 PM, Dimitri Glazkov dglaz...@chromium.org wrote: A typical example would be specifying an insertion point (that's content element) as child of a table: table content tr ... /tr /content /table Both shadow and template 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: ... table content trtdNo data/td/tr /content /table ... 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/
[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 content element) as child of a table: table content tr ... /tr /content /table Both shadow and template 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 content element. If the parent is shadow root or table, then it should make tr the child of content. Otherwise, it should use foster parenting as usual. :DG On Wed, Jan 18, 2012 at 10:58 AM, Ryosuke Niwa rn...@webkit.org wrote: What if content wrapped elements ignored by the parser. e.g. contenttrhi/tr/content What should the content element include in that case? - Ryosuke On Jan 18, 2012 10:19 AM, Dimitri Glazkov dglaz...@chromium.org 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 content element) as child of a table: table content tr ... /tr /content /table Both shadow and template 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 dglaz...@chromium.org wrote: Ah, that's a good question. This also must be specified. It should depend on the parent of the content element. If the parent is shadow root or table, then it should make tr the child of content. 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 rn...@webkit.org wrote: What if content wrapped elements ignored by the parser. e.g. contenttrhi/tr/content What should the content element include in that case? - Ryosuke On Jan 18, 2012 10:19 AM, Dimitri Glazkov dglaz...@chromium.org 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 content element) as child of a table: table content tr ... /tr /content /table Both shadow and template 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 w...@adambarth.com wrote: On Wed, Jan 18, 2012 at 1:29 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Jan 18, 2012 at 1:14 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Ah, that's a good question. This also must be specified. It should depend on the parent of the content element. If the parent is shadow root or table, then it should make tr the child of content. 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 rn...@webkit.org wrote: What if content wrapped elements ignored by the parser. e.g. contenttrhi/tr/content What should the content element include in that case? - Ryosuke On Jan 18, 2012 10:19 AM, Dimitri Glazkov dglaz...@chromium.org 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 content element) as child of a table: table content tr ... /tr /content /table Both shadow and template 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 rn...@webkit.org wrote: On Sat, Sep 24, 2011 at 9:47 AM, Ryosuke Niwa rn...@webkit.org 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 style scoped
@global seems cool. Roland, WDYT? :DG
Re: [whatwg] Selectors within style scoped
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 kor...@geekhood.net wrote:
On Thu, 16 Jun 2011 19:32:42 +0100, Dimitri Glazkov dglaz...@chromium.org
wrote:
What if we do this:
1) By default, style scoped implies that all selectors in this
stylesheet are prefixed with :scope.
2) Unless the :scope is already in the selector.
That feels magical and a bit backwards to me.
Why not scope all selectors except ones starting with :root?
.foo {scoped}
:root .foo {matches outside scope}
--
regards, Kornel Lesiński
Re: [whatwg] Selectors within style scoped
On Thu, Jun 16, 2011 at 2:11 AM, Lachlan Hunt lachlan.h...@lachy.id.au 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 ofstyle scoped). For example:
div class=foo
div
style scoped
.foo p { display: none }
/style
pTo be or not to be, that is the question./p
/div
div
In above snippet, the selector in the scoped stylesheet would match,
causing
thep element to be hidden...
The disadvantages:
1.) a scoped style may unexpectedly apply, because an arbitrary ancestor
of
the scoping element happens to partially match the scoped selector
This is the purpose of the :scope pseudo-class that is defined to match the
contextual reference elemnt, which for scoped stylesheets, will be the
parent of the style element.
So you could rewrite the style above to be:
:scope .foo p { display: none }
Then .foo will only match elements within the div.
http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class
This seems like it would allow us to pursue both use cases.
But looking at this with my Web developer hat on, I would almost
_always_ prefix scoped rules with :scope, just to be safe. I certainly
don't want my .closed .foo { display:none } to start reacting to
some doofus syndicating my code in the wrong way. I can see how this
logic quickly downgrades :scope to syntactic shellack.
I think we should ask how Web developers would view this. I am pretty
sure that their intuitive understanding of style scoped is that all
rules are implicitly prefixed with :scope.
:DG
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Selectors within style scoped
What if we do this:
1) By default, style scoped implies that all selectors in this
stylesheet are prefixed with :scope.
2) Unless the :scope is already in the selector.
:DG
On Thu, Jun 16, 2011 at 10:40 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Jun 16, 2011 at 10:28 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
But looking at this with my Web developer hat on, I would almost
_always_ prefix scoped rules with :scope, just to be safe. I certainly
don't want my .closed .foo { display:none } to start reacting to
some doofus syndicating my code in the wrong way. I can see how this
logic quickly downgrades :scope to syntactic shellack.
I think we should ask how Web developers would view this. I am pretty
sure that their intuitive understanding of style scoped is that all
rules are implicitly prefixed with :scope.
As a web developer, I agree - my intuitive understanding of @scoped is
that it makes matching *start* at the scoped element. That's what
scoped means. The other meaning is more like a filter.
I was convinced that @scoped worked exactly like this until this
thread. Apparently my previous reading of the spec was insufficiently
deep to spot the scoping/filtering difference.
FWIW, I also think that querySelector got this wrong. It should have
scoped by default, and then possibly also offered an option to filter
based on an element.
~TJ
Re: [whatwg] Selectors within style scoped
On Tue, Jun 14, 2011 at 11:50 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 15 Jun 2011, Roland Steiner wrote:
According to the HMTL5 spec, selectors are not limited to children of
the scoping element (the parent element of style scoped). For example:
div class=foo
div
style scoped
.foo p { display: none }
/style
pTo be or not to be, that is the question./p
/div
div
In above snippet, the selector in the scoped stylesheet would match,
causing the p element to be hidden. To me, this seems counterintuitive
- I originally would have the scoped stylesheet expected to be matched
starting from the scoping element (the 2nd div in above example)
downwards, and not cross the scope boundary.
As far as I can tell, the advantages of allowing the selector to cross
the boundary are:
1.) less change to selection behavior
2.) allow the styling to change depending where the scoping element is
inserted within the document
It also allows a number of other use cases, e.g. having styles when the
user is hovering over some ancestor of the section (:hover on ancestor),
changing style when the page URL is targetting some ancestor of the
section (:target on ancestor), distinguishing whether the section is
embedded in blockquote or article and using different styles in those
cases (e.g. using more of the source's branding if it's in article and
letting more of the page style show through if it's in blockquote),
coordination with the syndicator so that specific classes can be set up to
allow the styles to automatically distinguish whether the section was
embedded through user choice or through some seredipity algorithm, etc.
The disadvantages:
1.) a scoped style may unexpectedly apply, because an arbitrary ancestor of
the scoping element happens to partially match the scoped selector
2.) have to be very careful with using simple HTML tags in scoped selectors,
because of 1.)
3.) also because of 1.) have to be careful about recursive use of style
scopes - either programmatically generated, or in the course of XBL.
XBL2 specifically gives the author control over this issue, because it is
indeed a problem in a widget scoped style scenario.
That's http://dev.w3.org/2006/xbl2/Overview.html#allow-selectors-through, right?
I don't think these
disadvantages are likely to be common in the syndication use case, though:
typically, the ancestors are going to be pretty tame (a bunch of divs,
an article, maybe a section, probably little else).
--
Ian Hickson U+1047E )\._.,--,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
On Mon, Apr 25, 2011 at 7:13 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Mon, Apr 25, 2011 at 4:04 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Based on WebKit's current media controls, let's start with these pseudo-classes: Play state: - loading - playing - streaming - error What's the difference between 'playing' and 'streaming'? Currently I don't think we have anything that defines this in the spec. I am a total ignoramus of the spec, but in WebKit, streaming audio/video has slightly different UI (no rewind or back/forward buttons, etc.) Capabilities: - no-audio - no-video - has-closed-captioning Wouldn't it be better to have has-audio and has-video instead? Positive terms usually work better than negated terms. True, but has-audio is the default, so I'd rather not have to suddenly start video + div.volume-button only match when there's no audio. Or otherwise introduce both has-audio and no-audio. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
Based on WebKit's current media controls, let's start with these pseudo-classes:
Play state:
- loading
- playing
- streaming
- error
Capabilities:
- no-audio
- no-video
- has-closed-captioning
So, to show a status message while the control is loading or streaming
and hide when it's done:
video -webkit-media-controls-status-display {
display: none;
}
video:loading -webkit-media-controls-status-display, video:streaming
-webkit-media-controls-status-display {
display: initial;
...
}
Similarly, to hide volume controls when there's no audio:
video:no-audio -webkit-media-controls-volume-slider-container {
display: none;
}
Once I put these pseudo-classes in place for WebKit, a lot of the code
in
http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/shadow/MediaControlRootElement.cppexact_package=chromium
will go away, being replaced with straight CSS.
:DG
On Sun, Apr 24, 2011 at 8:31 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
A markup and CSS example would make things clearer. How do you think
it would look?
Silvia.
On Sun, Apr 24, 2011 at 9:40 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Sat, Apr 23, 2011 at 1:57 PM, Philip Jägenstedt phil...@opera.com wrote:
On Sat, 23 Apr 2011 21:32:06 +0200, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Sat, Apr 23, 2011 at 11:37 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Sat, 23 Apr 2011 17:02:56 +0200, Dimitri Glazkov
dglaz...@chromium.org
wrote:
On Sat, Apr 23, 2011 at 2:57 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Sat, 23 Apr 2011 05:25:20 +0200, Dimitri Glazkov
dglaz...@chromium.org
wrote:
I wonder if it makes sense to introduce a set of pseudo-classes on the
video/audio elements, each reflecting a state of the media on the
controls (playing/paused/error/etc.)? Then, we could use just CSS to
style media controls (whether native or custom), and not have to
listen to DOM events just to tweak their appearance.
With a sufficiently large set of pseudo-classes it might be possible to
do
*display* most of the interesting state, but how would you *change* the
state without using scripts? Play/pause, seek, volume, etc...
This is not the goal of using pseudo-classes: they just provide you
with a uniform way to react to changes.
In other words, one would still have to rely heavily on scripts to
actually
implement custom controls?
Heavily is subjective. But yep :)
Also, how would one style a progress bar using pseudo-classes? How about
a
displaying elapsed/remaining time on the form MM:SS?
I am not in any way trying to invent a magical way to style media
controls entirely in CSS. Just trying to make the job of controls
developers easier and use CSS where it's well... useful? :)
Very well, what specific set pseudo-classes do you think would be useful?
I can infer what would be useful from WebKit's media controls as a first
stab?
:DG
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
On Sat, Apr 23, 2011 at 2:57 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 05:25:20 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: I wonder if it makes sense to introduce a set of pseudo-classes on the video/audio elements, each reflecting a state of the media on the controls (playing/paused/error/etc.)? Then, we could use just CSS to style media controls (whether native or custom), and not have to listen to DOM events just to tweak their appearance. With a sufficiently large set of pseudo-classes it might be possible to do *display* most of the interesting state, but how would you *change* the state without using scripts? Play/pause, seek, volume, etc... This is not the goal of using pseudo-classes: they just provide you with a uniform way to react to changes. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
On Sat, Apr 23, 2011 at 11:37 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 17:02:56 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Sat, Apr 23, 2011 at 2:57 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 05:25:20 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: I wonder if it makes sense to introduce a set of pseudo-classes on the video/audio elements, each reflecting a state of the media on the controls (playing/paused/error/etc.)? Then, we could use just CSS to style media controls (whether native or custom), and not have to listen to DOM events just to tweak their appearance. With a sufficiently large set of pseudo-classes it might be possible to do *display* most of the interesting state, but how would you *change* the state without using scripts? Play/pause, seek, volume, etc... This is not the goal of using pseudo-classes: they just provide you with a uniform way to react to changes. In other words, one would still have to rely heavily on scripts to actually implement custom controls? Heavily is subjective. But yep :) Also, how would one style a progress bar using pseudo-classes? How about a displaying elapsed/remaining time on the form MM:SS? I am not in any way trying to invent a magical way to style media controls entirely in CSS. Just trying to make the job of controls developers easier and use CSS where it's well... useful? :) -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
On Sat, Apr 23, 2011 at 1:57 PM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 21:32:06 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Sat, Apr 23, 2011 at 11:37 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 17:02:56 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Sat, Apr 23, 2011 at 2:57 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 05:25:20 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: I wonder if it makes sense to introduce a set of pseudo-classes on the video/audio elements, each reflecting a state of the media on the controls (playing/paused/error/etc.)? Then, we could use just CSS to style media controls (whether native or custom), and not have to listen to DOM events just to tweak their appearance. With a sufficiently large set of pseudo-classes it might be possible to do *display* most of the interesting state, but how would you *change* the state without using scripts? Play/pause, seek, volume, etc... This is not the goal of using pseudo-classes: they just provide you with a uniform way to react to changes. In other words, one would still have to rely heavily on scripts to actually implement custom controls? Heavily is subjective. But yep :) Also, how would one style a progress bar using pseudo-classes? How about a displaying elapsed/remaining time on the form MM:SS? I am not in any way trying to invent a magical way to style media controls entirely in CSS. Just trying to make the job of controls developers easier and use CSS where it's well... useful? :) Very well, what specific set pseudo-classes do you think would be useful? I can infer what would be useful from WebKit's media controls as a first stab? :DG -- Philip Jägenstedt Core Developer Opera Software
[whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
I wonder if it makes sense to introduce a set of pseudo-classes on the video/audio elements, each reflecting a state of the media on the controls (playing/paused/error/etc.)? Then, we could use just CSS to style media controls (whether native or custom), and not have to listen to DOM events just to tweak their appearance. :DG
Re: [whatwg] Criticism of pushState (was Global Script proposal)
On Mon, Sep 7, 2009 at 4:40 PM, Justin Lebarjustin.le...@gmail.com wrote:
Dimitri Glazkov wrote:
But more to the point, I think globalScript is a good replacement for
the pushState additions to the History spec.
I'm not sure I agree. pushState lets you change the URI very quickly,
without doing any kind of navigation at all. To emulate a pushSate
with globalScript, you'd have to save and restore the whole document,
and the browser would still have to do at least one network request,
unless you were only changing the hash of the URI.
pushState does let you change the URI very quickly -- you're exactly
right! But it doesn't do anything else. The implementor still has to
grapple with the same problems as they did with the hash-navigation,
and that doesn't seem like much of an improvement.
I am becoming
somewhat convinced that pushState is confusing, hard to get right, and
full of fail. You should simply look at the motivation behind building
JS-based history state managers -- it all becomes fairly clear.
Could you elaborate on these points? It seems to me that pushState
attacks a specific problem and delivers a simple solution which is
much better than the current workarounds (using the URL's hash to
identify a page and store state). Yes, it's nontrivial to develop an
AJAX app which uses pushState and works correctly with bookmarking and
page refreshes. On the other hand, pushState makes this a lot easier
than it would be otherwise.
The problem pushState attacks is specific, correct. But IMHO it is too
specific -- you're trying to treat the symptom, not the root cause.
Why do developers want to reinvent the entire URL hierarchies -- and
elaborate ways of managing them! -- inside of the hashes? Because they
want cheap navigation. Why do they want cheap navigation? Because
there is no easy way to preserve tons of JS code that's been already
loaded and primed. With globalScript, they no longer have this
problem.
Just think about it -- load jquery (for instance) with tons
extensions, and reuse it on any page of your site. No need to load it
or re-initialize. Ideally, I should be able to do this:
function onContentLoaded() {
if (!globalObject.loaded())
globalObject.load();
document.body.appendChild(globalObject.uiNode());
}
.. and only hit .load() method once per browsing session.
Your entire controller survives navigation. Your pages become the
model, only delivering the minimum of markup (data). It's a much more
natural model from pretty much any reasonable perspective (that I know
of).
Then why the heck would we want to come up with a fancier way to
provide hash-navigation?
My big issue with pushHistory is that it messes with the nature of the
Web: a URL is a resource you request from the server. Not something
you arrive to via clever sleight of hand in a user agent.
Like it or not, this ship has already sailed. When I load Gmail, I'm
taken to https://mail.google.com/mail/#inbox, but my browser never
sends #inbox to the server as part of the HTTP request. Pandora and
Facebook do something like this too. Perhaps the new intuition is
that a URL tells you how to get back to where you were.
Again, you're diagnosing a symptom. Hashes were never supposed to go
back to the server. These hash-navigation controllers are workarounds.
Let's not create a better workaround.
Once you introduce pushState, you deviate from the normalcy -- now you
can have a URL in the address bar that the user agent hasn't requested
from the server.
So, you've managed to pushState your way to
a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks
it. What are you going to do know?
When reading this message in Gmail, my browser shows that I'm at
https://mail.google.com/mail/#label/WhatWG/{guid} . If I bookmark
this page and go back to it, Gmail takes me back to this exact
message. There's no actual resource named #label/WhatWG/{guid} on
Google's servers, but the URL I bookmarked is sufficient to identify
where I was, and Gmail's servers were intelligent enough to take me
there.
It's not the server that's intelligent. It's the URL controller in
Gmail's JS code -- in addition to the one on the server. Since hash is
never sent to the server, the user-agent-side hash-navigation
controllers have to be intelligent enough to figure out what to do.
That's another point where I see a failing of the pushState concept:
once you extend this to actual URLs, they will have to be just as
smart or even smarter to figure out the state to which they are
supposed to bring the page. So we're not really saving much beyond
cosmetics.
Maybe you think that Gmail's URLs should name real resources; maybe
they should look like
https://mail.google.com/mail.cgi?label=WhatWGmessage={guid} or
something. I'm not convinced this is better, but even if it suits
you, pushState still helps you navigate between mail.cgi?label=WhatWG
and mail.cgi?label=Drafts without a page refresh.
It's
Re: [whatwg] Global Script proposal.
On Tue, Sep 8, 2009 at 6:12 AM, Anne van Kesterenann...@opera.com wrote: FWIW, this is why I think pushState is great. If you bookmark it and later visit that page it allows the server to directly give the right content back instead of first loading a page which then fetches additional content based on the fragment identifier. And although disabling JavaScript these days is probably close to a non-starter it would allow you to create interfaces that have the same URL regardless of whether JavaScript is enabled or disabled and still use fancy effects and downloaded content incrementally when JavaScript is enabled. True, that's a benefit -- compared to the current hash-navigation systems. But I guess what I am trying to say is let's work to provide ways to make navigation cheap, rather than improving ways to simulate navigation. :DG
Re: [whatwg] Criticism of pushState (was Global Script proposal)
On Tue, Sep 8, 2009 at 9:21 AM, Justin Lebarjustin.le...@gmail.com wrote: To be clear, I'm not suggesting that pushState obviates the need for global script. My point is that pushState is useful in its own right, with our without global script. Without pushstate, you can't make a non-hash navigation without hitting the network. Even if you're clever and store all of JQuery and your whole DOM in global storage, if you want to change the pre-hash part of the URI, you need to load a new page. Imagine Google Maps trying to update the URI to match your current location as you pan around the map. Right now, they could update the hash as you panned. With pushstate, they could update the URI in an arbitrary way. With global state, they'd have to load a new page every time you panned. That's obviously worse, and probably not even an option. Ah, that's a use case I haven't thought of -- although now that you mentioned it, I vaguely remember reading about it. You're right, this one looks like a valid and appropriate use of pushState. Then why the heck would we want to come up with a fancier way to provide hash-navigation? Perhaps the point is to do something which works like hash-navigation, but to the user, looks like real navigation. Imagine Bugzilla using pushstate to navigate between bugs, but keeping the familiar show_bug.cgi?id=1234 URI. I don't pretend that the code necessary to make this work would be easy to write, but it's certainly no more difficult than changing the hash, and the resulting URLs are much nicer. Once you introduce pushState, you deviate from the normalcy -- now you can have a URL in the address bar that the user agent hasn't requested from the server. Again, this is just what happens when you're at your Gmail Inbox and click a link to http://mail.google.com/mail/#Drafts. You now have a URL in the address bar that the UA hasn't requested from the server. pushState improves this -- at least now the URL you didn't request from the server looks like one which you plausibly might have requested from the server. I guess what I was trying to say is that the server is completely blind to hashes, so both http://mail.google.com/mail/#Drafts and http://mail.google.com/mail/#inbox are the same URL from its perspective: http://mail.google.com/mail/, and that has been the case since the browsers were born (I think). I really don't care about how the URLs look. I just want the Web development to be easier. And in my humble opinion, building a request controller in JS and essentially a whole alternative reality navigation system using hashes is not. If you don't care how URLs look or if you don't mind making a network request when you navigate a page, then don't use the feature! A lot of people do care about one or both of those things, though, and they're willing to go through the pain of developing these alternative-reality navigation systems. PushState does not subsume global script. For many applications, storing the whole DOM in global script would get you sufficiently fast navigations -- I agree. But global script does not subsume pushState, either. Even with global script, you can't change the URI arbitrarily without navigating the page. Panning on Google Maps and changing the referer sent to a page are two instances where extra page navigations might be unacceptable. Ok, this sounds reasonable. :DG
[whatwg] Database storage API and argument type conversion
It would be a good thing to specify some standard way to convert argument types for the executeSql call. This question was first raised on public-html list (http://lists.w3.org/Archives/Public/public-html/2008Feb/0401.html), suggesting that the types, not directly supported by the database engine (SQLite seems to be the logical choice) are treated as strings. In other words, if the type of the argument is not null, string, double, or int, the argument is implicitly converted to to string. As an alternative, I would like to present a slightly different approach: if, during step 3 of the executeSql algorithm (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html#executing), an argument is found to be unpalatable for the underlying database implementation, the statement is marked bogus. Though a bit more stringent than the implicit conversion, this approach explicitly prevents any subtle coercion bugs and will probably lead to more debuggable code. What are your thoughts on this, oh wise WHATWG oracle? :DG
[whatwg] SQL storage API: optional name, version of the openDatabase()
Is there any reason not to make name and version of the openDatabase() method in the SQL storage spec optional (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html)? In some implementations, there may not be an opportunity to offer a UI where these parameters will be used. :DG
[whatwg] Moving openDatabase off the UI thread
In the current SQL storage spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html), all database operations can be nicely tucked onto a separate thread, so that they don't block the UI thread, except for one place: openDatabase has to query version information and open or create the database. This seems a bit out-of-sync (oh no, bad pun) with the rest of the spec, where everything is asynchronous. Would it be more logical/practical to explicitly (per spec) move the actual opening of the database off the main thread? Like so: Verifying database version and opening/creation of the database occurs at pre-flight of the transaction, unless the database is already open. Thus, no potential UI thread blockage by the database operations during openDatabase invocation, as well as no need to raise the INVALID_STATE_ERR exception. What do you think? :DG
Re: [whatwg] SQL storage API: optional name, version of the openDatabase()
Doh! I apologize. This has not been one of my shiniest moments. In addition to what Aaron says, I actually meant the reverse: only name and version being required (potentially with version optional, as he suggests), and display name and estimated size being optional. :DG On Thu, Apr 10, 2008 at 11:42 AM, Aaron Boodman [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 9:26 AM, Timothy Hatcher [EMAIL PROTECTED] wrote: Name and version is not just used for UI, it is used to specify what database to open and to prevent schema conflicts. Whoops, yeah. This request actually originally comes from me, and what I was referring to was the version parameter to open(). It can currently be the empty string, but it cannot be omitted. Any reason why not? Some (most?) applications will not need this field and it seems unfortunate to force them to pass an empty string. - a
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
Geoff, These are all good questions. I apologize, this was a spur-of-the-moment write-down-before-it-goes-away post. And as such, it's skimp on the meat. If anything, it was a good enough nudge for Aaron and Hixie to release their proposals. What I did want to capture is the idea of API familiarity to that could exist inside of a worker, so that the developers operate with the same (though a subset of) methods and properties as they would outside of the worker and use the same postMessage API to communicate with the workers as they would with other windows. :DG On Thu, Feb 14, 2008 at 5:05 PM, Geoffrey Garen [EMAIL PROTECTED] wrote: Since postMessage API is looking more an more like the Gears worker messaging API (or better), can we go one step further and introduce workers into the HTML5, defined as invisible windows with limited capabilities: Why call these windows at all? They seem to have no relationship physical windows, or the JavaScript window object. WorkerWindow openWorker(in DOMString url); Can I supply a URL to an HTML file here? Does the file load and parse as an HTML document? Is the document accessible to the worker? Since the whole point of the worker is to do JavaScript work, should this string be a script instead of a URL? How do I pass data to a worker? Is there an API contract regarding synchronization and/or order of execution? // some events attribute EventListener onabort; attribute EventListener onload; attribute EventListener onunload; Why these events? When is a worker considered loaded? Unloaded? Aborted? Thanks, Geoff
[whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
workers into the HTML5, defined as invisible windows with limited
capabilities:
WorkerWindow openWorker(in DOMString url);
with:
interface WorkerWindow {
// for consistency with Window
readonly attribute Window window;
readonly attribute Window self;
// caps
readonly attribute ClientInformation navigator;
// session/local storage
readonly attribute Storage sessionStorage;
...
// database stuff
Database openDatabase(...)
// to open new worker windows
WorkerWindow openWorker(in DOMString url);
// messaging
void postMessage(...)
// some events
attribute EventListener onabort;
attribute EventListener onload;
attribute EventListener onunload;
}
or something like that?
:DG
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
LOL. Who else has been quietly concocting a worker spec? This very much along the lines of what I was thinking. Equating worker to (or drawing parallels with) a window object is the approach that would make workers easier to understand for developers, IMHO. I am not quite sure yet about DOM access/interaction. On 2/14/08, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008, Aaron Boodman wrote: Well, as long as you've brought it up, I was working on a proposal too: http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal As was I. :-) http://www.hixie.ch/specs/dom/workers/0.9 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Asynchronous database API feedback
.. Speaking of batches, in my adventure of implementing the new SQL
spec, it looked like the transaction callback is mostly a functional
equivalent of a queue.
So, one idea would be explicitly make it an queue-like structure,
rather than a function callback:
var db = openDatabase('test');
var tx = db.createTransaction();
tx.add(db.sql('create table if not exists chickadees(name text, kind text)'));
tx.add(db.sql('insert into chickadees values(?, ?)', ['moesha',
'black-capped']));
tx.add(db.sql('select * from chickadees', [], function(rs) {
console.log(rs.rows.name); }));
tx.execute(function(error) {
console.log('bird flip!');
});
.. in which case single statements could be executed as:
db.sql('select count(*) as count from chickadees', [], function(rs) {
console.log(rs.rows.count); }).execute();
What do you think?
:DG
Re: [whatwg] Asynchronous database API feedback
Can you help me understand the problem you're pointing out? The
difference between the idea outlined and the current spec is the
absence of the transaction callback, but it basically (I think) has
the equivalent net effect.
db.createTransaction is just a mutable list of statements until the
execute method is called. In fact, it could even probably be just a JS
array.
tx.execute(..) immediately returns, then asynchronously (pardon the
sketchiness):
* opens transaction
* calls optional errorCallback if fails
* proceeds to execute statements in queue
* calls optional successCallback upon success.
I don't see it as being too much different from the spec's transaction
steps. In fact, I can easily see this written as a JS wrapper around
the current spec.
:DG
On Dec 12, 2007 12:33 PM, Brady Eidson [EMAIL PROTECTED] wrote:
I think the issue you're forgetting is when opening a transaction can
fail. The transaction callback is only called when the transaction is
successfully opened and you know that it is starting out valid.
~Brady
On Dec 12, 2007, at 9:37 AM, Dimitri Glazkov wrote:
.. Speaking of batches, in my adventure of implementing the new SQL
spec, it looked like the transaction callback is mostly a functional
equivalent of a queue.
So, one idea would be explicitly make it an queue-like structure,
rather than a function callback:
var db = openDatabase('test');
var tx = db.createTransaction();
tx.add(db.sql('create table if not exists chickadees(name text, kind
text)'));
tx.add(db.sql('insert into chickadees values(?, ?)', ['moesha',
'black-capped']));
tx.add(db.sql('select * from chickadees', [], function(rs) {
console.log(rs.rows.name); }));
tx.execute(function(error) {
console.log('bird flip!');
});
.. in which case single statements could be executed as:
db.sql('select count(*) as count from chickadees', [], function(rs) {
console.log(rs.rows.count); }).execute();
What do you think?
:DG
Re: [whatwg] Gigantoredesignorrific changes to the Database API
I like the operation structure, imposed by the new spec: (database
(transaction (statement (handler, and error callbacks are nice. A
couple of things stood out:
1) The transactions are now required and this seems like an
unreasonable performance hit. What if the API would assume transaction
mode, but would allow authors to explicitly state that the operation
is not a transaction:
db.operation(function(op) {
// implicitly a transaction
});
db.operation(function(op) {
// explicitly not a transaction, just a set of statements in one context.
}, null, false /* states that this is not a transaction */);
.. or something along these lines.
2) Fully asynchronous is scary. Are we sure this is going to be
well-digested? I can just see people doing this:
db.operation(function(tx) {
var count;
tx.executeSql(SELECT COUNT(*) AS C FROM BLAH;, function(r) {
count = r.item(0).c;
});
if (count 0) {
// do happy things.
}
});
3) I think I misunderstand step 11, help me out. If the commit has
failed once, why try to re-commit, even if the error callback
instructs you to?
:DG
Re: [whatwg] executeSql API is synchronous
On 9/25/07, Aaron Boodman [EMAIL PROTECTED] wrote:
On Sep 25, 2007 11:08 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Ah, that makes sense. A special purpose class for the rows property is
fine with me. I don't feel that strongly about forEach and friends.
Speaking of forEach, what do you think of (pardon any syntax errors,
writing straight into gmail window):
db.forEach(SELECT * FROM pages;, function(row) {
this.innerHTML += lia href=\ + row.url + \ + row.title +
/a/li;
}, document.getElementById(pages))
and...
document.getElementById(pages).innerHTML = ul + db.map(SELECT *
FROM pages, function(row) {
return lia href=\ + row.url + \ + row.title + /a/li
}).join() + /ul;
Why expose rows collection at all?
:DG
[whatwg] Persistent Scripting Context, was: Offline Web Apps
I've been sitting on this thought for almost a week, and with no time
in sight to formalize it into some sort of a proposal, I believe it'd
be better just to blurt it out here. Alex Russell's post was the
proverbial straw (http://alex.dojotoolkit.org/?p=623#more-623).
Overall, I think Ian's latest proposal is good. I am still trying to
wrestle understanding the specifics of Updaters and use cases, but it
looks like a pretty good way to implement offline storage.
Additionally, it appears to be a very elegant way to add an extra
level of scope that is much needed for Web applications. So, here is
the idea:
1. Instead of using application attribute, move the declaration into
a separate head element, like link rel=application. This provides
the ability to reference multiple applications and also name each
reference:
link rel=application type=text/html id=dojo
href=http://dojotoolkit.org/files/manifests/dojo-0-9-0.html;
(I am implicitly suggesting that the manifest is in XOXO format, but
that's another topic for another day)
2. All offline storage rules, outlined in Ian's proposal apply.
3. For each declared application, a scripting context exists. The
context is a JS object and can be accessed by querying
document.application[id], where id is the value of the id attribute
on the link element (a bit kludgy, better idea needed here). For
instance:
document.application.dojo.parser = function() { ... }
alert(document.application.dojo.version);
4. The scripting context is persistent for the duration of the browser
session. In other words, it retains scope and values of the context
members across documents, being initialized when the application is
first encountered during a browsing session and shutting down when the
browser session is terminated. I realize how complex this is
implementation-wise.
5. If the document is explicitly mentioned in the manifest of the
application, the context is read/write for this document. Otherwise,
the context is read-only. This allows any developer to use the
application without actually being part of it.
6. In addition to Updater, there are Constructor and Destructor
manifest entries. Their purpose is to initialize scripting context
when the application is encountered for the first time during the
browser session and tear down the context when the session ends.
Obviously, this is very sketchy, but I wanted to capture this in
writing, hoping that it will inspire more concrete ideas.
:DG
Re: [whatwg] Offline Web Apps
On 9/13/07, Aaron Boodman [EMAIL PROTECTED] wrote: The bugzilla scenario is a good one. Someone wants to offline-enable bugzilla. They could rewrite bugzilla to use fragment identifiers instead of querystrings, but then bug shortcuts on the web would not work with the offline-enabled application. They couldn't really cache all possible pages (there are lots of bugs, and that would be really inefficient). I suppose you could have each bug page be a separate application, and cache each one as it is viewed online, but this is really wasteful, and more importantly, bug shortcuts won't work offline unless you have previously visited them. - a This kind of puts us at crossroads as to whether keep treating a URL as an opaque identifier or attempt to break it down to determine whether a page belongs to a given set. Another, less cool path would be to use regular expressions or somesuch instead of explicit list. What if an application could be given an event when the link, clicked on a document that is part of the application leads to a page that is not present in cache? This way, the app could potentially manage the fallback. :DG
Re: [whatwg] Offline Web Apps
The following has a rant flavor to it, but I am hoping you'll find it helpful in the thought process. Distinct, server-reaching URLs (no fragment identifiers) for each page in an web application are a _good_thing_. Packing the whole application into one document and managing history with id hashes and other hacks is not. It's a necessary kludge that you have to do in order to avoid browser context re-initializing, re-parsing scripts, and re-requesting all accompanying graphical and stylistic overhead every time the user clicks on anything. I would've loved it if Google Reader had a distinct URL for each click I make on the page, and I am sure Google Reader devs would've loved it too. Except they also would've loved not having to worry about the browser/scripting context change. Instead, they have to essentially reinvent the way web works (http://www.tbray.org/ongoing/When/200x/2006/03/26/On-REST) by overloading fragment identifier with an entire URI management system. I applaud the effort and the result is awesome, but it doesn't make a good bedtime story. I guess the vision is that application context transcends and encompasses browser/scripting context somehow. :DG
Re: [whatwg] Offline Web Apps
Since, AFAIK, the fragment identifier is not passed onto the server by the UA, I can't see how an application could be designed with proper noscript degradation and reliance frament ids for query communication. Besides, using query parameters is much more natural for HTML: forms with method=get are the way to build it. On 9/10/07, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 10 Sep 2007, Aaron Boodman wrote: On Sep 10, 2007 2:21 PM, Ian Hickson [EMAIL PROTECTED] wrote: I still don't understand how you see this working using the same codebase both online and offline. The model I'm proposing basically relies on the app being an offline app, except that while you're online the offline app is talking to the server to keep its database updated and the server updated with the user's changes. What you're describing seems like it would require a different set of code for the offline case than the online case. You can share the UI code for normal web apps with local-mode ones if you have a clean separation between the server and the UI. In fact, I think it will be common to want to do this. Bookmarks and URLs from the online app should work with the offline one and vice versa. I agree, I just don't see how this applies to the example Robert gave with Bugzilla. The idea of having some URIs be decomposed by the client-side and have them fetch different pages from the server seems really unwise, especially since in browsers that don't support this, they'll not be decomposed and will end up fetching different pages. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Offline Web Apps
In fact, interrogating such a form should provide enough information to the UA on what query parameters are and even some of the values of these parameters. On 9/10/07, Dimitri Glazkov [EMAIL PROTECTED] wrote: Since, AFAIK, the fragment identifier is not passed onto the server by the UA, I can't see how an application could be designed with proper noscript degradation and reliance frament ids for query communication. Besides, using query parameters is much more natural for HTML: forms with method=get are the way to build it. On 9/10/07, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 10 Sep 2007, Aaron Boodman wrote: On Sep 10, 2007 2:21 PM, Ian Hickson [EMAIL PROTECTED] wrote: I still don't understand how you see this working using the same codebase both online and offline. The model I'm proposing basically relies on the app being an offline app, except that while you're online the offline app is talking to the server to keep its database updated and the server updated with the user's changes. What you're describing seems like it would require a different set of code for the offline case than the online case. You can share the UI code for normal web apps with local-mode ones if you have a clean separation between the server and the UI. In fact, I think it will be common to want to do this. Bookmarks and URLs from the online app should work with the offline one and vice versa. I agree, I just don't see how this applies to the example Robert gave with Bugzilla. The idea of having some URIs be decomposed by the client-side and have them fetch different pages from the server seems really unwise, especially since in browsers that don't support this, they'll not be decomposed and will end up fetching different pages. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Offline Web Apps
Still reading through... am I right assuming that the shortest attribute value would be #, i.e. html application=#, pointing to itself? :DG
Re: [whatwg] Offline Web Apps
Erm. Right. :DG
Re: [whatwg] Offline Web Apps
Intuitively, I think I agree with Maciej. Manifest is not as elegant as participation by association approach, but it allows for better packaging an application. I am thinking about scripts/stylesheets that are typically a limited set of resources, reused throughout an application. I also don't yet understand why Ian wants to store multiple versions of resource representations, if same representation is used by multiple apps. What is the motivation here? ... and how would one make an app like Twitter or Facebook available offline? Perhaps a markup attribute is not a good idea in this case, where every profile page is potentially an application. I am thinking that only _your_ profile page is an offline app. Right? On 8/24/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Aug 23, 2007, at 8:56 PM, Aaron Boodman wrote: On Aug 23, 2007 8:18 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 23 Aug 2007, Maciej Stachowiak wrote: I haven't read over the details but there seems to be an obvious showstopper problem: this won't work for web applications that consist of more than one page. Indeed, that was called out as a potential issue. But is that really a problem? It's easy to work around (e.g. with iframe)s if you really must have multiple top-level pages, but aren't web apps moving to a one-page model anyway? The problem gets significantly more complicated with multiple top- level pages all taking part in the same conceptual application. The single-page model has other nice advantages. For example, there's never any confusion about which cache should serve a resource. It's the one that's associated with the application which the resource is contained in. Could multi-page apps be addressed by letting applications specify that other applications should be cached (using a similar api to the one that lets applications programatically cache resources)? I don't think that works very well - you'd have to parse all the HTML, CSS and scripts associated with those other pages just to do the caching. That's a huge cost compared to just downloading the resources. Consider web apps like flickr and upcoming which consist of many many pages. Obviously these specific examples can't cache all of their pages offline but they may well want to cache a significant subset that is interesting to the user. I think it's easy to extend Ian's idea in a way that keeps it really simple for the simple case, but that works better for the multi-page case or other complex cases where pages load some resources dynamically. html application=manifest-file The manifest file would indicate all resources used by the web app, including other pages, and other resources that may be loaded by the current page but normally would not be at startup (another problem with Ian's proposal IMO). Multiple pages that refer to the same manifest are considered part of the same web app and share the same cache. If you give an empty value for the application attribute, then the implicit thing that Ian describes happens - the resources that the page actually loads are the ones cached. My thoughts on this aren't fully fleshed out, but Ian said he wants to start editing the spec right away so I wanted to give this minimal feedback before he writes up something in detail that I would strongly object to. Regards, Maciej
Re: [whatwg] rel/rev for form ?
Ok, here's my take: Having rel/rev for a form element is logical. Hyperlink and form are inherently related in that both are used to specify protocol of communication. So, if hyperlink can have rel/rev, why not form? As for the tags attribute discussion, you guys just invented a class attribute. :DG
Re: [whatwg] getElementsBySelector etc
Just a barely relevant observation for the moment: CSS selectors
really ought to be their own language, separate from CSS spec. Kind of
like XPATH/XSLT relationship.
I am running with the microformats crowd (or should I say herd :)
occasionally, and the CSS selectors are a great fit for searching for
a format and doing things with it (trying carefully to skirt the
binding behavior religious debate :).
:DG
On 9/30/05, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 19 Sep 2005, Erik Arvidsson wrote:
interface GetElementsBySelector {
NodeList getElementsBySelector(in DOMString cssSelector);
// returns true if an element matches the given CSS selector
boolean matchesSelector(in Element el, in DOMString cssSelector);
}
I agree that these would be useful. The former is even mentioned in the
WA1 draft at the moment. However, it seems to me that this would be more
in the realm of the CSSWG rather than the WHATWG.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsBySelector etc
Doh! :) Are there any languages at the moment that utilize Selectors other than CSS? :DG On 9/30/05, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 30 Sep 2005, Dimitri Glazkov wrote: Just a barely relevant observation for the moment: CSS selectors really ought to be their own language, separate from CSS spec. Kind of like XPATH/XSLT relationship. They are: http://www.w3.org/TR/css3-selectors/ Notice that the name of the spec (despite the URI, which is that way for historical reasons) is just W3C Selectors, not W3C CSS Selectors. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] textarea accept attribute -- solution to rich text editing in WF2?
On 8/24/05, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 23 Aug 2005, Dimitri Glazkov wrote: Ian, I think the opposite is true, actually. Most of the browser-based HTML editors that I saw operate by augmenting functionality of a textarea element, and the accept attribute would work make them fit perfectly into the WF2 world. ... I meant implementations in end-user UAs, like Opera, Safari, or Firefox. Do you think it's telling that there are so many implementations of basically the same thing? :DG
Re: [whatwg] What exactly is contentEditable for?
I've been following this thread for a little while. I too think that the contentEditable is not done quite right. My biggest problem with it (and this was pointed out before) is that it is a half-way effort: there is markup that enables the editing, but there is no markup that provides any information about submission for the edits. IMHO, this is incomplete. If you provide means for entry, it shall be your responsibility to provide means for exit. I was surprised to learn that WF2 spec does not support rich textarea. I still can't figure out why. Again, IMHO, the contentEditable attribute represents a shift of paradigm in Web markup: it suggests that the actual markup of the page could be the target of user manipulation. Prior to it, users were confined to forms elements. It's not that I mind the shift. But this shift is kind of huge, and I don't think it's wise to shift just bits and pieces. :DG
Re: [whatwg] What exactly is contentEditable for?
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 23 Aug 2005, Hallvord Reiar Michaelsen Steen wrote: Could we extend contentEditable in a way that would let the UA offer a non-scripting UI for saving the edited page? For example using the form attribute from WF2? What's wrong with File Save ? Save where? How? What? :DG
Re: [whatwg] What exactly is contentEditable for?
On 8/23/05, Ian Hickson [EMAIL PROTECTED] wrote: Actually, originally, HTML was supposed to be user editable always. Much like in Amaya. So contentEditable is more of a compromise between the original intent of the Web and the don't let them modify it! attitude that has grown since. I understand (and appreciate) the sentiment, but that's not how HTML had developed. Amaya's simplistic PUT is not going to cut it for most of today's managed content. Web pages have become compositions of resources, and something a little more sophisticated is needed to specify how the edits are passed on to the server. As you know, there is already a scheme for communicating server's expectations on input -- forms. I can't see how contentEditable fits in this scheme. The attribute only specifies whether the area is possible to edit. It does not specify how the UA is to communicate it back. It just doesn't seem kosher to leave it as is. And answering your earlier comment, I understand that it's just a couple of lines of code to provide that communication. The problem is that it's not a consistent or standardized way, which makes it next to impossible to determine how this communication is handled without actually executing the code. Shooting from the hip, I would rather see something like this: textarea type=text/html src=#mainPageContent id=mainPageContentEditor/textarea Where the src attribute points to an element (or the whole document, if you want to). The element and its children/descendants may or may not have contentEditable attribute set, thus regulating which parts of the fragment is editable. At least now you are using the same form scheme to specify how the server would like to receive this data. :DG
[whatwg] textarea accept attribute -- solution to rich text editing in WF2?
I may have spoken too soon on the absence of rich text editing textarea in WF2. Looking at the spec, there is an accept attribute for the textarea element, and its description fits the bill very nicely. If we have accept=text/html or accept=application/xml+xhtml, it is totally up to the UA to provide a specialized editor -- the HTML editor in this case. Am I right on this one? :DG
Re: [whatwg] [html5] window.print() undefined
On 7/19/05, Ian Hickson [EMAIL PROTECTED] wrote:
@media {
navigation { display: none; }
}
Ok, at least we all agree that it's not what the user sees :)
What functionality are you lacking? (Both in screen and print.)
Like, adding contextual content for print. Just like your main content
is not the only thing on the page, same may hold true for the print.
I think this discussion is about to turn into debunking of specific
application requirements and approaches, but I'll bite:
a) my invoice format requires a timestamp that says something like
this: printed by [person] on [timestamp].
b) To capture the essence of the browsing session, I would like to
build a breadcrumb at the bottom of the printed page, displaying
titles and urls of pages the user have visited on the site during this
visit.
:DG
Re: [whatwg] [html5] window.print() undefined
On 7/19/05, Ian Hickson [EMAIL PROTECTED] wrote:
b) To capture the essence of the browsing session, I would like to build
a breadcrumb at the bottom of the printed page, displaying titles and
urls of pages the user have visited on the site during this visit.
That seems like something that would be useful regardless of the medium.
Put it in the content, and then hide it in the media you don't want it
visible for, e.g.:
@media screen {
footer .breadcrumbs { display: none; }
}
This one was a trick question, sorry :) The per-session breadcrumbs
most definitely do not belong in markup. This breaks REST paradigm and
makes things like caching next to impossible. It's just wrong use of
HTTP.
The only correct way to implement them is to generate and render then
on/from the client side. Obviously, this doesn't impact either line of
reasoning behind print/screen media and does not invalidate what you
were saying -- consider it a sideline story :)
However, I think am starting to see what you're seeing. Basically,
your approach is to provide all content in the DOM tree and then flip
switches as needed to present it to various media types. Right?
Essentially, you are creating all-in-one DOM tree, where all content
co-exists in the same DOM space, then providing illusion of disparate
DOM spaces by turning on/off parts of the tree as needed using CSS. In
a way, you are using CSS to control representation of information,
rather than just content presentation.
This is the exact opposite of my sanboxing thinking, where I suggest
that separate DOM trees (representations) may be created.
But what about the cases where content needs to be reordered or just
plain needs to be slightly different? Is that still realm of CSS?
:DG
Re: [whatwg] Input type=date UI discussion
On 7/13/05, Dean Edwards [EMAIL PROTECTED] wrote: Matthew Thomas wrote: Dean Edwards wrote: We don't display them. Should we? The native version does. See the Date-Picker section of http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08c.asp. OK. We'll show them greyed out. But please don't make us show the today squiggly.. :DG
Re: [whatwg] Web Forms as data schema language
On 7/6/05, Ian Hickson [EMAIL PROTECTED] wrote: It isn't a data schema language (although I suppose HTML has been abused for worst things). Why not? And what does abuse have anything to do with this? Could you please elaborate? :DG
[whatwg] Some likeness of DOM Session scope
IMHO, one of the biggest obstacles for growth in Web applications
development is the fact that the entire application lives in the scope
of one request.
Once next request is made, the browser essentially forgets
everything and the whole new cycle of loading, initialization, and
binding begins.
Yes, you can simulate the effect of retaining scope across several
requests with XmlHttpRequest and even frames, but it's the simulate
part that bothers me. Simulate means hacking, and hacking
inevitably means inconsistent and/or incomplete implementations.
It seems that a future Web Application platform should have this type
of functionality readily available. What do you think about the idea
of having some likeness of a scope that's inherently wider than
request?
Consider this example (improvising here):
Request 1:
function SyntaxHighlighter()
{
// code goes here to provide on-the-fly beautification of code
}
document.session.highlighter = new SyntaxHighlighter();
Request 2+:
if (document.session.highighter)
{
var codeSections = document.getElementsBySelector(pre code)
for(var i = 0; i codeSections.length; i++)
{
SyntaxHighlighter.apply(codeSections[i]);
}
}
Is this a totally asinine idea?
:DG
Re: [whatwg] Canvas element
I guess I am still struggling to grasp the concepts, so please be patient with me. Isn't the main functional value behind the canvas element is the rendering context? If so, what is the significance of the canvas element itself? Take away the behavior, and you've got yourself another SPACER tag. Why not allow creating rendering context on all block-level elements? Why does the content have to contain information which block level element is meant for drawing? Also, I am having hard time the fallback content phrase. IMHO, it's not the fallback content, it's _the content_ of the element. The rendering context is presentation (hopefully, visual interpretation of the content), and so are all functional behaviors that come with it. However, if the rendering context is available on all block-level elements, you can do some really neat stuff, such as using the content of a block-level element as arguments for rendering. For instance, the markup of an ordered list of links and images is transformed into an image gallery. :DG On 4/20/05, Anne van Kesteren [EMAIL PROTECTED] wrote: Dean Jackson wrote: Obviously this has pretty significant accessibility problems. There is no content in canvas - it's just script. With document-based graphics solutions, such as SVG and even Flash, there is real content in the document. Accessibility tools can access that content and provide alternate renderings (such as voice). The content from the CANVAS element is the fallback content. canvas ... alternate content ... /canvas -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas element
On 4/20/05, Anne van Kesteren [EMAIL PROTECTED] wrote: Isn't the main functional value behind the canvas element is the rendering context? If so, what is the significance of the canvas element itself? Take away the behavior, and you've got yourself another SPACER tag. Not really. Since you know what the element is for it has some additional semantics. Which can be used I guess one way or another. Ok, let me rephrase that. What is the *content* significance of the the canvas element? Semantically, it's a placeholder for some multimedia behavior, the nature of which is not know from the perspective of content. That's just begging for all kinds of abuse. Besides, in terms of progressive enhancement, you are actually defining an element in the markup that is _meant_ to regress gracelessly. Canvas element, IMHO, is part of the declarative application development school of thought, and this school of thought does not mix very well with the structural markup school of thought. As an element, canvas belongs more with the XAML people than with the XHTML people. Or maybe WA1 is indeed about declarative application development? You guys tell me. I certainly don't see how you could mix the two (and you would have to, if you strive to become HTML5) and still get away with something that is not a frankenstein. Instead of this: canvas id=weightedTagsA neat, animated graph representation of Technorati tags, which you poor slob can't see because your agent doesn't support it./canvas I would rather see this: ol id=weightedTags li class=weight-3Stuff/li !-- ... more tags -- /ol with this as bound behavior: var weightedTags = document.getElementById(weightedTags); var context = weightedTags.getContext(CanvasRenderingContext2D); // use content of the weightedTags to draw with context // ... Does this make any sense? :DG
