Writing HTML in HTML
john.ankarstrom.se
john.ankarstrom.se
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 ) - 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.
I deliberately remove all inline styles while pasting and loading: https://github.com/c-smile/sciter-sdk/blob/master/notepad/re...
Browsers and apps like MS Word put too much garbage in HTML/ clipboard.
The app is still buggy in dusted corners though. Cleaning them time to time.
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/ , 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://terrainformatica.com/2018/12/23/sciternode-versus-el...
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.... 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.
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.
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.
Also, like I assume everyone else does, I version my source documents and html using git. So I can see what it looks like at any point in time if I want to take a trip down memory lane.
*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.
For a blog, you've probably a basic style sheet for this already and adding to this on the fly in order to express your ideas is a nice option.
Edit: I strongly advocate the use of semantic tags like <cite> or even <q> (instead of using typographical quotation marks), lang-attributes, etc. This is only about genuine marks of emphasis (as in speech).
Edit 2: I just learned about the "undeprecation" – so read cum grano salis (<– example of a lateral change of context expressed by the use typographical emphasis).
https://www.w3.org/International/questions/qa-b-and-i-tags
And I think the history here is pretty hilarious.
- Classic html: <b> and <i> mean bold and italics.
- Then the semantic folks took over, deprecated these tags, and say you have to use <strong> and <em> instead.
- Now with HTML 5 the <b> and <i> are brought back, but they don't mean bold and italics. They have new semantic meanings that sound like hilariously over-engineered attempts to pretend that they have some higher purpose that fundamentally really just means bold and italics.
What I think the committees must have missed is that presentation and semantics are not separable; in many ways the presentation is the semantics. Bold text itself gives meaning to the boldness, inferred by readers and authors, based on how the boldness looks to them.
As for the over-engineered part: I usually try not using spans or similar in markup to separate short terms or phrases, where there's a change in meaning or the level of information, rather using emphasis (<em>) for this. 99% of the time I end up styling this as italics. Because, this is really what typographical emphasis is all about.
P.S.: And I always failed to recognize the crucial difference in meaning of "bold" and "strong". Both in speech and type these are quite the same concept to me, "bold" may be even be a bit more general and specific at the same time. (E.g., "bold" is not shout, but it's about a general concept of raised importance, which isn't clearly expressed by "strong".)
This is some pretty selective reasoning by the working group considering they don't provide a warning for all other elements (not even <strong> or <em>, which can also be overridden by stylesheets). I could toss a "p { display: none !important; }" into my stylesheet, yet the <p> tag doesn't have a warning that text inside it might not be displayed. Seems like they're grasping for reasons to discourage <b> and <i>.
http://www.brailleauthority.org/formats/2016manual-web/secti...
As McLuhan said, the medium is the message
No semantic web person would have said <strong> and <em> “replaced” <b> and <i> except for the specific cases where <strong> and <em> are semantically appropriate. For example, italicizing ship names with <em> has always been wrong.
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.
Well, don't, they're deprecated. But you could.
Taking it a step further with the likes of nginx, cache the response, compress it. done.
It's mind boggling that it doesn't exist. XML has it - I can resuse the same image with a tag, but not HTML??
Why can't we have the same logic of SSI implemented in the browser?
Probably the perfect being the enemy of the good again.
This experiment by Jake Archibald looks interesting in this area. https://github.com/jakearchibald/streaming-include
<iframe src="/images/includespost/htmlexample.html" onload="this.before((this.contentDocument.body||this.contentDocument).children[0]);this.remove()"></iframe>
Also lists alternatives - see how whatwg request is bogged down in what/if complexity.
Paragraphs, lists, citations and tables are fairly manageable. Arguably, though, those things are exactly what Markdown excels at.
[1]:https://motherfuckingwebsite.com/ [2]:http://bettermotherfuckingwebsite.com/ [3]:https://thebestmotherfucking.website/
It is basically a text file in a basic font being rendered on the screen. You might as well use notepad instead.
What's the point of not using CSS to make it look at least half decent? What does this improve other than the elitist standpoint that websites should be no more than an unstyled text document because this is what it was 25 years ago?
I truly do not understand the constant pushback against things looking aesthetically pleasing on HN. Not everything has to look like a console terminal spit out some text.
[1]: https://github.com/denysvitali/thebestmotherfuckingwebsite/i...
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.
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.
Or static generation? (e.g. I rolled my own)
Of course, if I want an RRS feed, I need some dynamic generation. But I also think it stops there.
But I guess my broader point is that if I have to create a shell script to quickly generate the boilerplate file stuff for a new post/page, I’m _basically_ already doing what early PHP was designed to do. And at a certain point (and again, I’m not talking about you specifically, just the movements around this so-called simplicity more generally), we’re reinventing stuff that was literally created 25 years ago for these very reasons.
I’m hardly innocent of this either. As much as I hate them, I fantasize about and start working on a new CMS or SSG at least twice a year, only to inevitably abandon my efforts once boredom/frustration sets in.
I don’t think my proposed shell script (which I don’t even use) adds any complexity. (See my other comment [1] about it.)
Of course, I agree that it can go too far, and yes, sometimes we’re reinventing old stuff, but sometimes, we’re rather discovering that something that happens to be old actually works pretty well, if not better than whatever modern method we were using.
I didn’t suggest that; I suggested something like the following:
cp -r "$1" "$2"
sed -i '...' "$2/index.html" # remove old text
Simplifying the process of creating static sites and avoiding existing tools has been tried many times and none of the solutions is really satisfying. In the end, most require "just a small script", but which is likely to grow in complexity over time. I guess creating static sites is not that straightforward so it makes sense to use existing tools to keep things simple.
I probably first came across it at PHP 3, it was quite a step up from SSI for my frame based site.
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.
HTML is still a bit burdened with presentation vs semantics, although CSS has obviously helped a great deal.
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.
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.
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.
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.
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).
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.
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.
I had a similar thought though, and I think that custom components should still make it possible.
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.
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"...
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.
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.
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 :-)
Depending on the generator you chose, it might be a single binary rather than a gazillion of tools.
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/ [2] http://jjcm.org/blog/how_to_play_pa/
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.
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.
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.
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.
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 :).
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...
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
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?
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.
I've redone this page several times because the plots for it evolved on other pages, and I re "copy-pasted" the code back then: https://wordsandbuttons.online/interactive_guide_to_homogene...
>>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.
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.
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.
How is subsequent speed increased? In case of static pages everything but content is already cached.
Add the "defer" attribute to the script tag. This will cause the script to be ran after initial page load, and nothing will be waiting on it. This (along with NoScript, browsers that don't fully implement JS, etc.) is the reason for including anchor link fallbacks in the initial HTML payload. If the user clicks a link before the script is ran, the site behaves acceptably.
>How is subsequent speed increased? In case of static pages everything but content is already cached.
Let's say a user is browsing a blog they've never been to before, going between posts. There's a blogroll on the side of the layout that doesn't change between posts. Every time the browser requests a new static page it has to request this blogroll (as well as everything else) and render it all over again. Any images, scripts, and stylesheets used between pages will be cached, but the browser won't know which bit of text was for the blogroll versus the content; there's no real distinction in the DOM. Even for the elements that are cached, they'll be rendered all over again. The request time is practically nothing (just a cache check), but it's more time consuming to have the DOM render a cached image than it is to do nothing to an image that is already rendered and sitting in front of the user. Changing less is is less expensive than changing more, in terms of render time.
I'm definitely going to look at Emmet, though. Thanks to all for mentioning it!
Otherwise I adore the idea and I find it lovely! :)
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.
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/ (Found through a quick search for "jekyll structure").
[1] https://git.uberspace.net/homepage/tree/tools
As to writing practical web pages, I'm working on it, ;) The pages/blog you see on sgmljs.net are completely produced by SGML.
One of my friend just did her website all alone, and it's amazing: http://ivana.su - best page of the internet.
https://web.archive.org/web/20011102031149/http://www.mighty...
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.).
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.
> 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.
https://github.com/acdha/simple-cloud-site/blob/master/simpl...
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... extracts to http://microdata-extractor.improbable.org/extract/?url=https... without any need to be careful updating the system because if it didn't, the missing data would be immediately obvious.
I still keep my personal blog written in plain HTML with a wee bit of CSS to give it personality. It just works so well!
Of course, working out how to make this convenient to use is going to be the tricky bit...
Maybe mine was more like a nanoblog...
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.
There isnt really a way to hack into a HTML only site. With a CMS however thats different.
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.
Personally, I'm lazy, and tend to prefer at least a little bit of automation.
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...
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.
Or you could just spend 15 minutes trying to patch your existing site generator to suite your needs. This article sucks. Downvote.
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.
That was years ago when I did that. I won't do it again.
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.