– DRAFT –
(MEETING TITLE)

[css-sizing-3][css-values-4] Define width and height CSS values for SVG Elements in a mapping

w3c/csswg-drafts#12376

dmangal

dmangal: Defioning view port related length, with sizing.

dmangal: follow-up on last weeks discussions. CSS length attributes can take sizing like v-min, v-max with resolution depending on viewport. SVG elements do create their own viewbox thow. Which viewbox to use?

dmangal: outer SVG elements should use ICB but inner elements use viewbox of SVG eleemtns. So ICB is not clear.

dmangal: Viewbox related elements should be aligned to ICB or browser viewbox.

dmangal: most browsers do that but got pushback: what happens on an iframe?

dmangal: will the viewbox be the viewbox of browser window or iframe?

dmangal: other proposals got rejected as well.

<dmangal> https://www.w3.org/TR/CSS2/visudet.html#containing-block-details

dmangal: For SVG editors it will be the SVG documents width and height

krit: What was the proposal on teh Iframe?

dmangal: If we resolve the viewbox on browser window, iframe dimensions can be shorter.

dmangal: bounds will still be browser window bounds and not iframe

Ragvesh: not sure if that would be correct?

dmangal: most browsers only resolve ICB with browser windows bounds.

krit: lets define what browsers do already?

dmangal: people disagreed. We want to add something in the spec that is more "correct". No conclusion what would be correct.

karlcow: Not easy to change interop behavior of browsers.

karlcow: a change might break existing content

karlcow: there is no versioning

karlcow: not in favor for a new definition not already implemented in browsers.

dmangal: made this experience as well

krit: more in favor of defining interop

dmangal: CSS is not talking about browser window but ICB we don't have that for inner SVG.

<karlcow> https://svgwg.org/svg2-draft/coords.html#ViewportSpace

<karlcow> > The initial viewport's width, must be the value of the width presentation attribute on the outermost svg element, unless the following conditions are met:

dmangal: initial proposal was resolving to nearest SVG viewport. Percentage does this already though.

dmangal: especially Firefox was opposed because it is doable with percentage already.

Ragvesh: nearest viewport makes sense to me

dmangal: roots SVG element was one suggestion

dmangal: but no consensus there either

dmangal: browsers usually use root SVG for ICB today.

dmangal: this is common in all 3 browser engines.

krit: here again: IMO makes more sense to define the current implemented behavior.

dmangal: we still need to define it in a logical way in SVG.

<dmangal> w3c/csswg-drafts#12376

karlcow: we should open an issue on SVG spec and resolve the correct term in SVG itself and define the terms here.

RESOLUTION: We resolve units against ICB when available or SVG viewport of outer SVG root element. dmangal will clarify which terms to use with CSS WG.

::selection and other highlights in SVG

w3c/svgwg#894

karlcow: Selection of text element with ::selection here you get different behaviors on different browsers

karlcow: If you use colour, it doesn't work in SVG

karlcow: because we use the fill propoert for filling text.

karlcow: color: green does nothing in safari or chrome but with fill: green it shows green in Safari and Chrome and black in Firefox.

karlcow: FF seems bizar

krit: With currentColor you get the color in fill. If fill is not defined, it should use the initial value. What is it for fill?

karlcow: it is black

<karlcow> ::selection {color: green}

krit: so then the text should be black. If not specified it should use black (the inital value)

karlcow: the exmaple ::selection {color: green} is working on FF

<karlcow> ::selection {fill: green}

karlcow: Chrome and Safari only work with ::selection {fill: green}

<karlcow> ::selection {background-color: gold}

karlcow: the intention is to fill the selected text with the specified color. background-color does work even on SVG elements.

<karlcow> text {color: green}

<karlcow> text {fill: green}

karlcow: So background-color does work even on SVG elkements but color doesn't (in the way as for HTML elements, only via currentColor)

Ragvesh: In Chromium, for text, the pseudo element doesn't work (like ::first-letter)

Ragvesh: so maybe the behavior in FF is more reasonable?

karlcow: but selector is workin in general, it is only the difference for using the fill and color on SVG element. I wonder which one is right?

krit: so fill: green would not work in FF?

karlcow: no, it is black.

krit: what about stroke and stroke-width? Is that working in FF

karlcow: didn't try

<karlcow> https://wpt.fyi/results/css/css-pseudo/svg-text-selection-002.html

<karlcow> http://wpt.live/css/css-pseudo/svg-text-selection-002.html

krit: We should create a test on stroke. My feeling is we should use fill and stroke for SVG text as specified for non-selection behavior. But lets see if FF even supports stroke. If not, it is rather an implementation issue in FF.

karlcow: I'll test more and get back

dmangal: stroke seems to work on FF and Chrome

dmangal: having a test case.

RESOLUTION: karlcow getting back with more tests and open an issue on Firefox for further discussions. Then get back to SVG WG.

references to CSS specs in SVG2

Tav: Which specs do we update links to. Do we go to CSS Colors 4 as well?

krit: All CSS specs should be update to the latest versions in SVG, not just sizing but colors and others too.

Tav: what about CSS gradients as fill/stroke on SVG elements? Would that be supported too? Especially interpolation and color spaces is missing in SVG gradients.

RESOLUTION: Tav to create a github issue on CSS gradients in fill/stroke. All vendors shall get back to their teams and discuss this.

Vinay: Adoption might not be very welcome by browser implementers. Stroke does not work with text decorations in any browser.

Vinay: will comment on Tavs github issue with examples