the user can simply dissallow CSS allowing flying elements
Just put
* { position: static !important; }
in a user stylesheet. And then realise that there are lots of sites that use this legitimately, and take it back out again.
the web-page being permitted to do its thing within certain boundaries (boundaries that the user is in control of).
The crux of the matter is that dynamically positioning things on screen is not a reliable indicator that something is an advert, and that restricting pages from doing so will stop many legitimate things from being possible.
As far as I know, nobody has come up with a way to identify these things reliably. CSS "flying elements", as you call them, encompass a whole range of different things, only one of which is advertising.
The solution is to not allow layered content like that to cover up the page in the actual browser core.
That's not feasible. You're forgetting that they are part of the page - not some external thing that is easy to identify. Furthermore, the idea of positioning something on the page is a legitimate one, and is used all the time - e.g. for drop-down menus.
Unfortunately, advertisers are beginning to experiment with techniques that make it far harder to differentiate between adverts and content automatically - unrequested window.open()s are dead simple in comparison to trying to decide if every positioned element on the page is an advert or not.
Well, at least that's what makes GMail, et. al. different/innovative.
What makes GMail etc innovative? I've just finished explaining that these techniques have been in use for years. For instance, here's a story on Kuro5hinfrom 2002 that mentions a dynamic threading mode that can be used to display new information from the server without reloading the page.
But the browser wars/innovation have been over for 5 years. They decided to focus on usability and leave the non-compliant browsers at the station.
This isn't about "non-compliant browsers". Catering to browsers with different capabilities without resorting to highest common factor design is something web developers do all the time. It's not something that went out when people stopped supporting "both" browsers, and it's certainly not some kind of Netscape 4.x legacy. It's a general principle that the web relies on, and is unrelated to usability - apart from the fact that it is a method that avoids breaking things completely for some people.
The marketplace apparently approves.
I hope you aren't trying to imply that this means they are writing high quality code.
Today there are basically 3 categories of browsers: lynx, modern, and old-and-busted.
That's a ridiculous, superficial analysis. There are many ways in which user-agents can differ, and they can be quite independent. For instance, only the very latest betas of (modern) Opera support XMLHttpRequest, somebody might switch off images if they are surfing on their (modern) laptop over their (modern) mobile phone, or a business might follow (modern) CERT's advice and disable client-side scripting on their employee's (modern) browsers.
If you can measure an appreciable productivity increase for a good UI, how much of that is worth sacrificing for lynx? Graceful degradation may have outlived its usefulness.
Jesus H. Christ on a skateboard! You are replying to a comment that explains what graceful degradation is. How about you try reading it. It does not entail sacrificing any functionality whatsoever, for Lynx or any other browser. Sacrificing functionality is mutually incompatible with graceful degradation, so I fail to see how you could possibly confuse them.
What is your take on people that use the html generation tools (such as Netscape Composer)?
WYSIWYG is a myth on the web. Or rather, what you see is pretty unimportant. Rendering can, will and should differ depending upon the individual circumstances of the person visiting a website.
When you pay somebody to develop a website, you aren't paying them to draw you a picture that happens to have text in. The web is not like print media, it's fluid. What you are paying them for is a set of pages that adapt to the circumstances under which they are viewed.
WYSIWYG tools such as Netscape Composer are not very good for this purpose. They give a decent impression when all you do is type out a few pages and look at them on your computer, but to get results that are suitable for professional use, there really isn't any substitute for coding by hand.
Of course, many professionals code the front-end by hand, and use a CMS with a nice GUI on the back-end to make things simple for their clients. This is a good thing; hand-coded websites aren't better because they are harder to create, they are better because the HTML, CSS, Javascript, etc has been crafted to work appropriately - something an automated tool simply cannot do. Pouring content - that may have been entered by a nice GUI interface - into a hand-written "mould" like this is good practice.
So GUI tools aren't intrinsically bad, so long as they are simply the means by which you enter content into a high-quality front-end. The trouble is, many tools, including Netscape Composer, don't distinguish between the two tasks and also create the front-end for you - something they are unable to do effectively.
In terms of how much credence I'd give, it's roughly this order (best first):
Developers that have developed their own CMS specifically for the task at hand.
Developers that use an off-the-shelf CMS with templates they hand-coded.
Developers that hand-code.
Developers that use an off-the-shelf CMS.
Developers who use "WYSIWYG" tools to manipulate pages using templates that they hand-coded.
Developers whose websites are generated through "WYSIWYG" tools.
Most organisations will get the best quality:price ratio by hiring people somewhere in the middle - anything more is often overkill.
Also, what about companies that end up supporting a site that was written partially/entirely with what I would call sub-standard tools? It is almost never in the budget to re-write an entire site.
This is quite common, yes. One situation that is sadly very frequent is when a professional firm takes over something the manager's nephew did, or something that is otherwise awful but that they spent a lot of money on.
I know I've been trapped in the situation of maintaining hideous messes until the client can afford a redesign, when the only reason they can't afford a redesign is because they got ripped off by somebody who didn't know what they were doing.
Depending on the size of the website in question, it's sometimes quicker to simply start over from scratch. If the people who originally developed the site didn't know what they were doing, chances are, reorganising all the information is badly needed anyway.
I would guess a common response to a request to rewrite would be 'It works, doesn't it?'
In some cases a poor website can directly lead to business risk. For instance, a website that doesn't follow the W3C specifications is more likely to break when a new version of a browser is released. This is a historic trend with concrete examples that goes back to
If developers _did_ use both, I wouldn't be as annoyed with Javascript
If people abuse Javascript in the manner you describe, then by all means criticise them for it. But don't lump those incompetents in with the people who use Javascript - including remote scripting, or "AJAX" - appropriately.
but the "AJAX Engine" isn't going to always be small, either, and somehow I doubt you're being totally honest ( even to yourself ) by describing that layer in terms of a single XMLHttpRequest call...
Again, there is no such thing as an "AJAX engine" on websites any more than there is a "web engine" on websites or a "DHTML engine" on websites.
If you want to do lots of complicated things, then yes, there will be a lot of code. If you want to do small, simple things, then no, it won't be a lot of code. Remote scripting/AJAX is a technique that can be used in both situations. And like I said, you can use this technique effectively in a few lines of code.
People have linked to tutorials in these comments, I suggest that you at least skim them before complaining about it.
check out the script on Google Maps... maybe you have a different idea of what a 'small' javascript is than I do
I wouldn't call Google Maps small. Google maps needs a lot of code because it does a lot of stuff. This isn't anything to do with remote scripting or Javascript, it's simply how programming works. You want to write an application that does a lot of things - you write a lot of code.
Saying that remote scripting needs lots of code to work because you have a negative impression of Google Maps is like saying that C programs need millions of lines of code because you saw the source to Windows.
Websites that require certain browsers/OS combinations, when they don't need to do so, didn't I make that clear ?
But remote scripting requires no such thing!
You mean you just responded with all that because I characterized the "Ajax Engine" as a large Javascript?
I responded because you described a fairly useful technique in a completely unreasonable way without being the least bit familiar with it or even reading the article. You went on to state that "they won't work right" and said that since it requires communication with the server it was useless anyway!
Not only was it completely misleading to anybody unfamiliar with the technique, it was also pretty annoying when plenty of people have developed things with this technique that aren't incompatible or bloated, and are being described as such by you.
Yes, I agree, there are a lot of cases where Javascript is used in an inappropriate manner. It annoys me too. But you can write crap code in any language, and it's simply ignorant to criticise this technique because some people don't know how to apply it well.
I think you might be right (and I know what XMLHttpRequest is, thanks:) ). I was basing my statement on knowledge of an earlier draft. It appears that although it's implemented in the browsers I mentioned, it was taken out of the DOM3LS specification before final publication. I'm not sure if another specification covers this or if I'm missing the bit of the specification that refers to this, I'll have to investigate further.
Why, is this "Ajax Engine" script a tiny little thing?
So let me get this straight - you've characterised it as "an ungodly big JavaScript to pass XML between the server and client", and yet you haven't read or understood the article at all?
There is no "AJAX engine". It's a term used to describe a particular combination of technologies. Like the way we call HTTP+HTML+etc "the web" instead of calling it "HTTP+HTML+etc" all the time.
The core component that has been getting a lot of attention lately is the XMLHttpRequest object. You can pull XML documents over the network with a few lines of code. Your claim that it requires massive amounts of code is ridiculous.
Hey, sorry... clearly Javascript is a favorite technology of yours or something
Where did you get that idea? It's a tool, I use it where it's appropriate. I replied to you because what you were saying was completely misleading, not because I like Javascript.
although looking at where XMLHttpRequest comes in sheds some light on it's _clear_ browser-dependence, which is _exactly_ what I have a problem with.
Browser dependence? It works on Internet Explorer, Gecko, KHTML and the latest Opera betas. Including all the browsers using those engines, that's dozens of browsers it works in. So exactly what is your problem?
But like I said, if you _want_ to tie your web page to a particular class of browser, go ahead.
What does that have to do with XMLHttpRequest? I explicitly mentioned graceful degradation. You do know what that is, don't you?
I only dislike it's use when it locks alternative browsers out of content without good reason- which is, in my experience, all too often the case.
Then criticise the people that write that code. It's not something intrinsic to Javascript or XMLHttpRequest. Like I said, they can be used while remaining perfectly compatible with alternative browsers.
Yes, and, for browsers that don't support XMLHttpRequest, you can put a "get new messages" button on the page. Is that too much to ask ?
Of course not. But you are describing it as if developers have to choose between the two options. They can use both - offering automatic notifications for browsers that have XMLHttpRequest, and letting people using other browsers click the button manually.
On innovation: Google's use of "ajax" (if we must use that name) is novel (and hence an innovation) because it strings together a number of existing technologies to greatly increase the usability of their offering.
Which existing technologies? Google's use of remote scripting (that's the name it's had for years, I don't see the need to change it) uses HTML, CSS, Javascript and XMLHttpRequest.
Given that XMLHttpRequest has been used in relation to these technologies for just under six years, and that before that, invisible inline frames were used to do similar things, I fail to see how this is a novel combination of technologies. In fact it's hard to conceive of a use of XMLHttpRequest that didn't use these technologies.
GMail is the most complex example of it I have seen. GMail is the most popular example of it I have seen. But "complex and popular" does not mean "innovative" unless you are looking in a Microsoft dictionary.
First, "Ajax" would be impossible to pull off in Netscape 4.x or a text browser. Netscape is too broken, and Ajax is a GUI technology. So asking for graceful degradation in this context is asking too much.
Please go back and read what I wrote. I know this is impossible in those browsers. That's the whole basis for graceful degradation.
It is certainly possible to build a webmail application that works in Lynx and Netscape 4. It won't be very fancy, but it will work.
You can make it much more user-friendly for more advanced browsers in one of two ways.
Do it the Google way, and construct a Javascript behemoth that fails to function at all in browsers that don't support every feature Google wants.
Do it so that it degrades gracefully, so if a browser doesn't happen to have all the features you use, it falls back to less onerous requirements.
Quite frankly, I'm surprised that Google don't understand this better. If pages didn't degrade gracefully, the Google search engine itself would not be possible.
I should also note that we don't have to go back to browsers like Netscape 4 and Lynx when talking about this stuff - the latest releases of Konqueror, Opera and Safari have all had problems dealing with the GMail code.
That simply gives me a headache. Why does a Scalable Vector Graphics file format need support for NETWORKING? SVG can already be manipulated via the DOM. The DOM already includes features to load resources over the network. The same thing in SVG is simply redundant.
No wonder it's taking so long to implement SVG in browsers if this is the kind of thing they are sticking in the specs.
Or should I stick to using CSS/HTML + PHP and regular server-side coding, and then move to AJAX in version 2.0?
This isn't an either/or technology. AJAX depends upon Javascript and particular objects/features of particular implementations. It's nice (and useful) to have it mostly work in the most popular browsers, but it's not something that should be relied upon.
Build your application with CSS/HTML + PHP. Then, when you get around to it, add remote scripting as an optional enhancement. If the objects are available on the client, use them, otherwise fall back to submitting forms in the traditional manner.
Yeah, cause no one should be doing anything remotely new that niche browsers or browsers from 10 years ago can't handle.
"Graceful degradation" means that when you do do something new that some browsers can't handle, it's constructed in such a way that those browsers still get something that works.
Criticising graceful degradation as being an attitude of avoiding new, incompatible stuff is ignorant, since if you weren't doing new, incompatible stuff, graceful degradation wouldn't even apply.
What's described is "write an ungodly big JavaScript to pass XML between the server and client".
What? XMLHttpRequest can grab an XML document in a few lines of code. What makes you think you need to "write an ungodly big JavaScript"?
Then, they won't work right unless I use the browser you developed it on... yea, Google maps, that's great, it works with all the Javascript-supporting browsers out there, right ?
Feel free to single Google out for screwing up compatibility, but it's a shortcoming of Google, not something intrinsic to Javascript. Javascript can easily be used to enhance the UI for a web application, while gracefully degrading for clients that can't handle it.
Besides that, what really gets me is- hey, you're going to wait for some server process at some point anyway, right? What's your glorified Javascript doing besides displaying a "Waiting for server..." dialog anyway?
You really haven't paused to look at what's possible. For example, a webmail application can periodically poll the server for new events such as new mail without interrupting what the user is doing with a page reload. Yes, obviously the client still has to communicate with the server, but that doesn't mean it isn't an improvement.
The cynic in me says that this guy took a good look at Google's innovation and gave it a name:
Google's innovation? This technology has been around for years. Google are merely the first high-profile organisation to require it for public web applications. And requiring it is bad, the concept of "graceful degradation" is sadly lost on Google.
Disclaimer: I'm a web developer, and I don't always do things this way myself. They are rules of thumb, not laws that must be followed.
The most important thing to bear in mind is that you need to know what it is you want to achieve with the website. Some firms are all too happy to sell you an all-singing, all-dancing e-commerce haven (and charge appropriately), when all you actually need is a contact form, address and phone number on a single page.
Business stuff:
Use a contract. This is for your protection and theirs. If they don't use contracts, the chances of them getting sucked into a legal battle with one of their other clients rises. It also outlines exactly what you expect from each other in clear terms, which is, amazingly, an overlooked step in building a site a lot of the time.
Get concrete deliverables. Example deliverables:
A systems requirement document detailing exactly what it is you need.
A mock-up of a couple of pages to see how they look.
A demo version that doesn't work in all browsers.
A beta version that is supposed to do everything.
Final version.
These deliverables will be missed a couple of times. The important thing is that your contract states what constitutes acceptable quality and how slips will be resolved - if they lose money every time they miss a date or forget a feature, they'll keep to schedule and not rush things out the door.
Every time you pay them, get the copyright for the work they have done so far signed over. If they start acting badly, you need to be able to take the work elsewhere instead of being forced to either put up with them or writing off the current investment.
In a similar vein, make sure that the code they write isn't dependent upon any in-house tools. If you get your code off them, but it is built on top of their proprietary shopping cart API (for example), it's useless.
As everybody else said, talk to a few of their clients.
There are a few signs to watch out for from people selling snake-oil.
Unlimited bandwidth or disk space. The truth is, there are limits, and you won't know about them until they decide you're using too many resources.
Guaranteed search engine placement. They can't do that. Additionally, ask them if they can guarantee stuff like this, how come they aren't #1 in Google for "web design"?
"Meta tags". Virtually no search engine has used these in the past decade, so if they tell you they'll add them to each page, they are working with very obsolete information.
The human touch. Visit their offices a couple of times.
Do people seem relaxed?
Is it some guy in his parents' basement?
Is it the same people both times?
Technology:
Validate their HTML. If they have no errors, that's a good sign. If they have one or two errors, ask them about it. If they have dozens or hundreds of errors, stay away, they don't have any Q.A.
Validate their CSS. If they don't use it, stay away, they are using 90s technology in the year 2005. If they have a couple of errors, ask them about it.
Look through the validator output to see if they have any lines starting with width and ending in px; (percentages etc are fine). If any of them are setting anything to a width greater than 200px, it's a sign that they use fixed width layouts. This is a negative sign, but not the end of the world. Ask them what steps they take to deal with people on small screens - a technical explanation like "we offer alternative stylesheets" is okay, being blown off with "nobody has small screens like that" is very bad.
Go to the front page of the most recent addition to their portfolio. View source. Are there <table> tags in there? Look at the
Exactly. If this were about web authors wanting to control what users can do with their content, we'd see people getting angrier at Google than they did at Microsoft.
But it's not about trying to control users, it's about not letting a third party alter content without users realising.
I find it surprising that most/.ers, while criticizing the MPAA and the RIAA for placing restrictions on the way their content is used, balk when website content is manipulated on the browser end.
There is a world of difference between what Google are doing and what Microsoft did. Microsoft's "Smart Tags" were switched on automatically. As far as the average user was concerned, the website was linking those terms. This new feature of Google's is initiated by the user - so no such implication is made.
Website authors don't like the idea of having their websites altered to make it look like they are endorsing something. This isn't a case of stopping people from doing what they want with the content - if it were, Google wouldn't be "getting away with it", would they?
it confuses me that you'd rather lower barriers to entry for browser developers than to content producers
I'd rather lower the barrier for entry for browser developers because the barrier to entry for content producers is practically nil - or it would be if browsers weren't so lax.
However, I think these two pieces argue against your position more thoroughly than I ever could:
Not really.
Mark Pilgrim thinks that pointing out mistakes in code counts for something. It doesn't. Those mistakes are continually made in an environment that makes it easy to ignore them. You can't use that as an argument that a stricter environment wouldn't work, in fact, it's an argument for a stricter environment.
His thought experiment relies upon two utterly bizarre axioms; that a tool would exist that generated data that it crashed upon reading itself; and that tools like that would be commonplace enough to be a problem.
Think about it for a second. A CMS that produced invalid code that it couldn't handle itself would be like if the GIMP corrupted images when it saved them and then couldn't open them again.
Are you really saying that this would be an overwhelming problem for the web, when it's not a problem for any other type of software?
There isn't really anything you need to know except what objects are available and what their interfaces are. The documentation is good enough for that.
And even with the alternate versions, sometimes the background colored areas of the PNGs don't exactly match the actual background color even though they have the exact same color designation.
That's due to gamma correction. Remove gamma information from your PNG images, and it will display more consistently across browsers. More information.
Well, can't comment on the the validity of the site itself, but why does it matter? You're not buying *that* site.
Because if they can't even get their own website right, how can they be qualified to judge the quality of the templates they broker?
Some of them use CSS, but most do not.
This isn't the mid 90s. I'd certainly expect anything called "professional" to use CSS.
Looks kosher to me in both IE and Firefox.
That's about 1% of the configurations a professional should test in. Firefox with larger than normal fonts? Internet Explorer with smaller than normal fonts? Mozilla with Javascript switched off? Omniweb? Safari? Opera? Internet Explorer on the Mac has a completely different rendering engine to Internet Explorer on Windows. Internet Explorer on Windows renders things differently depending on what "mode" it's in. How do you know search engines can understand it? Does it comply with accessibility legislation?
That's the tip of the iceberg. Loading it up in two different browsers and saying "works for me" isn't professional. Like I said, it might be acceptable for a hobby website, but that's it.
Slashdot Mirror
Just put
in a user stylesheet. And then realise that there are lots of sites that use this legitimately, and take it back out again.The crux of the matter is that dynamically positioning things on screen is not a reliable indicator that something is an advert, and that restricting pages from doing so will stop many legitimate things from being possible.
As far as I know, nobody has come up with a way to identify these things reliably. CSS "flying elements", as you call them, encompass a whole range of different things, only one of which is advertising.
That's not feasible. You're forgetting that they are part of the page - not some external thing that is easy to identify. Furthermore, the idea of positioning something on the page is a legitimate one, and is used all the time - e.g. for drop-down menus.
Unfortunately, advertisers are beginning to experiment with techniques that make it far harder to differentiate between adverts and content automatically - unrequested window.open()s are dead simple in comparison to trying to decide if every positioned element on the page is an advert or not.
What makes GMail etc innovative? I've just finished explaining that these techniques have been in use for years. For instance, here's a story on Kuro5hin from 2002 that mentions a dynamic threading mode that can be used to display new information from the server without reloading the page.
This isn't about "non-compliant browsers". Catering to browsers with different capabilities without resorting to highest common factor design is something web developers do all the time. It's not something that went out when people stopped supporting "both" browsers, and it's certainly not some kind of Netscape 4.x legacy. It's a general principle that the web relies on, and is unrelated to usability - apart from the fact that it is a method that avoids breaking things completely for some people.
I hope you aren't trying to imply that this means they are writing high quality code.
That's a ridiculous, superficial analysis. There are many ways in which user-agents can differ, and they can be quite independent. For instance, only the very latest betas of (modern) Opera support XMLHttpRequest, somebody might switch off images if they are surfing on their (modern) laptop over their (modern) mobile phone, or a business might follow (modern) CERT's advice and disable client-side scripting on their employee's (modern) browsers.
Jesus H. Christ on a skateboard! You are replying to a comment that explains what graceful degradation is. How about you try reading it. It does not entail sacrificing any functionality whatsoever, for Lynx or any other browser. Sacrificing functionality is mutually incompatible with graceful degradation, so I fail to see how you could possibly confuse them.
WYSIWYG is a myth on the web. Or rather, what you see is pretty unimportant. Rendering can, will and should differ depending upon the individual circumstances of the person visiting a website.
When you pay somebody to develop a website, you aren't paying them to draw you a picture that happens to have text in. The web is not like print media, it's fluid. What you are paying them for is a set of pages that adapt to the circumstances under which they are viewed.
WYSIWYG tools such as Netscape Composer are not very good for this purpose. They give a decent impression when all you do is type out a few pages and look at them on your computer, but to get results that are suitable for professional use, there really isn't any substitute for coding by hand.
Of course, many professionals code the front-end by hand, and use a CMS with a nice GUI on the back-end to make things simple for their clients. This is a good thing; hand-coded websites aren't better because they are harder to create, they are better because the HTML, CSS, Javascript, etc has been crafted to work appropriately - something an automated tool simply cannot do. Pouring content - that may have been entered by a nice GUI interface - into a hand-written "mould" like this is good practice.
So GUI tools aren't intrinsically bad, so long as they are simply the means by which you enter content into a high-quality front-end. The trouble is, many tools, including Netscape Composer, don't distinguish between the two tasks and also create the front-end for you - something they are unable to do effectively.
In terms of how much credence I'd give, it's roughly this order (best first):
Most organisations will get the best quality:price ratio by hiring people somewhere in the middle - anything more is often overkill.
This is quite common, yes. One situation that is sadly very frequent is when a professional firm takes over something the manager's nephew did, or something that is otherwise awful but that they spent a lot of money on.
I know I've been trapped in the situation of maintaining hideous messes until the client can afford a redesign, when the only reason they can't afford a redesign is because they got ripped off by somebody who didn't know what they were doing.
Depending on the size of the website in question, it's sometimes quicker to simply start over from scratch. If the people who originally developed the site didn't know what they were doing, chances are, reorganising all the information is badly needed anyway.
It's an oversimplification, but a hard one to shake. Jakob Nielsen argues that a poor-quality website is harmful in the long run.
In some cases a poor website can directly lead to business risk. For instance, a website that doesn't follow the W3C specifications is more likely to break when a new version of a browser is released. This is a historic trend with concrete examples that goes back to
That's what I meant. Sorry for the imprecise (actually, incorrect) language.
No, it won't, the fix is in the 1.1 branch.
If people abuse Javascript in the manner you describe, then by all means criticise them for it. But don't lump those incompetents in with the people who use Javascript - including remote scripting, or "AJAX" - appropriately.
Again, there is no such thing as an "AJAX engine" on websites any more than there is a "web engine" on websites or a "DHTML engine" on websites.
If you want to do lots of complicated things, then yes, there will be a lot of code. If you want to do small, simple things, then no, it won't be a lot of code. Remote scripting/AJAX is a technique that can be used in both situations. And like I said, you can use this technique effectively in a few lines of code.
People have linked to tutorials in these comments, I suggest that you at least skim them before complaining about it.
I wouldn't call Google Maps small. Google maps needs a lot of code because it does a lot of stuff. This isn't anything to do with remote scripting or Javascript, it's simply how programming works. You want to write an application that does a lot of things - you write a lot of code.
Saying that remote scripting needs lots of code to work because you have a negative impression of Google Maps is like saying that C programs need millions of lines of code because you saw the source to Windows.
But remote scripting requires no such thing!
I responded because you described a fairly useful technique in a completely unreasonable way without being the least bit familiar with it or even reading the article. You went on to state that "they won't work right" and said that since it requires communication with the server it was useless anyway!
Not only was it completely misleading to anybody unfamiliar with the technique, it was also pretty annoying when plenty of people have developed things with this technique that aren't incompatible or bloated, and are being described as such by you.
Yes, I agree, there are a lot of cases where Javascript is used in an inappropriate manner. It annoys me too. But you can write crap code in any language, and it's simply ignorant to criticise this technique because some people don't know how to apply it well.
I think you might be right (and I know what XMLHttpRequest is, thanks :) ). I was basing my statement on knowledge of an earlier draft. It appears that although it's implemented in the browsers I mentioned, it was taken out of the DOM3LS specification before final publication. I'm not sure if another specification covers this or if I'm missing the bit of the specification that refers to this, I'll have to investigate further.
So let me get this straight - you've characterised it as "an ungodly big JavaScript to pass XML between the server and client", and yet you haven't read or understood the article at all?
There is no "AJAX engine". It's a term used to describe a particular combination of technologies. Like the way we call HTTP+HTML+etc "the web" instead of calling it "HTTP+HTML+etc" all the time.
The core component that has been getting a lot of attention lately is the XMLHttpRequest object. You can pull XML documents over the network with a few lines of code. Your claim that it requires massive amounts of code is ridiculous.
Where did you get that idea? It's a tool, I use it where it's appropriate. I replied to you because what you were saying was completely misleading, not because I like Javascript.
Browser dependence? It works on Internet Explorer, Gecko, KHTML and the latest Opera betas. Including all the browsers using those engines, that's dozens of browsers it works in. So exactly what is your problem?
What does that have to do with XMLHttpRequest? I explicitly mentioned graceful degradation. You do know what that is, don't you?
Then criticise the people that write that code. It's not something intrinsic to Javascript or XMLHttpRequest. Like I said, they can be used while remaining perfectly compatible with alternative browsers.
Of course not. But you are describing it as if developers have to choose between the two options. They can use both - offering automatic notifications for browsers that have XMLHttpRequest, and letting people using other browsers click the button manually.
Which existing technologies? Google's use of remote scripting (that's the name it's had for years, I don't see the need to change it) uses HTML, CSS, Javascript and XMLHttpRequest.
Given that XMLHttpRequest has been used in relation to these technologies for just under six years, and that before that, invisible inline frames were used to do similar things, I fail to see how this is a novel combination of technologies. In fact it's hard to conceive of a use of XMLHttpRequest that didn't use these technologies.
GMail is the most complex example of it I have seen. GMail is the most popular example of it I have seen. But "complex and popular" does not mean "innovative" unless you are looking in a Microsoft dictionary.
Please go back and read what I wrote. I know this is impossible in those browsers. That's the whole basis for graceful degradation.
It is certainly possible to build a webmail application that works in Lynx and Netscape 4. It won't be very fancy, but it will work.
You can make it much more user-friendly for more advanced browsers in one of two ways.
Do it the Google way, and construct a Javascript behemoth that fails to function at all in browsers that don't support every feature Google wants.
Do it so that it degrades gracefully, so if a browser doesn't happen to have all the features you use, it falls back to less onerous requirements.
Quite frankly, I'm surprised that Google don't understand this better. If pages didn't degrade gracefully, the Google search engine itself would not be possible.
I should also note that we don't have to go back to browsers like Netscape 4 and Lynx when talking about this stuff - the latest releases of Konqueror, Opera and Safari have all had problems dealing with the GMail code.
The latest version of HTTP is 1.1. What are you referring to when you say "HTTP version 2"?
That simply gives me a headache. Why does a Scalable Vector Graphics file format need support for NETWORKING? SVG can already be manipulated via the DOM. The DOM already includes features to load resources over the network. The same thing in SVG is simply redundant.
No wonder it's taking so long to implement SVG in browsers if this is the kind of thing they are sticking in the specs.
This isn't an either/or technology. AJAX depends upon Javascript and particular objects/features of particular implementations. It's nice (and useful) to have it mostly work in the most popular browsers, but it's not something that should be relied upon.
Build your application with CSS/HTML + PHP. Then, when you get around to it, add remote scripting as an optional enhancement. If the objects are available on the client, use them, otherwise fall back to submitting forms in the traditional manner.
"Graceful degradation" means that when you do do something new that some browsers can't handle, it's constructed in such a way that those browsers still get something that works.
Criticising graceful degradation as being an attitude of avoiding new, incompatible stuff is ignorant, since if you weren't doing new, incompatible stuff, graceful degradation wouldn't even apply.
What? XMLHttpRequest can grab an XML document in a few lines of code. What makes you think you need to "write an ungodly big JavaScript"?
Feel free to single Google out for screwing up compatibility, but it's a shortcoming of Google, not something intrinsic to Javascript. Javascript can easily be used to enhance the UI for a web application, while gracefully degrading for clients that can't handle it.
You really haven't paused to look at what's possible. For example, a webmail application can periodically poll the server for new events such as new mail without interrupting what the user is doing with a page reload. Yes, obviously the client still has to communicate with the server, but that doesn't mean it isn't an improvement.
Google's innovation? This technology has been around for years. Google are merely the first high-profile organisation to require it for public web applications. And requiring it is bad, the concept of "graceful degradation" is sadly lost on Google.
DOM 3 Load and Save was published as a W3C recommendation almost a year ago, and works in Mozilla, Firefox, Konqueror and the latest Opera betas.
Disclaimer: I'm a web developer, and I don't always do things this way myself. They are rules of thumb, not laws that must be followed.
The most important thing to bear in mind is that you need to know what it is you want to achieve with the website. Some firms are all too happy to sell you an all-singing, all-dancing e-commerce haven (and charge appropriately), when all you actually need is a contact form, address and phone number on a single page.
Business stuff:
Get concrete deliverables. Example deliverables:
These deliverables will be missed a couple of times. The important thing is that your contract states what constitutes acceptable quality and how slips will be resolved - if they lose money every time they miss a date or forget a feature, they'll keep to schedule and not rush things out the door.
There are a few signs to watch out for from people selling snake-oil.
The human touch. Visit their offices a couple of times.
Technology:
Or even the Joel Test for web development.
Exactly. If this were about web authors wanting to control what users can do with their content, we'd see people getting angrier at Google than they did at Microsoft.
But it's not about trying to control users, it's about not letting a third party alter content without users realising.
There is a world of difference between what Google are doing and what Microsoft did. Microsoft's "Smart Tags" were switched on automatically. As far as the average user was concerned, the website was linking those terms. This new feature of Google's is initiated by the user - so no such implication is made.
Website authors don't like the idea of having their websites altered to make it look like they are endorsing something. This isn't a case of stopping people from doing what they want with the content - if it were, Google wouldn't be "getting away with it", would they?
I'd rather lower the barrier for entry for browser developers because the barrier to entry for content producers is practically nil - or it would be if browsers weren't so lax.
Not really.
Mark Pilgrim thinks that pointing out mistakes in code counts for something. It doesn't. Those mistakes are continually made in an environment that makes it easy to ignore them. You can't use that as an argument that a stricter environment wouldn't work, in fact, it's an argument for a stricter environment.
His thought experiment relies upon two utterly bizarre axioms; that a tool would exist that generated data that it crashed upon reading itself; and that tools like that would be commonplace enough to be a problem.
Think about it for a second. A CMS that produced invalid code that it couldn't handle itself would be like if the GIMP corrupted images when it saved them and then couldn't open them again.
Are you really saying that this would be an overwhelming problem for the web, when it's not a problem for any other type of software?
There isn't really anything you need to know except what objects are available and what their interfaces are. The documentation is good enough for that.
That's due to gamma correction. Remove gamma information from your PNG images, and it will display more consistently across browsers. More information.
Because if they can't even get their own website right, how can they be qualified to judge the quality of the templates they broker?
This isn't the mid 90s. I'd certainly expect anything called "professional" to use CSS.
That's about 1% of the configurations a professional should test in. Firefox with larger than normal fonts? Internet Explorer with smaller than normal fonts? Mozilla with Javascript switched off? Omniweb? Safari? Opera? Internet Explorer on the Mac has a completely different rendering engine to Internet Explorer on Windows. Internet Explorer on Windows renders things differently depending on what "mode" it's in. How do you know search engines can understand it? Does it comply with accessibility legislation?
That's the tip of the iceberg. Loading it up in two different browsers and saying "works for me" isn't professional. Like I said, it might be acceptable for a hobby website, but that's it.