- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 11 Sep 2015 14:40:24 -0400
- To: www-style@w3.org
CSS Inline
----------
- There was discussion on if the multiple values of
alignment-baseline are necessary.
- alphabethic, central, and auto were agreed to be necessary.
- top, bottom, and center were considered awkward because they
weren't actually baselines
- There was no decision on the others and they will need
further conversation
- Google asked that figuring out glyph boundaries in
initial-letter be marked as at-risk because it will be time-
consuming for them to implement.
- Issues that need to be added to the spec are:
- What happens when baseline is not in font
- Add width and height to prop for initial letter
- Add a complete list of things that can be applied to
initial-letter
- Which baseline keywords do we need to keep
- Mark initial-letter-wrap as at-risk
- Where do before-edge and after-edge come from?
- RESOLVED: Add a length value to initial-letter-wrap
- RESOLVED: Publish an updated WD of CSS-Inline
===== FULL MINUTES BELOW ======
scribe: dael
CSS Inline: Baseline Alignment
==============================
<fantasai> https://drafts.csswg.org/css-inline/
fantasai: We updated the draft based on feedback from previous F2F.
fantasai: Things that are different: we filled out a bit of the
first chapter which defines vertical align. We defined
the dominant-baseline property. The two longhands for
'vertical-align' are there because SVG needed them
defined.
fantasai: That's roughly that. The definitions are straightforward.
The alignment-baseline has several values: auto |
text-bottom | alphabetic | central | mathematical |
hanging | text-top. If any should be dropped, let us
know. We have to have alphabetic and central and we need
auto.
Hanging Baselines and Fallback for Missing Metrics
--------------------------------------------------
jdaggett: You need clear definition of the fallback. There are
fonts that could have hanging baseline, but in the real
world there almost never are. Implementations fallback
to baseline all the time.
astearns: So we should omit hanging baseline?
jdaggett: Hanging and maybe mathematical are not widely supported.
jdaggett: Type designers design their type so it lines up with
other glyphs the way they want it to. When you're using
multiple fonts, how will they line up - it's not always
good. The information I think the spec needs isn't there.
We need to define the fallback clearly.
SteveZ: First is, hanging baseline alignment is not uncommon in
the parts of India that use the hanging baseline. How they
achieve it I don't know.
jdaggett: That's my point.
SteveZ: The second point is it seems to me we ought to be focused
on what the user wants rather than what the font provides.
I would rather a fallback way of calculating the hanging
baseline, i.e. fiddle with it until it fits, rather than
drop.
jdaggett: We have text-top and if you look at the open type table
for baselines and the hanging baseline is described for
what's used in Tibetan. Are we talking about the hanging
baseline or are we talking about text-top?
jdaggett: In the open type definition of the baseline table there
is a hanging baseline defined, but it's desc as the
baseline used for Tibetan. What is it you're really
wanting to use this for? Perhaps it's some other
baseline?
<dauwhe> John Hudson: " The BASE table specification also gives
examples of a ‘hanging baseline’ setting for Devanagari
script, but I’ve yet to see this implemented in either
fonts or software, and I believe it is based on a
mistaken notion. "
<fantasai> Is it a mistaken notion because nobody implemented it,
or a mistaken notion because nobody wants it?
<ChrisL> Baseline table spec -
http://www.microsoft.com/typography/otspec/base.htm
SteveZ: I want to use it for Devanagari, Bengali, Gujarati, and
Gurmukhi.
SteveZ: I understand hanging baseline was intended for those, but
it wasn't defined. For all of those I have examples of
alignment.
jdaggett: So what are the mechanics of that?
dauwhe: Do you have an example of digital content that does this?
SteveZ: Printed document. Newspapers. It's an everyday occurrence.
It's what people want to do. When you say what are the
mechanics, I don't know what the newspapers are doing.
SteveZ: What I would do is measure the glyph: the hanging baseline
is pretty obvious if I look at the bitmap of the character.
That would be my fallback.
jdaggett: You want to infer the metrics from analyzing the bitmaps?
jdaggett: That feature will never be implemented.
SteveZ: People do it all the time and this is particularly ID-able.
When metrics are missing you need some method to fill it
in.
tantek: Do you have an open issue on when metrics are missing?
SteveZ: Yeah.
ChrisL: You can put a BaseScriptTag in for any language you want
so I don't see why that would be impossible.
<ChrisL> eg “devn” BaseScriptTag for Devanagari script
jdaggett: My question is, I don't see fonts supporting this. You
clearly need a fallback and I don't think analyzing
bitmaps is a good solution.
SteveZ: We can record the issue and move offline.
dauwhe: And we can record the alphabetic font line.
SteveZ: There's some subtle points like with the hanging baseline
where the line is bigger on the initial cap then the body
text and there's an issue as to where you align to, but
that's a subtlety. People do align to the hanging line.
SteveZ: I think the equivalent of the news magazines do this on a
regular basis.
fantasai: Question is do we keep all the values, or do we drop?
Auto central and alphabetic have to stay.
SteveZ: And ideographic.
fantasai: I don't have that in spec.
SteveZ: It's used in fonts. In alignment in Japanese it's equally
likely to be horizontal. Text-bottom kind of works in that
case.
fantasai: I think text-bottom isn't what you want.
SteveZ: You're right.
fantasai: I wonder if text-top and -bottom are needed.
ChrisL: I'd like to understand, the fonts don't currently have
this table but they're used anyway. Are existing fonts
going to be changed to add these things in or are these
features that nobody uses?
SteveZ: Some font vendors supply the tables, relatively few supply
them because the way their production tools work doesn't
make it easy for them to produce the tables and nobody was
using them anyway. They were finding other methods to align.
SteveZ: Because we're trying to do it automatically we need to be
more hospitable to the requirements people have.
<jdaggett> baseline table data: under OSX 10.8, 810 fonts, 41 with
BASE table (all CJK fonts)
liam: In particular some of the countries with hanging baseline
have been slow to join the standardization efforts. If you
look at some scripts, they're not even supported by unicode.
They're using old bitmap or postscript fonts, but it's
changing fast.
<jdaggett> there's no harm omitting values for which we *can't*
support properly at this point
ChrisL: It's changing fast and they're moving to unicode, so it
seems like a bad time for the WG to remove baselines that
they might use. We can't pretend they are using them so we
have to explain how they're used. Presumably the spanning
engine in the browser knows. If it knows get it to tell
you.
jdaggett: Why does it have to know where the hanging baseline is?
SteveZ: Same font, but not same size.
jdaggett: We don't have data here to establish this. Coming up
with ways to wing it isn't good for this group.
ChrisL: The rendering engine is winging it so we use that.
jdaggett: It's not winging it. They're laying out on a baseline to
look right.
ChrisL: Within a single font
jdaggett: Precisely.
<jdaggett> there's no magic here guys, if the font isn't providing
these metrics the shaping engine is not creating it.
<Bert> -> https://www.microsoft.com/typography/otspec/baselinetags.htm
OpenType tag registry for "hang", which says "The
hanging baseline. This is the horizontal line from which
syllables seem to hang in Tibetan script."
* r12a waves
* fantasai waves back
<fantasai> we're discussing baseline tables
<fantasai> https://drafts.csswg.org/css-inline/#dominant-baseline%20property
<fantasai> r12a, question atm from me is, which baseline values do
we need atm?
<fantasai> r12a, thought you might know
<r12a> i've never really done the research i should wrt baselines -
i heard some interesting comments from John Hudson recently
hinting at some myths surrounding use of hanging
baselines, but it's only rumour really until i/we
investigate further
<r12a> i suggest we discuss in email and include people like John
<r12a> the comment from John i referred to came up in the
discussion about first-letter
Baseline Values to Keep
-----------------------
fantasai: Anyway, I need a list of what values need to go into
this spec. I'm hearing conflicting information. One is
support the hanging baseline because people need it and
if it's not provide fallback; and that if we support it
will encourage people to use it. The other side is don't
put it in there because people don't use this.
tantek: It's a signaling method.
jdaggett: It's not, it's a sign that it needs to be simulated.
fantasai: What about the mathematical baseline? Text-bottom,
text-top? I put everything in the spec.
SteveZ: Text-bottom and -top have been in since CSS 1.
dbaron: You can't change vertical-align.
fantasai: This is the dominant-baseline property, we can drop
anything.
fantasai: I'll keep all the values until I get an actual answer.
tantek: Capture the issues on the ones where people are
complaining.
<jdaggett> sure
<dbaron> dominant-baseline in SVG is
http://www.w3.org/TR/SVG11/text.html#DominantBaselineProperty
SteveZ: On hanging baseline if the fonts don't provide the data,
what do we do?
dauwhe: And we can contact the indic layout group through Richard.
tantek: I think this document is early enough that we can capture
each issue inline.
<jdaggett> counter example - small-caps glyphs have existed in
fonts for 20 years
<jdaggett> but up until a couple years ago, no browser used them
for 'font-variant: small-caps'
vertical-align and its longhands
--------------------------------
fantasai: Next is vertical-align which is shorthand for
baseline-shift and alignment-baseline.
Alignment-baseline takes the same values as dominant-
baseline plus bottom, top, and center as well as middle
because that was in CSS 2.1. Center is new, I think.
fantasai: Baseline-shift is you align to the baseline and then you
shift.
SteveZ: So you need to clarify the text that you compute the
baseline alignment first and shift it second.
fantasai: I think it's fairly clear, but I'll check.
dominant-baseline
-----------------
jdaggett: I think the spec needs to talk about use cases. What's
the use here for setting dominant-baseline and adjusting
the baseline?
dbaron: My memory of SVG is dominant-baseline gets used for
something additional in SVG which is not in CSS. With SVG
text when you say place at this x and y coordinate, the
dominant-baseline says what you align to that point.
<dbaron> (my comment about SVG explains why text-before-edge and
text-after-edge are important)
ChrisL: That's correct.
SteveZ: Traditional answer is in the open type spec there are
multiple baseline tables and it depends on which baseline
is dominant. If you're doing Japanese in and English
context it's a different table than English in a Japanese
context.
fantasai: That seems different from what I understood.
fantasai: The dominant-baseline is the baseline you use to align
the boxes. It has no effect if the font doesn't change.
SteveZ: There are different tables for different dominant
baselines. In the open type spec there is a baseline table
for each dominant-baseline. One of the reasons to have a
dominant-baseline is to say which set of tables you're
using.
jdaggett: That establishes the position. It would be nice to see a
use case in the spec.
fantasai: According to the spec right now, you have a baseline
table it has multiple baselines, alphabetic, top,
central, etc. The position of these baselines is
determined by the font size.
SteveZ: A font can have multiple tables and the dominant chooses
which one. Each table has a set of baseline offsets.
fantasai: So if there are four baselines each of four tables would
have four offsets.
<jdaggett> there's *one* BASE table which contains information for
multiple baseline definitions
<jdaggett> a font doesn't have multiple BASE tables...
<jdaggett> spec needs an example that explains how
dominant-baseline and vertical-align define where text
is placed along a line
fantasai: If I have a font that's got 0 coordinate as the
alphabetic baseline, above it there's 800 units which
gets me text-top and -200 units which is text-bottom.
There's a central at 300. This gives me four baselines.
fantasai: You're saying that's one baseline table and the font may
have an additional table that has a different alphabetic.
SteveZ: You don't need a baseline table for your example. That's
not the way baseline tables are done. They have values for
these things in the table. In this case the position of
the Japanese text in an English language context it might
be -100 instead of -200.
SteveZ: The English tends to be centered in the Japanese space,
but Japanese in English puts the Japanese higher.
astearns: We started this with thinking there should be
justification for this section of the document. We're in
the weeds. Let's just put some pictures in the document
and have a note that we need those and move on.
SteveZ: I sent a note to the WG about how it's calculated.
fantasai: There's one thing I'm confused about. There's a single
font in a single size. You're saying depending on the
baseline the glyphs switch up and down?
SteveZ: Because you switched which is dominant.
fantasai: What controls that?
SteveZ: Baseline table.
fantasai: And it's correlated with different glyphs in the font?
SteveZ: No. Where they are relative to the dominant-baseline can
differ. Let's take this offline and I can produce and
example.
plinss: Let's take it offline and move on.
SteveZ: I agree with jdaggett that we need an example and I think
I can come up with one.
fantasai: The examples in the spec I wrote if the dominant-
baseline is alphabetic and you have two different fonts,
you will find the alphabetic on each glyph and you will
align those.
SteveZ: That's the default.
fantasai: That's for alphabetic. If you're using central baseline
as dominant you align the two central points.
fantasai: The clear use case is in Japanese vertical text you have
a central baseline. You don't want alphabetic alignment
in vertical Japanese text.
fantasai: But for English text, you would want alphabetic alignment
within that context.
fantasai: Automatically in vertical we use central and the
horizontal we use alphabetic, but you may want to switch
that.
<Bert> -> https://www.microsoft.com/typography/otspec/BASE.htm
OpenType explanation of Dominant Baseline
vertical-align and its longhands (cont.)
----------------------------------------
plinss: Anything else?
fantasai: There's an issue here where we have top, bottom, and
center keywords. I shoved them into alignment-baseline
property because I didn't want to make a separate
longhand.
SteveZ: I sent you a proposal a couple hours ago that said I think
it makes sense to do them as a separate longhand and make
it exclusive with the other two. It's either or because
they're in sub trees. You couldn't shift a centered
subtree. It doesn't seem to me it would be a big thing.
fantasai: Having two properties in CSS trying to control the same
thing is you can't say which one wins.
SteveZ: One shorthand.
fantasai: The shorthand doesn't matter.
SteveZ: The default for the third property is auto which is the
other one wins. You have to put in a value for it to take
effect and if you do you can't use the other value.
fantasai: I don't like that kind of conflict model.
SteveZ: It's consistent with existing vertical-align.
fantasai: We can also put those in the alignment-baseline property,
which removes the conflict.
SteveZ: It seems it's easier to have syntactic conflict.
fantasai: But then you have authors that set something to not auto
and they're wondering why the alignment-baseline didn't
take effect and it's become someone else set it to not
auto. Conflict resolution for CSS is cascading and it's
better to avoid doing these one property always wins and
hopefully it didn't change when you didn't mean it to.
SteveZ: But nothing you said is fixed for your solution. Right
now, baseline alignment can take either a baseline or
subtree alignment. If I set a subtree it wipes out
baseline.
fantasai: You can't do both simultaneously anyway.
SteveZ: So you wiped it out.
fantasai: If I have a rule on this stylesheet here and I have
another rule over here then the second overrides the
first because it's later in the cascade.
SteveZ: I understand.
fantasai: That's why they're all in one property even though it's
not really a baseline.
fantasai: That's it for the top.
<dbaron> http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#baseline
has some pictures, for what it's worth
alignment-point for images
--------------------------
SteveZ: The last comment I made is you don't have the alignment
point property and that was in there to spec alignment
points for replaced items which don't have a baseline
associated with them that you want to be able to align
still.
SteveZ: You want that for things like initial caps which are
images such as the kind of things that were done in
medieval texts. You want to spec where the alignment point
it.
fantasai: It was alignment-baseline?
SteveZ: Alignment point.
Florian: You specify that on the replaced element? And that
matches that point on the dominant-baseline?
SteveZ: If you specify alignment-baseline, it aligns to that.
SteveZ: You align to whichever baseline it is aligned to.
fantasai: I don't see this in the XSL spec.
jdaggett: Florian's point gets to the point I'm not clear on. The
placement of glyphs on the page gets set to from which
set of stats.
fantasai: The model is roughly, I don't know the steps, but the
results should be I go ask the font, give me the glyph,
where is the alignment point, where is my dominant-
baseline, let's put the point there. I go get another
glyph and I match up the points. If I have a vertical
align shift I layout the points and I shift the box.
<jdaggett> um, implementations need precise details in this case
<jdaggett> "roughly" is a word I don't like...
Florian: I think we need to talk this offline.
plinss: We have 3 more topics for today.
SteveZ: Did that work for you jdaggett?
SteveZ: fantasai I'm willing to work with you.
fantasai: The way we handle inline images is that we synthesize a
baseline for the boxes. The text-bottom and alphabetic
are assumed the bottom text top is the top. If you need
to adjust that you can do it with margins. It didn't
seem urgent to spec another property. If we did I would
like to tie it to a specific baseline.
fantasai: To get it to work correctly I think you need to specify
a lot of the information, but most of the time you can
synthesize from just a few rules.
SteveZ: That's not my memory. Replaced elements are aligned to
their bottom edge and that's it.
fantasai: We added the synth rules in writing modes because that
gets you the correct by default.
SteveZ: That's not necessary correct.
fantasai: It's better for alphabetic in general.
SteveZ: We should record an issue for the handling of replaced
elements because I think different place elements don't
include the margin.
fantasai: I think the ones that don't contain text use the
margin-box.
SteveZ: I just remember it's different for different categories.
fantasai: If you think you need this thing, show me the use cases,
but I think we can do this without another property.
dauwhe: We want examples of all this stuff.
fantasai: That's that section.
CSS Inline: Initial Letters
===========================
<fantasai> https://drafts.csswg.org/css-inline/#initial-letter-wrapping
fantasai: Do you want to go over initial-letter?
dauwhe: We went and made the edits based on the Sydney F2F and
then added a new section on wrapping around initial
letters.
fantasai: We also changed the initial-letter-align property.
dauwhe: There has been some discussion about wrapping being at
risk.
initial-letter-wrap at risk
---------------------------
TabAtkins: Talking to our inline person, figuring out glyph
boundaries we think will be fairly expensive and
complicated for something that's a relatively minor
improvement.
fantasai: We're fine with that. The WG asked us to spec how it
would work so we know where we're headed.
tantek: We were doing glyph rending in 2000 so I don't go by the
performance argument.
TabAtkins: We can do it. It's code we'd have to write fresh and
it's complex for a small improvement.
jdaggett: I'm not sure that's true.
TabAtkins: The person who writes our font stuff says it's hard so
I believe him.
jdaggett: There's code for canvas to do outline.
TabAtkins: We don't want to paint a glyph onto a temporary canvas
and do pixel counting.
<jdaggett> this feature requires extracting an outline
<jdaggett> glyph ==> path, no painting involved
shane: Without technical details, we don't think it's a priority
so we want to mark it as at-risk. Is that okay?
Florian: They're not saying the code wouldn't perform well,
they're saying the don't want to write it.
tantek: How is this harder than exclusions?
Florian: They're saying they don't want to.
SteveZ: If you're doing shaping you can break it into the piece
that you need to shape.
TabAtkins: The shaping engine is a different part of the engine.
jdaggett: That's wrong. You do and you get the outline data from
the glyphs.
TabAtkins: With apologies that Emil didn't come to Paris, but
until you can convince us with Emil here, that will be
our official opinion. I cannot argue the point beyond
giving you the explanation that I have given for you.
<jdaggett> tabatkins: please ask behdad, he'll give you a better
answer I think.
liam: Clarification question. I think you're saying that you're
not wanting to implement at least part of the initial letter.
TabAtkins: Initial-letter-wrap.
liam: There's two aspects of that. One was wrapping exactly around
the glyph around the character and the other is just
adjusting the first line.
TabAtkins: They're equivalent in difficulty.
liam: Is there a possible compromise for the first line? You would
have user supplied move closer value. You could achieve the
same effect for the first line only.
<jdaggett> liam's effect -100000000000000000
<liam> jdaggett, well, I prefer it as spec'd too
TabAtkins: I see nothing wrong with that if the editors are there.
It's text-indent.
fantasai: text-indent indents the initial letter itself
liam: Text-indent doesn't work in the polyfill.
Initial Letter Alignment
------------------------
Florian: You say the previous feedback was integrated. On the
initial-letter-align prop, maybe I'm missing something
but I don't see where it says how to align when the
initial letter and the text aren't in the same script.
fantasai: I think you need to keep reading.
Florian: Is it border-box I should be reading?
Florian: If I want to align the ideographic and the text around
it, how do you do that?
fantasai: Read the note at the bottom. You have two values, we
just dropped a bunch and leaving it as auto made more
sense.
<fantasai> https://drafts.csswg.org/css-inline/#aligning-initial-letter
dauwhe: You just use the appropriate values on each half.
<tantek> As someone who has spent a lot of time both
implementing/shipping fancy first-letter effects 15 years
ago, and continues to publish content with CSS that uses
them (e.g. http://tantek.com/2015/224/b1/alphabet-indieweb )
I'm very happy with the improvements in this working
draft since the previous version and would like to see it
published as an updated public working draft.
<ChrisL> +1 to publishing
<astearns> +1 to publishing
fantasai: The initial things we were told to solve was deal with
the alignment of different scripts. We can deal with two
values, alignment point of letter and of line of text.
The values are 'auto' for choosing the alignment point
of the initial letter; and alphabetic, ideographic, and
hebrew for choosing the alignment points of the
surrounding text. (Hebrew needs metrics that don't
exist, but we think need to exist.)
fantasai: You need to pick from the letter and the line of text
lists. The initial value of letter is auto.
fantasai: We think the auto value doesn't need to be set
explicitly. It's just the first-letter if you can't tell
what script that is you have a problem.
Florian: That's not true.
SteveZ: Punctuation
fantasai: That's not a first letter. First letters have to be
Letters.
fantasai: We can go and do all the values if you want, but we
thought we had all these things and we don't need an
auto. We can just have border-box? And you can decide on
that and then you pick which part of the text you're
aligning to.
SteveZ: Hanging?
fantasai: It uses the cap height.
fantasai: The cap height corresponds to the hanging baseline point
in most of the fonts we checked so that seemed
reasonable.
SteveZ: The problem with the Indic is the top aligns.
fantasai: You use alphabetic as the default.
SteveZ: I have examples where that doesn't work.
fantasai: Alphabetic baseline worked in most cases.
SteveZ: I have an example on my screen where it doesn't.
dauwhe: Do you have the fonts?
SteveZ: No.
<tantek> content request for CSS Inline Layout: I think it should
specify which properties apply to ::first-letter, that
is, incorporate these properties:
https://drafts.csswg.org/css-pseudo-4/#first-letter-styling
<tantek> or rather that list of properties
<tantek> and I propose adding width and height to that list
<tantek> use-case: styling a bunch of different first-letters all
the same width and height
<tantek> like that post I linked to above
dauwhe: I love the initial idea for this to do something simple
that covers everything.
SteveZ: I'm hearing you people say that the Indic fonts don't
matter.
dauwhe: I think that's not true. I've spent 50 hours looking at
these fonts. Everywhere I can look at the font and look at
the font metrics and where I see being a good alignment
can work off of these metrics.
Alignment Autodetection
-----------------------
Florian: I see aligning glyph to glyph is different than
border-box. As to glyph to glyph I wonder if we can do
auto and that does the right thing. Specifying auto might
not be easy but given the text in the lines it's not
necessarily the case. I don't think expanding the number
of controls to say I have multiple letters and I have
multiple scripts, that's too many switches. Can we do
auto or border-box and that covers a lot of cases?
fantasai: The first letter it's easy to auto detect, but when you
have a lot of letters it becomes a lot less reliable.
You'll have a sentence that begins with IBM and the rest
is Japanese.
Florian: But you can detect that the M is English and the random
word in the middle is English.
fantasai: We don't care about that random word. Maybe if we have
text that's alternating language per paragraph and you
have two short paragraphs affected by a single initial
letter, *then* you might want to have a switch, but
that's a weird case so I don't think
we should care.
Florian: It's sure a weird case we shouldn't have a switch, but we
need to say what happens.
fantasai: We can give the user control over border-box or not and
alphabetic vs ideographic because we can't infer that
ourselves. Except for the first-letter we don't do
script-detection in CSS, because heuristics are often
wrong. The reason I'm comfortable making an exception
for first-letter there's really only one grapheme cluster.
Florian: There's a company that's mixed script what do you do?
fantasai: It picks the first letter.
Florian: The first draft didn't say what happens now we have
controls over what happens.
[initial-letter can be set on other elements than :first-letter]
fantasai: We bias against Latin is the set of rules we're using.
[reads the spec]
Florian: Generally speaking on the initial letter you were doing
auto and that's right, but on the text around I was
wondering if you could do auto.
fantasai: You can do auto with reliability on initial-letter
because it's short, but we don't get good results from
heuristics on longer pieces of text. We're making an
exception for initial-letter.
Florian: Okay.
liam: In the case where your random word in another script happens
to be on the third line--you could have several places where
you have initial letters and you want them all appear the
same, so it would be a mistake to make it special in any case.
SteveZ: So create a line grid with the dominant-baseline property
and align to the lines of that line grid irrespective of
where the lines come out.
fantasai: We agreed to that in the last meeting.
SteveZ: That's the only way you get consistent size.
liam: In the majority case where everything is the same language
it works out. If you have something with an accent on the
first line it works out. It's much simpler to implement.
liam: You can end up in a loop if you don't specify it this way.
Issue Summary
-------------
fantasai: Anything else you want to go over?
tantek: About initial-letters?
tantek: Yes. First, I read the draft and this is a huge
improvement. I'd like to see an updated public draft based
on this even if you don't make and changes.
tantek: My one request is I would like the list of what properties
apply to first-letter, I think that's appropriate for this
draft.
<tantek> https://drafts.csswg.org/css-pseudo-4/#first-letter-styling
tantek: I think there's so many effects in this draft that I think
it belongs here more than CSS pseudo. I'd like the list
copied or moved.
tantek: I'd like to propose adding to the list width and height to
the first-letter. I have a use case. When you want to
style multiple paragraphs with the same first letter all
with the same width and height. I tried to do it in a blog
post and I couldn't. I can put the blog post where I tried
in the notes.
<tantek> http://tantek.com/2015/224/b1/alphabet-indieweb
tantek: Those blocks where you can scroll down and see what I
achieved.
tantek: I wanted them aligned as blocks.
tantek: That was my only request. Nice work, I'd like to see an
updated draft published.
fantasai: I'd like people to summarize what issues they want in
the draft.
Florian: I'm happy to publish with or without issues.
fantasai: Anybody else have opinion on what needs to be in the
draft before we publish.
tantek: Mine are all would like to not need to.
SteveZ: Let me review the note I sent to the list.
fantasai: jdaggett?
<jdaggett> publishing fine
<jdaggett> i'll post issues at some point
plinss: Do we want to resolve on publishing?
fantasai: SteveZ needs more time.
fantasai: Issues so far are what happens when baseline not in
font, add width and height to prop for initial letter.
Add a complete list of things that can be applied to
initial letter. And the question of which baseline
keywords do we need to keep.
fantasai: Anything else I forgot?
liam: You got TabAtkins' feature as at risk?
fantasai: Mark initial-letter-wrap as at risk.
Fallback for When Wrapping Not Implemented
------------------------------------------
TabAtkins: I talked about text indent...Is that sufficient to do
this?
fantasai: I applies to the first letter.
TabAtkins: Unless we define it to not.
fantasai: I think we want it to.
dbaron: I feel like the initial-letter being indented is the more
common.
fantasai: You can do it with the margin property in theory so we
don't have to use text indent, but what do you want to
be the fallback if you don't get the styling.
liam: If you don't get it, that doesn't work because it's a three
line cap. You want to push the three lines out and move it
in. But maybe that's the difference between text-indent on
the first-letter.
fantasai: Text-indent is only the paragraph.
TabAtkins: If we kept it and only had a first length value as
mandatory and in absence of length it uses glyph bounds.
liam: Where there was a sub it could be off by a few pixels but it
would be a heck of a lot better. You could read the text
correctly.
TabAtkins: That seems fine.
liam: If we can do it in such a way that it doesn't get in the way
of glyph outline would be great.
fantasai: Having it as a value in initial-letter-wrap would work.
fantasai: You could then do
initial-letter-wrap: -0.5em;
initial-letter-wrap: first;
fantasai: Is that generally a good idea?
Bert: Is that a positive or a negative value?
TabAtkins: I'd match text-indent semantics
RESOLVED: Add a length value to initial-letter-wrap
fantasai: The bounding-box of the initial-letter is the side
bearings so that handles some cases.
Publication
-----------
plinss: So resolve to publish?
plinss: Opposed?
dbaron: I put one other issue in IRC that I don't know is worth
discussion. The spec lists 4 compat values for SVG, but I
think only 2 exist.
<dbaron> One other issue:
https://drafts.csswg.org/css-inline/#valdef-alignment-baseline-before-edge
-- text-before-edge and text-after-edge are in SVG, but
where do before-edge and after-edge come from? They
don't appear needed to me.
<dbaron> it's not in
http://www.w3.org/TR/SVG11/text.html#DominantBaselineProperty
or http://www.w3.org/TR/SVG2/text.html#DominantBaselineProperty
RESOLVED: Publish an updated WD of CSS-Inline
plinss: What do we do with css linebox?
fantasai: We should replace that.
plinss: We have inline on TR.
fantasai: They forgot to merge it when we did FPWD.
tantek: This supersedes?
fantasai: Yeah. It says it in the header. Well, we need to do that
when we publish.
<Florian> http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg
<Florian> http://florian.rivoal.net/csswg/mixed_script_initial.jpg
Florian: I pasted into IRC two cases of initials with mix scripts.
plinss: So on that we're done for the day.
<liam> [text-before-edge is in XSL-FO, e.g.
http://www.w3.org/TR/xslfo20/#font-model ]
Received on Friday, 11 September 2015 18:41:22 UTC