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

[CSSWG] Minutes Sydney F2F 2016-02-01 Part III: Writing Modes, Line Grid [css-writing-modes] [css-line-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 13 Mar 2016 08:38:01 -0400
Message-ID: <CADhPm3vAjZsikJr9xxFcBVJCiQmBduECfYkut1zpOfAS3qjY+g@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.
=========================================


Writing Modes
-------------

  - Koji shared that there are now over 900 test cases for Writing
      Modes, allowing a good sense of what properties don't have two
      interoperable implementations.
      - A document listing the properties where yellow items don't
          have enough implementations is available here:
          http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-01.html
      - Everyone praised the document and the work done in creating
          the test cases.
      - With this feedback, Koji would like to target PR at TPAC.
  - sideways-* had a lot of failures, but still a lot of support for
      its need, so it will stay in the spec for now and drop to
      level 4 if it becomes the last blocker for REC.
  - Some of the failures for unicode-bidi are in the details of the
      embed behavior, which Unicode and the Web Platform are moving
      away from anyway.  Those failures will be identified as
      failures in UAX9 implementation, not Writing Modes failures.
  - Several people received actions in order to continue progress on
      understanding these test results and getting more
      interoperable implementations.
  - RESOLVED: Make TCY fullwidth->proportional transform optional
              (text-combine-upright)

Line Grid
---------

  - koji presented this proposal for a new line grid spec that is
      simplified in order to get more implementor interest.
      - The proposal changes the snapping to grid behavior to an
          attempt to control heights.
      - It also replaces line-grid with snap-height relying on css
          custom-properties to add more versatility.
  - Though everyone understood the goal of getting something
      implemented, there was a lot of concern that the proposal is
      too fragile to be useful, especially for vertical-rhythm.
  - RESOLVED: Make an ED for snap-sizing to work out details of
              proposal
  - RESOLVED: Editors koji and fantasai
  - RESOLVED: Add ideographic advance unit to Values and units 4,
              come back to WG for approval after details worked out.

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

Agenda: https://wiki.csswg.org/planning/sydney-2016

Scribe: fantasai (with zcorpan scribing when fantasai spoke)

Writing Modes
-------------

  koji: Some Japanese companies have been funding gtalbot and some
        test engineers for a bit more than a year,
  koji: Have 900 testcases for Writing Modes.
  koji: The team also ran the tests for most browsers, not every,
        but all the tests were mostly were run by test team.
  koji: We now know which tests don't have two or more interoperable
        implementations.
  koji: I want to share the status of that,
  koji: and figure out plans for moving Writing Modes to PR/REC.
  koji: One reason I'd like this spec to move to REC
  koji: is that other organizations, e.g. IDPF EPUB are relying on
        this spec
  koji: but is not REC in CSSWG.
  koji: So if it's possible to move major part of the feature to
        REC, that's helpful
  koji: for those other organizations.
  Florian: Different people in different organizations are
           differently sensitive to status of the spec.
  Florian: People who care about Writing Modes care about the status
           and stability of the spec.

  koji: Wiki page there's a link to the status document I wrote up
  http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-01.html
  koji: Yellow row means that test doesn't have 2+ implementations.
  koji: Going to go over the yellow rows:
  koji: For section 1, all failures are for sideways-lr or
        sideways-rl
  koji: These two values are added at TPAC, are at-risk,
  koji: These values are not interoperable.

  koji: Next section is 2: Inline Direction and Bi-directionality.
  koji: Almost 10 tests, all for new values for unicode-bidi
        property,
  koji: These do not have 2 implementations today.
  koji: Most of the layout tests are done by adding prefixes, btw.
  koji: We run parsing tests without prefixes, but most layout
  koji: unicode-bidi values currently only Blink is unprefixed.
  koji: So these values don't have 2 implementations as of today.

  koji: Next one is 2.1: Specifying Directionality: the direction
        property
  koji: As you can see from filenames
  koji: failures are for sideways-*
  koji: Then there is some failures for rtl+upright.
  koji: More unicode-bidi ... only blink unprefixed these values.
  koji: This test is controversial, tests bidi reordering algorithm.
  koji: CSS spec defines how to map CSS properties to bidi control
        characters. And unicode spec defines how to reorder
        characters based on bidi controls.
  koji: These tests are testing rendering results.
  koji: So it's not really testable for CSS only, can only test
        combination of CSS and Unicode.
  koji: For blink, these tests are Unicode failures.
  Florian: So you want the spec to progress, not block, on unicode
           failures?

  koji: We have a failure for row-reverse (flexbox)
  koji: Don't know CSSWG strategy for combination of two specs.
  fantasai: We don't have a policy, but maybe we could have a policy
            if you have a test that tests the interaction of 3
            specs, should we be able to move all of the specs but
            the last one to rec?
  astearns: If there are interactions where some specs are already
            in REC, that could hold a spec back.
  Florian: Makes sense in general, but it's tricky if some browsers
           implement one spec and some implement the other
  Florian: If different browsers are working on different specs,
           unclear which specs are held up.
  Florian: But in this case, see no problem.

  koji: Next is table progression.
  koji: We have a bunch of failures for atomic inline baselines for
        vertical-lr and multiple lines in inline-block/table;
  koji: Complex case, only in Mongolian.
  koji: vertical-rl passes.
  koji: So vertical-lr is less interoperable today.
  koji: There are a bunch of tests for text-orientation that fail.
  koji: Orientation of unicode codepoints-
  koji: Uses JavaScript to render all codepoints.
  koji: Unfortunately that JS doesn't work for vertical flow,
  koji: in Gecko, it's failing,
  koji: But the reftests, Gecko passes.
  koji: So although these tests don't pass, I consider the property
        itself passes,
  koji: The failure is in CSSOM View.
  fantasai: Given Gecko would pass an equivalent reftest. I agree
            with that.

  koji: Next section we have some abspos failures
  koji: No excuses, they are failures.
  koji: I want to note that abspos has lots of combinations. Have
        250 tests.
  koji: About 25% of test suite is about abspos.
  koji: Those 270 are combination of [lots of things];
  koji: All the failure are about orthogonal flows.
  koji: When author sets abspos, that abspos box has different
        writing mode from its parent.
  koji: My take is that the basic cases of abspos are interoperable,
        but orthogonal cases are not really handled.

  koji: 9.1 text-combine-upright
  koji: Most failures in parsing.
  koji: Quite well implemented in Edge/Trident/Blink/Webkit,
  koji: But only Blink has unprefixed support.
  koji: For other layout tests, these implementations pass.

  koji: Last section is 9.1.3.1: Full-width Characters
  koji: Says that for text-combine, when author puts full width
        characters, should convert it to ascii characters.
  koji: Nobody implements that.
  koji: Need to either make it... or remove it
  fantasai: I think we can put it as a MAY, so won't block moving
            forward.
  Florian: Is this something to address with text-transform?
  fantasai: No.

  koji: After list of test failures, have list of non-interoperable
        items.
  koji: Questions?
  Florian: Other than thing we just talked about, have you found
           through these tests areas where the browsers disagree
           with the spec but agree with each other in a way that
           suggests changing the spec?
  koji: Abspos is a little...
  koji: It's likely unintentional, but as a result this browser test
        fails this combination, that one fails that combination.
  koji: That's what you call disagree?
  Florian: These are clearly bug.
  Florian: If we're trying to rush to REC, might be tempted to
           change spec, so not something to do here.
  Florian: Is there a case where browsers agree with each other,
           spec disagrees, and spec makes less sense and should be
           changed?
  koji: Full-width is the only one.

  fantasai: Thank you Koji for this report, it's really excellent.
  fantasai: I think from what we have here, we should encourage
            browsers to unprefix their implementations.
  fantasai: That's a relatively simple fix to move a lot forward.

  fantasai: Should also fix the full-width issue by changing to MAY
            in the spec.
  fantasai: Other than that, looks like some bugs we just have to
            wait to fix.

  heycam: Looks like a lot of failures for sideways-*, maybe should
          drop.
  Florian: I don't think it's a big issue.
  Florian: This syntax was introduced very recently, so not
           surprising people haven't caught up yet.
  Florian: If everything else was green, would consider what to do
           with that.
  Florian: When you support the rest, supporting this is actually
           easy.
  Florian: Nothing fundamentally new for these two values.
  Florian: By the time we have the rest, I expect these can be fixed
           as well.
  Florian: If not, then can drop.
  Florian: But relatively easy compared to the rest of things.

  koji: Depends who you ask,
  koji: But from viewpoint of relationship with EPUB.
  koji: text-combine is the only thing they refer to.
  koji: There is a possibility that if we can get text-combine, then
        we can move the all the rest to Level 4 and move all the
        rest to REC.
  koji: That make EPUB people very happy.
  Florian: We still have to fix the other bugs.
  koji: Make undefined in L3, move to L4.

  fantasai: I think we can probably make the EPUB happy by moving
            to snapshot stability.
  fantasai: With regard to sideways stuff, I think Mozilla
            implements that correctly.
  fantasai: The question is if other browsers will implement that.
  fantasai: If it's just abspos issues that shouldn't be too hard to
            fix.
  fantasai: If nobody is going to update to do sideways that that
            can be a problem.
  fantasai: This report does a good job on what we should focus on.
  fantasai: I'd prefer to not drop sideways because it's important
            for non-CJK use cases.
  fantasai: This is new syntax from 3 months ago so we should give
            more time before we move to PR.
  fantasai: There's a minimum time before we can move forward anyway.

  koji: REC doesn't indicate importance, but whether W3C saying
        these are interoperably implemented.
  koji: From that POV, if sideways are not implemented at some point
        moving to level 4 is natural to me.
  Florian: I agree, just don't think we're at that point.
  Florian: I think if we revisit at next TPAC, likely there's a lot
           more green.
  Florian: If by then sideways are the only thing holding us from
           PR, dropping makes reasonable sense.
  Florian: I'm optimistic that sideways values can be implemented as
           these other bugs are fixed

  astearns: Amazing job at getting so many tests together.
  astearns: Is work still ongoing?
  fantasai: Have funding for another 5 months at least.
  Florian: Do the people who have worked on this test suite consider
           the test suite complete, or should there be more tests
           written?
  koji: Hard question.
  koji: Test suite is never really complete...
  koji: I think it's a good level to move on, imho
  koji: For me, if generally it's reasonable to say we could target
        PR for next TPAC.

  koji: One really blocking factor from my perspective is
        text-combine and upright.
  koji: It would be really great if Edge can unprefix, or Gecko can
        implement.
  Rossen: If it's only about unprefixing, should be possible.
  koji: Blink has unprefixed, WebKit is prefixed but good, Edge
        needs to unprefix.
  koji: If we count webkit separately from blink, we have two.
  Rossen: Let's not have that discussion now.

  heycam: I think xidorn was going to ask about all vs 2-3.
  xidorn: Is it just the value 'all' or also the digits values?
  koji: Edge/Trident are the only implementations of 'digits'.
  koji: Digits are at-risk.
  koji: And EPUB doesn't use digits today.
  Rossen: And yet they were the ones that were asking for it the
          most,
  Rossen: Because they didn't want to pre-process their content.
  Rossen: Representatives from Japanese publishing companies were
          asking the most for 'digits' to be implemented.

  Florian: Wanted to discuss earlier comment about bidi support
           comments.
  Florian: How do others feel about those bugs?
  koji: There is actually a Unicode test suite for UAX9.
  koji: Since the test is not really unicode testable, Blink has a
        separate test harness to run it.
  koji: We have about 20-25,000 failures there,
  koji: Over 1 million testcases.
  koji: So its 2-2.5%.
  koji: I also converted that testcase to HTML and ran across
        browsers.
  koji: All browsers fail somewhere between 20-30000 tests.
  koji: So my current view on those failures is not to make those
        failures to zero.
  koji: But if users file bugs, then we try to fix it.
  koji: It's not really hard to make failing testcases.

  Florian: Is it possible to write the testcases to check the
           mapping is correct?
  Florian: Even if underlying unicode is being wrong?
  Florian: Should this hold up spec going to CR or not?
  fantasai: I don't know. I'd have to look at the specific tests

  SteveZ: Are these failures on simple testcases or complex
          combinations?
  SteveZ: How likely will real people come across the kinds of
          things that are failing?
  koji: I don't speak bidi languages.
  koji: Looking at spec logic, so can't tell.
  koji: If bugs are filed in our database, we'll look into it and
        try to fix. Those failures are not filed yet.

  koji: One more thing, not sure familiar with bidi-isolate.
  koji: In Unicode 6.3, 3 years ago, they came up with new kind of
        embedding, affects algorithm itself,
  koji: Everyone tells me isolate is the way to go in the long run.
  koji: We're moving towards it.
  koji: Talked about it last TPAC with Apple and ?
  koji: We're working on it.
  koji: Among those failures, many are for old embed style.
  koji: If you limit test to isolate mode, we have less failures.
  koji: Depends on timing, not sure how much want to fix those embed
        failures.
  koji: If everyone has moved to isolate mode, people might not be
        using embed.
  koji: But still testing this, so test might fail.
  fantasai: If embed is what's failing, that's already in CSS 2.1
            REC and we can move on.
  fantasai: We need to make sure the mapping is correct and we're
            trying to do the right thing with regard to nesting etc.
            and then can say edge cases is unicode's problem.
  fantasai: If you load a plain text with all the code points
            instead of CSS and it has the same failures then it's
            not a CSS bug.

  koji: So next step is ask fantasai to look at test failures and
        get some feeling.

  ACTION fantasai: Look over Writing modes test failures
  <trackbot> Created ACTION-748
  ACTION gregwhitworth: Look into unprefixing text-combine-upright
  <trackbot> Created ACTION-749
  ACTION hober: Look into unprefixing writing modes features in
         WebKit
  <trackbot> Created ACTION-750

  fantasai: In the spec we should change full-width transform to may?
  fantasai: Any combination of 1 to 2 digits should be upright,
  fantasai: and you have a sequence of 2 digits, the spec says first
            try to squeeze these ...?

  RESOLVED: Make TCY fullwidth->proportional transform optional
            (text-combine-upright)

  Rossen: Let's focus on L3 first.
  fantasai: I'd encourage blink and MS teams to look into sideways
            values.
  Rossen: We'll "look" into it.
  fantasai: sideways-rl at least should be easy because it's mostly
            the same as text-orientation: sideways + writing-mode:
            vertical-rl.

Line Grid
---------

  koji: The line grid, this is a proposal
  <astearns> https://github.com/kojiishi/snap-height
  koji: The basic idea is that line grid spec has been around for
        3-4 years without enough interest from implementers.
  koji: I just wonder if it can be more interesting if the spec is
        simplified.
  koji: This is a proposal to try to simplify further:
  koji: I want to see if this increases implementer interest, and
        also if it will still be interesting for solving use cases.
  koji: One thing is world is changing in 2-4 years.
  koji: Last time we discussed this, I googled about vertical rhythm
        or line grid,
  koji: All I hit was professional typography papers.
  koji: But this month when I go searching, everyone is talking
        about CSS, how to do it in Web browsers.
  koji: People are doing lots of complex calculations using SASS and
        SASS macros,
  koji: To provide that kind of capabilities.
  koji: I think this demand is coming to browsers, and people are
        hacking around,
  koji: But hacks do not work when page is zoomed,
  koji: Or are not responsive,
  koji: So doesn't work for mobile browsers or desktop browsers.
  koji: People are trying to solve this, but there is no really good
        solution yet.
  koji: So even with minimum level of line grid
  koji: I'm seeing it solves, helps a lot of web developers today.

  koji: Overview section of proposal
  koji: Speaks how I tried to simplify.
  koji: Basically 2 points of simplification.
  koji: One is instead of snapping to grid, this proposal tries to
        control heights
  koji: So that every line and box is multiple of grid.
  koji: As result of stacking, produces a grid effect.
  koji: Send point is instead of defining grid for elements or named
        grids,
  koji: We can now rely on CSS custom properties to define a value
        across documents,
  koji: So no longer need to define grids, just accepts values.
  koji: Assumes that CSS custom properties can fill in the gaps.
  koji: Proposal follows.
  koji: With regard to naming, talking to people, since only
        heights, not really a grid;
  koji: But please disregard naming for now.

  koji: First item is snap-height,
  koji: Very similar to line-grid,
  koji: Takes none or length.
  koji: What it does it just increase the height of line,
  koji: To be multiple of specified line length.
  koji: There is an example below
  koji: With help from css custom-property.
  koji: You can make all line heights as multiple of specified value.
  koji: There was some discussion of margins being multiple of grid
        unit.
  koji: With custom properties, this is easy to achieve.
  koji: Just use calc() and custom properties combination.

  koji: 2nd feature is snapping to Baseline, primarily for Latin.
  koji: This has a little tricky expression.
  koji: The basic idea is that author specifies in the grid, where
        you want to draw a virtual baseline.
  koji: Control spacing is that the baseline matches to the
        specified ratio in the grid.
  koji: Does that make sense?
  astearns: This doesn't work.
  astearns: If you have 2 lines snapping to different multiples.
  astearns: One to one multiple of a length, and one that is 2
            multiple of the length, then ratio is not going to get
            the baselines to align.
  koji: Ratio is for one grid, if your line is higher than one grid,
        you skip one grid, matches to same ratio of next grid
  Florian: ...
  SteveZ: If you've got a big descender, might creep into next box.
  koji: Basically the idea is to round up line-height to multiple of
        grid.
  koji: Then shift so that baseline matches to specified ratio.
  SteveZ: So I've got a "q" that's 3x larger than the other font.
  SteveZ: I move the descender to match the 3rd baseline down, and
          then that descender is going to go well below the line box.
  koji: But baseline matches...

  astearns: I think the idea of snapping heights and widths to
           multiples of values is probably a useful thing.
  astearns: I don't think it does enough to give you a vertical
            rhythm features.
  astearns: I think you should just drop the baseline ratio thing,
            and just get the multiple widths/heights thing you're
            looking for.

  astearns: How this proposal matches up to giving the Web a
            vertical rhythm feature.
  astearns: My main concern with this, like with existing solutions,
            have to control everything on the page in order to get
            it to stack up right.
  astearns: If anything is not participating in this multiple-height
            scheme, it throws off the rhythm.
  astearns: In order to have a vertical-rhythm, really need to have
            a grid that everything is working towards.
  astearns: That means you define a grid that things can participate
            in.
  astearns: You don't try to give every item on the page a
            particular height to make it conform to a grid that
            doesn't exist.
  astearns: There are too many failure modes to constructing a grid
            out of making things conform.
  astearns: You really have to have a grid, and have thing
            participate in the grid or not,
  astearns: to get the vertical rhythm feature.

  koji: I actually understand the concern, but if author wants
        vertical rhythm, he has to pay attention to every space
        anyway.
  koji: How it fails differs by having a grid or controlling heights.
  koji: If you have a grid, fails, need to jump to next grid.
  koji: Author doesn't want that big space, it's a failure anyway.

  Florian: I think my view is similar to astearns's.
  Florian: You are right, this is probably simpler to implement than
           existing proposal for line grid.
  Florian: Increasing chance of happening is useful.
  Florian: In very controlled situation, can get decent results with
           this.
  Florian: But it's quite fragile.
  Florian: So many situations that will break the rhythm.
  Florian: If it only sort of works, instead of really works, then
           we still want the other proposal.

  Florian: If we implement this sort-of-works thing, is that worse
           because we sort-of-solve the problem?
  Florian: And therefore not motivated to fix the good enough thing?
  koji: I actually agree with that.
  koji: I'm not saying grid is bad.
  koji: I'm fine to have 2 specs, Level 1 / 2 or something.

  koji: But for the fragility, it exists even with grid.
  koji: People who care about rhythm also care about unintentional
        large spaces.
  koji: So if fail to set space correctly, not pay enough attention,
        then in this proposal they break rhythm.
  koji: In real grid they get big space, which is also bad.
  koji: That's my view.
  astearns: It's the same problem in both.
  astearns: If you have something that doesn't fit the grid,
  astearns: In your proposal, then get a space.
  astearns: In grid, you get a space, but grid is also resumed.
  astearns: Once you have a stacking failure in this proposal, then
            everything is off.
  koji: That's true, so I'm not ..
  koji: My proposal is only that before we have grid, is this good
        to have or is it useless.

  astearns: Like I said, I think snapping to intervals is a fine
            feature to have.
  astearns: There's other use cases for that also.
  astearns: Probably belongs to sizing module.

  SteveZ: Could you extend line-height using the algorithms that
          you're talking about, so it always came out to an integral
          number of the snap unit?
  astearns: Doesn't give you a different property, just a different
            way to have line-height.
  astearns: Could have something that's a new length type,
  astearns: A function, or length unit.
  astearns: I'm not sure.
  koji: I thought about it, but functions or unit can introduce
        complex cases because can apply anywhere.
  koji: Goes against making things simper to implement.
  koji: The other one, is after this one, I applied it to block
        heights.
  koji: I don't care much about syntax or how many properties to use.
  koji: But not really positive about making too general.

  Florian: You were asking whether useful or useless.
  Florian: I think this is useful,
  Florian: But I'm concerned about being a little useful, but not
           enough, and decrease priority of real solution.
  astearns: I'm not as worried about it, as long as we don't sell
            this as a solution to line grids.

  astearns: Another argument for doing more generally is that line
            box heights, or block heights, maybe they are the only
            thing that stack...
  astearns: But I assume people would want to use multiples of a
            particular length for margins/padding/other things.
  Florian: If the multiple is 1, then we can probably introduce a
           unit that is the line height.
  Florian: And you can use margins and paddings in that.
  Florian: I can easily imagine ...
  fantasai: if all of you margins are a multiple...
  fantasai: I think I see 1.5lh on top and bottom margins being
            useful.
  SteveZ: Also have to worry about margin-collapsing.
  fantasai: No, not really a problem. If all input margins are
            multiples, output margin will be multiple.

  koji: Florian's concern is hard to answer.
  koji: But when I google vertical-rhythm css, 37K hits
  koji: These are asking how to do that.
  Florian: Pain is great, want to solve problem as well.
  koji: I know people hate to hear this, but Word shipped this
        height feature 20 years ago.
  koji: From what I hear from colleagues, not hearing any complaints
        about that. Turned on by default in East Asian versions.

  Bert: If I understand correctly, was looking at Example 1 in
        current line-grid spec.
  Bert: Trying to figure out how to do that in Koji's spec,
  Bert: But can't figure out how to do that.
  astearns: You'd have the headline's block-height snapped to a
            multiple of the line height,
  astearns: And leave the line boxes alone.
  astearns: The line boxes within the headline would stack as you
            see it in the example of the spec.
  astearns: You'd just have more space above and below,
  astearns: In order for the next paragraph to fit on the grid.
  Bert: Wondering if that's possible to specify with snap-height?
  Florian: You would need to use it with custom-properties so you
           have a repeating value.
  astearns: There would have to be a block-height-snap added to
            koji's proposal.
  koji: If the heading wraps to multiple lines, astearns is correct,
  koji: If it's simple line, then it works.
  SteveZ: That's an example of the problem!
  koji: Here the heading is larger than one grid, so automatically
        expands to 2 grids.
  koji: As you see, centered to 2 grids.
  koji: Haven't explained that yet, but see below -- snapping block
        boxes option.

  astearns: So, interest?
  koji: I'm interested in this, any other implementers?
  Florian: Vivliostyle might be interested. We're interested in
           line rhythm, not sure what we will consider first.
  <skk> BPS is also interested slightly. Small contribution might be
        possible.

  fantasai: How feasible is it to have a property that snaps the
            margin-box height of a box to an interval of length X.
  dbaron: what's a margin box?
  <dbaron> (in the presence of margin collapsing)
  fantasai: The margin box is the border box with the margins added
            to it
  ...

  astearns: One failure mode of the SASS approach is solved, if
            everything buys into this model.
  fantasai: Could you do it with the border box? (dbaron??)
  koji: Adjusting line-height, adjusting margin is second part.
  koji: That's problematic?
  Rossen: In general, if you marry the size of a box to the its
          position.
  Rossen: If you're fixing the height of the box based on its
          position.
  Rossen: Then the problem becomes hard.
  dbaron: So, if you were to...
  dbaron: I'm curious why you want the height.

  fantasai: The goal is to snap the height of an element's margin
            box to a multiple of the line height.
  dbaron: If it always breaks margin collapsing, then maybe it's
          implementable.
  Florian: Why does margin collapsing matter here?
  fantasai: If we don't have any collapsing margins, does this work?
  dbaron: Part of the issue is, is there going to be a problem when
          you try to implement and fuzz it, and is there an infinite
          loop.
  dbaron: Hard to answer off the top of my head.
  Florian: For this use case, if it would be with an uncollapsible
           margin, that's fine.
  Florian: Not sure if that's necessary, but if necessary to make
           sane to implement, sounds okay.
  dbaron: To be clear, my worry is about the margin inside the box
          collapsing to outside the box.
  koji: I myself don't really understand margin collapsing code atm.
  Rossen: It's pretty straightforward. :)
  koji: I'm sure I'll run into issues.

  koji: But haven't discussed how block snaps in my proposal.
  fantasai: I'm actually more worried about line part than block part.
  koji: There's a table about use cases and what gets adjusted.
  koji: I'm seeing that centering is quite difficult for us.
  koji: For first phase, only adjust margin-bottom.
  koji: After layout.
  koji: After height, determine position.
  koji: Height or margin is not affected by position in this proposal.
  koji: Only about adjusting margin bottom, output from height.
  * fantasai thinks this is worth working on, but doesn't think this
             proposal is ready for implementation yet.

  Rossen: Are you looking into A) sampling implementer interest B)
          moving into a spec and making a spec out of it or C) both
  Rossen: Think we should start wrapping up.
  koji: Asking both.
  koji: Want to see how much technical troubles I would get into by
        experimentally implementing in blink.

  Rossen: Is this something that should move to line grid spec?
  astearns: I'm of the opinion that this should be a more general
            thing,
  astearns: that can be applied to any length.
  * fantasai agrees with that too
  astearns: It's a multiple length, will snap to a multiple of the
            length you supply.
  astearns: Useful thing in all sorts of situations.
  fantasai: I think it's a useful direction to go in. Wouldn't
            implement just yet, want to work out e.g. interaction
            with margin collapsing etc. before trying to implement.
  koji: So make an ED?
  fantasai: Yeah, work out the details a bit, then decide where to
            put it.

  Rossen: For the B) part of the question is, let's start with an
          editor's draft, and go from there.
  Rossen: For other ones, implementers intent, that's an answer that
          we'll be getting as we work on the spec.
  Rossen: At least our reaction is, this is an interesting problem
          to solve.
  Rossen: Heard quite a bit in terms of interest at least in Japan.
  Rossen: That was one of the very clear asks from the Japan
          Industry Meetup.
  Rossen: Would we just throw everything away and start working on
          this immediately? Probably not.
  Florian: Another comment...
  Rossen: Not sure how much will bring to the table.
  Rossen: If there is an implementer really interest, engage with
          koji.
  Rossen: Otherwise let's take a break and come back.

  RESOLVED: Make an ED for snap-sizing
  RESOLVED: Editors koji and fantasai

  * fantasai proposes css-rhythm
  <Bert> (As the use case is double-sided printing, I guess it is
         more interesting if PDF formatters want to implement it
         than browsers...)
  <liam> (i think that's only one use case, but also it'd be a
         mistake to think people don't print web pages)

  <br>

  Florian: For CJK layout, in addition to line height snapping, it's
           important to do the same thing in the inline direction.
  Florian: The problem is slightly simpler, don't need to snap every
           character. Line length is sufficient.
  Florian: When you want to do such a thing, you use a font where
           each character is exactly the same width,
  Florian: No need for magic.
  Florian: The other reason is that at least in Japan, and mainland
           China, if some chars aren't full-width.
  Florian: You don't line up to the grid, you line up the start and
           the end and justify between.
  Florian: There are some cases where you want something else, but
           usually that's enough.
  Florian: Koji's spec, and mine, trying to address working on that
           line being a multiple of the char width.
  Florian: So that it works fine within the line.

  Florian: My proposal is an extension or variant of the line grid
           spec.
  Florian: Koji's proposal is more in line of size snapping.
  Florian: Same differences apply.
  Florian: What we discussed briefly during the break is that we can
           add my proposal to line grid spec.
  Florian: And as we work in parallel on line grid spec and snap
           heights do the same thing on these two features for
           inline axis.
  Florian: Proposal is to fold my proposal into Line Grid spec and
           figure out details there.

  SteveZ: One comment -- seems to be em based, need to use multiple
          of ideographic advance which is not necessarily 1em.
  Florian: Need to base on a different char,
  Florian: Similar to ch unit.
  Florian: Should probably use that unit instead of em.

  fantasai: On the topic of units, we've discussed line height unit
            and ideographic char unit. Are there other units we
            need, maybe add to Value sand Units 4?
  Florian: I wanted to add my proposal to spec.
  fantasai: We deliberately left it out to keep the draft simpler.
  astearns: I'm okay to add back in and split out later.
  Florian: Would prefer to have it in a spec rather than in people's
           heads.
  fantasai: I would be okay with it if we clearly mark it as
            targeted at level 2.

  Florian: Second issue is adding unit for ideographic character.
  fantasai: Seems useful for me.
  fantasai: Would be a unit based on the advance width of the
            character for water.
  dbaron: Need height and width.
  <dbaron> ...since it has a fixed orientation
  fantasai: So ih and iw?
  fantasai: Does it need just a single thing that's the advance
            measure?
  dbaron: If you do that, need to write down entire property
          dependency graph, to make sure it doesn't introduce any
          cycles.

  RESOLVED: Add ideographic advance unit to Values and units 4, come
            back to WG for approval after details worked out.
Received on Sunday, 13 March 2016 12:39:05 UTC

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