The <noscript> tag can be used to display a message if the user has scripting turned off - but is there any way in which it can be used to contain a conditional (html) statement, or more complicated coding?
Edit: Sorry, perhaps I wasn't clear; I have nothing against the noscript tag itself - but was wondering about the upward limitations of its usage? As far as I have seen, its usage has been merely to tell people to turn scripting on. I'm thinking about potential in terms of accessibility.
What's wrong with <noscript>? It can contain anything you'd want. From entire layouts, to <style> elements to a big fat warning message.
Obviously, you can't use JavaScript inside of it, but aside from that, you can do anything.
You could do this:
<div id="removeIfJS">Sorry, but javascript is disabled</div>
<script>
var sorry = document.getElementById("removeIfJS");
sorry.parentNode.removeChild(sorry);
</script>
Stick to the noscript tag because it's the standard method to solve things. Search engines knows how to deal with it, screen readers know to deal with it and people that have turned javascript off will see a fancy warning/message (with some CSS).
BTW: You cannot do any fancy stuff if scripting is turned off as well.
In a noscript tag you can use all elements that are allowed directly in a body tag. See the link you provided for details.
Related
I am working on some pretty old code and in every jsp file where there is a javaScript block I see some bizarre Syntax. It goes like :
<script language="JavaScript">
<!--
here is the main code (mixed jsp and javaScript)
//-->
</script>
neccesity <!-- code here //-->
I don't find any necessity for <!-- //--> this syntax. But to remove these from the whole project I really have to be sure why these syntax was used.
Does those had any significance previously, I mean for browser issue or something?
Or,
Just a simple mistake which were carried on.?
HTML style comments in javascript date back to a time when not all browsers supported javascript, so would render the code as text. The <script> tag was just assumed to be just like any other unknown tag, so the tag itself was not rendered, but the contents were
I don't think any current browser would have a problem with it, but I would recommend getting rid of it, because who knows what the future will bring
Does those had any significance previously, I mean for browser issue or something?
Yes, it used to. Remember that a script tag embeds non-HTML inside an HTML document, in this case JavaScript code. Since the content of the script tag isn't HTML, but is being parsed by an HTML parser (while it looks for the ending tag), the idea was to use an HTML comment (<!-- ... -->) to contain the JavaScript code, so the HTML parser wouldn't get confused by HTML-like things within the JavaScript code, and so really old browsers that didn't understand script tags at all wouldn't show the "text" inside them.
The one you've quoted is one of many variations.
There's no need, at all, to do this in an HTML document, with modern browsers — or even with really old browsers, at this point.
In an XHTML document, you do need to do something, but what's shown there is likely to be insufficient; you'd need a CDATA section instead.
Assuming you're writing HTML5 documents (<!doctype html>), you can remove those comments from the JSPs.
As stated here: http://www.w3schools.com/tags/tag_comment.asp
You can also use the comment tag to "hide" scripts from browsers without support for scripts (so they don't show them as plain text)
Nowadays not really an issue I suppose. But may not be the best idea to get rid of them.
Those are comments, just removed if no documentation comments are there
Back in the days there were all sorts of tricks used to make sure that the content looked decent even if the user had javascript or cookies disabled.
This looks like it was meant for hiding the javascript, if the browser didn't understand Javascript.
I am creating a website for a University assignment and we have to concentrate on the accessability functions. I have successfully managed to use resize text buttons but am looking for a way to turn off a css file via a button or link.
I have scoured the net and cannot seem to find very much, I found a good website that had the button I am looking for so hit F12 but it would not display the javascript for it.
Ideally I would like to achieve it without the use of javascript but if there is no other way then I am open to any help that I can get.
I am sorry if this is a simple question but I really did look hard for an answer but to no avail, I am only a first year student so have a long way to go!
This should work
for ( i=0; i<document.styleSheets.length; i++) {
void(document.styleSheets.item(i).disabled=true);
}
Here's a good way to do it quickly from javascript:
Precede all of your CSS rules with the tag body.enabled:
body.enabled p {
}
body.enabled #Myselector {
}
...
Declare your markup as such:
...
<body class="enabled">
...
</body>
...
In your JavaScript, when you want to disable CSS, remove the class "enabled" from the <body> and switch it with something else (say, "disabled"). Use whatever methodology you see fit to do this (jQuery would make this easy, but it can be done without)
You're not really disabling CSS using this, you're just making it so that none of it applies. From a user's standpoint, they likely won't know the difference.
You can do it server side when the user clicks on a "special" link, your server side code simply "skips" the stylesheets elements.
Are you trying to mimick every feature already designed in browsers (T+, T-, no CSS)? Were you asked to make an accessible website or specifically to implement accessibility features? I understand this is an assignment but that's quite a waste of time IMHO, a time that would be better spent on implementation of WCAG 2.0 recommendation. (I use the "Accessiweb" methodology a lot).
My first idea was to deconstruct existing CSS like Universal IE6 does for IE6 (you just have to remove the conditional comments and aim to every browser) but #kappa solution seems better as in both cases you must have access to source code.
In the 1990s, there was a fashion to put Javascript code directly into <a> href attributes, like this:
Press me!
And then suddenly I stopped to see it. They were all replaced by things like:
Press me!
For a link whose sole purpose is to trigger Javascript code, and has no real href target, why is it encouraged to use the onclick property instead of the href property?
The execution context is different, to see this, try these links instead:
Press me! <!-- result: undefined -->
Press me! <!-- result: A -->
javascript: is executed in the global context, not as a method of the element, which is usually want you want. In most cases you're doing something with or in relation to the element you acted on, better to execute it in that context.
Also, it's just much cleaner, though I wouldn't use in-line script at all. Check out any framework for handling these things in a much cleaner way. Example in jQuery:
$('a').click(function() { alert(this.tagName); });
Actually, both methods are considered obsolete. Developers are instead encouraged to separate all JavaScript in an external JS file in order to separate logic and code from genuine markup
http://www.alistapart.com/articles/behavioralseparation
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript
The reason for this is that it creates code that is easier to maintain and debug, and it also promotes web standards and accessibility. Think of it like this: Looking at your example, what if you had hundreds of links like that on a page and needed to change out the alert behavior for some other function using external JS references, you'd only need to change a single event binding in one JS file as opposed to copying and pasting a bunch of code over and over again or doing a find-and-replace.
Couple of reasons:
Bad code practice:
The HREF tag is to indicate that there is a hyperlink reference to another location. By using the same tag for a javascript function which is not actually taking the user anywhere is bad programming practice.
SEO problems:
I think web crawlers use the HREF tag to crawl throughout the web site & link all the connected parts. By putting in javascript, we break this functionality.
Breaks accessibility:
I think some screen readers will not be able to execute the javascript & might not know how to deal with the javascript while they expect a hyperlink. User will expect to see a link in the browser status bar on hover of the link while they will see a string like: "javascript:" which might confuse them etc.
You are still in 1990's:
The mainstream advice is to have your javascript in a seperate file & not mingle with the HTML of the page as was done in 1990's.
HTH.
I open lots of links in new tabs - only to see javascript:void(0). So you annoy me, as well as yourself (because Google will see the same thing).
Another reason (also mentioned by others) is that different languages should be separated into different documents. Why? Well,
Mixed languages aren't well supported
by most IDEs and validators.
Embedding CSS and JS into HTML pages
(or anything else for that matter)
pretty much destroys opportunities to
have the embedded language checked for correctness
statically. Sometimes, the embedding language as well.
(A PHP or ASP document isn't valid HTML.)
You don't want syntax
errors or inconsistencies to show up
only at runtime.
Another reason is to have a cleaner separation between
the kinds of things you need to
specify: HTML for content, CSS for
layout, JS usually for more layout
and look-and-feel. These don't map
one to one: you usually want to apply
layout to whole categories of
content elements (hence CSS) and look and feel as well
(hence jQuery). They may be changed at different
times that the content elements are changed (in fact
the content is often generated on the fly) and by
different people. So it makes sense to keep them in
separate documents as well.
Using the javascript: protocol affects accessibility, and also hurts how SEO friendly your page is.
Take note that HTML stands for Hypter Text something something... Hyper Text denotes text with links and references in it, which is what an anchor element <a> is used for.
When you use the javascript: 'protocol' you're misusing the anchor element. Since you're misusing the <a> element, things like the Google Bot and the Jaws Screen reader will have trouble 'understanding' your page, since they don't care much about your JS but care plenty about the Hyper Text ML, taking special note of the anchor hrefs.
It also affects the usability of your page when a user who does not have JavaScript enabled visits your page; you're breaking the expected functionality and behavior of links for those users. It will look like a link, but it won't act like a link because it uses the javascript protocol.
You might think "but how many people have JavaScript disabled nowadays?" but I like to phrase that idea more along the lines of "How many potential customers am I willing to turn away just because of a checkbox in their browser settings?"
It boils down to how href is an HTML attribute, and as such it belongs to your site's information, not its behavior. The JavaScript defines the behavior, but your never want it to interfere with the data/information. The epitome of this idea would be the external JavaScript file; not using onclick as an attribute, but instead as an event handler in your JavaScript file.
Short Answer: Inline Javascript is bad for the reasons that inline CSS is bad.
The worst problem is probably that it breaks expected functionality.
For example, as others has pointed out, open in new window/tab = dead link = annoyed/confused users.
I always try to use onclick instead, and add something to the URL-hash of the page to indicate the desired function to trigger and add a check at pageload to check the hash and trigger the function.
This way you get the same behavior for clicks, new tab/window and even bookmarked/sent links, and things don't get to wacky if JS is off.
In other words, something like this (very simplified):
For the link:
onclick = "doStuff()"
href = "#dostuff"
For the page:
onLoad = if(hash="dostuff") doStuff();
Also, as long as we're talking about deprecation and semantics, it's probably worth pointing out that '</a>' doesn't mean 'clickable' - it means 'anchor,' and implies a link to another page. So it would make sense to use that tag to switch to a different 'view' in your application, but not to perform a computation. The fact that you don't have a URL in your href attribute should be a sign that you shouldn't be using an anchor tag.
You can, alternately, assign a click event action to nearly any html element - maybe an <h1>, an <img>, or a <p> would be more appropriate? At any rate, as other people have mentioned, add another attribute (an 'id' perhaps) that javascript can use as a 'hook' (document.getElementById) to get to the element and assign an onclick. That way you can keep your content (HTML) presentation (CSS) and interactivity (JavaScript) separated. And the world won't end.
I typically have a landing page called "EnableJavascript.htm" that has a big message on it saying "Javascript must be enabled for this feature to work". And then I setup my anchor tags like this...
<a href="EnableJavascript.htm" onclick="funcName(); return false;">
This way, the anchor has a legitimate destination that will get overwritten by your Javascript functionality whenever possible. This will degrade gracefully. Although, now a days, I generally build web sites with complete functionality before I decide to sprinkle some Javascript into the mix (which all together eliminates the need for anchors like this).
Using onclick attribute directly in the markup is a whole other topic, but I would recommend an unobtrusive approach with a library like jQuery.
I think it has to do with what the user sees in the status bar. Typically applications should be built for failover in case javascript isn't enabled however this isn't always the case.
With all the spamming that is going on people are getting smarter and when an email looks 'phishy' more and more people are looking at the status bar to see where the link will actually take them.
Remember to add 'return false;' to the end of your link so the page doesn't jump to the top on the user (unless that's the behaviour you are looking for).
I was thinking about Web standards, and i was wondering if we need to have valid HTML and CSS before we apply JavaScript?
Can anyone enlighten me on the relation between valid HTML, CSS and JavaScript?
For instance, does invalid HTML and CSS prevent JavaScript from working correctly?
As much lip service as we pay to having valid HTML, browsers are extremely forgiving. The reasons for this are historical. There was (and still is) a lot of bad HTML in the beginning.
But you may get unpredictable differences between browsers with badly formed HTML. For example, different browsers may treat an unclosed tag differently.
All the markup causes to happen is to form a DOM (Document Object Model) in the browser based on how that browser interpreted it. CSS and Javascript are both applied to the DOM.
I disagree with the above responses: I have had very bad times hunting through apparent javascript bugs before I remembered to validate the page I was working on. As soon as I corrected the glaring errors, the scripts worked as intended.
The most obvious problem (not one I have experienced, because I already look for that): have two elements with the same id attribute, and try to make your script that depends on that to work as intended :)
While it may be true that the level of validation needed is somewhat low, when you are banging your head against the table because your website doesn't work and you don't know why, you'll remember this fondly.
I have been using a noscript tag to show a warning when users have JavaScript disabled or are using script blocking plugins like Noscript. The website will not function properly if JavaScript is disabled and users may not figure out why it is not working without the warning.
After the latest Google algorithm shuffle, I have seen the daily traffic drop to about 1/3 of what it was in the previous months. I have also seen pages that were ranking #1 or #2 in the SERPS drop out of the results. After doing some investigating in webmaster tools, I noticed that "JavaScript" is listed as #16 in the keywords section. This makes no sense because the site has nothing to do with JavaScript and the only place that word appears is in the text between the noscript tags.
It seems that Google is now including and indexing the content between the noscript tags. I don't believe that this was happening before. The warning is three sentences. I'd imagine that having the same three sentences appearing at the top of every single page on the site could have a damaging effect on the SEO.
Do you think this could be causing a problem with SEO? And, is there any other method to provide a warning to users who have JavaScript disabled in a way that won't be indexed or read by search engines?
Put the <noscript> content at the end of your HTML, and then use CSS to position it at the top of the browser window. Google will no longer consider it important.
Stack Overflow itself uses this technique - do a View Source on this page and you'll see a "works best with JavaScript" warning near the end of the HTML, which appears at the top of the page when you switch off JavaScript.
<noscript> is not meant for meaningless warnings like:
<noscript>
Oh, no! You don't have JavaScript enabled! If you don't enable JS, you're doomed. [Long explanation about how to enable JS in every browser ever made]
</noscript>
It's meant for you to provide as much content as you can, along with a polite mention that enabling JS will provide access to certain extra features. You'll find that basically every popular site follows this guideline.
I don't think using <noscript> is a good idea. I've heard that it is ineffective when the client is behind a JavaScript-blocking firewall - if the client's browser has JavaScript enabled the <noscript> tag won't activate, because, as far as the browser's concerned, JavaScript is fully operable within the document...
A better method IMO, is to have all would-be 'noscript' content hidden by JavaScript.
Here's a very basic example:
...
<body>
<script>
document.body.className += ' js-enabled';
</script>
<div id="noscript">
Welcome... here's some content...
</div>
And within your StyleSheet:
body.js-enabled #noscript { display: none; }
More info:
Replacing <noscript> with accessible, unobtrusive DOM/JavaScript
Reasons to avoid NOSCRIPT
Somebody on another forum mentioned using an image for the warning. The way I see it, this would have three benefits:
There wouldn't be any irrelevant text for search engines to index.
The code to display a single image is less bulky than a text warning (which gets loaded on every page).
Tracking could be implemented to determine how many times the image is called, to give an idea of how many visitors have JavaScript disabled or blocked.
If you combine this with something like the non-noscript technique mentioned by J-P, it seems to be the best possible solution.
Just wanted to post an interesting tidbit related to this. For a site of mine I have ended up doing something similar to what stack overflow uses, but with the addition of a "find out more" link as my users are not as technical as this site.
The interesting part is that following advice of people aboce, my solution ditched the noscript tag, instead opting to hide the message divs with javascript. But I found that if firefox is waiting for its master password, this hiding of the message is interupted, so I think I will go back to noscript.
If you choose a solution based on replacing the div content (if js is enabled, then the div content gets updated) rather than using a noscript tag, be careful about how google views this practice:
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=66353
I'm not sure google will consider it deceptive, but it's something to consider and research further. Here's another stackoverflow post about this: noscript google snapshot, the safe way