[CSSWG] Minutes Telecon 2015-07-08

Paris F2F
---------

  - Everyone was okay with having some overlap time with the SVG WG
      during the Paris F2F instead of during TPAC.

Using an images/ Folder for Specs
---------------------------------

  - RESOLVED: keep images and an images/ folder and source files in a
              source/ folder for each spec

Clarification on percent margin/padding
---------------------------------------

  - This issue was editorial and will be addressed by the editors

Logical Values for caption-side
-------------------------------

  - RESOLVED: add block-start-outside and block-end-outside

overflow: clip and BFCs
-----------------------

  - One of the blockers for the conversation was the use of the word
      'clip' when it really was a property to just do
      overflow: hidden, but not allow scrolling. If the property is
      re-named a main objection will be removed.
      - hidden-no-scroll was the new name used on the call.
  - A larger issue as to if this is solving an important problem was
      also raised. One side was that this is along the same lines as
      will-change that allows authors to indicate intentions in
      order to speed up the browser. However, the same argument that
      will-change was fixing an implementor issue can also be
      applied to overflow: clip.
  - Florian will write an e-mail summary of the conversation and the
      options moving forward to continue the conversation forward
      with input from those that weren't on the telecon.

Variants of pre-wrap and longhands of the white-space property
--------------------------------------------------------------

  - The third option in Florian's list of suggestions (available
      here: https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html)
      was discovered not to be a potential solution.
  - It was instead replaced by eliminating the white-space longhands
      that are causing the problem.
  - Discussion will continue on the list.

bikeshed user-select: element
-----------------------------

  - This conversation will wait a week so that people can review the
      history of this property.

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

Present:
  Rossen Atanassov
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Florian Rivoal
  Simon Sapin
  Hyojin Song
  Alan Stearns
  Lea Verou
  Johannes Wilm

Regrets:
  Tab Atkins
  Sanja Bonic
  Edward O'Connor
  Greg Whitworth

  scribe: dael

  plinss: Anything to add?
  Florian: Topics 6, 7, and 8 are related and I prefer 7 before 6.

Paris F2F
---------

  plinss: I did have one request from Cameron. Looks like SVG
          meeting isn't going to meet at TPAC and they're looking at
          co-locating with us in Paris and were hoping they could
          spend time with us in Paris.
  ChrisL: When in Paris?
  Rossen: We decided to combine SVG and CSS. SVG will start Monday
          or maybe Sunday and we'll overlap two days with CSS. In
          that way we can do a FX joint meeting either the first or
          second day of the CSS meeting.
  Rossen: If there are issues that require some members we can go
          back and forth between rooms.
  Rossen: Basically, they'll overlap for two days.
  Florian: Depending on agenda, I don't mind doing it during the
           overlap, but I do mind before.
  Rossen: I don't believe that was the request.
  Rossen: The request was for a regular CSS date.
  plinss: I'm not hearing objections so I'll send a thumbs up.
  Rossen: We can provision a half day and if more is needed everyone
          is in the same building so we should be able to facilitate
          as we go.
  plinss: Right. We can factor that into the agenda.
  Rossen: There's a number of topics pushed away for joint
          discussion. And since there's too many members with TPAC
          conflicts they decided to cancel that meeting.

