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

[CSSWG] Minutes Telecon 2017-06-21 [css-ui-4] [css-text-3] [css-multicol] [css-grid] [css-flexbox]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 21 Jun 2017 20:32:11 -0400
Message-ID: <CADhPm3udvDmjibyJtZRDKEPmD9+PQvp5TioOCxDBiYf1BziDvA@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
--------

  - The open Values & Units topics will be prepared for discussion
      next week.

Make selection change behavior configurable
-------------------------------------------

  - There were three proposed options:
      1) no change
      2) change from current and make it so clicking in
         user-select:none undoes current section
      3) have two values, one for each behavior
  - RESOLVED: option 1: no change and add perhaps a non-normative
              note explaining adding this on the root isn't a great
              pattern

word-break: break-all doesn't break before sentence-ending punctuation
    if UAX #14 is used
----------------------------------------------------------------------

  - RESOLVED: line-break: break-all on its own has the effect of
              allowing breaks everywhere.
  - This change will be put in L3 of CSS Text.

Clipping of content that overflows a column
-------------------------------------------

  - RESOLVED: Columns do not clip by default

Clarify that column-* properties only apply to block containers
---------------------------------------------------------------

  - RESOLVED: Columns are properties applied to block containers
              only.

Alias "nowrap" as "no-wrap"
---------------------------

  - Those arguing in favor of the alias did so for author usability.
  - However, the argument against the alias is that it adds weight
      to the API and sets a precedent for doing this again in the
      future.
  - The two sides couldn't agree within the time of the call so the
      topic was deferred back to github.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0023.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Dael Jackson
  Brad Kemper
  Tomoya Kimura
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Greg Whitworth

Regrets:
  Bert Bos
  Tantek Çelik
  Daniel Glazman
  Tony Graham
  Vlad Levantovsky
  Simon Pieters
  François Remy

Scribe: dael

  Rossen: Let's get going.
  Rossen: Hello again. As usual, wanted to check if there are last
          minute items people want to add to the agenda today
  fantasai: We could add bikeshedding outset properties, but that's
            only if we run out of topics.
  fantasai: top/left/bottom/right shorthands.
  Rossen: Yes, we'll do it if time permits.

Spec Rec
--------

  Rossen: I only saw gregwhitworth reply. There were a few progress
          changes around fonts and variables. Seemed like writing
          modes was close. Are we ready with transition fantasai?
  fantasai: There were substantive changes to the spec. I can't
            recall if it needs CR.
  Rossen: Is this on you or Chris?
  fantasai: I need to know if we're publishing CR or PR before I
            give it to Chris.
  Rossen: And I don't see Chris on the call. I'll ping him.

  Rossen: Values & units, is it ready?
  fantasai: I think changes section isn't compiled.
  fantasai: I did find discrepancies between L3 and L4. There's also
            open issues in the DoC.
  <fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2016
  fantasai: I updated with resolutions yesterday. Issue 4 requires
            edits and is still open.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/708#issuecomment-302240095
  fantasai: Issue 13 ^ is still open b/c there are comments from
            Patrick.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/708#issuecomment-303786908
  fantasai: And the one after it ^
  Rossen: Do any of those needs to be on the call agenda?
  fantasai: I suggest for next week. I'll prep a list

  <Florian> Also waiting for CR publication of css-contain. It's on
            Chris / Ralph's desks

  Rossen: Okay, and last is UI. It was pending some test reviews I
          think on fantasai
  fantasai: I need to do that. Florian promised to pester me today
  * Florian pesters
  Rossen: Thank you.

