This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24812 - Remove at risk features from CR HTML5 spec
Summary: Remove at risk features from CR HTML5 spec
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Robin Berjon
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: CR
Depends on:
Blocks:
 
Reported: 2014-02-25 20:02 UTC by Sam Ruby
Modified: 2014-09-01 21:19 UTC (History)
9 users (show)

See Also:


Attachments

Description Sam Ruby 2014-02-25 20:02:14 UTC
These features have been on the at-risk list with no objections or implementations:

* Application Cache
* <dialog>
* <details> and <summary>
* <input type=color>
* <input type=datetime>, <input type=month>, <input type=week>, <input type=time>, <input type=datetime-local>
* <output>
* <style scoped>
* <iframe seamless>
* Custom scheme and content handlers (registerProtocolHandler and registerContentHandler)
* Outline algorithm 

Additionally, please see https://www.w3.org/Bugs/Public/show_bug.cgi?id=18915 for the status of 'UA mechanism for navigating to resources linked to in cite=""'
Comment 1 Edward O'Connor 2014-02-25 22:43:54 UTC
<details> is exposed to the Web in Safari, Chrome, and Opera: http://caniuse.com/#feat=details

This should only count as one implementation, since the work predates Blink forking WebKit. But nevertheless, claiming that it has no implementations is innacurate.
Comment 2 Silvia Pfeiffer 2014-02-26 04:28:25 UTC
What about those listed at http://www.w3.org/html/wg/wiki/HTML5.0AtRiskFeatures ?
Comment 3 Sam Ruby 2014-02-26 19:54:43 UTC
(In reply to Silvia Pfeiffer from comment #2)
> What about those listed at
> http://www.w3.org/html/wg/wiki/HTML5.0AtRiskFeatures ?

Because we always were intending to have a second last call we have some flexibility.  Use your best judgement.  My only request is that the differences between what was listed in the previous Last Call and what actually gets removed be documented some place (perhaps as a comment in this bug?).
Comment 4 Silvia Pfeiffer 2014-02-26 22:18:40 UTC
OK, I just noticed that the ones I added to that list are already gone. Must have happened through bugs.
Comment 5 Robin Berjon 2014-02-27 12:03:14 UTC
(In reply to Edward O'Connor from comment #1)
> <details> is exposed to the Web in Safari, Chrome, and Opera:
> http://caniuse.com/#feat=details
> 
> This should only count as one implementation, since the work predates Blink
> forking WebKit. But nevertheless, claiming that it has no implementations is
> innacurate.

I'm not sure that we should count this as just one implementation.

I see two different reasons behind the "two implementations" rule. One is implementability, and the other is implementer interest.

For something like WebSQL, with all the complexity of SQL and its known interoperability issues, if everyone is using the same library then it's clear we have just one implementation (and a problem). For <details>, I think that argument is much less powerful.

The fact that it still is in both WebKit and Blink (it could have become disabled in either) IMHO shows interest in supporting it. I reckon we can keep it.
Comment 6 Sam Ruby 2014-02-28 00:34:04 UTC
(In reply to Robin Berjon from comment #5)
> (In reply to Edward O'Connor from comment #1)
> > <details> is exposed to the Web in Safari, Chrome, and Opera:
> > http://caniuse.com/#feat=details
> > 
> > This should only count as one implementation, since the work predates Blink
> > forking WebKit. But nevertheless, claiming that it has no implementations is
> > innacurate.
> 
> I'm not sure that we should count this as just one implementation.
> 
> I see two different reasons behind the "two implementations" rule. One is
> implementability, and the other is implementer interest.

The exit criteria we've adopted is explicit on this matter:

http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html

- Sam Ruby
Comment 7 Robin Berjon 2014-02-28 11:04:57 UTC
(In reply to Sam Ruby from comment #6)
> (In reply to Robin Berjon from comment #5)
> > I see two different reasons behind the "two implementations" rule. One is
> > implementability, and the other is implementer interest.
> 
> The exit criteria we've adopted is explicit on this matter:
> 
> http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html

I am well aware. However, while the rule of thumb is fine, it is just a rule of thumb and there are cases (such as this one) which I would argue are acceptable. The rules are only a tool to get to interoperability; in the hierarchy of norms the latter rates above the former.
Comment 8 Philippe Le Hegaret 2014-02-28 23:11:15 UTC
I agree with Sam here. The CR exit criteria are very explicit:
[[
Each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. 
]]

We would need to renegotiate the terms with the Director if we wanted to change the exit criteria.
Comment 9 Robin Berjon 2014-03-10 14:43:39 UTC
I just ran the tests for <output> and it's supported in Firefox, Chrome, and Safari. Looks safe to me.

(Based on http://w3c-test.org/submissions/658/html/semantics/forms/the-output-element/output.html)
Comment 10 Robin Berjon 2014-03-14 09:17:47 UTC
It's not flagged at risk but we should drop XMLDocument.load() as it has no implementation outside FF and may get removed there.
Comment 11 Robin Berjon 2014-03-14 12:52:52 UTC
(In reply to Sam Ruby from comment #0)
> * Application Cache

This is interoperably implemented and should not be removed.

> * <dialog>

There is movement on implementation, but it's not clear that it'll make the cut

> * <details> and <summary>

Irrespective of the source of the implementations, they still fail some pretty basic tests like html/semantics/interfaces.html.

> * <input type=color>

Supported in both Chrome and pre-Blink Opera.

> * <input type=datetime>

Supported in pre-Blink Opera at least.

> , <input type=month>
> , <input type=week>
> , <input type=time>

All three are supported in pre-Blink Opera and Blink.

> , <input type=datetime-local>

This one is already gone (but supported in Blink).

> * <output>

Multiple implementations.

> * <style scoped>

This is in Gecko, but I don't believe anywhere else yet. That said, my understanding is that there is interest such that this could make the cut.

> * <iframe seamless>

I believe this is now dead.

> * Custom scheme and content handlers (registerProtocolHandler and
> registerContentHandler)

These have decent support and should stay.

> * Outline algorithm 

This is not exposed by browsers, but is useful and has been implemented in other types of software. I believe it should stay.

> Additionally, please see
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18915 for the status of 'UA
> mechanism for navigating to resources linked to in cite=""'

This change has already been made, so I've gone ahead and closed that bug.

I'm leaving this bug open pending final discussion at the f2f.
Comment 12 Philippe Le Hegaret 2014-03-18 21:13:53 UTC
regarding <input type=color>, it just missed the firefox 28 release. See https://bugzilla.mozilla.org/show_bug.cgi?id=977301 . Now scheduled for firefox 29.
Comment 13 steve faulkner 2014-04-08 19:30:40 UTC
(In reply to Robin Berjon from comment #11)
> (In reply to Sam Ruby from comment #0)
> > * Application Cache
> 
> This is interoperably implemented and should not be removed.
> 
> > * <dialog>
> 
> There is movement on implementation, but it's not clear that it'll make the
> cut
> 
> > * <details> and <summary>
> 
> Irrespective of the source of the implementations, they still fail some
> pretty basic tests like html/semantics/interfaces.html.

Note: how summary/details are defined in HTML are not how it is currently implemented.
HTML defines details as the interactive element (via an anonymous control). In implementations summary is the interactive element. 

suggest it be dropped from 5.0 , left in 5.1
Comment 14 steve faulkner 2014-04-10 17:08:56 UTC

(In reply to Robin Berjon from comment #11)

> 
> > * Outline algorithm 
> 
> This is not exposed by browsers, but is useful and has been implemented in
> other types of software. I believe it should stay.

saw this in irc logs

<plh> Sam: Steve Faulkner thinks outline should be removed...
# [00:25] <plh> ... can we close the loop with him? 
http://krijnhoetmer.nl/irc-logs/html-wg/20140410#l-41

I think its OK for it to stay, but needs author advice around usage as robin noted:
> This is not exposed by browsers,

I have made some changes in the spec already, to address this, and have had discussions on the lists and elsewhere on providing additional clarification around the outline.

If we are good to make some further tweaks in advice I see no issue with it staying in 5.0
Comment 15 steve faulkner 2014-04-17 10:02:32 UTC
(In reply to steve faulkner from comment #14)
> 
> (In reply to Robin Berjon from comment #11)
> 
> > 
> > > * Outline algorithm 
> > 
> > This is not exposed by browsers, but is useful and has been implemented in
> > other types of software. I believe it should stay.
> 
> saw this in irc logs
> 
> <plh> Sam: Steve Faulkner thinks outline should be removed...
> # [00:25] <plh> ... can we close the loop with him? 
> http://krijnhoetmer.nl/irc-logs/html-wg/20140410#l-41
> 
> I think its OK for it to stay, but needs author advice around usage as robin
> noted:
> > This is not exposed by browsers,
> 
> I have made some changes in the spec already, to address this, and have had
> discussions on the lists and elsewhere on providing additional clarification
> around the outline.
> 
> If we are good to make some further tweaks in advice I see no issue with it
> staying in 5.0

have added a warning to outline section (commit https://github.com/w3c/html/commit/6d2fe96d62b49eec79841210f387240bc43f5ad3) needs pushing to CR once reviewed)
Comment 16 Robin Berjon 2014-06-06 09:39:08 UTC
Features slated for removal have been removed prior to the next snapshot.
Comment 17 Paul Cotton 2014-09-01 21:19:23 UTC
Due to a lack of implementations, the DataCue interface [1] and drag and drop [2] features were dropped from the Proposed Recommendation [3] after the July Candidate Recommendation [4].

/paulc

[1] http://www.w3.org/TR/2014/CR-html5-20140731/embedded-content-0.html#datacue 
[2] http://www.w3.org/TR/2014/CR-html5-20140731/editing.html#dnd 
[3] http://htmlwg.org/heartbeat/PR-html5-20140916/ 
[4] http://www.w3.org/TR/2014/CR-html5-20140731/