<Tavmjong> Be there in a couple of minutes.
<AmeliaBR> Scribenick: AmeliaBR
Dirk: We're still waiting for the WG charter approval, but there is no reason not to go ahead with the CG.
<krit> https://www.w3.org/community/#support
Dirk: It would allow topics to
move ahead outside the WG.
... Chris started the initiative already (link above) it needs
5 supporters to be created.
Amelia: Do we have a clear scope description for the CG versus the WG?
Dirk: That needs to be sorted
out. First activity of a CG is usually to decide on a chair and
charter.
... If anyone wants to volunteer, let us know.
Sairus: I've marked support, but the W3C community website seems broken. Information and comment links aren't going anywhere.
Dirk: We should probably follow up with Chris.
Sairus: First activity of a CG is usually a charter. Is there already a draft charter?
Dirk: I don't think so.
... The CG could move forward with that. Although it might help
to have at least one task for the new group.
Amelia: First task could be to decide on priorities, including reviewing all stalled spec proposals from the WG.
Dirk: That could be a good start.
Tav: I'm a little skeptical about this process. Do we have any buy-in from the browsers to support the CG?
dino: I think the idea is that the CG provides a place for the community to discuss & feel like they are having input without first having to get the browsers on board prior to discussing the idea.
Tav: But if browsers aren't committed to implement, what's the point of discussing it?
dino: If people want to push ahead on work, they will have a place to do it, before moving to the WG with wider support.
Dirk: I think the idea is that the CG can gather support from developers and designers & gain traction for the idea.
dino: And it is easier to get involved without being a W3C member.
Tav: That's great. My worry is that the CG will end up doing its work on the side but get ignored.d
dino: and that's what's happened before with the WG. So it's better to have it clearly acknowledged in a CG, so that the WG focuses on things with support.
Tav: Ok. I do like the idea of reviewing existing proposals, and getting clear community support for which should be focused on.
Dirk: I think the new SVG Native spec would start in the CG.
Myles: I thought this was in the main charter?
Dirk: There's currently some objections to the charter & some back & forth, not sure if it will end up in the charter. We could start work in the CG.
Myles: Is there a process for transferring work to the WG when the charter is approved?
Amelia: There's an established process for a WG adopting a project from the CG. It could probably be adapted.
Myles: OK. I have no problem with working with a CG. Would this mean another weekly call, though?
Amelia: I think it would be more welcoming for a CG to focus on async online communication anyway.
Dirk: Async is probably good for now.
Myles: One other thing: The charter calls it SVG Core, we've been calling it SVG Native. Not sure if that matters.
Dirk: Could be a first task of the CG to decide.
<krit> ScribeNick: krit
GitHub: https://github.com/w3c/svgwg/issues/478
AmeliaBR: we had a discussion
about this back in October. Half of the issue was resolved. We
were lacking some data
... SVGAngle/SVGLength DOM properties and setting values with
units did not match what the spec describes
... pasting in previous resolution
<AmeliaBR> from October: * RESOLUTION: When setting `value` on an SVGLength or SVGAngle, the current unit type is preserved if the object has a defined conversion factor from the unit type to user units / implicit degrees.
AmeliaBR: this is consistent for
most browsers
... but what if there isn't a clear conversion factor?
... Edge tries figure out values: em-units is 16px if no
associated font is present
... what about newer CSS units with clearly defined px ratio
but have no representation in SVG DOM
... Lot of inconsistencies. Chrome has most useful: handling
things behind the scenes choosing the closest unit type
... but it fails in a couple of places
... we decided to add no more new enumeration values
... long term is to replace everything with cSS OM
krit: is it worth working out the details for legacy behaviour?
AmeliaBR: need to consider long
term ideal solutions. But we need to ask this question.
Especially if implementations are willing to change.
... For detached objects I am happy with sepcifying: throw
error when you can not figure out a conversion to user unit. I
think that should be easy to implement.
... For new CSS units, I think we should prefer get/set value
as string if the UA supports the value as string.
... For CSS property there is support for setting value as
string in the DOM object.,
... we should get a few more implementers looking at this and
give feedback how difficult it would be to update their
implementations.
... I can create a PR for review with a recommendation. We
wouldn't merge it yet but implementers have something to look
at.
krit: Are there issues for each implementation? Can we point to your PR then?
AmeliaBR: there is one for
Chrome.
... wanted to file issues once we have the text and decided
about a solution.
... I'd recommend the Chromium behavior with the one fix I
talked about with Frederik in the GitHub issue.
krit: What does Frederik think about the proposal?
AmeliaBR: That it would be an
easy change and I filed a bug.
... this includes the throwing behaviour described
before.
... other browsers on the call
myles: no comment
krit: objections?
Proposed RESOLUTION: Amelia write proposal as PR and gathers feedback from implementers. Idea is to follow Chromium with some fixes described in the issue
RESOLUTION: Amelia writes proposal as PR and gathers feedback from implementers. Idea is to follow Chromium with some fixes described in the issue
<AmeliaBR> 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/issue change/easy change/ Default Present: krit, AmeliaBR, stakagi, dino, Tavmjong, myles Present: krit AmeliaBR stakagi dino Tavmjong myles Found ScribeNick: AmeliaBR Found ScribeNick: krit Inferring Scribes: AmeliaBR, krit Scribes: AmeliaBR, krit ScribeNicks: AmeliaBR, krit Found Date: 11 Feb 2019 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]