Is there a way to extend native elements (eg. HTMLInputElement, HTMLTableElement etc) instead of Polymer.Element ?
Short answer to your question is not as of now. The reason behind the same is that all the browsers have not agreed to implement this that's why polymer has not implemented it yet.
Polymer does not currently support extending built-in elements. The custom elements spec provides a mechanism for extending built-in elements, such as and . The spec calls these elements customized built-in elements. Customized built-in elements provide many advantages (for example, being able to take advantage of built-in accessibility features of UI elements like and ). However, not all browser makers have agreed to support customized built-in elements, so Polymer does not support them at this time.
Related
I've heard contextmenu is deprecated: https://html.spec.whatwg.org/multipage/obsolete.html#attr-contextmenu
Then, Is there are ways to replace it?
As the feature was not that popular, it is no longer supported.:
The support for HTML5 context menus, introduced with Firefox 8, will be removed soon. Other browser vendors were not interested in the feature, and therefore it has already been removed from the HTML spec, leaving Firefox as the only browser implementing the and elements as well as the contextmenu global attribute.
If desired, you can instead create your own context menu as seen in some rich web applications like Google Drive. The WAI-ARIA standard provides a way to create accessible menus which is highly recommended.
You can create your own menus using ARIA.
Instead of <menu> & <menu-item> you use normal lists (<ul> & <li>), decorate them and use JS for functionality.
You find more details and presets here and here.
In knockout we can create custom elements that can look something like this:
<flight-deals params='from: "lhr", to: "sfo"'></flight-deals>
The definition of custom elements in HTML is still work in progress and a part of the process of using this today is to register the custom element to the DOM using document.registerElement.
However, I can not find anything in the knockout documentation regarding these aspects, and when I investigate if my custom elements are registered to the DOM by knockout after calling ko.components.register, they turn out not to be.
So if I'm using custom elements in knockout, should I also make sure to also register these manually using document.registerElement? The fact that knockout does not already do this makes me a little confused.
You don't need to do anything special for modern browsers and IE9+.
For IE6 - IE8 support you do need to be aware of this and use a wee bit of magic. As the relevant documentation mentions:
HTML5-era browsers, which includes Internet Explorer 9 and later, automatically allow for custom elements with no difficulties.
Internet Explorer 6 to 8 also supports custom elements, but only if they are registered before the HTML parser encounters any of those elements.
IE 6-8’s HTML parser will discard any unrecognized elements. To ensure it doesn’t throw out your custom elements, you must do one of the following:
Ensure you call ko.components.register('your-component') before the HTML parser sees any <your-component> elements
Or, at least call document.createElement('your-component') before the HTML parser sees any <your-component> elements. You can ignore the result of the createElement call — all that matters is that you have called it.
I am thinking how KnockoutJs or AngulasJs type of frameworks allow us to add new Attributes, Elements etc in our HTML Code? How does the compiler at runtime allows these frameworks.
The only thing I can think of is that these frameworks have their custom DTD loading on the HTML page, but I can't see any reference to any DTD in html code.
Any suggestion how should I proceed?
As Kevin notes, custom attributes are legal in HTML5 if they start with -data.
You can put attributes that do not start with -data on an element, and modern browsers will not care, even though they are not valid per-spec. They will not have any effects, but they will not be removed. Javascript can then identify nodes that have them, and add behavior however they need to.
Custom Elements are also legal in modern browsers. In older version of Internet Explorer they can be defined using document.createElement. Knockout uses this method.
A number of developers have been wondering how graceful degradation should be approached in custom elements (or Polymer elements). This is for the use-case where either polyfills are not being used, Web Components are not supported or JavaScript is simply switched off.
Does anyone have thoughts on how this should be done?
There are two types of custom elements we're usually interested in adding support for graceful degradation to: Custom Elements that extend native HTML tags and Custom Elements which do not.
Custom Elements support natively extending elements already baked into the platform (e.g <button>, <input>). One way of doing this is using the is syntax. So, if you're extending a built-in, I believe the most direct way to ensure graceful degradation is to use the is syntax as follows: <button is="my-button"> rather than <my-button></my-button>.
Some examples of where I could see this working well are:
Fancy input fields:
<input is="fancy-input" type="text" value="So fancy">
Custom video players:
<video is="custom-player" src="amazeballs.mp4">
Music visualizers:
<audio is="music-visualizer" src="track.ogg">
This way if a browser without Custom Element cannot understand the is syntax, the element being extending should still work with a degraded experience.
What about Custom Elements where you are not extending a specific built-in? For example: <my-preload-animation>.
One approach I've been taking to this is specifying fallback content in the Light DOM:
<my-preload-animation>
Loading...
</my-preload-animation>
If a browser without Custom Element support interprets the tag as HTMLUnknownElement, the fallback (a loading message) will still be rendered. This (appears) to work for simple elements.
For more complex ones (e.g if you're making use of <content>/<shadow> in your element), I remove the fallback via script when my custom element is upgraded.
I think that's reasonable. This is how most (not all) HTML elements work. Check out this blast from the past: http://code.tutsplus.com/tutorials/quick-tip-html5-video-with-a-fallback-to-flash--net-9982
I heard of shadow DOM which seems to solve the problem of encapsulation in web widget development. DOM and CSS rules get encapsulated which is good for maintenance. But then isn't this what iframes are for? What problems are there with iframes that made it necessary for W3C to come up with Shadow DOM or HTML5 Web Components?
Today, iframes are commonly used to assure separate scope and styling. Examples include Google's map and YouTube videos.
However, iframes are designed to embed another full document within the current HTML document. This means accessing values in a given DOM element in an iframe from the parent document is a hassle by design. The DOM elements are in a completely separate context, so you need to traverse the iframe’s DOM to access the values you’re looking for. Contrast this with web components which offer an elegant way to expose a clean API for accessing the values of custom elements.
Imagine creating a page using a set of 5 iframes that each contain one component. Each component would need a separate URL to host the iframe’s content. The resulting markup would be littered with iframe tags, yielding markup with low semantic meaning that is also clunky to read and manage. In contrast, web components support declaring rich semantic tags for each component. These tags operate as first class citizens in HTML. This aids the reader (in other words, the maintenance developer).
In summary, while both iframes and the shadow DOM provide encapsulation, only the shadow DOM was designed for use with web components and thus avoids the excessive separation, setup overhead, and clunky markup that occurs with iframes.
iframes are use as just encapsulation objects...
with the exception of SVG (more on that later), today’s Web platform
offers only one built-in mechanism to isolate one chunk of code from
another — and it ain’t pretty. Yup, I am talking about iframes. For
most encapsulation needs, frames are too heavy and restrictive.
Shadow DOM allows you to provide better and easier encapsulation, by creating another clone of the DOM or part of it.
For example imagine you build a widget (as I have) that is used across websites.
You widget might be affected by the css on the page and look horrible, whereas with Shadow DOM it will not :)
Here is an excellent article on the topic:
What The Heck is Shadow DOM/