You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p><em>Any</em> property name starting with the prefix "data-" is a <i>data property</i>. Data properties are defined to be valid but meaningless as they are meant solely for allowing authors to pass custom data around their page, similar to the <ahref="http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes">custom data attributes</a> in HTML. Other specifications and user agents must not assign a particular meaning to data properties or attach a specific effect to them beyond the bare minimum that comes from them being valid properties.</p>
119
121
120
-
<pclass='issue'>I'm using data-foo for their rough parallel (in terms of being completely user-extensible) with the data-* attributes in HTML. Might another name be better? Suggestions so far are "var-foo", "$foo", and "var(foo)" (the latter two are intended to directly resemble the usage of the variable). Obviously, usage of the variable should match, as "var(foo)" or "$foo" or whatever.</p>
122
+
<pclass='issue'>The naming here is loosely based on the form of custom data attributes in HTML5. However, as defined here, the syntax for variable usage is different from the syntax for variable definition (i.e. data-foo for definition, data(foo) for usage). Some have suggested that the syntaxes should should match, using functional syntax in both cases. Others have suggested using a prefixed symbol instead of functional syntax (e.g. $foo) for both the property and usage.</p>
121
123
122
124
<p>The valid possible values of a data property are almost completely unrestricted. A data property can contain anything that is valid according to the <code>value</code> production in the <ahref="http://www.w3.org/TR/CSS2/syndata.html#tokenization">CSS Core Grammar</a>. The values do not have to correspond to any existing CSS values, as they are not evaluated except to replace variables occuring within them until they are actually referenced in a normal property with a variable.</p>
123
125
@@ -309,7 +311,7 @@ <h3 id='cssom-cssvariable'>
309
311
<h3id='cssstyledeclaration-interface'>
310
312
Additions to the <code>CSSStyleDeclaration</code> Interface</h3>
311
313
312
-
<pclass='issue'>The set of data properties is open-ended, so I'm not sure how best to represent this. I'd like to both expose the current set of properties with a non-initial value and allow setting of arbitrary properties. The most natural way seems to be to first, set up a getter behavior on the interface somehow that deals with data properties, and second, set up a <code>data</code> map that exposes the data properties that aren't set to their initial value.</p>
314
+
<pclass='issue'>The set of data properties is open-ended, so it's not clear how best to represent this. Ideally, the CSSOM would expose the current set of properties with a non-initial value and allow setting of arbitrary properties. The most natural way seems to be to first, set up a getter behavior on the interface somehow that deals with data properties, and second, set up a <code>data</code> map that exposes the data properties that aren't set to their initial value.</p>
<td><pclass=proposal>Change to “must not” or “is illegal”
256
+
257
+
<trclass=incomplete>
258
+
<tdid=x25><ahref="#x25">25</a>
259
+
<td>Lev Solntsev
260
+
<td><p>Allow colors (esp. semi-transparent ones) on all background layers. Tab says (1st response) it's no longer needed, because you can soon use 'image(red)' anywhere a URL is allowed, and (2nd response) that it would throw off the layer counting for the 'background-color' property.
0 commit comments