12 ms·

Author here. I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". However, I don't see it that cle

Author here. I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". However, I don't see it that clearly that this cannot be done since the start so that the expectations are right since the beginning. For example, I don't see the same problem in other formats like JPEG or PNG where you expect the image to work perfectly or fail with a decoding error. Other than implementing it and see how it goes, can you propose a feasible experiment to see how an new strict spec will measurably fail?

htmlenjoyye 4mo ago
browsers will display invalid/corrupt images (best effort) tried it right now - took a PNG and a JPEG, opened them in a text editor, literally deleted the second half of the file, saved, and dragged them into both Firefox and Chrome - they are displayed instead of erroring out. there is a classic article why a minimal version of the web with features removed will fail - you removed 80% of the features that YOU think are not important. thats a classic fatal mistake search the web for different proposals for a minimal web and you will understand - they will have removed some feature they think is bloat but which you kept in your proposal because you consider it critical. which is why you created a new proposal - their minimal proposal is not the right one for you https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/ https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
- pibaker 4mo ago
  > they are displayed instead of erroring out. I think what is lost on many people, ironically even the ones who want to retvrn the web to its former glory, is that the browser tries to display broken, half transmitted content because it happened so frequently due to circumstances completely out of the website operator or the user's control. And in most cases showing a half transmitted web page with half of the closing tags missing is almost certainly better than just outright refusing to show anything.
  - lostmsu 4mo ago
    Couldn't that be a source for vulnerabilities?
    - ipaddr 4mo ago
      Missing closing tags in html no.
      - lostmsu 4mo ago
        I could imagine a page where cutting HTML would cause it be a yes (not exact JS). <script> setTimeout(10000, () => { safeEval(<some user input>); }); </script> <script> window.safeEval = code => eval(code); </script>   <script>  const notTooSafe = window.safeEval; window.safeEval = code => { if (code.any(c => !c.isDigit())) throw "unsafe"; return notTooSafe(code); }; </script>
        a_t48 4mo ago
        Parent poster was talking about the latter half of a page being missing, rather than a chunk out of the middle, I believe.
        lostmsu 4mo ago
        If the script blocks are in the end, how would browser know there's no "latter half of a page"?
        a_t48 4mo ago
        Aha, now I get it. That's a neat idea.
masklinn 4mo ago
> I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". That... is not how anything happened. > I don't see the same problem in other formats like JPEG or PNG where you expect the image to work perfectly or fail with a decoding error. Browsers absolutely decode as much as they can, and if the file is corrupted halfway through you generally get garbling, not the entire image being replaced by "fuck off". The only case where that is so is if the browser can't parse anything at all, or can't retrieve the file. > Other than implementing it and see how it goes, can you propose a feasible experiment to see how an new strict spec will measurably fail? We already did that and saw where it went.
- eduction 4mo ago
  > 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.
  - masklinn 4mo ago
    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.
    - tardedmeme 4mo ago
      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?
- rodarima 4mo ago
  > Browsers absolutely decode as much as they can, and if the file is corrupted halfway through you generally get garbling, not the entire image being replaced by "fuck off". The only case where that is so is if the browser can't parse anything at all, or can't retrieve the file. 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. Like this one: https://html.spec.whatwg.org/multipage/parsing.html#adoption-agency-algorithm https://html.spec.whatwg.org/multipage/parsing.html#adoption... Perhaps a better example is a C program being compiled into an executable. You don't expect the compiler to guess what you meant while parsing. The current expectation is that a web browser must load any broken HTML and still display what it can, and is this expectation what I would like to change. I don't propose humans to write this format directly (although it should be human readable), but compile it from something that is easy to write, like Markdown or a similar language. The objective is to enforce tools that make the transformation to produce a strictly conformant document. Having a context-free grammar allows simple and fast parsing tools that can process your document, in a similar way that you can query or manipulate a JSON file with tools like jq because the grammar is simple and strict.
khimaros 4mo ago
as a person who just wants to publish a simple blog and informational articles, i would happily use this subset if it were still compatible with popular browsers. i've been praying for an effort like this to organize and am grateful that you are taking a stab at it. i would use dillo as my main testing browser if it was the browser that honored the subset spec most accurately and guaranteed compatibility with Chrome and Firefox.

