Hacker News new | past | comments | ask | show | jobs | submit login
This page is a truly naked, brutalist HTML quine (secretgeek.github.io)
952 points by Symmetry 11 months ago | hide | past | favorite | 179 comments

In a similar fashion of transforming the mechanics of code as art, this reminds me of code poetry.

Here is my favorite, Capsized by Zak Kain for Stanford's Code Poetry Slam:

    .ocean {
        color: cornflowerblue;
        pitch: high;
        overflow: visible;

    .boat {
        color: firebrick;
        transform: rotate(94deg);
        float: none;

    .rescue-team {
        visibility: visible;

    .crew {
        widows: none;

This one is pretty impressive. I get so many adds for dumb programming t-shirts that say stuff like "if (me.tired) drink.coffee()" which aren't very creative.

Nothing beats this one IMO: https://aem1k.com/world/

This guy is amazing: https://aem1k.com/

I wonder how some people are truly exceptional. Not exactly in the same league of hard sciences like Einstein, etc. But an adjacent track in programming. This is not the 10x vs 1000x type of stuff, but original creative thought executed elegantly.

Holy fuck!! I've never seen that one.......

This one is mesmerizing. https://aem1k.com/0/

Lol now that is weird! Wow... here's the source code he obfuscated. Very clever


It's the game of life, isn't it?


It’s not a quine though

For anyone else who doesn’t know what a quine is:

> A quine is a computer program which takes no input and produces a copy of its own source code as its only output.

Actually(tm), an older definition of a quine can be found here: https://www.scotsman.com/whats-on/arts-and-entertainment/fou...

So a parthenogenic Scotswoman would be a double quine.

An HTML file is not a program.

Of course it is, it is a collection of instructions that can be executed by a computer to perform a specific task. In this case the task is to display some data on a screen in a specific way. We need to stop arguing that HTML is not a programming language, it's silly and serves no purpose.

In most non-technical discussions like this, it's only serving the purpose of gatekeeping, as if people who work with HTML or CSS are not really programmers. That's nonsense and should be rejected.

I do think that, in specific technical contexts, a useful distinction (though still fuzzy on the margins) can be made between programming languages and markup languages.

> In most non-technical discussions like this, it's only serving the purpose of gatekeeping, as if people who work with HTML or CSS are not really programmers. That's nonsense and should be rejected.

that is my real point

Of all the things you can say about an HTML file, the one thing you can absolutely not say is that it is a collection of instructions. It is literally a declarative description of components to be rendered.

I also did not say HTML is not a programming language.

> declarative description of components to be rendered.

Doesn't the "to be rendered" part make it instructions? Its like there are two labels for a bottle of poison: "poison" and "poison: do not drink". But the label that says "poison" is of a shape, color, and design that is commonly understood to be a label that tells the reader not to imbibe the contents of the bottle to which it is attached.

If HTML is a programming language, then what, pray tell, are the artifacts in which that language is caused to produce output called?

It's not programming language because it's a markup langauge.

It's not turing complete. There are limits to the types of computation that can be performed with it.

It's not silly -- it's a meaningful distinction.

If you define a "program" as "a series of instructions to perform a task, where the instruction set is Turing Complete", then your statement is tautologically correct based on your definition. A much more general definition is simply "a series of instructions to perform a task". Do you feel that the former definition of the word "program" is the only one worth using?

As an example: if you use a Game Maker application to construct a video game where your inputs are the graphics, the level design, and some basic scripting to connect them up, is the resulting output "not a program" because the input scheme that you used in order to define its behavior was not Turing Complete? You could make an argument that, in the context of Quines, this isn't relevant because the Program is not outputting its own source code but only the top-most layer of its definition, but then again that's true at some level for any Quine not written in machine code (and even then it'd probably be missing much of the OS / display drivers / etc.).

Edit: removed an example about "programmable TV remotes" because it wasn't a very good example, and added a note about Quines.

>"a series of instructions to perform a task"

Limitations of those instructions is the key aspect. You couldn't use any English or natural language expression for example. It might seem obvious but complexity of those instructions is what makes the language abstract. Having complicated instructions isn't always desireable though e.g. the CISC vs RISC debate.

To be clear, I am in complete agreement with every point you've made explicitly in this thread. What I do not agree with is the following implicit claim:

An HTML file cannot be a Quine because an HTML file is not a program because HTML is not Turing Complete.

An html file doesn't contain just html.

If programming languages need to be turing complete, do you consider this language a programming language?


Also, you can generate RSA key pairs using HTML: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...

IMHO, the better mental model is that HTML is a declarative programming language that is very abstract.

HTML has sections for data and code just like most other executable files. The code parts in an HTML file are typically in <script> sections.

Why do you think it supports <script> tags? To allow you to extend the functionality where HTML is clearly limited.

Adding two numbers in HTML might be expressable but clearly it's much easier in Javascript.

Lots of historians consider programmable looms to be the first computers, even though they're not Turing-complete.

Cellular automation is Turing-complete, but is not a program.

Turing-complete is a fun thing to talk about in college theory classes, but has limited practical use outside of academia.

It's only real use outside of academia is getting investors on board with your cryptocurrency

And—apparently—gatekeeping what is a "real" programming language.

At some level probably a meaningful distention, like you wouldn't decide to create a neural network in HTML alone. But from a high level HTML is a language used in programming, generally with other languages to create distributed multi-platform computer programs.

My point is let's stop being so pedantic in the soft spaces. This isn't a discussion about "should I use HTML to write my kernel?"

Markup language is a useful category, but the dividing line isn't "Turing complete". Some traditional markup languages are Turing complete (certainly postscript, possibly troff?), while some interesting academic programming languages carefully avoid being so (eg. Charity).

While certainly the class of Turing-complete languages is an important one, I think it's a mistake to treat that specific class as the definition of “programming language”.

Is JSON a programming language then?

In my opinion: JSON is not a programming language when it's used as a data transport format; however, it can represent code which an interpreter could evaluate as a program.

For example, a Lisp based on JSON:


A program:

  ["+", 2, 3]
I suppose this is still not a proof that JSON is (or can be) a programming language, since it covers only the notation.

If that's the definition, then plain text is also a program. It instructs your text editor what to display on the screen.

Isn't that how most interpreted languages work?

it the text contains a program then it could be

This is HTML+CSS. CSS3 is Turing Complete.

why not? a html file is a set of instructions for the browsers render engine. That is enough for it to qualify as a program

does every program needs to be turing complete?

Not really, since programmable machines predate real-world turing-complete computers by at least a century.


Only if you define programs as instructions for manipulating Turing machines.

To be pedantic, we can define a non-Turing-complete subset of a Turing machine's instruction set, and pass combinations of these instructions to the machine, and that could still be called a program.

Why not?

It can receive input and create output. The browser is the interpreter for scripted HTML programs.

HTML by itself can't receive input or create output. It is input/output. It can't run or be executed. It doesn't transform state or even have state. It's not Turing complete.

HTML with either CSS3 or JavaScript is definitely a program, though.

> HTML by itself can't receive input or create output.

Neither can an ELF binary. It needs a loader to execute it.

> It can't run or be executed.

Yes it can, with a runtime that understands HTML.

> It doesn't transform state or even have state. It's not Turing complete.

That's not a requirement for a program.

So what is your definition of a program? It sounds like you're using a definition that's so broad, it would include image files, MP3s, and .gitignore.

You can write an entire game like super mario in an html file. Is a super mario game not a program? And no, this is not an archaic way to use html files, it is pretty common to share smaller games as html files. You play them by loading them into your browser.

Remember that html files are not just html. The way we use them today they are fully functional programs.

You are arguing against a statement I didn't make. Look back at the last sentence of my original comment[1] where I distinguished HTML from HTML+CSS3+JS.

It seems we agree that HTML (a language, not a file that also includes other languages) cannot create a game like Mario or even Pong.

1. https://news.ycombinator.com/item?id=24826670

"HTML by itself can't receive input or create output."

So GET and POST are figments of my imagination then?

Those are HTTP I believe.

Http verbs which can be sent from html

Except that you can "run" (display) an HTML document without ever sending any HTTP requests. The HTML has no power to send one. It just tells you what happens if a user clicks a UI element.

Saying that HTML can send HTTP messages is like saying that HATEOAS API responses[1] can send HTTP messages. They can't without a separate program (written in a non-HTML language) to interpret the HTML and send the message.

1. https://restfulapi.net/hateoas/

> HTML with either CSS3 or JavaScript is definitely a program, though

Then so is something in HTML that doesn’t use CSS3 or JavaScript, for the same reason that a C program that contains no loops is still a program.

> for the same reason that a C program that contains no loops is still a program

HTML is not "C without loops". It is, by definition, a subset of the string type. All HTML is a string, but not all strings are HTML.

The following is valid C, but I would absolutely argue that it isn't a program:

    char str[] = "Geeks";
It's a declaration, just like HTML is. It is a string that is being declared and stored.

Still, that C example is more of a program than any HTML is because it contains an instruction. It manipulates memory.

HTML is literally just a file format. It is not any more of a program than a PNG file is.

On a similar topic related to the display CSS property, you can attach a CSS to any XML document and have it displayed in a web-browser.

  <?xml-stylesheet type="text/css" href="style.css"?>
Bonus points if you mix that with XSLT.

A site I worked in more than a decade ago now had all the HTML generated by applying XSLT to the API output.

An argument determined if you wanted the page as XML, html or RSS. If you opted for XML, and your browser supported XSL, the XSL would be applied client-side. We still applied the XSL server-side by default to avoid having to deal with compatibility issues for the XSL, but it worked perfectly in most browsers and was great for testing.

XSLT was/is a massive pain, though.

I store my resume in XML and use XSLT to generate an html version and Python to generate a plain text version. I made it about 10 years ago after I learned XSLT for a project at work. I feel secure in knowing that the XSLT code I wrote will never become obsolete, as compared to the Python script I wrote which will eventually become harder to run as Python 2 is phased out. The biggest disadvantage is that I haven’t done any XSLT work in 10 years so I need to relearn it every time the script needs modification.

It seems that the XSLT code you have written has become a different kind of obsolete

Not exactly what you meant, because here the css is included after XSLT is applied to XML: http://xsubs.tv/ice/seriesn%E2%84%96.xml

On a similar topic, XSLT is still an excellent way to turn structured data into a page. It even works with RSS, ATOM, and OPML.

And you can even mix-and-match it with SPAs, and Vue.js with it's "hydration" system. That's an very power trick to slash data consumption, and improve cache hits for a "portal" style website. One showstopper: gazillion XSLT/XML bugs in Chrome left unfixed for 10+ years.

Another particularly interesting application is that you can turn XML data into SVG visualisation solely with XSLT, or you can add some JS with interactivity cod into XSL to run on the client side as a finishing step.

I remember my college professor (back in 2007) betting his career that XSLT would become the defacto standard. It’s always a reminder to myself to not get blindsided by being stuck/locked into a single technology.

> XSLT is still an excellent way to turn structured data into a page

Is it, though? I would think its only real win over a template system based on a scripting language is when the template author is untrusted. And that niche is now much better covered by Liquid: https://shopify.github.io/liquid/

Arguably, the most characteristic feature of XSLT is that it uses XML for serializing code text itself. As such, one can expect most benefit from XSLT which uses lots of literal XML content embedded into XSLT. But that can be had with any general-purpose language having XML literals as well (such as JSX or old E4X). Other than that, XSLT still remains a competent markup processor, and XSLT 1.0 (but no later version) is indeed highly portable.

Since DSSSL (precursor of XSLT) is based on Scheme, I've always wondered if some HNers will pick-up OpenJade as its reference implementation.

You can compose multiple XML docs using XSL, the catch is XML is not rendering until the whole document is loaded in Chrome, the benefit on the other side is that XSL, and referenced XML docs are cacheable.

Tell me of a single template language supported client-side without JS

Maybe I just lack imagination, but what are the applications for this? The only thing I can think of might be some static data repository of raw XML files, which are accessed using a server that can send an XSLT header but you want to avoid loading up with template processing.

In the case of a webapp, you're running JavaScript anyway, so it doesn't really matter. Fun fact— very early Google Maps used XML for the ajax responses, and then switched to JSON for performance/simplicity reasons, since the result was being used in code anyway, not just rendered and displayed.

XML API - robots exchange XML, converted to human form with a stylesheet, both on the fly and stored documents. From the description of fields to full blown application, think XSLX plugged Excel stylesheet.

That's how desktop applications work, maybe we should ask why is it not the norm? Why each request downloads application intertwined with data? Why can't one save response as one saves desktop document?

I am ok with JSON but I want a way to plug application supported by browser, XML is the only choice yet.

Traffic, and cache hit optimisation. By "hydrating" a transformed page you get the best of two worlds.

Both small initial package to render a page, cache hits, and relatively small SPA package.

We do this for CCDA documents. Makes it easy when you're passing them around during development.

> <p>p.s. <a href='https://github.com/secretGeek/html_wysiwyg/'>source code here</a></p>

This was a missed opportunity to link back to the very same page.

Besides being a quine, it's also a nice literate programming example.

Literate programming aims to help understanding, and this does the opposite. This was hard to read and follow along. I kept having to visually skip past meaningless markup.

There's no meaningless markup on that page.

It literally explains the meaning of each bit of markup.

If you're interested in quines, see also TiddlyWiki[0] (and specifically this[1] great talk by its creator Jeremy Ruston and the late creator of Erlang, Joe Armstrong)

[0] https://tiddlywiki.com/

[1] https://m.youtube.com/watch?v=Uv1UfLPK7_Q

Too much productivity have been wasted on setting up personal blog. IMO everyone should just use tiddlywiki

This page, while not brutalist, is IMO much more interesting since it codes itself live:


Discussed here: https://news.ycombinator.com/item?id=21035313

Well, it's a good thing it codes itself now, since the author was arrested for flouting money laundering rules [1].

Kidding, of course, America has a famously low-touch approach to financial crimes.

[1] https://www.nytimes.com/2020/10/01/technology/bitmex-bitcoin...

All I'm taking away from this article is that our finance laws are outdated and draconian, failing us in cases like this.

or maybe crypto as we know is an obvious attempt to sidestep the laws on money transmitting and money laundering by adding "but on a computer" and thinking it somehow obviates all the existing laws that were enacted for perfectly good reasons, and people who choose to involve themselves in these dubious legal schemes get rightfully nailed when they step over the line.

like, just because operating a crypto exchange that doesn't follow KYC laws is convenient and nice doesn't mean that we should get rid of all the laws. It would be convenient and nice if regular banking didn't have to follow KYC too, then you could pay for murder hitmen to take out your business partner with your regular bank account instead of needing crypto at all!

I don’t think this thread is the proper venue for your (as well as ancestors’) crypto opinions.

You are one comment late. The distraction was the mildrant about existing financial regulations. Your late reply makes you sound like a crypto apologist instead of someone making a reasonable attempt at keeping the thread tight.

The quine introduces a few concepts I've not yet seen before, and I always appreciate deep-dives into the (very) sloppy and forgiving parsing that browsers do to forgive the developer's perceived mistakes. One can argue, quite convincingly, that this was a bad idea™ and should never have been done; given that we can't break web backcompat, it's here forever, to live alongside all the sloppy coercion hacks and "did you mean?"s living in PHP & JS.

It is truly surprising that:

    * { display:block; }
actually displays the whole contents of <head>. It makes no sense, but neither does most of HTML, so why not?

> It makes no sense

Why so? <head> is a conventional place for tags with document metadata semantics to live, but <head> has no semantic meaning itself. (I think the only thing one could say about how UAs treat <head> is that some scraping robots might only parse <head>, discarding <body> entirely.)

And read my words above again: tags with document metadata semantics. Not “metadata tags.” All tags are just containers for DOM nodes or text, whatever additional implications they carry for the document. HTML is "a markup language for text first, and a container format for web pages second."

IMHO, <title> especially should be styled for display more often. It works great as an effective “<h0>“ tag, rather than duplicating <title>'s text into an explicit <h1> somewhere in the <body>. That way, the document only embeds its own title in one canonical location—a title which both gets rendered on the page, and displayed in the title bar. (And if you’re worried about positioning, there’s nothing saying you can’t put your <title> in your <body>. Yes, it will do the right thing.)

Tangent: in fact, there's really no reason to have <head> and <body> in your document at all. You can just declare <html> and start spitting tags. IMHO, despite going against a long-standing trend, it's a much more practical arrangement—especially if you keep all your "outside the content" formatting to CSS, and apply that CSS using a response header (https://www.w3.org/TR/html401/present/styles.html#h-14.6). If done correctly, your "full document" HTML can look exactly like your XHR-response "patch" HTML, such that your API endpoints can themselves render as full documents when viewed separately—without changing what they return! (I really need to blog about this.)

>And if you’re worried about positioning, there’s nothing saying you can’t put your <title> in your <body>

Well, the specification says you can't.

>You can just declare <html> and start spitting tags.

Strictly speaking, <html> is not required too. This is compliant HTML:

    <!DOCTYPE html> <title>something</title> hello
But that's just notation thing, implicit element will be automatically opened/closed, all rules still apply. Thus

    <!DOCTYPE html> hello <title>something</title>
is not valid, because 'hello' implicitly opens <body>, and <title> is not allowed to be there. Of course all of these would probably work in practice, because there's no junk that browser wouldn't happily accept. Discussed quine also violates standard, because it misses doctype and places <style> tags in body.

> Well, the specification says you can't.

If every implementation of a spec allows something that the spec doesn't, does it really matter what the spec says?

I always understood the various web standards as descriptive, rather than prescriptive. They tell you what browsers will/won't accept. If all browsers accept something, it should (in RFC terminology) become a part of the standard.

> places <style> tags in body

Entirely separate note: given the semantics of the CSS cascade, shouldn't stylesheets in the body only apply to the DOM nodes succeeding them, not to DOM nodes preceding them? (I have a feeling that that complexity is why <style> isn't allowed in the body...)

I've tried visible <title> [1], it looks natural in search results

    body ...
vs default

    title content
    same in h1 content. body...
Search engines claims that's error and may (I'm not sure) penalize. Have to use <meta description> to fix search results (its absence claimed as error too).

[1] http://sergeykish.com/live-pages

> * { display:block; } > > actually displays the whole contents of <head>

Yeah, it enables some whacky stuff. There's something funny about <style style="..."> actually working...

For lolz I hacked up the following piece of code where an "article" is rendered entirely from <head> (probably not the cleanest implementation, but it works, and passes the nu validator with flying colors too):

  <!DOCTYPE html>
        head {
          display: block;
          max-width: 600px;
          margin: 0.5em auto;
        style.show {
          display: block;
          /* Create new stacking context. */
          position: relative;
          z-index: 0;
          white-space: pre-wrap;
          margin-bottom: -1em;
          background-color: #fff;
        style.show::first-line {
          font-size: 0;
      <style class="show" style="font-weight: bold">/*
  An article rendered entirely from <head>

      <style class="show">/*
  Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam ut viverra purus. Ut enim ligula, luctus nec mi sed, molestie mattis purus. Praesent quis mauris orci. Nunc blandit eget ligula sollicitudin pretium. Duis at est porttitor, feugiat est ac, volutpat magna. Nulla varius nunc ut blandit porttitor. Vestibulum tempus eros quis massa efficitur, quis condimentum nunc condimentum.

      <style class="show">/*
  Duis porttitor lobortis nulla pretium aliquet. Nulla in dignissim magna, eget tincidunt odio. Interdum et malesuada fames ac ante ipsum primis in faucibus. Sed quis vestibulum ligula. Vestibulum nec nibh quis neque venenatis sodales vel et purus. Duis purus lorem, facilisis vitae dictum in, mattis eget est. Suspendisse porta ornare elit, vel dictum felis. Cras mattis erat nec sapien scelerisque faucibus. Donec quis odio porta, pretium nunc at, laoreet massa.

      <style class="show">/*
  Nullam bibendum ornare malesuada. Phasellus eget sollicitudin lectus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nulla eget diam sed erat interdum lobortis. Curabitur sed posuere magna. Donec ornare pulvinar gravida. Sed ante ipsum, laoreet vitae rhoncus in, vulputate a est. Maecenas a ligula eu leo fringilla commodo ac cursus ante.

      <style class="show" style="padding: 1em 0"></style>

Here's a fiddle: https://jsfiddle.net/zfs2rabc/

Thanks for pointing this out. This kind of stuff is why I love HTML.

And the comments are a quine relay: the top comment of that thread is a link to a simple html quine.

That's excellent!

They arrested him for having a sick website.

I have ThreeJS devtools installed and it also displays the injected code :)


If the page knew to show “<script>” before and after script tags, and to apply “ white-space: pre-wrap;” to script tags, it would’ve been slightly clearer what those tools were doing to you.

I have Dark Reader and it shows the CSS there too. Very cool.

Off topic: does anyone know why are the tags and attributes not selectable in the page?

That’s not off topic at all, very astute observation. Pseudo elements are not part of the DOM. They’re not really there.

Here’s a HTML reference https://www.w3.org/TR/CSS2/selector.html#pseudo-elements

IMO nothing shows the absurdity of CSS more than before/after rules.

I think it makes perfect sense. CSS is for display, not content. Therefore, anything that gets put in before/after is a display matter only, it's not semantic content. Therefore, it shouldn't be selectable.

You forgot about `user-select`

    * { user-select: none }
now entire page is for display. What is content and what is meta decided by consumer, author can guide, medium creates obstacles. <blockquote> does not copy quotes. Some pages present link as <a href=foo>foo</a>, it would be nice to use

    a::after { content: '(' attr(href) ')' }
but it is not selectable. A lot of pages present anchor as <a>¶</a> on hover, can't be done with CSS. What is missing is

    *::before, *::after { user-select: text }
Nope, it does not work.

Best tool so far is XSLT, I've written prototype that mimics CSS syntax

    quote {
      content-before: '"'
      content-after: '"'
    a {
      content-after:  '(' @href ')'
    h2 {
      content-before: <a href=@href>¶</a>
Anyone interested?

It show the sanity of CSS rules. CSS is meant for visual formating. Assumption here is that you want to copy the content, not the decoration of it.

It's not that unreasonable— it's the same as bullets and numbering in lists not be selectable.

Can you expand a bit on this? What are the reasons you consider them absurd, and CSS in general?

(honest question) As someone who used pseudo before/after in my own code, I'd be interested in their potential downsides or issues.

Arguing strictly from a language design PoV, and having used before/after myself, if markup is for content/structure, and CSS is for presentation, then it's just idiosyncratic af to generate content from CSS rules. Obviously, the purpose of before/after is to produce a visual effect; then why produce pseudo-content if CSS is oh-so-great a language for presentation? But IMO that's par for the course for CSS which starts out by migrating rendering properties that used to be HTML attributes into their own syntactic category that's neither here nor there, then postulates a structure/presentation dichotomy after the fact. When actually markup attributes are intended exactly for the purpose of holding rendering properties rather than some elusive "structural semantics" bs. Going from there, it feels like CSS heads got lost in their maze of separation of concerns story, which in any case has never needed new syntax, let alone a thousand micro syntaxes.

> Obviously, the purpose of before/after is to produce a visual effect; then why produce pseudo-content if CSS is oh-so-great a language for presentation?

Because sometimes the best way to style something is by using a character (bullet points, arrows, ...). Example: you could add a symbol to URLs by giving <a> a slight padding on the left and by adding an image showing an URL symbol. But by using &#x1f517; in a:before, you cheaply get vector graphics, and a symbol which (in a perfect world) will always match the font.

Because they're defined via CSS ::before{content} and ::after{content} properties, and browsers don't make that text selectable for some reason.

It's very useful when having stuff like that:

  <style type="text/css">
  .code-line::before {content: '>>> ';}
  <div class="code-line">print 12</div>
  <div class="code-line">a = [i**2 for i in range(10)]</div>
Then the reader can copy the actual code without the interpreter's prompt.

When text-transform is used on an element, the copy-pasted text is the original text from the DOM, not the transformed version.

There needs to be a CSS property that makes the visible text selectable and copyable.

Preferably there would be a browser option to choose whether or not to do this in the menu for interacting with the selection. The CSS could set the default and the browser could allow you to override it when you're interacting with the text.

While an interesting study in aesthetics, web brutalism or html brutalism isn't really brutalist at all. They all seem hyper-focused on exposing raw building materials when that totally misses brutalism's goals. A simple, small, unpainted cinder block shack doesn't hide its materials, is made of raw concrete, but probably isn't brutalist. Neither is a brick victorian.

The idea that beautiful forms can come from purely functional design without needing to cover things up with baroque decoration is really a central theme. As is making these huge structures with small, modular elements designed at human scale to get something that's truly people-focused. All of this stems from a utopian idea that scaling production can provide functional, beautifully designed buildings for use by all people, rather than just the privileged few. While the style is polarizing, I'd say it often accomplished its goals. In my experience, well-designed brutalist buildings are easy to navigate, have large open spaces, have lots of little nooks and crannies to foster human interaction, and have really beautiful forms.

While the page has nice enough lines and makes good use of color, the html tags have quite the opposite effect that a brutalist-era designer would hope to bestow upon the user. In this way, I'd say that this website is a far better example of brutalism than that website.

For context, this is a meme of modern architecture called "truth to materials", "which holds that any material should be used where it is most appropriate and its nature should not be hidden. Concrete, therefore, should not be painted and the means of its construction should be celebrated by, for instance, not sanding away marks left by timber shuttering"[0].

It's why so many modern buildings[1] are white or brown.

Also, brutalism is beautiful[2]. Even in its stark outside, it fosters an equal-and-opposite beauty within, like if Nine Inch Nails was buildings.

0: https://en.wikipedia.org/wiki/Truth_to_materials

1: https://en.wikipedia.org/wiki/Modern_architecture#Internatio...

2: https://images.jacobinmag.com/wp-content/uploads/2018/10/151...

“Brutalism is beautiful”? Brutalism is cost-effective, and the rest is making a virtue of a necessity IMHO. Chacon à son goût/À chacon son goût, as long as you don’t force people to look at it everyday. But neighborhoods must live with the buildings long after the architect moves away to that charming Greek island, hence the problem. The eternal problem of urban architecture and public art in general...

Any building can become blighted. Any architectural trend can be misused. Not all brutalist buildings are cheaply constructed.

> A simple, small, unpainted cinder block shack doesn't hide its materials, is made of raw concrete, but probably isn't brutalist. Neither is a brick victorian.

> The idea that beautiful forms can come from purely functional design without needing to cover things up with baroque decoration is really a central theme.

Huh? These two are contradictory statements. I recommend giving this a read, Architecture is where brutalism first sprung up: https://www.nytimes.com/2016/10/06/t-magazine/design/brutali...

> These two are contradictory statements.

They are not remotely contradictory. Something being beautiful because the architect or a stylist added beautiful decorations is entirely different from something being beautiful because the lines, forms, and overall composition of the functional form, by itself, is beautiful. Much of the material on a brick victorian is purely for decoration. A small cinder block box, unless it was purpose-built to store boxes, was not built carefully to consider how it interacts with its occupants.

I'm not sure if you just skimmed most of my comment, but it was pretty clearly discussing architecture.

A small cinder block shack isn't very functional, so not brutalist. A brick victorian is intentionally ornate (it exposes the brick as part of its aesthetic, not because of a reluctance to decorate) ergo it isn't brutalist.

Why isn't a cinder block shack functional?

I think the sentence was saying that a brick isn't Victorian, not that a brick Victorian isn't brutalist.

Plus, there is zero concrete used here.

I'd consider that a minor semantic point if the overall spirit of brutalism was honored in these sites... but honestly, that would be pretty boring!

Is an empty .html file technically the shortest html quine?

If it is a truly empty file then no, because that wouldn't validate as a valid html file.

The bare minimum I believe is <HTML></HTML> ...which on its own wouldn't be a HTML quine.

AFAIK in HTML5 you need a doctype and and a non-empty title, but the <html> etc tags are optional:

    <!DOCTYPE html>

Title is actually optional “if the document is an iframe srcdoc document or if title information is available from a higher-level protocol” (such as email). So the minimal valid HTML document is actually just <!doctype html>.

But you don't even need that if you're happy with quirks mode, right?

Right data:text/html,

Sure it is, just serve it with Content-Type: 'plain/text'.

That has nothing to do with HTML. That's an HTTP header.

This thread has a surprising amount of not knowing the difference between HTML and HTTP. The original post is entirely about HTML and does not involve HTTP transmission at all.

HTML <meta> tags are a thing, to invoke browser behavior typically associated with HTTP headers. I'm not sure if that can get you there; I would guess that to visually output the meta tag would require the same * { display:block } shenanigan that the original post is about.

Declaring that it’s not an HTML file is a weird way to claim the smallest valid HTML file.

This actually reminds me of an idea I had for my own website [1] when I redesigned it, but I wasn't going for a quine and rather made use of copy/paste with a simpler format.

I implemented a copy/paste feature using dummy elements that are only visible when being selected, so that when someone wants to copy text from my website, it will be copied as markdown notation (which was the originating article format before being statically rendered into the HTML code).

Technically, this would work with HTML+CSS only, but I decided to go with JS generating these nodes automatically to keep my sanity alive - because there were some quirks along the way with getting paragraphs to be copied correctly across the major Web Browsers. [2] and [3]

[1] https://cookie.engineer

[2] https://cookie.engineer/design/copypaste.css

[3] https://cookie.engineer/design/copypaste.js

Brutalist? There is a custom font, a fixed text width, and it is even centered! :)

Brutalist doesn't meen no css. Brutalism in architecture is minimum decoration. I mean, it would be brutalist to leave tubes and other plumbings visible on the outside, but if you hide them to make the spacer "prettier" it's still brutalism.

Yes, my understanding of brutalism is that it was meant to be about "honesty" rather than "ugliness" -- little decoration, craftmanship, or anything for the quality of the materials themselves to hide behind. But some of its most famous exponents appear to be more about "ugliness", so over time it's kind of come to mean "ugliness in the name of honesty", which really is hard to appreciate.

I immediately "got" brutalism in architecture when I saw those all-concrete no-windows structures. But you look at wikipedia and I think the ones with windows or color should have another, lesser name.

When I think of brutalism, I think of the Barbican Estate in London as a canonical example - there's a lot of concrete, but also a lot of windows (a whole lot more window area than you would find in other UK residential architecture).

And, it feels absolutely comfortable to be inside.

I value the experience of being inside the building, more than how it looks from the outside. As such, I find it hard to understand when people associate brutalism with ugliness.

First search result, by way of example: https://www.independent.co.uk/news/what-it-s-live-inside-bar...

It probably depends if you consider these things functional or decorative.

There is nothing brutalist about this page. "Brutalism" has been turned into yet another buzzword by web-designers. It's now basically an excuse to do cheap looking pages with no sense or understanding of webdesign at first place. It's a race to the bottom.

One of my co-workers made a fun sort of HTML quine: https://firebase.tools

It's a script you execute using curl | bash but it uses bash comments to contain HTML and CSS to prettyprint itself in the browser.

As far as I know he invented this technique.

reminds me of a super-nerdy magazine column we had back in college, printed (on paper) in raw LaTeX

Relatedly, I wrote this CSS that renders HTML as Markdown: https://gist.github.com/ImJasonH/c00cdd7aece6945fb8ea

Awesome! Thanks for sharing.

Interesting: in Chrome I can't search the content of <style> tags with ctrl+f. Seems to work in Firefox though.

E.g. ctrl-f "max-width": zero results in Chrome (but it's used in the final <style> tag).

Can this be turned in a browser extension that would allow a nicer view source?

For Firefox, I found this extension [1] which is really a step-up from the build-in source viewer.

[1]: https://addons.mozilla.org/en-US/firefox/addon/fire-source-v...

Unlikely, as in its current form, the styling includes special :before and :after rules for specific elements, and the inclusion of element attributes in the final output has to be also hand-coded for specific elements and attributes.

I also wrote a version that used javascript to see what elements existed in the page and generate the relevant before/after styles. Adding attributes would’ve be doable. But it gets a bit silly really, once you have a giant page.

Here is another one and it's simpler:


It uses the same idea as the one above, just has less explanation.

If curious see also

Show HN from last year: https://news.ycombinator.com/item?id=20094866

I really like that at this moment the two top stories on HN are about actual hacks!

Truly marvelous. Just what the doctor ordered.

(Kind of a statement on how horrible web tech has gotten, but that's a philosophical, not technical, discussion. Technically this is awesome!)

While not on the same level, this reminds of this gem:


I was initially going to quip that is more minimalist than brutalist, but then I realized ( even though brutalist was a trend associated with architecture, it does have in its definition an embrace of minimalism ). I think it is time for coffee.

Hah, you think that is brutalist? Try this instead: https://catfish.dev/catfish-developer.html

I think the "quine" part is the part that's more interesting...

Even more fun with <html contenteditable>!

Oh that's clever, and cute, and I like it.

Nothing but beautiful, great job!

Thanks Thomas!

fun to see every element visible

It's only really a Quine if it has a taste for desert landscapes


What does “quine” mean?

Quine is a person?

Yes, or was, for a while.

As was Haskell Curry: https://en.wikipedia.org/wiki/Haskell_Curry

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact