W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

[widgets] Minutes from 24 February 2009 Widgets F2F Meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 26 Feb 2009 11:18:51 -0500
Message-Id: <480A03DB-E404-4288-8C80-066899AB15DF@nokia.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT