[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 https://github.com/w3c/webref/issues/127#issuecomment-874135280

[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 https://github.com/web-platform-tests/wpt/pull/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

[faceless2]

Thank you both and yes, I will be asking questions!

[bernhardf-ro]

[repost of 2h old post from correct account]

I'd like to add support to @faceless2 stating that there are in fact implementations of the GCPM and other specifications targeting paged output. That they are not web-facing is not unexpected for specifications that target print and PDFs. So when counting independent implementations, please don't exclude candidates based on their target medium, especially when the specification targets that exact medium.

Regarding the GCPM specifically, I think that it should preferably only be retired after all remaining parts have been moved to different specifications. There is not much left, and all of it should fit into existing specifications. But if nobody is working on it, it's probably better to make that known.

[css-meeting-bot]

The CSS Working Group just discussed Duplicate property definition for string-set.

The full IRC log of that discussion

<TabAtkins> Topic: Duplicate property definition for string-set
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6435
<TabAtkins> jfkthame: Issue filed on spec I now own
<astearns> s/jfkthame/faceless
<TabAtkins> faceless: Need to review specs taht use <content-list>
<TabAtkins> faceless: Will fix once review
<TabAtkins> chris: Think reason is that GCPM's definition wasn't speific enough, so we just forked it. Should just align them.
<TabAtkins> faceless: I think we do *need* two slightly differnet definitions
<TabAtkins> faceless: Will fix when I'm back form vacation
<TabAtkins> astearns: Propose we wait until you evaluate it, then
<TabAtkins> astearns: Is the dupe causing immediate problems?
<TabAtkins> chris: Causing a problem with automated validators
<TabAtkins> TabAtkins: w3c tooling is complaining about two different definitions. They can maintain a manual fix for now but would like it to be correct in source
<chris> q+