08:29:30 RRSAgent has joined #wam 08:29:30 logging to http://www.w3.org/2009/02/24-wam-irc 08:29:32 arve has joined #wam 08:29:40 ScribeNick: ArtB 08:29:44 Scribe: Art 08:29:48 Chair: Art 08:29:54 Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda 08:30:01 Meeting: Widgets F2F Meeting 08:30:09 Date: 24 Feb 2009 08:30:09 mpriestl has joined #WAM 08:31:09 drogersuk has joined #wam 08:31:48 Marcos has joined #wam 08:32:06 Present: Art, Andy 08:32:32 present+ Audrey Delavarenne 08:33:09 present+ Ivan DE MARINO 08:33:09 Present+ Mark 08:33:14 Present+ David 08:33:18 Present+ Arve 08:33:25 Present+ Marcos 08:33:34 present+ Fabrice DESRE 08:33:59 present+ Benoit GRELARD 08:34:17 RRSAgent, make minutes 08:34:17 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 08:34:22 Present+ Mike 08:35:24 do you have a bridge? 08:35:51 or can skype me in? 08:38:51 MikeSmith: we've now called in and it's working 08:39:26 present+ Mohammed DADAS 08:40:14 do we have a meeting name? 08:41:16 Zakim has joined #wam 08:41:43 zakim, this is widgets 08:41:43 ok, Marcos; that matches IA_WebApps(Widgets F2F)3:30AM 08:41:48 :D 08:42:01 Benoit_ has joined #wam 08:43:12 Topic: Agenda Review 08:43:21 AB: agenda posted two weeks ago 08:43:28 ... we can modify it as we need to 08:43:33 ... Any change requests: 08:43:42 DR: want to add BONDI discussion 08:43:44 AB: OK 08:44:24 Topic: Localization and Internationalization 08:44:36 AB: Issue #80 - Runtime localization model for widgets; 08:45:09 Present+ Ranier 08:45:18 Zakim, please call Mike 08:45:18 ok, MikeSmith; the call is being made 08:45:19 AB: #80 http://www.w3.org/2008/webapps/track/issues/80 08:45:19 +Mike 08:46:31 AB: where do we stand on this Marcos? 08:47:25 MC: Josh's suggested the model was broken 08:47:29 ... and MP agreed 08:47:46 MP: I want to define a fallback model 08:47:54 ... 1st try localized folder 08:48:04 ... then fallback to the root if no localized stuff found 08:48:25 MC: need to think about the semantics of paths 08:49:28 ... need to think about XML Base i.e. don't want to specify something that isn't consistent 08:49:40 BS: think in terms of a tree 08:49:50 ... you are just replacing one tree with another tree 08:50:40 MC: where would one look if "/scripts/foo" is requested? 08:50:49 ... i.e. root or localized root 08:52:19 MC: another issue is the sublanguage tag 08:52:33 ... this could provide another level of fallback 08:52:53 ... I think it is an interesting proposal 08:53:05 ... Not sure the complexity is worth it 08:53:43 AB: what is the current state of impl for sublang tags 08:54:19 MC: no support that I know of 08:55:15 ... In fact, I don't think there is much support for even the single fallback 08:57:04 MC: I think it makes sense to add more flexibility 08:57:19 AB: Arve, what are your thoughts? 08:57:48 Arve: I don't feel strongly 08:57:58 AB: what is the state of the art in the Java world? 08:58:17 [No one had any input on Java ] 09:00:00 MP: re Josh's proposal, I was concerned the paths would have to be changed 09:00:34 ... concerned about authors not getting it right 09:00:52 ... If UA can't find a file in localized folder, it checks root 09:02:19 ... Josh wants "normal" file system behavior 09:02:48 ... not sure how to handle a file with no leading slash 09:02:58 Arve: what happens if "../" is used? 09:06:06 [ We look at Josh's proposal http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0485.html ] 09:06:17 MC: I think this is consistent with XML Base but not sure 09:08:34 AB: I like Josh's model 09:08:50 ... need to see if it holds up if author doesn't include leading slash 09:09:02 ... and still holds if author uses "../.." 09:09:25 ... authors won't remember to always include leading / 09:10:23 MC: I'm OK with this model 09:10:46 Arve: it doesn't align with XML Base 09:11:13 MC: if it doesn't align with DOM L2 that's a problem 09:12:06 Testcase: 09:12:07 09:12:07 09:12:11 abraun has joined #wam 09:12:34 The iframe will not point at http://virtuelvis.com/archives/ but rather at http://virtuelvis.com/ 09:12:53 Test at http://test.virtuelvis.com/loc/foo.html 09:13:15 AB: so what I'm hearing is we have some implied requirements that are not documented 09:13:32 ... we need to explicitly define these constraints for our localization model 09:15:28 Arve: need to be consistent with the Web 09:15:37 ... and this proposal is not 09:16:51 BS: an implemenation could create a shadow tree 09:18:28 Arve: that means the user cannot change its locale and have the widget run 09:18:49 BS: well but the shadow tree could be re-buildable 09:19:43 MC: but what if the fwd slash is not included 09:20:07 AB: will it work if the fwd slash is not included? 09:20:11 MC: yes I think it will 09:20:19 Arve: yes it will work 09:21:20 ... this does not change the semantics of the use of fwd slash 09:21:39 AB: would this create any new issues? 09:22:30 MC: not have leading / would then preserve HTML and DOM2 behavior 09:22:42 ... ie "file" is treated as the beginning of the package 09:22:49 ... and dont use "/file" 09:26:07 AB: draft resolution: we will use the fallback model Josh proposed with the exception that a leading slash is not used 09:26:27 AB: any concerns about this draft resolution? 09:27:19 if the / is used it will use theroot structure only 09:27:36 AB: draft #2: we will use the fallback model Josh proposed without changing the semantics with URI 09:28:45 This should be exactly equivalent to setting the xml/html base in a non-visible manner, and it should fall back to the *root* of the package if resolving the computed URI fails 09:30:48 AB: draft #3 localization fallback is equivalent to setting the xml/html base in a non-visible manner and it shold back back to the root of the pcakage if resolving the computed URI fails 09:31:19 AB: any concerns about #3 09:31:25 [ None ] 09:32:13 RESOLUTION: the localization fallback is equivalent to setting the xml/html base in a non-visible mannder and it should fall back to the root of the package if resolving the computed URI fails 09:32:43 Topic: support of sub-lang tags 09:33:32 AB: Jere raised the issue of whether the l10n model must support sub-lang tags e.g. en-US in the fallback mechanism 09:34:26 AB: do we have the same constraint re reusing HTML base semantics 09:34:33 BS: I like this idea 09:34:56 Arve: it is problematic for some languages e.g. where authors use the wrong tags 09:35:48 AB: doe any existing system provide support this sub-lang fallback mechanism? 09:36:01 MC: Jere mentioned some support in one of the JSRs 09:36:27 Arve: this is a language resolution mechanism 09:36:45 s/this is a/this requires the specification of a/ 09:37:26 MC: can we leave this out for v1 and add it to v2? 09:37:32 BS: we could make it optional 09:37:41 MC: but that creates fragmentation issues 09:39:15 AB: I'm not convinced this is needed for v1 09:39:29 ... we could wait until Candidate phase and solicit input 09:39:56 MP: if we don't support it then the work around is just to have extra files 09:40:27 BS: it would be a lot of extra work for the author, potentially 09:42:14 BS: I would prefer to add it to the spec and ask Reviewers if the complexity for implementors is too great to keep it in 09:43:40 MC: Opera widgets doesn't provide support for language subtabs and fallbacks 09:45:03 AB: I want to defer this until v2 09:45:08 BS: I want it in v1 09:45:26 MC: I'm about 60% leaning toward adding support for v1 09:45:44 Arve: I think we should have it for v1 09:45:54 DR: I agree with Arve 09:46:21 MP: agree we should do it now and avoid the backward compat problem 09:46:55 ACTION: Marcos work with Jere to define the model for supporting sub-lang tags and then get the model reviewed by I18N Core WG 09:46:55 Created ACTION-298 - Work with Jere to define the model for supporting sub-lang tags and then get the model reviewed by I18N Core WG [on Marcos Caceres - due 2009-03-03]. 09:48:15 MC: I'm not sure if this model should be in P&C spec or some other spec 09:48:31 AB: how much time will this take to specify? 09:49:26 MC: not sure; I'll work with Jere when he gets back; 09:50:28 Topic: I18N comments (from I18N Core WG); raised by Addison Phillips 09:50:43 AB: what is the status of addressing these comments, Marcos? 09:50:50 MoZ has joined #wam 09:51:02 MC: I believe I have addressed all of these comments 09:51:31 fabrice has joined #wam 09:51:45 ... He raised an issue re a single config file with multiple lang support 09:52:01 ... I18N BP said not to do that! 09:52:12 MC: I said we would follow BP #12 09:52:27 ... I also think that is messy 09:53:16 MC: the other issue he raised is making ISO-8859-1 the default char set 09:54:31 ... I responded to this in http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0522.html 09:55:05 ... in that response I define a model to address the concern that was raised 09:55:18 AB: any issues with MC's response? 09:55:21 [ None ] 09:58:17 MC: need feedback on default encoding 09:58:27 ... should it be MUST/SHOULD/MAY 09:59:57 ACTION: Marcos seek feedback from Jere and I18N Core WG regarding a default dencoding (e.g. Should/Must/May, ISO-8859-1, etc.) 09:59:57 Created ACTION-299 - Seek feedback from Jere and I18N Core WG regarding a default dencoding (e.g. Should/Must/May, ISO-8859-1, etc.) [on Marcos Caceres - due 2009-03-03]. 10:02:00 Benoit has joined #wam 10:02:00 Arve: I think most of this is edge case stuff 10:02:04 AB: I agree 10:02:14 tlr has joined #wam 10:02:22 Topic: Base folder and resolution of relative paths; raised by Francois Daoust 10:03:07 AB: what is the status, Marcos? 10:03:15 MC: I have a draft response 10:03:29 ... some overlap with issues we have already discussed 10:04:09 ... there is also at least one conflict between his proposal and something we agreed re the l10n model 10:04:40 ... I need to clarify base folder in terms of XML Base 10:05:12 AB: what is your ETA for a response, Marcos? 10:05:23 MC: I sent him some off-list e-mail 10:05:43 ... I could let him know we addressed most of his comments 10:05:53 ... I think two weeks, roughly 10:06:08 present+ Rafel UDDIN 10:06:46 present+ Claudio 10:09:08 ArtB: ↑ 10:09:23 -Mike 10:18:51 RRSAgent, make minutes 10:18:51 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 10:27:50 Topic: Support for sub-lang tags 10:28:15 AB: we did not record a resolution that v1 will include support for sub-language tags 10:28:31 ... I'll add that resolution to the minutes 10:29:56 RESOLUTION: v1 localization model will include support for language sub-tag (e.g. en-US) fallback 10:30:44 Topic: Window Modes 10:32:15 AB: Window modes http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda#Packaging_and_Configuration_spec 10:32:50 AB: requirements submitted by Mark http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0299.html 10:33:13 ... do we want to start there? 10:33:32 MC: I've consolidate Marks' 10 down into 4 10:33:55 ... they focus on display mode and author's desire for display mode 10:34:07 ... and then on API reqs 10:34:17 ... and UA's event handling model 10:35:06 AB: this is propoasl in your draft folder? 10:35:39 MC: I can sent it to list but prefer to continue to flesh it out 10:35:58 AB: I think if we don't get agreement on reqs we will rathole on other discussions 10:37:04 AB: let's then look at MP's requirements (http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0299.html) proposal 10:37:36 MP: #1 - need a set of display/view modes 10:37:47 ... a UA may support them 10:39:00 MC: agree we need to define some rendering modes 10:39:12 ... agree we need to support proprietary modes 10:40:00 MP: #2 - don't want screen dimension support to be a requirement 10:40:52 MC: I don't quite understand this 10:41:08 BS: don't want to say e.g. "this is a 300x400 mode" 10:41:36 MC: ACCESS defines such modes e.g. QVGA 10:41:44 .. .you're saying you don't want that? 10:41:53 MP: yes, we don't want that 10:42:05 ... want more abstract modes 10:42:34 AB: any objections? 10:42:36 MC: no 10:42:49 AB: this seems more like a guiding principle 10:42:59 Benoit has joined #wam 10:43:12 MP #3 - author should be able to indicate the preferred mode 10:43:18 ... UA could ignore it 10:43:59 MC: could say "my preferred mode is floating or fullscreen" but there is no guarantee 10:45:37 MP #4 - can indicate the mode the widget was designed for buy UA can ignore this 10:45:47 MC: don't think this should be in P&C but defined in a Media Queries 10:46:59 MP: I don't think that would be a problem 10:47:05 ... but what if no MQ is specified 10:48:05 MC: what if the user changes the mode to something the UA doesn't support? 10:48:21 MP: the UA would ignore such a request 10:49:17 AB: are there any interop probs with optional metadata 10:49:23 BS: the burden is on the author 10:50:49 MC: it's good to have the richness but there is some additonal complexity 10:51:06 MC: I'm OK with the abstract req but prefer it not be in the P&C spec 10:51:18 ... it could be a req for the UA 10:52:50 MP: I'm OK with it not being in the P&C spec 10:53:38 MP: #5 - we are discussling this on the mail list now 10:53:59 s/discussling/discussing/ 10:54:09 ... could specify height and width 10:54:13 ... depending on the mode 10:54:42 ... There have been some issues raised against this 10:55:48 MC: I have some issues of width and height 10:55:59 ... especially regarding the interaction with CSS pixels 10:56:11 ... could lead to clipping for example 10:57:38 RRSAgent, make minutes 10:57:38 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 11:27:58 anne has left #wam 12:07:05 drogersuk has joined #wam 12:07:19 Marcos has joined #wam 12:08:12 arve has joined #wam 12:08:23 ArtB has joined #wam 12:08:44 Benoit has joined #wam 12:09:45 abraun has joined #wam 12:11:27 RRSAgent, make minutes 12:11:27 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 12:11:39 RRSAgent, make log Public 12:11:47 RRSAgent, make minutes 12:11:47 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 12:13:13 mpriestl has joined #WAM 12:14:06 AB: let's resume MP's requirements input http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0299.html 12:14:16 ... starting with #6 12:14:58 MC: re req #5 - we different view points on this 12:15:15 ... not sure dimensions need to be in the config document 12:16:17 AB: I will add dimensions to the agenda and we'll get to that after we discuss reqs 6-10 12:16:40 MP: #6 is about switching modes 12:17:17 MP: #7 is about the widget being able to change content when mode changes 12:17:43 MC: this is about changing styles, really 12:18:08 MP: #8 this can be viewed as an absraction of #7 12:18:35 MikeSmith has joined #wam 12:18:41 ... if a state changes, may want to change behavior 12:18:50 MP: #9 this may be going a bit too far 12:19:01 Arve: yes, I agree 12:19:22 ... this could require a widget being active in more than one mode at the same time 12:19:53 ... this would add quite a bit of complexity 12:20:00 BS: what's the use case 12:20:43 MC: battery could have an icon state and a full app state 12:21:37 MP: I do agree this may be going too far 12:21:58 Arve: I would object to this requirement 12:22:44 ... it could lead for example for a need to communicate between a widget's different windows 12:22:53 MC: not sure we need to do this for v1 12:23:10 ... e.g. for multiple content elements 12:23:18 BS: I agree with the complexity 12:23:24 MP: I'm OK with dropping 12:24:19 s/with dropping/with dropping this req #9/ 12:25:40 MC: to add support for multiple states/windows and communication between them could require something like OAuth 12:26:28 AB: I'm hearing it's OK to drop #9 as proposed for v1 12:26:34 ... any objections? 12:26:50 ... We will make sure this req is included in our v2 reqs doc 12:28:22 claudio has joined #wam 12:28:25 ACTION: Claudio add a new req to v2 reqs list re an API for opening other browser contexts which will provide feedback to WUA based on the actions performed within that context 12:28:25 Created ACTION-300 - Add a new req to v2 reqs list re an API for opening other browser contexts which will provide feedback to WUA based on the actions performed within that context [on Claudio Venezia - due 2009-03-03]. 12:28:44 [ No objections to proposal above ] 12:29:20 MP: req #10 - UA must be able to move a Widget between display modes 12:30:54 BS: I agree with the general req 12:32:03 MC: "Rxx Display mode API and Events 12:32:03 A conforming specification MUST provide an API to allow authors to programmatically switch between display modes. A conforming user agent MUST be allowed to ignore requests by the author to switch to an unsupported display mode, but MUST throw an exception or error if it will not perform the mode change. A conforming specification MUST also provide a guaranteed means for authors to detect a change in display mode. " 12:32:19 AB: is this OK Mark? 12:32:25 MP: yes, that's a good solution 12:33:36 Topic: Marcos' Proposal on Consolidate Reqs for Window Mode 12:33:37 MC: from Mark's proposal, I wrote the following requirements. 12:33:41 "RXX. Display Modes 12:33:41 A conforming specification MUST specify a set of display modes for a Widget that stipulate how the widget SHOULD initially be rendered at runtime. A conforming specification MAY also define particular allowed, or disallowed, user-interaction behaviors for each display mode; such as the ability for a widget to be dragged or re-sized. For each display mode, the way in which the Widget is displayed MUST be specified so that the rendering of the Widget is as consistent 12:35:02 as possible across Widget User Agents. The display modes SHOULD also be specified to interoperate with technologies such as CSS media queries. Proprietary display modes MAY be supported by the Widget User Agent. 12:36:14 Billy has joined #wam 12:37:44 AB: any comments on the 1st sentence? 12:37:51 AB: I think it makes sense 12:38:18 - +45.29.aaaa 12:38:19 IA_WebApps(Widgets F2F)3:30AM has ended 12:38:21 Attendees were +45.29.aaaa, Mike 12:38:47 CV: how is a window popup managed by a browser? Is there a big difference for widgets? 12:39:40 MC: there is no notion of a popup per se 12:40:01 Arve: Opera's widget impl does nothing if you try to popup a window 12:40:10 ... i.e. window popups are not supported 12:40:32 ... the Browser UA and Widget UA do NOT share anything 12:41:08 Zakim has left #wam 12:42:38 MP: widget app could use HTML5's cross doc communication mechanism 12:43:54 AB: wrt sentence #2, what would you actually specify? 12:44:37 MC: can specify what can be selected 12:45:20 MP: during the last f2f we talked about each mode being specify-able in a sentence or two 12:45:28 ... is that still the expectation? 12:45:52 MC: yes, I think so 12:51:53 [ conversation about existing widget implemenations and their capabilities regarding various modes, interactions, ... ] 12:53:19 AB: any comments about sentence #2? 12:53:26 MP: think the MAY should be SHOULD 12:53:39 AB: that seems OK to me 12:54:47 AB: any comments on sentence #3? 12:55:03 AB: this seems OK; need to see how it gets manifested in the spec 12:56:07 AB: what is the requirement for MQs? 12:56:21 Arve: MQs will be used 12:57:05 will have to be used 12:58:14 BS: not sure we need to explicitly mention MQs in the requirement 12:58:25 AB: agree with BS; something more abstract is needed 12:59:09 [ Marcos makes a new proposal for the presentation sub-req ] 12:59:10 "The display modes SHOULD also be specified to interoperate with device independence best practices and specifications" 12:59:18 AB: any objections? 12:59:21 [ None ] 12:59:39 AB: last sentence 12:59:44 ... any comments? 12:59:52 Arve: not sure we want to do something here 13:01:17 AB: seems like we sholdn't preclude prop modes 13:01:36 ... we need a fallback mechanism so that if the mode isn't supported something useful can be done 13:01:53 AB: any objections on the last sentence? 13:01:56 [ None ] 13:02:26 ==CONFIGURATION DOCUMENT REQUIREMENT== 13:02:26 R.XX Preferred display modes 13:02:26 A conforming specification MUST provide a means for author to indicate at least one preferred display mode for a widget. In the absence of a preferred mode, a conforming specification SHOULD provide a consistent default display mode across all user agents. A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. The Widget User Agent MAY ignore the indications o 13:02:34 AB: OK, then we have now have agreement on this req and its' 5 sub-reqs 13:02:59 The Widget User Agent MAY ignore the indications of display mode supported, but SHOULD NOT ignore the preferred display mode. 13:03:34 MikeSmith has joined #wam 13:05:39 anne has joined #wam 13:07:19 Topic: Preferred Display Mode req proposed by Marcos 13:07:32 AB: see this req that MC entered above 13:07:35 AB: any comments? 13:09:06 MP: not sure about the last SHOULD 13:10:13 AB: so it is optional? 13:10:19 MC: yes, that's right 13:11:24 AB: I think this makes sense because it facilitates mapping existing UAs with no such support into this model 13:11:56 BS: not sure how this would work with Vista 13:12:12 ... with a default of Docked 13:14:01 AB: any other comments about this Preferred Display Mode req? 13:14:34 AB: I'm OK with this as written; no other comments 13:15:53 AB: from the spec writing perspective, what is the effort involved here Marcos? 13:16:32 MC: most of this req is mostly specified now 13:17:02 MP: I think this req is OK; we may need to add some additional stuff though 13:17:18 MC: may need to move some attributes to other elements 13:18:08 Topic: Display Mode API and Events 13:18:15 " 13:18:15 ==API AND EVENTS REQUIREMENT=== 13:18:15 Rxx Display mode API and Events 13:18:15 A conforming specification MUST provide an API to allow authors to programmatically switch between display modes. A conforming user agent MUST be allowed to ignore requests by the author to switch to an unsupported display mode, but MUST throw an exception or error if it will not perform the mode change. A conforming specification MUST also provide a guaranteed means for authors to detect a change in display mode. " 13:18:53 MP: I think this mostly good 13:19:11 ... last sentence needs some work to reflect initial display mode 13:19:49 ... Want to make sure the initial startup is not considered a mode change 13:20:08 MC: you want an event to be fired when the widget starts? 13:20:24 MP: need a means to detect the current mode 13:21:21 [ Marcos add new sentence to his proposed req above ... ] 13:21:44 "A conforming specification MUST provide a means for an author to check the current display mode of a widget. " 13:21:56 AB: any other comments on this req? 13:21:58 [ None ] 13:22:16 Topic: Display Mode Switching 13:22:31 " 13:22:31 ==USER AGENT REQUIREMENT== 13:22:31 Rxx. Display Mode Switching 13:22:32 A conforming specification MUST allow a widget user agent to dynamically change display mode of a widget. Switching from one mode to another, however, MUST not cause the re-instantiation of the Widget. Furthermore, it MUST be possible for a Widget to seamlessly move between modes, maintaining any processes that were in progress. 13:22:32 " 13:23:16 MP: last sentence is a bit fuzzy 13:23:27 ... need to be more specific about the state changes 13:24:24 "Furthermore, it MUST be possible for a Widget to seamlessly move between modes, maintaining runtime state and any processes that are in progress." 13:25:09 AB: any other comments? 13:25:22 MC: thank Mark for doing all of the hard work re requirements! 13:25:30 BS: , 13:25:38 AB: yes, that was extremely helpful! 13:26:18 ACTION: Marcos send these four Window Modes requirements to the mail list 13:26:19 Created ACTION-301 - Send these four Window Modes requirements to the mail list [on Marcos Caceres - due 2009-03-03]. 13:41:58 RRSAgent, make minutes 13:41:58 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 13:57:47 AB: thanks Marcos for closing ACTION-301 (http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0536.html)! 14:02:25 Topic: Window Mode Discussion Topics 14:02:51 AB: 1. Display modes - what are the ones we will support; dive into syntax 14:03:03 ... 2. Dimensions i.e. width and height 14:03:14 ... - how many? 14:03:16 claudio has joined #wam 14:03:29 ... 4. syntax for preferred mode 14:04:44 AB: are there other high level issues? 14:04:58 MC: no, I think that captures the main issues 14:05:07 Topic: Window Mode Naming 14:05:23 MC: we've had serveral proposal: Ivan, Mark, Benoit at least 14:06:04 ... latest ED says: 1) application; 2) floating; 3) fullscreen; 4) docked 14:06:17 BS: thinking minimize or maximize are needed 14:07:37 ... may also need a settings mode 14:08:20 ... e.g. Dashboard has such a mode for defing a widgets' settings 14:08:35 Arve: I disagree that is needed 14:09:36 abraun has joined #wam 14:10:52 AB: I want to stop for a second and regroup 14:11:02 ... earlier we agreed on some related reqs 14:11:11 ... those reqs should now guide our discussions 14:11:21 ... Want to first look at the 4 modes in the ED 14:11:34 ... if there are other modes to discuss we can do them next 14:11:36 .. .OK? 14:12:02 [ no objections ] 14:12:27 [ Arve sketches out a column to capture the discusion ... ] 14:12:40 MP instead of application, perhaps "chromed" 14:13:46 s/MP instead/MP: instead/ 14:13:58 Arve: want to start with important properties 14:14:07 ... Chrome, Transparency, Size, Control 14:14:12 AB: are these boolean? 14:14:23 Arve: no, want to use Must, Should, May 14:15:46 AB: I like this approach 14:16:22 [ MC changes property values to: Yes, No, Maybe ] 14:21:03 MC: what does size mean in this context? 14:21:15 Arve: initial size in terms of CSS pixels 14:21:43 ... on desktop top there is a 1:1 between CSS pixels and the display's pixels 14:38:17 [ Discussions about the values for the various properties which are now: Chrome, Transparency, CSS Overflow property value, Control, UA resizeable ] 14:41:31 s/.. .OK?/... OK?/ 14:52:18 tlr has joined #wam 15:39:00 [ Marcos checked in new version of P&C spec that captures the general agreements of the mode properties and the definition of the properties ] 15:41:51 AB: let's take a 10 min break and end the meeting @ 18:00. Is that OK? 15:42:10 [ No objections :) ] 16:04:54 claudio has joined #wam 16:06:37 ArtB has joined #wam 16:07:19 Marcos has joined #wam 16:07:31 RRSAgent, make minutes 16:07:31 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 16:10:14 Topic: Window Mode Names 16:12:17 Benoit has joined #wam 16:12:33 AB: right now we have 4 modes 16:12:42 ... don't want to rat hole too much on names 16:12:47 ... but names are important 16:13:06 ... There are also proposals for additional modes we need to discuss 16:13:48 MC: we should look at CSS media types 16:14:22 ... and discuss our consensus with them 16:14:51 MP: not sure we have equivalence with our modes and CSS media types 16:15:23 MC: some of our modes are close but some are different 16:16:15 DR: but the CSS media types definitions are fairly old 16:16:26 Arve: yes, about 10 years old :) 16:17:04 ... I don't think our modes are media types 16:17:44 MC: I think we want to do something like @media { ... } 16:18:59 ... we could also define our own CSS property e.g. @window-mode { ... } 16:19:52 MP: we can extend MQs by extending it with our own syntax 16:20:36 an example of what we currently do @opera: 16:20:38 @media all and (-o-widget-mode:docked) { 16:20:38 body { font-size: 80%; } 16:20:38 } 16:21:25 MP: can we define our own version of "-0-widget-mode"? 16:21:34 Arve: yes we can define our own 16:21:48 ... but we should get CSS WG to define this for us 16:22:13 @foo @bar { ... } is forbidden, afaict 16:22:16 Billy has joined #wam 16:22:54 AB: do we really want to build a dependency on the CSS WG? 16:23:17 Arve: it would be a new CSS3 module 16:23:41 ... that would be an extension of of the Media Features of CSS3 MQs spec 16:23:42 could* 16:24:21 anne has left #wam 16:24:26 MP: so could add width and height too, right? 16:24:28 Arve: yes 16:27:00 MP: this would be a separate spec as an extension of CSS3 MQs? 16:27:02 Arve: yes 16:27:22 AB: so this would be a new spec but not a depdency? 16:28:08 MC: yes. We would enumerate the modes but defer to this new spec re the behavior of the properties 16:28:31 Arve: or we could define the modes and let the CSS spec point to our definitions in P&C 16:29:08 MC: is Opera willing to submit this to the W3C? 16:29:19 Arve: it needs some work first 16:29:36 ... but I think it's a matter of a couple of days of work 16:30:32 AB: how do we proceed here? 16:30:52 MC: I think CSS3 MQ should house the definitive definitions 16:31:01 ... and P&C points to the CSS spec 16:31:48 ... P&C just validates the strings 16:32:09 ... and describes the values but the CSS spec contains the authoritative defintions 16:33:07 Arve: I don't think CSS WG will define the behavior 16:38:00 AB: not clear on the agreements and next steps 16:39:08 MC: I believe WebApps requires a separate spec to define the Window Modes for widgets in terms of CSS MQs 16:39:33 MoZ has joined #wam 16:40:35 Arve: I want a separate spec that defines the Window Modes 16:41:03 ... in terms of UA behavior 16:43:10 MP: in Arve's proposal, would still need the Window Modes in CSS MQs, right? 16:43:26 Arve: yes, that is true. I want two different specs 16:43:56 BS: the agreement is that the definitions should not be in the P&C spec 16:44:40 MC: would need a 1-pager type spec 16:44:49 AB: who will need agree to be the Editor 16:44:59 MC: I tenatively agree 16:45:19 ... to be the Editor of both specs 16:45:42 AB: how do we get closure on "tentative"? 16:45:52 MC: I'll need to check 16:46:42 MP: I want to talk about Docked mode today 16:47:05 Arve: add a note that all of the Window Mode stuff will be moved out of the spec 16:48:02 AB: I think this is the right approach 16:48:18 ... but I do get concerned about adding a dependency with the CSS WG 16:48:30 MC: I can work directly with some CSS WG members to help this 16:49:45 AB: draft resolution The authoritative Window Mode definitions will not be specified in the P&C spec but in two new specs 16:50:38 Arve: add "or CSS MQ spec is extended to include our Window Mode defintions" 16:51:24 "or add Widget Extensions for window modes, to the CSS MQ spec, without defining the window modes directly in CSSMQ" 16:52:42 RESOLUTION: The authoritative Window Mode definitions will not be specified in the P&C spec but in two new specs; or add Widget Extensions for window modes, to the CSS MQ spec, without defining the window modes directly in CSSMQ 16:52:43 anne has joined #wam 16:52:58 MC: how much time do we have tomorow 16:58:34 [ Short discusion on agenda for the rest of the week ... ] 16:59:26 MP: I think docked and minimzed are different 16:59:45 ... Docked can provide some user interaction 17:00:02 ... But in minimized, not allowed 17:00:24 BS: in mobile, some minimized have no interaction 17:01:00 s/Docked can/Docked cannot/ 17:01:11 s/,not allowed/ is allowed/ 17:01:49 BS: we are working with widgets on TV, desktop, mobile 17:02:10 ... reality is we will need, ATM, 3 different packages 17:02:19 ... want to get to one package though 17:03:28 MP: minimized size is determined by the Widget 17:03:35 BS: but that is implemenation specific 17:05:12 ... There is no notion of minimized in some systems 17:07:44 MP: in my definition of Docked, the UA will fill the space 17:09:55 [ Marcos draws picture on Whiteboard (sorry no camera ...) ] 17:10:57 anne has left #wam 17:16:20 RRSAgent, make minutes 17:16:20 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 17:20:19 DR: need to make sure widgets aren't minimized such that they aren't visible 17:21:10 MP: yes, need to consider a widget that goes invisible 17:22:28 Benoit has joined #wam 17:23:34 DR: think we need to talk about abuse of widgets 17:23:40 ... don't want to loose that 17:23:53 MC: I agree; it won't get lost 17:24:09 ... I can imagine UAs adding some counter measues 17:24:27 DR: need to think about m-commerce use cases as well 17:24:50 AB: we all have Actions to review the new specs that MC will [hopefully] create 17:25:01 ... in particular to submit comments on the definitions 17:25:13 ... and to make sure your UCs for modes are covered 17:26:42 AB: there will be plenty of opportunity to comment on Window Modes when the next specs are published 17:26:52 DR: do you have a security considerations section? 17:27:04 MC: no, but we can add one if we have sufficient input 17:28:41 AB: any objections to 9:00 tomorrow? 17:28:48 [ None ] 17:29:01 AB: we will meet tomorrow at 9:00! 17:29:06 AB: meeting adjourned 17:29:15 RRSAgent, make minutes 17:29:15 I have made the request to generate http://www.w3.org/2009/02/24-wam-minutes.html ArtB 17:31:57 RRSAgent, bye 17:31:57 I see 4 open action items saved in http://www.w3.org/2009/02/24-wam-actions.rdf : 17:31:57 ACTION: Marcos work with Jere to define the model for supporting sub-lang tags and then get the model reviewed by I18N Core WG [1] 17:31:57 recorded in http://www.w3.org/2009/02/24-wam-irc#T09-46-55 17:31:57 ACTION: Marcos seek feedback from Jere and I18N Core WG regarding a default dencoding (e.g. Should/Must/May, ISO-8859-1, etc.) [2] 17:31:57 recorded in http://www.w3.org/2009/02/24-wam-irc#T09-59-57 17:31:57 ACTION: Claudio add a new req to v2 reqs list re an API for opening other browser contexts which will provide feedback to WUA based on the actions performed within that context [3] 17:31:57 recorded in http://www.w3.org/2009/02/24-wam-irc#T12-28-25 17:31:57 ACTION: Marcos send these four Window Modes requirements to the mail list [4] 17:31:57 recorded in http://www.w3.org/2009/02/24-wam-irc#T13-26-18