Develop Reference

JavaScript Pop-up box vs Light box? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Hello cool so I think I have a good question for a bit of a debate. I am currently looking for a good method for displaying something important - terms and conditions for a product - so when a client comes to a page in order for them to access to any functionality they need to agree with the terms and conditions. now I know there are some disadvantages with pop-ups like:
If scripting is disabled, or if the browser does not support JavaScript, the pop-up will not work
Search engines cannot follow links to pop-up windows (scripted elements are always ignored)
Pop-ups present accessibility problems
Site management tools (e.g. DreamWeaver) cannot update links to pop-ups if you move the destination page to another section of your site
Many people have pop-up killers running that close the window the moment it’s opened
In Mozilla, there is an option to stop pop-ups opening in the first place
Not the thing I am worried about is that lightbox might not be compatible withsome of the older browsers. here in africa people are not super up-to date I have seen people using ie-4 (shivers down the spine). but we are only really concerned from ie-7 up. has anyone used lightbox before? or have any suggestions for something of this nature? I am use there must be a lot of use case for a feature like this.
What do you think?

as a webdeveloper myself i suggest you to use lightbox over popup anytime.
Your concern are right but i would rather focus on a couple:
rarely javascript is disabled nowaday, if it is often it's becouse of
company firewall and they wouldn't let the employers access
your site in first place. Yes, some people is still using old browser but it's diminishing overtime, if you are really concerned about it you can, with some more work, create both a popup and a lightbox and drive it trough the meta user agent check.
popup are incredibly annoying for the people becouse:
a) you have to click or to "tab-dance" on a different window that the one currently
active. b) as you stated most of the browser now block popup as a
default feature, so there are high chance that people won't even go
through the step of allowing the popup of www.mycoolsite.org to
work. c)it can kill any google analytics tracement (if you want any)
while lightboxes it's a normal html element in the page and thus
traceable via javascript event bind.
lightbox is amazingly easy to use and customize, offering you the
chance to develop your idea without compromise.

In your situation and technical requirements (IE4, no-javascript), you shouldn't use either.
Put a page in front of product access where the user needs to agree to terms.
That is the most pragmatic approach, business value before eye candy.
In fact, I would even go as far as to say that for required terms agreements, both lightbox and popup are anti-patterns, they just needlessly complicate matters for both developers and end users.

