Simply out of curiosity - I have been nailed in my previous question for trying to put button within an anchored image. I looked at documentations and other questions and although everyone is saying that it should not be done, they are not saying why.
Even the documentation http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element states that there should be no interactive content within anchor, but does not tell me the reasoning.
Does anyone know why is it such a horrible practice to do so?
Imagine that situation:
<a href="http://google.com">
<select>
<option>V1</option>
<option>V2</option>
</select>
</a>
Now when you press on select element these actions will take effect (in order):
Open select dropdown.
Bubble click event to parent (<a> in this case).
<a> element follows it's href value (at this point you leave current page).
(after some delay by human body) You would select desired option (but you had already left website)
Related
I see these lines of code in some professional developer's project:
<a href="###">
...
</a>
What is the use of three # instead of one?
That's usually written when you want your anchor tag to not change the href. For instance if you want to attach an event on it later on.
It doesn't matter how many # you are using. The href='#' will make the page jump to the top of the page if clicked.
My preferred way is doing <a href="javascript:void(0);". That way the click does absolutely nothing, instead of jumping the page up.
The first thing about "anchor tags"...
This use of ### in particular is to create a links that don't go anywhere, and to do that the href attribute must have a value. Please read the href W3C spec page for more info about that.
Browsers render default styles for elements and will change the default style of an anchor tag that doesn't have the href property. Instead, it will be considered like regular text. It even changes the browser's behavior with regard to the element. The status bar (bottom of the screen) will not be displayed when hovering an anchor without the href property. It is most optimal, then, to use a placeholder href value on an anchor to ensure it is treated as a hyperlink.
I've often seen <a href="#">, and <a href="##"> , a hashtag - # within a hyperlink specifies an html element id to which the window should be scrolled.
href="#some_id" would scroll to an element on the current page such as <div id="some_id">.
href="//example.com/#some_id" would go to example.com and scroll to the id on that page.
href="#" doesn't specify an id name, but does have a corresponding location - the top of the page. Clicking an anchor with href="#" will move the scroll position to the top.
So, when you use <a href="###"> this create a links but it doesn't go anywhere. You can use it from "##","###" and more of hashtag to create a links like a "Hyperlinks" but they take you nowhere.
My Conclusion:
So, what is the use of it?
You use it when you need a hyperlink that doesn't go anywhere. It's just to tell the browsers to change the style to an anchor tag.
Check this JSFiddle demo
As Bhuiyan's answer said, it is a variation on the href="#" trick...
Goal
So, to explain that trick. The trick is to work around the fact that Anchor tags are only rendered as links if they have a target to link to (see this example). The goal is to create a link that looks like a link, but doesn't actually go anywhere.
How it works
The href="#" idiom is taking advantage of the fact that anchors can specify a specific element as a target by using the href="#{other element identifier}]" notation. When you do this the browser will not redirect or reload the page, but instead scroll to that element. So when you specify href="#" you are essentially telling the browser that this is a link, but since there is no valid target element please don't do anything when it is clicked.
Note: It would work just as effectively to say href="#mybogusid" but then you would see #mybogusid appended to the url. Gross.
TL;DR of it all: <a href="###"> is just a way to make the browser render the anchor tag like a link, but not navigate anywhere on click.
I think this is same as Go to link that person just used three "###" instead of one "#". we can use more # if we want.
It was very useful when i had button and js click event. With '#' it scrolled to top every time i pressed the button, but with '###' it stayed in place as needed!
Chrome/Opera users in Windows: wrap the following lines in any valid html skeleton:
<a id = "a" href="http://www.google.com">http://www.google.com</a>
<br />
Some text THEN a link <a id="b" href="http://www.google.com">http://www.google.com</a>
<br />
<a id="c" href="http://www.google.com">http://www.google.com</a> A link THEN some text
<br />
Now, putting the mouse aside and using only tab and the the context key/menu key/application key*, attempt to "save link as". The first and third fail and attempt to save the current page.
The second works as it should. Additionally, if I use a css reset library like normalizr, it fails on all of the links.
In IE and Firefox, all links behave as they should. This only happens in blink-based browsers.
*(call it what you will, it's the image of a mouse pointer pointing at a context menu, usually bottom right of a keyboard's alpha section and is relied on by keyboard users and blind/screenreader users).
Chromium have removed the "bug" tag on my ticket and say the desire for consistent behaviour, not just between mouse and keyboard, but even between placement of links on a line, is a "feature request".
As well as assembling a small army of blind users to explain why excluding them sucks, I'm hoping to put together rock solid technical proof too.
The trouble is, after almost the entire morning, I can't find a way of "diff"-ing the two DOM elements to find out what causes one to work and one to fail.
There are many stackoverflow answers that point to something like:
var a = document.getElementById("a");
var b = document.getElementById("b");
alert( a.isEqualNode(b) );
But it doesn't help me much anyway. The trouble is, drilling down through all the event properties, listeners, elements, styles etc seems to be an endless task - on the "blur" listener alone there appear to be almost infinite levels of property. As you can tell, I'm a but out of my depth at this point.
tl;dr version of my question
Is there any way of taking everything the DOM/browser knows about an element, and comparing it with what should be an identical element?
Clarification
This is a question relating to accessibility for users relying on keyboard-shortcuts solely affecting browsers built round the blink rendering engine. This relates to DOM, not javascript. Please consider the question carefully before removing those three essential tags or adding other irrelevant ones. Thank you.
Probably a silly questions, but I'd like to have a hyperlink withing another hyperlink, much like a
<a href="#somewhere">
This is the hyperlink,
and this is the other one
</a>
Aside from that it's not compliant and all, is there a way of doing this?
*Edit: the outer hyperlink is used by a carousel, and won't take the browser somewhere.
Lets think about this. What is the browser suppose to do?
Go to the first hyperlink, or the second one, or both?
If you want the first one, then the second hyperlink is not required.
If you want the second one, then close the first one before and reopen if necessary after closing the second.
If both then write some Javascript to get it to open a new window. for the second hyperlink before loading the first hyperlink.
Anchor tags, just like inline or block level elements, layer up on top of each other when nested such that attributes can be set for different subsets of information or visual space within them. This may be useful if you have a large anchor element functioning as a large button, but want to insert a link to a different location within that button.
Have you tried implementing it? See this jsFiddle proving that nested inline elements work, both with span and anchor tags. Note that the nested element overrides the clickable area subset within the parent element, just as you'd expect it to if you were listening for a hover event.
Disclaimer: While technically this can be done, that doesn't mean that it should be done. Nesting links in particular can result in user confusion and be misleading about what content is pointing to what locations.
You can't nest it, but you can do something I did below..
<a href="somewhere">
This is the hyperlink,</a>
and this is the other one
May be you solution:
<form action="http://myhomepage.ru/" method="get">
second link within
<button>first link</button>
</form>
I've read various posts on this subject and think I understand the usual points of failure. I find that my two product thumbnail images, under the "This Click'n'Pick Set Consists Of The Following 2 Products" heading, are clickable, but do not take me to the named <div> element further down the page. Instead, they cause navigation to http://www.premierrange.co.uk/#bundle_product_anchor_448, for example. I see this both in Chrome (18.0.1025.33 beta) and Firefox (10.0.1) on Linux.
http://www.premierrange.co.uk/index.php?main_page=clicknpick&groups_id=2&chosen_0=243&chosen_1=448
So for example there's an anchor targeting '#bundle_product_anchor_243':
<a href="#bundle_product_anchor_243" title="Click here to jump to the 70cm Truly Curved Black Glass Curved Cooker Hood H77-7B">
<img src="http://www.premierrange.co.uk/thumbnailer.php?filename=images/H77-700.jpg&height=100" alt="70cm Truly Curved Black Glass Curved Cooker Hood H77-7B">
</a>
This targets the <div> further down the page:
<div class="productSeparator" id="bundle_product_anchor_243">
<h1>Product number 1 in this bundle of 2 products</h1>
</div>
I've also tried making the <h1> inside the target <div> be the target instead, in case the target must be an inline element rather than a div, but nothing seems to work.
The <div> containing the badly behaving <a> is completely closed by the time the <div> containing the target element appears in the document. I don't think there's a problem with the target element not being defined at the point in time the <a> is parsed by the browser.
Manually adding "#bundle_product_anchor_448" to the URL does work.
I am aware that the page fails HTML validation on a large number of points, due to a large number of factors that I'm not going to be able to address easily. I'd have thought this basic 'jump to a named element' functionality should work regardless. The page is completely functional other than this little navigation quirk.
Anyone got any clues?
Try removing <base href="http://www.premierrange.co.uk/"></base> from the page header.
The <base> tag specifies the base URL or target for all relative URLs (the ones that don't say http://www.example.com/...) on your page. Without it, your link should function as intended though you may have to fix other links to accommodate this change.
While using the <base> tag in your application, the best approach would be to just use absolute URL's before the hash, with the absolute URL pointing to the same page you're in.
So, assuming that you are on the 'http://example.com/products/curved-glass' page, instead of
<a href="#bundle_product_anchor_243">...
you would need to include the absolute current URL before the hash:
<a href="http://example.com/products/curved-glass#bundle_product_anchor_243">...
Finding out the current URL is a trivial task in most of the environments, and this method also avoids the removal of your <base> tag, action which might have negative consequences in other areas of your application.
Is there any alternative to <div>? My website is losing "accessibility" because I cannot set focus on a <div>. What control should I use in order to replicate <div> and still hold focus?
This is what my HTML looks like:
<div style="height:70px; overflow:hidden" id="divMsg">
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
<div class="DivClass">abcdefg abcdkfjghfjdfkj</div><br>
</div>
You can add tabindex to make it focusable; however, this is usually not enough. If you want the element to be clickable, you will also need to add a keydown or keypress handler so that the user can activate it using ENTER, similar to a A link. Otherwise the user will be able to tab to it, but may not be able to do anything with the link after.
If you are trying to create a clickable element, it is sometimes simpler to start with a A tag, and then style it so that doesn't look like a link. A elements respond to both keyboard and mouse and fire onclick for both, so you don't have to do additional keyboard input handing like you do with a DIV.
Finally, if you are making a DIV or A that visually looks like a button or some other control, add the appropriate ARIA role so that a screenreader will call out the appropriate element type - eg.
Complete Transaction
Just give it a tabindex attribute.
If you are specifically looking for accessibility, try out the new HTML 5 tags like <article>. So for example a textreader knows what to read, and your page is much better structured.
Check out this site.
To answer your exact question, it depends why you are using the div; I'm guessing for layout. The tab ordering is dependent upon more than tabindex, as defaults and overflow affects positioning and focus.
To be more specific, you won't use a div to latch onto for tabindex. Rely upon JavaScript and a unique ID; <div class="content" id="page1">
This will also provide you an anchor so you could use http://index.html#divMsg to link focus to the exact place in your HTML document. Note you have only one div ID and reuse the same div class twice in your example.
If this is all new to you the article on difference between ID and CLASS may be of interest to you
Links (element a) and form elements (input text and alike, file, radio and checkbox, submit, image and type button, select, textarea, button element, etc) are focusable by default.
Thumb rule: if an element does something, it should be a link or a form element part of a form. (OT: I guess I've a problem with conjugation here but can't find exactly what - english isn't my mothertongue)
Think twice (at least :)) before using the tabindex attribute: it'll work for a while in your project and then you make some modification elsewhere and suddenly all is broken. And it'll break again, again and again.
For testing with Safari, you'll need to modify Preferences: this browser (maybe also Chrome?) only cycle by default through form elements and not links. Users of keyboard cycle through every focusable elements I guess, like in IE and Firefox.
To learn further, Web Content Accessibility Guidelines 2.0 (WCAG 2.0) have Sufficient Techniques (and "Failure(s)" also) about keyboard use.