Minutes, London 2016 editor's meeting day 3

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