<myles_> uh oh, myles took my nick!
<myles_> ScribeNick: myles_
krit: We switch to biweekly. We made a poll to determine if a new time is better. There is a poll. No one from Google or Mozilla replied.
[waits for chris to re-join the call again]
krit: to chris: Are you only available on Monday?
chris: I have different
availability depending on the day.
... I'm in the USA.
krit: What about Wednesday at 3pm?
chris: yes
krit: It seems like that works
for everyone.
... Noon on wednesdays (in PST) is okay for everyone
... including Chris Little from BBC
So let's change the time of the call to that!
krit: Any objections?
... RESOLVED: Meeting times are on Wednesday at 20pm UTC
... Currently we use Boston time as reference
chris: This is easiest because the server is there
krit: We can leave it as Boston
time.
... No one is calling in from Australia any more.
RESOLUTION: Boston is the official SVG reference time
krit: AmeliaBR is not here, so we can skip her issues
<krit> ScribeNick: krit
GitHub: https://github.com/w3c/svgwg/issues/746
<nzimmermann> hi
krit: general description of SVG
Native.
... general description of the issue
chris: I prefer if we just talk
about a valid SVG Native document
... Therefore, require gradientUnits="useerSpaceOnUse"
myles_: every SVG Native document must be a valid SVG 1.1 document
<chris> with the same semantics
myles_: why do you prefer not to support objectBoundingBox, krit?
krit: it requires the bounding box of the shape... simple for rect and circle but complex for paths
AmeliaBR: rendering performance is not a big issue if we are not animating
myles_: performance matters for
fonts since there might be thousands
... So it could get a problem with hundreds of paths.
... what is the issue specifically? Getting the bounding box
itself?
krit: yes. If you have a bi-directional interface you can ask the rendering engine for the bounding box. Otherwise you'd need to calculate it yourself which is non-trivial
myles_: because you'd need to
rasterise and figure out the bounding box this way?
... If this is true, every gradient has to have this
attribute
AmeliaBR: there is always the user space transformations if you need it. Not pretty for authors but for export software it would be easy.
myles_: is it an issue for authoring tools?
krit: it should not be a problem for authoring tools to export obectBoundingBox as long as it supports it in the first place. Illustrator doesn't but maybe InkScape could.
myles_: So we are back to performance. In this case I agree with Chris and we should require the attribute
RESOLUTION: Gradients need to set gradientUnits="userSpaceOnUse" on gradient elements to be a valid SVG Native documents to keep compatibility with SVG Full.
GitHub: https://github.com/w3c/svgwg/issues/467
AmeliaBR: accidentally had Agenda+ last time.
<myles_> ScribeNick: myles_
<AmeliaBR> github: none
GitHub: https://github.com/w3c/svgwg/issues/744
AmeliaBR: This isn't actually an SVG issue. It's about the pointer events property and how it behaves on divs and iframes. That shouldn't be an SVG spec issue except for the fact that right now the only place the poitner events CSS property is normatively defined is in SVG. Even though all browsers support it on regular CSS boxes. I opened a CSS issue, but I'd like to to get a resolution from SVG to ask CSS to spec the pointer events property so they can
answer these kinds of questions
krit: CSS-ui spec used to have pointer-events defined, but was removed. Do you know why?
AmeliaBR: I think because there was no agreement on a stable spec.
chris: I think it was tantek who removed it. It was added for SVG but it was quietly dropped without notifying us. I'm trying to find the revision.
AmeliaBR: It was a ways back, and hasn't been brought back in.
krit: The request is to re-add it
to a CSS spec.
... This issue is something we can do with the SVG WG???
AmeliaBR: We could spec something
for divs and iframes, and in SVG we could talk about it in
<foreignObject> and make rules for foreign content in
SVG... and we could cover this case, but ....
... We're really not the best people to have this
discussion.
... I would probably tend to want to say "wontfix as an SVG
spec issue, but the SVG spec defers to a CSS spec about what to
do about divs and iframes" But right now we don't have that CSS
spec to defer to.
krit: We could add a note that a future CSS spec will define this
<chris> "Dropping features that were not implemented, or were insufficiently implemented to exit CR. "
<chris> https://www.w3.org/TR/2015/CR-css-ui-3-20150707/#changes
AmeliaBR: Adding a note sounds
like a good idea. LIke a warning to both developers and authors
and implementors that this property has an effect on non-SVG
content, which is not defined here and a future spec that
defines that might override the SVG-specific details. A note is
a good idea.
... Let me look up what we already have in the spec....
chris: I'm not finding anything since 2012 about pointer events in CSS
AmeliaBR: Maybe nobody has dared
touch it
... MDN just references the SVG spec. CSS index defers to the
SVG spec. It might never have been written up anywhere for the
general case
krit: We can resolve on 2 things: 1) Request the CSS WG takes over the pointer events property 2) add a note to the SVG spec saying this might be overridden by a future CSS spec
AmeliaBR: We have 1 paragraph about the content in <foreignObject> about hit testing, but no rules about pointer events values affect the foreign content
<chris> still not there, going back to 2004
RESOLUTION: Request the CSS WG takes over the pointer events property
AmeliaBR: I volunteer to discuss
this with CSSWG
... (but not to be an editor of the CSS spec)
<chris> https://bitsofco.de/theres-no-reason-to-use-pointer-events-for-html-elements/
<chris> "When used with non-SVG elements, only three values are available - inherit, auto and none."
nzimmermann: If I inteprret the current spec correctly, if the <foreignObject> is treated as a rectangular area, everyting is done by object boudnign box, and doesn't consider content below it (flattened like an image). If we have further spec about the descendents of the foreign object, does this replace the current text about flattening for hit testing?
AmeliaBR: That's what the second resolution would be. We would add a note about how this behaves for non-SVG content, but the CSS spec might change some of the details for SVG content.
<chris> (that page says "I don’t think there is a reason to use pointer-events for regular, interactive, HTML elements")
AmeliaBR: 2 things to decide. We would have to be okay accepting changes that another spec imposes on us
krit: (nzimmermann is from Igalia, joined SVGWG last week)
<chris> “The use of pointer-events in CSS for non-SVG elements is experimental. The feature used to be part of the CSS3 UI draft specification but, due to many open issues, has been postponed to CSS4.” — Mozilla MDN
<chris> https://css-tricks.com/almanac/properties/p/pointer-events/
RESOLUTION: Add a note to the SVG spec describing how behavior for pointer events will be defined in a yet-as-of-now unwritten CSS spec
<chris> https://caniuse.com/#feat=pointer-events
<chris> https://wiki.csswg.org/spec/css4-ui#pointer-events
RESOLUTION: Add a note to the SVG spec describing how behavior for the pointer-events property in foreign content will be defined in a yet-as-of-now unwritten CSS spec
chris: I found documentation of why it was removed
<chris> Moved from CSS3-UI editor's draft because it was the top source of issues for the 2nd CSS3-UI LCWD, and because it requires documenting previously undocumented web platform hit-testing model.
krit: <reads from history>
chris: they removed it because it was a big source of issues in CSS3-UI, and it requires previously undocumented web platform testing model.
AmeliaBR: We'll leave it to the CSS issue.
krit: Anything else?
chris: We chartered to try to
quickly pop out an SVG2
... Browser vendors aren't satisfied with that. They want the
same level of rigor as all other specs
... Doing SVG 2 is a huge job.
AmeliaBR: A lot of what we've been working on for the past year or more has been trying to mend little inconsistencies
chris: I would say it's more than
little inconsistencies
... The event model as well
krit: Are you askign about browser vendors wanting more detailed spec? What are you asking
chris: The process that was described to the AC is wildly insufficient. It's a huge job.
AmeliaBR: IF we talk about what
needed to happen with SVG 2 is just cutting back on implemented
features, vs what needs to happen is a lot of quality
improvements, then uh ...
... There are disagreements. This came up during the charter
time. That things were overly optimistic
krit: Where is your question headed?
chris: Rechartering.
AmeliaBR: timeline?
chris: We're supposed to be done already
AmeliaBR: Our charter is good until march 21. Within a year away. Our timeline within that charter was that January 2020 we'd have SVG 2 at recommendation status. That is where that's not happening.
krit: We had PLH calling in describing different models for new directions for W3C next year, including a live editing model for SVG. I don't think we can resolve on this today.
AmeliaBR: We agreed that either way we needed to get SVG cleaned up first, and then make a decision for what happens with SVG Next. It might be modular like CSS or a live standard like HTML.
krit: AFAIK the W3C did not resolve on this question. Therefore, we don't have pressure to make the decision quickly
chris: yes.
krit: Something that might be worth following up: An SVG editor. Chris: Can you follow up on that?
chris: yes.
krit: Thank you.
<krit> trackbot, end telcon
<krit> nzimmermann: next time type present+ and you'll be added
<chris> amelia btw have a look at https://webkit.org/specs/PointerEventsProperty.html
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: Tavmjong, krit, myles, chris, AmeliaBR Present: Tavmjong krit myles chris AmeliaBR nzimmermann Found ScribeNick: myles_ Found ScribeNick: krit Found ScribeNick: myles_ Inferring Scribes: myles_, krit Scribes: myles_, krit ScribeNicks: myles_, krit Found Date: 04 Nov 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]