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 The design I've got in mind (and briefly described today) should work well with any stylesheet, but especially ones which don't use custom classes! And as always I'll make sure I have a nice fallback stylesheet!

Attribute editting would be complete but deemphasized.

The main limitation in what I have in mind is lack of support for webform editting. Though I prefer that to be seperate anyways, with something that can handle the submissions... And double-nesting would be tricky...

@Seirdy Oh, and yes I'd be interested in somehow exposing this to webservices as a form input type they can reuse!

Given the architecture I have in mind that should be straightforward! Hardest would be designing an API that degrades gracefully...

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).