The first website I created had a nice set of frames and was probably done in some version of HTML without a DOCTYPE. Later I learned about XHTML and semantics and the frames were removed with some CSS. Before Arthur (blogline) and I switched to XHTML we had some debates on what we wanted to use and how to remain backwards compatible.
We wanted to found out if XHTML worked on every platform and how many versions of our website we had to create in order to be compatible with every single website. A version in text, a version with frames, a version without frames, a version with frames and Flash and perhaps even a version without frames with Flash. Since we were badly informed and read books that stated that XHTML was just a step between HTML and XML we wondered why we couldn't use XML directly, transform that with XSLT into XSL-FO and display it in the browser. (I'm not sure if we knew the appropriate terms back then, but we did know about some XML styling language as opposed to CSS, which was according to books quite similar only more advanced…) Obviously that wasn't possible and Arthur couldn't live with the idea to ignore Netscape 4 completely, dump Opera and older versions of Mozilla and Internet Explorer. (At that point we didn't know CSS was the only way to style things. Even in XML.)
Eventually, when we heard the "XHTML story" about being backwards compatible with a single version we were sold (and badly informed) and started working on projects.
Now, we are using HTML again.
mozilla and internet explorer both support xslt, but opera still don't support it.
and even mozilla dont support xsl-fo if you transform the xml with xslt to html, it works fine in mozilla and internet explorer.
XSL-FO became a W3C Recommendation 15. October 2001.
and XSLT became a W3C Recommendation 16. November 1999.
I import client-side my xml with xmlhttp, and that works fine in all modern browsers. (opera 7.60)
but if all browsers support xslt, i switch again to xslt.
why cant the browsers support xsl?
that language is a recommendation for a few years.
Well, there was an evolution. Your personal approach to building websites has really evolved. And there's a huge difference between the HTML you write now and what you wrote when you first started.
Vive l'evolution!
Heh, it didn't take long till somebody made that comment.
XHTML is an XML application which has to be valid. The XHTML DTD doesn't allow presentational elements.
So: valid XHTML is always well-formed AND presentation and content are separated. For me that's an important reason to use XHTML instead of HTML.
Two questions Michiel:
If they just had known the beauty of:
if (strpos($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml')) { header('Content-type: application/xhtml+xml; charset=UTF-8'); } else { header('Content-type: text/html; charset=UTF-8'); } It’s so easy... and no need to have a separate version for older browsers.
I think HTML should never have been as lax as it currently is, validation-wise. Actually, HTML should have been like XHTML in the first place :). If I create a C++ program and I forget a ;, it won’t compile. I fix it, and then it does.
Now C++ is a complicated language, but XHTML is not. Fixing an error in XHTML is easy. Just place that closing tag you forgot. Just nest those <b> and <p> tags properly. Just escape that ampersant.
And as far as dynamic content is concerned (which can be a little more challenging in some cases) – everyone is using CMS-es and pre-fabbed forums anyways. If HTML had been like XHTML from the start, those CMS-es and forums would produce proper, validating code, and there would be no problem.
But, no crying over spilt milk, I guess. I’ll just go and be happy in my little XHTML application/xhtml+xml corner. With the abovementioned header modification for older browsers. And hope other people start using XHTML as well so that I can use XPointer when they haven’t specified an ID for me to link to :).
~Grauw
p.s. I also hope everyone who doesn’t use Unicode yet will get a vision of bright white light which tells them to do so.
*curses the preview showing his <pre> block properly and the final post not doing so*
What I meant was:
if (strpos($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml'))
{
header('Content-type: application/xhtml+xml; charset=UTF-8');
} else {
header('Content-type: text/html; charset=UTF-8');
}
p.s.3. what about generating a pdf version of the documents on the site with xsl:fo? You may not be able to use xsl:fo in browsers (and imho, you shouldn’t want to, because I like CSS ;p), but you can use it elsewhere.
p.s.4. Dude, that post validation thing is a nice way to deter both comment spam and people not knowing what they’re talking about... :) (too bad it won’t deter me, of course ;p).
~Grauw
In theory HTML must be valid. But where browsers don't hesitate to display HTML pages with missing tags, XHTML browsers will do so. So practically speaking HTML doesn't have to be valid.
The center and font tags for example are, while deprecated, presentational elements which are allowed in HTML.
Michiel: The biggest problem with HTML is actually not whether it is as strictly validating as XHTML is (even though I might like to see so), the problem is that it doesn't define what to do when a page is invalid. At all. So UA's are left to create their own solution, which exists since the beginning of the web all the way through Netscape Navigator and IE, and now is a crime to work out in an compatible manner when you want to create an HTML browser today.
About that other thing you mentioned - HTML 4.01 has, just like XHTML 1.0, got 3 versions: Strict, Transitional, and Frameset. In HTML 4.01 Strict, <font> and <center> are not allowed (as they are deprecated, it says in the spec with big letters ;p). In XHTML 1.0 Transitional, they are. Some people like to speak of XHTML as XHTML Strict and HTML as HTML Transitional, but both exist in both standards, really.
~Grauw
Just use xml or xhtml for the text
css for the styling (colors, width, ...)
and javascript for the dynamic functions
and all can be valid, and you can be happy!
you don't have to use the font and center tags.
for that function there are css functions
it can be html or xhtml, it is just the browser (e.g. mozilla) that can handle real xhtml faster than text/html
And if you use all in other files, you can better find some if you would change some, and your browser can handle it faster.
so normal html is bad, because the browser isn't strict, and must find out more ways, and that isn't needed!
html can be used, but there are better ways to make a website, that is better for your browser.
if your website is xml based, you would see it if your website is valid, and it wouldn't try to make some of it. if you would program bad, with xml based way, your website would go down, and you know that the code is bad. now are there many websites that are bad, but nobody knows it.
try some websites to valid it, and looks how many websites aren't valid.
(i hope you understand my english, yes it is verry bad, i know it!)
Why always ask the question: is XHTML more strict then HTML, and let it be vaguely answered? Just go and find out wheter there is a strictly defined SGML spec on which the HTML specification is based. Then consider which of the two has best extensions/uses/tools (HTML DOM v.s. XML DOM 1, 2 and 3), and then choose the best. And after that there has to be the real-life decision: does either HTML or XHTML fit my or my customers wishes and requirements best? Thank you.
if your xhtml strict is text/html, it is like strict html text/html
but xhtml @ application/xhtml+xml isn't like strict html
but why use html? you don't need the old tags from html, if there is css!
i think it can be both html and xhtml, but i think that application/xhtml+xml is the best way to go, and there is the only sad old IE that say you must use text/html, and if you say it is valid html or xhtml, that don't not matter.
but if IE can read application/xhtml+xml, i think that that is the best to do.
I know that my website isn't xhtml to, but it is just text/html, and it is valid like xhtml.
soon i have a application/xhtml+xml version to.
the index.html for the html version, and .xhtml for application/xhtml+xml.
(yes, my page is 100% client-side, the rss to :D )
a customers don't care about if it is valid, but the browser ;)
XHTML has to be well-formed, unlike HTML, or user agents are forced to abort parsing. It doesn't have to be valid, although there are compelling reasons for making it so.
XHTML is no more strict in any way than HTML4 with the corresponding DTD. You seem to be confusing strict doctypes with XHTML.
As long as there is virtually no real support for XHTML, it's far better to use HTML 4.01 Strict.
I don't say that xhtml is more strict than html, but a good browser like mozilla can handle xml better than text/html. (html or xhtml)
And so if xhtml handle by xml like application/xhtml+xml, is better than text/html.
And if you say your text/html is valid html or xhtml, i don't care.
I think that IE is to old for this days.
Michiel: XML validity is overrated. The light version of Macsanomat, for example, works just fine even though it is DTDless, which makes it, by definition, not valid. The browsers don't use validating parsers, so they do not care care whether the document is valid or has a structure that would be equivalent to valid.
check the w3c validator:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.macsanomat.fi%2Flite%2F
No DOCTYPE Found! Falling Back to HTML 4.01 Transitional
Doctype: XML
Content-Type: application/xhtml+xml
Henri you're right. Browsers don't validate. But the W3C (X)HTML checker does.
I think that in the not-so-far future the semantic web will become reality. And that's when not only well-formed, but also valid XHTML will become very important, because then there must be consensus about what kind of information elements can have in them - I doubt this is good English...
Does this sound reasonable?
No DOCTYPE Found!
Well, obviously. I said in the document was DTDless.
You can still use the DTD override.
Browsers don't validate. But the W3C (X)HTML checker does.
By the way, the W3C validator is an SGML validator. It does not check all the XML validity constraints.
I think that in the not-so-far future the semantic web will become reality.
Maybe. Maybe not.
And that's when not only well-formed, but also valid XHTML will become very important, because then there must be consensus about what kind of information elements can have in them
Like I said, sensible element nesting and use of attributes is important. However, taking the additional step of meeting the definition of "Valid" as defined in the XML spec is not that important. You could assess the permissibility of element and attribute use with a procedural linter or with a Relax NG validator—without including a doctype incantation.
On the other hand, validity according to a DTD does not imply specification conformance. As a trivial example, validating against a DTD does not involve checking that the attribute values are of the form permitted in the spec prose.
I think HTML should never have been as lax as it currently is, validation-wise. Actually, HTML should have been like XHTML in the first place :). If I create a C++ program and I forget a ;, it won’t compile. I fix it, and then it does.
C++ is a general-purpose programming language that can create pretty much any application imaginable. HTML is a language for marking up web pages, originally designed for sharing physics papers over the Internet. They are different languages with greatly different purposes.
And as far as dynamic content is concerned (which can be a little more challenging in some cases) – everyone is using CMS-es and pre-fabbed forums anyways. If HTML had been like XHTML from the start, those CMS-es and forums would produce proper, validating code, and there would be no problem.
If HTML had been like XHTML from the start, there would be no CMSes and forums, because the only people using XHTML would be physicists sharing papers over the Internet.
Perhaps we need the compiler-like strictness of C++ to enable visionary things like the Semantic Web. But you don't need that strictness to blog/share photos of grandchildren/check email/buy and sell stuff over the web, which is what 99%+ of people want to do. There is an "impedance mismatch" between the strictness of XHTML and the actual use cases for web markup. And until the use cases for XHTML become a lot more compelling to the average citizen, I don't see anything changing.
As long as there is virtually no real support for XHTML, it's far better to use HTML 4.01 Strict.
I use XHTML on my website, Anne does too. It is supported perfectly well. It's true that IE and other legacy clients don't support it, but that's what the content-accept header is for, and why XHTML has been designed to be accepted as HTML on those clients. Mozilla, Opera and Safari all understand application/xhtml+xml.
Evan: I've heard the 'if HTML weren't lax, there would have been no internet like there is today' argument before, but I just don't buy it, sorry :).
Writing valid/well-formed code isn't hard, if your developer tools let you know about such errors. I don't see why some people think it is. CSS is stricter in its validating than HTML is (if you forget a ; or write a rule improperly, the property or the entire rule won't be parsed), and I've never heard anyone complaining about that. Because it's no big deal to write valid code. The only reason why so many pages are invalid is because the browser, the main development tool people use when creating pages, does not give *any* direct feedback on validity.
~Grauw
What I'm saying is: if I didn't have my browser checking my XHTML for well-formedness, I would be making just as many errors as everyone else. And while working on the code of my pages, that checking is a *help*, not a bother, because it will help avoid strange behaviours and keep everything tidy.
~Grauw
The only reason why so many pages are invalid is because the browser, the main development tool people use when creating pages, does not give *any* direct feedback on validity.
That’s correct, but one notable exception exists: iCab for Macintosh.
If presented with an error-free web page, iCab shows a green smiley icon in its browser toolbar. If the currently shown web page contains errors, the icon will show a red frowning face. This is a fast and simple aid to developing valid HTML.
Note that iCab is not a validating user agent: Its error report is indeed a report of errors that occured during parsing – i. e. it is really a report of what iCab thinks are errors. Because iCab’s support for HTML is outstanding, this is usually not a problem, but of course only a real validator can be the final authority.
(The current stable version has an incomplete implementation of CSS 1 and no implementation of CSS 2 and as such is not very impressive, but the current internal Betas are a lot better – in fact, the support for CSS 2 is at least as good as Gecko’s, probably better.)
That iCab things sounds hopeful. (I mean the beta versions, obviously, I heard about the outstanding support for HTML and some CSS 1 support before.) I hope you mean CSS 2.1 though.
Arne: wow, better CSS2 support than Gecko, you realize that that is a very bold statement, don't you!? Anyways, iCab has an awful 'Apple' sound to it, meaning that I won't be able to use it :(.
But, I wish more browsers would implement such a simple validation system.
~Grauw
iCab's CSS support is nowhere near Gecko. The box model isn't even nearly right on complex pages.
Anne, iCab 3 is designed to use CSS 2.1, but also implements CSS 2.0 and CSS 1. This implies that in cases where these specs differ (e. g. the clip property or the !important statement) CSS 2.1 is followed. In iCab 3.0 there will not be any noticable support for CSS 3; I expect that’s planned for a later version.
Henri, I was and am referring to iCab 3 Beta 216, which is not yet publicly available. I expect you’ve meant one of iCab 2.5–2.9.8, for which your statement alas is doubtlessly correct.
(By the way, there is not yet a release date for the first public
beta versions (public
means that they will be available to registered users of iCab), but my personal expectation is that some time during the next few months is not unlikely.)
Laurens, you can trust me when I say that we were very surprised at the result of our CSS browser–support comparison. Before this evaluation, we expected Gecko to be by far the best rendering engine, but our findings indicate that actually Gecko is better than KHTML while Opera is better than Gecko and iCab 3 will be better than Opera. We tried to keep the comparison fair as much as we could, but since it was intended to be an internal development aid instead of a public resource, it may well be misleading. As you probably know, conducting a comparison of CSS support in browsers is a fairly time-consuming task because of the large number of property value kinds etc.; we avoided testing all and everything for simplicity. At any rate, the result at least indicates that there won’t be a reason for iCab to hide in a closet anymore. :-)
To give some examples of stuff that doesn't seem to work at all in current release versions of Gecko:
display: marker
display: compact
content: counter(…), counter-increment, counter-reset
font-stretch
<col>
(It is probably not necessary for me to emphasize that these comments are not meant to debase Gecko in any way. Gecko is not only a very good rendering engine, but was also the very first rendering engine to be very good
, and I’m looking forward to both the further rise of its market share and its rendering engine’s improvements in the future.)
You are aware that display:marker becomes redundant quite soon and will be replaced with ::marker of which already some dubious patch is available on bugzilla.mozilla.org? (Implementing it with a prefix, obviously. This patch addresses the counter properties as well.) The other changes look good though, although I believe Mozilla has support for font-stretch, just not on the Mac.
Here are two links to quite extensive CSS support charts by ‘MacEdition’, which I always find very useful (although I guess they’re not 100% up-to-date):
MacEdition Abridged CSS2 Support Charts
MacEdition Guide to CSS3 Selector support
When I look at these charts, Tantek’s Tasman 1.0 engine (MSN for Mac OS X) kinda makes me drool... ^_^. Too bad it’s only available to MSN subscribers.
I believe you if you say that iCab has better support for CSS2.1, but I am wondering about the comparison... I mean, have Gecko, Opera and iCab all implemented the most important and widely used CSS2 stuff, and are the tags where some gain can still be made all a bit obscure ones? (note that I do not think content: counter() & co. are obscure, it amazes me that Gecko doesn’t support that yet).
What if you include CSS3 as well? Stuff like attribute selectors, the > descendant selector (I think the best and most useful addition to CSS3), the :not() selector...? And if only there were decent browser support for :nth-child() & co., that would be awesome, sigh...
Anyways, iCab being for Mac OS X, it obviously has support for the very-fancy text-shadow, eh... Hmmm... In any case, it must be wonderful being able to work on a cool CSS engine like that :). Standards are cool...
Oh, and Anne, I don't think Gecko has support for font-stretch... Take a look at this test case. Maybe you’re confusing it with letter-spacing.
~Grauw
Laurens, you are right. A simple search and I would have known… However, > is a child selector and part of CSS 2.1.
Arne, if you are one of the testers, please use the test suite from Ian Hickson and file bugs.
Arne Johannessen - do I take it you mean font-stretch does work in iCab? I've been waiting for that for years!
As for CSS3, Opera already includes some of it, stuff like media queries, which is really useful. (Set your layout depending on the screen size!)
Evan: I've heard the 'if HTML weren't lax, there would have been no internet like there is today' argument before, but I just don't buy it, sorry :).
And I've heard the "if only HTML had been like C++ from the beginning, we wouldn't be in the mess we are today" argument before. With all due respect, I disagree with that as well. :)
That argument falls apart for two reasons:
The theoretical reason: There were countless non-programmers -- grandmothers, fishing enthusiasts, poetry majors, activists, movie buffs -- who got started writing HTML code when the web started taking off in 1993/1994/1995. We might think that closing all your open tags is easy, but trust me, for non-programmers, it really isn't. When you're not a geek, and you just want to put up a few paragraphs and images about your favorite recipes, it's just frustrating and tedious and totally unnecessary.
The practical reason: Everyone says XHTML is easy. I believed that myself for a long time, until I actually tried collecting the evidence. How many large commercial sites (with legions of expert C, C#, Python, and Java developers) are XHTML? After XHTML has been out for nearly five years now? Zero. There isn't a single one.
If XHTML were easy, there wouldn't be roughly sixty XHTML sites. There would be millions. No matter how easy we think XHTML is from a theoretical standpoint -- and I have a hard time believing it too -- the actual evidence from the real world could not be more to the contrary.
Anne: ouch, of course, > is CSS2.1. Stupid me.
Evan: I think there are several reason why XHTML is used by so few. To name a few important ones:
Note that the first four of these problem areas would (obviously) not exist if HTML had been XHTML from the beginning. Note as well that this is just wishful thinking on my part and that that doesn’t change the reality :).
On a side note, claiming that XHTML is around for 5 years already is kind of nonsense of course. You’re dependant on browser support, including support for linked technologies such as MathML e.d., and the actual existence of such technologies which make adopting XHTML worth its while. Additionally, from my point of view only ‘recently’ XHTML is gaining a some popularity. Also, there is apparantly an inherent reluctance to adopt new technologies, largely also stemming from ignorance... I mean, look at Unicode, and how many pages are actually using it, they are rediculously few while the advantages are obvious (development tool support is also an issue there, btw).
Overall, I’d say especially for commercial sites the transition to pure XHTML is hardest, so that would definitely not be the area where XHTML adoption will early, as you seem to claim. This because they often have very extensive sites which are glued together from a number of different systems, often old, and stuff like XHTML has a priority of 0 on the manager’s list either. ‘If it works, it works’.
Now, to look at the bright side of the story, I work at a company where we are creating a product with which existing web-pages can be extended. It will only work with XHTML, mainly because we need a solid DOM tree and we like standards :). This means that every site using our technology must be using XHTML, which means that there are already a couple of corporate sites out there using XHTML, and there will be more as more corporations and people will use our product.
Well, I think that’s about all I have to say for now :).
~Grauw
Sorry Laurens -- by "legions of experts" I simply meant that large sites have full-fledged programmers that are capable of understanding a strict language syntax -- even if they don't "get" strict (X)HTML/CSS yet. I was being a bit glib there, my bad.
I just want to reiterate that the average person is not trying to do anything all that spectacular with their client-side markup. People want to post text and images and maybe submit HTTP POST or GET data every once in a while. And I don't think it's a bad thing that our current web infrastructure makes this very easy for even total novices.
What XHTML needs is more use cases -- use cases that are technically advanced enough to require XML's strictness. We know of a couple such use cases, but XHTML needs a lot more.
Evan, you act as if your list was a repository of links to all sites that would satisfy the selected constraints. Has it ever occurred to you that you are unknown to more than 6 billion people in this world? Next, why would the remainder even bother to participate in this list is beyond my comprehension.
What XHTML needs is more use cases -- use cases that are technically advanced enough to require XML's strictness. We know of a couple such use cases, but XHTML needs a lot more.
Actually, Evan, I agree wholeheartedly with that :).
~Grauw
Evan, you act as if your list was a repository of links to all sites that would satisfy the selected constraints. Has it ever occurred to you that you are unknown to more than 6 billion people in this world?
Darn, and here I thought my wild parties with Madonna and David Beckham were finally starting to pay off in global notoriety...
Turning on application/xhtml+xml is a very weird, obscure, and let's face it, technically risky thing to do. It is doubtful that anyone would spontaneously decide to do this without first reading any of the massively self-referential literature on the topic. Which is why although the X-Philes are an underestimate, they're not off by more than an order of magnitude.
But if you have evidence to the contrary, Moose -- if you are keeping some massive treasure trove of bulletproof XHTML sites under your hat -- please do feel free to share. Otherwise, please drop the histrionics and personal insults. Thanks.
Laurens, when you say you need XHTML in order to get a solid DOM tree, do you mean you require application/xhtml+xml? How is the HTML DOM not "solid"?
Henri, HTML is forgiving towards errors, which we can’t have, because when the code is not tidy different browsers will get different DOMs for the same document (as error handling is not defined). That aside, it was only one of the reasons why we chose XML over HTML.
We do not exactly require the ‘application/xhtml+xml’ MIME type (actually, at the moment it won’t work when doing so), but the documents are read with the browser’s XML parser, so in practice they must be well-formed or the browser will complain.
In addition to that, our product is modeled as an extension ‘the XML way’, so all added features reside in a different namespace. That is also a reason why we need XHTML.
~Grauw
Laurens, when you serve XHTML as text/html the tag soup parser with inferred HTMLisms and HTML DOM are used. There's no benefit over building the DOM from valid HTML. With valid HTML the browser differences are limited to comment nodes and white space text nodes and using XHTML as text/html does not remove those differences. The point about error handling is moot, because XML error handling is not applied anyway.
Re: Comment 6 and 7, Laurens Holst
You will send invalid Headers:
Accept: text/html;q=1,application/xhtml+xml;q=0,*/*;q=0.1
See this check for a better solution.
Henri, I think you did not read my post properly:
the documents are read with the browser’s XML parser
In other words, this is not ‘moot’, as the browser *will* generate a big error and fail to load the page when a document is not well-formed.
~Grauw