Re: April face-to-face meetings for HTML and WebApps
Or the other way around. In any case, I was only making a point against systematic avoidance of major religious holidays, in favor of a more case-by-case basis. On Thu, Feb 9, 2012 at 6:38 AM, Marcos Caceres w...@marcosc.com wrote: On Thursday, February 9, 2012 at 4:18 AM, Andres Riofrio wrote: Regarding the checklist: perhaps these things are only relevant if there are Christian/Jewish/Muslim people in the group. And if there are people that prefer not to meet on Saturday. It seems to me more reasonable to expect people with prior commitments, that plan to attend, to speak up, and expect the rest to understand and try to come to a consensus. That's why people ask for objections anyway. Right, sometimes one might have to make sacrifices and forgo a Saturday or observing some religious thingy out of respect for the sectarian nature of the W3C membership (and for the advancement of our beloved and sacred Web). Kind regards, Marcos
Re: April face-to-face meetings for HTML and WebApps
Regarding the checklist: perhaps these things are only relevant if there are Christian/Jewish/Muslim people in the group. And if there are people that prefer not to meet on Saturday. It seems to me more reasonable to expect people with prior commitments, that plan to attend, to speak up, and expect the rest to understand and try to come to a consensus. That's why people ask for objections anyway. Andres Riofrio riofr...@gmail.com On Wed, Feb 8, 2012 at 3:11 AM, timeless timel...@gmail.com wrote: It's Passover [1]. Passover begins in the evening of Friday, April 6, 2012, and ends in the evening of Saturday, April 14, 2012. As it happens, your calendar hits the *end* of Passover which is just as major of a holiday as the beginning (the middle is somewhat minor). At the risk of being seen as supporting an information source [2]. The last silicon valley item was an offline webapps thing on a Saturday. That wasn't well considered and I have yet to see minutes from it. But seriously: Please NO. While I love my friends in the bay area and wouldn't mind visiting them for the holiday, it'd pretty much suck. Dear chairs, could you please create a basic meeting scheduling check-list: 1. Does it hit a Christian holiday? (I'm not sure what these are, perhaps Good Friday?) 2. Does it hit a Jewish holiday? (google or wikipedia, or timeanddate [3]) 3. Does it hit a Muslim holiday? (Ramadan) 4. Is it a Saturday? Bad (see 2) To help you out on that last one: Ramadan begins in the evening of Friday, July 20, 2012, and ends in the evening of Monday, August 20, 2012. Thank you for asking in advance so that we can *not* do it at this time. [1] http://www.google.com/search?client=ms-rimhl=enq=passover%202012ie=UTF-8oe=UTF-8channel=browser [2] http://mobile.askmoses.com/article/207,195848/What-is-Chol-Hamoed.html [3] http://www.timeanddate.com/holidays/us/ On 2/6/12, Philippe Le Hegaret p...@w3.org wrote: Folks, in order to facilitate the work of the WebApps and HTML Working Groups, I've been discussing with the Chairs the idea of having a face-to-face in the silicon valley in April. Due to various constraints (WWW2012 and Google I/O most notably), I ended up with the second week of April: - WebApps WG: April 10/11 (Tuesday/Wednesday) - HTML WG: April 12/13 (Thursday/Friday) - WebAppSec: April 11/12 (Wednesday/Thursday) Is anybody else aware of other potential conflicts? The WebKit contributor meeting dates are not set yet but may overlap with webapps for one day (April 10)... I asked the Chairs to ask for objections to those dates as well, Note that this meeting would be in addition to the TPAC 2012 in November (Lyon, France). Thank you, Philippe -- Sent from my mobile device
Re: Obsolescence notices on old specifications, again
I like Glenn's idea of being verbose to avoid ambiguity. It is a spec---might as well spell out the consequences of the notice. :) Andres Riofrio riofr...@gmail.com 2012/1/24 Glenn Adams gl...@skynav.com 2012/1/24 Ojan Vafai o...@chromium.org Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 That doesn't really work for me. What would work for me is something like: Although DOM Level 2 continues to be subject to Errata Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, it is no longer being actively maintained. Content authors and implementers are encouraged to consider the use of newer formulations of the Document Object Model, including DOM4 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance .
Re: [XHR2] PATCH Method support
Correct me if I'm wrong. Changing the XHR2 spec to include other methods in that aforementioned list has the potential to break applications that use method names that are not all-uppercase. Is this right? Andres Riofrio riofr...@gmail.com On Wed, Aug 17, 2011 at 2:58 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 17 Aug 2011 11:48:19 +0200, Dominik Tomaszuk ddo...@wp.pl wrote: In Section 4.6.1 is: If method is a case-insensitive match for CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE, or TRACK subtract 0x20 from each byte in the range 0x61 (ASCII a) to 0x7A (ASCII z). IMO it would be better if it contained the PATCH method. HTTP methods are case-sensitive. These are case-insensitive for this API for legacy reasons. We are not going to add new methods here for each new method defined. (That also has the potential to break applications that use e.g. patch or Patch.) -- Anne van Kesteren http://annevankesteren.nl/
Battery Status API vs. Geolocation API
Hello, I have some comments on the Battery Status API. I was wondering why it was that the battery status API is exposed using Events (and adding an additional requirement When an event listener is registered with the event type batterystatus, then the User Agent must dispatch a BatteryStatusEvent event immediately.), when the Geolocation API is exposed using a getCurrent and a watch function, that invoke a callback when the information is available. Is there a rationale for using a different paradigm than the (kind of) established Geolocation API? I think it'd be better (saner for developers) to use the same paradigm. Further, doesn't the requirement that a BatteryStatusEvent be dispatched immediately incur a synchronous delay as the browser gets that information? That is, nothing else can happen because the event must be dispatched immediately. I might understand wrongly, but if this is the case, I think it should be changed to retrieves the relevant information and dispatches a BatteryStatusEvent asynchronously. Andres Riofrio
