lel

http://catb.org/~esr/html-hell.html

I will try all of them some day.

HTML is hell.

Perl is Dante's Inferno.
PHP the gjeprn;lwvacm;/cworse than χάος

>>1
ESR doesn't like black backgrounds. I guess that means he doesn't want his webpages to be easy to read or something. Stupid fucker.

>>5
You didn't read correctly:

[b]Forcing[/b] one of background and text colour, but not both.
  Suppose I like my pages to default to green text on a black background? (Yes, I actually got email from a reader who does this!)
  If you set your background color to white (or worse still, orange — this has happened too!)

IoW, he is talking about the contrast that must be implemented between background and foreground, esp in text. But above all, he is against the forcing of any style sheet. Only the user should decide.

I also like his take on images and media. Those things should have alternatives for TUIs AND they should be loaded last. IoW, the imperative content gets sent out first, then the other shit can follow. Let The CSS style the rest.

>>6
I'd take it one step farther for the CSS/JS bits. It should be possible for a web browser to be written that doesn't fetch any CSS/JS/etc from a server at all - by which I mean it just doesn't follow href tags in <link rel="stylesheet"> tags, not that it magically predetermines what the content of an item to retrieve will be - and likewise doesn't execute any javascript from the server. On the contrary, it relies on only local CSS and JS, as if it were Userstyles and Userscripts only. It should be possible for such a hypothetical browser to navigate any page on the web just fine. Ideally, there should be naming conventions for divs (like HTML tags themselves could have been, before W3C got its head stuck even farther up its ass) so that a single master CSS file can control any normal website to the user's specification.

I remember when I actually thought web development might be a thing that didn't suck. I saw http://www.csszengarden.com/ and thought ``This is going to take off, this is going to be big - I'm going to be able to theme any well-written page any way I like. I'm going to be able to flip a switch at 7 PM and make every webpage have a dark theme.'' And that still should be something that could happen.

>>7
For that I'd the go for the real step that should be taken:
http://gofish.sourceforge.net/

Honestly, that's HTML really fucked up the server/client model. It should not be worth considering.

The rest should be in SQL databases, with nice API like procedures only accessible via SSH. Nice and sane referencing of data/content, like a VCS. A true C[/F]MS.

>>8
HTSQL?

>>8
I'm not a fan of ``Everything is a database, every page is a query'', because databases are big and ugly and I like that I can pull down the source for one page and get (mostly) all of it, but I get what you're saying about content and presentation, and they're an implementation detail.

As for Gopher, goddamit guys. I started browing around and the second link on floodgap I click on leads to some anonymous bbs with ``Xarn fanclub thread'' and other things. By the timestamps, it was another CAPTCHA reaction spinoff I missed the construction thread for. (Replying by Gopher is a pain in the neck).

Everything you can fuck is an anus.

>>10
That's Hotaru's BBS. It's a few years older than /prog/'s CAPTCHA, but also completely abandoned, like all of Gopherspace. The only thing that's left there is paranoiac libertarians and gopher://xarn.no-ip.org:7070/.

Gopher is just pretty awful anyway. People assume that because the Web sucks, HTTP must necessarily suck as well, and anything that's not HTTP must be better. They're wrong on both counts.

>>12
All, I want is a simple CRUD protocol. Is there like an non-pervasive HTTP-lite that truly respects privacy and user rights?
All I can think of is NNTP, PostgreSQL, STOMP, IRC, and a PSYC one. Tell me if there are any others.

>>13
What's wrong with HTTP, honestly?

>>14
Just the massive required headers (bandwidth), synchronous transmission (really? when everyone knows asynchronous is the way to go), few TCP unsafe protocols, and that most HTTP servers abuse it to gather unnecessary intel on their users. Fingerprint is the worse, it and was made the norm two decades ago. Honestly, I like NNTP and STOMP the best. PSYC being the best freeform contender. And IRC, is well IRC.

Notes:
http://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html
http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm

>>15
NNTP is basically HTTP without the headers (and therefore the versatility), and STOMP is basically HTTP without the status codes. IHBT.

>>16
So you concur? But I thought STOMP was even more raw and barebones, that you actually have to create your communication states. Not trolling, really discussing. Just not bumping 'cause we need to make SexpML. Or just use org-mode

>>17
Please tell me you're not suggesting
#+BEGIN_PARAGRAPH
Hello #+BEGIN_SPOILER /prog/ #+END_SPOILER
#+END_PARAGRAPH
Please.

>>18
LOL, not that way:
#+BEGIN_SRC BBCODE :exports results
Hello [spoiler] prog [/spoiler]
#+END_SRC
Better yet:
#+BEGIN_SRC sexpml :exports results
(p 'Hello' + (spoiler 'prog'))
#+END_SRC
Of course, if you have:
src_bbcode[:exports results]{Hello [spoiler] prog [/spoiler]}
src_sexpml[:exports results]{(p 'Hello' + (spoiler 'prog'))}

Or you can make sexpml like this:
#+BEGIN_SRC sexpml :exports results

(p 'Hello' (spoiler 'prog'))

#+END_SRC

src_sexpml[:exports results]
{
(p 'Hello' (spoiler 'prog'))
}
I am not sure if breaking the src_<language> commands works, for indenting in the GNU style.

>>17
No, of course I don't concur. HTTP's headers are a good thing. They let you do things like add different kinds of compression to the protocol without having to come up with a new standard. There is nothing wrong with HTTP that NNTP or STOMP (or fucking gopher) even begin to address.

>>19
Yeah, no, org-mode syntax is SHIT.

>>21
Any other suggestions? 'Cause compression is applicable on NNTP and STOMP during and before a stream. You still have not addresses the bandwidth issue, asynchronous streams, and TCP safety. I am fine with a HTTP-lite mode; which is not on the standard.

>>22
I only say so, in cause you want to address other documents formats that the client can view/save as. In case they want to see LaTeX, HTML, DocBook, or roff for that matter. Like a browser that is pure org-mode, so it reads and displays on the fly. Unless you want to create another render engine.

>>23
Oh, makes sense.

But honestly, designing (and implementing) a SexpML spec from scratch is way more fun than reusing emacs.

>>24
Well SexpML has not been made yet, so we would still need to create it; even if we make a org-mode module. Should I ask that Anon to create another hidden Fossil client for the standard draft?

>>25
Sure. I'll have to learn how to use Fossil once and for all, but I guess that's a good thing.

>>7
W3C is the NSA's Manchurian Candidate program

They realized that people trust professors more than the eggheads at Xerox PARC

A rich history of digital communication since Telex