Robert Hogan | 31 Jul 20:19 2015

[css 2.2] [tables] Baseline on empty table cells

Hi there,

We've hit a bug in Blink while trying to confirm to It comes down to what height we should give the second cell box in: 

<!DOCTYPE html> <style> .cell{ height:453px; vertical-align: baseline; } </style> <table> <td class="cell"> An empty cell even if it has height should set the baseline for the row. This text should be at the top of the page. </td> <td class="cell"> </td> </table>

Everyone gives it a height of 453px but only FF and Blink currently put the baseline on the bottom of the cell. (If you put an empty <div> in the second cell then FF puts the baseline at the top (i.e. below top border and padding). I'm guessing it does this because the empty div has an empty linebox.)

Turning to the spec: "The baseline of a cell is the baseline of the first in-flow line box in the cell, or the first in-flow table-row in the cell, whichever comes first. If there is no such line box or table-row, the baseline is the bottom of content edge of the cell box." So with a height of 453px, it looks like the baseline should be down at the bottom of the cell like Blink and FF do.

But it's very hard to get away from : "The table cell's 'height' property can influence the height of the row (see above), but it does not increase the height of the cell box." (This is a recentish addition,

Accepting that the bottom content edge of the cell is not determined by the computed height of the cell means that is wrong. It looks like that test and FF (and us until we revert) are wrong. 

Is there something I'm missing?


John Drinkwater | 31 Jul 14:03 2015

[css-pseudo] Proposal: Add ‘filter’ property to styling highlights


Was hopeful I could use filter: invert(100%) with text selection, but 
noticed it is not part of the properties allowed for this selector.

ISSUE 3 notes there may be further properties wanted for this, so I 
suggest that filter be accepted.

Have looked over the current supported filter values, and my initial 
thought is that none of them go against the present limitations set on 
highlighting properties.



John ‘[Beta]’ Drinkwater        |      john <at>     |

Myles C. Maxfield | 30 Jul 23:42 2015

Proposal: add a "small-caps" value to "font-synthesis"


The font-synthesis CSS property is a way for authors to opt-out of synthesized font traits such as bold or
italics. It seems reasonable to add small-caps to this set. Using "font-synthesis: small-caps;" would
specify that, if a small-caps font cannot be found, to use a non-small-caps font without synthesizing
smaller, capital, text.

What are your thoughts?


Daniel Holbert | 30 Jul 22:05 2015

[css-containment] What does "contain:layout" do on table parts?

Hi www-style (Tab in particular),

What should happen if someone sets "contain:layout" on a table-part? (An
element with one of the various "display: table-*" values from )

For example, on a row:
 <table border>
   <tr style="contain:layout"><td>First Row</td></tr>
   <tr><td>Second Row</td></tr>

The spec just says the following:
 # When laying out the containing element, it must be
 # treated as having no contents. After layout of the
 # element is complete, its contents must then be laid
 # out into the containing element’s resolved size.

Is this really what we want to happen for a table-row? I can imagine
that in my example above, this would meant the <tr> would have 0 height,
and its cell would overflow the second row (with beveled borders
behaving a bit oddly...)  I suppose we could do something similar for
table and table-row-group as well. Is that what's supposed to happen?

I tend to think "contain:layout" doesn't really make sense on most table
parts, except maaaybe on "display:table-cell"...


Dael Jackson | 30 Jul 13:47 2015

[CSSWG] Minutes Telecon 2015-07-29

Publishing Grid Layout

  - RESOLVED: Publish updated WD of Grid layout

CSS Break

  - There was still no consensus on what to do with the name 'any',
      though it was agreed to be troublesome. Possible solutions
      - Accept the name
      - Rename it
      - Push it to level 4
      - Change 'always' to 'all' so that 'any' would make more sense
  - There was no consensus so discussion will continue on the
      mailing list

Percent resolution for abspos vs inflow grid items

  - As this issue is dependent on a F2F topic, a final decision will
      hold off until the Paris meeting.

Interaction between overflow-x and -y

  - There were three proposed solutions to address overflow: clip
      - A) "overflow: clip" is a paint only operation, it does not
          (on its own) create a BFC, and if "contain" is not
          "paint", you can have "overflow-x:clip" in one dimension
          and "overflow-y:visible" (and vice versa). Amend the
          definition of "resize" and "text-overflow" (and anything
          else that depends on "overflow") to deal with the new
          possibility of being visible in one dimension only.
      - B) Rename to "overflow: hidden no-scroll". It creates a BFC.
          If you specify it in one dimension only and leave the
          other visible, the visible one computes to auto.
      - C) Don't introduce a new value to overflow, make
          "contain:paint" cause "overflow:visible" to compute to
          "overflow:hidden", and implement heuristics to detect when
          browsers should avoid allocating the resources needed to
          do the scrolling.
  - The group first discussed the merits of A before deciding to
      rule it out completely.
  - C seemed like the ideal case, but browsers weren't capable of it
      yet, so the group decided on B.
  - RESOLVED: pick option B behavior, defer naming to editors,
              everyone complains if they pick something bad
  - There was a mini bikeshedding session after the telecon on IRC
      where 'clip' and 'none' seemed to be the most favored, but the
      decision is still up in the air.


  Rossen Atanassov
  David Baron
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Michael Miller
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

  Sanja Bonic
  Adenilson Cavalcanti
  Dave Cramer

  scribe: dael

  plinss: Let's start. Please add your name to IRC so we know you're
          here if you haven't.
  plinss: Anything to add to the agenda?
  fantasai: Publish grid layout?
  plinss: Anything else?
  Florian: Just to mention I asked for a week to review the proposed
           prefixing policy, and I did send it, but it was only sent
           two minutes ago so there hasn't been time to reply
  <gregwhitworth> We read it, I forgot to send feedback
  <gregwhitworth> florian: my bad
  <Florian> gregwithworth: no problem: I'm the one sending 2 minutes
            before the deadline. Comments on this new mail

