Slashdot Mirror


Finally We Get New Elements In HTML 5

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

22 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 Anonymous Coward · · Score: 1, Interesting

      I don't quite get why don't we just use XML. No need to wait for a predefined set of tags. If is missing, just write proper definitions and transformations. At this pace we're never gonna get fully semantical net.

    2. Re:Excellent! by Rorzabal · · Score: 2, Interesting

      The intent of making the article tag for accessibility is good. However, you know that people are going to start wrapping their advertisements in article tags, defeating the noble goal.

    3. Re:Excellent! by Bogtha · · Score: 3, Interesting

      Personally I think that's a bad idea, since CLASS carries style information, not semantic information

      This is a common misconception. The class attribute is intended for general purpose classification of elements, not merely as a style hook. The idea is that you classify your elements in a meaningful way (i.e. provide semantics), and then your stylesheets, scripts, etc, can use those semantics to manipulate the document in a useful way.

      there's probably already a ton of documents out there using, say [...] and their owners are gonna be really surprised when browsers suddenly start parsing those classes in new and unexpected ways.

      No, they wouldn't be parsed any differently, but they might be rendered differently.

      --
      Bogtha Bogtha Bogtha
    4. Re:Excellent! by nine-times · · Score: 2, Interesting

      I've always wondered whether there was any good reason these days to have the pre-defined elements the way we do. Is the current selection of elements really efficient and meaningful? Is there a good reason to prohibit people from making up their own elements?

      Back in the day, of course, web pages were pretty simple, and I guess it made sense that you would come up with a couple generic tags and assign each of them formatting. The "P" tag was a paragraph, and "LI" was a list item. Since pages were mostly plain text, and mostly paragraphs and lists, it made sense.

      But now? The type of data contained in a web page is so variable and people want to be more in control of layout and design. So sometimes, when I'm thinking about it, I start to feel like the whole thing is kind of weird. This is a weird debate for me, and I find myself having trouble articulating my thoughts.

      The main things I use are "A", "P", "H*", "DIV", "SPAN", "BLOCKQUOTE", "UL", "OL", and "LI"... I guess some others sometimes ("CITE", "DL", "DT", "DD"). But does that selection of default elements really make sense? Were they derived systematically? Even these new elements, were they derived systematically, or were they just pulled from what would go into a weblog or something?

      I don't know. The new elements seem good to me. There have been loads of times when I've had so many "DIV" tags with semantic classes that I've just wanted to make up my own elements specific to the data I'm working with. Yeah, I know it shouldn't be any harder to write "div class="article" vs. "article", but it would just make more sense in my own head and be easier to read.

      At the same time, I've spent a fair amount of time coming up with CSS that will just reset all the elements to a standard display (P and BLOCKQUOTE display as normal DIVs, no bullets on UL, H1 the same size as normal text, etc). Call me crazy, but sometimes it's just easier for me to start from scratch.

      Put these two ideas together, and sometimes I kind of feel like no web browser should have any default elements defined, and you should be able to make up any tag you want. The whole thing should be handled by convention, and there should be an agreed-upon default CSS file that you attach to get the display that would give you the layout browsers give you now without CSS. Hell, even include that CSS with the browser, but allow an easy switch in the HTML spec to disable the whole thing. Drop the "A" tag altogether and make anything a link if you include "href='http://example.com'".

      Then again, it seems like that might lead to chaos. I don't know. Sometimes HTML makes a lot of sense to me, and sometimes it seems like the stupidest set of conventions I've ever seen.

    5. Re:Excellent! by ptlis · · Score: 2, Interesting

      * However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.
      I'd agree with you if you'd been talking about XHTML 1.1. XHTML 1.0 SHOULD be served as application/xhtml+xml, but MAY be served as text/html when the compatibility guidelines are met. XTHML 1.1, however, SHOULD NOT be served as text/html. Even then, it's not a MUST NOT. But since it's a MAY for 1.0, i think calling it "incorrect" is a bit harsh. May, as you probably know, but just incase, is defined by RFC2119 as:

      Yes, I was talking about XHTML 1.0 (Appendix C is the location of said compatibility guidelines), it is widely considered to have been a mistake to allow developers to send XHTML documents with the wrong Content-Type because it causes subtle errors and defeats the purpose of using an XML based language (amongst many other reasons). My point is that when you serve XHTML as text/html you negate the point of using XML; You lose the ability to embed other XML languages (such as MathML or SVG) within your document, the page is no longer sent through an XML parser that checks for well-formedness thusly you're likely to introduce subtle errors without realising. When the day comes that all major UAs support application/xhtml+xml correctly and you decide to switch the Content-Type over there is a good chance of your pages not being displayed (works fine in IE but dies in Firefox due to crappy content negotiation) due to subtle errors in your markup that weren't apparent when your document was being parsed as tag soup.

      And for all these difficulties you get what? On the web today, with IE still having ~80% market share, XHTML offers no advantage of HTML4 and has a whole pile of potential pitfalls that a developer must take into account of and hack around. For example, <, >, & are all treat as markup irrelevant of where they are in a document when a page is treat as XML, causing problems with inline JavaScript blocks; as a developer you have to explicitly declare the contents of script block as cdata using <![CDATA[ followed by a closing ]]> with all Javascript between those two elements, however because the Javascript interpreter treats anything within a JavaScript block as code (and you're sending it as text/html) you have to comment them out so that when served as text/html to older browsers they don't try to execute the cdata declaration as code.

      There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.

      --
      There's mischief and malarkies but no queers or yids or darkies within this bastard's carnival, this vicious cabaret.
    6. Re:Excellent! by Lord+Flipper · · Score: 2, Interesting

      There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good [ptlis.net] content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.

      This is very interesting, and even though I dabble in XHTML and CSS and warping PHP templates, and have read a lot, I'd never considered sending different content types before. You know, the conventional 'wisdom' (I use that term loosely in my case) is all about hacks, and alternate stylesheets. But I worked with XML for years, and still hadn't considered the 'xml for these folks, html/text for those folks' idea. Time for me to start digging up my XSLT books and guidelines. Thanks for this.

  2. Can't we do all this stuff already? by Anonymous Coward · · Score: 2, Interesting

    Isn't it already possible to include proprietary tags in (X)HTML documents, then just use CSS to determine how they are presented (i.e. block level vs inline, positioning, color, etc.)?

  3. what happened to xhtml? by fredrated · · Score: 3, Interesting

    I thought xhtml was the next iteration after html 4, has that been changed?

    1. Re:what happened to xhtml? by Anonymous Coward · · Score: 1, Interesting

      Opera decided it wasn't in their best interest to make things easy for their competitors, so they and Apple got together and decided to enshrine IE5 bug-compatibility in a spec, then they started a competitor to W3C called WHAT-WG and announced they would now be running things there, so W3C invited them in to do their thing there.

    2. Re:what happened to xhtml? by DrSkwid · · Score: 2, Interesting

      W3 decided just to bring what-wg HTML5 into the fold, not give up on xhtml.
      The browsers relative level of eventual support will declare the winner after buch blood sweat and tears.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    3. 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.

  4. Good and bad at the same time by chriss · · Score: 3, Interesting

    On the one hand I welcome new tags like datagrid and menu, which will make HTML source easier to handle. Even though the increased complexity will make it harder to start with HTML. Most web developers still have problems with XHTML/CSS, advancing HTML will make that worse.

    Most likely this will lead to more automatically generated code, which in the long run (in combination with XML compliance) should lead to less buggy web pages and general browser compatibility. Which is a good thing. But somehow I think that one of the reasons HTMLs use has become so widespread (Microformats etc.) is simply because it was so easy to mess around with. Making it "better" might slow down innovation in these areas, which would be sad.

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

  6. Re:Do we need "MORE"? by Heian-794 · · Score: 3, Interesting

    One thing that should have been covered long ago in HTML but in fact stil requires CSS is vertical writing (such as in Asian languages). It's suprisingly difficult to guarantee correct display for any browser, even though word processors have had this essential feature for years.

  7. Re:Announcing by annamadrigal · · Score: 3, Interesting

    You beat me to it...
    Actually, seriously, one really serious omission from HTML and other "generic" markups which can be read widely is proper support for rendering of mathematical equations. It would be very useful for a lot of us if there was native HTML support for at least some of the more basic mathematical language that's contained in everything which gets written from day to day.
    The structure based nature of TeX and its variants seems self-evidently superior to that provided by HTML even with the various enhancements which have been retrofitted in recent incarnations and add-ons. Whilst TeX equally clearly isn't the right answer for generic web based content (and, indeed, it would be preferable not to have a standard which requires multiple parses to render anything useful) it seems that HTML really isn't what is needed and the more variations and versions that get implemented the more confusion there will be -- and the more deviation from these standards.
    That HTML is already ubiquitous doesn't seem a sufficiently good reason to insist that every new markup language should be a direct superset with ever more variations and multiple ways of achieving the same end. To start with, there's no future in a structure-based approach which makes it so easy to directly change the appearance of content -- think hold much easier it is to write in bold in HTML than it is to indicate that emphasis is required....
    What I think is needed, and surely must emerge sooner or later, is a no markup language based more on TeX and professional typesetting approaches than HTML which actually does things properly....

  8. May me redundant... by thatskinnyguy · · Score: 2, Interesting
    Did anyone notice the TeX style of some of those tags? i.e.

    <article><entry>etc...
    --
    The game.
  9. Re:XHTML/HTML divergence by PipianJ · · Score: 3, Interesting

    HTML5 is being developed hand-in-hand with XHTML5, which is merely the XML serialization of HTML5. Don't worry. You don't have to give up <br /> if you don't want to.

    That being said, I do believe that CSS still has fundamental problems that not even CSS3 seems to be solving, such as taking into consideration the growing use of HTML as an application framework rather than a document framework. The most notable issue of this would be the inability to center an object vertically in a viewport without Javascript to determine its size, which is a klutzy hack at best. The float: and clear: primitives, as you mention, are also comparatively weak (since you can't just float an element, have text flow around it, AND position it vertically), though CSS3 is introducing a Multi-column layout module. There are other issues too, but I can't pull them off the top of my head at this time.

  10. Do we really need to stop progress? by telbij · · Score: 4, Interesting

    +5 insightful? WTF? This is the same kind of specious reasoning that leads to such gems as "everything that can possibly be invented has been invented."

    With the one exception of Microsoft letting IE rot for 7 years, the advancement of the web has been steady and rapid. Even while IE was a thorn in our side, we were able to drop support for NS4, then IE5, then IE5.5. Firefox and Safari continually pushed the envelope of standards support. Javascript toolkits proliferated, bridging the gap between implementations. Even 5 years ago, using CSS for site layout was a much more difficult proposition than it is today.

    Now, if you had actually read the article, you would see that some of these tags provide very common functionality that currently require a mess of tag soup, CSS, and/or javascript. <video> and <audio> tags for instance, or <progress>. Sure you can't use them now, but in 10 years everyone will use them, and they'll be horrified with what we used to have to do. There's no reason to stop progress just because a handful of browser makers and lethargic standards bodies haven't yet perfected the first de-facto cross-platform, cross-media information platform in human history.

  11. I Don't Get It by RAMMS+EIN · · Score: 2, Interesting

    I don't get it. There was much excitement about the new tags in the dupe as well, and now here it is again. Is this really what the world has been waiting for? I thought that with the advent of XML, we could mix and match; include the languages we need, and come up with a nice, meaningful document, which could then be processed by various means to get various interesting results (one of those being a graphical rendering).

    So now we get more tags in HTML. What are those good for? Why are we putting them in a single language, rather than keeping things modular?

    Also, as far as I know, they still haven't solved some of the problems with XML (the most glaring one, in my opinion, being the lack of abstraction (think: eliminating repetion)).

    --
    Please correct me if I got my facts wrong.
  12. Re:Oh great... by Praedon · · Score: 2, Interesting

    Oh one more thing... another tag that is needed is one for sites that commonly get slashdotted. All we have to do is put several bandwidth hogging images and files inside the antislash tag, which would allow the coding to show or not show the code based on if the site is really crawling. All browser based too, so it cuts out having to ask the server if it's being slashdotted, well, because it obviously is if its going extremely slow. There are other measures to put in place too, like the browser keeping in mind if the referral page was indeed a slashdot article.

    I think I am just getting goofy now about this... : )

    --
    Just me
  13. Re:XHTML/HTML divergence by Blobule · · Score: 2, Interesting

    If thay can add a tag wrapper around a tags top change the semantics then I think they should consider also adding a tag wrapper that tells browsers the table used within is for layout purposes only. Then we can be done with the craptastic state of using CSS div kludges to layout data. Old pages wil lbe compatible, future browsers will understand that the table within is just for layout.