Bruno Racineux | 21 Oct 23:33 2014

[css-flexbox] Firefox+IE absolutely-positioned bug?

It seems that both Firefox and IE have a bug with absolutely-positioned items.
The spec is hard to grasp for absolute items, but in any case, there is a discrepancy with webkit.

I am wanting to use an absolutely positioning flex item on mobile
as fallback with -webkit–box and -moz–box for their lack of flex-flow support.

So for example, I have vertical flex items [ABC], with [B] and [C] at 'order: 10',
[B] at 'order: 1' and  [A] set to 'position: absolute' with 'top: inherit'.

The way webkit behaves is that [A] absolutely-position below [B] with top either set at 'initial' or 'inherit',
and acknowledge the reordering step of [A] now in second position (after B).

If I set 'top' with a value,  the 'top: 0' basis of [A] is the top root of the flex wrapper in all browsers.

What is the correct behavior for 'initial' or 'inherit' in this circumstance?
Sylvain Galineau | 21 Oct 22:20 2014

Re: [css3-animation] why content property not animatable?

On Oct 9, 2014, at 7:16 AM, Tim Larson <Tim.Larson <at>> wrote:

> Tab said that it's not in the spec because nobody has done the implementation to see if it would work–but
why would anyone try to implement it if the spec says it's unneeded? Chicken or egg...

Once again, the WG has resolved to allow discrete value to animate at the half-way point of a timing function
curve. Resolved means it will be required for browsers to do this when the current Transition and
Animations specs reach Recommendation i.e. it will be 'needed' in order to conform. Obviously no browser
implements this *yet* because this behavior wasn't required when they implemented a previous version of
the current spec. The specs will be updated; the browsers will update their code to match. There is no
chicken and egg issue here. 

What is *not* going to happen at this time is the ability to interpolate between code points e.g. animating
from 'A' to 'Z' through B, C, D etc. by only specifying the start/end values of the character range. 

Faruk Ateş | 15 Oct 12:01 2014

[css3-page] different <at> page size requirements under different orientations


Can someone explain this section of the <at> Page specification, specifically, _why_ the declaration must be ignored:

If a size property declaration is qualified by a ‘width’, ‘height’, ‘device-width’, ‘device-height’, ‘aspect-ratio’, ‘device-aspect-ratio’ or ‘orientation’ media query [MEDIAQ] (or other conditional on the size of the paper), then the declaration must be ignored. Media queries do not honor ‘size’: they assume the paper size that would be chosen if no <at> page rules were specified.

I searched the archive for an answer, but the latest I could find about this is from Bert Bos in

The author may have added media queries for different sizes of paper. 
The choice above applies to whatever size results from applying those 
media queries, given the user's chosen paper.

This perspective clearly suggests the possibility to specify two different <at> page { size: W H; } values in combination with media queries. That goes counter to what the spec currently stipulates, but I cannot find an explanation as to why.

We have a circumstance where this is preventing us from being able to provide the user the desired solutions to her problem. Our product, Presentate, is a fully web-based presentation tool that allows users to create slides and "narrative" -- purposefully public speaker notes, basically -- and for the Print stylesheet, we want to offer an optimized solution for each orientation: 

1. slides + narrative when in Portrait mode, resembling our "smartphone" (small screen) layout with the presentation basically becoming a long-form article with the narrative interspersed by their respective slide;
2. slides-only in Landscape mode, simulating the big-screen presentation mode experience where you have the slides maximized to the available space (screen or paper).

Specifically, the second option -- Landscape mode -- would provide a great Print-to-PDF solution that users may want to use as a backup in case of issues. But for that to actually work, the page size for Landscape would have to match the (fixed) aspect ratio of our slides.

However, this doesn't quite work because browsers seem to adhere to this part of the spec. When a precise size is specified, Chrome no longer supports switching between Portrait and Landscape because the size cannot be changed per orientation; Safari has similar and other issues (which I consider to be bugs, but that's neither here nor there); Firefox adheres to the spec and ignores these instructions.

There doesn't seem to be a particularly clear reason why this instruction is supposed to be ignored under such a perfectly reasonable condition (our use case may be specific, but Bert Bos' pointed out long ago that this may be a perfectly common author desire, and I agree). 

Apologies if this has been explained in detail somewhere and my searching was simply insufficient. If not, I'd love to hear why this is spec'd this way.

Faruk Ates

Nicolas Ploquin | 10 Oct 10:33 2014

[selectors] Mistaken example in column combinator

In Selector Level 4, Editor’s Draft, 7 october 2014,


Example 55 tells « The following example makes cells C, E, and G yellow. » but style defines a gray background and a white text color.


Best regards,



Tim Larson | 9 Oct 16:16 2014

RE: [css3-animation] why content property not animatable?

> The SMIL/SVG <set/> animation element can handle discrete animation
> with no problem Any property that can be set should be animatable by
> discrete animation, with no interpolation.

