IRC log of svg on 2016-04-21

Timestamps are in UTC.

01:51:43 [shepazu]
shepazu has joined #svg
07:08:25 [chaals]
chaals has joined #svg
07:58:29 [stakagi]
stakagi has joined #svg
08:18:19 [Tav]
Tav has joined #svg
08:22:41 [chaals]
chaals has joined #svg
08:23:56 [nikos]
trackbot, start telcon
08:23:58 [trackbot]
RRSAgent, make logs public
08:24:00 [trackbot]
Zakim, this will be GA_SVGWG
08:24:00 [Zakim]
ok, trackbot
08:24:01 [trackbot]
Meeting: SVG Working Group Teleconference
08:24:01 [trackbot]
Date: 21 April 2016
08:24:26 [nikos]
Meeting: SVG London 2016
08:24:30 [nikos]
chair: nikos
08:24:32 [nikos]
present+ nikos
08:24:41 [nikos]
present+ Tav
08:24:46 [LJWatson]
LJWatson has joined #svg
08:24:50 [nikos]
present+ AmeliaBR
08:24:56 [nikos]
present+ chaals
08:24:58 [nikos]
present+ LJWatson
08:26:49 [nikos]
Topic: Chapter 4: Document Structure
08:27:09 [nikos]
nikos: We got bogged down on this chapter yesterday, but would like to get it finished. Let's skip past use and go on
08:27:22 [stakagi]
present+ stakagi
08:27:26 [nikos]
scribe: nikos
08:27:50 [nikos]
AmeliaBR: I'll look at rewriting use on the way home
08:28:40 [nikos]
AmeliaBR: The tricky part will be making use of x,y,width,height properties without lots of special casing
08:29:09 [AmeliaBR]
AmeliaBR has joined #svg
08:29:11 [nikos]
chaals: There's another issue with multilingual titles
08:29:25 [nikos]
... if you have to use aria-label with title you can't do that with a multi lingual title
08:29:37 [AmeliaBR]
Demo comparing behavior of x+y attributes on <use> versus image, rect, foreignObject:
08:30:08 [nikos]
... if you say aria-labeledby you can't refer to one of the titles
08:30:17 [nikos]
AmeliaBR: aria is based on the assumption that you're probably using javascript
08:30:30 [nikos]
... which is unfortunate because there's a lot that is good from a declarative point of view
08:30:44 [nikos]
chaals: unless you can find out what language the user agent is presenting...
08:31:14 [nikos]
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
08:31:33 [nikos]
... in the svg mapping spec, we have wording that the correct name for the accessible name calculation is the title chosen
08:31:50 [nikos]
chaals: Think we should file an issue, point i18n at it and move on
08:32:35 [nikos]
nikos: let's jump to common attributes
08:32:36 [nikos]
08:33:14 [nikos]
AmeliaBR: conditional processing needs a lot of discussion but we can skip it for now
08:33:33 [nikos]
... back to 4.10, there has been discussion in CSS as to whether base should affect url notation
08:33:44 [nikos]
... which affects a lot of svg properties
08:34:10 [nikos]
... think browsers are consistent when base is set declarative, but get wonky when it's updated
08:34:38 [nikos]
... 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
08:38:50 [chaals]
-> issue on multilingual titles and aria
08:43:03 [nikos]
AmeliaBR: xml:lang is used in favour of lang, does anyone remember why we decided that?
08:43:23 [nikos]
nikos: In the past we said that lang favours xml:lang, not sure when that was reverted
08:43:38 [nikos]
... Original discussion on lang vs xml:lang
08:45:25 [chaals]
CMN: tabindex needs more information about how it works - I can provide a PR for that.
08:45:45 [chaals]
ACTION: CMN to expand the description of tabindex.
08:45:45 [trackbot]
Error finding 'CMN'. You can review and register nicknames at <>.
08:45:56 [chaals]
ACTION: chaals to expand the definition of tabindex
08:45:56 [trackbot]
Created ACTION-3840 - Expand the definition of tabindex [on Charles McCathie Nevile - due 2016-04-28].
08:48:53 [nikos]
chaals: it's surprising that title and desc don't get a role, might be worth adding a note
08:59:18 [stakagi_]
stakagi_ has joined #svg
09:00:41 [AmeliaBR]
In 4.12.3, Remove the "Unlike..." phrase on strong native semantics, so that sentence starts "State and property attributes".
09:04:33 [AmeliaBR]
SVG-AAM Editor's Draft:
09:08:25 [stakagi]
stakagi has joined #svg
09:13:53 [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.
09:46:49 [AmeliaBR]
AmeliaBR has joined #svg
09:48:21 [LJWatson]
LJWatson has joined #svg
09:51:12 [nikos]
Topic: Chapter 5: Styling
09:55:46 [nikos]
AmeliaBR: Regarding the style element, SVG 2 is in sync with HTML5, but HTML51 adds the scoped attribute
09:55:51 [nikos]
... would be good for SVG
09:56:10 [nikos]
... it's included in HTML so you can import widgets with self contained files and that sort of thing
09:56:35 [nikos]
RESOLUTION: Add the scoped attribute from HTML51 style element to SVG's style element
10:04:36 [nikos]
chaals: Chrome removed support - said it was too complicated
10:04:51 [nikos]
... I'm going to file an issue on HTML51 stating there isn't enough interop so it may get dropped from HTML51
10:11:34 [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)"
10:11:35 [nikos]
nikos: I filed an issue to track the scoped attribute -
10:20:12 [chaals]
-> HTML issue: should style scoped be removed
10:27:20 [nikos]
AmeliaBR: Anyone opposed to the for the presentation attributes with no name clashes, we make them valid on any element?
10:27:29 [nikos]
... then we won't have to update this table anytime an element is created
10:28:16 [nikos]
... we still need restrictions on geometry presentation attributes, otherwise things break
10:29:49 [nikos]
... Chrome and Edge already do things that way
10:30:03 [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.
10:58:29 [AmeliaBR]
Chapter 6: Geometry properties
10:58:47 [AmeliaBR]
Re "illegal value", here is the CSS 2.1 reference of what that means:
11:05:00 [AmeliaBR]
Issues re geometry property chapter
11:05:32 [AmeliaBR]
GH#74: "Initial value for the 'rx' and 'ry' properties"
11:13:35 [AmeliaBR]
AmeliaBR has joined #svg
11:43:08 [stakagi_]
stakagi_ has joined #svg
12:18:47 [stakagi]
stakagi has joined #svg
13:00:54 [AmeliaBR]
AmeliaBR has joined #svg
13:12:33 [AmeliaBR]
Nikos notes that it says width & height of auto are used as 0, but that's not true of <svg> (used is 100%)
13:17:00 [LJWatson]
LJWatson has joined #svg
13:18:55 [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:
13:19:40 [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.
13:22:19 [AmeliaBR]
Images were also supposed to support proper "auto" sizing, as an SVG 2 requirement:
13:25:55 [AmeliaBR]
CSS spec (ED) for auto-sizing replaced content:
13:47:48 [AmeliaBR]
Not in the draft, but for this chapter, is GH#49, AKA, what to do with path data as a geometric property
13:51:49 [nikos]
scribe: nikos
13:52:05 [nikos]
AmeliaBR: There's lots of discussion in the github, some is things for the future, but some is stuff needed for SVG 2
13:53:33 [nikos]
Tav: Why do we need to solve this now?
13:53:43 [nikos]
AmeliaBR: there's a strong need for this in CSS animations and such
13:54:03 [nikos]
... We have issues with the same or similar attributes with same name different effect, etc.
13:54:19 [nikos]
... We need to have a consistent naming scheme so one property has a specific meaning regardless of the element
13:54:39 [nikos]
... 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
13:54:51 [nikos]
... svg path data parsing rules don't place nicely with css parsing rules
13:55:42 [nikos]
nikos: could you summarise the discussion so far?
13:55:45 [nikos]
AmeliaBR: d is not a good name
13:55:52 [nikos]
... d is used for two different things, path and textPath
13:56:06 [nikos]
... we also have polygon and polyline points which have the same effect as d does on path
13:56:15 [nikos]
... but different syntax
13:56:25 [nikos]
... difference in syntax can be resolved using css functions
13:56:31 [nikos]
... the question is what is the name of that property
13:56:33 [nikos]
nikos: shape
13:56:41 [nikos]
AmeliaBR: other suggestion is geometry
13:56:52 [nikos]
... with shape, we have shape-insdie and shape-outside
13:57:02 [nikos]
... so having shape on its own makes it seem like a shorthand
13:57:14 [nikos]
... though its logical
13:57:21 [nikos]
... [missed a bit]
13:57:59 [nikos]
Tav: You have the problem that shape-inside can have multiple shapes and you flow from one to the next
13:58:44 [nikos]
... shape-subtract is a bit different because it's our (SVG) way of setting exclusions
13:59:51 [nikos]
AmeliaBR: so if we leave shape for text stuff, geometry would be the other option
13:59:57 [nikos]
nikos: ok with geometry
14:00:17 [nikos]
Tav: It's going to be hard for us to implement css function notation
14:01:29 [nikos]
nikos: was it just the name we need to work out?
14:01:48 [nikos]
AmeliaBR: other thing is whether we make geometry the magic toggle for basic shapes
14:01:56 [nikos]
... so geometry: circle looks at cx, cy, etc
14:02:50 [nikos]
... 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
14:03:51 [nikos]
Tav: doesn't CSS already have a circle function where you have to provide the values in the right order?
14:03:58 [nikos]
AmeliaBR: yes, that's a complication
14:04:06 [nikos]
Tav: think this isn't something we should try to get into SVG 2
14:04:12 [nikos]
... need to work it out with CSS
14:04:41 [nikos]
AmeliaBR: not sure there's anything we need to work out with css.
14:04:56 [nikos]
... at the moment we have properties that describe the parameters of the shape, but the shape itself comes from the xml side
14:05:13 [nikos]
... it's an incomplete model. We're half way into CSS but still have dependency on xml
14:05:19 [nikos]
Tav: whole point is to get path animation right?
14:05:22 [nikos]
AmeliaBR: yes
14:06:47 [nikos]
AmeliaBR: 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
14:07:33 [nikos]
AmeliaBR: the reason to change it now is to define a logical model that is extensible in the future
14:08:06 [nikos]
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
14:08:26 [nikos]
... I think it's a logical goal, just think it's too much for now
14:08:35 [nikos]
... Chrome already has d ready to go, they just want a name
14:08:57 [nikos]
AmeliaBR: we can leave off keyword values, that's something that can be defined as an additional property
14:09:12 [nikos]
... what we do need is one name for path data and polygon, polyline points
14:09:31 [nikos]
... where the value between teh three will be distinguished by the css shape function
14:10:47 [nikos]
Tav: I don't see a need to animate polyline
14:11:12 [nikos]
AmeliaBR: with charts where you ahve lots of data in an array it's a lot easier
14:11:20 [nikos]
Tav: It's the same without the initial M
14:14:55 [nikos]
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?
14:15:25 [nikos]
chaals: Not going to move the spec fowards by inventing functionality without any implementer input
14:15:52 [nikos]
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
14:16:10 [nikos]
AmeliaBR: we need to change the name of the attribute on textPath so it doesn't use d
14:16:22 [nikos]
... there are no implementations as far as I know so we 're not breaking anything
14:17:00 [nikos]
nikos: there's a few other places where we use path data. Somtimes without the inital moveto, that should be distinct
14:17:21 [nikos]
Tav: there's usage of a path attribute
14:19:13 [nikos]
RESOLUTION: Rename the d attribute on textPath to 'path'. It will just be an attribute for now.
14:19:32 [nikos]
Tav: if you want to animate textPath reference a path
14:19:42 [nikos]
Tav: I would just use 'd' for the presentation attribute for path data
14:19:48 [nikos]
AmeliaBR: value will just be a string
14:20:18 [nikos]
Tav: geometry can be added later to do what it needs to do
14:21:09 [AmeliaBR]
14:21:11 [nikos]
nikos: If Chrome want css functions they can provide a proposal
14:21:54 [nikos]
... and we'll do that as a separate module
14:22:34 [nikos]
AmeliaBR: are we going to leave points as an attribute for now?
14:23:01 [nikos]
Tav: Can see that might cause some confusion
14:23:12 [nikos]
... Can we make it a presentation attribute?
14:23:19 [nikos]
nikos: If we can make d a presentation attribute we can make points one
14:23:31 [nikos]
AmeliaBR: question is do we treate it as a string or a list of numbers?
14:24:28 [nikos]
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
14:25:10 [nikos]
AmeliaBR: since it's only going to affect path elements we can leave it in the paths chapter rather than moving to geometry
14:26:44 [nikos]
rrsagent, pointer
14:26:44 [RRSAgent]
14:26:54 [nikos]
rrsagent, make minutes
14:26:54 [RRSAgent]
I have made the request to generate nikos
15:32:01 [AmeliaBR]
AmeliaBR has joined #svg
16:17:56 [TabAtkins]
Hey y'all, the CSS Scoping spec is now updated to the current Shadow DOM model.