[selectors-api] Kudos on find/findAll, feedback on spec readability
I've been reading the CSS/selector specs lately. I'm interested both as a framework implementer, designing and implementing jQuery-like functionality for Meteor, and as an app developer who looks forward to the days when browsers provide the APIs we want. Coming into the new Selectors API, I was really hoping to discover that the proposed find and findAll methods behaved essentially like the jQuery calls. Put simply, in running elem.find(div p), both the div and the p in question would have to be descendants of elem (as well as each other) in order to match. In running elem.find( div p), there would be the additional constraint that only immediate descendants of elem would be considered as candidates for the div. Unfortunately, this didn't seem to be the case... until I read the spec about a half dozen more times, and I realized it was! If I'm reading it right, the spec does work this way and is additionally much more flexible about the relationship between the element, the scoping element (or elements), and the selector. From reading the list archives, I get the feeling that few web developers who come across the spec understand this much. First of all, I want to offer some encouragement. The names find and findAll are great, and their functionality is exactly what web developers will expect and appreciate. It's familiar and practical. And as long as in basic cases like element.find(a b c + d), it's required that all of a, b, c, and d descend from the element, I am happy with whatever scope selectors and edge cases are necessary or desirable. However, the spec is very hard to understand. I've read several specs cover-to-cover (Java VM, ECMAScript, JPEG) and I think there is a lot of low-hanging fruit in this short document (Selectors API Level 2) -- ways to improve its clarity and enlist your readers more in support of this spec. Some feedback from a reader, for what it's worth. 6.2 - ... first matching Element node within the subtrees... Don't define a new term subtrees which just means descendants. Say, ... first matching Element node that is a descendant of the context object. The main take-away from section 6.2 should be that find/findAll use a *different algorithm* from querySelector/querySelectorAll, or the same algorithm with a different setting (relative=true). This point is almost entirely lost. I think the intent is for the reader to perform a sort of dispatch on type when the algorithm in 6.5 is invoked, but it's confusing because you can't really look at a selector and a relative selector and tell them apart, and certainly not before parsing them. Isn't a relative selector (string) just a selector (string) optionally preceded by a combinator? It seems to me that find() and querySelector() *do different things*, conceptually; for example, the former will add an implicit :scope to your selector and the latter won't. It's nothing to do with their arguments. Given the same arguments, they will do different things. To make it concrete by analogy, how would you interpret this spec (or short of that, how does it feel to read and try to understand)? === Definitions: Chairs are made of wood. Generalized Chairs are made of wood, metal or plastic. The VARNISH function accepts a chair. The PAINT function accepts a generalized chair. VARNISH must coat its input with transparent, Acme brand varnish. PAINT must coat its input with liquid. When either method is invoked, the implementation must perform Algorithm Coat. Algorithm Coat: 1) If the input is a wooden chair, coat it with varnish. 2) Otherwise, if the input is a generalized chair, coat it with paint whose color matches the chair's referential color context. === Here are the stumbling blocks: - If you try to simulate the algorithm, it's a head-scratcher. Aren't wooden chairs also generalized chairs? How do we get to step 2 to paint a wooden chair? Are we really supposed to varnish or paint based on whether the chair is known-to-be-wood or merely incidentally-wood, or is painting wooden chairs not possible? - Presumably, painting was invented to support new chair materials and achieve color-coordinated finishes, yet there is barely a functional description of what PAINT does, let alone the intent. PAINT must coat its input with liquid is the closest thing we have to a definition. - We're describing these two functions along three axes, but the information is so spread out that it is hard to integrate. The ideal in clarity, which admittedly is not always possible with the need to specify algorithms and share them between sections, is something like: === The VARNISH function accepts a chair and coats it with transparent, Acme brand varnish. The PAINT function accepts a generalized chair and coats it with paint whose color matches the chair's referential color context. === That's a breath of fresh air. However, there are many other options, like: === The VARNISH function accepts a chair as its argument. The PAINT
Re: Sandbox
Apps (native/web) need direct access to bare metal. Browser vendors need to move away from the we do all the thinking and designing and implementing top-down model of innovation. Browser vendors need to provide minimal core OS APIs and get out of the way and let open source grow around and do the rest. For too long now the typical response to this kind of proposal has been how do you propose solving the security problems? That is to say, we should not do any of this unless we can perfectly solve the security problems. As if they can be perfectly solved. And so our most perfect solution has been to completely cripple web apps: No TCP. No UDP. No POSIX. No Hardware. Tim Berners-Lee raised this point first awhile back on Public Web Apps: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html As a user, I want to write a web app. I trust it. I want to give it UDP, TCP and POSIX anointing. I want it to use the resources of my machine to act on my behalf and assist me in my work. The browser won't let me. Why?
Re: Sandbox
On 17 Sep 2012, at 2:33 PM, Florian Bösch pya...@gmail.com wrote: Security is a pretty serious concern if you're distributing apps without any oversight to billions of users automatically upon a single link click. You are conflating web apps (trusted, installed) with web pages (single link click). No TCP. Wrong, see websockets which upgrade to plain old TCP after the handshake. No, WebSockets are not plain old TCP. No UDP. Coming with WebRTC in the form of unreliable data channels. WebRTC is above UDP. It's not UDP. WebRTC is a massive conglomeration of protocols and codecs and opinions. No POSIX. Why would you need cross-OS posix standards and operating system shells when you already have a browser which abstracts cross-OS APIs in its own fashion? How do you fsync in a browser? Tim Berners-Lee raised this point first awhile back on Public Web Apps: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html I believe his point was subtly different. He was arguing for vendors to come up with ways to solve the usecases he mentioned, not arguing to just blast the OS at the JS developer and let the ensuing security armageddon sort itself out. No, not at all. Nowhere did he ask for browser vendors to solve the use cases he mentioned.
List etiquette Re: Sandbox
Hi folks, this discussion is interesting. But it is not relevant to this mailing list, which is for working on specific APIs and other specifications. If you would like to propose a specific work item, or offer some use cases, requirements, tests or text for one that is either proposed or is in development, you're in the right place. General discussions of the form the web rocks/sucks because... such as this one are more likely to be relevant to www-talk or your favourite social network. (As a generic reminder, technical discussions on topics that have been decided to be out of scope are equally off-topic) cheers Chaals (co-chair) On Mon, 17 Sep 2012 15:06:09 +0200, Joran Greef jo...@ronomon.com wrote: On 17 Sep 2012, at 2:33 PM, Florian Bösch pya...@gmail.com wrote: Security is a pretty serious concern if you're distributing apps without any oversight to billions of users automatically upon a single link click. You are conflating web apps (trusted, installed) with web pages (single link click). No TCP. Wrong, see websockets which upgrade to plain old TCP after the handshake. No, WebSockets are not plain old TCP. No UDP. Coming with WebRTC in the form of unreliable data channels. WebRTC is above UDP. It's not UDP. WebRTC is a massive conglomeration of protocols and codecs and opinions. No POSIX. Why would you need cross-OS posix standards and operating system shells when you already have a browser which abstracts cross-OS APIs in its own fashion? How do you fsync in a browser? Tim Berners-Lee raised this point first awhile back on Public Web Apps: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html I believe his point was subtly different. He was arguing for vendors to come up with ways to solve the usecases he mentioned, not arguing to just blast the OS at the JS developer and let the ensuing security armageddon sort itself out. No, not at all. Nowhere did he ask for browser vendors to solve the use cases he mentioned. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Sandbox
On Mon, Sep 17, 2012 at 3:06 PM, Joran Greef jo...@ronomon.com wrote: You are conflating web apps (trusted, installed) with web pages (single link click). You should clarify that when you say web-apps you mean the other kind. No, WebSockets are not plain old TCP. After handshake the pipe isn't handling any http anymore. It's just plain old TCP sending bytes in both directions, and you select by catching websocket events. You aren't even restricted to same-domain policies with websockets, only thing, you need a websocket ready listener on the other end, not just any open connection, so the handshake can proceed. WebRTC is above UDP. It's not UDP. WebRTC is a massive conglomeration of protocols and codecs and opinions. Well you can be happy or unhappy with WebRTC, but WebRTC unreliable data channels *are* UDP. Instead of recvFrom you listen to channel events, but that's it. If you're not happy with WebRTC for UDP, go on and propose another standard that does it how you like it. How do you fsync in a browser? You mean you're not happy with the current state of browser supported file-systems. Fair enough, propose a better standard for that.
Re: CfC: publish FPWD of DOM Parsing and Serialization; deadline Sept 11
On Sun, 16 Sep 2012 21:57:00 +0200, Ms2ger ms2...@gmail.com wrote: On 09/04/2012 07:06 PM, Arthur Barstow wrote: This is a Call for Consensus to publish a First Public Working Draft of the DOM Parsing and Serialization spec using the following ED as the basis http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html. Sorry I missed the deadline; I lost track of this CfC. Given the standing W3C policy against forking specifications, I object to publishing this fork. Ms2ger Hi Ms2ger, the chairs and team have discussed your objection. It is procedural, not technical. The W3C Process and license have been available to the general public and working group since before the work was taken on under the existing process. We have therefore decided to publish, according to the public expectations agreed on as the Working Group charter. Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish FPWD of DOM Parsing and Serialization; deadline Sept 11
Hi Chaals, On 09/17/2012 04:47 PM, Charles McCathie Nevile wrote: On Sun, 16 Sep 2012 21:57:00 +0200, Ms2ger ms2...@gmail.com wrote: On 09/04/2012 07:06 PM, Arthur Barstow wrote: This is a Call for Consensus to publish a First Public Working Draft of the DOM Parsing and Serialization spec using the following ED as the basis http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html. Sorry I missed the deadline; I lost track of this CfC. Given the standing W3C policy against forking specifications, I object to publishing this fork. Ms2ger Hi Ms2ger, the chairs and team have discussed your objection. It is procedural, not technical. The W3C Process and license have been available to the general public and working group since before the work was taken on under the existing process. We have therefore decided to publish, according to the public expectations agreed on as the Working Group charter. Thank you for acknowledging the hypocrisy of this decision. Ms2ger
[Web-storage] subdomains / cooperation and limits
I have searched the archives and been unable to resolve this to a great answer and I just want to make sure that my understanding is correct lest I have to unwind things later as someone has recently made me second guess what I thought was a logical understanding of things. Essentially, x.wordpress.com and y.wordpress.com both allocate and use space - no problem, right? Access is subject to the browsers -general- sop, (leaving aside the ability to document.domain up one), right? If I have two affliate sites who communicate across an explicit trust via postMessage - is this problematic? I thought not, and it doesn't seem to be - further - I cannot imagine how it could work otherwise and still be useful for a host of common cases (like the wordpress one I mentioned above). I have been told that the draft contradicts my understanding, but I don't think so. Thought that some manufactures/maybe Hixie could set me straight...? Brian
