Source spec info from macros for HTML attributes

[teoli2003]

This is part of #1146.

I sourced specification for HTML attributes using {{Specification}}

A few notes:

• I'm not sure having HTML/attributes/ pages (and SVG/attributes) is a good thing. I'm not judging this here, I merely addapt them.
• BCD for input attribute is next to non-existent. I'm not fixing this here.
• I used several macros for the cases where the attributes are on several elements.
• Missing spec_url where bcd was present are fixed in Add spec_url to html attributes browser-compat-data#11240
• If no bcd, I keep the error message: it will be fixed when we add bcd info.

After this PR, there are 0 {{SpecName}}/{{Spec2}} macros left in web/html.

I plan to use the same techniques for the SVG attributes (>200 tables!)

[sideshowbarker]

Does a spec_url for html.elements.input.accept exist in BCD yet?

I don’t see it in the main branch of BCD, nor in the mdn/browser-compat-data#11240 patch

[teoli2003]

No. html.elements.input doesn't exist. BCD is broken into html.element.input-type. I could choose one instead…

[teoli2003]

@sideshowbarker Do you think I should just remove the input cases in this PR?

[sideshowbarker]

Ideally, I’d think we’d want to figure out some way to store the necessary data in BCD. For example, for this case we’d add an html/elements/input/accept.json file to BCD.

That’d mean that in the html/elements/input/ directory, we have a mix of files, some of which are for different input types (what we have now) and some of which are for various input attributes (what we’d need to add).

Yeah, I realize that’d be weird — but input is weird to begin with.

But if we don’t do that and we instead drop the input cases from this PR, does that mean also backing out the part of the change that deletes the existing static spec table?

Or does it instead mean that we end up with no spec links in the articles for these input attributes?

[teoli2003]

But if we don’t do that and we instead drop the input cases from this PR, does that mean also backing out the part of the change that deletes the existing static spec table?

This is the content PR. So I meant removing, for the moment, the {{Specification}} macro and keep the hardcoded table This would match the bcd PR mdn/browser-compat-data#11240. Advantage: we delay the complex cases and do not block the simple cases.

We could do the opposite: adding the spec_urlat relevant places on bcd for input/email (and the other relevant types) and update the parameter of the macro. I suspect that, even if not complicated, that may not be trivial.

My favour goes to the first alternative (removal from PR) – but this is not a strong feeling, I'm ok with both – as we can constrain the future discussions to a specific case, and move forward with the simple cases.

[sideshowbarker]

This is the content PR. So I meant removing, for the moment, the {{Specification}} macro and keep the hardcoded table This would match the bcd PR mdn/browser-compat-data#11240. Advantage: we delay the complex cases and do not block the simple cases.

✅

My favour goes to the first alternative (removal from PR)

I agree. So shall we go ahead with that?

[teoli2003]

I'm converting this to draft, as there is a conversation to have before (I'll link it here). I don't want this to be merged by error before.

[sideshowbarker]

Not sure what this PR is waiting on currently but given that it last had any updates on July 15th, it seems like it might benefit from getting some new attention

[teoli2003]

I will close this: no way I can do this before we migrate to Markdown.