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 4 years ago.
Improve this question
HTML 5 has interesting features for developer and user, but if customers are still demanding to have support for old browsers should designer/developer go for HTML 5 ? Or should stick to good old ways using JavaScript libraries, flex and flash to do the heavy lifting.
If accepting HTML 5 is too early, how long you think it will take to use HTML 5 features for big web application? (hear by big i mean application still reaching huge number of users with different OS and browsers combination)
Do you think HTML5 will carry all the issues(cross browser stuff) that web developers have faced over decade, or it will make life easier?
In a word: Yes.
People are STILL using IE6, and will be using IE7 for many years to come. If you're creating a public-facing application then you have to take into account browsers that may be being used by millions of potential visitors.
There are features that will degrade gracefully, and those are great.
If you're building a web based app that's not public, then you can go ahead an use whatever you like. I do a lot of development work where the final project is limited to a specific browser but in those cases the application is never available to the public.
Sitepoint has some very nice articles about this very subject:
http://articles.sitepoint.com/article/html-5-snapshot-2009
http://www.sitepoint.com/blogs/2009/05/26/html-5-now-or-never/
Also, check out the following to see what browsers support what new up-and-coming (or been here a while) features:
http://a.deveria.com/caniuse/
No, I think it isn't early.
Start now and slowly start adopting new elements (except video/audio as they are the least supported). For IE, you have JS solution that adds new elements and adds ability to style them.
Try, really. You'll see how much it's easier to tag your document :)
When people talk about "cross browser issues" they almost always mean "IE issues". Modern browsers, that is, anything but IE, pretty much work well with modern standards and practices and dumbing down the web just for IE is just sad.
There are a number of javascript workarounds to make older, non-standard browsers like IE work with HTML5 though I don't recall them off the top of my head but parts of HTML5 can be made to work easily in IE; such as the new elements aside, section, etc.
In my situation, we just completed an ecommerce solution using HTML5 elements with no problems but had to include the workarounds and hacks for IE.
Naturally, you need to take your audience into account. Check your analytics. But there are some great tools if you want to take advantage without leaving everyone behind:
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
I'd also recommend you take some time at html5doctor.com where they discuss what can and can't be used now. A really cool resource they are working on is the html5 reset: html5doctor.com/html-5-reset-stylesheet/
Oh, and use ogg ;)
I recommend you take in use any new feature you think is interesting but make them degrade gracefully. It can be a bit of work, but that's the life you choose if you go outside the life of using libraries. However you will probably learn some very valuable skills.
Using HTML 5 isn't an all-or-nothing solution, much like CSS3 there are specific features you can start using today that will enhance your sites for browsers capable of using them.
It's up to you to make a decision on what those features are and how far you can take them. If IE6 and no-Javascript are big factors in your audience, then this will likely be limited. However, if you are happy for those users to get a not-so-pretty but still-usable experience then go ahead!
Related
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 2 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Which syntax and features should I use if I wanted to write a webpage that could be correctly parsed by any device realistically still in use?
By currently in use I mean also devices whose usage is not statistically meaningful to be included on browser usage statistics, but still reasonable enough to be used in the real world without being too much of a stretch: e.g. A screen reader, a Point-Of-Sale/Kiosk Device, an Internet appliance like a smart TV or a console.
I've recently been assigned to develop an HTML landing page requiring support for - hear me out - the ancient Microsoft Internet Explorer 6. Yes, you read that right.
Long story short, it was in the requirements for a public administration project that was in a legal limbo for a long time, and reworking these requirements would be more problematic than developing it and be done with it. At least according to my boss. Besides, it shouldn't be that much different than writing a current-day HTML newsletter.
But it got me thinking - what's the oldest browser (as in, the one with the oldest HTML standard support available) that I could realistically find in the wild?
I'm not talking about relevance or caniuse-level-of-support numbers, just something that for some more-or-less realistic reasons (excluding "here's a Windows 3.1 VM getting to the internet" retro challenges) people would still be using to get online. Also some security requirements (mostly updated SSL/TLS) cut off quite a bit of older devices, mostly games consoles like the Dreamcast, PS2 w/Network Access Disk and the PSP, or the original Nintendo DS, so those are also excluded.
Other than the aforementioned IE6.0, I can think of Opera Mini browser (which version?) for some legacy mobile phones, or maybe some kind of internet appliance still using the Netfront runtime (IIRC The Playstation 3 still uses a pre-webkit version of it).
Any suggestion?
preword - apologies this became a bit of a rant, I will try and tidy it up later and focus it more. I also understand you may have to listen to your boss so this has become me ranting on your behalf to your boss. I hope you can use some of it to construct a strong argument with your boss to get the spec changed. It also doesn't answer the question as it is titled. Probably worth a few down votes but I enjoyed having a rant!
Given the comment the OP asked this answer is applicable to that.
What are the oldest browser standards I need to support for accessibility?
The WebAIM annual survey is a great place to get this information.
Under the section 'Browsers' we can see that 2.1% of respondents still use IE 6,7 or 8.
Unfortunately they do not indicate what split of those who use IE6 but I would imagine it would be less than 0.1% overall as very few sites still operate on IE6 correctly.
I personally develop to IE9 standards, so use ES5 for JavaScript (or compile to ES5), HTML 5.0 features and CSS3 non-experimental features.
The reason for this is that those who do use IE8 and below tend to be screen reader users due to compatibility with the software they own. They also tend to use a very specific set of websites due to the fact that most websites just will not work for them.
Many people would argue that you must include everyone, and in an ideal world you should. However you also have to consider that your goal in accessibility is to provide the best experience possible for the widest number of people. This is not possible using IE8 and below as you lose a lot of the HTML5 standards that are useful for accessibility (particular form related attributes, navigating by regions such as <main>, <nav> etc.).
So what about the people stuck on IE6-8 then?
As stated they tend to be screen reader users. The beauty of this is that as long as you develop valid HTML, user correct WAI-ARIA attributes etc. (basically go for AAA WCAG 2.1 rating or as close as possible, at least AA rating) then in IE6-8 the site will still function reasonably well and be usable, even if not perfect.
CSS is where your main struggle will be, making a site work in IE6 is just horrible if you still want to follow best practices (try styling a button for example to make the font size large enough and colour contrast AAA rated). Also how do you then make it responsive for mobile users without hundreds of hacks?
So what if you have to support older browsers.
You can provide a separate version of the site (shock, horror, gasp).
Use user agent sniffing to redirect people to a separate, stripped back, text only with minimal styling version of the site. Be sure to include a link to the main site and indicate that this is a version of the site designed for older browsers.
This requires careful planning as you have to ensure that the same information is maintained on both sites and that features introduced are replicated across both sites.
This is why nobody does this and isn't something I would recommend at all. The amount of things to consider, the limitations on features you can introduce and the chance of updating one version and not the other (even with a Content Management System) is very high. Making just one of those mistakes is likely to cause you more problems than not implementing this at all.
Conclusion
HTML5 introduces many great features for accessibility.
Regions for navigation are one of the biggest wins.
By designing to older standards you will likely end up with a site that is less accessible.
For example, a lot of WAI-ARIA attributes don't work in modern browsers, never mind in older browsers. Trying to fall back to using WAI-ARIA attributes is not going to work.
What about an accessible and easy to use layout? IE6 was the days of tables for layouts because CSS was so limited with positioning. (want a sticky navigation bar? Good luck implementing that!)
To provide 'best effort' I would use a HTML5 shim to at least fix the layout for things like IE7 and IE8, IE6 just isn't feasible.
Another argument is security. How on earth are you meant to write secure JavaScript that is IE6 compatible. Heck try finding a single piece of information alive on the internet today on 'how do i fix this problem in IE6'. Perhaps your solution here is to just not use JavaScript at all. (and yes someone will argue progressive enhancement allows you to use JavaScript, but then you have JavaScript errors which would then mean you fail WCAG under 'Robust').
Oh and did you know that you can't even use <style>*{position:relative}</style><table><input></table> as that will crash the browser?
As a final thought on this rant part, Windows 98 will run IE9 and NVDA. So we cannot make the argument that people may not have the financial resources to upgrade as NVDA is free. We could argue they do not have the technical knowledge on how to upgrade, at which point all I could say is write an article on the site on how to upgrade and redirect people there maybe? It gets a bit silly at that point as to where you draw the line.
How to win the argument with your boss / help them get the spec changed
Your boss is in a bad position but probably doesn't have the 'firepower' they need to persuade the spec to be changed easily.
Here is a simple way for them to win the argument:
WCAG 2.1 AA is the minimum legal standard that we can build this site to without risking getting sued.
This is impossible while maintaining compatibility with IE6 and without compromising on accessibility features.
The cost of getting accessibility wrong, coupled with the additional development cost associated with trying to develop to such an old standard makes this infeasible.
Couple that with the likelihood of developing a application with massive security flaws that could make the site vulnerable I would highly recommend we change the minimum requirements to IE8.
tl;dr
The oldest browser you realistically need to worry about is Internet Explorer 9. Even then you are being generous with your compatibility requirements. Do not try and develop a site that works in every browser ever encountered since 2001 (yes IE6 was 2001), you will break things for more people trying to accommodate people who do not want to upgrade (Windows 98 will run IE9 and NVDA).
Do not attempt to support IE8 and below as you will actually end up making decisions that will negatively impact accessibility.
If you can create a HTML5 valid and CSS3 valid website that is WCAG 2.1 AA standards compliant then you are already more accessible than 99% of websites in the world.
You're not asking the right question.
Users of what I build may be different than the users of what you build. To one audience, it may not matter if the site only loads on current browsers. To another audience, it may be the only thing that matters.
Additionally, some sites outright require newer browser features to function... no web-based fallbacks are available. Also, there are current browsers that don't support much of anything (i.e. Safari, Lynx, etc.) so it's not necessarily a matter of age... but capability.
The question you should be asking is, how do you make the decision of what to support and what not to support. Short of pointing you at your analytics and logs, this isn't a technical question, but a business question.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am designing a website using bootstrap ,HTML,CSS,CSS3 and PHP as Server side language. But when i checked it on different Browser I found that it is not compatible for all browser by examining some appearance and functionality of HTML elements. I want my web page should look on every browser.
I wanted to know :
1) What are the aspects that we have to take in consideration while designing cross-browsing website?
2) How can i design a page which can give me the same output on different browser.
1) Before you use any html5 element. Just check on caniuse.com. To see if it's compatible with the browsers you want. If you are desperate to use that element, provide error callback or just alternative callback.
2) Use prefixes like -webkit- or -moz- etc for partially supported css rules on browsers(you can check on caniuse). If they do not support the rule at all, fallback to images but mind page load. You can also use cssreset library like normalize.css to standarise default styling across browsers.
Your problem is not at all PHP related. PHP runs on a server and generates (HTML) output. That output must be compatible with the browsers, but it's not specific to PHP to get it that way. Therefor I've removed PHP from your title and tags.
The remaining question:
First aspects to take into consideration, is that no two browsers are the same. Even if you have the same browser, they can run on a different machine, have a slightly different update, run on different screen sizes, etcetera.
Also, browsers have their own CSS already built in. A h1 element has a big bold font. The exact size, family and boldness might vary across browsers. Therefor, many websites will start with a CSS Reset (Thanks, #Vucko). This is basically a bunch of CSS code that you can include, which will remove all markup or at least make it the same across browsers.
But even after that, don't aim for pixel perfect. Sometimes nearly is good enough.
This especially goes for unimportant features. For instance, rounded corners and shadows are not supported by old IE browsers, or may look slightly different. Instead of mimicing those CSS features by building big HTML structures and add background images, I think you should cut your losses and accept that a shadow won't show or the corners are squared when otherwise the site works okay.
It's good to follow standards. If you follow standards, and make sure your HTML is valid, it will show nearly the same in most browsers.
There might still be differences, expecially if you use new features that are not fully supported in all browsers. Using features that are widely supported, boils down to a lot of practise, a lot of knowledge, and being able to use at least these sites:
http://validator.w3.org/ - Check if your site is valid.
http://caniuse.com/ - Good overview of browser compatibility of specific HTML/CSS features.
http://www.quirksmode.org/ - A similar site.
Especially those overviews are very helpful. You can see in a glance whether a feature is supported or not, and whether you need special CSS prefixes (like -webkit-) in your CSS to make it work for some browsers.
The answer is actually the same as for 1: Don't. Make it look good on the most important browsers, and make it work on the less important ones. If a browser is really old, don't care about it. The oldest Windows that is still supported is Vista. Vista will run IE upto version 9. So IE8- users should just upgrade their browser. If you do want to support it, only make it work and look reasonable, but don't try to make it pixel perfect. Don't try to do that in any browser, for that matter.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Imagine somebody today, March 1 2011, has never written a webpage and would like to know what they should read to start building web pages today. They don't care about backwards compatibility, but want to build with web standards so that they will be portable amongst as many browsers as possible (Yes I'm saying I do not care if my web pages don't work with IE 4-8, Opera, Netscape, Mozilla, etc, I really don't care, because I've never used them, and that's likely true about those who will use the tools I'm building).
This person has zero biases or bad habits because they've never done it before. They're also hyperactive, so if they have to read 200 pages as to "why to use web standards" or "why web standards are better than "the old way"", they'll get discouraged and distracted and throw the book away, and go swimming. Speaking of which, my hair is wet.
They're looking for references that are engaging and concise. They're not stupid, this person is a real-live engineer who has done a tiny bit of development, a decade or two worth of systems administration, and even built a successful company or two. They just didn't go to college because they really aren't book learners, and are better at applied hands-on learning than at absorbing mounds of useless data in order to get to the two or three things they really need.
Given all of that data about the individual, and I know it's a lot about that individual (this individual is me, of course), what books or resources would you recommend?
(Zeldman's books are out because I already threw them away and then went swimming today.)
Some good resources to start:
Mozilla Developer Network: For HTML, CSS, Javascript, & DOM.
Dive into HTML5: For learning all about HTML5
JSfiddle: For fiddling around without having to build a whole page every time.
HTML Validator: For making sure the HTML you write is valid.
CSS3 Preview: Run-down of some of the new features of CSS3.
Official HTML5 spec: For when you need all the detail straight from the source.
jQuery: Arguably the best framework for making writing javascript for websites easier.
A List Apart: "For people who make websites". Definitely not for starting out, but good to read regularly.
Firebug: If you're using Firefox, this is a must-have.
Developer Tools: built in to Chrome & Safari (essentially firebug for webkit)
Also, do not use W3 Schools. Please see W3 Fools for a long list of reasons why. W3 Schools will often come up at the top of search results, but please resist the temptation to use it.
For someone that has never coded a webpage make sure you dont get sucked into the hype of HTML5 and CSS3 just yet. Although they have great features they all assume quiet a bit of knowledge of previous versions and all of the 'previews' will show you snippets related to enhanced interactivity rather than supported structural elements.
Stick to learning CSS2.1 and HTML4.01/XHTML which will give you a good grounding on which you can apply the new stuff later.
Im sure people will give this answer some negative feedback but if you need a JS snippet at the start of your code to enable the new HTML5 elements in one of the main stream browsers then it should be used for commercial purposes just yet.
I self-taught myself web design and development, and I have a background in engineering. You are comfortable with computers, so you are in good shape. To get started, I took a few online courses from http://www.hwg.org/. The courses are self-paced but moderated, and you get a lot of hands-on experience right away and you get an online community to help you bounce ideas around.
I took the HTML course, almost all the CSS courses and some JavaScript. Once you get some basic experience and learn the fundamentals, you can decide how much of the other stuff you need, for example, PHP/MySQL, or whether you need some design courses to make things pretty.
I would say, you need to put in about 80 hours of practice to master the basics, so give yourself a month of self-learning to get to that point. The reason to get to that point is that you will be fluent enough to ask good questions that will get you to a higher level.
About books, go to your local library and skim through a few books, find one that you like, buy it, skim through it and skip the parts that don't appeal to you.
Finally, if you really want to learn how to build web pages, get a good text editor and hand-code your HTML and CSS. In the long run, hand-coding is more efficient and you save quite a bit of money by not buying expensive tools like Dreamweaver. However, keep in mind that tools like Dreamweaver are often used by professionals and they serve a good purpose in production environments typically found in commercial web design firms. I actually use Dreamweaver in code view where I hand code my pages, but I have a few other editors that I use depending on the project.
Best wishes as you venture forth into a new and exciting field, and remember to have fun!
for html5: Dive into HTML5
for css3: http://www.css3.info/preview/
and if you want to use javascript it would be good to use jquery: http://jquery.com/
I created this question as community wiki in the hope that it and its answers will be edited as the situation with HTML5 changes.
Time to use HTML5?
This question gets trotted out about once a year, so I might be beating a dead horse, but is it finally time (in the summer of 2010) to use HTML5 when developing a brand new web site?
Related HTML5 Questions on Stack Overflow
Is it time to start developing with HTML5? ('09 edition)
Is it time to start using HTML5? ('08 edition)
Any reason not to start using the HTML 5 doctype?
Is there any pros to use HTML 5 doctype <!DOCTYPE html> even if i’m not using any new HTML 5 tag?
Is valid HTML5 OK to use now
Is it too early to use HTML5
Edit as a follow on
Is it a mixed bag: i.e. use these tags safely but stay away from x, y, z?
We are far far away, see:
When can i use...
But you can dive into it by following:
Progressive enhancement
Graceful Degradation
for the moment :)
I think you'd probably get better feedback if you clarified what you mean by 'use html5'. That covers a lot of different functionality, some of it not even finalized. Are you planning on using it all... or just certain pieces (like the tag?) Whether its a good idea to use it now is going to depend on what pieces of HTML5 you are talking about.
It depends what you mean by HTML 5. You can use the doctype now, and many of the features are backward-compatible, so you can use them now and they will fallback gracefully. Other tags just won't work, and so you have to be more judicious.
Not until 2022 (if they stay on schedule).
http://en.wikipedia.org/wiki/HTML5#cite_note-techrepublicref-8
Regarding the "When can I use" link posted by Sarfraz - wow, that's an awful lot of extra work, waste of time, and consideration that could all be avoided if you just drop HTML5 and use Silverlight, Flex, or JavaFX. Any virtual machine based solution is going to beat fighting an endless battle with browser wars.
Is your site ready to abandon half the internet?
Yes, it's time! By two reasons:
It already works
It speeds up development of HTML5 compatibility
Use it with caution though! Using the simplified doctype and the new semantic markup tags will not hurt, but just do good. Using canvas and the media tags with no fallback might be a couple of years too early.
I wish! Wouldn't that be great! I guess if you have a site that has a high enough demand that people will upgrade their browsers then go for it. It seems like people are more attached to their old browsers than super glue is to fingers.
According to readwriteweb, as of May 2010, 46% of users use browsers with html5 support. So, maybe we are over 50% now. But it really comes down to your audience - if you are targetting the general population, I would say it's a definitely too early. But if you are targetting a more tech-savvy audience, maybe not. Of course, degrade as gracefully as possible.
Link: http://www.readwriteweb.com/archives/46_of_internet_users_ready_for_html5.php
EDIT: Yes, the study mentioned in the readwriteweb reference was done by Chitika, and was based on HTML 5 video support. Chrome, Safari 3 and up, and Firefox 3.5 and up were consider "HTML 5".
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 8 years ago.
Improve this question
When you learn HTML and so forth nowadays, the mantra is always "Clean code = better code".
So why do sites like Mobile Me and Google and Facebook all use huge amounts of tables and other not-semantically correct code?
Thanks!
Because people still use IE6, unfortunately, and it's so incredibly bad at CSS as to make it almost worthless for CSS selectors of any sophistication. Until IE6 is gone and dead dead dead in the cold ground, you're still going to see a lot of this.
If you could see what SharePoint generates, you would probably go into seizures.
Clean code is better, yes.
But working code is much much better )
Because sometimes that's the path of least resistance. It's not always about being ideologically pure, it's about being pragmatic and getting the job done in this crazy, multi-browser, multi-platform world.
Because it's easier.
While the purist in me will also strive for semantic tags and external CSS for layout, the pragmatist in me need to get this site up by 6pm (so I can go home to my wife and a nice warm dinner!) and there's just this little problem with [insert browser here*] that could easily be solved with a bit of conditional CSS, or a table or something.
There are other reasons for high-traffic sites like Google and Facebook to use inline CSS and js: bandwidth. Every external file you reference is one extra round-trip to the server to fetch. Of course, that doesn't really explain the style="xxx" tags as opposed to just inline <style> tags, but it still reduces the size of the page. Also, while caching does tend to reduce the number of trips, there are still a significant number of requests that are made with a "clean" cache that you still want to optimise for that case.
Not always IE (but mostly is)
I had an affiliate marketing client the other day who wanted me to make him a web template where he could go in and edit it with Adobe Dreamweaver (some app I don't use because I'm a Linux user). So, being the web-savvy guy I am, I did it in XHTML with cross-platform CSS that I have learned over the years, using DIVs primarily, and only using TABLES for form field alignment simply because of the 80/20 rule. It was lean code in as few lines as possible, loaded super fast, and worked on all browsers from IE6 on up.
But then I handed it off to him, and he was visibly frustrated and asked me to make changes. He didn't like the CSS because he couldn't cut and paste sections to another page and have the styling carry over. Instead, he wanted me to switch everything to inline styles. Next, he couldn't edit the floating DIVs very well, and would undo my cross-platform work I had done, so he wanted it reverted back to tables. The end result was XHTML + CSS for the shell of the page that centers everything into the middle and adds the fancy graphics around the page. Then, I used PHP "include" separation for headers and footers. The final part was the middle of the page, and that was his domain. I had to compose it in TABLEs with inline styles. At that point, he was happy and I had a compromise.
So, keep this in mind that there are some cases where you have to use TABLE formatting and inline styles because that's all the client really knows how to manipulate.