Publishing Grid Layout

  fantasai: TabAtkins and I made a bunch of edits to fold in
            resolutions for grid layout.
  <fantasai>  changes
  <Rossen> +1 on publishing
  fantasai: We tracked the comments for this cycle. There's a couple
            of open issues, but we want to publish a WD to update
            what's out there and we wanted confirmation from Rossen
            specifically but the rest of the group too.
  Rossen: I went over your changes and I'm fully supportive of
          publishing a new WD.
  fantasai: If anyone wants more time to look that's fine, but if
            you want to publish next week that's fine too. We want
            it out in the next few weeks and to keep working.
  plinss: Any objections?

  RESOLVED: Publish updated WD of Grid layout

  fantasai: I'll aim to publish next Thursday.

CSS Break

  plinss: Looks like we wanted to get back to that this week.
  fantasai: Two was dropping cloned margins at the
            breaks and the other was naming of any. I can't remember
            if we closed on the first issue.
  Rossen: I thought we resolved on dropping margins and the name was
          up to debate, but I didn't hear anything better than 'any'.
  fantasai: If we had 'all' and 'any' it would be clear, but since
            we have 'always' which doesn't make sense for multiple
            types of breaks...has anyone impl the unprefixed break
            other than Opera?
  Rossen: We have not.
  fantasai: I think Mozilla has not. Blink? Safari?
  <dbaron> I think Gecko still has only page-break-{before,after}
  smfr: I don't think webkit has.

  fantasai: Okay. So I think we've got several possibilities:
  <fantasai> 1. Change nothing
  <fantasai> 2. Come up with a different name for any
  <fantasai> 3. Change 'always' to 'all' and leave 'any' alone.
  Rossen: The last e-mail I replied I did summarize what we talked
          about for renaming 'any' and no one replied.
  fantasai: I think there's three things that makes sense [reads
            list above]
  fantasai: I think one person said 'any' for fragmentation
            container would be the deepest one. There was discussion
            on trying to convey we're trying to get the deepest, but
            no one had a good idea.
  fantasai: We don't have any good options to fix this, though I
            agree the current set is confusing.
  <SteveZ> How about Break:Nearest
  <fantasai> SteveZ, seems might be confusing with nearest box,
             element, breakpoint, something else in a lateral

  Florian: One path is to say now that we're having more types of
           fragmentation containers we can go through the use cases
           and see if always and any are right or if we need to
           change these things. It's not clear that these are the
           best way to do things. The possibility to call out which
           you want to break has been suggested a few times.
  Florian: Maybe we go through the use cases and see what's best for
  fantasai: I think that's fair.
  Florian: And while we do that include the things we haven't quite
           finished like overflow fragments in the latest
  fantasai: Yeah, as we do the thinking. One of the use cases is if
            you break the column or the page depending on if I'm in
            a column or a page.
  fantasai: Although if you require a column break and all you have
            is pages maybe you do that since a page is really just a
            single column. The mixing of fragmentation contexts is
            weird. I think we want named contexts, but we wanted to
            defer that level for now.
  <fantasai> until those mechanisms were more definite

  Florian: I understand wanting to defer, but since the design is
           not obviously the right one, it sounds worth doing.
           Especially with regions and fragmenting the level of
           nesting may change within the document and it becomes
           more important to be able to name because you can't just
           could third from the top.
  Rossen: This is true and it's what we've been talking about, but
          at level 1 we want to at least give the ability to break
          at first fragmenting level which will let authors have
          content into templates regardless of what the templates
          are made out of. When there is content that wants to avoid
          or break any fragmentainer, that's what the keyword is
          intended to do.
  Rossen: Yes, named breaks will be something we're working on for
          another level.
  Florian: What I'm trying to say is that, I don't want named breaks
           now, but once we have named breaks, I'm not sure if we
           still need 'any' or 'always', maybe one will be
  Rossen: Perhaps, but we don't want to stall the progress for now.
          Named breaks are moving to level 4 and for this level we
          have any.

  Rossen: If anyone has any better names or wants to change the any
          keyword you can respond to the e-mail or speak up now.
          Otherwise we'll move on.
  SteveZ: The problem I have with 'any' seems arbitrary. Like pick
          any fragmentainer you're in and break it. I suggested
  Rossen: That's what I suggested to. I've suggested 'nearest' or
          'closest' or 'first'. The way I think of the auto of
          breaking, the element that is requesting to be broken or
          not is looking inside out and it wants to declare its
          preference for the first or nearest fragmentainer.
  fantasai: What I'm afraid of with 'nearest' is if you have a
            region with a fixed height and it's 1 1/2 pages worth.
            If you're on the first page, the nearest break is the
            page break, not fragmentation.
  Florian: So in linear, not depth.
  <bradk> 'Nearest-ancestor'?
  fantasai: Yeah, I think that will be a point of confusion.
  Rossen: I don't disagree.
  fantasai: And 'deepest', it means break before the deepest element
            in the tree, next isn't something they think of. This is
            why I'm struggling to come up with something that
            reflects what's going on.
  SteveZ: Doesn't 'any' have the same problem?
  fantasai: I agree it's ambiguous. But at least it's not specific
            in a misleading way.
  SteveZ: It's unspecific in a misleading way.
  <Florian> closest-ancestor-fragmentainer
  <bradk> closest-ancestor-or-self-fragmentainer

  Rossen: Or we could drop this to level 4.
  fantasai: I'm okay with that.
  Rossen: Me too.
  Florian: One alternative is just call it 'break'. When you think
           of for and why loops, you break just one level.
  Rossen: The analogy of loops isn't appropriate. You can break in
          the parent loop. In fantasai's example you can break at
          the page.
  Florian: Yeah, loops don't nest that way.
  Rossen: Right.

  Rossen: I think the way I see it, we can live with 'any'. There is
          a somewhat good use case for having 'any' or 'nearest' or
          whatever we come up with. Or we can say this logic will be
          solved by name breaks in level 4.
  Florian: What was wrong with 'deepest'?
  fantasai: It would imply a location deep in the element tree.
            Authors don't have a concept of nested fragmentainers.
            It's not fundamental enough in CSS it wouldn't do. Most
            people want a page, column, or region break. There's no
            nesting, it's just three different things in parallel.
  Rossen: I agree with what you're saying. I don't think authors
          will think of more than one level of nesting. No one
          thinks their multi col will be printed and what happens
          where there's fixed height.
  fantasai: Most common is something just wants to break for the
            next chapter and they don't care about what type. You'll
            need named break for regions.
  Florian: You'll want to say "break regions or columns" or "break
           regions or pages". You have a set of things you want to
           break into. You won't be completely agnostic about I
           don't know how many things will be nested but I want a
           specific break.

  Rossen: It sounds like there wasn't much resistance for this to be
          in level 4.
  Rossen: Given that this is the only big outstanding issue, we
          might have to think hard about this one.
  <SteveZ> +1 for level 4
  fantasai: Yeah, but we still have the problem of the always value
            that's in multi col. I think there's a case of authors
            just wanting a break and they don't care about the type.
            That's basic.
  fantasai: I don't know. I guess we should move to the next topic.
  <SteveZ> I do not think "just Break Me" is clear if people have no
           knowledge of the nesting
  Florian: The only reason I don't want to move to level 4 is any
           and always will have to named as a pair, so we should
           have them together in the same level. They're a set and
           if we define one and push the other to the next level,
           we're locking ourselves in. Other than that I'm happy to
           push back.
  Florian: If we're stuck on 'always' anyway, sure, but if it's
           still on the table I'm not sure.
  Rossen: Some of the other proposals were always-any,
          always-deepest, always-all
  Rossen: That's another proposal on the table.
  Florian: break one
  <bradk> break: page region /* not column */
  <Florian> break: something / break: everything

  plinss: I'm not hearing us getting closer to a solution here.
  plinss: Suggestions to make this go forward?
  fantasai: I think push back to the mailing list for now.
  plinss: Let's do that and come back when there's new info.

