Simon Fraser | 25 Oct 08:59 2014

[css-transforms] Editor's draft updated

I’ve updated the editor’s draft of CSS Transforms[1] with changes that describe the 3D rendering
model in more detail, as proposed at the Seattle F2F earlier this year.

The major changes are:

* Much-expanded section on the 3D rendering model, including explanation in terms of 3D rendering
contexts, and a description of the rendering order
* Addition of a “auto” value for transform-style, and clearer description of how transform-style
affects rendering.
* Some minor clarifications on the behavior of perspective and backface-visibility.

Feedback from authors and implementors is welcome!



Dirk Schulze | 25 Oct 07:50 2014

[css-images] Reference SVG paint servers with url()


I would like to suggest that it is possible to reference SVG paint servers like <pattern>,
<linearGradient> or <radialGradient> with url() and that this get added to the specification.

The ‘fill' and ‘stroke' properties are the first properties to support references of SVG paint
servers with url(). Both got extended in SVG2 to match the syntax of the ‘background’ shorthand
property and therefore support CSS images as well.

A recent change of SVG image handling, where an SVG document won’t be able to load further sub resources,
solves the cross origin issue we had before.

In WebKit we experimented with this way to reference SVG paint server resources and the result looks promising.

One difference to normal CSS Images: SVG paint servers are potentially infinite in size and won’t be
clipped, repeated or sized by other properties. I could imagine to have special behaviors when
referenced with element() or image().


Tab Atkins Jr. | 25 Oct 01:25 2014

[css-images] Extending image-set() to be equal-power with current srcset/<picture>

The image-set() function was originally designed to emulate the
functionality of the srcset attribute on <img>, back when it was first
proposed by Apple.

Today, though, the srcset syntax and functionality has been expanded,
and the <picture> element offers further elaboration on the concept.
It would be nice if CSS matched the functionality of HTML in this

There are four basic abilities offered by <picture>:

1. Let the browser choose which of several images it wants to
download, based on resolution.
2. Same as #1, but rather than specifying the resolution directly, you
specify the size of the image file and let the browser figure out the
effective resolution based on the size it'll be displayed at.
3. Different images based on MQs.
4. Supply images in multiple formats, with browsers ignoring ones they
don't understand.

Currently, image-set() satisfies #1, and MQs in CSS satisfy #3.  We're
left with #2 and #4 as things HTML can do but CSS can't.  I suggest we
fix this with two small additions to the image-set() syntax:

1. Allow, instead of a <resolution> value, an <image-size> value,
which is a dimension with a "w" or "h" unit, expressing how large the
image is in image pixels.  (The HTML image selection algorithm does
not yet use "h" data, but it will in the future, and it explicitly
ignores "h" descriptors without dropping the whole candidate, so that
in the future it can pay attention to them.)  It's resolved into an
(Continue reading)

Dirk Schulze | 25 Oct 00:14 2014

[css-shapes] Interpolation from or to none


It seems that the interpolation from a basic shape to ‘none', or ‘none' to a basic shape is not allowed
according to the spec [1]. IIRC, both interpolations are possible in WebKit and Blink. I think these
should be added to the spec.

IMO, it would be great if CSS Shapes could say that additive, accumulative animations as well as distance
computations[2] are possible (as long as ellipse/circle do not have
‘farthest-side’/‘closest-side’ specified). The individual scalars of the shape function
values are taken to compute the results.



Matt Rakow | 24 Oct 23:38 2014

[css-snappoints] 10/24 Snap points draft update

Hi all,

As noted on the conf. call a couple weeks ago, it's been a while since the last update to the snap points spec. 
I've pushed a new revision which resolves most of the issues.  I've also added this as a topic for TPAC so we
can discuss in person if needed - it's always easier to discuss this feature with a whiteboard handy.  I
believe I've captured or resolved all the feedback I've received -- if it looks like I've missed something
or if you disagree with the resolution please let me know.

Link for convenience:

