
Writing HTML in HTML - john-aj
http://john.ankarstrom.se/html/
======
c-smile
Being an author of my own HTML/CSS engine I know HTML/CSS very well as anyone
can imagine.

BUT! I don't like to write formatted texts in HTML sources - too hard to
consume it while writing.

Markdown (a.k.a. poor man WYSIWYG) is not that good either. Still palliative.

So I did html-notepad ( [https://html-notepad.com](https://html-notepad.com) )
- WYSIWYG editor. For myself and my wife primarily.

I am writing stuff for publishing in it and pasting to WordPress and other
destinations.

WYSIWYG HTML editing cannot be used for web site creation/design. But for
formatted texts, content islands in HTML, it is perfectly adequate.

Yet.

While 90% of formatted text editing tasks can be done in WYSIWYG, there are
tasks that are more convenient to do in source form. I use source view in
html-notepad with sync of caret position between source and WYSIWYG view -
quite handy if you would ask me.

~~~
ronjouch
Thanks for sharing.

Sciter, _" an embeddable HTML/CSS/scripting engine"_, looks especially
interesting, I had never heard of it and am intrigued by its compactness.
[http://sciter.com/](http://sciter.com/) , [https://github.com/c-smile/sciter-
sdk](https://github.com/c-smile/sciter-sdk) .

@c-smile / Andrew: are you (or other devs) still progressing on Sciter+Node?
Previous discussion:
[https://news.ycombinator.com/item?id=18746408](https://news.ycombinator.com/item?id=18746408)
/ [https://terrainformatica.com/2018/12/23/sciternode-versus-
el...](https://terrainformatica.com/2018/12/23/sciternode-versus-electron/)

~~~
c-smile
Not too much interest from the public expressed, unfortunately. Existing
customers are happy with built-in script and compactness of the engine as it
is.

Instead I am making efforts to add ES7 features to the Sciter's script. So
there are arrow functions, destructuring assignment, Node's file functions,
etc. now. More of those to come - Sciter uses same libuv library for
asynchronous IO as Node so porting of all NodeJs runtime is just a matter of
time (and practical need).

> I had never heard …

Well Sciter is 12 years old. Originally it was a "secret" UI engine of Norton
Antivirus. Symantec uses it since Norton AV 2007 and other their apps, check
this: [https://sciter.com/from-skeuomorph-to-flat-ui-evolution-
of-o...](https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-
application/). Use of CSS is quite convenient in UI of desktop applications.
All these years they do not change UI drastically - just modernizing look-and-
feel by CSS.

Since then pretty much all serious antiviruses are using the engine for their
UI. My estimation (based on customers' survey) is that Sciter code runs on 500
mln PCs and Macs now . That, I think, is comparable with, for example, current
FF installation base.

------
xmprt
> But how can I then keep the style and layout of all my posts and pages in
> sync?

I love his answer to this one. Just don't and you end up with blog posts that
are like a time capsule. This is a benefit in my books and something that
might actually shift the scale in favor of writing my blog in HTML next.

~~~
Scarblac
Yes, that is an inspiring answer.

But I'd also want to have a list of posts somewhere, a link to posts about the
same subject matter as this one, and working contact info everywhere. I'd
still want some things to be generated. And maybe an option to have comments
on some posts.

~~~
myfonj
I thought the same, but on the other hand, these are the things that are
usually just "one page" away. This concrete page / blog post doesn't even have
a link to the root section where one would seek other posts and categorization
you mentioned. This link could probably be safe to include in all pages and
consider it "stable", but I don't mind it is not there, I'm used to traverse
location using URL bar. I always thought it would be great if such features
would be provided by browser natively and "common" users were aware of them,
so that "common" pages could remain this gorgeous simple static capsules.

------
ibudiallo
I prefer* to write my own blog posts as HTML. Why add a middle man if the end
result is html?

*However HTML is not easy. I get it. Most of us here can write it with one hand tied behind our back. But the problem with html is that it gives me choices. Writing is hard enough that I have to use a minimalist text editor just to not be distracted.

When I write and think of a trivia fact, HTML tells me that I can nest it as a
side comment in a separate div. In fact, I should use an <aside> tag and style
it differently. It would be nice if it could hover on the side of the page
without breaking the flow of the content. Ah mobile. I should have it render
differently on mobile. Maybe it should be collapsed at first, but then the
user can click to expand it...

I use markdown so I only have to think of titles and bulleted lists. If I have
to add something complex, I'll turn to html, but it is not my default.

In the case of writing, I don't want to think about html.

~~~
baroffoos
HTML is not hard its just makes little sense to write a website without some
form of templating. If I add a navbar to my website the HTML way to do it is
to copy and paste the navbar in to 100 different html files. And then when I
want to add a new link to the navbar I have to copy it back in to those 100
files.

Or I could use a static site generator and put it in the navbar file and run a
command to have it inserted on every page.

The author of this blog has dealt with this issue by having no site
navigation.

~~~
mrweasel
Server Side Includes are still exists. It is in many ways surprising to me
that SSI never for more usage that it has, it solves a lot of small scale
problem, for minor websites.

~~~
ricardo81
mrweasel indeed, exactly what I was thinking. SSI for the head, top, nav,
bottom... unique content included. Update to the template is one simple edit.

Taking it a step further with the likes of nginx, cache the response, compress
it. done.

------
crunchbang123
Checkout motherfuckingwebsite[1], bettermotherfuckingwebsite[2], and
thebestmotherfuckingwebsite if you want to see what can be done with pure html
and minimal css.

[1]:[https://motherfuckingwebsite.com/](https://motherfuckingwebsite.com/)
[2]:[http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)
[3]:[https://thebestmotherfucking.website/](https://thebestmotherfucking.website/)

~~~
isostatic
1 is far more readable, pleasing on the eye, and informative than 3.

~~~
chacha2
That's because they forgot the best and ultimate one.
[https://bestmotherfucking.website/](https://bestmotherfucking.website/)

~~~
isostatic
Yes, that's good. That's 100 times better than (3), and I would agree is
better than (1).

------
filmgirlcw
I love this as a pure thought exercise/experiment — and it reminds me a lot of
the types of websites we used to build 20 years ago.

That said, once the templating/boilerplate stuff comes into play, the author
is like half a step away from trying to recreate PHP, which originally stood
for Personal Home Page. Like, he’s even using PHP for his RSS feed!

Like, I’m not opposed to these thought experiments in the slightest — but I
can’t help at the irony that most of these “simple” website engines (not
talking about this approach specifically) almost always lead us back to our
earliest CMS implementations.

I’m in my 30s. I literally grew up on pure HTML. But as much as I abhor how
bloated current CMSs are, I also shudder when I remember how hard it was to
create and manage HTML (and later, HTML and CSS) files by hand to
update/maintain anything but the most basic website.

~~~
jchw
My thoughts as well. It’s not that people don’t realize you can write HTML in
HTML - it’s just, we’ve long understood the caveats; it has poor hygiene. The
only practical way to avoid needing duplication is scripting or frames, which
is not ideal for the end users.

~~~
gdsimoes
I wonder if there’s no way of making frames work. It seems like such a waste
to have the same HTML code for navigation on every single file.

~~~
filmgirlcw
I think for usability and accessibility alone, we moved to scripting instead.

Frames were also often used for layout purposes, and when we all accepted the
idea that markup and presentation should be separate, CSS was a much better
solution.

------
valtism
> It’s more fun that way. Look at this website: if you read any previous blog
> post, you’ll notice that they have a different stylesheet.

You know what? This is _great_. I think the idea of each page having it's own
self-contained snapshot of where the site was at when you read it is a great
idea.

------
Theodores
If you write in HTML and know your elements well then it all becomes easier
and your HTML gets more feature rich. It lso encourages you to break down
paragraphs which are okay for book style writing into shorter web style
paragraphs.

What I find really helps for writing HTML in HTML is to use sections,
articles, headers, blockquotes and so forth to structure your writing. WYSIWYG
editors never allow you to do this properly. They are 'what you see' rather
than 'what you mean'. There is a difference.

Blocks of text should be like procedures in code, in a section, aside or other
HTML sensible element and with a header at the top.

If you enforce this writing style it becomes much easier to have super-neat
documents. It is just a pity you can't do this with WYSIWYG or some markdown
thing. Really HTML is the ultimate.

~~~
macintux
If you want “what you mean” then wouldn’t Docbook make more sense? Assuming
anyone still uses it.

HTML is still a bit burdened with presentation vs semantics, although CSS has
obviously helped a great deal.

------
TimTheTinker
As I understand it, the original reasons for including some indirection in the
production of HTML were: (1) templating - i.e. injecting boilerplate at
compile or run time. This would include standard headers, footers, <head>
elements, etc.; (2) navigation and tags - both of which are highly laborious
to maintain manually, and (3) RSS feeds.

I would be _really_ interested to see someone use modern web platform features
like HTML imports, web components, JS modules, or something else to achieve
the above features _at run time_ while enabling one to write in nearly pure
HTML.

~~~
ricardobeat
And lose static rendering, all the accessibility and ability for simple
parsers to understand and/or store the page. All that comes to mind when web
components come up is “what we’re they thinking?”.

~~~
TimTheTinker
> what we’re they thinking?

Browsers have native, built-in components like <select>, <select multiple>,
<input type="button">, <input type="date">, etc. Styling and behavior of those
is self-contained, with a public API.

The idea behind web components was to provide a built-in way to build your own
self-contained components - something people have been doing for a long time
with tons of <div> elements. But it's always been a challenge because doing
that well requires adopting some consistent approach (usually through a
library) that builds its own mechanisms. And there are many different
libraries, and they all have different approaches. Wouldn't it be better to
provide a _standard_ mechanism for defining custom components and abstracting
their styling/behavior?

Web components and other modern web tech could eliminate the need for
libraries like React to build complex web apps with custom controls.

~~~
ricardobeat
> Web components and other modern web tech could eliminate the need for
> libraries like React to build complex web apps with custom controls.

But they won't, for the reasons presented here. They solve only the lower half
of the problem. They're perfectly fine for building self-contained UI
controls/elements, but create a top-level `<BlogArticle>` component to mimic
the composability of modern frameworks and you lose all I mentioned above.

~~~
TimTheTinker
> But they won't, for the reasons presented here. They solve only the lower
> half of the problem.

Right, I wasn't arguing for use of web components for anything like
<BlogArticle>. That's way outside their scope. But with web components being
available, libraries like React would be optional/redundant when custom
components are involved (like in complex web apps).

But I still think it would be fun to see someone hack modern web tech (even
web components) to build modern blog features with pure HTML (+ sprinkled
JS/CSS, as needed).

~~~
ricardobeat
> libraries like React would be optional/redundant when custom components are
> involved (like in complex web apps)

This is where we disagree - this is not true at all. In complex web apps, what
you need the most is high-level components such as `<BlogArticle>` that allow
you to tame complexity, isolate reusable pieces of UI that might be as large
as a page itself, and not just localized elements. As you acknowledge, WC
doesn't even aspire to fill this role, meaning you'll still need higher level
frameworks on top of them, which significantly diminishes the value of being
built-in.

~~~
TimTheTinker
Have you ever tried to build a reusable multi-select combo box? That’s not
easy without some framework. Event and state management can become a real
headache.

But higher-level items like articles/comments are so much easier without a
framework - I just don’t see how React/etc. is necessary given you have a
decent templating library and a module loader that has CSS, JSON, and string
plugins.

------
okaleniuk
Can confirm. I'm doing
[https://wordsandbuttons.online](https://wordsandbuttons.online) in plain HTML
and yes, it's incredibly liberating.

But I went a bit further, I do write HTML by hand in vim (plus some python
scripts when applicable). Writing HTML is not that bad once you get used to
it. My pages are not plain text anyway. They are mostly interactive things
written in JavaScript. Since I spend considerable time coding, it doesn't
bother me to spend five minutes putting tags here and there, too.

Coming up with the design decisions takes much more effort than typing in the
actual tags.

And yes, I do have an RSS. It's also updated manually since it's again an
effort too small to automate.

------
dmje
There's some irony in ditching all the things in favour of none of the things
when actually the likely answer is some of the things...

But the whole static site generator thing is hilarious when you look at it,
and classic developer territory. "I'm gonna install a gazillion tools to write
some words on the web" \- fine if you're learning stuff by doing it but for
god's sake don't go suggesting it's "easy"...

~~~
john-aj
_> fine if you're learning stuff by doing it but for god's sake don't go
suggesting it's "easy"..._

This is exactly what I’ve come to realize. Static site generators are not at
all as simple, easy or intuitive as you might think.

~~~
okaleniuk
And they only automate the trivial stuff anyway.

I spend most of the time on writing, editing, then programming, and only then
typing the text and doing the layout. The last 5% of that could be automated,
but then I wouldn't be able to write things down from my phone while
traveling, or directly from my CHIP when exploring ARM-related things.

~~~
dmje
_I spend most of the time on writing, editing..._

And this is the really important point. If developers spent nearly as much
time thinking about the important bit: their words / grammar / spelling /
structure - as they did about which static site generator to use - we'd see a
monumental improvement in communication.

There are so many developer articles / blog posts which are just terrible -
sometimes because of language issues, yes, but more often than not just poor
writing and badly thought out arguments. But, you know, it's ok because
they're using TheLatestStaticGenerator :-)

------
jjcm
I do something similar for my own blog, purely because I enjoy having the
flexibility of styling every blog post in a way that's appropriate for that
specific page (i.e. a blog I did on photography[1] vs a blog I did on
gaming[2])

That said, I'm a man of convenience. Mixins are too much of a niceity to throw
out so I wrote some small apache cgis to dynamically compile pug (aka jade)
and stylus. I typically write directly on the server just using vim. Certainly
not the work flow for everyone, but I quite like the experience.

[1]
[http://jjcm.org/blog/anatomy_of_a_surreal_photoshoot/](http://jjcm.org/blog/anatomy_of_a_surreal_photoshoot/)
[2]
[http://jjcm.org/blog/how_to_play_pa/](http://jjcm.org/blog/how_to_play_pa/)

------
TazeTSchnitzel
It's technically not static content, but consider Server Side Includes
([https://en.wikipedia.org/wiki/Server_Side_Includes](https://en.wikipedia.org/wiki/Server_Side_Includes))
for when you want to share just a header and footer.

~~~
combatentropy
Server Side Includes are unfairly neglected simply due to age.

Another way, seldom mentioned, is JavaScript. Just include some script tag,
which inserts the HTML at the top, bottom, or wherever. An advantage it has
over Server Side Includes is that it is cached.

~~~
ricardo81
One disadvantage as that many search engines and other programmatic means
won't be able to read the Javascript.

------
city41
The article mentions GitHub will host Jekyll websites for free. Is that a
common misconception? GitHub will host absolutely anything for free, you’re
not limited to Jekyll at all. It’s just GitHub has some extra support for it.

But I’ve never felt any need to take advantage of the Jekyll features. Pushing
html of any sort to the gh-pages branch is trivially easy.

~~~
john-aj
I think people mention Jekyll especially because it’s supported directly by
GitHub – that is, they generate it for you (which is a bad idea, really,
because of the differences between the various versions of Jekyll).

------
lunchables
>Using a static site generator means that you have to keep track of two
sources: the actual Markdown source and the resulting HTML source. This may
not sound too difficult, but always having to make sure that these two sources
are in line with each other takes a mental toll.

I write in asciidoc and I find this trade off is well worth it. It means I can
write more easily, I can future-proof my documents (if html versions/practices
change, I just export them again) and I can output in multiple formats instead
of just publishing to the web.

I don't understand what he means by "keeping track of two sources". I have one
source: asciidoc documents. I output that into one format (today, typically)
HTML. I have a script that just adds a header/footer to each one and sync to
s3 bucket.

If asciidoc dies I can convert them to reStructuredText, Markdown, or whatever
format is popular next. My mark-up is very simple, headers,
bold/italic/underline, bulleted and unbulleted lists, etc. So my "source"
documents are simple to convert between formats.

I find this gives me the best combination of ease-of-writing, flexibility and
future-proofing.

------
kyle-rb
I've written a ton of notes for my university classes in HTML using Emmet.
Spinning up a list with ul[tab]li[tab] is pretty easy and fast.

The main abbreviation-expanding stuff is enabled in VS Code by default, and
you don't need to read all to documentation to get started, just the basic few
things.

------
ben165
It's funny that people write a whole blog post about sth. which was normal in
the early years of the web. I host my private programming website and travel
blog, so I wasn't forced to change my behavior. I always write HTML code by
myself.

The way to frameworks or generators was caused because of the site look
changing. Doesn't matter on which page you are, you have always a menu
provided with lots of links. The "Back"-button is not seen today anymore. How
I miss these days guys, this is why I love exploring neocities from time to
time :).

~~~
okaleniuk
Yes, I do that too. I do have scripts that do maintenance jobs, like changing
the footer now and then. But they don't work with templates, they use the HTML
input and just process it like any other data.

I don't really like the menu idea though. I prefer plain content with just a
bit of links in the footer, like this:
[https://wordsandbuttons.online/programmers_introduction_to_l...](https://wordsandbuttons.online/programmers_introduction_to_linear_equations.html)

------
TranceMan
There was a time when you _had_ to know how to write HTML - also FTP - oh and
Fax letterheaded paper to register a domain

Looking back now - MS Frontpage was way ahead of its time dealing with this
abstraction of generating html - you _saw_ the source change which the browser
(unfortunatley just ie - but that's what we had) would render when you made an
edit

------
methodin
I think we all look back fondly to the early days of HTML sites where
everything was pure, but let's not fool ourselves into thinking it was the
best setup for things like blogs. If you want to be a purist, do so by
leveraging newer advancements like web components. Suggesting people copy and
paste HTML/CSS for every post is a really bad suggestion for anything that
isn't a weekend project that you will never touch again.

And also, isn't a HTML IDE the equivalent of a static site generator except
lacking any of the actual features that make generators appealing?

~~~
wildrhythms
What I take away from this is the idea of each post having its own identity
and feel (each post with its own unique stylesheet). Contrast to a blogging
platform like Wordpress or a SSG like Jekyll where every post is generally
formatted and styled exactly the same way. The author's blog posts are now
these unique time capsules.

Obviously a blog at scale isn't going to do this, but I do think there's value
in what the author is trying- where each post is styled and formatted
independently with care instead of unceremoniously dumped in with a one-size-
fits-all stylesheet.

~~~
methodin
To what end? The inevitable outcome is that you have a hodge-podge of HTML and
styles and if you want to replicate one you have to backtrack through a
plethora of random posts to find the one that implemented it. I see zero value
in a time capsule because it's not one. If he crafted every page from scratch
- maybe, but to his own credit he's copy and pasting. That's nothing to aspire
to.

------
dreamcompiler
One problem I have with this is it violates the DRY (Don't Repeat Yourself)
principle. The author embraces temporal inconsistency, but I'm not a big fan
of it. Maybe inconsistency for content is okay, but for consistent DRY style I
think I'd at least use CSS even if I didn't use a CMS.

~~~
mbrock
It violates that principle but on the other hand it embraces the RY (Repeat
Yourself) principle which has its own set of pros and cons, the major pros
being simplicity of implementation and reduced risk of retroactive breakage.
I’ve found this principle very useful also in software design. The DRY
principle gets all the attention but we tend to ignore the question of when
it’s actually better to repeat oneself.

~~~
john-aj
I agree, especially with the part about retroactive breakage. It’s very easy
with static site generators; with just HTML and CSS, not so much.

------
blotter_paper
>There has be some reason why people don’t write their personal websites in
pure HTML. Well, it’s simple:

>>HTML is unpleasant to write.

>This is the only real reason.

This seems like a huge overstatement. His point about each page being a
snapshot in time strikes me as a bug, not a feature, but to each his own. My
biggest qualm besides this is that working without a template will make
nontrivial isomorphic rendering and rehydration way more developer-time
intensive, and I think we should be embracing this strategy for any behavior
that can be implemented both with and without page reloads -- even if you
don't like shwanky JavaScripts, subsequent page loads will be faster if you
just have to update the necessary changes rather than the whole page. Finally,
raw HTML isn't the cleanest format to write in. I don't want to be tied to a
WYSIWYG, I'd rather be able to access my editor from anything with an ssh
connection, and I don't want every text file I deal with to start with a bunch
of repetitious boilerplate (headers and such). I'd rather write in a cleaner
format for data and let the computer deal with fitting it into the template.

I don't think that HTML being unpleasant is a good reason not to write in it.
If you're writing in something that compiles to HTML you should probably
understand the model directly underneath you.

~~~
dmitriid
> working without a template will make nontrivial isomorphic rendering and
> rehydration way more developer-time intensive

What are you talking about? This is static HTML and static CSS. There’s no
isomorphic rendering ir rehydration. It already _is_ “rehydrated”. And it will
take significantly less time to download than for dozens of kilobytes of JS to
do the same thing.

~~~
blotter_paper
The beauty is that you can have it request the JavaScript after the HTML, so
those kilos of JS don't slow down first render and by the time a user clicks
something you're probably rehydrated and ready to request subsequent pages
without a full refresh. On the offchance you aren't rehydrated by the time of
a click you just fall back to the normal behavior of an anchor link. All the
delivery/render speed of static HTML with the subsequent page load times of an
SPA. I could see not liking this approach if you're trying to minimize bits
downloaded, but if you're concerned about user experience I would idealise
using this pattern on all internal links (pretty much -- there are weird
exceptions like embedded content that refuses to run after initial render for
security reasons). This approach is more complicated, but also more performant
due to less overall DOM manipulation.

Step 1: client requests page.

Step 2: static HTML is delivered.

Step 3: static HTML begins rendering on client.

Step 4: client requests JavaScript attached to bottom of HTML document.

Step 5: JavaScript is delivered.

Step 6: JavaScript begins execution.

Step 7: JavaScript goes through the document replacing normal anchor links
with elements that have click events which request only the content, and not
the template, for subsequent pages[0].

Step 8: user clicks a "link."

Step 9: client requests content.

Step 10: content gets delivered.

Step 11: client updates part of the page and the URL bar, but doesn't cause a
whole page refresh.

[0]Exception: you can give yourself hooks for a template change if you want,
and even a significantly different layout on the same site will often have
some common factors like footers and background.

~~~
icebraining
Why is this a better approach in terms of UX?

~~~
blotter_paper
Users don't like waiting for pages to load. Rendering fewer new DOM elements
takes less time. Thus, user experience is improved by not doing a full page
refresh when it isn't necessary.

------
pmlnr
Would love to do this. The reason why I'm going to stick to generating from
markdown is mainly to have markup that other sites can parse, in this case,
microformats2. Writing structured data by hand is brutally prone to error.

Otherwise I adore the idea and I find it lovely! :)

------
fergie
"Case in point about the downsides, the cv link is correct on the author’s
homepage. It is not correct on this page. That’s an easy mistake to make, and
I’ve definitely made versions of it. However, it’s much more pleasant to fix
when you can fix it everywhere by updating a template."

If HTML had some kind of templating functionality so that you could trivially
reuse, say, a header or a footer then lots more people would write HTML in
HTML.

~~~
zerocrates
The grand return of SSI is at hand.

------
rgoulter
If the author wants to write HTML directly, sure.

But, uh, kinda feels like the author's "reasons" aren't balanced in terms of
comparing "maintaining a website by writing HTML directly" to "maintaining a
website by using a static-site generator".

e.g.:

 _" But how can I then keep the style and layout of all my posts and pages in
sync?"_ _Simple: don’t! It’s more fun that way. Look at this website:_ _if you
read any previous blog post, you’ll notice that_ _they have a different
stylesheet. This is because they were written at different times._ _As such,
they’re like time capsules._

...But if someone _wanted_ to maintain/update consistent styles across a
website with only HTML files, then this would be a point in favour of a
templating system over writing in HTML directly.

 _Finally, you constantly have to work around the limitations_ of your static
site generator. _Let 's say you want your site to have a specific directory
structure,_ _where pages are sorted under various categories._ _With Jekyll,
this is practically impossible,_ _and even though you technically can get it
working if you really try,_ _it is only through much effort and with a source
code that is_ _organized much more unintuitively than if you just wrote it
directly in HTML._

While it's fair to say that you have to learn the idiosyncracies of a SSG to
use it, I'm not sure this is a fair criticism of Jekyll.

Seems that page output is determined by a 'permalink' key.
[https://jekyllrb.com/docs/permalinks/](https://jekyllrb.com/docs/permalinks/)
(Found through a quick search for "jekyll structure").

~~~
rossdavidh
I agree that some sites have a reason for wanting to keep the look of all
pages in sync, I think it's fair to point out (because most people won't think
of it), that this isn't really all that important for a basic blog. You don't
really need all your posts to look identical. There are some things, like what
url the home page links to, that need to be kept in sync everywhere, but that
isn't hard to do.

------
defanor
As yet another person authoring in HTML, a couple of things I found rather
helpful are XSLT for a bit of processing (generating indexes, atom feed, etc)
[1], and though I generally dislike WYSIWYG editing, as mentioned in other
comments, it can indeed be helpful to read documents with many inline links;
in emacs, I liked how org-mode handles it (only hiding links, but nothing
else), and wrote something similar for HTML [2,3].

[1]
[https://git.uberspace.net/homepage/tree/tools](https://git.uberspace.net/homepage/tree/tools)

[2] [https://git.uberspace.net/html-
wysiwyg/tree/](https://git.uberspace.net/html-wysiwyg/tree/)

[3] [https://defanor.uberspace.net/pictures/html-
wysiwyg.png](https://defanor.uberspace.net/pictures/html-wysiwyg.png)

------
tannhaeuser
The author really would benefit by taking at look at SGML (on which HTML and
XML is based). SGML has entities (for pulling in common content at multiple
places), context-dependent transforms (for producing navs, link decorations,
etc.), and short references (for parsing custom Wiki syntax such as markdown
or CSV into regular markup).

~~~
john-aj
Hm, I’m interested, but isn’t SMGL practically a different language? Apart
from syntax, are those concepts translatable to HTML? I mean, can I use it to
write web pages?

~~~
tannhaeuser
SGML is a markup meta-language, meaning it takes a vocabulary (a Document Type
Declaration grammar for HTML) as input, along with the actual HTML source
markup. See [1] for a HTML5 DTD which has all the necessary declarations for
HTML's element omission/inference rules, enumerated attributes, etc. Apart
from element inference and other markup shortforms, this will be familiar if
you know XML (which is a subset/profile of SGML), but SGML has a number of
additional concepts for content authoring/page composition such as _link
processes_ (an additional type of declaration set that can define an automaton
for assigning attribute values based on context, and can be pipelined to
produce "views" of documents such as a table of content or nav) and _short
references_ (which are element-context specific rules for replacing custom
text sequences into other text or markup tags). My SGML implementation also
has _templating_ which is an additional form of _parametric_ entity inclusion
based on concepts from HyTime, without adding any new syntax to SGML.

As to writing practical web pages, I'm working on it, ;) The pages/blog you
see on sgmljs.net are completely produced by SGML.

[1]:
[http://sgmljs.net/blog/blog1701.html](http://sgmljs.net/blog/blog1701.html)

------
kome
I am a big fan of writing HTML in HTML, this is my website:
[http://mrtno.com](http://mrtno.com)

One of my friend just did her website all alone, and it's amazing:
[http://ivana.su](http://ivana.su) \- best page of the internet.

~~~
okaleniuk
It is!

------
lenkite
I am so surprised that the author doesn't even mention Emmet
[https://emmet.io/](https://emmet.io/)

------
bigiain
I wrote html in html as a gag website once...

[https://web.archive.org/web/20011102031149/http://www.mighty...](https://web.archive.org/web/20011102031149/http://www.mightymedia.com.au/~bigiain/)

------
mhd
I would agree somewhat with pure textual matter. Incidentally, the one thing
where SGML doesn't totally suck, as it was pretty much invented for this.

It still has a pretty writing experience if you're going beyond just
paragraphs and the occasional emphasis. Take inserting hyperlinks as an
example, I've yet to see a UI that makes that easy enough, highlighting text
and then invoking a pop up window is often a bit wasteful and harder to
automate (e.g. inserting the current selection or the top-most browser's
content). At least with a WYSIWYG editor the content won't be littered with a
huge blob of computing ephemera, but having the URL hidden also means that you
can't just grab it if you want to repeat the link.

Now the problem is that modern HTML authoring often isn't about regular text,
but about creating some kind of hierarchical structure that serves as the
content for some pretty involved navigation or data manipulation histrionics.
Which means plenty of elements, plenty of nesting, with comparatively little
content. And that runs into all the areas that made XML the horror that it is.

In a perfect application of "This is normal now", people are actually quite
content with being in this burning room of tags and attributes, as long as the
IDE helps creating this mess. JSX, Emmet, templates -- it really reminds me of
the early days of Java, where everything was just solved by the IDE or code
generation tools (getters/setters, DI etc.).

------
fjfaase
I have been doing this for more this for 24 years now. Even developed my own
editor (based on the Crystal Edit controls), which has navigation. Pressing F5
on a link, will open the file (when it is local) at the given location
(following anchors) or send it to the default browser (when it is external).
It has syntax highlighting with checks on matching tags and inline JavaScript.
See:
[http://www.iwriteiam.nl/MySample.html](http://www.iwriteiam.nl/MySample.html)

~~~
fjfaase
I also wrote a program to check the consistency of all HTML files on my
website. It checks if all internal links are correct and even does some
checking on reverse links. Furthermore, it also has a mechanism for
maintaining tags with blog entries. It processes the FTP log to determine
which files needs to be uploaded and places these in an upload directory
(while adding a BASE HREF to the HTML files).

------
meerita
My personal website is generated with Jekyll. I use Jekyll because it's better
for links, sections, and other automated things like "related posts". It would
be a tiresome task to do it all manually.

I respect this guy anyways. He wanted the simplicity and it's ok. I've see one
of his posts has no CSS styling, and this is product of manual editing, you
lose consistance.

The only caveats I see on this websites is, when they setup the width of the
content. I love fluid pure HTML websites.

~~~
john-aj
I used Jekyll before, but I found myself always having to fight it to do what
I wanted. That’s why I switched to my current approach.

 _> The only caveats I see on this websites is, when they setup the width of
the content. I love fluid pure HTML websites._

Hm, thanks, I might change that.

------
acdha
I switched to this years ago with some Python code which uses the data
embedded in the HTML source to generate things like feeds or re-applying
templates. I've mostly neglected it for years but am generally happy with the
approach of developing templates interactively and then having a script which
just pulls values across using selectors (e.g. take [itemprop="articleBody"]
from the original page and use its children to set the contents of
[itemprop="articleBody"] on the template). This was nice for allowing you to
do anything you want at any time without having to fight a templating system
or CMS structure.

[https://github.com/acdha/simple-cloud-
site/blob/master/simpl...](https://github.com/acdha/simple-cloud-
site/blob/master/simple_cloud_site/templates.py)

I like the approach of using the same data values (schema.org microdata, meta
headers, etc.) which other things use to keep you honest about that: e.g.
[https://chris.improbable.org/2014/8/25/adventures-in-
unicode...](https://chris.improbable.org/2014/8/25/adventures-in-unicode-
digits/) extracts to [http://microdata-
extractor.improbable.org/extract/?url=https...](http://microdata-
extractor.improbable.org/extract/?url=https%3A%2F%2Fchris.improbable.org%2F2014%2F8%2F25%2Fadventures-
in-unicode-digits%2F) without any need to be careful updating the system
because if it didn't, the missing data would be immediately obvious.

------
japanoise
This reminds me of a microblog I used to keep; I had one `blog.html` page, and
added to it with an `<h2>` for the date and a few paragraphs of text... good
memories :)

~~~
zimpenfish
I'm starting to think that's a good idea as a supplement to a "real" blog -
sometimes there's just not enough oomph in a thought to carry it through to a
full post but would justify a couple of paragraphs.

Of course, working out how to make this convenient to use is going to be the
tricky bit...

~~~
japanoise
Some people use Tumblr for this; it's where I copped the term "microblog"
from.

Maybe mine was more like a nanoblog...

------
kragen
I've certainly written lots of HTML in HTML, but for Dercuano
[https://gitlab.com/kragen/dercuano](https://gitlab.com/kragen/dercuano) I
wrote a static site generator over the weekend in Python. (The Gitlab link is
the source; the latest release of Dercuano, built, is at
[http://canonical.org/~kragen/dercuano-20190610.tar.gz](http://canonical.org/~kragen/dercuano-20190610.tar.gz)
.)

Adding a new note to Dercuano just involves writing a new Markdown file in the
markdown directory, so as with HTML, there's no threshold. Actually, there's
less of a threshold: with HTML nowadays, I have to add stylesheet links, and
meta tags so browsers don't interpret it as ISO-8859-1, and more meta tags so
phones display the text at a readable size, and a <script> tag to add the
table of contents... with Dercuano, I just start writing text. By default, the
title is generated from the filename, or from the <h1> if the Markdown starts
with one.

Why not just copy and paste? Well, aside from reducing the download size,
sometimes I _want_ to improve something for all the pages at once. Fonts, for
example. There's always the risk that that will break some existing page, but
I think the grain size where that's the dominant part of the tradeoff is
somewhat larger than the million-word size of Dercuano.

I mention this not because I want you to use the Dercuano software (although
you're welcome to and it's in the public domain so you're legally protected)
but because I want you to know that writing your own is an easy weekend
project.

------
rntksi
Remember Dreamweaver, Frontpage, geocities, ...angelfire :) ? Those were the
days!

~~~
ricardo81
You had those "Frontpage includes" that IIRC search engines had no problem
parsing.

------
p410n3
Another thing to add might be a increased security.

There isnt really a way to hack into a HTML only site. With a CMS however
thats different.

~~~
icebraining
A CMS that produces a static site (e.g. Publii) has the same security, though.

------
danielbraun
Up next: Writing machine code in machine code

------
yellowapple
I feel like a happier medium would be to use a Makefile or something to
automatically concatenate a shared header + content + shared footer. Addresses
the concerns about maintaining the bits and pieces shared among multiple
pages, while at the same time avoiding a lot of the complexity of a full-blown
static site generator.

~~~
john-aj
I don’t think this is as simple as you suggest (because I’ve tried things like
it). First, you have to keep track of which documents need the same
header/footer (unless all are exactly the same). Second, you have to extract
the title from the content somehow. There are a bunch of little steps like
these that make it more complex (in my mind) than just writing HTML directly.

~~~
yellowapple
> First, you have to keep track of which documents need the same header/footer
> (unless all are exactly the same)

That should be pretty easy to program into a Makefile.

> Second, you have to extract the title from the content somehow

Or just "cat headerfront $PAGE/title headerback $PAGE/body footer >
$PAGE.html".

Like yeah, there's some upfront complexity, but nowhere near the complexity of
manually editing these things on each and every page. Once you have these
programmed in and scripted out, you get 90% of the useful stuff a SSG does for
you with 10% (at most) of the moving parts.

~~~
john-aj
The thing is, I don’t want any generation at all, at least not with my actual
HTML pages.

~~~
yellowapple
Okay, then don't do any generation. That's fine. Nothing wrong with doing
things manually if that's really how you like to do it.

Personally, I'm lazy, and tend to prefer at least a little bit of automation.

------
manbearpiggy
I get a tough time from some of my developer friends as I prefer pure HTML and
CSS, also you can throw together a nice website using W3 templates
([https://www.w3schools.com/w3css/w3css_templates.asp](https://www.w3schools.com/w3css/w3css_templates.asp)).

------
jefftk
I also like writing HTML in HTML. Example:
[https://www.jefftk.com/p/adventures-in-
upstreaming](https://www.jefftk.com/p/adventures-in-upstreaming)

I do have a static site generation step, though, which takes in my raw html,
wraps it into posts, builds index pages, adds srcsets to images, and generates
RSS feeds:
[https://github.com/jeffkaufman/webscripts/blob/master/makers...](https://github.com/jeffkaufman/webscripts/blob/master/makerss.py)

There are bits that are pretty hacky, but being able to put anything directly
into the html, just the way I want it, is much better than messing with
various converters. Simple HTML is really fine to write in.

------
straffs
Write a gdoc and convert it to html with a simple script. The hard part is to
write interesting content, not to format it.
[https://github.com/thejimbirch/GoogleDoc2Html](https://github.com/thejimbirch/GoogleDoc2Html)

------
ddtaylor
HTTPS Everywhere fails to load the page and attempting to force
[https://](https://) causes a certificate error.

------
Moxdi
I'm using Hugo and I only write html, Hugo supports it, forget about markdown
it sucks if you want to do anything complicated

~~~
city41
You can just write html in a markdown file. It’s the best of both worlds.

------
elliottkember
I once made an app for this -
[http://hammerformac.com](http://hammerformac.com). It was a delight to write
simple HTML with hot reloading, then add other bits when I needed to. It was a
hard sell to developers who like shiny new frameworks, but people who used it
really loved it.

------
ing33k
Not a bad idea if you really want to learn HTML/CSS.

------
gautam1168
Step1: Write pages in pure html Step2: Organize your html into folders that
are similar Step3: Write some scripts to _generate_ more folders easily Step4:
Write some sed scripts to make changes across files Step5: Release your
scripts as your own site generator

Or you could just spend 15 minutes trying to patch your existing site
generator to suite your needs. This article sucks. Downvote.

------
revskill
You're messing interface with implementation details, and i think it's not
good for maintainance in long term.

Keep interface in another format/language is a good practice. HTML is just the
compiled output (or implementation details), which we should not keep aware
of.

------
beardedwizard
Isn't using a wysiwyg editor an abstraction akin to markdown...?

------
wyclif
* challenged

------
sureaboutthis
I've given up trying to get people to understand that writing fundamental code
and markup is far easier than CMS/library/framework hopping. My company
created two large web sites that you visit at least once a month and no one
believes it's HTML and CSS is all handcrafted. To this day I'm still told what
we do is impossible even when I showed them the source.

That was years ago when I did that. I won't do it again.

~~~
blotter_paper
If you think it's easier, why won't you do it again? Maintainability?

~~~
sureaboutthis
Do not think we still don't do it. My line was to state that I have not
bothered to explain anything to anyone for years, not that we haven't done it
for years. We would never use code generators cause we're professional
programmers and know how to create our own output.

While I do not have issues with using some well-developed library, depending
on whose library it is, we are more likely to only use it till we develop our
own.

