Just this Monday we were filming for a TV programme and we used these guys to demo an iPad app on a giant touchscreen. It's still early days for the technology, but it works well for that use case already.
You cannot prove anything about the future... but you can identify trends.
Before Netscape 1.2 came out, it was a common, non-standard hack to use multiple title and body elements to get crude animation. Netscape 1.2 came out, and screwed these pages up. Following standards ensured forwards compatibility with Netscape 1.2.
Before Netscape 2.0 came out, missing quotes on the end of an attribute were detected as errors by Netscape 1.x and compensated for. Netscape 2.0 came out; it did not. Large sections of pages disappeared. Following standards ensured forwards compatibility with Netscape 2.0.
Before Netscape 3.0 came out, people were careless with their ampersands, failing to correctly encode them in URLs, for example. These were detected as errors by the current browsers, and compensated for. Netscape 3.0 came out; it did not. Lots of broken links everywhere. Following standards ensured forwards compatibility with Netscape 3.0.
Before Netscape 4.0 came out, people were still careless with character entities, omitting the trailing semicolon (I believe this was a property of many graphical editors, such as Frontpage). This was detected by the current browsers, and compensated for. Netscape 4.0 came out; it did not. Following standards ensured forwards compatibility with Netscape 4.0.
Before Netscape 6.0 came out, people used a variety of non-standard Javascript techniques and layer elements, detecting Internet Explorer, and serving them alternative code. Netscape 6.0 came out, it didn't support the proprietary Netscape-isms of previous releases. Following standards ensured forwards compatibility with Netscape 6.0.
More recent problems include stylesheets served with an incorrect content-type header, and table-layout images being broken up with lots of little gaps.
This list only includes Netscape behaviour, as that is the only list I have to hand. (Thanks to this article). I'm sure similar things apply to other browsers.
There is plenty of evidence that sticking with standard code results in forwards compatibility.
There are really only two important properties of future browsers:
They are likely to support at least as much of the specifications as the current version
Nobody can test in them
Thus, my overwhelming desire is to simply treat future browsers as I would any other browser I couldn't test in: code to standards, and when I get a chance to test, fix up what is necessary.
There are very few good reasons these days to write invalid code. Mostly it's just ignorance and apathy that causes people to write invalid code.
Firefox already adheres to standards better than IE, has a more rubust, and secure environment, and arguably provides a superior user experience to IE, and yet IE lives on... So why would some (arguably nice) DHTML addons make a difference?
Many organisations are legally obliged to make their internal applications, including web applications, accessible to the disabled.
Two of the most popular applications that can read websites out to blind people, JAWS and IBM Homepage Reader, are both based on Internet Explorer.
This code will supposedly make it easier for web applications using DHTML to work in Firefox for disabled people.
Most httpd's do not run as "root" (or equivalent), so unless you're satisfied with all created files being owned by something like "www-data", you have to use something different.
Most httpds do run as root, but drop privileges. The same goes for ftpds. As for ownership, it's not an easy problem to solve, but there are plenty of different solutions, e.g. the Apache on port 80 is a proxy for Apaches on other ports running as the correct user.
I only wish HTTP had an INDEX method, where you could get a real file/directory index listing in a standard XML format suitable for use in a file manager
Why use FTP, NFS, WebDAV, or SMB with all their bloat, complexity, and security problems when you could just be using good old HTTP which you already know and love?
WebDAV is HTTP. In particular, WebDAV is HTTP with a few extra methods. Lo and behold, one of the methods it provides is PROPFIND, which can return "a directory listing in a standard XML format suitable for use in a file manager".
I don't know why it's never been added by anyone as an extension, either.
It has. The extension is called "WebDAV". But that's just "bloat, complexity and security problems", right?:)
Sure, but Apache dumps this anyway according to the said META declaration.
No it doesn't. Apache doesn't pay attention to meta element types. I don't think any server does (or ever did). Sure, that's what <meta http-equiv> was originally designed for, but think about it - do you really want your web server to have to parse each and every HTML document it serves?
These days, <meta http-equiv> is merely an unreliable indicator to a browser. If you have legacy documents, it should be fairly simple to write a script to pipe them through HTML Tidy or something, or if they are in a separate area of your website, just use an.htaccess file to send a different header for those particular documents.
But, if AddDefaultCharset is defined and said charset value in META declaration is written in UPPERCASE, then Apache simply ignores it
Apache always ignores it. It's browser behaviour you are seeing.
The Open Sores Movement asks us to ignore three decades of innovation. It's just a notch above Luddism. At least they're not bombing Redmond. Not yet anyway.
I don't care what he invented decades ago, the guy's an idiot with a chip on his shoulder.
Actually writing the web pages is often done locally, and the contents transferred to the actual web site by copying the file over. If you use CSS files, you have to remember to also transfer the edited CSS files to the correct relative locations
But surely that is an artifact of compound documents and is also an issue with images, Javascript, video, etc? CSS is by no means the first type of external resource referenced by an HTML document.
except that a lot of the modern GUI's have a bad habit of replacing any relative links, content, inclusions, or anything else with absolute paths.
So what you are saying is that some of these visual layout editors are specifically broken with regard to CSS where they are not broken with regard to similar resource types? That's a bug in the editors, not a shortcoming of CSS. Use junk software, get junk output.
A free-standing, no inclusion webpage doesn't have this transfer problem.
And such webpages will have no images either, right? They too are external resources, unless you are using the data: URI scheme, which doesn't work in Internet Explorer and other old browsers.
You don't have to use external stylesheets with CSS, you can also include it in the head element of your documents. It's less efficient that external stylesheets, but still more efficient than presentational HTML.
If you don't believe me, go take a look at how people use FrontPage and MS Word-generated HTML, and compare it to a simply written and much smaller webpage actually written with a text editor.
Oh, I'm not defending code generating tools. I think they're crap too. But that doesn't mean we should use PHP in place of CSS, it means we should avoid using crap, broken software when there are better alternatives.
technically, following the recommendations of Appendix C will still get you into trouble if an actual XML parser ever sees your XHTML-as-text/html; that's why people go on about SHORTTAG
You mean SGML parser, not XML parser, right?
If you are blindly passing text/html documents to an SGML parser, you are ignoring RFC 2854, the text/html definition, because it states that some forms of XHTML are also suitable for transmission as text/html.
And Appendix C is not comprehensive here
Of course. This is why I said "XHTML 1.0 doesn't say that following Appendix C automatically makes you conform to all relevant specifications; that responsibility has always been the publisher's.".
it makes no mention of the problem caused by assumptions of default character encodings
Let's get this in perspective here. It's an appendix in a markup language's specification, intended to aid compatibility between different markup languages. Unsurprisingly, it focuses on the incompatibilities between the two markup languages, rather than transmission protocol issues.
And in fact you are wrong. It states:
In order to portably present documents with specific character encodings, the best approach is to ensure that the web server provides the correct headers.
And when you follow that advice, the problem of default character encodings simply goes away, because you aren't using the default character encoding.
and in fact recommends using an encoding which will be the wrong one if default character encodings come into play.
Appendix C doesn't recommend a character encoding. Go and read it. It points out that one consequence of omitting the XML declaration is that you are restricted to UTF-8 or UTF-16, but it doesn't recommend one.
And there's a vicious catch-22 there: if I take Appendix C to be correct and consistent, then I leave out my XML declaration and write in either UTF-8 or UTF-16. But that means I'm not using the default character encoding for the media type I'm using, which means I have to specify my character encoding. Which means I have to have an XML declaration (remember that many people, even now, publish on the web with no access to change the HTTP headers sent by their servers).
If you don't have the means to change the HTTP headers, you don't have the means to serve non-ASCII XHTML correctly. This does not mean that serving XHTML as text/html is wrong, it means some people can't do it. The catch-22 is imposed by hosts that don't provide the ability to transmit correct HTTP headers. The catch-22 is not imposed by the specifications and does not apply to everyone (or even most people wanting to serve XHTML, I'd imagine).
Speaking of which, I love how you triumphantly point out that the W3C Note on media types is non-normative, but then make a case which assumes we should follow it anyway
You've read too much into my comment. I didn't make the case that the note should be followed.
even when you follow Appendix C they say you 'SHOULD' send 'application/xhtml+xml'. So the RFC language here, in context, says "You can send 'text/html' if you want to, but we recommend you send 'application/xhtml+xml' instead." Got that?
Er, I understood it a long time before you tried to explain it to me, thanks. Where, exactly, do you think I've said something to contradict it? It seems you're reading too much into what I am saying. Stick to replying to what I actually say.
DOM checking is certainly the right way, but on 2005, almost all of these sorts of checks require that a knowledgable coder create seperate paths.
Well the crux of my argument is that object detection (what you call "DOM checking") is a much better way of branching than browser detection. The branching is necessary in many situations, yes.
In general, I dislike the code library approach because it tends to preserve buggy behavior forever.
Don't you have that the wrong way around? If you have a bug in a library, you can fix it once. If you copy & paste the code instead of making a library, then you have to hunt through all the Javascript you've ever written to fix it. I've tried both ways. It's the copy & paste that lets bugs live forever.
Most "getEl" scripts like yours put the document.all check first, which means that if the element doesn't exist, IE behaves differently than other browsers. Bug.
That's not something to do with object detection versus browser detection though, is it? Or even code library versus copy & paste.
A better practice in 2005 is to drop this sort of script all together. It is only needed to support IE4.0
No. This particular script is generally only useful when you need to support Internet Explorer 4.0, but that doesn't mean this sort of script is no longer useful.
A more relevant example would be checking for XMLHttpRequest, but that involves two different code branches anyway due to the difference in instantiation between the ActiveX and native objects.
I chose the document.getElementById versus document.all example because it's a simpler example of the technique. The fact that this particular example caters to an older browser is irrelevant. This sort of script is still the best method of supporting browsers with different capabilities today.
Oh, so then by 'working' you didn't mean 'valid'. Okay.
Browsers don't care if your documents are valid according to your own private DTD. Whether you comply or not is utterly irrelevent to the point - which, in your own words, is "to create markup that can be parsed as XML by the client".
The "problem" isn't that it doesn't validate. The problem is that it isn't valid.
Please, just stop and think for a second. Web browsers expect HTML or XHTML when they are served text/html, application/xhtml+xml or whatever.
You feed them something else. What's more important - that the document is valid according to a DTD they have never heard of and won't even read, or that it isn't what the browsers are expecting?
It isn't just the validator that can't figure out if the document is well-formed.
Well-formed != valid. We are talking about validity. If we were talking about well-formed, then writing a custom DTD would be even more pointless, because the documents are already well-formed without it.
Wow, that's pedantic, even for/.
So how do you determine what is and isn't XHTML then?
I don't consider calling a document that doesn't conform to an XHTML specification or validate with an XHTML DTD "not XHTML" to be pedantic. Pedantic, to me, is writing a DTD for your "not XHTML" to get a pat on the head from the validator even though browsers don't care and it doesn't help interoperability.
So, as you say, there's no reason to have a custom DTD because you don't need a custom DTD to have this markup parsed as XML
No, that's not what I am saying. I am saying that being valid according to a custom DTD is functionally equivalent to being invalid according to a custom DTD, as far as web browsers expecting HTML or XHTML are concerned. Valid or invalid customML, it's still not valid HTML or XHTML.
But, somehow, other client types are going to have ridiculous amounts of trouble accessing the "XHTML" document because of a couple of extra attributes in the DTD and this will seriously harm interoperability. Does this sound contradictory to you at all?
Don't overexaggerate my point to ridicule me. I never said "ridiculous amounts of trouble" or "seriously harm interoperability", they are just straw-man arguments.
People have been bitten before by "no browser is going to get confused by this" assumptions. Often, a new version of a browser comes out and gets confused and they have to scramble to fix up all their websites. The browser developers can check to see if it gets confused by HTML or XHTML before they release it. They have HTML and XHTML testcases. They can't check to see if it gets confused by any private document type you can trick it into viewing. They don't have testcases for your private document types.
Which media type are you serving these documents as? You are aware that the only form of XHTML that is suitable to be served as text/html is XHTML 1.0 documents following Appendix C of the XHTML 1.0 specification aren't you? If you are serving these documents as text/html (as pretty much every mainstream website must do to support Internet Explorer), then you might be conforming to your DTD, but you aren't conforming to the relevant RFCs.
Say you want to get an element with a particular id attribute. Older versions of Internet Explorer don't support document.getElementById() but do support document.all. Newer versions of Internet Explorer support both. Other browsers sometimes support document.all and sometimes support document.getElementById.
The bad way of sorting this mess out is to try and figure out which browser is being used, and keep updating your detection code on every website you do every time a new browser is released.
The smart way of sorting the mess out is to not care what browser is being used, but simply check to see if document.getElementById() and document.all exist. Example:
function getEl(id) { if (document.getElementById) { return document.getElementById(id); } if (document.all) { return document.all[id]; } return false; }
This way, somebody using a browser you've never even heard of can visit your site and have things work.
Internet Explorer 7.0 running on Longhorn will have a user-agent string of: Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0) according to the IE Blog. Presumbly, Internet Explorer 7.0 running on Windows XP will have a user-agent string of: Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1)
The point is to create markup that can be parsed as XML by the client.
No. If you RTFA, you'll see that there is already working code in place, and the solution of a custom DTD is solving the "problem" that it doesn't validate. I'm saying that solving that "problem" is pointless, because it's merely sweeping the problem under the rug.
You don't need a custom DTD to get your code to be parsed as XML.
The choice in TFA is between XHTML that does not validate as XHTML
If it doesn't conform to the XHTML specification and DTD, then it's not XHTML, is it?
The choice in the article is between a document that doesn't conform to any known DTD, and a document that conforms to your own custom DTD.
As far as I can see, the two choices are identical in terms of parsing as XML and in terms of interoperability. Which makes the extra effort of writing a custom DTD to be pointless.
Conforming to a DTD doesn't imbue your documents with magical interoperability goodness. Conforming to a DTD that lots of people know and use and which has an open specification aids interoperability.
Did you mean HTML user-agent? HTTP has clients, not user-agents.
If a shell script processes HTML, it's an HTML user-agent. From the spec:
An HTML user agent is any device that interprets HTML documents. User agents include visual browsers (text-only and graphical), non-visual browsers (audio, Braille), search robots, proxies, etc.
I can see you making the argument that JavaScript is "general purpose processing by user agents", but I don't see you making the case for the same with a shell script.
Why not? Because you don't think it's an HTML user-agent? It is. It doesn't have to be a browser to be an HTML user-agent.
And from that you say that calling the class attribute's intention to attach CSS behavior to an element as '"wisdom"' and 'completely wrong', which seems like quite a bit of an overstatement, if not also completely wrong.
No. If I had said that, then I would be completely wrong. I didn't say that though. What I did say was that your assertion that the class attribute is for CSS but not Javascript is completely wrong. The class attribute is for general-purpose processing. This includes CSS, Javascript, shell scripts, and pretty much anything else you can think of.
What's the point in conforming to a DTD if it isn't one of the DTDs that everybody else is using? The whole point of writing valid code is to aid interoperability. If you are using your own DTD, then it doesn't aid interoperability at all. You can redefine anything to be valid in your own private markup language. But what's the point?
It would be perfectly valid, sure, but it wouldn't be perfectly valid XHTML. It would be a perfectly valid document in your own private markup language. Even PPK admits it. I can write a DTD that adds <marquee> to XHTML 1.1 - that doesn't mean documents using <marquee> are valid XHTML 1.1 documents.
I guess you think JavaScript is "general purpose processing by user agents."
Yeah, I do. The class attribute is general purpose, not for any specific purpose like CSS or Javascript. You can do what you like with it. One of the things you can do is process it with Javascript. Another thing you can do with it is use it in a selector in CSS. Another thing you can do with it is pull it out with a shell script. You can do what you like with it. It's general-purpose.
Where's the disagreement here? What do you think the specification means by "general purpose"?
Those "purists" actually have read the specification, and then they've gone on to read the Note on Media Types
Would that be the Note that states:
Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
However, this document is not intended to be a normative specification.
?
which upgrades the lower-case "may" in the XHTML 1.0 spec to an upper-case RFC2119 "MAY" in the case of "compatible" XHTML 1.0 and adds a "SHOULD NOT" for any other XHTML.
So presumably you know what an RFC2119 "MAY" and "SHOULD NOT" means then? It doesn't mean "you must not do this" or "this is wrong". Even if the Note was a normative specification, it still wouldn't mean that it would be wrong to transmit XHTML 1.0 documents following Appendix C as text/html.
Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.
Sounds nice, but it's wrong
No, it's not wrong, it's a requirement. It doesn't state "this is how the document will be interpreted", it states "this are the encodings you must use to conform to this specification". The onus of working out how to use those encodings while still conforming to other specifications is on the author. Just like every other specification ever published, I would imagine.
So if you write your XHTML in UTF-8 or UTF-16, and follow the recommendation to leave out the XML declaration, then you should expect to see well-formedness errors related to the character encoding of the document.
Only if you ignore the specifications that dictate the default character encoding for text/* media. XHTML 1.0 doesn't say that following Appendix C automatically makes you conform to all relevant specifications; that responsibility has always been the publisher's. And the publisher who knows what he's doing will understand that the default character encoding isn't what he wants and will select UTF-8 or UTF-16.
the only way you can guarantee an assumption of UTF-8 or UTF-16 by the parser is to use application/xml or application/xhtml+xml
No, you can use the charset parameter to the text/html media type. In fact, that's the most common way of doing it.
And most, if not all of those XHTML compliant buttons on websites are incorrect, since they are sending the content as text/html, which is not an XML application
text/html is not for HTML alone. It's for XHTML too. Read the RFC. It explicitly states that it is permitted to send XHTML 1.0 documents following the "compatibility profile" (Appendix C) of the XHTML 1.0 specification.
The misconception that XHTML as text/html is wrong is popular, but incorrect. It might not be a good idea for most people to serve XHTML in this way, but it's not wrong or against the specifications in any way.
Classes are for CSS behavior, not JavaScript behavior.
I don't know where you picked up that little nuggest of "wisdom", but it's completely wrong.
The class attribute is for grouping disparate elements. This is very useful in both CSS and Javascript, but it is not "for" either. It's a general mechanism - you can use it in custom written shell scripts that work with wget if you like, no Javascript, no CSS, still perfectly fine.
If you are confused about what an element type or attribute is for, consult the specification. It is quite clear in stating that it's for "general purpose processing by user-agents".
Show me an implementation of an AJAX product catalog that doesn't suffer from severe usability problems.
Well AJAX is only recently gaining mindshare amongst developers, so there's not many examples of it out in the wild.
In any case, I can't think of a single product catalogue, with or without AJAX, that doesn't have usability problems.
Backbase is a perfect example of why this is not a good idea
No, that's a perfect example of a terrible use of AJAX. It's also a perfect example of a terrible use of Javascript. Does that mean all Javascript is bad? It's also a perfect example of a terrible website. Does that mean all websites are bad?
Really, there is nothing intrinsically bad about AJAX that means you can't use it for stateful applications. In fact, there are many opportunities to increase usability by using AJAX. Pointing out an example of somebody misusing AJAX doesn't change this fact.
As I said before, the important thing is to retain addressability. When somebody adds something to their shopping cart, there is no need to change the URI.
A better solution would be to start with a page that has an "edit" button that works without Javascript. Then have your Javascript check to make sure the AJAX stuff is available, and makes the visibility of the edit button hidden (while keeping a rule that unhides it on:focus for keyboard users).
Finding all the.editable elements in your onload handler or at the bottom of the page is bad practice as well. On a slow connection or when you have slow-loading ads, the user could be double-clicking like mad with nothing happening. Use actual ondblclick attributes on each element. It's more code, but doesn't break when the timing isn't perfect.
Doing AJAX badly is easy. Doing AJAX well requires a bit more thought if you want it to work reliably.
Slashdot Mirror
Just this Monday we were filming for a TV programme and we used these guys to demo an iPad app on a giant touchscreen. It's still early days for the technology, but it works well for that use case already.
Reposted from something I wrote a while ago
There are very few good reasons these days to write invalid code. Mostly it's just ignorance and apathy that causes people to write invalid code.
Many organisations are legally obliged to make their internal applications, including web applications, accessible to the disabled.
Two of the most popular applications that can read websites out to blind people, JAWS and IBM Homepage Reader, are both based on Internet Explorer.
This code will supposedly make it easier for web applications using DHTML to work in Firefox for disabled people.
PUT has been part of the HTTP 1.1 specification for years and years.
Most httpds do run as root, but drop privileges. The same goes for ftpds. As for ownership, it's not an easy problem to solve, but there are plenty of different solutions, e.g. the Apache on port 80 is a proxy for Apaches on other ports running as the correct user.
WebDAV is HTTP. In particular, WebDAV is HTTP with a few extra methods. Lo and behold, one of the methods it provides is PROPFIND, which can return "a directory listing in a standard XML format suitable for use in a file manager".
It has. The extension is called "WebDAV". But that's just "bloat, complexity and security problems", right? :)
No it doesn't. Apache doesn't pay attention to meta element types. I don't think any server does (or ever did). Sure, that's what <meta http-equiv> was originally designed for, but think about it - do you really want your web server to have to parse each and every HTML document it serves?
These days, <meta http-equiv> is merely an unreliable indicator to a browser. If you have legacy documents, it should be fairly simple to write a script to pipe them through HTML Tidy or something, or if they are in a separate area of your website, just use an .htaccess file to send a different header for those particular documents.
Apache always ignores it. It's browser behaviour you are seeing.
To late. He seems to have a real grudge against open-source. Here's an article where he refers to it as "open-sores software" from 1999. Here's a choice quote:
I don't care what he invented decades ago, the guy's an idiot with a chip on his shoulder.
Actually writing the web pages is often done locally, and the contents transferred to the actual web site by copying the file over. If you use CSS files, you have to remember to also transfer the edited CSS files to the correct relative locations
But surely that is an artifact of compound documents and is also an issue with images, Javascript, video, etc? CSS is by no means the first type of external resource referenced by an HTML document.
except that a lot of the modern GUI's have a bad habit of replacing any relative links, content, inclusions, or anything else with absolute paths.
So what you are saying is that some of these visual layout editors are specifically broken with regard to CSS where they are not broken with regard to similar resource types? That's a bug in the editors, not a shortcoming of CSS. Use junk software, get junk output.
A free-standing, no inclusion webpage doesn't have this transfer problem.
And such webpages will have no images either, right? They too are external resources, unless you are using the data: URI scheme, which doesn't work in Internet Explorer and other old browsers.
You don't have to use external stylesheets with CSS, you can also include it in the head element of your documents. It's less efficient that external stylesheets, but still more efficient than presentational HTML.
If you don't believe me, go take a look at how people use FrontPage and MS Word-generated HTML, and compare it to a simply written and much smaller webpage actually written with a text editor.
Oh, I'm not defending code generating tools. I think they're crap too. But that doesn't mean we should use PHP in place of CSS, it means we should avoid using crap, broken software when there are better alternatives.
You mean SGML parser, not XML parser, right?
If you are blindly passing text/html documents to an SGML parser, you are ignoring RFC 2854, the text/html definition, because it states that some forms of XHTML are also suitable for transmission as text/html.
Of course. This is why I said "XHTML 1.0 doesn't say that following Appendix C automatically makes you conform to all relevant specifications; that responsibility has always been the publisher's.".
Let's get this in perspective here. It's an appendix in a markup language's specification, intended to aid compatibility between different markup languages. Unsurprisingly, it focuses on the incompatibilities between the two markup languages, rather than transmission protocol issues.
And in fact you are wrong. It states:
And when you follow that advice, the problem of default character encodings simply goes away, because you aren't using the default character encoding.
Appendix C doesn't recommend a character encoding. Go and read it. It points out that one consequence of omitting the XML declaration is that you are restricted to UTF-8 or UTF-16, but it doesn't recommend one.
If you don't have the means to change the HTTP headers, you don't have the means to serve non-ASCII XHTML correctly. This does not mean that serving XHTML as text/html is wrong, it means some people can't do it. The catch-22 is imposed by hosts that don't provide the ability to transmit correct HTTP headers. The catch-22 is not imposed by the specifications and does not apply to everyone (or even most people wanting to serve XHTML, I'd imagine).
You've read too much into my comment. I didn't make the case that the note should be followed.
Er, I understood it a long time before you tried to explain it to me, thanks. Where, exactly, do you think I've said something to contradict it? It seems you're reading too much into what I am saying. Stick to replying to what I actually say.
Well the crux of my argument is that object detection (what you call "DOM checking") is a much better way of branching than browser detection. The branching is necessary in many situations, yes.
Don't you have that the wrong way around? If you have a bug in a library, you can fix it once. If you copy & paste the code instead of making a library, then you have to hunt through all the Javascript you've ever written to fix it. I've tried both ways. It's the copy & paste that lets bugs live forever.
That's not something to do with object detection versus browser detection though, is it? Or even code library versus copy & paste.
Microsoft said that they'd support Atom alongside RSS if it was finished before Longhorn. The Atom 1.0 RFC will be finalised any day now.
No. This particular script is generally only useful when you need to support Internet Explorer 4.0, but that doesn't mean this sort of script is no longer useful.
A more relevant example would be checking for XMLHttpRequest, but that involves two different code branches anyway due to the difference in instantiation between the ActiveX and native objects.
I chose the document.getElementById versus document.all example because it's a simpler example of the technique. The fact that this particular example caters to an older browser is irrelevant. This sort of script is still the best method of supporting browsers with different capabilities today.
Browsers don't care if your documents are valid according to your own private DTD. Whether you comply or not is utterly irrelevent to the point - which, in your own words, is "to create markup that can be parsed as XML by the client".
Please, just stop and think for a second. Web browsers expect HTML or XHTML when they are served text/html, application/xhtml+xml or whatever.
You feed them something else. What's more important - that the document is valid according to a DTD they have never heard of and won't even read, or that it isn't what the browsers are expecting?
Well-formed != valid. We are talking about validity. If we were talking about well-formed, then writing a custom DTD would be even more pointless, because the documents are already well-formed without it.
So how do you determine what is and isn't XHTML then?
I don't consider calling a document that doesn't conform to an XHTML specification or validate with an XHTML DTD "not XHTML" to be pedantic. Pedantic, to me, is writing a DTD for your "not XHTML" to get a pat on the head from the validator even though browsers don't care and it doesn't help interoperability.
No, that's not what I am saying. I am saying that being valid according to a custom DTD is functionally equivalent to being invalid according to a custom DTD, as far as web browsers expecting HTML or XHTML are concerned. Valid or invalid customML, it's still not valid HTML or XHTML.
Don't overexaggerate my point to ridicule me. I never said "ridiculous amounts of trouble" or "seriously harm interoperability", they are just straw-man arguments.
People have been bitten before by "no browser is going to get confused by this" assumptions. Often, a new version of a browser comes out and gets confused and they have to scramble to fix up all their websites. The browser developers can check to see if it gets confused by HTML or XHTML before they release it. They have HTML and XHTML testcases. They can't check to see if it gets confused by any private document type you can trick it into viewing. They don't have testcases for your private document types.
Which media type are you serving these documents as? You are aware that the only form of XHTML that is suitable to be served as text/html is XHTML 1.0 documents following Appendix C of the XHTML 1.0 specification aren't you? If you are serving these documents as text/html (as pretty much every mainstream website must do to support Internet Explorer), then you might be conforming to your DTD, but you aren't conforming to the relevant RFCs.
Say you want to get an element with a particular id attribute. Older versions of Internet Explorer don't support document.getElementById() but do support document.all. Newer versions of Internet Explorer support both. Other browsers sometimes support document.all and sometimes support document.getElementById.
The bad way of sorting this mess out is to try and figure out which browser is being used, and keep updating your detection code on every website you do every time a new browser is released.
The smart way of sorting the mess out is to not care what browser is being used, but simply check to see if document.getElementById() and document.all exist. Example:
This way, somebody using a browser you've never even heard of can visit your site and have things work.
Internet Explorer 7.0 running on Longhorn will have a user-agent string of:
Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)
according to the IE Blog. Presumbly, Internet Explorer 7.0 running on Windows XP will have a user-agent string of:
Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1)
No. If you RTFA, you'll see that there is already working code in place, and the solution of a custom DTD is solving the "problem" that it doesn't validate. I'm saying that solving that "problem" is pointless, because it's merely sweeping the problem under the rug.
You don't need a custom DTD to get your code to be parsed as XML.
If it doesn't conform to the XHTML specification and DTD, then it's not XHTML, is it?
The choice in the article is between a document that doesn't conform to any known DTD, and a document that conforms to your own custom DTD.
As far as I can see, the two choices are identical in terms of parsing as XML and in terms of interoperability. Which makes the extra effort of writing a custom DTD to be pointless.
Conforming to a DTD doesn't imbue your documents with magical interoperability goodness. Conforming to a DTD that lots of people know and use and which has an open specification aids interoperability.
Did you mean HTML user-agent? HTTP has clients, not user-agents.
If a shell script processes HTML, it's an HTML user-agent. From the spec:
Why not? Because you don't think it's an HTML user-agent? It is. It doesn't have to be a browser to be an HTML user-agent.
No. If I had said that, then I would be completely wrong. I didn't say that though. What I did say was that your assertion that the class attribute is for CSS but not Javascript is completely wrong. The class attribute is for general-purpose processing. This includes CSS, Javascript, shell scripts, and pretty much anything else you can think of.
What's the point in conforming to a DTD if it isn't one of the DTDs that everybody else is using? The whole point of writing valid code is to aid interoperability. If you are using your own DTD, then it doesn't aid interoperability at all. You can redefine anything to be valid in your own private markup language. But what's the point?
It would be perfectly valid, sure, but it wouldn't be perfectly valid XHTML. It would be a perfectly valid document in your own private markup language. Even PPK admits it. I can write a DTD that adds <marquee> to XHTML 1.1 - that doesn't mean documents using <marquee> are valid XHTML 1.1 documents.
Yeah, I do. The class attribute is general purpose, not for any specific purpose like CSS or Javascript. You can do what you like with it. One of the things you can do is process it with Javascript. Another thing you can do with it is use it in a selector in CSS. Another thing you can do with it is pull it out with a shell script. You can do what you like with it. It's general-purpose.
Where's the disagreement here? What do you think the specification means by "general purpose"?
Would that be the Note that states:
?
So presumably you know what an RFC2119 "MAY" and "SHOULD NOT" means then? It doesn't mean "you must not do this" or "this is wrong". Even if the Note was a normative specification, it still wouldn't mean that it would be wrong to transmit XHTML 1.0 documents following Appendix C as text/html.
No, it's not wrong, it's a requirement. It doesn't state "this is how the document will be interpreted", it states "this are the encodings you must use to conform to this specification". The onus of working out how to use those encodings while still conforming to other specifications is on the author. Just like every other specification ever published, I would imagine.
Only if you ignore the specifications that dictate the default character encoding for text/* media. XHTML 1.0 doesn't say that following Appendix C automatically makes you conform to all relevant specifications; that responsibility has always been the publisher's. And the publisher who knows what he's doing will understand that the default character encoding isn't what he wants and will select UTF-8 or UTF-16.
No, you can use the charset parameter to the text/html media type. In fact, that's the most common way of doing it.
text/html is not for HTML alone. It's for XHTML too. Read the RFC. It explicitly states that it is permitted to send XHTML 1.0 documents following the "compatibility profile" (Appendix C) of the XHTML 1.0 specification.
The misconception that XHTML as text/html is wrong is popular, but incorrect. It might not be a good idea for most people to serve XHTML in this way, but it's not wrong or against the specifications in any way.
I don't know where you picked up that little nuggest of "wisdom", but it's completely wrong.
The class attribute is for grouping disparate elements. This is very useful in both CSS and Javascript, but it is not "for" either. It's a general mechanism - you can use it in custom written shell scripts that work with wget if you like, no Javascript, no CSS, still perfectly fine.
If you are confused about what an element type or attribute is for, consult the specification. It is quite clear in stating that it's for "general purpose processing by user-agents".
Well AJAX is only recently gaining mindshare amongst developers, so there's not many examples of it out in the wild.
In any case, I can't think of a single product catalogue, with or without AJAX, that doesn't have usability problems.
No, that's a perfect example of a terrible use of AJAX. It's also a perfect example of a terrible use of Javascript. Does that mean all Javascript is bad? It's also a perfect example of a terrible website. Does that mean all websites are bad?
Really, there is nothing intrinsically bad about AJAX that means you can't use it for stateful applications. In fact, there are many opportunities to increase usability by using AJAX. Pointing out an example of somebody misusing AJAX doesn't change this fact.
As I said before, the important thing is to retain addressability. When somebody adds something to their shopping cart, there is no need to change the URI.
That's not degradable.
:focus for keyboard users).
.editable elements in your onload handler or at the bottom of the page is bad practice as well. On a slow connection or when you have slow-loading ads, the user could be double-clicking like mad with nothing happening. Use actual ondblclick attributes on each element. It's more code, but doesn't break when the timing isn't perfect.
A better solution would be to start with a page that has an "edit" button that works without Javascript. Then have your Javascript check to make sure the AJAX stuff is available, and makes the visibility of the edit button hidden (while keeping a rule that unhides it on
Finding all the
Doing AJAX badly is easy. Doing AJAX well requires a bit more thought if you want it to work reliably.