[HN Gopher] Next Gen Static Blogging
___________________________________________________________________
Next Gen Static Blogging
Author : mmackh
Score : 179 points
Date : 2021-01-09 15:25 UTC (7 hours ago)
(HTM) web link (inoads.com)
(TXT) w3m dump (inoads.com)
| pickpuck wrote:
| If the only thing being removed were <div> tags, which don't have
| structural or semantic meaning, it would probably be just as easy
| to parse for screen readers and robots.
|
| Two problems I see:
|
| 1. Where you have a heading you may want it and its associated
| content wrapped in a <section>. Where you have a separated
| paragraph you really do probably want a <p>.
|
| So these newlines aren't always just replacing <div>s. The page
| has no structure except what can be derived from headings.
|
| 2. Wrapping everything in a <code> tag seems like it could cause
| issues. It would probably be better to use <main> and apply the
| clever one line of CSS mentioned in the post.
| thayne wrote:
| So how would you do a code snippet with syntax highlighting?
| kome wrote:
| it's like a, messy, non-standard semantic web... at this point,
| and i'm totally serious, why not starting again to work on XHTML
| 2.0 standard? We need it badly.
| arvindamirtaa wrote:
| A neat little css property aside, isn't the separation of
| concerns a cornerstone of web pages?
|
| Html - structure of the document CSS - appearance JS -
| interactivity
|
| I could be wrong, but that's how I remember it. Is there an
| advantage to moving away from this fairly simple and unambiguous
| paradigm?
| k__ wrote:
| Separation of concerns is still seen as the way to go. People
| just have different opinions about what a concern is.
|
| It started with markup, styling, and interactivity. But many
| people think, this is a too technical perspective and software
| should be split up into non-technical concerns (i.e.
| microservices).
| tannhaeuser wrote:
| This structure vs appearance dichotomy was added after the
| fact, though, since CSS came significantly later than HTML. It
| has been used as a (misguided IMO) narrative to defend CSS's
| complexity and redundancy and is partially to blame for HTML
| and the web ceasing to be a straightforward medium for simple
| publishing, seized by big media and ad networks.
| [deleted]
| Brajeshwar wrote:
| Cool. Go one step further and render the CSS inline.
|
| Of late, I have been writing with just MarkDown and dropping in
| some of the simplest tool (Pandoc, Jekyll) possible to render as
| HTML.
| smlckz wrote:
| Here's some crazyness:
| https://dataswamp.org/~solene/2019-08-26-minimal-markdown.ht...
|
| I suppose it is not much hard to translate this into PHP...
| icy wrote:
| I built mawkdown[0] off of solene's initial awk
| implementation!
|
| [0]: https://github.com/icyphox/mawkdown
| smlckz wrote:
| I do not have much experience in awk, but after reading
| Solene's and your code, I am curious about why < > are
| escaped with \ ?
|
| In your m.awk, I also noticed that the markdown formattings
| (bold, inline and links) are not turned off in code blocks.
| xwdv wrote:
| This is ridiculous, only two articles on this blog and one is
| about static blogging.
|
| In the next generation, I implore people to focus on _content_ ,
| not the tech.
| mmackh wrote:
| Yep, this is not my first run at blogging. Looking forward to
| writing more content.
| xwdv wrote:
| I'll be watching to see if you do.
| teekert wrote:
| Yeah if browsers would just render markdown nicely that'd be
| great.
| codazoda wrote:
| I ran to my desktop to load this up and have a look. I'm ALWAYS
| looking for a more simple blogging solution. I was hoping for
| mostly plain text plus an em tag here or there. It's a little
| more involved than that, but it's given me some ideas.
|
| Shameless plug, I created the NeatCSS framework to have this
| "simple" look and feel. On that, however, I didn't try to avoid
| your typical HTML code.
|
| https://neat.joeldare.com
| clintonb wrote:
| > I'm ALWAYS looking for a more simple blogging solution.
|
| Why?
| unicornporn wrote:
| > Once you choose the technology that runs your blog, use it.
| Don't replace it, ever. Never ever rewrite it.[1]
|
| [1] https://macwright.com/2019/02/06/how-to-blog.html
| clintonb wrote:
| The antithesis of this is exactly why I asked the question.
| I was reminded of a tweet/post describing that most blogs
| have a single post: the one that describes how the author
| built their own static site generator/blog framework. After
| that, they are too tired/unmotivated to write anything
| else.
|
| I was on WordPress. Now I'm on Jekyll. I occasionally think
| of changing the theme, then I remember how little that will
| benefit me or my few readers.
| approxim8ion wrote:
| This is good advice, for anything that can be tinkered
| with. Just as applicable to setting up a window manager on
| Linux, for example. It's an amazing rabbit hole, but it can
| consume you.
| ricardolopes wrote:
| Interesting concept. This seems to simplify the writing part.
| What about the rest? Is the list of posts generated automatically
| (if so, how?), or does it require manual management? Do you need
| the code tag, or could it be something more semantically
| relevant, such as article?
| Tomte wrote:
| You can have it auto-generated using directory indexes in
| Apache. You can even customize them (within limits).
|
| I've toyed with having a minimal blog, where I simply drop text
| files with file names beginning with their date in a folder and
| rely on directory indexes as a "home page".
| ricardolopes wrote:
| I too was toying with a similar idea, but was finding the
| devil was in the details.
|
| For instance, you want to sort by publish date, which isn't
| the same as file creation date. If you add it to the file
| name, to sort by that, then you can no longer use file names
| for urls, at least without some transformation.
|
| So I was really curious how others were dealing with that in
| a clean way.
| iamtedd wrote:
| I found that using w3.org's CSS validator shows reference to
| the page's URI as '[...].php'. http://jigsaw.w3.org/css-
| validator/validator?uri=https%3A%2F...
|
| With that and the author's mention of using PHP for a custom
| blogging setup, I'm guessing it's being dynamically generated
| by PHP still.
| toddmorey wrote:
| Build setups can get complicated and simple sites can send way to
| much javascript to the browser. But neither one of these are
| required outcomes.
|
| I think it's ok to have build tools that do small automations to
| make writing more pleasant yet keep the markup semantic and
| accessible.
| demifiend wrote:
| I'm glad I'm not so blind that I need a screenreader for this
| site, because @mmackh doesn't seem to have given any
| consideration to accessibility.
|
| https://wave.webaim.org/report#/https://inoads.com/articles/...
|
| If this is "next gen", I think I'll stick to using emmet-mode in
| Emacs to write raw HTML, templating with m4 macros, validating
| with tidy, and doing the build and deployment with a makefile.
| richsu-ca wrote:
| Made me realize my own site needs work. Thank you for sharing
| this
| rayrag wrote:
| I bet that blind people can't wait for next 'next-gen' static
| blogging:
|
| html::after { content: "Welcome to my blog" }
| demifiend wrote:
| Whenever people do stuff like this, alternative text
| protocols like Gemini make more sense.
| Ryan_Goosling wrote:
| I thought the crowd on HN was more technically versed than this
| post. This self-titled "next-gen" blogging solution disregards
| SEO and accessibility. Am I wrong?
| tomtomtom777 wrote:
| I like the white-space: pre-line trick and very much like the
| omission of unnecessary <html> and <head> tags as the parsing of
| such valid source is neatly prescibed.
|
| But abusing <code>, <h4> and <h5> like that is a horrendous and
| pointless. Please use the proper tags to keep the web clean.
| Tomte wrote:
| It is a neat idea, but the purist in me misses those <p> tags,
| even though they are the main reason why I don't like writing
| HTML by hand.
| Izmaki wrote:
| What about the standard
| <html><head>...</head><body>...</body></html> tags?
| Tomte wrote:
| What about them? They occur exactly once, and I probably have
| a prepared file with them already in it.
|
| But for every paragraph I write I need to type <p> (and maybe
| even </p>, if I choose to).
|
| That's exactly the use case for Markdown, to get rid of that
| tedious stuff.
| schwartzworld wrote:
| A lot of modern text editors will let you type 'p' and then
| tab and they will create the opening and closing tag for
| you.
| Tomte wrote:
| Sure, I can type "<p", but that's still annoying.
|
| Look, I don't hate hand-written HTML. I actually like it
| better than Markdown.
| z3t4 wrote:
| What about Enter, Enter to get <p>|</p>
| Tomte wrote:
| I'm not interested in you selling me an editor or IDE.
|
| And I have zero idea why you all insist that I _must_
| love writing HTML.
|
| Leave me alone!
| JimDabell wrote:
| All of those tags are optional. It's perfectly valid to omit
| them.
| iamtedd wrote:
| Not according to w3.org's validator. https://validator.w3.o
| rg/nu/?doc=https%3A%2F%2Finoads.com%2F...
|
| Edit: Actually, seems you're right. Though doctype is not
| there, and there are other problems with the markup.
| Tomte wrote:
| Correct, documented at https://html.spec.whatwg.org/multipa
| ge/syntax.html#optional-...
| andyp-kw wrote:
| Maybe an expert can confirm, but my understanding is that this
| would be poor from an SEO standpoint.
|
| I don't really see how this can be next-gen when it strips out
| any semantic elements.
| timwis wrote:
| Wow, never heard of that CSS property -- cool!
|
| Regarding medium, I think the biggest barrier is the
| network/promotion you get from medium. Discovery and sharing
| within the network brings audiences you'd otherwise have to work
| quite hard for on your own site.
| swsieber wrote:
| IIRC there is some sort of tool for generating inter-blog
| links. Maybe by our stavros? My memory is fuzzy here.
| MaxBarraclough wrote:
| You can always publish on both Medium and your own blog.
| https://indieweb.org/POSSE
| sedatk wrote:
| It's funny that we've come full circle. The web had started with
| static web sites. Many of them had misused HTML tags to take
| shortcuts, and to achieve a certain look, including `<pre>`,
| `<table>`, etc. That had eventually caused so many compatibility
| issues that we thought malformed documents were a problem, so we
| defined a rigid structure for HTML called XHTML. We discovered
| the value of semantics and separated style from content with CSS.
| Then, we thought XHTML was too much work and just went back to
| loose style with HTML5 for ease of use. Then, people thought CSS
| was so much work that they applauded Tailwind for brining styling
| back into HTML. And three decades later, "next-gen static
| blogging" is about misusing HTML tags to take shortcuts, and to
| achieve a certain look. :)
| still_grokking wrote:
| Given that we're paying per CPU-seconds and MBs transmitted
| while running our stuff again on mainframes (The Cloud) this
| makes perfect sense, doesn't it?
| sradman wrote:
| <body style="white-space: pre-line"> The idea is that
| an extra newline within a block with style="white-space:
| pre-line" acts like <p> paragraph elements.
| This is a separate paragraph. </body>
| mmackh wrote:
| Author here: Sorry for not considering accessibility more. I use
| solarize everywhere - I'll look into fixing the low contrast
| issue. As for whether my approach is correct from an SEO or HTML5
| validation perspective - evidently not. But I do value the
| feedback and will take your comments into consideration when
| expanding my personal site. It's still a WIP.
| angus_gh wrote:
| You could also override the font-family of the main <code> to
| make it more readable; since it isn't code there's no need to
| use a monospace font. body code {
| font-family: sans-serif; }
| akkartik wrote:
| https://developer.mozilla.org/en-US/docs/Web/CSS/white-space...
| MoOmer wrote:
| This was my experience...
|
| 1. Read first sentence, Take a look at the
| source code of this page - I rely mostly on CSS for the rendering
| of this article.
|
| 2. Right click, "View Page Source" on Firefox (`84.0.2
| (64-)bit)`) Edit: adding that I do have
| `NoScript 11.1.8` and `uBlock origin 1.32.4` installed.
|
| 3. Close source pop-up/tab.
|
| 4. It takes ~10 seconds to re-render the page (with spinner gif
| running, in the meanwhile).
|
| 5. Tab completely frozen.
| codingdave wrote:
| Excellent performance, sketchy accessibility. But I applaud the
| effort to look for simplicity, even if it wouldn't work for many
| production use cases.
| egeozcan wrote:
| If I'm understanding correctly, here, the semantic value of the
| <code /> element is ignored to increase DX.
|
| I personally wouldn't make that compromise, why is pre-processing
| not simple enough?
| lobsang wrote:
| You could use <article /> instead (which I probably would).
| Jest tested it using dev tools, seems to work.
| z3t4 wrote:
| Using some HTML elements like section makes Safari switch to
| "reader" mode. Which is broken.
| chrismorgan wrote:
| The outer <code> here is simply a very poor choice due to what
| I can only imagine is ignorance. It would be better removed,
| and the `code` rule in the stylesheet changed to `body` and
| `font-family: monospace` added. (And `code code` would need to
| be changed to `code`.)
| robertoandred wrote:
| Why is he bragging about being awful at web dev? <p> tags exist
| for a reason. You're not cool for omitting them, you're hurting
| your users.
| beefman wrote:
| Is this better than my 2001 solution of wrapping everything in a
| <pre> tag?
|
| http://lumma.org/microwave/
| dasil003 wrote:
| Main benefit I see is text wrapping on small viewports
| Tomte wrote:
| Also a neat idea!
|
| That's like a text file blog, but with the ability to have real
| hyperlinks.
| hashkb wrote:
| > No need for JavaScript or any other complicated backend or
| client-side frameworks. I can use PHP to introduce dynamic
| elements to the page, but that's optional.
|
| This isn't the same "dynamic" - the author must know that JS can
| provide interaction without a page refresh; PHP (alone) cannot.
| onion2k wrote:
| I think it's a bit of a shame that this discussion has focused on
| the tech and (slightly odd) HTML choices here. Those are probably
| the least interesting parts of any discussion around what a "next
| gen" blog platform might look like.
|
| Where the author is correct about next-gen blogging (in my
| opinion anyway) is in the attempt to reduce the friction to
| publishing a new post. What tech stack you use, whether it's
| static, what your HTML looks like, are all entirely secondary to
| whether or not you actually use your blog to build a corpus of
| content that shows off your opinions, expertise, and insights
| over time. That's what a blog is. It isn't HTML tags and CSS.
| It's the content within the tags. For me any next-gen blog tech
| has to make 3 things trivially easy -
|
| - it needs to be simple to set up and maintain. If my laptop dies
| and I can't just clone my blog's repo and run a couple of
| commands to get back to where I was it won't work.
|
| - it needs to be _really_ simple to publish a post. Most blogs
| use Markdown with either front matter or a specific file path.
| That 's OK but it puts most of the cognitive load on me. I'm sure
| there's a better way but I don't know what it is. I use 11ty for
| my blog which is very good, and if I didn't worry about URLs as
| much as I do it would be could actually work. But I do.
|
| - there's nothing that pushes me to write more. This is the
| kicker, and no one has ever solved it. I think a blog platform
| that recommends posts I should write, and that praises me for
| writing, would drive me to actually write far more than I do. So
| far the only blog platform I've seen come close is Hashnode, but
| even that doesn't do it very well.
| rayrag wrote:
| Author created static website where he manually links to each
| page and he claims this is 'next-gen' of blogging. You know
| what's next gen of blogging? Substack. You know why? It's
| because for most people rss is "hard" to use (mostly because
| they aren't familiar with it, thanks Google!), meanwhile
| everyone is familiar with email clients.
|
| Author says: > Managing this blog is a little more involved
| than dynamically generating everything.
|
| and
|
| > Simplicity is key.
|
| If he will blog for long enough that simplicity might become a
| technical debt. Right know this 'next-gen' blog doesn't even
| have an rss feed.
| billbrown wrote:
| For me, the power of a blogging platform is in automating
| boilerplate. This lacks:
|
| - search - categories - RSS - archive pages -
| header/footer/navigation
|
| It's great that the content area is simpler, but if I just
| typey-typey for the blog post and then have to manually create
| backlinks and the RSS feed item then forget it.
|
| There is such a thing as _too_ simple.
| jl6 wrote:
| IMHO blogs are documents, and HTML is no longer designed for
| documents but web applications.
|
| Blogs need to go back to document publishing formats.
|
| I'm switching to PDF/A: https://lab6.com/0#page=2
| lawwantsin17 wrote:
| Cool. But yellow on green is more readable?
| chiefalchemist wrote:
| How does this play with Assistive Technology?
| lrossi wrote:
| Even simpler: serve txt files. Browsers display them just fine.
| meisel wrote:
| Agree that static blogging is nice, but I think this specific
| look needs some tweaking - for example, there's too low contrast
| in color between the links and the background at
| https://inoads.com/blog
| zbrozek wrote:
| I had to copy all the text out into a text editor to be able to
| read the article, not just the links. Contrast is out of vogue
| I guess.
| hedora wrote:
| I don't understand the current fashion of making everything
| off-gray on off-gray. I guess it keeps designers employed.
| conductr wrote:
| Hypothesis: Whenever you're building it, you spend hours
| looking at it, and want to reduce harshness of contrast.
| The reader is only going to spend 5 minutes and prefers
| contrast as it allows quick scanning of the text.
| mmackh wrote:
| Thanks for the feedback. The colour scheme uses
| https://ethanschoonover.com/solarized/ as a foundation. This is
| how I have all my editors / IDEs set. I'll look at implementing
| this next: https://developer.mozilla.org/en-
| US/docs/Web/CSS/Media_Queri...
| varajelle wrote:
| What I think is missing for static blogs are comments.
| demifiend wrote:
| I can't and won't speak for anybody else, but if I wanted to
| provide random strangers with a free soapbox I wouldn't bother
| with a static blog. I'd just fire up a new Fediverse instance.
|
| IMO, there's no need for comments. If people can't either send
| you an email or quote your blog with a link in their own blog,
| then they probably don't have much of value to say.
| martinsb wrote:
| How well is this handled from the accessibility point of view? I
| imagine that wrapping text in consecutive "p" tags is
| semantically clearer, however on the other side it shouldn't be
| too hard for any accessibility software to recognize this pattern
| described in the article.
|
| EDIT: some wording changes.
| chinathrow wrote:
| I think you have the year off by one (2020) on your datestamp.
| mmackh wrote:
| Thank you, completely missed this.
| john-doe wrote:
| If you're into the monospace look, .txt is cool too.
| Ryan_Goosling wrote:
| epic
| giantrobot wrote:
| For the web plain text is pretty terrible. Web browsers are
| terrible plain text readers, mobile browsers doubly so.
|
| Browsers render content in a "viewport". On the desktop the
| viewport width is the width of the window but on mobile
| defaults to 960 CSS pixels (pixels adjusted for screen DPI).
| When a page is rendered it's as if the browser window is 960px
| wide. This can be controlled with the viewport meta tag where
| you explicitly tell the browser the viewport is the window
| width, on desktop browsers that doesn't change anything but
| mobile browsers use their screen width rather than the default.
|
| When it comes to plain text there's no way to tell the browser
| to do that. So if the plain text doesn't have a hard column
| wrap it's rendered as if it's in a 960px wide window. If it
| _is_ hard column wrapped it 's probably to some common terminal
| width like 40 or 80 characters. At 80 characters the default
| font size ends up causing really awful wrapping in the
| viewport. Pinch to zoom doesn't change the font size but the
| viewport magnification do that doesn't help readability.
|
| You also lose hyperlinks and in-line images. The web could do
| with fewer stupid images bulking up pages but without
| hyperlinks you don't really have a web. Putting all links at
| the bottom of a document HN style isn't a great solution.
| Visitors still need to copy and paste links which is a pain in
| the ass at best and inaccessible at worst.
|
| If you want a monospace "look" just put 'body {font-
| family:monospace;}' in a style tag and you're all done. You get
| all the benefits of a real HTML document and the terminal chic
| of a monospace font. Don't waste everyone's time with plain
| text on the web.
| heroku wrote:
| I've built the simplest static site generator.
| https://github.com/eguneys/jener
| throwaway4good wrote:
| So instead of a body tag you have a code tag?! Is that next gen?
| Ennea wrote:
| That <date> tag you are using does not exist in the specs. You
| may want to change that to <time>.
| Ryan_Goosling wrote:
| So I'm guessing this isn't accessible for screen readers?
| chacha2 wrote:
| It would be nice to read a static blog that talks about more than
| creating a static blog.
| thotsBgone wrote:
| > The experience to writing this blog entry is very similar to
| using a dedicated word processor
|
| Except for the fact that a word processor does more than break
| lines. For example, when you type ", your word processor will
| convert this to a left opening quote or a right closing quote
| based on context. But the " in this article are still ". I guess
| they could have used a word processor after all.
| rayrag wrote:
| So, instead of using semantic html and css like 'white-space:
| pre-line' and 'max-width: 40ch' author wrapped content of his
| blog post into 'code' tag and called it 'next-gen'. What is
| 'next-gen' about it? Either I am missing something or I'm not
| drunk enough. Worst thing it has 100 upvotes :/
|
| >Simplicity is key
|
| This isn't simplicity...
|
| I need a beer.
| rpdillon wrote:
| The CSS the author uses (style.css) has both 'white-space: pre-
| line;' (line 6) and 'max-width: 640px;' (line 18).
|
| https://inoads.com/style.css
| rayrag wrote:
| Then he could use div tag instead of code tag but then it
| wouldn't be 'next-gen' I assume.
| ilovefood wrote:
| I wholeheartedly agree with you but there isn't any amount of
| beer or misuse of standard HTML tags that could fix this. It
| kind of anti-resonates a lot with the other post currently on
| the front page "Woo for its own sake". It also shows how the HN
| crowd is split in two, those who like this kind of stuff and
| those who don't. For my part and in my day job these are the
| kind of things that I actively fight against. As a fun exercise
| I still appreciate OP's effort for trying out something new,
| it's always welcomed and I think this forum is all about that.
| However, I don't agree with the clickbaity title techniques. I
| hope it doesn't normalize the practice here otherwise I'd throw
| in some Vodka as well :)
| susam wrote:
| Note that closing </p> tags are optional _+_ , so one can be an
| HTML purist and still write a decent HTML document with a
| relatively clean markup like this: <!DOCTYPE
| html> <html lang="en"> <title>Lorem Ipsum</title>
| <h1>Lorem Ipsum</h1> <p> Lorem ipsum dolor sit
| amet, consectetur adipiscing elit. Duis id maximus
| tortor. Sed nisi ante, fermentum vel nunc et, tincidunt
| sagittis magna. In ultrices commodo lacus, id tristique
| ipsum euismod laoreet. <p> Maecenas at neque
| posuere, aliquet erat at, vehicula est. Duis aliquet elit
| et arcu laoreet, id pulvinar eros pretium. Quisque
| consectetur, enim semper facilisis feugiat, velit sapien
| semper arcu, eu mollis libero est et odio. <p>
| Curabitur fringilla interdum ante vel ultricies. Mauris
| volutpat nisi sed turpis elementum elementum. Mauris nec
| eleifend lorem. Sed ac vulputate libero.
|
| A valid HTML5 document does not require _+_ explicit <head>,
| <body>, or the closing </p>, </html> tags. See the spec for
| optional tags at
| https://html.spec.whatwg.org/multipage/syntax.html#optional-...
| for more details. Similarly, the markup for lists and tables can
| be cleaned up too because the closing </li>, </tr>, </th>, </td>
| tags are optional _+_.
|
| Note that the opening <html> tag is optional _+_ too but I
| retained it in the above example to specify the lang attribute
| otherwise the W3 markup validator warns, "Consider adding a lang
| attribute to the html start tag to declare the language of this
| document."
|
| _+ These tags are optional provided certain conditions are met.
| See the spec for full details. In practice, one rarely has to
| worry about these conditions._
| chrismorgan wrote:
| And since we're talking about optional things:
| <link rel="stylesheet" href="/style.css" /> <meta
| name="viewport" content="initial-scale = 1.0,maximum-scale =
| 1.0" />
|
| Trailing slashes on HTML tags are useless. They're _allowed_ on
| void elements, for XML compatibility, but are by definition
| simply ignored. I recommend against including them, because
| they're simple visual noise, and misleading because they don't
| actually close tags--you can only use them on on elements that
| are defined as having no children.
|
| (Note that I say _HTML_ tags; on foreign elements--meaning
| inline SVG and MathML--trailing slashes _do_ make tags self-
| closing, XML-style.)
|
| Also since I'm writing, that viewport declaration is wonky. It
| should have device-width, and it should not have maximum-scale
| which is user-unfriendly.
|
| All up: <link rel="stylesheet"
| href="/style.css"> <meta name="viewport" content="device-
| width,initial-scale=1">
|
| And for completeness,
| https://html.spec.whatwg.org/multipage/syntax.html#elements-...
| defines void and foreign elements.
| kubanczyk wrote:
| > the opening <html> tag is optional too but I retained it in
| the above example to specify the lang
|
| > <html lang="en">
|
| Yeah, no. The text is in Latin (la), not in English (en).
| susam wrote:
| ~Any references to support your claim?~
|
| _[Edit: I notice now that the content is indeed written in
| Latin. It contains the "Lorem Ipsum" placeholder text. Nice
| catch! :-)]_
| Natfan wrote:
| To be fair, you _did_ write your post in Latin:
|
| > Lorem ipsum dolor sit amet, consectetur adipiscing elit.
|
| > Duis id maximus tortor. Sed nisi ante, fermentum vel nunc
|
| > et, tincidunt sagittis magna. In ultrices commodo lacus,
| id
|
| > tristique ipsum euismod laoreet.
| teekert wrote:
| Hmm I always thought lorem ipsum was a text with letter
| usage histograms similar to English, without distracting
| the reader with meaning. I could have sworn I read that
| somewhere...
| spijdar wrote:
| Lorem ipsum is words/phrases copied from one of Cicero's
| writings, "De finibus bonorum et malorum". It's not a
| straight copy, kind of like if you copied every other
| word in places, but it's definitely Latin.
|
| It does likely have relatively similar usage patterns to
| English in terms of letter distribution, if only because
| they're both indo-european languages and English has deep
| vocabulary ties to Latin through Norman influences.
| pvorb wrote:
| This is true. And still it is (nonsensical) Latin. It's
| chosen because Latin looks quite similar to English text.
| They use the same alphabet and word length tends to be
| similar.
| zwog wrote:
| You are almost right: The distribution of letters and
| length of words is similar to that of the Latin language.
| But it is not Latin and the text does not make sense.
| It's gibberish.
| datapolitical wrote:
| Those are Latin words, drawn from a Latin source.
|
| "Pencil what comma building twenty section human fedora"
|
| is English, even if it makes no sense.
| thotsBgone wrote:
| The words are English words, but many would argue it's
| not an English sentence.
| brodie wrote:
| la-gb? (Latin, Gibberish?)
| galaxyLogic wrote:
| This is great point. Doesn't it mean that "markdown" is kind of
| redundant ?
| tannhaeuser wrote:
| That's right, but it's probably more interesting that HTML 5
| simply hard-coded these rules based on the tag inference
| features of SGML and the particular per-element tag omission
| indicators of HTML 4 and earlier SGML DTDs for HTML (see links
| on how head and body elements in your example document are
| inferred by SGML in detail).
|
| [1]:
| https://www.youtube.com/watch?v=jy-b4jeJSas&list=PLQpqh98e9R...
|
| [2]: http://sgmljs.net/blog/blog1701.html (the "Talk" link for
| slides)
| fsiefken wrote:
| It would be valid, but wouldn't Google penalize it for being
| poor html?
| still_grokking wrote:
| Please never ever break XML compatibility!
|
| Not having valid XML in the first place complicates any further
| processing quite a lot. Also you're going to run into annoying
| and / or strange issues with tooling.
|
| Those HTML shortcuts are just not worth it. Their value is
| "questionable" (to put it kindly) but down the road their cost
| can become surprisingly high.
| cwackerfuss wrote:
| Frontend developer here --
|
| Although you could omit the closing tags, I don't see the
| benefit of doing so. If you know HTML, nesting is fundamental
| and not explicitly closing dom nodes would lead to confusion.
| You would also need to concern yourself with the "certain
| conditions" that must be met for it to work. Consistency and
| clarity over brevity!
| breck wrote:
| The man who collects rocks in his pockets eventually drowns.
| majormjr wrote:
| Especially with HTML as it's going to get minimized and
| hacked up to reduce the filesize. Including the closing tags
| makes the transpilers job easier and less error prone.
| susam wrote:
| A transpiler that gets confused when optional tags are
| missing (a feature explicitly allowed by the spec) is a
| broken transpiler and it needs to be fixed. This is like
| the automatic semicolon insertion of JavaScript
| debate[1][2] all over again. These things are spelled out
| in the standards and tools that do not adhere to the
| standards are broken.
|
| [1] https://web.archive.org/web/20201206065632/http://inimi
| no.or...
|
| [2] https://blog.izs.me/2010/12/an-open-letter-to-
| javascript-lea...
| chrismorgan wrote:
| I write plenty of HTML by hand, for myself. I prefer to omit
| things like </p>, </li>, </td> and </tr>, because it takes
| less effort (and I hate text editor plugins that
| automatically add closing delimiters of any form, because
| they _always_ do the wrong thing a meaningful fraction of the
| time in a way that I have to think about, more than if I just
| type the delimiters myself, though an accurate "insert at the
| cursor whatever is needed to close the last thing" shortcut
| might be handy), and reduces visual noise.
|
| I also normally omit quotes on attribute values if correct to
| do so.
|
| I mostly do these things when working on things of my own,
| when I know no one else needs to worry about them. When
| working on things others will touch, I don't drop quite as
| many closing tags, and will normally leave attribute values
| quoted.
| alpaca128 wrote:
| > I hate text editor plugins that automatically add closing
| delimiters
|
| Glad I'm not the only one. The less an editor does
| automatically to "help" me the better. I agree, a shortcut
| to close the last opening syntax element would be nice, but
| for this to work properly the editor needs to be aware of
| how all the syntax elements interact, e.g. to differentiate
| between '<' used in a logical comparison and the same
| symbol as start of an XML tag. Or to correctly close an XML
| tag no matter if it has attributes.
|
| I have a shortcut in Vim for three different kinds of
| brackets but it's a bit janky. Still better than the
| automatic stuff the typical IDE and modern editor does
| without asking, though.
| susam wrote:
| I am not a frontend developer. I agree with you. I write my
| blog posts with handwritten HTML because that is how I began
| writing blog posts many years ago when Markdown was not as
| popular as it is now. Indeed I never omit any optional tags
| while writing my blog posts or blog layout.
|
| I am not necessarily recommending that one should omit the
| optional tags. However, it is worth noting that the option to
| do so while conforming to the HTML5 spec is there. The
| "certain conditions" are not really much to worry about. I
| think they are drafted quite carefully and are quite
| sensible. If one is writing simple HTML documents, say, for
| blog posts, text-based articles, etc. one can safely omit the
| optional tags without running into issues due to the "certain
| conditions".
| ms123 wrote:
| I've been using this technique on midnight.pub as well, and it's
| working surprisingly well.
| Priem19 wrote:
| I applaud that simplicity seems to be trending, but the benefits
| of not having paragraph tags don't seem to outweigh the
| downsides. It's not that big of a deal, and it enables reader
| mode.
|
| Leaving as much as possible left to default is what I prefer; it
| supports the greatest number of browsers and assume is the
| fastest. https://www.quitfacebook.org/file/play.html
| Scaevolus wrote:
| Many static site generators, including Hugo and Jekyll, have file
| watching support and even automatic page reloads, so their
| workflow is barely different from editing raw html. You have to
| jump through some more hoops for raw html, but I expect you save
| time overall.
| ffpip wrote:
| Your site is too hard to read on. Make the color of the font
| darker or the background lighter please.
|
| I had to copy to a notepad so I could read it.
|
| Edit:
|
| Apparently, dark mode users get this -
| https://i.imgur.com/5PHYac1.png
|
| I get this - https://i.imgur.com/5PHYac1.png
|
| Light mode is terrible, dark mode is okay. Please increase the
| contrast in both places.
| city41 wrote:
| You linked the same image twice. I'm curious what the other
| image was.
|
| edit: nevermind, switched to dark mode using the dev tools. It
| looks like this just to be complete:
| https://i.imgur.com/qPv7guO.png
| bhauer wrote:
| Lower the contrast? Strongly disagree. Its use of gray text on
| a dark blue background is pretty common. If anything, the
| contrast is too low; I'd brighten the text if I were the
| designer. But it's readable.
|
| In my opinion, what makes it a bit difficult to read is the use
| of a fixed-width font for body text. Fixed width is great for
| code, but proportional-width fonts are easier for reading
| prose.
| mixedmath wrote:
| There is an interesting thing happening here. It appears the
| colors on the site are largely either similar to solarized-
| light or solarized-dark, depending on whether the user's
| browser has a dark-preference or not.
|
| The OP comment evidently looks at the light version (which is
| grey text on tan background, and which I also find a bit
| annoying to read). I would guess that the parent comment is
| seeing the dark-mode version.
| susam wrote:
| I agree with ffpip's comment. I too found the contrast to be
| too low for my comfort. Here are the colors used for the body
| element in the CSS (see https://inoads.com/style.css):
| background-color: #FDF6E3; color: #657B83;
|
| Now plug those values into
| https://webaim.org/resources/contrastchecker/ and we can see
| that this color scheme fails even the WCAG AA check (see
| https://i.imgur.com/iK7FRfU.png for a screenshot). I think
| the WCAG AA is the absolutely bare minimum accessibility
| guideline any color scheme should conform to, otherwise we
| risk making the text hard to read for many people just like
| the text in this website is hard for me to read.
| bhauer wrote:
| Ah, it seems this site is aware of my preference for a dark
| color scheme. @media (prefers-color-
| scheme: dark) { /* defaults to dark theme */
| body { background-color: #002B36;
| color: #AAA; } }
|
| You are seeing the bright color scheme and I am seeing the
| dark. So when ffpip said either "darken the text or
| brighten the background," and I'm looking at the _dark
| theme_ , that would mean _reduce the contrast_.
|
| I think we're all of the same opinion: the contrast
| should/could be higher.
| susam wrote:
| Ah! That makes sense. Indeed you had mentioned in your
| comment:
|
| > Its use of gray text on a dark blue background is
| pretty common
|
| That should have been a clue for me that you were seeing
| the dark color scheme.
| _4570 wrote:
| You can do that yourself as a one-off change using the web
| tools. On Chrome, just right click on some whitespace and click
| inspect. On the bottom right, you'll find an option to the
| change the background color of the body section. There's
| something similar on firefox as well.
|
| (ideally, the website should get the fix rather than you doing
| it... but this works better than notepad!)
___________________________________________________________________
(page generated 2021-01-09 23:01 UTC)