I am familiar with the use of setting inline styles on elements using the elements style property. For style properties which are hyphenated in a style sheet, the most common example is to use the dot-property, using a camel cased version of the property, eg,
element.style.fontSize = "14pt";
And like any other object, the same can be accomplished using the bracketed key form, eg:
element.style["fontSize"] = "14pt";
However, I discovered by accident, using the hyphenated property as a key also works in Firefox:
element.style["font-size"] = "14pt";
I am wondering if this form is reliable in all browsers. Ie, for element.style, will the hyphenated version alongside of the camel-cased version of the property always be present, and point to the same value? Is it part of the spec, or is this just an implementation detail for Firefox? My research of the use of inline styles in w3.org and MDN have not made this detail clear to me, as all examples I have seen only show the dot-property using the camel-cased version.
The bracketed key form is useful in some cases such as iterating over various properties, and to not have to deal with both the hyphenated and camel cased versions of the keys would be especially helpful, however I want to be sure this is reliable.
Edit: I'm hoping to find something definitive, like something in the spec which directly addresses this, or something in the definition of the element.style property which would make it absolutely clear.
Edit: It was suggested that my answer could be found in How do I reference a JavaScript object property with a hyphen in it? , however this does not actually answer my question. This (like the title states) asks a general js question as to how to deal with js properties with hyphens (even though the op happened to use element.style as an example.) What I am asking is specific to element.style, and whether in all browsers, will the hyphenated version of the property always exist alongside of the camel-cased version, and point to the same value?
The documentation links to the relevant specification.
An HTMLElement.prototype.style getter results in a CSS2Properties object which inherits from CSSStyleDeclaration, the specification of which has a few relevant paragraphs about camel-cased properties:
The camel-cased attribute attribute, on getting, must return the result of invoking getPropertyValue() with the argument being the result of running the IDL attribute to CSS property algorithm for camel-cased attribute.
Setting the camel-cased attribute attribute must invoke setProperty() with the first argument being the result of running the IDL attribute to CSS property algorithm for camel-cased attribute, as second argument the given value, and no third argument. Any exceptions thrown must be re-thrown.
… and about dashed properties:
The dashed attribute attribute, on getting, must return the result of invoking getPropertyValue() with the argument being dashed attribute.
Setting the dashed attribute attribute must invoke setProperty() with the first argument being dashed attribute, as second argument the given value, and no third argument. Any exceptions thrown must be re-thrown.
The mentioned IDL attribute to CSS property algorithm is a way of normalizing a property key before getting or setting the actual key and value. Therefore, the equivalence of the camel-cased and hyphenated version of properties is specified.
But there’s a single exception: float. Because ECMAScript editions 1, 2, and 3 disallowed reserved words as property names, using element.style.float was impossible; since the 5th edition it’s possible. The usable property is called cssFloat and the spec has this to say about cssFloat:
The cssFloat attribute, on getting, must return the result of invoking getPropertyValue() with float as argument. On setting, the attribute must invoke setProperty() with float as first argument, as second argument the given value, and no third argument. Any exceptions thrown must be re-thrown.
However, older browsers don’t follow this specification (or convention before the spec existed) very well. See Where do the JavaScript style property names come from?: old Internet Explorer versions use styleFloat instead of cssFloat.
CSS didn’t always have a specification; many parts were underspecified or simply unspecified and relied on conventions among browser vendors. It’s not easy to accurately find out the implementation reality of this feature, but after some “Internet history” digging, I found:
According to the compatibility table for CSSStyleDeclaration, Internet Explorer ≤8 didn’t support it (properly), but all other browsers did since the beginning.
The current CSSOM specification remained unchanged in this part since the beginning (September 2015).
A previous version of the specification had a complete table to translate properties from one form to the other, but the property normalization remained the same (July 2011).
A specification which goes back to August 2001 has one relevant passage about getting and setting properties and a table of all camel-cased CSS properties implemented on the same interface. The passage is about CSS2Properties and says:
The CSS2Properties interface represents a convenience mechanism for retrieving and setting properties within a CSSStyleDeclaration. The attributes of this interface correspond to all the properties specified in CSS2. Getting an attribute of this interface is equivalent to calling the getPropertyValue method of the CSSStyleDeclaration interface. Setting an attribute of this interface is equivalent to calling the setProperty method of the CSSStyleDeclaration interface.
getPropertyValue and setProperty do accept the hyphenated CSS properties in this version, and, as the quote says, “the attributes of this interface correspond to all the properties specified in CSS2”. However, it seems that the exact correspondence is implied; i.e. the fact that fontSize maps to font-size, or that they’re supposed to yield the same result, may be underspecified. It also seems to imply that "fontSize" is an acceptable argument to getPropertyValue, which it isn’t.
Furthermore, the specification only was a proposed recommendation shortly before that (i.e. before 13 November, 2000), and in terms of conformance to the DOM Level 2 CSS spec, this CSS2Properties interface was optional:
The interface found within this section are [sic!] not mandatory.
It doesn’t sound as if it’s very likely that browsers from the early 2000s support this equivalence between hyphenated and camel-cased CSS properties.
Works in
Chrome 92 Mac
Safari 14.1.2 Mac
Firefox 89 and 91 Mac
const element1 = document.getElementById("e1");
const element2 = document.getElementById("e2");
const element3 = document.getElementById("e3");
element1.style.fontSize = "14pt";
element2.style["fontSize"] = "14pt";
element3.style["font-size"] = "14pt";
p { font-size: 9pt;}
<p>Text</p>
<p id="e1">Text</p>
<p id="e2">Text</p>
<p id="e3">Text</p>
Related
Is there a way to execute a method exactly after the component has its properties available but before the first render?
I mean something between the class contructor() and firstUpdated().
It sounds trivial, maybe in fact I'm missing something trivial..
The element's constructor is called when the element is created, either through the HTML parser, or for example through document.createElement
The next callback is connectedCallback which is called when the DOM node is connected to the document. At this point, you have access to the element's light DOM. Make sure to call super.connectedCallback() before doing your own work, as the LitElement instance has some work to do here.
The next callback is shouldUpdate, which is an optional predicate that informs whether or not LitElement should run its render cycle. Useful if for example, you have a single observed data property and destructure deep properties of it in render. I've found that it's best to treat this one as a predicate, and not to add all sorts of lifecycle logic inside.
After that, update and render are called, then updated and firstUpdated. It's generally considered bad practice to perform side effects in render, and the occasions that you really need to override update are rare.
In your case, it sounds very much like you should do your work in connectedCallback, unless you are relying on LitElement's rendered shadow DOM, in which case, you might consider running your code in firstUpdated, then calling this.requestUpdate() to force a second update (or changing some observed property in firstUpdated)
More info: https://lit-element.polymer-project.org/guide/lifecycle
Historically in the XML DOM for any Element one can call element.getAttributes() which will return a NamedNodeMap. This map allows you to iterate the Node instances, which in this case are Attr instances describing each attribute.
But when reading MDN's description of the node type enumerated value for Node.ATTRIBUTE_NODE, they say:
An Attribute of an Element. Attributes no longer implement the Node interface as of DOM4.
Are they talking about Attr? But if Attr does not implement Node in DOM 4, what does element.getAttributes() return? A NamedNodeMap of nodes that are not instances of Attr?
Or does Element not have a element.getAttributes() method at all in DOM 4? If not, how does DOM 4 let me iterate through all the attributes? And is the code I'm writing in Java 11 using element.getAttributes() therefore eventually going to be out of date? And the same thing for JavaScript code I write in the browser?
There's various points here.
DOM4 does indeed not contain a getAttributes() method on Element. It does, however, have a property called attributes which on accessing returns a NamedNodeMap.
"NamedNodeMap" seems a slightly misleading name since its items are Attr objects.
MDN is out of date. Earlier versions of the Attr interface in the DOM4 standard did not extend the Node interface, but it was found not to be web-compatible, and so now the current definition of Attr does, just as DOM3 did.
Where can I find a full API reference for PolymerElements?
For example, the description for PaperDialogBehavior says
Use the dialog-dismiss and dialog-confirm attributes on interactive controls to close the dialog. If the user dismisses the dialog with dialog-confirm, the closingReason will update to include confirmed: true.
But I can't find any further information anywhere about what closingReason actually is (a property? a parameter passed to some callback?) and how it "includes" confirmed: true.
Instead of wasting time on guessing how to do every single little thing when using Polymer, it would be nice to have an actual API reference. Is there one?
There isn't any further information. Documentation isn't well written and you have to find many things on your own. Just remember that everything in Polymer is about properties. So closingReson is property that you can access on paper-dialog (or any other elements using paperDialogBehavior).
This property contains object {confirmed: true|false}
Truly said, behaviors has extremely badly written documentations. It is very confusing. For example:
modal: boolean = false
If modal is true, this implies no-cancel-on-outside-click, no-cancel-on-esc-key and with-backdrop.
but none of those properties are specified in paperDialogBehavior, because it is inherited from iron-overlay-behavior. And these inheritences are not documented (mostly).
I can get my <iron-meta> instance to work properly when using a static value. But when I bind the value to a dynamic variable (using {{}}) it <iron-meta> no longer behaves as expected.
Does <iron-meta> support binding its value to dynamic variables?
<iron-meta id="meta" key="info" value="foo/bar"></iron-meta> // works
<iron-meta id="meta" key="info" value="{{str}}"></iron-meta> // fails
Previous work
This question is a refinement of this question in order to clarify that the ONLY thing causing the problem is the change from a static string value to a dynamic string value binding. I was getting a lot of other suggesting that had nothing to do with the change from static to dynamic so I thought it might be best to rewrite the question to clarify that. But the entire code context is contained in the links there if that would help.
Alternative solutions
There has been some recent chatter about using <iron-localstorage>. Perhaps that is the best way to go for dynamic binding essentially creating global variables?
Yes, <iron-meta> does support binding to variables, but perhaps not in the way you think.
Example: http://plnkr.co/edit/QdNepDrg9b3eCTWF6oRO?p=preview
I looked through your code here, here, and here but I'm not entirely clear what your expectations are. Hopefully my attached repro might shed some light. I see you have declaratively bound <iron-meta id="meta" key="route" xvalue="foo-bar" value="{{route}}"></iron-meta> which is fine - when route changes, iron-meta's key="route" will update accordingly.
However, be aware that in Polymer 1.0, <iron-meta> is in essence a one-way bind from parent to child in the sense that you set a meta key value dynamically by binding to a property; but to get that value, you'll have to get it imperatively via iron-meta's byKey() method.
<iron-meta> is just a simple monostate pattern implementation without an in-built path notification mechanism. What this means is value changes do not propagate upwards. Therefore, doing something like
<!-- this does not work like the way you think -->
<iron-meta id="meta" key="foo" value="{{bar}}">
in order to get the value of foo, or listen to changes to foo, does not work. This behaves more like a setter, where you set the value of foo based on your data-bound property bar.
From what I gather, it seems that you're trying to implement some sort of global variable functionality. A monostate implementation used to work in Polymer 0.5, but not in 1.0. Unfortunately, until Google endorses a "best-practice" pattern for this, suggestions till-date seems a bit speculative to me. You might find this (Polymer 1.0 Global Variables) helpful.
I have had success using <iron-signals> to communicate global information. I know there is a warning in the <iron-signals> documentation that discourages its use for related elements, but when broadcasting a shared resource it seems just the thing. For example:
// source element
var db = SomeDB.init();
this.fire('iron-signal', { name: 'database', data: db });
<-- sink element -->
<iron-signals on-iron-signal-database="dbChange"></iron-signals>
class SinkElement {
dbChange(e, detail) {
this.db = detail;
this.db.getSomeData();
}
}
I'm using Coded UI Test to test a web application.
I have a class Locator that I use to stash the specifics needed for CUIT to find a control. To operate on a control, a page object specifies the locator, not the control, and lower-level functions find the control and perform the operation.
Right now, my class has:
Locator name.
One or more attrName/attrValue pairs that can locate the HTML element for the control.
An operator (Contains or EqualTo) that specifies the matching needed.
The problem: Some of the controls I need to operate on don't have enough unique attributes to allow them to be found. (Yes, I know the developers should improve their HTML, but I don't control that.) I have been using a locator to find a nearby element, then "walking" in the DOM to get to the element I want. I hate having this DOM-walking code in my page object, even factored into a function.
A possible solution: I'm considering enhancing class Locator so that it can have either the attrName/attrValue pairs or a reference to a function that has the DOM-walking code. One advantage of this is that the page objects would always use a locator object. Another is that when the HTML is improved, the locator could change from DOM-walking code to attrName/attrValue pairs, which would be transparent to the page object.
Still, I think this may be over-complicated.
Is there a better solution to this problem?
Not sure specifically how your locator works, but could you find the closest parent to that object, let's say an HTML Div with an id of "parent", and then count the tag instances underneath? For example:
HtmlDiv id="parent">
HtmlHyperlink>text1</
HtmlHyperlink>text2</
Would require the following code:
public HtmlHyperlink text2Link
{
get
{
HtmlDiv parentDiv = new HtmlDiv(browser);
parentDiv.SearchProperties["id"] = "parent";
HtmlHyperlink target = new HtmlHyperlink(parentDiv);
target.SearchProperties["TagInstance"] = "2";
}
}
This would find the 2nd hyperlink under the parent object. (Tag instances are not zero based).
Then, you'd just interact with your object as needed:
Mouse.Click(text2Link);
for example.