- From: Chris Lilley <chris@w3.org>
- Date: Mon, 23 Mar 2009 22:03:23 +0100
- To: public-svg-wg@w3.org
Hello public-svg-wg,
Minutes of the 21 March 209 SVG WG telcon are at
http://www.w3.org/2009/03/23-svg-minutes.html
and below as text.
SVG Working Group Teleconference
23 Mar 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0290.html
See also: [3]IRC log
[3] http://www.w3.org/2009/03/23-svg-irc
Attendees
Present
Shepazu, ed, [IPcaller], heycam, +39.524.9.aaaa, anthony,
+39.524.9.aabb, ed____, Chris
Regrets
Chair
Cameron
Scribe
Italian-Chris
Contents
* [4]Topics
1. [5]Additional value for image-rendering
2. [6]Sizing of <video poster=svg>
3. [7]Missing Resources Indicator
4. [8]SVG <title> containing markup or RCDATA
* [9]Summary of Action Items
_________________________________________________________
<trackbot> Date: 23 March 2009
scribe-niick: Italian-Chris
<heycam> ScribeNick: Italian-Chris
Additional value for image-rendering
CL: disable-resampling might give thr idea that the image is at 1:1
with device pixels
... so I prefer nearest-neighbor explicitly
DS: In favour
Cam: [bxxxxxt ... dd ... guh ]
<heycam> CM: should it be added to Core?
<scribe> ACTION: doug to add nearest-neighbor as a value of
image-rendering to Core [recorded in
[10]http://www.w3.org/2009/03/23-svg-minutes.html#action01]
<trackbot> Created ACTION-2500 - Add nearest-neighbor as a value of
image-rendering to Core [on Doug Schepers - due 2009-03-30].
ed: camelCase it or hyphen-ate it?
Cam: camel
CL: Other values are camel -
[11]http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty
[11] http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty
auto | optimizeSpeed | optimizeQuality
DS: Not sure
CL: Is it appropriate to do this as image-rendering is a hint. Whats
the conformance?
Cam: Seems like the other values are not hints
DS: rendering hints are ok for single vendor, get predictable
behaviour
<heycam> CM: for example, optimizeQuality requires something at
least as good as bilinear resampling
CL: Yes, the existing description uses shall
... We want something that forces NN even if, say, there is hardware
support for bicubic
<heycam> CM: there was some support for crispEdges on the mailing
list
<heycam> CM: it's not quite an accurate description, but it is used
by other similar properties
CL: could be confused with photoshop bicubic-sharper though
... at some point we should think about allowing unsharp masking
after image resampling
Sizing of <video poster=svg>
<heycam>
[12]http://www.w3.org/mid/op.uq3g00j2idj3kv@zcorpandell.linkoping.os
a
[12] http://www.w3.org/mid/op.uq3g00j2idj3kv@zcorpandell.linkoping.osa
[13]http://lists.w3.org/Archives/Public/www-svg/2009Mar/0174.html
[13] http://lists.w3.org/Archives/Public/www-svg/2009Mar/0174.html
ED: Have taled with simon, video in html5 can omit defined width and
height, use the intrinsic size from the video which may not be known
before decoding
... so you have poster images to show before the first frame, how
big are they
DS: Where the hell does 300x150 come from?
... seems arbitrary and almost always wrong
... I guess authors can easily override it with real values, by
giving intrinsic dimensions to the video element or the SVG itself
... wonder if it can be changed. Does content rely on this?
ED: Object gives you 100% width, and height from the intrinsic ratio
... This is something we coordinated with fantasai for CSS 2.1 and
Tiny 1.2
<heycam> CM: i guess using 100% width is going to be less useful, if
the video will resize to the intrinsic width of the video once it
starts playing
ED: If you have a table with svg poster frames in a table cell, then
300x150 is much less useful than 100%
<heycam> CM: does 100% mean use the width of the table cell?
CL: Yup, a table cell is a containing block
<heycam> CM: i think 300x150 is the way to go. if you specifically
want the avoid affecting the table cell width, you can put 100% on
it
<heycam> CM: since the instrinsic video size is going to be a fixed
pixel width, and not 100% anyway
ED: Might be
<heycam> CM: if we can't decide now, we can at least reply and give
our reasons for choosing (or not) 300x150
ED: this is not something defined in SVG. Its an html or css issue
DS: Don't agree. Could define default behaviour for generic
languages
... when SVG is used as an image what should it do. is it animated,
scripts run, click through etc
... other languages would want to know what do do - DocBooc, ODF,
XSL FO, and so on
<heycam> CM: should we just get back to them and give them our
various thoughts then?
are we converging on 100% and height from aspect ratio? we can point
to the css 2.1 spec for why
<heycam> CM: i figure that, with typical browser window sizes, 100%
is going to be less close to the final video size than 300x150
<heycam> CM: but in the end i think it's not that important, so i
don't mind too much
its of the containing block, not the window
<heycam> CM: given <img>, <embed> and <object> get 100%, i'd be ok
with going with 100%
It seems odd that CSS 2.1 specifies a behaviour but HTML 5 changes
that to another value
DS: Yes, the CSS rules make more sense here. HTML5 should play well
with CSS
... Fullscreen is a common requirement
... having a way to do that is desirable
... perhaps we could ask CSS WG to do that.
could be triggered by script or transitions or animation
ED: does that only happen for video?
DS: No, used for slideshows too . Covers the chrome
... also good for webapps where the chrome is a distraction
<heycam> CM: maybe an onfullscreen event?
DS: fullscreen mode should only be in response to user interaction
<heycam> CM: although: i can see that you'd want to have a full
screen button like in a youtube player
Missing Resources Indicator
[14]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/026
8.html
[14] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0268.html
DS: missing image - defined in html5?
[15]http://t-shirts.cafepress.com/item/tmwg-missing-image-tshirt/131
168141
[15] http://t-shirts.cafepress.com/item/tmwg-missing-image-tshirt/131168141
cam: make an issue for it
ds: not urgent
<shepazu> there is an HTML convention for this, I'm not sure it's
defined anywhere, but we should add some behavior similar to what
HTML does, in SVG 2.0
SVG <title> containing markup or RCDATA
ds: tiny has different behaviour to head off complaints, and tiny
tends to be for lower end devices. Can excpand in full. No need to
change in Tiny
CL: switch is a good use case, inside title
cam: otherwise the <title>s would be titling the <switch> element
itself
cl: xliff is an industry use case where markup is required
<heycam> CM: are we agreed then that we want markup inside <title>?
yes
<heycam> CM: is continuing to parse in "foreign content" mode what
we want?
<heycam> CM: (i think so)
cl: what does foriegn content mode do?
ok
<heycam> CM: at one point there was talk about allowing only
phrasing content inside <title>
<heycam> CM: so <p> elements e.g. wouldn't be allowed
yeah but a quick display:block can screw that up
<heycam> CM: only if it were rendered in a CSS context
<heycam> CM: which <title> isn't
true
<heycam> CM: we're at least settled on it not being plain text
CM: So it sounds like restricting it to plain text is not a good
idea
<heycam> CM: so someone should reply to the thread on www-svg that
mentioned RCDATA to say that, perhaps
(discussion on member vs public mailing lists; public is preferred)
<heycam> CM: i'll look into the parsing modes in html
cam: title in html ...
<heycam> CM: to see what is appropriate to get <title> working as we
want
ed: whats the current proposal in the svg-in-html spec?
ds: yes, stays as foreign content
cam: urgency?
ds: immediate
cam: state of dfeedback from mozilla?
ds: we have heard from some but not all of them
<heycam> CM: discussions on points that we hadn't agreed upon
haven't progressed really
<heycam> CM: we did say at one point that we'd start off the
proposal document being just the agered upon points
<heycam> CM: but i don't want the others to be forgotten
<heycam> CM: in a recent telcon we agreed that someone should
collate the not-agreed-upon points, so we know where we're at
<heycam> CM: but there wasn't an action assigned for that
we can add ednotes to log the unresolved parts. or create issues
<heycam> CM: yes i think adding ednotes in the proposal document is
reasonable
<heycam> CM: so that when we submit it to the HTML WG they can see
which things we haven't decided on yet
cl: agreed
<heycam> CM: somebody needs to find those not-agreed-upon points
though; it's not obvious to me right now what they are
<scribe> ACTION: cameron make the spec golden wonderful [recorded in
[16]http://www.w3.org/2009/03/23-svg-minutes.html#action02]
<trackbot> Created ACTION-2501 - Make the spec golden wonderful [on
Cameron McCormack - due 2009-03-30].
<heycam> ACTION-2501: Add happy rainbow unicorns
<trackbot> ACTION-2501 Make the spec golden wonderful notes added
<scribe> ACTION: cameron make the spec golden wonderful with ponies
and rainbows, and twinkly glitter dust [recorded in
[17]http://www.w3.org/2009/03/23-svg-minutes.html#action03]
<trackbot> Created ACTION-2502 - Make the spec golden wonderful with
ponies and rainbows, and twinkly glitter dust [on Cameron McCormack
- due 2009-03-30].
<scribe> ACTION: cameron ad ednotes to the svg-in-html spec noting
points where agreement is still lacking [recorded in
[18]http://www.w3.org/2009/03/23-svg-minutes.html#action04]
<trackbot> Created ACTION-2503 - Ad ednotes to the svg-in-html spec
noting points where agreement is still lacking [on Cameron McCormack
- due 2009-03-30].
close action-2501
<trackbot> ACTION-2501 Make the spec golden wonderful closed
close action-2502
<trackbot> ACTION-2502 Make the spec golden wonderful with ponies
and rainbows, and twinkly glitter dust closed
adjourned
Summary of Action Items
[NEW] ACTION: cameron ad ednotes to the svg-in-html spec noting
points where agreement is still lacking [recorded in
[19]http://www.w3.org/2009/03/23-svg-minutes.html#action04]
[NEW] ACTION: cameron make the spec golden wonderful [recorded in
[20]http://www.w3.org/2009/03/23-svg-minutes.html#action02]
[NEW] ACTION: cameron make the spec golden wonderful with ponies and
rainbows, and twinkly glitter dust [recorded in
[21]http://www.w3.org/2009/03/23-svg-minutes.html#action03]
[NEW] ACTION: doug to add nearest-neighbor as a value of
image-rendering to Core [recorded in
[22]http://www.w3.org/2009/03/23-svg-minutes.html#action01]
[End of minutes]
--
Chris Lilley mailto:chris@w3.org
Technical Director, Interaction Domain
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
Received on Monday, 23 March 2009 21:03:38 UTC