As you can see, pretty much NONE of these elements are supported in IE9, so how can any developer be comfortable with using these? I always here things about "progressive enhancement", but in this case, you're not dealing with rounded corners vs square corners, you're adding an element to the page in which an entire browser line does not support.
Like it or not, IE still has the market share, so why are developers OK with using these new features and hacking things for the #1 browser?
Don't get me wrong, I hate IE just as much as anyone else, but I'd like to hear your thoughts!
HTML5 is still a work in progress.
Even if most modern browsers have some HTML5 support and many rules have been established, i think many developers keep the right distances from it, at least at the present day.
Personally, i'll take HTML5 in consideration only when it will be officialized as an effective standard.
It's important to note this line (below the first chart):
All the new input types are supported in all browsers in that they will submit their data as if it were a "text" input. These valuations are based on if they do anything above and beyond and/or validate against the type of data relevant to them.
As far as I know, you can basically make up an input type, and every browser that doesn't now what to do with it will show a textbox. If you can cope with that, go for it. You can then try to implement some javascript tests to replace those inputs with your own input widgets if you're not comfortable leaving them as open text.
So, the comfort level, for some developers, is in that the users will at least see an open textbox, which is probably what you would have used if those new types weren't in the HTML5 draft. And at least this way, M$ will get the idea that people actually WANT TO and ARE using these new types. And yes, they ARE blatantly encouraging their visitors to use non-IE browser
HTML5 is still a work in progress.
The client side web standards set will be a "work in progress" forever. No browser will ever be fully compliant. And they will always be in disharmony with each other, each creating their own features and standards to attract attention. Thus, the "HTML5" doctype:
HTML Code:
<!doctype html>
The doctype really just indicates that ...
This file is "HTML" and may attempt to use the most recent features listed in the latest W3C draft and maybe some things from some other browser's feature set. Unsupported features should be treated like their "nearest" calculable equivalent (a DIV or a SPAN), and this page has been coded to deal gracefully with a lack of support for my made-up tags through the use of JavaScript, CSS, and informative messages within all potentially unsupported tag bodies!
If you want to stay inside the W3C standards, you often end up creating things that every browser supports a little differently. And if you want to stay in side the realm of what every browser supports exactly the same, you probably need to revert to table-based layouts, avoid javascript, eliminate your rollover effects, and probably drop a lot of your other CSS flair. Because frankly, not everyone uses a JavaScript or CSS enabled browser.
All the new input types are supported in all browsers in that they will submit their data as if it were a "text" input. These valuations are based on if they do anything above and beyond and/or validate against the type of data relevant to them.
This statement is pretty bold though!
And if you want to stay in side the realm of what every browser supports exactly the same, you probably need to revert to table-based layouts, avoid javascript, eliminate your rollover effects, and probably drop a lot of your other CSS flair. Because frankly, not everyone uses a JavaScript or CSS enabled browser.
Let's say 50% of people use IE ... where-as 5% of people have JavaScript and CSS disabled. Developing for 50% is much more important than 5%.
Let's say 50% of people use IE ... where-as 5% of people have JavaScript and CSS disabled. Developing for 50% is much more important than 5%.
True. And I should clarify -- don't rely on partially supported features for critical functionality. But don't eschew them entirely either. You can implement certain features that work BEST in non-IE browser, but are still passable in IE. And you can include the standard, "this page works BEST in these browsers.." message. And you can even implement most of a site to work perfectly fine in IE, but include some neat things that simply show "this widget does not work in IE and here's why" links in IE. And have them link to that fancy chart that basically shows IE's lack of enthusiasm and support for new/trending features.
Know what I mean?
ADDENDUM: This sort of "risk-taking" puts pressure on browser vendors and helps the web evolve. And as long as the site is passable or mostly functional in most browsers, the risks are pretty low, in my opinion.
Take it easy with HTML5. It is still in the stage of "working draft". Regarding the cornered elements, nor CSS3 is fully implemented in all the browsers. Don't mention the smartphone's browsers.
Client-side languages are different from server-side languages. There is always a pressure upon these languages: for changes, security, backwards compatibility, aso.
All you can do is to test the new standard (or the draft recommendations) in all the main browsers. If some don't work, try to find a workaround, either by testing yourself, or by consulting a Forum, (or Google for). Don't mention that we often meet bugs. This is what we all are doing for years. We don't like it, but we learned how to live with.
The browser wars have bothered me since the days of IE vs Netscape. Interestingly, things are changing, and IE is no longer anywhere NEAR dominant (according to w3c)
Plus, consider that IE is usually forced upon people at work (at least in my experience) and it is definitely not dominant. Still, a large enough share that it needs to be considered when developing (for now).
This is by no means an accurate measure, but my analytics for thepointless.com show IE users at 32.2%. However, I have another set of stats for an educational publishing site that shows IE usage at about 59% on the public side, and 79.5% on the private (authenticated) side.
So, I would caution against using stats from any specific sites: Browser shares depend entirely on your specific audience. When it comes time to determine which browser to favor when revamping your site, presuming you want to play to the biggest share, always use usage stats from your target audience! If you have an existing site that you're just replacing -- perfect: use those stats.
So, I would caution against using stats from any specific sites: Browser shares depend entirely on your specific audience
Agreed. You always need to know your audience.
The stats are interesting. Is this educational publishing site more likely to be accessed from work? (I'm pushing my theory that IE is forced on people at work, like it was on me until I figured out Chrome can install without Admin access).
I agree with Apple. And I want to see folks working with and pushing for improvements in HTML5 rather than defaulting to Flash.
I agree to your agree .
Somehow out of the topic, but it is something of general interest, I think: It looks like even Adobe understood, somehow, that problem. Therefor they have launched a tool for converting Flash into HTML 5:
Somehow out of the topic, but it is something of general interest, I think: It looks like even Adobe understood, somehow, that problem. Therefor they have launched a tool for convert Flash into HTML 5: http://labs.adobe.com/technologies/wallaby/
It's a limited tool, so far, but it is a start
Reply With Quote
Originally Posted by svidgen
Bookmarks