Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: incrediBILL
So practically, what does this mean? From what I've learned so far it looks like the jump from transitional 4.0 to strict 4.0 is a much bigger jump than going from strict 4.0 to XHTML.
Would it make more sense to go straight to XHTML? Looks like it's just a matter of writing strict HTML 4 and adding on a small handful of extra rules. Things like closing every element, for instance -- writing <br></br> or <br /> instead of <br> seems a little odd, but it's no biggie. Well, maybe I'll need to update my editor first.
By the way, I found a very simple tutorial [w3schools.com]. I can use the W3C for looking things up, but I have a lot of trouble learning something new there.
So what is everyone doing, or planning to do? Strict XHTML requires CSS -- so external stylesheets seems to be the first order of business. From there, it seems a relatively simple jump to strict XHTML 1.0. Am I right?
Above is just my interpretation, after a bunch of reading, converting a couple small (<50 page) sites, and building several new sites in it. My sense is that the small adjustments in coding practice, and the doctypes help browsers reduce the amount of guessing they have to do to render the page. (Think about the wide variety of html coding practiced, then try and picture yourself as a browser trying to render it.)
Go for it. There are a bunch of threads here on converting pages, etc.
There should not be a problem serving xhtml as html. Serving xhtml as xhtml is a problem with current browsers.
xhtml lets you steal all the content from a web site even more easily than you can at the moment. Great for winning over your boss. Who is probably using Netscape 4.x and so will only see a gracefully-degraded (i.e. terrrible looking) web page and wonder why Amazon can do good pages and his employees can't.
Its main benefit for a web site is that you can brag to your friends about how standards-compliant and browser-unfriendly your site is, and how none of your users know or indeed care as long as it works ;)
The xhtml 2 draft (not backwards compatible) is probably worth a read to see how ridiculous all this is getting ;) ;)
Its main benefit for a web site is that you can brag to your friends about how standards-compliant your site is, and how none of your users know or indeed care as long as it works
I totally agree and pleased you spoke up on the matter. However, I disagree in that I don't think the standards are ridiculous. I think they're a good thing and we should probably all do our bit to encourage it, it should make our jobs a whole lot easier one day, so we can concentrate on more interesting aspects of our work.
However, in terms of the real world, there is minimal pressure to be compliant or XHTML whatever. Check out all the big websites you can think of and validate their code, I doubt you'll find one without errors (including Google, Microsoft, IBM ..... and so on).
My next site will probably be done in strict XHTML but solely so I can add it to my CV.
Nokia, Motorola, Ericsson, Siemens and numerous other industry leaders in the mobile communications and content industries have today announced that they are supporting the XHTML markup language (Extensible Hyper Text Markup Language) as the format for the future evolution of mobile services.
This is an old article I think as it isnt date stamped.
Has anyone had experience with mobile devices and XHTML, as I have a possable free lance project coming up which could involve palm pilots and other wireless devices.
All current browsers handle xhtml. Xml is a whole different (larger) subject, it is used in word processors, financial software, etc, etc.
I try and avoid the arguements and oneupmanship, neither is useful.
I recently took a sample page from a large, pr8 site and redid it as a demonstration in xhtml and css. It looks identical to all but the most trained eye, and is half the size of the original. That will buy you several places in the SERP's, which is why I like the combination of css and xhtml.
XML specifies neither semantics nor a tag set. In fact XML is really a meta-language for describing markup languages. In other words, XML provides a facility to define tags and the structural relationships between them. Since there's no predefined tag set, there can't be any preconceived semantics. All of the semantics of an XML document will either be defined by the applications that process them or by stylesheets.
>Ok I must admit that when it comes to XHTML and XML I am a little confused.
What are the differences, or is it just that the letter X is in the title
XML is for storing data and HTML / XHTML is for displaying data . XML removes the information from a page to allow designers to design to their hearts content without messing up any important info . Kind of like using DB driven sites , but XML aint as pretty as as Access / SQL Server / MySQL , scrap that , MySQL doesnt even have a natural built in GUI yet .
XHTML is the next step up from HTML and is designed to stick to the basic principles of XML , well formed and structured .
"Make sure that you set up Dreamweaver to produce markup that is in lowercase (<p>), and that the default file extension is “.html” and not “.htm.”" -- from [nypl.org...]
Anyone know if this is truly the case?
I'm redoing my entire site, but hoping to keep the main page names the same to enjoy the search engine goodwill I've earned over time, so I'm reluctant to change my .htm's to .html's.
I recently read something that suggests that XHTML docs should have an .html, not .htm extension.
I hope that employee is not you, or I'd have to pity your boss... ;)
Just to repeat what has been said in this and other threads over and over again: The version of HTML/XHTML you're coding against has nothing to do with how the site looks in any browser. If your site is written in reasonably correct HTML 4.1 today, then it could validate against XHTML 1.0 transitional tomorrow, with only minimal changes to the code, and no changes to how it looks at all.
It's the lack of backwards compatibility in xhtml 2 draft that seems absurd to me.
I assume the meaning of the term "draft" is well known?
Do your really want to dismiss the current XHTML 1.0 standard (which was designed to be backwards compatible with HTML 4.1), just because the proposal for a future version introduces some new incompatibilities? Are you sure you thought long enough about this? ;)
and that the default file extension is ".html" and not ".htm."
That's a private internal guideline of the NYPL, and has nothing to do with HTML/XHTML/XML standards as such.
It's the lack of backwards compatibility in xhtml 2 draft that seems absurd to me
I assume the meaning of the term "draft" is well known? .
Now that's just silly. You think they *accidentally* put in "no backwards compatibility" - a slip of the keyboard perhaps?
The emperor has no clothes.
Great for winning over your boss. Who is probably using Netscape 4.x and so will only see a gracefully-degraded (i.e. terrrible looking) web page and wonder why Amazon can do good pages and his employees can't.
I hope that employee is not you, or I'd have to pity your boss...
Just out of interest: what do you tell your boss wrt Amazon?
Say she uses NN4 to get a plain html page from your site and a nice page from Amazon.
You say "Aha, our page looks plain but that's because we are being as w3c-standard-compatible as possible and anyway Amazon obviously has no idea how to write web pages despite theirs working effectively in more browsers than ours"
To support your point you add "and if Amazon used xhtml then everyone could programmatically steal all their content really easily!"
And then your boss says "...er... ok what about Google, what do they use?"
What normal, sane person would agree that strict xhtml should be used over browser-quirk supporting html?
Can you point me to the exact sentence on the w3c site where it says that it will be impossible to write an XHTML 2.0 site that can be displayed correctly with any of the browsers that are in common use today? I don't think they say this anywhere. What they are saying is, that XHTML 2.0 will introduce some new tags, and that some other tags will become deprecated (but will continue to work in the transitional version). This is exactly equivalent to the introduction of every new HTML version so far, since 2.0 (remember that?).
Can you give me any example why an XHTML 1.0 strict page would become invalid when you change its doctype declaration to XHTML 2.0 transitional? And if so, would that be an incompatibility that is non-trivial to fix? The w3c is in fact going to very great lengths to make the transitional definitions as backwards compatible as possible. The changes required for the move from HTML 4.1 strict to XHTML 1.0 transitional can be handled by automated tools without any problems, and no influence on content and layout.
Where does it say that an XHTML 1.0 site has to look ugly in NS4? Reality is, it doesn't have to. And many members here could show you examples that work and look beautifully in all current browsers including NS4.
What makes you think that the Google site would look any different than it does right now, if they took the time to validate their code? I doubt that adding quotes to all their tag attribute values would have that much of a visual effect.
And last, do your own sites (whichever HTML version you're using, if any) display correctly in Netscape 3? Because that's pretty much the aequivalent situation to what you'll be facing about Netscape 4 and XHTML 2. Fighting the inevitable changes is really pointless, but that's your choice. You can either be part of the problem, or part of the solution.
And last, do your own sites (whichever HTML version you're using, if any) display correctly in Netscape 3?
Yes of course they do! I'm a seasoned professional, I remember when doing coloured text was a new cool (un-valid) thing!
And a (v.) small number of users do still use NN3... ;)
Fighting the inevitable changes is really pointless, but that's your choice. You can either be part of the problem, or part of the solution.
I think this is where you and I differ. You're implementing stuff now in the expectation that these "inevitable changes" will come soon. I'm waiting to see a) if they do ever come b) how my customers react - if at all - and c) whether the entire web design community has temporarily gone mad or it's just me.
added: what do you tell your boss re: Amazon + Google? Go on admit it... you just keep quiet about them don't you ;)
I recently read something that suggests that XHTML docs should have an .html, not .htm extension.
I don't understand how this can be the case as developers will be delivering XHTML through dynamic pages (.asp, .php, .aspx, .dll etc) with any extension that server software chooses to utilise.
The separation of content from display is a meaningless point. For a small number of people, it will help them "maintain" their tiny sites that don't need to be maintained. Given that anyone with a significant site is using a database and a programming language, this stuff is all garbage.
The content is separated, its in the database.
Separating the display elements into XML and the colors into CSS? Whatever.
We do a lot with CSS and HTML 4.01 Transition, but XHTML 1.0, XHTML 2.0? No benefits that I can see. I don't think that it is inevitable, I think that the Internet will sit at HTML 4.01 forever. Some new stuff will be in XHTML, but the browser wars and improvements ended long ago.
XHTML/XML are kinda pointless.
That's a tough pill to swallow. Given XML is to make your markup more semantically meaningful. I don't claim to know XML, but I know that it allows for a more human-like logic to the way we markup our pages, whether importing from a database or not, no?
I've been converting some small sites to "validating" XHTML and CSS as a test to prepare me for upgrading my large site. In the process, I've been offloading most of the design to the style sheets, and have been having a lot of fun putting CSS through its paces. Along with server side includes and scripts, I've been trying to make it so that no bit of code is repeated--the object-oriented approach. The code I imagine in my mind is almost sexy in its elegance and simplicity. It's also vastly easier to edit and maintain.
But, when I test the pages in different browsers, problems arise because each browser is differently-compatible with CSS, and especially because there remain lots of bugs in how each deals with more advanced and obscure CSS techniques. It's actually the CSS, not the XHTML, that is giving the browsers indigestion. When I try to do careful browser sniffing to apply separate style sheets that work around each browser's bugs and CSS incompatibilities, I discover that for some issues, the only workaround that will work will be to put some of the design controls back in the HTML markup, rather than in the stylesheet, which means, of course, that the page probably won't validate. It's darn frustrating to spend all that time only to have to revert to "sloppy" workarounds that spoil your utopian plan for the perfectly-designed web site.
I think that both sides of the argument here are right. Let's be honest: one of the motivations for coding in XHTML and CSS that validates to the latest W3C recommendation is the intellectual thrill of attaining a kind of immaculate perfection. (See Ellen Ullman's Close to the Machine [archive.salon.com]) But there are practical reasons for doing it, too, which are that this is where the world is going, and XHTML is useful set of training wheels for a vehicle that's really only in beta right now.
The ultimate perfection that XHTML and CSS (and XML) seem to promise is not out of the lab, yet, and probably won't ever be fully attained. But while we wait for it to evolve more fully, why not get some practice? In re-coding your pages, the immediate dividends include easier development of new features and less and faster general maintenance. Down the road, the transition to the evolving standards will be a lot less of a headache.
For those who doubt XML/XHTML are of any use, all I can say is that you need to think beyond the web to grasp what XML is about. XML is the vehicle by which data can go anywhere and still be understood and manipulated.
Consider: If someone were sending you a long article that you needed to publish on your web site, wouldn't you be annoyed if they faxed it to you instead of e-mailing an electronic version? Someday, you will be annoyed if someone sends you documents or information that aren't in XML for a similar reason: they'll be less usable.
[edited by: nonprof_webguy at 5:15 pm (utc) on Sep. 5, 2002]
I don't think everyone is trying to achieve validation in their careers by throwing their sites through a validator. To me using this code means that information is accessible, streamlined and logical. No perfection necessary.
If your boss is left wondering why Amazon can build a 'proper' website for NN 4.X, and his/her own employees can't, I can only assume it's because his/her employees haven't really studied the purpose and limitations of the coding standards they're trying to use... because there's no reason you can't build a validating XHTML site that displays just fine in your boss' browser. ;)
Yes, CSS for NS4 is tricky, but it's possible to get it right there too. It requires a certain amount of redundancy, because the inheritage doesn't work as it should. But that affects one file for the whole site in the ideal case, and maybe half a dozen when you're going for a modular setup.
I am in the process of converting my Web site over to XHTML / CSS, and despite some huge headaches in the learning curve and also all the personal deliberations about styles and so forth... so far it's been wonderfully worth it!
I did make the early decision to go ahead and basically tell off all the NS4 users (around 5-8% of my userbase). This was a painful and difficult decision, but I figured that the other 92-95% of my users would greatly appreciate the improvement in my site AND it'd be such a pain (for me, at least) to continually guarantee compatibility.
You can see the new pages in the HUMOR and RELATIONSHIP sections of my site specifically (it's my understanding I can't list specific URL's, right?) For the curious, you can check out the oldindex.htm files in both areas to compare the new versions against the old ones.
One of the coolest things is that my two changed pages are 1/2 to 1/3 the size of the originals. WOW!