Philip Walton | 29 Nov 19:34 2015

[css-variables] Can custom properties be reset with all?

So, the spec seem to be pretty clear about this:

> Custom properties are not reset by the all property. We may define a property in the future that resets all variables.

The thing is, I've read comments by several people (including the spec editor) that specifically mention using `all: initial` for custom property resetting. For example, in this Github comment Tab says:

> Sure we can...that's what `all: initial` is for. (Alternately, an equivalent of all for just custom properties has been proposed; it would be called --, as in --: initial.) You can then let particular custom properties thru with --foo: inherit.

In addition, Firefox, Chrome Canary, and Webkit Nightly all reset custom property definitions when using all.

So I guess in addition to the question I posed in the subject line, is this a recent change?
François REMY | 29 Nov 09:00 2015

RE : [bikeshed] Missing line break in code samples?

Great, thanks!

When will this go live?



De : Tab Atkins Jr.
Envoyé le :samedi 28 novembre 2015 19:41
À : François REMY
Cc : www-style <at>
Objet :Re: [bikeshed] Missing line break in code samples?



On Thu, Oct 29, 2015 at 12:45 PM, François REMY
< <at>> wrote:
> It seems to me that the drafts hosted on seems to have a problem
> with code blocks and line-breaks, as the first one of them is missing
> consistently there.
> See
> for instance
> Am I the only one to see this?

No, you're seeing correctly. The <pre>s were still written in the
defensive style required in HTML, which Bikeshed (somewhat
intentionally) interprets incorrectly.  I've fixed the source to be




Daniel James | 25 Nov 23:23 2015

[nth-child(x) bug] nth-child does not correctly select an element with parent

Hello, I think I've found a bug or something within the CSS3 spec relating to nth-child that is incorrect and doesn't make sense when put into practical use. I've checked other browsers to make sure it's not a browser bug and the same behaviour occurs in Chrome (latest), Firefox (latest) and Internet Explorer (11).

The issue is that if you use for example:

.parent input:nth-child(1)

If inside the parent element is something like a label before the first input element, then everything you have put within that CSS selector above will not work.

This is because as far as nth-child is concerned, the first input is not the first child of the parent. However we're not looking for anything other than the first input child of the parent element.

I've created a demonstration in case I've not explained it very well. I believe this current behaviour is incorrect and should be revised as it's not literally doing what you're telling it to do.

I've found that using :nth-of-type is a suitable work around for this issue anyway.

Thanks, Daniel James
Tavmjong Bah | 26 Nov 15:39 2015

[css-inline] 'dominant-baseline' values


In reworking the SVG 2 text section I've come across a number of issues
with the values for 'dominant-baseline':

* The 'initial' value is given as 'normal' which is not defined. SVG
1.1 uses 'auto' which is defined.

* SVG 1.1 (and XSL) has the additional values:

  'use-script', 'no-change', 'reset-size', 'ideographic',
  'middle', 'text-after-edge', 'text-before-edge'

  I'm not too worried about losing 'use-script' and 'no-change' but I
think 'ideographic' and 'middle' should be kept. Both are supported by
Firefox and Blink. 'reset-size' also has a useful purpose (see next

* In both SVG 1.1 and XSL the baseline tables are not changed when the
font size changes. See the figure in the XSL spec.[1] The tables are
only changed when the 'dominant-baseline' has a value of 'reset-size'.
It's not clear that this is the prescribed behavior in the CSS Inline
spec and browsers don't seem to follow this.

* It would be useful to suggest default values for the various
baselines if they cannot be extracted from the font (and are not
otherwise clearly defined). Or, for example, one could try to measure
the hanging baseline by measuring the ascent of various glyphs in the
the Devangari, Bengali, Gujarati, etc scripts. The math baseline could
be found by finding the middle of the 'minus' character. 

* The 'auto' value for vertical text when coupled with the obsolete SVG
'glyph-orientation-vertical' values '90deg' and '90' breaks SVG
content. This is because these values for 'glyph-orientation-vertical'
are mapped to the 'text-orientation' value 'sideways' which dictates
that the 'dominant-baseline' has a value of 'alphabetic' where in SVG
1.1 the auto value of 'dominant-baseline' for all vertical text is
'central'. This is important as in SVG, text is positioned so that the
dominant baseline is aligned to the 'x' attribute of the <text> element
(for vertical text). Using the 'alphabetic' baseline for sideways text
will result in shifting the text by the difference between the
alphabetic and central baselines.

I've created a test SVG file with a custom font for the 'dominant-
baseline' property.[2]


[1], specifically this

Florian Rivoal | 26 Nov 15:01 2015

[CSSWG][css-device-adapt] Updated WD of CSS Device Adaptation L1

The CSS WG has published an updated Working Draft of the CSS Device Adaptation Module Level 1:

This specification provides a way for an author to specify, in CSS, the size, zoom factor, and orientation
of the viewport that is used as the base for the initial containing block.

This update contains changes accumulated since 2011, so there's quite a few of them.

Significant changes are listed at:

Please send any comments to this mailing list, <www-style <at>>, and 
please, prefix the subject line with


(as I did on this message).

For the CSS WG,
 - Florian Rivoal

Simon Pieters | 25 Nov 19:19 2015

[css-conditional][quirks] Quirks mode and <at> supports/CSS.supports

What is the interaction between


Testing in it  
appears that in Blink/WebKit/Gecko apply the quirks in  <at> supports, but not  
in CSS.supports(). Presto doesn't apply the quirks to  <at> supports and  
doesn't have CSS.supports(). I haven't checked IE/Edge. I suggest we  
specify what Blink/WebKit/Gecko do.


Simon Pieters
Opera Software

L. David Baron | 25 Nov 01:28 2015

[css-will-change] establishing containing block for fixed-positioned elements

  If any non-initial value of a property would cause the element to
  generate a containing block for fixed-position elements,
  specifying that property in will-change must cause the element to
  generate a containing block for fixed-position elements.

I think this should instead say:

  If any non-initial value of a property would cause the element to
  generate a containing block for fixed-position elements,
  specifying that property in will-change must cause the element to
  generate a containing block for fixed-position _and
  absolute-position_ elements.

I don't think we need special will-change handling for the
properties that establish a containing block for absolute-position
but not fixed-position elements (i.e., the position property), but
the properties that establish a containing block for
fixed-positioned elements *also* do so for absolutely-positioned
elements.  And it would be bizarre (and defeat the point of the
special will-change handling) to establish only half of the
containing-block nature and not all of it.

(Also see
about making this clearer in css-transforms and css-filters.)

While here, it's probably also worth using "absolutely positioned"
and "fixed positioned" as does,
rather than "fixed-position" and "absolute-position".



𝄞   L. David Baron                  𝄂
𝄢   Mozilla                   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)
L. David Baron | 25 Nov 00:44 2015

