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.
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.
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.
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 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.
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.
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”.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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!
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?
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.
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
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).
> * { 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>
<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>
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 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.
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
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 🔗 in a:before, you cheaply get vector graphics, and a symbol which (in a perfect world) will always match the font.
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.
“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...
> 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.
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.
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>.
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.
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]
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.
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.
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.
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.
Here is my favorite, Capsized by Zak Kain for Stanford's Code Poetry Slam:
https://web.archive.org/web/20170522035639/http://stanford.e...