Bogdan Brinza | 23 May 02:33 2015

[css-text] word-break: break-word


We've recently got an interoperability bug report for Microsoft Edge that was rooted in "word-break:
break-word". Chrome in this case breaks as if overflow-wrap/word-wrap is set to break-word and
Edge/Firefox don't. (example [1])

Looking at the latest draft [2] I see the expected values for word-break don't include break-word, which
lives as a property under overflow-wrap/word-wrap.

I didn't find any existing bugs in Blink/WebKit for this property and brief web search shows there might be
some WebKit history [3]. 

Looking at the usage data word-break: break-word is used on 3000 sites from the set of 1 000 000 unique sites.
Brief analysis suggests this might be mostly coming from couple JS libraries - but it doesn't look like any
of them depend on it.

What would be the right approach to solving this interop problem? Given the data so far it would make sense to
file bugs to consider removing this from WebKit / Blink, unless I'm missing something?


L. David Baron | 22 May 21:56 2015

renaming "Animatable:" to "Interpolation:" in property definition tables

In [1] and [2] the working group resolved that both animations and
transitions should work on properties that cannot be interpolated,
and these properties should switch when the timing function crosses
50%.  (This is particularly useful with the step-start and step-end
timing functions.)

Given this resolution, I think it no longer makes sense for the line
in the property definition table to be "Animatable:", as I suggested
on IRC in [1].

I'd like to change "Animatable:" to "Interpolation:", and change the
common "no" value to "discrete" or "in steps" or something similar.

This is basically an editorial change that follows from the existing
resolutions in [1] and [2], but since it affects multiple
specifications I wanted to give people a chance to comment.




𝄞   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)
(Continue reading)

Samwul Datong | 22 May 15:37 2015

CSS3 Rule weights

CSS3 uses the cascading set of rules and the !important keyword to determine which style rule among many conflicting rules should apply to an object/item.

However, with the heavy use of classes in css frameworks, the current system might not be totally appropriate to address all use cases.

I'm proposing a new simple css rule-weight property which can be added to any set of rules. The simple idea is that a set of rules with a heavier weight should take precedence over lighter weights.

