SVG Working Group Teleconference -- 03 Mar 2011

<trackbot> Date: 03 March 2011

<tbah> OK, thanks.

<anthony_nz> Scribe: Anthony

<anthony_nz> ScribeNick: anthony_nz

CSS 3D Object Position

ED: Ties into the discussion yesterday about images and aspect ratio
... CSS 3 has the new object fit properties
... they effect how images are hard positioned and extended in the image tag
... it offers more than preserveAspectRatio in SVG
... because you can position the image inside where ever you want
... use Calc even
... not sure how this will effect the decisions made yesterday
... it will definitely effect the case for img

DH: In SVG there is the override for perserveAspectRatio if object fit is specified

<ed> http://testsuites.opera.com/object-fit/README

ED: This is what Opera is doing at the moment
... this is how we've implemented it so far
... There are two things here
... do we want to have object fit and object position in SVG
... and perhaps get rid of preserveAspectRatio

CM: Not sure about getting rid of
... I mean we should have the properties apply to where preserveAspectRatio applies

ED: Positioning inside a viewport is nice
... for other things it's mostly the same
... the difference being it's a property and not an attribute

DS: Does it solve all the same cases that preserveAspectRatio solves or are there still uses for preserveAspectRatio?

CM: How you can specify preserveAspectRatio defer for an external document

ED: In most cases I think it is more useful to have it as a property and not an attribute

DS: That would let us deprecate an attribute that is not very well understood and not often used

AG: defer is not defined very well

ED: Yes, and I've hardly seen anyone use it

DS: So we can do everything with image-fit
... except for defer behaviour in preserveAspectRatio

CM: We could ask the CSS Working Group if they could add this functionality into object-fit properties

<ed> http://dev.w3.org/csswg/css3-images/#object-fit

ED: For the image element in HTML it will have an effect because the default value for object-fit will be "fill"
... That means it will fill the entire element
... That is the same as preserveAspectRatio "none"
... I don't think that is a change from the tests we did yesterday

CM: That's not the default behaviour of preserveAspectRatio

ED: If you have an HTML img element and you reference an image with preserveAspectRatio set
... it's not clear what happens
... I think that object-fit should override

CM: In your proposal it seems like you want to add a new value "auto" to preserveAspectRatio

JW: In CSS you don't have the knowledge that value is specified. The user should have to actively do something to say that the preserve aspect ratio is kept
... by using defer
... Without doing anything and saying that this overrides
... All reference SVG content will have their preserve aspect ratio will be overridden

CM: You want existing content that doesn't have preserveAspectRatio defined to render the same as if "none" is specified

JW: Seems to me we might need a value of "auto

DH: We might have to insert something to say override object-fit

DS: There are circumstances that an author would want to change the original document

<ed> http://testsuites.opera.com/object-fit/

DS: It would be nice to override what the document thinks the display is

CM: Even without SVG this object fit could effect how raster images are sized

DH: Raster images don't react to their viewport where as SVG does

JW: Having object-fit work on the SVG element the interaction there are even more complicated
... because you have an actual value and it is unclear when it would override
... which is why you'd want an "auto" value

CM: I agree, I think we need an "auto" value

ED: The argument that was made was you can set different defaults depending on the context it was used
... for the Video element it has one default value, where as the default is different for SVG

JW: It still doesn't solve the problem that I want to defer

DS: So "auto" would be "defer" or "fill"

CM: "auto" would mean just do whatever do what preserveAspecrRatio means in SVG currently

DH: I'd like to have "auto" be like "fill" or preserveAspectRatio "none"

<ed> http://testsuites.opera.com/object-fit/

ED: Here is the link to the test suite which has object-fit with SVG and some other test cases; Video, etc
... if you have feedback on this, I'd be happy to hear about it

CM: Does that mean that "auto" should be proposed?

ED: If we think "auto" is useful we should go back to the CSS Working Group with that
... The other issue I want to see resolved is to have the support for object-fit in SVG 2

JW: I still find some of these values not intuitively obvious about that they do

CM: Do we need to talk to them about "none" - was it dropped?

ED: It says it is controversial
... would need a good argument about why it is needed

ROC: I'm a bit worried about it because image sizing is already complicated as it is. It is easy to see how to use it for raster images
... but once you apply it to SVG images it starts getting complicated

ED: I'd say it's easier to use than preserveAspectRatio

ROC: If it's just an override it's not so bad

