The appeal of using plain HTML pages (2019)(utcc.utoronto.ca)
utcc.utoronto.ca
The appeal of using plain HTML pages (2019)
https://utcc.utoronto.ca/~cks/space/blog/web/PlainHTMLAppeal
211 comments
Imagine my smug face as the pendulum finally swings back to me, with my hand typed, hand crafted, fair trade, organic and bespoke HTML. For my next trick, I will achieve the unthinkable and show you how I launch my blog without a dual redundant k8s cluster.
> my blog
...is the usual use case for the "why not just use HTML?!" argument. Still, even at the enterprise level, considering SSR's popularity, the "pendulum" has been in favor of static HTML for a while.
...is the usual use case for the "why not just use HTML?!" argument. Still, even at the enterprise level, considering SSR's popularity, the "pendulum" has been in favor of static HTML for a while.
You mean static HTML loaded onto serverless cloud storage with cloudfront, using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket, then with a headless CMS visual editor which sits on some SaaS platform, with any server-side interactions written in Lambdas?
> static HTML loaded onto serverless cloud storage with cloudfront
That's just a verbose way of saying "a file hosting service."
> using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket
What's wrong with that though? You could describe any computer technology in arbitrarily high level of depth to mock how complicated it is. Text editors sound very complicated too if you describe their internal data structures, the window server the GUI runs on, the operating system's context switching system, etc.
That's just a verbose way of saying "a file hosting service."
> using Hugo to compile markup into HTML with a CI/CD pipeline created to push the content up to your S3 bucket
What's wrong with that though? You could describe any computer technology in arbitrarily high level of depth to mock how complicated it is. Text editors sound very complicated too if you describe their internal data structures, the window server the GUI runs on, the operating system's context switching system, etc.
For some reason
using a bash script to munge a few files together then a cron job running to rsync them to an Apache server running on a VPS
is considered morally and technically superior to
using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it.
There’s no obvious reason for this, other than a belief that if something can be done with 50 year old technology, it should be.
using a bash script to munge a few files together then a cron job running to rsync them to an Apache server running on a VPS
is considered morally and technically superior to
using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it.
There’s no obvious reason for this, other than a belief that if something can be done with 50 year old technology, it should be.
I don't think one is morally superior to the other, but there are trade-offs.
With bash, cron, rsync, and a vps, one is using stable, long-lived tools that usually come with Linux, are vetted and patched automatically, and are familiar in the sense that those same tools can be used for all sorts of tasks, not just frontend development. There is also the argument that the only remote piece controlled by the service provider is a vps which still gives you lots of control and flexibility with minimal lock-in.
I prefer somewhere in the middle of the two extremes, but I see more appeal to the "old" approach than you allude to.
With bash, cron, rsync, and a vps, one is using stable, long-lived tools that usually come with Linux, are vetted and patched automatically, and are familiar in the sense that those same tools can be used for all sorts of tasks, not just frontend development. There is also the argument that the only remote piece controlled by the service provider is a vps which still gives you lots of control and flexibility with minimal lock-in.
I prefer somewhere in the middle of the two extremes, but I see more appeal to the "old" approach than you allude to.
Funny that tools distributed via a linux package manager are considered 'vetted and patched automatically', but a broadly used JS build tool distributed via npm is likely seen as an unstable dependency, or worse a supply-chain attack vector.
Sure, there are maturity differences but it's nowhere near so vast a difference as some claim.
These are just preferences. It's not a culture war issue.
Sure, there are maturity differences but it's nowhere near so vast a difference as some claim.
These are just preferences. It's not a culture war issue.
If you don’t understand the difference between software shipped by a distro and software shipped by developer (npmjs.com) then all is left is preferences or culture war issues.
However there’s fundamental difference: in a model of distribution by a distro the developer only produces a software but they don’t release it themselves. They provide source code and that’s it. Maintainers of packages for each distro vet new releases, test, and sometimes patch them so they work best within context of a given distro. So there’s extra effort spent on making sure the software is stable. In a model where a developer publishes their new release to some package repository directly (npmjs.com is just one of them, same applies to pypi.org, rubygems.org, etc) that extra “QA” by others than the developer doesn’t happen.
However there’s fundamental difference: in a model of distribution by a distro the developer only produces a software but they don’t release it themselves. They provide source code and that’s it. Maintainers of packages for each distro vet new releases, test, and sometimes patch them so they work best within context of a given distro. So there’s extra effort spent on making sure the software is stable. In a model where a developer publishes their new release to some package repository directly (npmjs.com is just one of them, same applies to pypi.org, rubygems.org, etc) that extra “QA” by others than the developer doesn’t happen.
> There’s no obvious reason for this, other than a belief that if something can be done with 50 year old technology, it should be.
While past performance is no predictor of future performance, on the face of it I'm likely to bet on the stability and longevity of the classic time tested technology outlasting that of the newer technology. Especially if the newer one relies on specific 3rd party services.
While past performance is no predictor of future performance, on the face of it I'm likely to bet on the stability and longevity of the classic time tested technology outlasting that of the newer technology. Especially if the newer one relies on specific 3rd party services.
To clarify, how you build it and how you host it are two different questions with different constraints.
eg the trade offs of the new might be weighted differently than the old as they apply to building vs hosting. Your build breaking due to stack changes is a different PITA than a security vuln in the hosting. Although the build might break more often due to churn in the new fangled stuff, you might trade that off for the less hands-on hosting maintenance.
But for another trade-off, the old stuff is far less service dependent, so less work to migrate if you need to change service providers.
Engineering is trade-offs, and decisions are made based on assigned weightings of various factors. The weightings are subject to bias though and thus always personal.
eg the trade offs of the new might be weighted differently than the old as they apply to building vs hosting. Your build breaking due to stack changes is a different PITA than a security vuln in the hosting. Although the build might break more often due to churn in the new fangled stuff, you might trade that off for the less hands-on hosting maintenance.
But for another trade-off, the old stuff is far less service dependent, so less work to migrate if you need to change service providers.
Engineering is trade-offs, and decisions are made based on assigned weightings of various factors. The weightings are subject to bias though and thus always personal.
To clarify, my original post was more satire on the idea of using 4-5 different SaaS/PaaS services in order to put a simple HTML site onto the net.
I don't have any moral opinion about it - in fact I run a site with the setup described which is half why I am satirizing it (It's cheap to run, but it's also overly complex, has a load of dependencies that ultimately a simple HTML file shouldn't have, and the final setup is quite limiting).
I do think we lose something intangible by building websites with mousetrap-esque technologies. The idea is usually that when you abstract something away, it becomes simpler to understand and quicker to develop in - but IMO it seems like we have abstracted away and it has become harder to understand and slower to develop in.
I don't have any moral opinion about it - in fact I run a site with the setup described which is half why I am satirizing it (It's cheap to run, but it's also overly complex, has a load of dependencies that ultimately a simple HTML file shouldn't have, and the final setup is quite limiting).
I do think we lose something intangible by building websites with mousetrap-esque technologies. The idea is usually that when you abstract something away, it becomes simpler to understand and quicker to develop in - but IMO it seems like we have abstracted away and it has become harder to understand and slower to develop in.
Moral superiority? Perhaps in some purist circles.
No, the biggest problem is that for so called 'engineers', software engineers who do web development are by far among the worst at actually evaluating solutions based on their engineering merit. Thus, we get overengineered solutions in companies and areas that simply do not need that level of complexity.
No, the biggest problem is that for so called 'engineers', software engineers who do web development are by far among the worst at actually evaluating solutions based on their engineering merit. Thus, we get overengineered solutions in companies and areas that simply do not need that level of complexity.
Now we’re doing engineering? I thought we were just putting some HTML files on the internet.
The two approaches I described have exactly the same number of moving parts; they require you to understand exactly the same number of technologies. There is no difference in ‘complexity’.
The two approaches I described have exactly the same number of moving parts; they require you to understand exactly the same number of technologies. There is no difference in ‘complexity’.
The number of moving parts & the number of technologies is clearly only one aspect of complexity. The actual complexity and dependencies of each particular technology also differs. My point still stands, I've seen far too much resume building to have any other perspective. Obviously sometimes a company does require complex tools to deliver a product. That's fine. Often they don't, but they still end up with complex tools. That's not so fine.
I just don't see github actions, say, as an inherently more complex tool than cron. Or vice versa. Both have a certain essential complexity to getting a scheduled task to run, once you've overcome the initial hurdle of getting to a point where you can use them. Depending on where you're starting from, what tools you're already using, and what ecosystem you're already part of, that initial hurdle is going to be of a different size, but once you're over it, for either case, you're just configuring a job with a schedule, and then hopefully getting to forget about it.
> using a JavaScript tool to build a site
there is so much can go wrong that this unlikely to be as simple as running a bash script.
i usually use node cmd to write terminal programs but recently tried bash and i found it much better for simple stuff.
there is so much can go wrong that this unlikely to be as simple as running a bash script.
i usually use node cmd to write terminal programs but recently tried bash and i found it much better for simple stuff.
>"using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it."
Why would I want to introduce so many a dependencies when I can have zero? Yes in this case old tech is superior. Sure if (and that is a big if) your blog is super popular you might want to "cloudflare" but that's about it.
Why would I want to introduce so many a dependencies when I can have zero? Yes in this case old tech is superior. Sure if (and that is a big if) your blog is super popular you might want to "cloudflare" but that's about it.
As Douglas Adams once said:
“ I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.”
Only when applied to Linux, this amounts to:
Anything that was copied from UNIX is normal and ordinary and just part of the way the world works.
Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.
Anything else is a ‘dependency’.
“ I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.”
Only when applied to Linux, this amounts to:
Anything that was copied from UNIX is normal and ordinary and just part of the way the world works.
Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.
Anything else is a ‘dependency’.
> Anything that was copied from UNIX is normal and ordinary and just part of the way the world works.
> Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.
> Anything else is a ‘dependency’.
The picture you're painting of pure back-in-my-day-sonny! bias, while not totally wrong, is also not quite accurate. These different technologies have different installed bases, different probabilities of security vulns, different probabilities of still being maintained in 10 years, etc.
> Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.
> Anything else is a ‘dependency’.
The picture you're painting of pure back-in-my-day-sonny! bias, while not totally wrong, is also not quite accurate. These different technologies have different installed bases, different probabilities of security vulns, different probabilities of still being maintained in 10 years, etc.
Yes! The probability of a security vulnerability in the Apache install whose httpd.conf you had to write, running on a VPS you have to patch yourself, versus the probability of a security vulnerability in S3/CloudFront are indeed vastly different.
These are the kinds of trade offs we make.
These are the kinds of trade offs we make.
1) I do not use Apache.
2) As for probability - I had zero security incidents on my personal website / blog in 15 years. And I did not spend my life patching things. Just few minutes every once in a while. Keep this FUD for uninformed.
2) As for probability - I had zero security incidents on my personal website / blog in 15 years. And I did not spend my life patching things. Just few minutes every once in a while. Keep this FUD for uninformed.
Even if you did use Apache it’s FUD. It’s a very robust, well understood and documented technology.
If there is a security vulnerability in S3 or CloudFront, it will be patched pretty damn quickly.
If there is a security vulnerability in a static site generator, that is unlikely to present to the internet, as the generator is not running on a public-facing server.
Hugo is now 8 years old, Jekyll is now 13 years old. Both are actively maintained, and given the inability of most people to string together a shell script that is both portable and correct, are likely better solutions than said shell script.
If there is a security vulnerability in a static site generator, that is unlikely to present to the internet, as the generator is not running on a public-facing server.
Hugo is now 8 years old, Jekyll is now 13 years old. Both are actively maintained, and given the inability of most people to string together a shell script that is both portable and correct, are likely better solutions than said shell script.
>"As Douglas Adams once said:"
Sure doc. You are free to follow and waste your time and money. I do not get a kick out of using half of the world resources for writing glorified "hello world". And let all those intermediaries control what you do in a process.
Adams Douglas was magnificent. Your attempt to use his words in this particular context however is anything but...
Sure doc. You are free to follow and waste your time and money. I do not get a kick out of using half of the world resources for writing glorified "hello world". And let all those intermediaries control what you do in a process.
Adams Douglas was magnificent. Your attempt to use his words in this particular context however is anything but...
Sounds tedious, I propose we make scripts for all these steps and bundle it alongside the frontend framework that renders static html
Exactly, plain html!
> how I launch my blog without a dual redundant k8s cluster.
Filezilla? rsync? Please share your secret!
Filezilla? rsync? Please share your secret!
Exactly my take! Awesome. I add 'regional' :-)
We genuflect at your smugness and your ability to tune out the noise of false prophets.
Can’t wait to read that blog post! :D
Can’t wait to read that blog post! :D
artisinal html
cxr(2)
Just responding to note the use of "bespoke" in the wild.
It's not that rare a term, HN search has 13 pages of just titles using it: https://hn.algolia.com/?dateRange=all&page=8&prefix=false&qu...
[deleted]
Yes, this one million times over. I have went from home-rolled React to Jekyll to Gatsby to Hugo and now seriously considering just doing my own HTML/CSS. Practically, I have rarely run into the issues other markup languages and SSGs are supposed to fix and more often, I find their constraints actually limiting/complicating my fairly simple desires. If I want to add movie/album reviews, rather than just making /reviews directory with some files and some basic CSS, I get stuck thinking about Hugo "archetypes" and templates and _index.md and layouts and all of this baggage. I wanted to add support for my site to use my custom "CSS as S-expressions" parser [0], but got turned off by the idea of integrating Hugo "pipelines" or "assets" or all of that. Not to mention that this grows ever more overwhelming if I take a months-long break and have to Google how to start my own blog server! Then I look at RMS' site and, ugly as it is, it has held up and looks way easier to update and less constrained by any premeditated structure/hierarchy.
[0]: https://uncomputation.net/cascading-style-s-expressions/
[0]: https://uncomputation.net/cascading-style-s-expressions/
RSS.
If you're writing a blog, then you probably want a way for people to subscribe to it instead of making them visit your site manually. Unless you are confident that you not only CAN write a feed by hand, but will never forget to hand-update it after updating the post itself, you're going to want to at least have the RSS feed be auto-generated.
And once you've added the infrastructure to auto-generate the RSS index, there's very little point in not auto-generating the HTML index, too. If only because, that way, you won't forget to run it.
If you're writing a blog, then you probably want a way for people to subscribe to it instead of making them visit your site manually. Unless you are confident that you not only CAN write a feed by hand, but will never forget to hand-update it after updating the post itself, you're going to want to at least have the RSS feed be auto-generated.
And once you've added the infrastructure to auto-generate the RSS index, there's very little point in not auto-generating the HTML index, too. If only because, that way, you won't forget to run it.
labs.steren.fr is pure static HTML, https://labs.steren.fr/atom.xml is manually updated and it doesn't take me more than 1 minute per article to do so.
I know how to write XML by hand. It's not hard. The reason I use Jekyll instead is because updating the RSS feed is something I might forget to do at all. Before I used Jekyll, it was a custom Perl 5 script, and if GitHub ever stops supporting Jekyll, that's what I'd move back to.
A well-designed SSG, like all of the ones I've used, will interlock[1] updating the feed and the HTML. You can't easily update one without updating the other, just like you have to go out of your way to open a microwave oven without also turning it off.
[1]: https://en.wikipedia.org/wiki/Interlock_(engineering)
A well-designed SSG, like all of the ones I've used, will interlock[1] updating the feed and the HTML. You can't easily update one without updating the other, just like you have to go out of your way to open a microwave oven without also turning it off.
[1]: https://en.wikipedia.org/wiki/Interlock_(engineering)
>> my custom "CSS as S-expressions" parser [0]
That’s a pretty neat idea, if all CSS on a site originated from your s-exp’s then you’d make it trivial to find not just what, but why a particular style has been applied (because now you’re only looking in an acyclic-graph, it’s easier to search).
That’s a pretty neat idea, if all CSS on a site originated from your s-exp’s then you’d make it trivial to find not just what, but why a particular style has been applied (because now you’re only looking in an acyclic-graph, it’s easier to search).
Thanks, yeah this is actually related to/the first step in a similar idea I had for a CSS SAT solver which generates a set of minimal CSS rules.
Have you tried Jekyll? I don’t know Hugo; I like Jekyll because it’s very simple with very little abstraction. My blog is just some hand-written HTML with liquid templating. I like how you can add any metadata you want to a post/page and then use it in your templates.
I have various static sites that I maintain, I recently added a new site created in Jekyll and wrote a bunch of content for it.
While I like Jekyll and I'll continue using it, I can definitely relate to the frustration when first using it. I get this feeling that I already know what I want Jekyll's HTML to look like, and now I need to work backwards and develop an understanding of Jekyll in order to figure out how to get Jekyll to produce the desired output.
By "HTML" I don't actually mean that I have a problem with embedding specific markup in the page, it's stuff like putting the files in the right place, getting the template to contain the right material, etc.
And to be clear, I'm going to continue using Jekyll since it seems more practical than e.g. Hugo given my constraints / available resources / etc, and I may even migrate some other sites I maintain to Jekyll, but Jekyll, like other static site generators, seems to throw a lot of mess in the way of simple desires, as the parent comment articulates.
While I like Jekyll and I'll continue using it, I can definitely relate to the frustration when first using it. I get this feeling that I already know what I want Jekyll's HTML to look like, and now I need to work backwards and develop an understanding of Jekyll in order to figure out how to get Jekyll to produce the desired output.
By "HTML" I don't actually mean that I have a problem with embedding specific markup in the page, it's stuff like putting the files in the right place, getting the template to contain the right material, etc.
And to be clear, I'm going to continue using Jekyll since it seems more practical than e.g. Hugo given my constraints / available resources / etc, and I may even migrate some other sites I maintain to Jekyll, but Jekyll, like other static site generators, seems to throw a lot of mess in the way of simple desires, as the parent comment articulates.
Jekyll was literally mentioned in the second sentence. You may have missed the point of the comment.
this is probably the best chance I'll get to plug this on HN:
https://github.com/mivanit/pandoc-sitegen
It's a truly dead simple static site generator that uses pandoc to turn the markdown into HTML, and mustache as the templating language. It's about 400 lines of actual code total. It doesn't include an actual server, it just converts your markdown files into HTML. It's by no means finished but I use it for my personal website.
It's a truly dead simple static site generator that uses pandoc to turn the markdown into HTML, and mustache as the templating language. It's about 400 lines of actual code total. It doesn't include an actual server, it just converts your markdown files into HTML. It's by no means finished but I use it for my personal website.
Perhaps try picking a simpler SSG like Pollen or Pelican? I've been fairly happy with the latter.
I've found it hard to resist the conclusion that "Hugo sux".
You get out of it what you put in to it, so to speak.
It is very easy to over complicate things but it is also easy to use it for lightning fast static page generation focusing only on letting it manage the head and global page structure.
It is very easy to over complicate things but it is also easy to use it for lightning fast static page generation focusing only on letting it manage the head and global page structure.
I put quite a bit into a project with Hugo and haven't gotten anything out yet.
I expect to try at least one other static site generator before that project is done. To be fair I am very interested in a Python-based generator because I have a whole lot of visualization code in Python that could be cut-n-pasted into one.
I expect to try at least one other static site generator before that project is done. To be fair I am very interested in a Python-based generator because I have a whole lot of visualization code in Python that could be cut-n-pasted into one.
HTML as an authoring language is underrated, but several commenters are confusing "writing HTML" with the aesthetic of nearly unstyled HTML. I think this is happening because the post we're discussing is not itself an example of what the author is describing: it's authored in DWikiText.
An example (that I maintain) of what the author describes: https://www.bidadance.org. Each of the pages is just plain HTML on disk.
An example (that I maintain) of what the author describes: https://www.bidadance.org. Each of the pages is just plain HTML on disk.
It's not like the post is unclear that it's talking about a site other than itself. People just can't read good.
Looking at the article's source and then yours, I see no correlation. The author is clearly talking about authoring in html without any tooling, whereas yours clearly has a tooled event list. It's not an article taking about whether external files are used. In fact, the article talks how they style it to match their wiki, & that the article is not authored in DWikiText at all.
Edit: you cheated by changing uri. The point still stands for your home page
Edit: you cheated by changing uri. The point still stands for your home page
Sorry, I put the URL back to the root of the site. (I'd changed it to a page that I thought better illustrated this approach.)
The events list is created with JS, yes. But that's the only thing on the whole site (~25 pages) that works that way.
Here's another site I maintain this way where the events list is plain HTML: https://www.kingfisherband.com
The events list is created with JS, yes. But that's the only thing on the whole site (~25 pages) that works that way.
Here's another site I maintain this way where the events list is plain HTML: https://www.kingfisherband.com
Why aren't any of the paragraph tags closed?
Because it's unnecessary in html5, just like closing li, td, tr tags. When you use implicit tags (body, header, etc) and auto-closing tags (li, p, tr, td,...) then html becomes refreshingly lean and human-editable.
EDIT: for a nice summary, look at google's html style guide. Section 3.1.7 is particularly neat [0].
[0] https://google.github.io/styleguide/htmlcssguide.html#Option...
EDIT: for a nice summary, look at google's html style guide. Section 3.1.7 is particularly neat [0].
[0] https://google.github.io/styleguide/htmlcssguide.html#Option...
Just to clarify, HTML5 didn't introduce this, it's been the case since at least 1993.
https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
Before HTML5 it was common to hear things like "technically you don't need it, but it's not to spec so don't do it".
Browsers literally would not render with one tiny syntax error/spec-deviation in your HTML
No different than having a JSX syntax error in React today
No different than having a JSX syntax error in React today
In XHTML strict mode, which basically nobody used.
In XHTML transitional, and HTML1-4, what you'd get is browsers with divergent understandings of your DOM tree structure such that content that worked fine in one would be a horribly mangled mess (often breaking layout in difficult to read ways) in another browser.
In XHTML transitional, and HTML1-4, what you'd get is browsers with divergent understandings of your DOM tree structure such that content that worked fine in one would be a horribly mangled mess (often breaking layout in difficult to read ways) in another browser.
Some of us tried XHTML. A little bit of extra consistency in syntax and closed tags was rewarded with being able to use tooling built around XML expectations. I dug that.
And then I found out there were some browsers that wouldn't handle it right unless content-type headers were set up right on the server, and of course that made it an extra pain, especially on commodity hosting where you might not have that remotely under your control.
The "strict warnings"/"rendering problems crash the page" setting was also... mixed. Certainly prompted you to pinpoint the issue and fix it but that level of nag often felt unnecessarily militant after what everyone was used to.
And then I found out there were some browsers that wouldn't handle it right unless content-type headers were set up right on the server, and of course that made it an extra pain, especially on commodity hosting where you might not have that remotely under your control.
The "strict warnings"/"rendering problems crash the page" setting was also... mixed. Certainly prompted you to pinpoint the issue and fix it but that level of nag often felt unnecessarily militant after what everyone was used to.
Probably mostly a casualty of that window when people were trying to make XHTML happen, so all the SGML-isms like omitted close tags became verboten.
Well, then they were wrong, because it's always been part of every HTML spec.
Perhaps they were thinking of XHTML, which did require all tags because it was based on XML.
Perhaps they were thinking of XHTML, which did require all tags because it was based on XML.
I believe before html5 they weren't required, but what the parsed DOM tree looked like wasn't clearly defined if they weren't, and in practice different browsers did it differently meaning you could very easily end up with it rendering differently in different browsers. html5 fixed that.
This is not correct. What you’re describing sounds like how HTML5 standardized parsing of invalid HTML, but that is not the same thing as implicit closing tags, which have have always been valid, correct HTML producing an unambiguous, clearly defined result.
Oh, for sure, actually parsing HTML was awful before HTML5. The spec sometimes diverged from how browsers actually interpreted HTML, and error correction basically boiled down to browsers trying to reverse-engineer each other to figure out how they handled broken HTML. HTML5 was a godsend for actually standardizing all of that.
I don’t understand how they are optional.
<p>Qed.
<img src=“some_image.jpg”>
And
<p>Qed.</p>
<img src=“some_image.jpg”>
Are going to give me different results.
<p>Qed.
<img src=“some_image.jpg”>
And
<p>Qed.</p>
<img src=“some_image.jpg”>
Are going to give me different results.
Yes, that is a case where it's not legal to omit `</p>` if you don't want the image to be inside the paragraph. Take a look at the spec[1], which outlines exactly when it is valid to omit tags.
The `p` element in particular has pretty scary rules, but it basically boils down to "if it doesn't make sense for this to be inside a paragraph (usually because it's a block element of some kind), it ends the paragraph."
[1] https://html.spec.whatwg.org/multipage/syntax.html#optional-...
The `p` element in particular has pretty scary rules, but it basically boils down to "if it doesn't make sense for this to be inside a paragraph (usually because it's a block element of some kind), it ends the paragraph."
[1] https://html.spec.whatwg.org/multipage/syntax.html#optional-...
It's are "optional" in the sense that the spec says it's optional and defines what that means: "A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element."
LOL. So I can memorize or check that list every time I'm using a p tag (and, of course, I'm relying on someone not doing something like changing the display property of a block element to inline), or... I can just use a closing p tag. I know which one is infinitely easier for me.
The way tag inference is expressed in the HTML 5 spec is the problem here. What the HTML spec says is just a verbose description of SGML tag inference, by explicitly listing all elements that can't appear in a paragraph.
Citing from [1]:
Earlier [SGML] HTML DTDs included the following definition for flow capturing this in a rather straightforward way:
Nesting of phrasing into flow elements is about the most basic property of the HTML grammar. In SGML, the flow/phrasing hierarchy is expressed by declaring the content model of flow elements as allowing %phrasing;, where %phrasing;, like in earlier HTML DTDs, is substituted into a string such as a|abbr|... containing all phrasing elements as a name group.
For example, the element declaration for the p element is as follows:
- the content of p elements can be any sequence of text content (#PCDATA) and phrasing elements, and
- flow content isn't just forbidden in direct child content of p (via admitting %phrasing; elements only), but also isn't admitted anywhere in descendant content of p, as expressed by the -(%flow_only;) SGML exclusion exception, and
- the end-element, but not the start-element tag of p can be omitted, as declared in ps tag omission indicator - O
where the flow_only parameter entity contains block-level elements as described above, ie. flow elements that aren't also phrasing elements.
[1]: http://sgmljs.net/docs/html5.html
Citing from [1]:
Earlier [SGML] HTML DTDs included the following definition for flow capturing this in a rather straightforward way:
<!ENTITY % flow "%block; | %inline;">
Nesting of phrasing into flow elements is about the most basic property of the HTML grammar. In SGML, the flow/phrasing hierarchy is expressed by declaring the content model of flow elements as allowing %phrasing;, where %phrasing;, like in earlier HTML DTDs, is substituted into a string such as a|abbr|... containing all phrasing elements as a name group.
For example, the element declaration for the p element is as follows:
<!ELEMENT p - O
(#PCDATA|%phrasing;)*
-(%flow_only;)>
- the content of p elements can be any sequence of text content (#PCDATA) and phrasing elements, and
- flow content isn't just forbidden in direct child content of p (via admitting %phrasing; elements only), but also isn't admitted anywhere in descendant content of p, as expressed by the -(%flow_only;) SGML exclusion exception, and
- the end-element, but not the start-element tag of p can be omitted, as declared in ps tag omission indicator - O
where the flow_only parameter entity contains block-level elements as described above, ie. flow elements that aren't also phrasing elements.
[1]: http://sgmljs.net/docs/html5.html
You can memorize the list, but it's easier than that: things that can go in a paragraph (which includes images) let the <p> continue, while things that can't (which is the long list there) close the <p>. In practice you get used to it very quickly.
I mentioned "block elements" in my other comment, but to be clear, CSS has no effect on how HTML is parsed, so the display property isn't relevant here.
Furthermore, you need to know about this rule even if you do write `</p>`. If you write this:
Furthermore, you need to know about this rule even if you do write `</p>`. If you write this:
<p>
<div>hello</div>
</p>
<p>
</p><div>hello</div>
</p>
Do browsers actually do that?
They can't produce imbalanced tags because it's impossible to represent in a DOM tree.
They will indeed auto close the (first) paragraph, and also auto open a new <p> element because of the extra closing </p> tag.
Try it out by typing this in your address bar and open the inspector:
edit: sorry niconii, I edited my comment under your feet.
They will indeed auto close the (first) paragraph, and also auto open a new <p> element because of the extra closing </p> tag.
Try it out by typing this in your address bar and open the inspector:
data:text/html;charset=utf-8,<!DOCTYPE html><p><div>hello</div></p>
<head></head><body><p></p><div>hello</div><p></p></body>
edit: sorry niconii, I edited my comment under your feet.
Just to add to this, HTML parsers will attempt to make sense of any random line noise you give it and turn it into a DOM. When I say something is "invalid" HTML, what I mean is that it's not allowed by the spec and will result in an error if you run it through a validator (which you should do!)
For example, try running the following document through the W3C's HTML validator[1]:
[1] https://validator.w3.org/nu/#textarea
[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
For example, try running the following document through the W3C's HTML validator[1]:
<!DOCTYPE html>
<html lang=en>
<title>Test Document</title>
<p>
<div></div>
</p>
[1] https://validator.w3.org/nu/#textarea
[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
It is allowed by the spec afaik (the spec precisely tells browsers how to interpret this, so everything is perfectly specified in the spec boundaries - and so it's not "out of spec").
Of course, that screams "MISTAKE" that a validator should warn you about. Like a linter that would spot missing extra parentheses for an assignment in a if condition in C-like language. It is allowed to not put the parentheses, but it is recommended to put them.
And of course, that makes "Valid HTML" (almost?) redundant (There are probably "vocabulary" errors that are possible, like a missing src attribute for an img or a missing title tag in head - don't take my words on this though).
div in p is not invalid, it's outright impossible to obtain from HTML parsing.
You can obtain this by doing this in JavaScript:
Of course, that screams "MISTAKE" that a validator should warn you about. Like a linter that would spot missing extra parentheses for an assignment in a if condition in C-like language. It is allowed to not put the parentheses, but it is recommended to put them.
And of course, that makes "Valid HTML" (almost?) redundant (There are probably "vocabulary" errors that are possible, like a missing src attribute for an img or a missing title tag in head - don't take my words on this though).
div in p is not invalid, it's outright impossible to obtain from HTML parsing.
You can obtain this by doing this in JavaScript:
document.body.appendChild(document.createElement("p"));
document.body.firstChild.appendChild(document.createElement("div")))
data:application/xhtml+xml;charset=utf-8,<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"><head><title>Hello</title></head><body><p><div></div></p></body></html>
document.body.innerHTML
<p xmlns="http://www.w3.org/1999/xhtml"><div/></p>
This is not quite right. The HTML spec specifies not only what browsers/user agents are allowed to do, but also what document authors are allowed to do.
While the HTML parser does handle errors, to conform to the spec, document authors must not make these errors.
Here is an excerpt from the spec[1]:
> As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
Furthermore, a user agent is not required to correct errors, and can simply halt at the first error[2]:
> The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.
[1] https://html.spec.whatwg.org/multipage/introduction.html#how...
[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
While the HTML parser does handle errors, to conform to the spec, document authors must not make these errors.
Here is an excerpt from the spec[1]:
> As described in the conformance requirements section below, this specification describes conformance criteria for a variety of conformance classes. In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
Furthermore, a user agent is not required to correct errors, and can simply halt at the first error[2]:
> The error handling for parse errors is well-defined (that's the processing rules described throughout this specification), but user agents, while parsing an HTML document, may abort the parser at the first parse error that they encounter for which they do not wish to apply the rules described in this specification.
[1] https://html.spec.whatwg.org/multipage/introduction.html#how...
[2] https://html.spec.whatwg.org/multipage/parsing.html#parse-er...
I can't believe the committee approved this spec without consulting me. I can see that I'm not the only one that feels this degree of agency in syntax is a bridge too far. Clearly this part of the spec was written by a Ruby developer.
The specification is just codifying what browsers already did in practice.
There was a time when people thought we might be able to change web development practice and browsers to something more consistent, but (a) what they chose was XHTML and (b) the benefit of switching was not there.
There was a time when people thought we might be able to change web development practice and browsers to something more consistent, but (a) what they chose was XHTML and (b) the benefit of switching was not there.
Okay, I've gotten a bit carried away with HTML spec minutia elsewhere in these comments, mainly because this stuff really isn't common knowledge among web developers and it's hard to resist talking about it.
However, I also want to add to the other point here; namely, "why do this in the first place?"
Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit.
For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples):
On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)
However, I also want to add to the other point here; namely, "why do this in the first place?"
Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit.
For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples):
<table>
<tr><th>sample rate</th> <th>data rate</th> <th>max length</th></tr>
<tr><td>32000 Hz</td> <td>18000 byte/s</td> <td> ~3.641 s</td></tr>
<tr><td>16000 Hz</td> <td> 9000 byte/s</td> <td> ~7.282 s</td></tr>
<tr><td> 8000 Hz</td> <td> 4500 byte/s</td> <td>~14.564 s</td></tr>
</table>
<table>
<tr><th>sample rate <th>data rate <th>max length
<tr><td>32000 Hz <td>18000 byte/s <td> ~3.641 s
<tr><td>16000 Hz <td> 9000 byte/s <td> ~7.282 s
<tr><td> 8000 Hz <td> 4500 byte/s <td>~14.564 s
</table>
On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)
How likely is it that a dev would be reading an HTML table with hardcoded data in the code editor in this day and age?
Today, data tables are mostly dynamically generated, probably via accessing an API endpoint of some sort. The dev would at most write a function that would output the data inside a <table> element. But the table data itself would only be visible in the browser, it wouldn't be hardcoded into the HTML markup.
Today, data tables are mostly dynamically generated, probably via accessing an API endpoint of some sort. The dev would at most write a function that would output the data inside a <table> element. But the table data itself would only be visible in the browser, it wouldn't be hardcoded into the HTML markup.
If you're following the advice of the post, and using HTML as your authoring format, this is pretty common. I do it a lot on my blog.
It's similar to how often you see tables in Markdown.
It's similar to how often you see tables in Markdown.
Even the official Markdown guide suggests using a table generator because the markup is a hassle:
https://www.markdownguide.org/extended-syntax/
HTML tables are similarly cumbersome, with or without closing tags. If you have a table of static information to fill in, copy/pasting from Excel into a HTML table generator and pasting the output is signficantly faster.
https://www.markdownguide.org/extended-syntax/
HTML tables are similarly cumbersome, with or without closing tags. If you have a table of static information to fill in, copy/pasting from Excel into a HTML table generator and pasting the output is signficantly faster.
Markdown is suggesting using a generator for writing, but you were saying it was unlikely that someone would be reading a table in source.
I'd also much rather write an HTML table by hand than a markdown one.
I'd also much rather write an HTML table by hand than a markdown one.
What is your point? Even if it is a rare occurrence, from time to time you might want to output an html table using "print", and it will be slightly more comfortable that way. I sometimes find myself editing html by hand. Thanks to the optional and auto-closing tags it is just as easy as markdown, and you don't need an extra conversion step.
The verbose format has no advantage whatsoever, unless you are doing weird xml stuff.
The verbose format has no advantage whatsoever, unless you are doing weird xml stuff.
[deleted]
Using JS to insert headers and footers already makes them non-plain HTML pages. This is just trading one set of issues for another.
100% this, there's no good reason to do this in JS.
Apache has supported Server Side Includes forever. All you need to do is drop an 'include' in your HTML file and Apache will inject the contents in the right place.
https://httpd.apache.org/docs/current/howto/ssi.html
Edit:
IIS: https://docs.microsoft.com/en-us/iis/configuration/system.we...
Lighttpd: https://redmine.lighttpd.net/projects/1/wiki/docs_modssi
Nginx: https://nginx.org/en/docs/http/ngx_http_ssi_module.html
Tomcat: https://tomcat.apache.org/tomcat-7.0-doc/ssi-howto.html
Jigsaw: https://www.w3.org/Jigsaw/Doc/User/SSI.html
Apache has supported Server Side Includes forever. All you need to do is drop an 'include' in your HTML file and Apache will inject the contents in the right place.
<!--#include virtual="/header.html" -->
https://httpd.apache.org/docs/current/howto/ssi.html
Edit:
IIS: https://docs.microsoft.com/en-us/iis/configuration/system.we...
Lighttpd: https://redmine.lighttpd.net/projects/1/wiki/docs_modssi
Nginx: https://nginx.org/en/docs/http/ngx_http_ssi_module.html
Tomcat: https://tomcat.apache.org/tomcat-7.0-doc/ssi-howto.html
Jigsaw: https://www.w3.org/Jigsaw/Doc/User/SSI.html
The benefit of their approach is that they can drop the files into basically any server, and the site will work. Seems like a good tradeoff for the sort of concerns they have.
Upvote for Apache Server Side Includes. Two years ago I was tasked with redesigning an important informational website that never got the proper attention because all devs were occupied with maintaining the different web application stacks. I wanted something future-proof that an intern could update, basically straight HTML and minimal CSS. I replaced anything that would normally use PHP (and in some cases JavaScript) with stuff built in to Apache. It's cool that Apache also supports conditionals.
I mean, that's all cool, except now the next person needs to know (or learn) Apache directives. I would assume that intern is more likely to know PHP or JS. This solution is a compromise at best, and to me it doesn't sound like Apache is a good choice here (granted, there could be other circumstances I am not aware of).
If I received your code I would start by rolling my eyes, then by wasting some time learning Yet Another Technology (TM) that I will likely forget before the next time it comes handy.
In my experience, if you care about maintenance, one should stick to the worn path unless they have a good reason not to.
> It's cool that Apache also supports conditionals.
<...shudders...>
If I received your code I would start by rolling my eyes, then by wasting some time learning Yet Another Technology (TM) that I will likely forget before the next time it comes handy.
In my experience, if you care about maintenance, one should stick to the worn path unless they have a good reason not to.
> It's cool that Apache also supports conditionals.
<...shudders...>
Apache was just used as an example but the most popular web servers all support SSI.
I wouldn't suggest using it for anything complex but it's ideal for inserting common headers and footers into static HTML.
Plus, it's using fewer technologies than anything you suggest. Less to maintain, less to go wrong. Sounds like a winner.
I wouldn't suggest using it for anything complex but it's ideal for inserting common headers and footers into static HTML.
Plus, it's using fewer technologies than anything you suggest. Less to maintain, less to go wrong. Sounds like a winner.
It does in some cases, just not for the reasons stated (imho of course).
(didn't downvote you - I actually appreciate your sharing of your point of view)
(didn't downvote you - I actually appreciate your sharing of your point of view)
I wish this functionality was part of standard HTML.
Indeed, xinclude would be great. Combine that with an HTML-based and declarative web-component solution and it would go a long way to reducing the need for scripting on basic websites.
You mostly just described XSL. There's a ton of templating XSL can do "for free" in the browser with no JavaScript.
Yes, I was a big fan of XSL. Too bad it didn't catch on.
Sure, but it's about as far from user/dev friendly as it gets. I recently had to make a standalone FAQ-style page and got the idea to use XSL to render it from an XML file (since you can teach any semi-literate person how to write XML in like 5 minutes). Firstly, XSL is so much weirder than any templating engine we're used to, that it took me stupidly long to do the most basic things. Then it turns out, browsers don't include default styles in XSL-rendered documents (no headings, no lists, nothing!), so I had to style it completely from scratch.
Everything in the XML "ecosystem" (XSL, XPath, XDT, SOAP) is so unfriendly that I'm no longer surprised everyone is reinventing these concepts in (unfortunately) JSON these days.
Everything in the XML "ecosystem" (XSL, XPath, XDT, SOAP) is so unfriendly that I'm no longer surprised everyone is reinventing these concepts in (unfortunately) JSON these days.
XSD (XML Schema Definition) is pretty good though, and it makes autocomplete and spotting errors when hand-writing XML files very easy.
I’ve messed around with generating SVG classes in python and C++ using the XSD schema and while it is pretty good it falls flat on its face for anything complicated like SVG.
Resorted to using the DTD schema as it can support complex things (and that’s what they use for the probably never to be released updated version) through some python hackery to generate a hundred or more classes that takes forever to compile and, strangely enough, actually does what its supposed to do which is represent SVG as a bunch of classes with reading/writing to xml.
I was going through a phase and tried that with rss but it was more hassle than it was worth.
—edit—
Should add the DTD makes things like enums for tags or whatever simple so you can have typed values and property formed xml documents — can’t remember if I ever managed to get that working with the XSD.
Resorted to using the DTD schema as it can support complex things (and that’s what they use for the probably never to be released updated version) through some python hackery to generate a hundred or more classes that takes forever to compile and, strangely enough, actually does what its supposed to do which is represent SVG as a bunch of classes with reading/writing to xml.
I was going through a phase and tried that with rss but it was more hassle than it was worth.
—edit—
Should add the DTD makes things like enums for tags or whatever simple so you can have typed values and property formed xml documents — can’t remember if I ever managed to get that working with the XSD.
Frames are the closest thing HTML has to this
Frames trigger bad memories for some older devs for how they were abused but this is really the best way to do it. Doesn't depend on server modules for includes, and even text-mode browsers generally support frames (but many do not support JavaScript).
Except that frames cause issues with bookmarks or linking to specific pages from the outside.
An iframe with some CSS might however work to some degree.
An iframe with some CSS might however work to some degree.
transclusion
<iframe src='footer.html'>
Or you could use a frameset
Or you could use a frameset
Pandoc will create self-contained documents with the '-s' switch. It's also pretty easy to use a custom template as well. You can go from markdown (or asciidoc or whatever) to plain but templates HTML with a single command. You then have an HTML file you can stick anywhere.
Golang Templates also offer the ability to do this. I have an entire enterprise site built this way with separate header, footer, toolbar, search box, etc. And it’s silly fast too. We use AlpineJS for client side interactive bits. (edit: typos)
Rather than JS, one can use Caddy's built-in template engine [0] to include headers/footers server-side (but way more powerful than SSI):
[0]: https://caddyserver.com/docs/modules/http.handlers.templates
[1]: https://github.com/caddyserver/website/blob/master/src/docs/... <-- Try doing that with SSI
{{include "/includes/header.html"}}
[0]: https://caddyserver.com/docs/modules/http.handlers.templates
[1]: https://github.com/caddyserver/website/blob/master/src/docs/... <-- Try doing that with SSI
I love the way you've just reinvented PHP 1 (see https://en.wikipedia.org/wiki/PHP#Early_history).
That aside, Caddy is awesome, thanks for a great piece of software!
That aside, Caddy is awesome, thanks for a great piece of software!
I looked at the JS being loaded in the first place, and it's just two files: the entire JQuery package, and:
$(document).ready(function() {
$('nav').load('/nav.html');
});
I'm kind of wondering why JQuery is needed for that, but I'm not curious enough to dig into nav.html to see why. The navigation looks simple enough. An at-home static site generator that literally replaces a custom tag with the contents of a file using sed would take less maintenance it seems to me than keeping JQuery updated.
There is a modern fervor over tech minimalism/purism where using even a little bit of Javascript, for example, is just a reminder that perhaps the answer all along was to just to use the trade-offs that work for you.
Note, the people in the article were burned by wiki software that went unmaintained during its rewrite from Python 2.7 to Python 3 (afaict). Now they are editing HTML files on a production server. I'm sure getting let down like they did gave them a specific distaste for certain trade-offs that work for the rest of us, but you can also imagine the babies being thrown out with the bathwater like scaling out an article database without revision history.
That said, it tends to be a good thing when you realize a vastly simple solution works for you.
Note, the people in the article were burned by wiki software that went unmaintained during its rewrite from Python 2.7 to Python 3 (afaict). Now they are editing HTML files on a production server. I'm sure getting let down like they did gave them a specific distaste for certain trade-offs that work for the rest of us, but you can also imagine the babies being thrown out with the bathwater like scaling out an article database without revision history.
That said, it tends to be a good thing when you realize a vastly simple solution works for you.
Not just JavaScript, but AJAX using jQuery. Come on now.
I'm sympathetic to your view in favor of siplicity.
> I'm normally someone who's attracted to ideas like writing in a markup language instead of raw HTML and having some kind of templated, dynamic system (whether it's a wiki, a CMS, or a themed static site generator), as you can tell from Wandering Thoughts and DWiki itself.
Note that HTML is a markup language (an SGML application) and so is XHTML (an XML application).
If you meant by "a markup language" a user-friendly or domain-specific markup language, then there is good news: if you use XML as your markup (ideally by defining your own wiki's DTD, as simple or as sophisticated as you like) then you can associate an XLST transform "program" with it, and then a click on "view HTML" in the browser will display the underlying XML [sic], not as you would expect the generated XHTML, as the XHTML is generated from the XML on the fly only (not stored persistently anywhere, thus avoiding file clutter).
For example, you may like a structure like:
> I'm normally someone who's attracted to ideas like writing in a markup language instead of raw HTML and having some kind of templated, dynamic system (whether it's a wiki, a CMS, or a themed static site generator), as you can tell from Wandering Thoughts and DWiki itself.
Note that HTML is a markup language (an SGML application) and so is XHTML (an XML application).
If you meant by "a markup language" a user-friendly or domain-specific markup language, then there is good news: if you use XML as your markup (ideally by defining your own wiki's DTD, as simple or as sophisticated as you like) then you can associate an XLST transform "program" with it, and then a click on "view HTML" in the browser will display the underlying XML [sic], not as you would expect the generated XHTML, as the XHTML is generated from the XML on the fly only (not stored persistently anywhere, thus avoiding file clutter).
For example, you may like a structure like:
<docs>
...
<doc>
<title>...</title>
<text>...</text>
<keywords>...</keywords>
</doc>
...
</docs>
This is what happens when UNIX terminal users bring their anti-gui baggage to the web. He doesn't even use pure html he's got all kinds of dynamic stuff going on.
Advocate for simple and easy to read UI if you want but come on now.
Advocate for simple and easy to read UI if you want but come on now.
Honestly I feel these sorta of posts are just trolling for views. Hey if you wanna make your site feel like a '90s/Brutalist design throwback that's cool. But don't act like you're a more enlightened developer.
When you're just relying on browser defaults and there no basic styles to make the text readable. The pages are a challenge to understand. You can have plain html but using CSS to create some visual hierarchy would go a long way. Feels like there's two text sizes and two colors.
When you're just relying on browser defaults and there no basic styles to make the text readable. The pages are a challenge to understand. You can have plain html but using CSS to create some visual hierarchy would go a long way. Feels like there's two text sizes and two colors.
I'd say the author is one of the most respected tech bloggers out there.
With pure HTML and possibly some cleanly included JS he could get any visual appearance he wants, such as the common hero video or the effects you see where scrolling manifests differently as you scroll through different parts of the document.
With pure HTML and possibly some cleanly included JS he could get any visual appearance he wants, such as the common hero video or the effects you see where scrolling manifests differently as you scroll through different parts of the document.
You can be a good writer but none of that really changes the thrust of the parents point which, I think, is that: if you want easy upvotes on a site like this, you can just post some variation of "javascript bad, web 1.0 html good." If you can stretch this idea into 3 or more paragraphs, even if you say fundamentally nothing new that hasn't already been seen 100 times, you're virtually guaranteed to get a bunch of upvotes and "DAE?" comments about how epic of an approach it is.
In this case though, the author isn't submitting it, so it's not like they're the culprit. But even if they were it's also not really an indictment of any sort either; happens to everyone who writes online; it's the siren song of "engagement" with your work. (Lots of people here want to believe this site is somehow fundamentally different from Reddit or any other forum where "internet points" dictate the flow of content. It isn't; the tics and triggers are just different. Topics like this are a good example.)
> With pure HTML and possibly some cleanly included JS he could get any visual appearance he wants
With default browser font sizing and spacing? Yeah, sure, you can get any bad look you want from pure HTML and some JS. CSS is practically mandatory for webpage readability these days, but it's all a moot point since the OP doesn't seem to be arguing against CSS in any form anyway (and even literally admits he uses it.) Honestly the linked support site is mostly OK in this regard; though I'd blow up the font size a point/point-and-a-half more, add a tiny bit more line spacing, and make the margins bigger.
In this case though, the author isn't submitting it, so it's not like they're the culprit. But even if they were it's also not really an indictment of any sort either; happens to everyone who writes online; it's the siren song of "engagement" with your work. (Lots of people here want to believe this site is somehow fundamentally different from Reddit or any other forum where "internet points" dictate the flow of content. It isn't; the tics and triggers are just different. Topics like this are a good example.)
> With pure HTML and possibly some cleanly included JS he could get any visual appearance he wants
With default browser font sizing and spacing? Yeah, sure, you can get any bad look you want from pure HTML and some JS. CSS is practically mandatory for webpage readability these days, but it's all a moot point since the OP doesn't seem to be arguing against CSS in any form anyway (and even literally admits he uses it.) Honestly the linked support site is mostly OK in this regard; though I'd blow up the font size a point/point-and-a-half more, add a tiny bit more line spacing, and make the margins bigger.
> no basic styles to make the text readable
You mean dark grey text on light grey background?
Or a mobile stylesheet that displays one paragraph and half a photo on a 5k monitor and makes you scroll for the rest?
You mean dark grey text on light grey background?
Or a mobile stylesheet that displays one paragraph and half a photo on a 5k monitor and makes you scroll for the rest?
Only two CSS rules can enhance the readability a lot on my screen:
body { font-family: helvetica; line-height: 1.5; }That's the thing, the author here is using CSS and the hierarchy is still very poor and difficult to parse. It's the worst of both worlds.
The very short post says:
"our current support site [https://support.cs.toronto.edu/] is that most basic thing, a bunch of static .html files sitting in a filesystem (and a static file of CSS, and some Javascript to drop in a header on all pages)."
"our current support site [https://support.cs.toronto.edu/] is that most basic thing, a bunch of static .html files sitting in a filesystem (and a static file of CSS, and some Javascript to drop in a header on all pages)."
It's ironic you should call anything UNIX baggage since that whole website is a few kilobytes and renders instantly. As opposed to any 5MB JS-filled flaming cistern of a site a modern developer would make.
HTML comments to Stack Overflow pages? Display: table? Floats for layout?
That page is not an example of what the post is about: it's written with his Wiki software: https://utcc.utoronto.ca/~cks/space/dwiki/DWiki
At that point they might as well have hired it out to someone on fiverrr (not a dig at people who work fiverrr at all.)
GitHub pages seem to be about the simplest way to do this today - bringing the goodness of basic source control, simple issue management, and related.
Yup! I use Github pages as my "CMS" for my pure HTML static site (https://kolemcrae.com) works beautifully!
I have a fair number of sites on Github pages but I've ended up migrating most of them to Netlify (which is a very easy process) when I've needed more features, like wildcard ssl or multiple domains. Still haven't paid a cent!
for my sites that expect an occasional burst of traffic, I moved all the media assets to IPFS and served by one of the gateway that functions as CDN for IPFS stuff.
this circumvents Netlify's bandwidth metering and all the users retrieving the IPFS assets keeps the IPFS assets loading quickly
this circumvents Netlify's bandwidth metering and all the users retrieving the IPFS assets keeps the IPFS assets loading quickly
How did you do this? Is there a tutorial that you followed? I would love to do the same, potentially with Cloudflare further caching the IPFS-hosted files.
Although Pinata offers a SaaS service where you pay them monthly to pin and they charge for bandwidth, web3.storage lets you pin 1 Tib for free and without bandwidth metering. So I pinned there, and then got the hash and found the gateway+cdn with low ping time and just concatenate the url, which I hardcode in the frontend
note, I append ?filename=filename.extension to the url to keep track of which hash is what
ironically Pinata is also a gateway that will show any hash for free
then I just deploy the whole project/frontend/backend to github and that auto deploys to netlify and the domain name routes to that instance
note, I append ?filename=filename.extension to the url to keep track of which hash is what
ironically Pinata is also a gateway that will show any hash for free
then I just deploy the whole project/frontend/backend to github and that auto deploys to netlify and the domain name routes to that instance
Another lightweight github-based approach is to just link together a bunch of gists: https://gist.github.com/cellularmitosis/fdac60efe210d1cee263...
I like plain html pages for presentation too, but this writer is making a fundamental mistake. He keeps making it, as he vacillates between solutions.
He keeps mixing his data into his presentation of that data.
Keep your data however you like, plain text files in a simple directory structure, database, whatever. The important thing is, as much as possible, organize the data in a presentation neutral way.
Choose whatever programs you want to present that data, in whatever context. When you eventually tire of some of those solutions, if you've done things right, you will simply discard them and pick new ones to present your data in new ways.
As long as he continues to mix his data with it's presentation at the outset, he doesn't have data, he has a website, or a wiki, or whatever, and he'll keep having to solve the same problem.
He keeps mixing his data into his presentation of that data.
Keep your data however you like, plain text files in a simple directory structure, database, whatever. The important thing is, as much as possible, organize the data in a presentation neutral way.
Choose whatever programs you want to present that data, in whatever context. When you eventually tire of some of those solutions, if you've done things right, you will simply discard them and pick new ones to present your data in new ways.
As long as he continues to mix his data with it's presentation at the outset, he doesn't have data, he has a website, or a wiki, or whatever, and he'll keep having to solve the same problem.
I'm pretty sure that this is just a lower-strength version of "the wiki trap" mentioned in the article - if you write all of your pages in HTML, then they're going to stay HTML unless you invest the effort in writing a parser+translator that converts all of your content into Markdown or Wikitext or whatever else you might want to migrate that content into.
For instance, if you decide you want to give a templating language like Mustache a try - have fun programmatically extracting your content from those HTML pages and translating it into Mustache. Doable? Sure. Easy? Certainly not - and it's going to be very painful and manual if you didn't keep the same format for all of those HTML pages.
For instance, if you decide you want to give a templating language like Mustache a try - have fun programmatically extracting your content from those HTML pages and translating it into Mustache. Doable? Sure. Easy? Certainly not - and it's going to be very painful and manual if you didn't keep the same format for all of those HTML pages.
> if you write all of your pages in HTML, then they're going to stay HTML unless you invest the effort in writing a parser+translator that converts all of your content into Markdown or Wikitext
That can be a problem the other way around as well. I wanted to convert a Mediawiki-based site to static HTML pages, but ultimately gave up and instead updated to a recent version of Mediawiki, because I couldn't find a solution which would've kept all existing URLs working.
That can be a problem the other way around as well. I wanted to convert a Mediawiki-based site to static HTML pages, but ultimately gave up and instead updated to a recent version of Mediawiki, because I couldn't find a solution which would've kept all existing URLs working.
> if you write all of your pages in HTML, then they're going to stay HTML unless you invest the effort in writing a parser+translator that converts all of your content into Markdown or Wikitext or whatever else you might want to migrate that content into.
The designed virtue of Markdown is its ease of authoring; why would you want to convert to it? It's surely easier to convert directly from HTML to whatever other format you want than from Markdown to that format.
The designed virtue of Markdown is its ease of authoring; why would you want to convert to it? It's surely easier to convert directly from HTML to whatever other format you want than from Markdown to that format.
Because you're migrating a living document.
These days, it's easy to type your markdown into a text area and then use a JS library to convert it to html. If they're already loading Javascript, all they'd have to do is insert the necessary Javascript in there. No need to write any html.
I always thought there was more potential in HTML than gets realized
https://ontology2.com/the-book/html5-the-official-document-l...
but practically it never happens. So we get stuck with languages like markdown, restructured text and various sorts of wiki markup. Just about everybody who gets serious about extracting data from Wikipedia learns the hard way that parsing wikimedia markup is possible to get 90% right with a lot of suffering but if you have a DOM-intelligent HTML parser often you can get 99.95% right with 2 minutes of work parsing the HTML.
(The reason why is that people look at HTML and fix the markup until the HTML looks right, they don't look to see that the markup is conformant to any spec.)
For a long time I've wanted to like Dreamweaver and it didn't seem so bad in 2003 but today I type a few characters into the live view and then I can go on vacation and the characters might have appeared a week later. You'd think every HTML editor that is embedded in HTML was developed by a sadist except that it seems there is a basic conceptual problem that makes WYSIWYG HTML editing completely impractical.
https://ontology2.com/the-book/html5-the-official-document-l...
but practically it never happens. So we get stuck with languages like markdown, restructured text and various sorts of wiki markup. Just about everybody who gets serious about extracting data from Wikipedia learns the hard way that parsing wikimedia markup is possible to get 90% right with a lot of suffering but if you have a DOM-intelligent HTML parser often you can get 99.95% right with 2 minutes of work parsing the HTML.
(The reason why is that people look at HTML and fix the markup until the HTML looks right, they don't look to see that the markup is conformant to any spec.)
For a long time I've wanted to like Dreamweaver and it didn't seem so bad in 2003 but today I type a few characters into the live view and then I can go on vacation and the characters might have appeared a week later. You'd think every HTML editor that is embedded in HTML was developed by a sadist except that it seems there is a basic conceptual problem that makes WYSIWYG HTML editing completely impractical.
<p>I think writing in HTML is <em>very</em> frustrating. It can be particularly difficult to write it on a mobile device due to lack of easy access to special symbols.</p>
On the flip side, last time I wrote some in an editor with decent HTML-authoring autocomplete, it was so fast I wondered why we bother with weird compile-to-HTML templating languages anymore. It wasn't really any slower than writing Pug or whatever, and the result IMO was more readable.
Let's face it, mobile devices are primarily for consuming, not producing.
What’s more frustrating, writing in HTML or writing in a more concise format and having to maintain some build pipeline?
I guess the answer depends on many factors; personal preferences and also the project’s context play a big role; personally I’m surprised how often I choose <em>HTML</em>.
I guess the answer depends on many factors; personal preferences and also the project’s context play a big role; personally I’m surprised how often I choose <em>HTML</em>.
Markdown is probably a happy medium - markdown itself looks pretty much like normal writing in usenet or email, just formatted visually, and the 'build pipeline' is something like "markdown foo.md > foo.html"
>It can be particularly difficult to write it on a mobile device due to lack of easy access to special symbols.
I'm assuming this excludes laptops, so we're talking tablets/smartphones? If so, out of curiosity, how often are you writing code on a smart phone/tablet? I've never written a line of any code on anything other than a laptop (when travelling) or desktop.
I'm assuming this excludes laptops, so we're talking tablets/smartphones? If so, out of curiosity, how often are you writing code on a smart phone/tablet? I've never written a line of any code on anything other than a laptop (when travelling) or desktop.
Sometimes this is a good thing. Makes you stop. Sit down. Activates your analytical mind.
Mobile's deficiencies in UI and networking were bad enough when they were just mobile's problem. But now people just assume everything should be gimped so that mobile can keep up.
I'm sure there are 3rd party keyboards that optimize for different use cases, such as angle braces and double quotes.
I've used htp (https://sourceforge.net/projects/htp/) to manage what are essentially HTML-only web sites. It provides the ability to use "include" files and macros, which allow me to give all the pages a consistent look and feel that can be easily changed. I usually create a simple makefile so that all the HTML files can be updated as necessary whenever the source files change.
Good old m4 can get you pretty far, as a template system for generating html.
Reference with tutorial here: http://htp.sourceforge.net/ref/
One selling point is that it only uses regular HTML syntax, so no need for dedicated syntax highlighting. Development seems to have stopped though since 2015.
One selling point is that it only uses regular HTML syntax, so no need for dedicated syntax highlighting. Development seems to have stopped though since 2015.
I LOVE static html sites. I fell in love with https://surge.sh/ when I first started making sites, and now for the most part just host everything on GitHub or GitLab pages depending.
I also love Vue and the simplicity of remote html resources/dependencies for simple sites. I created a single html file VueJS template that has a bunch of resources out of the box for things that I commonly want if I want to create a quick simple site.
Check it out -> https://vue-template.spaghet.me
The beauty of the site is its basically a quine. You can get started by just running: curl https://vue-template.spaghet.me -o index.html
I also love Vue and the simplicity of remote html resources/dependencies for simple sites. I created a single html file VueJS template that has a bunch of resources out of the box for things that I commonly want if I want to create a quick simple site.
Check it out -> https://vue-template.spaghet.me
The beauty of the site is its basically a quine. You can get started by just running: curl https://vue-template.spaghet.me -o index.html
Just curious - why does your template include web3.js? Do you end up using that on tons of quick simple sites, and if so, what for?
That is leftover from another template, I actually meant to remove it!
---
I have created a few NFT / Web3 pages using that template. For the most part, a lot of Web3 UIs are just client side sites that connect to on-chain data, so another super lean use-case for simple HTML pages.
---
I have created a few NFT / Web3 pages using that template. For the most part, a lot of Web3 UIs are just client side sites that connect to on-chain data, so another super lean use-case for simple HTML pages.
I love plain HTML. The chief problem I have with it is just dealing with templates--stuff like navigation. Lots of other people have the same problem. So they add some simple templating system, where they stick some text around the HTML. Ok, and then they want to automatically generate navigation, maybe add a few other features here and there. Add width/height to <img>, syntax highlighting for code snippets, etc.
It's really easy for this kind of endeavor to get out of hand. The hardest part of plain HTML is sticking with it and writing just enough automation to keep you sane.
It's also far too easy to get sloppy when working on something that does some basic preprocessing. My personal preference is to keep the pages as HTML, and write a processor that does minor modifications to the HTML DOM, using a proper HTML5 library.
If done carefully, you can keep the experience close to the experience of editing pure HTML. For example, rather than some custom "shortcodes", you can use custom HTML elements. Custom HTML elements are a more verbose, but come with major advantages over terser shortcodes (use existing tooling, you don't need a parser). You can do simple stuff like automatically add alt="" or srcset="" to your <img> based on image metadata, or automatically generate breadcrumbs using site structure.
The general idea is to keep it as close to plain HTML as possible. If possible, make it so the page is plain HTML.
It's really easy for this kind of endeavor to get out of hand. The hardest part of plain HTML is sticking with it and writing just enough automation to keep you sane.
It's also far too easy to get sloppy when working on something that does some basic preprocessing. My personal preference is to keep the pages as HTML, and write a processor that does minor modifications to the HTML DOM, using a proper HTML5 library.
If done carefully, you can keep the experience close to the experience of editing pure HTML. For example, rather than some custom "shortcodes", you can use custom HTML elements. Custom HTML elements are a more verbose, but come with major advantages over terser shortcodes (use existing tooling, you don't need a parser). You can do simple stuff like automatically add alt="" or srcset="" to your <img> based on image metadata, or automatically generate breadcrumbs using site structure.
The general idea is to keep it as close to plain HTML as possible. If possible, make it so the page is plain HTML.
I adore plain HTML but their lack of any versioning seems silly to me. It's so easy to use (for instance) git to sync changes back and forth that eschewing it from the process just seems unnecessarily dangerous. Throw it all in source control (and maybe if you're using git create a public github repo) and you've got a free backup along with a safer way to edit the files. Considering it's all plain HTML local edits can be trivially vetted by just opening .html files in browsers or, for the more advanced, taking five seconds to download an appropriate WAMP/MAMP/LAMP binary that sets up apache and some crap you don't need - then just move your source dir into whatever their public_html is called.
It is so so trivial to vet local HTML changes and use a repository where you just directly push to master that I'd suggest it to anyone building a plain HTML site just for the fact that you're getting free backups as a side effect.
It is so so trivial to vet local HTML changes and use a repository where you just directly push to master that I'd suggest it to anyone building a plain HTML site just for the fact that you're getting free backups as a side effect.
Alternatively, they could just throw an rsync one-liner into a crontab and slurp down a backup copy of the files once per day, in case they make a mistake. This optimizes for the common case (the days where you don't make a mistake) and removes the requirement that everyone on the team needs to know git.
In the article they mention they're generally using vi for editing. The learning barrier for git is so much lower than vi.
Git, when used without branches and merges, is really dead simple.
Git, when used without branches and merges, is really dead simple.
Just one caveat: you might need to make sure the .git directory isn’t publicly accessible via the web server.
I guess though to be honest there isn't any privileged information stored in there to my knowledge? It's just historical information which you're probably going to end up publicly exposing on github anyways.
For a personal blog, I really see no reason to not just use Github/lab pages. You get free hosting, https, version control, automatic deployment, etc. It all just works so well that there is no point hosting it on your own server.
After getting frustrated with SSG, I evaluated a few options. SSGs usually begin as niche products and then add more features and become bloated with them. Ultimately, they have so many bells and whistles I don't need that it's not worth dealing with them.
I wanted something simple e.g. based on pandoc. I have also tried writing posts in pure HTML. HTML has lots of advantages, but when you have to read your own stuff, it's not very pretty. Markdown brings more clarity to your documents and also allows you to embed HTML.
I have used Sergey [1] to create some basic HTML templates, but it is not as pleasant to use as Markdown. Also, generating RSS and creating archives are problematic. This should be automated.
I decided to use Blot [2]. I am not familiar with the author, but I think it is a good tiny product worth recommending. It will turn any document into a page. You can create an HTML page and it will be embedded into your template. The author appears to be nice [3]. The code is open source.
[1]: https://sergey.cool/ [2]: https://blot.im/ [3]: https://blot.im/about/notes/politics
I wanted something simple e.g. based on pandoc. I have also tried writing posts in pure HTML. HTML has lots of advantages, but when you have to read your own stuff, it's not very pretty. Markdown brings more clarity to your documents and also allows you to embed HTML.
I have used Sergey [1] to create some basic HTML templates, but it is not as pleasant to use as Markdown. Also, generating RSS and creating archives are problematic. This should be automated.
I decided to use Blot [2]. I am not familiar with the author, but I think it is a good tiny product worth recommending. It will turn any document into a page. You can create an HTML page and it will be embedded into your template. The author appears to be nice [3]. The code is open source.
[1]: https://sergey.cool/ [2]: https://blot.im/ [3]: https://blot.im/about/notes/politics
I wrote about static HTML sites in "My stacks will outlive yours": https://blog.steren.fr/2020/my-stack-will-outlive-yours/
Something I've experimented with is web templating systems that are HTML 5 native, that is, you parse documents to the DOM, process them in the DOM, then serialize them to the disk (like Hugo) or the web browser.
For instance the "template" of your web site might be an HTML document that has something like
It's not that hard but I think it's never caught on for a few reasons.
One of them is that DOM parsing and unparsing is an order of magnitude or two slower than text-based templating sytems. I guess you could parse the template once and cache it but it's still going to be slow.
Another is that you run into "hygenic macro" problems if you want to merge random DOM trees into each other: for instance you could have multiple elements with the same id, the same classes used for different meanings in some other places. You need some answer to this if you want to make something scalable (e.g. the whole point of this exercise is that you should be able to transclude HTML + CSS from anywhere and have it "just work")
Finally it would be really nice to have a reliable WYSIWYG HTML editor, particularly one that would help you use CSS classes in a disciplined way to customize the system to add whatever markup features you want for your site.
It doesn't exist and I wonder why. Every HTML editor I've seen is just garbage. Latency for typing characters is several round trips to the moon. Navigation, selection, where characters appear when I type all seem to be random, like my computer is possessed by the devil.
(It's a general problem w/ most WYSIWYG editors that look like MS Word, including MS Word. I'm sure there is something conceptually wrong with the model which is why all those editors are buggy, but it seems everybody else thinks it is OK for selection, navigation and where you type characters to be random.)
For instance the "template" of your web site might be an HTML document that has something like
<div id="content"/>
It's not that hard but I think it's never caught on for a few reasons.
One of them is that DOM parsing and unparsing is an order of magnitude or two slower than text-based templating sytems. I guess you could parse the template once and cache it but it's still going to be slow.
Another is that you run into "hygenic macro" problems if you want to merge random DOM trees into each other: for instance you could have multiple elements with the same id, the same classes used for different meanings in some other places. You need some answer to this if you want to make something scalable (e.g. the whole point of this exercise is that you should be able to transclude HTML + CSS from anywhere and have it "just work")
Finally it would be really nice to have a reliable WYSIWYG HTML editor, particularly one that would help you use CSS classes in a disciplined way to customize the system to add whatever markup features you want for your site.
It doesn't exist and I wonder why. Every HTML editor I've seen is just garbage. Latency for typing characters is several round trips to the moon. Navigation, selection, where characters appear when I type all seem to be random, like my computer is possessed by the devil.
(It's a general problem w/ most WYSIWYG editors that look like MS Word, including MS Word. I'm sure there is something conceptually wrong with the model which is why all those editors are buggy, but it seems everybody else thinks it is OK for selection, navigation and where you type characters to be random.)
I use something like this for my personal website.
I don't know how fast text-based template systems are, but I can do a clean build of my entire website in under half a second. That seems pretty fast to me. I've been adding content to it for over 20 years now... it's not a massive site since it's just me, but it's not exactly small either.
Every page is authored as HTML, with some extra headers at the top. It's parsed as HTML5. The processor will apply templates in a fairly simple way... merge everything in <head>, merge everything in <body>. There's a special tag for templates that means "put the <body> here, instead of merging".
Any given piece of HTML will be parsed / unparsed only twice, because the templates work on DOM manipulation. The second parse / unparse is there because I use an HTML minifier, and the HTML minifier has a bytes in/bytes out interface.
> Another is that you run into "hygenic macro" problems if you want to merge random DOM trees into each other:...
This is a beast of a problem. If I need an ID in a template that may get used in multiple places, then there's some piece of code somewhere generating the ID.
My experience is that it really becomes a problem when you have large, large sites with tons of people working on them, and it's not a problem at all for one person.
> Finally it would be really nice to have a reliable WYSIWYG HTML editor, particularly one that would help you use CSS classes in a disciplined way to customize the system to add whatever markup features you want for your site.
It's called "Dreamweaver". Truly one of the most powerful web authoring tools ever made.
I don't know how fast text-based template systems are, but I can do a clean build of my entire website in under half a second. That seems pretty fast to me. I've been adding content to it for over 20 years now... it's not a massive site since it's just me, but it's not exactly small either.
Every page is authored as HTML, with some extra headers at the top. It's parsed as HTML5. The processor will apply templates in a fairly simple way... merge everything in <head>, merge everything in <body>. There's a special tag for templates that means "put the <body> here, instead of merging".
Any given piece of HTML will be parsed / unparsed only twice, because the templates work on DOM manipulation. The second parse / unparse is there because I use an HTML minifier, and the HTML minifier has a bytes in/bytes out interface.
> Another is that you run into "hygenic macro" problems if you want to merge random DOM trees into each other:...
This is a beast of a problem. If I need an ID in a template that may get used in multiple places, then there's some piece of code somewhere generating the ID.
My experience is that it really becomes a problem when you have large, large sites with tons of people working on them, and it's not a problem at all for one person.
> Finally it would be really nice to have a reliable WYSIWYG HTML editor, particularly one that would help you use CSS classes in a disciplined way to customize the system to add whatever markup features you want for your site.
It's called "Dreamweaver". Truly one of the most powerful web authoring tools ever made.
I want to like Dreamweaver but on a desktop replacement laptop it takes several seconds for characters to appear when I type.
Selection, where the cursor ends up when I click on something and where the cursor goes when I hit the arrow keys are all erratic enough to make me wonder if my computer is possessed by the devil.
I've submitted so many tickets to Adobe about strange problems with Dreamweaver that it's a wonder I haven't been hellbanned from their issue tracker.
Selection, where the cursor ends up when I click on something and where the cursor goes when I hit the arrow keys are all erratic enough to make me wonder if my computer is possessed by the devil.
I've submitted so many tickets to Adobe about strange problems with Dreamweaver that it's a wonder I haven't been hellbanned from their issue tracker.
All my experience with Dreamweaver is many years out of date. I don't doubt that it's become slow.
The problem is browsers don’t render like a word processor, so it’s hard to fit the model to reality.
Feel like this post confounds "plain html" for "minimal styling"
I've been a fan of Hugo (even if I don't like the strange Go template engine), because it offers a lot like tagging, generation of overviews etc. But Hugo breaks backwards compatibility on a regular basis and I'm bored of "fixing" my project just to be able to get a bugfix!
I will not go back to plain HTML, though. That is the other extreme, which is even harder to maintain, because changing the general structure, navigation or layout would require a lot of manual work. Maybe I'll write a site generator on my own ...
I will not go back to plain HTML, though. That is the other extreme, which is even harder to maintain, because changing the general structure, navigation or layout would require a lot of manual work. Maybe I'll write a site generator on my own ...
I remember hand coding my website in 1996 and then again in the early 2000s. I remember learning how to use whatever perl scripting or apache extension that enabled the .shtml extension to be rendered into a single page. I remember a friend introducing me to Frontier! and trying to figure that out.
Honestly, it was a lot more fun when it was my hobby and just me messing around in my spare time. I know WordPress is not particularly popular on HN, and I understand the reasons. That said, I use it for my personal blog because it reliably gets out of my way.
Honestly, it was a lot more fun when it was my hobby and just me messing around in my spare time. I know WordPress is not particularly popular on HN, and I understand the reasons. That said, I use it for my personal blog because it reliably gets out of my way.
This would be far more versatile as an approach if HTML could include other HTML. Not SSI but built into the spec and requiring nothing from the server and no JavaScript.
Couple this with good CSS and HTML could actually be composable. Composability was known to be a good thing in GUIs in the 1970s and the web still struggles with achieving it without heaps of JavaScript.
Of course I’m sure there is some weird reason this was never done, so instead you need mountains of shit to work around it.
Couple this with good CSS and HTML could actually be composable. Composability was known to be a good thing in GUIs in the 1970s and the web still struggles with achieving it without heaps of JavaScript.
Of course I’m sure there is some weird reason this was never done, so instead you need mountains of shit to work around it.
This is pretty much server side includes, SSI, and it's amazing and still in your server binary's today. It's a tiny, negligible, attack surface with just enough power to include bits of html so you can do templating and single file edits of the entire site.
It's old tech but it's really at the sweet spot for power versus complexity. I still use it and recommend others do as well. It makes a static site much easier to maintain.
It's old tech but it's really at the sweet spot for power versus complexity. I still use it and recommend others do as well. It makes a static site much easier to maintain.
Yeah, plain HTML and CSS is great and all, until you need a shared layout, dynamic ObjectGraph headers, a RSS feed, translations, or anything else more complex than a one-page landing page. Right tool for the job.
I still remember the days of "plain HTML pages", most people didn't even get to close tags properly and shipped malformed HTML to browsers.
I still remember the days of "plain HTML pages", most people didn't even get to close tags properly and shipped malformed HTML to browsers.
Years ago I had a simple blog site hosted by 1&1. Because dynamic layouts are so expected to keep pages modern, I found it's often a hassle to go static because web hosting platforms often come with WordPress or some templating engine.
I wish I knew a way around this because my knowledge of web design is incredibly small and I intend to keep it that way.
I wish I knew a way around this because my knowledge of web design is incredibly small and I intend to keep it that way.
> I wish I knew a way around this because my knowledge of web design is incredibly small and I intend to keep it that way.
Just copy the CSS from http://bettermotherfuckingwebsite.com/
Anything else is probably overkill.
Just copy the CSS from http://bettermotherfuckingwebsite.com/
Anything else is probably overkill.
Thanks, this is great. There’s so little CSS that is actually needed to make a modern looking page. Template engines have tricked us so badly.
If you use sane markup, modern browsers have "reader mode" that will take care of presentation for the most part.
If you don't want to learn web design, you don't have to learn web design. Keep creating and serving sensible html pages and you will be alright.
If you don't want to learn web design, you don't have to learn web design. Keep creating and serving sensible html pages and you will be alright.
Simple can be powerful. For example, the humble Apache directory listing can be JS-enhanced to a blog, a photo gallery, an album-per-folder music player and so on, and without JS it gracefully degrades to a list of posts, images or whatever media, or to a folder structure — just hide in .htaccess whatever files you don’t want visible.
https://gemini.circumlunar.space/
https://github.com/runvnc/tersenet (note that Gemini is a real system, mine is just an idea)
https://github.com/runvnc/tersenet (note that Gemini is a real system, mine is just an idea)
TerseNet seems like it has some good ideas, and I had some similar ideas, too. I would do some things differently though, such as not loading even one small image automatically (everything must be loaded explicitly), not having such a small limit for text files (I think that many documents will be much longer), not using Unicode, and some other things differently too, but much of that is like what I would have wanted to make, and I could write some of my own ideas about it too, in future, maybe.
A friend of mine runs a netlabel. Its website is a single static HTML page with no Javascript. Links to sectons are all anchor refs. It feels like Web 1.0 construction with a basic Web 2.0 face
https://moonmusiq.com/
https://moonmusiq.com/
Manually edited HTML requires great diligence to be well-formed, and this is important for accessibility.
My website has remained unsullied plain html since I wrote it. This would be more impressive if I ever actually updated it :D
(behold http://nerget.com and weep when you see the "new" features it refers to :D )
(behold http://nerget.com and weep when you see the "new" features it refers to :D )
I love reading all the hate the author is getting here. It means he’s right.
I'm with you with going stackless way for projects that don't need to be complicated, but you don't need javascript to add headers. Just a few commands would do
KISS
<link href="/~cks/dwiki/dwiki.css" rel="stylesheet" type="text/css">
"plain" here being "with judicous but none the less not exactly vanilla" CSS and JS
And plain old Html works with almost any device, even old nokias, motorolas, nintendos.
My entire web site is plain html, although I wrote the program that generates it.
Does PHP count as plain HTML?
How about PHP + CSS?
How about PHP + CSS?
That's lovely
(2019)