I have been using javascript to submit HTML forms at times for some convinence. I would like to know wheather there is any drawbacks of this approach compared to using classic form submit using a submit button
Using plain HTML is better for many reasons:
If your user does not have JavaScript enabled, or you havea JavaScript bug in your code, your form still works.
Plain HTML forms are simpler to write, and harder to screw up
An actual button is better semantically than a magic link or div that submits the form for you. This helps with things like tab ordering, OS integration, screen readers, and is clearer to programmers who work on the code after you.
The browser already has battle tested code to submit forms. Why would you rewrite that code for no point? It increases risk, complexity and time.
Not writing the JavaScript code means you have more time for other things, like not working on the code anymore.
If something already exists and works for your use case, don't reinvent the wheel!
The only drawback I can think of is if you need to have the page reloaded because you're integrating with an older site that regenerates HTML each time... But if you're building a new system, or it already does that, in my opinion it's better. Saves bandwidth, computing time, re-rendering time, etc..
If you're talking about just submitting an HTML form, there's really no difference.
No there are no drawbacks really. You might have more code the way you are doing it as opposed to just wrapping everything in a form and submit button but you can still take advantage of https of course and everything else the web may have to offer these days.
The most predominate disadvantage is the inability to provide functionality for visitors who have Javascript disabled. You can support both simultaneously by providing a different page to redirect to when javascript is disabled.
The following is a list of methods used to detect and react to disabled javascript:
<noscript> The HTML noscript tag.
Using jQuery or Javascript to set a cookie
Using Javascript to hide an area using CSS.
Personally, I'm not a fan of HTML forms. HTML is a layout language, and a poor one at that. Keeping layout and functionality separate is a central tenet of object-oriented programming. Whether you perceive HTML and JavaScript as representing these functions in that manner is probably a personal choice. You could argue CSS is the layout.
If you're writing a simple page with little else going on, then using HTML forms isn't a bad idea.
If you are planning to write a good-sized application, with lots of nice features, then, for me at least, it would make sense to have that in one place.
If you start introducing JSON or any kind of client/server relationship beyond "here is my text or drop-down choice" then take a programmer's approach rather than a web designer. JavaScript gives you more flexibility. You can chat with the server without anything happening on the page.
If you use a library like jQuery, the coding overhead is very minimal.
Related
I just recently started learning javascript and have a question regarding the'proper use'. I'm still trying to identify the role of Javascript within a website, and I'm curious whether or not it would be considered ok to have Javascript modified the HTML of a web page.
Let's say I have a panel on a web page. This panel houses a list. I would like users to be prompted to add items to this list.
I was thinking that it would be possible to use Javascript to generate list items to add to the list. However, this would be modifying the actual number of HTML elements on the web page... For some reason, this just seems 'hacky'. When I think of HTML, I think of a static structure that should come to life with CSS and Javascript.
So my question: is it considered okay to have Javascript modify the HTML of a web page? What about the case of adding items to a list?
Thank you!
Javascript is a programming language designed so it can modify the document that is being displayed(the DOM), the actual HTML is never touched.
Javascript has a place on a website and modifying the document/dom is perfectly acceptable and without it, would make javascript almost useless. CSS is great for certain tasks, but you can't do everything in CSS, though CSS5 is coming pretty close for many tasks.
Rewriting the entire DOM IS bad practice, but using it to shift an element's position based on an action, or creating a popup overlay is perfectly acceptable.
Remember the gold rule:
Modify as little as possible to accomplish the goal.
What matters is the user's experience of the (HTML) document. The representation of "the document" can change by utilising a language like javascript that "manipulates the DOM" - and the DOM is like an instance of the HTML document, or "document session" if you will.
So in a way, no, the HTML is touched. It is positively manhandled by javascript - indirectly and in a non-persistent way. But if you want to be pedantic... we say it isn't and leave half the readers confused.
When to use javascript and when not to. It's swings and roundabouts. You need to learn (mostly from experience) when one particular tool suits the situation. It usually boils down to some core considerations:
HTML is for markup. Structure. Meaning.
CSS is for style, feel, appearance.
Javascript is for those situations where none of the above work.
And I'm neglecting to mention server-side processing with the obvious disclaimer that all processing that ought to be done in privacy is done on the server (with a programming language like PHP or Ruby for example).
Sometimes you get the grey area in-between where you can do something either way. Those situations you may ask yourself a question like... would it be processed quicker if the client (user's computer) processes it, or the server... and that's where experience comes in.
It depends on the case to decide if you should manipulate DOM directly or let the JS do it.
If you have a static html page, just do your html and hand craft the
DOM. There is no need for JS to get a hand here.
If you have a semi static html page where the user actions change
part of it - then get the JS to do the changing part.
If you have a highly dynamic html page (like single page app) - you
should get the JS to render html mostly.
Using plain JS however is not the best for you in this age of great JS evolution. Learn it -but also learn to use good libraries and frameworks which can take you to the track very fast.
I recommend you to learn Jquery and Angular 2 which make you feel like learning a super set of JS straightaway.
Short disclamer: Javascript may modify DOM content in a browser but never change original HTML served from Web server.
Modern Web is unthinkable without javascript. JS allows to make static HTML interactive and improve User Experience (UX). As any sharp tool JS can produce a masterpiece out of nearly dead page and cut throat to a blooming static content.
Everything is up to the developer.
When not to use JS
Do not use JS to deliver ever-green content to the page. Web bots (crawlers) don't run JS, and you message "I come to this world to testify to the truth" may appear "a voice of crying out of desert" and be non-indexed and thus unread.
When JS in the must
Every time your page visitor does something the page should respond with proper action (using JS or, if possible, just CSS).
This is especially important when a prospect fills in a form. To err is human so a developer via JS should help the visitor to make wrong things right. In many cases it is possible without requesting server and in even more cases the answer should come from the server. And JS is your best friend in this case.
Javascript never lives alone. Browser object is its trustful ally. Most modern browsers support XMLHttpObject A.K.A AJAX (you may remember this name from ancient Greek history) which communicates with the server without reloading the page.
The idea of AJAX which stands for Asynchronous Javascript And Xml is to send request and receive response from the server asynchronously without blocking page in the browser.
Native javascript may be difficult to understand to many beginner developers. To make thing easier there are a lot of JS libraries with jQuery being most known.
Returning to the OP's question, Should Javascript be used to modify HTML?
The answer is: It Depends.
I am working on a website for a company (my first, except of my own), and i am a little confused. i know that i knew this before, but i have forgot.
i am going to create many different pages on the site and i guess that it´s not a good idea to create one new file for each page.
and i think the best way is to make one "div" for each page, in the index file, and somehow put all of then behind each other, and show one by one when i click on the right thing in the menu... how do i do this?
can i only use CSS or do i need some Java script, and how do i write the code?
very thankful for quick help! :)
You're talking about making a single HTML page that contains all of the content for a company website. It's a bad idea to build a corporate website this way, for several reasons:
Web browsers expect to navigate through a site that has multiple pages, which is why they have a location bar and forward/back buttons. Your approach breaks both of those.
This single page would be much larger and take longer to load in users' web browsers.
The SEO of the page would be poor, because its content would be hard for Google and other spiders to understand semantically. A large page with so much text would look like keyword stuffing to Google and would be penalized.
It would be difficult to keep such a page organized; making any change to anything would require you to edit a single file, so it would be harder for you to track and/or merge changes to different documents, and much harder for the company to make content changes.
Lastly, the approach is just inappropriate. You are correct that it's not too great to create one static HTML file for every page. But the solution is not to make a single web page; the solution is to use a CMS!
Wordpress is the most popular CMS in the world. It's designed for blogs but can be used for any website.
Drupal is a powerful CMS with lots of features you may not need, but it's more modern than Wordpress and may be more visually flexible.
If you don't want to use a full-fledged CMS and you feel like flexing some programming chops, you could try using an out-of-the-box MVC framework like Rails or Django, but bear in mind that those will require you to learn a little Ruby or Python.
The main thing is that you should be using server-side templates to solve the problem you have, not client-side JavaScript.
(Some very large websites do use a JavaScript-powered approach to page navigation, but these are usually web applications like Twitter. The approach is inappropriate for a corporate web presence.)
You can use Javascript to change the innerHTML of elements.
For example, create a div and give it the ID "myDiv":
<div id="myDiv"></div>
Then, when the user clicks on a button you can change "myDiv"'s innerHTML like this (by calling the function):
function show(){
document.getElementById("myDiv").innerHTML="html code here";
}
I hope I helped :-)
So head to www.jabsy.com, with Javascript turned off.
Basically, I use some JQuery UI Dialogs, I use Javascript for all the bindings on the page...I pretty much use it for everything. Is that really a bad thing though?
Nothing really works without Javascript. Not even the Google Maps API.
Should I go out of my way to try and make the entire page work without Javascript? Is that even possible with my site? I wouldn't even know where to begin as I use Javascript for everything, so could I get some points? How many users actually turn off their Javascript these days?
Would it help to let the user know if they have Javascript turned off and make them turn it on before accessing it and provide them with directions how?
Yes, if your site requires JavaScript you need to let the user know that it is required.
For example:
<noscript>
<div>
You need to have JavaScript enabled to use this site.
</div>
</noscript>
You can provide more description as appropriate. A savvy user that sees this text is going to be able to then go in and turn on JavaScript for your site. A non-technical user might have trouble, but I would think most of them would be running with JavaScript enabled anyway (?).
According to data collected in 2007, about 3% of users in the US have JavaScript off. I'm sure that number is lower today.
It really depends on how critical the sections of your page that require JavaScript are. If there is a form that is mission critical, but controlled completely by JavaScript, you probably want to engineer a way for that form to do the same thing with JS on and off.
However, you have animated snowflakes on your background (for the love of God, don't really do this), it's not going to negatively affect someone visiting your site with JavaScript off.
Really, it all comes down to how important the information or actions are to your site. Turn off JavaScript and note all the things you can't do that are absolutely vital, then make them work.
Keep in mind there are several audiences that will not render your JavaScript:
Screen readers/accessible browsers
Console-based browsers (Text based browsers)
Search Engines (Google)
Your specific service (location-based messages) will be way too cumbersome to use without JavaScript (and its content is dynamic). Therefore, I see no problem requiring it. You should, however, point out that JavaScript is necessary to use your site (Preferably at the top, in really large letters). You can do that by including the alternative no-JavaScript content in noscript tags, i.e.
<noscript>
<div style="font-size: 200%;">You need JavaScript!</div>
</noscript>
However, most websites are content-based, like a company's homepage, stackoverflow or Wikipedia. These websites should be usable without JavaScript. Nowadays, even smartphones have excellent JavaScript support, but Kindle and regular phones are still too slow for JavaScript.
There is a line of argument that says sites should work without JS. Personally, I think that is tosh, unless you have a clientelle for whom this is liable to be an issue. JS is a reasonable thing to expect for many sites.
However, it is polite to let people know that this is a requirement, and inform them rather than just letting it not work. If your site is heavily JS dependent, then you may have made some mistaken design decisions, but it is probably not worth re-working it. If you monitor the number of people who get the "you need js" message, you will identify if it is proving a turn-off. I suspect it will not be an issue.
So build based on what you need, BUT tell people if they need to have things set.
You can use the <noscript><!-- html here if no Javascript --></noscript> tags and place content to be rendered in between if javascript is turned off.
I don't think there are many sites that will work with these days without it. It's more or less mandatory.
Suppose I'm developing a web app that is heavily dependent on JavaScript and which uses AJAX for all the POST commands to store data, etc.
How should one deal with those situations where a user may have JavaScript turned off? Is it unreasonable to require that a user's browser has it turned on? Are there any best practices for these situations?
Use <noscript> tags to let users know that they cannot use the site without Javascript. It's not the best practice, but it is common at this point and most users without it will have experience being left out in the rain.
That said, if you can provide a version of the site that doesn't require Javascript (think the degraded version of gmail), that is clearly a superior solution. Without it, you will lose mobile surfers, plus blind folks and others with accessibility needs. And people who are too stubborn to use JS, but we don't care about them.
I personally think it is not that big of a requirement to expect people to have Javascript turned on.
If you do not want to support non-javascript, it is as simple as:
<noscript>
This site works better with Javascript turned on.
</noscript>
Near the top.
If you still want to support users without Javascript, you can structure your Javascript so that if the JS isn't loaded, all of the forms still submit to the right place.
For instance, if you have a form:
<form action="" method="POST">
<input type="text" name="name">
<input type="submit">
</form>
Don't build the actual form with the idea that you are using Javascript. Instead, simply hook into the page to enhance the experience.
Regularly, the above form would submit to itself. With Javascript, you can hook in and make that Submit happen through AJAX instead of a new page load.
The key here is the concept of "graceful degradation". You want to offer the best possible experience you can despite not having javascript support. For AJAX, this usually means making full page requests rather than the lovely dynamic ones we're used to; POST will similarly have to submit through HTML and load a new page.
This obviously isn't as feature-rich, and displaying it well can be a challenge, but if you're looking for a best practice, that's the goal. It's also worth telling users via a noscript tag that they have javascript disabled (some people might have legitimately done this by accident), but turning off your entire site due to a lack of javascript is not friendly behavior.
Any site worth making is worth making accessible.
Depends on the site; something like Google Maps, for example, is clearly just not going to work without Javascript. So simply showing a noscript element politely mentioning that they will need it to view the site is fine.
Probably best to avoid any patronising "you need to get a new browser" messages; they may not be able to, for a number of reasons, or may simply have chosen to install NoScript or similar. According to Mozilla, NoScript has had nearly 70 million downloads; obviously a large proportion of those will be repeat downloads for the same person, but there could easily be 10 million people out there with it installed - that's not insignificant.
"Best practice" would, I guess, be to have a gracefully degraded version if possible. Up to you to decide whether that's worth the effort or if it's appropriate for your site.
You can send form data through action attribute. When JavaScript is turned on, remove the attribute by using removeAttribute or setAttribute. That way, when non-JS users use the browser, they can still submit the forms. However, in the backend code, you have to support non-JS as well, which is way more better than using <noscript> or no-js (Mordenizr).
Of course, there's still some drawbacks by doing this, for example you need to reload the whole page each time, which consumes a lot of time and memories.
So far, this is the best solution I can think of. Hope it helps.
I'm working on an ajax application that makes extensive use of jQuery. I'm not worried about whether or not the application degrades gracefully.
So far I have been using Malsup's excellent jQuery form plugin to create forms that submit ajax requests. (For example, to submit updated record information.)
However I am considering dispensing with form tags altogether, and instead manually constructing $.post() statements when needed.
I'm wondering: What are peoples' thoughts on the best way to submit a large amount of information to the server - considering graceful degradation is not a requirement. Are there perils with just using $.post()?
Thanks in advance
Nope, not at all. That's all the plugin is doing anyway, under the hood.
The form tag does at least provide you with a nice structural grouping of your form tags, so that you can query for them more easily, though.
You've said it yourself - the peril is that it won't degrade gracefull!
Have jQuery add an extra field called UsingjQuery, then output your results based on whether this field is set or not.
This way users with javascript turned off (mobile clients, etc) will still be able to submit.
edit: Saw you mentioned 'degrades gracefully' but somehow didn't see it said 'not worried about' first!
Having a form tag does allow one javascript trick that jQuery doesn't support without: $('form').reset() ...
I stopped using FORM tags some time ago, but I also have a set of captured users that I know exactly what platform they are using.
I agree with David Pfeffer, however, I would also make the point that on occasion, form tags can get in your way. I've specifically had problems where I wanted multiple forms inside of a table, but that caused really ugly problems with positioning. So, I wound up dropping just the input elements in, copying them into a form that was elsewhere on the page, then submitting that form. It was a bit of a pain in the butt.
If you can do away with forms, and aren't worried about degradation, then I would highly consider it.