Does HTML5 supports replacing the context menu? - html

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.

Related

How to make sure that accessibility options are accessible

Many webpages have options where you can change the font size or increase contrast. Those options are most of time designed for visually impaired people.
What technics do you use to ensure that those people actually find the options to increase accessibility?
According to the WCAG 2.0 spec, a high-contrast toggle must itself be high-contrast. I've done this simply by creating simple black-on-white button (that inverts when hovered of focussed, for effect) at the head of my page. I opted to use a font-awesome icon for the button content, so I was careful to include role="img" and aria-label="High Contrast Toggle" in the <i>. I was also careful to make the toggle keyboard-accessible by adding a tabindex
It's better to make all text high-contrast by default, but I opted for the toggle as a learning challenge and also because I did not want to change my page's colour scheme. Alternatives to toggles that are suggested by the spec are using skrims or text-shadow. (description, 3rd paragraph). This would have looked and worked better, but my testing tools (WAVE Chrome extension v. 1.0.1) didn't detect the change, so I decided to make a toggle.
If you provide such widgets, you have to make sure that your document is also accessible without using them. Otherwise (= your document is inaccessible with the default settings) some users can’t find/reach/use your widgets to change the settings.
If you can’t make your whole document accessible without using the widgets, you should at least make sure that the widgets can be reached and used. This would be similar to providing a link to an alternate version.
As far as I know, there is no standard way to mark up or annotate such accessibility-related widgets. If they are important, it can make sense to have them as one of the first elements of the document.
(And just in case it’s not clear: it’s rarely necessary to provide such widgets, e.g., for text resizing, at all; there are often many other ways/technologies to make sure that your document is accessible.)

Can I have a nav element with no links in it?

<nav> typically has <a> elements inside it, but is it required? I have a radio button form whose purpose is akin to navigation. It doesn't navigate to other pages on the Internet, but instead changes the visibility of elements within the body of the HTML document (like a carousel).
Thanks! I've been wrestling with semantic markup tonight!
tl;dr: No, the nav element requires links (but not necessarily a elements).
W3C’s HTML5 defines the nav element like this:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
By default, a radio button doesn’t link to a part within the page. In your case, it changes the visibility of an element on the page. So it’s not appropriate to use the nav element for this purpose (unless, maybe, changing the radio button focuses the changed element; but that behaviour might be bad for usability).
The whole point of semantics, is that when viewed in an entirely different light, it's still readily clear in how to derive meaning and relational context from the content.
A web browser will parse your HTML out of the Dom after every load or change, and construct an opinion based on that about the content. The browser will keep this handy to itself internally in case it needs it later to assist it with difficult judgement calls should it be asked to perform a seemingly complex operation.
For example, someone who has really poor eyesight might enable an accessibility feature on their mobile device that tacks on a variety of different visual styles adding a great deal of visual emphasis to interactible elements they can touch, depending on the type of interaction. This could be something like a bright color coated and outlined overlay on top of elements, perhaps something like cyan for multimedia controls, yellow for form elements, and magenta for navigation points. This feature would have to work on any and all possible content which the browser will ever render, and so what you've got is a hidden under the hood runtime script that the browser is using to dynamically parse what ever it's loaded in order to construct some sort of opinion which it can lean on exorcise what will hopefully be good judgement. So no matter how clear your navigation might seem visually to someone with great eyesight, this is why semantics are such a big deal and why it's so important we continue to make efforts to use them correctly, as here you have a machine alternatively parsing your source code because it has zero comprehension of it's otherwise visual context.
When it comes to accessibility, browsers are much more complex in forming their opinions than just simply parsing the Dom. In a scenario such as this example, and the code you're wanting to write, wrapping your navigation elements in a nav tag should properly assist the browser into making the right call. Even if they're not link tags, the browser is going to take note of any elements inside of a nav tag witch active event listener handles items like click and similar.
As another user mentioned, semantics is all about judgement. There are countless other ways which good semantics play a role into good development, dry code and easier maintainability being my two favorites. There are no hard lines for "can do" and "can't do", but practicing good semantics is still pretty easy to do regardless. Just continually ask yourself these couple of questions about your core content-
• If someone or something tried to use this in ways which I'm not explicitly building in targeted functionality for, do I think it will be able to understand what content is what and the associated intents well enough to be successful at what ever is being attempted?
• If I was to refactor or repurpose any of this later, is there a clear separation of content, logic, and style? Is my content clean, and meaningfully distinguished? Is it so clean and ready, that I can just rip it out and drop it into something new with little or no change? Essentially, how portable is this content? Is it plug and play level portable? And if not, could it be made more portable with better semantics?
Practice developing with proper semantics using those couple of core guidelines, and you'll almost always be perfectly fine.
Just to make sure I've directly addressed your question- Yes. What you've done is "okay", and "semantically legal" 🙂

What is shadow root

