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!
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...
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.
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, ...
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..
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.
A private instance for the Finkhäuser family.