HTML5 Boilerplate vs. HTML5 Reset [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Hey everyone — HTML5 Boilerplate and HTML5 Reset are two HTML, CSS, and JavaScript templates with a lot of modern best practices built-in. Their goals are largely the same:
Fast, robust, modern Web development
HTML5 (duh!)
Cross-browser normalization (including support for IE6 and mobile browsers)
Progressive enhancement and graceful degradation
Performance optimizations
Not a framework, but the starting point for your next project
Obviously, they're very similar in function. In what ways are their implementations different (for example, perhaps IE-specific CSS fixes are achieved using different techniques)? Are they at all different in scope? It seems like HTML5 Boilerplate is a bit larger (build tools, server configuration, etc.), but it's hard to know where it goes beyond HTML5 Reset when it comes to the actual site that people will see.

In general, both projects set out to provide a solid starting point for developers working on web projects. They both get rid of a lot of the tedious, some-what error-prone boilerplate that many developers find themselves re-creating for each project. The details in how they go about it are slightly different, but for the most part, they achieve the same results.
HTML5Boilerplate has, as you noted, added in some build-script pieces to help developers follow best practices to speed up their pages in terms of server-side items, such as far-future expires headers, etc. where-as the HTML5Reset project is more focused on the semantics, content, and styling. For example, HTML5Reset has more example structure for the content of the page in HTML5 (to help show people how to use some of the new elements), whereas HTML5Boilerplate does not.
The response-time and page speed parts that HTML5Boilerplate includes get more and more important as more users find themselves on mobile platforms, and as Google increases the effect page response times have on page rank. There are lots of papers that show a small increase in the page response time has a measurable negative impact on how your site is used and perceived (especially in an eCommerce setting...often a 100ms slower page will get percentage less things sold).
On the CSS front, the majority of the reset style section for both projects is very much the same, with some minor differences in what the baseline is set to. The IE specific fixes, however, are largely the same, with HTML5Boilerplate asserting a bit more control than HTML5Reset over how IE styles some things like form elements (ie. check box / radio buttons and valid / invalid states)
Two major CSS areas that HTML5Boilerplate covers that HTML5Reset does not are common helper classes to assist with making sites more accessible, such as .hidden and .visuallyhidden, as well as some substantial adjustments to the print styles that serve to both make printing more similar across browsers, as well as some cost-savings and accessibility things like making background images transparent (to not waste toner), and adding the actual URL to links and the title to abbreviations.
I would highly suggest reading through both projects' info and how they do things in a side-by-side comparison because the similarities, and also the differences (and the reasoning behind them) is quite informative and has helped me to better decide what parts of each I wanted to use.
Ultimately, just like any "library" sort of project, you as the developer need to understand what you are doing and probably should tweak your baseline to meet the particular needs of the project.

You can use either one...
Like #murtaugh said (http://5by5.tv/bigwebshow/45) you don't need to learn anything when u first start with Reset. In my experience, working in an R&D department, when you need to demo or do quick iterations you can use the Reset (or Boiler if u already know it). When I need to build the product for deployment I turn to Boiler just because has more stuff.
Works for me but now because I know both I can easily use either one.

I actually almost want to say using the traditional reset.css is the best... I find no problems with compatibility in my mobile apps. However, I am developing these apps using the jQuery mobile framework.
So I guess it's really conditional as to what kind of tools you are using. Phonegap doesn't seem to have any problems compiling my code into all OS. And viewing my source code in emulators looks perfectly fine...
So I really don't see the point of a boilerplate unless you are trying to achieve polyfills.

I work in an environment where previous developers roped the company into using both JQuery and Prototype...and it's a mess. Not only do we have to work out of compatibility mode, but just think of the extra overhead that it causes. When debugging, Prototype "hijacks" debug messages in Firebug, which leads to even more work. And the maddening part is that I've been undoing this mess for months and am just starting to get close to being done with it....and just when I'm about to pull the plug on Prototype I always seem to find another section that relies on it...
It's for this reason that I argue every time against combinations of frameworks that have similar purposes. For example, no matter how cool you might think YUI Grids is, if you load the entire YUI Framework you best not be doing Jquery, Moo, or Prototype. You'd be just needlessly bogging yourself down. It kills the load time (which wrecks the user experience) and just gives developers headaches and needless work.
Look at this phase of your site like building the foundation. You have the opportunity to use anything you want to use, but you have to be careful not to "paint yourself into a corner" so to speak. So, use purpose-built and best in class tools that are available based on your resources. Don't just use something to be cute! We're lucky in that many very high quality tools are free, so we have a choice. But know that you're steering the direction of your site for the future, and you might be the person like me who has to deal with the consequences if your decisions are hastily made.
So, unless you're NEVER going to use another framework, I endorse Reset...or even just doing top quality standards compliant CSS.

Should we consider Flash as a last resort? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
When we make a website with some interactivity (not whole flash site). should we always find a way JavaScript way before to use Flash? Should we consider Flash a last resort, if possible?
It is true Flash will not be indexed by Search engine. and it will not run on apple devices.
Will javascript also perform better than flash, in terms of speed?
Edit:
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?

Flash has it's advantages. I personally love JavaScript and are always surprised what is possible without Flash. But on todays browsers you can do a lot more with Flash and it ill perform a lot faster.
In the bright future, you might be able to do almost everything you can do with Flash using JavaScript and the canvas element. But until the majority of all browsers will support that, there are some things you can only do with Flash.
I don't use flash on any of my projects anymore and I also have a lot of fance stuff on them. But I also have a fallback for non-JS users and you should also have that for non-Flash users. and because a JavaScript application/widget is build using HTML and CSS, such a fallback is much easier to realize than doing it with flash.
I don't say, that you should not use flash at all, but you should make yourself a list of things you want to have on your website and than search for JavaScript libraries or plugins that can do that.

Isn't anyone bored with this question yet? There are tons of answers/non answers on the internet. One could write a book about Flash advantages & disadvantages, actually many books :) I personally don't think there's a rule you can apply to every project that will let you know if you should or shouldn't use Flash. This is a personal choice , based on the type of project you're dealing with , the languages you're comfortable with and the objective you're trying to achieve.
Some clients won't care about not being able to be accessible on Ipads, some others will. You don't tackle a business site the way you would tackle an artist portfolio. Keep your options opened and , more to the point, master as many languages as you can and when you do, I have no doubt you won't bother with this question again.
so:
should we always find a JavaScript way before to use Flash?
why not? if JS can do it with similar quality & performance, why go Flash?
It is true Flash will not be indexed by Search engine.
Google has made a lot of progress in indexing Flash content so it's not entirely true
and it will not run on apple devices.
False. It will run on most apple devices, of course not the Ipad!
Will javascript also perform better than flash, in terms of speed?
that would depend on what you're trying to do
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?
Some level of understanding of both languages would help

I'd say no, but then again I might be bias.
Flash is good for its own certain points and needs. I think that it has received bad press as it has been misused a lot, it is not a replacement to other languages but has been used that way for quite a while. It should be used when needed, rather than an instant fix to make things look "cool" or "modern".
Flash is good for application based design, multimedia and complex animations. This admittedly is rather fuzzy, but it's hard to define nowadays closer than that. Javascript on the whole is a very powerful tool, and the new HTML <canvas> tags allow a great flexibility on what can be accomplished with JS, CSS and HTML, but requires specific support that isn't guaranteed on all browsers (10% of people still use IE6 supposedly) so it's very much a gamble on who your target market is to what you should be doing.
On the whole if you know what you are doing it is possible to do nearly all that flash does in javascript/css/back end technologies, but it is less encapsulated than a flash example, and as far as I know flash is more efficient in its resource allocation and can take advantage of CPU enhancement, where javascript can't as of yet. It all depends on specifically what you are trying to put together and how complex/portable you want the code to be. If you are putting together a 3d shooter, use flash, if you are trying to move a <div> 5 pix to the right, use javascript.
Flash in itself will run on "apple devices" except for the iPhone and offshoots of this technology (iPad for example) but will still run in safari etc. on macs. and is constantly getting better at being indexed on search browsers, and there are get-arounds for that anyway, so that shouldn't be the reason for stopping you.
Have a look at jquery examples like this page to see some of the fun things you can do, and maybe some inspiration.

Do we still need backup code for people who have javascript disabled? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I hear about it a bit in tutorials that I watch, that certain things won't work if javascript is disabled. Occasionally I see workarounds.
The question is, are these relevent? I can't imagine anyone not having a javascript enabled browser nowadays, except the most ancient of phones, and chances are your page won't render on them properly anyway.
Do people still bother to write backup code for javascript being disabled?
Edit: As a test, I turned javascript off. Facebook doesn't work.
Edit: I understand about visually impaired users, but do people care (harsh, yes) if their experience is buggy? Not to sound disrespectful, but not sticking to strict standards will alienate people using Internet Explorer 4 and 5 too, but we don't seem to care about them...?
Edit: Saying that people should do it seems like a very automatic response, considering how many people use JQuery and other groovy addon libraries.
Edit: I tried a bunch of fortune 500 sites, and so far about 70% of the ones I tried have broken
Dell
Walmart
Fedex
Intel
Coca Cola

Yes, we still need backup code for people who have JavaScript disabled.
JavaScript is often used to do things that break in screen readers (so many screen reader users disable it) or to cause changes to appear out of sight of a screen magnifier.
JavaScript is still one of the biggest attack vectors to exploit security holes in browsers.
Add-ons such as No-Script are increasing in popularity.
Search engines tend not to execute it (so you don't want to hide your content behind it)
I prefer to think of it as a foundation rather than backup.
I understand about visually impaired users, but do people care (harsh, yes) if their experience is buggy?
Nasty people don't.
The law (in many jurisdictions) does.
Not to sound disrespectful, but not sticking to strict standards will alienate people using Internet Explorer 4 and 5 too, but we don't seem to care about them...?
IE 4/5 have:
a smaller market share than users without JS
many security holes
no support from their own publisher

As a developer I no longer worry about 1% of users who turn off Javascript. It is too time consuming and development time is too expensive to waste on such nonsense. AJAX saves an incredible amount of bandwidth which turns directly into $$$ savings, which makes profits higher. If I lose one or two potential users of the site for every 100 users, those one or two lost users will cost a lot more in development than the potential income of they could ever bring in.
Try turning off Javascript and logging into Facebook, it becomes a very broken website after that. If it's good enough for Facebook, its good enough for me.

Support for JavaScript-disabled web sites a nice thought, but not of much help, and of questionable value, IMHO
It is almost impossible to design a robust website without java script, and those that disable JS, for whatever reason, probably don't expect much of a user experience. So if you are coding for that 1% of the population, you have no choice. But for the majority of us, it is a given that JS is there. Accessibility is a different issue, with its own challenges. When I was doing web sites for Hewlett-Packard, they had to meet strict accessibility standards, and it was tough to create anything more than very basic web pages. I wouldn't wish that on anybody.

I have a different opinion to many here. I don't think you necessarily should care in some scenarios, especially if your website is targeting a particular group of people or that it is going to mean a lot of work.
if you refer to:
http://visualrevenue.com/blog/2007/08/eu-and-us-javascript-disabled-index.html
(source: visualrevenue.com)
You can see that year on year more browsers than ever have Javascript enabled, contrary to the other answers' claims. It was at 96.9% in 2007.
So you lose 3% of potential viewers, so what, your advertising campaign will do a lot more damage than that!

Yes. Especially when it comes to 508 and WCAG compliance. While the technologies to create accessible JavaScript are coming out of their infancy (see ARIA), developer's should still be coding sites in a way the does not require JavaScript.
http://www.w3.org/WAI/aria/faq
http://www.w3.org/TR/WCAG10/

All the other questions got most of the points covered, but I'll chime in with this: it's not a big deal to have your page(s) degrade gracefully in the absence of javascript. If you've got some super-whizzy ajax-infested real-time comet style app that really isn't going to work without javascript, you should at least render a nice message to the effect that javascript is required.

It depends on your audience and type of website.
For instance, a graphic artist portfolio will not be visited by blind people or people using text browsers. So in that case it's not so important to build nice degradable JS, expecially because it will most probably be used for graphic effects.
If, on the other hand you're developing a news website and you decide (for whatever reason) to dynamically load your news with JS then you should definitely make it degradable. Also, remember that the spiders of indexing engines may have difficulties in indexing content loaded with JS in your page.
At the end of the day, in most cases it's not so difficult to program the site so that it works without JS. If you're retrieving content dynamically you already have the server-side code to load the content, you just need to accomodate how the page is called.
Same thing for forms, you can send the content via AJAX or via a normal POST, the backend will be pretty much the same, so it's again easy to implement.
Of course, the problem is not even posed for JS code that is purely graphical.

My recent experience:
My former supervisor claimed, in earnest, that because Google Analytics told us that "87% of our users have Java enabled and less than 3% are using IE6," that we didn't have to worry about supporting older browsers or users with JavaScript disabled.
Problem 1: Java is not JavaScript.
Problem 2: In order for Google Analytics to track a hit, the browser must have JavaScript enabled because the GA interface is a JS include. GA is not, and can not, be aware of users with JS disabled, which can potentially severely skew its reports.
Problem 3: one of our biggest customers requires that all engineers use IE6 with JS disabled.
Problem 4: The boss (at the time) didn't know how to read analytics reports.
If you want to know how important this support is to your business, a good place to start is the IIS logs. Just about everything related to the browser caps is stored by IIS. I regularly import the logs into SQL Server and run some basic reports from my admin site, which come in handy every time someone starts suggesting that we go crazy with the jQuery BS.
If you decide to start building complicated, script-dependent interfaces, be sure that your interface degrades gracefully and doesn't remove required functionality if JS is disabled.

It is not merely a question of whether a browser is capable of executing javascript, but if a user has disabled it for some reason.
For example, you need to be aware of vison-impaired users. Such users might disable javascript, because the effects are confusing their screen reader software.

Is it reasonable to assume my visitors have javascript enabled?

I understand that server-side validation is an absolute must to prevent malicious users (or simply users who choose to disable javascript) from bypassing client-side validation. But that's mainly to protect your application, not to provide value for those who are running browsers with javascript disabled. Is it reasonable to assume visitors have javascript enabled and simply have an unusable site for those who don't?

I browse with NoScript in Firefox, and it always annoys me when I get pages that don't work. That said - know your audience. If you're trying to cater to paranoid computer security professionals - assume they might not have JavaScript enabled. If you're going for a general audience, JavaScript is probably on.

Totally depends on who you're aiming at.
If your site or app is for an Intranet, you can make lots of assumptions. If your target audience is bleeding-edge social-networking types, you can assume JavaScript will work. If you anticipate a lot of paranoia sysadmin types, you can assume a bunch of them will be trying to access your site in lynx or have JS turned of for "security reasons."
A good example of this is Amazon -- their approach is driven by their business goals. They are a mass-market site, but for them, locking out users in old/incapable browsers means potential lost sales, so they work hard on non-script fallbacks.
So like lots of these kinds of questions, the answer is not just regurgitating what you've read somewhere about accessibility or progressive enhancement. The real answer is "it depends."

I think there is another reason which push you to support at least some main functionality without JS - lots of us now browsing from mobile and PDA, which have no the same lvl of JavaScript support.

http://www.w3schools.com/browsers/browsers_stats.asp
They claim 95% of users have Javascript on.

Duplicate
There's at least one category where the answer is definitely "no". If you work for the government, you must make sure the site is accessible to those using screen readers.

Is it reasonable to assume visitors
have javascript enabled and simply
have an unusable site for those who
don't?
There are actually two questions, and the answers are: Yes, it is reasonable to assume visitors have javascript enabled. And, No this does not mean others should be left with unusable site.
Progressive enhancement is the way to go. Have your site usable without javascript and then add bells and whistles.
As for client side validation, it is no more than a convenience for user to avoid unnecessary roundtrips to server (where real validation should be performed).

I browse with the NoScript plugin in firefox and I'm surprised at the amount of developers that haven't even considered making their site degradable.
Never assume the user has JavaScript disabled - especially seeing as it may not always be their fault. Many enterprises have firewalls which block JavaScript/ActiveX etc. - In this instance the <noscript> element won't work so I would NOT recomend using that either!
Unless you're creating a full-on web application which is going to be 90% Ajax then you must make sure to abide by standards and progressively enhance your site through various layers of interactivity.
Also don't forget the important of object detection, especially with the rise of mobile phone web browsing. One of the most popular mobile web browsers (Opera mini 4.0) doesn't allow all "Background javaScript" to work and Ajax calls rarely execute correctly... Just something to be aware of.
To be honest I am sick and tired of developers that think everyone will have JS enabled! What ignorance!!

Yes it is. But expose as much of it as possible through regular HTML and URLs, if for nothing else than for Google.

Accessible, yes... functional? Not really.
This is really a customer requirement question more than developer-answerable, but if your customer tries to enforce a requirement that non-JS browsers work, you should argue heavily against it and really hammer them on the "cool" factor they'll be missing.
Given the heavy reliance by GWT, RichFaces, etc. on Javascript, it's just not feasible to make an app with any kind of user-friendly UI without it.
You should certainly warn non-JS enabled users that the site they're trying to visit relies heavily on JS, though. No point in being rude about it.

It is ok in these days to assume your visitors have JS enabled. With that said, you should strive for the best possible degradation of your site with JS disabled. It is ideal if your site falls back to a state that is still usable without JS.

No! Some environments will have it disabled as a matter of policy, with nothing you can do to enable it. And even if it's enabled, it might be crippled.
This question has been asked before.

One interesting point to consider is that as a web developer you have a social responsibility to push technology forward - and by using things like AJAX, you increase exposure and potentially rate of adoption along with it. The only thing that should stop you from using the tech to its fullest extent is money - if you won't make the money that you need because people will have trouble viewing the material, you've got to reconsider.

Never ever assume Javascript for form validation, as your question implies. Someone will eventually realise this and turn Javascript off.
Instead, code the app in fairly regular html manner and use Javascript for what it is: an optional perk for your users.
Even for an entirely AJAX app like Gmail, the complete works of form validation is required on the server side.

Yes it is, JavaScript is as old as CSS and no one tries to build around browsers that don't support CSS. Cross Site Scripting is the reason people are afraid of JavaScript, but believe me if a developer wants to screw you over he doesn't need JavaScript to do it. As far as mobile browsers, most of them now have JavaScript, and the others shouldn't be considered browsers. My advice is not to open yourself to hackers by making your site vulnerable to those who choose to turn off their JavaScript, but at the same time don't go out of the way to support those who are living in the stone age. You aren't going to support IE 4 or Netscape, right? Then why support those who sabotage their own browsers because of blatant fear or paranoia?

I think it's fair to assume that the majority of visitors to your site will have JavaScript enabled. Some of the more trafficked sites out there have a dependency on JavaScript. For example, I was surprised to learn that you can't authenticate through a Passport-enabled site without a JS-enabled browser.

Nearly all (but not quite all!) users will have javascript enabled. (I believe the figure quoted above of about 5% is accurate.)
Given the vast improvement in usability you can make with the judicious use of javascript, my opinion is that most of the time, it is reasonable to assume it is enabled.
There will of course be some instances where that is not the case, (ie, a site designed for mobile devices, or with a high percentage of disabled users etc), and always a effort should definitely be given to making your site as accessible as possible to as large a percentage of the population as possible.
That said, if you only have a low traffic site, 5% of a small number is a very small number. It may not be worth bending over backwards to make your site accessible to these people when it may only gain you one or two extra users.
I guess the short answer is (as always), there is no correct answer - it will depend entirely on the target use, and target users of the sit in question.

According to this little page Javascript is enabled in 95% of browsers and it keeps raising.

The W3C Browser Statistics page (scroll down) has some information on this; they say that 95% of visitors have JavaScript on as of January 2008.

It's reasonable to assume your visitors have javascript enabled !-)
-- but of course it depends on who you're trying to reach ...
Several times above w3schools have been mentioned and, as Dan stated, its their own visitors which make it somewhat quirky to draw conclusion from.
However, if you look at theCounter.com it seems that their audience has the same habits in general on this point ...
A twist that hasn't been mentioned yet is the growing amount of crawlers, mailharvesters and so on, they definitely do not have javascript turned on, and how good are counters to detect them ?-)
My guess would be, that this sort of machine-browsers fill up a lot of those 5-6% !o]
-- that said, if it's at all possible, make your app degrade gracefully (as a wise man said)

Your questions seems to suggest form based input for an application. If it's an intranet application then you'd be guided by the in-house security experts. If it's public app, then as other posters have suggested, fail gracefully.

I will argue that it is more than reasonable to expect them to have javascript so long as you provide suitable means to replace javascript should it not be enabled. One of the reasons that I like the Yahoo UI Library is that it degrades gracefully.

I always try to code my sites as static one first, THEN i add js/ajax functionality. This way i can be kinda sure that will work on non JS browsers :)
But, javascript is like flash: all users have it, but developer have to concern on WHAT IF.... ? :D