Percent resolution for abspos vs inflow grid items

  Rossen: I believe this was waiting for Mozilla feedback, or was it
  fantasai: This was waiting for the F2F because TabAtkins wanted to
            reopen the whole thing.
  Rossen: This was for abspos, not just the general resolution. If I
          have a nested abspos item in a grid and that item happens
          to be laid out inside the grid, how does it resolve.
  Rossen: I believe we agreed it should be consistent and the abspos
          will resolve based on the grid. For that issue, I don't
          think there was push back by anyone, but we were waiting
          on someone to okay it.
  fantasai: I'm not sure I agree. If we revert to % being always
            against the width there's not issue. If we keep to top
            and bottom resolving against the height, then we have an
            abspos element that's positioned against the grid, it
            behaves like any other abspos element, just as if that
            grid container was any other kind of container. The
            expected behavior would be that the margins resolve the
            same as any other abspos context and that means going
            against width.
  Rossen: I don't buy it. It's saying if I have a grid item with
          nothing spec on it, it's the same as if the div was inside
          a block.
  * astearns this sounds like something for the face to face as well

  fantasai: Is an abspos element considered to be affected by the
            layout of the containment block, or is abspos a layout
  Rossen: It's the containing block.
  fantasai: It's just a rectangle. It's defined that was in CSS2.1
  Rossen: I know the definition, but as soon as we talk about grid
          and abspos items can be dependent on grid it's contextual.
          For level 3 and above it's more than a rectangle and it
          better be more or you're stuck in the 90s.
  * bkardell hmm, it seems like abspos is a layout mode
             conceptually to me :(

  Florian: What I'm hearing is that this is complex question and
           touches on what TabAtkins wanted to reopen.
  Rossen: There's nothing complicated about question.
  Rossen: If we're talking about abspos items only, that issue is
          very straightforward. If TabAtkins wants to reopen the %
          issue, we can do that at the F2F.
  Rossen: This is about items in a grid and has nothing to do with
          the bigger decision about percentages.
  * fantasai does not believe it is straightforward
  * bkardell believes fantasai in that it does not seem
             straightforward as it is presented as
  * antonp thinks the containing block should always be a rectangle;
           and that abspos is probably its own layout mode that's
           independent of the layout mode of its ancestors
  * dbaron agrees that containing block should be a box associated
           with an element rather than just a rectangle, but
           otherwise isn't really following
  * tantek is trying to remember very old conversations about
           containing block

  Rossen: So, what's going on? Are we discussing it or dropping by
          not discussing it.
  fantasai: Well.
  fantasai: The reason it has to do with the other issue, if we
            revert on the other issue, this becomes moot. Why it's
            not straightforward is you and other people have
            different conceptual ideas of abspos and until we decide
            if it's its own layout mode or not, we have to solve
            that conceptual problem before we can tackle this.
  <Florian> +1 to fantasai
  fantasai: So I don't think it's as straight forward as you think
            it is.
  Rossen: So do we want to leave it to the F2F?
  fantasai: I think that's a better idea.
  Rossen: Okay. I'm not the one who put the item on.
  fantasai: The chairs put it on after we decided last week to defer.
  plinss: Let's defer to the F2F.

  plinss: Next is grid OM issue
  fantasai: I said that this was answered on the ML. Did you not get
            that e-mail?
  plinss: I didn't. We can skip.
  <fantasai> email :

Interaction between overflow-x and -y

  [From the e-mail, the list options are:
    A) "overflow: clip" is a paint only operation, it does not (on
       its own) create a BFC, and if "contain" is not "paint", you
       can have "overflow-x:clip" in one dimension and
       "overflow-y:visible" (and vice versa). Amend the definition
       of "resize" and "text-overflow" (and anything else that
       depends on "overflow") to deal with the new possibility of
       being visible in one dimension only.
    B) Rename to "overflow: hidden no-scroll". It creates a BFC. If
       you specify it in one dimension only and leave the other
       visible, the visible one computes to auto.
    C) Don't introduce a new value to overflow, make "contain:paint"
       cause "overflow:visible" to compute to "overflow:hidden", and
       implement heuristics to detect when browsers should avoid
       allocating the resources needed to do the scrolling. ]

  Florian: It would be good to have TabAtkins. We can maybe talk a
           bit without him.
  Florian: Trying to summarize the current status. We have
           contain: paint which is to enable optimizations at the
           paint level. What it wants to do is establish a
           containing block. Also, to do clipping of anything that
           might overflow.
  Florian: And earlier version called this magic clipping. There are
           things that depend on this going through the overflow
           property. Text overflow and resize only work if overflow
           is not visible. TabAtkins and I proposed overflow: clip
           that does the same as hidden, but doesn't scroll. People
           said we should call it something else or we do something
           similar to clip path.
  <tantek> overflow and clip are so confusing both in name
           (including values) and function that I have to look it up
           every time. This despite having implemented it in IE5/Mac.
  <tantek> it's one of the worst parts of CSS 2 legacy.

  Florian: Another point that was raised was if we go hidden
           no-scroll is it needed? The browser can perhaps just
           detect that the scrolling isn't used and skip it to be
           more efficient. This is akin to will-change where if we
           assume a smart enough browser it can be done, but it
           doesn't seem like they'll be smart enough soon.
  Florian: We can say overflow: clip doesn't establish a BFC and you
           can have it only in one direction for contain: paint this
           may work, but I'm not happy about it because there are
           parts of CSS that assumes it's visible or there's a BFC.
  Florian: If a re-sizable thing isn't a BFC, suddenly margins
           collapse. It's a possibility.
  Florian: The other option, B, is to rename it and it's the same as
           hidden, but you don't get to scroll. C is contain: paint
           invokes the regular overflow hidden and browsers just
           need to get smart.
  Florian: I don't like A much, but if all browsers can convince
           each other to do the heuristic, C is good. TabAtkins
           doesn't think that's the case and he represents a
           browser, so if C won't do, I think B is what we should do.
  Florian: There's some side questions, but that's the meat of the
  * fantasai thinks that A makes the most sense

  smfr: What if you said that when contain: paint, it implies
        overflow: hidden, but in that scenario scrolling is
        disallowed. It would prevent scrolling and imply overflow:
  Florian: I guess it's okay unless you want scrolling because then
           you can't access it. Contain: paint provides other
           optimizations. If it's off screen, you know you don't
           have to paint so you can skip it. Say maybe you want it
           for that effect, but you're still interested in scrolling.
  smfr: Are you only concerned about where contain: paint and
        overflow: hidden are on the same element, or when the hidden
        is inside the contain?
  Florian: Not particularly the second. But overflow: hidden
           no-scroll allows for some optimized situations. contain:
           paint should be the superset of what you can get through
           overflow plus the rest so you have one switch that can
           turn it all on and it's fast. For speed it does work, but
           it reduces some things. Maybe it's a trade off and you
           can be fast or you can scroll.
  * bradk likes smfr's idea. Seems simpler.

  fantasai: I'm a little confused as to why A is so bad.
  fantasai: Not establishing a BFC is straight forward.
  Florian: On its own yes. But has the design of the resize property
           considered if it's fine to not be a BFC? Design hasn't
           considered it. So maybe that's okay for resize until you
           resize to 0. It's not obvious author-wise.
  fantasai: Resize right now only applies to elements with overflow
            not visible. So you would change it to also do clip.
            It's the same as visible and the only difference is you
            have this clip path and you may also want text overflow
            apply as an exception.
  Florian: That's why I don't like A. It could work, but you have to
           get into these little details. Are there other parts of
           other specs we've forgotten? There are these ripple
           effects and I'm not sure we have it under control.
  fantasai: I don't think there's many. text-overflow is this weird
            case because compat issues. I don't think there's that
            big of a problem with this kind of definition and I
            don't think the others are less complex.
  Florian: If that's all, it's not that bad. The other weird thing
           with A for not establish a BFC...I'm okay with an
           overflow: clip that doesn't effect margin collapsing, but
           that invisible floats can poke through feels weirder.
  <tantek> "invisible floats poking through" sounds very weird indeed
  Florian: I'm not objecting to A, it just feels weird.
  Rossen: It's definitely weird.
  fantasai: Yeah, that does seem weird.

  dbaron: We offer a whole bunch of other ways to do visual clipping.
          clip path, clip to some degree.
  fantasai: I don't have an objection either way, I just wanted to
  Florian: Between B and C, it's a matter of what browsers can do.
  * fantasai is really interested in what dbaron thinks of all this

  Rossen: Who wants A? Was that Mozilla?
  dbaron: I'd kind of like to see A. There are people that want to
          clip without the BFC.
  Florian: But wouldn't that be more appropriate to explore through
           clip and clip path instead of overflow?
  dbaron: Maybe.

  Florian: The play devil's advocate, there nice thing
           about A is that it opens the possibility to do overflow-x
           clip, ellipsis, and overflow-y visible. That seems useful
           regardless of contain: paint. That's how I would justify
  Florian: We previously resolved not to have that, so maybe it's
           not that strong a use case.
  smfr: I'm not convinced clipping only one axis is that useful and
        it would add to impl complexity.
  <gregwhitworth> I agree with smfr

  Rossen: So are we leaning B?
  Florian: I think you and smfr were against B and C.
  Rossen: We are not for A. Let's start there.
  Florian: So do we drop A?
  plinss: Anyone advocating for A?
  plinss: Okay, we'll ignore A.
  <fantasai> I think the main problem with A) is that contain: paint
             won't be able to use it, if floats outside of the
             element are not clipped
  <fantasai> (clipped layoutwise, I mean)
  <fantasai> (in addition to paintwise)
  * fantasai kinda prefers calling it overflow: clip anyway

  Florian: I think TabAtkins wants B. If everyone else wants B we
           can resolve. If not we need TabAtkins.
  Rossen: I'm okay with B.
  Rossen: B is the one that creates a BFC?
  Florian: You have a special value of overflow that creates a BFC
           and you can't scroll.
  smfr: Just like overflow: hidden, but you can't programmaticly
  Florian: Yes.
  smfr: It's making assumptions about impl details, but I can live
        with B.
  Rossen: B is more explicit for the users. It's declaring this
          won't scroll no matter what. If you're hidden is already
          declared. So B makes sense.

  Florian: Since you both pushed for C before, I think if you're
           okay with B we can resolve.
  Rossen: We can live with B. smfr?
  smfr: I feel like B is sort of making up for a historical mistake.
        We're adding complexity because we've got a previous mistake
        which is why I feel C is better.
  Rossen: I think you're right, but we are where we are and there
          are use cases where people want to prevent scrolling and
          they don't have that ability. They're making mistakes and
          now we're giving them an explicit way to say it's hidden
          because I don't want to scroll.
  smfr: I can live with B.

  Rossen: One bikeshed on B. Do we need the extra value, or can we
          make this an optional value to hidden?
  Florian: It's hidden no-scroll
  Rossen: I mistakenly heard it as hidden-no-scroll
  ChrisLilley: Yes, I wasn't clear on that.
  Florian: I wanted hidden no-scroll. I think it was minuted as
           hidden-no-scroll last time which might be the confusion.
           It's hidden no-scroll.
  Rossen: Okay, then we have no problem.

  smfr: Then if we use it on one axis, the other computes to auto?
  Florian: Yeah.
  fantasai: I think it would be easier to, as an author, pick one of
            these four options instead of one of these three and
            maybe a flag.
  <smfr> yeah what does overflow: scroll no-scroll do?
  Rossen: Is that true? I can see cases where people may or may not
          want to allow you to scroll the content given some
  fantasai: So you're suggesting we have no-scroll as an option on
  Rossen: To anything that's scrollable.
  Florian: To me it's a flag on hidden only.
  Rossen: I'm trying to figure out if there are other use cases we
          could cover. I can see forms where based on some form
          validation you might not want to let people scroll down.
  fantasai: It's an interesting point, but I'd like to keep to a
            single value property unless there's a really compelling
  Florian: The space instead of hyphen was to make it clear that
           it's a variant.
  fantasai: I'm not sure that tie in is necessary. Anything other
            than visible makes a BFC.
  Florian: Clip confused people, so I'd rather not that.
  fantasai: So another word. But it doesn't have to be connected to
            hidden. It's just here's your four values, pick one. It
            doesn't have to look like an extended variant. Authors
            might want to switch from hidden to this.
  <ChrisLilley> overflow: (push) and overflow (pop)
  Florian: So let's pick option B, defer naming to editors, everyone
           complains if we pick something bad.

  RESOLVED: pick option B behavior, defer naming to editors,
            everyone complains if they pick something bad

  Florian: Another question is if you set a value other than visible
           on one axis and leave the other unset and then you set
           contain: paint, the rules of computed value on overflow,
           if you have visible in one direction and not the other
           it's visible. We have different things trying to change
           the visible, but which acts first? I'd say it goes to
           auto and if the authors want something we can make it
  plinss: We're past the hour.

  fantasai: If anyone wants to do an apt share for Paris tell me now
            so I can find space for the number of people.
  Florian: I have 2 answers including mine. Is that what you have?
  fantasai: Yeah.

  plinss: Thanks everyone. Talk to you next week.

  <Florian> anybody interested in a mini bikeshed? "hidden
            no-scroll" "hidden-no-scroll" "none" "cut"
  * fantasai is against the first two for being too damn long to type
  <bradk> hidden-stuck
  <Florian> the second one looks like a long name because we
            couldn't find a name, so I don't like it. The first one,
            despite being almost the same, looks like a short name
            with a switch, and I'm ok with that. But yeah, it's
            still long.
  <Florian> "none" might be fine. It's even shorter than hidden,
            which means people might start using it just to save
            some typing and didn't actually need the scrolling.
  <Florian> (saving resources for everybody)
  <fantasai> I'd prefer a word that captures the fact that stuff is
             not visible if it overflows
  <fantasai> none just means "there is no overflow"
  <fantasai> Does that mean it got clipped? Or does that mean we
             made the box bigger so that it doesn't overflow? ;)
  <Florian> made the font smaller
  <fantasai> :)
  <Florian> or the author less verbose

  <bradk> 'none' is cool, but will confuse new learners, who have to
          try to understand the difference between that and 'hidden'.
  <fantasai> 'discard'?
  <antonp> fwiw I quite like "none"
  <Florian> new learners would pick none, which is good, since they
            almost never want the scroll part of hidden.
  <bradk> But I guess that's a problem regardless.
  <antonp> "hidden" quite nicely describes the current behaviour I
           think, since it really is there, but hidden
  <Florian> discard might be ok, but I'm worried about confusion
            with the fragmentation of overflow property/values
  <bradk> So far, I like 'none' best

  <antonp> None implies it's not there, which indeed it isn't, to
           all intents and purposes.
  <fantasai> actually, is that true?
  <fantasai> if there are two lines of content
  <fantasai> and they are too long to fit
  <fantasai> and so get clipped by this value
  <fantasai> and I select from the first to the middle of the second
  <fantasai> have I selected the text that is clipped?
  <fantasai> Will it get copied?
  <fantasai> I think it will
  <antonp> hmm, ok, good point
  <fantasai> So discard isn't good either

  * fantasai really thinks clip is the best
  * fantasai can't remember why it's bad
  <Florian> that rules out discard, but maybe not none (although
            your other concern stays)
  <Florian> clip is what I started with, but then half the WG got
            onto "but then why doesn't it do the same as the clip
            property, and skip establishing a BFC". Or at least that
            was how I understood the feedback
  <Florian> I was happy with clip until it seemed to confuse people.

  * antonp wonders how clip (property) behaves with regard to
           fantasai's select-and-copy use case
  <fantasai> no effect
  <fantasai> it's just a painting level thing
  <Florian> overflow: this-is-not-the-content-you-re-looking-for
  <Florian> it's still there, but you don't notice it
  <antonp> ok, that's what I imagined
  <Florian> (sorry)

  <fantasai> Florian: Were people actually confused, or was it just
             "but this is another possible interpretation that we
             need to consider"
  <fantasai> ?
  <Florian> fantasai: not sure.
  <fantasai> Florian: Particularly given Mozilla implements the A)
             behavior, I think any name you'd choose would bring up
             the same question
  <Florian> If we go for clip, that's less work for me, since the
            spec is already that way :) But I kind of like 'none'
            too now.
  <Florian> in casual talk, does "you should clip this element" mean
            "overflow:clip" or "clip:border-box" (or something like
  <fantasai> Probably anything that has a clipping effect
  <Florian> I meant: once we have both overflow:clip and
            clip-path:border-box, when 2 css designers talk to
            eachother, they cannot use word clip without being
  <Florian> I'll sleep on it, ping Tab (because of contain) and
            dbaron (co-editor), and see where that takes us. Maybe
            we'll stick with clip
  <fantasai> Florian: They could also mean 'clip' or 'mask' or
             'overflow: hidden'. They all clip
  <Florian> dinner time, see you all
  <fantasai> kk, laters

Matt Rakow | 30 Jul 02:13 2015

[css-snappoints] Associating element snap points with a scroller

>From Majid:

> Well, that does not prevent snap points to pass through to ancestor even
> when the intermediate scroller has "overflow:scroll". This fails to address
> the original issue raised by Simon. Original example below:
> <div id="outer" style="overflow:scroll; scroll-snap-points-x: elements;>
>     <div id="intermediate" style="overflow:scroll">
>         <div class="inner" style="scroll-snap-coordinate:50% 50%"></div>
>         ... more ...
>     </div>
> </div>
> With your suggestion the inner snap points will be associated with outer
> which means that when intermediate is scrolled, outer need to snap which is
> undesirable.
> Snap points should still be associated to nearest ancestor with non-hidden
> overflow but only ever snapped to if scroller has 'elements'. This allows
> them to cross boundaries when reasonable with an implicit cap. At the same
> time it prevents them to cause snapping on unintended scrollers.

Hm, I think maybe I misinterpreted the feedback.  It sounded to me initially that the request was to add the
capability for snap points to cross scroller boundaries by explicitly setting their target with the
"elements" value, but I think that's not what's actually being requested.  Let me try rephrasing and see if
I have this right:

1) The initial concern was that overflow: auto can make it ambiguous which scroll container a snap point
will associate to, as currently written.  David Baron suggested simply always calling "overflow: auto" a
scroll container regardless of whether a scrolling user interface is presented or not [1].  Simon
counter-proposed bringing back the "elements" value to resolve the ambiguity.  This would imply that
snap points could cross scroller boundaries, if the nearest ancestor scroller did not specify
"elements" but a further ancestor did.  The WG resolved on that approach.
2) Simon later emailed the mailing list with reservations about letting snap points cross scroller
boundaries [2].  Rob proposed sticking with "nearest ancestor" but splitting X/Y axes with nested 1D
scrollers in mind [3].
3) Majid elaborated on Rob's proposal with more independently controllable X/Y properties (e.g.
scroll-snap-coordinate-x/y) [4].  Simon pointed out that this might preclude support for a partial grid
of snap points (at least without some more thought on the API surface) [5].

