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

Minutes Telecon 2017-09-27 [css-backgrounds] [cssom] [css-writing-modes] [css-rhythm] [css-syntax-3] [css21] [css-inline] [css-multicol]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 27 Sep 2017 22:43:40 +0300
Message-ID: <CADhPm3uGX7sqj51ky2Tk5fbsGkPbODPQgNDLpv33jtyhg0wo8w@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.

'border: 1px inset' is not interoperable

  - It was agreed that if more specificity is needed for inset that
      work should occur in L4 of Backgrounds and Borders. However,
      there is currently no use case for this level of specificity so
      a use case is needed before this is revisited.

Define serialization for background shorthand

  - RESOLVED: Postpone this until there's further evidence of use
      cases and move this to L4 if there is evidence.

Publication of Backgrounds L3

  - RESOLVED: Publish a new CR of backgrounds and borders.

Orthogonal Flow Constraint: viewport vs scroller

  - RESOLVED: Add max-height as well as height to the conditions that
      define the height for resolution of orthogonal flow sizing.
  - Florian will write tests for this resolution.
  - It was suggested by Rossen to also add an informational note that
      this does not guarantee the height will be correct.

<hash-token> seems to get type ID for sequence "#-\" followed by EOF

  - RESOLVED: Fix the check for a valid escape as described in #1821.

Meta bug for line height

  - The working group was reminded to review the tests (available
      here: https://github.com/w3c/csswg-drafts/issues/1796) before
      the F2F.

Publication for Multicol

  - RESOLVED: Publish a new WD of multicol

Avoiding accidental double spacing

  - Koji wrote some test cases
      and wanted to understand if his test cases gave intentional or
      accidental double spacing.
      - In general, it was felt that the tests produced expected
  - Florian continues to be concerned that unintentional double
      spacing can occur between browsers on the same code due to
      differences in font calculations.
      - Koji plans to write more tests to investigate these concerns


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Sep/0053.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Javier Fernandez
  Robert Flack
  Tony Graham
  Dael Jackson
  Brad Kemper
  Myles Maxfield
  Thierry Michel
  Theresa O'Connor
  Anton Prowse
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Alan Stearns

  David Baron
  Bert Bos
  Emil Eklund
  Daniel Glazman
  Peter Linss
  François Remy
  Greg Whitworth

Scribe: dael

Agenda Setting

  Rossen: Let's get started.
  Rossen: Good morning!
  Rossen: As usual, first item is call for any additional items or
          anything to change on the agenda.
  rachelandrew: I posted to the list about putting multicol back to WD
                if we could add that.
  <fantasai> +1 to Rachel
  rachelandrew: To republish as a WD since we've had so many changes.
                I posted a run down of those changes.
  astearns: We decided to take this back to WD because there were so
            many changes. This is just a resolution to publish.
  Rossen: I see and I see your email.
  Rossen: Any other additional topics?

Spec Rec Next Steps

  Rossen: There was some good discussion on private list. I wanted to
          draw attention to the first one.
  Rossen: It's the topic of testability and that we want test cases to
          support CR+ specs.
  Rossen: astearns, are we closed on this topic? Is the final plan
          what's in the private list thread? Or do we need discussion?
  astearns: All I suggested was we keep issues open on CR specs until
            we have test cases.
  Rossen: And is there agreement on this?
  astearns: fantasai and I talked last night and I think...I think
            she's okay. Correct?
  fantasai: Yep.
  Rossen: Perfect. And thanks to everyone submitting test cases.

  Rossen: We have a couple of topics on backgrounds & writing modes
          which are tracked specs. I didn't see much about other specs.
  Rossen: If there are issues you're facing with the tracked specs
          please let us know.

Backgrounds & Borders

'border: 1px inset' is not interoperable
  github: https://github.com/w3c/csswg-drafts/issues/1489

  Rossen: Is zcorpan on?
  fantasai: I can probably take this.
  fantasai: Basically the inset and outset borders we don't define
            what color they should be. This is resulting in
            non-interop, especially on 1px. Do we want to work on
            aligning and, if yes, do we try and do this in L3 or L4?
  <tantek> L4 please
  fantasai: I don't think we can resolve on the result, but figuring
            out where to put this work would help me agenda set.
  Rossen: Fair.
  <tantek> unless someone has citations of real world sites where
           people are complaining
  <tantek> and in which case, seriously, 1px inset/outside/ridge etc.
           border?!? why?!?

  Rossen: For the impl would this be something high on your list of
          things to fix if we were to agree? Or will this be low
  Rossen: I'm going to take silence as it being low priority.
  Rossen: As an impl I would say this is low priority for us. We have
          no had any reports of issues because of this. I don't see us
          rushing this.

  Rossen: One more call.
  Rossen: If no one raises urgency I propose L4.
  Rossen: So this is the call. If you're an impl and want to rush an
          interop fix, now is the time.
  <tantek> if Edge is still using the Trident border style rendering
           code which was ported from Tasman, then I'd say that's a
           good default if you want to specify something in L4 :)
  <bradk> Wait for L4
  Rossen: Okay, let's take this to L4.

  Rossen: fantasai is this specific to 1px or inset in general?
  fantasai: I'm not sure.
  florian: From bug it looks like there's a general problem and it's
           worse at 1px. We need to dig into details.
  Rossen: Okay. Again, I don't think we can push inset to L4.

  <tantek> I want to know what is the use-case for these odd 1px
  <tantek> seriously why are people doing them? what effect do they
  fantasai: The spec has a not-specific statement as to what the color
            should be, but no formula. All impl are spec complaint.
  <tantek> yes that's deliberately vague to capture what
           implementations did in the late 1990s / early 2000s
  Rossen: Okay. Let's close saying if there are any more restrictive
          spec changes that have to be made in terms of inset and
          color computation, they would go in L4. Objections?
  tantek: I'd want a use case. Why are you doing this? for what effect.
  fantasai: The default rendering of hr to be consistent?
  tantek: Why?
  fantasai: Don't know.
  <bradk> Inset borders are not in vogue anyway
  tantek: That's why I want it documented. I'd prefer an explicit
          statement saying we don't know why to do this. Most things
          we do with a use case for what's trying to be achieved.
          You're just making work without a use case.
  <astearns> the effect we're looking to achieve is interoperability
             in an existing feature
  Rossen: Fair point.

  Rossen: Your point will be in github. If we ever come back to this
          we'll have to call for use cases and then revisit. Fair to
  tantek: Yeah.
  Rossen: Anything else?
  fantasai: That's it.

  <tantek> suspects that anyone wanting border color precision like
           that for 1px will explicitly compute and define each TRBL
           side's color explicitly
  <florian> tantek: I agree, and even more so once we add the multiple
            borders we've resolved on, you even do explicit inset/
            outset at subpixel level on retina screens.
  <tantek> florian yes, retina-specific enhancements / experiments is
           another good reason to leave those border-styles

