Add inline Registry Section #196
Conversation
Closes #195.
Previous workaround to replace the element entirely with an `<a>` is unnecessary - simply put an empty href on the `<a>` element and Respec no longer tries to find the link.
|
Self-review: it would be much more helpful to readers if the registry tables were placed within the sections where they apply rather than in appendix G. I'll refactor to move them there. |
|
Still to do: a few styling tweaks, and a note about registry sections in the document conventions. |
|
Ready to review now @cconcolato and anyone else. |
|
There will be some more tweaks to this based on https://lists.w3.org/Archives/Public/spec-prod/2023OctDec/0009.html from @jyasskin and a W3C Slack response from @dbaron:
There were other points, but I think they're less clear cut, and worth discussing more. In some cases it seems like this PR does what the Process says it should do, but the Process might need fixing. |
* Rename Registry Tables section to Registry Table Definitions * Don't mark up the Registry Section as having different update requirements to the rest of the document * Do mark up registry tables as "Registry Table Section" and explain in the document conventions how they differ; similarly update the SOTD text to explain that the document normatively specifies the registry table update requirements. * Add captions to the registry tables * some related minor editorial tweaks
|
Those tweaks made in 20380b0. One change made is to adjust the styling so the blue registry table section sidebar only appears on the left rather than on both sides, because data tables get "fixed up" by the W3C fixup.js script to be in a wrapper with the |
Yes, see G.1.1 which allows for a path in case TTWG no longer exists. |
|
The Timed Text Working Group just discussed
The full IRC log of that discussion<nigel> Subtopic: Add inline Registry Section #196<nigel> github: https://github.com//pull/196 <cpn> Nigel: Thank you Cyril for reviewing. Please take a look <cpn> ... We wanted registry tables in a few places, so this uses new features in W3C Process. They can be updated outside the normal Rec track process <cpn> ... I've based this on the boilerplate text in the TTWG repo <cpn> ... In doing this, I've had to raise a Process issue, but it's probably acceptable now to meet process requirements <cpn> ... Please look, to see if it has any issues <nigel> SUMMARY: Please review! |
|
I plan to merge this on Nov 23 if there are no unresolved objections, since that will have been 2 weeks since this PR was properly ready for review. |
|
Added some minor questions, but overall seems fine for me. |
How could there be a timing issue? As far as I can tell, everything else has already run beforehand, except maybe fixup.js which doesn't interact with this. I'd be more worried that making it async would cause a timing issue. |
Define and reference "registry table definitions" instead of using "registry table" definitions.
In respec processing, if promise returned for postProcess, respec will wait to be resolved before going to next task. |
Closes #195. Incorporates and modifies the TTWG boilerplate registry definition, and specifies starter tables for
daptm:descTypeanddaptm:eventType.Preview | Diff