Consider adding things back

[saschanaz]

This PR reverts commit ae454fc, and currently serves as a backup of the previous state of contentEditable spec. See also #2 (comment).

[marcoscaceres]

I'm against adding redundant things back. We had a solid plan to move things into HTML and have this spec define only things that really need to be defined here (i.e., the mechanics of how this works).

We made significant progress adding things to HTML - for example:
whatwg/html#5265

And some other definitions and fixed up algorithms.

Unfortunately, Janice finished her internship before we got that merged.

[marcoscaceres]

Let's keep working this. I think we can get this to a good state - but we gotta put in the editorial work. I'm willing to help with reviewing stuff, but this is outside my area of expertise. Nevertheless, we can't have things being defined here, in HTML, and in the again in a bunch of other specs - so let's make sure there is no redundancy and that things in this spec are things that are implemented in at least two engines.

[saschanaz]

@marcoscaceres As I said in #2 (comment) I'm not sure there is an active implementer interest here. AFAIK the focus has been moved to Input Event L2 and then to EditContext, so not sure we have anything to add back right now.

This PR is accordingly just a backup of the previous state.

[marcoscaceres]

Ah, ok.... so we should just mark it as "do not merge"?

[saschanaz]

Ah, ok.... so we should just mark it as "do not merge"?

Or a "draft PR" as it currently is 😁

[saschanaz]

BTW, @sidvishnoi, could you examine why ReSpec is rejecting data-cite=css-cascade?

[sidvishnoi]

why ReSpec is rejecting data-cite=css-cascade?

css-cascade is not in Specref database but css-cascade-4 is.
See: tobie/specref#564. Until then, need to either add the alias to localBiblio or data-cite="css-cascade-4"

[saschanaz]

why ReSpec is rejecting data-cite=css-cascade?

css-cascade is not in Specref database but css-cascade-4 is.
See: tobie/specref#564. Until then, need to either add the alias to localBiblio or data-cite="css-cascade-4"

localBiblio works but not data-cite="css-cascade-4", somehow ReSpec trims out the number part. The search page says it should be css-cascade, should it show a warning?

[sidvishnoi]

localBiblio works but not data-cite="css-cascade-4", somehow ReSpec trims out the number part

Ah yes. It was a trade-off in showing versioned number in references section vs letting people use version-free numbers in cite. That is, we use shortname without version in references section, but can use spec id for linking - given the alias exists in Specref.
I'll follow up on that Specref PR to get it in.

The search page says it should be css-cascade, should it show a warning?

Unfortunately, it's not possible to know in advance if Specref has proper entry for shortname or not. So, we cannot show a warning. Would have to send more requests to validate Specref entry and change the how-to-cite accordingly - which isn't feasible.

[johanneswilm]

@marcoscaceres @saschanaz The issue is that this document has always just been an outline of a proposal of some possible way forwards. So with the exception of one small detail (which has been moved to the HTML spec), none of it was ever implemented and there were never guarantees from implementers to go ahead with it and probably won't ever be until a full proposal including all parts of editing exist. This is not something I came up; it is how Benjamin Peters of Microsoft started writing this document many years ago.

Which parts of this we will need to continue with is something that probably will reveal itself once EditContext has been shipped and we find out which parts JS authors still need help with + whether it is possible to ship a "slimmer" version of contenteditable than what browsers currently contain without removing functionality for end users.