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

[CSSWG] Minutes Telecon 2016-03-02 [css-snap-size] [css-contain] [css-grid] [cssom] [css-font-loading]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 2 Mar 2016 19:33:12 -0500
Message-ID: <CADhPm3vDKAKWCeUgPGC_T2BCSBCq1byCOJfzVfX8i+BbYqOC1Q@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.

CSS Snap Size

  - Several people have requested more time to review before
      resolving on FPWD.
  - Any questions will be discussed on the mailing list and, if the
      issues are resolved, the group will revisit in two weeks.

Layout containment and overflow

  - RESOLVED: Accept #3 from the e-mail (Overflow is allowed
              visually, but it doesn't project its "geometry" past
              the layout-contained ancestor, so it can't trigger
              overflow past a layout-containment boundary) and say
              hit testing is currently undefined.
  - RESOLVED: Mark the undefined hit testing as an issue.

Styling the disclosure triangle of the <details> element

  - TabAtkins informed the working group that a decision was made by
      WHATWG to call <summary> element a display list item and the
      disclosure is a list item.
  - There was some strong objections to this decision; it was felt
      to be unfriendly to authors.
      - Anyone who objects should contact WHATWG as it was their

grid-template shorthand

  - RESOLVED: Remove the grid-template shorthand and fold it into
              the grid shorthand.

Events for FontFaceSet

  - TabAtkins will reach out to the appropriate implementors to
      continue conversation on this topic.


  - The publication resolved on during Sapporo will happen soon.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0025.html

  Rossen Atanassov
  Tab Atkins
  Bert Bos
  Dave Cramer
  Greg Davis
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Chris Lilley
  Peter Linss
  Michael Miller
  Simon Pieters
  Anton Prowse
  Matt Rakow
  François Remy
  Florian Rivoal
  Hiroshi Sakakibara
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

  David Baron
  Tantek Çelik
  Alex Critchfield

Scribe: dael

