- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Jul 2018 02:00:45 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `initial-letter vs float`, and agreed to the following:
* `RESOLVED: resolve as "won't fix" (no fixup) and add a note explaining what dbaron already mentioned above`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: initial-letter vs float<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/688<br>
<emilio> fantasai: so there's an issue of the interaction between float / initial-letter<br>
<emilio> fantasai: float blockifies an element, and `initial-letter` applies to that<br>
<emilio> fantasai: it was pointed out that you may want to use float as a fallback for initial-letter<br>
<emilio> fantasai: so we may want to ignore float if initial-letter is there as well<br>
<emilio> dbaron: florian: We should make initial-letter override float<br>
<emilio> heycam: you could use @supports<br>
<emilio> tantek: that's not enough because when you're actually trying to make it work you tweak other properties like font-size but also line-height<br>
<emilio> fantasai: font-size and line-height are ignored already<br>
<emilio> tantek: you also need margin<br>
<emilio> fantasai: that's not ignored<br>
<emilio> dauwhe: yeah, tantek is right<br>
<tantek> from view-source:http://tantek.com/2015/224/b1/alphabet-indieweb<br>
<tantek> .h-entry li::first-letter { float:left; margin:0.04em 1px 0 0; font-size:5.5em; text-transform:uppercase; line-height:0.8; }<br>
<emilio> florian: so margin is not covered but I think the compromise is reasonable if you're not trying to do pixel-perfect drop-cap both with and without first-letter<br>
<emilio> florian: you'd just not do the margin<br>
<emilio> Rossen: Let's get back to the issue at hand<br>
<emilio> Rossen: so tantek, you are against overriding float? or just saying that there's a bunch more?<br>
<emilio> tantek: not a lot, but just a few properties beyond float<br>
<emilio> florian: so for two of the three properties you want to cover it's fine already, for the rest you have @supports<br>
<emilio> florian: because the margin hack you may do I think it's still useful for initial-letter to override floats<br>
<emilio> tantek: I don't think you can make the initial letter look good without margin<br>
<emilio> fantasai: so you're arguing we shouldn't make the change?<br>
<emilio> fantasai: [re-states the proposal]<br>
<emilio> emilio: so you'd make an inline with `float: !none`?<br>
<emilio> dbaron: emilio: We want initial-letter to turn float to none<br>
<fantasai> fantasai: The current state is that computed value rules for 'display' cause a element with 'display: inline' with 'float' not 'none' to turn into 'display: block'.<br>
<frremy> ScribeNick: frremy<br>
<frremy> emilio: can we determine if initial-letter applies based on the box type only?<br>
<fantasai> fantasai: The proposal afaict is that if 'initial-letter' and 'float' are set on a 'display: inline' element, it won't compute its 'display' to 'block'. Thus 'initial-letter' would apply and 'float' wouldn't.<br>
<fantasai> (this comes before dbaron/emilio's statement)<br>
<frremy> emilio: I think we should make the rule as dumb as possible<br>
<frremy> emilio: even if this is a block, initial letter turns off float<br>
<frremy> TabAtkins: I agree, we should recomment authors use at-supports<br>
<frremy> tantek: a simpler rule would also make it clear to authors they should use at-supports<br>
<frremy> TabAtkins: we could add a note to the spec<br>
<frremy> dbaron: and it's also very likely people will not use initial-letters on things where it should not apply<br>
<frremy> Rossen: I believe this (?) should be the same rule<br>
<frremy> dbaron: I advocated for fixup before<br>
<frremy> dbaron: I am fine with no fixup in place<br>
<frremy> dbaron: but then I argue for a note that says that if you set float, then intial letter won't apply<br>
<frremy> tantek: simple fixup that forces float to none helps authors to debug using devtools<br>
<frremy> emilio: even now the display fixup order is not fully interoperable<br>
<frremy> emilio: so I'd prefer no fixup to not muddle fix further<br>
<frremy> Rossen: no fixup is better for implementers, I agree<br>
<tantek> would also slightly prefer no fix-up, can live with simple fix-up that is reflected in the value for the property shown in devtools so that it is more easily debugged by authors<br>
<frremy> dauwhe: I don't have a strong opinion, but it would be nice to have an example in the spec to make things clear<br>
<frremy> Rossen: the only good reasoning for fixup was be compatible with existing code, but now we have at-supports so authors should just that<br>
<frremy> Rossen: so, any objection to resolve as "won't fix" for now and add a note explaining what dbaron already mentioned above?<br>
<frremy> RESOLVED: resolve as "won't fix" (no fixup) and add a note explaining what dbaron already mentioned above<br>
<frremy> tantek: note?<br>
<frremy> astearns: yes, because the confusion dbaron was worried about was for implementers<br>
<frremy> dbaron: yes, note is fine<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/688#issuecomment-402585401 using your GitHub account
Received on Thursday, 5 July 2018 02:00:48 UTC