I'm learning jQuery and am about to write some pages using intensively that library. I just learned that some user disable JavaScript on their browser (I didn't even know that was possible and/or necessary).
Now, here's my question: What happens to my web application if a user disable JavaScript? For instance, I'd like to display some screens using AJAX and commands such as 'InsertBefore' to bring in live a DIV that will display the result.
So, if JavaScript is disabled, I wonder what going to happen to all this work that relies on JavaScript?
I'm kind of lost.
Thanks for helping
You may want to start by reading on Progressive Enhancement and Unobtrusive JavaScript.
I would also suggest to investigate how popular rich web applications like GMail, Google Maps and others, handle these situations.
I just learned that some user disable javascript on their browser
I do. The "NoScript" plugin for FireFox does the trick.
So, if Javascript is disabled, I wonder what going to happen to all this work that relies on Javascript?
It won't be functional.
A good practice suggests designing a site not to rely on JavaScript for major functionality. At least, accessing its content (in read-mode) should be possible. JavaScipt should only add interface enhancements like Ajax techniques etc. But the fallback version should always work.
I feel really sad when I see a site which is completely broken without JavaScript. Why can't people use CSS to put elements in proper places? Why do they try to align elements with JavaScript even if there is no dynamics involved?
The same goes for Flash sites. Once in a while a land upon a "web-design-agency" site which makes picky comments about me not allowing JavaScript. When I do I only see a basic primitive site with a few menus and that's it. What was the point of using Flash when the work is so primitive it can be done with raw HTML and CSS in an hour? For me it's a sign of unprofessional work.
All what's done in JavaScript won't work. Some users disable it for security reasons, NoScript is an excellent example. You can try it yourself by removing the scripts from your page or installing the NoScript-plugin for Firefox.
As a rule of thumb:
Make the website working with only semantic HTML
add the CSS
add the JS
But the website should be (almost) fully functional in stage 1.
If you disable Javascript in Safari things like Lexulous in Facebook won't work properly, the mouse letter carry function doesn't work.
Related
Can i hide my wordpress blog site's page source like this? I have to ask this question because there are many plugins which can disable page source and right-click. but after typing manually "view-source:url" in browser it instantly shows the source-code of wordpress site.If any body knows answer please write down . this is very important for all bloggers 'I think' .
TLDR: No, you can never hide the soure code of your page. There is NO way.
For a browser to render a web site you need to send it the HTML, CSS, and javascript code. Even though you can make it "harder" to see the code by disabling right click, anyone with just a little bit of understanding of the web will be able to read it easily (F12 in most browsers).
As a website designer it is important for you to understand this concept as it is very important in deciding on how to design your web site. Things the user should not see need to happen on the server side (where no user can reach it). Only things which dont matter if anyone can see should be sent to the user.
I think you cannot hide the whole code. Or do you want to hide a specific part of the code? For example, you can hide/encrypt the URL of an iframe in which you can display more sensitive content. However, I also don't really know how to do it in WordPress (I searched for a solution many times) but I heard it's possible.
I'm curious what about the answers.
I wouldn't even consider doing this. Not only does it ruin the end-user's experience, it can actually stop people with disability copying text from your site or using other right-click menu items.
You can't hide your code, but you can obfuscate some of it.
CSS Obfuscater.
JSS Obfuscater.
I want a single online web page for my bookmarks. The page should include small windows which opens the following pages:
Fizy, Facebook, Guardian.
There should also be a button for adding a new window with an URL text input.
Here's an illustration of how the page should look: http://i54.tinypic.com/2hrkb48.jpg
I've built a version of this at http://bit.ly/heqEd1, but as you may see, it uses iframes under javascript windows, which can not open frame-breaking sites (like fizy.com), or Facebook.
I'll make the research and but I am not sure how to proceed. Any solution will be accepted, like HTML5, XUL, Flex, AJAX or others. A solution with a local installation(like a Firefox extension) is not preferred, but still be ok.
Note: Piro Sakura has built a Firefox extension called split-browser. There's an element of the project called "subbrowser". An AJAX window that can show a subbrowser MAY solve the problem. I know the page will only be available from Firefox, but that is ok. (Again, a solution without an installation is preferred)
Any suggestions? How should I proceed? What should I learn? Is this possible?
Thanks.
I think you should use a Javascript with iFrames to do this. I'm not too sure what you're trying to accomplish with this, but it should be possible. As for which framework you'll use, it's up to you, but there will be a lot of custom code needed to implement this.
You can make multiple draggable windows in FLEX same as you have in you app
Please check sample as Starting point Movable/Draggable window and its demo
also u knows JS-DESKTOP lib with little customization to achieve that one of them are
jsdesk
sonspring-JQuery based
also you can do this using
Hopes that helps
I got a problem with a website that use onClick event to add items to the cart. The problem comes up to visually impaired users that cant use keybord to add the products.
I guess that bringin back the add function with a normal href="addtocard.php?id=1234" should solve the problem but on the SEO side this can effect other problems.
Is there any other way, maybe using events such as onkeypress, or that's totally related to the use of javascript? Thanks in advance.
Having an addtoCart.php?ID=5 should not have a detrimental impact on your SEO. Modern/top search engines will be smart enough to recognise what the function of that page is, and index it accordingly.
When designing sites, I forget the specific name of this type of design, but it is always best to build it upwards, that is add on the onclick/javascript functionality as an extra over the top of the base of your site, so that if users have any of these features disabled the site will still function perfectly, so that is something to consider when building your next site.
So I would recommend building the addtoCartPage. I don't think it's as bad as you think it is.
You can use something like this
Add To Cart
Or somethinkg like this
Add To Cart
It's the other way around from what your SEO consultant said. Most visually impaired people prefer keyboards. It's mice they can't use so well. The name makes you think that onclick only works with a mouse, but in general, onclick works fine for the visually impaired/non-mouse users, since it is triggered with the Enter key as well as with a mouse click. See http://webaim.org/techniques/javascript/eventhandlers#onclick.
That's why using onkeypress for accessibility is not a good idea. Jeremy Keith flatly says, "Beware of onkeypress" since even a Tab key could make it fire.
Besides progressive enhancement in general, you might try Unobtrusive Javascript in particular, which uses Javascript to rewrite links, and that means users without Javascript get regular HTML links. If Google can't follow your Javascript links, you do have an SEO problem.
I have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment
We have a nav that expands on rollover (based on this code: http://www.dynamicdrive.com/dynamicindex1/droptabmenu.htm).
First, should we have a no-javascript version of the nav?
If yes, what is the best way to do so?
Yes you should always have a non-javascript version of your navigation.
The best way to do this is to apply any styles that hide sub-menus with javascript - so if the javascript isn't run the whole menu will be visible.
The HTML for the menu you've linked to looks fine - <ul>s and <a>s - nice and easy for a spider or non-javascript user to read.
It's always a good idea to have a no-Javascript version of everything.
Search engine robots usually do not interpret Javascript, so your pages might not be indexed if they can't be reached without Javascript.
A sitemap page that simply has a link to every static page on your site is the easiest way to make sure everyone can get to anywhere.
You may want to use unobtrusive javascript, which basically means have no javascript in your html page, just load the javascript files.
Now, if you start with a menu on the left, for navigation, using <li> and anchor tags then you can have some navigation without javascript.
So, if your javascript runs, the first thing it should do, when the dom tree is ready, is to set display: none on the navigation div and put in the new, more interactive navigation bar.
This way you can see how it works without any javascript.
Or, you can have a message telling them that javascript is required and do nothing else, but this would also be hidden as above.
I prefer to have things work, even if it has less functionality, without javascript, when possible.
Don't get me wrong: It's a good idea to support browsers that don't have JavaScript turned on, especially for something as simple as a menu.
However, when a project doesn't have it in the budget, or the application that you're writing is deeply dependent on JavaScript, it just doesn't make sense to support it.
Statistic from w3c and the counter indicate that 93% to 95% of users have JavaScript enabled. Now, mind you that this is a global demographic. To really determine if it's worth your time and money, it would behoove you to do your own statistics to determine what percentage of your traffic/demographic has JavaScript enabled.
As a side note: for reasons similar to why people are moving away from supporting IE 6, my company is also moving away from noscript support. Especially in large scale RIA's, it's just not practical to write the same thing twice. Maintaining two code bases for one project is not my idea of a good time. But of course, this is always based on the client and the target demographic.