[css-will-change] 'will-change' and custom properties
defines the behavior of 'will-change: <custom-ident>'.  It has a
number of statements that "If a[ny] non-initial value of a property
would cause"...

Xidorn pointed out to me in that
technically this applies to custom properties, but it probably isn't
meant to.  I don't think implementations should be required to trace
through the uses of a custom property to see if the custom property
could possibly cause the creation of a stacking context or the
generation of a containing block for fixed-positioned elements.
That seems like a lot of work for very little benefit... and
will-change is intended to make things faster, not slower!

I think this definition should explictly exclude custom properties
from having these effects.



𝄞   L. David Baron                  𝄂
𝄢   Mozilla                   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)
Christian Biesinger | 25 Nov 00:17 2015

[css-sizing]? Scrollbars and preferred width

Hi there!

question about intrinsic width calculation and scrollbars. Consider

In Chrome and Firefox, at least, the first box gets a horizontal
scrollbar because the preferred width does not include the width of
the vertical scrollbar for overflow: auto. This makes sense because to
determine whether a scrollbar is needed, the box has to be laid out,
and the preferred width can't depend on layout. Conversely, at least
in Chrome (haven't tested other browsers), the scrollbar does get
included if it's overflow:scroll.

But my question is, is this behavior specified? (and correct? :) )

(Also, I was surprised when I realized that the scrollbar gets placed
within the content box, ie. width: 100px gets reduced by the scrollbar
size. Is that, too, specified?)


fantasai | 24 Nov 23:31 2015

[css-scroll-snap] Splitting scroll-snap-type, shorthanding on scroll container

The current 'scroll-snap-type' property takes two different,
and orthogonal, sets of values:

scroll-snap-type: none | [ proximity | mandatory ] || [ x | y | block | inline | both | point ]

There are the “strictness” values and the “axis” values.

We're thinking it would make sense to have a shorthand
and two longhands here. The question is, what are they
all called?

I've come up with four ideas so far:

   a) scroll-snap         -> scroll-snap-type / scroll-snap-axis
   b) scroll-snap         -> scroll-snap-capture / scroll-snap-axis
   c) scroll-snap-type    -> scroll-snap-capture / scroll-snap-axis
   d) scroll-snap-capture -> scroll-snap-type / scroll-snap-axis

I'm not super keen on any of them and welcome other ideas.

My main reservation with a) and b) is that 'scroll-snap'
might be better used as a shorthand for 'scroll-snap-align'
and 'scroll-snap-area', which are set on descendants of the
scroll container... or alternately we may want 'scroll-snap'
to also reset the 'scroll-snap-padding' property.

Thoughts on appropriate shorthanding structures and/or names?


Daniel Holbert | 24 Nov 23:30 2015

[css-align] Should 'justify-content:stretch' *compute to* or *behave like* flex-start, in a flex item?

In light of the recent thread[1] about css-align & 'left'/'right' being
converted to sensible values *at used-value time* instead of at
computed-value time: I have a similar question about
"justify-content:stretch" & flex containers.

The css-align spec says[2] that "justify-content:stretch" *computes* to
flex-start, on flex containers:
  #  since flexing in the main axis is controlled
  #  by 'flex', 'stretch' computes to 'flex-start'.
Is there a reason it chooses to do this, as opposed to just having
"stretch" *behave* like "flex-start" as a used value in a flex container?

(Moreover: this special computation behavior contradicts the "Computed
value: specified value" line in the justify-content/align-content
property definition.  If we really want this special computed-style
behavior, then that line needs an exception added.  But I'd really like
for us to just do away with this special computed-style.)


P.S. This special "stretch" computed-value behavior made more sense back
when "auto" computed to "stretch", in an older version of the css-align
spec -- then, the new initial value "justify-content:auto" would compute
all the way to its old value, "flex-start", on a flex container. But
given that "auto" computes to itself now[3], that won't happen anymore.
 So it seems like we should just have "stretch" compute to itself too.