- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Jun 2014 09:03:59 -0400
- To: www-style@w3.org
CSS Line Layout
---------------
- It was decided that the SVG 2 spec will likely move faster
through the rec process than Inline and therefore SVG should
take the lead in spec-ing and pull in the vertical-align
information from CSS and baseline alignment will be trimmed
to closer match SVG.
- There was a substantial productive conversation on how best to
handle dropcaps, beginning with a presentation by dauwhe.
(available here: http://epubzero.blogspot.com/2014/06/css-drop-caps.html)
- The proposed syntax and spec for the handling of dropcaps are as
follows:
- initial-letters: normal | <integer>{1,2}
- applies to ::first-letter or the inline-level first child
of a block container
- First integer represents the size of the letter (as N
lines with N-1 gaps)
- Second integer represents how many lines deep the letter
sinks into the paragraph.
See http://www.w3.org/mid/537AF67C.5010004@inkedblade.net for
more detailed summary and further discussion.
==== FULL MINUTES BELOW ======
Full Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael
CSS Line Layout
===============
<fantasai> http://dev.w3.org/csswg/css-inline/
plinss: Next topic is line layout
glazou: We have a message from krit about timing.
plinss: He's here for another hour it says.
dauwhe: It says something about moving drop caps.
fantasai: Is box align on the agenda?
plinss: Yes.
fantasai: I don't know if SteveZ put it on his list, but he should
be there.
fantasai: We should combine the topics about baselines
plinss: Line layout.
fantasai: Okay.
fantasai: I guess, let me use the projector.
krit: I'm here for the next 50 min and I'm not sure how long the
fantasai presentation would be but I'd like to discuss parts
of this.
fantasai: Let's go over what you want to go over.
krit: I'll wait for SteveZ.
* SteveZ Steve is here
glazou: He's there.
Aligning SVG and CSS Baseline Alignment Properties
--------------------------------------------------
krit: SVG has the spec on a REC and they'd like to reference CSS
spec instead.
krit: Especially since the properties are in SVG
krit: We want to be in CR for SVG2 by the end of the year and it
would great if line layout could progress within the year.
fantasai: I don't think that's realistic for inline layout
krit: We have the SVG interest and can do changes in SVG
fantasai: That might be more doable.
fantasai: I think the baselines can get in order, but there's a
whole section on general layout that needs to be cleaned
and I don't think we can get the whole thing together in
time.
fantasai: Best option might be to update SVG specs with tweeks.
krit: I think the baseline is in SVG. I think we can reference the
CSS as much as possible and if we could publish baseline
that would be great.
clilley: SVG doesn't need dropcaps. People don't want this stuff
in SVG. We got feedback saying why are you doing this in
SVG when you can reference CSS.
fantasai: So let's pull up the SVG spec. It's SVG 1.1?
clilley: 2 is what we want to do it this in, but it's mostly the
same content.
fantasai: The interesting section is 10.10.5
<krit> http://www.w3.org/TR/SVG11/text.html#DominantBaselineProperty
for reference.
<krit> 10.9 Alignment properties
fantasai: So that seems reasonable as a resolution. We need to
make sure dominant baseline is independent of other
properties.
fantasai: Vertical-align I think was suggested to be a shortcut.
dbaron: There's a bunch of things that happened. XSLFO published a
shorthand for a bunch or properties. SVG 1.0 had -around
the same time- alignment-baseline, and baseline-shift,
but didn't mention them as sub properties of vertical-align
dbaron: Ancient CSS proposed doing the same thing. I don't think
alignment-baseline and baseline-shift make sense except
as sub properties of vertical-align.
clilley: Why does that affect the validity?
fantasai: Because if you have alignment-baseline/baseline-shift
and vertical-align be totally independent properties,
you have two properties simultaneously trying to
control the same effect.
dbaron: If one isn't a shorthand, you have two things setting the
same thing and you don't know what to pay attention to.
clilley: Okay.
dbaron: Browsers haven't implemented so there's a bit of a
compat risk.
clilley: What would you say is the best path forward?
fantasai: Given your timeline we should work in SVG 2 to specify
that alignment-baseline and baseline-shift are longhands
of vertical-align, and that dominant-baseline is very
clearly an independent property.
fantasai: I think that we should generally include this in our
review of what we're doing and work within the SVG spec
for now.
clilley: So SVG gets edited and later it gets pulled out?
fantasai: So we'll sync this to the old version and merge so that
it makes sense.
fantasai: That gets us to a reasonable place.
clilley: That sounds reasonable to me. krit?
krit: Sounds reasonable.
fantasai: So whoever is editing this should pull in vertical-align
and put it in this section.
clilley: Can you send an e-mail saying what you just said?
fantasai: Yes. I haven't done a prose review.
<fantasai> Summary of vertical-align plan:
http://lists.w3.org/Archives/Public/www-style/2014May/0208.html
Overview of CSS Inline Layout L3
--------------------------------
krit: I'd like to know what's in CSS inline since we have the SVG
spec moving forward.
krit: Okay.
krit: Can we move to the next topic?
fantasai: The entire inline box definition needs to be cleaned up,
but that's a matter of digging through the trash.
fantasai: What needs to be changed is the vertical-align stuff
going into SVG 2
fantasai: The state of this draft is it's a mess and I don't know
what needs to be cleaned so if anyone has info on that
let me know.
fantasai: The draft is divided into logical sections. One is how to
determine the height of the line.
fantasai: Another is the baseline alignment section, where we have
a lot of properties that needs to be trimmed down to
what's in SVG 2 (unless someone thinks there's something
else important we should save).
<SteveZ> I think all the properties are important if you want to
align images to text.
fantasai: There's a drop cap section and I'd suggest that dauwhe
speaks on that.
Baseline Metric Heuristics
--------------------------
astearns: Before drop caps there was an additional issue about
fall back for data that wasn't present?
krit: Can you hold back with drop caps?
clilley: What do you mean?
krit: I'd like to do baseline properties. They require metrics and
this would need to be present for implementation. Spec says
that if they're available they should be used, but it
doesn't say how.
clilley: There are reasonable heuristics that we should spec
because it's not that hard.
astearns: So the plan is to put the reasonable stuff into SVG?
clilley: Yes. For now.
<dbaron> this is about what to do if a font doesn't have metrics
for, e.g., the ideographic baseline
<SteveZ> The heuristics are actually specified (but not quite
correctly) in the XSL-FO document
<SteveZ> See section 6.6.8 of XSL-FO 1.1
<clilley> Steve, do you have a list of what is not quite correct?
<SteveZ> I am working on tracking down good values for the
heuristics.
clilley: I recall seeing something in the last 6 months where
ideographic baseline is less than half or something that
gave reasonable fallback. I think it was on the style ML.
krit: For the heuristics I think webkit and SVG are spec'ed. Steve
was talking about if they're reasonable heuristics. I don't
care if we use XSL-FO or other heuristics, but I think we
should spec them.
clilley: The heuristics don't have anything to do with them, they
just need to be in that spec.
krit: XSL-FO already spec some heuristics and because these Steve
is suggesting that he tries to figure out heuristics that we
can use so we should spec which one we use.
<SteveZ> The ascender and descender values
clilley: I saw one in IRC that SteveZ said some are wrong. Do you
have a list on which bits?
krit: I can work with SteveZ to figure that out.
<SteveZ> I still need to track down values for hanging baseline.
<clilley> Is that typographic ascender instead of os/2 windows
ascender descender?
<SteveZ> As you may know, Adobe prefers the use sTypeAscender in
the OS/2 table
clilley: So is that topic done? Sounds like we have an action on
SteveZ to produce baseline stuff?
<SteveZ> Steve accepts the action item
krit: Yep.
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-631 - Work on the baseline stuff [on
Steve Zilles - due 2014-05-27].
Drop-Caps
---------
<fantasai> ACTION dauwhe post slides to www-archive
<trackbot> Created ACTION-630
<dbaron> http://dauwhe.github.io/dropcaps/Overview.html was the
link in the agenda
* SteveZ it would be useful to have the slides sent before the
discussion for us not in the room
Slides: http://epubzero.blogspot.com/2014/06/css-drop-caps.html
dauwhe: The first issue about drop caps is what to call them. We
can worry about that later.
dauwhe: Alignment is broken on the web. I've collected examples
from tutorials on how to use CSS.
glenn: Initial letter doesn't work for ideographic.
dauwhe: That's pretty straight forward, we'll just eliminate every
option.
fantasai: CJK characters are letters according to Unicode.
fantasai: So we're good.
dauwhe: What people do today is float them. This is a 3 line drop
cap and you just use trial and error to align.
dauwhe: The half line of the large letter is controlling the
vertical position.
clilley: Can you use calc()?
dauwhe: Calc() would need to know the ratio of the font size.
dauwhe: If I switch the font, it doesn't work any more.
<SteveZ> And has been pointed out in the e-mail thread, you want
to size the the base character in a composite glyph
combination.
dauwhe: Most publications switch drop caps to be raised caps
because it looks too bad in CSS.
dauwhe: What should happen in a drop cap would be the top line
aligns with the top of the cap.
clilley: So for accents it just sticks up but for descenders?
dauwhe: We'll get to that. So we still align with the top line of
text. A lot of this is because you want consistency and if
you scale down for the accent the size would vary wildly
as you move.
dauwhe: So as the simplest proposal, initial letters are defined
by how many lines they occupy.
dauwhe: The initial uses the drop initial property. If it's 1
nothing happens, if it's more than 1 you get to drop. It
can't be negative and must be an integer.
TabAtkins: Will this only be allowed on first letter pseudo?
<liam> [note: Hebrew uses "drop words" at the start of paragraphs]
dauwhe: I'd like to be able to apply this to an element partly
because there's questions about a case such as if there's
a starting punctuation it gets included in the drop
initial so you may need two elements.
TabAtkins: So it's display-line-element?
dauwhe: Only if it has a value over one it should display.
TabAtkins: So only on floated elements?
fantasai: You don't want a random word in the paragraph that
can drop down.
TabAtkins: To do it properly you need shapes to flow around.
dauwhe: There's lots of things that we do that can create visual
disasters.
dbaron: But we don't want to implement those disasters.
fantasai: We can say it's only first letter.
<liam> [some designs do have a word before the dropped initial,
this is neither difficult to implement nor bad; the hard
thing is the runaround but we already have those proposed]
TabAtkins: I think more than first letter is useful like drop word.
dauwhe: I've heard of word use cases, but haven't seen any.
<liam> [drop words - best known example is hebrew, esp in
religious contexts]
fantasai: It would have to be the first element in the block.
TabAtkins: If you require floats it doesn't matter. It's a
sizing thing.
fantasai: The float can be an entire table.
TabAtkins: Basic case is just sizing to the line grid.
<SteveZ> Floats will not work because they cannot appear higher
than the line from which they are called out
hober: That brings up the point, what does this require of the
paragraph you're in?
dauwhe: You can get into trouble with other inline elements of
various heights.
dauwhe: At least in the context we want to use these I'd love to
be able to say you have to have fixed line height.
TabAtkins: You only have fixed if you use line grid.
clilley: liam points out in IRC that there is uses for drop words.
dauwhe: So skipping the how to select issue, the rules are
capline-alignment and baseline-alignment. There's fonts
where the capitals have descenders so that it goes below
the baseline.
<fantasai> I'm wondering if what you want is for all the drop-caps
in the book to be e.g. 3 lines tall, and if the glyph
falls below, to wrap around it (shapes)
clilley: It seems that could be fixed with a property that allows
extra lines underneath. Another property that says how
much it'll allow underneath if needed.
plinss: It's the "if needed" that's the problem.
dauwhe: Another approach is to define the bottom alignment as
being different than alphabetic base.
clilley: It seems like you want them to all have the same number
of lines from cap height to base height.
dauwhe: This is inDesign's implementation of drop caps with this
check box that says scale for descenders.
clilley: So there's only "make it smaller"?
dauwhe: Yes.
dauwhe: So I checked that and it scaled to use the bottom of the
descender.
TabAtkins: It does look good for J, but I imagine it would look
odd in other cases.
dauwhe: Yes. There isn't a good solution. We can't solve all the
design problems.
hober: I think the ç is a good example, though.
<liam> +1 to use baseline
* liam q+ to note about multiple visible drop caps on a spread
<SteveZ> I sent an example earlier today that highlights a number
of the concerns you eventually want to resolve it is in
http://lists.w3.org/Archives/Public/www-style/2014May/0205.html
plinss: Why isn't this an exclusions problem
hober: If you do exclusions do you need a property? We don't want
a second property to get it to the default case that we
want to have.
TabAtkins: You want the main drop cap to be the leading with the
height. You'd want to exclude according to shape.
plinss: That should be opt in.
plinss: You want to follow the whole outline or be square.
TabAtkins: So if you have a odd extra swishy tail you'd want to
wrap around.
liam: If you have several large initials on a double page spread
and some have descenders or accents or don't and you clearly
want the base to be the same size.
liam: That's why you don't want the automatic approach to account
for the J.
dauwhe: I think the exclusion solution addresses that issue so all
the letters will be the same size.
liam: But you have to treat them differently when the drop cap is
just a big rectangle such as with fonts that don't give that
information. Also treating the glyph as an image.
hober: I want that as a value for shape outside.
dauwhe: I want that too.
liam: There's example on that blog I sent to the list.
* liam notes the "nd" should be close to the A here really because
it's the same word
dauwhe: The ED of inline has 6 properties for this, most of which
have large numbers of possible values.
dauwhe: This is a sunken cap. The number of lines is the same as a
3 line drop cap, but it drops 2 lines and goes up 1 so the
spec property to drop initial size, that defaults to auto.
dauwhe: Normally the user agent figures out the height.
hober: So in this case I'd have to do math, so why not instead
have a drop shorthand and it might be for both how far you
drop and how big you are?
dauwhe: It was proposed that you could take a number or percent.
hober: My option is limiting in that it only takes integers.
dauwhe: I'd support that.
hober: We're forcing them into a simplified model which is
the point.
TabAtkins: That way they don't force themselves out of a good
model (line grid). Do you have examples where it would
be different?
dauwhe: No.
<liam> [NO not just saving effort - you can't do drop caps right
now with CSS without this sort of stuff]
hober: Here's an inverted example I styled to have drop cap and
later replace for illuminated and I want drop caps to be
the same size as the illuminated.
plinss: Even than you'd want to scale.
fantasai: Use SVG!
hober: I agree.
<krit> fantasai: +1
* krit heard SVG
hober: The example provides how big, how far down, and how big to
exclude.
dauwhe: hober, I like that idea.
<liam> [ http://barefootliam.blogspot.ca/2014/05/using-images-as-initial-drop-caps.html
shows alignment points for an image (illuminated!) used as
an initial cap ]
glazou: SteveZ posed a use case. Would what you're proposing allow
that?
<dbaron> Steve's example:
http://lists.w3.org/Archives/Public/www-style/2014May/att-0205/InitialCap_from_MeetingGod-StephenHuyler-HinduPractice-selectedPages-2.jpg
SteveZ: Basically in that posting I identified 8 aspects that you
need to do that or related to the examples that were
posted by liam.
SteveZ: They're on the blog.
SteveZ: You need to know the bottom alignment and the size, but
you also need things like how it interacts with text
indent so the letter can fold into the margin and you need
to know if there's kerning into the line like in this
example.
SteveZ: As people have observed there's a need to allow shapes to
apply to the letter.
SteveZ: And if there's an exclusion or not so if you get a square
shape or follow the outline - if the character will be
overlaid.
SteveZ: There's a fair amount of baggage, some of which is already
there, just to do that example.
<clilley> drop caps in scribus
http://wiki.scribus.net/canvas/Advanced_Drop_Caps
hober: I'm scared of trying to provide n knobs for this really
awesome case here. This can have 2 or 3 knobs that get you
mostly there.
SteveZ: I agree. I was trying to outline what you need to cover. I
think in this case shape would do fine.
plinss: If you look carefully, the indent on the first line is to
the tangent of the right spot.
TabAtkins: It's shaped.
plinss: A nice way to address would be in controls of the
exclusions. I want to follow the glyph but only in this
area.
dauwhe: You want to draw the path.
plinss: I don't want to draw.
dbaron: The example I've seen of doing that with first letters
seem to follow the shape for the first line, but make sure
the following are square.
dauwhe: I've seen that
<clilley> It's an exclusion from the intersection of the glyph
outline and a given rectangular shape below the baseline
dbaron: I found one with a cap D and the first line was with the D
and the next three were flush with the box. But it wasn't
a real world example.
<dbaron> http://www.templates.com/blog/wp-content/uploads/2012/04/Learn-How-To-Create-Drop-Cap-Letters-In-CSS.png
dauwhe: I've seen a common thing where the first line is pushed
into the letter, but not the rest.
<liam> dbaron,
http://1.bp.blogspot.com/-qnEdyt8fczk/U22dxCLkvqI/AAAAAAAAAZY/HQA6xd0mMn4/s1600/114-drop-cap-examples-c.jpg
shows that (using metal type so the baseline didn't align
properly)
fantasai: That's to improve the visual connection between the
first letter and the rest of the line.
liam: People will want to get creative in ways we won't predict.
astearns: And this can be done with a shape.
hober: I like the exclusion box. If I have to do a polygon and the
user didn't have the font, it's busted.
plinss: We can do this with various things, where ever they came
from, and I can define how they interact. Then we just do
exclusions for drop caps
fantasai: Maybe we can add a keyword for text-indent and say if
we're following shape of a drop cap, since we have
first line controls in text-indent.
hober: Yeah.
fantasai: I haven't thought this through, but it's something to
think about.
<SteveZ> I am concerned that we should be looking at an
architecture that covers 100% of the case and then
simplify rather than hope we can extend.
<clilley> http://www.smashingmagazine.com/2012/04/03/drop-caps-historical-use-and-current-best-practices/
<dbaron> http://annesart.files.wordpress.com/2010/07/apes_macbeth.jpg
is also interesting.
astearns: So we have all sorts of things proposed, but I like the
idea of a restricted set for now.
dauwhe: And the percentage it'll cover will improve the situation
dramatically.
dauwhe: That's one concern I had with the current approach. That
there were all these things with options when we need a
default.
hober: So a shorthand that takes one or two values.
dauwhe: I like that idea a lot and this is something that's used
for a lot of authors that haven't spent quality time with
inline formatting models.
hober: The gap between those proposals and the example from SteveZ
is margin, z-index, and the exclusion, all of which we have.
dauwhe: All we need is the proposal that says this drops 4 and
takes up 5 lines.
astearns: [reads SteveZ IRC comments]
TabAtkins: Normally we make sure we know that the 100% would look
like, and know that we can eventually fill the holes
plinss: I don't want to fill this with 10 properties. I want a few
properties and then do the rest with CSS primitives.
<SteveZ> correct: have an plan that you need not fully flesh out
hober: The other kinds aren't unique.
clilley: We did just talk about finding all these baselines. I'm
concerned these are all Latin and I'd like to see things
that use different baselines.
* fantasai clilley++
<liam> [I do have a later blog entry pointing to some Arabic
examples]
dauwhe: One question about that is would each language have a
preferred set of alignment points?
clilley: It might but we don't know.
fantasai: We have a dominant-baseline property
TabAtkins: From the dominant-baseline you can infer the points.
clilley: The inferring needs to be in the spec.
dauwhe: I'm weary of the approach that lets me access 17 alignment
points and ends up in a mess.
hober: You shouldn't be forced into that mess if the first item is
CJK and the rest is Latin.
<dbaron> The Economist in general does the thing with the D
example -- first line fits to the glyph, second line fits
to the box.
<SteveZ> Liam also has examples where the first line is "kerned"
to the initial letter in his blog at
http://barefootliam.blogspot.ca/2014/05/bruce-rogers-on-drop-caps.html
dbaron: Random data point, the Economist takes the first line to
the drop cap and then aligns the rest to a regular point.
clilley: What fantasai was saying about indent...
fantasai: We'd have to add a keyword.
hober: It's any special value that's not negative
astearns: That would make it align.
TabAtkins: Text indent only shifts the first line.
<liam> first line indent - no because you don't know the distance
until you know the font.
<liam> first line joined to the initial is done when it's part of
the same word, e.g. [A]pples of the mind, rather than [A]
boy ate two apples.
plinss: You have to shift enough to not overlap the glyph.
dbaron: I think the Economist has custom flows.
dbaron: I think it's better to do smaller subset.
dauwhe: I don't see anything about your drop two that's boxing
us in.
hober: I don't want to gratuitously preclude adding more but I
don't think that's what we're doing.
<dbaron> I think it's actually that the non-first-line in the
Economist is one of the points to which justification
spacing is distributed.
astearns: If we start with simple shorthand, do we need longhand?
plinss: We can always break it out later if we need to.
hober: Why not drop: <integer> <integer>? It's just called drop.
dbaron: It can be a shorthand later.
clilley: So initial value is '1 0'.
[white board discussion with lots of pointing at things]
<SteveZ> But what do you do when the initial letter is only
partially dropped?
<liam> drop: n m, would be a partial solution, could it later be
declared a shorthand for a more powerful set of properties?
<dbaron> Yes, could definitely become a shorthand later.
<liam> dbaron, thanks (shorthand)
clilley: There's 3 things. Number of lines to span, a thing to
shift it up, and a thing that says how much space for
things below base?
dauwhe: We weren't going to do the third item, that would be on
by default.
dauwhe: We exclude on the em square.
plinss: Glyph square.
hober: I was envisioning a single property where it's three lines
tall and three lines deep. So two values of 3, one where it
is three high, but only goes down on line.
<dbaron> two integers that express (a) the number of lines the
line is sized to and (b) the number of lines it drops down
dauwhe: 3 1 is the raised cap.
SteveZ: What if the alignment isn't alphabetic baseline? Like a
hanging alignment thing.
TabAtkins: We talked about that.
TabAtkins: We'd figure out the right thing to align to and
possibly allow override but we'd come up with a
reasonable default.
[whiteboard discussion about what would constitute what dimension]
dauwhe: 3 is the number of lines occupied by the drop cap.
SteveZ: That doesn't work.
dauwhe: That's a short hand for when we describe when the drop cap
is n times the height.
SteveZ: You've got languages where you've got stuff underneath.
clilley: The initial size is how many lines it would cover and the
second integer determines if you cover all or some and
than there's an automatic property that's an exclusion
below.
SteveZ: That's not what you want. You want the base character size
the same throughout.
clilley: That's what we're doing. We're chopping out more lines
than spec'ed to allow to not intersect.
SteveZ: Okay. If that's true I think you'll have trouble writing a
clear spec to say exactly what, say, 3 means.
* liam think this only handles letters/glyphs, not images, right?
[Whiteboard suggestion]: initial-letter: <integer>{1,2}
dauwhe: Does <integer> include 0?
TabAtkins: We don't have a term for that and it's not clear if 0
is positive.
dbaron: There's also a constraint to make sure the second is less
than the first.
dauwhe: If the second integer is bigger it's just sunk more.
hober: I don't care if we disallow.
<dbaron> Yeah, maybe it's fine to allow "3 4"
<dbaron> It'll help people figure out what the values do, at least.
plinss: The property name shouldn't include the word letter. We're
not controlling how much we're doing this to.
<SteveZ> Images can be handled if you can overlay a baseline table
on the image.
hober: If this is only a value on the ::first-letter pseudo, then we
don't have to say first letter.
plinss: We're describing the behavior, not what it's applied to.
fantasai: So, it takes two integers, they must be > 0 and we don't
care about the relationship of them. First integer is
how many lines tall, second is how many lines it goes
into the paragraph.
dbaron: How many lines it's lower alignment point sinks in.
<liam> so in http://barefootliam.blogspot.ca/2014/05/using-images-as-initial-drop-caps.html
(see 2nd image) first number would be 4, what would second
be?
<SteveZ> For hanging alignment, the alignment point is not "lower".
dauwhe: How about when the paragraph is too short?
TabAtkins: Is it a float or something else? Because if it's a
float it's whatever you want in to do.
fantasai: Default should be it takes up space. If you want to do
fancy stuff we can do that later.
plinss: The other question is when we're not dropping the full
height, are we just making the first line taller?
hober: And then how does it interact with line grid?
TabAtkins: It's probably desirable to make it not take up
geometric space
plinss: But then you risk overlap with the paragraph above.
TabAtkins: So it should add extra space to the top?
hober: It's empty lines that don't get counted.
fantasai: So currently if you set font-size: 3em; you get a big gap
below the first line. (It's not a correct initial cap.)
Having the two proposed parameters lets us do both initial
and drop caps properly.
fantasai: For the name of the property, initial-letters?
zcorpan: What about a big initial character and you want the next
paragraph to be indented too. Is there a way?
hober: You float it.
fantasai: So, in most cases, do you want the drop to
continue through?
dbaron: Depends on if next paragraph has a drop cap.
hober: So if there's a lot of drop caps, you put float left and
clear left on my first one.
dbaron: Putting float left and clear left on the first under
current semantics moves the first letter, but not the
first line.
TabAtkins: You want this to work with the paragraph in a way float
doesn't do.
plinss: But maybe we can use clear.
<liam> (want clear: on the paragraph, but of course that interacts
with other things on the page)
dbaron: Does float on first letter behave like float?
plinss: I'd rather not a magic float.
hober: But if we have it we might as well admit it.
dauwhe: Does everything I want need magic?
TabAtkins: Yes.
<SteveZ> I would not like magic floats either.
<dbaron> http://www.edwardtufte.com/tufte/graphics/Page2.jpg
<dbaron> (first letter crossing multiple paragraphs)
<dbaron> fantasai's whiteboard currently says:
<dbaron> initial-letters: <integer>{1,2} | normal
<dbaron> * integers > 0
<dbaron> * glyph overflow is excluded
<dbaron> * handle non-alphabetic baselines
<dbaron> * subsequent paragraphs starting [with initial-letters]
normal wrap. Non-normals clear.
fantasai: So if we have the initial value as normal we can say if
your next paragraph starts normal you wrap. If it starts
special than you have to clear the initial cap.
astearns: This is getting into future territory. You can add a
switch to push or wrap the next paragraph.
fantasai: We can do an auto behavior now, though.
dbaron: What's initial?
fantasai: Initial is normal since we need it to be not 1 because
it triggers descender behavior.
fantasai: If you have two paragraphs, if the first one..
dbaron: I get it now.
plinss: But if you set it to 1, it gets pushed.
plinss: I'm wondering in the case of hanging baselines if the
default is to drop and exceptional is the shift.
plinss: If first controls size...
fantasai: Indic does initial caps, too. So behavior should be the same.
plinss: I'm wondering if the second might be negative with hanging
baselines.
fantasai: No. we won't do that.
<liam> [as far as I can tell, Hindi and Arabic do *not* align the
hanging baseline, they work like Western drop caps]
<astearns> liam - for Hindi that makes some sense. the hanging
line on the drop cap will be larger than the line in
the text, so aligning it wouldn't help much.
<liam> [Arabic example -
https://web.archive.org/web/20131025031223/http://garciamedia.com/images/blog/Shabopinion_thumb.png
]
<liam> [for Hindi, as per Richard Ishida's example mentioned in my
blog, it's a Drop Syllable]
Rossen: Are we modeling float or exclusion?
Rossen: That will make a difference if your second paragraph is
overflow: hidden. If we do floats the second paragraph is
pushed. If we do exclusion, second would be excluded. So
which is right?
fantasai: I think we want float because if you have a block
formatting context root you probably want that not
wrapping into the previous paragraph.
zcorpan: Is it possible to make the lines follow the shape?
hober: We talked about that with shape outside.
plinss: The default is exclude around the box. And if you want to
do some wrap that's an extension.
hober: Or a keyword.
plinss: It would only work on the first line, but future ones can
work on other lines.
fantasai: Name of the property?
plinss: Bikeshed.
Rossen: With a value of shenanigans.
fantasai: I like initial-letters. With the s it seems sufficiently
ambiguous.
hober: Can we defer naming to the editor?
dauwhe: The name can be hashed out on the list. I'm not sensitive
to the issues involved.
fantasai: We have letter-spacing already, which affects characters
from all scripts, so being consistent is good.
fantasai: We have a first-letter and letter-spacing.
plinss: I'm fine with first-letter for now, but I don't want that
to be the final name.
clilley: We can all it "first!"
<liam> [who is the editor? I'll be happy to help review the text
etc.]
<dbaron> liam, dauwhe
<liam> ok, thanks
fantasai: Any other points that we need to add to the summary?
plinss: If there's one number is the default the drop?
fantasai: Yes.
plinss: Is that how it should work?
dauwhe: That's the common case.
fantasai: The last time I made a property* where it took two values
providing only one didn't duplicate for the second like
in the rest of CSS, I regretted it later.
dauwhe: I think that's better.
liam: This sounds like it works for glyphs, but what about images?
liam: There's quite an industry for drop caps of images for print
and web.
TabAtkins: I don't see a problem with images. You give it the same
values, it would take whatever space. If it's atomic
you'd use different alignment.
dauwhe: You're still aligning with text.
dbaron: The problem is images aren't matched by the first-letter
pseudo.
<liam> [if it's SVG the formatter can scale it to fit]
clilley: And images is an image and doesn't have font information.
But open font format is having a new edition where you
can add SVG outlines where you can have anything.
clilley: If you have an image and want people to use it. You can
drop it into a font using SVG and provide that
information and you're done.
<dbaron> And this solves my problem too.
TabAtkins: I don't think we need new property for images, but as
images in a font we're great.
dauwhe: There's precedent in e-books.
SteveZ: I was going to say something similar to clilley.
SteveZ: I wanted to point out why one of the reasons that
vertical-align has an alignment point is to let you
describe that. The other half of the problem is trying to
figure out the top of the image as you might have extra
features that you don't want into your computation.
SteveZ: We need an alignment point and sizing point on the image.
dauwhe: Are we just defining what would have been the baseline of
the initial letter and what would have been the cap height?
dauwhe: And if there's frames these image initials have lots of
pretty things.
clilley: But than the exclusion magic kicks in. What happens if it
has extra stuff? Your left margin there, if the ink is
larger than it, does it extend?
<dbaron> italics too?
clilley: Liam, thoughts on characters wider than their advance?
liam: I've got an example where the top right of a W goes over and
that's an example where you use the outline of the glyph.
<liam> http://barefootliam.blogspot.ca/2014/05/drop-caps-other-writing-systems-other.html
links to an example...
<liam> http://uandlc.com/PDF/Volume%2017-2.pdf
starting at page 18 is the article of drop cap examples
SteveZ: I think what we said is if you use the shape exclusion and
image format, you get what you want.
plinss: I think the answer is yes. Possibly above and to the left.
fantasai: So a side point, we need to be able to spec the baseline
of a non-character.
hober: And for other cases.
fantasai: We have rule for synthesizing baselines on atomic inlines
in Writing Modes already, for baseline alignment of images.
Should re-use that here, and if we have an explicit property
for defining its baseline table, would use that in both places
as well.
fantasai: So the initial-letters property applies to ::first letter
and any inline-level first child of a block container.
hober: That takes care of where it uses a span path.
dauwhe: Or where we need that open quotation mark.
fantasai: At it means it applies to an image.
clilley: One thing it won't do is a paragraph with a span inside
it where I have punctuation in a different language.
hober: I'm okay if that's hard.
clilley: I've got a span where I put a language in which I don't
want to drop the symbol, than I put a span with the
letter I want to drop and hober doesn't care.
hober: It's an edge case.
clilley: It's an edge case only in English.
dbaron: Why does first-letter not work?
dbaron: Do you have example of that?
* liam has seen a Dutch example with a t’ at normal size, then the
Drop Cap
<astearns> http://etutorials.org/shared/images/tutorials/tutorial_77/figure10_16_quote.jpg
clilley: Commonly people use the example of punctuation.
plinss: But the punctuation will get the same size and you can
wrap them both as span.
TabAtkins: Where does the punctuation go when you drop the letter?
clilley: I'm not sure.
<liam> (and you need first-word for Hebrew)
dbaron: I haven't seen it with the punctuation not dropped.
hober: I've seen where to the left in the margin there's the
punctuation.
fantasai: We have a hanging-punctuation property for that.
<jdaggett> what's the common case that we're trying to support here?
<jdaggett> should aim to solve that problem *first*
<clilley> Example with initial letter and previous punctuation
http://www.lynda.com/InDesign-tutorials/Adding-hanging-punctuation-Optical-Margin-Alignment/114324/127131-4.html
<hober> l'hôtel
hober: A non-all-punctuation property is in French (see above).
hober: So the H is the drop cap.
glazou: No, it doesn't work like that.
clilley: I have a case in IRC where the punctuation is outside
the margin.
fantasai: And you can do that with hanging-punctuation.
hober: I want that to be handled. And if my French is wrong
that's okay.
glazou: No, the actual first letter (L) has to be the drop cap.
<dbaron> But in clilley's example the punctuation *also* has the
style/size, so you're fine.
TabAtkins: There should only be one thing so it doesn't have to be
limited.
dbaron: In clilley's case the punctuation is also resized.
clilley: The line indent is showing.
<clilley> example with first line indents
http://i.stack.imgur.com/45WNU.png
<SteveZ> What is hard in the clilley case is getting the negative
indent sized correctly.
<astearns> SteveZ: that should be done with a hanging-punct
property, imo
<SteveZ> hanging-punct property is OK if what is out dented is
the punct
fantasai: So to clarify text-indent and hanging-punctuation still
apply to the dropped text.
fantasai: We'll make sure that's in the spec.
plinss: We're done?
[question about where this gets specced]
TabAtkins: We've shipped a spec with one property, so we can do
what we want.
fantasai: We'll start in CSS inline and than we can split later if
needed.
End state of Whiteboard:
Bullets concerning initial-letters:
- glyph overflow is excluded, both dimensions,
- handle non-Alphabetic baselines,
- Subsequent paragraphs starting normal/wrap and non-normal
starting paragraphs and BFCs clear,
- omitted 2nd = 1st,
- Applies to: :first-letter inline-level and first child of a
block container,
- text-indent and hanging-punctuation still apply to the
dropped text (clarification)
<fantasai> Summary of discussion:
http://lists.w3.org/Archives/Public/www-style/2014May/0211.html
[break = 15 min]
Received on Wednesday, 11 June 2014 13:04:32 UTC