- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Apr 2017 02:36:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS-SVG Box Correspondences`, and agreed to the following resolutions: * `RESOLVED Initial value of transform is view-box` * `RESOLVED: Initial value of transform is view-box` * `RESOLVED: view-box and stroke-bo resolve to the same as boxes defined in fill-stroke module` <details><summary>The full IRC log of that discussion</summary> ``` <fantasai> Topic: CSS-SVG Box Correspondences <Rossen> ScribeNick: flackr <tantek> present+ <flackr> fantasai: issue is to have a standardized mapping between dash box keywords, bunch of properties take these kinds of keywords <skk> present+ <dbaron> s/dash box/*-box/ <flackr> Rossen: yesterday we partially covered issue, and agreed on mapping. content-box and padding-box map to fill-box. border-box maps to stroke-box <flackr> fantasai: we need something to go back in other direction <flackr> Rossen: for view-box? <flackr> TabAtkins: it's a box, but we don't have anything that let's you refer to it <dbaron> It seems we have three github issues on this: https://github.com/w3c/fxtf-drafts/issues/66 https://github.com/w3c/csswg-drafts/issues/999 https://github.com/w3c/csswg-drafts/issues/857 <flackr> TabAtkins: we can map view-box to one of the element based boxes <dbaron> Github issue: https://github.com/w3c/csswg-drafts/issues/857 <flackr> fantasai: in fill and stroke module css ends up having all of these boxes, <points to content, padding, border, stroke> <flackr> fantasai: are there places in other specs where we take these boxes? <flackr> TabAtkins: no, we only have these in fill and stroke because they talk about text, with geometry different than normal boxes <flackr> fantasai: fill-origin property, which takes these keywords can be set on any element. it's not applied to text, applied to an element and takes that object's geometry for settting the fill origin for images <flackr> fantasai: if we don't have transform-box or other box properties use that same definition, then if you set coordinates in transforms and set the same in fill or stroke, you would get different results <flackr> fantasai: we didn't run into a use case while working on transforms that we needed these text based bounding box concepts, but we should use this same concept in all of our boxes whereever fill or stroke appears <flackr> fantasai: for example for setting a mask image with the same origin when set to fill-box as a fill with origin set to fill-box <flackr> TabAtkins: possible <flackr> TabAtkins: problem is that mask, transform, and shapes <flackr> fantasai: shape doesn't have fill and stroke <dbaron> reading https://github.com/w3c/csswg-drafts/issues/999#issuecomment-277024658 <flackr> dbaron: the notion that some of the properties are doign different things does make some sense because they can't reasonably map into the same property <flackr> fantasai: didn't discover we needed fill and stroke box until we did this module <fantasai> s/this/fill-stroke/ <dbaron> https://drafts.fxtf.org/fill-stroke/ <fantasai> s/until/in CSS until/ <flackr> fantasai: view-box is on transform-box property? <flackr> TabAtkins: just on transform-box <flackr> ChrisL: the view-box declared on the closest svg element <flackr> Rossen: kind of like initial box of the svg <flackr> TabAtkins: I don't agree in general we should match fill-box and stroke-box to same meaning <flackr> TabAtkins: because these properties are dealing with text and these properties are talking about properly filling and stroking that text <flackr> TabAtkins: whereas for svg they are in a different context, it depends on the property you are interpreting for <flackr> fantasai: if you have element with some text, and the fill box is bigger, then when you draw an image and add a mask, these need to use the same coordinate system <flackr> fantasai: but if you're saying fill-box is not available for mask origin can't make these line up <flackr> TabAtkins: it's still a matter of which concept you're talking about, the box's geometry or the geometry of the text <flackr> fantasai: it should create the same coordinate system that it does if you set fill-origin on that element <flackr> Rossen: in css boxes internally, this is going to be an overflow box <flackr> fantasai: it's text only <flackr> fantasai: it's the outline of the glyphs, so not quite the inline text box <flackr> fantasai: i think we need consistent coordinate systems, fill-origin and mask-origin should have the same behavior for the same keywords <flackr> fantasai: if those have same behavior for same keywords, transform-box should too <flackr> TabAtkins: yeah, but other properties such as mask-origin, when using svg keyword on css stuff will have a changed meaning <flackr> fantasai: hopefully people aren't doing that <flackr> ChrisL: how much of a breaking change is this? <flackr> TabAtkins: might be minor, might be major, depends on content <flackr> fantasai: initial value might need to be some kind of auto keyword that depends on whether it's svg or css <flackr> ChrisL: i'd rather avoid making breaking changes unless we have to <fantasai> fantasai: or a UA stylesheet thing <flackr> TabAtkins: initial value of border-box for svg is view-box <flackr> TabAtkins: transforms and svgs default to the top-left corner <flackr> TabAtkins: i guess i'm okay with this <flackr> TabAtkins: with fill-box used in css meaning what's defined in fill and stroke <flackr> Rossen: we don't care about view-box? <flackr> fantasai: this is another issue i think <flackr> TabAtkins: think we added auto keyword <fantasai> [confusion about what the resolutions actually were] <flackr> fantasai: if I specify transform-box: border-box on svg element what do i get? <flackr> fantasai: If i specify transform-box: view-box on a CSS box what do i get? <flackr> TabAtkins: maps down to border-box, it's the closest you can get <flackr> fantasai: what's the initial value? <flackr> TabAtkins: something different, forget what specifically <dbaron> (answer to the previous question was border-box -> stroke-box on SVG) <flackr> fantasai: make initial value view-box to get behavior we want it to have <flackr> ChrisL: that seems fine <fantasai> Resolutions from yesterday, presumably were <fantasai> * border-box in SVG is treated as stroke-box <fantasai> * view-box is in CSS is treated as border-box <fantasai> * initial value is view-box <fantasai> From today: fill-box and stroke-box for CSS are as defined in fill-stroke <fantasai> for completeness, content-box and padding-box in SVG are treated as fill-box <flackr> Rossen: view-box and stroke-box resolve to the same as boxes defined in svg fill-stroke <flackr> RESOLVED Initial value of transform is view-box <flackr> RESOLVED: Initial value of transform is view-box <fantasai> RESOLVED: view-box and stroke-bo resolve to the same as boxes defined in fill-stroke module <fantasai> s/stroke-bo/stroke-box/ ``` </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/857#issuecomment-296024182 using your GitHub account
Received on Friday, 21 April 2017 02:36:18 UTC