W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[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.

From: <bugzilla@jessica.w3.org>
Date: Mon, 15 Aug 2011 18:24:27 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qt1pr-0008HG-Bv@jessica.w3.org>

--- Comment #13 from Aryeh Gregor <ayg@aryeh.name> 2011-08-15 18:24:25 UTC ---
(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.

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:24:53 UTC

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