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

[CSSWG] Minutes Telecon 2015-10-07 [css-2015] [css-text] [cssom-view] [css-writing-modes] [css-logical-properties] [css-grid] [css-flexbox] [css-break]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 8 Oct 2015 07:32:42 -0400
Message-ID: <CADhPm3sHZFB0j1tuN-Rc8OEDCYiKvOhw2WRt54yPoUYZNraFwg@mail.gmail.com>
To: www-style@w3.org
TPAC
----

  - Everyone was reminded to add items to the wiki for TPAC
      conversation.
  - The Houdini task force will meet on the Thursday of TPAC. They
      may also hold a breakout session on the plenary day depending
      on if there are proposals for specific topics and/or meet on
      Friday if they need more time.

Snapshot
--------

  - RESOLVED: Adopt Section 3 of the Snapshot.
  - RESOLVED: Publish Snapshot.

white-space:pre-wrap and pre-wrap-auto
--------------------------------------

  - Florian and fantasai agreed that the spec should say something
      along the lines of the UA must provide a smart behavior and
      should match platform with 'be smart' defined as 'provide a
      good experience'. They will work on solidifying the wording.
  - RESOLVED: In pre-wrap, disallow wrapping before the first space.

Behavior of scrollLeft in RTL or vertical-rl mode
-------------------------------------------------

  - The right people weren't on the call for a resolution, but
      webkit plans to change to be more consistent with the proposal.

The 'inline-{start,end}' values for 'float' and 'clear'
-------------------------------------------------------

  - This issue needs a consistent decision between all 2d
      positioning, not just for floats. It was added to the TPAC
      agenda.

Default Alignment of Grid Tracks
--------------------------------

  - There was a strong feeling from Rossen that there wasn't a need
      to make Grid and Flexbox consistent in their 'auto' value for
      alignment.
  - The spec will be left as-is for now and fantasai will look for
      more feedback, especially from authors.

