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

[CSSWG] Minutes Telecon 2017-05-10 [css-writing-modes] [geometry] [css-grid] [css-align] [css-text] [css-cascade] [css-pseudo] [css-multicol]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 10 May 2017 23:31:55 +0300
Message-ID: <CADhPm3vLruxMOcgnPOigdftjsR1H34BKtBZWTudn4c2X=-mGXw@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.

Spec Rec next steps

  - Most specs were addressed over email in advance of the call.
  - astearns submitted a pull request for the final changes needed
      for Writing Modes.

DOMMatrix stringifier behavior doesn't seem to match implementations

  - RESOLVED: In the case of NaN we would throw an exception during

Stretching image grid items in both dimensions

  - RESOLVED: Stick with Seattle resolution: making the default

Rename `auto` to `legacy` for `justify-items`

  - RESOLVED: Rename auto to legacy.

Alignment publication

  - RESOLVED: Move CSS Alignment to CR with the added legacy value
              defined as at-risk. The action of starting the CR
              process will start in 2 weeks (May 27) unless we hear

Question re white space processing rules for U+000D

  - RESOLVED: Accept the change in

How does 'inherit' keyword behave in a child of ::first-line?

  - fremy will write a summary of the proposal on the GitHub issue
      so the group can resolve next week.

Allow percentages for `column-gap`

  - RESOLVED: Add percentages for `column-gap` to L1 and mark as


Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0022.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Robert Flack
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Michael Miller
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

  Vlad Levantovsky
  Lea Verou

Scribe: dael

Spec Rec next steps

  Rossen: Let's get started. Hello everyone.
  Rossen: Are there any extra items people want to add?

  Rossen: Thanks to everyone who replied to emails. Almost
          everything is replied.
  Rossen: One thing I couldn't gage is writing modes. Did we make
          the editorial change?
  astearns: I submitted a PR. It needs fantasai review and merged.
  Rossen: Awesome. Thanks astearns.

  Rossen: The other thing...there were a few specs that were still
          waiting for dbaron or someone from Mozilla for tests and
          discovering if there were some that could be contributed.
          Is any of that materializing now that we're past F2F?
  Rossen: I'll take that as a no.

Stretching image grid items in both dimensions
  Github Topic:

  Rossen: I don't see fantasai yet.
  Rossen: Anyone from Mozilla want to handle this? Or do we move on?
          Current tag is customer not satisfied.
  TabAtkins: We should wait on fantasai because she might have more
             to the topic to explore.

