Related
Recently, I have been building a website for someone and am getting irritated with some browsers rendering the website one way and other browsers rendering another way. I decided to look into why this is and discovered that the issue likely lies in the HTML engine beneath the browsers. For example, Chrome and Opera (along with most, if not all, Chromium browsers) use the Blink engine, which is a fork of the WebKit engine (which descended from the KHTML engine). Safari uses WebKit. Internet Explorer uses the Trident browser; and Edge uses the fork of Trident known as EdgeHTML. Netscape and FireFox use (or used, in Netscape's case, considering the browser is discontinued) the Gecko engine.
Considering all of this, is it possible to apply CSS to specific engines rather than browsers? Or is this already being done when we try to use browser-specific CSS? Was the point of the user agent string to do this (which apparently was messed up by the developers wanting to imitate other browsers)?
Note, I would think from comparing how these engines are related that there are 3 main engines: KHTML-based, Trident-based, and Gecko. So I am guessing that the answers on this question will give at least three different methods (one for each of the main engines).
Even if it was possible (using vendor prefixes) it could be a pain to maintain the code base. I suggest you to reset or normalize.
My reset is a merging of reset and normalize.
You can use vendor prefixes, even target some of them via suppot queries with vendor prefixes, such as
#supports (-webkit-appearance:none) {}
Browserhacks has a great collection of approaches for that.
That being said, you really, really shouldn't. It will be a nightmare to maintain.
Browser differences are caused by:
1) Different user-agent styles (default browser rules); Normalise or reset will take care of that for you.
2) Some experimental features that might be available just to some browser, or be different between them, normally addressed by vender prefixes; Autoprefixer such as Prefix Free or Post CSS's Autoprefixer deal with that perfectly fine.
3) Different features; knowing what you can and can't do on each will take you a long way, and whenever you find a limitation, make sure to use fallbacks or even polyfills.
99.999% can be achieved with normalise, an autoprefixer, and a decent understanding of browser features and fallbacks.
Remember your projects should work fine on all browsers (or as many as you can, no one expects to support IE6 on 2018..) but it can look and have a better experience on some / most. That's what progressive enhancement and graceful degradation are for.
Like the title says I'm just wondering the current support for canvas.toDataUrl? I have it working in Firefox 4 but haven't really tried it in any other browers. When I look it up on Google most of the results are pretty scattered as some are from a year ago. It says its only supported with webkit nightly builds. (which I assume now are the actual releases)
I'd also like to know the support for mobile devices as well.
I personally prefer using caniuse.com for finding out the current browser support. Caniuse covers various major releases of each browser, as well as some mobile browsers. However, I always recommend that with anything mission critical, you test in all browsers just to be on the safe side.
If you take a look again at caniuse.com you will see that the support tables are all color-coded and they tell you whether a browser fully-supports, partially-supports, does not support, or does not support (but a polyfill exists). The canvas.toDataUrl, property would fall under the category of "basic support", which shows that the canvas api (or rather the current working draft for it) is fully supported in all major browsers, and there is a polyfill available for IE.
So while it doesn't go into great detail about the specific properties browsers support, it stands to reason if a browser "fully-supports" the basic canvas API, you can safely assume that includes toDataUrl. Once again, if you dont want to leave things to chance, or if you for some reason do not trust caniuse.com, your best bet is to build a test-suite and personally test your app against all browsers.
Actually it's currently broken in the webkit nightly build, a minor security bug I found a couple days ago:
http://code.google.com/p/chromium/issues/detail?id=91016
But in general in the stable release of Chrome it works just fine. In IE9 it works just fine too.
If you had to choose a browser (just one) to be the primarily supported browser for a company jumping into HTML5 (CSS3).. Which one would be your safest bet on the middle-long term?
Chrome, FireFox, Safari, IE?
I'm looking for an objective recommendation based on standards driven/compliant, developer tools, fast & correct feature implementations, memory footprint, etc.
UserBase/MarketShare would not be an issue because it would be on a closed environment in which we control the clients (which are basically big machines with a Web interface).
Thanks!
I would say a webkit based browser. That would be the best balance of speed/stability and HTML5/CSS3 features.
However I believe that Opera has the most implemented features.
Opera has always been in the lead, but they've also always had weird bugs. Right now, Chrome is in an interesting position: Google just bought an internet video protocol company (On2), and so they have the power to end the H.264 vs. Ogg Theora battle by releasing this great new codec they've bought as open source.
HTML5 itself isn't anything new: it's just new elements that display differently. Think of it like this: if HTML5 was the first to introduce the <blink> tag, developers would be a little iffy about it because you can just use CSS to set text-decoration:blink or use some Javascript to make the blinking happen.
With HTML5, things aren't that different. Most of the new elements are just extensions of <div>. For the ones that aren't (<video>, <audio>, <canvas>, etc.), there are either already strong implementations (pretty much across the board) or the implementations as complete as the HTML5 spec is.
Will there be a best browser for HTML5? Probably not. It's all just a matter of how the browsers position themselves (like I mentioned with Chrome above).
If you control the environment I would say pick one based on that has features your app can exploit to make your job easier. Otherwise, lower-common-denominator is a widely used approach for a small team.
I would say Gecko (firefox and friends) or webkit (safari, chrome and friends). I wouldn't go with IE nor Opera. Here is a HTML5/CSS3 comparison table that pretty much supports my views.
Safari’s pushing CSS animations and transitions, if they’re a big draw for you.
If you want to make a HTML5 app/site that focuses on one browser, then you might as well use HTML 4 and JavaScript. For the next many many years most HTML5 sites will have to function in non-HTML5 mode.
See HTML5 features as glacing on the cake, to add benefits to the browsers that can take advantage of it.
All the modern versions of browser support HTML 5. But recently launched internet explorer 9 specifically designed by keeping in mind future web technology needs and incorporated latest features that give rich and interactive web experience. Latest browser Internet explorer 9 has more support for Cascading Style Sheet than previous versions of Microsoft browser. It supports CSS3 and more emerging SVG2 markup standards. IE 9 includes new java script engine that designed to take advantage of multi core processor and give maximum performance.
What, if any, considerations (HTML, CSS, JavaScript) should you take when designing for Google Chrome?
Chrome uses Webkit, the same engine as is used by Safari, OmniWeb, iCab and more. Just code everything based on the standards and verify in each browser.
I think first and foremost you should focus on using HTML and scripting that follows the standards.
After you have that running, file a bug report then make the browser-specific tweaks. If Chrome is worth a flip you shouldn't have to tweak things for it.
The same ones you'd take for Safari, as they share the same rendering engine (with a slight version mismatch).
I'm sure filing a bug report really helps with all those IE rendering issues!
Realistically, you need to test your application in each browser, no browser 100% follows the W3C standards so ultimately you can't rely on following that at all. You need to test everything you do in any browser you wish to support.
As has been mentioned, Google Chrome has the same rendering engine as Safari/iPhone/etc., WebKit which passes Acid3, so there should be minimal issues if you follow the standards. But don't rely on it. Google Chrome currently uses a slightly older version of WebKit than Safari. I'm sure they'll eventually be on the same version at some point, but unfortunately any new browser becomes just another browser to test in.
Are you designing specifically for Chrome, or do you want to make sure your pages work well with Chrome?
Assuming it's the latter, then just use the same design considerations you'd do for any browser. If applicable, keep in mind that many phones and video game consoles have web browsers now.
Chrome uses a new JavaScript engine, so you'll have to test your JavaScript using Chrome as well as Safari. The HTML and CSS may render pretty much the same, but they use different JavaScript engines.
Is anyone writing applications specifically to take advantage of google chrome?
Are there any enterprise users who are considering using it as the standard browser?
Yes, I have started to pay very good attention to Google Chrome for my applications. Recent analytics show that between 6%-15% of my users are accessing my applications (varies between 6 to 15 in different applications) on Chrome. And, this number looks on an upward trend.
Thus, I can't really ignore it for testing right now.
As far as taking it as a standard goes, thats a long way off. I still have to test for IE6! :( Though, we have been planning to start using features like Gears (inbuilt in Chrome - downloadable elsewhere) once Chrome crosses the 25% mark. Thats when I believe that we will be looking at Chrome to be our preferred browser. I hope that we have Chrome 1.0+ by then! ;)
I switched to Chrome and haven't looked back except for the occasional site which doesn't work properly, forcing me to load it in Firefox. All my existing web applications work fine on it, and I'm using it for primary testing on my current development project.
I'm not actually targeting chrome, but I have added chrome to my browsers to test sites on. I've found some odd quirks in this product where some plugins cause the browser to hang, or run really slow in some environments, but they are still in beta in active development. But I definately now make sure sites I work on render well in chrome, as well as firefox, latest versions of IE, safari, Konquerer and opera. I usually check out how it looks on lynx as well, that helps me catch "un-alternated text" in images. Yeah, I know that isn't a word, but some people will understand what I'm saying.
Because chrome uses the webkit to render HTML, you can be assured if it works in safari, it'll work under chrome, however it's rendering engine isn't up to scratch quite yet. I think writing applications that take advantage of it is similar to writing iPhone applications, remember chrome is expected to be adopted by android to make it similar to iPhone. That way it pretty much takes advantage of all those iPhone apps.
Would I install it as the browser of choice? not yet - but i'll certainly work on valid web pages that will render across all browsers.
One of our major customers has outlawed Chrome because it installs on the C drive without asking. They deploy a standard image with a small C drive and large D drive so they can easily re-clone the system part of the image on C without destroying the client's personal files on D. Most software allows you to choose the install directory. Anything that violates this is disallowed, and they're a big enough company to have some weight with most vendors.
We have enough headaches trying to support
Firefox
Two versions of IE which have their own iffy bugs
Safari
I'm not sure why we continue to support Safari. Most of our users (corporate) use IE6 or IE7. We try to make sure that things work in both of those.
Maybe not for programming purposes but Chrome w/ Google Reader makes for the most powerful RSS reader. Can handle up to 1500 feeds w/ performance still ok, managing subscriptions still functioning.
I'm using it on my work machine, but that's about it. It's been stable for me, and I like the barebones UI. I'll still switch to Firefox for the web developer extensions however.
I'm liking some of GoogleChrome- the Start page with your 9 most recent is the winner for me. The interface takes a little getting used to, but the speed is impressive, especially with Gmail.
However, it glitches with Java, which rules it out for serious work at the moment. I use FireFox mostly and have Chrome for the "other" websites at work.
I'm considering using GWT on an intranet project and considering suggesting to the users that use Chrome to take advantage of the enhanced Javascript performance. Any AJAX-heavy app would be a great candidate to target Chrome.
At my company, we're not targeting it, but we're definitely paying attention to it. My boss is using it as his primary browser, and I have implemented browser detection for it in our scripts in case we ever to need to target it for some reason.
Chrome has the .png opacity bug where the transparent parts of the .png are a solid color if you try to transition the opacity from 0 to 1. In IE7 the opaque parts are black, and in Chrome, they are white. Today, I decided to go ahead and account for this bug in my JavaScript. I don't really test sites on Chrome that often, but I am actually using it for almost all of my browsing.
I will target Chrome as soon as a stable Linux and OSX client is available.
Targeting Chrome/Chromium right now, I think is like targeting Konqueror web browser. It will get popular, but you should wait to a more stable beta, and/or some Linux and OS X client.
My website statistics shows 3.xx % visitors using Chrome which arrived just few weeks back. And Opera is only 4.xx % which has been around for several years.
Easily you can see that rate at which Chrome is picking up.
You can see how easily Google takes over all areas of your computing world and personal world too.
Since Chrome uses Webkit, it has the same rendering engine and DOM support as Safari (not necessarily the same revision of Webkit though). By testing in Safari, you can generally get by without worrying about Chrome. Any differences you find are probably just bugs that you should file on instead of work around.
However, because Chrome uses a different JS engine, there may be a few incompatibilities with Safari. So, if you're doing anything with JS, you might as well fire up Chrome and see if there's anything obviously wrong.
Generally though, you don't target browsers, you target rendering engines (with their associated DOM support and JS engines).
I am using Google Chrome, so far all the web apps I have work fine in it with no modifications.
No.
Why help Google further build an evil empire? In this particular case it is so obvious that they do not care about users but only obsessed with gathering usage info.
It's not any major player yet