I'm writing some code that involves CSS tabs, but IE doesn't support the :target css3 attribute. I have a work around by checking the hash value in an interval (ew), but I want to only have that code run when :target is not supported. I would do the regular IE check, except early versions of Firefox do not support it, nor does early Safari or Opera. Does anyone know how to test for :target support?
You can test for CSS support by adding a rule like #someid:target { visibility:hidden; color:#abcdef; } and then setting the target to #someid, reading if the color is #abcdef, and then reseting the hash.
This will, however, generate entries in the browser history: 1 for when you navigate to the id, and 1 for when you reset it to whatever it was before. It may also create a flicker in your tabs, so that may not be ideal - but I don't know what you can get away with.
Ideally, tabs should ideally read and write the hash for bookmarkability. But I don't think that :target is the ideal solution to creating tabs. I know it looks appealing to begin with (did to me). Given the poor support of the selector, how badly it scales with nested or multiple tabs, and how volatile it becomes with other markup (someone adds a #skip-to link on the page), it is less headache to implement with good old clicks.
Related
I'm developing a website that should run in ancient browsers (IE 7/8/9, Safari 5.1.7). Our target customer is the old people.
I'm no expert in javascript and I searched for solution. My title question is very straight-forward.
I used input radio and others that has custom design using before and after.
If it's checked. I just toggle in after and before display property in css.
The problem is when the user is using ancient browser, the input radio will never appear. My idea is toggle display in input radio if the browser doesn't support pseudo-elements.
For CSS feature detection there really is no need to reinvent the wheel, tools like Modernizr do this perfectly and have a very small footprint, since you can select only the feature detects that you need.
Seeing as you want to support IE <8, I would strongly advise you to use it, since you're probably going to run into a lot of situations where CSS/JS features are unavailable.
Detect if they have a sufficient browser: http://caniuse.com/#feat=css-gencontent
Basically, IE8 (maybe 9 depending on what you need) and older don't work, everything else does.
You may find the library Modernizr useful in this instance. It allows you to test for browser features.
Optionally if you want to shim it so you know that the browser will support it you can use Selectivizr
I've made a web-app using the jQuery Mobile framework for which I would like to provide a fall-back, for lower-spec phones.
My question is... what is the best way to target JQM-capablephones? I saw a similar question posted on the jquery forum. One of the answers suggested http://detectmobilebrowser.com/ which provides a long list of handsets.
Is this the best way, or should I be testing for browser-capabilities rather than actually targeting handsets. If it is the latter what feaures are considered to be 'Grade-A' featues?
Cheers
Progressive enhancement is what you should aim for, jQuery allows you to have a single codebase and have it work across the range of devices.
Consider this:
All links to other pages are regular html links, links will still work without AJAX support because they'd just send you to the location of the required page
All major framework elements are built around lists, links, and a few divs. No HTML5 required for rendering content
At the bare minimum, all phones can display a good amount of styling, allowing you to display the content no matter how capable
Do you have custom interfaces which wouldn't work at all without full support for jQuery mobile?
I agree that graceful degradation is the best solution. I would add that using the noscript tags is also a good way to provide graceful degradation by adding adding functionality via HTML for phones that have no support for JS.
I think it will be difficult to find a browser-capability (or even a set) that defines whether the phone will work with JQM. In my own experience I have used WURFL, an open source device detection library, that provides capability information. However I used it to target specific devices to include device specific CSS and remove all JS for other devices that I know do not support it (to remove the overhead of the JS being downloaded).
WURFL: http://wurfl.sourceforge.net/
JQM advertises that it provides graceful degradation:
Graceful Degradation: jQuery Mobile uses the very best HTML 5 and CSS 3 features to provide the best possible experience in the most-capable browsers. However we don’t consider this to be an all-or-nothing proposition: Less capable browsers will still receive the best possible experience that their platform can handle. They may not have all the gradients or fancy transitions of the best platforms but they’ll still be highly usable. The most basic browsers will easily degrade back to simplified HTML and CSS.
I have also tested multiple JQM pages in a single mobile page which work great (very speedy) in JQM but suffer from the same problem mentioned (all pages show up when javascript is turned off in the browser of a smart phone). To work around this issue, only use a single page per JQM page (you give up speed and uniform page transitioning though). In regards to the NOSCRIPT tag option, that tag is NOT universally recognized in all browsers. To work around that issue, you could try something like the following:
<div id="no-js">
<!-- Place HTML without javascript here -->
</div>
<div id="js">
<script language="javascript">
// place javascript here which would be ignored by browsers not support javascript or with
// javascript turned off
document.getElementById("no-js").style.display = "none"; // be sure to hide the non javascript
// div
</script>
</div>
The above logic would work in either NOSCRIPT tag type browsers as well as those that do not recognize NOSCRIPT.
dlausch
is it more efficient to use $('.active') or $('div.active') ? I have always avoided including "div" because it's extra text in the javascript file I don't want the user to have to download.
Older versions of IE will benefit from the inclusion of div because they don't support getElementsByClassName().
Because of that, every element on the page needs to be selected with:
document.getElementsByTagName('*');
...and manually tested to see if it has the active class.
If you include div, then it is able to narrow it down a bit, since it can do:
document.getElementsByTagName('div');
...then test only those elements.
When I say older versions, I mean IE6 and IE7 since IE8+ supports querySelectorAll.
EDIT:
Browser suppport:
getElementsByClassName: http://www.quirksmode.org/dom/w3c_core.html#t11
querySelectorAll: http://www.quirksmode.org/dom/w3c_core.html#t13
It depends. If you mean performance.
I prepared special test for everyone on JSPerf: jquery class selector test.
On my browser and computer (FF 3.6.13 and Core 2 Duo 1.6) div.active is a bit slower. But found it variable - it seems GC has something doing here.
And after few more tests it seems that div.active:
Speed is variable on FF, sometimes GC turns on 'div.active' test, but generally difference is very small.
Unnoticable difference on Chrome and Safari
Faster on IE9
I like to include the tag name if it helps self-document the code. If I can use
$("nav.primary")
instead of
// this is the primary nav
$(".primary")
I tend to do it.
I guess the best way to get some speed on large pages is to use find instead.
$( your-container ).find("div.active")
Since you always? know where you should look, you can create your own scope. So that the browser only need to search within that area of code.
By the way, you don't need to care about size of the css, EVER :)
Use css minifing tools to minimize the css when the site is in production mode. You can also set your web server to automatically gzip your css files before sending the to the user. And if you don't change your css filename on every pageload, the browser cache up to whole css file.
CSS selectors in jQuery used to be optimized similar to how you would do it for browsers, see: http://css-tricks.com/efficiently-rendering-css/
Specifying a generic tag anywhere, even with an ID or class would be dramatically slower than just specifying the ID or class alone. See:
http://www.no-margin-for-errors.com/demos/how-to-optimize-jquery-selectors/
The above uses jQuery 1.3. Since jQuery 1.4 and the introduction of the Sizzling selector engine, this is less important from what I understand. See:
http://hungred.com/useful-information/jquery-optimization-tips-and-tricks/
For myself, I decided in CSS to use whatever reads the easiest, and I am more specific there since that is only parsed once. In jQuery, however, I have been more careful since those selectors could run thousands of times over the life of a page.
If I have a CSS solution for all browsers except IE then what should be chosen for IE?
CSS expression in IE conditional comments
or
JavaScript in IE conditional comments
or
jQuery + plugin in IE conditional comments
Which will be less slow in rendering speed?
CSS expressions only work in Internet Explorer only, so you'll have to use Javascript in some form, for complex styles. Firefox, Safari and Chrome recognise a lot of CSS3 so if you're trying to do something like rounded corners or multiple backgrounds you could use that and look for an expression equivalent for IE.
However, I would recommend using jQuery. It's built to be cross-browser, and your code will likely end up simpler than using combinations of expressions/browser-specific styles.
jQuery plugin, if I'm already using jQuery.
I don't think I ever used CSS expression, not even as a hack.
As for a non-jQuery JavaScript library - I'd have to learn it from scratch, it might re-implement some of jQuery's features (so doesn't benefit from jQuery's engine, cross browser, etc), and it may not be written in the convenient style of jQuery, like chaining and liberal null checks.
You should avoid CSS expressions.
As for JavaScript vs. jQuery, that depends. If I can do it in just a few lines of JS without cross-browser issues, and I'm not already using jQuery for other stuff, there's no reason to load the entire jQuery library. Anything much more complicated than a few document.getElementById or alert calls, though, and I'm likely to want jQuery available, and at that point I might as well be using jQuery plugins
Do not use CSS expressions.
The reason:
CSS expressions can be evaluated many hundreds of times per second. Especially considering that IE is not the fastest horse in the race, don't do that to the poor old browser.
The average IE CSS expression is evaluated over one thousand times in the time the person views the page.
What's more, it is just Javascript - it doesn't work if JS is off, creates the same garbage global variables, et al. So the gain is nill, the loss is high.
Do not include JQuery just for this.
But if it (or Mootools etc.) is included, use them by all means.
Creating your function without JQ is simple and straightforward.
Just have it run on page load and resize (http://www.devarticles.com/c/a/JavaScript/OnReset-OnResize-and-Other-JavaScript-Events/1/) and that should do the trick.
Use IE conditional comments and you are even valid.
<!--[if IE]>
<script>
var dumbIE = function (){
//your stuff
}
onload=onresize=dumbIE;
</script>
<![endif]-->
Although I strongly disrecommend using CSS expressions (is there really no "normal" CSS hack for the particular problem? doublecheck it, twice, if necessary ask question here), I would go ahead with it. This removes the risk that the your application breaks in case that the user has JS disabled. JS is at its best when used unobtrisively and in your case it is clearly not the solution.
Updated to new focus: If you've got it looking good in everything but IE (an all too common situation...) then you need some method of writing code that only IE sees/executes. You can do this with browser sniffing in JavaScript, conditional comments in CSS and HTML. IE CSS bugs (anyone else have some good links?)
(Old answer:)
CSS expressions: Internet Explorer only shortcut.
JavaScript: Have to code every stinking thing yourself. Works "cross browser", but you still need to test in all the browsers to make sure it's doing what you want.
jQuery: cross browser, easy, simple. :D
Wait for Microsoft to improve IE.. haha.
Ignore IE -> Encourage your web-visitors/users yo download/use a different browser (IMHO, firefox is a really, really good choice, if not the best)
There are ways of making IE 'compatible' with modern, css-stylized websites (such as the well-known comment <!--[if lte IE 6]>...<[endif]--> and so on.. but anyway, it's up to you.
so i've been working on a website now for like a couple months and i test it on chrome mainly. but before i release anything big i always check it on firefox 3.something and IE7. Now i've received some complaints that that it doesn't look very good in IE6 and when i do check it... well ya it doesn't look like its supposed to. Is there any quick fix that i can add to my HTML to make it look the same in IE6 as it does every where else?
At the risk of downvotes: have you tried adding IE6 to your test matrix? If you have a significant number of users complaining that it looks bad on IE6, you clearly have a significant number of users using IE6 to use it, so it seems like it would be worth your while to just add it to the set of browsers you check before release. Just sayin'.
A really good start is http://code.google.com/p/ie7-js/ Just place it in conditional comment tags in the head of your document and it will make ie6 'standards-compliant'. After that make sure you have seperate css documents for each version of IE, and make sure all of your code is valid with w3's validator. Also declaring a doctype can fix many issues, but it MUST be on the very first line that the browser sees.
Edit: also, for png transparency, I've found that this http://www.twinhelix.com/test/ (IE PNGFIX 2.0 Alpha) works best.
There is no quick trick to getting everything to work. Pretty much have to examine each element that looks different.
That said, you might try looking at a CSS reset file.
Yahoo has one.
And if you search google I'm sure you can find others.
Read this: Internet Exporer box model bug. Also try using YUI reset or Eric Meyer's resetReloaded to set a baseline for all your styles.
And stop developing in Chrome! Try Firefox with Firebug.
How badly does your website 'break' in IE6? If it's minor, then I wouldn't worry about it.
How critical is it that it works in IE6? It's share of the market is slowly but surely declining (Looking at my own logs from a Government website also shows that IE6 is definitely going away). Can you display a message on your website letting users know if they use IE6 and advising that they upgrade?
There are many reasons to upgrade, and educating your users as to why they should upgrade might also be worthwhile?
Uhm... if there is a simple solution I really want to know it. :)
But you can anyway use this good Microsoft tool to cross-test your pages.
It can be usefull for compare the final render of a website.
CSS resets will probably do nothing if it looks fine in IE7. Things like double margins when floating and overflow:auto bugs are things that need to be manually added for each occurance. I'd suggest adding the following line to your head tag:
<!--[if lt IE 7]><style type="text/css">#import "/stylesheets/ie6.css";</style><![endif]-->
and then writing an ie6.css file to fix all the bugs (yes, one at a time)
Probably not what you wanted to hear, but it is why everyone hates IE6 so much
you can check version of client browser and include css fixing for that browser. but most simple solution is to show an alert or notification to client that his browser is outdated and provide links to download latest browser
here are some way to show that notification
http://garmahis.com/tools/ie6-update-warning/
i like this solution
http://www.browser-update.org/