In Google Chrome’s Developer Tools, I see a #shadow-root right under <html lang="en"> tag. what does it do and what is it used for? I don’t see it in Firefox nor in IE; only in Chrome, is this a special feature?
If I open it, it shows <head> and <body> and a link beside named reveal, by clicking, it points to the <head> and <body>, nothing else.
This is a special indicator that a Shadow DOM exists. These have existed for years, but developers have never been given APIs into it until recently. Chrome has had this functionality for a while, other browsers are still catching up. It can be toggled in the DevTools Settings under the "Elements" section. Uncheck the "Show User Agent Shadow DOM". This will at least hide away any Shadow DOMs created internally (like select elements.) I am unsure right away if it affects user-created ones, such as custom elements.
These come up in things like iframes as well, where you have a separate DOM tree nested inside of another.
The Shadow DOM is simply saying that some part of the page, has its own DOM within it. Styles and scripting can be scoped within that element so what runs in it only executes in that boundary.
This is one of the primary pieces needed for Web Components to work. Which is a new technology allowing developers to build their own encapsulated components that developers can use just like any other HTML element.
As an example of Shadow DOM, when you have a <video> tag on a web page, its shown as just one tag in the main DOM, but if you enable Shadow DOM, you will be able to see the video player's HTML(player DOM).
This is explained aptly in this article, http://webcomponents.org/articles/introduction-to-shadow-dom/
In the case of web components, there is a fundamental problem that makes widgets built out of HTML and JavaScript hard to use.
Problem: The DOM tree inside a widget isn’t encapsulated from the rest of the page. This lack of encapsulation means your document stylesheet might accidentally apply to parts inside the widget; your JavaScript might accidentally modify parts inside the widget; your IDs might overlap with IDs inside the widget and so on.
Shadow DOM addresses the DOM tree encapsulation problem.
For example, if you had markup like this:
<button>Hello, world!</button>
<script>
var host = document.querySelector('button');
var root = host.createShadowRoot();
root.textContent = 'こんにちは、影の世界!';
</script>
then instead of
Hello, world!
your page looks like
こんにちは、影の世界!
Not only that, if JavaScript on the page asks what the button’s textContent is, it isn’t going to get “こんにちは、影の世界!”, but “Hello, world!” because the DOM subtree under the shadow root is encapsulated.
NOTE: I have picked up above content from https://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ as it helped me understand shadow DOM a little better than answers already here. I have added relevant content here so that it helps others but do take a look at the link for detailed discussion on same.

Styling autocomplete dropdowns in browsers

On many websites, when typing in a username for example, a dropdown occurs where previous input shows up so the user can easily select something instead of typing. I know you can turn this off in browsers by having the form or input have an attribute of autocomplete="off". The problem is when I want it on, and the input has padding. The dropdown looks horribly off because it has no padding for each item.
Is there any way to style this with only css? I'm aware that you could potentially use a javascript/jQuery workaround to store previous entries in a cookie or something and make your own dropdown. But I don't want to rely on javascript for this.
Nope. Autocomplete is not a part of any standard, and is not part of the DOM. The only way to style is, as you've suggested yourself, by recreating that functionality using JavaScript.
Unfortunately there is no way to style the drop down box itself with CSS, because in this case (when not using javascript/jQuery/mootools/etc.) it is operating system dependent - i.e Windows/Linux/Mas OS visualize it according the visual user settings (i.e scheme).

Element.hidden variable portability

I'm writing a template page for a personal site I'm designing, and I'm going to be using drop-down DIV tags for the log-in form.
I'm also using Google Chrome as my primary testing, etc. browser, and noticed that all visible Elements appear to have a property called 'hidden' that holds a boolean value.
It works just like you'd expect, becoming hidden when set to True and visible when set to False.
document.getElementById("element").hidden = true;
document.getElementById("element").hidden = false;
Strangely enough, even Firefox 8.0.1 handles this in the same manner.
As my Google-fu hasn't been able to turn up any information on this, does anybody here know why this appears to be working, and how many other browsers support this?
I will add that this website I'm building is for my personal use, so cross-browser-compatibility is not intended, but would be a nice side-effect.
hidden is a new global attribute introduced in HTML5. This means that browser support should be fairly good in modern browsers, though it will not be supported in IE8, and possibly IE9. As an aside, your use of the hidden attribute is probably incorrect.
This Boolean attribute indicates that the element is not yet, or is no longer, relevant. For example, it can be used to hide elements of the page that can't be used until the login process has been completed. The browser won't render such elements.
Your login form is not part of the page that is no longer relevant, but rather simply hidden as part of the presentation. You should therefore be using CSS for this instead. For more information, see:
Relevant MDN article: https://developer.mozilla.org/en/HTML/Global_attributes#attr-hidden
HTML5 specifications: http://developers.whatwg.org/editing.html#the-hidden-attribute
What you are doing is the same as doing:
<div hidden="true"></div>
However I would suggest you just do:
document.getElementById('question').style.display = 'none';