Benjamin Poulain | 31 Oct 02:47 2014

[selectors] Minor issue with section 2 "Selectors Overview"


The section 2 has a table with example of selectors. On the right hand side, there is the level in which the given selector was introduced.

I noticed a mistake:
:indeterminate, :required, :optional
are all marked as “4”, that should be “3-UI/4” since those were introduced in CSS 3 UI:

James Craig | 31 Oct 00:34 2014

[mediaqueries] CSS "prefers-" media features (from TPAC discussion)

Thanks for discussing this topic during the CSS WG meeting at TPAC. I think it's important to raise the new
distinction of a "prefers-" media feature as opposed to an applied one. For example, some of the iOS 7+ and
OS X Yosemite (10.10) settings might be exposed as:

• prefers-reduced-motion
  Allows certain views to remove or tone down animations. For example, launching an app
  on iOS 7 and iOS 8 changes to a subtle dissolve animation rather than a full-screen zoom.

• prefers-reduced-transparency
  Allows certain translucent views to switch to an opaque rendering.

• prefers-differentiation-without-color (this media feature name needs work)
  Allows certain views to change from color-dependent renderings. Messages app on OS X changes 
  status icons from red/green/orange circles to red squares, green circles, and orange triangles.

Changing these user settings don't change the rendering of anything. It just conveys a user preference
that allows the frameworks, native apps, or web apps to adjust for this user preference/desire/need.

I should also note these proposed names don't fit well within the "none or truthy" pattern of some existing
media features. It'd be awkward to specify that "prefers-reduced-motion: none" means "user is okay with
animation." The none value here may be open to misinterpretation, so please consider a "default" or
"no-preference" value that behaves like "none" for boolean comparisons.

  prefers-reduced-motion: [ default | reduce ];
  prefers-reduced-motion: [ no-preference | reduce ];

Thanks for considering,

PS. I plan to post new thread topics for high/increased contrast (including the MS proposal) and full
keyboard access media features. Those are specific and complex enough that they deserve their own threads.

Zack Weinberg | 30 Oct 17:58 2014

[css-fonts] font prefetch hints

This is related to, but abstractly independent of, the font-timeout
behavior proposal being discussed in another thread.  I like that
proposal, but I think there's an additional, independent high-level
knob that could be very useful to authors.

Right now,  <at> font-face { ... } often doesn't trigger an immediate
fetch, because browsers are optimizing for minimal network traffic, on
the assumption that they're not going to need any particular font
until layout tells them otherwise.  In the increasingly common case
where sites want to specify exact fonts for everything, this is the
wrong move; browsers ought to kick off loads immediately upon
encountering the  <at> font-face.

On the other hand, sometimes a site might want to specify a whole
bunch of  <at> font-face rules in a site-wide CSS file, that may or may not
be relevant on any given page; the example that comes to mind is
Wikipedia, on which any given page *might* include a few words in some
script other than that used for the primary language, and they'd like
not to have to worry about whether the reader's OS shipped fonts for
that script.

This is orthogonal to the 'font-rendering: optional/swap/mandatory'
mechanism because a font might be mandatory *if used on a particular
page*, but unnecessary to download until it's known to be needed --
math and icon fonts, or those alternate-script fonts (for which one
would probably use local() to further hint that system fonts will do
if available).  Conversely, a font used for body copy on every page,
but chosen for design reasons, would probably be 'optional' or 'swap'
but the author would like to tell the browser that it really should
start loading it now because it WILL be used.

I can imagine heuristics that would do a reasonably good job of
inferring whether a load should start immediately from things like
presence or absence of 'unicode-range', whether the font is being
applied to high-level structuring elements (<body>, <main>, etc), and
like that, but they are probably too heavyweight to apply for
prefetching.  It might even be nice to be able to hoist font-prefetch
hints out of the style sheet into <link> tags, so those loads can
proceed concurrently with the load of the style itself!  (N.B. FF
doesn't parse style incrementally and it would be a major overhaul to
change that.)

Concrete suggestion: in  <at> font-face,

    prefetch: auto | true | false

'auto', the default, means whatever happens now; 'true' means browsers
SHOULD load this font immediately, and 'false' means they SHOULD NOT.

(Can we stop adding redundant 'font-' prefixes to  <at> font-face
descriptors where not necessary for parallel structure with font-*
properties in style rules, please?)


Manuel Rego Casasnovas | 30 Oct 16:24 2014

[css-grid] Editioral: Move "Z-axis Ordering" section under "Grid Items"


this is just a suggestion, but for me the "9.5. Z-axis Ordering" section
seems out of place under "9. Alignment":

IMHO, it could be moved to "4. Grid Items" section. Like in the flexbox

Just my 2 cents,

Rik Cabanier | 29 Oct 18:01 2014

[css-images] gradient interpolation hint


the CSS images level 4 spec defines the color interpolation hint to move the midpoint color between 2 color stops [1].
This was recently added to WebKit [2], Blink [3] and Firefox [4].  Since we now have 3 implementations, can this be added to level 3?

Koji Ishii | 29 Oct 10:26 2014

