W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Seoul F2F 2014-05-20 Part III: CSS Line Layout

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Jun 2014 09:03:59 -0400
Message-ID: <CADhPm3u78cbCju5fv1tvHD+4u9dESWufhN5uNLnW8dckXwsoNQ@mail.gmail.com>
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
      - 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 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
  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
  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:

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

  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].


  <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
  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

  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
  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
  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

  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
  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
  <dbaron> Steve's example:
  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
  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
  SteveZ: There's a fair amount of baggage, some of which is already
          there, just to do that example.

  <clilley> drop caps in scribus

  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
  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,
         shows that (using metal type so the baseline didn't align
  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
  dauwhe: That's one concern I had with the current approach. That
          there were all these things with options when we need a
  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
  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
  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
  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
  <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
  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 -
  <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
  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
  <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
  <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
  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
  <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
  dbaron: In clilley's case the punctuation is also resized.
  clilley: The line indent is showing.
  <clilley> example with first line indents
  <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

  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:

  [break = 15 min]
Received on Wednesday, 11 June 2014 13:04:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:43 UTC