SVG Working Group Teleconference -- 22 Apr 2016

<scribe> Meeting: SVG London 2016 Day 3

Next F2F

AmeliaBR: I'll be at CSS Day in Amsterdam in June

nikos: That may be a good opportunity to all be able to get together again

Tav: I may be able to do that

nikos: Let's see if any others would be able to make it. Seems like a good opportunity
... Finding an office space might be problematic

<AmeliaBR> Chris Little notes that term "open path" is undefined in textPath discussion. Added issue to get linkable definitions of this & related terms: https://github.com/w3c/svgwg/issues/123

TextChapter

Tav: if you have multiple sub-paths, what is the behaviour of text on a path
... should the text flow from one sub-path to another, is this affected by the sub-path being closed?

nikos: What happens on a single closed sub-path now?

Tav: text flows around the shape multiple times

AmeliaBR: I would be happy that by default text gets clipped, and there is a control for allowing wrapping

Tav: I talked to heycam about overflow for text on a path, he said overflow wasn't intended to work on text on a path
... I believe text overflow only applies if overflow is none
... the SVG spec says that text-overflow applies regardless of the overflow property
... because we don't turn on scroll bars and do fancy things
... the text-overflow only has two values - clip and ellipse
... So I removed the thing that says text-overflow applies to text paths
... if we want it to apply we need behaviour for clipping at any point - text on a path only drops whole characters if the mid point doesn't lie on the path

AmeliaBR: so we would need to discuss with css and come up with some new behaviour

Tav: My inclination is to keep it simple, but there is an issue in svg for how to allow text-overflow for content regions
... we don't want scroll bars

AmeliaBR: not useful for text in a shape

Tav: if you look at the figures now it shows overflow, clipping and ellipsis
... but there's no actual way to get the first option

<AmeliaBR_> https://svgwg.org/svg2-draft/text.html#TextOverflowProperty

AmeliaBR_: for text, this is the default cSS text overflow property
... but none of those options include the svg behaviour for text path

Tav: yeah so I was going to keep that separate
... because it's already defined in svg 1.1

AmeliaBR_: we could ask CSS if they could add another value that drops characters

nikos: seems like it would be useful, but might be difficult to do if it's all handled inside the text layout engine

AmeliaBR_: if you have overflow hidden text-overflow describes how you hide it.

Tav: right now svg text says to ignore overflow
... we really don't want scroll bars

<AmeliaBR_> Rules for interpretting overflow where scroll bars don't make sense: https://svgwg.org/svg2-draft/render.html#OverflowAndClipProperties

AmeliaBR_: may need to update that table, but we already have rules that turn a computed value into a used value that never has scroll bars

Tav: so that requires changing the rule on overflow and the describing text
... think we can agree that's what we do with shape

RESOLUTION: A value of scroll for overflow for text in a shape will be the equivalent of hidden

