Hi, in keeping with the latest and greatest, I was playing around with xhtml. Now the standard seems to be that xhtml should be send es application/xhtml+xml in the first place (there's a note about it somewhere). Or, if that is not possible, application/xml, text/xml, etc. Never as text/html (because this mimetype is not registered for this content). However, dillo doesn't recognize this mimetype and always tries to save an application/xhtml+xml file, though it can always be rendered as html. The current workaround for dillo and other browsers is just send text/html but since standards compliance is very important for dillo I would suggest treating application/xhtml+xml as though it was text/html for the time being. (or at least until the CSS support is complete). Thoughts? Ideas? Wim
Hi Wim, On Wed, Sep 07, 2005 at 05:17:13PM +0200, Wim De Smet wrote:
Hi,
in keeping with the latest and greatest, I was playing around with xhtml. Now the standard seems to be that xhtml should be send es application/xhtml+xml in the first place (there's a note about it somewhere). Or, if that is not possible, application/xml, text/xml, etc. Never as text/html (because this mimetype is not registered for this content).
I really wish things were that simple! :-) Just to get the idea, you can start here: http://www.hixie.ch/advocacy/xhtml (the URLs inside are more than worth a read too!)
However, dillo doesn't recognize this mimetype and always tries to save an application/xhtml+xml file, though it can always be rendered as html. The current workaround for dillo and other browsers is just send text/html but since standards compliance is very important for dillo I would suggest treating application/xhtml+xml as though it was text/html for the time being. (or at least until the CSS support is complete).
Thoughts? Ideas?
Yes, the above-mentioned links. To save you the agony of understanding it all, I'd say: * It's incredibly easy to allow Dillo to treat xhtml as html, but it's against the xhtml standard spirit (well, if something of its point still remains. :-) * I prefer not to allow the official Dillo to do this out of the box until at least some validation tailored to xhtml is in place. Remember, the UA is expected to do validation. The bug meter does this, but with the HTML4.01 spec in mind. It would require an XHTML mode. Given the current priorities, that day seems far away. Now, having an rc option like "treat_xhtml_as_tag_soup", could do the trick in the meanwhile, but only if someone goes through the above-mentioned links and convinces me that's there's no point in not having it. :-) -- Cheers Jorge.-
On 9/9/05, Jorge Arellano Cid <jcid@dillo.org> wrote:
Hi Wim,
On Wed, Sep 07, 2005 at 05:17:13PM +0200, Wim De Smet wrote:
Hi,
in keeping with the latest and greatest, I was playing around with xhtml. Now the standard seems to be that xhtml should be send es application/xhtml+xml in the first place (there's a note about it somewhere). Or, if that is not possible, application/xml, text/xml, etc. Never as text/html (because this mimetype is not registered for this content).
I really wish things were that simple! :-)
Just to get the idea, you can start here:
http://www.hixie.ch/advocacy/xhtml
(the URLs inside are more than worth a read too!)
However, dillo doesn't recognize this mimetype and always tries to save an application/xhtml+xml file, though it can always be rendered as html. The current workaround for dillo and other browsers is just send text/html but since standards compliance is very important for dillo I would suggest treating application/xhtml+xml as though it was text/html for the time being. (or at least until the CSS support is complete).
Thoughts? Ideas?
Yes, the above-mentioned links.
To save you the agony of understanding it all, I'd say:
* It's incredibly easy to allow Dillo to treat xhtml as html, but it's against the xhtml standard spirit (well, if something of its point still remains. :-)
* I prefer not to allow the official Dillo to do this out of the box until at least some validation tailored to xhtml is in place. Remember, the UA is expected to do validation. The bug meter does this, but with the HTML4.01 spec in mind. It would require an XHTML mode.
Given the current priorities, that day seems far away. Now, having an rc option like "treat_xhtml_as_tag_soup", could do the trick in the meanwhile, but only if someone goes through the above-mentioned links and convinces me that's there's no point in not having it. :-)
I will not try arguing the point. While I believe that there is a very good reason to want to do this from a user perspective (eg. you can migrate to xhtml now and not 10 years from now) I also understand there are plenty reasons not to. You probably have a much clearer point of view on this. Though the article you linked lacked one reason to use xhtml, namely it's really clean to write. :-) I've been thinking about UA parsing to determine doctype but I've always considered UA parsing pure evil so will probably not do that. Have I completely missed it or is there indeed no standard way for a webserver/site to determine browser capabilities? greets, wim
On 9/11/05, Wim De Smet <kromagg@gmail.com> wrote:
I will not try arguing the point. While I believe that there is a very good reason to want to do this from a user perspective (eg. you can migrate to xhtml now and not 10 years from now) I also understand there are plenty reasons not to. You probably have a much clearer point of view on this. Though the article you linked lacked one reason to use xhtml, namely it's really clean to write. :-)
While it may be, if you try to integrate it into other technologies such as Javascript, the article points out you have a headache and a half waiting to happen. I've read it. The service I oversee is sticking with HTML 4.01.
I've been thinking about UA parsing to determine doctype but I've always considered UA parsing pure evil so will probably not do that. Have I completely missed it or is there indeed no standard way for a webserver/site to determine browser capabilities?
Other than what the web browser asks for in terms of MIME types, not really. -- Kelly "STrRedWolf" Price http://strredwolf.furrynet.com
participants (3)
-
Jorge Arellano Cid -
Kelly Price -
Wim De Smet