Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

HTML to be 'Incrementally Evolved' 359

Posted by CowboyNeal from the new-and-improved dept.
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."
This discussion has been archived. No new comments can be posted.

HTML to be 'Incrementally Evolved' More

HTML to be 'Incrementally Evolved'

Comments Filter:

  • Please upgrade BLINK (Score:5, Funny)

    by LiquidCoooled ( 634315 ) on Saturday October 28, 2006 @10:44AM (#16622510) Homepage Journal
    We cannot have new HTML without upgrading the best part of the web.

    Example of server side blink [blartwendo.com]

    Wonderful!?

    • Re: (Score:3, Funny)

      by Anonymous Coward
      Server side blink's nothing. I want blink integrated into the database engine used for data storage. Imagine MySQL having blinkingtext field type. Wouldn't it rock?

      Or maybe we should have blinking characters added to Unicode?

      I'm sure these would be nice innovations that Microsoft could include in post-Vista Windows versions.

    • Re: (Score:2, Funny)

      by drpimp ( 900837 )
      My IE 4.01 came with Windows and the blink doesn't work. It was much larger installation than 300MB and it still doesn't work. Please explain!!!
    • I once came across a page composed entirely of blink tags. The doctors say its getting better, but I still get headaches sometimes.

    • Re: (Score:3, Funny)

      by Mutatis Mutandis ( 921530 )

      This seems to go back all the way to the days when Netscape "incrementally evolved" HTML too, and frustrated developers commented that its next set of new HTML tags would probably be peek and poke.

  • More focus on standard the most will ignore. (Score:3, Insightful)

    by macurmudgeon ( 900466 ) on Saturday October 28, 2006 @10:51AM (#16622578) Homepage
    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.

    • Re: (Score:2, Insightful)

      by MrDrBob ( 851356 )
      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.

  • A Waste of Time (Score:4, Insightful)

    by ImustDIE ( 689509 ) on Saturday October 28, 2006 @10:52AM (#16622592)
    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.

    • Re:A Waste of Time (Score:4, Insightful)

      by baadger ( 764884 ) on Saturday October 28, 2006 @12:22PM (#16623408)
      Agreed. I don't see how incremental changes is going to do anything but produce more versions of legacy HTML to worry about in X years time when everyone should be using XHTML already.

      There are plenty of other things the W3C could work on. How about they spend some time extending 'forms' (which are essentially just embedded controls) to incorporate more complex widgets like embedded video viewers or audio players? I'm sick of being a Linux user and hitting pages that use some strange flash/activex player system or something thats sized in a pop up explicitly for Windows Media Player's browser plug in.

      They wouldn't actually have to produce anything using native widgets, just a set of standards regarding embedded video player sizes (and perhaps basic layout formats) that implementors could follow, and suggest a standard for styling this via CSS and controlling it via javascript.

      The web is more than just hypertext now, people expect media, but as it stands theres a dozen different ways to embed things like video it into a web page unlike images and the old faithful <img> tag. I say if it can work for images it can work for video and sound, and even flash and we can do away with alot of this activex and netscape embedded junk.

      Back on getting people to move to XHTML, I blame schools, the various courses i've been on that mention HTML still talk of it as a series of tag's in vaguely the right order rather than explaining the concept of XML, nesting or CSS.

    • Re: (Score:2)

      by hritcu ( 871613 )
      Multiple incompatible adopted versions is exactly what doomed RSS as a standard and made it an easy pray for a standard with only one version: Atom 1.0. But and at least for RSS there was not only one entity to blame for all the incompatible versions. Here there is one: the W3C.

      Is W3C so blind not to see what is so obvious? Are they so deaf not to hear the million developer's voices asking for only one thing? Stability. There is no feature in this world that could somehow compensate for dooming HTML to t
      • Is W3C so blind not to see what is so obvious? Are they so deaf not to hear the million developer's voices asking for only one thing? Stability.

        CSS2 has been around for over eight years now. So where's the fully-compliant browser?

        I'd say the W3C has been holding up their end of the "stability" bargain quite admirably. Maybe these "milion developers" shuld actually start thinking about delivering on their end of it?

  • Looking 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.
    • I believe there would be LESS crash if browsers would support *just* XHTML, instead of providing fixes for all the broken code out there.
      Of course 90% of the web would stop working too, for better or for worse.
  • I'm not a web designer. I do know, however, the difference between HTML and XHTML (Wikipedia can be so incredibly useful [wikipedia.org]), but I don't quite understand the advantages of XHTML over HTML. Wikipedia notes this:

    Whereas HTML is an application of SGML, a very flexible markup language, XHTML is an application of XML, a more restrictive subset of SGML. Because they need to be well-formed (syntactically correct), XHTML documents allow for automated processing to be performed using a standard XML library--unlike HTM

    • Re: (Score:3, Informative)

      by Ford Prefect ( 8777 )
      To laymen like me, this sounds rather cryptic. Could any of you web gurus please elaborate, and/or list other advantages of XHTML?

      With it being XML, it's easier to read with other tools - using an XML library makes it trivially easy to write code to turn an XHTML web-page into a highly structured, tree-like associative array which contains everything the original page contains.

      In layman-speak - instead of mashing through the 'view source' equivalent (one big string), it becomes a mightily detailed tree, wit

    • Re: (Score:3, Interesting)

      by MBCook ( 132727 )

      XHTML is VERY strict. That makes it very easy to parse. But that same facet makes it very tough to write by hand. What I mean is that with HTML you've got all your tags, but many people don't write them correctly. How often do you write a closing P tag? Do you close your IMG tags like you should (<IMG SRC=... />)? Most people don't. If you did that in XHTML, you're page would be wrong and if the browser is in strict mode, things die with an error. Improper nesting can also cause this (<P>Some

      • Re: (Score:2)

        by Kijori ( 897770 )
        You don't have to convert the HTML into XHTML, you're right, that is difficult to do correctly. All you have to do is validate the comments as XHTML and if they don't pass, output them as plain text not HTML.

      • Re:Advantages? (Score:5, Insightful)

        by jesuscyborg ( 903402 ) on Saturday October 28, 2006 @12:10PM (#16623326)
        But that same facet makes it very tough to write by hand. What I mean is that with HTML you've got all your tags [...]
        Funny, I always thought the hard part of writing XHTML wasn't actually closing my tags, but figuring out how to separate content and style enough to keep Berners-Lee happy, have it be easy to drop in new and totally different styles down the road, have it actually look good, but still keep my sanity.

        • Re: (Score:3, Insightful)

          by timeOday ( 582209 )
          Separating content from presentation on the client side is just a bad idea. It pushes too much complexity to the client, which users don't care about anyways. Browsers should only have to support a simple presentation format, which a little simple customization of basic things like linewrapping. Let the server side worry about chugging through various data sources and formatting templates to create a good-looking presentation, but don't try to standardize all that on the client side. It just hasn't work

      • This adds serious complexity for some people. While Dreamweaver can easily handle that, can you imagine what it would take to make /. XHTML? You would have to write little bits to parse out every comment and story submission that's in HTML and then output it into valid XHTML. That's a TON of work.

        So reject any story submission that's not valid; same with comments. Slashdot already checks comments for all sorts of crap. Besides, while its "a TON of work," its a TON of boring, well-defined repetitive work.

      • XHTML is VERY strict. That makes it very easy to parse. But that same facet makes it very tough to write by hand.

        I've found that writing valid XHTML is pretty similar to writing valid HTML 4.

        If you're more used to writing something which resembles HTML 4, but is completely invalid - then you'll have problems. ;-)

    • Re: (Score:3, Informative)

      by metalhed77 ( 250273 )
      The advantage of XHTML is that it's easier for machines (and developers) to process and work with after it's written. Additionally it supports emerging useful new standards such as XForms, and other XML processing tools.

      The disadvantage of XHTML is that it's harder to write initially and has stricter rules. Most people write broken HTML 4 transitional pages that, quite honestly, work fine for their audience (web only).

      Parsing HTML is a bitch, working with it is, quite simply difficult. Additionally XHTML su
      • "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.

        • Re: (Score:2)

          by 808140 ( 808140 )
          You're looking at this in the short term. The increased machine-parsability of XHTML means that programs can handle it more efficiently: that means that not only are browsers faster, more efficient and less error prone when parsing well-formed XHTML, but it also means that really good standards compliant web authoring tools are easier to write.

          HTML was designed to be written with a text-editor, but XHTML/CSS was not really designed to be written by hand, it was designed with machines in mind.

          Until a good X
      • For 99% of the websites, all you need to know as 'the difference from HTML' is: http://www.w3schools.com/xhtml/xhtml_html.asp [w3schools.com]

        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.

      • Re: (Score:2)

        by BillX ( 307153 )
        So in other words, having well-formed, XML-like code will make it easier for other people to scrape data from your pages (e.g. XHTMLized product database listings) to their own databases and regurgitate your content elsewhere. ;-)

        There is a minor potential payoff in that correct XHTML will be easier to parse for disabled users (think screen-readers, etc.). *Properly-written* HTML should not present a problem here either, but XHTML forces the markup to be properly-written.
    • One of the advantages is that you could use Xslt to convert an XHTML document in something else (like LaTeX, RTF, ...).

      • One of the advantages is that you could use XSLT to convert an XHTML document in something else (like LaTeX, RTF, ...).

        XSLT is possibly the most horrible language to use for transforming documents. Languages such as CDuce [cduce.org] are years ahead.

        Rich.

    • Re: (Score:2)

      by RevMike ( 632002 )

      To laymen like me, this sounds rather cryptic. Could any of you web gurus please elaborate, and/or list other advantages of XHTML?

      Think about learning English grammar. Most of the time, a sentence has the subject first, then the verb, then the direct object. When you learn grammar in school, you spend one day learning this pattern, then spend the rest of the year studying all the exceptions. Imagine if someone came along and redefined English so that there were no exceptions. They could call it xEngli

  • 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.

    • Re:The problem with XHTML... (Score:4, Insightful)

      by tepples ( 727027 ) <.tepples. .at. .gmail.com.> on Saturday October 28, 2006 @11:06AM (#16622718) Homepage Journal
      [The requirement that the entire document be well-formed] makes it unsuitable for sites that allow users to add content.

      Then make sure that the content added by the user is well-formed before adding it to the site.

      • Then make sure that the content added by the user is well-formed before adding it to the site.

        Please, by all means write a forum BBCode parser that outputs valid XHTML that works under the application/xml+html mime-type.

        It's easier said than done, as you have to track every open and close tag and rewrite them if the user gets them in the wrong order or omits one.

        • Re: (Score:3, Insightful)

          by vidarh ( 309115 )
          It's a lot easier than you think to support the kind of feature sets most forums supports. I've written parsers to do more or less that (but accepting actual HTML tags) in both C++ and PHP, and it's quite straightforward. A very basic tag parser plus a stack of open tags and a lookup table to determine when to automatically close tags (to prevent tags that shouldn't enclose content, like "img" from enclosing anything following it at the same level, is really all you need. A few hundred lines at most in a re

        • Please, by all means write a forum BBCode parser that outputs valid XHTML that works under the application/xml+html mime-type.

          The wiki I wrote [merjis.com] does something analogous to that. (Not BBcode, but MediaWiki-ish markup which is similar). It's not really so hard for a competent programmer.

          Rich.

        • Most things that are easier said than done, but the problem you describe is old and very well understood. Such a parser could easily be an assignment in a beginner programming class.
  • 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 ba
  • 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 programme

  • HTML vs XHTML (Score:3, Insightful)

    by cgenman ( 325138 ) on Saturday October 28, 2006 @11:23AM (#16622884) Homepage
    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 benefits of switching to XHTML are mostly theoretical.

      I found the benefit of being able to easily embed MathML into my XHTML documents to be quite practical. MathML is a pain to write, but fortunately there are good LaTeX to MathML translators around.

    • Re: (Score:2)

      by Shados ( 741919 )
      Yeah, that is my issue with the W3C. They honestly live in a world of unicorn and little pink imps.
      Too busy seeing XHTML/CSS has the -core- of everything and anything, they forget that we're not 10 years ago, and that developers actualy could care less about the theorical integrity of their apps, they just want it to work, and be maintainable. And sorry, needing 15 divs wrapped around a single element to get it positioned the way I want it to does NOT make it easier to maintain. Having a formatting spec t

  • becasue we dont care (Score:4, Insightful)

    by grapeape ( 137008 ) <mpope7@kBOHRc.rr.com minus physicist> on Saturday October 28, 2006 @11:24AM (#16622896) Homepage
    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.
  • 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.
  • 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

  • One of the best texts I've read on this subject can be found here... http://www.hixie.ch/advocacy/xhtml [hixie.ch]

  • Very Simple (Score:5, Insightful)

    by Fnkmaster ( 89084 ) on Saturday October 28, 2006 @12:00PM (#16623220)
    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
  • I've always thought of HTML as Extrementally Involved.

  • HTML is dead, but no one noticed (Score:5, Insightful)

    by Dracos ( 107777 ) on Saturday October 28, 2006 @12:42PM (#16623554)

    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:

    • Browsers and WYSIWYGs allow incredibly sloppy markup
    • Therefore, developers don't see any need to move up

    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.
  • 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 b

Slashdot Top Deals

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Close