[css-inline] spec should define behavior when 'initial-letter' and 'float' both set on same element/pseudo-element

[dbaron]

The definition of initial letter styling should specify what happens when float and initial-letter are set on the same element.

Prior to the introduction of initial letter styling, CSS had two types of ::first-letter pseudo-elements: (1) regular inlines and (2) floats. Now (3) initial-letter creates a third, but I think it should be creating only one more and not two. In particular, I don't think there should be two different types of initial letter. (The spec certainly doesn't describe two such types.)

Then there's the question of, given code like:

p::first-letter {
  float: left;
  initial-letter: 3 3;
}

which one wins. That is, do we create a type (2) pseudo-element or a type (3) one.

I tend to think that if we want to allow authors to use various graceful degradation strategies (although they could do more with @supports, I suppose) it's probably better for the newer feature to override the older one, i.e., for the above case to result in the float: left being ignored.

Either way, this should be explicitly specified.

And I think that explicit specification should probably result in the computed value that is ignored being changed, although I haven't thought through the details of this at all.

[dbaron]

cc @chenpighead

[fantasai]

Currently, float values other than none are defined as causing display to compute toblock, and initial-letter doesn't apply to blocks, only to inlines. So the end result is you get a floated ::first-line pseudo-element if you specify both: float takes effect, and initial-letter-* is ignored.

@dbaron I think the float/display rules make this issue invalid. Please reopen if you think a different conclusion is needed.

[frivoal]

I agree with your conclusion that it is what happens given the current spec, but it seems to me that the opposite behavior might be helpful to let authors provide simple fallbacks without having to use @supports. Example:

p::first-letter {
  initial-letter: 3;
  float: left;
  line-height: 1;
  font-size: 3em;
}

Having this do a float-based drop cap in legacy browsers, and an initial-letter based drop cap in newer ones would sound great.

Also, it is what happens in Safari.

[fantasai]

@frivoal If we're doing that, then I'd want initial-letter to cause display to compute to inline in that case.

[frivoal]

@fantasai that sounds reasonable to me.

[css-meeting-bot]

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

The full IRC log of that discussion

<fantasai> Topic: initial-letter vs float
<fantasai> github: https://github.com//issues/688
<emilio> fantasai: so there's an issue of the interaction between float / initial-letter
<emilio> fantasai: float blockifies an element, and `initial-letter` applies to that
<emilio> fantasai: it was pointed out that you may want to use float as a fallback for initial-letter
<emilio> fantasai: so we may want to ignore float if initial-letter is there as well
<emilio> dbaron: florian: We should make initial-letter override float
<emilio> heycam: you could use @supports
<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
<emilio> fantasai: font-size and line-height are ignored already
<emilio> tantek: you also need margin
<emilio> fantasai: that's not ignored
<emilio> dauwhe: yeah, tantek is right
<tantek> from view-source:http://tantek.com/2015/224/b1/alphabet-indieweb
<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; }
<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
<emilio> florian: you'd just not do the margin
<emilio> Rossen: Let's get back to the issue at hand
<emilio> Rossen: so tantek, you are against overriding float? or just saying that there's a bunch more?
<emilio> tantek: not a lot, but just a few properties beyond float
<emilio> florian: so for two of the three properties you want to cover it's fine already, for the rest you have @supports
<emilio> florian: because the margin hack you may do I think it's still useful for initial-letter to override floats
<emilio> tantek: I don't think you can make the initial letter look good without margin
<emilio> fantasai: so you're arguing we shouldn't make the change?
<emilio> fantasai: [re-states the proposal]
<emilio> emilio: so you'd make an inline with `float: !none`?
<emilio> dbaron: emilio: We want initial-letter to turn float to none
<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'.
<frremy> ScribeNick: frremy
<frremy> emilio: can we determine if initial-letter applies based on the box type only?
<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.
<fantasai> (this comes before dbaron/emilio's statement)
<frremy> emilio: I think we should make the rule as dumb as possible
<frremy> emilio: even if this is a block, initial letter turns off float
<frremy> TabAtkins: I agree, we should recomment authors use at-supports
<frremy> tantek: a simpler rule would also make it clear to authors they should use at-supports
<frremy> TabAtkins: we could add a note to the spec
<frremy> dbaron: and it's also very likely people will not use initial-letters on things where it should not apply
<frremy> Rossen: I believe this (?) should be the same rule
<frremy> dbaron: I advocated for fixup before
<frremy> dbaron: I am fine with no fixup in place
<frremy> dbaron: but then I argue for a note that says that if you set float, then intial letter won't apply
<frremy> tantek: simple fixup that forces float to none helps authors to debug using devtools
<frremy> emilio: even now the display fixup order is not fully interoperable
<frremy> emilio: so I'd prefer no fixup to not muddle fix further
<frremy> Rossen: no fixup is better for implementers, I agree
<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
<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
<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
<frremy> Rossen: so, any objection to resolve as "won't fix" for now and add a note explaining what dbaron already mentioned above?
<frremy> RESOLVED: resolve as "won't fix" (no fixup) and add a note explaining what dbaron already mentioned above
<frremy> tantek: note?
<frremy> astearns: yes, because the confusion dbaron was worried about was for implementers
<frremy> dbaron: yes, note is fine