- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2015 17:49:39 -0400
- To: www-style@w3.org
CSS Inline
----------
- RESOLVED: Add full kerning to css-inline, perhaps dropped later
based on implementation experience, but try to figure
out how it all fits together.
- RESOLVED: Choose alignment points by using the top alignment
point of each script and the bottom alignment point of
each script.
- Discussion of how run-in and ::first-letter interact will
continue on the mailing list.
- Alignment points presented several challenges, especially for
Hebrew, which doesn't have relevant font metrics to use, and
Arabic, for which the appropriate top point is unknown.
More information and examples for non-Western typography are
very welcome.
====== FULL MINUTES BELOW ======
CSS Inline
==========
Scribe: fantasai
dauwhe: Wanted to go over some issues with initial letters.
dauwhe: Then wanted to review css-linebox stuff.
CJK and Indic Initial Letters
-----------------------------
[Slides available here:
https://lists.w3.org/Archives/Public/www-archive/2015Feb/0004.html]
dauwhe: Florian raised various issues, here's the first one.
dauwhe: Where initial letter is part of the same word, we want at
least Latin text to kern back a little bit so that there
isn't a break within the word.
dauwhe: But don't want to do that for CJK.
SteveZ: There are examples where you want to kern the second line
as well.
SteveZ: You want to follow the shape of the outline.
dauwhe: We do want that, but the full effect of that would be the
next level.
SteveZ: By specifying what you're doing, you screw up the
extension.
fantasai: Yes, we want to do kerning around the shape of the
letter eventually, but that's a stylistic choice: we
decided to do the rectangular version first
fantasai: We're not going to allow various behaviors. Have to
define one or the other, shouldn't be up to the UA.
<jdaggett> Is this discussion about the illustration in 2.9?
http://dev.w3.org/csswg/css-inline/#initial-letter-position
<fantasai> Yes.
SteveZ: [...]
Liam: There are examples that don't kern the first line of text,
but they're not good examples. Should try to do it if we can.
<liam> [not good - there were technological limitations in the
past]
[...]
jdaggett: It think this is a feature that needs more work.
jdaggett: e.g. distance from glyph outline to text needs to be
controllable.
fantasai: I think for controlling the distance you can use the
margin on that side of the glyph.
<tantek> A decade ago I had proposed ::first-letter('A') to select
only first letters that were a capital 'A' in order to
customize styling on it.
<dbaron> I actually haven't found examples of follow-the-curve.
<tantek> I found examples of follow-the-curve plenty over a decade
ago.
<astearns> http://graphicdesign.stackexchange.com/questions/10561/text-wrap-in-illustrator-cs6
fantasai: From what Liam and dauwhe were saying is that the common
case is kerning that first line, so that should be the
default.
fantasai: If you want a rectangle, you can add a transparent
border or padding.
SteveZ: The issue is should the kerning apply only on the top
example, the rectangular one, or should it apply.
SteveZ: What should be the default?
fantasai: The way it works right now is that you only do this
kerning if you have margins but not borders or padding.
fantasai: We took the margin collapsing principle that the edges
of the box are permeable if padding/border is zero.
fantasai: So you can get both behaviors.
fantasai: I think the model is fairly consistent.
[argument over which is more common, clearly not clear]
<dbaron> Yeah, I've seen a lot where the first line follows the
initial letter outline, but I couldn't find examples
where lines other than the first do.
fantasai: You can add margins if you want more spacing, you can
add padding if you want rectangularness.
dauwhe: We could defer if necessary for implementations.
fantasai: I would prefer to try for this.
fantasai: There is a sensical mode. Wrt implementability, you need
the glyph outline (which you have to have anyway, since
that defines the content box of the initial letter).
fantasai: And you need an offset control, which is provided by
margin.
[tantek talks about full wrapping]
dauwhe: Case #3 is much more common and simple, prefer to defer it.
Florian: Unless someone wants to argue that the bottom is
undesirable or relatively bad thing that we don't want to
be the default, then.
Florian: I think the model is very sane.
SteveZ: My concerns weren't that case #3 isn't desirable, but
worried about separating case #3 and full kerning.
SteveZ: Want to see how it interacts with full kerning.
tantek: I'd like to see what full kerning would look like, and
include it in the draft now, before cutting it.
dauwhe: I'm okay, if that's where we want to go.
[Liam, tantek, Szilles, fantasai agree on this approach]
liam: As an implementer, think it's good to have all possibilities
there, will help to organize your code appropriately.
jdaggett: I want to make clear that I think the difference between
the first option and the one that's in any way following
the outline is an exponential order of time difference.
jdaggett: Because you're looking at the glyph outline.
jdaggett: Wouldn't imagine that a mobile browser wants to do that.
dauwhe: Wouldn't it make sense to include this and then react to
implementation experience later?
jdaggett: I think this should be opt-in behavior.
tantek: I think some implementors have motivation to do
high-fidelity rendering.
tantek: You mention mobile, I think that's a top use case.
jdaggett: I don't think it's universally true that this is the
optimal thing.
jdaggett: It depends on the use case.
jdaggett: The behavior of margins vs. padding is confusing to
authors.
dbaron: I agree that doing this based on padding/border being set
is confusing.
dbaron: Odd implicit thing that people won't get.
dauwhe: Full kerning would need another switch.
dauwhe: I think at this point it's worth doing the full thing,
cost mostly on editors writing spec, and then check in
with implementors later.
<SteveZ> +1 for borders and padding being confusing in this case.
<liam> +1 add and solicit more feedback
<tantek> +1
RESOLVED: Add full kerning to css-inline, perhaps dropped later
based on implementation experience, but try to figure
out how it all fits together.
Initial Letters with Different Script
-------------------------------------
dauwhe: Florian brought up issue of what if initial letter is a
different script than the surrounding text.
dauwhe: Conclusion is you use the top alignment point of each
script and the bottom alignment point of each script.
dauwhe: E.g. "A" inside indic script shows cap-height to
hanging-example, alphabetic to alphabetic.
dauwhe: Florian has an example of this.
Florian: Chinese-English dictionary.
<Florian> example of mixed scripts
http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg
RESOLVED: Choose alignment points as described above.
Run-in and ::first-letter
-------------------------
dauwhe: Next issue is run-in.
Florian: Combination of run-in and ::first-letter
Florian: Having ::first-letter select the first letter of the
original text seems very weird.
Florian: Makes more sense to select the first letter including the
run-in.
Florian: Should either select that or select nothing.
tantek: I lean towards selecting nothing, the author can select
the first letter of the run-in.
dbaron: Does ::first-letter apply to run-ins? I don't think it
does.
<tantek> but it could
<tantek> ::first-letter *could* apply to something with
display:run-in
fantasai: I think dbaron' is right. Run-ins are defined as
inlines, effectively. And you can have multiple run-ins
run into the same paragraph, in which case one of them
for sure won't be at the beginning of the paragraph.
fantasai: So I'm not sure we can have ::first-letter apply to
run-ins.
fantasai: In which case, you'll want to have ::first-letter select
the first letter of the first run-in in a paragraph,
since there's no other way to do it.
fantasai: Although I'm not a box-construction expert, so I don't
know if that's sane.
<dbaron> What decision are we trying to make right now?
[fantasai explains run-in box model: old model was run-in is a
block if it doesn't run into anything; new model it's
always an inline, sometimes inside an anonymous block]
Florian, fantasai: So if we want to do this, either run-ins need
to accept ::first-letter, or ::first-letter
needs to apply to to a run-in inside a
paragraph.
SteveZ: Off-topic: the example on the screen is aligned to the
x-height, not the cap-height
dauwhe: The box aligns to the alignment points, it has padding and
a background.
[Discussion moved to ML]
Floats
------
dauwhe: We had a discussion wrt floats and initial letter.
SteveZ: Having a float that occurs in the 2nd line be 1 line down
from the top of the paragraph is the worst behavior.
fantasai: You run into a problem when you have a floating image
somewhere in lines 1-3 -- in those cases you should
clear the initial letter.
Florian: [to SteveZ] that proposal would introduce a loop in the
layout that doesn't exist.
SteveZ: No, it doesn't, it already exists.
<astearns> I think line 1 should be fine, floats in lines 2+
should clear
[discussion about whether floats moving up creates a problem]
Rossen: Do you expect your proposed algorithm to work for only
left floats?
SteveZ: Yes.
Rossen: Then your proposal only affects one side of floats.
dbaron: We only have a problem on this side of the initial letter.
dbaron: And I don't believe SteveZ. There's a problem.
fantasai: Does anyone other than SteveZ think there is not a
problem?
[silence]
fantasai: Okay, then I suggest someone explain it to SteveZ during
a break, otherwise we'll spend the rest of the
presentation explaining how floats work.
align to letter or box?
-----------------------
[next slide]
dauwhe: Want the ability to align the box as a whole including
borders/padding/backgrounds.
dauwhe: florian suggested that we use box-sizing to determine
whether you align the letter or the box.
astearns: I think it's a bit confusing to use box-sizing. It might
be better to have that as a keyword in the initial-
letter property.
Florian: The initial letter-align property says which set of
baselines to use.
Florian: Must speak either of the letter or the box.
Florian: If you're aligning a box, the baseline values mean
nothing.
Florian: Other values were about vertical centering of box once
you have the box or something.
Florian: We could have a different property for this switch.
Florian: The nice thing about box-sizing is that... [missed]
astearns: It made a lot of sense to have shape-outside key off of
box sizing.
astearns: But we were eventually convinced that having that
conflation of concerns for box-sizing was something to
avoid
astearns: and that's why we put the keyword into the shape keyword
itself.
fantasai: Why not use initial-letter-align?
Florian: What does padding do if you don't have this?
Florian: Why not use box-sizing, since we've changed what we're
using box sizing?
fantasai: People put box-sizing on everything today, to make it
border-box.
Florian: Then by default in those pages you will align the border
box.
[...]
Alignment Points
----------------
dauwhe: The initial indic req doc says that the bottom alignment
point of indic scripts is the text-bottom edge (based on
em box),
dauwhe: but it is definitely not correct.
[dauwhe shows example]
dauwhe: You get very unrealistic results, don't seem to match
examples I've seen.
dauwhe: Because this alignment point is not a visible thing in the
font.
dauwhe: The bottom alignment point in these scripts is in fact the
alphabetic baseline.
dauwhe: Matches much more closely to real examples, and to things
we can see in the fonts.
dauwhe: Still have lots of questions about CJK.
dauwhe: The top example here is Hebrew.
dauwhe: One problem with Hebrew is that the font metrics don't
seem to have a natural alignment point.
dauwhe: There's a strong vertical rhythm along the top of the
characters.
dauwhe: There is a probable top alignment point there.
dauwhe: But it's not an existing metric. It's not the x-height, or
cap-height.
dauwhe: Not sure what issue that raises for this.
dauwhe: In the case of Arabic I have no clue.
fantasai: I think the character you want to align to is the alef.
fantasai: The top of the first letter at the beginning of your
example. lam has the same height (normally).
[dauwhe: projects a table of alignment points]
dauwhe: The myth of hanging baseline.
dauwhe: John Hudson made the point that most fonts typically don't
implement the base table that specifies the position of a
hanging baseline.
dauwhe: And most software doesn't actually use the hanging
baseline.
dauwhe: They're not even sure if hanging base line is what happens
in these scripts.
dauwhe: Here's some examples of characters vastly different in
size.
dauwhe: What happens in every implementation I'm aware of is
alignment at alphabetic baseline.
dauwhe: Looking at CKJ, lots of options in indesign.
dauwhe: Lots of questions about that.
Remaining Content for CSS Inline
--------------------------------
dauwhe: And that's the intro to the next bit, the rest of CSS
inline.
dauwhe: Wanted to get a sense of what that needs to include.
dauwhe: What needs to change from CSS2.1?
dauwhe: Do we really need to define 20 kinds of baselines?
dauwhe: To match bottom ideographic char frame with mathematic
baseline???
jdaggett: I think we have some issue with inter-group issue.
jdaggett: SVG has a bunch of stuff taken from XSL.
jdaggett: dominant-baseline and various properties.
jdaggett: It's a huge number of values.
jdaggett: Some people say this is a compat issue.
jdaggett: But need to coordinate with SVG to see who's going to do
what.
jdaggett: Dunno what's actually implemented.
jdaggett: Properties are parsed, but what's implemented?
<jdaggett> example:
http://mxr.mozilla.org/mozilla-central/source/layout/svg/SVGTextFrame.cpp#328
<jdaggett> Gecko dominant-baseline implementation.
<ChrisL> Dominant baseline stuff was copied from XSL-FO yes and
needs to be cleaned up
dauwhe: Yes, I'm curious about what's happening in the wild.
SteveZ: I was going to ask, in the indic example you have there,
SteveZ: It's what browsers do today, but certainly not what
happens in print.
SteveZ: They do use that in print.
dauwhe: I haven't actually seen an example of mixed-text sizes in
the real world, other than drop-caps.
jdaggett: I think we have to temper things with actual data that
we get from fonts.
jdaggett: We have to be careful of using theoretical models of
what different baselines exist theoretically vs real
world font metrics.
* liam would guess Michael of RenderX would have actual real
examples.
dauwhe: Yeah, I don't believe anything until I can read it out of
the font metric.
SteveZ: That leaves you with real problem with Hebrew then.
SteveZ: Sounds like you're going to end up synthesizing font
metrics that you need.
SteveZ: Existing font metric principle won't work.
dauwhe: It's a starting point, not an ending point.
dauwhe: Should we move forward?
fantasai: Yes, even have some existing resolutions on what to add.
jdaggett: Lots of stuff from SVG, XSL, don't want to add.
fantasai: Yeah, don't want to copy from XSL.
SteveZ: Vertical-align had made some assumptions, so XSL was to
make vertical-align be a shortcut.
SteveZ: Wanted to place things, not just glyphs, but also images.
SteveZ: The list of baselines is unimportant. There was some set
that was useful that you might get at.
<br type='lunch'>
Received on Wednesday, 18 March 2015 21:50:07 UTC