Re: Component Model Update
On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
All,
Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:
* Created a general overview document for behavior attachment problem
on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
* Wrote down the a set of guidelines on how we intend to tackle the
problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
* Updated the list of use cases and desired properties for each case
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
* Captured the overall component model design and how it satisfies
each desired property (http://wiki.whatwg.org/wiki/Component_Model),
including a handy comparison with existing relevant specs and
implementations
(http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
After of this iteration, the proposed shadow DOM API no longer
includes the .shadow accessor (see details here
http://dglazkov.github.com/component-model/dom.html). Instead, the
shadow DOM subtree association happens in ShadowRoot constructor:
var element = document.createElement(div);
var shadow = new ShadowRoot(element); // {element} now has shadow DOM
subtree, and {shadow} is its root.
shadow.appendChild(document.createElement(p)).textContent = weee!!';
This is getting a bit better, more XBL2-like, but just with different
syntax :)
Adam already sent comments about most of the things I had in mind
and I'm especially interested to know about
This section http://wiki.whatwg.org/wiki/Component_Model#Consistency
seems to imply that components can override the traversal and
manipulation APIs defined by DOM Core. since that could have major
effects to browser engine architecture. If all the APIs could be
overridden, and browser engine is expected to call the JS implemented
versions, the problems we have now with mutation events would be there
with all the DOM methods.
The wiki page doesn't mention at all how events are propagated.
I assume mousemove events should be fired in the real dom, but also in
shadow dom? mouseover/out should in some cases fire only in shadow dom,
but in some cases both in shadow and real...etc.
Is the idea to clone events like in XBL2, or propagate but
re-target like in XBL1 or what?
-Olli
Keeping the accessor out allows for proper encapsulation and
confinement (better explanation of these new bits of terminology here:
https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
also simplifies the API surface.
Please review. Feedback is welcome!
:DG
[widgets] CFC to republish Widget URI spec
Hi, I would like to republish the Widget URI scheme spec as a Working Draft. http://dev.w3.org/2006/waf/widget-uris/ Please consider this a 1 Week CFC - if you object, please let the group know. What's new: 0 . Added a bunch of examples. 1. Resolving URIs is now left to the host Document (i.e., HTML5's resolve URL algorithms). 2. Added straw-man for behaving like HTTP (inspired by FileAPI's blob://) 3. Generalized the dereferencing algorithm so non PC compliant runtimes can use it. I will continue doing a minor cleanup over the next week. Kind regards, Marcos
Re: Component Model Update
Hi Olli!
On Wed, Aug 24, 2011 at 3:13 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
All,
Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:
* Created a general overview document for behavior attachment problem
on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
* Wrote down the a set of guidelines on how we intend to tackle the
problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
* Updated the list of use cases and desired properties for each case
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
* Captured the overall component model design and how it satisfies
each desired property (http://wiki.whatwg.org/wiki/Component_Model),
including a handy comparison with existing relevant specs and
implementations
(http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
After of this iteration, the proposed shadow DOM API no longer
includes the .shadow accessor (see details here
http://dglazkov.github.com/component-model/dom.html). Instead, the
shadow DOM subtree association happens in ShadowRoot constructor:
var element = document.createElement(div);
var shadow = new ShadowRoot(element); // {element} now has shadow DOM
subtree, and {shadow} is its root.
shadow.appendChild(document.createElement(p)).textContent = weee!!';
This is getting a bit better, more XBL2-like, but just with different syntax
:)
I am glad you like it!
Adam already sent comments about most of the things I had in mind
and I'm especially interested to know about
This section http://wiki.whatwg.org/wiki/Component_Model#Consistency
seems to imply that components can override the traversal and
manipulation APIs defined by DOM Core. since that could have major effects
to browser engine architecture. If all the APIs could be
overridden, and browser engine is expected to call the JS implemented
versions, the problems we have now with mutation events would be there
with all the DOM methods.
The wiki page doesn't mention at all how events are propagated.
I assume mousemove events should be fired in the real dom, but also in
shadow dom? mouseover/out should in some cases fire only in shadow dom,
but in some cases both in shadow and real...etc.
Is the idea to clone events like in XBL2, or propagate but
re-target like in XBL1 or what?
The event propagation is already mostly spec'd out here:
http://dglazkov.github.com/component-model/events.html
Propagation through content element and handling evenets for the
confinement primitives isn't yet done.
:DG
-Olli
Keeping the accessor out allows for proper encapsulation and
confinement (better explanation of these new bits of terminology here:
https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
also simplifies the API surface.
Please review. Feedback is welcome!
:DG
Re: [selectors-api] Return an Array instead of a static NodeList
I agree with this, but it might be too late to make this change. The problem is that if we returned an Array object, it would not have a .item function, which the currently returned NodeList has. I guess we could return a Array object and add a .item function to it. / Jonas On Sun, Aug 21, 2011 at 10:52 AM, Julien Richard-Foy jul...@richard-foy.fr wrote: Since Javascript 1.6, a lot of useful collection functions are defined for Array [1]. Unfortunately, they can’t be used directly with results returned by .querySelectorAll, or even .getElementsByTagName since these functions return NodeLists. I understand the DOM API is defined without a language in mind, but these collection functions are really useful, easy to implement and already available in most mainstream languages. Therefore, why not create a base Traversable type which would be implemented by all collection types (like NodeList) and which would provide the so useful bunch of iteration methods? Are there some issues or drawbacks I did not think of? Regards, Julien [1] https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array#Iteration_methods
Re: [selectors-api] Return an Array instead of a static NodeList
On Sun, Aug 21, 2011 at 1:52 PM, Julien Richard-Foy jul...@richard-foy.fr wrote: Since Javascript 1.6, a lot of useful collection functions are defined for Array [1]. Unfortunately, they can’t be used directly with results returned by .querySelectorAll, or even .getElementsByTagName since these functions return NodeLists. You can already use these methods with .call() if you want, like: [].forEach.call(nodeList, fn). But this is a highly unintuitive hack -- I don't see why nodeList.forEach(fn) shouldn't work. I understand the DOM API is defined without a language in mind, but these collection functions are really useful, easy to implement and already available in most mainstream languages. Therefore, why not create a base Traversable type which would be implemented by all collection types (like NodeList) and which would provide the so useful bunch of iteration methods? Are there some issues or drawbacks I did not think of? This sounds like a good idea. It's not what the subject of your e-mail says, though (Return an Array instead of a static NodeList). I think we should keep returning a NodeList, just make it have the same iteration methods as an Array. On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote: I agree with this, but it might be too late to make this change. The problem is that if we returned an Array object, it would not have a .item function, which the currently returned NodeList has. I guess we could return a Array object and add a .item function to it. Or return a NodeList and add .forEach/.filter/etc. to it?
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? -- erik
[Bug 13891] New: Allow author scripts that fire before or after every command
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13891 Summary: Allow author scripts that fire before or after every command Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Ehsan, Ryosuke, Annie, Jonas, and I spoke about this today. We agreed that some use-cases for mutation events in editing would best be served by allowing authors to specify scripts that fire before and after every command, particularly: * Replace a command by an entirely custom implementation. This is useful for commands that are fired by the UA rather than the author, like insertText or insertParagraph. I've been told Safari also automatically lets the user run bold/italic/etc. via the usual keyboard shortcuts. * Modify the results of a command. E.g., adding classes or id's to added elements. Actual events that wait for the event loop are inappropriate -- we need these to run immediately before or after the command. Scripts that run before the command need to be able to cancel it for the first use-case. Scripts that run after it need info about what it did, like a list of newly-created elements, for the second use-case. Speccing the before part should be easy if we provide no info except the command name and value. Speccing the after part will require careful work to decide which nodes to expose. If new use-cases arise, we can expose more info for both the before and after events. This might provide a better solution to some of the use-cases for a mutation events replacement, but not all of them. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. :DG -- erik
[Bug 13893] New: Only HTML elements should be editable
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13893 Summary: Only HTML elements should be editable Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Ehsan pointed out that it doesn't make any sense to let the user edit SVG or MathML unless the browser has a special editor for them. We should make only HTML elements editable/editing hosts for now. Embedded SVG/MathML should be treated as opaque, like an img. This probably means the root node of the foreign content does need to be editable, so we know we can delete it, but we don't want to touch any of its descendants. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR2] Blobs, names and FormData
On 8/24/2011 1:33 AM, Anne van Kesteren wrote: On Tue, 23 Aug 2011 20:44:15 +0200, Charles Pritchard ch...@jumis.com wrote: Is there any interest in supporting application/x-www-form-urlencoded ? It would of course lose any carried content types or file names from Blobs. urlencoding is certainly inefficient, and it's something that can be done in JS as things currently stand. It would help to send urlencoded posts to services that don't support multipart. Examples of such services would be useful here. (That would still accept urlencoded files.) A URL encoded post; that it would use a blob as the source of one of the values is secondary. The idea is to improve the FormData interface, so that xhr.send(FormData) can support x-www-form-urlencoded quickly/easily. Prpoposed: FormData output with the x-www-form-urlencoded mime type: formData.toUrlEncodedBlob(xhr.send) If going down the blob path, these two would have the same end-result: formData.toMultipartBlob(xhr.send) xhr.send(formData); What kind of API-style is this? [Supplemental] FormData void toMultipartBlob(in callback) void toUrlEncodedBlob(in callback) The first would create a multipart mime message, in a blob, and run the callback with the blob as the first argument, the second would create a urlencoded message, in a blob, and also run the callback. They'd set the appropriate content type on generated blob. -Charles
Re: Component Model Update
On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@adambarth.com wrote: I feel somewhat like I'm walking into the middle of a movie, but I have a couple questions. Please forgive me if my questions have already been answer in previous discussions. Welcome to the show! On Tue, Aug 23, 2011 at 1:40 PM, Dimitri Glazkov dglaz...@chromium.org wrote: All, Over the last few weeks, a few folks and myself have been working on fleshing out the vision for the Component Model. Here's what we've done so far: * Created a general overview document for behavior attachment problem on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment); * Wrote down the a set of guidelines on how we intend to tackle the problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology); * Updated the list of use cases and desired properties for each case (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases); * Captured the overall component model design and how it satisfies each desired property (http://wiki.whatwg.org/wiki/Component_Model), This section http://wiki.whatwg.org/wiki/Component_Model#Consistency seems to imply that components can override the traversal and manipulation APIs defined by DOM Core. Do you mean that they can override the JavaScript APIs folks use for traversal and manipulation, or can they override the traversal and manipulation APIs used by other languages bound to the DOM and internally by specifications? I certainly didn't mean to convey either: the former as some new thing introduced by the Component Model, and the latter as something that is being attempted. All it says is that your components are DOM objects and inherit the DOM Core APIs. You can add your own properties and extend the API surface. For example, suppose we implemented the Component Model in WebKit and a component overrided the nextSibling traversal API. Would Objective-C code interacting with the component (e.g., via Mac OS X's Object-C API for interacting with the DOM) see the original API or the override? Similarly, for browsers such as Safari, Chrome, Firefox, and Opera that provide a script-based extension mechanism, would extensions interacting with these components (e.g., via isolated worlds or XPCNativeWrappers) see the original API or the override? My sense is that you only mean that Components can shadow (and here I mean shadow in the traditional Computer Science sense http://en.wikipedia.org/wiki/Variable_shadowing) the normal traversal and manipulation, not that they can override it, per se. Just to reiterate, the Component Model doesn't add or change anything here that's not possible today. How can I make this more clear in the overview? This section http://wiki.whatwg.org/wiki/Component_Model#Encapsulation says ... and ensures that no information about the shadow DOM tree crosses this boundary. Surely that's an overstatement. At a minimum, I assume the shadow DOM participates in layout, so its height and width is leaked. Oh you're right. I need to ratchet down the language. Information is a very heavy word. ---8--- var shadow2 = new ShadowRoot(this); // throws an exception. ---8--- I'm not sure I understand why that's the best design decision. Maybe this is explained elsewhere? I link would help folks like me understand better. It looks like this design decision is tied up into how http://wiki.whatwg.org/wiki/Component_Model#Composability works. Ah, good point. I need to expand on this. I'll start a thread to discuss. This section http://wiki.whatwg.org/wiki/Component_Model#Desugaring says ... this also explains why you can't add shadow DOM subtrees to input or details elements. It seems unfortunate that some elements will accept new ShadowRoots but others will not. Is this an implementation detail? What's the list of elements that reject ShadowRoots? As I mentioned in the section, any element that uses more than one CSS box and isn't specified in terms of CSS. The spec would need to have an explicit list. As an example, it seems entirely reasonable that you'd want to create an autocomplete dropdown component for use with an input element. It seems like the natural thing to do would be to subclass the input element and add an autocomplete dropdown as a shadow DOM. This design choice appears to preclude this use case. Instead, I need to subclass div or whatever and replicate the HTMLInputElement API, which seems like the opposite of the reuse existing mechanisms design principle http://wiki.whatwg.org/wiki/Component_Model_Methodology#Design_Priniciples. For what it's worth, this particular use case has grown into a list attribute on the input element: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-list. But more on the multiple shadow DOMs per element thread that's
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov dglaz...@chromium.org wrote: All, Adam raises an interesting question: should we allow more than one shadow DOM subtree per element? Background: per current design (http://wiki.whatwg.org/wiki/Component_Model#Encapsulation), you can only create one ShadowRoot instance per element. The reasoning behind this goes like this: * The use cases for adding an extra shadow DOM subtree for built-in elements seemed like hacks around existing limitations of the elements; * We give leverage to elements, allowing them to control whether their shadow DOM subtrees can be extended. If the element exposes its shadow subtree, then yes you can. If it don't then no you can't. What is the benefit of this leverage? Secure presentation of input type=file? Sane editing model for textarea? * Multiple shadow DOM subtrees introduce the problem of ordering, where the order of rendering these trees is unknowable at the time of creation, which seems like a bad thing. Folks who worked on this with me, I am sure I am missing a couple of things here -- please chime in. However, allowing multiple subtrees certainly has benefits: * No more explicit dead-list of elements that can't have a shadow DOM. You can just create another one. This problem could be tackled without the complexity of multiple shadows by reducing the dead-list to zero, by defining how a shadow would work with input, textarea, … any HTML element we hitherto thought would be “dead.” Or do you mean dead-list of instances of elements, not dead-list of kinds of elements? * More freedom for extending elements (yes, this is the opposite of the single-tree control benefit above) Concept-wise: * Multiple shadow subtrees would just be a list. * The order of a list is established once and is unchangeable. How it is established? I have no idea. * The trees are rendered sequentially (in list order) as if they are children of the hosting element. Security-wise, I don't see any issues off hand. Plumbing-wise, adding support for multiple shadow subtrees should be fairly simple, provided that we solve the order problem. What do you think? :DG
Re: Component Model Update
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Yes, shadow DOM gives the author an extra lever to control visibility and hackability of their code. It's up to them to use this lever wisely. Maybe I grew up on to much Web koolaid, but browsers should be giving all extra levers to users. In real life control in the hand of authors means control in the hands of suits and suits will always pick the hide all setting. This is not without precedent. Just like authors who choose to use canvas to build their entire applications are shutting the door (intentionally or not) on extensions, I bet we'll also see these extremes with the Component Model. In the case of canvas the reason is technical inferiority, the medium is write only. Component Model has not such technical limit. However, I am also sure that a lot of authors will see value in retaining composability for extensions. If anything, shadow DOM can help authors draw proper composability boundaries and thus inform extensions developers where tweaking is ok and where may cause explosions. Again, that's old school. Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. jjb
xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@adambarth.com wrote: This section http://wiki.whatwg.org/wiki/Component_Model#Performance says When an unknown DOM element with an x--prefixed tagName is encountered It seems unfortunate to special-case tag names that begin with x-. The IETF has a lot of experience with x- prefixes, and they're somewhat unhappy with them: http://tools.ietf.org/html/draft-saintandre-xdash I can't seem to draw a parallel between prefixing author-defined custom DOM elements and prefixing HTTP parameters -- other than the prefix itself, that is. There's a clear meaning of the prefix in the Component Model -- this element was defined by an author. Additionally, we are explicitly trying to avoid a registry-like situation, where one has to announce or qualify for the right to use a tag name. Can you help me understand what your concerns are? That RFC is interesting, but I didn’t find it a perfect parallel either. In protocol headers, clients and servers need to agree on the meaning of headers, and require migration from non-standard to standard headers with attendant interoperability issues. Components are different, because both the x-name and its definition are under control of the author. The intent is that if HTML standardizes an x-name, it will be christened with the un-prefixed name; the UA can continue supporting old x-names and definitions using the generic component mechanism. I guess we could get into interoperability difficulties if user agents start to rely on specific x-names and ignoring or augment their definitions. For example, if a crawler ignores the scripts that define components but interpret a common x-name a particular way. Or if a browser automatically augments the definition of a given x-name for better security or accessibility. Yeah, the parallel breaks down a bit because in HTTP the X- names are used by two parties and here we're only talking about one party. Maybe a better parallel is data attributes, which are also segmented into their own namespace... On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button That's something like 40% of the use cases... I don't have much of a better suggestion. You're running up against all the usual distributed extensibility issues. Adam
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth w...@adambarth.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@adambarth.com wrote: This section http://wiki.whatwg.org/wiki/Component_Model#Performance says When an unknown DOM element with an x--prefixed tagName is encountered It seems unfortunate to special-case tag names that begin with x-. The IETF has a lot of experience with x- prefixes, and they're somewhat unhappy with them: http://tools.ietf.org/html/draft-saintandre-xdash I can't seem to draw a parallel between prefixing author-defined custom DOM elements and prefixing HTTP parameters -- other than the prefix itself, that is. There's a clear meaning of the prefix in the Component Model -- this element was defined by an author. Additionally, we are explicitly trying to avoid a registry-like situation, where one has to announce or qualify for the right to use a tag name. Can you help me understand what your concerns are? That RFC is interesting, but I didn’t find it a perfect parallel either. In protocol headers, clients and servers need to agree on the meaning of headers, and require migration from non-standard to standard headers with attendant interoperability issues. Components are different, because both the x-name and its definition are under control of the author. The intent is that if HTML standardizes an x-name, it will be christened with the un-prefixed name; the UA can continue supporting old x-names and definitions using the generic component mechanism. I guess we could get into interoperability difficulties if user agents start to rely on specific x-names and ignoring or augment their definitions. For example, if a crawler ignores the scripts that define components but interpret a common x-name a particular way. Or if a browser automatically augments the definition of a given x-name for better security or accessibility. Yeah, the parallel breaks down a bit because in HTTP the X- names are used by two parties and here we're only talking about one party. Maybe a better parallel is data attributes, which are also segmented into their own namespace... Yes, the data-* attributes are the correct thing to draw parallels to here. On the other hand, it seems likely that some of these xdash names will come into multi-party use. For example, the following use cases involve xdash names chosen by one party and then used by another: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button That's something like 40% of the use cases... These are fine as well; the important case where prefixing causes problems is when one of the parties is the browser itself, where it will eventually want to change from recognizing the prefixed name to recognizing the unprefixed name. ~TJ
Re: Component Model Update
On Wed, Aug 24, 2011 at 2:50 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Yes, shadow DOM gives the author an extra lever to control visibility and hackability of their code. It's up to them to use this lever wisely. Maybe I grew up on to much Web koolaid, but browsers should be giving all extra levers to users. In real life control in the hand of authors means control in the hands of suits and suits will always pick the hide all setting. This is not without precedent. Just like authors who choose to use canvas to build their entire applications are shutting the door (intentionally or not) on extensions, I bet we'll also see these extremes with the Component Model. In the case of canvas the reason is technical inferiority, the medium is write only. Component Model has not such technical limit. However, I am also sure that a lot of authors will see value in retaining composability for extensions. If anything, shadow DOM can help authors draw proper composability boundaries and thus inform extensions developers where tweaking is ok and where may cause explosions. Again, that's old school. Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. Let me see if I can capture this into a feature: user scripts may have access to shadow DOM subtrees. In terms of WebKit, when run in user script worlds, the Element has an extra accessor to spelunk down the shadow DOM. Is this what you're suggesting? :DG jjb
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov dglaz...@chromium.org wrote: All, Adam raises an interesting question: should we allow more than one shadow DOM subtree per element? Background: per current design (http://wiki.whatwg.org/wiki/Component_Model#Encapsulation), you can only create one ShadowRoot instance per element. The reasoning behind this goes like this: * The use cases for adding an extra shadow DOM subtree for built-in elements seemed like hacks around existing limitations of the elements; * We give leverage to elements, allowing them to control whether their shadow DOM subtrees can be extended. If the element exposes its shadow subtree, then yes you can. If it don't then no you can't. What is the benefit of this leverage? Secure presentation of input type=file? Sane editing model for textarea? No, this isn't for built-in controls. If Bob builds a Foo element, he may decide to give it a Foo.shadow accessor to let anyone muck with its shadow DOM. That's the situation I was talking about. * Multiple shadow DOM subtrees introduce the problem of ordering, where the order of rendering these trees is unknowable at the time of creation, which seems like a bad thing. Folks who worked on this with me, I am sure I am missing a couple of things here -- please chime in. However, allowing multiple subtrees certainly has benefits: * No more explicit dead-list of elements that can't have a shadow DOM. You can just create another one. This problem could be tackled without the complexity of multiple shadows by reducing the dead-list to zero, by defining how a shadow would work with input, textarea, … any HTML element we hitherto thought would be “dead.” How would you do that? I am curious. If input element creates a shadow DOM when constructed, it can't have a shadow DOM. How can we make it work with shadow DOM? Or do you mean dead-list of instances of elements, not dead-list of kinds of elements? I think you lost me here -- can you explain? :DG * More freedom for extending elements (yes, this is the opposite of the single-tree control benefit above) Concept-wise: * Multiple shadow subtrees would just be a list. * The order of a list is established once and is unchangeable. How it is established? I have no idea. * The trees are rendered sequentially (in list order) as if they are children of the hosting element. Security-wise, I don't see any issues off hand. Plumbing-wise, adding support for multiple shadow subtrees should be fairly simple, provided that we solve the order problem. What do you think? :DG
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? Can you help me understand what you mean by this? What would be a functional difference between the two cases you outlined? :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
Also -- we can always try to start with just one subtree, and then enable multiple. Since the plumbing and the order specification are trivial, it's something we can easily add. :DG On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How about not throwing on new ShadowTree(element) and just append a new shadow root after the existing ones? That would make the order as instantiated, which is totally fine by me. It would be good to add a use case which describes the need for this. Anyone got a good idea? Don't want to reuse Adam's autocomplete one, since HTML already provides a solution. +1 to finding a use case. When I try to think of one, I usually end up with: I would rather do this using composition. The only benefit of multiple shadows over composition is that I don’t need to forward most of the API to the primary part of the composition. One big question for me is: Do you expect multiple shadows to be designed to work together, or come from multiple independent sources (like different script libraries)? :DG -- erik
Re: Component Model Update
On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. Let me see if I can capture this into a feature: user scripts may have access to shadow DOM subtrees. In terms of WebKit, when run in user script worlds, the Element has an extra accessor to spelunk down the shadow DOM. Is this what you're suggesting? Yes. Encapsulation is good UI, not security. I want to ignore the subtree normally but jump into the astral plane for special enlightenment. XUL has such a mechanism, but I'd wish for less mystery. I spent many hours trying to keep element inspection working on XUL. The API should aim to work well with code designed for normal elements. jjb :DG jjb
Re: Component Model Update
On Wed, Aug 24, 2011 at 8:23 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available to extensions. Let me see if I can capture this into a feature: user scripts may have access to shadow DOM subtrees. In terms of WebKit, when run in user script worlds, the Element has an extra accessor to spelunk down the shadow DOM. Is this what you're suggesting? Yes. Encapsulation is good UI, not security. I want to ignore the subtree normally but jump into the astral plane for special enlightenment. XUL has such a mechanism, but I'd wish for less mystery. I spent many hours trying to keep element inspection working on XUL. The API should aim to work well with code designed for normal elements. jjb Ok. Can you help me formulating a use case for this API, and how it affects desired properties, and building blocks? Anybody has an allergic reaction to something like this? :DG :DG jjb
Re: Component Model Update
I'm still trying to digest this, but it seem pretty clear the 'confinement' is the clear scope thing I was asking about on es-discuss. According to that discussion, this means needs to fit with the 'modules' thing on ecmascript. That seems to be where you are headed, but basing a new proposal on another new proposal is ... well I'll let you fill in the blank depending on how you are feeling. I guess the actual implementation of confined script evaluation would not be difficult (Firefox can do it now if you can get some one to explain it). Getting the entire 'modules' effort out? I'm thinking that could be hard. jjb
