W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-10 Part III: CSS Inline

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2015 17:49:39 -0400
Message-ID: <CADhPm3umVj_aQ3NcO+O673WECCJiT6SWD1KM2gwLPjb8jPi=WA@mail.gmail.com>
To: www-style@w3.org
CSS Inline
----------

  - RESOLVED: Add full kerning to css-inline, perhaps dropped later
              based on implementation experience, but try to figure
              out how it all fits together.
  - RESOLVED: Choose alignment points by using the top alignment
              point of each script and the bottom alignment point of
              each script.
  - Discussion of how run-in and ::first-letter interact will
      continue on the mailing list.
  - Alignment points presented several challenges, especially for
      Hebrew, which doesn't have relevant font metrics to use, and
      Arabic, for which the appropriate top point is unknown.
      More information and examples for non-Western typography are
      very welcome.

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

CSS Inline
==========

  Scribe: fantasai

  dauwhe: Wanted to go over some issues with initial letters.
  dauwhe: Then wanted to review css-linebox stuff.

CJK and Indic Initial Letters
-----------------------------

  [Slides available here:
https://lists.w3.org/Archives/Public/www-archive/2015Feb/0004.html]
  dauwhe: Florian raised various issues, here's the first one.
  dauwhe: Where initial letter is part of the same word, we want at
          least Latin text to kern back a little bit so that there
          isn't a break within the word.
  dauwhe: But don't want to do that for CJK.

  SteveZ: There are examples where you want to kern the second line
          as well.
  SteveZ: You want to follow the shape of the outline.
  dauwhe: We do want that, but the full effect of that would be the
          next level.
  SteveZ: By specifying what you're doing, you screw up the
          extension.
  fantasai: Yes, we want to do kerning around the shape of the
            letter eventually, but that's a stylistic choice: we
            decided to do the rectangular version first
  fantasai: We're not going to allow various behaviors. Have to
            define one or the other, shouldn't be up to the UA.

  <jdaggett> Is this discussion about the illustration in 2.9?
             http://dev.w3.org/csswg/css-inline/#initial-letter-position
  <fantasai> Yes.

  SteveZ: [...]
  Liam: There are examples that don't kern the first line of text,
        but they're not good examples. Should try to do it if we can.
  <liam> [not good - there were technological limitations in the
         past]
  [...]
  jdaggett: It think this is a feature that needs more work.
  jdaggett: e.g. distance from glyph outline to text needs to be
            controllable.
  fantasai: I think for controlling the distance you can use the
            margin on that side of the glyph.

  <tantek> A decade ago I had proposed ::first-letter('A') to select
           only first letters that were a capital 'A' in order to
           customize styling on it.
  <dbaron> I actually haven't found examples of follow-the-curve.
  <tantek> I found examples of follow-the-curve plenty over a decade
           ago.
  <astearns> http://graphicdesign.stackexchange.com/questions/10561/text-wrap-in-illustrator-cs6

  fantasai: From what Liam and dauwhe were saying is that the common
            case is kerning that first line, so that should be the
            default.
  fantasai: If you want a rectangle, you can add a transparent
            border or padding.
  SteveZ: The issue is should the kerning apply only on the top
          example, the rectangular one, or should it apply.
  SteveZ: What should be the default?
  fantasai: The way it works right now is that you only do this
            kerning if you have margins but not borders or padding.
  fantasai: We took the margin collapsing principle that the edges
            of the box are permeable if padding/border is zero.
  fantasai: So you can get both behaviors.
  fantasai: I think the model is fairly consistent.

  [argument over which is more common, clearly not clear]

  <dbaron> Yeah, I've seen a lot where the first line follows the
           initial letter outline, but I couldn't find examples
           where lines other than the first do.
  fantasai: You can add margins if you want more spacing, you can
            add padding if you want rectangularness.

  dauwhe: We could defer if necessary for implementations.
  fantasai: I would prefer to try for this.
  fantasai: There is a sensical mode. Wrt implementability, you need
            the glyph outline (which you have to have anyway, since
            that defines the content box of the initial letter).
  fantasai: And you need an offset control, which is provided by
            margin.

  [tantek talks about full wrapping]
  dauwhe: Case #3 is much more common and simple, prefer to defer it.
  Florian: Unless someone wants to argue that the bottom is
           undesirable or relatively bad thing that we don't want to
           be the default, then.
  Florian: I think the model is very sane.
  SteveZ: My concerns weren't that case #3 isn't desirable, but
          worried about separating case #3 and full kerning.
  SteveZ: Want to see how it interacts with full kerning.
  tantek: I'd like to see what full kerning would look like, and
          include it in the draft now, before cutting it.
  dauwhe: I'm okay, if that's where we want to go.
  [Liam, tantek, Szilles, fantasai agree on this approach]
  liam: As an implementer, think it's good to have all possibilities
        there, will help to organize your code appropriately.

  jdaggett: I want to make clear that I think the difference between
            the first option and the one that's in any way following
            the outline is an exponential order of time difference.
  jdaggett: Because you're looking at the glyph outline.
  jdaggett: Wouldn't imagine that a mobile browser wants to do that.
  dauwhe: Wouldn't it make sense to include this and then react to
          implementation experience later?
  jdaggett: I think this should be opt-in behavior.
  tantek: I think some implementors have motivation to do
          high-fidelity rendering.
  tantek: You mention mobile, I think that's a top use case.
  jdaggett: I don't think it's universally true that this is the
            optimal thing.
  jdaggett: It depends on the use case.

  jdaggett: The behavior of margins vs. padding is confusing to
            authors.
  dbaron: I agree that doing this based on padding/border being set
          is confusing.
  dbaron: Odd implicit thing that people won't get.
  dauwhe: Full kerning would need another switch.
  dauwhe: I think at this point it's worth doing the full thing,
          cost mostly on editors writing spec, and then check in
          with implementors later.
  <SteveZ> +1 for borders and padding being confusing in this case.
  <liam> +1 add and solicit more feedback
  <tantek> +1

  RESOLVED: Add full kerning to css-inline, perhaps dropped later
            based on implementation experience, but try to figure
            out how it all fits together.

Initial Letters with Different Script
-------------------------------------

  dauwhe: Florian brought up issue of what if initial letter is a
          different script than the surrounding text.
  dauwhe: Conclusion is you use the top alignment point of each
          script and the bottom alignment point of each script.
  dauwhe: E.g. "A" inside indic script shows cap-height to
          hanging-example, alphabetic to alphabetic.
  dauwhe: Florian has an example of this.
  Florian: Chinese-English dictionary.
  <Florian> example of mixed scripts
http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg

  RESOLVED: Choose alignment points as described above.

Run-in and ::first-letter
-------------------------

  dauwhe: Next issue is run-in.
  Florian: Combination of run-in and ::first-letter
  Florian: Having ::first-letter select the first letter of the
           original text seems very weird.
  Florian: Makes more sense to select the first letter including the
           run-in.
  Florian: Should either select that or select nothing.

  tantek: I lean towards selecting nothing, the author can select
          the first letter of the run-in.
  dbaron: Does ::first-letter apply to run-ins? I don't think it
          does.
  <tantek> but it could
  <tantek> ::first-letter *could* apply to something with
           display:run-in
  fantasai: I think dbaron' is right. Run-ins are defined as
            inlines, effectively. And you can have multiple run-ins
            run into the same paragraph, in which case one of them
            for sure won't be at the beginning of the paragraph.
  fantasai: So I'm not sure we can have ::first-letter apply to
            run-ins.
  fantasai: In which case, you'll want to have ::first-letter select
            the first letter of the first run-in in a paragraph,
            since there's no other way to do it.
  fantasai: Although I'm not a box-construction expert, so I don't
            know if that's sane.
  <dbaron> What decision are we trying to make right now?

  [fantasai explains run-in box model: old model was run-in is a
            block if it doesn't run into anything; new model it's
            always an inline, sometimes inside an anonymous block]
  Florian, fantasai: So if we want to do this, either run-ins need
                     to accept ::first-letter, or ::first-letter
                     needs to apply to to a run-in inside a
                     paragraph.

  SteveZ: Off-topic: the example on the screen is aligned to the
          x-height, not the cap-height
  dauwhe: The box aligns to the alignment points, it has padding and
          a background.

  [Discussion moved to ML]

Floats
------

  dauwhe: We had a discussion wrt floats and initial letter.
  SteveZ: Having a float that occurs in the 2nd line be 1 line down
          from the top of the paragraph is the worst behavior.
  fantasai: You run into a problem when you have a floating image
            somewhere in lines 1-3 -- in those cases you should
            clear the initial letter.
  Florian: [to SteveZ] that proposal would introduce a loop in the
           layout that doesn't exist.
  SteveZ: No, it doesn't, it already exists.
  <astearns> I think line 1 should be fine, floats in lines 2+
             should clear

  [discussion about whether floats moving up creates a problem]

  Rossen: Do you expect your proposed algorithm to work for only
          left floats?
  SteveZ: Yes.
  Rossen: Then your proposal only affects one side of floats.
  dbaron: We only have a problem on this side of the initial letter.
  dbaron: And I don't believe SteveZ. There's a problem.
  fantasai: Does anyone other than SteveZ think there is not a
            problem?
  [silence]
  fantasai: Okay, then I suggest someone explain it to SteveZ during
            a break, otherwise we'll spend the rest of the
            presentation explaining how floats work.

align to letter or box?
-----------------------

  [next slide]
  dauwhe: Want the ability to align the box as a whole including
          borders/padding/backgrounds.
  dauwhe: florian suggested that we use box-sizing to determine
          whether you align the letter or the box.
  astearns: I think it's a bit confusing to use box-sizing. It might
            be better to have that as a keyword in the initial-
            letter property.
  Florian: The initial letter-align property says which set of
           baselines to use.
  Florian: Must speak either of the letter or the box.
  Florian: If you're aligning a box, the baseline values mean
           nothing.
  Florian: Other values were about vertical centering of box once
           you have the box or something.
  Florian: We could have a different property for this switch.
  Florian: The nice thing about box-sizing is that... [missed]

  astearns: It made a lot of sense to have shape-outside key off of
            box sizing.
  astearns: But we were eventually convinced that having that
            conflation of concerns for box-sizing was something to
            avoid
  astearns: and that's why we put the keyword into the shape keyword
            itself.

  fantasai: Why not use initial-letter-align?

  Florian: What does padding do if you don't have this?
  Florian: Why not use box-sizing, since we've changed what we're
           using box sizing?
  fantasai: People put box-sizing on everything today, to make it
            border-box.
  Florian: Then by default in those pages you will align the border
            box.
  [...]

Alignment Points
----------------

  dauwhe: The initial indic req doc says that the bottom alignment
          point of indic scripts is the text-bottom edge (based on
          em box),
  dauwhe: but it is definitely not correct.
  [dauwhe shows example]
  dauwhe: You get very unrealistic results, don't seem to match
          examples I've seen.
  dauwhe: Because this alignment point is not a visible thing in the
          font.
  dauwhe: The bottom alignment point in these scripts is in fact the
          alphabetic baseline.
  dauwhe: Matches much more closely to real examples, and to things
          we can see in the fonts.

  dauwhe: Still have lots of questions about CJK.

  dauwhe: The top example here is Hebrew.
  dauwhe: One problem with Hebrew is that the font metrics don't
          seem to have a natural alignment point.
  dauwhe: There's a strong vertical rhythm along the top of the
          characters.
  dauwhe: There is a probable top alignment point there.
  dauwhe: But it's not an existing metric. It's not the x-height, or
          cap-height.
  dauwhe: Not sure what issue that raises for this.

  dauwhe: In the case of Arabic I have no clue.
  fantasai: I think the character you want to align to is the alef.
  fantasai: The top of the first letter at the beginning of your
            example. lam has the same height (normally).

  [dauwhe: projects a table of alignment points]
  dauwhe: The myth of hanging baseline.
  dauwhe: John Hudson made the point that most fonts typically don't
          implement the base table that specifies the position of a
          hanging baseline.
  dauwhe: And most software doesn't actually use the hanging
          baseline.
  dauwhe: They're not even sure if hanging base line is what happens
          in these scripts.
  dauwhe: Here's some examples of characters vastly different in
          size.
  dauwhe: What happens in every implementation I'm aware of is
          alignment at alphabetic baseline.
  dauwhe: Looking at CKJ, lots of options in indesign.
  dauwhe: Lots of questions about that.

Remaining Content for CSS Inline
--------------------------------

  dauwhe: And that's the intro to the next bit, the rest of CSS
          inline.
  dauwhe: Wanted to get a sense of what that needs to include.
  dauwhe: What needs to change from CSS2.1?
  dauwhe: Do we really need to define 20 kinds of baselines?
  dauwhe: To match bottom ideographic char frame with mathematic
          baseline???

  jdaggett: I think we have some issue with inter-group issue.
  jdaggett: SVG has a bunch of stuff taken from XSL.
  jdaggett: dominant-baseline and various properties.
  jdaggett: It's a huge number of values.
  jdaggett: Some people say this is a compat issue.
  jdaggett: But need to coordinate with SVG to see who's going to do
            what.
  jdaggett: Dunno what's actually implemented.
  jdaggett: Properties are parsed, but what's implemented?
  <jdaggett> example:
http://mxr.mozilla.org/mozilla-central/source/layout/svg/SVGTextFrame.cpp#328
  <jdaggett> Gecko dominant-baseline implementation.
  <ChrisL> Dominant baseline stuff was copied from XSL-FO yes and
           needs to be cleaned up
  dauwhe: Yes, I'm curious about what's happening in the wild.

  SteveZ: I was going to ask, in the indic example you have there,
  SteveZ: It's what browsers do today, but certainly not what
          happens in print.
  SteveZ: They do use that in print.
  dauwhe: I haven't actually seen an example of mixed-text sizes in
          the real world, other than drop-caps.
  jdaggett: I think we have to temper things with actual data that
            we get from fonts.
  jdaggett: We have to be careful of using theoretical models of
            what different baselines exist theoretically vs real
            world font metrics.
  * liam would guess Michael of RenderX would have actual real
         examples.
  dauwhe: Yeah, I don't believe anything until I can read it out of
          the font metric.

  SteveZ: That leaves you with real problem with Hebrew then.
  SteveZ: Sounds like you're going to end up synthesizing font
          metrics that you need.
  SteveZ: Existing font metric principle won't work.
  dauwhe: It's a starting point, not an ending point.

  dauwhe: Should we move forward?
  fantasai: Yes, even have some existing resolutions on what to add.
  jdaggett: Lots of stuff from SVG, XSL, don't want to add.
  fantasai: Yeah, don't want to copy from XSL.
  SteveZ: Vertical-align had made some assumptions, so XSL was to
          make vertical-align be a shortcut.
  SteveZ: Wanted to place things, not just glyphs, but also images.
  SteveZ: The list of baselines is unimportant. There was some set
          that was useful that you might get at.

<br type='lunch'>
Received on Wednesday, 18 March 2015 21:50:07 UTC

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