Slashdot Mirror
Why You Should Use XHTML
Da_Slayer writes "The w3's HTML group has released the 6th public working draft for XHTML 2.0. XHTML 2 is a general-purpose markup language designed for representing documents for a wide range of purposes across the Web. Meaning it is to be used for document structuring which is why it does not have presentation elements. The draft is located at w3's website. Also they have a FAQ about why you should use XHTML over HTML. It goes into specifics about embedding MathML, SVG, etc... and has links to tools and resources to help convert existing html documents to xhtml. One of those resources is a document on XML events and its advantages over the onclick style of event handling."
Slashdot isn't even valid regular HTML, let alone XHTML, and they're running a story on why we should be using XHTML? I'd laugh if it weren't so sad.
Can someone please explain the differences between XHTML an XML?
Not everything is analogous to cars. Car analogies rarely work.
You have to wonder if Microsoft will be implimenting this new standard in IE. I have done some webdevelopment and have really noticed that they rarely impliment any of the standards in there browser. Not to mention that they are on the board that approves these standards :P
anyone else amused that this article was posted on slashdot? a site who's HTML is so bad they've blocked validator? I'm amused.
I post links to stuff here
Which browsers accept the media type application/xhtml+xml? Browsers known to us include all Mozilla-based browsers, such as Mozilla, Netscape 5 and higher, Galeon and Firefox, as well as Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, and all browsers on mobile phones that accept WAP2. In fact, any modern browser. Most accept XHTML documents as application/xml as well. See the XHTML Media-type test for details. Does Microsoft Internet Explorer accept the media type application/xhtml+xml? No.
M$ Lawyer: But `gcc
Maybe we should use XHTML because HTML is ancient and broken? Furtheremore, CSS must be pushed to replace most of the format specifications. XHTML+CSS actually simplify the rules by which browsers format text.
I've been using XHTML for some time, but only in the modes that safely fall back to HTML for browsers that don't "speak" XHTML.
I have to wonder if 2.0 is going to catch on. Internet Explorer isn't likely to support it any time soon, and nobody wants to code two versions of every web application.
Still, good FAQ on that site. I learned some details that had been hazy.
lately the W3C is useless and isn't able to produce anything useful. Schema is still horribly limited and doesn't really fit the needs of OOP. Schema should allow a complex type to extend or implement an external class/interface. It can be optional and not required. The current schema sucks. I won't bother with the other specs. Many of them are just as bad, or the specs are so poorly written it's a bitch to understand. XSLT/XPath is a good example of really poorly written specs.
It would be nice if Mozilla composer could save in XHTML....I'd gladly use it if more editors would save in XHTML format.
With all the time we spend hearing about alternatives to IE around here, you would think that slashdot would be compliant to at least some W3C standard. If /. were some tiny hobby weblog this would be forgivable, but /. could use the size of it's audience to actually lead. Why not do it?
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
XHTML 2.0 almost forces you to seperate "content" from "presentation". Which is a good thing.
Something better would be to use pure XML for creating content and then let the browser apply a CSS to present the content.
See Mozilla + CSS + XML = Structured + Formatted Content for more info.
Consensus is good, but informed dictatorship is better
Haha, like the editors actually read Slashdot anymore.
(Before I'm completely slaughtered for complaining about performance, a disclaimer: I haven't done strict benchmarks)
Is it my imagination or are XSLT transforms very slow. I know this will depend on what engine you use to transform, but during the course of designing a website for a friend I tried several Java based transforms to go from XML to an XHTML page.
Why are these operations so slow - I thought XML (and therefore XHTML) was supposed to be straight forward and easy to parse.
In my limited experience XHTMLs benefits seem to be "weakened" by parsers/transformers that are still a bit away from maturity (speed-wise).
(Hint: if anyone knows a lean, mean transformer nows the time...)
[ Monday is a terrible way to spend one seventh of your life. ]
I dif XML and all, but things like replacing tags with stuff like:
<p src="map.png"><span src="map.gif">Exit from station...</span></p>
seems a bit too... anal? or purist/academic at best.
I suppose it's a moot point if MS/Macromedia/Adobe comes out with a great XHTML2.0 WYSIWYG editor, then 95% of the developers out there wouldn't even care...
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
The reason most HTML is not valid is because browsers have generally not supported CSS completely, which makes it necessary to replace DIVs with tables, add huge browser functions to Javascripts, etc.
Now, Safari, Mozilla and Opera support about 98% of CSS-1 and parts of CSS-2, so it becomes possible to actually develop a working web site without spending 10 hours of testing and debugging (yes, debugging HTML) for every one hour of actual development.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
Do ANY web browsers support those out of the box yet?
I wouldn't cry fowl about being modded as a troll when you post offensive web pages and say "see how W3C clean it is?"
Get your own free personal location tracker
Man, do you remember when writing a webpage by hand was easy? Back in 1996 or so when just about anybody with a text editor and a link to that excellent Netscape HTML manual could write a decent page without spending hours poring over obtuse documentation?
Now you have to figure out what Doctype to set, learn CSS, enter some sort of weird workaround for IE, etc... Worse, HTML used to be fairly forgiving for the author so Newbies could get a decent page without spending hours and hours trying to figure out why their page is coming up blank or trying to figure out why the validator is complaining at them. (I really hate when it says stuff like: Illegal use of <B>. And I'm left scratching my head as to why it is illegal.). It's no wonder newbies choose instead to write their webpage in Word and use the horrible "export to HTML" feature.
I read the internet for the articles.
XHTML is the next iteration of HTML. It is more formal and more strict, and (hopefully) more consistent. From http://www.w3schools.com/xhtml/xhtml_html.asp:
XHTML vs. HTML:
XML:
XML is not really parallel to XHTML/HTML. It is more useful for defining data containers and storing data. It is another step along the path to separating content from presentation.
From from http://www.ucc.ie/xml/#acro:
"XML is actually a `metalanguage' --a language for describing other languages--which lets you design your own customized markup languages for limitless different types of documents."
---------------------
Dr. Movie Movie: DrMovieMovie.com
Tomorrow's media behemoth -- today's independent voice.
Meaning it is to be used for document structuring which is why it does not have presentation elements.
That's what they said about HTML in 1992. Look what happened to it when it got popular: bastardized so badly with presentation elements that it lost almost all of its structuring features. Remember <fig>? It was obsoleted before it even made it out of draft status because commercial browser vendors (*cough* Netscape *cough*) pushed <img align> on everyone instead, because it was quick and easy. That's just one example. Who's to say this new XHTML won't be spoiled the same way? We could say "Use HTML if precise control over layout is needed" but back in the HTML days, we were saying "use PDF if precise control is needed" and we were ignored, and HTML was destroyed so badly that XHTML is now needed to fill the role HTML had to abandon.
What's to prevent lather/rinse/repeat?
Edith Keeler Must Die
Offensive? I (and the First Amendment) call that free political speech. It's no secret that moderators' respect for free speech rights ends at valid dissent.
Nope, you're right.
I'll go out on a limb and say that using XML as the document format for web site production is a terrible idea. XML is a great data exchange language between systems, but it's insanely inefficient for use within a single system. All of XML's positive attributes (self documenting, robust, extensible, supports encodings, validation, use XSLT to do transforms between arbitrary XML representations of data, etc.) are all important between loosely coupled systems. But those issues don't occur within a single system, and the overhead of using XML is immense. It's orders of magnitude faster to query a datbase directly than to parse XML, transform, etc.
Enable 3D printed prosthetics!
You forget the original purpose of HTML. HTML's purpose, and the reason it grew so quikly, was to be an easily understood markup language that could be used by less technical people. The reason so many people were able to make their own homepages and grow the web like they did was that HTML could be easily learned.
Now we have XHTML and CSS. Neither of these are easy to learn. Neither of them is easy to use. Less technical people are incapable of using either. This is great for job security for webmasters, but for the growtrh of the next and for the internet as a medium of free and easy communication its horrible. XHTML is broken as an HTML replacesment because it does not meet the original purpose of HTML- to be something that anyone can easily learn and use.
I still have more fans than freaks. WTF is wrong with you people?
The IMG tag is perfectly acceptable in XHTML.
I think that so long as the WYSIWYG community keeps implementing these standards into their applications, web developers will follow suit. The latest version of Dreamweaver codes excellent XHTML and almost forces designers/developers to use CSS to incorperate presentation elements out of the box. For those who code 100% manually XHTML is an easy thing to tackle. The big issue it seems is that, like many web developers out there, I am getting quite sick of the frustration in multiple browser support. While it may be the most popular browser, IE is quite possibly one of the worst for supporting standards. I don't mind Microsoft trying to develop their own web standards so long as they are 'implementable' in other browsers/systems, but that never happens.
-- Bored? Check out my Portfolio
The only version of XHTML that is suitable for transmission as text/html is XHTML 1.0 following Appendix C. XHTML transmitted in this fashion doesn't have any of the benefits of mixed namespaces, stricter parsing, etc.
You get these benefits when you serve XHTML as application/xhtml+xml, and your visitors use browsers that support those features (such visitors are extremely rare - SVG isn't even in main Mozilla builds yet). But many legacy user-agents require text/html. Search engines would probably be the most important ones.
So unless you are willing to set up content-negotiation, sending different document types to different browsers, and unless you have a niche market that use browsers that understand these new features, you really aren't going to get anything from XHTML. Not for a few years, anyway.
Sending XHTML as text/html Considered Harmful
Besides which, XHTML 1.1 and 2.0 aren't even vaguely backward-compatible.
"Feel free to submit patches back to us if you come up with anything useful."
In other words:
"This clusterfuck is roping us a comfortable enough income from ad revenue that it's not worth our time to deliver a better product to you, our customers. If you want a better site, YOU do the work!"
"Ask not what your country can do for you." --John F. Kennedy
"Structured documents" for public distribution usually don't work. The problem is that the costs of tagging are incurred by different people than those who benefit from it. Unless you have some enforcement agency that makes people tag their data, it doesn't happen. Even then, the data quality tends to be terrible. The SEC used to require financial statements in a rigid SGML form, in the EX.27 schedule of 10K and 10Q filings. Companies hated that. Not only did they get the numbers wrong, they hated having to express their numbers "uncreatively".
There are ways it might happen. If Google said that "You must tag all "buyable things" in this format, or you don't get into our index", we'd see it happen. That's how a few big retailers forced manufacturers to bar code, two decades ago.
Regular HTML:
<img src=logo.gif width=10 height=10>
XHTML:
<img src="logo.gif" width="10" height="10">
I hate those extra quotes. Why is this progress!?
There's really not much to it:
Firefox's WebDeveloper extension makes XHTML/CSS validation (among other funcs) so easy that there's no excuse to be lazy about it.
--
Power to the Peaceful
Why should you not encourage XHTML?
often touted as a 'human readable' data format.
Did you ever take a peek at it recently? Its completely cluttered and unreadable.
Yes, this will allow web designers to handle special cases that rarely come up.
Why the hell should the browsers accept a messed-up page?
Think about a C compiler who could be as error tolerant as a web browser is for the html. This would result as a huge ridiculous lost of performances, pure counter-optimization!
If you are not enough skilled to learn a language as simple as x(html) can be, then use any of the wysiwyg apps out there. This will at least generate valid markup.
Microsoft was usefull to bring personal computers into the home of everybody, but now it is fucking slowing down how the web and the computer technology could evoluate. We already know it, but IE and Frontpage is the worst thing happening these days to the default end users.
I remember developing one application in XHTML, only to find that it has no support for the javascript OnLoad page event which completely broke what I was trying to do. I was forced to go back to strict HTML for my application to work. I probably won't be using XHTML until it's compatible with all the DHTML elements I can currently use.
1) why is that a bad thing always remember to validate
3)http://sourceforge.net/projects/tidy/ *shoud* correct that for you
xhtml isn't a format it's a type of XML
If you have nothing useful to say post as AC.
Also they have a FAQ about why you should use XHTML over HTML.
Meaning it is to be used for document structuring which is why it does not have presentation elements.
What! No <blink> tag?? No
No way I using it!11!1 I'm a serious web designer!
(This comment looks best at 717x913 resolution, using Internet Explorer for the security holes and that essential <marquee> tag. Page designed in Microsoft Word, because that HTML stuff makes my head swim. Enhanced with buggy JavaScript we stole off some Russian porn site, to resize your browser window, make its controls inaccessible, ensure the "security" of our images by disabling right-click, and to reject any browsers other than Netscape 4.72 and IE 5.5. Please bookmark this comment and come back when we've made the entire comment one big Flash animation completely inaccessible to anyone not running Flash or running Flash but on dial-up. PS: we appreciate your business.)
Opinions on the Twiddler2 hand-held keyboard?
If MS waits for Longhorn then they''re unlikely to upgrade IE on Win XP or earlier. Longhorn will take some time to be adopted. As a point of reference, Google's June zeitgeist shows Wiin XP with 51% of Google requests - this is about three years after it came out.
Unless MS upgrades current IE or Longhorn is adopted much faster than XP or compliant browsers are adopted at a much faster rate it could easily be 4 to 6 years before XHTML2+CSS2 have 50% market share.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
And XHTML is actually easier to write than HTML.
Thanks for your opinion though.
by sending out simple 503 Service Unavailable responses.
Amen.
The box model is only broken on IE5. It's even been correctly implimented in IE6. CSS is for all practical purposes fully supported by modern browsers.
No! NO!! Why are they wasting time on this stupid, non-usable language?!?! It makes me want to rip out my face and say "BLAAHAHA". Geez, why don't they fix CSS first and try doing something GOOD, like making the id and name attributes the same or both handled in CSS and javascript. Pathetic. I hate life. XHTML gets the official *thumbs down*!
doing their preferred geeky thing in the most efficient way possible
Now maybe your preferred geeky thing is minimizing bandwidth over the short term.
And maybe others' geeky things include minimizing over a longer term.
I could spend $10K in time to save $5K/year in expenses, or $10K on some other effort that will have a better long term payoff.
The "editors" here ARE in fact geeks, and they know what they are doing behind the scenes, which you do not. Maybe you should assume they have some idea of what they are doing, and that as you have said, since they have little actual editing to do, maybe, just maybe, they actually do some geeky things that you know nothing of.
Infuriate left and right
HTML versus XML and the related set of schemas, including XHTML, can be compared to building with Lego versus real construction materials. HTML comes out of the realm of the old web where everyone and their uncle can be a so-called "web designer", a title anyone in the industry knows to actually refer to a graphic artist who draws buttons and banners. Coding in HTML revolves around nudging table cells by a few pixels this way or that way and hoping that all falls in place on that old piece of crap browser that half of the customers of your company are still using for some reason. HTML can be written by a 5-year-old. Some see this as an advantage, those who use it professionally can't see it as anything but a shame. I've known my fair share of web developers, being one myself, and the number of them who know anyhing about actual software development is probably less than one percent of the total.
XML, and all the web-related schemas and standards like XHTML, on the other hand, provide you with an ability to present very complex business domains over the internet. Anyone wno knows anything about programming will say that jumbling all your data, along with it's structure, along with it's presentation is a terrible way to write software. The new standards allow one to keep data separate (XML), structure separate (XHTML), and presentation separate (CSS). While it's admittedly more complex than the regular HTML it lets you do so much more with your data. Switch stylesheets and bam, your site looks completely different. Switch XSL stylesheets and you can serve the same data in completely different ways on a PC, a PDA, or a mobile phone.
Lastly I want to bring up that web clients are often used as front ends for company intranets and while it's going to be a while until web developers (and consumers!!!) will be able to enjoy the benefits of the move to XML on www those benefits can already be reaped in the controlled environment of your company intranet.
I read it, and agree that the web could be better, and they have some great ideas on how to do it...
But some things just drive me nuts, so I decided to sit down and blog it.
If the can't manage to do it, what makes them think the world will do it?
They have always been fans of backwards compatibility... but not in a very fundimental sense.
I'd rather a form control not appear properly to NN3, than a large chunk of the web be unable to view my content.
Just my $0.02
-
Do you remember that web pages in 1996 look like shit?
Oh please.Do remember that web development these days cannot rely on simple static text?
Do you realize that with HTML/XHTML editing tools around these days, it doesn't matter?
Right tool for the job, my friend. A text editor is for writing static text. HTML/XHTML tools are used for making web pages and interfaces.
Do I remember? Yeah, I've been coding HTML by hand since 1995, and my pages looked pretty messy back then. But it wasn't the HTML - it was my poor grasp of what looks good and works well for other users.
"Cannot rely on simple static text"? It's been said here before, and apparently you don't believe it. If your pages rely on flashy formatting and movement and pixel-level formatting, you're letting the formatting get in the way of content.
Right tools? Heh. Sorry, I've tried PageMill, and FrontPage, and Netscape and Mozilla built-in editors, and even MS Office's HTML editing. Don't like them. They all generate bulky, messy code, hard to tweak, impossible to really control. I've hand-coded everything from day one, and will always do it. And if you think hand-coded HTML is unpretty, somehow, visit http://www.worship-live.com for what you can do without an editor. Looks nice in any browser, lightweight and therefore bandwidth-friendly, and has yet to generate complaints of any significance. Maybe it won't parse out as perfectly W3 compliant - maybe I put the italics tag on the wrong side of my paragraph tag - but it works.
Sorry, but I just disagree with your basic premise. Frankly, the biggest problem facing the web today is people who somehow think that PageMill or Frontpage make them better web designers. Sorry - that's exactly the wrong answer.
--Brandon / Split Infinity Music
At this stage, why bother with YAHTMLS (Yet Another HTML Standard) and why not just go straight to the full-blown XML standards? Like has been said, 95%+ of browsers will support it nicely (the 5% being made up of the 4th gen browsers and others that are XML-free). It would save having to redo your work in another thre years when they forgo the HTML-esque standards and just tell everyone to use XML.
Damien
I'm no expert in XSLT, but since XHTML is in XML, should it not be possible to create a XSLT to transform a XHTML page to good old HTML4? And by configurating the webserver to serve this transformation to legacy browsers (read IE!) you could handle all documents internally in whatever latest XHTML standard you chose to use. Sort of like a serverbased browser plugin...
Another comment attached to this story makes me belive that the current state of XSLT tranformation engines are quite slow? Well, nothing a few months of Moores law can't solve! :-)
Does anyone know if this revision will specify more precisely how it should be displayed by a web browser?
The problem I've found with fully using XHTML+CSS for web pages is that it is not possible to layout pages that will scale accurately as the font size is increased. So much for accessibility!
I wonder why it was decided that it would be useful for text that doesn't fit, to run-over other text and elements on the same page.
It would be better if we could tell the browser that when elements expand the other parts of the page must move out of the way.
- Brian.
XML is big, unweildy, and complete. Some people like the completness, but it only leads to confusion, and doubly so when any namespaces are involved.
XML was designed to be easily read by eye, but it is often less readable than other text formats.
XML was designed to find the holy grail of 'eliminating version incompatability' and allowing different applications to share common data in the glorified XML format.
HTML is a presentation language and well, websites do present. It doesn't take a programming genious to separate the presentation from the content if that is desired.
XHTML and CSS are much, much easier to learn than the giagntic mess of nonstandard, browser-incompatible, downright screwy tags that encompass the current state of HTML. Maybe HTML was once intended as a great democratzier of the internet, but it's a misapprehension to think that back in the day everyone was writing and grasping HTML - the people who were early-adopters of the web and were coding their home pages were the technical people anyway. Few average-guys-on-the-street were setting up elaborate page designs unless their job called for it. Even then, most people relied heavily on editors and templates. The proliferation of bad Frontpage-designed websites is a testament to that.
The internet has changed and old-fashioned HTML - and the idea of one person coding it all for themselves - isn't really up to the task anymore.
Let's face it, most "non-technical" people stopped coding HTML by hand when the spec for "table" came out. Those that continued gave us interminable headaches with tags that wouldn't validate, but occasionally IE or NS would consider "good enough" and try to fix, or little end-run hacks that would do one specific formatting thing in IE4 that would break horribly in every other browser.
There's less of a need these days anyway for a non-IT-or-related-industry person to deal with the deep mechanics of markup. Much of the great democratization of the net has come from services - forums, blogs, and yes even slashdot, not from my next door neighbor coding a personal home page. Even in industry, the "web designer" is becoming a rarity in the post-dotcom economy. NOw it's either more comprehensive media designers who apply their skill to the web, "regular" employees who develop content, or developers and admins who code HTML as front-ends to applications and services. Few people have the specific job of just making web pages anymore.
For those of us who do have to deal with the nuts and bolts of markup, the XHTML/CSS combo is a godsend. Code is more legible, information hierarchies make sense (in some ways, a lot of it hearkens back to the early days when everything was h1, h2, h3...), if doen right you only need to make one set of pages that can be easily made to work cross-browser...what's not to love?
And really, it's not hard to learn. Oh, sure, CSS has a lot of detail to it, but how often is someone going to have to know what the CSS2 spec is for alpha-masking? Standards things like "font-family" and "background-color" are pretty easy to remember, and are certainly easier to deal with than those bloody font tags and 900 conflicting html attributes.
----
"I used to listen to Null Device before they sold out."
The above is true, but I think what w3c is trying to get people to do is to start following the standard. There's a chicken-and-egg thing going on with the standards and implementation now (and always) where the standards are generally considered a "good thing", but people don't use them because no applications use them, and since people don't use them, companies don't make products that incorporate them, which means people can't use them or don't find benefit from using them. More often than not, us developers have waited for companies to give us something before we do it. If we all did it first, then they'd have to give it to us, and they'd have to give us what we wanted and not what they thought we might want.
In other words, just like voting with your feet or your wallet, vote with your code.
what is this "mozilla"? is it like an internet program or something? i have never heard of anything like it in my ~5 years of visiting slashdot.
Not at all. CSS is difficult for people without a CS or IT background. They don't understand the idea of abstraction and of differentiating content and presentation. And a lot of those "screwy" tags in HTML made life a lot easier. And example is the center tag. People understood that, it made sense. People don't understand .
In 95 and 96? Yeah. In 97 and up? No, many of them were average Joes. Many of the people blogging now are. Sure none of them are technophobes, but not all of them are technicly knowledgable either. As for elaborate page designs- who cares? The web is not about just the giant sites. Its about all the pages, from little to big. If anything, the little ones are even more important. When I google for information, I find myself sent to some small homepage far more often than I am some giant of the internet world.
Sure it is- I'd be willing to bet hard money that there are still more single programmer pages out there than there are professionally produced ones.
Slashdot was a small personal homepage with user comments that made it big. I'm not going to downplay the importance of blogs or forums, but homepages do far more, and are far less emphermal, than blogs ever did. Blogs are great for reporting spur of the moment thoughts and short articles. But homepages do all that and more. I tend to think of blogs as minimalistic homepages.
I'll agree, CSS and some of the XHTML features make life easier for big designers. IF you think its going to make cross-browser work though, you're kidding youself. HTML would do just as well if the spec was followed. It wasn't, and this one won't be either. You'll be back to the same types of tricks within a week.
And CSS is definitely hard to learn. Not for the average
I still have more fans than freaks. WTF is wrong with you people?
We also have C, Perl, Fortran, Lisp, and so on and so on and so on... and they are all difficult to use. You actually have to sit down, open a book, read, learn, and think. Can somebody tell me why XHTML should be anything different?
First of all, XHTML is easily recognizable to anyone who knows HTML. I don't know where you get off saying it's harder than HTML. As for CSS, it's a hell of a lot easier than messing with tens if not hundreds of nested font tags and other legacy presentational markup crap.
Second, why do development tools and languages have to be simple and easy to use by the masses? So the tools can be a little less popular? Is that even bad? I for one would be quite happy if more people out there who are too dumb to figure out how to use relatively simple tools like XHTML correctly weren't producing material for the web. Even then, there is now lots of software out there that produce valid, semantic XHTML (modern incarnations of Dreamweaver, for example, are capable of this). So where is the problem?
We as developers should definitely be interested in making end-user products easy and functional. But when it comes to the languages and tools, fuck that. Let's make them good for developers, not our grandparents.
Why bother.
I don't know about you guys, but my pages are already written in XHTML 1.0 and, thanks to CGI.pm, all I need to get my pages up to the XHTML 2.0 spec is a newer version of CGI.pm which would be provided through a newer Perl distribution.
Ah portability..
- Readability: XHTML is readable as long as it is structured correctly. Note: That doesn't mean having everything on one line.
- XHTML can be done with a plain text editor just like regular HTML, though as always, it's best to use a text editor that at least has syntax highlighting.
I code valid XHTML nearly everday as a freakin' hobby. There's 3 useful things I've come to know:- Make it structured and it is easily readable. Tabs, line breaks, and spaces in appropriate places.
- A text editor with syntax highlighting. A must.
- Ok, so I forgot what the third was.
The above is true for nearly all programming. Slashdot, home of the all-knowing arrogant beings.My web site, http://www.igsgames.com, has a couple dozen pages all written by hand with a text editor. I use bbedit mostly but never touch the web widgets. It is quite simple to cut and paste to create a new page. I know exactly what code is in each page, so it is easy to modify. And I am not a web developer by trade.
Please spread the word that HTML is easy for anyone to learn!!!
jfs
The only thing worse than a Democrat is a Republican.
What are you talking about? Buy expensive programming languages. I use vi exclusively (not saying its better just what I'm used to) to create web content, xhtml included. Last time I checked I was human. As for the expensive programming language(!?), the validator code is readily available for free.
One huge problem I've encountered trying to switch pages from HTML 4.01 to XHTML is more established engines tend to hail from the HTML 3.2 days (Slashcode) and have not evolved much since. Forum software is often the worst in my experience, everything is littered with tables and fixed size elements. A lot of people host their sites on vhosts and many of those don't support things like HTML::Template, Mason, or Smarty. As such most coders just write their own template system which may or may not handle newer web standards.
Since many sites are using crappy HTML they want to spice up they tend to use equally crappy JavaScript to add little stylistic features. I think many people are surprised when they hit up a CSS tutorial and figure out they can replace their stylistic JavaScript with CSS and have much better performing web pages.
I'd love to see more sites using XHTML, even transitional XHTML, with CSS for styling and layout purposes. Documents end up much more flexible and quite a bit smaller. It is also easier for end users to override the page's CSS with their own to either make elements more legible or friendlier for their output device (PDA, cell phone, screen reader).
Coders of CMS engines: Please use sane template systems so it is easier for your poor end users to make their pages better comply with web standards. Also don't wrap stuff in tables, not everyone uses tables to lay out their pages! Presentation logic is fine and dandy but don't hard code layout elements, let the users decide! Thank You.
I'm a loner Dottie, a Rebel.
Plans are in progress
Yeah, right.
nt
It's not a surprise to hear someone complain about XHTML and CSS and all that goes with it. People have become complacent with markup. When HTML was the only way you built Web pages, people thought "Cool, this is so easy, anyone can do it!" and this was true. Anyone who could, did. But then rules got involved. Browser makers went on their own paths, interpreting or altogether ignoring W3C recommendations and spec and causing a new breed of technology employees major pains in their collective ass.
If you wrote HTML, you had all the browsers effectively working against you. You still do today. They are slow to incorporate W3 standards, and even when they claim to do so- the engines still interpret the meaning of the markup slightly differently. The DOM support has gotten way better, but there are still differences between browsers and even within versions of the same browser. Take IE for example. Simply adding the DOCTYPE tag causes all three versions to behave different from themselves! Even if you use XHTML 1.0 Transitional, you're still going to face rendering problems. They can all be gotten around, but it takes patience and experience.
Not just anybody can sit down and author HTML for a complex page that looks and behaves the same across platforms and browsers. Clearly, not EVERY browser, but it can be done. I regularly build sites that support IE 5 >, NS 6.2 >, Mozilla 1.8 > on PC and Mac and Safari on Mac. But, I have the experience of doing it for years, and the time to make sure it gets done right. The moment most authors are faced with writing code that works outside their favorite browser most give up and slap a "Best viewed in..." disclaimer on their site. This isn't really their fault, they may not always have the time or resources to do it. Others are driven by project requirements that say it should only work in such and such browser.
Really good front end developers are frustrated because there is STILL this mentality that any idiot can write HTML. Sure, but only a few of us can craft it and weild it like a blade. I would argue that authoring markup to be cross browser/cross platform requires the same level of understanding markup (HTML/XHTML) CSS and JavaScript that a C++, Java or other compiled language author must know about that language. There isn't an IDE in the world that can generate x-browser/x-platform code involving those three things (markup, JS and CSS). Some come close or do certain things really well but it's just a fact that the browsers behave too differently to do it. Unless YOU KNOW how to make it work, it likely won't using an HTML generator. Products like Dreamweaver are fine, and they have their place. But they are not a substitute for someone who knows what they are doing.
If you still think the problem is in the spec though, that's fine. I would recommend using a looser one and giving it another shot. I mentioned XHTML 1.0 Transitional earlier. This is, in my op, the best one to start with and use if you are really wanting to adhere to XHTML but don't want to give up some of the things you know and love (or hate, but need to use anyway) like table cell attributes that would otherwise be deprecated. If you're producing pages that should work in PC and Mac browsers with equal functionality and appearance, this is the one you want.
R(k)
will be sure to acheive the desired effect.
I really dislike sites that use javascript redirects. I use IE with *all* scripting turned off, so I have to view the source and manually enter the URL when someone gets cute and uses a javascript redirect. Jerks.
I bet it has a much bigger market share than some of those browsers. And no, Safari is not the same.
It's horribly painful to create a decent layout using strict XHTML and CSS. You can make some nice-looking things after a bit of work, such as the samples at CSS Zen Garden. However, try looking at the CSS file for any of the nicer designs. They appear to be completely hacked together! Separating the CSS stylesheets from the XHTML source makes them even harder to understand, since you can't figure out which element has which id/class and what order the elements come in.
For 99% of site designs, tables work perfectly well. You want some header accross the top, a sidebar with links on the left, perhaps another sidebar on the right, then some content and a footer that spans the bottom. It's very natural to perform a layout using rectangular blocks. If you look at any print publication, it's probably also laid out using blocks.
When you're making a website, one of your main goals is to make it look good. If you just wanted to give the user annotated data, you could just give them a plain XML file.
As much as I like the work of W3C, it's as if they are stuck in a time warp where they could actually effect development patterns. It's not 1994 any more, and there's so much existing infrastructure in HTML 4.0 (or similar) code and horrible Ineternet Explorer interpretation of that code that little will happen for YEARS. The lead time on their final specifications are probably at 5 or 6 years now.
Don't get me wrong-- they're doing the right thing, but it's as if they could shout at the top of their lungs that MathML and SVG should be standard and no one will care. Oh wait, nobody does. How many browsers support either "out of the box?" If you were to add up their market share it would be in the single digits.
It's time we just realize, as web developers and designers, that we are stuck with a horribly inefficient means to share information that is worsened by the lackluster industry movement required for change in the way we get at that information.
I'd say this is a new thing, but it's not. Look at any industry and the same thing always occurs.
"Politicians find new names for institutions which under old names have become odious to the people."
Basically, we got to choose between using not using JavaScript or supporting MSIE, but not both. I campaigned for the former; my boss picked the latter and he and his paycheck-writing skills won the discussion.
For the sake of customers like yourself, I added a clickable link that's encased in <noscript> tags to the new page. The whole reason that we have an intermediate page is that the destination page takes about 90 seconds to generate, and we wanted customers to have "instant" feedback that they had successfully clicked the link. We didn't want them to sit there click-click-clicking all afternoon as query after query queued up on the server and the application ground to an agonized halt.
If we could get all of our customers to upgrade to a standards-compliant browser then my life would be much easier and I could use the right tools, not just the ones that happen to work. Still, I've at least managed to keep the entire site validateable as XMHTL 1.0 STRICT (plus validated CSS), so things could be worse.
Dewey, what part of this looks like authorities should be involved?
Read the EFF's Fair Use FAQ
someone doesn't know what formatting option to pick.
I do like how your post trailed off into bold italics, though. Nice touch.
This isn't a troll, it's valid. Slashdot's HTML is terrible. Go read the dillo mailing list archives.
It was clearly not posted to offend. Just a joke site anyway.
This guy is way out there
I've been "coding" to XHTML transitional for a few years now, and have noticed recently that a lot of the sites being created or redesigned now are also opting for it rather than the old HTML401.
XHTML is just a reformulation of HTML as an XML application. In other words, beyond syntax and well-formedness they're largely the same.
All the old bandwidth-wasting presentation elements (like <FONT>) are now CSS presentation ATTRIBUTES of any element by using id= class= and style=
This goes for HTML 4.01 as well. Both HTML 4.01 and XHTML 1.0 have the three DTDs: Transitional, Frameset and Strict. The goal of separating presentation from structure/content (and putting it into stylesheets) has less to do with HTML vs. XHTML, and more to do with Transitional vs. Strict document types.
The Strict DTD disallows all deprecated tags (such as <font>), and this is really what you want when working with presentational information exclusively in CSS, because the Strict DTD will force you to do so - assuming you're not too tempted to use inline style= declarations. But again, you can do this with both HTML 4.01 Strict and XHTML 1.0 Strict. For XHTML 1.1 there is only one DTD (which is Strict implicitally) - the last step in ridding the world of tag soup pages (assuming we're going to get busy using the application/xhtml+xml media type, but that's another matter).
To recap, if you have HTML 4.01 Strict, you can switch to XHTML 1.0 Strict easily with a little syntax tweaking (with few exceptions). When you have XHTML 1.0 Strict, you can switch to XHTML 1.1 by just chaging the DTD at the top of your document (again, with few exceeptions).
So why use XHTML? Well, because you can parse it with XML tools and do all kinds of neat things with your pages in, say, a server backend before you push it out to clients as whatever XHTML or even HTML you like.
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
I go out of my way to make sure every site I design is XHTML 1.1 compliant, and the CSS validates. I live the w3c's validators. Great things, they are.
So unless you are willing to set up content-negotiation, sending different document types to different browsers, and unless you have a niche market that use browsers that understand these new features, you really aren't going to get anything from XHTML. Not for a few years, anyway. (my emphasis)
So true! And right now, the biggest obstacle for the adoption of XHTML - used with the proper mentioned media type - is really Internet Explorer's dominance and lack of XHTML support.
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
<rant> Amaya v 8.5.0.0 (apparently, the current stable version) takes an HTML 4.01 transitional page, using CSS1 and that small subset of CSS2 that happens to work across-the-board with Moz, IE and Konqueror, and trashes the layout, even tho the html and css have blessed by the w3c html [http://validator.w3.org/] and css validators [http://jigsaw.w3.org/css-validator/] -- as they were also by CSE's html validator and by Top Style's css tool).
Recognize the above is tantamount to a sideways plug (but note: no links as there would be if this were a disguised promotion) but given the stats I get off my servers, I'm going to keep on worrying about the vast preponderance of visitors who use IE, NS and Moz and who -- just BTW -- are predominantly using dialup, where compactness really counts!
</rant>
And -- re some other comments on this story -- I find XHTML to require a significant size increase to achieve the same effect as can be done compactly with 4.01 + CSS... and without, as another poster noted, spending nearly as many hours debugging as I (for one) need to clean up XHTML. Feel free to argue that that's an experience/knowledge issue, but what are we gonna' do for those whose real contribution to the net is content -- ideas, pictures, arguments -- rather than scrupulous code.
[this sig has been trunca
Damn, I thought this would have been modded up already!
The linked text should be required reading for all people who use XHTML. Don't be fooled by the title, it's actually the best advocacy for proper use of XHTML. It also presents the drawbacks of the current improper use of XHTML (on pretty much every site on the Internet).
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
I couldn't agree with you more. It irks me to see people taking a position to not use the W3C standards. You don't need to encourage that... everybody programs against W3C standards. It's not like there's some magical treasure in coding poorly. Anybody can and does do it.
If message boards want to make it simple for everyday people to mark up their messages, they can do what they've been doing: process the basic markup into valid XHTML code. Any good message board code will clean and validate all of the input, first. Running vanilla HTML or XHTML makes no difference. You are responsible for your site.
If I had mod points, they'd be all yours, parent.
Skip the intermediary standards and do pure XML data with XSLT, XPath, etc.
Damien
You should neither need to do javascript or redirect. You can use a multipart mime-message. First generate a HTML page with "please wait" then calculate the new page and when it is finished push it out on the same connection.
What you could even do is push multible pages, with a continued estimate on how long it is still going to take, say every 10 seconds. It can know this because you are pushing these pages in the same process as the long calculation is.
:%!tidy -q
These eleven keystrokes (including 'enter') mean 'replace all the lines in this file with the result of piping them through the command "tidy -q"'.
This should work for any version of vi, but vim really is the best.
I often begin an HTML doc with
Page description
And then ":%!tidy -iq -asxml" fills the rest in for me, indented and everything.
This blog is quite interesting. I had no idea such a thing existed.
http://www.petitiononline.com/googhtml/
libguestfs - tools for accessing and modifying virtual machine disk images
So you say that website with tables used for design are more easy to read ? Are you sure ?
d io.asp and listen what a blind person can ear when a website use unecessary tables.
:)
Have you ever work on the website of another person, company, project using table for design ? It sis totally impossible to maintain it without losing much time.
Now about the goal of a website, it is not to look good but to provide information. Now if it look beautiful too it is better. But information is the main point and accessibility - I mean information for everybody (blind persons, persons using their mobile phone,...) With tables for design accessibiliy is not possible
Foolow this link http://www.humanfactors.com/downloads/chocolateau
Moreover XHTML is more easily readable than XHTML for web-engine. With the separation of content and design you win lot's of bandwidth. Etc.
All my websites now use XHTML and CSS and I am very happy with this. It work perfectly and I win so much time than bfore using tables. I can change the look of all my website by changing one file. Do this with table and without server languages (PHP,ASP,...).
XHTML rox ! CSS rox ! HTML will die slowly
..english language validator? ;oP
I am NaN
For 99% of site designs, tables work perfectly well.
No they don't, they can throw off screen readers which (rightly so) expect tabular data to be in tables.
Every site I've done in the past few months has been completely xhtml and css based. Sure, the first few times took a bit longer than before, but what I find now is that it takes me less time than it used to for a table based layout! Plus, if the client comes back a few months later wanting a redesign it's much easier because my content is separate from the visual display, so all I do is reorder some divs, update the stylesheet and bam, it's much quicker and thus cheaper for my clients.
one of your main goals is to make it look good.
No, the main goal is to make it as accessible as possible, then make it look good. What good is a flashy site if you cut out several % of viewers?
I am NaN
Can you separate content from form?
We should've stick to ASCII.
[o]_O
...there are many languages out there which follow these rules, and humans always tend to hate them.
Why should we need a semi-colon to end a statement. The line feed should be enough. Well, that's the way it was in assembly language and shell scripting, but people bitched and moaned, and statement-separators have been a part of both kinds of language ever since.
Why should we need a closing brace. Cannot the compier SEE that it is the end of a block simply because the indenting is different? And yet, whenever Python is suggested as a language, the usual response is some language bigotry about "the indentation nazis taking over." Heck, even Stroustrup tried a variation of C++ where the try/catch blocks didn't have to be enclosed in braces, because the "try" and the "catch" made everything redundant. The compiler was just fine with it, but the people using the language clamored for the braces to be put back.
I'll stick to Python, but I'll let the sloppy Perl coders share the same air as me. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
and a good CMS to boot. www.drupal.org
are you joking?
I suppose if you mean 'render' as 'can use without logging in'... or mabye i'm justing an old version of dillo?
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
Now that every browser anyone would dream of using supports IMG in some form, even if it's just replacing the element with the contents of the ALT element, it's easy to forget about its heritage and not correctly shame the creators of this, one-broken-always-broken element.
IMG was added to Mosaic back in the day, and after it was implemented it was submitted for peer review. The "peers" correctly noted that the use of an 'alt' attribute to handle browsers which cannot display the image is inadequate because pre-IMG browsers will not render it at all. In addition, it can only accept plain text and not full markup, so it is impossible to provide proper fallbacks in non-trivial cases. Sadly, the Mosaic developer responsible for IMG decided that since it had already been implemented as submitted, and Mosaic was the browser of the time, it wasn't worth the trouble to rewrite the support for this element in their tag-soup parser.
Today we have OBJECT which works as suggested by the peer review of IMG back in the day, but IMG has become so ingrained that no-one can feasibly use it. OBJECT is clearly a superior solution, supporting all kinds of object and providing multi-tiered fallback simply by nesting OBJECT elements within each other and finally nesting other elements such as IMG.
I'm not so sure that I agree with this new "everything is potentially an image" idea, though. It seems nice in theory, but just that example of a SPAN element inside a P element shows that it's all just an awful hack. It's a good start, but it seems like they didn't really think it through properly.
As a Web developer I can tell you that there is 90% chance that XHTML 2.0 will never be used by anyone.
/> is evil, but it is still neaded. <l> does not replace it. <l> encapsulates, <br /> separates. <hr /> as been changed to s everywhere. And, there are the ones that pay's the web developpers. I know, I can, and will, do everything that's possible to make my web pages validate to web standards and have the best semantic HTML that is possible relative to everything else (incompatible CMS, marketing divisions, Flash, tight schedules, fellow web developer that don't test except in IE). But leaving
First, it does not add anything really useful that you could not do with XHTML 1.0. Well, there are things that are useful (in related standards actually), but there are too complicated to be implemented in current browsers (XForms, XML Events, add all of SVG to that). <section> and <l> are great, but you could do similar things with <div class="section"> or even "gasp" <nobr> (I know, nobr as only a visual meaning, but you could infer a real semantic meaning if you really wanted to).
Now, if it added something that would really change something for the Web developer, like in XAML (I don't know a lot about it, it seems interesting) I would eagerly wait for the implementations. What the WHATWG does seems a lot more interesting.
The next real web standard will be to HTML/XHTML what client server computing is to dumb terminal / mainframe computing. Anything that does not go in that direction will not be accepted by the industry. XHTML 2.0 is completely uninteresting in that regard.
And for crying out loud, I know <br
just takes the biscuit!
Sorry for the rant, the awful english and the bad Hitch Hicker's to the Galaxy references.
That wouldn't work for us. We're using a Zope server, and the queries that take ages to run are isolated in their own objects. The page that displays the results has no knowledge of the internals of the query objects, other than that they return some interesting attributes.
Dewey, what part of this looks like authorities should be involved?
So which browser should I use to be up to the latest "standards compliant" ... and also work reliably the way I am used to working? I've tried Firebird, which is Mozilla based. But it has too many bugs and mis-features for it to be my default browser. I can still start it up when needed, but it's a pain because I have to set about 20 configuration items each time because it won't save them correctly. Netscape 4.77 is my default browser with Netscape 3.04 as a fallback when I get some really raunchy HTML.
FYI, I use Linux, so please don't suggest IE.
Note: this post is an entrapment to get free tech support.
now we need to go OSS in diesel cars
Separating the CSS stylesheets from the XHTML source makes them even harder to understand, since you can't figure out which element has which id/class and what order the elements come in.
Get Firefox and install the Web Developer extension. It has a feature called View Style Information. Turn it on and your mouse becomes a crosshair. Click on an element and you can see exactly which CSS rules apply to that element.
Never mind the fact that XHTML is acctually easier to use than HTML because the rules are stricter and clearer.
You are *such* a fucking pussy. Hang it up and go home.
"Boo-Fucking-Hoo, valid HTML's too hard to write for more than 30 lines. My pussy just swells up & falls the hell off if I have to use vi! BWAAAAAHHHHHH!!!!!"
What about MathML?
Cause another damned standard will be out next week
So, why do we need a strict language that will barf at the first syntax error ?
Languages don't barf at syntax errors, browsers do. And I suspect that IE will be very, very lenient with XHTML syntax errors, just like it has been very, very lenient with HTML syntax errors. Why? Not because Microsoft wants world domination (they want that, too, of course), but because they don't want to have to deal with support calls like "this page renders in other browsers and IE is broken for not rendering it". XHTML provides an opportunity for browsers to become more strict, but chances are, they won't, and it's unclear that they should.
The real problem is that {HT,X}ML wasn't designed for usability, so people make mistakes and take any shortcut they can. The way to fix that is not for software to barf at either users or authors, the way to fix that is to fix the f*cking {HT,X}ML syntax to be more user friendly: i.e., scrap the effort and start over and create a new, entirely different markup language for the web.
Of course, hell will freeze over before that happens, so authors will have to live with lousy syntax and browsers will continue to accept the errors users make. Life is not perfect.
"Now we have XHTML and CSS. Neither of these are easy to learn. Neither of them is easy to use. Less technical people are incapable of using either. This is great for job security for webmasters, but for the growtrh of the next and for the internet as a medium of free and easy communication its horrible. XHTML is broken as an HTML replacesment because it does not meet the original purpose of HTML- to be something that anyone can easily learn and use."
You know, I think I know part of the reason our jobs are being outsourced. Here we have someone basically complaining about how technology has changed, and is growing up. That's something technology will always do. But does the poster embrace this change, and approaches it with a "can learn" attitude? Afraid not The reason given is that the "less technical" can't handle it (presumptious, and insulting). Sort of a geek's "think of the children" You will note that the people who are learning CSS, and XHTML and all the rest of it, don't have such hangups about technology. They recognize it's changing. They recognize that they can learn (They don't go on long dirades about how incapable they are). And they recognize that other's inabilities are their opportunities. You people want your jobs back? Losing the defeatist attitude will go a long way. If you can't keep up with technology, then why did you go into this field?
Why you shouldn't use XHTML.
I honestly see no reason to use XHTML especially if you arent using XML data within your web application. so many things XML are getting hyped up as much as those other BIG things with BIG acronyms that get hyped in the tech community. Standard HTML and CSS work just fine for general display purposes in your web site.
Many big companies still use plain old delimited files, Java has not made the network a replacement for your software and Push technolgies hasnt changed the web at all.
Any more hype?
and my God Slashdot, This message board is a disaster in UI.
You are correct sir! Unless you are handling content negotiating with XML than there really is no reason. The better thing to make the size of your pages smaller and faster is to use CSS instead of tables etc.
Obviously you can't benefit right now, but if nobody moves to XHTML, there never will be!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I mean really, why? The FAQ does not answer this, the FAQ explains how XHTML works, how it is different and all that. But it doesn't explain why I should change. It explains why HTML is bad, or to be more accurate how easy it is to write bad HTML, but that is not sufficient reason for me. Sure if I want to use some of the newer features, I need to use XHTML, but I'm not seeing anything I need there either.
Here are some reasons *not* to change:
1. It doesn't work in IE without a nasty work around. IE is still the dominant browser last time I checked, despite a
2. It doesn't work in older browsers. Some people still do use them.
3. I have a boatload of stuff in HTML and experience to match. Any time spent upgrading that for no real benefit is time wasted.
YMMV.
meh
You'd be interested in this project, in that case:
4) http://poopmup.sf.net
Considering the quality of HTML that Microsoft Word generates,
For me, almost always the quantity of html, the damned thing generates, itself had been the problem.
The above comment is very pertinent and informative.
I would mod this up as insightfull.
Léa Gris
Took me (a chemical engineer/C++ coder with no design ability at all) no time at all to knock up a (IMHO) good looking site. It's not exactly complex, but it was easier than using tables. Surely you're not saying the world's highly trained web designers are less capable than a glorified plumber?
> Languages don't barf at syntax errors, browsers do
Correct. I posted too much in a hurry (which also probably explains the huge number of typos I made. Sorry).
> IE will be very, very lenient with XHTML syntax errors [...]. Why? [...] because they don't want to have to deal with support calls like "this page renders in other browsers and IE is broken for not rendering it"
But other browsers (like Mozilla) already choke on a malformed application/xhtml+xml page. Hence, I think this point is moot. Also remember : the only ones who will be biten by this feature will be the ones writing HTML by hand (rare, and intelligent enough to RTFM) or those using antiquated authoring tools (a way for MS to sell them FrontPage.NET 2019, with added XHTML compliance :-)
> The real problem is that {HT,X}ML wasn't designed for usability, so people make mistakes and take any shortcut they can
I disagree. You could also argue that C, or even LaTeX weren't designed for usability (and you would have a point ;-) But the difference is, a syntaxically incorrect file in those language won't be accepted by the parser. Thus, you see a lot less broken C/LaTeX code floating out on the 'Net. The real mistake was to allow for syntax errors to be accepted instead of creating usable authoring tools in the first place.
> the way to fix that is to fix the f*cking {HT,X}ML syntax to be more user friendly: i.e., scrap the effort and start over and create a new, entirely different markup language for the web.
We often feel that a system is broken when it doesn't adapt to our way of thinking. For instance, I find HTML too verbose, and the table syntax is horrendous. I also find the Linux Filesystem Hierarchy Standard to be quite hairy, my keyboard mapping is totally stupid, and I could go on and on. Since I touched a computer, I felt compelled to reinvent the wheel many times. But reinventing the wheel would mean people would lose all the know-how they've aquired over time, there would be painful transitions, and so on. It would just be rejected (think about the Dvorak keyboard. It's probably better, but it requires an adaptation period, hence its failure. Or think about Linux on the desktop). Backward compatibility (even if limited) is just necessary to get people to move over to the new standard. Trust me.
> authors will have to live with lousy syntax and browsers will continue to accept the errors users make
Are you sure ? XHTML provides for simpler syntax (by relegating the presentational code to CSS). And some browsers already do not accept errors for pages sent as XML documents. I'm not saying the Web will be totally valid overnight, but as the legacy code gets phased out, the situation can only improve, IMHO.
Xenu brings order!
I will bet you any amount of money that there are more actual XHTML sites on the internet than there are actual HTML ones. Because browsers render absolute HTML shit soup when given it fine, people write HTML shit soup and think they know HTML.
In fact, if you want to code XHTML shit soup, you can as long as you send it as text/html. It won't be XHTML, but neither are most webpages HTML.
It is much easier to write proper XHTML than it is to write proper HTML, so people who care about propriety and validity write XHTML.
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
It should be noted that em and strong are not 100% equivalent to i and b . Specifically, you should also be using cite, var, dfn, and a few others when you are actually dealing with a book title, a variable name, or a word that's defined in the sentence it's in.;)
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
"One reason I test my web apps in many browsers, if it dosent look the same in all of them, I'm not doing something right!"
Or the browser isn't.
You could also argue that C, or even LaTeX weren't designed for usability (and you would have a point ;-) But the difference is, a syntaxically incorrect file in those language won't be accepted by the parser.
C compilers have incompatible extensions, but many users don't use them because they want their programs to be portable.
LaTeX has just a single implementation, so the question of variability among implementations doesn't arise.
But reinventing the wheel would mean people would lose all the know-how they've aquired over time, there would be painful transitions, and so on. It would just be rejected
It depends on how, when, and why. Replacing XML, HTML, or XHTML would be hard, but sooner or later it's going to happen, probably with some form of backwards compatibility.
Are you sure ?
How can one be "sure" about anything in the future? But it looks unlikely to me that Microsoft is going to make IE more restrictive because anything else is just too much of a pain.
It doesn't matter.
It irks me to see people taking a position to not use the W3C standards. You don't need to encourage that
Other than that XHTML 1.0 Transitional was the last W3C HTML standard to support semantic numbering of list items (the value element of the li element) or dynamic replacement of object contents on click (the target element of the a element), both of which were deprecated in XHTML 1.0 and removed from XHTML 1.0 Strict and XHTML 1.1?
Other than the inability to set proper XHTML media types through some web hosting providers, combined with a setup fee to switch hosting providers?
Other than Microsoft Internet Explorer's inability to read XHTML documents served with an XHTML media type without an obscure hack?
Other than the absence of a canonical default stylesheet for web authors to start from, making XHTML 2.0 complicated to get started with and discouraging look-and-feel consistency among web sites? In HTML 4, links are blue + underline because browsers have their own stylesheets for HTML, but no current browser understands XHTML 2 without an external stylesheet, and it appears to be each web author's job to duplicate effort in creating such a stylesheet.
Little inconveniences like this are why people stay on HTML 4 rather than one of the W3C's newer XML applications.
As for simplicity, XHTML (strict) has fewer tags than HTML.
In XHTML 1.0 Strict, how do you code a list that starts at 6 and ends at 10? No wait, you can't because <li value="..."> was deprecated and thus removed from Strict. And how do you designate that a link should open a page within a given object element without <a target="...">, which was also deprecated?
And a lot of those CSS designs either fail royally in the 85% browser or require extremely hairy hacks to get them right in the 85% browser.
CSS can do anything a table-based layout can do
If 85 percent of graphical user agents get tables right but CSS wrong, what would you use?
Also note that users of IE4 and IE 5.0 (and 5.5) obviously aren't using Windows Update.
If you look closer at their user agent strings, notice that some of them aren't even using Windows, let alone Windows Update. IE 5.x for Mac OS has its own set of bugs.
Do you like Strict? If so, I have a question for you. What's the Strict way to express a list with five items, whose first item is numbered 6, and whose last item is numbered 10? (<li value="..."> is deprecated.) And what's the Strict equivalent to Transitional's <a target="...">?
And here's why we're not going to see application/xhtml+xml any time soon.
Instead, you should think about what you're actually making -- a list of links. Therefore, use
And chances are that if you do something the "right way" with CSS, then then IE 6 will go and fuck it up.
Go look at CSS Zen Garden. Then go look at the source code and all the hairy hacks to work around the deficiencies of the 85% browser.
SELECT * FROM my_dogs
</script>
if different from
<blockquote>
...
...
SELECT * FROM my_dogs
</blockquote>
Embedded images:
...
WdRERscsdfD
Gh8Xds=
open4free © : XHTML 2.0 for FireFox-1.0.0?
SELECT * FROM my_dogs
</script>
if different from
<blockquote>
...
...
SELECT * FROM my_dogs
</blockquote>
Embedded images:
...
<mime img=my_doc.png>
WdRERscsdfD
Gh8Xds=
</mime>
open4free © : XHTML 2.0 for FireFox-1.0.0?
SELECT * FROM my_dogs
</script>
if different from
<blockquote>
...
...
SELECT * FROM my_dogs
</blockquote>
The embedded images are useful to make only-page-xhtml:
...
<mime img=my_dogs.png>
WdRERscsdfD
Gh8Xds=
</mime>
open4free © : XHTML 2.0 for FireFox-1.0.0?
Jakob Nielsen wrote about frames and iframes: "All of a sudden, you cannot bookmark the current page and return to it (the bookmark points to another version of the frameset), URLs stop working, and printouts become difficult."
The bookmark problem happens with POST-driven interfaces as well, such as many webmail apps. And how would one create Google Groups without frames?
"Even worse, the predictability of user actions goes out the door: who knows what information will appear where when you click on a link?"
If there are two frames side by side, one for a list of messages and one for the message, what's so unpredictable about that?
About the deprecation of <li value="...">: read this.
Actually, a far bigger problem I find is that it's not obvious (and is sometimes ambiguous!) from the spec what various combination of CSS attributes should do to output. Because of this, a Web designer or developer must test their work in as many browsers as they wish to support, or face unexpected results.
With a reference implementation, a designer could test their work against that implementation, and see how it should render. If it differs from a given browser, they can tell the browser authors what the problem is, and how the reference implementation renders it, rather than arguing over ambiguous semantics.
(The biggest problem is that the only standard on the Web which matters is "Works in IE." You cannot produce a page you wish to have viewed by a large audience unless it "Works in IE." Ultimately, that means any page done for or by a business will have to "Work in IE." IE doesn't support XHTML, nor CSS 2.1. Sucks to be the Web.)
Semi-colons are optional - you only need them if you want multiple statements on one line.
There's neither closing nor opening brace, nor BEGIN and END keyword equivalents. The indenting is all the compiler needs.
I don't know about all language compilers, but one at least does just that. (As well as being a language with very few keywords, making it even easier to learn and use.)
http://www.isolani.co.uk/blog/standards/CostOfSupp ortingNonStandards
The IE team is not working on standards compliance, nor do they have any plans to.
You mean your homepage? You're using a table to layout the browse images... I'm not a rocket scientist but
Slashdot doesn't need to switch to XHTML simply to use CSS. They can add CSS without changing much of anything, in much the same way I use my User Stylesheet in Opera, along with slashdot's Lighter version in Slashdot preferences, available when logged in.
- I don't need to go outside, my CRT tan'll do me just fine.
Here's how I do it:
Rule #1: Avoid floats unless absolutely necessary
Rule #2: Avoid nested floats...period
Rule #3: Side bars get position absolute and have width specified in ems
Rule #4: Main content area is given margins (or padding, depending on your needs) equal to the widths of the left and right content (in ems)
Rule #5: Make sure the content area is lower (z-index) than the sideboxes
Rule #6: Write for Mozilla/Opera/Safari first and port to IE later
Rule #7: Use IE7 to help port to IE instead of raw CSS hacks
Works for me.
- I don't need to go outside, my CRT tan'll do me just fine.
I meta-modded you unfair. This article is about XHTML, and the posted site is strict compliant.
http://validator.w3.org/check? &uri=http://www.gnaa.us;verbose=1
Okay, you may have some points, but my point is this:
/.'er). Stylesheets as a design concept are no big deal to the average user - Word's supported them for ages. If the editor supports XHTML and CSS natively, then this is a step forward to having non-broken websites all around. Websites that I can properly browse from my phone. Websites that comply with section508, so my incredibly nearsighted cousin can see them. As it stands with current HTML these things are quite doable, but not always intrinsically obvious to an average user (or even apparrent). A move to XHTML and CSS may not democratize markup the way HTML was supposed to (and, in my opinion, failed miserably), but it will democratize browsing, which is a far larger audience.
HTML is not easy. Not if you want it to work. Hence the proliferation of monobrowser sites, sites that are broken in many ways, and the annoying excess of marquee tags out there.
I've worked with a number of really big companies, with lots of people who have to develop content for the web. The vast majority of them do not bother to wrap their brains around HTML at all, choosing instead to hit "save as HTML" in Word or...ugh...frontpage.
When it comes right down to it, things are going to stay that way. People are going to use editors far more often than they're going to use vi for their markup (unless, of course, they're a
----
"I used to listen to Null Device before they sold out."
Use verse elements with no margins and padding. Make them children of stanza elements that do have margins.
I think I understand what you're getting at, lines themselves being elements rather than separated by elements, and stanzas being paragraphs. But what are the new elements called in XHTML 2, or do we need a separate XML application for this? And how will we re-educate amateur web authors to use the new markup?
Not as funny as the Firefox parody.
They are not meaningfully comparable.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD