Xhtml Is Not Suppose To Be Text/html IE not planning to support XHTML yet

I am quite disappointed in IE's development as with keeping up but still if they feel they need to fully work on current things that they have already attempted to resolve and perfect then that is a good thing, but development should have never got so messy and only the developer would know that it's his fault and not MS's.

This isn't to bad mouth IE, but it's so sad to know that even after 5 years or more of IE6, IE7 has no intention of supporting XHTML and I don't think I can wait for IE8 if development takes such a long time. They should also realise that HTML will become obsolete but it would be IE who would be successful in making that happen rather than Web Designers/Developers.

So for this thread, XHTML is not just about changing tags and passing the W3 Validator, in fact the validator has it's limits and we know what limits it has, and we can rectify the situation.

I'm talking about XHTML 1.1, although this does apply to XHTML 1.0 Strict and most definitely would apply to XHTML 2.0 yet this is still in draft.

When designing your site, you should make sure you pass the validator, http://validator.w3.org/ (you should check most those check boxes for this test).

But that's not all, to be 100% compliant the mime-type that an XHTML document must pass is application/xhtml+xml , in XHTML 1.0 they let it slip by for text/html but only if compatibility was the issue, however you should if you can send application/xhtml+xml to User Agents who can parse XML and as a backup send application/xml or text/xml or as a last and final backup text/html but eventually it will need to be resolved.

I hate trying to fight for standards against people who believe they follow standards, I don't know how many web developers/designers have read nearly every document in W3C, I know I haven't read everyone, but I've read most of them related to HTML, XML, XHTML, CSS, XSL/XSLT and even this effort I have taken to has already surpassed most web designer/developers, so I rather not fight and just let people know that it's how the standards were set.

If you understand this, then you'd probably want to know the advantage of XHTML 1.1 application/xhtml+xml.

I have to say the biggest advantage is "well-formed", it's forced upon you, you make one mistake, it's not going to show your site, it will however show you the XML parser error and will not give you an excuse for making mistakes. This is what I consider the greatest debugging method I have when writing sites, as validators can not give this much power in validating.

Other advantages are you can make your own tags, elements, etc, you are not stuck in using HTML tags no more, you can make tags, styled to how you want, which means you can make better use of CSS if you wanted to as you could create tags for each and every instance, e.g. replacing <p class="copyright">Copyright © 2005.</p> with something that has better meaning for it. e.g. <copyright>Copyright © 2005</copyright>

There are many more advantages, but so much to explain. The main point is we're using data and making the data more appropriate and thus far more effective, especially for Search Engines and searches made.

The biggest disadvantage, the most used browser under windows does not support it. I heard though that same browser on Mac does, is that strange or what?

What we are forced to do with current situations is discover which browsers support it and work with them, we also need to know of other User Agents who definitely support it and work with them, there's so much of making workarounds for it, that I'm quite sick in the slow progress that has been taken to standards, these standards have been out for years now.

Thanks to Mozilla and Opera and the other browsers (Camino, KHTML, etc) who better support standards and know the importance of keeping up to date.

As for sending application/xhtml+xml

We have many methods, but we should not need workarounds, because I find I have to even work on the workaround to perfect it even more so here's the simplistics of getting it working inside PHP. Headers must be sent first, so make it appear at the top/start of your page.

<?php if(isset($_SERVER['HTTP_ACCEPT'])){$http_accept = $_SERVER['HTTP_ACCEPT'];if(stristr($http_accept, 'application/xhtml+xml'))$mime_type = 'application/xhtml+xml';elseif(stristr($http_accept, 'application/xml'))$mime_type = 'application/xml';elseif(strstr($http_accept, 'text/xml'))$mime_type = 'text/xml';}else$mime_type = 'text/html';header('Content-Type: ' . $mime_type);?>

This is only the basics of it, there's more since validators/search engines etc don't use HTTP_ACCEPT which means we must work on the HTTP_USER_AGENT instead which means sifting through hundreds and that is why I'm sick of not being able to just send application/xhtml+xml without blocking anyone from using it, even though I do feel like blocking IE just cause I can but that's not fair on my viewers.

