[[FULLSCREEN]] should map to fullscreen.spec.whatwg.org

[annevk]

No other specification is maintained. We could call the other version LEGACY-FULLSCREEN or W3C-FULLSCREEN? Happy to write a pull request for this.

[tobie]

So this implies also handling this somehow in the auto-update scripts or it'll get overwritten when the next auto-update kicks in.

[annevk]

Can you give me a pointer? Happy to do that.

[tobie]

The auto-update scripts are kind of a giant ball of Scotch tape at this point, so I'm not 100% sure what the solution is. Not to mention that W3C has two completely different ways of indicating retired specs, one which I just found out about now. FYI, the file that handles W3C updates is "/scripts/rdf.js".

Simply renaming things doesn't work as it's immediately overwritten by the auto-update script.

Ideally, W3C would publish the specs that are superseding retired specs, but I'm not holding my breath.

I need to think about this a bit more. Would <3 input from @darobin and @marcoscaceres on this topic.

[tobie]

Fixed the isRetired issue in #186. Intend to use this as a way to prevent overwriting (perhaps).

[marcoscaceres]

hmmm... I guess the best thing to do right now is to have a "whatwg-fullscreen" ref. There is no much we can do about W3C squatting "fullscreen" :( I think that will be fine, as the fullscreen spec has been gutted and points anyone who lands there to the right place.

[tabatkins]

@marcoscaceres Nah, that's just a short-term solution. As tobie alluded to, when we know that a spec is retired, we can avoid having the auto-updater overwrite a same-name spec from a different source.

[marcoscaceres]

Ok, we should work with the w3c team then.

[tobie]

Well, we have this data; a bunch of specs--including this one--are already marked as retired. Now we just have to account for this information in order to avoid overwriting references that have been manually modified.

[tabatkins]

Looks like it's just a matter of, at rdf.js:142, checking if the rdf ref is retired, and the current ref is !isGeneratedByThisScript(), and only doing the work in that conditional if both of those are false.

[annevk]

The alternative is maybe having duplicate metadata? And let the specification decide which set to use? E.g. I noticed [[ENCODING]] is bogus though, listing a W3C editor that is not actually editing. And maybe for WHATWG documents I would just credit the WHATWG, not anyone in particular.

[tobie]

@tabatkins something like that (that script is in such a bad state I'm never too sure what effect an actual change has until I actually run the script on the data and compare the output).

@annevk so the problem with [[ENCODING]] is its gathering the data from the W3C tr.rdf file which lists editors as they were indicated on the last WD.

ToDos:

• fix the W3C import script so it doesn't overwrite content if the reference is marked as retired (@tobie)
• modify biblio.json so [[FULLSCREEN]] points to the WHATWG version (@tobie).
• add a reference entry for all WHATWG specs in the form of [[WHATWG-shortname]] (@annevk, @tabatkins, or @marcoscaceres) (note if the editors/authors were listed on https://spec.whatwg.org/ we could write a script to automate that really easily).

Lastly, I'm also considering adding a W3C-prefixed version of all specs. Like that we'd have:

• [[W3C-FULLSCREEN]] points to the retired NOTE.
• [[WHATWG-FULLSCREEN]] points to the WHATWG spec.
• [[FULLSCREEN]] is aliased to [[WHATWG-FULLSCREEN]].

If you have thoughts on the above, please share them.

[annevk]

I'm happy to host a JSON file on resources.whatwg.org that has an overview of all WHATWG documents that you could scrape. Or we could add it to this repository? Automated seems overkill given that we don't actually believe in referencing snapshots.

[tobie]

@annevk whatever's more convenient for you. I wasn't intending to reference snapshots, just scrape it daily to automatically reference new specs and modify existing ones in case of a title or editor change. If you're willing to do the work by hand directly in biblio.json, that works too.

[annevk]

Can it be a distinct file in this repository that the build script pulls in? That might make it a little bit more convenient to work with while still keeping all references in a single place.

[tobie]

Absolutely.

The biblio file needs to be split up anyway. It's just too big.