Using an images/ Folder for Specs
---------------------------------

  plinss: TabAtkins isn't here, but he sent an e-mail with the
          proposal.
  fantasai: Sounds good to me.
  Florian: It's all images in a sub folder of each spec, not a joint
           folder, right?
  plinss: Yes.
  Florian: That I'm okay with.

  smfr: I like the idea and did it for transforms.
  smfr: There was question about where to put files generated by
        images and I'd prefer them in a separate folder.
  astearns: Things should be in sub folders, that's what we should
            go with.
  Rossen: The way I read the request is he was requesting a single
          folder for all of them.
  Florian: It's one per spec.
  <astearns> and we shouldn't dictate folder structure

  fantasai: Each spec has a folder for where the files and and the
            images for the spec would go in there.
  Rossen: And this is more optimal than one images folder for all
          the specs and if a spec requires something special...
  fantasai: We have:
  <fantasai> css-break/Overview.bs
  <fantasai> css-break/Overview.html
  <fantasai> css-break/images/
  <fantasai> css-break/images/diagram.png
  fantasai: And all the stuff goes inside images.

  Florian: We don't share images across specs.
  plinss: And a shared folder would create publication problems.
  ChrisL: And if something changes you need to work out dependencies.
  Florian: Do the source files for the images go in there or do we
           use a sub folder?
  ChrisL: I prefer separate. And for publication it makes it easier
          to have separate.
  * fantasai prefers keeping sources in the same folder, easier to
             see which file you're supposed to edit when working
             with them images
  * fantasai is sympathetic to concerns wrt publishing, though
  smfr: How does publishing choose which files?
  ChrisL: On the new system you send a manifest file that lists all
          the directories and files in that. Old way someone made
          the choice.

  Florian: My small use case for separate images and source is what
           I did for CSS 3 there were a bunch of images and not all
           were used and it makes it a lot easier if the images
           supposed to be used are in one place, but that's a small
           thing.

  RESOLVED: keep images and an images/ folder and source files in a
            source/ folder for each spec

  dbaron: But it goes in a sub directory?
  plinss: bikeshed source file, see where they are. This is just
          files to generate images if any.
  <dbaron> I don't think "source/" was a name to be used for image
           sources...

Percentage resolution for abspos vs inflow grid items
-----------------------------------------------------

  Florian: Didn't we do that?
  fantasai: And we need TabAtkins

Clarification on percent margin/padding
---------------------------------------

  Rossen: This is editorial. I don't think it requires much group
          discussion.
  Rossen: Basically someone reading the spec was confused by the
          current text that says margins and paddings resolve their
          percent values from their...what was the current text...
          from their respective sizes or something like that. It
          sounds like they would resolve percent from themselves.
  Rossen: It's editorial to show they resolve from the width or
          height of the block.
  plinss: We'll let you take care of that one.

Grid issues
-----------

  Rossen: Who has this one?
  plinss: There were some from fantasai and gregwhitworth had one.
  Rossen: For gregwhitworths's he's on vacation.
  Rossen: I don't have the ability to do those. We can push them to
          the end of the call and by then I might be in the office.
  plinss: We'll defer those.

Logical Values for caption-side
-------------------------------

  <dael> https://lists.w3.org/Archives/Public/www-style/2015Jul/0004.html

  fantasai: We have 2 values of caption-side that didn't have
            logical equivalents. In the spec and those are
            top-outside and bottom-outside and the proposals are
            block-start-outside and block-end-outside.
  Rossen: Let's start with those and if we rename we'll do
          everything. Being consistent with the current ones sounds
          good.

  plinss: Other opinions?
  <glazou> +1
  smfr: What does outside mean in this context; source? stuff for
        generating images? I would rather leave it up to editor
        choice.
  fantasai: The model for table captions in CSS 2 is the table
            caption is a block whose containing block is the width
            of the table's containing block. In implementation
            captions were constrained to the size of the table
            itself. In CSS 2.1 we changed the definition so that
            that's how it behaved.
  fantasai: Because you often want the old behavior we said there
            would be top and bottom values that would hold the
            behavior. Mozilla had implemented those as per spec and
            since they have that and they're implementing logical
            equivalents they needed logical values for those that
            don't exist anywhere but note.
  smfr: So it's in terms of containment, not left page, right page.
  fantasai: Yes, it's about the table, not paging.

  Rossen: What module is that in?
  fantasai: caption-side values are in CSS 2.1 in a note.
  fantasai: And we have the logical equivalents in writing-mode.
  Rossen: Thank you.
  <fantasai> The model for table captions in CSS2.0 was the table
             caption was a block whose containing block was the
             table's containing block.
  <fantasai> However, in implementations, captions were constrained
             to the size of the table itself.
  plinss: It sounds like people are okay with it.

  RESOLVED: add block-start-outside and block-end-outside

