An Event Apart and HTML 5

Published 15 years, 11 months past

The new Gregorian year has brought a striking new Big Z design to An Event Apart, along with the detailed schedule for our first show and the opening of registration for all four shows of the year.  Jeffrey has written a bit about the thinking that went into the design already, and I expect more to come.  If you want all the juicy details, he’ll be talking about it at AEA, as a glance at the top of the Seattle schedule will tell you.  And right after that?  An hour of me talking about coding the design he created.

One of the things I’ll be talking about is the choice of markup language for the site, which ended up being HTML 5.  In the beginning, I chose HTML 5 because I wanted to do something like this: 

<li>
<a href="/2009/seattle/">
<h2><img src="/i/09/city-seattle.jpg" alt="Seattle" /></h2>
<h3>May 4—5, 2009</h3>
<p>Bell Harbor International Conference Center</p>
</a>
</li>

Yes, that’s legal in HTML 5, thanks to the work done by Bruce Lawson in response to my href-anywhere agitation.  It isn’t what I’d consider ideal, structurally, but it’s close.  It sure beats having to make the content of every element its own hyperlink, each one pointing at the exact same destination: 

<li>
<h2><a href="/2009/seattle/"><img src="/i/09/city-seattle.jpg" alt="Seattle" /></a></h2>
<h3><a href="/2009/seattle/">May 4—5, 2009</a></h3>
<p><a href="/2009/seattle/">Bell Harbor International Conference Center</a></p>
</li>

I mean, that’s just dumb.  Ideally, I could drop an href on the li instead of having to wrap an a element around the content, but baby steps.  Baby steps.

So as Bruce discovered, pretty much all browsers will already let you wrap a elements around other stuff, so it got added to HTML 5.  And when I tried it, it worked, clickably speaking.  That is, all the elements I wrapped became part of one big hyperlink, which is what I wanted.

What I didn’t want, though, was the randomized layout weirdness that resulted once I started styling the descendants of the link.  Sometimes everything would lay out properly, and other times the bits and pieces were all over the place.  I could (randomly) flip back and forth between the two just by repeatedly hitting reload.  I thought maybe it was the heading elements that were causing problems, so I converted them all to classed paragraphs.  Nope, same problems.  So I converted them all to classed spans and that solved the problem.  The layout became steady and stable.

I was happy to get the layout problems sorted out, obviously.  Only, at that point, I wasn’t doing anything that required HTML 5.  Wrapping classed spans in links in the place of other, more semantic elements?  Yeah, that’s original.  It’s just as original as the coding pattern of “slowly leaching away the document’s semantics in order to make it, at long last and after much swearing, consistently render as intended”.  I’m sure one or two of you know what that’s like.

As a result, I could have gone back to XHTML 1.1 or even HTML 4.01 without incident.  In fact, I almost did, but in the end I decided to stick with HTML 5.  There were two main reasons.

  1. First, AEA is all about the current state and near future of web design and development.  HTML 5 is already here and in use, and its use will grow over time.  We try to have the site embody the conference itself as much as possible, so using HTML 5 made some sense.

  2. I wanted to try HTML 5 out for myself under field conditions, to get a sense of how similar or dissimilar it is to what’s gone before.  Turns out the answers are “very much so” to the former and “frustratingly so” to the latter, assuming you’re familiar with XHTML.  The major rules are pretty much all the same: mind your trailing slashes on empty elements, that kind of thing.  But you know what the funniest thing about HTML 5 is?  It’s the little differences.  Like not permitting a value attribute on an image submit.  That one came as a rather large surprise, and as a result our subscribe page is XHTML 1.0 Transitional instead of HTML 5.  (Figuring out how to work around this in HTML 5 is on my post-launch list of things to do.)

    Oh, and we’re back to being case-insensitive.  <P Class="note"> is just as valid as <p class="note">.  Having already fought the Casing Wars once, this got a fractional shrug from me, but some people will probably be all excited that they can uppercase their element names again.  I know I would’ve been, oh, six or seven years ago.

    Incidentally, I used validator.nu to check my work.  It seemed the most up to date, but there’s no guarantee it’s perfectly accurate.  Ged knows every other validator I’ve ever used has eventually been shown to be inaccurate in one or more ways.

