- From: Toby Inkster <tai@g5n.co.uk>
- Date: Tue, 15 Sep 2009 12:30:57 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: Jeremy Keith <jeremy@adactio.com>, Anne van Kesteren <annevk@opera.com>, Simon Pieters <simonp@opera.com>, HTMLWG WG <public-html@w3.org>
On Tue, 2009-09-15 at 11:09 +0000, Ian Hickson wrote:
> Search for "unreliable" in:
> http://lists.w3.org/Archives/Public/public-html/2009Jul/0685.html
hasFeature was unreliable because the features were too broad. Asking
for a boolean answer to hasFeature('StyleSheets') is clearly not going
to give you a useful answer.
Asking for a boolean answer to implements("elements#details") is a
different matter though. To claim that it's the same thing is a false
comparison.
Do you really expect that any browsers will be released with *partial
implementations* of the <details> element? Implementations may be buggy,
but they're pretty likely to be complete.
And even in the case where a browser does implement partial support for
<details> - say, it exposes the element's DOM, but don't offer a way of
expanding and contracting the element - then how does the suggested
alternative:
if (typeof document.createElement('details').open == 'undefined') {
// script that implements <details> here
}
improve matters? The meat of the script will not be executed.
Using <script implements> provides us with a neat, consistent and
readable syntax. People seeing the code above would naturally ask
themselves what is being opened. <script implements> is simple and
declarative. People seeing <script implements="element#details"> can
say: oh, OK, this script implements the element <details>.
Given the amount of script out there on the web at large that does
feature detection, <script implements> would be paving a cowpath,
replacing an ad-hoc approach to development with a consistent,
standardised one.
--
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
Received on Tuesday, 15 September 2009 11:31:42 UTC