<krit> scribe: myles

<scribe> ScribeNick: myles

"Sizing properties" section should mention the "use" element

<krit> me https://github.com/w3c/svgwg/issues/607

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

AmeliaBR: This one is my fault. I did the edits to one section on the <use> element and didn't do the edits to the other section about the actual property, saying they apply to the <use> element. That's how we ended up with the inconsistency. Backstory: Originally, when width and height were added as CSS properties to replace the SVG attributes, it was only a limited number of elements it applied, and <use> wasn't on the list. So it wasn't in the first batch

of implementation in chromium and webkit. The reason it was added in later had to do with some testing. Because of the way things were defined with symbol, width and height were getting used on <symbol> even though they weren't defined to, so we decided to add in the attributes on <symbol> and in the discussion we asked if there's no reason not to allow them as properties

AmeliaBR: But, it's a case of: I don't think anyone has followed up at this point.
... so width and height on <use> would only be attributes. Benefit: Gets away from the extra confusion about how width and height on <use> and how they apply to the re-used element in the shadow dom. So we wouldn't have to deal with describing that in CSS. Opinions?

krit: You're right that width and height propagation to shadow dom is something that needs more description. As the reporter noted, there aren't implementatiosn that would allow the widht and height properties on <use>. Should we defer the presentation attributes on the <use> attribute?

AmeliaBR: ... Based on the test, even for nested <svg> and some other elements, we don't have two implementations.
... either way, even if we roll back this specific behavior with <use>, we still need to put pressure on implementations to add it on the other elements. Maybe it's worth having that discussion to see if it will happen.

ericwilligers: I think the properties are important for animation.

AmeliaBR: Yes. CSS animations of size, they need to be CSS properties.

ericwilligers: Can we defer? i will look at it.

AmeliaBR: sounds good.
... Myles, please follow up and see on WebKit if there are trakcing issues

myles: ok

krit: Is specifically about <image> <foreignObject> <use> or what?
... We have <image> and <foreignObject> implemented in blink.

AmeliaBR: Nested SVG isn't working even in Chrome.

krit: mhm.
... For those that dont' have any implementations, would they be at risk? It would jsut be nested <svg>, right? It's a bit tricky.

AmeliaBR: an SVG element that is SVG layout, as opposed to the outer SVG element which uses CSS layout anyways.

krit: We would need to specificy it more specifically. SVG elements in some contexts would be one way ... it's a little bit weird.
... We should open issues on different implemetnations. The question comes up with <use>, and ericwilligers asked to defer, I'm fine with that. For <image> and <foreignObject>, should we mark "at-risk" or just leave it?

AmeliaBR: Let's make the decision when we get to the topic again.

krit: Let's move on.
... if there is implementor interest and a timeline or priority....

Mark 4 text properties at risk

AmeliaBR: these are text properties that are a mixed bag of properties. Two are about shape, two are about text decorations.

krit: Let's discuss with shape-inside and shape-subtract.

AmeliaBR: We already agreed that anything to do with wrapping text will be at-risk?

krit: it might make sense to make a resolution to put shape-inside and shape-subtract at-risk.

AmeliaBR: That's part of the previous decision. They should be at-risk.

RESOLUTION: Put shape-inside and shape-subtract at risk.

krit: Next two properties: text-decoration-fill and text-decoration-stroke. Why did we add them?

<AmeliaBR> https://github.com/w3c/svgwg/issues/610#issuecomment-445965272

AmeliaBR: They are added to be equivalent to be text-decoration-color which is in regular CSS. SVG text doesn't use color, it uses fill and stroke, so we need some way to explain it. I commented on this issue ^^^ I think it's appropriate to defer them. They are still being discussed as part of the fill and stroke spec. Even if we defer them we still need some text somewhere that explains how to use text-decoration-color in SVG. Does it override fill and

stroke? Does it work together?

krit: Fill and stroke spec was created to fill and stroke in HTML. Why do we have separate text-decoration-fill and text-decoration-stroke at all?

AmeliaBR: It's for styling the underline separately from the text it's attached to.
... the fill and stroke spec will take over this issue by making it a universal issue, not svg issue.
... until that spec is stable, we still have browsers that are shipping text-decoration-color, i don't know whether we have consistent behavior in browsers about whether or not it affects SVG text.

Tavmjong:

tav

tab?

Tavmjong: Do we have any implementations?
... inkscape supports color.
... do any browsers support text-decoration-color in SVG?

myles: I think we do but I haven't checked

AmeliaBR: it doesn't work in Chrome

krit: the text-decoration-color property is part of CSS Text Decoration module. Shouldn't we move this issue there?
... We should move it there. Many other modules have SVG-specific text.

Tavmjong: I'm reluctant to agree with you because we don't have representation there.

krit: Yes, but everyone is free to contribute or participate on those specifications.

