W3C home > Mailing lists > Public > www-svg@w3.org > June 2018

Fwd: Meeting minutes 11 June 2018

From: Dirk Schulze <dschulze@adobe.com>
Date: Mon, 11 Jun 2018 20:30:37 +0000
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <4B8D6602-E7C9-419F-8BCB-FDB606199D66@adobe.com>

Begin forwarded message:

Hi all,

Here are the meeting minutes of the SVG WG meeting from 11 June 2018: https://www.w3.org/2018/06/11-svg-minutes.html


scribe nick: krit
<scribe> scribenick: krit
HTML 5.3
liam: We are waiting for the IDL changes of WHATWG
... should add this to our feedback
<AmeliaBR> https://lists.w3.org/Archives/Public/www-svg/2018Jun/0009.html
krit: I think it covers the discussion about IDL
liam: don't think there is more to it then
Review remaining items "at risk"
<liam> https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3AAgenda%2B
krit: do we have a list of remaining items?
AmeliaBR: We don't have a nice list but attribute and rendering changes would be on this list
... We could go through the attribute value list or SVG changelogs.
liam: we started in November and went through some of it
... if we don't have a full list within 2 weeks we should republish a cR with current at-risk items in the spec
AmeliaBR: are we republishing as new CR or go back to WD?
... WD doesn't need to address all issues.
liam: I personally think we should show progress with republished CR
krit: We might need to at least review open issues after last publication.
AmeliaBR: Some changes need to get polished
liam: I think it would be ideal to do as much of the editing. It is up to us to set the bar. We must stay within the guidelines of the process of course. There are minor issues we need to track.
chris: We can say that we are discussing issues still
krit: I'd support a new CR mostly for other specs to reference a spec that is in CR already.
AmeliaBR: The other side of republishing is the SVG2.1 branch. We need to do the edits that we agreed on. Need to make a list of changes since 2.0.
liam: We can publish this as FPWD
... bar is low so we don't need a complete list of changes.
... we could publish with a note that the list of changes will follow and a short list with summary of things that got in
AmeliaBR: makes sense. We set them up on GitHub so we could provide a diff between the 2 branches.
liam: I try to find the barries of publishing and getting rid of them
... We might not get to publishing CR of 2.0 but should get close to it.
RESOLUTION: We republish SVG 2.0 as an updated CR ASAP
<liam> https://github.com/w3c/svgwg/issues?q=is%3Aopen+is%3Aissue+label%3AAgenda%2B
krit: anything else to discuss? Bogdan seems to work on the list of at-risk?
<liam> https://github.com/w3c/svgwg/issues/468
AmeliaBR: disposal of comment list
<liam> github issue 468
<chris> github:
liam: lets go through the issues
<liam> github issue https://github.com/w3c/svgwg/issues/468
<liam> github issue: https://github.com/w3c/svgwg/issues/468
liam: is there anything we need to do about the cursors on SVG links?
AmeliaBR: links should have a pointer cursor according to CSS
... we need to have the normative text for it.
chris: CSS agreed to a generic language to require pointer cursor and that goes to CSS-UI
<AmeliaBR> https://bugs.chromium.org/p/chromium/issues/detail?id=841146
AmeliaBR: Safari and Firefox do support the pointer cursor
liam: chris: So not at risk anymore
... we could do this in 2.1 but it is a small risk so put it on 2.0
dstorey: support it in 2.0. Just an update on UA stylesheet. Really easy
AmeliaBR: We need to add this change to the spec.
... sufficient testing in place.
RESOLUTION: Add UA stylesheet change into normative text on SVG 2.0 to show cursor pointer on links
<liam> github issue: https://github.com/w3c/svgwg/issues/423
<AmeliaBR> Test case PR (already merged): https://github.com/web-platform-tests/wpt/pull/11396
<liam> github issue: https://github.com/w3c/svgwg/issues/423
out of range value on an enum in the DOM
<liam> github issue: https://github.com/w3c/svgwg/issues/423
krit: this seems to be on svgDOM
liam: seems a mix of browsers do the one thing and other browsers another thin g
krit: all tested browsers throw (Edge not tested)
... just that they throw differently
... according to the comment, Edge throws but does set baseVal to something else
... first question should be throw or not to throw
chris: I think we should keep baseVal unchanged which means throw
... 1. most implementations do it 2. it is more useful
AmeliaBR: silently failing is what CSS does.
... we should not set the value on invalid value. Shall we throw or be silent about it.
RESOLUTION: not change current baseVal on setting it to an out-of-range value
... Throw on out-of-range value for baseValue
<liam> https://wpt.fyi/results/svg/types/scripted/SVGAnimatedEnumeration-SVGClipPathElement.html has results for safari & firefox
<liam> ff - SyntaxError: An invalid or illegal string was specified
krit: Open question: What should we throw. Put this part back to GitHub?
<liam> safari - SVG_INVALID_VALUE_ERR
<liam> chrome - TypeError
krit: I'd be in favour for TypeError
liam: invalid value or TypeError might make sense.
AmeliaBR: TypeError would be more in line with what we spec. But depends on how difficult it is for browser
RESOLUTION: Use TypeError for out-of-range values on baseVal and wait for UA implementation feedback
<liam> github issue: https://github.com/w3c/svgwg/issues/394
dur attribute should permit leading
<liam> github issue: https://github.com/w3c/svgwg/issues/394
liam: AmeliaBR points out that SMIL doesn't support the dot
AmeliaBR: can we redefine it in SVG with a new syntax or do we continue to align with SMIL? This is not in SVG 2.0 anymore.
krit: suggest to leave issue for later.
AmeliaBR: we should discuss number issues in general first. (differences between CSS and SVG)
floating point differences of numbers between CSS and SVG
<liam> github issue: https://github.com/w3c/svgwg/issues/331
liam: noticed in a bug in arc and there was no definition when to floating point numbers are the same.
AmeliaBR: I'd not base number equality on the number format but on the mathematical value.
krit: question: do we want to align numbers for all uses in all attributes.
AmeliaBR: general we should align
... trailing dot is not adding anything
krit: trailing dot is commonly used in programming though not a reason to have it in CSS/SVG.
chris: Probably not a real world problem.
krit: do we need to align specs and implementation? What about UAs that continue to want to support them?
... FF already clearly stated that CSS and SVG number must use the same format for their implementation. So either CSS supports SVG numbers as well or they won't implement.
chris: Use CSS numbers, allow UAs to implement SVG 1.1 numbers but strongly discourage to use them
liam: hard to test... but in this case maybe the best.
RESOLUTION: Use CSS numbers, allow UAs to implement SVG 1.1 numbers but strongly discourage to use them
AmeliaBR: who is doing it?
krit: I'll take the action but it might take some time.
RESOLUTION: Same applies to SVG transform attributes in CSS Tansform
<AmeliaBR> github-bot, end topic
Received on Monday, 11 June 2018 20:31:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:14 UTC