See also: IRC log
<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
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
AB: Issue #80 - Runtime
localization model for widgets;
... #80 http://www.w3.org/2008/webapps/track/issues/80
... where do we stand on this Marcos?
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 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="http://virtuelvis.com/archives/">
<arve> <iframe src="/"></iframe>
<arve> The iframe will not point at http://virtuelvis.com/archives/ but rather at http://virtuelvis.com/
<arve> Test at 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
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 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;
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
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0522.html
... in that response I define a model to address the concern
that was raised
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 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
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: ↑
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
AB: Window modes
http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda#Packaging_and_Configuration_spec
... requirements submitted by Mark
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0299.html
... do we want to start there?
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 (http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0299.html)
proposal
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
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0299.html
... starting with #6
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 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> 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.
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
<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 ]
<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 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 (http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0536.html)!
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
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 :) ]
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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/this is a/this requires the specification of a/ Succeeded: s/discussling/discussing/ Succeeded: s/with dropping/with dropping this req #9/ Succeeded: s/MP instead/MP: instead/ Succeeded: s/.. .OK?/... OK?/ Succeeded: s/Docked can/Docked cannot/ FAILED: s/,not allowed/ is allowed/ Found ScribeNick: ArtB Found Scribe: Art Default Present: +45.29.aaaa, Mike Present: Art Andy Audrey Delavarenne Ivan DE MARINO Mark David Arve Marcos Fabrice DESRE Benoit GRELARD Mike Mohammed DADAS Ranier Rafel UDDIN Claudio Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda Found Date: 24 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/24-wam-minutes.html People with action items: claudio four jere marcos modes requirements send these window with work[End of scribe.perl diagnostic output]