- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Thu, 28 Apr 2016 01:08:51 +0000
- To: www-svg <www-svg@w3.org>
Minutes from day three are at:
https://www.w3.org/2016/04/22-svg-minutes.html
And as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
22 Apr 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/04/22-svg-irc
Attendees
Present
nikos, AmeliaBR, Tav, ChrisLittle, stakagi
Regrets
Chair
nikos
Scribe
nikos
Contents
* [3]Topics
1. [4]Next F2F
2. [5]TextChapter
3. [6]Github issues
4. [7]zero value for pathLength
5. [8]Direction of markers and line caps on segment
boundaries
6. [9]Limit pattern & gradient attributes that are
inheritable using href
7. [10]Full glyph cell term is not defined
8. [11]How should text following <textPath> be
positioned?
9. [12]Marker element percentages are missing reference
values
10. [13]Clarify whether 'filter' attribute is valid for
<tspan> elements
11. [14]positioning attributes on textPath directly
* [15]Summary of Action Items
* [16]Summary of Resolutions
__________________________________________________________
<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:
[17]https://github.com/w3c/svgwg/issues/123
[17] 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_>
[18]https://svgwg.org/svg2-draft/text.html#TextOverflowProperty
[18] 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:
[19]https://svgwg.org/svg2-draft/render.html#OverflowAndClipPro
perties
[19] 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
[20]http://www.w3.org/2016/04/22-svg-minutes.html#action01]
[20] 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
[21]https://github.com/w3c/svgwg/issues?utf8=%E2%9C%93&q=is%3Ai
ssue+is%3Aopen+label%3A%22London+2016%22+label%3ANew
[21] 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
[22]https://github.com/w3c/svgwg/issues/81
[22] 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
[23]https://github.com/w3c/svgwg/issues/79
[23] 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?
[24]https://github.com/w3c/svgwg/issues/104
[24] 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
[25]https://github.com/w3c/svgwg/issues/64
[25] 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
[26]http://www.w3.org/2016/04/22-svg-minutes.html#action02]
[26] 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)
[27]https://bugs.chromium.org/p/chromium/issues/detail?id=47655
4 WebKit has same problem
[27] https://bugs.chromium.org/p/chromium/issues/detail?id=476554
<AmeliaBR> Chromebug for interaction of startOffset & x/y
attributes:
[28]https://bugs.chromium.org/p/chromium/issues/detail?id=52155
0
[28] https://bugs.chromium.org/p/chromium/issues/detail?id=521550
Discussion on before and after on SVG text ->
[29]https://www.w3.org/2015/03/12-svg-minutes.html#item04
[29] 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:
[30]https://www.w3.org/TR/css-pseudo-4/
[30] https://www.w3.org/TR/css-pseudo-4/
Summary of Action Items
[NEW] ACTION: Amelia to update refX/refY to define what it's
all relative to [recorded in
[31]http://www.w3.org/2016/04/22-svg-minutes.html#action02]
[NEW] ACTION: nikos to update table in render chapter to
include overflow behaviour for text [recorded in
[32]http://www.w3.org/2016/04/22-svg-minutes.html#action01]
[31] http://www.w3.org/2016/04/22-svg-minutes.html#action02
[32] http://www.w3.org/2016/04/22-svg-minutes.html#action01
Summary of Resolutions
1. [33]A value of scroll for overflow for text in a shape will
be the equivalent of hidden
2. [34]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
3. [35]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
4. [36]The butt line of the cap must always be oriented
correctly against the dash it is opening/closing
5. [37]pattern style inheritance will be specified to match
current implementations
6. [38]Paint servers will inherit only specific relevant
attributes (be specific about which ones in the spec) not
all attributes as the spec currently says
7. [39]text following textPath text is positioned as if the
x,y is at the end point of the equivalent path
[End of minutes]
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 28 April 2016 01:09:25 UTC