[css-content][css-gcpm] Duplicate property definition for string-set

[tidoust]

The string-set property (and companion string() and content() functions are defined twice:

• in css-content-3
• in css-gcpm-3

I suspect the definition in css-content is the "right" one. Could the definition in css-gcpm be dropped?

Via w3c/webref#127 (comment)

[cdoublev]

I do not know if CSS Content has "authority" over CSS GCPM but the definition from CSS Content is compatible with the definition from CSS GCPM but not the other way around, ie. a valid value parsed against the definition from CSS Content will always be successfully parsed against the definition from CSS GCPM.

[tabatkins]

We should probably just retire GCPM to Note status, I guess? It has no active editors and no planned changes to that status, plus no web-facing implementations of the remaining bits of it.

[faceless2]

We should probably just retire GCPM to Note status

Please don't do this. Not yet.

We're all aware that GCPM has issues but it's formed the basis for a number of independent implementations and has been largely unchanged for a decade. There is at least some compatibility across implementations as a result, and this has been the case for many years.

There's cleanup to be done, certainly: in order to implement page number counters you need to consult Content-3, Lists-3 , Pages-3 but not GCPM-3. Bookmarks were moved to Content-3, despite not generating any content on the page while Page selectors are in GCPM despite having nothing to do with content, and should probably be in Page-3. It needs more and better testcases (cough web-platform-tests/wpt#21701) and it needs an editor.

So I would also like to have a discussion on this, but with the goal of fixing it, not retiring it. If an editor is required for this and the WG would consider me for it I'd certainly like to know more about what's involved. I'll make sure I'm on the next call.

What I don't want to do is make a case specifically against retiring it, rather than for improving it, on only a few days notice in the comments on an unrelated issue where the people that will be affected most are unlikely to see it.

[fantasai]

Side comment: the latest Process now has a dedicated status for discontinued REC-track work. See https://www.w3.org/2021/Process-20211102/#abandon-draft

[faceless2]

There are eight different CSS layout engines that I know of that implement at least some of this specification, with various degrees of interop, and it now has a new editor. So although GCPM might not have had a lot of love recently, it's no longer abandoned. I'm hoping to put some time into it over the next few months, once I've clarified the process.

[svgeesus]

Strongly in favor of cleanup and re-evaluation rather than quietly and per-emptively discontinuing without asking any of the actual implementers.

@faceless2 if you need any help as editor, let me know.

[tabatkins]

Now that it has an editor, I'm fine with it staying around and getting fixed. My "let's just retire it" was based on it being abandoned and left in a bad state.

[svgeesus]

So when counting independent implementations, please don't exclude candidates based on their target medium, especially when the specification targets that exact medium.

This used to be easier: Shepherd had a way to manually upload test results from non-browser implementations, although each test had to be run by importing it, one by one, looking at the PDF or whatever output it used, and then jotting down in a file the pass or failure.

We now have on WPT automated running of all tests - but in four browsers, three of which use different engines, and with no way to inject non-browser test results. And no way to get results for tests that require a human to judge the pass/fail (so gradients are entirely un-tested, for example).

[tabatkins]

rather than quietly and per-emptively discontinuing without asking any of the actual implementers.

Also y'all are really giving me lots of power I don't actually have; this would have been done with WG discussion, not by me just summarily changing the status and pushing a new publication on my own. Thus the wording from my post, "we should probably [retire it]"; it was a suggestion, not me banishing it from existence.

[svgeesus]

My faith in your necromantic powers is severely shaken