Apple, Opera, and Mozilla Push For HTML5

foo fighter writes "The World Wide Web Consortium (W3C) has been slumbering the past several years: HTML was last updated in 1999, XHTML was last updated in 2002, and no one is taking seriously their largely incompatible work on 'next-generation' XHTML or 'modularized' XHTML. Both HTML and XHTML are in sorry need of removing deprecated items while being updated to reflect the current practices of web and browser developers and remaining compatible with legacy Recommendations. The much more open and transparent WHATWG (Web Hypertext Application Technology Working Group), formed in 2004 to address this problem, and has been hard at work on developing a draft spec for HTML5 to update and replace legacy versions of both HTML and XHTML. The quality of this work has reached the point that Apple, Opera, and Mozilla have requested the adoption of HTML5 as the new 'W3C Recommendation' for Web development."

Comments

The More they add, the less I like

[ackthpt]

OK, I'm a curmudgeon. There, happy?

I still design pages using HTML 3.2 standard. Life was happy when pages were small and simple. I'm very put-off by the way HTML now can do things formerly reserved for javascript. Further, people no longer appear interested in the size of the footprint their pages make and the bandwidth necessary to download them.

We rail away at Microsoft and anyone else who adds bloat to software, but the web is now plagued by page bloat and overly clever designs which render poorly at times, take over the browser and sometimes crash it. Behaviour is becomming terrible, but as pages are done by authors who do not really care, so long as it looks like it should and does the basics, they care not what a wreck have created.

Don't even get me started on people whose home page is some massive flash object.

"Hi, we assume you have the latest browser and all the plugins!"

Re:The More they add, the less I like

[KenAndCorey]

I'm with you brother, although I use HTML 4 and CSS 2. I wish people would take the time to code their pages so they are fast loading and elegant (code-wise), and HTML generation apps would do likewise. Additionally, I wish people would use proper caching as well -- this really speeds a site up too.

Re:The More they add, the less I like

[alienmole]

You have something of a point, but mostly you're confusing abuse by users with a problem with the technology. Compared to HTML 3, it's worth using HTML 4 and CSS, but just be sane and use a sensible subset.

A lot of the bloat is there to satisfy the marketing crowd who want to e.g. control things at the pixel level (and don't understand how that fails on different screen geometries), but that doesn't mean you can't write good-looking, efficient HTML4/CSS pages.

Re:The More they add, the less I like

[littlewink]

I'm the same.

HTML 3.2 and no JavaScript if possible. That's my Lowest Common Denominator.

JavaScript, CSS, and the various HTMLs have forked significantly, largely thanks to IE's lack of adherence to standards.

And as the availability of high bandwidth increases, rich clients become less and less important. Today you can deliver fast, effective systems over dialup _and_ cable or dsl with HTML 3.2.

Re:The More they add, the less I like

[Bogtha]

I actually find things like "normal <B>bold <I>bold italic</B> italic</I> normal" useful

I hate to break it to you, but that's not HTML 4.01 Transitional either. No version of HTML has permitted overlapping elements in the way that you describe. You are merely exploiting error handling that is fairly common amongst web browsers.

Re:The More they add, the less I like

[Billosaur]

Yes, this incessant pushing of the technology/standards envelope is creating a lot of disjoint, stilted, and otherwise unreadable web sites. It used to be web pages were mainly HTML with a few SSI thrown in for good measure; now they are over-burdened with flashy graphics, tricky menus (god how rollovers are getting out of hand!), and a lack of decent content. I mean, I go to a web site to find information I'm looking for. In the old days, you could do that -- now content is so snarled in meaningless fluff that have the time I have to search the source code just to find what I'm looking for.

Re:The More they add, the less I like

[ackthpt]

I'm with you brother, although I use HTML 4 and CSS 2. I wish people would take the time to code their pages so they are fast loading and elegant (code-wise), and HTML generation apps would do likewise. Additionally, I wish people would use proper caching as well -- this really speeds a site up too.

I haven't done much with style sheets, finding them to be just one more thing to manage, as they can get rather large the more I relied upon them.

Effectively when we write the HTML code by hand we're creating very lightweight pages. I set some colours and a simple background based upon a small sample and I'm good. I came from the K-I-S-S school of web design, which seems to be dying mostly thanks to webapp/webpage development tools. It's like watching people program without a care about optimizing for size or speed. They're paid by the hour, not for the quality of the code.

Re:The More they add, the less I like

[mstahl]

Hi there. I'm a web developer/designer. I do flash, too. Good times, right?

I design and build to the XHTML 1.0 transitional standard, and for some bizarre reason one of my clients still makes me test their pages in IE5. When was the last time you even saw a computer that had IE5 on it?

Your objections to design I can't really comment on beyond saying I hope you're not referring to any of mine. But your objection to HTML/CSS doing what javascript used to be necessary for? Really? You prefer writing little-stupid javascript functions to just putting a :hover rule in your CSS? Really?

You, sir, are a rare breed. Hats off to you though; HTML 3.2 is really the only standard the most browsers agree upon (IE6/7 have all those weird box model problems with XHTML 1.0).

Re:The More they add, the less I like

[Bootvis]

Well, you can't blame him. He is not the only one that doesn't get it right: http://validator.w3.org/check?uri=http%3A%2F%2Fwww .whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Fmu ltipage%2F&charset=(detect+automatically)&doctype= Inline

Re:The More they add, the less I like

[LighterShadeOfBlack]

Life was happy when pages were small and simple. The Internet was also small and simple, relatively speaking. Unfortunately now it's a huge mess of information, some useful, some not. In order to helpfully and meaningfully wade through all this fluff we need to more tags and more specificty in our markup to aid search engines and the like in finding what we really want. We may be a way off from the "Semantic Web" as Berners-Lee envisions it, but these are the first steps towards making that happen and preventing the web from being collapsing under it's own ever-increasing mass.

I'm very put-off by the way HTML now can do things formerly reserved for javascript Yeah, that never happened in the past <blink>Remember me?</blink>. Seriously though, I agree on this in principal although I'm not sure specifically what features in HTML you're referring to. Ultimately any attempt to dynamicise (I know, I know, not a word) HTML will fail as it will always be three steps behind what people want from dynamic web pages since we're now moving into the whole "Web 2.0" thing.

Further, people no longer appear interested in the size of the footprint their pages make and the bandwidth necessary to download them. I'm not sure I agree with this. Relatively modern developments allow far more efficient web pages. Firstly by using CSS you can do a lot more with simple markup while allowing the stylesheet itself to be cached for a reasonable amount of time (whereas many webpages have content which prevents long-term caching). XmlHttpRequest obviously allows for only the relevant portions of a website to be updated. Javascript allows for less data to be sent and for the code to do the work of constructing an elaborate webpage (only applies to certain types of webpages obviously).

We rail away at Microsoft and anyone else who adds bloat to software, but the web is now plagued by page bloat and overly clever designs which render poorly at times, take over the browser and sometimes crash it.

...

Don't even get me started on people whose home page is some massive flash object. Sure, some people use poor designs which drain resources unnecesarily, I don't think that's necessarily an issue of new standards or technologies being poor though, just that the flexibility we demand from our new web technologies inevitably allows for misuse. You can't blame Javascript, XHTML, or even Flash simply because some people will misuse it any more than you can blame HTML 3.2 because someone decides to use 24 levels of <table><tr><td> tags to make their layout the way they want. As far as crashing goes, that's a software issue and nothing more.

Re:The More they add, the less I like

[Doctor-Optimal]

They can have my blink tag when they pry it from my cold, dead hands!

Re:The More they add, the less I like

[Bogtha]

It's like watching people program without a care about optimizing for size or speed. They're paid by the hour, not for the quality of the code.

Funny, that's how I feel about people who don't use CSS. Seriously, if you are that concerned with the size of pages and bandwidth, like you say in your other comment, then why are you transmitting your style information on every single page load?

Re:The More they add, the less I like

[Blakey Rat]

HTML/Javascript is such a mess now anyway, one more standard can't possibly make anything worse.

Re:The More they add, the less I like

[Bogtha]

All of those errors are down to the fact that the validator doesn't understand HTML 5. Although it is quite interesting to note the chicken-and-the-egg problem of publishing the specification for a document format in the document format itself. You need to understand the format in order to read the document that explains how to understand the format.

Re:The More they add, the less I like

[nine-times]

I don't really get your complaint. I mean, I share your annoyance with uselessly flashy pages, and literally Flash-y pages, but what's wrong with refining standards? Many of the updates to HTML have made things cleaner, more precise, and more consistent. Some of the added features have allowed web developers to do more with less code (if you can call HTML "code"). Much of what's added in-- if you don't want to use it, don't use it. But if you have some reason to do something flashy on your site, it's probably better to have it be done in some standard way rather than though some hack or by adding Flash to your page.

Re:The More they add, the less I like

[partenon]

Should I assume you use to define the position of the elements?

Re:The More they add, the less I like

[Chris Mattern]

They can have my blink tag when they pry it from my cold, dead hands!

That...can be arranged.

CHris Mattern

Re:The More they add, the less I like

[Bogtha]

You prefer writing little-stupid javascript functions to just putting a :hover rule in your CSS?

I get the impression he's not a professional web designer, so he can just ignore stuff like that entirely.

HTML 3.2 is really the only standard the most browsers agree upon

There's a very good reason for that. The W3C were working on HTML 3 when it became apparent that their work was diverging from what browsers understood; browser vendors were adding stuff at a crazy rate while ignoring the HTML 3 work. So the W3C decided to scrap HTML 3 and make a decent description of what browsers understood in HTML 3.2.

Basically, the reason why "most browsers agree upon HTML 3.2" is because HTML 3.2 was merely rubber-stamping what browsers already did.

IE6/7 have all those weird box model problems with XHTML 1.0

There's no such thing as a "box model" in XHTML 1.0. The box model is a feature of CSS.

Re:The More they add, the less I like

[Bogtha]

They can have my blink tag when they pry it from my cold, dead hands!

If that's what it takes to stop you using <blink>, so be it :).

Re:The More they add, the less I like

[zappepcs]

Uhm, not so sure about that. MS FrontPage seemed to do just that and worse... terribly difficult to parse through with a text editor.

Re:The More they add, the less I like

[blincoln]

Funny, that's how I feel about people who don't use CSS. Seriously, if you are that concerned with the size of pages and bandwidth, like you say in your other comment, then why are you transmitting your style information on every single page load?

Agreed.

To the GP: I recently redesigned my main website after running it for five years with a design very much like the one you describe - all coded by hand, HTML 3.2, no CSS (although I had some equally old Javascript for highlighting the navigation buttons).

The new version uses CSS, and since I designed it using the "strict" mode of newfangled HTML, it renders more or less identically on different browsers. I also built a batch build content management system, so that I don't have to manually edit a bunch of HTML when I change the design or whatever. I made sure the output is basically what I would have done if I did it all by hand though.

I was very skeptical about it before I started, but it really is a much better way to build websites. It saves time, it makes redesigns and multi-platform stuff easier (like theoretically I could swap out CSS files to make a version formatted for PDAs if I were running a website that would be at all useful on them), and it's *much* easier to get relatively consistent rendering across platforms. The only visible difference I'm aware of between Firefox and IE6/7 is related to tables without a fixed width. Neither one looks superior, they're just different.

Re:The More they add, the less I like

[Christianfreak]

Damn kids get off my lawn?

I still design pages using HTML 3.2 standard. Life was happy when pages were small and simple.

Unless you're just putting text on a white page, HTML 3.2 doesn't make anything small and simple ... doing a decent layout with just HTML requires tables which in the end creates tag-soup because they weren't designed for page layout. CSS eliminates that problem.

I'm very put-off by the way HTML now can do things formerly reserved for javascript.

Like what exactly? The :hover pseudo class? That's about the only thing I can think that you might be talking about and its CSS, not HTML.

Further, people no longer appear interested in the size of the footprint their pages make and the bandwidth necessary to download them.

See my first point. An external stylesheet can get cached, table-soup cannot. Besides, its not like people not caring about bandwidth is a new problem.

We rail away at Microsoft and anyone else who adds bloat to software, but the web is now plagued by page bloat and overly clever designs which render poorly at times, take over the browser and sometimes crash it.

HTML hasn't really changed that much .. in fact they've removed more than they've added, unless you're talking about CSS again. I'm not sure what you mean by "clever designs" unless you're talking about something other than text on a white background. I suppose we should get rid of images as well. Heck we might as well go back to using Gopher.

I'm not going to deny that bad sites can crash browsers but that's a problem with the page and arguably the browsers themselves, not with the standards.

Behaviour is becomming terrible, but as pages are done by authors who do not really care, so long as it looks like it should and does the basics, they care not what a wreck have created.

I can't remember a time that this hasn't been the case. Blame the browsers for trying to render tag-soup instead of enforcing the standards from the beginning.

"Hi, we assume you have the latest browser and all the plugins!"

I'm sorry but I'd guess that better than 95% of people have some kind of modern browser(if you can consider IE6 modern ... which is another debate) and better than 90% of people have Flash. Heck even Linux has Flash 9 available. Coding for a single browser is one thing but keeping legacy code for browsers that worked in 1997 is ridiculous. I code my pages to downgrade gracefully but I don't have the time to go and test Netscape 3 for you.

People want the web to be more than pretty pictures and Geocities home-pages. They want it to do something, they want to buy things and they want to contribute. New technology makes all that easier. You don't have to do that but don't complain when the rest of us do.

Re:The More they add, the less I like

[osu-neko]

Should I assume you use <table> to define the position of the elements?

If we're assuming this is a real old-timer we're talking about, probably not. HTML was not intended for complicated magazine layouts. To position his paragraphs one above the other, he puts the one he wants above before the one he wants below in the document, and separates them with <P>. He positions his images using the appropriate attributes. Maybe every once in a while, he gets wacky and uses the <CENTER>. He doesn't use <TABLE> (except when presenting tables of data) for the same reason he doesn't use CSS: there's absolutely no need for it, and almost any use of it you can think of detracts from the simple, easy to read layout he strives for. He doesn't worry about the position of the elements because that's what the browser is for, and he knows HTML was designed so that the browser can position things however the user likes, in whatever size the user likes, and that's perfectly fine. He's okay with the fact that his page isn't going to look exactly the same to the reader as it does on his screen. He knows that if the user decides to render pages with the font 800% larger than he designed it with (note I don't say "for"), it'll still look fine, and any web page that doesn't is poorly designed.

Re:The More they add, the less I like

[Bogtha]

Yes, because MS FrontPage would never output broken HTML, would it?

Re:The More they add, the less I like

[Overly Critical Guy]

I still design pages using HTML 3.2 standard. Life was happy when pages were small and simple.

Congratulations, you stick to old, broken HTML that takes more bandwidth to do the same thing newer, more optimal versions can. Should clients be forced to suffer through Javascript libraries for form validation, or do you want to be able to just specify it in a tag and let the browser take care of it? Computers are for doing the hard work for you, right?

Re:The More they add, the less I like

[Firethorn]

If that's what it takes to stop you using , so be it :).

Agreed.

60hz refresh on a monitor drives me slowly insane.

sub 10 hz blinking text or repetitive graphics(like most web ads), drive me homicidal in under a minute.

Re:The More they add, the less I like

[Vexorian]

A perfect implementation of HTML wouldn't need javascript. Javascript is just wrong to have most of the time, pages are data, not programs, seriously. I am the opposite to your opinion, I think I like a lot the improvements on html4 and specially CSS, I just don't see the point on being nostalgic about HTML 3.2.

Re:The More they add, the less I like

[Bootvis]

I don't think so. To be honest I didn't read the spec (yet) but it appears the page is following HTML 4.01 strict but the doctype is incorrectly specified.

Maybe I'm missing something very important but using HTML 5 to describe HTML 5 seems _stupid_ to me. Like learning an adult French using only French.

Re:The More they add, the less I like

[EsbenMoseHansen]

Effectively when we write the HTML code by hand we're creating very lightweight pages. I set some colours and a simple background based upon a small sample and I'm good. I came from the K-I-S-S school of web design, which seems to be dying mostly thanks to webapp/webpage development tools. It's like watching people program without a care about optimizing for size or speed. They're paid by the hour, not for the quality of the code.

Why do you set color and background? Let that be up to the user. Structured text with some hyperlinks, that is the way to go! Emphasize text with the em tag, use h1-h3 for headers, and the list tags... maybe the table tag for a simple table, or if extreme vital, a link to a SVG or PNG image (which should be obvious). That should be all you need. If you need personal, do a favicon, or maybe a link to a personal picture.

;)

Re:The More they add, the less I like

[MemeRot]

Pages are data, not programs? That's a fine attitude for plain text content sites. Not very good for web applications though.

Re:The More they add, the less I like

[Nimey]

What's a French?

Re:The More they add, the less I like

[Trailer Trash]

(IE6/7 have all those weird box model problems with XHTML 1.0).

No they don't. You simply have to declare a doctype which will trigger standards mode in both IE and mozilla. Problem solved. There are other IE issues to deal with, but thankfully this isn't one of them.

Re:The More they add, the less I like

[dedazo]

Javascript allows for less data to be sent and for the code to do the work of constructing an elaborate webpage

The GP is right though. It's literally the case that a "web designer" will create an impressively streamlined page with a careful mix of validating markup and external stylesheets... only to have you download a megabyte+ of JavaScript.

You know, I think that many of these people have forgotten what it's like to use dialup, and that's why their pages work "just fine". I have nothing against "AJAX" in particular - I think it's a technology that has its place like everything else. But seriously, it's getting out of hand.

Re:The More they add, the less I like

[Anonymous Coward]

Maybe I'm missing something very important but using HTML 5 to describe HTML 5 seems _stupid_ to me. Like learning an adult French using only French. Obviously, it was also stupid to think that a teacher could "learn" you English using only English. ;)

Incidentally, we call teaching someone a foreign language by using nothing but that language "immersion". While it's certainly not the most gentle method in terms of initial learning curve, it has been demonstrated time and again to be among the best methods. It works on adults to. If you move to a country without knowing the language, the desire to stay alive (and eat!) tends to be a very strong motivator for accelerating the learning process.

(Compiling the source of a compiler with the compiler itself is a mark of maturity. Writing a specification in itself doesn't seem in any way outlandish.)

Re:The More they add, the less I like

[osu-neko]

Damn kids get off my lawn?

Damn straight. What was nice about the WWW was that I could now stick images, bold/italics, and most importantly hyperlinks to other documents inside my documents. These were important and very nice features that made it worth moving from Gopher-space into the WWW, and life was good.

Then some people got the silly notion of trying to do "page layout", and getting upset because they couldn't control exactly what the page looked like on the end user's browser. Of course they couldn't. How would they know what size fonts the end user finds comfortable reading? How would they know what kind of margins the end user prefers seeing? How much space he likes between his paragraphs?

Insofar as CSS moves all the "page layout" functionality out of the HTML document itself, this is a very good thing. Insofar as there are many people who's pages look completely borked if you rip out the CSS link, there's still a lot of progress to be made until the web finally looks as good and is as easy to use as it was in '95. We took giants leaps backwards for several years, and haven't quite fully recovered yet. But CSS, when used properly, does promise to return us to the days of simple, quick, easy to read HTML.

Still, I frequently show up at sites looking for information, look at the horrid layout, and wish they had a Gopher site with the same information, where I'd actually be able to read it. :p

Re:The More they add, the less I like

[LighterShadeOfBlack]

I'm afraid I can't agree with it being the browser developers fault. Can you have a monopoly based on 3 entirely separate and competing companies anyway? Besides, the Gecko renderer is open source so it's not like Mozilla have some vested interest in any kind of lock-down. Someone could always fork the Gecko project at any time if they didn't like where Mozilla were going with it.

Sure, as things are getting more complex then it becomes harder to create accurate renderers. However I do not believe it is the browser developers who are the primary reason for the push, they are simply trying to provide what people want. Consumers (by which I mean web surfers, website developers, and more recently web-based application developers) want more features. The important thing is that new developments are properly standardised and documented openly so that even if new standards are harder to render, they can at least be developed without having to be "in the club". Which thankfully both the W3C and WHATWG are doing. Also I'd say that HTML5 is a lot less complex than the W3C's proposed developments for XHTML.

Re:The More they add, the less I like

[jalefkowit]

I still design pages using HTML 3.2 standard. Life was happy when pages were small and simple. I'm very put-off by the way HTML now can do things formerly reserved for javascript. Further, people no longer appear interested in the size of the footprint their pages make and the bandwidth necessary to download them.

If you are sticking to the HTML 3.2 standard you are doing exactly the opposite of what you state. Before CSS, HTML documents had to have tons of redundant markup for formatting embedded inside them. Using CSS, you can move all that stuff into a single file that the client only has to fetch once, and which can then be cached locally by the browser. You can replace hundreds or thousands of FONT tags with a single one-line directive in your CSS file. That means more efficient use of bandwidth, not less. CSS is a fantastic tool for reducing page weights and download times -- especially compared to porky HTML 3.x pages.

And as for "HTML doing things formerly reserved for Javascript", I literally have no idea what you're referring to. HTML elements can't have logic embedded in them without Javascript. They can't change based on user actions or page state without Javascript. They can't alter page presentation without Javascript. And on and on.

Don't even get me started on people whose home page is some massive flash object.

Proprietary binary blobs like Flash are completely different beasts from standards like HTML and CSS, and have nothing to do with the problems the W3C and WHATWG are working on. They are trying to make the Web better so that there is less demand for proprietary binary blobs! How on earth is that a bad thing if you hate proprietary binary blobs?

OK, I'm a curmudgeon. There, happy?

If you're rejecting better technologies out of hand just because you decided in 1997 to stop paying attention, you're not part of the solution, you're part of the problem.

Re:The More they add, the less I like

[sYn pHrEAk]

Le Français est une langue.

Re:The More they add, the less I like

[f00dif00]

A computer with IE 5.0? Well, actually, saw one last Monday night. We're working on upgrading it.

Re:The More they add, the less I like

[644bd346996]

Implementing a browser that can handle compliant pages is actually pretty easy. Sure, implementing HTML+JS+CSS would take a long time compared to just XHTML, but it still wouldn't take several years with several people working on it.

What makes implementing a browser hard is handling the errors that exist on most pages. Practically every automated web design tool spits out non-compliant pages, and most existing sites prioritize IE compatibility over standards compliance. No browser will be useful in the real world if it can't handle the most common errors.

Re:The More they add, the less I like

[nottoogeeky]

well said :)

Re:The More they add, the less I like

[lee1]

I still design pages using HTML 3.2 standard.

No, you don't. Your website fails to declare a doctype and fails to validate (17 errors on the home page alone). Also, it rudely opens new windows when I click on links. And it's ugly.

Re:The More they add, the less I like

[EugeneK]

Way to miss the parent's point! His point was exactly that; that if you use CSS you don't need to send the styling info with every page load.

Re:The More they add, the less I like

[Bootvis]

For HTML 5 there is nothing yet only the draft and the draft is in HTML 4.01 strict. My guess: They fscked up. P.S. I have learned my languages using a teacher, a textbook and immersion (except for latin ;) ).

