Skip to content

Conversation

@mozfreddyb
Copy link
Collaborator

@mozfreddyb mozfreddyb commented Nov 5, 2025

This builds on the fixes in #351 and the suggestion I made in #354.

I'm not entirely sure a long table is the best idea, but I also don't like any of the other options :)


Preview | Diff

@mozfreddyb mozfreddyb force-pushed the tabular-allow-reasoning branch from 0f24e33 to b51c5c8 Compare November 5, 2025 08:59
@otherdaniel
Copy link
Collaborator

I'd really like to have that list. Particularly in light of #349, where it turns out that we omitted something because of an oversight, and having a list which records the reasons allowed us to check that it was indeed an oversight. I wonder whether we should/could generate it; both for easier spec maintenance as well as for more flexible presentation.

I like how this enumerates the set of reasons. These basically form an enum of allowability. If we keep a file with name, namespace, allowability, we could quite easily generate these list. We could also derive the built-ins from them, or at least check them against the builtins for error checking.


Currently, we group by namespace, then list element/attr name -> allow-status. I suspect it'd be more compact if we'd group by namespace; then group by allow-status; then have a box of element/attr names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants