SVG Working Group Teleconference -- 12 Mar 2015

<trackbot> Date: 12 March 2015

<heycam> nikos, did I forget to update the date in the URL :(

<nikos> yep =)

<scribe> ScribeNick: AmeliaBR

Telcon time

Doug: We should have a telcon time. And debate for an hour.

Cam: I think last time we sent out a list of proposals and selected from it

Doug: Can we re-use the options from last time, or do we have to restart?

Cam: I don't think we really checked everyone's availability, so we might as well check.
... I'll send an email in the next few weeks, before Europe goes to summer time.

Transform on SVG View

ED: I think we should postpone until we have more replies to Amelia's email.

Amelia: I suspect after a while we can assume if no replies, then no one cares too much and we can decide. But delay for another week.

Controlling box-sizing for ObjectBoundingBox units ("box-rendering" property?)

<heycam> http://www.w3.org/mid/CACfsppBMiK-0uRJrxTgq4Ke-5xyHQDF42tqHpteSM2ct+1bmLg@mail.gmail.com

Cam: Proposal on email list from Paul LeBeau
... Since we have multiple options for getBBox, can we use this for paint servers
... As we all know, paint servers on strokes are messed up

(particularly for horizontal/vertical lines!)

Cam: ... Paul's proposal was a separate bbox-rendering property

ED: Don't we have something like this from masking

Cam: Yes, that was my comment as well

<ed> http://dev.w3.org/fxtf/css-masking-1/#the-clip-path

<birtles> http://dev.w3.org/fxtf/css-masking-1/#the-mask-origin ?

Cam: you declare the reference box in the property

<ed> http://dev.w3.org/fxtf/css-masking-1/#the-mask-clip

Cam: I would like to see a similar structure.

Doug: Agreed. Good idea, lets figure out how best to make it work

Amelia: +1 to using the same syntax

Tav: I think the problem with a separate property is what if you wanted different reference box for fill or stroke.

Birtles: In masking, they actually are separate properties, but then there's a shorthand syntax

Cam: Yes, I'd forgotten that. I think that is an argument for creating a separate property, but different properties for fill and stroke

Amelia: And we should use a similar naming convention, whatever that is

Cam: There is the mask-origin property, nothing currently for clipping

Tav(?): That doesn't stop us adding one

<birtles> there's also http://dev.w3.org/csswg/css-ui-3/#box-sizing

Amelia: There should be one, for the same reason: the clip path can be an SVG path with objectBBox units

Cam: Currently, in clip-path you specify the reference box as part of the main property, it hasn't been split out
... Since clippath uses one property and masking splits it, I suppose we can choose which to follow

Amelia: One thing to consider is the multiple fill/stroke syntax. Might be convenient to have a separate property that applies the reference box for all values in that list

Cam: That's right, it's after all a common enough syntax for background properties
... Also you could specify it once on the SVG for the whole graphic

Amelia: Would it be an inherited property? Fill/stroke are, but mask, clip, background etc. aren't

Cam: We should mirror the inheritance I think
... so inheritance would be the same as fill and stroke
... Ok. Then if there is a separate property, would fill and stroke become shorthands, with additional properties for other parts?

Amelia: The idea of using fill and stroke as shorthands has come up before, e.g. when talking about contextStroke/fill keywords

https://lists.w3.org/Archives/Public/www-svg/2015Jan/0012.html

ED: We also have to think about what happens for elements which don't have these types of BBoxes

Doug: Let's ask for a proposal and think about all the details then

ACTION on Cameron: Reply to Paul's email regarding BBox reference for paint servers

<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: Cameron to Reply to Paul's email regarding BBox reference for paint servers [recorded in http://www.w3.org/2015/03/12-svg-minutes.html#action01]

<trackbot> Created ACTION-3772 - Reply to paul's email regarding bbox reference for paint servers [on Cameron McCormack - due 2015-03-19].

SVG 2 status

Cam: Tav we were still working on the text chapter?

Tav: I think we covered everything that can easily be decided

Cam: There was one issue in the Styling I wanted to discuss -- Issue 25
... Animation of presentation attributes

There was text that animating presentation attributes was equivalent to animating CSS, but there was a problem.

<birtles> https://bugzilla.mozilla.org/show_bug.cgi?id=1062106

Birtles: There was, but we have a bug report to fix it in Mozilla ^^^

<heycam> "Animation of presentation attributes is equivalent to animating the corresponding property. Thus, the same effect occurs from animating the presentation attribute with attributeType="XML" as occurs with animating the corresponding property with attributeType="CSS" (see ‘attributeType’)."

<heycam> that is the current text

Amelia: Animating presentation attribute isn't *exactly* the same currently, because there is also the cascade issue

Doug: The XML vs CSS thing confuses a lot of people, so we resolved to get rid of it

Cam: So to answer your question, the animation would go into the cascade as a style, not an attribute

