I have a problem with deep linking. I have a single page site, in which I have many small boxes and a single big boxes, that is the 'active' content. Clicking on a small box, I clear the innerHTML. Wtart an animation, the clicked become the active content, then I replace the innerHTML($('element').html('new content')) with the new content.
My question is: there is a way to deep link this process, to have:
mysite.com/firstcontent (or something similar) and have the right content active, without have to write a mega-switcher? have I to replace all with AJAX?
Typically this is handled by changing the hash (test.html*#foo*) in the window.location.
You can do this in conjunction with the hashchange event and window.history.pushState / replaceState You will need some sort of shim for older browsers. There is a jQuery plugin that will supposedly handle this for you.
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.
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'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.
On the page I am making, I need to use the jQuery UI accordion control twice. I am able to use it one time with no problems, but when I try to use it add another one on the same page, the first one stops working and the second one IS working.
Any ideas?
Link to the code
You cannot use the same ID in the same page - per W3C specifications. Depending on which browser renders the content - you won't get the same behavior. You need to use classes or custom attributes to trigger the accordion behavior. IE is one browser that will not handle elements with repeating element IDs (other browsers are more lenient with the spec).
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