Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
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.
Got it.
Note that component authors could permit extension in a controlled way
by including an instance of a trivial component within the larger
component with simple composition, and then expose _that_ element’s
shadow root. That would permit multiple shadows within a component.
* 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?
If we decide that the element should always be presented, then the
built-in shadow DOM could include a trivial descendant element that is
the extension point. When the script requests a shadow root for the
component, it is commuted and gets a shadow root for the extension
point.
If we decide that it is OK to suppress the presentation of the
component, then we could imagine that these elements capture a
reference to their built-in shadow root and use that. When the script
requests a shadow root for the component, the element’s shadow is
replaced. The implementation of the element continues to consult its
captured shadow.
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?
There are two kinds of dead—dead on arrival, like input,
textarea; elements that you know by looking at the tag name that can
not have shadow (at least in a given implementation) because it uses a
shadow.
Then there are newlydeads, like:
function FooElement() {
// super initialization etc.
// not dead here
var shadow = new ShadowRoot(this);
// 'this' is newly dead to extension via new ShadowRoot at this point
}
Making input, textarea etc support shadows means nothing is DOA;
permitting multiple shadows means there are no newlydeads
either—nothing is ever dead.
Dominic
: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: [selectors-api] Return an Array instead of a static NodeList
On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote: 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? That works, but what is the advantage? And .push/.pop or other mutating functions wouldn't work. / Jonas
Re: [XHR2] Blobs, names and FormData
On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchard ch...@jumis.com wrote: 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. The syntax you've written above wouldn't work in JS. You're only passing in a reference to the send function, not a reference to the XHR object on which to call .send on. So formData.toMultipartBlob(xhr.send) is equivalent to formData.toMultipartBlob(XMLHttpRequest.prototype.send) So in this case you'd have to pass in two argument, the function and the 'this' object. Or require people to use .bind. In general I'm not a fan of this syntax. / Jonas
Re: [selectors-api] Return an Array instead of a static NodeList
On 25 août 2011, at 08:33, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote: 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? That works, but what is the advantage? And .push/.pop or other mutating functions wouldn't work. All mutable functions will work (forEach, map, etc.) and bring a better expressiveness to the code.
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 11:57 AM, Dimitri Glazkov dglaz...@chromium.org wrote: 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? Can I push that on the stack until we have use cases? My suspicion is that it will be qualitatively different; if a widget library provides a set of shadows that are designed to work together, the library can manage the complexity of stacking them right. If the author has to get the order right, it will be hard. But without use cases I’m not certain—just a hunch. I have been wracking my brain for use cases. I keep going in two circles though: 1. Sometimes you want to alter the presentation of the element. (Or at least the element’s children—we’ve always just focussed on the element’s children.) But sometimes you want to augment the presentation. Imagine if input type=text did not use shadow, and you want to use shadow to add a very fancy tooltip. That won’t work, because you will obliterate the text in the input element when you add the tooltip. Why does the *first* shadow have such special semantics? 2. You describe multiple shadows as stacking up side-by-side. What about containment? What if I could do this: var shadowA = new ShadowRoot(someElement); // init shadow A var shadowB = new ShadowRoot(shadowA); // init shadow B then shadowB’s content could chew on the flattened tree of shadowA. It can put things side-by-side by putting elements side-by-side with content; it can also put things inside other things by nesting content. (This doesn’t solve your order problem, though.) :DG -- erik
Re: [Component Model]: Shadow DOM Subtree per element: One or Many?
On Thu, Aug 25, 2011 at 11:58 AM, Dimitri Glazkov dglaz...@chromium.org wrote: 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 Yes. This sounds like a good plan. If we come up with use cases, we can reevaluate in the light of new ideas. Even if new use cases prove compelling, starting with a single shadow is probably still a good approach anyway. Dominic 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: [XHR2] Blobs, names and FormData
On 8/24/11 11:36 PM, Jonas Sicking wrote:
On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchardch...@jumis.com wrote:
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.
The syntax you've written above wouldn't work in JS. You're only
passing in a reference to the send function, not a reference to the
XHR object on which to call .send on. So
formData.toMultipartBlob(xhr.send)
is equivalent to
formData.toMultipartBlob(XMLHttpRequest.prototype.send)
So in this case you'd have to pass in two argument, the function and
the 'this' object. Or require people to use .bind.
In general I'm not a fan of this syntax.
/ Jonas
You're right on that end. Sorry for the confusion.
xhr.send(formData) would be the same as:
formData.toMultipartBlob(function(blob) { xhr.send(blob); });
I didn't mean to propose fancy scope items.
-Charles
Re: Component Model Update
On Thu, Aug 25, 2011 at 2:03 PM, John J Barton johnjbar...@johnjbarton.com wrote: 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. Courageous? 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 If we do the design so that good things are possible when modules arrive, and the component model is useful for some use cases even without hermetic confinement, then it sounds reasonable to work on specing, implementing and getting experience with the other parts?
Re: [selectors-api] Return an Array instead of a static NodeList
On Wed, Aug 24, 2011 at 11:47 PM, Julien Richard-Foy jul...@richard-foy.fr wrote: On 25 août 2011, at 08:33, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote: 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? That works, but what is the advantage? And .push/.pop or other mutating functions wouldn't work. All mutable functions will work (forEach, map, etc.) and bring a better expressiveness to the code. Not if he 'this' object is a NodeList. / Jonas
Joystick support
Hello, I noticed that Mozilla has started to prototype support for Joystick events. There's some documentation on this effort https://wiki.mozilla.org/JoystickAPI as well as a prototype https://bugzilla.mozilla.org/show_bug.cgi?id=604039 I'm also interested in adding support for joysticks to Chromium and so would like to open the discussion up to a broader audience. Do others see this as a valuable API? Or have comments on the design? scott
Re: Component Model Update
Here is a quick first cut: How about use cases like these: - Extension that wants to inspect input type=password and warn you when you are entering you password in an insecure form (from abarth earlier in the thread.) - Password manager that wants to find anything that looks like a login panel and decorate it/fill it. - Extension that removes formatting from a page to make it easier for on-screen reading. - Extension that finds phone numbers in a page and embosses them with links to a crank call service. - Extension that replaces all ads in a page with pictures of kittens. Or an extension that detects pictures of kittens and monetizes them with ads. - Extension that on hover looks up dictionary/thesaurus/translation/urban dictionary/wikipedia/etc. How does it change desired properties? The desired properties are good for the page. Extensions can typically exercise capabilities the page has (right?) Extensions can additionally violate encapsulation. However the UA may bless some encapsulation as inviolate (when the implementation uses shadow and wants to rely on nobody—not even extensions—messing with it.) Extensions sometimes have their own notion of confinement. I think it is OK if extensions can’t violate confinement. There is no deep reflective API for JavaScript, so it would not be so useful anyway? How does it change the primitives? Extensions can detect which elements have shadow, get the shadow root, and get the host for a given shadow root. (In addition to creating shadow roots and any other typical DOM manipulations an extension can do.) Do any of the above use cases need to access the flattened tree? If so, maybe there should be an API for that, because computing it in script would be tedious. Dominic On Thu, Aug 25, 2011 at 1:06 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 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
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!!';
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
It would be rather strange if one needs to explicitly construct
shadow tree after the element is created.
(Component Model is getting closer and closer to XBL, and it is not
quite clear to me why XBL2 couldn't be used. It needs some
minor fixes, but should work otherwise.)
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: Joystick support
Hi Scott, We should definitely open it up for a broader discussion. I think the right place for the discussion might be the new device apis WG, which I've cc'ed. Thanks, Paul Am 24.08.11 21:23 schrieb Scott Graham unter scot...@chromium.org: Hello, I noticed that Mozilla has started to prototype support for Joystick events. There's some documentation on this effort https://wiki.mozilla.org/JoystickAPI as well as a prototype https://bugzilla.mozilla.org/show_bug.cgi?id=604039 I'm also interested in adding support for joysticks to Chromium and so would like to open the discussion up to a broader audience. Do others see this as a valuable API? Or have comments on the design? scott
Re: Joystick support
Hi all, On Aug 25, 2011, at 10:49 , Paul Bakaus wrote: We should definitely open it up for a broader discussion. I think the right place for the discussion might be the new device apis WG, which I've cc'ed. It certainly feels like such an API would find a logical home in Device APIs. It's a shame that it didn't come up a little earlier since we just finished rechartering and it's not on our list of deliverables. That being said, if there's support for doing this work (in the form of people willing to put in the work of writing the spec and implementers willing to prototype and provide feedback) I'd be very happy to talk about finding it a home (in DAP or elsewhere). -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Joystick support
On 08/25/2011 12:54 PM, Robin Berjon wrote: Hi all, On Aug 25, 2011, at 10:49 , Paul Bakaus wrote: We should definitely open it up for a broader discussion. I think the right place for the discussion might be the new device apis WG, which I've cc'ed. It certainly feels like such an API would find a logical home in Device APIs. I'd say WebEvents WG would be more logical place for Joystick API, Joystick is just another input device, like touchscreen. But I don't really care in which WG the standardization is done. -Olli It's a shame that it didn't come up a little earlier since we just finished rechartering and it's not on our list of deliverables. That being said, if there's support for doing this work (in the form of people willing to put in the work of writing the spec and implementers willing to prototype and provide feedback) I'd be very happy to talk about finding it a home (in DAP or elsewhere).
Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Aug 22, 2011, at 11:47 , James Graham wrote: I don't really understand your point here. If you used the smaller document presumably you could just have easily have read the relevant chapter from the larger document. [...snip...] Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are, leading to the problem of important detail dropping into the gaps between the specs. I don't understand your point here. If you used the larger document presumably you could just have concatenated all the dependencies into one. More seriously, if we don't want to rathole forever on this we have to collectively admit that any supposed rule about how people might review or edit a document based on its size or componentisation are, in the absence of hard data, just subjective bollocks. Different people read differently, different editors edit differently, and at the end of the day all you'll get out of such a discussion is a rehash of space vs tabs, vi vs Emacs, boxers vs briefs, etc. It doesn't matter that the truth is obviously on the side of space, vi, and thongs you'll still get no consensus. What we *may* be able to come up with if we really intend to reach some form of agreement here is a set of best practices in document engineering. This would involve answering such questions as: • Is it easier for twenty editors to work on a single document or on twenty smaller documents? And by this I mean measurably — not personally. • What is the best way of capturing the dependencies that a testable assertion may have on other testable assertions, or on a set of defined terms, and does that best way benefit more from a given organisation of content or another? • What is the best approach with regards to patent policy (in a realistic world)? This must take into account such aspects as the political necessity of having multiple groups, time to Rec, feature-completeness of FPWD (since that's when the first exclusion period runs from), etc. • Several others I won't bother to list just yet. If we can't be bothered with discussing this right then we should probably exit the rathole and leave it up to editors of individual documents. FWIW my personal experience is very much in line with Jonas's. Additionally, having releases of a spec makes it possible to know what browser vendors and other significant players agree on. A ever changing slowly evolving spec doesn't say what browser vendors agree is good as opposed to what the editor happened to have put in since the various stake holders took a look at it. What browser vendors agree on is entirely unimportant to authors. What they care about is what actually ships. Once things are shipping browser vendors typically don't have much leeway to change things even when they all agree that it would be a nice idea. Right, but that's a non-sequitur to Jonas's point. Having snapshots of consensus that can be distinguished from whatever the editor just happened to braindump into the spec is very useful to anyone joining the conversation mid-way. The alternative is trawling through diffs and older thread which is error-prone, a barrier to entry, and conducive to permathreads. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Component Model Update
On Thu, Aug 25, 2011 at 5:41 PM, 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!!';
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's content.
It would be rather strange if one needs to explicitly construct
shadow tree after the element is created.
Looking at the use cases, it looks like components need to run script
anyway, at least to hook up event listeners. So would it be fair to
rephrase this as: “There should be a concise way to get HTML into a
shadow tree.” ?
(Component Model is getting closer and closer to XBL, and it is not
quite clear to me why XBL2 couldn't be used. It needs some
minor fixes, but should work otherwise.)
I feel like XBL2 doesn’t get the power-to-weight ratio right—it looks
hard to use and implement, and as this
http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations
summarizes XBL2 doesn’t mesh well with JavaScript, and doesn’t get
confinement. So this proposal looks like it made a good tradeoff…
eliminate a lot of what’s complex to use and implement in XBL2, and
focusses instead on useful capabilities like confinement.
Dimitri et al studied XBL2 in depth in designing the component model.
It is possible when you follow through with minor fixes to XBL2 you
will end up here anyway… it might be more productive to work on
fleshing out and fixing this proposal.
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: Joystick support
Hi, This seems like it could fit more into the Web Events WG. In the Web Events, we deal with touch events, which are user inputs, this seems to be in the same category. Thanks Tran -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Robin Berjon Sent: Thursday, August 25, 2011 2:54 AM To: Paul Bakaus Cc: Scott Graham; public-webapps@w3.org; public-device-a...@w3.org Subject: Re: Joystick support Hi all, On Aug 25, 2011, at 10:49 , Paul Bakaus wrote: We should definitely open it up for a broader discussion. I think the right place for the discussion might be the new device apis WG, which I've cc'ed. It certainly feels like such an API would find a logical home in Device APIs. It's a shame that it didn't come up a little earlier since we just finished rechartering and it's not on our list of deliverables. That being said, if there's support for doing this work (in the form of people willing to put in the work of writing the spec and implementers willing to prototype and provide feedback) I'd be very happy to talk about finding it a home (in DAP or elsewhere). -- Robin Berjon - http://berjon.com/ - @robinberjon
RE: Joystick support
Also, there are some interests from our TV group to support such devices similar to Wii Remote. Thanks Tran -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Tran, Dzung D Sent: Thursday, August 25, 2011 7:23 AM To: Robin Berjon; Paul Bakaus Cc: Scott Graham; public-webapps@w3.org; public-device-a...@w3.org Subject: RE: Joystick support Hi, This seems like it could fit more into the Web Events WG. In the Web Events, we deal with touch events, which are user inputs, this seems to be in the same category. Thanks Tran -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Robin Berjon Sent: Thursday, August 25, 2011 2:54 AM To: Paul Bakaus Cc: Scott Graham; public-webapps@w3.org; public-device-a...@w3.org Subject: Re: Joystick support Hi all, On Aug 25, 2011, at 10:49 , Paul Bakaus wrote: We should definitely open it up for a broader discussion. I think the right place for the discussion might be the new device apis WG, which I've cc'ed. It certainly feels like such an API would find a logical home in Device APIs. It's a shame that it didn't come up a little earlier since we just finished rechartering and it's not on our list of deliverables. That being said, if there's support for doing this work (in the form of people willing to put in the work of writing the spec and implementers willing to prototype and provide feedback) I'd be very happy to talk about finding it a home (in DAP or elsewhere). -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Component Model Update
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fiwrote: One thing missing is some kind of declarative way to define shadow trees, similar to XBL1's content. I think this omission is a big plus. XBL1 content is mysterious. If a dev tool wants to add support for building Components from declarative markup, awesome. But the bizarre combo of xml, .css, and .js in XBL one is poorly supported by tooling and thus is just a mess. Create a great JS solution then let tools build on that. jjb
Re: Component Model Update
On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote: One thing missing is some kind of declarative way to define shadow trees, similar to XBL1's content. It would be rather strange if one needs to explicitly construct shadow tree after the element is created. I know we plan to add a declarative syntax similar to XBL, but the scripted syntax gets into the details better, so it's better to focus on that first. It's also easy, when you start from a declarative solution, to accidentally build in magic that's hard to replicate imperatively. Starting from imperative has similar risks, but I think they're easier to manage. ~TJ
[Component Model] Declarative syntax for shadow DOM subtrees, was Re: Component Model Update
On Thu, Aug 25, 2011 at 8:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote: One thing missing is some kind of declarative way to define shadow trees, similar to XBL1's content. It would be rather strange if one needs to explicitly construct shadow tree after the element is created. I know we plan to add a declarative syntax similar to XBL, but the scripted syntax gets into the details better, so it's better to focus on that first. It's also easy, when you start from a declarative solution, to accidentally build in magic that's hard to replicate imperatively. Starting from imperative has similar risks, but I think they're easier to manage. Splitting into a fresh thread. I also think being able to use markup to declare shadow DOM trees is pretty cool, however I would strongly recommend coming up with a use case that clearly illustrates the need for it. Now that we have a fairly rigorous framework around this spec development (http://wiki.whatwg.org/wiki/Component_Model_Methodology), we should follow it. So we have to answer this question first: Why and to Whom is it important to have such a feature? One notion I was toying with is productivity, since declarative markup should be easier to read. Another possible point is consistency: we can build DOM trees using markup in a document, why not in shadow DOM? I don't think performance quite cuts it anymore, since JS engines have gotten to the point where I doubt you'll see a significant difference between declarative and imperative tree instantiation. :DG
Re: Joystick support
Thanks all, On Thu, Aug 25, 2011 at 2:54 AM, Robin Berjon ro...@berjon.com wrote: ... That being said, if there's support for doing this work (in the form of people willing to put in the work of writing the spec and implementers willing to prototype and provide feedback) I'd be very happy to talk about finding it a home (in DAP or elsewhere). I'm not experienced in the process, but am happy to do the work of writing the spec and prototyping an implementation. I guess I will try to take the step of putting together a rough strawman spec so we have something concrete to discuss. scott
Re: HTTP, websockets, and redirects
On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow art.bars...@nokia.com wrote: Hi All, Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I would characterize them both as editorial [Bugs]. As such, the redirect issue Thomas originally reported in this thread (see [Head]) appears to be the only substantive issue blocking WSAPI Last Call. As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be characterized as editorial bugs. Microsoft has no objections to the requirement to fail non-101 responses such as redirects. If there are no further concerns in the working group related to this issue, then the current WebSocket API looks feature complete. I recommend that we publish a Last Call working draft and define a timetable to reach Candidate Recommendation. If anyone wants to continue discussing this redirect issue for WSAPI, I recommend using e-mail (additionally, it may be useful to also create a new bug in Bugzilla). As I understand it, the HyBi WG plans to freeze the Web Socket Protocol spec real soon now (~August 19?). -Art Barstow [WSAPI] http://dev.w3.org/html5/websockets/ [Head] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.ht ml [Bugs] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort _de sc_type=allwordssubstrshort_desc=product=WebAppsWGcomponent=We bSocket+API+%28editor%3A+Ian+Hickson%29longdesc_type=allwordssubstr longdesc=bug_file_loc_type=allwordssubstrbug_file_loc=status_white boar d_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywo r ds=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailt ype1=substringemail1=emailtype2=substringemail2=bug_id_type=anyex actbug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=d oitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0- 0=noopvalue0-0-0= On 7/27/11 8:12 PM, ext Adam Barth wrote: On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro gabriel.montene...@microsoft.com wrote: Thanks Adam, By discussed on some mailing list, do you mean a *W3C* mailing list? A quick search turned up this message: But I'm totally fine with punting on this for the future and just disallowing redirects on an API level for now. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079. html I started that thread at Greg Wilkins' recommendation: This is essentially an API issue for the browser websocket object. http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html Also, allowing the users to handle these explicitly implies that the API does not mandate dropping the connection. Currently, the API does not have this flexibility, nor does it allow other uses of non-101 codes, like for authentication. I understand the potential risks with redirects in browsers, and I thought at one moment we were going to augment the security considerations with your help for additional guidance. If websec has already worked on similar language in some draft that we could reuse that would be great, or, similarly, if we could work with you on that text. We can always add support for explicitly following redirects in the future. If we were to automatically follow them today, we'd never be able to remove that behavior by default. Adam -Original Message- From: Adam Barth [mailto:w...@adambarth.com] Sent: Sunday, July 24, 2011 13:35 To: Thomas Roessler Cc: public-ietf-...@w3.org; WebApps WG; Salvatore Loreto; Gabriel Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald Alvestrand; Tobias Gondrom Subject: Re: HTTP, websockets, and redirects This issue was discussed on some mailing list a while back (I forget which). The consensus seemed to be that redirects are the source of a large number of security vulnerabilities in HTTP and we'd like users of the WebSocket API to handle them explicitly. I'm not sure I understand your question regarding WebRTC, but the general answer to that class of questions is that WebRTC relies, in large part, on ICE to be secure against cross-protocol and voicehammer attacks. Adam On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roesslert...@w3.org wrote: The hybi WG is concerned about the following clause in the websocket API spec: When the user agent validates the server's response during the establish a WebSocket connection algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the websocket connection. http://dev.w3.org/html5/websockets/ Discussion with the WG chairs: - this looks like a conservative attempt to lock down redirects in the face of ill-understood cross-protocol interactions - critical path for addressing includes analysis of interaction with XHR, XHR2, CORS - following redirects in HTTP is optional for the client, therefore in principle a
Re: [selectors-api] Return an Array instead of a static NodeList
On Thu, Aug 25, 2011 at 2:33 AM, Jonas Sicking jo...@sicking.cc wrote:
That works, but what is the advantage?
The same advantage as having those methods work for Array. :)
They're useful for lots of stuff.
And .push/.pop or other mutating functions wouldn't work.
Right. I'm only talking about the methods that are already generic
and work with anything that looks like an Array: filter, forEach,
every, etc.
On Thu, Aug 25, 2011 at 3:03 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 24, 2011 at 11:47 PM, Julien Richard-Foy
jul...@richard-foy.fr wrote:
All mutable functions will work (forEach, map, etc.) and bring a better
expressiveness to the code.
Not if he 'this' object is a NodeList.
This works fine right now:
alert(
[].filter.call(document.querySelectorAll(*), function(elem) {
return elem.textContent.length 6 })
.map(function(elem) { return elem.tagName })
.join(, )
);
And I use that pattern a *lot*, but it's both verbose and extremely
unintuitive. Why can't that be just this?
alert(
document.querySelectorAll(*)
.filter(function(elem) { return elem.textContent.length 6 })
.map(function(elem) { return elem.tagName })
.join(, )
);
Likewise for all Array-like types, but NodeList is the most common.
RE: [indexeddb] Updates to the IDBCursor.advance method text and exception list.
I made these changes. E -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps- requ...@w3.org] On Behalf Of Jonas Sicking Sent: Monday, August 22, 2011 7:20 PM To: Israel Hilerio Cc: public-webapps@w3.org; Tom Bolds Subject: Re: [indexeddb] Updates to the IDBCursor.advance method text and exception list. On Mon, Aug 22, 2011 at 5:24 PM, Israel Hilerio isra...@microsoft.com wrote: I wanted to confirm with you that we want to add the following text to the IDBCursor.advance to keep it consistent with IDBCursor.continue: Before this method returns, unless an exception was thrown, it sets the got value flag on the cursor to false. Calling this method more than once before the cursor data has been loaded is not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For example, calling advance() twice from the same onsuccess handler results in a NOT_ALLOWED_ERR being thrown on the second call. IDBDatabaseException: * TRANSACTION_INACTIVE_ERR - The transaction this IDBCursor belongs to is not active. * NOT_ALLOWED_ERR - The cursor is currently being iterated, or has iterated past its end. If we agree, we can make this change. Sounds good to me. / Jonas
Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
Le 22 août 2011 à 05:47, James Graham a écrit : Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are Note that in some circumstances it might have some benefits in forcing orthogonality. Our tools and cultural usage of tools are shaping the way we think both ways but… What they [authors] care about is what actually ships. Not the point. I think Jonas was making. A smaller specification is easier to grasp, and even if authors care about what actually ships, they also like to read the specification be it directly or through a technical writer. Smaller specifications are easier to read for those readers. Robin is making a good point. The same way the document is one agent participating to the way you *design* a technology, it is also a way to design the way we work together. Le 25 août 2011 à 09:19, Robin Berjon a écrit : • Is it easier for twenty editors to work on a single document or on twenty smaller documents? And by this I mean measurably — not personally. When we talk small/big documents, we are not asking the right questions. The way we want to work (editors, wgs, etc.), the type of usage we want for these documents (readers, articles, implementers), the way these documents will be handled by the society (patent policy, references), etc. All of that is what creates the choice. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
[Bug 13908] New: WordStar semantics aren't supported
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13908 Summary: WordStar semantics aren't supported Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: i...@hixie.ch QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org The editing spec assumes that the caret cannot be independent of the current user selection. However, the selection spec rightly says On some platforms (such as those using Wordstar editing conventions), the caret position is totally independent of the start and end of the selection, even when the selection is empty. Thus, for instance, if [...] denotes the selection and | denotes the caret, and the current situation is: He|ll[o World] ...then when the user hits enter, the result will unexpectedly be: Hell | ...rather than, as expected: He ll[o World] ...which is what one would get in an editing environment with WordStar semantics. This isn't a huge problem since browsers pretty much all have a caret that matches the selection, but we shouldn't be making UAs that want to try different interaction models non-conforming. At a minimum, therefore, things in the Additional Requirements section should be SHOULD not MUST. Even better would be to handle the case of the caret not matching the selection explicitly. In UAs with WordStar semantics, you never blow away the selection implicitly. So this might be as easy as only doing that in the cases where the selection is treated like a fat caret. -- 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.
[Bug 13909] New: Selections have three possible directions, not two
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13909 Summary: Selections have three possible directions, not two Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Range AssignedTo: dave.n...@w3.org ReportedBy: i...@hixie.ch QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org On Mac, a newly created selection is by default neither forward nor backward. See the equivalent text in the HTML spec for input elements. -- 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.
[Bug 13910] New: There can never be no active range
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13910 Summary: There can never be no active range Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: i...@hixie.ch QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org According to DOM Range, there's always a selection; if it's empty, it is just one range with start=end. This means there's always an active range, so the Editing spec doesn't need to say it can be null. -- 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.
[Bug 13911] New: Active range's definition relies on the context object but there might not be one
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13911 Summary: Active range's definition relies on the context object but there might not be one Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: i...@hixie.ch QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org context object is defined as the object on which the method or attribute being discussed was called. active range is defined as The active range is the first range in the Selection given by calling getSelection() on the context object. However, in the context of the definition of active range, there isn't a method or attribute being discussed, so the term context object is undefined. If we assume that the definition of context object is to be inherited from wherever the term active range is defined, then this fails in the case of the Additional Requirements section, where user interaction results in calling algorithms that rely on the active range, despite no method or attribute being involved at all at any point. -- 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.
[Bug 13913] New: Attributes don't have an order
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13913 Summary: Attributes don't have an order Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: i...@hixie.ch QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Copy all attributes of element to replacement element, in order doesn't say what order. -- 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: Mouse Lock
Continuing the discussion of some of the open issues I'm aware of: -- If MouseEvent types are returned under mouse lock, what should .clientX/Y and screenX/Y be? -- Spec as drafted states they should be the center of the target element. That's likely a poor idea, as discussed, and a better solution is to freeze .clientX/Y and screenX/Y to whatever their last value from the user agent was. (Pending feedback, I will update spec to state that .clientX/Y .screenX/Y will report the same constant values of the last known cursor position just as mouse lock was entered. This will also be the location the system cursor will be placed at when mouse lock is exited) -- Modify MouseEvent, or a new type returned by new mouse events? -- Spec as drafted now has simply added .movementX/Y data members to the MouseEvent type which is returned by mouse events: click, mousedown, mouseup, mouseover, mousemove, mouseout. No new mouse event types are introduced. Several, including Glenn Maynard, Robert O'Callahan have brought up points against this, suggesting different events and types. Let me enumerate options and my perceived pro/cons: Option A: as currently drafted: reuse existing mouse events, make minimal modification to MouseEvent to include movementX/Y valid regardles of mouse lock state, mouseover mouseout will never be fired under mouse lock. pro 1. minimal change to existing events and types pro 2. movementX/Y available even when mouse is not locked. Purely a convenience, apps could compute similar data by tracking the last position of a mouse event and computing deltas (resetting last position on a mouseover event). pro 3. event handling code that can operate both with and without mouse lock being acquired can do so easily using the same functions and taking the same MouseEvent data type input. e.g. rotateView(mouse_event) could be called from a mousemove event regardless of mouse lock state and still use .movementX/Y. con 1. When under mouse lock, clientX/Y screenX/Y will not offer any useful data - or worse implementations may not follow spec and provide misleading data of the actual hidden cursor location. con 2. Not all mouse events using MouseEvent are appropriate, mouseover and mouseout should be suppressed. Glen continued that it is probably cleaner to stop firing *all* mouse movement events entirely, as if the mouse isn't moving, and to use a separate mousedelta event when locked which only has deltaX and deltaY. Robert reiterated that point. Option B: make no use of or modification to any existing mouse event or the MouseEvent type. New mouse events created with unique names for click, down, up, move, e.g. mouselockclick, mouselockdown, mouselockup, mouselockmove. New events return a MouseLockEvent type derived from UIEvent that contains movementX/Y, ctrlKey, shiftKey, altKey, metaKey, button. The events and data types are completely mutually exclusive based on the state of mouse lock. pro 1. (dual of Option A con 1): clientX/Y screenX/Y do not exist under mouse lock. pro 2. (dual of Option A pro 3): Functions designed specifically to operate only under mouse lock, or only when not under mouse lock, are only triggered when appropriate. con 1. (dual of Option A pro 1): Larger change, introducing 4 new events and a new return type. con 2. (dual of Option A pro 2): movementX/Y must be calculated manually by apps when not under lock. Some hybrid could be considered, e.g. only make a new mouselockmove event but reuse the click/down/up events. I don't think that hybrid is worth discussing. My opinion: - Option A con 1 (.client .screen not useful, could be wrong): I don't perceive much damage here, and if implementation are making mistakes much more could go wrong elsewhere, but they don't get new data even with faulty client and screen data. - Option A con 2 (not all events returning MouseEvent are appropriate in mouse lock) isn't substantial... 4 of the events are and they happen to share a MouseEvent type. - I see no logical argument leading us to one or the other option. I'd prefer the minimal change, the convenience of code that can use the same MouseEvent structure, and .movementX/Y even when not in mouse lock. (Pending feedback, I will leave spec at Option A but add clarification about e.g. mouseover/mouseout not being called) -- Separate targets for keyboard and mouse locked events? -- Robert: ... is there a need for mouse-lock motion events to go to one element while keyboard input goes elsewhere? ... I'm asking whether we can reuse the existing notion of the currently focused element and send mouse events to that element while the mouse is locked. I argue yes, there's a good cause for mouse events to a different target than keyboard input. Status quo enables typing into an input field while mousemove events are sent to different targets the mouse happens to be moving over. In mouse lock, consider a game with a 3D viewport controlled by mouse and a chat window with the active keyboard
Re: xdash name prefixes (was Re: Component Model Update)
On Wed, Aug 24, 2011 at 5:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: 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. That's a pretty narrow view. :) Adam
Re: [WebIDL] remove modules
Paddy Byers: WAC does refer to interfaces defined in one module from another module; however, we have not been using scoped names for these references - we use the unqualified interface name. More or less every WAC module does this. Cameron McCormack: If WAC is already considering these names globally, and incorrectly referring to them without using scoped names, then it seems like they are not actually using the functionality that modules affords them. WAC is using modules solely as a grouping mechanism, and not as a namespacing mechanism, as far as I can see. So it seems like no actual important functionality would be lost if we dropped modules from Web IDL. If all you need to do is group some definitions together and give them a name, you could simply say in your specs: The foo module comprises the following interfaces and exceptions: Foo, Bar, DontTouchThat, etc. If WAC specs already define an interface named, for example, Element, then it's going to be problematic if you want to have an implementation that supports both that WAC spec and the DOM spec. You can't have both interface objects living at window.Element. If WAC specs define an interface named Goober, and then in the future a Web platform spec comes long and defines an interface named Goober, then that's also going to be a problem, and you could of course request the relevant W3C WG use a different name. Paddy/Brian, do you agree with my assessment? I think we should focus on the fact that Web IDL is primarily to be used for defining Web platform features. If other ecosystems wish to use Web IDL, that's fine, but when there are conflicting interests we should favour the Web. (I think the future of JavaScript namespacing (in terms of avoiding name clashes across independently written codebases) is going to be ES Harmony Modules. They're not quite done yet, but when they are then I think it would be better to have a Web IDL module mechanism map to them.)
Re: Joystick support
On Thu, 25 Aug 2011 16:23:19 +0200, Tran, Dzung D dzung.d.t...@intel.com wrote: This seems like it could fit more into the Web Events WG. In the Web Events, we deal with touch events, which are user inputs, this seems to be in the same category. Yes, I also think this belongs in Web events. Cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Mon, Aug 22, 2011 at 2:47 AM, James Graham jgra...@opera.com wrote: On 08/22/2011 11:22 AM, Jonas Sicking wrote: http://www.whatwg.org/specs/web-apps/current-work/complete/ I *always* used the much smaller document that used to be available here: www.whatwg.org/specs/web-workers/current-work/ I don't really understand your point here. If you used the smaller document presumably you could just have easily have read the relevant chapter from the larger document. The point is that if it's just a chapter in a larger spec, how do I know that there isn't other important information in the larger spec that I have to read in order to get a understanding of the full feature. When implementing a spec, the first thing I'd like to do is to read the whole spec front to back. This in order to get a sense for the various concepts involved which affects the implementation strategy. It is also important as it's required to review the specification. With a spec the size of, for example, the HTML5 spec, this is substantially more difficult. Not only does it take significantly longer to read the full HTML5 spec if all I want to implement is the pushState feature. It's also impossible to hold the fully spec in memory, even at a high level. Why would you read the whole spec to implement features contained in a single subsection? Alternatively, why wouldn't you read the whole HTML5 spec to implement web workers since there are normative dependences? It seems very arbitrary to base your choice of what is enough background information on someone else's choice of multiple files vs multiple sections in a single file. Small specs are absolutely more easily implemented and reviewed. I think this is an illusion. Self-contained features are more easily implemented and reviewed. There is no reason that a relatively self-contained feature can't be a section of a larger document. But how will I as a reader know if the feature is self contained or not? Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are, leading to the problem of important detail dropping into the gaps between the specs. What people need in order to design good specifications is to have an understanding of the web platform. If they don't have that then they won't design a good spec. I don't see how merging specifications into a larger specifications will increase their understanding. In particular, they need to have an understanding of the features that their spec is related to. We'll help them a lot more by making it easy to research those features, than my merging specs together and hope that that causes them to read more. Additionally, having releases of a spec makes it possible to know what browser vendors and other significant players agree on. A ever changing slowly evolving spec doesn't say what browser vendors agree is good as opposed to what the editor happened to have put in since the various stake holders took a look at it. What browser vendors agree on is entirely unimportant to authors. What they care about is what actually ships. Once things are shipping browser vendors typically don't have much leeway to change things even when they all agree that it would be a nice idea. I'm not talking about authors, I'm talking about browser vendors. As someone looking to implement a spec, I'm very interested in knowing which parts of the spec has consensus and which ones doesn't. / Jonas
