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

Forking the Web

dillo-browser.org

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Forking the Web

#101

Post by tardedmeme »

stavros wrote: post #49
singpolyma3 wrote: post #30

Earlier quoted context omitted.

To be fair, HTML5 also has a defined parsing algorithm. It just happens to always work on any input to produce a webpage

I think the GP has an issue not with the specification part, but with the part where it's forbidden for clients to render a noncompliant page.

It's not forbidden. They just don't render certain noncompliant pages. Namely the ones with gross syntax errors.

Why are we okay with formats like PDF that have similarly catastrophic error handling?

Re: Forking the Web

#102

Post by tardedmeme »

masklinn wrote: post #81
eduction wrote: post #73

Earlier quoted context omitted.

> That... is not how anything happened. What the heck are you talking about? User agent devs and users did indeed always go toward it mostly works.

People didn't go towards "it mostly works", people go towards "it works at all". A lot of people tried to use xhtml, and it didn't work, broken content was pervasive and the experience when facing broken content was irredeemable.

What was the exact nature of how devs found themselves unable to emit valid XML in all scenarios? What kind of bugs did they run into?

Re: Forking the Web

#103

Post by stavros »

tardedmeme wrote: post #101
stavros wrote: post #49

Earlier quoted context omitted.

I think the GP has an issue not with the specification part, but with the part where it's forbidden for clients to render a noncompliant page.

It's not forbidden. They just don't render certain noncompliant pages. Namely the ones with gross syntax errors. Why are we okay with formats like PDF that have similarly catastrophic error handling?

I mean, the linked page and the comment above say it is:

> It is explicitly forbidden for clients to accept any page that doesn't conform with the specification. This prevents the standardized diabolic rules that one must implement in order to correct a

Re: Forking the Web

#104

Post by zbentley »

tardedmeme wrote: post #101
stavros wrote: post #49

Earlier quoted context omitted.

I think the GP has an issue not with the specification part, but with the part where it's forbidden for clients to render a noncompliant page.

It's not forbidden. They just don't render certain noncompliant pages. Namely the ones with gross syntax errors. Why are we okay with formats like PDF that have similarly catastrophic error handling?

I mean, we aren’t ok with that for PDF. That’s why PDF renderers have incredibly baroque rules for parsing weirdly or brokenly formatted documents, and why many PDF documents fall back to embedding images or absolute-positioned pixel-like layouts for compatibility purposes.

Re: Forking the Web

#105

Post by vanviegen »

andsoitis wrote: post #47
vanviegen wrote: post #27

Earlier quoted context omitted.

I think XHTML failed because it didn't give web devs any new capabilities, so most didn't feel the need to learn it and do the extra work of getting their tags correct. Then html5 came along, providing all kinds of shiny goodies and saying not to bother with the tags. In the end, a more rigid standard would have been nice.. (Though this is mostly about the skin deep part of the standards.)

> I think XHTML failed because it didn't give web devs any new capabilities, and what new capabilities does this new proposal provide?

None, as far as I can tell.

Re: Forking the Web

#106

Post by anthk »

rodarima wrote: post #98
masklinn wrote: post #87

Earlier quoted context omitted.

> What I meant is that you don't expect PNG or JPEG images to be created in a way that the parser needs to run a complex process to reconstruct the bits that are broken and interpret what you meant to say. So what you meant is neither what you wrote, nor what you advocate for? because in case you have forgotten here is what you advocate for: > Pages that don't conform with the specification won't be rendered. That is…

> Pages that don't conform with the specification won't be rendered. I agree on what I wrote here. They will fail with an error indicating where the mistake is so you can correct it (more likely the tool that produced it). >> The objective is to enforce tools that make the transformation to produce a strictly conformant document. > >Ah, an open and non-monopolizable format which can only be written via an official to…

Instead of C, maybe, Lisp, or Forth without messing the stack.

Re: Forking the Web

#107

Post by Yokohiii »

doublerabbit wrote: post #97
Yokohiii wrote: post #29

I am generally interested in approaches to cut down complexities of fundamental web technologies. Creating a browser from scratch shouldn't be impossible or a trillion dollar experiment. But... > No scripting How is will it be possible to go back? The average ecom presence usually relies heavily on JS. I haven't checked in a long time that any relevant sites work without JS. I think going back to more basic approache…

JavaScript isn't inheritedly bad. It's won that reputation because of bloat. No one codes standard vanilla any more so it's always a framework and the existing are failures. It's shocking how 2mb of JavaScript could be done in 2kb and that JavaScript was never designed to conceive.

It's interesting that you say that JS isn't inherently bad, but everyone uses TS. Is there something bad about vanilla?

Either way, my problem isn't generally JS as is, but that it is the only language, the only platform that drives everything. Maybe web assembly can change that, it's not really a fast progress. But that is kind of the problem, replacing JS or introducing alternatives is extremely hard.

Re: Forking the Web

#108

Post by cindyllm »

PaulHoule wrote: post #19
TFNA wrote: post #13

Earlier quoted context omitted.

XHTML failed in an era when writers (even normies) were writing some HTML of their own and they could't be trusted to close their tags properly. XHTML also assumed writers would be personally invested in semantic markup like distinguishing e.g. the italics of book titles from the italics of emphasis. Today, when writers are using visual editors (or Markdown), few are writing their own HTML any more. A web standard re…

Markdown sux and so do visual editors. I think visual editors were just invented to make it so cut-and-paste never quite works right. There's been some conceptual problem with the whole idea ever since MS Word and the industry has never dealt with it.

[dead]

Re: Forking the Web

#109

Post by culi »

fooqux wrote: post #20
TazeTSchnitzel wrote: post #9

> The specification must contain a non-ambiguous formal grammar that can be parsed easily. A page can then be tested against the standard and reject or accept as compliant. Pages that don't conform with the specification won't be rendered. It is explicitly forbidden for clients to accept any page that doesn't conform with the specification. This is what XHTML was, and it was a complete disaster. There's a reason almo…

Agreed. There may be some situations where I may want to ensure 100% correctness. I'm thinking life or death scenarios, (which if so, maybe should use a different protocol). However, checking the sports score or looking at cat memes isn't that.

When you visit an HTTP site, browsers give you a warning screen alongside an option to "open anyways".

We could do the same with sites that are not 100% correct. User are already used to having to click "Open anyways" for older, non HTTPS, sites anyways

Re: Forking the Web

#110

Post by Bratmon »

culi wrote: post #109
fooqux wrote: post #20

Earlier quoted context omitted.

Agreed. There may be some situations where I may want to ensure 100% correctness. I'm thinking life or death scenarios, (which if so, maybe should use a different protocol). However, checking the sports score or looking at cat memes isn't that.

When you visit an HTTP site, browsers give you a warning screen alongside an option to "open anyways". We could do the same with sites that are not 100% correct. User are already used to having to click "Open anyways" for older, non HTTPS, sites anyways

Browsers briefly tried that in the early 00s. It turns out that, from a user perspective, that's an incredibly stupid question- the user has no way of knowing how well the page works until they click "yes"!
Post reply on HN