RESOLUTION: SVG 2 will require object-fit and object-position

<scribe> ACTION: JWatt to Gather up issues regarding object-fit and it's applied to SVG and email CSS Working Group [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action01]

<trackbot> Created ACTION-3001 - Gather up issues regarding object-fit and it's applied to SVG and email CSS Working Group [on Jonathan Watt - due 2011-03-10].

<heycam> roc, http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.svg

Accessibility

DS: SVG should be accessible but is not accessible
... problems are inconsistency between implementations and the lack of normative behaviour of content
... There are different kind of accessibility needs
... [Goes through presentation]
... my proposal is that we undertake to have an SVG Accessibility document that talks about how SVG can be authored
... for accessibility
... We wouldn't be starting from scratch we will be engaging people that already have knowledge and are already working in the field
... There is an Australian thing call NVDA who would be interested in working with us

CM: NVDA is open source

DS: It was installed on every library in New Zealand

CM: Do you see us collaborating with the accessibility groups on this

DS: We'd talk with the people doing ARIA
... I think we should start a different mailing list for SVG accessibility

AD: If a lot of CAD drawings and other schematics go to SVG
... they're going to need to be accessible

ROC: SVG is not semantic and HTML has that same problem with Canvas

DS: SVG is semantic in the sense withing the realm of mathematics. Outside that it's not.

CM: We should take the top 10 types of graphics - information graphics
... and define ARIA roles for them
... Also include guidelines to say when doing a certain type of document uses certain roles and don't do certain things

DS: It would be good to define how to make accessible graphics

CM: What sort of things?

DS: Colour choices
... I feel making a general accessibility document would be good. Perhaps the first thing to do is make one for SVG
... then extract that out
... I've seen cases where different tones were played for the a bar chart to indicate the overall trend in the graph

CM: Sonification

RESOLUTION: We will start an accessibility document for SVG

AG: So you'll be the editor Doug?

DS: Yes, I can be one of the editors. I would like to bring in other people who know the field more deeply

CM: I would like to get in the expertise

z-index

AD: Your proposal solves some of the problems
... if you do enable-background="new" what do with the z-index
... the concept of the stacking context solves this problem

<jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index

AD: main problem is how it would fit in the rendering model
... If you introduce a stacking context when a z-index is specified
... it solves the problem just fine

ED: I haven't read all of the details
... I think it makes sense to add z-index support rather than layered-g

AD: If you don't specify z-index then your performance impact is nothing really. Only if you specify z-index you need to walk the tree twice which isn't too bad

DS: It's better from an authoring perspective

AD: I wouldn't bother putting any note in until it's shown to be a problem
... or a performance hit
... but I wouldn't expect there to be a performance hit

DS: This is an SVG 2 thing right?

JW: Yes

CM: If there are technical details we can work them out when we are writing up SVG 2

RESOLUTION: We will add Jonathan Watt's z-index proposal to SVG 2

JW: From what I remember CSS talks about how to deal with the background
... and we're not going to get stroke and fill on different levels

CM: The syntax of the property is just the same as CSS?

JW: Yes
... same definition, but with simplified instructions of how it works

<scribe> ACTION: JWatt to Add z-index proposal to SVG 2 [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action02]

<trackbot> Created ACTION-3002 - Add z-index proposal to SVG 2 [on Jonathan Watt - due 2011-03-10].

DS: Would be good to have a diagram showing the layers
... for example showing a document without z-index and then a document with z-index
... this would be good for authors to illustrate how the layers work in the document

JW: applying a filter to an element cause it to create a new stacking context

Text over-flow

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Text-overflow

ED: Some proposed wording for text-overflow in SVG
... It's basically saying if my text is too long clip it or flow it
... This property is defined in CSS 3
... It's not defined there for SVG
... but it is something we could apply to SVG elements
... My proposal is to add to SVG text element and SVG textArea (in Tiny 1.2)

ROC: It wouldn't take effect if you just had a clipping thing that contains text
... If it doesn't have a width it doesn't do anything
... HTML 5 Canvas Text has something useful
... What they do is they say here's the text and here's the width. If it's too big shrink the width
... and increase the height

ED: You can already do that with textLength attribute
... This is different
... one of the differences is this is for blocks of text

CM: What would happen with tspans and absolute position of glyphs

ED: Good question
... this proposal doesn't solve all of the issues
... I have at least 10 that I could think of
... So we would need to solve these
... I don't have any strong opinion on how we solve these

