SVG working group telecon, unofficial minutes for 2018 08 20

A reminder to working group members: we need to officially start a telcon
on IRC if we want minutes to be recorded!

(The magic words are `trackbot, start telcon`. Among other things, it then
invites the RRSAgent into the channel)

The Github Bot is very helpful in making sure minutes get posted where they
are needed, but only for topics that we formally associated with an issue
or pull request. It's less helpful when someone (ahem, me) says "Let's just
quickly review open pull requests to see which ones need full discussion."

Anyway, for everyone:

Here's the unedited record of IRC during our call, thanks to IRCCloud's
memory.

1:35 PM <krit> AmeliaBR: lets quickly skip to the open new issues
1:35 PM <krit> topic: Review open PRs
1:35 PM <krit> AmeliaBR: We got this path grammar. Is this redundant now?
1:35 PM <krit> AmeliaBR: should it stay open?
1:36 PM <krit> https://github.com/w3c/svgwg/pull/346
1:36 PM — github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
1:36 PM <krit> ericwilligers: there is still more content to merge but the
first part was merged. Will look into creating further PRs
1:36 PM <krit> AmeliaBR: so leave it open as reminder?
1:36 PM <krit> ericwilligers: sounds good.
1:37 PM <krit> github: https://github.com/w3c/svgwg/pull/374
1:37 PM — github-bot OK, I'll post this discussion to
https://github.com/w3c/svgwg/pull/374 ('d' presentation attribute: use
path() function).
1:37 PM <krit> GitHub: none
1:37 PM — github-bot OK, I won't post this discussion to GitHub.
1:38 PM <krit> AmeliaBR: we wanted to get some feedback from the original
commentors
1:38 PM <krit> krit: asked the original reporters but just added them this
morning.
1:38 PM <krit> Tav: There are 5 issues. Got 3 of them. Will take on the
other 2 and then reply.
1:39 PM <krit> AmeliaBR: https://github.com/w3c/svgwg/pull/524 is my try to
clean up build system. krit you wanted to look at it?
1:39 PM — github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
1:39 PM <krit> krit: do so ASAP
1:40 PM <krit> AmeliaBR: we had a contributor about language tags.
1:40 PM <krit> AmeliaBR: ericwilligers looked at it and his comments are
that changes are rehired.
1:40 PM <krit> s/required/rehired/
1:40 PM <krit> s/rehired /required/
1:40 PM <krit> ericwilligers: is there a test?
1:40 PM <krit> AmeliaBR: there should be and we can create an issue for it.
1:41 PM <krit> ericwilligers: how could we run tests?
1:41 PM <krit> AmeliaBR: would require manual testing.
1:41 PM <krit> Talking about: https://github.com/w3c/svgwg/pull/528
1:41 PM — github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
1:42 PM <krit> krit: from my point of view is that this is not a normative
change but a clarification.
1:42 PM <krit> AmeliaBR: we should add a test still and I'll check changes
section
1:43 PM <krit> ericwilligers: Browsers were following SVG 1.1
1:43 PM <krit> krit: It is requiring to follow BCP 47 according to SVG 1.1
already.
1:44 PM <krit> krit: https://github.com/w3c/svgwg/pull/533 removes child
keyword and child function.
1:44 PM — github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
1:44 PM <krit> AmeliaBR: someone should look at missing reference cleanup
anyway
1:44 PM <krit> ericwilligers: any implementation out there?
1:44 PM <krit> AmeliaBR: no
1:45 PM <krit> Tav: I'd love to have it but didn't implement it yet
1:46 PM <krit> AmeliaBR: is that all to say about open PRs.
1:47 PM <krit> topic: Wrong description of percentage units
1:47 PM <krit> GitHub: https://github.com/w3c/svgwg/issues/406
1:47 PM — github-bot OK, I'll post this discussion to
https://github.com/w3c/svgwg/issues/406 (Wrong description of percentage
units).
1:47 PM <krit> krit: what is the issue?
1:47 PM <krit> AmeliaBR: more or less suggested working clarification
1:47 PM <krit> AmeliaBR: not sure if we can discuss on a call effectively
1:48 PM <krit> AmeliaBR: Percentage were relative to the viewport but
should be viewBox according to the reported. But this may get messy. We
should read the section and come up with suggestions to change it.
1:48 PM <krit> Tav: do we have tests for that?
1:48 PM <krit> AmeliaBR: no normative changes but clarifying things in a
useful way
1:49 PM <krit> krit: the confusion is that viewport in SVG is something
different than in CSS
1:50 PM <krit> AmeliaBR: We might need to change a lot in the spec to avoid
using the same term in the SVG spec.
1:50 PM <krit> AmeliaBR: I thought Chris had a point how to clarify in the
issue.
1:52 PM <krit> krit: reading the suggestion I do think that he makes a good
point. Even without the viewport differences of CSS and SVG there are valid
points.
1:52 PM <krit> AmeliaBR: Maybe we could clarify the introduction text to be
more precise and remove the problematic statements in the paragraphs.
1:54 PM <krit> AmeliaBR: Specifically the paragraph about "SVG viewports
can be nested." and here the 2nd sentence needs clarification.
1:54 PM <krit> s/2nd/3rd
1:54 PM <krit> s/2nd/3rd/
1:55 PM <krit> AmeliaBR: do ppl like the idea to trimming down the section?
Then I could post a PR for others to look at.
1:55 PM <krit> Tav: ok
1:55 PM <krit> krit: sounds good
1:55 PM <krit> AmeliaBR: leave discussion on the bigger terminology to
issue #519.
1:56 PM <krit> topic: Deprecate type attribute on SVGStyleElement
1:56 PM — github-bot Successfully commented on
https://github.com/w3c/svgwg/issues/406
1:56 PM <krit> GitHub: https://github.com/w3c/svgwg/issues/411
1:56 PM — github-bot OK, I'll post this discussion to
https://github.com/w3c/svgwg/issues/411 (Deprecate type attribute on
SVGStyleElement?).
1:57 PM <krit> AmeliaBR: David suggested deprecating the type attribute
1:57 PM <krit> AmeliaBR: in SVG1.1 the attribute technically was required
1:57 PM <krit> AmeliaBR: in SVG 2 we added the suggestion to only use it
with CSS and don't make it a required attribute for content.
1:58 PM <krit> AmeliaBR: the idea is to deprecate the attribute entirely
now but keep it in SVG2
1:58 PM <krit> Tav: we do support XSL
1:58 PM <krit> AmeliaBR: even on style elements? Browsers do support for
external styles
1:58 PM <krit> Tav: maybe I am misremembering this. I can do some looking.
1:59 PM <krit> AmeliaBR: since qe added the default value... there could be
older tools that do not assume a default value.
1:59 PM <krit> AmeliaBR: InkScape a couple of version ago didn't support
the style element w/o typing.
1:59 PM <krit> AmeliaBR: for authoring tools it might still be a good idea
to keep support.
2:00 PM <krit> AmeliaBR: doesn't block deprecation;
2:01 PM <krit> krit: We could deprecate as a suggestion to implementors or
suggest not using it as a strong suggestion to not use it.
2:01 PM <krit> AmeliaBR: there is a difference between obsolete and
deprecation and the latter can be permanently
2:02 PM <krit> krit: on the server side, XSL ws used in the past.
2:02 PM <krit> krit: I'd still support deprecation because of low usage
today
2:02 PM <krit> Tav: no strong opinion
2:03 PM <krit> krit: this would also harmonise SVG style element with the
HTML one a bit more.
2:03 PM <krit> AmeliaBR: I am fine with deprecation but required support.
2:04 PM <krit> suggestedResolution: Make type attribute on Style element
deprecated but reuired for backwards compatibility.
2:04 PM <krit> Resolution: Make type attribute on Style element deprecated
but required for backwards compatibility.
2:04 PM <krit> topic: Update/move the normative-but-outdated SVG DOM
appendix
2:04 PM — github-bot Successfully commented on
https://github.com/w3c/svgwg/issues/411
2:05 PM <krit> github: https://github.com/w3c/svgwg/issues/520
2:05 PM — github-bot OK, I'll post this discussion to
https://github.com/w3c/svgwg/issues/520 (Update/move the
normative-but-outdated SVG DOM appendix).
2:05 PM <krit> AmeliaBR: title is specifically about SVGDOM appendix but it
actually is normative text. Other normative text is implementation
requirement.
2:06 PM <krit> AmeliaBR: one issue with the SVG DOM appendix: It is not
very up-to-date. Not all spec references are the latest version of the
spec. So some editing is needed.
2:06 PM <krit> AmeliaBR: Do we want to bring normative text out of appendix
and merge it into main sections.
2:07 PM <krit> krit: wasn't there a lot of normative text?
2:07 PM <krit> AmeliaBR: not anymore.
2:07 PM <krit> krit: we are just talking about normative text that is no
implementation requirement first?
2:07 PM <krit> AmeliaBR: everything that is required... some parts are
simple notes
2:08 PM <krit> AmeliaBR: I looked where the different implementation
reuiqremnts could go. SVG DOM probably in scripting.
2:08 PM <krit> AmeliaBR: First step: do we want to move content into the
chapters.
2:09 PM <krit> krit: Fine with specific normative text. What about
cross-section normative text?
2:09 PM <krit> AmeliaBR: we have some sections that are cross sections. We
could put the text there.
2:09 PM <krit> Tav: Getting it out of the end might be a good idea.
2:10 PM <krit> Tav: like crapping values that clip to a certain range. I
think there are even issues in filters because of this.
2:10 PM <krit> krit: sounds like there is an agreement
2:10 PM <krit> RESOLUTION: Move normative text from appendixes to chapters.
Discuss particular moves in the issues.
2:10 PM <AmeliaBR> s/crapping/clamping/
2:11 PM → florian joined (~florian@public.cloak)
2:11 PM <krit> AmeliaBR: need some volunteer to update the references and
see where text can move.
2:12 PM <krit> krit: I can volunteer for taking a first look and lining out
suggestions
2:14 PM <krit> topic: Rotating text
2:14 PM — github-bot Successfully commented on
https://github.com/w3c/svgwg/issues/520 and removed the "Agenda+" label and
removed the "Agenda+ F2F" label
2:14 PM <krit> GitHub: https://github.com/w3c/svgwg/issues/260
2:14 PM — github-bot OK, I'll post this discussion to
https://github.com/w3c/svgwg/issues/260 (Rotating text).
2:14 PM <krit> Tav:  this requires WG resolution though it is not a big
chnage
2:14 PM <krit> Tav: in SVG 1 everything was about rotating characters
2:15 PM <krit> AmeliaBR: I'd separate last bullet point into 2
2:16 PM <krit> Tav: SVG 1.1 talks about chars or glyphs. We actually want
graphical units called typographical characters
2:16 PM <krit> Tav: the glyph changes depending on the font and shaping
engine.
2:17 PM <krit> Tav: so you really want to use the smallest peace of text
that has to stay a unit
2:17 PM <krit> Tav: for western languages there really is no differences
but for east/mid/south asian languages it gets very complicated.
2:18 PM <krit> Tav: since we change talking from glyph to typorgrahic
characters we need to agree on a glyph.
2:19 PM <krit> krit: So minor change with bigger influence on certain
languages
2:19 PM <krit> AmeliaBR: pretty much
2:19 PM <krit> krit: I am fine with the change.
2:20 PM <krit> suggested resolution: Text layout attributes should apply to
typographic units as a whole
2:20 PM <krit> RESOLUTION: Text layout attributes should apply to
typographic units as a whole
2:21 PM <krit> topic: d property value
2:21 PM — github-bot Successfully commented on
https://github.com/w3c/svgwg/issues/260 and removed the "Agenda+" label and
removed the "Agenda+ F2F" label
2:21 PM <krit> GitHub: https://github.com/w3c/svgwg/issues/320
2:21 PM — github-bot OK, I'll post this discussion to
https://github.com/w3c/svgwg/issues/320 ('d' presentation attribute
inconsistent with shipped implementation and offset-path).
2:23 PM <krit> krit: So we only support the path CSS function and the none
keyword on the CSS property but not the path string directly?
2:23 PM <krit> ericwilligers: that is correct.
2:23 PM <krit> Tav: we treat the attribute and property the same. So for us
this is difficult.
2:24 PM <krit> ericwilligers: but we still support the old syntax on the
attribute.
2:24 PM <krit> ericwilligers: what is the implementation issue?
2:24 PM <krit> krit: WebKit and Blink usually use the same parser for the
attribute and property on presentation attributes.
2:26 PM <krit> AmeliaBR: there are some difference in implementations
already like unit less length value support for attributes and properties.
2:26 PM <krit> krit: but this is just a flag in the cSS parser for
implementations.
2:26 PM <krit> AmeliaBR: then we have the difference on transform attribute.
2:28 PM <krit> krit: here again... there is the problem of how transforms
get stored internally. It works for browsers but maybe not for d property.
Maybe it does though.
2:28 PM <krit> AmeliaBR: my concern is mostly about the different flavour
of the CSS shape function.
2:29 PM <krit> krit: I think there are 2 issues... 1) there is the
fill-rule value as part of path() shape function. and 2) the missing other
shape functions.
2:29 PM <krit> ericwilligers: that is right, that is missing.
2:29 PM <krit> AmeliaBR: yes, that is another concern.
2:30 PM <krit> krit: do we think we can spec something in SVG2 or should we
put it in other spec?
2:30 PM <krit> AmeliaBR: implementations just don't know what to do.
Otherwise they would do it.
2:31 PM <krit> Tav: We implemented the d property read-only
2:31 PM <krit> krit: with the CSS function path?
2:32 PM <krit> Tav: yes and that is reasonly because we treat attributes
and properties the same way.
2:32 PM <krit> AmeliaBR: one option would be to extend the syntax of the
attribute.
2:33 PM <ericwilligers> Custom property use case:
https://jsfiddle.net/ericwilligers/jq2af341/
2:34 PM <krit> krit: I wanted to get to this as well... should we add
everything from the property to the attribute as well?
2:38 PM <krit> krit: lets start with the discussion if we want to defer or
if we can finalise for SVG 2
2:38 PM <krit> AmeliaBR: my concern is as longer as the Chrome
implementation is out the less likely the implementation will change
2:39 PM <krit> krit: I share the concern and we already have this with
clip-path and the outdated implementation in Blink.
2:39 PM <krit> krit: I'd like to have a conclusion between the WG members.
2:39 PM <krit> AmeliaBR: Tav, what do you do about CSS transforms?
2:41 PM <krit> Tav: we don't implement it yet.
2:41 PM <krit> krit: Can you live with just starting work on the path
function for now AmeliaBR ?
2:42 PM <krit> AmeliaBR: if that is the choice between deferring and only
path yes.
2:42 PM <krit> AmeliaBR: I'd be happier with a living long term plan to
support all shape function.
2:43 PM — Tav just got cut off... calling back in
2:43 PM <krit> krit: I agree but the other shape functions are harder to
specify because of the relative values they support.
2:44 PM <krit> AmeliaBR: path() uses absolute units but the other shapes do
support percentages and should be relative to boxes. I don't want to lock d
on path() only.
2:45 PM <krit> krit: I'd like us to focus on path() only for now and
discuss boxes and other shapes later.
2:46 PM <krit> RESOLUTION: d property only supports path() for now but
potentially will support other CSS shape function
2:47 PM <krit> AmeliaBR: 2nd resolution would be to decide if d attribute
only supports string or will support shapes as well in the future.
2:48 PM <krit> ericwilligers: I'd advocate to let d attribute only support
path string and the property to support shape functions and no string
2:49 PM <krit> krit: the decision to only support string on the attribute
does not block us to add functions later
2:50 PM <krit> proposed RESOLUTION: The d property will support the shape
function path() only for now. The d attribute will only support SVG path
string an no functional notation. d will be a presentation attribute and
contributes into the CSS styling hierarchy as other presentation attributes.
2:51 PM <krit> RESOLUTION: The d property will support the shape function
path() only for now. The d attribute will only support SVG path string an
no functional notation. d will be a presentation attribute and contributes
into the CSS styling hierarchy as other presentation attributes.
2:51 PM <krit> krit: last question from me: Can we align path() to the CSS
Shape functions??
2:51 PM <krit> AmeliaBR: we could have one data type path() function
2:51 PM <AmeliaBR> <path-function> = path("..svg path code..")
2:52 PM <AmeliaBR> <shape-function>=<path-function> | ellipse(..) |
circle(..) | ...
2:54 PM <krit> krit: IMO it is still confusing for content creators why we
have patch() w/ fill rule and one path() w/o fill rule setting? We would
just need to clarify how the fill rule interacts with the
fill-rule/clip-rule properties?
2:55 PM <krit> AmeliaBR: My suggestion was to have 3 options for
fill-rule... default w/o fill rule would act as "auto" value... which would
be fill-rule/clip-rule property on the d property. But with explicit fill
rule to would overwrite the properties.
2:55 PM <krit> AmeliaBR: default would be current behavior and with the
explicit value the implementation would use this explicit value
2:56 PM <krit> https://drafts.fxtf.org/motion-1/#offsetpath-pathfunc
2:56 PM <krit> ericwilligers: it was removed as value since it is not
needed for offset-path
2:57 PM <krit> AmeliaBR: but it would be needed for clip-path and shape
properties.
2:58 PM <krit> AmeliaBR: currently the polygon() function has default
values for missing winding rules. We would need to clarify with the CSS WG
if we can make the default value dependent not he CSS property using the
function notation...
2:58 PM <krit> AmeliaBR: the same would apply to path()
2:59 PM <krit> AmeliaBR: define that the missing value does not compute
until used value time.
2:59 PM <AmeliaBR> s/not he/on the/
2:59 PM <krit> krit: could you bring this up to the CSS wG?
2:59 PM <krit> AmeliaBR: I could
2:59 PM <krit> ericwilligers: what is the motivation
3:01 PM <AmeliaBR> > Computed Values of Basic Shapes
https://drafts.csswg.org/css-shapes/#basic-shape-computed-values
3:01 PM <AmeliaBR> Omitted values are included and compute to their
defaults.
3:01 PM <krit> krit: any resolutions we need to add still?
3:02 PM <krit> RESOLUTION: Discuss winding rule issue of polygon() and
path() with CSS WG. Especially with regards of use in different properties
like offset-path, d and clip-path.
3:02 PM <krit> RESOLUTION: Keep path() without fill rule on d property for
now.
3:03 PM <krit> trackbot, end telcon
3:03 PM — trackbot is ending a teleconference.
3:03 PM <trackbot> Zakim, list attendees
3:03 PM — github-bot Successfully commented on
https://github.com/w3c/svgwg/issues/320 and removed the "Agenda+" label and
removed the "Agenda+ F2F" label
3:04 PM <trackbot> RRSAgent, please draft minutes
3:04 PM <trackbot> RRSAgent, bye
3:05 PM <krit> RRSAgent, please draft minutes
3:06 PM <krit> looks like RRSAgent got lazy