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

[CSSWG] San Francisco F2F 2016-05-11 Part I: Step-Sizing, CSSOM View [cssom-view]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 7 Jun 2016 21:25:06 +0300
Message-ID: <CADhPm3spd87WwDXvtv4-bMY++iJPG62=kqnVxA5WCucO6m4vUg@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - The group reviewed Koji's proposed spec for snap-sizing
      (available here: https://drafts.csswg.org/css-step-sizing/)
      and still had a few too many concerns for FPWD. The concerns
      - The potential for fonts rendering differently depending on OS.
      - Interaction with line-grid being confusing for authors.
      - That the proposal breaks the CSS design rule of being robust.
      - The spec didn't have enough use cases for the group to
          determine if this proposal would solve the problem-space.


  - Brief discussion of changes for handling of empty rects in


Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Takao Baba, Beyond Perspective Solutions
  L. David Baron, Mozilla
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Daniel Glazman, Disruptive Innovations (only IRC)
  Daniel Holbert, Mozilla
  Jihye Hong, LG Electronics (only IRC)
  Joone Hur, Intel Corporation
  Koji Ishii, Google
  Brad Kemper, Invited Expert
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, HPI
  Myles Maxfield, Apple
  Edward O'Connor, Apple
  Simon Pieters, Opera
  Florian Rivoal, Vivliostyle Inc.
  Andrey Rybka, Bloomberg
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Simon Sapin, Mozilla (only phone)
  Jen Simmons, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Shane Stephens, Google
  Lea Verou, Invited Expert
  Greg Whitworth, Microsoft

  Dael Jackson, Invited Expert
  Hyojin Song, LG Electronics

Scribe: iank


  koji: I'm going to demo some experimental builds.
  koji: This is a normal multicol with headings and images inline.
  koji: Lines don't line up.
  koji: When you turn on snap-height, images and headings snap to
        the body text height, all lines line up.
  koji: Latin text wants to align baseline to the text of the heading.
  koji: Not sure what people want for images.
  koji: inline-block baseline is the last line.
  astearns: For a multiline heading you'll only have last line snap
            to the baselines.
  koji: For images bottom of the image is the baseline.

  <jensimmons> link to this demo? link to a draft spec?
  <dauwhe> https://drafts.csswg.org/css-step-sizing/

  astearns: Can you remind me of the baseline syntax?
  koji: line-height-step has two values, 20pt is size of step, 70 is
        within the step where you want to set the baseline to.
  koji: The browser will move the baseline around so it is 70 of the
  fantasai: Would be nice if that could be derived from the font.
  astearns: You are just setting a number.
  fantasai: It looks better if you pick a baseline from the font.
  astearns: It is responsive to the fonts, instead of the browser
            picking the baseline from the font, you are setting the
  koji: The problem with picking from fonts is need to pick from
        primary font. When fallback occurs, fallback may have a tall
        ascent, and will jump to next line.

  astearns: This gives you first baseline offset, for your block you
            can say where the baseline is starting.
  <tantek> +1 astearns

  Florian: This requires numbers to be set very precisely to avoid
           accidentally ending up with lines skipping. Or you have
           to set the line-height to be substantially smaller than
           the actual line rhythm to avoid that problem.
  fantasai: That seems counter-intuitive, you would expect the
            line-height and step-sizing to be the same.
  koji: Setting the line-height and step-sizing to be the same size
        is fragile. CJK fonts this would make every line double.
  Florian: Because of the baseline, there are a whole bunch of
           reasons for this to be different as things will go wrong.

  <liam> [ does this override entirely any line spacing coming from
         the font metrics? ]
  <astearns> liam - it responds to line spacing, but quantizes the
             spacing to a multiple of the step
  <liam> thanks. (sorry, should have done q+ but am not on the 'phone)
  <liam> [ sounds like what is used is max(step size, font height)
         and you can't set text solid; maybe when combined with the
         separate line-height property fantasai and dauwhe proposed
         in email it would work ]

  dbaron: During transitional phase, people will have to use a hack
          (setting line-height smaller than what they want) bad for
          UAs not supporting feature initially.
  dbaron: Concerns about rendering on different OSes, for example
          New Yorker currently relying on font-metrics assumption.
  astearns: There is not a huge difference between line-height and
            snap-sizing, just enough to get enough effect you want.
  dbaron: You have to guess right, that might have bad results in
          either direction if you guess wrong.
  <dbaron> (and you might even get bad results in both ways with the
           same number)

  <fantasai> http://fantasai.inkedblade.net/weblog/2012/css-layout-evolution/#principles
  <fantasai> I think we're violating Robust and Understandable, here

  ChrisL: Had to reread the text, 70 is actually a percentage, why
          is it not a <percentage>?
  koji: Same feedback from Tokyo, I'm open to this.

  ChrisL: "by adding the space over" - what is a space over?
  koji: Ascent side.
  fantasai: "over" means ascent side of the line.

  koji: Talking to devs about this feature, they don't want to think
        about fallback. Very expensive for web-devs to develop
        without this feature.
  koji: As long as it requires fallback, cost won't go down.
  fantasai: We're not suggesting that the fallback should be
            baseline-aligned nicely.
  fantasai: Only that it shouldn't be worse than what you would
            naively do today.
  fantasai: E.g. if I had a double-spaced essay, I would use
            line-height: 2.
  fantasai: With the new feature, I should be able to add some code
            and make it baseline-aligned.
  fantasai: But here I have to also set line-height to something
  fantasai: So that my intention in the old browser is not
            preserved: the line-spacing is less than double-spaced.

  koji: The catch is that neither line-grid or step-sizing doesn't
        work, by just turning on, get bad results, creates lots of
        undesired spaces.
  koji: When you are talking about fallback, if you want everything
        to look good, need to switch everything (margins etc) with

  astearns: I agree if you want to do the best you possible you can,
            with all UAs, it is more costly.
  astearns: I think that there are acceptable fallback strategies,
            which will look ok.
  astearns: Looking okay in older browsers, and looking
            exactly how you want in new browsers, is acceptable.

  Florian: It's not just a fallback between supports / not, but also
           browsers with different font-metrics.
  koji: I can't think of a real scenario where a font will exceed
        the step.
  koji: They don't use step as 1.1 (small value), people will do
        1.5,1.8 (large value).

  tantek: From a design perspective, how much extra space
          above/below a font, is enough to make any finely tuned
          design to look good/bad on different OSes. I can't think
          of any way to make this look good, unless by undoing what
          the OS does.
  tantek: Should ask designers how they are dealing with this cross
          OSes, serving different stylesheets?
  koji: You usually don't that that small line-size.
  dbaron: If you have script off for New Yorker, underline is above
          the baseline.
  <tantek> New Yorker-- for depending on script to have decent

  myles: I don't want to have two properties that fight to get the
         correct result.
  myles: How would this interact with line-grid?
  koji: line-grid and step-sizing handle two slightly different
  koji: line-grid can snap to absolute positions.
  astearns: They solve a similar set of problems about lining things
            up, with step-sizing you need to control everything
            about the layout to get two different elements to line
            up, for line-grid everything just aligns.
  astearns: line-grid for global, step-sizing for within a
            particular element.
  myles: I'm worried about properties jumping down by a different
  astearns: I see it as a tool for getting lines to fit will within
            a line-grid.

  TabAtkins: I thought this was a simple version of line-grid that
             we could go with.
  myles: Need clarification of if this is in addition to line-grid
         or replace.
  astearns: Any out of flow thing, like floats is a problem for
  koji: When you are in normal flow step-sizing works better.
  myles: I'm interested when both are being used on the same element.
  koji: step-sizing rounds up line height, it just grows, line-grid
        moves line box down.
  myles: If we specify both numbers, the spec appeared to be moving
         line boxes also.
  astearns: The baseline moves within the linebox but doesn't move
            the linebox itself.
  astearns: line-grid does move the linebox.
  astearns: If you have both step-sizing and line-grid, with a
            baseline you get double spacing.
  <Florian> if line grid creation takes its lines from the result of
            applying step-sizing, it seems it would work out ok.
  * liam wondering if this spec's functionality could be better done
         with a function notation for line height
  <Florian> Koji: If line grid works from used value of the line
            height, then it works since step sizing affects that.

  fantasai: I think that at a high level we have a number of design
            principles for CSS.
  fantasai: One of them is that features should be robust, shouldn't
            break down in unexpected conditions.
  fantasai: Another is that it should be understandable to the
  fantasai: The tools and syntax that we use to express, they should
            be understandable.
  fantasai: The way this proposal works breaks both these principles.
  koji: Can you specific?
  fantasai: The double spacing issue, I need to make the line-height
            smaller than I intend to get the result of double spacing.
  fantasai: That's confusing for authors.
  astearns: For grids there are a particular way to work with grids,
            you set up the grid, then get the line-heights to work
            with the grid.
  fantasai: Why aren't you always setting them to one?
  astearns: People set up line-heights to 0 in InDesign for things
            to fall on the grid.
  fantasai: This seems like a design flaw.

  fantasai: I want to solve the problem, but this feels a little bit
            like the variables situation.
  fantasai: We had many proposals to solve variables, but each time
            it felt not quite right, and we didn't adopt it.
  fantasai: Then we ended up current variables proposal which works
            really well with the way CSS works.
  fantasai: I don't think we're there yet

  ekimber: It feels to me like this would be one feature.
  ekimber: I'm curious where is the origin of the top line defined.
  koji: It is always at the top.
  koji: Its rounding up heights.
  ekimber: What other properties of text depend on the line-height,
           what things would be mis-positioned?
  ekimber: For example if I'm specifying super/sub-script would be
           affected the way I want?
  koji: Since this is just rounding up line-heights, if the
        super/sub-script it will work, if they don't you'll get
  Florian: If you set line-height to 0?
  astearns: Nothing happens.
  koji: If you set line-height to 1.2, you get minimum padding
        between lines.

  TabAtkins: Earlier what are the difference between line-grid. What
             cases do we want to use step-sizing instead of line-
             grid? (where line-grid would be bad).
  koji: You always need to worry about characters aligning to
        different elements.
  koji: If you offset an element by 2px, then you get next grid.
  TabAtkins: Unless you get that element to create a new line gird.
  astearns: I think that step-sizing is simpler for the simple case.
  TabAtkins: It's simpler because its ignorable. In koji's example,
             if you weren't careful, then everything would get
             messed up, its very simple, but requires the author to
             stay very simple, or carefully manage things.
  <tantek> +1 TabAtkins, I'm also confused about line-grid vs.
           step-size approach.
  Rossen: If you have blocks which can't be step-sized then things
          appear wrong.

  fantasai: Most of the time people don't mix font sizes in a line.
  fantasai: The font size within a particular block element doesn't
  fantasai: It would be nice if you created a basic paragraph it
            should just work.
  * bradk wishes that we had regular leading, even if it made
          superiors overlap the previous line.
  <liam> bradk, yes
  dauwhe: Within blocks I want to say the spacing between line is X,
          I'm used to using line-height prop for that, it works some
          of the time.
  dauwhe: Baseline to baseline distance is X, do that, this is what
          I want.

  fantasai: In a basic document, the kind we're discussing a lot
            here as examples, are two major problems for baseline
  fantasai: First one is, if I'm using the same size font throughout
            a block (which is by far the common case), want baseline-
            to-baseline spacing to be the same throughout.
  fantasai: Let's solve that directly, either tweak rules for inline
            layout or add a switch if we have to
  fantasai: Then the other one is, I have something different: a
            heading, a blockquote, an image, whatever; that is
            interrupting the flow here
  fantasai: And in order to maintain the rhythm, need it to take up
            a step-size of the line-box-height.
  fantasai: This proposal doesn't solve that. You have to make
            things inline-blocks, which is weird, has many other
            layout effects.
  dauwhe: I can't believe I'm saying this, I would like to see a
          wide-variety of layouts, and how we would do them in the
          various proposals, and do they meet these usecases,
          understandable etc.
  fantasai: Headings and block images should just be blocks.
  fantasai: Let's solve this directly with step sizing on the margin
            box of such blocks.
  dauwhe: Would like to see examples in the spec, more multi-line
          blocks and how they handle this.

  * skk thinks that I agree to TabAtkins opinion. In case I want to
        use this feature, the existence of line-grid and step-sizing
        is confusing. Is it impossible to make line-grid as step-
        sizing's level2?
  <myles> skk that is the question i asked earlier - how to upgrade
          from one to the other w/o deprecating the old one
  <skk> myles, sorry I missed your question. I think one of a
        problem is line-grid specification is complicated and
        difficult to implement in browser. If such a big
        specification can be divided into a few part according to
        implementation perspective, that might be helpful for
        gradual implementation. It's just a design idea.

  dbaron: 1) We did have old proposal, in line-box draft,
          line-box-contain, gave you some control over what affects
          the line-height.
  dbaron: There are some tradeoffs, some of the things that CSS
          wants to include in the line box height, as they will vary
          between machines, even if line spacing looks fine on your
          machine, may differ.
  dbaron: 2) It sort of seems fragile.
  dbaron: If goal (of authors) is to maintain a consistent grid
          between columns, and trying to accomplish that with
          heights, everything that is not a height, (margins etc)
          need to be consistent with that grid.
  dbaron: Makes me feel that this proposal is very fragile.
  koji: If the dev doesn't pay enough attention to spaces, it is
        true that this proposal will break, for line-grid it will
        jump to the next grid.
  <dbaron> While line-grid is harder to implement, I don't think
           it's all that hard.

  Florian: I think that what Tab is saying, in both systems if you
           aren't sufficiently careful you have problems.
  Florian: When this kind of stuff happens, with line-grid you can
           fix it locally.
  Florian: With step-sizing you have a local problem, which causes a
           global problem.

  astearns: Lets wrap up this topic.
  <debate about complexity of problems>
  astearns: Let's talk about color first, then if we have time lets
            come back to it.
  koji: Are people fine with FPWD?
  astearns: Doesn't sound like we are ready.


  astearns: So, we had a schedule plan where we expected color to be
            in the afternoon, for dino calling in.
  astearns: Could split out color now. And then everybody comes back
            for step-sizing part 2.
  astearns: scroll-snap has to happen in the afternoon.


  Topic: getBoundingClientRects()
  astearns: So CSSOMView has been handled?
  zcorpan: Yes.
  zcorpan: A few years ago we got feedback from roc about gBCR when
           there is a collapsed range. The spec would not return
           anything useful.
  zcorpan: Anne fixed it
  zcorpan: Blink fixed it, and got feedback from authors when the
           range starts with an empty rect and later has a non-empty
  zcorpan: We basically changed the spec to what gecko did.
  zcorpan: New behavior is ignore the empty ones, and use the ones
           that are not empty.
  zcorpan: Previously the first rect was always included.
  smfr: Does the first one have a zero size?
  TabAtkins: It has a position.
  zcorpan: If you have an empty range...
  smfr: I just the spec to be clear about zero size vs. zero origin.
  <smfr> url pls?
  <zcorpan> https://github.com/w3c/csswg-drafts/commit/0e7a5cbdea19397086e9423b508fe6f41decdcec
            is the spec change
Received on Tuesday, 7 June 2016 18:26:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 June 2016 18:26:04 UTC