overflow: clip and BFCs
-----------------------

  <dael> https://lists.w3.org/Archives/Public/www-style/2015Jul/0013.html

  Florian: In relation with containment and paint containment, we
           added a value to overflow that's 'clip'. It's the same as
           'hidden', but you can't scroll even programmatically.
           Very often that's what authors want and if they can say
           that it allows browsers to be more efficient.
  Florian: Mozilla has a slightly different thing. Every value of
           overflow other than visible makes the elements create a
           BFC.
  Florian: Mozilla's doesn't do that.
  Florian: Before we go further I thought we should consider that
           and if we should align. I think it's odd, but it's what
           they do.

  Rossen: This would complicate the float algorithm quite a bit
          because if I have floats that extend past the bounds of
          the clipping element, it means they're bound for the
          purposes of line layout will need to be considered for
          visual clipping.
  Rossen: That sounds weird.
  dbaron: That's not what Mozilla's value does.
  dbaron: This is how we did overflow: hidden before it was clear
          what it did. What we do is just visual clipping, it's not
          layout change.
  dbaron: It's a lot like clip, but it applies to more than abspos
          elements.
  Rossen: So layout would have been taken account like it's visible
          and the clipping is render time only behavior?
  dbaron: Yes.
  Florian: So for historical reasons, I see how you ended up there,
           but do you want to maintain it?

  <vollick> Is this related to contain:paint?
  <vollick> I.e., is overflow:clip similar to overflow:hidden +
            contain:paint?

  Rossen: I question the usefulness.
  dbaron: Its been useful as a lighter weight variant of clipping.
  Rossen: What makes it heavy weight?
  dbaron: You need to be able to allow scrolling. In our
          implementation some of that is heavy.
  Florian: That's why overflow: clip is supposed to be different.
           It's the same as hidden, but you don't have the scrolling.
  Rossen: It's going to be a different behavior because all the
          floats inside the clipping element, but adding clip all
          the floats won't affect the layout outside. If you toggle
          back and forth with the clip you have to re-layout.
  Florian: That's the same as hidden.
  Rossen: Yeah, in that respect yes. In the way dbaron described it
          you wouldn't have to do anything, it's just visual.
  Florian: In terms of run time costs, switching to my clip is
           higher cost than Mozilla's. But in terms of
           implementation you have it already because you have
           hidden.
  Rossen: In terms of implementation cost for us, if we pursue one
          of the other there won't be that much difference, I don't
          think. It's allowing...um...

  Florian: I question the usefulness of hidden floats going outside
           and change the layout.
  Rossen: That's what I have a problem with. If there's a float to
          the bottom and I clip it the stuff at the bottom will re-
          layout and that's weird.
  dbaron: It's also weird to design things to be more expensive just
          because of floats which we do a lot.
  Rossen: But we can't just ignore them, right?

  fantasai: Keep in mind that we do now have a switch for creating a
            block formatting context group. A lot of overflow is to
            make the BFC and you can do that now explicitly. Right
            now you can't say I just want to clip as easily.
  Florian: What's the use case for clipping without a BFC?
  fantasai: Maybe you don't have floats, just margin collapsing, and
            you don't want to change the margin collapsing behavior.
  Rossen: It sounds again like we're oversimplifying once we toss
          the float out of the picture.
  Rossen: dbaron, in your implementation I'm assuming the only
          things you're doing is constraining the key region for the
          rendered sub tree?
  dbaron: I think so, yes.

  Florian: One of the goals for this value, just like the other
           non-visible values you should be able to use it with the
           stuff that requires overflow to be non-visible.
  fantasai: That should be fine. Right now we don't have a way of
            saying I want to clip only in this dimension.
  fantasai: This would allow you to combine, you could have hidden
            overflow in the y and visible in the x, we don't have
            that.
  Rossen: I would argue we should extend clip and define it so that
          it applies to everything and not piggyback on overflow.
  dbaron: I think if we want overflow: visible in one direction and
          not the other, it makes sense to not make a BFC. I suspect
          webcompat will let us not extend and we'd need something
          new.
  <tantek> agreed with dbaron about clip compat
  Rossen: Do you know how much of a compat issue this is for you?
          Because we haven't done this.
  dbaron: We haven't implemented and I don't think anyone has. Its
          been out there for years so I think there will be breakage.
  fantasai: 'clip' could apply to more than abspos if you made the
            rect value not apply.
  fantasai: The rect notation is very awkward so the other ways of
            spec clip paths are better and if we had those they
            could apply to all.

  Rossen: So if we're talking about clipping, let's make it part of
          clipping not overflow.
  Florian: Stepping back, one of the reasons of introducing this,
           when you do contain: paint it would do a number of things
           including something like overflow: clip but it wouldn't
           go through the overflow property, so you couldn't have
           resize apply to that. Unless you turn it to hidden or
           auto, but that causes memory allocation to go up. Having
           contain: paint do overflow :clip through the overflow
           property is part of the justification for having this.
  Florian: If we have the ability to be overflow-x: visible and
           overflow: clip the resize property doesn't make sense. We
           used to have a note that this is an oops and we need to
           fix it, but we removed it because we didn't think it
           would happen.

  Rossen: Do you think this would change if we define it on the clip
          rather than the overflow?
  Rossen: I have overflow: visible in both directions and have
          clip: bottom...
  Florian: There would be a compat issue if resize starts to work
           when overflow is visible. There may be things that
           depend on it not applying.
  Florian: We could define to do something sensible when you have
           visible only in one direction. That could be an expansion
           to the spec.
  Florian: If you say resize in both directions, but only one is
           visible, the other is clip, then I don't know.
  Florian: It's not a case that's been possible before. Maybe you
           can do in both directions if it's something other than
           visual. It's a bit more complex than saying it's the same
           as hidden without scrolling.
  Florian: To do as fantasai said, this would be possible.

  Rossen: My pushback is I'd prefer it to be part of clipping. The
          overflow has already happened. If the floats that are
          overflowing have already affected the contents, it means
          it happened.
  Florian: I think it's going to be a problem to go through clip
           because if you're trying to contain: paint and resize.
           You do contain: paint because you don't want a large
           buffer. If you're in overflow: visible you can't have the
           resize apply. And then you have to flip and you end up
           with the buffer and possibly scroll bars.
  fantasai: I think a more common case is wanting to have text
            overflow apply and the ellipsis set.
  Florian: Yes. Same problem.
  Rossen: This is a use case for overflow: hidden
  Florian: Yes, but it brings in what you didn't want, scrolling.
  Rossen: You're describing to me having an additional scroll/no
          scroll keyword to overflow: hidden...
  Florian: Yes, I'm just calling it clip. I'm happy to call it
           hidden-no-scroll except that it's long.
  Rossen: And that comes with all the BFC-ness etc. It basically
          clips on both sides.
  Florian: Yes.

  Florian: So if we rename you find it more acceptable and leaves
           'clip' for another property?
  Rossen: Correct.
  Florian: I'm okay with that.
  Rossen: Are you defined those as part of UI4?
  Florian: Overflow spec.
  Rossen: Oh, okay,
  <tantek> yes we decided a while ago to move overflow properties
           from UI to another spec, except text-overflow.
  Florian: And in containment when it comes to computed value of
           both properties.
  Rossen: Right, right, okay.

  Florian: I think Rossen and I are on the same page.
  fantasai: I'm a bit less sure.
  Rossen: What if you did the changes and we can discuss more on the
          list or at a call?
  Florian: I'm okay with that. I'm not editing clip property's spec
           so the part that is done through the clip property
           someone else will need to do the edits. I'm happy writing
           something. For overflow I can spec and discuss again.
  Rossen: Cool.

  smfr: Is it accurate that you're suggesting a new hidden-no-scroll
        because for some UA hidden makes you scroll and allocate
        resources?
  smfr: I'd argue that's an implementor issue. If the hidden is
        never scrolled, the UA doesn't have to allocate resources.
  Florian: It's the same nature as the will-change. You could get
           around it, but in practice people don't. So let authors
           be explicit we have a value.
  Rossen: I'm fully...I agree with smfr. If we're talking about the
          heuristic, you would create all the scroll handlers and
          objects the first time you request to scroll from script
          for overflow: hidden. Going into the behavior where users
          explicitly want to prevent scroll, like you're doing
          layout behind the scenes, for that I can see a better
          argument.
  Rossen: What I'm hearing is the motivation is the performance. And
          a new value for that is overkill
  Florian: I understand your point, but why is it that having a new
           value for this isn't good, but will-change is fine? They
           are the same kind of thing.
  Rossen: I've never said I was fine with will-change.
  Florian: For me, I'm not the biggest fan, but if we're going in
           that direction this makes equal sense.
  Rossen: But piggybacking on...I'd prefer to follow the good
          examples.
  <vollick> I tend to agree with smfr as well.

  Rossen: Back to your topic, do you...I don't know where we stand.
          Do we want to discuss more on the ML when TabAtkins can
          contribute?
  Florian: I think we have two reasonable ways forward. One is to
           have hidden-no-scroll and contain: paint can invoke that
           or it just invokes hidden and you can scroll. I'm okay
           with both. I'm not okay with contain: paint doing the
           magic clip and it's not accessible manually
  <fantasai> +1 to what florian just said
  Florian: If contain: paint will do something to overflow, I want
           it to affect overflow.
  smfr: Can it not select clip-path?
  Florian: Then you can't use the resize which depends on it not
           being visible.
  smfr: It allows resize?
  Florian: contain: paint does not in itself prevent resize. The
           thing is if it is just like overflow except not through
           that property then that it's not through there means you
           have to set overflow to get the things that depend on
           that and if that affects speed it's no good.

  Florian: So I think given the situation we're in it's too early to
           write a spec, but I can write a new summary that says can
           we have good enough heuristics and is this important
           enough.
  Florian: And if I'm missing something, you can reply to that
           e-mail.
  Florian: Does that sounds like a decent path forward?
  Rossen: Sounds good.
  smfr: I think so.

  ACTION Florian write a summary e-mail about the discussion on
         overflow: clip to move the conversation forward
  <trackbot> Created ACTION-701

  <vollick> Fighting with webex a bit. It feels like the efficiency
            of overflow:hidden should, as smfr said, be a UA concern.
            If we want a will-change style hint to say that we won't
            scroll, could we tie this hint to will-change explicitly?
  <tantek> ooh good question. is there an existing table we can use
           and extend?

