Minutes, 21 July 2016 SVG WG telcon

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Minutes, 21 July 2016 SVG WG telcon

Nikos Andronikos
Apologies all, I was looking through the archives and discovered these minutes were never sent out.

https://www.w3.org/2016/07/21-svg-minutes.html

   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

21 Jul 2016

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2016/07/21-svg-irc

Attendees

   Present
          nikos, stakagi, Tav, shepazu, AmeliaBR

   Regrets
   Chair
          Nikos

   Scribe
          Nikos

Contents

     * [4]Topics
         1. [5]Use element re-write & related changes
         2. [6]Does conditional processing mute sound playback
         3. [7]Allow transforms on textPath
         4. [8]Use CSS gradient rules for transitioning
            semi-transparent stop-colors
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   <scribe> Scribe: Nikos

   <scribe> scribenick: nikos

Use element re-write & related changes

   [11]https://github.com/w3c/svgwg/pull/206

     [11] https://github.com/w3c/svgwg/pull/206

   AmeliaBR: I have issues that came up from that PR
   ... as I have it drafted x,y,width,height are simple attributes
   ... think I"m just going to change it
   ... one way or the other they're not going to behave nicely
   with css
   ... we are going to have to say if the value computes to this
   then do that on the shadow element
   ... and we're not going to be able to define it nicely in css,
   but we can define them as presentation attributes and use the
   final computed value on the use element
   ... unless I have implementers saying not to do it I'll just go
   ahead and change them

   +1

   AmeliaBR: I wanted to remove the comment about things going in
   defs. I'll go ahead with that

   +1

   AmeliaBR: As far as resolving cross references, I have a large
   section on what you should actually do to find the referenced
   element
   ... the important thing is if a cross reference references an
   element that doesn't exist, but that is created later, then you
   should listen and react to it
   ... browsers do that but it wasn't specced
   ... and for external files say we are processing in secure
   static mode
   ... so don't fetch additional resources
   ... you may fetch those resources if they are referenced by an
   element in the shadow dom, but you don't just grab them all
   ... wasn't clearly defined previously
   ... the issue is that this should apply to filter and paint
   servers and other cross references
   ... I'd like aresolution as to whether I should rewrite to make
   it more general

   nikos: Sounds reasonable, can't think of anything it would
   break

   <AmeliaBR> Proposed Resolution: Move the resolving
   cross-references section (
   [12]https://ameliabr.github.io/svgwg/build/publish/struct.html#
   UseHref ) to linking chapter & make general for all
   cross-references

     [12] https://ameliabr.github.io/svgwg/build/publish/struct.html#UseHref

   AmeliaBR: we would have to adapt for which references are
   allowed to be cross referenced

   RESOLUTION: Move the resolving cross-references section (
   [13]https://ameliabr.github.io/svgwg/build/publish/struct.html#
   UseHref ) to linking chapter & make general for all
   cross-references

     [13] https://ameliabr.github.io/svgwg/build/publish/struct.html#UseHref

   AmeliaBR: After I wrote this I thought there should be a load
   event
   ... Nikos suggested we deal with this as a future request
   ... I had a comment about width and height on the use element
   affecting symbol and whether it should affect width and height
   of other used elements (e.g. foreignObject)
   ... I feel it shouldn't but it needs to be clarified
   ... think foreignObject should behave as image, which doesn't
   size
   ... did anyone have a problem about use elements and animation
   being in this spec?

   nikos: Since this applies to how to animate this and it's
   general to CSS and SVG animations it makes sense to have it
   here rather than in the SVG animations spec

   AmeliaBR: I would like to make sure implementors see this
   ... One of the confusions with animations, is what to do if the
   animation element isn't cloned with the rest of the content
   ... I've got a special rule about theoretically cloning
   something and it acts like it's in the shadow tree
   ... if Brian or anyone else working on animations says it needs
   to change then thats fine otherwise I'll assume its ok for now
   ... final points are relating to interface adjustments that
   I've got to fake backwards compat with SVGInstance
   ... I've got something called SVGElementInstance but it's an
   extension to SVGElement
   ... the way it is currently defined you wouldn't have an object
   called SVGElementInstance in the global namespace
   ... didn't think there was any use having a separate interface
   object
   ... final one is alittle trickier, the extension is that the
   element in the shadow dom will have a link to its source
   document
   ... that's to mirror the previous functionality of the shadow
   instances
   ... but useful for catching events
   ... that could have a perf impact because you're if you're
   pointing to an element in another document you have to hold
   onto that document
   ... you would have to maintain in memory the original DOM

   nikos: Could you ask a note for now outlining the impact and
   ask for implementor feedback

   AmeliaBR: I could do that
   ... not sure if alternative is an error or if it acts as null.
   I can mention both options
   ... then it will stand as a warning to authors
   ... the other issue is redefining paint server cross references
   to use the same model
   ... when you have a pattern that has an href to another
   pattern, then you create a shadow dom for that pattern with the
   child content
   ... that would affect style matching - it would use the shadow
   matching rules. That wasn't defined in SVG 1.1
   ... think that's the only way that would change compliance
   requirements
   ... but it's also having a consistent model that could be used
   for other edge cases
   ... Tav did you look at my reply about how the changes to
   styling work?

   Tav: I did look at your example in InkScape - the stroke is
   green on both circles

   AmeliaBR: THat's the SVG 1.1. behaviour

   Tav: We rely on that behaviour in some parts of our code
   ... if you have a copy of the use element you only inherit from
   the use element if something is undefined
   ... don't know if this breaks that or not

   AmeliaBR: it may prohibit some optimisations

   Tav: My understanding from way back is if something is
   referenced it is defined at the point where it is inserted in
   the svg file

   AmeliaBR: markers are different because they never inherit any
   styles
   ... marker is treated like an image fragment

   Tav: We now have currentColor and currentStroke

   AmeliaBR: that changes things a bit where you can't just paint
   it once and reuse it
   ... but we don't have inherited styles so you can still use the
   computed style and sub in the value
   ... for use elements the computed styles were always adjusted
   ... CSS has names for this - can't remember what they are
   ... the main justification for changing this is that 1.
   interactive styles become useful instead of a big mess 2. the
   other is so the browsers can implement it with the same rules
   that they're using with shadow dom

   Tav: I' worried it will break a lot of inkscape

   AmeliaBR: my expectation is that no code that inkscape creates
   would trigger this problem

   Tav: looking at <g class="special" supposing I put a style
   element on that

   AmeliaBR: it won't change anything - in my example I have the
   fill style set on the g element
   ... that won't change behaviour
   ... the styles on the g element don't inherit on the old model
   or the new model

   Tav: Currently circle does inherit

   AmeliaBR: it shouldn't - we're reusing the circle, not the g

   Tav: I'm seeing that it is inheriting the green in inkscape

   AmeliaBR: it's not inheriting hte green, the green is being set
   on the circle that isa child of the elemnt with a special class
   ... it's being set on css on the circle, the circle is getting
   that style, but it's getting its style from the dom tree
   ... pretty sure you'd never create that case in InkScape, but
   it could be created by hand and then things will change

   Tav: I probably need to do a few more tests to understand. We
   don't write out selectors at all

   nikos: It sounds like from Amelias understanding of what you do
   then everything is ok
   ... can we assume that its ok and you'll do some more testing
   just to confirm that?

   Tav: that's fine

   AmeliaBR: I'll add this example to the spec and try to make it
   a bit more clear
   ... that's all I have to talk about this. Pending those tweaks.
   No one else has any complaints?
   ... I'll try to make those changes this weekend

