This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Doesn't that just mean that we can remove <output> from the list?
Well, since that is my goal with each of these bugs, definitely. It means we can remove output from list. I can only hope that getting the other 4-6 features I'm not wanting to see go off the list could be so easy. I filed a bug because I've checked the draft every few days for over a month and it hasn't changed. My concern is that if someone doesn't advocate for these features, the assumption will be that they won't be missed, without a real check on where the feature is in terms of implementation (obviously if one of the features became the talk of the town, it would survive, but significant implementation but still low like a jump from 3 - 10% implementation may not be taken seriously without a bug or a voice acting as a counter to being on the list in the first place).
(In reply to Silvia Pfeiffer from comment #1) > Doesn't that just mean that we can remove <output> from the list? I think it does
(In reply to Anthony from comment #2) > Well, since that is my goal with each of these bugs, definitely. It means we > can remove output from list. I can only hope that getting the other 4-6 > features I'm not wanting to see go off the list could be so easy. > > I filed a bug because I've checked the draft every few days for over a month > and it hasn't changed. My concern is that if someone doesn't advocate for > these features, the assumption will be that they won't be missed, without a > real check on where the feature is in terms of implementation (obviously if > one of the features became the talk of the town, it would survive, but > significant implementation but still low like a jump from 3 - 10% > implementation may not be taken seriously without a bug or a voice acting as > a counter to being on the list in the first place). Hi Anthony I would also note that because a feature is listed (currently) at risk for HTML5 it does not mean that it is/will be removed from the 5.1 spec http://www.w3.org/html/wg/drafts/html/master/ and if the feature is interoperably implemented then it will be removed from the list before HTML5 goes to Rec.
(In reply to Anthony from comment #0) > <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. Please remember that items were marked at risk by the HTML WG NOT only because the WG members thought they might need further implementations but ALSO because someone might have been concerned about the interoperability of the implementations of the feature. For example, is there any evidence that the implementations you pointed to for <output> actually follow the HTML 5 CR spec, and give the same results? Note that the current document that summarizes the CR exit criteria for HTML5 lists <output> as needing testing. http://www.w3.org/html/wg/tests-cr-exit.html So in summary I believe that <output> will remain on the "features at risk" list until the HTML WG has concrete testing proof of at least two independent and interoperable implementations. /paulc HTML WG co-chair PS: I have not yet had time to double check the current HTML5 testsuite to determine if <output> tests have been added since the CR exit criteria was drafted in June.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: none Rationale: First and foremost Anthony, I would like to say that I heartily agree with your approach and feelings. I personally have a strong love for this sort of "small" feature that actually does nice things without being particularly bloggable. However, we are planning on shipping HTML 5.0 this year. The rules for what goes into that draft are clear: it has to be (sufficiently) implemented. The At Risk list is basically just a listing of things that look like they may not make the cut. But the goal there isn't to push them out of the draft, but rather to bring attention to them. We will revisit this list in the coming few months, probably inside of Q2. It's not at all cast in stone. The most important criterion there will be testing. If there's a test that shows a feature is supported, then it very likely just stays in. If your passion for this continues, I invite you to look at https://github.com/w3c/web-platform-tests/ as well as the community that goes with, and if there are no tests for a feature you care about then contribute some. Beyond that, the only way of making sure that one of those features makes the 5.0 cut (those that don't will stay in 5.1) is implementation. You can file bugs with implementers (or register your support with existing bugs), or, if you have the time and skills, maybe even contribute. For the time being however, the At Risk list stays the same, pending the upcoming re-evaluation.