Re: [Desktop-extensions-team] Proposal for a page visibility API
On Thu, 20 Jan 2011 11:51:17 +0100, Charles McCathieNevile cha...@opera.com wrote: Use cases * An app can provide notifications (using the Web Notification stuff that is under developemnt) when it is not visible/focused, but skip them when it is to minimise distractions and reduce cognitive load * An application can (try to) communicate with the currently focused application. This is essentially what a whole class of extensions does in practice. Enabling it for general HTML would be a step towards making it possible to share different functionality extensions. Right now, it would rely on out-of-band agreement about how to communicate, but that is perfectly feasible in practice. It also introduces a clear requirement for a security discussion (see the paper that Art posted recently...). Also, an app that knows it's invisible can stop, for example, some expensive canvas rendering that no-one will see, making your laptop battery happier. -- Alexey Feldgendler Software Developer, Desktop Team, Opera Software ASA [ICQ: 115226275] http://my.opera.com/feldgendler/
Re: Breaking up the widget specs? Re: [widgets] Removed LocalizableString interface from Widgets API
On Jan 20, 2011, at 22:10 , Marcos Caceres wrote: On 1/20/11 6:48 PM, Arthur Barstow wrote: If people have spare time for the widgets specs, it seems like that time would be better spent moving the existing specs forward. Agree. Just testing the waters to see if any other members were interested. If no one else is interested, and there are no resources available, then this is a non-starter and we press on with what we got. Ditto. In this question I'm actually more interested in what people who haven't implemented widgets think. -- Robin Berjon - http://berjon.com/
Re: [widgets] Removed LocalizableString interface from Widgets API
On 1/21/11 11:48 AM, Robin Berjon wrote: On Jan 19, 2011, at 19:39 , Marcos Caceres wrote: On 1/17/11 1:56 PM, Robin Berjon wrote: Nothing in P+C is super-hard to implement, but the l12n parts account for most of the complexity, I've only implemented the i18n stuff in Javascript, but I didn't find it particularly hard (relative to anything else). I say this because when implementing it is is both what took longest and what had the most bugs. It was also the part that required the most spec-reading. To be extremely clear: I'm certainly not shooting at i18n. I18n is a core requirement for any W3C product. I'm thinking about the specific localisation mechanism that we have specified (removing it does not prevent i18n in any way). True. But the alternative was no i18n model at all, right? No, I think that we can be more fine-grained here. There are essentially two mechanisms at work. One is used to select values in the config.xml file, the other is used to select resources in the widget. The former is useful in that it's the only way one has to ship a multilingual widget that can show a different name and description when integrated with the system. It's also the easiest bit (I found). The latter, however, does not really match how I've seen localisation done elsewhere, is more painful, more error-prone, and less useful. I don't see how you can make these claims (which are relative to which model exactly)? does wigeon support any of the i18n model at all? I've had a brief look at the source and the logs from the project and I can't find your code for i18n stuff. I'm sure you've probably done it (or tried it), I just couldn't find it. If there are better solutions, I would like to see a list of them so we can discuss them properly. We worked for over a year with the i18n WG and I would be extremely surprised if those guys didn't know all the pit falls of each model. I also discussed the model with our localization team at Opera and they were supportive of the model. I don't think that copying the same HTML in multiple directories just to change the language (if you're writing an application) is a good approach. One is far more likely to want to have a single structure (to avoid having to change it multiple times) and replace tokens inside of it to localise. That's absolutely fine too, if that is the model one chooses to use. The model is flexible enough to support both approaches by design. The spec does not force a developer to use the i18n model if they don't want to: a developer opts into the model by explicitly putting stuff into the /locales/ folder. Otherwise, one can do whatever he or she chooses. There is nothing stopping one from using a custom API or a script that contains the key-value pairs for look-up (or whatever). The key was to provide that flexibility and not lock anyone in, but to have one fallback that is simple and has been shown to work (what we currently have). That's the part that I'm most concerned about. But as I said, if we split the specs into pieces I'm happy! The point of splitting the specs would be to allow us to explore/standardize alternatives without breaking current runtimes and content. Let me make this absolutely clear: this is not an exercise to discard the current solution. Splitting the specs would be a way to further the reach of widgets and improve their adoption in the market. That's exactly what I'm saying. Would we get more implementations with that approach? Maybe. I'm putting the call out for feedback here. App stores that don't inter-operate are cropping up from major browser vendors, which use packaging formats (Zip + signature) and metadata formats (JSON or XML) that closely resemble W3C widgets. I think we can all agree that it would be beneficial to the Web community to get convergence on these technologies in the form of an open standards at the W3C.
Re: [widgets] Removed LocalizableString interface from Widgets API
note that you don't *need* to duplicate html files. the format allows for one to have json based localizations. a nokia maps application uses json for localization and could be easily ported to the widget format. i can't do it publicly because i don't own/manage the code.
[Bug 11834] New: API for send/receive of binary data? Current IETF protocol drafts have binary type. Consider typed arrays (ArrayBuffer).
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11834 Summary: API for send/receive of binary data? Current IETF protocol drafts have binary type. Consider typed arrays (ArrayBuffer). Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#the -websocket-interface OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-websocket-interface Comment: API for send/receive of binary data? Current IETF protocol drafts have binary type. Consider typed arrays (ArrayBuffer). Posted from: 99.20.208.90 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 11835] New: Please do *not* require a same-origin restriction in user agents (as currently specified under Security Considerations)! This cross-origin data leakage security issues have alrea
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11835 Summary: Please do *not* require a same-origin restriction in user agents (as currently specified under Security Considerations)! This cross-origin data leakage security issues have already been addressed by the CORS specification (http://www.w3.org/TR/cors/). Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/eventsource/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: Please do *not* require a same-origin restriction in user agents (as currently specified under Security Considerations)! This cross-origin data leakage security issues have already been addressed by the CORS specification (http://www.w3.org/TR/cors/). EventSource should simply adopt the policies outlined there. I consider this a critical flaw, as cross-domain requests are essential to working around useragent connection limits. Unless this is addressed, developers will simply ignore native useragent implementations and write their own, XHR+CORS-based, APIs (as they're already doing.) This spec will be nothing more than tepid inspiration for those 3rd-party solutions, and ignored otherwise. Posted from: 66.220.144.74 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [widgets] Removed LocalizableString interface from Widgets API
On Fri, 21 Jan 2011 19:32:57 +0100, timeless timel...@gmail.com wrote: note that you don't *need* to duplicate html files. the format allows for one to have json based localizations. a nokia maps application uses json for localization and could be easily ported to the widget format. Could you automatically port it? I agree with Marcos that it is very valuable to automatically be able to move a localised app from one environment (e.g. app store, or dev toolkit) to another and know how the localisation works... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Proposal for a page visibility API
On Thu, Jan 20, 2011 at 12:50 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jan 20, 2011 at 2:36 PM, Alex Komoroske komoro...@chromium.orgwrote: If you intend preview to include large but smaller-than-full-size previews, eg. scaled to 50%, I'd recommend avoiding the word thumbnail; I think most people wouldn't consider that a thumbnail. (I could probably come up with a reasonable UI where a preview is at 100%, too...) I agree, although I'm struggling with the precise wording to replace that description with. Do you have any suggestions? I did, too. The main generality behind previews that I came up with is that they're not actually the real, interactive page; they're more like a picture of the page than the page itself (eg. moving the mouse over it won't trip any mouseovers)--but that's far too complicated to get into for a description that should be simple and generalized. How about: “preview” : the page may be at least partially visible, but not in an interactive form (e.g. a lower-resolution thumbnail when switching between tabs). visibilitychange A simple event, fired at the document object immediately after document.visibilityState transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibilityState just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired. This should also include the old document.visibility value. Agreed, but what should the property of the event be called? fromVisible seems awkward. wasVisible is more natural, but it may be inconsistent to use both from and was in the same event. I'm not sure if there are any precedents to follow... I have a moderate preference for wasVisible given the extreme awkwardness of fromVisible On Thu, Jan 20, 2011 at 6:47 AM, Boris Zbarsky bzbar...@mit.edu wrote: So an iframe that's scrolled out of view could return hidden if the browser wants? That's probably bad: if you're in a hidden iframe, you likely want to know if the document you're in is visible, not to always think you're hidden. I think that's right. I'll add language that makes it clear it's the top-most containing page visibility. If in the future there are valid use cases for an iframe to know when it's hidden within its visible parent or scrolled off screen, we could provide an additional visibility state in the second (optional) set of return values for document.visibilityState that can be used for this case. -- Glenn Maynard
[FileSystem]: URI format, uses
The Entry.toURI method specified in the FileSystem spec [1] currently
has an open issue to define its format. I believe we also need to
describe the ways in which it can and cannot be used, as some
potential uses may have security implications.
I propose the following format:
filesystem:{protocol}://{domain}[:port]/{storage type}/{path}
e.g. filesystem:https://www.google.com/persistent/images/logo.png
I think that, for the domain that owns the asset referred to by the
URI, pretty much any reasonable use should be allowed:
video/audio/img/iframe/script sources, XHR [GET only], etc. I'm
iffier on allowing any access to other origins, even for e.g. img
sources, even though they're normally allowed cross-origin. I'd love
to hear security arguments against and use cases for cross-origin
access. Of course, it's always easiest/safest to start out not
allowing such a thing and relax the rules later.
Thanks in advance for any comments.
Eric Uhrhane
er...@google.com
[1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#widl-Entry-toURI
[Bug 11836] New: Don't specify the transport, just specify API and protocol
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11836 Summary: Don't specify the transport, just specify API and protocol Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: major Priority: P2 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: rob...@broofa.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org EventSource shouldn't concern itself with transport issues that aren't directly related to what's required to drive the EventSource API. Conceptually an EventSource is simply a client-side API that is driven by an EventSource data stream. Whether that stream is an XHR request, or a WebSocket, or a raw TCP stream is not important to the core purpose of an EventSource. Trying to specify the details and interface required to implement a specific transport (e.g. what domain restrictions should be imposed) will be confusing when there are already multiple specifications in place for exactly this (i.e. XHR and WebSockets). Instead, the EventSource interface should abstract all this out by adding a transport property that points to the implementation-specific object used to connect to the server. This will allow developers to access the internals of the transport as needed, without having to mirror the API in the EventSource interface. (For example, the Mozilla XHR object has a withCredentials property that developers will want to access when doing cross-domain requests.) You might also want to clarify that the readyState property and the open/message/error events are not expected to correspond directly to any similar interface in the transport object, even though similarities are expected. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [FileSystem]: URI format, uses
On Fri, Jan 21, 2011 at 6:12 PM, Eric Uhrhane er...@google.com wrote: I think that, for the domain that owns the asset referred to by the URI, pretty much any reasonable use should be allowed: video/audio/img/iframe/script sources, XHR [GET only], etc. I'm iffier on allowing any access to other origins, even for e.g. img sources, even though they're normally allowed cross-origin. I'd love to hear security arguments against and use cases for cross-origin access. Of course, it's always easiest/safest to start out not allowing such a thing and relax the rules later. Putting family photos in a directory and giving a webpage access to it isn't the same as putting them on a publically-accessible webserver. I think no cross-origin access should be allowed. I do think there should be a mechanism within createObjectURL to allow cross-origin access, which could be then used with a File created from an Entry. I don't think that makes sense for Entry URIs, though. -- Glenn Maynard
