Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Forking HTML into a static language doesn't make sense

robert.ocallahan.org

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Forking HTML into a static language doesn't make sense

#81

Post by sergeykish »

bjoli wrote: post #67
sergeykish wrote: post #52

Earlier quoted context omitted.

But what is the difference once you disable JS and CSS? And reader mode? I find it great that I can progressively enable features.

I can't browser it in emacs, the world's best tool for navigating and working with text :) I have thought about what I want since writing. I want a format where the receiving end decides how to display it. Tabular data? Give me a default sort and leave the rest to me. Images? Should they break text or be showed as a thumbnail with textflowibg around it? I haven't thought a lot about it, but I want content with metada…

Sure, and browser is a javascript virtual machine to execute HTML/CSS/JS serialized images fetched from network. It just happens that some images can be converted to readable text.

I still don't get it, most of the web perfectly works without JS, so what is the problem? Most of the authors equally don't care about your and my case. Maybe text around article? It is easier with CSS support, thought it should be possible to replicate reader mode heuristics if it was not done already, fetch what to hide from UserScripts or create alternative.

Images may come in different resolutions (up to 8K).

Re: Forking HTML into a static language doesn't make sense

#82

Post by ezequiel-garzon »

sergeykish wrote: post #59
ezequiel-garzon wrote: post #58

Earlier quoted context omitted.

I don’t see how making text legible and adding some style to tables would break existing unstyled pages. With regard to your second point, I’m not talking about user style sheets, but about the prospect of writing unstyled HTML. If I ever get to post anything on my personal website I will walk the walk and use plain HTML, yes, but I doubt this will have any meaningful impact!

It would make them look different, maybe conflicting with other applied styles. Browsers still supports quirks mode. It is only possible to change defaults if no content exists - XHTML has no quirks mode. I'm trying to explore this direction, http://sergeykish.com/live-pages - just a few rules. Publish it, this page is from 2015, finally published. I believe the main obstacle is authoring and I want to resolve it. Wr…

Hey, thanks for your replies, and interesting project! Correct me if I'm wrong, but quirks mode applies when the doctype declaration is missing, right? I'm talking about modern, validated HTML documents that have no CSS. And I'm sorry to repeat myself if you go over my comment history, but the whole thing about having to specify all of a sudden in a proprietary tag that I suggest to use the device(-)width as the width... well, is my ultimate pet peeve. Again, I'm talking about valid documents that make no use of CSS at all, and that failing to include that render the text font microscopically. That would be my suggested point of departure for the improvements, and generally speaking I feel the overall default aesthetics could be improved without breaking anything.

Here is a relevant example. The very first website ever made [1] renders like this [2] without a viewport meta style on a current iPhone, but like [3] when you include this tag which made its debut decades later. Again, I believe way more could safely be done from the browser side, but this would be a sane start.

Edit: I realize I'm giving the oldest possible example, which necessarily triggers quirks mode, but the same can be said of any modern, proper HTML document without CSS.

[1] http://info.cern.ch/hypertext/WWW/TheProject.html

[2] https://imgur.com/gallery/0THBhQ9

[3] https://imgur.com/gallery/HQkxXFF

Re: Forking HTML into a static language doesn't make sense

#84

Post by earthboundkid »

bonestormii_ wrote: post #66
earthboundkid wrote: post #55

Earlier quoted context omitted.

I'm not sure why you think the web is less parseable now. HTML5 is well described and it's easy to get a compliant HTML5 parser for whatever language. Back in the day, people were just doing regex. There's a separate issue that a lot of stuff requires JS, but the JS mostly just calls JSON endpoints, so that's easy to scrape. The tricky thing is scraping ASPX sites that jump through a bunch of hoops instead of having…

Oooo well said. One of the first programs I ever wrote was a scraper for such an ASPX site. Parsing state ids and reposting them over and over again... what a joy it was.

Good news, ASPX is alive and well in the United States governments many state backends 🇺🇸 🇺🇸

Re: Forking HTML into a static language doesn't make sense

#85

Post by earthboundkid »

