Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
News

W3C Announces XHTML As Its Recommendation 100

Posted by michael from the you've-seen-the-draft,-now-see-the-real-thing dept.
miester writes "Since I haven't seen anything about this on Slashdot I thought I might submit it. W3C has officially recommended that XHTML Basic be the next step for the World Wide Web. Just when I learned how to do tables ...."
This discussion has been archived. No new comments can be posted.

W3C Announces XHTML as its Recommendation More

W3C Announces XHTML as its Recommendation

Comments Filter:
  • Of course, we do all realize that eventhough IE4 and NN4 are 90+ percent compatible, companies and designers still choose to DETECT THE BROWSER AND CREATE DIFFERENT VERSIONS.

    TD Waterhouse [tdwaterhouse.com.au], admittedly an online stockbroker, won't let you use any browser other than IE or NN because:

    For your security to access the TD Waterhouse website you require either Internet Explorer or Netscape 4.0 (or above).

    Once you pass their browser detection test you're forced to use javascript in order to navigate around the site. They're obviously very concerned about security. Heh!

  • Well, the W3 recommended the CSS1 spec, and IE, Netscape6, Mozilla, and Opera follow it religiously. Hell, most of them support some of CSS2. Most of the "standards" people talk about being unsupported are, in fact, unfinished. While the base XML standard was solid for a while, other standards that were needed to make it web viable, such as XSLT were not (although I think it just became "stable" recently). No browser vendor in their right mind is going to implement something that is subject to change.

    Also, some of the standards are a bit "ambitious", and are therefore hard to implement without breaking backwards compatibility. Some are just a pain to code into a browser (like CSS2's drop shadow effect that should be able to affect any text it is applied to). Sure, someone like MS that has a "Microsoft Universe" to work with will implement silly browser specific stuff, but they will still support standards. Arguably, standards, in part, made IE come out on top in the browser wars. Sure, aspects of their monopoly put pressure on Netscape to make stupid mistakes, and also probably cut down on their overall workforce, slowing them down. The main aspect is that people will always want the web to work better, and standards do just that. The browser makers will cater to that desire or they will perish. Old Netscape died because it didn't move with the times fast enough.

  • but <br /> works fine in both IE and Netscape....just make sure to use the space between the br and the /. IE will work without the slash, but NS chokes.
  • Aren't singular tags closed inside that tag in XHTML? Like this:

    <br />

  • XHTML Basic = a good things for content creators (Score:3)

    by Quietti ( 257725 ) on Saturday December 23, 2000 @05:23AM (#542270) Journal

    Honnestly, look at W3C's own homepage [w3.org] and see for yourself what clean HTML means. Already since the first XHTML draft was released almost a year ago, they have simplified their presentation, but the important stuff is still there: the documentation about WEB Publishing standards.

    Sure, there are colors and neat formatting tricks, but most of that is done using CSS. Oh, there are a few icons and logos, too. Is the absence of frames and nested tables an obstacle to the content's diffusion? Well, admit it, it is not. All we need to find from W3C is there: the standards.

    Also, while the obvious intention of XHTML Basic is to reconcile WML and HTML into a unified common base, note that Web Content created using this barebone standard with linked CSS sheets (as opposed to embeded style rules within the text) also has another strong advantage: it obsoletes the very concept of forcing people to "upgrade" to whatever latest version of a specific browser, which increases accessibility of the content and makes it possible to use "deprecated" browsers without loosing anything significant.

    My own appreciation of XHTML Basic, from an HTML comparision point of view, is that it is about half-way between HTML 2.0 and 3.2: basic text and images, plus forms and tables, with XML rigor as a bonus. If your Web Authoring really is about content, not Flash animations demo, then XHTML Basic is all you really need.


    --
  • Look deeper -- Openwave (nee Phone.com), Ericsson, Sun, Microsoft and other key members of the WAP Forum have representatives on the XHTML Basic working group. Also of note is that a representative Access Co Ltd of Japan -- the developer of the microbrowser inside the popular i-mode phone, and another member of the WAP forum -- is listed as one of the editors of the spec. From this list of contributors, it should be clear that xHTML basic is going places.

  • XHTML is a good thing because it's strict. It's much easier to create an XHTML-compliant browser than an HTML [insert any version, variant, and de facto standard here]-compliant one. Browsers have gone too far in forgiving mistakes and accepting bad code. Well, I don't expect bad HTML to disappear overnight, but XHTML is a step in the right direction.

    And when it comes to "new" markets - like the Internet on small devices - XHTML has the chance to succeed quickly. You don't have many gigabytes to play with on a PDA or a mobile phone, so a browser that parses XHTML Basic will of course use much less resources than a bloated browser that caters for all obscure HTML codings out there. This is the chance to do it right from the beginning!

  • Indeed. The proper term is:

    Web Programmers

    *smirk*
  • Do you even run a web site? 3 - 4% of users on my site are still using 4.x on various platforms. Do you want to tell them all to go away?
  • Having done quite a bit of CSS-P, it's actually easier to do once you bend your mind to it. Table driven sites are an endless mess of tags inside your HTML code making it quite unreadable. Instead, just wrap the whole thing in a DIV tag, and use the positioning code to place it appropriately.

    This means that you can hand the page to some junior HTMLer and know that the page will still have a chance of validating and looking right when you get it back. You can also simply hand it to a secretary with a comment of "Don't touch the angle brackets", and they can easily update the text on a page and have it work.

    The trickey bit is writing your page in a way that makes sense when it's flat. Because of the positioning code, The DIVs can appear in any order. When I'm working on a site like this, I try to look at the page in lynx. When I'm happy with it there, I'll move the elements around the page and check it with Mozilla. Lynx never even sees the positioning code.

    I suspect by the time IE6 and Mozilla 1.0 come out, that the worst of the positioning bugs will have gone away so that it's actually cross platform usable.
  • Tim misunderstood SGML's goals and mangled them in the creation of HTML, but mightn't it have been a more pragmatic thing? He wanted something usable, and he created it, and it worked.

    It definetely works. My point is that it wasn't a systematic process of fixing SGML what made HTML work. Rather it was his misunderstanding of SGML goals what happen to made HTML good.

    One can't and shouldn't judge people like Tim and their achievements from a purely software-theoretic point of view. Rather, he made something usable for the rest of us, and raised the bar for those coming after him.

    Don't get me wrong. There are many things right with HTML... but for better or for worse (and it can certainly be argued) it simply does not reflect a proper understanding of what SGML was....

  • True, the issue at hand is the fact that current browser producers have such shocking CSS support that trying to use these elements is futile. If it worked fine, I'm sure people would stop using tables.

    And, unfortunately, it's not a problem that can be solved with "Well, we'll put up a syntactically and conceptually correct website that's going to be rendered problematically, or not at all, on most of our client's browsers, in the hope this will encourage the producers to actually get it right"...

  • Lynx does have its uses, in circumstances. Some lee7 users take it far too far. Case in point, a usenet comment:

    "But Lynx CAN display images. I run it in an X-window, and have it configured to fire up xv for each image on the page."

    To be polite, why the fuck would you do this?

  • You keep saying that Tim misunderstood SGML, but do you actually have any evidence of that? I'm suggesting that he may have understood SGML and its goals perfectly well, but in the process of singlehandedly creating something useful, he made some pragmatic compromises. Often, the ability to make such compromises work can indicate a deeper understanding of the issues than you might think.

    Of course, it's also possible that Tim did misunderstand SGML, or just didn't care about its intent and saw it as simply a useful tool. But I don't know that that's true.

  • You keep saying that Tim misunderstood SGML, but do you actually have any evidence of that?

    Yes I do. I was there...

    Go back and read the archives. (Say for example the emails between Dan Connolly and Tim).

    For XML a good source is:

    http://www.ibiblio.org/xml/quotes1999.html

  • If you were there, why didn't you just set him straight? ;)

    Thanks for the reference, but I browsed some messages from the early '90s and didn't see anything particularly incriminating. Unless you can provide something more concrete, I shall continue to believe that Tim was a lot smarter than all the SGML nuts, and knew what was really important...

  • Eh, my main problem is how they deal with CSS, especially NS4.7 and its refusal to let CSS persist through table cells.

    As for who is using NS4.7... well, my school, for one. Every flaming Mac and PC on the network has NS4.7 and, unless a student has installed somethign else, only NS4.7 I think I've talked them into including NS6 in the next network iamge, but we'll see.

    -J
  • Maybe i am confused but does this not run direct interference with the "glory" of .net -or at least i hope so lol:)
  • I am psyched about XHTML, but especially the ability to MOD it for specific applications. That's what makes XHTML Basic so *VERY* cool. I also know that whatever "Basic" spec we come up with, there will always be at least one feature somebody can't do without.

    The feature I can't do without is forms.

    All I want to do is take 1980's technology and make it interact with the web. If I could put my entire address book on a calculator watch, why can't I use a similar watch to exchange addresses, phone #'s via the web? Back then, I was doing a lot with a little four line LCD screen.

    I think the spec is missing a very important piece of functionality -- a little interactivity.

  • Phear the mighty Slashdot Effect (Score:2)

    by Anonymous Coward
    Since I haven't seen anything about this on Slashdot [slashdot.org] I thought..

    Hey, you! Have mercy with the poor operators of that little site! Now thousands of people will follow the link, and the small Slashdot server will go down on its knees. It's Christmas, damnit!

  • It's the UberWhore! (Score:1)

    by Anonymous Coward
    Do they give you a bonus for providing a link to slashdot [slashdot.org] in your submission?
  • Ironically enough, the W3C uses a table to layout the W3C A to Z bar to the left, the news content in the middle, and the other links of the right side. And I quote..

    <table summary="Layout table: The first cell contains a navigation bar of W3C technologies, the second contains news, and the third another navigation bar of W3C pages." border="0" width="99%" cellspacing="0"
    cellpadding="10">

    Yes, it isn't as hideous as some of the nested tables I've seen, but funny still that the W3C uses tables for layout.

  • Noooo! Not XTHTML Basic! (Score:3)

    by small_dick ( 127697 ) on Saturday December 23, 2000 @06:59AM (#542288)
    The XHTML Pascal working group will be crushed.

  • For table cells, can it inherit font specs? Or do I stil have to specify the font you want to use for each table cell?
  • I know there aren't even tables in the spec, but it'd be a great way to "page" your friends.

    But there are tables in the spec. The ordinary, much abused set of table elements aren't all available. Just a few common-sense table-elements for small-screen devices. IMHO, they're making tables what it was supposed to be: for tabular data

  • It adds a bit of complication by requiring you to know all those standards, but when you grok it (and believe me, it's not so hard - one can do it in a matter of days), it vbecomes clear and logical hierachy of content representation standards

    But most people can pick up html in a number of minutes - It's certainly a lot easier to pick up than XML. A huge % of sites on the web are made by amatuers (look at geocities), and XML is just going to confuse the hell out of people.

  • Excellent point. I never really thought about XHTML that way, but I think you are wrong.

    Really, the main point of XHTML is that is should be produced by editors and XSLT stylesheets (reformatting other XML into XHTML).

    However, producing a conformant XHTML document by hand is really not that much harder than regular. Plus, whatever XML viewer you are using is going to give you very SPECIFIC error feedback.

    This kind of feedback was not possible before because bad HTML is very ambiguous. Bad XHTML is very easy to pick out by the parser.

    So, in the end, I think that coding by XHTML will make your job easier.
  • You know, stone axes were once "most successful, most widely deployed techology". That not saves them from being totally unaproppriate for the modern world, from any point of view except being displayed at historical museum. HTML was fine for academical knowledge-exchange networks. It's not appropriate for data-representation or webpage-building of today. And quality of current HTML (go find how many of them validates as HTML 4.0?) and nasty tricks you have to do to get something useful of it (browser detection, etc) is the best evidence of this.

    And yes, quantum physics of today won't exist without alchemy too. But it's not the reason for quest of the philosopher's stone in 21th century. This quest was a total failure, though brought very significant advances on the way. The case of HTML is alike - it didn't reach it's purpose, but brought a lot of useful things on the way. But the time has come to bury it.

  • FYI, the font tag is dead and has been for a long time. If you use stylesheets, you can put the class attribute in practically any tag (such as table, tr, td), and it should* apply to anything nested inside.

    * Obviously some current browsers don't do this right. But what do they do right?


    Yes, I am a Raxis.

  • I'm not sure if a move toward XML is necessarily a good thing. I hope I don't sound like a modern Luddite, so please hear me out.

    HTML and most browsers allow a large "fudge factor" -- your tag names can be uppercase or lowercase, you can quote your tag clause values if you want or not (like <P ALIGN="RIGHT"> or <P ALIGN=RIGHT>), you can use the header tags (<H1>...<H6>) in any order, etc.

    In HTML, you can develop your own coding style.

    I prefer uppercase tag names and tag-clause names, quoted tag-clause values for strings, nonquoted tag-clause values for numbers, free arrangement of headers.

    Along comes the W3C, the "trusted" authority on browser standards and forces XHTML on us which has incredibly rigid syntax. Now it's all lowercase tags, all quoted tag clause values. We're supposed to adopt the single-tag XML syntax for <BR> and <HR>, etc. (like "<BR />" and "<HR />"), but we shouldn't use it for <P> or various other tags which normally had an end tag in HTML because it might screw up some browsers...? Can they even get the XML-ization of HTML right?

    There is even an "ISO HTML" standard which demands the header elements always be in "proper" order. I find it's much easier to whip out <H1> or <H2> when I need big text than going <FONT SIZE=+2> or defining a new style sheet class. Besides, the W3C doesn't want me using <FONT>, anyway...

    There's an ANSI C standard, but it doesn't dictate that you always use the "one true brace" style, does it? I was taught code differently. But at the same time, I respect those who use the "one true brace" style.

    Also, while we're talking about small, less-capable devices like PDAs, etc., how about people with lower bandwidth. I always try to make my HTML as compact as possible within reason. The damn picky Validator told me I had to add a TYPE="text/javascript" clause in my <SCRIPT LANGUAGE="JavaScript1.2"> tags because the LANGUAGE clause was deprecated. That's stupid. First, due to differences in implementation of JavaScript between the various versions, it's necessary to say LANGUAGE="JavaScript1.2" to tell the browser "execute this code using JavaScript 1.2 rules". I don't think there's such a MIME type as "text/javascript1.2" or "text/javascript1.1". Secondly (and this was the point I wanted to make), they're just asking for more bytes to be added to size of the page. I have many <SCRIPT> tags on this one page I'm working on. I want it to load quickly for dial-up users, and I'm supposed to make it larger? The TYPE clause above and separating space is only 23 bytes, but with many tags, that adds up.

    Someone else was talking about <B> and <I>, etc. being dropped and being replaced with style sheets. (I haven't read that much of the specification so I don't know for sure.) Apart from the fact that style sheets are harder to learn, this (once again) slows down loading times because of the extra request from the client to fetch the style sheet.

    And, with XHTML, every tag clause value needs to be quoted -- even numeric ones? That's unreasonable!

    I realize we can't have anarchy and a standard is needed, but I don't think the W3C is totally in touch with what the Web has become and the business around it. If I didn't know better, I'd say they were trying to bring us back to 1993 with all pages being really basic and simple and all <H1> and <H3> elements having <H2> (not <h2>!!) elements between them.

    What if a company has a standard coding style of uppercase elements, nonquoted tag-clause values? Are they forced to change?

    Sure we use tables, <FONT> tags, and transparent GIF spacers like nuts. I'm sure it upsets Lynx users. But perhaps we're not catering to Lynx users. Most visitors to my pages are using IE 5.5, 5.0, or Netscape 4.51 or higher. Less than 0.1% are using Lynx. In business, you want an attractive page, and if that means making it difficult for one or two people so you can get more business from several thousand, so be it.

    My apologies to those who prefer to code with lowercase tags, etc. We're all entitled to our own styles...until we get to XHTML.
  • Sadly CAPITALIZED are not allowed and only lowercase tags are proper for the spec :( CRY lowercase tags are a lot harder to read and parse when you are looking at raw html. and it is easy to add capital tags to the dtd they are just lazy. :( W3C-- msew
  • Then use or . (Some browsers like the latter better.)
  • Most browser security problems are javascript or Java related. ActiveX is itself a security problem (it ain't related, it's the mother of security problems ;) ) .

    The other browser security problems are far less common.

    When these problems are reported the usual workaround is to turn scripting off, until you get the patch.

    After a while if you have any clue you just keep it off.

    And to answer in what possible way, go do a search on www.securityfocus.com for javascript, then you'll see tons of ways.

    Cheerio,
    Link.
  • Failure? Looks like HTML is pretty successful. Even PHB's can do HTML ;).

    XHTML basic may be for the lowest common denominator device. But evidence shows that HTML is almost easy enough for the lowest common denominator person ;).

    Because, fortunately as the previous poster said, Tim "screwed up" SGML, and so we have something far more popular.

    Actually Tim didn't screw up at all. HTML is very good at what it does. Getting _people_ to make hypertext information available to other _people_. Not machines. People. As a result we have millions upon millions of webpages.

    Now you have all those committee-heads trying to make everything logical, organized, nice and tidy.

    For example: XML and e-business. I think it's ironic. You have all these people who were pushing EDI (which sucked and mostly failed), and now they are trying to put EDI into XML. Crap in a nice can is still crap.

    Most of these idiots seem to think to get two different companies to talk, you should define thousands of _encompassing_ "standards".

    Like that would help. As if the thousands of different business rules isn't bad enough. People should see what people do when communicating in a foreign country.

    Buyer:
    [points at object]
    [shows 3 fingers]

    Seller:
    [shows 5 fingers]

    Buyer:
    [shows cash]

    Seller:
    [smiles]
    [hands goods over]

    You need very simple basic practical standards. Standards defined by committees tend to be complex and all encompassing, because you have to satisfy 10-20 huge organizations (who the committee members represent).

    Watching all these consultants and committees propose EDI over XML is almost like watching people trying to run ISDN over ADSL ;). Funny, sad, and nauseating at the same time.

    Of course having complex standards is good for the consultants, since the PHB can't say "Hey my 8 year old kid knows how to do that, you can't charge me that much".

    Cheerio,
    Link.

  • XHTML Basic != XHTML (Score:5)

    by leighklotz ( 192300 ) on Friday December 22, 2000 @11:33PM (#542300) Homepage

    Note that XHTML Basic is a stripped-down version of XHTML for phones, etc. It's meant to be the future of WML, not the future of Netscape (uh, IE, Opera, whatever).

    As for tables, XHTML Basic includes tables, but simplified ones as necessary for reduced screen real-estate devices, not tables as are used to layout complex graphic designs in HTML.

    Give XHTML a try -- as far as web authors go, it's pretty much just using lowercase tags and closing them all. Or try HTML Tidy [w3.org] with the "-clean -asxml" options to convert your HTML pretty effortlessly to XHTML. Current browsers will work fine with it.

    Disclaimer: I am a member of the XML Forms [w3.org] committee, a descendent of XHTML, but I had nothing to do with XHTML Basic.

  • This should make things better:)
  • Well - 3 or 4% is not much, that's about as much as spiders and bots on my site. Either they use Mozilla/Netscape 6.0 or they switch to IE or Opera, I don't care, but I'd rather spend 1 hour improving the site for the 97% of visitors that use a modern browser than for the 3-4% loosers that are still using the old Netscape 4.x. Heck, some people still go around with horses, yet nobody gives a sh* about designing roads for horses.
  • Yes here's what was important, what made the difference:

    HTML made it easy for _people_ to create and distribute hypertext information. Mozilla helped immensely to popularize it - it made the viewing easier on the eyes with the nonstandard img tags and such. But overall it was simple enough for people to create more and more pages by themselves.

    And the result is billions of webpages. Many of them made by people, some even fresh from AOL ;).

    In contrast SGML doesn't seem to be simple for people - as someone has claimed that Tim Berners-Lee misunderstood it. And I'm sure Tim has above average intelligence.

    I guess if you shove SGML down everyone's throats, we'll have maybe a few thousand public pages in comparison. Sure they'll be nice and logical, very tidy and very organized, easy parseable by machines.

    And you won't have silly people abusing blink tags and stuff or the big red button that does nothing. ;)

    Maybe Tim did misunderstand SGML. But I think someone somewhere has misunderstood what languages are for ;). When a language is being discussed more than used, it's an utter failure.

    Cheerio,
    Link.

    But God chose the foolish things of the world to shame the wise [gospelcom.net]

  • Your points about the obligation to quote all values, self-closing BR tags, disapearing B and I tags ... have all been carefully considered by W3C when they decided to formalize these things.

    Advantages of formalism in markup languages:

    1. No need to guess where a value ends, just parse and look for the quotation marks within a tag.

    2. No need to check for UPPER and lower case versions of the same tags and attributes; everything is in lowercase.

    3. Removal of presentation control allows the same source document to be used for a variety of output devices.

      If you are authoring for any medium or major -sized content provider, chances are that making the content outputable in several of the following formats is a must:

      • HTML
      • WML
      • Postscript (includes PDF)
      • MAN page
      • Newsgroup post

      By using XML as the source format (or, in this case, XHTML Basic), all of these can be covered easily using the appropriate Style Sheet or in a few cases, with sophisticated XSLT schemas.

      • HTML: no transformation needed, already in XHTML; CSS can optionally be used to add visual nicies and presentation control.

      • WML: no transformation needed, unless transport buttons are required. In any case, no presentation control available, so XHTML can pretty much be used as is.

      • Postscript: probably needs an XSLT schema to ensure a predictable, printable layout. Otherwise, the source XHTML document already provides the structure, which can easily be parsed to provide an automated Table of Content page, as a bonus.

      • MAN page: the structure is already provided by XHTML, but must be filtered by troff or similar tools to convert the tagging into appropriate markup for MAN pages; a simple substitution game, easily handled by a script.

      • Newsgroup post: the document structure is already provided by XHTML, but tagging must be stripped and converted to carriage returns, tabs or spaces, to render a plain text message.

    For the record, I also hated the disappearance of favorite tags and the requirement of using lowercase for everything, because I still prefer to hand-type my HTML (with the help of auto-expanders that provide tags out of a few keystrokes).

    Ever since I adopted HTML Tidy [w3.org], the conversion to XHTML has been rather painless. Sure, reading lowercase-only tagging took a few weeks to get used to, but nowadays I hardly notice the difference; the tags have become easy to spot, once again.

    In closing, I would like to thank W3C people for their efforts, in both web standardization and providing freeware tools to implement these standards. Tidy is something I can no longer live without! ;-)

    However, (and this also goes for a lot of other standards out there, such as NTP [ntp.org]), you people really need to learn how to distill all those technicalities into more accessible documents: XHTML Basic was the very first human-readable recommendation you produced! Heck, for once, I could find a list of supported tags in one single section [w3.org], instead of having to decipher an impossibly long DTD!


    --
  • ..and therefore aims at the non-open WAP-standard. so this is (c) a good thing.

  • XHTML and LCDs (Score:3)

    by Robert S Gormley ( 24559 ) <robert@seabreeze.asn.au> on Friday December 22, 2000 @11:35PM (#542306) Homepage
    ...as in Lowest Common Denominator. To me XHTML is not a step forward in many senses, but a step back. Things like nested tables, and quite a few others (I'm not sure right now, I forgot!) are now "unavailable", as some Internet Devices may not be able to use them.

    It's definitely a step towards device independant web browsing, but I think a better approach would be two streams. Some might think this an evil idea, but if this is the way W3C is going, with all its member companies dreaming of their own little 'devices', perhaps a stream for "feature rich" browsers and another for "feature poor" is appropriate...

  • Is XML -> XSLT -> XHTML more complex and CPU/memory intensive than just using HTML? Yes.

    No, if the XSLT transformation is done client-side it's less CPU intensive for the server.

  • For The Confused (Shoulda Been In The Summary) (Score:4)

    by CritterNYC ( 190163 ) on Friday December 22, 2000 @11:38PM (#542308) Homepage
    XHTML 1.0 [w3.org] is the current W3C recommendation for regular web content (ie the stuff we use HTML for now). XHTML Basic [w3.org] is basically a subset of the XHTML 1.0 functionality and is "designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes".

    Basically, XHTML Basic has about the same feature set as HTML 3.2: images, forms, simple tables, etc.

  • is it just me or does the paper say that XHTML basic is a recommended standard for internet devices, not for the web as a whole?

  • Wow, that was one of the lamest first posts I have ever seen. You should try harder. It's 3am eastern, it's not like you have a lot of competition.
  • But I think someone somewhere has misunderstood what languages are for ;). When a language is being discussed more than used, it's an utter failure.

    Amen! This goes back to what I started out saying. Languages based on academic foundations often tend to have rigorous goals that have much more to do with the requirements of formal systems, or other theoretical requirements, than with making them usable by real humans. There are really two different goals: theoretical soundness vs. usability - and the two often don't intersect, or even have anything to do with each other, although people confuse the two all the time. (Ask a Scheme or Smalltalk programmer to explain why the syntax of their lanugage sucks and you'll get an example of this ;)

    But I also think that some people underestimate the compromises it takes to "ship" version 1.0 of any given software system. It's easy in hindsight to look back and say, "hey, why didn't Tim just stick to the clean separation of content, structure and presentation which SGML allows", but regardless of any misunderstandings Tim may or may not have had, the real answer to that will invariably be "because we didn't have the time or resources to do it perfectly first time round."

  • Now we'll need IE 6.0 for "internet devices". Please login to your microwave before use.

    Internet devices or not how hard do you think it will be to usurp already heavily embeded technology.

  • HTML moving forward (Score:3)

    by Alomex ( 148003 ) on Friday December 22, 2000 @11:40PM (#542313) Homepage
    I'm always amazed at how wrong Tim Berners-Lee got SGML and how for exactly that reason HTML was successful where SGML had failed miserably.

    XML is an effort from the SGMLers to retake the lead and bring HTML back to the purity of markup languages.

    Originally XML was a simplified SGML aiming to replace HTML. So much for that one. Many of the original SGML problems were still there (in a nutshell too powerfull and general for the average web page).

    However SGMLers learned in the process, split the original XML proposal into many subcomponents, including XHTML. They also learned that rendering/formating is important and should be part of a tagging standard (thus XSLT)...

    We'll see if the world finally follows them in this third attempt to take over text management...

  • Re:Standard for low end devices is good (Score:1)

    by Anonymous Coward

    Professional web designers

    Contradiction in terms.

  • I thought they were recommending this for a while now. Like anything over there. No one really listens.

    But heck, HTML + Javascript + StyleSheets and now we are adding more closing tags and more tags. Oh, and don't forget the cross browser crap, browser and OS version compatibility, and oh, must add FLASH. Wait, we could even parse this stuff with CGI, ASP, or PHP. And don't forget your MySQL database and MIDI soundtracks. I guess we will leave Java out this time.

    So someone tell me. Is this just all fvcked up or what.

  • true

    However, we live in a computing world where it is the job of the inquisitive to see what things will do outside of their design parameters.

    Almost a definition of "hack"

    When the functionality of the product gets tightened and the undocumented features fail well that's just too bad.

    It's good though that the subverted uses get proper built in functions. That the font tag is being depreciated is a good thing. Just look at the spew that Dreamweaver etc. *have* to output to ensure consistency. CSS is a beautiful evolution.

    I fully support XHTML and it's derivatives and I'm looking forward to swtiching my development away from SGML to XML based solutions.


    .oO0Oo.
  • Of course, we do all realize that eventhough IE4 and NN4 are 90+ percent compatible, companies and designers still choose to DETECT THE BROWSER AND CREATE DIFFERENT VERSIONS.

    So just because HTML becomes "compatible" with different devices, everyone is still going to create tailored versions for each device anyway.

  • No. XHTML is not aimed at PDA's. XHTML is an XML-ified version of HTML 4. It does a lot of cleanup and makes the whole thing much saner. It also divides up HTML into various profiles, of which one is very "correct" in the sense that it doesn't have FONT, CENTER etc. tags. Instead, all styling is done with CSS, which is *very* good.

    What XHTML has to do with WAP is that the WAP Forum has announced that WAP 2.0 will essentially be XHTML. So it's WAP that is adapting itself (thank God!!) to XHTML. It's not XHTML which is for PDA's.

    WAP is one of the worst cases of re-inventing the wheel ever, so this is a good thing - that I agree on!
  • That is because the server-side browser detection does know more than the user, in the majority of all cases. Aunt Magda wont wanna choose "IE6 or NN7.5 version" of the page when she goes online to buy christmas presents for the kids... she just wants things to work.

    Of course, you might actually know more than the server-side browser detection... But then either the designer is really incompetent and doesnt know what will work on his targetted browsers... or you know more, but it doesn't matter, because the server side detection knows enough to make it work. Either way, adding the choice for the user is just a waste of time, and will probably scare away people who don't know.

    Aunt Magda would probably either give up and turn the power off, or just pick one. And then she'd get a messed up screen when she picked the wrong one. Where's the benefit in that?

  • Re:XHTML Basic != XHTML (Score:1)

    by Anonymous Coward
    "Give XHTML a try -- as far as web authors go, it's pretty much just using lowercase tags and closing them all. Or try HTML Tidy with the "-clean -asxml" options to convert your HTML pretty effortlessly to XHTML. Current browsers will work fine with it."

    Hmm, Netscape 4.7 will take <br></br> as two <br>s.

    Not quite what you'd expect.

  • The idea of linking to anywhere from anyplace, isn't really new. Vannevar Bush [ruku.com] introduced the concept of hypertext already in the 1945 article"As We May Think" [theatlantic.com]. This is recommended reading for anyone interested in hypertext as a concept.

    The impression I got from BrowseUp [browseup.com] is that it is supposed to implement some of his ideas. Whether they are successful or not, I cannot answer. Their idea however, is in no way new or radical

  • Weren't computers supposed to make our lives easier? To me it doesn't make sense that we are forcing what used to be a flexible, tolerant Mark-up into the spend-half-an-hour-looking-for-the-missing-forward -slash nightmare that C and (sometimes) Perl present to us 'less precise' developers.

    I personally think it's swell that i don't have to finish tags (<br/> - come on!) or make sure they're all in the right case - let the computers work it out for themselves - they don't mind! really.

    I'll admit browsers sometimes go too far - IE is infamous for ignoring MIME types and searching the content of a document to 'work out' whether it's html, xml, or japanese (and let's not talk about it accepting back slashes - just go to http:\\www.microsoft.com\ie\) but come on - we've already been robbed of the meal-in-a-pill, silver body suits and personal jetpacks - let's not start spending our days working for machines!
  • My first thought was "basic? in html?"..i havent had my morning coffee yet..
  • XHTML Basic has forms. It just doesn't have file and image input types (since "only devices with a local filesystem can take advantage" of them).
  • In general, HTML became total failure.
    I'm somewhat at a loss of how to respond to someone who calls the most successful, most widely deployed computer technology of the last 10 years a "total failure." I guess there were people who considered the Model T Ford a "total failure" because it didn't have a lot of horsepower, or very good brakes, or come in any color other than black. There were certainly better, more technologically sophisticated vehicles at the time, but it's hard to argue that any was more successful. The same is true for HTML. There are more "pure" markup languages like SGML which have been around for years and been successful in niche applications without making a substantial impact on the industry as a whole. HTML is far from perfect but it's simple, cheap, and the closest thing to a lingua franca that this industry has.

    You seem to like XML, but let's face facts here: XML wouldn't exist today if not for HTML. We'd have SGML as a niche technology in high-end applications, and we'd have some proprietary "file format" (remember Blackbird?) for the masses.

    Let's try this: if HTML is a "total failure" then what, Frodo, do you consider to be a success?

  • or <br/> & <br /> as that was supposed to say.

  • If you use this standard, the page will work in pretty much any browser, including IE. Now, if you make pages like this [neu.edu] [1] or this [harvard.edu] [2], then it's your own damned fault if it completely breaks in a different browser.

    1. My University's main page. Blecch.
    2. Somewhere I worked briefly. Actually this page works quite well in the Big Two on Windows, but I can't even imagine what it'd look like in a PDA. In Lynx it looks like this: [LINK] [LINK] [LINK] [LINK] ...

    Yes, I am a Raxis.

  • Being a Frontpage 2000 whore, I am a bit hesitant to use CSS "THemes"(as frontpage puts it). For some reason when I apply a background image to one of my themed pages, the background never takes.
  • To say that you just need to create a new xsl file is kind of simplifying the whole operation. Because there are fewer formatting tags, you may need to redesign the look of your site, along with the navigation. After which comes all of the testing and retesting. Each time you wish to make a change, return to step 1 and repeat.

    I thought XHTML was brought out to simplify and standardize the development of web sites. By splitting the language off in so many directions, the W3C is increasing the difficulty for web designers, software writers, and appliance manufacturers to create a homogeneous standardized internet.

    I have been reading up on the WML specs, and am well aware it needs to be updated. However I also feel that appliance manufacturers should set their sites higher to the same standards as computer browsers (this sentence really didn't come out right, but you all know what I mean :^)). By giving them a halfway point, there will be yet another fragmentation in the browser market.

    The more options we give them, the more excuses they will have.

    --
    Rod
    !

  • The person who designed that site [k10k.net] deserves to be shot...

    After you get by the frame code, find the right frame to view, and scroll past the JavaShit, you find this:

    <table>
    <tr>
    <td>

    Real good design there.


    Yes, I am a Raxis.

  • OK, something messed up a large portion of that last comment. Was trying to show how they have about a hundred table cells inside TRs inside the table. Meh.

    Yes, I am a Raxis.

  • Yeah, I saw that & laughed, too. However, I think it's 'cos they want their homepage viewable with a nice layout even by people who's browsers can't do CSS.
  • A lot of browsers have problems with stuff like that. For instance, I have to leave in a lot of html 3.2 stuff just to get netscape 4.x to view pages correctly. On my html 4 pages, netscape just doesn't get the background unless I throw it in the body tag.

    As far as IE though, I've not had a problem with it. I don't use frontpage (I use topstyle and homesite at work, vim at home) so I dunno what kind of funky stuff it's throwing into the css. You may consider geting topstyle lite (it's beer-free) for your stylesheets and just tell frontpage to link to them. You may want to set your .css files read only when you have frontpage open though - it may try to screw with them.
  • As a fairly typical geek, I taught myself HTML, and until recently had no formal training in the (black) art. So last month, I took notice when I sat in a classroom where HTML newbies were encouraged to make their tags UPPERCASE to stand out better, which seemed like a good idea to me.

    Being committed to open standards, I've been spending a lot of time on the W3C [w3.org] site, and when this announcement came out, I followed my curiousity to find out what XHTML is... only to find out that XHTML tags are case sensitive! This is a Bad Thing<tm> IMNSHO, because it breaks too many established conventions for no good reason. Maybe it's because I've used terminals that didn't support lower-case letters, back in the Bad Old Days.

    The other major difference between HTML 4 and XHTML 1.0 seems to be that every element must explicitly closed, either with a corresponding closing tag, or the self-closing variety: <br /&gt&Note the space before the closing slash, which older UAs will interpret as an unknown attribute, and therefore ignore, but XML UAs will correctly see as the self-closed element syntax. This is a Good Thing, because it becomes possible to parse a document without any knowledge of which elements require closing tags.

    And that is important because the whole point of XML is that it is eXtensible: New tags can be defined and implemented without those annoying

    You don't have
    • Infernal Exploder Version X.YZ or better,
    • SchlockRave Plugin "Foobar for Morons",
    • Mutant JavaScript From Hell enabled,
    so you suck. Don't come back here until you do, Luzer!
    messages. Once you have a UA that does XML, it upgrades its rendering abilities as necessary without opening gaping security holes or requiring a 12-megabyte download and install
    Installation Complete. Windows will now restart your computer.
    before being able to see some content-free gaudy animated graphic junk on a splash page.
  • There wasn't a link to his site you fscking moron... it's in his profile. Damn, why don't you actually look at the site before you post anything else that further highlights your stupidity. If you've read his site, and his comment about being "slashdotted", he basically refers to an article posting as a "slashdotting".
    Just when I thought I've seen all the idiots, another one comes along ;-/

  • As I said, a website should offer two versions. If a user doesn't feel like making that decision, that decision can be made behind their backs. However, for users that can and want to make that decision, it should not be forced upon them. An enabled-by-default checkbox, maybe? "Accept the server's recommendation for site options."

    --
  • Lowercase tags are easier to read. Capital letters don't have ascenders & descenders, which act as visual cues, allowing us to recognize words by their profile.

    --

  • XHTML Basic is just a subset of XHTML 1.0 which already achieved recommended status last January.

    http://www.w3.org/TR/xhtml1/

    It is meant to be used for smaller applications such as PDA's and such. Personally I believe this set will go the way of the dodo. Designers will not be too keen on creating yet another version of their sites just to accomodate another markup.

    I do plan on updating my own sites to xhtml transitional within the next couple of months.

    -Rod!
  • True, and my site does this too, if only because of offsets...

    I was more referring to XHTML's bitching about nesting of tables, frames, functionality...

    Some browser detection is necessary due to implementation, though I think many can be over-anal about it.

  • No, I honestly don't believe that a stricter language is the next step anywhere. Remember, in the internet, a step that helps stupid people do more is key. Like AOL and IE. Its almost common now for people to leave out html tags and the browsers don't care. The other thing that seems to drive a lot of people is the way it looks. If they cant have browser specific custom scroll bars or annoying DHTML/flash they get bored. So I think the next step, if XHTML is even in the equation, are programs that write XHTML or some type of action that just makes XHTML more like HTML.
    "Compared to the rich functionality of HTML 4, XHTML Basic may look like one step back, but in fact, it is two steps forward for clients that do not need what is in HTML 4.."
    Is that saying that a simple HTML may be better for people that don't need everything in HTML 4? Id understand if it was "for an audience that cant read full featured HTML 4", but if you dont need something in HTML 4, you just dont use it?
  • Those complaining about the lack of tables miss the point. Tables really aren't very useful on a lot of small devices. People who use them for layout find their pretty design turns into crap on a little 150 pixel wide screen (and sometimes on a TV screen too). People who use them for tabular data still find that all that nice tabular data won't fit in the width of these small devices.

    Leaving out tables emphasizes that you really can't count on a wide screen to fit all your lovely design and content into, and since the purpose of this standard is to have a simplified HTML for devices that don't fit well with the full HTML standard, it makes a lot of sense.

    I just got my VisorPhone today and went browsing a bit using PalmScape. Pages generally were fairly readable except for the parts using navigation and tables and such that were expecting to fit on a wider screen, those fell into a total mess because they just don't fit on a small device. Sites designing with those devices in mind need to avoid reliance on things like tables- they just don't fit the medium well.
  • This is really a good thing. Devices that can't afford the real estate for a full featured HTML/ XHTML renderer shouldn't be ignored. For a lot of e-commerce and information sites, the ability to display on mobile devices is really important. If I'm a business person checking my portfolio on the road (or even looking for directions on the road), then I'm an important client with a device that can't support full XHTML.

    A lot of Professional web designers already pay a lot of attention to the standards. When you write, you have to pay a lot of attention to the platforms available, but new standards tell you what you can look for on the latest software, and what to keep a heads up for in the next version. Most browsers have some CSS support now, and that's very useful, for example.

    It's really good to extend this to less featured devices. Plus, there is a better chance that they will track the standards, since many of them have not been developed yet, and even the ones that are often need a software upgrade to work with the Internet at all.

    There is also much less diversity in the feature set supported across each class of device, so that makes it easier, also.

  • It doesn't have trames, tables-in-tables, no scripts no bold-tags an things like that....
  • In which case a lot of people are "missing the point". Go into a newsgroup like comp.infosystems.www.authoring.html (which is a story unto itself), and you'll see endless and pointless competition on people converting their sites to XHTML, just because it can be done. Or in many cases, can't.
  • Of course, we do all realize that eventhough IE4 and NN4 are 90+ percent compatible, companies and designers still choose to DETECT THE BROWSER AND CREATE DIFFERENT VERSIONS.
    This is happening a lot less often. I've worked at two different interactive agencies, and my experience has been that many agencies these days prefer to avoid the work of browser detection if they can. If they're using ornate Javascript, then they'll do it if they have to, but otherwise, they consider it labor wasted because it could've been spent on better design or a more robust backend.

  • Now we have Dynamic Positioning

    But we really don't have that yet, and we won't until most people are using browsers that support it.

    Seth

  • Just when I learned how to do tables ....

    Yeah, really. We're moving pretty fast here, aren't we? Hells, most browers now aren't fully standards-compliant (how that annoys me!). Also, what about web designers who are learning the language now? I've known HTML for quite a while, but my mastery of tables and their relationships with CSS has been more recent.
    Nevermind whether XHTML is better or worse, this will probably confuse everyone involved with web design, from coders like me to browser designers.

    BTW(and OT), I've recently switched from IE and NS4.7 to Mozilla 0.6 and I'm quite satisfied with it. Though I still have to use IE to post to /. ...

    -J

  • Again this is a giant leap forward. WML is truly xml compliant. xHTML 1.0 is a full transitional version before all the static crap on the web now will become xml compliant requiring only transitions to decided what final formatting will do.

    One huge drawback to this is expertise required to get a simple site up and running that you will be able to sell your thingymcbobs on, and some place like Amazon will have the staff with the expertise making the web an unlevel playing field. Gone are the days where someone with a great product could acheive national buisness as things shift from IE vs. Netscape to: IE vs. Netscape vs. Mozilla vs. WebTV vs. Palm vs. Motorola StarTAC vs. Dreamcast vs. WinCE vs. whateverNewContraptionComesDownThePike!

    Its a sad day for designers as well, although they may enjoy the challenge. I guess its just a good thing that you really have 1-2 years before this technology really grabs hold.

  • HTML in it's current state is a terrible failure. It did not serve it's purpose as content markup (what XML successfully does now), because of browser-makers' addition of non-content tags and too late introduction of CSS (if CSS was out there when HTML started, we won't have FONT tags and all that sillyness). Neither it served it's purpose as visual markup language - try to do something really smart with HTMl and you get or into browser-dependant DHTML/Javascript, or into Java or Flash.

    Ih general, HTML became total failure. That's why the urge for replacement was so strong that W3C even created some useful stadards before Microsoft or some other marketing juggernaut had to come and do it as they like.

    But, misuderstanding those new standards can do you a bad service, as it did to HTML. XML not an HTML replacement. XML is purely content-markup language. You can generate visual markup from XML content markup with XSLT or DSSSL and CSS, but XML itself has only logical markup, that's it. It is returning to SGML principles, enriched by the expirience of real application and real developers' needs. It adds a bit of complication by requiring you to know all those standards, but when you grok it (and believe me, it's not so hard - one can do it in a matter of days), it vbecomes clear and logical hierachy of content representation standards.

  • Re:Basic is just a subset (Score:3)

    by JimDabell ( 42870 ) on Saturday December 23, 2000 @05:04AM (#542350) Homepage

    Personally I believe this set will go the way of the dodo. Designers will not be too keen on creating yet another version of their sites just to accomodate another markup.

    You're missing the point. You can create a single set of xml files to store your content, and two (or more) xsl files, to render into different formats, e.g. xhtml, xhtml basic, pdf, etc.

  • I know they aren't kidding when they say BASIC, but what do you want in markup that'll work on a wristwatch as well as my PC.

    A sure sign that XHTML has become too BASIC(*) is when we start seeing markup like this: (grin)

    <10><FOR i = 1 TO 10>
    <20><PRINT i>
    <30><NEXT i>

    * BASIC = Beginner's All-purpose Symbolic Instruction Code

  • I think you misunderstand the point of SGML and XML. XHTML was not split from XML; it uses XML as a base for ease of parsing. XML is simply organization of data. In the case of XHTML, it is the organization of layout data. The point of XML is to separate the data issues from the business logic from the presentation concerns of publishing information.

    Case in point: A <p> tag in HTML is what? It is a paragraph delimiter and it signals to the browser to skip a line. The meaning and the presentation are intimately connected. But what if you don't want your paragraphs to render that way? What if you want to give your paragraphs a distinction from other paragraphs? What if it is not a paragraph at all, but you wanted a blank line (very often the case with HTML)?

    XHTML also serves to normalize programmatic manipulation. That previous sentence of gibberish simply means that we can use a standard XHTML-compliant parser instead of reinventing the wheel. It means that we don't have to worry as much about some lame-brain who decided that a <body> tag should go inside of their table cell.

    XML is meant to give meaning and structure where HTML could not. After you know how to organize your data, styling it with a conversion (via XSLT) to XHTML or styling it directly with CSS becomes more trivial. But why not start with HTML? Because the XML you have is only data and because that is a separate piece, a new XSLT transformation can occur or a new CSS representation can be substituted with minimal effort.

    Separation of concerns also allows for someone to define a structure (schema) for the data so that a common set of stylesheets may be used. For example, in the Cocoon project (http://xml.apache.org/) it is possible to have a single data source (XML), but the output may be presented differently for different web clients, output as plain text or even output as PDF!

    Combine this with something like RDF to give further context to the data and you're well on your way to avoiding the search engine hell that we have today. If I do a search for breast cancer, porno should not come up in the search results. If I want porno, I shouldn't get links to breast cancer. HTML and XHTML will never solve this issue on their own.

    Is XML -> XSLT -> XHTML more complex and CPU/memory intensive than just using HTML? Yes. Does that mean we should continue to use HTML only? Absolutely not! Tuned assembly language will always be faster than the equivalent JavaScript code. So why don't we code in assembly on our web pages? The answer is that we don't want to worry about pushing onto the stack, firing an interrupt or maintaining the heap allocator when all we want is an alert box. And we want to be able to read, add to and maintain it tomorrow and the next day.

    The analogue here is that we don't want to have to update the company logo on hundreds or thousands of web pages every time the company decides that it needs a new logo (don't you love the marketing department?). It means that you can change it on only a handful of stylesheets instead.

    CPU time and memory consumption are relatively cheap when compared to time spent by human developers. Every 18 months, computer speed and storage capacity doubles. This is not so with the humans that use them. You do the math.

    This is (mostly) not a W3C power-play. This is common sense trying to climb over the dung-heap of data known as the web. C'mon! Who better than a Swiss to get things organized?

    P.S. XSLT is not a rendering/formatting mechanism. It is a schema transform mechanism. The fact that most people use it to transform to XHTML is incidental. It can (and is) be used to simply transform from one data-oriented XML document to another.

    P.P.S This post was not meant for the 16-year-old updating their dog's picture on his/her "free" 5MB of web space that came with the parents' new DSL line. This is meant for those individuals who work on the web and must maintain hundreds or thousands or millions of pages of press releases, product brochures, support information, employee registries, bug tracking and project schedules. Or in the case of porn, it is meant to separate the blow-jobs from the anal sex.
  • Ironically enough, the W3C uses a table to layout the W3C A to Z bar to the left, the news content in the middle, and the other links of the right side. And I quote..

    Ah, but it is a table of content, isn't it? ;-)


    --
  • You're missing the point entirely, as others have pointed out, XHTML Basic != XHTML.

    As for two streams, it's a very Bad Idea [tm], because the number of possible User Agents and uses are infinite, so you would have an infinite number of streams. Or being constrained to a small number of streams like we now are. I hate it.

  • However I also feel that appliance manufacturers should set their sites higher to the same standards as computer browsers.

    What is required from an appliance such as a mobile phone, and what is required from a full-fledged computer browser is completely different. "Internet appliances" generally have a much slower connection, and must provide a much quicker response. There is a tiny fraction of screen space available compared with a computer screen. The user is likely to be much less computer literate. The device is used in a different way, for different purposes.

    What this all adds up to is...(gasp!) using the internet from a device such as a mobile phone is different from using it from a computer. And usually, different problems require different solutions. Hell, if the manufacturers really think they can manage it, they can always try to implement full XHTML on their devices. While they're at it, they can probably fit in Java applet support as well, right?

  • XHTML was not split from XML; it uses XML as a base for ease of parsing.

    That is not how it happened.

    When XML was presented with great fanfare in the 1997 World Wide Web conference the designers claimed it was the end of HTML. A while later, when nothing of the sort seemed likely, they shifted gears and by 1999, the same group of designers were saying "let's face it XML won't replace HTML".

    I know 'cuz I was there...

    XSLT is not a rendering/formatting mechanism. It is a schema transform mechanism. The fact that most people use it to transform to XHTML is incidental.

    Once again you lack the historical context. XSL was proposed to do formatting. In the process of implementing this formater, people realized that what we call formating is actually two things (1) a transformation and (b) page layout.

    So they split the project into two XSLT and XSL the first with transformation primitives and the second with formating objects.

    This is (mostly) not a W3C power-play. This is common sense trying to climb over the dung-heap of data known as the web. C'mon! Who better than a Swiss to get things organized?

    A power play is the wrong term. This is more like an ongoing technical debate between the SGMLers and the rest of the world. The SGMLers believed that SGML was the end all (I think it is only a good beginning) and aimed to destroy the impure HTML with XML. In the process SGMLers learned a lot about simplicity of design, predefined tags, formating and linking. All issues that had been neglected by SGML.

    As part of that learning process came the realization that there was a need for XHTML.

  • I'm always amazed at how wrong Tim Berners-Lee got SGML and how for exactly that reason HTML was successful where SGML had failed miserably.

    I assume you're saying that Tim misunderstood SGML's goals and mangled them in the creation of HTML, but mightn't it have been a more pragmatic thing? He wanted something usable, and he created it, and it worked.

    The software field is littered with theoretically pure technologies which aren't widely adopted because of a staggering variety of practical issues that arise when ordinary mortals are faced with the task of doing something useful with a computer. Every now and then, someone with a practical bent comes along and incorporates just enough of the most useful and usable pieces of one of these pure technologies into a working end product, which people then adopt en masse, largely because the theoretical underpinnings, while imperfectly implemented, significantly improve on what went before.

    Think of computing science and the concepts it produces as a Platonic world which effectively has no real existence, because of lack of practically usable implementations. The real world can only generate weak shadows of the concepts in that Platonic world. Cutting-edge software designers attempt to translate theoretical concepts into useful and usable end products, but these attempts often fail.

    One can't and shouldn't judge people like Tim and their achievements from a purely software-theoretic point of view. Rather, he made something usable for the rest of us, and raised the bar for those coming after him.

  • So even though there exist at least 25 million web servers serving at least 1.3B web pages (i.e. html documents), html is still a "total failure"? We must be using different dictionaries, 'cause I'd call that a pretty successful technology. Again, I'd ask that you share your special definition of "total failure" with the rest of us. Hint, it's not the same thing as "imperfect."

    Believe me, I agree that HTML's day has passed, but it is not a "total failure", in fact it has done a huge amount of good for the computer industry, and will be regarded by history as a tremendously successful (albeit imperfect) technology.

  • Many simple Web clients cannot display fonts other than monospace. Bi-directional text, bold faced font, and other text extension elements are not supported.
    I've been goading my friends for years to make web pages that are easy to view in lynx, but XHTML "Basic" goes too far in its rigorous approach to creating a universal standard.

    Beginners now, instead of using <b> and </b> will have to learn how to create style sheets or use extensions to the DTD! This new move, if actually adopted by web browsers, will make even MORE people use Netscape Composer and other front-ends rather than realizing how simple HTML is... or was... to use. XHTML Basic doesn't seem so "basic" to code, removing one of HTML's great strengths.

    Wireless clients will now have to send out more GETs to display data. If they honor any sort of style sheet, they're going to be following at least one LINK per web page. That'll use up more air time; services charging by the page or even by the minute will cost more for wireless users.

    Can't handhelds and other browsers just ignore markups that they can't display?

  • The recommendation for compatibility -- and what tidy does -- is to use the XML notation for a tag that closes itself: <br />
    Note the space.
  • Oh, hey, the W3 recommended it! I wonder what impact this will have on how Netscape and IE put together their browsers... hmm... well they've been pretty top-flight in sticking to spec so far, haven't they? I imagine they'll be about as compatible as they have so far, which is to say, very freakin' little.
  • I know they aren't kidding when they say BASIC, but what do you want in markup that'll work on a wristwatch as well as my PC. I know there aren't even tables in the spec, but it'd be a great way to "page" your friends.

    It seems to me that this will be a big hit for "Push" content (like PointCast -- remember PointCast?) I just wish it could have tables and forms for more interactivity. I guess if you're getting pages on your smart watch it's not an issue.

    Still I'd like the ability to punch in my zip code to get some weather updates, or something.

    I wonder if they will make XHTML Basic less basic when people start adding tables and forms with XHTML Modules. Interactive sells. Is XHTML Basic, too basic? (No forms, or tables -- can Mod it though)

  • Re:XHTML and LCDs (Score:3)

    by Fred Ferrigno ( 122319 ) on Saturday December 23, 2000 @12:56AM (#542363)
    There's nothing wrong with saying "hey, your browser might not work with this." The problem is that server-side browser detection says "I know more than you about what your browser can handle." A good site should, as was suggested, offer two versions. The important part is to let the client choose which one to use, rather than forcing one.

    --

  • Another reason to avoid tables (Score:3)

    by lemox ( 126382 ) on Saturday December 23, 2000 @12:59AM (#542364)

    It's not just about device independance, it's about a change in concept. Tables were not intended to be formatting elements, but to contained tabulated information. Previously, there was no other way to do the same kind of formatting that tables accomplished, therefore they were used as such.

    Now we have Dynamic Positioning, which negates the necessity to use tables for formatting. It can do everything tables can do, and much, much more. Being able to look at positioning attributes in their own seperate file eases upkeep by an infinite amount when compared to wading through multiple levels of tables that will break if just one of the tables is off by a bit.

    Dyanmic Positioning is a CSS element, therefore seperating Style from Content(tm). If everyone started using tables only for their intended purpose, the searching capabilities would expand tenfold. TD stands for Table Data, not "A place to to put yet another grossly overused left-hand nav buried within 10 nested tables".

  • Yes, XHTML Basic is for internet devices, as it is just a subset for XHTML 1.0, which is a recommended standard for the web as a whole.

Slashdot Top Deals

FORTRAN is not a flower but a weed -- it is hardy, occasionally blooms, and grows in every computer. -- A.J. Perlis

Close