CM: With the CSS one what happens when you get selection range?

ROC: Do you talk about the placement of the glyphs with BiDi

ED: Yes, I did
... same as CSS

ROC: I'm not so happy with the behaviour, but it is the same between the two
... CSS and SVG

ED: In order to get the ellipsis you need to specify overflow

CM: I still think that SVG does need some sort of layout things in it
... SVG as it is don't need to worry about overflow property

ED: I think the ellipsis thing is the one thing people want

AD: There is high demand for it in the IPTV world

ED: textArea might be a bit simpler because it already has width and height

AD: It's really ugly to do this in script

CM: You can imagine all different types of ways squashing the text in
... I would like to see font size adjustment to fit things

ED: That would be more a textLength thing

CM: What happens when you have both textLenght specified and width?

ED: If the textLength is longer than the width you'd get ellipsis I guess

CM: I was thinking the other way
... to ellipsis replacement first
... so you'll never get overflowing text using textLength?

ED: No, it will just squash it up

CM: In CSS what happens with styling of the ellipsis?

ROC: In CSS it's either you use the style of the block which declares the overflow but it may have changed

CM: It seems like you want to do closest common ancestor
... but we don't need to solve these issues now

ED: I'd like to see if this can be place in SVG 2

AD: In textArea it should wrap so you don't show an ellipsis. But we've had feedback from editors that it is really ugly
... they want a character by character horizontal scroll
... For the simple case where you have a login box which just does a character by character scroll we never did that
... We had to word wrap it and they had to live with it
... It really restricts the textArea as an editable control

CM: Why not have the functionality on text?

AD: textArea was suppose to be flow container
... that allowed glyphs etc.
... The whole chapter is defined
... we defined all the algorithms for it
... and it was reviewed by the experts in Indesign and they liked the model

DS: This is something that a lot of people want solved

AD: I'm strongly in favour of text-overflow

RESOLUTION: We will add text-overflow in SVG 2

<scribe> ACTION: Erik to Add text-overflow in SVG 2 [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action03]

<trackbot> Created ACTION-3003 - Add text-overflow in SVG 2 [on Erik Dahlström - due 2011-03-10].

CM: The whitespace property, does that have any effect on us?

ED: No

CM: Can we move away from using XML whitespace and use the whitespace property?

ED: That would be nice

DS: How about we say that XML space doesn't do what it did in SVG 1.1

ROC: So drop support for xml:space?
... how much content will break?

CL: None

ROC: Can we remove it from the test suite?

RESOLUTION: We drop xml:space from SVG 2 and remove the relating tests from the SVG 1.1. test suite

ROC: Should warn authors that in SVG 1.1 that this is being deprecated

<scribe> ACTION: Chris to Remove the tests from the SVG 1.1 tests suite that relate to xml:space [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action04]

<trackbot> Created ACTION-3004 - Remove the tests from the SVG 1.1 tests suite that relate to xml:space [on Chris Lilley - due 2011-03-10].

<scribe> ACTION: JWatt to Draft a proposal to use CSS whitespace in SVG 2 [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action05]

<trackbot> Created ACTION-3005 - Draft a proposal to use CSS whitespace in SVG 2 [on Jonathan Watt - due 2011-03-10].

<pdengler> I haven't seen any activity here, are you still out to dinner

<roc> we just got back --- from lunch

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Next F2F

<roc> I booked nine single-person kayaks, the tide is in the morning so we need to be there at 9:30am : http://www.puhoirivercanoes.co.nz/puhoi_river_kayak_trips.htm

<roc> I told them it might only be eight people in the end

http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Next_F2F

CM: jun mailed the list about meeting at the same time/place as csswg in tokyo, in june
... I think we should meet then

AG: google offered meeting space just on the same dates as the csswg meeting
... for the remaining days, canon or kddi can host

DS: maybe some csswg people can stay on for extra days to have meetings with us, rather than eat into their meeting time

<scribe> ACTION: Chris to tell CSSWG that we want to meet them! In Tokyo in June. [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action06]

<trackbot> Created ACTION-3006 - Tell CSSWG that we want to meet them! In Tokyo in June. [on Chris Lilley - due 2011-03-11].

DS: we have colocated in the past with LGM

CL: which is in montreal this year

DS: with SVG Open, which is in Boston