[css-text] Justification opportunity exists between different values of text-justify?

Since the text-justify property[1] is applied to "block containers and, optionally, inline
elements”, given the following example:

<span style=“text-justify:inter-character”>a</span><span style=“text-justify:none”>b</span>

should there be a justification opportunity between “a” and “b”?



Bobby Tung | 29 Oct 01:14 2014

Serif / italic is not a good solution for Kai

As we discussed in TPAC day 2 afternoon. 

There is a reason for not use italic of serif for Kai. Because one more frequently used font in print book in Chinese:

Imitation song: [zh] 仿宋體(fang songti), [ja]宋朝体(Sochotai) [1] is considered to be italic of serif. It is discussed by Japanese typography community.

It can be done by <at> font-face, but all operating systems do not have imitation song. If authors want to use, they should embed the font or by webfont.

So their should be another way to make it easier. 

font-family: "whatkindlesKai", "whatlinuxkai", "STKaiti-TC", "DFKai-SB";  not a good idea.

System font for Kai is not a problem, here's a list for reference [3]. DFKai-SB as a Chinese system font for Windows 95, not till Windows Vista, there's no sans-serif system font.

/Bobby Tung

Koji Ishii | 28 Oct 10:22 2014

[css-text][selectors] Right align only if single line

An author asked me if it’s possible to right align if single line, otherwise left align.

She creates a list of quoted articles, and each article has its source like this:

Multiple lines of text text text...
- New York Times, Oct 28th, 2014

She wants the source line be right aligned if single line, but she wants left aligned if more than single line
because using right align to multiple lines for this purpose does not look good.

She thought she can do this by:
  text-align: left;
  text-align-last: right;
but since text-align-last applies not only to single line but also the last line of multiple lines, it
doesn’t work as she expected.

One idea to solve this is to introduce a pseudo selector for single line. I first thought it’s not great,
since when such selector makes font size smaller and the new result fit into single line, that’s a source
of troubles, but then I find we already have :blank, which could be in similar situation if author sets the
content property, so I’m guessing it’s a needless fear.

The other idea is to add the text-align-single property. I merely remember I had a discussion on this with
someone but don’t remember well.

Thoughts? Other ideas to solve this better?


fantasai | 28 Oct 06:41 2014

[css-flexbox] Alignment differences should depend on wrapping not # lines

   # The align-content property aligns a flex container’s lines
   # within the flex container when there is extra space in the
   # cross-axis, similar to how justify-content aligns individual
   # items within the main-axis. Note, this property has no
   # effect when the flex container has only a single line.

   # When a flex container (even a multi-line one) has only one
   # line, the cross size of the line is the cross size of the
   # flex container, and align-content has no effect.

This makes the alignment behavior of flex items depend on whether
the content wraps. So, for example, if an author wanted to center
all the items with 'align-content: center', and assumed that they
would wrap, and I happened to open the page on a really wide monitor,
or there were fewer database items than the author tested, suddenly
the items would no longer be centered.

We should fix this by making the alignment behavior depend on
the value of 'flex-wrap', not on how many lines were in the
flex container.


Robert O'Callahan | 27 Oct 23:36 2014

[css3-transforms] 3D transform updates

Thanks for doing this! The spec is much improved.

Putting all non-3D content of a 3D rendering context at the very bottom of z-order seems simpler and more robust than putting it at z=0 as the spec currently says. Authors can usually opt into the z=0 effect by wrapping content in a trivial 3D transform. There is one case where they can't: as written, a preserve-3d child of the root element can be partially behind and partially in front of a 'position:fixed' element. Is that something we want to support --- or something we explicitly *don't* want to support?

Do we know anything about how Web-compatible the spec changes are?

oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo
otohoeo ofoioroeo ooofo ohoeololo.
Koji Ishii | 27 Oct 14:05 2014

Korean Hangul-only traditional layout?

I was reading KLREQ[1] and have got a fundamental (I think) question.

In my understanding, there are 3 types of Korean documents:
1. Hangul-only (with Latin mixed) documents.
2. Hangul + some Han, with Latin mixed documents.
3. Han-only (sometimes with a few Hangul) documents.

>From layout characteristic perspective, #1 and #2 are similar to Latin; words are split by spaces, though
there’s a stylistic variation to allow line breaks at any character boundaries.

#3 is different from these two in that it’s closer to Chinese; such documents do not use spaces to delimit
words, and they always allow line breaks at any character boundaries.

When I was reading KLREQ, I found some examples such as pictures in [2] or [3] that consist of only Hangul
characters, but I can’t find any spaces to delimit words in these examples.

What typographic characteristics do these documents have? Should they be layout like traditional Korean
documents (i.e., Chinese documents,) such as expanding between any letters when justified?

Currently, based on the understanding I mentioned at the top of this e-mail, the CSS WG thinks Korean
authors can use #1/#2 layout with lang=“ko”, and can switch to #3 by specifying lang=“ko-hani”.
If there were documents that consist of only (or-mostly) Hangul but have Chinese-like layout, this idea
may not be great.