– DRAFT –
SVG WG Meeting

<karlcow__> FYI: the real state of the spec is at https://w3c.github.io/svgwg/svg2-draft/ until we get the possibility to publish on svgwg.org domain

Should width and height apply to nested svg elements as CSS properties

w3c/svgwg#1057

dmangal: Chromium starts applying CSS properties for width/heighth on svg elements

dmangal: No styling gets applied and we got a lot of feedback.

dmangal: Initially we started to adviocate for the feature but there were to many

dmangal: We disabled the feature. Safari and FF do not support it

krit: clarification question: <svg> inside of <svg> elements?

dmangal: yes

oops, sorry

scribe_

krit: I am not sure if we meant to be applied for nested elements

krit: spec doesn't mention outer most SVG element?

dmangal: No it does not

krit: Can you add more info about the rendering issues

karlcow__: there are examples on the ticket

karlcow__: some examples were completely incorrect.

<dmangal> https://issues.chromium.org/issues/449170647#comment7

nzimmermann: IMO the spec in 7.8 (sizing properties) "are used for SOME SVG elements"...

nzimmermann: IMO it was a nice idea but should never have applied to any other elements other than outer SVG elements.

nzimmermann: For rect it is not eval but for SVGSVGElement it is.

nzimmermann: I think we should explicitly exclude non-outer SVG elements. Including foreignObject. rect is relatively fine but for none of the other elements.

nzimmermann: it is mostly about web compatibility with existing content that applies svg { width: 100%, height: 100% }. This was inteded to only apply to outer SVG elements for those devs. So we are breaking a lot of existing content. So the issue is not supporting it from a technical perspective -- it would be possible. My concern is only about web compat

<karlcow__> S/inteded/intended/

dmangal: According to spec, the width/height for inner outer SVGSVGElement, Rect, foreignObject and use

ydaniv: And view eleement?

krit: is that in SVG 2?

<karlcow__> https://w3c.github.io/svgwg/svg2-draft/linking.html#ViewElement

karlcow__: It is there but doesn't have width/height

dmangal: rect and image are probably fine

<karlcow__> https://w3c.github.io/svgwg/svg2-draft/struct.html#UseElement

<karlcow__> > The x, y, width and height geometric properties specify the positioning of the referenced element. The width and height attributes only have an effect if the referenced element defines a viewport (i.e., if it is a ‘svg’ or ‘symbol’); if so, a value other than auto for the ‘use’ element overrides the value of the corresponding geometric property on that element.

<karlcow__> > A negative value for width or height is invalid and must be ignored. If width or height is zero, and the properties have an effect on the referenced element, then rendering of that element will be disabled.

<karlcow__> https://w3c.github.io/svgwg/svg2-draft/struct.html#SymbolElement

nzimmermann: The use element already talks about the connection to CSS sizing eventhough not explicitly referring to it

<karlcow__> > The x, y, width, and height geometry properties have the same effect as on an ‘svg’ element, when the ‘symbol’ is instantiated by a ‘use’ element. In particular, if width and height compute to auto (and are not over-ridden by values on the instantiating ‘use’ element), then they will be treated as a value of 100%.

<dmangal> https://chromestatus.com/metrics/feature/timeline/popularity/5730

nzimmermann: Can we support width/height on use at least? Same behavior for rect?

<karlcow__> Also https://w3c.github.io/svgwg/svg2-draft/struct.html#UseLayout

dmangal: See example why I am not in favor.

dmangal: For inner SVGs and use, symbol we won't honor CSS width/height. For Rect, Image, foreignObject and outer SVG elements, the CSS properties will be honored.

<dmangal> https://svgwg.org/svg2-draft/geometry.html#Sizing

krit: how can we easily categories these elements to make it easier to understand which elements do honor CSS properties of width/height?

dmangal: can we add a reference to sizing?

karlcow__: The idea is, can we simplify?

nzimmermann: we could copy the section on each of the effected elements but it would be easy to miss. We should add it in the general section, references directly by the individual elements?

krit: I am fine with this compromise too

proposed Resolution: The CSS width/height properties are honored as presentation attributes for rect, image, foreignObject and outer-SVG elements and ignored by all other elements with the width/height attributes.

RESOLUTION: The CSS width/height properties are honored as presentation attributes for rect, image, foreignObject and outer-SVG elements and ignored by all other elements with the width/height attributes.

ACTION: dmangal to update specification text

SVG path animation: unclear behavior for from + by when commands mismatch

w3c/svgwg#1056

viralipurbey: Using from/by animations on the d attribute.

viralipurbey: When animation values are incompatible, the animation should fall back to discrete animation.

viralipurbey: this is not clear for from/by animations on d path.