DOMMatrix stringifier behavior doesn't seem to match implementations
  Github topic: https://github.com/w3c/fxtf-drafts/issues/120

  zcorpan: DOM Matrix has [missed] for parsing a string. The string
           is CSS syntax. Values are unrestricted doubles so you can
           have non and infinity and it's unclear what the
           serialized is to do. If it returns NaN and infinity with
  zcorpan: I think the most reasonable things is to just use
           ECMAScript to string.

  TabAtkins: I asked in the related thread what's the benefit of
             allowing infinity and NaN in CSS and I'm not sure how
             the thread on DOMMRect you pointed to answer the
  TabAtkins: At the bottom of fxtf draft you reference the issue
             1343 in CSS.
  TabAtkins: You proposed CSS syntax should allow infinity and NaN
             so DOMMatric can round trip. I asked what was the
             benefit and you pointed to another thread.
  <smfr> TabAtkins is referring to
  zcorpan: It does cover DOMMatrix in that thread. It's part of the
  zcorpan: It's with one level of quotation for the reason of using
           unrestricted double in geometry APIs.

  TabAtkins: What transforms can produce a NaN or infinity in here?
  zcorpan: I'm not sure if it's possible.
  TabAtkins: We don't allow the values. It can't be possible because
             then we'd have transforms without matrix.
  ChrisL: You can generate one and re-serialize it.
  zcorpan: Exactly. If you do 1/0 it's an error now but it could be
           infinity instead.
  TabAtkins: It could in theory but it doesn't yet and we don't have
             a proposal to do it yet. afaict the only things that
             can produce NaN or infinity are operations we don't
             allow. I'm still not clear on the benefit of allowing
             CSS to recognize them because it doesn't mean anything
             in CSS. If you gave this to transform what would it do?
  zcorpan: I don't know. How matrix work is above my head, but you
           can end up with NaN and infinity so I wanted to get a
           resolution on how this would parse. I don't have a use
           case for it.
  TabAtkins: Alternative is in other cases where you can get into a
             state with a value that cannot be represented we just
             give up and do the empty string when you serialize. Can
             we do that? If you as for the CSS Serialization of a
             string with NaN or infinity you get an empty string.
  zcorpan: Reasonable. I can live with that.
  smfr: I know we're getting an empty string...
  zcorpan: If you parse it again you get an identity matrix.
  Rossen: zcorpan you're okay with TabAtkins resolution I think. Is
          there anything else to explore on this?
  zcorpan: Consensus on TabAtkins proposal sounds good.

  smfr: I don’t think think that returning an empty string is
  <smfr> authors won’t know why they got an empty string
  TabAtkins: smfr is disagreeing. Thanks for clarifying.
  TabAtkins: I don't know what else you can do, though. The to
             string of DOM produces CSS matrix. If you have a matrix
             that can't be a valid CSS transform, what are you
             supposed to do?
  smfr: Throw exception.
  zcorpan: What happens in Chrome & Gecko you serialize NaN. When
           you parse you get an error.
  Rossen: I still don't get what happens when you try and roundtrip.
          What's the expected behavior when you parse back.
  TabAtkins: Yeah, it fails to parse.
  <zcorpan> SyntaxError
  Rossen: So if this was an error on input, why not an error on
  TabAtkins: I'm okay with throwing as well. Just something that
             indicates the to string failed.
  Rossen: That's what I'd lean towards as well.

  Rossen: Let's try to resolve. Prop: In the case of NaN we would
          throw an exception during serialization.
  Rossen: Objections?

  RESOLVED: In the case of NaN we would throw an exception during

  <zcorpan> InvalidStateError?
  <TabAtkins> Yeah, I think that's probably the best error, zcorpan