I may build some test sites for those who want to test their browsers, it would be nice to get some feedback so I might also allow for comments to be made on that site. I will be collecting some information from the use of it however, nothing other than things that will help me better improve on supporting all browsers and then helping you share my results and fixes for it. I'll get back to this when I've completed that part of the site. I will show you plain html files (written in XHTML) that pass W3C, as well as errored html pages (won't validate at W3C) that still display in the browser when they shouldn't (this is because browsers love to fix your problems instead of telling you there's a problem), in xhtml it will be same, but this time instead of the browser fixing your problem, it will tell you! That way you will be a better developer/designer knowing that if you met "well-formed" documents then no doubt you have made the effort to be error free.

Give me time as I'm still trying to see if I can edge on the developer for IE to try for supporting this mime-type yet it seems there's too much to "hack" that it's best to not touch it when it's near releasing.

I understand that people don't want a messy hack, well if they paid attention, he already messed up (if you think this is just a lie, I can point you to sources of him admitting it) and that's why IE requires a rewrite in that department, so messy hack or not, it was already a mess.

There will no doubt be a patch to work with this, I even considered writing one myself, but I felt unofficial patches and the fact that it infringes on something is not worth it, lets just get them to fix the problem themselves. Also to do this patch, it's not an easy task, so don't think I'm making it sound easy, it is indeed a lot of work.

So hopefully this will make you realise that standards are strict as hell, but well worth it.

http://www.w3.org/ - The only site that has it all. Although you should be quite technical as it's how they speak there and not for those who need basics, basics are left up to us to help you will fully grasp it and we will teach you correctly, or as correct as we understand those documents at W3C.

I do have to say though, it's due to us not following W3C as fully as we can that we messed up in the designing/developing side of things.

Cheers,


MC

I discovered the W3 site a short while ago, and since then it's really opened my eyes. I'd never realized there were standards that should be followed when coding a page, I just thought if it shows up right it's fine. Having read through many of the W3's rules and whatnots I've sorta "rebuilt" myself as a novice HTML Designer. When designing my sites I place a lot of emphasis on doing what meets the standards, not just what works. The W3 Validator has helped me a lot, it's an amazing error finder and a useful tool. I plan to switch my HTML->XHTML within the next couple months, and hopefully I'll find the change easy.It's nice to know that when I do make the change there will be people here ready to help. :mellow:Thanks, MC!

I never tried using Xtml I always use Dtml (If you want to have the H there its fine with me). Is Xtml as easy as D?

Killer008r; I would say easier, personally. Then again, I've been working with HTML and XHTML for a bit of time, and I've oriented myself with the markups.

 

mastercomputers; you've got a point... The standards seem to continuously change, and it gets harder to meet such stipulations. However, I don't mind the challenge and I actually don't mind I.E. - however, that's just me. I also haven't tried FireFox, which apparently is also a good browser...

 

In any case, since I found out about the W3C, I have made attempts to "standardize" my site, and I can certainly say, they have been successful attempts (I just validated my site again - yes, I checked all the boxes - even though I've done it many times before)!

 

When the time comes where it will be necessary to update my markup, I shall do so. When the time comes that I will simply require a whole new markup, I will do so. That's when the time comes!

 

Here to help,

HTML_Guru

-->MC:

Regardless of the fact that there are things on which I agree with you, and things on which I don't, I still can't grasp the point of your point. Are you trying to say we should be more active in enforcing Browser Makers (User Agent Makers, in W3C lingo) to adhere to the standards? I can see you talked about many things in your post, but still I don't understand how the subject "Xhtml Is Not Suppose To Be Text/html" is related to them.

 

Anyway, I've actually been too busy to keep up with the IE7 pre-release info, so I first learnt that IE7 is not planning to incorporate the XHTML MIME type from your post. Are you sure about this? I'm going to have to see how Microsoft explains this. It's too weird, considering their Office package has been supporting it for quite a long while now.

 

One thing you said struck me as rather selfish (sorry ). It seems to me that you think User Agents make a big mistake when they display a badly-coded source. Well, of course this makes the lives of Web designers that much harder, but in most conditions, it's a pretty good thing for the page viewers. I do agree with you, though, that the User Agents should alert the viewers more conciously about the errors; at least so that technically-oriented viewers know if they're missing something important.

 

-----

 

Also, I think it's wrong for us to think of XHTML as an extension of HTML. Yes, they share the same parent (SGML), and they have loads of tags in common, but still, I think XHTML should be viewed as an independent language, if one is to understand and make the best of it.

 

I think our role - as people who think W3C recommendations are important - is to keep talking to User Agent Makers. If they see enough demand, they'll respond. Not out of courtest, but it'll be their they'll try to protect, then.

The part you think selfish, is not at all, I'm not saying it's not a bad mistake because it's covering our own *bottom*, but unless designers learn to clean their code, make sure it works, go further than just viewing it in a browser then they've done enough, having the browser correct our mistake (designer/developer and not end user) might make us think our site works fine, however since there is no standard method for how browsers can handle errors, we will get totally different results across browsers, that is why it is better to not have errors than to mask them. W3C also recommended how errors should have been handled, yet it never defined how conforming users agents handled general error conditions.

 

The key line I like to point out would be: We also recommend that user agents provide support for notifying the user of such errors.

 

However we were also told not to rely on this and I also agree. Have you ever had a user agent point out errors in your HTML 4.01 documents? On Firefox I can have this if I install the Tidy Extension. On Amaya browser, I can not get into a site that doesn't conform to it's detected DTD without fixing those problems, I can get into some sites that have minor errors, but I've got Tidy in the bottom corner of it notifying me of problems with the page.

 

If I want to put that into a story:

 

Say we're at an Ice Cream Parlour, we know they do ice cream but we want to know if they do milkshakes. If it's not pointed out to us then obviously we're going to ask them.

 

If we looked at this as a web browser, we know they render web pages for us. If it encounters an error, are we to ask the browser if such an error exists?

 

The point being, if it's not pointed out, then how do we know it even exists?

 

All the ice cream parlour needed, instead of being asked was a sign advertising milkshakes. All a browser needed us to do was inform us of the error, now this does not have to be given to us in a message box but if you use the Tidy extension, that's a nice way of knowing there's problems. As with the ice cream parlour needing a sign, it may have had one, yet we found it difficult to find. Maybe this is the case with many browsers? I've never really looked indepth to that extent.

 

http://www.w3.org/TR/html4/appendix/notes.html%23h-B.1

B.1 Notes on invalid documents

 

This specification does not define how conforming user agents handle general error conditions, including how user agents behave when they encounter elements, attributes, attribute values, or entities not specified in this document.

 

However, to facilitate experimentation and interoperability between implementations of various versions of HTML, we recommend the following behavior:

 

    * If a user agent encounters an element it does not recognize, it should try to render the element's content.

    * If a user agent encounters an attribute it does not recognize, it should ignore the entire attribute specification (i.e., the attribute and its value).

    * If a user agent encounters an attribute value it doesn't recognize, it should use the default attribute value.

    * If it encounters an undeclared entity, the entity should be treated as character data.

 

We also recommend that user agents provide support for notifying the user of such errors.

 

Since user agents may vary in how they handle error conditions, authors and users must not rely on specific error recovery behavior.

 

The HTML 2.0 specification ([RFC1866]) observes that many HTML 2.0 user agents assume that a document that does not begin with a document type declaration refers to the HTML 2.0 specification. As experience shows that this is a poor assumption, the current specification does not recommend this behavior.

 

For reasons of interoperability, authors must not "extend" HTML through the available SGML mechanisms (e.g., extending the DTD, adding a new set of entity definitions, etc.).

 

So the thing is, since there was no means to tell them how to correct HTML or problems encountered, XML/XHTML was made different, they told them how to handle these errors and there was no excuse to not handle it their way, although I know a few browsers who still insist on fixing those errors and blatantly ignoring W3C's recommendation.

 

Unfortunately, W3C is not a Standards Authority, the attitude towards them could be "He's not my father, he can't tell me what to do" and that is true. They can't, nothing they've said is a Standard, they are only recommendations and some people can not put in the effort to learn it, infact it's a huge learning curve and I've still got lots more to learn from it, but if I can share what I know already and make it easier on those who are still learning then that is fine.

 

As for IE, they don't support applications/xhtml+xml, application/xml or text/xml and should not be compared with their Office Suite. I'm not sure how MS developer's work, but I think they each have their own projects, and only offer little input for different projects.

 

This thread however was to support W3C and what they asked for, XHTML 1.1 and mime-type: application/xhtml+xml this however is not what they're getting. This is my attempt to point out something that does exist but is not made obvious, similar ice cream story.

 

You must realise that if mime-type is application/xhtml+xml, it's formatted differently (mime-types lets the User Agent/Programs etc, know what type of content they can expect so that the program can use appropriate means to handle the data), it's no longer using the HTML renderer but the XML Parser, there's a huge difference in handling, but almost similar output if keeping to traditional tags.

 

Using HTML to handle XHTML is incorrect, there are huge differences in the two Mark Up language that being XHTML 1.0 the compatibility, and XHTML 1.1 being the move away from depreciated and obsolete elements. If I were to write solely in XHTML with my own tags and tried to use text/html to display it, I'm bound to have problems with weird displays, since HTML had no means of notifying errors and when encounter, did it's own thing. We don't want it trying to even attempt XHTML if it doesn't support it, so I have to detect every browser/user agent and correct it, by making sure that I send XHTML to those browsers who support it, and another page in plain HTML to those who don't.

 

I should also add that this slow down in the major browser market is a bad thing for us, the standards haven't altered dramastically that it would be a lot of work for the developer, the standards have been released for over 2 years (that's long enough as it is), but what would the point be in learning these standards if we must wait 4-8 years before we can fully make use of them?

 

In the business world, they are moving to handheld devices yet I feel I'm going back to history where I must make certain browsers can handle things, e.g. we had to detect if they could use javascript, we had to detect flash, etc I thought the times for detecting what people used were over, but this is not the case. I remember writing sites to detect browsers, and displaying them pages that would render correctly with them, then after doing so was wasted when browsers started standardising themselves, I'm glad the browser war is over (IE did not win that war if you wanted to know who won, they claimed the market afterwards with integration), but the war against the browsers isn't over. I spend more time on finding out what browsers know and don't know than producing my site. I just can't rely on any browser anymore. I could however go back to HTML and not make use of newer technology, but then when the change does happen, I'm further behind. By the time they do make that change, 4 years later or so, something else would have already replaced it.

 

IE should get out of the dark, we need them to make the moves else we might have "sites optimised for all except IE", "this site is best viewed without IE", sites being built, something I was hoping not to see arise again.

 

Cheers,

 

 

MC

I usually use Java-Script and Dtml in the sites that I make but lately I have been seeing how much I can do in Flash, and been creating some nifty Flash intros' and pages.

Well, Killer, this sounds good. If JavaScript, DHTML, and FLASH work for you and - most importantly - your visitors, then great. But you should keep in mind that XHTML is NEITHER a new technology like JavaScript and FLASH NOR a HTML alternative like DHTML. XHTML is the proposed substitute for HTML. It's not an add-on or an extension.

 

Like MC said, it's proposed to not only rectify, but basically eliminate the shortcomings of HTML. You see, HTML has gone over the years through so many modifications... many of them were forced upon by features that IE and Netscape incorporated in their browsers in order to dazzle their users. One would add blinking text, the other would add marquee or scrolling text. And since the W3C has no actual control over this process, it had to work with what already exists.

 

The proposed XHTML is all but a totally new approach. Sometimes I think of it as the first time the W3C truly has the initiative. And the best thing is, XHTML doesn't force designers to do something; it frees them to do whatever they want, in a way that's compatible with the all browsers. So it won't diminish creativity or increase control; it'll simply enforce consistency.

 

I think I now understand your point better, MC. Am I right?

That is the point to get "consistency" which is the same as saying standardised.Browsers have two modes, standards compliant and quirks. This is usually determined by the DOCTYPE being used. If there is no DOCTYPE it will be rended in quirks mode which could be based on HTML 2/3/4 etc, browsers didn't have to follow any DOCTYPE definition, however if they did base it on 2 there would be more problems encountered. However you could still have a DOCTYPE and it would be incorrect, in which case either a mix mode of standards and quirks or just quirks would be applied, again nothing to determine which to apply, it is browser dependant.Quirks mode was created for compatibility, since then that was when web desigers could do what they like and still have browsers render their site correctly or incorrectly, depending on every individual browsers method of handling quirks. This was so the majority of sites would still be able to be seen.I think we've lived in this mess long enough, that it's time for us to clean our act. If browsers only supported standards, web developers would definitely have to clean their act. It is this clean up that will take the longest and is why browsers do not go down this path. I am doubting ever seeing this change in my lifetime either, so instead of just "hot air" I will strive to guide web designers/learners into teaching them correctly by following standards.HTML 4.01 is a mess, XHTML 1.0 is still a mess but aimed to clean up it's act, XHTML 1.1 cleans up but still is messy, XHTML 2.0 again is another cleanup and I can say this is getting nearer and nearer to a cleaner markup language, yet few browsers support it. There is little in features being added to this language, it's all been a slow cleanup. The features that are added are external and seperate from it.However this is different for Web Browsers, they don't clean up that part, they refine it or they build on top of that mess making sure that backwards compatibility is still achieved. I understand the importance of having your browser actually work, but they could probably do more in teaching people correctly, and achieve that ability for them to move on. I don't know if you know this but IE in the browser war lost and then came up with integration however with IE5 I think, they had achieved around 90% support for CSS1 and literally blew every browser away in this respect, but once they achieved that market, it went downhill, they slacked off, and continued to be behind. While other browsers try their hardest to support standards, they can only slowly gather back that market. I am positive a big factor of this is the integration but none the less, the more compliant browsers, are not getting as much recognition as they should and are being attacked for rendering sites incorrectly when IE rendered them fine. I listened in on IE7's development and heard positive things, but then to be told XHTML was not even being considered shocked me. (rumour had it MS were going to ignore standards and work more with ASP and quite possibly their own Markup, big disappointment in web development as this was what standards were trying not to have). IE don't really have a roadmap to their development, you just tell them what they've missed and they either make it a priority or say it can wait. Now that they're nearing release, you can only point out what they are missing but more importantly bugs or issues they have and what was missed can wait till next round.Cheers,MC