- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Fri, 12 Jun 2009 12:54:03 +0100
- To: public-webapps <public-webapps@w3.org>
- Message-Id: <1604551D-3E23-4517-A53B-1DBCF11F39FD@gmail.com>
One scenario for hasFeature():
1. I install a Widget with:
<feature name="http://my.feature.com/x" required="false"/>
2. In my Widget's JavaScript, I have something like:
if (hasFeature("http://my.feature.com/x")){
doCoolThing(); // great, we have the X API! Lets use it
} else {
doLessCoolThing(); // ok do something that doesn't need the X API
}
How can this be realised if hasFeature() is removed? Or should this UC
be specifically out of scope for A&E? For example, would I have to
create two different widgets, one with X and one without?
Without hasFeature(), what does P&C <feature ... required="false"> mean?
S
However, the Widget can't do
On 12 Jun 2009, at 11:45, Arthur Barstow wrote:
> The draft minutes from the June 10 Widgets f2f are available at the
> following and copied below:
>
> <http://www.w3.org/2009/06/10-wam-minutes.html>
>
> WG Members - if you have any comments, corrections, etc., please
> send them to the public-webapps mail list before 18 June 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
>
> 10 Jun 2009
>
> [2]Agenda
>
> [2] http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009
>
> See also: [3]IRC log
>
> [3] http://www.w3.org/2009/06/10-wam-irc
>
> Attendees
>
> Present
> Benoit, Mike, Josh, Jere, Robin, AndyB, Marcos, DanA, David,
> Laura, Marcin, Magnus, Kai
>
> Regrets
> Chair
> Art
>
> Scribe
> Art
>
> Contents
>
> * [4]Topics
> 1. [5]A+E spec
> 2. [6]A+E spec - again ...
> 3. [7]Window Modes / Query spec
> 4. [8]Testing
> * [9]Summary of Action Items
> _________________________________________________________
>
>
>
> <ArtB> ScribeNick: ArtB
>
> <scribe> Scribe: Art
>
> Date: 10 June 2009
>
> <MikeSmith> trackbot, status?
>
> <trackbot> This channel is not configured
>
> trackbot, associate this channel with #webapps
>
> <trackbot> Associating this channel with #webapps...
>
> <MikeSmith> trackbot, status?
>
> <trackbot> This channel is not configured
>
> <MikeSmith> ArtB: trackbut is confused
>
> Scribe+ David
>
> A+E spec
>
> <scribe> ScribeNick: drogersuk
>
> AB: Agenda is API and Events
> ... we have several red block issues
> ... and there is a discussion related to storage
>
> <Marcos> [10]http://dev.w3.org/2006/waf/widgets-api/
>
> [10] http://dev.w3.org/2006/waf/widgets-api/
>
> MC: To progress this, viewMode is not a big issue here
>
> AB: Let's go back to the start of the document. Is the abstract
> up-to-date?
> ... The title includes events but there aren't a whole lot of events
>
> MC: There are events
>
> JS: 3rd bullet point in abstract doesn't make sense
>
> MH pointed out some editorial issues in the abstract
>
> scribe: defined by... defines for example
>
> JS: requests in the 4th bullet should be request
>
> AB: What is the interface that supports the last bullet?
> hasFeature()?
>
> MC: Yes
> ... Perhaps we should concentrate on some of these issues rather
> than the editorial points
>
> AB: Are there any definitions we are missing?
> ... In section 4
> ... we've talked about nailing down origin
>
> MC: it isn't really relevant in this spec, because origin pertains
> to the storage interface and that already defines where you get
> origin from
>
> AB: So we can have this discussion when we discuss the storage
> attribute
>
> MC: As long as we have consensus in the group that each widget has
> its own storage and that storage cannot be accessed by other
> widgets..
>
> AB: We'll deal with this as we get to it in the document
> ... Section 5 begins with the block of the widget interface...
>
> JK: We need to define what is a feature etc.
>
> MC: Do we need a more technical definition than P&C?
>
> There was a discussion about how to define feature
>
> <darobin> [11]http://www.w3.org/TR/SVG11/struct.html#SwitchElement
>
> [11] http://www.w3.org/TR/SVG11/struct.html#SwitchElement
>
> <darobin> actually, this better:
> [12]http://www.w3.org/TR/SVGMobile12/struct.html#SwitchElement
>
> [12] http://www.w3.org/TR/SVGMobile12/struct.html#SwitchElement
>
> <drogers> AB: Back to section 4 - let's look at the first red block
>
> <timeless_mbp> We considered offering a video decoder as another
> example of a "feature" in addition to an API. While we decided not
> to list it as an example, this isn't because it isn't an example,
> but merely because we decided not to list a second.
>
> <drogers> MC: The first red block item covers some items that are
> not defined - e.g. viewMode
>
> <drogers> ...viewMode should be in the window modes spec which is
> not written
>
> <drogers> AB: Robin agreed to be the editor of this
>
> <drogers> ...obviously Robin has had higher priorities
>
> <drogers> AB: mediaquery and windowmodes were going to be two specs
>
> <drogers> MC: and I think they should be one
>
> <drogers> AB: We don't want a dependency on the CSS working group
>
> <drogers> MH: This is a question of timeline
>
> <drogers> AB: So what is the consensus?
>
> <drogers> It was agreed that there would be one spec for this
>
> <drogers> RESOLUTION: There will be one specification for
> windowmodes and mediaquery
>
> <drogers> MC: We need to align the attributes with the steps to
> remove the next red block
>
> <drogers> 5.1 - viewMode attribute:
>
> <drogers> in mediaquery spec - feature is defined too
>
> <drogers> ...we need an explanatory note here
>
> <drogers> MC: The text does not make sense
>
> <drogers> <drogers writes z version on whiteboard>
>
> <drogers> MC: The user agent makes the decision about the window
> mode display
>
> <drogers> ...it is described in the P&C spec (lifecycle) and also in
> the windowmodes spec
>
> <drogers> AB: The sentence: "Upon instantiation...." was removed#
>
> <drogers> The red block issue: this is a computed value was edited
> to change to editorial note. It is to be dealt with by the Editor
>
> <drogers> Locale attribute was discussed
>
> <drogers> MC: I don't think this has relevance anymore
>
> <drogers> BS: This could be useful
>
> <drogers> JS: You would want the widget to see everything though
>
> <drogers> ..this definition is currently wrong and unhelpful
>
> <drogers> MC: We will return the user agent locales
>
> <abraun> Noting for drogersuk
>
> <abraun> MH: Why is it identifier and not id
>
> <abraun> MC: Because of potential confusion around XML id
>
> <abraun> RB: ok to move identifier to id because their will not be
> confusion with XML id
>
> <abraun> MC: ok
>
> <abraun> MC: will change width and height to postive numbers.
>
> <abraun> AB: good change
>
> <abraun> MH: authorInfo why not author.info
>
> <abraun> abraun: Josh: each dot adds a lot of overhead.
>
> <abraun> BS: why not just author
>
> <abraun> MC: ok
>
> <abraun> dicussion leads to question Do we need to define
> installation vs instantiation in P&C?
>
> <abraun> more discussion....
>
> <abraun> AB and Josh prefer definition in A&E
>
> <abraun> MC disagrees
>
> <darobin>
> [13]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/04
> 45.html
>
> [13] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0445.html
>
> <abraun> AB: where less important than that it is done and is
> consistent
>
> <abraun> general concern about scope creep delaying P&C
>
> <abraun> ACTION: Marcos to define installation and instantiation
> [recorded in
> [14]http://www.w3.org/2009/06/10-wam-minutes.html#action01]
>
> <trackbot> Created ACTION-355 - Define installation and
> instantiation [on Marcos Caceres - due 2009-06-17].
>
> <abraun> AB: wonders if other w3c spec define these
>
> <abraun> MH: may have something in BONDI lifecycle document
>
> <abraun> ACTION: Mhanclik to investigate definitions of installation
> instantiation in BONDI work [recorded in
> [15]http://www.w3.org/2009/06/10-wam-minutes.html#action02]
>
> <trackbot> Created ACTION-356 - Investigate definitions of
> installation instantiation in BONDI work [on Marcin Hanclik - due
> 2009-06-17].
>
> <ArtB> ScribeNick: abraun
>
> <scribe> continued discussion on installation vs instantiation
>
> <Marcos> Installation means the first time a widget package and the
> configuration document have successfully passed through the steps
> for processing a widget package.
>
> <Marcos> Instantiation is any subsequent run through the steps for
> processing a widget package post installation of a widget.
>
> MC: when you install you set preferences.
>
> AB: why is install only first time
>
> BS: I took installation means creating something new rather than
> restarting the first time
>
> <hendry> postinst and package life cycle is kinda defined by debian.
> e.g. 'postinst' in
> [16]http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html
>
> [16] http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html
>
> MC: intialization is the first time for setting prefs etc
>
> Josh: yes, then intiatiation is for making multiple copies
>
> <timeless_mbp> s/int/init/ ?
>
> <timeless_mbp> err no... someone else fix that line in the minutes
> :)
>
> timeless fix the line?
>
> <timeless_mbp> intiatiation => initiation ?
>
> <timeless_mbp> intialization => initialization
>
> AB: group has agreed to change instantiation to initialization
>
> <richt> have we lost zakim or this is deliberate?
>
> <timeless_mbp> zakim said it wasn't needed and left
>
> <timeless_mbp> MikeSmith: any idea if this was a time expired thing?
>
> working through the spec to investigate individual instances of
> instantiation
>
> MH: how do instantiate a file
> ... has issues with authorHref name
>
> Josh: Link is better than Href
>
> AB: should have compelling reasons for change this late in the game
>
> MC: won' change P&C because it is substantive
>
> agreed that authorHref will remail as is in A&E
>
> AB: authorEmail will also remain as is
>
> BS: is 5.8 description limited in content? can it have markup?
>
> MC: yes but will be stripped out as defined in P&C
>
> BS: so I can put a URI in description?
>
> Minutes reFlect no additional comments on 5.10 5.11
>
> <ArtB> Scribe+ Jere
>
> <ArtB> ScribeNick: JereK
>
> A+E spec - again ...
>
> AB: A&E, preferences. Lots of discussion in the past, strong
> feelings.
> ... related to HTML5 storage. Red block.
> ... Arve has commented about this. Marcos, lead us.
>
> MC: Red block added by me based on input by Hixie. Need to define
> error conditions when setItem called for read-only
> ... In context where you already have storage, must not end up with
> two.
>
> JS: Let's look at section 3.4.
>
> MC: It's not there anymore, in separate spec now.
>
> BS: Diving into storage now?
>
> <ArtB> Web Storage spec: [17]http://dev.w3.org/html5/webstorage/
>
> [17] http://dev.w3.org/html5/webstorage/
>
> JS: No, but how you reference it.
>
> <Marcos> [18]http://dev.w3.org/html5/webstorage/
>
> [18] http://dev.w3.org/html5/webstorage/
>
> BS: Either local or remote storage?
>
> JS: Just about the binding.
> ... Want to have something like in HTML5.
>
> BS: Clone this section from HTML5?
>
> JS: Yes
>
> BS: So not reference? By cloning this section into A&E, not going to
> reference?
>
> JS: No, still going to reference.
>
> AB: Josh, what parts?
>
> JS: Not the 3rd para, or at least very different. Take first two
> sentences, refer to widget.
> ... must have a set of preferences for each instance.
> ... fourth thing not needed.
>
> Noted that Marcos should do this as Josh describes in detail.
>
> JS: Do people want to listen to preferences change events?
> ... some version of para #6 is maybe needed.
>
> (Marcos proceeds to read the para/sentence.)
>
> MC: Yes, we expect that.
>
> MH: Do I need to read HTML5 to understand A&E?
>
> MC: Have to solve mutex problems anyway.
>
> JS: Do we have workers?
>
> MC: Yes.
>
> AB: Impl. detail?
>
> JS: Workers preempt mutexes?
>
> MC: Significant amount of work required.
> ... not super-difficult, though.
>
> AB: What will you have to copy?
>
> MC: Preferences and read-onlyness...
>
> MH: Could be done consistently in DAP; similar stuff defined in
> BONDI now.
>
> RB: Storage already defines exception codes.
> ... would use the same set of codes.
>
> MC: super simple hash map
> ... only defines quota error and index size error
>
> AB: Important to nail this down, identify the parts.
> ... almost like defining a profile of Storage.
>
> JS: removeItem also has to be able to throw read only error.
> ... in addition to setItem.
>
> <Marcos> If setItem() or removeItem() is invoked with a value
> defined as read-only, then the user agent must throw a
> NO_MODIFICATION_ALLOWED_ERR exception.
>
> (live editing of relevant text parts)
>
> BS2: First ever instantiation?
>
> (Discussion about installation - instantiation comes up again...
> waiting for the outcome)
>
> MC: Not yet satisfied, but might leave that as impl detail.
>
> JS: Can we have an "unConfigured" widget instance?
>
> AB: People can still submit comments if we go with what we now have.
> ... All relevant parts copied from WebStorage now?
>
> MC: Yes
>
> AB: Any other comments? (No.) Moving on to 5.13.
> ... No feedback. Moving on to 5.14 (hasFeature method).
>
> MC: Do we need this?
> ... no means of requesting a feature.
>
> JS: Cheaper for impl, easier on the user to just use it and deal
> with any errors.
>
> MH: Not returning objects anymore. You request a feature and set up
> a callback.
> ... not in global namespace.
>
> JS: hasFeature needs to die.
>
> MH: Similar discussion on geolocation list.
>
> AB: Anybody object to deleting 5.14?
>
> BS: Didn't see that coming.
>
> AB: Marcos, is this harmful?
>
> MC: No, just useless.
>
> AB: Some people find it useful. Anyone else object?
>
> BS2: How can a developer, in a generic sense, find out if something
> is available?
>
> JS: You check for objects, and use them if they are available.
> ... Object needs to be defined.
>
> MC: Scott Wilson's e-mails re: "What does it mean to have an
> unavailable API?"
>
> <ArtB> ...
> [19]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/07
> 12.html
>
> [19] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0712.html
>
> MH: hasFeature is about access to config.xml
> ... if something is required and it's not there, the widget is not
> instantiated
>
> MC: Does not tell you everything
>
> JS: You always only get information you already know from
> hasFeature.
>
> AB: If we do keep it, red block issue remains.
>
> MC: Deleted the red block.
>
> JS: Need to add that the URI needs to be an exact match.
>
> MC: No point in adding if we kill it.
>
> AB: Could explicitly identify it as a feature at risk.
>
> MC: requestFeature as described before could work, but seems like a
> mobile optimization
>
> MH: Same thing could happen on desktop.
>
> MC: Should be discussed in DAP.
>
> JS: +1 to MC
>
> MC: Better bound to the window object.
>
> MH: Affects security.
>
> JS: widget isPropertyOf window
>
> MH: About window.widget.hasFeature or window.hasFeature?
> ... would drop hasFeature and deal with requestFeature later
>
> AB: When Bryan comes back we'll have a formal vote and a decision.
> ... On to 5.15, openURL
>
> <Bryan> be there in a minute
>
> JS: Need someone to have a veto
>
> AB: any objections to 5.15?
>
> MC: It is a SHOULD
>
> JS: And failure case is a MUST
>
> MC: adds statement about UA rejecting
>
> JS: can live with it
>
> AB: any additions to modfications?
> ... none, accepted.
> ... Back to question about deleting 5.14
>
> BS: Some other means to do the same thing?
>
> AB: Yes, as DAP gets going they'll look at both {has/request}Feature
> use cases.
>
> RESOLUTION: hasFeature() will be removed from A&E
>
> AB: Just two more pieces to go with A&E
>
> BS: About openURL, assumption about response?
>
> JS: No feedback, worth noting?
>
> BS: Not returning any data?
>
> JS: Yes, it's void.
>
> BS: Only argument is URI, no limitations?
>
> MC: Yes, openly defined.
>
> AB: On to 5.16, getAttention() (basically a prompt)
> ... Any objections to the current text?
> ... None noted.
> ... On to 5.17, showNotification()
>
> BS: Is string just plain text?
>
> JS: 3rd argument applies it is not modal
> ... text is subOptimal
>
> AB: If UA posted this with title, would there be something to click
> to make it go away?
>
> JS: Yes, but widget won't know when it happened.
>
> BS2: iPhone notification example
>
> (discussion of how the iPhone applications notify the user)
>
> AB: Kai, how would you test user ack?
>
> MH: WebIDL for this has issues
>
> MC: Should get rid of this, to specify elsewhere to get a more
> complete notification model
>
> AB: +1 to MC. Any other approaches?
>
> JS: Feature at risk would be a good baseline
>
> AB: Strong feelings about the options?
>
> MC: Have to talk to Arve
>
> AB: MC will mark it as at risk of being removed.
>
> JS: Draws analogy to Growl notifications
>
> MH: Security workshop Dec 2008: Mozilla and async prompts. Is
> showNotification part of this effort?
>
> JS: If doing that, there is overlap. Sync notifications eat up
> stack.
> ... If Windows would have that, it would be duplicated.
>
> AB: Want to close discussion about A&E
>
> MC: References already done.
>
> AB: OK to remove red block then?
>
> MC: Yes.
>
> AB: Publication plan of A&E?
>
> MC: Needs a day of TLC
>
> AB: Is the next pub a WD or LC?
> ... Any objections for the next version being a LC?
> ... None recorded
> ... When do we record a resolution that it is ready for LC?
> ... Propose to publish LCWD with Marcos' changes, ASAP
> ... Earliest pub date most likely June 18th, needs to be ready by
> June 16th
>
> <anne> [20]http://www.w3.org/TR/widgets/ is going to LC again?
>
> [20] http://www.w3.org/TR/widgets/
>
> MC: Want to finish P&C first, comments from Marcin
>
> <Marcos> anne, no
>
> AB: Agree to publish LC on June 18th?
> ... No objections recorded
>
> RESOLUTION: Agreed to public LCWD of A&E as soon as it is ready.
>
> Time for a break, testing with Kai Hendry next.
>
> <anne> Marcos, cheers, getting confused by all the abbreviations
>
> For the record, "A&E" is Widgets 1.0: APIs and Events
>
> <ArtB> Scribe+ Josh
>
> Window Modes / Query spec
>
> <ArtB> ScribeNick: timeless_mbp
>
> <ArtB> Window Modes:
> [21]http://dev.w3.org/cvsweb/2006/waf/widgets-wm/
>
> [21] http://dev.w3.org/cvsweb/2006/waf/widgets-wm/
>
> [22]http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-wm/Overview
> .src.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1
>
> [22] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-wm/
> Overview.src.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1
>
> AB: Marcin has noted that we should do some work on this
>
> <hendry> in [23]http://hasather.net/widgets/widgets.rnc :
> application, floating, fullscreen, mini, all
>
> [23] http://hasather.net/widgets/widgets.rnc
>
> AB: Brian, you agreed to provide some input
> ... in the absence of any real inputs, then we'll just open the
> floor for comments
> ... when we're done with that, we'll talk about what's the next step
>
> JS: useless comment to marcos :)
>
> AB: this was cobbled together in Paris based on a rough consensus
>
> Kai: what are the view modes defined by this specification?
>
> Marcin: We had a discussion yesterday, what is discussed here is
> window mode, like full screen
>
> MC: In the media query specification, they define different features
> for media types
>
> RB: If we wanted to balance this, we could call these the "docked
> media feature", ...
>
> AB: let me give a little bit of background; during the february
> meeting, we realized that we wanted the packaging spec to proceed
> and not be blocked on window modes
> ... we agreed that P&C would have absolute minimal definitions and
> the canonical list of values
> ... and this spec would contain the fleshed out definitions
> ... I believe this document is version 1.0
> ... what is here is what was entered in february and has no
> attention since then
>
> Kai: Was what I wrote on irc the list?
>
> MC: yes
>
> BS: I'm trying to understand "media feature", I'm familiar w/ SIP,
> but you're referring to CSS "media feature"
>
> <[24]http://www.w3.org/TR/css3-mediaqueries/>
>
> [24] http://www.w3.org/TR/css3-mediaqueries/%3E
>
> <www.w3.org/TR/css3-reader>
>
> <[25]https://developer.mozilla.org/En/CSS/Media_queries ->
>
> [25] https://developer.mozilla.org/En/CSS/Media_queries
>
> Kai: how do media modes relate to things like
> application/floating/fullscreen?
>
> MC: these don't line up because the spec is out of date
> ... we intend to update it to align with P&C
>
> BS: is this intended to address audible media modes?
>
> MC: yes ...
> ... e.g. @media aural and (widget-mode: docked) { .... }
>
> AB: the things after @media <here> are defined by CSS3
> ... what we're saying is that the author can further qualify @media
> modes with widget-modes to affect how things are rendered
>
> MC: I don't think you can change the @media
>
> BS: what about changing from minimized to maximized
>
> RB: those are widget-mode, not @media
>
> BS: oh, i'm confusing those two things, because the two specs
> interact
>
> RB: the examples shouldn't be there, there should be more text,
> there should be examples with details in the rules
>
> BS: So I can test things with this?
>
> MC: You could use A&E to do that instead
> ... Except media type changed event would tell you about some things
> here
>
> Benoit: we put in ResolutionEvent in Paris because it needed to be
> somewhere
> ... and if someone complains *and* provides it where it belongs,
> we'll gladly remove it
>
> JS: There are two modes here
> ... The media types will be unlikely to change for the life span of
> an instance on a device
> ... And widget modes which the widget will be able to ask the user
> agent to change
> ... What this spec allows is for the widget to use CSS to control
> how the widget is presented according to the intersection of these
> two criteria
>
> BS: The combination of the media type and the widget mode allow the
> widget to style its presentation in that combination. And that's the
> purpose of this spec?
>
> Benoit: exactly
>
> BS: And the other thing is some event stuff, which should be
> elsewhere?
>
> Benoit: yes
> ... The general issue is that in the P&C spec, there was a need to
> define modes
> ... This spec is to enable the P&C spec not to have that stuff,
> because it was too much information
>
> BS: do we expect of have more features here?
> ... the feature to me is an example of a widget mode. Widget,
> Docked, Full Screen
> ... Application
> ... In Widget mode, you get a box?
>
> Benoit: Not even a box, just a space
>
> BS: Will there be more?
>
> Benoit: I believe that set was defined
>
> AB: Let me find the reference
>
> Benoit: this was discussed
>
> BS: what about icons?
>
> Benoit: there were reasons icons were taken out
>
> BS: this set of modes is presumed to be complete?
>
> AB: Yes.
>
> MO: Icons. Was that related to notifications?
>
> AB: I wouldn't say it was never covered. We talked about icons being
> one of the states
>
> JS: The reason we don't have icons in the list is because icons
> coexist with another state
>
> AB: P&C has 5 values, what's the definition of mini?
>
> RB: it's not very well specified
>
> MC: It's a mode that's smaller than full screen
>
> Benoit: originally this comes from Vista where you have docked and
> undocked
>
> MC: You have full screen...
> ... Application, which is slightly smaller with some chrome
> ... Floating, which is application with no chrome
> ... Mini, which is UA specific
>
> RB: Art, maybe you can iTunes to show Mini player
>
> (Art shows iTunes in Mini mode, and RT pokes fun at RB)
>
> MC: it's up to the implementation to say which mode it's putting
> things in
>
> RB: it would be nice to have semantics to the keywords
>
> BS: What about all?
>
> RB: all is useful for having a rule that applies to all modes
>
> BS: Can I query for mode all?
>
> Benoit: No
>
> RB: But if you queried to see if it matched all, it'd say yes
>
> Marcin: We have widgetMode, viewPort and widget-mode
>
> AB: We recognize that this draft is out of date/sync
>
> Marcin: the question is do we need this document
> ... currently what's needed in terms of modes is already listed
> outside this specification
> ... A&E offers an api to get/set modes
>
> <hendry> Marcos: floating in terms of X means a window that isn't
> tiled (~docked) or fullscreen. It has no relation to chrome. /me
> worried there might be confusion.
>
> Marcin: for me it seems like media query is an informational
> document
> ... but what about all?
>
> RB: I don't think all will be exposed
>
> Benoit: All is for CSS
>
> <MagnusO> Howis ALL related to Fullscreen?
>
> Marcin: Could we add a note that 'all' will never be returned by A&E
> viewMode?
>
> (MC points to the P&C spec with some section highlighted)
>
> (including "all")
>
> Marcin: The issue is that we're using the same token list for 3
> places
> ... but in one place it doesn't fit (A&E)
>
> <MagnusO> So ALL is really same as able to appear in any form, full,
> mini etc.
>
> MC: What I am getting is that i need to clarify where/when all is ok
>
> Benoit: All should be listed in its own sentence
>
> RB: yes, outside the original list, with an explanation.
>
> AB: The default is floating
>
> MC: In addition, the all keyword can be used to denote that all the
> valid view modes are supported by the widget
>
> JS: +1
>
> (offtopic chatter)
>
> Marcin: P&C talks about a widget views spec
> ... and widgets views spec is really green -- not yet defined
> ... and we can take P&C to a certain state
>
> AB: It isn't undefined, it's underdefined
> ... Again, we ask that if people have inputs for window modes/views,
> we ask for inputs
>
> Marcin: and we're asking for input as quickly as possible
>
> MC: We intend to publish a first working draft (FWD) the first week
> of July
>
> BS: The height and width attribute in P&C have a reference to the
> widget views spec
>
> AB: We need to make sure Widgets VIews talks about which modes would
> support this
> ... Some of us feel that User Agents should have flexibility wrt
> what modes might support this stuff
>
> BS: This should be easy, right?
> ... Which attributes are dependent on view modes, and which are
> independent. and could we have a table?
>
> AB: That sounds great for someone to write
>
> <scribe> ACTION: Bryan to make a table (if it's easy) [recorded in
> [26]http://www.w3.org/2009/06/10-wam-minutes.html#action03]
>
> <trackbot> Created ACTION-357 - Make a table (if it's easy) [on
> Bryan Sullivan - due 2009-06-17].
>
> Testing
>
> Kai: Widget testing. My name is Kai Hendry. I work for Aplix
> Corporation.
> ... I spend one day a week on the Mobile Web Testing group, which a
> w3 wg
> ... Have you heard of the Mobile Web Compatibility Test for Mobile
> Browsers?
>
> (many hands raise)
>
> scribe: Widget Tests!. So I started months ago
> ... Marcos told me that some things were stable, so I started
> working.
>
> <DKA> Web Compatibility Test for Mobile Browsers:
> [27]http://www.w3.org/2008/06/mobile-test/doc.html
>
> [27] http://www.w3.org/2008/06/mobile-test/doc.html
>
> scribe: I wrote a blog about these tests
>
> <DKA> I am a big fan.
>
> scribe: I wrote a bunch of zip files for testing
>
> <hendry> [28]http://wtf.webvm.net/
>
> [28] http://wtf.webvm.net/
>
> scribe: That's the next thing I've been doing, with a guy named
> Robert from Opera
>
> [29]http://dabase.com/
>
> [29] http://dabase.com/
>
> [30]http://dabase.com/blog/Widget_Test_Framework/
>
> [30] http://dabase.com/blog/Widget_Test_Framework/
>
> Kai: The idea with WTF is you point your Widget Runtime....
> ... there is a test harness
> ... did you want to write some tests? i could show you how this
> works :)
> ... A lot of the tests are automated in that you have a config.xml
> and the widget would load, and you would query it with the widget
> API to see if the widget would load
> ... You would load the widget, test a property and see if it's
> correct and post a result
> ... To get more done, it would be good if the spec was stable
> ... If you want to help out, you could provide some tests
> ... Or if you wanted me to add something, you could email me
>
> Benoit: do you have any target objectives?
>
> Kai: not really. I tried to pin it to when the spec was going to be
> stable, but that stopped being realistic
> ... It's been a learning experience
> ... At first I wrote things by hand
>
> <DKA> hand
>
> Kai: I learned from Opera to use JS to generate tests
>
> MC: I think we will contribute stuff
>
> Kai: The [Opera] Spartan stuff is really cool, because it can do
> stuff with (green/red) colors on the screen
>
> AB: I have some questions
> ... Kai, at one point in time you were maintaining this CVS
> repository
>
> Kai: I use git and dump to Dom, and he pushes to CVS
>
> <scribe> ACTION: Art to coordinate with Kai and Dom [recorded in
> [31]http://www.w3.org/2009/06/10-wam-minutes.html#action04]
>
> <trackbot> Created ACTION-358 - Coordinate with Kai and Dom [on
> Arthur Barstow - due 2009-06-17].
>
> AB: The LC period for P&C ends June 19
> ... Assuming we don't get any major issues in the next 9 or 10 days,
> and we should enter Candidate by the end of the month
> ... In order to begin the Candidate phase is to define how we get
> out of Candidate phase by declaring a call for implementations
> ... which involves us defining a complete test suite
>
> MC: how do we judge if the changes we've made to the spec are
> substantive enough to prevent us from doing CR v. LC?
>
> MS: The WG decides
>
> <anne> (Actually, per the Process document you'd have to go back to
> WD even, not another LC, as I understand things.)
>
> <anne> (And it's a MUST requirement too. Substantive change is
> defined here:
> [32]http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-c
> hange )
>
> [32] http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change
>
> AB: What he says is true
> ... that assumes we've had a substantial comment
>
> <anne> (Actually, Marcos already made a substantive change...)
>
> Benoit: We've already raised this question
>
> MC: He's made the assertion that we've made substantive changes
>
> DA: I'm saying that what constitutes substantive changes is up to
> the Chair
>
> RB: A good definition of a substantive changes is something which
> would cause an existing implementation to cease to be conformant
>
> <tlr> the important point when going to CR is "does the change
> invalidate previous review"
>
> <anne> it's all defined in the above link
>
> MC: There are a bunch of changes, including an l10n change yesterday
>
> <anne> new rules for case sensitivity of folders certainly would
> affect any implementation
>
> AB: We can as long as we the working group by consensus determine
> that the changes are substantive
>
> RB: What we have to do is list the changes in the transition request
> ... and then it's up to the director to decide
>
> MS: Ultimately, that's what it comes down to, and that's where it
> would be arbitrated
>
> Action-5?
>
> <trackbot> ACTION-5 -- Olli Pettay to produce test template for D3E
> -- due 2008-06-25 -- CLOSED
>
> <trackbot> [33]http://www.w3.org/2008/webapps/track/actions/5
>
> [33] http://www.w3.org/2008/webapps/track/actions/5
>
> Action-358?
>
> <trackbot> ACTION-358 -- Arthur Barstow to coordinate with Kai and
> Dom -- due 2009-06-17 -- OPEN
>
> <trackbot> [34]http://www.w3.org/2008/webapps/track/actions/358
>
> [34] http://www.w3.org/2008/webapps/track/actions/358
>
> AB: Kai, is it safe to assume that Dom is in the loop that he's
> checked on the License status?
>
> Kai: The copyright is probably my employer. But we're flexible
>
> <Marcos> /me hhmmmm... "Show evidence of wide review.".... wonder
> how that will apply to Widgets Dig Sig.
>
> <scribe> ACTION: Art to work with Mike and Dom and Kai on the
> license+copyright on the Test Suite [recorded in
> [35]http://www.w3.org/2009/06/10-wam-minutes.html#action05]
>
> <trackbot> Created ACTION-359 - Work with Mike and Dom and Kai on
> the license+copyright on the Test Suite [on Arthur Barstow - due
> 2009-06-17].
>
> AB: Kai, the spec that's most ready for testing is the Digital Sig
> spec
>
> <scribe> ACTION: Art to ping TLR and FH regarding reuse of
> XMLDigSig1.0 Test Suite [recorded in
> [36]http://www.w3.org/2009/06/10-wam-minutes.html#action06]
>
> <trackbot> Created ACTION-360 - Ping TLR and FH regarding reuse of
> XMLDigSig1.0 Test Suite [on Arthur Barstow - due 2009-06-17].
>
> Kai: Do they have a test suite for 1.0?
>
> <tlr> the tests for 1.1 were very, very specific
>
> RB: They have one, there's been a requirement to reach PR to have a
> test suite
>
> <tlr> strike 1.1, make that 2nd ed
>
> JS: tlr, is there a link?
>
> AB: The assumption is that we'd be able to leverage that test suite
>
> Kai: their suite should be simple, right?
> ... and detached, applicable to SHA256 and x509....
>
> <scribe> ACTION: Art to find or create examples of widgets digital
> signature documents - helloWorld [recorded in
> [37]http://www.w3.org/2009/06/10-wam-minutes.html#action07]
>
> <trackbot> Created ACTION-361 - Find or create examples of widgets
> digital signature documents - helloWorld [on Arthur Barstow - due
> 2009-06-17].
>
> AB: Anything else on testing?
> ... I think we should pause and look at anne's submissions
>
> <darobin> <anne> I don't like the link colour, it should be pink
>
> AB: Kai, would you walk us through an example?
>
> <anne> pink is dafunkz
>
> (Kai puts up his test framework)
>
> <[38]http://wtf.webvm.net/>
>
> [38] http://wtf.webvm.net/%3E
>
> Kai: Questions?
>
> MC: How do you record which assertion from the spec you've tested
>
> Kai: I've tried to name things sensibly
> ... After the chapters of your specification
>
> <darobin> one example:
> [39]http://www.w3.org/Graphics/SVG/1.2/Tiny/ImpReport.html
>
> [39] http://www.w3.org/Graphics/SVG/1.2/Tiny/ImpReport.html
>
> Kai: The Bondi Widget runtime is likely to be one of the two
> interoperable implentations
>
> RT: Kai's statement was overly enthusiastic
>
> DA: it's a possible candidate
>
> AB: Meeting Adjourned
>
> RRSAgent: Make minutes
>
> Summary of Action Items
>
> [NEW] ACTION: Art to coordinate with Kai and Dom [recorded in
> [40]http://www.w3.org/2009/06/10-wam-minutes.html#action04]
> [NEW] ACTION: Art to find or create examples of widgets digital
> signature documents - helloWorld [recorded in
> [41]http://www.w3.org/2009/06/10-wam-minutes.html#action07]
> [NEW] ACTION: Art to ping TLR and FH regarding reuse of XMLDigSig1.0
> Test Suite [recorded in
> [42]http://www.w3.org/2009/06/10-wam-minutes.html#action06]
> [NEW] ACTION: Art to work with Mike and Dom and Kai on the
> license+copyright on the Test Suite [recorded in
> [43]http://www.w3.org/2009/06/10-wam-minutes.html#action05]
> [NEW] ACTION: Bryan to make a table (if it's easy) [recorded in
> [44]http://www.w3.org/2009/06/10-wam-minutes.html#action03]
> [NEW] ACTION: Marcos to define installation and instantiation
> [recorded in
> [45]http://www.w3.org/2009/06/10-wam-minutes.html#action01]
> [NEW] ACTION: Mhanclik to investigate definitions of installation
> instantiation in BONDI work [recorded in
> [46]http://www.w3.org/2009/06/10-wam-minutes.html#action02]
>
> [End of minutes]
>
>
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 12 June 2009 11:54:55 UTC