[HN Gopher] Smallest Possible Files
___________________________________________________________________
Smallest Possible Files
Author : yread
Score : 80 points
Date : 2025-05-27 11:57 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| RandallBrown wrote:
| There must be some interesting code golf stuff hidden in here,
| but it seems like it's mostly empty files.
| eru wrote:
| For eg the C examples, it depends a lot on which compiler you
| are using (and implicitly then also on which standard).
| JimDabell wrote:
| The linked blog post about the smallest possible valid (X)HTML
| documents is noteworthy, if only for the fact that a surprising
| amount of people adamantly refuse to believe that they are
| valid. Even when you think you have gotten through to them with
| specifications and validators, a lot of people will _still_
| think _"yeah, but it's relying on error handling though"_. I'm
| not sure why _"HTML explicitly permits this"_ will not be
| tolerated as a thought and somehow transforms into _"HTML
| doesn't permit this but browsers are lenient"_. It's a
| remarkably unshakeable position. And even the people who are
| eventually convinced that it's valid _still_ think that it is
| technically incorrect in some unspecified way.
| currysausage wrote:
| This is especially ironic, considering the same people will
| gladly use XML syntax and serve it as text/html.
| Historically, this has only worked because no relevant
| browser has ever implemented SGML (and NET [1], in
| particular), as required by HTML standards up to version 4
| [2].
|
| [1] https://en.wikipedia.org/wiki/Standard_Generalized_Markup
| _La...
|
| [2] https://www.w3.org/TR/html401/conform.html#h-4.2
| JimDabell wrote:
| That's not _quite_ the whole story. Appendix C of the XHTML
| 1.0 specification provides HTML compatibility guidelines:
|
| > This appendix summarizes design guidelines for authors
| who wish their XHTML documents to render on existing HTML
| user agents.
|
| -- https://www.w3.org/TR/xhtml1/#guidelines
|
| And RFC 2854, which defines the text/html media type,
| explicitly states this is permissible to label as
| text/html:
|
| > The text/html media type is now defined by W3C
| Recommendations; the latest published version is [HTML401].
| In addition, [XHTML1] defines a profile of use of XHTML
| which is compatible with HTML 4.01 and which may also be
| labeled as text/html.
|
| -- https://datatracker.ietf.org/doc/html/rfc2854#section-2
|
| However even browsers that support XHTML rendering use
| their HTML parser for XHTML 1.0 documents served as
| text/html, even though they should really be parsing them
| as XHTML 1.0.
|
| But yes, that extra slash means something entirely
| different to the SGML formulation of HTML (HTML 2.0 to HTML
| 4.01). HTML5 ditched SGML though, so SHORTTAG NET is no
| longer a thing.
| currysausage wrote:
| I believe the sentence from the RFC:
|
| _[XHTML1] defines a profile of use of XHTML which is
| compatible with HTML 4.01_
|
| is technically incorrect. While the XHTML 1 compatibility
| profile was compatible with HTML 4 _as implemented by
| major browsers_ , that wasn't actually HTML 4. HTML 4 is
| based on SGML, while what was implemented was a
| combination of HTML 4 semantics with the tagsoup parsing
| rules that browsers organically developed. These rules
| were only later formalized as part of HTML 5.
|
| The compatibility guidelines do recommend a space between
| <br and />, but (at least according to
| https://validator.w3.org/ in HTML 4 mode) this doesn't
| change anything about <br /> being a NET-enabling start-
| tag <br /, followed by a greather-than sign.
|
| Enter this: <h1>Hello<br />world</h1>
|
| and select "Validate HTML fragment", "HTML 4.01", and
| "Show Outline". This is the result: [H1]
| Hello>world
|
| (Obviously nitpicking, but that's my point: the
| nitpickers can be out-nitpicked.)
| myfonj wrote:
| > Historically, [...] no relevant browser has ever
| implemented SGML [...] NET
|
| I can probably confirm that "relevant" part of this claim
| for the times spanning from the first decade of 2000s, but
| I still desperately (in a way) seek information whether
| _ANY_ even niche and obscure application that consumed
| "HTML" treated the NET as specified back then. I am quite
| certain W3C Validator did (that Mathias' article proves
| that, after all) and that Amaya might have do that, since
| it was a reference implementation from the same spec body,
| IIRC, but cannot swear on that.
|
| Have anybody here have a clearer recollection of that
| times, or even some evidence?
|
| I still find it strange such feature had such prominent
| space in the specs back then, but practically nowhere else.
| JimDabell wrote:
| EMACS/W3 originally supported SHORTTAG NET but was
| "fixed" to remove support. In practical terms, mainstream
| browsers couldn't afford to parse SHORTTAG NET properly
| because it was very common to leave attribute values
| unquoted. You can leave _some_ values unquoted, but not
| ones with slashes in. So the very common error <a
| href=http://xn--rvg would not get parsed as the author
| expected if SHORTTAG NET was enabled.
|
| This is the earliest reference I could locate easily,
| from the www-html mailing list:
|
| https://lists.w3.org/Archives/Public/www-
| html/2002Nov/0057.h...
|
| You'll be able to find more if you go trawling through
| USENET archives of places like
| comp.infosystems.www.authoring.html from 25-30 years ago,
| but it was a fairly niche subject even back then.
|
| I think there were a couple of other niche tools that
| supported it, but I don't remember the details after all
| this time.
| JimDabell wrote:
| I believe this is the exact change where support for
| SHORTTAG NET was removed from EMACS/W3 in order to
| support XHTML better:
|
| https://github.com/emacsmirror/w3/commit/68af7c107dcbe194
| e30...
| myfonj wrote:
| Thanks! That's actually really valuable insight and seems
| to be a promising start for a interesting investigation
|
| I'd even say that from a glance, EMACS ("W3" browser in
| it) seems like possibly hugely relevant application,
| actually. Will look into it.
| JimDabell wrote:
| If you really want to, you could check out Evolt's
| browser archive:
|
| https://browsers.evolt.org
|
| It's got over a hundred ancient web browsers. I suspect
| none of them support SHORTTAG NET though.
| myfonj wrote:
| Good idea. I remember I have done some research about
| this in the past when I tried to trace historical
| arguments for the infamous "should there be a space
| before slash in void tags for the best compatibility"
| <br/> vs <br /> (vs <br>)
|
| discussion, but didn't get much far then
| (https://stackoverflow.com/a/30880386/540955).
| jerf wrote:
| "if only for the fact that a surprising amount of people
| adamantly refuse to believe that they are valid... And even
| the people who are eventually convinced that it's valid still
| think that it is technically incorrect in some unspecified
| way."
|
| Speaking from my personal experience, if your idea of "valid
| HTML" was created in the late 1990s or early 2000s, it's
| worth a spin through the current HTML standard. HTML has
| always _de facto_ been permissive, but _de jure_ it had
| certain requirements. However, HTML 5 essentially works by
| reifying a very, very well-specified algorithm for how to
| handle HTML "loosely" (even though it is very strictly
| specified), and then refactors away effectively every
| requirement it possibly can and defers them to that algorithm
| instead.
|
| Technically speaking, as long as you put down the correct
| doctype, you can elide almost anything nowadays and get a
| functional document; for instance, "<!DOCTYPE
| html><title>Hello</title>" is fully standards compliant now
| (push it through [1]). Only thing the validator gives is a
| warning that you might like to specify a language in the
| doctype. It isn't just "browsers will pretty much do the
| 'right thing'" with that, which has been true for a long
| time... that's actually standards-compliant HTML now.
|
| What a lot of old hands don't understand is that HTML 5 was a
| seismic shift in how HTML is specified. Instead of specifying
| a rigid language and then pretending the world is complying
| and it's super naughty of them not to, it defines a standard
| for extracting a DOM tree from effectively any soup of
| characters you can throw at it, compliance is loosened as
| much as is practical, and even when things don't comply
| there's a specification on exactly how to pick up the pieces.
| HTML 5 has a completely different philosophy than HTML 4 and
| before.
|
| (Relatedly, the answer to the frequently-asked question "What
| is the BeautifulSoup equivalent for $LANGUAGE", at least as
| far as parsing, is effectively now "Find an HTML 5-compliant
| parser", which they all have now. Beautiful Soup's parsing
| philosophy was enshrined into the standard.)
|
| [1]: https://validator.w3.org/nu/#textarea
| arexxbifs wrote:
| The Python, Perl, Lua, etc. files are arguably valid quines.
| ayaros wrote:
| Reminds me of
| https://github.com/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee/eeeeeeee...
| rollcat wrote:
| Kinda. Empty files for so many languages, it would be
| interesting to see at least an exit(0) or so.
| DaSHacka wrote:
| I love how even though the entire repo is essentially a
| shitpost, it still uses a CoC.
|
| You know, to ensure cordiality in any of the various riveting
| PRs and discussions.
| vitorfrois wrote:
| yes what about the biggest possible files
| jerf wrote:
| Many of them are infinite, so you'd have to provide them as
| functions rather than files. There's obvious ones like plain
| text, but some less obvious ones, like, PNGs are defined as a
| series of chunks, but there's no chunk count in the header,
| so you can keep appending chunks forever:
| https://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
|
| This sort of thing is not just a funny question, it's
| something you think about when you're writing scanners. For
| instance, another "biggest possible file" is the zip file
| that decompresses to itself[1], which is in some sense also
| an infinite file. Many a scanner has been written that will
| fill the disk then crash if presented with that file, which
| is actually more pathological behavior than would be
| experienced if the scanner isn't there.
|
| [1]: https://research.swtch.com/zip
| adzm wrote:
| I really appreciate the .gitignore file there
| https://github.com/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee/eeeeeeee...
| arexxbifs wrote:
| The 42 byte transparent GIF saw ample use in web development a
| quarter century ago, when it was used to create pixel perfect
| <table> layouts. Some things have changed for the better.
|
| https://x42.com/test/gifdot.shtml?abcdef
| JimDabell wrote:
| The smallest GIF is still useful because it is the smallest
| possible valid favicon. This means you can stuff it into a
| data: URI to prevent useless requests showing up when you are
| working on something: <link rel="icon"
| href="data:image/gif;base64,R0lGODlhAQABAAAAADs=">
| vbezhenar wrote:
| You can also make an actually useful and readable SVG favicon
| this way: <link rel="shortcut
| icon" href='data:image/svg+xml,%3csvg
| xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100
| 100">%3ccircle cx="25" cy="50" r="20"/>%3ccircle cx="75"
| cy="50" r="20"/>%3c/svg>' />
| JimDabell wrote:
| Good to know! My goal is simply to stop a 404 popping up
| during development in the simplest way possible, so the
| smallest amount of code is best for me.
| zamadatix wrote:
| If you're just wanting to shut the request up and aren't
| actually trying to display a certain favicon you can do:
| <link rel=icon href=data:>
|
| With the bonus you've probably already remembered how to
| reconstruct this on demand just by reading this comment. It
| is "invalid" data but so is your example on Safari and
| Firefox instead of Chromium based browsers. It doesn't matter
| as much because that problem is local and silent in the logs,
| unlike the request.
| JimDabell wrote:
| Thanks! I'm pretty sure I tried this ages ago and it didn't
| work at the time, but I tried this again now and it does
| the job.
| zamadatix wrote:
| The key is to keep up through "data:" since any shorter
| (even just dropping the ":") and it gets treated a
| relative link instead.
| gudzpoz wrote:
| A use case: https://news.ycombinator.com/s.gif (43 bytes) (use
| for comment indentation)
| rollcat wrote:
| It's kinda cool than HN looks OK even in simple browsers like
| Dillo:
|
| <https://imgur.com/a/Seu8rYT>
|
| However it's pretty bad on narrow screens. I wish there was
| some progressive enhancement via modern CSS, or at least just
| dark mode.
| user32489318 wrote:
| Reminded me of a major "data"/"AI" platform that stripped all
| empty files when deploying the code. Because of "security" you
| were not allowed to list files on the deployed instance, nor
| review the deployment pipeline code or logs ("it just a
| works/batteries included").
|
| The most brilliant way to screw all Python developers I've ever
| seen.
|
| Later learnt that the docker container run the code as root, so
| basically you could destroy the platform from within. Good times.
| Wowfunhappy wrote:
| ...I feel like completely empty files shouldn't be allowed. Like,
| I realize the Python interpreter won't error if you feed it an
| empty file, but how can you really say that empty file represents
| a Python script if there is no script there?
|
| However, I can't put my finger on what the correct rule would be.
| ks2048 wrote:
| I guess if you can run `python myfile.py` and it finishes with
| without error (return code 0), you could consider it valid.
|
| By that measure, there are also 1 byte valid Python programs
| (e.g. "1").
| nivertech wrote:
| File size of -[?] is the smallest
| jotux wrote:
| Not if the file size is -[?] - 1.
| LegionMammal978 wrote:
| Some of these files are very much nonstandard, even when the
| standard leaves no leeway (unlike HTML). E.g., every PDF standard
| requires an %%EOF, startxref offset, and an xref table (or an
| xref stream in the later versions), but this PDF file is missing
| those, among other oddities, like the page object missing a /Type
| and /MediaBox. Too bad the author doesn't specify which
| implementation these are supposed to work in.
| ks2048 wrote:
| Pretty cool. But as everyone is pointing out, empty files aren't
| that interesting. 31/137. $ find . -name ".git"
| -prune -o -name "README.md" -prune -o -type f -print | wc -l
| 137 $ find . -name ".git" -prune -o -name "README.md"
| -prune -o -type f -empty -print | wc -l 31
|
| I suppose if you wanted minimal, non-empty examples, you'd end up
| with a "hello, world" collection, of which there are many, but
| nice that this handles file formats as well as programming
| languages.
| aidenn0 wrote:
| The traditional minimal bourne-like shell script has a single
| ":" in it. This is because, when looking at an executable[1],
| bourne-alikes may try to detect if the file is binary to
| prevent executing a binary file. I don't know for a fact that
| some sh implementations will refuse to execute an empty file,
| but it seems likely.
|
| 1: If you try to run a program binary from a bourne-like shell
| and execl() signals ENOEXEC, then (if it believes it to be a
| text file) it will try to run it as a shell script; this makes
| shebangs optional for programs executed only from a shell. You
| can try it yourself (tested on bash, dash, ksh, fish, zsh, and
| osh): $ echo 'echo hi' > foo.sh $ chmod
| +x foo.sh $ ./foo.sh
| chasing wrote:
| Okay, but what about the largest possible files?
| dmd wrote:
| For people who enjoy this sort of thing, vaguely related is this
| puzzle: https://dmd.3e.org/a-shell-puzzle/
___________________________________________________________________
(page generated 2025-05-30 23:01 UTC)