HTML5 details element, built-in and bolt-on accessibility
Now that the HTML5 spec is settling down, we’re seeing a resurgance of people attempting to cut good bits out. One of the latest targets is the very useful details element. This is an expanding and contracting element that you can use to “hide” more details without JavaScript. It’s not supported anywhere yet, but my glamorous co-author Remy cleverly fakes it on his 2010 Full Frontal conference page. His code is
<details>
<summary>Get in touch</summary>
<p>Interested in sponsoring? Get in touch.</p>
</details>
If you click on the text inside the summary element (which defaults to the text “details” if absent), the details element expands. Click again, and it contracts.
Anyway, the argument against this element is that it duplicates what you can do already with a div, some JavaScript and some WAI-ARIA information to add role and state information to this widget. That’s true, but it completely misses the point that one of the reasons HTML5 is so interesting to developers is precisely because it greatly simplifies web development, meaning you don’t have to muck around with script and ARIA.
The new HTML5 forms UI widgets and validation (supported in Opera), for example, are entirely superfluous, you could argue, because you can do the same in JavaScript. Why have built-in sliders for input type=range or input type=date or even good old fashioned textarea when you could have one single input element and script everything else?
The answer is because it’s much more hassle to pull in script and keep role and state info with ARIA. It’s much better to build these things into the language, with built-in accessibility because the browser vendors bake in role and state information and hook up the widgets to the operating system.
Expecting developers to reinvent this wheel every time is “bolt-on” accessibility, and we all know that they won’t actually do it. Yes, they can use a library. I’ve seen the whole jQuery library pulled in just to make an expando box behave like details.
I refer you to John Foliot, whose email to the HTML Working Group makes an excellent argument that explains the subject much better than I can. I should add that Foliot is by no means an HTML5 cheerleader and is a great advocate of accessibility and ARIA. His main points are
- Elements are better than attributes for semantics, javascript, css
- If something needs to be referenced you should normally make it an element, with an id attribute
- If something represents a separate entity, make it an element: you might want to add attributes later
- having a simple element express something instead of requiring a bunch of lines of scripting is way more efficient.
- moving functionality into the browser natively, instead of relying on scripting which requires additional CPU is an efficient design choice
- having ‘accessibility’ built-in rather than bolt-on (which is what ARIA is) is a fundamental desire of most of us in the a11y community.
I recommend you read the whole email and his blogpost Thoughts on <details> versus @summary .
Added June 2011: Implementing HTML5 <details>.
48 Responses to “ HTML5 details element, built-in and bolt-on accessibility ”
I’d like to see captions/ transcript work that way too. Too many attributes gets too confusing.
personally, i don’t like this because it’s so strangely specific to one single effect. why not define another element for an accordion menu? and another one for a dropdown menu? or an image carousel?
it seems arbitrary that the spec should have a baked-in effect like this little expando-thing…unless i’m missing the point completely…
Bruce, these questions have to be answered before introducing declaractive elements into production use. We can’t toss the elements up and say, well we’re about these issue later.
In current applications is JS is turned off, collapsed sections should be displayed by default. People are used to this now. What happens when we start to introduce inconsistent behaviors?
As for the print, typically printed pages are either printed with a separate CSS, whereby everything is open by default, or, at a minimum, jS is turned off. The details element operates outside of this normal, standard web environment.
What does it add that makes up for the problems it will cause. What does it enable, to compensate for the unresolved issues?
And your bullet list — what is the reason for each item. They’re a statement of fact, but what is the background to justify them being considered as facts?
I hate comment boxes and GMail. Typo city.
Should say:
“We can’t toss the elements up and say, well we’ll worry about these issue later. “
I should add that Foliot is by no means an HTML5 cheerleader…
Hey Bruce, that’s not quite true, nor fair. I am a huge fan and supporter of HTML5, as it will, when done, advance web accessibility significantly. I stand diligent however to ensure that we do the very best we can do, as we craft this next generation mark-up language, to ensure that accessibility remains a big winner.
Shelley Powers wants to know why elements are better than attributes. I did respond to that question in an email to the HTML WG Mailing List, but it seems she doesn’t want to hear (or doesn’t like) the answer.
In HTML (and XML) elements are the basic building blocks of our DOM structure. Elements are clearly defined and easily processed by parsing agents. We can extend properties to these basic building blocks using attributes, but be very clear, attributes are *additional* properties added to a basic element, and extending those additional properties requires both additional code, and additional effort on the part of the author. Demanding that authors add additional code to any element to ensure that it ‘becomes’ accessible is problematic, as any author who fails to add these extra properties (either through negligence or ignorance) has now created a ‘thing’ that is not accessible. This is the ‘bolt-on’ approach to accessibility that the accessibility community has been working to eliminate for years. (Yes, ARIA is itself a bolt-on solution, but that’s simply because it was designed as a retro-fit solution. Given the choice between bolting on accessibility, or having none, the choice is clear. However ARIA is not optimal for the very reason that it *is* bolt-on, and if we can do better this time, we should.)
Having an element that has explicit rules for processing, including the accessibility requirements, ensures that when the author uses said element, the accessibility comes as part of the element, no additional effort required. Identifying common, repeated patterns in existing markup (as HTML5 has done) and taking common attributes from these patterns to create new elements is an efficient choice, as we can now also ensure that these elements are accessible ‘out of the box’ as well. As I explained to Shelley in that subsequent email, we can certainly perpetuate a pattern that reads or we can admit that eventually we need a new element: . I ask you, which makes more sense, which is easier to author, and which would *you* rather use? Arguing that we continue to use from here on in is inefficient, short sighted and sub-optimal, as it leaves open the possibility of authors simply creating (which would be accurate, but incomplete).
I want to be very clear; ARIA is extremely useful and should hold an important place in the hierarchy of the HTML5 stack. At the same time however, every move we can make to reduce the need for ARIA by shifting the accessibility bits higher up that stack is a move we should embrace fully today. I cannot fathom arguing to maintain the status quo, when we can do better moving forward.
(And as for how the details element *should* be rendered in print? Why, use a print style sheet of course! Perhaps you might want to style the details element as a footnote: http://www.w3.org/TR/css3-gcpm/#turning – again, elements are also easeir to work with when styling or scripting:
details {
float: footnote;
}
…seems pretty obvious to me.)
(Grrr… trying this again)
Having an element that has explicit rules for processing, including the accessibility requirements, ensures that when the author uses said element, the accessibility comes as part of the element, no additional effort required. Identifying common, repeated patterns in existing markup (as HTML5 has done) and taking common attributes from these patterns to create new elements is an efficient choice, as we can now also ensure that these elements are accessible ‘out of the box’ as well. As I explained to Shelley in that subsequent email, while we can certainly perpetuate a pattern that reads <hole-in-a-wall class=”window”> or we can admit that eventually we need a new element: <window>. I ask you, which makes more sense, which is easier to author, and which would *you* rather use? Arguing that we continue to use <hole-in-a-wall class=”window”> from here on in is inefficient, short sighted and sub-optimal, as it leaves open the possibility of authors simply creating <hole-in-a-wall> (which would be accurate, but incomplete).
John, what makes you think it’s easier for a developer or designer to have to create an element than it is to create an attribute.
If you use the DOM, to add or remove an attribute is one function call. To add or remove an element is, at a minimum, three lines of code. Or more. Where did people get the impression that elements are somehow easier than attributes?
As for ARIA and the “stop gap” attitude about it, when you get all browsers and other user agents to support something like aria-hidden, then you can use aria-hidden in many widgets. When you package widget behavior, you then have to go out and advocate accessibility for _each and every widget.
Example: input type=datetime is implemented in Opera. But it’s not implemented accessibly. And you can’t style the calendar that pops up, because _it is not part of the DOM.
Yet alternatives available now are accessible, and can be styled and customized.
Patrick also has a very pertinent point: why details? Why not tabbed pages, and accordion, and any of the other dozens, hundreds of widgets?
Even if these items become available in browsers, are they available in the HTML editors? The WYSIWYG
editors? The lint tools, such as HTML Tidy? No, and there’s a darn good chance they may not, either. Many of the developers of these tools do not like HTML5. They feel it’s sloppy and introduces conflict, as well as applying arbitrary and difficult to implement conformance rules. Many feel they’ve been ignored by the browser companies.
Regardless, I’d rather see this discussion energy directed towards write ups in the HTML WG that I can respond to once, rather than by bits and pieces and Twitter and comments here and there.
I’m also getting a little tired of the personal attacks against me, because I do disagree with the inclusion of these elements. I’ve had my arguments called “tripe”, and been accused of being “awful” to members of the accessibility community _just_ because I disagree.
1) Shelley Powers has put forth a *Change* Proposal – it is incumbent on her to build support behind this requested change; it is foolish to suggest that others must put forth other Change Proposals to counter her proposal. To be clear, myself personally, I don’t want any change, so there really should be nothing I need do.
2) Shelley asks:
…what makes you think it’s easier for a developer or designer to have to create an element than it is to create an attribute.
I didn’t say that. However, it’s very basic: attributes are children of elements; you can have an element without any attributes, but you cannot have an attribute without any element. *I* want baked in accessibility without the need of attributes whenever possible, because if you rely exclusively on attributes to extend accessibility, there remains a chance that the attribute will not be added – a point of failure we should be able to address.
3) Shelley seems aghast and surprised that ARIA is a stop-gap solution (albeit one that is actually getting some traction – hurrah). Yet, if you’ve spent any time working in the field of web accessibility, you would know that this ‘stop-gap’ approach was by design:
Up to now, the roadmap has addressed current (X)HTML markup as supported by today’s desktop browsers using ARIA. The markup in today’s browsers, like accessibility, requires developers to do things manually through the use of JavaScript. While this is extremely flexible, it suffers from a number of problems:
Although improvements have occurred, JavaScript does not behave the same on all browsers and platforms.
Data models are inconsistent.
Accessibility is bolted on, rather than being built in.
Accessibility solutions remain more device-dependent than they should be.
Heavy accessibility lifting is done by the author in line with the way JavaScript is used.Through the use of declarative markup and tight integration of accessibility into the application framework, we can produce more consistent cross-platform solutions which support accessibility and reduce the enablement efforts of the author.
http://www.w3.org/TR/wai-aria-roadmap/
4) Shelley also states:
Many of the developers of these (authoring) tools do not like HTML5. They feel it’s sloppy and introduces conflict, as well as applying arbitrary and difficult to implement conformance rules. Many feel they’ve been ignored by the browser companies.
Many? I know of one (Vlad Alexander of XStandard), but can Shelley point us to other editor developers who share Vlad’s perspective? There are numerous standalone editors out there, including very large tool-sets such as the Creative Suite from Adobe, which includes an industry staple: DreamWeaver (how do they feel?), as well as some very well known plug-in WYSIWYG editors (TinyMCE, CKEditor, etc.) – I am unaware of their “concerns”, but look forward to hearing them as part of any dialog.
5) Dialog *has* happened on the HTML WG Mailing List, and to date it has generally not found a lot of support for Shelley’s Proposal. That she is frustrated about this I can understand, but her Change Proposal was put forth with little consultation of the larger Working Group, and in particular with the Accessibility Task Force set up to work on accessibility issues within the emergent HTML5 specification. As she is requesting a change that runs counter to the work and efforts of the WAI over the past decade (vis-a-vis “bolt-on” solutions), it really should not be surprising that there is little interest from that quarter.
6) I personally have discussed this with Shelley in a number of fora, and have striven to remain professional and to not make this personal. If at any time it has appeared otherwise, I will publicly apologize for that, as it is neither my intent nor desire. However, I remain adamant that Shelley’s proposals introduce potential failure points w.r.t. accessibility, and I cannot in good faith support them.
[…] I’m not the only one seeing this, btw. It’s not that we’ve too many cooks in the kitchen, but that the cleaning staff […]
Re: what will web editor creators like Adobe (Dreamweaver) and Microsoft (Expression Web) do with HTML 5?
In my experience as an Adobe Community Expert and Microsoft MVP they will add the new elements to the next version of their editors when either the specification became a published recommendation or there is substantial browser support.
Fortunately both of those programs are extensible and people can add support even before the program’s developers do. So folks won’t have to wait to implement HTML 5 of they do not want to do so. That’s how support for php first appeared in Dreamweaver for example.
What other smaller companies do depends on then market but both Abode and Microsoft have government agencies as major clients so anything that helps create accessible code will be something they will want to implement sooner rather than later.
I wrote a follow up posting on this to the HTML WG:
http://lists.w3.org/Archives/Public/public-html/2010Apr/0157.html
A few thoughts more: many of the new elements in HTML5 aren’t yet perfectly rendered across all browsers – HTML5 being very much a work in progress. However, using Shelley’s justifications, we might as well also drop <video> and <canvas> too, as a) neither are accessible *today*, b) we can already do these things using other common and hugely deployed tools in hand today (yes, I mean Flash).
(And for those of you that go, but, but… it’s essentially the same argument on why I prefer not to use scripting to supply accessibility – there is too much overhead and many just shy away)
I also find it interesting that Shelley’s original proposals centered so heavily on accessibility, yet when holes were punched in that argument she heads of to find more. Now it just sort of looks like “I don’t like them, and I’ll just keep poking until I can find a reason to kill them”
I humbly suggest that rather than eliminate great ideas based on incomplete implementation today, that efforts would be better focused on identifying current and existing issues and working towards getting them fixed (as Bruce and Patrick Lauke are doing at Opera). In this regard, the note quoted in Shelley’s latest post from Doug Sheppers (W3C CSS WG) about looking to ensure that CSS is properly extended to these new elements is a far more productive path forward. Take the win we get from more semantic elements (and their baked in accessibility) and make them “world class” w.r.t. CSS and scripting.
We all benefit in the end.
Notice in my post that I’m focusing on specifics.
Not generalities. Specifics. And you’re welcome to respond in the email list with specifics. Bruce, you can respond via link in the bottom of the archive page if you’re not a member.
http://lists.w3.org/Archives/Public/public-html/2010Apr/0157.html
You can also provide a counter-proposal, I believe, even if you’re not a member. Check with the co-chairs on that one.
John, I listed several very specific issues related to the built in elements versus either using existing elements (such as a div and img for figure) or using a script library (for progress). You might want to use that as a basis to respond.
Or you can also write a counter proposal, since the chairs have called for these now. Or not, your choice.
As for why my original reasons for focusing on accessibility, I answered that: because that was that rationale given by the editor, and the only rationale given by the editor.
Perhaps you didn’t read my response to Jonas that included this explanation.
Specifically: Shelley’s proposals are bad for accessibility, as it/they perpetuates the ‘bolt-on’ philosophy to access, by suggesting that authors can use ARIA to add the accessibility bits to their code-base – bits that are not natively present. When authors don’t (by design or accident) we have a failure, and there is very little we can do about it: it is a failure of the author, not the technology.
Creating stand-alone elements that have specific accessibility hooks/semantics integrated directly within them ensures that accessibility is bound directly to those elements, not added to after-the-fact. Authors need only use the appropriate element, and the AT and User-Agent work seamlessly to ensure access: if it isn’t perfect today (for example, poor CSS support), that can (and should) be worked on – it should *not* be a reason to abandon this approach.
Specifically, this kind of behavior has been requested and advocated for since at least 2007, by the highest ranking advisory committee within the W3C’s Accessibility Working Group (the PFWG – Protocls and Formats Working Group): http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html (so it’s not just John that is saying this, it is, in fact, the current consensus position within the WAI community of experts, including those who actually developed ARIA in the first place – who else but they would be more aware of the shortcomings of what they wrought?)
Specifically, most content authors I’ve spoken to about this are in agreement that this both makes sense, and is efficient and useful moving forward (as opposed to remaining stuck in 2010 solutions). Not a single one of them has expressed concerns about ‘cost’.
Intentionally or otherwise, Shelley your proposals specifically shackle accessibility advances, and should not be considered for *THAT REASON ALONE*.
I am aware of some counter-proposals coming forth soon, and will watch to see what happens there. I have all of April to decide if another counter-proposal is in fact required. There is also the CfC (Call for Consensus) process, which must be followed whether or not alternate proposals or counter-proposals emerge, and if the CfC is tight, a vote might also be considered as well.
John, you seem to believe that if these elements are released, developers will immediately flock to their use. I find it unlikely that most will be used. They are inferior to what we have, and most developers won’t use an inferior product.
Seriously, no one is going to use hidden. “Material that isn’t relevant” What an inane and vague description. And it’s the exact same thing as aria-hidden…except there’s nothing about its accessibility in the HTML5 spec. Nope, not a thing.
Then there’s the progress element that differs across platforms, and even browsers. Oh, and it can’t be styled. Yup, that one will go over well. But better than meter, who know has a clue what it’s about.
But there’s something else about them — there’s nothing in the spec about how they map to the accessibility APIs. Nope, not a thing. You all will have to negotiate with each and every browser to get this. You’ll have to file bugs, and pester. Why? Because it’s not accessible.
I could go on, but I’m tired of talking to air.
I would think a better use of time for accessibility is stop referring to ARIA as a “bridge”, a “stop gap”, or “bolt on”, because all you do is give developers the idea that, what the hell, maybe we shouldn’t add ARIA to our libraries and applications.
After all, the accessibility folks don’t seem to believe in it.
That’s the message being sent. That’s what we’re hearing.
Bruce, yes, you have to propose a counter-proposal. Several people are working together as a team, maybe you can join them?
Joke: How many WhatWG members does it take to counter my change proposals? Evidently quite a few.
Well, I thought it was funny…
And this should be worth a glance for you John — Webkit folk desperately trying to implement accessibility into the progress element, making up roles as they go. This ought to go well.
Oh, yes. Yes indeed. Really superior option.
I take exception to Shelley’s comment, as it completely ignores history and the actual design intent of ARIA, which was developed (starting close to a decade ago) to retro-fit content that was inaccessible for a variety of reasons. As a retro-fit solution, it is *very* clever and well done, but as it still requires additional effort and code on the part of the author, it is less optimal than using specific native elements which require no additional effort on the author’s part to convey meaning; for example <button> (see how you know what that is, no ARIA required?) Even the W3C admits that using ARIA, while strongly recommended, adds to the developer’s workload:
Including WAI-ARIA support does require a little extra effort, yet it is not significantly more than usual development. For those developing static Web pages or using libraries with WAI-ARIA built in, implementing WAI-ARIA is fairly straightforward. Developing custom, cross-browser JavaScript widgets is more complex, and implementing WAI-ARIA in these is proportionally more complex. http://www.w3.org/WAI/aria/faq
It is less than helpful to the accessibility cause to have late-comers show up and start telling those who have worked in the field for years (including some of the biggest and brightest stars, including Rich Schwerdtfeger (IBM Distinguished engineer), TV Ramen (Google, developer of Emacspeak), James Craig (Apple), and countless others) that they are wrong. Further, to go onto blogs and tell that community that quoting from the ARIA document is inappropriate does the accessibility community a real disservice. Quoting directly from the ARIA Working Draft:
WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page. This is important because the invention of new types of objects is faster than standardized support for them appears in page languages.
It is not appropriate to create objects with style and script when the page language does provide semantics for that type of object. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively.
It is expected that, over time, host languages will evolve to provide semantics for objects that previously could only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature. Legacy content may continue to use WAI-ARIA, however, so the need for user agents to support WAI-ARIA remains. http://www.w3.org/TR/wai-aria/introduction#co-evolution
Frankly Shelley, please stop spreading mis-information; you are helping no-one, and hurting the web accessibility cause simply to drive your own political agenda. If you believe that the ARIA Working Draft is incorrect, you might still be able to provide your feedback, although the deadline for submissions to the Protocols and Formats Working Group at the W3C was February 2, 2010. It’s really too bad your interest and knowlege in ARIA doesn’t go back that far, as if your observations were valid, they could have been addressed prior to that date in the appropriate forum.
And as Steve pointed out in his writing, just because it’s built in doesn’t mean people will use it. The issue isn’t about accessibility, it’s about whether it’s better to have native elements or use other technologies to create the functionality. In particular, when the native elements are demonstratively inferior, and have a heavy cost to tool builders, are they really the better option?
John, I’ve been in the development community for 25 years, and one thing I know: given two options, we won’t pick the inferior one.
I’ve been creating websites since 1993 and teaching people how to create sites since 1998. It is so much easier to teach people to use native elements than to get them to add ARIA to add in accessiblity when they want bells & whistles.
Yes Shelley, we can all see how <button> is inferior to this:
<DIV id=:rk class=”J-K-I J-J5-Ji L3 J-K-I-JO” tabIndex=0
unselectable=”on” closure_hashCode_l16mgm=”182″ act=””>
<DIV class=”J-J5-Ji J-K-I-Kv-H” unselectable=”on”>
<DIV class=”J-J5-Ji J-K-I-J6-H” unselectable=”on”>
<DIV class=J-K-I-KC unselectable=”on”>
<DIV class=J-K-I-K9-KP unselectable=”on”> </DIV>
<DIV class=J-K-I-Jz unselectable=”on”>Search Mail</DIV>
</DIV></DIV></DIV></DIV>
(Source: http://www.paciellogroup.com/blog/?p=585, taken from Gmail)
And that superior choice of code? Ooops… they forgot to bolt on the ARIA stuff, so guess what? Inaccessible.
Please, stop spreading your FUD. You are right, the issues *is* “…about whether it’s better to have native elements or use other technologies to create the functionality…” and many of us are tired of you telling the world that a retrofit is better than a fresh start. The accessibility experts community believes that semantic elements are better (not just me), the majority of the browser manufacturers and WHAT WG members believe they are better, and through-out this entire time, I’ve not heard, read or seen *anyone* support your proposals or perspective. I know that this bothers you, but at some point, you need to give it up and listen to the crowd, or remain bitter and frustrated.
Bruce, sorry to monopolize your blog here. I don’t believe there is anything more I can contribute to this discussion – I leave it to your readers to form thier own intelligent and informed decisions, and hope that the links I have previously provided help them in their research. I am bowing out now – thanks for the opportunity.
One question: what is my political agenda?
Seriously, Bruce and John, you both have said this. What is my agenda?
Looking at the example :
<details>
<summary>Get in touch</summary>
<p>Interested in sponsoring? Get in touch.</p>
</details>
Details… details of what? p is the details.
Summary… summary of what, the details?, but is a child of details,
A summary of a table I can buy, but a summary of a detail?
English is not my first language, but am I the only one to think this is weird semantics?
I’d rather have something like this
<section id =”mysection”>
<h1>section title </h1>
<p>Default stuff</p>
<p detailsOf=”mysection”>
The details
</p>
</section>
Think of something similar to label input relationship. But this looks like a reverse longdesc so I am not sure this is a good idea either.
It is that HTML already has the necessary semantics to define a details relationship.
I fear that the details element is only a bolt on element to add default behaviour for a something / details relationship. Isn’t that the job of JavaScript? It is like if we would add an ul element because we need indentation (not because we need an unordered list). IMHO this is wrong and ugly.
What if semantically speaking I define some content to be the details of some other content, but don’t want the default behaviour (show hide). What will happen? What’s the impact on accessibility? I really don’t like this.
Do we really want/need a “clickToShow” element? That’s what details looks like to me. Like it or not, that’s its primary function. That is how people will understand it. I don’t think this is good for accessibility in the long run.
[…] HTML5 details element, built-in and bolt-on accessibility […]
[…] HTML5 details element, built-in and bolt-on accessibility – Bruce Lawson’s personal site – possible advantages of HTML5 over scripting and ARIA. […]
[…] HTML5 details element, built-in and bolt-on accessibility – Bruce Lawson’s personal site – possible advantages of HTML5 over scripting and ARIA. […]
[…] HTML5 details element, built-in and bolt-on accessibility – Bruce Lawson’s personal site – possible advantages of HTML5 over scripting and ARIA. […]
Very interesting read.
At first, I thought this was a no brainer, but I must admit Shelley made a few good points.
I don’t think authors go for “superior” solutions though, imho they go for whatever gives them more freedom (room for customization). I’d say the gmail “button” is a good example of that.
If native elements come with unwanted behavior/styling, developers will prefer to go with junk markup if that gives them more power. And *that* will hurt Accessibility (imho).
So on one hand there is the risk that some authors won’t bother using ARIA, and on the other hand there is the risk that these native elements will not be used at all because they come with some string attached to them.
What if these native elements came with an attribute that would let authors turn off their native behavior/styling? Something the end user could switch back on if he wanted to (i.e., via UA’s preferences).
[…] alternative to this approach that we may be able to use in the future. Bruce Lawson provides an interesting summary of details and an argument in favor of using semantic interactive elements over […]
[…] alternative to this approach that we may be able to use in the future. Bruce Lawson provides an interesting summary of details and an argument in favor of using semantic interactive elements over […]
[…] alternative to this approach that we may be able to use in the future. Bruce Lawson provides an interesting summary of details and an argument in favor of using semantic interactive elements over […]
[…] …or use the HTML5 details element. […]
[…] alternative to this approach that we may be able to use in the future. Bruce Lawson provides an interesting summary of details and an argument in favor of using semantic interactive elements over […]
[…] alternative to this approach that we may be able to use in the future. Bruce Lawson provides an interesting summary of details and an argument in favor of using semantic interactive elements over […]
Hi, Neat post. There’s a problem with your site in internet explorer, could check this? IE still is the market chief and a large component to other folks will pass over your excellent writing due to this problem.
Hi Bruce,
I was wondering if you would know why Im having trouble measuring the height of an element which is wrapped in a parent with hidden overflow (both inside a element)
Pretty standard expand/collapse stuff, but for some reason when its inside a element js (well jQuery.outerHeight fn) only reads the padding not actual height.
Ive created a demo to explain it better, both examples share the same css rules and js enhancement yet the 1st example which uses a tag doesn’t work!
Seems fine on every other browser except chrome (safari is fine), its like theres some strange property chrome applies to a element.
Anyway if you have any thought it would be most appreciated.
http://www.iconinc.com.au/tests/chrome-test-case.html
oh sorry in the comment above I didn’t escape <details> so where it says “a element” it should read “a <details> element”
Good web site you have here.. It’s difficult to find good quality writing like yours nowadays. I really appreciate individuals like you! Take care!!
Feel free to surf to my blog :: Spotify What It Is and How To Use It
You and John have both given bullet points, such as elements are better than attributes, but you haven’t said why.
Why? Considering the attributes exist anyway, why is encapsulating a dynamic behavior in Details better than using JavaScript. And what should happen with Details, when JS is turned off? Or it’s used in a print context?
You also don’t cover the costs associated with new elements. Do you consider it negligible?
Regardless, I hope you submit your post as a counter-proposal to the W3C. You don’t have to be a member.