Re:The More they add, the less I like

[Anonymous Coward]

"Effectively when we write the HTML code by hand we're creating very lightweight pages. I set some colours and a simple background based upon a small sample and I'm good."

So your pages are designed for @media = screen and projection only? What about tty, handheld, print and tv media types that view your page? Here CSS comes in real handy.

Re:The More they add, the less I like

[porneL]

IE6/7 have all those weird box model problems with XHTML 1.0

No, IE can handle box model perfectly. It's XHTML it can't handle at all. You must be sending your pages as HTML (text/html) and you've put XML prolog in your HTML, which triggers quirks mode (you may think it's XHTML, but browsers see it as HTML with lots of syntax errors and bogus DOCTYPE).

obligatory hixie reference

Re:The More they add, the less I like

[cultrhetor]

Actually, you can just add a stylesheet that makes sure it renders correctly on PDAs. No need for switching:

<link rel="stylesheet" href="styles/standard.css" type="text/css" media="screen, projection" />
<link rel="stylesheet" href="styles/pda.css" type="text/css" media="handheld" />

Re:The More they add, the less I like

[fyngyrz]

It works on adults to.

...apparently not.

Re:The More they add, the less I like

[leoPetr]

Because HTML5 is intended to be backwards-compatible with HTML4 browsers, publishing the document in HTML5 is a way of sanity-checking that. The doctype is intentionally abbreviated -- it's long enough to trigger standards-mode (rather than quirks-mode) in all browsers.

Re:The More they add, the less I like

[psykocrime]

Pages are data, not programs? That's a fine attitude for plain text content sites. Not very good for web applications though.

Well, it can be argued that there shouldn't be any such thing as a "web application," at least as we know them today. Browsers and HTML are document / data centric concepts, and everything that's been done to shoe-horn applications into them is a hack. If you want to run *applications* remotely with the display exported to your local machine, there are protocols and software designed for that express purpose: the X-Window system comes to mind.

Re:The More they add, the less I like

[LouisZepher]

I personally do style my site with CSS, but I don't use techniques that completely over-ride the user's own settings. For example, for determining font size, I use the following:

body {font: 1em}

Then, for h1/h2/etc, footers, and any instance of larger/smaller text, I use percentages. (For example, I set h1 at 215%.) What this does is sets the default font size for the page at whatever the user has set as default in their browser. The percentages cascade from there. (h1 is 215% of the user's default font setting, a footer will be 85%.)

I believe that a web-author shouldn't feel restricted in terms of creativity, but at the same time, the author should never attempt to completely over-ride the visitor's preferences.

Re:The More they add, the less I like

[Bogtha]

To be honest I didn't read the spec (yet) but it appears the page is following HTML 4.01 strict but the doctype is incorrectly specified.

Well read the spec then. That's the HTML 5 doctype. The only reason they use a doctype at all is because otherwise it would trigger quirks mode.

Re:The More they add, the less I like

[Excors]

As it happens, that multipage version is one I hacked together yesterday, using the html5lib parser and an HTML5 innerHTML-like serialiser. The original and more-official version of the spec (from which the multipage one is derived) validates as HTML 4.01 Strict - the only problem is that it's quite large and makes browsers unhappy, hence the new multipage version.

(The multipage one does conform as HTML5 - but the conformance checker and the spec are still far from stable, so that doesn't mean a lot.)

Re:The More they add, the less I like

[CaptainPinko]

You realise your page isn't actually compliant? If you use FireFox I suggest you install the HTMLTidy plug-in and it'll point out the few bits you missed. Very nice work though on the HTML.

Re:The More they add, the less I like

[Bogtha]

If you are sticking to the HTML 3.2 standard you are doing exactly the opposite of what you state. Before CSS...

While it doesn't apply to the person you are responding to, it's perfectly possible to use CSS with HTML 3.2. In fact, you can use it with HTML 2.0. From the HTML 2.0 RFC:

The <LINK> element is typically used to indicate authorship, related indexes and glossaries, older or more recent versions, document hierarchy, associated resources such as style sheets, etc.

CSS might not have been invented when HTML 2.0 was around, but that doesn't mean they hadn't already come up with the way to associate stylesheets with HTML documents.

And as for "HTML doing things formerly reserved for Javascript", I literally have no idea what you're referring to.

I suspect he's talking about how you can do client-side validation declaratively with HTML 5 instead of writing JavaScript event handlers for form submit events.

Re:The More they add, the less I like

[LouisZepher]

Holy hell, not only is it ugly, but the marble image looks like he threw it together in two minutes using and older version of Bryce with only the included materials. I'm half surprised he didn't use the newbie "orb over water" image instead. Also, he's using frames, but, as you saw, every link opens a new window/tab. Someone hand this man a Guinness.

Re:The More they add, the less I like

[RalphSleigh]

Trying to read the menu at the side is giving me headaches...

Re:The More they add, the less I like

[dhalgren]

It's what you did during Stairway to Heaven in grade 10.

Unless you're a Slashdot regular, of course.

Torben

Re:The More they add, the less I like

[Theatetus]

Damn kids get off my lawn?

I've got to side with Osu-Neko above. The Web was much easier to use 10-12 years ago. Then marketing people got this burr up their ass about being able to control page layout like they could in print or video. It was beyond idiotic. You can't. You can try, and you can spend millions trying and end up eating the "extra" profit you imagine you'll make from a site that looks like a magazine or tv show, but ultimately you'll fail.

This has had the unintended (I assume) consequence of limiting Web page rendering to large standalone browser applications running on personal computers, when it is not intended to be limited to that. The reason nobody uses phones, or ttys, or clocks, or blah blah blah to read web pages is that these same marketing "geniuses" have been breaking the whole point of HTML in order to render exactly the way they want something to look on one particular type of standalone browser software on a personal computer.

In fairness, I like CSS: it's a good idea in principle. I haven't used a font tag or a table for element placement in years. But I also know what HTML is and what it's for: it's a way for me to present text (I stress text) along with some suggestions (I stress suggestions) as to how the client might best render them. I still do almost all placement by textual order (if I do placement by CSS, the order still has to be sensible). The only comments I get are, "wow, this site loads really fast".

Re:The More they add, the less I like

[NickFortune]

A perfect implementation of HTML wouldn't need javascript.

In much the same way as a perfect implementation of integer addition wouldn't need string manipulation. I mean it's absolutely, unarguably correct, and at the same time, utterly misses the point.

JavaScript and HTML do different things. Now if you want to argue that using javascript to implement mouseover effects is not a good idea, then fair enough. On the other hand, I don't want a specification for HTML that is Turing complete, either. Separation of concerns and all that.

Re:The More they add, the less I like

[eclectic4]

"this incessant pushing of the technology/standards envelope is creating a lot of disjoint, stilted, and otherwise unreadable web sites. etc..."

The technology standards didn't create those websites, the developers did. You seem to be asking to halt technological advancement to save developers from themselves, when it should be the other way around...

Re:The More they add, the less I like

[dugjohnson]

And I used to write code that ran in 640K....and we had to do support on 1200 baud modems....and we LIKED it.

Re:The More they add, the less I like

[PietjeJantje]

It's like watching people program without a care about optimizing for size or speed. They're paid by the hour, not for the quality of the code.
Oh yeah, fear the moment the mod_gzip'ed pages of text take away a fraction of the bandwidth you use to update your pr0n collection, which should not be slowed down!

Re:The More they add, the less I like

[Jugalator]

The More they add, the less I like

Hmm... They're actually deprecating a lot of things both in XHTML vs HTML, and cleaning things up further in HTML 5.

You make it sound like they only keep adding stuff. Little could be further from the truth. Actually, the HTML 3.2 standard -- now that's something that's messy, cluttering structural elements with visuals, for one thing.

Re:The More they add, the less I like

[StarkRG]

I design my pages using strict xhtml. It makes things easier to read and understand (assuming you've inserted new lines and tabs). There's never any kind of formatting using tags, only CSS. I even try not to use the style attribute. The only kind of formatting I use is the and tags, which are more descriptions than formatters (it's up to the browser or other display device to determine how to display something as emphasized or strong, perhaps they're both the same, perhaps they're different colors, perhaps they're different sizes, usually they're italic and bold, but that's not always the case, and you design knowing that).

The perfect design is one where there are no #ids or .classes in the css file. You can swap the css file with another generic one and the page gets rearranged and styled properly. The file should also be able to be read top to bottom with it still being understood (for screen readers, and audio browsers).

The perfect designer knows that what they're writing in the css file is only a guideline of what they'd like the browser to do, knowing full well that it's going to do whatever it wants. They code the html file so that, even if a browser doesn't understand css it'll still read fine. The information is the more important part of the page, not the layout.

Re:The More they add, the less I like

[StarkRG]

D'oh! I forgot that it reads tags as tags and doesn't display them verbatum, oops.

Re:The More they add, the less I like

[caudron]

There's no such thing as a "box model" in XHTML 1.0. The box model is a feature of CSS.

I agree with everything else you said, but have to defer to the other guy on this one.

CSS allows you to play with the box properties (like borders and padding and margins), but the box model is the direct result of the div structure of XHTML 1.*. I know why you say otherwise. Conventionally, when we talk about the box model, we are talking about CSS's use of it, but technically, convention is wrong, in that the box is defined in the XHTML rather than the CSS.

God. I am such a 'tard that I couldn't let this minor point go uncorrected. lol! Forgive my pedantry. ;-)

Tom Caudron
http://tom.digitalelite.com/

Re:The More they add, the less I like

[blincoln]

Ah, very interesting, thanks. I'm happy that the warnings it reports are minor and easy to fix. I actually hadn't bothered with any validation yet, just made the code look the way I'd want it to if I were reading it for the first time =).

Re:The More they add, the less I like

[try_anything]

To position his paragraphs one above the other, he puts the one he wants above before the one he wants below in the document, and separates them with <P>. He positions his images using the appropriate attributes.

I know this is picky, since you correct yourself later, but he doesn't position anything. No way, no how. If he's even thinking about positioning, then he's violating the spirit of semantic markup by thinking about a particular browser implementation instead of thinking of the whole range of devices that render HTML, some of which don't render it visually at all.

Re:The More they add, the less I like

[blincoln]

Great point. I knew that a few months ago, but had forgotten because I hadn't needed to make use of it.

Re:The More they add, the less I like

[Anonymous Brave Guy]

Your proposal is acceptable.

Re:The More they add, the less I like

[MP3Chuck]

If the user wants it to be up to themselves, they can disable external stylesheets and define their own. The whole point of semantic [X]HTML, with presentation broken out into CSS, is that the user can do that, if they so choose, and still have a functional document in front of them. The other 99.999% of Web users would likely perfer if they didn't have to do that.

Re:The More they add, the less I like

[ChameleonDave]

Le Français est une langue. That means "The Frenchman is a language". If you want to say "French is a language", you need to use a lower-case f.

Re:The More they add, the less I like

[BlueStraggler]

doing a decent layout with just HTML requires tables which in the end creates tag-soup because they weren't designed for page layout. CSS eliminates that problem.

Apparently you haven't actually tried to do real layout with CSS. There's only a small number of basic layouts that actually work, and even those may require ridiculous hacks that exploit browser bugs to hide rules from certain browsers, and use image backgrounds to create the appearance of cells. Google for 3-column page layouts to see the contortions you have to go through to make a basic 3-column layout with one liquid column. And that's a pretty damn trivial layout. Anything more complicated than that and you're in for a world of pain.

Small wonder then, that everyone seems to have standardized on 2- and 3-column presentation. It's pretty much the most you can do without a Ph.D. in web voodoo. But let's not pretend that this is a holy advance in the world of design. It's the opposite - a set of handcuffs for the designer, for the sake of getting one useful feature (namely, separation of content and design).

To be fair, I am referring to CSS as it has been implemented, not as it has been designed. There are a ton of fabulous CSS features that address all my complaints. It's just that none of them work out there in the real world.

Re:The More they add, the less I like

[mabhatter654]

and you wouldn't need Javascript at all.

Re:The More they add, the less I like

[nuzak]

> I mean, I go to a web site to find information I'm looking for. In the old days, you could do that

No you couldn't, because most of the time it wasn't there.

All some people can do is bitch. Go unplug.

Re:The More they add, the less I like

[mabhatter654]

what they need to do is to split documents from web applications. I remember in 95 Bill Gates thought the web was stupid because people should just use Windows GUI calls and make real apps instead. From the point of view of THIS article he was partly right.... partly.

The original purpose of HTML was "one document==one idea" policy. Each report would be a document, each birth record, each marriage record, etc. Browsers would just be used to flip the pages. The idea was to have the documents be as plain as possible with markup in text only so the data inside could always be accessed. In the 30 year view it was a great idea and in general it is starting to catch on at least at the govt level where there are now tens of thousands of important documents locked up inside computers that can't be easily read. But we can still get to text or stream files on decades old VAX machines...

Somewhere along the line documents weren't well formed enough to let the "browsers" speed read them, so people developed pages with lots of links to be used as tables of contents... then manual maintenance got to be a bitch so they automated the tasks with scripts. It was easy because the script just had to return a valid page file and any browser could read it!! But that's not what it's meant for. Tim is spinning right now because data is locked up in private towers instead of free and flat like a library. For example WikiPedia is great, but it should be individual files and OUR BROWSERS should be smarter and scanning the archive rather than being database records fed by a script one at a time. It's that philosophical difference that the W3C can't get over.. or at least not soon enough. Google is a closer tool to what he envisioned, but even then it should be OUR PERSONAL machines doing the scanning, not a corporate one. Pretty formating is way down the list of priorities in his model.

In the meantime the free market has spoken and they want the web as applications to private databases, not collections of documents. Personally, I think a split is in order. XHTML should be grounded to version 1.0 strict and used in the manner intended, as archives of individual documents. What's needed is a NEW model for Web Applications that is built to tie to databases from the ground up. Actually, how people write and use web scripts like PHP or RoR is very similar to how RPG works on AS400's (and you though those were old fashioned!)... spookily so. The one thing no web companies want is to get proprietary lock-in again... so that makes the easy things like .net or Java or X sessions out, even though those were built for exactly how people make web apps! So step back and look at how AS400's use the standard telnet stream to piggy back all sorts of extra data. The reason I keep brining that up is that IBM also built in session data, determinism, and encryption right into specs... those are the key hang-ups of most web apps.. a particular downfall of PHP to handle the security issues of making it up from scratch well. Mozilla firefox is already working on remote session support. What's really needed is to create a new internet type rather than bolting on to HTTP. perhaps web:// the server apps can be cleaned up to send streams that are managed for security, state, sessions rather than "pages" all the cool bits used for Ajax and such can be built right in at the browser level. At that point browsers will also be able to talk BACK because the data both ways will be defined and we'll have really cool stuff. But in doing that it will be more locked in, less free but as long as we keep Microsoft and Adobe far away from it, it should be OK.

Re:The More they add, the less I like

[nuzak]

HTML was not intended for complicated magazine layouts.

What's your grand vision of what HTML was intended for? Oh yeah, "information", because aesthetics are fundamentally immoral.

Here's mine: if it has a MIME type and a visual representation, the web should be able to show it, with any variant that type allows and any position the container can handle. Yes, do go on and decry the anarchic ruin such flexibility will bring. The rest of us will use it.

Re:The More they add, the less I like

[mabhatter654]

I'd agree that HTML and XML was not designed for applications... BUT that ship has sailed, no point in arguing about it now.

That said even Bill Gates suggested directly mapping windows Apis to the browser in 95... OF COURSE nobody wants that because it would tie you into somebody else's software all the time. The web works because it is mostly OS/browser agnostic. I think it's time for a web application URL... say web://web.slashdot.com for example... keep both the protocol and default server name the same.. (or maybe watp:// for web application terminal protocol) the whole http/www thing is silly to repeat if you don't have to. This would be for just web apps. It would look like XHTML and have CSS and such but it would have things like state, sessions, security built right in. It would sacrifice a lot of privacy on your part because you would be actually running an app.. not pretending to pull a page, but it would make development much simpler.

Re:The More they add, the less I like

[Tablizer]

Like C-style brackets, eh? Now we'll have all the "lost nesting" headaches it gives.

Re:The More they add, the less I like

[koreaman]

<français>> est un mot sans majuscule. Sauf bien sûr si l'on parle d'un Français, un habitant de la France.

Re:The More they add, the less I like

[EsbenMoseHansen]

Ehm. You do know it was a joke? Hence the ";)" at the end :)

Anyway, the grandparent forswore stylesheets, too (they were too complicated, I think)

Re:The More they add, the less I like

[partenon]

-1 Wrong. We are talking about HTML 3.2 here.

Re:The More they add, the less I like

[Bogtha]

What this does is sets the default font size for the page at whatever the user has set as default in their browser.

This code is actually useless by definition. You don't have to set the default to be the default because it's the default. The definition of 1em is the same size as the parent element, and the font-size property is inherited by default, so specifying "1em" for the font size is unnecessary unless you are overriding another rule.

Re:The More they add, the less I like

[Bogtha]

Actually, you are reinventing the wheel. That shortcut syntax is part of HTML. I don't think any browser ever implemented it though.

Re:The More they add, the less I like

[Bogtha]

the box model is the direct result of the div structure of XHTML 1

Er, "the div structure"? There is nothing special about the <div> element type whatsoever. It's just like any other element type. Sure, a lot of newbie web developers seem to think that <div>s are a type of layout scheme, but it's really just a general-purpose block-level element type.

I know why you say otherwise. Conventionally, when we talk about the box model, we are talking about CSS's use of it, but technically, convention is wrong, in that the box is defined in the XHTML rather than the CSS.

You're close, but not quite there.

XHTML doesn't involve itself with layout, and doesn't define any kind of box model. If you disagree, go read the specs.

CSS defines the box model. According to the CSS specifications, elements from the source document may generate boxes.

So that's where you got the idea that the box model comes from XHTML. But as you can see, it's not the XHTML specification that defines the box model, it's the CSS that describes the box model and where to get the boxes from.

Now you can argue that a particular XHTML document defines some of the boxes in a particular rendering, but the boxes themselves and the box model are two separate things. The box model is the way it all works. The boxes are artifacts of a particular document that has been rendered according to the box model.

Re:The More they add, the less I like

[8-bitDesigner]

Bah, it gets easier the more often you do it. Two and three column layouts are quite trivial at this point in the game (google "Opposed Floats"), and you can really get creative with absolute positioning to eschew the whole "column" thing if that's not your bag.

Honestly, the last site I built was pretty straightforward CSS-wise, and worked in IE6, Firefox, and Safari without hacks. Well, slight lie, as IE6 needed three lines of CSS to bring it into line, but that's only because it chokes in 'min-height'.

Otherwise, like with any moderately difficult persuit, practice helps.

Re:The More they add, the less I like

[LouisZepher]

True, but unless I've seen instances where my CSS wouldn't validate otherwise.

Re:The More they add, the less I like

[Christianfreak]

Actually I own a web company and we do all our layouts with CSS only ... thanks for playing. But hey if enough people think it can't be done they'll keep paying people like me to do it :)

