This module introduces logical properties and values that provide the author with the ability to control layout through logical, rather than physical, direction and dimension mappings. The module defines logical properties and values for the features defined in [CSS21]. These properties are writing-mode relative equivalents of their corresponding physical properties.
CSS is a language for describing the rendering of structured documents
(such as HTML and XML)
on screen, on paper, in speech, etc.
Status of this document
This is a public copy of the editors’ draft.
It is provided for discussion only and may change at any moment.
Its publication here does not imply endorsement of its contents by W3C.
Don’t cite this document other than as work in progress.
GitHub Issues are preferred for discussion of this specification.
When filing an issue, please put the text “css-logical-props” in the title,
preferably like this:
“[css-logical-props] …summary of comment…”.
All issues and comments are archived,
and there is also a historical archive.
Properties that accept physical directional keyword values
(top, bottom, left, or right) are redefined
to also accept the appropriate logical directional keywords.
In such cases,
the logical values can be used in place of the corresponding physical values.
For properties that take multiple keywords, combinations of logical and
physical values are not allowed (unless otherwise specified in a future specification).
Properties can be either 1-dimensional or 2-dimensional.
When contextually constrained to one dimension,
the logical keywords are shortened.
The caption-side property is 1-dimensional in CSS2.1,
but was 2-dimensional in CSS2.0,
(and presumably will be 2-dimensional again in the next update to CSS tables).
It therefore accepts the full set of logical directions.
However, the inline-start and inline-end properties
(which correspond to the behavior of the left and right values in CSS2.0)
are only required to be supported by UAs that support left and right.
1.2. Logical Values for the float and clear Properties
In CSS, all pages are classified by user agents as either left pages
or right pages. [CSS21] Which page is first in a spread, however,
depends on whether the page progression is left-to-right or right-to-left.
To allow control of page breaking to the page that is on the earlier
or later side of a spread, rather than to the left or right side of a
spread, this module introduces the following additional keywords for the page-break-after and page-break-before properties [CSS21]:
Equivalent to right in left-to-right page progressions
and left in right-to-left page progressions.
Equivalent to left in left-to-right page progressions
and right in right-to-left page progressions.
Logical page selectors are also added to support logical page selection.
Authors typically place page numbers using physical placements,
but the contents of headers often follows conventions depending
on which page in the spread is earlier.
A computed value that has logical and physical properties
is determined by applying the CSS cascade to declarations of both.
Overriding is not determined by whether a declaration is logical or physical,
but only by the rules of the CSS cascade [CSS3-CASCADE].
Note that this requires implementations to maintain
relative order of declarations within a CSS declaration block,
which was not previously required for CSS cascading.
For example, given the following rule:
The shorthand properties for margin, padding, and border set values
for physical properties by default. But authors can specify the logical keyword at the beginning of the property value to indicate that the values
map to the logical properties instead of the physical ones.
other candidates of the keyword are: relative, script, writing-mode, beas, or the value itself (e.g., vertical-lr-ltr)
The following [CSS21] shorthand properties accept the logical keyword:
is this the right default? we need to investigate which is more common
This property defines whether background images are transformed to match to
the value of writing-mode property, and whether background-size widths and
heights are logical or physical. Values have the following meanings:
The values for the background-size property are logical.
The background images are transformed to match to the logical axis.
The values for the background-size property are physical.
The background images remain unchanged.
Similar to logical, except that the inline direction is ignored.
The result is affected only by the block flow direction.
The repeat-x and repeat-y values are logical, but in CSS3 this
property can also accept double values to specify horizontal and vertical
behaviors separately. The double values are considered logical if the logical keyword is specified, otherwise physical.
should also add repeat-horizontal and repeat-vertical for the physical value?
Conformance requirements are expressed with a combination of
descriptive assertions and RFC 2119 terminology. The key words “MUST”,
“MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this
document are to be interpreted as described in RFC 2119.
However, for readability, these words do not appear in all uppercase
letters in this specification.
All of the text of this specification is normative except sections
explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example",
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from the
normative text with class="note", like this:
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention and are
set apart from other normative text with <strong class="advisement">, like
this: UAs MUST provide an accessible alternative.
Conformance to this specification
is defined for three conformance classes:
A style sheet is conformant to this specification
if all of its statements that use syntax defined in this module are valid
according to the generic CSS grammar and the individual grammars of each
feature defined in this module.
A renderer is conformant to this specification
if, in addition to interpreting the style sheet as defined by the
appropriate specifications, it supports all the features defined
by this specification by parsing them correctly
and rendering the document accordingly. However, the inability of a
UA to correctly render a document due to limitations of the device
does not make the UA non-conformant. (For example, a UA is not
required to render color on a monochrome monitor.)
An authoring tool is conformant to this specification
if it writes style sheets that are syntactically correct according to the
generic CSS grammar and the individual grammars of each feature in
this module, and meet all other conformance requirements of style sheets
as described in this module.
Requirements for Responsible Implementation of CSS
The following sections define several conformance requirements
for implementing CSS responsibly,
in a way that promotes interoperability in the present and future.
So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid
(and ignore as appropriate)
any at-rules, properties, property values, keywords, and other syntactic constructs
for which they have no usable level of support.
In particular, user agents must not selectively ignore
unsupported property values and honor supported values in a single multi-value property declaration:
if any value is considered invalid (as unsupported values must be),
CSS requires that the entire declaration be ignored.
Implementations of Unstable and Proprietary Features
Once a specification reaches the Candidate Recommendation stage,
implementers should release an unprefixed implementation
of any CR-level feature they can demonstrate
to be correctly implemented according to spec,
and should avoid exposing a prefixed variant of that feature.
To establish and maintain the interoperability of CSS across
implementations, the CSS Working Group requests that non-experimental
CSS renderers submit an implementation report (and, if necessary, the
testcases used for that implementation report) to the W3C before
releasing an unprefixed implementation of any CSS features. Testcases
submitted to W3C are subject to review and correction by the CSS