- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Aug 2017 16:59:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `baseline alignment`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: baseline alignment<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/1039<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/1039<br>
<dael> fantasai: This one is an issue where the handling of baseline alignment in terms of how it effects intrinisic track sizing wasn't weel spec. I checked in changes, I'm asking for review at this point.<br>
<fantasai> https://drafts.csswg.org/css-grid/#algo-content with <ins> as green text<br>
<dael> fantasai: I just wanted to announce that. Impl should see if they fix the issue. THe changes are green text in the spec.<br>
<dael> fantasai: Just a request for review. Hopefully resolve next week.<br>
<dael> Chris: We'll leave the agenda+ on this one.<br>
<dael> Chris: We have 10 minutes left. What would people like to do?<br>
<dael> fantasai: There was a sizing issue.<br>
<dael> fantasai: Suggestion we should have a shorthand for both width and height.<br>
<dael> fantasai: Obvious would to use a size property. Problem is we have an @page size descriptor and they behave just like properties.<br>
<dael> Chris: It should be a problem for a descriptor and property to have same name. We have that, right?<br>
<dael> TabAtkins: No.<br>
<Chris> s/should/shouldn't/<br>
<dael> TabAtkins: You have a width and a heigh descriptor on @page rule. You also have a size, but it does not behave like this propsal.<br>
<dael> fantasai: Options are come up with another name or deal with that they have the same name and this might be a little awk in some impl.<br>
<dael> plinss: Size descriptor, does that interact with width and height?<br>
<dael> TabAtkins: Orthogonal<br>
<dael> fantasai: Not really. Page isze is a size in whch you put the box and width and height desc the content box.<br>
<dael> plinss: I'm wondering if we can't redefine the size in the page [missed]<br>
<dael> fantasai: Size defines the margin box and width/height are content box<br>
<dael> TabAtkins: And the part of the grammer exsits in the size descriptor. You can put @page { size: 6in 9in } and it looks exactly like the size shorthand for width and height.<br>
<dael> Chris: So we've talked ourselves to this won't be a conflict.<br>
<dael> TabAtkins: No, the opposite. There will be a conflict.<br>
<dael> Chris: Got it.<br>
<gregwhitworth> How much is @page size descriptor used? Anyone know?<br>
<tantek> good q gregwhitworth<br>
<gregwhitworth> I know whatever we call this shorthand it will be used a ton<br>
<dael> fantasai: I feel like it's probably okay. But it is a q where impl will have different handlings for parsing in size when it's parse in for @page and that could be tricky.<br>
<Chris> in print stylesheets, obvs. for paper selection I imagine<br>
<fantasai> gregwhitworth, it's used a lot in the printing world<br>
<dael> TabAtkins: It's tricky for impl and confusing for authors if they use @page ruel.<br>
<fantasai> gregwhitworth, e.g. by CSS->PDF it's almost always used<br>
<gregwhitworth> good to know fantasai<br>
<dael> Chris: Can we come up with a different name?<br>
<gregwhitworth> dimension?<br>
<dael> TabAtkins: I'm kind for box property. That makes it easy to fold box sizing into the short hand.<br>
<dael> fantasai: I don't think you want a size property that resets box sizing. People set box sizing and just want to leave it. IF you have a shorthand that resets it it won't be useful.<br>
<jensimmons> +1 to what Elika just said<br>
<tantek> fantasai's observation is correct IMO<br>
<gregwhitworth> wh<br>
<tantek> what fantasai said is the path of least surprise<br>
<fantasai> s/leave it/leave it and pretend that we had border-box sizing from the beginning/<br>
<dael> TabAtkins: Sometimes. Sometimes they want to reset it and doing it in one property is great. But I see your argument.<br>
<dael> Chris: I tend to agree with fantasai.<br>
<dael> Chris: There's 4 minutes. Any bright ideas?<br>
<dael> Chris: Sounds like not.<br>
<dael> Chris: Anything to talk about in 3 minutes?<br>
<gregwhitworth> We have cx and cy<br>
<gregwhitworth> why not wh?<br>
<dael> fantasai: We should figure out something here and do it.<br>
<gregwhitworth> I don't like it, but...<br>
<fantasai> s/We should/We definitely have authors who want this shorthand to exist, so we/<br>
<dael> Chris: gregwhitworth was that serious or trolling?<br>
<dael> gregwhitworth: I don't know.<br>
<fantasai> s/so we/so we should/<br>
<TabAtkins> Those names are legacy from svg, we'd never name them that fresh<br>
<dael> gregwhitworth: I can't think of anything becides dimension and size that make sense.<br>
<dael> Chris: I agree with TabAtkins. We have thos because we were going for short attribute names.<br>
<dael> Chris: Okay. no bright ideas.<br>
<dael> Chris: Let's leave it open.<br>
<fantasai> area?<br>
<gregwhitworth> proportion<br>
<dael> Chris: We'll discuss on Github.<br>
<gregwhitworth> lol, same here fantasai<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1039#issuecomment-322835252 using your GitHub account
Received on Wednesday, 16 August 2017 16:59:35 UTC