Changes and additions:
-Section 3 - Replaced usage of the term "leading edge" with "start edge", matching the CSS Alignment spec.
-Section 4 - Specified behavior when content is added, moved, deleted, resized.  Mandatory snap points
MUST reconcile, proximity snap points MAY reconcile.
-Section 5 - Removed list syntax due to lack of scenario justification and since feedback was that people
didn't like it.  One collateral benefit of this is that it also resolves the ambiguity incurred if an author
tries to specify diagonal snap points using lists.
-Section 5 - Removed "element" value for scroll-snap-points property by popular request.  Its original
intent was to guarantee mutual exclusivity between list/interval vs. element snap points.  While we
still don't have scenario justification for combining interval and element snap points, we also don't
have strong justification for prohibiting it.  Best practice will be to avoid mixing the two.
-Section 7 - Specified that the snap-coordinate is relative to the element's border box, rather than the
box specified with the box-sizing property.  Added a new issue for Rob's request for the ability to specify
which box to use.
-Section 7 - Specified that the snap-coordinate is transformed along with the element, such that the snap
point is aligned with the element as-drawn.
-Throughout - Converted all <length>{2} values to <position> values.
-Throughout - Specified that the visual viewport adheres to the snap points (as opposed to the layout
viewport).  This resolved the question about zoomed behavior.
(Continue reading)

Tab Atkins Jr. | 24 Oct 22:57 2014

[css-fonts] Proposal for standardizing font timeout behavior

Font faces downloaded via  <at> font-face can sometimes take a while on
slow connections.  Browsers have adopted some inconsistent default
behavior regarding timeouts and display.  Some Chrome team members
(including input from me) have put together a proposal to let authors
control this, which has received a good response from developers.  You
can find the full proposal at

The abbreviated proposal is to add a new 'font-rendering' descriptor
to  <at> font-face, and a related 'font-rendering' property.

The grammar is:

font-rendering: optional | swap <time>? | mandatory <time>?

"optional" means that the font is nice to have.  If it's available at
the time the text starts rendering, it's used, but otherwise the UA
will fallback.  (It'll still download the font in the background, but
wont' do anything with it on this page load - subsequent page loads
might use it, though.)

"swap" means that the font is important, but not mandatory to read the
content.  The UA will render with a fallback until the font is
available, then swap to the downloaded font.  If <time> has passed
(default: 3s) without the font being available, the UA wont' swap even
if the font comes in (to avoid disrupting layout when people are
already deep into reading).

"mandatory" means that the font is necessary for rendering the
content.  The UA will block rendering of the text until the font comes
(Continue reading)

Florian Rivoal | 24 Oct 07:52 2014

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

On 15 Oct 2014, at 03:01, Faruk Ateş <faruk <at>> wrote:

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 believe that the logic of this paragraph is to avoid having a <at> page rule being conditionally applied based on the size of the page, then the <at> page rule changing that size, then the media query no longer matching, and getting into a loop. However, there are (probably) better ways to deal with this, as highlighted in the issue following this paragraph.

We have a circumstance where this is preventing us from being able to provide the user the desired solutions to her problem. […]

If I understood what you’re doing correctly, I believe that if we changed to what is suggested in that issue instead of the current text, your scenario would work out fine.

 - Florian
Daniel Holbert | 23 Oct 23:51 2014

[css-flexbox] "scaled flex shrink factor" is it scaled by *inner* or *outer* flex base size?

Hi Tab & fantasai,

I just ran across a possible bug in Gecko & Blink, where they disagree
with the flexbox spec -- but I think it might really be a spec bug, & I
wanted to clarify it here before proceeding with a Gecko patch.

The spec text in question is:
   # For every unfrozen item on the line, multiply its
   # flex shrink factor by its outer flex base size,
   # and note this as its scaled flex shrink factor.

I'm interested in the word "outer" here.  With that word, the spec is
saying that an item's margin/border/padding (henceforth "MBP") should be
included in the flex-shrink-factor scaling calculation.

Firstly, here's a testcase to show what browsers actually do:

As shown by that testcase, IE11 scales by the outer flex base size
(matching the spec), while Firefox & Chrome scale by the *inner* flex
base size.

The specced behavior seems wrong to me -- I think we should drop the
word "outer" there (leaving us with the "inner" flex base size).

Here's my thinking:
 (1) In a flex item, the part that's *actually* flexible is its *content
box* -- not its MBP. The flexbox algorithm doesn't grow or shrink the
MBP (ignoring auto margins, since they don't come into play here).  Flex
items with larger content boxes really *do* have more room to shrink
(until we clamp at their min-size), so it makes sense that we scale
their flex-shrink factor accordingly -- BUT -- flex items with larger
MBP do *not* have any additional ability to shrink, so it does *not*
make sense (to me at least) for the MBP to influence their scaled
flex-shrink factor.

Looking at it from a slightly different angle:
 (2) The flex-shrink scaling behavior is designed to prevent bad
scenarios where some elements might shrink to nothing, while other
elements still have plenty more room to shrink.  Yet, this bad scenario
is exactly what will happen, with the current spec text, if you've got
an item with large MBP.  That item will be "penalized" for its MBP, and
its content-box will rapidly shrink to 0 (or its min-size clamp) as the
container shrinks, while other items with similarly-sized content-boxes
& without any MBP will shrink less rapidly.

Also, FWIW: the changeset that added the word 'outer' here was really
just cleaning up 3 stale mentions of "flex basis" (replacing them with
"hypothetical main size"), and in this one instance (out of the three),
the word "outer" was added as well. This introduction represented a
behavior-change, which may not have been intended by that commit.

Changeset link:

(Ultimately, I'm OK with either behavior (it's easy enough to switch);
it just makes more sense to me that the MBP should be excluded from the
scaling, per (1) and (2) above.)


