-
Notifications
You must be signed in to change notification settings - Fork 497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validate frontmatter (and tags in particular) #7456
Comments
Yes please! But it won't stop someone from typing I went through the same problem with my Firebase app I'm hacking on. It's a document store so I basically rely on typing the same string exactly identical in multiple locations of the database. Sucks but everything as its trade-offs. But how do you know what the valid tags are? Do you need to intimately know exactly what the relevant KS macro expects? We might want to transfer this issue to mdn/yari. |
By the way, we could easily validate slugs and use the Flaw system to highlight the ones we don't like. But I still don't understand how you're supposed to know which ones are valid in the first place? We can also break this down and switch to case insensitivity first if you think that's smart. |
I only intended to imply that we do it for certain known and previously standardized tags. Doing more than that is a longer discussion. |
Even that isn't trivial. E.g. you can only become a member being by being one of the other members :) But there are other tricks we could consider such as a dedicated CLI tool that you manually execute once. |
We already have a list of standard tags. All I'm advocating here duplicating functionality that we had when this was a wiki. It's worth duplicating because that functionality prevented a lot of pain and an enormous amount of technical debt. |
From #7456
|
I'm going to move this issue to yari (as that's where it should live) but I'm going to add the Having said that this issue reminds us to validate front matter as a whole. |
On the wiki adding standardized tags such as 'Interface', 'Method', 'Property' etc. was pretty foolproof. If a contributor typed even a part of a standard tag, a prompt would ensure that correct spelling and punctuation is used. This is not longer true, which opens the possibility of creating duplicate tags such as 'Property' and 'property'. Reviewers would reasonably think a single instance of one or the other were correct. Other variations 'PRoperty' could creep in through human error. I opened this issue because I corrected what I believe to be the first instance off this in mdn/content#31
Another solution would be to make grouping of pages under a tag case-insensitive. Given the nature of computer work, I can't prove that won't create an overloaded tag somewhere.
The text was updated successfully, but these errors were encountered: