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.
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.
I ran my site through the W3C validator for HTML 5, which is still experimental, I know. I got this warning with it though that I don't really understand:
The menu element is not supported by browsers yet. It would probably be better to wait for implementations.
I'm confused why this warning exists. What exactly needs to be "implemented" in the browser? As far as I was aware, the <menu> element was just another element for better semantic meaning, that was basically equivalent to a <div> element. Did I miss something? Is there something special that browsers are supposed to do with this element?
The menu tag is designed to contain 'commands' (see What exactly is the HTML5 <command> tag and what is the browser support). It is the command functionality that has not been widely implemented yet.
It may be implemented through a right-click menu, through an additional menu in the browser, or something else entirely.
Lots more good info here: http://www.html5laboratory.com/by-your-command.php
I know that you can add context menu items(currently only in Firefox) but can you replace the context menu entirely with items specified?
By that I mean that if I create a context menu with:
Action 1
Action 2
Then when opening the context menu ONLY those items would appear.
I also mean according to the HTML5 menu element specification and not current implementations.
No, HTML5 doesn't and you can't. An important reason for having the menu element affect the context menu was to allow authors to be able to put operations on the context menu without disrupting all the facilities that are built into the browser and are important to the user. So allowing the web page author to remove the existing context menu options would defeat the point.
It isn't HTML that supports this, but the browser.
Some browsers do indeed allow you to disable the context menu and activate something else on right click, but others don't.
It's been possible in most browsers for ages (certainly long before HTML5), but one or two browsers have never allowed it, on the grounds that you're interfering with the standard browser UI. (Opera was always the odd one out here)
For browsers that do support it, you need to use the onmousedown event, which will give you an event object that will tell you which mouse button was pressed.
Or you can use a jQuery plugin -- there seem to be a few of them around for this. Try this one or this one.
What is HTML5 ARIA? I do not understand how to implement it.
WAI-ARIA is a spec defining support for accessible web apps. It defines bunch of markup extensions (mostly as attributes on HTML5 elements), which can be used by the web app developer to provide additional information about the semantics of the various elements to assistive technologies like screen readers. Of course, for ARIA to work, the HTTP user agent that interprets the markup needs to support ARIA, but the spec is created in such a way, as to allow down-level user agents to ignore the ARIA-specific markup safely without affecting the web app's functionality.
Here's an example from the ARIA spec:
<ul role="menubar">
<!-- Rule 2A: "File" label via aria-labelledby -->
<li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span>
<ul role="menu">
<!-- Rule 2C: "New" label via Namefrom:contents -->
<li role="menuitem" aria-haspopup="false">New</li>
<li role="menuitem" aria-haspopup="false">Open…</li>
...
</ul>
</li>
...
</ul>
Note the role attribute on the outer <ul> element. This attribute does not affect in any way how the markup is rendered on the screen by the browser; however, browsers that support ARIA will add OS-specific accessibility information to the rendered UI element, so that the screen reader can interpret it as a menu and read it aloud with enough context for the end-user to understand (for example, an explicit "menu" audio hint) and is able to interact with it (for example, voice navigation).
ARIA stands for Accessible Rich Internet Applications.
WAI-ARIA is an incredibly powerful technology that allows developers to easily describe the purpose, state and other functionality of visually rich user interfaces - in a way that can be understood by Assistive Technology. WAI-ARIA has finally been integrated into the current working draft of the HTML 5 specification.
And if you are wondering what WAI-ARIA is, its the same thing.
Please note the terms WAI-ARIA and ARIA refer to the same thing. However, it is more correct to use WAI-ARIA to acknowledge its origins in WAI.
WAI = Web Accessibility Initiative
From the looks of it, ARIA is used for assistive technologies and mostly screen reading.
Most of your doubts will be cleared if you read this article
http://www.w3.org/TR/aria-in-html/
What is it?
WAI-ARIA stands for “Web Accessibility Initiative – Accessible Rich Internet Applications”. It is a set of attributes to help enhance the semantics of a web site or web application to help assistive technologies, such as screen readers for the blind, make sense of certain things that are not native to HTML. The information exposed can range from something as simple as telling a screen reader that activating a link or button just showed or hid more items, to widgets as complex as whole menu systems or hierarchical tree views.
This is achieved by applying roles and state attributes to HTML 4.01 or later markup that has no bearing on layout or browser functionality, but provides additional information for assistive technologies.
One corner stone of WAI-ARIA is the role attribute. It tells the browser to tell the assistive technology that the HTML element used is not actually what the element name suggests, but something else. While it originally is only a div element, this div element may be the container to a list of auto-complete items, in which case a role of “listbox” would be appropriate to use. Likewise, another div that is a child of that container div, and which contains a single option item, should then get a role of “option”. Two divs, but through the roles, totally different meaning. The roles are modeled after commonly used desktop application counterparts.
An exception to this are document landmark roles, which don’t change the actual meaning of the element in question, but provide information about this particular place in a document.
The second corner stone are WAI-ARIA states and properties. They define the state of certain native or WAI-ARIA elements such as if something is collapsed or expanded, a form element is required, something has a popup menu attached to it or the like. These are often dynamic and change their values throughout the lifecycle of a web application, and are usually manipulated via JavaScript.
What is it not?
WAI-ARIA is not intended to influence browser behavior. Unlike a real button element, for example, a div which you pour the role of “button” onto does not give you keyboard focusability, an automatic click handler when Space or Enter are being pressed on it, and other properties that are indiginous to a button. The browser itself does not know that a div with role of “button” is a button, only its accessibility API portion does.
As a consequence, this means that you absolutely have to implement keyboard navigation, focusability and other behavioural patterns known from desktop applications yourself. You can find some Advanced ARIA techniques Here.
When should I not use it?
Yes, that’s correct, this section comes first! Because the first rule of using WAI-ARIA is: Don’t use it unless you absolutely have to! The less WAI-ARIA you have, and the more you can count on using native HTML widgets, the better! There are some more rules to follow, you can check them out here.
What is ARIA?
ARIA emerged as a way to address the accessibility problem of using a markup language intended for documents, HTML, to build user interfaces (UI). HTML includes a great many features to deal with documents (P, h3,UL,TABLE) but only basic UI elements such as A, INPUT and BUTTON. Windows and other operating systems support APIs that allow (Assistive Technology) AT to access the functionality of UI controls. Internet Explorer and other browsers map the native HTML elements to the accessibility API, but the html controls are not as rich as the controls common on desktop operating systems, and are not enough for modern web applications Custom controls can extend html elements to provide the rich UI needed for modern web applications. Before ARIA, the browser had no way to expose this extra richness to the accessibility API or AT. The classic example of this issue is adding a click handler to an image. It creates what appears to be a clickable button to a mouse user, but is still just an image to a keyboard or AT user.
The solution was to create a set of attributes that allow developers to extend HTML with UI semantics. The ARIA term for a group of HTML elements that have custom functionality and use ARIA attributes to map these functions to accessibility APIs is a “Widget. ARIA also provides a means for authors to document the role of content itself, which in turn, allows AT to construct alternate navigation mechanisms for the content that are much easier to use than reading the full text or only iterating over a list of the links.
It is important to remember that in simple cases, it is much preferred to use native HTML controls and style them rather than using ARIA. That is don’t reinvent wheels, or checkboxes, if you don’t have to.
Fortunately, ARIA markup can be added to existing sites without changing the behavior for mainstream users. This greatly reduces the cost of modifying and testing the website or application.
I ran some other question regarding ARIA. But it's content looks more promising for this question. would like to share them
What is ARIA?
If you put effort into making your website accessible to users with a variety of different browsing habits and physical disabilities, you'll likely recognize the role and aria-* attributes. WAI-ARIA (Accessible Rich Internet Applications) is a method of providing ways to define your dynamic web content and applications so that people with disabilities can identify and successfully interact with it. This is done through roles that define the structure of the document or application, or through aria-* attributes defining a widget-role, relationship, state, or property.
ARIA use is recommended in the specifications to make HTML5 applications more accessible. When using semantic HTML5 elements, you should set their corresponding role.
And see this you tube video for ARIA live.