We all need to rejoin… Re: Fwd: Web Applications Working Group Revised Charter Approved; join the Web Applications Working Group (Call for Participation)
On Wed, 13 Aug 2014 18:45:08 +0200, Coralie Mercier cora...@w3.org wrote: Hello public-webapps, FYI, relaying the Call for Participation to the Working Group's primarily public mailing list, to notify the group, including Invited Experts. In particular note that EVERYONE needs to rejoin in order to (still) be part of the group. (If you wonder why, please take the question to public-w3proc...@w3.org - it's the way chartering is done at W3C, and nothing specific to this group). cheers Chaals Best regards, Coralie --- Forwarded message --- From: Coralie Mercier cora...@w3.org To: w3c-ac-fo...@w3.org Subject: Web Applications Working Group Revised Charter Approved; join the Web Applications Working Group (Call for Participation) Date: Wed, 13 Aug 2014 18:39:43 +0200 Dear Advisory Committee representative, Chairs, The Director is pleased to announce the re-charter of the Web Applications Working Group: http://www.w3.org/2014/06/webapps-charter.html The revised charter extends the group through 31 July 2016 to continue working on specifications that enable improved client-side application development on the Web. The charter of this Working Group includes new deliverables that require W3C Patent Policy licensing commitments from all Participants. Consequently, all Participants must join or re-join the group, which involves agreeing to participate under the terms of the revised charter and the W3C Patent Policy. Current Participants may continue to attend meetings (teleconferences and face-to-face meetings) for 45 days after this announcement, even if they have not yet re-joined the group. After 45 days, ongoing participation (including meeting attendance and voting) is only permitted for those who have re-joined the group. Use this form to (re)join: http://www.w3.org/2004/01/pp-impl/42538/join The Working Group chairs are Art Barstow (Nokia) and Charles McCathieNevile (Yandex). The Team Contacts are Yves Lafon and Xiaoqian Wu; together with Team participation from Philippe Le Hégaret, Robin Berjon, Michael Smith, Wei Wu, and Doug Schepers for a total of 0.30 FTE. More information about the Web Applications Working Group can be found at: http://www.w3.org/2008/webapps/ [...] This announcement follows section 8.1.2 of the W3C Process Document: http://www.w3.org/2014/Process-20140801/#ACReviewAfter and the Call for Participation follows section 6.2.4 of the W3C Process Document: http://www.w3.org/2014/Process-20140801/#cfp Thank you, For Tim Berners-Lee, W3C Director, Philippe Le Hégaret, Interaction Domain Lead, and Yves Lafon and Xiaoqian Wu, Team Contacts; Coralie Mercier, W3C Communications -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
usecases Re: [editing] Leading with ContentEditable=Minimal
On Mon, 30 Jun 2014 10:54:36 +0300, Robin Berjon ro...@w3.org wrote: On 30/06/2014 07:22 , Johannes Wilm wrote: Another use case: Create a track changes function within an editor (like https://github.com/NYTimes/ice ) that really should be run MVC in order to keep the code somewhat readable. Currently ICE breaks whenever any of the browser makers decide to change anything about contenteditable. Oh yeah, anything involving tracking, OT, or whatever temporal really, really can't use the markup as its model. I'm surprised ICE went that way, it must be terribly painful. Create an extension that substitutes an editor adapted to the user's needs for a default editing setup in an application. -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: WebIDL Spec Status
On Tue, 24 Jun 2014 16:11:23 +0600, Mounir Lamouri mou...@lamouri.fr wrote: On Tue, 24 Jun 2014, at 10:45, Glenn Adams wrote: On Mon, Jun 23, 2014 at 3:05 PM, Marcos mar...@marcosc.com wrote: Even if we were able to take the V1 bits to Rec (a lot of which is now obsolete), the V2 stuff is already widely supported and heavily relied on by browser vendors. IMO, it's a waste of everyone's time to try to maintain multiple versions. I agree that the V1 CR should be abandoned or replaced with a completed snapshot of V2. Though it would be useful to ask a wider community about the value of moving some flavor of V1 to REC. What's the benefits from having a REC based on v1 even if we know it is already obsolete? People who can happily use the obsolete version, but need something stable, can refer to a well-known version they use, that others can also use. This gives far better, although incomplete, interoperability than if everyone who wants a stable reference more than something they have to invest in watching, and reacting to, continuously, refers to a random update. cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: WebIDL Spec Status
On Mon, 23 Jun 2014 22:05:55 +0100, Marcos mar...@marcosc.com wrote: On June 23, 2014 at 4:07:09 PM, Glenn Adams (gl...@skynav.com) wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? The plan is based on an editor who is provided by Mozilla, but who is very often too busy to work on the spec. We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Given the high degree of dependency from other specs and implementations on this work, we really need to find a way to wrap up this work or at least publish something reasonably stable. That relies on someone to the the Work™. IMO, we should just concede that this document needs to be a Living Standard (tm). IMO (ie chair hat off) that would be a Really Dumb Idea™. While there is no reason to believe it would solve the problem of Heycam's availability, it would assume everyone using the spec the time to watch out for changes, and is somehow in a position to change their implementations or explain the problem in such a way as to convince the group. Given that this requires a commitment on the part of many people that probably exceeds the amount of time the editor himself spends, it seems a very expensive way to try working around a relatively simple problem. This would result in a fragile and probably increasingly fragmented ecosystem, without the minimal measure of interoperability that is gained by common references to known stable versions. Trying to move this through the W3C process is clearly not working. Even if we were able to take the V1 bits to Rec (a lot of which is now obsolete), the V2 stuff is already widely supported and heavily relied on by browser vendors. IMO, it's a waste of everyone's time to try to maintain multiple versions. Everyone is not trying to do so. A couple of people in the whole world are. A lot of everyone would benefit from the periodic publication of stable versions. While nobody is offering an editor who can get the work done, this argument is in any case academic (unless the editor's availability is predicated on the outcome, in which case it would be mere political machinations). just my 2 kopecks -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28
On Wed, 21 May 2014 16:27:36 +0200, Arthur Barstow art.bars...@gmail.com wrote: On 5/21/14 7:02 AM, Anne van Kesteren wrote: Developers seem to complain about us using mailing lists to communicate rather than GitHub or some other centralized platform that is not email. Might be worth checking with them first. Yes, good point Anne. I tweeted this Q with some tags that were intended to extend the reach. If others would also reach out, I would appreciate it. I realize mail lists are a tool and there could be better ones to reach/engage the developer audience. I don't object to creating a list enough to block the consensus, but as well as Anne's point, I wonder if we should be doing this in webapps or if we should be trying to support W3C's more general Dev Rel efforts instead. Which is partly a question to us, about the easiest way for us to provide any helping others capacity, and partly a question about how developers want help to get to them… cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Custom Elements: 'data-' attributes
On Thu, 08 May 2014 19:42:04 +0200, Ian Hickson i...@hixie.ch wrote: On Thu, 8 May 2014, Bruce Lawson wrote: On 7 May 2014 20:03, Ian Hickson i...@hixie.ch wrote: Requiring a dash is pretty ugly. I would allow any attribute, and we'll just have to be careful when introducing new global ones. I think the ship HMS Ugly has already sailed, given a dash is compulsory for the names of custom elements. Also, requiring a dash in the names of custom attributes would establish an easily-memorable convention for authors, and safeguard new global attributes. I disagree. I think the HMS ugly really has been launched - and successfully sailed for years. I agree with Bruce that dashes in attributes are easy for everyone to remember. The question is really how important that is. With element names, you really should be putting a uniquish prefix on your element names to avoid clashes with other custom vocabs. So the dash is just the way we encourage that. Right. google-button yahoo-button ...etc. But the attributes are _already_ scoped, since they're on the element. android-patterngrid width=3 height=3 ...vs android-patterngrid data-width=3 data-height=3 The data- bits don't add anything useful. if they were andr- they might remind authors that this is a width specifically scoped to the element (and measured in unicorns, or somehow different from the normal width). For more obviously custom attributes like translation-tracker tt-src=http://example.org/yvfol; I suspect this is actually helpful for authors in getting it right. But if we simply require everything to be data-* I agree that we're not likely to help anyone much. So if we are going to do something, IMHO it should look more like your attributes must have a dash in their name… Anne's point about the DOM interface also being an issue is very important also. Yes. Unless we're also going to be forcing everyone to prefix their APIs, which would also be really ugly, the namespace wouldn't be protected anyway. True… This a price of ditching XML and namespaces (which was done because there were benefits too). Those things are seperable, and there is no law that we can never re-invent namespaces for an HTML world if it turns out that the functionality really was needed. Hence my initial question - can we get a really important benefit for some (more) ugliness in the Web platform, do we need to find another solution, or is the problem so small we don't need to worry? I'm dubious about the last suggestion, but whether one or the other of the first two is more likely to be correct isn't immediately apparent to me. cheers chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Progress on Push API
Hi Eduardo, all, On Tue, 29 Apr 2014 11:00:15 +0200, EDUARDO FULLEA CARRERA e...@tid.es wrote: Hi all, Last week the Push API editors (ATT, Telefónica) and other interested parties (Mozilla, Google) met to progress this specification. Just a gentle reminder that if you are having a meeting there needs to be an announcement of it. I don't want to stop people doing work - obviously, we encourage that happening and applaud members who take initiative to get things done. But there is a process requirement, that you and your employer agreed to when joining the group. It isn't just a quid pro quo for the rest of us agreeing to go through a PAG if necessary. It is also based on an important legal requirement that standards be developed according to a fair process, to avoid being construed as engaging in anti-competitive or cartel behaviour. And of course it is good manners. As a quick reminder, the general notice times required are 1 week for a distributed telephone meeting (unless it is a regularly scheduled meeting) and 8 weeks for a physical meeting. If you want to organise a meeting for a particular topic the chairs and staff contacts will be very happy to help, both to make sure we meet the process requirements and with any necessary logistics. The notice period is the only one likely to have any real impact, and there is a way to approve shorter notice if it is really necessary. But I would ask people who want to organise a get-together that they provide the notice required by the Process, to ensure that interested parties in the working group have a fair opportunity to attend. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Progress on Push API
On Tue, 29 Apr 2014 16:02:43 +0200, EDUARDO FULLEA CARRERA e...@tid.es wrote: Hi Chaals, all, Hi, It was not intended to be an official W3C meeting, but just an informal discussion to feed the official standardization track, which AFAIK this mailing list is part of. Right. But the boundaries are difficult to define. If you invite more people than the editors to a discussion that isn't archived on this list (or a specific list for your spec, where relevant), then I strongly recommend that you make it a formal WG meeting. As you know, that doesn't actually have to be very formal. Basically, you have to tell people where and when it is happening, and give enough notice to meet the process requirements. Ideally there would be minutes, or at least a rationale along with any proposals. As you may note my previous email was not imposing any agreement to the group but just proposing a set of changes and asking from feedback from other parties. Understood - and that is a general part of how the group works: The requirement that decisions are made asynchronously, rather than imposed from some meeting where people may not be able to attend. But sorry if my email has led to any misunderstanding. No, it hasn't led to a misunderstanding, it shows that we (the chairs, but probably everyone) seem to have some misunderstanding in the group about meetings. As you know, this group tries to avoid having meetings unless they are for some purpose - but when we do have a purpose, we should be clear and hold a real meeting. And we do work to make that as simple and efficient as possible. Again, I am pleased that you are making progress. That's the real reason we are here. But part of the chairs' job is to make sure we follow the fairness procedures of W3C. Another part of our job is to make that as simple as possible for everyone so it becomes the easiest and obvious way to do things. cheers Chaals Regards, Eduardo. On 29 abr 2014 at 15:42:40, Charles McCathie Nevile wrote: Hi Eduardo, all, On Tue, 29 Apr 2014 11:00:15 +0200, EDUARDO FULLEA CARRERA e...@tid.es wrote: Hi all, Last week the Push API editors (ATT, Telefónica) and other interested parties (Mozilla, Google) met to progress this specification. Just a gentle reminder that if you are having a meeting there needs to be an announcement of it. I don't want to stop people doing work - obviously, we encourage that happening and applaud members who take initiative to get things done. But there is a process requirement, that you and your employer agreed to when joining the group. It isn't just a quid pro quo for the rest of us agreeing to go through a PAG if necessary. It is also based on an important legal requirement that standards be developed according to a fair process, to avoid being construed as engaging in anti-competitive or cartel behaviour. And of course it is good manners. As a quick reminder, the general notice times required are 1 week for a distributed telephone meeting (unless it is a regularly scheduled meeting) and 8 weeks for a physical meeting. If you want to organise a meeting for a particular topic the chairs and staff contacts will be very happy to help, both to make sure we meet the process requirements and with any necessary logistics. The notice period is the only one likely to have any real impact, and there is a way to approve shorter notice if it is really necessary. But I would ask people who want to organise a get-together that they provide the notice required by the Process, to ensure that interested parties in the working group have a fair opportunity to attend. cheers Chaals Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [admin] WebApps and the Proposed changes to the TR Process
are basically in flux and should be expected to change significantly more than the rest) is extremely valuable. A big goal is to get those reviews, as well as CR reviews, earlier in the process, instead of spinning around LC/CR for most of the development time of the spec saying it's almost finished... * Assuming the Director approves the proposal, there is a somewhat elaborate transition plan defined in http://lists.w3.org/Archives/Public/public-w3process/2014Mar/0019.html. Given WebApps' current charter expires at the end of May 2014, it's not clear to me if our new/updated charter would mean we will be a new (2014) WG or not; we could be in a situation where some of our specs use 2005 process and others the 2014 process. Don't ask me. I wasn't a big part of that decision process. But I *think* we could be a new group if we wanted to, although we could continue any specs that are almost finished under the old process. [Thank gawd Yves and Cindy will be responsible for `managing` this process ;-)] [Indeed. Although I think (hope…) it *looks* much more complicated than it will be in practice]. Comments about how the above are welcome as well as any other comments about how the proposed TR process could affect the group. It should not affect the group much at all, except that if we do a CR more or less right we won't have to go back through Last Call to revise it. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [admin] Should WebApps' HTML Templates spec be published as a WG Note?
On Wed, 26 Feb 2014 21:47:19 +0100, Arthur Barstow art.bars...@nokia.com wrote: On 2/26/14 3:44 PM, ext Rafael Weinstein wrote: It may be useful to mention in the note that the Template spec was merged to HTML (as opposed to simply becoming a concern of HTML, which might raise the question did HTML do something different than what this spec used to say?). Yes, I agree merged is a key operative word we would want to communicate in the Note. Agreed - and yes, this would be a good thing to do in general. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)
Tab, On Thu, 13 Feb 2014 19:09:33 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren ann...@annevk.nl On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell slightly...@google.com Until we can agree on this, Type 2 feels like an attractive nuisance and, onreflection, one that I think we should punt to compilers like caja in the interim. If toolkits need it, I'd like to understand those use-cases from experience. I think Maciej explains fairly well in http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html why it's good to have. Also, Type 2 can be used for built-in elements, which I thought was one of the things we are trying to solve here. Stay after class and write 100 times on the board: Type 2 is not a security boundary. This is not appropriate on this email list. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [progress-events] Progress Events is a W3C Recommendation
On Wed, 12 Feb 2014 16:49:07 +0400, Jungkee Song jungk...@gmail.com wrote: Thanks Art. The work is attributed to Anne, Chaals and Ms2ger. Thanks! Actually, I did editing, like Jungkee, and the work is attributed to quite a lot of people, many of whom worked on it before the WebApps group existed. Anyway congratulations to everyone. cheers Chaals On Feb 12, 2014 9:28 PM, Arthur Barstow art.bars...@nokia.com wrote: Congratulations to Anne, Jungkee and Chaals on the publication of a Progress Events Recommendation http://www.w3.org/TR/2014/ REC-progress-events-20140211/ . (I updated this spec's PubStatus data to state that no additional work is planned and that the feature is now part of XHR.) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [File System APIs] If one is good, then two must be better?
On Tue, 04 Feb 2014 20:48:30 +0400, Arun Ranganathan a...@mozilla.com wrote: On Feb 4, 2014, at 6:15 AM, Charles McCathie Nevile wrote: On Mon, 03 Feb 2014 19:09:53 +0400, Arthur Barstow art.bars...@nokia.com wrote: On 1/31/14 10:44 AM, ext Ian Clelland wrote: Hi Art, For what it's worth, theFile API: Directories and System is also implemented (and supported) by Apache Cordova[1]. The implementation is essentially complete for mobile applications on Android, iOS and FireOS, with nearly-complete support on Blackberry and Windows Phone. While our plugin registry was counting downloads, it was the most-downloaded plugin for the platform by a wide margin, so I believe it is being used actively. Thanks for this information Ian! I don't know if Cordova should count as a browser implementation for the purposes of this WG, but we are implementing the APIs and making them available to (hybrid) web application developers. The group has some flexibility regarding the specifics of the interoperability criteria used to advance a spec along the Recommendation track, but we haven't talked about the criteria for these specs since they are still working drafts. And the particular question here isn't about CR criteria, but about whether one or other approach is more likely to achieve the consensus of interoperable implementation. Which essentially means whether implementations are likely to switch, or credible future implementors have a strong preference for one over the other. In which case, what Cordova does (and more to the point what developers do with it) seems relevant information to consider as we try to find a consensus. Two interoperable implementations of a specification should determine the way forward. In this case we have multiple ways forward, and the fact that any of them have two implementations is an important but not sufficient indicator that they therefore have industry consensus as the way forward. For historical comparison, there were three at least reasonably interoperable independent browser implementations of WebSQL, when there were no real implementations of IndexedDB. There was one browser objecting to dropping WebSQL for IDB, 2 who said they would not implement it, and 4 (including 2 of the 3 webSQL implementors) saying they *would* implement IDB. We thus made the decision to focus on IDB. For any faults that it may have, it appears to have become the standard, which makes me suspect that focusing on it was the correct decision at the time. Similarly the issue here is not whether we can make a specification for one or the other approach that *could* be a standard, since it seems we can, but whether one or the other is a clear candidate to be a real standard - i.e. what people *will* actually do... I think one of the mistakes with IndexedDB (and appcache for that matter) was that the participants in the discussion were too heavily biased toward browser implementors, without enough input or involvement from working developers. Which meant that we standardised something that didn't meet people's expectations as well as we and they hoped. I hope that when we make a choice it's one that not only matches the reality of what gets implemented, but helps us provide what the market really wants. I presume everyone here hopes for that. I think a key part of how to get there is to listen carefully to the feedback we get, and look around at what people are doing, rather than just relying on formulaic rules of thumb or bureaucratic tallying of test results. cheers Chaals While I think distributions like PhoneGap are extremely useful as web-like abstractions on top of disparate mobile platforms, it is not straightforward to make a clear apples to apples comparision for API interoperability between PhoneGap and a web browser, or conduct common test cases. Naturally, the distinctions blur, but I still think they exist. A web page using the FileSystem API in JavaScript and working in two separate browser implementations seems like a good measure of interoperability, and I think this should be what helps us make a determination. -- A* -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
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: Regarding: Making the W3C Web SQL Database Specification Active
On Wed, 01 Jan 2014 23:00:21 +0100, Marcos Caceres w...@marcosc.com wrote: On Tuesday, December 31, 2013 at 3:29 AM, Shane Harrelson wrote: Not to beat a dead horse, but would https://code.google.com/p/csharp-sqlite/ count as an independent implementation of the SQLite SQL syntax? So no, it would not count (not unless we want to really dilute how a specification becomes a W3C standard). To prove that it is possible to independently implement the specification and get something interoperable, it would in principle be fine. But that is only one part of the requirements for a standard... Using an unmaintained project as a ways of advancing as specification would kinda defeat the point of standardization of browser technology. In that it fails to change the perception that there is not real interest in making the particular spec into a standard. To benefit the web, the only independent implementations that would actually matter would need to be browser-based. That's not really true. It is important to get implementations in browsers, and the fact that currently a number of major browsers have stated that they are not interested in implementing (or in some cases in maintaining impementations of) Web SQL is one reason it is not considered worth further work at this time. If there were compelling* services based on WebSQL, the question might be re-examined. The inability to meet a particular bureaucratic interpretation of independently implemented interoperable uses isn't the reason why work has stopped. It happened because there was no apparent likelihood of WebSQL becoming a standard that was generally implemented, and there was an alternative that appeared to have a much higher probability of being worth working on. Of course, all these judgements are just that. History has proven them wrong in the past, and that will continue to happen. cheers Chaals *I mean something that has 10% penetration, or 25% penetration in a few key markets, not just a few hundred people agree this is really fantastic - although if those people happen to be browser engineers or standards wonks the reality is that you have a better chance of getting a real standard to occur) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Contributions Re: Call for Exclusions: DOM Parsing and Serialization
On Fri, 13 Dec 2013 16:42:20 +0400, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Dec 12, 2013 at 6:31 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: It's unclear what you think we should be doing differently. Well, for instance, that when I point something out that was missed I am not directed to submit my feedback again, elsewhere. Hmm. That isn't what happened: [[[ On 12/10/13 10:54 AM, ext Anne van Kesteren wrote: On Tue, Dec 10, 2013 at 3:42 PM, Arthur Barstow art.bars...@nokia.com wrote: During the CfC, I only recall one technical comment and Travis created bug [23936] for that comment and he noted that comment will be considered as a `LC comment`. It seems the technical comment about it blatantly contradicting the DOM Standard went lost somehow. It's not ready for Last Call. Well, it certainly wouldn't be the first time we've had more than one LC ... Anyhow, if the bug doesn't capture your concern(s), please update it. ]]] i.e. we believe the editor is tracking your feedback, we hope we have correctly interpreted it, and in case we haven't you have a pointer to correct us. You're not directed to submit it again, we're trying our best to ensure that we don't misunderstand and fail to deal with it adequately. So I still think there is a misunderstanding here rather than a real problem - but if I am wrong, I'm happy to keep trying to find out what the problem that we should solve is. (Please note that I am not trying to pick on you. In this particular instance I think we have ended up wasting more of everyone's, and in particular each others', time than we needed to, by not being very clear in the first place. And for my fault in that I apologise). cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Call for Exclusions: DOM Parsing and Serialization
On Thu, 12 Dec 2013 19:49:30 +0400, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 7:35 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Tue, 10 Dec 2013 17:21:20 +0100, Anne van Kesteren ann...@annevk.nl wrote: Since when did we start putting the onus on the reviewer that her or his feedback is captured? Before I started working with W3C in the mid 90's (although as noted below it is part of a set of checks and balances). Given the scarcity of quality review that seems bad. I think what's bad is that it is difficult to get quality review, good editors, and excellent contributions from the working group. But I don't see an obvious fix for that. Indeed, the point of soliciting review is because it seems unlikely that even the best set of contributors working together will always be right. Indeed. And we expect the editor to do that to the best of their ability. In the past, where editors were actually editing a document that was produced more directly by the whole Working Group, the group itself also assumed some of that function. But editors are not infallible, and the new model Working Group tends to be less hands-on about directing the editor. I believe largely at the perceived behest of a handful of high-profile editors such as yourself. So in practice the necessity for a commenter to check that their comment was understood correctly and correctly acted on has become a little more prominent in the overall balance of how things are done. Sad to learn this is how WebApps tries to run things. Both as editor and reviewer I find this unacceptable. I think we're misunderstanding each other. This isn't how Webapps tries to run things, nor any kind of formal policy. It is a reflection on the imperfect world we live in. It's unclear what you think we should be doing differently. If you believe we can simply insist that editors do a perfect job of capturing feedback and responding to it correctly, we will have to disagree. If you think that reviewers should expect the editor and the Working Group to make a serious good faith effort to understand and respond correctly to a review comment we are in violent agreement. As an editor and a chair, I find it unfortunate when a reviewer doesn't follow up their comment to ensure that it was clear and that the Working Group acted on it in a satisfactory way, because while I would like to trust that this is the case I am more confident after checking. But given the absence of an enforcement mechanism, that's just another of the unfortunate things that happens (and in general I would prefer that than a too-strict enforcement mechanism). cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Call for Exclusions: DOM Parsing and Serialization
On Tue, 10 Dec 2013 17:21:20 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 4:04 PM, Arthur Barstow art.bars...@nokia.com wrote: Anyhow, if the bug doesn't capture your concern(s), please update it. Since when did we start putting the onus on the reviewer that her or his feedback is captured? Before I started working with W3C in the mid 90's (although as noted below it is part of a set of checks and balances). That seems like the wrong way around. The editor should actively seek feedback and make sure it's tracked and addressed. Indeed. And we expect the editor to do that to the best of their ability. In the past, where editors were actually editing a document that was produced more directly by the whole Working Group, the group itself also assumed some of that function. But editors are not infallible, and the new model Working Group tends to be less hands-on about directing the editor. I believe largely at the perceived behest of a handful of high-profile editors such as yourself. So in practice the necessity for a commenter to check that their comment was understood correctly and correctly acted on has become a little more prominent in the overall balance of how things are done. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On Tue, 10 Dec 2013 20:14:35 +0100, Travis Leithead travis.leith...@microsoft.com wrote: During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared Workers from the W3C Web Workers spec [3] in order for the spec to pass the first of the two stated CR exit criteria in the spec itself. It is my intention to start this work soon. My question for the group-should I transplant the Shared Worker spec prose into a separate REC-track editor's document, or simply remove it outright? (Removing it would be easier of course :0) And of course, I'd love to see you do the work of putting it into a new spec for the Rec-track, especially if you're able to follow up on editing it. As a chair and personally, I'd love to see someone volunteer to take that work and move it faster than you can... cheers [1] http://www.w3.org/2008/webapps/track/actions/709 [2] http://krijnhoetmer.nl/irc-logs/webapps/20131112#l-661 [3] http://www.w3.org/TR/2012/CR-workers-20120501/ -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish new WD of Input Method Editor API; deadline December 13
On Fri, 06 Dec 2013 18:16:06 +0100, Arthur Barstow art.bars...@nokia.com wrote: Takayoshi would like to publish a new Working Draft of Input Method Editor API. This is a Call for Consensus to do so using the following document as the basis: https://dvcs.w3.org/hg/ime-api/raw-file/default/TR4.html Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. Please go ahead. cheers If you have any comments or concerns about this proposal, please reply to this e-mail by December 13 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, ArtB -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [webcomponents] HTML Imports
On Wed, 04 Dec 2013 18:58:10 +0100, Scott Miles sjmi...@google.com wrote: seems a specification that seems really pushed/rushed Since my team (Polymer) has been working with imports in practice for a year-and-a-half (100% public and open-source, btw) this seems a strange conclusion. As Bjoern pointed out, this functionality is something we have been trying to get on the web for most of the history of the web. And I think it is fair to say that we have often pushed to get something accepted. We're still pushing - it would be useful to solve this longstanding problem. I don't know if that equates to rushed. This is discussed elsewhere, and I don't think it's a very fruitful discussion. But this is only my perspective, I'm still a standards n00b I suppose. In any case, I codified the concepts that our team has been espousing in a document here: https://docs.google.com/document/d/14qJlCgda7GX2_KKxYhj1EULmY_hqNH35wjqDgGSkkOo/edit# The aim of this document was to address some of the questions around pragmatic operation of the spec as we see it. Thanks. This is helpful. More perspectives from different kinds of people who have tried to use Web components may be important contribution in deciding whether we have it right enough. cheers Chaals Scott On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com wrote: I would say though that I get the feeling that Web Components seems a specification that seems really pushed/rushed and I worry that might lead to some poor design decisions whose side effects will be felt by developers in the future. I very much share this sentiment. -- http://annevankesteren.nl/ -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?
On Wed, 04 Dec 2013 08:18:31 +0100, Marcos Caceres w...@marcosc.com wrote:
On Wednesday, December 4, 2013 at 4:16 PM, Jonas Sicking wrote:
I’m not saying we shouldn’t allow it - just sayin’ its kinda crappy
because it encourages bad development practices (leading to single
page apps, etc.).
For simple apps I don't see anything wrong with single-page.
I'd rather spend time on making multi-page experiences good so that
authors don't avoid it, than try to force it.
[...]
Sorry, I should have clarified this a bit more. This isn’t about single
page vs multipage apps (of course there will be apps that are single
page!) - it’s about the expectation by browser vendors that apps would
be developed as single page and what we are seeing in the data about
single page apps: When looking at apps that declare
“*-mobile-web-app-capable”, which are supposed to be single page apps by
design, we found that very few apps are actually built as single page.
[...]
Having said that, there are issues also with navigating installed web
apps. The phonegap guys have a wealth of experience to share here,
though they are proponents of single page apps to overcome limitations
in the Web platform (e.g., avoiding the flash of white when loading
another web page when navigating). Anyway, we can deal with those issues
later - but just want to be clear about what we’ve seen in the dataset
we’ve been looking at in WebMob and what the forthcoming issues are
going to be if this goes mainstream.
Looking forward to you publishing that data. Is there a simple pointer for
those of us who haven't been following webmob closely so we can start from
somewhere better than all of webmob?
meta name=manifest content={ ... },
link rel=manifest content={ ... },
I think developers will object to the above. If src-n was an
abomination to some, then I can’t imagine the above being well received.
I think the src-n dislike came from the fact that it tried to use
something that has always been a dictionary with a limited and defined
set of keys and tried to use it as an array with an unbounded key set.
Yes, from an implementation perspective yes. But in the RICG, from web
developer perspective, it was more about the strange use of the
attribute.
Indeed.
That's very different from what we are doing here which is sticking a
very large value into an attribute.
Personally my vote goes to using link rel=manifest for external
manifests, and meta name=manifest for internal manifests. That has a
nice symmetry and reuses existing elements in a proper way.
And you can put line breaks inside attributes. They don't show up in
the attribute value but that seems ok here.
And you don't have to escape quotes as long as you use apostrophes as
to delimit the attribute value. I.e. the following is just fine.
meta name=manifest content='{
a: 1,
b: foopy
}'
I really don’t like this - specially messy with the single quote/double
quote thing which is one screws it up is a huge pain in the as to debug.
Structured content really feels like it should be in an element.
Yes, but I wonder how big a real problem that is. I happen to use a
bare-bones version of vi that doesn't balance parentheses, quotes, etc,
but I believe that shows I am a very strange person. As far as I know,
debugging this kind of error semi-automatically is actually pretty
trivial, and common.
or something else. Like you said, I think it's a conversation we
need to have with the HTML people.
I’ll investigate a bit more. I’ve added a bug here:
https://github.com/w3c/manifest/issues/91
I’ll just note that having link rel=manifest and script type
manifest would kinda suck… if we can just have:
* script type=“application/manifest+json”
src=“manifest.json”/script
* script type=“application/manifest+json”{}/script that would be
great.
That would be great. Reading the HTML spec, I think we can.
I prefer link/meta as the above is pretty verbose and a lot to
remember. And using link to link to external manifests just make so
much sense.
But I'll defer to you on this.
I’ll bounce it to HTMLs people and see what they say.
From an authoring perspective I don't think the verbosity is a big issue,
and the two options *seem* about equivalent in cognitive load - switching
elements is odd but people are clearly used to doing it for style, and
setting a type attribute in a script element compared to using link/meta
is the same thing.
Which makes the big question about taste in syntax (unless there is some
real implementation or web-compat issue). So I expect it to be the hardest
one of all to solve :)
cheers
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: New manifest spec - ready for FPWD?
On Tue, 03 Dec 2013 19:27:15 +0100, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Dec 2, 2013 at 9:40 PM, Marcos Caceres w...@marcosc.com wrote:
What I think we should have is something like:
chrome: {
back: true
}
Yep, this is currently captured here:
https://github.com/w3c/manifest/issues/76
Those of us working on this still need to investigate FxOS a bit more
to see what people are using in practice and why (e.g., how much
granularity do we really need? to the button level “forward”/“back, or
can we just say “navigation-bar”, etc.). Captured here:
https://github.com/w3c-webmob/installable-webapps/issues/17
Simply wanting *just* the back/forward buttons has been common. I
could imagine apps relying on the reload button as well.
Yes. Especially for things that come off the web (as opposed to packaged
apps).
I have not heard of, but I could imagine, apps wanting to rely in the
title of the page being displayed.
Quite possibly
[use case snipped]
The url bar is a very common separate UI piece on most platforms.
However it's unclear how a URL bar would work in a standalone UI.
Would the user be able to type any URL while still remaining in within
the standalone UI? Seems surprising if we imagine that the standalone
UI uses the icon of the app. Though we could always open any typed URL
in the default browser. Anyway, staying away from url-bar seems safer
for now.
Yes. In-apge Search is something that might also be useful within an app -
especially if you can find out it is happening and respond to it
intelligently if the app hides things by default.
Beyond that I think platforms diverge a lot. In FirefoxOS we're
planning on adding a whole menu which contains things like bookmark,
save, share, reading list etc.
Hmm. I don't think platforms diverge that widely, but I agree that we
should expect different platforms to offer different functions. We
probably want to agree on what we call anything, rather than have
different names for each different browser (кладки is intuitive to most
people who will develop for Yandex, but might not be the best choice
overall ;) ).
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: Fixing appcache: a proposal to get us started
On Thu, 28 Nov 2013 16:38:55 +1000, pira...@gmail.com pira...@gmail.com
wrote:
Json manifest seems a nice solution to me :-)
Blergh! :-)
More to the point, it seems that the approach of ServiceWorker discussed
at the TPAC meeting, and based on Alex Russell's proposal which is
unfortunately lacking an actual spec, is getting considerable traction as
the path to follow for fixing appcache.
It would be useful to get a sense of whether people think we should do
something else.
cheers
Chaals
Send from my Samsung Galaxy Note II
El 28/11/2013 07:21, eli elib...@gmail.com escribió:
The web is server + client sides. Trying to fix issues you have
with
client technologies only (appcache, JavaScript, ...) will always be
a
bad
choice.
I disagree, Javascript and web browsers are becoming powerful enough
to delegate servers to their barebones, just offering storage or
databases or specific web services, being able to delegate all the
operatibility to the client-side code. In the new web, web servers
are
just plain ol' API
It's not that much a question of available power, it's just operations
that needs to be done before any file hit the device.
To be available offline, the device has to hit a server first, then the
appcache magic happens.
No reason the server couldn't prepare / select what to send to the
device: iOS won't support WebM anytime soon, there is no reason to
constantly ask iOS device the same info again again. That just makes
no
sense, and force devs to produce device/os specific files (manifest)
anyway.
And it's not AppCache job to do so. Its job is just make a web document
available offline + make updates simple easy.
Example : Not being able to update one single file keeping the others
cached is a structural mistake. Sub-manifests sounds like an
over-engineered fix to me, just making things more complicated for
developers, browser vendors for future evolution of this
specification.
Could the problems of not being able to update one single file in the
cache, and not sending WebM files to iOS devices, both be solved by
adding
additional file info to the cache manifest?
For example, if the manifest were in JSON:
{'CACHE': [
{'file':'index.html','timestamp':'2013-11-27
00:00:00','expires':'2013-12-02
00:00:00','type':'text/html'},
{'file':'video.webm','timestamp':'2013-11-27
00:00:00','expires':'2013-12-02
00:00:00','type':'video/webm'},
{'file':'video.mp4','timestamp':'2013-11-27
00:00:00','expires':'2013-12-02
00:00:00','type':'video/mp4'}
],
'NETWORK':'*',
'FALLBACK':[['online.jpg','offline.jpg'],['online.htm','offline.htm']],
'SETTINGS':'prefer-online'}
This way, a browser can compare a file's timestamp in the newly
downloaded
manifest to the one in its stored manifest to determine whether or not
to
download a new version. And an iOS device could ignore 'video/webm'
file-types.
-Eli
--
Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix.
– Linus Tordvals, creador del sistema operativo Linux
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish FPWD of Manifest for web apps and bookmarks; deadline December 9
On Mon, 02 Dec 2013 19:27:09 +0100, Arthur Barstow art.bars...@nokia.com wrote: Marcos proposed in [1] that WebApps publish a First Public Working Draft (FPWD) of Manifest for web apps and bookmarks and this is a Call for Consensus to do so, using the following document as the basis for the FPWD: http://w3c.github.io/manifest/ Please do. cheers 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 December 9 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0588.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Fwd: Reminder: TPAC 2013 feedback requested by 8 December
Reminder. If you were at TPAC, please fill this survey out. In particular, the format of TPAC meetings is up for discussion, and results from this survey are likely to get a fair bit of weight - in many cases they represent the opinion of people who went out of their way to attend, which is a sound reason to listen to what they say. cheers Chaals --- Forwarded message --- From: Ian Jacobs i...@w3.org Subject: Reminder: TPAC 2013 feedback requested by 8 December Date: Mon, 02 Dec 2013 23:14:52 +0100 Dear TPAC Attendees, If you have any feedback on TPAC 2013, please take a moment to complete this survey before 8 December: https://www.w3.org/2002/09/wbs/35125/tpac2013-feedback/ Thank you! Ian -- Ian Jacobs i...@w3.org http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: New manifest spec - ready for FPWD?
On Tue, 03 Dec 2013 06:40:43 +0100, Marcos Caceres w...@marcosc.com wrote:
On Tuesday, December 3, 2013 at 3:01 PM, Jonas Sicking wrote:
On Tue, Nov 26, 2013 at 1:02 PM, Marcos Caceres w...@marcosc.com
(mailto:w...@marcosc.com) wrote:
The Editors would appreciate if people take a look and see if you
agree with the feature set.
When we did outside-of-browser-UI web apps for FirefoxOS we quickly
found that a lot of developers want to be able to rely on UA-provided
UI such as the back button.
Yeah, this was my experience developing widgets as well. Saying they run
in the browser means people assume the browser can do normal browser
things (which, admittedly, are poorly defined beyond follow links and go
back).
Yes, the app can detect that it's running standalone and display a
back button itself. However that was significantly more work than any
other part of creating a standalone app, which mostly consisted in
writing a manifest. It's especially a lot of work if you want to try
to replicate the platform-rendered back button on all platforms.
What I think we should have is something like:
chrome: {
back: true
}
Yep, this is currently captured here:
https://github.com/w3c/manifest/issues/76
Those of us working on this still need to investigate FxOS a bit more to
see what people are using in practice and why (e.g., how much
granularity do we really need? to the button level “forward”/“back, or
can we just say “navigation-bar”, etc.). Captured here:
https://github.com/w3c-webmob/installable-webapps/issues/17
I'd suggest keeping the functions pretty granular. My navbar include
various extension buttons, and my Opera navbar included the rewind
function (which I loved). I think we'll set very mixed expectations if we
try to make general statements about what browser functionalities are,
that will cause more confusion than benefit.
(Unless we want to do that to try and discover exactly what people expect
by seeing how much of all the thingz get b0rken).
If the UA doesn't support any of the properties in the chrome
section, then the UA should be required to not launch the app in
standalone mode.
Yeah that makes sense.
I also think that we need a way to put the manifest in-line in the
main document. In part, technologies tend to be a lot easier to
understand if you can create a single-file demo. In part, for small
simple apps, having to separate the manifest into a separate file
could be annoying and might drive people to stick to the existing
meta-tags.
Would it suffice to use the API? It’s much simpler than trying to write
out JSON by hand and wouldn’t require us to create any new special
script type, etc.
script
if(“requestBookmark” in navigator){
var appDetails = {name: “Awesome app!”, mode: “standalone”};
navigator.requestBookmark(appDetails).then(happy,sad);
}
/script
It’s more or less equivalent to making it declarative and easily passes
the “OMG! that’s so easy!” test :)
Why wouldn't we use the API *and* allow people to write JSON if they want
to? Or is that what you meant?
Obviously, devs will still need to continue using a lot of the meta tags
for a while to support legacy browsers (or any browser that doesn’t
implement this).
I also think the dont-share-cookies-and-stuff thing needs more work
before it's ready for inclusion.
Yes, totally. It’s just there for discussion.
So might be better to drop that for
FPWD. But I'm fine with keeping it in for now too and dropping it if
we can't solidify it.
I’m happy either way. I’ve been told by lawyer types elsewhere at the
W3C that it’s best to pack lots of half-baked ideas into an FPWD. Gives
those folks a better understanding of the impact the standard might have
on them (… they will have to check again in LC, obviously, but it gives
them a head start).
Likewise it helps implementors who are not following the group really
closely (and I can think of several of those off the top of my head) get a
sense of what we're thinking about. On balance I think it's a better
approach to include stuff, and say inline where it's up to in stability -
especially at the relatively early stages where we expect changes anyway.
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Re: [screen-orientation] screen orientation angle
or screen.orientation.angle (and screen.orientation.name). WDYT? [1] http://oldworld.fr/google/compass.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058 [3] the value can be negative, which is a footgun and the having this value living in window and the rest in window.screen is odd -- Mounir -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish Candidate Recommendation of File API; deadline November 28
On Thu, 21 Nov 2013 19:44:29 +0100, Arthur Barstow art.bars...@nokia.com wrote: Hi All, Arun completed processing the comments [Comments] for the Last Call version of File API [LCWD]. Although the comments resulted in changes to the spec (see [Diff]), no new features were added and the changes are considered bug fixes. The most significant change is the Constructor APIs in Section 7 - see [Section-7]. Arun proposes the spec be advanced to Candidate Recommendation and this is a Call for Consensus (CfC) to publish a CR using the following version as the basis: http://dev.w3.org/2006/webapi/FileAPI/ Please do. ... I propose 3 months as the minimal amount of time before we are ready to advance the spec to Propose Recommendation and I propose we re-use the CR exit criteria we used for the IDB CR: [[ During the Candidate Recommendation period, which ends @T+3months, the WG will complete its test suite. Before this specification exits Candidate Recommendation, two or more independent implementations must pass each test, although no single implementation must pass each test. I suggest s/each/every/ here just to disambiguate a bit more. But I can live with these as criteria. cheers chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish Proposed Recommendation of Progress Events; deadline November 25
On Mon, 18 Nov 2013 20:28:06 +0800, Arthur Barstow art.bars...@nokia.com wrote: The Implementation Report [ImplReprt] for the Progress Events CR [CR] indicates the CR's exit criteria have been met. As such, this is a Call for Consensus to publish a Proposed Recommendation of Progress Events using [CR] as the basis. If you have any comments or concerns about this CfC, please reply to this e-mail by November 26 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. please do. chaals -Thanks, AB [ImplReprt] http://www.w3.org/wiki/Webapps/Interop/ProgressEvents [CR] http://www.w3.org/TR/2011/CR-progress-events-20110922/ Original Message Subject: ACTION-702: Start cfc to publish pr of progress events (Web Applications Working Group) Date: Mon, 11 Nov 2013 09:10:18 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-702: Start cfc to publish pr of progress events (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/702 On: Arthur Barstow Due: 2013-11-18 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline November 25
On Mon, 18 Nov 2013 20:00:00 +0800, Arthur Barstow art.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish a LCWD of DOM Parsing and Serialization, using the following ED as the basis: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html Please do... cheers 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. ]] Currently, this spec has one Editorial bug [18939] that is open and Travis will fix this before the LCWD is published. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by November 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. The proposed review period for this LC is 4 weeks. Assuming this CfC passes, if there are any specific groups (e.g. HTMLWG, TAG, I18N, WAI, Privacy IG, Security IG, etc.) we should ask to review the LCWD, please let me know. -Thanks, AB [18939] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18938 Original Message Subject: ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) Date: Mon, 11 Nov 2013 01:59:39 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-701: Start a cfc to publish lcwd of dom parsing and serialization (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/701 On: Arthur Barstow Due: 2013-11-18 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
where Re: CfC: publish WD of Streams API; deadline Nov 3
On Mon, 04 Nov 2013 09:52:20 +0100, Domenic Denicola dome...@domenicdenicola.com wrote: As for *where* the work is done, I will be working within the context of the WHATWG to produce this specification. My understanding is that usually the W3C picks some point in time to fork WHATWG specifications into W3C ones, changes some minor details (such as removing authorship information and changing the genders used in examples), then advancing it through the usual ED/WD/LCWD/CR/PR/REC track in order to get patent disclosure. Err, no. Although this has happened, it is not the usual pattern and is not the way this or other Working Groups try to work. I'm very interested in ensuring patent disclosure for the streams specification, so I hope someone takes on this work, but I do not think it would be a good use of my time to do so, as from what I understand there are people at the W3C who have this process down to an art. You seem to have misunderstood the point of the Working Group. Although Art is pretty efficient at publishing documents where the editor doesn't do the work required, he is under no obligation to do so and it is not a goal of the Working Group to spend his time on that. The idea is that the Working Group discusses the issues it has, reaches consensus (typically this happens because technical people come to an agreement by discussing things, although e.g. on bikeshed issues it can be more painful and need to be done by some formal process), and produces a specification. It is not an assumption that people in this Working Group are also following WHATWG, and there are likely to be important contributors who are not doing so. Where specs have been taken to WHATWG (e.g. XHR) the development is essentially independent, converging to the extent that the two communities come to the same conclusions. You're welcome to work where and (within requirements that may be made by each community) how you want. But the effective way to provide your specification with the patent commitments made by W3C members is to do the work within the W3C process. W3C members make no commitment to specs that do not go through that process, and you should not assume that a spec developed elsewhere will automatically be considered - the quid pro quo of the patent commitments made by W3C members is a deliberate choice to take up any given work item. Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Testing Pointer Lock
On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib sch...@google.com wrote: Pointer lock is tricky to automate tests for. Consider some examples: - Upon lock, no pointer should be visible. - A user gesture is required to lock when not in fullscreen. - Transitioning to fullscreen and pointer lock then exiting fullscreen should maintain pointer lock. (User gesture required to enter fullscreen) - While locked, moving the mouse indefinitely in any direction must continue to provide non zero movementX/Y values. I'm considering starting some pointer lock tests with testharness.js. The only solution I see is to provide instructions in many tests for manual actions and observations. I appreciate any best practice suggestions, or pointers to other specifications with similar challenges. So far I see geolocation tests provide manual instructions. Longdesc also has manual tests. The ones at http://github.com/chaals/longdesc-tests are looking like they will be accepted as actual tests. There is *1* automated test, which I haven't tried to put it into testharness yet. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: HTML as application manifest format
On Thu, 01 Aug 2013 20:24:40 +0400, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: Hi Kornel, Although I have complete empathy about your criticisms regarding JSON, it is actually quite fit for this purpose. Using HTML in the way you describe is kinda problematic, in that it could include scripts and other resources: basically, one would need to build a DOM to parse out the information - and even if scripts where not run, or resources loaded, one would still then need to make a special HTML just for this purpose (which would confuse people, as if you use HTML you expect to be able to have access to features of the platform). We are going to need a custom processor for the JSON format, but at least parsing is already done for us (as it was with XML, though sadly it seems that devs prefer JSON). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. Hmm. JSON seems to be Mozilla's serialisation format, and is also used in Blink for a bunch of stuff. That said, people have already commented on its drawbacks: - unless you think in data structures or pad it with whitespace everywhere it is hard for humans to read - it's incredibly strict and I don't know of any concrete suggestion that would change that - there is no standard mechanism for comments - nor localisation But for vast numbers of developers meta name=key content=value stuff Is really *really* easy. It gets harder when you want to nest things - you can have meta name=icon content=icon.png but we all know that you really need one of meta name=icon content=icon.png size=12x12 meta name=icon content=icon.png,12,12 meta name=icon content=icon.png maxwidth=12px maxheight=12px or something similar that does complicate the use of meta. As Scott notes, there are in fact a lot of people using the existing widget manifest stuff apparently without tearing their hair out - as well as his list there are Sencha, Blackberry, and other reasonably well-known examples. As Marcos has pointed out elsewhere, it is feasible to relax the XML parsing to work like HTML (Opera Presto does this for XML in general, and has been able to since well before they were working on widgets), which removes the most obvious source of terrible errors. Adding a third way to encode the same semantics isn't obviously the right thing to do, but I think the idea is worth exploring. My take is that the concerns about building DOM and developers being confused are not super-critical. Yeah, I suspect that isn't as big an issue as it seems. HTML Templates produce chunks of DOM that don't run scripts or load resources, and it's unlikely that constructing a DOM tree for the manifest will cause any serious performance concerns. On the other side, if a page defines an application, and the metadata lets you take that application and run it off the page, that seems like a useful thing. From that perspective, the preformance impact of a few meta elements on a running application seems trivial. Browsers will generally be running the app (so for them the separate file is an optimisation, albeit a minimal one), while things like app stores that just parse the metadata are likely to ignore scripts etc. Another problem arises if someone tries to use script to adapt the metadata eg for localisation, and a processor doesn't apply the script - but that's a case of defining use cases, requirements, and specifying what implementations need to do with the information they get. For serious use cases I am pretty sceptical of meta elements. On the other hand I also think JSON is horrible, but there are plenty of developers who love it and want to use it for everything. Frankly I'm far more interested in looking at the approaches people are using and trying to overcome the repetitive NotInventedHere, or at least get the *same* semantics instead of *roughly the same* as we currently have. I think achieving even that limited goal would be a far greater service to developers and therefore to their users than the meagre benefits that have been offered by the slight differences we have managed to build into each system so far. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Web Widgets, Where Art Thou?
a few of the old sites that are using view mode media feature targeted at presto and see if they have a separate page or if they use the same page. That should at least be indicative of who is more right? -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Web Widgets, Where Art Thou?
for it, and I think the benefits of JSON are sometimes overplayed. While it is relatively compact and familiar to people who live in javascript, it is less intuitive than XML to a surprisingly large number of developers. It really suffers from being terrible for internationalisation, although that is something a company working in multiple scripts and languages sees more than people who only work in english. And it isn't otherwise as free as it seems. I guess Mozilla and Google will continue to work with JSON, so it is important to take taht into account. But others will continue to find it extremely limited, while requiring a high-degree of complexity for a limited set of features. As far as I can see it currently makes sense to continue doing what we do and produce/consume both JSON and XML, and keep the two in synch. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Web Widgets, Where Art Thou?
years in front. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Registration for TPAC 2013 is Open
Hi folks, (forwarded...) Webapps is planning to meet at TPAC. Registration for TPAC2013 is now open: TPAC 2013 11-15 November Shenzhen, China http://www.w3.org/2013/11/TPAC/ (that page includes information about visas, and getting an invitation - which many people will need in order to get a visa). 1) Register: https://www.w3.org/2002/09/wbs/35125/TPAC2013/ NOTE: Many people are required to have a visa for entry into China. Please see the registration form for information about securing an invitation letter from Beihang University for a Chinese visa to attend TPAC 2013. 2) Make your hotel reservation: http://www.w3.org/2013/11/TPAC/#Accommodation NOTE: The TPAC 2013 organizers have secured a special guest room rate at the Shenzhen Wuzhou Guest House (the venue). The special rate expires 10 October 2013. If you have any questions, please contact Angel Li w3t-tpregis...@w3.org. -- On registration and registration fees -- There is a daily registration fee. The per person, per day fee is: * 60 USD if registration and payment completed by 18 October 2013; * 120 USD otherwise. As in the past, registration is a two-step process: 1) completing a registration form: https://www.w3.org/2002/09/wbs/35125/TPAC2013/ 2) using a payment system. We are using a new payment system for TPAC 2013. Upon registration you will receive an email with payment instructions. NOTE: The payment system will be available shortly; you may still register right away and you will be notified automatically once the payment system becomes available. For more information about registration fees (including who is not required to pay registration fees) and the payment system, see http://www.w3.org/2013/11/TPAC/#Registration -- Camp-style Plenary Day -- We plan to organize the plenary day camp-style, as we did last year. We encourage you to propose breakout sessions in our wiki: http://www.w3.org/wiki/TPAC2013/SessionIdeas -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Kickoff application manifest work
On Tue, 25 Jun 2013 16:49:09 +0400, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 24, 2013 at 11:50 PM, Jonas Sicking jo...@sicking.cc wrote: All of this information can of course be duplicated in each HTML page that an application consists of. But that's a lot of information duplication. It would definitely put some hard requirements on that generation of HTML pages is always done using code of some sort. (It is in principle possible to copy by hand, although it is a pretty good way to make a powerful footgun…) It also makes it very difficult for several applications to share a page as a component unless the design becomes crazy-complex. While such sharing may introduce security risks, it seems that simply prohibiting it outright for everything isn't the right place to impose the restrictions. Either make files or server side scripts. I wonder if we should do something similar to script/style. That you can do either. It is a minor increase in complication, but in principle I liked the idea... Requiring an external file seems kinda onerous too, though maybe it's not so bad. In practice I think it is not at all bad. Even a manifest as simplistic as appcache seems to work ok in an external file, and as Jonas said, being able to have app metadata in an easily spidered format isn't a bad thing. (Bad joke: You could always use a .mht archive to have everything in the same file...) We could also enable pages to signal this information through an API to the UA. That way they author can put the information in a central location himself. And it doesn't seem like a particularly simple solution in practice But that also means that the metadata can't be found through spidering. True, although it seems spiders are becoming ever closer to full-blown browsers. The great big ones, sure. But being friendly to people who have small custom spiders (e.g. that really only crawl for app manifests or whatever) seems important to me. Allowing for open App stores seems like a use case for this - it should be possible to effectively make systems for curating a collection of apps semi-automatically, without requiring a full browser infrastructure under the hood. (I realise this is as really a business philosophy point rather than a truly technical one, but it has technical implications) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Kickoff application manifest work
On Fri, 21 Jun 2013 09:15:30 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 19, 2013 at 7:39 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: One of the scenarios I have in mind is where a few apps from an origin use some common stuff. Which is obviously increasing the attack surface in the way that you mention, but if the same people are forced to use different origins for stuff that is copy-pasted across then I am not sure we are really exposing anything new except a requirement to buy more domains... Well, sharing data via messages rather than having actual shared data is a big benefit security-wise. Yeah, definitely. To be honest I was thinking of sharing e.g. scripts and images - semi-static resources. Because the boundary is there by default, you instead need to think about what to expose to other applications and what is safe. In principle that's true, but I am suspicious that the net effect is that people just reflexively copy-paste a pile of stuff without thinking very hard (similar to the way they just import a whole library because they want a couple of functions). You'll also scale better as you can more easily integrate with services running on other systems. (I need to think about that to be sure I understand it) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Kickoff application manifest work
On Wed, 19 Jun 2013 11:27:33 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 19, 2013 at 3:59 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Wed, 19 Jun 2013 06:56:13 +0200, Anne van Kesteren ann...@annevk.nl wrote: Downside of that approach is increased attack surface for a suite [of] applications Can you please expand on that? Say you have http://example.org/mail/ and http://example.org/contacts/ Because of the way origin-restrictions work today, if I find an XSS-exploit for /contacts/, I can get to /mail/'s data too. click. OK. Thanks :) We could maybe make an opt-in change to origin to provide further robustness to such setups, by allowing path or some such to be added to the computation of origin. Given the way CORS and such work now I'm not sure how deployable such a change would be, even if opt-in, but it's worth exploring I think. Yeah, I think it is too. One of the scenarios I have in mind is where a few apps from an origin use some common stuff. Which is obviously increasing the attack surface in the way that you mention, but if the same people are forced to use different origins for stuff that is copy-pasted across then I am not sure we are really exposing anything new except a requirement to buy more domains... cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [ime-api] Followups from April f2f discussions
On Fri, 31 May 2013 16:36:52 +0500, Arthur Barstow art.bars...@nokia.com wrote: Hi Mike, All, During WebApps' April 25 discussion about IME API ([Mins]), Mike agreed to a couple of actions for the ime-api spec: [...] Also, did the group decide to not support a webpage creating their own IME, at least not for v1? No, we ran out of time and did not ahve a resolution either way. There were some voices raised against allowing this, and others in favour. Swapping my chair hat for my Yandex cap, we already do this in high-profile sites and would like standards that made it work better. cheers Chaals [Mins] http://www.w3.org/2013/04/25-webapps-minutes.html#item12 [ED] https://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC - working on manifest
This call passes, and a manifest spec has been added to www.w3.org/2008/webapps/wiki/PubStatus cheers Chaals On Tue, 14 May 2013 17:28:58 +0400, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. for the chairs Chaals [1] http://manifest.sysapps.org/ [2] http: 404 (and people ask me why I care where things get published) [3] http://www.w3.org/2012/webapps/charter/Overview.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish Widget Updates as a WG Note; deadline May 23
On Fri, 17 May 2013 03:40:16 +0400, Arthur Barstow art.bars...@nokia.com wrote: It appears there is no longer sufficient interest to move the Widget Updates on the Recommendation track so this is a Call for Consensus to publish this spec as a WG Note and thus formally stop work on it. Go ahead. cheers If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by May 23 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB Original Message Subject:Re: [widgets] Does anyone still care about Widget Updates? Resent-Date:Tue, 14 May 2013 13:33:26 + Resent-From:public-webapps@w3.org Date: Tue, 14 May 2013 09:32:22 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org Scott indicated [1] Wookie implemented Widget Updates and Chaals indicated [2] he would followup with Opera but I couldn't find a response from them in the list archive. Do we have two (complete?) implementations of the spec? Opera, Richard? It's not clear to me if we should drop this spec (i.e. publish as a WG Note) or if there are sufficient resource commitments to continue to advance it along the REC track. Marcos - what is the status of the test suite http://dev.w3.org/2006/waf/widgets-updates/test-suite/? (The Implementation Report doesn't look good http://dev.w3.org/2006/waf/widgets-updates/imp-report/.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0256.html [2] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0261.html On 10/20/12 8:12 AM, ext Arthur Barstow wrote: For various reasons, a Candidate Recommendation of Widget Updates was never published, although the CfC to do so passed and the ED is prepared as such [widget-updates]. Since no one has raised this as an issue, I would like feedback on what we should do with this spec. The main options are: 1) to stop work (and publish a WG Note); 2) to move forward with the CR. I don'tthink it makes much sense to move the spec to CR if we do not have commitments for at least two independent implementations of the CR. Therefore, Implementors should please speak up if they willcommit to implementing this CR. -Thanks, AB [widget-updates] http://dev.w3.org/2006/waf/widgets-updates/ Original Message Subject: CfC: publish Candidate Recommendation of Widget Updates; deadline May 2 Resent-Date: Thu, 26 Apr 2012 16:42:00 + Resent-From: public-native-web-a...@w3.org Date: Thu, 26 Apr 2012 12:41:34 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org CC: public-native-web-a...@w3.org The comment deadline for the Widget Updates LCWD ended April 19. No comments were submitted for that document so this is a Call for Consensus to publish a Candidate Recommendation of the spec using the LC as the basis http://www.w3.org/TR/2012/WD-widgets-updates-20120322/. The Exit Criteria for the CR will be the same as that used for the other widget specs, namely that two or more implementations must pass each test case. This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is May 2 and all comments should be sent to public-webapps at w3.org. -Thanks, AB -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC - working on manifest
On Tue, 14 May 2013 17:28:58 +0400, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. We support this. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: Face to face meeting on Components, 21 June
On Tue, 14 May 2013 17:19:53 +0400, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi folks, Dmitry started talking to people about getting together in the Bay Area to talk through components, and ended up with a number of people interested. Although we are past the deadline for a normal meeting announcement, unless anybody objects it is still possible to hold an official meeting. This would let us use Zakim to provide remote dial-in, and the chairs feel that this is far better than simply having the meeting go ahead pretending not to be a webapps meeting. We are therefore calling for consensus to let this meeting go ahead despite the short notice. I am very happy for the meeting to go ahead. Thanks Dmitry for taking the initiative. cheers Silence will be considered assent, and responses will be taken up to the end of the day (midnight in the last timezone) Tuesday 21 May. Assuming we get the go-ahead, an agenda, dial-in details, etc will be made available, but the topic for the meeting is the Web Components work. for the chairs Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [XHR] anonymous flag
Hi Anne, chair hat on Please stick to the technical discussion without making assertions about people's motives or actions for which you don't have concrete evidence. chair hat off On Fri, 17 May 2013 13:53:08 +0400, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Anonymous mode still seems like useless complexity to me, so I'm still in favour of dropping it. Right. I don't really get the feeling you're considering the arguments carefully and since nobody else seems to be participating here (much like before) I'm not sure this is a good use of our time. Silence is not very useful as evidence nobody cares, since it may also mean everybody agrees (but then, it isn't strong evidence that everybody agrees for similar reasons). Since Hallvord's argument made sense and was in an active discussion it seemed unnecessary to repeat it or me too it, but in the interest of clarity: The OpenID scenario seems to match common real scenarios, and therefore the risk Hallvord identifies seems worth being careful about. With respect to your use case for keeping anonymous I agree with Hallvord. I cannot think of a real use case for a browser-like thing that accepts arbitrary URLs. Could you please provide some more explanation of the real scenarios for this use case? cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: A very preliminary draft of a URL spec
On Mon, 13 May 2013 17:25:23 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Sun, May 12, 2013 at 8:34 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. Given that you're questioning this, I am not questioning whether it is a good idea. I am checking that it will actually get implementation - since a spec of things we think people should do, but they don't and probably won't is just an idea written down. Personally I don't think the Web is just what browsers will implement, since there are things (like microdata) that don't really need the browser at all in order to be important to the web. But in this case, as with most APIs I think browser implementations are particularly important. maybe you want to study HTML's dependencies. Sure, but making life easier for spec authors is not directed at the highest priority group in the hierarchy of audiences (much as I want to do it). It seems that's a problem overall. This draft doesn't go into detail about any of the problems for which HTML started defining URLs by itself in the first place. Sure. As I noted, it is extremely rough, and it is definitely missing more than it includes at this stage. What's wrong with the http://url.spec.whatwg.org/ URL standard. 1. It is apparently not intended to become a stable reference that can be used in situations where fixing every edge case is less important than fixing the content we agree we are looking at. 2. It provides extremely detailed algorithms that certain classes of tools require to work with URLs, at the expense of an easily-read explanation of what is and isn't a URL. 3. It does not provide any kind of license commitment from anyone likely to have patents on the technology described. The first two of these are only problems from a specific set of perspectives, but those perspectives happen to be ones that match real existing needs. I believe that the third is a non-issue in practical terms, given that most of what is specified has been around for long enough to ensure the existence of prior art, but it doesn't hurt to be surer about this. Not invented here? Ironically (given the history of URLs as used on the Web today), that is indeed a defensible explanation of one issue. For reasons including stability of the document content, WHAT-WG living standards are not suitable as normative references for W3C Recommendations. As you note, HTML essentially depends on having a sound reference. (For other mostly technical reasons I believe that RFC 3986 and perhaps to a lesser extent RFC 3987 are not especially suitable either, because the question is equally valid as to what is wrong with them). It is quite possible that the whole problem will go away, and one or more of these specifications will just happily disappear in deference to the rest. However, that's not currently the world we live in, and meeting W3C's interim need seemed a useful investment of some time. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC - working on manifest
On Tue, 14 May 2013 17:28:58 +0400, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. Yandex (still) supports this... cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC - working on manifest
On Tue, 14 May 2013 18:39:34 +0400, SULLIVAN, BRYAN L bs3...@att.com wrote: Chaals, Overall, I think we support this proposal but have some questions I would like to get clarifications on: Minutes of the discussion, to help jog your memory: http://www.w3.org/2013/04/25-webapps-minutes.html#item04 (I apoogise for not linking those from the original CfC message). Maybe I don't recall but is SysApps asking Webapps to take the manifest aspect? Yes. Or is this something Webapps thinks is its right because of the prior focus on Widgets packaging? I don't recall case of a group unilaterally taking back something similar to something else it had worked on in the past. No, the idea is that we all agree on this. If SysApps did approve but in the end disapproved with the result, what recourse would they have? Comment on the spec and say that's terrible, it should be If necessary as formal objections to moving forward. As a practical matter I think nearly all of sysapps members are also represented in webapps. So I would be surprised if there were a real issue. Woudnt it be better to have this as a joint deliverable then? No, there is a handful of frustrating overhead to do that which, if it is as unnecessary as it seems in this case, the people who would have to deal with it (chairs, editors, staff contacts) preferred to avoid. Thanks, Bryan Sullivan -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Tuesday, May 14, 2013 6:29 AM To: public-webapps WG Subject: CfC - working on manifest Hi, at the face to face meeting we agreed to take back the work on a manifest specification for apps, based on the current manifest draft from sysapps [1] that was developed from the proposal [2] included in our charter [3], and to leave the runtime part of the work with Sysapps. This is a formal Call for Consensus on that resolution. Silence will be taken as assent. Responses will be accepted up to the end of the day Tuesday 21 May. for the chairs Chaals [1] http://manifest.sysapps.org/ [2] http: 404 (and people ask me why I care where things get published) [3] http://www.w3.org/2012/webapps/charter/Overview.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: A very preliminary draft of a URL spec
On Mon, 13 May 2013 04:34:32 +0100, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: I made a couple of updates, including a pointer to the readable incarnation of the latest version: https://dvcs.w3.org/hg/webapps/raw-file/default/url/url.html I hope there will be a bugzilla component really very soon And there is one, linked. Further comments are still appreciated, obviously. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
A very preliminary draft of a URL spec
Hi, to close ACTION-693 I scribbled some stuff into a very preliminary draft of a URL spec: https://dvcs.w3.org/hg/webapps/raw-file/81f24bfc5970/url/url.html In the end I didn't copy Anne's spec beyond believeing him about some Unicode points when I was offline. So far I have done nothing at all about an API, and am waiting for some formal confirmation from people who implement stuff that they would like to standardise an API for dealing with URLs. It seems to be a common task, judging from the number of people who seem to have some scrap of code lying around for it, so I expect to hear people say Yes, great idea - although I have been surprised before. As the more astute (read people who look at the spec for a few seconds with at least some level of attention) will notice, this needs work. I would be very pleased to receive comments that help clarify things the spec gets wrong, doesn't specify, or doesn't explain clearly. I hope there will be a bugzilla component really very soon, but I neglected to request one so far. If Mike happens to be reading, I'd be grateful for him to do the magic before I get around to writing the request. In the meantime I guess you should just reply to the thread... And no, it doesn't use futures. Sorry. At some point I will come back with the answer to a request for a way to change that. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: Shelve Web Intents, Web Intents Addendum, Pick Media Intent, Pick Contacts Intent, respond by 17 May (next Friday) (resend)
On Thu, 09 May 2013 13:35:06 +0200, Arthur Barstow art.bars...@nokia.com wrote: On 5/8/13 4:00 PM, ext frederick.hir...@nokia.com wrote: This is a Call for Consensus (CfC) to shelve the Web Intents, Web Intents Addendum, Pick Media Intent, and Pick Contacts Intent specifications (4 specs). Shelving in this case means that we are not sure the specifications will advance along the lines the drafts indicate. As a result we want to be clear to everyone that we may not advance the specifications or that we may change the approach. This does not mean that we have decided not to advance them, just that there is a question as to the direction and/or progression at this point. My general comment is the Consortium's way to state work on a document has ended is to publish a WG Note [WGNote]. So although I agree it is important to clarify the status of Web Intents, it's not clear to me that inventing new process (shelving) is a good approach and it certainly fails the HeartBeat publication requirement [Heartbeat]. It appears to me Web Intents has not changed in seven months [Changelog]. Is there any credible plan including commitment(s) to continue the work? If so, where is that info? Based on the data I have seen so far, it seems like the appropriate next step for Web Intents is to publish it as a WG Note. (I am indifferent about the other specs mentioned above.) I agree with Art here. cheers Chaals (At some future point in time, if there is consensus to do so and the necessary resources are identified, the spec could continue along the TR track). -AB [WGNote] http://www.w3.org/2005/10/Process-20051014/tr.html#q75 [Heartbeat] http://www.w3.org/2005/10/Process-20051014/groups.html#three-month-rule [Changelog] https://dvcs.w3.org/hg/web-intents/log -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Rough summary of minutes from the face to face
Hi, in line with the last item on this list, I committed to make a rough summary of the meeting available to go with the raw minutes. The idea is that people who aren't in the group and weren't there can actually understand what the minutes mean. So here it is. Minutes for Thursday[2] and Friday[2] are available Notes on the topics listed in the minutes: Thursday =Dashboard / PubStatus Webapps maintains a wiki page[4] with the latest knowledge about the specs the group is working on. =App Manifest This is a manifest for packaged (i.e. an installable zip) or hosted (something like pages with an appcache manifest) apps, that provides metadata, an icon, etc. It will be moved from the Sysapps group to the web apps group, who already have it as an explicit charter deliverable. There is a comparison chart[5] of Manifest formats available (but not 100% correct - I believe contributions are welcome. =AppCache There are two initial proposals for fixing it, one from Mozilla[6], and one expected from Google based on Navigation Controller[7]. A key question is whether to have a declarative format (Jonas' proposal has a JSON format that is more or less declarative, Navigation Controller is just script). NB Since the meeting we have started to collect use cases[8] in our Wiki =Indexed DB Hopefully version 1 will be finished in a few months. It seems the last point of disagreement was resolved at the meeting, so we expect a new draft in a couple of weeks that will be more or less the final one. =DOM3 Events - Status Update Keyboard events are known to be difficult to standardise. They don't have enough tests to be confident that they have this part right, and want more. Maybe they will be ready some time around the end of the year. =Web Components There are now 4 specifications that are being developed to allow the creation of custom elements in HTML (and XHTML). The work is led by Dmitry Glazkov from Google. There was an introduction to the various specs, where they fit and where they are up to. =Web Components Security Model, CORS, CSP This was a brief discussion with the Web App Security working group, just describing basic things and meeting the people. =IME This specification is meant to allow use cases including writing a custom IME to replace the system one (like what we do for translate), to make sure that it is easier to interact cleanly with IME when doing something like suggest, etc. There was a joint meeting with an accessibility group, but they were more concerned about building editors (which is very hard) than actual IME (which is moderately hard, unless you can't interact with the native one which makes it horribly hard). =File API Mozilla has a new proposal[9] (as of the morning of the meeting). FileAPI has a few outstanding issues, and is likely to try and ship rather than updating to use futures, ... =WebIDL This probably only matters for people writing specs. WebIDL level 1 is likely to be finished in a few months, with level 2 work ongoing. Friday =Testing, Move to Github The Web needs more tests. There are occasional Test The Web Forward events where people make them. W3C is moving its test infrastructure to use a single github repository for everything. =Progress Events These are used by XHR, the img element, and the Sysapps messaging API. The spec should be finalised in summer =XMLHttpRequest There will be a level 1 specification that describes the interoperable bits, to be finalized this year. Work will continue on level 2, with CORS, authentication, etc, aiming to be done by late 2014. =Coordination (TC39) There has been a discussion asking for more coordination with TC39 for things like making sure that when new APIs are developed at W3C (e.g. in Webapps) there is a notice to them so they can give an early review on things like whether the API looks like normal Javascript, not something mostly designed as if it were in C++ or some other language. The conclusion was Please do more coordination. [1] http://www.w3.org/wiki/Webapps/April2013Meeting [2] http://www.w3.org/2013/04/25-webapps-minutes.html [3] http://www.w3.org/2013/04/26-webapps-minutes.html [4] http://www.w3.org/2008/webapps/wiki/PubStatus [5] http://www.w3.org/community/webappstore/wiki/Manifest [6] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html [7] https://github.com/slightlyoff/NavigationController [8] http://www.w3.org/wiki/Webapps/AppCacheUseCases [9] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0382.html I'm interested in whether this was a useful exercise, by the way. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Proposal for a DOM L3 Events Telecon
On Tue, 07 May 2013 23:07:28 +0200, Gary Kačmarčík (Кошмарчик) gary...@google.com wrote: On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano masay...@d-toybox.comwrote: Hello, sorry for the big delay due to my business trip and holiday week of Japan. I'm available on either schedule. When I join the telecon, how can I join it? Skype or something? Excellent question - I'm wondering the same thing. Will this be using Zakim (http://www.w3.org/2002/01/UsingZakim) and will we have an IRC channel as well? We can certainly ask for a zakim slot. I strongly suggest using IRC as well, especially to help Masayuki follow (which means someone needs to scribe...) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [XHR] test nitpicks: MIME type / charset requirements
On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote: It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? This is how the web is rings like an 'argument from authority'. I'm generally less concerned about those than I believe you are, but I think Julien's questions here are important. It seems to me they promote bad practice (case-sensitive testing of Content-Type). There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). (maybe.) 1. Require the same from everyone. So is there a concrete dominanant implementation that is case-sensitive? Because requiring case-insensistive matching from everyone would seem to meet your requirement above, in principle. And it might even be that with good clear specifications and good test suites that the dominant implementation reinforces a simpler path for authors. Anything else is likely to lead some subset of developers to depend on certain things they really should not depend on and will force everyone to match the conventions of what they depend on I know this has happened on the web for various cases. But it actually depends on having a sufficiently non-conformant implementation be sufficiently important to dominate (rather than be a known error case that is commonly monkey-patched until in a decade or so it just evaporates). I don't see any proof that it is *bound* to happen. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
W3C Brand Survey
Hi folks, W3C has engaged a marketing firm to run a survey about their brand. You may have seen discussion of same on twitter. Apparently now it has been adjusted based on feedback, although I have no idea what the ajustments are. Anyway, they might be grateful if you filled it out: http://pull.erssurvey.com/W3C cheers Chaals (who is also interested in feedback on the survey) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
if the appcache is currently in the process of downloading an update for this appcache. It's also true if the appcache is doing the initial download of the appcached resources. The download function allows a website to download an update for an appcache object even if the user isn't currently using that appcache. The cancelDownload function allows such an update to be cancelled, either if the website itself triggered the download, or if the UA triggered it either by the user browsing to a page that used that appcache, or if it thinks the user is using the cache often enough that it's keeping it up-to-date. The lastUpdateCheck attribute and checkForUpdate function lets a page trigger a manual update check. This is useful for security conscious pages that want to make sure that an update is rolled out immediately when it's available. Right now some websites hand-roll this functionality by checking using an XHR object to check in with the server. This is basically the whole thing. Below are some additional implementation requirements as well a pile of open questions (some of which are basically a brain-dump so please ask if they are incomprehensible). Implementation requirements: If update fails, don't throw away resources but rather re-attempt to download the missing ones at next update time. Can cache URLs on any server, but never captures cross-origin URLs. The URLs can be cross-origin from the manifest, but not cross-origin from the HTML page that links to the manifest. I.e. the origin of an AppCache is determined by the origin of the HTML page that created it. HTML-pages can't be cross-origin from that. The expiration attribute for the manifest overrides the caching headers for the manifest URL. Allow cross-origin manifest using CORS (or other opt-in) Don't use heuristics for estimating expiration dates for URLs cached in the appcache. Explicit headers are honored (unless overridden by the appcache manifest), but heuristics based on last-modification dates or similar are not allowed. Outstanding questions: * What should happen if an appcache caches index.html, but index.html links to another cache? If it doesn't link to any cache we should probably treat that as if it linked to the cache, but what to do if it explicitly links to another cache? * What should happen if a version property exists and contains the same value, but resources have been added or removed. Or have had their etags/last-modified changed. * Should we add support for optional urls? I.e. once which are ok if they fail to download? If so, do we need to specify handling for a failed download (use old version vs. use 404) * Rather than using the map feature to handle cache-busting URLs, should we introduce a list of URLs for which to ignore query parameters? * Is a capture feature needed? I.e. a list of URLs which if the user navigates to, the appcache should be used. This would have to be a subset of the set of URLs that the appcache has cached or mapped. * the map-to-worker feature could allow setting the worker property to a worker-url in order to support multiple httpworkers. Needed? * How do we solve moving appcache manifests? Can that even be done while also supporting the browser updating the appcache automatically without the user visiting the website? * This is not solving Microsoft's use case of having multiple apps on the same URL. * This doesn't contain a check network, otherwise use cached resource ability. Could be added through additional map rules if we need it. * Do we need some feature to avoid getting broken sites if we're downloading an appcache just as the app is being updated - how about a notion of this resource is compatable with manifest etag W/rev-5. either in the representation or it's HTTP headers. * We could add the ability to say force revalidate on the urls in cache. * Do we need the captive-portal-detection feature? * How do we support comments in the manifest? One way would be to use some for of extended JSON which supports comments. Another way would be to advocate people sticking properties named // in the manifest. * Should the main appcache be considered ready to use even if all submanifests are not yet downloaded? This could enable loading one part of a website even if later sections are still loading. [1] http://etherpad.mozilla.org/appcache [2] https://github.com/slightlyoff/NavigationController [3] https://github.com/slightlyoff/DOMFuture / Jonas -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
ZIP archive API?
Hi all, at the last TPAC there was discussion of a ZIP archive proposal. This has come and gone in various guises. Are there people currently interested in being able to work with ZIP in a web app? Are there implementors and is there an editor? cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: roadmap for inclusion of people with cognitive disabilities
Hi Lisa, On Sun, 21 Apr 2013 08:52:38 +0300, lisa.seeman lisa.see...@zoho.com wrote: Over the weekend I put up a (very) draft outline for a roadmap for inclusion of people with cognitive disabilities. See http://athenatechnologies.org/RoadmapCog01.html. The most relivent part is probebly the specification suggestion at http://athenatechnologies.org/RoadmapCog01.html#specification. Do you think we should set some time at the FTF to see how WebAPPs can fit in? Hi Lisa, After talking to my co-chair, we believe are not ready to schedule WebApps time for this. The draft is at too early and too conceptual a stage so far. Web Apps generally works on a more or less concrete proposal for a given API or set of APIs (and assocaited markup as relevant). We don't think the group has the necessary expertise and understanding to be an effective place to develop the work from its current stage. If you will be at the meetings I encourage you to talk to *people* from Web Apps, and explain the direction you are working in, to see if they can offer insight or if you can offerit to them. But I think that at this stage you should be developing this further in WAI before coming back to Web Apps with a potential proposal for work. (There may be resistance there to some of the things you are aiming to do, but it is less than in other places, and there is more expertise there than in other parts of W3C). Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)
of downloading an update for this appcache. It's also true if the appcache is doing the initial download of the appcached resources. The download function allows a website to download an update for an appcache object even if the user isn't currently using that appcache. The cancelDownload function allows such an update to be cancelled, either if the website itself triggered the download, or if the UA triggered it either by the user browsing to a page that used that appcache, or if it thinks the user is using the cache often enough that it's keeping it up-to-date. The lastUpdateCheck attribute and checkForUpdate function lets a page trigger a manual update check. This is useful for security conscious pages that want to make sure that an update is rolled out immediately when it's available. Right now some websites hand-roll this functionality by checking using an XHR object to check in with the server. This is basically the whole thing. Below are some additional implementation requirements as well a pile of open questions (some of which are basically a brain-dump so please ask if they are incomprehensible). Implementation requirements: If update fails, don't throw away resources but rather re-attempt to download the missing ones at next update time. Can cache URLs on any server, but never captures cross-origin URLs. The URLs can be cross-origin from the manifest, but not cross-origin from the HTML page that links to the manifest. I.e. the origin of an AppCache is determined by the origin of the HTML page that created it. HTML-pages can't be cross-origin from that. The expiration attribute for the manifest overrides the caching headers for the manifest URL. Allow cross-origin manifest using CORS (or other opt-in) Don't use heuristics for estimating expiration dates for URLs cached in the appcache. Explicit headers are honored (unless overridden by the appcache manifest), but heuristics based on last-modification dates or similar are not allowed. Outstanding questions: * What should happen if an appcache caches index.html, but index.html links to another cache? If it doesn't link to any cache we should probably treat that as if it linked to the cache, but what to do if it explicitly links to another cache? * What should happen if a version property exists and contains the same value, but resources have been added or removed. Or have had their etags/last-modified changed. * Should we add support for optional urls? I.e. once which are ok if they fail to download? If so, do we need to specify handling for a failed download (use old version vs. use 404) * Rather than using the map feature to handle cache-busting URLs, should we introduce a list of URLs for which to ignore query parameters? * Is a capture feature needed? I.e. a list of URLs which if the user navigates to, the appcache should be used. This would have to be a subset of the set of URLs that the appcache has cached or mapped. * the map-to-worker feature could allow setting the worker property to a worker-url in order to support multiple httpworkers. Needed? * How do we solve moving appcache manifests? Can that even be done while also supporting the browser updating the appcache automatically without the user visiting the website? * This is not solving Microsoft's use case of having multiple apps on the same URL. * This doesn't contain a check network, otherwise use cached resource ability. Could be added through additional map rules if we need it. * Do we need some feature to avoid getting broken sites if we're downloading an appcache just as the app is being updated - how about a notion of this resource is compatable with manifest etag W/rev-5. either in the representation or it's HTTP headers. * We could add the ability to say force revalidate on the urls in cache. * Do we need the captive-portal-detection feature? * How do we support comments in the manifest? One way would be to use some for of extended JSON which supports comments. Another way would be to advocate people sticking properties named // in the manifest. * Should the main appcache be considered ready to use even if all submanifests are not yet downloaded? This could enable loading one part of a website even if later sections are still loading. [1] http://etherpad.mozilla.org/appcache [2] https://github.com/slightlyoff/NavigationController [3] https://github.com/slightlyoff/DOMFuture / Jonas -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [webcomponents] writing some pages that use webcomponents, and blogging along the way
On Wed, 27 Mar 2013 23:16:11 +0100, Scott Miles sjmi...@google.com wrote: This is great stuff Mike, thanks for making it available. I think we are all #facepalm at the notion of self-documenting component files, very clever. Hmm. We built the BEM framework for templating with multiple technologies, and one of its features is allowing multiple technology - CSS, JS, HTML, XSLT, etc, which we use to provide self-documentation with markdown for wikis. But I still didn't get far enough into this to connect those dots. With a bit of luck I can get someone from the front-end team who does this by reflex to have a look, because they might have some more help to add. making things that use components and custom elements is proving extremely fun =) Music to my ears. Yeah, it's nice when the stuff we do turns out to be useful in the real world :) Which mostly implies props to the folks who did the hard work... cheers Chaals Scott On Tue, Mar 26, 2013 at 11:48 AM, Mike Kamermans niho...@gmail.com wrote: Hey all, I've been playing with web components and custom elements for a bit, blogging about my understanding of it at http://pomax.nihongoresources.com/index.php?entry=1364168314 and writing a demo for the Mozilla webmaker dev group to see what we can do with them, which is hosted at http://pomax.github.com/WebComponentDemo/ This demo has a stack of custom elements that all tack onto a media element on the page, if there is one, with two pages, one with a media element, the other with an image instead, but identical code outside of that difference, using the components defined in http://pomax.github.com/WebComponentDemo/webmaker-components.html One thing we're wondering about how to play with is self-documenting components. Was there already work done on this, or has anyone else already played with that idea? Right now we've hardcoded the documentation as plain HTML, trying to come up with a nice way of autogenerating it by having some JS that checks whether the components were loaded as the document itself and if so, generate the documentation from the element definitions, but finding a clean way to include a general description as well as attribute documentation is tricky. If anyone has good ides for doing this, I'd be delighted to hear from you! Also, if there's anything on those pages that we did wrong, or that can be done better, I'd also love to hear from you. These things feel like game-changers, and making things that use components and custom elements is proving extremely fun =) - Mike Pomax Kamermans -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
fixing appcache...
Hi, we've been talking about appcache inside Yandex. Actually we're not at all sure that appcache is what we really want, so much as an API to use the normal cache better. Right now we prefer to use local storage, since appcache isn't actually helpful. Anyway, here are some use cases: 1. Initial loading. Our SERP (and Yandex main page www.yandex.ru) uses embedded styles and scripts for faster loading than with multiple requests for styles/scripts/... But users load them every time they visit the results page, because the browser doesn't cache it. It would be nice on the first visit to extract the styles and scripts and store them in the cache. 2. Bundles. Sometimes we need to load several resources (js/css/json/...) before we can actually show something to user. Like a dialog, or another complex control. Or if it's a single page application before change page. Again, it's often faster to make one request than several, but it would be even faster if we could then cache them separately: HttpCache.store(url1, content1); HttpCache.store(url2, content2); ... So that later we can use the files as usual (script, link...). 3. Diffs (delta updates) Every static file (js/css/...) has a version, e.g. http://yandex.st/mail/1.3.8/mail.js Whan we release a new version our users have to download it. It could be hundreds of kilobytes (or more). But the difference between versions is often not very big. So we want to make delta updates. It would be nice if we could download the diff, apply it in the browser and store the update in cache e.g.: var oldVersion = '1.3.8'; var newVersion = '1.3.9'; var oldContent = HttpCache.get(oldUrl); var newContent = applyPatch(oldContent, patch); HttpCache.store(newUrl, newContent); 4. Preloading. Well, we can use normal xhr for that but maybe we can do more with HttpCache. Basically we want methods for loading resources, storing them in cache, fetching them from cache, checking if something is in the cache, ... cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of Input Editor Method (IME) API; deadline March 28
On Thu, 21 Mar 2013 17:39:46 +0100, Arthur Barstow art.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish a new WD of Input Editor Method (IME) API, using the following ED as the basis: https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the _contents_ of the WD. Please publish... chaals If you have any comments or concerns about this proposal, please reply to this e-mail by March 28 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, AB -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of Clipboard API and events; deadline March 26
On Tue, 19 Mar 2013 23:12:08 +0100, Arthur Barstow art.bars...@nokia.com wrote: Hallvord has made a number of changes since the last publication of Clipboard API and events (last published in Feb 2012). As such, this is a Call for Consensus to publish a new WD of this spec using the ED as the basis: http://dev.w3.org/2006/webapi/clipops/clipops.html Please do. cheers Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the _contents_ of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by March 26 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, AB -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: move WebApps' test suites to Github; deadline March 22
On Fri, 15 Mar 2013 17:40:18 +0100, Arthur Barstow art.bars...@nokia.com wrote: As you probably know, the HTMLWG recently moved its test suite to GitHub (GH). Tobie, Robin, Odin, Ms2ger and others propose WebApps do the same and this is a Call for Consensus to do so. We support the move. cheers Odin defined the new testing process for GH in [Proposal] and this will replace most, if not all, of the testing processes already agreed [Testing]. (Some things like using testharness.js will remain the same.) Assuming this CfC passes: * [Proposal] will likely be updated as we gain experience with GH and may be replaced by more general information like https://github.com/w3c/web-platform-tests/blob/master/README.md. * The root of the repository will be the same as HTML(WG): https://github.com/w3c/web-platform-tests and each of WebApps' specs will have its own subdir. For example the Web Storage test suite would be https://github.com/w3c/web-platform-tests/webstorage/. * WebApps' hg test repository https://dvcs.w3.org/hg/webapps/ will become Read-only (i.e. write access will be turned off). * Tobie, Robin, Odin and Ms2ger will do the work of the move (Test Facilitators are not required to do the work). If you have any comments or concerns about this CfC, please reply to this e-mail by March 22 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB [Proposal] http://www.w3.org/wiki/Webapps/Submitting_tests [Testing] http://www.w3.org/2008/webapps/wiki/Testing -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: security model of Web Components, etc. - joint work with WebAppSec?
On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad bh...@paypal-inc.com wrote: Is there time available on the April F2F agenda for discussion of this? If not in WebApps, would relevant WG members be willing to join us if we found time to discuss in WebAppSec’s timeslot Thursday or Friday? http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics Shows agenda wide open so far. Should we just plop something into one of the slots? Yep, that's a reasonable thing to do... cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [admin] Towards XHR The Attorney's Edition
On Thu, 28 Feb 2013 15:46:34 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
Last year we agreed to stop work on the baseline XHR spec because no
one was willing to work on that version of the spec. Since then, the new
XHR Editors agreed to work on a baseline version as well as to continue
to work on the `bleeding edge` version.
One goal of the baseline version is to specify features that are widely
implemented and deployed today. As such, it _should_ be relatively
straight forward to move this version to LC and then to CR-PR-REC and
thus finalize the IP commitments by WebApps' members. (There are no
firm IP commitments for XHR until a REC is published.)
My proposal is to use the XMLHttpRequest1 shortname for the baseline
version, the same shortname as the XHR WG Note published 17 January 2012
[XHR-Note]. Thus, the first TR publication of the new baseline spec
would replace the WG Note (although the dated version of the WG Note
[XHR-Note-Dated] will of course be untouched).
I don't feel strongly about the title of the baseline version. Some
options: XMLHttpRequest Baseline, XMLHttpRequest Level {0,1} and I
could live with something like XMLHttpRequest: The Attorney's Edition
[v{0,1}].
Comments?
Much as I love it, I don't think The attorney's edition is a helpful
addition to the title. Besides, I think it is valuable for people for
reasons other than just fulfilling the patent policy requirements.
Since we expect this to basically be the stuff in what used to be called
XMLHttpRequest level 1 that is actually widely implemented (ie really
standard, not just the things we think should be), I think XMLHttpRequest
level 1 makes a pretty sensible real name.
cheers
Chaals
-Art and Chaals
[XHR-Note] http://www.w3.org/TR/XMLHttpRequest1/
[XHR-Note-Dated]
http://www.w3.org/TR/2012/NOTE-XMLHttpRequest1-20120117/
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
Face to face meeting registration
Hi folks, Registration at the meeting is required. The #registration page is now available (thanks PLH), and linked from the #meeting page on the wiki. Note that we expect to finish at lunchtime on Friday, so people can leave in the afternoon to catch flights. #registration: https://www.w3.org/2002/09/wbs/42538/webapps-april-2013/ #agenda http://www.w3.org/wiki/Webapps/April2013Meeting cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: DRM nonsense in HTML
On Tue, 12 Feb 2013 17:20:56 +0100, Tobie Langel to...@fb.com wrote: On 2/12/13 5:05 PM, Florian Bösch pya...@gmail.com wrote: DRM does not belong into HTML, nor into any kind of W3C standard. [...] This is the wrong mailing list. You might want to look at http://www.w3.org/html/wg/lists/. Exactly. Discussion on this list should be restricted to work items of this group - http://www.w3.org/2008/webapps/wiki/PubStatus - or proposals for new work items. Things other groups should or should not do are explicitly off-topic. for the chairs Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Allow ... centralized dialog up front
olution has proven to be both flexible and secure. Handling permissions up front has three unwanted effects: 1. Users tend to not read the upfront permission settings that much thus often accidentally granting more privileges than they would like to. That's a security and privacy issue. 2. Users tend to reject apps which have too many permission requests or permission requests that feel out of scoop of the app. Eg. A chess game asking for permissions to use the camera is rather off-putting until you realize it uses it to take snapshots of a chess-board and suggest next moves. This awareness generally comes with app usage, or because you're aware of the feature set of the app through information provided by the developer (marketing) or third parties (reviews, friends, etc.). 3. Upfront permission lists rapidly get out of sync with real application requirements. What happens then? In fact, Upfront permission requirement only really makes sense when the user has already built a relationship of trust with the developer of the application or trusts a third party that has means of enforcing good behavior from the app developer (e.g. through an app store system). A hybrid approach that considers upfront permissions as hints of permission requirements to come offers the best of both worlds. It allows developers to ask permissions upfront for things that make sense given the context (e.g. a camera app would require camera access upfront) and at a later stage for features that might not be so obviously connected to the app's main use case or present a bigger risk for the user. It also allows the User Agent to treat these hints as it wishes, e.g. by prompting the user upfront, by automatically granting some permissions using various kinds of heuristics, or by deciding to only prompt the user when the feature is actually going to be used. It is worth noting that the developer will still need to code defensively for such an approach, as the user (or user agent) might very well not grant all permissions upfront and still require prompting at a later stage. Previously granted permissions might also be recalled at any time. This approach doesn't require the User Agent to let the developer know which permissions the user has granted upfront nor would that be useful given permissions can change at any time. --tobie -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Re: Allow ... centralized dialog up front
On Fri, 01 Feb 2013 11:48:33 +0100, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com wrote: I would propose to centralize this and make it an up-front dialog remembered for a site such that: (Your proposal is broadly in line with the common thinking of browser makers today, but...) That kind of bulk approach does not work. Users don't understand what's going on. That's what research shows. To be fair, we've generally presented the options in ways that are over-technical. This application will have access to your location is not as clear as This page can tell anyone where you are and where you go while it is open ... If you enter a credit card number in this page, anyone can 'listen in' and copy it compared to the certificate is issued by an unrecognised authority... etc Browsers have got a lot better at this over the last few years, and it is probably time to do some more research. To what extent are we sure users understand a prompt about for example web storage? That is the question. As Anne says, the research generally concludes we're pretty sure most of them didn't even read the message. (This has been discussed in the past too, I suggest you read the archives of this list, public-web-notifications maybe, and probably public-device-apis.) It certainly has been discussed but not really resolved - also, UI paradigms and usability research evolve, so I guess it's natural to revisit this discussion now and then. Yes. It does of course lie somewhat outside of the scope of most W3C work, given that it is about a specific aspect of browser UI, Yep. There was some security work done a few years ago specifically looking at the sort of things that users understood, which recommended that for security it is helpful to have consistent presentation across browser UI. While it is useful to do the research, and share results, especially where we can show that consistency is important, how to implement this is basically a user agent implementation question. And it has evolved over time. which might be one of the reasons why it's so hard to find good solutions. Maybe, but I think the main reason is that it is a very hard problem. (One secondary reason is that browser vendors generally don't pay enough attention to really thinking hard about user experience and usability as an evidence-based and evolving field, where it is almost impossible to do too much work - but very possible to overrun any budget you can come up with). cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Allow ... centralized dialog up front
On Fri, 01 Feb 2013 12:59:35 +0100, Florian Bösch pya...@gmail.com wrote:On Fri, Feb 1, 2013 at 12:56 PM, Arthur Barstow art.bars...@nokia.com wrote: Web Security Experience, Indicators and Trust: Scope and Use Cases http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/Yeah, has anybody actually even read that notes TOC, you can scroll straight to section 2.6:http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/#trust-decision-managementLots of people, lots of times. It is one of the better-known truisms in designing security interfaces, and a really well-known principle for managing security on the Web.It doesn't invalidate what Anne said - but what Anne said doesn't invalidate your suggestion either. As I said, what you propose is what most of the industry seems to already be moving towards.Having it written in a new specification doesn't seem to make much sense - it is already there. And it is one of they key ideas repeated almost every time security or privacy comes up in relation to a specification.cheersChaals No matter how well security context information is presented, there will always be users who, in some situations, will behave insecurely even in the face of harsh warnings. Thus, the Working Group will also recommend ways to reduce the number of situations in which users need to make trust decisions. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Allow ... centralized dialog up front
OK, I think I'm getting this now.On Fri, 01 Feb 2013 13:39:34 +0100, Florian Bösch pya...@gmail.com wrote:The idea is to allow vendors to improve their UX (if they're so inclined) by allowing developers (if they're so inclined) to use a central, up front API. For lack of a better term let's dummy it as "requestAPIs" and it would work a bit like this:
var gotAPIs = function(mandatorEnabled, optionalAPIs){ if(!mandatoryEnabled){ ...; return;} if(optionalAPIs.desktopNotification){ ... }}
Look at the feature element in the Widget stack, or permissions property in Chrome/Yandex extensions, or in Mozilla apps [3].[1]http://www.w3.org/TR/widgets/#the-feature-element-and-its-attributes[2]http://developer.chrome.com/apps/declare_permissions.html[3] https://marketplace.firefox.com/developers/docs/manifestsRight now, although this stuff is in Webapps charter and we have delivered specs, mozilla seems to prefer to do the work in Sysapps, Google and Opera seem uninterested, and Apple has a habit of forcing Patent Groups, which so far tend to delay but not derail the work.I'd be happy to work on this in either group, or it *may* (I haven't looked) fall within the charter of the webapps-security group.document.requestAPIs({mandatory: ['fullscreen', 'pointerlock', 'WebRTC', 'Webcam', 'geoLocation'], optional: ['desktopNotification', 'keyboardSymbolResolution', 'peer2peer'], onAPIs: gotAPIs});
How a vendor presents that to a user is the vendors choice, but the semantic lets the vendor use that information for good UX. If a developer wants to use that API is up to the developer, if he doesn't, he'd still go down the "popup by popup" UX, that's up to the developer. But at least it would be possible way forward.
Right now vendors look at a page and can often heurisitically generate a permission request that is either consolidated, or depends on actual usage. For example, and app may be able to use my camera, location, audio, orientation and contacts db, but not necessarily need to use them all. One of the patterns clear with Android apps (which use a central dialogue like you are proposing) is applications that request a massive number of permissions that are irrelevant to their main purpose, and which effectively train users to ignore the whole question and click yes. :(cheersChaalsOn Fri, Feb 1, 2013 at 1:27 PM, Florian Bösch pya...@gmail.com wrote:
I don't propose writing into a specification how the dialog would look like. There does need to be a specification however on the API that developers can use to indicate an applications desire to use any of the dozen or so restricted APIs.
On Fri, Feb 1, 2013 at 1:25 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote:
On Fri, 01 Feb 2013 12:59:35 +0100, Florian Bösch pya...@gmail.com wrote:
On Fri, Feb 1, 2013 at 12:56 PM, Arthur Barstow art.bars...@nokia.com wrote:
Web Security Experience, Indicators and Trust: Scope and Use Cases
http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/Yeah, has anybody actually even read that notes TOC, you can scroll straight to section 2.6:http://www.w3.org/TR/2008/NOTE-wsc-usecases-20080306/#trust-decision-management
Lots of people, lots of times. It is one of the better-known truisms in designing security interfaces, and a really well-known principle for managing security on the Web.
It doesn't invalidate what Anne said - but what Anne said doesn't invalidate your suggestion either. As I said, what you propose is what most of the industry seems to already be moving towards.
Having it written in a new specification doesn't seem to make much sense - it is already there. And it is one of they key ideas repeated almost every time security or privacy comes up in relation to a specification.
cheersChaals
No matter how well security context information is presented, there will always be users who, in some situations, will behave insecurely even in the face of harsh warnings. Thus, the Working Group will also recommend ways to reduce the number of situations in which users need to make trust decisions.
-- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
-- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Allow ... centralized dialog up front
On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch pya...@gmail.com wrote:On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt adriennef...@gmail.com wrote: My user research on Android found that people have a hard timeconnecting upfront permission requests to the application feature that needs the permission. This meant that people have no real basis by which to allow or deny the request, except for their own supposition. IMO, this implies that the better plan is to temporally tie the permission request to the feature so that the user can connect the two. In some circumstances this works, in others, it does not. Consider that not every capability has a UI-flow, and that some UI flows are fairly obscure. More often than not a page will initiate a flurry of permission dialogs up front to get it out of the way. Some of the UI-flows to use a capability happen deep inside an application activity and can be severely distracting, or crippling to the application. If a developer wants to use the blow-by-blow popup dialogs, he can still do so by simply not calling an API to get done with the business up front. But for those who know their application will not work without features X, Y, Z, A, B and C there is no point. They already know their app is not going to work. They already know they would have to pester the user 6 times with successive popups. They already know that they will severely distract the user or cripple themselves by making the user click trough 6 popups whenver it becomes necessary. They already know that 80% of their users will quit their page after the 3rd popup asking random questions. Why should there not be a way to prevent all that from happening?The stock answer (and I think it is too glib, and we should be thinking harder about this) is"because those who just want the user to agree to give away their security and privacy will be able to rely on permission fatigue. Which they can create, by getting sufficient users to download versions of popular stuff that requests unreasonably complicated permissions. So consolidating everything will make the system effectively useless".cheers Chaals-- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Allow ... centralized dialog up front
On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch pya...@gmail.com wrote:Repetitive permission dialog popups at random UI-flows will not solve the permission fatique any more than a centralized one does. However a centralized permission dialog will solve the following things fairly effectively: - repeated popup fatiqueSure. And that is valuable in principle.- extension of trust towards a site regardless of what they ask for (do I trust that Indie game developer? Yes! Do I trust google? No! or vice versa)I don't think so. As Adrienne said, as I have experienced myself, without understanding what the permission is for trust can be reduced as easily as increased.- make it easy for developers not to add UI-flows into their application leading to things the user didn't want to give (Do we want a menu entry "save to local storage" if the user checked off the box to allow local storage? I think not.)- make it easy for developers to not waste users time by pretending to have a working application, which requires things the user didn't want to give. (Do we really want to offer our geolocated, web-camera using chat app to users who didn't want to give permission to to either? I think not. Do we want to make him find that out after he's been entering our UI-flow and been pressing buttons 5 minutes later? I think not.) These are not so clear. As a user, I *do* want to have applications to which I will give, and revoke, at my discretion, certain rights. Twitter leaps to mind as something that wants access to geolocation, something I occasionally grant. for specific requests but blanket refuse in general.The hypothetical example you offer is something that in general it seems people are happy to offer to a user who has turned off both capabilities.I think the ability for a page to declare permission requests in a standard way, the same as applications and extensions, is worth pursuing, because there are now a number of vendors using stuff that seems to only differ by syntax.The user agent presentation is a more complex question. I believe there is more research done and being done than you seem to credit, and as Hallvord said, I think this is an area where users evolve too.For the reasons outlined already in the thread I don't think an Android-style "here are all the requests" is as good a solution in practice as it seems, and there is a need for continued research as well as implementations we can test.cheersChaalsOn Fri, Feb 1, 2013 at 3:22 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch pya...@gmail.com wrote: On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt adriennef...@gmail.com wrote: My user research on Android found that people have a hard timeconnecting upfront permission requests to the application feature that needs the permission. This meant that people have no real basis by which to allow or deny the request, except for their own supposition. IMO, this implies that the better plan is to temporally tie the permission request to the feature so that the user can connect the two. In some circumstances this works, in others, it does not. Consider that not every capability has a UI-flow, and that some UI flows are fairly obscure. More often than not a page will initiate a flurry of permission dialogs up front to get it out of the way. Some of the UI-flows to use a capability happen deep inside an application activity and can be severely distracting, or crippling to the application. If a developer wants to use the blow-by-blow popup dialogs, he can still do so by simply not calling an API to get done with the business up front. But for those who know their application will not work without features X, Y, Z, A, B and C there is no point. They already know their app is not going to work. They already know they would have to pester the user 6 times with successive popups. They already know that they will severely distract the user or cripple themselves by making the user click trough 6 popups whenver it becomes necessary. They already know that 80% of their users will quit their page after the 3rd popup asking random questions. Why should there not be a way to prevent all that from happening? The stock answer (and I think it is too glib, and we should be thinking harder about this) is"because those who just want the user to agree to give away their security and privacy will be able to rely on permission fatigue. Which they can create, by getting sufficient users to download versions of popular stuff that requests unreasonably complicated permissions. So consolidating everything will make the system effectively useless". cheers Chaals-- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
RfR: Proximity Events (DAP) Last Call
The Device API Working Group [1] has published a Last Call working draft of the Proximity Events specification today, 6 December 2012 [2] and requests review comments from this group, among others. The draft is available at http://www.w3.org/TR/2012/WD-proximity-20121206/ The Last Call period ends 24 January 2013 (7 weeks to account for the holidays) - please send comments to the DAP public mailing list with [proximity LC] at the start of the Subject line. [1] http://www.w3.org/2009/dap/ [2] http://www.w3.org/News/2012#entry-9649 Cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Mon, 03 Dec 2012 14:07:40 +0100, Ms2ger ms2...@gmail.com wrote: On 12/03/2012 01:44 PM, Charles McCathie Nevile wrote: Just a reminder: this group is a forum for discussion of technical specifications, and follows the existing W3C process. Discussion of what process *should* be is off topic here. I find it unfortunate that you try to cut off discussions relevant to technical issues with our specifications by calling them process discussions. And we the chairs find it unfortunate that you continue to bombard the working group with discussions of and objections based on process, simply because there are technical considerations to what the process of this organisation should be. This is a formal warning. The discussion is off topic, so please desist. From my understanding reasons for the practice include the following: - W3C aims to provide stable specifications that can be used as references which won't change. This is a general underpinning of its policy for specifications published as TR documents. Making a normative reference to an unstable document obviously defeats this purpose. The argument that TR documents are in some way more stable than other documents is simply fallacious. This has been discussed at length here and in other venues; By stable, we mean are formally published as a stable reference. The technical issues this brings up, as I said in this thread, are known. I won't go into it again. Thank you. In this working group, please apply the same approach to other discussions of W3C process. Furthermore, I should point out that referencing the TR draft of WebIDL would (if anybody tried to implement the TR spec and its TR references; nobody does, of course) lead to a specification that is not implementable. The WebIDL used in XHR is not valid according to the 19 April 2012 CR of WebIDL. [...] [chaals' example of currently unwritten requirements] I find this comparison, in particular, to be unhelpful and rather rude. I'm sorry. If you'd like to discuss this further, in an appropriate forum, I will endeavour to find a comparison more to your taste. Otherwise, please accept my apologies. Nobody is suggesting using expletives in specifications. The only parallel I can imagine with the current situation is that some people seem offended by the existence of the WHATWG, and for some reason want to make sure no W3C publication ever mentions it. This is a misrepresentation of the facts, unless you have special knowledge of some person's individual motivation. In particular, both the chairs and many others have repeatedly expressed that credit should be given where credit is due, and in particular that appropriate references to WHAT-WG documents on the same topic are the sort of thing that should be in the spec, because that kind of reference is expected of socially competent adults. This is a currently accepted consensus of the group, and I do not recall having seen any dissent. It is also an extension of the discussion, and an inappropriate ascription of motives to others. The question here is whether WHAT-WG documents are suitable as *normative references for W3C specifications*. I had hoped we had been able to come to a somewhat more mature relationship between this WG and the WHATWG after the recent discussions about attribution, but changes like this make me lose confidence in the goals of the W3C Team and the chairs of this WG on this matter. That is unfortunate. I maintain my technical objections to the publication. The chairs maintain that your objection is not technical. In any event, we draw your attention to the sentence [[[ Consensus is not a prerequisite for approval to publish; the Working Group MAY request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements. ]]] - http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd in section 7.4.1 of the process document. We note your objection, and resolve to publish the Working Draft. for the chairs Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Tue, 04 Dec 2012 01:50:35 +0100, Ian Hickson i...@hixie.ch wrote: ... This is just plagiarism. Ian, this accusation against colleagues of yours working in good faith is offensive, and it is untrue. It is therefore inappropriate for this mailing list. I will repeat, since you may have missed it, what I said [1] in an earlier side-branch of this thread discussing how credit should be given to Anne for his work on this specification. The general principle is that we expect to give credit for contribution (but recognise that this is always an approximation). This is orthogonal to W3C's referencing policy for specifications. The process, and W3C's publication rules, are off-topic for this working group. If you want to discuss issues, please do so in the relevant forum. You are able to write to the Advisory Board, request Google's Advisory Committee representative to raise the issue. Anybody can participate directly in the W3Process Community Group[3]. [[[ In particular I note consensus that we don't want to misrepresent contribution to the work. I considered it obvious - it is how civil adults work and it is an accepted part of W3C process and practice. On Sat, 24 Nov 2012 00:34:02 +0400, Glenn Adams gl...@skynav.com wrote: Is Anne the *sole* author? As I understand it, Anne wrote the words of various specifications. In other words, the person whose artistic expression is reflected in the document. Although various bits of boilerplate are just pattern repetition. he also did a significant proportion of the testing, thinking, and developing the content at a conceptual level. But no, I believe other people did parts of this work, unless Anne simply ignored anything other people had already done, or we accept that by repeating other people's work he has produced original work, which runs against what I believe is a common definition. In particular, other people contributed information to Anne as members of the Webapps working group - with an understanding that the resulting documents would be published by that working group. To try and whitewash that out of history seems to be somewhere down the slippery slope of plagiarism. Nobody has suggested that the contributions of those beyond the working group should be ignored or misrepresented, the arguments have been about the precise editorial details of how that is done - what is generally called wordsmithing or bikeshedding (depending on whether it is us or them doing it). ]]] [1] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0574.html [2] http://www.w3.org/community/w3process/ I note that I have now raised the issue of pubrules with Philippe le Hegaret, and expect that the document will be clarified. Since W3C works by consensus of its stakeholders, this is unlikely to happen instantly, but I will continue to follow the issue. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
think it's a goal to replace all links to point to W3C resources even when they are strictly worse. The claim that this is *strictly* worse relies on a particular restriction of use cases. That's not in the W3C pub rules or a good idea. It isn't written there, although it has been applied for as long as I can remember (which stretches back to before pubrules was a document). To the extent W3C thinks this should apply, they should indeed write it in there, since it has recently become contentious. Pubrules doesn't, as far as I know, prohibit f-bombs in specs. W3C working group members, including editors, are expected to be socially competent adults, which is a catch-all for what would otherwise be an endless set of statements like people who know not to use the 'f word' in a spec even without a written rule. (If I recall correctly this is in section 3.1 of the process document. It certainly isn't worth looking up). It is probably worth yet more discussion. It turns out that at least some W3C members consider this a live issue. But the membership, perhaps because it is broader than people in this conversation or even this group, tend to take a broader view of who needs and uses specs which leads to accepting a wider range of use cases. This in turn means that while the costs of W3C's approach are actually understood, the existing (legacy?) consensus of the members has been that it is a price worth paying. And so long as that is the case, this group is a forum for technical discussion, and follows the existing W3C process. If you want to play W3C politics, members have an obvious forum - talk to your AC rep. Note that there is also a Community Group where W3C process and practise is the topic, and anyone can contribute. That gets the attention of the editor of the W3C process document (me), the Advisory Board (who are responsible for the process document and advise W3C on what should be looked at as best practice), and the CEO of the W3C, among others. for the chairs Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: Selectors API Level 1 Test Suite; deadline November 23
On Fri, 16 Nov 2012 15:48:28 +0400, Arthur Barstow art.bars...@nokia.com wrote: The RfR for the Selectors API Level 1 test suite passed WebApps' testing group's review (see below), and according to the agreed #Approvalprocess, this now means a group wide review should be done. As such, this is a CfC for this test suite: http://w3c-test.org/webapps/SelectorsAPI/tests/approved/ With no negative feedback, this Call for Consensus passes and we resolve to accept the test suite. for the co-chairs chaals If you have any comments, please send to public-webapps by November 23. If you review any set of the tests and find no issues, please state that as a reply to this RfR (so we can get a sense of who reviewed what). In the absence of any comments, these tests will be considered Approved. Note: for all practical purposes, I suspect the set of people that will actually review our tests are already subscribed to the testsuite list, thus this extra CfC is unlikely to result in additional review. As such, if no one beats me to it ;-), I will (separately) start a thread about streamlining the testing process a bit (for example remove the separate group wide CfC for a test suite and include the test suite review in the CfC to move a spec from CR to PR). However, let's please not derail this CfC on testing process issues. -Thanks, AB #Approval http://www.w3.org/2008/webapps/wiki/Approval Original Message Subject: Re: RfR: Selectors API Level 1 Test Suite - deadline 14 November Resent-Date:Thu, 15 Nov 2012 16:18:17 + Resent-From:public-webapps-testsu...@w3.org Date: Thu, 15 Nov 2012 17:17:42 +0100 From: ext Charles McCathie Nevile cha...@yandex-team.ru Organization: Yandex To: public-webapps-testsu...@w3.org, Lachlan Hunt lachlan.h...@lachy.id.au, Charles McCathie Nevile cha...@yandex-team.ru On Sun, 11 Nov 2012 16:07:08 +0100, Charles McCathie Nevile cha...@yandex-team.ru wrote: On Wed, 24 Oct 2012 14:28:41 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: This is a request for review of the Selectors API Level 1 test suite. This is a formal resolution that the test suite has passed the review, and is accepted. Although the only review we are aware of is Opera's, there are 5 browsers scoring 97-99% on the tests, and people seem to have checked the tests in practice. cheers Chaals (as co-chair) -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Editor change for Web Application Manifest Format and Management APIs specification
On Wed, 21 Nov 2012 18:58:02 +0400, Mounir Lamouri mou...@lamouri.fr wrote: Hi, Anant stepped down as an editor of Web Application Manifest Format and Management APIs specification [1] but Mozilla is still interested in this specification so I will replace Anant as an editor. However, given the feedback we got on this specification [2], we are merging it with the Runtime and security model specification that will happen in the System Applications Working Group [3]. We are not against keeping the specification in this WG but we fear that it might not gain much traction as-is. Hi Mounir, Yandex is interested in this spec. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [admin] XHR ED Boilerplate
Warning. This discussion seems by and large non-technical bike-shedding for political purposes, which I have tried to stay away from. But some important points are drowning in rhetorical over the several threads that have dealt with this "issue".In particular I note consensus that we don't want to misrepresent contribution to the work. I considered it obvious - it is how civil adults work and it is an accepted part of W3C process and practice.On Sat, 24 Nov 2012 00:34:02 +0400, Glenn Adams gl...@skynav.com wrote:Is Anne the *sole* author?As I understand it, Anne wrote the words of various specifications. In other words, the person whose "artistic _expression_" is reflected in the document. Although various bits of boilerplate are just pattern repetition. he also did a significant proportion of the testing, thinking, and developing the content at a conceptual level.But no, I believe other people did parts of this work, unless Anne simply ignored anything other people had already done, or we accept that by repeating other people's work he has produced original work, which runs against what I believe is a common definition.In particular, other people contributed information to Anne as members of the Webapps working group - with an understanding that the resulting documents would be published by that working group. To try and whitewash that out of history seems to be somewhere down the slippery slope of plagiarism.Nobody has suggested that the contributions of those beyond the working group should be ignored or misrepresented, the arguments have been about the precise editorial details of how that is done - what is generally called "wordsmithing" or "bikeshedding" (depending on whether it is "us" or "them" doing it).I don't think "author" is a particularly accurate description, but I don't think that what people who contribute are called by the specification is a particularly important issue, so long as it is roughly accurate. So far I am happy enough with how the different people who have done the work of preparing different documents choose to represent the different contributions made. If it's good enough for the "I can live with it" test in a world where we don't want to minutely examine every person's work, but would rather focus on actually making progress I am happy to live with the varying details, in order to keep working in such a world.I suggest that is a more productive way for the Working Group to continue, and more respectful of people who have done significant hard work in the expectation that it would benefit the stakeholders in the web, rather than any individual or group's perceived place in history.cheersChaalsDid the WG or others not contribute any text or suggested text to the spec? It seems like a bit of a slippery slope to attempt to designate a sole author for any W3C product. You might want to check with the pubs team on this matter. On Fri, Nov 23, 2012 at 11:44 AM, Arthur Barstow art.bars...@nokia.com wrote: [ Sorry for the delayed response, I was choking on some turkey ... ] Here's what I did for the URL spec re the boilerplate to help address the "attribution issue" re Anne and WHATWG: [[ http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html This Version: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html Latest WHATWG Version: http://url.spec.whatwg.org/ Previous Versions: http://www.w3.org/TR/2012/ED-url-20120524/ Author: Anne van Kesteren ann...@annevk.nl Editor: Web Applications Working Group public-webapps@w3.org Former editors: Adam Barth w...@adambarth.com Erik Arvidsson a...@chromium.org Michael[tm] Smith m...@w3.org ]] In the case of XHR, the new Editors would be listed as Editors and if they made contributions to the spec, they would also be added to the Author list too. If something like that would not be acceptable for the XHR ED, what specific change(s) do you request? -Thanks, AB -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Sun, 25 Nov 2012 22:34:03 +0400, David Bruant bruan...@gmail.com wrote: Le 22/11/2012 18:16, Ms2ger a écrit : On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I'm unfamiliar with the W3C process, so sorry if my question is stupid, but why would it be necessary? It isn't, for the reasons you point out. But it is good manners to make some reasonable acknowledgement of contribution, and therefore considered a requirement in practice. (I'm unconvinced that this group's time should be spent on the finer nuances of exactly what that text should be and where it should go, but that an acknowledgement is required I consider settled question). cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish Candidate Recommendation of Server-Sent Events; deadline November 21
On Wed, 14 Nov 2012 14:27:55 +0100, Arthur Barstow art.bars...@nokia.com wrote: The comment period for the October 23 LCWD of Server-Event Events ended yesterday. Since there were no comments submitted nor new bugs files, this is a Call for Consensus to publish a Candidate Recommendation of this spec using #Draft-CR as the basis. Yandex supports publication. cheers This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs. The CR Exit Criteria (#Exit) is identical to WebApps' last CR (WebSocket API) and the expected CR duration is two months. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is November 21 and all comments should be sent to public-webapps@w3.org. -Thanks, AB #Draft-CR http://dev.w3.org/html5/eventsource/publish/CR-eventsource-Dec-2012.html #Exit http://dev.w3.org/html5/eventsource/publish/CR-eventsource-Dec-2012.html#crec -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Mon, 26 Nov 2012 10:38:35 +0400, Jungkee Song jungkee.s...@samsung.com wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. The proposed wording seems accurate enough to meet my I can live with it test. As the co-Editors of W3C XHR spec wrote in the threads, we have our role and contribution in moving this spec toward the W3C REC. Up to the moment, we mostly had to take care of the gaps between W3C version and WHATWG version to make them convergent. We will try to make more productive discussions along the way from this point on. Indeed. Thank you chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD of XHR; deadline November 29
On Thu, 22 Nov 2012 14:04:54 +0100, Tobie Langel to...@fb.com wrote: On 11/22/12 2:01 PM, Arthur Barstow art.bars...@nokia.com wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so ... Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. +1 Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Two years on and still no sensible web storage solutions exist
ffline applications. Help is appreciated. Trying to help is generally appreciated too.cheersChaals-- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Making offline apps easier?
Hi folks We have a handful of things that could be on our plate here. 1. Appcache. Yeah, we know. But if nobody makes a proposal, nothing will get better. (There is also a fixing-appcache community group taht might come here with proposals). 2. Offline apps breakout at TPAC http://www.w3.org/wiki/TPAC2012/Offline_Apps Ashok Malhotra (Oracle, who aren't webapps members), ran a session. Where we agreed to divide the thoughts into the app shell and the app data - either of which could be brought from offline, or online, independently. Plus I made a half-page note about different ways of having apps offline 3. File APIs. The plain File reader seems almost done. Still. There are apparently people interested in a File System (Opera implemented one for Opera Unite, Chrome and Yandex have one, and there are discussions about making a simpler one). 4. Databases IndexedDB seems to be getting traction across all platforms. Unlike at the face to face, when literally nobody spoke in favour of WebSQL, there are people who think it is worthwhile. At the same time Ashok has been hinting at using something more seriously SQL to help with issues like synch (which always seems like it won't be that hard, but never actually works entirely properly after all). 5. Widgets and packaged apps There is the official widget stack. At the face to face the only people who spoke up in favour of keeping this alive and connected to other app systems were Zynga. There is the Mozilla proposal for apps packaged with a JSON manifest, and Yandex has the same functionality but probably slightly different syntax for the JS. And there may be others... cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CFC Selectors API L1 to CR/PR
On Mon, 15 Oct 2012 23:13:53 +0200, wrote: Hi, Formally, this is a Call for Consensus to move Selectors API to CR (and possibly direct to Proposed Recommendation - see below). Responses are due by Friday 26 October, and while silence will be considered assent, formal approval is preferred. As foreshadowed at TPAC, this Call for consensus has passed. We expect to request zero-length CR, if the associated RfR on the test quite doesn't turn up any reason to do otherwise. cheers Chaals In addition, we would appreciate any information implementors may be able to provide about proposed plans for fixing outstanding bugs in their implementations. The Selectors API Level 1 spec [1] has been fundamentally stable for quite a while, and one issue was raised during Last Call, about what to do with comments. Since we are working on a level 2, Lachlan has proposed to leave the comments case undefined for now and figure out what to do during the time Level 2 is finished, which has been accepted by the commenter [2]. The existing test suite [3] has not been approved yet (a separate mail is coming on that) and Lachlan suggests it could use improvement, but it shows two independent browsers passing each test (Opera 12.1 snapshot and Firefox 16 Release both already pass the ns|div tests that are listed as having no passes in the implementation report linked. General-purpose sites like caniuse.com claim it is implemented everywhere. If it is possible to satisfactorily demonstrate interoperable implementability, I propose to request a direct advance to proposed Recommendation. [1] http://www.w3.org/TR/selectors-api/ [2] http://www.w3.org/mid/501fa594.8000...@oupeng.com [3] http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/level1-baseline.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish Candidate Recommendation of Widget Updates; deadline May 2
On Thu, 26 Apr 2012 18:41:34 +0200, Arthur Barstow art.bars...@nokia.com wrote: The comment deadline for the Widget Updates LCWD ended April 19. No comments were submitted for that document so this is a Call for Consensus to publish a Candidate Recommendation of the spec using the LC as the basis http://www.w3.org/TR/2012/WD-widgets-updates-20120322/. It has been a while. We believe that people using Widget Updates include at least Opera (who have a server-side and client-side implementation) and Apache Wookie, and there are others who have said that they intend to do so. Meanwhile we don't have any actual dissent. This CfC is therefore resolved to have passed, and we will request CR publication for Widget Updates. cheers Chaals The Exit Criteria for the CR will be the same as that used for the other widget specs, namely that two or more implementations must pass each test case. This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is May 2 and all comments should be sent to public-webapps at w3.org. -Thanks, AB -- 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: W3C document license [Was: Re: Call for Editor: URL spec]
On Tue, 06 Nov 2012 12:57:38 +0100, Arthur Barstow art.bars...@nokia.com wrote: On 11/06/2012 08:02 AM, Adam Barth wrote: Does the WebApps Working Group plan do either of these things? B) License the fork in such a way as to let me merge improvements into my copy I am not aware of any changes nor impending changes to the W3C's Document license policy WebApps follows. Actually there are efforts being made to change the document license. But they are not in the scope of this group. If you're a W3C member then you should already know how the organisation changes itself. If not, you're still welcome to e.g. the W3C Process Community Group, where among other people the CEO, and the current editor of the Process Document, actually listen to what people say and engage in discussion. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Pre-fetch rough draft
On Mon, 05 Nov 2012 13:28:43 +0100, Julian Reschke julian.resc...@gmx.de wrote: On 2012-11-02 11:16, n...@yandex-team.ru wrote: On Tue, 30 Oct 2012, Michael Nordman micha...@google.com wrote The appcache is encumbered with guarantees about atomically updating a set of resources and then explicitly not hitting the network for them ... This gist of this prefetch list seems different. More of a hint to warm things up if possible and viola things are more responsive if those hints are taken. Yes. Exactly. It's not about offline apps, it's about reducing loading time. There's already the prefetch link relation that you could use. This makes sense if we agree that prefetching a manifest (see below for some reasons I think they serve different initial use cases) is the same as prefetching an individual resource. Personally I am not convinced that is true, although I don't know of any reason to feel strongly one way or the other. Prefetch manifest is a way to tell browser what should be downloaded in advance. So when user opens the site (for the first time) all resources (css/js/images/...) are already cached. And if later site's resources are updated browser could check prefest manifest and re-download all new resources in background. Before user visited site again. But then you don't need a manifest for that (see above). I think you do in the case where the list of resources that are used by the site changes faster than the resources themselves. e.g. 1. We use several versions of a script library, because different sites that rely on them update at different times. So we might point to v 1.1.1 and v 1.1.2 and v 1.2.1 in different Yandex properties, updating the prefetch manifest while the cache-control says we're not changing the version-specific stuff. 2. We highlight some photos in a property. The photos are static resources - but the highlights change every so often (but not every page view or there would be no point in caching). cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Pre-fetch rough draft
On Tue, 30 Oct 2012 10:22:47 +0100, Charles McCathieNevile cha...@myopera.com wrote: Hi, I mentioned this and it's something we are working on. Basic idea: site provides list of resources that it uses and can be cached for general improvements on the whole site. (We're seeing load-time improvement from 50% - 300% in our testing. We are using it on sites - mail.yandex.ru/prefetch.txt has an example). mnot already suggested that we use http://tools.ietf.org/html/rfc5785 to locate our well-known URI, and we agree. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CFC Selectors API L1 to CR/PR
On Mon, 15 Oct 2012 23:13:53 +0200, wrote: Formally, this is a Call for Consensus to move Selectors API to CR (and possibly direct to Proposed Recommendation - see below). Responses are due by Friday 26 October, and while silence will be considered assent, formal approval is preferred. Please reply to this thread to indicate your response. Yandex formally supports Selectors going forward. cheers Chaals In addition, we would appreciate any information implementors may be able to provide about proposed plans for fixing outstanding bugs in their implementations. The Selectors API Level 1 spec [1] has been fundamentally stable for quite a while, and one issue was raised during Last Call, about what to do with comments. Since we are working on a level 2, Lachlan has proposed to leave the comments case undefined for now and figure out what to do during the time Level 2 is finished, which has been accepted by the commenter [2]. The existing test suite [3] has not been approved yet (a separate mail is coming on that) and Lachlan suggests it could use improvement, but it shows two independent browsers passing each test (Opera 12.1 snapshot and Firefox 16 Release both already pass the ns|div tests that are listed as having no passes in the implementation report linked. General-purpose sites like caniuse.com claim it is implemented everywhere. If it is possible to satisfactorily demonstrate interoperable implementability, I propose to request a direct advance to proposed Recommendation. [1] http://www.w3.org/TR/selectors-api/ [2] http://www.w3.org/mid/501fa594.8000...@oupeng.com [3] http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/level1-baseline.html -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [widgets] Does anyone still care about Widget Updates?
On Mon, 22 Oct 2012 15:37:51 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 20 Oct 2012, at 13:12, Arthur Barstow wrote: For various reasons, a Candidate Recommendation of Widget Updates was never published, although the CfC to do so passed and the ED is prepared as such [widget-updates]. Since no one has raised this as an issue, I would like feedback on what we should do with this spec. The main options are: 1) to stop work (and publish a WG Note); 2) to move forward with the CR. I don'tthink it makes much sense to move the spec to CR if we do not have commitments for at least two independent implementations of the CR. Therefore, Implementors should please speak up if they willcommit to implementing this CR. Its implemented in Apache Wookie from version 0.13. It's implemented in Opera extensions, and in their extension server set up, although I don't have a lot more details to hand. I'll ask Opera if they can provide more info. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?
On Tue, 09 Oct 2012 08:43:13 +0200, Florian Bösch pya...@gmail.com wrote: Cheer up everyone, we've got somebody dedicated to writing fullscreen exploits now :) http://feross.org/html5-fullscreen-api-attack/ Summary: Change blindness may make phishing attacks feasible (displaying a mock browser/page in fullscreen) Cause: Switch to fullscreen before user consent. Fix: Switch to fullscreen after user consent. Questions: - Is this a problem? The blog shows why it is a problem? It matches a very well-known class of problem. So I would say Yes, there is a problem here. - Does the proposed fix address the problem? The question of what gets tp go fullscreen matters. Getting user consent to go fullscreen, but then making something else the actual thing that takes the screen, may not solve the problem because it still enables the attack to be developed. - What is the reasoning to switch before user consent? It allows developers to control more of the experience (which they generally want). Given the price in security for the user, I would say the end is not justified. cheers Chaals On Fri, Oct 5, 2012 at 6:45 PM, bugzi...@jessica.w3.org wrote: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 Summary: May user agents apply additional restrictions on entering pointer lock? Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Pointer Lock AssignedTo: sch...@chromium.org ReportedBy: sch...@chromium.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org The pointer lock spec Working Draft 29 May 2012 is written specifying several requirements to enter mouse lock, and leaving user agents to add additional constraints to prevent nuisance and enforce security policies. Specifically the Element requestPointerLock method section [1] states The user agent determines if pointer lock state will be entered and the Security section [2] includes varying policies including 'A conservative approach' requiring user gestures and 'A full screen approach' requiring full screen. Initial implementations have added additional constraints beyond those explicitly listed in [1]. Firefox 14 introduced pointer lock requiring that fullscreen be entered and confirmed and that the pointer lock target match the fullscreen element. Chrome 22 introduced pointer lock with a more permissive policy, allowing pointer lock of any element after fullscreen has been confirmed. Chrome also permitted pointer lock outside of fullscreen if it was requested via a user gesture. Concern was raised in public-webapps discussion [3] that all user agents should use the same policy and that be incorporated into the specification. [1] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#methods [2] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#security [3] http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html -- 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. -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation
On Thu, 27 Sep 2012 23:55:37 +0400, Tobie Langel to...@fb.com wrote: On 9/27/12 9:35 PM, Arthur Barstow art.bars...@nokia.com wrote: W3C Advisory Committee members are asked to Please review the specification and indicate whether you endorse it as W3C Recommendation or object to its advancement by completing the following questionnaire https://www.w3.org/2002/09/wbs/33280/widget2e/. I'm getting the following error when answering the questionnaire: Hopefully it is fixed now (Dom++) cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
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: 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
