Richard Ishida | 29 Jan 13:20 2015

Bopomofo related information

If you are interested in Traditional Chinese you may find the article I 
just posted of interest.

Bopomofo on the Web


A key issue for handling of bopomofo is the placement of tone marks. 
When bopomofo text runs vertically (either on its own, or as a phonetic 
annotation), some smarts are needed to display tone marks in the right 
place. This may also be required (though with different rules) for 
bopomofo when used horizontally for phonetic annotations (ie. above a 
base character), but not in all such cases. However, when bopomofo is 
written horizontally in any other situation (ie. when not written above 
a base character), the tone mark typically follows the last bopomofo 
letter in the syllable, with no special handling. For more details, see 


Dael Jackson | 29 Jan 02:23 2015

[CSSWG] Minutes Telecon 2015-01-28


  - dbaron asked that everyone review the Transitions ED since he
      hopes to bring it up for publication at the F2F.

Next Week's Telecon/Sydney F2F

  - Since both chairs, and likely many others, will be traveling
      next Wednesday, there will be no telecon.
  - Everyone was reminded to add items to the wiki for discussion in

Where is the "Complete Document"

  - RESOLVED: Turn the old road map into a 301 redirect to /TR/CSS
              and discuss updating /TR/CSS at the F2F


  - RESOLVED: Use 'content' as the new value for flex-basis
  - TabAktins explained his rational for creating 'no-wrap' as an
      alias to 'nowrap' to alleviate author confusion. However, the
      group remained unconvinced as to if it was the best way
      forward. This issue will remain open while the explores more
      possibilities and look for more information.
  - The remaining flexbox issues still need some work and/or
(Continue reading)

Cameron McCormack | 29 Jan 01:09 2015

[css-logical-props] resolving against parent's writing mode properties

I don’t understand the reasoning behind resolving the margin-* and
padding-* logical properties against the writing mode properties of the
parent, rather than the element itself.  Can someone explain, and
perhaps add that explanation to the spec as a note?

Also, the spec should define what happens when you use one of these
logical properties on the root element.


Cameron McCormack ≝

Mark Watson | 28 Jan 18:02 2015

Wide Color Gamut and High Dynamic Range displays


It would be nice to be able to detect whether the display has the capability of rendering Wide Color Gamut and High Dynamic Range video.

This is independent of codec support: in fact the video codec itself may be unaware of the colorspace and dynamic range of the encoded video. It may also be the case that the media pipeline in a device supports these things but the presently connected display does not.

