AW: WebSocket API: close and error events
Is executing step 2 above (fire error) meant to cancel execution of step 3 (fire close)? No, it would say ...and abort these steps if it did. Just to be sure I get that right: If step 2 is executed, that is error is fired, then abort and do not continue with step 3, that is do not fire close If step 2 is not executed, continue and execute step 3, that is fire close ? Specifically, which events should be fired when WS(S) connection establishment fails due to: a) host unreachable (TCP could not even be established) b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus no WS handshake also) c) TLS handshake failed due to invalid server certificate d) TLS handshake failed for other reasons (invalid client cert, non-acceptable ciphers, ..) All of these should be handled identically (for security reasons -- if we treat them differently you could use it to probe non-WebSocket servers on an intranet, for instance). Ok, I see. Thats a good reason. Practically, I am mostly interested in: How can I detect TLS failed due to invalid server cert from JavaScript in the context of WSS. You cannot, by design. If we allowed JS to detect this it would enable attackers to do network topology scans of restricted networks. Ok. Would the following then be appropriate behavior for browsers? User loads https://somehost.com:9000/index.html UA presents cert for somehost:9000 not trusted .. accept .. continue? dialog. = That dialog is builtin, no JS involved. As today. If user continues, then index.html loads, contains JS. The JS then opens wss://somehost.com:9090 UA present cert for somehost:9090 not trusted .. accept .. continue? [*] = Builtin dialog, no JS involved. Not available in browsers today. If user continues, then the WSS connection succeeds. WS onopen() handler fires. If user does not continue, then WSS connection fails. WS onerror() handler fires - the latter does not give reason for failure. The JS will get onerror() fired for all reasons a) - d) above. Thus, there would be not only needed new dialog [*] for invalid server cert, but also for the other reasons a) - d). In no case JS involved .. dialogs are browser builtin. Does above make sense?
Re: Proposal for a new Matrix API
Hello, On Fri, Oct 21, 2011 at 8:04 PM, Cameron McCormack c...@mcc.id.au wrote: On 20/10/11 10:39 AM, Igor Oliveira wrote: Currently CSSMatrix and SVGMatrix has an immutable API. None of the method calls change the Matrix, instead, it creates a new Matrix with the changed value. It can be a problem specially when CSSMatrix is used together with WebGL. [1] SVGMatrix is not immutable. You can modify the a, b, ..., f properties. Yeah, i meant the rotate, multiply, inverse, translate and others methods. http://www.w3.org/TR/SVG/coords.html#InterfaceSVGMatrix However the methods that perform operations do return new matrices rather than modifying the one the method is called on. We from WebKit are proposing a new Matrix API(simple as possible), see below or [2], where the standard methods change the matrix(in place operations) and additional methods (multipliedBy, scaledBy and so on) create a new Matrix as is done by CSSMatrix and SVGMatrix. The idea is make this class accepted where CSSMatrix and SVGMatrix is used and be the preferred class for all Matrix needs. [3] I agree that unifying CSSMatrix/SVGMatrix is a good idea, if that is possible. Will look at your specific proposal a bit later. Great. Igor
Re: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011 10:49:05 +0200, Tobias Oberstein tobias.oberst...@tavendo.de wrote: Is executing step 2 above (fire error) meant to cancel execution of step 3 (fire close)? No, it would say ...and abort these steps if it did. Just to be sure I get that right: If step 2 is executed, that is error is fired, then abort and do not continue with step 3, that is do not fire close If step 2 is not executed, continue and execute step 3, that is fire close ? No. Specifically, which events should be fired when WS(S) connection establishment fails due to: a) host unreachable (TCP could not even be established) b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus no WS handshake also) c) TLS handshake failed due to invalid server certificate d) TLS handshake failed for other reasons (invalid client cert, non-acceptable ciphers, ..) All of these should be handled identically (for security reasons -- if we treat them differently you could use it to probe non-WebSocket servers on an intranet, for instance). Ok, I see. Thats a good reason. Practically, I am mostly interested in: How can I detect TLS failed due to invalid server cert from JavaScript in the context of WSS. You cannot, by design. If we allowed JS to detect this it would enable attackers to do network topology scans of restricted networks. Ok. Would the following then be appropriate behavior for browsers? User loads https://somehost.com:9000/index.html UA presents cert for somehost:9000 not trusted .. accept .. continue? dialog. = That dialog is builtin, no JS involved. As today. If user continues, then index.html loads, contains JS. The JS then opens wss://somehost.com:9090 UA present cert for somehost:9090 not trusted .. accept .. continue? [*] = Builtin dialog, no JS involved. Not available in browsers today. I believe Opera does this (if you enable websockets). We might change this to reject untrusted certs for websocket, though. If user continues, then the WSS connection succeeds. WS onopen() handler fires. If user does not continue, then WSS connection fails. WS onerror() handler fires - the latter does not give reason for failure. The JS will get onerror() fired for all reasons a) - d) above. Thus, there would be not only needed new dialog [*] for invalid server cert, but also for the other reasons a) - d). In no case JS involved .. dialogs are browser builtin. Does above make sense? No, both error and close fire. -- Simon Pieters Opera Software
AW: AW: WebSocket API: close and error events
Would the following then be appropriate behavior for browsers? User loads https://somehost.com:9000/index.html UA presents cert for somehost:9000 not trusted .. accept .. continue? dialog. = That dialog is builtin, no JS involved. As today. If user continues, then index.html loads, contains JS. The JS then opens wss://somehost.com:9090 UA present cert for somehost:9090 not trusted .. accept .. continue? [*] = Builtin dialog, no JS involved. Not available in browsers today. I believe Opera does this (if you enable websockets). We might change this to reject untrusted certs for websocket, though. Does that mean Opera might just _silently_ reject untrusted certs without giving the user a dialog to accept the cert? That would be unfortunate IMHO. Since then there is no way to get an acceptable user experience any longer. I can't present a JS created notification and act accordingly, since JS won't be allowed to detect invalid cert. I can't rely on the browser rendering a builtin dialog for the user to accept the cert. WSS just fails silently. How is a JS app using WSS supposed to create an acceptable user experience? btw: does Opera support =Hybi-10, and if so, how do I activate it? If user continues, then the WSS connection succeeds. WS onopen() handler fires. If user does not continue, then WSS connection fails. WS onerror() handler fires - the latter does not give reason for failure. The JS will get onerror() fired for all reasons a) - d) above. Thus, there would be not only needed new dialog [*] for invalid server cert, but also for the other reasons a) - d). In no case JS involved .. dialogs are browser builtin. Does above make sense? No, both error and close fire. Ok. There are different views on that I guess http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html but I - given the comment by Ian, that JS should in no case get detailed error feedback on invalid cert, whether onclose fires or not - honestly do not care any longer .. it won't solve my problem anyway. On the other hand, I think it should be decided which is the desired behavior: fire onerror only, or fire both.
Re: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011 15:54:17 +0200, Tobias Oberstein tobias.oberst...@tavendo.de wrote: Would the following then be appropriate behavior for browsers? User loads https://somehost.com:9000/index.html UA presents cert for somehost:9000 not trusted .. accept .. continue? dialog. = That dialog is builtin, no JS involved. As today. If user continues, then index.html loads, contains JS. The JS then opens wss://somehost.com:9090 UA present cert for somehost:9090 not trusted .. accept .. continue? [*] = Builtin dialog, no JS involved. Not available in browsers today. I believe Opera does this (if you enable websockets). We might change this to reject untrusted certs for websocket, though. Does that mean Opera might just _silently_ reject untrusted certs without giving the user a dialog to accept the cert? Right. That would be unfortunate IMHO. Since then there is no way to get an acceptable user experience any longer. I can't present a JS created notification and act accordingly, since JS won't be allowed to detect invalid cert. I can't rely on the browser rendering a builtin dialog for the user to accept the cert. WSS just fails silently. How is a JS app using WSS supposed to create an acceptable user experience? By using a cert that isn't rejected. btw: does Opera support =Hybi-10, No. -00. and if so, how do I activate it? Enable WebSockets in opera:config. If user continues, then the WSS connection succeeds. WS onopen() handler fires. If user does not continue, then WSS connection fails. WS onerror() handler fires - the latter does not give reason for failure. The JS will get onerror() fired for all reasons a) - d) above. Thus, there would be not only needed new dialog [*] for invalid server cert, but also for the other reasons a) - d). In no case JS involved .. dialogs are browser builtin. Does above make sense? No, both error and close fire. Ok. There are different views on that I guess http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html Seems Richard is misreading the spec. but I - given the comment by Ian, that JS should in no case get detailed error feedback on invalid cert, whether onclose fires or not - honestly do not care any longer .. it won't solve my problem anyway. OK. On the other hand, I think it should be decided which is the desired behavior: fire onerror only, or fire both. The spec clearly requires both. -- Simon Pieters Opera Software
Re: QSA, the problem with :scope, and naming
Your guesses are all right in terms of existing jQuery but one:
'div': [1, 2, 3, 4]
'': []
'#3': [3]
' div': [1, 2, 3]
'[foo=bar]': []
'[id=1]': [1]
':first-child': [1, 4]
'+ div': [5]
'~ div': [5, 6]
You can see the results live at http://jsfiddle.net/Dj3Ab/.
The basic rule is that if there is no combinator, a descendent combinator is
implied.
jQuery returns an empty list with an empty String, but querySelectorAll
throws an exception (the spec says that the selector SHOULD match a slightly
loosened version of the selector production in
http://www.w3.org/TR/2009/PR-css3-selectors-20091215/#w3cselgrammar, which
disallows the empty string). It probably makes sense for find or findAll to
raise an exception too, but an empty list is fine too.
I'm not as sure about the :scope cases. I can make some guesses:
e.findAll(:scope) // context
e.findAll(div:scope) // context
e.findAll([foo=bar]:scope) // context
e.findAll(:scope div) // 1,2,3,4
e.findAll(div:scope div) // 1,2,3,4
e.findAll(div:scope #3) // 3
e.findAll(body :scope div) // 1,2,3
e.findAll(div, :scope) // 0,context,1,2,3,4,5,6
e.findAll(body :scope div, :scope) // context,1,2,3
e.findAll(:not(:scope)) // all elements except context
In cases where :scope is used, I would say that the selector behaves
identically to the id hack used by most JavaScript libraries. In
particular, the selector is relative to the root element, and the :scope
element simply represents the context element.
So you could change the :scope rules to be:
e.findAll(#context) // context
e.findAll(div#context) // context
e.findAll([foo=bar]#context) // context
e.findAll(#context div) // 1,2,3,4
e.findAll(div#context div) // 1,2,3,4
e.findAll(div#context #3) // 3
e.findAll(body #context div) // 1,2,3
e.findAll(div, #context) // 0,context,1,2,3,4,5,6
e.findAll(body #context div, #context) // context,1,2,3
e.findAll(:not(#context)) // all elements except context
This also means that the above (non-:scope) rule could (I think) be restated
as:
- Each selector in a selector group passed to find or findAll has an
implied leading :scope
- If no initial combinator is supplied, a descendent combinator is
implied
Yehuda Katz
(ph) 718.877.1325
On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
Not necessarily. It depends what exactly it means for a selector to
contain
:scope for determining whether or not to enable the implied :scope
behaviour. Consider:
foo.find(:not(:scope));
Ooh, this is an interesting case too. So here's the full list of cases
which we need defined behavior for (again looking at Alex and Yehuda here).
In the following DOM
body id=3
div id=0/div
div id=context foo=bar
div id=1/div
div class=class id=2/div
div class=withChildren id=3div class=child id=4/div/div
/div
div id=5/div
div id=6/div
/body
What would each of the following .findAll calls return. I've included my
guessed based on the discussions so far:
var e = document.getElementById('context');
e.findAll(div) // returns ids 1,2,3,4
e.findAll() // returns an empty list
e.findAll(#3) // returns id 3, but not the body node
e.findAll( div) // returns ids 1,2,3
e.findAll([foo=bar]) // returns nothing
e.findAll([id=1]) // returns id 1
e.findAll(:first-child) // returns id 1
e.findAll(+ div) // returns id 5
e.findAll(~ div) // returns id 5, 6
e.findAll(:scope)
e.findAll(div:scope)
e.findAll([foo=bar]:scope)
e.findAll(:scope div)
e.findAll(div:scope div)
e.findAll(div:scope #3)
e.findAll(body :scope div)
e.findAll(div, :scope)
e.findAll(body :scope div, :scope)
e.findAll(:not(:scope))
/ Jonas
Re: Is BlobBuilder needed?
This ultimately amounts to syntactic sugar compared to the existing api. It's tasty, but adds no new functionality. Also there's still the issue of how this new api would provide the existing functionality around line endings, so less functionality at the moment. I'm not opposed to additions/enhancements, just want to put it in perspective and to question whether the api churn is worth it. On Mon, Oct 24, 2011 at 10:19 PM, Erik Arvidsson a...@chromium.org wrote: On Mon, Oct 24, 2011 at 19:54, Jonas Sicking jo...@sicking.cc wrote: Sure. Though you could also just do var b = new Blob(); b = new Blob([b, data]); b = new Blob([b, moreData]); That works for me. -- erik
Re: Is BlobBuilder needed?
The new API is smaller and simpler. Less to implement and less for web developers to understand. If it can meet all our use-cases without significant performance problems, then it's a win and we should do it. For line-endings, you could have the Blob constructor also take an optional endings argument: new Blob(String|Array|Blob|ArrayBuffer data, [optional] String contentType, [optional] String endings); On Tue, Oct 25, 2011 at 11:57 AM, Michael Nordman micha...@google.comwrote: This ultimately amounts to syntactic sugar compared to the existing api. It's tasty, but adds no new functionality. Also there's still the issue of how this new api would provide the existing functionality around line endings, so less functionality at the moment. I'm not opposed to additions/enhancements, just want to put it in perspective and to question whether the api churn is worth it. On Mon, Oct 24, 2011 at 10:19 PM, Erik Arvidsson a...@chromium.org wrote: On Mon, Oct 24, 2011 at 19:54, Jonas Sicking jo...@sicking.cc wrote: Sure. Though you could also just do var b = new Blob(); b = new Blob([b, data]); b = new Blob([b, moreData]); That works for me. I'm happy with this. In theory, vendors could implement this using copy-on-write or something similar so that this pattern is roughly as efficient as BlobBuilder, right?
Re: Is BlobBuilder needed?
On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai o...@chromium.org wrote: The new API is smaller and simpler. Less to implement and less for web developers to understand. If it can meet all our use-cases without significant performance problems, then it's a win and we should do it. For line-endings, you could have the Blob constructor also take an optional endings argument: new Blob(String|Array|Blob|ArrayBuffer data, [optional] String contentType, [optional] String endings); I believe (or at least, I maintain) that we're trying to do dictionaries for this sort of thing. Multiple optional arguments are *horrible* unless they are truly, actually, order-dependent such that you wouldn't ever specify a later one without already specifying a former one. ~TJ
[Bug 14564] New: mlnbdv bdg gk fgbjkgjfbjgfml vl bnkl ghl
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14564 Summary: mlnbdv bdg gk fgbjkgjfbjgfml vl bnkl ghl Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: mlnbdv bdg gk fgbjkgjfbjgfml vl bnkl ghl Posted from: 176.8.11.40 User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.102 Safari/535.2 -- 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 14564] mlnbdv bdg gk fgbjkgjfbjgfml vl bnkl ghl
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14564 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- 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: Is BlobBuilder needed?
+1! On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote: Hi everyone, It was pointed out to me on twitter that BlobBuilder can be replaced with simply making Blob constructable. I.e. the following code: var bb = new BlobBuilder(); bb.append(blob1); bb.append(blob2); bb.append(some string); bb.append(myArrayBuffer); var b = bb.getBlob(); would become b = new Blob([blob1, blob2, some string, myArrayBuffer]); or look at it another way: var x = new BlobBuilder(); becomes var x = []; x.append(y); becomes x.push(y); var b = x.getBlob(); becomes var b = new Blob(x); So at worst there is a one-to-one mapping in code required to simply have |new Blob|. At best it requires much fewer lines if the page has several parts available at once. And we'd save a whole class since Blobs already exist. / Jonas
Re: Is BlobBuilder needed?
On Tue, Oct 25, 2011 at 3:53 PM, Ojan Vafai o...@chromium.org wrote: I'm happy with this. In theory, vendors could implement this using copy-on-write or something similar so that this pattern is roughly as efficient as BlobBuilder, right? It's simpler than that, since Blob data is immutable; you don't even need copy-on-write, just shallow copies. But you want that with BlobBuilder, too; I don't think this changes anything. -- Glenn Maynard
Re: Is BlobBuilder needed?
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai o...@chromium.org wrote: The new API is smaller and simpler. Less to implement and less for web developers to understand. If it can meet all our use-cases without significant performance problems, then it's a win and we should do it. For line-endings, you could have the Blob constructor also take an optional endings argument: new Blob(String|Array|Blob|ArrayBuffer data, [optional] String contentType, [optional] String endings); I believe (or at least, I maintain) that we're trying to do dictionaries for this sort of thing. Multiple optional arguments are *horrible* unless they are truly, actually, order-dependent such that you wouldn't ever specify a later one without already specifying a former one. I agree actually. So, it could be any of the following: 1. new Blob(data, [optional] options) 2. new Blob(options, data...) 3. new Blob([optional] dataAndOptions) I don't feel strongly, but option 1 seems best to me since it allows simple usages like 'new Blob(foo)'. On the other hand, option 2 lets you not have to create an array to append multiple elements to the Blob.
Re: QSA, the problem with :scope, and naming
On Tue, Oct 25, 2011 at 10:43 AM, Yehuda Katz wyc...@gmail.com wrote: Your guesses are all right in terms of existing jQuery but one: 'div': [1, 2, 3, 4] '': [] '#3': [3] ' div': [1, 2, 3] '[foo=bar]': [] '[id=1]': [1] ':first-child': [1, 4] '+ div': [5] '~ div': [5, 6] You can see the results live at http://jsfiddle.net/Dj3Ab/. The basic rule is that if there is no combinator, a descendent combinator is implied. jQuery returns an empty list with an empty String, but querySelectorAll throws an exception (the spec says that the selector SHOULD match a slightly loosened version of the selector production in http://www.w3.org/TR/2009/PR-css3-selectors-20091215/#w3cselgrammar, which disallows the empty string). It probably makes sense for find or findAll to raise an exception too, but an empty list is fine too. I'm not as sure about the :scope cases. I can make some guesses: e.findAll(:scope) // context e.findAll(div:scope) // context e.findAll([foo=bar]:scope) // context e.findAll(:scope div) // 1,2,3,4 e.findAll(div:scope div) // 1,2,3,4 e.findAll(div:scope #3) // 3 e.findAll(body :scope div) // 1,2,3 e.findAll(div, :scope) // 0,context,1,2,3,4,5,6 e.findAll(body :scope div, :scope) // context,1,2,3 e.findAll(:not(:scope)) // all elements except context In cases where :scope is used, I would say that the selector behaves identically to the id hack used by most JavaScript libraries. In particular, the selector is relative to the root element, and the :scope element simply represents the context element. So you could change the :scope rules to be: e.findAll(#context) // context e.findAll(div#context) // context e.findAll([foo=bar]#context) // context e.findAll(#context div) // 1,2,3,4 e.findAll(div#context div) // 1,2,3,4 e.findAll(div#context #3) // 3 e.findAll(body #context div) // 1,2,3 e.findAll(div, #context) // 0,context,1,2,3,4,5,6 e.findAll(body #context div, #context) // context,1,2,3 e.findAll(:not(#context)) // all elements except context This also means that the above (non-:scope) rule could (I think) be restated as: Each selector in a selector group passed to find or findAll has an implied leading :scope If no initial combinator is supplied, a descendent combinator is implied I'm no longer strongly convinced that we need to support :scope not at the front of the selector. el.find(foo :scope bar) is equivalent to first doing el.matches(foo :scope), then running el.find(bar) if it does. This is slightly inconvenient with individual elements, but in the ideal future when .find returns a nice NodeList class that's a subtype of Array, the NodeList can have its own .filter and .find functions on it that automatically runs the operations over all the children and unions the results into a new NodeList. Then you can do elems.filter(foo :scope).find(bar), and you're done. ~TJ
Re: QSA, the problem with :scope, and naming
On 26/10/11 4:43 AM, Yehuda Katz wrote:
Your guesses are all right in terms of existing jQuery but one:
'div': [1, 2, 3, 4]
'': []
'#3': [3]
' div': [1, 2, 3]
'[foo=bar]': []
'[id=1]': [1]
':first-child': [1, 4]
'+ div': [5]
'~ div': [5, 6]
You can see the results live at http://jsfiddle.net/Dj3Ab/.
The basic rule is that if there is no combinator, a descendent
combinator is implied.
jQuery returns an empty list with an empty String, but
querySelectorAll throws an exception (the spec says that the selector
SHOULD match a slightly loosened version of the selector production in
http://www.w3.org/TR/2009/PR-css3-selectors-20091215/#w3cselgrammar,
which disallows the empty string). It probably makes sense for find or
findAll to raise an exception too, but an empty list is fine too.
I'm not as sure about the :scope cases. I can make some guesses:
e.findAll(:scope) // context
e.findAll(div:scope) // context
e.findAll([foo=bar]:scope) // context
e.findAll(:scope div) // 1,2,3,4
e.findAll(div:scope div) // 1,2,3,4
e.findAll(div:scope #3) // 3
e.findAll(body :scope div) // 1,2,3
e.findAll(div, :scope) // 0,context,1,2,3,4,5,6
e.findAll(body :scope div, :scope) // context,1,2,3
e.findAll(:not(:scope)) // all elements except context
In cases where :scope is used, I would say that the selector behaves
identically to the id hack used by most JavaScript libraries. In
particular, the selector is relative to the root element, and the
:scope element simply represents the context element.
I think allowing explicit :scope in findAll() will be perpetually
confusing. I can imagine someone looking at old code like:
e.findAll(div.foo span, div.bar :scope span)
and asking themselves what's the rule again? If there's :scope in the
selector then there's no :scope implied? Or was that just on each single
selector? Or is :scope always implied at the start of the whole selector
list and that's why it's explicit in the second part? Dammit, why didn't
we just use querySelectorAll() if we wanted explicit :scope?
So you could change the :scope rules to be:
e.findAll(#context) // context
e.findAll(div#context) // context
e.findAll([foo=bar]#context) // context
e.findAll(#context div) // 1,2,3,4
e.findAll(div#context div) // 1,2,3,4
e.findAll(div#context #3) // 3
e.findAll(body #context div) // 1,2,3
e.findAll(div, #context) // 0,context,1,2,3,4,5,6
e.findAll(body #context div, #context) // context,1,2,3
e.findAll(:not(#context)) // all elements except context
This also means that the above (non-:scope) rule could (I think) be
restated as:
* Each selector in a selector group passed to find or findAll has an
implied leading :scope
* If no initial combinator is supplied, a descendent combinator is
implied
Yehuda Katz
(ph) 718.877.1325
On Fri, Oct 21, 2011 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 20, 2011 at 2:33 PM, Lachlan Hunt
lachlan.h...@lachy.id.au mailto:lachlan.h...@lachy.id.au wrote:
Not necessarily. It depends what exactly it means for a
selector to contain
:scope for determining whether or not to enable the implied :scope
behaviour. Consider:
foo.find(:not(:scope));
Ooh, this is an interesting case too. So here's the full list of
cases which we need defined behavior for (again looking at Alex
and Yehuda here).
In the following DOM
body id=3
div id=0/div
div id=context foo=bar
div id=1/div
div class=class id=2/div
div class=withChildren id=3div class=child id=4/div/div
/div
div id=5/div
div id=6/div
/body
What would each of the following .findAll calls return. I've
included my guessed based on the discussions so far:
var e = document.getElementById('context');
e.findAll(div) // returns ids 1,2,3,4
e.findAll() // returns an empty list
e.findAll(#3) // returns id 3, but not the body node
e.findAll( div) // returns ids 1,2,3
e.findAll([foo=bar]) // returns nothing
e.findAll([id=1]) // returns id 1
e.findAll(:first-child) // returns id 1
e.findAll(+ div) // returns id 5
e.findAll(~ div) // returns id 5, 6
e.findAll(:scope)
e.findAll(div:scope)
e.findAll([foo=bar]:scope)
e.findAll(:scope div)
e.findAll(div:scope div)
e.findAll(div:scope #3)
e.findAll(body :scope div)
e.findAll(div, :scope)
e.findAll(body :scope div, :scope)
e.findAll(:not(:scope))
/ Jonas
Re: QSA, the problem with :scope, and naming
On Tue, Oct 25, 2011 at 1:47 PM, Sean Hogan shogu...@westnet.com.au wrote: I think allowing explicit :scope in findAll() will be perpetually confusing. I can imagine someone looking at old code like: e.findAll(div.foo span, div.bar :scope span) and asking themselves what's the rule again? If there's :scope in the selector then there's no :scope implied? Or was that just on each single selector? Or is :scope always implied at the start of the whole selector list and that's why it's explicit in the second part? Dammit, why didn't we just use querySelectorAll() if we wanted explicit :scope? Using :scope explicitly at the beginning of selectors is necessary if we want a sane way to have selector lists chain off of the scoping element. I'm okay with the string starting with a combinator when it's a single selector like + foo, but not when it's a selector list like + foo, + bar. ~TJ
AW: AW: AW: WebSocket API: close and error events
Does that mean Opera might just _silently_ reject untrusted certs without giving the user a dialog to accept the cert? Right. That would be unfortunate IMHO. Since then there is no way to get an acceptable user experience any longer. I can't present a JS created notification and act accordingly, since JS won't be allowed to detect invalid cert. I can't rely on the browser rendering a builtin dialog for the user to accept the cert. WSS just fails silently. How is a JS app using WSS supposed to create an acceptable user experience? By using a cert that isn't rejected. There are situations when self-signed certs are quite common like on private networks or where self-signed certs might be necessary, like with a software appliance that auto-creates a self-signed cert on first boot (and the user is too lazy / does not have own CA). The latter is our deployment scenario. We won't ship a fresh key / cert created by an official CA with every appliance. We won't force users to upload such a key/cert before they can use the appliance with https and wss. We need a smooth user experience for users to accept permanently the auto-created self-signed certs for https and wss the appliance uses. We will offer them a way to upload keys/certs when and if they want to. Do you think thats an invalid use case / approach?
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011, Tobias Oberstein wrote: There are situations when self-signed certs are quite common like on private networks or where self-signed certs might be necessary, like with a software appliance that auto-creates a self-signed cert on first boot (and the user is too lazy / does not have own CA). A self-signed cert essentially provides you with no security. You might as well be not bothering with encryption. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: QSA, the problem with :scope, and naming
On 26/10/11 7:51 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au wrote: I think allowing explicit :scope in findAll() will be perpetually confusing. I can imagine someone looking at old code like: e.findAll(div.foo span, div.bar :scope span) and asking themselves what's the rule again? If there's :scope in the selector then there's no :scope implied? Or was that just on each single selector? Or is :scope always implied at the start of the whole selector list and that's why it's explicit in the second part? Dammit, why didn't we just use querySelectorAll() if we wanted explicit :scope? Using :scope explicitly at the beginning of selectors is necessary if we want a sane way to have selector lists chain off of the scoping element. I'm okay with the string starting with a combinator when it's a single selector like + foo, but not when it's a selector list like + foo, + bar. ~TJ I didn't follow that. Why does findAll() need to support explicit :scope? It is simpler if querySelectorAll() supports explicit :scope and findAll() doesn't. Plus it means findAll() matches how js libs currently work. Sean
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 25 Oct 2011, Tobias Oberstein wrote: There are situations when self-signed certs are quite common like on private networks or where self-signed certs might be necessary, like with a software appliance that auto-creates a self-signed cert on first boot (and the user is too lazy / does not have own CA). A self-signed cert essentially provides you with no security. You might as well be not bothering with encryption. This is complete nonsense. Protecting against passive attacks is a major, clear-cut win, even without protecting against active (MITM) attacks. -- Glenn Maynard
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 2:34 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 25 Oct 2011, Tobias Oberstein wrote: There are situations when self-signed certs are quite common like on private networks or where self-signed certs might be necessary, like with a software appliance that auto-creates a self-signed cert on first boot (and the user is too lazy / does not have own CA). A self-signed cert essentially provides you with no security. You might as well be not bothering with encryption. This is complete nonsense. Protecting against passive attacks is a major, clear-cut win, even without protecting against active (MITM) attacks. Generally speaking, we don't want to show certificate errors for subresource loads (including WebSocket connections) because the user has no context for making a reasonable security decision. For example, Chrome doesn't let the user click through certificate errors for images or iframes. Protection against passive eavesdroppers isn't worth losing protection against active network attackers. Adam
Re: QSA, the problem with :scope, and naming
The only case I can think of where explicit scope might be useful would be to filter out certain cases entirely: elem.findAll(:scope:visible div); elem.findAll(#contents :scope [data-foo]) It's probably fine to just say that you should do a match first in that case, given the additional complexity of remembering all the rules. Alex, what do you think? Yehuda Katz (ph) 718.877.1325 On Tue, Oct 25, 2011 at 2:33 PM, Sean Hogan shogu...@westnet.com.au wrote: On 26/10/11 7:51 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au wrote: I think allowing explicit :scope in findAll() will be perpetually confusing. I can imagine someone looking at old code like: e.findAll(div.foo span, div.bar :scope span) and asking themselves what's the rule again? If there's :scope in the selector then there's no :scope implied? Or was that just on each single selector? Or is :scope always implied at the start of the whole selector list and that's why it's explicit in the second part? Dammit, why didn't we just use querySelectorAll() if we wanted explicit :scope? Using :scope explicitly at the beginning of selectors is necessary if we want a sane way to have selector lists chain off of the scoping element. I'm okay with the string starting with a combinator when it's a single selector like + foo, but not when it's a selector list like + foo, + bar. ~TJ I didn't follow that. Why does findAll() need to support explicit :scope? It is simpler if querySelectorAll() supports explicit :scope and findAll() doesn't. Plus it means findAll() matches how js libs currently work. Sean
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011, Glenn Maynard wrote: On Tue, Oct 25, 2011 at 5:18 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 25 Oct 2011, Tobias Oberstein wrote: There are situations when self-signed certs are quite common like on private networks or where self-signed certs might be necessary, like with a software appliance that auto-creates a self-signed cert on first boot (and the user is too lazy / does not have own CA). A self-signed cert essentially provides you with no security. You might as well be not bothering with encryption. This is complete nonsense. Protecting against passive attacks is a major, clear-cut win, even without protecting against active (MITM) attacks. That only makes sense if passive attack is significantly easier than active attack, which it is not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: QSA, the problem with :scope, and naming
On Tue, Oct 25, 2011 at 2:33 PM, Sean Hogan shogu...@westnet.com.au wrote: On 26/10/11 7:51 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au wrote: I think allowing explicit :scope in findAll() will be perpetually confusing. I can imagine someone looking at old code like: e.findAll(div.foo span, div.bar :scope span) and asking themselves what's the rule again? If there's :scope in the selector then there's no :scope implied? Or was that just on each single selector? Or is :scope always implied at the start of the whole selector list and that's why it's explicit in the second part? Dammit, why didn't we just use querySelectorAll() if we wanted explicit :scope? Using :scope explicitly at the beginning of selectors is necessary if we want a sane way to have selector lists chain off of the scoping element. I'm okay with the string starting with a combinator when it's a single selector like + foo, but not when it's a selector list like + foo, + bar. I didn't follow that. Why does findAll() need to support explicit :scope? Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. ~TJ
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 5:59 PM, Ian Hickson i...@hixie.ch wrote: That only makes sense if passive attack is significantly easier than active attack, which it is not. Passive attacks are significantly easier to do without any risk of discovery, especially on a large scale. -- Glenn Maynard
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, 25 Oct 2011, Glenn Maynard wrote: On Tue, Oct 25, 2011 at 5:59 PM, Ian Hickson i...@hixie.ch wrote: That only makes sense if passive attack is significantly easier than active attack, which it is not. Passive attacks are significantly easier to do without any risk of discovery, especially on a large scale. Sure, there are specific cases where one is easier than the other. There are also specific cases where it's easier to just send malware to the user than attempt a passive attack. That doesn't mean that we should just protect against malware and pretend that a passive attack is not a problem, just like we shouldn't pretend that active attacks are not a significant risk and thus should allow self-signed certs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: QSA, the problem with :scope, and naming
On 26/10/11 9:28 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 2:33 PM, Sean Hoganshogu...@westnet.com.au wrote: On 26/10/11 7:51 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.au wrote: I think allowing explicit :scope in findAll() will be perpetually confusing. I can imagine someone looking at old code like: e.findAll(div.foo span, div.bar :scope span) and asking themselves what's the rule again? If there's :scope in the selector then there's no :scope implied? Or was that just on each single selector? Or is :scope always implied at the start of the whole selector list and that's why it's explicit in the second part? Dammit, why didn't we just use querySelectorAll() if we wanted explicit :scope? Using :scope explicitly at the beginning of selectors is necessary if we want a sane way to have selector lists chain off of the scoping element. I'm okay with the string starting with a combinator when it's a single selector like + foo, but not when it's a selector list like + foo, + bar. I didn't follow that. Why does findAll() need to support explicit :scope? Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. So +foo becomes :scope +foo But +foo, +bar throws an error? What about: +foo, bar :scope+foo, bar body :scope+foo, :scope+bar What do JS lib selectors do? Do any support :scope? Do any not support +foo, +bar, foo, bar? Sean
Re: QSA, the problem with :scope, and naming
The CSS grammar (http://www.w3.org/TR/selectors/#w3cselgrammar) has a production for selector_group and selector. I would think that :scope would be prepended to each selector, not the entire selector group. -- Yehuda Katz On Tuesday, October 25, 2011, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 2:33 PM, Sean Hogan shogu...@westnet.com.aujavascript:; wrote: On 26/10/11 7:51 AM, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 1:47 PM, Sean Hoganshogu...@westnet.com.aujavascript:; wrote: I think allowing explicit :scope in findAll() will be perpetually confusing. I can imagine someone looking at old code like: e.findAll(div.foo span, div.bar :scope span) and asking themselves what's the rule again? If there's :scope in the selector then there's no :scope implied? Or was that just on each single selector? Or is :scope always implied at the start of the whole selector list and that's why it's explicit in the second part? Dammit, why didn't we just use querySelectorAll() if we wanted explicit :scope? Using :scope explicitly at the beginning of selectors is necessary if we want a sane way to have selector lists chain off of the scoping element. I'm okay with the string starting with a combinator when it's a single selector like + foo, but not when it's a selector list like + foo, + bar. I didn't follow that. Why does findAll() need to support explicit :scope? Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. ~TJ -- Yehuda Katz (ph) 718.877.1325
Re: AW: AW: AW: WebSocket API: close and error events
On Tue, Oct 25, 2011 at 6:32 PM, Ian Hickson i...@hixie.ch wrote: Sure, there are specific cases where one is easier than the other. There are also specific cases where it's easier to just send malware to the user than attempt a passive attack. That doesn't mean that we should just protect against malware and pretend that a passive attack is not a problem, just like we shouldn't pretend that active attacks are not a significant risk and thus should allow self-signed certs. I didn't say any of these things. I said encryption without a trusted signature is not useless. Encryption is always better than no encryption, whether or not you have a trusted certificate. Reducing the safe, undetectable, easily-scalable passive attacks is a significant win. (That doesn't mean the behavior in this particular case is wrong. Adam is almost certainly right: regular users have enough trouble with top-level certificates, and the subresource complication on top of that is probably too much. But please, stop equating unsigned crypto to cleartext.) -- Glenn Maynard
Re: QSA, the problem with :scope, and naming
* Tab Atkins Jr. wrote: Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. Allowing + foo but not + foo, + bar would be really weird. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
RE: [IndexedDB] IDBObjectStore.delete should accept a KeyRange
On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote: On Mon, Oct 24, 2011 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 24, 2011 at 10:17 AM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote: Currently IDBObjectStore.count/get/openCursor and IDBIndex.count/get/openCursor/openKeyCursor all take a key or a KeyRange. However IDBObjectStore.delete only accepts keys. We should fix this to allow .delete to accept a KeyRange as well. / Jonas This makes sense to me. Is this something we still want to do? Yup, I think so. I was just waiting to hear back from others. I'll go ahead and make that change to the spec right away. I made this change. I still kept the difference that .delete(null) does not work. I.e. it doesn't match, and delete, all records in the store. It simply seems like it would make it too easy to accidentally nuke all the data from an object store. We also already have the .clear() function to do that. While I was there it did occur to me that the fact that the .delete function returns (through request.result in the async API) true/false depending on if any records were removed or not might be bad for performance. I suspect that this highly depends on the implementation and that in some implementations knowing if records were deleted will be free and in others it will be as costly as a .count() and then a .delete(). In yet others it could depend on if a range, rather than a key, was used, or if the objectStore has indexes which might need updating. Ultimately I don't have a strong preference either way, though it seems unfortunate to slow down implementations for what likely is a rare use case. Let me know what you think. / Jonas To clarify, removing the return value from the sync call would change its return signature to void. In this case, successfully returning from the IDBObjectStore.delete call would mean that the information was successfully deleted, correct? If the information was not successfully deleted, would we throw an exception? In the async case, we would keep the same return value of IDBRequest for IDBObjectStore.delete. The only change is that the request.result would be null, correct? If no information is deleted or if part of the keyRange data is deleted, should we throw an error event? It seems reasonable to me. Let us know what you think. Israel
Re: QSA, the problem with :scope, and naming
On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Tab Atkins Jr. wrote: Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. Allowing + foo but not + foo, + bar would be really weird. Tab, what specifically is weird about el.find(+ foo, + bar)? Seeing a combinator immediately after a comma just seems weird to me. This may just be a personal prejudice. ~TJ
Re: QSA, the problem with :scope, and naming
fwiw, jQuery doesn't properly handle the comma-separated case, but this is most definitely a bug, caused by the naïve implementation that Alex showed early on in this thread. -- Yehuda On Tuesday, October 25, 2011, Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.orgjavascript:; wrote: On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.netjavascript:; wrote: * Tab Atkins Jr. wrote: Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. Allowing + foo but not + foo, + bar would be really weird. Tab, what specifically is weird about el.find(+ foo, + bar)? Seeing a combinator immediately after a comma just seems weird to me. This may just be a personal prejudice. ~TJ -- Yehuda Katz (ph) 718.877.1325
Re: QSA, the problem with :scope, and naming
On 26/10/11 11:03 AM, Yehuda Katz wrote: fwiw, jQuery doesn't properly handle the comma-separated case, but this is most definitely a bug, caused by the naïve implementation that Alex showed early on in this thread. So no-one is actually using +foo, +bar? How common is +foo usage? Sean
Re: QSA, the problem with :scope, and naming
On Tue, Oct 25, 2011 at 4:58 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Tab Atkins Jr. wrote: Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. Allowing + foo but not + foo, + bar would be really weird. Tab, what specifically is weird about el.find(+ foo, + bar)? Seeing a combinator immediately after a comma just seems weird to me. This may just be a personal prejudice. With my web developer hat on, I would expect the selector list version to just be a comma-separated list of any valid single selectors. We should either allow it in both cases or neither IMO. My preference is to allow it. Ojan
Re: QSA, the problem with :scope, and naming
* Tab Atkins Jr. wrote: On Tue, Oct 25, 2011 at 4:56 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Oct 25, 2011 at 4:44 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Tab Atkins Jr. wrote: Did you not understand my example? el.find(+ foo, + bar) feels really weird and I don't like it. I'm okay with a single selector starting with a combinator, like el.find(+ foo), but not a selector list. Allowing + foo but not + foo, + bar would be really weird. Tab, what specifically is weird about el.find(+ foo, + bar)? Seeing a combinator immediately after a comma just seems weird to me. A list of abbreviated selectors is a more intuitive concept than a list of selectors where the first and only the first selector may be abbreviated. List of type versus special case and arbitrary limit. If one abbreviated selector isn't weird, then two shouldn't be either if two selectors aren't weird on their own. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
A proposal for Element constructors
Hi folks,
* Background *
I have been working on making DOM objects look and feel more like ordinary
JavaScript objects. I implemented Event constructors [1], for example.
* Proposal *
Element.create() has proposed and been under discussion [2]. Besides
Element.create(), I propose constructors for Elements, like new
HTMLButtonElement(...), new HTMLDivElement(...) and new
HTMLVideoElement(...). I think that both Element.create() *and* Element
constructors are useful.
For example,
var button = new HTMLButtonElement( {disabled: true},
[new
TextNode(Click Me!!),
new
Image( {src: http://example.com/xxx.png http://xxx.com/xxx.png} ) ] );
document.body.appendChild(button);
is equivalent to the following HTML:
button disabled
Click Me!!
img src = http://example.com/xxx.png http://xxx.com/xxx.png /
/button
As shown in above, the constructor has two arguments. The first one is a
dictionary of Element properties. The second one is an array of Nodes, which
become child nodes of the Element.
* Advantages of Element constructors *
(a) Better errors when you misspell it
Element.create(vdieo, {src: ...} ) == No error; HTMLUnknownElement is
created
new HTMLVdieoElement( {src: ...} ) == ReferenceError; Stack trace points
you to the faulty line of code
(b) Consistency with other constructable DOM objects
e.g. new XMLHttpRequest(), new Image(), new Event(), new CustomEvent(), new
MessageEvent(), ...
(c) Enables to subtype DOM objects in the future
We are planning to make DOM objects subtype-able, like this:
function MyButton(text) {
HTMLButtonElement.call(this);/* (#) */
this.textContent = text;
}
MyButton.prototype = Object.create(HTMLButtonElement.prototype, {...});
var fancyButton = new MyButton(Click Me!!);
In order to make the line (#) work, HTMLButtonElement must have a
constructor.
* Spec examples *
interface [
NamedConstructor(optional HTMLButtonElementInit initDict, optional
NodeArray children)
] HTMLButtonElement : HTMLElement {
attribute boolean disabled;
attribute DOMString value;
... (omitted)
}
dictionary HTMLButtonElementInit : HTMLElementInit {
boolean disabled;
DOMString value;
... (omitted)
}
interface [
NamedConstructor(optional HTMLElementInit initDict, optional NodeArray
children)
] HTMLElement : Element {
attribute DOMString lang;
attribute DOMString className;
... (omitted)
}
dictionary HTMLElementInit : ElementInit {
DOMString lang;
DOMString className;
... (omitted)
}
interface Element : Node {
readonly attribute DOMString tagName;
... (omitted)
}
dictionary ElementInit : NodeInit {
DOMString tagName;
... (omitted)
}
interface Node {
readonly attribute unsigned short nodeType;
... (omitted)
}
dictionary NodeInit {
unsigned short nodeType;
... (omitted)
}
* Discussion
(a) Element.create() *and* Element constructors?
I think that both are useful for the reasons that dominicc pointed out in
[3]. Element.create() is good when we have a tag name in hand, like
var tag = button;
Element.create(tag, { }, ...);
On the other hand, Element constructors have the advantages that I described
above.
(b) How to specify properties and attributes in the dictionary argument
A property and an attribute are two different things [4]. A property is the
thing that can be set by a setter like foo.value, and an attribute is the
thing that can be set by foo.setAttribute(). A discussion has been conducted
on how we can set up properties and attributes in the dictionary argument
[2]. Proposed approaches in [2] are as follows:
(b-1) Let a constructor have two dictionaries, one for properties and the
other for attributes, e.g. new HTMLButtonElement( {disabled: true}, {class:
myButton, onclick: func}, ...)
(b-2) Add a prefix character to attributes, e.g new HTMLButtonElement(
{disabled: true, @class: myButton, @onclick: func} )
(b-3) Introduce a reserved key attributes, e.g new HTMLButtonElement(
{disabled: true, attributes: {class: myButton, onclick: func} } )
Another difficulty around attributes is how to naturally set a value of a
boolean attribute in the dictionary when we have the value in hand. In case
of a property, you just need to write like this:
var b = new HTMLButtonElement({disabled: value});
However, in case of an attribute, we need to write like this:
var options = {};
if (value)
options.disabled = ;
var b = new HTMLButtonElement(options);
Basically, I think that we should keep the succinctness of constructors and
should not introduce a new syntax just for allowing people to set attributes
in the constructor. Thus, I propose that we allow only properties in the
dictionary, at least at the present moment. If we found in the future that
people wish to set
Re: A proposal for Element constructors
Another solution to that more than one tag per interface problem is
to introduce subclasses of those interfaces for each tag.
Adam
On Tue, Oct 25, 2011 at 8:42 PM, Kentaro Hara hara...@chromium.org wrote:
Hi folks,
* Background *
I have been working on making DOM objects look and feel more like ordinary
JavaScript objects. I implemented Event constructors [1], for example.
* Proposal *
Element.create() has proposed and been under discussion [2]. Besides
Element.create(), I propose constructors for Elements, like new
HTMLButtonElement(...), new HTMLDivElement(...) and new
HTMLVideoElement(...). I think that both Element.create() *and* Element
constructors are useful.
For example,
var button = new HTMLButtonElement( {disabled: true},
[new
TextNode(Click Me!!),
new
Image( {src: http://example.com/xxx.png} ) ] );
document.body.appendChild(button);
is equivalent to the following HTML:
button disabled
Click Me!!
img src = http://example.com/xxx.png; /
/button
As shown in above, the constructor has two arguments. The first one is a
dictionary of Element properties. The second one is an array of Nodes, which
become child nodes of the Element.
* Advantages of Element constructors *
(a) Better errors when you misspell it
Element.create(vdieo, {src: ...} ) == No error; HTMLUnknownElement is
created
new HTMLVdieoElement( {src: ...} ) == ReferenceError; Stack trace points
you to the faulty line of code
(b) Consistency with other constructable DOM objects
e.g. new XMLHttpRequest(), new Image(), new Event(), new CustomEvent(), new
MessageEvent(), ...
(c) Enables to subtype DOM objects in the future
We are planning to make DOM objects subtype-able, like this:
function MyButton(text) {
HTMLButtonElement.call(this); /* (#) */
this.textContent = text;
}
MyButton.prototype = Object.create(HTMLButtonElement.prototype, {...});
var fancyButton = new MyButton(Click Me!!);
In order to make the line (#) work, HTMLButtonElement must have a
constructor.
* Spec examples *
interface [
NamedConstructor(optional HTMLButtonElementInit initDict, optional
NodeArray children)
] HTMLButtonElement : HTMLElement {
attribute boolean disabled;
attribute DOMString value;
... (omitted)
}
dictionary HTMLButtonElementInit : HTMLElementInit {
boolean disabled;
DOMString value;
... (omitted)
}
interface [
NamedConstructor(optional HTMLElementInit initDict, optional NodeArray
children)
] HTMLElement : Element {
attribute DOMString lang;
attribute DOMString className;
... (omitted)
}
dictionary HTMLElementInit : ElementInit {
DOMString lang;
DOMString className;
... (omitted)
}
interface Element : Node {
readonly attribute DOMString tagName;
... (omitted)
}
dictionary ElementInit : NodeInit {
DOMString tagName;
... (omitted)
}
interface Node {
readonly attribute unsigned short nodeType;
... (omitted)
}
dictionary NodeInit {
unsigned short nodeType;
... (omitted)
}
* Discussion
(a) Element.create() *and* Element constructors?
I think that both are useful for the reasons that dominicc pointed out in
[3]. Element.create() is good when we have a tag name in hand, like
var tag = button;
Element.create(tag, { }, ...);
On the other hand, Element constructors have the advantages that I described
above.
(b) How to specify properties and attributes in the dictionary argument
A property and an attribute are two different things [4]. A property is the
thing that can be set by a setter like foo.value, and an attribute is the
thing that can be set by foo.setAttribute(). A discussion has been conducted
on how we can set up properties and attributes in the dictionary argument
[2]. Proposed approaches in [2] are as follows:
(b-1) Let a constructor have two dictionaries, one for properties and the
other for attributes, e.g. new HTMLButtonElement( {disabled: true}, {class:
myButton, onclick: func}, ...)
(b-2) Add a prefix character to attributes, e.g new HTMLButtonElement(
{disabled: true, @class: myButton, @onclick: func} )
(b-3) Introduce a reserved key attributes, e.g new HTMLButtonElement(
{disabled: true, attributes: {class: myButton, onclick: func} } )
Another difficulty around attributes is how to naturally set a value of a
boolean attribute in the dictionary when we have the value in hand. In case
of a property, you just need to write like this:
var b = new HTMLButtonElement({disabled: value});
However, in case of an attribute, we need to write like this:
var options = {};
if (value)
options.disabled = ;
var b = new HTMLButtonElement(options);
Basically, I think that we should keep the succinctness of constructors and
