Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.comwrote: On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. We editors agreed with requesting a CfC to publish [2] as a WD. I'll request it as soon as I'm ready with a WD-ready version. Thanks, Jungkee -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html -- Jungkee Song
CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
Hi Art, I'm wondering if we can change the group's work mode to not requiring CFCs for ordinary working drafts? Unless I'm not getting something, they seem to add an unnecessary delay to getting stuff published. Kind regards, Marcos -- Marcos Caceres On Monday, January 27, 2014 at 3:37 PM, Jungkee Song wrote: On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.com (mailto:art.bars...@nokia.com) wrote: On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. We editors agreed with requesting a CfC to publish [2] as a WD. I'll request it as soon as I'm ready with a WD-ready version. Thanks, Jungkee -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html -- Jungkee Song
RE: CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
This sounds great. It would be cool if editors ping the relevant list as working drafts get updated, just so everyone can use the lists as an ambient feed of what's going on. But an actual CFC process seems unnecessary. From: Jonas Sicking jo...@sicking.cc Sent: Monday, January 27, 2014 12:18 To: Marcos Caceres Cc: public-webapps; Arthur Barstow Subject: Re: CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review For specs that are passed FPWD, and thus where consensus to publish there has been reached, this sounds like a good idea. Though it might also be good to enable anyone to raise concerns about a spec such that automatic WDs aren't published until concensus is reached again. / Jonas On Jan 27, 2014 7:49 AM, Marcos Caceres w...@marcosc.commailto:w...@marcosc.com wrote: Hi Art, I'm wondering if we can change the group's work mode to not requiring CFCs for ordinary working drafts? Unless I'm not getting something, they seem to add an unnecessary delay to getting stuff published. Kind regards, Marcos -- Marcos Caceres On Monday, January 27, 2014 at 3:37 PM, Jungkee Song wrote: On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.commailto:art.bars...@nokia.com (mailto:art.bars...@nokia.commailto:art.bars...@nokia.com) wrote: On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. We editors agreed with requesting a CfC to publish [2] as a WD. I'll request it as soon as I'm ready with a WD-ready version. Thanks, Jungkee -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html -- Jungkee Song
Re: CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
For specs that are passed FPWD, and thus where consensus to publish there has been reached, this sounds like a good idea. Though it might also be good to enable anyone to raise concerns about a spec such that automatic WDs aren't published until concensus is reached again. / Jonas On Jan 27, 2014 7:49 AM, Marcos Caceres w...@marcosc.com wrote: Hi Art, I'm wondering if we can change the group's work mode to not requiring CFCs for ordinary working drafts? Unless I'm not getting something, they seem to add an unnecessary delay to getting stuff published. Kind regards, Marcos -- Marcos Caceres On Monday, January 27, 2014 at 3:37 PM, Jungkee Song wrote: On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.com(mailto: art.bars...@nokia.com) wrote: On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. We editors agreed with requesting a CfC to publish [2] as a WD. I'll request it as soon as I'm ready with a WD-ready version. Thanks, Jungkee -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html -- Jungkee Song
Re: CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
On Mon, 27 Jan 2014 16:48:18 +0100, Marcos Caceres w...@marcosc.com wrote: Hi Art, I'm wondering if we can change the group's work mode to not requiring CFCs for ordinary working drafts? Unless I'm not getting something, they seem to add an unnecessary delay to getting stuff published. Yes, I strongly support that proposal. There is no process requirement that there be a formal Call for Consensus for heartbeat drafts, and no barrier to a group adopting a general process of simply publishing them whenever the editors are ready. cheers Chaals Kind regards, Marcos -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Do we need a rendering spec?
On Fri, Jan 24, 2014 at 5:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov dglaz...@google.com wrote: As HTML imports [1] are implemented across browsers, there’s a potential for diversity of opinion in how rendering of documents with imports occurs. What blocks rendering? What doesn’t? To prevent the inevitable pain of converging on a de-facto standard behavior, it would be super-nice to have precise documentation of when the rendering engine should start (and stop) rendering the document. I don't think we want to expose when rendering / painting / style resolution happens to the Web just like we don't want to expose GC timing to the Web. e.g. it makes the UAs much more vulnerable against the timing attacks. If the HTML imports specification exposes such timing, then we should fix that so that we expose such timing. But before jumping to conclusions, could you clarify how exactly HTML imports creates a dependency on the rendering timing? There was a long thread around this subject in November: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/thread.html#msg476, which culminated in realization that developers ultimately want control over rendering: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0607.html The whole thread is worth the read, though. :DG
Re: [manifest] orientation member
On Mon, Jan 13, 2014 at 1:44 AM, Marcos Caceres w...@marcosc.com wrote: On Wednesday, December 4, 2013 at 5:26 AM, Jonas Sicking wrote: 3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri mou...@lamouri.fr (mailto:mou...@lamouri.fr) wrote: On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote: My impression has been that the vast majority of apps only need a single orientation that is independent of media-query results. If that's the case, then I think the above is too complicated. I.e. if that is the common case, then we should support: orientation: [landscape], or maybe even orientation: landscape, I definitely agree with that. Though, we should allow both syntaxes (array and string). If we want a more complex system later, we could move to that. For the moment, I think we should keep it simple. Also, when comparing how applications handle landscape/portrait, it is worth considering how common/easy it is to write responsive UI on the platform. iOS has a very limited number of device sizes so I am not really surprised that iOS applications try to optimize for some sizes (thus arbitrary ignore some others). Is that common on Android? Would that be common using Web applications? I too am curious what the use cases are for switching orientation based on screen size is. If your app runs fine in both orientations, then why lock the orientation at all? Yes, of course when one presents it like that (if it works on both, why lock it?) it seems to makes sense: but it’s overly simplistic: It’s only in the opposite case (on smaller devices/phones, single locked orientation makes more sense)… i.e., this is a “mobile first” design issue - where even though it “works” in landscape, the experience is so sub-optimal for some application types that it’s not worth optimizing/designing for. However, the Web case may be unique, in that installed applications are bookmarked from browsers, which generally support portrait and landscape on phones and anything bigger. You can see that the landscape experience is sub-optimal if you just play around with apps on your mobile phone that are not games. With the exceptions of a few apps (e.g., calculator on iPhone, which turns into a scientific calculator when rotated; and the Stocks app - which shows a graph view when rotated to landscape), I’m confident that you will see that even the ones that support rotation are not particularly useful in landscape mode (i.e., are more natural to use in portrait - particularly web applications). Games are always the exception, as they really do require landscape to support for continuos interaction (i.e., because the user’s fingers are on the screen so would block too much of the viewport). Also, on phones, starting applications is generally done in portrait mode (at least on iPhone, Android, and FxOS) - so most apps are expecting to be launched and primarily used in portrait. But that’s not the case on tablets (particularly for applications that are both created for both phones and tablets) - where it’s natural to hold the device in any orientation. This leads to the problem: 1. an application may work best as portrait on a phone, but has to work on any orientation on tablet. Forcing a single orientation would only be useful for games - all other application types would need to support any (forcing developers to have to design for landscape on small devices when they don’t have to in their native counterparts - or worst, they have to display a “rotate your phone portrait” message to users, as some apps already do - e.g., forecast.io displays advertising for a future product when rotated to landscape). 2. Forcing an application on a table into portrait leads to a bad user experience (because a percentage of users will be unnecessarily forced to rotate their device to portrait). So I don’t imagine anyone will use this, unless they are using UA/device sniffing, which would show that the solution is broken. Ok, makes sense. So my counter questions are: 1. Could we get away without using generic media queries and instead only allow switching on screen size height and/or width? 2. Could we get away with just using static orientations in v1? I.e. punt using different orientations for mobile/tablet until v2 of the manifest? / Jonas
[Bug 23147] Describe File API Model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147 Arun a...@mozilla.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Arun a...@mozilla.com --- (This bug hasn't really been fixed IMHO). -- You are receiving this mail because: You are on the CC list for the bug.
Re: Do we need a rendering spec?
On Jan 27, 2014, at 1:05 PM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Jan 24, 2014 at 5:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 23, 2014, at 2:45 PM, Dimitri Glazkov dglaz...@google.com wrote: As HTML imports [1] are implemented across browsers, there’s a potential for diversity of opinion in how rendering of documents with imports occurs. What blocks rendering? What doesn’t? To prevent the inevitable pain of converging on a de-facto standard behavior, it would be super-nice to have precise documentation of when the rendering engine should start (and stop) rendering the document. I don't think we want to expose when rendering / painting / style resolution happens to the Web just like we don't want to expose GC timing to the Web. e.g. it makes the UAs much more vulnerable against the timing attacks. If the HTML imports specification exposes such timing, then we should fix that so that we expose such timing. But before jumping to conclusions, could you clarify how exactly HTML imports creates a dependency on the rendering timing? There was a long thread around this subject in November: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/thread.html#msg476, which culminated in realization that developers ultimately want control over rendering: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0607.html Thanks. On the surface, guaranteeing that certain elements, e.g. pending stylesheets, will block the painting seems valuable, but I don’t see howe can spec. that. For example, WebKit waits for the pending stylesheets but it can timeout at some point and paint the contents anyways. In general, UAs use various heuristics to determine when a page is ready to be shown to the user, and I don’t think we want to necessarily spec that. We also need to be extremely careful not to preclude future optimizations and improvement such as doing layout and painting in parallel and reducing FOUC as this area has historically allowed UAs to innovate. - R. Niwa
[xhr-1] XMLHttpRequest Level 1 WD update
Thanks for all the comments. I've updated the WD of XMLHttpRequest Level 1 as such: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/TR/Overview.html This version (Level 1) reflects all the up-to-date features in WHATWG version except: - The URLSearchParams type in send() method. - The additional methods other than append() defined in the interface FormData. (** Note: This version is not planned to be revised in the language of the WHATWG Fetch spec.) If you have any concerns about this draft, please leave your comments. Here's the reference urls to the relevant testing activities: Test suite: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/ Test result: http://jungkees.github.io/XMLHttpRequest-test/ For the co-editors, On Jan 28, 2014 2:31 AM, Domenic Denicola dome...@domenicdenicola.com wrote: This sounds great. It would be cool if editors ping the relevant list as working drafts get updated, just so everyone can use the lists as an ambient feed of what's going on. But an actual CFC process seems unnecessary. -- *From:* Jonas Sicking jo...@sicking.cc *Sent:* Monday, January 27, 2014 12:18 *To:* Marcos Caceres *Cc:* public-webapps; Arthur Barstow *Subject:* Re: CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review For specs that are passed FPWD, and thus where consensus to publish there has been reached, this sounds like a good idea. Though it might also be good to enable anyone to raise concerns about a spec such that automatic WDs aren't published until concensus is reached again. / Jonas On Jan 27, 2014 7:49 AM, Marcos Caceres w...@marcosc.com wrote: Hi Art, I'm wondering if we can change the group's work mode to not requiring CFCs for ordinary working drafts? Unless I'm not getting something, they seem to add an unnecessary delay to getting stuff published. Kind regards, Marcos -- Marcos Caceres On Monday, January 27, 2014 at 3:37 PM, Jungkee Song wrote: On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.com(mailto: art.bars...@nokia.com) wrote: On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. We editors agreed with requesting a CfC to publish [2] as a WD. I'll request it as soon as I'm ready with a WD-ready version. Thanks, Jungkee -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html -- Jungkee Song
[Bug 23719] Consider adding pull style flow control method to Stream
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23719 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Takeshi Yoshino tyosh...@google.com --- It's in ED now. Named awaitSpaceAvailable(). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23975] [Streams API] Remove read as Blob support
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23975 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Takeshi Yoshino tyosh...@google.com --- Done in ED. Stream will replace most of roles of Blob and most of APIs accept ArrayBuffer. It should be fine not having read as blob functionality. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23977] [Streams API] Generic object stream
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23977 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Takeshi Yoshino tyosh...@google.com --- Done in ED. Now ByteStream classes have been renamed back to Stream. Binary handling features are being redesigned not to interfere generic Stream too much. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24421] New: [Shadow]: Clarify that Shadow DOM spec takes care of nodes which are *inDocument*.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24421 Bug ID: 24421 Summary: [Shadow]: Clarify that Shadow DOM spec takes care of nodes which are *inDocument*. Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: hay...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 It might be better to imply that *disconnected* nodes are out of this spec's scope. -- You are receiving this mail because: You are on the CC list for the bug.