Stretching image grid items in both dimensions
  Github topic: https://github.com/w3c/csswg-drafts/issues/523

  fantasai: In Seattle we had three options. One we wouldn't take
            because violates design guidelines. Other two we would
            have contain & intrinsic size behavior. You could opt
            into either. We picked intrinsic for the default.
            There's details in
  fantasai: We closed that, but Mats disagrees with the resolution.
            All other issues on Grid are closed as of when we
            stopped accepting issues.
  fantasai: This issue has a commenter disagreement so comes back to
            WG. Do we stick or do we change to contain sizing by
            default and opt-in for intrinsic via keyword-max-content
            or something like that.
  Rossen: Opinions?

  jensimmons: My opinion is I agree #3 should not be considered. I'd
              be okay with leave as-is, but I agree with Mats that
              as an author having the default be contain would be
              more handy and make more sense. We need both as an
              option and the tool to switch definitely. The default
              I'd lean contain.
  TabAtkins: Reason why we didn't go for contain is it puts sizing
             control in this property...
  fantasai: TabAtkins we changed.
  jensimmons: That was 3 which we agreed not to do.
  fantasai: Option was default is contain on all keywords, not just
  jensimmons: Ideally we would have tool to switch between, but the
              way the world works if we set default to contain we
              would get the switching tools quicker. Not certainly,
              but might.
  <rachelandrew> I'm still keen on the resolution
  Rossen: But forcing a less then optimal default as a forcing tool
          isn't doing much good.
  jensimmons: Agreed. I still like contain as a default. That's a
              secondary non-heavy.
  TabAtkins: I'm concerned that when we have contain
             sizing....having different defaults based on layout of
             parent it makes the design confusing. It's better if we
             have consistency.
  jensimmons: [missed]
  <Rossen> +1 to what Tab said
  fantasai: Flexbox resizes to fit the container. It does only do
            that with a single line. If you have wrapping it takes
  TabAtkins: It obeys constraint of flexbox and a bit of aspect
             ratio magic. The sizing is normal flexbox, not just
  jensimmons: You can make the same arguments here.
  TabAtkins: I disagree. Part of flex is doing this one thing. We're
             not adding a different way of sizing.
  jensimmons: I think from author prospective there would be
              something similar to having default of flexbox where
              they are both text and image contained. If there's an
              image just left with intrinsic size it starts to
              overflow and that's not typically what authors want.
              Authors expect content to stay in grid cells.
  fantasai: Things that are smaller then grid size, contain will
            cause them to size up.

  rachelandrew: I don't like the upscaling. I like the original
                resolution because it's the most consistent and
                easier to explain. The upscaling will cause problems.
  <gregwhitworth> +1 to TabAtkins rachelandrew
  fantasai: Another thing to consider is grid is being deployed and
            we don't have a definition of contains that WG approved.
            Changing will cause implementation stress.
  TabAtkins: Adding that, even if we had a contain definition, it's
             still transition stress because it's shipped without
             this. They're getting things to look well and then this
             change will break pages.
  fantasai: I would say if it was significantly better thing to do
            it might be worth doing, but since we're debating and
            there's good for both sides, given the status we're at
            it makes sense to go with intrinsic and add the contain
            keyword. That would be my position.
  TabAtkins: I agree.
  <rachelandrew> +1 to fantasai
  fantasai: I'm sympathetic, but it's not so clearly better that
            it's definitely the right answer.
  TabAtkins: I would also treat it differently if it was obvious fix
             instead of possibly better.

  Rossen: I'm seeing people favor option 1. Let's try for resolution.
  Rossen: Unless jensimmons you feel there's something else you want
          to add.
  jensimmons: I don't want to block it, but I think we need to
              define contain.
  fantasai: We have a definition, we need comments. There is a
            definition in sizing 4. Mostly waiting for dbaron and
            Mats there.
  jensimmons: We should keep going forward on getting that done
              because it's desperately needed.
  dbaron: Does option 1 match what impl ship today?
  Rossen: I believe so.
  TabAtkins: It does.
  jensimmons: I'm curious about that. I'm not sure what Mats impl
              and he did Gecko.
  TabAtkins: I'd hope he's not impl something different. Even if he
             is, the other browsers aren't.
  dbaron: I would disagree with TabAtkins' hope. But I don't know
          what he did.
  Rossen: Let's go back to this. Since Mats isn't here I'd like to
          call for consensus on #1. We'll continue working on
  <astearns> is this the definition?

  Rossen: Objections to sticking with Seattle resolution: making the
          default intrinsic?

  RESOLVED: Stick with Seattle resolution: making the default

  <jensimmons> we don’t have interop on https://jsfiddle.net/1fd948nz/1/
               at the moment, fyi
  <fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/saved/5143
  fantasai: We've got different behavior on different browsers

Rename `auto` to `legacy` for `justify-items`
  Github topic: https://github.com/w3c/csswg-drafts/issues/1318

  fantasai: Alignment spec has a bunch of keyword magic with
            justify-items. It sets default value of justify self for
            any children. We tried to figure out how to incorporate
            center tag and did it with a special set of keywords
            called legacy with an initial value of auto. All auto
            does is this magic, but we could just use legacy keyword
            by itself.
  fantasai: Proposal is rename auto to legacy so all it does is if
            you have legacy keyword on parent it pulls the parent
            alignment, else does normal thing.
  fantasai: Alternate is drop this thing.
  fantasai: We haven't gotten any significant comments. Apparently
            style stuff is implemented chrome. Not sure how people
            are impl center and align attributes in HTML.
  fantasai: If impl don't want to implement center and align
            attributes through this we should drop. If we want to
            keep it we recommend the rename.
  fantasai: Did that make sense or do we need more explanation?
  Rossen: Your explanation was great. In our impl we handle center a
          little magic. Rename would be okay. Trying to kill it
          would be better.
  Rossen: I'm in favor of mostly everything you proposed.

  fantasai: Reason to keep it would be if we want to standardize.
            Alternative would be add yet another property to control
  fantasai: We can't unimplement center tag.
  TabAtkins: Benefit of another alignment property is we can make it
             actually inherit. It might be better structurally.
  fantasai: But then you have a weird thing where you have to figure
            out, I inherited this, alignment is this, what wins?
  fantasai: We can't resolve with cascade.
  fantasai: Incorporating it has the benefit that the cascade is
  <dbaron> For what it's worth, I'd probably have an opinion on this
           if I had ten minutes to think about it...
  TabAtkins: There's definitely problems either way, I agree.
  fantasai: I'm happy to defer
  Rossen: Let's resolve on rename
  Rossen: Any objections on renaming auto to legacy?

  RESOLVED: Rename auto to legacy.