If I've got my head straight now, I think here are the things we agree on:
1) The presence/absence of a scrollbar controlling which element receives a snap point in the overflow:
auto case is confusing.  Overflow: auto should qualify as a scroll container regardless of whether a
scrollbar is actually present.
2) A snap point should only contribute to the nearest ancestor scroller, at least on a per-axis basis.  It
should not be able to bypass the nearest ancestor scroller and associate itself with a more-distant ancestor.

Things I'm less clear on:
1) What's the likely construction of a nested 1D scroller scenario -- would the author really want to snap
the outer scroller against elements contained within the inner scroller(s)?  For something like the
Netflix UI (effectively a series of horizontal 1D scrollers in a vertically scrollable page) I would
expect the vertical snapping to be done with snap points on the horizontal scrollers themselves, rather
than the elements.
2) Supposing there is a sensible construction that would work best with snapping the inner contents
against the outer scroller, and supposing that we have to make a tradeoff of that functionality against
the partial grid of snap points as Simon suggests, how do folks feel about the relative rank of those two
capabilities?  Partial grid seems more interesting to me on the surface (as mentioned previously for map
scenarios) but would like to see what opinions people have.

If we don't think snapping an outer scroller against the inner scroller's elements is an interesting
scenario, then I think the update is simple -- just make the change David Baron initially proposed of
"overflow: auto" is always a scroll container, and leave out "elements".  If we do want to support that
construction then I think it probably ends up something along the lines of what Majid proposed.

