Call for Consensus - Publish First Public Working Draft

[chaals]

This is a call for consensus on the proposition

The WebPlatform Working Group will publish a First Public Working Draft of Static Range based on the current spec.

Please respond before the end of Sunday 3 December.

Positive response is preferred (you can leave a "thumbs-up" on this comment"), silence will be taken as assent to the proposal, negative response should be acocmpanied by rationale - e.g. as a reply to htis comment.

[frivoal]

For reference, the draft is here: https://w3c.github.io/staticrange/

[frivoal]

I support publication as FPWD (and for that matter, frequent republication after that as WD as issues get fixed).

The static range spec is a dependency of Input Events, so we cannot work on that without working on this as well.

[bzbarsky]

Is there any chance that the various longstanding (from back in the spring) issues already raised will be fixed? Right now it's impossible to even evaluate the draft sanely because of some of those issues.

[frivoal]

@bzbarsky, I don't think that needs to block the publication as a FPWD, but issues should absolutely be addressed.

@garykac, @chaals (or other chairs @LJWatson @adrianba ), how about adding a co-editor to make sure the feedback is processed in a timely manner?

[johanneswilm]

I could help as coeditor if Gary wants some help.

[domenic]

I think ideally this should be done as a pull request to the DOM Standard, not as a separate specification. /cc @annevk to see if he agrees.

That of course doesn't prohibit publishing a FPWD or similar incubation style efforts, but should be considered as the specification matures and gains broad enough multi-implementer acceptance to be part of the DOM Standard.

[annevk]

Given the suggestions in #1 and what it would take to resolve them adequately I think starting with a PR against whatwg/dom sooner rather than later would be good. Especially if the plan is to implement this soonish we need to figure those things out.

[LJWatson]

@domenic @annevk

Whatever your reasons, your comments are disrespectful to the people working on this specification at
the W3C. I remind you both of the W3C Code of Conduct.

[chaals]

This proposal passes.^W^W^W

Wait for it... (sorry, I got confused by timezones early in the morning)

[michaelchampion]

Uhh Chaals, you didn't wait until the end of December 3 on the US West Coast. This just came to my attention, and while I'm not speaking for Microsoft here, nor have I worked as a DOM editor since about 2001, as a procedural matter I think it's inappropriate to close this issue while:

• None of the people who have worked on the static range spec have made their opinion known on publishing it as a standalone spec in W3C, as far as I can see.
• The editor of the spec this is spun off from and normatively references (the DOM Living Standard) has made what sounds to me like an objection. I for one don't consider it disrespectful to raise the question of whether static range should be in a standalone spec vs part of the DOM, or to raise the the question of whether the critical mass of expertise needed to get this feature standardized lies at W3C or WHATWG. So if you're discounting that objection because it was "disrespectful", I respectfully disagree with the decision to declare this proposal passed without objection ;-).
• The question of how DOM Range and StaticRange should relate to one another architecturally looks unresolved to me from a quick scan of GitHub. Why presuppose the answer to an architectural issue by publishing a standalone spec?

So, I strongly urge the WP chairs to keep this issue open until there is some architectural consensus on how Range and StaticRange relate to one another, and until the people doing the work to write and implement the spec have clearly indicated that they do prefer to see it as a standalone spec in the WP WG.

[chaals]

Yes, sorry for the confusion, the CfC is still open.

I am not presupposing any architectural decision. Producing a standalone spec was the initial preference of the WG. Technical comments from non-members of the group are relevant but the question here is an administrative decision to publish and start the formal timing of the licensing clock, in case the WG does not change its mind.

[annevk]

My apologies for being disrespectful.

My problem is that as stated in #1 this will effectively end up changing all range-related methods in the DOM. I think to carefully consider the implications of that and do that properly it should be done in collaboration with the community that manages the DOM.

See https://annevankesteren.nl/2014/02/monkey-patch for a longer form explanation of this issue.

[frivoal]

@chaals Hmmm. I don't want to get into the institutional politics of one standardization body vs another, and for the record, I am generally happy with static ranges being their own specification, but as far as I can tell, @domenic and @annevk had technical arguments (“Given the suggestions in #1 and what it would take to resolve them adequately”) for why this may be better done as a PR against DOM. Maybe they are right, and maybe they are wrong, but I am not sure why we should declare consensus without exploring this point.

@domenic did say "That of course doesn't prohibit publishing a FPWD or similar incubation style efforts", but usually, FPWD documents are meant to start the path towards REC, not to be an incubation for a PR on another spec. So we do seem to have disagreement about what the best future for this.

Maybe an independent specification is the best path forward, as I initially thought. But I think we should not dismiss @domenic and @annevk, and certainly not without hearing the arguments.

---

@domenic @annevk I'm curious about one thing. In my mind, being related to the same topic isn't necessarily a sufficient argument for merging to things, and maybe small specs can be more manageable of the coupling is low enough. If static range was monkey patching DOM, that would be an excellent argument for merging, but as far as I can tell, that's not what it's doing.

Could you elaborate a bit on why you think these two are better as one document?

[frivoal]

@annevk it looks like our comments crossed each-other. That's exactly what I was looking for.

So the questions left are, as far as I can tell:

• Do we agree that resolving Should we make Range a subclass of StaticRange? #1 is likely to lead to monkey patching DOM? If yes, the ultimate fate of this spec is probably to be merged with DOM.
• If this spec is meant to be merged with DOM later on, is there value in putting it on the REC track? I guess that's a question for the lawyers, not for the engineers.
• If this spec is meant to be merged with DOM later on, what is the best way to prepare it so that the merge is as painless as possible?
• Which ever path we chose, it looks like we need a co-editor to make timely progress. @johanneswilm volunteered. Anyone else?