I'm really not sure what your argument is ... that CSS becomes tag soup as well or that tables are better for layout in general because you can do things other than columns? I hope its the former .. though I would argue if your CSS becomes tag soup then you aren't doing it right.

If you're arguing that tables are better then it simply makes no sense. All you get with tables is columns and rows, which seems worse since even if your assertion about CSS were true, you still don't get the separation of content and presentation.

Re:The More they add, the less I like

[BlueStraggler]

Actually I own a web company and we do all our layouts with CSS only ... thanks for playing. But hey if enough people think it can't be done they'll keep paying people like me to do it :)
I'm really not sure what your argument is ...

The argument is that if you do all your layouts with CSS, you aren't doing much in the way of layout. That's been my experience in my own web company. Don't get me wrong, I use CSS-based layout all the time, but that means I'm running into its limitations all the time, and when that happens, there's usually a simpler HTML solution than trying to find a cross-browser, javascript-free CSS solution.

If you're arguing that tables are better then it simply makes no sense. All you get with tables is columns and rows, which seems worse since even if your assertion about CSS were true, you still don't get the separation of content and presentation.

It's not that tables are better, just that there are a handful of layout problems that are WAY easier to solve using tables than CSS, but you pay the price of mashing up your content and design. A few examples:

• a multi-column layout with more than one liquid column
• a multi-column layout with bordered columns
• any multi-cell layout that doesn't involve absolute positioning
• any multi-cell layout that needs to be maintained by non-experts (eg. anything in a user-friendly CMS)

Lastly, the problem of mashing up your content and presentation is increasingly irrelevant, because CMS systems keep them separated far better than CSS does. CSS doesn't really give true separation of content and design, because you have to mark-up everything in wrapper DIVs to signal the stylesheet what rules to apply. Sure, the mark-up is minimalist, but it's still there, and content maintainers still have to be aware of it in order to have things formatted properly. However, if you use a decent CMS, the contents of the DIVs can be completely separated from the DIVs themselves using some kind of templating scheme, eg.

<div id="foo">
$foo_html
</div>

If you're doing something like this, then CSS is somewhat irrelevant, since your content and presentation are fully separated to a degree that CSS can only dream of. $foo might not even be HTML; it might be passed through a filter first before being inlined into the template, in which case the content maintainers work with it in a native format. In this case, CSS not a content-separation tool, but merely an optimization to reduce page bloat by using cacheable stylesheets. This frees you up to use tables or whatever else gets the job done most efficiently. When you require new presentation, you simply point your content at a new template, rather than pointing it at a new stylesheet. Since the new template also includes new stylesheets, this approach solves a superset of problems that CSS alone does.

How will this effect IE7

[jhfry]

I don't see Microsoft on the list of those pushing for it. Any chance that HTML5 is compatible with IE7... or should I say, is IE7 compatible with HTML5... Hell, is IE7 compatible with any web standard?

Re:How will this effect IE7

[aicrules]

No one is compatible with HTML5.

Re:How will this effect IE7

[Anonymous Coward]

Chris Wilson of Microsoft's IE team is one of the co-chairs of the HTML WG. The work of the WHATWG however has been created without any input from MS. It remains to be seen whether or not MS will adopt everything. There are also internal quarrels among the other three, read the public-html list archives to find out.

Re:How will this effect IE7

[jimbojw]

> No one is compatible with HTML5.

Yeah, that's true - right now. If HTML5 became a W3C endorsed standard, you can bet that Firefox, Safari and Opera would pick it up quickly - especially anything based on Gecko. OTOH, any bets on whether IE7 would support it ... ever?

Re:How will this effect IE7

[brunascle]

considering IE7 doesnt even support XHTML yet, i wouldnt hold your breath.

Re:How will this effect IE7

[maxwell demon]

OTOH, any bets on whether IE7 would support it ... ever?

No. IE7 is already out now, and MS would be silly to give the next version the same version number as the current version.

Re:How will this effect IE7

[jimbojw]

Good point - I should have said IE 7.x

Re:How will this effect IE7

[freeweed]

And IE7's not compatible with anything - it all works out in the end.

Thanks, folks, I'll be here all night! Check out our loose slots!

Re:How will this effect IE7

[wootest]

Point versions would be a silly place to start supporting a major new standard. Usually it takes two or three versions to approach what could be called reasonably full compliance, depending on how 'major version' hungry you are (Mozilla Suite - by that name, yes, I know Seamonkey exists - was abandoned around 1.7 or 1.8).

Re:How will this effect IE7

[jimbojw]

Point versions would be a silly place to start supporting a major new standard.

Maybe - but it's even sillier to make any sort of realistic reference to the available features in IE8.

Re:How will this effect IE7

[wootest]

Saying "IE8 is more likely to introduce HTML5 support than is any point release of IE7" sounds like it makes sense.

And meanwhile in IE Land...

[CastrTroy]

And meanwhile in IE Land, we're still trying to get proper CSS Support. It will always come down to the lowest common denominator, especially when the LCD is the most popular browser. Nobody is going to code HTML 5 pages when the most popular browser doesn't support them. It's great that MS has finally made some headway with IE 7, but if they wait another 5 years until their next major release, then they are going to be even further behind. While all the other browsers are working on CSS3 and HTML5, MS is still working on CSS2 and HTML4.

Re:And meanwhile in IE Land...

[nine-times]

If Microsoft can't keep up with Mozilla, Opera, and Apple, then they'll just lose the "browser wars". It's not as though there aren't alternatives, so consumers will be fine.

Re:And meanwhile in IE Land...

[Jeff Fohl]

Yes, Microsoft is definitely the ball and chain that holds progress back - but at least they have joined the HTML Working Group.

Re:And meanwhile in IE Land...

[sconeu]

Oh great, so now we'll have tags that say "Work like IE4".

Re:And meanwhile in IE Land...

[Excors]

A fundamental design principle of HTML5 is that HTML5 pages should work in existing browsers like IE6. You can write <input type="email">, and an HTML5 browser will allow useful auto-filling and immediate validation feedback, while old browsers will simply show a text box. New elements like <video> can have fallback content, e.g. to embed a Flash video player. New elements like <canvas> can be partially implemented by JavaScript in IE6. The HTML5 doctype (<!DOCTYPE HTML>) is chosen so that it triggers standards mode (as opposed to quirks mode) in all existing browsers.

So, you can write in HTML5 to provide added benefits for users of browsers that understand HTML5, while still being no worse than before for users of older browsers. And given that IE development has started up again, with IE7 making some progress on CSS standards compliance, and given that Microsoft is a member of the W3C's HTML working group which will almost certainly accept the current HTML5 work (as it was the reason for the working group to be formed, and nobody has raised any serious objections since it was proposed), I believe there is reason to be hopeful.

Re:And meanwhile in IE Land...

[Excors]

HTML4 says the default value for input's type is "text". Since HTML4 browsers don't recognise "email", they use the default instead, which gives a plain text box. (HTML4 is generally under-specified, so it doesn't actually say what should happen when a unrecognised value is given, but everybody implements it in the same way.)

You'll always have to do server-side validation – but users will have a nicer experience if errors are immediately flagged in a standard way by their web browser, rather than having to go through a slow round-trip to the server before being told they made a mistake. The browser can also provide some UI to let people quickly enter their own email address into the box, or to copy one from their address book.

The Good News

[Philomathie]

This can really only be seen as a good thing - although we may have to relearn large parts of HTML (or XHTML), it is a relatively simple language and the tradeoffs in browser compatability and interoperability we can get would be staggering, no more pages that are designed to work just in IE, and we could be sure that a web page would look the same in all modern browsers - no more testing them individually and tweaking code until it looks "acceptable" in all of them. Is is quite possible that this new standard could also decrease the bandwidth required by the HTTP protocol throughout the internet's 'pipes', which gives us more space for those darned torrents!

Re:The Good News

[JordanL]

Moving away from pages that "only work in IE" would take a lot more than HTML5. Microsoft made IE the engine for displaying all system windows in their OS... when you browse my computer, what more or less happens is Windows generates an HTML DOM object to display the contents.

This is the reason Microsoft has had so much trouble with standards and the reason they will never be able to fully support standards as long as IE is integrated in Windows to the level it is. Standardizing would leave the OS itself high-and-dry, which is something Microsoft is not willing to do.

This was part of the reason Netscape sued them, and it was part of their anti-trust suit here in the US. Everyone knows this was done almost for the sole purpose of using MS controlled platforms (IE) to prevent non-MS controlled platforms (the web) from abstracting out all the functions a user needs. Most people still think the internet doesn't work on Linux, or that Linux has a "different internet" of its own. I would venture to say that their anti-competative practices with IE are the ONLY reason they still command the market share they do.

Talking to Microsoft before formalizing a web standard is like going to them for an open document format: you just end up knee deep in shit that Microsoft doesn't genuinely believe in the first place.

I started to

[caluml]

I started to code my pages in XHTML. But it's just not worth it. Use what works. :)

Re:I started to

[jd]

We need to replace the blink tag with a more general annoy tag that can have blink attributes. This will allow W3C to properly codify all the ways of being a complete pain under a single, unified system.

Re:I started to

[pkulak]

Yeah, well, it's also never actually worth it.

Re:I started to

[Yvan256]

May I suggest the tag?

Re:I started to

[StonedRat]

Blink is already supported by the W3C in CSS:

text-decoration: blink;

http://www.w3.org/TR/REC-CSS2/text.html#lining-str iking-props

5???

[aicrules]

I just figured out HTML1 and I am still crying that doesn't work! :~(

Re:5???

[metamatic]

Actually, HTML 1.0 was much closer to HTML 4.0 than HTML 3.2 was. HTML 1 and 2 were modeled on SGML, whereas HTML 3.2 was rubber stamping the garbage invented by Netscape.

Update CSS not XHTML/HTML

[oliverthered]

What we need is an updated version of CSS that lets you do things like reference other elements attributes so that you can create tables and line up things across/down the page. The ability to put different images on the left and right hand sides and top and bottom and all variants off would be great for putting rounded corners on things etc... instead of having to do hacks link putting in extra p tags just for the image.

HTML is more or less fine, give me a better version of CSS anyday.

Re:Update CSS not XHTML/HTML

[drinkypoo]

IMO what we really need in CSS is variables and math. Variables are really key. And to be able to say that the width of an element is n% of the width of another element, even when it is not nested within that elements, is also key - otherwise you have to use javascript for assloads of things. Of course other similar things would be possible. This is absolutely critical. Without it CSS makes life harder in a disturbing number of situations.

Re:Update CSS not XHTML/HTML

[CastrTroy]

I think variables (and math) would be the thing that would really make CSS Complete. There's so many times where I've wanted to make something the same width or half as wide as something else that I have lost count. Currently, you can do a couple tricks, like setting fonts to 150%, and they will be 1.5 times larger than the rest of the document, but I really would like full math and variable abilities.

Re:Update CSS not XHTML/HTML

[richdun]

Some of that is in the CSS3 and further specs, like the advanced layout module, but those are beyond the reach of even the latest versions of FF, Opera, KHTML, etc. at the moment.

But, really, XHTML 1.1 is a great standard, and instead of moving ahead, let's try to get everyone to use it first. It hasn't been updated in forever (forever in web terms, of course) because the push has been to get everyone to actually use standards, and to get browser support of CSS2 and eventually CSS3 complete across all platforms and engines.

Just glancing over it, the HTML5 standards up at WHATWG worry me slightly. There seems to be a lot fo presentational/non-structural markup sneaking back in. Not necessarily as obvious as some of the older tags that were dropped in HTML4/XHTML1, but still. We have to keep in mind the separation of powers - XHTML/HTML for markup, CSS for presentation, and DOM for scripting - or things will just get way too complicated again.

Make things easier and more accessible for the developer/design? Sure. Add presentational content to HTML so he/she doesn't have to learn how to properly use CSS and the DOM? No. Do this, and it'll open the floodgates for everyone (MSFT) to add "special" tags to further "help" the developer/designers. Next think you know we'll be running around with a bunch of "Works best in ..." graphics like its 1998 again (only this time we'll be using PNGs or JPEG2000s instead of GIFs).

Re:Update CSS not XHTML/HTML

[Blakey Rat]

I've love to be able to do simple math in CSS. I should be able to set an attribute to 1em + 5px, but right now you can't. Your idea about giving CSS references to attributes that you could refer back to in other attributes is good, also.

Re:Update CSS not XHTML/HTML

[TheRaven64]

I'd also like to see something like XSLT supported better. I hate having to put lots of class="foo" attributes in. Just let me define new tags and have the browser translate them into something sensible with a simple mapping. It would reduce bloat a huge amount.

Re:Update CSS not XHTML/HTML

[partenon]

Please, no. What kind of math do you want in CSS? And as for variables, I would suggest something like "style sets". They may seem like variables, but variables are way too powerful for CSS, which is *not* a programming language. By "style sets" I mean: "$defaultBg {color: white; background-color: black;}" or something like that.

I think a good point to understand *why* CSS don't have math, variables and alikes is the HowCome's (Haakon) interview here on /.

Re:Update CSS not XHTML/HTML

[gaspyy]

In IE6 and later , you can mix CSS and javascript. I know, I know, IE is 'teh EViL' but the idea is pretty cool.
I've written about it on my blog, the idea is that you can write

#mydiv {
      width:expression( ... )
}

and it'll work.

Sometimes the layout can be very complex (especially with fluid layouts) and you need to mix relative dimensions (%) with fixed ones (px or em) so the more tools one can use, the better.

Re:Update CSS not XHTML/HTML

[richdun]

That would also be great. XSLT really has the potential to take presentation beyond the web that CSS just isn't built to do. CSS is good for now, but the future should look much more like XSLT. I'd love to be able to markup a document, then build one XSLT for a web page, one for a printed document, etc.

But then again, the only major site I've seen using XSLT is www.worldofwarcraft.com (and perhaps the rest of Blizzard's sites, but haven't really poked around them much in a while). Remember, it took Wired and others switching over to pure CSS to get everyone's attention. More major sites using XSLT would go a long long way.

Re:Update CSS not XHTML/HTML

[drinkypoo]

Please, no. What kind of math do you want in CSS?

I want the four basic mathematic functions.

I don't necessarily need variables but I need to be able to refer to other elements' properties. Namely, if I could say that:

div.class2 { width = ( div.class1{width} / 2 ) }

That sort of thing would solve immense numbers of problems not just for me, but for zillions of others. It would eliminate the necessity to use javascript to accomplish very simple and obvious formatting routines.

