- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Oct 2014 14:08:58 -0400
- To: www-style@w3.org
Initial Letters
---------------
- RESOLVED: Publish FPWD of CSS-inline with initial-letter section
intact, and 2 prior sections pointing to appropriate parts of
2.1, with note that they will be updated.
- RESOLVED: initial-letter depends on line grid spacing or (if
none) line-height of containing block. Does not depend on
content of the lines.
- RESOLVED: initial-letter does not have longhands
- RESOLVED: Order of values is size first, drop second (as decided
in previous F2F)
- RESOLVED: size is a <number>. Alignment point is determined by
script.
- There were some unresolved concerns about the best approach to
handle initial-letters with combining marks.
- Discussed cases where the alignment subject should be the glyph bounds
vs. the margin-box bounds.
- Ruby's interaction with initial letter was also an area of concern.
==== FULL MINUTES BELOW ======
Scribe: fantasai
Initial Letters
---------------
dauwhe: To my surprise and delight, WebKit implemented initial-
letters last week.
dauwhe: We also got feedback from dhyatt.
dauwhe: There's a thread on www-style about that.
dauwhe: Firstly, we should have a WD, since people are doing this.
dauwhe: It's part of CSS Line layout, which is our oldest WD...
from 2002
dauwhe: Can we publish a WD of the whole thing?
fantasai: I think we just comment out the rest of it.
SteveZ: Put a note saying that the text is under development.
hober: Is there enough useful content in the old...
SteveZ: No.
SteveZ: There is useful content in the old stuff, but it's in an
inconsistent half-revised state
SteveZ: So it's really difficult to read unless you know what it's
supposed to say
SteveZ: That keeps the pieces together, but lets you get it out.
SteveZ: Leave sections 1 and 2, replacing text with a note.
hober: We want to publish a new WD of this thing, cool. In a thing
already had FPWD.
<dbaron> I think some of the problem was that back in 2003 I was
afraid of being too destructive of the material already
in the draft.
dbaron: Probably also another pass through for patent policy.
dbaron: So probably need another FPWD for patent policy.
hober: I'd like initial-letter to go through FPWD soon.
dauwhe: We talked about possibility of splitting it.
SteveZ: My suggestion for dealing with that is not to leave it
blank, but point to 2.1 as the most up-to-date description
of the content of these sections, and that it would be
updated
SteveZ: Well, point at appropriate sections of 2.1.
fantasai: You would want to make sure the first-letter clearing
behavior that we discussed at last f2f is in the spec.
dauwhe: Yes, it should incorporate all recent feedback.
[discussion of publishing vs. upcoming edits]
SteveZ: We can resolve on the plan.
RESOLVED: Publish FPWD of CSS-inline with initial-letter section
intact, and 2 prior sections pointing to appropriate
parts of 2.1, with note that they will be updated.
dauwhe: First issue is, should initial-letter be a shorthand for
initial-letter-size and initial-letter-drop?
TabAtkins: I think fantasai made a convincing argument that no,
they shouldn't.
florian: What was the argument?
TabAtkins: They don't want to cascade independently.
<florian> I then agree with Fantasai's point
<hober> Re: shorthand or not, what about hyatt's point in
<http://www.w3.org/mid/023DB250-5BFE-457E-8969-A42F8973DF70@apple.com>?
<astearns> hober: I believe the control he's talking about could
be addressed by allowing more than integers for the two
values
<hober> astearns: or at least a <length> for the height, yeah
SteveZ: I have an issue with the two things.
SteveZ: In looking through my collection of various documents from
various languages
SteveZ: The size really only works for Western alphabets and
doesn't really work for Indic, Thai, etc. Probably Tibetan
as well. These have stacked bits, so the size of something
varies.
SteveZ: You can't say the number of lines and figure out the font
size, it might not quite correspond.
Bert: If I say my letter is # lines high, then what if those lines
actually don't have all the same size?
SteveZ: I think you use the paragraph size.
dauwhe: ...
dauwhe: Use baseline grid, or set the line-height.
florian: Might want to draw distinction between content of line
making the line taller vs. using line grid
[dauwhe describes the circular dependency of initial-letter size
and number of lines if content is accounted for.]
florian: Does that take into account things like line-grid and
anything that can affect the line height other than
content of the line?
fantasai: I think we can resolve that it's using the line grid, if
using line grid; else line-height of paragraph.
SteveZ: Yes. Which is kind of an implicit line grid.
dauwhe: What's the term for that, line-height?
fantasai: 'line-height' of the containing block.
RESOLVED: initial-letter depends on line grid spacing or (if none)
line-height of containing block. Does not depend on
content of the lines.
hober: Next issue is for non-Western cases you probably want to
specify a length, not just number of lines, for cap-height
astearns: perhaps alignment as well, e.g. top-aligned.
fantasai: For CJK, I think Bobby Tung pointed out that you want
ICF Top or Bottom, not the em box or cap-height
fantasai: A lot of the font size tweaking for CJK is to get to the
ICF size, but we can calculate that from font metrics.
dauwhe: Probably needs to be language-dependent.
fantasai: In many cases might be script-dependent, not language-
dependent
SteveZ: Depends on conventions.
[of course]
dauwhe: We have formula for font-size in CJK, based on the
paragraph text size and number of lines dropped.
fantasai: I think he was just saying, you account for the gaps...
astearns: If there are adjustments needed.
hober: Yeah. And I think we can put a length there.
hober: We have 2 values, right now. If you put one, it gets
duplicated. What if 1 value is a length?
fantasai: I think you can have an auto value for the drop, and
that would calculate the drop from the length value
given in the size.
hober: Does that suggest we should switch the order of the two
values?
fantasai: maybe?
<fantasai> (probably, yes, size should be first)
<hober> IIRC in Seoul we had size first
<hober> not that that matters
<fantasai> Did the spec accidentally switch that?
<hober> yup.
[SteveZ shows an example of Kannada magazine article. The first-
letter is centered inside a box with a border]
SteveZ: The top of the box is what's aligned to the cap-height,
not the characters.
SteveZ: And the characters in the box are centered inside of that.
[astearns points out that the box is not really aligned to the
text though we could pretend they were trying]
SteveZ: We can tell that the emphasis is on the box, not the
character.
SteveZ: So trying to do something that's focused on the size of
the font in terms of lines, that might work well for
Western text, but not necessarily for other text.
fantasai: Depends on the effect you're going for. In Western text,
a fancy illuminated letter might have same behavior.
SteveZ: Might need to be able to specify the alignment.
<astearns> my suggestion for the box case is to use a line-grid
and box-snap the border box of a float to the grid
SteveZ: I'm wholeheartedly in favor for simple syntax for common
cases.
SteveZ: I have examples of others without boxes, align to western
baseline.
SteveZ: The way we've done this, it's very difficult to come back
and say, use a different alignment point, or pick a
different font-size.
SteveZ: Need to think about ways to extend what we have.
SteveZ: I don't have any great ideas, except that you want to
define a font size, not a height.
dauwhe: This looks like single value-d thing that says "I want my
box to take up 4 lines, and I want my letter centered in
the box."
hober: :first-letter without initial-letter can do these cases
fantasai: Not really. Sizing of the box won't work if the glyph
isn't centered in the em box to begin with (e.g. Latin
letter A)
dauwhe: Is there a possibility of having some value of
initial-letter-align, that could be chosen in this case?
If I pick this value, align the top to the aligning
baseline, etc.
SteveZ: We already made a comment that they don't cascade
independently for the 2 values we have now.
SteveZ: I'm guessing that this is a multi-value property rather
than an independently cascading thing.
florian: That one does make sense as an independent property.
fantasai: Might be able to reuse vertical-align.
SteveZ: The alignment stuff in the section we're dropping has
enough stuff, except it doesn't say whether you want the
top/bottom/center alignment.
astearns: I don't think we should be trying to avoid the
complexity of all these points.
astearns: I think we might postpone it, work on a 2-value
property, knowing that in the future we may be adding
alignment points in the future.
florian: If we want to use vertical-align, we need to figure that
out now.
astearns: I think vertical-align doesn't have enough...
SteveZ: astearns noted there's a distinction between aligning to
the center of the middle line vs aligning to the center of
a whole block, because lines might not be equal in size
<fantasai> hober -
http://lists.w3.org/Archives/Public/www-style/2014May/0211.html
fantasai: But we're assuming they are...
dbaron: But should we be making that assumption?
fantasai: I guess if we have :first-line styling, we should
account for that.
* fantasai is a bit annoyed that the draft doesn't follow the F2F
conclusions
* fantasai wrote those all out *very clearly*
* fantasai dauwhe, you did a pretty bad job of copying the f2f
conclusions into the spec if you got the ordering wrong
[discussion of multi-pass algorithms, scribe missed the context]
astearns: There's virtue of having consistent size for initial
letters and virtue in dropping consistent number of lines
[...]
dauwhe: Web authors are already confused about superscripts
disrupting line rhythm.
dbaron: There's 2 solutions for that in the inline module.
hober: Sounds like we should allow use of <length> as well as
<integer> for height.
dbaron: Well, does the height mean the font-size or the box height
or the glyph height...?
<dbaron> (i.e., the glyph height that in the <integer> case you're
aligning to cap-height and baseline)
astearns: What if instead of a length, we allow a percentage, that
is a percentage of what auto would have been?
fantasai: That doesn't seem useful. Unless you know the font's
glyph proportions.
astearns: Well, font-size is similarly not useful.
Bert: It's useful for initial caps.
<chrisl> What happens with initial letters which are capitals and have
accents above the cap height?
<chrisL> Or initial letters which have descenders below the bottom
of the first line?
...
<astearns> fantasai:
http://dev.w3.org/csswg/css-inline/#initial-letter-exclusions
* fantasai right
* hober wonders about <p><ruby style="initial-letter:3">...
<fantasai> fun
<fantasai> Could say it doesn't apply to ruby
<fantasai> Alternately, treat ruby as ascenders/descenders
<hober> What about inter-character ruby?
<hober> (which hyatt has a patch for, btw)
<fantasai> Include that as extra "letter" in :first-line -- takes
up advance
<hober> Yeah, ascender in the normal case & that for bopomofo.
Makes sense to me.
[hober explains the exclusion principle]
<chrisl> Exclusion is fine for descenders. Does not cover accents
though.
SteveZ: Another parameter is whether you push things down for
stacking, combining marks, etc.
dauwhe: There's a similar problem with accents above.
dauwhe: We want to maintain a consistent font size.
florian: Do we make sure we clear the stacked accents?
fantasai: I think we do need to push it down to make sure there's
space.
dbaron: Economist does initial-caps that cover 2 lines. Js and Qs
indent 3 lines
florian: Question was about accent *above*
...
SteveZ: Angstrom symbol
florian: [...]
florian: If you take J with circle on it, say how it clears, it
works for that letter, why would that not work for other
languages?
SteveZ: It would solve the no-collision problem. Wouldn't
necessarily solve the artistic problem.
SteveZ: Sometimes it's very hard to compute what that extra piece
is in both directions..
SteveZ: You could use the bounding box, although in some fonts the
bounding box isn't the bounding box...
SteveZ: E.g. in swash fonts, the bounding box often doesn't
include parts of the ink.
florian: Isn't the point of that so that you do get collisions?
SteveZ: Yes, but people kept overloading things, so,
SteveZ: There's 3-4 sets of ascender/descender information.
SteveZ: It got misused, people redefined it, it got misused again,
etc.
SteveZ: I don't see us getting anywhere.
<chrisl> I'm asking on John Hudson and JF Porchez on twitter about
initial letter with cap accent
<Bert> -> http://www.w3.org/Talks/2013/1003-Style-Amsterdam/scan-17.jpg
An old manuscript with drop caps that cause non-rectangular
exclusions even in other flows than its own.
SteveZ: One way out of this;
SteveZ: Is it more important that the font size stay consistent or
that the line incursions stay believable?
SteveZ: You can't do both.
SteveZ: If we pick one, then answering what length means will be
an easier thing to do.
dauwhe: I strongly support font-size consistency.
SteveZ: Me to.
SteveZ: Assuming we want to keep font-size consistent, then we can
solve the problem of what length means by describing how
it sets a font size
SteveZ: So, if you use the same length everywhere, you'll get the
same font-size.
hober: I have 12pt paragraph, initial-letter: 3
hober: Are you saying that's equivalent to 36pt?
SteveZ: No.
SteveZ: There's a rule for each script that converts 3 lines to a
point size.
SteveZ: In a Latin font, it would take cap-height.
SteveZ: Whatever fits there, that determines the font-size
dbaron: You also have to account for line-gap, difference between
cap-height and baseline, etc.
dauwhe: In Latin we know the alignment points, so based on that we
can just calculate it.
dauwhe: For CJK we have a different calculation.
<dbaron> dauwhe was just giving the formula just below the figure
in http://dev.w3.org/csswg/css-inline/#f2
astearns: We have this calculation, that results in a font-size,
given a value of 3,
astearns: And it will be consistent for a given font in a given
paragraph.
astearns: Why is that useful for determining the interpretation of
<length>?
dauwhe: If I say 30pt instead of 3 lines...
SteveZ: You do the same thing. You imply a top-alignment point and
a bottom-alignment point, and adjust the base doing the
same thing.
fantasai: I don't think that was what we were trying to solve.
hober: We're trying to solve the problem of 'what does a length
mean'?
fantasai: That seems like a really backwards way to do things.
dbaron: If it's not clear what this other thing should mean, but
we want to allow authors to make fine-tuned adjustments,
dbaron: Then maybe we allow <number> instead of <integer> and
authors can tweak it until they're happy.
astearns: Until we add additional alignment keywords, no, you only
get one alignment, and we choose it per script.
<dbaron> <number> greater than or equal to 1
dbaron: Because that could give you a negative size.
* fantasai didn't understand that
<dbaron> Given 'line-height: 3', then 'drop-initial: 0.5' would
give a negative size because of the N-1 in the formula in
http://dev.w3.org/csswg/css-inline/#f2 being more
negative than the positive part.
hober: Use <number> instead of <integer> for height. When <number>
is not an <integer>, precise alignment is TBD.
SteveZ: If it's an integer, you have 2 alignment points.
SteveZ: If it's not an integer, then there's only one alignment
point. The script will indicate what that alignment point
is.
fantasai: And you can use vertical-align to tweak it :)
SteveZ: With Florian's other piece, given an alignment point and
you have something that extends above, what do you do?
RESOLVED: initial-letter does not have longhands
RESOLVED: Order of values is size first, drop second (as decided
in previous F2F)
<dbaron> Previous F2F minutes were
http://lists.w3.org/Archives/Public/www-style/2014Jun/0108.html
RESOLVED: size is a <number>. Alignment point is determined by
script.
<chrisl> Is the order different in the draft because of a
transcribing error or was it deliberate?
<dauwhe>: It was deliberate due to mailing list discussion.
fantasai: Drop if you don't have an integral size?
SteveZ: Round up.
astearns: Sylvain and I have been working on a JS library for this.
astearns: We will make it public soon.
dauwhe: What do we do with regards to alignment?
?: We aren't sure yet
florian: Might want it to be independent.
<dbaron> OK, I've been looking for a Scandinavian newspaper that
uses drop caps so we can find examples of drop-Å in the
wild, and finally found one: Dagens Næringsliv
<dbaron> http://www.face2face.se/uploads/blog/6593bda3d9d72bfef9cafacb5d21ad7ac2777949.png
has a drop-Å
Bert: Is the size of the border the size of the box, or size of
the letter?
fantasai: Issue of where borders go, it would go around the glyph
bounding box.
Bert: Does the initial-letter property now refer to size of the
box? Or size of the glyph?
fantasai: I can see wanting both ways. e.g. T that rests on the
bottom baseline and top capheight and has a border around
it which is excluded around.
fantasai: Or wanting that box to be sitting on the
baseline/capheight
fantasai: Probably you need a switch.
[discussion of drop-shadows, other effects]
fantasai: Use margin box to control exclusion. Can always make it
larger or smaller (negative).
<hober> In <4187383B-5D9F-4317-9AA1-36D4B04B19CF@apple.com> points
3 and 4 cover this, though the w3.org archive of it
doesn't contain the images :(
plinss: I don't like magic of e.g. changing sizing behavior based
on whether there's a border or not.
plinss: Do we have an answer here?
fantasai: We might make the switch part of how we do alignment.
fantasai: If the content box is drawn around the glyph bounds,
then you get equivalent behavior to what we have when
everything is zero. You can then tweak things from there.
fantasai: The exclusion area would be the margin box.
fantasai: The question here is whether the alignment area matches
that box or matches the character.
[Bert asks about illuminated letters]
fantasai: That's why we allow initial-letter to be applied to
inlines. You can apply it to an image.
dauwhe: The height from initial-letter applies to the image.
fantasai: You use the content box instead of the font metrics.
<sgalineau> Does initial-letter apply to ::first-letter?
<fantasai> yes.
<fantasai> Also to the first inline of a containing block.
<fantasai> The main use case is ::first-letter, but could use
<span> for first-words.
<hober> fantasai and I were emoting about how ruby behaves with
initial-letter. Consider <p><ruby style="initial-letter:3">
<rb>私<rt>わたし</ruby>は...& lt;/p>
[hober summarizes IRC discussion about ruby]
dbaron: Seems like a lot of work for a weird case.
fantasai: Could make it optional. You *may* apply it to ruby, and
if you do so, you do it this way.
dbaron: Do you increase the annotation size?
* fantasai assumes so
SteveZ: jukugo ruby, and breaking...
hober: initial-letter applies to the entire inline, not the whole
fragment.
dbaron: That's the easy case. What if you have ::first-letter and
the first child of the block happens to be ruby?
SteveZ: I think you say it doesn't apply.
dbaron: I'd be happy with that.
[discussion of what ought to happen if something does happen]
SteveZ: The annotation gets adjusted accordingly.
SteveZ: Along with the first letter of the base.
plinss: I think we're in a weird corner and we should take a
break, and you can discuss over a break.
[discussing dbaron's negative for < 1 problem. Seems like just
flooring the number of affected lines at 1 would work fine,
you can still use 0.5 as a size]
Received on Wednesday, 15 October 2014 18:09:26 UTC