If XHTML strict is more important to my client than legacy support , what browsers do you suggest I test in, to cover most of the market share?
Ii can’t think of any reason why browsers would keep the DTD in the cache - they’d keep it iin a separate area where it can’t be turned off since there would never be a reason to (since referencing a non-public DTD would be the way to access one that is subject to change).
Hm, that makes more sense. One of those folders like .dtd
It would still be a massive DDoS on www.w3.org since it would be at least one request per user per DTD. However, if we ignore the DDoS issue, it’s still an unacceptable performance hit to wait for a DTD before being able to parse the rest of the web page. Still, if we also ignore the performance hit, it’s still completely useless usage of network and processing since browsers are perfectly able to parse web pages without reading a DTD. The future compat argument is bogus since generalizing the parser is the wrong optimization – changing the parser is trivial.
Not to mention that DTDs can’t even express how a browser (or other general-purpose Web-facing HTML UA, e.g. search engine) needs to parse HTML in order to be compatible with the Web anyway.
Browsers usually ignore the DTD completely and use their own built in rules instead.
There wouldn’t be an issue with browsers actually using the DTD because they’d only have to read it once and could then keep it stored locally for all subsequent references. The suggestion that it would overload the server where the DTD is stored would therefore not apply since any one DTD would only ever be accessed once from there for each browser that actually used it. The browser could search its stored copies of the DTDs and would only need to download a DTD if it hadn’t already done so.
This would be like the way the browsers cache web pages except that as a given DTD never changes once it is made public there’d be no reason for ever downloading a public DTD a second time.
[FONT=Verdana]<ot>
I think you misunderstood what he was getting at; basically every (x)html document requires a Unique DTD URI. What he basically said was for every page that has a something like:
[/FONT]<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML Basic 1.0//EN”
“http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd”>[FONT=Verdana]
[/FONT] [FONT=Verdana]The browser would have to always request that file ‘xhtml-basic10.dtd’ at that EXACT Unique PUBLIC URI it wouldn’t be allowed a mirror.
But it doesn’t happen like that; as you are aware; browsers (usually) have localised versions of the DTD.[/FONT] 
</ot>
^unless you have lots of nerds like my colleague who, for whatever reason, has caching off.
My caching is set to a pretty low limit… at least once a week, plus whenever I’m trying to get a favicon to change or retest non-visited link colours, my cache, history, everything is wiped.
There isn’t one - that’s my point. Anything that can be done with embed can already be done with object so adding a new embed tag is unnecessary.
There may be a few less common browsers that support object that DON’T support embed but there are certainly none that require that you replace the object tag with embed in order to work.
Anything that can be done with embed can already be done with object in all the browsers that support embed as well as some that don’t support embed.
The only current complication with using object is IE6 and that problem is just about to go away and will be a distant memory by the time HTML 5 is finalised.
Sure object is more verbose than embed but that’s because it offers lots more options and more flexibility for the future.
That’s because the W3C expected that HTML would be replaced by XHTML given all of the added benefits that XHTML has over HTML. Abandoning XHTML splits the universe of documents into two groups - web pages and everything else. Adopting XHTML would have made web pages interconvertible with all other XML document types.
Then, whose fault is that when you get embarrassed? 
cheers,
gary
I edit my pages in a text editor. I upload them with an FTP client. I will often then check them in a browser, but if I’m only making minor edits then I don’t always bother immediately.
By XHTML STRICT I’m going to assume you mean 1.0 - since there is no reason to be working with 1.1 since IE doesn’t support it. I’m also going to assume you are writing code that follows the appendix C compatibility recommendations which means your page WILL work in most legacy browsers, EVEN IE – despite the wild “the sky is falling” claims of XHTML “not working” you’ll often see in threads like this.
You follow the compatibility guidelines, toss in a couple simple rules like “never declare a fixed width or height the same time as padding/border” and you can make your pages work off a SINGLE STYLESHEET (none of that IE conditional comment asshattery) all the way back to IE 5.5 with minimal effort.
You also have to remember that windows CE/Mobile handhelds only JUST got IE6 two years ago; IE 5.5 still being the majority of Windows Mobile handhelds and IE6 still totalling around a THIRD of IE users - which boils down to around 400 MILLION users. It takes nowhere near as much effort to support IE as people claim if they would just stop using broken methodologies in the first damned place.
There’s a reason I rained on that IE funeral malarkey from so high you’d think god herself had been pissing on it.
Which is why my testing list remains IE 5.5, 6, 7 & 8, Opera 9.6 (since Opera mobile users don’t upgrade as often as they should) and latest (10.53), Firefox 2 (since many forks/other gecko builds lag behind the main branch and some whackjobs still won’t upgrade to 3.x) and Latest (3.6.something - lord knows I can’t keep up with their one release every three days crap), and the latest flavors each of Safari and Chrome (which I’m a lot less dilligent about testing for legacy on)
Now, just because I TEST in those browsers doesn’t mean I obsess on the layout being perfect across all - the oldest on the list: IE 5.5 and FF2 - I generally only test that the page renders in a usable manner, not that it’s perfect. People still using 5.5 (like on mobile) or 5.2 Mac pretty much expect pages to be broken at this point.
But there is NO excuse not to have full IE6 support - and it’s NOT THAT HARD TO DO PEOPLE!!! Couple simple haslayout triggers, the occasional rare ‘zoomfix’, start out with a **** RESET, inline-fix on floats that have margins (or just pad the parent instead of margin the child!!!), position:relative to overcome some depth sorting issues, and you’re done. You get in the habit of coding with those in the first place once you know where they are generally needed, it really shouldn’t take any extra time.
Can you be more explicit? To my knowledge The box model was the only major miss-application of the standards. Even that was fixed in IE6 standards mode. Most problems in 5 & 6 came down to MSFT’s attempt to borrow hasLayout from their Office suite to implement a block formatting context. John Gallant and others managed to suss out what was going on and created a bunch of work-arounds, which the bug-fix upgrade, IE7 internalized.
Other problems were sins of omission; not implementing at all many of the css properties, that and a few html element tags.
IE8 has eliminated hasLayout, and expanded css and html4 support almost completely.
W3C rules require there be 2 implementations before adoption as a recommendation. Without doing some level of trials, bugs, differences, and gotchas cannot be effectively dealt with. I think the vendors have been responsible in their warnings of instability, and have generally done well promoting cross-vendor agreeance.
cheers,
gary
How would it happen that you’d release a page you couldn’t even view in your own browser? Once you get it right, it will stay right; it won’t spoil once it’s out in the wild. For the developer, it’s like automagically validating at every browser refresh. I’d call that a benefit.
A better approach to fault tolerance than the tag-soup-make-it-work-somehow method would be that of css; simply ignore any invalid syntax. Is there a block element inside an inline (excepting object ) element? Ignore it and its content. A wonky page would be feeble, but not dead.
cheers,
gary
Let’s hope that they all learned something from IE’s mistake so that does not happen again. I would think that all the major browsers are aware of this potential problem and that they will not jump the gun.
I’m not sure that that really counts as a benefit! I am punctilious about checking my code is valid, but even so, errors occasionally creep in, and I would much rather that the browsers had a good go at working out what I meant (which they invariably do a reasonable job of) rather than showing my visitors a YSOD and showing me up to be incompetent.
You are the only person I have ever seen on this forum who gives a wet slap about SGML. Correct HTML5 code follows HTML5 standards, as specified by W3C, who are the body who set standards for website coding. Therefore, as a believer in standards, I will follow those standards, which means I can use HTML5.
IE10 and possibly IE11 will be long gone before HTML 5 ever reaches the status of becoming a pseudo-standard.
Once all the browsers support XHTML then use of XHTML will really take off since there are plenty of developers who are only using HTML because of the lack of support in IE… One huge benefit that XHTML has is that the browser itself will detect any errors and refuse to display the page until you fix them (unlike HTML that will try to interpret any old garbage).
Since HTML 5 doesn’t follow the SGML standards those who believe in standards will ignore it. That will leave XHTML 1.1 as the latest standard for web pages until such time as XHTML 1.2 is developed or XHTML 2.0 reinstated.
So what are the main ie6 fixes and how do I implement them? Is there a fixed list, I want to do ie6 compat, I think its reasonable to expect really.
If you serve pages as text/html then you are writing HTML. It doesn’t matter whether you save it as .xhtml and make sure you close and self-close all your elements, what goes down the wire to the user’s computer is HTML. So you might as well have saved it as .html and not bothered with all those ugly self-closing slashes.
It’s only XHTML if you send it as application/xhtml+xml, and nobody in their right mind does that on the world wide web, because no existing versions of Internet Explorer support it.
oh well, cant please all the people “n” that.
<ot>
I assume you are making a joke; if you remember it is the “can of worms” you opened: http://www.sitepoint.com/forums/showthread.php?t=678703 
Really, there is no need to say you are using ‘XHTML Strict’ unless it’s for a specific piece of code sample you have issues with - it will just agitate people whether purposely or not - while that previous thread is still in people’s memory.
That is why you have been getting some shallow answers when you mentioned legacy browsers and what they can handle regarding the x-word.
I’ve just offered you some good words of advice for future reference.
</ot>