I made a simple Javascript routine that reports all the style properties present in a browser.
var list = new Array();
var div = document.createElement('div');
for (var style in div.style)
list.push(style);
And it works. The results are in JavaScript format, so for instance borderTopLeftRadius means the CSS property border-top-left-radius, MozAnimationTimingFunction means -moz-animation-timing-function and so on.
Here is a fiddle where you can see it live.
(The list is flawed, by the way. For instance, in Firefox and IE, the list doesn't even contain float, but it does in Chrome. Firefox and IE have cssFloat. Oh well, I can live with that.)
So far, so good.
However, my goal is to have only a list of CSS property names. But the results also include entries that are not property names at all, like getPropertyPriority and length. And my question is, how can I filter these out? How to differentiate between these entries (some are Javascript functions, some are read-only properties) and the actual CSS property names?
Edit:
I don't mind about the properties that apply to SVG only; it's OK to keep those.
Also, while most of the offending ones can be filtered out by checking if the property has type 'string' as Mr_Green pointed out (see updated fiddle), there are still some entries in the list that are not CSS property names, such as cssText and marks (the latter only in some browsers). I want to filter those out as well, but haven't found a way to do so.
The W3C mentions a function called supports() but I haven't been able to make that work. Can anybody find me an example?
I don't know if your goal is to check whether a property is supported or not but
function isPropertySupported(property)
{
return property in document.body.style;
}
can check whether a property is supported or not. I hope it helps. Correct me if I am wrong.
Check whether a CSS property is supported or not
EDIT:
Check this out CSS Supports
supports(DOMString property, DOMString value), returns boolean
supports(DOMString conditionText), returns boolean
When the supports() method is invoked with two arguments property and value, it must return true if property is a literal match for the name of a CSS property that the UA supports, and value would be successfully parsed as a supported value for that property. (Literal match means that no CSS escape processing is performed, and leading and trailing whitespace are not stripped, so any leading whitespace, trailing whitespace, or CSS escapes equivalent to the name of a property would cause the method to return false.) Otherwise, it must return false.
Related
I am using this script to make a style object of all the inherited, etc. styles.
var style = css($(this));
alert (style.width);
alert (style.text-align);
With the following, the first alert will work fine, but the second one doesn't... it's interpreting the - as a minus I assume. The debugger says 'uncaught reference error'. I can't put quotes around it, though, because it isn't a string. So how do I use this object property?
Look at the comments. You will see that for CSS properties, the key notation is not compatible with a number of properties. Using the camel case key notation therefore is the current way:
obj.style-attr // would become
obj["styleAttr"]
Use key notation rather than dot
style["text-align"]
All arrays in JavaScript are objects and all objects are just associative arrays. This means you can refer to a place in an object just as you would refer to a key in an array.
arr[0]
or the object
obj["method"] == obj.method
A couple things to remember when accessing properties this way:
they are evaluated so use strings unless you are doing something with a counter or using dynamic method names.
This means obj[method] would give you an undefined error while obj["method"] would not
You must use this notation if you are using characters that are not allowed in JavaScript variables.
This regex pretty much sums it up:
[a-zA-Z_$][0-9a-zA-Z_$]*
The answer to the original question is: place the property name in quotes and use array style indexing:
obj['property-with-hyphens'];
Several have pointed out that the property you are interested in is a CSS property. CSS properties that have hyphens are automatically converted to camel casing. In that case you must use the camel cased name like:
style.textAlign;
However this solution only works for CSS properties. For example,
obj['a-b'] = 2;
alert(obj.aB); // undefined
alert(obj['a-b']); // 2
CSS properties with a - are represented in camelCase in JavaScript objects. That would be:
alert( style.textAlign );
You could also use a bracket notation to use the string:
alert( style['text-align'] );
Property names may only contain characters, numbers, the well known $ sign and the _ (thanks to pimvdb).
Use brackets:
var notTheFlippingStyleObject = {
'a-b': 1
};
console.log(notTheFlippingStyleObject["a-b"] === 1); // true
More information on objects: MDN
NOTE: If you are accessing the style object, CSSStyleDeclaration, you must use camelCase to access it from JavaScript. More information is here.
alert(style.textAlign)
or
alert(style["textAlign"]);
To directly answer the question: style['text-align'] is how you would reference a property with a hyphen in it. But style.textAlign (or style['textAlign']) is what should be used in this case.
Hyphenated style properties are referenced via camelCase in JavaScript, so use style.textAlign.
To solve your problem: The CSS properties with hyphens in them are represented by JavaScript properties in camelCase to avoid this problem. You want: style.textAlign.
To answer the question: Use square bracket notation: obj.prop is the same as obj["prop"] so you can access property names using strings and use characters that are forbidden in identifiers.
I think in the case of CSS styles they get changed to camelCase in JavaScript, so test-align becomes textAlign.
In the general case, where you want to access a property that contains non-standard characters, you use array-style: ['text-align']
The object property names are not one-to-one matches for the CSS names.
At first, I wondered why the solution didn't work on my end:
api['data-sitekey'] // Returns undefined
...later on I figured out that accessing data attributes was different:
It should be like this:
var api = document.getElementById("some-api");
api.dataset.sitekey
The line below (allegedly) looks for a form with id frm1 (W3S source).
var x = document.forms["frm1"];
Why should it even work? If you look in the reference, document.forms returns the collection of forms. There are no associative arrays in JS, so document.forms["frm1"] basically asks for a property called frm1 of the returned collection. I think the right way is to use namedItem("frm1").
Is it merely a mistake in this tutorial, maybe something that worked in the past and is no longer valid?
As #Teemu pointed out, the answer you're looking for lies here: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCollection
HTMLCollection.namedItem()
Returns the specific node whose ID or, as a fallback, name matches the string specified by name. Matching by name is only done as a last resort, only in HTML, and only if the referenced element supports the name attribute. Returns null if no node exists by the given name.
While this is true and works fine for ID's when given a string, it also supports indices:
HTMLCollection also exposes its members directly as properties by both name and index. HTML IDs may contain : and . as valid characters, which would necessitate using bracket notation for property access. Currently HTMLCollections does not recognize purely numeric IDs, which would cause conflict with the array-style access, though HTML5 does permit these.
As you can see, there are problems present with mixing ID and index together. But this allowed it to have a short and sweet syntax as you can see. HTML5 has eased up the strictness, but conflicts can result.
I've recently discovered a very fundamental difference between the 2 methods of setting custom DOM attributes in Javascript. The difference is in how the HTML5 Selectors API interacts with those attributes (ie, in document.querySelector() and friends).
<button id="b3">View</button>
<script>
document.getElementById('b3').shape = 'square';
console.log( document.querySelector('*[shape]') ); // FAIL: returns null
document.getElementById('b3').setAttribute('shape','square');
console.log( document.querySelector('*[shape]') ); // WORKS: returns element
</script>
So basically if you apply attributes to an element without using .setAttribute() then you cannot later select the element by the attribute name.
BTW. This behaviour is consistent across browsers which makes me think it might be addressed by the standard, however I can't see it:
http://www.w3.org/TR/css3-selectors/#attribute-selectors
http://www.w3.org/TR/selectors-api/
The selectors API standard doesn't appear to care:
Selectors allow the representation of an element's attributes. When a
selector is used as an expression to match against an element,
attribute selectors must be considered to match an element if that
element has an attribute that matches the attribute represented by the
attribute selector.
The entire attribute matching rule seems to boil down to "if the element has an attribute" and you would think that someElement.someAttribute = something would meet the criteria of "having an attribute" but for whatever reason it doesn't.
My question is basically why the difference? Is it actually part of a standard or just an identical implementation quirk in all the major browsers (IE11, FF38 and Chrome 43)?
The reason is very simple - getElementById and all of those kind return an Element Object (see specs: http://www.w3schools.com/jsref/met_document_getelementbyid.asp)
Which means you set property shape on an object. Then you try to do a query selector, but you haven't modified the html that's queried. They are different things.
I'm looking to get the used css values of all DOM elements on a page. When I say "used values" I'm referring to the definition as specified in the W3C specification:
6.1.3 Used values
Computed values are processed as far as possible without formatting the document. Some values, however, can only be determined when the document is being laid out. For example, if the width of an element is set to be a certain percentage of its containing block, the width cannot be determined until the width of the containing block has been determined. The used value is the result of taking the computed value and resolving any remaining dependencies into an absolute value.
These should be the final values computed with respect to the actual page layout. Mozilla's docs claim that you can use window.getComputedStyle to get the used values, but this does not make sense to me because computed values are different from used values (and I want used values). Even if these are the used values, I'm not sure if this only works in Firefox or not. Is there a way to reliably get used values in all browsers?
Note: The world has moved on since the question was asked and answered. There are now more layers of values than there used to be: declared, cascaded, specified, computed, resolved, used, and actual. getComputedStyle returns resolved values (which are either computed or used depending on the property). Here are the layers:
From CSS Cascading and Inheritance Level 4:
Once a user agent has parsed a document and constructed a document tree, it must assign, to every element in the tree, and correspondingly to every box in the formatting structure, a value to every property that applies to the target media type.
The final value of a CSS property for a given element or box is the result of a multi-step calculation:
First, all the declared values applied to an element are collected,
for each property on each element.
There may be zero or many declared values applied to the element.
Cascading yields the cascaded value.
There is at most one cascaded value per property per element.
Defaulting yields the specified value.
Every element has exactly one specified value per property.
Resolving value dependencies yields the computed value.
Every element has exactly one computed value per property.
Formatting the document yields the used value.
An element only has a used value for a given property
if that property applies to the element.
Finally, the used value is transformed to the actual value based on constraints of the display environment.
As with the used value, there may or may not be an actual value for a given property on an element.
Then, the CSS Object Model defines resolved values:
getComputedStyle() was historically defined to return the "computed value" of an element or pseudo-element. However, the concept of "computed value" changed between revisions of CSS while the implementation of getComputedStyle() had to remain the same for compatibility with deployed scripts. To address this issue this specification introduces the concept of a resolved value.
The resolved value for a given longhand property can be determined as follows:
...which is followed by a list of properties (specific ones and categories) saying whether the resolved value is the computed or used value.
With that backdrop:
getComputedStyle works on all major modern browsers. Earlier versions of IE provide a near-equivalent in the form of currentStyle.
getComputedStyle returns resolved values, which for any given property is either the computed value or the used value, with the CSSOM spec defining clearly what properties get returned with which kind of value under which circumstances. I don't see anything in CSSC&I4 or CSSOM defining a way to access used values in cases where the resolved value isn't the used value, or a way to access actual values, and gsnedders says they have checked with the working group and confirmed there isn't a way to get used values, at least not yet.
Resolved values are probably good enough for what you need. For instance, the following example shows 207.5px or similar , not 50%. That's the resolved value, which is also the used value in this particular case (because I used width on an element where the display isn't none or contents), but possibly not the actual value, depending on whether subpixel rendering is feasible and appropriate in this case.
(function() {
var target = document.getElementById("target");
var style = window.getComputedStyle(target);
display("computed width = " + style.width);
function display(msg) {
var p = document.createElement('p');
p.innerHTML = String(msg);
document.body.appendChild(p);
}
})();
<div id="target" style="display: inline-block; width: 50%">x</div>
You could use jQuery or another preferred library in most cases.
For instance, your question title has font-size:100% applied to it which can be retrieved w/firebug. But with jQuery api you can retrieve the value used like so:
$('#question-header .question-hyperlink').css('font-size');//run in console
//or enter this in the url bar
//javascript:alert($('#question-header .question-hyperlink').css('font-size'));
//returns "23.06px"
NB the library is included on this page, but it would be fairly trivial to create a bookmarklet that includes jQuery and polls the necessary properties.
It appears that sometimes object.setAttribute(attrib,value) isn't equivalent to object.attrib=value in javascript?
I've got the following code, which works fine:
var lastMonthBn = document.createElement('input');
lastMonthBn.value='<'; // This works fine
lastMonthBn.type='button'; // This works fine
But the following code doesn't:
var div = document.createElement('div');
div.class = 'datepickerdropdown'; // No luck here!
So i need to use the following:
div.setAttribute('class','datepickerdropdown');
My question is, why? From reading this, I thought that object.setAttribute(blah,value) was the same as object.blah=value??
Properties and Attributes aren't really the same, however the DOM exposes standard attributes through properties.
The problem you're facing specifically with the class attribute is that class is a future reserved word.
In some implementations the use of a future reserved word can cause a SyntaxError exception.
For that reason, the HTMLElement DOM interface provides a way to access the class attribute, through the className property:
var div = document.createElement('div');
div.className = 'datepickerdropdown';
Remember, attributes aren't the same as properties, for example:
Immagine a DOM element that looks like this:
<div></div>
If you add a custom attribute to it, e.g.:
myDiv.setAttribute('attr', 'test');
An attribute will be added to the element:
<div attr="test"></div>
Accessing attr as a property on the div element, will simply give you undefined (since is not a property).
myDiv.foo; // undefined
If you bind a property to an element, e.g.:
myDiv.prop = "test";
The getAttribute method will not be able to find it, (since is not an attribute):
myDiv.getAttribute('test'); // null
Note: IE wrongly messes up attributes and properties. :(
As I've said before, the DOM exposes standard attributes as properties, but there are some exceptions that you'll have to know:
The class attribute, is accessible through the className property (the problem you have).
The for attribute of LABEL elements, is accessible through the htmlFor property (collides with the for statement).
Attributes are case-insensitive, but the language bindings for JavaScript properties are not, so the convention is to use the names is camelCase to access attributes through properties, for example the ones formed by two words, e.g. cellSpacing, colSpan, rowSpan, tabIndex, maxLength, readOnly frameBorder, useMap.
It should be noted that browsers like Safari will NOT run JavaScript if keywords like "class" or "int" are present.
So it's a cross-browser support sort of thing. "class" is present in JS2.0 [I believe a package system is available there too]
...
I should also note that in IE, setAttribute [for non-class things, since setAttribute should be use-able for other members such as "style"] can be glitchy.