Re: The challenges of HTML editing

On 2024-05-10 14:16, Joshua Cornejo wrote:
> Hi all,
> 
> Following today’s call where I asked how to edit the pages, I was told 
> that most people just edit in github.

> For some reason (I remember FrontPage from MS) HTML editing has devolved 
> … so even this solution will need to be a mix of editing both HTML and 
> on the WYSIWYG plug in. (And GIT seems to have a problem with html – as 
> I’ve tried different ways and it keeps removing spaces from the original 
> HTML file).
> 
> If anyone has a better solution – please share.


IMHO, "better" is going to be in the eyes of the beholder ;)

You raise a major topic since the dawn of authoring and publishing HTML 
documents on the Web (if not decades before in computing for authoring 
human-readable documents). I find this topic fascinating and complicated 
to say the least. I also see how modern open web standards can be used 
to realise the necessary tooling for individuals. Needless to say, there 
are already countless tools and services out there ranging from raw HTML 
editing to WYSIWYG editors.

In fact, the Web browser ( https://en.wikipedia.org/wiki/WorldWideWeb ) 
gave us the ability to read *and* write in the browser. Amaya ( 
https://www.w3.org/Amaya/ ) was W3C's Web editor that beautifully 
exemplified - "ate its own dogfood" - what web standards can do.

I believe in this day and age, technical specification authors/editors 
for instance need not be constraint to the Git(Hub) environment / flow 
to edit, author, annotation, publish. W3C doesn't mandate a particular 
tool but instead describe specification "publication rules" for HTML and 
CSS. That said, here we are, most of us are still mangling through raw 
HTML editing - for better or worse.

I think we, as editors/authors of technical specifications are missing 
out a lot on what the Web platform offers. We can do better.

That's a long way of getting to my point on the project I've been 
working on for a long time now. It is called dokieli, which is "a 
clientside editor for decentralised article publishing, annotations, and 
social interactions.":

https://dokie.li/

Source: https://github.com/linkeddata/dokieli

It tries to apply an ocean of web standards: 
https://github.com/linkeddata/dokieli/blob/main/README.md#specifications 
includes Solid stuff, as well as making some ways into ODRL (see 
screencasts e.g.:

"Open digital rights contrasting storage description and personal 
policies, agreements and actions between people":

* https://dokie.li/media/video/dokieli-odrl-storage-description.webm
* https://dokie.li/media/video/dokieli-odrl.webm

Much in the spirit of the first browser and Amaya.

If you're up for a backgrounder on dokieli, check out:

https://csarven.ca/okieli-dokieli

Now, is this "better" than the common flow out there for writing 
technical specifications or that anyone is going to change their way 
over night? Unlikely. But, I feel this approach is promising and many 
would like to continue at. Not everyone wants to always drop-down to 
"handcode" authoring as the primary way. The user ought to focus on more 
interesting things about their document. Making connections / linking... 
Here is one of million examples:

https://dokie.li/media/video/dokieli-spec-conformance.webm

showing specification requirements, test coverage, version diff, and
change log based on:

* https://solidproject.org/ED/protocol
* https://solidproject.org/TR/2022/protocol-20221231
* https://solid-contrib.github.io/specification-tests/coverage (for the
purpose of this demo).

And a graph view.

Here is a graph view of a bunch of specs based on the underlying Linked 
Data (in RDFa):

https://solidproject.org/TR/?graph=https://solidproject.org/ED/protocol&graph=https://solidproject.org/TR/2022/notifications-protocol-20221231&graph=https://solid.github.io/web-access-control-spec/&graph=https://solidproject.org/ED/qa

...

-Sarven
https://csarven.ca/#i

Received on Tuesday, 21 May 2024 09:13:42 UTC