Re: VMMF — new version
On Thu, Mar 4, 2010 at 3:13 PM, Robin Berjon wrote: > I just produced an update of VMMF to make it ready for publication: > http://dev.w3.org/2006/waf/widgets-vmmf/. > > Essentially I changed it so that it corresponds to CSS Media Queries. That, > plus it being a UI oriented specification, means that there's only one > normative assertion and it's a SHOULD. > > Comments welcome, I think that this baby can ship. Just to be difficult, i object to maximized being misspelled by an old-worlder. I'd suggest "max" or "maxed" as a compromise :) > widgets that have no chrome and that therefore could masquerade some other > existing objects on the screen. s/therefore could/could therefore/ > (e.g. tool bars, title bars, menus, etc.). > (e.g. the menu bar, the clock and similar icons, the system menu, etc.). the use of 'e.g.' is generally incompatible with 'etc.' >The view mode is the manner in which a widget is presented to a user that > corresponds to the metaphors and functionalities in use on a given functionality [N-UNCOUNT] >Describes a widget providing a more immersive interface, Google says that "immersive" isn't in their dictionary, Firefox concurs. Oh well, the web and its 3 million hits evolves to provide such terms.
[cors] Response header whitelist requires changing the API
Hi, Our server has a REST-ful API, where creating a user is done by POST-ing to /users. The response contains a Location header pointing to the newly-created resource, such as "Location: /users/15". Since reading the Location header is not possible for cross-origin requests, we must change the API to return this information somewhere in the body. I'm not sure if this is against the Requirement #15: > Cross-origin requests should not require API changes other than allowing > cross-origin requests. This means that the following examples should work for > resources residing on http://test.example (modulo changes to the respective > specifications to allow cross-origin requests): [...] Anyway, a way of specifying which headers the client is allowed to read, or some other solution, would be nice. Regards, Jaka
Re: [widgets] dir and span elements
Hi Addison, Richard, and i18 WG, On Sat, Mar 6, 2010 at 8:12 PM, Marcos Caceres wrote: > Hi Addison, All, > > On Mon, Mar 1, 2010 at 11:47 PM, Phillips, Addison wrote: >>> >>> Thanks Addison - and yes, I think this makes a lot of sense for a >>> "content"-style spec like HTML, however as the Widgets P&C is a >>> configuration document most of which is IRIs, integers and so on >>> rather than text content its less of a clear case. >>> >> >> No, I understand and don't disagree. However, there is something to be said >> for making it an attribute of , for example. Then you could have an >> override of directionality only when a given element has a different base >> direction. In the example in the spec [1], consider how this might be >> cleaner: >> >> >> >> >> But ltr override here works fine. >> >> >> >> Some rtl text. >> >> >> bidi authors name >> >> >> ... >> >> >> >> >> Compared to: >> >> >> >> >> Some RTL. >> >> >> >> Have to include dir a lot. >> >> >> >> ... >> >> >> >> ... >> >> >> >> I'm not suggesting that 'dir' makes sense everywhere, but there is some >> utility in allowing direction (and maybe language/locale??) in at the >> outermost element? >> > > So you are saying that "dir" affects: > > 1. all child nodes (text, elements, etc.). > 2. _only_ the attributes of child nodes (and _not_ the attributes of > the element on which it is declared). > > I'll note that that behavior is inconsistent with xml:lang, which I > understand applies to the element's attributes on which it is declared > as well as child notes. So, everything below is in English: > > > English > > > but, unless I missed something, I still seem to have a problem (see > second ): > > > > > Some ltr text because name said so... I am rtl > again! more ltr. > > > > Some rtl text. > > > > > I've defined a new rule that is supposed to emulate the behavior of > your example above: > > [[ > ==Rule for Getting a Bidi Attribute Value== > The rule for getting an Internationalized single attribute value is > given in the following algorithm. The algorithm always returns a > string, which can be empty. > > 1. Let /element/ be the element that contains the attribute to be processed. > 2. Let result be the value of the attribute to be processed. > 3. If /element/ has a parent element with a dir attribute, then > process result in accordance to the [Widgets-Bidi] specification. > 4. In result, replace any sequences of space characters (in any order) > with a single U+0020 SPACE character. > 5. In result, remove any leading or trailing U+0020 SPACE characters. > 6. Return result. > ]] > > > AFAICT, this rule would only apply to name element's short attribute. > However, I need i18n WG to evaluate the other attributes. To make this > task easy, I've added a table that lists the elements and their > attributes with links: > > http://dev.w3.org/2006/waf/widgets/#table-of-elements-and-their-attributes > > So, together with the modified Rule for Getting Text Content, which now reads: > > "If input has a dir attribute, or has a parent element with a dir > attribute, or has any child elements that contain a dir attribute, > then process input and its descendant text nodes in accordance to the > [Widgets-Bidi] specification and return the resulting string." > > We now generally have a solution for both processing elements and > attributes so that BIDI strings can be used for display purposes. > >>> If dir conformance is tested in relation to the Rule For Obtaining >>> Text Content then this already scopes its use to the four elements >>> mentioned as these are the only elements that the rule applies to. >>> >> >> I agree, but there is one more potential case. The element could >> have a default base directionality set (each target or localized >> equivalent might also override it). >> > > I would prefer to leave directionality of the element to the > whatever its source attribute points to (i.e., always leave it up to > the start file). > > Kind regards, > Marcos > Upon reflection on the discussion above, I think the dir attr must behave the same as xml:lang - meaning that the value of dir is applied to the element, all its attributes, and its child nodes. It is then left to the specification of a given element to define if the rendering of the value of an attribute or the text content of a node is affected (as is the case with the name element and its short attribute VS the feature element's name attribute, which is an IRI... which is something I've been wanting to ask, can IRIs be rendered rtl?). Rationale through example: Below, the issue I mentioned in my previous email is solved by using a span element: I am ltr I AM RTL! I am ltr I am ltr I AM RTL! I am ltr I am ltr I AM RTL! I am ltr again Thoughts, comments? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: VMMF — new version
On Mar 10, 2010, at 09:55 , timeless wrote: > Just to be difficult, i object to maximized being misspelled by an > old-worlder. I'd suggest "max" or "maxed" as a compromise :) Since we're being pedantic, it's incorrect to consider -ize as a new-worlderism — in many cases both are "correct" in proper English. It just so happens that -ise is often preferred in so-called "International English", especially for words of Latin origin (as is clearly the case here). That having been said, when it comes to actual token the rule is to use the carpetbagger spelling so I've effected the change. >> widgets that have no chrome and that therefore could masquerade some other >> existing objects on the screen. > > s/therefore could/could therefore/ Done, ta. >> (e.g. tool bars, title bars, menus, etc.). >> (e.g. the menu bar, the clock and similar icons, the system menu, etc.). > > the use of 'e.g.' is generally incompatible with 'etc.' I must've been drunk, thanks. >> The view mode is the manner in which a widget is presented to a user that >> corresponds to the metaphors and functionalities in use on a given > > functionality [N-UNCOUNT] What's your source? I get uncountable and countable (but I can't find information on whether there's a context differentiator). >> Describes a widget providing a more immersive interface, > > Google says that "immersive" isn't in their dictionary, Firefox > concurs. Oh well, the web and its 3 million hits evolves to provide > such terms. I wasn't completely happy with that term, but I've seen it used rather regularly to describe UIs that use their own style corresponding to what they do rather than reuse the platform's metaphor — as far as I can tell it's typical UX talk, though I'll happily take another option that might be less jargonistic. -- Robin Berjon - http://berjon.com/
RE: VMMF — new version
A small comment. It's probably best to use the OED for English dictionary words rather than a google search: http://www.askoxford.com/results/?view=dict&freesearch=immersive&branch=13842570&textsearchtype=exact David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of timeless Sent: 10 March 2010 08:55 To: Robin Berjon Cc: public-webapps WG Subject: Re: VMMF — new version On Thu, Mar 4, 2010 at 3:13 PM, Robin Berjon wrote: > I just produced an update of VMMF to make it ready for publication: > http://dev.w3.org/2006/waf/widgets-vmmf/. > > Essentially I changed it so that it corresponds to CSS Media Queries. That, > plus it being a UI oriented specification, means that there's only one > normative assertion and it's a SHOULD. > > Comments welcome, I think that this baby can ship. Just to be difficult, i object to maximized being misspelled by an old-worlder. I'd suggest "max" or "maxed" as a compromise :) > widgets that have no chrome and that therefore could masquerade some other > existing objects on the screen. s/therefore could/could therefore/ > (e.g. tool bars, title bars, menus, etc.). > (e.g. the menu bar, the clock and similar icons, the system menu, etc.). the use of 'e.g.' is generally incompatible with 'etc.' >The view mode is the manner in which a widget is presented to a user that > corresponds to the metaphors and functionalities in use on a given functionality [N-UNCOUNT] >Describes a widget providing a more immersive interface, Google says that "immersive" isn't in their dictionary, Firefox concurs. Oh well, the web and its 3 million hits evolves to provide such terms.
Re: [widgets] dir and span elements
Hi Marcos, 2010/3/10 Marcos Caceres > Hi Addison, Richard, and i18 WG, > [snip] > > Upon reflection on the discussion above, I think the dir attr must > behave the same as xml:lang - meaning that the value of dir is > applied to the element, all its attributes, and its child nodes. > Correct. This is also how the element is defined in ITS, see the "inheritance" column at http://www.w3.org/TR/its/#datacategories-defaults-etc : "Textual content of element, *including* attributes and child elements", the same as "language information" in the same table (a mediator for xml:lang). Best, Felix
Re: VMMF — new version
On Mar 10, 2010, at 16:29 , David Rogers wrote: > A small comment. It's probably best to use the OED for English dictionary > words rather than a google search: > http://www.askoxford.com/results/?view=dict&freesearch=immersive&branch=13842570&textsearchtype=exact Well, maybe not — the OED seems to think it's to do with 3D UIs, which sounds like something from the 80s :) Googling for "immersive UI" brings up a number of instances of what I had in mind. Again, I'm happy to change that if someone has a suggestion. -- Robin Berjon - http://berjon.com/
Re: Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
Here are my personal comments on the document: 1. Overall, it's a good a light document. I agree the feature is needed. 2. I don't understand why this is restricted to Widgets... A HTML page can be dropped on a desktop or be rendered chromeless by Mozilla Prism. A web page can be rendered in a browser in fullscreen mode, etc. All values still make sense in the case of a browser. I think this spec should be made app-agnostic and Widgets should not be the only target. 3. why "maxiMIZED" and only "mini"? 4. I think a "hidden" value makes sense for future system use of webapps... Don't say no immediately and think more about it please.
Re: Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
Hi Daniel, thanks for your comments! On Mar 10, 2010, at 17:57 , Daniel Glazman wrote: > 1. Overall, it's a good a light document. I agree the feature is needed. Glad that you think so. > 2. I don't understand why this is restricted to Widgets... > A HTML page can be dropped on a desktop or be rendered chromeless > by Mozilla Prism. A web page can be rendered in a browser in > fullscreen mode, etc. All values still make sense in the case of > a browser. > I think this spec should be made app-agnostic and Widgets should not > be the only target. I don't see why that would be an issue. Do you see the need to change anything (other than some terminology) in the draft to achieve that? > 3. why "maxiMIZED" and only "mini"? Hmmm, because they were added at different times? :) It's a good point, is there a preference between -mized or not? > 4. I think a "hidden" value makes sense for future system use of > webapps... Don't say no immediately and think more about it please. I'm not saying no, but could you just clarify a little bit what you have in mind for this? If it's not an immediate use case, the keyword can be added later too. -- Robin Berjon - http://berjon.com/
Re: Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
On Wed, Mar 10, 2010 at 11:09 AM, Robin Berjon wrote: >> 3. why "maxiMIZED" and only "mini"? > > Hmmm, because they were added at different times? :) It's a good point, is > there a preference between -mized or not? Since the alternative is to use "maxi" for consistency... I think I prefer "minimized". ^_^ That maps better to the traditional verbage used for that window state anyway. ~TJ
Re: Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
On Mar 10, 2010, at 9:09 AM, Robin Berjon wrote: >> 2. I don't understand why this is restricted to Widgets... >>A HTML page can be dropped on a desktop or be rendered chromeless >>by Mozilla Prism. A web page can be rendered in a browser in >>fullscreen mode, etc. All values still make sense in the case of >>a browser. >> I think this spec should be made app-agnostic and Widgets should not >> be the only target. > > I don't see why that would be an issue. Do you see the need to change > anything (other than some terminology) in the draft to achieve that? It looks to me that saying whether or not the viewport is transparent or not is not the important thing, but whether or not it is running within application and/or OS chrome or not. So, in attempting to understand the view modes, I was categorizing them in my mind thusly: application (maybe "windowed" or something else would be a better word): the HTML (or whatever) is running within a "normal" window, or whatever the OS normally puts just outside the viewport for Web pages and such. So, even in a windowless OS such as the iPhone, you would see a status bar, application control buttons, etc. floating: there may be OS chrome (menu bar, status bar, etc.) but there is no window or chrome directly associated with that particular widget or Web page. This would include such things as Opera Widgets, which exist within the application space alongside any open Opera windows, but which have no window chrome of their own. fullscreen: there is no OS chrome showing (unless, perhaps, it is seen through the transparent portions of the widget? I'm thinking that at least a desktop image might show through, or other applications. Otherwise, what? Solid black?). There is no window or chrome showing that is directly associated with that particular widget or Web page, because the viewport is filling the current screen or possibly filling all monitors (it may exist beyond the edges of the screen(s) though, possibly). The OS or application would report to the widget/page whether or not it was in this kiosk-like mode, and it doesn't actually matter to the widget/page if that mode includes a transparent viewport or not. maximized: exactly like "application", but the OS or application is reporting to the widget/page that it is in a maximized mode, and it doesn't matter if that mode includes a transparent viewport or not. This might never happen in a Mac application, BTW, as the notion of maximized doesn't always follow the Windows notion. minimized: more or less like "application", except that the "window" is really whatever chrome the OS or application adds or doesn't add to the display for individual docked items (a beveled edge, drop shadow, margin from other minimized things, etc.). The OS or application would report to the widget/page whether or not it was in this minimized mode, and it doesn't matter if that mode includes a transparent viewport or not. smime.p7s Description: S/MIME cryptographic signature
