SVG Working Group Teleconference -- 16 Aug 2012

<trackbot> Date: 16 August 2012

<pdr> Hi, I am [Google].

<heycam> https://www.w3.org/2002/09/wbs/19480/SVGLucerne2012/results

<scribe> scribenick: nikos

heycam: first we'll have an introduction from Rich

richardschwerdtfe: I'm involved in a number of w3 efforts on accessibility
... I work for IBM. CTO for accessibility in software
... what I'm interested in svg2 is having it as accessible as possible for the svg2 release
... next week Ican go through the gap analysis we did if yo ulike
... i'll send a doc for review before then

heycam: We have a F2F coming up, might be a bit soon for you to attend

richardschwerdtfe: I probably won't be able to make it
... I have one question - in terms of accessibility work, are you looking for content changes?

heycam: generally we have people pitching into the documents that they can
... Tav and I probably do the most editorial work

richardschwerdtfe: I'm happy to pitch in then

Publication of FPWD of SVG 2

heycam: This is a reminder that we're scheduled to publish Tuesday next week
... I'm going to do clean ups this morning and then send off request to the webmaster
... so if you have any changes (that aren't controversial) get them in now

Sizing of SVG and HTML

pdr: Hi, I'm from Google on the Chrome team
... I'm implementing the sizing stuff, where you have image with svg in it

<heycam> https://docs.google.com/document/d/1gDnYxvqIMPjs4TThwc5N0Jc6qgIKlrgPaYJglsvrjtI/edit?pli=1

pdr: what I can tell, this is really underspecified in the spec - all browsers are different
... I thnk Firefox is the best implementation
... I was wondering if we could clean up the spec and converge on their approach

<pdr> https://docs.google.com/a/chromium.org/document/d/1gDnYxvqIMPjs4TThwc5N0Jc6qgIKlrgPaYJglsvrjtI/edit?pli=1

pdr: I listed the various permutations of svg file
... you can click on the bottom and I have a list of results - you can see how they differ

heycam: I was wondering if you could summarise the behaviour of FF

pdr: for the basic things - all are right
... differences when you hav ean image with a width and an svg width property and they differ (attribute or property)
... if you look at the table in my doc
... last 2 rows are an example of this

heycam: Am I right that the svg width property doesn't seem to be doing anything

pdr: that's right. that's the path mozilla took and it's as good as any

krit: svg in image tag?

pdr: that's the first table
... second is inline svg
... my request for the WG is to clean this stuff up

heycam: this has been an open issue for a while and we are keen to fix it up

pdr: would you like someone to write it up?
... I have a test suite that matches mozilla behaviour - we could spec it from that

krit: regarding embedding svg image inline - do we want to differ between width attribute and property in future, when we move to presentation attribute?
... Canvas is a bit different than SVG
... Canvas has resolution

Tav: The equivalent in SVG is the viewport size

krit: for inner svg element, would there still be separate width attribute and property?

heycam: currently the width property on inner svg element doen'st do anything?

all: right

krit: I'd like to specify something that is common for all browsers

shepazu: pdr, can you write the specification from the data you have?

heycam: If you could write up the rules from the sizing, that would be helpful

pdr: ok

shepazu: we talked about adding the viewbox value auto, which automatically sets the viewbox to the bounding box of the containing shapes

pdr: how would you like me to do this?
... email results to www-svg?

all: yes

heycam: we'll wait for a resolution until you write up the rules
... is everyone ok that we move forward?

shepazu: I think the general approach is fine, it's a good way forward

Resolution: Address the question of SVG sizing

Filter Effects - clipping of subreagions

krit: I can summarise.
... we have an issue in the filter effects spec where we might mwant to specify a keyword or property that allows the author to clip the input or output or nothing
... since we haven't decided if we want just input or output I'd like to delay this
... it would be good to get Erik's input
... we discussed this last week and resolved to ask Erik about it

Filter Effects - dx and dy with primitiveUnits="objectBoundingBox"

<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feOffsetElement

krit: I just realised that dx and dy take numbers and percentages
... some browsers support percentages

heycam: is it useful to support percentages?

krit: I would expect that percentage is relative to either viewport or object depending on primitiveUnits
... I think it's ok to have numbers that act as percentages
... I think we shouldn't chane the specification

heycam: if we have percentages it might seem like we can take arbitrary lengths as well
... percentages are separate from lengths in css?

krit: yes

heycam: I'm looking at other things that take 0-1 number values
... the new filter shorthand property value takes number as well as percentage
... I'm wondering if there's an expectation that values that take 0-1 are a ratio

krit: if you put 0.5 with primitiveUnits="objectBoundingBox" it means 50%
... with the other value of primiteUnits it means 0.5 * the unit

heycam: I think it would be good to get Erik's input - are you happy to talk about it when he's back?

krit: yep

CSS Masking

krit: I want to summarise

<krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html

krit: I brought up a short first draft
... it specifies what webkit is doing with css msaking as well as waht firefox is doing with svg masking
... mask-repeat, etc are all shorthand for the webkit properties
... I think they can apply to svg in the same way
... the css wg isn't in favour of using all these properties
... not all these properties make sense for svg
... such as mask-attachment, clip and origin
... I think we could remove these for svg
... so far no one in css has objected to clip-paths

heycam: all those mask properties - they are things that webkit currently supports for html content?

krit: mask-attachment doesn't do anything in webkit, mask-type you can select between luminance and alpha masks
... the editorship of the specification, I'd like to delay to next css meeting, to see if they reject completely or decide to go on
... they are worried that they have too many specifications on the go

heycam: you were going to look at whether you could supply resources for editing the spec weren't you?

krit: it depends on css wg, whether they reinvent the wheel or not. It may be too much work
... if it's just removing properties and changing behaviour of properties then it's ok

heycam: I think it would be a bit silly to do everything from scratch
... currently clip-path stuff is in the spec

krit: no one from css objected to it yet

heycam: maybe because they haven't thought about it properly yet
... it would be good for us to review it also

krit: there are some descriptions missing, but the general intent of the spec sould be clear
... css wg is looking at aligning mask feature with specific part of element, i.e just mask border or just content

heycam: that seems similar to shaders, with filters applying to different parts

krit: it might apply to svg elements once we support vector effects, i.e. i just want to have mask on stroke or fill

heycam: even without full vector effects we could support that

krit: dont know if we will fit this in svg 2

heycam: if the css wg doesn't want to take it on, what will be the way forward?

krit: I think it's reasonable to define what webkit already does

heycam: Brian said he probably doesn't have time to be a full editor

krit: css wg meet is in 2 weeks so we'll see what they say

heycam: for the moment the masking chapter is in the svg 2 spec - it's probably a bit early to point to the new document
... I think the direction is good though
... I might agree with comments about proliferation of the background style property and whether we can cut some out
... just a reminder to register for the F2F

<heycam> https://www.w3.org/2002/09/wbs/19480/SVGLucerne2012/

krit: just one more thing - css wg has decided to publish draft of filter effects

heycam: I noticed css working group resolved to include scientific notation
... there was some opposition but it got through

- DRAFT -

SVG Working Group Teleconference

16 Aug 2012

Attendees

Contents

Publication of FPWD of SVG 2

Sizing of SVG and HTML

Filter Effects - clipping of subreagions

Filter Effects - dx and dy with primitiveUnits="objectBoundingBox"

CSS Masking

Summary of Action Items

Scribe.perl diagnostic output