<scribe> scribenick: AmeliaBR
Dirk: There's a new Community
Group on positive work environment; used to be members-only,
now trying to be more open. Also, part of general move by W3C
to make sure people are supported.
... For our Working Group, I talked with W3C & various AC
reps. Everyone still wants SVG WG to go forward.
... but from W3C side, there is still strong push to get a
PR-ready spec by end of November.
... For a Charter renewal, there was interest from elsewhere in
Adobe & others that we get a clear W3C spec for the SVG
that is covered by SVG-in-OpenType fonts. This is mostly a
subset of SVG 1.1.
Amelia: There are also some new features that are used in SVG in OpenType, like the context keywords.
Dirk: That's true. There is a lot
that needs to be specified more clearly. But also, the idea is
that this new spec wouldn't be *just* for glyphs, but a
standardized subset of SVG for various applications.
... For the main spec, I think the interest is *not* to do an
SVG 2.1, but to use SVG 2.0 as a basis and then pursue new
features in modules, not a monolithic spec.
... There was a request from Microsoft to have a few additions
to SVG 2, they hope to make proposals soon.
Amelia: Changes for the 2.0 spec, or new features?
Dirk: New features for
modules.
... It also sounds like we might get some new editors. There
was suggestions from Microsoft that they will assign people
again. Not sure if it will be David Storey or someone
new.
... There was also process updates. A new system where you
could ask for a re-publication with a GitHub issue or PR
instead of emails to staff contact. Haven't looked at the
differences carefully..
Tav: What are the new features Microsoft is proposing?
Dirk: One was something like
non-scaling-stroke, but scaling with maximum and minimum.
... also non-scaling pattern fills, and something about
gradient types
... he was going to send a proposal.
... One thing to discuss is whether we want new proposals to go
to a community group or WICG, or keep it in the main
group.
... There are 4 different SVG-related community groups, but
none of them are very active right now.
Tav: Splitting things up can kill momentum if there aren't enough people.
Dirk: Yes. But there are a number
of different approaches being used by other groups. Probably
best to wait until we get new WG members.
... Any concerns about leaving SVG 2.0 as the last monolithic
spec & doing future work in modules?
Amelia: That was what I hoped would happen.
Dirk: So I thought, but we will need to clarify as we write the new charter, which I'll be working on with Chris.
https://github.com/w3c/webcomponents/issues/179#issuecomment-433401067
Amelia: Based on the comment in the issue, there was a "rough consensus" to match the Chrome/Firefox behavior (so SVG cross-references work inside shadow DOM), but there are still details to work out.
Dirk: And the decision was to
treat links differently than other cross-references, so they
could still link out to the rest of the page.
... But also not clear which spec this should be in.
... Not sure what needs to change in our spec. There was a
discussion of having xlink:href behave differently from href,
but others disagreed with that.
Amelia: I will be keeping an eye
on the issue. I don't think we'll need to change much in SVG
2.0 core
... If the behavior they decide on isn't backwards compatible
with use-element shadow DOM, then use-elements will just have
special behavior. So all we need is to keep defining what use
elements should do.
Github: https://github.com/w3c/svgwg/issues/504
Dirk: Amelia & I discussed
this with Emilio (who posted the issue) over IRC last
week.
... So, the nature of shadow trees is that style selectors from
the main document don't match into the shadow tree. In SVG 2
currently, we say to copy the CSS rules into the shadow tree
& then match again. But some rules wouldn't match, because
the shadow tree is only part of the original tree.
... This allows the approach to be more consistent with the
rest of the web platform, but it doesn't match
Edge/Chrome/Safari current behavior. From discussion, Microsoft
in particular was against any change that wasn't backwards
compatible.
... So maybe we can work with people to find a solution that is
both consistent with web components and also backwards
compatible.
https://svgwg.org/svg2-draft/images/struct/Use-changed-styles.svg
<krit> https://svgwg.org/svg2-draft/struct.html#UseStyleInheritance
That's the example from the spec of a rule that would change between the old or new rules.
Amelia: One thing that has
changed since the SVG 2 text was written is we decided to make
the use shadow trees closed to author scripts. This gives us
room for a little extra magic that can't be defined by regular
shadow DOM.
... The SVG 1 version of cloning the cascaded styles has its
own problems. But the break comes specifically from selector
matching. So maybe what we need is a little bit of "magic"
rules for how selectors match in use-element shadow
trees.
... so if a path element was cloned from somewhere it was a
child of a g, then `g > path` would match the shadow path,
even though there is no shadow `g`.
... but interactive selectors like `:hover` would still be
assessed on that particular shadow element, not on the
original.
Dirk: Is this possible to implement cleanly?
Amelia: It would need special code, but anything that is backwards compatible would need special code, because its unique behavior.
Dirk: Ok. But I think we need a discussion with CSS & web components folks.
Github: https://github.com/w3c/svgwg/issues/563
Dirk: I made a PR, Amelia has already reviewed. I initially was wondering whether these should stay as graphical elements, but since there is no support I just removed them completely.
Tav: Removing completely? Oh, for direct reference only. But they would still work in foreignObject.
Dirk: yes
... No implementations and limited interest. The PR also covers
SVGUnknownElement. I'm not even sure if there's agreement
whether that's a good idea. It could also require changes in
the HTML parser.
Tav: No problem with the removal.
Amelia: For the media elements,
the main interest was from non-browser software, to be able to
use multimedia without a full HTML+CSS implementation. But that
means less likelihood that browsers will move forward to
implement.
... So deferring makes sense for now.
... For SVGUnknownElement, that's a bit of a breaking change.
Not sure if just deferring will fix anything. Maybe just accept
to remove.
Dirk: Well, we can decide the future later. But do we agree to remove from 2.0?
Tav: Yes.
Amelia: Yes
<gsnedders> Yes.
Amelia: I had specific questions on the PR, making sure we don't accidentally remove other text, but support for the general idea.
github: https://github.com/w3c/svgwg/issues/525
Dirk: The spec has some
inconsistencies, about whether x/y/width/height are geometry
properties on symbol and use.
... there are also pattern and mask.
Amelia: Inconsistency was my
fault; changed the definitions for symbol/use & didn't
catch the other places that should be updated.
... Can't remember all the discussion that went in to the
change, but I think main argument was that it was useful for
authors & there was no real reason not to allow it.
... But, problem is that that change happened after the Blink
& WebKit implementations of geometry properties shipped,
and I don't think anyone has updated it since, so we don't have
our two implementations for Proposed Rec status.
... Now, as Dirk mentions, there are other elements with these
attributes where we weren't yet ready to call them CSS
properties, but hope to in the future. So if we roll the spec
back, its not to say that it won't happen in the future.
Dirk: So, the question is what do we include in SVG 2?
Amelia: I think we need some tests. Confirm what is/isn't supported yet. Maybe ask if any implementations are in process.
Dirk: Agreed. Then we can follow up with discussion on the issue & bring it back to the WG with more data.
Dirk: North America switches back to Standard time next week.
Amelia: It might be best to do an email poll, where everyone can see it in their own time zone.
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/Topics: Web components & SVG/Topic: Web components & SVG/ Default Present: AmeliaBR, Tav, krit Present: AmeliaBR Tav krit Found ScribeNick: AmeliaBR Inferring Scribes: AmeliaBR Found Date: 29 Oct 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]