.class1 {color:blue; font-size:1em; rule-weight:10}
.class2 {color:red; background-color:#b2b2b2; text-align:center; rule-weight:50}

<div class="class1 class2">Hello World</div>

Here, for any rules defined in both class1 and class2, the rules in class2 would take precedence because class2 has a higher rule-weight than class1.

This should make working with stylesheets simpler and easier to understand
Derek Gray | 20 May 05:27 2015

[selectors] Re: ::sticky/::stuck pseudo-class


Forgive me for my naivety. Couldn't the repaint process refer to the calculated state resulting from the most recent reflow to determine whether a given element is currently ‘stickied’ or not and thus apply or skip a sticky pseudo-selector?

I expect there to be some low-level details I’m missing, but I don’t see why the performance would be less than or equal to ‘user-scripted’ equivalents.

-- Derek

Majid Valipour | 21 May 17:38 2015

[css-snappoints] Separate scroll-snap-coordinate into {x,y} offsets


I was reading the latest snappoints spec draft and noticed that element snap coordinate is defined as a list of <position> values.

Current definition: scroll-snap-coordinate: none | <position>#
Simple example: scroll-snap-coordinate: 0 0, 10px 10px

The problem I see here is that it forces elements to always contribute snap points on _both_ axis which may be undesirable and unexpected. This also feels to be at odds with the rest of the spec which considers snap points to be defined for each axis independently e.g., scroll-snap-points-{x,y}.

I think the spec should separate the coordinate properties for x and y i.e., scroll-snap-coordinates-{x,y}. This is more consistent with the rest of the spec as well.

# Example Scenario
Consider the following example where the author intends for 
vertically scrolling body to snap to sections and horizontal 
image gallery to snap to images. However according to the spec the below code will result in  body to snap to both the sections and image centers.

body {
   overflow-y: scroll;
   scroll-snap-type: mandatory;
   scroll-snap-destination: 0 0;

section {
    scroll-snap-coordinate: 0 0;

#gallery-horizontal {
    overflow-x: scroll;
    white-space: nowrap;
    scroll-snap-type: mandatory;
    scroll-snap-destination: 50% 50%;

img {
    display: inline-block;
    scroll-snap-coordinate: 50% 50%;

   <section> </section>
   <section id='gallery-horizontal'>
   <section> </section>

To give you some context, I am looking into implementing snap points for Blink so I expect to be sending more questions and comments to the list as I make progress with the implementation. If you are curious, our hope is to build blink's implementation on top of some new primitives which are being actively developed such as CompositorWorker and Scroll Customization APIs.

Bang Seongbeom | 21 May 17:05 2015

[css-variables] var() for non-custom properties

Is there some reason that var() can not be used for non-custom properties?
Except shorthand, it would be a good idea.
We're already using a similar mechanism such as var() for non-custom 
property; currentcolor. Here is an example using var() instead of 
..parent {
      color: green;
..child {
      /* background-color: currentcolor; */
      background-color: var(color);

Shinyu Murakami | 20 May 10:49 2015

[css-ruby] ruby offset affected by font?

I believe the offset between the ruby base characters and the ruby annotation characters (between each
em-box) should be zero in normal cases.
However I found this offset is affected by font in current browser implementations.

Sample HTML:

The result on Windows Chrome/Firefox/IE:

A = MS Mincho
B = Meiryo
C = Yu Mincho
D = IPAMincho
E = Arial Unicode MS

MS Mincho and IPAMincho results are good, but other fonts cause big gap between ruby base and ruby annotation.

I guess this gap is caused by the TypoLineGap [1] value of the font metrics.
MS Mincho and IPAMincho's TypoLineGap value is 0 and Meiryo's is 1024 (1/2 of unitsPerEm 2048).

This value is "to compute a typographically correct default line spacing" [1] and should not used for ruby positioning.

I think this is a browser implementation's problem, but it may be necessary to clarify this in CSS Ruby spec.


Shinyu Murakami (村上 真雄)
CEO & Founder, Vivliostyle Inc.
murakami <at>

Shinyu Murakami | 19 May 07:51 2015

[css-page-floats] block-start/end and left/right values

CSS Page Floats
4.2. The float property

> block-start
>   If the float reference is a line box, block-start behaves like inline-start.
>   ...
> block-end
>   If the float reference is a line box, block-end behaves like inline-end.
>   ...
> left
>   Behave like block-end, inline-start or inline-end depending on the 
>   float containing block’s direction and writing-mode.
> right
>   Behave like block-start, inline-start or inline-end depending on the 
>   float containing block’s direction and writing-mode.

I think these definitions have problem and need to be fixed.

Consider 'float: right' in vertical-rl writing-mode and this float is a normal float (not page/column/region).
The float value 'right' will behave like block-start in this case, and block-start behaves like inline-start.
The 'inline-start' maps to 'top' in vertical-rl writing-mode. So 'float: right' in vertical-rl
writing-mode is floated to top. This is not consistent with CSS Writing Modes ('float: right' is floated
to bottom in vertical writing modes):

CSS Writing Modes
7.5. Line-Relative Mappings

> The line-right and line-left directions are calculated with respect 
> to the writing mode of the containing block of the box and used to 
> interpret the left and right values of the following properties:
>   the float property [CSS21]
>   the clear property [CSS21]

I think the left/right value should be treated as line-left and line-right, as described in Writing Modes,
when the float is not a page(column/region) float.

Shinyu Murakami (村上 真雄)
CEO & Founder, Vivliostyle Inc.
murakami <at>

Jens Oliver Meiert | 18 May 16:53 2015

Re: Standards growth and complexity

A few concerns about the growth of CSS &c.:

Personally I’ve been concerned about this for some time—from my view
common HTML and CSS code gets worse by the hour, with problems
typically being addressed by what caused them in the first place: new
features. (This is a generalization, but you get my drift.)

However, this is solely meant to keep the topic alive.

(Also shared with two other groups, posted separately to honor group

Jens Oliver Meiert

✎ The Little Book of HTML/CSS Frameworks:

Bang Seongbeom | 18 May 13:27 2015

[mediaqueries] Intuitive definition for custom media

Generally variable name is thought to be replaced. But custom media is 
not; The brackets surrounding it are removed when it is really used in 
' <at> media'.
For intuition, it should be defined in brackets from the first.

 <at> custom-media = <extension-name> [ <media-query-list> | true | false ] ;

 <at> custom-media = ( <extension-name> ) [ <media-query-list> | true | false ] ;

Xidorn Quan | 18 May 13:24 2015

[css-ruby] Overhanging and auto-hiding

The current spec says:

> The ruby annotations related to a ruby base must never overhang another ruby base.

However, there are cases that a ruby base doesn't not actually have any annotation with it. One of the cases would be auto-hidden annotation. Also, if there is shortage of annotation, a ruby base could have no annotation to pair with.

I propose that we should relax the restriction here, and allow ruby annotation to overhang ruby base if the ruby base doesn't have effective related annotation. Ruby base with no visible annotation should just be treated as plain text.

- Xidorn