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

[CSSWG] Minutes Telecon 2016-05-04 [mediaqueries] [css-page] [css-scroll-snap]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 May 2016 19:39:48 -0400
Message-ID: <CADhPm3sP9gGrG+Y7AE8B=8Wk2HV95NY-998Rg_WO9nnFSQJp+w@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.

MQs should respond to page size

  - There was agreement on the mailing list that media queries
      should respond to page sizes set in @page, but Florian wanted
      more guidance with what direction the proposed text should take.
  - Florian suggested that he could write the text to allow the
      property function similar to @viewport.
      - There was some uncertainty as to if this was the right
          approach, though several people were also in favor of it.
  - Florian will write proposed text including use cases and bring
      it back to the group.

propdef tables for shorthands

  - RESOLVED: Adopt the proposed convention for propdef tables for
              shorthands (proposal here:

Snap Points

  - 'proximity' and 'mandatory' still need to be renamed, but the
      group didn't like 'strict' and 'loose'.
  - Though originally the topic was around the snap alignment
      container, there were really three items that need to be named:
      A. a box that has a scrollbar
      B. the viewport of the scroll container
      C. the snapping area of the viewport of the scroll container
          (i.e. viewport minus scroll-snap-padding)
  - RESOLVED: A div with overflow that's not visible is a 'scroll
  - RESOLVED: B (the viewport of the scroll container) is a
              scrollport. C (the snapping area of the viewport of
              the scroll container) is a snapport.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016May/0022.html

  Rossen Atanassov
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  François Remy
  Jen Simmons
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Tab Atkins
  Tantek Çelik
  Michael Miller

Scribe: dael

MQs should respond to page size

  astearns: Let's get started.
  astearns: Just to make sure, ChrisL are you on for the first
            topic? [silence]
  astearns: Okay.

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Apr/0352.html
  Florian: There is a statement in the paged media spec, css page
           spec, together with an issue saying it may be wrong that
           MQ don't respond to the size of the page. That's very
  Florian: On the ML we agreed it would be good to have it work, but
           we need to define what "it work" means. I can write a
           proposal, but I want a sense of what we're trying to
  Florian: There's two levels of what to achieve. The first, which
           is important, is if you have an unqualified @page rule
           and inside you size the page, if you have a MQ query
           against width or height it should take that into account.
  Florian: Second level, less critical. Inside that MQ that has
           adjusted based on the @page size, can you adjust the page
           again? How many levels do we go after. An interesting
           thing we can try and do is you query for @media maxwidth
           = 5inches and inside you do @page size=5 inches have a
           boundary on how small the page can get.
  Florian: Do we want to do that as well? Some level of nesting for
           @page and @media? Or is that not important?

  Rossen: Is there a use case?
  Florian: In general, or level 2?
  Rossen: The circular reference?
  Florian: It's because we have to write a definition. In general
           it's the same situation with @viewport. If you have a
           responsive design that can shrink to a point and after a
           point it would be too squished. Dealing with that case
           seems as reasonable with printing
  Rossen: Why should this be an exemption? This problem is nothing
          new. At some point you have to resolve if the container or
          content has preference on setting size. If you have a
          container, a regular div, that changes in size and inside
          of it you have a flexbox that wants to be as big as
          possible, we have a mechanism to resolve by saying at the
          end of the day the container will have the size it wants
          and the content inside may take it into consideration or
  Rossen: In no case do we have the content dictating what the final
          container size is.
  Florian: Not quite. With @viewport you can have a MQ that says if
           the screen gets smaller than a size then don't do it. We
           have it on @viewport but it would be worth it on @page.
  Rossen: Is there currently a use case to solve, or just going for
          theoretical completeness? And if there is a use case
          should it be different than other layout constraints.
  Florian: I think we're just repeating...I'm not sure how to
           rephrase. Let's do the queue.

  glazou: To address the beginning question, I support the original
          and the extra. It's implemented in the wild and people are
          using it for @viewport so people will use it for print and
          pages. So I'm in favor of both things.

  <dbaron> I still don't understand how @page interacts with actual
           sizes of paper...

  MaRakow: I was going to say I understand what Florian is talking
           about for @viewport, but even for that it's a confusing
           set of logic. It would probably be easier to look at this
           in a concrete form, a draft or examples. I'm familiar
           with viewport, but I'm not sure about items unique to
  Florian: I was kind of asking before I wrote so that I spent time
           writing what the group wants. If I need to write so we
           can develop consensus I can do that.
  MaRakow: I think it's more obvious with viewport where there's one
           viewport instead of multiple page sizes and the like.
  Florian: What we've been saying is this only is non-qualified
           @page which applies to all pages. If some pages have
           different sizes, that doesn't count. MQ respond to the
           unqualified page. If you change that size it should
           respond. If you only change page 37 the MQ can't answer
           to just that in any way I can think of.

  Florian: Trying to answer Rossen. I'm not trying to be different.
           I'm proposing same as @viewport.
  Florian: The @viewport mechanism works both ways. Either you're a
           typical mobile UI which by default sets constraints or
           you can use it to add constraints to a viewport where you
           can go up and down but don't go too small because my
           layout can't handle that. I'm suggesting we carry that
           over. It's not required, but nice to have. It vaguely
           matches what Chrome has now.
  <dbaron> FWIW, I'm a bit hesitant about the second half
  <dbaron> though I don't feel like I really understand the issue

  astearns: It sounds tome there's general agreement to have
            something like @viewport for @page. So I think you
            should write more details so we can argue over them.
  Florian: Is it okay if I make a pull request and post about that
           on the list?

  <BradK> Page3 editors draft already allows @page inside @media

  plinss: I'm not convinced it's the right way to go. It seems the
          MQ should query the size it's being.
  Florian: Most of the time you print to PDF and the size of the
           page is the one you ask for. All MQ designed for screen
           fail as soon as you print.
  plinss: I'm not sure I get the second point. There's aspects of
          how @viewport works that seem broken to me that I'd like
          to fix. It's more than I can load into my head right now,
          but we can talk offline. Solving the PDF would be better
          from a new mechanism to say your desired page size.
  Florian: But @page with size says the size of the page you want.
  fantasai: It is the syntax designed. It's unfortunate. We didn't
            sort out how to handle if your parent has three sizes
            how to you express a preference.
  Florian: I can make a proposal based off of what we have discussed
           and we can re-discuss after that.
  astearns: Please add the PDF case and any other use case you're
            solving to what you propose.
  Florian: Sure.
  ACTION Florian write a proposal for @page with use cases
  <trackbot> Created ACTION-767

  astearns: Next topic is "Bug in nested counter scopes" and
            TabAtkins is not here.
  astearns: Anyone else have an opinion?
  astearns: Or do we table for now?

  ChrisL: I'm here now.
  astearns: We decided to do color next week because smfr dropped
            and Ric is coming next week. So maybe Wednesday next week.
  ChrisL: And that's more MQ color than CSS4 Color?
  astearns: Yes. MQ and spec higher gamut colors.

propdef tables for shorthands

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0007.html
  fantasai: Basically I was going through some specs where we're
            using shorthand and we have a convention of seeing the
            property to get the shorthand. In a lot of cases they
            have a lot of the same information. I thought it would
            be nice to put that info in the propdef table. That
            would be useful as we encourage people to use the
            shorthands more. scroll-snap-padding and the like where
            we add more longhands to deal with physical and logical
  fantasai: For one spec we deferred longhands to an appendix and
            put the shorthands at the top.
  astearns: So the proposal is only when things can be a single
  fantasai: Yes.

  dbaron: I think this is mostly okay as long as whatever defines
          the concepts in the propdef tables says if a shorthand
          defines one of these and disagrees with a longhand that's
          an error in the spec. If we have something explicit where
          if a spec does that there's a mistake.
  fantasai: I'm down with that. I'm not sure where we have something
            that defines the propdef tables, but I'm fine with it.
  Florian: I'm not sure on which side of the error we should do. If
           it contradicts itself there's an error. I'm not sure if
           we should say it's on the shorthand or longhand.
  fantasai: I agree. It's not clear which is correct, there's an
            error that needs to be fixed.
  <leaverou> I wonder if these could be marked up as shorthands and
             bikeshed would automatically generate the right propdef

  astearns: Anyone opposed to this convention?
  Florian: One question: is this going forward or do we rework
  fantasai: Going forward and as people update specs we should
            update. We don't have to go back and fix everything
  Florian: That makes sense to me. And encouraging people to use
           things right is a good point for me.
  Florian: Getting people's attention where it should be sounds like
           a good idea.
  <jensimmons> +1 — anything that makes the specs more usable for
               general authors is :)

  RESOLVED: adopt the proposed convention for propdef tables for


