We need more smart and usable solution.
We need more smart and usable solution. (Yes, I've repeated this twice.)
The solution is a dedicated API to read raw values of CSS-properties. The API could consist of two methods:
// Returns all CSS-properties as name-value pairs:
// Returns specified CSS-properties only:
// Returns value of single specified CSS-property:
The element.getStyles() method could return an associative-array-like object. For example, if we have CSS:
some-property: some value;
another-property: another value;
var styles = document.getElementById('example').getStyles();
// The 'styles' variable now contain two name-value pairs:
// styles['some-property'] === "some value"
// styles['another-property'] === "another value"
element.getStyle('some-property') could return value of single specified property:
var style = document.getElementById('example').getStyle('some-property');
// The 'style' variable now contain string "some value".
Once we've got value of the property, all we need is to parse just this individual value.
Needless to say, parsing an individual value is incomparably more easy and feasible than parsing full stylesheet from scratch.
For browsers, this could be quite easy to implement the API since they _do_ read all CSS-properties (including unsupported ones), but just _skips_ unsupported ones. For API to be implemented, it's probably enough to just expose such skipped properties via the API described above.
The API you propose can't be implemented without the API user providing a good bit more detail about how the property works. For more information, see:
(In reply to comment #1)
Thank you for valuable comment, David.
The API I've proposed is a _minimal_ API _enough_ to get value of an unsupported property.
Such minimal/enough API is _much, much_ better then current situation when we have no access to unsupported properties _at all_ and are forced to parse stylesheets entirely from scratch.
As far as I understand CSS-parsing mechanism, if we have following unsupported property declaration:
some-property: some value;
then entire string "some-property: some value;" is skipped by browser.
In this string, a browser can automatically treat string before first colon as property name, while treating rest part of the string (after colon) as its value.
Inheritance (when needed) could be calculated by JS-script itself by iteratively checking the property for all parents of the element -- from direct parent to root element of element's owner-document.
Feel free to supplement the API with additional features that would make accessing unsupported properties (as well as unsupported values of supported properties) even easier for web-developers.
Based on information available at your link, we could add 'inherit' boolean parameter to getStyle() method:
// Second parameter specifies whether property should be inherited (false by default):
(Actually, it's enough to be able to read individual properties via only getStyle() method to achieve subject goal. getStyles() method is optional compared with getStyle().)
As for "parse + compute function", I'm not sure it's reasonable enough to use them in _client_ scripts (as opposed to internal browser's chrome scripts). Appropriate parts of parsing script could be called later in script -- when raw value is already obtained. There is no big need to do these actions in exactly one step.
Out of scope for HTML.
How about only exposing unknown properties as specified style, not letting them take part in computed style or inherit or anything? This would mean that variables don't work, though.