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

71–80 of 94 posts

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

#71

Post by protomyth »

miohtama wrote: post #69
protomyth wrote: post #49

Earlier quoted context omitted.

How much of the problem was the lack of power in the platform versus the actual design of WML. I remember it worked ok, but I was using a better platform at the time. Then again, I really didn't go much farther than working through the ORA book. I suppose, strictly, it did have WMLscript to go with it so might not be suitable for the original author.

As far as I remember WML was processed to a binary payload by an operator gateway and the phone never tried to interpret XML itself Thus, a special operator support was required with GPRS connection. In 2000 they also had WAP-over-SMS. That was slow. And expensive. One SMS could carry 140 bytes.

Yeah, I remember the binary convert thing, but the WML itself wasn't so bad.

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

#72

Post by WorldMaker »

zokier wrote: post #60
WorldMaker wrote: post #56

Earlier quoted context omitted.

4) The W3C HTML spec is now mostly just a placeholder that says "Whatever WHATWG thinks is best" and it is almost but not quite true that WHATWG's Living Spec is increasingly "Whatever works in Chromium/Chrome"

Well XHTML 2.0 was such a roaring success that I'm sure they'll be super stoked to take on another project to improve HTML as hypertext without the baggage of browser backing and buyin.

Correct, the debate over XHTML 2.0 was exactly why the WHATWG was formed. It's indeed how the W3C lost most of its teeth in browser standards. XHTML 2.0 had some good ideas, but it shows how hard it is to govern standards from ivory towers.

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

#73

Post by sergeykish »

dragonwriter wrote: post #45
recursivedoubts wrote: post #28

Earlier quoted context omitted.

Sure, but htmx is small (~1.7K loc[1]), written mostly by one guy part time and, while not perfect, advances HTML significantly as a hypermedia. That something like this hasn't been discussed in a significant, public manner by the w3c in over a decade[2] indicates to me there is either a lack of understanding or of interest in advancing HTML as a hypermedia. I readily admit I may be missing something. [1] - https://g…

What you seem to fail to recognize is that the reason nothing has been discussed (whether of the style you want or otherwise) at W3C regarding advancing HTML since XHTML2 is that the colossal failure of the “we’ll right a from-first-principles spec with no concern for pragmatics” approach with XHTML2 resulted in W3C being completely sidelined for HTML development. No one is listening to them, the browser vendors all…

XHTML was not that bad. It was quite conservative - make serialization/deserialization idempotent, remove document.write, quirks mode, DOM Level 0 accessors.

The stupid part was advertising of writing XML by hand - both XHTML and XSLT. That is machine format - "application" in "application/xml". Not more sense than writing JS AST. And semantic web has no advantage for author.

XHTML 2.0 - XML Events is like IE , alt is good, is good, removal of , - no one would see, XForms - partly adopted, and RDF - don't know.

Though it kind of understandable - XML was in rage. Everyone pushed it, Microsoft above all, IE5 accepted "text/xml" [1]. And Microsoft pushed XSLT without XSL-FO.

[1] https://www.xml.com/pub/a/1999/03/ie5/first-x.html

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

#74

Post by wegs »

earthboundkid wrote: post #55
wegs wrote: post #23

From my perspective, the reason to have a language for static documents is parsability. With HTML5+CSS+JS, there are few organizations at the scale which can sustain making something like a web browser, a general-purpose web crawler, a11y tools, or similar. Could it be a common language? Perhaps. I liked HTML2. I hated basically everything which went into HTML3 and HTML4. HTML5 has made a lot of good progress on roll…

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…

Your timeline is completely confused. ASPX came out in 2002, after HTML4. HTML2 was the era when CGI scripts were dominant.

Next, HTML2+SGML were also well-designed, and people weren't just doing regexp. The mess didn't come in until HTML3 and even more so, HTML4.

Today, it's easy to parse /specific/ pages. If I want to automate one web page, and it's well-formed, HTML5+AJAX makes that easy.