Define serialization for background shorthand
  github: https://github.com/w3c/csswg-drafts/issues/418

  fantasai: Defining serialization when splitting BG into multi long
            hands. Question is do we tackle in L3 or is L4 okay?
  fantasai: Is it really important to converge now or are people happy
            to defer?
  Rossen: I'll piggyback on tantek's point for use cases as well as
          ask if there are any impl that are currently seeing interop
          issues because of this and in any urgency to change their
  Rossen: I'm hearing silence which I am taking as no interest or use
  Rossen: Obj to postponing this until there's further evidence of use
          cases and move this to L4 if there is evidence?
  <tantek> +1 to at least postpone to L4, and note explicitly no

  RESOLVED: Postpone this until there's further evidence of use cases
            and move this to L4 if there is evidence.

Publication of Backgrounds L3

  <fantasai> https://drafts.csswg.org/css-backgrounds-3/issues-cr-2014
  Rossen: Backgrounds and Borders was...that was bikeshedified last
          week, correct?
  fantasai: Yep. I updated DoC. We just closed issue 14. Issue 12 is
            adding caniuse panels which we don't need to block on. All
            other issues are clarifications or resolved.
  <tantek> ship it!
  Rossen: Awesome. Any objections to publishing new WD of backgrounds
          and borders?

  RESOLVED: Publish a new CR of backgrounds and borders.

  <tantek> do we have a changes section?
  <tantek> since prev CR?
  <astearns> do we have tests for all of the backgrounds and borders
             changes since the last publication?
  <tantek> astearns also a good question - "tests for all ... changes"
           - I was just looking for a "Changes from 2014 CR" section
           myself to understand what those changes were. tests would
           be great in addition!
  <tantek> anyway I'm ok with resolving to publish an updated CR (
           because that takes a while post-resolution) but I'd
           strongly prefer if it the updated CR included a "Changes
           from previous CR" informative section (e.g. in the/an
           appendi x)

