meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

The Missing Link

One of the few things I think XHTML2 got absolutely, totally, 125% right was freeing the href attribute from the few elements that accepted it and spreading it all over the language.  It saddens me that this isn’t happening in HTML5, especially since at least 1.5 of the four reasons given seem off base or flat-out incorrect.  From where I stand, at any rate.

Here, let me explain by having a pseudo-dialogue with the four reasons.

It isn’t backwards compatible with existing browsers.

Neither was CSS, table markup, PNG support, or any number of other worthwhile advancements in the web.  And yes, table markup was an absolutely worthwhile advancement: previous to that, the only way to have a table of data that lined up in any fashion was to space-format it and throw the whole thing into a pre element.  Ugly nonsemantic fun!

For that matter, if lack of backwards compatibility is an accepted reason to exclude something from HTML5, then a whole bracket of new elements—like, say, nav, article, aside, dialog, section, time, progress, meter, figure, video, datagrid, header, footer, need I go on?—need to come out of the specification right now.  They’re totally unsupported, and may not even be stylable, by older browsers.

(Yes, I just proposed that the term for a group of elements be a “bracket”.  A pod of whales, a flock of seagulls, a bracket of elements.  Try it out, see how it feels on the tongue.  A little angular, perhaps?  Don’t worry, you’ll get used to it.)

It adds no new functionality that can’t already be achieved using the a element.

What?  What?!?

Given a table where each row contains several cells of of summary data, and there is a desire to be able to click on a row to get more detailed information via a search keyed off that summary information, please explain to me how being able to use <tr href="..."> on each row as opposed to writing a whole bunch of JavaScript to associate a click event listener and delegation code and handler functions and target assembly logic just to simulate what <tr href="..."> would do, were it permitted, constitutes “no new functionality”.  Please.  I would love to hear that one.

Unless of course HTML5 is going to let us wrap a elements around whatever arbitrary collection of elements we like, in which case, never mind.  I’ll just wrap all my trs in as and be done with it.  That’d be keen.  Will that be possible?  Will the HTML5 syntax be so flexible as to permit that?

Yeah, that’s what I thought.

Not that I spent half the week banging my head against this problem and getting a bunch of hand-holding in the arcana of JavaScript and inconsistent browser event handling just to address what twenty-five seconds or so would have sufficed to resolve in an href-everywhere world or anything.

And for the flip side of this, see Wilson Miner’s “Accessible Data Visualization with Web Standards“, where a bar graph is built out of spans so that they can all be wrapped in an a element in order to let you click on any “row”—that is, what would have been a row had he been able to use table markup—and get more information.  Yes, absolutely, all that stuff should be in a table, but it was a case of have a table with a bunch of not-that-easy JS forced onto it, or have the contents of every cell in a row be a separate hyperlink to the same destination, or do simple markup with savaged semantics.  We shouldn’t be forced into that choice.

It doesn’t make sense for all elements, such as interactive elements like input and button, where the use of href would interfere with their normal function.

True enough.  So don’t add it to those elements which would suffer, like input and button.  Or, alternatively, define behavior conflict resolution in those cases.  There might actually be good reasons to have button accept an href value as a fallback in cases where the normal function of the button fails in some manner.

Either way, the fact that adding href doesn’t work in some cases is no reason to forgo its addition in all cases.

Browser vendors have reported that implementing it would be extremely complex.

I’m always willing to hear why implementors think something is complex to implement, as they’re often subtle and fascinating insights into web browser development.  Still, it seems to me that everything ubiquitous href attribution would imply can be recreated with a heavy dose of JavaScript event handlers and related code—(on)click for the sending you off to the target (and any :active-style effects you wanted to bring in), (on)mouseover or plain old :hover for the interactive effects, et cetera, et cetera.  Are they really saying that it’s more complex to support this sort of thing in markup than it is to support all the scripting and DOMiness that permits people to laboriously recreate it on their own?  If so, why?  I’m really curious to know what would make this “extremely complex”, which sounds a good deal more dire than “complex” or just plain old “difficult”.

I’m open to having my mind changed by strong evidence that this would be borderline impossible to implement, even though it can apparently be simulated via existing DOM/JS implementations.  Anything short of that, however, isn’t going to convince me that this should be dropped.  It was a good idea when it was in XHTML2, and it shouldn’t be abandoned if there’s any chance to save it.