<scribe> ACTION: nikos to update table in render chapter to include overflow behaviour for text [recorded in http://www.w3.org/2016/04/22-svg-minutes.html#action01]

<trackbot> Created ACTION-3841 - Update table in render chapter to include overflow behaviour for text [on Nikos Andronikos - due 2016-04-29].

Tav: so lets talk about how text-overflow applies

AmeliaBR_: we are going to need to add a UA style sheet rule that says text path by default has hidden overflow

Tav: we need to be careful because as soon as we allow overflow for text on a path we have to define where the text goes

nikos: do we really want to change text on a path? what's the need for overflowing text on a path?
... what about if we define it as an equivalent path that starts from the offset and ends at the offset
... and text on a path never wraps past the end

Tav: I can write it up like that

AmeliaBR_: do we ever want someone to be able to put an ellipsis on clipped text for text on a path?

Tav: I'm not too bothered about that

nikos: I think text on a path is a case where automatic layout isn't so important so we don't need to go there

ChrisLittle: As a user if I had a shape that was filled with text, If it was a rectangle I would expect it to continue beyond the end of the rect
... but if it's not a rectangle it gets messy. Maybe acceptable behaviour would be to just continue the last line?

AmeliaBR_: it's defined in CSS based on cSS layout boxes
... you have your layout box, you cut out your shape, then you continue beyond the bottom of the layout box
... in svg we don't have a layout box so we would have to say the layout box is the shapes layout box
... so we would have to create a box, but it would be inconsistent with the way css has defined it

Tav: i think for SVG 2 it's better to just say this may be defined in the future, we don't define it here
... and recommend you provide an overflow shape - I have a note about that in there already
... in normal cases it will be correct, but if someone adjusts the size it might look wonky

AmeliaBR: As browsers come up with implementations we may see ways of doing it that are better

RESOLUTION: The wrapping behaviour of text on a path will be defined based on the start offset for closed paths with a single sub-path and will not be controllable by text overflow and the other overflow properties

AmeliaBR: Right now path-offset is XML only
... we can leave start-offset as xml only for now

Github issues

<scribe> scribe: nikos

The list of github issues that we need to work through is at https://github.com/w3c/svgwg/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22London+2016%22+label%3ANew

zero value for pathLength

https://github.com/w3c/svgwg/issues/81

nikos: The spec doesn't state what to do with with pathLength=0
... implementations are not consistent
... see the github issue for details

AmeliaBR: if the author gives a pathLength of zero to a path that has non zero actual length, we have a theoretical scaling factor of infinity
... with this infinity factor anything positioned at zero stays at zero
... anything anywhere else gets clamped to the max possible value

Tav: Agree that continuity for animation is important

AmeliaBR: for dashing, dash-offset needs to be taken into account

RESOLUTION: if the author gives a pathLength of zero to a path that has non zero actual length, we have a theoretical scaling factor of infinity with this infinity factor anything positioned at zero stays at zero anything anywhere else gets clamped to the max possible value

Direction of markers and line caps on segment boundaries

https://github.com/w3c/svgwg/issues/79

nikos: Think what happened in this case is the algorithm didn't capture the behaviour we expect
... So the algorithm currently says that the direction is based on the segment originating at a point, but I think we want to say that for start caps that is the case, but end caps should be based on the preceding segment

Tav: ... Agree

RESOLUTION: The butt line of the cap must always be oriented correctly against the dash it is opening/closing

nikos: I'll update the algorithm

AmeliaBR: And we'll need to file bugs on the browsers that are doing it wrong at the moment

Limit pattern & gradient attributes that are inheritable using href

AmeliaBR: We should include a list as suggested
... the other issue this raises is that style inheritance isn't defined clearly for what happens when you do that
... what I'd like it to have been is where style inheritance is like use elements
... you copy the pattern but change inherited colours
... or other style features
... but no one implements that way

Tav: so if you have a pattern that's referncing another pattern, you can't change the style on it?

AmeliaBR: you can change the pattern tile dimensions because they're attributes on the pattern element itself that you override
... and you can replace child content
... but you can't change inherited colours
... but it's not clearly said in svg 11 whether you should or shouldn't
... because it uses an href and is otherwise similar to use elements, I would ahve otherwise assumed that, and think it would be useful
... but if we are looking to match implementations, I haven't found an implementation that does it the useful way

Tav: wonder how easy it would be for them to implement it ?
... it does sound useful

nikos: if implementations are consistent, we should spec their behaviour

AmeliaBR: it'll be difficult to define that in a consistent way
... I'll give it a look when I do the use rewrite

RESOLUTION: pattern style inheritance will be specified to match current implementations
... On the pattern element, specific relevant attributes override, not all attributes
... Paint servers will inherit only specific relevant attributes (be specific about which ones in the spec) not all attributes as the spec currently says

nikos: ...

RESOLUTION: Paint servers will inherit only specific relevant attributes (be specific about which ones in the spec) not all attributes as the spec currently says

Full glyph cell term is not defined

nikos: this one is easy, just need to check terms and describe it in those terms
... think it's advance width and EM box height

Tav: agree

How should text following <textPath> be positioned?

https://github.com/w3c/svgwg/issues/104

AmeliaBR: we have two interoperable implementations

nikos: Specify as end of the path provides new x/y?

Tav: yeah

AmeliaBR: what about closed paths and start offset stuff

nikos: So end of the equivalent path that we defined before?

AmeliaBR: using last letter is simpler, but agree end of the path is likely to be more aesthetically pleasing

RESOLUTION: text following textPath text is positioned as if the x,y is at the end point of the equivalent path

Marker element percentages are missing reference values

https://github.com/w3c/svgwg/issues/64

So percentages are relative to the containing viewport, adjusted by the scaling factor of the stroke width

AmeliaBR: So percentages are relative to the containing viewport, adjusted by the scaling factor of the stroke width
... marker doesn't establish a new viewport, though it has a viewBox
... SVG11 didn't allow percentages on markerWidth and markerHeight

Tav: then lets get rid of it

AmeliaBR: spec doesn't allow percentages on pattern even though they do make sense and are supported!
... so spec for pattern needs updating

Tav: Makes sense for pattern, but marker has no bounding box

nikos: Should we drop it for markerWidth and markerHeight for now until we get a way of specifying percentages relative to something other than the viewport?

AmeliaBR: yes for markerWidth and markerHeight. refX and refY should allow percentages and be relative to whatever symbol is relative to - viewbox or whatever else

Tav: refX and refY on a symbol was added

AmeliaBR: for symbol and marker we need to define whether it's L/C/R of the viewbox you're drawing into or the width/height
... Think it has to be relative to the viewBox coordinate system

<scribe> ACTION: Amelia to update refX/refY to define what it's all relative to [recorded in http://www.w3.org/2016/04/22-svg-minutes.html#action02]

<trackbot> Created ACTION-3842 - Update refx/refy to define what it's all relative to [on Amelia Bellamy-Royds - due 2016-04-29].

Clarify whether 'filter' attribute is valid for <tspan> elements

Amelia: in SVG 1.1 tspan and textPath weren't full graphics elements, they were just for text formatting
... we've already allowed transform, so I assume all other styles that goes on a graphics element
... filter in filters spec applies to all elements
... I'm going to reply that FireFox is wrong

Tav: so you can apply a filter to a tpsan - and you use the bounding box for the tspan for the filter area

AmeliaBR: Yeah, we have text in svg 2 that mentions that

<scribe> scribe: nikos

positioning attributes on textPath directly

AmeliaBR: can we put x,y,dx, and dy on textPath so that authors don't need to specify them on a parent text or tspan element?

Tav: It's extra parsing work.
... I'd like implementor feedback

nikos: Certainly beneficial for users and seems like it would be fairly easy to implement. We could add it and mark it at risk and see what people think

Tav: x and y should not be on textPath
... only dx and dy

AmeliaBR: there's definitions for how to use them mid way through
... in the one direction, with the rule that in the perpendicular direction they're ignored
... but that was never well defined and is inconsistent across browsers
... has it been removed?

Tav: I haven't done anything with it

<AmeliaBR> Chromebug re startOffset (results in a bad SVG figure in the spec) https://bugs.chromium.org/p/chromium/issues/detail?id=476554 WebKit has same problem

<AmeliaBR> Chromebug for interaction of startOffset & x/y attributes: https://bugs.chromium.org/p/chromium/issues/detail?id=521550

Discussion on before and after on SVG text -> https://www.w3.org/2015/03/12-svg-minutes.html#item04

Tav: it would be a non trivial amount of work to implement in InkScape
... not too hard to read in, but needs incorporating in the layout code
... it's very messy code

AmeliaBR: if we're not going to change it, can we add a warning into the spec?
... it really confused me

Tav: I would be happy to do that

<AmeliaBR> Latest CSS WD spec on pseudo-elements: https://www.w3.org/TR/css-pseudo-4/

- DRAFT -

SVG Working Group Teleconference

22 Apr 2016

Attendees

Contents