Make selection change behavior configurable
-------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1317

  Florian: user-select: none makes it impossible to select things.
           But also if something is selected somewhere else in the
           doc and you click in a user-select: none area the spec
           says this should not effect existing selection.
  Florian: I believe we picked this because in native UI there are
           often places that are inert. However, someone has said
           they sometimes want the other way around where if you
           click in a user-select: none area it should unselect.
  Florian: Example for that I think was a FB page with posts. Post
           content is selectable, but if you click in the empty
           areas, like the margin around the post, people expect
           that to undo the selection
  Florian: My original reaction was then don't use user-select: none
           However people that do app-like things do
           user-select:none on the root and make some small area
           selectable.
  Florian: Maybe they shouldn't be doing that, but maybe there is a
           need. We should either flip the behavior or create the
           ability to do the two behaviors. What do people think?
  fantasai: I don't think flipping makes sense. It seems there are
            two behaviors wanted here.
  Florian: I think I agree flipping wouldn't be good. I'm less sure
           if we want 2 values or we recommend people don't do
           user-select:none on the root and instead selectively
           apply it.

  Rossen: Have we circled back with the editing group and asked if
          they have any best practices for such scenarios?
  Florian: We have not but could.
  Rossen: I think they have reviewed these kinds of patterns. I
          don't think we should re-invent the wheel here. If they
          have a recommendation we should match.
  Florian: I think it's fair to ask. I'm not sure we'll get an
           answer as the editing TF is focused on content:editable
           and that isn't primarily about selection. This is also
           used in non-editing places.
  Rossen: I don't disagree, but since editing is their charter I
          would expect most people would be expert in editing
          behaviors and use cases so they may have a recommendation.
          If they don't we're at square one.
  Florian: Even if they do, this isn't about just editing so we may
           not want to just take it. We need to think about
           non-editing use cases. That's the majority of the use
           cases. This is about making tool bars and labels
           non-selectable so when people select something to copy/
           paste they don't get UI as well.
  Florian: It does interact with editing, but it's not limited to
           that.

  Rossen: What are the options on the table?
  Florian: 1) no change
           2) change from current and make it so clicking in
              user-select:none undoes current section
           3) have two values, one for each behavior.
  Florian: Together with option 1 it comes with add a note about
           setting user-select:none on the root having undesirable
           behavior.
  Rossen: What do people think? Can we live with #1?
  bdc: From a designer perspective I feel this is a very minor issue
       I've never seen before. I feel we have everything in place to
       leave as-is. I would personally go with option 1.
  Rossen: Thanks.
  Rossen: Other opinions or should we resolve?
  Rossen: Objections to option 1: no change and add a non-normative
          note explaining adding this on the root isn't a great
          pattern

  RESOLVED: Option 1: no change and add perhaps a non-normative note
            explaining adding this on the root isn't a great pattern.

word-break: break-all doesn't break before sentence-ending punctuation
    if UAX #14 is used
----------------------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1171

  Florian: Title is a bit old. Now, at the last F2F we agreed to add
           a break-all value to line-break that might, in isolation
           allow breaks anywhere and everywhere. We did not decide
           if this should work on its own or if putting it on
           line-break should only effect punctuation.
  Florian: We said impl would prefer it work on its own and it
           appeared unlikely there were use cases to have breaks
           around punctuation but not inside words, but we weren't
           sure.
  Florian: I tried to ping i18n but there has been no answer.
  fantasai: I asked on one of the telecons, they said they had not
            heard of a use case.
  Florian: So we should have line-break: break-all have effects on
           its own.
  fantasai: I agree.
  Rossen: In the absence of other recommendations from i18n or any
          other proposals, do we resolve?
  fantasai: I think we can.
  Rossen: Any other opinions or options before we resolve?

  Florian: Proposal: Line-break: break-all on its own has the effect
           of allowing breaks everywhere
  Rossen: Objections?

  RESOLVED: line-break: break-all on its own has the effect of
            allowing breaks everywhere.

  * fantasai thinks we need a shorthand for line-break and
             word-break so that we can have some kind of sensible
             interface to all of this nonsense
  <Florian> +1 to fantasai

  Rossen: Is this a change to the current spec?
  Florian: Yes, we're adding this new value.
  Rossen: And this is L3 or 4 of text?
  Florian: I've made a pull for L3 but I'm not sure we resolved
           either way.
  Rossen: fantasai, do you have a preference?
  fantasai: I don't. I think the feature is so simple it could be in
            3.
  fantasai: We can mark at-risk.
  Rossen: Okay.
  Rossen: We'll add it to L3.