May F2F

  Rossen: Let's get going
  Rossen: I wanted to give an update of where we are. As you know
          the dates are firm and Shane and Ojan from Google have
          been working to secure a room for us in their San
          Francisco office. Current situation is there is a room
          secured and reserved for us. Problem is the current
          capacity is about 30 people.
  <glazou> dates and precise location?
  Rossen: The actual...I'll paste into IRC
  Rossen: It has [reads]
  <Rossen> room's large enough for 56 (standing) / 48 (theatre) / 22
           (classroom) / 30 (clusters), and is 690 sq ft (about 8m x
  Rossen: So the room is not huge. I was going over past attendance
          of F2F and if we are considering members only we should be
          able to fit.
  Rossen: If we don't think we can fit or be comfortable there for
          all 5 days of CSS and Houdini, shout out and we'll see if
          we can get something else. Current state of room booking,
          this is what we have.
  <bradk> I can probably attend this one, since in Bay Area

  glazou: One thing that has been consistent is that attendance to
          meetings in San Francisco is higher than others. I'm
          wondering if it's enough.
  Rossen: Yeah. That's why I said if it comes to it, we can limit
          the meeting to members only and if there are people who
          want to observe, as long as we're under 25 we'll be fine.
  glazou: My point is that we're usually 30-35 members in San
          Francisco not counting observers. Some people who never
          show up show up there.
  Rossen: If you believe it's going to be the case...
  glazou: It could happen. If it has to be that room I suggest a
          poll as soon as possible. It could be a harsh limit.
  Rossen: We could do that. I'll send an e-mail to the members list
          and the Houdini one.
  Rossen: I was looking at last couple years and even Santa Clara we
          weren't that much for members. We had a lot of observers.
  * glazou said SanFran, not Santa Clara....

  Rossen: This was the topic I wanted to bring up. If anyone has a
          strong allergic reaction and believe we won't fit, send me
          an e-mail or the e-mail list a message.
  Rossen: Shane and Ojan haven't stopped looking for something bigger.
  Rossen: And the dates are May 9-11
  Rossen: 12 and 13 for Houdini
  Rossen: Basically 9-13 for those joining both.
  <Rossen> May, 2016-05-09..11 (with possible Houdini 12-13), US
           West Coast

  Rossen: Any questions or anything else on this topic?

CSS Snap Size

  Rossen: Call for feedback and a request for FPWD.
  koji: I uploaded the spec from the proposal I presented at last
        F2F. Spec was changed a bit from proposal as I
        experimentally implemented it and found some things.
  koji: After that I think the current ED is in good shape.
  koji: I appreciate reviews and feedback. If this looks good I'd
        like to publish as FPWD.

  Florian: I'm happy to see work on this area, but haven't had time
           to review the draft. Would it be okay to ask for a week?
           In general I'm okay, but I haven't had time to read what
           you'd done.
  * fantasai hasn't read the draft either
  ChrisL: Are you likely to object? I'd rather make the decision to
          publish now and if you decide you want a change just shout.
  fantasai: I think that works well when we have a draft, but for
            FPWD we want to make sure everyone agrees that this is
            something we potentially want to implement. It's not a
            request as to if this is an improvement, but a question
            as to if we want to pursue this. For that reason, I
            think it's important to have a more positive consensus
            and not just a "sure, why not".
  Rossen: Fair point.

  Florian: If 2 weeks are possible, I'd be delighted, but if we want
           one week I can try.
  * fantasai would prefer more time as well
  Rossen: So we have one member asking for an extension on the

  astearns: I still have the feedback I gave in Sydney. The draft as
            stands doesn't talk about snapping, just modifying
            heights in inline boxes. I'd prefer terminology that
            doesn't use snap.
  astearns: Bigger concern is this is only inline boxes and not
            block boxes. That's a terrible mistake. We shouldn't
            design a feature that gives you this height manipulation
            and restrict it to inline. For example... 2.3 has an
            example I think is terrible. I'd object to having a
            draft that says this doesn't apply to block level.
  koji: The feature...The first point I'm not sure how better to say
        it than snap. I think you meant not to grid. It snaps size,
        not position, to a specified value. If you have better
        terminology, I'm fine with that.
  astearns: I'll try and come up with something.
  koji: For block level, from and implementor's point of view making
        block snappable adds quite a lot of complexity. This has
        been discussed a long time without being implemented. I'd
        like small parts to step and we can add features later.
  astearns: You've been doing an experimental implementation. Have
            you heard interest from other implementors to try this?
  koji: It's generally hard.
  Florian: I think that's one of the difficulties with this. The
           reduced version is simpler and therefore more likely to
           implement. Same time it does less than other things we
           discussed before. If we can get this and not the rest
           that's an up side, but if you can extend in the different
           direction as astearns suggests you get more. It's close
           the grid snapping and close to general sizing problems.
           It covers both problems spaces a bit but not completely.
  Florian: That's part of why I want time to review.
  Florian: To see if we need to extend to properly solve this.
  * fantasai shares Florian and astearns' concerns; hasn't looked
             too deeply into the specific technical details.

  Rossen: So we need more time to work on this before we go to FPWD.
          astearns has some feedback that hasn't been fully
          addressed. Florian may have feedback and some potential
          interest as well. How about we give it 2 weeks and work on
          the mailing list.
  Rossen: We will revisit the decision in 2 weeks if we agree on the
          mailing list this is ready to go.
  Rossen: How does that sound koji?
  koji: Sounds great, thank you

Layout containment and overflow

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Feb/0314.html
  Florian: That's TabAtkins and me.
  TabAtkins: A few weeks ago we talked about what to do about a
             layout contained element that overflows. It naively
             allows overflow that allows scroll and violates
             existing semantics.
  TabAtkins: I was actioned to talk to our implementor. By accident
             we're doing solution 3 in the e-mail: when children of
             a layout contained element overflow, the ancestors
             don't know about it. So they cannot trigger scrollbars.
             They will overflow visually in the worst case.
  TabAtkins: I went ahead and specced that.
  TabAtkins: The only remaining question is if the overflowing part
             should be able to hit test.
  Florian: I believe the behavior TabAtkins described is called ink
           overflow. I agree this is the behavior we want, we just
           disagree on if it's called that.
  TabAtkins: Ink overflow is the right term. I'll switch the spec to
             use that.

  smfr: Ink overflow becomes visual overflow and the driver still
        has to manage overflow and you may need some code to treat
        it as ink overflow. That it works as a side effect we
        shouldn't spec that way.
  TabAtkins: I think it's a nice benefit, but also #3 is the right
  smfr: #2 is the logical behavior you want and easy to implement.
  TabAtkins: Why is that best? We have the concepts separated
             because they're separate concepts.
  smfr: It seems odd at some level to convert layout and ink overflow.
  TabAtkins: Basically we just don't inform the ancestors that
             there's any overflow happening.
  TabAtkins: So the layout is the normal bounds.
  Florian: That's paint time.
  TabAtkins: The layout code that figures out if there's scroll bars
             is not informed of the overflow.
  smfr: I'm not too happy with that.

  Rossen: It should be like the #3 for me...it sounds like you're
          bubbling up the behavior of overflow on a child to its
          containing scrollers. Once you have a child that has
          overflow contain, it becomes ink only, the parent is not
          supposed to be able to scroll to that ink overflow. I'm
          concerned this will break a bunch of scenarios.
  TabAtkins: This is only the contain property. It doesn't effect
             scrolling, but things outside layout contained elements
             doesn't see effects.
  Rossen: You have one element which is a scroller, overflow: auto
          and one div. This div is width and height 50% so it
          doesn't cause scrollbars for scrolling parent. If you
          insert a third element inside the div you're saying you
          can't get to it if it's overflowing.
  TabAtkins: If the middle element has contain:layout on it. You're
             saying nothing in this element should effect layout
             outside this element.
  Rossen: How do you scroll to show the entire...you have the parent
          which is a scroller, but no scroll bars trigger.
  Florian: And you're explicitly asking for this not to change
           regardless of the middle div because that's the point of
  Rossen: You're creating a case where users can't see content.
  TabAtkins: No more than paint containment already causes. I'm
             saying on certain situations make assumptions.
             contain:paint hides all overflow, no matter what.
             contain:layout says that if you really overflow you
             can't see it, but that's less worse than paint layout.
  fantasai: Basically what this is doing is saying the element with
            contain:paint the layout overflow is the size of the box.
            The ink is whatever the union of ink and layout would
            have been. It's not complex and digging around in
            scrollers. Just for that element you clip the layout
            overflow and left the ink to be as big as the rest of
            the content.
  TabAtkins: Yes.
  <Rossen> <div style="overflow: auto; width: 100px; height: 100px:">
           <div style="contain:layout; widht: 50%; height: 50%">
           <div style="width: 200px; height: 200px;"> This will be

  smfr: I'm concerned about hit testing.
  smfr: I don't think we take ink overflow into account with
        hit testing. We may have to do work.
  TabAtkins: If making it interactive is hard, we just don't do #3.
             So the assumption is don't overflow your layout
             containment you crazy person because you can't interact
             with it. That's fine.
  Rossen: This will be difficult to implement for us.

  Florian: I think I'm still in favor of #3, but if we consider the
           alternative of layout overflow implying paint overflow,
           it's worse. If you do option 3 you can see them
           sometimes, #2 you'll never see them. So it doesn't fix
           that aspect of the problem.
  TabAtkins: I was just making certain that shadows are ink overflow.
             So we're saying layout:contain is the same as the shadow.
  Florian: The only question is do we hit test
  <fantasai> hit testing is only border-box area (as modified by
  <gregwhitworth> hit testing on a shadow is much different than hit
                  testing on content
  <fantasai> shadows are theoretically infinite :)

  Rossen: Say layout overflow for contain:layout becomes ink. The
          geometry isn't propagated up so no floats that are part of
          that can penetrate.
  TabAtkins: You're formating context, that's beyond definition.
             This is only about scrollbars on ancestors.

  Rossen: It sounds like you want to resolve on option 3
  TabAtkins: So resolve on option 3, that's in the spec. And, if
             possible, I'd like to agree on hit testing. Sounds like
             we're leaning no on it.
  smfr: I'm concerned about creating a foot-gun and they have ink
        overflow and don't realize it.
  <gregwhitworth> I agree, a lot of this feature feels like a foot
  TabAtkins: This property at its basic is a foot gun.
  Rossen: Invisible and not interactive is by design. Visible and
          not interactive is a poor UX.
  TabAtkins: That's why you don't do it. Contain isn't designed to
             be a safe property.
  <fantasai> +1 to smfr's point. It's much more confusing if it's
             visible but not interactive--the author is much less
             likely to notice the problem.
  Florian: If you don't give an explicit size it will collapse to 0.
  TabAtkins: There's a lot of things to discourage causal usage.
  Rossen: There's a number of people concerned about the
  TabAtkins: This property in all aspects creates bad behavior if
             you don't treat it right. It's terrible to use if you
             don't obey the restrictions. It's not safe. It's
             'optimize me really hard'.

  Florian: TabAtkins position was that he wanted hit testing and the
           suggestion that it's hard from implementors is what is
           causing us to say no hit testing. I'm for it if we want
           hit testing.
  Rossen: I still believe it will be tricky to get the hit testing
          on our end.
  Rossen: TabAtkins does your current implementation hit test?
  TabAtkins: I don't know yet. Our implementor hasn't answered me yet.
  Rossen: At the least if we go with option #3 and require it to be
          hit testable per spec, would that be okay with other
          implementors? Specifically smfr?
  smfr: I have to think about it. I don't want to make it hard to
        implement this property. The point is the browser can do
        shortcuts to make it fast and if the browser has to do a lot
        for hit testing that defeats the purpose.

  TabAtkins: Just the scrollbar question, I said this is easy for us
             to do in a performant manner. It works as a performance
  Florian: TabAtkins while you're checking on hit testing, can you
           document the use cases that need layout and NOT paint
  TabAtkins: Anything that wants negative margins to poke out, they
             should be allowed. They don't normally change layout,
             but they can happen to have just enough poke out that
             you happen to get scrollbars.
  Florian: So anyway this is optimization so we don't restrict it we
           remove a few cases.
  TabAtkins: We restrict it which isn't good. There's a few cases
             where if you set it just right you can emulated layout
             containment. I'd like to not restrict people when they
             have reasonable use.

  Rossen: We have a couple of options. 1) put this on ice until you
          hear about hit testing. 2) Accept #3 and require hit
          testing works. 3) Accept #3 and say hit testing is
          optional or not supported.
  TabAtkins: What I want is #3 and leave hit testing undefined until
             we investigate further. Say we're unsure about hit
             testing in the spec and that it will be replaced with
             spec text soon.
  Rossen: Sound like 3 with optional hit testing.
  TabAtkins: No, undefined hit testing.
  Rossen: So #3 with undefined hit testing. Objections?
  <fantasai> Okay, if called out as an issue
  <fantasai> not just left undefined
  <fantasai> Rossen^

  RESOLVED: Accept #3 from the e-mail (Overflow is allowed visually,
            but it doesn't project its "geometry" past the layout-
            contained ancestor, so it can't trigger overflow past a
            layout-containment boundary) and say hit testing is
            currently undefined.

  astearns: Rossen you missed fantasai objecting in IRC.
  TabAtkins: She didn't object to what I actually said so it's fine.
  Rossen: So an issue and it's undefined.
  TabAtkins: Yeah.

  RESOLVED: Mark the undefined hit testing as an issue.

