Something I'd love to tackle once I've got text rendering working well (I hope I'll get that far at least!) is to tackle WYSIWYG editting! Because the indieweb needs that! Because don't want accessable to remain needlessly at-odds with accessible reading!

I'd implement 2 or (counting my "Amphiarao" web inspector) 3 distinct WYSIWYG editors builtin: 1 for HTML, & 1 for CSS.

The HTML editor would need deep integration into the browser engine, but most of that would be needed for text selection.

HTML editting would consist of a bottom-sidebar providing of all elements (with tooltips & MDN links) used to wrap the selected text in a specified element. Possibly replacing whichever element was already wraping it! Double clicking a selection would spread the selection out to its parent element.

I'd add outlines & labels to all elements containing the text cursor. Clicking handles selects the el.

Implement using CRDTs, & text selection is vital for a11y & OS integration.

As for CSS...


(Oh, I forgot to mention the attributes sidebar in the HTML editor...)

For CSS properties its all a matter of designing a nice organization/layout to find the controls in. And add dropdowns of extra options for vars, cascade, etc. Live previews will help!

For CSS selectors visually I might have to rely on syntax highlighting. But interactively I could highlight elements on the page to communicate what they mean. And I could let editors choose a sample of what should be selected!


@alcinnz Would love to see something that conforms properly to the WAI Authoring practices and supports microformats2. That could combine well with a stylesheet that doesn’t use any custom classes, just microformats classes and role attribute selectors.

My current site doesn’t actually use any classes in the CSS apart from image-rendering utility classes; I use POSH, ARIA and microformats selectors for everything else.

The great thing about a purely semantic stylesheet is re-usability across other websites.

#POSSE note from


@Seirdy @alcinnz There are limits to what you can do with purely semantic style sheets, and microformats don't help with that. Plus, reusability is not guaranteed.

Say your microformat (with pseudo markup) tags a first and second name. You could have e.g.

<blah role=first>foo</blah><blorp role=second>bar</blorp>

And you can apply some kind of format to these elements, and be happy. Say you align them so that the second name is big, and the first name floats...

@Seirdy @alcinnz ... above it and is much smaller. Something that might work for an address book or something.

On another page, the tags are different, and the last name appears first. Meanwhile the first name element is a table cell.

Your CSS would have to reinterpret the meaning of the page elements to apply the same formatting and still produce a sensible rendering.

Part of solving this is to not use microformats that mark up page elements with meaning.

@Seirdy @alcinnz You can instead embed the raw data in JSON or whatnot and reference that. That's not really what makes microformats powerful, though. But fair enough, let's go with that.

The point here is that in page elements, you'd reference that data as an atomic unit. Then you can format it the same wherever you reference it. Your universal style sheet works, at least.

But you're left with another problem. Maybe in a detail view to an address book entry, ...

@Seirdy @alcinnz ... you want to display the full name in big, but in the list overview you want to go with something more compacted as I described.

That is, the style that's best is highly contextual. And that's actually not a bad thing. Because it is what *permits* the optimal styling for whichever case you have.

In GUI terms, there is no "Person" widget. There's a ContactList and a ContactDetails widget; the database entry backing them is the same.

@Seirdy @alcinnz Microformats aren't intended for styling, they're meant to mark up styled elements with semantic meaning. And as much as HTML *should* be used more style neutral, something as simple as rearranging elements with the same meaning on a page changes display. You can't divorce HTML tags from display.

You can separate data from styling, but really the way to do that is with a templating system. However, when you look at those, you'll quickly discover..

@Seirdy @alcinnz ... that all the useful ones embed some kind of control flow language that at least let you render stuff in a loop, or switch out elements based on some variable's value.

But you do get a clean separation. And you could theoretically use it to select different templates to the same data on different pages. That's really the way to reuse "style", IMHO.

HTML+CSS are too hybrid for anything cleaner.

@jens @alcinnz I think what I described makes more sense for regular documents than for really fancy pages for which purely-aesthetic enhancements detached from semantics are mixed in with functional enhancements.

You can get a feel for what I'm describing on a page like with its dokieli widget.
Sign in to participate in the conversation
Finkhäuser Social

A private instance for the Finkhäuser family.