Clipping of content that overflows a column
-------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/314

  Florian: The TR version of multicol and the ED are contradicting.
  Florian: Browsers aren't interop.
  Florian: If something overflows from a column should it be visibly
           overflowing or clipped when the line is in the middle of
           the two columns.
  Rossen: Do you mean overflow in the inline direction in a column,
          block, both?
  Florian: That's the other part. Specs are vague and they don't
           define all cases. The case I'm interested in is not the
           kind that triggers fragmentation. I'm interested in any
           other kind of overflow.
  Florian: Both versions contradict. TR says clip, ED says overflow.
           Both use wording that means you do that in some cases,
           but don't say what to do in other cases.
  Florian: I think we should not clip and overflow for everything
           for 3 reasons. First, there are use cases for positioned
           content to overflow. 2 is that lists, numbered or
           bullet...because the default HTML styling have the
           bullets overflow by default because it's padding on the
           <ul> in the stylesheet. That means bullet stick out and
           that's bad.
  Florian: If we're doing it for this we should be consistent and
           not invent a new behavior to let some things overflow and
           some clip.
  Florian: That's bad, especially if one day we have a selector to
           select column boxes.
  <bradk> +1 on those examples

  <rachelandrew> I think currently firefox overflows, Chrome clips
  <rachelandrew> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110
  Rossen: Speaking of our impl, the columns themselves do not clip
          and the multicol box wrapping around all the columns may
          or may not clip depending on the overflow prop. You're not
          clip in either horizontal or vertical. I don't have bugs
          suggesting we change this. So I would be in support of
          your proposal.
  Florian: Current spec says not to clip in some cases, but doesn't
           define other cases. The behavior you describe agrees with
           FF, but not Chrome. I think Safari is with Chrome.

  gregwhitworth: Is there a test case? I'm looking at bugzilla and
                 all browsers have overflow.
  Florian: 5 minutes ago I made a test case and I lost it, but with
           a float with a margin that makes it stick out and Chrome
           clips that.
  Rossen: That's why I was asking about inline or block. Block
          direction has very specific rules in fragmentation and
          when we have monolithic boxes that don't fragment multicol
          lets you create net column. If your column count is fixed
          you may overflow in the box direction eventually and that
          should be controlled by overflow property.
  fantasai: Even if you have fix column count you can overflow by
            creating more columns.
  Rossen: You're correct.
  Rossen: You can always have an item that overflow the height.

  fantasai: We're talking about an item that overflows the column
            box itself. Overflow in block we're clear it's visible.
            Overflow in the inline you have a box in the first
            column and it'll overflow, will it overlap content in
            the second column?
  Florian: That's the core. Slightly broader do we want to
           distinguish between types of content that might overflow
           or do we want one answer for all the things?
  fantasai: I'm guessing one answer is easier to impl.
  Florian: Yes, and that's not what the spec says
  fantasai: Also, abspos elements is a different question as it's
            not in the column.
  Florian: It depends on the containing block.
  fantasai: Right, they would be clipped by containing block, not
            the column necessarily. So the abspos case splits into
            two sub-cases.
  Florian: I think I would like nothing gets clipped and if people
           come up with use cases to clip we'll add a selector for
           column boxes and they can use overflow on that.

  <Rossen> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110
  Rossen: To be on the same page, rachelandrew pasted a codepen^
  Rossen: I want to make sure this is the test case we're talking
          about. There's an image in the middle which is too wide.
          Question is does it clip.
  Florian: That's one of the cases.
  Rossen: What is see is that all browsers but FF clip.
  Rossen: This is most likely a change in our behavior that was made
          for interop purposes.
  <fantasai> Rossen, the original spec called for clipping iirc,
             that's why multiple browsers clip
  Rossen: If we agree to not clip it means we'll have to change all
          but one implementation. We have to be mindful of the
          effect of the overall web compat.
  Florian: I thought you said Edge doesn't clip.
  Rossen: We didn't used to. At some point we must have changed for
          interop.
  fantasai: Or it could have been for spec compliance. It did say to
            clip.
  Rossen: What I wanted to point out is if we change the spec it
          means changes to webkit, blink, and edge. I'm not sure
          what that would mean for web compat.

  Florian: Another argument for that is multicol has been more
           successful in printed media and prince does overflow.
  Rossen: That could be, though I've seen epub readers use multicol
          for pagination. Those might suffer.
  Florian: Then again, these do not want to have the selective
           clipping and overflow, they likely want always clipping
           which is not what we have today.
  Rossen: It might suggest this is either an optional value to
          multicol where you can say clip or not and then put the
          behavior in the author hands and then we decide what the
          default is.
  Florian: If we want to put it in author hands...
  dbaron: It seems like the overflow is the easy way to make it
          author controlled.
  Rossen: dbaron did you mean overflow of multicol or have it apply
          to a selector.
  dbaron: Probably some sort of pseudo element. Problem is overflow
          defaults to visible and it's weird to have one thing
          default to clipping.
  Florian: I think visible is a good default. For regular multicol
           there's no clear reason why clipping would be a good
           default and turning list into multicol isn't crazy.
  Rossen: If you put together market share I'd say a majority of
          content does clipping.
  Florian: You can cope with it, doesn't make it good.
  Rossen: It's what's expected on the web.
  Florian: Except for people in print and people using FF.
  dbaron: I also haven't seen this as a compat issue for us.

  gregwhitworth: [missed]
  dbaron: I don't remember seeing it
  Florian: I don't think it would be mobile browsers, I think it
           would be apps that use browser as the run time.
  <fantasai> Those would be easier to handle, since when they pull a
             new copy of the engine they can make the adjustment via
             ::column { overflow: hidden; }
  Rossen: That's what I was referring to. I've seen multiple touch
          webapps that do provide epub experience based on multicol.
  Florian: I think that's how ibook works.
  Florian: I'd like to go visible by default and have a column
           selector that could take overflow.
  Florian: Current behavior isn't clip by default. It's clip by
            default except something and that's not great.

  <dbaron> do Chromium, WebKit, and Edge all clip columns in both
           dimensions?

  Rossen: What is not clipped? I couldn't find anything.
  Florian: abspos and the like?
  Rossen: You cannot make a column be a containing block
  fantasai: You can make an element in the column.
  Rossen: In which case the element itself is clipped.
  fantasai: Box can overflow the element.
  Rossen: If you have a non-breaking word that expands past the
          column it's clipped anywhere except FF
  <Rossen> https://bug1282363.bmoattachments.org/attachment.cgi?id=8765359
  Florian: And floats with negative are clipped. I haven't tested
           transformed content. Maybe everything is clipped, I
           haven't tested all variants.
  Rossen: Going through the test case what you're desc for abspos is
          clipped in FF.

  Florian: If we can prove there's no compat problem, would we agree
           visible by default is a better behavior or not?
  Rossen: I cannot speak on better or not.
  Rossen: It's preferential.
  fantasai: It's more expected since that's what we do everywhere
            else.
  <bradk> Overflow should be visible
  * dauwhe ran Rachel's codepen through Prince. Photo overflows
           column all the way to the page edge

  Rossen: I'd like to hear from blink or webkit if they're willing
          to change.
  myles: I'm not prepared to comment.
  TabAtkins: I dunno.
  <rachelandrew> I don't have a strong opinion, not sure many
                 authors are using this (on the web)

  Rossen: I think the overall behavior proposed change is well
          understood. Let's try to close and see how to move
          forward. Florian's proposal is to change the behavior and
          define that overflow of items inside columns of multicol
          are not clipped. And if we add a column selector with
          overflow is a separate topic.
  Rossen: In the absence of the column selector, are there
          objections to changing the behavior of items being clipped
          to not clipped.
  <fantasai> is in favor
  <bradk> +1
  * Florian is in favor
  Rossen: objections?

  RESOLVED: Columns do not clip by default

  Rossen: If there are use cases for clip we'll decide if we need
          the selector
  <fantasai> It's possible to workaround the lack of clipping on
             columns by wrapping the columns entire contents in a
             block with overflow: hidden. This also addresses the
             weirdness of the clipping boundary being in the middle
             of the gap instead of at the near edge.

