Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
The Internet Programming Technology

The Future of HTML 404

An anonymous reader writes "HTML isn't a very good language for making Web pages. However, it has been a very good language for making the Web. This article examines the future of HTML and what it will mean to Web authors, browser and developers. It covers the incremental approach embodied by the WHATWG specifications and the radical cleanup of XHTML proposed by the W3C. Additionally, the author gives an overview of the W3C's new Rich Client Activity."
This discussion has been archived. No new comments can be posted.

The Future of HTML

Comments Filter:
  • Flash (Score:5, Insightful)

    by mattwarden ( 699984 ) on Friday December 09, 2005 @02:39AM (#14217148)
    "Everything will be in Macromedia Flash soon." - 1999
    • Re:Flash (Score:5, Funny)

      by B3ryllium ( 571199 ) on Friday December 09, 2005 @03:10AM (#14217260) Homepage
      *ahem* 1997 is calling, they want their VRML back.
    • Re:Flash (Score:4, Funny)

      by tratten ( 783047 ) on Friday December 09, 2005 @03:24AM (#14217306)
      "Everything will be in Adobe Flash soon." - 2005
    • Re:Flash (Score:2, Funny)

      by Anonymous Coward
      Modded insightful? Mod it funny!
  • What? (Score:2, Insightful)

    by Anonymous Coward
    "HTML isn't a very good language for making Web pages."

    What? Of course it is. It's perfectly suited for making Web pages. What is this, Wired Magazine?

  • It wont ever leave. (Score:4, Interesting)

    by Sinryc ( 834433 ) on Friday December 09, 2005 @02:49AM (#14217180)
    Why should something leave that is so simple to use, and something so many people know? Hell, I can slap up a little page with HTML in about 20 minutes, but I can't do it in anything else.
    • I suppose one might have said the same thing about DOS 15 years ago. I even remember an article in a PC magazine back then where a priest condemned the GUI, stating that "Icons belong in the church, not in the computer." Times have changed since then. I'm sure something better and probably even easier than HTML will come along and take over eventually, we just don't know when or what it is yet.
      • by Anonymous Coward
        I would fully embrace any new technology that's better than HTML if it were easier. Unfortunately, every new thing that developers think of does a million and one things with a million and one ways to go about them. Programmers get off on this sort of thing. "It can do ANYTHING!" Bravo, nerd, but you forgot about the majority of users along the way. Over-engineering. Learn it. Be aware of it. And for God's sake, stop doing it! Or at least hide all of the scary wiring from us who don't want to do every last
        • That (the relative difficulty) is part of why the current set of proposed technologies aren't going to replace HTML completely. Once someone comes up with a sane web-friendly document description language without the rendering ambiguity of HTML, that is also as easy to write for a human and efficient to parse, then we'll have a good replacement for HTML. As long as it's unencumbered by patents, of course. I'm sure it will happen, I just don't know when.
  • FALSE (Score:5, Funny)

    by majest!k ( 836921 ) <slash@NoSpAM.majestik.net> on Friday December 09, 2005 @02:50AM (#14217184)
    "HTML isn't a very good language for making Web pages."

    Sounds like one of those stupid True/False questions from my highschool computer class
    • Re:FALSE (Score:3, Insightful)

      by jurt1235 ( 834677 )
      Sounds like Microsoft to me.
      Microsoft has been saying this for years. They invented AJAX as an extention to speed up HTML since it is just not fast enough in their opinion.

      I think however that a XML based document style, what HTML in essence is, is extremely easy to use with even the simplest tools. Any other document with that much layout options, needs extended editors (unless you know postscript out of your head, so you can do it in postscript (-: )
  • by Anonymous Coward on Friday December 09, 2005 @02:51AM (#14217187)
    It hasn't been stated enough. HTML worked (and got up the noses of lots of I.T. people whose power it undermined) because even a child could do it!

    The real tragedy has been the unnececesary complexity of what has come since.

    A key reason why CSS has taken so long to standardise across browsers is its sheer complexity and contradictions of logic.

    Simplicity is the hardest thing to do. W3C needs to return to it.
    • by dolphinling ( 720774 ) on Friday December 09, 2005 @03:06AM (#14217247) Homepage Journal

      No.

      The only reason "a child could do" HTML is that it doesn't matter if they screw it up, the browser will still display things, and do a pretty good approximation of what they want. With XML, one misplaced & or < kills the whole page, and plenty of people who use it professionally still mess up, especially in dynamic environments, and especially when outside content is being used, like allowing comments.

      A child, you'll find, can also do CSS. It takes a small bit of tutorial, and a lot of looking things up or asking around or copying and pasting when they need to do something, but they do it, and it works. This is because CSS has well-defined error handling. The spec says what to do in (nearly) every situation, so all browsers do it the same way, and it's not draconian--one mistake only kills the rule you're working with.

      CSS hasn't "standardized across browsers", because the largest-marketshare browser hasn't been updated in 7 years, since around the time CSS 2 first came out. In all modern browsers, all but the most obscure and least tested features of CSS render the same.

      • by Fallingcow ( 213461 ) on Friday December 09, 2005 @03:42AM (#14217376) Homepage
        CSS hasn't "standardized across browsers", because the largest-marketshare browser hasn't been updated in 7 years, since around the time CSS 2 first came out. In all modern browsers, all but the most obscure and least tested features of CSS render the same.

        It's not just that they havn't updated. They also use a non-standard box model, and since as far as layout is concerned the box model is the most important part of CSS, most non-trivial layouts (and even many trivial ones!) will require hacks to look the same in IE as they do in other browsers.

        This, more than the failure to update, is the biggest annoyance for those trying to code standards-compliant CSS, IMO.
      • The only reason "a child could do" HTML is that it doesn't matter if they screw it up, the browser will still display things, and do a pretty good approximation of what they want. With XML, one misplaced & or > kills the whole page, and plenty of people who use it professionally still mess up, especially in dynamic environments, and especially when outside content is being used, like allowing comments.

        And that is bad? One of the reasons alot of websites are so broken is because thier developers didn

    • Another reason was because you could learn from other people. I don't know how many times I have hit view source to learn how the author did something or another.

      HTML was open source and simple source. That's a powerful combination and a lesson waiting to be learned.
  • HTML = simple. (Score:5, Insightful)

    by ki85squared ( 778761 ) on Friday December 09, 2005 @02:52AM (#14217192) Homepage
    I know that as a novice developer, HTML is the more simple web developing language. I was taught HTML freshman year along with everyone in my grade level, and most people picked it up right away. If schools tried to teach php or something to 14 year olds, I'm not exactly sure they'd quite get it.
    • But PHP isn't the same thing as HTML at all! It doesn't do anything remotely similar or share any purposes. You can't teach PHP as a replacement to HTML.

      And the problem with the replacements to HTML aren't their complexity - it's that they are different for difference's sake. Apart from an expandable namespace in XML, the differences between HTML and XML are minimal, mostly unimportant, and just increase the chances older browsers will screw up - not to mention an hypothetical XML-only browser would be una

  • by dolphinling ( 720774 ) on Friday December 09, 2005 @02:52AM (#14217195) Homepage Journal
    As someone on the WHATWG mailing list (I'm actually on the list of contributors for WF2, though for minor things), I'd say this is a decent overview of what WHATWG's doing. I expected something about XHTML 2, though, and a comparison.. I guess that's part 2 of the "two-part series".
    • Already a jumble of variant support. WebForms 2, XHTML 2, canvas. Different browsers supporting different subsets of features: IE, Opera, Firefox, Safari, Konqueror.

      I agree this looks like a great extension to HTML. But these standards groups need to get agreement and cooperation out of the browser development groups and releases. I guess I wouldn't mind Firefox and Opera leading the edge, since they seem to have better rate of development (well, MS could beat them with sheer resources, but the play-nice
  • by js92647 ( 917218 ) on Friday December 09, 2005 @02:53AM (#14217203)
    This isn't different than saying that BASIC will go away.
    In my own opinion, I think that, like BASIC, people will make their own variations of HTML to do the job it's made for. Saying "it will go away" is total BS, because really, nothing goes away.

    Pascal is how old? What's Object Pascal? That's right, it's Delphi.

    Another media exaggaration. Stop with this blatant crap. Same has been said about C/C++ because of .NET and C#, but guess what: I don't see anything happening because you cannot remove a language that does a job that it's actually made for. HTML is simple enough anyone can use it, that's the whole point of having it as a "beginners" web language. It's the lowest common denominator, once again, just like BASIC was (and probably still is). They even rambled on how Java would replace C/C++. Jesus flipping christ.
  • by cperciva ( 102828 ) on Friday December 09, 2005 @02:57AM (#14217215) Homepage
    Yes, there is such a thing as being too smart -- at least if you're a piece of software. These days, if you're a web browser, it isn't good enough to know how to perform HTTP requests and parse HTML; you have to understand images in many different formats, interpret Javascript, keep track of cookies, parse XML, and maybe even execute Java or Flash applets.

    So what's the problem? People like having all of these features, right?

    The problem is that there is a hidden cost to having all of these features: Security, or rather a lack thereof. Remember that every line of code is a potential security flaw; and then think about the fact that FireFox is about 15x larger than lynx. Unsurprisingly, there aren't many security flaws in lynx.

    I'm not suggesting that we should never add new features. Adding support for embedded images, for example, was a pretty significant step forward for the web. However, every time somebody steps forward and says "look at this new feature which I've added to the web browser and all the cool things I can do with it", our first questions should be "how much code does it take?" and "how easily can it be done securely?" -- and if the answers are "lots" and "umm, I haven't thought about that", then it's probably not a worthwhile feature, regardless of the amazing tricks it can be used to perform.
  • HTML Did Quite Well (Score:5, Interesting)

    by MoThugz ( 560556 ) on Friday December 09, 2005 @02:57AM (#14217218) Homepage
    The one thing that the author missed is the "Intention" behind HTML. It was invented primarily to create documents (hence, the availability of h1 to h6 tags as the article illustrates). Furthermore, HTML is oh so accomodating and expandable.

    Basically, every example that the author's given can already be replicated using current web technologies albeit via plugins and some scripting (server side and/or client side).

    Not bad for a language that was primarily intended to generate documents now, is it? I fail to see why the author chooses to make it very clear at the start of his writeup about how "clunky" and "unsophisticated" HTML is, but concluded it by saying how current innovations like AJAX is already making HTML5 obsolete.

    Nice writeup, but no clear objectives.
  • HTML is fine (Score:5, Interesting)

    by NittanyTuring ( 936113 ) on Friday December 09, 2005 @03:17AM (#14217282)
    HTML is fine. CSS is great. It's everything inside of <script></script> that needs cleaning.
    • Why stop at <script>? I use CSS so that I don't even need a <body>! I can change the entire content of the page by just changing the style sheet. Localization is a snap: I serve the same HTML to everyone, and just change the CSS for each locale! Here's an example:

      <html>
      <head>
      <style type="text/css"> .t { background:url('hello world!') }
      </style>
      <body onLoad="document.write(document.styleSheets[0].rul es[0].style.background.substring(4,16))">
      </body>
      </html
      • document.styleSheets[0].rules has no properties

        (and even if you changed that to cssRules, you would still have the value "transparent url(hello world!) repeat scroll 0% 0%" for background :P)

    • Re:No it is not. (Score:5, Insightful)

      by SolitaryMan ( 538416 ) on Friday December 09, 2005 @05:16AM (#14217649) Homepage Journal
      It's everything inside of <script></script> that needs cleaning.

      It is so dirty because HTML is not fine in the first place. Many JS on the page usually just compensates for HTML incapability of providing good widget set and rich controls. I don't like JS, and I think that controls such as trees, popups etc. is a MUST for web markup.
  • by Animats ( 122034 ) on Friday December 09, 2005 @03:24AM (#14217309) Homepage
    Web pages that won't run without a connection to the server are limited. They can't be archived. They can't be cached effectively. They can't be viewed offline. They often cannot be printed.

    Much of this "dynamic content" is annoying advertising, anyway. So it's going to have to be blocked, like popups and Flash.

    Worse, programmability in the browser means advertisers running their software on your machine. You just know they'll try adware and spyware if it can possibly be implemented. Keeping Java and Javascript in their cage is tough enough already.

    Web Forms 2.0, though, is a good idea. We should have had more declarative validation years ago. Declarative forms are good - the browser may be able to fill in fields.

    • OK, dynamic content should be blocked!? I really hope that I'm misunderstanding you. Dynamic content is what makes the web worthwhile. If we had to go back to static pages being updated by hand we'd be back in the stoneage. If you're talking about dynamic in the browser, you have somewhat more of a point, but I still think there is a very useful place for dynamic client-side interfaces. With all of the data that is available from the server through database connections and web services, the user interf
  • by HoneyBunchesOfGoats ( 619017 ) on Friday December 09, 2005 @03:34AM (#14217347)
    "HTML isn't a very good language for making Web pages."
    Like most languages (including spoken ones), it's not the language itself which is the problem, but rather it is the inability of people to use it correctly.
  • the future (Score:4, Insightful)

    by lsblogs ( 818271 ) on Friday December 09, 2005 @03:34AM (#14217349) Homepage Journal
    All very nice, but lets face it, the big players cant even get browsers to work in a standardised manner for simpler things like CSS and HTML. God help us with more complex features... HTML will be here for a long time, new things will come out, and will be used, but html itself wont disapear for a long long time. There are far to many webpages out there that cant be updated, or wont be updated for it to just disapear. Not everyone will be able to use the newer, more complex features, so in effect, the rich will get richer, and the poor, poorer - as in general the ones with the money will have the ability to hire people to upgrade, or buy tools to do it themselves. Plus where do they draw the line, its great new features may be on the way, but most people know that software is usually out of date by the time the programmer has nearly finnished writing it.... Does this mean they will keep re-inventing the wheel and forcing people to redo sites each year to keep up with newer gadgets and gizmos? (saying that, thats pretty much the current state of things anyway) Then there will be all the extra processing power that will be required just to display what should really be a simple page.. I will probably have to upgrade my pc just to view the next gen websites.
  • by Anonymous Coward on Friday December 09, 2005 @03:46AM (#14217387)
    Check out this open-source project http://witty.sourceforge.net/ [sourceforge.net] which kind of ports the Qt API to web application programming.

    Makes perfect sense for people developing web applications who do not want to know about the latest AJAX/JavaScript/CSS buzz.
  • give it a rest! (Score:3, Insightful)

    by penguin-collective ( 932038 ) on Friday December 09, 2005 @03:53AM (#14217409)
    We have barely scratched the surface of what is possible with the current generations of HTML, JavaScript, and SVG. The two areas where a little bit of standardization would be nice would be in support for drag-and-drop (for simplifying uploads) and rich text editing. Other than that, these people should just give it a rest and let us digest the current set of technologies.
    • Do you think SVG will actually become widely adopted? Who is pushing for it at this point? Who is actively developing viewers for it?
      • I hope SVG will get widely adopted (at least the basic profile) and replace Flash. I think there is a good chance that it will succeed because there is a need for it that none of the alternatives address well. Technically, I think it's at the threshold--there are multiple implementations, and tools and editors are increasingly supporting it.

        However, if SVG were to fail, it would make the argument that there are too many web standards coming out even stronger.
  • it's like ipv6: obviously superior to what we got, but too complicted or costly to implement

    there isn't a lot of overhead required to write an html webpage, there is no educational or infrastructure barrier to entry

    that defines the success of html

    meanwhile, all the replacement specs i see trotted out all over the place are often far more complicated. and i recognize that this is by design, not a failure to grasp the concept of simplicity. they are so complicated because they are trying to do so many things, these more sophisiticed protocols and doc templates. well then that's the error: setting your sites too high. people don't want more options, they just want to do something

    this megalomaniacal approach: "do everything" is not a superior way to design a spec. like electronics makers putting television on cellphones or ipods now. this is so stupid, and doomed to failure. christ, people just want to make phone calls

    so what new webservices or protocols will be successful? THE SIMPLE ONES. i even have an example: rss. simple and straightforward. a raft of services similar to rss aren't nearly as successful. too complicated

    KISS, people, KISS

    never forget the KISS principle: Keep It Simple, Stupid!
  • 3D Graphics (Score:5, Insightful)

    by hayriye ( 609198 ) on Friday December 09, 2005 @04:00AM (#14217428)
    From the article:
    And why, in this era of 3D-accelerated graphics cards and sophisticated user interfaces, are Web pages limited to clunky text boxes and radio buttons for user input?
    Why do we need sophisticated user interfaces? The existing controls are easy and universally understood.
    • I totally agree.

      Add to it the fact that not all computers that can access the internet (laptops, PDAs, cellphones, even desktops) have 3d graphics cards. If someone tries to implement a website that only allows you to input information utilizing your 3dFX card... they just end up drastically cutting back on the amount of users visiting their site.

      Ditto for anything web-related, not just form controls. I've helped many people (friends and family) set up their systems without enabling ActiveX because of all o
    • Thanks, that paragraph also caught my eye.

      In addition: Maybe there will be better UI elements for entering text and picking items from a list in the future. But I doubt that very fast 3D graphics will have anything to do with their acceptance and implementation.
  • by 5plicer ( 886415 )
    let's just deprecate all tag except div :p
  • HTML is good (Score:3, Insightful)

    by mymaxx ( 924704 ) on Friday December 09, 2005 @04:10AM (#14217462)
    HTML is good for making web pages, but bad for web apps. For that you have DHTML, CSS, JavaScript, AJAX, etc...
  • I was speaking to a webdesigner friend and he said HTML is a pain as its trys to combine formatting of a page and content. The split between content (XML) and then having formating (say CSS) makes things much easier to handel and use as you can changes things on the fly
    • Your webdesigner friend is ill-educated, then - although I suspect you're misquoting him/her. HTML does not force you to incorporate formatting, and works perfectly well with CSS. There is no practical advantage to XHTML over HTML, unless your back-end system requires XML compliance. HTML-4.01 can't achieve that due to the presence of a few empty elements without close tags.

    • Put me firmly in the camp that html is brilliant. It suits exactly its designed purpose: to allow academic papers to be easily shared among colleagues. There are no formatting imperatives in a basic html document, the tagging scheme allows the author to include identifiable hints to be rendered or ignored as the client browser chooses.

      Now what you report your web-designing friend as saying sounds a bit like a jumble of the justification for xml, which is a way to tag informational content so that transform

  • HTML isn't a very good language for making Web pages.

    Compared to what? Sure, I've coded enough HTML to have bumped into countless limitations and annoyances. But with all the file formats invented over the years that have been even less adopted, why are we so sure there's something so much better than HTML? Describing visual objects with words (what any web page language has to do) is hard. I've used Java and other languages to do app layout, and they're certainly not any better. Or perhaps we want to
  • by perkr ( 626584 ) on Friday December 09, 2005 @04:36AM (#14217529)

    As long as IE doesn't understand application/xhtml+xml I see no reason to switch.

    Read more about it here: Sending XHTML as text/html Considered Harmful [hixie.ch].

  • by shotgunefx ( 239460 ) on Friday December 09, 2005 @07:04AM (#14217975) Journal
    "HTML isn't a very good language for making Web pages."

    This is based on what? That it's not postscript or flash? Granted there are improvments that could be made, but by and large, it works wonderfully. A simple and universal UI and a markup that almost anyone can learn.

    How is bloating it to do everything you could ever want going to improve things?

    Why do I need to be able to use it as an etch-a-sketch? You want to be able to draw or run around a maze? Get a plugin. Now if they want to standardize plugins, that's another issue.

    Forms could use some work, but personally, I think the limited control of layout is a big plus. Almost anyone who has filled out a form, can figure out any other form. Client side validation? What's the point? Still need to validate server side. Maybe it saves a trip, but that is probably negated by all the extra markup that will be coming over the pipe.

    I like the direction google is taking things. I think incorporating a few smaller changes and we can get most of what's desirable.

    <RANT>
    And author control over auto-completion of form elements? Maybe an author hint, but control? Um, no. Fuck off. For some reason, this somewhat benign point really vexes me. Not to go off on too much of a Dennis Leary tangent, but goddamn it, I'm getting sick of computers and devices doing what they feel like and not what I tell them to. Like power buttons. I want a power button that shuts off that fucking power, not suggests that it should, if it feels it's appropriate. I press open on a drive tray, it better damn open.
    </RANT>

  • by Simon Brooke ( 45012 ) * <stillyet@googlemail.com> on Friday December 09, 2005 @07:58AM (#14218129) Homepage Journal

    If you start by asserting a falsehood as an axiom, any conclusion you reach is going to be wrong. In this case:

    HTML isn't a very good language for making Web pages.

    Sorry, wrong.

    • HTML is a relatively compact, low overhead markup. An HTML page is much more compact than, for example, a PDF or a Word file containing exactly the same data. The consequence of this is it makes good use of low bandwidth links, without needing compression - a benefit I'll return to later.
    • HTML leverages SGML's experience in dealing with multiple character sets, scanning directions, etc; it's therefore effective as a universal markup, not limited to any particular natural language or culture.
    • HTML separates data from presentation, allowing the same content to be made available on a wide range of devices, and to people with a wide range of special needs.
    • HTML is extremely simple to parse; the parser can be extremely lightweight. This in conjunction with the fact that the data representation is compact and doesn't need decompression means that HTML can easily be rendered on extremely low powered devices.
    • HTML's forms extension is admittedly a hack. But it's a successful hack because it's a good hack - it allows system designers to make use of ubiquitous low cost clients. There is a tradeoff between simplicity and functionality and admittedly HTML forms err on the side of simplicity; some more input types would be beneficial. But the XForms proposal is woefully over complex and will fail to be widely deployed for that reason.
    • Finally, HTML is universal and ubiquitous. A huge range of devices out there can accept well formed HTML and render it usefully; there's no need to worry about whether this or that extension or plugin is available on the client.

    In summary, HTML has been so successful largely because it's an extremely good language for writing Web pages. It's become universal and ubiquitous because it's simple, flexible and lightweight. Admittedly HTML is weak in the area of representing special technical formatting such as mathematical formulae; there is a place for such things as MathML et al.

    Yes, there are a huge number of proposals to give us more prolix, more byzantine languages in which to write Web pages. They are going to have to co-exist in a darwinian environment with HTML, and outcompete it. They won't, in my opinion, succeed. In ten, or twenty, years time there will be devices out there which will render formats we haven't yet imagined, and there will be a fragmented web of pages which can only be read on this or that specialised device. But there will still be a web of plain old vanilla flavoured [X]HTML, because that will be the lingua franca that every device can use.

  • Faulty Assumptions (Score:3, Informative)

    by Jerk City Troll ( 661616 ) on Friday December 09, 2005 @09:43AM (#14218646) Homepage

    One faulty assumption I picked out of that read was the mention of header tags.

    Why, for instance, does HTML have headings H1 through H6? Who ever seriously used a six-level-deep heading hierarchy?

    Well, I have. My company makes a web application where we have some heavily nested data (say, for example, a person nested within another person who is their relative, for any number of levels). Because I try to keep all my mark-up as semantic as possible, I need deeply nested header tags. I can also think of all sorts of technical writing that might use deeper than six levels of section hierarchy.

    It is useless to state assumptions which assume a usage will not be necessary. Instead, make as few assumptions as posisble then handle general case which applies as well to everybody’s typical situation but is easy to extend to edge cases. That’s a basic principle anybody in technology should follow. And, in fact, this is precisely what XHTML 2.0 does. It has a "header" tag which is not indexed and styled by CSS which checks for how many ancestor headers there are.

  • by Hosiah ( 849792 ) on Friday December 09, 2005 @10:18AM (#14218952)
    HTML is worse than bad; it needs to be buried. It looks like whoever wrote it must have been swigging absinthe while taking a case-by-case approach and writing *whatever* popped into their mind at the moment. "Um...how to make text bigger? h1,h2,h3,h4,...but we'll use "big" tags here. And change the font size there. And make it so you can also specify size in percent, pixels, *and* points, so no two pages will handle sizing of text the same way. Now, what else can I screw up?"

    CSS, once I learned it (getting the excellent http://www.nvu.com/ [nvu.com]nvu helped), struck me as the way the web should have been designed to start with. At least all the style twiddling is done in one place. At least I use just *one* command to do one thing. Never mind "50 creative ways to do it."; just give me ONE way: the RIGHT way!

    As for TFA, I love canvas and can't wait to start working with it. It looks like the kind of thing javascript was meant to do 20 years ago when everybody started trying to gangbang it. But javascript itself...I would still like to see java and css integrate themselves closer. In fact (as I've said before in these very hallowed halls) I wish for ONE language that does EVERYTHING with one unified syntax - not using this fourth of a language to write this module, and this tenth of a language to write that section. How about making a *whole* web language that can stand on it's own for a change? Since when is trying to knit five baby languages together to make one little page a good idea, when I only needed one language to write the whole operating system and the web browser on?

    Last but not least, forget the backward compatibility. These days, my philosophy is: "Use the brightest and best technology that pleases me at the time, and if it's not compatible, tell 'em to get a REAL browser." I'm sick and tired of trying to build a page that will accomodate *any* Rube Goldberg contraption that *any* moron whacks together and calls a web browser. Do we make our freeways to accomodate ruk-tuks, Big Wheel tricycles, and pack elephants? Come to that, are the roads in a Tibetan temple designed to accomodate Mac trucks and American Monster SUVs? The time has come to say: "If you insist on traveling the world using only a Conestoga, there are certain places you just won't be able to go. We can't pave the ocean just for you."

    • > "Um...how to make text bigger? h1,h2,h3,h4,...
      > but we'll use "big" tags here.

      , etc are not "make text bigger" -- they're "This is a heading". HTML as originally designed didn't have a concept of "make text bigger" at all -- the assumption was that HTML would have logical markup (headings, paragraphs, quotes, etc) and that the renderer would choose the best way to actually present that markup.

      Then browser makers started introducing all sorts of presentational markup ( is an example, as are , etc).
  • by Matthendrix ( 928488 ) on Friday December 09, 2005 @10:31AM (#14219101) Homepage
    Imagine the big websites in a classroom, and the teacher is CSS...

    Teacher: "Google, you're a naughty boy, stop using tables."
    Google: "But mi-eeessss, i'm reaching so many people and making so much money"
    Teacher: "Doesn't matter, get rid of them, now!"

    Teacher: "Amazon, did I see you with an ImageMap? Yes? Well put that away this instant!"
    Amazon: "But Miss, I too am reaching millions and making that much in cash!"
    Teacher: "Doesn't matter, get rid of it, this instant!"

    Teacher: "And Ebay, I see you're covered yourself in Nested Tables again, clean yourself up, you are a disgrace!"
    Ebay: "But miss, i'm just doing what Amazon is doing. And making lots of cash!"

    Teacher: "When you kids grow up, you'll all thank for me making you act correctly."

    Google, Amazon & Ebay:"Yeah, but we'll be rich and you'll still be playing along like a broken record."



    Epilogue: Miss CSS is now in a 12 step program - CSS Purists Anonymous; where she is recovering from her addiction, one day at a time.
  • by egarland ( 120202 ) on Friday December 09, 2005 @01:49PM (#14221135)
    HTML was originally desigend to allow for marking the different types of text as the type they were so the USER could pick how they were displayed. This is a code snippet, this should be fixed width, this is preformated text, etc.

    This delegation of display style was and is a great idea empowering browsers to make things look good and users to pick the fonts they liked the best on "their" machines. It has since been undemined by a flood of additions giving authors the ablity to choose font names for text which most web sites employ (not slashdot though.. thanks guys!) set widths of pages (your new layout sucks arstechnica), pop up new windows without address bars (who was the moron at netscape that decided that was a good idea?) and other fine grained page-layout style things added since.

    HTML was and is an excellent tool for making web sites. It scales all the way from <b>HI</b> to google. It's because it was so very very good at doing what it does that the web is now in the position of global general purpose use and these kids are whining about how hard it is.
  • by recharged95 ( 782975 ) on Friday December 09, 2005 @01:50PM (#14221149) Journal
    HTML isn't a very good language for "making Web pages"

    The above notion is inaccurate. HTML was very good in making web pages, especially back in 1995, but the hardware and requirements have evolved, but HTML has not. More accuracy, it should be that HTML isn't a good syntax for making web applications.

To avoid criticism, do nothing, say nothing, be nothing. -- Elbert Hubbard

Working...