Is your feature request related to a problem? Please describe. hdot should support ARIA attributes to improve accessibility of a site.

Describe the solution you'd like ARIA Attributes should be supported similar to data attributes using camelCase.

h.button.ariaLabel('Close`)();

Describe alternatives you've considered The only workaround right now is using [aria-xyz] which is not a very nice syntax (and no TS support):

h.button['aria-label']('Close')`button`,

This PR rewrites a good bit of the core logic.

Before

Before, every get on h would append to this.htmlString: string internally, and calling the resulting function would return that string:

h.div.id("test")(
  h.p`Hello world`
) === `<div id="test"><p>Hello world</p></div>`

After this PR

Now, instead of passing this.htmlString around and appending to it, we pass around this.tree, which has the same type signature as https://posthtml.org/#/tree.

Furthermore, calling the resulting function will no longer return an HTML string, but return the h instance itself. Instead, one must manually call toString on the outermost function to get an HTML string.

h.div.id("test")(
  h.p`Hello world`
).toString() === `<div id="test"><p>Hello world</p></div>`

Why make this change? It is more verbose.

In the first code block, hdot functions are stringified from the inside out. h.p is converted to an HTML string, which is passed as a child to h.div. This has a major ramification: parent elements can not inspect the content of their children without complex string manipulation.

The new logic builds one tree structure, and then only stringifies once from the top down, when the dev calls toString.

Plugins

This enables plugins to do a lot more. Since the tree structure is the same as postHTML's, plugins should be mostly interoperable with a few more changes. Plugins will now only run once per tree, which should be a performance boost.

TODO: add more plugin docs

Fixes an issue where aria attributes were not properly converting to kebab case upon serialization. Resolves #2.

Before:

h.div.ariaLabel("test123") === `<div arialabel="test123"></div>`

Now:

h.div.ariaLabel("test123") === `<div aria-label="test123"></div>`

Unit test suite "aria attributes" was added for this change.

This PR refactors the type generation logic found in the core package.

Key updates:

• Aria attributes are now recognized and do not cause a type error ( resolves #2 ). Short term work still needs to be done to add JSDoc descriptions to each attribute, and refine their value type. Less short term, it would also be nice to restrict the allowed aria attributes to those that are compatible with the role of the element (is this possible?).

• Lerna mode was swapped to independent. This PR started out with the intention to move HTML types to their own package, and with that, I decided independent mode made a bit more sense for the repo. However, I changed my mind on splitting the types into a separate package due to some limitations with mapped types preserving JSDoc comments and tags. Ideally, I would like for more of the manual type generate to utilize TS itself over code gen, but at this point the IDE type hints are better if we are less DRY (sadly).

• More investigation needs to be done on "convenience patterns", i.e. passing Array<string> as the value to .class(). The behavior needs to be consistent--I think one off special cases are a potential footgun and I am removing for now ( concerns #3 ). Should any of the convenience patterns be built in, or moved to a plugin? I am thinking plugins, but then, what is the best way for users to update the accepted types of the h function?

  Prior art here, but it would involve changing the api in a way that requires constructing a new instance of h before it is usable: const h = new hdot().

Describe the bug The parameter type of the class attribute function accepts a string or an array of strings. But when using an array it will call .join() which results in class="one,two,three".

To Reproduce Steps to reproduce the behavior:

1. Create an element: h.p.class(['one', 'two', 'three'])('hello')
2. Inspect the element in the DOM
3. The classes are joined with ,

<p class="one,two,three">hello</p>

Expected behavior The classes should be joined using spaces:

<p class="one two three">hello</p>

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Browser: Brave
• Version: 1.36
• Node: 16.13.0
• Eleventy: 1.0.0

Additional context Right now we either need to use a string or add a custom plugin:

setPlugins(h, [
  {
    attribute: (tagName, key, args) => {
      if (key === "class" && Array.isArray(args)) {
        return [key, args.join(" ")];
      }
      return [key, args];
    },
  },
]);

Currently, hdot does not type-check the content category of children passed to other elements. This feature needs to be added to the element types here.

The following should cause a type error, since <link> is an empty element.

h.link('Hello world'); 

Find more info here: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories