<krit__> chair+

<scribe> scribe: AmeliaBR

krit: Any agenda items?

Amelia: Remember it's CSS F2F next week. If you have anything they need to look at, make sure it gets on agenda.

New proposals & SVG community group

krit: We got many new issues with new proposals for SVG additions. How do we want to handle this & where?

Tav: And are we allowed to handle them.
... … we can use github as a place for discussion, but not sure our charter allows us to act on them.

krit: Our charter is not as restrictive as it was. We can create new specs. But it's supposed to be low priority & the community group is supposed to be the venue.
... and then pull in when they're more formed.

Tav: has anything got to that state.

Amelia: No, not much happening at CG.

Tav: So, should we direct people from our issues to the CG? Seems like pointing them to a black hole.

Amelia: More people discussing things there could help. But it really needs a moderator / some guidance & I haven't had time to do that.

krit: I agree. Needs someone with time to help & coordinate.

Tav: I don't see that happening when we have a hard enough time getting participation here.

krit: So, what should we do about the issues in our tracker?

Amelia: At least consistently tag them, “New proposal” or something. Maybe comment to let the poster know that CG is available if they want to work on it further.

krit: Is there any best practice from other groups? Although, still doesn't help if we don't have resources.
... should at least do the tagging.
... Would help to have documentation about how best to make a proposal.

Amelia: The CG charter has a bit about what makes a good proposal, but it's very high-level.

krit: That's a start. We can always wait & respond to questions. Learn together as a community.
... I probably won't have time until Feb. If someone else can do some of the issue tagging & info text that would help.

Amelia: I can do the tags & leave a generic comment about the CG on each.

Support pathLength via CSS

github: https://github.com/w3c/svgwg/issues/773

<krit__> ScribeNick: AmeliaBR

Amelia: Been some blogs & twitter discussion about how pathLength is helpful for stroke effects. But that raised question of why it needs to be an attribute when stroke styles AND geometry are now in CSS.
... proposal is to make a path-length geometry property.
... I think it's a good idea. But not sure about adding it to SVG 2. No implementations yet. Is it a priority?

krit: Looks some interest from at least one implementer.

Amelia: Yes, fsoder said he could do the work in Blink. But needs others.

nzimmermann: WebKit doesn't yet do anything with the attribute. It just parses it, doesn't affect rendering. So that still needs to happen. But adding it as a CSS property doesn't seem to make it any more complicated.

Amelia: And might even be easier to do both changes at the same time?

Tav: We (Inkscape) don't appear to implement it (for stroke dashing). But for us, properties and attributes are treated very similarly. Wouldn't make much extra work.

Amelia: So it sounds like first step is get some tests of what pathLength (as attribute) is supposed to do, re stroke dashing and such.
... Then we can get some feedback on how hard it is to implement.
... The benefit of adding to CSS depends on it actually affecting rendering!

krit: There is one test. It uses animations.

Amelia: That was the only part explicit in SVG 1. Stroking effect wasn't well defined; that was added in SVG 2.

nzimmermann: One concern is that anything to do with pathLength is very complicated. In WebKit, this is all in the platform-specific underlying code. You tell the backend the path & the stroke pattern.

krit: What you'd need to add is scaling of the stroke pattern.

nzimmermann: Yes, but then you need to ask the backend to calculate a path length. Which isn't trivial.

Amelia: I mean, the purpose of pathLength was to adjust for these underlying differences in path length calculation. But then you do need some back-and-forth between the two code levels.

krit: Original intention was specifically for things like textPath and animation where it is really important to be consistent.

nzimmermann: And for those cases, we already calculate path length on our own, so it's easier to scale. But with stroking we defer to the backend.
... I'm not sure it's technically possible to get the exact length the underlying code is using for the stroking.

Tav: Is that a big difference?

krit: Maybe, but point is to get rid of that difference, so we need to know it.

Tav: But other use case is just ease for author. To explicitly set length of 100 and then work with that, without having to measure anything.

[more discussions on underlying libraries]

krit: So first thing is to write tests to know if it is implemented at all.

Amelia: Or, implemented consistently in the details.

Tav: And performantly.

krit: We also need buy-in from CSS working group, since this would be a new property.
... let's ask TabAtkins to bring it up at CSS WG F2F
... And for the performance criteria, does that really affect whether it should be in CSS? Or whether it should be there at all?

Amelia: It's not related to CSS. It's whether pathLength should affect stroking that is performance issue.
... but if we take that out, not much point to add to CSS.
... Beyond that, only question is can anyone write up some tests?

krit: And writing good tests, considering the subtle differences between implementations.

Amelia: I don't think we need to specifically test *for* those differences. But need to be careful they're not ruining results with pixel differences.

Tav: I can try to write some up.

Clarify that non-CSS rendering environments can override default width/height of embedded SVG

github: https://github.com/w3c/svgwg/issues/762

krit: As I understand it, this is mostly about HTML canvas?

Amelia: Yes. And it's more complicated than I originally thought when I created the issue. But we have a discrepancy between Firefox and Chromium. When drawing an SVG image to a canvas, Firefox uses viewBox and prefersAspectRatio. Chrome draws it at default sizes than uses bitmap scaling.

krit: Do we have an example?

Amelia: Not yet, unless it's in the linked browser bug.

krit: So, we have different situations depending on what parameters go into the drawImage() function. Probably need some examples to consider them all.

Amelia: Sounds good. I stand by my original concern about unintentional changes between SVG 1 and SVG 2, but the canvas issue is more complex.

krit: Are there tests for that changed text in the spec?

Amelia: Not sure how. It's about SVG embedding in non-CSS contexts.

krit: Maybe we should then split it into two issues. One for the editorial changes, one specific to canvas.

Amelia: Maybe wait until we have a clearer understanding of the canvas issue, then file it on HTML spec.

krit: So, needs more tests.

Remove the 'timelinebegin' attribute

github: https://github.com/w3c/svgwg/issues/749

Amelia: This is a follow-up to the issue about discard element. Other attributes were added at the same time.
... But I thought our decision re discard was to leave the spec as-is for now.

krit: yes, our resolution for 717 was to ask Blink for more feedback. Which fsoder gave. But we need to make that decision before changing anything else.
... For now, we could add an issue into the spec that this is experimental.

Amelia: Makes sense. The stand-alone Animations spec has never been properly published, although we've resolved to. Adding issues, marking unimplemented parts as at-risk, would be a good step before FPWD.

krit: Don't need formally at risk at this point. But should have a warning for people reading the spec.

Amelia: So strategy would be to add warning about unimplemented parts & then follow up with publication.

krit: Not warning, but issue. It's still being discussed.

Amelia: OK, who could do this?

krit: Not in next 2 weeks, but you could assign to me.
... add issues for discard element and the 2 new attributes.

RESOLUTION: Add issues to SVG Animations spec re discard element and the 2 new attributes, asking for implementation feedback.

github-bot, end topic

krit: Please add agenda items for next meeting!

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)

Default Present: AmeliaBR, krit__, Tavmjong, nzimmermann, stakagi
Present: AmeliaBR krit__ Tavmjong nzimmermann stakagi
Found Scribe: AmeliaBR
Inferring ScribeNick: AmeliaBR
Found ScribeNick: AmeliaBR

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 15 Jan 2020
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.)