Does that sound right?  Apologies for the confusion :-/



Chris Rebert | 29 Jul 23:40 2015

[css-ui] Trivial formatting error

Under , the text "links and
status cursors" is within a <p>, instead of a <dt> like the other
cursor categories.

Bootstrap Core Team member
Browser 🐛s galore:

Matt Rakow | 29 Jul 22:31 2015

[css-snappoints] Merging element snap points with snap points from repeat()

From Majid:

> I understand how making elements and repeat mutually can help with a
> simpler syntax but are there no good use case for using both at the same
> time? Perhaps a map that snaps at 100% intervals and city centers?

So far no good examples.  Snapping a map at 100% intervals wouldn't make sense since it's not a paginated
scenario, plus mixing it with city center snap points would just make it appear to the end-user as if the
snapping "missed the city" at random.

I don't have a strong opinion here but with no supporting scenarios I'd rather take the simpler route
unless/until we have a hypothetical customer at least.

> Also, any ideas on how we are going to handle specification of scrollable
> area start and ends as snap points? I can see something like:
>               scroll-snap-points-x: *start* repeat(100%) *end*
> These snap points cannot be be mutually exclusive with either elements or
> repeat. If that is going to be handled using a space-delimited syntax then
> allowing the repeat in the mix should not make thing anymore complicated.

