- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Nov 2018 18:06:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Draft line-box-contain proposal`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Draft line-box-contain proposal<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3199<br> <dael> fantasai: We talked about having a prop that does roughly this. Some control over height of line calc. Been discussed since before my time. dbaron had interesting proposals for how to do it<br> <dael> fantasai: Know we need 3 behaviors: now, quirks mode, and consistant lines people want<br> <dael> fantasai: Drafted rough proposal with behaviors talked about.<br> <fantasai> https://drafts.csswg.org/css-inline-3/#line-sizing-property<br> <dael> fantasai: Wanted to ask WG if we want to work on this? Add something? I think need to add to inline spec, this is a rough draft.<br> <dael> fantasai: I think we need to add a property that does something smooth with a syntax<br> <dael> fantasai: Vague, but I wanted a start<br> <dael> myles: Been thinking about this for a while and I don't know right approach. Need backwards compat, but mode switches are confusing and multiple ways to solve line-height is extra mantanence and makes web more complicated. Not sure right way to do this<br> <dael> florian: Hard time seeing anything but a mode switch here. Not sure we need that many values, I'd rather 2. One does legacy or quirk depending on mode and the better behavior. Others listing leave out until proven<br> <dael> fantasai: The 'better behavior' says [reads]<br> <dael> fantasai: It might be possible to slip that in without breaking too much. Any ledding is too much. It's possible that wont' break anything<br> <fantasai> q+ dbaron<br> <dael> myles: Not saying mode switch bad. More frustration about where we got to. Also, want to say this is one of the most requested features from people that care about text. Great to solve. We're between a rock and a hard place<br> <fantasai> s/Any ledding/Any leading/<br> <dael> dauwhe: I will use it as soon as it exists<br> <Rossen> q?<br> <fantasai> s/is too much/would break, but only eliminating positive leading might be possible/<br> <dael> Rossen: Where do we work on it?<br> <dael> dbaron: A few comments<br> <Rossen> ack dbaron<br> <dael> dbaron: I think there is an alternative to mode swhich is new syntax to line-height. Mode switch-like, but not as bad in some ways<br> <rachelandrew> I seem to only have mic issues with WebEx, need to figure out why as I use this setup for podcasts with no issue.<br> <dael> dbaron: May need >1 new value. bunch of use cases for things like images in a line and in default you want images to change line height, but there are cases where images within a line and do not want a change because images are roughly the size of the text<br> <dael> fantasai: In terms of new keywords for line-height for ergonomics a mode switch is better. Line-height you're talking about quantity of space, not the mechanism by which you want to measure. It's a separate thought in how you want to do it.<br> <dael> fantasai: You want the good line height calc on the whole page and forget it. Same way as box sizing is done. I used to think it was a mistake, but the way we did box sizing was originally almost always wrong. Webdev would rather set it once on a style sheet.<br> <dbaron> I actually disagree about box-sizing, since I think it depends whether you care about the inside-size or the outside-size<br> <dael> fantasai: This is similar. You almost never want to switch. You want to set at the top and you don't want to think anymore. If you put it in line-height you have to think every time you change the line height<br> <dael> myles: Would a mode swtich change the way line-height is inherited?<br> <tantek> yes it was certainly my intent when I proposed box-sizing that it was a "just fix it so things work like I expect across all the things box related"<br> <myles> s/inherited/inherited or how it applies to only block elements and not inlines/<br> <dael> fantasai: Various behaviors prop. One that would fix most problems would be to change it so line-height is ignored on all inline elements. They just have a line-height of 1 effectively.<br> <dael> fantasai: Had to modify so if you set line-height <1 we add negative leading so your effect is honored<br> <dael> fantasai: Not that it doesn't apply, just only applies if negative leading. Applies to root and then applied to every line. As long as you're in that space, if the sizing box fits, it doesn't increase height of line or move it<br> <dael> myles: Any precedent for that type of behavior?<br> <dael> myles: I mean changing the behavior of a prop based on another prop. Not sure how I would impl<br> <myles> Rossen: sorry! i didn't realize the time<br> <dael> Rossen: Sorry to interrupt. We're 4 minutes overtime. I want convo to continue, but I want to let everyone else go. We won't resolve, but convo should continue<br> <gregwhitworth> scribenick: gregwhitworth<br> <gregwhitworth> oh<br> <gregwhitworth> lol<br> <dael> myles: I have to go too.<br> <dael> fantasai: Schedule a separate call about this<br> <dael> Rossen: Good idea<br> <dael> Rossen: Focused group would be good. I'll send an email to private list to see if we can get folks<br> <dael> fantasai: I can sent<br> <dael> Rossen: Have a great Thanksgiving for those of you celebrating. Talk to you next week.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3199#issuecomment-440760435 using your GitHub account
Received on Wednesday, 21 November 2018 18:06:20 UTC