Orthogonal Flow Constraint: viewport vs scroller
  github: https://github.com/w3c/csswg-drafts/issues/1391

  florian: We resolved recently that if you had orthogonal flows with
           indefinite size you would go with icb or closest scrollport
           with fixed dimensions. We did not discuss, but I found out,
           chrome & safari will also pick one up with auto height and
           fixed max height and they'll pick up the max for the auto.
  florian: Since we have almost two impl and that looks useful, I
           suggest we add scrollport with fixed max height to what we
           look through.
  Rossen: The one thing I want to add is that when we talk about these
          use cases and combinatorial nesting of scrollports the one
          thing I don't see being addressed is with the addition of
          flexbox and grid there are many different other cases which
          will result in a scrollport having a defined width or height.
  Rossen: And max height is not the only one. If your scrollport is a
          grid item with height stretch that will also be defined.
          Computing dimensions in which we resolve orthogonal flows
          based on these two properties won't be enough in all cases.
  Rossen: Having said this I also know there will be too many other
          permutations we can come up with so I'm a little concerned
          we will have something that kinda makes sense for blocks
          only but when we come to more powerful layout features we'll
          be back to having quite a bit of interop issues.
  Rossen: My hopes is we either keep it more vague for now or we try
          and nail down all the permutations.
  florian: For other permutations don't you need to do some kind of
           layout to figure them out?
  Rossen: You have to.
  florian: Max height you don't.
  Rossen: You have to do the layout to figure out final size. If we
          are striving for some height quality of guarantee which are
          of the order if you have orthogonal flow we guarantee it
          will always be visible. If we want that type of guarantee we
          need to do a lot more work and take into account other
          sizing and layout effects.
  Rossen: If we don't want that guarantee I'd prefer less rigorous and
          leave text as-is.

  florian: I'm not sure question of level is right. Once one behavior
           is established it is. I'd want to make it as convenient as
           we can without depending on layout. Adding max-height seems
           simple and useful. But if you don't want to I wouldn't
           object, I just noticed this was the case in 2 browsers
  <fantasai> +1 to Florian
  Rossen: Here you have 2 impl that have this behavior. And you said
          they are not interop when border and padding is in play. I'm
          a little wary of trying to define a little bit to nudge and
          require others to follow if we're not going all way.
  florian: Multiple browsers will have to change anyway because we're
           not interop. But your argument of all or not at all...okay.
           I felt it was easy fruit so I'd rather grab, but I don't
           care strongly. I just felt it was new information.
  fantasai: I agree with florian that including max height isn't any
            harder then doing height. I don't see a reason not to.
  Rossen: I've stated my reason.
  fantasai: We're not suggesting look for the thing with max height
            and use actual height. We're just saying use max height as
            the limit. That's straight forward.
  <fantasai> <div style="overflow: auto; height: 100px">
  <fantasai> <div style="overflow: auto; max-height: 100px">
  Rossen: florian I thought you said that would also work with height
  florian: What I meant is what fantasai said. That height is auto we
           can't use that height, but if max height is there we use
           that. I meant what fantasai said.
  Rossen: It's a pretty crude approximation. That you have max-height
          doesn't mean you'll grow to that. You could have a fixed
          height parent which drives overall height and you get
          overflowing vertical text. I don't see how max height
  florian: I don't think it guarantees, I think it's never worse and
           sometimes better.
  fantasai: You use smaller of closest scroller. If we look at closest
            scroller and it has no height we'll use initial containing
            block. Accounting for max height means we can limit. If we
            don't consider max height we'll be bigger for sure.
  florian: I think it's easy, sometimes useful, never worse.
  Rossen: I would agree with that. It shouldn't make it worse.

  Rossen: Are there other opinions on this topic?
  Rossen: What is effect on the current tests for writing modes and
          what would it do for progress?
  fantasai: Simple edit to text. In terms of tests the impl have yet
            to converge. I have an action item to write some tests for
            this. Impl sometimes match speccing behavior sometimes
            don't and that's because they're based on different logic.
            This is prob simpler. Regardless of this change we'll need
            specs to change.
  florian: If we write extensive tests we won't get 2 impl any way. We
           could write naive tests that pass.
  Rossen: Current snapshot of the test suite was sometime last year,
  florian: We resolved recently to change that so we need a new test
           anyway. It's just what resolution do we write it to.
  Rossen: I'm just trying to understand where we are.
  koji: As I understand last thing had 2 impl. And you said safari is
        slightly not interop.
  florian: If you just test this thing you get impl. If you try and
           interact to check for robust it breaks. If you just test
           this it passes in chrome and safari.

  Rossen: Other opinions?
  Rossen: Obj to add max-height as well as height to the conditions
          that define the height for resolution of orthogonal flow

  RESOLVED: Add max-height as well as height to the conditions that
            define the height for resolution of orthogonal flow sizing.

  Rossen: I also think adding a note that suggests there are many
          cases that will break this...the current resolution is
          brittle if we claim we guarantee the height.
  florian: We don't offer that guarantee. If you want a note that this
           helps but isn't enough, I'm fine with that.
  Rossen: A note that it's not guarantee is good for authors.

  ACTION florian to write tests for the resolution " add max-height as
         well as height to the conditions that define the height for
         resolution of orthogonal flow sizing"

