WG Status

<scribe> scribe: Amelia

PLH: I've been talking with others, was an email thread on AB.
... what I'll propose to management, on Wednesday:
... although we don't know how long testing will take, we expect an updated spec by TPAC.
... So I'm going to recommend the extension, with the plan to work on a longer term charter during that time.
... Hopefully, as we work on cleaning up the spec, we will get a better idea of how much time it will take to get the test suite & implementations.

Dirk: If this is being discussed on Wed, when is a decision expected.

PLH: Not that soon. But I would not worry too much. You can keep working, all the resources are still there, for GitHub & calls & such. Only thing you can't do is republish right now.
... At this point, I don't think the idea of moving to a community group is on the table.

Dirk: Could you send an update after Wednesday's meeting, maybe to the internal mailing list.

PLH: Sure.
... I've been talking with Chris Lilley, also wondering how long an extension. After TPAC, but how long I don't know. Maybe a month. Depends on how much happens face-to-face at TPAC. Not sure how many people will be there.

Dirk: I'll be there.

Tav: I could be.

Amelia: Maybe, if I could find funding, but I haven't been looking into it.

PLH: Well, we should hopefully have a charter distributed before them. So in-person is not essential.

Tav: Benefit would be to actually get work done.

Dirk: We should have the spec updated by then. So the focus would be on planning the test suite.

PLH: We really need to keep track of progress. I hope by September you'll have a clearer idea of how much work you need to do, then you know what can happen by TPAC.
... from a process perspective, 4 months or 5 months doesn't make a difference. Might as well give the extra month to be sure.
... We know that any major process changes, like a Living Standard mode, won't happen by TPAC & therefore the next charter.
... So I'm going to ask for 5 months. If you get the spec & new charter ready before that, that's not a problem.
... There are some tooling issues that need to be fixed. The WebIDL code in the current spec is broken, our automatic tools wouldn't compile.

Dirk: If you have any pointers for the tests or validators, let us know.

PLH: I think it's just changes to WPT, that should be fixed when we update the new TR version.
... So I'd like to know, how soon can an updated TR be published.

Dirk: Depends on whether we want a new good CR, with all the issue fixes, or not.

PLH: Since it's already CR, you don't need to justify anything that hasn't changed, you only need to indicate the justification behind any changes.
... I could do a first pass on getting it ready for publication.

Dirk: That works for me.

PLH: OK. Just need official request for publication from the WG.

All: Sounds good.

PLH: Ok, I'll need to review the repo to figure out the build process. If need be, I can take the editor's draft & update headers manually.

RESOLUTION: Publish a new CR of SVG 2 as soon as possible.

PLH: I will keep in touch during August for updates on testing, as well.

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

Dirk: Doesn't look like any new comments to discuss.

Amelia: Tav did merge a few PRs, so thanks for that.
... I'm hoping to get to finishing the implementation review summaries this week.

Dirk: I'm off work this week & next, won't be doing anything but the calls.

Tav: I'm also on vacation, and won't be able to call in next week.

Amelia: Ok, why don't we skip next week (August 6). Next call will be August 13.

Dirk: any issues need discussing?

Amelia: There are some issues posted a few weeks ago by Firefox contributor Emilio, about use element & shadow DOM (502 & 504). If anyone has a chance to review, would be helpful.

https://github.com/w3c/svgwg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Needs+editing%22

The "Needs Editing" tag is another area for people to review. Some are more complicated than others, but a few of these are where we made decisions but haven't made the edits.

Enum values

Github: https://github.com/w3c/svgwg/issues/424

Dirk: We agreed to add new enums for things like marker orientation and blend modes, where we have new attribute values.
... But then a question was raised about things like SVGLength unit types, do we want to support the new CSS units.
... David commented that Edge does not have these, and I know that WebKit doesn't. I added a few hacks to work around that.
... So do we want to add things? CSS could add more units, hard to keep up.

Amelia: I think we should make sure there is clear behavior for units that don't have a reflected value.

Dirk: Agree, but the first question is should we try to extend the list.

Amelia: I don't think so. Too difficult to keep up with new units, and CSS Typed OM should eventually replace it anyway.

Proposed RESOLVED: Do not extend the SVG_LENGTHTYPE_* and SVG_ANGLETYPE_* constants & enumeration for new CSS units.

RESOLUTION: Do not extend the SVG_LENGTHTYPE_* and SVG_ANGLETYPE_* constants & enumeration for new CSS units.

Dirk: Can we add a link to CSS Typed OM in the spec?

<plh> --> https://www.w3.org/standards/history/css-typed-om-1 CSS Typed OM

Amelia: A note is easy. Won't automatically apply for all SVG attributes, but will apply for those that have been upgraded to CSS properties.

Dirk: Other attributes won't use CSS properties, anyway.

Amelia: Not necessarily. We sometimes use CSS syntax for attribute values that aren't CSS properties.

Dirk: Probably need to reconsider that. Not sure if browsers use them.

Amelia: Yes, last I checked browsers are very wonky about new units (and calc) in SVG attributes, including ones that *do* map to CSS properties.

Dirk: I'd prefer to have a clearer distinction between presentation attributes & parsing vs others.

Amelia: Either way, we still need guidelines on what to do with the legacy DOM interfaces when new units are used.

Dirk: Looking at the enum value, there is an "UNKNOWN" value, so that makes sense to use.

Amelia: Yes, but not sure how that affects the rest of the interface & math methods. Can we still convert it to the px value or other units?

Dirk: Need to check the existing spec & implementations. Probably make it able to convert to the simple number value, but not the rest.

Tav: If it's a lot of work to *not* update the list, would it be easier to just update it?

Dirk: Either way, with new units being proposed, we'd still need to define what happens.

Amelia: I do agree that the focus should be to keep it as simple as possible. Unknown unit, but still make the simple user-unit value still returns a valid number.
... Either way, should be a separate issue to discuss the details.

Proposed: If a length/angle was declared using a unit not in the enum, it should be exposed as type UNKNOWN.

RESOLUTION: If a length/angle was declared using a unit not in the enum, it should be exposed as type UNKNOWN.

<plh> Next meeting is August 13

github-bot, end topic

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)

Default Present: AmeliaBR, krit, Tavmjong, plh
Present: AmeliaBR krit Tavmjong plh
No ScribeNick specified.  Guessing ScribeNick: AmeliaBR
Found Scribe: Amelia

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

Found Date: 30 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.)