Browser versions tested: Firefox 36 (Nightly), Chrome 40 (dev), IE11

Greg Whitworth | 23 Oct 20:08 2014

[css-text] Should contenteditable word-wrap: break by default

We have an interop issue that was submitted to us as a bug and it concerns contenteditable. Currently Chrome currently adds the following props by default to any element that has a contenteditable:

     word-wrap: break-word

     –webkit-line-break: after-white-space


Firefox/IE currently render the same by adding scroll bars if the length of the content overflows the input (assuming overflow: auto|scroll) if there are no spaces inserted into the editable div, if there are spaces all browsers render the same.


Here is a fiddle: (just type in the input without spaces)


I am not passionate on this one way or the other, but would just like to get the opinion of the group to determine if FF/IE should change to match Chrome or vice-versa.




Behrang Saeedzadeh | 23 Oct 12:36 2014

Reseting CSS on div


Have there been any discussions to allow defining a div that ignores any styling defined outside it and only honors <style> tags defined within it?

I know this is a little bit more complicated than it seems, as we might want to define some styling on the div itself as well.

But finer details aside, the use case is for when a third-party JS script injects some HTML to the current DOM, without an iframe, and uses class names that can conflict with class names already used by our site.

So, then, we can define a div, for example, like:

<style>.foo {} </style>
<div id="root" ignore-outer-stylesheets>
  <style>.foo { }</style>

And only the rules defined in the second <style> tag will be picked up by #root and its descendants.

Best regards,
Koji Ishii | 23 Oct 11:50 2014

Re: Question on Text Justification of Korean

How badly broken is it? Is it bad enough to sacrifice justification quality of Hangul-only documents (it’s slightly though)? A long story in short, if this is too critical to fix, we will need to sacrifice justification quality of a) Chinese, b) Japanese, and c) Hangul-only Korean documents.

On Oct 23, 2014, at 10:00 AM, hyunyoung kim < <at>> wrote:


The following examples can explain (A)bad situation


And I am sorry not to provide (B)Broken case because it is not existed in general documents

HyunYoung Kim

2014-10-23 2:13 GMT+09:00 fantasai <fantasai.lists <at>>:
The CSSWG is working on default rules for text justification, for
when there is no information on the document language. The rules
will not be ideal for any one language, but should nonetheless
produce acceptable results.

A key question we are stuck on is whether in Korean it is acceptable
to expand between Han and Hangul characters even when Hangul is not

For example, is it OK to expand
  0.  서울특별시(서울特別市)는 한반도
  1.  서울특별시(서울 特 別 市 )는    한반도
We suspect this is not ideal, but want to know whether this is
(A) bad or (B) broken.

For comparison, here are examples of English justification:
  0.  This is a justification example.
  1.  This          is           a          justification         example.
  2.  T h i s     i s    a    j u s t i f i c a t i o n    e x a m p l e .
  3.  This        is        a       just   ifica   tion         ex  ample.

(A) Bad: #1 & #2
  #1 & #2 look bad because there is too much space making it hard to read.
(B) Broken: #3
  #3 is broken because, while the spaces within words are smaller
  than between words, they are placed where there shouldn't be spaces,
  distorting the text.

And here are examples of Japanese justification:
  0. Elikaは勉強しますから寝ませんでした。
  1. E l i k a は 勉 強 し ま す か ら 寝 ま せ ん で し た。
  2. Elika                   は勉強しますから寝ませんでした。
  3. Elika    は   勉   強   しますから   寝   ませんでした。

(A) Bad: #1 & #2
  #1 is not good because it is preferred not to expand Roman in most cases;
  but it is acceptable to put space there.
  #2 is not ideal because there is too much space, creating discontinuity.
(B) Broken: #3
  #3 is broken because Japanese does not accept to treat Kanji and Kana
  differently for justification.

So, please let us know, is example #1 for Korean--putting space between
Han but not Hangul--considered (A) bad or (B) broken?

Thank you!