Matt Rakow | 25 Jun 02:28 2016

[css-transforms] Individual transform properties, stacking contexts, containing blocks

Hi all,

Any non-"none" value for the transform property causes the element to establish a stacking context and
containing block.  The individual transform properties are not currently specified as establishing
either of these; should they (I think yes)?

If yes, when?  Do these properties also need a "none" value as the default?


TAMURA, Kent | 24 Jun 07:16 2016

[selectors] :user-invalid or :user-error

The current draft is very confusing.

> 12.3.4. The User-interaction Pseudo-class: :user-invalid
> The :user-invalid pseudo-class represents ...
> The :user-error pseudo-class must ...
> :user-error match an :invalid element ...

> it won’t match :user-error until ...

What is defined in this section; :user-invalid or :user-error?

Software Engineer, Google

fantasai | 24 Jun 03:52 2016

[CSSWG][css-scroll-snap] Merged WD of CSS Scroll Snap Module Published

The CSS WG has published an updated Working Draft of the
CSS Scroll Snap Module Level 1:

This module contains features to control panning and scrolling behavior with
“snap positions”, to which the UA is biased to land after a scroll operation.

This update represents the completed merge of Tab and fantasai's change
proposal into the main draft. See (May 2016)

Further work will involve resolving the remaining open issues, and addressing
any new ones that are filed.

Please review the draft, and send any comments to this mailing list,
<www-style <at>>, prefixed with [css-scroll-snap] (as I did on this
message) or (preferably) file them in the GitHub repository at

For the CSS WG,

Christian Biesinger | 23 Jun 23:40 2016

[css-flexbox] [css-sizing] Interaction of min-height and box-sizing: border-box

Hi there!

With a testcase like this:

<div style="height: 20px; min-height: min-content; box-sizing:
border-box; padding-top: 50px;">
  <div style="height: 50px; width: 50px;"></div>

What should the final size of the div be? Clearly, min-content here is
a 50px content-box or 80px border-box. But sizes in min-height get
adjusted by box-sizing. Do we insert the 50px content-box into
min-height, then adjust by box-sizing, and get an effective min-height
or 30px? Or not?

And (for the css-flexbox part of the question), does it make a
difference when this happens in the context of min-height: auto?



Dael Jackson | 23 Jun 02:36 2016

