See also: IRC log
<MikeSmith> trackbot, start meeting
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
<MikeSmith> peh
<MikeSmith> timeless: ↑
Date: 4 December 2009
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
<marcos> Zakim: , IPcaller is I
AB: any change requests?
... try to allocate time for Window Modes
... any other requests?
[None]
AB: only more VC this year -
December 18
... that date coincides with the publication moratorium for the
rest of the year
<timeless> zakim +358 is Jere
<arve> Zakim: aabb is me
AB: see
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0340.html
... Marcos, quick update and issue coverage
MC: in the Widget package we
don't have a header (like HTTP)
... so we need to define a mapping of file extenstions to Media
Type
... I have now submitted a proposal to the list
... It uses HTML5's content sniffing algorithm
Arve: I think Henri's proposal is basically OK
MC: I'm divided on it
... and still investigating
Arve: two things make sense
here
... As Henri said, a simple solution is a good one
... If rely on sniffing, can have some probs with older HTML
docs
... I'm concerned we can break some widgets e.g. layout
... May also have probs with document.write()
... If a document is labeled .txt and is actually HTML, a
browser will treat it as HTML
MC: the proposal is to check file extension first and if that fails, revert to content sniffing
AB: you mean what is in the ED
now?
... http://dev.w3.org/2006/waf/widgets/#files
MC: yes
Arve: need to look at what Hixie
wrote about this earlier
... I don't think we should do content sniffing
AB: we have at least member of
the WG that has reservations re content sniffing.
... Any other feedback
<arve> <ArtB> ... If a document is labeled .txt and is actually HTML, a browser will treat it as HTML
AB: Mike, anything you want to mention on this issue?
<arve> that is not what I said
<arve> browsers will not try to sniff it
MS: in HTML5 we aren't really covering sniffing by file extension
AB: Arve, let's correct what I minuted re sniffing
Arve: browser will treat it as a plain text file
<timeless> zakim: +44 is Mark
Arve: I think the common sense
solution is to specify what browsers are actually doing
today
... we don't want to specify something that isn't being done
today
... If we need a way to override that, then we could define an
author mapping mechanism
<marcos> MC: for instance, .php text/html
AB: Marcos, what's the next step
MC: do we want to define the overide format for v1?
Arve: I think not
... this hasn't been a problem for Opera widgets
AB: sounds like we have a
resolution: we will not define an override format/mechanism for
v1
... any objections?
[None]
RESOLUTION: we will not define an override format/mechanism for v1
AB: what additional guidance do you need on this topic, Marcos?
MC: I just need to document
this
... Wondering if there are any concerns about the requirement I
proposed
<marcos> http://dev.w3.org/2006/waf/widgets-reqs/#r12.-
AB: I don't have any major issues with this
Arve: I don't understand the need for this requirement
MC: I think we need this to
provide guidance on how UAs process the files
... I think we will have some interop issues if we don't
specify this
AB: do you see this req as harmful, Arve?
Arve: I don't object to it; I
just don't see a need for it
... I don't think it will change the behaviour of UAs
AB: when I read that section, I don't see prescriptive text
MC: yes, I need to work on it; plan to do so today
AB: where do we stand on this
issue?
... http://www.w3.org/2008/webapps/track/actions/231
MC: this is related to the topics
for next week's security workshop
... I am expecting related discussions next week
... At the moment, I think the text in the spec is OK
... But want to revisit this based on the Workshop outcomes
Arve: I agree with that reasoning
MC: I'd like to close
Arve: let's wait until next VC
MC: OK
AB: proposal is
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0398.html
... is this blocking you Marcos?
MC: no
... there is some inconsistency we need to fix
AB: my inclination is without
strong opposition to let the Editor make a proposal
... and then codify it
... any comments on the proposal
<marcos> MC: do we really need <author img="">?
AB: without a compelling use
case, I favor removing syntax
... do you have enough feedback, Marcos?
MC: yes
... we may want to expand on this in V2 but I will remove it
now
AB: any problems or issues with that?
[None]
AB: Marcos proposal:
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0403.html
... this has been an open issue for a while
... we discussed it in Mandelieu for example
Arve: it is a hard prob
... Opera has a notion of window modes
... Perhaps it should be deferred to v2
... It needs to be in some spec but perhaps not the P&C
spec
AB: what would we do, syntactially then, for the author?
<marcos> MC: syntactically, <widget mode="someMode">
MC: in the spec we list the mode values but not the behavior
Arve: I don't see the need for a
default
... letting the impl decide can lead to some probs
... e.g. a mobile impl may default one way and desktop default
a different way
... could specify the first four opts and then let the impl
decide the default
... I could reply with some info about our impl
MC: yes, please do
JS: with the N97, there are things on the home screen that looks like widgets
AB: I don't know if S60 widgets has support for this semantics
[ Discussion about sizes for widgets ]
MC: I can check with Orange to see what they have
JK: I will check S60 and report back if I find anything useful
MP: if I find some useful info I
will submit it
... what do you expect to specify in the P&C spec,
Marcos?
MC: we need some more information than what I included in my e-mail
AB: what do you plan to do in the next few day?
MC: I will flesh out the definitions of these modes and refine their names
AB: our plan for several months now is to publish a LCWD of P&C spec by the end of 2008
<arve> ArtB: sorry about interrupting, but I have a hard deadline for now, as I have a train to catch
AB: I want to know what people think here
MC: I do indeed want to publish the LC this year
<arve> I support as-is with the changes outcome of this call
Arve: yes, I do support publishing a LC if it reflects today's discussion
MP: will there be a review period from the 11th to 17th?
AB: yes
MP: If something on the feature element comes out of the Security WS, I'd like an opportunity to reflect that in the LC doc
AB: understood
MP: given this, I support LC
JK: no specific opinion; need to
abstain but generally positive
... need to look at the I18N part
JS: I need to look at it
MC: if Jere can look at the I18N
stuff, that would be good
... there is one error I need to fix but otherwise it is
stable
... I would appreciate it if we could get a complete review of
the spec prior to going to LC
JS: ping me on Monday or Tues and I'll try to do it
AB: plan is to begin a CfC on Dec 11, end it on Dec 17 and submit pub request on Dec 18
AB: does anyone object proposed
directory for the test suite?
... Marcos, have you looked at the test?
MC: yes, some; need to do more
research
... want to make sure Kai is interpreting the spec
correctly
AB: I'll respond to Dom that we
prefer using the widgets CVS directory as opposed
... any objections?
[None]
AB: start thinking about the end
of Feb
... any other topics?
... 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/talking about file sniffing/covering sniffing by file extension/ Succeeded: s/could make/could define/ Succeeded: s/MC: I don't/Arve: I don't/ Found Scribe: Art Found ScribeNick: ArtB Default Present: ArtB, Josh_Soref, Mike, marcos, +358.503.85aaaa, Jere, +47.23.69.aabb, arve, +44.771.751.aacc, Mark WARNING: Replacing previous Present list. (Old list: Art, Josh, Mike, Marcos) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ +Jere WARNING: Replacing previous Present list. (Old list: +Jere) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ +Arve WARNING: Replacing previous Present list. (Old list: +Arve, Mark) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Art, Arve, Marcos, Jere, Josh, Mark, Mike Present: Art Arve Marcos Jere Josh Mark Mike Regrets: David Claudio Thomas Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0360.html Found Date: 04 Dec 2009 Guessing minutes URL: http://www.w3.org/2008/12/04-wam-minutes.html People with action items:[End of scribe.perl diagnostic output]