[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat
From: |
Ivan Zaigralin |
Subject: |
Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat |
Date: |
Thu, 08 Mar 2018 11:04:13 -0800 |
User-agent: |
KMail/4.14.10 (Linux/4.4.118-gnu; KDE/4.14.32; x86_64; ; ) |
Just like Stephan, I am mostly an observer when it comes to web standards,
although I did wet my toes by writing personally to Tim Berners-Lee about
their epic EME fail, and later by trying to convince various people of
consequence that we, the free software community, need to fork everything w3c
got, and take them out to the curb. So I guess I am not really much like
Stephan, being a meddler and all that :)
Anyways,
Other replies to this post are correct to point out there are HTML+CSS
features which allow interactivity and adaptive design without a need to
resort to client-side scripting. What Stephan says about the application stack
goes had to hand with that. I think I would agree that regardless of how it's
accomplished on a technical level, web users do expect something like an
application platform, or may be even an application marketplace. Even
something like a simple POST/GET form creates an air of interactivity, and the
website becomes, essentially, an app in the mind of a user. Web search sites
function like app stores/repos, you get the idea. It seems kind of pointless
to object to this way of using the web, as long as we can implement it in an
ethical, user-friendly manner — as opposed to user-hostile. And it does look
like this is a tractable problem. Even now, most appy needs can be met with
HTML+CSS, and the rest can be implemented in browser plugins and new tags.
Whether or not we can overcome the inertia or even convince most users this is
a direction worth exploring, that's an open question.
I completely agree about the bloody gooey mess that is HTML without the
leading X. As TBL himself said back in 2006, when he was still worth paying
attention to,
> The attempt to get the world to switch to XML … all at once didn't work.
> The large HTML-generating public did not move
12 years later, the large HTML-generating public is guzzling the cool-aid, so
we are as far from a wide adoption of a sane technical standard as we've ever
been, and the outlook is not good. Notice how astute this quote is, it
correctly identifies the culprits, who are not web users, not browser
developers, not standard-setting bodies, but the web developers. And the
problem with them, there are only a few good apples in that barrel.
Let's try to analyze this issue and look for possible solutions. The
commercial web is huge these days, could that be the source of the mess? It
seems plausible to me that the commercial web design is motivated, in large
part, by competition. And what could be better than your competitor's website
being 35% less funteractive than yours? Well, one thing comes to mind — when
your competitor's website stops working altogether. So if you are a commercial
web designer, there is this massive *evolutionary* pressure to bend the web
standards to your personal will, and I doubt it can be counteracted by good
intentions or even good work done by small minorities. The large HTML-
generating public will surely continue to tug on the standard from all
directions, chaotically, with the end result of HTML# absorbing more and more
collective stupidity, with none of the old issues ever being fixed.
Now let's talk solutions.
A pipe-dream solution is a new web standard, basically web 6.0, with
everything above URIs rewritten from scratch. Dump the XML monster, no one
will cry. Lay down clear guidelines for going forward, taking the needs of
users, including privacy and security, into account. From the ground up,
design the markup with interactive functions in mind.
A safe and practical local solution for the free software community is an
XHTML+CSS fork, and convincing user-respecting web designers to make a clean
break.
The only practical global solution would be legislative in nature. We must
apply enough pressure on commercial web designers to counteract the
evolutionary force which drives them deeper into the HTML5 jungle. Web users,
not Web designers, should have the ultimate control over the web platform,
unless they <3 getting shafted with every click. Indeed, web designers are
neither demanding nor exercising any direct control, being completely at the
mercy of what is *perceived* as the web standard, so they won't care or
notice. Their current influence is simply a superposition of millions of
little individual tugs, and we could block it very effectively with basic
regulations protecting the consumer rights on the web.
On Wednesday, March 07, 2018 20:14:50 Stephan Kreutzer wrote:
> Hi guys,
>
> I don't know to which extend each of you is involved in web standards -- I
> myself only observe it passively, so feel free to object to any of my
> following statements:
>
> To me, it looks like that there can't be a HTML6 any more than there was a
> HTML4 and HTML5, because in HTML5, the crazy web guys decided that they
> neither need a DOCTYPE any more, and the deprecated version attribute for
> the root element was removed, so now, to my knowledge, there's no way to
> distinguish a HTML5 document from a HTML6 document except reading the whole
> thing and heuristically find out at the very end that it isn't the
> version/standard your custom supports, or to find out according to which
> Schema that document wants itself to be validated against. The idea here
> seems to be that older clients are supposed to still be able to
> read/interpret documents that contain elements of a newer standard, but
> only react to those elements they support and ignore all others, at the
> expense of never being able again to introduce new structures that conflict
> with the older standards, as there's no secure path for safe identification
> and conversion any more.
>
> Regarding the scripting and general conception, I arrived at the impression
> that the web is more or less an application stack (forms and JS and media
> elements and whatnot) and not for mostly static documents at all, because
> what do you have for the latter? Headers, paragraphs, lists and only the
> most primitive type of link, that's basically it? The initial concept and
> spec seems to be focused on providing a mechanism to link together
> resources from different systems in different formats in lists, so it's
> easier to navigate them while the host system details are abstracted away
> by the URL [1], while the CERN research data and publications themselves
> weren't (re)written in HTML (and how could they, who would ask the world to
> convert all of their stuff for this small Hypertext system that doesn't
> offer a lot for text?). Later, the browser people abandoned the semantic
> web as there's more money in e-commerce, online applications and
> centralized services like Google. What would happen if ordinary people
> could run their own small clients/agents that can easily work with data
> that's published on the web without the need to bring a big, bloated
> browser that's able to parse whatever crap HTML might be out there and
> tries to make something reasonable out of it? And now that effort is
> revived under the new name "linked data", but in contrast to semantic web
> ideas, now humans are supposed to invest their valuable lifetime to read
> API documentation and write specific code for it.
>
> I might be totally wrong with my perspective, but on 2018-12-09, it'll be
> the 50th anniversary of Doug Engelbart's Mother of All Demos, so there's a
> group that tries to come up with something that's a better networked
> environment than what we usually encounter today, along the lines of the
> early Internet pioneers [2], Doug Engelbart [3], Ted Nelson [4], and I'll
> also add David Gelernter [5]. Things are all over the place as the new
> system isn't there yet, but
>
> https://doug-50.info
>
> is a place to learn more about those efforts and to get involved, as I would
> doubt as of now that "HTML6" will help with some of the problems at hand.
>
>
> Sincerely,
> Stephan Kreutzer
>
>
>
> [1] https://www.youtube.com/watch?v=x2GylLq59rI
> [2] https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing
> [3] https://www.youtube.com/watch?v=yJDv-zdhzMY,
> https://archive.org/details/000127EngelbartColloquiumPart1 from 38:00 on,
> https://archive.org/details/000127EngelbartColloquiumPart2 from 44:00 on,
> but especially from 49:19 [4] https://www.youtube.com/watch?v=c3I54QXQPLA
> [5]
> https://www.youtube.com/watch?v=XrhM6uXMLZg&list=PLZQMfWBUelIge46VFOd53V1Ih
> W-UzHScK https://www.youtube.com/watch?v=8pTEmbeENF4
>
> --
> Sent with freely licensed software (GNU/Linux). See
> https://www.gnu.org/distros/free-distros.en.html For encrypted
> communication (GPG):
> https://pgp.mit.edu/pks/lookup?op=get&search=0x25BE126289B321DC
>
> --
> http://gnuzilla.gnu.org
signature.asc
Description: This is a digitally signed message part.