<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 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 - 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> http://www.w3.org/mid/op.uq3g00j2idj3kv@zcorpandell.linkoping.osa

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

http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0268.html

DS: missing image - defined in html5?

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

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/added/be added/
Succeeded: s/are hints/are not hints/
Succeeded: s/easily override it with real values/easily override it with real values, by giving intrinsic dimensions to the video element or the SVG itself/
Succeeded: s/Tint/Tiny/
Succeeded: s/for the tables/in a table cell/
Succeeded: s/gueg/guag/
Found ScribeNick: Italian-Chris
Inferring Scribes: Italian-Chris
Default Present: Shepazu, ed, [IPcaller], heycam, +39.524.9.aaaa, anthony, +39.524.9.aabb, ed____, Chris
Present: Shepazu ed [IPcaller] heycam +39.524.9.aaaa anthony +39.524.9.aabb ed____ Chris
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0290.html
Found Date: 23 Mar 2009
Guessing minutes URL: http://www.w3.org/2009/03/23-svg-minutes.html
People with action items: ad cameron doug ednotes