[Bug 13423] Remove the Editing APIs section. It's extremely incomplete and contradicts my editing spec on a lot of points, so it will confuse implementers.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13423

--- Comment #14 from Shelley Powers <shelleyp@burningbird.net> 2011-08-15 18:26:27 UTC ---
(In reply to comment #13)
> (In reply to comment #8)
> > WG Member here. If the existing text is a subset of what is being implemented,
> > that's no different to the rest of the frozen W3C spec. But if it contradicts
> > what is being implemented to the extent that clientside code written against
> > the spec will fail, that will cause authors confusion and users may experience
> > breakage. (Implementor feedback would be valuable as to which is the case
> > here.)
> 
> The existing text is so sketchy that it's almost useless for interoperability. 
> I think leaving it in would be confusing, but not likely to cause
> implementations to diverge appreciably.
> 
> (In reply to comment #9)
> > My own personal preference (not speaking as Chair) would be to have Aryeh's
> > text submitted to the W3C in some form (either to the HTML WG or the Web Apps
> > WG). I believe if that occurred, there would be no controversy about removing
> > the buggy/incomplete editing spec text from the HTML5 spec.
> 
> As I've said several times, my spec is in the public domain (CC0) and anyone
> who wants to submit it to the W3C is free to do so.  I won't stop them.
> 
> This is an excellent opportunity for those who believe that the W3C is a good
> place to develop specs to show their willingness to improve the web.  All it
> would take is a modest amount of effort to submit the spec for W3C publication,
> and of course in their view, this would be beneficial because the W3C is a good
> place to publish specs.  I wait with interest for one of the many people who
> have expressed concern about the editing spec not being at the W3C to spend the
> necessary time themselves to fix the problem, rather than expecting others to
> do it.
> 
> (In reply to comment #10)
> > My first reaction is that this bug is INVALID as it does not provide "A clear
> > statement of a problem with the spec�bug reports are more useful if they
> > identify concrete problems."  Furthermore "Only one issue�please use separate
> > bugs for separate issues.".  Instead it provides, and only provides, "one
> > suggested way to solve the problem".
> 
> As far as I read the Decision Policy, the criteria it gives for bug filing are
> purely advisory.  It says only "bug reports that do not have enough information
> to identify a problem or potential action may be closed as INVALID."  I
> interpret this as saying that although the editor is likely to close such bugs
> as INVALID, this is not a requirement or even a suggestion, just a prediction. 
> If the editor feels this bug report contains sufficient information to be
> actionable, he is entitled to resolve it as FIXED in his sole discretion,
> subject only to the usual escalation procedures.
> 
> Do you disagree with my interpretation of the policy?
> 
> (In reply to comment #12)
> > I did want to say, though I'm not an HTML WG member, that I agree 100% with
> > this. I think this is an elegant solution and a win/win for everyone.
> 
> Are you volunteering to do the work to submit the spec to the W3C?  If not, do
> you know of anyone who would be willing to do so?  It's all very well to
> propose that as a solution, but it doesn't help much if no one cares to do it.


I'm actually not a member of the W3C. And I won't be as long as there are
limitations on my joining that exceed those for others. 

Are you saying you've quit the W3C and the HTML WG?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 15 August 2011 18:26:30 UTC