Hallstyles

Reply: Hallstyles

my proposal in a nutshell:

whostyles are defined using <link rel="whostyle"> tags in the <head> of a post page
the class name of a whostyle element is “whostyle” and then the URL of the poster’s h-card, with spaces and punctuation replaced with hyphens (e.g. whostyle-jacobhall-net)
when writing a whostyle, assume that you inherit the CSS rules of the parent website
whostyles should be stored and linked per-post rather than per-poster

Aha - since you’ve got Webmentions up, let’s do this!

Hey Jacob! I’m familiar with your website - I covered your linkroll in Directory Uprising.

It’s really comforting to see you interested in projects like directories and whostyles that aren’t necessarily protocols - which the Indieweb can get very focused on. Whostyles are definitely a tough one to turn into a protocol - since CSS evolves over time and it’s tough to know how to restrict the styling. (But it’s also important bc perhaps you don’t want to load a bunch of whostyles that blow up your site.)

Your introduction of all: revert is exciting - didn’t know about that!

My larger plan for this site involves a full comment moderation system, so I already intend to read everything that people send me. Given the scale of my site, and the relative geekiness of whostyles as a concept, I’m not too worried about how many CSS rules I’ll have to manually review day-to-day. When my webmention endpoint receives a webmention, it will sniff the source site for a whostyle. If one is detected, it will be downloaded and presented to me as a part of the comment moderation process. I will review the rules within it, making sure that it a) doesn’t do anything naughty and b) doesn’t completely break my site. Perhaps if this becomes a burden, I’ll invest more time writing a script to do the editing for me.

So this is exactly what I do as well - just manually create the whostyles and apply them once I get into a longer dialogue with someone. This gives me (and hopefully you now) plenty of time to mess with whostyles in the field.

Over years of reimagining ourselves online, it would be very complex to create styles that properly support everything we’ve written.

This is another thing I think about as well - and I guess I was going to take it on a case-by-case basis. If h0p3 has a new style, I might make a new ‘h0p3_2’ style for him - or might just update the old stuff if it makes sense.

Ok - as far as your proposals, they look good! My original plan was pretty shaky - so am glad to see improvements. Just feeling a lot of gratitude that you took the time and have energy to put into it.

I guess, as a bit of additional response, I should also mention that I’ve thought about doing this as a JSON format rather than as CSS.

Here’s a look at the JSON format we’ve been using for Multiverse box styles.

{
    "header": {
        "color": "#6B1173FF",
        "back": "#B6B5A8A5"
    },
    "main": {
        "fill": {
            "type": "Solid",
            "color": "#FAE9FF00",
            "back": "#FFFFFFF2",
            "direction": "vertical"
        },
        "border": {
            "color": "#000000",
            "style": "none",
            "radius": 0
        },
        "shadow": {
            "type": "None",
            "color": "#B6B5A8A5",
            "style": "plain"
        },
        "highlight": {
            "type": "None",
            "style": "plain"
        },
        "text": {
            "font": {
                "family": "Roboto"
            },
            "fill": {
                "type": "Solid",
                "color": "#6B1173FF"
            }
        }
    },
    "title": {
        "fill": {
            "type": "Solid",
            "color": "#FAFAFA00"
        },
        "border": {
            "color": "#2DC0A6FF",
            "style": "dotted_1px",
            "radius": 0
        },
        "shadow": {
            "type": "None",
            "style": "plain"
        },
        "highlight": {
            "type": "None",
            "style": "plain"
        },
        "text": {
            "font": {
                "family": "Red Rose"
            },
            "fill": {
                "type": "Solid",
                "color": "#17C27FFF"
            }
        }
    }
}

For fonts, we could keep an expanded list of font names that are supported - or at least a kind of registry - just like browsers already understand Verdana, Arial, Courier, etc.

So perhaps this paired with a font registry format would do the trick. I don’t have a strong preference tho - and am just throwing this out there.

PLUNDER THE ARCHIVES