htmlenjoyye 4mo ago

browsers will display invalid/corrupt images (best effort) tried it right now - took a PNG and a JPEG, opened them in a text editor, literally deleted the second half of the file, saved, and dragged them into both Firefox and Chrome - they are displayed instead of erroring out. there is a classic article why a minimal version of the web with features removed will fail - you removed 80% of the features that YOU think are not important. thats a classic fatal mistake search the web for different proposals for a minimal web and you will understand - they will have removed some feature they think is bloat but which you kept in your proposal because you consider it critical. which is why you created a new proposal - their minimal proposal is not the right one for you https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/ https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

pibaker 4mo ago
> they are displayed instead of erroring out. I think what is lost on many people, ironically even the ones who want to retvrn the web to its former glory, is that the browser tries to display broken, half transmitted content because it happened so frequently due to circumstances completely out of the website operator or the user's control. And in most cases showing a half transmitted web page with half of the closing tags missing is almost certainly better than just outright refusing to show anything.
- lostmsu 4mo ago
  Couldn't that be a source for vulnerabilities?
  - ipaddr 4mo ago
    Missing closing tags in html no.
    - lostmsu 4mo ago
      I could imagine a page where cutting HTML would cause it be a yes (not exact JS). <script> setTimeout(10000, () => { safeEval(<some user input>); }); </script> <script> window.safeEval = code => eval(code); </script>   <script>  const notTooSafe = window.safeEval; window.safeEval = code => { if (code.any(c => !c.isDigit())) throw "unsafe"; return notTooSafe(code); }; </script>
      - a_t48 4mo ago
        Parent poster was talking about the latter half of a page being missing, rather than a chunk out of the middle, I believe.
        lostmsu 4mo ago
        If the script blocks are in the end, how would browser know there's no "latter half of a page"?
        a_t48 4mo ago
        Aha, now I get it. That's a neat idea.

masklinn 4mo ago

> I agree that you cannot go from HTML to XHTML because users and UA devs will always go towards "it mostly works". That... is not how anything happened. > I don't see the same problem in other formats like JPEG or PNG where you expect the image to work perfectly or fail with a decoding error. Browsers absolutely decode as much as they can, and if the file is corrupted halfway through you generally get garbling, not the entire image being replaced by "fuck off". The only case where that is so is if the browser can't parse anything at all, or can't retrieve the file. > Other than implementing it and see how it goes, can you propose a feasible experiment to see how an new strict spec will measurably fail? We already did that and saw where it went.

eduction 4mo ago
> 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.
- masklinn 4mo ago
  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.
  - tardedmeme 4mo ago
    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?
rodarima 4mo ago
> Browsers absolutely decode as much as they can, and if the file is corrupted halfway through you generally get garbling, not the entire image being replaced by "fuck off". The only case where that is so is if the browser can't parse anything at all, or can't retrieve the file. 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. Like this one: https://html.spec.whatwg.org/multipage/parsing.html#adoption-agency-algorithm https://html.spec.whatwg.org/multipage/parsing.html#adoption... Perhaps a better example is a C program being compiled into an executable. You don't expect the compiler to guess what you meant while parsing. The current expectation is that a web browser must load any broken HTML and still display what it can, and is this expectation what I would like to change. I don't propose humans to write this format directly (although it should be human readable), but compile it from something that is easy to write, like Markdown or a similar language. The objective is to enforce tools that make the transformation to produce a strictly conformant document. Having a context-free grammar allows simple and fast parsing tools that can process your document, in a similar way that you can query or manipulate a JSON file with tools like jq because the grammar is simple and strict.

khimaros 4mo ago

as a person who just wants to publish a simple blog and informational articles, i would happily use this subset if it were still compatible with popular browsers. i've been praying for an effort like this to organize and am grateful that you are taking a stab at it. i would use dillo as my main testing browser if it was the browser that honored the subset spec most accurately and guaranteed compatibility with Chrome and Firefox.