Im using the HTML language parser and for the most part its been great! I’m looking to add Space as a key to trigger autocompletion suggestions for HTML attributes inside a tag. Is there an example to look at for how to add?
I’ve tried adding something like:
{ key: 'Space', run: startCompletion(target)}
to the defaultKeymap exported from lang-html, but that doesn’t seem to work? My guess is that when Space is pressed, the default startCompletion context doesn’t “know” its inside an HTML tag and therefore can’t show a completion hint?
Another way to explain what I’m after is this. I’d like to show the same completion list for attributes that gets shown when typing a character after a space in an HTML tag, but just show that after the space is typed instead of after a character is typed.
After a little bit of digging, it seems like there’s no external way to accomplish this because of this line:
which only does attributeName completion when the autocomplete context is explicit (when a user has typed the combo to initiate it) and that part of the check for attributeName completion isn’t configurable.
The thing I’m trying to do is show attribute/value hints for a component library of cusotm HTML elements. @marijn, what do you think about the possibility of making the context.explicit part of attribute name completion configurable? or at least configurable for extraTags when extra tags are present?
I understand that doing attribute completion automatically for every HTML tag and every attribute/value could be annoying, but for component library authors using codemirror for documentation/playground applications, seeing all the available attribute/value options for custom element tags (like sl-alert from https://shoelace.style) is super helpful from a documentation/self-help perspective.
I guess there’s very little one can do after whitespace in a tag that doesn’t involve an attribute name. So attached patch removes the explicit check for this type of completion. Does that work for you?
That works great! If you’d feel better about adding a config option that would be fine also, but it might be a weird config option to create a name for?
On the line above, the type for the TagSpec indicates that the attrs configuration, can only be null or string[]. I have found that true is also allowed and works well for boolean attributes on HTML elements.
Would you accept a PR to update this TagSpec.attrs to true | readonly string[] | null to officially account for boolean attributes?
Not exactly. Boolean attributes in HTML are truthy when present and falsy when not present. They don’t need to have a value at all. More strictly speaking, an attribute value of "false" is actually truthy, not falsy because its a string not an actual boolean.
Some good examples of native boolean attributes are: required, disabled, readonly, autofocus, etc. None of those attributes need values at all.
So my proposal is to add true as a valid type to represent attributes that have and need no value at all.
Currently the lang-html runtime code treats true exactly correctly. For attributes whose value is true autocomplete doesn’t show any hint or values. My proposal is only that the Typescript type be updated to say that true is a valid value since the runtime code already does the right thing.
That would work I guess. For me personally, Typescript typing is about being explicit. So I figured that the docs currently say that null is for “free-form” attributes. Boolean attributes aren’t really “free-form” imo. They are explicitly “no value” not “any value”. Might be a subtle distinction to be sure.
Another potential reason is that Typescript types are also meant to document the runtime code and true currently is acceptable. Since true doesn’t error, then the Typescript type is technically incorrect, because true is an acceptable value at runtime, but would be disallowed by Typescript.
At the end of the day its not a huge deal because both null and true work. Was mostly proposing to make a clear distinction between boolean attributes and other attributes because of how different they are. Imo having null mean " any string" value, true mean boolean attr, and string[] mean string attr with only certain acceptable values would be a good way to denote all the kinds of HTML attributes that exist.
