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

==== FULL MINUTES BELOW ======

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
          updated
  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
          <http://www.w3.org/mid/023DB250-5BFE-457E-8969-A42F8973DF70@apple.com>?
  <astearns> hober: I believe the control he's talking about could
             be addressed by allowing more than integers for the two
             values
  <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
          varies.
  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-
            dependent
  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
         values?
  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
          character.
  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
          cases.
  SteveZ: I have examples of others without boxes, align to western
          baseline.
  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 -
http://lists.w3.org/Archives/Public/www-style/2014May/0211.html
  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
             conclusions
  * 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:
http://dev.w3.org/csswg/css-inline/#initial-letter-exclusions
  * 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
           though.
  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
            space.
  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
           languages?
  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,
          etc.
  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
            paragraph.
  astearns: Why is that useful for determining the interpretation of
            <length>?
  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
         mean'?
  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
          is.
  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
           http://lists.w3.org/Archives/Public/www-style/2014Jun/0108.html

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

  <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
            baseline/capheight
  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
         fragment.
  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