I use media-queries for responsive design on my website, and uses respond.js to ensure it works in browsers that don't support media queries. But when I tested it on IE8, it didn't work.
From other Q&A, I have ensured that I:
place the respond.js script after the CSS
it is ran on a server and not locally with a file:// protocol
Avoided any cross-browser issues
Made sure my include path is correct(!)
But none solved the issue.
I have found that including too many styles within media queries will sort of 'overload' it, and nothing within the media queries will show at all. I have tested this by removing all but one style within the media queries and it worked again.
The 'solution' is to place as much CSS outside media queries as possible (use overriding properties instead) and combine multiple media queries into one, which is good practice anyways.
This might have been the issue here also, where the last media query didn't work because of overloading.
A similar conclusion was made by another developer from 29 Steps.
Related
Is there anyway to detect old browsers in HTML like the code I use for IE e.g :
<!--[if lt IE 9]>
...
<![endif]-->
I want to show a warning message as some of my web features are not supported for them.Is it better to use a JavaScript to detect this instead ?
Thanks
I finally used the code found at
http://www.php.net/manual/en/function.get-browser.php#92310
by using PHP
Feature detection. Not browser detection.
If you want to warn them about missing web features, why not use feature detection for those specific features, rather than browser version detection?
This has two major advantages:
Firstly, for your code, it has the advantage of making it clear what you're actually doing, and why you're doing it. This will make your code easier to work with in the future.
Secondly, this will allow you to reliably pick up all browsers that don't have the feature(s) you need, which means that if someone visits your site using (for example) and old mobile phone browser that's never been updated, you'll still be able to pick it up and show the correct message, even though you never thought to test for that specific browser.
You didn't tell use which specific features your site needs, so I can't give you details of how to detect it, but you may find the Modernizr library useful; it does feature detection for a wide range of modern browser features.
You may also have the option to add a 'polyfill' to your site to add support for the missing feature to old browsers. Modernizr is good for helping with this, and they also have a big list of polyfills you might like to try.
As I have been learning, I have developed a bad habit of only doing things in chrome. More recently I have started looking at stuff I make in other browsers; it sucks. I have noticed that the positioning in firefox is a little different, safari is basically the same, and IE is a hot mess. For now I am just going to focus on getting things to work correctly in firefox. Is there a sort of if Firefox conditional statement?
There is no equivalent to IE Conditional Comments in Mozilla based browsers like Firefox.
Depending on your server-side platform (if any), you could elect to sniff the browser type and conditionally include different style-sheets. Of course, you want to avoid this as much as possible. Usually by fixing things to work consistently across all browsers, you end up with better, more robust, site that will probably save you time in the long run.
Regarding CSS differences, you might consider starting with a reset CSS, such as the one suggested in Joe's answer, to provide a uniform baseline.
Regarding standardization of HTML and other features between the browsers, you might want to check out modernizer.
I find this script will solve a lot of quirks (minus IE of course) reset.css
In Firefox there are plugins and extensions. Could you please explain to me why these addons have different name and tabs ? Does they differ so much so they need different names? I think it's a little unnatural to differ these things, extensions have so much and more functionality, what they lack for comparing to plugins?
The difference is both historical and real:
plugins are compiled, loadable modules, originally descended from NPAPI; they can live outside of the browser's process space (which leads to all kinds of fun interoperability issues and vulerabilities). The most common examples of these are Flash and Java - both request a sub-window ("viewport" or "canvas" (not HTML5's canvas - that's something else altogether: a native part of the webpage)) inside the webpage and handle it themselves, in a way that's largely independent of the browser.
extensions are written mostly in JavaScript and XUL. Since the extensions act as part of the browser, they have wider access privileges than JS-in-a-webpage, but they are still subject to some limitations. The most common way of integration is to hook into some part of FF's functionality and extend it.
So, although the plugins and extensions might appear to be related, they're very different technologies behind the scenes.
According to Mozilla, plugins help the browser display content, such as playing media. Extensions actually add new functionality to the browser.
See the first couple paragraphs here:
https://developer.mozilla.org/en/extensions
One are programs which runs side-by-side of firefox. They get a canvas and when they paint on the canvas, firefox renders it. Notable examples: Flash, Java, QuakeLive.
The other are programs which run in the javascript interpreter/compiler of firefox. They extend firefox functionality more directly, since they have access to the firefox internals and are not merely a canvas. Also, they are much more portable since they do not require underlying support of the operating system as much.
There are advantages and disadvantages to both approaches, and they solve different tasks.
We want to make an audio based web based app that will have many sound snippets. We want to cache these files so that performance is good and not dependent on network speed. Can HTML5 cache audio for offline mode?
It certainly seems to me that this should work, and I can't find any documentation that says it shouldn't work (either from the W3C or from vendors like Apple), but putting audio files as resources in cache manifest just doesn't seem to work with Safari on the iPad & iPhone at least.
Sounds play fine when the app is in online (although it seems to load them anew each time and not cache them) and it doesn't complain about the resources not being there when in offline mode (which is does immediately if you forget to include a JavaScript, CSS, HTML or image resource).
Instead of complaining (or loading); if the element has a control that control is replaced with a box that says "Cannot play audio file.". Alternatively, if it's an element without a control - i.e. accessed via JavaScript all to .play() - then it simply just doesn't play (it doesn't cause any errors, there is just no sound, the JavaScript otherwise continues to execute normally).
I have tested this with pretty small (<20k) files and the result is the same, so it doesn't seem to be size related, just a blanket refusal to copy. I'm not sure if you can encode sound as a resource in a page (e.g. encoded in base64) the way you can with images, but I'm going to investigate that option - I suspect that would be possible. I tried encoding audio data as data URI strings and even tried generating audio on the fly - both work fine in Safari on the desktop but do not work on the iPhone / iPad OS (at least on version 3.x - I have not tried on iOS 4, but it won't be out for a week, and is not expected for the iPad for a few months, even if they do fix it).
I would guess the refusal to cache sound files in iOS is an implementation bug or intended limited functionality. It's certainly annoying and a show stopper for a lot of use cases.
I am not sure what happens with other HTML5 clients, I'd be interested to know (in particular on Andriod). Google's support for audio hasn't been stellar either, so it may suffer from the same limitations.
You could always develop a decoding/encoding layer that talks to the client SQLlite DB
I don't see any reason why you can't specify audio files in the cache manifest.
Jeff mentioned the concept of 'Progressive Enhancement' when talking about using JQuery to write stackoverflow.
After a quick Google, I found a couple of high-level discussions about it.
Can anyone recommend a good place to start as a programmer.
Specifically, I have been writing web apps in PHP and would like to use YUI to improve the pages I am writing, but a lot of them seem very JavaScript based, with most of the donkey work being done using JavaScript. To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
Anyone have some good places to start using this idea, I don't really care about the language.
Ideally, I would like to see how you start creating the static HTML first, and then adding the YUI (or whatever Ajax framework) to it so that you get the benefits of a richer client?
As you've said
To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
This isn't progressive enhancement. Progressive enhancement is when the site works perfectly without JavaScript or CSS, and then adding (layering) these extra technologies/code to increase the usability and functionality of the website.
The best example I can give is the tag input box on this website. With JavaScript turned off, it would still work allowing you to enter tags separated with a space. With JavaScript turned on, you get a drop down with suggestions of previous entries.
This is progressive enhancement.
See also Unobtrusive JavaScript which is the bedrock progressive enhancement is built.
Going at it from the other direction is sometimes referred to as graceful degradation. This is usually needed when the site is built first with the enhanced functionality afforded by the various technologies then modified to degrade gracefully for browsers with those technologies are not available.
It is also graceful degradation when designing to work with older browsers (ancient in the Internets terminology) such as IE 5.5, Netscape, etc...
In my opinion it is much more work to gracefully degrade the application. Progressively enhancing it tends to be much more efficient; however, sometimes the need to take an existing app and make it accessible in these lacking environments arise.
Basically, if your site still works with JavaScript turned off, then anything you add with JavaScript can be considered progressive enhancement.
Some people may think that this is unnecessary, but plenty of people browse with addons like NoScript (or, with JavaScript simply turned off in their browser settings). In addition, many Mobile web browsers may or may not support JavaScript. So, it's always a good idea to test your site completely with and without JavaScript.
Progressive Enhancement is a development technique that stresses the primacy of the semantic HTML, then testing for browser-capability and conditionally "layering" on JavaScript and/or CSS enhancements for the browsers that can utilize those enhancements.
One of the keys is understanding that we're testing for what the browser can do, as opposed to browser-sniffing. Modernizr is a very popular browser-capability test suite.
Progressive-Enhancement is inherently (section 508) accessible; it provides for meeting the letter of the law and the spirit of the rule.
The Filament Group wrote the excellent "Designing With Progressive Enhancement" book on the subject. (I am not affiliated with Filament Group, though they are so freaking smart I wish I were.)
This is such an important concept and it saddens me that so few web developers understand it.
Basically, start by building a site/framework in Plain Old HTML -- structural elements, links and forms. Then add on some style and then shiny stuff (Ajax or what have you).
It's not very difficult. Like palehorse says, graceful degradation is more work.
Websites should work in any user agent, not look the same (not even look but sound if your vision impaired), just work.
Progressive Enhancement:
The plain HTML/CSS site is awesome (fully working and user-friendly).
Adding JavaScript defines a new level of awesome.