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 11 years ago.
From searching SO, this question was already asked, almost a year ago now.
So now with the new FF, Opera, IE, is it finally time to start developing sites with HTML5 or is it still a little premature and will cause compatibility issues?
Is using HTML5 just going to require us to use more and more JS on websites to 'trick' older browsers into working properly?
It's a great idea if used in a "Progressive Enhancement" way. ie. Code your website to work in "standard" HTML 4.01 mode, and then add some fancy HTML 5 bits to give it some extra flourishes in browsers that support HTML 5
If you add nice features to your site, it is possible it will be talked about and reach the news sites for some free publicity.
Aside from that, It would make a good beta site and give you a head start for when it becomes the new technology. However, until HTML 5 enabled browsers are widespread (at least 20% of the market, possibly 50%) it makes little sense to alienate nearly the whole internet.
If there is a feature in HTML 5 would be useful for the project you are working on, then it is worth considering using it.
You will need to weigh the benefits against the possibility of the specification changing, the less mature testing tools available for HTML5 validation and the probability that you will need to use JavaScript to fake support in older browsers (of course, the HTML 5 spec gives a roadmap that someone else may have already followed in writing such JS).
If HTML 4.01 gives you everything you need — stick with that.
Assess your target audience. Are they likely to be early-adopters? Is it critical that all visitors to your site are catered for? Or will a few not mind being met with an inconvenient, yet polite "please upgrade your browser" message?
For business sites I'd say no. Not yet, anyway. You probably can't afford to lose users of older browsers.
For a personal website or project, why not? It'll be great experience learning the latest HTML5 features, and you'll be ahead of the curve when it does become mainstream. Besides, more people writing sites conforming to HTML5 means more pressure on users of older browsers to upgrade, benefitting all of us in the long run.
The answer is most certainly YES. Firefox, Safari, Chrome and Opera make up more than 30% of the market and they support many HTML5 standards:
Audio & video tag
New tags (footer, header, section, etc)
Canvas
HTML5 doctype (<!DOCTYPE html>)
validator.w3.org supports HTML5 validation (it's experimental, but it seems stable)
For IE you can use these things to make some HTML5 elements work:
HTML5 shiv: http://ejohn.org/blog/html5-shiv/ , this allows you to style new tags in IE
Fallbacks for IE when using the video tag: http://hacks.mozilla.org/2009/06/html5-video-fallbacks-markup/
ExplorerCanvas: http://code.google.com/p/explorercanvas/ , allows the use of canvas in IE
And IE supports the HTML5 doctype, it simply renders in strict mode, which is fine.
Hope that helps, and gets you started using HTML5!
Bruce Lawson of Opera gave an interesting presentation on this at OSCON, see his slides; the verbal conclusion was that it's OK, though there was some debate. Of course that's from somebody working for a browser maker so they're going to be less worried about older browsers (since everybody upgrading is to their advantage;-). The more you need to worry about older browsers, the worse your life is in general of course, but html 5 wouldn't help you there, sigh!-(
I have begun developing pages with the new HTML5 DOCTYPE:
<! DOCTYPE html>
This new DOCTYPE essentially puts the browser into a sorta "standards-based mode." Obviously this is all pretty new to most browsers but creating pages under this DOCTYPE will allow sites to last longer than ever. This also degrades gracefully within every browser I have tested in and no noticeable HTML or CSS downsides.
W3C has began using an experimental validator for HTML5 which can be used the exact same way as all of their other validation engines. An intersting side note: According to the W3C validator, you do not need to close the BODY or HTML tag at the end of the page; allowing for very minimal load time decreases.
As HTML5 continues to make its way to the forefront, I plan to begin implementing more advancements that just the DOCTYPE. For now that seems to be all that is new and widely supported.
Hope this helps.
-B
This site has a pretty good HTML5 shiv for IE. Just include it on you page and you can then style the HTML5 elements.
http://html5.adamhunter.me/examples/html-shiv
Related
Let's say I outsource the development of an HTML/JS/CSS/AJAX web app targeting ONLY modern browsers. If it matters, assume there are 20 unique templates used in creating the application (to give an idea of the size of this application). My understanding is that much time/money is spent hand tweaking the code to make it consistent among browsers. I'm interested in ways to minimize this expense.
As of June 2011, Google Chrome Frame is advertised to not require administrator privileges for the user to download and install for IE 6-9, which essentially runs Chrome as a plug-in inside IE to avoid browser incompatibility issues with IE (substituting potential compatibility problems with Chrome, which should be much less than IE).
If I were to direct the developers to target only modern browsers minus IE, requiring all IE users to download Chrome Frame instead, would this path translate into any significant development cost/time savings? (My users are engineers and may be willing to accept this tradeoff since this application is not offered elsewhere.) I just don't have a feel for how much effort is made for IE versus other (modern) browsers, and wondered if anyone with experience could comment whether this makes cents (pun intended) or is simply crazy.
Also, any downside to doing this?
You will save time and money. I have done something similar for our in-house application. The site runs only on webkit browsers (chrome and safary).
We save a log of time, because the css and JavaScript can be more efficient, and most importantly, we do not have to test every change on 6 different browsers. This is very liberating.
If your users allow you to exclude IE, i recommend it.
It all depends on your application and developers. With enough knowledge it's possible to write code without even checking in IE until the end but only keeping it in mind and have 99% of things as expected in ie8-9, 80% in ie6-7.
If your users are engineers I can hardly imagine them using ie in the first place and even if so definitely not ie6/7.
Even if you don't go with Chrome-frame, given above points, if you're willing to go with slight to mild visual design degradation you can get away without specifically targeting ie...
Here's a little ie9 promo for ya :)
http://varonasf.com/ie69/
(only works in decent browsers)
This is the design decision behind Google Frame. You always have the choice of either designing for the lowest common denominator, i.e. IE6, and having a limited function site, or designing for a reasonable HTML 5 standard and forcing users to upgrade.
...allowing users to access modern web technologies like HTML5 on
legacy browsers.
http://blog.chromium.org/2010/09/google-chrome-frame-stable-and-speedy.html
Let me start by saying I really appreciate the work done at QuirksMode.org but in recent experience the content seems a bit dated.
Some pages haven't been updated from anywhere between 6months and a year.
Compatibility tables still only show chrome at version 5.0 (W3C DOM Compatibility) or 1.0 (Event compatibility tables)
In cases where content seems a bit dated I generally refer to Sitepoint's References, but their HTML and Javascript Reference pages are also a bit our of date.
What compatibility reference guides do you all use?
update
I'm aware of sites like CanIUse, which are invaluable reference new feature support like new JS API libraries and CSS3 support. However I'm more interested in things like supported attributes (bad example I admit) and browser events. The more vanilla stuff.
And please, noone mention w3schools (see w3fools why you should never use this site)
http://caniuse.com is quite good and (provided you use the correct keywords) has good search functionality as well.
In addition to the above you might be interested in the ES5 compatibility tables that Kangax maintains at http://kangax.github.com/es5-compat-table/
update
In the meantime there is also the ES6 compat table. Quite red for now (9/2014) admittedly, but getting more and more useful.
I trust Quirksmode, have you any idea how many tests PPK runs? It's not that it's outdated (yet!) it's that CSS support (and Browser uptake) has reached a new level, trust me you will appreciate the experience if you have to support an older browser.
Not every FF or Opera user updates quickly anymore which is what could be relied on for a while! - so yes you're right to question the findings. personally I look for recent sites too but I don't "trust" them nearly as much as the older and even then I tend to test for myself.
There's no replacement for experience IMO often these guys can "guess" at what may be the problem based on their past experience even if the so called "bug" or unexpected display is new to them in that context.
I have a "bug" report detailed on PPK's site - yea it and me are old - but only last week I got asked about something (seemingly unrelated) which turned out to be the same thing and have the same solution, it's IE7 related so will be with us for a while yet. (I see caniuse thinks that's old eeek!) - I am completely in awe of these guys who have kept up these sites for so long, if you can reverse engineer the bugs you get to understand the browsers.. that will never fail you as long as the browsers are on the go - their render engines don't usually change all that much between versions!
but then again this is a new era of Browser wars so who knows what will happen :)
Have a look at this big javascript compatibility table
http://compatibility.shwups-cms.ch/de/home/
Its very big, but checks at the moment only for existenz of javascript properties.
I see that many people have problems with cross-browser compatibility issues.
My question is why do browsers render the html, css or js differently?
Is it due to the DOM? The box model?
Why are there cross-browser compatibility issues when there are standards from W3C etc?
Are there any differences in the way the major Internet browsers display HTML content? Why is it that Internet Explorer, Firefox (Mozilla), Opera may display the same content differently?
What should I keep in mind when building a cross-browser compatible web site?
There are a lot fof reasons or incompatibility:
Specs are often written in response to the development of propriety features by specific vendors,
Specs can sometimes be poorly written, have ambiguity or were not written in anticipation of specific end-use cases.,
Browser vendors occasionally ignore the specification for their own reasons.
Additional factors:
A lot of this stuff is hard to implement, let along implement correctly,
It also has to be implemented to handle poorly formed HTML, backwards compatibility etc. Browser vendors sometimes sacrifice 'correctness' for 'interoperability',
History, politics & personalities.
I'm sure someone will answer this much better, but here's a start:
Yes, there are standards that are supposed to be adhered with respect to CSS rendering. The problem is, some browser editors (cough Microsoft cough) don't consider it a priority to implement the specifications correctly (or even fully, for that matter). Even, when the layout engine is being worked on to attempt to ensure compatibility, it can get quite nasty figuring out how things should be rendered correctly when mixing various CSS properties and units (see for example, the ACID test http://en.wikipedia.org/wiki/Acid3)
To have a cross-browser website, you'll basically have to check all of your website's pages render correctly in the browsers your visitors use (or that you support). Various tools such as Selenium (seleniumhq.org) can help with this.
You basically have to decide what you're going to do
design for the lowest common denominator (if it's IE6, there isn't much you'll be able to do)
design using validating CSS and using hacks (e.g. clearfix) to correct erroneous behavior in certain browsers
decide not to support certain browsers (IE6 being a prime candidate)
sniff browser and adapt display accordingly (NOT the preferred way to do it)
With respect to differences in manipulating the DOM, libraries such as jQuery help a lot as they hide the implementation differences from you.
For reference, it's a good idea to test your website in at least the following:
WebKit-based browser (Chrome, Safari)
Gecko-based browser (Firefox)
IE
Opera
It is an aftermath of the Great Browser War. Now Netscape Communications lies in ruins, but quirks opponents made to outperform each other is still remains in browsers' codebase, and people are still in development team. Consider watching Crockford's lecture, he gives some highlight on subject. (you will want to save the file instead of streaming it)
Everything that Hamish said, plus another major problem that he alluded to is how browsers handle incorrect HTML. For example, back in the days of IE4/NS4, the element was very problematic. If you didn't close a tag, IE4 would close it for you. Netscape 4 would silently disregard the table completely.
This is still true today where one browser will fix incorrect markup differently than another. Yes, the markup should be corrected, but browsers will try their best to render something.
The standard specifies how HTML/CSS markup should be rendered into displayed as visual elements. It does not specify how the rendering should work specifically. Many different people and companies have created different ways of rendering markup visually. Since HTML rendering is an extremely complex task, of course they didn't all converge on the exact same solution. All rendering engines are aiming for the same goal, but often the spec is vague enough to allow for small differences (be it just pixel level), and bugs are inevitable as well.
Add to that that back in the days browser vendors cared less about standards and more about gaining market share quickly and that certain companies have been very slow in turning around to embrace standards (you know who you are).
In the end, specs, which are quite complex, and browsers, which are even more complex, are written by many different people; you can't expect absolute perfection to arise from this process. And perfection is not the goal of HTML either; it's meant to be a simple, vendor and platform independent markup language to present information on a variety of devices, something it does remarkably well. If you need pixel perfect results, you need to go with a technology that was meant to provide this, like Adobe Flash (which is neither platform nor vendor independent nor simple).
Try to look at it from the glass-half-full perspective: Thousands of different people have written millions of lines of code doing vastly different things on many different platforms with many different goals and focuses, and yet in the end all render HTML markup almost identical with often only tiny, virtually irrelevant differences. There are of course weak spots in every engine and if you happen to hit them all at once, your site will break in every browser in different ways. But this is possible to avoid with a bit of experience.
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.
I look at ExtJS, and it appears to provide many of the RIA features that more bulky suites such as Flex provide, without the flash requirement. However, as Open-source initiatiatives such as jQuery-UI continue, will ExtJS simply die at some point? Furthermore, since flash penetration only continues to increase, why put stock in a javascript library?
That said, JavaScript libraries such as jQuery have made gigantic leaps in providing easy-to-use APIs with great functionality, so maybe there's some merit in that.
Thoughts? Opinions? ExtJS has a price tag, so I have to ask this question.
IMHO, the need in jQuery, ExtJS etc. will be eliminated as soon as XBL2, entire collection of CSS3 specifications, SVG and HTML5 all get available in an equal extent across all desktop/mobile web-browsers, which is not going to hapen within coming 5 years.
I look at ExtJS, and it appears to provide many of the RIA features that more bulky suites such as Flex provide, without the flash requirement.
To run Flex application you still need Flash player, which for example is not available on mobile devices
However, as Open-source initiatiatives such as jQuery-UI continue, will ExtJS simply die at some point?
Comparing ExtJS to jQuery-UI doesn't make good sense, since jQuery is primarily a cross-browser library to simplify operations on HTML documents and make web-pages nicer, while ExtJS is a true aplication framework that brings enhanced data-driven UI components to make applications easier.
Furthermore, since flash penetration only continues to increase, why put stock in a javascript library?
It doesn't really matter that Flash penetration "only continues to increase", since it is already available on 98% of desktop devices. Putting stock in a Javascript library makes sence, believe Google (who put most of its stock in DHTML)
will ExtJS simply die at some point?
Indeed it will, as at some point will die .Net, Java etc. It will not die in a foreseen future however and the need for this kind of Flesh-less solutions will only increase.
You may also want to take look into an alternative GUI framework Ample SDK, which will go Open-Source on 1st November this year. It enables technologies, such as SVG, XUL and more equally cross browser.
I don't think Ext JS will die anytime soon. When it will it will probably be one of the last JS frameworks standing. I'm saying this because ExtJS has a solid user and developer base and lots of open source projects are building on it (e.g. an ASP.NET dual-licensed CMS, Sense/Net builds its backend entirely around it among others).
They have a solid user-base and I don't see them leaving the race anytime soon. That said you can always look at the Internet as you look into the general market. Both Starbucks and the local cafe can co-exist.
That said...
Compare the trends between jQuery, ExtJS and Mootools
III'm not a javascript/DOM guru, just an ASP.NET programmer and now-and-then FlashBuilder coder who is looking into 100% client-side libraries. What I am finding is that ExtJS is much richer in its layouts and its UI widgetry than jQuery -- though jQuery has much momentum and new UI components are coming all the time. Still, ExtJS has a major lead in this regard.
With jQuery it is a lot easier to get something basic up and running mainly because jQuery hangs its effects on existing elements in your page markup: you can create a skeletal html page and then apply jQuery functionality to the elements. Compare that to ExtJS where your page is basically an empty body tag and the page contents are created by Ext writing to the DOM. Without the Ext (visual) Designer to lay out my pages and set properties, coding ExtJS configuration objects with a text editor is far too tedious for me and not at all to my liking. But with Ext's visual Designer, you do approach RAD.
ExtJS on IE8 can be slow and sloppy because of IE8's shortcomings. In my experience ExtJS RIA layouts work beautifully on FF, Chrome, and Opera but not nearly as well on IE8. However, IE8 with Google's Chrome-Frame addresses that. Nice gut-punch to those Proprietarians at MSFT, guys at Google!
I really like the hybrid approach FlashBuilder takes. With FB, you can write mxml and/or ActionScript classes. The down-side, as I see it, is that the Flash plug-in is required, and I fear that the Flash plug-in is going the way of that other dodo, WordPerfect, which once roamed the earth with 99% market share. I really wish one could design in FlashBuilder taking full advantage of ActionScript's OO features. mxml, and the FB debugger, and then cross-compile to ExtJS! FB : Ext :: GWT : Closure.
Like with each technology, everybody will have his own piece of cake. ExtJS will not die until ExtJS LLC exists (they are using it :)) And until they will have worshipers using their lib (like me) when You are at some point You just have to use chosen technology, no matter if it is perfect or not. Look at Lotus Domino - it is piece of crap and on the other hand piece of great software - and it is still alive... :)
ExtJS has dual-license And it's opens source
See here general details
And here licenses
And i using it. Good library for working with data - grids, trees... you name it.
And it has many controls. so just good library...
As long as the developers continue to work on it, the framework won't die. There have been a few frameworks that are effectively dead (e.g. MochiKit, which I love but have dropped for yui3) but that only means that they're not getting updated, not that they're unusable. If you liked one well enough, you could easily put out your own release and start up the project again.
Personally, I use Prototype, but it's the same argument. I strongly dislike flash due to the numerous security issues that follow it and the fact that not all devices can play flash. The iPhone is one major example. It CAN support animations and other things using JS libraries.
Some companies also disable flash as policy for security, although this isn't all that common. (I've worked places where this was the case, however.)
Another question is whether we'll care about flash with the advent of new HTML standards will largely eliminate the need for Flash altogether.
It's the year 2009. Internet Explorer 8 has finally been released, and Firefox is coming up to 3.5. Many of the large browsers are starting to integrate features from CSS3 and HTML 5, or have been doing that for quite a while now. Still, I find myself developing web pages exactly the same way I did back in 2005.
A lot of progress has been made since then, and I think the reason that I haven't started taking advantage of these new possibilities is that it's so hard to know which of the new features that work in all major browsers. Since I'm mostly a backend developer I just don't have the time to keep up these developments anymore. Still, I feel like I'm missing out on a lot of cool stuff that actually would make my life a lot easier.
How can I quickly determine if a feature of CSS3 or HTML5 is supported by all major modern browsers?
Can I Use is a website which tracks browser support for current and upcoming web standards. Check it out if you would like to know whether or not a given feature is widely supported.
Font embedding through CSS, using #font-face. Webkit/Safari has been supporting it since version 3.1, Microsoft since IE4, Mozilla since Firefox 3.5 (browser support overview).
Also, the varied implementations of the Selectors API, which provides a browser-native CSS selector engine for use in DOM scripting.
For other examples, When Can I Use... seems to be a very good reference.
I would say display:table and a range of CSS2.1 selectors are the big wins for designers. display:table solves some unsolvable or difficult layouts like 100% height and inside borders without breaking semantics and using actual tables.
Multiple classes (.c1.c2)
I use min/max-width/height a lot.
Also working :hover and !important are awesome.
I would have liked to add SVG support to that list but naturally Microsoft messed that up.
BTW, big warning to those getting excited about HTML5 features. There is no official date for the adoption of this spec. It's even been implied it could take another 10 years (though I doubt that). The point is anything you do with HTML5 now is subject to breakage when the official spec does arrive and in the meantime you can expect plenty of browser inconsistencies, bugs and API changes (not to mention browsers that don't support the features at all).
Browser support for local storage should enable a bunch of new ideas now that some content can be saved on a user's machine.
Reference docs:
Mozilla Firefox
Internet Explorer