Rapid Browser Development Challenges Web Developers

Esther Schindler writes "Feeling a little overwhelmed by changing web standards and new browser choices? You aren't the only one. Mozilla is launching development tracks for the next two editions of its Firefox Web browser immediately, with hopes to push both into general release before the end of the year. This while Microsoft previews Internet Explorer 10 on the heels of its IE9 release, and Google projects Chrome 13 just one year after Chrome 7. Meanwhile, HTML5, the next version of the Web's primary language, appears to have entered a permanent gestation phase. Writes Scott Fulton: All the confusion has prompted Web developers to ask this question: What do we develop our sites against now?"

Comments

HTML 3.2

[Hatta]

HTML 3.2. If you can't do it with HTML 3.2, you don't really need to do it.

Re:HTML 3.2

[The MAZZTer]

IE7. If you can't do it with IE7, our clients don't want it. :(

Re:HTML 3.2

[ep32g79]

IE7. If you can't do it with IE7, our clients don't want it. :(

Consider yourself lucky, I'm still stuck with supporting IE6. PNG overlays, forgettaboutit.

Re:HTML 3.2

[itchythebear]

Yeah sure, i'll just file that quote alongside "640k ought to be enough for anybody".

Re:HTML 3.2

[anyGould]

Really, if your software doesn't work on Lynx...

Re:HTML 3.2

[Anonymous Coward]

pngfix.js?

Re:HTML 3.2

[Anonymous Coward]

Until you lose all that form data because the page reloaded to tell you that the username you specified was unavailable.

Re:HTML 3.2

[next_ghost]

HTML 4.01 Strict. At least until W3C comes back to its senses and drops the "living standard" crap for HTML5.

Re:HTML 3.2

[madprof]

Not if you want translucent PNGs for a background.

Re:HTML 3.2

[twebb72]

IE7. If you can't do it with IE7, our clients don't want it. :(

Consider yourself lucky, I'm still stuck with supporting IE6. PNG overlays, forgettaboutit.

You are missing out on a tremendous amount more then overlays. How about stable multiple class usage; first-child, +, >, ~, attr selectors; :hover/:active improvements; min/max-heigth/width support; overflow: visible actually works; position: fixed -- erm, is fixed. Thats just the CSS list.
(But thank goodness for jquery, otherwise I would have to memorize a much longer list of newly supported features.)

Re:HTML 3.2

[terrox]

"than"

Re:HTML 3.2

[Anonymous Coward]

Or HTML 3.11 For Workgroups

Re:HTML 3.2

[smellotron]

HTML 4.01 Strict.

Amen to that! I've had many arguments in the past over HTML 4.01 Strict vs. XHTML. My conclusion was that unless you're using inline SVG, MathML, or XSL-based stylesheets for a website (a terrible idea), there was no real benefit to advancing beyond 4.01 Strict. Things will probably eventually change with HTML5, but not if it's a moving target.

Re:HTML 3.2

[Anonymous Coward]

If your clients only want IE7, I don't want your clients.
Since they're bankrupt soon anyway, trying to go against MY clients. Who hate IE. ^^

Re:HTML 3.2

[Anonymous Coward]

"Funny" hardly, it's true, html 3.2, javascript, can do virtually it ALL. The newer tech is for specialty applications, to re-invent the wheel(make it easier I suppose), and , heres the big one... Control/limit your access,, more sophisticated advertising! I've never seen a site 'today' that wouldn't be equally presented by html 3.2 and minor script. not to mention load faster etc etc...
Theres not bee any computer 'improvement' in a decade, now it's about 'screen time' and starting to channel your access, limit countries etc..
The walls are closing in..
Software is just more bloated to justify needing the faster hardware; rinse and repeat

anyway thats my opinion.

Re:HTML 3.2

[Anonymous Coward]

W3C validator works (albeit experimental) for HTML5. I don't need HTML5 features but I like that it forces me to use CSS (previously I sometimes got a bit lazy). I don't give a rats what browsers do; if my pages validate that's all I care about. Lucky I don't have to keep clients happy though, because clients tend to be the most demanding and unpredictable validation for any developer, regardless of what browser/version they use.

Re:HTML 3.2

[AmiMoJo]

Problem is that users expect more from a web site these days. Limiting yourself to HTML4 results in masses of Javascript to implement features that are native to HTML5, and lots of bandwidth wasting images to make up for deficiencies of CSS and lack of things like font and SVG support.

A lot of web developers do all that stuff anyway to make up for incomplete or differing HTML5 implementations, because the alternative is trying to maintain two versions of the code to satisfy compatible and incompatible browsers. CSS and HTML5 was supposed degrade gracefully and handle variable width displays properly, but in practice it is very hard to make it work.

Re:HTML 3.2

[Confusador]

Funny, yes, but making sure your site works on Lynx at least to the point that it's comprehensible is a handy proxy for making sure it'll work for a screen reader.

Re:HTML 3.2

[next_ghost]

Well you can just get fucked you useless cunt - your ignorant attitude, on a wider scale, is the type of reason that html5 most likely won't get anywhere.

Eat W3C's and browser developers' shit and like it, if you want to call yourself a web dev!!!

FTFY. And no, I'm not gonna eat someone else's shit. I'll get behind HTML5 when W3C gives me a stable set of features I can expect from its implementation (ie. a fixed version of the standard).

Oh, and the masochistic attitude like yours is the reason why MSIE still hasn't died the horrible death it deserves for its crimes against web developers' sanity.

Re:HTML 3.2

[Anonymous Coward]

W3C

"living standard" crap for HTML5

No connection there. You really need to read up on the matter. Hint: The "HTML5" link in the summary doesn't link to HTML5.

Re:HTML 3.2

[maxwell demon]

It also makes sure that search engines will understand it.

Re:HTML 3.2

[dolmen.fr]

You don't have to remember: http://caniuse.com/

Re:HTML 3.2

[mrrudge]

One of the reasons I call myself a developer is an ability to assess suitability of technology for purpose. html5 is not production ready. It's early push by Apple in particular ( in presenting it as a viable alternative to Flash on iOS ) has led to several differing public implementations before a reference implementation.

It's currently a fragmented mess mirroring previous OS 'wars', that's being used politically by large corporations. The standards body has changed it's idea of progress to match these commercial concerns and it is not certain now these differences will ever be reconciled.

So that would put me in the 'fuck off' camp. A good standard wouldn't require me to 'get behind it', it should be an obvious choice providing uniformity when adhered to. It doesn't. It now may never.

why, standards, of course

[arth1]

What do we develop our sites against now?"

Why, standards, of course. To develop a web site "against" or "for" browsers is having lost the battle before you've even started it.

Re:why, standards, of course

[betterunixthanunix]

You must have not been paying attention over the past 15 years; the battle was already lost, people have been developing against browsers and not standards for a long time.

Re:why, standards, of course

[Daniel Dvorkin]

Yeah, but what standard? That's the problem. For a number of years, ever since we got past the bad old days of Netscape vs. IE, you could point at HTML $NUMBER and say, "that's it, that's the standard." Kind of the point of TFA is that you can't do that anymore, or won't be able to shortly, and it sucks.

Re:why, standards, of course

[Phyridean]

Not that I disagree with your philosophy, but this is rather like saying "Don't develop for real-world conditions. Develop for our theories! I don't care that the real world doesn't conform to our theories, it really should." and then being surprised that whatever you're building doesn't actually work.

Re:why, standards, of course

[Anonymous Coward]

You must have not been paying attention over the past 15 years; the battle was already lost, people have been developing against browsers and not standards for a long time.

Just because it's the way it has always been done doesn't mean that it is correct. Develop for standards. The browser that best supports the standards will be the one that wins. The browser developers should be the ones aiming for compatibility, not the web developers. Once you make the switch, the only viable browsers are the ones that support standards. Bye bye IE. See you never.

If enough high profile clients complain to microsoft that their browser makes their site look funny, maybe they will actually fix it. I realize this is easier said than done, but it's a case of throw a handful of developers for the browsers at the problem to make it standards compliant, or throw millions of developers at the web programming end to try to keep up with it. On the other hand Woo! Job Security!

Re:why, standards, of course

[Anonymous Coward]

Yes, because the average user can fully differentiate between whether the site was coded improperly or the browser is rendering it improperly.

Re:why, standards, of course

[arth1]

Not that I disagree with your philosophy, but this is rather like saying "Don't develop for real-world conditions. Develop for our theories! I don't care that the real world doesn't conform to our theories, it really should." and then being surprised that whatever you're building doesn't actually work.

And that is how you should develop. But, you should, of course test against real world conditions, once you have working code, and not a moment before.
Fix or adjust for the few browser-specific issues that may be left at that point -- they will be far fewer than the issues you create if you code for real world browsers - that's painting yourself into a corner, and pretty much guaranteeing that your product will fail spectacularly when a new browser enters the market.

Resist the temptation to want to see how the web site looks before it's finished. It doesn't buy you anything, and sidetracks you. If you build a building, you build it according to code, and don't build it to fit particular users, or move the windows and resize the doors while building because of how one individual is built.

Re:why, standards, of course

[ep32g79]

Yeah, but what standard?

In most of my web development work it's always been the client that sets the standard. There have been some clients that have said "Support IE6 and beyond" (/cringe) and others that have more reasonable standards, e.g. IE7+, Firefox 3.5+, Chrome 9+

Re:why, standards, of course

[Anonymous Coward]

It's funny - HTML5 was a reaction against the W3C and against standards in general. It is basically a long wish list, with the current "spec" defined by the subset of the list that a majority of browsers implement at any given point in time. I'm not even sure the term 'valid html5' is meaningful. Is this the wave of the future, or an anomaly?

Re:why, standards, of course

[Anonymous Coward]

First develop for modern standards, most of which are implemented on modern browsers. Use feature detection for features that may not be implemented in old browsers that people are still using (*cough* IE6/7/8 *cough*) and find an alternate route for those old browsers, fixing any other quirks you find those browsers create. Otherwise you end up with a website like the US government's FAFSA website (http://www.fafsa.ed.gov), where IE9, FF4, Chr9+, and O11 are not supported (only IE9, through quirks-mode a.k.a. pretending to be IE8, can fill out the FAFSA; otherwise all modern browsers are sent to an incompatible browser page https://fafsa.ed.gov/FAFSA/app/errors?page=incompatibleBrowser). If your develop for browsers, you end up with something stupid like this in the worst-case scenarios. If you develop for standards (which, once they reach last call or recommendation status, tend not to change rapidly), you just have to ask the browser if it supports that part of the standard, and if not, then you rattle your head as to why people are still using things like IE6 and try to figure out a workaround in those odd cases..

Re:why, standards, of course

[Anonymous Coward]

LOL, you're so silly. Have you ever done any actual software development? Any at all?

Re:why, standards, of course

[next_ghost]

The de facto standard is IE.

Which version? I know at least a dozen differences in rendering of HTML 4.01/CSS2 between any two major versions of IE out there.

Re:why, standards, of course

[arth1]

LOL, you're so silly. Have you ever done any actual software development? Any at all?

Since the days of Mosaic, actually. And as late as, um, today?
More than two million lines of code according to the CMS, both front-end and back-end. Including, most likely, several sites you have been on, and may even have bookmarks to.

For the past decade or so, the only times I have had to modify a site after delivery is when the customer asked for functionality changes, or someone else had messed up the site by adding browser-specific code.

Now what are your qualifications again, Anonymous Coward?

Re:why, standards, of course

[achbed]

The browser that best supports the standards will be the one that wins.

Wrong. The browser that the corporate IT organizations use wins. Period. If some giant corp requires the use of IE6, you will code to that because they will not allow you to dictate the internal "approved" infrastructure because you want something fancy like proper DIV handling or modern security. The larger the company, the more it becomes "the devil you know".

Re:why, standards, of course

[Eponymous Hero]

if you think IE is ubiquitous because web developers never took a stand against it, you are hopelessly naive. the microsoft standard wasn't created by developers, it was created by businesses who put millions of IE browsers in front of their workers. IE won't go away simply because some other browser developer will make a better browser -- that's already been done! good lord, you are naive.

your idyllic utopia:

pogue: look boss, this website we developed for the company looks like crap on IE browsers when we follow web standards.
boss: oh that's alright. you did it the right way, despite that the majority of users have IE. i'll just complain to microsoft and they should have their browsers fixed before our launch deadline.

reality:

pogue: look boss, this website we developed for the company looks like crap on IE browsers when we follow web standards.
boss: well make it look good in IE (as well as other browsers that follow web standards to differing degrees), and your deadline still stands. oh, and there's a list of features we'd like to add while you're in there testing. some of them contradict the user stories you've been building for. make it work in IE 5.5 for mac too. because my mom uses that, and when i show it off to her i want it to look perfect.

Re:why, standards, of course

[cavreader]

The question is are the standards evolving as fast as the functionality needed on today's web pages? With the proliferation of browsers and each of them trying to out do the others in feature and performance will they let standards get in the way or just support the new functionality even if it breaks the standards. Most web users, both public and business users, could really give a shit whether the browser is standards compliant they just want the functionality to work and the web developers in the business sector in particular are not going to hold up the development just because they might have to violate the standards. This entire issue is really no different than all the other aspects of modern system design. Things change rapidly. From cpu's, OS's, and development models what worked last week might not work this week. As a developer it seems like right when you get proficient on a particular set of technology the technology changes and you have to start over again. It makes for an interesting job but can be a pain in the ass sometimes.

Re:why, standards, of course

[grahamd0]

In most of my web development work it's always been the client that sets the standard. There have been some clients that have said "Support IE6 and beyond" (/cringe) and others that have more reasonable standards, e.g. IE7+, Firefox 3.5+, Chrome 9+

I've never felt that IE7 was substantially better than IE6.

The addition of transparent PNG support and a few more CSS selectors is great, but it's got almost all of the same rendering bugs that IE6 does.

Re:why, standards, of course

[grahamd0]

More junior developers are usually surprised when they show me a site that works great in Firefox or Safari, but breaks in IE, and the first thing I do is change it enough to break identically in the working browsers.

But then suddenly the fix is easy, obvious and universal.

Re:why, standards, of course

[arth1]

Indeed. And that's a lot less work than trying to make exceptions and special conditions for each and every browser..

It's like "Doctor, my back hurts when I bend forward to put my hands on the ground, and then twiist 90 degrees." And the same reply as the doctor will give you applies here too.

Re:why, standards, of course

[terrox]

Although if ALL web developers DID take a stand against IE, Microsoft would certainly fix IE all the way back to IE6 - they would never risk losing that much share. This will never happen.

Re:why, standards, of course

[Anonymous Coward]

I would say that most buildings are purpose built. I haven't seen too many office buildings that look like warehouses or houses that look like sports complexes. Also, windows are often designed to give a better view of the area the building is built in, not just stamped out to what they did a city over.

Also, I typically do want to see how my site looks prior to finishing it. If there are major issues I can tackle them early and avoid repeating them as I continue development. I can't recall ever writing a whole page and waiting until I think I'm complete before viewing it and making sure I like the direction it is headed.

Re:why, standards, of course

[dudpixel]

what?

pretty sure you can still code for HTML1 and it will still work.

It seems like people are worried that they wont be using the latest stuff when the product finally ships...but if you dont know what the latest stuff is yet, then this is just silly.

develop for HTML5. done.

Its not like any new standard that shows up will mean that HTML5 will suddenly stop working. The web still works even though we have new browsers...and I'm pretty sure no one is going round updating every single website in the world every time there's a new browser release.

Re:why, standards, of course

[Daniel Dvorkin]

develop for HTML5. done.

Again, the point is that you cannot define what "develop for HTML5" means the way you could define "develop for HTML $X", where $X was any release from 1 to 4 (including point releases.) That is not a good thing.

Re:why, standards, of course

[witch-doktor]

Operation Tunisia
Operation Egypt
Operation Sony

and so on.

-Anonymous

Re:why, standards, of course

[yuhong]

Yea, from what I read IE7's layout engine feels like a hack on top of IE6's. It isn't just CSS, BTW. Guess why the contents of OBJECT elements don't show up in the DOM in IE7? Clue: IE7 fixed the bugs where nested object elements were still initiates even when fallback is not needed.

Re:why, standards, of course

[Anonymous Coward]

Speaking as someone who has been a professional web programmer since 1995, I don't agree at all. If you're trying to do complex UI on the browser, if you develop to published standards rather than developing to what you (should) know the browsers actually do, you'll waste a lot of time fixing it to actually work after you discover that none of the browsers really comply with published standards.

The real way to save time is to use an abstraction layer that takes care of the browser quirks for you, so you don't have to care which browser the user is on and can create a single layer of presentation and a single layer of business logic and not worry about it. Then you just upgrade the abstraction layer from time to time and things keep working.

Re:why, standards, of course

[lonecrow]

Oblig. http://validator.w3.org/

Re:why, standards, of course

[cavebison]

Why, standards, of course.

Back in the real world, we develop for the audience our application has. If it's an in-house app for IE6, that's what you have to take into account, or get another job.

Look at the Google search page. CSS as part of the web page, and tables used for some layout. Shock horror. The rule is whatever works best for your app and its audience. That might be 80% standards and 20% custom fudge.

Re:why, standards, of course

[cavebison]

But, you should, of course test against real world conditions [...] Resist the temptation to want to see how the web site looks before it's finished.

Firstly, you should know what the site is going to look like anyway, and secondly those are a bit contradictory - if you wait till it's "finished" (whatever that means in the real world) till you start testing, you're in for a lot of rewriting.

Re:why, standards, of course

[DI4BL0S]

Yes because you can always include something like

Dear valued customer, we regret that the browser you are using does not adhere to web standards and is not capable of handling all the great things this website has to offer, May we advise you to download a browser instead of an explorer. Any choice will do really as it seems that only Microsoft is incompetent enough to adhere to world wide web standards. we suggest a browser like Chrome, Firefox, Opera or Safari. This will not only greatly improve your internet experience but will also protect you against allot of Virus & Malware treats. We hope to see you again soon with a browser of your choice.
if you continue browsing on this page with your current browser you may experience incorrect page behaviour.


maybe leave some of the anti microsoft speak out of it but you get the pickture

Re:why, standards, of course

[buchner.johannes]

I have never understood why people love to shoot themselves in the foot by targeting browsers with weird hacks. Just use the common ground that all browsers support. Design additional elements so that the browser can degrade smoothly to something simpler if it does not support them -- This degradability is not well understood or practiced by the average web developer in my eyes.

Re:why, standards, of course

[Anonymous Coward]

I know what you're saying but is it really that hard? For me it's XHTML 1.1. It's a solid, stable standard that, being XML, works fully with various other XML tools such as XSLT.

I guess the problem is that most web developers are a bit special, they don't really have good computing backgrounds and often tend to come into developing for the web via the rather chaotic and inconsistent but forgiving PHP. Most developers with a more professional development background should be more than capable of understanding what standard is best for the job.

Re:why, standards, of course

[Jonner]

That's why we develop for XHTML 1.0 where I work. We don't need any of the fancy new features and we don't have to spend much time thinking about browser compatibility.

Re:why, standards, of course

[Anonymous Coward]

We tried that at a previous job.

Develop for IE4. Tell IE3 users to download IE4. Tell Netscape users to download IE4. Tell IE5 (yes, really) users to download IE4.

IE5 became too important to ignore.

Rewrite for IE5. Tell IE4 users to download IE5. Tell Netscape users to download IE5. Tell IE6 users to download IE5.

IE6 became too important to ignore.

Rewrite for IE6. Standardize on IE6. Block Windows Update from installing IE7/8/9.

At my current job, we develop for Firefox (not quite the standard, but close enough that things usually works in everything but IE). Then we fix the stuff that doesn't work in IE8. When IE9 came out, nobody worried, because we knew it would be somewhat closer to standards than IE8, so either the standard way or the IE8 way ought to work.

This way of doing things works much better than targeting the current version of IE, and we don't need to rewrite all the time.

Re:why, standards, of course

[CProgrammer98]

MOD PARENT UP >9000!

Oh I wish I had mod points. I'm fighting this very battle right now in my company (a large insurance co) Devs don't seem to give a rats ass for standards, half of them wouldn;t know an html validator if they tripped over it. Our acceptance tests don't check for compliance, they just check that our pages look good on a list of specific browsers. I'm crying on the inside over my current assignement (DDA compliance on one of our sites; they first step of which is to ensure our pages validate against html 4.01 strict)

Re:why, standards, of course

[Anonymous Coward]

Dear Supplier,

May we advise you to invest in a course of study of the English language.

There you may learn that "allot" means "to allocate" and that a common alternative for "more than a few" is "a lot" (especially note the space between "a" and "lot". Also you may discover that "treats" are good things (if malware provided treats, it wouldn't be malware), that pickture is not a word (but picture is) and finally, you may get to master the very important principle of starting sentences with the first letter of the first word in upper case, and completing them with a period.

Re:why, standards, of course

[doohan]

protect you against allot of Virus & Malware treats.

Mmmmm tasty Malware Treats. Get yours now!

Re:why, standards, of course

[Anonymous Coward]

others that have more reasonable standards, e.g. IE7+, Firefox 3.5+, Chrome 9+

That word doesn't mean what you think it means. Here's what it means.
Grandparent has half a clue:

you could point at HTML $NUMBER and say, "that's it, that's the standard."

$NUMBER = 5
This is the HTML5 spec. What the link in the summary points to is not the HTML5 spec but Mr Hickson's private scratchpad, and he doesn't even call that HTML5. HTML5 is in Last Call, which means that most of it is pretty stable now, and will be rock solid in 2014. So that's it, that's the standard. If you don't like it, use HTML 3 or 4 or XHTML 1.

Re:why, standards, of course

[ep32g79]

You are still missing the point. It's not the Technical Standard that you program for, but quite simply the customers standards.

Re:why, standards, of course

[losinggeneration]

And that is how you should develop. But, you should, of course test against real world conditions, once you have working code, and not a moment before.
Fix or adjust for the few browser-specific issues that may be left at that point -- they will be far fewer than the issues you create if you code for real world browsers - that's painting yourself into a corner, and pretty much guaranteeing that your product will fail spectacularly when a new browser enters the market.

Which is exactly why you still see web apps that require IE6 and fail for pretty much anything else. They developed for a browser instead of the standard. It's sad that people still try to do this even though history has shown us it's bound to be extremely problematic.

Re:why, standards, of course

[dolmen.fr]

Although if ALL web developers DID take a stand against IE

Microsoft itself take a stand against IE 6: http://www.theie6countdown.com/

The status quo will only change when organization will massively move from Windows XP to Windows 7 because they will move to IE 9 at the same time.

Re:why, standards, of course

[dolmen.fr]

This is the HTML5 spec.

Can't you read? W3C Working Draft 25 May 2011. Not a final spec.

And there is a big red warning at the bottom that suggest to read potentially a more up-to-date document : http://dev.w3.org/html5/spec/Overview.html

Re:why, standards, of course

[Anonymous Coward]

Nobody complains to the browser manufacturer. The site owner complains to the web developer before it ever goes live. And the developer changes it because s/he wants a paycheck.

Testing

[ustolemyname]

Testing has become a bigger pain then it used to be. Before I could cover everything (except browsers on OS X) in just a handful of virtual machines. Now? The number of parallel installs required and the constant need to add new browser versions is becoming a pain.

I'm starting to wonder if maybe it's simpler just to test against an older version of the browser (ie chrome 6) and the latest (chrome 12) and run with the assumption that nothing is broken in between. Thoughts?

Re:Testing

[Daniel Dvorkin]

You could always put up a "This site is best viewed in ..." button, for that touch of 90s nostalgia.

Re:Testing

[starsky51]

Take a look at Spoon. It's a browser plugin that launches applications in their own virtualised environment. Meaning that different versions of the same browser can run alongside each other, without you having to con Windows into it.

Re:Testing

[Anonymous Coward]

Not necessarily a good assumption, but it has been my experience that people either don't update because they have some piece of software holding them back that prevents them from updating, or don't update because they don't know any better. If the latter, they can be told to upgrade fairly easily, and the process is not difficult. If the former, well, they can just use a different browser for everything but the piece of shit software that won't support anything that was released less than 2 years ago. (I'm looking at you *nameless company who makes software a lot of universities use for a whole bunch of stuff*) Quite frankly, we have provided a thinapp internally that runs the old version of firefox because this program doesn't even support IE8 yet and only started supporting IE 7 a few months ago, but feel as though if the companies making these monstrous packages can't be bothered to upgrade their software to work with modern browsers, they should provide their own bloody "browser" and just make the whole thing a proprietary app. It's not like they haven't made it so much of a pain in the ass that it wouldn't matter to their clients if they did. If they did provide their own for this purpose only browser, locked down to a certain set of URLs for internal use, at least their clients wouldn't be courting disaster every time they browsed the internet with their horribly out of date unpatched "multi purpose" browser.

I don't see the point of busting your ass to make things compatible for people (or companies) who are too lazy or uninformed to upgrade, or why companies pay people to bust their asses to do this. If you have a customer who would be alienated by having to spend 3 minutes to update their web browser screw em. They should get off the internet. Many flash apps require you to update to the latest version of flash player to use their content. Why us doing the same thing with websites so horrifying to people?

I would rather web developers were able to find time to make sure their sites were accessible to the visually impaired and the color blind rather than frantically try to make things work for people who don't know how to run windows update or click OK on the update box.

On the other hand, If people want to see the (potentially) degraded content, it should be allowed. The "I don't recognize your browser so I'm not going to let you look at my site" thing was really frustrating when I was experimenting with Opera, OmniWeb and iCab (there's a blast from the past) Yay fake User Agent strings!

Re:Testing

[Anonymous Coward]

Since you have to go out of your way to prevent Chrome from automatically updating itself, we've decided we will only support the latest version of Chrome, whatever that happens to be. We would like to use this same policy for all "rapid release" browsers, but it remains to be seen if Firefox will auto-update as painlessly as Chrome. If it doesn't, my personal opinion is to drop support for Firefox out of sheer impracticality.

Re:Testing

[SmilingBoy]

I'm starting to wonder if maybe it's simpler just to test against an older version of the browser (ie chrome 6) and the latest (chrome 12) and run with the assumption that nothing is broken in between. Thoughts?

Regarding Chrome specifically, it is very simple. Virtually nobody has an old version of Chrome as it gets updated automatically (and this really works - look at the statistics two weeks after a new version came out). So just test against stable, beta and dev.

Re:Testing

[ustolemyname]

Fair enough. I originally wrote "firefox 3" and "firefox 4", but figured that though the spread is growing, not everybody may think that 3.5/6 are hiding in there. You are correct, chrome is a silly example. Running it on linux, I wasn't aware of the autoupdate feature on other platforms.
It's more the leap from ie7 -9 that's starting to get me, along with firefox. And mobile testing, bah.

Re:Testing

[Anonymous Coward]

My copy of Firefox can't handle updates at all, let alone automatically applying them. I'm running 3.6.15 (yeah, I know, I haven't got round to running the dmg to upgrade to 4 yet) and it can't see any updates when told to check for updates - but there's 3.6.16, 3.6.17 or 4.whatever available. Thunderbird did the exact same thing.

Re:Testing

[ustolemyname]

Thanks, I'll give that a shot.

Re:Testing

[bunratty]

Hardly anyone runs the old version of Chrome just a week or two after a new version is released. Why the hell are you testing against many different versions of Chrome? Do you bill by the hour?

Re:Testing

[Eponymous Hero]

I don't see the point of busting your ass to make things compatible for people (or companies) who are too lazy or uninformed to upgrade, or why companies pay people to bust their asses to do this

i'll make it simple for you to understand. it's called the LCD - Lowest (or Least) Common Denominator. many people far more clever than you at making money and manipulating people through marketing have determined that the more people to whom you can get your message across, the higher the return on investment. just like how you keep getting flyers in the (snail) mail that have nothing to do with your needs. ignorance of how to make your clients money is the source of all your questions.

who is your demographic? for quite a few markets, the elderly are prime targets. the elderly make up a majority of those people who you wish would get off the internet. for the companies that make money on this demographic, they want these people to stay on the internet. sure, it would be nice if they upgraded their crap, but if all it takes is making a bunch of web developers stay late to accomodate their old browser, then so be it.

another real world example: the LCD is why nintendo put out that really shitty wii console that immediately outsold all other consoles, despite inferior hardware and games. it wasn't until developers showed the greater video game market that kinect games could be just as shitty as wii games that the market shifted again. god forbid an awesome game came out for use with kinect, it might have killed the tech off altogether.

Re:Testing

[Eponymous Hero]

does not work. i'm gonna take a break from trolling and try to actually be helpful here. i have personally seen instances where the same code that works in IE6 behaves differently in IE7, differently again in IE8, and again in IE8 with compatibility mode, and again in IE8 with compat mode and IE7 standards, and again with all those combinations but this time with Quirks mode. i have had CSS headaches where an IE hack meant to solve an issue in IE7 ends up breaking the layout in IE8. after that, the * hack no longer applies. i find that loading separate css files for each browser version supported helps a lot.

Re:Testing

[aztracker1]

You could always be a bit more discrete, like this when viewed in IE. Personally, if it's up to me, I check in IE9, Chrome Dev channel and Firefox (latest) ... I tend to use Chrome dev channel as a rendering bencmark of how it *should* look... firefox rarely needs tweaking, IE9 a few here and there, and older IE, takes more...

Some general html5 syntax with additional tags, and css5 do a lot of the heavy lifting now, and js is relatively light/fast when done right. I try to make non-admin interfaces at least functional in older browsers... but depends on your needs and the target.. not doing some test as you go for layout will lead to dramatic issues further in.

Re:Testing

[aztracker1]

had a problem earlier today with ie7 specifically.. grr... need to get XP users to Chrome or FF... everyone I've introduced to Chrome loves it.. multi-user scenarios in windows is the only pain with it. I would like an adblock that really works like the FF version (blocked before remote requests)... but that's my only real gripe. The auto update is my biggest reason to push now, tired of out-dated browsers at every turn.

Re:Testing

[BZ]

For what it's worth, IE9 is a better benchmark of "how it should look" than Chrome in many ways. Of the four major rendering engines, WebKit has the buggiest CSS 2.1 support, for example...

Re:Testing

[whereiswaldo]

Try checking for updates using the account that installed the software, if you haven't already. I've found that Firefox doesn't want to update itself in a different (but also admin) account on OS X than the one that installed it.

Re:Testing

[Anonymous Coward]

Why don't you just use http://browsershots.org/ ?

Re:Testing

[aztracker1]

And what of CSS3, no linear gradient backgrounds in IE9, which has caused me a *LOT* of headaches, as rounded corners + the filter for gradients in IE9 fails... css3pie works okay for IE6-8, but I can't do a lot of things in IE9 that I would like/want to do... I can get around a lot of this with inner shadows, but not the same. There's also the fact that MS isn't releasing IE9 for XP, or IE10 for Vista... I'd rather have chrome's always updated by default and continuous develop/release approach so then the experience is at least predictable.

Re:Testing

[BZ]

We're talking about correctness here, not feature checklists. Last I checked, there wasn't even an agreed-on syntax for linear gradients. WebKit and Gecko use different syntax for them.

My point being that if you assume that any given browser's rendering of something it claims to support is "correct" you will get burned more with Chrome than with IE. If you have such an expectation for anything from CSS3, you will naturally be doubly burned, because often there is no "correct" for it yet.

I'm glad you prefer the approach of shipping buggy things just so you can list them on your feature checklist. But is it a better approach for web developers? Hard to say.

Re:Testing

[aztracker1]

in IE, filters for gradients etc are supported... rounded borders are supported... gradient + border radius = fail... I can only say that expected rendering work more consistently for Chrome than IE in my experience. As fore standard.. well, thats what vendor prefixes are for... -ie-* would be acceptable imho. It's still better than falling back to complex markup and tables for said rendering...

Re:Testing

[BZ]

Oh, IE has its share of bugs. I'm just surprised you haven't run into more problems with Chrome... I mean this is the browser that can't draw a non-opaque border correctly.

I have a challenge for web developers

[MobileTatsu-NJG]

Stop making links open new tabs. Let me decide when to use a tab and when I want it to just be a back-button away!

( Sorry, I admit I didn't really have anything productive to add to this particular discussion. )

Re:I have a challenge for web developers

[Anonymous Coward]

You can probably fix that with a browser setting in many situations. Perhaps you have it default to open in a new tab, and default to the new tab having focus.

It's more upsetting to me when they break my middle-click functionality. If I use the "open in a new tab" button, it means I want to open it in a new tab.

Easy...Netscape Navigator

[Anonymous Coward]

Just avoid the blink tag and you should be fine.

Side note: A blink tag for /. would come in handy...

Re:Easy...Netscape Navigator

[Xtifr]

Just avoid the blink tag and you should be fine.

I saw Marc Andreessen give a talk shortly after the initial public release of the Netscape Navigator code. One of the things he mentioned was that the very first patch they received from outside Netscape was one to make the blink tag work with images!

The little remaining faith I had in humanity died that day. :)

Re:Easy...Netscape Navigator

[CastrTroy]

Easy enough to accomplish with an animated GIF.

Obvious

[Anonymous Coward]

Make it functional in IE6 and above. Make it pretty in IE8 and above. If your site generates gazillions of dollars, make it pretty in IE6 and above.

And the standard is....

[Anonymous Coward]

....IE 6!

Re:And the standard is....

[drb226]

We desperately need a "sad but true" mod.

As an end-user...

[Anonymous Coward]

As an end-user, I'm perfectly happy with Firefox 3.6. I tried FF 4 on another computer just for testing and didn't really see any difference aside from some minor UI changes.

Re:As an end-user...

[Runaway1956]

You obviously don't run any benchmarks. Try Acid1, 2, and 3 - then try Peacekeeper. The side-by-side results from FF3.6 and FF4.0 aren't overly dramatic, but they do show that FF4 has more capability than 3.6 Then, try FF5b and FF6a to see even more improvements.

Failing to upgrade won't mean that you are left behind overnight - but you may find yourself left behind if you don't pay attention. "Hey, AC, have you seen that cool new shits on wildwhackybling.com?" "Nahhhh, that shits won't load in my browser, so I just closed the tab." "Man, you gotta get with the times!!! Change to blah-blah browser, then go to wildwhackybling!"

Re:As an end-user...

[Anonymous Coward]

Of course I'm not running benchmarks. I use my browser for viewing web sites, not running benchmarks. FF 3.6 works fine for all of the sites I use and FF 4 didn't show any improvement.

Hit standards, miss the market

[xxxJonBoyxxx]

See comment on "testing" - if we simply targeted standards, we'd never deliver product.

BTW, this happens in other industries too. Life is harder than college - get used to it.

Re:Hit standards, miss the market

[arth1]

See comment on "testing" - if we simply targeted standards, we'd never deliver product.

You target standards, and test with a validator before it even hits the first browser in test phase 2. That reduces the delivery time.
Especially when a new browser comes out in the middle of the development process, and you won't have to rewrite a single line of code.
Oh, and it will be future proof too, and work just as well in Firefox 7 as in IE 12.

Re:Hit standards, miss the market

[Anonymous Coward]

You cannot possibly be serious. It is impossible to know how a browser will render certain constructs. Just with tables (i.e. tables within tables with tables with conflicting constraints, horizontal alignment) and once you get to CSS and Javascript it get much worse.

But that has always been the situation, the w3c from the beginning did an abominable job at standardization and interoperability. It's just the way it is and we have to deal with it. But just because it is doesn't mean it's not an abomination.

Re:Hit standards, miss the market

[Anonymous Coward]

LOL, is that something that one of your comp. sci. professors taught you? Or are you the professor preaching that crap to your students?

You're spewing bullshit and nonsense theory like only an academic, or somebody who is gullible enough to listen to an academic, can. In the real world, everything you just said is totally false or totally inapplicable.

Re:Hit standards, miss the market

[arth1]

You cannot possibly be serious. It is impossible to know how a browser will render certain constructs.

Which is exactly the point. You don't know, so don't make any assumptions about it either. If you have coded for the standards, it will render it readable, and quite likely looking good too.
Even when the users do such unthinkable things as changing the defaults, or downloading a browser that wasn't even out when you made the site.

(Unlike the latest incarnation of this site, I may add, which looks horrid for quite a few users because the clueless designer obviously targeted it at specific browsers, DPI settings and font sizes.)

Re:Hit standards, miss the market

[Chuck Chunder]

You target standards, and test with a validator before it even hits the first browser in test phase 2

Which would be more useful, if browsers met those standards reliably. Even modern browsers have quirks. In IE 9 for example rounded borders suddenly stop working on a fieldset if it has a legend.

I am fortunate enough to only have to deal with vaguely modern browsers (I mostly work on a non public app where we can set reasonable minimum requirements for supported browsers) but there are still nasties and work around we employ now may well bite us and require reworking when a new browser version turns up.

Re:Hit standards, miss the market

[Anonymous Coward]

In IE 9 for example rounded borders suddenly stop working on a fieldset if it has a legend.

You did realize that rounded corners aren't in any current standard before trying to make them work, right? That's his point - building to current standards tend to make things less painful. Sure, there's always something that's not quite to standard in a browser, but at least you have that concrete base to work from.

Re:Hit standards, miss the market

[Anonymous Coward]

Those rounded corners really make the web app more usable.

If you're users are only complaining about squared corners, I need your users for my web app.

Re:Hit standards, miss the market

[smellotron]

In IE 9 for example rounded borders suddenly stop working on a fieldset if it has a legend... I mostly work on a non public app...

Oh dear, please tell me that "no rounded borders on a non-public form" was never an actual deal-breaker.

Re:Hit standards, miss the market

[DrXym]

See comment on "testing" - if we simply targeted standards, we'd never deliver product.

BTW, this happens in other industries too. Life is harder than college - get used to it.

The correct way to develop web content is against the standards and make exceptions where necessary for a browser. It may be that QA sort browsers into various tiers so some browsers need more attention / hacks than others. But always code to the standard first. If it turns out IE has a problem with some CSS rule, or Firefox has a race condition for something else you can surgically deal with that one problem and leave the rest standard. AJAX tools like JQuery help too especially for perrenial headaches like XMLHttpRequest

Re:Hit standards, miss the market

[Anonymous Coward]

"In IE 9 for example.."

Which IS NOT and SHOULD NOT be your concern. When a bug is in another product, you DON'T break yours. You point the users to the party responsible for fixing the other product. To do anything else is INCORRECT, and HARMFUL.

"This is a bug in Microsoft Internet Explorer. Please ask your system administrator to resolve it with Microsoft. Closed. INVALID."

Re:Hit standards, miss the market

[tbannist]

If more people target the standards and complain when the browser makers don't then the browser makers will do a better job of targetting the standards. If you target a browser, that browser has no incentive to improve their implementation of the standard, and the more people who target the browser, the large the disincentive to improve because fixing something might break something other people are relying on.

The IE9 issue is trivial and should not be addressed. Tell Microsoft it doesn't work and that you're not going to work around it, so they can fix the bug or they can live with web sites that look worse in IE9 than in every other modern browser in the world.

Re:Hit standards, miss the market

[Hognoxious]

If more people target the standards and complain when the browser makers don't then the browser makers will do a better job of targetting the standards.

The hell they will.

Microsoft can ignore you because, well, they're Microsoft. And they will.

Mozilla will tell you that if the users want Firefox to conform, then the source is out there for them to modify.

Any others? None that matter.

Re:Hit standards, miss the market

[tbannist]

The more people who say "this browser doesn't work" the harder it becomes to shrug off the complaints. Microsoft was only able to ignore browser standards as long as developers were content to pretend that IE was the standard and that the standard was wrong if it didn't work in IE.

The more that people target the standards, the less any group can get away with implementations that don't work. To the end user when one site doesn't work in a browser, it the site's fault, when many sites don't work in the browser, it's the browsers fault.

Flash

[Rob Riggs]

Use HTML4 and Flash. That's good enough for everyone that matters. :-)

Re:Flash

[TarMil]

So for you, iOS doesn't matter?

Re:Flash

[rrossman2]

Nope, I have an Android phone :)

Re:Flash

[Anonymous Coward]

yes. fuck the iPhone and every other iShit device and the idiots who bought them.

Re:Flash

[tyrione]

Use HTML4 and Flash. That's good enough for everyone that matters. :-)

That's rationale. Not! Skip WebGL, shit can Canvas, WebApps, WebSockets, etc., all for Adobe? Pass. Hell, even Adobe is contributing to Poppler which makes it clear to me that even their own stuff [PDF] rendered sucks compared to an outside project. There was a reason Apple wrote Display PDF--they're better at it.

Re:The AllBrowsers service

[Drooling Iguana]

I'm not going to click on your link as it's a tinyurl. This isn't Twitter; you can link to proper URLs here, so that people can actually see where they're going before they click.

Re:The AllBrowsers service

[Shikaku]

Goatse link.

What do we develop against?

[Anonymous Coward]

IE8. IE6 is dead, IE8 is going to be the biggest common denominator at least until extended support for Windows XP ends.

Listen up, Mozilla: Microsoft still defines the web. If you want to change that, you need to become much more predictable and stop mixing production software and experimental features. Anyone who targets your software learns very quickly that a maintenance nightmare is unavoidable, unless one restricts everything to a stable feature-set, for example that which is also available in IE8.

Re:What do we develop against?

[rrossman2]

I ran into an issue with IE with CSS. (Besides the transparency tag difference for IE vs FF, Chome, Opera, Safari). I have some blank DIV's setup as spacers in a list (think of like a vertical UL).

I had to mimick a pre-existing Flash based site into just HTML, CSS, JavaScript. Only had a short period to do this for a lady in another department (mostly because it's not a department we oversee, so it was more of a when I had free time deal). Anyhow, looks the same in FF, Chrome, Opera, Safari.. but hit it with IE and the DIV heights just go to shit and the list basically goes from the top to the bottom of the screen. Stupid IE.

Re:What do we develop against?

[Anonymous Coward]

Blank divs as spacers??? As much as i dislike IE, i don't think you can really blame it for rendering your bodgy web design badly.

IE6

[nedlohs]

with flash if you want to be fancy.

Re:IE6

[amicusNYCL]

It pains me that people still mark comments like that as Insightful. Look up Sencha/ExtJS or another full-featured framework with UI components. Javascript plus CSS and images can do a ton of extremely useful things that we used to need Flash for. I'm not positive about this, but I think the only thing that ExtJS 4 uses any Flash components for is for some really nice charting tools. That could change with support for canvas, but one of the advantages of ExtJS 4 is that it works in IE6. Granted, like all things Javascript, IE6 takes its sweet goddamn time to do anything, but it does work.

I take that back about the charting, apparently ExtJS 4 uses SVG and VML, not Flash (unless the browser doesn't support SVG or VML).

Did I mention the API Docs?

It's not 2001 anymore, even though we have to support a browser from 2001 doesn't mean our tools need to be that old also. There's nothing Insightful about telling people to target IE6 and use Flash for anything "fancy". There are hundreds of thousands of people using the applications I've built with ExtJS (older versions, no less), and I bet a lot of them use IE6.

Re:IE6

[nedlohs]

1 person is not "people".

The other moderated worked out it was a joke...

This is why

[lul_wat]

This is why I got out of any type of web design work, and if a friend asks me to make them a site, I just say no. This is just going to keep happening and happening. Just wait till IE20 & FF20 are out.

Re:This is why

[Anonymous Coward]

So... next year?

Re:This is why

[Anonymous Coward]

I gave up on web standards when IE5.5 still had a significant installed base and didn't see the need to change my decision whilst IE6 continued the trend of making life hell for front-end designers. Instead I chose to focus on content with front-end done in simple HTML4. My time was much better spent learning Perl, DBI, Template Toolkit, PostgreSQL and how to get what matters onto a web page. I managed to reduce the need for Javascript to next to nothing. Client-side form validation doesn't stop hackers so just do it in Perl on the server. Most Javascript and non-basic CSS is just eye candy. Fine if you have time on your hands to become an expert in browser incompatibilities with HTML/CSS/Javascript and DOM. I don't miss those days with 3 machines running and nothing more to show for being up 'til 3 in the morning than a page which renders cross-browser. I haven't looked back since.

Re:The AllBrowsers service

[Anonymous Coward]

Preview of TinyURL.com/5szfvml
This TinyURL redirects to:

        data:text/html;base64,PHRpdGxlPllvdXIgdXJsIGF
udGktc2hvcnRlbmVyIHdvcmtzPzwvdGl0bGU+PGltZyBz
cmM9aHR0cDovL2JpdC5seS9lakdqdEsgaGVpZ2h0PTEwM
CUgLz4K

which is:

<title>Your url anti-shortener works?</title><img src=http://bit.ly/ejGjtK height=100% />

which is a link to goatse.

Wait until 2014.

[Anonymous Coward]

Then HTML5 will be finalized and XP will have its support dropped so no more IE6,7 and 8 to worry about. Until then design for IE7/Firefox 3.6 and if your business still needs IE6 then install another browser, the world isn't going cater to your old browser forever, no matter how persistent your incompetent managers are.

tus sorular

[Anonymous Coward]

http://www.tusason.com/tus-sorulari.html

BlueGriffon

[Anonymous Coward]

WYSIWYG html editors will always be used by the large majority of cheap developers, so whatever they spit out is the lowest common denominator.

HTML5 or GTFO

[LavosPhoenix]

Simple, just use HTML5. If your POS browser doesn't support it then delegate that browser or user to the ash heap of history.

This article is confused

[roca]

This article is confused in so many ways, it's hard to know where to begin.

One big thing that it misses is that a lot of "HTML5" is actually writing a detailed spec for existing features that were never properly specified (e.g., HTML parsing). And a lot of the work of implementing HTML5 in a browser is to get those details right so they're the same across browsers. That helps Web authors who aren't even using any of the new features.

The list of HTML5 features has many errors. "contenteditable" is nothing to do with Web Forms and is not new in HTML5; it's been implemented in all browsers for a long time, and HTML5 just provides a (partial) spec for it. Falling back to SVG when canvas isn't available would be a mistake since every browser that supports SVG also supports canvas.

I don't know how Microsoft's "native" sloganeering got mixed up in there, because it's completely irrelevant, but let's point out that it's completely bogus. It's not even clear what they mean by "native"; the best guess is that it means "abstraction layers are bad so a browser that only runs on Windows 7 must be the best", which is complete nonsense.

John Foliot is wrong about the need for frozen spec snapshots. We often find errors in supposedly "stable" parts of the spec; if those parts are frozen in some official snapshot, that just means the snapshot is going to be more wrong than the the up-to-date version.

Web developers should always look at the latest versions of the specs for the features they use. They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.

Re:This article is confused

[merreborn]

They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.

I'm involved with a site that's 44% IE6-8. We've even got a vocal (albeit tiny) set of users running IE6 on Windows 2000 or older, which means they don't even have the full set of IE6 service packs (only XP and newer got anything more recent than IE6 SP1).

It's delightful.

Re:This article is confused

[SanityInAnarchy]

Falling back to SVG when canvas isn't available would be a mistake since every browser that supports SVG also supports canvas.

It also seems like it's missing the point. If what you want to do can be done in SVG, isn't that a better choice anyway than canvas?

Re:This article is confused

[roca]

That is generally true but sometimes you could do it either way and get better performance with canvas.

Re:This article is confused

[cavebison]

They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.

That's the most sensible comment I've read so far.

Re:This article is confused

[SanityInAnarchy]

...which is likely also missing the point.

I'm sure sometimes it makes sense, but it seems to me that in most cases, it's a browser implementation detail which has better performance. What's relevant is that SVG is actually more flexible -- it does actually fit as a more natural extension to HTML. You can have things like hyperlinks inside it, and I'd imagine microformats. You, and your users, can mess with it in similar ways to what you do with HTML.

Canvas is for stuff you can't do with SVG, or for when you're absolutely sure SVG's capabilities are irrelevant. But as far as the DOM goes, Canvas is this opaque blob -- kind of similar to, say, a video tag. Sometimes it's exactly what you need, but would you ever use a video tag as a substitute for good old-fashioned DHTML animation, if you can do it both ways, even if the video tag had better performance in some browsers?

Disclaimer: I am not currently working with either technology, or, really, as a web developer. I've done some of this stuff in the past, but I didn't get too deep into either, partly because I actually couldn't count on either SVG or Canvas being present and working well for the browsers we were targeting, and partly because I didn't actually need either.

Re:This article is confused

[Anonymous Coward]

I'd say getImageData/putImageData are the core of what canvas is useful for. manipulating RGBA bytes.
Kinda like GIMP vs Inkscape.
Sure you can use GIMP + path stroking to do some basic basic vector stuff, but that's about it.
Each has their place however.

Oh, and of course there is 3D canvas now, that's a whole different ballgame.

Answer: Discipline, Lists...

[theNAM666]

The obvious answer would be to only implement known-good solutions that work across all major browsers-- something that would be easily implemented by making a list.

Unfortunately, the "web development industry," which ranges from people who couldn't get hired by McDonalds and who are charging less hourly than McDonalds pays, to people charging upwards of $350/hr, is not exactly known for either discipline or standards.

Confusion? Challenge?

[BrooksMarlin]

It's is the same it's always been: you develop against the worst browser that has significant penetration. From 2001-2008 this was IE6 and you were stuck with it, now that IE6 has finally dropped below 5% (my arbitrary cutoff) I can simply ignore it, and get mad at IE7 instead. Chrome 6 vs 12? Firefox 3.6 vs 4? Who gives a shit! As long as the IEs lag so far behind everyone else, they are the roadblocks and causes of confusion in web development. Not the minor differences between the actual modern browsers.

Re:The AllBrowsers service

[rrossman2]

yup, thanks Chrome! :)

The fight goes on and on

[cdrguru]

The creators and maintainers of HTML and XHTML have said over and over that the language is a description of content and absolutely not in any manner a design for presentation. Presentation was to be left to the browser and the user.

Well, that lasted all of about five minutes. The first thing that came along was the use of white-space spacing graphics and tables to push things around so they looked consistent across varying screen widths - so that the 800x600 screen looked like the 1024x768 screen. To make the presentation customized as designed by the web developer (and whoever is paying them) and to have a consistent user experience. Not at all what the design of HTML is for.

So today we have web sites developed with the specific intent of circumventing the design of HTML and XHTML. Amazingly, these design hacks are not something that anyone really tests for in browser development - they are interested in developing something that meets the criteria of the design of HTML, not the intent of the web developer. In a few cases there are actually things that have been adopted into the browser design to make the web developer's life easier. Since these things are clearly non-standard and unique to a particular browser they make the web developer's life hell.

So where there were maybe 4 or 5 specific platforms to test against before, now there are far more. 15? 20? More?

The real solution is to have a web presentation language that does define presentation, which is what just about everyone really wants. Except for the maintainers of the HTML standard. Not only is the problem not going to get any better, by definition we have two groups moving in different directions. It is going to get a lot worse and probably at an expotential rate.

Re:The fight goes on and on

[surveyork]

+1

Re:The fight goes on and on

[Anonymous Coward]

Mod parent +Insightful

Re:The fight goes on and on

[Anonymous Coward]

The real solution is to have a web presentation language that does define presentation, which is what just about everyone really wants.

I am not a web developer, and this is the thing I have never understood. Why in the world do the web developers want a page to look consistent on all user agents? That's dumb. As a user, I just want your content: hypertext--text and hyperlinks. I don't care what color, width, or fonts you want stuff to be rendered in. That's my business.

All that matters to me is the information your website gives me, and what it allows me to do. Quit wasting so much of everyone's resources on what it looks like. I have the power to change that at my own whim anyway.

Re:The fight goes on and on

[0123456]

I am not a web developer, and this is the thing I have never understood. Why in the world do the web developers want a page to look consistent on all user agents? That's dumb. As a user, I just want your content: hypertext--text and hyperlinks. I don't care what color, width, or fonts you want stuff to be rendered in.

But then most web page designers would be out of a job. Someone has to decide whether the page should use 36-point Comic Sans or 12-point Times Vogon.

Re:The fight goes on and on

[AlXtreme]

1999 called, it wants its rant back. Where have you been this last decade?

Seriously, with CSS (W3C, not coincidently the same maintainers of HTML) we have that web presentation language and it works pretty well across all major browsers. If you want to give your users a 'consistent user experience', CSS will force it upon them.

Even with differences between CSS versions and DOM implementations we have it much easier than when frames, white 1px images, ActiveX hacks and tables were the way to do "web design". Those 'designed for IE' labels weren't for show: getting that consistent user experience was a beast for a single browser and nearly impossible across multiple browsers.

Nowadays we have 3 major rendering engines: Trident, Gecko and Webkit. You have differences between IE-versions that you should test for, but it's rare that a Firefox or Chrome/Safari update would ruin your site. Between CSS being the norm and having a number of great Javascript libraries to work with, web development is a breeze compared to the old days.

Now get off my lawn!

Re:The fight goes on and on

[Anonymous Coward]

The real solution is go back to 'desktop' applications. The only thing web apps simplify is installation. Applications can communicate over a network to get the data it needs from a server. Applications can auto-update themselves. If people stopped spending tons of time creating workarounds for all the problems web apps bring, we could have a nice OS independent (dependent would work too) updater that installed applications would register themselves on and it could let the user know of all possible updates instead of each application doing it slightly different (sort-of like Ubuntu's Software Center).

I keep being told that web apps and websites are write once run everywhere. Since when has that been the case? Desktop applications have three major platforms and work with later versions when designed correctly. Web apps have more than three browsers to target and different browsers versions may handle proper code in different ways. Desktop applications give you full GUI control and let you store user state. One could still have the application used user data back to a server so they could log-in to the application from any other computer it's installed on. Web apps are hacks on top of hacks to emulate desktop GUIs.

I think Java Web Start had the right idea. Why isn't it being expanded/improved upon?

Why don't people see this? Am I missing something?

Re:The fight goes on and on

[Fallingcow]

I am not a web developer, and this is the thing I have never understood. Why in the world do the web developers want a page to look consistent on all user agents? That's dumb. As a user, I just want your content: hypertext--text and hyperlinks. I don't care what color, width, or fonts you want stuff to be rendered in. That's my business.

As soon as you change human psychology so people don't stick around longer on and buy more widgets from pretty, precisely-designed pages with pervasive branding consistency right down to the font, maybe the marketing and graphic design folks will let us programmers write pages that all look the same.

Until then, you can just stick to reading RSS feeds.

Re:The fight goes on and on

[Anonymous Coward]

Web apps have a few important advantages past no installs. The most important one in my mind is that they are sandboxed by default. Running a random desktop app can do more or less arbitrarily bad things to your computer. A website has well-defined limitations in what it can do (of course, security bugs exist but you should not have to worry about them using an up-to-date browser). There is no risk in visiting a website.

Re:The fight goes on and on

[yuhong]

From what I read, it began with people taking up Mosaic in 1993 or so making HTML popular, but many of these people also designed webpages based on the display in Mosaic. <Hx> was abused to change font size, <DD>, <DL>, <BLOCKQUOTE>, and several other tags was abused for indentation, etc. It certainly didn't help that these tags looked cryptic to people unfamiliar with HTML. Then came Netscape introducing <CENTER>, <FONT>, etc. Netscape gained a monopoly effectively killing HTML 3.0 (that was in development as HTML+ since 1993). Then I think David Siegel invented using tables for layout and spacer images.

Re:The fight goes on and on

[yuhong]

Those 'designed for IE' labels weren't for show

I know, that was why Web Standards Project was created. What was interesting was that it took the creation of competition from IE for people to finally care enough about web standards to start this project.

Re:The fight goes on and on

[cbhacking]

Pretty sure the "web presentation language" you're asking for is called CSS. You may have heard of this language? One of those little features that helped IE4-6 win the browser war of the 90s? The preferred way to format and lay out content, and even do neat tricks like show and hide things dynamically, for over 10 years now? The language that allows you to explicitly define presentation in a way that all browsers on all computers are supposed to show identically, and if they don't, allows you to define a fallback?

OK, so the ideal of a universal implementation doesn't actually exist. This is too bad, though hardly surprising. The vast majority of the finalized spec, and much of the unfinalized stuff, is handled correctly by all modern browsers, though.

Re:The fight goes on and on

[Anonymous Coward]

The real solution is to have a web presentation language that does define presentation, which is what just about everyone really wants.

We have one! It's called CSS, and while page layout is a pain in the ass, once you get your stylesheets defined everything else suddenly becomes super easy.

Re:The fight goes on and on

[Anonymous Coward]

1999 called, it wants its rant back. Where have you been this last decade?

Browsing the web?

I still regularly come across sites that are way too wide to read in a maximized browser (on a widescreen display), and get horizontal scrollbars on a non-maximized browser. I'm sure there's some magic size in between somewhere, where the site looks as the designer intended, but I'm not going to drag around until I find the designed with on every single page.

The problem still exists, and CSS did not solve it. Quite the opposite, it made it gave a standard way to make crappy sites. (Not saying that CSS makes a crappy site, but it allows crappy designers to get what they want - crap).

Re:The fight goes on and on

[Anonymous Coward]

What annoys me is that creating a footer that plays nicely, ie stays at the bottom of the window unless the content is longer - still seems to need hacks.

Re:The fight goes on and on

[maxwell demon]

OTOH, with desktop apps, to compromise the app for an user you have to get into the user's computer. Compromising it for all users would mean getting into all user's computers. With web apps, you have only to attack one server to compromise all users.

Why, the same standards as always...

[Anonymous Coward]

Adobe Flash

Never ending

[Anonymous Coward]

http://www.youtube.com/watch?v=HNTxr2NJHa0

IE8 is dead

[Anonymous Coward]

IE8 is dead. If you develop for IE8 you're throwing away 75% of the functionality.
Unless your target audience is noobs, then HAHA.

Re:IE8 is dead

[Anonymous Coward]

PHBs are a special class of noobs. Ones who have control of a lot of paychecks. So, yes, the target audience is generally noobs.

Just a WebDev's opinion

[Anonymous Coward]

I see lots of people who are probably not employed as web dev's attempting to speak as such, I'm employed as one (I do more layout using CSS and heavy JS development [current codebase - all internal and can't be released - 1200 lines handwritten]).

Develop for IE7. That's your lowest. UNLESS you know that your crowd is going to be using better, such as Beta services usually attract users of Chrome and Firefox with iOS and Android coming in, then target those. If you include vendor prefixed, include all of them, even if it is a little bloated (Yes even -o and -ms). Polyfill what you can, and develop against standards and then change based on testing. So first make fully compliant, then test against IE7. Make sure it's what you want. Then check to see if you regressed anything. Regardless of what people say, DO NOT USE hacks, use Conditional statements for IE (stylesheets work best). Never write something that exploits bugs, that's asking for trouble. After IE7 is done, check IE 8 XP, IE8 Windows 7, IE9, Firefox stable, Chrome stable, and that's it. Opera is conformant (mainly) to Webkit, which Chrome stable will be a lower version, and is close enough to Safari that it's not worth the trouble.

That's how I write it, and I've NEVER had layout bugs. I keep 2 OS's (Windows XP and Windows 7) with 6+ browsers (Opera latest, Chrome Canary, Chrome Dev, Chrome Stable, Safari 5, IE7, IE9, Firefox Aurora, Firefox Stable, Lynx) so that I know I can recreate 90%+ of the problems.

Oh, and don't ignore accessibility. It's important to crawlers, screenreaders, and you in the future (if you need to munge the data).

Headline is completely backwards

[sco08y]

Should be:

"Rapid web copy-pasta challenges browser developers."

And the fact that the "standards" are little more than committee wishlists doesn't help much.

It's a conspiracy to keep us buying books ...

[WebManWalking]

... so that we'll never actually get rich.

Evolutionary Dead End.

[VortexCortex]

So -- We took SGML document language, then slapped on a shitty scripting language that successfully rode Java's coat-tails, on no other merit than "it's what's available". Then we tried to formalize everything, HTML5 got delayed (is still being delayed) for EIGHT YEARS...

All for what? What did we do with a stateless distributed document display system and a scripting language? Why we built stateful applications out of them.

We all booed and hissed at ActiveX and Java -- native code is insecure, no one has the right Java version installed, it's a slow VM! -- But now we take JavaScript and compile it into insecure native machine code, run it in a slow hybrid VM, and no two browsers have the all the same features, and visitors don't have a common version installed.

Meanwhile someone discovered that if you give the general public access to a software repository, and give coders a stable platform and channel to access customers via -- You can do the exact same bullshit as a web-app with less resources, and make it graphically slick too. (Of course fracturing is starting to happen again -- The old beast of platform diversity rares its head -- Google needs to step up and say: "If you don't give your users the updates after a set period, you can't access the Marketplace with new devices" [with an exemption for older hardware] ).

I'm no iFan, but this is what I've been saying since I wrote my first web app: "This sucks, it will eat itself alive with complexity as it gets popular".

Hey the "web" is neat -- But bending your code to support non-standard browser extensions has bit us in the ass -- Abandon ship, It's not worth the hassle to keep bailing at this point -- look over there, a good ol' fashion Repository... and it doesn't leak development time/money like a sieve...

Believe what you want. Yes, the web is too big to fail, but as long as we haven't learned that basic lesson -- Standards or Bust -- the platform (be it web or app) is doomed to be huge clumsy insecure zombie with an insatiable lust for mindshare, and development time.

Re:Evolutionary Dead End.

[shutdown -p now]

We all booed and hissed at ActiveX and Java -- native code is insecure, no one has the right Java version installed, it's a slow VM! -- But now we take JavaScript and compile it into insecure native machine code,

The difference between native code of an ActiveX control, and native code produced by JavaScript JIT-compilers, is that the latter comes from a language that is verifiably memory-safe - meaning you can actually sandbox it, with said sandbox being foolproof so long as your verifier is not buggy (but this holds for any implementation technique - even an AST interpreter can have bugs exploitable for arbitrary code execution).

Re:Evolutionary Dead End.

[arkenian]

So basically you're saying that the current situation on the internet amounts to a job security program for web developers. What I"m having difficulty understanding is where the problem is with this? Actually when I put it that way, it explains a lot....

Re:Evolutionary Dead End.

[lennier]

What did we do with a stateless distributed document display system and a scripting language? Why we built stateful applications out of them.

Yes, we did. And I'm very sad that we did, because at the core of HTTP's stateless REST architecture is a very neat half-formed idea struggling to get out, which we've been hell-bent on strangling at birth since 1989.

Facebook and Twitter should be teaching us something about what we're missing. The SGML document/element divide is mostly hugely unhelpful. What we generally want to publish is not huge consolidated 'documents' but the raw data objects themselves. We should have a distributed publishing infrastructure that lets us post arbitrary data objects like individual blog posts or tweets to persistent global addresses and let the fabric sort out the routing and presentation. Ideally we should also be able to publish side-effect free functions to the same publishing fabric, and then apply one part of the fabric to another part and republish that. And so on, indefinitely. Mix, remix and repost. It should be as simple to post 'hey, here's a new function/template for rendering blog posts' as the posts themselves.

What we'd end up with then is something a lot more like Ted Nelson's 'Xanadu' (minus his weird mathematical neologisms and patent walls). Of the currently available systems, Google's "Wave" experiment came very, very close to being something like this, but they lost interest.

Instead, we've got this baroque multi-tier architecture of HTML, DOM, JavaScript, PHP/Java, and divides between 'client' and 'server' which really don't make sense in a Facebook kind of world. The divide is great for those developing 'applications' who get to keep the 'users' on the other side and pay for access. But in real life, even the users often want to construct and share workflows and methods. The current multi-tier Web is one of the worst ways possible of doing that.

Re:Evolutionary Dead End.

[Anonymous Coward]

Nothing is stopping you from publishing raw objects over HTTP, although I guess your point is that a web browser is not designed to display such data in a way that is useful to the user without a server deciding how they go together in a document. That said, some REST APIs do throw around raw objects (as JSON or other formats).

The other, not necessarily separate, idea you have is, if I understand you correctly, to separate addressing from physical location, so URIs do not need to include where to get the information requested. I like that idea (see my sig), but implementing it is much harder than implementing HTTP. For one, the data still needs to live somewhere (well, on one or more machines). Now most people have always-on internet connections, so they could host their own data, but still a lot of people have laptops or simply turn off their desktops, so serving their own data is not feasible. Hence the reliance on servers.

The web, Javascript (with its various strange quirks) especially, is a good example of worse is better development: it's popular not because it is well-designed, but because it is simple. The openness of the web allows for a lot of creativity in how it is sued.

Re:Evolutionary Dead End.

[SanityInAnarchy]

shitty scripting language that successfully rode Java's coat-tails, on no other merit than "it's what's available".

I wonder if you actually know a single thing about JavaScript. No, it's not Java. It's better in pretty much every way I care about.

What did we do with a stateless distributed document display system and a scripting language? Why we built stateful applications out of them.

Go read about REST, first of all. The documents are the state.

But I'm not entirely sure I see your point. Having the UI be as stateless as possible -- it doesn't care how I got to this URL, only whether the resource is still valid -- and having concepts like idempotence built into your app at a deep level, go a long way towards robust applications, stateful or otherwise.

We all booed and hissed at ActiveX and Java -- native code is insecure,

If you really think that's the reason ActiveX and Java were despised...

ActiveX really was a security hazard, and not because of native code, but because it was insufficiently sandboxed. It was never designed to run arbitrary code from the Web, it was designed to make it easier to extend local applications. It was designed for things that you might recognize in browsers as plugins and extensions. It was not meant for every web developer who couldn't be bothered to learn JavaScript to write "web" apps in native, Windows-only code.

Oh, and it was Windows-only.

Java was despised because it was slow. That was pretty much it. Security risks? The JVM is actually pretty damned secure, assuming you don't just click anything through that asks for it. No, people hated Java because it would add ten seconds or more to page load time. This is a stigma that's stuck to Java, despite ridiculous performance improvements over the years. It's probably the biggest reason Flash started winning, though I'm not sure either one loads faster these days.

And the way in which Java is still slow? Boot time. That's pretty much it -- once you get a Java app running, it's plenty fast.

But now we take JavaScript and compile it into insecure native machine code,

Are you retarded? The native-ness is irrelevant to security. From the developer's perspective, JavaScript is every bit as much a scripting language as before, it just runs faster. That the VM might have some vulnerabilities is pretty much irrelevant -- interpreters have had vulnerabilities, also.

run it in a slow hybrid VM,

Slow? JavaScript is about the fastest dynamic language of any sort by now. It certainly doesn't have the problem Java did -- aside from not inheriting Java's brain-dead language design, JavaScript also boots pretty much instantly. Hell, the entire Chrome browser, JavaScript VM and all, starts about as fast from a cold boot as opening a new tab, which is faster than I could ever possibly want.

And what's your problem with VMs? It is an implementation detail, after all. Keep in mind -- JavaScript was interpreted. Now it's sometimes compiled all the way to native code.

Meanwhile someone discovered that if you give the general public access to a software repository, and give coders a stable platform and channel to access customers via -- You can do the exact same bullshit as a web-app with less resources, and make it graphically slick too.

Great! Say, could you point me to this magical repository where I can run graphically slick, lower-resource, cross-platform applications without installing them, which I can use on any computer on the fucking planet, with full access to all my stuff?

Never mind that the Web comes with at least a half-dozen features off the top of my head that not every app has, and that people find themselves re-implementing in native desktop apps because people miss them from browsers. Bookmarking. The Back button. Z

Re:Evolutionary Dead End.

[Anonymous Coward]

Right.
This is exactly why when the enthusiastic crop of users at my company rose in unison for "something we can open via Internet Explorer..." --- I quickly quelled any thought of webapp development but instead pushed for a uniform installation of Java Plugin through out the org to roll out applets.

The users still get their flashy interface and more -- but the code can now be controlled, shared amongst different projects, and utilizes a lot of infrastructure already in place. Trust me, I have tried web development and got sick of the immense structure I needed to maintain for brain-dead IE -- and forget about Javascript -- the whole language is just... messy. How do people even justify coding enterprise-level logic into it?

Until user agents save data entered in DHTML forms

[tepples]

Let me decide when to use a tab and when I want it to just be a back-button away!

Navigating away from a page and then navigating back with the back button tends to lose data entered into a form if the form is created with DHTML (manipulation of the HTML DOM by script). So until user agents* figure out how to preserve data in a DHTML-generated form, we're stuck with opening a document in target="_blank".

* The phrase "until user agents" appears often in the WCAG where it describes workarounds for deployed browsers' failure to implement proposed elements and attributes that improve accessibility.

Simple

[DogDude]

It's really simple. Pick a point in time in the past, and develop for that. With web browsers, I'd guess that aiming for standards (whether official or defacto) about 3 years ago should be usable for 99% of visitors. Trying to develop using features included in current browsers is nearly impossible.

morse code, the only programming language you need

[Eponymous Hero]

if you can't do it with a telegraph then you don't need to do it.

I give up!

[Anonymous Coward]

I lost my faith in web development, the internet, standards and life...
I'll go to the country to grow and orchard and some chickens.

Screw you all.

I'm glad I retired

[Anonymous Coward]

The rate of change in IT is too rapid for anyone to keep up with. Esp. us old coots. You young folks still in the game, your skills are practically outmoded
before you've had a chance to use them. You have my sympathy.

HTML5

[Lennie]

That is one of the many reasons why we have HTML5 now, so we don't need to do that.

Again: What standards?

[pavon]

Yeah, we should be writing standards compliant code. Nobody disagrees with that. However, all of the browsers only implement a subset of the standard, and if you implement an important feature using part of the standard that isn't well supported yet, then you fucked up. Last minute tweaking won't fix that; you have to completely redo the code using a different approach.

You need to know what subset of the standard to use before you start coding. This is arguably getting more difficult these days as W3C takes ages to release a standard and WHATWG has decided to abandoned released standards, and instead continually adding to a moving "standard".

The difficulties in trying to determine this subset is the point of the article.

Develop to the Standards!

[Anonymous Coward]

Develop against standards, not browsers. It's the way it always should have been. You may need to support a standard or two backwards in time, but write to one standard or another and if the browsers don't work with any modern standard correctly for some feature you require, you can blame the browser and get it fixed.

Separate content from presentation

[Ichijo]

To develop a web site "against" or "for" browsers is having lost the battle before you've even started it.

One way to avoid this is not to write content in HTML directly. Write in LaTeX or DocBook or a similar language that separates content from presentation, in order to insulate your content from changing HTML standards. Then have your script publish to the latest HTML standard. When the HTML standard changes, simply update the conversion tool.

Re:Separate content from presentation

[BBTaeKwonDo]

That would work great if this were 1995 and we were writing static HTML, but every web site since then has been dynamically generated. There's no LaTeX for "check if the username is already taken before submitting the form."

Re:Separate content from presentation

[Ichijo]

That would work great if this were 1995 and we were writing static HTML, but every web site since then has been dynamically generated.

Even dynamic web sites still use static HTML. I know this because I occasionally see HTML tags mistakenly displayed as text in articles on news sites.

Use Google Web Toolkit

[SplashMyBandit]

Google Web Toolkit (GWT) is pretty darn good at sorting out the browser dependencies for you. There are some pre-browser CSS tweaks you have to do for layout, but basically GWT is to the Web what the Java Virtual machine is to hardware - you just don't have to care about it. Plus, you write GWT in Java, which you already know and are using on your back-end Enterprise cluster. Take a look at GWT, if you are writing a significant part of your AJAX web application at the level of HTML5 and ECMAScript then you are doing the Web-equiavalent of writing assembly code (sometimes necessary, but can be avoided most of the time).

Here's the link to GWT if you haven't seen it before: http://code.google.com/webtoolkit/overview.html

Re:Use Google Web Toolkit

[Anonymous Coward]

Yes because everyone knows Java and writes Enterprise apps. Pfhtttt. Dumb ass.

Re:Use Google Web Toolkit

[Anonymous Coward]

This comment applies to about 0.01% of the web. Thanks.

Re:Use Google Web Toolkit

[trev.norris]

I haven't posted in a while, but this is wrong on so many levels. Let's start:

...basically GWT is to the Web what the Java Virtual machine is to hardware...

I guess maybe on some strange high level of abstraction this might be metaphorically applicable, but in reality it's completely wrong. I think you meant "GWT is to the browser," but still nope.

...you write GWT in Java, which you already know and are using on your back-end Enterprise cluster.

Wow. What a strangely strong assumption. I think what you said just before this is key, "...you just don't have to care about it." Guess when you have a hammer everything really does look like a nail. Java isn't the only solution available, and definitely not the best for everything (or nearly anything imho).

...if you are writing a significant part of your AJAX web application at the level of HTML5 and ECMAScript then you are doing the Web-equiavalent of writing assembly code...

Every time I read this my stomach turns over. First, did you overhear ECMAScript mentioned by a co-worker? It's the freakin' standard. Browsers use JavaScript, a specific ECMAScript implementation. That's like saying you know how to run your POSIX Operating System. Also, GWT does not compile from a complex language to a simple language, it compiles a complex language to an equally complex language (though for different reasons). People who can't program a complex website without the use of their beloved OOP is because they are unable to adapt to the web development workflow.

I've been doing this for 4 years and have helped launch significantly complex websites. None of these have needed an overly complex layer of gooey fluff to help complete a well designed product. GWT is nice for Java developers who don't know how to do web development, but never say that GWT can replace a well skilled web developer.

Re:Use Google Web Toolkit

[Anonymous Coward]

Plus, you write GWT in Java, which you already know and are using on your back-end Enterprise cluster.

Except, of course, for those of us who don't.

Re:Use Google Web Toolkit

[SplashMyBandit]

> People who can't program a complex website without the use of their beloved OOP is because they are unable to adapt to the web development workflow.

Whateverz. You know nothing about what I develop for, yet your four year 'experience' (which to me means you are still crawling in professional career development terms) you clearly think you know it all - and every web problem can be solved by resorting to Javascript. That's simply bollox!

The reason I suggest GWT is that Java is the most general purpose and widely used development language on the planet (at the moment). It is not the best language at any one particular thing but it can be used for just about everything (unlike sh!tty Javascript). You may not be aware but there are developers out there who aren't simple webmonkeys doing development for a mere four years (mate, I used to build stuff for Mosaic back in early part of the public web) and think they know it all. Some of us build very complex front-ends to very complex back ends (eg. one of my current clients requires me to to integrate multiple radar devices of differing types, mash the data in complex ways, and present a nice interactive front end). Can you do this integration all in Javascript? hell no! Can you do all this integration using only Java (with GWT as just another library)? hell yes! Furthermore, I choose Java not because it is most complex and it makes me feel 733t but instead because it is the *most simple* language that can be used anywhere (my PhD in Astrophysics makes me feel 733t, I don't feel the need to brag to others about all the development languages I know while suggesting Java is not l33t nor fashionable enough, and think crappy Javascript is better). Java's 'simplicity by design' pays off in terms of money and development time (since my customers aren't all running Windows or one browser, they are big and run a lot of everything) and on any big complex project there is never enough time (development time matters). So I find it laughable when someone thinks programming in Javascript is the shizzle for the web - you clearly have not done enough complex sites (all the way to the back end custom hardware integration) for huge enough customers to make a decent judgement. You clearly think people should waste their time hacking Javascript for each and every browser rather than solving the real business problems that matter to customers. People come to me asking to submit RFPs because I have a proven track record with Java/GWT and those tools are extremely agile with change, with the technologies I use I'm not a dime-a-dozen PHP and Javascript webmonkey hoping someone will give me a less than six figures job.

Incidentally, this is also the reason (if you care to look at the Tiobe Index for the figures) why there is so much Java development - its not cause the developers are stupid and have to choose a simple language because they can't cope - its because they are making smarter business decisions and leveraging the simple and fast pathway with extremely good tooling and libraries to improve productivity. It is a shame your stomach turns irrationally at the thought of Java since clearly you can't grok its considerable advantages from a business perspective. One day when you get to architect or manage big projects requiring large teams of developers you will certainly see the world differently. Good luck with your career.

Re:Use Google Web Toolkit

[olau]

You are exaggerating. Javascript is a nice little language and is actually standardized pretty well. What's not properly standardized is the DOM/browser API, that's why you find yourself a little utility library like jQuery with a really nice API.

Yes, you need to use multiple languages (unless you use Node.js). It has its upsides and downsides, just like GWT. One of the upsides is that it's easier to figure out what's going on since you're much closer to the DOM and the protocols.

Re:Use Google Web Toolkit

[Anonymous Coward]

I remember checking this out a few years back, but I hadn't actually struggled my way through piping data back and forth between JS and PHP to make something approaching an "App" at that stage, so the advantages didn't push any buttons then, I was still making crappy "database driven online galleries" and the like.

But NOW, after the PAIN of trying to debug my dodgy JS efforts on various browsers, switching to and from bits of Perl to parse external XML from an API then send JSON to the browser, this thing sounds quite amazing.

I haven't studied Java though, so I guess that would be a good first step... surely it can't melt my brain as much as trying to chain 5 functions of various looped ajax calls to happen in order did last night... christ it just made something not break slightly for a few map markers some of the time, so much pain for some invisible gain...

Re:Use Google Web Toolkit

[Anonymous Coward]

I concur that Javascript isn't always where progress seems to choke during my web app development efforts, but the sheer number of balls I need to get into the air just to achieve seemingly trivial stuff, it's almost depressing sometimes! Having watched some pretty talented solo C++ developers churn out rapid prototypes of impressive mac applications overnight (full custom GUIs, not jammed out from prefabbed parts), it just seems like I'm some kind of country bumpkin with a cart of turnips for market, getting passed by Ferraris the whole way. Web delivered apps seem like a no-brainer for me to focus on developing, plenty of scope across many platforms, but simply - any advantage I can see to close the gap between how much I can get done in a day compared to a desktop app developer, I'm going to check out.

plus, if I never have to fire up vmware to test some horrible bug in IE again, I will breathe a sigh of relief.

Re:Use Google Web Toolkit

[trev.norris]

...you clearly think you know it all - and every web problem can be solved by resorting to Javascript.

Once again with your overly general comments, and in this case I can't fathom what you mean by "every web problem." JavaScript is a language that the browsers use, and it's quite possible to understand it well enough to handle a website of any complexity.

One day when you get to architect or manage big projects requiring large teams of developers you will certainly see the world differently. Good luck with your career.

So I guess currently being in charge of Configuration Management and Development Workflow for the upcoming store launches of Toy'R'Us, Timberland, RadioShack and other GSI Commerce clients doesn't count? We're using Java on the back-end, and it's sufficient, but hardly necessary on the client-side with a well experienced team of developers. The 4 years experience I mentioned was of a very specific scope.

Re:Use Google Web Toolkit

[SplashMyBandit]

So you're a Configuration Manager rather than a web dev? So you don't actually get your hands dirty with the nuts and bolts Javascript development? So you think that 'raw' Javascript tweaked for each current browser will be easy to maintain on those sites a decade from now, rather than insulating yourself from the browser? This seems to be what you were advocating instead of insulating yourself through an excellent library like GWT that Google's horde of engineers maintain. I'm interested to hear how you think using straight Javascript route eases the maintenance aspect of these sites (this is not intended to be sarcastic, I'm genuinely interested in your thoughts here, in case there is some aspect I have missed).

language target

[Anonymous Coward]

HTML 4.01 Strict, it's the highest spec supported by the generic builds of k-meleon from browserchoice.eu (it uses the FF2 engine)
all the other browsers are either wrappers for IE (and so get upgraded with IE) or use the chrome engine and support HTML5

when k-meleon upgrades it's engine, then you can support html5

Call it flamebait if you will...

[Cryacin]

But consider Flex. 4.5 is compatible with all browsers, Desktop Installs with AIR, iOS, Android and Blackberry. This whole "code for every platform" rubbish, and an app for iOS, an app for Android, an app for blackberry et al is all just silliness.

At the end of the day, you have a finite amount of time/budget that can either be spread over 5 different market segments, or one single codebase. So yes, crap all over Flash/Flex if you want. At the end of the day, if you are a serious developer interested in developing useful and profitable applications, you simply can't rewrite and maintain your codebase over many different and often mutualy exclusive code domains, over several different languages.

Re:Call it flamebait if you will...

[mrrudge]

I agree. Especially when those code domains are evolving comparatively rapidly. It makes the business of making and selling websites much harder as there's no one technology which is both multimedia capable and available across all platforms. ( Flash + specialist iOS html is my current best for minimum number of versions for multimedia web delivery ). It makes choosing a speciality as a developer difficult which surely results in less specialists.

I have doubts at this stage that html5/js is the one size fits all future solution. It's fragmented before reference implementation and it's best features are unavailable on some browsers ( WebGL on IE, Etc. ).

I also have doubt that Adobe will release a sleek and secure Flash player. Though we've yet to see fallout from html/js implementation security lapses, ( http://www.us-cert.gov/current > WebGL ). We've yet to see the rise of annoying html adverts which use core browser functionality and so aren't easily disabled. Flash may yet not be the greater evil. ( Keeping multimedia in a plugin works for me. )

I wouldn't put it past Apple to sell 'Now with Flash !' at a later date either.

I want accelerated 3d to everyone who accesses it with a modern browser, I'll happily deal with differing workload per device. Currently it's not only impossible, but there is no clear way to see it happening.

Re:morse code, the only programming language you n

[syousef]

if you can't do it with a telegraph then you don't need to do it.

You just can't do it period! It can't be done!

Browsershots

[aywang31]

Try http://browsershots.org/ It's not going to help with testing functionality, but it'll definitely help with layout.

Re:Until user agents save data entered in DHTML fo

[MobileTatsu-NJG]

Is that why a site like the Digg makes you click a link that opens a new window? (Example.) That's usually where I get annoyed by it. I have to right click and hit 'open' to get it to stay in the same tab. Lots of forums do that, too. I don't feel like this is due to a technical reason, it feels like they want their page to stay up longer.

Use what works...

[Anonymous Coward]

A good reference is http://caniuse.com/

Shit Can the Browser...

[sycodon]

...at least for corporate online sites.

Too much time is wasted jerking off to the restrictions of the browser model. Code all over the fucking place...javascript here, server code there. Sessions variables that aren't available because...excuuuuse me, I'm in the wrong code block. Is it full Postback or a partial Postback? Do you really need a fucking library of books that constitute an entire zoo? Perl, Python, Ruby, PHP, Java, .NET, C#, C++, C++++, VB.net, F#, FU! Ajax, SOAP, Object not set to an instance of an object...which fucking object God Dammit!

AAAAHHHHHH!!!!!!

This wheel has been reinvented so many times the development world is like a huge used tire depot. More often that not, it's on fire.

Re:Until user agents save data in DHTML forms

[smellotron]

Navigating away from a page and then navigating back with the back button tends to lose data entered into a form if the form is created with DHTML (manipulation of the HTML DOM by script).

I'm sure there are a number of reasons why generating a form completely on the client side is the best solution. However, I'm equally sure that there are many situations where that form generation could be done on the server side with no client-side scripting (or at most css display tweaks to hide precomputed dynamic fields). Given the history of the WWW, I'm willing to bet that most developers are erring on the side of too much "ooh shiny" and not enough "it just fscking works".

Chill out

[Art3x]

This story is overwrought. I'm a web developer who maintains about 40 apps on our Intranet, and I have always tried to make them work in IE, Firefox, Safari, Opera, and now Chrome. But really it boils down to making them work in both IE and non-IE browsers. First I try to make it work in Firefox, and I find that it then also works without modification in Opera, Safari, and Chrome. That was the easy part. Then I try to make it work in IE, which involves various patches, and hand-wringing.

I haven't yet developed against it, but I hear that IE 9 has finally become enough like the rest that maybe the angst will end. Indeed, the browsers are overall converging, not diverging. Really, this is the happiest time in 10 years of web development.

And as for HTML 5? Well, yeah, it's still in development, and different browsers support different parts of it. But it's not like the CSS or DOM nightmare of the past, where different browsers --- I mean, IE, implemented the standard differently. But yes, if you want to make a web site that uses all the latest features like Canvas, Audio, and offline storage, then yes you might have a hard time for a couple years.

forget about browser ?

[Anonymous Coward]

The more browsers, the more problems.
On mobile devices the solution is now trivial : forget about it, develop a dedicated "app".

This is probably (and sadly) the direction things should go for applications that require to work. (I think about in-entreprises applications, not public websites).

Ever wondered why flash was so successfull ?

Its client expectations that kill...

[SuperCharlie]

With browser versions rolling out like donkey-kong barrels, and a pretty good number of very stylized websites to look after, we spend a pretty good amount of time fielding calls about why x website looks different in y and z browser.. the general client doesnt realize that it looked fine in every available major browser 6 months ago, they **expect** it to be the same in all versions **forever**. This is my headache and it doesnt get better with standards..especially "living" ones..

Rapid Browser Development Challenges Sysadmins

[dolmen.fr]

The major issue of faster browser version cycle is for sysadmin.
And this is a good thing.

Sysadmins and organisation must understand that a web browser is not a software that you can keep at the same version for 5 years (IE6). This software is the door to the external world and must be updated regularly to adapt to the changes in the external world. Organizations and sysadmins must adapt their software deployment process to the product developement cyle. The fact that the media talk about it will hopefully help the executives to understand that.

Once organization will have adapted their software deployment process for desktop to reflect that change, we, as web developers, will have less problems with legacy browsers.

Re:Rapid Browser Development Challenges Sysadmins

[Anonymous Coward]

Unfortunately, management does not realise that they must allocate extra funds appropriately so the sysadmin can match the changes in browser development.
Most businesses do not allocate funds unless they see a profit to do so. HTML5 has to offer some serious *profit* reasons for businesses to pull their websites out of the stone ages.

Re:Rapid Browser Development Challenges Sysadmins

[dolmen.fr]

In the case of legacy internal applications (intranets) which are often the cause of usage of legacy browsers, profit is usually mesured by increased productivity for workers and reduced frustration.

OK, I'll say it once more

[Anonymous Coward]

Develop against the standard, not any browser versions. Provide fallbacks or shims ("polyfills") for browsers that don't implement the full standard.

What is the standard? It's not hard to find out. There is a globally recognized standards body for HTML and related technologies. No, that would not be WHATWG.
What you linked to as HTML5 is not HTML5. It doesn't even call itself HTML5 any more. HTML5 has just entered Last Call, so most of it is stable now.

The browser is no place for an application...

[Anonymous Coward]

HTML was never intended to be an application language...

GWT is good but too slow...

If you are building web pages it won't matter - just use HTML 3.2 etc...

If your building a real world application use Silverlight, Flash (etc), i.e. a proper development tool...

Re:The browser is no place for an application...

[olau]

Maybe it wasn't, but it certainly has become.

Sorry, that's the truth.

Take a threaded forum as an example

[tepples]

However, I'm equally sure that there are many situations where that form generation could be done on the server side with no client-side scripting

A "Reply to This" link that navigates to a new document, like under Slashdot's old discussion system, would take the user away from the context of the discussion in order to post a new comment.

(or at most css display tweaks to hide precomputed dynamic fields).

On a Slashdot discussion, would you really want 50 different "Reply to This" forms to get loaded with each press of the "Get More Comments" button, all hidden with display:none until the user activates the "Reply to This" element above them?

Re:Take a threaded forum as an example

[smellotron]

On a Slashdot discussion, would you really want 50 different "Reply to This" forms to get loaded with each press of the "Get More Comments" button, all hidden with display:none until the user activates the "Reply to This" element above them?

I'm not sure why you're giving me an example of a situation where static forms are silly, as I had already indicated that sometimes they do have their place. However, my personal opinion on the matter of the Slashdot discussion system and forms is this:

• I always open "Reply to This" in a new tab, to avoid losing my place in the existing thread. It's a mental context switch, so the physical switch of having two pages loaded at once makes sense to me.
• Nothing is stopping /. developers from dynamically generating an iframe instead of a local DOM structure. From the browser's perspective, it's a separate page and gets its own form caching and whatnot, but from the user's perspective it can be seamless. I've been away from the tech for a few years, I don't know if <iframe> is still demonized or not.
• Putting "Reply To This" on a separate page-load adds a little bit of resistance to knee-jerk comments, which I consider a good thing. Of course there is a balance with how much effort you want to ask a user to go through for posting, but I just don't see a big benefit to inline replies for a serious discussion. Maybe someone has done some research on whether this is a real effect or if it's just "common sense gone wrong", but I'll stay conservative on this side for the discussion system.
• Overall, /.'s discussion UI has gotten worse for me over time (poor use of whitespace, unnatural behavior with back/forward buttons, inconsistent and unintuitive preferences). It's also obvious from my mobile phone that their design is not very "friendly" to alternate UAs. I don't exactly view them as a shining example for user experience or appropriate client-side scripting in the first place.

IE6

[sam0737]

Honestly! I work for mainland chinese clients, and all their desktops are XP + IE6, and Servers are 2003.

Browsers = Regression

[Anonymous Coward]

It is ironic to me that we have largely abandoned fast, compiled code in favor of slow, barely standardized multiple, largely incompatible browser technologies all in their infancy, running as script on the client machine when we have had the same technology just becoming available in browsers(although at a slow, buggy clip) available in fast, compiled code for 15 years. Case in point: HTML5 Canvas tag. Wow now we can code slow sprites in javascript! Welcome to 1990!