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

[CSSWG] Minutes Telecon 2016-10-05 [css-overflow] [css-grid] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 5 Oct 2016 19:37:19 -0400
Message-ID: <CADhPm3u95z0_xB8eRsmv=EGgb8+8yXDEnw-EAVp3eqrGjs9ykQ@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.
=========================================


Consider support for overlay scrollbars
---------------------------------------

  - TabAtkins summarized his proposal for creating overflow-gap:
      auto | stable | always
  - Rossen asked if making these optional values for auto on the
      overflow property would make more sense as it would avoid
      creating another property.
      - This was considered and a few people originally expressed no
          preference, but the more it was discussed the more people
          felt this was the wrong approach.
  - There still wasn't agreement as to if this new property should
      be a longhand of the overflow: auto or if it should be
      completely separate.
  - RESOLVED: We will work on a solution to accommodate issue 92
              (https://github.com/w3c/csswg-drafts/issues/92)

Stretching image grid items in both dimensions
----------------------------------------------

  - RESOLVED: The normal value of align-self and justify-self
              preserves aspect of image but stretch causes it to
              stretch to fit containing block. Default value
              continues to be normal.

CSS Text DoC issues
-------------------

  - RESOLVED: Accept the proposal for issue 96 (for linebreak
              transformation rules ambiguous characters are narrow
              unless it's Chinese or Japanese or Yi in which case
              they are wide)
  - RESOLVED: Make tab size animatable
  - RESOLVED: Make tab size <<number>>
  - RESOLVED: Have tab-size account for letter spacing and word
              spacing
  - RESOLVED: No change to the spec for issue 110
  - RESOLVED: Capitalize only title cases lower case things, not
              upper case letters
  - RESOLVED: text-align-last: justify will compute to center for
              CJK

===== FULL MINUNTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Oct/0053.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Tony Graham
  Jihye Hong
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Vladimir Levantovsky
  Peter Linss
  Myles Maxfield
  Simon Pieters
  Anton Prowse
  Liam Quin
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

Regrets:
  Rachel Andrew
  Bert Bos
  Daniel Glazman
  Chris Lilley

  Rossen: Let's get going.
  Rossen: First topic is stretching image grid items in both
          dimensions.
  Rossen: There was chatter during TPAC and a bit more on the queue
          but this is flagged as agenda+.
  Rossen: So fantasai take it away.
  [fantasai isn't on]
  Rossen: Or is TabAtkins on?
  <TabAtkins> one sec
  [trying to find a topic with the right people on the phone]
  Rossen: Does anyone have a topic they can do without TabAtkins and/
          or fantasai?
  <astearns> testing?
  TabAtkins: I'm in now.
  Rossen: Can you do the grid topic or do we need to wait for
          fantasai?
  <Florian> This one: https://github.com/w3c/csswg-drafts/issues/523
  TabAtkins: [looks] I have not read up on this.
  <dbaron> I could probably speak a little about 523, but not
           comprehensively
  Rossen: Second items requires fantasai as well as koji and others.

Consider support for overlay scrollbars
=======================================

  <Florian> https://github.com/w3c/csswg-drafts/issues/92
  Florian: We had a fairly long conversation on this. TabAtkins you
           had the last proposal.
  TabAtkins: This was from a little while ago where we discussed
             having table scrollbars issue. Current proposal is
             overflow-gap using gap terminology from elsewhere with
             auto|stable|always
  TabAtkins: Auto is do what the browser currently does. Stable is
             always have a gap if you have potential scrollbars.
             Always is always have a gap.
  TabAtkins: I can go over reasoning if needed. So proposal is
             overflow-gap: auto|stable|always. This only has effect
             if you're in overflow: auto.
  Florian: Only problem left is fantasai didn't like calling it a
           gap, she wanted gutter. Else wise I like it.

  Rossen: I've been reading through this, did we consider having an
          optional value for overflow: auto? Seems to me having this
          property is overkill given that it only applies to
          overflow: auto
  Florian: We partly considered that, though not with the latest
           incarnation. It goes down to if they should cascade
           separately and you may want to have this on the entire
           page except for where you override it.
  Florian: If you do that it's good to have them separate.
  TabAtkins: Against that is if you always use this when activating
             auto you should pick the right value.
  Florian: Then you have to set it twice to deal with fallback.
  Rossen: Depends on the what defaults are.
  TabAtkins: Florian is dealing with fallback for non-supporting
             browsers and that's true.
  Florian: Yeah. I would prefer separate but I'm fine if we roll it
           in.
  TabAtkins: I'm fine with it being an extra value.

  Florian: overflow: auto and then overflow: auto|stable|always
  Florian: Auto is implied.
  TabAtkins: Stable is okay, I think we want a different name then
             always.
  Rossen: Auto always suggests scroll.
  TabAtkins: I'm happy to go with that and come up with a better
             name. The question is should I do this in an active
             draft? There was some interest in Chrome in doing this
             and removing some properties of overflow, but it
             requires stability.
  Florian: It should go in overflow level 4 if we have agreement.
  Rossen: I think we should start in level 4 and bikeshed in there.
          We can call for consensus now.

  Rossen: I see smfr on the queue.
  smfr: I think it's bizarre to tack this onto overflow. If I read
        overflow: auto always I wouldn't understand what it means.
  <jensimmons> I agree.
  TabAtkins: Always is no longer good, but stable suggests the
             meaning.
  smfr: Overflow is how the content behaves. I think a separate
        property would be so much clearer.
  smfr: I would prefer overflow-gutter.
  * fantasai agrees with smfr, this is confusing
  TabAtkins: If we make overflow a short hand we could say overflow
             auto stable and it would work correctly. I'm with
             Florian and don't care either way.

  Florian: I hadn't realized you meant as long hand.
  TabAtkins: If we add overflow-gap overflow needs to be a shorthand.
  * fantasai doesn't think overflow-gap and shorthanding makes that
             much sense
  <fantasai> having it cascade independently would make sense

  <Rossen> overflow-style
  <Rossen> overflow-style: stable | auto-hiding | gap
  <jensimmons> Yeah I'm not sure what overflow gap is either. So
               many times handling overflow doesn't involve
               scrollbars. Need a way to let people know, hey this
               is about scrollbars and gaps. And whatever.

  smfr: Another request we've had is hide scrollbars but allow user
        scrolling and we should allow extensibility to allow that
        also.
  TabAtkins: I talked about that separately, but I think we have
             room with overflow-gap. I'm not sure it would make
             sense there, but someone in overflow there's room to
             accommodate.

  fantasai: I think gap control should cascade independently of if
            something scrolls.
  TabAtkins: We aren't sure why you would want it to cascade
             separately. There's no reason to use overflow auto and
             depend on it being set to stable elsewhere.
  Florian: I kind of disagreed with that logic.

  Rossen: Sounds like there's a strong desire to have the property.
          We have a spec where we can put it and continue to argue
          or agree. So should we get an consensus on adopting this
          in overflow 4?
  Florian: We have consensus on the function, but we don't have it
           on if it's a separate property etc.
  fantasai: We shouldn't put it into the draft unless there's a
            concrete proposal.
  TabAtkins: The proposal as stands is in the issue.
  Florian: There's 3 proposals and they're different.
  <gregwhitworth> for the cascade scenario, it would be nice for use
                  cases that authors would want them to cascade
                  separately
  fantasai: If this is issue 92 the last comment is from me.
  Rossen: And that was about naming.
  Florian: We have 3 concrete proposals, not one.
  TabAtkins: Do we have consensus on having this ability so that we
             should pursue doing it?
  fantasai: We have consensus we want to solve the issue so it stays
            open and we try and discuss proposals. Last comment you
            have, TabAtkins, is adding overflow-gutter property. Now
            we're adding a value into overflow directly.
  TabAtkins: We can fill in that detail in writing. This came up
             before you joined the call.
  fantasai: If I'm the only one disagreeing go ahead, but I hear
            reservations from others.
  Rossen: That was about using it as a value, not a property.
  Rossen: That was provoked by me because I didn't see it and we had
          a brief conversation.
  Florian: And TabAtkins using overflow implied it's a long hand and
           I missed the nuance.
  <jensimmons> It sounds like some new ideas just came up, and
               further discussion in the issue is the next step. And
               that everyone want this feature. Just needs a bit
               more baking before getting put into the spec.
  Florian: Since there's no concrete proposal I don't know what we
           should put in the spec.
  TabAtkins: Let's resolve to add something with this pending
             agreement with how to do it. I want something on the
             record saying we want to do this.
  Florian: I'm in favor of saying we want to do this, not having
           something in the spec.
  Rossen: Objections to having us work on overflow [some name] to
          accommodate issue 92?

  RESOLVED: We will work on a solution to accommodate issue 92

Stretching image grid items in both dimensions
==============================================

  <Rossen> https://github.com/w3c/csswg-drafts/issues/523
  Rossen: There was a conversation during TPAC with Manuel and
          others. Can you take this one fantasai?
  fantasai: The issue was about preserving aspect ratio of grid
            items that have one. Current spec says squash the image
            if it's a fixed size grid block.
  fantasai: You can use object fit properties to contain it or you
            can change the width but the argument was we should
            preserve the aspect ratio by default. With object-fit
            you preserve and clip and if you use auto the image box
            has this gap and it becomes obvious.
  fantasai: We could change auto to cause it to shrink and preserve
            aspect ratio by default.
  fantasai: I don't have a strong opinion. I do think how object-fit
            works is super messed up.

  dbaron: I think Mats feels strongly squashing is wrong by default.
          Part of the problem is the initial value of object-fit
          doesn't work well for grid which stretches by default.
  dbaron: Given that the initial value is stretch, grid does this
          other sizing on top that makes the stretch happen in more
          cases. It feels object-fit is the wrong default for gird.
          If we do the other behavior object-fit becomes slightly
          less useful.
  fantasai: You can set width and height to 100% and it'll fill the
            cell.
  fantasai: It would be nice if alignment would work to control
            this, but they work on each axis independently. You can
            say I want to stretch or do intrinsic sizing in this
            axis. You can preserve axis ratio, but you may overflow
            if you don't know which is longer.
  TabAtkins: I think you're saying that preserving aspect ratio if
             you let it stretch and do object-fit: contain
  fantasai: But than you don't resize the borders. That's a problem
            with object in general.
  TabAtkins: It's a problem object doesn't solve, sure.

  <smfr> object-fit has only been applied to replaced elements so far
  <dbaron> smfr, this is about applying to replaced elements --
           images that are grid items

  Rossen: Is this something dbaron you're okay with? You expressed
          Mats has a strong preference.
  Rossen: Having a clear work around for this...
  fantasai: Another thing we can do to allow an easy switch is we
            have a normal value for alignment. For grid items it's
            equivalent to stretch. We could say normal does what
            Mats is proposing to make sure the image fits in the
            frame and stretch alters the aspect ratio. That gives us
            a switch for all common behaviors.
  dbaron: Seems like a nice idea to me. I'm curious what Mats thinks.
  jensimmons: Feels to me that stretch should stretch it and
              something else could be the default. Having stretch
              not stretch is disappointing. There's use cases to
              have the containing box be controlled by grid and
              having the crop to make it fit. Having that be the
              default is the awkward part.

  fantasai: Other thoughts on this or should we go with that?
  fantasai: Summary: The normal value of align-self and justify-self
            preserves aspect of image but stretch causes it to
            stretch to fit containing block. Default value continues
            to be normal.
  Rossen: Sounds reasonable.
  Rossen: Objections?
  <dbaron> This is proposing changing the grid rule in
           https://drafts.csswg.org/css-align/#distribution-grid
  <dbaron> ... so that it's a different default for (I guess)
           replaced elements

  RESOLVED: The normal value of align-self and justify-self
            preserves aspect of image but stretch causes it to
            stretch to fit containing block. Default value continues
            to be normal.

CSS Text DoC issues
===================

  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-96
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-102
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-108
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-110
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-111
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-114
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-123
  <Florian> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-122

Use language context for dropping spaces around A (issue 96)
------------------------------------------------------------

  fantasai: There is discussion about that the Chinese use same " as
            English therefore East Asian treats them as ambiguous.
  fantasai: We're using East Asian width to determine if align-break
            is just a space of if it disappears as in CJK languages.
  fantasai: There's rules that say if you're in CJK turn the line
            break into nothing. If you're non-CJK keep the space. We
            determine it by looking at East Asian width property of
            character before and after line break.
  fantasai: Issue that came up is can we make this context dependent
            so the " doesn't prevent the line break from collapse.
  fantasai: Proposal is use the content language if it is known. If
            it's unknown we treat them as narrow.
  fantasai: Is this okay for the set-up rule and, if yes, do we
            adopt?

  Florian: The alternative is be language dependent in the markup or
           context dependent in surrounding characters?
  fantasai: We're using context now and using wide vs narrow to make
            that distinction.
  Florian: If it's Kanji " Kanji you're wide?
  fantasai: Currently all ambiguous is narrow. If content language
            is East Asian treat ambiguous as wide is the proposal.
  Florian: That sounds fine.

  koji: I'm fine with language, I'm concerned with adjacent(?)
        character. We can only see the character next to.
  Florian: Adjacent doesn't sound like a good idea. Sorry for
           brining it up.
  fantasai: Characters immediately after the one that has the line
            break?
  Florian: That's what I thought of and I don't think it's a good
           idea.
  fantasai: I think there was easier a rule to walk if there's
            punctuation but we simplified to immediately adjacent.
  fantasai: This seemed a simpler solution.
  Florian: Yeah.

  <dbaron> Gecko has some language-dependence in justification code
           (currently conditioned on C or J but not K!) but I'm not
           sure about how far away the code for this is
  <dbaron> My suspicion is that the language dependence probably
           isn't a problem
  Florian: dbaron says in IRC yes to the on C and J but not K
  dbaron: fantasai asked about language dependence. I didn't follow
          what this is about. We have language dependence in code
          that classifies differently on CJ but not K. I think
          language dependence is probably okay. It's worth thinking
          if you mean CJK or just CJ.
  fantasai: It's Chinese and Japanese, but not K. K has spaces so we
            don't want to remove those.
  fantasai: This is in the white-space collapsing code.
  dbaron: It's hard to know for sure if something is implementable
          until you implement it, but barring that it sounds okay to
          me.

  fantasai: Okay, then I'd say this is a good proposal and we should
            accept.
  Rossen: Objections?

  RESOLVED: Accept the proposal for issue 96 (for linebreak
            transformation rules ambiguous characters are narrow
            unless it's Chinese or Japanese or Yi in which case they
            are wide)

Animating tab-size (issue 102)
------------------------------

  <fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-102
  fantasai: Animating tab size. dbaron pointed out it's not
            animatable. We need to change the integer to a number to
            make this possible. Is that okay and do we want it to be
            animatable?

  Rossen: Let's start with should it be animatable?
  myles: What's the use case?
  fantasai: I don't think there is one.
  TabAtkins: Consistent platform. You have a number and no reason
             you can't have something between the two. This would be
             another quirk you have to remember.
  myles: If we don't expect anyone to do this is there a point is
         spec?
  Florian: We have to go one way or another.
  myles: It is specced one way.
  TabAtkins: By default. Bikeshed by default says not animatable
             unless you spec it. Tab size does have a length. It's a
             weird inconsistency. Small tiny use case, but an
             inconsistency we don't need to have.

  Rossen: Sounds like TabAtkins proposes we make it animatable.
  * fantasai defers to dbaron on this
  <bradk> Animatable +1. Principal of least surprise.
  TabAtkins: fantasai proposed it and I support. I don't care if we
             change it to a number. That they're an integer isn't
             significant. But even if they're pure integers they'll
             be animatable.
  dbaron: I feel there is a real use case for number over integer.
          People would be surprised they can't do 2.5.

  Florian: I think we're splitting hairs here. Most likely you're
           doing this with monospace and you can use ch unit.
  fantasai: There is another issue that makes numbers different than
            ch in monospace.
  fantasai: This issue is coming up on the list.
  Florian: [dramatic oooh]
  fantasai: In which case this would be smoothing animatable.
  Florian: So if it accounts for letter spacing what would 2.5 mean
  fantasai: It would be space+letterspace+wordspacing and multiply.
  Florian: Not n-1 on spacing?
  fantasai: Nope.
  Florian: Then it's fine.
  TabAtkins: I don't know if I agree with that proposal, but it
             doesn't matter because it interpolates fine.

  Rossen: Let's call for consensus. Objections to making tab size
          animatable? Objections to be being a number?

  RESOLVED: Make tab size animatable
  RESOLVED: Make tab size <<number>>

tab-stop should handle word/letter-spacing (issue 114)
------------------------------------------------------

  Florian: Letter yes, word I'm not sure.
  fantasai: Word increases size of space. Every space character
            would get increased.
  TabAtkins: Does this have an analog in other environments with
             tabs?
  fantasai: I don't think so? Maybe word processors?
  TabAtkins: The important point is if you have a monospace fonts
             and tab size is 8 with this change is it lining up to 8
             monospace characters?
  fantasai: Yes.
  Florian: I'm confused on how we space words, but given that it
           works this way that's okay.
  Rossen: Is this Issue #114?
  fantasai: Yes.
  Rossen: Objections to have tab-size account for letter spacing and
          word spacing?

  RESOLVED: have tab-size account for letter spacing and word spacing

  * dbaron notes issue 113 is an issue in a feature that's in CSS1

Capitalizing enclosed alphanumerics (issue #110)
------------------------------------------------

  fantasai: There was an issue as to if alphanumeric characters with
            a circle should be capitalized. They're symbols in
            unicode and the case transforms are only for letters.
            Jonathan Kew and someone had an argument to have it
            stay. There was another to say change.
  <tantek> link to email thread?
  <gregwhitworth> I think it's this one:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0144.html
  fantasai: My recommendation from all the comments is we should
            leave the spec as-is and not case transform symbols.
  Rossen: I think your last e-mail was we should go with whatever
          unicode case mapping is defined and have CSS match that.
  fantasai: Yes. I concluded we should keep the spec what it is. We
            say which set of characters are effected by case mapping.
  fantasai: So this is a similar restriction where case mapping is
            only letter characters and not symbols characters.
  Florian: I would tend to agree based on if we add custom text
           transforms it will be easier to create a new one that
           does general capitalization plus that then make one to
           remove it.
  <tantek> I think that's wise

  Rossen: Let's see if we can conclude to leave spec unchanged.
  Rossen: Objections?

  RESOLVED: No change to the spec for issue 110

Titlecasing digraphs (issue #111)
---------------------------------

  <dbaron> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-111
  <gregwhitworth> Email thread:
https://lists.w3.org/Archives/Public/www-style/2015Mar/0242.html
  fantasai: There is a difference in unicode between capitalizing
            and titlecasing. Most letters it's the same, but in a
            digraph the titlecase capitalizes the first but not
            second letter. Issue was we shouldn't take that and put
            it in title case if it's already in upper case.
  fantasai: You would get an odd effect where if you title case the
            first letter you have a lower case letter in the middle
            somewhere for no reason. I agree with that.
  Rossen: Is this an addition?
  fantasai: Yes.
  Florian: Where we go from fully lower case digraph for fully upper
           seems non-controversial.
  fantasai: Text transform uses language dependency.
  Florian: That makes sense.
  fantasai: If it's not in unicode case mapping file we don't try
            and fix it.
  <dbaron> IJ, ij, etc.
  fantasai: Otherwise Turkish i wouldn't work.
  Florian: Give that's covered, I agree
  fantasai: Capitalize only title cases lower case things, not upper
            case letter.

  RESOLVED: Capitalize only title cases lower case things, not upper
            case letters

  <TabAtkins> Reviewing the effects of spacing on a <pre>, yeah, I
              def agree with the resolution from before - literal
              spaces definitely take letter-spacing and word-spacing
              into account. I can't tell off-hand whether it's
              literally (space width + letter-spacing +
              word-spacing) * spaces, or if there's a -1 in there
              somewhere, but it looks about right.

Fallback alignment for justified text
-------------------------------------

  <dbaron> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-117
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2014Oct/0395.html
  fantasai: There is several possibilities for when you justify text
            and try and space it out to align on both edges. Issue
            is what do you do if you have no place to insert a
            space. We have text-align-last property that says what
            the last line does. There's a justify value. So when you
            can't justify a line in the middle of the paragraph we
            say do whatever text-align-last is.
  fantasai: If it's justify we don't know what to do. We need
            another fallback. I propose to just use centering. Use
            cases with text-align-last is justify is where they want
            centering as the fallback. Classic use case if the dish
            name is the column and it's 1-7 characters. If last line
            is 1 character is should center.
  fantasai: Since there doesn't seem to be a strong case to have the
            last line fallback to anything other than centering, I'm
            proposing we make it center all the time if you're not
            caught by text-align-last.

  Florian: When do we do something other than center?
  fantasai: You can't justify text in most languages, you just fall
            back to start alignment. Those cases are covered by when
            you have text-align-last to start.
  Rossen: You're argument is for text-align-last it should be always
          center.
  fantasai: The initial value is start. If you have set
            text-align-last to justify, the fallback is center.
  Rossen: I'm not 100% sure.
  Florian: I concur on the CJK use case. I don't know the other
           languages.
  Rossen: If you have only one word start makes most sense in
          non-CJK.
  fantasai: But for that you wouldn't have set text-align-last
  koji: I agree with fantasai. text-align-last is set in most CJK
        use cases.
  Rossen: Objections?

  RESOLVED: text-align-last: justify will compute to center for CJK.

  Rossen: That's the hour. Thanks to everyone. We made good progress
          on text.
Received on Wednesday, 5 October 2016 23:38:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 October 2016 23:38:20 UTC