However, in contrast to HTML2, it's very hard to parse pages /generically/. That's why I gave the example of Altavista and a11y tools, which need to work with any web site.

Try to make something like that today: a generic search spider, a web browser, or an a11y tool. See how far you get talking to JSON endpoints. They're often easy enough to reverse-engineer for a specific web site, but you need a human-in-the-loop for each web site. With HTML2, one would build tools which could work with /any/ web site.

And boy were there a lot of tools. Look at all the web browsers of the nineties, and the innovation there.

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

#75

Post by sergeykish »

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…

Search engine that prioritizes pages with no JS and minimal CSS would help.

JS requires audit - even small script can game rank by encoding JS and CSS in other resources to pretend there is not much of it. Audit requires reproducible response, can be gamed, requires web of trust.

In the end it is all about goodwill, which may be hard to find in spyware ridden web.

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

#76

Post by wegs »

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.

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, crawlers, and bots which automated things on the web for you. Anyone could write a web browser, so many people did.

The dot-com boom/bust had companies doubling in size every few months, people who could barely code HTML making 6-figure salaries, Netscape imploding, early JavaScript (which, at the time, looked like a high schooler's attempt at a programming language), and web standards with every conceivable ill-thought-out idea grafted in.

If one of the first programs you ever wrote was a scraper for an ASPX site, you never saw the elegance of the early days. ASPX came out not just after HTML3, but after HTML4.

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

#78

Post by ultrarunner »

fardelian wrote: post #26
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…

You want "Save to my calendar" but we still don't have full support for date inputs. Chrome has supported the main features since 2012, Firefox joined only in 2017, and we're still waiting on Safari to make a move. https://caniuse.com/#search=input-date

I have an application that is partially broken in Safari only because of the lack of support for input type="datetime-local". Very frustrating.

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

#79

Post by danShumway »

One idea that I bring up whenever I see arguments around what features should be added to HTML or what splits should happen is that the DOM is not primarily a layout language, it is a presentation layer.

The really clever, wonderful part of HTML/DOM that is worth keeping around is that it forces you to describe your current page/application state as pure text.

Imagine if every time you wanted to write a GUI app with GTK, you were first required to build a functioning terminal interface, and then (for the most part) only allowed to pull elements from that terminal interface into the main GUI of your app. That is how the web do.

So proposals around, "HTML needs to be its own static thing" kind of miss the point in my mind. Suppose we had an amp-like purely declarative format that replaced HTML and it had some basic controls around data-binding, and infinite scroll, and whatever. At that point, it would cease to be a semantic presentation layer, it would be a document layout tool.

Of course, no system is perfect, there are some exceptions in HTML that blur that line, largely because the web is very messy and its hard to correct mistakes once they're out in the wild. And yes, Google is pushing templates and shadow-DOM, both of which are bad ideas that make the web worse. We can't win everything. But I will still strongly assert that HTML is not here to make you happy as a developer -- HTML is for the user. The point of HTML is that it forces you to describe your interface as semantic data, not pixels.

----

To extend off of that point, the other thing I'll go to my grave asserting is that once you start to think of HTML as a user-accessible presentation layer for what your state is right now, you start to realize that the distinction between web pages and applications is kind of garbage.

Most apps are just interactive documents, regardless of whether they're online or on native platforms. There are some exceptions (3D editing software, maps, etc...), but for the most part what I tell UX designers is that if they can't sit down and describe the current state of an application as an XML tree, they probably don't have a very good grasp of what that state is or how to organize it for the user.

I think I can count on one hand the number of apps I have installed on my desktop computer that couldn't be expressed in HTML. Even apps like Photoshop turn out to be XML documents with a few embedded canvases once you really think about them.

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

#80

Post by ultrarunner »

jasonhansel wrote: post #77

Really I just want browsers to have built-in support for running single-page apps. So you could go to a site and have it just send your browser a JS file, avoiding even needing to fetch and HTML file with a script tag.

Sounds a little too much like side loading to me, which means everyone with an app store is probably not terribly motivated to implement it.
Post reply on HN