While the project objectives are very nice, I hope it solves one other problem, the "contentEditable" problem
In the pre-historical days, web pages are static, served as a file blob, in one way, or both ways (FTP)
Then there came server side templates, we now have dynamic pages.
Then CGI and Perl came, we have <form> so user could put their contributions to the server.
Then there's AJAX opened the possibility of "Web apps"
However, all of existing efforts left behind a very basic concept of HYPERTEXT: It is always read-only or partially read-only. The browser is good at display HYPERTEXT or manipulating part of it, but not create those.
We have WYSIWYG editors, and the famouse Markdown (and alternatives), they lowered the level of entry of a "writable" Web.
I hope in one day, users can write hypertext freely, as easy as make an edit on contentEditable, the user input & interactions could become parsable data, and the developer's layout/css tweaking and js debugging could be made from web browser Firebox/DevTool directly back to LESS/Coffeescript.
Browsers, really, should consider shifting from a consumerism tool to an authoring platform. Branched, incremental and versioned.
> I hope in one day, users can write hypertext freely, as easy as make an edit on contentEditable, the user input & interactions could become parsable data, and the developer's layout/css tweaking and js debugging could be made from web browser Firebox/DevTool directly back to LESS/Coffeescript.
If you only care about the content, then a wiki engine with support for flexible styles should be enough to fulfil your hope.
Instead if you want to be able to completely rewrite a page, including its layout and behaviour, then you need to take into account that the page you see is not just "content" but "code + data".
I always wanted to have a "Edit source" button in applications, but then, what does it mean to "edit the source"? Decent web pages are produced by quite deep applications stacks composed of megabytes of running code. To show a link to a certain resource you need, in current frameworks, something like a 20-level deep stack of functions calls. At which of these points would your editor works?
If applications where completely client-side you could think of editing most of it in the browser, but still, which client could handle the client-side creation of a Wikipedia page, for example?
In the pre-historical days, web pages are static, served as a file blob, in one way, or both ways (FTP)
Then there came server side templates, we now have dynamic pages.
Then CGI and Perl came, we have <form> so user could put their contributions to the server.
Then there's AJAX opened the possibility of "Web apps"
However, all of existing efforts left behind a very basic concept of HYPERTEXT: It is always read-only or partially read-only. The browser is good at display HYPERTEXT or manipulating part of it, but not create those.
We have WYSIWYG editors, and the famouse Markdown (and alternatives), they lowered the level of entry of a "writable" Web.
I hope in one day, users can write hypertext freely, as easy as make an edit on contentEditable, the user input & interactions could become parsable data, and the developer's layout/css tweaking and js debugging could be made from web browser Firebox/DevTool directly back to LESS/Coffeescript.
Browsers, really, should consider shifting from a consumerism tool to an authoring platform. Branched, incremental and versioned.
My two cents.