myles: ::mumble mumble mumble::

krit: The CSS WG should decide.
... If we have any text describing text decoration color in SVG, can we move it to the text decoration module in CSS?

<AmeliaBR> https://svgwg.org/svg2-draft/text.html#TextDecorationProperties

AmeliaBR: Yes, we have a whole section about it, to try to describe how it should interact.
... it's a big wall of text. I don't know how much would persist.

myles: this isn't an SVG problem, it shouldn't go in SVG

AmeliaBR: <missed>

krit: Let's move the text out of SVG

AmeliaBR: Who wants to actually do the work?
... this is about text decoration and new properties, so someone will have to go through the specs to figure out what the changes should be

krit: Someone should do it with fantasai, she will know what to do.
... I can take an action if no one else wants to

Tavmjong: It's been 4 years since CSS said they were going to fix this. We should push them

krit: It's well defined in CSS but we need to mention SVG. Is there agreement that it should go into CSS?
... SVG-specific text decoration color definition should move to a CSS module. Follow up with CSSWG.

Tavmjong: We don't define text decoration color already.

AmeliaBR: Because we don't use it, we use these new ones.
... It might be as simple as saying that text decoration color does not directly apply to SVG text.
... And then teh fill and stroke module can define which properties work instead

krit: It's up to the CSSWG about where it should go.
... Both fill and stroke and this spec are part of CSSWG. We can give guidance.

AmeliaBR: Text-decoration module is candidate rec, so they'll not want to make too many changes.

krit: It's up to the CSSWG.
... objections?

RESOLUTION: SVG-specific text decoration color definition should move to a CSS module. Follow up with CSSWG.

krit: Let's talk about text-decoration-fill and text-decoration-stroke. Should we do the same?

RESOLUTION: Remove text-decoration-fill and text-decoration-stroke from SVG. Suggest to CSSWG to move their definitions to CSS fill and stroke or CSS text decoration

how should display:contents affect SVG conditional processing attributes?

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

AmeliaBR: I haven't looked at this issue.
... it shouldn't. The SVG attribute should happen first before any CSS, but...
... The processing attributes are all defined to happen even if something is display:none. They exist on their own level. I don't think we should try to complicate things by having it interact with display:contents.

krit: What about inline SVG? We have to define how svg contetns define display content

AmeliaBR: That's already defined at the basic level. If something is hidden because of conditional processing, then adding display:contents on it won't change anything. If it's displayed, then okay, it's displayed but now you're doing whatever we arleady defined display:contents to do on that element. The only thing that's not defined is if you put display:contents directly on a <switch>

krit: <reads spec>
... doesn't that mean that no matter which SVG we have in the document, it will always have display:none on the root and therefore not get displayed?

AmeliaBR: Yes, but i don't know how that affects conditional processing
... SVG already defines, conditional processing says, of these 3 children, this is the one that gets displayed, but that child has display:none, then nothing gets display:none. So the same thing would happen if we're display:contents'ing that child. It's two separate sets of processing, and if the net result is nothing gets displayed, then nothing gets displayed.

krit: Sounds reasonable to me.
... Why not just take the next node or whatever?
... hrm.

AmeliaBR: Anything else would be adding a lot of complication for something that is hardly ever going to come up.

krit: Do we think there's anything on SVG's side that we need to resolve?

AmeliaBR: probably not. Possibly a clarification to the conditional processing bit where it says "not affected by display:none" we could chagne it to say "not affected by display:none or display:contents"

krit: Does that need to go into SVG or into CSS Display?
... We can follow up.
... Let's wait for the feedback that we get from heycam and fantasai

AmeliaBR: I found the relevant statement in SVG. "Note that the values of display have no effect on <switch>" that's all-inclusive and we don't need to change anythign.

<AmeliaBR> "Note that the values of properties display and visibility have no effect on ‘switch’ element processing."

krit: So we don't need a resolution.

'image' element not defined to fire 'load' event when load happens

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

krit: David worked on this before.
... Ideally, this should just reference HTML stuff. The question is, "fire a load event" is not specified at all. But I'm pretty sure this is supported in WebKit.
... Don't we need to at least say that the load event should fire or must fire when the image is loaded, and reference HTML to describe how that happens?

AmeliaBR: SVG 1 had its own special load event, which fired on every element in its subtree, so there wasn't a need for a special description about image. We removed that and replaced it with the general DOM load events, and maybe when those changes happened, people didn't realize that extra text was needed about specific elements. Generally I support the idea of being consistent with HTML image behavior and referencing the HTML spec as much as possible

krit: Let's make a resolution: Fire the load event when the image was loaded, and reference the HTML specificaiton.

AmeliaBR: Has someone done testing on whether browsers do it already?

krit: There is no test on the issue yet.
... But you're right we should test.
... Who can do testing?
... ericwilligers, can you do it?

