Minutes, SVG Working Group Telecon, 12 March 2015

The minutes for today's call are available at the following URL, or pasted
below for the archive

http://www.w3.org/2015/03/12-svg-minutes.html

_____________________________________________________

- DRAFT -

SVG Working Group Teleconference

12 Mar 2015

Agenda

See also: IRC log

Attendees

PresentRegretsRossen, Bogdan, NikosChairCameronScribeAmeliaBR

Contents

Topics

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

________________________________

<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 inhttp://
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?

Summary of Action Items

[NEW] 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]

[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-03-12 21:44:31 $
________________________________

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/DS/Doug/
Succeeded: s/property?/property?)/
Succeeded: s/Also/Doug: Also/
Found ScribeNick: AmeliaBR
Inferring Scribes: AmeliaBR

WARNING: No "Present: ... " found!
Possibly Present: Amelia AmeliaBR Bogdan BogdanBrinza Cam Correction Doug
Doug_Schepers IPcaller Microsoft P10 P12 P9 ScribeNick Smailus Tav
Thomas_Smailus birtles ed heycam https joined nikos stakagi svg text
trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Regrets: Rossen Bogdan Nikos
Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Mar/0040.html
Found Date: 12 Mar 2015
Guessing minutes URL: http://www.w3.org/2015/03/12-svg-minutes.html
People with action items: cameron

[End of scribe.perl diagnostic output]