Rapid Browser Development Challenges Web Developers 221
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?"
HTML 3.2 (Score:4, Funny)
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 (Score:4, Funny)
Re: (Score:3)
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: (Score:2)
Not if you want translucent PNGs for a background.
Call it flamebait if you will... (Score:2)
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 d
Re: (Score:2)
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!
Re: (Score:3)
You don't have to remember: http://caniuse.com/ [caniuse.com]
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
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: (Score:2)
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 brows
Re: (Score:3)
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
why, standards, of course (Score:5, Insightful)
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: (Score:2)
Hit standards, miss the market (Score:3, Informative)
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 (Score:5, Funny)
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: (Score: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
Re: (Score:3)
Oh dear, please tell me that "no rounded borders on a non-public form" was never an actual deal-breaker.
Re: (Score:2)
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 set
Re: (Score:2)
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 lik
Re:why, standards, of course (Score:5, Insightful)
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: (Score:2)
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: (Score:3, Funny)
protect you against allot of Virus & Malware treats.
Mmmmm tasty Malware Treats. Get yours now!
HTML5 (Score:2)
That is one of the many reasons why we have HTML5 now, so we don't need to do that.
And the standard is.... (Score:2, Informative)
....IE 6!
Re: (Score:3)
Re:why, standards, of course (Score:5, Insightful)
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: (Score:3)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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 ev
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 [anybrowser.org] is not well understood or practiced by the average web developer in my eyes.
Re:why, standards, of course (Score:5, Insightful)
Re:why, standards, of course (Score:5, Insightful)
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.
Again: What standards? (Score:2, Insightful)
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
Re: (Score:3)
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: (Score:2)
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: (Score:3)
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?
Separate content from presentation (Score:2)
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 [wikipedia.org], 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: (Score:2)
Re: (Score:2)
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.
Testing (Score:4, Interesting)
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: (Score:3)
You could always put up a "This site is best viewed in ..." button, for that touch of 90s nostalgia.
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:3)
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: (Score:2)
It's more the leap from ie7 -9 that's starting to get me, along with firefox. And mobile testing, bah.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
Flash (Score:2)
Re: (Score:2)
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: (Score:3)
Nope, I have an Android phone :)
IE6 (Score:4, Insightful)
with flash if you want to be fancy.
Re: (Score:2)
It pains me that people still mark comments like that as Insightful. Look up Sencha/ExtJS [sencha.com] 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 [sencha.com]. That could change with support for canvas, but one of the advantages of ExtJS 4 is that it works in IE6. Granted, like a
This is why (Score:2)
Wait until 2014. (Score:2, Insightful)
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.
This article is confused (Score:5, Informative)
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: (Score:3)
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: (Score:2)
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: (Score:2)
That is generally true but sometimes you could do it either way and get better performance with canvas.
Answer: Discipline, Lists... (Score:2)
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.
The fight goes on and on (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
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".
Re: (Score:2)
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: (Score:2)
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 killi
Re: (Score:2)
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 f
Re: (Score:2)
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: (Score:2)
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
Headline is completely backwards (Score:2)
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 ... (Score:2)
Evolutionary Dead End. (Score:4, Interesting)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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 infrast
Use Google Web Toolkit (Score:3)
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 [google.com]
Re: (Score:2)
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
Re: (Score:2)
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
Browsershots (Score:2)
Shit Can the Browser... (Score:3, Insightful)
...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.
Chill out (Score:2)
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 develo
Its client expectations that kill... (Score:2)
Rapid Browser Development Challenges Sysadmins (Score:2)
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 h
Re:The AllBrowsers service (Score:5, Insightful)
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: (Score:2)
Goatse link.
Re: (Score:2)
yup, thanks Chrome! :)
Re: (Score:2)
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 wit
Re: (Score:2)
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 brow
Until user agents save data entered in DHTML forms (Score:3)
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 acce
Re: (Score:2)
Is that why a site like the Digg makes you click a link that opens a new window? (Example. [digg.com]) 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.
Re:Until user agents save data in DHTML forms (Score:2)
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 fi
Re: (Score:3)
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: (Score:2)