I've spent less time thinking about specialized start/end snap points since we haven't really heard
requests for them.  In theory it sounds like functionality you'd expect, but in practice I haven't really
seen cases that would require it.  Authors using the interval syntax typically have content that is an even
multiple of their interval size, so *start* and *end* are already snapped to without explicitly
specifying them.  For elements it's somewhat difficult to imagine a scenario where the author wants to
snap to elements, but also to the start and/or end despite not having an element there.

Similar to above I don't have a strong opinion either way since I don't have a supporting scenario, but I'd
prefer a leaner spec if there's not a compelling reason to ask implementers to take on extra work.

Matt Rakow | 29 Jul 21:35 2015

[css-snappoints] Always snapping to a mandatory point

Rob and Majid both recently brought up questions about the invariant in the spec of always ensuring the
scroll offset satisfies a snap point when mandatory snap points are in use, so I thought it would be
worthwhile to split that discussion off into a separate thread for more in-depth discussion.  I'll do
similar for the other issues that have come up since my last rollup email.

> I would argue that there should be a way for programmatic scrolling to
> evade "snap-points" when necessary. Perhaps evading snap points should be
> default for programmatic scrolls with an option to opt in to snap points!
> When an application uses a programmatic scrolls to scroll to a specific
> offset it actually means to scroll to that offset and snap points should
> not interfere with that.


