A typical attribute impl now:

// Source image.
#[derive(Debug, Clone)]
struct Src(String);

impl Attribute for Src {
    fn name(&self) -> &'static str {
        "src"
    }

    fn value(&self) -> String {
        self.0.to_string()
    }
}

/// Image width.
#[derive(Debug, Clone)]
struct Width(usize);

impl Attribute for Width {
    fn name(&self) -> &'static str {
        "width"
    }

    fn value(&self) -> String {
        self.0.to_string()
    }
}

/// Image height.
#[derive(Debug, Clone)]
struct Height(usize);

impl Attribute for Height {
    fn name(&self) -> &'static str {
        "height"
    }

    fn value(&self) -> String {
        self.0.to_string()
    }
}

A lot of boilerplate.

Perhaps we could do:

#[derive(Debug, Clone, Attribute("src")]
struct Src(String);

#[derive(Debug, Clone, Attribute("width")]
struct Width(String);

#[derive(Debug, Clone, Attribute("height")]
struct Height(String);

for newtypes where the .0 is a string.

Or figure out something else.

We have functions such as add_style, add_class, add_text, etc on Node.
They all add to the global attrs.

As such these are convenience functions, and don't enable more functionality.

Therefore, it feels more precise to have these only in NodeExt instead of on Node itself.

Right now, if we do Div.class("a").class("b") we end up with <div class="a" class="b"></div>, which interestingly some browsers swallow up and turn into <div class="b"></div> (iirc).

The workaround now is to instead do Div.class("a b"), which does the correct thing.

If we allowed the same user APIs but stored it on the node differently, we could fix this.
We could then also allow removing classes.

It seems that what is referred to as tags in code should perhaps be called element in web vernacular.
We're learning!

HN example has a settings page which is now not visible from anywhere.
Blog example simply has no nav either.

Create a nav which can be used by both.
This also shows more how templating works.

Early experiments have left a bit of tests which serve no real purpose, and code which is commented out and/or not in use outside tests.

Delete.

Run this on all crates in repo: https://github.com/est31/cargo-udeps

Since we're lazy and just copy-pasting Cargo.tomls for new examples etc. right now.

The convenience function o(...) was used to go from a specific impl Tag type to Node.

So code like

let thing = o(Div).add_class("hi").kid(o(Span).add_class("hello"));

was common.

Now, we have an extension trait NodeExt, which allows us to instead write the above as:

let thing = Div.class("hi").kid(Span.class("hello"));

Which works by using the fact that all elements implement NodeExt, and e.g. class(...) takes the NodeExt implementor, turns it into a node, then continues working on it.

New style is cleaner, so purge the old!

Instead of a clone.
The clone mimics the HTML structure closely.

The cousin will instead follow the KISS principle.

Try to make HTML structure as simple as possible,
then do bootstrap/tailwind for CSS or roll own if we only need a few things.

We save a few keystrokes by keeping kid, but it looks jarring and is probably not used anywhere else.
Maybe we can do some import ... as ,,, tricks if child gets too long.

Since we cloned it by looking at the HTML source without having a good overview of it, the code isn't very neat.

Perhaps have a good spring cleaning of it or refactor it into more logical components.

Either this, or refactor the axum parts into a common example dependency.

If we solve #3 , then we can simply tie together examples using that to navigate in-between.

This also lowers the barrier for adding new examples, since there is less boilerplate.
It also then highlights what the responsibility of html-strong is, vs. what axum does.