[annevk]

@frivoal overloading compareBoundaryPoints() so it also takes StaticRange and rearranging interfaces so they share a common ancestor and algorithms, as suggested in #1, is what makes me think this should be in DOM. The current interface and prose effectively duplicates a lot of text, which is fine for an initial draft, but not where we want to end up long term.

[annevk]

The best way to get it done would be to work on a PR (which I'm happy to help review and give advice on) and corresponding tests (required to merge the PR). It seems there are already implementation commitments, so it shouldn't be too hard overall, though adequate test coverage might be somewhat tough.

[chaals]

@annevk, @florian, I agree that this may end up as a patch on DOM and we stop developing an independent spec. That is pretty easy to do if we decide that way. As Florian said, this step is basically about process, and if we do decide to continue with a standalone spec it is helpful to get through the process. (And in another monday-morning I forgot to formally reopen this until its deadline, doing so now)

The technical issue is under discussion in #1, and indeed it is relevant to talk to the people working on DOM specs.

ping @yongsheng

[othermaciej]

For the record, I agree with @michaelchampion 's comments, though since it's past the CFC deadline I am not registering a thumb.

[chaals]

@michaelchampion (and so @othermaciej )...
addressing your points.

• We generally don't propose to publish a specification without a go-ahead from the editor, and indeed got such agreement before putting this CfC. However I have pinged @garykac to ask for an explicit reply
• I am not discounting 'disrespectful' opinions. It makes perfect sense that this work is considered in relation to work on DOM (and other work it impacts, as e.g. @frivoal noted), but that by itself is not a reason not to publish it.
• And while the question of whether to merge it remains open, that does not a priori seem like a reason to hold off publication. A key purpose of moving along W3C's publication path is to signal that there is a desire to get more attention to a piece of work, and so review from a broader range of stakeholders (implementors, users, others affected by the document...).

[johanneswilm]

I support publication as FPWD as is. I don't have an opinion as to where this should live long-term. I am fine with it continuing to be its own spec or to be merged into another spec.

We need a FPWD in order to continue with the Input Events spec.

[johanneswilm]

@annevk:

It seems there are already implementation commitments

There are two browsers (Chrome & Safari) that have been shipping the Input Events spec which makes use of static ranges in their production version for the past half year. As I understand it, Edge is working toward something similar. We have not heard much from Firefox over the past year.

[rniwa]

I don't think we should spec static range as a separate standalone spec separate from DOM. For example, methods of Range like isPointInRange, comparePoint, and intersectsNode shroud also exist on StaticRange. Otherwise, authors would be creating "live" ranges just to call those methods. And we shouldn't be duplicating or monkey-patching DOM spec to add those methods to static ranges.

[plehegar]

I agree with @annevk and @domenic that it would be better to integrate in the DOM spec. However, until the day we'd be able to have a unified approach for producing the DOM spec, it should be done as a PR against the W3C DOM.

[frivoal]

@plehegar hmm. Maybe, but the fact that WHATWG DOM and W3C DOM are not the same thing makes this non trivial. Neither considers the other as upstream of the other, and both W3C and WHATWG exercises independent editorial control over the content of their respective specifications (see the WebPlatform WG's charter).

The normative references in the existing static range spec point to WHATWG DOM, and it seems reasonable to assume that the authors and contributors to static range have therefore been basing their work off the WHATWG document. The most natural spec to send a PR to would therefore be the WHATWG DOM.

[johanneswilm]

Could a solution be to create two PRs, one for each of WHATWG DOM and W3C DOM? Or what would you guys think is the fastest possible way to get something equivalent of a FPWD of this without having to deal with the question of which DOM spec is better, etc. . Remember that this is being shipped already.

[yongsheng]

I'll add it into W3C DOM 4.2.

[frivoal]

@yongsheng since this is not a finished document, and it has open issues to be addressed, I'd rather we didn't jump into adding it anywhere before we figure out the maintenance strategy.

I support:

1. Add Johannes as an Editor
2. Publish as FPWD
3. Work out key issues (at least Should we make Range a subclass of StaticRange? #1, probably all currently open issues), edit, and republish accordingly
4. only then, turn into a PR against DOM.

[yongsheng]

ok. For 4.2, it's not started yet. need a complete process.

[rniwa]

I don't think we should publish a standalone FPWD for static ranges.

[chaals]

Yes, it doesn't seem like there is consensus. This call is formally resolved as not having found consensus on the proposal.

With respect to @frivoal's position above, we have three open issues, but none seem so complex that they would make it really difficult to put static ranges directly into a DOM spec and resolve them as with other issues there.

[chaals]

@frivoal For what it is worth, until we are ready to make a Pull Request against DOM I suggest dealing with the issues on this repository...

[garykac]

Even if we don't publish a FPWD for StaticRange, are we still going to keep the issues and discussions in the repo for the time being? For example, it would be nice to get agreement on whether or not we need to have an AbstractRange (or RangeBase) that StaticRange and Range inherit from. Once there is agreement, then separate PRs can be made for each of the DOM specs, and then this spec can be abandoned (having served its purpose). What I'm most concerned about is if we have separate discussion threads that lead to separate decisions.

…

On Wed, Dec 13, 2017 at 4:45 AM, chaals ***@***.***> wrote: @frivoal <https://github.com/frivoal> For what it is worth, until we are ready to make a Pull Request against DOM I suggest dealing with the issues on this repository... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABaVSuB67ehuz4G4CuuSlUHuM-SEdZELks5s_8cDgaJpZM4QoS-J> .

[rniwa]

Yes, I think keeping the discussion in this repository makes a lot of sense at least we reach a consensus on contentious bits like whether Range should inherit from StaticRange, etc...