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

[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-09 Part III: Initial Letters

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Oct 2014 14:08:58 -0400
Message-ID: <CADhPm3v=5W+YFAobatNNUCuKrmbVCyqu2xyghnPGBikSFR_rJg@mail.gmail.com>
To: www-style@w3.org
Initial Letters

  - RESOLVED: Publish FPWD of CSS-inline with initial-letter section
       intact, and 2 prior sections pointing to appropriate parts of
       2.1, with note that they will be updated.
  - RESOLVED: initial-letter depends on line grid spacing or (if
       none) line-height of containing block. Does not depend on
       content of the lines.
  - RESOLVED: initial-letter does not have longhands
  - RESOLVED: Order of values is size first, drop second (as decided
       in previous F2F)
  - RESOLVED: size is a <number>. Alignment point is determined by
  - There were some unresolved concerns about the best approach to
       handle initial-letters with combining marks.
  - Discussed cases where the alignment subject should be the glyph bounds
       vs. the margin-box bounds.
  - Ruby's interaction with initial letter was also an area of concern.


Scribe: fantasai

Initial Letters

  dauwhe: To my surprise and delight, WebKit implemented initial-
          letters last week.
  dauwhe: We also got feedback from dhyatt.
  dauwhe: There's a thread on www-style about that.
  dauwhe: Firstly, we should have a WD, since people are doing this.
  dauwhe: It's part of CSS Line layout, which is our oldest WD...
          from 2002
  dauwhe: Can we publish a WD of the whole thing?
  fantasai: I think we just comment out the rest of it.
  SteveZ: Put a note saying that the text is under development.

  hober: Is there enough useful content in the old...
  SteveZ: No.
  SteveZ: There is useful content in the old stuff, but it's in an
          inconsistent half-revised state
  SteveZ: So it's really difficult to read unless you know what it's
          supposed to say
  SteveZ: That keeps the pieces together, but lets you get it out.
  SteveZ: Leave sections 1 and 2, replacing text with a note.
  hober: We want to publish a new WD of this thing, cool. In a thing
         already had FPWD.
  <dbaron> I think some of the problem was that back in 2003 I was
           afraid of being too destructive of the material already
           in the draft.
  dbaron: Probably also another pass through for patent policy.
  dbaron: So probably need another FPWD for patent policy.

  hober: I'd like initial-letter to go through FPWD soon.
  dauwhe: We talked about possibility of splitting it.
  SteveZ: My suggestion for dealing with that is not to leave it
          blank, but point to 2.1 as the most up-to-date description
          of the content of these sections, and that it would be
  SteveZ: Well, point at appropriate sections of 2.1.
  fantasai: You would want to make sure the first-letter clearing
            behavior that we discussed at last f2f is in the spec.
  dauwhe: Yes, it should incorporate all recent feedback.

  [discussion of publishing vs. upcoming edits]

  SteveZ: We can resolve on the plan.

  RESOLVED: Publish FPWD of CSS-inline with initial-letter section
            intact, and 2 prior sections pointing to appropriate
            parts of 2.1, with note that they will be updated.

  dauwhe: First issue is, should initial-letter be a shorthand for
          initial-letter-size and initial-letter-drop?
  TabAtkins: I think fantasai made a convincing argument that no,
             they shouldn't.
  florian: What was the argument?
  TabAtkins: They don't want to cascade independently.
  <florian> I then agree with Fantasai's point

  <hober> Re: shorthand or not, what about hyatt's point in
  <astearns> hober: I believe the control he's talking about could
             be addressed by allowing more than integers for the two
  <hober> astearns: or at least a <length> for the height, yeah

  SteveZ: I have an issue with the two things.
  SteveZ: In looking through my collection of various documents from
          various languages
  SteveZ: The size really only works for Western alphabets and
          doesn't really work for Indic, Thai, etc. Probably Tibetan
          as well. These have stacked bits, so the size of something
  SteveZ: You can't say the number of lines and figure out the font
          size, it might not quite correspond.
  Bert: If I say my letter is # lines high, then what if those lines
        actually don't have all the same size?
  SteveZ: I think you use the paragraph size.
  dauwhe: ...
  dauwhe: Use baseline grid, or set the line-height.
  florian: Might want to draw distinction between content of line
           making the line taller vs. using line grid

  [dauwhe describes the circular dependency of initial-letter size
       and number of lines if content is accounted for.]
  florian: Does that take into account things like line-grid and
           anything that can affect the line height other than
           content of the line?
  fantasai: I think we can resolve that it's using the line grid, if
            using line grid; else line-height of paragraph.
  SteveZ: Yes. Which is kind of an implicit line grid.
  dauwhe: What's the term for that, line-height?
  fantasai: 'line-height' of the containing block.

  RESOLVED: initial-letter depends on line grid spacing or (if none)
            line-height of containing block. Does not depend on
            content of the lines.

  hober: Next issue is for non-Western cases you probably want to
         specify a length, not just number of lines, for cap-height
  astearns: perhaps alignment as well, e.g. top-aligned.
  fantasai: For CJK, I think Bobby Tung pointed out that you want
            ICF Top or Bottom, not the em box or cap-height
  fantasai: A lot of the font size tweaking for CJK is to get to the
            ICF size, but we can calculate that from font metrics.
  dauwhe: Probably needs to be language-dependent.
  fantasai: In many cases might be script-dependent, not language-
  SteveZ: Depends on conventions.
  [of course]

  dauwhe: We have formula for font-size in CJK, based on the
          paragraph text size and number of lines dropped.
  fantasai: I think he was just saying, you account for the gaps...
  astearns: If there are adjustments needed.
  hober: Yeah. And I think we can put a length there.
  hober: We have 2 values, right now. If you put one, it gets
         duplicated. What if 1 value is a length?
  fantasai: I think you can have an auto value for the drop, and
            that would calculate the drop from the length value
            given in the size.
  hober: Does that suggest we should switch the order of the two
  fantasai: maybe?
  <fantasai> (probably, yes, size should be first)
  <hober> IIRC in Seoul we had size first
  <hober> not that that matters
  <fantasai> Did the spec accidentally switch that?
  <hober> yup.

  [SteveZ shows an example of Kannada magazine article. The first-
       letter is centered inside a box with a border]
  SteveZ: The top of the box is what's aligned to the cap-height,
          not the characters.
  SteveZ: And the characters in the box are centered inside of that.
  [astearns points out that the box is not really aligned to the
       text though we could pretend they were trying]
  SteveZ: We can tell that the emphasis is on the box, not the
  SteveZ: So trying to do something that's focused on the size of
          the font in terms of lines, that might work well for
          Western text, but not necessarily for other text.
  fantasai: Depends on the effect you're going for. In Western text,
            a fancy illuminated letter might have same behavior.
  SteveZ: Might need to be able to specify the alignment.
  <astearns> my suggestion for the box case is to use a line-grid
             and box-snap the border box of a float to the grid

  SteveZ: I'm wholeheartedly in favor for simple syntax for common
  SteveZ: I have examples of others without boxes, align to western
  SteveZ: The way we've done this, it's very difficult to come back
          and say, use a different alignment point, or pick a
          different font-size.
  SteveZ: Need to think about ways to extend what we have.
  SteveZ: I don't have any great ideas, except that you want to
          define a font size, not a height.
  dauwhe: This looks like single value-d thing that says "I want my
          box to take up 4 lines, and I want my letter centered in
          the box."

  hober: :first-letter without initial-letter can do these cases
  fantasai: Not really. Sizing of the box won't work if the glyph
            isn't centered in the em box to begin with (e.g. Latin
            letter A)

  dauwhe: Is there a possibility of having some value of
          initial-letter-align, that could be chosen in this case?
          If I pick this value, align the top to the aligning
          baseline, etc.
  SteveZ: We already made a comment that they don't cascade
          independently for the 2 values we have now.
  SteveZ: I'm guessing that this is a multi-value property rather
          than an independently cascading thing.
  florian: That one does make sense as an independent property.
  fantasai: Might be able to reuse vertical-align.
  SteveZ: The alignment stuff in the section we're dropping has
          enough stuff, except it doesn't say whether you want the
          top/bottom/center alignment.

  astearns: I don't think we should be trying to avoid the
            complexity of all these points.
  astearns: I think we might postpone it, work on a 2-value
            property, knowing that in the future we may be adding
            alignment points in the future.
  florian: If we want to use vertical-align, we need to figure that
           out now.
  astearns: I think vertical-align doesn't have enough...
  SteveZ: astearns noted there's a distinction between aligning to
          the center of the middle line vs aligning to the center of
          a whole block, because lines might not be equal in size
  <fantasai> hober -
  fantasai: But we're assuming they are...
  dbaron: But should we be making that assumption?
  fantasai: I guess if we have :first-line styling, we should
            account for that.
  * fantasai is a bit annoyed that the draft doesn't follow the F2F
  * fantasai wrote those all out *very clearly*
  * fantasai dauwhe, you did a pretty bad job of copying the f2f
             conclusions into the spec if you got the ordering wrong

  [discussion of multi-pass algorithms, scribe missed the context]

  astearns: There's virtue of having consistent size for initial
           letters and virtue in dropping consistent number of lines
  dauwhe: Web authors are already confused about superscripts
          disrupting line rhythm.
  dbaron: There's 2 solutions for that in the inline module.
  hober: Sounds like we should allow use of <length> as well as
         <integer> for height.
  dbaron: Well, does the height mean the font-size or the box height
          or the glyph height...?
  <dbaron> (i.e., the glyph height that in the <integer> case you're
           aligning to cap-height and baseline)
  astearns: What if instead of a length, we allow a percentage, that
            is a percentage of what auto would have been?
  fantasai: That doesn't seem useful. Unless you know the font's
            glyph proportions.
  astearns: Well, font-size is similarly not useful.
  Bert: It's useful for initial caps.
  <chrisl> What happens with initial letters which are capitals and have
           accents above the cap height?
  <chrisL> Or initial letters which have descenders below the bottom
          of the first line?
  <astearns> fantasai:
  * fantasai right

  * hober wonders about <p><ruby style="initial-letter:3">...
  <fantasai> fun
  <fantasai> Could say it doesn't apply to ruby
  <fantasai> Alternately, treat ruby as ascenders/descenders
  <hober> What about inter-character ruby?
  <hober> (which hyatt has a patch for, btw)
  <fantasai> Include that as extra "letter" in :first-line -- takes
             up advance
  <hober> Yeah, ascender in the normal case & that for bopomofo.
          Makes sense to me.

  [hober explains the exclusion principle]
  <chrisl> Exclusion is fine for descenders. Does not cover accents
  SteveZ: Another parameter is whether you push things down for
          stacking, combining marks, etc.
  dauwhe: There's a similar problem with accents above.
  dauwhe: We want to maintain a consistent font size.
  florian: Do we make sure we clear the stacked accents?
  fantasai: I think we do need to push it down to make sure there's
  dbaron: Economist does initial-caps that cover 2 lines. Js and Qs
          indent 3 lines
  florian: Question was about accent *above*
  SteveZ: Angstrom symbol
  florian: [...]
  florian: If you take J with circle on it, say how it clears, it
           works for that letter, why would that not work for other
  SteveZ: It would solve the no-collision problem. Wouldn't
          necessarily solve the artistic problem.
  SteveZ: Sometimes it's very hard to compute what that extra piece
          is in both directions..
  SteveZ: You could use the bounding box, although in some fonts the
          bounding box isn't the bounding box...
  SteveZ: E.g. in swash fonts, the bounding box often doesn't
          include parts of the ink.
  florian: Isn't the point of that so that you do get collisions?
  SteveZ: Yes, but people kept overloading things, so,
  SteveZ: There's 3-4 sets of ascender/descender information.
  SteveZ: It got misused, people redefined it, it got misused again,
  SteveZ: I don't see us getting anywhere.
  <chrisl> I'm asking on John Hudson and JF Porchez on twitter about
           initial letter with cap accent

  <Bert> -> http://www.w3.org/Talks/2013/1003-Style-Amsterdam/scan-17.jpg
         An old manuscript with drop caps that cause non-rectangular
         exclusions even in other flows than its own.

  SteveZ: One way out of this;
  SteveZ: Is it more important that the font size stay consistent or
          that the line incursions stay believable?
  SteveZ: You can't do both.
  SteveZ: If we pick one, then answering what length means will be
          an easier thing to do.
  dauwhe: I strongly support font-size consistency.
  SteveZ: Me to.
  SteveZ: Assuming we want to keep font-size consistent, then we can
          solve the problem of what length means by describing how
          it sets a font size
  SteveZ: So, if you use the same length everywhere, you'll get the
          same font-size.

  hober: I have 12pt paragraph, initial-letter: 3
  hober: Are you saying that's equivalent to 36pt?
  SteveZ: No.
  SteveZ: There's a rule for each script that converts 3 lines to a
          point size.
  SteveZ: In a Latin font, it would take cap-height.
  SteveZ: Whatever fits there, that determines the font-size
  dbaron: You also have to account for line-gap, difference between
          cap-height and baseline, etc.
  dauwhe: In Latin we know the alignment points, so based on that we
          can just calculate it.
  dauwhe: For CJK we have a different calculation.
  <dbaron> dauwhe was just giving the formula just below the figure
           in http://dev.w3.org/csswg/css-inline/#f2
  astearns: We have this calculation, that results in a font-size,
            given a value of 3,
  astearns: And it will be consistent for a given font in a given
  astearns: Why is that useful for determining the interpretation of
  dauwhe: If I say 30pt instead of 3 lines...
  SteveZ: You do the same thing. You imply a top-alignment point and
          a bottom-alignment point, and adjust the base doing the
          same thing.

  fantasai: I don't think that was what we were trying to solve.
  hober: We're trying to solve the problem of 'what does a length
  fantasai: That seems like a really backwards way to do things.
  dbaron: If it's not clear what this other thing should mean, but
          we want to allow authors to make fine-tuned adjustments,
  dbaron: Then maybe we allow <number> instead of <integer> and
          authors can tweak it until they're happy.
  astearns: Until we add additional alignment keywords, no, you only
            get one alignment, and we choose it per script.
  <dbaron> <number> greater than or equal to 1
  dbaron: Because that could give you a negative size.
  * fantasai didn't understand that
  <dbaron> Given 'line-height: 3', then 'drop-initial: 0.5' would
           give a negative size because of the N-1 in the formula in
           http://dev.w3.org/csswg/css-inline/#f2 being more
           negative than the positive part.
  hober: Use <number> instead of <integer> for height. When <number>
         is not an <integer>, precise alignment is TBD.
  SteveZ: If it's an integer, you have 2 alignment points.
  SteveZ: If it's not an integer, then there's only one alignment
          point. The script will indicate what that alignment point
  fantasai: And you can use vertical-align to tweak it :)
  SteveZ: With Florian's other piece, given an alignment point and
          you have something that extends above, what do you do?

  RESOLVED: initial-letter does not have longhands

  RESOLVED: Order of values is size first, drop second (as decided
            in previous F2F)
  <dbaron> Previous F2F minutes were

  RESOLVED: size is a <number>. Alignment point is determined by

  <chrisl> Is the order different in the draft because of a
           transcribing error or was it deliberate?
  <dauwhe>: It was deliberate due to mailing list discussion.

  fantasai: Drop if you don't have an integral size?
  SteveZ: Round up.
  astearns: Sylvain and I have been working on a JS library for this.
  astearns: We will make it public soon.
  dauwhe: What do we do with regards to alignment?
  ?: We aren't sure yet
  florian: Might want it to be independent.

  <dbaron> OK, I've been looking for a Scandinavian newspaper that
           uses drop caps so we can find examples of drop-Å in the
           wild, and finally found one: Dagens Næringsliv
  <dbaron> http://www.face2face.se/uploads/blog/6593bda3d9d72bfef9cafacb5d21ad7ac2777949.png
