Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/20/2012 10:36 AM, Ryosuke Niwa wrote:
On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
Ojan points out
that simply using end-of-task could expose low-level implementation
detail of the parser to script (such as how much parsing is done in a
single task
before the parser yields).
Does Firefox do anything special here? Or does it simply use the same
end-of-task delivery as everywhere else?
end-of-microtask or end-of-task everywhere. And yes, some parsing /
networking details may unfortunately be exposed, but in a way which should be
quite random. Web devs just can't really rely on network packages to be
delivered to parser in some exact way.
That randomness seems undesirable. Can we delay the delivery until
DOMContentLoaded is fired so that we can have more consisnte behavior here?
Well, the randomness is about the same randomness which is exposed to web pages
already.
img src=http://www.example.org/nonexisting.png;
onerror=console.log('img')
scriptconsole.log('script')/script
the order of 'img' and 'script' in the console is random.
-Olli
- Ryosuke
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On Tue, Jun 19, 2012 at 10:36 PM, fantasai fantasai.li...@inkedblade.net wrote: Hm, so if I scroll with a fullscreened dialog, the dialog scrolls out of view, but if I scroll with a fullscreened img, the image stays in view? If dialog itself was fullscreened it would be fixed I think. If it was a descendant it would not. I'm not completely familiar with the details and I'm sure they'll change as we learn more about the feature. If it's not maintained it's dead and unreliable anyway... How unreliable it is depends on how stable it became before it was abandoned. Which is a function of whether it was implemented properly so I think we should be okay. In any event, 'center' is no longer mentioned. Why? It has no children. Sure, that's fine. Might make it explicit, but really the issue is what element does the ::backdrop element inherit from? Clarified. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On Tue, Jun 19, 2012 at 10:48 PM, fantasai fantasai.li...@inkedblade.net wrote: You could just work in the explanation I sent in http://www.w3.org/mid/4fc64100.3060...@inkedblade.net Added a note. The reason this is not very elaborated is that this really belongs in a CSS specification that defines the layout box model and painting order etc. in detail. As part of that you would have the top layer concept and ways to hook into it via pseudo-elements, such as ::backdrop. And some non-normative description around it to aid people new to the material. Having this in Fullscreen is just patching holes in the CSS 2.1 specification, which is not a great way to do things. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
[Shadow DOM] Shadown DOM and Regions CSSOM
Hello, This is a cross-post from the www-style discussion list in case anyone is interested about this subject: Currently the CSS Regions spec doesn't mention what happens with regions that are part of a shadow tree. The NamedFlow interface exposes the getRegions API that returns the sequence of regions in the region chain associated with the named flow. I suppose the CSSOM needs to be adapted to take into account the shadow boundaries. One way to do it is to add NamedFlow accessor APIs to the shadow root object, similar to what's available on the Document. The NamedFlow objects returned using the new API will provide access to the regions found in the shadow tree. The NamedFlow objects returned from the host document give access only to the regions above the shadow boundary. Thoughts? Andrei.
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On Wed, Jun 20, 2012 at 12:05 AM, Sylvain Galineau sylva...@microsoft.com wrote: I don't think people who don't live in WHATWG/W3C mailing lists and/or make browsers for a living can read a document like this one - or, say, CORS - and hope to figure out what problems they are/aren't trying to solve. (I'm not sure they're even that obvious for people who do) I don't really see how this is a helpful contribution. I fully realize everything is not as good as it can be (and you know I do), but we have limited resources and many problems worth solving. If you know someone that can do a better job on CORS or Fullscreen please by all means have them do it. I put my time into documenting the platform in a detail I hope is sufficient for implementors to reach interoperable implementations which helps reducing site compatibility issues and developer frustration. I certainly compromise on non-normative material, because there are so many parts not documented well. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 11:06, Lachlan Hunt wrote: Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces I have now updated the testsuite to reflect this change. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Wed, 20 Jun 2012 16:26:14 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Yeah, if that works, it's fine. Back then we were in a position where people cared enough to object, so we chose a different way of making most of the people unhappy that drew less objection... cheers Chaals (You think this is bad, people bikeshed how I should write *my*name* ...) -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 6/21/12 5:16 AM, ext Anne van Kesteren wrote: On Tue, Jun 19, 2012 at 10:48 PM, fantasai fantasai.li...@inkedblade.net wrote: You could just work in the explanation I sent in http://www.w3.org/mid/4fc64100.3060...@inkedblade.net Added a note. The reason this is not very elaborated is that this really belongs in a CSS specification that defines the layout box model and painting order etc. in detail. As part of that you would have the top layer concept and ways to hook into it via pseudo-elements, such as ::backdrop. And some non-normative description around it to aid people new to the material. Having this in Fullscreen is just patching holes in the CSS 2.1 specification, which is not a great way to do things. Daniel, Fantasai - please confirm whether or not Anne's latest changes ([1],[2]) address the #2 issue ([3]) that is blocking FPWD: https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#::backdrop-pseudo-element -Thanks, AB [1] https://dvcs.w3.org/hg/fullscreen/rev/41052063ef66 [2] https://dvcs.w3.org/hg/fullscreen/rev/23f36a1db497 [3] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1252.html
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 21/06/12 13:18, Arthur Barstow a écrit : Daniel, Fantasai - please confirm whether or not Anne's latest changes ([1],[2]) address the #2 issue ([3]) that is blocking FPWD: https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#::backdrop-pseudo-element Fine by me. Thanks. /Daniel
Re: Tags and origins (was: Re: Web Notifications)
On Wed, 20 Jun 2012 15:07:27 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 20, 2012 at 3:03 PM, Charles McCathieNevile cha...@opera.com wrote: In the default case yes. Can you use something to change that (a la from-origin)? I don't really see how. Do you have an example where it makes sense? Probably by adding something like analgous to CORS as an attribute. Seems like a feature creep that should be directed to some future version. cheers Chaal -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 17:46, Marat Tanalin | tanalin.com wrote:
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span)// span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation
that matching elements need to be descendants of the context
object. There is nothing obvious that makes h1.querySelector('+ H2')
impossible to work in newer implementations (in older ones it would
not work anyway -- to the same extent as `elm.querySelector(span)`
that you've declared as could work).
Supporting this without the risk of breaking compatibility would require
switching selection behaviour based on the presence of the :scope pseudo
class (either explicit or implied), for each individual selector in the
group. When :scope is present, then matching could be applied to the
entire tree, just like it is in element.find().
That is, given the group of selectors:
elm.querySelectorAll(:scope+p, div p)
(Note: After pre-processing, there is no difference between explicit
:scope and implied :scope in +p)
Only :scope+p would be permitted to match non-descendant elements and
the other div p would have to retain the backwards compatible
selection behaviour where the subject of the selector must be a
descendant of the context object.
That means, the implementation would need to split the group of
selectors such that :scope+p (or any other selector with explicit or
implied :scope) is potentially compared with all elements in the tree.
Then the other selector div p should only be compared with descendants
of the context object.
It will also not work for the reference combinator in some cases. If
switching selection behaviour depends on the presence of :scope, then
the reference combinator will not always work effectively.
elm.querySelectorAll(label /for/ input)
In this case with no :scope, the matching input must be a descendant of
the context object, but the label may or may not be. Compare that with
this:
elm.findAll(label /for/ input)
In this case, :scope is implied at the beginning, so the label must be a
descendant of the context object, but the matching input elements may
appear anywhere in the tree.
Overall, this adds significant complexity to the implementations, so
while it may actually be technically possible in some cases, it's far
from ideal and doesn't address all problems.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. or Despite 70% of the Web developers are in favor of name X, compatibility research shows that or even Despite 70% of the Web developers are in favor of name X, 100% of browser developers are not and therefore ... or even Nobody ran either a public vote and compatibility research and the editor made the decision on X because he likes it. (Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public, but at least this is easier to understand than design by committee or design by editor, which is just well, difficult to understand to a causal person who cares about the standard but doesn't have the bandwidth to go in.) In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (will try to bring real feedback next time.) Cheers, Kenny
[websockets] Seeking comments on moving back to CR; deadline June 28
Hi All, I created a tracking document for the two comments and five bugs that were submitted against the 24 May LCWD of Web Sockets (or in the approximate time frame of that publication): http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-24May2012. Below is my take on these bugs and comments. It would be good to get this spec back to CR and hence closer toward the IP commitments that will only be final when the spec reaches Recommendation. Bugs: * 17073 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073 - marked as an Enhancement; don't include in the v1 CR * 17224 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224 - this looks like an Editorial bug to me as I stated in the bug. Assuming there is consensus the text should be unsolicited pongs, if Hixie can't fix this before the v1 CR copy is created, I'll make this change in the v1 CR. * 17262 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262 - Jonas' view as expressed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262#c13 seems reasonable so I propose closing this with a resolution of WorksForMe. * 17263 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263 - send(ArrayBuffer), which was included in the December 2011 CR, has been implemented and presumably must be supported by some browsers (e.g. bc/legacy reasons). As such, it seems reasonable to fix this bug and perhaps we could argue a new LCWD is not needed since it has already been implemented. * 17264 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 - this bug appears to be a rehash of bug 13104 which was Fixed in October 2011 so I propose closing this with a resolution of Duplicate. Comments: * LC-1 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0807.html - The 28-May-2012 reply by Takeshi Yoshino notes this is a Chrome bug and not a spec bug. The 1-June-2012 reply by Simon Pieters indicates the Protocol spec needs to be updated. As such, I don't think any changes are needed for v1 of the spec. * LC-2 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html - This is an editorial bug and is already captured in Bug 12510. Ideally, this bug would be fixed before the v1 CR branch is created. However, if Hixie can't fix it before then and if no one else creates an acceptable patch for Hixie, I don't support blocking the v1 CR for this. Please send all comments by June 28. -Thanks, AB
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. By editorial decision, I meant that the decision of what to name it should be up to the editor, not that it is a minor editorial issue. Sorry for the confusion. Fixing tests is trivial, but the name should be decided before implementation begins and a testsuite is written anyway. At this stage, I haven't seen any overly strong objections to the names find/findAll anyway, so hopefully this is a non-issue. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: What happened last time was that I carefully reviewed the entire debate, taking into account all arguments for and against every suggested alternative I found at the time and posted a thorough review and rationale for the decision I made at the end. http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0077.html This then resulted in some people in the group complaining loudly enough because they weren't happy, mostly because it's impossible to please everyone, leading to a vote between 6 choices, ultimately overruling me. Anecdotally, I heard from a few web developers at the time saying they even liked the names I'd chosen, despite them being a little long, but were later disappointed with the result of the vote. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public Sure. In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Selectors API Implementation Report
Hi, I have created a basic implementation report covering the baseline tests. All 5 browser implementations are at 99.2% pass rate, each browser only failing 8 of these tests because of the recent change for the NAMESPACE_ERR issue. http://dev.w3.org/2006/webapi/selectors-api-testsuite/001-report.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Web Activities: counter-proposal to Web Intents
Thanks, Mounir. I've been reading the overview, and I have a lot of the same reactions Robin did to issues of scope. Based on what I read in the wiki and in this mail, the scope you have in mind is very similar to where I think we all agree the use cases of web intents predominately lie (edit, pick, share, view). The approaches of the APIs (RPC-style as opposed to mediated through postMessage, for example) are very similar. The mechanisms they use are are also functionally very similar: there's registration, there's invocation, there's delivery, there's response. I see an open action and type namespace, so that web developers are free to take advantage of the functionality to do things that we can't predict currently, and yes, so that other standards can use the functionality as a mechanism, in the same way it uses things like structured clone and eventing. All this makes me believe we have a very similar understanding of this problem and what is entailed in a responsive solution. I am optimistic that we'll figure out the technical details and come to consensus about the right API to expose this functionality to web developers. Moving to specifics of the API, I find a lot to like in this proposal. Invocation by scope closing is unintuitive, but using a Future-style object is appealing. That is, something like this: var futureValue = navigator.startActivity(intent payload); futureValue.onReply = handler; futureValue.onError = handler; In Web Intents, we used callbacks for this mechanism, since it ends up being more compact and also more idiomatic for web APIs. Still, IndexedDB makes good use of the Future style, and so do many popular JS libraries. One might wish the File/Filesystem API had taken a similar approach. The differences in service and intent parameters are mostly cosmetic. One excellent solution I found there to a longstanding problem, which we should adopt, is to include a multiple=true extras parameter to indicate that the client can handle (and therefore, that the service can produce), arrays of values in the return type. For delivery, I think utilizing a novel system message handler is less desirable than other evented mechanisms for delivery. There are a couple such that we should consider, however. When originally proposed, we specifically wanted to rule out multiple delivery to a particular context, which led us to the very simple window.intent mechanism. Our thinking now is that ruling this out is a mistake, and we need to provide a mechanism to deliver the intent payload as an event. I think the most unsurprising way to do this would be a window-based intent event. Another suggestion which Alex Russell made, and I think is really slick, is to deliver to an intent listener on the intent tag itself. This couples registration and handling in a very compelling fashion. For registration, I think Ian Hickson's proposal to consider web intents, registerProtocolHandler, and registerContentHandler, as all part of the same feature is the right direction. I prefer declarative to imperative registration, as I think it apportions responsibilities more cleanly and accurately, but it looks like at the end of the day we'll have both, and for good reasons. On Tue, Jun 12, 2012 at 7:08 AM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, With some people at Mozilla, we've been working on an API similar to Web Intents in some points but distant enough to be a counter-proposal. We believe that the API is now in a good enough shape to be officially sent in those mailing lists and discussed. You can have an overview of the API here:https://wiki.mozilla.org/WebAPI/WebActivities Web Activities' intent is not to be a clone of Google's Web Intents with some naming and API details changed. Web Activities aim to be a simple API trying to solve a very clear set of use cases. It has been a bit hard to judge the desired scope of Web Intents. People have suggested that Intents should be able to solve everything from getting low-level Sensor information [1] to the ability to implement services like Push Notifications [2] to doing discovery and control of DVR hardware from the browser [3]. It is unclear if this is just a list of things people wish that Intents could help with, or if these are hard requirements that the spec authors are using to design the spec for. An API which allows building a wide range of applications is generally a good API, however it is also important to have a concrete set of use cases when designing an API to make sure that it solves those use cases well. Our concern is that Intents are designed to solve the ambigious use case of communicating with anything. As a reminder, the basic use cases of Web Intents seem to be: Users use many different services on the web to handle their day to day tasks, such as sharing images, editing documents and listening to music. They expect their applications to be connected and to work together seamlessly. [4] and the
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/21 23:28), Charles McCathieNevile wrote: On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Well, yes, though I wonder why we can't define best to be what gets the most public votes (just in this case, please don't generalize this to cases when X and Y are having different implementation difficulty). Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Thanks for the information (and to Lachy too). I also found the vote[1] itself quite interesting. [1] http://www.w3.org/2002/09/wbs/38482/selectorsNames/results Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. I claim that numeric data is as honest as we ever can be. Taking a look at Lachy's summary, I have to say while I appreciate the effort spent on this, there are really just contradictory sentences that made me frown, and Lachy later admitted[2]: [[ In hindsight, looking at the arguments above, I probably did let my own personal dislike of the name get in the way of my objectivity in this case, as much as I tried to avoid doing so. As such, I am now willing to consider these alternatives. ]] . Debating these rationale seems to be a waste of time too. I don't see why doing a public poll can be considered dishonest. The honest description would just be We ran a public poll on (pointer goes here) with X people, Y % of them are Web developers (pointer to the statistics goes here). The result ... [2] http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0120 (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. I never like the design by committee term because it seems to suggest a solution (the benevolent dictator) without explaining what's going on. In the querySelector case, although I admit that I think what
RE: CfC: publish FPWD of Fullscreen spec; deadline May 24
[Anne van Kesteren:] I don't really see how this is a helpful contribution. I fully realize everything is not as good as it can be (and you know I do), but we have limited resources and many problems worth solving. If you know someone that can do a better job on CORS or Fullscreen please by all means have them do it. If you saw how it were helpful there would be no need to bring it up, would there? Use-cases are actually discussed at length on mailing lists; in some cases they are even documented on a wiki page. But all this material is often way too hard to find or gather for folks who aren't regular insiders. So what *I* don't see as helpful is the expectation that readers ought to go spelunking through months of mailing lists to figure out what a spec is/is not trying to solve. I'm not suggesting such content should be exhaustive, formal or even normative but there is a huge difference between some of the primary use-cases this spec aims to solve are documented in Appendix X and nothing else to see here, this is for implementation only; if you want to know what this was meant to solve why don't you go search the last n years of archives because, well, we have more important problems to solve than making sure you really get what this is for. From your end I understand how this may sound like overhead since you live in these mailing lists, write specs for a living and primarily care about the small number of implementors whose job also includes following these daily conversations. The result, however, is documents that can be far less useful for everyone else. And, since even implementors can't follow everything, we also make it more likely some could end up using the wrong tool to solve a problem. So that, for instance, you could find yourself spending way more time arguing with the Fonts WG about why they shouldn't use CORS as a same-origin solution than you would have spent clearly documenting the scenarios the spec aims to solve vs. what it's not meant to solve. Mind you, it's not something I would mandate. But I suggest it would be good practice to try this; and that the cost/reward may be positive. I put my time into documenting the platform in a detail I hope is sufficient for implementors to reach interoperable implementations which helps reducing site compatibility issues and developer frustration. I certainly compromise on non-normative material, because there are so many parts not documented well. I'm not suggesting you're the only person who does this or even the worst offender. Most specs these days have this limitation (a few do a decent job using use-cases as examples). Given the growing number of documents and the reach of the platform I think this is something we all need to work on in the future.
Re: [websockets] Seeking comments on moving back to CR; deadline June 28
On 2012-06-21 16:28, Arthur Barstow wrote: ... http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html - This is an editorial bug and is already captured in Bug 12510. Ideally, this bug would be fixed before the v1 CR branch is created. However, if Hixie can't fix it before then and if no one else creates an acceptable patch for Hixie, I don't support blocking the v1 CR for this. ... I disagree that this is editorial. Without proper references the spec simply is incomplete. If you disagree, please walk me through how a reader is supposed to find out what absolute URL or resolve the URL string means. Best regards, Julian
Web Intent work scope
Hi, Is Web Intent expected to work only between web apps on client or any services provided on the client, regardless it is implemented natively or not, could be in the discovery scope of Web Intent? Thanks, Dan
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 06/21/2012 04:18 AM, Arthur Barstow wrote: On 6/21/12 5:16 AM, ext Anne van Kesteren wrote: On Tue, Jun 19, 2012 at 10:48 PM, fantasai fantasai.li...@inkedblade.net wrote: You could just work in the explanation I sent in http://www.w3.org/mid/4fc64100.3060...@inkedblade.net Added a note. The reason this is not very elaborated is that this really belongs in a CSS specification that defines the layout box model and painting order etc. in detail. As part of that you would have the top layer concept and ways to hook into it via pseudo-elements, such as ::backdrop. And some non-normative description around it to aid people new to the material. Having this in Fullscreen is just patching holes in the CSS 2.1 specification, which is not a great way to do things. Daniel, Fantasai - please confirm whether or not Anne's latest changes ([1],[2]) address the #2 issue ([3]) that is blocking FPWD: https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#::backdrop-pseudo-element # ... for an element in the top layer's stack. E.g. for the element that # is displayed fullscreen as described by this specification. This second part is a fragment, not a sentence, so I'd suggest rewording, maybe like this | ... for an element in the top layer's stack (such as a fullscreen element). But otherwise it seems fine to me. ~fantasai
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 06/21/2012 02:11 AM, Anne van Kesteren wrote: Why? It has no children. Sure, that's fine. Might make it explicit, but really the issue is what element does the ::backdrop element inherit from? Clarified. That's an interesting approach, you probably want someone familiar with the style system to check that having an element that is not the root act as if it was the root of the style tree is a reasonable thing to do. Also, to be precise, you're not actually clear about what happens to e.g. 'color', which is an inheritable property. If it doesn't inherit from anything, what is it's value? This is not defined, because currently in CSS every element has a parent except the root, and there is a special exception to inheritance specifically for the root element. ~fantasai
Re: [IME] WebIDL bugs
Greetings Dom, This is just for your information. I have pushed a change that applies your comments: http://dvcs.w3.org/hg/ime-api/rev/420725ab06cd. Regards, Hironori Bono E-mail: hb...@google.com On Tue, Jun 5, 2012 at 6:16 PM, Hironori Bono (坊野 博典) hb...@google.com wrote: Greetings Dom, Thanks for your bug reports and sorry for my slow response. I will update this draft next week to apply them. (Unfortunately, I cannot afford to fix this draft this week.) Regards, Hironori Bono E-mail: hb...@google.com On Mon, Jun 4, 2012 at 4:19 PM, Dominique Hazael-Massieux d...@w3.org wrote: Hi, I spotted a few bugs in the WebIDL fragments of the Input Method Editor API draft [1]that I'm reporting below. I'm happy to bring the required changes directly to the draft if that's preferred. -- interface HTMLElement … Object getInputContext (); }; should be partial interface HTMLElement InputMethodContext getInputContext (); }; (assuming this interface is really to be added to HTMLElement) -- CompositionClauseList is a typedef of a sequence type but is used for an attribute; sequences are not appropriate type of attributes, you would want to use an array instead. -- int is not a valid WebIDL type, you would want to use either short, long or long long -- Composition, CompositionCaret and CompositionClause should probably be dictionaries rather than interfaces. That would also allow to define default values directly in the IDL. -- The methods in InputMethodContext uses the in keyword that is no longer a valid WebIDL keyword. Dom 1. http://www.w3.org/TR/2012/WD-ime-api-20120524/
Re: [Shadow DOM] Shadown DOM and Regions CSSOM
On Thu, Jun 21, 2012 at 6:23 PM, Andrei Bucur abu...@adobe.com wrote: Hello, This is a cross-post from the www-style discussion list in case anyone is interested about this subject: Currently the CSS Regions spec doesn't mention what happens with regions that are part of a shadow tree. The NamedFlow interface exposes the getRegions API that returns the sequence of regions in the region chain associated with the named flow. I suppose the CSSOM needs to be adapted to take into account the shadow boundaries. One way to do it is to add NamedFlow accessor APIs to the shadow root object, similar to what's available on the Document. The NamedFlow objects returned using the new API will provide access to the regions found in the shadow tree. The NamedFlow objects returned from the host document give access only to the regions above the shadow boundary. Thoughts? That makes sense to me. It is in line with the Shadow DOM concept of upper-boundary encapsulation and is analogous to the methods and properties on ShadowRoot, like NodeSelector, that provide access to the encapsulated stuff. Dominic
