Re: [css-inline] initial-letter in WebKit (feedback after implementing)

On Sep 5, 2014, at 7:36 AM, Dave Cramer <dauwhe@gmail.com<mailto:dauwhe@gmail.com>> wrote:

On Wed, Sep 3, 2014 at 3:46 PM, David Hyatt <hyatt@apple.com<mailto:hyatt@apple.com>> wrote:
I have added basic support for initial-letter and wanted to provide some feedback after implementing it. Note I don't handle ideographic baselines yet, nor do I handle vertical text. The property is also only applicable to ::first-letter at the moment, so confine your testing to examples using only ::first-letter.

Thank you so much for doing this. It was a wonderful moment when I downloaded WebKit nightly and saw initial-letter working!


Here is my feedback after implementing this property:

(1) initial-letter should become a shorthand for initial-letter-drop and initial-letter-height rather than staying a single property that specifies two distinct values.

I'm fine with this. This would not be a typical shorthand, as an omitted value would not use the initial value of the longhand property. We do want initial-letter: 3 to mean initial-letter-size: 3 and initial-letter-drop: 3.

Well, if the most common use-case is for one property to match the other you could have initial-letter-height's initial value be 'auto' and resolve to initial-letter-drop?


Using only one longhand might result in some interesting results, depending on the initial values (see below). Having initial-letter-drop to be 2 or 3 without a corresponding initial-letter-size would result in a small dropped letter. Let's hope that doesn't become a design trend!


(2) The draft says the initial value is "normal" and yet this isn't listed as an allowed value in the grammar (which simply shows 1 or two integers). I implemented "normal" and interpreted it as "off", i.e., a special value that means ignore the property completely and just keep first-letter behavior the way it is now in shipping browsers.

On further reflection, I wonder if "normal" is necessary, or if the initial values could just be "1". If initial-letter-drop is "1", then the initial letter should sit on the first text baseline, which it would do anyway. And if initial-letter-size was "1", then the character should extend from the baseline to the cap height of the same line, which it would do anyway.

FWIW I think it's fine to have an explicit keyword for 'no dropcap positioning/sizing' vs. "1 means this is not a dropcap unless the height is not 1".



(3) The spec really needs to talk about where the borders, padding and margins are placed around the first-letter. I made the assumption that the first-letter extends above the baseline by cap-height and below the baseline by the glyph bounds, and so any borders and padding you put around the first-letter would snugly fit this area. Aesthetically this looked right to me (rather than putting the border/padding above the ascent and below the descent).

Example with initial-letter: 2 3;

<Screen Shot 2014-09-03 at 2.33.12 PM.png>

Yes, this looks right.

(4) Again, getting into border/padding, I assumed that you still align the cap-height of the first-letter with the cap-height of the line, even if the first-letter has border/padding. In the example above, you can see the letter is aligned and the border/padding simply "spill up", which means they possibly would overlap a previous paragraph. This is consistent with border/padding/margins on inlines themselves, and I think it's worth deviating from normal float behavior in this case. Here's another example showing what I mean (deliberately ugly just to prove a point):

<Screen Shot 2014-09-03 at 2.37.25 PM.png>


Yes. I think the key point is that we always align to the letter, regardless of margin/padding/border.

This does raise a question of whether lines should dodge the bottom border/padding of the float, or if they should overlap it. At the moment I'm still dodging bottom border/padding/margin. I am inclined to suggest that they should overlap, since it's consistent with normal inline text behavior with borders and padding.

I'm not sure about this, and would like to do some more testing. It's relatively common for drop caps to have a background color, which would extend out a bit from the letter. I've tried some of these and they look good, but I can also imagine cases where the usual inline behavior would be good (gradients, etc.).

Maybe I misunderstand but it seems awkward to have lines overlapping a border? Should it maybe behave similarly to margin collapsing rules i.e. overlap unless there is padding and/or border on the dropcap?