6 ms·

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

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.

masswerk 7y ago
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 and is a bit of a hassle. ( is still an abstract concept like , 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.
- stan_rogers 7y ago
 Both and live on for traditional typographic use that doesn't imply emphasis (or a heading). 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).
 - masswerk 7y ago
 However, if we're using – as it happens – and 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 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).
- nfoz 7y ago
 HTML5 undeprecated the and tags. https://www.w3.org/International/questions/qa-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: and mean bold and italics. - Then the semantic folks took over, deprecated these tags, and say you have to use and instead. - Now with HTML 5 the and 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.
 - masswerk 7y ago
 Ah, yes, I just noticed. Wasn't this marked as deprecated in HTML 5.2? Now the Living Standard explicitly notes that 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 () 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".)
 - masswerk 7y ago
 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 and . (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.)
- masswerk 7y ago
 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/ https://www.masswerk.at/nowgobang/
baroffoos 7y ago
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.
- roywiggins 7y ago
  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 https://www.w3schools.com/tags/tag_frameset.asp
  - notahacker 7y ago
    iframes aren't deprecated. I'm only half joking...
- mrweasel 7y ago
  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 7y ago
    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.
- DrScientist 7y ago
  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 https://github.com/jakearchibald/streaming-include
john-aj 7y ago
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.
petepete 7y ago
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.

masswerk 7y ago

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 and is a bit of a hassle. ( is still an abstract concept like , 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.

stan_rogers 7y ago
Both and live on for traditional typographic use that doesn't imply emphasis (or a heading). 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).
- masswerk 7y ago
 However, if we're using – as it happens – and 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 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).
nfoz 7y ago
HTML5 undeprecated the and tags. https://www.w3.org/International/questions/qa-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: and mean bold and italics. - Then the semantic folks took over, deprecated these tags, and say you have to use and instead. - Now with HTML 5 the and 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.
- masswerk 7y ago
 Ah, yes, I just noticed. Wasn't this marked as deprecated in HTML 5.2? Now the Living Standard explicitly notes that 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 () 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".)
 - masswerk 7y ago
 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 and . (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.)
masswerk 7y ago
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/ https://www.masswerk.at/nowgobang/

baroffoos 7y ago

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.

roywiggins 7y ago
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 https://www.w3schools.com/tags/tag_frameset.asp
- notahacker 7y ago
  iframes aren't deprecated. I'm only half joking...
mrweasel 7y ago
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 7y ago
  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.
DrScientist 7y ago
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 https://github.com/jakearchibald/streaming-include

john-aj 7y ago

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.

petepete 7y ago

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.