has a drop-Å

  Bert: Is the size of the border the size of the box, or size of
        the letter?
  fantasai: Issue of where borders go, it would go around the glyph
            bounding box.
  Bert: Does the initial-letter property now refer to size of the
        box? Or size of the glyph?
  fantasai: I can see wanting both ways. e.g. T that rests on the
           bottom baseline and top capheight and has a border around
           it which is excluded around.
  fantasai: Or wanting that box to be sitting on the
  fantasai: Probably you need a switch.

  [discussion of drop-shadows, other effects]

  fantasai: Use margin box to control exclusion. Can always make it
            larger or smaller (negative).
  <hober> In <4187383B-5D9F-4317-9AA1-36D4B04B19CF@apple.com> points
          3 and 4 cover this, though the w3.org archive of it
          doesn't contain the images :(
  plinss: I don't like magic of e.g. changing sizing behavior based
          on whether there's a border or not.
  plinss: Do we have an answer here?
  fantasai: We might make the switch part of how we do alignment.
  fantasai: If the content box is drawn around the glyph bounds,
            then you get equivalent behavior to what we have when
            everything is zero. You can then tweak things from there.
  fantasai: The exclusion area would be the margin box.
  fantasai: The question here is whether the alignment area matches
            that box or matches the character.
  [Bert asks about illuminated letters]
  fantasai: That's why we allow initial-letter to be applied to
            inlines. You can apply it to an image.
  dauwhe: The height from initial-letter applies to the image.
  fantasai: You use the content box instead of the font metrics.

  <sgalineau> Does initial-letter apply to ::first-letter?
  <fantasai> yes.
  <fantasai> Also to the first inline of a containing block.
  <fantasai> The main use case is ::first-letter, but could use
             <span> for first-words.

  <hober> fantasai and I were emoting about how ruby behaves with
          initial-letter. Consider <p><ruby style="initial-letter:3">
          <rb>私<rt>わたし</ruby>は...& lt;/p>
  [hober summarizes IRC discussion about ruby]
  dbaron: Seems like a lot of work for a weird case.
  fantasai: Could make it optional. You *may* apply it to ruby, and
            if you do so, you do it this way.
  dbaron: Do you increase the annotation size?
  * fantasai assumes so
  SteveZ: jukugo ruby, and breaking...
  hober: initial-letter applies to the entire inline, not the whole
  dbaron: That's the easy case. What if you have ::first-letter and
          the first child of the block happens to be ruby?
  SteveZ: I think you say it doesn't apply.
  dbaron: I'd be happy with that.
  [discussion of what ought to happen if something does happen]
  SteveZ: The annotation gets adjusted accordingly.
  SteveZ: Along with the first letter of the base.
  plinss: I think we're in a weird corner and we should take a
          break, and you can discuss over a break.

  [discussing dbaron's negative for < 1 problem. Seems like just
       flooring the number of affected lines at 1 would work fine,
       you can still use 0.5 as a size]
Received on Wednesday, 15 October 2014 18:09:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:25 UTC