I left the field and now, with only a little home-grown PC experience, at 56 I have been asked by a fledgling animal rescue non-profit organization to set up a web page for them. I want to set it up as simply as possible html , require as little maintenance as possible xhtml and yet be functional on what appears to be an ever changing web xhtml. So, from all of your comments it appears there is a host of peripheral considerations when using XHTML.
Under different circumstances and from all of your comments I would probably choose to learn XHTML and go forward from there. Considering my limitations, HTML makes more sense. I think I need this visual picture to see what I am really getting myself into! Any inputs from anyone? Emil, thanks for Friendly Bit.
It has given me considerable food for thought! Perrymc: Perhaps it could help to see a real site growing? I wrote an article some time ago about building a poker site. Good hearing that you too like my readers :. Thank you very much for an excellent article. Being a newbie to the world of valid X HTML i have to say that i agree with most of what this article has to say.
In the beginng, i found it very difficult to write valid markup, and would as such definitely not recommend XHTML to beginners. I don't care about the anal retentive tag structure making my content more "hardcore".
I do it for the warm and fuzzies I get of having a "well formed document" that can be predictably parsed by any software that is able to understand the doctype.
I don't want people to have to know how to split an atom to post content that I want to view. As a user, as long as it looks good in my browser I don't care what they use. Now as a developer, I am inclined to do some extra work on my part, to insure uniformity in my code regardless of it's context or application.
Someone may want to parse my work into another format, text reader, whatever. I publish content for others to use. I do what I can to insure they can parse, view, format, whatever my content any way they wish. There is definitely something to be said for uniformity in code. HTML can be made perfectly valid, well-formed, and strict. I'm compelled to think that you add the slash for some other reason The problem at this time was the missing compatibility of browsers. So I had to learn about how to get contents displayed in older browsers.
So how do You explain a beginner this? Of course, everything has its pluses and minuses, but when it comes to me, I feel XHTML has more pluses in the long run than the minuses. Kamran: separation of content and style has nothing to do with XHTML, it's just a matter of selecting the strict doctype. This is what beginners are taught by the W3C. From a beginners perspective this is quite confusing. I'll definitely look more into this with the links provided. I disagree with the statement that HTML is and could be learned by a beginner in a short amount of time.
Just all those omissability rules of SGML alone are so incredibly complex, it just blows one's mind. Will: I totally agree. No one would ever use the code you describe. It's nearly impossible to read all comments to search for the question I have. W3C advises to use XML to change data in the future I understood with wordprocessors, databases, spreadsheet applications. They expect the application programmers to adapt these programms which makes exchanging data easier.
Emil, what do you think about this W3C motivation? You don't need to worry about your site though, it will probably work on older browsers too unless you did everything right, which very few know ;. Thank you for your quick reply Emil! I doubt new websitewriters have interest in exchanging data yet, but if youngsters learn writing XHTML with CSS correctly in an early stage, I can't really think what would be against this.
It might depend on the education level, I guess? Nice article, Emil! It highlights a very crucial problem of transparency which needs to be addressed before we can progress much further with web standards. One of my co-workers, not a fellow of the programmer mindset and accustomed to designing with tables in Dreamweaver, was trying to get to grips with using valid HTML and CSS to design websites.
The process was painful and agonising to watch; sometimes, I wanted to scream after looking at the code he produced. And then I remember that I used to write code like that. This man isn't clueless, either. He's been designing websites since before I even saw a webpage for the first time! There is no way on earth that the vast majority of the online population have any place being asked to consider the complex rules governing character encodings and MIME types.
At this level of technical detail there should be limited user involvement; common XHTML problems should be dealt with by an abstraction layer which can take care of it without the need for low-level supervision. We need smarter tools to lighten the cognitive load for non-technical users. Using your examples, here's the sort of thing I mean: If I used XHTML and parsed it properly and someone used invalid code in the comments the page would break.
Blogging sites need built-in tools which can handle and deal with receiving malformed input. New coders should be strongly encouraged to use existing abstraction layers rather than hand-coding them. Whatever CMS you are using to publish articles should already be able to deal with different character encodings; again, those who want to write their own CMS should be directed to use existing modules which take care of these complicated problems before they arise.
Javascript is a tricky one. However, we need to develop better procedures for packaging, documenting and integrating Javascript into webpages. I think that what we really need are IDEs which enforce modularisation of Javascript and external resources, clearly identifying dependencies between modules; then, when the site is launched or tested, the necessary files are "precompiled" into a distribution directory. This is similar to how Java programmers have been working for a while.
In my opinion, this will be much easier when most browsers support newer versions of Javascript with an " import " directive. However, once tools, technologies and applications have evolved which make producing and interacting with XHTML as easy and useful as it was always intended to be, I won't be surprised if HTML is swiftly abandoned in favour of its more powerful sibling. One final note: a huge part of the responsibility here lies with browser vendors.
When we can finally rely on valid markup and CSS being interpreted correctly, and uniform Javascript support across different platforms, I predict that progress will be made in leaps and bounds.
Here's to IE 8! Might as well stick with good ol' HTML 4. I had not coded in Strict before today, but still never used any deprecated tags, so the convert wasn't that painful. I undrestand your thoughts, but i disagree with your conclusion. For the casual web page writer it may be more easy to handle. But html is limited.
The 'X' in xhtml stands for 'extensible'. That is: In xhtml you could use xml namespaces and then include other xml dialects in the page. Most notably would be rdf and its derivates. Or think of svg to directly include vector graphics into the code. You could include anything.
If you use html, you can't directly include it. You may include such things via object, but then: If the browser is capable to parse xml to render an external svg object, why then not directly parse xhtml as xml? It is the same parser. So as a conclusion: As long as you are well of with what html offers you, it should be sufficient to code and send as html. As soon as you plan to add more to your pages you should think of switching to xhtml. Using xhtml consequently breakes every limit.
Your possibilities virtually become unlimited. Many times html 5 will be absolutely sufficient. But as soon as you can get more, there will be an increasing demand for more, so you will have to switch to xhtml at some point. And, BTW, it is still possible to automatically convert xhtml to html using xsl. It is nearly impossible to automatically convert erroneous html files to proper xhtml.
Most people do not though, not now, and not in any distant future, and there's no reason for them to change. Might be good to know. Yes, i know. And it's not the worst idea. Just the naming convention is very bad. Calling the html version html 5. Calling the xhtml version xhtml 5. It would be much better calling it xhtml 1. The real, although not near future is xhtml 2. The problem with the html effords is, you always have to add new features to the monolitic block of html. With xml you freely get modularisation.
So in fact this is the way to go. You're right, those additional features are not much needed today. For most issues html 4. Su as long as you accept the limits you may stick to html. And since the IE does not understand xml not without an xsl stylesheet , today it is generally better to at least offer a parallel html version, if not just an html version alone. But the point will come where you have to switch.
It is your personal decision, when to switch. But some day it will be necessary. Old style html will then be just a markup language for the casual hobby web page producer.
Professionals will need xml. In the future :. I looked away from a tree, and found a forest Better tools for common users could nullify this entire debate. A well built composer should publish pages following all the standards. It handled or so of the most commonly used tags in a research environment. Secretaries were using it with a couple hours introduction. BUT, sigh William: I'm not such better tools fully fixes the problem. We still have the issue of error-handling in the browser XML has one way of handling errors that just doesn't work on the web.
HTML can and should be its own thing. Understand that I have nothing against XML: it has its uses, and some of them are very cool. However, XML is a very complicated beast, despite its billing as the panacea for all that ails us. One of the biggest strengths of HTML was its simplicity and fairly minimal set of requirements. You could write it in any combination of upper- and lowercase, and browsers didn't care.
It has a very simple syntax. It asked only that authors and tools respect a fairly simple structure and not mess up their attribute quoting. As it turns out, even that was too much. Once the browsers started trying to save authors from their own mistakes, it was all over.
EDIT2: after reading all your comments and the links, I indeed agree that another post deserves to be the correct answer, so I chose the one that directly links to the best source.
Including the following bit;. XHTML 1. A simple XSL transformation will not be sufficient in most cases, because some semantics won't translate properly. HTML 4. A valid HTML 4. Future compatibility can be huge when working on some projects. The article goes on to make several other good points, but I think that may have stood out the most for me. One of the major reasons for developing the XHTML specification was to de-emphasise presentation-related tags in the markup, and to defer presentation to CSS.
Whilst this separation can be achieved with plain HTML, this behaviour isn't promoted by the specifcation. XHTML was not developed for use by itself, but by use with a variety of other technologies.
It relies heavily on the use of CSS for presentation, and places a foundation for things like Microformats whether you love them, or hate them to offer a standardised markup for common data presentation. Don't be fooled by the crowd who think that XHTML is insignificant, and is just overly restrictive and pointless The trade-off will come purely in how you describe the document using the available markup.
XHTML tags tend to be longer, due to required attributes, proper closing, etc. With that being the case, I think you're talking about comparing one type of apple, with a very slightly different type of apple For the visitor of a website it probably doesn't make any visible difference. If your HTML is going to be regularly processed by automated tools instead of being read by humans, then you might want to use XHTML because of its more strict structure and being XML it's more easy to parse from an application standpoint.
Not that XML is inherently easy to parse, though. Apart from that I don't see any compelling reasons to use it, though. All browsers support HTML. W3C HTML5 is written as we speak and addresses needs of web applications used today, and has very good backwards compatibility. XHTML2 is not going to be supported by web browsers in forseeable future.
Anybody who says otherwise, hasn't read the specification. I encourage everybody to read the spec — it's suprisingly short and uninteresting. XHTML myths. It depends how the parser is implemented. The overall difference in cost of parsing is tiny compared to time it takes to download document, build DOM, run scripts, apply CSS and all other things browsers have to do.
Here's why:. If you just serve it with the default mimetype, all browsers will interpret it as HTML - eg, accepting unclosed or improperly nested elements. If, support for the XHTML mimetype becomes significant enough to convince people to start using it, most of their javascript code will break - even if they think their pages validate as XHTML.
Instead of continuing to debate HTML 4. John Resig, the author of jquery, made a similar suggestion last year on his blog. HTML 5 also has proper support for media and media is a fairly important aspect of the web these days! It's becoming increasingly clear that HTML 5 is the future of markup on the web. All of the browser vendors have publicly announced their support for HTML 5. At the end of the day, even if XHTML2 regains support from the industry, it won't be a significant issue having two competing standards as it has been in the past.
There are some good reasons apart from modularisation. While this is a really simple example, it could also get more confusing and different browsers could lay out things differently. As a programmer, you should be VERY concerned about your code.
HTML is ugly and follows few rules. XHTML is better for everyone, as it will help move the web to a point where everyone all browsers can agree on how to display a web page.
This isn't very logical, because the img tag never gets closed. Many tools exist today to process XML. By using XHTML, you are allowing a huge set of tools to operate on your pages and to extract information programmatically. If you were to use HTML, this would be possible too. However, these tools can often be more specialized than those for XML. Furthermore, there are so many uses for XML nowadays that you may be using XML for some other part of an application; why not also use that same XML parser to parse your web pages?
If you're already comfortable and familiar with HTML 4. If you're using something other than HTML 4. This makes the different browsers behave better and, most importantly, more like each other. This makes your job as a webdeveloper a lot easier since it reduces the amount of browser specific tweaks needed to make the content look the same in all browsers.
In my opinion, the strictness is, at least in theory, a good thing, because in HTML, you don't need to be strict, and because of that and the HTML5 junk, Browsers have advanced error correction algorithms that will make the best out of broken HTML.
Why you should have a website: it's the law! Why Web 2. Was I right? The Power of Two Available computing power doubles every 18 months. Why aren't we taking advantage of it?
Hotel Heartbreak Why are hotel booking sites on the Web so terrible? Letter Writing, Telephones, and Television So is the net bad for human relationships? Restrictive practices Region codes on DVDs are a stupid idea. The Kiss of the Spiderbot The economic value of making websites accessible. A Pixel is not a Point Screen resolution pixel density is increasing.
Don't use pixels as a measure of font size if you want people to continue reading your web pages. Go away! Web sites that don't care if you can see their content Choose one: fast, correct, or pleasurable On the definition of usability. Electric IP What will it mean for the user if Internet comes out of the electric plug?
Did convergence kill the clock? Will devices converge to one all-powerful device, or will they stay separate and learn to communicate? The culture of uncertainty A proposed explanation of why some websites are apparently so wilfully hard to use. In search of the killer app Successes and failures of the mobile Internet. The design of notations Many eyes make UI bugs shallow, too. Photocopy this article! Why publishers should be encouraging digital copying like Napster. Abusus non tollit usum Is it OK to use the word "Affordance" about aspects of screen interfaces?
The accidental death of reviewing Peer-review has structural problems that may just go away It rings for me How our interactions with devices live in the fringes of unanticipated possibilities. The demise of the book If you're one of those people that thinks there's nothing like the feel and smell of a lovely book, come over to my house sometime and smell mine.
0コメント