ericwilligers: <silence>
... no.

krit: I can do it.
... maybe next year.

AmeliaBR: Do we want to make a conditional resolution to add spec text if there is interop?

krit: let's wait for the testing.

AmeliaBR: We'll come back to the issue once we have data.

Resolved value for the 'width' and 'height' geometry properties

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

AmeliaBR: This has to do with what you get back from getComputedStyle().
... In general, for CSS width and height, if you do getComputedStyle() and the element's width and height actually apply to it, then percentages and keywords get converted to final px values. But if you do it on an element where width and height dont' have meaning, then you get the partially-simplified version, because there is nothing that can convert percentages. The people who implemented width and height on svg <rect> didn't change how

getCOmputedStyle() works on these, so I think as far as spec changes, as soon as we say that width and height to <rect> and <image> then based on the rules in CSS, getComputedStyle() should convert everything to final absolute values. But its' a case on needing to follow up on implementations.,

AmeliaBR: And the rest of the comments in the issue are what happens on what stage in the CSS process for different properties.

krit: when you look at CSSOM, it doesn't seem to differ between objects which make meaning of width and height and which don't. It just has special case for display:none.

AmeliaBR: The question is if the resolved value only exists if the element applies

krit: Like if you have a circle with width=%, what does getComputedStyle() return?

AmeliaBR: On a circle, width doesn't apply, so you get back what you specified. But if it was a <rect> then you get px

ericwilligers: Can't we just preserve percentages?

<AmeliaBR> https://drafts.csswg.org/cssom-1/#resolved-value

AmeliaBR: It depends on the property and whether or not the percentage can be resolved. It's illogical legacy in CSS but hey that's what we have
... For margin, padding, height, width, if the property applies to the element or the pseudo element, and it's being displayed, you have to resolve down to the used value, which is px.

krit: Then it says "otherwise"
... So for the circle, all those apply

AmeliaBR: Width doesn't apply to a circle.
... We have to be consistent with weird legacy rules.
... Width and height are already in CSS, so they already have these legacy rules. What about the other SVG geometry properties where we don't have a legacy issue that we have to treat them this way but do we want to treat them this way anyway so they're consistent with width and height?

krit: So usually it's the used value or the computed value?
... which one is which?

AmeliaBR: the resolved value, which is the return of getComputedStyle(), is a special case, it would return the used value if the property applies to the element. So if you getComputedStyle of "R" on a circle, if we opted in to these rules, it would convert percentages to px.

krit: Are there properties that take a width percentage which have been added after CSS2 which are different from width and height

AmeliaBR: The logical properties. Inline-size, block-size margin-end
... in those properties, it was decided to keep consistent

krit: So we would have to do something about resolved value of the computed style, how it serializes to a computed style, for x, y, cx, cy, rx, ry

AmeliaBR: we don't have to write a lot of extra spec text. We have to say the resolved value for the geometry properties behave like this example. And tests to back it up. And they're not implemented that way so we need to follow up with implementations.

krit: But we did testing for the other properties in other implementations. They are following the SVG 2 spec text currently.
... Was it correct?

AmeliaBR: SVG 2 didn't say anything about it, so they did the CSS thing, which is to return the computed value not the used values.

krit: So it would be a change to both specification and implementations for the geometry properties.
... So let's keep it for width and height specifically. The text is already there in CSSOM. So, is there anything we need to resolve on?
... Unless we say the geometry properties should behave like width and height, there's nothing to change because it's already covered and implemented.

AmeliaBR: It's a matter of testing, rather than specs

krit: Is there an interest to chagne geometry properties to follow width and height computed style?

AmeliaBR: From a user's perspective, I find it helpful if they were consistent. From a spec perspective, the spec should say what browsers already do

krit: it will be more confusing if we change that part now

ericwilligers: I'll add tests

myles: We should keep what is implemented

krit: Give ericwilligers's tests we can see what is implemented.

AmeliaBR: Sounds good.
... ericwilligers, please ping someone from CSS to make sure it is reviewed and correct

krit: We are out of time.
... anyting else?

<silence>

AmeliaBR: We agreed one more meeting this month, next week, and then 2 weeks off.

krit: Okay, bye!

myles: 👋

<krit> 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/RESOLVED: Remove text-decoration-fill and text-decoration-stroke from SVG. Suggest to SVGWG to move their definitions to CSS fill and stroke or CSS text decoration//
Succeeded: s/krit: Let's open a new topic//
Succeeded: s/yes/let's wait for the testing/
Default Present: krit, ericwilligers, myles, Tavmjong, AmeliaBR, Chris_Lilley, stakagi
Present: krit ericwilligers myles Tavmjong AmeliaBR Chris_Lilley stakagi
Found Scribe: myles
Inferring ScribeNick: myles
Found ScribeNick: myles
Found Date: 10 Dec 2018
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.)