Alignment publication

  Rossen: Was that the only thing keeping us from CR on alignment?
  fantasai: Yes...I think we should add legacy to at-risk list. All
            the issues are closed. I would like to initiate
  Rossen: That would be great.
  fantasai: While we process that we can look at dropping. If it's
            at-risk we can drop later.

  dbaron: I'll try and start asking this for all CRs: Is there
          someone other then the editor that has read the draft and
          thinks it's ready?
  fantasai: We've had a lot of comments from Igalia & Matt. There
            have been detailed reviews of the draft. I think it has
            been impl...this was the reference spec of grid. I think
            it's gotten decent amount of review.
  dbaron: There's bunches not related to grid and I worry those
          aren't ready.
  fantasai: I think they're straight forward. We kept asking for
            review and no one has so TabAtkins and I have done two
            line by line reviews of the spec.
  fantasai: If someone wants to review the spec I'm happy to delay 2
            weeks, but if it'll be more no response and no review
            it's not useful.
  fantasai: I've been asking for review for years.
  dbaron: I submitted comments a year or two ago.
  dbaron: I would like the bar for CR to involve someone other then
          the editors say they think it's ready.
  fantasai: I totally agree with that.
  <astearns> we're meant to show wide review before CR
  <rachelandrew> Does this review need to be from an Implementor?
                 I've spent a lot of time reading it, I'd be happy
                 to do a more formal review.
  <astearns> rachelandrew: does not have to be from an implementor -
             your formal review would be great
  dbaron: I can probably look, but not this week.
  Rossen: I agree, dbaron. We can action the WG to review Alignment
          spec in the following two weeks. I also sympathize with
          fantasai saying she has asked for review. Let's use the
          resolution forcing function. Would you agree two weeks is
          enough before we call for resolution? Or three?
  dbaron: 2 is fine.

  Rossen: Proposal: Move CSS Alignment to CR with the added legacy
          value defined as at-risk. The action of starting the CR
          process will start in 2 weeks unless we heard elsewise.

  Florian: Have we asked for horizontal review? We could bundle the
  Rossen: Good idea. Let's see. Who do we need for horizontal
          review? a11y folks.
  ChrisL: i18n, privacy, security
  fantasai: I think for privacy & security we should send them a
            note saying we don't think there's anything that would
            effect you, but feel free to read the spec.
  Rossen: That's good.
  Florian: Is 2 weeks short for horizontal?
  ChrisL: It is. i18n wants 4 weeks.
  ChrisL: I think for specs we're prepping for CR we should in the
          future schedule earlier.
  fantasai: I don't think we'll get feedback on horizontal review.
            Maybe general this could be better written.
  fantasai: i18n wanted flow relative directions which is what we
            did. We have self-start vs start so there's all kinds
            of writing mode control. a11y issues are ones that
            effect everyone, e.g. if stuff overflows it could be bad.
  Rossen: I think we should stick to 2 weeks. If someone starts
          screaming we can be flexible.

  RESOLVED: Move CSS Alignment to CR with the added legacy value
            defined as at-risk. The action of starting the CR
            process will start in 2 weeks (May 27) unless we hear

  fantasai: Rossen can we have WD resolution?
  Rossen: Oh, yes.
  <fantasai> TabAtkins, would you mind adding the at-risk thing and
             pushing to /TR?

