W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2013

[Bug 23589] New: Endangered Features : output

From: <bugzilla@jessica.w3.org>
Date: Tue, 22 Oct 2013 03:38:48 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-23589-2486@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23589

            Bug ID: 23589
           Summary: Endangered Features : output
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: CR HTML5 spec
          Assignee: robin@w3.org
          Reporter: crazytonyi@gmail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: public-html-admin@w3.org

Of the 16 (by way of 11 bullet points) features that have been listed as *at
risk* for lack of implementation, some of them I won't miss and I doubt most
ever knew they ever existed. Some of the others be called back before they got
a real chance, but that's the way it goes. But a few I am an almost offended to
see on the list, at the very least incredibly disappointed. The entire list
feels very...superficial. Like the wall of kids who didn't get picked for the
kickball team or the ugly kids in the corner not dancing with anyone at
homecoming. And honestly I'm not sure "lack of implementation" is the right way
to decide which features get's tossed away. Lack of ability to implement, that
would make sense. But unpopular because people didn't make entire blog posts to
rally the troops, that's just throwing something away before the real
developers who are looking for   that one fix or one part that would solve some
seemingly small problem and stumble on a new design pattern, etc etc etc.

So that's my preamble. I plan to submit a bug for each of the features which
don't deserve to be on that list, whether it's on their merits, their true
potential, or simply that whoever did the tally was *wrong*.

And the first one is the nerdiest duckling in the bunch, I think. And the one I
had needed many times but didn't know was an option, let alone was missing:

<output>

First an foremost.  Not implemented?  Maybe not sexy. Maybe not part of a web
app that gives it street cred yet. It's wallflower demeanor keep it off even
the comprehensive lists like:

http://caniuse.com/#search=output

But not implemented. Check again:

http://html5test.com/compare/feature/form-output-element.html

I've never been good at counting and whatnot, but it looks like this friendly,
simple to understand, "hey why not, it'll boost our score" element is
implemented by the current and most recent release of every major browser and
even most gaming consoles. And why shouldn't it be? The value of this element
is not having to store the value of other inputs into some heavily stylized
read-only input. it's basically a div that you can pass a value to. How cool is
that? And maybe that doesn't make for a great blog post, but if you've ever
written a time sheet webapp (which I have and so has my mother, no lie) that
adds in two directions with a grand total, or a billing statement with 15
subtotals *none* of which will ever be writable but could be by a simple DOM
tweak and never should look like they could be writable, but will with CSS
disabled... output was the element that I never new I could have. Now it's on a
chopping block due to "lack of implementation", presumably because Internet
Explorer was focusing on finally getting canvas support and didn't notice this
easy to implement element.

Final note, regarding output. Of the neat new interactive and palpable content,
it looks like IE has taken a pass on output. Why have I still not seen a decent
demo of <menu type="toolbar"> ? Sounds like a really hand idea. And sexy too.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 22 October 2013 03:38:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:45 UTC