I get the distinct impression that use of HTML 5 is going to cause equal parts of comfort (for the familiar parts) and eye-watering rage (for the apparently idiotic differences).  Thus it would seem the HTML 5 Working Group is succeeding quite nicely at capturing the current state of browser behavior.  Yay, I guess?

And then there was the part where I got really grumpy about not being able to nest a hyperlink element inside another hyperlink element… but that, like so many things referenced in this post, is a story for another day.

Comments (71)

  1. I used HTML5 on our redesign this fall largely because, like you, I wanted to give it a shot and be at the forefront. Reading your article just prompted me to validate our site. The only errors I get are attribute not allowed errors: “name” on an a tag (and I learned while building this site that for # links name is pretty much deprecated) and “alt” not allowed on abbr, a little redundancy I threw in, I guess. Overall it was a pleasant enough experience.

  2. I had considered re-doing my own site as HTML5 a couple of months ago, for much the same reasons as yourself. But then I thought : why?

    HTML5 buys me nothing that I want. Thanks for experimenting live – I’d love to see some examples of where you feel HTML5 is offering good things XHTML doesn’t. The anchor wrap is a nice one, but just doesn’t seem worth the regressions of the technology.

  3. You mentioned “XHTML 1.1 Transitional”. Is that a typo? I think it should either read “XHTML 1.1” or “XHTML 1.0 Transitional.”

    Thanks for taking the leap with HTML 5 and keeping us informed.

    [Yep, that’s a typo. Fixed. Thanks! -E.]

  4. If the li element (and any element really) would be able to take on the href attribute, you wouldn’t need to be able to wrap all kinds of elements inside an anchor. Wouldn’t that be easier than changing the hierarchy rules we’re already used to?

  5. Methinks you need to follow the “arbitrary-href agitation” link in the post, Els. Or, if you prefer, check some of the older posts in the (X)HTML category.

  6. Hey Eric, thanks for taking a dive into new and fairly un-explored territory. If you have a minute, I had 2 quick questions.

    #1. I didn’t notice anything in the doctype or other header elements denoting the pages as HTML5. Is there anything that you would need to do to correctly identify your document as HTML5?

    #2. It seems that the main markup reason you used HTML 5 was to allow block elements (h2,h3,p) inside of an inline element (a). Since the browsers didn’t render this correctly, doesn’t resorting back to spans still meet the Xhtml 1.1 spec since they are inline elements?

    Not trying to be confrontational, I’m just trying to make sure I cover all my bases when pushing forward with new advancements.

  7. Maybe I’m misunderstanding the issue (quite likely btw!), but I just meant to say that I don’t understand the reasoning behind allowing any element inside an anchor, while allowing the href on any element would be easier/better/more logical.

    My “wouldn’t that be easier” was not directed at you, but at the people who are making the HTML5 specs, and the browser makers who decided to support elements inside anchors in the first place.

  8. When I first read that the site was coded using HTML5 I thought I might see more of the new elements introduced – header, nav, article etc. – but then I guess the site still needs to be presentable in older browsers too.

  9. Ian: HTML5 documents don’t contain anything to identify themselves as HTML5 pages. They just use “<!DOCTYPE HTML>” to identify themselves as not being legacy pages that will cause web browsers to emulate IE5 bugs. The plan is that HTML6 pages will use “<!DOCTYPE HTML>” too – web browsers will continue to always just implement the latest version of HTML, so it’s misleading for a page to declare itself as HTML5 when everyone is instead going to use HTML6’s rules for processing the page.

    Els: If the href attribute was added to all elements, then every web browser would have to write code to handle that new attribute, and then you’d have to wait years until almost all your users had upgraded to a recent browser that supported that feature. And you’d have to update all the search engines to crawl those new link attributes. And you’d have to add all the other link-related attributes (target, rel, media, type, …) to every element (and deal with conflicts when some elements already define some of those attributes), along with all the relevant DOM APIs. And users of old browsers would find that they’re unable to click any links on some new sites. So it’s a pain for everybody.

    On the other hand, <a> around block elements already works in web browsers (except for some bugs and quirks) so it simply needed some small changes in the validator to stop complaining about those cases, which is much easier.

  10. I’ll say here what I said on your original href agitation post: Pansy douchebag browser vendors’ whining about “OHHH IT’S SO HARD TO DO THAT” has almost got to be a crock.

    I admit that I’m no programmer. But I’m fairly certain I could write Javascript to implement block-level links in like an hour. Nothing that’s a trifle in Javascript should be a huge unovercomeable obstacle in the browser’s code.

    Perhaps I’m wrong. I’d love to see an explanation from, say, someone at Mozilla about why this is so mind-blowing a problem.

  11. Hey,

    Nice post!

    I just wanted to mention that I noticed your link to the html 5 spec on the a element was not working, I think it should go here: http://dev.w3.org/html5/spec/Overview.html#the-a-element

  12. Pingback ::

    Links of the day (Jan 02) » Grégory Karékinian

    […] Eric’s Archived Thoughts: An Event Apart and HTML 5 […]

  13. Thanks for the namecheck, Eric. Ian: the DOCTYPE for HTML 5 is <!DOCTYPE html>; it’s there at the top of the page. Actually, HTML 5 doesn’t really need a DOCTYPE, but browsers do, in order to go into Standards mode, so that’s why it’s there.

    John Faulds: there’s no reason why you couldn’t use header, nav, article etc now; they can be styled with CSS with no problem (even in IE, with a clever little trick). You can see it work in Opera, Firefox, Safari, and even IE in my test page http://www.brucelawson.co.uk/tests/html5-elements.html

  14. .. of course, the demo above is just a demo. It should be styled with CSS tables rather than floats, and should definitely have WAI-ARIA document landmark roles added to the markup, so screenreaders know what each area of the screen is for, but I didn’t want to obscure the central point.

    And I can’t take all the credit for the function of anchors in HTML 5. But I’m happy to take some …!

  15. CONGRATS Eric (thx bruce)!

    I’m very happy that your “href-initiative” bore fruit (didn’t know till today).
    Now my lazyness pays off and i’ll just have to change the doctype of my own page to have my “<li><a href=”xxx”><h2> …” (unchanged since feb 08) be valid :D

    Greetings and Happy New Year,
    Wolfgang

  16. I did very seriously consider that, John, but after the link-wrap render problem, I decided to minimize the changes in markup in order to be sure we launched on time and intact.

    As to what might happen in the near future… well, we’ll just have to see.

  17. Being able to wrap and group block elements in a single anchor is an excellent feature – but the markup will get messier, and (x)HTML is already a tag soup.

    I have to roll my eyes whenever I hear the argument that browsers don’t currently support feature X – for a long time browsers didn’t fully support CSS2 features, HTML4 features, and more… (some still don’t) – did the w3c wimp out then and water down CSS and HTML? No – the browsers brought up their support to the level of the standard.

    I would much prefer having the href attribute available to most tags (like on the LI tag in Eric’s example), and a systematic method for compensating for older browsers to overcome lack of support for new features.

    Or we could just let the browser vendors dictate the HTML standards, and end up with the mess that we had back in the days of Netscape/Microsoft and HTML 3.

  18. Pingback ::

    Max Design - standards based web design, development and training » Some links for light reading (6/1/09)

    […] An Event Apart and HTML 5 […]

  19. I recall a conversation with a screen reader user working for the RNIB that block level elements inside of anchors gets error-corrected by either the browser or the screen reader (IE6 & JAWS combination I think) so that the link gets terminated before the start of the block level element. The result of that is that the readable text inside the block level elements does not get read out in a “link voice” (as opposed to a “non-link voice”), so the user is not aware that this content is part of a link – or, in the cases where the link just contains block level elements, an empty link.

    Has this technique been tested in mainstream browser and screen reader combinations and assessed as not creating a barrier for screen reader users? I don’t see any direct or indirect mentions of accessibility concerns of this technique in this or in referenced posts, hence this query on the matter.

  20. At the risk of derailing Eric’s blog post, I’m interested in the juxtaposition of Stuart Jones’ and Isofarro’s comments.

    Stuart writes, “we could just let the browser vendors dictate the HTML standards, and end up with the mess that we had back in the days of Netscape/Microsoft”.

    That would be folly. Isofarro then points out to a problem that IE/ JAWS has with the experimental HTML 5 technique and asks “Has this technique been tested in mainstream browser and screen reader combinations and assessed as not creating a barrier for screen reader users?”.

    My question – which isn’t rhetorical – should we wait until the Netscape 4-style beasts that are the commercial screenreaders catch up before we can use a technique?

    They were invited to participate in the development of HTML 5 (http://lists.w3.org/Archives/Public/public-html/2007Jul/1249.html) but I don’t know that they took up that invitation: http://lists.w3.org/Archives/Public/public-html/2008Aug/0795.html

    My personal belief (e.g., I represent no-one here) is that if we’d waited for JAWS et al to support it before using Flash, Ajax etc, we’d still be waiting now.

  21. @Stuart Jones – “did the w3c wimp out then and water down CSS and HTML” – Yes, they did. Text-shadow is just one example of something that was in CSS 2 and not in CSS 2.1. HTML5 is happening, in part, because Microsoft still hasn’t started supporting XHTML (no, using an HTML parser when it is served as text/html doesn’t count).

  22. Hi Bruce,

    Bruce asks: “My question – which isn”t rhetorical – should we wait until the Netscape 4-style beasts that are the commercial screenreaders catch up before we can use a technique?”

    With Netscape 4 we had an HTML and CSS recommendations that had been around for years, plus it’s market share was taking a nose-dive and it needed someone to hammer the stake right in.

    The more pertinent question is – can we afford to go ahead using such constructs if there isn’t mainstream support of it from assistive technology? At least with the Web standards movement we always had progressive enhancement – we started with a well structured document that adhered to the most widely accepted HTML “specification” out there.

    And points out: “My personal belief (e.g., I represent no-one here) is that if we”d waited for JAWS et al to support it before using Flash, Ajax etc, we”d still be waiting now.”

    Until the assistive technologies supported the accessibility features of Flash, and dealt with Ajax in a reasonable manner, we aimed for progressive enhancement – we could always rely on there being a decently structured document underneath those other layers. What’s the similar fallback for HTML5 – is it even possible to degrade back into a document that is valid with an existing HTML recommendation that is final?

    (Does this mean the answer to my original question is ‘No’?)

  23. Hi, really enjoyed this artice, but I’m worried I’ve missed something obvious…

    Why can’t you wrap the ‘li’ in an ‘a’ ? Is it not semantic?

    Thanks

  24. Isofarro says “Until the assistive technologies supported the accessibility features of Flash, and dealt with Ajax in a reasonable manner, we aimed for progressive enhancement ”

    True enough; *we* did. But Gmail and all the sexy Flash people didn’t, and I suspect that’s what drove the screenreader vendors to add support.

  25. @bruce – of course it would be folly to let browser vendors dictate standards.

    @David Dorward – fair enough, I didn’t know of a specific example to counter my original thoughts. Still, on the flipside, HTML4 was a lot more stringent than HTML3 was when the earlier standard attempted to accomodate the various browser-specific elements.

    @isofarro – “assistive technology” should keep up – w3c standards development is not something that happens overnight, and browser developers get a pretty good idea of the direction in which things are heading – is it so hard for them to be prepared for something like HTML5 where it has been under discussion and refinement for at least a couple of years already?

    @Mike – I don’t see that having a specific <a> for links as opposed to having the href attribute for any element is more or less semantic. In fact, by specifying that the href for linking can be put into any other element, it means that the anchor element can be restored to generally only having one meaning – that is, as an anchor point within a document for linking to.

  26. ‘“assistive technology” should keep up’ – the spec isn’t finished yet, is subject to change, and mainstream browsers are “keeping up” largely due to the spec being written around their foibles!

  27. Pingback ::

    Bruce Lawson’s personal site  : HTML 5 elements test

    […] Meyer recently recoded An Event Apart to use the HTML 5 DOCTYPE, and one of the comments he received was “I thought I might see more of the new elements […]

  28. @stuart

    I was wondering why Eric said
    “I could drop an href on the li instead of having to wrap an a element around the content”

    but he can can’t he: > li /li /a

  29. oops, sorry. why can’t he:

    a li /li /a

  30. @David Dorward – that is why discussions such as this are important, as long as they filter on to people involved in the conversation at W3C (and HTML5 is still very much in open discussion).

    @Mike – there is nothing wrong with writing the HTML like that, per se, (at least in HTML5, at the moment) – but to me, it looks like it will just increase the tag-soup, when having a flexible href attribute will reduce it.

  31. Pingback ::

    Discussing, implementing & improving HTML 5 » Broken Links

    […] Eric Meyer writes about his experience using HTML 5 for the recent redesign of An Event Apart, which seems to be pretty well summarised as “it doesn’t work yet”. Really, all he did was write HTML 4.01 with an HTML 5-compatible doctype (see later). Browser support just isn’t in place for much more yet. […]

  32. Pingback ::

    Eric Meyer on HTML 5 | Jeff Siarto

    […] Eric Meyer on HTML 5 A quick write-​up on the redesign of An Event Apart and Meyer’s choice of HTML 5 as the markup lan­guage. There is also a good dis­cus­sion of HTML 5 DOC­TYPES in the dis­cus­sion section. […]

  33. Pingback ::

    valeriovaz.com » Bookmarks for January 7th through January 9th

    […] Eric’s Archived Thoughts: An Event Apart and HTML 5 – […]

  34. Pingback ::

    Apple, HTML & Entrepreneurial « stephentrepreneur

    […] both HTML and CSS to create interesting pages of data are still my hobby and fascination, yet not on the forefront of interest so much anymore. Meh. […]

  35. Interesting approach to HTML5, Eric.

    I’m just wonder why there is no microformats, no hCalendar, in the site, the event lists would be a perfect place to include it, instead of generic classes like ‘title’, ‘date’: maybe the BBC/accessibility matter?

  36. It seems that having href for (nearly) any element would solve some of the simpler accessibility issues, on the order of ensuring every image has a title or alt attribute.


    <a href='some_place' title='something'>
    <img src='some_image' title='something else' alt='and more'>
    </a>

    Right now under html4, if I wrap an img within a hyperlink, I have two titles for the same object, as the user views it. One for img, and one for a. This creates a certain amount of ambiguity for a visual browser, at the very least. When rendering a tool tip, which one of the title attributes ought it use? The browser must respect my intention to create a hyperlink the size, shape and location of the image, but it could be argued which title is more semantically correct to reveal to the user, or even which is more useful.

    If I was able to rewrite the example as


    <img src='some_image' href='some_place' title='something' alt='something else'>

    then it alleviates some of the potential for the browser to get it wrong. Additionally it adds clarity for new authors, or authors who have only recently been exposed to the advantages of semantic and accessible markup. That adds to the quality of web pages overall.

  37. Pingback ::

    HTML5 im produktiven Einsatz? - Code Candies

    […] Eric Meyer hat An Event Apart in HTL5 umgesetzt. […]

  38. Thanks for keeping to the edge of the road Eric. Your books helped me make the leap to full CSS table free designs. I hope you keep on pushing the limits.

  39. Button tag (submit “type”) with image tag inside, anyone? It’s been working for quite some time, now (I mean, HTML 4).

  40. Pingback ::

    Bruce Lawson’s personal site  : Redesigning with HTML 5 and WAI-ARIA

    […] dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few […]

  41. Pingback ::

    Selección de 12 recursos para lograr el salto al HTML 5 | Cosas sencillas

    […] An Event Apart and HTML 5. Otro artículo de An Event Apart sobre el tema del HTML 5. […]

  42. Pingback ::

    NoBigBlog » Ponderous things #1

    […] Eric Meyer uses HTML5 for the AnEventApart site and talks about it a bit. […]

  43. Pingback ::

    Jetzt schon HTML5 nutzen! - Code Candies

    […] bin ich aber noch nicht. So wird’s wohl auch Eric Meyer gegangen sein, der seinen Artikel dazu erst ganz euphorisch pro HTML5 beginnt, dann aber letztendlich doch zum bekannten HTML4-Markup […]

  44. I did notice that, with css disabled, your skipper link to navigation is linked to #navhead which does not seem exist in your mark-up

  45. I was really confused, Chris, until I realized that you were talking about meyerweb, and not the AEA site. You’re quite right! It’s fixed now. Thanks!

  46. Pingback ::

    Lensco.be | Blog | The year of HTML 5

    […] and published their thoughts and experiences along the way: An Event Apart by Jeffrey Zeldman and Eric Meyer, and UX London by the lads from […]

  47. Looking forward to when I can add an href to an LI.

  48. One more thought:

    “but some people will probably be all excited that they can uppercase their element names again”

    The thing that happened when XHTML picked up in popularity is that web developers started thinking they had to lowercase their elements everywhere. I don’t know why or how this started but people started thinking the XHTML police were going to come after them if they even showed an element in uppercase when talking about it in an article or when referring to it in a style sheet. It was really only required within an XML/XHTML document with no such requirement existing outside XML/XHTML documents. Of course it’s not even required in an XML/XHTML document if you don’t care if the doc is valid or not . . . but that’s a different matter.

    The reason I’m bringing this up is because when reading a web development article or looking at a style sheet it’s much easier to read if X/HTML elements are presented in uppercase letters but the rampant “lowercase everywhere” mentality really caught on and got an iron grip in the web development world.

    http://developer.cmzmedia.com/?p=9 (my own little blog post about the matter)

  49. Pingback ::

    Latest Accessibility News on Accessify » Markup Maker - Updated with improved HTML5 support

    […] Maker a small update today. Nothing too earth-shattering, but with all the talk of HTML5 in recent weeks, I thought I should take a look and see how it copes with this flavour of HTML and decided to add a […]

  50. Thanks for pushing against these limits Eric. Your specific example is a dilemma I have struggled with on a number of occasions.

    Using the href on elements such as li is certainly appealing, although I imagine it would present some curly problems for screen readers if used around largish blocks of content. Perhaps it would be feasible for them to only read out certain elements within each link when tabbing through a page…

    Maybe in those cases something more akin to the for attribute applied to the parent element – referencing a contained anchor be more practical?

    For those looking for another (validating) approach to your specific problem that will work with today”s browsers, here is a rewritten portion of your example from the AEA site. I have used JavaScript for the same visual/clickable effect without the spans: AEA with jquery.biggerlink.

  51. href attribute on any element would indeed be great but we still have a semantical problem there.

    Why wouldn’t it be possible to use some kind of label-ish “for” attribute associated to the ID of any element?

    You keep the anchor as-is but add a pointer to it. The browser then knows the id referenced in the “for” attribute is clickable and should point to the anchor’s href.

    Any W3C member in here? ;-)

  52. Pingback ::

    Theme Awesome — educe me

    […] am also coming away from XHTML and leaning towards HTML(5), after reading many articles on the subject of XHTML vs HTML. This theme’s code is set to easily switch to HTML5 […]

  53. Pingback ::

    Adventures in Web 3.0: Part 1 - HTML 5 « Web developer

    […] Part 1 – HTML 5 By tejas786 Last week I was reading about the Event Apart re-design which uses HTML5. I have remained peripherally aware of HTML 5 (I’m on the mailing list) but mostly I’ve […]

  54. What I didn”t want, though, was the randomized layout weirdness that resulted once I started styling the descendants of the link. Sometimes everything would lay out properly, and other times the bits and pieces were all over the place. I could (randomly) flip back and forth between the two just by repeatedly hitting reload.

    So it’s a bit late now, but I believe this is caused by an issue in Firefox where the parsing of blocks-in-inlines is dependent on TCP/IP packet boundaries (which is why it changes on reloads). I’ve not tested this recently, but I’m fairly sure it’s possible to work(/hack) around the bug by writing <a ...><span> ... all the normal semantic block elements ... </span></a>. (But then it’s no longer valid HTML5.)

  55. You wrote:
    “But you know what the funniest thing about HTML 5 is? It”s the little differences. Like not permitting a value attribute on an image submit. That one came as a rather large surprise, and as a result our subscribe page is XHTML 1.0 Transitional instead of HTML 5. (Figuring out how to work around this in HTML 5 is on my post-launch list of things to do.) ”

    My question to you is why use an input at all when a button tag works?

  56. Pingback ::

    Pemaquid Crunch: Web Design notes from Portland, Maine » Blog Archive » HTML5 - A Look Ahead

    […] An Event Apart and HTML5 – Eric Meyer discusses the making of AnEventApart.com in HTML5 […]

  57. Pingback ::

    Go forth and HTML 5 » Positively Deranged

    […] Eric Meyer on using HTML for An Event Apart […]

  58. aneventapart.com is written in HTML5? Did the HTML5 get nixed? Maybe I missed a post explaining it has switched back?

    Just checked the source and I’m not seeing it.

  59. Thanks, Philip! Good to know I wasn’t crazy, as well as mind-boggling that the problem to rendering lay in packet boundaries.

    Requirements of the off-the-shelf scripts we’re using, Lauren. I have yet to find time to hack around their limitations.

    Yes, D Ross, it’s still in HTML5 as of your comment (and this one too). Nothing has changed since the post was written.

  60. I’m so glad they’re adding this to HTML5. I’ve been using workarounds ever since. You can see a prime example on my website’s search results template. I’m using this:

    <a href="http://..." title="Read more" rel="nofollow">
    Post Title
    Post Date
    </a>

    In my CSS I did a display: none; on the so that if the search results are viewed without a stylesheet applied, they would still display in a human-readable format. This structure was the only way I saw fit since you can’t wrap an <a href="" around any other text elements. I don’t know if it’s the best way but it works.

    HTML5 answers the call on this one and that makes me happy. Thanks for bringing this to light. I can’t wait to see what’s in store and I’m happy that we’re discussing this in a civil manner.

  61. D’oh, I totally borked that one. Do a search on my website and view the source to see what I mean.

    [Fixed the markup in the previous comment. One of these years I’ll get around to doing ‘code’-bound entity translation, or at least having a “I included sample markup so please translate it!” checkbox. -E.]

  62. Pingback ::

    HTML 5 Weekly Review #3 | Jeff Siarto

    […] of the first higher‐​profile sites to switch to an HTML 5 DOCTYPE. Eric goes into more detail here about why he used HTML […]

  63. Pingback ::

    Key Takeaways from An Event Apart at Space Ninja

    […] Eric Meyer says “HTML 5 allows interesting new patterns, but there are still limitations.” […]

  64. Pingback ::

    Key Takeaways from An Event Apart - Pop Art Blog

    […] Eric Meyer says “HTML 5 allows interesting new patterns, but there are still limitations.” […]

  65. Pingback ::

    six03 » HTML5, DOCTYPES & MIME Types

    […] I use HTML5? Another fellow I met awhile back went with HTML5, it seems to have worked out fine. It works? It doesn’t work? It’s good, it’s […]

  66. Pingback ::

    Most useful and must read articles on HTML 5

    […] Website: meyerweb.com […]

  67. “Like not permitting a value attribute on an image submit. That one came as a rather large surprise, and as a result our subscribe page is XHTML 1.0 Transitional instead of HTML 5. (Figuring out how to work around this in HTML 5 is on my post-launch list of things to do.)”

    I just got stuck on this too, I was converting a valid XHTML page to HTML 5. I ended up just leaving out ‘ value=”submit” ‘ but not really sure if this is correct. Did you ever figure out a work around?

  68. Pingback ::

    AhsanZaheer» Blog Archive » Designing a blog with html5 - Blog

    […] and dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences […]

  69. Pingback ::

    Designing a blog with html 5 « RAM Computer Repairs

    […] if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences […]

  70. Interesting. But I wish I could read it with more than two or three words per line. IMO webdesigners need to check what their pages look like to visitors with moderate visual impairment — the sort of thing that requires zooming normal font size up to 24-30px. Margins using em are usually the problem in column width shrinkage. Great for the average user, but hell when you can’t read it comfortably either way. *Sigh*

  71. Pingback ::

    Designing a blog with Html5 | webrak

    […] using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few […]

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview