1. 序論
この~moduleは、[ ~UIに関係する~propと その値に対し,作者による~style付けを可能化する ]ような,各種~CSS~propについて述べる。 ◎ This module describes CSS properties which enable authors to style user interface related properties and values.
`CSS1$r の 2.1 節, および `CSS21$r の 18 章 では、~UIに関係する数種の[ ~prop, 値 ]が導入されている。 `CSSUI$r ( 2000 年 2 月 16日)では、~UIに関係する 数種の新たな特色機能が導入された。 ◎ Section 2.1 of CSS1 [CSS1] and Chapter 18 of CSS2 [CSS21] introduced several user interface related properties and values. User Interface for CSS3 (16 February 2000) introduced several new user interface related features.
後に,これらを組入れて, 拡張し, それらに取って代わる, `CSS-UI-3$r が導入された。 この仕様は、この作業を継続して, `CSS-UI-3$r を置換する。 ◎ [CSS-UI-3] was later introduced to incorporates, extends, and supersedes these. This specification continues this work, and in turn replaces [CSS-UI-3].
1.1. 目的
この仕様の目的は、次の~~目標を達成することである: ◎ The purpose of this specification is to achieve the following objectives:
- `CSS21$r, `CSS-UI-3$r による~UI特色機能を拡張する。 ◎ Extend the user interface features in [CSS21] and [CSS-UI-3]
- ~CSSによる追加の仕組みを供して、~HTMLにおける他の動的な呈示に関係する特色機能を,増補する/置換する。 ◎ Provide additional CSS mechanisms to augment or replace other dynamic presentation related features in HTML.
- ~UIの構築を支援するための方向的~navi~propを導入する — それは、方向的~navi~modelを用立てる。 ◎ Introduce directional navigation properties to assist in the construction of user interfaces which make use of a directional navigation model.
2. ~module間の相互作用
この文書は、~~以前までの仕様に存在しなかった,新たな特色機能を定義する。 加えて、[ 次を置換して,それに取って代わった `CSS-UI-3$r ]を置換して,それに取って代わる: ◎ This document defines new features not present in earlier specifications. In addition, it replaces and supersedes [CSS-UI-3], which itself replaced and superseded the following:
- `CSS21$r の: 18.1 節, 18.4 節, [ Appendix E にて定義される`外形線$の積層法についての情報 ] ◎ Section 18.1, section 18.4, and Information on the stacking of outlines defined in Appendix E of Cascading Style Sheets, level 2, revision 1 [CSS21]
- User Interface for CSS3 ( 2000 年 2 月 16日) `CSS-UI-3$r ◎ User Interface for CSS3 (16 February 2000) [CSS-UI-3]
注記: 以前までこの仕様にて定義されていた `box-sizing$p ~propは、 `CSS-SIZING-3$r に移動された。 ◎ Note: The box-sizing property was previously defined in this section of the specification, but has been moved to CSS Intrinsic & Extrinsic Sizing Module Level 3 §box-sizing.
注記: 以前までこの仕様にて定義されていた `text-overflow$p ~propは、 `CSS-OVERFLOW-3$r と, その ~level 4 による拡張 `CSS-OVERFLOW-4$r に移動された。 ◎ Note: The text-overflow property was previously defined in this section of the specification, but has been moved to CSS Overflow Module Level 4 §text-overflow.
3. 各種 外形線( `outline-*^p )~prop
~stylesheet作者は、[ ~button, 作動中の~form~field, 画像~map ]などを目立たせるため,それらの 視覚的~objの周囲に外形線( outline )を作成させるよう求めることもある。 外形線は、次の点で~borderと異なる: ◎ At times, style sheet authors may want to create outlines around visual objects such as buttons, active form fields, image maps, etc., to make them stand out. Outlines differ from borders in the following ways:
- 外形線は、空間を~~排他的に占めない。 ◎ Outlines do not take up space.
- 外形線は、矩形状でないこともある。 ◎ Outlines may be non-rectangular.
- ~UAは、 `focus^ps 状態にある要素に対し,外形線を描画することが多い。 ◎ UAs often render outlines on elements in the :focus state.
各種 外形線~propは、これら動的な外形線の~styleを制御する ◎ The outline properties control the style of these dynamic outlines.
これらの外形線を描画するときの積層法は、~platformに応じて より良い利用者~体験を供するため、明示的に実装に委ねられる。 これは、 CSS 2.1, 付録 E による外形線の積層法に取って代わる。 ◎ The stacking of the rendering of these outlines is explicitly left up to implementations to provide a better user experience per platform. This supersedes the stacking of outlines as defined in Appendix E of CSS 2.1 [CSS21].
~keyboard利用者 — 特に他のやり方で頁とやりとりできない身体的不利のある利用者 — は、 `focus^ps 状態の要素~上で外形線が可視になることに依存する。 よって作者は、そのような外形線を,代替的な強調の仕組みを供することなく不可視にしては~MUST_NOT。 ◎ Keyboard users, in particular people with disabilities who may not be able to interact with the page in any other fashion, depend on the outline being visible on elements in the :focus state, thus authors must not make the outline invisible on such elements without making sure an alternative highlighting mechanism is provided.
外形線に変形( `transform^p )を適用したときの描画は、この~levelの仕様においては,明示的に未定義とする。 ◎ The rendering of applying transforms to outlines is left explicitly undefined in CSS3-UI.
3.1. 外形線の略式: `outline^p ~prop
◎名 `outline@p ◎値 [ `outline-color$tp || `outline-style$tp || `outline-width$tp ] ◎初 個々の~propを見よ ◎適 すべての要素 ◎継 されない ◎百 受容しない ◎算 個々の~propを見よ ◎順 文法に従う ◎ア 個々の~propを見よ ◎表終3.2. 外形線の太さ: `outline-width^p ~prop
◎名 `outline-width@p ◎値 `line-width$t ◎初 `medium^v ◎適 すべての要素 ◎継 されない ◎百 受容しない ◎算 絶対~長さ — ただし, `outline-style$p が `none^v の場合は `0^v 。 ◎ absolute length; 0 if the outline style is none. ◎順 文法に従う ◎ア `長さとして$ ◎表終3.3. 外形線の~pattern: `outline-style^p ~prop
◎名 `outline-style@p ◎値 `auto$v | `outline-line-style$t ◎初 `none^v ◎適 すべての要素 ◎継 されない ◎百 受容しない ◎算 指定値 ◎順 文法に従う ◎ア 離散的 ◎表終3.4. 外形線の色: `outline-color^p ~prop
◎名 `outline-color@p ◎値 `color$t | `invert$v ◎初 `invert^v ◎適 すべての要素 ◎継 されない ◎百 受容しない ◎算 `invert$v に対してはそのまま `invert$v。 `color$t 値に対しては `CSS-COLOR-4$r による`色~値の解決-法$を見よ。 ◎ The computed value for invert is invert. For <color> values, see resolving color values in [CSS-COLOR-4]. ◎順 文法に従う ◎ア `色として$ ◎表終3.1. 〜 3.4. 外形線~prop
上に示された各種 外形線~propにより作成される外形線は、~boxの “上から” 描かれる — すなわち外形線は、常に手前にあり,~boxや他の~boxの位置や~sizeには波及しない。 従って、外形線の表示の有無が変わっても,再flowが生じることはない。 ◎ The outline created with the outline properties is drawn "over" a box, i.e., the outline is always on top, and doesn’t influence the position or size of the box, or of any other boxes. Therefore, displaying or suppressing outlines does not cause reflow.
外形線は:
- 矩形状でなくても~MAY。 例えば,要素がいくつかの行lたちに分断されている場合、それらの各~boxを囲うような,最小本数の外形線からなるべきである。 ◎ Outlines may be non-rectangular. For example, if the element is broken across several lines, the outline should be an outline or minimum set of outlines that encloses all the element’s boxes.
- その各~部分は、(改行されるときの,`行内$~要素の~borderのように)線が途切れることなく,輪になるべきである。 ◎ Each part of the outline should be fully connected rather than open on some sides (as borders on inline elements are when lines are broken).
- その各~部分も、矩形状になることは要求されない。 `~border辺$をなぞる所では,`border-*-radius$p による曲線もなぞるべきである。 ◎ The parts of the outline are not required to be rectangular. To the extent that the outline follows the border edge, it should follow the border-radius curve.
- その位置は、子孫~boxに影響され得る。 【例えば、子孫~boxが親~boxからはみ出すときは,はみ出た部分も囲うように描かれるであろう。】 ◎ The position of the outline may be affected by descendant boxes.
~UAは、利用者に~focusの概念を伝えるものとして 適切な領域を囲うような,外形線を決定する~algoを利用するべきである。 ◎ User agents should use an algorithm for determining the outline that encloses a region appropriate for conveying the concept of focus to the user.
注記: この仕様は、外形線の正確な 位置/形状 を定義しないが、それは概して,~border~boxの直ぐ外側に描かれる。 ◎ Note: This specification does not define the exact position or shape of the outline, but it is typically drawn immediately outside the border box.
【利用中の~browserによる,~border(灰)から相対的な外形線(青)の位置を示す図:】
`outline-width$p ~propは、 `border-width$p 【の個々の成分~値】と同じ値を受容する。 ◎ The outline-width property accepts the same values as border-width (CSS Backgrounds 3 §4.3 Line Thickness: the border-width properties).
`outline-line-style@t は、[ 値 `hidden^v は,外形線~styleとして合法でない ]ことを除いて, `line-style$t と同じ値を 同じ意味として受容する。 加えて, `outline-style$p ~propは、値 `auto@v も受容する。 この値は、~custom外形線~styleを描画することを~UAに許可する: 概して、~platformにおける~UI既定の~styleで, あるいは おそらく~CSSにて述べ得る詳細よりも多彩な~styleで — 例えば、外縁の画素が半透明に輝いて現れるような,丸まった辺による外形線など。 そのようなわけで、この仕様は,`auto^v ~styleの外形線を描画するときに `outline-color$p が 組入れられる/利用される としても,その方法は定義しない。 ~UAは、 `auto^v を `solid^v と扱ってよい。 ◎ <outline-line-style> accepts the same values as <line-style> (CSS Backgrounds 3 §4.2 Line Patterns: the border-style properties) with the same meaning, except that hidden is not a legal outline style. In addition, the outline-style property accepts the value auto. The auto value permits the user agent to render a custom outline style, typically a style which is either a user interface default for the platform, or perhaps a style that is richer than can be described in detail in CSS, e.g. a rounded edge outline with semi-translucent outer pixels that appears to glow. As such, this specification does not define how the outline-color is incorporated or used (if at all) when rendering auto style outlines. User agents may treat auto as solid.
`outline-color$p ~propは、すべての色( `color$t )に加え,~keyword `invert@v も受容する。 `invert$v は,~screen画素~色の反転を遂行するものと期待される。 これは、色~背景に関わらず~focus~borderが可視になるのを確保するために,共通的にとられる~~技法である。 ◎ The outline-color property accepts all colors, as well as the keyword invert. invert is expected to perform a color inversion on the pixels on the screen. This is a common trick to ensure the focus border is visible, regardless of color background.
適合的~UAは、~screen上の画素~色の反転を~supportしない~platform上では, `invert$v 値を無視してよい。 ◎ Conformant UAs may ignore the invert value on platforms that do not support color inversion of the pixels on the screen.
`invert$v 値を~supportしない~UAは,その値を構文解析-時に却下し~MUST — その場合の `outline-color$p ~propの初期値は、~keyword `currentcolor$v とする。 ◎ If the UA does not support the invert value then it must reject that value at parse-time, and the initial value of the outline-color property is the currentColor keyword.
`outline$p ~propは、略式~propであり,[ `outline-style$p, `outline-width$p, `outline-color$p ]すべてを設定する。 ◎ The outline property is a shorthand property, and sets all three of outline-style, outline-width, and outline-color.
注記: ~borderとは対照的に、外形線は どの側でも同じであり, `outline-top^p や `outline-left^p 等々の~propは無い。 ◎ Note: The outline is the same on all sides. In contrast to borders, there are no outline-top or outline-left etc. properties.
この仕様は、複数の外形線が重合するときや, 他の要素の背後に部分的に~~覆われている~boxに対し,外形線がどう描かれるかについては定義しない。 ◎ This specification does not define how multiple overlapping outlines are drawn, or how outlines are drawn for boxes that are partially obscured behind other elements.
`button^e 要素の周囲に 太めの( `thick^v )外形線を描く例: ◎ Here’s an example of drawing a thick outline around a BUTTON element:
button { outline: thick solid }
~graphic的~UIは、頁の どの要素が~focusを得ているかを 利用者に伝えるために,要素の周囲に外形線を利用してよい。 これらの外形線は,~borderへの追加であり、外形線の有無が切替わっても,文書は再flowされるべきでない。 ~focusは、文書における利用者との対話が主目的である(例えば,~textを手入力したり~buttonを選択する, など)。 ◎ Graphical user interfaces may use outlines around elements to tell the user which element on the page has the focus. These outlines are in addition to any borders, and switching outlines on and off should not cause the document to reflow. The focus is the subject of user interaction in a document (e.g. for entering text or selecting a button).
例えば,次の規則は、要素が~focusを得ているときは周囲に太めの黒色~線を,要素が作動中のときは太めの赤色~線を描かす: ◎ For example, to draw a thick black line around an element when it has the focus, and a thick red line when it is active, the following rules can be used:
:focus { outline: thick solid black } :active { outline: thick solid red }
注記: 外形線は、整形には影響しない(すなわち,~box~modelにおいて空間を占めない)ので,頁~上の他の要素と重合することもある。 ◎ Note: Since the outline does not affect formatting (i.e., no space is left for it in the box model), it may well overlap other elements on the page.
3.5. 外形線の~offset法: `outline-offset^p ~prop
外形線は、既定では,ちょうど`~border辺$の外側に描かれる — が、そこから外へ~offsetして描かすこともアリである。 ◎ By default, the outline is drawn starting just outside the border edge. However, it is possible to offset the outline and draw it beyond the border edge.
◎名 `outline-offset@p ◎値 `length$t ◎初 `0^v ◎適 すべての要素 ◎継 されない ◎百 受容しない ◎算 `絶対~単位$( `px^u または`物理~単位$ )による `length$t 値 ◎ <length> value in absolute units (px or physical). ◎順 文法に従う ◎ア `長さとして$ ◎表終`outline-offset$p の算出値が `0^v でない場合、外形線は,その分量だけ`~border辺$から外へずらされる。 ◎ If the computed value of outline-offset is anything other than 0, then the outline is outset from the border edge by that amount.
例えば,次の規則を利用すれば、~focus外形線と[ ~focusを得ている, または 作動中の ]要素との合間に, 2 画素~分の隙間をあてがえる: ◎ For example, to leave 2 pixels of space between a focus outline and the element that has the focus or is active, the following rule can be used:
:focus,:active { outline-offset: 2px }
負の値は、外形線を~border~boxの中へ縮短させ~MUST。 絶対~値が大きい負~値でも,外形線を必ず描画できるようにするため、外形線で描かれる形状の~~外縁の[ 縦幅, 横幅 ]は、いずれも[ `outline-width$p ~propの算出値の 2 倍 ]以上にするべきである。 ~UAは、この拘束を,各~次元ごとに独立に適用するべきである。 外形線が,単連結でない, 複数の形状として描かれる場合、この拘束は,各~形状ごとに別々に適用される。 ◎ Negative values must cause the outline to shrink into the border box. Both the height and the width of outside of the shape drawn by the outline should not become smaller than twice the computed value of the outline-width property, to make sure that an outline can be rendered even with large negative values. User Agents should apply this constraint independently in each dimension. If the outline is drawn as multiple disconnected shapes, this constraint applies to each shape separately.
4. ~resize法
CSS2.1 は、`塊~容器$~要素~上の~scroll用の仕組み(例:~scrollbar)の外観を制御するための仕組みを供する。 この仕様は、利用者が要素を~resizeできる能に加えて,~text~overflowの挙動を指定する能を制御する仕組みを追加する。 ◎ CSS2.1 provides a mechanism for controlling the appearance of a scrolling mechanism (e.g. scrollbars) on block container elements. This specification adds to that a mechanism for controlling user resizability of elements as well as the ability to specify text overflow behavior.
4.1. ~boxの~resize法: `resize^p ~prop
`resize$p ~propにより、作者は,[ 要素が利用者により~resize可能かどうか, および その~~方向は縦横いずれが可能か ]について,指定できるようになる。 ◎ The resize property allows the author to specify whether or not an element is resizable by the user, and if so, along which axis/axes.
◎名 `resize@p ◎値 `none$v | `both$v | `horizontal$v | `vertical$v ◎初 `none$v ◎適 `overflow$p が `visible$v でない要素, および 任意選択で[ 画像/動画/ `iframe$e ]などの`置換~要素$ ◎ elements with overflow other than visible, and optionally replaced elements such as images or videos, and iframes ◎継 されない ◎百 受容しない ◎算 指定値 ◎順 文法に従う ◎ア 離散的 ◎表終- `none@v
- ~UAは、要素~上に~resize用の仕組みを呈示しない — 利用者には、要素を直に~resizeする操作の仕組みは与えられない。 ◎ The UA does not present a resizing mechanism on the element, and the user is given no direct manipulation mechanism to resize the element.
- `both@v
- ~UAは、縦横二方向の~resize用の仕組みを呈示する — 利用者は、要素の 縦幅, 横幅 いずれも調整できるようになる。 ◎ The UA presents a bidirectional resizing mechanism to allow the user to adjust both the height and the width of the element.
- `horizontal@v
- ~UAは、横方向のみ~resize用の仕組みを呈示する — 利用者は、要素の横幅のみ調整できるようになる。 ◎ The UA presents a unidirectional horizontal resizing mechanism to allow the user to adjust only the width of the element.
- `vertical@v
- ~UAは、縦方向のみ~resize用の仕組みを呈示する — 利用者は、要素の縦幅のみ調整できるようになる。 ◎ The UA presents a unidirectional vertical resizing mechanism to allow the user to adjust only the height of the element.
現在,要素~上の~scroll用の仕組みについては、 `overflow$p ~propを利用して,その外観を制御することもアリである(例: `overflow^p に対する `scroll^v / `hidden^v )。 `resize$p ~propの目的は、要素~上の~resize用の仕組み(例: ~boxや~widgetの~resize)の外観と機能を制御できるようにする所にある。 ◎ Currently it is possible to control the appearance of the scrolling mechanism (if any) on an element using the overflow property (e.g. overflow: scroll vs. overflow: hidden etc.). The purpose of the resize property is to allow control over the appearance and function of the resizing mechanism (e.g. a resize box or widget) on the element.
注記: ~resize用の仕組みは、~scroll用の仕組みと同じでないし,~UAによる~zoom用の仕組みにも関係しない。 ~scroll用の仕組みは,[ 利用者が,要素の内容のどの部位が示されるかを決定できるようにする ]ものである一方、~resize用の仕組みは,[ 利用者が,要素の~sizeを決定できるようにする ]ものである。 ◎ Note: The resizing mechanism is NOT the same as the scrolling mechanism, nor is it related to any UA mechanism for zooming. The scrolling mechanism allows the user to determine which portion of the contents of an element is shown. The resizing mechanism allows the user to determine the size of the element.
`resize$p ~propを適用-可能なのは、[ `overflow$p の算出値が `visible$v でない,要素 ]である。 ~UAは、 `overflow$p ~propの値に関わらず,次のものに適用してよい: ◎ The resize property applies to elements whose computed overflow value is something other than visible. UAs may also apply it, regardless of the value of the overflow property, to:
- 画像や動画を表現している`置換~要素$ — `img$e, `video$e, `picture$e, `svg$e, `object$e, `canvas$e など。 ◎ Replaced elements representing images or videos, such as img, video, picture, svg, object, or canvas.
- `iframe$e 要素。 ◎ The iframe element.
生成d内容における `resize$p ~propの効果は未定義とする。 実装は `resize$p ~propを生成d内容に適用するべきでない。 ◎ The effect of the resize property on generated content is undefined. Implementations should not apply the resize property to generated content.
注記: 将来 `CSSPseudoElement^c ~interfaceが実装されたときには、 `resize$p ~propが生成d内容に適用されるかもしれない。 ◎ Note: the resize property may apply to generated content in the future if there is implementation of Interface CSSPseudoElement.
要素が利用者により~resizeされたときは、~UAは、[ DOM 内の,要素の`~style属性$ ]内の[ `width$p, `height$p ]~propを,利用者から指示された~sizeによる `px^u 単位の長さ値に設定する — 既存の~prop宣言があれば,その `!important^css を除く部分は置換して。 ◎ When an element is resized by the user, the user agent sets the width and height properties to px unit length values of the size indicated by the user, in the element’s style attribute DOM, replacing existing property declaration(s), if any, without !important, if any.
片方の次元のみ,要素が~resizeされた場合、対応する~propのみが設定される。 ◎ If an element is resized in only one dimension, only the corresponding property is set, not both.
~resizeする精確な方向(すなわち,要素のどの隅を改めるか)は、~CSS~layoutに関するいくつもの要因に依存し得る: 要素は絶対位置されているかどうか, `right$p, `bottom$p ~propを利用して位置されているかどうか, 要素の言語が右横書きかどうか,等々。 ~UAは、利用者に~resize用の仕組みをどのように伝えるかを決めるときに,(~CSS~layoutにより決定される)~resizeする方向, 並びに~platformの慣行や拘束を考慮するべきである。 ◎ The precise direction of resizing (i.e. altering the top left of the element or altering the bottom right) may depend on a number of CSS layout factors including whether the element is absolutely positioned, whether it is positioned using the right and bottom properties, whether the language of the element is right-to-left etc. The UA should consider the direction of resizing (as determined by CSS layout), as well as platform conventions and constraints when deciding how to convey the resizing mechanism to the user.
~UAは、利用者が要素を~resizeできる範囲に対して課す拘束を `min-width$p, `max-width$p, `min-height$p, `max-height$p によるものに限ら~MUST。 ◎ The user agent must allow the user to resize the element with no other constraints than what is imposed by min-width, max-width, min-height, and max-height.
注記: 利用者が要素の~resizeを試みても,上書きされたり無視されたように現われる状況があり得る: 例えば、[ DOM 内の,要素の`~style属性$ ]内の[ `width$p, `height$p ]~propに取って代わるような, `!important^css 宣言の~cascadingにより。 ◎ Note: There may be situations where user attempts to resize an element appear to be overriden or ignored, e.g. because of !important cascading declarations that supersede that element’s style attribute width and height properties in the DOM.
要素の `resize$p ~propの算出値に対する変更により、利用者による要素の~resizeすることに因る`~style属性$に対する変更が再設定されることはない。 ◎ Changes to the computed value of an element’s resize property do not reset changes to the style attribute made due to user resizing of that element.
例えば,次のような規則を利用すれば、 `iframe$e を~scroll可能かつ~resize可能にできる: ◎ For example, to make iframes scrollable and resizable, the following rule can be used:
iframe, object[type^="text/"], object[type$="+xml"], object[type="application/xml"] { overflow:auto; resize:both; }
5. ~pointing装置と~keyboard
5.1. ~pointerに関する対話性
5.1.1. ~cursor用の~style: `cursor^p ~prop
◎名 `cursor@p ◎値 [ [`url$vt [ `x$vt `y$vt ]?,]* [ `auto$v | `default$v | `none$v | `context-menu$v | `help$v | `pointer$v | `progress$v | `wait$v | `cell$v | `crosshair$v | `text$v | `vertical-text$v | `alias$v | `copy$v | `move$v | `no-drop$v | `not-allowed$v | `grab$v | `grabbing$v | `e-resize$v | `n-resize$v | `ne-resize$v | `nw-resize$v | `s-resize$v | `se-resize$v | `sw-resize$v | `w-resize$v | `ew-resize$v | `ns-resize$v | `nesw-resize$v | `nwse-resize$v | `col-resize$v | `row-resize$v | `all-scroll$v | `zoom-in$v | `zoom-out$v ] ] ◎初 `auto^v ◎適 すべての要素 ◎継 される ◎百 受容しない ◎算 相対~URLは絶対~URLに変換されることを除いて,指定値 ◎ as specified, except with any relative URLs converted to absolute ◎順 文法に従う ◎ア 離散的 ◎表終この~propは、[ ~pointing装置~用の~cursorの~hotspotが,要素の`~border辺$の中を指している ]ときに表示される,~cursorの型を指定する。 ◎ This property specifies the type of cursor to be displayed for the pointing device when the cursor’s hotspot is within the element’s border edge.
注記: `CSS3BG$r に従い、~border辺は `border-*-radius$p に影響される。 ◎ Note: As per CSS Backgrounds 3 §5.1 Curve Radii: the border-radius properties, the border edge is affected by border-radius.
複数の要素が重合している場合、~cursorの型を決定する要素は、接触判定に基づく — すなわち、その位置からの `click$et ~eventを受取る要素になる。 ◎ In the case of overlapping elements, which element determines the type of cursor is based on hit testing: the element determining the cursor is the one that would receive a click initiated from this position.
注記: 接触判定の~~詳細は,この仕様の視野~外であり、~CSSまたは~HTMLの将来の改訂にて定義されるものと~~期待されている。 ◎ Note: The specifics of hit testing are out of scope of this specification. Hit testing will hopefully be defined in a future revision of CSS or HTML.
~UAは、次に挙げるような~UA~control上では, `cursor$p ~propを無視してよい: ~scrollbar, ~resizer, その他、例えば~form要素~用に ~UAに特有の実装の~~内部で利用され得るような、~native~UI~widgetなど。 ~UAはまた、~UIにおける種々の状態を指示するためとして, `cursor$p ~propを無視して 自身による~cursorを表示してもよい — 頁が応答できないときには~busy~cursor, 利用者が~text選択を行なっているときには~text~cursor, 等々。 ◎ User agents may ignore the cursor property over native user-agent controls such as scrollbars, resizers, or other native UI widgets e.g. those that may be used inside some user agent specific implementations of form elements. User agents may also ignore the cursor property and display a cursor of their choice to indicate various states of the UA’s user interface, such as a busy cursor when the page is not responding, or a text cursor when the user is performing text selection.
注記: `HTML$r は、画像~mapにおける `cursor$p ~prop用に 特別な取扱い を定義している。 ◎ Note: [HTML] defines special handling of image maps for the cursor property.
各種 値の意味は: ◎ Values have the following meanings:
【 ~keyword値に対しては、 その直後の~box にマウスを重ねると,利用中の~UAによる~cursorが示される。 】
- 画像~cursor ◎ image cursors
-
- `url$t
-
~UAは~URIが指名する資源から,~cursorを検索取得する。 ~UAは、~cursor~listの最初の~cursorを取扱えない場合は その次の~URIを, それも取扱えない場合は その次の~URIを, 等々,順に試み~MUST。 ~UAが,どの利用者定義~cursorも取扱えない場合、~listの終端の~cursor~keywordを利用し~MUST。 適合~UAは、 `url$t の代わりに,その上位拡張である `image$t を~supportしてよい。 ◎ The user agent retrieves the cursor from the resource designated by the URI. If the user agent cannot handle the first cursor of a list of cursors, it must attempt to handle the second, etc. If the user agent cannot handle any user-defined cursor, it must use the cursor keyword at the end of the list. Conforming User Agents may, instead of <url>, support <image> which is a superset.
~UAは、次の画像~file形式を~supportし~MUST: ◎ The UA must support the following image file formats:
- PNG `PNG$r ◎ PNG, as defined in [PNG]
- secure static mode `SVG2$r 下における~SVG `SVG11$r のうち,内在的~sizeを有するもの。 ◎ SVG, as defined in [SVG11], in secure static mode [SVG2], if it has an intrinsic size.
- `background-image$p ~propなどの他の~propにおける `image$t 用に~supportされる,他の非~animated画像~file形式 ◎ any other non-animated image file format that they support for <image> in other properties, such as the the background-image property
加えて、~UAは、次の画像~file形式を~supportするべきである: ◎ In addition, the UA should support the following image file formats:
- secure animated mode `SVG2$r 下における~SVG `SVG11$r のうち,内在的~sizeを有するもの。 ◎ SVG, as defined in [SVG11], in secure animated mode [SVG2], if it has an intrinsic size.
- `background-image$p ~propなどの他の~propにおける `image$t 用に~supportされる,他の~animated画像~file形式 ◎ any other animated image file format that they support for <image> in other properties, such as the the background-image property
~UAは、追加で他の~file形式を~supportしてよい — [ secure static mode / secure animated mode ] `SVG2$r 下にあるが内在的~sizeを有さない~SVG `SVG11$r も含め。 ◎ The UA may also support additional file formats, including SVG, as defined in [SVG11], in secure static mode or secure animated mode [SVG2], even if it does not have an intrinsic size.
注記: CSS Working group は、初期~時は,内在的~sizeの有無を問わず すべての~SVGを~supportするものと意図していたが、実装の欠如に因り,内在的~sizeを有さない~SVGは 義務的から任意選択に格下げされた。 ◎ Note: The CSS Working group initially intended support for all SVG, intrinsically sized or not. Support for non intrinsically sized SVG was downgraded from mandatory to optional due to lack of implementations.
注記: この仕様が書かれた時点では( 2015 年 春)、共通的な~desktop~browserが ~cursor用に~supportしている~file形式は, Microsoft が設計した[ .ico, および .cur ]の他にない。 旧来の内容との互換性をとるため、~UAには,これらを~supportすることが奨励される — オープンな仕様がないため,これらの形式についての規範的な要件は作り得ないが。 `Wikipedia^_ にて,ある程度の情報を見られる。 ◎ Note: At the time of writing this specification (spring 2015), the only file formats supported for cursors in common desktop browsers are the .ico and .cur file formats, as designed by Microsoft. For compatibility with legacy content, UAs are encouraged to support these, even though the lack of an open specification makes it impossible to have a normative requirement about these formats. Some information on these formats can be found on Wikipedia.
~cursor画像~用の`既定の~obj~size$は、~UA が定義する — その~sizeは、 ~UAの~OSにて代表的な~cursorの~sizeに基づくべきである。 ◎ The default object size for cursor images is a UA-defined size that should be based on the size of a typical cursor on the UA’s operating system.
`実obj~size$は、`既定の~sizing~algo$を利用して決定される。 ~OSが,所与の~sizeを超える~cursorを描画する能力を欠く場合、その~sizeより大きい~cursorは — ~cursor画像に内在的~縦横比があれば,それは保守しつつ — ~OSで~supportされる~~限界~sizeまで縮短され~MUST。 ◎ The concrete object size is determined using the default sizing algorithm. If an operating system is incapable of rendering a cursor above a given size, cursors larger than that size must be shrunk to within the OS-supported size bounds, while maintaining the cursor image’s intrinsic ratio, if any.
- `x@vt `y@vt
-
`x$vt, `y$vt 座標(省略可)は、画像の中の正確な~pointer位置(~hotspot)を識別する。 ◎ The optional <x> and <y> coordinates identify the exact position within the image which is the pointer position (i.e., the hotspot).
いずれも `number$t である。 ~cursorの座標系における(左端, 上端に相対的な)位置の x, y 座標は、画像~内で~pointerが指す精確な位置を表現する。 ◎ Each is a <number>. The x-coordinate and y-coordinate of the position in the cursor’s coordinate system (left/top relative) which represents the precise position that is being pointed to.
注記: この仕様は、種々の型の `image$t 用に座標系を確立する方法は定義しない。 それらの定義は `CSS4-IMAGES$r まで先送りされる。 ◎ Note: This specification does not define how the coordinate systems of the various types of <image> are established, and defers these definitions to [CSS4-IMAGES].
値が指定されていない場合、利用された画像~資源の~~内部で定義される,内在的~hotspotになる。 その~hotspotも定義されていない場合の効果は、値 `0 0^v が指定されたかのようになる。 ◎ If the values are unspecified, then the intrinsic hotspot defined inside the image resource itself is used. If both the values are unspecific and the referenced cursor has no defined hotspot, the effect is as if a value of "0 0" were specified.
~hotspotの座標が — 画像~資源の~~内部か, `x$vt, `y$vt 値のいずれで指定されるにせよ — ~cursor画像の外側に出る場合、内側に入るように( x, y について独立に)切詰められ~MUST。 ◎ If the coordinates of the hotspot, as specified either inside the image resource or by <x> and <y> values, fall outside of the cursor image, they must be clamped (independently) to fit.
- 一般用~cursor ◎ general purpose cursors
-
- `auto@v
- ~UAは、現在の文脈に基づいて,表示する~cursorを決定する。 特定的には、[ 選択-可能な~text / 編集-可能な要素 ]上では `text$v, 他では `default$v のように挙動する。 ◎ The UA determines the cursor to display based on the current context. Specifically: auto behaves as text over selectable text or editable elements, and default otherwise.
- `default@v
- ~platformに依存する既定の~cursor。 矢印として描画されることが多い。 ◎ The platform-dependent default cursor. Often rendered as an arrow.
- `none@v
- 要素に対しては~cursorは描画されない。 ◎ No cursor is rendered for the element.
- ~link/~~状態を表す~cursor ◎ links and status cursors
-
- `context-menu@v
- ~cursorが指す~objにて,~context-menuが可用であることを指示する。 ~menuに似た小さな~graphicを傍に伴う,矢印として描画されることが多い。 ◎ A context menu is available for the object under the cursor. Often rendered as an arrow with a small menu-like graphic next to it.
- `help@v
- ~cursorが指す~objにて,~helpが可用であることを指示する。 疑問符や~balloonとして描画されることが多い。 ◎ Help is available for the object under the cursor. Often rendered as a question mark or a balloon.
- `pointer@v
- ~linkを指示する~pointer~cursor。 人差し指を立てた手の甲として描画されることが多い。 ◎ The cursor is a pointer that indicates a link. Often rendered as the backside of a hand with the index finger extended.
- 他が指定されない限り,~UAは、自身が~supportする すべての文書~形式において,~hyperlink用の `cursor$p にはこの値を — 通常の(すなわち, `!important$css でない)宣言を,`~UA~stylesheet$に利用することを介して — 適用し~MUST。 ◎ Unless otherwise specified, UAs must apply cursor: pointer to hyperlinks for all supported document formats via the UA stylesheet, using a normal (i.e. not !important) declaration.
- `progress@v
- ~programが何らかの処理を遂行していて,進捗中にあることを指示する。 利用者は~programと対話できることを表す点で `wait$v と異なる。 ~~回転する~beach-ball,あるいは 腕時計/砂時計を伴う矢印として描画されることが多い。 ◎ A progress indicator. The program is performing some processing, but is different from wait in that the user may still interact with the program. Often rendered as a spinning beach ball, or an arrow with a watch or hourglass.
- `wait@v
- ~programが処理中( ~busy )にあり,利用者は待機すべきであることを指示する。 腕時計や砂時計として描画されることが多い。 ◎ Indicates that the program is busy and the user should wait. Often rendered as a watch or hourglass.
- 選択~cursor ◎ selection cursors
-
- `cell@v
- 利用者は いくつかの~cellを選択できることを指示する。 真中に~dotを伴う,太めの正符号として描画されることが多い。 ◎ Indicates that a cell or set of cells may be selected. Often rendered as a thick plus-sign with a dot in the middle.
- `crosshair@v
- 単純な極細十字線。 二次元~bitmap選択~modeを指示するために利用されることが多い。 ◎ A simple crosshair (e.g., short line segments resembling a "+" sign). Often used to indicate a two dimensional bitmap selection mode.
- `text@v
- 利用者は,~textを選択できることを指示する。 縦方向 ~I-beam として描画されることが多い。 ~UAは、縦書き~text用には,自動的に横方向の~I-beam ~cursorを(例えば `vertical-text$v ~keywordに対するとき同じに)表示してよい。 あるいは、斜めに描画される~text用には,その角度の~I-beam~cursorを表示してよい。 ◎ Indicates text that may be selected. Often rendered as a vertical I-beam. User agents may automatically display a horizontal I-beam/cursor (e.g. same as the vertical-text keyword) for vertical text, or for that matter, any angle of I-beam/cursor for text that is rendered at any particular angle.
- `vertical-text@v
- 利用者は,縦書き~textを選択できることを指示する。 横方向 ~I-beam として描画されることが多い。 ◎ Indicates vertical-text that may be selected. Often rendered as a horizontal I-beam.
- ~drag&~drop ~cursor ◎ drag and drop cursors
-
- `alias@v
- 何かの~alias/何かへの~shortcut が作成されることになることを指示する。 曲がった小さな矢印を傍に伴う,矢印として描画されることが多い。 ◎ Indicates an alias of/shortcut to something is to be created. Often rendered as an arrow with a small curved arrow next to it.
- `copy@v
- 何かが複製されることになることを指示する。 小さな正符号を傍に伴う,矢印として描画されることが多い。 ◎ Indicates something is to be copied. Often rendered as an arrow with a small plus sign next to it.
- `move@v
- 移動されることになる何かを指示する。 ◎ Indicates something is to be moved.
- `no-drop@v
- ~drag中の~itemは,~cursorが現在 指す所には~dropできないことを指示する。 打ち消し線を伴う小さな円を伴う[ 手/~pointer ]として描画されることが多い。 ◎ Indicates that the dragged item cannot be dropped at the current cursor location. Often rendered as a hand or pointer with a small circle with a line through it.
- `not-allowed@v
- 要請された動作は、~~実行されないことを指示する。 打ち消し線を伴う円として描画されることが多い。 ◎ Indicates that the requested action will not be carried out. Often rendered as a circle with a line through it.
- `grab@v
- 何かを掴める(~drag/移動できる)ことを指示する。 開いた手の甲の様に描画されることが多い。 ◎ Indicates that something can be grabbed (dragged to be moved). Often rendered as the backside of an open hand.
- `grabbing@v
- 何かを掴んでいる(~drag/移動している)ことを指示する。 閉じた手の甲の様に描画されることが多い。 ◎ Indicates that something is being grabbed (dragged to be moved). Often rendered as the backside of a hand with fingers closed mostly out of view.
- ~resize/~scroll時の~cursor(括弧内の矢印は方向を表す) ◎ resizing and scrolling cursors
-
- `e-resize@v(→)
- `n-resize@v(↑)
- `ne-resize@v(↗)
- `nw-resize@v(↖)
- `s-resize@v(↓)
- `se-resize@v(↘)
- `sw-resize@v(↙)
- `w-resize@v(←)
- ある辺が移動されることを指示する。 例えば、~boxの右下~隅(南東 — south-east )から動き始めるときは, `se-resize$v ~cursorが利用される。 ◎ Indicates that some edge is to be moved. For example, the se-resize cursor is used when the movement starts from the south-east corner of the box.
- `ew-resize@v(←→)
- `ns-resize@v(↑↓)
- `nesw-resize@v(↙↗)
- `nwse-resize@v(↖↘)
- 双方向への~resize~cursorを指示する。 ◎ Indicates a bidirectional resize cursor.
- `col-resize@v(←→)
- ~itemや~columnを横方向に~resizeできることを指示する。 左右を指す矢印に, それらを分離する縦~barが伴われて描画されることが多い。 ◎ Indicates that the item/column can be resized horizontally. Often rendered as arrows pointing left and right with a vertical bar separating them.
- `row-resize@v(↑↓)
- ~itemや~columnを縦方向に~resizeできることを指示する。 上下を指す矢印に, それらを分離する横~barが伴われて描画されることが多い。 ◎ Indicates that the item/row can be resized vertically. Often rendered as arrows pointing up and down with a horizontal bar separating them.
- `all-scroll@v
- 何かを,どの方向にも~scrollできることを指示する。 真中に~dotを伴う,上下左右を指す矢印として描画されることが多い。 ◎ Indicates that the something can be scrolled in any direction. Often rendered as arrows pointing up, down, left, and right with a dot in the middle.
- ~zoom用の~cursor ◎ zooming cursors
-
- `zoom-in@v
- `zoom-out@v
- 何かを内外へ~zoom(拡大縮小)できることを指示する。 中心に[ "+" ( `zoom-in$v のとき)/ "−" ( `zoom-out$v のとき) ]を伴う,拡大鏡の様に描画されることが多い。 ◎ Indicates that something can be zoomed (magnified) in or out, and often rendered as a magnifying glass with a "+" or "-" in the center of the glass, for zoom-in and zoom-out respectively.
いくつかの~cursor値とともに,~fallback~cursorを利用する例: ◎ Here is an example of using several cursor values.
:link,:visited { cursor: url(example.svg#linkcursor), url(hyper.cur), url(hyper.png) 2 3, pointer }
この例は、すべての~hyperlink上で(訪問-済み( `visited^ps )か否かにかかわらず),~cursorを外部 ~SVG~cursor ( `SVG11$r, 16.8.3 節)に設定する。 ~SVG~cursorを~supportしない~UAは、単純に,次の値 `hyper.cur^v ~cursorを利用しようと試み、その~cursor形式も~supportしない場合,明示的な~hotspotを伴う `hyper.png^v ~cursorの利用を試み、これらのどの画像~cursor形式も~supportしない場合,最後の値による `pointer$v ~cursorを描画することになる。 ◎ This example sets the cursor on all hyperlinks (whether visited or not) to an external SVG cursor ([SVG11], section 16.8.3). User agents that don’t support SVG cursors would simply skip to the next value and attempt to use the "hyper.cur" cursor. If that cursor format was also not supported, the UA could attempt to use the "hyper.png" cursor with the explicit hotspot. Finally if the UA does not support any of those image cursor formats, the UA would skip to the last value and render the pointer cursor.
5.1.1.1. ~canvasの~cursor
文書の`~canvas$とは、文書が描画される無限平面である `CSS21$r 。 ~canvasに対応する要素は無いので、どの要素にも触れない~cursorにも~styleをあてがえるようにするため、~canvasの~cursorには,根~要素の~cursorが再~利用される。 しかしながら、根~要素~用の~boxが生成されない場合(例えば,根~要素の `display$p が `none^v にされているなど)、~canvas~cursorは,~platformに依存する既定の~cursorになる。 ◎ The document canvas is the infinite surface over which the document is rendered [CSS21]. Since no element corresponds to the canvas, in order to allow styling of the cursor when not over any element, the canvas cursor re-uses the root element’s cursor. However, if no boxes are generated for the root element (for example, if the root element has display: none), then the canvas cursor is the platform-dependent default cursor.
注記: 不可視の要素でも,~boxを生成することはある。 例えば、要素の `visibility$p は `hidden^vにされていて, `display$p は `none^v にされていない場合、~boxは生成され,その~cursorが~canvasに利用される。 ◎ Note: An element might be invisible, but still generate boxes. For example, if the element has visibility: hidden but not display: none, boxes are generated for it and its cursor is used for the canvas.
5.2. ~text挿入~caret
5.2.1. 挿入~caretの色付け: `caret-color^p
◎名 `caret-color@p ◎値 `auto$v | `color$vt ◎初 `auto^v ◎適 すべての要素 ◎継 される ◎百 受容しない ◎算 `auto$v に対しては `auto^v 。 `color$t 値に対しては `CSS-COLOR-4$r による`色~値の解決-法$を見よ。 ◎ The computed value for auto is auto. For <color> values, see resolving color values in [CSS-COLOR-4]. ◎順 文法に従う ◎ア `色として$ ◎表終- `auto@v
- ~UA は `currentcolor$v を利用するべきである。 ~UA は、良好な視認性/周囲の内容との~contrastを確保するため,~caretの色を自動的に調整してよい — `currentcolor^v, 背景, 影, 等々に基づくなどして。 ◎ User agents should use currentColor. User agents may automatically adjust the color of caret to ensure good visibility and contrast with the surrounding content, possibly based on the currentColor, background, shadows, etc.
- 注記: `caret-shape$p が `block$v のとき,良好な可視性と~contrastを確保することは、 `currentcolor$v 以外の色を~UAが決定することで最善に達成される。 ◎ Note: When caret-shape is block, ensuring good visibility and contrast is best achieved with a UA determined color other than currentColor.
- `color$t
- 挿入~caretの色は,指定された色になる。 ◎ The insertion caret is colored with the specified color.
~caretは、利用者が[ ~text (あるいは他の内容もあり得る)を挿入できる所を指す,要素~内の挿入~箇所 ]を,視覚的に指示するものである。 この~propは、その可視~指示子の色を制御する。 ◎ The caret is a visible indicator of the insertion point in an element where text (and potentially other content) is inserted by the user. This property controls the color of that visible indicator.
注記: ~UAは、追加の何かを “~caret” と扱うこともある。 例えば,~UAには “~navi~caret” を示すものもあり、挿入~caretと似たように動作しつつ,~caretとして機能するように編集できない~text周りにも移動し得る。 他方、 `cursor$p ~propが[ `auto$v / [ `text$v / `vertical-text$v ]]にされた[ ~text/要素 ]を~hoverするときに示される~cursor画像は、~caretに似せられることもあろうが,~caretではない(それは~cursorである)。 ◎ Note: UAs might have additional things that count as “carets”. For example, some UAs can show a “navigation caret”, which acts similarly to an insertion caret but can be moved around in non-editable text, and is functionally a caret. On the other hand, the cursor image shown when hovering over text when the cursor property is auto, or when hovering over an element where the cursor property is text or vertical-text, though it sometimes resembles a caret, is not a caret (it’s a cursor).
caret-color:#00aacc; を伴う `textarea$e: ◎ Example: a textarea with caret-color:#00aacc;
5.2.2. 挿入~caretの形状: `caret-shape$p
◎名 `caret-shape@p ◎値 `auto$v | `bar$v | `block$v | `underscore$v ◎初 `auto$v ◎適 入力を受容する要素 ◎ elements that accept input ◎継 される ◎百 受容しない ◎算 指定値 ◎順 文法に従う ◎ア 不可 ◎表終この~propは、~text挿入~caretに欲される形状を,作者が指定できるようにする。 ◎ This property allows authors to specify the desired shape of the text insertion caret.
この定義の文脈においては、 `文字@ とは, `UAX29$r にて定義される extended grapheme cluster (拡張された書記素~cluster)として解されるとし、 `可視~文字@ とは,送幅が 0 でない文字を意味する。 ◎ Within the context of this definition, character is to be understood as extended grapheme cluster, as defined in [UAX29], and visible character means a character with a non-zero advance measure.
- `auto@v
- ~caretの形状は、~UAが決定する。 それは、~platform規約に合致するべきであり,文脈に基づいて調整されても~MAY。 例えば、~UAは ~insert(~~挿入)~modeと ~overtype(~~上書き)~mode とを切替える場合、利用者が~keyboard上の insert ~keyを押し下げたときは、[ ~insert~modeにおいては `bar$v, ~overtype~modeにおいては `block$v ]による~caretを示して~MAY。 ◎ The UA determines the shape of the caret. It should match platform conventions, and may be adjusted based on context. For example, if a UA switches between insert mode and overtype mode when the user presses the insert key on their keyboard, it may show a bar caret in insert mode, and a block caret in overtype mode.
- `bar@v
- ~UAは、~text挿入~caretを挿入~点に置かれる細い~barとして描画し~MUST。 これは、文字には重ならない,`文字$の[ 合間 / 前 / 後 ]いずれかを意味する。 ~barは、`行内-軸$と垂直になるべきである。 ただし,[ ~italic/~oblique ]~textを挿入するときは、~UAは傾けて描画しても~MAY。 ◎ The UA must render the text insertion caret as a thin bar placed at the insertion point. This means it is between, before, or after characters, not over them. It should be perpendicular to the inline progression direction, although UAs may render it slanted when inserting italic or oblique text.
- `block@v
- ~UAは、~text挿入~caretを,[ 挿入~点に後続する次の`可視~文字$に重合している矩形 ]として描画し~MUST。 そのような文字が後続していない場合、~UAは ~caretを最後の`可視~文字$の後に描画し~MUST。 ~UAは、[ ~italic/~oblique ]~textを挿入している所では,描画する矩形を傾けても~MAY。 ◎ The UA must render the text insertion caret as a rectangle overlapping the next visible character following the insertion point. If there is no visible character after the insertion point, the UA must render the caret after the last visible character. UAs may render it as a slanted rectangle when inserting italic or oblique text.
- `underscore@v
- ~UAは、~text挿入~caretを,[ 挿入~点に後続する次の`可視~文字$ ]が占める`行-下面$に,細い線として描画し~MUST。 そのような文字が後続していない場合、~UAは,最後の`可視~文字$の後に~caretを描画し~MUST。 ◎ The UA must render the text insertion caret as a thin line under (as defined in [CSS-WRITING-MODES-3] the next visible character following the insertion point. If there is no visible character after the insertion point, the UA must render the caret after the last visible character.
[ `block$v / `underscore$v ]~caretの横幅は、挿入~点の後に来る次の`可視~文字$の送幅にされるべきである — ただし、[ そのような文字は無い/ この情報を決定することは実用的でない ]場合には `1ch^v にされるべきである。 ◎ The width of the block and underscore carets should be the advance measure of the next visible character after the insertion point, or 1ch if there is no next visible character or if this information is impractical to determine.
~caretの方位と外観を決定するときは、~UAは,`書字mode$ `CSS-WRITING-MODES-3$r を織り込んだ上で, 変形 `CSS-TRANSFORMS-1$r を適用し~MUST。 編集された~textが ある~path上に~lay-outされている場合 — 具体例として,~SVG `textPath$e 要素を利用して — ~UAは それも織り込むべきである。 ◎ When determining the orientation and appearance of the caret, UAs must take into account the writing mode [CSS-WRITING-MODES-3] and must apply transformations [CSS-TRANSFORMS-1]. If the edited text is laid out out on a path, for instance by using the SVG textPath element, UAs should also account for this.
~caretを積層する位置は、~UAは 次の拘束を満たすことを除き,未定義とする: ◎ The stacking position of the caret is left undefined, within the following constraints:
- ~caretは、要素の背景で遮られては~MUST_NOT。 ◎ The caret must not be obscured by the background of the element
- `block$v ~caretに対しては、それに重合している文字が~caretに遮られないように描画し~MUST。 ◎ UAs must render block carets so that the character it overlaps with is not obscured by the caret
種々の~caret形状の代表的な外観を図示する。 各 見本~描画における挿入~点は、字 "u" と "m" の合間にあるとする。 ◎ This illustrates the typical appearance of the various caret shapes. In each of the sample renderings below, the insertion point is between the letters u and m.
`caret-shape$p | 見本~描画 | 利用中の~browserにおける呈示(~cellを~focusすれば~caretを見れる) |
---|---|---|
`bar$v | Lorem ipsum | Lorem Ipsum |
`block$v | Lorem ipsum | Lorem Ipsum |
`underscore$v | Lorem ispum | Lorem Ipsum |
[ `underscore$v / `block$v ]~caretは、この例にあるように,~terminalや~command-lineで共通的に利用される。 ◎ underscore or block carets are commonly used in terminals and command lines, as in this example.
.console { caret-shape: underscore; background: black; color: white; font-family: monospace; padding: 1ex; }
これがどんな見かけになるべきかを,下に模倣される描画で図示する。 ◎ The simulated rendering below illustrates how this should look.
user@host:css-ui-4 $ ls -a
. .. Overview.bs Overview.html
user@host:css-ui-4 $
要素を~focusすれば、利用中の~browserがそれをどう描画するか見れる。 ◎ Focus the element below to see how your browser renders it.
user@host:css-ui-4 $ ls -a . .. Overview.bs Overview.html user@host:css-ui-4 $
5.2.3. 挿入~caret略式~prop:`caret^p
◎名 `caret@p ◎値 `caret-color$tp || `caret-shape$tp ◎初 `auto^v ◎適 入力を受容する要素 ◎ elements that accept input ◎継 される ◎百 受容しない ◎算 個々の~propを見よ ◎順 文法に従う ◎ア 個々の~propを見よ ◎表終この略式~propは、[ `caret-color$p, `caret-shape$p ]を 1 個の宣言で設定する。 省略された値は、それぞれの初期~値に設定される。 ◎ This property is a shorthand for setting caret-color and caret-shape in one declaration. Omitted values are set to their initial values.
5.3. ~keyboardによる制御
5.3.2. 廃用: `ime-mode^p ~prop
一部の~browserで ある程度~実装されている `ime-mode^p ~propは、問題を孕んでおり,この仕様とその前の仕様 `CSS-UI-3$r により公式的に廃用にされた。 ◎ ime-mode is a property somewhat implemented in some browsers, that is problematic and officially obsoleted by this specification and its predecessor [CSS-UI-3].
これらの実装の非 相互運用性について 文書化されている。 ◎ There is documentation of non-interoperability of these implementations.
~UAは、 `ime-mode^p ~propを~supportするべきでない。 ◎ User agents should not support the ime-mode property.
作者は、 `ime-mode^p ~propを利用しては~MUST_NOT。 ◎ Authors must not use the ime-mode property.
利用者が,利用者~stylesheetにて `ime-mode^p ~propを利用してよいのは、不良~siteや旧来の実装~用に回避策を要するような,修復-の利用事例に限られるとする — 例えば,次の様な利用者~stylesheet規則を用いて: ◎ Users may use the ime-mode property only for repair use-cases where they have to work around bad sites and legacy implementations, e.g. with a user style sheet rule like:
利用者~選好の例: ◎ Example: user preference
input[type=password] { ime-mode: auto !important; }
この~CSSは、~password入力~fieldの挙動を既定の方式に強制するために,利用者~stylesheet~fileの中に置かれてよい。 ◎ This example CSS may be placed into a user style sheet file to force password input fields to behave in a default manner.
この仕様は、旧来の `ime-mode^p 実装の機能性を文書化することも,それが何を特定的に~supportするかも,~~意図的に試みない — そのような方針を追求する/推奨することは,無意味なので。 ◎ This specification deliberately does not attempt to document the functionality of legacy ime-mode implementations nor what they specifically support because it does not make sense to pursue or recommend any such path.
注記: `HTML5$r には、[ 利用者にとってより良い入力~体験を,~UAが供せるようにする ]ための情報を~UAに供するために,作者が利用するべき特色機能がある: ◎ Note: there are several [HTML5] features which authors should use to provide information to user agents that allow them to provide a better input user experience:
- 大域的 `lang$a 属性 ◎ The global lang attribute
- `input$e 要素の[ `inputmode^a, `pattern^a, `type^a ]属性 ◎ The inputmode, pattern, and type attributes of the input element
6. 利用者との対話
6.1. 内容~選択の制御-法
`user-select$p ~propは、[ 文書~内のどの要素をどう選択できるか ]を,作者が指定できるようにする。 これにより,[ どの要素も選択するに等しく有用 ]ではないときでも、利用者は,不用意に隣接する内容を選択するのを避けられ,対話し易くなる。 ◎ The user-select property enables authors to specify which elements in the document can be selected by the user and how. This allows for easier interactions when not all elements are equally useful to select, avoiding accidental selections of neighbouring content.
◎名 `user-select@p ◎値 `auto$v | `text$v | `none$v | `contain$v | `all$v ◎初 `auto$v ◎適 すべての要素, および ~UAの任意選択で[ `before$pe, `after$pe ]疑似要素 ◎ all elements, and optionally to the ::before and ::after pseudo elements ◎継 されない ◎百 受容しない ◎算 下を見よ ◎順 文法に従う ◎ア 離散的 ◎表終~UAは、[ `first-line$pe / `first-letter$pe ]疑似要素には, `user-select$p ~propを適用しては~MUST_NOT。 ◎ User Agents must not apply the user-select property to the ::first-line and ::first-letter pseudo elements.
注記: ~UAは、[ `before$pe / `after$pe ]疑似要素にも,この~propを適用して~MAY。 そうする場合、これらの疑似要素~上では,値 `auto$v は `none$v に算出されるが、他の値も指定できる。 これは、生成d内容を[ 選択-/~copy ]できない旧来の挙動を保全する — それは、これらの疑似要素が装飾的な目的に利用されたときには,適切になる。 しかしながら,この~propは、それらが内容の一部を生成するために利用される事例においても,利用者の期待に沿うよう[ 選択-/~copy ]可能にする。 作者は、装飾的でない目的には,生成d内容を利用するのはアリな限り避けて、すべての内容を~DOM内に含めることを選好するべきである。 この特色機能は~risk下にある。 ◎ Note: The UA may apply this property to the ::before and ::after pseudo elements. If it does, auto value computes to none on these pseudos, but other values can be specified. This preserves the legacy behavior of generated content not being selectable or copyable, which is appropriate when these pseudos are used for decorative purposes. However, this property allows them to become selectable and copyable, as the user would expect in cases where they are used to generate part of the content, such as the issue numbers in this document. To the extent possible, authors should avoid using generated content for non decorative purposes, and should prefer including all the content in the DOM. This feature is at risk.
`user-select^p を `none$v 以外の値に変更することが ~copy可否と~DOM~API において何を意味するか,~~明らかにする必要がある。 ◎ if we allow user-select to change to a value other than none, we need to figure out what this means for copyability, and DOM APIs.
疑似要素~内の生成d内容が,この仕組みを通して選択-可能になるときは、~UAは,探索~機能からも その内容を見出せるようにするべきである。 ◎ When generated content in pseudo elements becomes selectable through this mechanism, UAs should also make this content findable through their search function.
`marker$pe にも適用するべきか? `頁~margin~box$にも適用するべきか? `auto$v に対する算出値は `none$v, `text$v のどちらが適切か? ◎ Should it also apply to ::marker? To page-margin boxes? Should the computed value of auto also be none, or would text be more appropriate?
次に挙げる場合を除き,算出値は指定値になる: ◎ The computed value is the specified value, except:
- `編集-可能な要素$上では、指定値に関わらず,算出値は常に `contain$v になる。 ◎ on editable elements where the computed value is always contain regardless of the specified value
- 指定値が `auto$v のときは、下に定義される他のいずれかの値に算出される。 ◎ when the specified value is auto, which computes one of the other values as defined below
この仕様の目的においては、次に該当する要素が `編集-可能な要素@ とされる ⇒ 編集中の~host/ `変異-可能$な~form~controlのうち,~textを内容とするもの — `textarea$e など。 ◎ For the purpose of this specification, an editable element is either an editing host or a mutable form control with textual content, such as textarea.
編集中の~hostの編集-可能な子孫である要素~上の算出値に対し,何が起こるかについて、拘束はあるべきか? その意味論は、明白ではない。 `none$v は `text$v に算出されるべきかもしれないし, 他の値も `text$v に算出されるべきかもしれない。 ◎ Should there be constraints on what happens to the computed value on elements that are editable descendants of editing hosts? The semantics are not obvious. Maybe none should compute to text, or maybe all values should compute to text.
- `auto@v
- `auto$v に対する算出値は、[ `before$pe / `after$pe ]疑似要素~上では `none$v になる。 ◎ The computed value of auto is determined as follows: ◎ On the ::before and ::after pseudo elements, the computed value is none
-
`auto$v に対する算出値は、要素~上では,次に従って決定される: ◎ ↑
- `編集-可能な要素$ならば、 `contain$v になる。 ◎ If the element is an editable element, the computed value is contain
- 他の場合,親の `user-select$p の算出値は[ `all$v / `none$v ]ならば、それと同じになる。 ◎ Otherwise, if the computed value of user-select on the parent of this element is all, the computed value is all ◎ Otherwise, if the computed value of user-select on the parent of this element is none, the computed value is none
- 他の場合、 `text$v になる。 ◎ Otherwise, the computed value is text
注記: この[ 継承されない~propと, 初期~値 `auto$v に対する算出値が親~要素に依存すること ]との通例的でない組合わせは、実質的には,選択的な継承をアリにするためにある。 これは,当初は、 Microsoft IE において継承に類似する挙動を導入するために提案された — ここでは、値 `contain$v は継承されないが。 ◎ Note: This unusual combination of a non inherited property with an initial value of auto whose computed value depends on the parent element makes it possible to create what is effectively selective inheritance. This was initially proposed by Microsoft in IE to introduce a behavior similar to inheritance except that the contain value does not inherit.
- `text@v
- 要素は、選択に拘束を課さない。 ◎ The element imposes no constraint on the selection.
- `none@v
- ~UAは、この要素~内から開始される選択を許容しては~MUST_NOT。 ◎ The UA must not allow selections to be started in this element.
-
この要素の外側から開始される選択は、この要素~内で終端しては~MUST_NOT。 利用者が そのような選択を作成しようと試みた場合、~UAは,代わりに選択~範囲を要素~境界の所で終端し~MUST。 ◎ A selection started outside of this element must not end in this element. If the user attempts to create such a selection, the UA must instead end the selection range at the element boundary.
注記: これを書いている時点では、試験的な実装は,この様に挙動していない部分がある。 Firefox は、そう挙動する。 Chrome, Safari は、ほぼそう挙動する: 選択が要素より後から開始して, 要素の中へ後戻りしようと試行している場合,それらはここに指定したように挙動するが、選択が要素より前から開始して, 要素の中へ進もうと試行している場合、要素は `all$v にされていたかのように挙動する結果,全体を選択する。 IE ( Internet Explorer )は要素の外側から開始され, 要素の中へ行く選択を全く制約しない。 Chrome, Safari における別の相違には、 `none$v にされた要素の内側からも選択を開始できることが挙げられる — 選択が要素の外で終端したときには、要素の境界から終端した所までの選択が作成される。 Firefox, IE は、この仕様に述べたとおりに挙動するので,選択を全く作成しない。 ◎ Note: As of the time of writing, experimental implementations do not all behave like this. Firefox does. Chrome and Safari almost do: for a selection started after the element and trying to go backwards into the element they behave as specified here, but for a selection started before the element and trying to go into the element they behave as if the element has all and select it entirely. IE does not restrict selections started outside of the element from going into it at all. Another difference is that in Chrome and Safari, if the user attempts to start a selection inside a user-select: none, and to end the selection out of it, a selection will be created from the boundary of the element to the user-designated end-point. Firefox and Internet explorer behave as prescribed in this specification and do not create a selection at all.
- しかしながら,この要素の子孫に[ `user-select$p の算出値が `none$v にならないもの ]がある場合、そのような子孫の中で開始して, 終端する選択は,許容される。 ◎ However, if this element has descendants on which the computed value of user-select is not none, selections that start and end within these descendants are allowed.
- ~UAは、選択が この要素を挟むように拡張することを許容した上で,そのような選択からこの要素を除外し~MUST。 ただし、選択ごとに複数の範囲を~supportしない~UAは,この要素を含めて~MAY。 この要素の子孫に[ `user-select$p の算出値が `none$v にならないもの ]がある場合、そのような子孫は,要素を挟むように拡張している選択~内に含まれ~MUST。 この仕様は、~clipboardの挙動についての規範的な要件は課さない: しかしながら,~UAには、~copy時に~clipboardに~copyされるものと, 視覚的~選択との整合性を保つことが奨励される。 選択されたように現れない~textを~copyすること, あるいはその逆は、利用者をひどく惑わすので。 ◎ The UA must allow selections to extend across this element, and must exclude this element from such a selection. An exception is made for UAs which do not support multiple ranges per selection, and they may include this element. If the element has descendants on which user-select does not compute to none, these descendants must be included in a selection extending across the element. This specification makes no normative requirement about the behavior of the clipboard. however, UAs are encouraged to keep the visual selection consistent with what would get copied to the clipboard when copying. Copying text that does not appear to be selected, or vice versa, is highly confusing to users.
- `user-select$p が `none$v にされた要素~内から — それを~clickする/ その中から~dragを開始するなどにより — 選択を開始しようと試みられても、既存の選択は,いかなる仕方でも — 未選択にされるなど — 影響されては~MUST_NOT。 ◎ Attempting to start a selection in an element where user-select is none, such as by clicking in it or starting a drag in it, must not cause a pre-existing selection to become unselected or to be affected in any way.
-
`user-select$p は、~UI利便の仕組みであり,~copy保護の仕組みではない — ~UAは、 `user-select$p が `none$v にされようが,利用者が~textを明示的に選択する代替的な仕方を供しても~MAY。 ◎ As user-select is a UI convenience mechanism, not a copy protection mechanism, the UA may provide an alternative way for the user to explicitly select the text even when user-select is none.
注記: `none$v は~copy保護の仕組みではないので、そのように利用しても,効果は無い:
- ~UAには、それを迂回する仕方を供することが許容される。
- ~supportしない旧来の~UAには,その効果は無い。
- いずれにせよ,利用者は、~UAの利用者~stylesheetやそれに等価な仕組みを通して不能化できる。
`none$v に意味されているのは、[ 作者が、選択しても有用にならない~UI要素の選択を不能化できるようにする ]ことにより,[ 利用者が,求める内容を選択し易くする ]ことである。 [ ~CSS検証器, ~linter, ~browser内の開発者~tool ]などの~toolには、経験則を利用して,[ 使い勝手を悪くしたり,共通的な利用者の期待に違反する ]ような[ 不正, あるいは濫用的 ]な用法を検出して,警告することが奨励される。
◎ Note: none is not a copy protection mechanism, and using it as such is ineffective: User Agents are allowed to provide ways to bypass it, it will have no effect on legacy User Agents that do not support it, and the user can disable it through the user style sheet or equivalent mechanisms on UAs that do anyway. Instead, none is meant to make it easier for the user to select the content they want, by letting the author disable selection on UI elements that are not useful to select. Tools such as CSS validators, linters or in-browser developer tools are encouraged to use heuristics to detect and warn against incorrect or abusive usage that would hamper usability or violate common user expectations. -
注記: 作者は、利用者を不必要に拘束しないことについて注意深くあるべきである。 例えば,根~要素~上の `user-select$p を `none^v に設定した上で[ 作者が選択するに有用と判定した,一握りの要素において、その制約を緩める ]ことは、利用者をいらつかせかねない: ◎ Authors should be careful about not constraining the user unnecessarily. For example, setting user-select: none on the root element, and relaxing that restriction on a handful of elements the author judges useful to select can be frustrating to users:
- 空の区画を~clickして現在の選択を未選択にすることが,できなくなる ◎ Clicking in empty areas to undo the current selection will no longer be effective
- 作者は、選択-可能にすべき区画を見落とすかもしれない ◎ The author may have overlooked some areas which should be selectable
- 後で頁に区画を追加するとき,選択-可能にし忘れるかもしれない ◎ Areas may be added later to the page without remembering to make them selectable
- 利用者は主だった内容~以外の~text片を選択したいと求めるかもしれない — 具体例として、それらを[ 何らかの辞書や翻訳~toolで検索する / 探索~engine内で警告や~error~messageを見つける ]ためなど… ◎ The user may want to select pieces of text other than the main content, for instance to look them up in a dictionary or in some translation tool, or to look for warnings and error messages in a search engine…
作者にとって代わりになる良い実施は、[ 不用意に選択されると,意図される動作に干渉すると見込まれる要素 ]に対し,選択的に
`user-select$p: `none^v
を適用することである。 頁~内の[ 対話されないと見込まれる部品 ]を不用意に選択-可能なままにする方が、その逆にするより,ずっと利用者をいらつかせずに済むと見込まれるので。 ◎ Instead, a good practice is for authors is to selectively apply user-select: none to elements which seem likely to be accidentally selected when doing so would interfere with the more likely intended action. Accidentally leaving parts of the page that are unlikely to be interacted with selectable will likely cause much less frustration to users than the opposite. - `contain@v
- ~UAは、この要素から開始された選択が,要素の外側まで拡張されるのを許容しては~MUST_NOT。 ◎ UAs must not allow a selection which is started in this element to be extended outside of this element.
- この要素の外側から開始された選択は、この要素~内で終端しては~MUST_NOT。 利用者がそのような選択を作成しようと試みた場合には、~UAは,選択~範囲を要素~境界の所で終端させ~MUST。 ◎ A selection started outside of this element must not end in this element. If the user attempts to create such a selection, the UA must instead end the selection range at the element boundary.
- ~UAは、選択が この要素を挟むように拡張することを許容し~MUST。 そのような選択には、要素の内容も含め~MUST。 ◎ The UA must allow selections to extend across this element, and such selections must include the content of the element.
- 注記: これを書いている時点では,試験的~実装の挙動は、[ 外側から開始された選択, 要素の中へ行く選択 ]について互いに異なる。 この挙動は、 `contain$v を明示的に~supportしない~browserにすら[ `textarea$e / `contenteditable$a ]要素の中へ選択しようと試行することにより観測できる。 ◎ Note: At the time of writing, experimental implementations behave differently from eachother about selections started outside and selections going into the element. The behavior can be observed even on browsers that do not explicitly support contain by trying to select into a textarea or a contenteditable element.
- 注記: これは、当初は Internet Explorer における試験的な特色機能として, `user-select$p に対する値 `element^v の下で導入された。 ◎ Note: This was initially introduced as an experimental feature in Internet Explorer, under the name user-select: element.
- `all@v
- 要素の内容は、不可分的に選択され~MUST。 選択が要素の一部を包含することになる場合、選択は,要素~全体を — そのすべての子孫も含め — 包含し~MUST。 要素の親の `user-select$p の算出値も `all$v の場合、要素が選択されたときには,親も再帰的に選択に含まれ~MUST。 ◎ The content of the element must be selected atomically: If a selection would contain part of the element, then the selection must contain the entire element including all its descendants. If the element is selected and the computed value of user-select on its parent is all, then the parent must be included in the selection, recursively.
- この要素の子孫に `user-select$p の算出値が `all$v でないものがあって,選択~全体が そのような子孫たちに包含されている場合、[ 選択が この要素~一体を含むように拡張する ]ことはないとする。 ◎ If this element has descendants on which the computed value of user-select is not all and if a selection is entirely contained in these descendants, then the selection is not extended to include this whole element.
注記: 選択は、~textのみならず,[ 画像, ~table, 動画, 等々 ]まで拡張して,それらを含み得る。 そのような選択を[ ~copyする/~pasteする ]ときの挙動は、この仕様の視野~外である。 ◎ Note: Selections can include more than just text and extend over images, tables, videos, etc. The behavior when copying and pasting a such selections is out of scope for this specification.
~HTML用には、次の~UA~stylesheetが追加される: ◎ The following additions are made to the UA stylesheet for HTML:
button, meter, progress, select { user-select: none; }
上の~listは不完全であり、少なくとも `input$e の各種~button類は含める必要がある。 ◎ the list above is incomplete, and needs to include at least the various button-like variants of input.
旧来の内容との互換性を得るため、 `user-select$p を~supportする~UAは, `-webkit-user-select^p も別名として~supportし~MUST。 ◎ For compatibility with legacy content, UAs that support user-select must also support -webkit-user-select as an alias.
注記: 別名にする仕組みの詳細は、意図的に~UAに委ねられる。 `-webkit-user-select^p を `user-select$p の略式~propにすることは,有効な~approachとして既知であり、新たな実装者は それを考慮するべきである。 しかしながら、互換性に反する帰結なしに,他の手段を通して `-webkit-user-select^p を `user-select$p の別名として~supportしている~UAも存在するので、この仕様は,そのような柔軟性を許容する。 ◎ Note: The details of the aliasing aliasing mechanism is intentionally left up to the UA. Making -webkit-user-select a shorthand property of user-select is known to be an effective approach, and new implementers should consider it. However UAs supporting -webkit-user-select as an alias of user-select through other means exist, without adverse consequences to compatibility, so this specification allows flexibility.
7. ~form~controlの~style法
7.1. 外観の切り替え法
これ【 `appearance$p ~prop】は、まだ出荷するに準備済みでない。 ( Github issue 1250 を見よ)。 ◎ This is not ready for shipping (see Github issue 1250).
これは、ほとんどの~browserにおいて,以前まで接頭辞~付きの形として存在していた。 標準~化の前までは、アリな値は, `none^v に加えて[ 要素の見かけを与え得るすべての仕方からなる,とても長い~list ]であった。 この~listは、~browser間にわたり異なっていた。 ◎ This previously existed as a prefixed form in most browsers. Before standardization, in addition to none, the possible values were a very long list of all the ways an element could look; this list was different across browsers.
これを標準~化するのはアリでないと結論された — その~~理由の一つとして、~form要素をどう構築するかは各~browserごとに異なり,多くの値は 他の~browserが備えていない疑似要素に適用されることが挙げられる。 ◎ We concluded this was impossible to standardize, in part because many apply to pseudo-elements that other browsers don’t have, as they construct form elements differently.
ここでは代わりに、値 `auto^v, `none^v だけ備えることにする。 `auto^v は、~form~controlは,何であれ それに必要な見かけになる様にする。 `none^v は、 “~nativeな” 見かけを抑止する。 ◎ Instead, we’d just have an "auto" value that makes form controls look like whatever they need, and a "none" value that suppresses "native" look.
しかしながら,次のような利用などに因り,これが非~web互換になり得る根拠がある: ◎ However, there is evidence that this may not be web compatible, due in part to uses such as:
input { appearance: none; } input[type=checkbox] { appearance: checkbox; }
そのような~codeは、この~propの~vendor接頭辞~付き変種のみに制限されることもあるが,常にではない — 作者は、将来の動作保証に備えて,接頭辞なし~versionも含ませることが多いので。 ◎ Such code is sometimes limited to the vendor-prefixed variant of this property, but not always, as authors often include the prefixless version for the sake of future proofing
素朴に[ `appearance$p / `-webkit-appearance^p ]を別名~化しても、挙動が相当に異なることに因り,働かないと見込まれる。 ◎ Due to substantially different behavior, naïve aliasing of appearance and of -webkit-appearance is unlikely to work.
先へ進む道として、次が挙げられる: ◎ Possible ways forward include:
- 互換性の問題がさほど深刻でなければ、設計をあるがままにする。 ◎ Keep the design as is, if the compatibility problem is not that serious
- 現在の設計を保った上で、 `none$v, `auto$v の他に一握りの値を追加する。 この~propの設計は、 `auto$v 値がある限り 他の値を予め排することはないので,網羅的になる必要はない。 ◎ Keep the current design, and add a handful of values other than none and auto. The design of this property does not preclude having other values. As long as we have the auto value, there is no need to be exhaustive.
- 現在の設計を保つが、他の値も受容して(場合によっては、~whitelistとして, あるいは何でも受容するような),それらを `auto$v と同じに挙動させる。 上に例示したように, `none$v, `auto$v 以外の値の共通的な利用は、[ 要素の外観を何か他に切替える ]ことも, [ ~nativeな見かけを備えないものにそれを与える ]こともなく,それまでに適用されていた `none$v を元に戻すだけある。 `auto$v 値は,非~標準の~versionには存在しないので、この目的に特定の値を利用していた作者がいても, `auto$v の挙動で足るであろう。 ◎ Keep the current design, but also accept other values (possibly white-listed, possibly accept anything) and let them behave the same as auto. As demonstrated in the example above, common uses of values other than none and auto are not to switch an element’s appearance into something else, nor to give a native look to something that didn’t have one, but merely to undo a previously applied none. Since auto did not exist in the non standard version, authors have been using specific values for this purpose, but the behavior of auto would be sufficient.
- 前 2 項の選択肢を組合わす — 特有の挙動を伴う一握りの明示的な値を追加しつつ, `auto$v と同じに挙動する他の値も受容する。 ◎ Combine the previous two options, adding a handful of explicit values with specific behaviors, and also accept any other value letting them behave the same as auto.
- 現在の設計を放棄して、代わりに `-webkit-appearance^p の挙動を指定する — `auto$v 値を無くす代わりに,すべての組み合わせを伴わせて。 これはおそらく、少数の疑似要素も指定することが要求される — `-webkit-appearance^p ~prop用の種々の値は、~form~controlを成す下位~componentを~styleするために利用されているので。 ◎ Abandon the current design, and specify instead the behavior of -webkit-appearance, without an auto value and with all the permutations instead. This probably requires specifying a few pseudo-elements as well, as various values of the -webkit-appearance property are used to style sub-components of form controls.
Microsoft の経験に基づけば、この~listの 3 番目の選択肢で足りそうに見受けられる。 これは、仕様と実装の労力~面で相応に安くつくであろう。 ◎ Based on Microsoft’s experience, it seems that the 3rd option in this list may be sufficient. This would be fairly cheap in terms of specification and implementation effort.
2 番目の選択肢は,いくぶん高くつくが適度にそうである一方で、 5 番目の選択肢は,有意に高くつく。 ◎ Option 2 is somewhat more costly but reasonably so, while option 5 is significantly more costly.
互換性~問題の~~範囲と資質について、実装者からの~feedbackがもっと必要である — それに取組むには、どの選択肢が必要十分であり得るかについても。 ◎ More feedback from implementors is needed about the extent and nature of the compatibility problem, and about which option may adequately address it.
文書~内のほとんどの要素に対しては、その見かけは~CSSにより全部的に制御できる。 一方で,~form~controlは、概して,~host~OSの~native~UI~controlを用いて~UAにより具現化される — それは、~CSSを利用して再現できないし, ~styleできない。 ◎ While the way most elements in a document look can be fully controlled by CSS, form controls are typically rendered by UAs using native UI controls of the host operating system, which can neither be replicated nor styled using CSS.
この仕様は、 `appearance$p ~propを導入して,この挙動にいくらかの制御を供する。 この~propに値 `none^v を利用すれば、作者は,~form~control用の~native~styleを抑止した上で、~CSSを用いてそれを全部的に~styleし直せるようになる。 ◎ This specification introduces the appearance property to provide some control over this behavior. Using appearance: none allows authors to suppress the native style of form controls, so that CSS can be used to fully restyle them.
◎名 `appearance@p ◎値 `auto$v | `none$v ◎初 `auto$v ◎適 すべての要素 ◎継 されない ◎百 受容しない ◎算 指定値 ◎順 文法に従う ◎ア 離散的 ◎表終定例の要素~上の `auto$v は、 `none$v に算出されるべきか? 編集者は、それには~~否定的である。 そうすることにした場合,整合性をとるためには、新たな値を導入するたびに 一部の要素~上で `auto$v が何に算出されるかも変更することになり,望ましいとは思えない。 ◎ Should auto compute to none on regular elements? I would say no: If we did that, to be consistent, every time we introduced a new value, we would change what auto computes to on some elements, which doesn’t sounds desirable.
注記: この仕様は、[ この~prop用の早期の提案 / いくつかの~UA~vendorによる試験的な実装 ]にて以前に試みられたような,[ 可用な[ ~form~control, 下位~control ]にアリなすべての外観を,一連の値として~~定める ]ことは、意図的に控える。 そのような~listは、とても長くなり,保守するのは実用的でないことが経験から示されている。 加えて、~form~controlを実装する際には 非~標準の疑似要素が利用されることもあり,~UAは その挙動を織り込むために非~標準の値を追加する必要もある。 さらには,そのような列挙を成す値の多くは、単独の[ 要素/疑似要素 ]に限り~~意味を成し,~UA~stylesheetの外側では決して利用されない。 代わりに,この仕様は、 `auto$v, `none$v のみを供する。 したがって,~UAは、~UA~stylesheet内では,各~controlの~nativeな見かけと感触を与えるためとして, `appearance$p ~propを利用できない — 代わりに `appearance$p に `auto$v を利用し~MUST。 ◎ Note: This specification intentionally refrains from making the appearance of all possible form controls and sub-controls available as values, as had previously been attempted by earlier proposals for this property and by several UA vendors in experimental implementations. Experience has shown that such a list would be very long and not practical to maintain, and UAs would need to add non-standard values to account for the behavior of non-standard pseudo-elements sometimes used to implement form controls. Moreover, many values of such an enumeration only make sense on a single element or pseudo-element, and are never used outside of the UA stylesheet. Instead, this specification only provides auto, none. UAs cannot therefore use the appearance property in the UA stylesheet to give each control its native look and feel, and must use appearance: auto instead.
文書~内の一定の要素に~native~form~controlの様な見かけと挙動を欲している作者は、文書の~markup言語において,正しい要素を利用するべきである — この~propや その試験的~変種を利用しようと試みるのではなく。 ◎ Authors desiring to make certain elements in their document look and behave like native form controls should use the correct element in the markup language of the document rather than attempt to use this property or its experimental variants.
この仕様の将来~versionは、共通的に欲される外観~用に,少数の値をさらに追加し得る — 試験的な実装~用に書かれた内容に互換性の問題があることが立証されたならば。 これまでの所、これに該当する事例は無いことが経験により指示されている。 これが起きたとしても、~propが[ アリなすべての~controlとその下位~controlを受持つ ]までに成長することは,~~期待されていない。 ◎ Future version of this specification may add a few more values for commonly desired appearances if compability with content written for experimental implementations proves problematic. So far, experience indicates that this is not the case. Even if this were to happen, it is not anticipated that the property would grow to cover all possible controls and sub-controls.
- `auto@v
- ~UAは、~form~controlを[ ~host~OSの~native~controlを利用して / ~CSSでは表せない見かけと感触で ]具現化して~MAY。 ◎ UAs may render form controls using native controls of the host operating system or with a look and feel not otherwise expressible in CSS.
- ~form~control以外の要素は、 `none$v が指定されていたかのように具現化され~MUST。 ◎ Elements other than form controls must be rendered as if none had been specified.
- `none@v
- 要素は、~CSSの通例の規則に従って具現化される。 ~form~control以外の置換~要素は、これにより影響されず,置換~要素であり続ける。 ~form~controlは、~host~OSの~native~controlの様な見かけには されない。 詳細は下を見よ。 ◎ The element is rendered following the usual rules of CSS. Replaced elements other than form controls are not affected by this, and remain replaced elements. Form controls are not made to look like native controls of the host operating system. See below for details.
- この名前は "`normal^v" にするべきでは? `none$v では、要素が現れなくなる様な~~印象を受ける。 ◎ Shouldn’t this be called "normal" instead? none makes it sound like the targeted element will disappear.
~form~control要素~上で算出値が `auto$v になる所では、~UAは,一部の~CSS~propを無視rして~MAY — 意図される外観が保全されるのを確保するために, あるいは 当の~propは選ばれた外観に有意義でなくなり得るならば。 しかしながら、次に挙げる~propは,無視rしては~MUST_NOT: ◎ On form control elements where the computed value is auto UAs may disregard some CSS properties to ensure that the intended appearance is preserved, or because these properties may not be meaningful for the chosen appearance. However, the following properties must not be disregarded:
- `appearance$p
- `display$p
- `visibility$p
- `position$p
- `top$p
- `right$p
- `bottom$p
- `left$p
- `float$p
- `clear$p
- `margin$p とそれに関係する下位~prop ◎ margin and related long-hand properties
- `unicode-bidi$p
- `direction$p
- `all$p — これは、 `all^p を適用してすべての~propを再設定する要件は,含意しない。 ◎ all This does not imply a requirement to apply all the properties reset by all
- `cursor$p
- `z-index$p
この~listに含めるべき~propは他にあるか? ~listから除去するべきものはあるか? 無視してよい~propの~whitelistを与えるべきか? — そうでないものの~blacklistに代えて。 どちらの仕方でも、~UAは,~form~controlを具現化するときに 一部の~propを無視するので、この仕様は,これについて何か言う必要がある。 ◎ Are there more properties should include in this list? Should we remove some? Should whitelist the properties that are ok to ignore instead of blacklisting those that are not? Either way, UAs do ignore some properties when rendering form controls, so this specification needs to say something about this.
~form~controlの装飾的な視覚的~側面を成すもののうち,~CSS~style規則によるものでないすべては、 `appearance$p を用いて外観が変更されたときには,抑止され~MUST — この要素~用の~UAの内部~表現が、複数の 要素や疑似要素 を一緒に組合わすように組成されていたとしても。 例えば `select$e は、右端~側に[ 要素が~clickされたとき~listは展開されることを指示する,矢印 ]で描画されることが多い。 `appearance$p の算出値が `none$v になる場合、これは現れなくし~MUST。 ◎ All decorative visual aspects of a form control which are not caused by a CSS style rule must be suppressed when the appearance is changed using appearance, even if the UA’s internal representation for this element was composed of multiple elements or pseudo elements combined together. For example, select is often rendered with an arrow on the right side indicating that the list will be expanded if the element is clicked. If the computed value of appearance is none, this must disappear.
しかしながら,~UAは、~form~controlの側面のうち[ その元の意味論の下で,~controlを操作oするために必要とされるもの ]は,保全し~MUST。 これに含まれるのは、~controlの側面のうち,単に~controlの状態を観測するために必要なものを除く、利用者が~controlの状態を改変-可能にするために必要なものに限られる。 しかしながら,~UAは、~controlを操作oでき続ける限り,異なる見かけと感触を与えても~MAY。 例えば, `<input type=range>^c の~sliderは、 `appearance$p は `none$v であっても保全される(または、等価な仕組みに置換される) — さもないと,この範囲~controlの値を~mouseや~touchscreenで変更できなくなるので。 他方、 `<input type=checkbox checked>^c の~check-markは抑止され~MUST — それは 要素の状態を指示するだけであり、 `checked$ps 選択子を利用して異なる仕方で~styleできるので。 ◎ However, the UA must preserve aspects of the form control which are necessary to operate the control with its original semantics. This does not include aspects of a control which are merely needed to observe the state the control is in, only those that are needed for the user to be able to modify the state of the control. The UA may however give them a different look and feel as long as it remains possible to operate the control. For example, the slider of an <input type=range> is preserved (or replaced by an equivalent mechanism) even if appearance is none as it would otherwise not be possible to change the value of the range with the mouse or touchscreen. On the other hand, the check mark in an <input type=checkbox checked> must be suppressed, as it merely indicates the state the element is in, which can be styled in different ways using the :checked selector.
~UAたちは、直前の 2 つの段落について一貫していない。 ここに指定したものは、 `appearance$p の利用事例に基づいて,何が保全され, 何が保全されないかについての論理を与えようと試みる。 ◎ UAs are inconsistent about the preceding two paragraphs. What is specified here attempts to give some logic to what is preserved and what is not, based on the use-cases for appearance.
~UAは、自身の~UA~stylesheetに,[ `appearance$p が `none$v でないときに,~form~controlに認識-可能な形状を与える ]ための~style規則を含めるべきである。 ◎ UAs should include in their User Agent stylesheet style rules to give form controls a recognizable shape when appearance is none.
注記: したがって,作者は、自身が意図する~style付けを得るためには — 場合によっては, `all$p に `unset^v を用いて — これらの~UA~style規則を上書きする必要があるかもしれない。 ◎ Note: Authors may therefore need to override these UA style rules to get the styling they intended, possibly by using all: unset.
`all$p ~propのこの用法は、 `outline$p ~propにより作成される~focus指示子を除去することになり,望ましくないように見受けられる。 `all$p に `revert^v を用いても,意図されるように~UA~styleを除去するのに失敗するので、それは解消されない — どうやってこれを軽減する? ◎ This usage of the all property would remove focus indicators created by the outline property, which seems undesirable. Using all: revert would not solve it, as it would fail to remove the UA styles as intended. How can we mitigate this?
この~propは、~host言語が定義する要素の挙動と意味論には波及しない。 例えば、 `appearance$p の算出値に関わらず: ◎ The behavior and semantics of elements remain defined by the host language, and are not influenced by this property. For example, regardless of the computed value of appearance:
- 複数の状態をとり得る要素は、その能を保ち,関連する疑似類は通例通り合致する。 ◎ Elements which can be in different states keep this ability, and the relevant pseudo-classes match as usual.
- `select$e 要素が作動化された場合、それに結付けられている `option$e 要素の一つを選ぶための~UIが示される(その見かけは異なり得るが)。 ◎ If a select element is activated, the UI to choose one of the associated option elements is shown (although it may look different).
- 要素に添付されている~event~handlerは、通例通り誘発される。 ◎ Event handlers attached to the element trigger as usual.
反対に,要素の外観を変更することは、それが当初は備えていなかった[ 新たな意味論, 疑似類, ~event~handler, 等々 ]を獲得しては~MUST_NOT。 `appearance$p ~propは、要素が~focusされる能も変更しない。 ◎ Conversely, changing the appearance of an element must not cause it to acquire new semantics, pseudo classes, event handlers, etc that it did not initially have. The ability for an element to be focused is also not changed by the appearance property.
作者は、~HTMLにおける~check-boxの見かけと感触を~custom化しようと求めるならば,次を利用することもできる: ◎ An author wanting to customize the look and feel of check boxes in HTML could use the following:
input[type=checkbox] { appearance: none; all: unset; width: 1em; height: 1em; display: inline-block; background: red; } input[type=checkbox]:checked { border-radius: 50%; background: green; }
`<input type="checkbox">^c は、 として描画されることになる一方で、 `<input type="checkbox" checked>^c は として描画され、要素を(例えば~clickして)作動化すれば,状態を通例通り切替することになる。 ◎ <input type="checkbox"> would be rendered as , while <input type="checkbox" checked> would be rendered as , and activating (for example by clicking) the element would toggle the state as usual.
7.2. ~form~controlに特有の規則
7.2.1. 単行~text入力~control
単行~text入力~control — `HTML$r の `<input type=text>^c など — は、 `appearance$p が `auto$v のときには,次のように描画され~MUST: ◎ When appearance is auto, single-line text input controls such as [HTML] <input type=text> must be rendered so that:
- 行内~方向においては、内容を`内容~辺$で切取る。 ◎ The content is clipped in the inline direction to the content edge
- 塊~方向においては、内容を`~padding辺$で切取る。 ◎ The content is clipped in the block direction to the padding edge
- 内容は、縦方向において中央寄せにする。 ◎ The content is vertically centered
- 内容は折返さない。 ◎ The content does not wrap
- `text-overflow$p ~propは、`overflow$p ~propの値に関わらず適用する。 ◎ The text-overflow property applies regardless of the value of the overflow property
付録 A. 謝辞
~INFORMATIVEこの仕様は `CSS-UI-3$r の上に築かれている。 その仕様のほとんどの部分は、1999 年から~~現在に至るまで, Tantek Çelik 氏により編集され, 書かれた。 氏は、最初は Microsoft から, 次は Invited Expert として, ~~最近は Mozilla から参加されている。 ◎ This specification builds upon [CSS-UI-3], which was edited and written for the most part by Tantek Çelik from 1999 to the present, first while representing Microsoft, then as an Invited Expert, and most recently while representing Mozilla.
次の方々からの~feedback/協力に:
Thanks to feedback and contributions from Rossen Atanassov, Tab Atkins, L. David Baron, Bert Bos, Matthew Brealey, Rick Byers, Ada Chan, James Craig, Michael Cooper, Axel Dahmen, Michael Day, Micah Dubinko, Elika E., Steve Falkenburg, Andrew Fedoniouk, Al Gilman, Ian Hickson, Bjoern Hoehrmann, Alan Hogan, David Hyatt, Richard Ishida, Sho Kuwamoto, Yves Lafon, Stuart Langridge, Susan Lesch, Peter Linss, Kang-Hao Lu, Masayuki Nakano, Mats Palmgren, Brad Pettit, Chris Rebert, François Remy, Andrey Rybka, Simon Sapin, Alexander Savenkov, Sebastian Schnitzenbaumer, Lea Verou, Etan Wexler, David Woolley, Frank Yan, Boris Zbarsky, and Domel.
付録 B. 変更点
~INFORMATIVE2017 年 12 月 22 日 初公開~作業草案 からの変更点: ◎ Changes from the 22 December 2017 Working Draft
- ~form~controlに特有の描画~規則についての詳細を追加した。 ◎ Added details about form control specific rendering rules
- `text-overflow$p と匿名~塊~容器との相互作用を明確化した。 ◎ Clarify interaction between text-overflow and annonymous block containers
- すべての文書~形式において,~hyperlink用の `cursor$p は `pointer^v にすることを要求した。 ◎ Require the pointer cursor for hyperlinks in all document formats
- `box-sizing$p ~propを `CSS-SIZING-3$r に, `text-overflow$p ~propを `CSS-OVERFLOW-4$r に移動した。 ◎ Moved the box-sizing and text-overflow properties to [CSS-SIZING-3] and [CSS-OVERFLOW-4] respectively.
2015 年 9 月 22 日 初公開~作業草案 からの変更点: ◎ Changes from the 22 Sep 2015 First Public Working Draft
- `caret-animation^p ~propは、除去された。 根拠に足る利用-事例があれば、再~導入され得る。 ◎ The caret-animation property have been removed. It may be reintroduced later given sufficient evidence for use cases.
- `resize^p ~propは、今や 画像や動画を表現している`置換~要素$, および `iframe$e にも適用される。 ◎ The resize property now also applies to replaced elements representing images or videos, and to iframes.
- `text-overflow$p ~propに対する[ 文字列~値, 2 成分~値 ]は、~level 3 からこの仕様に移動された。 ◎ The string values and dual values of the text-overflow property were moved to this specification from level 3.
- 方向的~focus~navi~propを~level 3 から~level 4 へ移動した ◎ Move directional focus navigation properties from level 3 to level 4
- 今や安定的になった `CSS-UI-3$r からの内容が併合された。 ◎ Content from the now stable [CSS-UI-3] has been merged in.
付録 C. security / privacy 上の考慮点
~INFORMATIVEW3C TAG は、仕様の編集者向けに security/privacy に関する自己評価 質問票 を開発中にある… 【以下、この節の内容は未訳。他サイトによる訳】 ◎ The W3C TAG is developing a Self-Review Questionnaire: Security and Privacy for editors of specifications to informatively answer.
付録 D. ~HTML用の既定の~stylesheetに対する追加
~INFORMATIVE~HTMLの~form~control, および 少数の動的な呈示~属性を表すためとして,基底~stylesheetにあり得る追加: ◎ Potential additions to the base style sheet to express HTML form controls, and a few dynamic presentation attributes:
:enabled:focus { outline: 2px inset; } button, input[type=button], input[type=reset], input[type=submit], input[type=checkbox], input[type=radio], textarea, input, input[type=text], input[type=password], input[type=image] { display: inline-block; } input[type=button], input[type=reset], input[type=submit], input[type=checkbox], input[type=radio], input, input[type=text], input[type=password], input[type=image] { white-space: nowrap; } button { /* `button^e ~tagの空白について特に取扱う ◎ white space handling of BUTTON tags in particular */ white-space:normal; } input[type=reset]:lang(en) { /* 言語に応じた,~HTML `input type=reset^e ~buttonに対する既定の内容 ◎ default content of HTML input type=reset button, per language */ content: "Reset"; } input[type=submit]:lang(en) { /* 言語に応じた,~HTML `input type=submit^e ~buttonに対する既定の内容 ◎ default content of HTML input type=submit button, per language */ content: "Submit"; } /* ~UAは、他のものに対しても,言語に特有の reset/submit 規則を利用するべきである。 ◎ UAs should use language-specific Reset/Submit rules for others. */ input[type=button], input[type=reset][value], input[type=submit][value] { /* ~HTML `input$e ~buttonの~text 内容/~label ◎ text content/labels of HTML "input" buttons */ content: attr(value); } textarea { /* `textarea$e ~tagの空白について特に取扱う ◎ white space handling of TEXTAREA tags in particular */ white-space:pre-wrap; resize: both; } input[type=hidden] { /* ~HTML `hidden$a ~text~fieldの外観について特に取扱う ◎ appearance of the HTML hidden text field in particular */ display: none !important; } input[type=image] { content: attr(src,url); border: none; } select[size] { /* size が 1 を超える~HTML `select$e ~listの外観 ◎ HTML4/XHTML1 <select> w/ size more than 1 - appearance of list */ display: inline-block; height: attr(size,em); } select,select[size=1] { /* size を伴わない, または `size=1^a の~HTML `select$e (~popup-menu) ◎ HTML4/XHTML1 <select> without size, or size=1 - popup-menu */ display: inline-block; height: 1em; overflow: hidden; } select[size]:active { /* size が 1 を超える active ~HTML `select$e — active list の外観 ◎ active HTML <select> w/ size more than 1 - appearance of active list */ display: inline-block; } optgroup, option { display: block; white-space: nowrap; } optgroup[label],option[label] { content: attr(label); } option[selected]::before { display: inline; content: check; } /* `frame^e を~resizeすることは、この仕様では直には取組まれていないが、次の規則は,適度な挙動に近いものを供するであろう。 ◎ Though FRAME resizing is not directly addressed by this specification, the following rules may provide an approximation of reasonable behavior. */ /* frame { resize:both } frame[noresize] { resize:none } */