Some feedback on an attempt to use `hypertext`

[Porges]

I tried converting some code that's currently using maud to instead use hypertext and ran into a few issues. I thought I'd provide them as feedback here to help improve the library.

I did really like the “checked” aspect which is something I really wanted to get with maud, and which is not currently possible there.

The main (blocking) issue for me with hypertext was that it's not possible to return an error during formatting, which is easy to do with maud. Yes, it's possible to do all error-checking up front and only then do the rendering, but the maud syntax makes it very easy to interleave this and that’s one of its strengths.

The other thing is that it is difficult to have a Renderable and share it across multiple renders. I do this with static blocks of content in maud.

• I think probably Renderable should not consume its contents (which would also make it dyn-compatible [object-safe]), so you can have some shared Box<dyn Renderable> or &dyn Renderable). As far as I can see there’s no performance to be lost here since any Renderable needs to copy into the target String in any case.

Other minor issues are:

• lack of support for aria-* attributes (easy enough to add yourself, but should really be included by default), #6
• also lack of support for RDFa-Lite attributes (maybe included as an optional extra?)
  • these are the five (global) attributes vocab, typeof, property, resource, prefix
  • they are much easier to add in the library (because of the existing macro invocations) rather than as an end-user since they're global and need to be on everything

[vidhanio]

Hi there,

Thank you for the feedback!

The error handling issue is one I considered early, but I just kind of enforced that a user would handle any errors and have all the data cleaned before beginning the rendering process. I do think a try_maud! macro might fix it, but I would have to think about it longer to figure out implementation.

I actually have no idea why I chose to make it consume self, but that is definitely a breaking change I would consider for the next version, as well as some helper type alias for boxed renderable.

The other attributes are something I never got around to doing due to university and stuff, but are something to do at some point.

As for the RDFa-Lite attributes, the global attributes are actually pretty easy to add to everything from the user end through an extension trait:

trait RdfaLiteAttributes: GlobalAttributes {
    const vocab: Attribute = Attribute;
    const typeof: Attribute = Attribute;
    const property: Attribute = Attribute;
    const resource: Attribute = Attribute;
    const prefix: Attribute = Attribute;
}

impl<T: GlobalAttributes> RdfaLiteAttributes for T {}

[vidhanio]

re-opening to address the minor issues, everything else should be solved as of 0.8.

[nonnorm]

Hello! I really wanted to thank you for making this crate. I'm using the git version in a project right now, and I love the type safety, maud syntax, minimal allocations, and especially the new component macro. I just wanted to ask if you could prioritize the addition of SVG elements/attributes and aria attributes. The SVG pull request has been open for a while with very few updates. Is there anything I can do to help?

I'd also love another release with all the git changes, but I'm sure you have that planned in due time.

[vidhanio]

hi @ravenclaw900, sorry about that, yeah i've been meaning to finish up documenting all the stuff on the main git branch and document it + add svg support. i'll hopefully get it done this month.

[vidhanio]

ARIA support has been added in the latest commit, and it will be released by EOD today @Porges @ravenclaw900. SVG support is still under works as there are a lot more attributes/elements. I'll be closing this as svg support is tracked already by #2. again, apologies for the wait. had university/job things to attend to.