On Sun, Jun 11, 2017 at 5:19 AM, Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:
> On Sat, Jun 10, 2017 at 01:30:12PM -0700, Louis Santillan wrote:
>> https://youtu.be/1uflg7LDmzI?t=5m35s
>>
>> James Mickens calls it Project Atlantis.
>
> I could not find any Project Atlantis code, do you know where to find it?
I haven't either. Presumably, it's locked up somewhere in MS
Research, Havard, or MIT. :/
>
>> Make the web/content developers responsible for their own rendering
>> and content parsing.
>
> No, this is exactly what you don't want. Current accessibility is already
> terrible. I'd like it if HTML goes back to a document-based model like it was
> created instead of a "pixel-precise" rendering model. The W3C should be more
> strict when defining these standards instead of adding random battery-reading
> APIs[0]! Currently using well-formed simple HTML or (the "old") Gopher it is
> possible to display (or listen!) to the document in any way.
I think if completely human readable markups were required (my
preference would be Creole+Salt+OpenIconic), then we could improve
accessibility. I actually have nostalgic feelings for gopher. One
thing that was lacking in gopher was the ability to deliver
applications. And I think the current web has proven that a
zero-install (or zero-friction install, or easily uninstallable)
application delivery platform has huge value. Ian Hickson also
mentioned that content-neutrality [0] is important in replacing HTML5.
> In relation to HTML: I think ideally Javascript and other custom client-side
> execution should be completely removed, but some semantic-context should
> be added to the current HTML.
I think client-side script should be made entirely optional and that
content should not depend on it. Maybe the way is to limit the amount
of code or to limit amount of content in each transfer/request.
> There are some useful things where Javascript is (ab)used right now, because
> alternatives are missing or inconsistent:
>
> - Implementations of more native missing/inconsistent control types: datepicker,
> colorpicker, etc.
> - Client-side form validation to indicate the user: should be native in HTML.
> (similar to <input pattern="" />).
> - Sending form data in a "dynamic" way (using XMLHttpRequest).
> - etc...
I agree with your point about the missing & inconsistent features.
[SNIP]
>
> W3C is also already "succumbing" (see editors list) to adding DRM[4] to your
> browser, wake up sheeple!
That has been disheartening. Even more so that Mozilla (who claims to
be for the people and the web) has accepted & implemented EME [1].
>> Narrow & simplify the scope of what a browser needs to be (shouldn't
>> duplicate all the functions of an OS). His Deny First Same Origin
[SNIP]
>
> Adding abstractions is not the solution in my opinion.
>
> It doesn't seem to simplify the scope. The rendering part is "just" given
> as responsibility to the developers and a RPC layer is added, but at this
> point you are already screwed in various ways.
Micken's intent is to reduce the abstraction. Rendering in this case
doesn't mean the same thing in this architecture. It's more of the
layout responsibility that CSS is supposed to fulfill.
[SNIP]
> Coming back to the real practical world: until then I try to keep my (personal)
> HTML pages simple[5] and use as little Javascript as possible (no jQuery!).
I agree. I'm planning on porting my notes over to Creole.
[0]
https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw
[1]
https://www.eff.org/deeplinks/2016/04/save-firefox
Received on Mon Jun 12 2017 - 12:29:27 CEST