Rename keywords 'proximity' and 'mandatory'

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0006.html
  fantasai: Someone, I think astearns raised this issue being that
            they're grammatically inconsistent. No one had a good
            proposal, but we do have something that takes 'strict'
            and 'loose'
  MaRakow: My main concern is that they're less indicative of what
           they do. near and always gave more indication of what
           they're trying to do. I feel lukewarm on everything
           proposed, but those are easier to spell.
  leaverou: 'Strict' and 'loose' are not self-evident to me. I agree
            we need to resolve the grammar.
  * glazou agrees with Lea
  ??: I agree
  Florian: They're long words, but they work. I'm okay with 'strict'
           and 'loose', but I'm not sure they're better.
  astearns: Sounds like we need to keep searching for terms. I agree
            none of the proposals are right.

Snap alignment container (concept name)

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0000.html
  fantasai: There have been a handful of options. 'scroll snap port'
            and 'snap window' came on the list. This is the area of
            the viewport that we're snapping boxes into. It's the
            viewport scroll snap padding.
  MaRakow: I like 'snap box' a lot.
  astearns: I'm not that happy with 'snap box' because it's a
            category error. When I think of snapping boxes I'm
            thinking of the page layout, not the window in which
            viewing the content.
  Rossen: What do you mean by window? a div with a scrollbar?
  fantasai: There's the area representing the box and the area
            representing region of the viewport. They're snapping
            together. 'snap box' is too generic. It doesn't indicate
            if it's the content or viewport part?
  Rossen: So I have a bit with a scrollbar and something scrolling
          inside? What's the viewport.
  fantasai: Snap window is the scroller's viewport.
  Rossen: So every view defines a viewport.
  fantasai: Yes. I don't know what you want to call it, but the
            scrollers viewport has the window.
  Rossen: It's a box with a scrollbar on it and a bunch of boxes
          moving beneath it.
  fantasai: That needs a name. You can call it whatever, but for now
            let's call it the scrollport. The part of the scrollport
            being snapped to needs a name.

  MaRakow: To clarify, on 'snap box' the way it's controlled and
           adjusted is similar to margin box etc. I see you need to
           distinguish scroller box vs contained elements. Maybe
           there's something with meaning. I like usage of box
           because it's similar to how you're controlling the box. I
           like that idea.
  Florian: If we call everything a box, box doesn't mean anything.
  fantasai: A box is similar concept to an element, but we also use
            margin box etc. It's overloaded and I don't want to
            overload it more. It's a rectangle. You can't fragment
            the box. So I think it would be better not to use box.
  MaRakow: The language we've been using seems to have been aligning
           boxes to boxes. It feels natural.
  Florian: Everything in CSS is boxes, but we want a word not a

  leaverou: Window is overloaded from JS, so it's a minor objection,
            as I'm not sure any authors will be confused due to JS.
  Rossen: I had the same. Window has a meaning in many places.

  Florian: Though I don't think we had consensus it's a great name,
           every time we say 'scroll port' people know what it means.
           I think it's stable so we can derive from it. 'scroll
           snap point'. I'm not sure it's lovely, but it wouldn't be
           confused so I'm for it.

  astearns: It sounds like there are two options, one with port and
            one with box. Or can we go with port.
  leaverou: What's wrong with 'snap container'?
  fantasai: Container tends to be a box in a more structured thing.
            I would consider it to be the scrolling element itself.
            In our version we used 'scroll snap container' to refer
            to the scroll container capturing snap point.
  fantasai: It's a rectangle within that. It has a thing and needs
  leaverou: I think I misunderstood. Isn't the scroll container also
            the thing trying to define?

  fantasai: We need a bunch of names.
  <MaRakow> https://drafts.csswg.org/css-snappoints/#definitions
  <fantasai> a) Need a name for a box that has a scrollbar
  leaverou: THat's a scroll container.
  <MaRakow> scroll container +1
  fantasai: That or 'scrollable box'. I'm happy with either, but
            lets start with that. A div with overflow that's not
            visible, what's that thing.
  leaverou: scroll container.

  RESOLVED: A div with overflow that's not visible is a 'scroll

  fantasai: Yep. We need to get overflow in sync with this.
  fantasai: Next concept. The viewport of the scroll container.
  <fantasai> e.g. @viewport doesn't apply to the scroll container
             (unless it's the root element)
  leaverou: right...
  Florian: scroll-port
  MaRakow: I think it's viewport
  Florian: Earlier Rossen said this is a thing with nothing special.
           Viewport has special characteristics. I'm not happy with
           overloading it. It may be we at some point make them able
           to do the same things, but not now. So, 'scroll port'.
  <jensimmons> IMO, I would not call it a viewport. That’s already a
               complex concept that people struggle to understand.
  MaRakow: It sounds bad, though. viewport is familiar.
  fantasai: @viewport and meta rule don't apply to this. It does
            make sense that they're distinct.
  fantasai: So I think it makes sense to have a separate term.

  Rossen: I think it's clear what leaverou and jensimmons think. I
          see jensimmons opposes viewport name. It would be great to
          hear from the devs.
  leaverou: I can see reasons...
  <jensimmons> scrollport or snaport would hint to people — “hey
               it’s kinda similar, but not. Check this out… it’s a *-
  fantasai: We have the viewport units that reference the root
            viewport. There are several things in CSS named after
            the viewport that don't have any relation to these
            scroll containers.
  leaverou: I can see why we could do 'adjective viewport', but I
            also agree it could be confusing. I'm not quite sure.
  jensimmons: I don't have a lot to say because I'm trying to
              understand snap-points, but viewport is a huge
              important concept and I has a name. fooport indicates
              similar without the same.
  <BradK> +1 Jensimmons
  leaverou: I'm not sure about inventing names. 'scroll port' hides
            the view port so it doesn't sound similar.
  ChrisL: The port thing in viewport means a type of port that has a
          subregion. 'snap port' doesn't inherit from viewport. It's
          in the snap area.
  <jensimmons> +1 on that
  Florian: We don't have many ports in CSS. If you get the port you
           don't get confused.

  leaverou: If we invent words in CSS it gets confusing like
  <ChrisL> fragmentainer is an *awesome* neologism
  <dauwhe> fragmentainer has been useful, I think
  Florian: Fragmentainer isn't common, but it's clear.
  <fantasai> "port - n. an opening in the side or other exterior
             part of a ship for admitting air and light or for
             taking on cargo. "
  <BradK> The snapping area of a scroll port should be the snap port
  astearns: So this is a word we're inventing for the spec. We're
            inventing instead of a longer phrase through the spec.
  leaverou: The words leak into tutorials.
  ChrisL: That's better than overloading a word.
  Florian: We invent words all the time. Like flexbox.
  leaverou: Flexbox is a contraction of "flexible box" though.
  ChrisL: In the same way style-space-sheet is a lot of things, but
          stylesheet is a specific subclass of thing.
  MaRakow: The viewport terminology, people are confused because we
           have too ambiguated a definition. We have talked about
           splitting layout and visual viewport and when we get to
           that it's clear this is the visual viewport.
  MaRakow: I think if we get that cleared up visual is the same as
           what we're talking about where an element scrolling is
           top-level scrolling.
  leaverou: sub viewport?
  Florian: I think this is a scroll port.

  fantasai: We're on b.
  <fantasai> b) the viewport of the scroll container
  <fantasai> b.1 - scrollport
  <fantasai> b.2 - visual viewport of the scroll container
  fantasai: Proposals on the table ^
  fantasai: And we will get to c.
  <fantasai> c) the snapping area of the viewport of the scroll
             container (i.e. viewport minus scroll-snap-padding)

  <BradK> Isn't scrollport already in common use?
  <MaRakow> @BradK no
  * BradK Googled "CSS scrollport". 2,620 results.
  <MaRakow> @BradK that's exactly how many times it's been said in
            this conversation alone ;-)

  leaverou: visual viewport of the scroll container is too long. It
            could be scroll container viewport
  fantasai: visual viewport
  leaverou: Is there a not visual viewport?
  Florian: Yes.
  <Florian> SCROLL container visual viewPORT = SCROLLPORT
  MaRakow: You don't have to say the whole name every time. You say
           the visual viewport after the first time.
  dbaron: In the original email in the agenda it is drawing a
          distinction between the snapping thing and the scrolling
  fantasai: Yes.
  Florian: That's the c thing. We're on b.
  Florian: We're trying to name the thing with an offset. The offset
           is FROM something we also don't have a name for.

  astearns: Is b or c more likely to leak out?
  fantasai: I think they'll both be common. b isn't specific to
            scroll snap spec. It'll be in overflow and other specs;
            probably transforms.
  fantasai: There's a number of things that are distinct between top
            level viewport effected by @viewport rules. They don't
            apply to these scroll ports. We'll want to use these
            terms to define differences. So it'll definitely be in
            scroll snap and overflow.
  fantasai: C is only for scroll snap.
  <jensimmons> I suggest figuring them out together. They’ll work
               together in people’s understanding.
  <jensimmons> A: scroll container. B: scrollport. C: snapport.
  astearns: I propose we go with what jensimmons put in IRC. If c is
            specific to snapping it's a snap point.
  Florian: I'm with jensimmons
  <Florian> b : SCROLL container visual viewPORT = SCROLLPORT
  <Florian> c : SNAP area of the scroll container visual viewPORT =
  ???: Me too
  <dauwhe> +1 to jensimmons
  fantasai: I'm with jensimmons
  <BradK> +1 Jensimmons

  <dbaron> What's the difference between A and B?
  astearns: Anyone object?
  <ChrisL> +1
  <leaverou> +1, they do work well together
  BradK: Do we use hyphens?
  fantasai: I would go with no.
  fantasai: A is the css box that has overflow other than visible.
  fantasai: B is the viewport of the scroll container.
  dbaron: Okay.
  astearns: So dbaron are you okay with this term?
  dbaron: Is A a box?
  fantasai: Yes.
  Florian: Is it an element?
  fantasai: It's a box in the same way a flex container is a box and
            a fragment container is a box.
  fantasai: It's good to maintain the invariant that a container is
            a box.
  <leaverou> Although I'm convinced about scrollport/snappport now,
             note that even fantasai described it as "the viewport
             area of the scroll container" right now to get whoever
             asked to understand.
  Florian: How is it not an element?
  Rossen: Elements make boxes.
  fantasai: I'll sent a link.
  <fantasai> https://www.w3.org/TR/css-display-3/#intro
  Florian: I'm just not sure why it's one or the other.
  Rossen: Elements aren't visual, boxes are.
  dbaron: A is a box and B and C are rectangles.
  fantasai: Yes.
  dbaron: Okay.

  astearns: Objections to A: scroll container. B: scrollport. C:

  RESOLVED: B: scrollport. C: snapport.
  <fantasai> Yay!

  astearns: There was one item that Rego wanted to talk about, but I
            don't think we have time.
  fantasai: We need to do that one at the F2F.
  astearns: I was going to suggest it for the F2F agenda.
  astearns: Anything else anyone wants to bring up?


  Rossen: Quick one on TPAC. I know dbaron and Florian are on call.
          Please look at proposed time and date for Houdini and make
          sure it's okay with you before we settle the arrangements.
  Florian: What's the link?
  Rossen: I'll dig it up, it's in the Houdini ML. It' a reply to
          your e-mail.
  Bert: Isn't it too late to decide dates? I think the schedule and
        room is published.
  Rossen: I just received an e-mail that I was hoping we weren't too
  ChrisL: The date was the 15th. That was if we're meeting or not.
          There's no room allocations.
  Florian: Most likely I won't be able to avoid some conflicts.
           Schedule it and I'll attend what I can.
  astearns: Please do keep adding things to the agenda. I think
            that's it for the call. Thanks everyone!
Received on Wednesday, 4 May 2016 23:47:25 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:59 UTC