<krit> present SairusPatel
<scribe> scribenick: AmeliaBR
Dirk: As of last week, we have Myles joining the WG from Apple. He's particularly interested in a limited SVG spec for fonts. And we have Sairus from Adobe.
Sairus: I'm Adobe's lead on OpenType project. So I've been working with Sairus and Dean at Adobe on the SVG OpenType spec.
github: https://github.com/w3c/svgwg/issues/559
<SairusPatel> "Myles & Dean at Apple" should be: "Myles & Dean at Apple". I may have misspoken
s/"Sairus & Dean at Adobe" should be: "Myles & Dean at Apple". I may have misspoken//
Dirk: Question is whether
vector-effect is just a visual effect or whether it actually
affects geometry, and therefore hit-testing and the API.
... I'd like to get a resolution to adopt fsoder's
recommendation: vector-effect should affect these APIs.
Amelia: Agree that's ideal. Only concern was implementation cost, but I think browsers are already doing all the calculations so there shouldn't be much overhead.
Dirk: I don't think there is any implementation concern.
RESOLUTION: vector-effects property contributes to hit-testing and `isPointInStroke`.
github: https://github.com/w3c/svgwg/issues/306
Dirk: The spec has many other
values for vector-effects, which were marked at risk because of
lack of implementations.
... We now have a browser implementation (Firefox), plus also
JavaScript implementations.
Tav: And these are independent?
Dirk: Yes.
Tav: I'm also planning to work on an implementation in Inkscape.
Eric: Are there tests merged into WPT, or is this specifically the PR that is currently open?
Tav: I suspect those are the tests we're talking about.
Amelia: Might be merged tests for non-scaling-stroke.
<ericwilligers> vector-effects tests that need review: https://github.com/web-platform-tests/wpt/pull/13302
Dirk: You'll want to check with
the Firefox people, since they would have made some for their
implementation.
... So, question is: can we remove the "at risk" flag.
Tav: We had previously agreed that JS implementations do count for PR status.
Amelia: Is there any harm in keeping it at-risk for now? Does that prevent going to PR status?
Eric: Has anyone looked at the polyfill? Is it high quality for production sites?
Dirk: There's a link on the issue (#306). I haven't looked at it carefully.
Eric: It looks good at a glance. I think we can count it as an implementation.
Amelia: Still need to do full testing.
Dirk: But that's true for many features.
RESOLUTION: Remove "at-risk" flag for vector-effects in SVG 2.
github: https://github.com/w3c/svgwg/issues/469
Amelia: CSS has introduced new
keywords for `width` and `height`. Since we re-use those
properties for SVG geometry, we need to define what happens
when they're used. My recommendation is to follow TabAtkins'
suggestion & treat as `auto`.
... Confusion is that `auto` means different things on
different SVG elements.
Dirk: Second question is where to define. If CSS adds additional keywords in the future, how to handle them? Shouldn't the spec say how the keyword behaves?
Eric: Can't we just say that all new keywords act as auto?
Dirk: But maybe certain keywords in future would make sense to have a different value.
Amelia: What about: "Any other keyword values behave as auto for SVG elements, unless otherwise defined in the spec that introduces them."?
Dirk, Eric: OK
RESOLUTION: New CSS sizing keywords behave like auto for SVG elements, unless spec'd otherwise when they are defined
github: https://github.com/w3c/svgwg/pull/374
Eric: I've updated the PR to reflect different syntax for the attribute.
Amelia: I'll try to take a look at that.
Eric: Issue for today is, can we get a second implementation in time for PR?
Tav: I'd be willing to do it for Inkscape.
Eric: Are there any polyfills?
Dirk, Tav: Not that we know of.
Amelia: The main stumbling block for implementations in browsers, I think, was discrepancy between spec and shipped implementation in Chrome. Now that is sorted, we need to poke browser tracking issues again.
Dirk: So, first step is to merge
that PR to get the up-to-date spec.
... And then we can review status again before going to
proposed Rec
RESOLUTION: Keep `d` as geometry property in SVG 2, merging the amendments previously agreed upon after review
(discussion about difficulty implementing in Inkscape)
github: https://github.com/w3c/svgwg/issues/373
Dirk: As discussed in the issue, I think this probably can be deferred to a future spec.
Amelia: Issue is a new feature was added to HTMLImageElement, request was to harmonize.
Dirk: Question is, is there any harm in deferring? Would it be easier for implementations to harmonize sooner.
Eric: If no one has implemented it yet, we should defer it.
Amelia: Bigger issue is should we try to work with HTML working groups so that when these things get added, they get added to both elements at the same time?
Dirk: And that goes beyond the image elements. We've had the same issue with A element, for example.
Eric: But we wouldn't want to be holding up future work for HTML.
RESOLUTION: No new API features / attributes for SVGImageElement in SVG 2.0.
Proposed: Work with HTML standards on better coordination for paired elements that should have common functionality, e.g., through IDL mixins.
RESOLUTION: Work with HTML standards groups on better coordination for paired SVG/HTML elements that should have common functionality, e.g., through IDL mixins.
github-bot, end topic
<ericwilligers> github: https://github.com/w3c/svgwg/issues/574
github: https://github.com/w3c/svgwg/issues/574
Eric: What's the history of this property? Browsers support `auto` but it's not in the spec.
Amelia: I don't think SVG ever defined `auto`. But the property in general is under-spec'd. It's only defined for SVG, but it's supported for other elements in a way that isn't defined anywhere.
Dirk: I think it used to be in CSS UI. Should probably be there again. But we still need to define what `auto` means for SVG elements.
Eric: MDN is fairly clear that `auto` means `visiblePainted` for SVG elements. So the initial value doesn't change in practice.
RESOLUTION: Add `auto` as initial value for `pointer-events`, and define it to behave as `visiblePainted`
Eric: I can make those edits.
Amelia: We should also push the CSS WG to spec it separately, with definitions for non-SVG elements.
Eric: I can follow up after I've made the edits.
trackbot, end telcon
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/Sairus & Dean at Adobe/Myles & Dean at Apple/ FAILED: s/"Sairus & Dean at Adobe" should be: "Myles & Dean at Apple". I may have misspoken// Default Present: krit, AmeliaBR, Tavmjong, SairusPatel, ericwilligers Present: krit AmeliaBR Tavmjong SairusPatel ericwilligers Found ScribeNick: AmeliaBR Inferring Scribes: AmeliaBR Found Date: 05 Nov 2018 People with action items: 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]