- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Wed, 17 Aug 2016 07:16:34 +0000
- To: www-svg <www-svg@w3.org>
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.
Received on Wednesday, 17 August 2016 07:17:13 UTC