1. 序論
一部の文書~形式は、[ 文書~内の特定の要素に~style情報を直に適用する ]ことを作者に許可するための, `~style属性@ を備えている。 ある文書~形式が`~style属性$を定義していて ( "`style^a" と命名されるものに限られない), それが値として~CSSを受容するならば (そのような属性は、 `~CSS~style属性@ とも称される)、 この仕様が,[ その構文, その値の解釈 ]を定義する。 ◎ Some document formats have a style attribute to permit the author to directly apply style information to specific elements in documents. If a document format defines a style attribute (whether named ‘style’ or something else) and the attribute accepts CSS as its value, then this specification defines that style attribute’s syntax and interpretation.
次の例は、 ~HTMLにおける `style^a 属性の利用を示す: ◎ The following example shows the use of the style attribute in HTML [HTML401]:
<p style="color: #090; line-height: 1.2">...</p>
2. 適合性
【 この節の他の内容は、 ~CSS Snapshot ~pageに移譲。 】
[ 文書/実装 ]は、 この仕様~~単独には適合し得ないが、[ `~CSS~style属性$を備える文書~言語の定義に従って, ~CSSを その属性の取扱いも含めて実装するとき、 この仕様における適合性の要件を満たす ]ならば,適合性を主張できる。 ◎ A document or implementation cannot conform to CSS Style Attributes alone, but can claim conformance to CSS Style Attributes if it satisfies the conformance requirements in this specification when implementing CSS together with style attribute handling as defined in a document language that has one or more CSS style attributes.
この仕様への適合性は、 次に挙げる~classに定義される: ◎ Conformance to CSS Style Attributes is defined for two classes:
- 文書
- 文書~言語のうち[ 何らかの要素に`~style属性$0を定義するもの ]で表現される文書。 ◎ A document represented in a document language that defines a style attribute for one or more of its elements.
- 解釈器( `interpreter^en )
- [ 文書, および それに結付けられた~style情報 ]の意味論を解釈するもの (ほとんどの~CSS~UAは,ここに分類される)。 ◎ Someone or something that interprets the semantics of a document and its associated style information. (Most CSS user agents fall under this category.)
3. 構文と構文解析
`~style属性$0の値は、 `~CSS宣言~block$の内容(~blockを区切る括弧は除く)の構文に合致しなければナラナイ。 その正式な文法は、 ~CSS中核~文法の用語と表記規約を通して, 以下に与えられる: ◎ The value of the style attribute must match the syntax of the contents of a CSS declaration block (excluding the delimiting braces), whose formal grammar is given below in the terms and conventions of the CSS core grammar:
style-attribute : S* declaration-list ; declaration-list : declaration [ ';' S* declaration-list ]? | at-rule declaration-list | /* empty */ ;
注記: CSS2.1 の規約に従って、 ~comment~tokenは,上の規則には示されていない。 ◎ Note that following the CSS2.1 convention, comment tokens are not shown in the rule above.
解釈器は、 `~style属性$0の値を[ 通常の~CSS~stylesheetにおける宣言~block内容の構文解析に適用されるものと同じ,前方-互換な構文解析~規則 ]を利用して,構文解析するモノトスル ( `CSS21$r § 4 を見よ)。 加えて,~UAは、[ 宣言/~at-規則 ]の開始 (すなわち, `IDENT^prod ~token/ `ATKEYWORD^prod ~token) を期待する所で,期待されない~tokenを見出したときは、 その~tokenは,不正形の宣言の最初の~tokenと見なされる。 この場合、 どの~tokenを無視するかを決定する際に,[ 不正形の文( `statement^prod )ではなく,不正形の宣言( `declaration^prod ) ]に対する規則が利用される。 ◎ The interpreter must parse the style attribute's value using the same forward-compatible parsing rules that apply to parsing declaration block contents in a normal CSS style sheet (see chapter 4 of the CSS2.1 specification [CSS21]), with the following addition: when the UA expects the start of a declaration or at-rule (i.e., an IDENT token or an ATKEYWORD token) but finds an unexpected token instead, that token is considered to be the first token of a malformed declaration. I.e., the rule for malformed declarations, rather than malformed statements, is used to determine which tokens to ignore in that case.
注記: `~CSS~style属性$の構文には,宣言~listを区切る開き括弧は無いので、 ~style属性の値における閉じ括弧( `}^c )は,~style~dataを終了させない — それは、 単に無効な~tokenになる。 ◎ Note that because there is no open brace delimiting the declaration list in the CSS style attribute syntax, a close brace (}) in the style attribute's value does not terminate the style data: it is merely an invalid token.
注記: 文法が許容するとしても、 `~style属性$0にて妥当な~at-規則は,現時点では定義されていない。 構文解析~規則は前方-互換であり、 そのような~at-規則に後続する宣言は,無視されない: ◎ Although the grammar allows it, no at-rule valid in style attributes is define at the moment. The forward-compatible parsing rules are such that a declaration following an at-rule is not ignored:
<span style="@unsupported { splines: reticulating } color: green">【!"@unsupported" の "{}" の中身も無視されることになる】
4. ~cascade法と解釈
`~style属性$0内の宣言は、 その属性を有する要素に適用される。 この宣言は、 ~cascadeにおいては[ その`出自$は`作者$であって,`詳細度$は どの選択子よりも高い ]ものと見なされる†。 `~style属性$0が~stylesheetと一緒にどう~cascadeされるかは、 `CSS21$r にて定義される。 属性の値を構文解析するときは、 ~style~data内の相対~URLは,`~style属性$0を有する要素 (あるいは,要素ごとの解決が【文書~言語にて】定義されていない場合は,文書【の~URL】) に相対的に解決するモノトスル。 【! so dynamic changes to the base URL don't affect the CSS Hixie 】 ◎ The declarations in a style attribute apply to the element to which the attribute belongs. In the cascade, these declarations are considered to have author origin and a specificity higher than any selector. CSS2.1 defines how style sheets and style attributes are cascaded together. [CSS21] Relative URLs in the style data must be resolved relative to the style attribute's element (or to the document if per-element resolution is not defined) when the attribute's value is parsed.
【† ~cascade法の最新な仕様においては、 (ほぼ同じことになるが,)`要素に付された~style$として扱われる。 】
`~style属性$0内の宣言は、 ~cascade法における相違は別として,[ それが,要素に適用される~CSS~style規則にて与えられていたとき ]と正確に同じに解釈するモノトスル。 ◎ Aside from the differences in cascading, the declarations in a style attribute must be interpreted exactly as if they were given in a CSS style rule that applies to the element.
~CSS~WGは、 文書~言語に対し,単独の要素に複数種の`~CSS~style属性$を許容しないことを強く推奨する。 複数種の`~CSS~style属性$が許容される文書~言語においては、 それぞれを独立に構文解析して, 別々な~style規則として扱うモノトスル — それらの順序付け【どの属性による~styleがより優先されるか】は、 文書~言語が定義するベキである — さもなければ未定義とする。 ◎ The CSS Working Group strongly recommends that document languages do not allow multiple CSS style attributes on a single element. If a document language allows multiple CSS style attributes, each must be parsed independently and treated as a separate style rule, the ordering of which should be defined by the document language, else is undefined.
5. 変更点
- 2013年 10月 3日 勧告案 からの変更点 ◎ Changes since the 2013-10-03 Proposed Recommendation are:
- 将来の拡張を許容するため、 宣言~list内の ~at-規則も構文解析することにした。 ◎ Parse at-rules in declaration lists to allow future extension.
6. 謝辞
次の方々からの~feedbackに:
Thanks to feedback from Daniel Glazman, Ian Hickson, Eric A. Meyer, Björn Höhrmann.
~privacyの考慮点
この仕様に対し報告された新たな~privacyの考慮点は無い。 ◎ No new privacy considerations have been reported on this specification.
~securityの考慮点
この仕様に対し報告された新たな~securityの考慮点は無い。 ◎ No new security considerations have been reported on this specification.