Re: [csswg-drafts] [css-transform] the used value for border-box

The Working Group just discussed `default value for the used value for border-box et al.`.

<details><summary>The full IRC log of that discussion</summary>
&lt;krit> topic: default value for the used value for border-box et al.<br>
&lt;BogdanBrinza> GitHub: https://github.com/w3c/csswg-drafts/issues/999<br>
&lt;krit> krit: different geometry boxes, they are boxes from CSS + additional boxes for SVG<br>
&lt;krit> krit: padding-box, border-box, content-box... how do they map to SVG?<br>
&lt;krit> AmeliaBR: There was a resolution from cSS to have a universal map that works on all properties but...<br>
&lt;krit> krit: border-box would map to stroke-box, content-box to obejctBoundingBox and so on<br>
&lt;krit> AmeliaBR: SVG elements defines an SVG canvas that has CSS and SVG layout (defined by its content)<br>
&lt;krit> krit: my issue with transforms specifically is the default used value is border-box for HTML and it would be incompatible to SVGs default which can not be mapped to SVGs stroke-box<br>
&lt;krit> BogdanBrinza: is there an example that can show the incompatibility.<br>
&lt;BogdanBrinza> https://jsfiddle.net/rcnLcg4a/<br>
&lt;krit> krit: if you look at the example, the origin for rotation is outside of the rectanble<br>
&lt;krit> krit: more prceisely, it is the opt left of the "view-box"<br>
&lt;krit> krit: we can not break that for SVG.<br>
&lt;krit> krit: if you create an example with HTML, you'd see that the origin (on top left origin) would be the origin of the top left border box and not the viewport or anything else<br>
&lt;krit> krit: for me this is a "no fix" for the spec. Keep it as it is, map border-box to view-box in SVG<br>
&lt;krit> krit: we can decide what to do next week as well.<br>
&lt;krit> BogdanBrinza: I am still not sure I see the difference between HTML and SVG and how they would be incompatible if we change it to the CSS resolution. I'd like to see more examples.<br>
&lt;krit> krit: I'll create examples and attach them to make the difference between HTML and sVG visible for next week.<br>
&lt;krit> AmeliaBR: I think for transform I thought the spec changed to the resolution... question is if we can use same definition on other specs like clip-path.<br>
&lt;krit> BogdanBrinza: yes, that is right.<br>
&lt;krit> BogdanBrinza: would be super helpful to see how this breaks.<br>
&lt;krit> AmeliaBR: currently as speed in mask, if you use any of the HTML boxes it defaults to the default for SVG boxes ditto the other way around.<br>
&lt;krit> s/speed/speced/<br>
&lt;krit> AmeliaBR: ideally we would like to keep them as logical as possible.<br>
&lt;krit> AmeliaBR: only complication is that some only allow certain sub-boxes of these boxes<br>
&lt;krit> BogdanBrinza: action to dirk to provide examples and to Jeff to look at the examples and see if there is any breakage<br>
&lt;krit> AmeliaBR: as far as compatibility is concerned, the default behavior has to match SVG1 behavior<br>
&lt;krit> krit: I think fill and stroke spec defines border-box as stroke-box  which is incompatible<br>
&lt;krit> AmeliaBR: the default changed in transform which still makes it compatible... we need to look at mask and clipping as well now.<br>
&lt;krit> AmeliaBR: make defaults consistent but adapt them to make the mapping consistent as much as backwards compatibility doesn't break<br>
&lt;krit> krit: so create some examples for masking and clip-path and review them in one of the next meetings.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/999#issuecomment-383687906 using your GitHub account

Received on Monday, 23 April 2018 19:07:11 UTC