1. 序論
最初に~CSS仕様が公表されたときの `CSS Level 1$ は、 ~CSSを成すすべてを一つの文書~内に包含するよう定義された。 `CSS Level 2$ も,単独の, 複数~章からなる文書により定義された。 しかしながら,~Level 2 を超える~CSSからは、 ~CSS~WG†は,すべてを単体的な仕様~内に定義するのをやめ、 各~moduleが~CSSのある部分を定義するような,~modular~approachを採用することにした。 これは、 仕様をより管理し易い部分ごとに分け, ~CSSを速やかかつ増分的に改善することを許容する。 ◎ When the first CSS specification was published, all of CSS was contained in one document that defined CSS Level 1. CSS Level 2 was defined also by a single, multi-chapter document. However for CSS beyond Level 2, the CSS Working Group chose to adopt a modular approach, where each module defines a part of CSS, rather than to define a single monolithic specification. This breaks the specification into more manageable chunks and allows more immediate, incremental improvement to CSS.
【† ~WGは、 `Working Group^en の略語 — この訳では、 一律に “~WG” と表記する。 】
各~CSS~moduleの安定性は,それぞれに異なる~levelにあるので、 ~CSS~WGは、 2024年現在における~CSSの視野と状態を定義するものとして, この~profileを公表することにした。 ◎ Since different CSS modules are at different levels of stability, the CSS Working Group has chosen to publish this profile to define the current scope and state of Cascading Style Sheets as of 2024.
1.1. ~CSSとは何か?
- `~CSS@ ( `Cascading Style Sheets^en, 略称 `CSS^en ) ◎ Cascading Style Sheets (CSS)
- ~CSSは、 `~stylesheet$を書くための言語であり, 様々な媒体~上で有構造~文書(~HTMLや~XMLなど)の具現化を述べるために設計される。 ~CSSは,`~source文書$の呈示を述べるために利用され、 通例的に,当の文書の`文書~言語$により表出された下層の意味論は変更しない。 ◎ CSS is a language for writing style sheets, and is designed to describe the rendering of structured documents (such as HTML and XML) on a variety of media. CSS is used to describe the presentation of a source document, and usually does not change the underlying semantics expressed by its document language.
- 【 “具現化( `rendering^en )” — 視覚-媒体であれば~~描画, 聴覚-媒体であれば~~音声化, 等々により,当の媒体に内容を具現化して呈示することを意味する。 和訳においては、 文脈に応じて単に “~~描画”, “~~音声化” 等々と記される。 ~~音声化に関わる~CSS仕様は、 現時点では, `CSS-SPEECH-1$r の他には ごく一部 ( `CSS-COUNTER-STYLES-3$r の `§ 発話~合成@~CSSCOUNTER#counter-style-speak-as$など) に限られるが。 】
- `~stylesheet@ ( `style sheet^en ) ◎ Style sheet
- 文書の呈示を指定する一群の規則からなる集合。 ~stylesheetは、 文書を`利用者$に呈示するために, `作者$により書かれ, `~UA$により解釈される。 ◎ A set of rules that specify the presentation of a document. Style sheets are written by an Author, and interpreted by a User Agent, to present the document to the User.
- `~source文書@ ( `source document^en ) ◎ Source document
- 1 つ以上の~stylesheetが適用される文書。 ~source文書の構造と意味論は、 `文書~言語$(例:~HTML/~XML/~SVG)を利用して符号化される。 ◎ The document to which one or more style sheets apply. A source document’s structure and semantics are encoded using a document language (e.g., HTML, XHTML, or SVG).
- `作者@ ( `author^en ) ◎ Author
- [ 文書, それに結付けられた~stylesheet ]を書く者。 `著作~tool@ ( `authoring tool^en )は、 ~stylesheetを生成する`~UA$である。 ◎ An author is a person who writes documents and associated style sheets. An authoring tool is a User Agent that generates style sheets.
- `利用者@ ( `user^en ) ◎ User
- 文書を[ 視る, 聴く, その他~利用する ]ために~UAとヤリトリする者。 ◎ A user is a person who interacts with a user agent to view, hear, or otherwise use the document.
- `~UA@ ( `user agent^en, 略称 `UA^en ) ◎ User Agent (UA)
- `利用者$に利するために[ 文書, それに結付けられた`~stylesheet$ ]を解釈する,任意の~program。 `~UA$は、 文書を表示する, 読み上げる, 印刷させる, 別の形式へ変換する, 等々 を行い得る。 ~CSS仕様の目的においては、 ~UAは,それら各~仕様に定義されるとおり`~CSS$を~supportして解釈する~UAである。 ◎ A user agent is any program that interprets a document and its associated style sheets on behalf of a user. A user agent may display a document, read it aloud, cause it to be printed, convert it to another format, etc. For the purposes of the CSS specifications, a User Agent is one that supports and interprets Cascading Style Sheets as defined in these specifications.
1.2. 背景0: ~W3C批准過程と~CSS
◎非規範的`~W3C批准過程@https://www.w3.org/policies/process/$cite ( `W3C Process^en )において勧告への行程( `Recommendation-track^en )にある文書は、 以下に要約される 3 ~levelの安定性を通過する: ◎ In the W3C Process, a Recommendation-track document passes through three levels of stability, summarized below:
- `作業草案@~W3C-TYPES#WD$ ( `Working Draft^en, 略称 `WD^abbr )
- これは、 ~W3C仕様の設計~相である。 ~CSS~WGは、 内外からの~feedbackに呼応して仕様を~~更新し続ける。 ◎ This is the design phase of a W3C spec. The WG iterates the spec in response to internal and external feedback.
- 最初の公式的な作業草案は、 `最初の公な作業草案@~W3C-TYPES#FPWD$ ( `First Public Working Draft^en, 略称 `FPWD^abbr ) として指名される。 ~CSS~WGによる `FPWD^abbr の公表ngは、[ 編集者による草案にて大まかな視野が定められ, 提案された, 当の~moduleにおける作業 ]に~CSS~WGが全体として合意したことを指示する。 ◎ The first official Working Draft is designated the “First Public Working Draft” (FPWD). In the CSSWG, publishing FPWD indicates that the Working Group as a whole has agreed to work on the module, roughly as scoped out and proposed in the editor’s draft.
- 次の段階への移行は、 “最終作業草案” ( `Last Call Working Draft^en, 略称 `LCWD^abbr )相と呼ばれることもある。 ~CSS~WGは、 既知な課題すべてが解決され, ~testと実装の~buildから得られる~feedback抜きにはそれ以上~進捗できなくなったとき、 作業草案へ移行する。 ◎ The transition to the next stage is sometimes called “Last Call Working Draft” (LCWD) phase. The CSSWG transitions Working Drafts once we have resolved all known issues, and can make no further progress without feedback from building tests and implementations.
- この段階における “`Last Call for Comments^en” は、 明らかになった課題の報告期限を設定し、 ~CSS~WGが~feedbackを追跡して特別に取組むことを要求する。 それらの~commentを追跡している文書は、 各~commentに対する処置集( `Disposition of Comments^en, 略称 `DoC^abbr )と呼ばれる。 それは、 広範からの考査と受容を実証して, `Director^en から認可を得るため、 更新された草案に伴って提出される。 ◎ This “Last Call for Comments” sets a deadline for reporting any outstanding issues, and requires the WG to specially track and address incoming feedback. The comment-tracking document is the Disposition of Comments (DoC). It is submitted along with an updated draft for the Director’s approval, to demonstrate wide review and acceptance.
- `勧告候補@~W3C-TYPES#candidate-recommendation$ ( `Candidate Recommendation Draft^en, 略称 `CRD^abbr / `Candidate Recommendation Snapshot^en, 略称 `CR^abbr )
- これは、 ~W3C仕様を~testする相である。 この相は、[ 実装を~testするためではなく、 各種~testと実装を利用して,仕様を~testするためにある ]ことに特に注意。 仕様における更なる問題は,この過程で露呈することが多いので、 勧告候補は,実装と~testingからの~feedbackに呼応して,時を経て~~形を変えていくことになる — 通例的には、 設計~相( `WD^abbr )よりは少ないが。 ◎ This is the testing phase of a W3C spec. Notably, this phase is about using tests and implementations to test the specification: it is not about testing the implementations. This process often reveals more problems with the spec, and so a Candidate Recommendation will morph over time in response to implementation and testing feedback, though usually less so than during the design phase (WD).
- 勧告候補から次へ~~昇格するためには、[ 互いに独立な 2 つ以上の実装が,各~特能を正しく実装したこと ]の実証が要求される。 そのため,~CSS~WGは、 この相において,~test一式( `test suite^en )を~buildして実装~報告を生成する。 ◎ Demonstration of two correct, independent implementations of each feature is required to exit CR, so in this phase the WG builds a test suite and generates implementation reports.
- 次の段階への移行は、 `勧告案@~W3C-TYPES#PR$ ( `Proposed Recommendation^en, 略称 `PR^abbr ) である。 この相においては、 `W3C Advisory Committee^en は,勧告への移行を認可しなければナラナイ。 ◎ The transition to the next stage is “Proposed Recommendation” (PR). During this phase the W3C Advisory Committee must approve the transition to REC.
- `勧告@~W3C-TYPES#REC$ ( `Recommendation^en, 略称 `REC^abbr )
- これは、 ~W3C仕様が完了した状態であり, 保守~相を表現する。 この時点から、 ~CSS~WGは,正誤表( `errata^en )文書のみを保守するが、 ときには,正誤表を仕様に組入れて更新した版を公表する。 ◎ This is the completed state of a W3C spec and represents a maintenance phase. At this point the WG only maintains an errata document and occasionally publishes an updated edition that incorporates the errata back into the spec.
`編集者草案@ ( `Editor’s Draft^en, 略称 `ED^abbr )は、 実質的に,編集者の自前の作業用~複製をそのまま~~反映するものである。 それは、 ~CSS~WGによる総意を反映することも, しないこともあり, その時点では自己不整合な状態にもなり得る。 (~W3Cにおける公表ng過程は,~~時間と~~労力を要するので、 `編集者草案$は,通例的に仕様に対する最良な(かつ最新の)参照である。 公式的な草案が定期的に~~更新され, `編集者草案$が元の構想場としての~~機能に~~戻れるよう、 各~公表版の不一致を抑制する労が現在~~行われている。) ◎ An Editor’s Draft is effectively a live copy of the editors’ own working copy. It may or may not reflect Working Group consensus, and can at times be in a self-inconsistent state. (Because the publishing process at W3C is time-consuming and onerous, the Editor’s Draft is usually the best (most up-to-date) reference for a spec. Efforts are currently underway to reduce the friction of publishing, so that official drafts will be regularly up-to-date and Editor’s Drafts can return to their original function as scratch space.)
【 編集者草案は、 上述した各~安定性~levelと排他的でないし,それらとの順序関係もない。 同じ~URLで,例えば勧告候補として一時的に公表されることもあり、 その後も,編集者草案として更新され続け得る (場合によっては、勧告に達した後でも)。 】
2. 各種~CSS仕様の分類
すべての~CSS~moduleの一覧, 安定的なものと進捗-中なもの, それらの位置付けは、 `CSS Current Work@https://www.w3.org/Style/CSS/current-work$cite ~pageにて見出せる。 ◎ A list of all CSS modules, stable and in-progress, and their statuses can be found at the CSS Current Work page.
2.1. ~CSSの公式的な定義
この~profileは、 安定的 `かつ^em 十分に実装~経験が得られ, 安定性について確かなものと見なされた仕様のみを含む。 ◎ This profile includes only specifications that we consider stable and for which we have enough implementation experience that we are sure of that stability.
注記: これは、 `CSS Desktop Browser Profile^en (~CSSの~desktop~browser用の~profile)として意図されるものではない: この~profileは、 特能を,その安定性のみに基づいて含めており、 期待される利用や~Web~browserによる採用に基づいてはいない。 この~profileは、 最も完全な形で~CSSを定義する。 ◎ Note: This is not intended to be a CSS Desktop Browser Profile: inclusion in this profile is based on feature stability only and not on expected use or Web browser adoption. This profile defines CSS in its most complete form.
2024年現在の~CSS( `Cascading Style Sheets@ )は、 以下に挙げる仕様で定義される。 ◎ As of 2024, Cascading Style Sheets (CSS) is defined by the following specifications.
- `CSS Level 2, 最新な改訂版@~TR/CSS2/$cite (正誤表も含む) `CSS2$r 【`和訳@~CSS22J$/`和訳(部分訳)@~CSS2J$】 ◎ CSS Level 2, latest revision (including errata) [CSS2]
- ~CSSの中核を定義する。 うち一部【今や,大部分】は、 後の仕様により上書きされる。 特に, `§ 2@~CSS22/intro.html$ を読むよう~~勧める — それは、 ~CSSとその設計~原則についての基本的な概念の一部を導入する。 ◎ This defines the core of CSS, parts of which are overridden by later specifications. We recommend in particular reading Chapter 2, which introduces some of the basic concepts of CSS and its design principles.
- `CSS Syntax Level 3@~TR/css-syntax-3/$cite `CSS-SYNTAX-3$r 【`和訳@~CSSSYN$】
- ~CSS2の[ §4.1, §4.2, §4.4, §G ]を置換する。 ◎ Replaces CSS2§4.1, CSS2§4.2, CSS2§4.4, and CSS2§G,\
- ~CSSを構文解析する方法を定義し直す。 ◎ redefining how CSS is parsed.
- `CSS Style Attributes@~TR/css-style-attr/$cite `CSS-STYLE-ATTR$r 【`和訳@~CSSSTYLEATTR$】
- ~CSS宣言を~markup属性~内に埋込む方法を定義する。 ◎ Defines how CSS declarations can be embedded in markup attributes.
- `Media Queries Level 3@~TR/css3-mediaqueries/$cite `CSS3-MEDIAQUERIES$r 【`和訳@~MQ3J$】
- ~CSS2の §7.3 を置換する。 ◎ Replaces CSS2§7.3\
- 媒体に特有な~style用の構文を拡げる。 ◎ and expands on the syntax for media-specific styles.
- `CSS Conditional Rules Level 3@~TR/css-conditional-3/$cite `CSS-CONDITIONAL-3$r 【`和訳@~CSSCOND$】
- ~CSS2の §7.2 を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§7.2,\
- `media$at 規則の定義を入子ngを許容するよう更新する。 ◎ updating the definition of @media rules to allow nesting and\
- 特能~supportの有無を~queryするための `supports$at 規則を導入する。 ◎ introducing the @supports rule for feature-support queries.
- `Selectors Level 3@~TR/selectors-3/$cite `SELECTORS-3$r 【`旧~勧告の和訳@~SELECTORS3J$ / `~level 4 和訳@~SELECTORS4$ 】
- ~CSS2の[ §5, §6.4.3 ]を置換する。 ◎ Replaces CSS2§5 and CSS2§6.4.3,\
- `選択子$の範囲を拡張する。 ◎ defining an extended range of selectors.
- `CSS Namespaces@~TR/css-namespaces/$cite `CSS3-NAMESPACE$r 【`和訳@~CSSNS$】
- `namespace$at 規則を導入して、 名前空間~接頭辞~付き`選択子$を可能にする。 ◎ Introduces an @namespace rule to allow namespace-prefixed selectors.
- `CSS Cascading and Inheritance Level 4@~TR/css-cascade-4/$cite `CSS-CASCADE-4$r 【`~level 5 和訳@~CASCADE$】
- ~CSS2の[ §1.4.3, §6 ], および `CSS-CASCADE-3$r を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§1.4.3 and CSS2§6, as well as [CSS-CASCADE-3].\
- すべての要素~上のすべての~propに値をアテガうために,~style規則を比較照合する方法を述べる。 ~cascade法と継承の仕方により、 すべての要素~上のすべての~propに,値を伝播させる。 ◎ Describes how to collate style rules and assign values to all properties on all elements. By way of cascading and inheritance, values are propagated for all properties on all elements.
- `CSS Values and Units Level 3@~TR/css-values-3/$cite `CSS-VALUES-3$r 【`和訳@~CSSVAL3J$ / `~level 4 和訳@~CSSVAL$】
- ~CSS2の[ §1.4.2.1, §4.3, §A.2.1–3 ]を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§1.4.2.1, CSS2§4.3, and CSS2§A.2.1–3,\
- ~CSSの~prop定義の構文を定義する。 ~CSSの単位たちが成す集合を拡げる。 ◎ defining CSS’s property definition syntax and expanding its set of units.
- `CSS Custom Properties for Cascading Variables Module Level 1@~TR/css-variables-1/$cite `CSS-VARIABLES-1$r 【`和訳@~CSSVAR$】
- すべての~CSS~propが受容する新たな~primitiveな値~型として, ~cascadeする変数を導入すると伴に、 それを定義するための~custom~propを導入する。 ◎ Introduces cascading variables as a new primitive value type that is accepted by all CSS properties, and custom properties for defining them.
- `CSS Box Model Level 3@~TR/css-box-3/$cite `CSS-BOX-3$r 【`~level 4 和訳@~CSSBOX$】
- ~CSS2の[ §8.1, §8.2, §8.3 ( §8.3.1 以外), §8.4 ]を置換する。 ◎ Replaces CSS2§8.1, §8.2, §8.3 (but not §8.3.1), and §8.4.
- `CSS Color Level 4@~TR/css-color-4/$cite `CSS-COLOR-4$r 【`和訳@~CSSCOLOR$】
- ~CSS2の[ §4.3.6, §14.1, §18.2 ], および `CSS-COLOR-3$r を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§4.3.6, CSS2§14.1, and CSS2§18.2, also extends and supersedes [CSS-COLOR-3],\
- ~sRGBを超える各種 色~空間を導入すると伴に, 色~用の値の範囲【および構文】を拡張する。 【!and CSS Object Model extensions for color: CSSOM は他へ移動された】 ◎ introducing an extended range of color spaces beyond sRGB, extended color values, and CSS Object Model extensions for color.\
- `opacity$p ~propも定義する。 ◎ Also defines the opacity property.
- `CSS Backgrounds and Borders Level 3@~TR/css-backgrounds-3/$cite `CSS-BACKGROUNDS-3$r 【`和訳@~CSSBG$】
- ~CSS2の[ §8.5, §14.2 ]を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§8.5 and CSS2§14.2,\
- 背景と~border対する更なる制御を供する — 次を含め ⇒# 背景~画像の多層化, 画像による~border, 落影 ◎ providing more control of backgrounds and borders, including layered background images, image borders, and drop shadows.
- `CSS Images Level 3@~TR/css-images-3/$cite `CSS-IMAGES-3$r 【`和訳@~CSSIMAGE$】
- 外部~2D画像を表す値~型を定義し直して組入れる。 ◎ Redefines and incorporates the external 2D image value type,\
- ~nativeな~2D~gradientを導入する。 ◎ introduces native 2D gradients,\
- 置換d要素の[ ~sizing/描画 ]用の追加的な制御を追加する。 ◎ and adds additional controls for replaced element sizing and rendering.
- `CSS Fonts Level 3@~TR/css-fonts-3/$cite `CSS-FONTS-3$r 【`和訳@~CSSFONT3$】
- ~CSS2の §15 を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§15\
- [ ~fontの~~選択/~font特能の選定 ]に対し,更なる制御を供する。 ◎ and provides more control over font choice and feature selection.
- `CSS Writing Modes Level 3@~TR/css-writing-modes-3/$cite `CSS-WRITING-MODES-3$r 【`和訳@~CSSWM3$】
- ~CSS2の[ §8.6, §9.10 ]を置換して, 拡張する。 ◎ ↓
- 様々な国際的な書字~mode用の~CSS~supportを定義する — 次に挙げるものなど ⇒# 左横書き(例:~Latinや~Indic), 右横書き (例:~Hebrewや~Arabic), 双方向的(例: ~Latinと~Arabicの混在), 縦書き(例:~Asian用字系) ◎ Defines CSS support for various international writing modes, such as left-to-right (e.g. Latin or Indic), right-to-left (e.g. Hebrew or Arabic), bidirectional (e.g. mixed Latin and Arabic) and vertical (e.g. Asian scripts).\ Replaces and extends CSS2§8.6 and §9.10.
- `CSS Multi-column Layout Level 1@~TR/css-multicol-1/$cite `CSS-MULTICOL-1$r 【`和訳@~CSSMCOL$】
- ~CSS~layoutに複-柱(段組)による~flowを導入する。 ◎ Introduces multi-column flows to CSS layout.
- `CSS Flexible Box Module Level 1@~TR/css-flexbox-1/$cite `CSS-FLEXBOX-1$r 【`和訳@~CSSFLEX$】
- ~CSS用の【!flexible linear】~flex~layout~modelを導入する。 ◎ Introduces a flexible linear layout model for CSS.
- `CSS Basic User Interface Module Level 3@~TR/css-ui-3/$cite `CSS-UI-3$r 【`和訳@~CSSUI3J$ / `~level 4 和訳@~CSSUI$】
- ~CSS2の[ §18.1, §18.4 ]を置換する。 ◎ Extends and supersedes CSS2§18.1 and CSS2§18.4,\
- `cursor$p, `outline$p を定義し、 ~UIを増強する,いくつかの新たな~CSS特能も定義する。 ◎ defining cursor, outline, and several new CSS features that also enhance the user interface.
- `CSS Containment Module Level 1@~TR/css-contain-1/$cite `CSS-CONTAIN-1$r 【`~level 2 和訳@~CSSCONTAIN$】
- `contain$p ~propを導入する。 それは、要素の下位treeに対し,独立な~CSS処理を施行する — 上手く利用すれば、~UAによる~~強力な最適化を可能化するような。 ◎ Introduces the contain property, which enforces the independent CSS processing of an element’s subtree in order to enable heavy optimizations by user agents when used well.
- `CSS Transforms Level 1@~TR/css-transforms-1/$cite `CSS-TRANSFORMS-1$r 【`和訳@~TRANSFORM$】
- 座標に基づく~graphicな変形nを~CSSに導入する。 ◎ Introduces coordinate-based graphical transformations to CSS.
- `CSS Compositing and Blending Level 1@~TR/compositing-1/$cite `COMPOSITING$r 【`~level 2 和訳@~COMPOSITING$】
- 多層化された内容の組成-法と混色-法を定義し、 その~modeを制御する特能を導入する。 ◎ Defines the compositing and blending of overlaid content and introduces features to control their modes.
- `CSS Easing Functions Level 1@~TR/css-easing-1/$cite `CSS-EASING-1$r 【`~level 2 和訳@~CSSEASING$】
- 何らかの値が変化する比率を制御する変形nを,作者が定義する仕方を述べる。 そのような変形nを~animationに適用されるよう利用すれば、 慣性などの物理-現象を真似たり, ~robotの様にカクカク動く~animationを生産できる。 ◎ Describes a way for authors to define a transformation that controls the rate of change of some value. Applied to animations, such transformations can be used to produce animations that mimic physical phenomena such as momentum or to cause the animation to move in discrete steps producing robot-like movement.
- `CSS Counter Styles Level 3@~TR/css-counter-styles-3/$cite `CSS-COUNTER-STYLES-3$r 【`和訳@~CSSCOUNTER$】
- `counter-style$at 規則を導入する — それは、~CSS[ ~list~marker /生成d内容による~counter ] `CSS-LISTS-3$r と伴に利用するための,自前の~customな~counter~styleを定義することを作者に許容する。 それはまた、共通な~counter~styleたちが成す集合を予め定義する — ~CSS2, CSS2.1 に在ったものも含め。 ◎ Introduces the @counter-style rule, which allows authors to define their own custom counter styles for use with CSS list-marker and generated-content counters [CSS-LISTS-3]. It also predefines a set of common counter styles, including the ones present in CSS2 and CSS2.1.
注記: ~CSS~WGは、 この~snapshotを形成する各 仕様が有意に変更されるものとは見越していないが、 それらの仕様が凍結されたことを意味するわけではない。 ~CSS~WGは、 仕様に問題が見出されたなら,それに取組み続けることになる。 実装者は、 結果の[ 変更/訂正/明確化 ]について, `www-style@https://lists.w3.org/Archives/Public/www-style/$ や `~CSS~WG Blog@https://www.w3.org/blog/CSS$ を注視するべきである。 ◎ Note: Although we don’t anticipate significant changes to the specifications that form this snapshot, their inclusion does not mean they are frozen. The Working Group will continue to address problems as they are found in these specs. Implementers should monitor www-style and/or the CSS Working Group Blog for any resulting changes, corrections, or clarifications.
2.2. ~~相応に安定的だが実装~経験は限られた~module
以下に挙げる~moduleは、 設計~作業は完了していて,~~相応に安定的であるが、 まだ,~testingと実装~経験が足りていない。 これらは、 将来の~snapshotにおいては, `~CSSの公式的な定義@#css-official$の中に組入れるよう希望されている。 ◎ The following modules have completed design work, and are fairly stable, but have not received much testing and implementation experience yet. We hope to incorporate them into the official definition of CSS in a future snapshot.
- `Media Queries Level 4@~TR/mediaqueries-4/$cite `MEDIAQUERIES-4$r 【`~level 5 和訳@~MQ5$】
- `CSS3-MEDIAQUERIES$r を拡張して,それに取って代わる。 ◎ Extends and supersedes [CSS3-MEDIAQUERIES],\
- 構文を拡げる/ ほとんどの媒体~型を非推奨にする/ 新たな媒体~特能を導入する。 ◎ expanding the syntax, deprecating most media types, and introducing new media features.
- `CSS Display Module Level 3@~TR/css-display-3/$cite `CSS-DISPLAY-3$r 【`~level 4 和訳@~CSSDISP$】
- ~CSS2の[ §9.1.2, §9.2.1 ( §9.2.1.1 以外), §9.2.2 ( §9.2.2.1 以外), §9.2.3, §9.2.4 ]を置換する(および, §9.7 を置換するための土台を~~敷く)。 ◎ Replaces CSS2§9.1.2, §9.2.1 (but not §9.2.1.1), §9.2.2 (but not §9.2.2.1), §9.2.3, and §9.2.4 (and lays the foundations for replacing §9.7),\
- ~CSS整形~box~treeが,文書~要素~treeから どう生成されるかを定義する。 それを制御する `display$p ~propを定義する。 ◎ defining how the CSS formatting box tree is generated from the document element tree and defining the display property that controls it.
- `CSS Writing Modes Level 4@~TR/css-writing-modes-4/$cite `CSS-WRITING-MODES-4$r 【`和訳@~CSSWM$】
- `CSS-WRITING-MODES-3$r を拡張して,それに取って代わる。 ◎ Extends and supersedes [CSS-WRITING-MODES-3],\
- 縦書き用に,もっと~optionを追加する。 ◎ adding more options for vertical writing.
- `CSS Fragmentation Module Level 3@~TR/css-break-3/$cite `CSS-BREAK-3$r 【`~level 4 和訳@~CSSBREAK$】
- ~CSS2の §13.3 を拡張して,それに取って代わる。 ◎ ↓
- 断片化~modelを述べる — それは、~flowを一連の[ ~page / 柱 / 領域 ]の中へ区分する。 それを制御する各種~propを定義する。 ◎ Describes the fragmentation model that partitions a flow into pages, columns, or regions and defines properties that control it.\ Extends and supersedes CSS2§13.3.
- `CSS Box Alignment Module Level 3@~TR/css-align-3/$cite `CSS-ALIGN-3$r 【`和訳@~CSSALIGN$】
- 様々な~CSS~box~layout~model — 塊~layout, ~table~layout, ~flex~layout, 格子~layout — において、 容器の中での ~boxどうしの整列を制御するための各種~propを導入する。 ◎ Introduces properties to control the alignment of boxes within their containers in the various CSS box layout models: block layout, table layout, flex layout, and grid layout.
- `CSS Shapes Module Level 1@~TR/css-shapes-1/$cite `CSS-SHAPES-1$r 【`和訳@~CSSSHAPES$】
- 浮動体(~CSS2の §9.5)を拡張して,矩形でない回込み図形の効果も得られるようにする。 ◎ Extends floats (CSS2§9.5) to effect non-rectangular wrapping shapes.
- `CSS Text Module Level 3@~TR/css-text-3/$cite `CSS-TEXT-3$r 【`~level 4 和訳@~CSSTEXT$】
- ~CSS2の §16( §16.2 は除く)を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§16 excepting §16.2,\
- ~text操作~用の各種~propを定義して,その処理~modelを指定する。 次に挙げるものなどを受持つ ⇒# 行l分断法, 両端揃え, 整列, 空白の取扱い, ~text変形n ◎ defining properties for text manipulation and specifying their processing model. It covers line breaking, justification and alignment, white space handling, and text transformation.
- `CSS Text Decoration Module Level 3@~TR/css-text-decor-3/$cite `CSS-TEXT-DECOR-3$r 【`和訳@~CSSTEXTDECOR$】
- ~CSS2の §16.3 を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS2§16.3,\
- ~text行l装飾に対する更なる制御を供して,~textに圏点や影を指定する能を追加する。 ◎ providing more control over text decoration lines and adding the ability to specify text emphasis marks and text shadows.
- `CSS Masking Module Level 1@~TR/css-masking-1/$cite `CSS-MASKING-1$r 【`和訳@~MASKING1$】
- ~CSS2の §11.1.2 を置換する。 ◎ Replaces CSS2§11.1.2\
- 内容を[ 切抜く/~maskする ]ための より強力な仕方を導入する。 ◎ and introduces more powerful ways of clipping and masking content.
- `CSS Scroll Snap Module Level 1@~TR/css-scroll-snap-1/$cite `CSS-SCROLL-SNAP-1$r 【`和訳@~CSSSCROLLSNAP$】
- “留め位置” に[ ~panする/~scrollする ]ときの挙動を制御するための特能を包含する。 ◎ Contains features to control panning and scrolling behavior with “snap positions”.
- `CSS Speech Module Level 1@~TR/css-speech-1/$cite `CSS-SPEECH-1$r 【`和訳@~CSSSPEECH$】
- ~CSS2の §A を置換する。 ◎ Replaces CSS2§A,\
- ~CSS2の(規範的でない) `speech rendering^en 章を改修する。 ◎ overhauling the (non-normative) speech rendering chapter.
- `CSS Scrollbars Styling Module Level 1@~TR/css-scrollbars-1/$cite `CSS-SCROLLBARS-1$r 【`和訳@~CSSSCROLLBARS$】
- ~scrollbarの視覚的な~style法に波及する各種~propを定義して、 それらの[ 色, 幅 ]用の制御を導入する。 ◎ Defines properties to influence the visual styling of scrollbars, introducing controls for their color and width.
- `CSS View Transitions Module Level 1@~TR/css-view-transitions-1/$cite `CSS-VIEW-TRANSITIONS-1$r 【`和訳@~CSSVT$】
- ~view遷移~API,および それに結付けられる各種[ ~prop, 疑似要素 ]を定義する。 それは、[ 文書~状態における変化を視覚的な遷移として表現する~animation ]を作成することを開発者に許容する。 ◎ Defines the View Transition API, along with associated properties and pseudo-elements, which allows developers to create animated visual transitions representing changes in the document state.
2.3. 概ね相互運用可能な~module
以下に挙げる~moduleは、 `概ね相互運用可能$であり,広範に配備されているが、 まだ,その詳細は[ その策定が全部的に済んでいないか,十分きちんと指定されていない ]ため,更に[ ~testする/~bugをとる ]必要がある。 これらは、 将来の~snapshotにおいては, `~CSSの公式的な定義@#css-official$の中に組入れるよう希望されている。 ◎ Although the following modules have been widely deployed with rough interoperability, their details are not fully worked out or sufficiently well-specified and they need more testing and bugfixing. We hope to incorporate them into the official definition of CSS in a future snapshot.
- `CSS Transitions Level 1@~TR/css-transitions-1/$cite `CSS-TRANSITIONS-1$r 【`和訳@~TRANSITION$】
- `CSS Animations Level 1@~TR/css-animations-1/$cite `CSS-ANIMATIONS-1$r 【`和訳@~CSSANIM$】
- ~CSS~propの算出d値を,時間~越しに遷移させる仕組みを導入する。 ◎ Introduces mechanisms for transitioning the computed values of CSS properties over time.
- `CSS Grid Layout Module Level 1@~TR/css-grid-1/$cite `CSS-GRID-1$r 【`~level 2 和訳@~CSSGRID$】
- ~UI設計に最適化された,二次元な格子に基づく~layout~systemを導入する。 格子~layout~modelにおいては、 格子~容器の各~子を,[ 予め定義された,~sizeが[ ~flex可能/固定d ]な~layout格子 ]内の任意な~slotの中に位置させれる。 ◎ Introduces a two-dimensional grid-based layout system, optimized for user interface design. In the grid layout model, the children of a grid container can be positioned into arbitrary slots in a predefined flexible or fixed-size layout grid.
- `CSS Grid Layout Module Level 2@~TR/css-grid-2/$cite `CSS-GRID-2$r 【`和訳@~CSSGRID$】
- `CSS-GRID-1$r を拡張して,それに取って代わる。 ◎ Extends and supersedes [CSS-GRID-1],\
- “下位格子” を導入する — それは、格子を共有する~frameworkにおいて入子な~markupを管理する。 ◎ introducing “subgrids” for managing nested markup in a shared grid framework.
- `CSS Will Change Level 1@~TR/css-will-change-1/$cite `CSS-WILL-CHANGE-1$r 【`和訳@~CSSWILLCHANGE$】
- `will-change$p と呼ばれる,処理能~hint~propを導入する。 ◎ Introduces a performance hint property called will-change.
- `Filter Effects Module Level 1@~TR/filter-effects-1/$cite `FILTER-EFFECTS-1$r 【`和訳@~FILTERS$】
- 要素が文書~内に表示される前に その描画を処理する仕方として,~filter効果を導入する。 ◎ Introduces filter effects as a way of processing an element’s rendering before it is displayed in the document.
- `CSS Font Loading Module Level 3@~TR/css-font-loading/$cite `CSS-FONT-LOADING-3$r 【`和訳@~CSSFONTLOADING$】
- ~font資源を動的に読込むために利用される各種[ ~event, ~interface ]を導入する。 ◎ Introduces events and interfaces used for dynamically loading font resources.
- `CSS Box Sizing Level 3@~TR/css-sizing-3/$cite `CSS-SIZING-3$r 【`和訳@~SIZING$】
- ~CSS2の §10 の~~上層を成すように,それを拡張する。 ◎ Overlays and extends CSS§10.,\
- 各種~sizing~propの値~集合を拡げる。 ◎ expanding the value set of the sizing properties,\
- もっと精確な[ ~sizingの各種用語 ]を導入する。 ◎ introducing more precise sizing terminology,\
- ~CSS2では曖昧にしか定義されていなかった様々な自動的~sizingの概念を,もっと精密かつ詳細に定義する。 ◎ and defining with more precision and detail various automatic sizing concepts only vaguely defined in CSS2.
- `CSS Transforms Level 2@~TR/css-transforms-2/$cite `CSS-TRANSFORMS-2$r 【`和訳@~TRANSFORM2$】
- `CSS-TRANSFORMS-1$r の上に築かれ、 三次元な変形~用に新たな[ 変形~関数, 変形~prop ]を追加する。 また、単純な変形~用に便利~関数を追加する。 ◎ Builds upon [CSS-TRANSFORMS-1] to add new transform functions and properties for three-dimensional transforms, and convenience functions for simple transforms.
- `CSS Lists and Counters Module Level 3@~TR/css-lists-3/$cite `CSS-LISTS-3$r 【`和訳@~CSSLIST$】
- ~list~counterに関係する~CSS特能を包含する — [ それらを~styleして位置する/ それらの値を操作する ]ための。 ◎ Contains CSS features related to list counters: styling them, positioning them, and manipulating their value.
- `CSS Logical Properties and Values Level 1@~TR/css-logical-1/$cite `CSS-LOGICAL-1$r 【`和訳@~CSSLOGICAL$】
- 論理-[ ~prop, 値 ]導入する — `CSS2$r にて定義された特能~用のそれらも含めて。 これらは、物理的ではなく論理的な[ 方向, 次元 ]の対応付けを通して~layoutを制御する能を作者に供する。 これらの~propは、 書字~modeに相対的な[ 対応する物理-~propと等価なもの ]を定義する。 ◎ Introduces logical properties and values that provide the author with the ability to control layout through logical, rather than physical, direction and dimension mappings. Also defines logical properties and values for the features defined in [CSS2]. These properties are writing-mode relative equivalents of their corresponding physical properties.
- `CSS Positioned Layout Module Level 3@~TR/css-position-3/$cite `CSS-POSITION-3$r 【`和訳@~CSSPOS$】
- ~CSSの各種[ 座標に基づく位置決め/~offset法 ]の~schemeとして,次を定義する ⇒# `相対~位置決め$, `張付き位置決め$, `絶対~位置決め$, `固定d位置決め$ ◎ Contains defines coordinate-based positioning and offsetting schemes of CSS: relative positioning, sticky positioning, absolute positioning, and fixed positioning.
- `Resize Observer@~TR/resize-observer-1/$cite `RESIZE-OBSERVER-1$r
- 要素の`首要~box$の~size変化を観測するための~APIを述べる。 ◎ This specification describes an API for observing changes to element’s principal box’s size.
- `Web Animations@~TR/web-animations-1/$cite `WEB-ANIMATIONS-1$r 【`和訳@~WANIM$】
- ~Web~pageの呈示に対する変化の[ 同期法, 計時 ]用の~modelを定義すると伴に、 この~modelとヤリトリするための~APIも定義する。 ◎ Defines a model for synchronization and timing of changes to the presentation of a Web page. Also defines an application programming interface for interacting with this model.
- `CSS Fonts Module Level 4@~TR/css-fonts-4/$cite `CSS-FONTS-4$r 【`和訳@~CSSFONT$】
- `CSS-FONTS-3$r を拡張して,それに取って代わる。 ◎ Extends and supersedes CSS Fonts 3 and\
- ~font~~選択と~font特能~選定(~OpenType異体~用の~supportも含む)にもっと制御を供する。 ◎ provides more control over font choice and feature selection, including support for OpenType variations.
- `CSS Color Adjustment Module Level 1@~TR/css-color-adjust-1/$cite `CSS-COLOR-ADJUST-1$r 【`和訳@~CSSCOLORADJUST$】
- [ 利用者-選好, 機器~出力の最適化 ]を取扱うための,~UAによる自動的な色~調整の~model, それに対する制御を導入する。 ◎ This module introduces a model and controls over automatic color adjustment by the user agent to handle user preferences and device output optimizations.
- `CSS Conditional Rules Module Level 4@~TR/css-conditional-4/$cite `CSS-CONDITIONAL-4$r 【`和訳@~CSSCOND4$】
- `CSS-CONDITIONAL-3$r を拡張して, `選択子$が~supportされるか否か~testすることを許容する。 ◎ Extends CSS Conditional 3 to allow testing for supported selectors.
- `CSS Cascading and Inheritance Level 5@~TR/css-cascade-5/$cite `CSS-CASCADE-5$r 【`和訳@~CASCADE$】
- `CSS-CASCADE-4$r を拡張して, `~cascade層$を追加する。 ◎ Extends CSS Cascade 4 to add cascade layers.
- `Motion Path Module Level 1@~TR/motion-1/$cite `MOTION-1$r 【`和訳@~MOTION1$】
- [ ~graphicな~objを位置して,それを作者が指定した~pathに沿って~animateする ]ことを作者に許容する。 ◎ This module allows authors to position any graphical object and animate it along an author specified path.
2.4. ~CSSの各~level
~CSSには,伝統的なイミでの~versionは無い — 代わりに,いくつかの `~level@ がある。 ~CSSの各~levelは、 以前のものを基に,定義を精緻化し, 特能を追加して築かれる。 より高~levelな特能たちが成す集合は,より低~levelなものの上位集合になる。 所与のどの特能に対しても、 より高~levelにて許容される挙動は,より低~levelにて許容される挙動の下位集合になり、 より高~levelな~CSSに適合している~UAは,より低~levelなものすべてに適合する。 ◎ Cascading Style Sheets does not have versions in the traditional sense; instead it has levels. Each level of CSS builds on the previous, refining definitions and adding features. The feature set of each higher level is a superset of any lower level, and the behavior allowed for a given feature in a higher level is a subset of that allowed in the lower levels. A user agent conforming to a higher level of CSS is thus also conformant to all lower levels.
- `CSS Level 1@
- ~CSS~WGは `CSS1 仕様@~TR/2008/REC-CSS1-20080411/$cite を廃用と見なしている。 `CSS Level 1$ は、 この CSS1 仕様にて定義された特能(各種[ ~prop, 値, ~at-規則, 等々 ])すべてとして定義されるが、 `CSS2.1 仕様@~TR/CSS2/$cite の構文と定義を利用している。 `CSS Style Attributes@~TR/css-style-attr/$cite 【`和訳@~CSSSTYLEATTR$】 は、要素に特有な~style属性による~CSSの内包を定義する。 ◎ The CSS Working Group considers the CSS1 specification to be obsolete. CSS Level 1 is defined as all the features defined in the CSS1 specification (properties, values, at-rules, etc), but using the syntax and definitions in the CSS2.1 specification. CSS Style Attributes defines its inclusion in element-specific style attributes.
- `CSS Level 2@
- `CSS2 仕様@~TR/2008/REC-CSS2-20080411/$cite は,形上では~W3C勧告であるが、 ~W3Cが勧告候補の段階を定義する前に,勧告に至った。 時を経て、 実装~経験と更なる考査により, CSS2 仕様には多数の問題が明るみに出ている。 そのため,~CSS~WGは、 すでに`長大になった正誤表@https://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html$を拡げる代わりに, CSS Level 2 Revision 1( CSS2.1 )を定義することにした。 二つの仕様~間で競合する事例に対しては、 CSS2.1 が,その決定版の定義を包含する。 ◎ Although the CSS2 specification is technically a W3C Recommendation, it passed into the Recommendation stage before the W3C had defined the Candidate Recommendation stage. Over time implementation experience and further review has brought to light many problems in the CSS2 specification, so instead of expanding an already unwieldy errata list, the CSS Working Group chose to define CSS Level 2 Revision 1 (CSS2.1). In case of any conflict between the two specs CSS2.1 contains the definitive definition.
- CSS2.1 が勧告候補になったとき — その安定性は,公式的には CSS2 と同じ~levelとされていないが — CSS2 勧告は,実質的に廃用にされた。 CSS2.1 から落とされた CSS2 の特能は,勧告候補の段階で考慮されるべきだが、 これらの多くは, `CSS Level 3$ の作業草案にすでに取り込まれたか, そうなる予定にあり、 その取り込んだ仕様が勧告候補に達したなら, CSS2 による定義は廃用にされることになる。 ◎ Once CSS2.1 became Candidate Recommendation—effectively though not officially the same level of stability as CSS2—obsoleted the CSS2 Recommendation. Features in CSS2 that were dropped from CSS2.1 should be considered to be at the Candidate Recommendation stage, but note that many of these have been or will be pulled into a CSS Level 3 working draft, in which case that specification will, once it reaches CR, obsolete the definitions in CSS2.
- `CSS2.1 仕様@~TR/CSS2/$cite は、`CSS Level 2$ を定義する。 `CSS Style Attributes@~TR/css-style-attr/$cite 仕様は、要素に特有な~style属性による~CSSの内包を定義する。 ◎ The CSS2.1 specification defines CSS Level 2 and the CSS Style Attributes specification defines its inclusion in element-specific style attributes.
- `CSS Level 3@
- `CSS Level 3$ は、 その中核に CSS2.1 仕様を利用して,~moduleごとに `CSS Level 2$ の上に築かれている。 各~moduleは、 機能性を追加したり, CSS2.1 仕様の一部を置換する。 ~CSS~WGは、 新たな~CSS~moduleは CSS2.1 仕様と矛盾せず,[ 機能性を追加する/定義を精緻化する ]のみになるものと意図している。 各~moduleは、 完了するに伴い,[ CSS2.1 と完了した~module ]用の既存の~systemに差込まれることになる。 ◎ CSS Level 3 builds on CSS Level 2 module by module, using the CSS2.1 specification as its core. Each module adds functionality and/or replaces part of the CSS2.1 specification. The CSS Working Group intends that the new CSS modules will not contradict the CSS2.1 specification: only that they will add functionality and refine definitions. As each module is completed, it will be plugged in to the existing system of CSS2.1 plus previously-completed modules.
- この~levelから、 各~moduleは,独立に~levelを持つようになる。 例えば `Selectors Level 4^cite は、 `CSS Line Module Level 3^cite 【 `CSS Inline Module^cite ?】より早く,~~十分に完了されるかもしれない。 `CSS Level 2$ に等価なものがない~moduleは,~Level 1 から開始され、 `CSS Level 2$ に存在する特能を更新する~moduleは,~Level 3 から開始される。 【前者の~moduleで~Level 3 に達したものもあり、それらは,~Levelのみからは後者と区別できない(例: `CSS Containment Module^cite )。】 ◎ From this level on modules are levelled independently: for example Selectors Level 4 may well be completed before CSS Line Module Level 3. Modules with no CSS Level 2 equivalent start at Level 1; modules that update features that existed in CSS Level 2 start at Level 3.
- `CSS Level 4@ 以上
- CSS Level 4 は無い。 ~~個別の~moduleは,独立に~level 4 以上へ達し得るが、 言語としての~CSSには,もはや~levelは無い。 (用語としての “CSS Level 3” は、 以前の単体的な~versionと区別するために限り利用される。) ◎ There is no CSS Level 4. Independent modules can reach level 4 or beyond, but CSS the language no longer has levels. ("CSS Level 3" as a term is used only to differentiate it from the previous monolithic versions.)
2.5. ~CSS~profile
すべての実装が,~CSSに定義されるすべての機能性を実装するわけではない。 ◎ Not all implementations will implement all functionality defined in CSS.
~CSS~WGは、 過去には,少数の~profileを公表していた。 それらには、[ 様々な~classの~UAが~supportするものと期待される, 必要最小限な~CSSの下位集合 ]を定義することが意味されていた。 ◎ In the past, the Working Group published a few Profiles, which were meant to define the minimal subset of CSS that various classes of user agents were expected to support.
が、 この労は、 実効性も有用性も見出せなかったので,もう継続されない。 以前に定義された~profileは、 今や保守されていない。 ◎ This effort has been discontinued, as the Working Group was not finding it effective or useful, and the profiles previously defined are now unmaintained.
注記: ~CSSの部分的な実装は、 自身が実装する下位集合が公式的な~profileであるとしても, `部分的な実装@#partial$に課される前方-互換な構文解析~規則に従うモノトスル。 ◎ Note: Partial implementations of CSS, even if that subset is an official profile, must follow the forward-compatible parsing rules for partial implementations.
3. 実装に課される要件
以下の各~節では、 ~CSSを現在tから将来への相互運用能を促す仕方で実装するための, 適合性~要件をいくつか定義する。 ◎ The following sections define several conformance requirements for implementing CSS responsibly, in a way that promotes interoperability in the present and future.
3.1. 部分的な実装
作者が前方-互換な構文解析~規則を活用して,~fallback値をアテガえるようにするため、 ~CSS`具現化器$cfは、[ ~at-規則, ~prop, ~prop値, ~keyword, その他の構文-構成子 ]のうち[ 自身が実用~levelで~supportしないもの ]を無効なものとして扱う(それに伴い,適切に`無視する$)モノトスル。 特に,~UAは、 複数成分からなる値をとる単独の~prop宣言の中で, 自身が~supportする値のみ尊守しつつ, 未~supportな値を選択的に無視してはナラナイ。 いずれかの成分が無効と見なされる場合(未~supportな値は,そう見なすモノトスル)、 それを含む宣言~全体を`無視する$ことが~CSSから要求される。 ◎ 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.
3.2. 不安定な/~proprietaryな特能の実装
将来の安定的な~CSS特能との衝突を避けるため、 ~CSS~WGは,次を推奨する ⇒ ~CSS用の[ `不安定$な特能/`~proprietary拡張$ ]を実装する際には、 以下に挙げる最善な実施に従う。 ◎ To avoid clashes with future stable CSS features, the CSSWG recommends the following best practices for the implementation of unstable features and proprietary extensions to CSS:
3.2.1. 試験運用と不安定な特能
`不安定$な特能 — ~W3C仕様に述べられてはいるが,相互運用可能ではない特能 — の実装は、 一般用途には~releaseされるべきでないが, 制御された環境における[ 制限付きな,試験的な用途 ]には~releaseされてもヨイ。 ◎ Implementations of unstable features that are described in W3C specifications but are not interoperable should not be released broadly for general use; but may be released for limited, experimental use in controlled environments.
何故?
[ 作者, 実装者 ]の両者が特能について試験して~feedbackできるようにしつつ、[ 作者が製品n~web~siteにて,それらに依拠する結果、 後で変更され得る構文や挙動が,(内容の依存性を通して)なし崩し的に “~~固定化される” こと ]を防ぐことも求まれるので。 ◎ We want to allow both authors and implementors to experiment with the feature and give feedback, but prevent authors from relying on them in production websites and thereby accidentally "locking in" (through content dependence) certain syntax or behavior that might change later.
例えば~UAは、 `不安定$な特能を[ 試験運用のために, ~beta版その他の~testing相~buildを通して~releaseする ]こともできる — [ 環境設定~flagの背後に~~隠すこと / 特定の試験的な共同者のみ可能化できる切替手段 / その他 依存性が生じるような利用を制限する何らかの手段 ]を通して。 ◎ For example, a UA could release an unstable features for experimentation through beta or other testing-stage builds; behind a hidden configuration flag; behind a switch enabled only for specific testing partners; or through some other means of limiting dependent use.
仕様が~W3C批准過程における勧告候補( CR )の段階に達するまでは、 当の~CSS特能は `不安定@ と見なされる。 例外的な事例においては、 ~CSS~WGは, CR 段階に達していない特能を — 公式的に記録される解決を通して — [ 一般用途に~releaseしても安全と見なされる集合 ]に追加することもある。 `§ 勧告候補~前に~releaseしても安全な例外@#CR-exceptions$を見よ。 ◎ A CSS feature is considered unstable until its specification has reached the Candidate Recommendation (CR) stage in the W3C process. In exceptional cases, the CSSWG may additionally, by an officially-recorded resolution, add pre-CR features to the set that are considered safe to release for broad use. See § 4 Safe to Release pre-CR Exceptions.
注記: 各~vendorは、 明示的に~CSS~WGに諮るべきであり, この点に関して前提を置くべきでない — 長く~~留め置かれ, CR 段階に達していない仕様は、 通例的に,安定的というより古くなったことを表すので。 ◎ Note: Vendors should consult the WG explicitly and not make assumptions on this point, as a pre-CR spec that hasn’t changed in awhile is usually more out-of-date than stable.
3.2.2. ~proprietaryな/標準~化されていない特能
将来の~CSS特能との衝突を避けるため、 CSS2.1 仕様では,~CSSに対する[ ~proprietary/試験的 ]な拡張~用に `接頭辞~付き構文@ ( `prefixed syntax@~CSS22/syndata.html#vendor-keywords$en ) を予約している。 ある~vendorによる~UAでしか~access可能でない,閉な環境~用途の~CSS特能は、 `~proprietary拡張@ とされる。 ~UAは、 そのような`~proprietary拡張$を[ ~vendor`接頭辞~付き構文$を通してのみ~supportする ]べきであり、 それらを~openな(複-~UAな)環境 — World Wide Web など — に公開するべきでない。 ◎ To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax [CSS2] for proprietary and experimental extensions to CSS. A CSS feature is a proprietary extension if it is meant for use in a closed environment accessible only to a single vendor’s user agent(s). A UA should support such proprietary extensions only through a vendor-prefixed syntax and not expose them to open (multi-UA) environments such as the World Wide Web.
何故?
接頭辞を付与する要件により、 標準~CSSへの将来の追加と競合することなく, 閉な環境に特化された特能を出荷できるようになる。 ~openな~systemへの公開に対する制約は、 公な~CSS環境が[ 標準~化されていない`~proprietary拡張$に, なし崩し的に依存するようになる ]のを防ぐためである。 ◎ The prefixing requirement allows shipping specialized features in closed environments without conflicting with future additions to standard CSS. The restriction on exposure to open systems is to prevent accidentally causing the public CSS environment to depend on an unstandardized proprietary extensions.
例えば[ Firefox の XUL に基づく~UI / Apple の iTunes ~UI / Microsoft の Universal Windows Platform ~app ]は、 ~CSSに対する拡張を利用し, 各~~主体の手による~UAに実装されている。 これらの~UAが,当の特能への~accessを~Web内容に許容すると、 そのような内容が当の`~proprietary拡張$に依存するようになる機会も生じることになる。 ◎ For example, Firefox’s XUL-based UI, Apple’s iTunes UI, and Microsoft’s Universal Windows Platform app use extensions to CSS implemented by their respective UAs. So long as these UAs do not allow Web content to access these features, they do not provide an opportunity for such content to become dependent on their proprietary extensions.
最終的に~Web利用が意図されている特能であっても、 まだ標準~化されていない場合は,依然として~Webに公開されるべきでない。 ◎ Even if a feature is intended to eventually be used in the Web, if it hasn’t yet been standardized it should still not be exposed to the Web.
3.2.3. 市場~圧力と事実上の標準
ある特能がまだ`不安定$ (すなわち、その仕様は,まだ安定化されていない) であっても, ~AND↓ が満たされるならば… ◎ If a feature is unstable (i.e. the spec has not yet stabilized), but
- 当の特能を実装する~UAが 3 つ以上ある (`または^em、 ~UAが他の規則に従わずに,`不安定$あるいは標準でない特能を製品n~releaseにて一般用途に出荷した) ◎ at least three UAs implement the feature (or a UA has broken the other rules and shipped for broad use an unstable or otherwise non-standard feature in a production release),
- 各~実装は、 `概ね相互運用可能$である ◎ and the implementations have rough interoperability,
- ~CSS~WGは、 当の特能は[ 存在するべきであり,~releaseされるべきである ]ことの総意を記録した ◎ and the CSS Working Group has recorded consensus that this feature should exist and be released,
…ならば、 実装者は,当の特能を`接頭辞~無し$として,一般用途の~release~buildにて出荷してもヨイ。 `概ね相互運用可能@ であるかどうかは、 相違点があるとしても,[ 各~実装が,相当数の利用事例において,製品n~web~siteにて十分似る様に利用されているかどうか ]に関する, `subjective judgment^en 【主観的判断?】により満たされる。 ◎ implementers may ship that feature unprefixed in broad-release builds. Rough interoperability is satisfied by a subjective judgment that even though there may be differences, the implementations are sufficiently similar to be used in production websites for a substantial number of use cases.
注記: それでも、 各~vendor間の協調を確保するため,および 各~vendorからの~CSS専門家による首尾一貫性の考査を確保するため、 ~CSS~WGに諮らなければナラナイことに注意。 また,`概ね相互運用可能$であるとしても、 通例的に[ 際どい事例では(または,さほど際どくない事例でも) 相互運用可能とは とても言えない部分が,まだある ]ことを意味することにも注意 — 特に、 詳細が まだ標準~考査の過程を通して確定されていないときは。 ◎ Note that the CSSWG must still be consulted to ensure coordination across vendors and to ensure coherency review by the CSS experts from each vendor. Note also that rough interoperability still usually means painful lack of interop in edge (or not-so-edge) cases, particularly because details have not been ironed out through the standards review process.
何故?
標準~化を終える前に,当の特能を 3 つ以上の~browserが実装するほど十分に普及したならば、 この条項は,出荷への圧力の解放を許容する。 また、 ある特能がすでに野に放たれていて,~~多数の~web~siteがそれに依存し始めた場合、 それを “試験的” なまま~~留め置いても,誰の助けにもならない。 当の特能が今や事実上の標準と化したことを認めて, 他者による接頭辞~無しの実装の出荷を許容した方が、 作者が各~platformに適応可能な~codeを書くのを~~促す結果になる。 ◎ If a feature is sufficiently popular that three or more browsers have implemented it before it’s finished standardization, this clause allows releasing the pressure to ship. Also, if a feature has already escaped into the wild and sites have started depending on it, pretending it’s still “experimental” doesn’t help anyone. Allowing others to ship unprefixed recognizes that the feature is now de facto standardized and encourages authors to write cross-platform code.
3.2.3.1. 不安定な特能に対する~vendor接頭辞の付与
実装は、 標準への行程( `standards-track^en )にある`不安定$な特能を,製品n~releaseにおいて~Webに公開するときは、 当の特能に対し,[ `接頭辞~付き構文$/接頭辞~無し構文 ]`どちらも^em~supportするべきである。 特能が安定化され,相互運用可能な挙動に合致するよう実装が更新されたときには、 `~vendor接頭辞~付き構文$の~supportは,除去されるべきである。 ◎ When exposing such a standards-track unstable feature to the Web in a production release, implementations should support both vendor-prefixed and unprefixed syntaxes for the feature. Once the feature has stabilized and the implementation is updated to match interoperable behavior, support for the vendor-prefixed syntax should be removed.
何故?
これが推奨されるのは、 作者が次を行えるようにするためである ⇒ すべての実装を~targetにする接頭辞~無し構文を利用しつつ、 必要yなときは,[ 当の特能が[ 標準~化/~bug~~解消 ]の過程を通して確定されるに伴い,特定の実装に非互換性が生じたとき ]にも対処する。 ◎ This is recommended so that authors can use the unprefixed syntax to target all implementations, but when necessary, can target specific implementations to work around incompatibilities among implementations as they get ironed out through the standards/bugfixing process.
接頭辞~付き構文~しか~supportしない相が無ければ、 接頭辞~付き構文のみを伴う`~stylesheet$が書かれる~riskも大幅に抑制される。 その結果,~UA~vendorは、 当の特能が安定的になったとき,[ 既存の内容を非互換化する~riskを低く抑えながら,自身の接頭辞~付き構文を退役させれる ]ようになる。 それはまた,ときには、 ある~vendorが[ 別~vendorの接頭辞を伴う特能 ]の構文を — 内容がそれに依存していることに因り — ~supportする羽目になることも,抑制する。 ◎ The lack of a phase where only the prefixed syntax is supported greatly reduces the risk of stylesheets being written with only the vendor-prefixed syntax. This in turn allows UA vendors to retire their prefixed syntax once the feature is stable, with a lower risk of breaking existing content. It also reduces the need occasionally felt by some vendors to support a feature with the prefix of another vendor, due to content depending on that syntax.
`不安定$な特能を作者に促しているどの~~主体であれ、 自身の手による標準を接頭辞~無し構文により文書化するべきである。 加えて、 実装~間の相違点に対処する以外の いかなる目的にも, `~vendor接頭辞~付き構文$の利用を奨励するのは避けるべきである。 ◎ Anyone promoting unstable features to authors should document them using their standard unprefixed syntax, and avoid encouraging the use of the vendor-prefixed syntax for any purpose other than working around implementation differences.
3.2.3.2. ~CSSの~open性を保全すること
~CSSの[ 技術としての~openな資質 ]を保全するため、 各~vendorは,[ 自身が出荷するどの特能についても,他の実装者が自由に実装する ]ことをアリにするべきである。 よって,各~vendorは、 当の特能の標準~化を完了するよう,仕様を[ 編集する/~testする ]ための資源を供するべきであり、 競争相手にとって当の特能が出荷し難くなる障害 (例:~platform依存関係, 利用許諾上の制約) を避けるべきである。 ◎ In order to preserve the open nature of CSS as a technology, vendors should make it possible for other implementors to freely implement any features that they do ship. To this end, they should provide spec-editing and testing resources to complete standardization of such features, and avoid other obstacles (e.g., platform dependency, licensing restrictions) to their competitors shipping the feature.
3.3. 勧告候補~levelの特能の実装
仕様が勧告候補の段階に達したなら、 実装者は — 勧告候補~levelの特能に対し,仕様に則って正しく実装されたことが実証できたなら — `接頭辞~無し$な実装を~releaseして, その特能の`接頭辞~付き$な変種を公開するのは避けるべきである。 ◎ 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.
実装~間にわたる~CSSの相互運用能を確立して保守するため、 ~CSS~WGは,試験的でない~CSS`具現化器$cfに対し[ その実装~報告を (および、必要yなら,実装~報告に利用した~testcaseも併せて) — ~CSS特能の接頭辞~無しな実装を~releaseする前に — ~W3Cに提出する ]ことを要請する。 提出された~testcaseは、 ~CSS~WGによる考査と訂正の~subjectになる。 ◎ 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 Working Group.
[ ~testcase/実装~報告 ]の提出-法についての更なる情報は、 ~CSS~WGの~web~site `https://www.w3.org/Style/CSS/Test/@https://www.w3.org/Style/CSS/Test/$ に見出せる。 質問があれば, public-css-testsuite@w3.org ~mailing-list宛に寄せるべきである。 ◎ Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at https://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.
4. 勧告候補~前に~releaseしても安全な例外
以下に挙げる特能は、 当の仕様が勧告候補に達する前に 広く~releaseされても安全なことが, ~CSS~WGにより明示的かつ事前的( `proactive^en )に明瞭にされた — `§ 試験運用と不安定な特能@#experimental$を見よ: ◎ The following features have been explicitly and proactively cleared by the CSS Working Group for broad release prior to the spec reaching Candidate Recommendation. See § 3.2.1 Experimentation and Unstable Features.
- 次に挙げる,各種~propの`~flow相対な等価@~CSSLOGICAL$ — `説明@https://lists.w3.org/Archives/Public/www-style/2015Jul/0040.html$と `仕様@~TR/css-logical-1/$ 【`和訳@~CSSLOGICAL$】 を見よ ⇒# `~sizing~prop@~SIZING#sizing-property$( `width$p, `height$p, 等々), ~border~prop, ~margin~prop, ~padding~prop ◎ The flow-relative equivalents of the sizing properties (width, height, etc.), the border properties, the margin and padding properties. See explanation and specification.
- 次に挙げる,各種~sizing~prop用の~keyword — `裁定@https://lists.w3.org/Archives/Public/www-style/2015Aug/0109.html$と `仕様@~TR/css-sizing-3/#sizing-values$ 【`和訳@~SIZING$】 を見よ ⇒# `min-content$v, `max-content$v ◎ The min-content and max-content keywords of the sizing properties. See decision and specification.
- `conic-gradient$f ~gradient記法。 `裁定@~CSSissue/2383#issuecomment-371340088$を見よ。 ◎ The conic-gradient() gradient notation. See decision.
- `aspect-ratio$p ~prop。 `CSS-SIZING-4$r ◎ The aspect-ratio property. [CSS-SIZING-4]
- 次に挙げる~prop `CSS-TRANSFORMS-2$r ⇒# `translate$p, `rotate$p, `scale$p ◎ The translate, rotate, and scale properties. [CSS-TRANSFORMS-2]
- `hyphenate-character$p ~prop。 `CSS-TEXT-4$r ◎ The hyphenate-character property. [CSS-TEXT-4]
- `color-mix$f 関数 `CSS-COLOR-5$r ◎ The color-mix() function. [CSS-COLOR-5]
- `color-interpolation-method$t — これは、 `CSS-COLOR-4$r にて定義され,各種~gradient `CSS-IMAGES-4$r の補間~用に利用される。 ◎ The <color-interpolation-method>, defined in [CSS-COLOR-4] and used for interpolation of linear, radial and conic gradients. [CSS-IMAGES-4]
- `CSS-COLOR-5$r にて定義される`相対~色~構文$ ◎ The relative color syntax, defined in [CSS-COLOR-5]
以下に挙げる特能は、 当の仕様が勧告候補に達する前に 広く~releaseされても安全なことが, ~CSS~WGにより明示的かつ事後的( `retroactive^en )に明瞭にされた: ◎ The following features have been explicitly and retroactively cleared by the CSS Working Group for broad release prior to the spec reaching Candidate Recommendation:
- 次に挙げる仕様~内にあるすべて ⇒# `CSS Animations Level 1@~TR/css-animations-1/$cite 【`和訳@~CSSANIM$】, `CSS Transitions Level 1@~TR/css-transitions-1/$cite 【`和訳@~TRANSITION$】 ◎ Everything in CSS Animations Level 1 and CSS Transitions Level 1.
- `SELECTORS-4$r による,次に挙げる疑似類 ⇒# `dir()$ps, `lang()$ps, `focus-within$ps ◎ The :dir(), :lang(), and :focus-within pseudo-classes from [SELECTORS-4].
5. 索引
◎非規範的5.1. 用語~索引
【 この節は未訳。 】
5.2. 選択子~索引
- `*^css(`全称~選択子$)
- `active$ps
- `after^ps ※( `after$pe )
- `before^ps ※( `before$pe )
- `checked$ps
- `disabled$ps
- `empty$ps
- `enabled$ps
- `first-child$ps
- `first-letter^ps ※( `first-letter$pe )
- `first-line^ps ※( `first-line$pe )
- `first-of-type$ps
- `focus$ps
- `hover$ps
- `lang()$ps【!`lang$ps】
- `last-child$ps
- `last-of-type$ps
- `link$ps
- `not()$ps
- `nth-child()$ps
- `nth-last-child()$ps
- `nth-last-of-type()$ps
- `nth-of-type()$ps
- `only-child$ps
- `only-of-type$ps
- `root$ps
- `target$ps
- `visited$ps
【 `選択子$によっては,参照-先が複数あるが (当の選択子を定義する[ 仕様/仕様~level ]ごとに)、 ここでは,概ね~level 4( `SELECTORS-4$r )のみに簡素化する。 】【 ※ が付与されたものは、 旧-構文であり,実際には同じ名前の`疑似要素$である。 】
5.3. ~at-規則~索引
- `charset$at†
- `counter-style$at
- `import$at
- `keyframes$at
- `media$at
- `supports$at
【† `charset^at は、 本物の~at-規則ではない。 】
【 ~at-規則には、 他にも次に挙げるものがある(網羅的ではない): 】
- `-webkit-keyframes$at
- `color-profile$at
- `container$at
- `custom-media$at
- `else$at
- `font-face$at
- `font-feature-values$at
- `font-palette-values$at
- `function$at
- `layer$at
- `namespace$at
- `page$at
- `position-try$at
- `property$at
- `scroll-timeline$at
- `starting-style$at
- `viewport$at
- `view-transition$at
- `when$at
5.4. ~prop索引
【 この節は未訳。 参考:`全~prop一覧@css-all-properties.html$(不安定な仕様も含む) 】
5.5. ~prop値~索引
【 この節は未訳。 】
謝辞
`§ 試験運用と不安定な特能@#experimental$ の初期~草案を作成された, `Florian Rivoal^en 氏に特別な謝意を。 ◎ Special thanks to Florian Rivoal for creating the initial draft of the § 3.2.1 Experimentation and Unstable Features recommendations.
適合性
【 この節は,原文には無いが、 ほぼすべての~CSS~moduleに共通な § 適合性 の内容を集約するために, ここに与えている (それらの和訳では、この節を参照している)。 以下に現れる “この仕様” や “この~module” は、 この節を参照している個々の~CSS~moduleを指す。 】
表記規約
適合性の要件は、 記述的な表明と `RFC2119$r による句の組合nで表出される。 この文書の規範的な部分における句 `“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”^en は、 RFC 2119 の定義に則って解釈することになる。 しかしながら、 可読性のため,これらの語は大文字で記されない。 【これらが日本語訳にてどう表記されるかについては、 RFC 2119 が規定する句に利用される対訳を参照されたし。】 ◎ 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.
明示的に “規範的でない( `non-normative^en )” 【あるいは, “参考( `informative^en )” 】 と記された節, および[ 例, 注記 ]を除く, この仕様のすべての~textは、 規範的である。 `RFC2119$r ◎ All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
この仕様における各 例は、 語 “例えば( `for example^en )…” 【あるいは, “例:( `e.g.,^en )…” / “一例として( `for instance^en)…” 】 で導入されるか, 次の様な~styleで規範的な~textから隔てられる: ◎ Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:
これは参考~例。 ◎ This is an example of an informative example.
この仕様における各 参考~注記は、 語 “注記( `Note^en ):” で始まるか, 次の様な~styleで規範的な~textから隔てられる: ◎ 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.
告知文は、 次の様に `class="advisement"^c で~styleされて (場合によっては `strong^e 要素でも~mark-upされた上で), 注目を引くように規範的な部分から隔てられる: ◎ Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this:
~UAは、~access可能な代替を供するモノトスル。 ◎ UAs MUST provide an accessible alternative.
この仕様の内容に関係している~testは、 “~test” ~blockとして,次の様に文書化され得る。 そのような~blockは規範的でない。 【和訳では、 “~test” ~blockは省略している — 各~仕様の原文を参照されたし。】 ◎ Tests relating to the content of this specification may be documented in “Tests” blocks like this one. Any such block is non-normative.
適合性の各種~class
この仕様に対する適合性は、 次に挙げる 3 種の~class用に定義される: ◎ Conformance to this specification is defined for three conformance classes:
- `~stylesheet@cf
- `~stylesheet$ 【!CSS style sheet】。 ◎ A CSS style sheet.
- `具現化器@cf( `renderer^en )/描画器
- `~stylesheet$の意味論を解釈し,それらを利用して文書を具現化する`~UA$。 ◎ A UA that interprets the semantics of a style sheet and renders documents that use them.
- `著作~tool@cf
- `著作~tool$。 ◎ A UA that writes a style sheet.
`~stylesheet$cfは、 この~moduleにて定義される構文を利用するすべての文が[ 汎用~CSS文法, および この~module内に定義される各種 特能の個々の文法 ]に則って妥当であるとき,この仕様に適合するものとされる。 ◎ 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.
`具現化器$cfは、 適切な仕様の定義に従って`~stylesheet$を解釈することに加えて、 それを正しく構文解析して, それに則って文書を具現化することを通して, この仕様にて定義されるすべての特能を~supportするとき、 この仕様に適合するものとされる。 ただし,[ 機器の制限に因り文書を正しく具現化できないために,この仕様の一部のみを実装する~UA ]の不能性は、 不適合tとされない (例えば,~UAには、単彩色~monitorに他の色を描画することは要求されない)。 ◎ 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.)
`著作~tool$cfは、[ 汎用~CSS文法 および この~module内の各種 特能の個々の文法 ]に則って構文上は正しい`~stylesheet$を書出す, かつ[ この~module内に述べられた,`~stylesheet$cfに課される他のすべての適合性~要件 ]を満たすとき、 この仕様に適合するとされる。 ◎ 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.
部分的な実装
作者が前方-互換な構文解析~規則を活用して,~fallback値をアテガえるようにするため、 ~CSS`具現化器$cfは、[ ~at-規則, ~prop, ~prop値, ~keyword, その他の構文-構成子 ]のうち[ 自身が実用~levelで~supportしないもの ]を無効なものとして扱う(それに伴い,適切に`無視する$)モノトスル。 特に,~UAは、 複数成分からなる値をとる単独の~prop宣言の中で, 自身が~supportする値のみ尊守しつつ, 未~supportな成分を選択的に無視してはナラナイ。 いずれかの成分が無効と見なされる場合 (未~supportな値はそう見なすモノトスル)、 それを含む宣言~全体を`無視する$ことが~CSSから要求される。 ◎ 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 component 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.
不安定/~proprietaryな特能の実装
将来の安定的な~CSS特能との衝突を避けるため、 ~CSS~WGは,[ ~CSS用の[ `不安定$な特能/`~proprietary拡張$ ]を実装する際には, `最善な実施に従う@#future-proofing$ ]ことを推奨する。 ◎ To avoid clashes with future stable CSS features, the CSSWG recommends following best practices for the implementation of unstable features and proprietary extensions to CSS.
試験的でない実装
仕様が勧告候補の段階に達して,試験的でない実装がアリになったならば、 実装者は,勧告候補~levelの特能のうち[ 仕様に則って正しく実装したことをデモれたもの ]に対し[ `接頭辞~無し$な実装 ]を~releaseするべきである。 ◎ Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.
実装~間の~CSSの相互運用能を確立し, 保守するため、 ~CSS~WGは、試験的でない~CSS`具現化器$cfが接頭辞~無しな~CSS特能の実装を~releaseする前に,~W3Cに実装~報告を (および、 必要yなら,実装~報告に利用された~test事例も併せて) 提出することを要請する。 ~W3Cに提出された~test事例は、 ~CSS~WGによる考査と訂正の~subjectになる。 ◎ 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 Working Group.
~test事例, および実装~報告の提出-法についての更なる情報は、 ~CSS~WG~web~siteの `https://www.w3.org/Style/CSS/Test/@https://www.w3.org/Style/CSS/Test/$ にて見られる。 質問があれば, public-css-testsuite@w3.org ~mailing-list宛に寄せられるべきである。 ◎ Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at https://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.
勧告候補から~~昇格するための判定基準
【 この節は、`編集者草案$には無い。 】
この仕様が勧告案に~~昇格するためには、 各~特能に対し,独立かつ相互運用可能な実装が 2 つ以上なければナラナイ。 各~特能は、異なる製品からなる集合により実装されてもヨイ — 単独の製品がすべての特能を実装するとする要件は無い。 この判定基準の目的においては、 次に挙げる用語が定義される: ◎ For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:
- 独立 ◎ independent
- 対象になる各~実装は、 異なる主体により開発されなければナラナイ — 各~実装は、対象になる別の実装に利用される~code[ を共有し得ない/を再利用し得ない/から導出し得ない ]。 この仕様の実装とは~~無関係な~code節は、 この要件からは免除される。 ◎ each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.
- 相互運用可能 ◎ interoperable
-
公式的な~CSS~test一式 内の【当の特能に】対応する~testcase群に合格すること — 当の実装が~Web~browserでない場合は、 等価な~test群に合格すること。 ◎ passing the respective test case(s) in the official CSS test suite, or, if the implementation is not a Web browser, an equivalent test.\
そのような【~Web~browserでない】~UAが相互運用能を主張するために利用される場合: ◎ ↓
- ~test一式 内の関連な各~testと等価な~testが作成されるベキである。 ◎ Every relevant test in the test suite should have an equivalent test created if such a user agent (UA) is to be used to claim interoperability.\
- 加えて、 相互運用能の目的において,[ それらの等価な~testと同じ仕方で合格する他の~UA ]が 1 つ以上はなければナラナイ。 ◎ In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability.\
- 等価な~test群は、 ~~専門家から考査する目的~用として, 公に可用にされなければナラナイ。 ◎ The equivalent tests must be made publicly available for the purposes of peer review.
- 実装 ◎ implementation
-
~AND↓ を満たす~UA: ◎ a user agent which:
- この仕様を実装している。 ◎ implements the specification.
- 一般から公に可用である。 実装は、 出荷~製品に加え,他の公に可用な~version (すなわち、 ~beta~version / ~preview~release / “`nightly^en ~build” ) も対象になり得る。 ただし,後者であっても、 安定性をデモるため,当の特能~群を 1ヶ月以上は実装しなければナラナイ。 ◎ is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or "nightly build"). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability.
- 試験的なもの (すなわち、 ~test一式に合格するよう特定的に設計された~versionであって,通常の用法に至ることは意図されていないもの) ではない。 ◎ is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward).
この仕様は、 6ヶ月~以上は勧告候補であり続けることになる。 ◎ The specification will remain Candidate Recommendation for at least six months.