Clarify that column-* properties only apply to block containers
---------------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1364

  Florian: This is not a hard change for the spec. If there's
           agreement I'll do it.
  Florian: There is behavior agreement, it's a question as to if we
           should update multicol to say it or are we happy with
           where it's defined.
  Rossen: Opinions?
  Rossen: Proposed: leave it where it is, don't change.

  fantasai: It's an error in the spec and needs to be changed. We
            need an exception for tables where they don't apply to
            tables or table wrapper box. That should be called out.
  <dbaron> yeah, seems better for the multicol spec to just say the
           right thing
  fantasai: For sure block containers. The list is really specific
            and not quite correct
  <gregwhitworth> not tables
  Rossen: You propose to change to it applies to only block
          containers?
  fantasai: Yeah. Block containers is well defined.
  fantasai: They weren't when the spec was originally written.
  Rossen: Reasonable. Other opinions?

  Rossen: Proposal: COlumns are properties applied to block
          containers only
  Rossen: Objections?

  RESOLVED: Columns are properties applied to block containers only.

Alias "nowrap" as "no-wrap"
---------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1537

  Rossen: shane added this
  TabAtkins: I can explain
  TabAtkins: Deal is a while ago we discussed...we agree nowrap was
             a legacy mistake. It was a legacy issue. There was
             discussion as to if we should try and fix it and add an
             alias of no-wrap where nowrap is accepted.
  TabAtkins: zcorpan brought up counter argument that they'll have
             to recognize no space as they'll have to return it in
             cssom. Is it worth it to add the alias?
  TabAtkins: My position is same as Naina where I do see people
             making this mistake still. I've never been happy with
             the no dash version and I still have to fix it when I'm
             using the property. I think it's good to add the alias
             and in the future just use the dashed one.

  Rossen: What's the default and how does this roundtrip? Do we need
          to have enough state inside to know which was cascaded as?
  TabAtkins: I don't have a strong opinion. It is lower cost to map
             the dashed version to the no dash. You don't need
             anything new in the data structure. It's probably
             better for authors to maintain them separately.
  TabAtkins: I would slightly prefer them as distinct values in the
             OM, but I'm not hugely opposed.
  dbaron: I'd prefer not to have multiple different mechanisms for
          value aliasing and I think we have the parse time one.
  Rossen: I'm on the same page. As a first step I'd be okay with
          parse-only aliasing. Next would make it mess, but we could
          do it if we have to.
  TabAtkins: I don't remember any other value time aliases. In the
             property spec it doesn't matter which way, they'll get
             it back. Values don't have that affordance.
  Rossen: We have some mostly around legacy webkit values from what
          I recall. Again, the feedback is it's a pain, but possible.

  Rossen: If we can do parse only aliasing we would be happy. If you
          say this makes author life easier that's fine. Supporting
          the round tripping...ehhhh...if we have to.
  Florian: It's not hard to impl.
  Rossen: But cascade is tricky
  dbaron: You have to decide if they're different as computed.
  Rossen: And if they are different when you have to roundtrip it
          becomes messy if they're variables involved
  TabAtkins: It's just adding a new value. We take nowrap definition
             and copy/paste it to no-wrap.

  myles: That's my primary concern. If there's no actually
         difference it's only increasing the API surface.
  Florian: It doesn't have behavior benefits, but typo benefits.
  TabAtkins: I suspect a lot of authors mistype this. I do. Platform
             comprehensibility is important and making this one
             weird exception work is not 0 benefit.
  myles: I don't think adding a new alias value is worth the API
         cost.
  <dbaron> So in Gecko we have parse-time aliasing for
           overflow:hidden/-moz-scrollbars-none,
           user-select:none/-moz-none,
           writing-mode:horizontal-tb/lr/rl/lr-tb/rl-tb,
           writing-mode: vertical-rl/tb/tb-rl, and probably some
           others since this was from visually scanning a list of
           tables

  Rossen: We have 3 possible scenarios.
          1) no change at all, don't add dash.
          2) add dash as parse aliasing.
          3) add dash version as a recognized new value that behaves
             same as no dash.
  Rossen: What do people prefer?
  <bradk> Treat it like a prefixed value?
  myles: I prefer 1 because setting up the pure alias that isn't
         about prefix sets a precedent. We don't want the to keep
         occurring.
  TabAtkins: This is fixing a legacy mistake so I don't think this
             establishes a strong precedent.
  Florian: I think we'll ask about currentcolor but that's where it
           will stop.
  myles: That we know about now.
  TabAtkins: Worse case scenario is if we import more SVG
  <fantasai> https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode
  dbaron: I scanned the keyword tables in gecko I found two parse
          time for moz prefix and one for standard that's writing
          mode. So existing case for parse time is from writing
          modes.

  myles: Why don't we continue this next week since it's after time?
  Rossen: We can try and resolve on #1. TabAtkins would you object
          to resolve on no change?
  TabAtkins: I wouldn't be the happiest. I wouldn't want to throw
             this out because it's late.
  Rossen: In that case let's go back to gihub. We can try and
          resolve this next week and it'll let Naina weigh in.
  * astearns notes that Naina wanted to be on the call for this
             discussion
  <fantasai> defers to dbaron on this issue, fwiw
  <dbaron> I don't have strong feelings about 1 vs. 2
  <dbaron> I just prefer not to do 3.
  Rossen: We'll continue next week. Thank you everyone, talk to you
          next week.
Received on Thursday, 22 June 2017 00:33:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 22 June 2017 00:33:17 UTC