- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Jul 2019 21:00:58 +0000
- To: public-svg-issues@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <AmeliaBR> topic: [svg-native] Which CSS concepts should be supported in presentation attributes?<br> <AmeliaBR> s/topic: [svg-native] Which CSS concepts should be supported in presentation attributes?//<br> <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.<br> <krit> myles: I am also not sure if it is valuable for authoring tools.<br> <krit> myles: as far as I understand the author would create a graphic that is relative to an artboard.<br> <krit> myles: I am not sure if the relative length to the viewport dimension is relavant for authoring tools.<br> <krit> AmeliaBR: for SVG fonts, the viewport would be the em square of the font glyph<br> <krit> AmeliaBR: It is not well defined and we do not have good support in browsers<br> <krit> AmeliaBR: ... in all SVG viewers<br> <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<br> <krit> AmeliaBR: (1em instead of 60px as default sizing)<br> <krit> krit: you would not object to myles proposal in general still?<br> <AmeliaBR> s/it would be useful/it wouldn't be necessary/<br> <krit> AmeliaBR: just saying that this is the one use case.<br> <krit> AmeliaBR: especially when viewBox is required, there is no need of relative units inside<br> <krit> myles: no need to make it required.<br> <krit> myles: If the author wants to use relative dimensions then the author could simply specify a view<br> <krit> s/view/viewBox/<br> <AmeliaBR> s/ on the outer SVG element/ on the element in the outer document that is embedding the SVG file/<br> <krit> proposal: SVG Native will not support relative units that are relative to either font metrics or the viewport.<br> <krit> RESOLUTION: SVG Native will not support relative units that are relative to either font metrics or the viewport.<br> <krit> krit: lets go on to percentage values<br> <krit> myles: percentages are mostly the same arguments.<br> <krit> myles: I am only familiar with authoring tools that create images as standalone items<br> <krit> myles: having elements move around as the containing document stretches doesn't sound useful.<br> <krit> AmeliaBR: benefit is for hand editing<br> <krit> AmeliaBR: allows hand editing w/o repeating yourself even within a viewBox<br> <krit> AmeliaBR: when you don't have a viewbox and want things to be flexible in how they stretch<br> <krit> AmeliaBR: 2nd use case would be eleminated if we require viewBox<br> <krit> AmeliaBR: it is a matter what are the priorities: Is SVG Native an export format only? Then we don't need percentage.<br> <krit> myles: one of the stated assumption is that they are not prioritising hand editing<br> <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.<br> <myles> https://docs.microsoft.com/en-us/windows/win32/api/d2d1_3/nf-d2d1_3-id2d1devicecontext5-createsvgdocument<br> <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.<br> <krit> AmeliaBR: that may limit the optimisations you could do.<br> <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.<br> <krit> AmeliaBR: if we put it on the implementation, what is the constrains on the document?<br> <krit> AmeliaBR: if not viewBox, then width and height could be good enough. And when not defined there is a fallback size.<br> <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.<br> <krit> AmeliaBR: if you have a 50%/100% relative width/height then it scales to a predefined preset<br> <krit> myles: most font implementations don't need this information since it is specified somewhere else within the font<br> <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.<br> <krit> RESOLUTION: SVG Native does not support percentage length values.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/681#issuecomment-507424228 using your GitHub account
Received on Monday, 1 July 2019 21:01:00 UTC