Styling the disclosure triangle of the <details> element

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Feb/0282.html
  TabAtkins: I don't know who put this specifically, but the e-mail
             was from Mozilla.
  TabAtkins: The <summary> element of <details> is supposed to have
             a disclosure element that says if it's open or closed,
             but doesn't have good details on how to implement.
  TabAtkins: fantasai and I agree it seems reasonable to call
             <summary> element a display list item and the
             disclosure is a list item. That's handled by disclosure
             open and closed. HTML thought it was odd at first, but
             were assuaged when I explained. There's a PR pending
             that accepts tweeking the UA style sheet to require
             that it makes it required.
  <zcorpan> i think this is https://github.com/whatwg/html/pull/748
            (which is merged)
  TabAtkins: HTML accepted this styling and we're okay unless
             someone objects.

  glazou: Display doesn't cover semantics, but saying details is a
          summary list item is pretty terrible.
  TabAtkins: When you say it is not a whatever you're implying
  glazou: Web designers will be confused because they don't have
          knowledge of the discussion.
  fantasai: This is better than anything on the table.
  glazou: Just do an alias, don't use list item.
  <zcorpan> ...no
  TabAtkins: Another name for list item for this one thing is silly.
  glazou: We'll avoid the cost of one string because we're saying
          this works?
  TabAtkins: Are we adding one string because someone is in theory
  glazou: If you do that in a UA style sheet people can use it
          elsewhere. <details> display list item, no one is shocked?
  leaverou: I agree with glazou. If people want display of summary
            they have to set it back to list item.
  glazou: I object formally to this. It's terribly ugly
  <zcorpan> i object to adding an alias
  TabAtkins: This is HTML's deal.
  glazou: So I'm proposing the CSS WG makes a comment saying this is
  TabAtkins: fantasai and I agree with it. So the CSS WG is torn on
             the issue, so I don't know if we can make an official
             WG pronouncement.
  fantasai: Someone will object in either case.
  <zcorpan> glazou: pls file an issue on html
  <glazou> I will
  <zcorpan> ty

  glazou: Let me add one thing. You seem to have been involved a bit
          in this, correct?
  glazou: Is there anyone in this WG that was involved?
  TabAtkins: I suggested it and fantasai supported it and we argued
             for it in the HTML group.
  glazou: I'm surprised that you're supporting such a thing.
  TabAtkins: You've said you disagree.
  glazou: I thought we were trying to make things the right way and
          we're reusing something not made for that.
  fantasai: It is made for that. The list item is a box that is a
            block box and generates a marker box. The name is tied
            to list, but the meaning is the right behavior.
  glazou: There is difference on the marker position that is allowed
          on list items and not this. Marker is related to the list
  TabAtkins: No it's not. There has never been a list in CSS; it's
             list items that sit in a block box, but we never invoke
             a parent.
  fantasai: It's just the same as 'display: table/table-cell', which
            are named after their use in presenting data tables, but
            don't confer that semantic either.
  <ChrisL> I agree with fantasai, css display as table can be used
           on non tables so this can be used on elements which are
           not list items
  glazou: Rename list item, then. This is ugly.
  TabAtkins: It's an informative update, please feel free to yell at

  ChrisL: I agree with fantasai that you can style any element as a
          table if you choose to. So that this is being used where
          the element isn't a list item but is being styled like one
          is fine.
  leaverou: Is there any elements styled as tables by default?
  <zcorpan> nope
  TabAtkins: Only tables.
  leaverou: Exactly.
  TabAtkins: If there was any other grid-like elements in HTML they
             may get grid-like elements.
  Florian: I would expect this in a book by leaverou about neat CSS
           tricks, not in the UA style sheet.
  fantasai: This does everything that you would expect it to do and
            that we want it to do: it generates a block box and a
            ::marker box and lets you style them and reposition the
            marker or suppress it. List item contains all the things
            we want. It totally makes sense for using this and not
            making a new feature though the name is odd.
  Florian: So maybe send a mail to the CSS WG suggesting a new name.

  Rossen: So, TabAtkins and fantasai are you looking for a WG
  TabAtkins: No, it's an update. It was HTML's decision. If you
             object tell them. You no know what's going on.
  <glazou> I will
  Rossen: If you want to yell at the HTML group, feel free.

