- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Jul 2017 16:43:02 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1609<br> <dael> fantasai: Wewon't reoslve here, but I wanted attention. I checked in some rules for this that are in the sizing spec and we'd appriciate review. There's another case in issue 951. There's no hints in 2.1 for this case and there's discussion there on how to handle it.<br> <AmeliaBR> q+<br> <dael> fantasai: So there's two things with these. We'd like review of the new text and we should resolve 951, but that's on the F2F agenda.<br> <Rossen_> ack AmeliaBR<br> <dael> AmeliaBR: I haven't looked into the various issues with as much detail as I'd like, but it looks like the specific issue of what to do when width is undefined...that's....basically there are a lot of thigns with SVG not defined in any spec but we're getting a defactor standard from browsers impl so you'd want somme tests to see what's already done.<br> <dael> AmeliaBR: I or someone else could do that before the meeting in a couple weeks. Sorry I didn't prepare before.<br> <AmeliaBR> s/defactor/de facto/<br> <dael> Rossen_: Good point. In terms of SVG and ways we compute intrinisic size and all the varitions...about a year ago we were revving our version of SVG sizing and at that time we did document what everyone is doing. I believe we have introp in most of the cases. The result of the work I believe was spec or tried to spec in the integration spec<br> <dael> Rossen_: If it didn't make it it should be there. Regardless it's a valid point and we should solidify and explain how that works. Definitely a big +1 from me<br> <AmeliaBR> https://www.w3.org/TR/SVG2/coords.html#SizingSVGInCSS<br> <dael> AmeliaBR: The text is SVG 2^<br> <dael> AmeliaBR: That's written in very SVG specific. For CSS you'd want to generalize, but it's written with CSS termonology. It can prob be resused. It doesn't cover min-width and max-width which becomes and issue w ith flexbox and grid layouts.<br> <dael> fantasai: This is defining what intrinisic dims the SVG has. THe SVG can return any combo of these as far as I'm aware.<br> <dael> fantasai: I thinkt he one combo they don't have is widht and height but no aspect ratio because you infer that.<br> <dael> Rossen_: Width and height with both % aren't.<br> <dael> fantasai: SVG says we don't have an aspect ratio in %<br> <dael> Rossen_: Width and height are computable.<br> <dael> fantasai: Spec says if width or height are auto or % CSS is told there is no width or height. CSS algo takes that to calc a box. CSS then tells the SVG here's your size. Then SVg uses information to draw inside the rectangle. This spec is about howto size that rectangle.<br> <dael> fantasai: When you're auto sized if the SVG has a width and height that's easy. If it has one or the other...it's missing some info...we need answers. IF it has aspect ratio ut not width or height browsers tend to use size of contaiing block to calc width and use aspect ratiof or height<br> <dael> fantasai: That gives you a fulls sized SVG image taking up width of containing block.<br> <dael> fantasai: So that's great and I think standardizing on that wehre we can is great. THere's one case with cyclic dependency. You can't use containing block size if that size depends on you.<br> <dael> fantasai: We need an answer for that size. I think there sin't consistancy in this respect. I think using 300px for the width is possible but not ideal. 951 is to find a better solution. Current proposal is same as what we do for orthgonal flows. We havea formula to find a size<br> <dael> fantasai: The rest of the cases are a little constrained. If you don't have any intrinisic size or aspect ratio, that's the iframe case and we use 330 x 150.<br> <dael> fantasai: We took t he 2.1 rules and tried to write them into Sizing. That one underfined case is on the F2F agenda.<br> <dael> Rossen_: That's 951?<br> <dael> fantasai: 951 is the open. Other we believe is consistant with 2.1, but it all requires a bunch of testing and i haven't done that.<br> <dael> fantasai: We're looking for review of CSS 3 Sizing to make sure it's correct and thoughts on 951.<br> <dael> Rossen_: I'm going to go back to your opening statement that this is more of an awareness call. I would side on taking this to the F2F and solving on a white boar.<br> <dael> Rossen_: Resolving now won't get us too far.<br> <dael> fantasai: If AmeliaBR would review that section we'd appriciate.<br> <dael> AmeliaBR: I'll try.<br> <dael> Rossen_: Will you be at F2F?<br> <dael> AmeliaBR: No.<br> <dael> [sadness]<br> <dael> Rossen_: Let us know if you can call in and we'll try and accomodate.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1609#issuecomment-318112114 using your GitHub account
Received on Wednesday, 26 July 2017 16:43:03 UTC