Another severely needed item is the ability to count elements. If I have an 800 pixel wide space, and I have three elements, those elements will need a different width (regardless of whether I handle things through percentage or absolute width in pixels, which will in turn depend on whether I'm doing a fixed or liquid layout) depending on the number of elements. I'm not sure at all what that syntax would look like, but it eliminates the need to use javascript, which is my goal here.

I think a good point to understand *why* CSS don't have math, variables and alikes is the HowCome's (Haakon) interview here on /.

Well, I read it. There was very little applicable material there. There are short blurbs like "For CSS1, the downsides of aliases were considered more significant than the benefits." (I'm not talking about aliases - you are.) So that doesn't even begin to address my comment. But thanks for playing!

The simple fact is that there is currently no way but the use of Javascript to set one element to a width based on the width of another element. Your argument would appear to be that adding complexity to CSS would lead to additional complexity. That's true, but what it ends up leading to is added complexity both of the page and the browser, because you are literally forced into stupid Javascript DOM hacks.

Re:Update CSS not XHTML/HTML

[richdun]

Sorry for the double-reply - hit Submit before the thought completed in my head.

Advanced selector support in CSS3 could also help with reducing the need for tons of classes and such. But that's also an implementation issue - Safari is pretty good, Mozilla and Opera are getting better, but even IE7 doesn't support all the CSS2 selectors, let alone the CSS3 ones.

For those not familiar, I'd encourage checking out the full list of selectors - especially the nth-child and attribute ones, which could make a huge difference for paragraph spacing, drop caps, and, most commonly, the "zebra striping" in data tables, forums, email apps, etc. Check out Andy Clarke's Transcending CSS (http://www.transcendingcss.com/) for a really great look at advanced CSS3 features that will make you hate browser manufacturers even more and make you wish all these things were actually usable in today's web.

Re:Update CSS not XHTML/HTML

[Chysn]

> And to be able to say that the width of an element is n% of the width of another element, > even when it is not nested within that elements, is also key #left { height: (#right.height) + 50; } #right { height: (#left.height) + 50; } Yeah, good times!

Re:Update CSS not XHTML/HTML

[oyenstikker]

XSLT and CSS server different purposes. You use XSLT to get from your own XML format to HTML, and the HTML links a CSS stylesheet. How exactly do you propose that XSLT takes over CSS's job? Do you want to put all the presentation control back into HTML?

Re:Update CSS not XHTML/HTML

[wootest]

I agree. This would be tremendously useful and even enable the true kind of table-like column layouts we've been wanting (not just text flowing into other boxes like CSS3 columns). Something like:

#column1 { /* Assume this exists */ }
/* Assume a function, of, that takes two arguments, the name of the property and the selector, and another function, own, that takes the name of the property and works on its own rule. */
#column2 {
width: (of(width, body) - of(width, #column1) - (own(padding)*2));
height: of(height, #column1);
padding: 0.5em;
}

Re:Update CSS not XHTML/HTML

[eugene ts wong]

I agree. I wish that they would finish CSS 2.*. They haven't even managed to get it to render correctly for print layout, and they are already trying something else? In fact, they haven't even finished HTML 4.01. The tables don't render correctly, when colspan=0 or rowspan=0.

Re:Update CSS not XHTML/HTML

[WebCowboy]

What we need is an updated version of CSS

What we REALLY need is updated versions of BROWSERS (especially IE--even v7 is out of date in terms of compliance). We don't need CSS4 or HTML5 or XHTML2...browsers still have a hard time with CSS2, HTML4.x/XHTML1.x!

do things like reference other elements attributes so that you can create tables and line up things across/down the page.

Does not CSS3--a current standard with which nobody yet complies--provide means for columnar layouts? Also, last time I checked the latest HTML/XHTML specs supported table, tr, th, td etc...and none of it is deprecated...and even CSS2 has tabular layout stuff. It drives me up the wall when I see something like a calendar or other tabular information marked up with silly CSS an div and span tags all over the place. The thing is, if it is "semantically" a table, you should USE an (x)html table! Not only is the CSS simpler, the actual content (in terms of (x)html source) makes more sense to parsers and humans.

OTOH, is you want columnar layout for non-tabular data (news sites, discussion forums) then stop using tables already! It isn't all web developers' faults...the biggest problem is that the lack of support for CSS3 and the difficulty in doing such layouts in older versions of CSS is reinforcing bad behaviour (however, there is NO excuse for marking up lists with divs and spans--another annoyance to me. The ol, ul and li tags are there and CSS supports formatting these elements quite well).

HTML is more or less fine, give me a better version of CSS anyday.

I mostly agree if you mean strict XHTML, though CSS3 is a big improvement as well and what we need is better CSS SUPPORT. A few things I'd more like to see to make the WWW a better place:

* better native support for SVG in browsers...if you want rounded corners and other spiffy presentational elements THAT is probably the most appropriate place for it to be done.

* if (x)html is to be messed with lets look at how forms are handled...we could do with something that is more "evolutionary" than what W3C has been mulling perhaps.

* the standard that needs the most work is Javascript/ECMAscript...the xmlhttprequest object is not implemented as a standard and there is no standard proposed for it. Instead we have a proposed standard for similar functionality by the W3C (DOM level 3 "load and save") that is more cumbersome and nothing like the "de-facto standard". This "real" standard (DOM3LS) thus far is only supported in Opera IIRC, and the Mozilla team really pushes back when asked to work on such support. People, pick something and get it working the same in all browsers..this is what holds back "web 2.0" the most IMO!

Re:Update CSS not XHTML/HTML

[FooBarWidget]

The only reason why I don't actively use XHTML (and instead use HTML 4 strict) is because Internet Explorer doesn't correctly support it. It renders XHTML as HTML 4 *transitional*, which activates IE's broken 'compatibility' box model. And IE doesn't support the XHTML MIME type.

The past new years I've noticed that the browser world has become IE versus "the rest". Firefox, Opera and Konqueror seem to render everything nearly identically. 95% of the rendering problems during website development seem to come from IE, and IE only.

Re:Update CSS not XHTML/HTML

[belg4mit]

That might be nice, but I think a more fundamental ability would be to be able to refer to the values of other properties:

    blarg { wuz: 9em }
      . . .
    mangle{ yoz: blarg.wuz }

And no

    blarg, mangle { wuz: 9em }

is not a solution as it's not dynamic. Nor should one need to revert to JavaScript for such simple dynamicity.

Re:Update CSS not XHTML/HTML

[korisu]

Please don't do this. Please please please, for the love of god, don't do this. Why? The content inside the expression() tag is evaluate upon every (yes, every) window event that could possibly alter the value of the content. Load? Evaluate. Resize? Re-evaluate. Click? Re-evaluate. Mouseover? Re-evaluate. I've seen a single window, consisting of nothing but a dynamically sized popup menu using an expression() on each element, balloon from 100MB usage to over 400MB memory usage (and lock up the system), simply from grabbing a border of the window and shaking it around a few times. Expressions and behaviors in CSS are bad. If the CSS box model doesn't work for you, or if you want the sizes tied to an event, then tie them to the damn event already. Using Javascript.

Re:Update CSS not XHTML/HTML

[korisu]

Although getting this implemented would be a nightmare, I would think that XSLT's approach to variables (declarative rather than imperative - you can't set a variable's value twice) would be feasible in CSS. But then again, one could argue that you should just use XSLT for your layout logic in the first place. :P

Re:Update CSS not XHTML/HTML

[richdun]

I hadn't really poked around the WoW site source too much, but was more just impressed that someone actually used the technology (whether it was done well or not). Bad practice is never something you want to see, but any try will at least get it out there in the open so we can evaluate whether it's a good idea or not. I did have some trouble with it in FF 1.6 when they first launched it, but have been using Safari and FF2 so I'm not sure if they ever fixed that.

And I've used CSS for, but am not nearly as big a fan of it as I am CSS for the web. I was thinking that maybe using an XSLT to put something in MS Office XML or other XML document formats to not only print, but to eliminate the need for all those goofy "Export to ..." APIs out there.

Re:Update CSS not XHTML/HTML

[Bogtha]

Does not CSS3--a current standard with which nobody yet complies--provide means for columnar layouts?

Actually, CSS 2 does. But Internet Explorer doesn't implement that bit of CSS 2, despite the spec turning nine years old this year.

the xmlhttprequest object is not implemented as a standard and there is no standard proposed for it.

Yes there is.

Instead we have a proposed standard for similar functionality by the W3C (DOM level 3 "load and save")

Actually, that became a Recommendation just over three years ago. There's nothing "proposed" about it.

This "real" standard (DOM3LS) thus far is only supported in Opera IIRC, and the Mozilla team really pushes back when asked to work on such support.

I remember trying out DOM3LS a couple of years ago, and Opera, Mozilla and Konqueror all supported the draft specification.

This could be the leverage needed against MS

[erroneus]

The biggest problem/complaint against Microsoft is that their dominance is hurting standards. Perhaps to some degree, the standards body could come up with a way to force Microsoft into being compliant and compatible? Perhaps there should be a level of completeness of implementation that would be required before being approved as "HTML5" compliant or compatible?

We know Microsoft is capable but they just don't want to. Their weight and sloth is an abuse to the community at large.

Re:This could be the leverage needed against MS

[140Mandak262Jamuna]

Microsoft does not care for standards, nor does it want true interoperability or compatibility with any software not made in Redmond. As long as users are apathetic they will be under no pressure to change. Free markets will work only when a large portion of the users act rationally. Locking up all your data in a format and making all your processes depend on a single vendor's API are not very rational decisions. So, yes, MSFT will thumb its nose at any proposed standard. Muddy the issue by saying users should have "choice". Yeah, sure I want multiple choices in the kind of wall outlets I plug my appliances into. Round pin, flat pin, three pin, two pin polarized US style, UK style, Singapore style? Pay some consultants to come up things like "Total Cost of Ownership" etc. But dont blame MSFT. Educate the users.

Re:This could be the leverage needed against MS

[Aldur42]

Unfortunately, there is no way a standards organization can force Microsoft into doing anything. Microsoft's bloat and lack of agility has made accepting any change very expensive for them. There going to fight these standards or implement them half assed. The more ubiquitous the web becomes the less relevant their large proprietary operating systems become. Vast improvements in Firefox and opera's market share is the only way Microsoft will adopt any web standards.

Re:This could be the leverage needed against MS

[gstoddart]

Perhaps to some degree, the standards body could come up with a way to force Microsoft into being compliant and compatible?

Entire governments can't convince Microsoft to provide the documentation so someone else can make things interoperate.

How the hell do you think a friggin' standards body is going to force Microsoft to make things compliant and compatible? Microsoft's relationship with standards bodies has been to stick around long enough to find out what it's supposed to do, release a proprietary version which specifically isn't compatible, and then lament that the rest of the world isn't using their perfectly good (closed, licensable, not for FOSS) mechanism.

It is simply not in their interests (or, means I believe) to adhere to open standards. Their development cycles have always meant they need to start before the standard is even finished; that allows them to get a product out the door, and, most importantly, they get to effectively become the de-facto standard for business. Then, any products which come down the pipe later aren't compatible with the Microsoft ones, and don't get accepted.

Microsoft has been refusing to adhere to any standard for a very long time. They're not about to start now.

Cheers

Re:This could be the leverage needed against MS

[Blakey Rat]

It certainly doesn't help that, in this case, the standards absolutely suck. It's hard to convince anybody to use standards when the 'standard' version of the page doesn't let you do simple things you want to do without tons of workarounds and nasty hacks. Like center an image vertically. Or anything related to AJAX.

Re:This could be the leverage needed against MS

[starwed]

I'm sure it will ease your mind to know that the chair of the working group works for MS... :P

Re:This could be the leverage needed against MS

[AthenianGadfly]

If I were a chair, I would not want to work at Microsoft...

It could be dangerous

Opera

[RonnyJ]

Speaking of Opera, version 9.2 was released yesterday, but doesn't seem to have warranted a headline here as of yet.

http://www.opera.com/download/

Talk about spin!

[Bogtha]

"The World Wide Web Consortium (W3C) has been slumbering the past several years

No, the W3C have been very busy.

XHTML was last updated in 2002

No, XHTML was last updated two months ago.

no one is taking seriously their largely incompatible work on 'next-generation' XHTML or 'modularized' XHTML.

Everybody is ignoring XHTML 2.0 because it isn't finished yet. XHTML 1.1 is not an option for most developers for one reason in particular: you can't use it with Internet Explorer. Blame Microsoft.

Both HTML and XHTML are in sorry need of removing deprecated items

No, both HTML 4.01 Strict and XHTML 1.0 Strict are available for those people who wish to use a document type that doesn't include the deprecated stuff. And even if they weren't available, nobody needs deprecated items to be removed. If you don't want them, don't use them. Just because they appear in a specification it doesn't mean you are forced to use them.

The quality of this work has reached the point that Apple, Opera, and Mozilla have requested the adoption of HTML5 as the new 'W3C Recommendation' for Web development.

No, they are requesting that the W3C — the organisation you've just written off as closed and useless — adopt their work as a starting point, so that it can be developed further at the W3C. They aren't asking that the W3C give it Recommendation status, they are asking the W3C to take over its development.

Re:Talk about spin!

[Anonymous Coward]

Everybody is ignoring XHTML 2.0 because it isn't finished yet.

I thought it was because it was a pointless and unneeded reformulation of existing standards with no BC?

XHTML 1.1 is not an option for most developers for one reason in particular: you can't use it with Internet Explorer. Blame Microsoft.

1.1 is not an option if you want to support UA's that only accept text/html and Lynx will never support application/xhtml+xml. All XHTML1.1 does is modularize version 1.0, most users probably don't even know what that means ;-o

Re:Talk about spin!

[Bogtha]

I thought it was because it was a pointless and unneeded reformulation of existing standards with no BC?

You're welcome to that opinion, but I think the fact that it's a work-in-progress is the relevant factor to consider when wondering why people aren't using it. Even the W3C themselves don't want anybody to use it yet. In their own words, from the top of the latest specification: "It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever."

Lynx will never support application/xhtml+xml

Lynx already supports application/xhtml+xml. According to the changelog, support was added almost three years ago.

Re:Talk about spin!

[Dionysos Taltos]

I concur. If you read through the thread, you'll see this ...

On Mon 4/9/2007 10:38 PM Maciej Stachowiak wrote:

>Dear HTML Working Group,

>[three hyphen-delimited proposals; one auxilliary proposal]

I guess since much of this is already on the co-chair's agenda: http://www.w3.org/html/wg/il16 (item #2) , I would, from a procedural point of view, have preferred the question to have been called by one of the chairs. It would lend an air of formality to whatever discussion ensues.

regards, David Dailey

Re:Talk about spin!

[Excors]

I think the fact that it's a work-in-progress is the relevant factor to consider when wondering why people aren't using it.

That's not a relevant factor for the Safari developers to say "the HTML standards process has been moribund; the W3C's HTML Working Group has focused almost exclusively on XHTML2, a new standard that was highly incompatible with existing practice" and "We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web". As far as I am aware, Mozilla, Opera and Microsoft are all not planning to ever implement XHTML2, whereas they are already working on HTML5 – HTML5 also has many features that are work-in-progress and which nobody is using yet, but which the browser vendors are already implementing, because they are valuable changes and don't break compatibility with the current hundred billion documents on the web.

Re:Talk about spin!

[BenoitRen]

Have you taken a look at the XHTML 2.0 spec yet? It doesn't make sense. For one thing, a href attribute on every tag? WTF?!

Re:microsoft?

[peragrin]

Since when has MSFT done anything to standard? MSFT didn't like javascript so they made ActiveX. MSFT couldn't corrupt Java(though they did try and got sued) So they made .NET. IE7 doesn't support existing standards why should the rest of the industry wait for MSFT.

IE7 is a lot better than IE6. Fact is if MSFT doesn't make the "standard" MSFT won't support it properly.

Misses the point

[starwed]

The article misses a pretty large point: the w3 has already decided to work on the next version of HTML. The post linked to is a recommendation that the HTML 5 spec be used as a starting point for that work.

Firefox plugin

[alienmole]

What we need is a Firefox plugin for IE. Someone get on that, please.

Re:Firefox plugin

[TheRaven64]

There is a Gecko ActiveX control. It is, theoretically, possible to detect IE and send a page that includes the ActiveX control and runs the rest of the site in that. It's a several MB download though, and people might get bored waiting for the site to load (not to mention your bandwidth bills).

Re:Firefox plugin

[mabhatter654]

you mean like IETab that lets firefox open individual pages with IE if you need to!!!

Re:Firefox plugin

[orpheum]

Here's a better idea. You could download Netscape 8. It uses the IE and Firefox engines and allows you to switch between them whever you please.

Ta-da!

Re:Firefox plugin

[illegalcortex]

We here at the Firexplorer project have been working on this. We're about ready to release a 0.1 pre-alpha. Unfortunately, a lot of the CSS support is kind of broken due to the way we implemented the wrapper. Firexplorer is actually a fork of Interzilla, which is up to 0.4 right now. They have better CSS support but some of the javascript functions don't always kick in like they're supposed to. But they plan on starting over with a new codebase in Interzilla 2.0, which should get javascript better supported, though it will mean reimplementing the CSS code which could introduce a few more bugs.

So you'll probably want to test your page against Firefox and then Interzilla, Interzilla 2.0 (when it's ready) and probably Firexplorer just to be on the safe side and make sure it works in all of them.

Re:Firefox plugin

[alienmole]

That looks interesting, but I'm not sure it's what I was thinking of. Firexplorer looks like a version of Firefox that looks like IE, is that correct? I was thinking of an actual plugin for IE, so that users would actually run IE but be able to transparently get Firefox (or at least a Gecko renderer) in the IE window, similar to the situation with Flash. That way they'd still have the real IE for sites which require it, but sites which want to could target the Firefox plugin so they don't have to deal with IE's quirks.

Re:Firefox plugin

[illegalcortex]

Note to self: When making next joke about a phony plugin whose purpose is to eliminate rendering differences between IE and Firefox having rendering differences of it's own, google made-up plugin names first. Also, be less subtle. ;)

Re:Firefox plugin

[alienmole]

That's a good note to self! I might not have had a problem with the subtlety if Firexplorer didn't actually exist...

For the record: (1) I did wonder why you didn't link to Firexplorer. I was quite impressed to find it on mozdev.org. (2) I thought it was strange that you should be having CSS problems etc., but didn't want to criticize without knowing more about it. For all I know, it could have been a problem with stylesheets being picked up by the container (IE) rather than the plugin, or something like that, since unless the plugin does its own network comms, it might have issues with access to content that has extensions that IE wants to handle. And I regularly deal with developers who don't quite understand the issues they're working on, so I thought you might be one of those. (3) The only mention of Interzilla I could find was "A project to run Bugzilla on Interbase", so in hindsight, that was really the biggest clue, since you implied that Interzilla was the more established project.

Re:Firefox plugin

[AVee]

A Gecko ActiveX control is a great idea. The several MB's of download are a bit of a problem, so what we do need is an Opera ActiveX control. They still manage to squeez a proper browser into a few MB. I'm sure they can come up with an AciveX control of bearable size.

A bit premature?

[DragonWriter]

Maybe its just me, but I think its a good sign that a proposed spec isn't ready for adoption when it contains this warning on one of its elements (see 5.4.1 The UndoManager interface):

This API sucks. Seriously. It's a terrible API. Really bad. I hate it.

Its also not a good sign when it has sections with a note of the form "Does anyone know enough about $foo to write this section" or "Need to write this section". Certainly I can see a need and utility for something like the Web Applications 1.0/"HTML5" standard, but it certainly doesn't seem ready for adoption as a Recommendation yet.

Re:A bit premature?

[ZachPruckowski]

I don't think anyone is saying it's ready to be adopted, except the mis-informed and the FUDers. If you read the email, they propose to make it the starting point for HTML 5, not the finishing point.

Re:A bit premature?

[DragonWriter]

Yeah, I made the mistake of trusting the summary and only clicking through to the spec, not the email that the summary, loosely speaking, "summarized".

Re:A bit premature?

[ZachPruckowski]

Yeah, slashdot summaries can be a bit misleading at times.

Re:microsoft?

[drinkypoo]

how about talking to microsoft first before submitting this "standard"... If we can get all major browsers to agree on the spec it might atleast be usefull from a cross platform perspective.

That's like asking the government for permission to go start a competing culture. you don't ask, you just go fucking do it, and if you do it right, the rest of the nation has no choice but to follow along.

Re:Alternative Names . . .

[Ghworg]

HTML.net :-).

Why Developers Aren't Caring Too Much

[moore.dustin]

We are all going to be making a majority of our sites to work in IE6 for many years to come. The release of IE7 did hardly anything to change how I design my pages. All it did was add another browser to test in really. IE6 will remain on old Windows OS's (2000 cant run IE7) and non-upgraded machines; therefore, we will all develop for them as we have for some time now.

All this means to me as a developer is that I have another thing to keep track of in regards to my industry. Add it to the list which includes: Seeing if AJAX, RoR, and other Web 2.0 fads survive the next year; if PHP has even a glimmer of hope; PNG issues; content delivery to mobile devices; and of course assorted security issues.

We always have something new coming down the pipe, but that does not mean it is the next new thing. Many sing the praises of AJAX, but really it is far from perfect and likely to be replaced by something much better very soon. Nature of the biz I suppose, but I would not have it any other way !

Re:Why Developers Aren't Caring Too Much

[Kelson]

You may appreciate this post: Kill IE6 to Let CSS3 Live.

I'd settle for some taking away

[Dorceon]

I'll be happy with any version of HTML that removes the required ROWS and COLS attributes from textarea and lets me size the damn things with CSS without dropping me into quirks mode.

Re:I'd settle for some taking away

[Bogtha]

I agree that it's silly that they are required attributes, but merely missing the attributes off doesn't dump you into quirks mode. Quirks mode is determined by the doctype you use.

Re:I'd settle for some taking away

[J0nne]

you mean the following doesn't work?

textarea {
width:200px;
height: 100px;
}

I guess I've been doing css all wrong for years now :(...

Re:I'd settle for some taking away

[MankyD]

It works, but it's not standards-compliant - it's not required to work.

Re:I'd settle for some taking away

[jandrese]

I'd be happy if we just had a way to layout the page such that it would size with the browser window. I _hate_ hardcoded sizes, but it's a pain in the rear to get good layout without using it (good as in: not having everything on top of each other or in a single big column). It's one thing I miss about tables, they by default behaved sanely when people resized their browser windows.

Re:I'd settle for some taking away

[Dorceon]

More like, "Whether or not it works depends on what the doctype is, if any."

Re:I'd settle for some taking away

[Lachlan Hunt]

It is standards compliant. There is absolutely nothing wrong with setting the rows and cols attributes in the HTML and then overriding the height and width using CSS. Doing so provides a useful fallback size for when CSS is disabled, though HTML5 does make the attributes optional.

Re:I'd settle for some taking away

[Carewolf]

Except styling replaced elements with CSS is not covered by the CSS standard, and is optional at best.

So no it is not a standard, but a pretty good idea that works is most if not all modern browsers.

Re:I'd settle for some taking away

[MrNaz]

Fully fluid page designs are quite easy in CSS. What are you trying to achieve that you can't while maintaining full fluidity of page flow?

Re:I'd settle for some taking away

[Bogtha]

I'd be happy if we just had a way to layout the page such that it would size with the browser window.

Er, we do, and it's actually the default. Load a page without any styling information at all and see for yourself. If you want to specify a width, use { width: 75%; } or whatever relative width you like instead of using px, pt or whatever you are using now.

Horrible

[Zenethian]

This is horrible. The mess of backwards compatibility on the web, particularly in HTML, is what causes so much "liberal" output from web developers and designers. XHTML took a solid step forward in squashing some of those problems by creating a very rigid set of rules to be followed for document markup. XHTML2 addresses the actual semantics of it. Backwards-compatibility is not always a great thing. Something like XHTML2 promises a clean breakaway from the horrors of HTML. This "HTML5" seeks to make the web even worse off than it already is by providing developers and designers a free ticket to make their code as horrifically nonstandard as possible. Documents should consist of well-formed markup that is easily parsed by both humans and machine alike. From a purist point of view, XHTML is blissful, though it does truly have it's own set of issues. From a realist point of view, there will sadly always be backwards compatibility on the Web, but can we *please* restrict it to software implementation and NOT in standards?! The web browser will always need to support HTML 2, 3.2, 4.0, etc etc (not that they do, but they should...). If someone wishes to code in HTML 3.2 then they should. But the next version of the (X)HTML standard should not promote backward-compatibility. It should move the technology forward instead of accommodating for previous bad practices.

Re:microsoft?

[msh104]

"Fact is if MSFT doesn't make the "standard" MSFT won't support it properly."

that's exactly why they should be in the standard creation team.

Please, give us better layout tools

[PapayaSF]

Tim Berners-Lee, bless him, didn't seem to understand that anyone would ever want a web page with more than one column. So some genius (a name I've forgotten) thought of using tables for layout, and many problems were solved: multi-column layouts with headers and footers which stretched to accomodate content and rendered the same way (more or less) across all browsers and platforms. Hooray!

Then came CSS: coding could be much cleaner and more flexible, but tables-for-layout was considered bad, and we began wrestling with creating layouts using divs and clears and floats, having to use such kludges as negative margins in order to replicate table-like behavior. It can be done, but it's harder. So for HTML5, how about setting aside creating new but not-very-helpful features like "overline" (who uses that?) and coming up with things that actually help us create web pages? Why not create a tag called "grid" that acts like a table, but is designed for page layout? Most graphic designers use grids, and it would really help web design as a whole if something like that existed for us.

How about a way of having content reflow from one column to another when a window is resized? Page layout programs have done this for 20+ years, so shouldn't it be possible for a web page and a browser today?

So please, HTML5 people, don't just talk to computer scientists and advocates for the disabled when creating this new specification. Think of the people who actually have to lay out pages!

Re:Please, give us better layout tools

[apathy maybe]

If you have data that uses a table, use the "table" tag. If you don't, use CSS. HTML is not for describing presentation, that is what CSS is for. As such, your idea for a "grid" tag, is not really for HTML at all.

What happens when your page gets displayed on a phone? With CSS you can simply revert to a single column (or the phone can just drop the CSS), with "grid", you need two pages, one for desktops, and one for phones.

I think XHTML is fine, it works and does the job. The only thing I would like is a client side include. Apart from that, I think CSS needs updating, not (X)HTML (or perhaps just browser support for CSS?).

Re:Please, give us better layout tools

[SCHecklerX]

I agree. And also with the person above about variables in CSS (sorry, I have no mod points today). That would make life a LOT easier, and I've wanted that on several occasions.

One set of tags that I'm sure would be welcomed by everyone: ... . Sure would beat all of the javascript hacks, and could be implemented by non-javascript and text-only browsers like links as well. Text-only browsers could render a table-like list. Others could roll them up. Or browsers could implement as a real menu instead of inside the content, etc.

Re:Please, give us better layout tools

[MobyDisk]

HTML is not for describing presentation, that is what CSS is for. Bad moderator!
That wasn't flaimbait - that was a pertinent point about the design goals of HTML.

Re:Please, give us better layout tools

[Fujisawa Sensei]

Why not create a tag called "grid" that acts like a table, but is designed for page layout? Most graphic designers use grids, and it would really help web design as a whole if something like that existed for us.

Because this would make sense, and help web designers/developers actually do what they've been doing all along. Its just the people in the business of writing the spec, have something different envisioned.

Re:Please, give us better layout tools

[random0xff]

Amen! It is ridiculous how easy it is to create a solid 3 column layout using tables. But if I do that I will be doomed forever by the gods of CSS. But I must also look out for 'divitis' or they will have my head.

I really need to be able to specify layout, and I don't care if it's CSS or HTML, because I have projects to finish and deadlines to meet. Flex is looking better every day... ("but it's not accessible!" they say...)

Re:Please, give us better layout tools

[Kelson]

Why not create a tag called "grid" that acts like a table, but is designed for page layout? Most graphic designers use grids, and it would really help web design as a whole if something like that existed for us.

Because this would make sense, and help web designers/developers actually do what they've been doing all along. Its just the people in the business of writing the spec, have something different envisioned.

Not really. If it is functionally equivalent to TABLE, then it's redundant markup (like the old MENU and DIR list types, which were in practice equivalent to UL). It'll also have exactly the same shortcomings that table-based layouts have (particularly: mixing presentation in your structure, and limits on scalability, particularly going down to small devices like phones). The only thing that will distinguish it from TABLE is that parsers will know not to interpret it as tabular data. You may as well add a "NOTDATA" attribute to TABLE.

The only designers it will benefit are those who follow the "don't use tables" mantra as received wisdom, rather than understanding the reasons behind it. It's just like people who try to use CSS to imitate a table layout in order to present actual tables, because they've heard "tables are bad, use CSS instead" instead of "tables as layout lead to a number of problems with can be avoided by using CSS instead"

Re:Please, give us better layout tools

[TheoMurpse]

So please, HTML5 people, don't just talk to computer scientists and advocates for the disabled when creating this new specification. Think of the people who actually have to lay out pages!

HTML isn't for layout. CSS is for layout, and CSS3 has methods of creating true multicolumn pages.

Re:Please, give us better layout tools

[Fujisawa Sensei]

But if you design your grid for functional layout, you can have attributes allowing for things like column wrapping. In effect the idea would be to use it more like a layout manager in Java.

I'm not saying that its the best solution, but its certainly an improvement over what we have.

Re:Please, give us better layout tools

[Richthofen80]

Why not create a tag called "grid" that acts like a table, but is designed for page layout?

Because the idea behind the semantic web is: Markup should tell us ABOUT the data, not how to show the data. That's what CSS is for.

What the hope was behind moving to standards is that you could separate layout and design so that multiple devices can see the same markup and interpret the visualization of the markup differently based on CSS. What would 'GRID' mean to a lynx browser, or a PDA? What about Google and other bots? What about screenreaders? which order should they read the grid in?

Re:Please, give us better layout tools

[tuxedokamen]

While I agree that page layout on the Web is no where near as simple as it should be (I'm doing a webapp right now, and sometimes it really does feel like alchemy), I disagree slightly with your last point. It's vital to listen to advocates for the disabled--particularly the visually impaired and those with motor difficulties--when solidifying standards like this. The whole idea of the web is accessing information, and if a designer takes the easy way out in terms of implementation and leaves huge swaths of people unable to see the content, IMHO they've kind of missed the point entirely. This is, in part, why tables, spacer gifs, etc. are bad, as I understand it (and also, from my own testing): they really play havoc with screen readers, to the point that a page is nearly incomprehensible. And that assumes the screen reader can make enough sense of things to read them at all--if a a page is malformed enough, there's just silence. I'd imagine the situation with braile-output devices and systems for navigating by alternative means are similar.

Government websites have to be fully accessible according to a government standard (508, I think), but non-government websites certainly don't. And making the argument that the visually impared/those with motor control difficulties make up such a small percentage of the population is not only superfluous, as even ten percent of the total internet population is well over 100,000, and the number of people with alternative access needs will only continue to rise as access proliferates, but outright discriminatory. If the guilding principle of the web is information and communication for all, exclusion isn't an option.
(I realize I'm not using exact statistics here, but I unfortunately don't have time to look them up right now.)

For the webapp we're doing, our team is adhering to the Authoring Tool Accessibility Guidelines (ATAG) 1.0 (http://www.w3.org/TR/WAI-AUTOOLS/). This set of guidelines and the Web Content Accessibility Guidelines (WCAG) are perhaps more important than entanglements over HTML5 and such right now, as they're concerned not only with implementation (how a page is programmed), but how it is designed, from the ground up, to be accessable to all. Implementation should flow from this, IMHO.

Re:Please, give us better layout tools

[GigsVT]

CSS is terrible at layout. His point remains, using CSS for any nontrivial layout is a complete bitch. It obviously wasn't designed with that in mind. It works great for styling a flat page, but doing layout in it is terrible.

Re:Please, give us better layout tools

[sootman]

So some genius (a name I've forgotten) thought of using tables for layout...

Possibly not invented by, but definitely refined, popularized, and documented by David Siegel, author of the book Killersites, in 1997, along with the single-pixel GIF trick.

Re:Please, give us better layout tools

[Spy Hunter]

The only thing I would like is a client side include.

Man, wouldn't that be nice. How is it that we've gone through all these major revisions of [X]HTML and an <include> element has never been added? It seems so obvious. Is there some technical reason?

Re:Please, give us better layout tools

[jeffy210]

Would you mind explaining this further or pointing me in the right direction to research it more. I'm trying to switch more to CSS for that exact reason (write once, read many).

Re:Please, give us better layout tools

[Bogtha]

Government websites have to be fully accessible according to a government standard (508, I think), but non-government websites certainly don't.

Please don't talk as if the USA is the only country in existence. Accessibility laws across the world vary quite widely, and there's plenty of places where non-government organisations are bound by law to ensure their websites are accessible. Even in the USA, it's not as clear-cut as you make out - non-government organisations have been sued under the ADA, and they've set conflicting precedents, so it's not at all clear what is legally required and what isn't.

Re:Please, give us better layout tools

[Bogtha]

How is it that we've gone through all these major revisions of [X]HTML and an <include> element has never been added?

You've already had a client-side include for over a decade. It's called the <object> element type.

Re:Please, give us better layout tools

[apathy maybe]

No that isn't what I meant. Have you ever used Server Side Include? Or the PHP ?

What it does is make a seamless page, the object tag doesn't do that. The only way to get a seamless page with includes on the client side is a JavaScript hack (which you can research if you want).

Re:Please, give us better layout tools

[apathy maybe]

Simply use an external stylesheet. For example,

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head><title>Moo! - index</title>
  <meta name="GENERATOR" content="gedit (Linux) &amp; Vim" />
  <meta name="CREATEDBY" content="apathy maybe" />
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!-- -->
  <link rel="stylesheet" href="layout.css" />
  <link rel="stylesheet" href="format.css" />
<!-- -->
</head>

I almost always use two style shees, layout and format. Then you just use the styles as you would otherwise.

Re:Please, give us better layout tools

[tuxedokamen]

No offense meant. I should have specified that I was speaking of the US government. I'll admit I often fall into the trap of considering slashdot as being 99 percent US read, just because of the topics discussed and the fact that the large majority of posts seem to be written in US English.

I am well aware of the ADA's ambiguity on this sort of thing. It's ambiguous in a lot of other areas as well--did you know that private universities do not have to be fully physically accessible (e.g.: automatic doors), even though they cannot discriminate in admissions on the basis of physical ability? I was just pointing out what I know to be true: that all US government sites must comply with the government accessibility standard. This is a legal requirement. Court cases set precedent, but unless it's a very powerful court, precedent only bites you if you get sued. For example, if the Supreme Court ruled a certain class of website had to meet accessibility requirements under the 14th Amendment (Equal Protection Under the Law), that would have nation-wide implications and effect. If a lower federal court did it, it would still have nationwide implications, but it wouldn't be acted on nation-wide so long as there was a chance of appeal. State and local courts likewise have progressively smaller areas of influence and ability to set meaningful precedence outside that area of influence. And yes, I am aware this is an oversimplification of how the court systems work.

I would be curious to know--and I will admit not having done much research here--if accessibility cases have made it to the Supreme Court, and what the outcome was. I think a court ruling at this level as I described above (inaccessibility being in violation of the Constitution) is what we'll need in the US to force NGOs to adopt accessible practices. The alternative is a meaningful amendment to the ADA, and that's not going to happen anytime soon in the current political environment.

Re:Please, give us better layout tools

[GiMP]

There is a client-side include, it is called XSL.

Re:Please, give us better layout tools

[GiMP]

HTML isn't for layout. CSS is for layout, and CSS3 has methods of creating true multicolumn pages.

I choose to advertise that XHTML is the layout, and CSS is for style/fashion.

The truth is that it is nearly impossible to write XHTML such that CSS can have full control over the layout. Much of CSS's abilities are dependent on the positioning of the elements within the XHTML. That is why the real layout must be in XHTML. Luckily, we can openly, and easily, create XHTML layouts in a dynamic and open way through the use of templates, aka. XML/XSLT.

For example... While CSS might be able to position a navigation bar on the left or right side a page, it is limited in its ability to re-sort or move items. It can assign alignment or displacement amongst items, but cannot and does not define the layout.

Re:Please, give us better layout tools

[Spy Hunter]

Hmm interesting. But XSL has some disadvantages. It's a huge spec to implement and a lot of processing overhead just to get an element. It will never be supported everywhere, it requires splitting code into a separate stylesheet file, it requires XHTML so you have to do your doctype and xmlns incantations just so, you can only include complete well-formed XML documents with a single root element (so you couldn't include multiple paragraphs without wrapping them in one div or span), and perhaps worst of all it disables incremental rendering. An HTML element would be trivial to implement so support would soon become widespread. It would have little runtime overhead and could easily address all of the above limitations.

Re:Please, give us better layout tools

[GiMP]

Hmm interesting. But XSL has some disadvantages. It's a huge spec to implement and a lot of processing overhead just to get an <include> element.

HTML is a huge spec as well, so I don't see much argument there, and it isn't like the XSL parsers haven't been written, there are many available. Computers are plenty fast today to process such things, and I even have mobile devices that happily, and quickly, support such pages.

It isn't *just* about an <include>-esque element, it is about providing a full suite of client-side layout templating. I consider XML the data, XHTML the layout, CSS the style, and XSL the glue ;-) I believe that many of the purported advantages of CSS are lost without implementing the full suite of XML/XSL/XHTML/CSS.

My idea of a "3.0" webapp is something that outputs XML, transforms with client-side XSL into XHTML, and stylizes with CSS. Such development allows not only for user-specified CSS files, but also for alternative page templates. My deepest concern with this movement is with phishing and cross-site attacks, something that we will be seeing enough of with the growth of web services.

It will never be supported everywhere, it requires splitting code into a separate stylesheet file,

It is already supported... and splitting code into a stylesheet file?? Don't we already do that with CSS? Don't you already do that with your existing templating system? This replaces, to some extent, your existing templating systems such as HTML::Mason.

it requires XHTML so you have to do your doctype and xmlns incantations just so, you can only include complete well-formed XML documents with a single root element (so you couldn't include multiple paragraphs without wrapping them in one div

The <html> tag is the single root element. What other root elements do you use in (X)HTML?

and perhaps worst of all it disables incremental rendering

A defect of modern implementations, as I understand it. This is not a defect of the standard. Sure, this might mean that its slightly premature, but it *is* supported by yesterday's browsers. It might not be the best support, but enough to appease those that choose not to upgrade when "The Next Big Thing" comes along.

Re:Please, give us better layout tools

[TheoMurpse]

I choose to advertise that XHTML is the layout, and CSS is for style/fashion.

I think you're confusing "layout" with "structure." Perhaps we should use the terms "structure" for the (X)HTML and "presentation" for CSS.

CSS is for layout, because layout is positional properties, and those are governed by CSS's height, width, top, bottom, left, right, etc. (X)HTML is for structure, i.e. "here is a division of text (DIV)," "here is a span of text (SPAN)," "here is a very important header (H1)" -- of which I say nothing about how it shall appear to the user.

Re:Please, give us better layout tools

[GiMP]

(X)HTML is for structure, i.e. "here is a division of text (DIV)," "here is a span of text (SPAN)," "here is a very important header (H1)" -- of which I say nothing about how it shall appear to the user.

It isn't the markup that specifies how it should display to the user, it is the order and hierarchy of the elements that, in XHTML, specifies the layout. The reality is that, unless only using absolutely positioned elements, CSS has only limited control over the presentation of a webpage.

A CSS stylesheet can specify how to style a navigation bar, but cannot actually specify WHAT will appear in that navigation bar. To elaborate, imagine Slashdot, applying a new CSS stylesheet cannot reposition the "Preview" button, nor can it reposition the "Logout" link onto the left-hand navigation menu. This *is* a matter of layout, and this is handled not in CSS, but in XHTML.

Re:Please, give us better layout tools

[TheoMurpse]

A CSS stylesheet can specify how to style a navigation bar, but cannot actually specify WHAT will appear in that navigation bar. To elaborate, imagine Slashdot, applying a new CSS stylesheet cannot reposition the "Preview" button, nor can it reposition the "Logout" link onto the left-hand navigation menu. This *is* a matter of layout, and this is handled not in CSS, but in XHTML.

CSS most definitely can specify what will appear in the navigation bar. The reason that there is any "layout" without CSS specifically specifying it is because the browser chooses a default "layout" in the absence of an author-specified one.

It is absolutely not handled by the XHTML. The XHTML tells the browser "the element B is a child of this other element A." Then, if no CSS describing where A and B specifically belong is given to the browser by CSS, the browser constructs its own "layout" declaring that, by default, B is going to be drawn inside of A. Thus, the XHTML does not give any layout instructions at all. The browser makes assumptions based on the structure of the document (given by the XHTML) as to how to invent its own presentation.

Talk to developers of any web browser or web standards, and they'll tell you it is true. Of course, there are deprecated exceptions (such as the B, I and U tags), but the main thrust stands: (X)HTML is for structural definition, and CSS is for presentational definition.

Re:Please, give us better layout tools

[Spy Hunter]

With CSS, you don't have to split your code into separate files. CSS can be inline. I see no way to do that with XSL (although if there is one, I'd be happy to know about it). There are pros and cons of both ways of doing things and it's nice to have that flexibility (pretty much every site uses both embedded CSS and separate stylesheets).

You misunderstand about the root element thing. Say I want to write some HTML like this and implement include with an XSL stylesheet:

<ul class="comments">
<li>stuff goes here</li>
<include href="./someothercomments.pl?whatever">
</ul>

The included file can't have multiple <li> elements at the top level, because then it's not a well-formed XML document by itself, and XSL can only include complete well-formed xml documents with the document() function. Yes, this can be worked around. But why should we have to? (Personally, I think this is a problem with XML in general. I've never heard the rationale for why XML requires a single root node. I'm sure there is one; I'm not sure that it's good.)

As for incremental rendering being a problem with implementations and not the spec, well, I thought I remembered a Bugzilla discussion about this:
tinyurl to avoid the Bugzilla Slashdot ban: https://bugzilla.mozilla.org/show_bug.cgi?id=18333 #c83

Turns out that running XSLT is incremental, but, in the general case, all the input must be available before you can *start* running it, due to XPath. Since the slow part is obtaining the input and not actually running the XSLT, that doesn't really help you. Mozilla may in the future implement incremental rendering when your XPath is simple enough, but it sounds like it won't be trivial, and I'll just bet that even *if* that optimization is ever implemented, it will be easy to defeat with relatively innocuous XPath expressions, resulting in an instant fallback to non-incremental rendering. Boy will that be fun to debug!

Re:Please, give us better layout tools

[GiMP]

The included file can't have multiple elements at the top level, because then it's not a well-formed XML document by itself, and XSL can only include complete well-formed xml documents with the document() function. Yes, this can be worked around. But why should we have to? (Personally, I think this is a problem with XML in general. I've never heard the rationale for why XML requires a single root node. I'm sure there is one; I'm not sure that it's good.)

It isn't that hard to have a root element in your included file. Plus, if you're including XHTML documents, you will already have an html top-level element.

<ul class="comments">
<li>stuff goes here</li>
<xsl:copy-of select="document('somefile')/html/body/ul/*">
</u l>

Re:Alternative Names . . .

[Paulrothrock]

How about HTML 2.0?

Multi-column is already in the pipeline

[Kelson]

How about a way of having content reflow from one column to another when a window is resized? Page layout programs have done this for 20+ years, so shouldn't it be possible for a web page and a browser today?

The CSS3 multi-column module was designed for exactly that purpose. It's available in experimental form in current Mozilla-based browsers (Firefox, Seamonkey, Camino, etc.), and according to that page, it's available in nightly builds of Webkit, which will eventually become a future version of Safari. (Since the spec isn't final, the rules use -moz and -webkit prefixes, so that if the spec changes they won't have to change the official rule's behavior.) No word from Opera, though there are reportedly a bunch of CSS3 features in store for the next major update, and of course, who knows how long before we'll see it in IE.

Remember: HTML for structure, CSS for layout.

Re:Multi-column is already in the pipeline

[HTH NE1]

The thing about multi-column layout is it is very annoying to read when the columns are taller than the browser window. You reach the end of one column and you need to scroll back to the top of the next. It's the same annoyance as reading lines of text which are wider than you screen, just less frequently. (It works for newspapers and magazines because their whole page is visible and is only a matter of scanning with the eye.)

The proper rendering of multi-column text is to embrace horizontal scrolling and forbid vertical scrolling. Column width and gutter need to be an even divisor of browser width and leave column height and count to flow to fit the window.

Of course, this is at right-angle odds with the design philosophy of web pages, so multi-column sections pretty much have to be subsections of the page itself as like an IFRAME, allowing the multi-column view without disrupting the rendering of the rest of the page.

As a result, it's a design mess and people go back to the single column view with sidebars for additional information, using web design to its strengths rather than forcing it to behave like other media.

If it must exist, it should be a style sheet rule-set so it can be applied according to output type such as hard copy where that presentation makes sense. I'd prefer to have image masks that enable text to flow around the curves of an image, and leveraging transparency for it would reduce the bandwidth impact.

Re:Multi-column is already in the pipeline

[HTH NE1]

The proper rendering of multi-column text is to embrace horizontal scrolling and forbid vertical scrolling.

What an absolutely terrible idea. The whole point of embracing vertical scrolling instead of horizontal scrolling is that text flows horizontally. If you add horizontal scrolling, you then have to scroll back and forth as you read each line. If scrolling is vertical, then you scroll as you read without ever having to scroll backwards.

Kindly read the rest of my posting before responding again, particularly the very next sentence that addresses your complaint: "Column width and gutter need to be an even divisor of browser width and leave column height and count to flow to fit the window." As such no reverse scrolling, be it up- or leftwards, is necessary.

Re:Multi-column is already in the pipeline

[Anonymous Coward]

As I responded an earlier post: Tofu gives a great example how multicolumn documents should work in CSS.

Re:Multi-column is already in the pipeline

[HTH NE1]

As I responded an earlier post: Tofu gives a great example how multicolumn documents should work in CSS.

I didn't know about that program. I think I'll give it a try. Thank you, AC, for letting me know about it. I think I'll use my Karma Bonus to lend your mention a little more prominence.

And to not be totally redundant, I'll relate a story about multi-column printing:

When I still used a dot matrix printer with fan-fold paper, I'd print everything sideways giving a nice continuous scroll that was much easier to page through than printing upright on one long fan-fold column. Today, at work I still print sideways (primarily to allow for long code lines). And sometimes I tape the pages together to get back to that fanfold presentation at the half-page size of 5.5 x 8.5, conveniently small to carry around the office and read in the restroom or break-room. (If only I could get xemacs 19.13 (1995) to print sideways in two columns so I don't waste half a sheet of paper per page, and some kind of fast-drying "liquid tape" to join the page edges quickly without causing facing pages to stick together.)

Re:HTML5?

[Kelson]

HTML 1, 2, 3, 4, etc. are different revisions of the specification. New capabilities are added (IMG wasn't in the original version), some are changed (P used to be a double-line-break, but now it's a container with a top and bottom margin), other little-used features are removed (have you seen an ISINDEX tag lately? how about a MENU list?).

XHTML 1.0 is essentially HTML 4 translated into XML. Later versions of XHTML have diverged.

Why MS will support HTML5 ASAP

[Klaus_1250]

# Markup for advertisements Will make Admuchers/Adblocks job a lot easier too :-)

be nice if HTML was deprecated

[brunascle]

personally, i'd like to get rid of HTML completely and replace it with XHTML. i absolutely hate that some tags dont have to be closed in HTML. without some sort of outside knowledge of the HTML standard (e.g. by downloading the DTD), a parser cannot be expected to properly organize an HTML document.

here's an example:

<div>
<br>hi
<br>how are you?
</div>

<ul>
<li>hi
<li>how are you?
</ul>

without knowledge about HTML, a parser cannot be expected to understand in the first case that the <br> element is empty and in the second that the <li> element is not.

Re:be nice if HTML was deprecated

[Carewolf]

It doesn't matter if
  is empty or not. It will render exactly the same ;)

And no, that is not accidental.

Not to put words in his mouth...

[Kadin2048]

But your objection to HTML/CSS doing what javascript used to be necessary for? Really? You prefer writing little-stupid javascript functions to just putting a :hover rule in your CSS? Really?

I'm going to go out on a limb and bet that the GP would probably be against :hover rules generally.

The problem isn't the implementation of the useless eye candy, the problem is the useless eye candy.

Re:Not to put words in his mouth...

[Bogtha]

Hover rules aren't useless eye candy. Hover rules are visual feedback letting you know you are over something clickable. If you move your cursor across a bunch of links, it's immediately obvious which one you are currently over without having to pay attention to precisely where your cursor is. Usability++.

Re:Not to put words in his mouth...

[jandrese]

That's not necessary if you make your links look like links though. The only time you really need :hover is when you have some element that is not normally a link that you want to turn into a link. Links are immediately obvious in regular HTML pages because they're a different color and usually underlined. Your mouse cursor also changes when it is pointing at them. There is no need to have it jump out or change color again unless you're doing strange things with your page. If you have a bunch of links back to back in such a way that it is difficult to tell where one stops and another ends, then you probably need to redesign your webpage anyway.

Re:Not to put words in his mouth...

[Bogtha]

Links are immediately obvious in regular HTML pages because they're a different color and usually underlined. Your mouse cursor also changes when it is pointing at them.

Did you even read my comment? I'm talking about when you are moving through a list of links, like a navbar. Just because the links look like links and your mouse pointer indicates that you are over a link, it doesn't mean you are getting strong visual feedback about exactly which link you are over.

If you have a bunch of links back to back in such a way that it is difficult to tell where one stops and another ends, then you probably need to redesign your webpage anyway.

Take a look at your own page. You provide an unstyled list of links at the top. When I put my mouse over the first one and move it down over the list, it's not obvious exactly which one I am over when I am anywhere near the edges. I have to look at the status bar if I want to be sure.

This is not about funky layouts or designs that scew things up. This is about a totally normal situation — adjacent links — being slightly improved by the appropriate use of visual feedback.

Re:Not to put words in his mouth...

[jandrese]

A vertical list where each link is on it's own line followed by a description is confusing?? You need some sort of extra help to discern that those are separate links?!? My webpage is certainly no paragon of modern design, but I think it's easy to navigate. It does look pretty dated these days and I guess I should update it at some point, but I don't have a lot of motivation to fix something that works just fine.

Re:Not to put words in his mouth...

[Bogtha]

Are you deliberately misreading my comments? I didn't say that adjacent links are confusing and I didn't say that anybody needs help to figure out that they are separate links. What I said was that when you interact with them with the mouse (i.e. when hover rules are relevant), it's not always immediately obvious exactly which link you are interacting with, and hover rules can improve that.

Do you seriously not get this? Even unstyled links on separate lines are adjacent to one another, no extra styling necessary to cause this problem. One pixel can mean the difference between clicking on one link and clicking on the other. How do you find out? Well you can squint at the screen and hope for the best, or you can look at your status bar, or you can move your mouse further away from the edges or, if the web designer has provided hover rules, it can be immediately obvious. Which do you think is the most user-friendly?

Re:Not to put words in his mouth...

[Anonymous Brave Guy]

A vertical list where each link is on it's own line followed by a description is confusing?? You need some sort of extra help to discern that those are separate links?!?

No you don't, and that's not what Bogtha said.

However, users navigate around web pages primarily via fairly imprecise mouse movements, usually tracked by a relatively discreet mouse cursor graphic. It is much clearer, when displaying a load of adjacent links, to have the entire link change colour or something than just to have the mouse cursor change and rely on the user to identify correctly which part of the "pointer" is the relevant one. One of these things tells you you're over a link. The other tells you which link you're over. Good usability practice strongly favours the latter, and that's all Bogtha is trying to explain to you.

Explaining the plan

[alienmole]

Here's what I was thinking: ordinary users don't seem to have a problem installing Flash, which is a several MB download, when they're told that they need it to view a site. So if the Gecko ActiveX control does the trick, those of us who are serious about eliminating IE should detect IE visitors and display a page saying that you need to download the Firefox/Gecko control to use the site (or Firefox itself, of course).

Pretty soon, about as many people who have Flash will also have Firefox running inside IE, and it'll no longer be necessary for many people to cater to IE.

Re:Explaining the plan

[alienmole]

I deal with ordinary users every time I deliver one of the systems I develop. But add "one way or another" to my sentence if it makes you happy. The point is, Flash is installed on a lot of user machines, whether they did it themselves, or whined at their local IT grunt to do it for them, or whether the IT grunts preinstall it as a matter of policy.

Re:Explaining the plan

[massysett]

Ditto to that. Flash isn't the only example. People install Acrobat Reader, Real, and all sort of other junk to get the content they want.

Web browsers are written for two markets: the end users and the web site developers. Most end users don't care all that much about their browser--unless it isn't showing them the content they want. If web sites banded together and pushed Firefox adoption, they could get somewhere.

Of course some of it is chicken/egg. People install Flash because it's got some critical mass. But just because IE is the browser shipped with Windows doesn't mean it has to dominate. MSN Messenger ships with Windows but look at the massive hordes still using AIM.

Re:Explaining the plan

[Dan Ost]

IE usage share is currently less than 80% (at least according to http://marketshare.hitslink.com/report.aspx?qprid= 3).

At what point to web designers decide that they need to cater to the remaining 20%?

Re:microsoft?

[gstoddart]

"Fact is if MSFT doesn't make the "standard" MSFT won't support it properly."

that's exactly why they should be in the standard creation team.

Yeah, like that helps. They've been on standards committes before. They mostly just try to push their own agenda and technologies, file for a few submarine patents, or work on their own proprietary/incompatible version to be released anyway -- thereby invalidating the point of the standard.

Microsoft has never perceived standards as being in their interests. Sitting on yet another standards committee won't change that. Hell, their latest attempt at a 'standard' is that XML file format for office which self-referentially says "do it the way we did it years ago that was buggy".

They're certainly not going to be in favour of any standard which doesn't see them getting license revenues or that can be implemented by OSS people. They are going to actively prevent this from happening.

Cheers

Forget HTML, it's CSS that's Broken, deal with it

[StreetFire.net]

I WANT A REAL LAYOUT LANGUAGE!!!!!!!!

I've tried, I really have, to embrace the Zen garden Juu-Juu of CSS, can you make a simple blog page work in CSS? sure! Can you make an massive website with many different templates and variable width data-areas work in CSS? Yea, if you're a complete lunatic. but you have to get there with hack over hack over hack over hack. Here is the deep dark secret of CSS, it's not designed for layout. It's fantastic for styling, but try doing a Box-model or Float layout and you quickly realizing you're asking CSS to do things it wasn't intended to do, and it simply does not break gracefully the way a simple table layout does (You know floats were originally intended for pictures, not layout areas). So while I respect the purity of a CSS for style, HTML for content concept, in practice CSS is just as much of a kludge as Table design. I've saved hours of time and reached wider audiences of compatibility by going for a hybrid design, but this breaks the "standards".

IMO, standards should follow simple elegant solutions, a hundred lines of CSS browser compatibility code and float hacks is far from an elegant solution. PLEASE PLEASE PLEASE give designers a proper layout language!!

Dear W3C,

[circletimessquare]

Please revive the <BLINK> tag. I thought it was as awesome as MC Hammer. In fact, just go ahead and make an <MCHAMMER> tag.

What would it do? You have to ask!?

Yours,
the early 1990s

Re:Dear W3C,

[apathy maybe]

"Schrödinger's cat is not dead"

(Yes I stole this, in fact it is on the Wikipedia page (though I had seen it before hand). I don't care.)

Re:Dear W3C,

[apathy maybe]

FUCK!

"not" should either be blinking or have tags around it like at http://en.wikipedia.org/wiki/Blink_tag#Use_in_popu lar_culture and http://schroedingers.cat.woot.cc/

Today is NOT a good day to die.

[ScentCone]

When was the last time you even saw a computer that had IE5 on it?

So, I've got a client that runs an e-commerce site. At least a couple hundred orders per day. I did a quick dig into today's stats. So far: 4 orders from people running IE5, and one from a Netscape 4 flavor. All appeared to be on dial-up connections. A little over $1600 worth of business in those 5 orders. These are orders for non-essential items, which suggests disposable income that COULD go into a computer upgrades, broad-band connections, etc. for those shoppers, but which have not. I absolutely guarantee that my client would rather have today's business from those 5 customers than have whatever liberty may come from being able to leverage current formatting fanciness/compatibility. Their site renders just fine in every browser to date, and that $1600 is in the bank, instead of that of a CSS-ed-to-the-hilt, hipper-than-thou competitor. Someday the numbers of legacy users will drop low enough to warrant the change, but $1600 before lunchtime says today's not the day.

Re:Today is NOT a good day to die.

[Lord Ender]

If paying a developer cost him $2,000 per week, and it takes an extra week of time to test against rare, old browsers; then it takes two more weeks add all the hacks required to make it work properly in those rare, old browsers....

well...

He just spent $6k to save $1.6k.

Re:Today is NOT a good day to die.

[lahvak]

He spent $6k once to make $1.6k a day.

Re:Today is NOT a good day to die.

[FonzCam]

The $1600 was for one morning of sales, even at 10-20% margin the guy will make back the $6k in less then a month.

Re:Today is NOT a good day to die.

[drix]

Meh. First, you're talking gross. What's his margin on those $1600 worth of orders? If it's "standard" retail, let's say 5%. So $80 bucks a day. Now, how much extra time and effort did it take you, the developer, to support browsers that are almost a decade old and that, by your own admission, affect roughly 2% of the userbase? My guess is at least a couple thousand dollars, unless you adopted a lowest-common-denominator approach, in which case the site must look unappealingly 1997. More importantly, what sort of tradeoffs were you forced to make? Have you studied at all how much business your client is forgoing by not leveraging the current "formatting fanciness"? Here are a couple points to consider.

1. People like sites that are clean looking and easy to use. Marketing studies have consistently shown that people will pay more for the exact same item from a place that sells it in a more aesthetically pleasing manner. (I'm not saying this can't be done with HTML 3.2 or whatever, but it's much harder.)
2. Standards-compliant sites that use semantic markup place higher in search engines, netting more impressions and more sales.
3. Table-based layouts are slow and unresponsive. How many people here remember good old NS 4 sitting there blank-faced, cranking away on the old, complicated table layouts of yore. I do. Responsiveness is huge; people have come to expect it as the rule, not the exception--a marked departure from the dark days of IE5 and NS4.

Re:Today is NOT a good day to die.

[ScentCone]

First, you're talking gross. What's his margin on those $1600 worth of orders?

He makes about 35% markup on orders like that. As of a more recent check (some hours since I chimed in on the thread), the ancient-browser-checkouts have now grossed about $2200. We'll call that, conservatively, about $500 of profit (not counting taxes, flushing the toilets, pizza for the warehouse guys, etc).

the site must look unappealingly 1997

No, I'd say it looks more early-2005. The design is deliberately lean, spartan, and surprisingly navigable considering they have around 12,000 items. The are leveraging Froogle, affiliate marketing with feeds and hot links into products... lots of the more recent goodies. There are some nested tables in play, still... but they come back with first-page Google hits on a great deal of what they talk about and sell.

Responsiveness is huge

Yes, it is. But any latency I've had to fight was almost always due to database performance problems, usually because some session management table or other beastie had outgrown the way the indexes were built, etc. Believe me... a complete redesign for new standards is desireable, and could indeed bring in some otherwise missed sales. But it's nice to not run off the little old ladies and their credit cards, too. 10 of them today, it looks like. That's about 300 of them per month, and they do a lot of repeat business... the business has about a 45% repeat customer rate. Which might not sound great until you realize they're growing rapidly. So, don't "meh" something that's working pretty solidly, and which is very much a topic of discussion and planning at the business. My point (back to the thread, here) is that the "web designer" to said "when was the last time you even say a machine running IE5" is full of crap. I'm not just seeing them, I'm seeing them show up and spend money.

Re:Today is NOT a good day to die.

[drix]

Seeing as we're a mouse click away from forming our own judgements.. what's the site?

Re:Today is NOT a good day to die.

[BenoitRen]

These are orders for non-essential items, which suggests disposable income that COULD go into a computer upgrades, broad-band connections, etc. for those shoppers, but which have not.

You don't need to upgrade your computer or Internet connection to get a better browser. Even on dial-up, it doesn't take an eternity to download Firefox or Opera.

Re:Today is NOT a good day to die.

[Dirtside]

Table-based layouts are slow and unresponsive

Can you elaborate on that? I've never seen any performance difference in rendering between CSS and table layouts. And I'm talking huge, monstrous, multi-dozen-column, multi-hundred row tables with weird exceptions and yadda yadda. Not piddly 5-row tables on a blog.

Re:Today is NOT a good day to die.

[ScentCone]

You don't need to upgrade your computer or Internet connection to get a better browser. Even on dial-up, it doesn't take an eternity to download Firefox or Opera.

You don't need to tell ME that! My point is that out there, in the wild, are people participating in the web-centric economy, spending money on lots of things, and doing so using old browsers on (probably) old, creaky machines and operating systems. They're out there, and you can ignore them, or you can sell them things if you find it profitable to do so.

Re:Today is NOT a good day to die.

[drix]

Sure. First, browsers (at least the old ones, back when I cared about this issue) won't render tables until the whole table source, including all the images it contains, have loaded. Separating your content into blocks allows the page to render progressively. This makes a huge difference. Second, using a table layout essentially embeds all your styling in each page, greatly increasing download times. Moving this out into a CSS file allows it to be cached, so it's basically loaded once and that's it. In my experience the raw .html files are 25-33% as big when you move to a table-free layout.

Re:Today is NOT a good day to die.

[businessnerd]

Probably better to not post the link. From what has been described, I doubt the site could withstand a slashdotting.

Re:Today is NOT a good day to die.

[ScentCone]

Seeing as we're a mouse click away from forming our own judgements.. what's the site?

For obvious reasons, I decline. I'm happy to report my experiences here, to help address the "are there still IE5 users out there" question, but it would be uncool to link to the site in the context of this thread.

Re:Today is NOT a good day to die.

[Anonymous Brave Guy]

So, I've got a client that runs an e-commerce site. At least a couple hundred orders per day. I did a quick dig into today's stats. So far: 4 orders from people running IE5, and one from a Netscape 4 flavor. All appeared to be on dial-up connections. A little over $1600 worth of business in those 5 orders.

A valid point, to be sure, though I do wonder about the opportunity cost of supporting the older browsers. Depending on the weakest area of the site, it's quite likely that a few days of staff time could instead have been spent on something like usability research, with much better returns than the 2.5% you're quoting.

Re:Today is NOT a good day to die.

[edwdig]

The older browsers you speak of that render tables slowly (really just Netscape 4.x and older) also don't do a very good job of CSS. Essentially, in those cases where table rendering speed is an issue, you don't really have a choice of another way to do it.

Re:Today is NOT a good day to die.

[mabhatter654]

And in the amount of time they spent looking at your site deciding what to order they could have Firefox 1.5 that runs on windows all the way back to 98! The internet is new an evolving... staying behind more than 5 years is a foolish expectation, especially when it's FREE to be up to date.

Re:Today is NOT a good day to die.

[ScentCone]

And in the amount of time they spent looking at your site deciding what to order they could have Firefox 1.5 that runs on windows all the way back to 98! The internet is new an evolving... staying behind more than 5 years is a foolish expectation, especially when it's FREE to be up to date.

I'm a little foggy here. Most people, on the site in question, go from showing up to placing a straight-forward order and be done with checkout in about 12 minutes. Are you suggesting that we redirect people with older browsers to a nag page, explain that even though the site they're visiting will work just fine right that moment, that they're really behind the times, and don't let them spend money until the go off to download something they've probably never heard of, and trust the retailer that they're visiting that a software upgrade is really the right thing to do, etc...? Might as well just redirect them to slashdot and hope for the best.

People will upgrade when they're good and ready, usually because a fading system just won't keep up with them any longer. When a retailer (like the one in question) is still seeing enough of that sort of traffic, it makes more sense to sell them things and provide customer service than it does to evangelize about a system upgrade. I want them to upgrade. EVERYONE wants them to. But doing so while in the middle of trying to buy a product and have it shipped is a little tone deaf, I think.

Re:Today is NOT a good day to die.

[sarabob]

No, he doesn't want to give you the site because he's already given you information about margins, turnover etc etc etc. As it stands it's interesting information about how supporting an older browser results in a not-insignificant amount of business; telling you the site would Obviously be a different level of disclosure.

Re:Today is NOT a good day to die.

[NulDevice]

There is obviously a cost of supporting older browsers, but...I've always looked at it this way - do you want to be the guy who turns away a customer? If that customer calls to complain, do you want to explain to the CEO that you decided that a certain group of customers were unimportant?

I had an old CIO who insisted we spend the extra money and time to back-compatibility test. His rationale was even if we spend more than we make from having web apps that are successfully compatible with pretty much everything, it's still a lot better than losing anything because we just told a customer he can't use our site. The direct financial loss may be insignificant at first, but bad word of mouth (particularly in a very tight-knit industry like that employer was in) could be devastating long-term.

Granted, he never said it had to be *perfect* across browsers, but it had to at least work. And honestly, getting it workable-but-not-always-pretty wasn't terribly difficult or expensive.

Re:Today is NOT a good day to die.

[Anonymous Brave Guy]

I've always looked at it this way - do you want to be the guy who turns away a customer?

Only if I'm getting more or better-paying customers by doing so.

But it's always a return-on-investment question in business. Of course it's desirable to get every sale you can, but realistically, you often have to prioritise. Supporting an older browser used by perhaps 2–3% of your customer base is likely to have a lower priority than improving usability that will affect the remaining 97% and generate an average 10% increase in sales to each.

Similarly, you're quite right that you have to factor in good will and market reputation rather than looking at isolated cases, but that cuts both ways as well. If you improve the usability of your web site or your brand recognition, then this is likely to improve your word-of-mouth sales. Again, whether this is worth more than what you lost by giving up those customers with older browsers is a decision you can only make in the specific circumstances of your particular business, preferably with some kind of research into the pros and cons of each investment you might make to help you decide.

Re:Today is NOT a good day to die.

[mstahl]

Glad to know I'm not the only one who's seen this. My gripe is with a client who approved a design that was not feasible to develop in IE5 *and* modern browsers simultaneously. My solution was a dirty filthy javascript kludge that adds more styles to the stylesheet (overriding the ones in the main CSS files of the site) if it knows the client is using IE

As for hipper-than-thou web design . . . I took offense at that comment for a brief second then looked at what I was wearing. No comment.

Re:Today is NOT a good day to die.

[ScentCone]

Sorry, what? Obvious?

This seriously weakens your point, pal.

No, it seriouly demonstrates a little bit of professionalism. I don't want to distort my client's traffic stats, I don't want to burn up a bunch of his bandwidth and storage with even a minor slashdotting that will very likely not result in business for him, and I don't want to cross-link a discussion about business behavior/history/demographics with his actual business web presence in a discussion board that will be archived/googled/etc. That these things didn't already leap to mind before you fired off your anonymous note suggests that you're not really coming to the conversation with any sort of business savvy, ethics, or a thought for how a business owner might see the results of such a disclosure. Pal.

Re:Today is NOT a good day to die.

[8-bitDesigner]

I've seen heavy table-based websites crawl on IE7, so it's not a moot point. Tables are inherantly more complex due to the 3x increase in markup (1 DIV versus TABLE - TR - TD), and cause the browser to do more work, than with a simple stylesheet.

Also, the previously mentioned point about browsers being incapable of rendering page content until the entire markup is downloaded still stands.

Re:Today is NOT a good day to die.

[edwdig]

I've seen heavy table-based websites crawl on IE7, so it's not a moot point. Tables are inherantly more complex due to the 3x increase in markup (1 DIV versus TABLE - TR - TD), and cause the browser to do more work, than with a simple stylesheet.

That entirely depends on the layout of the specific page. Table layout is extremely regular, so once you've started parsing the table, you can infer a lot about the rest of it. Consecutive table rows/cols have much more in common than consecutive divs do.

Also, the previously mentioned point about browsers being incapable of rendering page content until the entire markup is downloaded still stands.

That hasn't been true since Netscape 4. One of the key design goals of Mozilla's Gecko engine was that it wouldn't limitations like that. I don't think IE ever had that limitation.

Re:Today is NOT a good day to die.

[8-bitDesigner]

Table layouts may be regular, but they're certainly not terse; a virtue when dealing with a limited connection.

A standard website content cell (as you'll find on any eCommerce or Smarty Tag-esque site) looks like <table<tr><td>(content)</tr></td></table> compared to a simple <div> which could easily be used in its place. With a dozen or so include files looking like this, the overhead on your average eCommerce site starts to add up pretty quickly.

As far as the table rendering limitations being lifted as early as the first Gecko browsers emerged, I hadn't heard of that, though it does surprise me somewhat. Anecdotally however, I do see table-based sites loading more slowly, which makes me wonder if lean markup is quicker to load than I'd previously expected

Re:Today is NOT a good day to die.

[mabhatter654]

please...

people will download Xvid xx codex or WMP updates 20 times if a page nags them, they'd download endless versions of Flash or Acrobat reader for minor features... and you're worried about nudging people to get Firefox. don't get started on IM, toolbars... and all the crap that people click on.

I understand the need to make checkout easy and I wouldn't do anything to affect the basic transaction part. But I'd bet if you could study your logs more closely, you'd see that people browse for a while, but don't actually create an account that lets you track them until right before they've created a cart and are ready to buy.... in reality you're probably taking 12 minutes just to take down CC and shipping info AFTER the product is already picked out.

Look at it this way, if you nudge for firefox you can also trim down some browser testing because it works on all the major platforms and almost all the minor ones... and compatibility between Firefox and opera or safari is a whole lot easier than IE.

Think of our bottom line!

[Wayofthebit]

I get the feeling that the W3C and these three businesses don't really give a damn about the web or its users. All they care about is the bottom line or justifying their very existence.

From reading their faq and some other articles. It seems they are saying they don't believe in using XML on the web. They are willing to support the cludge use of HTML and XHTML in a more standard way. However, they never intend to become complete XML solutions. I thought this was why XHTML was created in the first place. To begin the transition to complete XML solutions on the web. If they never intended to go the distance why have they waited so long to tell their users?

In the end it just sounds like they want to keep things the way they are now. Just try to agree on a better way of supporting the various markup we have now. They've had years to get HTML to be consistent. Yet, they've not been able to acheive this seemingly simple task. Why would I believe HTML 5 to be any different? XML is supposed to be more precise and standardized. Perhaps that isn't the case, but they sure as hell waited long enough to tell thet rest of us.

God Save Backward Compatibility

[The Queen]

Perhaps you'll be kind enough to take the phone calls from my clients and explain to them why the pages they've been refusing to let me completely overhaul for the past 5 years, NOW have to do so, because the Internet broke them? :-)

(All this stuff is moot where I work. Non-profits don't have the funds to upgrade ANYTHING, therefore, I fudge what I can and say "no" a lot.)

Why HTML5 rocks?

[porneL]

<!DOCTYPE html>
<meta charset=utf-8>
<h1>Hello world!</h1>
<p>This is a complete, valid HTML5 document

and it does work in current browsers as intended, even in IE6.

Re:Why HTML5 rocks?

[Excors]

Not quite valid – title is required. But I think the removal of the copy-and-paste doctype/meta strings (and script/style type, etc) is definitely nice for anyone writing pages by hand.

Ugh...

[psykocrime]

Ugh... HTML 5 is the LAST thing the Web needs. That just works to perpetuate mistakes that
we've been forced to deal with for 15+ years now... and holds back adoption of XML formats
that are much easier to process and much more amenable to creating a Semantic Web.

Retire HTML and let's get XHTML2 out the door and get browser support for it... that's what
the Web needs.

Re:Ugh...

[jandrese]

This is of course assuming the Semantic web is a realistic (or even good) idea. I'm still not convinced it won't require some sort of hyperadvanced AI to deliver on the promises that the Semantic Web advocates have been talking about for years. We all know how fast AI research has been moving for the past 30 years...

Re:Ugh...

[Shados]

Agreed. I'll actually say that, with a realistic implementation of CSS that reflects today's needs (web APPLICATION, not just web PAGES), XHTML 1 would be okay... In the end, the important part is being able to use a standard XML parser to parse validated markup, instead of "tag soup parsers".

Once we can do that, we're good to go. The rest is just icing on the cake.

WRONG!!

[mabhatter654]

Any serious team should kick IBM, Adobe, and Microsoft out. Period. Those companies are the ones that wrecked the current W3C specs by bloating them up with "good ideas" from their established products, then not doing good implementations. MS was in meetings for CSS2 and XHTML, way back in 1999 and they have yet to properly support it. The mother of all W3C specs is SVG... the committee bit when Macromedia and Adobe wanted everything + kitchen sink, but the spec is so ambiguous and bloated nobody can implement it.. worse browsers don't implement the SAME features so it's even more pointless.

I'd like to see JUST browser makers and web designers in on the next specs. I under stand TBL (father of the web) doesn't like the idea of "web apps" over semantic documents, but the case is lost. The biggest thing is that the W3C doesn't actually make a fully useful browser of their own... they should defer to those that DO make browsers and those who design web pages and create a spec that's 100% useful and implemented rather than "pie in the sky".

Re:WRONG!!

[VGPowerlord]

The biggest thing is that the W3C doesn't actually make a fully useful browser of their own...

They don't?

(Note: I haven't tried Amaya, so I don't know how well it works.

Re:WRONG!!

[mabhatter654]

Amaya is cute, but for surfing it's barely functional. It's got some neat features that you can edit documents and add some cool DTDs... but it's support for ACTUAL web pages isn't that great. And it doesn't support the "hard stuff" that real browsers do. It's a nice prototype what the W3C wants for a semantic browser, but not useful for actually browsing.

CSS is a failure, as is much of "Web Design"

[Ralph Spoilsport]

Adobe cooked up PostScript. Theoretically, you could "read" PS code. It was hard, but not impossible. Within a few years this PAGE DESCRIPTION LANGUAGE was made simple and invisible by programs such as Illustrator, FreeHand, Fontographer, then Pagemaker and Quark as well as other apps that are gone and largely forgotten (ReadySetGo anyone?).

You place an element on a page. size it, etc. and you have NO contact with the code underneath, and frankly, you DON'T want to deal with it. It's messy and complicated.

Now, HTML was cooked up YEARS ago, and the closest we have to Pagemaker/Quark is Dreamweaver. Brilliant. And placing elements on a page is such a hack job between browsers that an entire industry of useless coders have sprung up to "take care of that" for us - CSS specialists who demand serious dollars to do something that shouldn't even be handled by humans. And WHY is this so?

1. Microsoft Their insistance on being non-public standard compliant and shoe-horning more crap into their browser and DOM for IE(x) has been a monstrous thorn in the side of web developers everywhere. At the same time, it is this incompatibility that gives CSS specialists and web designers/developers a job. Still, this is not a happy situation, and it is not going in a useful direction (HTML 5 will be gleefully ignored by Redmond, and the complexity of the resulting situation will only give more work to more CSS/AJAX specialists.

2. Fiefdoms The resulting incompatibilities that create the need for specialists actively works against finding automated solutions. If web design was reduced to the level of Adobe InDesign and web development was made as simple as visualBasic, then much of the "Web Industry" would disappear. Thousands would lose high paying jobs. I nreality, they (and this means YOU) are nothing but parasites subsisting on a faulty broken technology. Fix the technology and the cost of development would gradually collapse. Insisting that a web designer should know code would be seen as absurd as insisting that a type designer know how to read PostScript or raw TrueType instructions.

3. Flash et al. It seems much of the web started as one thing and ended up another.

Tables were built for tabular data, they soon became the structure by which a page was architected, as it put things in a specific place in page that was pretty much the same across browsers. And that is still the case. If I'm going "whip out" a page with a variety of elements arranged in the page, I'll use a table. It's faster and easier and it works. It's not as flexible or useful as CSS, but it works. With CSS, you spend huge amounts of time tweaking crap to appear across browsers. Still, Tables are old and not as flexible, and have been pressed into doing service they weren't designed for.

Same with CSS. It was developed to make things all purty-like. Now it's used for page layout and element placement - WAY beyond it's original mandate, which was taken from Desktop Publishing (stylesheets).

Flash was just a way to do spline based illustrations and animations on the web. When it was clear Flash could do much of the basics of what Director could do in a tiny fraction of the footprint, they began "directorfying" Flash, and shoehorned a Lingo into it, known as ActionScript. It is now a full blown frankensteinian disaster that is considered a "development platform", which is a cruel and misdirected hoax.

The examples are many and continuous. The "web" is a hack job. It is a slow moving train that has left the tracks (IE5 did that), and is slowly dying in its own complexity (of CSS, XHTML, AJAX, etc. hackery) as it rolls in excruciating slow motion off the cliff.

And now that the very livelihoods, mortgages, and private schools for the kids are DEPENDING on this complexity, the only logical conclusion is increased complexity, resulting in an ever higher range of exclusivity, casuistry, and sophistry. It will die, replaced by a lower context system, and when it does, a lot of people are going to get hurt. And, given the nature of the audience on /., it will mostly fall on their shoulders.

RS

Re:CSS is a failure, as is much of "Web Design"

[Logic and Reason]

You're missing a major reason why HTML hasn't gotten the kind of drop-dead easy WYSIWYG editors that Postscript has: web pages typically have dynamic layouts and, more and more often nowadays, interactive elements. Postscript is designed to show static content in one way and one way only, which makes it MUCH easier for software to deal with. If that were all we needed from web pages, we'd all be using "index.pdf" now.

Re:CSS is a failure, as is much of "Web Design"

[Ralph Spoilsport]

I know what you're saying, but that's my exact point - HTML has no business being extended into dynamic activity. It's all hackery. And my warning is that it WILL collapse.

Re:CSS is a failure, as is much of "Web Design"

[TeknoHog]

You're missing the most important idea of HTML. It is about information transfer with logical markup (e.g. "this is a heading") with little regard to presentation details. It makes sense because the user agent (Ordinary web browser, cellphone, etc.) can decide how to present the information, but you obviously have less control on the actual looks. Conversely, PS is meant for the exact replication of content, but it's less flexible for viewing on different devices.

Incidentally, many web designers fail to realize this, which has led to many of the current problems. They are trying to use HTML where PS would be much more appropriate.

Re:CSS is a failure, as is much of "Web Design"

[magixman]

You paint a colorful picture that cannot be faulted in the main. Not really unlike an honest assessment of say the war in Iraq circa spring 07. So where do we go from here? We all want a ubiquitous, simple, clean, cross-platform way of developing rich applications without the need for guru charlatans and divining rods. It just ain't there. So unless you want to be as John Mayer says, "Waiting on the world to change", just get on with it.

Re:CSS is a failure, as is much of "Web Design"

[karlto]

I know this is a late addition to the discussion, but I just want to congratulate you on posting the only comment that demonstrates an understanding of the fact that strict layout doesn't belong in web pages. It'd be nice if just a few more web developers understood this and stopped complaining that "CSS can't produce table layouts".

Re:CSS is a failure, as is much of "Web Design"

[PSdiE]

"If web design was reduced to the level of Adobe InDesign and web development was made as simple as visualBasic, then much of the "Web Industry" would disappear."

LOL! So the entire web development industry (of which I am a member) exists solely to hand-code HTML/CSS? I beg to disagree. Granted, battling with browsers differences, broken CSS support et al saps a disproportionate amount of our working hours, but professional web developers do rather more than churn code!

• Design of the look & feel of the website - most home-brew websites look awful due to lack of design expertise; no automated tool is going to create a great looking bespoke design to your requirements and branding.
  
  
• Search Engine Optimisation - a constantly changing black-art with an entire industry dedicated to it; your typical amateur webmaster cannot be expected to keep up with best practice for delivering decent search result page (SRP) performance.
  
  
• Functional requirements capture/modelling and Usability design - in our experience, clients often have a rough idea of what they want, perhaps a rough navigation plan, possibly even a full site spec. 9 times of 10, however, these plans are full of holes and designed from an internal rather than user perspective (= poor usability/sales conversions). A professional developer will get to the bottom of what you REALLY want and will translate this into an effective site structure and feature set.
  
  
• Graphic design/editing? Copywriting? Back-end programming code? Database design (inc data modelling -> table design, DB config/tuning)? Client-side scripting to enhance usability when enabled? I could go on, but I have work to do - around 25% of which is HTML/CSS coding ;)

I beg to disagree that a glorified copy of FrontPage would kill off the web design/development industry. We want more ubiquitous, bug-free standards more than anyone; clients see little value in time spent overcoming browser deficiencies, so this is one of the lowest profit aspects we handle.

BJ

Woah! Slow down! Seriously....

[nilbog]

Come on guys, we need to slow this down so we can give Microsoft a chance to catch up to what has already been done. Don't worry, they should have IE up to speed by the end of the decade - THEN, and only then, can we start talking about ridiculous things like upgrading HTML!

Re:Forget HTML, it's CSS that's Broken, deal with

[GigsVT]

You are very correct. CSS gets much more hacky than "legacy" layout if you try to do any significant layout with it.

I tried to make a simple 3 column table with CSS only. After struggling with that for an hour, I said fuck it, and put an old style table in there. It was much easier.

Okay, but....

[Kadin2048]

Okay, but just to play the devil's advocate here, why should that be part of the page design, and not a feature of the user's reader, perhaps as a configurable option?

It used to be pretty standard for people to customize their browsers in order to change the text, link, followed-link, background, hightlight, and other colors; why does the page designer necessarily know better than the users themselves what the user wants?

We've moved a long way over the past few years towards making the browser into a generic 'portal' that simply displays whatever the web developer wants to toss up on it for the user to look at; frankly it's very television-like.

However, there is a completely different conception of the internet where the pages should be marked up as generally as possible, and the user's browser should then choose how to display the information in a way that's meaningful to the user. It would probably mean that "your Internet" wouldn't look anything like "my Internet," but there's no inherent reason why that's bad. We've grown to treat it as if it is, but that's only because we want the web experience to be like flipping channels on a TV, where your Discovery Channel looks exactly like mine.

Re:Okay, but....

[Bogtha]

why should that be part of the page design, and not a feature of the user's reader

With CSS, it can be both. The "C" in "CSS" stands for "Cascading". The style rules suggested by a web designer cascade together with style rules preferred by the user.

As for why it's a good idea for web designers to have this feature, well it's for the same reason any styling is useful for the web designer to have. Because although the user should have the final say (which CSS allows), it's difficult to predict exactly which presentation is most suitable for all the pages you are likely to encounter in the future. The web designer that produced the page, on the other hand, knows the context in which the information is being related and has a good chance of being able to come up with a more appropriate presentation than something that is generic to all pages.

However, there is a completely different conception of the internet where the pages should be marked up as generally as possible, and the user's browser should then choose how to display the information in a way that's meaningful to the user.

Well if that's what you want, then pages being "marked up as generally as possible" is exactly the opposite of what you want. If you are relying on the browser to handle all presentation, then what you need is specific, accurate markup, not general stuff.

In any case, the two goals are not mutually exclusive, and CSS has been handling this for over a decade. For those users who like to be in control, they can configure their browsers to ignore author-supplied stylesheets. Everybody else can take what is suggested by the web designer, or configure their browser to make only minimal changes (e.g. font size).

Re:Okay, but....

[Stormx2]

In an entirely functional world, what you are saying would be true. I designed in XHTML 1.1 / CSS frequently, and what you are saying is the direction that the W3C are taking (X)HTML

The whole point of XHTML is that it is accessible. There isn't any styling in it, none at all. That means that if a user chooses, then they can apply whatever markup they like. That is the whole basis of csszengarden. Accessible doesn't only mean for odd devices, it means for odd browsers and custom(ised) browsers

Getting onto what you were saying about the use of the designs. A few points:

1. Users associate a design, like they would a logo, with a company. Familiarity
2. A visually attractive website does increase sales / whatever it is for.
3. Do you honestly trust IE and FF to get along if the styling was left to them?

Oh, and read up on RSS. Every website should have RSS imho. It is basically what you are getting at.

Re:Okay, but....

[Anonymous Brave Guy]

It used to be pretty standard for people to customize their browsers in order to change the text, link, followed-link, background, hightlight, and other colors; why does the page designer necessarily know better than the users themselves what the user wants?

I'm not sure it was ever true that most people customised their browsers in that way. In any case, the better web sites now get people who know what they're doing to work on the graphic design. It is a very good bet that a professional graphic designer/typographer will produce a page that looks and works better for the user than whatever most users would come up with themselves. This is true whether or not the untrained user actually realises it.

Re:Okay, but....

[mabhatter654]

Even the W3C lost that argument... that's why we've got this article. The founder Tim Berner-Lee wanted documents to be portable and generic. The majority of web designers and users want "magazine" like content tied to databases. Personally I think a new data type is in order. Stop bolting to the old "page" format and create a WEB:// url that looks a lot like HTML and XML but follows application rules directly.

by the way Slashdot is an Excellent example of what CSS can do. if you turn off styling you can see a basic, boring page that is neatly formatted, if you look at the DIV tags you can even figure out what different parts do and turn them off!!! Also the upgrade to CSS pages SAVED several Kb per page download by allowing browsers to properly cache the .JS files and images across many slashdot pages.

Re:Forget HTML, it's CSS that's Broken, deal with

[amorsen]

I can only say that I agree with you entirely. The CSS box model is completely broken. It can only be made to "work" by generous sprinkling of clear=left etc.

Frankly I would prefer something like LaTeX. XML'ify it if you must. Not that TeX isn't broken itself, with all the fixed limits it has. Those would be easy to fix though, if TeX was unfrozen.

Did anyone read the replies?

[purpleraison]

I read the request which was posted in the lists, which was interesting. The responses from Doug Jones, Dao Gottwald, Henrik Dvergsdal, and particularly Maciej Stachowiak were more insightful though, and from a web designers perspective these are important things to understand.

It seems a number of the responses on Slashdot with respect to this request are negative, but both the request and responses provide a meaningful first step in consolidating modern web standards, and giving proper attention to things that no longer serve a purpose.

For instance, instead of eliminating the ungodly 'blink' tag, the concept is to allow the receiving things like this, but not sending elements that are being phased out. This way nothing breaks, and the web can continue to move forward.

It is also interesting to note that one concern is to take the unique important elements from each browser, and include it in the standards, 'so it doesn't need to be reverse engineered'.

Microsoft owns the web

[QuietLagoon]

No advances will be allowed unless they are sanctioned by Microsoft via Internet Explorer.

Re:HTML5 === steaming pile of shit

[wootest]

Are you seriously suggesting that XML's error handling is ideal - that the correct way, after 17 years of accepting non-perfect content in web browsers is to inform readers of a page that a href attribute that contains an & that's not part of an entity like & that the page is broken and then quit without showing any information? XML is awesome for programs reading data produced by other programs. Draconian error-handling is appropriate in such scenarios. However, way too many people are hand-writing HTML - and it's way too hard to generate sensible HTML - to be able to make that plausible.

HTML5 defines and codifies separate HTML parsing rules, mostly backwards-compatible. You're able to download a HTML5 package and parse almost any site on the web today - are you willing to bet you can do that with half the XHTML pages? (Even if you still want to use XML, you can just write XHTML5, which is HTML5 with XML parsing.)

WHATWG's two specs specify both the HTML markup and the DOM. The two go hand in hand - that's why it in comparison to HTML 4.01 or even XHTML 2 looks like a "mish-mash of markup and javascript", because it's just not solely a markup spec anymore. If there's going to be a new HTML spec, it deserves to be a solid and holistic spec. The least you can do is include the DOM model inline, and not just publish a different spec, by a different working group, and brand it as "DOM HTML Extensions", or what have you.

I think this is great

[drix]

I haven't read TFA or even ever heard of HTML 5, but I really hope they get it right this time. Some many things in XHTML and CSS just leave you scratching your head, especially if you come from a print background.

• Why are columns so hard? Why can't I just write <column>::stuff::</column>? This is like the the most common use case in all web design, and the current implementation completely whiffs.
• Why do floats suck? Why don't they automagically cause their containing box to expand? I read the explanation for this once, somewhere, but I can't remember it now. And it just seems silly.
• Why can I only have one background image per block? Or why can't I specify a bunch of "adjoining" images, so I don't have to make five nested div's every time I want to add a drop shadow?
• Why can't I vertically align things (not just text) in a block? Ugh.

And so forth. Certain other things that other people have called for, I'm more agnostic about, like built in support for drop shadows and rounded corners, but there'll be no love lost on my part when they finally replace the current standards.

Re:I think this is great

[BenoitRen]

I can answer a couple of your questions.

Why do floats suck? Why don't they automagically cause their containing box to expand?

Floated elements are outside of the document flow. Hence why they're called floated elements.

Why can I only have one background image per block? Or why can't I specify a bunch of "adjoining" images, so I don't have to make five nested div's every time I want to add a drop shadow?

Image borders are coming in CSS3.

Re:I think this is great

[belg4mit]

WTF? Whay are you people modding *questions* about *CSS*
(from somebody who isn't even aware of HTML 5) "Insightful"?!
"Interesting" *at best*, but actually OT.

Re:I think this is great

[argent]

Columns shouldn't require CSS, or table fakery. They need to REALLY separate layout from content.

You should be able to define the flow of running text independently of the text itself, so you neither have to guess where to put the column breaks or use floats to fake columns.

Re:I think this is great

[belg4mit]

>They need to REALLY separate layout from content.
That be the general definition of CSS (for better or worse).

As for the rest, CSS3 requires none of said hackery. Of course, nobody's actually done it yet;
fucking W3C takes half a decade to decide something. And no, -moz-column-width etc. are not
acceptable. Who the hell thought it was a good idea to prefix standards to be as fucking
proprietary extensions? So you have to write -moz-column-width, -webkit-column-width, column-width
to cover current and future implementations.

Re:I think this is great

[argent]

That be the general definition of CSS (for better or worse).

CSS separates style from content (that's right there in the name, cascading style sheets), it doesn't address layout at all, which is why people using it for layout have to come up with horrible hacks with floats and the like. They're no better than tables, and I'm glad -moz-column-width is ugly and prefixed and not a standard, because it's too damn specialised. Reminds me of ... too bad that wasn't <-mosaic-image ...> so there was a reason to switch to <fig>...</fig>

Re:Woah! Slow down! Seriously....

[Billly Gates]

More than likely they will have their own incompatible version of html5 and will make sure Frontpage includes these new tags by default.

Then it wont matter. I hate monopolies and this is the reason. At least when Netscape tried netscape specific tags IE then came into the scene to force compliance.

Re:Woah! Slow down! Seriously....

[Shados]

Funny enough, the upgrade of Frontpage (Microsoft Expression Web) actualy renders (in its wysiwyg) html and css quite correctly. So its always amusing to do some more advanced CSS (mind you, advanced from IE's point of view. We're talking basic stuff like min-width or display:table-*) and have it work perfectly in Expression Web, then opening it in Opera or Firefox, and have it work exactly (or well, as exactly as wysiwyg will work). Then opening it in IE (especially 6, obviously) and it breaks horribly.

This is really a place where Microsoft is a 2 headed entity. The web development team(s) (asp.net, their ajax team, microsoft expression, the next version of visual studio, etc) tend to, for the most part (at least recently) work toward standards, cross browser stuff, etc. The browser team though... I guess they're doing their best while being whipped by the people who sign their paychecks.

Re:HTML5 === steaming pile of shit

[leighklotz]

>Draconian error-handling is appropriate in such scenarios. However, way too many people are hand-writing HTML - and it's way too hard to generate sensible HTML - to be able to make that plausible.

I find it fascinating that people are willing to accept string syntax checking hand-written for JavaScript but not for HTML.

Re:HTML5 === steaming pile of shit

[wootest]

JavaScript is a programming language. HTML is a markup language.

All things being equal and HTML starting out fresh, I guess you could make a case for a "strict only"-policy. We're not starting out fresh though.

Oh boy! Another "standard" to ignore

[walterbyrd]

Face it, as long as browsers work with HTML4, nobody is going to care whatever "standards" are dreamed up by whoever.

Please understand, I am not saying these standards *should* be ignored, I am saying they will be ignored.

All I want...

[jonadab]

... is to be able to put block-level elements inside of paragraphs. That's it. Apart from that, XHTML 1.0 is good. That's the only change I want.

CSS is another matter. I can think of a few dozen improvements I'd like to have there. OTOH, even the best browsers are still trying to catch up with what's already specified, so having anything more specified is unlikely to have an immediate impact.

Re:HTML5 === ***

[leighklotz]

>All things being equal and HTML starting out fresh, I guess you could make a case for a "strict only"-policy. We're not starting out fresh though.

(BTW, I don't like the subject line of this thread (I didn't create it) so I changed it to ***.)

This is another issue I don't understand. If you visit a web page, and it requires the Flash plugin, or if it requires JavaScript, or if it works only in Internet Explorer, or if it requires Java, then either you get the stuff and it works, or you don't get it and it doesn't work. There's plenty of ways to find out if a client supports something and serve up one version or another. The same is true for other markup-based technologies such as SVG; either you get the SVG content or you don't. But there aren't people running around saying the entire web is broken because there are pages with SVG in them.

It's not that hard a task to add SVG to Firefox once you know how to implement SVG; in fact, it's been done. It's not that hard a task to add recognition of XHTML2 markup if someone wanted to do it. And XForms is in version 0.7, heading towards a 1.0 release in Firefox as well. None of these things break the web. If you want to use them, use them. If you don't, don't. But why must you run around telling other people not to implement them? What is it that you fear? I think it's the lack of mystery.

Modularizing HTML so that it's possible to intermix SVG, XForms, and other markup and get predictable results takes a lot of the mystery out of writing web browsers. And mystery is important if your business is writing web browsers, (i.e. for the mobile phone market) because if you could read the specs and write software and sell it, then there'd be less money to be made for the established players.

Re:Forget HTML, it's CSS that's Broken, deal with

[Phroggy]

Thank you.

I don't really care what they do with HTML. As long as support for the old versions doesn't go away (and as long as you include the appropriate DOCTYPE there's no reason why it should), I'll always have the option of using the old version if I like it better, or using the new version if they make real improvements. I use the W3C validator, and a Firefox plugin to do the same (although the Mac version seems to be broken at the moment). HTML is great. I'm sure they'll make it better. Fine.

But CSS is a nightmare. I've got two books on CSS on my bookshelf; neither seems in any way comprehensive, and I don't think it's the fault of the book authors. My horribly broken stylesheets always pass validation anyway, because the syntax is fine, they just don't work the way I wanted. I'm not looking forward to building a new site a client wants me to make, partly because I know I'll have to build a new stylesheet for it. I love what CSS is capable of doing, I love the concept of using a stylesheet instead of splattering layout and style markup all over the HTML. But CSS, it its current form, is painful.

I want a AJAX tag :p

[VGfort]

Do some web 3.0 stuff for me

<curvedcorners>Bling Bling</curvedcorners>

and maybe they will implement the </sarcasm> tag, no opener needed :p

Re:Forget HTML, it's CSS that's Broken, deal with

[angryrobot]

Here's one method:
http://alistapart.com/articles/holygrail

Here's another:
http://www.glish.com/css/7.asp

But yeah, it's hard. Lot's of people have found solutions to the problems, though. Even if it is cumbersome, I think it's better than visual markup.

CSS is an adjunct

[tknn]

Here is a simple study. Turn off your css. You should be able to see a page that still makes logical sense. If you don't then you shouldn't be designing websites, because you have no idea how to properly code HTML semantically. That means using H1 tags instead of [span class="heading1"] and all the other nonsense I have seen out there. HTML is creaky and needs the work. But nothing says that you can't just turn off the css functions and customize pages the way you want, except for idiot-coders.

Re:microsoft?

[MP3Chuck]

MS is a member of the W3C.

That has worked out real well, eh?

Blinky?

[Tavor]

"Both HTML and XHTML are in sorry need of removing deprecated items" ...I'll just be happy if they remove the blink tag.

Re:Blinky?

[argent]

I'd rather they removed the tag.

Re:Block elements in paragraphs?

[jonadab]

You're missing that I want to be able to put just ANY block-level element inside a paragraph. Say, for instance, an ordered list. Or a div, of a certain class. Or a table. Or whatever.

The workaround I currently use is <div class="p"> instead of just <p>, but it's annoying to have to do that, and it's contrary to the principle of semantic markup. I have never heard any explanation why block-level elements inside of paragraphs were ever disallowed in the first place. In non-web contexts, people put things like bulleted lists and indented addresses and so forth in the middle of paragraphs all the time, and have done for decades.

I've heard that XHTML 2 is planning to fix this, but it's been a long time in coming, and XHTML 2 also dorks around unnecessarily with a lot of other things, e.g., re-introduces the concept of frames, which I was hoping we'd done away with for good, makes unnecessary and not-backward-compatible changes to the handling of forms, and I don't know what all else. It's a lot of changes, and browsers will take years and years to implement it, even once it *is* made a formal recommendation, which at the current rate of progress could be a while. So it will be years and years before we can actually use it on the web.

What I really want is just an XHTML 1.5, which should allow block-level elements inside of paragraphs, with very minimal (if any) other changes from the previous version. I'd like to have it be made a formal W3C recommendation a couple of years ago, if possible, so that browsers could get it implemented soon and we could all get on with actually using it.

The other thing I want is the ability to use SVG in img elements, something like this:
<img src="foo.svg" alt="Foo" title="Dig that foo!" width="50%" class="floatright" />

But that doesn't require any changes to HTML (except maybe to allow inches or whatnot as units on the image width and height, but that could be added later). Browsers could add support for using SVG images like this *now*, if only they would.

And yes, I understand the theoretical advantages of embedding the image markup straight into the XML document using namespaces, but in many cases they're largely theoretical. In practice, that *usually* isn't what I want to do.

Multi-column: another special-purpose hack. Sigh.

[argent]

You REALLY want to use CSS for layout, you need a new container type.

Call it box or flow or slot, what it does is define the layout of the places where text WILL go. The text is in a separate div with a target that specifies the box to flow it into.

That way you can define a set of boxes around a picture, all with the same name, and then just feed text into it. The text will start filling the first box, then overflow into the second, and so on. When the text reaches the end of the last box the boxes start expanding to accomodate the text, unless they have the an attribute that defines them as fixed-size. The boxes define the layout, the divs define the text to go into it, and spans define the style of the text.

Re:microsoft?

[korisu]

Do you actually read these articles, or do you just scan through them to find the part where you can lash out against Microsoft? A lot of what you're saying is true... as of 1998, but then again, they were working on creating the features that are used everywhere now. Regardless, I take it you've never touched XSLT or MSXML. If you had, you would have realized that their XML processor is one of the fastest and most robust for XSLT 1.0 out there today... because they were making it against a standard that made 100% complete logical sense, and they didn't have to support tens of thousands of corporate-level developers' broken code. But that is the case with IE and HTML, so you're better off bitching at the developers who write the broken code in the first place.

Validation...

[cyclomedia]

And therin lies the problem, the w3c make a big shouty shiney deal out of "validating" HTML and CSS markup in pages - wether or not it actually produces desirable output in the shitty attempts at support by ALL the browser vendors - and not copyrighting the terms "HTML" and "CSS"* and then not allowing browsers to claim to render them unless the BROWSERS ITSELF CONFORM TO THE SPECS

*yeah i know it's too late for that now but "HTML 5" could be called "WML : Web Markup Language" instead, whilst being new and buzzword-tastic, M$ could not then release a "WML Support Upgrade" for IE7 unless the w3c said so.

too bloody simple, obviously

Re:HTML5 === steaming pile of shit

[wootest]

Our stances on whether XML's strictness is good or bad *for the web* is obviously different. I do think it's useful to be strict when handling strictly-formatted documents, as most XML documents are. HTML documents, beyond html, head and body tags, don't really have a strict structure to follow, just rules about how the tags will be nested, and therefore I think it's a really different situation. I will point to Mark Pilgrim's "Thought experiment" to explain my side, but I think it's a waste of our time to continue to debate this if your stance is set in stone. (As an aside, that article ended up converting John Gruber - the creator of Markdown, which you mentioned - to Pilgrim's side.)

There's also a philosophical side: *writing* HTML this far has been about firing up Notepad and a web browser. (Uploading and hosting is a different matter, but I'm talking about writing.) Requiring xmllint to write HTML isn't the web I want.

XHTML 1 is HTML 4 reformulated in XML syntax. By definition, it's backwards compatible. And no, I mean that HTML5's parsing is backwards compatible. Run a page, any HTML page, through an HTML5 tokenizer. HTML will come out right unless you are relying on browser-specific bugs, and there are allowances for XHTML void-tags with the / embedded. Google ran this tokenizer on a billion web pages to scrape them for attributes and tags. It works.

Regarding the XML 'noscript' point, the spec offers up this note: "All these contortions are required because, for historical reasons, the noscript element causes the HTML parser to act differently based on whether scripting is enabled or not. The element is not allowed in XML, because in XML the parser is not affected by such state, and thus the element would not have the desired effect." Does this mean you actually would like to be able to write invalid XML?

Whether you like it or not, DOM manipulation is being used in tandem with HTML, and it needs to be defined somewhere. The spec is actually called "Web Applications", and it describes HTML5 and, additionally, the DOM that should be used to manipulate it and that's used to store it internally. It's also important to remember that the spec is for browser implementors as well as authors! You need not be proficient in the parsing or tokenization or DOM manipulation of HTML5 to write in it, just as you don't need to be proficient in the meaning of uppercase 'SHOULD' or 'MAY' as defined in RFC2119 to be able to use XHTML. HTML5 itself is still a markup language, just as ever, but it's not just markup that needs to be defined in the spec.

At the end of the day, the browser vendors that care about standards sat down and said "this is getting messy, what do we need to codify?" and put it in the same spec with HTML5. CSS2 and CSS3 are well-defined. JavaScript is well-defined as ECMAScript. The font tag is deprecated and irrelevant and doesn't help your argument one whit.

XSL:FO

[DragonWriter]

I WANT A REAL LAYOUT LANGUAGE!!!!!!!!

Wasn't doing a better job than CSS at providing that for a wide variety of media one of the big purposes of XSL:FO? Unfortunately, while there were a few proof of concept browsers early on with rough support for XSL:FO, mostly support for it seems, from what I've seen, to have gone all to tools designed for print/PDF production.

Re:HTML5 === steaming pile of shit

[wootest]

The DOM - or something like it - has to be constructed by the browser even when no scripting is involved whatsoever. Specifying it does not do any harm.

I have to say that I don't pretend to know all the background of the noscript case in particular, but if you believe that the explanation given to the special noscript XML treatment is bullshit, why would it even be in there to begin with? There's no reason effort should be spent shooting down XML in an asinine way without needing to adjust for either backwards compatibility, current established browser behavior or what the XML standard says - don't you think you're missing something? And if you're 100% sure you've got the right answer in this case, why not point out exactly what's wrong to the WHATWG folks themselves?

I have a tough time thinking that the canvas tag or the XMLHTTPRequest object would be invented in an HTML specification - yes. This is paving of cow paths - specifying things that are already widely implemented. The W3C, in their infinite wisdom, are *also* specifying things like it. There's already an XMLHTTPRequest specification.

All I'm advocating is that those writing XML write valid XML. Again, nowhere have I suggested parsing HTML using xmllint, we were discussing XHTML and I proceeded to answer your question in that context after explicitly noting your change of topic.

I did not catch this nuance. I apologize.

However, it did sound like you were shooting down anything that was *not* XHTML as valid backing for a new HTML standard. There's a W3C HTML working group now, and on their mailing list are two kinds of requests: people wanting their own tag or people wanting to adopt the Web Apps draft standard as a starting point. Am I amiss in thinking a third alternative - another good way for HTML forward - will not arise for the forseeable future? Why not provide constructive critisism for the HTML5 branch going forward instead of saying that they're all nuts?

I think I should say that I do not want XHTML dead - although I believe that XML's parsing sematics are holding back its tenability, because not everyone produce valid code all the timewithout XML libraries, and very few text editors have XML libraries. Like you say, if you can produce good XML, then XHTML may be better for you than HTML. I also do not think the Web Apps spec has got everything correct. Like you, I do not want the web to just turn into an application API. However, I do want the parts that are already there - like forms - to stop sucking. At over 120 printed pages, it's hard to agree with everything, but according to the browser guys themselves, this level of detail is what they want.

But what is "quite trivial"?

[Anonymous Brave Guy]

Bah, it gets easier the more often you do it. Two and three column layouts are quite trivial at this point in the game

That depends on your definition of trivial, of course. Relative to what people used to try, the more recent techniques are certainly a lot more concise in the CSS, I agree. And it's only taken nearly a decade for us to get from what people really did do trivially with tables to a vaguely transparent CSS approach that gets the same result mostly reliably. Hurrah!

So now think about other things that should be easy with good separation of content and presentation, but aren't. Here's a simple example: I want to write my text, duly marked up logically, and I want to tell a browser to flow it into as many 3–4" wide columns as will fit in my user's browser window to give even widths and 0.5" margins and inter-column spacing, or a single column for more narrow devices. Doing this in print would be pretty routine for any DTP package. Doing it in CSS... well, sorry, you can't, because it's not even close to powerful enough to express that kind of concept. The best attempts so far rely on Javascript hacks. And this is in a world where the web is one of the dominant communication media for millions of people, and where home user display hardware varies from a little 15" CRT someone's had for years to a funky new 24" widescreen TFT, not to mention all the mobile devices that have some web capability.

So, when I can get a two-column layout in CSS by writing "columns: 2" in the style for a DIV, plus any spacing options I want to set, then I'll accept that getting a two-column display is trivial. Until then, it's just less of a hack than it used to be, it still requires non-semantic mark-up, and it's still beyond most users.

Re:But what is "quite trivial"?

[8-bitDesigner]

And it's only taken nearly a decade for us to get from what people really did do trivially with tables to a vaguely transparent CSS approach that gets the same result mostly reliably. Hurrah! I lay the blame for that one a few notable browsers from Microsoft. The difference between Quirks and Standards mode is daunting from the start, but the hasLayout issue is just an outright bastard to troubleshoot.

So, when I can get a two-column layout in CSS by writing "columns: 2" in the style for a DIV, plus any spacing options I want to set, then I'll accept that getting a two-column display is trivial. Until then, it's just less of a hack than it used to be, it still requires non-semantic mark-up, and it's still beyond most users. Browser support, again. CS3 handles many of these features that people like you and I have been clamoring for, but again, browser uptake is lacking. It's a bit of a chicken and egg issue, as Mozilla doesn't seem keen to implement too many CSS3 features when the dominant force in the market is only now catching up to basic CSS2.1 features like "min-width".