[svg-native] Which CSS concepts should be supported in presentation attributes?

[litherum]

Forked from https://github.com/w3c/svgwg/issues/658:

We already agreed that parsing the presentation attributes needs to use a CSS lexer. How much further should we go?

• var()
• env()
• calc()
• percentages
• relative units
• CSS global keywords unset, etc

Comments should just work, and https://github.com/w3c/svgwg/issues/658 resolved that var will work.

[dirkschulze]

@litherum Could you provide a concrete proposal which features should/should not be supported? IIRC we agreed that var() must be supported.

[litherum]

Sure.

Concept	Supported	Reason
var()	✅	Required for compatibility with OpenType palettes
env()	❌	For now, because nothing would use it, but eventually we should probably add support because env() is a better fit for OpenType palettes than var()
calc()	❌	Large implementation complexity
Percentages	❌	They’re easy to implement, but I can’t think of a reason that a tool would ever want to emit one
Relative Units	❌	Again, can’t think of a reason that a tool would ever want to emit one
CSS global keywords (initial, inherit, unset, revert)	❌	A tool knows what the style should be, so it can just write out the desired style without any of these keywords
all Property	❌	Ditto
Property / Attribute Inheritance	✅	Implementation burden isn’t high, and not having to emit the full style on every element can significantly decrease file size. Also, every existing OT-SVG glyph relies on this

Did I forget anything?

[dirkschulze]

@litherum attr() is in an ED and more functions (all the math functions) are about to arrive. So a white list might be preferable over a black list. But taking the currently speced features as a starting point probably is a good thing. @AmeliaBR comments?

[AmeliaBR]

Going through Myles' list:

• I agree that var() and env() are fairly equal from an implementation perspective. Might as well allow both. But no requirements that a renderer needs to provide any initial values, only that they can parse the function and apply the fallback.

• calc() is most useful in combination with relative or percentage units. If those are going to be banned, banning calc also makes sense, given the implementation complexity. Same for other math functions, which are most useful for dynamic graphical layouts, where you don't want to pre-calculate all the results.

• For percentages, the implementation complexity evaporates if we require viewBox on the root <svg> (and continue to disallow nested SVG viewports). But, the authoring benefits evaporate, too: you can always directly convert the percentages to user units if you know the viewBox size.

• Font-relative units aren't very useful inside a graphic if there is no text within it. But maybe we could still allow all units (and percentages) on the width and height attributes on the outer <svg>, since they set the default size when the graphic is rendered. (E.g., it's common to set them to 1em for an icon.) Viewport-relative units in SVG are like percentages with extra complications, so I suppose they are reasonable to exclude, as well.

• I don't see why there is any implementation complexity to supporting initial and inherit, to cancel inheritance in a normally inherited property or force inheritance in a normally uninherited one.

• all is more complex, but we've already prohibited it by saying we only support styling via presentation attributes; there is no all attribute.

• Full property inheritance is essential.

• attr() doesn't offer any benefits in SVG that only uses presentation attributes.

Other things to think of:

• Which color syntaxes must be supported?
• Should URL values support data URIs?

[dirkschulze]

@AmeliaBR Good points! I am not opposed to special treatment of width and height on the root SVG element but we should clarify what they compute to for user agents that do not support text at all.

It seems that, for the most part, we are in agreement to @litherum ‘s list!

[css-meeting-bot]

The SVG Working Group just discussed Which CSS concepts should be supported in presentation attributes?, and agreed to the following:

• RESOLUTION: SVG Native requires env()

The full IRC log of that discussion

<krit> topic: Which CSS concepts should be supported in presentation attributes?
<krit> GitHub: https://github.com/w3c/svgwg/issues/681
<krit> myles: Made a proposal as a starting point
<krit> myles: We resolved that we need var() last time. env() is a better fit and we will use it eventually.
<krit> AmeliaBR: the spec was not stable and when adopted it should be treated as var(). Maybe some text like that.
<krit> myles: percentages are not difficult to implement but not sure what it would be used for. lets do relative units first...
<krit> myles: Relative units doesn't fit the requirement that there is just one layout and the layout should not change dependent on the content it lives in (similar to PNG)
<krit> AmeliaBR: we might want to have special rules for outside SVG (or maybe not?). Maybe it makes sense to always have absolute values on SVG root?
<krit> myles: Presumably an image element would be styled with a width and height already
<krit> AmeliaBR: just an intrinsic width and height
<krit> AmeliaBR: benefits for abs values is forcing an absolute/explict intrinsic dimension.
<krit> myles: I think I agree on that. Good argument for abs values even on SVG root.
<krit> AmeliaBR: then we have viewBox requirement on SVG root element.
<krit> AmeliaBR: if there is none, then percentages make a difference depending on the computed viewport.
<krit> AmeliaBR: spect ratio is special and separate from rel/abs units.
<krit> myles: If you create a native apps and you put in some things inside it and change the size the resource it might be very unexpected.
<krit> AmeliaBR: viewBox can be discussed separately.
<krit> myles: Requiring env() is future proof and if it works as var() not difficult?
<krit> myles: "If you support var() you should support env()"
<krit> myles: since var is required, env is required.
<krit> RESOLUTION: SVG Native requires env()
<krit> trackbot, end telcon