grid-template shorthand

  Rossen: Should the grid-template shorthand collapse into the grid
  TabAtkins: I'm fine with this.

  Rossen: One thing I wanted to check, would that mean that any
          ascii syntax accepted for grid-template would be accepted
          by the grid shortcut? So any syntax can be grid-template
  TabAtkins: Correct. Grid shorthand says whatever grid-template
  Rossen: So grid: blah blah; is a valid syntax.
  TabAtkins: It has been for a long time. We have grid which has
             better resetting we may as well drop grid-template.
  Rossen: I see.
  <gregwhitworth> for web devs I prefer them using something that
                  resets stuff based on the flex issues.
  fantasai: Grid template syntax is a subset of grid syntax, so
            we're making it simpler to authors. Otherwise you'd have
            to choose based on reset of invisible things. That's
            going to be confusing for authors.
  Florian: I've already been confused by this :)
  Rossen: Yeah, I guess I wouldn't have objections to this.

  Rossen: Any other implementors on the call that would have a
  Rossen: Doesn't sound like it.
  Rossen: So you're going to fold the grid-template into the grid
  TabAtkins: We'll move the syntax into grid, yes.
  Rossen: Simplification is goodness. Objections?

  RESOLVED: Remove the grid-template shorthand and fold it into the
            grid shorthand.

Events for FontFaceSet

  Rossen: There was one last topic, but we have one minute.
  Rossen: It was just the topic on font faces. There was a question
          on what implementors think about it. On our end we're fine.
          I think this is for people currently supporting it.
  TabAtkins: The only person that has said something is Myles. I
             want to hear from FF and our implementor. I'm fine if
             other people are fine.
  <zcorpan> i think it's not shipped by anyone yet, is it
  <zcorpan> ?

  Rossen: Anyone capable of talking about this?
  TabAtkins: The relevant implementors are HeyCam and Kenji on our
  Rossen: Let's push to next week or maybe this is on mailing list
          this week.


  fantasai: Are we publishing on CSS OM some time?
  <fantasai> https://www.w3.org/TR/cssom/ 2013
  Rossen: We resolved on that in Sapporo.
  Rossen: zcorpan?
  zcorpan: Sure, we can.
  zcorpan: I've made some small changes, but we can publish.
  Rossen: It's top of hour and people need to peel off.
  fantasai: We were going through a section of CSS OM a month so we
            should set that schedule. Ask zcorpan which section to
  Rossen: Will do.
  Rossen: Thanks everyone.
Received on Thursday, 3 March 2016 00:34:12 UTC

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