W3C home > Mailing lists > Public > www-style@w3.org > May 2017

[CSSWG] Minutes Tokyo F2F Wed 2017-04-19 Part II: Writing Modes PR, USVString, Baseline Alignment [css-writing-modes-3][cssom][css-align]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 26 May 2017 20:40:48 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <0c75b4a3-1914-cb54-df73-17b6d4140ad9@inkedblade.net>
   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

   - There was conversation as to if the spec was passing enough
       tests to move to REC. In general it seemed as though failures
       were implementation problems or problems with related specs,
       not problems with the Writing Modes spec.
   - RESOLVED: Change "containing block" to "parent box", and define
   - RESOLVED: Republish WM as CR, after making the normative change
               for the current open issue.
   - There will be a four week review period after the CR publication.


   - RESOLVED: CSSOM can use either USVString or DOMString
   - If any web compat issues are found from this change, issues
       should be raised.

CSS Box Alignment

   - Discussed proposal to use final scroll position to find last
     baseline of scrollable boxes vs current resolution of using
     the higher of the last baseline and bottom margin edge at
     initial scroll position.
   - RESOLVED: Change bottom margin edge to bottom border edge.


Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics

Scribe: TabAtkins

Writing Modes

Implementation report

   koji: The current status of Writing Modes is that we have an impl
   koji: In the topic.
   koji: And a DoC update.
   koji: One open issue from Boris.
   <koji> https://wiki.csswg.org/planning/tokyo-2017#topics
   koji: If there are any comments on the impl report or DoC...
   koji: Hopefully solve the last open issue, and get the resolution
         to publish.
   koji: If anyone has feedback, please let me know.

   Florian: I have on both.
   Florian: Some detailed feedback, but first...
   Florian: I think we should indeed go to PR with this module; it's
            in a good shape.
   Florian: The impls are coming along, and there are political
            reasons to take a stand and say this has made progress.
   Florian: But we should do it with the understanding that we are
            stretching a little the definition of what a REC is.
   Florian: Our charter says "2 indep.. impls of each feature", and
            that's fuzzy - what's a feature?
   Florian: We don't need 2 impls of the entire spec as a block; I
            think we have two impls of each testable statement.
   ChrisL: That's correct.
   <tantek> at least a property is a feature, or a value

   fantasai: For example, WM in table cells. Impls do slightly
             different things.
   fantasai: It's a fairly significant use-case for vertical text,
             but it flat-out doesn't work.
   Florian: So it rotating a table cell is a feature, we have it, but
            we don't have sizing in the same browser.
   <Florian> http://jsbin.com/vubeti/edit?html,css,output
   fantasai: So it's more of a weird way the test got split out.
   Florian: Haven't tried this test-case in the latest everything,
            but recently, not a single browser does everything.
   Florian: Enough browsers pass each aspect that we can pass all the
            tests, but none pass it meaningfully.
   Rossen: What do you think should do?
   Florian: [details that I missed]
   Florian: With that said, I think we should still go to PR.
   Florian: This is a large enough spec with fingers everywhere;
            we'll find issues for years. If we wait for it being 100%
            complete, we'll never go to REC.
   Florian: Just want to make it clear that just having unit tests
            passing doesn't mean the job is done.

   koji: As far as I understand.
   koji: ...w3c process means you have to pass unit tests
   TabAtkins: Passing all unit tests isn't enough to say you
              implement the feature, you do need integration tests
   <TabAtkins> (If you can pass all the tests but not implement the
               feature correctly, there aren't enough tests.)
   Rossen: That's fine. People will find bugs, they'll file, we'll
           become more interoperable...

   iank: We'll be doing a revamp of our table code probably 9-12
         months from now.
   iank: Expect we'll have more feedback at that time.
   Florian: To be clear, I didn't take tables as the sole thing; it's
            representative, and I was putting together a talk for the
   Florian: I was doing some example coding and saw we didn't have

   dbaron: I'm worried about how this interacts with intrinsic sizes.
           Much is not in WM, some is in Sizing, some I think is not
   dbaron: I think when you say something "doesn't work", it's
           because it doesn't do what you expect, but the obvious way
           you can fix the spec might not be something we're willing
           to do.
   dbaron: So it might take changes to the spec to get to the point
           where we agree on an intrinsic sizing behavior. Maybe
   dbaron: So this makes me worried to take this to PR right now.
   Florian: Agree. I still think PR is useful for political reasons.
   iank: Intrinsic sizing isn't well-defined for WM, right?
   fantasai: It is, I think.
   dbaron: I disagree.
   fantasai: It requires doing layout.
   dbaron: Which I don't ever want to do.
   fantasai: ...which Firefox and Chrome don't have the architecture
             for, yes. But Edge does, IIRC.
   Florian: For this spec, we'll find issues for a very long time.
            I'm not sure it would be a good move politically to delay
            the spec for 5-10 years.
   fantasai: Solving vertical text in table cells requires doing
             intrinsic sizing after layout, and I don't think it's
             reasonable to say that we will never solve what is a
             major use case of vertical text
   dbaron: I don't think that it requires not addressing those use
   <tantek> This sounds to me like 1) we don't have actual interop
            (use cases), 2) if we don't know what features are
            features, we are underspecified CR exit criteria, and
            need to fix that with a new CR that specifies it, 3) if
            we have disagreement among browsers on how these features
            work right now, it is likely we will need normative
            changes to fix it, which means we need a new CR
   <tantek> "will find problems a very long time" is just normal
            maintenance expectations and must not be used as an
            excuse for any decision.

   Florian: HTML has gone with some holes and vagueness.
   Florian: We have a fairly comprehensive test suite.
   TabAtkins: Mentioning HTML in this regard isn't meaningful.
   Florian: There's been substantial push from Japanese gov to get
            this to a more stable level.
   Florian: As a milestone.
   Florian: Maybe we wouldn't ideally want to call it Rec, but that's
            the name we have; we can still have things to fix.
   koji: Ignoring the Japanese community, Rec always to me means
         there can still be work to do.
   tantek: That's false. "There's always maintenance" is true for
           everything. But it's a difference of degrees - there's a
           difference between holes and interop.
   fantasai: There's always going to be interop issues - CSS2.1 still
             does. There's a just different thresholds you can hit.
   fantasai: It's always a judgment call, and a reflection of the
             issues we have going in.
   fantasai: I think there's still some issues to edit in, but
             there's not much issues coming in for the spec itself,
             just minor details.
   fantasai: There are a lot of impl bugs - this spec affects *every*
             layout system - and there will be forever.
   tantek: You're using incoming issues as a metric - Florian, did
           you file issues for these?
   Florian: No, because they're not spec bugs as far as I can see. I
            could be wrong.
   tantek: If you can't make a judgment call, file an issue.
   tantek: So someone else can decide.
   fantasai: A large part of the complexity of the spec is its
             interaction with all of CSS 2.1.
   fantasai: There's no error in how the interaction is described,
             there's just a lot of details that can get wrong in

   tantek: A particular issue that bothered me - behavior in table
   tantek: In CSS 2.1, how properties worked in/out of table cells
           was one of our biggest sources of interop problems.
   tantek: So if we can't even do that, we have major problems.
   Florian: I don't know if it's a spec problem - my reading isn't
            showing a problem - but are impls wrong because they
            don't know it's wrong, or they know it but can't fix it?
   rbyers: That's what tests are for.
   Florian: I don't have budget for detailed investigation work. I'm
            just raising the flag.

   Florian: So being aware of that, do we do that and go to Rec in a
            year or five, or go to Rec for political reasons and
            still fix it.
   dbaron: A third possibility is that the impls *are* doing what's
           specified... there's plenty of holes.
   fantasai: There's bits where things are defined "analogously to
             2.1" - if you don't make that translation correctly, you
             get some bugs.
   fantasai: That's where most of our issues come from - people not
             applying the analogy fully and correctly.
   fantasai: Different from Flexbox or the like, where interop issues
             are a problem directly in the spec.
   tantek: I see that; we had similar with box-sizing, and we had to
           go into more detail. Maybe that's the solution.
   fantasai: That means rewriting the 2.1 block/inline layout specs,
             which isn't happening right now.
   tantek: Sure. But currently our features just don't pass the
           interop guidelines.
   Rossen: I don't believe this is true. I agree with fantasai that
           WM is a horizontal feature that cross-cuts, like intrinsic
   <tantek> Fundamental problem is: do use-cases have interop or not?
   fantasai: Like logical properties; we don't define each individual
             property, we just describe the mapping and the names.

   Rossen: Counter-example to get away form WM for a second - when we
           started defining fragmentation, another horizontal
           feature, we had a choice - start defining how
           fragmentation works for everything, and put all of this
           into one single spec, or define the basic rules and what
           it is and how it's supposed to be applied, then every
           other layout module defines how it happens.
   Rossen: WM is not that different.
   Rossen: Going thru the WM spec, the WM part is pretty well-defined.
   Rossen: There are interactions with every layout module, there
           will be integration issues - a flexbox inside a table
           inside a grid, all with different WMs, there will be
           issues that impls have to work thru, and we do.
   Rossen: That's not a WM problem, that's an integration problem.
   Rossen: So for horizontal features, I don't want us to have to
           pull all of CSS into the feature and blaming all the buggy
           integrations on this particular spec.
   tantek: I get that, but a bit of a strawman - inside a table cell
           or not, or inside an abspos or not. Those seem simple
           circumstances, that an author would expect to work.
   tantek: If we don't have tests that demonstrate interop on that, I
           find it hard to believe we have interop.
   koji: We have those tests, but only some are passed in each
   Florian: Worse, each layout mode not only has to work in other
            WMs, it has to work in orthogonal flows.
   Florian: We have only 1k tests - it can't cover everything.
   Florian: But if we cover everything that exists today, we'll never
   tantek: Still strawman. If the simple examples you came up with,
           just to show something at the AC meeting, that's stuff we
           should look into.
   tantek: You're not making a newspaper, just simple examples. If
           you don't have interop there, something's broken.
   tantek: Maybe spec, maybe impls, but we have to investigate.
   tantek: I'm not asking for perfection.
   <Florian> http://jsbin.com/vubeti/edit?html,css,output

   koji: So what do you say when two impls pass?
   TabAtkins: He's saying that we have a theoretical integration test
              failing, even though unit tests pass.
   tantek: Not even a complicated one - no deep nesting - just simple
           "in a table cell".
   Rossen: So there are impls that are behind, and it's up to them to
           catch up.
   koji: Blink and Webkit don't implement it in table cells, but we
         plan to implement it
   Florian: And the two that have it, MS and Mozilla, behave
            differently, and neither is good.
   Florian: Mozilla doesn't implement sizing - your table cell will
            be rotated but sized wrong.
   Rossen: So it's an impl problem, file a bug.
   Florian: Unless Mozilla won't fix it - then it's a spec problem.
   fantasai: Koji said that Chrome/Blink will fix it though
   rbyers: Sounds like we should have a more integration-y test.

   Rossen: So currently 98% passes in two impls.
   Rossen: Which means it works in a lot of major cases.
   Rossen: I can find you float bugs today, and we've had floats for
           15 years.
   Rossen: It would be a little unfair to blow it up and say 2.1
           can't go to Rec.
   Rossen: At the same time, there's plenty of content that's
           depending on vertical WM that works well.
   Rossen: epub, etc.
   Rossen: Even though it's not as interoperable as it should be.
   Rossen: But WM today, for 90% of use-cases, is usable as-is.
   Rossen: It would be a little unfair to over-index on one thing and
           let it skew whether we go to Rec.
   tantek: I'd call into question your 90% assertion.
   tantek: If every example Florian tried to show is failing
   Florian: I haven't tried comprehensive testing, so maybe I was
            just very unlucky to run right into the problems.
   koji: And table cells are a known issue for two browsers, so you'd
         have to pass both for the two remaining.

   koji: Pages have really changed today in using WM. Nowadays, many
         pages are using WM in real pages, I see this supporting
         Rossen's idea.
   astearns: And jensimmons started writing up tons of WM examples a
             few months ago, and she's not been reporting spec bugs.
   Florian: So the devil is in the details here. It's def not done
            and tied up, there are problems, but they're probably not
            that bad - it's used in the wild - and probably not that
            good - we find some problems.
   <jensimmons> I haven’t found bugs in Writing Mode implementations,
                no. And yes, I always test cross browser (although
                sadly, not Edge so much since that’s on a different
                machine). My biggest complaint about WM
                implementations is that only Firefox has
                writing-mode: sideways-*;
   tantek: Are people testing in one browser?
   rbyers: 1 in 200 pageviews in Chrome are using WM. We rarely see
           features that popular for Chrome-specific code.
   koji: And people end up knowing that WM doesn't work on table
         cells; they instead put a <span> in there as a workaround.
   <tantek> good to know koji, thank you

   <Rossen> here's what we see in terms of usage
   <Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/writing-mode/
   <rbyers> And here's Chrome usage: https://www.chromestatus.com/metrics/css/timeline/popularity/394
   * jensimmons expects Writing Mode usage to increase now that CSS
                Grid has shipped. Trying to use WM without Grid was
                not nearly as exciting. A lot of ideas for WM require

   Rossen: Koji, you had some questions/issues to go over, can we get
           back to that?
   Florian: I have some comments, but they don't matter if we decide
            to go ahead with publishing.
   Florian: There's some places in your report that lists tests that
            fail, but it's okay because they're cross-spec tests for
            specs not in Rec, but for some I can find what the other
            spec is.
   fantasai: Some are the unicode specs; if you have bad unicode
             data, some of these will fail.
   Florian: But isn't Unicode REC-equivalent?
   fantasai: Yeah. But if you just miss some cases in scripts, it's
             more of a Unicode bug than a WM bug.
   Florian: So do we want to go that level of detail, or do we just
            say "eh, we're going to Rec, don't bother".
   astearns: The # is so small, that removing them doesn't change the
             % passing (at integer courseness).
   Florian: I think we shouldn't mislead ourselves that this is
            Done©, but as long as we're aware of that, I think we can

   <skk> For my understanding, WM is huge spec, and it affects lots
         of other specs. And it looks difficult to satisfy
         interoperability with other specs. As Florian said, "being
         aware" might be important. So, WM L4 or L3.1 (it doesn't
         exist now. This might be bug-fix spec for WM L3) is needed
         for "being aware".