<hash-token> seems to get type ID for sequence "#-\" followed by EOF
  github: https://github.com/w3c/csswg-drafts/issues/1821

  TabAtkins: Definitely a bug, needs change. I won't do details, but
             if you have a malformed hash token at end of stylesheet
             it can sometimes report it's valid even though it can try
             and escape an EOF.
  TabAtkins: If you have a hash token with like a # symbol [missed]
  TabAtkins: hash -/end of stylesheet it's [missed] This is a small
             bug to test if something is a valid escape. I don't check
             to see if second character is EOF. If I add that it won't
             have any additional consequences.
  TabAtkins: All bugs were extremely minute. It's just that this is
             not what was intended in the spec.
  florian: Go for it.
  Rossen: Any other opinions or concerns on this topic?
  Rossen: If not we can resolve.
  Rossen: Objections?

  RESOLVED: Fix the check for a valid escape as described in #1821.

Meta bug for line height
  github: https://github.com/w3c/csswg-drafts/issues/1796

  florian: As I've said before I made a bunch of tests and made
           conclusions. Please review my tests so we can change the
           spec. I think we're almost fully interop. Look into it.
           Thank you.
  florian: There will be TPAC drawings. But that will be more useful
           if people read before.
  Rossen: I see it's on the F2F agenda. This is a nudge to everyone to
          look before the F2F.

Publication for Multicol

  <tantek> changes section?
  <astearns> tantek - yes, many changes:
  <tantek> thanks astearns, noting here FTR:
  Rossen: Objections to publishing multicol WD?

  RESOLVED: Publish a new WD of multicol