CL: SVG Open is late this year, and in Boston.
... two weeks later is TPAC

AG: there's one week gap between them

DS: I think the Thursday is the workshop, for SVG Open

CL: maybe we could have part of the F2F before SVG Open, then part of it on Thursday/Friday after
... so we can concentrate on feedback we get from SVG Open

DS: one other thing with SVG Open, is that W3C is thinking about having a night, like in Paris
... where there'll be some presentations on teaching SVG, showcasing it, to the general public
... so that's probably going to happen the evening before SVG Open
... I imagine either MS or W3C would be able to provide meeting space there
... while LGM is a good opportunity to touch place with the open source community, and is fun, I'm not sure is as critical as SVG Open
... how many meetings are we planning on having?

CL: we are meant to attend TPAC
... wht aabout Thursday Friday in Boston, after SVG Open
... then 2 days at TPAC

[discussion about Tokyo meeting days]

CL: we could meet on Fri June 3 with CSS WG, take the weekend off, then have our normal 5 day meeting on the following week

<scribe> ACTION: Anthony to coordinate with Fujisawa-san to organise hosting for Tokyo SVG F2F [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action07]

<trackbot> Created ACTION-3007 - Coordinate with Fujisawa-san to organise hosting for Tokyo SVG F2F [on Anthony Grasso - due 2011-03-11].

AG: how about the late year F2F?

CL: go to SVG Open, Mon-Wed, do Thurs-Fri SVG WG meeting
... then the week in between is free
... following week is TPAC

AG: I probably can't make the final Friday of the Tokyo F2F

DS: let's just make it Mon-Thurs on that week then

