- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Oct 2018 09:02:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Aspect Ratio`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: Aspect Ratio<br>
<fantasai> jensimmons: There's been a longstanding desire for aspect ratio support in CSS<br>
<fantasai> jensimmons: Brought up not only because I brought it up, but many people around the worl dhave been writing blog posts talking about this<br>
<fantasai> jensimmons: So fantasai drafted up some spec text last week<br>
<fantasai> jensimmons: Here's an example<br>
<fantasai> jensimmons: People are resizing their images in CSS, and width is being set to 100% and height to auto, and the image keeps its aspect ratio<br>
<fantasai> jensimmons: But some elements do not have an intrinsic aspect ratio<br>
<fantasai> jensimmons: e.g. iframe, article, tec.<br>
<fantasai> jensimmons: Some are replaced elements, some are not, but they odn't have intinsic aspect ratio so things get squished<br>
<fantasai> jensimmons: Why are people not using the video element?<br>
<fantasai> jensimmons: THey're using youtube, vimeo, etc.<br>
<fantasai> jensimmons: because of adaptive bitrate streaming<br>
<fantasai> jensimmons: but it's a reality that's very important for supporting varyious netowrk connections<br>
<fantasai> jensimmons: so videos in iframes are important<br>
<fantasai> jensimmons: Here's what happens when you try to resize the iframe: no preservation of the aspect ratio<br>
<fantasai> jensimmons: First solutionof the industry was fitvids.js<br>
<fantasai> jensimmons: It's not a great idea<br>
<fantasai> jensimmons: Everything since has been using the padding hack<br>
<fantasai> jensimmons: Using the fact that pading in % is going off the width rather than the hack, and ppl exploiting that to get aspect ratio<br>
<fantasai> jensimmons: Only some ppl know about it, it's tricky to use..<br>
<fantasai> jensimmons: Would be much better to have something in CSS to solve this<br>
<fantasai> jensimmons: Our current thoguht is to use a property, 'aspect-ratio: 16 / 9' e.g.<br>
<fantasai> jensimmons: This would cause the element to hook into all the existing rules that handle elements with an asepct ratio<br>
<fantasai> jensimmons: This is written up as a super rough draft in CSS sizing L4<br>
<astearns> https://drafts.csswg.org/css-sizing-4/#ratios<br>
<fantasai> https://drafts.csswg.org/css-sizing-4/#ratios<br>
<fantasai> jensimmons: Videos would be done like<br>
<fantasai> jensimmons: iframe { aspect-ratio: 16/9; width: 100%; height: auto; }<br>
<fantasai> jensimmons: Syntax of the property is coming from the Media Query syntax for aspect-ratio<br>
<fantasai> jensimmons: Idea was just to copy that syntax<br>
<fantasai> jensimmons: for consistency and also I like that<br>
<fantasai> jensimmons: SO that's great, solve things like video in iframj<br>
<fantasai> jensimmons: But there are also other cases where we care about aspect ratios<br>
<fantasai> jensimmons: Let's say you want a bunch of squares with text in them<br>
<fantasai> jensimmons: In this example I used viewport units, but it would be nice to be able to just give an intrinsic aspect ratio<br>
<fantasai> jensimmons: Here's a use case<br>
<fantasai> jensimmons: We have boxes with different amounts of content in them, and we want them to have 2:1 aspect ratio<br>
<fantasai> jensimmons: Problem here is that in some cases there's too much text, and it oveflows!<br>
<fantasai> jensimmons: Want to be able to say that "I want this aspect ratio as my min-height, if the box get bigger let it grow like usual"<br>
<fantasai> jensimmons: Two options in the raft<br>
<fantasai> jensimmons: Option A is to have a keyword of some kind which you can put in min-height to request from-ratio, and then say that the height is max-content<br>
<fantasai> jensimmons: article { aspect-ratio: 2 / 1; height: max-content; min-height: from-ratio; }<br>
<fantasai> jensimmons: Other possibility is to use 'ar' units, which come from grid L2 spec<br>
<fantasai> jensimmons: I would change the name, don't think 'ar' is the right name<br>
<fantasai> jensimmons: But basically it grabs the number of the corresponding property in the opposite dimension and multiplies it<br>
<fantasai> jensimmons: e.g. we ahve gaps in one side, the other side says 2ar, it'll be twice the width of the other-dimension gap<br>
<fantasai> jensimmons: So we could use those in the height properties, e.g. 'min-height: 0.5ar'<br>
<fantasai> jensimmons: Going further, it'd be great if we could use attr() to grab the width/height attributes from the HTML and put it into the aspect-ratio<br>
<fantasai> jensimmons: This would solve a performance problem everyone wants to solve, to do layout before the image loads<br>
<fantasai> jensimmons: There's been a variety of proposals for adding new attributes to do this, but we could just use it with CSS by using attr<br>
<TabAtkins> https://github.com/ojanvafai/intrinsicsize-attribute for the HTML-based way to set intrinsic sizes/ratio before loading them.<br>
<fantasai> jensimmons: e.g. iframe { aspect-ratio: attr(width px) / attr(height px); }<br>
<TabAtkins> Still an early proposal, could use some feedback from us.<br>
<fantasai> gregwhitworth: I'm excited about this topic<br>
<fantasai> gregwhitworth: Prefer the aspect-ratio syntax from MQ<br>
<TabAtkins> (I've given some feedback, I think it's pretty decent.)<br>
<fantasai> gregwhitworth: We also did talk about aspect ratio in picture elements<br>
<tantek> +1 I'm excited to see aspect ratio solved<br>
<fantasai> gregwhitworth: I think we'd like an HTML solution because we want to do it earlier<br>
<fantasai> gregwhitworth: but of course also in CSS too<br>
<fantasai> gregwhitworth: Interested in the other stuff<br>
<fantasai> gregwhitworth: We have a WICG thread under ? for asect ratio that has additiona issues to think about that we should think about<br>
<TabAtkins> (Ojan's proposal is *just* about setting intrinsic sizes of replaced elements that *already have* aspect-ratio information. Not directly intersecting with the 'aspect-ratio' property.)<br>
<florian> fantasai: in terms of adding attributes to HTML, we were looking at this, and thinking we can just do that using the height and with attribute<br>
<florian> fantasai: currently, they link to the width and height property, so you loose them when you set the css properties<br>
<florian> fantasai: but we could change that, to make them also plug into the aspect-ratio property<br>
<florian> fantasai: so if you set them in css, you'd override the width/height, but not the ratio<br>
<florian> fantasai: we might be be able to do that in a web compatible thing<br>
<florian> fantasai: so before we add more to HTML, we should look into whether we can do that mappinng in the CSS layer<br>
<fantasai> glazou: I really like that<br>
<fantasai> glazou: Two things I'd like to know<br>
<fantasai> glazou: First, when we have for some elements a placeholder to display until the element isloaded from the network, we are going to have a cahnge of aspect ratio<br>
<fantasai> glazou: So it would be good to detect that the aspect ratio is changing from some external source like the network<br>
<fantasai> glazou: About your a) nand b) rpoposals for the limits<br>
<florian> q+<br>
<fantasai> glazou: from-ratio won't allow partial value sunless you allow into calc(), so I would prefer th eunit<br>
<franremy> q+<br>
<TabAtkins> (The point of doing *some* aspect-ratio things in HTML is, as Greg suggested, to be even more preloader friendly.)<br>
<fantasai> futhark: For the min-height problem, try min-max aspect ratio<br>
<fantasai> fantasai: We thought about it, but though tthis was mroe stragithforward and easier to understand<br>
<fantasai> fantasai: what's a min-aspect ratio? would ahve to privilege one dimension over the other<br>
<fantasai> gregwhitworth: ....<br>
<fantasai> astearns: Might want to limit current discussion to concerns about whethe rto add to the draft<br>
<krit> q+<br>
<fantasai> florian: based on what you said, I'm happy to move this forward<br>
<astearns> ack florian<br>
<astearns> ack franremy<br>
<dbaron> I think I prefer option A over B, for being clearer, and I think we should eventually get from-ratio into calc()<br>
<fantasai> fremy: I would say that from-ratio seems way easier to implement<br>
<fantasai> fremy: ???<br>
<fantasai> fremy: Among the two solutions, an implementatio nperspective from-ratio is way easier<br>
<fantasai> fremy: That's all, not opposed to the unit<br>
<fantasai> fantasai: Note that this unit exists already for gaps, we're just copying that solution here<br>
<TabAtkins> q+<br>
<fantasai> krit: Shoudl look at preserveAspectRatio attribute<br>
<fantasai> florian: I think parallel between preserveAsepctRatio is with the 'object-fit' property in CSS<br>
<fantasai> florian: Some aspects of viewbox correspond to this<br>
<fantasai> florian: My first impression is that even if we add as properties the things that SVG already has<br>
<fantasai> florian: These things an this, have a shorthand-longhand relatioship, so there's no conflict<br>
<astearns> ack krit<br>
<fantasai> florian: We need to think through it but there's no conflict<br>
<fantasai> jensimmons: If you look at issue 333, I've dropped links to authors writeups on aspect ratios<br>
<fantasai> jensimmons: So we need to go through all that and make sure we've thought about those comments and ideas<br>
<fantasai> astearns: What about SVG?<br>
<astearns> ack TabAtkins<br>
<fantasai> jensimmons: Sara Soueidan wrote up a blog post on viewport in CSS<br>
<fantasai> TabAtkins: I am in favor of doing this<br>
<fantasai> TabAtkins: I want to put it WICG<br>
<fantasai> florian: Let's incubate in the CSSWG like we always do<br>
<fantasai> astearns: I'm going to close the discussion at this point.<br>
<fantasai> astearns: It's break time<br>
<fantasai> https://www.w3.org/TR/2018/WD-css-grid-2-20180804/#alignment<br>
<fantasai> ar units ^<br>
<astearns> FYI: Chris and Lea are out at a hospital today, Lea's health took a turn for the worse yesterday evening.<br>
<myles_> ScribeNick: myles_<br>
<myles_> ::people fuss with the AV setup::<br>
<TabAtkins> https://drafts.csswg.org/css-shadow-parts/<br>
<myles_> TabAtkins: we discussed shadow parts in the past, fergal_daly worked closely with rniwa to figure out hwo we can get a consensus solution on some details. It went well, made amny changes and feedback. Notable: we separated the naming of something as a part from forwarding something's parts up into your part namespace. They're now separate attributes. Chagned syntax of part forwarding to match JS syntax for desctructuring because it's the same. While it's<br>
<myles_> eays to get confused about whch name does what in JS destructuring, \people only have to learn it once. wen're not exposing ssomethign new and novel. Functionality is the same - can expose chunks of shadow dom<br>
<fantasai> s/eays/easy/<br>
<myles_> can't do further structuring, can't grab a part of a part, unless it's exlicitly forwarded, can do before and after<br>
<myles_> and other pseudoclasses<br>
<myles_> there are still some discussion about theme<br>
<myles_> the thing that automatically exposes your parts arbitrarily up so they can be used from anywhere. further discussion is ongoing but the core part, the part pseudo element and how to expose it appears to be reasonably agreed on by us and apple<br>
<TabAtkins> s/before and after/::before and ::after/<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2368<br>
<myles_> rniwa: there is consensus on the github issue. the 1 contentious part is the IDL attribute. for now we can add itand move foward. one question is because the topic of whether par tapplies to jsut hte first elemtn or everything? For theme, clearly allt he elements with the theme should ge tthe style, not jsut the first one. so the discrepancy there might be confusing. but on tehother hand, the use cases are different it may be okay that only the first elmetn<br>
<myles_> gets the first the styl<br>
<myles_> TabAtkins: so it's treated like an ID?<br>
<emilio> q+<br>
<myles_> rniwa: it's a question. Let's say shadow root has 2 elements that have a part attribute, boht say part=foo. Sholud both get the style? If the model is users are exposing an element to to outside to style, then it should be just one element. but if hte model is more like the users define style for a part and the compoent takes it form the users and apply somewhere, then it akes more sense for multiple elements<br>
<myles_> TabAtkins: imagine a to do app. you want to expose for styling all of the indiviaul to do items. You can give them the same part naem and style them all, it works like a class. If you can only do one, each item would need a unique name.<br>
<astearns> ack emilio<br>
<myles_> emilio: that's better. I prefer to style the style of elements to be independent<br>
<myles_> emilio: validation could be tricky. When you insert an element with a part element, you have to look for hte same part naem elsewhere in the tree<br>
<myles_> rniwa: that's fine.<br>
<heycam> s/validation/invalidation/<br>
<myles_> rniwa: it's just a question. i dont' know the answer.<br>
<myles_> TabAtkins: the goal of the session is to confirm we hav rough agreement on the feature set. earlier there were more disagreement. so i don't think we're ready for FPWD now but we can adopt as official ED.<br>
<myles_> astearns: i dont' remember if its an EN<br>
<myles_> TabAtkins: it's marked as an ED><br>
<myles_> TabAtkins: so we're pretty good. comments?<br>
<myles_> TabAtkins: please raise issues.<br>
<myles_> astearns: i suggest - the issue is a monster issue with many sub issues. if there's anything remaining, please move it to new issues. It's impossible to read.<br>
<myles_> TabAtkins: ok.<br>
<myles_> TabAtkins: we did already<br>
<myles_> fergal_daly: please use existin issues<br>
<myles_> astearns: sometimes TabAtkins will move comments for people<br>
<myles_> fergal_daly: i'll do that then.<br>
<myles_> fantasai: what are you looking for before FPWD?<br>
<myles_> fantasai: FPWD doesn't mean it's done. it' means it's rough<br>
<myles_> fantasai: and we have consensus on the approach, but not details. We don't have to fix the issues<br>
<myles_> TabAtkins: it coule be reasonable to do FPWD<br>
<myles_> fantasai: if there are no major issues before FPWD and we all agree we want to do it, we should do FPWD<br>
<myles_> fantasai: and continue work with more visibly public draft<br>
<myles_> fergal_daly: should we take theme if we haven't decided on it?<br>
<myles_> TabAtkins: i'd be okay.<br>
<fantasai> s/theme/theme out/<br>
<myles_> rniwa: it makes sense. we need to update the spec. the ED is outdated.<br>
<myles_> rniwa: remove the theme and the IDL attributes<br>
<myles_> fergal_daly: IDL is already out.<br>
<myles_> TabAtkins: yes.<br>
<myles_> TabAtkins: right nwo the only way to access parts is to ge tthe attrigbute using the standard dom api<br>
<myles_> fergal_daly: is there controversary for adding IDL for part as opposed to part fowarding? That's useful for feature detection<br>
<myles_> rniwa: no controversy. It's okay to epxose part IDL attribute.<br>
<myles_> fergal_daly: okay i'll do that.<br>
<myles_> fergal_daly: and leave otu the map stuff completely<br>
<myles_> TabAtkins: it might be worthwhile to officially do FPWD in a few weeks.<br>
<myles_> astearns: yes, i'd liek to see people sign off on the state of the draft before FPWD<br>
<myles_> TabAtkins: ok<br>
<myles_> fantasai: for extracting out the stuff we're not doing now, maybe throw that into L2<br>
<myles_> TabAtkins: ok<br>
<myles_> s/L2/Level 2/<br>
<myles_> TabAtkins: we can incubte the theme attribute.<br>
<myles_> astearns: other comments?<br>
<myles_> rniwa: mozilla support?<br>
<myles_> emilio: it's reasonable<br>
<myles_> emilio: when peopel askfor feedbakc, the conclusion iwas it's worht experiementing. the current agreed on thing makes sense<br>
<myles_> astearns: Edge signals?<br>
<myles_> TabAtkins: Edge just agreed to do shadow dom, so we'll see you in 6 months<br>
<myles_> astearns: next topic: i18n<br>
<gregwhitworth> I said that we'll take a look at the proposal and provide feedback at a later date<br>
<myles_> ::people cast around for short topics while we wait for i18n::<br>
<myles_> jensimmons: there is an issue for renaming the AR unit<br>
<myles_> jensimmons: it's in grid level 2<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2368#issuecomment-432161305 using your GitHub account
Received on Tuesday, 23 October 2018 09:02:40 UTC