[whatwg] CSSOM

Alpha component is equal to 1.
The color is an uppercase six-digit hexadecimal value, prefixed with a
# character
(U+0023 NUMBER SIGN), with the first two digits representing the red component,
the next two digits representing the green component, and the last two
digits representing the blue component,
the digits being in the range 0-9 A-F (U+0030 to U+0039 and U+0041 to U+0046).

---
I think I remember an earlier spec said that colors are returned in
RGB(0-0xFF,0-0xFF,0-0xFF) string format. Some implementations provide
an rgb value, others provide whatever was supplied in the sheet.
Others, such as Safari, are more complex.

Setting a value to have a keyword, using javascript:

rule.style.color = "lawngreen";
rule.style.color.indexOf( "rgb" ) != -1; // true, safari just
converted it to an RGB string.

I cound not find mention of color keywords. For example: red.

having RGB value is more useful, otherwise you have to have a whole
table in js to convert "red" to "#FF0000". Painful.

Consider reading a color value of an element. If the color is 0xFF0000,
I expect an rgb value.

getComputedStyle(el, "").getPropertyValue("color"); // => returns
"rgb(255, 0, 0)"

Given one stylesheet with one rule, matching that same element

#el {
  color: red;
}

document.styleSheets[0].cssRules[0].style.color// => "red" or "rgb(255, 0, 0)" ?

It would be useful to get the computed style from the property; the
other value, "red", is available in the cssText.

Should getting a property return the computed value? I think it
should. I think the cssText should contain the rules
given cssText, though, not computed cssText.
I would not mind having a method to get the given value, such as
CSSRule.getProperty(...), but would probably not use it.


Whitespace:
If whitespace may be removed without changing the meaning of the value
it is to be removed.
---
Why?

A single space should be added after each comma that is not part of a string,
except where that would change the meaning of the value. For example:
---
Why does this matter?



The deleteRule(index) method, when invoked, must remove a statement
where index is index and rule list is cssRules.


---
ADD: Upon deletion, the view should be updated, reflecting the removal
of the rule, even if the rule is an @import rule.

---

The document does not mention that selector text is case-sensitive and
should not be case-converted. Although this
seems obvious to me, to Microsoft, it does not. IE converts element
selectors to upper case, probably
to deal with IE's HTML parser.


Regarding the design of the API, I have found:
1) no good way to get all the CSSStyleRules of a styleSheet.
2) no good way to find a CSSStyleRule by selectorText.

Finding a CSSStyleRule by it's selectorText is painful. It requires a
lengthy search to first loop
through the rules, then split the selector text on ",", then do a
RegExp on each selector text.
It should be necessary (using the standard API), to loop again through
the media rules. This is painful.

It would be more convenient to me to have a styleSheet method for
this. It's not terrible, but it is
a little painful. Here is js code, which does not return a list, and
does not even consider rules that may be
nested inside @media rules (too much work).


	/** IE will not return the correct selector text for Element
selectors in HTML.
	 * Instead, IE puts the element selector and pseudoclass selectors in
upper case.
	 *
	 * Media rules are not queried.
	 * This function compares selectors, case sensitive, but
	 * case insensitive for element selector parts.
	 * @return CSSStyleRule the first rule that matches the selector text.
	 */

	getRuleBySelectorText : function(selectorText) {
		var tuc = APE.StyleSheetAdapter._tagNamesToUpperCase;

		// Convert local selectorText to have upper-case element selectors.
		selectorText = tuc(selectorText);
		var cssRuleList = this.sheet.cssRules || this.sheet.rules;

		// Loop through the cssRuleList.
		for(var i = 0, iLen = cssRuleList.length; i < iLen; i++) {

			// Check each rule's selectorText to see if it matches the one provided.
			// Since a rule can have multiple selectors, separated by ",",
			// we split on "," (with optional whitespace) and return the rule for any
			// matching selector text.
			var selectorTextMatches = cssRuleList[i].selectorText.split(/\s*,\s*/);

			for(var j = 0; j < selectorTextMatches.length; j++) {
				if(tuc(selectorTextMatches[j]) == selectorText)
					return cssRuleList[i];
			}
		}
		return null;
	},


/**
 * Converts the tag names of selector text to upper case.
 * This is used internally for matching/comparison of selector text.
 * Internet Explorer converts all
 * HTML Element selectors to upper case. It is a bad design decision
by the IE team.
 * @private
 */
APE.StyleSheetAdapter._tagNamesToUpperCase = function(s) {
	// Element Selector = Start of string or ws, followed by one or more
letter chars.
	var elementSelector = /(^|\s)([a-z]+)/;
	var matches = s.match( elementSelector ), R = RegExp;
	while( elementSelector.test(s) ) s = s.replace(elementSelector,
R.$1+R.$2.toUpperCase());
	return s;
};

I would prefer this to be native code.

/ **
  * @param {String} media media blocks to search in.
  * if media is null or "", then does not look in nested media blocks.
  * @return {CSSRuleList} list of matching rules, empty if no matches found.
  */
interface CSSStyleSheet : StyleSheet {
  CSSRuleList getRulesBySelectorText(in DOMString SelectorText, in
DOMString media);
}

Not a lot of people use CSSOM and I think it's mostly because of poor
browser support. But the spec has changed contradictorily. Only
Mozilla had good support a long time. IE is still very non-standard.
Safari is only recently supporting this. The other reason it is not
used much is that the API is not as convenient to use. So you have an
API that is not very convenient, coupled with poor browser support.
What you get is people writing there own query engines
(getElementsBySelectorText)/

The other approach is to let the browser do the cascade and modify the
stylesheet rules, like Webkit's CSS Transitions.
Using javascript to implement CSS transitions can provide a fallback
as other browsers catch up to webkit.
It has different implications, and is doesn't let you get the actual
elements, but it is perfectly valid approach; in fact it's more
appropriate in some cases.

I have also found want for:
1) element.getCascadedStyle
2) element.getImplementedRules

However, at this point, I think fixing API features would take
precedence over adding new API features. Ian seems to think CSSOM
should be abandoned.

Received on Monday, 28 January 2008 19:03:27 UTC