CSS WG Blog » i18nCascading Style Sheets Working Group Blog2015-02-28T18:23:12Zhttp://www.w3.org/blog/CSS/feed/atom/WordPressfantasaihttp://www.w3.org/blog/CSStemp/2007/12/12/case_sensitivity/2011-09-22T23:35:42Z2007-12-12T21:17:29Z]]>Case-insensitivity in CSS is currently not precisely defined. The meaning of “case-insensitive” is pretty obvious in ASCII, but it’s not so obvious in Unicode. Some characters map differently based on the locale, some characters can’t round-trip a case mapping operation so you get different matches depending on whether you map to lowercase, uppercase, or “case-fold” case, etc.

What the case mapping should be for CSS-defined identifiers such as property and keyword names.

What the case mapping should be for user-defined identifiers such as counters and page names.

For the first issue, since CSS-defined identifiers only use characters
in the ASCII range anyway, ASCII case-insensitivity would be sufficient.
It would also prevent strings containing characters outside the ASCII
range from unexpectedly matching CSS keywords (which could cause
security problems).

For the second issue, we could adopt the Unicode case-folding algorithm,
which is at least well-defined. However a test shows that
implementations already treat counter names as case-sensitive. This is
interoperable across all four major CSS counters implementations:
Firefox, Opera, Safari, and PrinceXML (an HTML/XML + CSS -> PDF
converter).
Also because it’s much more straightforward than case-insensitivity in
Unicode, case-sensitivity is more likely to be interoperable going forward.
The downside is that case-sensitive counters could be more confusing for
authors used to case-insensitive CSS.

Status

The W3C has a Japanese Layout Task Force, which is a joint effort of the I18n, XSL, SVG, and CSS working groups. Their current goal is to document layout requirements for Japanese documents so that W3C working groups can incorporate them into their respective technologies. Most meetings are face-to-face in Japan in Japanese, but there was a bilingual F2F last week in Tokyo, and fantasai was able to attend for the CSSWG and report back. The intention of the task force is to create a W3C Note in English. So far only Part I, which mostly covers page-level layout, has been written and translated. The task force plans to finish most of parts II and III by the November 2007 W3C Technical Plenary.

RESOLVED

The CSSWG resolved to create a parallel document that explains how CSS can or plans to accomplish each of the requirements in the JTF document and highlights places where CSS currently does not handle the requirements. This document will be written on the wiki.

RESOLVED

The shift direction (direction of superscripts wrt the baseline) in vertical text by default is left to right, i.e. consistent with the default orientation of Western scripts.

The breadth (e.g. line length) of an auto-height vertical block in horizontal flow shall be limited by default to the height of the viewport. This is accomplished by defining max-height: none to be equivalent to max-height: 100vh (i.e. the height of the viewport) in this case. The analogous solution shall be applied to horizontal blocks in vertical flow.

Rationale: This preserves readability in the default case: the document can always be scrolled such that the lines fit within the viewport even though it may be a little awkward. The author can and should set more appropriate constraints. This follows the “DBaron Principle”.

Comments: It was noted that a particularly elegant way to handle such blocks would take advantage of the multi-col module. However that module has a problem in that it doesn’t define behavior for blocks with a totally unconstrained “width” (which so far hasn’t ever happened in CSS) and an auto “height” with a max constraint (i.e. the parent’s available width). This is recorded as issue 1 in the Multi-Column issues list.

DBaron Principle

The DBaron Principle states: If the most important cases are handled by a reasonable specification, then the remaining edge cases can be treated by a simple rule that everyone agrees to implement interoperably, even if that rule is not ideal in all cases.