Variants of pre-wrap and longhands of the white-space property
--------------------------------------------------------------

  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
  <tantek> pre-wrap is one of my favorite CSS features :)
  Florian: At the F2F we discussed changing pre-wrap and allowing
           some of the current implementations in through
           pre-wrap-auto
  Florian: We also said in level 4 we would add pre-wrap-trim
  Florian: We're explaining these in terms of white space, but in
           level 4 of text white-space is a short hand and I'm not
           sure how to split these between the longhands.
  Florian: That's what this mail is about.

  Florian: The longhands are text-space-collapse and text-wrap. One
           option is to say text-space-collapse is the weird one. Or
           we can go the other way around and say that text-space-
           collapse is normal and text-wrap is weird.
  Florian: I can see a lot of options and I'm not sure how to
           proceed. If anyone has a feeling on how to split these
           I'd appreciate input.
  plinss: Anyone have anything?
  Florian: I can be more specific, but I'm not sure it's easy to
           think through by listening.

  Florian: I have one question. This white space property now that
           it's a long hand: is text-space-trim a longhand of that?
  fantasai: I can't because it doesn't inherit.
  Florian: Okay. That means option 3 in my e-mail is eliminated.
  Florian: This pre-wrap-auto and trim are difficult because
           wrapping and collapsing aren't entirely orthogonal.
           That's why it's hard to say on which side of the
           longhand.

  fantasai: We could give up on the longhand?
  Florian: That's the new option 3.
  Florian: I can define options 1 and 2, but it feels weird. I'm not
           sure of how the implementation is actually done, but I
           think it's multiple stages and when you think of it as
           stages the property can influence multiple stages. If you
           don't care about stages, I can describe it and I have a
           preference.
  Florian: I think if fantasai can reply to my mail, if we can agree
           we can ask the group it it's fine.
  fantasai: It looks like a situation with no good option, but okay.
  Florian: Okay. You have the URL, we can move forward.
  Florian: I'm happy to spec both, but I'd like an opinion on which
           way.
  plinss: Okay.

