<scribe> Scribe: AmeliaBR
Dirk: There have been a lot of PRs.
GitHub: https://github.com/w3c/svgwg/pull/500
Amelia: Is? this specific to just markers, or all the child-selector references?
Dirk: Probably applies to all. Is this something we want to keep in SVG 2, or move to 2.1?
Tav: I don't think anyone's implemented, and we're in no rush to.
Amelia: I agree, no prospects for
implementation in time for 2.0.
... Eric's PR looks like it's coordinating the markers bit with
other parts of the spec, so maybe merge that first, in both
branches, then a separate PR to delete from 2.0.
Dirk: There's also the
possibility (TabAtkins discussion) of having something in CSS
directly to do this, so they we wouldn't need to define it for
each SVG property.
... agree should merge & then delete from 2.0
Tav: Agreed.
Amelia: The CSS idea is interesting. Since we're deferring anyway, more time to see if anything happens there.
Proposed Resolution: Defer the <child-selector> option for markers, paint servers, etc. to SVG 2.1
RESOLUTION: Defer the <child-selector> option for markers, paint servers, etc. to SVG 2.1
Amelia: Dirk, Can you follow up on PR review, and then make an issue for the deferrment edits?
Dirk: Will do.
github-bot, end topic
Amelia: Any other PRs need discussing?
GitHub: https://github.com/w3c/svgwg/pull/398
Dirk: When reviewing, I found a statement that seemed to be missing relative to 1.1, not sure if that was intentional.
Tav: That looks like it should be there.
Dirk: Ok. Not sure if I should merge the PR & make a separate edit later, or...
Amelia: Might be nicer to merge it all at once. You might be able to edit' Eric's PR, or just suggest & wait for him to follow up.
github-bot, close topic
Amelia: Phillipe, did you join to say something or just listen in?
PLH: Mostly listen in, but also make sure you had feedback. I understand you've asked for 4-month extension, to after TPAC.
Amelia: That's what we asked, to give a chance to get the spec updated.
PLH: Would that be the spec, or also test suite & implementations?
Dirk: For sure we could do a republished CR, but I'm not sure of the full test suite.
PLH: What about the implementation?
Dirk: So, the plan is that we are removing things that don't have strong implementer commitments. It's possible there will be some implementations not done.
PLH: I think we want implementations, too, by TPAC.
Amelia: We're using the 2 existing implementations standard for cutting features, so we should probably meet that, if not full implementations.
PLH: And what about testing? Will that happen, to confirm implementations?
Tav: I'm trying to submit tests for things that are relevant to Inkscape, but doesn't cover all features for browsers.
PLH: We really need tests to be
able to confirm implementations.
... I don't want to ask the rest of admin for the extension,
and then in four months we're not where we said we would
be.
Dirk: I don't realistically think we can promise all the tests.
Amelia: The main block is not enough people to do the work. So maybe one thing you can do is talk with member org reps about whether they can find more personnel.
PLH: So far, Firefox has not
seemed very interested. Microsoft has been pulling back. Eric
is back from Google, so that's something.
... Do we know how much work it is?
Dirk: Amelia started an issue to list areas needing testing. Would that be helpful?
<plh> https://www.w3.org/TR/SVG2/changes.html
<krit> https://svgwg.org/svg2-draft/changes.html
Amelia: It's a start, but not
complete. We don't really have a good list of all changes that
were made that need implementaions, let alone which ones have
implementations.
... Where implementations exist, there should be tests in
browser's own test suites, but we haven't got any support from
them for importing into WPT.
PLH: What about the changes list in the spec?
Amelia: It's rather messy. My issues in GitHub were trying to summarize the net changes & which ones were normative.
PLH: OK, well, it would be helpful to have that final list of changes.
<liam> David's spreadsheet - https://onedrive.live.com/view.aspx?resid=FD9E7123283F274C!594647&ithint=file%2cxlsx&app=Excel&authkey=!AIguPi1fOc66FII
<liam> (some of the FALSE cells shoud be TRUE now though i think)
Liam: There was also a spreadsheet by David Storey of all DOM IDL changes & implementations status.
PLH: Ok, I will follow up, but I'm not sure if 4 months to TPAC is enough time for an extension.
Tav: One thing about extending to TPAC is that some work could happen there, in person.
PLH: At this point, we do want to extend the working group. The question is how long.
Dirk: Would it help to have multiple steps? A timeframe for the updated CR, then test suite and implementations. It's hard to estimate the whole project right now. Most of the time will be the test suite, but that depends on what is left in the spec.
PLH: The main issue right now, is
if the WG is out of charter, we cannot update the CR. So it
might help to have multiple-step extensions.
... I think I've got enough information to keep working at this
point. I will likely come back next week to give an update.
Dirk & all: Thanks Phillipe.
GitHub: https://github.com/w3c/svgwg/issues/456
Dirk: First question, is this new in SVG 2 or was it an extension from 1.1?
Amelia: It's new in SVG 2. And we've got a couple implementations, so it should stay.
Dirk: OK, then we need to clean
up these questions.
... question is whether it can return valid values in certain
conditions, like display: none
... Blink and Webkit always return false in these cases, and
there are implementation reasons that make it difficult to work
around.
... Geometry is defined by CSS properties, and those properties
aren't fully computed for a display: none element.
... likely to affect Firefox, too, when they implement CSS
properties.
Amelia: We don't want to spec
something that can't be implemented. But don't want to give up
without even looking into implementation options.
... I really don't like returning false in this case, though.
Better to throw an error if geometry can't be computed.
Dirk: One complication is that SVG 1.1 didn't have any exceptions for display: none, so wouldn't this be a breaking change?
Amelia: The isPointInFill/Stroke
methods weren't in 1.1, so that's not an issue. But it would be
an issue for getBBox, which has the same complications for
geometry and was in 1.1.
... but Firefox did have a bug with that (not returning valid
BBox values for non-rendered elements), so it may never have
been *fully* web compatible.
Dirk: Good point. Blink &
webkit used to have no problem with that, but now that they
support d etc in CSS, there are inherited problems in the
render tree.
... Multiple ways to address this:
... could say that the behavior is not defined
... could say to throw an error if shape cannot be computed,
leave it to implementations to decide when that case it
exists
... or we could explicitly define which cases a shape cannot be
computed.
Amelia: I like your second option. Clearly define an error behavior if the shape cannot be computed, but leave it undefined in this spec when that will occur. Wait for implementation feedback, see if we get a consistent pattern.
Dirk: By error behavior, you mean the method throws an error?
Amelia: Yes.
Dirk: Which error?
Amelia: I don't know. We'd need to review the error classes, see if one makes sense.
Dirk: OK, we can look into that later.
Amelia: One issue, if we wanted
to extend that behavior to getBBox, that would change the
definition of an existing method so that it can now throw
errors. That could be a compatibility issue.
... We could make a tentative resolution, but I'd like to get
feedback from implementer teams.
Dirk: I'm off the next few weeks,
but I'll try to run some tests in WebKit when I get back.
... Separate issue is, what if there is no fill or is no
stroke? That's also not defined.
Amelia: Did you test the current implementations?
Dirk: Neither Blink nor Webkit compute the stroke shape when stroke is none. For fill, Blink doesn't , WebKit does (but that can be changed easily).
Amelia: As I mentioned in spec, with pointer-events we can have pointer-sensitive stroke even if it is not painted. So the browsers need to do the calculations for hit testing, would expect the DOM method to work, too.
Dirk: I will try to look into what WebKit does in that case, and update the issue.
Amelia: Also hope to get other implementer feedback. Maybe @ewilligers can look into Blink.
github-bot, end topic
Liam: Thanks everyone, a reminder this is my last call.
Everyone: Thanks Liam!
<liam> (i'll be around on irc next Monday i expect but have a conflict)
trackbot, end telcon
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/Is/Amelia: Is?/ Succeeded: s/Dirk:/Amelia: Dirk, / Succeeded: s/AmeliaBR, Sorry, I don't understand that command. Try 'help'./Topic: Working Group Charter status/ Default Present: AmeliaBR, Tavmjong, liam, krit, stakagi, plh Present: AmeliaBR Tavmjong liam krit stakagi plh Found Scribe: AmeliaBR Inferring ScribeNick: AmeliaBR WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 23 Jul 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]