Re: [widgets-twi] window object
On Tue, Feb 9, 2010 at 4:05 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: In Wookie we just create the widget object in the global scope, and then add it as an attribute to the window object. Author scripts can access it either by window.widget or just plain widget. I wonder though - for authors what should we recommend if they want their widget to run unmodified in the most UAs? I think window.widget would be best. -- Marcos Caceres http://datadriven.com.au
Re: Rechartering WebApp WG
On Feb 11, 2010, at 05:40 , Doug Schepers wrote: Scott Wilson wrote (on 2/9/10 10:32 AM): There are a couple of additional areas it would be useful to consider for future work in the Widgets space, specifically: - inter-widget communication (both single-user and multi-user, e.g. collaboration) - social web APIs for widgets (e.g. friends, friends-of) Are these deliverables the Widgets folks are willing to take on? If so, are there clear use case requirements documents, and available editing resources? Our preference is to minimise the surface area of what is specific to widgets to the absolute strict minimum. That means that inter-widget communications should just be taken care of as part of Web Messaging, for instance. I'm not sure what Social Web APIs would be. It sounds like a protocol? -- Robin Berjon - http://berjon.com/
RE: [widgets] Draft Agenda for 11 February 2010 voice conf
Hi, I will not be able to join the telco this time. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, February 10, 2010 2:30 PM To: public-webapps Subject: [widgets] Draft Agenda for 11 February 2010 voice conf Below is the draft agenda for the 11 February Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open and Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/02/04-wam-minutes.html Logistics below. -Regards, Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. LC of XML Signatures spec published 4 Feb: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0531.html 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ CR Implementation Report: http://dev.w3.org/2006/waf/widgets/imp-report/ a. Important Test Suite Updates by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0485.html b. Action-486: Create ITS test case(s) for the PC test suite http://www.w3.org/2008/webapps/track/actions/486 4. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. API - openURL security considerations by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0501.html b. TWI: comments by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0479.html c. window object by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0476.html 5. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Action-490: [AB to] Work with MC, RB and Dom on creating a infrastructure to test the WARP spec http://www.w3.org/2008/webapps/track/actions/490 6. AOB a. Charter renewal - please send comments to public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0493.html Comments from Scott Wilson: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0525.html Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] Draft Agenda for 11 February 2010 voice conf
Hi Cyril, On Feb 10, 2010, at 10:22 AM, ext Cyril Concolato wrote: Dear Mr. Barstow, As indicated in the mails about MPEG-U, I would like to request that the WG discusses the MPEG liaison regarding widgets. Could you add it to the agenda ? We can do so provided you agree to never again call me Mr. Barstow :-). Seriously though, yes we can add it to the AOB section of today's agenda. Please join us if you can. -Art Barstow Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/member-bin/irc/irc.cgi Confidentiality of minutes: Public
Re: Rechartering WebApp WG
On Feb 11, 2010, at 5:32 AM, ext Robin Berjon wrote: On Feb 11, 2010, at 05:40 , Doug Schepers wrote: Scott Wilson wrote (on 2/9/10 10:32 AM): There are a couple of additional areas it would be useful to consider for future work in the Widgets space, specifically: - inter-widget communication (both single-user and multi-user, e.g. collaboration) - social web APIs for widgets (e.g. friends, friends-of) Are these deliverables the Widgets folks are willing to take on? If so, are there clear use case requirements documents, and available editing resources? Our preference is to minimise the surface area of what is specific to widgets to the absolute strict minimum. That means that inter- widget communications should just be taken care of as part of Web Messaging, for instance. I'm not sure what Social Web APIs would be. It sounds like a protocol? Scott - would you please elaborate on this, in particular the interop problem(s) that could be addressed by standardization at the W3C? -Art Barstow
Re: Notifications
On Thu, Feb 11, 2010 at 7:24 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. Have you ever tried to browse the web with javascript or images turned off? It's not an experience most users would say is useful. I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I disagree with 2 and 3 being goals. Taking advantage of platform capabilities isn't a goal in and of itself, it's just a mean. Providing a better user experience is the goal IMHO. If users that want to use Growl can't get their browser notifications through growl because the browser was forced to use some other mechanism to implement HTML notifications, then we haven't improved that users experience. Even worse, if they don't get *any* notifications because the website didn't provide a non-html equivalent, then we certainly haven't helped that user. As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? I really think this is a silly rathole that we've gotten ourselves into here. I'm sure that we can come up with a technical solution that gracefully degrades for those users who want html notifications to integrate with growl/etc but provides a robust experience for the rest of users. J
Re: Rechartering WebApp WG
Hi, Art- Thanks for the feedback. Arthur Barstow wrote (on 2/9/10 9:34 AM): On Feb 8, 2010, at 7:25 AM, ext Doug Schepers wrote: We are interested in comments to refine the charter before submitting it to the Advisory Committee and W3C management for review. [1] http://www.w3.org/2010/webapps/charter/Overview.html The changes from the current [Charter] look good Doug! Thanks, happy to help. Some additional changes I propose, using [PubStatus] as a guide for some of the comments: 3.1 - a straight diff on the draft and [Charter] shows a relatively significant set of changes. However, there are really just 3 additions: Alternate Input Device Events, PostMessage + MessageChannel and Web Notifications. Perhaps it would be useful if these three additions were marked up such that these additions were easily identified. Added a paragraph describing the changes, and notated each of the new deliverables. 3.1 - it would be convenient if all of the specs included pointers to their EDs (links are missing for Clipboard, DOM, File API, Progress Events, PostMessage/MessageChannel, Selectors L1 and L2, Web Notifications, XBL2, XHR L1 and L2). Done. 3.1 - CORS is included as a 1st-level bullet and a sub-bullet of Secure Cross-Domain Scriptiong. I would delete CORS' 1st-level bullet. Copy/paste error... removed. 3.1 - Widgets specs: we have already started to remove the Widgets 1.0: prefix for the spec names and this draft charter should do the same (e.g. change Widgets 1.0: Updates to Widget Updates). Done. 3.1 - re Widgets View Modes - there are actually two related EDs so I would change this to Widgets View Mode: a media feature and API related to presentation mode. Done. 3.3 - I think you can delete the Notes: line Removed. 4.1 - besides XHR, at least one of the widget specs (TWI) has a dependency on the HTML5 spec. Added. 4.2 - re CSS WG, change the text to To collaborate on the Selectors API and widget media feature specifications Changed. 2., 3.1 and 4.2 all refer to the Canvas Graphics API. What is this API and would it make sense to consolidate this info in one or two places in the charter? Removed from 2. and 3.1. Probably won't happen anyway, but it has been split out as a separate HTML WG deliverable, so it's good to be prepared in case more upheaval happens. 4.2 - Security Group? - it's not clear what this is about. Is this the informal security IG (public-web-security) or the XML Security WG or something else? TLR is working on putting together a Security Interest Group, but it won't be ready in time, so I've commented this out. 4.2 - re the MAWG, given WebApps' history with Media related spec work, perhaps the text should be a bit more specific e.g To integrate consistent APIs for multimedia functionality e.g. MAWG's a href=http://www.w3.org/TR/mediaont-api-1.0/;API for Media Resource 1.0/a. Done. 4.3. - the Web Sockets protocol is in scope for IETF's HyBi (not their HTTP WG) and it should be explicitly identified. I think this can be addressed by using ... keep pace with the IETF's HTTP and a href=http://www.ietf.org/dyn/wg/charter/hybi-charter.html;HyBi/a groups' work Done. 9. Given WAF and Device API WGs closed almost two years ago, I would delete the Please also see ... sentence. Changed to a link to previous charter. Lastly, 4 specs are listed in [PubStatus] and not included in the draft charter. Above I propose a way to reflect our interest in what [Charter] calls Media Object, but re the other three: a. Element Traversal - it seems like this should be explicitly included in the charter with a caveat that no work will be done except errata handling if the need arises. Added back, with notes. b. File Upload - does the group now consider this work taken over by the File API and File System spec or is there something here we want to explicitly include in the draft? Added a note in File API that it replaces File Upload. c. Window object - given the wording in 3.1 re HTML5 split out, I presume it's OK for the draft to not explicitly include this spec since this wording would permit WebApps to take it (given an Editor, etc.). That was the previous suggestion, so I removed it. I would be happy to add it back if we had an editor who will follow through on it, but those are scarce. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Rechartering WebApp WG
Hi, Folks- Per the telcon today, I have explicitly added a Widget Embedding deliverable to the charter [1] to allow widgets to be referenced from other web content, much as a '.swf' or '.flv' file is referenced in html:object. This is a small but vital aspect of widgets that should round out the deliverables, and I've been given to understand that these deliverables will all be completed in the next charter period. (As a side note, this is actually something the SVG WG has gotten quite a few requests for, especially as more Flash developers are looking to HTML5 and SVG for analogs to Flash functionality. Maybe Adobe and Microsoft could even consider this as a new way to package and deliver their embedded content.) I've also revised the Web Messaging description, again per the telcon, to include resource discovery; the use case described was, for example, having several YouTube video tabs open, and finding them all to give the currently focused one dominance and pause the others. Along with normal use of XHR, this should also satisfy Scott's request for inter-widget communication in both the single-user and multi-user cases. With these additions, and having integrated the feedback from the discussions on member-webapps and public-webapps, I would like to move ahead with W3M review, so we can get this in front of the Advisory Committee for further consideration. [1] http://www.w3.org/2010/webapps/charter/Overview.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Rechartering WebApp WG
On Thu, 11 Feb 2010 16:58:40 +0100, Doug Schepers schep...@w3.org wrote: [1] http://www.w3.org/2010/webapps/charter/Overview.html Sorry for being late. Should it say DOM Level 4 Core rather than just DOM Level 4? If not maybe DOM Level 4 Events and new editions of existing DOM specifications does not need to be mentioned. It is XMLHttpRequest, not XmlHttpRequest. And Object can be dropped. (And there's no Level 1 technically, but I suppose the reference makes that clear.) Looks good otherwise. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Draft Agenda for 11 February 2010 voice conf
Hi Cyril, On Feb 11, 2010, at 14:03 , Arthur Barstow wrote: On Feb 10, 2010, at 10:22 AM, ext Cyril Concolato wrote: Dear Mr. Barstow, We can do so provided you agree to never again call me Mr. Barstow :-). Yeah, we wouldn't want to anger Mr. Barstow. Seriously though, yes we can add it to the AOB section of today's agenda. Please join us if you can. We discussed this on the call today and decided that it would be better if you were around while we discussed it; would it be possible for you to join our next call? -- Robin Berjon - http://berjon.com/
Re: Rechartering WebApp WG
Hi, Anne- Thanks for your feedback. Anne van Kesteren wrote (on 2/11/10 11:06 AM): On Thu, 11 Feb 2010 16:58:40 +0100, Doug Schepers schep...@w3.org wrote: [1] http://www.w3.org/2010/webapps/charter/Overview.html Sorry for being late. NP, just in time. Should it say DOM Level 4 Core rather than just DOM Level 4? Quite right, fixed. If not maybe DOM Level 4 Events and new editions of existing DOM specifications does not need to be mentioned. The specs may not end up with those names, but I wanted the basic deliverables in scope. Note that new editions (like, DOM3 Core 2nd edition, which incorporates errata) are different from new versions of those specs; I added this on Maciej's request, and it seems like a good thing to have in scope. It is XMLHttpRequest, not XmlHttpRequest. Hah! I had actually just corrected that to XmlHttpRequest (it was written both ways previously)... un/re-corrected. And Object can be dropped. Fixed. (And there's no Level 1 technically, but I suppose the reference makes that clear.) Yeah, understood, I thought it was a little clearer to casual readers this way. Looks good otherwise. Thanks. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
[widgets] Applying Stylesheets to Resources
Hi, folks- I've meant to mention this for a while (a couple years), and it's probably too late, but I thought I'd drop it in for future consideration. One odd part of the separation of content and presentation is that a stylesheet is applied to a file by including a link to the stylesheet in the target file. That is totally backward. It's understandable in the historical context, because the file that was being navigated to was the HTML page, and there was no other way to associate or allow discovery of other applicable stylesheets. Widgets, because it defines a manifest, could correct this, if the author wants that option. I would like the manifest to add a linking element that points to a stylesheet and to its target resource (an HTML or SVG file, say), and says, apply this stylesheet to this file. This would allow the author to reuse and repurpose a target resource without touching that file itself. Mix this with parameters (something we are working on in SVG and CSS), and it's a nice model. Is it possible to add something like this? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [widgets] Applying Stylesheets to Resources
On 2/11/10 11:57 AM, Doug Schepers wrote: One odd part of the separation of content and presentation is that a stylesheet is applied to a file by including a link to the stylesheet in the target file. That is totally backward. Strictly speaking, this is just because most people don't have control over their web servers (which is why the link element exists). Link HTTP headers work fine for applying stylesheets. -Boris
[widgets] Draft minutes from 11 February 2010 voice conference
The draft minutes from the 11 February Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/02/11-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 18 February (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Web Applications Working Group Teleconference 11 Feb 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0532.html See also: [3]IRC log [3] http://www.w3.org/2010/02/11-wam-irc Attendees Present Art, Robin, Bryan, StevenP, Marcos, Arve, Doug Regrets Stephen_Jolly, David_Rogers, Marcin_Hanclik Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]PC spec: Important Test Suite Updates 4. [8]PC spec: Action-486: Create ITS test case(s) for the PC test suite 5. [9]Widget Interface spec: openURL() security considerations 6. [10]Widget Interface spec: general comments by Cyril Concolato 7. [11]Widget Interface spec: window object comments by Cyril Concolato 8. [12]TWI spec: test suite 9. [13]AOB: charter renewal 10. [14]AOB: ISO's MPEG-U and Widgets * [15]Summary of Action Items _ trackbot Date: 11 February 2010 scribe ScribeNick: ArtB scribe Scribe: Art scribe Meeting: Widgets Voice Conference Date: 11 February 2010 Marcos member:Zakim, +1.479.524. is me scribe Meeting: Widgets Voice Conference Marcos bah Review and tweak agenda AB: yesterday I sent out the draft agenda for this meeting ( [16]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/05 32.html ). Are there any change requests? ... we will add MPEG-U discussion to AOB ( [17]http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip ) ... we will drop 5.a discuss Action-490 ( [18]http://www.w3.org/2008/webapps/track/actions/490 ) since I hoping to get to it before this meeting but did not and thus have nothing to report. ... any agenda change requests? [16] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0532.html [17] http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip [18] http://www.w3.org/2008/webapps/track/actions/490 [ no ] Announcements AB: two normative refs in Widgets DigSig to XML Signatures specs entered LCWD on Feb 4 ( [19]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/05 31.html ). Any other short announcements? [19] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0531.html PC spec: Important Test Suite Updates AB: last week Marcos mentioned he would add a new test case to the PC test suite. He has done that ( [20]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/04 85.html ). Thanks Marcos! What is the status of people running this new test? [20] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0485.html MC: it has been run by Aplix, BONDI, Wookie have all run this new test and passed it AB: wrt the PC Interop Report, are we back to 3 impls that pass 100% of the test suite? MC: yes, that is correct PC spec: Action-486: Create ITS test case(s) for the PC test suite AB: Marcos, what is the status of the PC ITS testing and Action-486 ( [21]http://www.w3.org/2008/webapps/track/actions/486 )? [21] http://www.w3.org/2008/webapps/track/actions/486 MC: I haven't done that yet AB: do you need some help wrt coordinating with the I18N WG? MC: no, I just need to create the test or tests ... it's not that much work ... I don't think it should block us from going to PR AB: I agree but we know the Director has indicated he would like to see that test ... do you need an impl of ITS to test the tests? MC: yes, that is correct ... I am not aware of any impl that will support it ... it is indeed optional AB: would like SP to help us with the process here SP: if it is optional then there should be at least one impl ... with something like this, not sure what to suggest ... to go to REC with an unimplemented feature would mean the feature is at risk AB: but what about going to PR? SP: should try to find something that can do something with the test scribe ACTION: barstow work with MC and the Team to determine how to test the PC ITS test(s) [recorded in [22]http://www.w3.org/2010/02/11-wam-minutes.html#action01] trackbot Created ACTION-491 - Work with MC and the Team to determine how to
Re: [widgets] Applying Stylesheets to Resources
Hi, Boris- Boris Zbarsky wrote (on 2/11/10 12:04 PM): On 2/11/10 11:57 AM, Doug Schepers wrote: One odd part of the separation of content and presentation is that a stylesheet is applied to a file by including a link to the stylesheet in the target file. That is totally backward. Strictly speaking, this is just because most people don't have control over their web servers (which is why the link element exists). Link HTTP headers work fine for applying stylesheets. Ah, interesting... I didn't know that, thanks! Is this [1] the most recent reference on that? Still, I think adding a way to do this in the Widgets manifest would be a nice authoring solution. [1] http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [widgets] Applying Stylesheets to Resources
On 2/11/10 12:18 PM, Doug Schepers wrote: Ah, interesting... I didn't know that, thanks! Is this [1] the most recent reference on that? I believe so, yes. Still, I think adding a way to do this in the Widgets manifest would be a nice authoring solution. Sure; just have to make sure to define the cascading order. -Boris
[widgets] Testing infrastructure for Widget Access Request Policy (WARP) spec
Hi Dom, All During the 4-Feb-2010 widgets voice conference, we discussed how to test WebApps' WARP spec [WARP] and Marcos raised concerns about how to test the spec given it requires at least two domains to test against since the test cases will make cross-domain requests: http://www.w3.org/2010/02/04-wam-minutes.html#item07 Marcos indicated you had mentioned some related work (i.e. cross- domain testing) has been done at the W3C thus we are wondering if you have a testing infrastructure we can use/leverage. -Art Barstow Reference: Action-490 http://www.w3.org/2008/webapps/track/actions/490 [WARP] http://dev.w3.org/2006/waf/widgets-access/
Re: [widgets] Applying Stylesheets to Resources
Doug Schepers wrote: Hi, Boris- Boris Zbarsky wrote (on 2/11/10 12:04 PM): On 2/11/10 11:57 AM, Doug Schepers wrote: One odd part of the separation of content and presentation is that a stylesheet is applied to a file by including a link to the stylesheet in the target file. That is totally backward. Strictly speaking, this is just because most people don't have control over their web servers (which is why the link element exists). Link HTTP headers work fine for applying stylesheets. Ah, interesting... I didn't know that, thanks! Is this [1] the most recent reference on that? Still, I think adding a way to do this in the Widgets manifest would be a nice authoring solution. [1] http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt The most recent is http://tools.ietf.org/html/draft-nottingham-http-link-header-07, currently in IETF Last Call. AFAIK, only FF and Opera support this (for stylesheets) right now, and their implementations aren't really complete. Best regards, Julian
Re: Notifications
I can't help but think the Growl issue is way overblown. I am the user who uses Growl and also a GoogleTalkLabsEdition for Mac that pop ups nice notifications about upcoming meetings, email and chat. Growl is connected to IRC and something else (don't even remember). They both use top-right corner of the screen to pop up their balloons and co-exist just fine. I don't remember having them ever overlap (or that being a problem). And snooze on meeting popups is great. As for less-capable devices like phones, a few years ago even having a real HTML displayed on them was out of the question. There are still successful companies out there that provide a service of translating any given HTML page into dumbed-down version for a particular cellphone model - for a fee per-translation. Sites that are serious about mobile internet on wide variety of currently-deployed devices often use this stuff to serve pages, it's easier then to build up expertise on all the variants of crippled 'browsers' out there. The progress in this field in a last few years is phenomenal and fast. It wouldn't be surprising if 'regular' HTML notifications were totally possible on those devices by the time the spec and implementations gain some maturity. There is no reason why user of a cell phone can not have a nice meeting reminder with a snooze button, or a chat invite with 'reply now', without the need for a native app. Dmitry On Thu, Feb 11, 2010 at 6:07 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Feb 11, 2010 at 7:24 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. Have you ever tried to browse the web with javascript or images turned off? It's not an experience most users would say is useful. I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I disagree with 2 and 3 being goals. Taking advantage of platform capabilities isn't a goal in and of itself, it's just a mean. Providing a better user experience is the goal IMHO. If users that want to use Growl can't get their browser notifications through growl because the browser was forced to use some other mechanism to implement HTML notifications, then we haven't improved that users experience. Even worse, if they don't get *any* notifications because the website didn't provide a non-html equivalent, then we certainly haven't helped that user. As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? I really think this is a silly rathole that we've gotten ourselves into here. I'm sure that we can come up with a technical solution that gracefully degrades for those users who want html notifications to integrate with growl/etc but provides a robust experience for the rest of users. J
Re: [widgets] API - openURL security considerations
On Mon, Feb 8, 2010 at 6:36 PM, Marcos Caceres marc...@opera.com wrote: At Opera we've been discussing some of the security implications around the openURL method in the widgets API spec. We think the spec might benefit if we were to add a non-normative security consideration section for openURL. The following text, which I did not write, can serve as a basis for the note - we are presenting it here for discussion, and you'll note it uses different terminology than the one found in the spec. In other words, please don't consider the following to be spec text, it needs a fair amount of editing but tries to get to the heart of the problem: Personally, I'd rather suggest that openURL not be treated as openURL but add url to suggested links. I have a blog draft that tries to explain it, but basically, an application has no reason to ask another application to open urls. Instead it should have the ability to give the user a series of urls which the user can treat as a bookmark list. If the user chooses to open one or more of those bookmarks, fine, however, if the user closes the application, having decided that the bookmarks aren't interesting, then they're gone. http://viper.haque.net/~timeless/blog/2/popups/ is the write-up, it's actually the oldest thing in my blog :). Note that my opinion has nothing specifically to do with widgets, I don't approve of random applications on my computer launching my web browser and ordering it to go somewhere. I'd rather my web browser just collect those suggestions and enable me to decide whether *I* want to go to some of them, and if so, which, and of course, at the time of my choosing. Note that in the case where a user actually trusts another application on their system, the user is free to use drag and drop to pull a url into the web browser, that would bypass the suggestion behavior. In the case of widgets, I don't think that such a feature should be supported because there's too much risk that the user is tricked into dragging something dangerous and changing the security principals of the source.
[XHR] RfC for Guidelines for Web Content Transformation Proxies; deadline 11 March
Anne, All, WebApps has been asked to review LCWD #3 of: Guidelines for Web Content Transformation Proxies 1.0 http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/ In particular, Francois notes for the following for WebApps the document applies to proxies that may receive requests initiated by XmlHTTPRequest objects. The XHR references appear to be isolated in section 4.1.2 and 4.1.3: 4.1.2 no-transform directive in Request http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/#sec-request-no- transform 4.1.3 Treatment of Requesters that are not Web browsers http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/#sec-non-web- browsers If you have any comments, please send them to public-bpwg- comme...@w3.org by March 11 at the latest. -Art Barstow Begin forwarded message: From: ext Francois Daoust f...@w3.org Date: February 11, 2010 5:29:39 PM EST Subject: Third Last Call of Guidelines for Web Content Transformation Proxies published Hello TAG, HTML WG, XHTML2 WG, WebApps WG, HCG, Web Security Context WG Chairs, This is a transition announcement for the third Last Call Working Draft of the Guidelines for Web Content Transformation Proxies, published today at: http://www.w3.org/TR/2010/WD-ct-guidelines-20100211/ This set of guidelines for Web Content Transformation proxies (i.e. non transparent HTTP proxies) was developed by the W3C Mobile Web Best Practices Working Group to address some of the needs identified in particular on mobile networks, in accordance with the working group's charter [1]. A second Last Call working draft was published a few months ago, and you had been invited to review the specification back then. The Working Group received a few comments that triggered substantive changes in the document. The group addressed the comments and decided to publish a third Last Call [2]. Status ref. patent policy is available at [3]. This new Last Call review period extends until 11 March 2010. Although the sections mentioned below have not changed since the previous publication, we would be grateful if your group could review the document once more. in particular: * for the TAG, since the document still relates to its issue genericResources-53 and its accompanying finding: http://www.w3.org/2001/tag/doc/alternatives-discovery * for the HTML and XHTML2 Working Groups, since the document makes use of the (X)HTML link element to give hints on content transformation proxies (no change in this version though) * for the WebApps Working Group, since the document applies to proxies that may receive requests initiated by XmlHTTPRequest objects. * for the HyperText CG, as the official point of liaison with the Open Mobile Alliance which might want to submit a review on the document given its implications on the mobile ecosystem. * for the Web Security Context WG, for the section on HTTPS link rewriting (no change in this version though) (The Working Group is also requesting a review from the IETF HTTPBis Working Group). If your group wants to submit a review but is unable to provide it in that timeframe, please let us know so that we can determine a possible extension of the review period. The working group has just sent official replies to the commenters of the second Last Call. At this point of time, there are no formal objections. Thanks, Francois Daoust, Staff Contact of the Mobile Web Best Practices Working Group [1] http://www.w3.org/2008/06/MWBP-WG-charter.html#deliverables [2] http://www.w3.org/2010/02/09-bpwg-minutes.html#item02 [3] http://www.w3.org/2004/01/pp-impl/37584/status