> However, that conflicts with the spec text "If the content changes such
> that the visual viewport would no longer rest on a snap point (e.g. content
> is added, moved, deleted, resized), the scroll offset must be modified to
> maintain this guarantee." It doesn't make sense to allow some DOM APIs to
> violate that invariant but require other content changes to preserve it. If
> a script scrolls away from a snappoint, and then there's an insignificant
> DOM change, what would we do? I suggest we just remove that spec
> requirement; I think it's hard to implement and is likely to produce
> undesirable behavior anyway.


> If we ensure there is an API for pragmatically causing snap then
> applications can use it to cause snap when desired after any scripted
> scrolling or any changes that may update layout. This is backward
> compatible and allows developers to create the experience they want without
> needing to re-implement snap themselves. Perhaps something like:
> Element.scrollTo(x,y, 'snap').

This requirement is in direct response to feedback we received that our implementation of the API was
difficult to use because there was no good way to ensure a mandatory snap point was always satisfied.  If
you're able to try building some basic scenarios with the IE11 implementation you'll quickly see how this
is painful to implement even in the basic 100% interval case.

The imperative API approach is not sufficient to satisfy the scenario; it just pushes the requirement to
the author rather than the implementor.  This is a requirement that implementors should take on rather
than authors, because:
1) The author would need to understand and arbitrate between all input types and potential causes of
content change to ensure they do not force a snap while the user is still interacting with the scroller, but
does snap as soon as a rest state is reached.  If a new input type is introduced (e.g. the author didn't think
about touch) then the control likely breaks.
2) The author currently has no way of knowing (esp. interoperably across browsers) when scrollbar-based
scrolling has reached a steady state, e.g. when the user has "let go" of the scrollbar gripper.  Thus it's
difficult to know when it's safe to call an imperative API to force a snap.
3) Even for input types that have better eventing, this will require the developer to register for all input
events of all types to track when the scroller has reached a rest state.  Probably mutation observers as
well unless they can constrain their control's layout to avoid reaching an invalid scroll offset.
4) The author does not know which snap point is appropriate to snap to without doing a large amount of work to
track the currently snapped element and keep that up to date.  Consider example 1 from the spec [1], and
suppose the user is currently viewing image 5 (thus the scrollLeft is 2000).  If the scroller and images are
resized to 1000px wide (perhaps in response to the user maximizing their browser window) then image 3 is
suddenly in view rather than image 5.  The developer would have had to track that image 5 was the currently
snapped image, detect that something caused it to move, and called the imperative API to re-snap to the
correct image.