bikeshed user-select: element
-----------------------------

  Florian: It had this name, element, for no longer relevant history.
           The behavior IE and everyone else has in text areas. If
           you select within the element you can't select outside
           the element. It's strange. I'd rather a new name. Its
           compat risk is much smaller than other values so I think
           we can rename.
  Florian: I'd like 'contain'. Is that okay?
  smfr: webkit implements this. The use case we had is we wanted an
        element to select atomically. Our interest was outside-in
        selection.
  Florian: Atomic selection is something we have and it's
           user-select: all
  smfr: Okay, maybe I'm mis-remembering.

  tantek: But you're right, that was the original intent, it's just
          not needed.
  Florian: And I think it was originally more complicated, like
           selecting one and not several elements in a drop down
           which is a different kind of selection.
  * fantasai is pretty confused at this point

  Rossen: I honestly don't remember the history.
  Rossen: If we're okay to wait for next week so I can discuss this
          and look back, I'd prefer to do that.
  Rossen: Is that okay?
  Florian: Yea.

  plinss: We'll defer then. That's the top of the hour.
  <glazou> bye
  plinss: I'll be gone the next two weeks at F2Fs. Try not to have
          too much fun without me.


Follow-up conversation on IRC about user-select: element
-----------------------------

  <Florian> user-select (way back when) used to do several things.
            Selection as we mean it today was one, but deciding
            whether you can pick only one (like radio buttons) or
            several (like checkboxes) in form controls was another
            goal. radio buttons was called "element" and checkboxes
            was called "elements"
  <Florian> this was also supposed to apply to dropdowns

  <tantek> Florian, also list view <select> elements
  <tantek> where you could either select *one* <option> inside, or
           multiple <option>s inside
  <Florian> indeed.
  <tantek> the point was to be able to rebuild that behavior out of
           any elements
  <tantek> rather, to be able to specify that behavior via UA
           stylesheet
  <tantek> rather than HTML magic
  <tantek> on selection/option/input

  <Florian> The modern incarnation of user-select does none of this,
            but the "element" name has been repurposed to something
            else. The something else is a useful thing, but the name
            "element" is not a good match for it.
  <Florian> for what the property and value do now, I'd rather call
            it contain. Element is confusing, as evidenced by smfr,
            who thought it meant "select the whole element" (which
            is what the "all" value does).
  <tantek> no smfr was right
  <tantek> it's just that you two disagreed on outside-in aspects vs.
        inside-out aspects
  <tantek> or had different assumptions thereof
  <Florian> well, smfr was right that it is one of the things this
            value used to do, but he was wrong in that the value
            webkit implemented to do atomic selection is not this
            one.
  <tantek> user-select was always intended to affect how selection
           of stuff *inside* the element worked
  <tantek> but seems to be have been re-interpreted as how selection
           of the element itself works in its parent context
  <tantek> "all" is atomic on the outside. element / elements is
           atomic on the inside.
  <tantek> they're both "atomic" selection variants

  <TabAtkins> ...lolwut (re user-select being used to do
              radio/checkbox)
  <TabAtkins> That's nowhere near sufficient to model them. I know,
              I wrote the spec to do so.

  <Florian> element in the old spec was that. element as currently
            shipped by microsoft (and the css-ui-4 spec follows that)
            is not.
  <Florian> The new incarnation of element is not about atomicity.
            It simply says that a selection that starts inside an
            element may not escape it. but you can still select only
            part of that element.
  <Florian> I am not debating whether or not the old version of
            user-select matches this model, since nobody is
            implementing (or planing to implement) the old version
            of user-select.

Received on Thursday, 9 July 2015 12:12:19 UTC