Slashdot Mirror

← Back to Stories (view on slashdot.org)

Finally We Get New Elements In HTML 5

Posted by ScuttleMonkey on from the not-so-patiently-waiting dept.

An anonymous reader writes "Pure HTML enhancements hardly grew at all in the last eight years. Forward motion basically stopped in 1999 with HTML 4. Now the future looks bright. Recently, HTML has come back to life with HTML 5. Tons of new elements will be available for structure (article, nav, section, etc.), block semantic elements (aside, figure, dialog), and several other functions."

13 of 378 comments (clear)

  1. Excellent! by Anonymous Coward · · Score: 5, Interesting

    More tags for browsers to neglect to implement!

    On a slightly more serious note, it sounds like they're giving up on having most browsers support CSS styling of XML, and just adding new tags that serve no point other than being CSS targets. Semantically, what's the difference between:

    <div class="article">...</div>

    And:

    <article>...</article>

    Answer: Nothing. One is easier to type and less verbose, and the CSS selector rule saves a single character.

    1. Re:Excellent! by Conspiracy_Of_Doves · · Score: 5, Funny

      The whole point of a semantic tag is that it is machine parsable. A script that is interpreting the page will know what parts of the page is the article, which parts are the navigation, which parts are the advertisements, and so on.

      Actually, they need to put in an <ad> tag.

      --

      Technoli
    2. Re:Excellent! by LighterShadeOfBlack · · Score: 5, Insightful

      The idea is that an "article" is semantically different from other text. It's all well and good styling your text with <span class="header">, <span class="emphasis">, <span class="cite"> etc. to make your text look good on your webpage but that's no good for a computer that's trying to interpret your text in a meaningful way. By using semantic tags it should mean computers can do more in terms of searching and indexing the web to allow all of us to find what we want faster.

      --
      Spelling mistakes, grammatical errors, and stupid comments are intentional.
    3. Re:Excellent! by patman600 · · Score: 5, Insightful
      Because there is no standard. You could have

      <div class="article"> or <div class="main texty stuff">
      . If there is a standard, then things like screen readers will easily be able to divide the article text from a navigation section. Imagine telling your computer to read you the article, and not having to wait for it to work it's way past the navigation bar. Or skipping back to the nav bar if you are tired of the article half way through.
    4. Re:Excellent! by rhartness · · Score: 5, Insightful

      No, they shouldn't because it would be a waste of time. No web designer in their right mind would mark any thing as an object because, sure enough, as soon as it's implemented in an HTML spec, some one out there will right a plug-in to hide those elements.

      Web developers want their ads to be seen. They aren't going to make it easy for those ads to be blocked.

    5. Re:Excellent! by Bogtha · · Score: 5, Insightful

      Microformats are a good solution where a problem is domain-specific. HTML is extensible with mechanisms like the class attribute so that HTML doesn't have to include lots of element types that aren't useful to most people.

      But when something is applicable to a wide variety of situations, the right place for it is in the HTML specification, not as an ad-hoc extension. Otherwise, you could just make the argument for every element type under the sun being replaced with <div class="..."> or <span class="..."> . At that point, you're just using the class attribute as a bodge to avoid new element types, not because it's a good idea.

      Yeah, sure, it's nice that browsers don't have to be updated for microformats to work. But that doesn't mean it's good design to try to stuff everything under the sun into the class attribute. Sometimes the right place for something is in the HTML specification.

      --
      Bogtha Bogtha Bogtha
    6. Re:Excellent! by Xtravar · · Score: 5, Insightful

      And so how do advertising campaigns fit into this wondrous new paradigm where web developers supposedly have the competence and ethics to only put an article in an article tag?

      The fact of the matter is, nobody will use the damn tags correctly and then a screen reader will read a paragraph on Viagra before actually getting to content.

      More bastardization of already bastardized HTML... and even more new ways to fuck things up.

      --
      Buckle your ROFL belt, we're in for some LOLs.
    7. Re:Excellent! by Touvan · · Score: 5, Informative

      Page authors could use XHTML 5 (XHTML is allowed under the HTML 5 spec, which they call XHTML 5), and include an xsl style sheet that would convert these new tags to something useful in the older browsers which do not support the new tags (convert to ). That way, there is no need for users to upgrade. There are lots of other strategies for dealing with older browsers too. The answer doesn't always have to be "require users to upgrade".

      --
      http://www.unfocus.com/
  2. The most greatly wanted tag by Anonymous Coward · · Score: 5, Funny
    And, of course, the addition of the long overdue

    <dupe>http://developers.slashdot.org/article.pl?si d=07/07/20/1226235</dupe>
    tag.
  3. So do tags ever deprecate? by lonechicken · · Score: 5, Interesting

    Years from now, are we still going to see IE 10, Firefox 5, and Safari 3.1 support deprecated tags? (Or is it depreciated? Defecated?)

    It's like slapping on a shiny new paint job on your car, but the back seat is still full of old McDonald's bags.

  4. Announcing by Bluesman · · Score: 5, Funny

    The BRAND NEW HTML 5!

    Almost as good as TeX!

    --
    If moderation could change anything, it would be illegal.
  5. XHTML/HTML divergence by Animats · · Score: 5, Insightful

    What's wierd about this is that it goes off in a completely different direction than XHTML. Tags don't have to be properly closed, no namespaces, etc.

    A big advantage of XHTML was that the conversion to a parse tree was unambiguous. Why give up that at this late date? All this ambiguity breaks visual HTML editors. Dreamweaver 3 was closer to "what you see is what you get" than today's Dreamweaver 8.

    Consider, for example, a lone </br> that doesn't terminate anything. Most browsers today treat that as a valid break, not an orphan tag to be ignored. XHTML was supposed to end that kind of nonsense.

    The problem with XHTML has been that CSS layout was badly designed. "float" and "clear" just aren't a good set of layout primitives. Cell-based layout (yes, "tables") was a fundamentally more powerful concept. But it's not XHTML that's the problem. It's that the positioning mechanisms for "div" sections are terrible.

    Layout is really a 2D constraint problem. Internally, you have constraints like "boxes can't overlap", which turns into constraints like "upper left corner of box B must be below lower left corner of box A", or "right edge of box A and left edge of box B must have same X coordinate". Browsers really ought to do layout that way. Table layout engines come close to doing that. At least with tables you never get text on top of other text. "div" doesn't have comparable power. "float" and "clear" represent a one-dimensional model of layout, and that's just not good enough.

  6. Re:what happened to xhtml? by jalefkowit · · Score: 5, Interesting

    Yes. Kind of.

    There are currently to Working Groups in the W3C working on markup -- the XHTML working group, and the HTML working group. These are separate entities with separate memberships and separate processes.

    XHTML was originally intended to be the successor to HTML. But a couple of things that happened after XHTML1 "shipped" caused that to be re-evaluated:

    • The whole point of XHTML was that moving to XML syntax would open up new possibilities for user-agents: not just browsers (whose lives would be simplified by not having to deal with "tag soup" anymore"), but applications that would take advantage of already knowing XML to do cool stuff with the web. Only that never really happened; and because Microsoft wasn't on board, browser vendors still had to parse the "tag soup" anyway.
    • The XHTML Working Group went off the deep end and announced that XHTML2 would handle errors the way XML parsers are supposed to: by shutting down and throwing up an "Non-conforming document" error. Needless to say, this is not how the Web works today, and it threw a scare into millions of Web publishers who incorporate third-party content that they have no control over (like, say, ads) in their sites. They also proposed major changes to the syntax of XHTML2 versus XHTML1 to clean it up and make it more logical; which sounds great until you realize that now you have to teach those millions of web publishers a whole new syntax or their sites break.

    When it became clear that continuing down the XHTML path promised tons of heartburn for publishers and user-agent developers without much reward in return, people started thinking that maybe rebooting the HTML specification process wouldn't be such a bad thing. The W3C picked up the WHATWG's independent "HTML5" spec as a starting point, and that's where we are today: XHTML is for people who are comfortable with radical changes between versions of the spec and Draconian error processing; HTML is for people who want backwards compatibility and less strict parsing.

    --

    Read my blog.