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