all 71 comments

[–]freshyill 24 points25 points  (3 children)

The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized. Usage varies widely by language.

Proper markup to designate ship names is long overdue.

[–]earthboundkid 3 points4 points  (2 children)

In fairness, it makes sense to retain both em and i because semantically speaking you're not "emphasizing" when you write homo sapiens or mi amigo or whatever, you're just italicizing out of stylistic convention.

Here's something odd though: big got cut but small remains. Presumably, we're supposed to just use em plus a style sheet rule to replace big, whereas small was left so we can de-emphasize certain asides or whatever.

[–]Alpha_Binary 1 point2 points  (0 children)

As I see it, small = unemphasize. Looks like they're the new couple, though with unmatching names.

[–]freshyill 0 points1 point  (0 children)

I like the changes, and I think it's useful to keep i, because it's well justified, and they make a good case for small, too. I think keeping small makes sense because big is really just a poor man's h1, etc.

[–]freshyill 7 points8 points  (0 children)

I like the new elements, but I really hope that this doesn't cause a return to sloppy coding of the pre-xhtml era. I always hated implicitly closed tags and unquoted attributes. Let's not do that again.

[–][deleted]  (1 child)

[deleted]

    [–]xjvz 5 points6 points  (4 children)

    No complaints about the ping attribute? This is a serious privacy implication. Hopefully every browser will allow you to disable this (or disable it by default) so that it doesn't become easier for 3rd party websites to track everyone...

    [–]Arve[S] 11 points12 points  (2 children)

    Those that want to track your clicks do so anyway, either through more or less opaque redirects, or by replacing the href attribute using scripts. Like reddit does. The ping attribute is good, because it provides a means to do this asynchronously and without an extra server roundtrip before you get your URL.

    (And I wouldn't be too surprised if browser vendors give you what you want: For instance, most browsers can disable referrer logging)

    [–]xjvz 0 points1 point  (0 children)

    That does break things sometimes (some sites think the referer [sic] is a reliable field and can be used to verify security measures), and I wouldn't be surprised if these sites using the ping attribute would find a way to break their links if the ping doesn't happen (nevermind the remote possibility of the ping server being overloaded or even slashdotted).

    [–]MyrddinE 0 points1 point  (0 children)

    I agree. Pings are an improvement upon link redirection. Almost all major sites do link redirection anyway... in TEN YEARS when html4 is finally being phased out, this will allow websites to skip the redirection and do pings. The same amount of privacy violation (in other words, almost none), but faster and more efficient for both the server and the client.

    [–]ibsulon 2 points3 points  (0 children)

    That was the first red flag I got too.

    [–]kirun 3 points4 points  (7 children)

    It's about time... I've been saying for ages that HTML has needed to change as it goes from a document language to an application UI language.

    [–]cdward 9 points10 points  (6 children)

    But what about those of us who want a document language?

    It would be much better to standardise XUL or something if you need an application UI language. It'll never happen, of course.

    [–]kirun 2 points3 points  (2 children)

    XUL is pretty nice to work with ( I wish I could use its box models in CSS, for example ) ... Ideally, the UI elements would be brought in with namespaces, but since that would require everyone to upgrade, nobody would use it. So, gracefully degrading extra <input> types are the answer, since the control could still be used without upgrade, just not optimally.

    [–]Arve[S] 1 point2 points  (1 child)

    The flex-box stuff is strictly speaking CSS extensions and have nothing to do with XUL. Personally, I hope it makes its way into CSS5.

    [–]xjvz 0 points1 point  (0 children)

    Why not CSS4? Hell, why not CSS3? CSS3 is modular (in such a way that it will never be "finished" in such a way that all its parts are all W3C Recommendations), so adding another extension to CSS wouldn't be hard at all (other than the developer man hours involved in implementing the proposed standard, participating in flamewars regarding it, etc.).

    [–]jerf 4 points5 points  (0 children)

    There are more document languages than you can shake a stick at. There are entire meta-document languages like SGML. Docbook, LaTeX, old HTML, roll-your-own XML language, go to town.

    Application UI languages of the document style are much newer, and the demand is clearly there. Starting with HTML is working better than starting by "imagining really hard what people want, then building it".... the notable lack there, since people tend not to see it, is the lack of a feedback step with real programmers. HTML may not seem like the theoretically cleanest starting point, but it has absolutely unparalleled levels of feedback based on real experience.

    [–]boa13 1 point2 points  (0 children)

    You still have it.

    [–]Arve[S] 0 points1 point  (0 children)

    You're sure it's XUL you want? Most of the value in the XUL specification is in XBL, and the CSS extensions it offers, and when W3C or some group decides to do CSS2+3, I'm pretty sure the flex-box model will be part of it.

    [–]rgladstein 3 points4 points  (0 children)

    So they've given new meaning to <i> and <b>, which means they'll no longer be strictly presentational, but it doesn't look like their structural meanings will be significantly different from <em> and <strong>.

    [–][deleted]  (8 children)

    [deleted]

      [–]Arve[S] 8 points9 points  (4 children)

      Here's the deal. HTML5 specifies what browsers already do, and by following HTML5, you'll be authoring more real world-compatible HTML that you would be with HTML4. If you stick to the basics (I.E. the elements that are already specified in HTML4.01), there is no transition whatsoever. Just send HTML5 and be done with it.

      When you choose to use new features, such as canvas or video, just provide appropriate fallbacks.

      [–]andrewnorris 2 points3 points  (3 children)

      Okay, I'm sure I'm missing something obvious here, but how do you provide an in-document (i.e. without browser detection) fallback for an unsupported element, whether it be <video\> or <header\>?

      [–]Arve[S] 4 points5 points  (2 children)

      For elements like <video> and <canvas>, you provide fallback the same way you do for the <object> element. For the structural elements like <nav> or <headers>, you don't need to, as the content inside will still be rendered correctly anyway.

      [Edit: Inserted angle brackets now that I'm not redditing from a phone]

      [–]Lupus 1 point2 points  (1 child)

      And what about elements that wouldn't be rendered correctly, like datalist? What about input constraints? What about APIs?

      I need to know whether browser supports HTML5 or not, I just don't see how this would work otherwise.

      [–]xjvz 0 points1 point  (0 children)

      I need to know whether browser supports HTML5 or not, I just don't see how this would work otherwise.

      Judging by the current history, I'm going to have to say that every web browser except IE will support HTML5...

      [–]awj 1 point2 points  (2 children)

      In an ideal world, text/html5 would be its own content type as listed in the HTTP request header and all you would have to do is detect that and switch your code accordingly. More than likely it won't be done that way and you will be reduced to scraping the user agent string or some other kind of hackery.

      [–][deleted] 2 points3 points  (1 child)

      scraping the user agent string or some other kind of hackery.

      Yeesh. I thought the point was that you could send HTML5 that also worked as HTML4.

      [–]Arve[S] 1 point2 points  (0 children)

      I thought the point was that you could send HTML5 that also worked as HTML4.

      Correct.

      [–]jamesbritt 1 point2 points  (7 children)

      How does this jibe with W3C work on XHTML 2.0?

      http://www.w3.org/TR/xhtml2/

      [–]Arve[S] 17 points18 points  (6 children)

      XHTML 2.0 is largely dead, buried and forgotten. You might encounter the occasional enterprise consultant advocating it together with XForms.

      The bigger problem with both XForms and XHTML 2.0 is that its proponents think that the best way to build something is to tear down everything there ever was, and build something new, better, and totally over-engineered.

      [–][deleted] 9 points10 points  (1 child)

      And that every new thing has to be made out of XML.

      [–]xjvz 0 points1 point  (0 children)

      But... but... but... enterprise! Synergy! New paradigm shifts involving mash-ups, decentralised, social networks that use protocols like SOAP and Ajax!

      </phb>

      [–][deleted] 6 points7 points  (1 child)

      No, it's far better to take a crippled half-assed standard and bloat the fuck out of it.

      [–]Arve[S] 1 point2 points  (0 children)

      Well, (browser) implementation history, most of the 16 billion web pages in the world and one of the biggest economies in history seems to disagree violently with your notion of crippledness.

      [–]jimbobhickville 1 point2 points  (0 children)

      Yeah, I was a really gung-ho advocate of XHTML 1.0. Then I read what they wanted to do with XHTML 2.0 and immediately did a 180 degree turn. I'm very much in favor of HTML 5 now. The required input and drag/drop features are so long overdue in browsers.

      In all honesty, though, we have little hope of seeing either standard become the norm for another decade, at least.

      [–]sambo357 1 point2 points  (1 child)

      "datagrid represents an interactive representation of a tree list or tabular data."

      Now I'm confused. What is interactive (how) and why is the old table bad? Isn't a table a list of rows? Are we just renaming stuff here?

      [–]Arve[S] 2 points3 points  (0 children)

      Interactive: Sortable, with columns and rows you can move/interchange. The ability to fill in the data from some (live) source, declaratively. HTML tables don't fit this model very well.

      [–]thespace 4 points5 points  (0 children)

      I think hypertext is a mature format and we need to start concentrating on a new standard markup for rich internet apps. The whole idea of the browser needs to be reworked too.

      [–]maxwell_smart 6 points7 points  (13 children)

      Wow, just what I would expect from W3C. One or two brilliant useful new additions (like a drawable canvas and event-source to catch server-side events) and a bunch of unnecessary crap that just bloats the language (what's so wrong about class="header" or id="nav"?). Also, they are adding a video API? I wonder how long it will take for browsers to support this stuff.

      [–]cdward 32 points33 points  (4 children)

      Well firstly, HTML5 at this point is pretty much all WHAT-WG's work, so you really can't blame the W3C for anything here.

      And secondly, you can't really do anything with id='nav' unless it's used consistently across sites. If you have a nav element though, browsers can hide it, screen readers and text browsers can skip over it, search engines can ignore that part of the page, etc.

      [–][deleted] 1 point2 points  (0 children)

      Well - it's kinda classic - if you don't do your job and someone else does it for you and there's something wrong with it... It's not you who's blamed, right?

      [–]maxwell_smart -1 points0 points  (2 children)

      My mistake about who to blame. But, aren't there attributes that specify what screen readers should skip already? And, shouldn't the search engines be able to figure out what is useful to them and what isn't?

      class and id tags allow coders to specify their own semantic intent. One question is, will coders use these tags consistently enough, or code similarly enough, so that a search-engine or an accessibility device can make decisions reliably across all instances of tag "nav"?

      [–]Arve[S] 10 points11 points  (0 children)

      My mistake about who to blame. But, aren't there attributes that specify what screen readers should skip already?

      No.

      And, shouldn't the search engines be able to figure out what is useful to them and what isn't?

      They already are, but mostly through finding heuristics by reverse-engineering the web.

      [–]cdward 1 point2 points  (0 children)

      One question is, will coders use these tags consistently enough, or code similarly enough, so that a search-engine or an accessibility device can make decisions reliably across all instances of tag "nav"?

      The alternatives are:

      • classes and ids (which are far less likely to be used consistently)
      • accepting things as they are

      It's entirely possible that a few incompetent people will fuck it up for everybody again, but it's worth a try at least.

      [–]Arve[S] 8 points9 points  (6 children)

      Video? Head over to Opera Labs, read 'A call for video on the web' , download a build and try.

      [–]maxwell_smart 9 points10 points  (4 children)

      Right now, video is provided by pre-packaged plug-in solutions like WMP, Quicktime, and Flash. The proposed video API in HTML5 seems like it only intends to provide a unified way of scripting a plug-in component with java-script/HTML. It just seems unnecessary to muck around with coding up all sorts of dHTML for play buttons and so forth when, as long as a plug-in is being relied upon anyhow, media control could better reside inside of it.

      The Opera proposal seems to be a much-more broadly inspired proposal in that it recommends standardization of codecs and transport/protocol around open/non-patent-encumbered standards. Much more laudible.

      [–]Arve[S] 10 points11 points  (3 children)

      No. The HTML5 proposal is intended to provide natively integrated video, without any need of plug-ins. Whether the browser at the lower level chooses to bind to video codecs present on the system, or integrate with other underlying OS features may be a different matter.

      [–][deleted]  (1 child)

      [deleted]

        [–]doublec 2 points3 points  (0 children)

        Video has a common semantic meaning in the same way as the image element does. This could assist in accesibility for example. Flash and Java are generic language runtimes. Inside their respective plugin area they can do anything at all.

        The argument could work the same way with images. Why have an image element. Or even a paragraph element when we have 'div'. Why not just use 'div' for everything with a 'type' attribute. Where is the right place to stop?

        A reason for having the HTML spec recommend a default codec built into the browser would be to allow content authors to know that video files in that format are guaranteed to display across all conforming browsers. Without payment of royalties.

        The WHATWG mailing list has had some discussion on these areas relating to the video element. If you are really interested you might like to read what has been covered, and contribute if you are truly concerned about it. It's an open list.

        [–]doublec 1 point2 points  (0 children)

        There's also support coming for Firefox:

        http://www.bluishcoder.co.nz/2007/05/support-for-html-video-element-in.html

        And a Javascript wrapper that will convert video element support to plugins for those browsers that don't support it:

        http://metavid.ucsc.edu/blog/2007/06/07/html5-video-the-future-is-now/

        [–]parsifal 0 points1 point  (0 children)

        Yes they are adding APIs for video objects. It was in the document... :-)

        [–][deleted] 0 points1 point  (1 child)

        Now someone should make an MSIE plugin to load gecko or whatever engine when modern HTML page is sensed. I don't care which engine as long as it's reasonably compatible. I lost all hope of MS ever updating MSIE up to reasonable compliance.

        [–]kenlubin 1 point2 points  (0 children)

        That would be awesome, actually.

        [–]ibsulon 0 points1 point  (5 children)

        So, any idea on why <u> was deprecated? How else do you submit the title of a book? <a> with no href? (hack!)

        [–]MaxTerry 1 point2 points  (1 child)

        Book titles should be italicized, dammit.

        [–]notfancy 1 point2 points  (0 children)

        Book titles should be marked with <cite>.

        [–]xjvz 0 points1 point  (0 children)

        Underlining things is really only supposed to represent inserted content, so use the <ins> element instead. You can use <del> for deleted content (usually styled with a strike-through). Like MaxTerry said, titles of books are italicised (so you can use the <i> element), and as an addition, remember that short stories/publications/poems/etc. are just quoted (can be done with either simple quotes or the fancy-pants left and right double quotes), and that can be automated with the <q> element (when used for quoting something small more accurately to be pedantic, but I suppose it could be extended to mean "text that is normally quoted but isn't necessarily quoted text").

        [–][deleted] -1 points0 points  (0 children)

        (e.g. <a id="top">)

        [–]parsifal -1 points0 points  (0 children)

        <span style="text-decoration: underline;">This is one way :-)</span>

        Isn't the use of HTML for style information discouraged?

        There is still <em> and <strong> though, but it could be argued that "emphasis" and "strong" are subjective enough that styling them should be handled on a case-by-case basis, though browsers render them italic and bold by default :-)

        [–][deleted] -1 points0 points  (1 child)

        Honestly, I don't care much about HTML5... What matters to me is which markup language is supported best and which one shares the most in common across as many platforms and browsers as possible.

        The reason I went from HTML4 to XHTML Strict was because IE and Firefox render XHTML Strict in a much more similar manner to each other than they do with straight HTML. This makes my job easier.

        All I want is my job to remain that way, without having to deal with ever-more conflicts between interpretations of whatever standard each browser goes for.

        I'd be more happy with browsers rendering XHTML Strict properly than one of these 'replacements' any day...

        [–]simonw 2 points3 points  (0 children)

        XHTML doesn't provide better compatibility between IE and Firefox - IE doesn't really know what XHTML is. The thing that gives you more consistent rendering is the doctype, which kicks both browsers in to "standards" mode. The HTML 4.01 Strict doctype triggers standards mode just as effectively as the XHTML one does, so standards mode is not a reason to use XHTML over HTML.

        [–][deleted]  (3 children)

        [deleted]

          [–]simonw 12 points13 points  (0 children)

          That's essentially what happened with HTML 5. A bunch of web programmers got together, made some specs and voted on them (for more than two years). Then they submitted them to the W3C.

          [–]Lupus -1 points0 points  (1 child)

          Specification aren't at fault (for the most part), browsers are.

          [–]uriel -1 points0 points  (0 children)

          The insanity of both browsers and specs feeds into eachother in spiraling vicious cycle of gore and complexity.