Comment by ibudiallo | Hacker News Reader

Comment by ibudiallo | Hacker News Reader

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.

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.

Just reach back to the other old method: framesets!

Well, don't, they're deprecated. But you could.

https://www.w3schools.com/tags/tag_frameset.asp

iframes aren't deprecated. I'm only half joking...

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.

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.

What's missing from HTML is simple client side includes.

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

Here's another approach: https://www.filamentgroup.com/lab/html-includes/

    <iframe src="/images/includespost/htmlexample.html" onload="this.before((this.contentDocument.body||this.contentDocument).children[0]);this.remove()"></iframe>

Given that Googlebot will render and use JavaScript now, I'd be intrigued as to whether this works with it, but client side it seems OK.

https://github.com/jakearchibald/streaming-include/blob/mast...

Also lists alternatives - see how whatwg request is bogged down in what/if complexity.

So do I. And I wouldn't say that HTML is difficult to write, at least, it was once made for this. However, the deprecation of <b> and <i> is a bit of a hassle. (<b> is still an abstract concept like <strong>, but the latter is 5 characters more – and this twice, once for the opening tag and once for the closing part.)

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.

Both <b> and <i> live on for traditional typographic use that doesn't imply emphasis (or a heading). <i> with a lang attribute (and, optionally, a class to indicate it's a foreign usage), f'rinstance, is the right way to italicize foreign words. And, depending on the text, those italics may be instances of <cite> or <dfn> or some such. You can - and should - pack a lot of useful metadata into HTML tagging; it can be of a lot of help to readers when typographic conventions change (as they always have throughout history).

However, if we're using – as it happens – <strong> and <em> as direct replacements, we do not gain much on the semantic side of things. "italic" is still an abstract concept to express emphasis, by convention expressed in type by a cursive script font and in handwriting by a single underline. (A double underline would be equivalent to bold and a tripple one to small caps. An alternative method used in traditional typesetting to express the same hierarchy is letter spacing by various degrees. There's nothing in HTML saying that <i> shouldn't be rendered using letter-spacing by a browser. In early browsers, it was a regular feature that the related display styles could be set by the user.)

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).

HTML5 undeprecated the <b> and <i> tags.

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.

Ah, yes, I just noticed. Wasn't this marked as deprecated in HTML 5.2? Now the Living Standard explicitly notes that <b> isn't necessarily rendered as bold (because it might be overridden by style sheets), by this loosening the connection to typographical appearance.

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".)

As a sidenote, as I now recall it, I was just too shocked by the phasing out of framesets in order to recognize the "undeprecation" of <b> and <i>. (I really fail to see where it helps, if future browsers fail to present historic documents in appropriate and meaningful context. Even more so, when 99% of these structures could be easily translated to semantic regions and landmarks, like header/banner, main, footer, aside, etc, even navigations could be inferred with ease by screen readers. Moreover, screen readers now have to support dynamic updates of isolated regions anyway in order to cope with JS frameworks. There was probably never a time, when frames would have posed that small a problem than at this point in time.)

>Now the Living Standard explicitly notes that <b> isn't necessarily rendered as bold (because it might be overridden by style sheets), by this loosening the connection to typographical appearance.

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>.

But boldness might not look like anything -- the user agent could be outputting to a brail reader for all the developer knows. This is the purpose of the redefinition.

Braille has typeform indicators that appear before the text to indicate that it's bold, italic, underline, etc. It is written differently in the sense that there's a character prefix.

http://www.brailleauthority.org/formats/2016manual-web/secti...

>in many ways the presentation is the semantics

As McLuhan said, the medium is the message

Doesn't <i> mean a fontawesome icon? /s

<b> and <i> were never deprecated. They are perfectly valid in HTML 4.01 and XHTML 1.1 and were basically treated like <span> except with default styling.

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.

Here's the blog in question [1], entirely written in HTML and a bit of CSS on the fly. That is, the body is written by hand and mangled into the blog using a few definitions in a JSON-like data file. Apparently the result isn't too bad as some posts have been featured here. (Some of the posts are rather extensive and are exceeding simple notes.)

[1] https://www.masswerk.at/nowgobang/

The HTML of an entire page might not be, but if you're only writing the _article_ and embedding it in a header/footer/nav it's really not too bad.

Paragraphs, lists, citations and tables are fairly manageable. Arguably, though, those things are exactly what Markdown excels at.

I hear you, but the benefit of HTML (especially in a WYSIWYG editor like Seamonkey that doesn’t support CSS) is that your style sheet and basic page layout is already done. When you start writing, you very rarely need to adjust it.

Reply on news.ycombinator.com