wegs wrote: post #76
bonestormii_ wrote: post #66

Earlier quoted context omitted.

Oooo well said. One of the first programs I ever wrote was a scraper for such an ASPX site. Parsing state ids and reposting them over and over again... what a joy it was.

Much as an argument confusing World War II Germany with the Holy Roman Empire might be called 'well-said.' You're confusing the early web era with the dot-com boost/bust period. The early web were the era of dozens, perhaps hundreds of competing web browsers which were made possible by simple, well-engineered web standards. Pages were served statically, or with CGI scripts. You had a whole swarm of generic spiders, c…

If you define early web as pre-1998, then you’re essentially talking about five guys who all had computer science backgrounds. Yes, they were good at their jobs, but it was never going to last. Increasing the number of web developers by 1000x by definition had to drag down their average skill level to the average skill level of the population at large.

Most definitions of the early web include the PHP Cambrian explosion because essentially all websites today got their start then and only a few horseshoe crabs sites (mostly the homepages for CS profs!) predating it survive. Gopher sites were also probably really easy to scrape too. ;-)

Re: Forking HTML into a static language doesn't make sense

#86

Post by wegs »

earthboundkid wrote: post #85
wegs wrote: post #76

Earlier quoted context omitted.

Much as an argument confusing World War II Germany with the Holy Roman Empire might be called 'well-said.' You're confusing the early web era with the dot-com boost/bust period. The early web were the era of dozens, perhaps hundreds of competing web browsers which were made possible by simple, well-engineered web standards. Pages were served statically, or with CGI scripts. You had a whole swarm of generic spiders, c…

If you define early web as pre-1998, then you’re essentially talking about five guys who all had computer science backgrounds. Yes, they were good at their jobs, but it was never going to last. Increasing the number of web developers by 1000x by definition had to drag down their average skill level to the average skill level of the population at large. Most definitions of the early web include the PHP Cambrian explos…

It was before your time, kid. (1) I think you underestimate the early web by quite a bit. It had a lot more awesome than you give it credit for, and if not for dot-com bubble + bust, it would have evolved in a much more thoughtful way (2) And dot-com boom and growing developers 1000x didn't need to involve Netscape, Microsoft/IE, or the W3C implosions of the time. Those were a question of management decisions and personalities.

But my original comment was 100% unambiguous: "I liked HTML2. I hated basically everything which went into HTML3 and HTML4."

Y'all responded by citing bad examples from the HTML3 / HTML4 era as examples of things going wrong...

---

Note: Before I get jumped on for "kid," it's the username.

Re: Forking HTML into a static language doesn't make sense

#87

Post by leephillips »

smacktoward wrote: post #42
Grumbledour wrote: post #7

The Gophersphere seems to prosper and I have seen some interest in Project Gemini[0] over on Mastodon in the last weeks. So I guess People are trying and somewhat succeeding. Personally, I am also quite skeptical of the benefits of these approaches. I would like a web more focused on documents, but many of the "forbidden" features these communities define are actually things I was excited about when they were introdu…

