As a lone developer with limited resources, I made the decision some time ago not to continue support for IE8 and IE9.
To manage the situation I use IE's conditional comments - I now also use Modernizr to detect support for individual features, which the above browers do not support anyway.
Javascript is also a given for me - if you don't have it, then sorry but we can't do business.
I was therefore considering removing conditional comments and letting Modernizr/javascript do the job.
Conditional comments do break a lot of things that scrape the site - for instance CopyScape will not work - there's also testing software I use that breaks and/or gives out false signals.
Does anyone have any cast iron reasons NOT TO remove them or TO remove them?
Given that support for conditional comments was removed from IE10, I would recommend against using them at this point in time. It's 2017; time to move on. (That's my take, anyway; YMMV.)
I would consider providing a bare bones version of the site designed for any browser other than your preferred one (which, conveniently, also helps you support experiences you didn't plan for).
Related
I want to make a desktop app with electronjs. For this I want to use custom elements. (not Polymer)
But here on MDN is a note that the spec will be rewritten:
Spec for Custom Elements will be rewritten in early 2016. All current
implementation are experimental and the upcoming standard will not be
compatible with these. Web sites using Custom Elements are likely to
be broken in the near future.
Are there any updates in this? What will change? Are there new specs available? Where can I find more information on this?
The Custom Elements W3C Editor's Draft specification is available on GitHub. It was last updated on June 1, 2016 (as of this writing) though you can expect it to continue to be updated. To answer your first question, yes, there are updates and you can see them directly at the spec. Which also answers your third and fourth questions.
Because it is a draft, you cannot expect any browser to support it yet (though some claim to). Polyfills are your best bet if you want to use it now, knowing that since you are using bleeding edge technology you will need to stay on top of browser implementations and constantly review what works.
Because it lives on GitHub, you can file bugs against the spec if you want a say in how it progresses (it is not tech support, however). Looking at open issues essentially answers your second question.
As for browser support, Can I Use is tracking where it stands today including who does and doesn't have it on their roadmap. Note that browsers who claim to support it are supporting an incomplete spec that will change. That same page also has a link to lots of handy resources to help get you up to speed.
tl; dr: making website for biological researchers. Are these guys apt to use IE8?
I'm developing a website that will act as a reference for biology researchers. I'd like to implement loads of HTML5 and CSS3 if I can. But I can't spend forever developing it though, and fixing websites for IE8 takes too long, especially with the heavy reliance on SVG elements I have planned. With such a user base (researchers), would it be safe to drop support for IE8 and below? I've heard that it's mostly banks and airline companies that use IE <= 8, but I've never come across an actual statistic, other than that global usage of IE8 is around 10%, which is a bit high for my taste.
The short answer is, of course, "it depends", but some things you might consider:
-Who benefits from people using your site? If it's you who wants them to use it, then the onus is more on you to make their lives easier by supporting whatever browser they use (most ecommerce sites would fit this category). If there's less value to you and you're genuinely just trying to be helpful by producing a valuable tool for you particular research community, it'd probably be more reasonable to expect them to update if they care enough.
-How much effort would support be? If it's little extra effort, then just do it, but for what you've described it sounds like support would be very difficult. If it's going to take 5 times as long to support 10% more people, I personally wouldn't bother.
-What sort of age are they? Not always true, but generally speaking younger people will tend to use more recent browsers.
In your position, I'd try to ask 10 or so people who you'd expect to use the site what browser they use. If only 1 or 2 people would be affected, I'd ditch IE8 support, and make sure the site falls gracefully back to a page explaining why they aren't able to use it and how to update their browser.
Points to consider:
Many people who use IE8 may also have other browsers installed as well. (choice of browser isn't an 'either-or' option)
How about making your site semi-functional for IE8 rather than entirely non-functional? If parts of it don't work, explain that to the user, but don't stop them using the bits that could work for them.
There are fall-back options (polyfills) for IE8 that allow you to do some modern browser features, including SVG -- see here. They won't work as well as modern browser, but they might make it possible to support IE8 a bit more than you think, without too much extra work on your part.
If your resource is useful enough, and the IE8 users can see what they're missing, it might push people to upgrade in order to use it.
Surely a group of intelligent people (scientists, researchers) would be sufficiently technically literate that they'd at least know about alternative browsers, even if they are still using an old PC that originally came with IE8. With luck, your target market may have fewer IE8 users than the general population.
I am learning how to program and my goal is to build a simple functional prototype...I'm at the very beginning.
I am not concerned with the visual design at this stage, other than as it relates to being able to demonstrate the functionality.
My question is: do I need to worry about ironing out cross-browser bugs in the HTML/CSS, or can I do development on a single browser? (Perhaps a better way of asking this is does the back-end programming have any effect on which browser is displaying it).
If you are at the very beginning and only want a functional prototype, do not worry about cross browser HTML/CSS. In fact forget the CSS altogether and focus on printing just standard HTML. Since the visual design will change, focus on the content, styles can always be applied and switched later.
If you need Javascript/AJAX stuff I would recommend using a library like JQuery that has already solved many cross browser problems for you.
The back-end stuff "Perl, PHP, Python, etc" shouldn't care about the browser as it is simply printing text for the browser to render as it will.
The back-end programming will affect the way a given browser displays your page and there might well be two schools of thought on whether you should be picky about the browser compatibility issues.
On the one hand, if you're just finding your feet in web development it might be asking too much to expect to have a standards-perfect, cross-browser site or application every time. It might be better to focus on actually accomplishing a finished result and learning as much syntax and technique as possible.
On the other hand, it might be argued that it's a good idea to get into the habit of adopting good practices now and recognising the sorts of things that are going to give you headaches... probably when you view your page in Internet Explorer. This takes more time to reach a finished product, but it would teach you good habits up-front.
Really it comes down to your own approach and preferences. Do you want to be detail-oriented and turn out a polished result in a longer period of time, or would you prefer to just get to the finish line and identify issues on a case-by-case basis?
Do car prototypes have a working stereo, leather upholstery, chrome rims, dice, and other random stuff which does not demonstrate the functionality of the newly-designed car?
My rule of thumb is that if it takes you more than 10 minutes to make it look acceptable to others (I'm completely fine with a disgusting design when prototyping), you're spending too much time on the aesthetics and less time on the actual clockwork.
What good does a "pretty-looking" site do if it has no functional layout?
This depends on both your audience and on your tooling. If you are trying to support all users on all browsers, then you will certainly need to do testing on those browsers (although actively developing on those browsers may not be necessary), whereas if you only need to support WebKit-based browsers (Chrome, Safari) or WebKit-based browsers and Firefox, that is less testing that you need to do.
It also depends on your tooling. For example, if you are writing directly in HTML and CSS, then you are much more likely to run into browser compatibility issues. However, if you use a tool such as GWT, which can generate browser-specific output automatically, there are fewer such issues to deal with.
Note that you can use Selenium (aka WebDriver), to automatically test your code on multiple different browsers, even if you only actively develop within a single browser environment. That way, you can know if you've broken something, but not have to constantly manually test in multiple browsers.
Due to the low level of support for HTML5 in older browsers should one (or could one) use any part of HTML5 at this point in time for a new website that will have varying users with the full spectrum of browsers (and versions) to access the site?
EDIT: To fill in some more info here. The website in question, for simplistic comparison, would resemble fb. I am not talking a social website just one that will reach that type of vast audience (anyone can join) and will be an interactive portal (not just a site full static content being displayed).
First, HTML5 is a standard that includes the previous standards. Therefore, you are already doing HTML5 without knowing it.
Second, HTML5 could be compared to CSS in terms of feature grouping (CSS = CSS1 + CSS2 + CSS3 and so on). In other words, it is a collection of individual features and not one big thing.
Third, you will have to implement new HTML5 features one day or another. Why wait? Ooh right some people do not care about "modern browsers". You have a responsibility as a Web developer/designer to inform people about the consequences of obsolete browsers.
Last but not least, there is tons of information already... Like this website: http://diveintohtml5.ep.io/.
Some complementary info can be found from this answer and this other answer I wrote for other questions about HTML5.
Have fun! :)
Thank god MS is finally campaigning to get gid of IE6 but it surely will be in China for years to come due to pirated windows software which I had altogether too much experience with; despite this push for higher standards tons still use IE7, 8, and some even 9 is not perfect. Chrome IMOP is exceptional followed by Safari and FF for HTML5 support but even these browsers are not perfect.
I think it is ok to use features css3 and HTML5 such as canvas but in an unobtrusive manner like javascript enhances UI HTML5/CSS3/jQuery should enhance not be the content.
With javascript we can check for browsers and use appropriate methods this concept should also be applied to HTML5. So if you do implement anything I think it's important to understand how to detect and this is probably the best resource to start with.
http://diveintohtml5.ep.io/detect.html
You can use all of the new HTML Field types in forms safely, any HTML 5 inputs in browsers which don't support html 5 will simply fall-back to a standard type="text" inputs.
Mobiles currently seem to benefit from HTML 5 forms most at the moment as they recognise the input type, lets say "email" and then provide an email specific keyboard layout to the user.
Its also simple to provide JavaScript fall backs for some html 5 elements with http://www.modernizr.com/
Recently, I have been battling with: weird table borders/margins, div alignments, positioning problems, and am having a down right nightmare supporting Internet Explorer 6. I know a lot of you like me are forced to support, IE6-IE8, Web-Kit, and Mozilla based browsers.
My questions to you are:
What are the important rules you use before hand, when developing across multiple browsers to save you time?
How do you prevent yourself from writing incompatible tags?
What is the best way to avoid hacking your code?
Where do you find research on browser compatibility, do you use any tools?
Finally, when do you cross the line/where do you draw it?
I usually code against Firefox (or Safari) first. That usually produces the best results across browsers other than IE. I then hit IE8, IE7, then finally IE6.
Know what tags are going to cause you trouble and avoid using them at all costs. It's all about how familiar with each browser's issues.
Don't use hacks. Use IE conditional comments. By using conditional comments, you can load one stylesheet for all other browsers, one for IE8, one for IE7, and yet another for IE6 (if you need that kind of granularity to fix your issues). It will give you nice clean stylesheets with as little hack-i-ness as possible.
LitmusApp
There really aren't lines to cross. If you need compatibility, you need compatibility. You just whiddle down your issues as best as you can one at a time until you have something usable.
I would say to start with standards-compliant code. Always test in a standards-compliant browser first like Firefox, or Safari/Chrome. I prefer Firefox for the addons (such as Firebug, HTTPFox and the Web Development Bar). Then work your way DOWN (and by down, I mean all versions of Internet Explorer).
Try to stay away from temporary fixes per situation or site and generalize your code as much as possible. For example, as Justin Neesner said in his answer, using conditional comments and a general style sheet for IE6 , 7, and 8 will knock out most of your problems with layout and formatting, without using (too many) hacks. You can reuse the IE stylesheets, and just place the site-specific code in it.
Use a testing platform like browsershots, netrenderder or LitmusApp so you can see what your site is doing in as many versions of browsers out there. Studying browser compatibility deeply will make you pull your hair out, but any great resource like quirksmode.org can give you information on the little gnats of incompatibility, so you don't go crazy, and bald.
As far as when do I cross/draw the line, it's 99% Internet Explorer issues, and if it's close enough to looking like FF or Chrome/Safari, I'm done. Almost like art, it's not when you're finished adding, it's when you're done removing the crap you don't want to see; that's when you know it's done.
I say there is not that much you can do except sticking to the basics:
Code standards compliant HTML
Validate early, validate often
For Javascript, use a framework like JQuery, Prototype or Dojo
Pick one "main browser" you optimize for first.
in every project, there will be a number of issues, but if you stick to these points, not too many.
I find it extremely helpful to build 100% W3C valid code. Not because it matters - much of what the W3C validator complains about will not make any difference in real world browsers - but because being able to run a validation, and getting a green light and knowing that all is well on that end is very helpful.
To test multiple IE instances at once, you can use IETester. It's not perfect - conditional comments won't work in it for example - , but mostly usable in everyday development work.
use a doctype like html 4.1 transititional which makes ie6 render in standardsmode. You can also use a reset stylesheet.
Use strictly compliant HTML and CSS markup and do not use browser proprietary extensions to CSS.
IE 6 does not implement CSS correctly beginning with its absolute ignorance of the box model.
IE 8 on the other hand has a test suite to prove they implement every aspect of CSS 2.1 correctly (which no other browser does).
Develop for Firefox as stated above and make a decision about supporting IE 6 & 7 or not. Frankly, I no longer develop separate style sheets for those browsers. They don't have enough market share (at least on my site.)
Given the interest in HTML 5 and the lack of interest in XHTML 2, develop HTML 4.01 Strict and follow these practices: (which are recommended in HTML 4, and required in HTML 5 and XHTML 1.1)
all elements and attribute names must appear in lower case,
all attribute values must be quoted,
non-Empty Elements require a closing tag,
no attribute minimization is allowed,
In Strict mode, all inline elements must be contained in a block element.
Why to learn HTML 4.01 Strict with references.
Also see the CSS 2.1 Test Suite
So I have been running around for a while now, 26 days later I think I am ready to give some feedback to my findings.
Coding:
First of all, I found that column systems seem to cut down the amount of HTML and CSS written. They are also very cross-browser friendly. Although there are many of them, I found that the 960 Grid System works the best for me: http://960.gs
Next up I found that Ruby has a cool extension for CSS called, LESS. This has been ported over to .NET and can be found at: http://www.dotlesscss.com. It is easy to setup, and is very powerful when used right.
Javascript, can be tricky but I found out that avoiding certain selectors and shortcuts in languages like JQuery will not only speed up the performance of your application, but exhibit less awkward behavior.
Testing the browsers:
Here comes the interesting part. Without any software I found that testing my applications against Internet Explorer 6 and Safari at the same actually helped increase the speed of my development. Firebug and Firefox actually cause me to develop around the problems and this is what causes a lot of extra code. When developing simple code against IE6 and Safari I found that going back to Firefox and IE8 is incredibly easier. Most problems I have had were with border widths, which were easy fixes.
The best software solution I found that was accessible to me was Expression Web with Superpreview, if you ever wonder why Microsoft releases a bunch of version of IE, its probably so they can sell you tools like these.
Anyway, that's my 2 cents for right now.