> Specs like JSON-LD are included but do not meaningfully change the numbers.
JSON-LD was a simple example that I just used b.c. it was on the front page. That JSON-LD doesn't meaningfully change the numbers doesn't change the fact that the catalogue is a dump of things related to the web, which is probably different from each spec (POSIX, C, C++, etc...) which has a narrow scope. For example, the link dump has 104 links that mentions CSS in the slug: it probably makes sense to make a comprehensive CSS spec (which would probably reduce the size since it will remove a lot of repetitive parts), but the web standards don't work like that.
> This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard?
That's based on some @chubot's oilshell blog posts[0][1][2][3] about shell.
Excerpts from blog post:
> POSIX Uses Brute Force: In theoretical terms, a language is described by a grammar, and a grammar accepts or rejects strings of infinite length. But POSIX apparently specifies no such thing. Only the "unspecified" cases are allowed to use a grammar!
> Over the last few years of implementing shell, I've found many times that a careful reading of the POSIX spec isn't sufficient.
> The POSIX shell spec says that shell arithmetic is C arithmetic, So it's natural to wonder what the creators of C used. They didn't use grammars to specify their language. The code came first and grammars came later.
> Discovery: all shells are highly POSIX compliant, for the areas of the language that POSIX specifies. But POSIX only covers a small portion of say dash, let alone bash.
There are probably much more posts about this, but I think this is sufficient enough to explain that POSIX is underspecified.
> Can you make a website with confidence which works on all browsers?
I can make a website that reasonably works well on all browsers with confidence.
At least on the level where one can develop a full SPA based on one browser and then try & test it on others.
Most browser-specific issues don't exist and when they do, it's usually a one-liner.
> When was the last time you found a browser-specific issue? Mine was three days ago.
That's interesting, what was it? (Genuinely interested in that one.)
In my experience, it doesn't surface that much unless you're trying to use WASM or some new/non-standard APIs.
As someone who has also worked on implementing a POSIX shell, and read and implemented large swaths of POSIX besides, in my experience the main thing it lacks in is edge cases. These would normally be corrected with as much as one sentence, and by my intuition I would expect no more than 100,000 additional words would be necessary to fully specify these edge cases. It doesn't meaningfully move the dial on any of these numbers.
>I can make a website that reasonably works well on all browsers with confidence. At least on the level where one can develop a full SPA based on one browser and then try & test it on others. Most browser-specific issues don't exist and when they do, it's usually a one-liner.
On Chrome and Firefox, maybe. How about IE or Safari? How about Netsurf or Lynx or w3m? SourceHut (of which I am the founder and lead developer) works in all of those browsers, by the way.
>That's interesting, what was it?
Believe it or not, it was in how they interpreted margins. This was the fix:
todo.sr.ht rendered differently on Firefox and Chrome before this change. I didn't dig into it enough to make any bug reports, so connecting the dots is up to you if you're interested.
I hit another browser bug a while ago because Chrome arbitrary decided that the maximum number of elements in a CSS grid is 1,000.
> These would normally be corrected with as much as one sentence, and by my intuition I would expect no more than 100,000 additional words would be necessary to fully specify these edge cases. It doesn't meaningfully move the dial on any of these numbers.
I expect it would take much more than that to specify exactly what bash, dash and a lot of other shells should do in a cross-platform manner, consolidate the language to one, and allow backwards compatibility (just like where the web APIs are based on the consolidation efforts of IE, Netscape, and a bunch of other browsers in the 90s)
> On Chrome and Firefox, maybe. How about IE or Safari? How about Netsurf or Lynx or w3m? SourceHut (of which I am the founder and lead developer) works in all of those browsers, by the way.
Chrome, Firefox, and Safari are pretty easy to target all at once, as they have the usual modern features.
Considering Lynx, Netsurf, or w3m as modern web browsers invalidate your points, since I'm pretty sure they don't implement a lot of the standards, does w3m implement flex box/CSS grid for example?
I can't say this in confidence, but I think it won't be that hard to (not that it's easy) implement a web browser with a complexity of w3m.
> Believe it or not, it was in how they interpreted margins. This was the fix:
Hmm, my intuition feels like that's a SCSS-compiling problem where they mixed up the rules... but if they weren't, that would definitely be at least one browser bug.
JSON-LD was a simple example that I just used b.c. it was on the front page. That JSON-LD doesn't meaningfully change the numbers doesn't change the fact that the catalogue is a dump of things related to the web, which is probably different from each spec (POSIX, C, C++, etc...) which has a narrow scope. For example, the link dump has 104 links that mentions CSS in the slug: it probably makes sense to make a comprehensive CSS spec (which would probably reduce the size since it will remove a lot of repetitive parts), but the web standards don't work like that.
> This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard?
That's based on some @chubot's oilshell blog posts[0][1][2][3] about shell. Excerpts from blog post:
> POSIX Uses Brute Force: In theoretical terms, a language is described by a grammar, and a grammar accepts or rejects strings of infinite length. But POSIX apparently specifies no such thing. Only the "unspecified" cases are allowed to use a grammar!
> Over the last few years of implementing shell, I've found many times that a careful reading of the POSIX spec isn't sufficient.
> The POSIX shell spec says that shell arithmetic is C arithmetic, So it's natural to wonder what the creators of C used. They didn't use grammars to specify their language. The code came first and grammars came later.
> Discovery: all shells are highly POSIX compliant, for the areas of the language that POSIX specifies. But POSIX only covers a small portion of say dash, let alone bash.
There are probably much more posts about this, but I think this is sufficient enough to explain that POSIX is underspecified.
> Can you make a website with confidence which works on all browsers?
I can make a website that reasonably works well on all browsers with confidence. At least on the level where one can develop a full SPA based on one browser and then try & test it on others. Most browser-specific issues don't exist and when they do, it's usually a one-liner.
> When was the last time you found a browser-specific issue? Mine was three days ago.
That's interesting, what was it? (Genuinely interested in that one.) In my experience, it doesn't surface that much unless you're trying to use WASM or some new/non-standard APIs.
[0] https://www.oilshell.org/blog/2017/08/31.html#posix-uses-bru...
[1] https://www.oilshell.org/blog/2020/01/alias-and-prompt.html#...
[2] https://www.oilshell.org/blog/2017/04/22.html
[3] https://www.oilshell.org/blog/2019/01/18.html#criteria-for-t...