- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 3 Aug 2020 19:42:43 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Sizing ---------- - RESOLVED: 'height: stretch' behaves as 100% applied to margin-box where 'align-self: stretch' isn't possible (Issue #1614: `height: stretch` should just behave as `height: auto`) - There was interest/support in doing further exploration into and creating a proposal for importing the aspect-ratio from a child (Issue #5269: Import aspect-ratio from child image). Some items raised on the call for the proposal to consider is behavior around whitespace and importing from first child instead of importing only if there's one child. CSS Images ---------- - RESOLVED: Do not expose orientation data for cross-origin images by treating EXIF orientation as integral (can't ignore) (Issue #5165: image-orientation:none violates same-origin policy) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#monday Scribe: fantasai Sizing ====== `height: stretch` should just behave as `height: auto` ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/1614#issuecomment-661391733 TabAtkins: A little while ago we added 'stretch' keyword to width/ height TabAtkins: width: stretch does what blocks normally do in block layout TabAtkins: even in cases that currently do fit-content for 'auto' TabAtkins: The question was what happens if specify for height TabAtkins: Initially tried to do something from an earlier attempt from dbaron TabAtkins: would increase height of item as much as needed to fill height of closest definite ancestor TabAtkins: This ended up being weird, potentially blows up further than you want TabAtkins: Took a resolution to make it behave like 'align-self: stretch' wherever that has a meaning TabAtkins: and in other cases, behaves like auto TabAtkins: but when editing in realized we could do most of what was wanted TabAtkins: by treating similar to percentage height when percentages can resolved TabAtkins: So basically act like slightly smarter 100% (considers margins also) TabAtkins: wherever that's currently defined to resolve TabAtkins: and otherwise fall back to auto TabAtkins: no extra magic TabAtkins: Filling container when percentage could resolve TabAtkins: gives better abilities TabAtkins: this proposed behavior, acting like 100% minus margins, border, padding TabAtkins: Gives an expected and useful behavior for 'stretch' without causing the inflating behavior concerned with earlier cbiesinger: This makes a lot of sense. AmeliaBR: If you did want the behavior of dealing with a couple parents levels of padding and borders, just describing each level as 'height: stretch', would that work? TabAtkins: Just as percentage resolved against definite size is treated as definite, stretch resolved against such would also be definite TabAtkins: would then follow up the tree cbiesinger: This is basically renamed fill-available keyword, right? TabAtkins: Yes astearns: Questions or comments? dbaron: I guess the one thing, the thing I originally proposed dbaron: for orthogonal flow stuff dbaron: somewhat different use case dbaron: it's a little weird TabAtkins: At least, I don't think we want that behavior by default, so don't think hooking it into 'stretch' TabAtkins: if we want that, maybe different keyword astearns: So proposed resolution is that height: stretch, when can't behave as align-self: stretch, will behave as 100% but accounting for margins <AmeliaBR> +1 for the proposal. Let's make this as useful as possible. Rossen: Would it contribute to any other height sizing algorithms that aren't fixed? TabAtkins: What do you mean? Rossen: If this is just a block wrapped in a block... Rossen: grid item has behavior already defined Rossen: but block inside grid item is now simply defined by the closest fixed container Rossen: so if grid item is not fixed, then you have to propagate up Rossen: and stretch the size minus margins borders padding to whatever is in the further ancestry of that thing TabAtkins: That is explicitly what we are not doing TabAtkins: This just looks nearest container, same as percentages TabAtkins: it is exactly identical as 100%, but sizes margin box instead of content box Rossen: ok, then that makes a lot of sense <cbiesinger> nearest container -> containing block, I think? <fantasai> not exactly, e.g. <p><span><inline-block/></span></p> AmeliaBR: We have a few cases in CSS where percentages aren't doing useful things AmeliaBR: e.g. cyclic percentage contributes zero, resolves, lots of overflow, is bad Scribe: dael fantasai: I think most of those cases where you have problems are those where percent isn't 100. If you put 50% you get weird overflow. If you put 100% these resolve ok. TabAtkins: Child of a float fills at 100%. There will be weird because margins/border/padding AmeliaBR: I had it in mind with weird percentages astearns: Other comments? astearns: Proposal: height-stretch behaves as even better 100% astearns: I have a concern astearns: Is it possible for modes that doesn't match to align-self we're in a corner? TabAtkins: This is meant to be same as align-self in those cases. If we didn't have that in grid and defined this it should be same. We anticipate extensibility. fantasai: Where align-self doesn't apply are cases where it doesn't make sense. You have a stack of things that are placed relative to each other. 'stretch' is not defined as whether align-self is implemented in that mode, but if it's defined to apply there per spec. astearns: Okay astearns: Objections to height: stretch behaves as better 100% where align-self: stretch isn't possible RESOLVED: 'height: stretch' behaves as 100% applied to margin-box where 'align-self: stretch' isn't possible <break type=30min> Import aspect-ratio from child image ------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/5269 TabAtkins: Two big use cases people run into that make aspect-ratio not work how they want TabAtkins: In block layout if you have image with aspect-ratio and wrapper doesn't effect, but in flexbox or grid there is special code that is defeated by wrapper; Including link or picture element which are common TabAtkins: Request is for a parent element to get aspect-ratio from child but only if it has a single child with aspect-ratio. In all other cases acts like aspect-ratio none TabAtkins: I don't think needs to grab other intrinsic sizes, but we can think about that. Flexbox only cases about ratio. TabAtkins: Some unanswered questions. What do you want to do with margins/borders/padding which change render size TabAtkins: We can probably resolve in further issues TabAtkins: General case to pull aspect-ratio from single child do people think this is reasonable? fantasai: Not sure we want to take from an only child. A lot of cases where we pull something like this where you grab first child. Whatever we do for grab info from child should be consistent. Not sure it should be check for only one child TabAtkins: I don't think SVG is useful for examples because it doesn't have layout. Further children don't affect. In this case if you have an element with image and fit caption if you take from image it's meaningless fantasai: You can have positioned caption on top of picture which makes sense TabAtkins: One inflow child then AmeliaBR: That's my point, one inflow child for case of figure with caption on top of image. AmeliaBR: I'm not sure what fantasai was thinking on SVG but I can't think of a case where it gets aspect-ratio from children. SVG in a CSS layout having these behaviors is useful fantasai: Not specifically aspect-ratio. I think some property in SVG grabs info from children AmeliaBR: title and description? AmeliaBR: Either way, need to think about would it be web compat to make this default change? We have lots of flex and grid layouts where if this was available authors would have loved but they have made adjustments and doing by default is problem AmeliaBR: Could make keyword for aspect-ratio property. On you picture element have an aspect-ratio from content that would have this special behavior AmeliaBR: If it's web compat to make it default where if you have one inflow child with an aspect-ratio container is aspect-ratio it would be great to be automatic. TabAtkins: I strongly suspect its not web compat. I'd like to run on that assumption that this is specific property; an aspect-ratio keyword that does it fantasai: Or some new syntax fantasai: New keyword or something else emilio: I was going to say behavior will be weird with applied whitespace. Children create boxes which can be collapsed or suppressed but that's optimization. Bit weird that whitespace around image this trick doesn't work TabAtkins: How weird if we did ignore collapsed whitespace emilio: Somewhat. I don't have strong opinions. Direction with single box is odd. fantasai: I would have said first child element Rossen: In doc order? emilio: Right fantasai: Yes TabAtkins: If you take first child element it excludes text. Non-whitespace text would be ignored too so should trigger no aspect-ratio <AmeliaBR> So… if the container has exactly one in-flow, non-collapsed-ws child box…, then `aspect-ratio: from-contents` works <fantasai> I think we can let the author not specify the keyword if there's other content they want to ignore <heycam> in SVG we did at one point discuss allowing properties that refer to elements by URL to have a "from-child" or something keyword, e.g. so you could do <path style="marker-end: from-child"><marker>. but that didn't really go anywhere beyond an idea. (might be fantasai is thinking about this) cbiesinger: I'm also concerned it's a lot of magic. A lot like emilio's comments cbiesinger: Have to be careful to not add something that will break this cbiesinger: Use cases I've heard from webdev is they wanted aspect-ratio and they were happy. Didn't ask for this cbiesinger: Final thing, picture element should probably take aspect-ratio from img tag TabAtkins: I don't think just aspect-ratio is usable because of picture. Different source could provide different aspect-ratio and you can't easily predict cbiesinger: Getting aspect-ratio from child makes most sense TabAtkins: Don't see reason to differentiate between picture and a. Picture into link is common and easy and I would prefer it didn't break layout cbiesinger: Careful about line breaks between a and img TabAtkins: Unless we do something about collapsible whitespace fantasai: Collapsible whitespace doesn't generate box right? emilio: Maybe. In Gecko we don't when we can prove it doesn't have to. But we need to deal with it. TabAtkins: Unsure if it's clear if box is generated. fantasai: If it did it would interrupt margin collapsing. TabAtkins: Yeah, okay. Great observation. In that we observe this with margin collapsing should be able to observe without being particularly weird Rossen: Looking through issue this is mostly to introduce and feel room Rossen: Sounds like some level of anxiety but also use cases which are supported. Rossen: What's next step? Work more for concrete proposal? TabAtkins: I was seeking if objections. Information is useful. We can put a proposal in spec and bring it to WG Rossen: Anything else on this? CSS Images ========== image-orientation:none violates same-origin policy -------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5165 heycam: We have image-orientation. Ignoring print processors it's used for authors to opt out of what we're moving to with EXIF orientation honored by defualt. It's really that EXIF orientation is impl detail on how image is represented in file heycam: We have image-orientation: none which lets authors opt-out heycam: In Gecko and Chrome image-orientation: none applies to same and cross origin images heycam: Anne pointed out that applying to cross-origin it's a leak of one bit of info. For images cross-origin you can look at width and height. Because you can tell if it's re-oriented 90 deg you can get an extra bit of info to know if image meta was one set of value or another heycam: Shouldn't add more leaks in theory. Perhaps arguable if it's super important if this makes a difference and weigh it against value for authors heycam: It's something to discuss TabAtkins: All this makes sense to me. image-orientation and the image resolution which you can observe via src set is info leaks. Way through is make cross-origin images behave like it's information was baked in so they can't turn off orientation. It would mean cross-origin would act as if exif was it's native orientation. Similar logic would apply to resolution where you could select correctly but it would act baked in TabAtkins: Regardless of how you look at image you get same data. TabAtkins: Sounds good, happy to adopt TabAtkins: Not sure if it's css or html but happy to figure it out fantasai: It think it lives in css-images. AmeliaBR: Support what TabAtkins said. One proposal in issue was do reverse where cross-origin ignores exif and I don't want that. Render it as the image format is supposed to be rendered including exif but don't make it inspectable how it was generated. cbiesinger: Two comments. Seems like angle is a possible value with same problem. cbiesinger: In response to TabAtkins I think a lot of websites are images from different host. Seems like not supporting would make chrome exif a lot less useful. cbiesinger: Don't have a good solution but it's not ideal AmeliaBR: This would be normal http cross-origin so if you have full control over cdn and can give correct headers that's one way to turn off exif TabAtkins: This should continue to work as normal for cdn but you wouldn't be able to turn exif off. It would always be on heycam: Possible you're using images from cdn and relying on orientation not being applied. I don't think there's anything special about images from cdn TabAtkins: In general our research has shown better for web if we do respect exif at all times heycam: I'm in favor of model TabAtkins describes. Had one person contact me where he would like it to continue to apply to cross origin because they have tool to present image and get user to annotate and then they hand over annotation to another tool. Without being able to tell the tool the orientation they can't tell if they have to process. heycam: They can work around that by fetching the image on the server side TabAtkins: Or proxy the image request to turn on cors stuff they'll be fine Rossen: Where do we go from here? TabAtkins: Unless there's objections proposal is do not expose orientation data from cross-origin images. Do it by having the masquerade as their exif orientation being the native TabAtkins: 2 resolutions. One we want, one is implementation strategy Rossen: Proposal: Do not expose orientation data for cross-origin images Rossen: Comments or objections? RESOLVED: Do not expose orientation data for cross-origin images by treating EXIF as native resolution Rossen: Question; for things like cloud functions are they cross-origin? Rossen: Cloud functions your source has an image call TabAtkins: Don't know but definition of cross-origin is stable so I'll rely on that. It's very precise and I don't want to manipulate it cbiesinger: Question is do we have use counter data for how often we have image orientation that's not from exif? TabAtkins: Don't think we do yet. We know in general honoring exif is the better way to go so even if there are cases that are specifically needing to care it's a smaller subset of the subset we consider is okay to break cbiesinger: Okay it's better, curious about how big the number is <cbiesinger> looks like image-orientation in general is only used on 0.13% of pageloads so this is probably OK Rossen: Have the resolution on record. Add anything about impl direction or in the minutes is enough? TabAtkins: Minutes is enough heycam: Anne raised a separate issue about who defines this and have a spec which can be referenced. That's something for later.
Received on Monday, 3 August 2020 23:43:37 UTC