Orthogonal flows on inlines and display transformation

   <fantasai> https://github.com/w3c/csswg-drafts/issues/1212
   koji: Can we discuss bz's issue?
   koji: When WM is different from parents, the spec says it
   koji: bz is saying that "blockifies" can't compute containing
         block before layout.
   koji: It says "parent element", should be "parent box", but parent
         box isn't well-defined.
   dbaron: Historically containing block depends on styles, but this
           is trying to make styles depend on containing block.

   fantasai: We can change it to parent box, that's defined in
   fantasai: Only important case is when display is inline.
   fantasai: If any parent of an inline, which is also an inline, has
             a different WM, it will have become an inline-block,
             which makes it the containing block.
   fantasai: An inline can't have a different WM from its containing
             block anyway, it becomes an inline-block.
   fantasai: The difference between parent box and parent element is
             only really relevant for display:contents afaict.
   fantasai: You look "past" a display:contents.
   fantasai: There are other cases where this clause doesn't apply
   fantasai: I'm in the process of trying to figure out the wording
             with bz, but I think we can just change to "parent box"
             as long as people are okay with walking up
   dbaron: You can come up with a new term that is "parent element,
           walking thru display:contents".
   fantasai: That's just "parent box", no?
   dbaron: Box tree isn't defined yet.
   [fantasai and tabatkins bicker over whether it's sufficiently
   koji: [provides some example that I missed]
   fantasai: I think I can fix this over lunch.

   Florian: So we're looking for "parent element, but walk up
   koji: So should we define this in WM?
   fantasai: It's in Display; if it doesn't quite exist yet, I'll
             define it.
   Florian: So it sounds like we agree on behavior, if not on
            terminology. Can we resolve to that?
   Rossen: Sounds like nothing to change in WM?
   fantasai: There's a mention of "containing block" that needs to
             change to the new thing.
   koji: So proposal is to change "containing block" to "parent box",
         and define that.
   Florian: And we can define "parent box" without needing the whole
            box tree.
   TabAtkins: "Closest ancestor element that generates a principle

   RESOLVED: Change "containing block" to "parent box", and define

   <tantek> that's a normative change right?


   koji: So with the last open issue resolved, I wonder from the last
         discussion if we're fine to resolve to publish or what.
   tantek: Didn't we just make a normative change?
   astearns: We need to make the update, get bz's approval, *then* we
             can ask for PR.
   Florian: Do we have to cycle CRs since it's a normative change?
   tantek: Technically, yes.
   tantek: Any excess features to drop?
   fantasai: We already did.
   Rossen: So we can resolve to republish CR with that change?

   RESOLVED: Republish WM as CR, after making the normative change
             for the current open issue.

   Rossen: Response period?
   Florian: 4 weeks, shortest time, we're not looking for any
            particular input here.
   <fantasai> just bzbarsky's input :)

CSSOM: USVString vs DOMString
   Scribe: fantasai

   <dbaron> Github topic: https://github.com/w3c/csswg-drafts/issues/1217
   SimonSapin: In JS, strings are made of a sequence of 16-bit
   SimonSapin: Can be any arbitrary sequence
   SimonSapin: Usually interpreted as UTF-16
   SimonSapin: But doesn't have to be well-formed UTF-16.
   SimonSapin: In particular, there's a range of values that are called
   SimonSapin: If you have a leading surrogate plus a trailing
               surrogate, i.e. 2 UTF-16 ints, that forms a single
               Unicode codepoint.
   SimonSapin: But in JS, nothing stops surrogates from appearing in
               the wrong order, or a single one by itself.
   SimonSapin: This is invalid Unicode.
   SimonSapin: But you can do it in JS.
   SimonSapin: If you want to convert that string to UTF-8, UTF-8 is
               designed to exclude surrogate codepoints to align with
               set of valid UTF-16 strings.
   SimonSapin: So not all JS strings can be represented in UTF-8
               without losing data or using an escaping mechanism.
   SimonSapin: Wasn't an issue, because every browser internally uses
               same type of string as JS7.
   SimonSapin: So if you have CSSOM string that has an unpaired
               surrogate, e.g. in an ident or content property string
   SimonSapin: it's ok.
   SimonSapin: What's changing now is that in Firefox, we have a
               project called Stylo, which is to import Servo style
               system into Gecko.
   SimonSapin: That style system is using Rust str type for all
   SimonSapin: which is based on UTF-8, so it cannot represent
               unpaired surrogates.
   SimonSapin: What that means is in practice, whenever a string
               comes from CSSOM and goes into the style system in
               Servo and in the future in Firefox, we convert to
               UTF-8 and in that process, any unpaired surrogate is
               replaced with U+FFFD REPLACEMENT CHARACTER
   SimonSapin: So there is some data loss.
   SimonSapin: However, I think this kind of situation only happens
   SimonSapin: Fact that JS strings are this way is not a feature,
               it's a historical accident.
   SimonSapin: I don't think there is a real compat risk with
               shipping Firefox this way.
   SimonSapin: Still, it's a deviation from current interoperable
               behavior, so wanted to bring it up.

   Florian: Proposal?
   SimonSapin: In WebIDL which we use to define interfaces for JS,
               there is two string types. DOMString corresponds to JS
               strings with arbitrary 16-bit.
   SimonSapin: Then there is USVString, Unicode Scalar Value String,
               which has no unpaired surrogates, only well-formed
   SimonSapin: When you convert DOMString to that, you get the same
               behavior as in Servo, replacing lone surrogates with
   SimonSapin: If we want to keep this interoperable, then I propose
               to use USVString for all of CSSOM.
   ChrisL: Seems like a good idea, since unpaired surrogates are only
           an error.
   ChrisL: Only used for binary data, and can't imagine that in CSSOM.

   TabAtkins: USVString is supposed to be avoided in WebIDL.
   TabAtkins: Currently only used in networking protocols that use
              scalar values.
   TabAtkins: Requires extra processing compared to UTF-16 strings.
   ChrisL: Maybe in custom properties though, people would want to
           store binary data; they should encode it to avoid syntax
           issues though so no big deal.
   dbaron: Annevk disagrees with advice in WebIDl spec, btw.
   dbaron: There's a github issue against WebIDL spec to give
           coherent advice, but ppl disagree on what that should be.

   dino: Appreciate that you want to use rust string type, but we all
         have to use our own string types.
   dino: Maybe resolution is all DOM strings should be that way.
   TabAtkins: No, that would break a lot of things.
   TabAtkins: People smuggle binary data in JS strings
   TabAtkins: But for things that talk text, could do it.
   dino: Everything, not just CSSOM.
   Florian: Would it be reasonable for implementations that don't do
            rust strings internally?
   myles: If we don't know perf impact, can't agree to do this
   myles: So somebody somewhere has to try it first before we agree
          to it.

   SimonSapin: Tab, did you mean changing JS or DOM would break things?
   TabAtkins: Some DOM Apis have to be 16-bit, e.g. Fetch ...
   rbyers: It's not in Chrome.
   [TabAtkins muses]
   till: It's not entirely out of the question that it would be
         Web-compatible enough that we could change it in JS itself.
   fantasai: For JS itself, Tab was saying it's not doable, but for
             DOM Apis more likely to be possible.
   <TabAtkins> Mistook the API - *Fetch* uses USVString, but XHR uses

   iank: Need to check with architecture folks about this
   iank: Our architecture folks in charge of bindings and string
         types and stuff.
   iank: Looked for code where we switch to USVStrings, and that's
         very expensive for us it looks like.
   iank: Might be perf problems.

   fantasai: My take is that this is a very weird edge case with no
             real use: lone surrogates in the CSSOM.
   fantasai: So I would say, let's spec you can use either, and we
             don't care.
   myles: Every string would have to get transcoded, that's crazy.
   TabAtkins: ....
   iank: Would have to guarantee that that block internally is clean.
   TabAtkins: Move to UTF-8 clean internally.
   iank: Sounds non-trivial.
   Florian: Spec that either is Okay then it's not any work.
   Florian: If we can't spec that, then it means web depends on it,
            so Servo will have to bite the bullet.
   TabAtkins: I'm okay with doing that, put a note that we'd like to
              move to USVString.
   shane: If there's a web compat problem, then it's a problem.
   TabAtkins: That means someone is injecting lone surrogates into
              the CSSOM. Can't come out of the parser.
   TabAtkins: In that case probably buggy anyway.
   shane: If ppl notice a problem, they'll file bugs.
   eae: It's very hard to get into the situation except intentionally.

   myles: Does Servo have to translate between JS string and UTF-8
          String all the time?
   SimonSapin: Yes
   SimonSapin: We have optimizations, e.g. if ascii then stored in
               one byte per unit, skip UTF-8 conversion.

   Florian: Can we just resolve on allowing both and if it's a problem,
            if it comes back with issues, we'll change the spec?
   fantasai: I think interop in this very very weird case is not
             worth any effort, so spec should allow both.
   till: It's not servo-specific, others might want UTF-8 codepaths.
   myles: I believe that you believe that.
   Rossen: Any objections?
   rbyers: We should re-discuss if we find web compat issues.

   RESOLVED: CSSOM can use either USVString or DOMString

   fantasai: We can always raise issues if they're found later.
   SimonSapin: This also affects other specs with WebIDL interfaces,
               e.g. CSS Fonts defines @font-face interfaces
   Florian: Should we define a CSSString?
   iank: But if we do this later...
   fantasai: We are literally deciding that you can do either,
             forever. Unless someone comes back and says "lone
             surrogates in CSSOM are an important use case and I need
   * fantasai is sure that will never happen
   [Rossen discusses agenda items]

CSS Box Alignment: Last baseline alignment of scrollable boxes
   Scribe: shane

   <dbaron> Github topic: https://github.com/w3c/csswg-drafts/issues/766
   fantasai: If you have a scrollable box with content
   fantasai: question of last baseline, once content is taller than box.
   fantasai: Most recent resolution was that if last baseline is
             above the fold then use that, if below the fold then
             floor at bottom margin edge
   fantasai: previously just used bottom margin edge regardless.
   fantasai: TabAtkins and I want to suggest that once scrolling
             offscreen, scroll whole box to the bottom and pick last
             baseline at final scroll position.
   myles: In order to know where baseline is then you need to do a
          scroll, look at baseline, unscroll?
   fantasai: Just need to figure out bottom scroll position then find
             last baseline's position then subtract bottom scroll
             position from it.

   dbaron: What if there's a bunch of whitespace and when you scroll
           to the bottom your last baseline is way up?

   smfr: Does this apply to overflow: hidden as well as overflow:
   smfr: An alternative is to align to the baseline of the last
         visible line (i.e. the one you can see).
   dbaron: That's weird because different font metrics could make it
           pop differently.
   smfr: Won't you get popping with this too?

   iank: Can we just consider this an edge case?
   Florian: What's the use case?
   Rossen: DIY form controls.
   iank: If you've got a eula at the bottom of a form, e.g.
   Rossen: In the non-overflowing case it makes sense to align to the
           bottom line, I think we all agree to that much.
   dbaron: I agree it's abstractly sensible. But we have interop on
           the opposite right now.
   fantasai: WebKit implements the resolved behavior and has for many
             years. So no interop.
   Rossen: Which means nobody cares?
   tantek: So we have interop except for WebKit.
   fantasai: Yes, WebKit's behavior is higher quality than the
             specced behavior.
   Florian: And this means there isn't evidence that there's
            dependence on either behavior.
   myles: So are there other use cases than a select box?

   flackr: Proposed behavior is has discontinuity - if baseline falls
           below margin then it might suddenly jump upward.
   fantasai: No.
   Rossen: Do you have the problem of baselines above box today?
   myles: We just take the ???
   dbaron: People often put a page of blank space below scrollable
   <smfr> https://codepen.io/anon/pen/Wjreqe
   myles: ???
   Rossen: Which is less than optimal for when there's no overflow.

   myles: Resolution was 3 years ago, hasn't been any movement so far.
   fantasai: It is in CSS Box alignment module which is about to hit
   Rossen: When you changed this were there use case motivations?
   myles: From what I remember it wasn't use case based. I was
          working on some site compatibility problem
   myles: something like a row of icons and we were shifting them
   Rossen: Which was dbaron's concern - that we might start breaking
           such content.
   Rossen: I share that.

   iank: Reiterating: currently 3 impls just do the end margin edge.
         Current resolution is to do last baseline if no overflow,
         otherwise end margin edge.
   myles: Logic was that if text shorter than block, putting
          overflow: hidden on should have no effect.
   iank: That's different to no overflow though, right?
   myles: nope, *draws*
   iank: But if you have a massive box with no text and it triggers
         overflow, then last baseline would go to end margin edge?
   smfr: I posted a codepen with examples: (https://codepen.io/anon/pen/Wjreqe)
   fantasai: That's not clear.
   fantasai: If the last baseline is above the bottom edge and
             there's no overflow, why would you jump if there was
   fantasai: Baseline should be the bottom edge only if it would
             otherwise be below.
   myles: That describes what we currently do.
   iank: OK so if there's overflow you still look at the last
         baseline of the text.

   fantasai: Seems weird we're clamping to the margin edge rather
             than something where the text stops being visible like
             border box.

   Rossen: OK so back to myles' comment, is anyone actually going to
           change this?
   smfr: I can't see any difference between browsers in this codepen.
         I think I've captured the behavior.
   smfr: OK I've updated the codepen and the 3rd box now has a
         different baseline in browsers
   smfr: Safari differs from everyone else.
   fantasai: And Safari's behavior is what we resolved on.
   Rossen: So this is what's defined in the alignment spec?
   fantasai: Yup.
   Rossen: Do we need to resolve anything further?
   fantasai: Only if we want to change it, e.g. what we proposed or
             change margin-box to padding-box.
   Rossen: border?!
   fantasai: padding!?
   Rossen: Don't need to decide on border vs. padding right now.
   fantasai: Trying to take spec to CR, need to close off the issues.
             Could maybe decide after lunch though?

   <br type="lunch">

   fantasai: We discussed the last baseline of scrollable boxes, but
             we need a resolution.
   fantasai: The last thing I heard: suggestion: floor it at the
             bottom border edge.
   Rossen: <deliberately nods>
   fantasai: 3 options: 1. leave it as is. 2. Change from bottom
             margin edge to bottom border edge. 3. Scroll to the
             final position, take the last baseline.
   fantasai: Aforementioned suggestion is #2.
   Rossen: What does "leave as is" mean?
   fantasai: What the spec says now.
   Rossen: Then there's no reason to do #1.
   <dbaron> I'm happy with either #1 or #2; I think #3 has some
            issues that would need to be sorted through.
   <fantasai> dbaron, do you want to see those investigated?
   <dbaron> fantasai, no need if we're just going to do #2
   astearns: objections to #2?

   RESOLVED: Change bottom margin edge to bottom border edge.
Received on Saturday, 27 May 2017 00:41:24 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:04 UTC