For WGC, the basic question is whether the display can interpret data coded in the BT.2020 or DCI P3 colorspaces (I say "interpret" deliberately, because I'm unaware of any displays that can render the full BT.2020 space yet.)

Would it make sense to add attributes for these properties to the CSS OM View Module ? Other suggestions ? Questions ?

Thanks in advance,

Axel Dahmen | 28 Jan 17:28 2015

[css-transitions]: Extend CSS property list

The list properties to which transitions apply seems rather short. Important 
visual properties are missing:


* backgrounds should fade if property rules can't be matched,
   e. g. from "background: linear-gradient();" to "background: 

* otherwise, if properties can be matched, animate these,
   e.g. from "background: linear-gradient(black, black 20%, white;)" to 
"background: linear-gradient(black, black 80%, #888;)"
   which would result in an in-between of "background: 
linear-gradient(black, black 50%, #ccc;)" at 50% of the transition


* if the number of shadows defined for a box-shadow rule won't match,
    replace each missing shadow with "[inset] 0 0 0 0 rgba(0,0,0,0)",
    animate each of the given shadows then separately,
       e.g. from "box-shadow: 1ex 1ex 1ex 0 rgba(255,0,0,.5), inset 1ex 1ex 
1ex 0 rgba(0,0,255,.5)"
               to "box-shadow: -1ex -1ex -1ex 0 rgba(0,255,0,.5)"
       would result in first extending the second box-shadow definition to:
               "box-shadow: -1ex -1ex -1ex 0 rgba(0,255,0,.5), inset 0 0 0 0 
       then "1ex 1ex 1ex 0 rgba(255,0,0,.5)" would be transitioned to 
"-1ex -1ex -1ex 0 rgba(0,255,0,.5)"
       while simulatenously "inset 1ex 1ex 1ex 0 rgba(0,0,255,.5)" would be 
transitioned to
       "inset 0 0 0 0 rgba(0,0,0,0)"

Axel Dahmen 

Axel Dahmen | 28 Jan 16:01 2015

[css-text-decor]: text-shadow should also apply to replaced content, like semi-transparent images

Since box-shadow doesn't apply to content but only to boxes, whereas 
text-shadow applies to the content itself, I suggest to amend the 
text-shadow property specification to have this property also apply to 
inline replaced content, e.g. semi-transparent images, like PNG images with 
transparent areas.

Axel Dahmen 

Simon Pieters | 28 Jan 11:10 2015

[cssom] Serializing non-opaque colors, background-position keywords


Josh Matthews contributed some CSSOM serialization tests for  
web-platform-tests which uncovered some issues: (remove  
submissions/1427/ if this 404s)

The CSSOM spec needs work in general around serialization, so these aren't  
questions of "what does the spec say now?" but rather "what do we want the  
spec to say?".

== Non-opaque colors ==

How should color: rgba(5, 7, 10, 0.9) be serialized? Gecko round-trips  
alpha as 0.9 but Blink makes it 0.901961. I think Gecko faithfully  
round-trips two decimals for colors. Should we specify Gecko's behavior of  
rounding to a "nicer" number?

Similarly for 'opacity' (although that is represented with higher  
precision I think).

== background-position keywords ==

How should background-position: 0% top be serialized? For,  
Gecko round-trips keywords, Blink converts to percentages. For  
getComputedStyle, both convert to percentages. I think the spec for  
background-position says keywords compute to percentages.


Simon Pieters
Opera Software

Linss, Peter | 28 Jan 02:12 2015

[csswg] Agenda conf call 28-jan-2015

Time/Phone/SIP details available to WG Members in w3c-css-wg. See

** CSS WG Members, please send regrets to Member-only list if you can't
** attend.

0. Digressions, F2F, Etc

1. Where is the "Complete Document"

2. transform-style: preserve-3d creating containing blocks

3. flex-box-basis: <magic>

4. Flexbox issues

5. Extending break-* to lineboxes

6.text-wrap: balance

7. css-ui-3 Issues

8. Allowing  <at> import to be conditional on  <at> supports queries

9. Logical border radius properties

10. New 'font-size' value for automatic sizing of ruby

11. text-orientation: sideways-left

Boris Zbarsky | 27 Jan 18:57 2015

Re: spec complain: css letter-spacing in tabs not clear

On 1/26/15 8:18 AM, -=}\*/{=- wrote:
> ​please help us on this bug, we are having spec interpretation issues:
>    ​

More precisely, the spec is clear but probably not very useful.

Specifically, if you have preformatted text in a block with 
letter-spacing, the spacing of tab stops is not affected by the 
letter-spacing per spec.  Maybe it should be, because otherwise 
preformatted text with tabs in it ends up laying our all wrong.


-=}\*/{=- | 26 Jan 14:18 2015

spec complain: css letter-spacing in tabs not clear

​please help us on this bug, we are having spec interpretation issues:

Alan Stearns | 26 Jan 23:55 2015

[css-text-4] text-wrap:balance take 2

Hey all,

I’ve taken the last round of suggestions and updated the definition of 
text-wrap:balance. The changes are meant to satisfy these requirements:

1. The number of lines should not change
2. Balancing should consider float widths
3. Balancing should only occur within a block with direct inline box 

The definition is now:

- - - -
    Same as normal for inline-level elements. 
    For block-level elements that contain 
    line boxes as direct children, 
    line breaks are chosen to balance 
    the inline-size those line boxes consume. 
    This must not change the number of line boxes 
    the block would contain 
    if text-wrap were set to normal.

    For balancing purposes, 
    the inline-size to consider includes 
    any length taken up by floats 
    that shorten the line box. 
    Line boxes are balanced when 
    the deviation from the average inline-size consumed 
    is reduced over the block 
    (including lines that end in a forced break).

    The exact algorithm is UA-defined.

    UAs may treat this value as normal 
    if there are more than ten lines to balance.
- - - -

Please pile on with more improvements.