Any way of making this HTML rather than XHTML? I mean that img[apply macro] should yield <img> rather than <img />
Andreas
Any way of making this HTML rather than XHTML? I mean that img[apply macro] should yield <img> rather than <img />
Any reason why? I know it's not actually used in HTML but it would make it easier to change to XHTML if you ever needed to. I ask because I'm working on merging the HTML XHTML bundles into one and simplifying it a lot in the process.
Any reason why? I know it's not actually used in HTML but it would make it easier to change to XHTML if you ever needed to. I ask because I'm working on merging the HTML XHTML bundles into one and simplifying it a lot in the process.
Because <img /> won't validate as strict html 4.01 :) So, why HTML then, and not XHTML? Well I wass all for cutting edge XHTML yada yada, then I read in this book that there really is no difference AND XHTML makes some JavaScript stuff more complex if you really want to play by the rules. I still have some problems not going XHTML, but then again, why? for example, you're not allowed document.createElement('img'), but rather it should be document.createElementNS(... DTD path to xhtml, 'img) instead. The author spends little over two pages arguing that HTML is better than XHTML (for now). Books is DHTML utopia, from sitepoint, by Stuart Langridge.
I must confess I don't really know either way, but he makes a good argument :) So if you have any further points I'd like to hear about them, although it might blote the list a bit.
Andreas
On Oct 8, 2005, at 3:31 PM, Andreas Wahlin wrote:
I must confess I don't really know either way, but he makes a good argument :) So if you have any further points I'd like to hear about them, although it might blote the list a bit.
Well, I would say the main argument, from my point of view, is that you get the power of xml. For instance, you can use MathML (http:// www.w3.org/Math/) to enter mathematics in a pretty good way. Check out for instance the examples at http://www.w3.org/Math/testsuite/, with a good browser, e.g. Firefox. Being a mathematician, that's one thing for me in favor of XHTML. I'm sure other people can list other uses of XML. I have not messed around with Javascript, so I can't comment on that.
Andreas
Haris
On Oct 8, 2005, at 4:31 PM, Andreas Wahlin wrote:
Because <img /> won't validate as strict html 4.01 :) So, why HTML then, and not XHTML? Well I wass all for cutting edge XHTML yada yada, then I read in this book that there really is no difference AND XHTML makes some JavaScript stuff more complex if you really want to play by the rules. I still have some problems not going XHTML, but then again, why? for example, you're not allowed document.createElement('img'), but rather it should be document.createElementNS(... DTD path to xhtml, 'img) instead. The author spends little over two pages arguing that HTML is better than XHTML (for now). Books is DHTML utopia, from sitepoint, by Stuart Langridge.
The beauty of XHTML is you can then parse it with XML parsers and do tricks with that, etc etc.
Also, I've used document.createElement() just fine in XHTML. While it's probably deprecated in XHTML, it still works just fine.
The beauty of XHTML is you can then parse it with XML parsers and do tricks with that, etc etc.
Also, I've used document.createElement() just fine in XHTML. While it's probably deprecated in XHTML, it still works just fine.
ah, didn't really think of it that way ... well, persuasive arguments indeed. I'll probably have to stick with xhtml then :) On the other hand, there are issues with MIME types, that no one will probably notice anyways ... http://www.webstandards.org/learn/askw3c/sep2003.html
ok, time to put a cap on this for focus purpouses I guess.
Andreas
On 09/10/2005, at 0.59, Andreas Wahlin wrote:
The beauty of XHTML is you can then parse it with XML parsers and do tricks with that, etc etc. [...]
ah, didn't really think of it that way ... well, persuasive arguments indeed. I'll probably have to stick with xhtml then :) On the other hand, there are issues with MIME types, that no one will probably notice anyways ... http://www.webstandards.org/learn/askw3c/sep2003.html
The link is currently down (it seems), but there's also this:
http://www.hixie.ch/advocacy/xhtml
Which basically says: stick with HTML 4, because what's currently happening is, that a lot of people deliver broken HTML (as text/ html), and it probably wouldn't validate as strict XHTML (if delivered as application/xml+xhtml, which one can't really use because of lacking browser support, but which changes how the document should validate).
From what I've heard, it's fine to server XHTML, but you really should server it as text/html rather than application/xml+xhtml. The reason is because if it's broken (i.e. non-validating), the browser still understands it as text/html but not as application/xml+xhtml. This is because Firefox and Safari (I don't know about others) uses a full-blown XML parser to read application/xml+xhtml files, but it uses a regular HTML parser to read text/html files, so any non- validating stuff will break completely as application/xml+xhtml but will work as text/html.
So basically, XHTML is perfectly fine to use. Just don't use application/xml+xhtml as your MIME type unless you're 100% sure that your page validates, because if any part of it doesn't, the entire page will be rendered unreadable as the parser says "hey this isn't valid!"
On Oct 9, 2005, at 4:43 AM, Allan Odgaard wrote:
The link is currently down (it seems), but there's also this:
http://www.hixie.ch/advocacy/xhtml
Which basically says: stick with HTML 4, because what's currently happening is, that a lot of people deliver broken HTML (as text/ html), and it probably wouldn't validate as strict XHTML (if delivered as application/xml+xhtml, which one can't really use because of lacking browser support, but which changes how the document should validate).
Kevin Ballard wrote:
So basically, XHTML is perfectly fine to use.
Better yet: I have yet to see an XHTML page that renders significantly different in Safari, Firefox and IE (even 5.0 seems to do most of this correctly).
Whereas with valid HTML the results can vary.
Jeroen.
On 10/9/05, Kevin Ballard kevin@sb.org wrote:
From what I've heard, it's fine to server XHTML, but you really should server it as text/html rather than application/xml+xhtml. The reason is because if it's broken (i.e. non-validating), the browser still understands it as text/html but not as application/xml+xhtml. This is because Firefox and Safari (I don't know about others) uses a full-blown XML parser to read application/xml+xhtml files, but it uses a regular HTML parser to read text/html files, so any non- validating stuff will break completely as application/xml+xhtml but will work as text/html.
So basically, XHTML is perfectly fine to use. Just don't use application/xml+xhtml as your MIME type unless you're 100% sure that your page validates, because if any part of it doesn't, the entire page will be rendered unreadable as the parser says "hey this isn't valid!"
It is with the application/xml+xhtml mime type that you have the Javscript problems as well, plus with dynamic content like a blog it is a real pain to keep everything validating as no matter how hard you try you end up doing some silly mistake in a post and totally fsck'ng up your site until you realize it.
Hence why I am not currently serving as application/xml+xhtml although I did for a while using content negotation to serve it to the browsers that could support it.
Regards, -- Jason Bainbridge http://kde.org - webmaster@kde.org Personal Site - http://jasonbainbridge.com
-
Allan Odgaard -
Andreas Wahlin -
Charilaos Skiadas -
Jason Bainbridge -
Jeroen van der Ham -
Kevin Ballard -
Michael Sheets