[CSSWG] Minutes Telecon 2016-06-22 [css-snappoints] [css-text-3] [css-round-display] [mediaqueries] [css-grid] [css-align] [css-inline]

  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 WG Charter

  - astearns will input the dates he proposed on the private mailing
      list (available here:

Scroll Snap Publication

  - RESOLVED: Publish CSS Scroll Snap

Line breaking opportunities at the boundary of a white-space:pre
  inline element

  - RESOLVED: Line break opportunities should be controlled by the

Round Display

  - The 'auto' value of offset-position will be written to mean do
      nothing to the position of the element.
  - 'contain' will be moved into offset-path as it's only relevant
      when there's an angle.
  - RESOLVED: Change the initial value of offset-rotation to 0deg.
  - jihye will move the offset-* properties into the Motion Path.

Edits that have been accepted and need WG approval for MQ

  - RESOLVED: Rename update-frequency to update (issue #1).
  - RESOLVED: Rename normal to fast (issue #1).
  - RESOLVED: Move inverted colors to level 5 (issue #8).
  - RESOLVED: Move custom MQ to level 5 (issue #9).
  - RESOLVED: Publish a new WD of MQ4.

Grid Issues

  - A decision on what happens with grid line names when dropping
      tracks (Issue here:
      was deferred until next week to give people time to review.
  - RESOLVED: vertical-align: baseline means first baseline except
              for inline-blocks (due to CSS2.1 legacy)



  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Joone Hur
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Michael Miller
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Alan Stearns
  Greg Whitworth
  Steve Zilles

  Tantek Çelik
  Ian Vollick

Scribe: dael

  Rossen: Let's get going.
  Rossen: As usual, let's start with a quick call for anything to
          add to the agenda.

CSS WG Charter

  Rossen: There have been a few updates since last week.
  Rossen: The one remaining piece is going over the dates and
  Rossen: There was an email started by astearns and there have been
          dates proposed and chatter. astearns can you summarize?
  astearns: I put together a straw man schedule I think we should
            put in the charter and then do what we can to meet those
  astearns: The other thing that needs to go in is the list of
            things working on. TabAtkins gave me an automation that
            has about half the information. I'm hand-editing the
            rest and should be done today.

  Rossen: To the WG: has everyone had a chance to look at the
          proposed straw man dates from the private list?
  Florian: Just the part that lists REC right?
  astearns: Right. This is REC dates over the charter period.
  Florian: That seemed reasonable.
  Florian: I haven't looked at the rest. What do we say about things
           not listed as going to REC. Do we list them all or...?
  astearns: Current plan is have them in list of things working on,
            show current status, and not give dates for progression.
            plh thought that was okay.
  ChrisL: Deliverables and dates are separate sections.
  Florian: For a spec like CSS 3 UI which has been fairly
           implemented fairly tested but not fully we just don't say
           anything special?
  astearns: Correct. It doesn't mean we can't work on it.
  <Florian> then it looks all good to me

  Rossen: Again, to summarize. It sounds like our plan is to put the
          automated list of drafts in the scope section. Dates will
          be those astearns posted.
  Rossen: That will send a message the rest is in progress but don't
          have a clear idea of where it will land.
  Rossen: Is everyone okay with that?
  <ChrisL> +1
  <glazou> +1 to rossen
  hober: Sure.
  fantasai: My position is if people don't commit to testing nothing
            will get to REC so I'm skeptical of the dates.
  Rossen: That's okay.
  glazou: That's no different than the last 20 years. We've always
          had a testing problem.
  Florian: There is discussion in the AC forum about that. There's
           talks about if we can change the charter process to deal
           with that, but it's not changed yet.
  Rossen: Anything else anyone wants to bring up? Otherwise we can
          action astearns to make the edits.

  ACTION astearns make the edits to have your proposed rec dates in
         the charter
  <trackbot> Created ACTION-780

Scroll Snap Publication

  Rossen: Just a quick request for a resolution.
  Rossen: Anyone opposed to publishing CSS scroll snap?

  RESOLVED: Publish CSS scroll snap

  <MaRakow> yay :)
  ChrisL: fantasai are you using the automatic from bikeshed or does
          it need to queue?
  fantasai: It needs to be queued up. There's a short name change.
  ChrisL: You don't have to zip it, I can do it manually.
  fantasai: short name change is to css-scroll-snap
  <fantasai> css-snappoints -> css-scroll-snap
  <ChrisL> css-scroll-snap-1 ?
  <fantasai> yep
  Rossen: And we have a resolution on that and that editors are
          yourself, TabAtkins and MaRakow.
  fantasai: Yes.
  Rossen: Great. Let's get that to a more final WD and proceed.
             <- previous resolutions on name change, editorship, etc.
  <TabAtkins> ChrisL: If you run `bikeshed echidna --just-tar`,
              it'll prepare a TAR with all the TR fixes you need
              before publishing.
  <TabAtkins> ChrisL: In the folder you run it in.
  <ChrisL> cool
  <ChrisL> although, see my recent comments on bikeshed issues about
           that, still things to fix manually

Line breaking opportunities at the boundary of a white-space:pre
  inline element

  <Florian> <p>あいうえお<span style="white-space:pre">か</span>きくけこ</p>
  Florian: Here's the relevant bit of code.
  Florian: I've been through the spec and it doesn't say how it
           should work. If you didn't have the span you'd have a
           line break opportunity between all characters. We have
           the white-space:pre in there. Should you be able to break
           on element boundaries? All browsers except blink and the
           webkit family do.
  Florian: I suspect that's from another bug they have. But either
           way the spec doesn't say it's a bug and I think it is.
  Florian: On github we were leaning toward when white-space:pre is
           applied to an element the parent should determine.
  fantasai: It should be just like letter spacing where the spacing
            is given by the parent.
  Florian: I think so too. If everyone agrees can we put it in the
  fantasai: I agree.

  Florian: I suspect we have the same issue about things like
           word-break, but I didn't check the spec.
  fantasai: Line break opportunities should be controlled by the
            parent. All of them.
  Florian: Makes sense to me.
  Rossen: Okay. Question. When you say parent do you mean block
          container parent or parent?
  <fantasai> by block container parent, you meant "containing block"
  fantasai: Parent of the boundary.
  Rossen: Okay.
  Rossen: Any objections?
  <bcampbell> I'm seeing this in the git issue, is that just me?
              "<p>あいうえお<span style="white-space:pre">か</span>きくけこ

  RESOLVED: Line break opportunities should be controlled by the

  <dbaron> by "the parent" do we mean "the nearest common ancestor"?

CSS Round Display

  jihye: I think it's better to see the github conversation. At San
         Francisco F2F there was a resolution to integrate polar
         positioning to motion path.
  jihye: I wrote a draft to describe the resolution.
  jihye: Properties related to polar positioning were merged to
         motion path. It's not just about motion but becomes path
         positioning. There are some properties that changed the
         name. offset-path and the like.
  jihye: offset-path defines the path an element can move on. It's a
         merge of motion path and polar-angle. offset-distance is
         the positioned element along the path. offset-anchor is the
         origin of the element which comes from round display polar
         anchor. I have another suggestion for rotation that wasn't
         in resolution.

  jihye: There's 2 issues to discuss.
  jihye: First is about the need for offset-position. It is similar
         to polar origin.
  jihye: The path which the element is positioned along is specified
         by offset path property. When angle is given to offset-path
         it is a straight line with the degree of the angle.
  jihye: The start is the center of the containing block and end is
         the edge of the containing block.
  jihye: Initial position of the elements is the start point of the
         path. After defining the path like that we can use
         offset-position. I defined polar-position as specifying the
         initial position. For example when I define:
  <jihye> offset-path: 90deg;
  jihye: It means the path starts at the center and ends at the
         middle of the right-side edge.
  <jihye> offset-position: 0% 50%
  jihye: Then I add offset-position: 0% 50% the path starts at the
         middle of the left side edge and ends at the middle of the
         right side edge.
  * smfr needs to see pictures
  jihye: With this use case, do you think it's useful and defined
  bradk: Several things aren't what I understood the resolution to
         be in San Francisco. Offset-position when discussed I
         agreed to because it had use independent of if you're
         moving along a path. We didn't say when using path it jumps
         to the center. The path is a position relative to where the
         element started. So if you use relpos or top it starts
         where ever it started.
  <fantasai> +1 to bradk
  bradk: If you did an angle you'd move from an angle. Not that it
         jumps to the beginning of the position.
  bradk: Instead of positioning the shape for the containing block
         you position the path's initial point to the element. That
         was it works to all the other positioning properties like
         top and offset and position: relative.
  <TabAtkins> And starting it in the center is just a matter of
              "offset-path: 45deg; offset-position: center;"

  fantasai: The auto value of offset-position was intended to be
            don't do anything special to the position of the
            element. If it was relpos it would be based on its
            position. If abspos it's from the calculation in 2.1 and
            left/right etc. properties. The position of the element
            and path is determined by the position. When it's not
            auto it moves according to offset-position.
  bradk: I don't think you need offset-position to come up with the
         origin. We described that you would start from where ever
         the position was. You don't need it for an origin point.
  Florian: There were two reasons why it was better that way. One
           being that the path itself will change depending on where
           you put the origin. If it's not center and goes to edge
           it's different points than center to the edge.
  bradk: And that's what offset-anchor was for.
  fantasai: You're mixing it up.
  bradk: You need an anchor for where align point to element.
  fantasai: The original proposal says where the path begins. From
            that point you go at an angle until you reach the edge.
            If you start center and go to edge length is 50%.
  fantasai: This applies even if the element is a 1x1px. The path
            will change depending on origin.
  fantasai: Where you attach element to path is the anchor.
  fantasai: Where the path is with respect to containing block is
  bradk: If using offset:position.
  Florian: It doesn't just change the position, but also the shape.
  bradk: Why?
  Florian: If you say center and right you do it as center bottom.
  bradk: For a circle or whatever the only odd thing is the inset
         shape. For everything else you position the path the the
  fantasai: It changes what percentage means. 100% means all the
            way, 0% means stay. 100% changes depending on length of
            path and length depends the origin and end point.
  bradk: Shouldn't. Percentage should be of containing block
  fantasai: No of the path. If you do polar positioning and you want
            45 deg 100% should go as far as you want until the edge.
            That isn't how it's defined in the spec.
  <ChrisL> agree with fantasai, this is how it should work
  bradk: I'm talking about where the path is relative to the
         element. The distance part doesn't come into that expect
         you're picking a size for the path. You're taking a length
         along that path. As long as you have the length you can be
         positioned along it.

  jihye: When path is defined by angle it has to pass through the
         center point.
  bradk: Why?
  bradk: You pick where it starts based on element, pick an array,
         and determine your point along that. You need to know where
         it starts relative to the element itself.
  jihye: I agree. Path doesn't have to start at center. Path has to
         pass through the center of the containing block.
  bradk: No...
  fantasai: The auto values need to be fixed. I think everything
            else is fine.

  Florian: Another point of difference. offset-difference has
           optional contain keyword and the like. I think they
           should be on the path not the distance.
  fantasai: Yes.
  Florian: Because they define what the path is. 100% gets you 100%
           on the path. Right now the contain and the like keywords
           are attached to the distance. But since we decided to put
           the angle as a part of the path they should go together
           with the angle to define the path. And 100% means 100% of
           the path.
  jihye: I put contain on the offset-distance because when I first
         suggested it for polar the major use is the element is not
         overflowing from containing block.
  Florian: I'm not changing behavior, but which property. What we
           put it in is offset-path, not -distance. At least I
           think. Behavior is correct, it's which property it goes
  bradk: I'm not sure the advantage of one or the other.
  Florian: When offset-path isn't an angle what do the keywords mean
           on the distance. That's why they have to stay with angle.
  <fantasai> Florian: offset-path newly takes an angle plus a
             keyword (as yet
  <fantasai> undefined list, including contain).
  jihye: When offset-anchor is the center of the element and
         offset-distance is 100% then some part of the element can
         overflow from containing block. So when you put contain on
         offset-distance the overflowing part can come inside the
         containing block.
  Florian: But for offset-path let's say you have a circle or a
           polygon. And then on offset-distance you have the closest
           edge. What does that mean?
  Florian: I don't think it has a clear meaning. And I think the
           behavior is correct but only makes sense when there's an
           angle. That's why I think it should be with the angle.
           When you have it with and angle and percentage I think
           we're fine.
  bradk: Florian, I think I agree, but I guess you could shrink the
         path to be contain.
  TabAtkins: That's going way beyond the use cases. It's keeping a
             polar element from overflowing.
  bradk: But it would more or less. I think I agree it's just a part
         of path.
  Rossen: Going back to jihye...
  Rossen: Are you okay with that?
  jihye: Now I agree with Florian. I agree with contain keyword is
         meaningful when path has an angle value. I think contain
         should be moved to offset-path. I agree with that.
  Florian: And same with closest-side, etc.
  jihye: I agree.

  Rossen: Do you need a resolution from the WG or is this already
  jihye: The offset-position I defined on the spec has to be changed
         or remain?
  bradk: The important thing on offset-position it shouldn't be
         required on path movement. You start the path on the
         element, not the containing block.
  Florian: I think we had agreed on that.
  Rossen: I'm trying to stop us before we open the can of worms.
  Florian: We're in the can already.

  fantasai: Offset-position always has a value and the initial is
            auto and it means do the things.
  <fantasai> that you would do if offset-position didn't exist.
  Rossen: And that's what we agreed already.
  <fantasai> yes
  TabAtkins: But the spec doesn't say that.
  Rossen: So it's editorial to make the changes.
  <fantasai> Right, the spec needs to be brought in line with the
  Florian: Yep. It's just auto stops doing the magic.
  <fantasai> It's not editorial, it's correcting the spec.
  Rossen: So the proposed path is jihye to take the clarifications
          into the spec. And that's it.
  <fantasai> It's not clarifications, it's fixes.
  <fantasai> Clarifications don't change behavior, this will. It
             will change the behavior to match the resolution.
  bradk: I'm still not clear on the auto magic.
  Rossen: Same as SF
  TabAtkins: Basically stop doing magic.

  jihye: I have 1 more topic. Initial value of offset-rotation
  jihye: Motion rotation means the path the element moves along.
         Initial value of auto is reasonable while element moves
         being rotated in direction of the path seems natural.
         offset-path could be for an element without motion. So in
         this case having initial rotation as 0deg is natural
  <fantasai> +1 to 0deg initial value
  jihye: I think 0deg is more proper than auto as the initial value
         for offset-rotation. Is it okay to change that?
  fantasai: I strongly agree.
  bradk: So do I. I think the only person who had it different is
         shans. We always had it so that if the property doesn't
         exist it matched and 0deg is that.

  TabAtkins: We should probably re-name auto to be more useful. Like
             follow or match. Don't need to discuss that now.
  bradk: There's another issue as to if we can use transforms, but
         that's a different day.

  Rossen: So proposed resolution is to change to 0deg as the initial
          value of offset-rotation.
  Florian: Isn't there a compat issue? It's changing the initial
           value of an existing property.
  TabAtkins: This isn't existing.
  Florian: It's called motion.
  bradk: That's separate and I don't think it's impl.
  TabAtkins: The motion properties aren't publicly impl. I think we
             have them a behind a flag. We have room to change.
  bradk: With a different property name there isn't an issue.
  TabAtkins: There's 0 compat issues
  Florian: says motion path is enabled in Chrome.
  ChrisL: That's in SVG.
  Florian: Alright.
  Rossen: I'll take TabAtkins's word.
  Rossen: Any objections to the resolution?

  RESOLVED: change to 0deg as the initial value of offset-rotation

  TabAtkins: Final bit. I thought we agreed to move these to motion
             path spec. I'd like to do that or resolve on it. It's
             the proper place for them to live.
  Rossen: I don't recall.
  Florian: I think we had one and added jihye as a co editor.
  Rossen: Okay. Who is editing motion path?
  jihye: shans
  bradk: What do we move?
  TabAtkins: All of them. They're transform based at the bottom.
  Florian: Yep.
  TabAtkins: They all get triggered into a transform in the
             transformation matrix.
  bradk: I guess, but offset-position doesn't have much to do with
  fantasai: It doesn't belong in round display. We can argue on the
            rest later.
  <astearns> from the SF minutes: "The motion path spec will need to
             be renamed since it's more about path positioning than
             it is about motion."
  fantasai: shans agreed with the changes and we added jihye as the
  ACTION: jihye to move offset- properties to motion-path spec
  <trackbot> Created ACTION-781

Edits that have been accepted and need WG approval for MQ


Issue #1

  fantasai: There were some issues. 1 was rename update-frequency:
            normal to update: fast.
  fantasai: List seemed to find that okay.
  fantasai: Dunno if there are other opinions.
  <fantasai> So, two changes: 1) rename update-frequence to update
             2) rename normal to fast
  Florian: I'm okay with the change, but I think there was a purpose
           to the naming. slow and fast doesn't give a reference
           point. When you have slow and normal it's quite clear.
           It's the usual thing and slow. But then again people can
           read the spec.
  Rossen: Okay. fantasai you want a resolution?
  fantasai: One to rename the property and one to rename the value
  Rossen: Property first. Objections?

  RESOLVED: Rename update-frequency to update (issue #1).

  Rossen: Objections on normal to fast?
  Florian: I prefer the other but don't object

  RESOLVED: Rename normal to fast (issue #1).

Issue #8

  Rossen: Defer inverted colors is next.
  fantasai: Yeah. Discussed deferring it so we can do a proper
            evaluation for all the things needed to handle colors
            correctly since it's not clear that's sorted out.
            Proposal is to move this so we can cut down to
            everything stable and ship this summer.
  Florian: I think deferring is okay. This is an investigation we
           haven't done.
  Rossen: I'd agree on moving this to later. As an implementor of
          high contrast more time would be good.
  Rossen: Any objections to moving inverted colors to level 5?

  RESOLVED: Move inverted colors to level 5 (issue #8)

Issue #9

  Rossen: Issue #9
  fantasai: This one isn't 100% baked so defer it to level 5.
  Florian: I'm okay with it. I think TabAtkins intended to move to
  TabAtkins: We'll move it where it needs to be. Doesn't matter.
  Rossen: Objections to move custom MQ to level 5?

  RESOLVED: Move custom MQ to level 5 (issue #9).


  Rossen: Any other MQ items?
  fantasai: There's some stuff for later, but I think we should
            publish a new WD and deal with the next set of issues in
            the next cycle.
  Rossen: That would be great. Anyone objecting?

  RESOLVED: Publish a new WD of MQ4.

  TabAtkins: I'll handle publication.
  <ChrisL> tab, mq4 is already in place and queued for publication


What happens with grid line names when dropping tracks

  fantasai: We discussed...the question was with the auto-fit:
            repeat we dropped tracks that were empty after the
            layout. You collapse and give them 0 width and merge
            gutters. We made a proposed set of edits and what to
            resolve on this definition shift.
  fantasai: The collapse helps with the abspos items that need to
            define where they are if using lines. Also output of
            CSSOM is clear because it's just 0 width. In terms of
            determining positioning and gaps the gutters around
            collapsed tracks are collapsed to nothing. If you're in
            the middle of the grid they overlap. This gives the
            expected behavior.
  Rossen: Only end or beginning as well?
  fantasai: It's symmetric.
  fantasai: We wanted to define the correct behavior, not because we
            expect this to be common but it's quite likely we'll add
            a concept of collapsing tracks explicitly. Looking
            forward this hooks into how that would work.

  fantasai: That's the change set.
  Rossen: Any comment or feedback?
  Rossen: I don't hear anything. I'm personally behind on this, but
          I can comment on github. Are you looking for a particular
  fantasai: Resolution on the change.
  fantasai: We can defer a week
  Rossen: That would be great for us.
  TabAtkins: We just wrote it yesterday.
  Rossen: If you're okay to push a week let's do that.

Baseline alignment

  fantasai: Do you align to the first or last baseline? We say the
            first. In CSS 2.1 it has tables align to the first and
            inline blocks to the last. Other precedent is how
            baseline values work in flexbox which always uses the
            first. So grid will interpret first line is the baseline.
  Rossen: I'm in favor of keeping those in sync as much as can.
  Rossen: We do the same for inline tables as well?
  fantasai: Yes, that's the first row.
  Rossen: So I'm even in more favor.
  Rossen: Objections?

  RESOLVED: vertical-align: baseline means first baseline except for
            inline-blocks (due to CSS2.1 legacy)

  fantasai: Last one, #8, needs more work from TabAtkins and I. It
            needs to defer anyway.
  Rossen: In that case that's the top of the hour and the end of the
          agenda. Thank you everyone. We'll call it a day.
  Rossen: Thanks, bye

Johannes Wilm | 22 Jun 18:30 2016

[css-page-floats] [css-logical-properties] state of logical directions in relation to floats

it has been a while so I have been looking at what i could find of communication on this. The following is my understanding of the situation:

Page floats are currently defined as moving only in one direction (inline-start/end or block-start/end). For this reason the direction had to be specified saying whether it should either be the inline or the block direction the float went in.

Through the discussion about this, and various people pointing out how this would be problematic, I came to agree with those critics of the current draft such as Tab, who held that page floats really always need to be two-dimensional: they need to go to one of the four corners of the fragmentainer they are in, and there is not any sense in only having page floats be able to float in two of the possible four corners. 

If the spec is changed accordingly, this should no longer be an issue as both directions will need to be specified. 

So it can either be A)  that we use "float: start start" where the first "start" is the block direction and the second is the inline direction, or B) we can use "float: block-start inline-start" in which case the order doesn't matter. We can also agree a shorthand for case A, if only one direction is mentioned, that "start" stands for "start start" and "end" stands for "end end". I do not have an opinion on whether A or B is better.

It has been a while, so my understanding of the state of the dicsussion may be somewhat incorrect, but if I'm not mistaken we seemed to be close to a consensus on this. Brad Kemper seemed to maintain a more general criticism of  defining page floats in terms of exclusions and I think he wanted to possibly write an alternative spec in which he wanted to expand the current inline floats to be able to float in two directions (?), but if I'm not mistaken, the issue of inline-start/end was not part of that disagreement.
Rossen Atanassov | 22 Jun 07:06 2016

[csswg] Agenda conf call 22-June-2016

Time/Phone/WebEx details available to WG Members in w3c-css-wg.
US Toll Number: +1-617-324-0000

For local times, see:

0. Extra agenda items and other digressions

1. [csswg] CSSWG Charter - go over and finalize draft dates

2. [css-scroll-snap] Request for Publication

3. [css-text-3] Line breaking opportunities at the boundary of a white-space:pre inline element

4. [css-round-dispaly] CSS Round Display Issues

5. [mediaqueries] Edits that have been accepted, but need WG approval:

6. [css-grid] What happens with grid line names when dropping tracks

7. [css-grid][css-align][css-inline] Which baseline to use as alignment baseline for grid container?

8. [css-grid][css-align] Removing restrictions on baseline-aligning things that have block-axis
baselines (due to containing orthogonal content).


Sebastian Zartner | 21 Jun 13:57 2016

Each spec. line at has several options
at the right side. Those options should show a tooltip when they are
hovered to clarify their meaning.


Martin Auswöger | 18 Jun 18:12 2016

[css-containment] Splitting size into width and height


the current CSS containment draft defines the “size containment” and mentions, as a possible use
case, JS libraries implementing the “container query” concept. I wrote [such a library][1] and
think it would be very helpful if size containment could be enabled for one dimension only so that the other
dimension can still be auto-sized.

Tab Atkins already wrote something about this here on [16 Mar 2016][2]
> It's also useful for userland implementations of "container queries" to prevent loops, especially if we
can activate it *solely* for the inline axis (letting the block axis still auto-size based on children).

There was also a discussion about container queries and size containment at [ResponsiveImagesCG/container-queries#3][3].

Containment could get changed to:

contain: none | strict | content | [ layout || style || paint || [ size | [ width || height ] ] ]

There may be better names for width/height like size-x/size-y or inline-size/block-size but I think
width/height ist more obvious for CSS authors.

Does this make sense, or could it have any negative implications?



Jihye Hong | 20 Jun 04:41 2016

Agenda+ CSS Round Display Issues

I would like to discuss about integrating polar positioning of CSS Round Display to Motion Path.

I wrote the draft about that:
   Spec Draft: 
and related thread is here:

The topics for the discussion are:
[css-round-display][motion-path] Integrate polar positioning to the motion path spec
   1. Need for 'offset-origin'
   2. Initial value of 'offset-rotation'

= Jihye

Léonie Watson | 17 Jun 11:53 2016

FlexBox keyboard disconnect - new property proposal

Hello CSS,

Had an impromptu chat with Simon Pieters and Greg Whitworth about the
FlexBox keyboard disconect [1]. It resulted in an idea for a new CSS

At the moment the problem is that FlexBox can create a disconnect between
the DOM order and visual order. This affects sighted keyboard users - or at
least exacerbates the disconnect that has existed since CSS layouts were
first a thing.

There is a workaround in Firefox, whereby the keyboard order matches the
visual flex order, instead of the DOM order. On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?

It seems like it would be good to have a property to enable developers to
choose whether the keyboard order matched the DOM order or the flex order.
Off the top of my head, something like:

tab-order: dom;


tab-order: flex;

>From the work Mozilla has already done, and this briefest of conversations
with Greg and Simon, it seems there is energy from the browser vendors to
find a solution to this problem. Hoping this idea kicks off further


 <at> LeonieWatson Carpe diem