<myles> hello
<scribe> scribenick: AmeliaBR
<myles> let me try a different coputer
krit: Let's get started & hope the connection issues will sort out
GitHub: https://github.com/w3c/fxtf-drafts/issues/245
Dirk: Question is what happens
when `display: none` on the <mask> or <clipPath>
element itself.
... I uploaded some test results
... most browers disable the effect (as if you didn't specify a
clip-path). But there are discrepancies when the effect is on
HTML elements.
... (for browsers/effects which are supported on HTML element,
`display: none` is treated as if the mask was full transparent
/ clipPath was empty. So the element with the effect
disappears.
... Not sure what to do with that, but for SVG effects on SVG
elements, it looks like we have consistency.
... I'd recommend standardizing that: if clip-path or mask
property references an element with `display: none`, treat it
the same as if it referenced a non-existant element, so no
effect.
Chris: Does this only apply if
`display: none` is directly set on the element itself, or does
it also imply by inheritance, e.g., from `<defs
display="none">`.
... Because a defs is general defined as the same as display:
none.
<krit> https://codepen.io/anon/pen/eomKyj
Amelia: And it also depends on the spec text. Assuming the SVG 1 spec was implemented (display: none has no effect), we rewrote it to define these elements as having a `display: none !important` user agent style so it could be defined with CSS. But that doesn't work if display: none actually has an effect.
<krit> https://codepen.io/anon/pen/qwEKpG
Dirk: After a quick test, it looks like an explicit `display: none` on the defs element does disable the child masks / clipPaths, in Blink and WebKit.
Amelia: Since we have consistency between browsers, there may be content depending on it, we should change the spec to match. But we need to figure out what that is, and how to define it clearly. And whether it applies to other elements, e.g., filter effects.
Dirk: Yes, so we need to do some comparison, e.g., for the defs issue. But I think we should focus on masks / clipPath for now.
Amelia: The same text about display not having an effect is used in many parts of the spec. If we're going to rewrite it, we need to figure out how much need to edit.
Dirk: Can we agree on the `display: none` for the mask and clipPath element?
Amelia: I think we need to do more testing first. Go through all the elements in SVG that have the same rules.
Dirk: But these aren't in the SVG spec anymore, they're in CSS Masking.
Amelia: Are you in a rush to republish?
Dirk: No, but we don't want edits on one spec to wait for the other.
Amelia: But we do want to make sure that the final edits are consistent.
Dirk: OK, so you want to get data for all SVG effects, like gradients and patterns and so on?
Amelia: Yep. Should probably open a dedicated issue on the SVG repo. And filter effects, too.
Dirk: There's already one on
Filters (https://github.com/w3c/fxtf-drafts/issues/130)
... it's also on the agenda, but I guess we should also defer
until we get full data.
github: https://github.com/w3c/fxtf-drafts/issues/197
Amelia: I raised the issue because I thought it was a minor typo. But after testing, it looks like most browsers don't really use `clip` on SVG elements at all. So question is whether spec should match.
Dirk: Yes, Firefox does support `clip` but inconsistently. And `clip` is deprecated in CSS anyway.
Amelia: We do need to keep support for clip on SVG elements with CSS boxes. But beyond that, unless anyone knows of other software that uses `clip`, we should probably indicate that it isn't supported.
Dirk: Tav, does Inkscape support it?
Tav: I think we'll apply it.
Dirk: But you wouldn't mind removing it?
Tav: No, I don't think that would be a problem.
Dirk: And I don't think any Adobe
software relies on it.
... For the edits, how do we handle the bit about CSS layout
boxes.
Amelia: There's already an "applies to" that restricts it according to CSS positioning. So that's probably good enough. Just delete the extra sentence about SVG.
RESOLUTION: Remove special `clip` applies-to rules for SVG elements.
github: https://github.com/w3c/fxtf-drafts/issues/17
Dirk: As background, clipPath
currently only allows shapes, text, or use elements that
directly reference shape or text.
... Proposal is to allow the <g> element and possibly
other elements.
... Given that CSS Masking is in CR & there are no
implementations, I want to resolve that we're not changing this
for Level 1. But we could do it in Level 2.
Chris: That makes sense.
Dirk: Any objections to moving to Level 2?
Amelia: No, it's new functionality, should go in the next spec.
Dirk: OK, I have no problem with the idea for Level 2. But we need to figure out the details.
Chris: I think those details may be why it wasn't allowed in the first place.
Dirk: Any other comments?
Amelia: Worth mentioning that is much-requested feature from authors. Current restrictions can make re-using content difficult.
RESOLUTION: Expand the clipPath content model in CSS Masking Level 2; no change for Level 1. Exact details to be determined.
github-bot, end topic
Dirk: Any other updates?
... Ok, please add other agenda items for next week's
call.
<myles> we're still doing a review of the SVG Native spec internally. I'll have it by the next call
<myles> i can hear you but webex wouldn't let me talk.
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/using it/removing it/ Succeeded: s/RESOLVE/RESOLVED/ Succeeded: s/Great, thanks// Succeeded: s/scribenick: Amelia/scribenick: AmeliaBR/ Default Present: myles, AmeliaBR, stakagi, krit, Tav, chris Present: myles AmeliaBR stakagi krit Tav chris Found ScribeNick: AmeliaBR Inferring Scribes: AmeliaBR Found Date: 01 Apr 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]