Minutes, 10th June 2016 SVG WG telcon

Hi all,

Minutes from today’s call are at:
https://www.w3.org/2016/06/09-svg-minutes.html



And below as text:
   [1]W3C

      [1] http://www.w3.org/


                               - DRAFT -

                    SVG Working Group Teleconference

09 Jun 2016

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/www-svg/2016Jun/0009.html


   See also: [3]IRC log

      [3] http://www.w3.org/2016/06/09-svg-irc


Attendees

   Present
          nikos, Tav, AmeliaBR, shepazu, stakagi

   Regrets
   Chair
          nikos

   Scribe
          nikos

Contents

     * [4]Topics
         1. [5]Unknown elements behaving as g
         2. [6]Clarification on complex text shaping
         3. [7]Cleaning up title and desc
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <scribe> Scribe: nikos

   <scribe> scribenick: nikos

Unknown elements behaving as g

   nikos: There was a github isse about tidying this text up
   ... Dirk pointed out that we may have removed this feature
   ... I looked into the history
   ... the latest resolution I could find was 2013 where we
   resolved to remove the feature

   [10]https://github.com/w3c/svgwg/issues/122


     [10] https://github.com/w3c/svgwg/issues/122


   scribe: Erik remembers discussion after that where we decided
   to keep the feature
   ... I don't mind putting it back in, won't be too much editing
   work
   ... also think it wouldn't be too bad to just spec current
   browser behaviour
   ... in terms of getting SVG 2 to CR
   ... then look at web components and custom elements and what to
   do with unknown elements later

   Tav: why do we want unknown elements to act as g?

   AmeliaBR: the way unknown markup is treated in html is that
   it's just transparent
   ... and you continue with child content
   ... in svg the only element that behaves like that is g
   ... it's useful because you can be a little more forward
   focused, if there's additional new markup that the current ua
   doesn't recognise
   ... it can find the parts it does recognise
   ... and generally try to make more robust features that could
   potentially be extended to custom elements

   Tav: if I have an unkonwn element with a transform
   ... it would act like g with a transform?

   AmeliaBR: yes
   ... and global attributes and styles could be applied
   ... I know we discussed this recently because we were
   discussing implementation details

   Tav: has anyone implement this?

   nikos: I've tested Chrome, Safari, and FireFox and they don't
   render and use the SVGElement interface

   Tav: From our point of view, if you have unknown elements, I
   don't think we would want to deal with them
   ... we would have to parse it - say it's not a g but acts like
   a g
   ... we would have to make sure we output as it originally was

   nikos: what were the obvious problems with the html parser?

   AmeliaBR: don't think they're unsurmountable, but if it gets to
   an element that isn't svg it'll insert a close tag

   shepazu: My suggestion is if it's a roughly equal amount of
   work either way, is to add it to the spec, mark it at risk
   ... the impact is pretty low one way or the other
   ... I feel like if we add it to the spec and it gets dropped,
   it's not a tragedy
   ... gives us a chance to get feedback from other people
   ... turns out if it doesn't get implemented then we drop it

   nikos: I'm happy with that

   Tav: I'm indifferent, don't think we'd implement in the near
   future

   nikos: ChrisL had raised concerns that if someone implemented
   an extension but put their custom elements in the svg
   namespace, then content could break

   AmeliaBR: like replicate for instance
   ... might not hurt in that case, but there's cases where we
   could break content

   shepazu: think that's pretty theoretical

   AmeliaBR: yeah, we don't have huge frameworks like html

   nikos: Ok, lets add it back in, do the small edits that are
   needed and see what happens to it in CR

   AmeliaBR: Don't see it as a feature that's at risk, but the
   error handling behaviour is different

   RESOLUTION: SVG 2 will treat unknown elements as g for the
   purposes of rendering, and they will use the SVGUnknownElement
   interface

   Tav: make sure to mark it at risk

   [11]https://rawgit.com/nikosandronikos/svg2-cr-issues/master/sv

   g2-cr-issues.html

     [11] https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html


   <scribe> ACTION: Nikos to look at github issue #103 on Monday
   [recorded in
   [12]http://www.w3.org/2016/06/09-svg-minutes.html#action01]

     [12] http://www.w3.org/2016/06/09-svg-minutes.html#action01]

   <trackbot> Created ACTION-3846 - Look at github issue #103 on
   monday [on Nikos Andronikos - due 2016-06-16].

Clarification on complex text shaping

   [13]https://github.com/w3c/svgwg/issues/65


     [13] https://github.com/w3c/svgwg/issues/65


   Tav: This is basically about what breaks ligatures

   AmeliaBR: there was discussion on www-style about this
   ... they had some related questions
   ... about line breaks and forced line breaks

   Tav: my view is that we pass a block of text to css to layout,
   and we need to follow css rules for breaking ligatures at that
   point
   ... then we come back and do dx, dy, and rotate, and I don't
   think we should break ligatures at that point
   ... if you do want to break ligatures, we have
   font-variant-ligatures that can be used to break ligatures
   explicitly

   nikos: I'm not an expert in that area, but sounds reasonable to
   me
   ... is there anyone specific you'd like input from?

   Tav: there was some discussion when one font has ligatures and
   one doesn't, if you substitute and get ligatures there might be
   problems

   AmeliaBR: sensible point is to allow them and author can turn
   them off if appropriate
   ... we can't judge what looks good so it has to be down to an
   author on that

   RESOLUTION: We will keep SVG 1.1 behaviour wrt to ligatures
   allowed on text on a path

   Tav: rotate will apply to the glyph, not to individual
   characters

   AmeliaBR: no matter how large and awkward that is
   ... we can treat this as authoring advice

   Tav: I'll add a note explaining how to turn them off
   ... Also about lengthAdjust=spacing
   ... if you put a non zero space it breaks ligatures

   AmeliaBR: that's a css rule

   Tav: what about textLength ?
   ... e.g. textLength="..." lengthAdjust="spacing

   AmeliaBR: I would suggest to leave it simple

   RESOLUTION: lengthAdjust=spacing will not break ligatures.
   Ligatures must be explicitly broken.

   AmeliaBR: sometimes textLength will have negligible affect, but
   breaking ligatures will have a much larger effect on the text
   length

   <AmeliaBR> [14]https://github.com/w3c/svgwg/issues/102


     [14] https://github.com/w3c/svgwg/issues/102


Cleaning up title and desc

   AmeliaBR: jarek created issue that elements are a bit arbitrary
   about whetehr they allow title and desc
   ... it's part of a larger issue of inconsistency in the spec
   ... want to see if people agree that we allow it pretty much
   everywhere
   ... even for pattern and stuff that is not accessible to a
   screen reader
   ... there is a theoretical accessible use where you can use non
   rendered elements as part of a description of a shape
   ... I've got an example of that
   ... or it can be general metadata
   ... I don't see a logical reason to prohibit that
   ... current status in SVG 1.1 is somewhat random

   nikos: I'm ok with that, obviously switch can't have it.
   Anything else?

   AmeliaBR: that's the only one I have an issue with
   ... html elements borrowed from html namespace wouldn't have
   them

   RESOLUTION: title and desc can be a child of any svg namespaced
   element except switch

   [15]https://rawgit.com/nikosandronikos/svg2-cr-issues/master/sv

   g2-cr-issues.html

     [15] https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html


Summary of Action Items

   [NEW] ACTION: Nikos to look at github issue #103 on Monday
   [recorded in
   [16]http://www.w3.org/2016/06/09-svg-minutes.html#action01]

     [16] http://www.w3.org/2016/06/09-svg-minutes.html#action01


Summary of Resolutions

    1. [17]SVG 2 will treat unknown elements as g for the purposes
       of rendering, and they will use the SVGUnknownElement
       interface
    2. [18]We will keep SVG 1.1 behaviour wrt to ligatures allowed
       on text on a path
    3. [19]lengthAdjust=spacing will not break ligatures.
       Ligatures must be explicitly broken.
    4. [20]title and desc can be a child of any svg namespaced
       element except switch

   [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 Friday, 10 June 2016 00:11:48 UTC