Once upon a time (aka the early '90s), Gopher and WWW were both simple systems for publishing hypertext. Neither one was appreciably more complex or ambitious than the other. WWW eventually pulled out into the lead, due largely to licensing considerations; WWW had been developed at CERN, which explicitly disclaimed any ownership over it, while Gopher had been developed at the University of Minnesota, which preferred…

That’s not why the web won over gopher. This is why:

“Both Gopher and the Web embraced the idea of hypertext. Both allowed users to follow a conceptual path through a virtual space by following links, with little need to understand the structure that existed underneath. They differed considerably, however, in the information architecture that they established for laying out hyperlinked information. The main difference between the two is that the HyperText Transfer Protocol (HTTP) of the Web was built up around documents in HyperText Markup Language (HTML). This markup language allowed document creators to place links within documents, whereas Gopher provided pointers to documents through menu files, which existed separate from the documents themselves. The indexing component of the two information architectures -- i.e. the part that enumerated what items existed within the information space and where they could be found -- thus differed considerably.” From https://ils.unc.edu/callee/gopherpaper.htm

I was using Gopher and WAIS (nobody seems to remember that), both improved versions of FTP, when the web appeared. It immediately captured my imagination, and I and everyone around me forgot about the other protocols (except FTP, which hung on for ever). It had nothing to do with licensing. It was hypertext.

Re: Forking HTML into a static language doesn't make sense

#88

Post by Rotten194 »

earthboundkid wrote: post #39
Grumbledour wrote: post #11

Earlier quoted context omitted.

I think this is an interesting and important argument, because I always felt many shortcomings of the modern web were actually caused by browser vendors and their reluctance to improve their platforms and the web. We have so many custom UI Elements, because forms did and still do suck. RSS always had a back seat, because it always was second class in browsers. Semantic web died outside of search engines, because brow…

Forms suck, but if you actually make a form, it becomes clear that while you can do 90% of stuff declaratively, there's a leftover 10% that just has to be described imperatively, which requires something like JS. Modern forms actually give you a lot for free with pattern matching and whatnot. I could imagine it going a little further and adding properties for "dirty" or not, which right now you have to add using JS o…

The thing is, (at least personally I feel) JavaScript isn't the problem. The problem is because of the lack of tools people have leaned into doing everything with JS, instead of trying to manage the awkward 50-50 split we had before. If 95% could be done with HTML++, then a couple form customizations and a bit of business logic being done with 100 lines of JS would make sense and not be as horrible as the modern web.

Re: Forking HTML into a static language doesn't make sense

#89

Post by sergeykish »

ezequiel-garzon wrote: post #82
sergeykish wrote: post #59

Earlier quoted context omitted.

It would make them look different, maybe conflicting with other applied styles. Browsers still supports quirks mode. It is only possible to change defaults if no content exists - XHTML has no quirks mode. I'm trying to explore this direction, http://sergeykish.com/live-pages - just a few rules. Publish it, this page is from 2015, finally published. I believe the main obstacle is authoring and I want to resolve it. Wr…

Hey, thanks for your replies, and interesting project! Correct me if I'm wrong, but quirks mode applies when the doctype declaration is missing, right? I'm talking about modern, validated HTML documents that have no CSS. And I'm sorry to repeat myself if you go over my comment history, but the whole thing about having to specify all of a sudden in a proprietary tag that I suggest to use the device(-)width as the widt…

Thank you. Ah, so you grudge is , sorry, I was confused by default awful table style.

That is much harder, there was no simple answer [1], browsers displayed viewport, some (Opera Mobile or Mini) had text reflow option. One company decided that it is authors responsibility [2], others followed. And now it is bad default.

So what can we do? Improve own experience – vote with your feet, inject setting in extension, patch and compile open source browser – plenty of options, and write about it. From my experience – Linux, uMatrix, Stylus, patch Firefox, have to write now (I'll edit later). That's why why meant by "have you updated yours (user.css)?".

If anything we need more choice. Build your own browser -Ungoogled, Iridium, Tor browser, Beaker Browser. Hack on smaller codebase - Netsurf, Dillo. There are graphical DOS browsers, console browsers, BeOS browser, Plan 9 browser, Emacs browser.

I mentioned quirks mode (correct, without doctype) to show how insignificant details with almost no presence still guarded by browsers. That page was written before pixel perfect reproduction was a thing. There are a lot of pages from another era https://theoldnet.com/

[1] https://www.quirksmode.org/mobile/viewports2.html

[2] https://developer.apple.com/library/archive/documentation/Ap...

Re: Forking HTML into a static language doesn't make sense

#90

Post by boomlinde »

jasonlotito wrote: post #30

Developers can already do this. They can just use HTML. Plain old HTML. They don't have to use JavaScript. They don't have to use CSS. They can just use plain boring HTML. That they can do this now makes me ask the question: what problem are we solving? If people aren't using the existing solution enough, and the existing solution solves the "issues" of CSS and JavaScript being used, then what is the problem?

solderpunk addressed this (in terms of Gemini): https://portal.mozz.us/gemini/gemini.circumlunar.space/%7Eso...
Post reply on HN