[dirkschulze]

We already agreed on supporting env() and define that it behaves like var() (or vice versa).

I hope we can make some more progress faster.

Can we get to a conclusion on relative values next? Concerns about not supporting relative values in SVG Native?

Next is percentage values: As @litherum said, in general not a big deal to support it. As @AmeliaBR said, we should require a viewBox if we allow percentage values. With percentage values there might be a desire to support calc().

So can we get to a conclusion to not support percentage values @AmeliaBR @litherum ?

[css-meeting-bot]

The SVG Working Group just discussed [svg-native] Which CSS concepts should be supported in presentation attributes?, and agreed to the following:

• RESOLUTION: SVG Native will not support relative units that are relative to either font metrics or the viewport.
• RESOLUTION: SVG Native does not support percentage length values.

The full IRC log of that discussion

<AmeliaBR> topic: [svg-native] Which CSS concepts should be supported in presentation attributes?
<AmeliaBR> s/topic: [svg-native] Which CSS concepts should be supported in presentation attributes?//
<krit> myles: myles relatives units make no sense in SVG like the font metrics depending units. then there are viewport relative units. the viewport is a little bit confusing in fonts.
<krit> myles: I am also not sure if it is valuable for authoring tools.
<krit> myles: as far as I understand the author would create a graphic that is relative to an artboard.
<krit> myles: I am not sure if the relative length to the viewport dimension is relavant for authoring tools.
<krit> AmeliaBR: for SVG fonts, the viewport would be the em square of the font glyph
<krit> AmeliaBR: It is not well defined and we do not have good support in browsers
<krit> AmeliaBR: ... in all SVG viewers
<krit> AmeliaBR: for the default dimensions on the outer SVG element, the width and height attribute set the default dimensions. In that case it would be great if the context would say that the dimension is 1em x 1em and then it would be useful to have relative units within the SVG element. But even then it is not essential. You could still set the image dimension on the outer SVG element
<krit> AmeliaBR: (1em instead of 60px as default sizing)
<krit> krit: you would not object to myles proposal in general still?
<AmeliaBR> s/it would be useful/it wouldn't be necessary/
<krit> AmeliaBR: just saying that this is the one use case.
<krit> AmeliaBR: especially when viewBox is required, there is no need of relative units inside
<krit> myles: no need to make it required.
<krit> myles: If the author wants to use relative dimensions then the author could simply specify a view
<krit> s/view/viewBox/
<AmeliaBR> s/ on the outer SVG element/ on the element in the outer document that is embedding the SVG file/
<krit> proposal: SVG Native will not support relative units that are relative to either font metrics or the viewport.
<krit> RESOLUTION: SVG Native will not support relative units that are relative to either font metrics or the viewport.
<krit> krit: lets go on to percentage values
<krit> myles: percentages are mostly the same arguments.
<krit> myles: I am only familiar with authoring tools that create images as standalone items
<krit> myles: having elements move around as the containing document stretches doesn't sound useful.
<krit> AmeliaBR: benefit is for hand editing
<krit> AmeliaBR: allows hand editing w/o repeating yourself even within a viewBox
<krit> AmeliaBR: when you don't have a viewbox and want things to be flexible in how they stretch
<krit> AmeliaBR: 2nd use case would be eleminated if we require viewBox
<krit> AmeliaBR: it is a matter what are the priorities: Is SVG Native an export format only? Then we don't need percentage.
<krit> myles: one of the stated assumption is that they are not prioritising hand editing
<krit> myles: I still don't think viewBox should be a requirement if we see it as a scaling image as long as the implementation has access to the dimension.
<myles> https://docs.microsoft.com/en-us/windows/win32/api/d2d1_3/nf-d2d1_3-id2d1devicecontext5-createsvgdocument
<krit> myles: The implementation could know what the viewBox could be based on the extra attribute. So viewBox doesn't need to come from the inside as long as the implementation knows what it is going to be.
<krit> AmeliaBR: that may limit the optimisations you could do.
<krit> myles: We can state that implementations act as if a viewBox was defined but it doesn't actually need to be in the SVG file.
<krit> AmeliaBR: if we put it on the implementation, what is the constrains on the document?
<krit> AmeliaBR: if not viewBox, then width and height could be good enough. And when not defined there is a fallback size.
<krit> AmeliaBR: in all browsers with html elements you don't need a viewBox if you have a width and height on the SVG file.
<krit> AmeliaBR: if you have a 50%/100% relative width/height then it scales to a predefined preset
<krit> myles: most font implementations don't need this information since it is specified somewhere else within the font
<krit> AmeliaBR: with the aggement that SVG Native is not expected to be a hand edited document we can decide against percentage and discuss viewBox later.
<krit> RESOLUTION: SVG Native does not support percentage length values.