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

[CSSWG] Minutes Paris F2F 2015-08-26 Part IV: CSS Inline [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 11 Sep 2015 14:40:24 -0400
Message-ID: <CADhPm3uSq3+obmrkqyrmf_0zJwuo+6T1XdgFdz1ax=ihYrmBUg@mail.gmail.com>
To: www-style@w3.org
CSS Inline

  - There was discussion on if the multiple values of
      alignment-baseline are necessary.
      - alphabethic, central, and auto were agreed to be necessary.
      - top, bottom, and center were considered awkward because they
          weren't actually baselines
      - There was no decision on the others and they will need
          further conversation
  - Google asked that figuring out glyph boundaries in
      initial-letter be marked as at-risk because it will be time-
      consuming for them to implement.
  - Issues that need to be added to the spec are:
      - What happens when baseline is not in font
      - Add width and height to prop for initial letter
      - Add a complete list of things that can be applied to
      - Which baseline keywords do we need to keep
      - Mark initial-letter-wrap as at-risk
      - Where do before-edge and after-edge come from?
  - RESOLVED: Add a length value to initial-letter-wrap
  - RESOLVED: Publish an updated WD of CSS-Inline


  scribe: dael

CSS Inline: Baseline Alignment

  <fantasai> https://drafts.csswg.org/css-inline/
  fantasai: We updated the draft based on feedback from previous F2F.
  fantasai: Things that are different: we filled out a bit of the
            first chapter which defines vertical align. We defined
            the dominant-baseline property. The two longhands for
            'vertical-align' are there because SVG needed them
  fantasai: That's roughly that. The definitions are straightforward.
            The alignment-baseline has several values: auto |
            text-bottom | alphabetic | central | mathematical |
            hanging | text-top. If any should be dropped, let us
            know. We have to have alphabetic and central and we need

Hanging Baselines and Fallback for Missing Metrics

  jdaggett: You need clear definition of the fallback. There are
            fonts that could have hanging baseline, but in the real
            world there almost never are. Implementations fallback
            to baseline all the time.
  astearns: So we should omit hanging baseline?
  jdaggett: Hanging and maybe mathematical are not widely supported.
  jdaggett: Type designers design their type so it lines up with
            other glyphs the way they want it to. When you're using
            multiple fonts, how will they line up - it's not always
            good. The information I think the spec needs isn't there.
            We need to define the fallback clearly.

  SteveZ: First is, hanging baseline alignment is not uncommon in
          the parts of India that use the hanging baseline. How they
          achieve it I don't know.
  jdaggett: That's my point.
  SteveZ: The second point is it seems to me we ought to be focused
          on what the user wants rather than what the font provides.
          I would rather a fallback way of calculating the hanging
          baseline, i.e. fiddle with it until it fits, rather than
  jdaggett: We have text-top and if you look at the open type table
            for baselines and the hanging baseline is described for
            what's used in Tibetan. Are we talking about the hanging
            baseline or are we talking about text-top?
  jdaggett: In the open type definition of the baseline table there
            is a hanging baseline defined, but it's desc as the
            baseline used for Tibetan. What is it you're really
            wanting to use this for? Perhaps it's some other

  <dauwhe> John Hudson: " The BASE table specification also gives
           examples of a ‘hanging baseline’ setting for Devanagari
           script, but I’ve yet to see this implemented in either
           fonts or software, and I believe it is based on a
           mistaken notion. "
  <fantasai> Is it a mistaken notion because nobody implemented it,
             or a mistaken notion because nobody wants it?
  <ChrisL> Baseline table spec -

  SteveZ: I want to use it for Devanagari, Bengali, Gujarati, and
  SteveZ: I understand hanging baseline was intended for those, but
          it wasn't defined. For all of those I have examples of
  jdaggett: So what are the mechanics of that?
  dauwhe: Do you have an example of digital content that does this?
  SteveZ: Printed document. Newspapers. It's an everyday occurrence.
          It's what people want to do. When you say what are the
          mechanics, I don't know what the newspapers are doing.
  SteveZ: What I would do is measure the glyph: the hanging baseline
          is pretty obvious if I look at the bitmap of the character.
          That would be my fallback.
  jdaggett: You want to infer the metrics from analyzing the bitmaps?
  jdaggett: That feature will never be implemented.
  SteveZ: People do it all the time and this is particularly ID-able.
          When metrics are missing you need some method to fill it
  tantek: Do you have an open issue on when metrics are missing?
  SteveZ: Yeah.
  ChrisL: You can put a BaseScriptTag in for any language you want
          so I don't see why that would be impossible.
  <ChrisL> eg “devn”     BaseScriptTag for Devanagari script

  jdaggett: My question is, I don't see fonts supporting this. You
            clearly need a fallback and I don't think analyzing
            bitmaps is a good solution.
  SteveZ: We can record the issue and move offline.
  dauwhe: And we can record the alphabetic font line.
  SteveZ: There's some subtle points like with the hanging baseline
          where the line is bigger on the initial cap then the body
          text and there's an issue as to where you align to, but
          that's a subtlety. People do align to the hanging line.
  SteveZ: I think the equivalent of the news magazines do this on a
          regular basis.

  fantasai: Question is do we keep all the values, or do we drop?
            Auto central and alphabetic have to stay.
  SteveZ: And ideographic.
  fantasai: I don't have that in spec.
  SteveZ: It's used in fonts. In alignment in Japanese it's equally
          likely to be horizontal. Text-bottom kind of works in that
  fantasai: I think text-bottom isn't what you want.
  SteveZ: You're right.
  fantasai: I wonder if text-top and -bottom are needed.

  ChrisL: I'd like to understand, the fonts don't currently have
          this table but they're used anyway. Are existing fonts
          going to be changed to add these things in or are these
          features that nobody uses?
  SteveZ: Some font vendors supply the tables, relatively few supply
          them because the way their production tools work doesn't
          make it easy for them to produce the tables and nobody was
          using them anyway. They were finding other methods to align.
  SteveZ: Because we're trying to do it automatically we need to be
          more hospitable to the requirements people have.
  <jdaggett> baseline table data: under OSX 10.8, 810 fonts, 41 with
             BASE table (all CJK fonts)
  liam: In particular some of the countries with hanging baseline
        have been slow to join the standardization efforts. If you
        look at some scripts, they're not even supported by unicode.
        They're using old bitmap or postscript fonts, but it's
        changing fast.
  <jdaggett> there's no harm omitting values for which we *can't*
             support properly at this point
  ChrisL: It's changing fast and they're moving to unicode, so it
          seems like a bad time for the WG to remove baselines that
          they might use. We can't pretend they are using them so we
          have to explain how they're used. Presumably the spanning
          engine in the browser knows. If it knows get it to tell
  jdaggett: Why does it have to know where the hanging baseline is?
  SteveZ: Same font, but not same size.
  jdaggett: We don't have data here to establish this. Coming up
            with ways to wing it isn't good for this group.
  ChrisL: The rendering engine is winging it so we use that.
  jdaggett: It's not winging it. They're laying out on a baseline to
            look right.
  ChrisL: Within a single font
  jdaggett: Precisely.
  <jdaggett> there's no magic here guys, if the font isn't providing
             these metrics the shaping engine is not creating it.
  <Bert> -> https://www.microsoft.com/typography/otspec/baselinetags.htm
            OpenType tag registry for "hang", which says "The
            hanging baseline. This is the horizontal line from which
            syllables seem to hang in Tibetan script."

  * r12a waves
  * fantasai waves back
  <fantasai> we're discussing baseline tables
  <fantasai> https://drafts.csswg.org/css-inline/#dominant-baseline%20property
  <fantasai> r12a, question atm from me is, which baseline values do
             we need atm?
  <fantasai> r12a, thought you might know
  <r12a> i've never really done the research i should wrt baselines -
         i heard some interesting comments from John Hudson recently
         hinting at some  myths surrounding use of hanging
         baselines, but it's only rumour really until i/we
         investigate further
  <r12a> i suggest we discuss in email and include people like John
  <r12a> the comment from John i referred to came up in the
         discussion about first-letter

Baseline Values to Keep

  fantasai: Anyway, I need a list of what values need to go into
            this spec. I'm hearing conflicting information. One is
            support the hanging baseline because people need it and
            if it's not provide fallback; and that if we support it
            will encourage people to use it. The other side is don't
            put it in there because people don't use this.
  tantek: It's a signaling method.
  jdaggett: It's not, it's a sign that it needs to be simulated.

  fantasai: What about the mathematical baseline? Text-bottom,
            text-top? I put everything in the spec.
  SteveZ: Text-bottom and -top have been in since CSS 1.
  dbaron: You can't change vertical-align.
  fantasai: This is the dominant-baseline property, we can drop
  fantasai: I'll keep all the values until I get an actual answer.
  tantek: Capture the issues on the ones where people are
  <jdaggett> sure
  <dbaron> dominant-baseline in SVG is

  SteveZ: On hanging baseline if the fonts don't provide the data,
          what do we do?
  dauwhe: And we can contact the indic layout group through Richard.
  tantek: I think this document is early enough that we can capture
          each issue inline.
  <jdaggett> counter example - small-caps glyphs have existed in
             fonts for 20 years
  <jdaggett> but up until a couple years ago, no browser used them
             for 'font-variant: small-caps'

vertical-align and its longhands

  fantasai: Next is vertical-align which is shorthand for
            baseline-shift and alignment-baseline.
            Alignment-baseline takes the same values as dominant-
            baseline plus bottom, top, and center as well as middle
            because that was in CSS 2.1. Center is new, I think.
  fantasai: Baseline-shift is you align to the baseline and then you
  SteveZ: So you need to clarify the text that you compute the
          baseline alignment first and shift it second.
  fantasai: I think it's fairly clear, but I'll check.


  jdaggett: I think the spec needs to talk about use cases. What's
            the use here for setting dominant-baseline and adjusting
            the baseline?
  dbaron: My memory of SVG is dominant-baseline gets used for
          something additional in SVG which is not in CSS. With SVG
          text when you say place at this x and y coordinate, the
          dominant-baseline says what you align to that point.
  <dbaron> (my comment about SVG explains why text-before-edge and
           text-after-edge are important)
  ChrisL: That's correct.

  SteveZ: Traditional answer is in the open type spec there are
          multiple baseline tables and it depends on which baseline
          is dominant. If you're doing Japanese in and English
          context it's a different table than English in a Japanese
  fantasai: That seems different from what I understood.
  fantasai: The dominant-baseline is the baseline you use to align
            the boxes. It has no effect if the font doesn't change.
  SteveZ: There are different tables for different dominant
          baselines. In the open type spec there is a baseline table
          for each dominant-baseline. One of the reasons to have a
          dominant-baseline is to say which set of tables you're
  jdaggett: That establishes the position. It would be nice to see a
            use case in the spec.
  fantasai: According to the spec right now, you have a baseline
            table it has multiple baselines, alphabetic, top,
            central, etc. The position of these baselines is
            determined by the font size.
  SteveZ: A font can have multiple tables and the dominant chooses
          which one. Each table has a set of baseline offsets.
  fantasai: So if there are four baselines each of four tables would
            have four offsets.
  <jdaggett> there's *one* BASE table which contains information for
             multiple baseline definitions
  <jdaggett> a font doesn't have multiple BASE tables...
  <jdaggett> spec needs an example that explains how
             dominant-baseline and vertical-align define where text
             is placed along a line

  fantasai: If I have a font that's got 0 coordinate as the
            alphabetic baseline, above it there's 800 units which
            gets me text-top and -200 units which is text-bottom.
            There's a central at 300. This gives me four baselines.
  fantasai: You're saying that's one baseline table and the font may
            have an additional table that has a different alphabetic.
  SteveZ: You don't need a baseline table for your example. That's
          not the way baseline tables are done. They have values for
          these things in the table. In this case the position of
          the Japanese text in an English language context it might
          be -100 instead of -200.
  SteveZ: The English tends to be centered in the Japanese space,
          but Japanese in English puts the Japanese higher.

  astearns: We started this with thinking there should be
            justification for this section of the document. We're in
            the weeds. Let's just put some pictures in the document
            and have a note that we need those and move on.
  SteveZ: I sent a note to the WG about how it's calculated.

  fantasai: There's one thing I'm confused about. There's a single
            font in a single size. You're saying depending on the
            baseline the glyphs switch up and down?
  SteveZ: Because you switched which is dominant.
  fantasai: What controls that?
  SteveZ: Baseline table.
  fantasai: And it's correlated with different glyphs in the font?
  SteveZ: No. Where they are relative to the dominant-baseline can
          differ. Let's take this offline and I can produce and
  plinss: Let's take it offline and move on.

  SteveZ: I agree with jdaggett that we need an example and I think
          I can come up with one.
  fantasai: The examples in the spec I wrote if the dominant-
            baseline is alphabetic and you have two different fonts,
            you will find the alphabetic on each glyph and you will
            align those.
  SteveZ: That's the default.
  fantasai: That's for alphabetic. If you're using central baseline
            as dominant you align the two central points.

  fantasai: The clear use case is in Japanese vertical text you have
            a central baseline. You don't want alphabetic alignment
            in vertical Japanese text.
  fantasai: But for English text, you would want alphabetic alignment
            within that context.
  fantasai: Automatically in vertical we use central and the
            horizontal we use alphabetic, but you may want to switch
  <Bert> -> https://www.microsoft.com/typography/otspec/BASE.htm
            OpenType explanation of Dominant Baseline

vertical-align and its longhands (cont.)

  plinss:  Anything else?
  fantasai: There's an issue here where we have top, bottom, and
            center keywords. I shoved them into alignment-baseline
            property because I didn't want to make a separate
  SteveZ: I sent you a proposal a couple hours ago that said I think
          it makes sense to do them as a separate longhand and make
          it exclusive with the other two. It's either or because
          they're in sub trees. You couldn't shift a centered
          subtree. It doesn't seem to me it would be a big thing.
  fantasai: Having two properties in CSS trying to control the same
            thing is you can't say which one wins.
  SteveZ: One shorthand.
  fantasai: The shorthand doesn't matter.
  SteveZ: The default for the third property is auto which is the
          other one wins. You have to put in a value for it to take
          effect and if you do you can't use the other value.
  fantasai: I don't like that kind of conflict model.
  SteveZ: It's consistent with existing vertical-align.
  fantasai: We can also put those in the alignment-baseline property,
            which removes the conflict.
  SteveZ: It seems it's easier to have syntactic conflict.
  fantasai: But then you have authors that set something to not auto
            and they're wondering why the alignment-baseline didn't
            take effect and it's become someone else set it to not
            auto. Conflict resolution for CSS is cascading and it's
            better to avoid doing these one property always wins and
            hopefully it didn't change when you didn't mean it to.

  SteveZ: But nothing you said is fixed for your solution. Right
          now, baseline alignment can take either a baseline or
          subtree alignment. If I set a subtree it wipes out
  fantasai: You can't do both simultaneously anyway.
  SteveZ: So you wiped it out.
  fantasai: If I have a rule on this stylesheet here and I have
            another rule over here then the second overrides the
            first because it's later in the cascade.
  SteveZ: I understand.
  fantasai: That's why they're all in one property even though it's
            not really a baseline.

  fantasai: That's it for the top.
  <dbaron> http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#baseline
           has some pictures, for what it's worth

alignment-point for images

  SteveZ: The last comment I made is you don't have the alignment
          point property and that was in there to spec alignment
          points for replaced items which don't have a baseline
          associated with them that you want to be able to align
  SteveZ: You want that for things like initial caps which are
          images such as the kind of things that were done in
          medieval texts. You want to spec where the alignment point
  fantasai: It was alignment-baseline?
  SteveZ: Alignment point.

  Florian: You specify that on the replaced element? And that
           matches that point on the dominant-baseline?
  SteveZ: If you specify alignment-baseline, it aligns to that.
  SteveZ: You align to whichever baseline it is aligned to.
  fantasai: I don't see this in the XSL spec.
  jdaggett: Florian's point gets to the point I'm not clear on. The
            placement of glyphs on the page gets set to from which
            set of stats.
  fantasai: The model is roughly, I don't know the steps, but the
            results should be I go ask the font, give me the glyph,
            where is the alignment point, where is my dominant-
            baseline, let's put the point there. I go get another
            glyph and I match up the points. If I have a vertical
            align shift I layout the points and I shift the box.
  <jdaggett> um, implementations need precise details in this case
  <jdaggett> "roughly" is a word I don't like...

  Florian: I think we need to talk this offline.
  plinss: We have 3 more topics for today.
  SteveZ: Did that work for you jdaggett?
  SteveZ: fantasai I'm willing to work with you.

  fantasai: The way we handle inline images is that we synthesize a
            baseline for the boxes. The text-bottom and alphabetic
            are assumed the bottom text top is the top. If you need
            to adjust that you can do it with margins. It didn't
            seem urgent to spec another property. If we did I would
            like to tie it to a specific baseline.
  fantasai: To get it to work correctly I think you need to specify
            a lot of the information, but most of the time you can
            synthesize from just a few rules.
  SteveZ: That's not my memory. Replaced elements are aligned to
          their bottom edge and that's it.
  fantasai: We added the synth rules in writing modes because that
            gets you the correct by default.
  SteveZ: That's not necessary correct.
  fantasai: It's better for alphabetic in general.
  SteveZ: We should record an issue for the handling of replaced
          elements because I think different place elements don't
          include the margin.
  fantasai: I think the ones that don't contain text use the
  SteveZ: I just remember it's different for different categories.
  fantasai: If you think you need this thing, show me the use cases,
            but I think we can do this without another property.
  dauwhe: We want examples of all this stuff.
  fantasai: That's that section.

CSS Inline: Initial Letters

  <fantasai> https://drafts.csswg.org/css-inline/#initial-letter-wrapping
  fantasai: Do you want to go over initial-letter?
  dauwhe: We went and made the edits based on the Sydney F2F and
          then added a new section on wrapping around initial
  fantasai: We also changed the initial-letter-align property.
  dauwhe: There has been some discussion about wrapping being at

initial-letter-wrap at risk

  TabAtkins: Talking to our inline person, figuring out glyph
             boundaries we think will be fairly expensive and
             complicated for something that's a relatively minor
  fantasai: We're fine with that. The WG asked us to spec how it
            would work so we know where we're headed.
  tantek: We were doing glyph rending in 2000 so I don't go by the
          performance argument.
  TabAtkins: We can do it. It's code we'd have to write fresh and
             it's complex for a small improvement.
  jdaggett: I'm not sure that's true.
  TabAtkins: The person who writes our font stuff says it's hard so
             I believe him.
  jdaggett: There's code for canvas to do outline.
  TabAtkins: We don't want to paint a glyph onto a temporary canvas
             and do pixel counting.
  <jdaggett> this feature requires extracting an outline
  <jdaggett> glyph ==> path, no painting involved

  shane: Without technical details, we don't think it's a priority
         so we want to mark it as at-risk. Is that okay?
  Florian: They're not saying the code wouldn't perform well,
           they're saying the don't want to write it.
  tantek: How is this harder than exclusions?
  Florian: They're saying they don't want to.
  SteveZ: If you're doing shaping you can break it into the piece
          that you need to shape.
  TabAtkins: The shaping engine is a different part of the engine.
  jdaggett: That's wrong. You do and you get the outline data from
            the glyphs.
  TabAtkins: With apologies that Emil didn't come to Paris, but
             until you can convince us with Emil here, that will be
             our official opinion. I cannot argue the point beyond
             giving you the explanation that I have given for you.
  <jdaggett> tabatkins: please ask behdad, he'll give you a better
             answer I think.

  liam: Clarification question. I think you're saying that you're
        not wanting to implement at least part of the initial letter.
  TabAtkins: Initial-letter-wrap.
  liam: There's two aspects of that. One was wrapping exactly around
        the glyph around the character and the other is just
        adjusting the first line.
  TabAtkins: They're equivalent in difficulty.
  liam: Is there a possible compromise for the first line? You would
        have user supplied move closer value. You could achieve the
        same effect for the first line only.
  <jdaggett> liam's effect -100000000000000000
  <liam> jdaggett, well, I prefer it as spec'd too
  TabAtkins: I see nothing wrong with that if the editors are there.
             It's text-indent.
  fantasai: text-indent indents the initial letter itself
  liam: Text-indent doesn't work in the polyfill.

Initial Letter Alignment

  Florian: You say the previous feedback was integrated. On the
           initial-letter-align prop, maybe I'm missing something
           but I don't see where it says how to align when the
           initial letter and the text aren't in the same script.
  fantasai: I think you need to keep reading.
  Florian: Is it border-box I should be reading?
  Florian: If I want to align the ideographic and the text around
           it, how do you do that?
  fantasai: Read the note at the bottom. You have two values, we
            just dropped a bunch and leaving it as auto made more
  <fantasai> https://drafts.csswg.org/css-inline/#aligning-initial-letter
  dauwhe: You just use the appropriate values on each half.

  <tantek> As someone who has spent a lot of time both
           implementing/shipping fancy first-letter effects 15 years
           ago, and continues to publish content with CSS that uses
           them (e.g. http://tantek.com/2015/224/b1/alphabet-indieweb )
           I'm very happy with the improvements in this working
           draft since the previous version and would like to see it
           published as an updated public working draft.
  <ChrisL> +1 to publishing
  <astearns> +1 to publishing

  fantasai: The initial things we were told to solve was deal with
            the alignment of different scripts. We can deal with two
            values, alignment point of letter and of line of text.
            The values are 'auto' for choosing the alignment point
            of the initial letter; and alphabetic, ideographic, and
            hebrew for choosing the alignment points of the
            surrounding text. (Hebrew needs metrics that don't
            exist, but we think need to exist.)
  fantasai: You need to pick from the letter and the line of text
            lists. The initial value of letter is auto.
  fantasai: We think the auto value doesn't need to be set
            explicitly. It's just the first-letter if you can't tell
            what script that is you have a problem.
  Florian: That's not true.
  SteveZ: Punctuation
  fantasai: That's not a first letter. First letters have to be
  fantasai: We can go and do all the values if you want, but we
            thought we had all these things and we don't need an
            auto. We can just have border-box? And you can decide on
            that and then you pick which part of the text you're
            aligning to.

  SteveZ: Hanging?
  fantasai: It uses the cap height.
  fantasai: The cap height corresponds to the hanging baseline point
            in most of the fonts we checked so that seemed
  SteveZ: The problem with the Indic is the top aligns.
  fantasai: You use alphabetic as the default.
  SteveZ: I have examples where that doesn't work.
  fantasai: Alphabetic baseline worked in most cases.
  SteveZ: I have an example on my screen where it doesn't.
  dauwhe: Do you have the fonts?
  SteveZ: No.

  <tantek> content request for CSS Inline Layout: I think it should
           specify which properties apply to ::first-letter, that
           is, incorporate these properties:
  <tantek> or rather that list of properties
  <tantek> and I propose adding width and height to that list
  <tantek> use-case: styling a bunch of different first-letters all
           the same width and height
  <tantek> like that post I linked to above

  dauwhe: I love the initial idea for this to do something simple
          that covers everything.
  SteveZ: I'm hearing you people say that the Indic fonts don't
  dauwhe: I think that's not true. I've spent 50 hours looking at
          these fonts. Everywhere I can look at the font and look at
          the font metrics and where I see being a good alignment
          can work off of these metrics.

Alignment Autodetection

  Florian: I see aligning glyph to glyph is different than
           border-box. As to glyph to glyph I wonder if we can do
           auto and that does the right thing. Specifying auto might
           not be easy but given the text in the lines it's not
           necessarily the case. I don't think expanding the number
           of controls to say I have multiple letters and I have
           multiple scripts, that's too many switches. Can we do
           auto or border-box and that covers a lot of cases?
  fantasai: The first letter it's easy to auto detect, but when you
            have a lot of letters it becomes a lot less reliable.
            You'll have a sentence that begins with IBM and the rest
            is Japanese.
  Florian: But you can detect that the M is English and the random
           word in the middle is English.
  fantasai: We don't care about that random word. Maybe if we have
            text that's alternating language per paragraph and you
            have two short paragraphs affected by a single initial
            letter, *then* you might want to have a switch, but
            that's a weird case so I don't think
            we should care.
  Florian: It's sure a weird case we shouldn't have a switch, but we
           need to say what happens.
  fantasai: We can give the user control over border-box or not and
            alphabetic vs ideographic because we can't infer that
            ourselves. Except for the first-letter we don't do
            script-detection in CSS, because heuristics are often
            wrong. The reason I'm comfortable making an exception
            for first-letter there's really only one grapheme cluster.

  Florian: There's a company that's mixed script what do you do?
  fantasai: It picks the first letter.
  Florian: The first draft didn't say what happens now we have
           controls over what happens.
  [initial-letter can be set on other elements than :first-letter]
  fantasai: We bias against Latin is the set of rules we're using.
           [reads the spec]
  Florian: Generally speaking on the initial letter you were doing
           auto and that's right, but on the text around I was
           wondering if you could do auto.
  fantasai: You can do auto with reliability on initial-letter
            because it's short, but we don't get good results from
            heuristics on longer pieces of text. We're making an
            exception for initial-letter.
  Florian: Okay.

  liam: In the case where your random word in another script happens
        to be on the third line--you could have several places where
        you have initial letters and you want them all appear the
        same, so it would be a mistake to make it special in any case.
  SteveZ: So create a line grid with the dominant-baseline property
          and align to the lines of that line grid irrespective of
          where the lines come out.
  fantasai: We agreed to that in the last meeting.
  SteveZ: That's the only way you get consistent size.
  liam: In the majority case where everything is the same language
        it works out. If you have something with an accent on the
        first line it works out. It's much simpler to implement.
  liam: You can end up in a loop if you don't specify it this way.

Issue Summary

  fantasai: Anything else you want to go over?
  tantek: About initial-letters?
  tantek: Yes. First, I read the draft and this is a huge
          improvement. I'd like to see an updated public draft based
          on this even if you don't make and changes.
  tantek: My one request is I would like the list of what properties
          apply to first-letter, I think that's appropriate for this
  <tantek> https://drafts.csswg.org/css-pseudo-4/#first-letter-styling
  tantek: I think there's so many effects in this draft that I think
          it belongs here more than CSS pseudo. I'd like the list
          copied or moved.
  tantek: I'd like to propose adding to the list width and height to
          the first-letter. I have a use case. When you want to
          style multiple paragraphs with the same first letter all
          with the same width and height. I tried to do it in a blog
          post and I couldn't. I can put the blog post where I tried
          in the notes.
  <tantek> http://tantek.com/2015/224/b1/alphabet-indieweb
  tantek: Those blocks where you can scroll down and see what I
  tantek: I wanted them aligned as blocks.
  tantek: That was my only request. Nice work, I'd like to see an
          updated draft published.

  fantasai: I'd like people to summarize what issues they want in
            the draft.
  Florian: I'm happy to publish with or without issues.
  fantasai: Anybody else have opinion on what needs to be in the
            draft before we publish.
  tantek: Mine are all would like to not need to.
  SteveZ: Let me review the note I sent to the list.
  fantasai: jdaggett?
  <jdaggett> publishing fine
  <jdaggett> i'll post issues at some point

  plinss: Do we want to resolve on publishing?
  fantasai: SteveZ needs more time.

  fantasai: Issues so far are what happens when baseline not in
            font, add width and height to prop for initial letter.
            Add a complete list of things that can be applied to
            initial letter. And the question of which baseline
            keywords do we need to keep.
  fantasai: Anything else I forgot?
  liam: You got TabAtkins' feature as at risk?
  fantasai: Mark initial-letter-wrap as at risk.

Fallback for When Wrapping Not Implemented

  TabAtkins: I talked about text indent...Is that sufficient to do
  fantasai: I applies to the first letter.
  TabAtkins: Unless we define it to not.
  fantasai: I think we want it to.
  dbaron: I feel like the initial-letter being indented is the more
  fantasai: You can do it with the margin property in theory so we
            don't have to use text indent, but what do you want to
            be the fallback if you don't get the styling.
  liam: If you don't get it, that doesn't work because it's a three
        line cap. You want to push the three lines out and move it
        in. But maybe that's the difference between text-indent on
        the first-letter.
  fantasai: Text-indent is only the paragraph.
  TabAtkins: If we kept it and only had a first length value as
             mandatory and in absence of length it uses glyph bounds.
  liam: Where there was a sub it could be off by a few pixels but it
        would be a heck of a lot better. You could read the text
  TabAtkins: That seems fine.
  liam: If we can do it in such a way that it doesn't get in the way
        of glyph outline would be great.
  fantasai: Having it as a value in initial-letter-wrap would work.
  fantasai: You could then do
              initial-letter-wrap: -0.5em;
              initial-letter-wrap: first;
  fantasai: Is that generally a good idea?
  Bert: Is that a positive or a negative value?
  TabAtkins: I'd match text-indent semantics

  RESOLVED: Add a length value to initial-letter-wrap

  fantasai: The bounding-box of the initial-letter is the side
            bearings so that handles some cases.


  plinss: So resolve to publish?
  plinss: Opposed?
  dbaron: I put one other issue in IRC that I don't know is worth
          discussion. The spec lists 4 compat values for SVG, but I
          think only 2 exist.
  <dbaron> One other issue:
           -- text-before-edge and text-after-edge are in SVG, but
           where do before-edge and after-edge come from?  They
           don't appear needed to me.
  <dbaron> it's not in
           or http://www.w3.org/TR/SVG2/text.html#DominantBaselineProperty

  RESOLVED: Publish an updated WD of CSS-Inline

  plinss: What do we do with css linebox?
  fantasai: We should replace that.
  plinss: We have inline on TR.
  fantasai: They forgot to merge it when we did FPWD.
  tantek: This supersedes?
  fantasai: Yeah. It says it in the header. Well, we need to do that
            when we publish.
  <Florian> http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg
  <Florian> http://florian.rivoal.net/csswg/mixed_script_initial.jpg
  Florian: I pasted into IRC two cases of initials with mix scripts.
  plinss: So on that we're done for the day.

  <liam> [text-before-edge is in XSL-FO, e.g.
http://www.w3.org/TR/xslfo20/#font-model ]
Received on Friday, 11 September 2015 18:41:22 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:53 UTC