SVG Working Group Teleconference -- 21 Apr 2016

trackbot, start telcon

<scribe> Meeting: SVG London 2016

Chapter 4: Document Structure

nikos: We got bogged down on this chapter yesterday, but would like to get it finished. Let's skip past use and go on

<scribe> scribe: nikos

AmeliaBR: I'll look at rewriting use on the way home
... The tricky part will be making use of x,y,width,height properties without lots of special casing

chaals: There's another issue with multilingual titles
... if you have to use aria-label with title you can't do that with a multi lingual title

<AmeliaBR> Demo comparing behavior of x+y attributes on <use> versus image, rect, foreignObject: http://codepen.io/AmeliaBR/full/BFowL/

chaals: if you say aria-labeledby you can't refer to one of the titles

AmeliaBR: aria is based on the assumption that you're probably using javascript
... which is unfortunate because there's a lot that is good from a declarative point of view

chaals: unless you can find out what language the user agent is presenting...

AmeliaBR: the idea is that you shouldn't need an aria label attribute, that's a fall bcak for when there's no svg title element
... in the svg mapping spec, we have wording that the correct name for the accessible name calculation is the title chosen

chaals: Think we should file an issue, point i18n at it and move on

nikos: let's jump to common attributes

https://svgwg.org/svg2-draft/struct.html#CommonAttributes

AmeliaBR: conditional processing needs a lot of discussion but we can skip it for now
... back to 4.10, there has been discussion in CSS as to whether base should affect url notation
... which affects a lot of svg properties
... think browsers are consistent when base is set declarative, but get wonky when it's updated
... we probably don't need to discuss now but may affect whether something needs to be taken out of CR if we don't have somehting stable and testable

<chaals> issue on multilingual titles and aria

AmeliaBR: xml:lang is used in favour of lang, does anyone remember why we decided that?

nikos: In the past we said that lang favours xml:lang, not sure when that was reverted
... Original discussion on lang vs xml:lang https://www.w3.org/2015/02/11-svg-minutes.html#item09

<chaals> CMN: tabindex needs more information about how it works - I can provide a PR for that.