viralipurbey: should the render the from value/by value?

viralipurbey: Firefox is not rendering anything.

viralipurbey: It reads it as animation. This feels reasonable. Other engines may take a different decision as we do not talk about additive animations in the spec.

viralipurbey: so either renderers should render nothing or fall back to from/by values.

nzimmermann: Did you spec the original SMIL specification?

viralipurbey: I went thought the spec.

viralipurbey: We can not use the original SMIL animation as it does not apply to d. But I would interprete it as discrete animation. But it too does not mention additive animations with mismatching values for from/by.

nzimmermann: I agree with you. If there is no valid use case, having an error is better than defining a behavior. This is much easier to spot for developers. IMO it is a good point.

<karlcow__> Is it part of https://svgwg.org/specs/animations/ ?

krit: should we really not render the element at all in case of error?

nzimmermann: no, it is about not applying the animation

viralipurbey: I actually mean not to render as it is easier to spend. During animation it should not render anything.

<karlcow__> https://svgwg.org/specs/animations/#FromAttribute

nzimmermann: well in that case there is no value to start from. So they can't render anything. This is specific.

nzimmermann: not rendering at all would be against the spirit of the SVG spec

karlcow__: I haven't tried it yet. But there is a different spec: Web Animations.

karlcow__: may the answers be in that spec.

<caribou> SVG Animations is not listed as a deliverable in our charter either

viralipurbey: For from/by animations or additive animations, if we have incompatible values, the animation should be canceled and rendering falls back to the base value for the time of the animation. Even after the animation, the base value should be used.

krit: simplified: animation has no effect?

viralipurbey0: yes

<karlcow__> https://w3c.github.io/svgwg/svg2-draft/animate.html

nzimmermann: There is SMIL, SMIL3, SVG Animations, Web Animations, CSS Animations/Transitions... what should be referenced by SVG2? WebAnimation has nothing from SMIL. So where would we reference the animations? No on uses SMIL as a reference anymore. Do we even investigate into SMIL? Should we discourage the use of SMIL?

karlcow__: I don't think we are in a state where we are looking into animations. Our task is to work on SVG2.

karlcow__: I don't think we can take other things.

<karlcow__> Web Animations Level 1 https://drafts.csswg.org/web-animations-1/

krit: We still need to specify what we stand to to SVG Animations: 1. don't support it anymore? 2. frozen to SVG 1.1? 3. Replaced by CSS Animations?

nzimmermann: Animating colors has a complete replacement in CSS.

nzimmermann: transform has a full replacement

nzimmermann: there is animation attributes possible

nzimmermann: there is CSS Motion for d attribute

nzimmermann: we won't have matching support for everything but to what extend is CSS attribute animation possible?

nzimmermann: IMO CSS covers 90% of real use cases for animations

ydaniv: SMIL animations are deprecated. This has been stated for a while.

ydaniv: SMIL should be considered deprecated.

ydaniv: there is a lot you simply can't do with SMIL

ydaniv: clearly the path forward is facing to CSS

ydaniv: SMIL is already behind in many ways

ydaniv: best way forward is more presentational attributes where it works and animate with CSS.

ydaniv: sequencing is still missing for web animations. Which is one gap on CSS yet. But we should continue the work in Web Animations.

ydaniv: There are still many ppl using SMIL.

<Neha> Need to jump to another meeting.

<karlcow__> Wondering if we need to guide of equivalence in between SMIL/SVG -> CSS animations.

nzimmermann: Would suggest: 1. depricate SMIL 2. Reference SVG Animations in SVG 1.1 for web compat 3. Add a list of WG resolutions for additional clarifications but no further update on the actual spec.

<Vinay> https://www.w3.org/TR/SVG2/paths.html#TheDProperty

<Vinay> For animation, two d property values can only be interpolated smoothly when the path data strings contain have the same structure, (i.e. exactly the same number and types of path data commands which are in the same order). If an animation is specified and the lists of path data commands do not have the same structure, then the values must be

<Vinay> interpolated using the discrete animation type.

<karlcow__> https://w3c.github.io/svgwg/svg2-draft/paths.html#DProperty

RESOLUTION: For from/by animations or additive animations, if we have incompatible values, the animation should be canceled and rendering falls back to the base value for the time of the animation. Even after the animation, the base value should be used.

viralipurbey: Should we add it to the existing text for this particular issue as we already have it mentioned in the spec?

nzimmermann: fine with me

ydaniv: shouldn't we make it wider to match CSS animations as well?

nzimmermann: additive animations are byond CSS.

RESOLUTION: Add calrification into SVG spec directly for this partiuclar issue.

ACTION: Virali to do spec edits

RRSAgent: make minutes