[widget] proposal to add defaultlocale attribute to widget element (PC Spec), was Re: [widgets] Span example
On Fri, Apr 30, 2010 at 5:16 PM, Marcos Caceres marc...@opera.com wrote: Hi Richard, On Fri, Mar 26, 2010 at 9:32 PM, Richard Ishida ish...@w3.org wrote: The example looks rather baroque, but I think it does illustrate a number of points. (I think that in real life it may be simpler to just use xml:lang=he and dir=rtl on the description tag in a localized config file like this. The example does currently illustrate inheritance though. Yeah, the example is convoluted on purpose to illustrate all the features you mentioned. It also shows how to markup up the language while still marking default text for localization failures. I hadn't realised that that was how you indicated the default for localization. FWIW I'd have preferred a special attribute for that, rather than overloading the xml:lang attribute, but I guess it's too late to change that now. An attribute like localizationdefault=yes would reduce the need for the extra spans. good point. We can add it to our list of things to add in the future. Seems the future finally arrived!:)... After some experience with deploying i18nlized widgets and trying to communicate the i18n model of widgets to developers, Opera strongly feels the need to add a defaultlocale (or similarly named) attribute to the widget element defined in the PC spec. As was pointed out by Richard, the problem with the current spec is that we have overloaded the semantics and functionality of xml:lang. As a result, the only way for an author to say that some content is not localized was for it not to have an xml:lang attribute (or for the xml:lang attribute to be explicitly empty). This is causing confusion amongst our development community. What would be preferable would be to have some means for authors to explicitly declare the default locale of a widget. Consider the addition of a defaultlocale attribute: widget xmlns = http://www.w3.org/ns/widgets; defaultlocale = en-us name short=Weather xml:lang=en-us The Ultimate Weather Widget /name name short=Boletim xml:lang=pt Boletim Metereológico /name /widget As in this case there is no unlocalized content, the user agent that does not support either 'en-us' or 'pt' will not select any content (!). Having the defaultlocale allows the author to hint to user agent which one of the two to use in case it cannot match any content (and returns xml:lang to having its original function - indicating the language of an element and its children). A further advantage, which Richard also alluded to, to having a defaultlocale is that is avoids the baroque constructions like: widget ... name short=Boletim xml:lang= span xml:lang=ptBoletim Metereológico/span /name /widget And has the advantage that the short attribute can also be identified as being in Portuguese (this is actually fairly critical on the Widget API side, as widget.shortName.lang would not have a language associated with it). How it would work: to keep it simple, a one-to-one match would be used to derive the default locale of a widget. So, saying default locale is en will only match elements with xml:lang=en. Default locale is only used iff the user agent cannot match any localized content. Proposed changes to spec: 1. The semantics of defaultlocale would be defined as part of the widget element definition. 2. I18n section of spec would be updated to show examples of usage 3. A default locale would be defined as part of the configuration defaults (Step 3 in processing) 4. How to process defaultlocale would be defined in Step 7. Adding the defaultlocale will not affect existing content as all current rutimes behave as is defaultlocale = . Thoughts and comments welcomed. I'll start spec'ing this up in the meantime. -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
Both Firefox and Chrome offer users privacy features which will cause Web Storage to be non-persistent across browser restart. For example Firefox has a Never remember history option, and Chrome has a clear cookies and other data when I close my browser option. For an application developer, it would be helpful to know when such features have been enabled, so that the application can inform the user, assist in troubleshooting, or disable features that depend on persistent storage. Hi. Although I understand the reasoning, I strongly disagree with the request. When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. There should be no way for a webpage to sniff if private mode is enabled: an advertiser could block users because it wouldn't be able to set tracking cookies for instance, like many of those sites that say Enable cookies to continue, but in this case applied to Storage. Specifying that an API can change its behavior radically solely based on a user preference goes completely against the principle of interoperability: same code running everywhere unchanged. The last thing the user needs is the webpage breaking because there are unexpected exceptions being thrown. By mentioning private tabs, the same applies to other features that remove data. So, +1 to transparency.
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
(Note that this is from a ticket; the OP probably won't see replies here.) On Mon, Dec 27, 2010 at 7:46 PM, João Eiras joao.ei...@gmail.com wrote: When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. Users won't completely understand what privacy mode does; what data can't be stored and what can. If you log into Gmail in privacy mode, does that mean that your saved drafts will be stored, or lost? That depends on whether they're stored on the server or in (for example) localStorage, a distinction no ordinary user can be expected to understand. If Gmail uses localStorage to save drafts (it doesn't), it should definitely be able to tell the user: warning, your saved drafts will be lost at the end of your browser session because your browser is configured not to keep this data around, or to change storage mechanisms. The alternative is ugly--users spending half an hour writing a mail, saving a draft, and having it silently lost, because they expected privacy mode to prevent their login cookie to be discarded, not their drafts. This means that even if localStorage is appropriate for a particular use, the dangers of angry, confused users may make it unacceptable. I don't like the idea of a not persistant attribute: although I don't personally find the transparency argument convincing, I'm pretty sure that even if the spec requires having such an attribute, browsers will ignore it. That seems worse than not having it at all. My first impression was that privacy mode should simply disable these interfaces (as the current Web Storage editor's draft seems to require, though as I mentioned before it's unclear), but that's no good for IndexedDB, which is very useful even if it's not persistant. I don't know the right answer in general. -- Glenn Maynard
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
FWIW, the Chrome team has come down pretty hard on the side of not ever leaking to apps that the user is in incognito mode, for precisely the reasons described previously. Incognito mode loses much of its utility if pages are able to screen for it and block access. I do think there's a user education burden that isn't entirely being met yet, though - the Chrome documentation doesn't really talk about local storage, for example. But I don't think that pushing this responsibility onto individual web applications is the right solution. -atw On Mon, Dec 27, 2010 at 5:45 PM, Glenn Maynard gl...@zewt.org wrote: (Note that this is from a ticket; the OP probably won't see replies here.) On Mon, Dec 27, 2010 at 7:46 PM, João Eiras joao.ei...@gmail.com wrote: When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. Users won't completely understand what privacy mode does; what data can't be stored and what can. If you log into Gmail in privacy mode, does that mean that your saved drafts will be stored, or lost? That depends on whether they're stored on the server or in (for example) localStorage, a distinction no ordinary user can be expected to understand. If Gmail uses localStorage to save drafts (it doesn't), it should definitely be able to tell the user: warning, your saved drafts will be lost at the end of your browser session because your browser is configured not to keep this data around, or to change storage mechanisms. The alternative is ugly--users spending half an hour writing a mail, saving a draft, and having it silently lost, because they expected privacy mode to prevent their login cookie to be discarded, not their drafts. This means that even if localStorage is appropriate for a particular use, the dangers of angry, confused users may make it unacceptable. I don't like the idea of a not persistant attribute: although I don't personally find the transparency argument convincing, I'm pretty sure that even if the spec requires having such an attribute, browsers will ignore it. That seems worse than not having it at all. My first impression was that privacy mode should simply disable these interfaces (as the current Web Storage editor's draft seems to require, though as I mentioned before it's unclear), but that's no good for IndexedDB, which is very useful even if it's not persistant. I don't know the right answer in general. -- Glenn Maynard
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
On Mon, Dec 27, 2010 at 10:55 PM, Drew Wilson atwil...@google.com wrote: FWIW, the Chrome team has come down pretty hard on the side of not ever leaking to apps that the user is in incognito mode, for precisely the reasons described previously. Incognito mode loses much of its utility if pages are able to screen for it and block access. A similar argument can be made for ad blockers, and in my opinion much more convincingly: ad blockers very directly (even measurably) mean sites make less money. Yet, in my years of using ABP, I've never once encountered in the wild a site that refused to work because of it, despite the fact that they're trivial to detect. If ad blockers had been designed to hide their activity from pages, the end result would have been much worse. Images would have to be marked visibility: hidden rather than display: none, since the changes in layout are detectable. A huge amount of bandwidth would be wasted, since the server can check to see that a banner is actually being downloaded. This just has the feel of those theoretical problems that are easy to argue for, but are unlikely to ever actually surface. I do think there's a user education burden that isn't entirely being met yet, though - the Chrome documentation doesn't really talk about local storage, for example. But I don't think that pushing this responsibility onto individual web applications is the right solution. My experience suggests that most users will never know the difference between local and server-side storage, and probably don't want to; most designs that require that much user education don't work. The most likely end result is ignoring the issue: let a few people lose data, and if they complain, tell them it's your fault for using incognito mode, and your browser's fault for preventing us from warning you. Not ideal, but pushing the blame onto the browser is likely to be the path of least resistance. -- Glenn Maynard
