I'm creating a web app that has a list of commands that change elements on a single page. The page is 100% dependant on JavaScript. I therefore coded these links as:
Command #1
Doubting that this is semantically correct, I found numerous places stating that I should use a button instead.
This makes sense, but means I have to alter the style of a button to look like a link, which feels hacky. Is this the correct method?
The style you give to the element is irrelevant to whether or not it's semantically correct code, so I wouldn't worry too much about that.
Links are meant to, well, link the user between pages on the web.
HTML Input elements are meant to take user input and do things with them.
Based on this simple heuristic, I'd say go with a button!
The HTML5 spec is pretty clear in that you shouldn't use a:
If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor).
The definition of "hyperlink" is:
These are links to other resources […]
So don't use a for "actions" on your single page web app.
You should go with button or resp. input (I'd say both with type value of button).
If you like to dive into newer HTML5 stuff, take a look at menu and command.
Just to be sure: you shouldn't "enhance" other elements (like span or div) with JS to act like links/buttons. This wouldn't be accessible without further work, if at all.
Both are technically fine to use. For me, if it is a text link, then I'd use the <a> tag and if it is a form button or image, use <button>. That way you are consistent with what the elements intended uses are.
I don't think using links is semantically incorrect. If it makes you feel better, you can style your links as buttons.
Otherwise, if that still rubs you the wrong way, there's nothing wrong with styling a button to look like a link. The functionality of your app should have little to do with how you present your buttons, as long as they do the same thing and fit within your expectations.
As mentioned in the comments, if you wish to use buttons, bear in mind that they style as form elements and can be more difficult that working with an anchor tag.
Generally i prefer using div's for these things. Links come with a lot of inherent browser styling, even more so for buttons. Div's only rule is display:block. So it's saves me some reset css lines. Also it saves me some js code to prevent default behaviour. Add that to the fact that there is no correct semantic choice, then using div's makes a lot of sense.
Related
I am building a website and have previously built navigation using both buttons and anchors. I am confused which one to use for tabbed navigation.
I have looked at this question/answer which essentially came down to:
Use <a> when you are redirecting to another page as this is the intended use of a hyperlink.
Use <button> to carry out an action like a form submission, or to execute a function.
This makes a lot of sense to me, but my particular site is an app with tabbed navigation. I have a few pages that are being built by manipulating the DOM, but the site link remains the same, and the navigation is actually just replacing existing dom elements with new ones.
In this case, is it better to use buttons for navigation, or should I just always stick to anchors even if they aren't "redirecting" the page traditionally? I know that some of the differences are just subjective, such as the out of the box styling differences, but are there considerable drawbacks for using one over the other in tabbed navigation?
Semantically speaking, this sounds like same-page navigation to me. As per standards, use the <a> element for this purpose. Then add an event listener for any JavaScript side effects.
Read the standards of the <a> element here - on whatwg.org.
Read about the <a> element on the MDN documentation - here.
Hope this helps.
Imagine that there's a button on one web page (not mine) and when it's clicked it performs some
Javascript. I want to have a button on my web page that performs exactly the same. So I need to
attach all necessary js files (but first I have to find them) to my html page and sometimes add some js to my html page.
What I usually do in this case? I inspect this button html element to see if there's onclick attribute for this button. If it is, I see the function called when button is clicked and then I try to search for this function in current html page and all js files attached to page. Also I need to find all dependencies (like jQuery, fancybox etc.).
If the button doesn't have onclick attribute I have to look for direct getElementById or jQuery selector pointing to this button with rest of code there. Sometimes there's no such a selector and I have to find a nested selector - really hard and annoying thing.
Is there any better, automated way for doing things above. Ideally after selecting the element in DOM (button in this case) and pressing some magic button I will be able to see all js files involved in processing this click and also js code in html page.
It's going to involve digging no matter what you do. But Chrome's Dev Tools can help with the attached event handlers, to an extent. When you right-click an element and inspect it, on the right-hand side there's a panel showing various tabs: [Styles] [Computed] [Event Listeners] [DOM Breakpoints] [Properties]. The [Event Listeners] one shows the listeners directly attached to that element. Of course, on a site using jQuery (which is more than half the sites using JavaScript at all), looking at the handler will dump you into the jQuery event handling code, but it's a start.
Just as a side point: While it's fine to look at the source of pages for inspiration, or to see how they solved a particular problem, or what plugins they're using to get an effect, etc., I assume you're not grabbing large sections of their actual code (as opposed to libraries and plugins with liberal licenses) without their permission, which is probably not cool.
Is there a preferred way or advantages to using one over the other ?
i.e.
You can have a hyperlink a where the href points to # with a class or id and then javascript that looks for that elements on-click event.
You can have a simple div or span that has a class or id and bind the javascript on-click to that element.
I have seen both done.
Context is ruby on rails applications that are using javascript for some functionality.
I think the main advantage of using <a> tags is that the default behavior (when including an href) is that the browser cursor signifies an link. Although both can be done, using the <a> tag is also more semantic.
Constructing semantic markup is a staple of good design. By using anchors to signify navigation, you are sticking to the specification. The perfered way would be what the spec outlines, if you need to deviate I would make sure your changes are justified.
One advantage for preferring an anchor tag is screen reader software for the blind will parse the DOM for anchors to help users navigate on the page. By using div's or span's the nav links will be overlooked.
This is more of an HTML question than javascript.
A elements are simple, work in every browser and are utterly reliable whether scripting is available or not.
Browsers support A elements through context menu features to open them in new windows or tabs
A elements have a default presentation in browsers that lets users know they are links without any other scripting or styling support required
Different browsers may present links slightly differently, so users get used to seeing them behave in the particular way their browser presents them. Scripted and styled other elements likely will present in an unfamiliar way to at least some users.
Browsers offer features to support A element links such as tab navigation between links and separate lists of links in the page.
Screen readers and other support mechanisms for accessibility understand A element links and can present them to their users
Browsers typically present the destination of an A element link to a user so they can decide whether to follow the link or not
A element URLs are easily copied and shared without following the link
A elements can be used to create bookmarks without following the link
Scripted and styled links do not have any of the above features, or at least require significant additional effort to support any of them.
I like to write code which actually means something. I generally achieve this by using the most appropriate (semantically speaking) elements.
I use the a element when the purpose is to navigate in the application. To quote the spec:
Links are a conceptual construct [...] that represent a connection between two resources
For other cases, it depends. But I usually use the button element
div are by definition meaningless, you should avoid them for this kind of purpose. To quote the spec:
Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable.
If it's a JavaScript-only link then it doesn't matter what element you attach it but using an <a> gives you built-in link/hover/visited styles whilst being semantically correct. However, the biggest reason for using an actual link is the ability to have a fall-back for browsers without JS enabled.
For example, you could have a link which loaded the next 10 results by ajax if possible else server-side if the link is followed.
<a id="nextByAjax" href="?next=10">Next 10</a>
I have an anchor tag in my application that has the sole purpose of firing some javascript to expand/collapse some panels. I was thinking about changing it to be a span with a click handler instead. Which is the best method:
Toggle Panels
OR
<a onclick="togglePanels()" href="javascript:void(0);">Toggle Panels</a>
OR
<span onclick="togglePanels()">Toggle Panels</span>
Or is there a better option that I have not included?
I would use a <button>. You can style it accordingly with CSS, but the semantic meaning is still preserved.
But if the user disables JavaScript, the button becomes useless and users might get confused.
If your site works with JavaScript only anyway, then this would be ok, but if it also works without, you better add it programmatically or hide it initially with CSS.
Update:
Don't forget to set type="button". By default a button is a submit button for a form, so omitting the type attribute would make it some kind of invalid outside of a form (although it would still work).
A common progressive-enhancement approach is to make your anchor an actual anchor link... if JS is not available, clicking the link will just bring the panels (which you can place down below, in the flow of the document, and hide on dom-ready/load when JS is available) to the top.
Toggle Panels
<div id="panels"><!-- your panels--></div>
Then in your click handler for #panelToggler, first use e.preventDefault() so it won't try to pull the anchor to the top, then include the logic to toggle the panels.
If you don't care about users without JS being able to use whatever is in the panels, then don't even show them the toggle panels control at all. Even if it doesn't look like a link, it is really janky to just have a non-working "toggle panels" line of text sitting there in your UI. In this case, it really doesn't much matter what element you hang the functionality on for the JS-enabled users... button is appropriate, but a is generally more flexible with styling options. Take a look at most of the buttons in GMail... they're clusters of nested divs.
I prefer to define a span element without any handler attributes, and then wire up any handlers in a separate script file. In my case, I have many different span elements with the same toggle expansion behavior, so giving them all the same class, like "expand", allows me to wire them all in my document loaded method using a class selector.
The better option would be using unobtrusive JavaScript:
var element = document.getElementById("#anchorId");
element.onclick = togglePanels;
A jQuery approach also helps a lot:
$("a").click(togglePanels);
But of course I think that it's nice as an anchor, since you can still have an href pointing to something in case the user isn't with JavaScript enabled.
Yes, if the element is in your original markup, the span is better. This is in the interest of some semblance of graceful degradation; users who don't have JavaScript enabled will still get the impression they can interact with the hyperlink, which they cannot.
The truly idealized unobtrusive solution would be to not include the element in the markup at all, and add it programmatically using JavaScript.
At the very least, you should not use the javascript: protocol in a hyperlink reference. Aside from challenges some might make that it is an improper use of hypertext references (hyperlinks should reference documents or resources, not define behavior) it poses a few technical challenges; for example, you don't have access to the anchor element via this.
I learned that a anchor will make the browser "ready to launch" when focused. Meaning some resurses will used. But I think transparency is important: http://www.javascripttoolbox.com/bestpractices/#onclick
Mike
I have got a table, and it has a label in one of its containers, what I want is so when the user clicks on that label it will turn into a optionbox with options and the user can select one then when he clicks out it will switch to the label he chose.
I am assuming this can be done in Javascript.
Something like this? It's just a quick-and-dirty JavaScript implementation, so if you have other, specific requirements, feel free to add to the question.
Yes, you can do this in JavaScript.
Here is a small, self-contained example that shows the answer using the javascript framework jQuery. If you are going to be heavily into Javascript on your page, I recommend using a framework.
Here is that same example using no Javascript frameworks.
Both examples rely on providing a class to a div containing the label/select indicating whether it is currently a label or a select. Both use a click handler on the whole document and a click handler on the label/select.
I highly recommend you digging into events and handlers in Javascript as well as the Document Object Model (DOM) if you already haven't to understand how this works.