No its not, period, full-stop, end of story. Its just naive and wrong at an ethical level, not to mention you miss out on around 50% of Internet users worldwide (believe it or not 70% of web access worldwide is from mobile devices).
Add extra nifty stuff that requires Javascript, thats fine. Don't make your site unusable without Javascript unless you have really, really, really good reason to do so.
Someone rightly pointed out that I don't have evidence to back up my claim of 70% mobile web users. Unforunately I can't find the source I got it from but I remember it being authorative so have no reason to doubt it. It does make sense though when you consider worldwide usage, many developing countries have more mobile phones than landlines and broadband. A statistic that was quoted in my not-to-be-found source was that one African country in particular has 300,000 landlines, but has 1.5 million mobile phones!

This is totally a "it depends" question, as many people have pointed out.
This is why metrics is valuable on sites to help show if you can really run with the analogy that "major sites say that the majority of people have JS on" - you could have a site where it's 99%.
I won't dig in to what's been said above, as it's been answered very well :)

Not that everyone else hasn't chimed in, but I disagree with the "look at your audience" position to some extent.
It really should be "look at your app" if you are just displaying some information, and your js is for bell/whistle purposes, then certainly look at nice degradation, if you want to.
However, if you're building something like Google Docs, it's really asinine that someone would think they could use your site without js, so perhaps let them know that via a nice sarcastic message inside <noscript> tags.
From a purely philosophical point of view, if users want to access your site, they will flip the js switch, or upgrade to a decent browser, etc. And you should force them to do this, because evolution is important for the survival of the species.

According to this site, 95% of browsers use JavaScript.
That said, there are a LOT of bots that don't use JavaScript: scrapers, search bots, etc. I'd say closer to 100% of actual human users use JavaScript. But your guess is just as good as mine.