HTML 5.1 Specification define strange property in the Document IDL.
getter object (DOMString name);
It's not a typo and I don't understand how to use it.
That part of the WebIDL definition for the Document interface specifies that it has a named property getter. It only has meaning in combination with the section of the spec of the HTML spec that defines the supported property names for the Document interface.
Together, those specify some things that get exposed as named properties of a Document.
Consider the following document:
<!doctype html>
<form name=foo></form>
<form name=bar></form>
<iframe name=bar></iframe>
<p id=baz>
If you call document.foo you’ll get back a single element, the form name=foo element.
If you call document.bar you’ll get back a collection that includes both the form name=bar element and iframe name=bar element.
And if you call document.baz you’ll get back undefined.
The reason for all that behavior is, the section of the HTML spec defining the supported property names for the Document interface specifies that form[name] values and iframe[name] values are accessible as named properties of a Document
And that spec section also says that if a Document named property matches only one element, then that element is returned, but if it matches multiple elements, then a collection is returned.
And the reason document.baz returns undefined is because that spec section does not specify p[id] values as being accessible as named properties of a Document.
However, if you instead do window.baz you will get back the p id=baz element.
The reason for that difference is: while the WebIDL definition for Window specifies it is having a named property getter (just as the Document WebIDL does), the section defining the supported property names for Window—unlike the similar section for Document—does specify p[id] values (actually id values of any element) as being accessible as named properties of a Window.
Related
MDN says:
If you want default content for your , you enter it between the opening and closing tags. does not support the value attribute.
but in angular property binding we can bind to value.
<textarea rows="10" [value]="'test'" ></textarea>
is there any online repository where we can find all the properties with regard to angular.??
I found the article "HTML Attributes vs DOM Properties and Angular 2 Data Binding" useful, especially the following sections:
DOM is basically collection of objects (window,html,body, head and etc) which allows us to manipulate it. It means that HTML elements are contained in the DOM as objects.HTML elements have attributes which initilizes DOM properties. Once initilization process is done attributes job is done.
<input type=”text” value=”5">
Given input element has type and value attributes. When HTML element is created its properties which have similar names to attributes (but not same thing) is created, too. After initilization given input element have properties such as type and value.
Angular property binding acts on the elements/objects contained in the DOM. You can find a list of properties of all element interfaces at MDN Web APIs documentation. Most of the one's you're interested in, have a name that starts with 'HTML'.
The HTMLTextAreaElement interface for example corresponds to the <textarea> element. You can use all its properties and the properties of its parent interfaces for Angular property binding as long as they're not read only.
I know that custom tags need to have a "-". And I kwnow that custom attributes need the "data-" prefix. But what about custom attribute on a custom tag?
If I define a custom HTML tag/element, such as <x-sososlik></x-sososlik>.
And I need some custom attributes on it. For example: hair-color.
Does that attribute need the data-* prefix?
<x-sososlik hair-color="green"></x-sososlik>
-or-
<x-sososlik data-hair-color="green"></x-sosolik>
The question is more about "what is the CORRECT way", because it works with both.
I'm asking because I cannot find that information.
I need to know it because I'm trying to shorten the attribute names on existing project, in the real code there a lot of them.
No, you don't need to use the data- prefix on an autonomous custom element (as opposed to a customized built-in element). As specified in the WHATWG HTML standard:
Any namespace-less attribute that is relevant to the element's functioning, as determined by the element's author, may be specified on an autonomous custom element, so long as the attribute name is XML-compatible and contains no ASCII upper alphas. The exception is the is attribute, which must not be specified on an autonomous custom element (and which will have no effect if it is).
I am using neon-animation-pages and I want to see if an attribute is set on one of its child elements. From what I understand you can just add any attribute you want and if it is in the tag it will resolve to true if it doesn't have a value explicity set. For instance:
<neon-animation-pages id="pages">
<div awesome>This one is awesome</div>
<div>This one is not</div>
<div>This one is not</div>
</neon-animation-pages>
Above I created my own attribute called: awesome
In my code I use this:
_onIronSelect: function(){
console.log(this.$.pages.selectedItem.getAttribute('awesome'));
}
The console only spits out 'null' or ' ' depending on whether it has my awesome attribute. I can prob make it work, but I thought it was supposed to resolve to true or false, boolean?
Found this in the docs
Boolean properties are set based on the presence of the attribute: if
the attribute exists at all, the property is set to true, regardless
of the attribute value. If the attribute is absent, the property gets
its default value.
at https://www.polymer-project.org/1.0/docs/devguide/properties.html
So I assume I should be trying to get the value of the selectedItem's property > awesome. How can I do this?
There's an important difference between properties and attributes. Properties are JavaScript properties on the DOM object. Attributes basically provide a string valued key/value database that can be initialized from markup.
The Polymer docs you quoted are talking about properties. If a Polymer element has a property, awesome, listed in the properties object with a type of Boolean, it will deserialize to true or false as described.
This is a service Polymer provides because it's a common pattern for HTML elements. For example, if you set the id attribute on an HTML element, the browser automatically reflects that to the id property. But if you add a generic attribute that that element doesn't know about (like awesome), the attribute isn't reflected as a property.
If you want to test for the presence or absence of an attribute on any element (standard HTML or Polymer), use hasAttribute as #günter-zöchbauer said. According to MDN, getAttribute in all modern browsers returns null when the attribute is absent, but apparently this wasn't always true, so hasAttribute is probably safer, as well as clearer.
https://developer.mozilla.org/en-US/docs/Web/API/Element/getAttribute
Maybe you want
this.$.pages.selectedItem.hasAttribute('awesome')
When working with custom HTML elements in web components, should I still name custom attributes with the prefix data?
For example:
<!-- Should form be data-form? -->
<my-button form="foo">click me</my-button>
No, that's not necessary.
Existing HTML elements have a defined set of attributes, which means you would invalidate the HTML by just adding any attribute. By introducing the data- attributes, it was made possible to extend existing elements without invalidating them.
Web components are custom elements. They have no defined set of attributes, you define them yourself. Whether or not you use data- attributes is completely up to you, but you don't have to. Your component cannot become invalid because there is no definition of valid for it.
If you care about semantic/valid HTML, this answer may be relevant to you too: Are custom elements valid HTML5?. In short: use a dash in your component name to make sure it's picked up as valid HTML.
In general, there is no difference between custom elements and predefined. You might create an element of your choice with document.createElement and register it with document.registerElement. The result would be:
console.log(document.createElement('my-button').constructor);
//⇒ function HTMLElement() { [native code] }
console.log(document.registerElement('my-button'));
//⇒ function my-button() { [native code] }
console.log(document.createElement('my-button').constructor);
//⇒ function my-button() { [native code] }
As you could see, once registered, the element is awarded with it’s own constructor. That provides an ability for components to behave in it’s own way. But:
console.log(document.createElement('my-button').__proto__.__proto__);
//⇒ HTMLElement
is still a good old plain HTMLElement. So, the rules for attribute naming were not changed.
Please note, that libraries, like polymer, might add additional attribute handling; the above is true for plain web-components only.
I'm validating my site using W3C validation and the validation gives error like data attribute is not allowed on anchor tag. I've removed and added the same data attribute to the parent tag again I'm getting the same error for that parent element.
Whenever you see a reference to a "data attribute", it does not literally mean an attribute called data.
A data attribute, more fully known as a custom data attribute, is an attribute, of any name and value you choose, whose name is prefixed with data-. For example, data-color or data-category. Sometimes they're written as "data-* attributes" to make it clearer that the data- portion is a prefix and not the entire attribute name.