Slashdot Mirror
HTML to be 'Incrementally Evolved'
MrDrBob writes "It has been decided that HTML is going to be incrementally updated, as the W3C believe that their efforts with XHTML are going unnoticed or unused by many websites out there. HTML is going to be worked on in parallel with XHTML (but with no dependencies), with the W3C trying to evolve HTML to a point where it's easier and logical for everybody to transition to XHTML. However, their work is still going to attempt to improve HTML in itself, with work on forms moving towards transitioning into XForms, but bearing in mind the work done by Webforms. In addition, the W3C's HTML validator is going to get improved, with Tim Berners-Lee wanting it to 'check (even) more stuff, be (even) more helpful, and prioritize carefully its errors, warning and mild chidings'. This looks like a nice step forward for the W3C, and will hopefully leave all the squabbling and procrastination behind."
We cannot have new HTML without upgrading the best part of the web.
Example of server side blink
Wonderful!?
liqbase
Yea, I'm sure that changing which policy it's all listed under will change what all of the lazy web developers and their authoring tools will produce right away
Because we all know God created HTML in 6 days, and evolution is impossible. ;-)
HTML should go in a direction where content and form are truly separated. Have a document (or part of a document) mark the content in a purely logical fashion (like XML) and another document (or another part of the document) describe a presentation and which parts of the content to use where in that presentation.
HTML relies too much on the order of the content for presentation. It should be more like the workflow in a DTP program: Add a text box to the layout, then fill it with text.
What practical effect will this have? As long as browsers will render junk (X)HTML most people won't bother with an updated standard any more than they do the present one. Learning any proper coding system is work. What's the incentive other than pride in the craft? Firefox, IE, etc. make learning standards optional, which is just another word for more work.
I don't really see how this will improve the chances of their standards being adopted. It's not exactly like the leap from html to xhtml is all that confusing as is. This will just be even more confusing. Good luck getting all of the major browsers to support all of these incremental changes when they can't even keep up with the standards suggested years ago.
The answer is - we DONT need it.
Thats as simple as it is.
As it is, html serves its purpose. Neither the visitors nor developers need more from html.
It is a problem with such groups like w3c that they have a baseless belief that even something that people are satisfied with needs tampering with.
Read radical news here
I welcome the idea that at last the W3C has get down from their high views and realize that most of the web is HTML and unless the web browsers are able to understand new markups the web developers can't use them. So instead of forcing everyone to dump everything they know the right approach is to fix existing problems in the current specs and move them forward to such ideal world step by step.
But I don't like the tone of the message itself as it refers to the WHATWG:
As the WG is currently formed by developers from 3 of the 4 browsers engines, it would be a real disaster to ignore all they current workLooking forward to more crashing browsers and garbled pages due to the new stuff. There's a LOT that can be done with standard HTML, even if it is tedious to do so, without turning it from something elegant into a whopper of a monster.
Where were you when the voynix came?
I think the way the W3C are going to try and go about it means that they'll gradually upgrade HTML so that there will eventually be a clear and simple transition path to XHTML, and therefore more websites will make the jump into the land of order.
The problem with XHTML is that if your code isn't absolutely perfect, the parser dies with (usually) unhelpful error messages.
This "feature" makes it unsuitable for sites that allow users to add content.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Why are webmasters who are currently ignoring XHTML going to be any more interested in Yet Another Dialect of HTML? At least XHTML has some advantages (like being a well-defined standard, being well-formed XML, and therefore being able to use it with XML technologies such as XSLT). It's not as if W3C provides the tools used by the non-conforming webmaster or anything. As long as there are significant numbers of sites that use bad HTML, and tools that produce more bad HTML, browsers will continue to parse bad HTML, and the pressure for people who don't care about standards to follow standards will remain slight. Come to think of it, even XSLT provides "un-XMLing" features when in HTML mode. If W3C announced a deal with Microsoft and Adobe to phase out bad HTML "features" from their website creation tools, there might be a chance of changing something...
Virtually serving coffee
You mean some standards committee somewhere pulled a solution in search of a problem out of its collective rectal database?
:-P
No! Can't happen!
The W3C should release updated "HTML" specs only with both reference code for parsing, any state-setting, and any rendering, and validator with UI to test HTML for compliance.
UA makers should be able to submit to the W3C new proposed specs with both reference code and validator.
HTML versions should be date/timestamped, and validated between UA and server.
That kind of open, but moderated and encapsulated process will help ensure new specs are not only workable, but distributed to all UA makers (and programmers targeting them) uniformly. UA makers can produce their own code, as long as their HTML validates and the state/rendering results are consistent with the reference results.
A faster, more open, more comprehensive process. More uniform upgrades, more compliant/working websites, less programmers targeting specific browsers "because they work".
--
make install -not war
HTML at the moment is solid, robust, and gets the job done. As it has evolved it has gained additional features and power at each step, including CSS integration, better javascripting, DHTML, etc, thus leading at every step to a better end-user experience.
XHTML for all practical purposes, is HTML but with more errors. With XHTML, you get the power of being told that you have to put an end tag on all
tags. And, umm, not a lot else. The benefits of switching to XHTML are mostly theoretical.
The W3C needs to break the focus on validation, and get back to trying to work with developers and users to get what THEY want into specifications. It sounds like they realized that XHTML will not overtake HTML any time soon, and that they need to provide some sort of reason or reasons to make that change.
The ______ Agenda
HTML has been and continues to be "Good Enough". If there were some truly compelling reason to upgrade to something else most already would have. When image tags were introduced, people abandoned lynx rather quickly, the same goes for transparent gif support, CSS, etc. Its nice to try to bring order or whatever the goal of xhtml is but frankly if its got the ability to slap some text on page, embed and image and throw in a pretty background its good enough for most people, they know it, they are comfortable with it and they arent going to change without a really compelling reason.
Not in the mid-west; God designed their HTML.
I am sure Microsoft have their own view on this, so bollocks to standards.
What difference does it make if an ad is served using well formed markup?
Being forced to use well formed markup has the potential to stop some of the more scummy tricks advertisers use. It also forces them to employ people who understand document structure and these people would generally be opposed to obnoxious ads.
- programming language writers love the process of creating
something so much that they don't care about the consequences. Example:
Pascal. It was a wonderful language. It worked well. It was easy to use
also with low level stuff. Wirth developed Modula, then Oberon.
These were so radical changes that Pascal was killed.
- Small changes can be devastating. Example: why does XHTML
backslashes in hr or br tags.
These are completely unnecessary requirements. XHML did not take off
because who would want to wade through thousands of pages
in HTML written during the last decade and make those changes?
- Too hasty evolution can be a disaster: Example: I'm convinced that it
was the accelerated evolution of Java which essentially killed it
as a valuable tool for the web. What language architects often
are note aware of are the existing resources, books, libraries.
In the case of Java, applets written only a few years ago
suddenly would no more compile because of depreciated language.
Suppose a educator created a Java applet 8 years ago. She has long moved on
to other projects. The language changes. The tool is lost. We can see
that in many examples, where Java applets work different on different
browsers and operating systems. In the case of Java for the web,
Flash has taken over. Now Adobe might make the same error again,
and evolve it too fast. Sorry: a flash 13 plugin needed.
- The German language reform is an other example of
intellectual arrogance. It produced a lot of
controversy.
Language architects have to take into account the huge library
of existing books, textbooks etc, which become obsolete or
awkward after a change of language.
Evolution of languages is nothing bad. But it has to happen so gently that one can adapt and in such a way that old things are still readable and that porting of most existing material to the new level can be realized in time.I believe that this is a response to the actions of the WHATWG (Web Hypertext Application Technology Working Group) (X)HTML 5 and to Bjoern Hoehrmann leaving the W3C QA.
So it's not a new pie-in-the-sky idea like XForms or XHTML2, but something much more likely to be useful to web developers that need to work in a world where IE is (still) the biggest fish.
There's a hidden treasure in Python 3.x: __prepare__()
You want a library to validate the XML and validating XML parsers are common as muck. Easy to check tags and attribs too.
I use HTML 4.01 Transitional in my pages. Why? I am the only developer, so i develop my pages semantically and leave the layout to CSS.
So why not use strict? It is illegal in strict to have a target attribute in anchors, for example. No iframes (if used wisely, they can be intuitive)
XHTML doesn't give me enough reasons to migrate, although i did use it for my old thesis project.
Open Source Java Web Forum with LDAP authentication
People use HTML (not always in the way it is supposed to be used of course..), and people generally don't use xhtml
There are 2 ways to deal with this if this isn't what you want..
1. Make HTML even more crappy and hope people stop using it (they will, in favor of the older less crappy version of course)
2. Make using XHTML easier and more attractive.
I don't see how you accomplish 2. by changing HTML
This may seem like a stupid question, but how else did we go from HTML 1.0 to 4.01 without the standard being 'incrementally evolved'?
Don't you just hate it when people reply to your signature?
One of the best texts I've read on this subject can be found here... http://www.hixie.ch/advocacy/xhtml
"there will eventually be a clear and simple transition path to XHTML, and therefore more websites will make the jump into the land of order."
How many transition paths do we need? Isn't XHTML suppose to be a transition path to XML? And arguably what's been holding back XHTML+CSS so far is likely IE6. But nevertheless, when it comes to commercial web site development, standards are out the window. These sites will mix and match all standards for their desired effect and what works for the many HTTP user agents.
Another transition standard means another 8 years before IE7 adopts it and we would be in the same boat as today with XHTML, IMHO.
Develop a few *actual* applications where the XML-compliance of XHTML is actually useful in an observable way, and everybody will start producing XHTML compliant code for new websites, lest they be left out from a new revolution on the web.
As long as the benefits are just hypothetical (with XHTML somebody could develop useful parsing applications based on commodity XML parsers), try actually developing some such apps that generate real, observable value today, and you'll start convincing people who don't care about standards for their own sake.
I do generally try to stick to XHTML 1.0, since I care about standards and ease of parsing, but the majority of people don't, and they are the target audience the W3C needs to work on convincing.
I'm looking forward to improvements to the validators. Especially a better differentiation between different types of errors.
When troubleshooting old web pages, it is quite annoying to have to wade through hundreds of 'required attribute "ALT" not specified.' or 'there is no attribute "HEIGHT".' to find the real cause of problems, like 'document type does not allow element "TABLE" here; missing one of "TH", "TD" start-tag.'.
Also, when trying to explain to clients why their old web site is crap and needs to be redesigned before it becomes practical to do small changes, a link to the validator page could be useful. We could say something like "see, it is full of bugs; we need to repair the chassis before we can start the paint job". But for that, I would rather show a link to a page with 10 bad structural errors, than to a page with 200 'required attribute "ALT" not specified.' which will not be taken seriously.
"XHTML is, however, a lot harder to write. HTML tolerates a lot of errors, XHTML technically tolerates none, though browsers usually overlook this.
It sounds like the adoption of XHTML is in the best interest of the professional IT community. As a more arcane and precise skill set, you will get fewer amateurs, easier maintenace, and be able to charge more for your services.
We are all just people.
IE7 still doesn't support XHTML.
Analogies don't equal equalities, they are merely somewhat analogous.
Without iframes (currently supported by IE, Firefox and Opera, at least) 4.01 Strict isn't workable for most sites that rely on third-party content for advertising -- eg, ads from Amazon. And that's a large chunk of the web.
Ph-nglui mglw'nafh Gates M'dna wgah'nagl fhtagn.
For 99% of the websites, all you need to know as 'the difference from HTML' is: http://www.w3schools.com/xhtml/xhtml_html.asp
That is for XHTML 1.0, though. XHTML 1.1, and the remaining 1% of websites which go deep into further XHTML functionality are a different matter.
Try reading the recc or RFC 3236 sometime. There's no problem serving XHTML to clients advertising the appropriate MIME string via accept. It's treated as XML otherwise it's served as text/html and treated as HTML.
That's the way XHTML was designed, the only problem here exists within Hixies head.
> Isn't XHTML suppose to be a transition path to XML?
No, no, and still no. It is a specific application of XML.
I've always thought of HTML as Extrementally Involved.
HTML is dead. It's been superceded by XHTML for years now.
HTML was a good idea with some rough edges. It took XHTML to smooth some of them out. Specs that are less vague, more complete, and leave less to interpretation will fix more problems in the future.
XHTML is simpler than HTML (contrary to popular belief) because the syntax and structure is more consistent than HTML. You don't have to wonder whether you need a closing a tag: all tags get closed. All attributes get quoted. All tag names and attributes are lower case. It's really not that hard; if you don't want to do it because you can't read it anymore (you capitalization whore), that's what syntax highlighting is for. You just have to put forth a tiny bit of effort to make turn these rules into instinct.
There are two reasons why the transition to XHTML hasn't happened:
As long as browsers try to interpret messy markup, few people are going to care. It's the "good enough" attitude. "Quirks mode" is the big bad here. Browsers and visual authoring tools need to tell users that the page they are looking at is non-conformant and warn that it may not behave correctly. No other softare on the planet is as forgiving of the data it handles as web browesers.
If GCC still compiled C code when curly braces, paretheses, and quote marks are omitted at random, how much shittier would all the C code in the world be?
At least the W3C is doing something about the quagmire, but working in parallel is just a waste of time. Let HTML be, it's old and busted. XHTML is the new hotness. The W3C can spew out all the Recommendations (the flimsient of terms) it wants, but no one is going to care unless there's some enforcement at the other end of the line.
One thing the W3C needs to do is get off the semantic web high horse; it's putting the cart before the horse. They need to evangelize correctness, and the semantic web (plus other aspects) will follow naturally.
So, all you so called "developers" and "designers", keep on churning out your HTML 4.01 Transitional pages (or let Dreamweaver do it for you) with bloated table layouts. You'll keep contributing to the problem.
I think it's great that these guys are trying to improve an already existing standard.
What? They want to take elements away from us? Who the fuck do they think they are, I'm not going to change all the code on my webpage just because they say, "Oh, using <b> is so 1997, we're all using CSS now."
In short, they can pry my <s> tag out of my cold dead hands.
"Live as if you'll die tomorrow." Ridiculous. You could die later today.
Or are you talking about the need to write your own browser?
-- I ignore anonymous replies to my comments and postings.
Luckily I can see fine, but to visually impaired users, I would think e.g. menus consisting of images without alt text is a very real problem.
This may seem like a stupid question, but how else did we go from HTML 1.0 to 4.01 without the standard being 'incrementally evolved'?
Well, it sure as heck wasn't through intelligent design!
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Yes, that was in 2005!!! that's entirely out of line for a modern program. An XHTML page is not valid unless it has the proper header... his compatibility concerns are moot because XHTML does not have a compatibility mode... it's valid or it's not, make the web page authors bite the bullet and release proper code, don't crap out your product because users might not do it right.
So, wait. Webmasters are ignoring XHTML, so they're going to roll out yet another dialect of HTML that forgoes the advantages of XHTML, but slowly becomes XHTML-like, and expect everyone to suddenly flock to it?
Sure, as a webmaster, I can follow XHTML rules for any new page or script I write - for someone who already writes correct HTML, the nuances are not substantial. Tell a webmaster about the existence of the </p> tag and you're a third of the way there. But do they really expect I'm going to go back and rewrite all those pages I wrote back in '99? Where does the W3C get off remotely invalidating something that was correct when people wrote it, and expecting them to "fix" it? As long as browsers will correctly render old HTML, old HTML will persist.
Caveat Emptor is not a business model.
I don't think this is much a matter of wanting to conform to standards, as it is that the majority of web pages out there were probably built before XHTML became popular.
I think most professionals are probably coding in XHTML, whether by hand or by GUI program.
This is going to be one of those slow-adopting things just like everything else because you don't want stuff to break. Look how long it took us to get rid of the PS2-style mouse/keyboard ports on our computers, even though USB has been around for ages now.
-David
This is why XHTML has failed and will never be adopted: There is no incremental migration strategy. The alternatives to existing valid HTML are bizarre and pointless.
In what alternative universe is <span class="bold">...</span> superior to <b>...</b>?
XHTML suffers from the "Second Systems Effect" http://en.wikipedia.org/wiki/Second-system_effect and should just be ignored.
It seems to me the powerhouse developer crowd here will do just fine with whatever state high grade XHTML will be in once MS IE7 gets its act together and renders standards properly (3rd Quarter 2008?) However, the brilliance behind some of the initial design of HTML was that the inclusive concept of the Web only works if *everyone* feels they have a chance to get in on the fun.
Example: Miss Pelling is an assistant school administrator by day, takes care of her family, and plays Hearts on the third thursday of the month. She wants to make a small webpage to list the results of the four Hearts teams in her gaming group. She only has time to study a little HTML about 5 hours a month, and within 3 months her page is up, and a couple months later, she has fixed the worst of the initial goofs and found a nice background her nephew told her about. About in line with her patience level, starting with month 7 her page is just how she likes it, and she gleefully posts her victory.
I support a parallel development of a "Training Version" of HTML that slowly encourages some of the changes that will eventually prove necessary for someone who wants to graduate to XHTML. Many people want to learn comptuter skills in as forgiving an environment as possible. (Don't we always get called upon for "free IT" every time an Adobe PDF locks up the printer?) However badly distorted in Hollywood, Revenge of the Nerds nailed the mood dead-center: As of 1983, computers simply weren't ready for the masses.
I myself am not a professional coder. In my limited recreational time, I'm not interested in fixing obscure errors. I peeked at XHTML twice, and it's too much right now. But I am willing to fix some bad habits incrementally, so that some such year if I get a 3 month sabbatical, I might be able to learn. I think I just stumbled across some remark that says "tags should be in lower case letters". Oh.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
I have an idea. Since XHTML is XML and can be parsed as such (as stated in another post referencing WIKI) why not have the 'important' search engines out there give kudos points to those that use higher DTDs? I am imagining that if a document is valid XHTML, it can be indexed (XPath?, etc) easier and therefore processed with fewer 1s and 0s and with less ambiguity then HTML.
Nothing is foolproof because fools are so ingenious.
You know the blink tag is based on AJAX when the Slashdot effect makes its blink rate slow down.
That is the LaTeX attitude in a Word world.
Presentation is everything. Humans are emotional, not logical.
PDF and Flash are damn close to what people want. The main thing holding them back is that they aren't as integrated into the browser as HTML.
I'm pretty unimpressed with what's been coming out of the W3C over the last few years; yes, they cleaned up the specs a little, but they produced a disproportionate amount of junk in the same time and I think most of their new standards have been flops.
I think the problem is that the W3C is trying to invent new stuff rather than standardizing existing practice after the market has decided on something. Unfortunately, that kind of approach not only risks going wrong, it attracts entirely the wrong kind of people to an organization like that.
Serving XHTML as per RFC3236 and XHTML1 requires server side switching of the HTTP content type header according to the client accept string. RFC2616 requires the Vary header however qvalues can be ignored because this is not content negotiation. Lynx doesn't support application/xhtml+xml and probably never will so I expect to be doing this long after IE6 is gone.
If you understand what I just wrote (all professional web developers should), then there's no problem. Most casual HTML authors would rightly not have a clue. Obviously browser developers do not want the support nightmare, hence they advise users to avoid XHTML. From my point of view, XHTML1 is an excellent doctype for a public web server and has been for over 5 years. Saying that it's "just not ready" or should be avoided outright is rediculous.
How does 508 require validity?
W3C WCAG 1.0 requires validity at the AA (middle) level.
W3C WCAG 2.0 requires "well formedness" but not validity. The WAI chickened out there.
I paid the going retail price for a Windows screen reader and got a free Unix computer!
I always follow the webstandards.
Making a new HTML wont make people follow it.
Webmasters who don't follow webstandards need to be stabbed.
What you need is Xframes and XHTML2
HTML neither provides logical structure to information nor provides a nice way to create rich applications. It was originally made to put near plain-text with hyperlinks online and that is pretty much all it's good for. It was a minor improvement over Gopher. Switching to XHTML + CSS does help a lot but it still is a pretty crappy solution. I'd rather they create a new format for the web, without all the pointless hold overs, that makes it easy to keep information, layout, and function as discrete components that can easily be modified or alternated individually. HTML was good because it was simple and just worked which is what you need to get a technology going but eventually you have to make something that works well if you want a concept to keep growing.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I've noticed that MSIE tends to render (valid) XHTML by just displaying the raw XML. I'd imagine that that's quite a barrier to adoption. Removing the DOCTYPE and avoiding CDATA sections seems to help, presumably because Explorer just assumes it's HTML in that case. But then it doesn't validate, of course. Also, what extension should be used for local files (e.g. documentation) if Windows users must be able to double-click the files to read them?
-NT-
The tag.
It's actually better to use HTML, even after all these years of xHTML in the wild.
All the hand wringing... really!
As long as there are window dresser's and make-up artists we'll continue to see XHTML-type evolutions. Missing are the journalists, librarians, ethnographers, anthropologists, etc... who could actually massage *content* into higher order contexts rather than reaching for new formats, colors, bells and whistles.
Does a good enough job for me, is accepted by all the major browsers, is an accepted standard, keeps content and style separate, and doesn't require as big a change from HTML transitional (tag soup) as there is going to XHTML. Not to mention that IE still doesn't handle XHTML properly, and as far as I'm, concerned, there just aren't enough reasons to change to XHTML.
You're probably not as smart as you think.
:)
:)
Every day I see websites, blogs, wikis, forums, and other such software all claiming "XHTML compliance". And sure, for the most part, many of them are well formed and run throught the w3 parser just fine.
HOWEVER, the vast majority of them are _not_ compliant!
Why is this? While the _markup_ is fine, the content is not being sent with the correct _mime type_, invalidating the document before parsing can even begin.
You see, the vast majority of XHTML documents are sent with the text/html header. Think of the mime type as being like an envelope that the document is sent inside.* The browser, when it gets the envelope, decides what parser it is going to use to process the contents inside. And it sees text/html, and sends it straight off to the tag soup parser, the _HTML_ parser, NOT the XHTML one.
The relevant standards show that unless you are serving "HTML compatible" XHTML (this is XHTML 1.0 transitional), you are in violation of the standards by serving XHTML as text/html. And since everyone's favourite web browser, IE6 (and 7), do not support proper XHTML mime types, you're stuck with at most XHTML 1.0 transitional.
And then, given the problems outlined with serving XHTML as HTML anyway, you may as well just use HTML 4 strict or transitional (if you want iframes).
So what does this have to do with this issue? Well, sure the vast majority of websites on the 'net do not use XHTML. But maybe that's partly because the user agent space simply isn't ready for it. Fix the user agents, then the supposed XHTML software out there can become compliant, and from there you may see more people make the transition.
Note: I'm not in any way defending _all_ of the websites out there that don't use XHTML. Just some of them
* With apologies to Martyn Smith, whom I borrowed the analogy from
Real men don't write sigs
Jesus, how hard is it to change from HTML to XHTML? Learn CSS (no hard task), get rid of stuff like frames and tables, and HTML Tidy.
Todd?
I love all the new features and functionality that have been coming to us incrementally over the years - css, xml, xhtml, etc - to make life easier and more organized for a web developer. But the most frustrating part is that there will always be a huge base of software/systems only using the 'old' way of doing things. The only way I've been able to cope without losing my sanity is through 'progressive enhancement' techniques. The basic idea is that a web site starts out with the base level and builds up on that in a completely user transparent way. One example is with javascript on/off. Start by displaying a JS neutral site and then have a non-JS browser invisible tag that 'turns on' JS features and 'turns off' the non-JS components of a page. Perhaps these techniques can be used for future enhancements coming down from W3C
Vicito | The Group Messenger
1) Make a new proposed Standard.
2) Hope everyone accepts it.
(everyone rejects it)
3) Modify current standard to force people to accept it.
What's the point of a proposed standard if they won't accept rejection?
Have you read my journal today?
The <object> tag.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head></head>
<body>
<object height="400" width="400" data="http://www.amazon.co.uk/" type="text/html"></object>
</body>
</html>
"This page is accessing information that is not under its control. This poses a security risk. Do you want to continue?"
Welcome to the wonderful world of Internet Explorer.
Ph-nglui mglw'nafh Gates M'dna wgah'nagl fhtagn.
No, XHTML 1.0 Strict is valid with a text/html header, however, it's not recommended.
That's what'a missing, a decent editor for XHTML that is:
- WYSIWYG (not everyone 'gets' style tags)
- Low Cost
- Cross Platform
- and easy to use
Many people are still using the likes of Claris Home Page, PageMill, Hotdog, etc. mainly because there are no good entry level web editors in thier price range or skill set anymore.
Same thing with ODF it may be a better standard but common people need to have access to it.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
when you use mime type text/html instead of xml the browsers that properly support XHTML have trouble with embedded CSS, SVG, and MathML because it's not using the XML parser because you "cheated". One specific vendor's broken implementation is preventing all the rest from moving forward. In the IE blog post they mention having "server side" check before sending the page.. .what a load of Bullocks!!
Figures.
And let me guess, it doesn't bitch about <iframe> ?
See the handful of tags where it says "Allowed HTML" when you are posting to Slashdot? I seem to recall there being some suggestion that things like b for bold were discouraged, and that we are supposed to use stylesheets instead. NO WAY. Let me repeat that. NO WAY. Why? Because these handful of core tags are simple and easy to remember. If you start forcing people to use complicated stuff, we are just going to end up with more abominations like WikiText and WBBScript, which just re-invent the simple tags that HTML already has. Yuck. Please don't do that.
OTOH, if they are not talking about taking away my simple little tags, then sorry for the rant.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I appreciate the relative simplicity of HTML- I taught myself enough of it in about a month to be able to put together a descent website. I strive to make my site clean and fast, and I code it directly, without dreamweaver or whatnot, but I'm sure it's a kludge compared to expert sites.
What's nice about HTML is that it IS a kludge-tolerant system. Obviously, some things on the web will benefit from more program-like languages, and there will be websites that do more and cooler things with XHTML and whatnot. But what's good about HTML is that it's comprehensible to guys like me, who don't know programming languages, and who will probably never learn one. HTML opened the internet up, allowing most sectors of society access to its utility. And the more people make use of the internet, the more information gets added to the system, and the more useful it becomes.
This is not to say that every GeoCities page is a masterpiece of citizen journalisim, but keeping HTML's document-like simplicity seems important if we value what non-programmers have to say.
Clearly the Semantic Web is not targeted at people who have difficulty writing xhtml.
It is targeted at groups who have valuable information to exchange in a very flexible manner. For those people, the Semantic Web is taking off. Think mashups. Think databases.
What the world needs is a programming language platform that:
HTML then could simply be a hypertext sub-language of this language, and there would be no problem to extend it in arbitrary new ways.
Lol. I don't think that word means what you think it means...
`Bollocks', not log-hauling-bovines...
The Shoes of the Fisherman's Wife Are Some Jive Ass Slippers
This will mean at least one more "background color" parameter with a different spelling and syntax. Probably will depend upon its location within the HTML page.
The HTML language is a gawdawful language for doing anything. And to top it off, it's been modified, added to, plugged into, and garbaged up relentlessly by people who apparently have no concept of what a language really needs to display web pages.
I'll wait for the whole Internet structure to be torn down and replaced with something logical and therefore easy to use and program.
Fata viam invenient.
I went to Firefox's search bar and typed "define:bullo" and it suggested bullocks. Damn, that thing is smart.
That's not what the word valid means. I understand why it's a bad idea, and I generally use application/xhtml+xml, but that doesn't change the fact that the XHTML spec says that text/html is a valid application type for XHTML documents. Secondly, you obviously can't use text/html when you're not using a purely [X]HTML document. That's why application/xhtml+mathml (I think that's right...) and kin were invented.
Yeah, it has no problem with iframe, although I seem to recall it bitches about those too if they're below a certain height and width, as people were using them to surreptitiously inject attacks.
From what I gather it's because IE treats all object tags as potential ActiveX components, which in turn is probably due to the browser's handling of MIME types.
Ph-nglui mglw'nafh Gates M'dna wgah'nagl fhtagn.
I reminded of Ayn Rand's "Anthem". This is sounds sooo similar to the difficulty of the story's postulate that the society had difficulty upgrading from torches to candles due to the approval process.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
I'm a little late in replying, but, I'm still going to :)
First off, I do not believe (X)HTML is still the way to go for web. Don't get me wrong, I'm not a Flash advocate (*eek*) but it's simply horrible to do anything useful. I'd personally like to see a more 'software-development' approach to these things, but hey, that's me.
Anyway, IMHO, very bad and very good comments have been made for both HTML and XHTML. Yes, HTML 4.01 will get the job done in many cases, and no, XHTML isn't properly supported in the most-used browser: IE. What strikes me as odd as that it's seen as so either/or.
You can implement most XHTML things perfectly in HTML (as in, browsers will display it properly) and it does, very much, improve readability and maintainability. What makes me scream "wtf?!?!!" the most is people who disagree with that. Using lowercase tags, using " to encase attributes (and doing attributes the XHTML way), closing all tags, strict doctype, etc. It's just so much easier in the end, get used to it and you will not want to go back! All popular browsers will accept HTML formed like this perfectly. Since I switched to this (ofcourse including all the CSS and such, though CSS is still lacking in so many ways), development has actually gotten a lot easier, and my pages have the added bonus of being perfectly parseable by any XML parser. So no, it's not 100% HTML, it's not 100% XHTML, but it's nearly XHTML and looks good in HTML, cross-browser and all.
In the end though, it's still not 'how the web should be'.
Obsolete web pollution, dragging an extra standard along helps no one.