Precisely. Obviously, interpolation doesn't always make sense. For example,

 <at> keyframes spinsquare {
         0% { content:"\25f3"; } /* ◳ */
        25% { content:"\25f2"; } /* ◲ */
        50% { content:"\25f1"; } /* ◱ */
        75% { content:"\25f0"; } /* ◰ */

It is immediately obvious what I'm trying to accomplish. Of course, when values are discrete and not
continuous, from/to don't make sense, but simply changing from one explicitly given value to the next at
the correct time in the transition is certainly possible. For comparison, the spec says font-weight is
animatable, but that's not truly a continuous scale either; it's a set of one to nine discrete ordered values.

Tab said that it's not in the spec because nobody has done the implementation to see if it would work–but
why would anyone try to implement it if the spec says it's unneeded? Chicken or egg...

Tim Larson ⁞ Schneider Electric ⁞ Energy Development ⁞ Software Developer

NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized use, disclosure or distribution is prohibited. If you are
not the intended recipient, please contact the sender by reply email and destroy all copies of the
original message.
Brian Birtles | 21 Oct 10:07 2014

[css-writing-modes] Underline in vertical text


For the following markup which side is the underline drawn on?

   div {
     writing-mode: vertical-rl;
     text-orientation: upright;


 From my reading of the spec and testing in Chrome, it seems like it 
appears on the left side.

That seems odd from a Japanese language point of view since "underlines" 
appear on the right-hand side in vertical Japanese (i.e. the same side 
as the ruby text).

Should authors overwrite this manually? e.g.

   u:lang(jp) {
     text-decoration-line: overline;

Or does it make sense to change the default behavior for this, e.g. 
through a UA stylesheet?

Best regards,


Cameron McCormack | 21 Oct 07:35 2014

[css-text][css-fonts] preventing font fallback from ruining my monospace text's alignment

I have a document that includes some code snippets in <pre> elements. 
Here is one:

       &lt;ex:arc from="n2" to="n3" label="Λ + c"/&gt;

It turns out that the font I am using for my code snippets doesn't have 
a glyph for the "Λ" character, and that the fallback font it ends up 
using has an advance that is a bit bigger than that of the surrounding 
characters.  This causes all the following characters to look 
misaligned, when looking at the lines above and below it.

Is there a way to prevent that from happening?  I feel like I want the 
ability to compress the "Λ" so that its advance is 1ch or perhaps to let 
it render at its slightly-bigger-than-I-want size but then place the 
following character where I expect it.

   pre { font-family: My Monospace Font; text-advance: 1ch compress; }

Benjamin Poulain | 21 Oct 03:45 2014

[selectors] Groups and repetition


I was gonna start implementing the filtered sibling selector
( in WebKit but it occurred to
me that there is an other syntax with a simple implementation and more capabilities.

Instead of creating a special purpose indirect sibling, we could just extend the existing syntax by
allowing groups and repetition, similarly to regular expressions.

Taking the examples already discussed:
    h1 ~(:not(h1, p)) p
Could be (using regexp “*” for 0-to-n repetition):
    h1 ( + :not(h1, p))* + p
Which is h1 following by any number of siblings matching :not(h1, p) followed by <p>.

The non-linked-image case:
	:root >>(:not(:any-link)) img
can be:
        :root (> :not(any-link))* > img

The advantage of this syntax over the other one is that you can express a much wider variety of relations.

I do not have strong use cases for this over the syntax “~(selector list)” but I wanted to raise this to
see if there is any interest before spending time implementing the other option.


Jonas Thiem | 18 Oct 21:36 2014

Proposal: easy attribute to uncollapse margins

Hi people responsible for CSS,

Sometimes collapsed margins are undesirable on elements with no
borders and padding, e.g. for the body element if you want to do exact
height calculations (for example to have its minimum height match the
viewport height) without the first child or last child's margins
throwing your calculations off.

The internet has come with nightmare'ish hacks to work around this:

The shortest and most readable solution I have found is still this
one: margin: -1px 0 0 0; border-top: 1px solid;

However, this is still a hack. The obvious question is: can't you add
a simple uncollapse-margin:uncollapse; style property or something
along the lines to the CSS specs?

Sorry if this is already in the specs, but I couldn't find something
along the lines on the internet and I'm not a regular CSS proposal
person, so I don't know all of the specs in full detail. Also sorry if
this mail has gone to the entirely wrong place, this seemed like the
correct list to mail this to.

Jonas Thiem

Rik Cabanier | 20 Oct 06:39 2014

[css-image] gradient midpoint vs color interpolation hint

CSS Images 4 defines the midpoint as a 'color interpolation hint'

Since we've always talked about that it specifies the midpoint of the gradient and authors are more familiar with that term, can we change the spec?
It's also a bit weird to call it a 'hint'

fantasai | 19 Oct 18:10 2014

[css-text][css-lists] Justification of bullet spaces

Gecko noticed that there are some differences in whether the gap between
a bullet and the start of the text of a list item is justifiable or not.

I'm pretty sure it should not be, since the start of the text across
items should line up precisely.

This should probably be clarified in Lists, that the contents of list-item
markers do not justify, at least for block lists.