See also: IRC log
trackbot, start telcon
<scribe> Meeting: SVG London 2016
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
... 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
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
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.
AmeliaBR: Regarding the style
element, SVG 2 is in sync with HTML5, but HTML51 adds the
... 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
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
... 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
AmeliaBR: other suggestion is
... 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
... 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?
... 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
... 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
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
... 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
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 Scribe: nikos Inferring ScribeNick: nikos Present: nikos Tav AmeliaBR chaals LJWatson stakagi Found Date: 21 Apr 2016 Guessing minutes URL: http://www.w3.org/2016/04/21-svg-minutes.html People with action items: chaals cmn[End of scribe.perl diagnostic output]