[css-inline] Should first/last baseline values of vertical-align belong to alignment-baseline or separate longhand?
#861
Labels
Comments
|
OK, so we resolved in having them space separated in https://lists.w3.org/Archives/Public/www-style/2016Oct/0130.html The remaining question is whether they should be incorporated into the |
fantasai
changed the title
vertical-align belong to alignment-baseline or separate longhand?
|
I'd note the link in the initial comment here is to |
|
@dbaron Only alignment-baseline. I"ll edit the link... |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: aspect-ratio and width/height attributes<argyle> elika not you <fantasai> ScribeNick: argyle <argyle> there we go <argyle> florian: my understandin as that we all agreed this would be a goo didea if possible, and we should check if possible <argyle> tab disagrees, i want to hear that <argyle> for context: "it" is using the width and height of attribtues to trigger the intrinsic aspect ratio <argyle> elika: specifically, where we map the width and height to width and height props, we could also use them to calc the ratio back to css <cbiesinger> s/elika/fantasai/ <argyle> that would solve the problem around the aspect ratio information would be lost due to waiting for the image to load, waiting to discover auto sizing <AmeliaBR> s/that/...that/ <argyle> so the proposal was to introduce attributes to solve the same problem <argyle> rosson: was is the data we need to gather then <fantasai> s/was to introduce/was to do that instead of introducing new/ <argyle> florian: so we dont break the web <AmeliaBR> s/so the/...so the/ <argyle> rossen: for the width and height <argyle> florian: do we not agree? <Rossen> s/rossen/Rossen/ <argyle> tab: having width and height be presentation attributes, and no affecting those new and exciting ways <Rossen> s/tab/TabAtkins/ <argyle> tab: the other reason i liked it, some of the other things, like picture, you wanted to give an intrinsic size to them, and tab feels semantically better to be specific about being intrinsic than doing css things that also set intrinsic sizes. <argyle> florian: there's no intrinsic tools to do this <AmeliaBR> +1 to Tab's argument about `<picture><source intrinsicsize="...">` making more sense than width & height <argyle> miles: what about canvas <argyle> miles: we should consider the interaction with canvas where w and h have other meanings other than mapping to css <cbiesinger> s/miles/myles/ <Rossen> q? <Rossen> ack dbaron <argyle> rosson: david, you're on the queue <fantasai> s/miles/myles/ <fantasai> TabAtkins: It sets the backing store on width/height, which is compatible <argyle> david: ... if this is a, major thing sites can do to improve loading, if a cms can just do this, that's great, and it means that lots of sites can get it cheaply <argyle> david: i think, if it's it's won attr() it can do that, i dont think we .. <fantasai> s/won attr()/own attribute/ <fantasai> s/i dont think we/I don't think it's as safe to do if we're re-using width and height/ <argyle> florian: if the cms wanted to check if there was previously a width and ehight, they could still inject the w/h and multiply by whats needed, but they also need to check minheight and maxheight, and then it gets messy <argyle> alan: we're theorizing about things Ojan has experience in, at the most this conversation should inform what he continues to do as he tries to find a solution <Rossen> q? <argyle> alan: but i'm not sure i see the utility of theorizing when we have an experimentor <argyle> florian: utility is we dont need to experiment if we have other demos, not worth checking if we dont want to do it anyway <xfq> ack jen <argyle> rosson: go ahead jenn <cbiesinger> s/rosson/rossen/ <argyle> jenn: i think the original intention behind what elika was saying, here's an idea, might be much simpler than adding attributes, we'd like this considered <TabAtkins> `<style>img { width: 100%; }</style> <img intrinsicsize="350x450">` works by default. Changing it to <img width=350 height=450> doesn't work; you have to manually set `height: auto` in CSS too. <argyle> jenn: i do think there's a way to do it that hooks into cms's and existing things, instead of making it more complicated <astearns> s/jenn/jensimmons_ / <skk> s/alan/astearns/ <argyle> jenn: if only width is coming out of a cms, and there's no height, there's no mapping to intrinsic, we can map with that limited data <argyle> jenn: maybe there's something more complex needed, and we do both, i think there's an elegance here tapping into what we already have. perhaps that's what ojan is intending <argyle> jenn: hey, we're going to solve some of this in css, and to have that really heard, .. that's what i'd like to see happen <argyle> rosson: where does this leave us <astearns> s/rosson/Rossen / <argyle> jenn: sounds like someone's going to find something out <argyle> (thanks for the correction y'all!) <argyle> (thanks for the corrections y'all!) <argyle> amelia: i think it's great, we're leveraging something that already works, but i think i agree with the arguments there's too many cases where things can get messy for repurposing <argyle> amelia: if browsers implemented the attr function that values to lengths, ... any image, grab these values, put them together, here's the ratio <argyle> amelia: not sure if there's utility if no one's has implemented it yet <jensimmons_> +1 to what AmeliaBR just said <jensimmons_> maybe that could even be included in a project called CSS Remedy <argyle> tab: i feel like there's just more discussion, but in the way of being explicit with cases and approaches, and i dont know if i want to spend time trying to nail it down <argyle> elika: there are advantages of usign existing attr(), like for images out there, we get the faster layout/loading for free. info is already there <argyle> no updating cms, no html file updates, it would let them hook into it via current functionality <AmeliaBR> s/attr()/attributes/ <argyle> jenn: there's 100's of sites that put height and width on things. then in their code, height 100% in their code. decade of work built that way, and likely arent maintained <fantasai> s/100's/100,000s/ <argyle> jenn: quick way to boost all sites <astearns> s/on things/on images in the cms/ <argyle> jenn: don't get deep into picture element, ..., hey this is a performance thing, but it back in and it'll be faster <argyle> jenn: other proposals will use it for be used for simple and complicated things, and some it'll be too much <astearns> s/height 100%/width 100% height auto/ <argyle> elika: historically, we've asked users to put weight and height on them, back into the 90s, and hooking into that advice, it hooks into content and knowledge better. it wont just work on new things for people keeping up with latest things <argyle> tab: happy to do more discussion, but not confident enough to decide now, or for us <argyle> chris: maybe we could break out and talk about it? <astearns> s/chris/chrishtr / <argyle> chris: i dont think i fully understand, and I'd like time for that <argyle> rossen: ok so, i didnt hear that say the HTML width and height attributes is the worst idea i've ever heard, we shouldnt do it <argyle> rossen: i also didnt hear we shouldnt think about the intrinsic aspect ratio, because it'll just work <argyle> rossen: tab has committed to work on this fully <argyle> tab: chrome people will be working on this <argyle> rossen: kidding aside, we'll close this issue for now. thanks for introducing it to the working group, and making it an actual proposal <argyle> rossen: i think there was another bit in this, which was css property, which will then have to map using either the height or width attributes, as a ratio, or whatever else is there, if anything is added as an additional attribute <argyle> rossen: i think the property can be discussed at a later point, or is this something you want to discuss later today <argyle> elika: it's already in the draft <fantasai> s/elika/fantasai/g <argyle> jenn: so this discussion about not doing other things in HTML, the stuff we've already talked about, there will be more to talk about aspect ratio with min-height and min-width <fantasai> s/jenn/jensimmons/g <AmeliaBR> q+ <argyle> jenn: there is a question of: do we put in what's there already in the draft, support for ??, whether it's happening int he UA style sheet, we do have the ability to grab information about height and width <argyle> jenn: might be right inbetween, and i think we should do what rossen mentioned <argyle> rossen: great point, thank you. before we move on <Rossen> ack AmeliaBR <argyle> amelia: i have a question: it's not being proposed by a web group. before we get a css spec, we need to get that moving up into the HTML wg, so it's outside our scope, so long as it's going through process and getting standardized. chrome pushed it without standarization, we need to make sure that happens <astearns> TabAtkins: definitely should be in wicg - we'll get it there <argyle> rossen: topic, css inline, first and last baseline <astearns> github: https://github.com//issues/861 <argyle> dauwhe: no opinions <argyle> elika: this issue keeps coming up because i dont have any points in favor or against either options, and i'd like to hear why we should pick one over the other <argyle> fantasai: do we have the board, do you want the [..] baselines, fantasai explains the problem <argyle> fantasai: once you match the baselines, you shift <argyle> fantasai: once one of those has multiple lines in it, what do we do <argyle> fantasai: do we put it in it's own properly, align baseline preference, and it cascades independently, .. continues explaining <argyle> AmeliaBR: reminder: long hands exist for legacy compat. so svg had align, baseline shift, css had vertical align.. they descirbe the same functionality but behave slightly differently <argyle> AmeliaBR: ..., adding new features to the long hand, when it's just for compat, seems questionable. also, not sure how first/last would work in SVG. i dont see benefit there <astearns> [fantasai outlines things on the easel] <argyle> fantasai: we cant add values to the short. so it there's a reason to choose one over the other, it'll help us resolve <argyle> AmeliaBR: new property may not be used <argyle> fantasai: related issue: from the MATH ML folks, they want to take the baseline not from the first or last item, but from a specific item <argyle> fantasai: so that ties in a little bit with this, we dont have a proposal, but we have an idea we should do it. so that might tie into we end up with another that helps us solve this as well <argyle> AmeliaBR: i suppose the value of a new property is that vertical align is already supported with current functionality <argyle> AmeliaBR: you may end up with duplication anyway <argyle> fantasai: does anyone want to think about it more, or push it off to the next <argyle> dbaron: i can imagine there's reasons you want them separate, unknown how important they are. consider multiple languages.. <argyle> fantasai: alright, we can resolve the issue <argyle> dbaron: i'm not convinced anyone will want to do this, but it does seem like a good thing to do <argyle> AmeliaBR: resolve to make a new long form property <argyle> astearns: we figure the name out later <argyle> fantasai: no matter how silly, make suggestions <fantasai> s/suggestions/suggestions in IRC, we'll evaluate later/ <dbaron> dbaron (earlier): you might want to set alignment-baseline as a function of the language without messing with the first/last choice set for other reasons <argyle> Rossen: ok, any other opinions that can top David Barons? <argyle> Rossen: anyone object to david? or oppose? <argyle> Rossen: no objections. resolved. <argyle> astearns: so, david, could you put your actual suggestion into resolve line <argyle> dbaron: the question was a boolean, do we want a separate prop or not <argyle> RESOLVED: we'll add a separate property for this <argyle> astearns: great <argyle> fantasai: thank you <argyle> Rossen: next one is an awesome one <emilio> ScribeNick: emilio <florian> github: none <Rossen> github: https://github.com//issues/861 |
fantasai
added
Closed Accepted by CSSWG Resolution
Needs Edits
and removed
Needs Feedback/Review
labels
fantasai
added a commit
that referenced
this issue
May 22, 2019
|
Edits committed. Went with |
|
Please file new issues for any follow-up, renaming, missing details, etc. :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Do we need to add first and last to baseline values?
Note, in this property, these are combinatorial, whereas in the align/justify-self/content properties, it’s singular. Do we want to align the syntaxes wrt hyphens vs. spaces or what?
The text was updated successfully, but these errors were encountered: