HTML global attributes

[Elchi3]

I've been going back and forth on this, but I think I should file a PR so we can discuss instead of me thinking this through on my own. So, this is an attempt to introduce a new content type "HTML global attributes". I've kept the PR small, so all it does is adding one global attribute "contenteditable" for now.

I'm interested in hearing if this is the correct way to add a new content type and then I'd like to discuss how stumptownified it is and which way we need to go next.

So, I think this would migrate global attributes into a structure, but it mostly treats the information as prose. That is, if we migrate all the global attributes like this, a data consumer would know which global attributes exists and could do a few queries about them. But:

It doesn't follow a structure for the values. We have this for element specific attributes and I think it would need a bit of refactoring of that code to also make it work for global attributes values. Or is the problem rather that the element specific attributes should follow a recipe (as discussed in the writer's guide PR) and then have global attributes and element specific attributes share that recipe and any code that extracts structured information? I feel like this is an essential question about recipes and information extraction and would like to know what y'all think about it or if I'm just blanking out on how to implement this correctly.

[wbamberg]

This should have short_title because it has a wordy title. To decide whether short_title is needed, imagine title in a sidebar, under a heading describing what sorts of things these are:

- Global attributes
    - contenteditable attribute
    - dir attribute
    - draggable attribute
...

versus:

- Global attributes
    - contenteditable
    - dir
    - draggable
...

[wbamberg]

I think the recipe should include prose.overview after the interactive example, and we should use this "Usage notes" section for it (we've done something similar with the HTML elements, see #55).

[wbamberg]

I'm interested in hearing if this is the correct way to add a new content type

Yes, very nicely done! I've tested it in stumptown-renderer and it renders properly, too.

It doesn't follow a structure for the values. We have this for element specific attributes and I think it would need a bit of refactoring of that code to also make it work for global attributes values. Or is the problem rather that the element specific attributes should follow a recipe (as discussed in the writer's guide PR) and then have global attributes and element specific attributes share that recipe and any code that extracts structured information?

On using the same recipe for element-specific attributes, I've filed #215 and made a rather long comment there. Perhaps we can talk about structuring global attributes independently of that.

There seem to be two things that are structured in element-specific attributes, but are not structured in this PR.

• type: this seems like it could be a front matter item whose value is once of various strings: "String", "Number", "Boolean", maybe "URL" and "Regex"?
• values: this seems to want to be an array of [name, description] . But I don't think we should have prose-y Markdown descriptions in the front matter. Would it be reasonable to list the value names in front matter, and have them be resolved as sections of the prose?

---
...
values:
    - foo
    - bar
...
---

## Short description
...

## Values

### foo
...

### bar
...

?

It would be a bit annoying for authors to have to update foo in both places I suppose, but having the summary list in the front matter might help make this bit of structure more explicit.

I think this situation, where we have structured content whose "leaves" are prose, is going to come up a lot - CSS properties might also have values, and function parameters might have something similar.