I'm trying to make a link on a webpage to link to another website.
It works in Google chrome but in IE and FF it's not working.
When i hover the link in chrome, it shows in the left bottom cornor the correct link. When i hover it in FF and IE it shows the link of the page that i am currently on.
this is the code i have on my .apsx page
<div id="return">
<button>
<p><a id="ReturnBack" runat="server" href="http://www.stuff.be">Terug naar de site</a></p>
</button>
</div>
i even added some javascript to force it to redirect
$('#return button').click(function () {
alert("oke?");
window.location = 'http://www.stuff.be/Pages/Home.aspx';
});
The alert triggers when u click the link, just to check if it works
And when in IE in the f12 screen i can use window.location = 'http://www.stuff.be/Pages/Home.aspx'; to redirect it. So they both work seperatly but not in combo :s
Is there anybody who can help me?? i just spend 2 days on a silly link :(
This is probably confusing to the browser:
<button>
<p><a id="ReturnBack" runat="server" href="http://www.stuff.be">Terug naar de site</a></p>
</button>
A button which contains a paragraph and a link? I don't think buttons can contain links. (After all, when you click on the link, are you clicking on it or on the button?) This is probably invalid HTML, which means browser behavior is going to be undefined and browser-specific.
Don't use a button, just use a link:
<p><a id="ReturnBack" runat="server" href="http://www.stuff.be">Terug naar de site</a></p>
You can style the link to look like a button if you want. But structurally it can't be inside a button.
Then just change your jQuery selector:
$('#return a')
(Or, conversely, remove the link and keep the button? It's up to you. But it can't be both.)
Side note: This has nothing to do with ASP.NET. What you're using here is HTML and JavaScript.
You can't put a link inside a button.
Remove the button tags and script and it will work like a normal hyperlink in all browsers. You can style it to look like a button if you need that.
Alternatively, remove the <p> and <a> tag from within the button, and keep the click script...
I'm wondering about screen reader accessibility using Twitter Bootstrap framework and FontAwesome icon fonts.
I'm looking at 2 different icon situations:
1) The icon has helper text that a screen reader will pick up:
<span class="fa fa-pencil"></span> Edit
2) And a standalone icon without any helper text:
<span class="fa fa-pencil"></span>
Ideally, in both situations, a screen reader will announce that the element is an "Edit" button.
Per FontAwesome's site:
Font Awesome won't trip up screen readers, unlike other icon fonts.
I don't see any speech css tags related to FontAwesome or Bootstrap and not really clear to me how a screen reader will react to each of these situations.
I'm also aware of aria-hidden and Bootstrap's .sr-only and there has to be an ideal way to handle both situations.
Edit: added title="Edit to example 2.
What advantage does using aria-label="Edit" have over the standard title="Edit"?
Edit 2: I came across this article that explains pros and cons of different use implementations.
First of all, you should probably use <button> instead of <a href="#">. Empty links can be confusing for screen readers, but a button is a button. In short, links take you places, buttons perform actions. (http://www.karlgroves.com/2013/05/14/links-are-not-buttons-neither-are-divs-and-spans/; https://ux.stackexchange.com/questions/5493/what-are-the-differences-between-buttons-and-links).
I would go with a variation of your first code sample, and utilize Bootstraps .sr-only class. If we update your code with button and add in the class, we have:
<button type="button" class="btn btn-default"><span class="fa fa-pencil"></span> <span class="sr-only">Edit</span></button>
We now have a more semantically correct button element; sighted users see the edit pencil icon; and screen reader users will hear "Edit". Everyone wins.
(Note, the button code is straight from Bootstraps CSS Buttons section.)
From my understanding I think it may be useful to also add in:
aria-hidden="true"
to the span class that holds the pencil icon. This will prevent the screen reader from trying to read this element.
<span class="fa fa-pencil" aria-hidden="true"></span>
As part of making our site WCAG compliance we are adding play/pause buttons for carousel.Here the screen reader is reading in different manner
<div id="imageCarouselPlayBtn" class="cblt-button imageCarouselPlayBtn" tabindex ="0">
►
</div>
<div id="imageCarouselPauseBtn" class="cblt-button imageCarouselPauseBtn" tabindex ="0">
‖
</div>`
in this case screen reader is reading pause button as double vertical line and group for play button.
if we use sprite image instead it is reading as group for both play/pause buttons.
Is there any good solution for this problem instead of using image tags for both ?
You could use WAI-ARIA’s aria-label attribute:
It provides the user with a recognizable name of the object.
Also: Is there a reason why you don’t use button/input instead of div for the play/pause buttons? With buttons, your markup could look like:
<button type="button" aria-label="Play">►</button>
<button type="button" aria-label="Pause">‖</button>
I have a DIV tag. Inside the DIV, I have a Table and in a row, I have placed a script code which displays random images which on a click leads to a url.
This is how the script renders inside the Div Tag
<div>
<table>
<tr>
<td>
<script />
<a href="some random url">
<img></img>
</a>
...
When the user hovers over these images, the anchor url shows as a message on browser status bar. This is very misleading for users. I want to know how to use CSS to hide this status message - Cross Browser and display a custom message instead. On the Div, I have given onmouseout and onmouseover, however it does not help.
Can this be done?
See https://developer.mozilla.org/en/DOM/window.status :
This property does not work in default configuration of Firefox and some other browsers: setting window.status has no effect on the text displayed in the status bar. To allow scripts change the the status bar text, the user must set the dom.disable_window_status_change preference to false in the about:config screen.
This is a security feature that you can't realistically bypass.
common users dont know that they should look at that place in the browser window.
but you can hide that message... you can maybe just redirect with javascript
something like this:
<a href="javascript:void(0);" onclick="someredirectfunction('someurl');return false;" >
<img />
</a>
onmouseout and onmouse over are used for events for client side scripting. Those are used "mostly" for a language called ecmascript(javascript). You unfortunately will not be able to do what you are asking with CSS, css is desinged to represent the appearance of a site, HTML the form, and javascript (other scripting sources) the function.
I started using a diagnostic css stylesheet, e.g.
http://snipplr.com/view/6770/css-diagnostics--highlight-deprecated-html-with-css--more/
One of the suggested rules highlights input tags with the type submit, with the recommendation to use <button> as a more semantic solution. What are the advantages or disadvantages of <button> with type submit (such as with browser compatibility) that you have run across?
Just to be clear, I understand the spec of <button>, it has a defined start and end, it can contain various elements, whereas input is a singlet and can't contain stuff. What I want to know essentially is whether it's broken or not. I'd like to know how usable button is at the current time. The first answer below does seem to imply that it is broken for uses except outside of forms, unfortunately.
Edit for 2015
The landscape has changed! I have 6 more years experience of dealing with button now, and browsers have somewhat moved on from IE6 and IE7. So I'll add an answer that details what I found out and what I suggest.
When using <button> always specify the type, since browsers default to different types.
This will work consistently across all browser:
<button type="submit">...</button>
<button type="button">...</button>
This way you gain all of <button>'s goodness, no downsides.
Answering from an ASP.NET perspective.
I was excited when I found this question and some code for a ModernButton control, which, in the end, is a <button> control.
So I started adding all sorts of these buttons, decorated with <img /> tags inside of them to make them stand out. And it all worked great... in Firefox, and Chrome.
Then I tried IE6 and got the "a potentially dangerous Request.Form value was detected", because IE6 submits the html inside of the button, which, in my case, has html tags in it. I don't want to disable the validateRequest flag, because I like this added bit of data validation.
So then I wrote some javascript to disable that button before the submit occurred. Worked great in a test page, with one button, but when I tried it out on a real page, that had other <button> tags, it blew up again. Because IE6 submits ALL of the buttons' html. So now I have all sorts of code to disable buttons before submit.
Same problems with IE7. IE8 thankfully has this fixed.
Yikes. I'd recommend not going down this road IF you are using ASP.NET.
Update:
I found a library out there that looks promising to fix this.
If you use the ie8.js script from this library: http://code.google.com/p/ie7-js/
It might work out just fine. The IE8.js brings IE5-7 up to speed with IE8 with the button tag. It makes the submitted value the real value and only one button gets submitted.
Everything you need to know: W3Schools <button> Tag
The tag is supported in all major browsers.
Important: If you use the button element in an HTML form, different browsers will submit different values. Internet Explorer will submit the text between the <button> and </button> tags, while other browsers will submit the content of the value attribute. Use the input element to create buttons in an HTML form.
Pros:
The display label does not have to be the same as the submitted value. Great for i18n and "Delete this row"
You can include markup such as <em> and <img>
Cons:
Some versions of MSIE default to type="button" instead of type="submit" so you have to be explicit
Some versions of MSIE will treat all <button>s as successful so you can't tell which one was clicked in a multi-submit button form
Some versions of MSIE will submit the display text instead of the real value
From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button:
IE7 has a bug where when submitting a form with Click me, the POST data sent will result in myButton=Click me instead of myButton=foo.
IE6 has an even worse bug where submitting a form through a button will submit ALL buttons of the form, with the same bug as IE7.
This bug has been fixed in IE8.
An important quirk to be aware of: In a form that contains a <button/> element, IE6 and IE7 will not submit the form when the <button/> element is clicked. Other browsers, on the other hand, will submit the form.
In contrast, no browsers will submit the form when <input type="button"/> or <button type="button"/> elements are clicked. And naturally, all browsers will submit the form when <input type="submit"/> or <button type="submit"/> elements are clicked.
As #orip's answer says, to get consistent submit behavior across browsers, always use <button type="button" /> or <button type="submit" /> inside a <form/> element. Never leave out the type attribute.
I've had some experience with the quirks of <button> now, 6 years later, so here are my suggestions:
If you're still supporting IE6 or IE7, be very careful with button, the behavior is very buggy with those browsers, in some cases submitting the innerHtml instead of value='whatever' and all button values instead of just one and wonky behavior like that. So test thoroughly or avoid for those browser's sake.
Otherwise: If you're still supporting IE8, <a href='http://example.com'><button></button></a> doesn't work well, and probably anything else where you nest a button inside a clickable element. So watch out for that.
Otherwise: If you're using a <button> mainly as an element to click for your javascript, and it's outside of a form, make it <button type='button'> and you'll probably be just fine!
Otherwise: If you're using <button> in a form, be wary that the default type of <button> is actually <button type='submit'> in (most) cases, so be explicit with your type and your value, like: <button type='submit' value='1'>Search</button>.
Note that: Using a button-mimic class, like Bootstrap's .btn allows you to just make things like <div> or <a> or even <button> look exactly the way you want it to, and in the case of <a> have a more useful fallback behavior. Not a bad option.
TLDR; Ok to use if you don't care about ancient browsers, but Bootstrap provides even more robust css visually similar alternatives worth looking into.
Is it broken or not:
As usual, the answer is "it works fine in all major browsers, but has the following quirks in IE." I don't think it will be a problem for you though.
The <button> tag is supported by all the major browsers. The only support problem lies in what Internet Explorer will submit upon pressing a button.
The major browsers will submit the content of the value attribute. Internet exploter will submit the text between the <button> and </button> tags, while also submitting the value of every other one in the form, instead just the one you clicked.
For your purposes, just cleaning up old HTML, this shouldn't be a problem.
Sources:
http://www.peterbe.com/plog/button-tag-in-IE
http://www.w3schools.com/tags/default.asp
Here's a site that explains the differences:
http://www.javascriptkit.com/howto/button.shtml
Basically, the input tag allows just text (although you can use a background image) while the button allows you to add images, tables, divs and whatever else. Also, it doesn't require it to be nested within a form tag.
You might also run into these problems:
jQuery cannot target the button (not jQuery's fault, though): <button> in IE7
Multiple request variables if there are >1 <button>s: http://www.peterbe.com/plog/button-tag-in-IE
Another thing is related to styling it using the sliding-door technique: you need to insert another tag e.g. <span> to make it work.
as far as I am concerned the difference between submit and button tags is this:
gives you the option to have different text displayed than the element's value
Let's say you have a list of products then next to each product you want a button to add it to the customer's cart:
product1 : <add to cart>
product2 : <add to cart>
product3 : <add to cart>
then you could do this:
<button name="buy" type="submit" value="product2"> add to cart </button>
Now the problem is that IE will send the form with value="add to cart" instead of value="product2"
The easiest way to workaroound this issue is by adding onclick="this.value='product2'"
So this:
<button name="buy" type="submit" value="product2" onclick="this.value='product2'"> add to cart </button>
will do the trick on all major browsers - I have actually used this on a form with multiple buttons and works with Chrome Firefox and IE
Looks like the main reason to use <button> is to allow for CSS markup of that button and the ability to style the button with images: (see here: http://www.javascriptkit.com/howto/button.shtml)
However, I think the more adopted approach I've seen in (X)HTML + CSS is to use a div and style it completely with images and :hover pseudo-classes (simulating button downpress... can't add more than one link per answer, so just google "div button" you'll see lots of examples of this), and using javascript to do form submission or AJAX call... this also makes even more sense if you don't use HTML forms, and do all submissions with AJAX.