45 Responses»

    • #1
    • Comment
    • Mon 2 Jun 2008
    • 0945
    Mikołaj wrote in to say...

    WHATWG Wiki says:

    HTML has served the Web community well, but it lacks some basic semantics necessary for modern Web applications. HTML 5 attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.

    Maybe my memory doesn’t serve me well but wasn’t linking <tr>s an issue raised in the past few years? IIRC past eight years or so?

    • #2
    • Comment
    • Mon 2 Jun 2008
    • 1044
    Frank Boës wrote in to say...

    Well, I never liked XHTML2. But the href-Attribute for everything was a great invention. And with only a single line of javascript every document with these atributes appended to non-a-tags could even be used in old browsers.

    Styling via CSS would be easy in non-IE-browsers to: [href] {text-decoration:underline;color:blue;cursor:pointer;} and your done.

    Imagine , or .

    Opera demonstrated with its support for Web Forms 2.0 (http://www.whatwg.org/specs/web-forms/current-work/), that with only some CSS- and Javascript-modifications one could easily extend its browser to handle such new language-constructs.

    • #3
    • Comment
    • Mon 2 Jun 2008
    • 1123
    Kevin H wrote in to say...

    Here’s a whatwg thread on the subject.

    While I wouldn’t be surprised if Ian Hickson or other WhatWG folks find your complaint here on your blog and follow up with it, (especially now that I’ve seeded it with the appropriate keywords ;) ), if you really want the WG to consider it, I would think a mailing list would be a more appropriate place to raise the issue, no?

    Last I heard, these specs are still under development and are subject to revision where a good argument can be made, and I’d say a good argument could be made for href on <tr> elements, at the least.

    • #4
    • Comment
    • Mon 2 Jun 2008
    • 1124
    Devon Young wrote in to say...

    The HREF’s being applied to any element, was always one of my favorite ideas too. Nice clear post on why it really can be and should be added into HTML5. Gives me an idea for a new post…

    • #5
    • Comment
    • Mon 2 Jun 2008
    • 1205
    Kevin H wrote in to say...

    p.s. I don’t think you ever made it clear that you were looking for href semantics in your post about javascript event handling. If that is all you needed, then I believe the following simple code would have sufficed:


    function rowclick()
    {
      alert(this.getAttribute('href'));
    }


    function init()
    {
      var tbl = document.getElementById('someTable');
      var rows = tbl.getElementsByTagName('TR');
      for (var i=0; i<rows.length; i++)
      {
        if (rows[i].getAttribute('href'))
        {
          rows[i].onclick=rowclick;
        }
      }
    }

    • #6
    • Comment
    • Mon 2 Jun 2008
    • 1215
    Jay wrote in to say...

    Right on Eric. Makes more sense to do it your way.

    • #7
    • Comment
    • Mon 2 Jun 2008
    • 1259
    Chris wrote in to say...

    I don’t know the “correct” usage of the href tag but it seems to me to be notably different from an onClick event. href, if I had to guess, is in its most abstract, “correct” usage is a property to indicate a relation. Now this makes sense for XML: XML can be queried via XPath and XML is often used to express relational data. HTML 5 is a completely different ball game, and while HTML 5 fits neatly into the syntax and largely into the purpose of XML, we still refer to them by two different names because the differences between the two are still notable.

    In the meantime I’m a big advocate of extension toolkits like jQuery, which make adding arbitrary onClick events into simple one liners.

    • #8
    • Comment
    • Mon 2 Jun 2008
    • 1314
    Anne van Kesteren wrote in to say...

    It would help if you explained what you would use this for. Is this primarily needed for table rows?

    • #9
    • Comment
    • Mon 2 Jun 2008
    • 1315
    Anne van Kesteren wrote in to say...

    (Also, it would be nice if you could post your comments on HTML5 on either the W3C HTML WG or WHATWG mailing list. That makes tracking comments easier. We do try our best to track blog comments as well though.)

    • #10
    • Comment
    • Mon 2 Jun 2008
    • 1404
    Lars Gunther wrote in to say...

    Let’s not forget that adding href also means adding hreflang, type, ping (in HTML 5) and some other stuff.

    Besides tr, td and th, I think it would be very hard and confusing to bring href to anything but simple subset of the inline elements: abbr, dfn, and perhaps two or three more.

    Since JAWS and other screen readers use links to quickly navigate a page, that is also a concern. I have no answers, though.

    • #11
    • Comment
    • Mon 2 Jun 2008
    • 1404
    Matt Wilcox wrote in to say...

    The ‘browser vendor’ argument always annoys me. Get off your backsides and program the things that designers need! Seriously, why is so much stuff ‘impossible’ (no, you can’t have href on all elements. No, you can’t have a parent selector. Why? Because we say it’s too hard). Yet what are these things really? How is it so hard as to be impossible to implement when you can write a JS hack to do the same things? When we live in a world where you can boot up a PC and play online games with thousands of other people over numerous networks, using multitudes of different hardware, in true 3D worlds that are near photo-realistic, featuring complex interactive physics: but we can’t have a parent selector in our browser. That is a joke, and it’s not funny. It almost feels like browsers are being forced into obsolescence by engineers that don’t want to see them survive. Is our future going to be Silverlight and AIR? I hope not.

    Utterly agree with your points Eric. The HTML5 WG and the W3C just dont seem to be headed in any useful direction (still).

    • #12
    • Comment
    • Mon 2 Jun 2008
    • 1453
    Eric Meyer wrote in to say...

    Kevin, thanks for the pointer! I see Shannon made pretty much exactly the same points I did, only three months earlier. He or she also makes a point I meant to include but cut for focus, which is that backwards compatibility concerns can be further nullified via DOM scripting for older browsers (crawl the document for non-a elements with href attributes and slap an (on)click on ‘em).

    Anne, the use cases are many. My specific use case last week was table rows, but off the top of my head, I would add the href to at least the following HTML4/XHTML1 elements based on what seem like fairly obvious use cases:

    tr, th, td, caption, li, img, cite, blockquote, dfn, abbr, acronym, code, tt, kbd, var, span, legend, h1, h2, h3, h4, h5, h6, address

    …and I’m pretty sure there must be several more where I’m just not remembering an element or coming up with a valid use case.

    I can’t keep up with the HTML5 mailing list, unfortunately, which is why I’m not a member.

    Lars, I’d be happy to see those attributes come along. rel and rev should also come along for the ride, assuming they survive.

    • #13
    • Comment
    • Mon 2 Jun 2008
    • 1601
    Wolfgang Löer wrote in to say...

    i totally agree!

    just recently i cursed the href limitations, because i wanted full semantic “teaser-boxes” (divs including h2, img and one or more p) to link to the corresponding pages.

    i think it is much more convenient and user-friendly to simply klick the whole box instead of seeking out the title or an “read more” towards the end.

    • #14
    • Comment
    • Mon 2 Jun 2008
    • 1629
    Paul D. Waite wrote in to say...

    My favourite from XHTML 2 was the <section> element, with the <h> element inside it, instead of your <h1>s and <h2>s.

    • #15
    • Comment
    • Mon 2 Jun 2008
    • 1638
    Martin wrote in to say...

    To me, it seems like a bad idea to rely on scripting to maintain backwards compatibility, what happens when you disable javascript?

    It would be nice to have the href attribute though, I’ve felt the need for it in the same situation as Wolfgang.

    • #16
    • Comment
    • Mon 2 Jun 2008
    • 1645
    Daniel wrote in to say...

    Matt, javascript libraries can implement parent selectors because they don’t have to deal with the dynamic nature of HTML or operate at the speed we’d expect of a browser CSS implentation.

    With current CSS a browser can know what CSS selectors to apply to a given element by just examining it’s parents and earlier siblings of it and its parents (this might not be true for all pseudo selectors). So when incrementally rendering a document only the previous elements need to be examined so they can tell which CSS selectors to apply when they start rendering an element. With parent selectors previous elements would need to be revisited as more elements are added, possibly causing multiple reflows during the rendering of a page.

    When elements are dynamically added only their descendants, their siblings and their siblings’ descendants can possibly be affected with current CSS. With parent selectors every element in the document can be affected so adding an element could become very slow.

    Calculating whether a given element matches a given CSS selector would also greatly increase in complexity (I suspect it would be an increase in the big O complexity). I imagine that if any caching schemes are used to speed up CSS calculations as the document changes they’d be a lot less useful with parent selectors.

    I’m not a browser implementor so I imagine there are further problems that I haven’t anticipated. Which is to say that if the browser implementors say that something is difficult to implement, then they might just be talking from experience that you and I don’t have. Some javascript which does a fraction of what you’re asking them to do and at much slower speed than would be acceptable does not prove them wrong.

    • #17
    • Comment
    • Mon 2 Jun 2008
    • 1646
    Michael R. Bernstein wrote in to say...

    Paul, mine too. That one feature would make creating modular templates *so* much easier, not to mention giving a huge boost to the reusability of the markup and CSS.

    • #18
    • Pingback
    • Mon 2 Jun 2008
    • 1701
    Received from XMLRPC Test » GR Shared Link - The Missing Link

    [...] The Missing Link [...]

    • #19
    • Comment
    • Mon 2 Jun 2008
    • 1754
    Lanny Heidbreder wrote in to say...

    The browser-vendor argument is bunk. If it’s possible to do :hover on arbitrary elements and nested elements, then it’s possible to make a click on those elements do whatever you want.

    I’ve always heard that stuff like table column background colors can’t be done because there’s no good way to specify its behavior in a progressive-rendering model. I don’t understand why the standard has to make absolutely everything possible with progressive rendering, or indeed why it has to have anything to do with the each browser’s rendering algorithm at all.

    IANAProgrammer, though, so what do I know?

    • #20
    • Comment
    • Mon 2 Jun 2008
    • 1838
    Nico wrote in to say...

    @Chris: Xpath works on the DOM and a HTML5 and XHTML5 document can be represented in the same DOM. So you can use Xpath for HTML5 – you only need a different parser for the document.

    • #21
    • Comment
    • Tue 3 Jun 2008
    • 0034
    Nick Harvey wrote in to say...

    I think I agree with you Eric. I’ve been trying to follow the discussion on the whatwg disuccion list and the argument feels like it is going in circles. I’m with you that the backwards compatability argument is erroneous, surely any new specification will introduce anomolies with previous editions otherwise what the point of having a new specification. Besides, as long as the href attribute is not removed from the anchor element in HTML5, where will compatability be affected?

    IMHO links are not truly semantic, they are behavioural, so why should we have to resort to additional markup to achieve them. Put the behaviour into any tag and resolve the conflict.

    • #22
    • Pingback
    • Tue 3 Jun 2008
    • 0035
    Received from JasonMorrison.net » Blog Archive » XHTML 2 vs HTML 5 and the href Attribute

    [...] Eric Meyer has at least one point in XHTML 2’s favor – the ability to add and href attribute to anything, making it a link.  In addition to making the <a> tag jealous, this would let you do some pretty cool stuff like turn an entire table row into a link in a dynamic data reporting web app without a lot of Javascript or duplicated tags. [...]

    • #23
    • Comment
    • Tue 3 Jun 2008
    • 0540
    Anne van Kesteren wrote in to say...

    Eric, those are not really use cases. That’s a list of syntax proposals that you feel solve a certain problem. I can certainly come up with use cases for some of them, but they don’t really seem convincing. (The table row case sort of is though and is probably worth investigating more.)

    As for the mailing list, it’s not a prerequisite to keep up with it. You can just filter out most of the e-mail apart from the bits that interest you.

    • #24
    • Comment
    • Tue 3 Jun 2008
    • 0620
    David Owens wrote in to say...

    @Paul and @Michael,

    The section element is in the current HTML5 spec. There are still different header elements, but they take their importance relative to the (possibly nested) section they are in, rather than the document.

    • #25
    • Comment
    • Tue 3 Jun 2008
    • 0638
    Eric Meyer wrote in to say...

    Anne, perhaps you could define exactly what constitutes a “use case” so that I know what standard I have to meet.

    • #26
    • Comment
    • Tue 3 Jun 2008
    • 0706
    Sander Aarts wrote in to say...

    @Anne: I’d say that all block-level elements that may contain other block-level elements would benefit having a href= attribute. The use case for all would simply be when you need the whole element and all of it’s descendants to redirect to another location. Block-level elements that can only contain inline elements, like p, don’t need this as the good ol’ a will do the job.

    • #27
    • Comment
    • Tue 3 Jun 2008
    • 0714
    Sander Aarts wrote in to say...

    Introducing a new block-level anchor tag may be more easy for browser vendors to implement. Not sure if that is to be prefered though.

    • #28
    • Comment
    • Tue 3 Jun 2008
    • 0730
    jgraham wrote in to say...

    Eric, a use case is a description of a problem that (probably one that you have encountered) that (presumably) does not have a clear existing solution. So, for example, the use case statement you have above is

    a table where each row contains several cells of of summary data, and there is a desire to be able to click on a row to get more detailed information via a search keyed off that summary information

    given that use case it is also helpful if you can suggest several possible solutions and what the pros and cons are of each. so, to meet the use case you have here allowing href on tr is only one possible solution. Other possible solutions for this use case include:

    * Using javascript onclick handlers (pro:works in many UAs today, con:does not work when scripting is disabled, requires authors to know javascript to fulfil the use case)

    * Making the content model of <a> transparent (pro:works in many situations in many UAs today, con:doesn’t work well in tables due to special parsing requirements, may make conformance checking less useful)

    * Adding a new block-level element that has a transparent content model (pro:no parsing problems, con:doesn’t work in UAs today, requires scripting for legacy support)

    for more details on how to describe use cases and possible solutions, see this email from Hixie. The key idea is that use cases are descriptions of problems that should be solved rather than descriptions of solutions to problems.

    I also second Anne about the mailing list thing; there is really no need to read everything that gets posted to the whatwg list or public-html in order to productively contribute to those lists. It is clear that some of the most useful contributions are from people who simply ignore everything but the area in which they have a particular interest.

    • #29
    • Comment
    • Tue 3 Jun 2008
    • 0826
    Sebastian Redl wrote in to say...

    > Browser vendors have reported that implementing it would be extremely complex.

    Other browser vendors have already implemented it. I believe Mozilla supports xlink:href on all elements.

    • #30
    • Comment
    • Tue 3 Jun 2008
    • 0949
    J. King wrote in to say...

    Eric, I think what Anne means by a use case is something along the lines of: “For each element upon which you would like to have ‘href’, detail, with specific example, why this would be useful.”

    • #31
    • Comment
    • Tue 3 Jun 2008
    • 1106
    Anon wrote in to say...

    J King: That’s a bit unrealistic, isn’t it, given the number of HTML elements there are? Shouldn’t the point be: justify why the majority of elements should NOT support the href attribute.

    • #32
    • Comment
    • Tue 3 Jun 2008
    • 1756
    Maniqui wrote in to say...

    Although on a first read, I thought: “hey, this is a good idea”, I think I still don’t get it, sorry.

    Wouldn’t this make the <a> element totally unnecesary? (this isn’t necessary a problem)
    What about nested elements where both parent and child have a value for the href attribute? And in this case of nested “links”, wouldn’t this arise some serious accessibility problems? It’s difficult enough for some people to click on a single isolated link; nesting an “inline-element link” on “block-element link” could really be a new challenge for navigating?

    I hope I’m not missing something here.

    • #33
    • Comment
    • Tue 3 Jun 2008
    • 2150
    Ben Buchanan wrote in to say...

    I’ve found the WHATWG use the backwards compatibility argument whenever it suits their decision, yet ignore the same issue with all the new elements they ARE creating.

    The biggest failure for me was the lack of a generic, extensible heading system. XHTML 2 had h+section, HTML5 just has h1-6 but it DOES have section. Because that makes sense. H wasn’t ok, but SECTION was?

    I’m starting to think we’ll never use HTML5, something else will come along and bypass it.

    • #34
    • Comment
    • Tue 3 Jun 2008
    • 2230
    Isaac Lin wrote in to say...

    Anon: no, the reverse is far more work since it would be a never-ending tasking of justifying why every existing and proposed attribute didn’t belong on every existing and proposed element. Note too that by understanding the use cases (i.e. problems) that need to be addressed, we can potentially identify what elements have common characteristics that are at the root of the problem, and so the rationale behind the proposal can encompass all of these common elements at once. This is one of the values of working out a clear use case: it helps you step back to look at the problem from a wider perspective.

    • #35
    • Comment
    • Wed 4 Jun 2008
    • 0104
    Henri Sivonen wrote in to say...

    Ben, HTML5 has a system like h+section. In that system, h is just called h1.

    • #36
    • Comment
    • Wed 4 Jun 2008
    • 0433
    Anne van Kesteren wrote in to say...

    Sebastian, xlink:href in Mozilla does not actually work on HTML or SVG elements last I checked. (It apparently didn’t come for free when implementing it.)

    • #37
    • Pingback
    • Wed 4 Jun 2008
    • 0848
    • #38
    • Comment
    • Wed 4 Jun 2008
    • 2121
    Ben Buchanan wrote in to say...

    @henri: I do not consider a document full of h1 elements to be the same as a document using h elements. h1 has an existing meaning and personally I only use one h1 per document. So it is my opinion that a document full of h1s is not a proper contextual heading system, it’s a halfway hack.

    I also fail to see any logical reason why you would allow the addition of section yet decide that h should be left out because it’s “not backwards-compatible”. If you use section, Firefox and IE aren’t going to be able to read and style the page properly (based on a quick test, Opera and Safari allow styling via section). Remember you’re going to have to use section to contextually style all those h1s into something with a visual hierarchy, which will break in non-html5 browsers just as much as h would break.

    Anyway, I’ve had this argument before and I know HTML5 isn’t going to have h. The working group’s decision making process just bothers me, and it appears to bother at least a few other people as well.

    • #39
    • Comment
    • Thu 5 Jun 2008
    • 0641
    Anne van Kesteren wrote in to say...

    Ben, Firefox 3 will allow proper styling of section and for Internet Explorer you need to use the document.createElement('section') hack for a while I suppose. Using h would mean that older assistive technology for instance doesn’t even recognize it as a heading and not use it in the document outline. That seems bad. The styling issues you mention we’ll have to overcome anyway. Using h will not magically solve those. In fact, it’s not really clear what problem h using would solve.

    • #40
    • Comment
    • Fri 6 Jun 2008
    • 0831
    Vlad Alexander wrote in to say...

    Anne, help me understand why HTML 5 folks don’t think that changing the meaning of numbered headings will not confuse users? Headings are the most important construct for making Web pages accessible but almost nobody uses numbered headings correctly. Why not fix this serious problem? The section/h construct is the best solution.

    The section/h construct must also be structured just like tables, definition lists, and ordered/unordered lists. Every section element must have one h element as the first element. For example:

    <section>
    <h>…content goes here…</h>
    … content and other section elements go here …
    </section>

    As an authoring tool vendor, we believe that the use of structured section/h construct is the only way to ensure the correct use of headings in authoring tools.

    • #41
    • Pingback
    • Mon 9 Jun 2008
    • 2249
    Received from Trevor Davis | Blog | Weekly Link Round-Up #34

    [...] The Missing Link [...]

    • #42
    • Comment
    • Fri 11 Jul 2008
    • 2205
    gossard wrote in to say...

    Sebastian, xlink:href in Mozilla does not actually work on HTML or SVG elements last I checked. (It apparently didn”t come for free when implementing it.)

    • #43
    • Comment
    • Thu 17 Jul 2008
    • 0512
    Chicco wrote in to say...

    Well, technically speaking there is more than one way to do this and make it compatible with a range of browsers.

    I can’t see specific technical usage for extending “href” attribute to tags like “tr” but I guess this would turn to be useful to (smart) marketer… ;-)

    Cheers/Chicco

    • #44
    • Comment
    • Tue 22 Jul 2008
    • 1125
    Rexibit Web Services wrote in to say...

    True Chicco, but again it comes to how you want to conform your site to the standards. If you are going to create links, they need to be usable over various other mediums as some sites to pull content off yours to theirs. I doubt they would continue to help build your links and content distribution if you were causing them validation errors.

    • #45
    • Comment
    • Tue 1 Sep 2009
    • 1109
    Tony wrote in to say...

    Gawd. I don’t know when my brain got things mixed up, but up until about 20 minutes ago I thought that the @href attribute was going to be global in HTML5.

    GRR!

    Regarding the following: Browser vendors have reported that implementing it would be extremely complex.

    I would echo your response to reason #1: Neither [ were tons of things implemented in several browsers ] or any number of other worthwhile advancements in the web.

    I mean, is it easy to get a browser to pass Acid3? I don’t personally know for sure, but I’m going to go with No. But browser vendors still work for it.

    Gah, Eric, please beat some sense into the spec authors on this point!

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


June 2008
SMTWTFS
May July
1234567
891011121314
15161718192021
22232425262728
2930  

Sidestep

Feeds

Extras