<scribe> ACTION: Chris to liaise with MS for the F2F meeting around SVG Open [recorded in http://www.w3.org/2011/03/03-svg-minutes.html#action08]

<trackbot> Created ACTION-3008 - Liaise with MS for the F2F meeting around SVG Open [on Chris Lilley - due 2011-03-11].

<pdengler> Could we consider the week of the 26th for the Face to Face in ENgland?

<shepazu> pdengler: we are planning to have 2 days after SVG Open, then the next 2 days at TPAC a week later

<shepazu> could microsoft host the F2F after SVG Open?

<shepazu> pdengler: the problem is, we really need to meet at TPAC

buffered-rendering

<jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/User_controlled_caching_of_rendering

JW: we discussed this a bit, roc alex and myself
... everyone decided that some sort of user control of off screen caching would just end up being misused, or used improperly
... and we'd need to disable it or not recognise it anyway
... implementations can generally detect when things are moved around in a way that would benefit from caching
... so caching would be automatic

<pdengler> I will look into hosting the f2f yes,

JW: one thing that will be an issue is animations, where the start of the animation is immediate and smooth
... that's always going to be a problem with an automatic caching mechanism that detects motion and decides to cache
... if you do some gesture on a webpage that should animate things on the screen quickly, you want it to react immediately
... the whole purpose of using offscreen caching is beause you need responsiveness
... but you might have a couple of frames where it's sluggish
... we used it in a previous job, but in that situation we were able to correct misuses of buffered-rendering because this was a closed system
... in general I think user control of offscreen caching we shouldn't do, at this stage

DH: sounds like your situation where it would be slow initially, on animation start, since it's declarative animation you could detect this

JW: sometimes, but if your begin is something.click, so in response to a user interaction, and if you have lots of these things in the document, and you don't want to cache them all, you still have this issue

AD: also if it's all script

DH: for declarative, you could render the offscreen rendering on the very first sample of the animation
... we currently recompute the world on every sample

JW: there are two parts that make it slow
... there are the first 1 or 2 paints, when ou figure out it's moving, which you can avoid if the animation is declarative
... and the other one is the slow rendering into the offscreen buffer, which you can't avoid even with declarative animation

CM: because these are complex objects you want to buffer?

JW: yes

AD: you could have a limit, say 1 or 2 buffered-renderings in the document, or a certain MB of cache

ED: we've implemented it, and already seen misuse of it
... it says in the spec that if you update the subtree, it says you should rerender it, but it doesn't say when
... there's a bit of free room there for experimenting
... i think it will be hard to harmonize implementations there

AD: what was the motivation for proposing this?

JW: i occasionally hear people requesting it
... I wanted it for one document I was writing

ED: I think it's fine for closed systems, but not sure it's good for the web as a whole

RESOLUTION: We won't add buffered-rendering to SVG 2 unless implementor feedback indicates that it is needed

Connectors

DS: [presents some slides]
... connectors would be a straight line between two nodes
... you can style their appearance
... there would be a list of connectors for navigation purposes
... they wouldn't dynamically position nodes in the graph
... no concept of weighting on edges
... it wouldn't do line routing
... it wouldn't allow automatic drag-and-drop

[rest of the presentation]

DH: seems useful

RO: it seems like a step towards graph layout
... and edge routing

DS: you can draw the lines yourself, the straight line is the default

CM: the part I like the most is the automatic connection to the closest point on a shape
... the semantic part I'm not sure about, without having a whole aria vocab

JW: regarding routing, how about having routing points?
... yes you can have polylines

CM: would it be a separate connector element? how about just sticking some attributes on a <path>?

DS: i like the syntax of a separate element

SVG Integration

DS: I'll give you a brief overview of the document as it stands

<birtles> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

DS: we have "referencing modes for svg"
... they are ways for specifications to say they are using svg in particular contexts
... e.g. css might use a particular referencing mode for images
... html might use one for image and another for iframe
... it describes svg in terms of some specific capabilities -- animation, external references, [...]
... we've talked about having one or two more, but i won't go into the individual referencing modes

RO: why not define those flags as independent things? you might want a combination of flags that's not one of the preset modes.

DS: we could. i did it this way because people in the past have asked "how do I reference SVG, what's a handy name for a set of common flags"
... so we can say it's using "secure animated modes"

CL: you could do both

RO: or you could make the flags normative, and the modes informative

DS: yes, well the modes would be normative, but yes
... network admins, once they understand animated script-less svg is safe for them, they don't have to think about it any more

[shows examples from the spec]

scribe: it also talks about foreign content in svg
... how you can comine -- we don't explicitly talk about using html in foreignObject, in the svg spec
... in SVG Integration we decided we'd actually talk about that
... talking to implementors about considerations about that

DH: might be good to mention plugins and scripts
... i think you can only have plugins in foreignObject in svg
... maybe in the "no script" mode it would mean no plugins

DS: also talks about svg in foreign content
... it also talks about how to extend svg
... this was so that OASIS/ODF would know how best to integrate SVG as a first class citizen
... then we wanted to have a list of all elements/attributes/properties in SVG
... which could be referenced by HTML
... that's all that's in there now. we've talked about other things, compound document scenarios that Tav's talked about
... e.g. svg as a button in an HTML page, or in an img, etc.
... tav will help me draw up some of that
... maybe much of that should be defined by html, it seems it's not addressing that at the moment
... it's worth pointing out specific modes if we think they are useful, e.g. a mode that we know should be used for css backgrounds, we should predefine it

DH: audio/video also

DS: individually, since audio is more annoying

DH: and it's also a subset of video, since video comes with audio

DS: earlier on we talked about how filters would be used in html content, etc.
... but those are in their own specifications at this point

CM: and I think that's going to work fine

DS: I agree
... ultimately I don't know if this should be a part of SVG 2
... I think it might be worth maintaining on its own

CL: I agree
... it's an interface document
... we should publish a FPWD

DS: i'd like to add the flag idea from roc and the audio/video/plugins comments from daniel, first
... i'd estimate probably by the end of the month it'd ready for publication

RESOLUTION: We will publish SVG Integration after Doug addresses feedback

BB: [some comments about whether to allow TimeEvents to be dispatched in animations in SVG-as-img mode]

pointer-events processing and security

RO: [summarises the issue raised a while ago]
... we need to have something around pointer-events
... we do need to be able to have pointer events, make things transparent when alpha=0
... but in a controlled way
... so maybe pointer-events should consider to intersect the entire <image> when the image is cross origin
... so elementFromPoint would always return that element, if the coordinates were within the bounds of that image
... there is also the properites on SVGUseElement, if you are doing cross origin using
... you want to block those

this is ISSUE-2071

ISSUE: SVG2 should block cross origin SVGUseElement property access

<trackbot> Created ISSUE-2407 - SVG2 should block cross origin SVGUseElement property access ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2407/edit .

rechartering

DS: I've been working on the charter document
... addressed some comments from Cameron

<shepazu> http://www.w3.org/Graphics/SVG/WG/charter/2010/

<anthony_nz> Thank you Mozilla for hosting a productive meeting!

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

03 Mar 2011

Attendees

Contents