Actually, with regard to point #4, the invariant should be clarified in the spec that the *same* snap point
must be snapped to (if it still exists) when content changes, not just any snap point.

If evading a snap point is a goal with a script-based scroll (is there a supporting scenario for this?) then
it's inappropriate to use mandatory-type snap points since it's obviously not mandatory to snap. 
Proximity snap points are likely the appropriate type in that case.  Mandatory signifies "the user will
see a view that is unacceptable in the rest state if they are not snapped to a mandatory point".  Proximity
signifies "the user will see a more-optimal view if they are snapped to a proximity point".  These
definitions are intentionally agnostic of what mechanism was used to execute the scroll because they're
effectively describing valid/optimal views on the content, rather than directly describing scrolling
mechanism behaviors.

Agreed that this requirement isn't the easiest, but it's also where the feature holds value to authors so
they don't have to implement it themselves.



Mis User | 26 Jul 21:30 2015

[CSS22] [CSS21] <'border-width'> non-existent value type mentioned in section 1.4.2 of CSS 2.1 specification

There is an error in section 1.4.2 of Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification

and also in Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification

4. non-terminals that do not share the same name as a property. In this case, the non-terminal name appears between "<" and ">", as in <border-width>. Notice the distinction between <border-width> and <'border-width'>; the latter is defined in terms of the former. The definition of a non-terminal is located near its first appearance in the specification. In the electronic version of the document, each instance of this type of value links to the corresponding value definition.

There is no such value type as <'border-width'>, so it should be replaced by 'border-width', which is a CSS property name, so the above paragraph would read as follows:

4. non-terminals that do not share the same name as a property. In this case, the non-terminal name appears between "<" and ">", as in <border-width>. Notice the distinction between <border-width> and 'border-width'; the latter is defined in terms of the former. The definition of a non-terminal is located near its first appearance in the specification. In the electronic version of the document, each instance of this type of value links to the corresponding value definition.
Linss, Peter | 29 Jul 01:42 2015

[csswg] Agenda conf call 29-jul-2015

Time/Phone/WebEx details available to WG Members in w3c-css-wg. See

For local times, see:

** CSS WG Members, please send regrets to Member-only list if you can't
** attend.

0. Digressions

1. css-break last issues followup

2. Percentage resolution for abspos vs. in-flow grid items

3. Grid OM issue

4. Interaction between overflow-x and overflow-y
(if Florian sent email about it as stated last week)

5. Containment and overflow
(if Florian sent email about it as stated last week)

6. writing-modes and text-orientation

7. Ruby issues

8. HCL colors

9. "system" generic font name

10. Specifying how keyframes interact

11. Remove requirement for whitespace around and/not

12. max-content contribution not defined for flex items