scribe nick: krit
<scribe> scribenick: krit
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
<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+
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
<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
<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)
<liam> github issue: https://github.com/w3c/svgwg/issues/331
https://github.com/w3c/svgwg/issues/331#issuecomment-388108799
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
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/raining/remaining/ Succeeded: s/Use TypeError/Use TypeError for out-of-range values on baseVal/ Succeeded: s/AmeliaBR/krit/ Present: Tavmjong dstorey liam stakagi BogdanBrinza AmeliaBR Found ScribeNick: krit Inferring Scribes: krit Agenda: https://lists.w3.org/Archives/Public/www-svg/2018Jun/0008.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 11 Jun 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]