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

Minutes, 21 March 209 SVG WG telcon

From: Chris Lilley <chris@w3.org>
Date: Mon, 23 Mar 2009 22:03:23 +0100
Message-ID: <46330906.20090323220323@w3.org>
To: public-svg-wg@w3.org
Hello public-svg-wg,

Minutes of the 21 March 209 SVG WG telcon are at

and below as text.
                   SVG Working Group Teleconference

23 Mar 2009


      [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


          Shepazu, ed, [IPcaller], heycam, +39.524.9.aaaa, anthony,
          +39.524.9.aabb, ed____, Chris




     * [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

   <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

   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

   <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

   <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>


     [12] http://www.w3.org/mid/op.uq3g00j2idj3kv@zcorpandell.linkoping.osa


     [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

   <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
   ... 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/0268.html

   DS: missing image - defined in html5?


     [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

   cl: xliff is an industry use case where markup is required

   <heycam> CM: are we agreed then that we want markup inside <title>?


   <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?


   <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


   <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

   <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

   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

   <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

   <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

   <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

   <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


Summary of Action Items

   [NEW] ACTION: cameron ad ednotes to the svg-in-html spec noting
   points where agreement is still lacking [recorded in
   [NEW] ACTION: cameron make the spec golden wonderful [recorded in
   [NEW] ACTION: cameron make the spec golden wonderful with ponies and
   rainbows, and twinkly glitter dust [recorded in
   [NEW] ACTION: doug to add nearest-neighbor as a value of
   image-rendering to Core [recorded in

   [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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC