Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
The Internet

Apple, Opera, and Mozilla Push For HTML5 384

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."
This discussion has been archived. No new comments can be posted.

Apple, Opera, and Mozilla Push For HTML5

Comments Filter:
  • by KenAndCorey ( 581410 ) on Thursday April 12, 2007 @12:35PM (#18703835)
    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.
  • by erroneus ( 253617 ) on Thursday April 12, 2007 @12:41PM (#18703953) Homepage
    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.
  • by moore.dustin ( 942289 ) on Thursday April 12, 2007 @12:49PM (#18704123) Homepage
    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 !
  • by ackthpt ( 218170 ) * on Thursday April 12, 2007 @12:50PM (#18704137) Homepage Journal

    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 Good News (Score:4, Interesting)

    by JordanL ( 886154 ) <> on Thursday April 12, 2007 @12:50PM (#18704151) Homepage
    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.
  • by LighterShadeOfBlack ( 1011407 ) on Thursday April 12, 2007 @12:53PM (#18704221) Homepage

    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.
  • by PapayaSF ( 721268 ) on Thursday April 12, 2007 @12:57PM (#18704285) Journal

    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:Firefox plugin (Score:4, Interesting)

    by TheRaven64 ( 641858 ) on Thursday April 12, 2007 @01:06PM (#18704419) Journal
    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).
  • by TheRaven64 ( 641858 ) on Thursday April 12, 2007 @01:09PM (#18704467) Journal
    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.
  • by richdun ( 672214 ) on Thursday April 12, 2007 @01:40PM (#18705013)
    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 ( []) 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.
  • by EsbenMoseHansen ( 731150 ) on Thursday April 12, 2007 @01:47PM (#18705147) Homepage

    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.


  • by ScentCone ( 795499 ) on Thursday April 12, 2007 @01:48PM (#18705157)
    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.
  • by Wayofthebit ( 1087569 ) on Thursday April 12, 2007 @02:13PM (#18705601)
    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.
  • by HTH NE1 ( 675604 ) on Thursday April 12, 2007 @02:18PM (#18705671)
    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.
  • by Ralph Spoilsport ( 673134 ) on Thursday April 12, 2007 @02:38PM (#18705991) Journal
    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.


  • Re:Okay, but.... (Score:5, Interesting)

    by Bogtha ( 906264 ) on Thursday April 12, 2007 @03:16PM (#18706717)

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

  • by wootest ( 694923 ) on Thursday April 12, 2007 @03:18PM (#18706747)
    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 &amp; 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.
  • by drix ( 4602 ) on Thursday April 12, 2007 @04:12PM (#18707679) Homepage
    Seeing as we're a mouse click away from forming our own judgements.. what's the site?
  • by WebCowboy ( 196209 ) on Thursday April 12, 2007 @06:22PM (#18710107)
    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!
  • 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.

Nothing ever becomes real till it is experienced -- even a proverb is no proverb to you till your life has illustrated it. -- John Keats