Question re white space processing rules for U+000D
  Github topic: https://github.com/w3c/csswg-drafts/issues/855

  Rossen: Is anyone prepared to talk on this?
  TabAtkins: I can do it based on thread.
  TabAtkins: According to the text spec a lone U+000D is the same as
             a proper line break.
  TabAtkins: Impl don't do that, they drop it from white space
  TabAtkins: There's a test case in the issue. It appears it's
             consistent. We should probably change spec to match

  Florian: To clarify, is that the one macs used to be used before
  TabAtkins: Someone used it at some point.
  fantasai: Yes.
  Florian: So it's not likely something on the rise, it's the other
           way around.
  myles: Matching implementation is good idea.
  dbaron: This is about carriage returns getting to the CSS level.
          Classic mac could have processed before.
  TabAtkins: I don't think HTML parser does magic.
  gsnedders: It replaces them with line feed (000A).
  <zcorpan> or textContent = "foo\rbar"
  <zcorpan> html parser normalizes
  TabAtkins: Nevermind. He's just using entities in test example.
  Florian: Then go for it.
  Florian: Make the suggested change to match impl.
  Rossen: Okay. Any objections to accepting the change?

  RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/855

Reconsider name of frames() timing function
  Github topic: https://github.com/w3c/csswg-drafts/issues/1301

  Rossen: Long issue, added by dbaron. Has some ML discussion.
  TabAtkins: I feel like github is having fruitful discussion

How does 'inherit' keyword behave in a child of ::first-line?
  Github issue: https://github.com/w3c/csswg-drafts/issues/1097

  fremy: There's a proposal that makes sense. On the properties that
         apply on ::first-line and inherit should inherit and not
         custom properties.
  fremy: I can explain the issue if someone needs.
  Rossen: Yes, please.
  fremy: The issue is a span is inside a div with ::first-line. If
         you set on the span color: inherit will do so from
         ::first-line. In webkit if you do this wrong it also
         appends. It seems like it's causing some problems.
  fremy: It furthers what happens with custom properties where if
         you do the inherit from the ::first-line it could become a
         block and then it's not part of first line. The prop is if
         custom properties & background do not inherit by the
         children of the ::first-line.
  fremy: If you spec a background inherits on the ::first-line it'll
         inherit from the div.
  <dbaron> Is the proposal written somewhere?

  Florian: At first it sounds reasonable, but I expect horrible,
           subtle things hiding somewhere.
  fremy: I think proposal makes sense.
  Florian: I think so too.
  fantasai: I agree with Florian. I don't have time to look right
            now. I would prefer a week to look.
  Rossen: We can push the resolution out a week. Let's look at this
  Rossen: Florian are you okay?
  Florian: Yeah.
  Rossen: fremy?
  fremy: Sure.

  dbaron: If we have a week, can there be a written version of the
          proposal? The issue is very long and I don't know what
          proposal we're looking at.
  Rossen: fremy let's have you summarize the proposal on the github

Allow percentages for `column-gap`
  Github topic: https://github.com/w3c/csswg-drafts/issues/1321

  Florian: We resolved 4 years ago to allow column-gap to take
           percentages. Given that it's now, is that L1 or L2?
  Rossen: Didn't we take the opposite for grid-gap?
  Florian: I don't remember.
  jensimmons: We resolved grid-gap to take percentages.
  Rossen: If we're in alignment there's no controversy. They should
          be aligned.
  Florian: Behavior is not unexpected. Question is where do we spec
  Florian: We'll have to redo L1 CR, but we could do it there. Not
           sure there's impl.
  Rossen: I would say add as at-risk and then pass it to L2. I'm
          fine with that. Just more process & editorial work. Other
          way is push to L2 now and if impl pick it up we can bring
          it back.
  fantasai: It's trivial to edit and to impl compared to making so
            other stuff in columns work. I think L1 and at-risk is
  Rossen: That's fine. Leave this in multi-col L1 and mark it as
  Florian: Put it in L1.

  RESOLVED: Add percentages for `column-gap` to L1 and mark as

  Rossen: That's the hour. Thanks everyone.
Received on Wednesday, 10 May 2017 20:33:01 UTC

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