This page is a truly naked, brutalist HTML quine
secretgeek.github.io
secretgeek.github.io
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;
}
https://web.archive.org/web/20170522035639/http://stanford.e...This guy is amazing: https://aem1k.com/
for(b=i=[X=3772];i--;)b[i]=68*i%9%2;setInterval('for(a=b,b=[h="<pre>"],i=0;i++<X;i%w||(h+="\\n")){for(d=j=0;e=[1,91,w,93][j++];)d+=a[i+e]+a[i-e];h+=".#"[b[i]=3==d|a[i]&2==d]}document.body.innerHTML=h',w=92)> A quine is a computer program which takes no input and produces a copy of its own source code as its only output.
HTML with either CSS3 or JavaScript is definitely a program, though.
So GET and POST are figments of my imagination then?
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.
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.
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.
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.
Remember that html files are not just html. The way we use them today they are fully functional programs.
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.
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.
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.
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.
An HTML file cannot be a Quine because an HTML file is not a program because HTML is not Turing Complete.
Adding two numbers in HTML might be expressable but clearly it's much easier in Javascript.
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.
https://github.com/ainfosec/crema
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.
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?"
For example, a Lisp based on JSON:
https://github.com/kanaka/miniMAL
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.I also did not say HTML is not a programming language.
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.
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.
that is my real point
So a parthenogenic Scotswoman would be a double quine.
<?xml-stylesheet type="text/css" href="style.css"?>
Bonus points if you mix that with XSLT.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.
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/
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.
Both small initial package to render a page, cache hits, and relatively small SPA package.
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.
Since DSSSL (precursor of XSLT) is based on Scheme, I've always wondered if some HNers will pick-up OpenJade as its reference implementation.
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.
This was a missed opportunity to link back to the very same page.
It literally explains the meaning of each bit of markup.
Discussed here: https://news.ycombinator.com/item?id=21035313
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?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.)
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.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...)
title
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).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>
<html>
<head>
<title>.</title>
<style>
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>
<style class="show" style="font-weight: bold">/*
An article rendered entirely from <head>
*/</style>
<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>
<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>
<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>
<style class="show" style="padding: 1em 0"></style>
</head>
</html>
Here's a fiddle: https://jsfiddle.net/zfs2rabc/Kidding, of course, America has a famously low-touch approach to financial crimes.
[1] https://www.nytimes.com/2020/10/01/technology/bitmex-bitcoin...
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!
http://web.archive.org/web/20201019103343/https://secretgeek...
<style type="text/css">
.code-line::before {content: '>>> ';}
</style>
<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.There needs to be a CSS property that makes the visible text selectable and copyable.
Here’s a HTML reference https://www.w3.org/TR/CSS2/selector.html#pseudo-elements
(honest question) As someone who used pseudo before/after in my own code, I'd be interested in their potential downsides or issues.
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 🔗 in a:before, you cheaply get vector graphics, and a symbol which (in a perfect world) will always match the font.
* { 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?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.
> 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...
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.
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...
The bare minimum I believe is <HTML></HTML> ...which on its own wouldn't be a HTML quine.
<!DOCTYPE html>
<title>x</title>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.
Live: https://gistpreview.github.io/?0b8b18ca9dbd5a648d9fa21d7f146...
Source: https://gist.github.com/MarkTiedemann/0b8b18ca9dbd5a648d9fa2...
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]
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'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.
E.g. ctrl-f "max-width": zero results in Chrome (but it's used in the final <style> tag).
[1]: https://addons.mozilla.org/en-US/firefox/addon/fire-source-v...
Show HN from last year: https://news.ycombinator.com/item?id=20094866
(Kind of a statement on how horrible web tech has gotten, but that's a philosophical, not technical, discussion. Technically this is awesome!)
As was Haskell Curry: https://en.wikipedia.org/wiki/Haskell_Curry