Avoiding accidental double spacing
  github: https://github.com/w3c/csswg-drafts/issues/938

  <koji> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-330561882
  koji: The biggest problem for me is I'm failing to understand
        definition. I made this example ^
  koji: astearns gave me feedback that...the left most in the example
        is normal. Second I applied line-grid. I applied line-box
        contain to third.
  koji: Second block has some double spacing but astearns says they're
        all intentional. Is that common understanding within this
  myles: I think you're asking me?
  florian: Everyone.
  koji: Yeah. We need to distinguish intentional and accidental double
        spacing and there isn't a clear definition.
  koji: The second box is [missed] it happens accidental when font
        metric is only slightly larger. Is that correct?

  astearns: One thing I missed when I commented is that in your
            example you are not changing line height. It's all the
            same, but there are some fallback fonts making some lines
  koji: Correct. It started with line-height:normal and it does double
  astearns: Right. With that new understanding I believe you are
            correct that this is an example of the problem stated by
            the issue. 2nd is accidental line spacing because the
            author had line-height:normal and the grid set to
            something without double spacing.
  astearns: In my mind this is an intentional result of the feature.
            You use rhythm to get consistent spacing, but the content
            is such that you don't get it, so the spacing is forced by
            the grid so the result is what authors should expect.
  koji: Okay.
  koji: Are you saying this is intentional or accidental?
  astearns: Accidental in that if the author didn't know what content
            would go into their grid, they didn't have control over
            the fonts used, the person setting up line grid might not
            have expected it. But they chose a rhythm, chose a grid,
            so we're fitting author intent of using a grid.
  astearns: I think this is an example of the issue as stated. I
            personally don't think the issue is terrifically important
            because author said they wanted to use a grid or rhythm.
  koji: Thank you, that is exactly my understanding. florian do you
        have different opinion?

  florian: I'm struggling with how to say my opinion in 10 minutes
           when in last F2F we tried to discuss and didn't conclude in
           2 hours.
  florian: I think when you have a case of line-height: normal and
           then step to a value and large fallback the feature works
           as intended. Similar case, technically, is line-height:
           normal, line-height-step to a specific value, and the main
           font on the engine happens to be a little too big and
           everything is double spaced. That's not what authors want
           and I don't know how to fix that.
  florian: First problem happens with line-grid but the second one you
           don't have the same problem because line-grid falls out of
           main font size.
  koji: But if you go to single grid in that case lines overlap. Grid
        is fixed height, line-height is normal, and main font is lager.
  florian: Line-grid you don't set it. That's the point.
  koji: What you're saying is line unit is fixed size and line-height:
        normal and the primary font is taller then specified unit. Is
        that the case?
  florian: I think yes, I didn't hear you clearly.
  koji: If you compress the font to a single unit they overlap. You
        said the font is taller then the unit, right?
  florian: What unit?
  <Rossen> how is this problem different than having display: grid
           with fixed row repeats and auto placed grid items? ... some
           will fit in one row others will cause two rows to be created

  koji: Let me confirm. You said unit is fixed size.
  florian: I said line-step-height is fixed, line-height is normal.
           That font on that system gives a line-height taller then
           step you set for primary font.
  koji: If the font is taller and you try and fit in a single step you
        overlap, right?
  florian: Line-height is normal. They're larger then your step so you
           double space everything.
  koji: You said that's a problem?
  florian: Yes.
  florian: Double space everything is a problem if the rhythm works in
           general and some fallback is taller that's working as
           intended. If everything is double spaced that's not working
           as intended.

  florian: Primary font...I can't do this in 5 minutes.
  florian: I tried for hours and failed.
  koji: [missed] We mostly discussed which features people break and
        that's not related.
  Rossen: For the sake of furthering this, I think in summary I've
          heard that florian's main objection is in case of fallback
          font being slightly larger then primary you will have double
          spacing when fallback font is used.
  florian: That is how it works and in general not a problem.
  Rossen: And because of this you expect everything will have double
  florian: No, what I'm saying is when the author sets a value for
           line-step-height they don't know what the result of line
           height calculation will be so they cannot set it in a
           reliable way. So there is a possibility that things will
           look right on one browser and not in the other because
           different font metrics. That's not what the author wants
           and a limitation. The double space everywhere on every
           browser is what's wanted.
  koji: I think I understand your point much better. I'll prepare
        another test to see if my understanding is correct.

  Rossen: Sounds great. How about we try and wrap here. Seems like
          there's more clarity for koji in test cases you need to look
          at. Why don't you create the test cases and bring them back?
  Rossen: We'll take time during F2F on this, but if we can resolve
          before even better.
  Rossen: Okay for both of you?
  koji: Okay for me.
  florian: I have no objections to koji trying things out. I don't
           think it'll change what I think of this feature.

  Rossen: That's the top of the hour. Have a great day/night and we'll
          talk next week.
Received on Wednesday, 27 September 2017 19:44:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:08 UTC