Amelia: So to be clear, this is effectively deprecating/ignoring the attributeType option, and just using the default behavior (CSS if such a style exists, XML if it doesn't)

<ed> the issue I'm referring to is issue-1 in the animation chapter

ED: But there would have to be qualifications for elements that have XML attributes with the same name but different meaning to new presentation attributes (e.g. `x`)

Cam: Is there a clear definition somewhere of how CSS animations and SMIL animations interact? What is the cascade?
... Does SMIL override the style attribute?

Amelia: Yes it does

Cam: Issue 26 in the styling chapter, should we support ::before and ::after?

Doug: I'll argue the pros. For accessibility, If I'm using ARIA markup to indicate that SVG text is a list, I would want to use ::before and CSS counters to add numbering; in other cases, I might want to add a bullet
... In general, the functionality of using icons in SVG could be enhanced by being able to insert a text definition before/after
... But, I do think it should be restricted to text elements. It doesn't make sense elsewhere.

Amelia: Might we want to extend that to metadata like title and desc?

Doug: I'm not sure whether it makes sense to use CSS for accessibility content; as of today, I don't think it would have any effect in most screen readers.

Amelia: As you said, it could be a later implementation if there were use cases/implementation.

<heycam> text::before { content: url(someimage.png); }

ED: Would you explicitly disallow using URL to reference an image?
... If this is only being used within text content.

Doug: I think we should probably disallow it unless someone comes up with a good use case.
... But maybe it does make sense, if someone has a graphic they've defined and they want to use it as a bullet or something within the text.

Amelia: But we don't have any rules for how to layout an image in the midst of a stream of text, the way the CSS box layout does.

Doug: But we are already incorporating a lot of CSS box model layout for text, so doesn't it make sense to use the same rules?

Tav: It makes sense for some types of text layout, not others.

Doug: Can we reverse-engineer that? We do have a text box already, it's just a single-line box the length of the text.
... but then we'd have to figure out padding & margins & so on between text and image

Tav: We resolved last week to not have padding etc. on non-boxed text

Doug: I think it will happen eventually... maybe for SVG 3

Amelia: So we could resolve now to support plain text before/after content, with images to be possibly supported/defined later.

Doug: That works. After all, you could still use unicode characters for bullets.

Tav: How does that affect alignment: text-anchor start/end?

Amelia: I would think that would be straightforward, just adding extra characters to the text. But what about character-by-character positioning attributes?

Doug: I think we need to clearly define this in the proposal

Tav: I think other issues take priority

Doug: We can break it into multiple issues, not committing to which version of SVG they will go in

Proposed resolution: That we will support ::before and ::after pseudoelements with text content; and that we will consider other types of replaced content after resolving all issues related to text content

Correction: That SVG will support ::before and ::after pseudoelements with text content (and possibly other types of replaced content), subject to resolving other text layout issues
... first

RESOLUTION That SVG will support ::before and ::after pseudoelements with text content (and possibly other types of replaced content), subject to resolving other text layout issues first

<ed> (on text content elements only?)

RESOLUTION: That SVG will support ::before and ::after pseudoelements with text content (and possibly other types of replaced content), subject to resolving other text layout issues first

Stroke-dash animation of paths

Doug: This is a common & popular technique, to use stroke-dasharray and stroke-dashoffset to create the effect that a line is being drawn in realtime. It's kind of a Wowzer kind of feature.
... I've always liked this feature, but it is somewhat limited. You aren't actually drawing the shape in real time, not actually changing the path and other properties related to it.
... It's kind of a hack, and there are many things it cannot do.
... Also, for other path animations (morphing shapes), it is limited by the fact that you need the same number of path segments of the same kind.
... So I wanted to throw an idea out a Brian about whether it should be possible to animate two paths together by creating a simplified version and animating between the two.

<heycam> animate from "M 0,0" to "M 0,0 C ... ... ..."

Bogdan: In IE, we're following the curent Chrome process, I don't think it would be possible to animate from an arbitrary path to another.

Amelia: It's not impossible if there are clear definitions. In transforms, there are definitions for how to animate one type of transform to another (or none).
... We'd need clear definitions, e.g. to upgrade a straight line to a curve that looks like the same line, and animate that.

Bogdan: That sounds possible, but right now, we need to be able to animate from one another to another.

Cam: The problem is that there are multiple possible solutions.

Doug: I would propose that we keep this in mind, not necessarily for SVG 2, but in future. I like Amelia's idea, and think it's a natural extension of the way we've already defined how there is a clear, decomposed path for all the basic shapes.
... the logical next step is to decompose one type of path to another.
... I know there was a JavaScript program that could do this in order to animate any two shapes. If it can be done in JavaScript, it can be done in C.
... I think it might also be useful to define a standard decomposition for all path elements. Maybe we could create a separate spec.

<ed> Presto had a "bezierize" path normalization method for similar purposes... was used for the glyph warping for textPath (method=stretch)

Bogdan: It's definitely something that would have much interest in the community. But I'm not sure it can easily be done in the current situation.

Doug: And for the specific case of animating the path length, maybe have a specific "draw a path" algorithm that also draws the fill of the shape.

<birtles> we can define normalizing path segment types into, e.g. cubic beziers, so that you'd only need to have the same number of segments (not necessarily the same type)--when you have a different number of segments though you need to say how they line up but maybe Cyril's superpath syntax could be used to specify the anchors

Amelia: I'm not sure about the math for that one.

Cam: Doug, why don't you put together some ideas in a wiki page for discussion in the future?

- DRAFT -

SVG Working Group Teleconference

12 Mar 2015

Attendees

Contents

Telcon time

Transform on SVG View

Controlling box-sizing for ObjectBoundingBox units ("box-rendering" property?)

SVG 2 status

Stroke-dash animation of paths

Summary of Action Items

Scribe.perl diagnostic output