See also: IRC log
<scribe> Scribe: Nikos
<scribe> scribenick: nikos
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 ( https://ameliabr.github.io/svgwg/build/publish/struct.html#UseHref ) to linking chapter & make general for all cross-references
AmeliaBR: we would have to adapt for which references are allowed to be cross referenced
RESOLUTION: 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
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
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 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].
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> 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 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 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].
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> https://github.com/w3c/svgwg/issues/180
<AmeliaBR> 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: 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.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: nikos Present: nikos stakagi Tav shepazu AmeliaBR Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jul/0007.html Found Date: 21 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/21-svg-minutes.html People with action items: nikos tav[End of scribe.perl diagnostic output]