Does conditional processing mute sound playback

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

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

   AmeliaBR: This gets down to whether this is conditional
   processing or conditional display
   ... if we make it conditional display then can we change the
   name?
   ... we should be clear
   ... in my mind processing means do scripts run and do you fetch
   external resources, etc
   ... if we're only changing display then we should change it

   nikos: not creating the tree is definitely more useful and if
   we were writing this from scratch that's how I'd want to do it
   ... but pragmatically at this point I think we should make it a
   synonym for MQ and display:none

   AmeliaBR: If we have it so switch effecst are only display:none
   then we lose the ability to extend switch to have behviour of
   the picture element, where it allows decision on what resource
   to download

   nikos: My hope is that browsers optimise this internally and
   try to be clever

   AmeliaBR: for me, someone decided script and style shouldn't be
   affected because that's how we implemented it the first time.
   That really limits their effectiveness
   ... if we further make it a display control only that removes
   any reason for them existing other than conditional language
   processing

   nikos: Does anyone else have any input on neutering switch?

   shepazu: I have mixed feeling about switch. I wonder how much
   it is used and I worry about browsers spending too much effort
   on switch that isn't going to be implemented and used
   ... if you think about its origins, what was it used for ? It
   came from SMIL. SMIL was a very specific community of authors
   and processors and I don't think that's what people are doing
   today with web content for the most part
   ... so we inherited it from style, I wonder if we should do the
   minimal thing to not break it in SVG 2
   ... if we want to do declarative conditional processing outside
   of CSS we should reexamine the use cases and see what we're
   trying to accomplish
   ... this comes up in accessibility. If someone makes a document
   that has switch for languages, whats the accessible name?
   ... makes sense for title, but very few go to the effort

   Tav: We had people request that last year

   AmeliaBR: It's a useful function, but there's no way to control
   it from the user end without changing browser settings
   ... for the feature support side as well, there's a strong move
   for declarative feature support testing features
   ... bu they're being done in a way that isn't a direct
   extension of how it was done with switch

   nikos: At this point I'm going to propose we make it
   conditional for display and move on. Think we are reluctantly
   agreeing on this

   AmeliaBR: Are you ok with changing prose to call it conditional
   display?

   nikos: think so

   shepazu: we're talking about changing switch, what is so broken
   about switch now? What is so broken now that it demands change
   in SVG 2?

   AmeliaBR: question that came up is that now we have audio and
   video, should they play if they're in a turned off branch
   ... if you have audio and video it does play
   ... other issue is what to do with use element - do you fetch?
   ... same with image element

   nikos: I feel if someone has raise and explicit issue then we
   need to resolve it

   RESOLUTION: Switch fill function as conditional display

   <scribe> ACTION: Nikos to update switch prose to make it
   conditional display [recorded in
   [15]http://www.w3.org/2016/07/21-svg-minutes.html#action01]

     [15] http://www.w3.org/2016/07/21-svg-minutes.html#action01]

   <trackbot> Created ACTION-3848 - Update switch prose to make it
   conditional display [on Nikos Andronikos - due 2016-07-28].

Allow transforms on textPath

   [16]https://github.com/w3c/svgwg/issues/210

     [16] https://github.com/w3c/svgwg/issues/210

   nikos: Think Tav is against adding transform to tspan and
   textpath

   Tav: that's right

   AmeliaBR: and then we ran across unclear behaviour if the path
   is transformed

   Tav: There's an example in the spec that shows what it should
   be

   AmeliaBR: it doesn't have a picture showing the output
   ... for tspan and textpath being transformable - we're dealing
   with css saying an inline text element is not transformable.
   we're treating these in svg as inline
   ... but that will break content - anyone who has been using the
   a element hack

   Tav: I could not find any browser that supported that

   <Tav> [17]http://tavmjong.free.fr/SVG/text_tspan_transform.svg

     [17] http://tavmjong.free.fr/SVG/text_tspan_transform.svg

   AmeliaBR: Not supported in Chrome or Edge

   nikos: I propose we dont' allow transform on inline elements

   AmeliaBR: let's go with that

   RESOLUTION text and tspan are treated as inline elements and
   inline elements can't have transform

   nikos: Is that how it's specced?

   Tav: think tspan can have transform in SVG 2

   AmeliaBR: CSS transforms defines transformable elements and
   we'll need to change that to get rid of that paragraph so it's
   based on block vs inline elements

   <scribe> ACTION: Nikos file issue on CSS Transforms [recorded
   in [18]http://www.w3.org/2016/07/21-svg-minutes.html#action02]

     [18] http://www.w3.org/2016/07/21-svg-minutes.html#action02]

   <trackbot> Created ACTION-3849 - File issue on css transforms
   [on Nikos Andronikos - due 2016-07-28].

   <scribe> ACTION: Tav to update spec to reflect no transform on
   inline elements [recorded in
   [19]http://www.w3.org/2016/07/21-svg-minutes.html#action03]

     [19] http://www.w3.org/2016/07/21-svg-minutes.html#action03]

   <trackbot> Created ACTION-3850 - Update spec to reflect no
   transform on inline elements [on Tavmjong Bah - due
   2016-07-28].

Use CSS gradient rules for transitioning semi-transparent stop-colors

   AmeliaBR: I filed this suggesting we should have consistent
   behaviour with CSS gradients.
   ... but that would make use inconsistent with canvas
   ... so not concerned one way or the other, but I want a clear
   definition that Safarai is wrong
   ... so what happens if stop-color is a semi transparent colour
   - Safari ignores the alpha

   Tav: Why is Safari wrong?

   <AmeliaBR> [20]https://github.com/w3c/svgwg/issues/180

     [20] https://github.com/w3c/svgwg/issues/180

   <AmeliaBR>
   [21]https://github.com/w3c/svgwg/issues/180#issuecomment-229147
   823

     [21] https://github.com/w3c/svgwg/issues/180#issuecomment-229147823

   AmeliaBR: third one doesn't fade to transparent at all
   ... it's an SVG gradient purely defined in terms of stop-color
   rather than using stop-opacity
   ... final stop-color is a transparent colour and it's ignoring
   the alpha component
   ... if you have a rgba fill and a separate opacity they get
   combined

   Tav: So how do we factor it in?

   AmeliaBR: there is debate on the CSS side. Canvas has it
   consistent with how other browsers implement SVG
   ... I would say keep it how other browsers implement it
   ... so going back to the screenshot at the top of the page
   ... this is what other browsers do
   ... talking about the third case, you are doing it all with
   rgba colours and the destination colour is rgba transparent
   black - aka the transparent keyword
   ... stop-color transitions to black and opacity transitions to
   zero. What they don't do is modify the ipmact of the colour so
   that if it has zero alpha it has zero influence on the colour
   ... to be clear, the top two are still options. You just have
   to set stop-color and stop-opacity yourself
   ... I'm happy with speccing this to match implementations
   ... and file a bug on webkit

   nikos: +1

   shepazu: +1

   <AmeliaBR> Preposed Resolution: partially transparent
   stop-opacity should be factored in to gradients, multiplicative
   with any change in stop-opacity; color blending uses
   non-pre-multiplied colors

   RESOLUTION: partially transparent stop-opacity should be
   factored in to gradients, multiplicative with any change in
   stop-opacity; color blending uses non-pre-multiplied colors

   <AmeliaBR> CR requirements:
   [22]https://www.w3.org/2015/Process-20150901/#candidate-rec

     [22] https://www.w3.org/2015/Process-20150901/#candidate-rec

   RESOLUTION: Publish SVG 2 CR, pending updates to Amelia's use
   element rewrite and the new text changes. Will put a call for
   additional resolution comments to the mailing list with one
   week to respond.

Summary of Action Items

   [NEW] ACTION: Nikos file issue on CSS Transforms [recorded in
   [23]http://www.w3.org/2016/07/21-svg-minutes.html#action02]
   [NEW] ACTION: Nikos to update switch prose to make it
   conditional display [recorded in
   [24]http://www.w3.org/2016/07/21-svg-minutes.html#action01]
   [NEW] ACTION: Tav to update spec to reflect no transform on
   inline elements [recorded in
   [25]http://www.w3.org/2016/07/21-svg-minutes.html#action03]

     [23] http://www.w3.org/2016/07/21-svg-minutes.html#action02
     [24] http://www.w3.org/2016/07/21-svg-minutes.html#action01
     [25] http://www.w3.org/2016/07/21-svg-minutes.html#action03

Summary of Resolutions

    1. [26]Move the resolving cross-references section (
       https://ameliabr.github.io/svgwg/build/publish/struct.html#
       UseHref ) to linking chapter & make general for all
       cross-references
    2. [27]Switch fill function as conditional display
    3. [28]partially transparent stop-opacity should be factored
       in to gradients, multiplicative with any change in
       stop-opacity; color blending uses non-pre-multiplied colors
    4. [29]Publish SVG 2 CR, pending updates to Amelia's use
       element rewrite and the new text changes. Will put a call
       for additional resolution comments to the mailing list with
       one week to respond.

   [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.

Reply | Threaded
Open this post in threaded view
|

neutering switch (was Minutes, 21 July 2016 SVG WG telcon)

David Dailey
Hi Nikos and Doug

>From Wednesday, August 17, 2016 3:17 AM  
 nikos: Does anyone else have any input on neutering switch?

   shepazu: I have mixed feeling about switch. I wonder how much
   it is used and I worry about browsers spending too much effort
   on switch that isn't going to be implemented and used
   ... if you think about its origins, what was it used for ? It
   came from SMIL. SMIL was a very specific community of authors
   and processors and I don't think that's what people are doing
   today with web content for the most part
   ... so we inherited it from style, I wonder if we should do the
   minimal thing to not break it in SVG 2
   ... if we want to do declarative conditional processing outside
   of CSS we should reexamine the use cases and see what we're
   trying to accomplish
   ... this comes up in accessibility. If someone makes a document
   that has switch for languages, whats the accessible name?
   ... makes sense for title, but very few go to the effort

I'm not sure if this is a valid use case or not, but, since so much of the
web is now phone-based, and things like

https://ello.co/ddailey/post/p68grxig2tne7wpu8k1jjq

or

https://ello.co/ddailey/post/hwqd8hmolnwx7-vp4zocfq


don't work so well on phones yet (requiring more horsepower and maybe a
GPU),  having a declarative way to switch content, so that something could
be SVG for a grown-up machine and animated GIF (which most of the world of
animated graphics uses anyhow) for the purposes previously reserved for SVG
Tiny, could be quite valuable. Doing this declaratively is of interest since
SVG will ultimately reach far more people through <img> tags than through
CodePen -- just sayin'. Of course my sense is that whenever things are moved
away from SVG, they have a tendency to break for a few years and sometimes
never get fixed.

regards
David