<chaals> ACTION: CMN to expand the description of tabindex. [recorded in http://www.w3.org/2016/04/21-svg-minutes.html#action01]

<trackbot> Error finding 'CMN'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<chaals> ACTION: chaals to expand the definition of tabindex [recorded in http://www.w3.org/2016/04/21-svg-minutes.html#action02]

<trackbot> Created ACTION-3840 - Expand the definition of tabindex [on Charles McCathie Nevile - due 2016-04-28].

chaals: it's surprising that title and desc don't get a role, might be worth adding a note

<AmeliaBR> In 4.12.3, Remove the "Unlike..." phrase on strong native semantics, so that sentence starts "State and property attributes".

<AmeliaBR> SVG-AAM Editor's Draft: https://w3c.github.io/aria/svg-aam/svg-aam.html

<AmeliaBR> Language is really confusing in 4.13.1 re partial implementation (for all SVG user agents) of the HTML-defined extensions to Document interface. Need to clarify that HTML-support user agents must implement full interface, others implement this limited set.

Chapter 5: Styling

AmeliaBR: Regarding the style element, SVG 2 is in sync with HTML5, but HTML51 adds the scoped attribute
... would be good for SVG
... it's included in HTML so you can import widgets with self contained files and that sort of thing

RESOLUTION: Add the scoped attribute from HTML51 style element to SVG's style element

chaals: Chrome removed support - said it was too complicated
... I'm going to file an issue on HTML51 stating there isn't enough interop so it may get dropped from HTML51

<AmeliaBR> Section 5.7, the prose describing the user stylesheet for transform-origin isn't quite correct. Parentheses should be "(except for root ‘svg’ elements and ‘svg’ elements that are the child of a ‘foreignObject’ element or an element in a non-SVG namespace; these elements must transform around their center)"

nikos: I filed an issue to track the scoped attribute - https://github.com/w3c/svgwg/issues/118

<chaals> HTML issue: should style scoped be removed

AmeliaBR: Anyone opposed to the for the presentation attributes with no name clashes, we make them valid on any element?
... then we won't have to update this table anytime an element is created
... we still need restrictions on geometry presentation attributes, otherwise things break
... Chrome and Edge already do things that way

<AmeliaBR> Based on quick tests, it looks like Chrome & Edge already implement it this way, recognizing a fill="red" presentation attribute on <fe*> elements not in that list.

<AmeliaBR> Chapter 6: Geometry properties

<AmeliaBR> Re "illegal value", here is the CSS 2.1 reference of what that means: https://www.w3.org/TR/CSS21/syndata.html#illegalvalues

<AmeliaBR> Issues re geometry property chapter

<AmeliaBR> GH#74: https://github.com/w3c/svgwg/issues/74 "Initial value for the 'rx' and 'ry' properties"

<AmeliaBR> Nikos notes that it says width & height of auto are used as 0, but that's not true of <svg> (used is 100%)

<AmeliaBR> And <mask> is even more complicated (defaults are x/y -10%, width/height 120%, like filters). CSS masking defines them as attributes, not properties: https://drafts.fxtf.org/css-masking-1/#MaskElement

<AmeliaBR> Agreed: remove the mention of <mask> from the geometry properties chapter. CSS masking can opt-in to upgrading attributes to properties (with necessary changes to user style sheets, etc.) later.

<AmeliaBR> Images were also supposed to support proper "auto" sizing, as an SVG 2 requirement: https://svgwg.org/svg2-draft/embedded.html#ImageElement

<AmeliaBR> CSS spec (ED) for auto-sizing replaced content: https://drafts.csswg.org/css-sizing-3/#auto-box-sizes

<AmeliaBR> Not in the draft, but for this chapter, is GH#49 https://github.com/w3c/svgwg/issues/49, AKA, what to do with path data as a geometric property

<scribe> scribe: nikos

AmeliaBR: There's lots of discussion in the github, some is things for the future, but some is stuff needed for SVG 2

Tav: Why do we need to solve this now?

AmeliaBR: there's a strong need for this in CSS animations and such
... We have issues with the same or similar attributes with same name different effect, etc.
... We need to have a consistent naming scheme so one property has a specific meaning regardless of the element
... we are changing the syntax anyway because CSSWG baulked at the idea of having full svg path data as a series of tokens that needed to be parsed
... svg path data parsing rules don't place nicely with css parsing rules

nikos: could you summarise the discussion so far?

AmeliaBR: d is not a good name
... d is used for two different things, path and textPath
... we also have polygon and polyline points which have the same effect as d does on path
... but different syntax
... difference in syntax can be resolved using css functions
... the question is what is the name of that property

nikos: shape

AmeliaBR: other suggestion is geometry
... with shape, we have shape-insdie and shape-outside
... so having shape on its own makes it seem like a shorthand
... though its logical
... [missed a bit]

Tav: You have the problem that shape-inside can have multiple shapes and you flow from one to the next
... shape-subtract is a bit different because it's our (SVG) way of setting exclusions

AmeliaBR: so if we leave shape for text stuff, geometry would be the other option

nikos: ok with geometry

Tav: It's going to be hard for us to implement css function notation

nikos: was it just the name we need to work out?

AmeliaBR: other thing is whether we make geometry the magic toggle for basic shapes
... so geometry: circle looks at cx, cy, etc
... there's nothing in the computed style that explains how the properties of the shape are worked out, it's based on the tag name

Tav: doesn't CSS already have a circle function where you have to provide the values in the right order?

AmeliaBR: yes, that's a complication

Tav: think this isn't something we should try to get into SVG 2
... need to work it out with CSS

AmeliaBR: not sure there's anything we need to work out with css.
... at the moment we have properties that describe the parameters of the shape, but the shape itself comes from the xml side
... it's an incomplete model. We're half way into CSS but still have dependency on xml

Tav: whole point is to get path animation right?

AmeliaBR: yes
... Chrome has deprecated SMIL and MS never implemented it. So there's strong demand from authors for path animation, and strong demand from browsers to do it in CSS
... the reason to change it now is to define a logical model that is extensible in the future

Tav: I'm just worried it's going to be an awful lot of work and I don't want to see the animation of d stalled
... I think it's a logical goal, just think it's too much for now
... Chrome already has d ready to go, they just want a name

AmeliaBR: we can leave off keyword values, that's something that can be defined as an additional property
... what we do need is one name for path data and polygon, polyline points
... where the value between teh three will be distinguished by the css shape function

Tav: I don't see a need to animate polyline

AmeliaBR: with charts where you ahve lots of data in an array it's a lot easier

Tav: It's the same without the initial M

AmeliaBR: ok so we're ok with geometry as the name and have it effect path, polygon, and polyline, and define a new CSS shape polyline function somewhere in CSS?

chaals: Not going to move the spec fowards by inventing functionality without any implementer input

nikos: Google has been supportive of Amelia's proposal on github, but I agree we should focus on speccing the minumum now and extend further through a module

AmeliaBR: we need to change the name of the attribute on textPath so it doesn't use d
... there are no implementations as far as I know so we 're not breaking anything

nikos: there's a few other places where we use path data. Somtimes without the inital moveto, that should be distinct

Tav: there's usage of a path attribute

RESOLUTION: Rename the d attribute on textPath to 'path'. It will just be an attribute for now.

Tav: if you want to animate textPath reference a path
... I would just use 'd' for the presentation attribute for path data

AmeliaBR: value will just be a string

Tav: geometry can be added later to do what it needs to do

<AmeliaBR> https://svgwg.org/svg2-draft/paths.html#DProperty

nikos: If Chrome want css functions they can provide a proposal
... and we'll do that as a separate module

AmeliaBR: are we going to leave points as an attribute for now?

Tav: Can see that might cause some confusion
... Can we make it a presentation attribute?

nikos: If we can make d a presentation attribute we can make points one

AmeliaBR: question is do we treate it as a string or a list of numbers?

RESOLUTION: d will become a presentation attribute (no name change) with path data string as a value and for now it only affects the path element

AmeliaBR: since it's only going to affect path elements we can leave it in the paths chapter rather than moving to geometry

- DRAFT -

SVG Working Group Teleconference

21 Apr 2016

Attendees

Contents

Chapter 4: Document Structure

Chapter 5: Styling

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output