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

61–70 of 94 posts

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

#61

Post by recursivedoubts »

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…

thank you for clarifying

i knew there was some drama betweeen the two organziations but didn't know the history

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

#62

Post by sergeykish »

bjoli wrote: post #41
fortran77 wrote: post #18

Remember XML/XSLT? You were supposed to write your webpage in pure XML -- this way the content was pure, and can be indexed, processed by other programs, etc. -- and then styled by XSL transformations. I spent a lot of time learning this. It never caught on. Browsers still support it. http://xml.silmaril.ie/browsers.html

I just style XML directly with CSS. That works fine if you just want to display it in a browser. XSLT can of course do a lot more complex transformations on your data.

Could you please share a bit more? I know I can style XML with , it can be handy to make RSS readable - http://feeds.bbci.co.uk/news/rss.xml

Anything else where it shines?

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

#63

Post by kodablah »

I had begun to spec out a strict subset of HTML[0] until I realized I had just recreated AMP. What we need is an AMP-like HTML subset w/out the custom tags and ads (same issue with htmx). Any such HTML "fork" should make it a goal to be easily implement a viewer/browser of said type which means instead of just adding things, things need to be removed too.

0 - https://github.com/cretz/narrow

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

#64

Post by zokier »

I think the crucial thing is that it could be a "soft fork", something that is fully interoperable with current browsers. The important thing is to foster a community of people who are willing accept a common ground. Think of Medium or tumblr etc, but with different angle. Sure, it won't be for everyone, but it doesn't need to be massively popular to be a success and to thrive. You could build interesting link aggregations and search engines around sites built with the "dogma" spec, which allows people more readily spend time on the sort of sites the like. Nobody thinks that you can't build low-fi sites already now, but connecting authors and readers is the tricky part.

Of course I have my own ideas how it could work, there could be an optional headers, one from browsers saying "I want light/fat version" and one from server indicating if it's lightweight so that browser can apply better default styling and disable features. I also think it makes sense to define different levels or profiles of features so that you don't need to try to get everyone to agree on everything, but that might be problematic.

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

#65

Post by hinkley »

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?

What people can do and what the will do have very little in common.

Without the cooperation of my coworkers, bosses, and third party suppliers, very little of what I do will stick, and I have to be clever or at least subtle for that to happen. Any broad-stroke things like 'Just use HTML'? You've got to be kidding.

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

#66

Post by bonestormii_ »

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…

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.

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

#67

Post by bjoli »

sergeykish wrote: post #52
bjoli wrote: post #33

I think there is a rather big divide between people like me who thinks the web should be "content-only" and people who see it as an application platform. Most of what I do on the web resolves around reading things, not interacting in any meaningful way. Most of the web tries it's best to ruin that experience. Most of what I do online would be better served by gopher. I understand I am a part of a minuscule minority,…

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 metadata attached.

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

#68

Post by bjoli »

sergeykish wrote: post #62
bjoli wrote: post #41

Earlier quoted context omitted.

I just style XML directly with CSS. That works fine if you just want to display it in a browser. XSLT can of course do a lot more complex transformations on your data.

Could you please share a bit more? I know I can style XML with , it can be handy to make RSS readable - http://feeds.bbci.co.uk/news/rss.xml Anything else where it shines?

You can make any document into a full blown web page. I remember looking at the source of a snappy yet functional web page recently. It was the raw XML output from their code comments with an XML front page. It was all just raw XML and CSS.

There is no "time until valid paint". Everything renders when it's done, which means you get a lag before things show up in screen where you otherwise already have things rendering.

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

#69

Post by miohtama »

protomyth wrote: post #49
miohtama wrote: post #36

Earlier quoted context omitted.

I worked with some of very first mobile web sites. It was WML and Nokia 7110. While it seems rosy now, it was not that pleasant to work with. Pushing out any meaningful user interaction was painful. It was similar to remote control menus on TVs. Plus it did not help that the entire device rebooted on a markup parsing errors and such bugs.

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.

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

#70

Post by sergeykish »

tannhaeuser wrote: post #21
jillesvangurp wrote: post #12

Earlier quoted context omitted.

If you step back a little what we have today is a combination of a common browser implementations (aka. the DOM tree + render logic) and bunch of standardized parsing and interpretation logic that maps textual versions of CSS and HTML to this. For better or for worse, this stuff is standardized via WhatWG & W3C as well as the three remaining browser engines (chromium, gecko, and safari) whose intersection of behavior…

> The business of rendering static text to a browser is kind of a solved problem. It's everything else that's kind of hard to deal with via a DOM api. WASM is breaking this discussion wide open as suddenly people are porting decades worth of native code to run in a browser. If it is so hard to layer a coherent and not laughably overcomplicated runtime on top of a document viewer in 20 years, then it follows that it p…

You are not in charge. If contenteditable is such a nuisance you can fix it, fill bugs and help with triage. I've been recently playing with it. There are so many bugs like noone use it. A lot of people want WASM and drive it. It is not zero sum game.

There already several tiers of the browsers. Top tier opens competition with native/mobile. This may be huge - Windows, Mac, *nix, iOS, Android - universal application without walled garden.

Next tier works with mostly static content - NetSurf and Dillo. Dillo is fast, no need to throw away web. Any open source browser has entire history - pull and compile. First Mozilla check in is before Gecko - Layout Classic [1].

It is not browsers who ruins experience but authors. I browse without JS, it works.

[1] https://github.com/sergeykish/gecko-dev/tree/init/lib/layout

Post reply on HN