Re: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
On 10/5/12 7:06 AM, ext Bryan Sullivan wrote: - more info on serverProtocols It still seems like the set of valid strings will need to be defined. Perhaps at this point, it would be sufficient if a related Issue Block was added. (I'll ask Mike to create a Bugzilla component for the spec.) - additional references (I still need to update the respec biblio) Yes, please do as this must be fixed before the FPWD is actually published in /TR/. (Robin provided some related info in [1].) I would like to request a CFC for FPWD publication, if there are no more substantive comments on the updated version. I will start a CfC for the FPWD. (If you haven't prepared a doc for publication as a TR, please see http://www.w3.org/wiki/Webapps/SpecEditing for some information about the PubRules and such.) -Thanks, AB [1] http://krijnhoetmer.nl/irc-logs/webapps/20121005 * serverProtocols - what are the expectations for the valid set of values; where are they specified? Good question. We need some means of registration of well-known services so the protocols can be recognized.
CfC: publish FPWD of Push API; deadline October 12
The Push API Editors would like to publish a First Public Working Draft of their spec and this is a Call for Consensus to do so, using the following spec as the basis http://dvcs.w3.org/hg/push/raw-file/default/index.html. This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by October 12 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB
Re: CfC: publish LCWD of Pointer Lock; deadline Oct 4
On 9/27/12 8:26 AM, ext Arthur Barstow wrote: This is a Call for Consensus to publish a LCWD of Pointer Lock using the following document as the basis for the LC http://dvcs.w3.org/hg/pointerlock/raw-file/tip/index.html. This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] The proposed LC review period is 4 weeks. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by October 4 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. Hi All - given the discussion in the Is Pointer Lock feature complete i.e. LC ready? thread (see f.ex. [1] and follow-ons), it appears we don't yet have consensus the spec is ready for LCWD. As such, I recommend we work toward consensus on the issues raised in this thread before proceeding with the LCWD. To help people track the issues raised, perhaps it would be helpful to create a related bug [2] (and to add a link to [2] in Status of the Document section). -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html [2] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Pointer%20Lockresolution=---
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Fri, Oct 5, 2012 at 4:22 AM, Henri Sivonen hsivo...@iki.fi wrote: On Tue, Aug 21, 2012 at 9:17 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Similarly, some of the a11y folks have recently been talking about applying aria-* attributes via CSS, again, because it's just so much more convenient. What's the rationale for this radical change of mind? Back when ARIA was introduced, the a11y wanted to specifically avoid the introduction of reflecting DOM properties for the ARIA attributes in order to force authors to use setAttribute() so that JAWS could retrieve the ARIA data via COM in ARIA-unaware legacy IE. If the a11y folks were so serious about being compatible with IE7 a few years ago, why isn't there now similar concern that applying ARIA by a new mechanism would leave behind IE10 and earlier, which, presumably, currently have the same sort of expected enterprise lifespan as IE7 had when aria was introduced? I have no idea. However, it seems irrelevant for my proposal - as currently specified, CAS desugars into setAttribute calls. ~TJ
Re: CfC: publish FPWD of Push API; deadline October 12
Hi All, As usual, this is not the official mozilla position, as there is no such thing. Several of us at at mozilla has been looking at push quite a bit lately. We still don't have a clear idea of exactly what we think a push system should look like. However we are concerned that a system like the one in http://dvcs.w3.org/hg/push/raw-file/default/index.html would be hard to implement at internet scale in a manner which keeps it stable enough to be reliable for webapp developers. First of all the fact that a single message from the application server to the notification server can cause millions of messages from the notification server to end-user devices makes us concerned that it's too easy to DoS the notification server. Second, using a message passing mechanism puts a lot of responsibility on the notification server to never lose any messages. In the event of a server crash or server overload the current solution seems to have no way for the notification server to avoid dataloss. As points of reference, both Apple and Google has been creating similar Push solutions for iOS and Android respectively. Both of these systems have struggled with scalability. The result for Apple was to delay their solution for a year. The result for google was to deprecate the system and they are working on designing something new. The system proposed here is more powerful than both Apple's and Google's system. Finally we also have some security concerns. The messages passed through the current API will likely very often end up being cleartext. Application developers certainly can make sure to always encrypt the messages on the server and then manually decrypt them in the client (using for example the new crypt API). The API already requires passing two cryptographically strong tokens to the API. Requiring developers to also decrypt the message in the client means involving a third cryptographically strong token. This is a lot for developers to get right and if they don't, there's a risk of privacy or even security problems. These are all hard problems to solve, and so far we do not have a counter proposal. But I figured that I should raise these concerns since they seem relevant. I'm also very aware that in the past I have pointed at message-passing based protocols in the past as mozilla experiments. However lately we have started at looking at alternatives due to the scalability issues discussed above. Letting people know about this is another reason I'm writing this email. But since we don't have a counter proposal, and since I personally generally think that people should be allowed to publish working drafts, I don't oppose this FPWD. But I can't say with certainty at this time that this is an API that we're planning on implementing. / Jonas On Fri, Oct 5, 2012 at 4:38 AM, Arthur Barstow art.bars...@nokia.com wrote: The Push API Editors would like to publish a First Public Working Draft of their spec and this is a Call for Consensus to do so, using the following spec as the basis http://dvcs.w3.org/hg/push/raw-file/default/index.html. This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does _not_ necessarily mean there is consensus on the spec's contents. If you have any comments or concerns about this CfC, please reply to this e-mail by October 12 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB
RE: [IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor
On Wednesday, October 3, 2012 6:50 PM, Jonas Sicking wrote: On Wed, Oct 3, 2012 at 9:48 AM, Joshua Bell jsb...@chromium.org wrote: On Wed, Oct 3, 2012 at 1:13 AM, Odin Hørthe Omdal odi...@opera.com wrote: So, at work and with the spec in front of me :-) Odin claimed: There is a note near the algorithm saying something to that point, but the definite text is up in the prose let's explain IDB section IIRC. Nope, this was wrong, it's actually right there in the algorithm: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps -for-iterating-a-cursor # If direction is prevunique, let temp record be the last record in # records which satisfy all of the following requirements: # # If key is defined, the record's key is less than or equal to key. # If position is defined, the record's key is less than position. # If range is defined, the record's key is in range. # # If temp record is defined, let found record be the first record in # records whose key is equal to temp record's key So it'll find the last foo, and then, as the last step, it'll find the top result for foo, giving id 1, not 3. The prevunique is the only algo that uses that temporary record to do its search. I remember this text was somewhat different before, I think someone clarified it at some point. At least it seems much clearer to me now than it did the first time. Since I have it the link handy - discussed/resolved at: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.htm l Israel Hilerio said: Since we're seeing this behavior in both browsers (FF and Canary) we wanted to validate that this is not by design. It would bet several pennies its by design, because the spec needs more framework to explain this than it would've needed otherwise. What that exact design was (rationale et al) I don't know, it was before my time I guess. :-) Yes, the behavior in Chrome is by design to match list consensus. (FWIW, it's extra code to handle this case, and we've had bug reports where we had to point at the spec to explain that we're actually following it, but presumably this is one of those cases where someone will be confused by the results regardless of which approach was taken.) Yes, this was very intentional. The goal was that reverse iteration would always return the same set of rows as forward iteration, just in reverse order. This seemed like the most easily understandable and explainable behavior. Consider for example a UI which renders an address book grouped by first letter and showing the first name in that letter. It would seem strange if the user changing z-a or a-z shows different names. / Jonas Thanks everyone for the explanations. Jonas, your last example clarified things for me. We'll file a bug on our side. Israel
Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
For those with threaded email clients, at Arthur's suggestion I've filed an issue to track this topic. http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0040.html. On Tue, Oct 2, 2012 at 4:50 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote: Speaking from the point of view of a web developer having to use this feature. It is quite painful having to perform an end-run about failure modes that are unspecified, undocumented and a moving target. In my understanding, this is precisely the intent of a specification, to avoid such incompatibilities and headaches for developers. 1) If it is intended that additional failure modes are to be randomly introduced by vendors, then this should be made explicit in the specification. 2) If such wording is added to the specification, I don't see any residual value in the specification since any developer will have to perform the trialerror endrun repeatedly patching things up as the failure modes move, we can just skip the specification altogether. As I read through this thread, I was thinking exactly the same thing that Florian has said here. Looking forward to real feature completion ;) Rick On Wed, Oct 3, 2012 at 12:08 AM, Vincent Scheib sch...@google.com wrote: I agree that pointer lock is quite useful outside of fullscreen, but before attempting to codify that in the specification I would want buy in from other browser vendors. I can appreciate an argument to remain restricted to fullscreen. Application developers can automatically escalate to requesting fullscreen upon the first pointerlockerror given the current behavior of FireFox. It's more code, but not a burdensome amount. If future abuse of the feature appears on the web, there may be other criteria used by browsers to suppress the feature. The specification states The user agent determines if pointer lock state will be entered which allows for browsers to add additional constraints. I could word that more explicitly if it would help. But my intent was specifically to allow browsers to use additional discretion. E.g. see the 'A full screen approach' in the specification's non-normative security section. Also, note that Chrome allows users to enter global suppression of the feature via the content settings preference, a override accepted similarly by the specification. Also, a small nit regarding chrome requires the pointer lock request to fail if not resulting from a user interaction target. Chrome allows pointer lock without any user gesture if requested when in fullscreen. Out of fullscreen a user gesture (click, key press) is required. See http://www.chromium.org/developers/design-documents/mouse-lock On Tue, Oct 2, 2012 at 2:59 PM, Florian Bösch pya...@gmail.com wrote: On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 10/02/2012 11:55 PM, Florian Bösch wrote: I'd like to point out that vendors are using additional failure criteria to determine if pointerlock succeeds that are not outlined in the specification. Firefox uses the fullscreen change event to determine failure and chrome requires the pointer lock request to fail if not resulting from a user interaction target. I think that Firefoxes interpretation is less useful than Chromes, But safer Also not in conformance to the specification (hence a bug). Additionally, it will make it really difficult to follow the specification since non-fullscreen mouse capture is specifically intended by the specification by not adding that failure mode *to* the specification (there's a fairly long discussion on this on the chrome ticket for pointerlock resulting in what Chrome does now). and that Chromes interpretation should be amended to the spec since it seems like a fairly good idea. I'm not yet convinced that it is safe enough. Also, it is not properly defined anywhere. So either Chrome is also implementing in conformance to the specification, or the specification is changed. Ipso facto, the specification is not complete since I don't think Chrome will drop this failure mode, and it seems like Firefox is intending to follow Chromes lead because otherwise it wouldn't be possible to implement non-fullscreen pointerlock.
[Bug 16302] possible unnecessary insertion of U+0020 SPACE in mime type expression
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16302 Michael[tm] Smith m...@w3.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NEEDSINFO --- Comment #9 from Michael[tm] Smith m...@w3.org 2012-10-06 03:55:30 UTC --- Not sure what action if any I need to take on this. Re-assign to one of the W3C XHR editors? -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