Fragmentation Issues
--------------------

  - RESOLVED: Issue #19 is out of scope.
  - RESOLVED: Take Roc's suggested wording about keeping inline
              blocks non-fragmented (Issue #21)
  - RESOLVED: Each fragmentainer must contain at least some content
              or fragment of content.
  - Issue #24, adding 'force' to the page, column, and region
      keywords, still needs to be discussed either on a call or at
      TPAC.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2015Oct/0062.html

Present:
  Rossen Atanassov
  Tab Atkins (IRC only)
  David Baron
  Bert Bos
  Bo Campbell
  Tantek Çelik
  Alex Critchfield
  Greg Davis
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Edward O'Connor
  Anton Prowse (IRC Only)
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Johannes Wilm
  Greg Whitworth

Regrets:
  Adenilson Cavalcanti
  Dave Cramer
  Simon Pieters
  Lea Verou

  scribe: dael

TPAC
----

  glazou: Let's get started.
  glazou: Before extra items, let me remind you we have to collect
          items for TPAC discussion.
  glazou: If you haven't registered for TPAC you should do it today
          because the fee doubles tomorrow morning.
  glazou: That said, I think there is at least one agenda extra item
          from Bert about Houdini. Anything else?

  glazou: So Bert you asked about the Houdini meeting?
  Bert: I was asked if we still needed a room. I remember there was
        a doodle, but I don't know the conclusion.
  Rossen: Let's look. There were a couple of efforts started to get
          more data. One was I asked people to sign up on the
          Houdini wiki.
  Rossen: There was not too much sign-up there. I guess the doodle
          was created which got more people to post. Based on the
          doodle we can take time off of plenary. Or Thursday or
          Friday are good days.
  * glazou leaves on friday and will not be available thursday
           afternoon, would prefer thu morning

  Rossen: Back to if we should meet, we've agreed to meet. It's a
          question of do we do it Thursday, or Friday. Or play hooky
          on plenary day.

  Rossen: I didn't see anyone sign up from Apple though they brought
          up the conversation.
  hober: I'll bug dino.
  Rossen: Do you know if he has a preference?
  hober: I don't know.
  Rossen: But someone from Apple will be there?
  hober: Yes.

  Rossen: Based on the doodle Wednesday works for most except dbaron.
          Friday morning is good for everyone.
  glazou: I plan to attend Houdini, but I'm leaving Friday and the
          plenary day isn't good. I'd prefer Thursday morning.
  Rossen: It's an option. There are 3 people conflicting with
          Thursday. dbaron, Florian, and dauwhe. They're not
          opposed, they're listed as 'if needed'. If we say it is
          needed then let's shoot for that. Reserve the room on
          Thursday and go from there.

  Florian: So plenary didn't work out?
  Rossen: For plenary day...I would be in favor of it if we need it,
          but I would like to poke into different meetings that day.
  astearns: I think having a specific topic for Houdini on plenary
            would make sense.
  Rossen: Or make it a Houdini awareness topic.
  Rossen: Or is that what you meant?
  astearns: Instead of a general 'this is Houdini' or 'let's discuss
            topics', I think it makes sense to have it be specific
            like CSSOM or Box Model so people can decide to go.
  Rossen: Okay. Let's book a room for Thursday. If someone puts a
          specific topic forward for Wednesday let's also book
          something for during the day Wednesday.
  Rossen: That way we'll narrow down the people interested in that
          specific topic. So if, for ex. we do CSSOM people not
          interested can join other meetings. We'll have the
          standard with everyone Thursday. How does that sound?
  Florian: Worth a shot.
  Rossen: Okay, let's have that. I'll update the Houdini mailing
          list and we'll go from there.

  Bert: I'll take care of the Thursday. Someone else want to take
        care of Wednesday?
  Rossen: If we can get a room for the whole day on Thursday that
          would be best. I'm not sure if we'll spill to Friday. If
          we do we'll play by ear.
  Rossen: Definitely having one room for Thursday is great.
  Florian: And Wednesday can be done last minute. We don't have to
           write it in advance.
  glazou: We always spend 30 minutes writing topics on the wall.
  Rossen: So we'll leave Wednesday to be spur of the moment. All of
          Houdini will meet Thursday. Same goes for Friday, if
          people are around and we need to discuss we will.

Snapshot
--------

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0000.html
  glazou: TabAtkins said it's been a month since the mostly final
          wording and all requests for additional clarification have
          been made. fantasai, is there a specific request to
          publish or...?
  Florian: We were waiting on Apple and Microsoft. They tentatively
           agreed but wanted to check with a team.
  gregwhitworth: We're good with it.
  hober: I don't think we have additional feedback.
  hober: I don't think we have consensus internally, but it
         shouldn't hold anything up.
  Florian: Meaning whoever is disagreeing will be made to agree?
  hober: I didn't say it, but it sounds good :D
  glazou: Let's suppose we have consensus on the doc.

  fantasai: So here's what we've got...what we plan to do is if we
            have a resolution to accept section 3, that's the main
            thing holding up publication. That's part of the boiler
            plate added to every spec. Once we have a resolution
            we'll update bikeshed. We'd like to publish the snapshot
            itself.
  fantasai: We'll update the snapshot again this year because we
            don't have the table of properties.
  fantasai: We need resolution to adopt section 3 of the snapshot
            and a separate resolution to publish the snapshot.

  <fantasai> https://drafts.csswg.org/css-2015/#responsible

  glazou: Opinions?
  Florian: Yes, let's do this.
  * TabAtkins hopes we can publish the 2015 snapshot in 2015
  glazou: I agree. +1
  <SimonSapin> +1
  <fantasai> +1
  glazou: Objections?

  RESOLVED: Adopt Section 3 of the Snapshot.
  RESOLVED: Publish Snapshot.

  fantasai: Okay. Excellent.
  <fantasai> ACTION: fantasai publish Snapshot 2015
  <trackbot> Created ACTION-724
  <fantasai> ACTION: TabAtkins update Bikeshed to spit out new
             wording
  <trackbot> Created ACTION-725

white-space:pre-wrap and pre-wrap-auto
--------------------------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0272.html
  <glazou> and https://lists.w3.org/Archives/Public/www-style/2015Sep/0228.html
  Florian: Two things. One isn't so much about behavior, but if it's
           allowed. From NYC meeting we set this specific behavior
           for white-space:pre-wrap and created pre-wrap-auto which
           lets browsers do something they may prefer.
  Florian: fantasai wrote the spec prose that said the browsers may
           deviate in order to match platform conventions. But, for
           example, Chrome does its own smart thing so I'd rather go
           with language saying it should match, but not must. We
           can't test that a browser matches platform conventions so
           I don't see the point of maintaining. I think should and
           please do something smart is better.
  Florian: Especially given that Chrome doesn't match.

  fantasai: I think we should say something about what the point of
            deviating from the standard behavior should be.
  Florian: I think one thing is there isn't a platform convention.
           There's default text control, but all text based editors
           behave differently. So, why would you do something
           different? It's because you've decided for editing the
           behavior you want is more user friendly, even if it
           doesn't match.
  fantasai: We should have a goal for allowing implementation to be
            non-interoperable. If the goal is create a better widget
            for text editing, let's say that. If the goal is match
            platform conventions, say that. If the goal is do
            something different for the sake of different, that's a
            problem.
  Florian: I was attempting to word along the lines of the UA must
           provide a smart behavior, should match platform. And be
           smart is defined as provide a good experience.
  fantasai: I'm okay with that.
  Florian: So match platform conventions and if you can do better go
           ahead.
  fantasai: Let's word smith this unless anyone else has something
            to say.
  Florian: I'll send a pull request and we can discuss.

  koji: I wasn't at NY, but I think this issue has two prospectives.
        One is if platform convention should be allowed. Engines are
        not agreeing, but if we want two values, one for platform
        and one that doesn't, that's okay. My concern is if pre-wrap
        wraps before a space.
  Florian: That's the other issue.
  Florian: The resolution we had allows wrapping before and after
           spaces. But koji and fantasai have concerns. koji wants
           no wrapping before the first space and fantasai assumed
           that. Should we re-resolve? It seemed reasonable, but you
           guys disagree.
  fantasai: I think that would cause a problem...it's common to use
            single spaces to separate words and you'd have a lot of
            single spaces at the beginning of the line. Multiple is
            more reasonable.
  <fantasai> to wrap
  <tantek> agreed with fantasai

  Florian: We could do a between. You don't wrap before a single
           space, but if you have a single at the end of a line that
           overflows you don't count it as an advance and you let
           the single space overflow. Or that's too magic.
  koji: That's more magic to me. There's no editors that do that.
  Florian: I'm not sure about that.
  Florian: There's so many editors doing different things I'm not
           sure which does that. If you have a word space word and
           if it doesn't fit you wrap the word and no matter what
           the space doesn't wrap.
  <tantek> plenty of editors do that. iOS "Notes" app for example,
           and "Messages" as well.
  <tantek> extra spaces at the end of the line just stay on the end
           of the line, until you type a visible character, then
           that character starts the new line, not the spaces

  fantasai: There's two main goals. One is present code and in that
            case you want every character and not wrapping in the
            middle of a long line of spaces is awkward. The other
            use case is I'm editing and I want to wrap stuff and
            when I hit space I should hit that because it's plain
            text. If those are the two use cases...code and plain
            text...then doing code which is pre-wrap should display
            every character and not do magic collapsing.
  fantasai: The other should do whatever intelligent things it wants
            to do to make plain text editing happier.
  Florian: I'm sold.

  <tantek> existing plain text editors do not wrap spaces at the end
           of a line
  <tantek> I'm disappointed by the lack of specific examples
  <tantek> to back up these claims of "code" vs. "plain text" editors

  koji: The point I made is when you're editing code you wrap before
        space and break with it.
  Florian: So if the only change is we don't allow a break before
           first space, you're happy...is that correct?
  koji: After every space...what about between spaces?
  Florian: In pre-wrap you do wrap, but not before the first one.
  koji: I don't like that.
  Florian: Why?
  koji: My experience is word processors don't expect spaces to wrap
        to the next line.
  <tantek> exactly!
  Florian: We have pre-wrap-auto which does what you want from a
           word processor. If you want a simple mode where I press a
           space and the space appears, we don't have that.
  koji: If you want code editing you want to break between words too.
        That's a break-all.
  fantasai: break-all is between every character. It's not about
            spaces.
  Florian: I disagree that in a code editor you want to break
           mid-word. I don't want that.
  fantasai: No one does that. Maybe in Japanese.
  koji: They do between words.
  fantasai: Not between letters.

  koji: I think we should create a list of editors.
  Florian: I tried to start with a list, but it left people more
           confused.
  glazou: We're starting to take too much time.

  Florian: If we make the change I suggested, fantasai is okay with
           it. You had a bug filed against Chrome that would be
           fixed by how we're presenting. We're fixing that it
           breaks before the first space. It's a first step and we
           can look again.
  koji: I don't like spaces to wrap to next lines.
  Florian: We had an hour+ discussion about this in NY. I'm not sure
           we should have it again now. I'm proposing that for now
           we fix what we did in NY and if you want to revisit the
           whole NY discussion we can do that at TPAC.
  Rossen: I'm not hearing too much new information that wasn't in NY.
          If this is a discussion just to re-discuss, perhaps we can
          leave it for TPAC?
  Florian: And we need drawings.

  glazou: Let's conclude.
  Florian: So do we have a resolution to fix it?
  glazou: Not yet. Can you type the proposed resolution?
  <Florian> proposed res: in pre-wrap, disallow wrapping before the
            first space
  glazou: Comments or objections?
  Florian: Given that we might reopen the whole topic.
  koji: I'd rather mark an issue.
  <tantek> Agreed - leave it as resolved NY
  <tantek> anyone that wants to change it - provide a written
           proposal, and instead of plain assertions "editors do
           this", or "code editors do that", or "plain text works
           like this" - provide SPECIFIC examples of WHICH editors,
           so we can verify your claims

  Rossen: Florian you had a test case. Can you share that?
  Florian: Let me find them. I'll paste in IRC.
  <Florian> http://florian.rivoal.net/csswg/wrap/

  glazou: koji to answer you, this is not a moment to discuss what
          to do instead. There's a proposal, do you object to it?
  koji: I want to mark an issue.
  glazou: koji, you want to mark an issue. Do you object to the
          proposal?
  koji: I don't object.
  glazou: Any other objections?

  RESOLVED: in pre-wrap, disallow wrapping before the first space

Behavior of scrollLeft in RTL or vertical-rl mode
-------------------------------------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0303.html
  glazou: This is from zcorpan. He can't be on the call.
  <glazou> for the telecon which i am not able to attend today, re
           "Behavior of scrollLeft in RTL or vertical-rl mode", IIRC
           the spec is intended to match Gecko. i can look into it
           more closely tomorrow
  glazou: So Mozilla people, is there anything else to say?
  * fantasai hasn't got a clue about this issue, fwiw
  smfr: Webkit is buggy in this area. I agree with the proposal and
        at some point webkit will change to be more consistent and
        do that.

  glazou: Maybe we need to wait for zcorpan to resolve.
  glazou: zcorpan's comment was on the message link I posted.
  dbaron: What was zcorpan's comment?
  glazou: [reads]
  dbaron: Okay. That's fine.

  smfr: Edge is also inconsistent. Does Microsoft have plans to fix?
  Rossen: Unlikely, but I'll look into it.

The 'inline-{start,end}' values for 'float' and 'clear'
-------------------------------------------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Oct/0062.html
  Florian: Is johanneswilm on the call?
  johanneswilm: Yes.
  johanneswilm: I wasn't part of the conversation, but whatever the
                outcome is it should apply to page floats. I would
                say keep as-is, but if people want just start and
                end I'm fine with that.

  Florian: If we have 2d and it can do inline and block, keeping it
           explicit is preferable so keep as-is in page floats.
  koji: I agree, but have concerns. Can authors remember if this
        property is 1d or 2d and understand that it's inline is
        confusing. That properties can be changed between 1d and 2d
        can create changes.
  Florian: If you a float with block-start you're not moving inline;
           it's clear.
  koji: Block-start is clear.
  koji: But how people distinguish why a float is start is confusing.
  Florian: If you do float start nothing happens. Therefore you
           should use inline-start
  Florian: But I see your point.
  * bradk thinks it would be more confusing if one said 'block-" and
          the other didn't say 'inline-'
  <tantek> anything with float is confusing
  <SteveZ> I agree with Koji, we have, to date, only use "start" and
           "end" for inline. Therefore, they need no prefix. We
           should use other keywords for block direction

  fantasai: We're looking into this for other properties. What I
            think is we should get a list of what are all the
            properties that need the keywords and look together. I
            think I'm happy with inline-start and -end for now.
            Possibly allow both. I don't know. I've been looking at
            2d positioning a lot. One thing I concluded looking at
            background positioning syntax is that being super
            verbose is sometimes convenient and sometimes not. So
            having start start is convenient sometimes.
  fantasai: We might want to codify the ability to shorten the
            syntax. But it's also useful when you only need one
            keyword it's nice to put that one and not try and decide
            which to set null.
  Florian: And in floats you can't move arbitrarily in 2d so the
           position things doesn't apply for now.
  johanneswilm: Until we have 2d floats.
  Florian: Which will probably happen.

  fantasai: The best conclusion I have now is we should have start
            and end for now and we should think on this further.
            It's a complicated situation and looking at float in
            isolation won't get us the answer. But I don't think
            this is for the call.
  johanneswilm: Agreed.
  koji: I'm good with that.

  SteveZ: So we should talk about that with TPAC?
  fantasai: Yes. We should do all the logical things. I'll add to
            the agenda.
  glazou: Anything else on that topic?

Default Alignment of Grid Tracks
--------------------------------

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Oct/0022.html
  fantasai: In the alignment property, in the past we had the
            ability to use content distribution keywords like
            stretch in flexbox, but not grid. We added it in grid,
            though. The alignment spec was written before that. It
            said the initial value is 'auto'. For Flexbox 'auto' was
            'stretch' and for grid it was 'start'. Now it's
            inconsistent that they don't behave the same. So the
            proposal is to make grid follow the flex setup. The
            initial value for align-content would stretch the tracks.

  Rossen: I do like to keep flex and grid consistent as much as
          possible. I'm not convinced this issue needs to be
          resolved in favor of keeping them consistent. Stretching
          in flex is a lot more common and expected than it is in
          grid.
  Rossen: Having the 2d layout and behavior of grid compared to that
          of flex, it doesn't naturally suggest that items or trunks
          should be stretched.
  Rossen: I'm in favor of keeping grid as start. The argument that
          Javier is making that it's more work, I don't buy that.
          You have to make both work and it comes from an initial
          value, not adding more code.
  fantasai: To clarify, the effect of making it stretch only effects
            auto-sized tracks.
  Rossen: I know what it effects.
  fantasai: But you're not the only person on the call.
  fantasai: It effects auto-sized tracks and only by making them
            bigger if there's extra space. You'd have auto-sized
            rows and if your container is taller than the rows the
            extra space would get distributed.
  fantasai: If your grid was auto height to begin you won't have
            extra space.
  Rossen: I said what I have to say. Even with that...fantasai was
          restating how it works. My comment/feedback remains.

  fantasai: Are there other people with thoughts? Or would like time
            to look?
  glazou: Apparently not.
  fantasai: I'm not convinced yet, but I'll leave spec as-is until
            there's other information or comments.
  glazou: Okay. No resolution for that. We have 8 minutes on the
          call.
  Rossen: Isn't the resolution to not change anything? Just for the
          people commenting on the thread so they have feedback?
  fantasai: I think we should be looking for more feedback at this
            point. Particularly from authors.
  glazou: I agree.
  Rossen: You have one that's speaking right now.
  Florian: You're not an author.
  glazou: Anything else? We'll close this one. We need more feedback.
          I agree with Florian that you're not only a user/author.

Fragmentation Issues
--------------------

  <fantasai> https://drafts.csswg.org/css-break/issues-lc-2015#issue-19
  fantasai: Issue #19. How the OM model works for fragmented boxes.
            I figured it's out of spec and the OM should talk about
            that. I wanted confirmation that people feel that's a
            reasonable conclusion.
  glazou: I think so because otherwise it would block the spec.
  glazou: Agree?
  Florian: Yes.
  astearns: Fine by me

  RESOLVED: Issue #19 is out of scope.

  <fantasai> https://drafts.csswg.org/css-break/issues-lc-2015#issue-21
  fantasai: Next is a break in inline blocks. A line box cannot
            fragment so what do we do with them? Roc proposed we
            cannot fragment. That's fine by me. If someone wants
            something else tell me and we can discuss.
  SimonSapin: Sounds good to me.
  Rossen: So keep inline block as non-fragmented? That makes sense.
  fantasai: It's about if you have an inline block taller than the
            page, what do you do?
  Rossen: It's 2d fragmentation so yeah.

  RESOLVED: Take Roc's suggested wording about keeping inline blocks
            non-fragmented.

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Sep/0153.html
  fantasai: Next is about guaranteed progress. We resolved a
            fragmentainer is 1px tall at least. But we didn't
            resolve that you need 1px of content on that
            fragmentainer.
  Rossen: I thought we did.
  fantasai: It's not in the spec.
  Rossen: So we need to edit it that 1px on content is consumed.

  Florian: Should it be 1px height or does it consume while
           overflowing?
  fantasai: We said it was 1px high.
  Florian: But we should consume 1px of content.
  fantasai: So you must place at least 1 thing on every fragmentainer.
  SimonSapin: Should we talk about non-0 amount of something?
  <tantek> nonzero++

  Rossen: Since this is near error condition, can we leave the spec
          to say content process must be made by ensuring
          fragmentainers are at least 1px tall? The rest is implied.
          How the content is consumed is decided by what content it
          is.
  fantasai: I think someone will say let's push this to the next
            page because 1px is too small. We're missing from the
            spec that progress is being made.
  Rossen: Yes. Let's not be too specific.
  fantasai: Yes, you must place a thing. Put whatever you can, but
            there has to be 1 thing.
  Rossen: Okay.

  fantasai: So each fragmentainer must contain at least some content
            or fragment of content.
  Florian: I like non-0 amount of content.
  fantasai: Okay.

  RESOLVED: Each fragmentainer must contain at least some content or
            fragment of content.

  <fantasai> https://drafts.csswg.org/css-break/issues-lc-2015#issue-24
  fantasai: Last issue, I'm just presenting. During last F2F hober
            suggested page, column, and region keywords would be
clearer if prefixed with force. So do we want to rename
            them. We're out of time, so we can't discuss. It's on
            the agenda, though, and should be discussed at some point.
  glazou: We have 1 or 2 calls before TPAC so we'll do it there if
          we don't get a call.

  glazou: I know some of you will be away the week before TPAC so
          can't do a call. If you know you can't be on the call that
          week, please let me know. I'm skeptical that we could make
          quorum for that call.
  * fantasai will be traveling, but can attend the call
  * SimonSapin same
  <dbaron> I'll still be around the Wednesday before TPAC.
Received on Thursday, 8 October 2015 11:33:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:34 UTC