My Current HTML Boilerplate(matuzo.at)
matuzo.at
My Current HTML Boilerplate
https://www.matuzo.at/blog/html-boilerplate/
290 comments
I first saw that technique used by Moderinizr, which was a very useful tool back in IE8 days!
https://modernizr.com/
https://modernizr.com/
Website is unmaintained, check the Github repo for the lastest version.
https://github.com/Modernizr/Modernizr
https://github.com/Modernizr/Modernizr
There was a post on Metafilter highlighting a similar approach to graceful javascripting, back when javascript was a question, not an answer.
Basically, serve a page with formatting done via table layout, and then rewrite it with javascript in the client to use more modern layout tools, depending on which features were available on the browser.
Basically, serve a page with formatting done via table layout, and then rewrite it with javascript in the client to use more modern layout tools, depending on which features were available on the browser.
What's wrong with using modernizer now?
As long as you don't have to deal with IE11, cross-browser support is much better, partially due to fast release cycles. No point including a whole library if all you want to do is detect whether JS is enabled.
Edit: To be clear, Modernizr isn't a big library like jQuery and you can specify the thing you want to detect, so you can cut it down, but it's still pointless if you just want to know if JS is enabled or not.
Edit: To be clear, Modernizr isn't a big library like jQuery and you can specify the thing you want to detect, so you can cut it down, but it's still pointless if you just want to know if JS is enabled or not.
There's even a <noscript> tag since HTML 4.01. You can apply CSS to it too.
<noscript> is a blunt instrument that isn’t anywhere near as useful as you think it is.
<noscript> is pretty much a feature of the HTML parser. It disappears. The DOM representation doesn’t include a <noscript> element, so you can’t style it. (This is also why you can’t use <noscript> in the XML syntax of HTML. If you don’t know about the XML syntax, I’ll simplify and say it roughly means what was commonly called XHTML.)
What makes it even less useful is that the absence of the <noscript> content doesn’t mean that your scripts are being executed. If you use something like uMatrix or uBlock Origin to block certain types of scripts, for example, you might find that none of the scripts execute, but that the <noscript> content is also not loaded, because it could have executed some scripts, if the right URLs had been requested. Or perhaps the browser was happy to execute JavaScript, it’s just that it failed to fetch the JavaScript, for whatever reason. (Perhaps you put your JS on a CDN, on a different origin, and it’s down.)
In the end, the .no-js approach is far superior to the use of <noscript>.
<noscript> is pretty much a feature of the HTML parser. It disappears. The DOM representation doesn’t include a <noscript> element, so you can’t style it. (This is also why you can’t use <noscript> in the XML syntax of HTML. If you don’t know about the XML syntax, I’ll simplify and say it roughly means what was commonly called XHTML.)
What makes it even less useful is that the absence of the <noscript> content doesn’t mean that your scripts are being executed. If you use something like uMatrix or uBlock Origin to block certain types of scripts, for example, you might find that none of the scripts execute, but that the <noscript> content is also not loaded, because it could have executed some scripts, if the right URLs had been requested. Or perhaps the browser was happy to execute JavaScript, it’s just that it failed to fetch the JavaScript, for whatever reason. (Perhaps you put your JS on a CDN, on a different origin, and it’s down.)
In the end, the .no-js approach is far superior to the use of <noscript>.
You CAN style stuff you put in <noscript>.
Of course, if your app breaks because of browser extensions, you should handle errors gracefully, but that goes beyond the no-js classname.
I just posted this since I haven't seen it mentioned and it's fairly useful.
Of course, if your app breaks because of browser extensions, you should handle errors gracefully, but that goes beyond the no-js classname.
I just posted this since I haven't seen it mentioned and it's fairly useful.
>Of course, if your app breaks because of browser extensions, you should handle errors gracefully
Web developers don't do graceful degredation anymore.
Web developers don't do graceful degredation anymore.
Apps break even without browser extensions. A huge number of websites try to use localStorage, and do not check for errors. (localStorage will raise if the cookie settings for the UA do not permit storing data.)
> You can apply CSS to it too.
I read that as “you can apply CSS to a <noscript> tag”, which is false. Stuff within it, sure. But the <noscript> tag itself vanishes during document parsing.
I maintain my position: <noscript> is nowhere near as useful as it first appears, and should seldom be used.
I would even suggest that, excluding spiders, user agents that don’t run some or all JavaScript will normally be due to browser extensions. This is a fairly niche area overall, and various extensions are the main factor.
I read that as “you can apply CSS to a <noscript> tag”, which is false. Stuff within it, sure. But the <noscript> tag itself vanishes during document parsing.
I maintain my position: <noscript> is nowhere near as useful as it first appears, and should seldom be used.
I would even suggest that, excluding spiders, user agents that don’t run some or all JavaScript will normally be due to browser extensions. This is a fairly niche area overall, and various extensions are the main factor.
> But the <noscript> tag itself vanishes during document parsing.
This is wrong. In case the browser does not have JS (enabled) its a normal element.
This is wrong. In case the browser does not have JS (enabled) its a normal element.
I was indeed wrong about this. I’d grown used to uMatrix’s spoofing, where it does get changed, and misrecollected things. I have now refreshed my understanding from the spec: it’s still a parser feature in that that iff scripting is enabled, it parses its children as raw text (like <script> or the old <xmp>). (And then there’s the user-agent style on it, `display: none !important`, so that you can’t get it to appear whatever you do, unlike most normally-hidden tags like head, title and script.)
I apologise for misleading people.
I apologise for misleading people.
Yes, you can see it in the dev tools/inspector.
I think you're talking past each other.
To be clear, the noscript tag "disappears" when javascript is enabled in the browser. When javascript is disabled it behaves like any other tag and can be styled accordingly.
Extension can disable scripts selectively but in that case javascript is still considered enabled for the purposes of the noscript tag.
To be clear, the noscript tag "disappears" when javascript is enabled in the browser. When javascript is disabled it behaves like any other tag and can be styled accordingly.
Extension can disable scripts selectively but in that case javascript is still considered enabled for the purposes of the noscript tag.
In uMatrix, there is an option "Spoof <noscript> tags when 1st-party scripts are blocked" that shows <noscript> content.
edit: uBlock Origin shows <noscript> when the entire site's JS is disabled.
edit: uBlock Origin shows <noscript> when the entire site's JS is disabled.
I think this is the most obvious way, no? What approach did you use before?
Simple =/= Obvious.
I've also used something like this for Internet Explorer 10 detection.
Hmm, why bother even having the no-js class, then?
Because you can target it with CSS and apply styles specific for when the document is viewed without JavaScript enabled.
Is it too much trouble to just override the base style with the js style? As in, don’t specify the base style with “no-js” at all, just the js overrides.
Complicates the base case if you need to undo in it any unwanted styled applied in the no-js case.
Conceptually it's a lot easier to manage if they're fully distinct, or at least if the common bits are explicitly common.
Conceptually it's a lot easier to manage if they're fully distinct, or at least if the common bits are explicitly common.
most websites are going to be JS-first. If it makes sense for you to augment your site with JS, then sure knock yourself out and reverse it.
If javascript isn't running in the browser, the script won't run and the class won't change from no-js to js.
[deleted]
Drupal had this for quite a long time (since Drupal 5 through 8 IIRC), but there was a proposal to remove it.
I won't. Under my definition, it causes the page to stop being a document and start being an application. Being able to detect JS can be useful sometimes, but, to me, it doesn't belong in a boilerplate.
http://blog.danieljanus.pl/2019/10/07/web-of-documents/
http://blog.danieljanus.pl/2019/10/07/web-of-documents/
The web is moving on without you.
Edit: Your blog doesn't even use SSL...
Edit: Your blog doesn't even use SSL...
The “documents not applications” battle is like 10 years old at this point. The web moved on a decade ago...
I’ve had the “how to deal with folks who disable JavaScript” discussion for well over 10 years and the answer in every shop I’ve worked in has always been the same... don’t bother. And it was the developers themselves making that call, not the “business people”.
I’ve had the “how to deal with folks who disable JavaScript” discussion for well over 10 years and the answer in every shop I’ve worked in has always been the same... don’t bother. And it was the developers themselves making that call, not the “business people”.
Yeah I was being nice. It moved on so long ago I'm not sure how he calls himself a developer. Okay there... I said it.
Sometimes "the industry" "moves on without" a valuable perspective. That doesn't mean those "left behind" (e.g. Richard Stallman) should give up. Something something "marketplace of ideas."
But yeah, GP, get a Let's Encrypt certificate for the sake of your readers!
But yeah, GP, get a Let's Encrypt certificate for the sake of your readers!
OT :
What http site is left we can go to when isp or WiFi greets with a welcome login page. Going to https sites gives an error.
What http site is left we can go to when isp or WiFi greets with a welcome login page. Going to https sites gives an error.
ISPs & WiFi APs can stop trying to attack connections like that, and implement RFC 8910[1].
Otherwise… example.com, maybe. I guess we'll see how long the http version of that lasts.
I assume ISPs will get around to this a few decades after implementing IPv6.
[1]: https://tools.ietf.org/html/rfc8910
Otherwise… example.com, maybe. I guess we'll see how long the http version of that lasts.
I assume ISPs will get around to this a few decades after implementing IPv6.
[1]: https://tools.ietf.org/html/rfc8910
You are welcome to use my site: http://krazerlasers.com
You are also welcome to use my html boilerplate:
You are also welcome to use my html boilerplate:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<link rel="stylesheet" type="text/css" href="blue-white.css">"You can't argue with popularity. Well, you could, but you'd be wrong!" - Robbie Williams
Not to bring you down, but to let anyone else know, this isn't novel and has been standard practice for a decade or so.
The technique as it isn't new of course, but I doubt this specific implementation (checking for module-supporting JS) is standard practice for a decade.
[deleted]
This doesn't check for "module-supporting JS"
> [not] for a decade
Agreed, probably longer. How old is Modernizr?
> [not] for a decade
Agreed, probably longer. How old is Modernizr?
Well you're wrong because it does check that it supports modules. Go look at it more closely.
> “To let everyone know, this is not novel”
Who asked?
Who asked?
“Not to bring you down, and not adding anything useful here, but...”
It is kind of useful. I'm trained to feel dubious of anything newly invented if the underlying elements of the solution have been there for 2 decades (there must be some reason people didnt do it that way then). If this is existing practice then it sounds right.
[deleted]
No it hasn't
It’s not novel but consider how unproductive your attitude is. Someone was excited about learning something new, and you took a massive dump all over it, with no benefit whatsoever. If you’re upset that not everyone knows everything, you should be working to cultivate that excitement!
https://xkcd.com/1053/
https://xkcd.com/1053/
A few notes:
> It must come before the <title> element to avoid faulty characters in the page title.
This isn’t quite true. Rather, any meta element declaraing a charset should occur within the first 1024 bytes, or it may be ignored.
———
Print styles: you might think that putting print styles in a separate file would let the browser not load them unless the user actually seeks to print, but in practice browsers load all stylesheets, even for media queries that will never match. I think this may be for fingerprinting reasons, but I don’t truly know. In the distant past (maybe a decade ago), print stylesheets would block rendering while they loaded in most browsers. No idea whether they still do, but I’d guess (uneducated) that they may be deferred a bit now.
In light of all this, I generally recommend a small @media print { … } block in your existing stylesheet, rather than a separate print stylesheet file.
———
The favicon prefers-color-scheme thing: don’t put too much weight on this, it doesn’t actually do what people are commonly saying it does: there is only a slight correlation between prefers-color-scheme and the colour the favicon is rendered atop. prefers-color-scheme is for content, not chrome. If I recall correctly, Chrome’s incognito mode renders the tab bar dark; and in Firefox the concept of browser theme (light/dark/all kinds of custom) is completely separate from prefers-color-scheme—so I have dark browser chrome but light content.
Understand that the favicon could be being rendered atop anything at all. Any solid colour, any image, anything. Very light and very dark greys are the most common colours for them to be rendered against, but you want to make it so that your favicon is at least not horrifically bad on any background.
> It must come before the <title> element to avoid faulty characters in the page title.
This isn’t quite true. Rather, any meta element declaraing a charset should occur within the first 1024 bytes, or it may be ignored.
———
Print styles: you might think that putting print styles in a separate file would let the browser not load them unless the user actually seeks to print, but in practice browsers load all stylesheets, even for media queries that will never match. I think this may be for fingerprinting reasons, but I don’t truly know. In the distant past (maybe a decade ago), print stylesheets would block rendering while they loaded in most browsers. No idea whether they still do, but I’d guess (uneducated) that they may be deferred a bit now.
In light of all this, I generally recommend a small @media print { … } block in your existing stylesheet, rather than a separate print stylesheet file.
———
The favicon prefers-color-scheme thing: don’t put too much weight on this, it doesn’t actually do what people are commonly saying it does: there is only a slight correlation between prefers-color-scheme and the colour the favicon is rendered atop. prefers-color-scheme is for content, not chrome. If I recall correctly, Chrome’s incognito mode renders the tab bar dark; and in Firefox the concept of browser theme (light/dark/all kinds of custom) is completely separate from prefers-color-scheme—so I have dark browser chrome but light content.
Understand that the favicon could be being rendered atop anything at all. Any solid colour, any image, anything. Very light and very dark greys are the most common colours for them to be rendered against, but you want to make it so that your favicon is at least not horrifically bad on any background.
> This isn’t quite true. Rather, any meta element declaraing a charset should occur within the first 1024 bytes, or it may be ignored.
Both correct: charset before title element, and charset within first 1024 bytes.
Older browsers would infer charset automatically if not in first 1024 bytes or undefined. So if user had possibility to change the page title (for example: profile name), they could do persistent XSS by having IE infer the title contents as UTF-7, before the actual declaration happens. Sometimes the title or other elements can also be stuffed, so the charset declaration happens after 1024 bytes.
> Older versions of Internet Explorer can be tricked into interpreting the page as UTF-7. This can be used for a cross-site scripting attack as the < and > marks can be encoded as +ADw- and +AD4- in UTF-7, which most validators let through as simple text.
Modern browsers don't fall for this, but this was a huge XSS vector back in the day (for instance, Google was vulnerable to this, and maybe still is, for its users on ancient browsers).
Both correct: charset before title element, and charset within first 1024 bytes.
Older browsers would infer charset automatically if not in first 1024 bytes or undefined. So if user had possibility to change the page title (for example: profile name), they could do persistent XSS by having IE infer the title contents as UTF-7, before the actual declaration happens. Sometimes the title or other elements can also be stuffed, so the charset declaration happens after 1024 bytes.
> Older versions of Internet Explorer can be tricked into interpreting the page as UTF-7. This can be used for a cross-site scripting attack as the < and > marks can be encoded as +ADw- and +AD4- in UTF-7, which most validators let through as simple text.
Modern browsers don't fall for this, but this was a huge XSS vector back in the day (for instance, Google was vulnerable to this, and maybe still is, for its users on ancient browsers).
Fun project: create a favicon using just the right tones of gray so that it appears one way against a light background and another way against a dark background.
Related to this, alpha channels can be very useful in writing a single colour that appears as different colours against known dark and light colours. For example, see the mention of #8888 in https://chrismorgan.info/blog/dark-theme-implementation/, where that #8888 becomes effectively #bfbfbf against white, and #484848 against black.
I wish Google would pay attention to the favicon colors thing with their new icons. The new Gmail logo looks bad on pretty much every background because it has various light and dark colors in it, and isn't on its own backdrop, so pretty much any color it sits on, one of the colors kinda blends into it. It looks so bad
I generally recommend a small @media print { … } block in your existing stylesheet, rather than a separate print stylesheet file
Does it really matter anymore with HTTP2?
Does it really matter anymore with HTTP2?
Chrome is considering removing HTTP2's push feature. I use it on my websites when there's not a same-origin referrer, but apparently not many other websites use it. It's really only useful if your html + css is less than ~14000 bytes. I know it causes a lot of confusing cache issues in some cases though. The alternative "103 Early Hints" doesn't look very useful to me because it still requires a full round trip time.
https://www.chromestatus.com/feature/6302414934114304
https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL...
Not sure if HTTP2 push is what you're referring to.
https://www.chromestatus.com/feature/6302414934114304
https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL...
Not sure if HTTP2 push is what you're referring to.
Tangent:
> I totally forgot about print style sheets
You know who else seems to have forgotten about print style sheets, at least for a while? Wikipedia. Or maybe they didn't do anything and it was browser support that got worse for a while, I dunno, I shouldn't be too quick to assign blame to a specific party here.
All I remember is that years ago, if I clicked the "print page" link I would get a nicely styled printable version with minimal markup. It was a great way to get a "light markup" version of the page before browsers had built-in "reader view" tools.
Then for a while it just gave me a terrible¹ webpage version - basically showing the left menu bar and the huge logo when trying to print the page. Now it seems to have print style-sheets again, but with a "no longer supported" warning when used on a screen (not visible when printing though). See and compare:
https://en.wikipedia.org/wiki/CSS
https://en.wikipedia.org/w/index.php?title=CSS&printable=yes
¹ terrible in the context of printing, I'm not hating on the regular webpage here
> I totally forgot about print style sheets
You know who else seems to have forgotten about print style sheets, at least for a while? Wikipedia. Or maybe they didn't do anything and it was browser support that got worse for a while, I dunno, I shouldn't be too quick to assign blame to a specific party here.
All I remember is that years ago, if I clicked the "print page" link I would get a nicely styled printable version with minimal markup. It was a great way to get a "light markup" version of the page before browsers had built-in "reader view" tools.
Then for a while it just gave me a terrible¹ webpage version - basically showing the left menu bar and the huge logo when trying to print the page. Now it seems to have print style-sheets again, but with a "no longer supported" warning when used on a screen (not visible when printing though). See and compare:
https://en.wikipedia.org/wiki/CSS
https://en.wikipedia.org/w/index.php?title=CSS&printable=yes
¹ terrible in the context of printing, I'm not hating on the regular webpage here
Must-have extension to use before printing anything:
https://addons.mozilla.org/en-US/firefox/addon/aardvark-duex... (based on https://www.karmatics.com/aardvark/ which is a bookmarklet hence does not work with Content-Security-Policy enabled pages)
It allows to easily and quickly remove stuff from webpages, without opening devtools. Just hover over unwanted element, keep clicking `w` (wider) until you have its whole container, then `r` to remove.
https://addons.mozilla.org/en-US/firefox/addon/aardvark-duex... (based on https://www.karmatics.com/aardvark/ which is a bookmarklet hence does not work with Content-Security-Policy enabled pages)
It allows to easily and quickly remove stuff from webpages, without opening devtools. Just hover over unwanted element, keep clicking `w` (wider) until you have its whole container, then `r` to remove.
Yeah this extension rocks - i actually copied it and put it in a chrome extension - very weakly, i'm sure, as I know almost zero about chrome extensions - but fwiw
https://github.com/bradparks/aardvark_chrome_extension
https://github.com/bradparks/aardvark_chrome_extension
Oh wow, that is a really useful extension, thank you!
It's using media queries now, so you can use the browser's default printing function instead of having to find a bespoke button for that functionality.
I feel you are bit confused what print stylesheets are? They are exactly the opposite of having special version of the page for printing, and instead just restyling the same page for different media. That is why the printable=yes page is "no longer supported" in wikipedia, because it doesn't need a special printable page anymore, it can use just print stylesheet on the normal page instead.
This is what the print style looks on screen on Firefox on my computer: https://ibb.co/QN6Gsjk
Pretty decent if you ask me. Sure, technically its not separate stylesheet in Wikipedias case, but media queries, but the effect is the same.
This is what the print style looks on screen on Firefox on my computer: https://ibb.co/QN6Gsjk
Pretty decent if you ask me. Sure, technically its not separate stylesheet in Wikipedias case, but media queries, but the effect is the same.
I think you missed this sentence while reading my message:
> Then for a while it just gave me a terrible webpage version - basically showing the left menu bar and the huge logo when trying to print the page.
That is to say: trying to print the page in any way (clicking the "print page" link, using the browser menu) resulted in a webpage-styled output.
> Then for a while it just gave me a terrible webpage version - basically showing the left menu bar and the huge logo when trying to print the page.
That is to say: trying to print the page in any way (clicking the "print page" link, using the browser menu) resulted in a webpage-styled output.
If you wanna get real fancy, you could replace
document.documentElement.classList.remove('no-js');
document.documentElement.classList.add('js');
document.documentElement.classList.replace('no-js', 'js');
I used to use no-js/js classes too, but stopped because scripts being enabled isn't a guarantee that a given external script will run successfully (adblockers, connection error, etc).
Nowaways I default to "js isn't available" state, and if the script(s) is able to load, then it augments or hydrates the static markup.
Nowaways I default to "js isn't available" state, and if the script(s) is able to load, then it augments or hydrates the static markup.
But in the first example, `js` is always added, even if `no-js` doesn't exist.
In the context of the presented html, the first line is <html lang="en" class="no-js"> . So, "no-js" does exist.
Indeed, but this is a case where you are reducing lines of source code in exchange for (slightly) increased coupling and fragility. By replacing remove/add with replace, you have now made an assumption that causes the replace line to be coupled to the html lang line where no coupling existed previously...
It's a well known convention (CTM), it's been part of a lot of front end application shells for years. Like other shells, an HTML boilerplate is somewhat expected to be a delicate, hand-optimised system. When it needs revising (which should be very rare) it should always be reasoned about as a whole. Its job is to bootstrap the front-end environment with maximum efficiency, and that means doing things that would be considered bad programming in another context.
Wow thank you, tangentially I was trying to figure out how to change a hidden object to visible with tailwind and this seems like it would be perfect for that!
butt__hugger(3)
If you want to get less fancy, and even briefer, and incidentally fix the (non-)issue described by ryannevius and umvi in the adjacent subthread, you could use
document.documentElement.className = 'js';This would overwrite any other classes as well, which might be fine if you don’t have any but could lead to bugs later on if you forget about this behavior.
I don’t really think the point brought up by the other commenters is an issue. If the `no-js` class is missing, that’s a bug. Allowing it to be missing or present makes the behavior hard to reason about: If there is neither a `js` or `no-js` class, what is the desired behavior?
If the elimination of coupling is desired, maybe we should get rid of the `no-js` class altogether and interpret the absence of a `js` class to indicate no js. I think I like this solution best.
I don’t really think the point brought up by the other commenters is an issue. If the `no-js` class is missing, that’s a bug. Allowing it to be missing or present makes the behavior hard to reason about: If there is neither a `js` or `no-js` class, what is the desired behavior?
If the elimination of coupling is desired, maybe we should get rid of the `no-js` class altogether and interpret the absence of a `js` class to indicate no js. I think I like this solution best.
All these open graph data tags (!) and half of them redundant.
I’m gonna be the one to complain about it here. Why are we adhering to a proprietary format by facebook when equivalent meta tags exists. e.g. why is og:description a thing when we have <meta name="description"> and why specify og:title when <title> is literally the only contented tag required by the HTML standard (so all websites are required to have one).
This reminds me of a post from yesterday: “We were promised Strong AI, but instead we got metadata analysis”[1]. And a poor one at that indeed.
https://news.ycombinator.com/item?id=26941332
I’m gonna be the one to complain about it here. Why are we adhering to a proprietary format by facebook when equivalent meta tags exists. e.g. why is og:description a thing when we have <meta name="description"> and why specify og:title when <title> is literally the only contented tag required by the HTML standard (so all websites are required to have one).
This reminds me of a post from yesterday: “We were promised Strong AI, but instead we got metadata analysis”[1]. And a poor one at that indeed.
https://news.ycombinator.com/item?id=26941332
Because when someone (or our social media team/agency) shares one of our pages on FB we want it to look nice.
Then a follow up question: Why are the scrapers on FB, Twitter, etc. so dumb? Why can’t they fall back to <title> if <meta name="og:title"> is missing? Why is it my job to make things look nice on their platforms, when all the metadata they require is already there?
Optimal Titles are different lengths for different use cases for FB and Twitter ideally you want a call to action shorter title as compared to a longer optimised page <title>
It still begs the question: What about the—in my experience—more common use case where they are the same (i.e. current title and description is sufficient for social shares)?
Here is an example of a discord server refusing the expand the site description and title on one of my sites[1], just because there is no og:title and og:description (even though I provide both <title> and <meta name="description">).
All I can take from this is either: a) Social media companies are bad at (or don’t care about) implementing common sense features, or b) Facebook is actively and aggressively pushing their own proprietary format over established standards. In either case it is bad.
1: https://forums.online-go.com/t/random-starting-position-flex...
Here is an example of a discord server refusing the expand the site description and title on one of my sites[1], just because there is no og:title and og:description (even though I provide both <title> and <meta name="description">).
All I can take from this is either: a) Social media companies are bad at (or don’t care about) implementing common sense features, or b) Facebook is actively and aggressively pushing their own proprietary format over established standards. In either case it is bad.
1: https://forums.online-go.com/t/random-starting-position-flex...
"og:title" falls back to <title>. My <title> tags include the title of the website _and_ the title of the page. I put _just_ the page title in "og:title".
"og:image" has no standard alternative.
The rest are usually not needed. og:description falls back to meta description just fine.
"og:image" has no standard alternative.
The rest are usually not needed. og:description falls back to meta description just fine.
I wish there was a metadata tag that could prevent sharing on social media platforms.
You used to be able to prevent sharing by blocking their "thumbnail generator" requests via firewall. Or block entire range such as "2a03:2880::/32".
I haven't looked into this method's feasibility in years though. I imagine there are much better ways they protect outbound clicks from their apps these days.
I haven't looked into this method's feasibility in years though. I imagine there are much better ways they protect outbound clicks from their apps these days.
<meta name="robots" content="noindex">
What if you set og:image to a female-presenting nipple?
All your content are belong to us.
" why is og:description a thing when we have <meta name="description"> and why specify og:title when <title>"
.....
Because facebook/twitter/linkedin have different ways to display information and sometimes what's inside the description (for SEO purposes) is NOT the same as what you want displayed on a social media platform or other outlet for your content!
<title>, <meta name="description" ...> nearly always get used to optimise for Google and not the end user of a social media platform.
.....
Because facebook/twitter/linkedin have different ways to display information and sometimes what's inside the description (for SEO purposes) is NOT the same as what you want displayed on a social media platform or other outlet for your content!
<title>, <meta name="description" ...> nearly always get used to optimise for Google and not the end user of a social media platform.
I expect this to become a thread of people sharing their preferences. I prefer something minimal, that I can almost remember and write by hand:
I use this bottom padding, because I like to scroll all the way up and it also is useful if you have low anchors for one to see on top what was supposed to be there.
<!DOCTYPE html>
<meta charset=utf-8>
<meta name=viewport content="width=device-width,initial-scale=1">
<style>
body{
font:menu;font-size:1.125em;
margin:auto;max-width:40em;
padding:0 0.5em 90vh 0.5em;
}
</style>
I use this bottom padding, because I like to scroll all the way up and it also is useful if you have low anchors for one to see on top what was supposed to be there.
While not closing tag or using head / body element is a matter of taste, not using the HTML element with a proper lang attribute and missing the title element can lead to accessibility issues.
I guess you're right. The lang attribute is useful. I'll add it to my personal template.
I omitted the title, but it's a part of the content for me. This way I can use the simplest SSG there is: cat.
I omitted the title, but it's a part of the content for me. This way I can use the simplest SSG there is: cat.
> font:menu;font-size:1.125em;
As a default for otherwise-unstyled content, it's not very user-friendly to override the user's default font and size preferences.
The browser lets me decide how I'd like unstyled text to appear. Unless you're explicitly doing typographic design, please don't arbitrarily override my choice.
As a default for otherwise-unstyled content, it's not very user-friendly to override the user's default font and size preferences.
The browser lets me decide how I'd like unstyled text to appear. Unless you're explicitly doing typographic design, please don't arbitrarily override my choice.
I hear you. But this battle is lost for a long time, isn't it? You already know, that if you allow CSS things will happen.
I would personally not do this if browsers would have sensible defaults, but IMO they don't. Mostly it is a matter of backward compatibility.
Also I'm using font:menu so theoretically the same as your browser is using. Depending on your browser/OS you can change the font for all, not ideal, but doable. Similar to how every browser has different settings for your preferred fonts. But in Firefox for example you can deselect "Allow pages to choose their own fonts, instead of your selections above" and you're done.
I'm saying all this as a person wanting to implement a modern html-only browser to make all those obnoxious stylesheets go away.
I would personally not do this if browsers would have sensible defaults, but IMO they don't. Mostly it is a matter of backward compatibility.
Also I'm using font:menu so theoretically the same as your browser is using. Depending on your browser/OS you can change the font for all, not ideal, but doable. Similar to how every browser has different settings for your preferred fonts. But in Firefox for example you can deselect "Allow pages to choose their own fonts, instead of your selections above" and you're done.
I'm saying all this as a person wanting to implement a modern html-only browser to make all those obnoxious stylesheets go away.
You should use system-ui, sans-serif to avoid abusing the semantics of menu.
I don't see why you'd think font:menu is appropriate for the general body of web content. Menus are a UI element that normally contain just a few isolated words or very short phrases. Recognizing words in such a context is not the same as reading textual content on a page. A font chosen for one may not be well suited to the other.
If your issue is that many browsers default to a serif font, and you really dislike that, maybe setting font-family:sans-serif would be better? At least that's intended to be suitable for content, rather than UI.
If your issue is that many browsers default to a serif font, and you really dislike that, maybe setting font-family:sans-serif would be better? At least that's intended to be suitable for content, rather than UI.
<meta name=viewport content="width=device-width,initial-scale=1">
Excuse my ignorance: what the heck does this achieve?!
Excuse my ignorance: what the heck does this achieve?!
It's an incantation to make the page look slightly less stupid on a phone.
https://www.w3schools.com/css/css_rwd_viewport.asp for an example image
https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_m... for more detailed info
https://www.w3schools.com/css/css_rwd_viewport.asp for an example image
https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_m... for more detailed info
So the html looks as god intended on mobile devices. It became necessary, because web pages squeezed to mobile sizes were looking terrible with all those sidebars bent and excessive padding and margins. So Apple (I believe it was them) made this workaround, by default your phone renders pages scaled, like it's a window to your desktop computer's maximized browser. Then it looked good. But what about pages that are responsive or just look good no matter the window size? That's the line that needs to be there.
It sets mobile browsers use actual widths and not emulate desktop width.
it is not exactly the actual width of the device, but the default viewport width, given in CSS pixels. E.g. for the iphone 6 it is 375 pixel, although the physical width is 750 pixel...
Yeah, but the same is true for desktops/laptops that use scaling. I think that people are used to the fact that 1 render pixel does not always equal 1 physical pixel.
I prefer a parser-friendly template that makes Web Scraping easy. My template [1] is both parsable by HTML5 and XML processors.
[1] https://github.com/Conaclos/origin.html/blob/master/template...
[1] https://github.com/Conaclos/origin.html/blob/master/template...
No box-sizing: border-box?
I'm not doing anything complex enough for it to matter.
Like using margins or padding?
> <meta name=viewport content="width=device-width,initial-scale=1">
This is a cat and mouse game. iOS 14 doesn't respect user-scalable=no or maximum-scale, unfortunately.
What you need to do is this now, if you don't want the web browser to respond to scaling (and as much as the idiots at Apple love their high horses, there are actual use cases for this, including when you are building a webapp or when you are building a web page with your own pinch zoom logic):
This is a cat and mouse game. iOS 14 doesn't respect user-scalable=no or maximum-scale, unfortunately.
What you need to do is this now, if you don't want the web browser to respond to scaling (and as much as the idiots at Apple love their high horses, there are actual use cases for this, including when you are building a webapp or when you are building a web page with your own pinch zoom logic):
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<style>body { touch-action: pan-x pan-y; }</body>
Are you surprised? If every damn website out there starts copying and pasting the same thing regardless of whether it makes sense, and it makes the iOS user experience worse as a result, of course they're going to change things. Their priority should be their users. It sucks for those that actually have a valid reason for it but there's no way to separate those automatically.
The problem is the OS zooming fights against pinch zooming that you may implement inside your webapp's logic, especially for non-static content (maps for example), multi-finger games where two touches don't signify a zoom, etc. They just broke the UX of a whole bunch of websites.
When will we ever have HTML5 apps that match native apps? When they actually let HTML5 apps do what native apps do, like multitouch without triggering a default action.
When will we ever have HTML5 apps that match native apps? When they actually let HTML5 apps do what native apps do, like multitouch without triggering a default action.
No, that's not the problem. Remember, developers are a minority, users are the majority, so making things work well for users takes priority over making things work well for developers. When functionality that's useful for webapps is misused for websites where it has no place and where it breaks the user experience, the only way to improve things for users is to make things harder for developers.
developers make the things the majority use, if you make things worse for developers they have a harder time making things that work well for the user, when that happens they will look to misuse functionality to improve things for their users. The only way to improve things for users is to make things easier for developers.
There are good developers who try to improve things for their users. There are also many developers who don't and ruin it for the rest.
Do they earn 30% from HTML5 apps?
The OS or browser should not just take over one of the primary means of interacting with an app and effectively disable it for any other use. You might as well just pull those gestures out of the specs at that point. The point of an os or browser is to get out of the way, not be omnipresent. It's extremely patronizing and cripples important functionality for likely millions of sites.
The browser is the app.
The web app is the app. A browser is a mini OS at this point.
That's what web devs like to pretend. Then they are surprised when browser developers continue developing their browsers.
If you want to develop an app, develop an app, not a website. Use Electron or its mobile equivalents if you must.
If you want to develop an app, develop an app, not a website. Use Electron or its mobile equivalents if you must.
So you are saying that pinch and double tap should just be removed from js specs because one company arbitrarily decided you can't use them anymore. Whatever.
Also, MS office and Adobe are web apps and far more complex than almost any "real apps" out there. It's completely untrue that web apps are not apps.
Also, MS office and Adobe are web apps and far more complex than almost any "real apps" out there. It's completely untrue that web apps are not apps.
No, I think JS as a whole should be removed completely independently of what any company decided. Websites in general aren't trustworthy, which means they can't be trusted to determine the browser's behaviour.
> Also, MS office and Adobe are web apps and far more complex than almost any "real apps" out there. It's completely untrue that web apps are not apps.
You can pretend they are until someone takes away your toys. Then, suddenly, your "app" cannot even process its own input. Or access the clipboard. Or do any of the other things that websites just aren't trustworthy enough for.
> Also, MS office and Adobe are web apps and far more complex than almost any "real apps" out there. It's completely untrue that web apps are not apps.
You can pretend they are until someone takes away your toys. Then, suddenly, your "app" cannot even process its own input. Or access the clipboard. Or do any of the other things that websites just aren't trustworthy enough for.
There is nothing that makes an installed app, with higher permissions, more trustworthy than a web app. Getting rid of js altogether is just throwing away the web to make it something poorly performing and requires sending all data back to the server - so not really a serious option. Browsers only exist to allow interaction with websites, and as such they should follow specs and allow them to be used. Websites are more important than browsers by definition.
> There is nothing that makes an installed app, with higher permissions, more trustworthy than a web app.
Yes, there is. The fact the user has installed it.
> Getting rid of js altogether is just throwing away the web to make it something poorly performing and requires sending all data back to the server - so not really a serious option.
Not the web, just webapps. The web will perform better afterwards.
> Browsers only exist to allow interaction with websites, and as such they should follow specs and allow them to be used.
Yes, but those specs have to be sane. Which means even a completely untrusted party – that's what a random website is – cannot abuse them.
> Websites are more important than browsers by definition.
Nonsense, either is useless without the other. Websites are content, browsers define how they're viewed.
Yes, there is. The fact the user has installed it.
> Getting rid of js altogether is just throwing away the web to make it something poorly performing and requires sending all data back to the server - so not really a serious option.
Not the web, just webapps. The web will perform better afterwards.
> Browsers only exist to allow interaction with websites, and as such they should follow specs and allow them to be used.
Yes, but those specs have to be sane. Which means even a completely untrusted party – that's what a random website is – cannot abuse them.
> Websites are more important than browsers by definition.
Nonsense, either is useless without the other. Websites are content, browsers define how they're viewed.
At what point do they think my English "makes the iOS user experience worse" and change the text between two <div>s?
> iOS 14 doesn't respect user-scalable=no
Best change made in Safari in a long time. My eyesight is going and unzoomable websites were a serious accessibility issue.
Best change made in Safari in a long time. My eyesight is going and unzoomable websites were a serious accessibility issue.
At the same time, they created accessibility issues on lots of other websites. Games that need multitouch, photo galleries that implement their own pinch zoom and progressive higher res image loading logic, and lots of other things.
Then websites just cannot use that feature. Zoom is necessary for accessibility, period. Being able to implement games as websites isn't. If you want to control the UI, write an app.
But not everyone wants to give money to apple to be able to deploy their apps, so the "sensible" way is to use hacks[1] to have a normal html5 behavior.
[1]: https://stackoverflow.com/q/37808180/6885801
[1]: https://stackoverflow.com/q/37808180/6885801
I'm sympathetic to the argument that you shouldn't have to pay to play on iOS devices but that doesn't mean that the browser has to cater to every possible use-case especially when that use-case hurts accessibility for almost all real web pages if used.
If you give web developers any way to disable zoom they will disable zoom whether it's appropriate or not. With an app that gets human reviewed you can make rules like "this feature can only be used for full-screen games" but not on the web where there's one set of rules for everyone.
If you give web developers any way to disable zoom they will disable zoom whether it's appropriate or not. With an app that gets human reviewed you can make rules like "this feature can only be used for full-screen games" but not on the web where there's one set of rules for everyone.
No, it's shitty developers that hurt accessibility. There are so many other worse ways to wreck accessibility than disabling zoom, including popup modals, grossly large banner ads, JS that consumes CPU and huge amounts of bandwidth, supporting only English, putting text in images without alt text, hard-to-read font choices, and so on. People do all of the above. There are good devs and crappy devs. If a website is made by crappy devs it will naturally lose reader interest.
There are actual accessibility reasons for wanting to take control of pinch zoom behavior. As long as I'm actually catering to accessibility, if I have to be forced to use the OS pinch zoom to do that it's going to be LESS accessible. The OS pinch zoom only works for text and static 2D images and nothing else. If you try to OS-pinch-zoom a 3D object on a web page, it zooms the whole UI and not the object. That's a major accessibility problem for say a website that offers 3D models.
And no, I don't think "create an app" is the answer as another comment said. I want LESS apps, LESS spyware, and more in-browser, fully-featured, perfect mobile experiences designed in HTML5 because it's MUCH harder to invade privacy with HTML5 than it is with a native app, and if Apple would stop compromising HTML5 features, a huge number of mobile apps can be implemented in it.
There are actual accessibility reasons for wanting to take control of pinch zoom behavior. As long as I'm actually catering to accessibility, if I have to be forced to use the OS pinch zoom to do that it's going to be LESS accessible. The OS pinch zoom only works for text and static 2D images and nothing else. If you try to OS-pinch-zoom a 3D object on a web page, it zooms the whole UI and not the object. That's a major accessibility problem for say a website that offers 3D models.
And no, I don't think "create an app" is the answer as another comment said. I want LESS apps, LESS spyware, and more in-browser, fully-featured, perfect mobile experiences designed in HTML5 because it's MUCH harder to invade privacy with HTML5 than it is with a native app, and if Apple would stop compromising HTML5 features, a huge number of mobile apps can be implemented in it.
> If you try to OS-pinch-zoom a 3D object on a web page, it zooms the whole UI and not the object. That's a major accessibility problem for say a website that offers 3D models.
Why doesn't it zoom the object along with the rest of the page?
Why doesn't it zoom the object along with the rest of the page?
I'm not even arguing if zoom is or not necessary but this kind of thought doesn't make sense for me anywhere else than when a feature can compromise a user device.
If a website borks its usability/accessibility you as a user can decide not to use it. If it's a public service or a company there will be for sure pressure for it to conform to whatever accessibility standard is deemed appropriate. Developers in those situations will have to do the work they are hired to do.
Now saying that I should not as an independent developer customise certain behaviour or appearance in a browser (say scrollbars, or many others) to appease that arbitrary accessibility doesn't make sense. If I can't build a certain app (due to arbitrary constraints that have no security implications) then its accessibility is effectively reduced to 0 isn't it?
If I, as an idiot, want to build a website that screen readers won't be able to parse or will spew lines of William Shake-s-pear as image alt tags, isn't that my choice and am I not able already to do so?
As such, if I for instance wanted to write a game in a browser where some of these things are detrimental, and just can't because, no, accessibility, what does that net any one?
This patronising "we know better everything" is sincerely annoying.
If a website borks its usability/accessibility you as a user can decide not to use it. If it's a public service or a company there will be for sure pressure for it to conform to whatever accessibility standard is deemed appropriate. Developers in those situations will have to do the work they are hired to do.
Now saying that I should not as an independent developer customise certain behaviour or appearance in a browser (say scrollbars, or many others) to appease that arbitrary accessibility doesn't make sense. If I can't build a certain app (due to arbitrary constraints that have no security implications) then its accessibility is effectively reduced to 0 isn't it?
If I, as an idiot, want to build a website that screen readers won't be able to parse or will spew lines of William Shake-s-pear as image alt tags, isn't that my choice and am I not able already to do so?
As such, if I for instance wanted to write a game in a browser where some of these things are detrimental, and just can't because, no, accessibility, what does that net any one?
This patronising "we know better everything" is sincerely annoying.
You can implement whatever you want, just not in a website. Write an app instead. Sure, it may not be available on Apple device because of their restrictions on that matter, but that's a separate issue.
It would be nice if web developers could be trusted to only disable zoom when it either does not impact accessibility or when making a website accessible is absolutely not possible. In practice, making an inaccessible website is often more profitable because it's less effort. Also, I've seen a lot of ordinary websites disable zoom for no real reason.
Important websites have to be accessible. So if your website would not be accessible anyway, it not existing may not be a gain for anyone but it isn't a big deal either.
And in many cases, it is better for a website to not exist that for it to be inaccessible: Market forces, your employer, school, university or state can require you to access a website that is not accessible to you. They cannot do that if it does not exist.
It would be nice if web developers could be trusted to only disable zoom when it either does not impact accessibility or when making a website accessible is absolutely not possible. In practice, making an inaccessible website is often more profitable because it's less effort. Also, I've seen a lot of ordinary websites disable zoom for no real reason.
Important websites have to be accessible. So if your website would not be accessible anyway, it not existing may not be a gain for anyone but it isn't a big deal either.
And in many cases, it is better for a website to not exist that for it to be inaccessible: Market forces, your employer, school, university or state can require you to access a website that is not accessible to you. They cannot do that if it does not exist.
> You can implement whatever you want, just not in a website. Write an app instead.
I don't want to write an app for it. By your logic websites should be plain text and we should all be learning N frameworks to do things that are way easier to do in a browser, available without having to install black box crap software on our devices.
It makes no sense, since you can do plenty of worse things than disabling zoom, in fact the browser allows a whole range of things that are not in the interest of users and they don't do anything to curb those, so your point is basically moot.
> In practice, making an inaccessible website is often more profitable because it's less effort.
This has no bearing in real accessibility, it's, as plenty of other things, a red herring, since real accessibility is not defined by zooming or changing your scrollbar appearance - as you can confirm by visiting a very large part of the internet.
> And in many cases, it is better for a website to not exist that for it to be inaccessible:
This is like, your opinion. Which besides being as the saying goes, isn't even backed by any rational argument. Just because you keep saying the same words they don't change reality, unless you're Dumbledore, and you're a character in a book, or a movie, and even then, it only changes the story there, not the story outside of it.
All the cases you mention can, and should be dealt with in legal terms - your school, employer, university, or state, are public entities, there can certainly be accessibility guides, references and standards, as there are in a multitude of others things, exactly to regulate that.
Your argument is like saying, that paper should not be used to draw, or do origami, or write in other languages because someone might not understand what it is, or what is contained in it. Of course, that's silly. And when it comes to government, schools, and public entities, according to the type of documents, printed and available in paper, they do have to follow a specific ruleset, without impacting what paper can be used for in other situations.
I don't want to write an app for it. By your logic websites should be plain text and we should all be learning N frameworks to do things that are way easier to do in a browser, available without having to install black box crap software on our devices.
It makes no sense, since you can do plenty of worse things than disabling zoom, in fact the browser allows a whole range of things that are not in the interest of users and they don't do anything to curb those, so your point is basically moot.
> In practice, making an inaccessible website is often more profitable because it's less effort.
This has no bearing in real accessibility, it's, as plenty of other things, a red herring, since real accessibility is not defined by zooming or changing your scrollbar appearance - as you can confirm by visiting a very large part of the internet.
> And in many cases, it is better for a website to not exist that for it to be inaccessible:
This is like, your opinion. Which besides being as the saying goes, isn't even backed by any rational argument. Just because you keep saying the same words they don't change reality, unless you're Dumbledore, and you're a character in a book, or a movie, and even then, it only changes the story there, not the story outside of it.
All the cases you mention can, and should be dealt with in legal terms - your school, employer, university, or state, are public entities, there can certainly be accessibility guides, references and standards, as there are in a multitude of others things, exactly to regulate that.
Your argument is like saying, that paper should not be used to draw, or do origami, or write in other languages because someone might not understand what it is, or what is contained in it. Of course, that's silly. And when it comes to government, schools, and public entities, according to the type of documents, printed and available in paper, they do have to follow a specific ruleset, without impacting what paper can be used for in other situations.
> I don't want to write an app for it. By your logic websites should be plain text and we should all be learning N frameworks to do things that are way easier to do in a browser, available without having to install black box crap software on our devices.
- Web apps don't require less trust than proper ones. Their developers can use dark patterns, abuse your data, etc.
- Cross-platform frameworks exist
- I have no idea why you think I mind hypertext
> This has no bearing in real accessibility, it's, as plenty of other things, a red herring, since real accessibility is not defined by zooming or changing your scrollbar appearance - as you can confirm by visiting a very large part of the internet.
Are you seriously claiming zooming is not an accessibility feature?
> This is like, your opinion. Which besides being as the saying goes, isn't even backed by any rational argument.
Please stop the flaming.
> All the cases you mention can, and should be dealt with in legal terms - your school, employer, university, or state, are public entities, there can certainly be accessibility guides, references and standards, as there are in a multitude of others things, exactly to regulate that.
Sure. And once there are strict accessibility laws, worldwide, that everyone follows, and all the legacy software has been replaced, we can give developers control over zooming again.
- Web apps don't require less trust than proper ones. Their developers can use dark patterns, abuse your data, etc.
- Cross-platform frameworks exist
- I have no idea why you think I mind hypertext
> This has no bearing in real accessibility, it's, as plenty of other things, a red herring, since real accessibility is not defined by zooming or changing your scrollbar appearance - as you can confirm by visiting a very large part of the internet.
Are you seriously claiming zooming is not an accessibility feature?
> This is like, your opinion. Which besides being as the saying goes, isn't even backed by any rational argument.
Please stop the flaming.
> All the cases you mention can, and should be dealt with in legal terms - your school, employer, university, or state, are public entities, there can certainly be accessibility guides, references and standards, as there are in a multitude of others things, exactly to regulate that.
Sure. And once there are strict accessibility laws, worldwide, that everyone follows, and all the legacy software has been replaced, we can give developers control over zooming again.
> Web apps don't require less trust than proper ones. Their developers can use dark patterns, abuse your data, etc.
They do, mostly because the browser allows it.
> I have no idea why you think I mind hypertext
Perhaps a better model would be that the web shouldn't be hypertext by default (or can be something else), and instead that hypertext is one of the possible formats for something on the web, along with others - the web would be the "envelope" and not the definition of the content.
If you follow your line of thought to the end, then the conclusion would be that we should be left to pure hypertext.
> Are you seriously claiming zooming is not an accessibility feature?
No, I'm claiming that there's no reason to not allow someone to control the behaviour of certain parts of the browser when browsing a web property of someone else, as long as it doesn't pose a security risk. While at it, the browser could implement white listing of actions, data, and other details that the web property has access to without my consent. If I visit a website for a game and it tells me "this website is going to: - disable zoom - change your scrollbars - change the right click button; check which ones you agree/do you agree" there's no loss of accessibility. And the same for scripts, watching mouse input, text typing, hijacking the back button, showing me popups, etc. Of course that would be technically very challenging to implement.
> Please stop the flaming.
The first rule is if you don't like something done to you, you shouldn't do it to others. Once you do you have to man up.
> Sure. And once there are strict accessibility laws, worldwide, that everyone follows, and all the legacy software has been replaced, we can give developers control over zooming again.
Why do they need to be strict and before-hand?
They do, mostly because the browser allows it.
> I have no idea why you think I mind hypertext
Perhaps a better model would be that the web shouldn't be hypertext by default (or can be something else), and instead that hypertext is one of the possible formats for something on the web, along with others - the web would be the "envelope" and not the definition of the content.
If you follow your line of thought to the end, then the conclusion would be that we should be left to pure hypertext.
> Are you seriously claiming zooming is not an accessibility feature?
No, I'm claiming that there's no reason to not allow someone to control the behaviour of certain parts of the browser when browsing a web property of someone else, as long as it doesn't pose a security risk. While at it, the browser could implement white listing of actions, data, and other details that the web property has access to without my consent. If I visit a website for a game and it tells me "this website is going to: - disable zoom - change your scrollbars - change the right click button; check which ones you agree/do you agree" there's no loss of accessibility. And the same for scripts, watching mouse input, text typing, hijacking the back button, showing me popups, etc. Of course that would be technically very challenging to implement.
> Please stop the flaming.
The first rule is if you don't like something done to you, you shouldn't do it to others. Once you do you have to man up.
> Sure. And once there are strict accessibility laws, worldwide, that everyone follows, and all the legacy software has been replaced, we can give developers control over zooming again.
Why do they need to be strict and before-hand?
This! The whole movement of making webpages do all the things apps can do…
That's what I tell iOS users that complain that page zooms in if they tap too fast on a button adding items to cart. It's for their own good, and they can thank their overlord - Apple.
Not zooming in when doing stuff unrelated to intent to zoom, is just not in their interest as determined by Apple.
Not zooming in when doing stuff unrelated to intent to zoom, is just not in their interest as determined by Apple.
Yes, if their browser's UI has problems distinguishing between zooming and clicking buttons, that's definitely the responsibility of the browser's vendor. Who can only improve that if the browser is actually in charge of the UI – e.g. zooming is implemented by the browser, not by every random website.
Perhaps one of those features which should have been made a toggle, but yes: pinch-zoom is an essential feature which all sorts of sites were disabling for no good reason, and so this toy gets taken away from everyone. This kind of tragedy of the commons stuff is why we can't have nice things on the web.
Thanks for this, is it backwards compatible with previous versions of iOS? Or is there some combination of incantations that does graceful degradation?
Erm WTF your going to have problems using things like GTM and GA for a start.
Just blatantly breaking standards like this is not a good idea seen some real howlers from sprint back when I worked on x.400.
Just blatantly breaking standards like this is not a good idea seen some real howlers from sprint back when I worked on x.400.
Not using either of those things sounds like a benefit.
Yeh want to justify your ROI you will :-)
And using GTM instead of hand coding every thing is a win
And using GTM instead of hand coding every thing is a win
W3C HTML5 validator will issue a single warning for not having an openning html tag with the lang attribute. Other than that there are no errors. It is not breaking any standards. As sibling commented I would just add the html tag with the lang attribute.
I don't use GTM or GA or almost any JavaScript whatsoever.
I don't use GTM or GA or almost any JavaScript whatsoever.
No standards are broken here. Maybe you can bother to read them:
https://html.spec.whatwg.org/#optional-tags
There will also be no issue including GTM/GA or other scripts.
https://html.spec.whatwg.org/#optional-tags
There will also be no issue including GTM/GA or other scripts.
It's missing an obnoxious cookie dialog, mailing list modal window and multiple ads.
Someone correct me if i'm wrong but I've been doing a bit of research and I'm pretty sure you can remove these:
The same is true for apple touch icon, you can just remove it:
<link rel="icon" href="/favicon.ico">
The same is true for apple touch icon, you can just remove it:
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<meta charset="UTF-8">
> I'm pretty sure you can remove these: <link rel="icon" href="/favicon.ico">
The presence of the SVG favicon, with the same rel, may throw the default-finding off. I haven’t tested it, but I would expect various older user agents that don’t support SVG to fall over if you omit the favicon.ico link once you’ve provided the SVG link.
> By default servers add the charset as an http header.
This is not true: it depends entirely on the server configuration. Maybe one serves `content-type: text/html`, maybe another serves `content-type: text/html; charset=utf-8`. The reason people recommend <meta charset="utf-8"> is so that you don’t depend on server configuration that the authors of the HTML commonly can’t control, and which may not always be possible: specifically, what happens if someone saves your HTML page locally?
> And since utf-8 is the only valid charset for HTML5 it shouldn't be the default.
UTF-8 is the only valid charset for HTML now, but that doesn’t mean it’s the only supported charset. See https://html.spec.whatwg.org/#determining-the-character-enco.... The default varies by locale and even user configuration (see the table in step 9). If the default was changed to UTF-8, many non-English old documents would break. Maybe eventually the default will be changed anyway, at least where the short <!doctype html> doctype is used.
The presence of the SVG favicon, with the same rel, may throw the default-finding off. I haven’t tested it, but I would expect various older user agents that don’t support SVG to fall over if you omit the favicon.ico link once you’ve provided the SVG link.
> By default servers add the charset as an http header.
This is not true: it depends entirely on the server configuration. Maybe one serves `content-type: text/html`, maybe another serves `content-type: text/html; charset=utf-8`. The reason people recommend <meta charset="utf-8"> is so that you don’t depend on server configuration that the authors of the HTML commonly can’t control, and which may not always be possible: specifically, what happens if someone saves your HTML page locally?
> And since utf-8 is the only valid charset for HTML5 it shouldn't be the default.
UTF-8 is the only valid charset for HTML now, but that doesn’t mean it’s the only supported charset. See https://html.spec.whatwg.org/#determining-the-character-enco.... The default varies by locale and even user configuration (see the table in step 9). If the default was changed to UTF-8, many non-English old documents would break. Maybe eventually the default will be changed anyway, at least where the short <!doctype html> doctype is used.
That's a good point about the favicon mix. I really want to get a difinitve answer to all this. I'll do some tests when I have time.
I guess that should read most servers? I'm not much of a backend dev, but every default I've seen has included the charset in the headers.
I realize I'm blowing against the wind on this one!
On a site by site basis it seems that you really can get rid of it. I've only tested my own sites offline in various browsers and they work fine without the meta tag.
One example of a site that doesn't use it is YouTube, and I figured that can't be an accident.
I guess that should read most servers? I'm not much of a backend dev, but every default I've seen has included the charset in the headers.
I realize I'm blowing against the wind on this one!
On a site by site basis it seems that you really can get rid of it. I've only tested my own sites offline in various browsers and they work fine without the meta tag.
One example of a site that doesn't use it is YouTube, and I figured that can't be an accident.
> in the case of offline where there are no http headers, the browser works out what encoding to use
For file: URLs, Firefox and, a bit less reliably, Chrome do work out that an HTML file is UTF-8. Safari does not.
> And since utf-8 is the only valid charset for HTML5
Correct.
> it should be the default.
It isn't. See https://hsivonen.fi/utf-8-detection/ for why.
Having <meta charset="UTF-8"> in the boilerplate is good advice.
For file: URLs, Firefox and, a bit less reliably, Chrome do work out that an HTML file is UTF-8. Safari does not.
> And since utf-8 is the only valid charset for HTML5
Correct.
> it should be the default.
It isn't. See https://hsivonen.fi/utf-8-detection/ for why.
Having <meta charset="UTF-8"> in the boilerplate is good advice.
> the browser works out what encoding to use.
Historically, letting the browser guess anything at all has been a disaster. Although IE is all but dead now, there's no guarantee that another browser won't try something similarly reckless in an attempt to be a little too convenient.
Historically, letting the browser guess anything at all has been a disaster. Although IE is all but dead now, there's no guarantee that another browser won't try something similarly reckless in an attempt to be a little too convenient.
So i guess the question is — should we keep markup for the case where someone downloads our webpage on a legacy browser?
For me the answer is yes, if people are using an old netbook on a dialup connection and they save your site locally to save data. That could be a good idea. I'll do some testing though because I think even old IE defaults to utf-8.
For me the answer is yes, if people are using an old netbook on a dialup connection and they save your site locally to save data. That could be a good idea. I'll do some testing though because I think even old IE defaults to utf-8.
IE defaults to the locale-dependent legacy Windows code page.
The edge cases are hard to test. IIRC the weirdest issues had something to do with valid UTF-8 content the first X bytes of which also happened to be valid in some exotic charset related to the user's locale. English users would rarely come across such issues.
> And since utf-8 is the only valid charset for HTML5 it should be the default.
In actual practice, firefox will try latin encoding if the first few kilobytes are ASCII7 and the document is not indicating its encoding.
In actual practice, firefox will try latin encoding if the first few kilobytes are ASCII7 and the document is not indicating its encoding.
Then that's a bug in Firefox that needs to be fixed, not worked around.
I have run into issues using KaTeX and some other rendering libraries without the <meta charset="UTF-8"/> tag. There are likely other problems that could occur without it.
I think it is important to review best practices like this yearly. However I am also disappointed how much accomodation is required to make various platforms happy. From social media cues with og: to meta tags for crawlers, to manifests for Android. It just seems ... infected with ephemera. I mean, social media is pushing 20 years so I'm probably sounding my age, but something about all those customizations hidden behind meta tag prop lists is icky. IMHO.
Something worth mentioning if you're using color schemes:
chromium has a "Force dark mode" option that inverts the colors of light pages to make them dark. This used to play well with color schemes: normal page → inverted, page with prefers-color-scheme: dark → use dark theme. Of course they managed to break it: for some reason (but it's not a bug!), new chromium versions always choose the light theme and invert it, even if the page declares it has a dark theme, which is not nice.
They only way to make chromium in dark mode use the CSS color schemes is to add the meta tag:
They only way to make chromium in dark mode use the CSS color schemes is to add the meta tag:
<meta name="color-scheme" content="dark light">
Nice. Check this out too https://htmlhead.dev
Slightly related note, if you are a web developer, I would highly recommend reading this long read on "How to Section Your HTML". This is especially important if you want your site to function correctly when screen readers are used for accessibility purposes. I would pretty much give 100% credit to this article which helped me go from a newbie on HTML design to knowing how to correctly structure it:
https://css-tricks.com/how-to-section-your-html/
https://css-tricks.com/how-to-section-your-html/
The only other tag I suggest adding to this, especially since its a boilerplate is the <meta http-equiv="X-UA-Compatible" content="IE=edge">.
[You can read more about why from smart people on StackOverflow](https://stackoverflow.com/a/8942455/10783165)
[You can read more about why from smart people on StackOverflow](https://stackoverflow.com/a/8942455/10783165)
As far as I know, edge is the default mode [1], no need to set it explicitly, especially not for sites that target modern browsers.
[1]: https://docs.microsoft.com/en-us/archive/blogs/ie/living-on-...
[1]: https://docs.microsoft.com/en-us/archive/blogs/ie/living-on-...
Why are the non-container elements like 'meta' and 'link' not terminated with '/>'? Did I miss a memo?
yes, you don’t use those in html5 (though they are required in things like jsx)
that hasn't been a thing since xhtml. html5 did away with /> for tags that don't have a closing tag. like img, meta, br, etc.
xhtml was never supported by all major browsers. You couldn't do stuff like <div/> and get away with it.
Not sure why the the self closing tags became widely used
Not sure why the the self closing tags became widely used
> Not sure why the the self closing tags became widely used
For a while adhering to the open/close conventions helped use tooling / libraries built around the assumptions for XML in dealing with HTML, maybe up through the late 00s/early 10s.
Any utility gains there faded as HTML5 conventions and libraries became more solid, but I still have a bit of the habit, especially with <img/> & <br/>.
For a while adhering to the open/close conventions helped use tooling / libraries built around the assumptions for XML in dealing with HTML, maybe up through the late 00s/early 10s.
Any utility gains there faded as HTML5 conventions and libraries became more solid, but I still have a bit of the habit, especially with <img/> & <br/>.
> xhtml was never supported by all major browsers.
Source? https://caniuse.com/xhtml says otherwise
> You couldn't do stuff like <div/> and get away with it.
I just tried on both Firefox and Chromium, they parse it properly.
Source? https://caniuse.com/xhtml says otherwise
> You couldn't do stuff like <div/> and get away with it.
I just tried on both Firefox and Chromium, they parse it properly.
When xhtml was popular internet explorer was a major blocker for using it properly. I never saw xhtml served with the proper content type at the time.
I don't see a reason to mix html and xhtml today. It will only lead to problems. (I.e using self-closing tags and & mismatches in urls)
If you use <div/> in html the browser will just ignore the end / See https://jsfiddle.net/sw8j9fo2/
I don't see a reason to mix html and xhtml today. It will only lead to problems. (I.e using self-closing tags and & mismatches in urls)
If you use <div/> in html the browser will just ignore the end / See https://jsfiddle.net/sw8j9fo2/
[deleted]
Some editors had trouble with color coding non-compliant xhtml. At least that was my reason for doing it. (In the very early 2000s)
'link' and 'meta' are void elements in HTML5 and are forbidden to have end tags.
https://www.w3.org/TR/2011/WD-html-markup-20110113/syntax.ht...
https://www.w3.org/TR/2011/WD-html-markup-20110113/syntax.ht...
Thanks, I did miss that ... probably because I don't do front-end development anymore.
The HTML serialisation doesn’t do self-closing tags. A trailing slash does precisely nothing: the parser just skips it. It’s dead weight. I strongly recommend against including trailing slashes, because (a) they serve no purpose to the machine; and (b) they mislead people into thinking they mean something, when they don’t—and indeed the vast majority of cases where I see trailing slashes used, they’re not used consistently, so some void tags have them and others don’t (if it was used consistently I wouldn’t mind so much).
(The XML serialisation is still a thing, in various contexts. Serve a document with an XHTML MIME type and the XML parser will be used; or embed HTML in SVG via foreignObject and it’ll be XML serialisation you need. Also note that SVG in HTML invokes… uhh… more XMLy behaviour from the HTML parser, so that the trailing slash does have its XML meaning.)
(The XML serialisation is still a thing, in various contexts. Serve a document with an XHTML MIME type and the XML parser will be used; or embed HTML in SVG via foreignObject and it’ll be XML serialisation you need. Also note that SVG in HTML invokes… uhh… more XMLy behaviour from the HTML parser, so that the trailing slash does have its XML meaning.)
To add to what you said: the HTML specification has a bunch of rules to say how to parse a tag that doesn't have a matching close tag. These grew organically based on how browsers responded to malformed documents. At some point the rules were enshrined in the HTML specification.
Some tags such as <meta> and <img> are always considered as a leaf node ("void element"). The HTML parser knows that these tags cannot contain other tags.
Other tags, such as <p> or <li> have various rules saying how to automatically insert a closing tag if it's missing. For example, if you leave out the </li> tags in a list the HTML parser will parse it as if you had closed all the list items.
Some tags such as <meta> and <img> are always considered as a leaf node ("void element"). The HTML parser knows that these tags cannot contain other tags.
Other tags, such as <p> or <li> have various rules saying how to automatically insert a closing tag if it's missing. For example, if you leave out the </li> tags in a list the HTML parser will parse it as if you had closed all the list items.
<ul>
<li>first
</li>second
</ul>
<ul>
<li>first</li>
</li>second</li>
</ul>
Slight correction: all tags will get a closing tag if it’s missing; it’s just less likely to be where you want on tags that “require” an end tag than those where it’s explicitly optional. Remember that HTML defines an exhaustive parser: all inputs produce a defined tree. “Invalid HTML” means a nonconforming document, but it doesn’t actually change anything; it’s just a way of making you feel guilty, or pointing out a place where it’s very likely you made a mistake or might make a mistake in further modifying the document.
If you have something like this:
Of your example, I think you typed it incorrectly in a couple of places. Here’s what I think you meant to express (plus a third one to make things clearer with the second having a bad trailing slash):
If you have something like this:
<div>
<h1>A
<p>B
<img>
<p>C
<h2>D
<p>E
</div>
<div>
<h1>A
<p>B
<img>
</p><p>C
</p></h1><h2>D
<p>E
</p></h2></div>
Of your example, I think you typed it incorrectly in a couple of places. Here’s what I think you meant to express (plus a third one to make things clearer with the second having a bad trailing slash):
<ul>
<li>first
<li/>second
<li>third
</ul>
<ul>
<li>first
</li><li>second
</li><li>third
</li></ul>This is useful I think purely for the meta tags and the opengraph properties and related magic values you need to make things like twitter show images and descriptions properly when a link is embedded.
They forgot the OpenGraph prefix though. Small nitpick.
I like how the author says "we don't need these and these things because latest versions of X don't require it anymore" — well what about people who don't use the latest versions of X?
Well, it's perfect readable in lynx & IE6.
I think for the most part, it's a pretty reasonable selection of tags. And there's almost no excuse to keep crazy old stuff around these days.
I think for the most part, it's a pretty reasonable selection of tags. And there's almost no excuse to keep crazy old stuff around these days.
I think the argument that most X'es are self-updating browsers. I'm not sure how valid that is, but it seems to me that you need to do active effort to be eg on Firefox 70 today.
The big non-self-updating X is IE11 which the author addresses separately.
The big non-self-updating X is IE11 which the author addresses separately.
time to upgrade?
As a user of wien.gv.at I want to thank you for your work. It's great to use a website that puts HTML first, rather than a mess of Javascript to render what essentially is just text.
I use:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title></title>
</head>
<body>
<h1></h1>
</body>
</html>
For comparison, this would achieve the same thing now and is much shorter and more memorable:
<!doctype html>
<title></title>
<h1></h1>
This is the shortest thing starting with that doctype that I can get validator.w3.org to accept without error or warning:
<!doctype html><html lang=""><meta charset="UTF-8"><title>x</title>The ="" there is unnecessary; writing an attribute name only implies an empty value.
If you’re going for shortest valid document at all, <!doctype html> is enough, provided the document exists in a context that makes title optional (e.g. email or <iframe srcdoc>) and that the charset is declared out-of-band.
If you’re going for shortest valid document at all, <!doctype html> is enough, provided the document exists in a context that makes title optional (e.g. email or <iframe srcdoc>) and that the charset is declared out-of-band.
You may be able to use a UTF BOM instead of the meta tag, or I think someone mentioned elsewhere having the server declare the character encoding in a header. I guess it depends on whether you count the header size which is better for golfing.
I fill in the title and h1 elements - this is just the template. And this version is not precisely the same, because it can't have the same timestamp :).
Wow, I haven't seen an HTML 4.01 doctype in ages.
Your boilerplate lacks all the features of this one...
Your boilerplate lacks all the features of this one...
Note that HTML allows you to avoid quoting parameters to make them easier to type:
<html lang=en class=no-js>
Why is type="module" the opposite of nomodule? This isn't a real question... just a big ol sigh
It’s a way of conveniently achieving compatibility with old and new browsers.
JavaScript is executed differently when it’s a “module script” to when it’s a “classic script” (using the HTML spec terms), so you want a way of preventing old browsers from executing it (whether they’re syntactically compatible or not). Hence type="module", because old browsers won’t execute scripts with the type attribute containing an unknown value.
Once you have that, you commonly want to bifurcate on modules support, so you want a way of saying “don’t execute this if you support modules”. This can be done with feature-detection code, to the effect of “does it support modules? if yes, do nothing; if no, load the code, probably by adding another script tag with the correct src to the document”, but this is inconvenient and causes at least mild inconvenience with security measures like Content-Security-Policy. So the solution was to put another attribute there that new browsers could use as the inverse of type="module": nomodule.
Perhaps it’s a big ol’ sigh, but as is very commonly the case with such sighs, they make a good deal of sense when you understand the reasons and history involved.
JavaScript is executed differently when it’s a “module script” to when it’s a “classic script” (using the HTML spec terms), so you want a way of preventing old browsers from executing it (whether they’re syntactically compatible or not). Hence type="module", because old browsers won’t execute scripts with the type attribute containing an unknown value.
Once you have that, you commonly want to bifurcate on modules support, so you want a way of saying “don’t execute this if you support modules”. This can be done with feature-detection code, to the effect of “does it support modules? if yes, do nothing; if no, load the code, probably by adding another script tag with the correct src to the document”, but this is inconvenient and causes at least mild inconvenience with security measures like Content-Security-Policy. So the solution was to put another attribute there that new browsers could use as the inverse of type="module": nomodule.
Perhaps it’s a big ol’ sigh, but as is very commonly the case with such sighs, they make a good deal of sense when you understand the reasons and history involved.
Be really interesting to understand when this actually get's executed
Maybe inline scripts ignore module, as they do defer and async
<script type="module">
document.documentElement.classList.remove('no-js');
document.documentElement.classList.add('js');
</script>
Maybe inline scripts ignore module, as they do defer and async
Inline <script type="module"> is executed after DOMContentLoaded.
Inline <script> is executed during parsing.
https://html.spec.whatwg.org/multipage/scripting.html#the-sc... gives the full details of the interactions between type, src, defer and async. Inline scripts are normally referred to as script elements where the src attribute is not present.
Inline <script> is executed during parsing.
https://html.spec.whatwg.org/multipage/scripting.html#the-sc... gives the full details of the interactions between type, src, defer and async. Inline scripts are normally referred to as script elements where the src attribute is not present.
Wow, thanks for that detail. That's some obscura to me.
>because it’s a vector and not raster image, and we can add HTML and CSS to the SVG, which means that we can support dark mode.
Doesn't work with the black chrome theme though, it seems. Can't see the icon at all because they gave it no outline.
Doesn't work with the black chrome theme though, it seems. Can't see the icon at all because they gave it no outline.
The in-your-face disclaimer at the top is really not needed. The site looks fine.
I think it's expected to look fine most of the time. But since the author isn't developing it locally, but rather updating the live site and seeing how things go, sometimes they will stuff up.
It's still nicely readable on both my old, cheap android tablet and my desktop. Kudos to the author for using good basic styles, even while reworking things.
You can also skip the " in many places, to be even more minimal.
Browsers don't follow the standard here completely, so you can do:
<a href = /some<!--li=nk<<"&wer' >link</a>
and all that garbage is parsed as is as attribute content until the first space or >. Only thing that terminates attribute value is > or whitespace.
You can also use entity refs in unqoted value.
That means you can use unquoted attribute values for almost anything that doesn't contain whitespace when writing html manually.
Browsers don't follow the standard here completely, so you can do:
<a href = /some<!--li=nk<<"&wer' >link</a>
and all that garbage is parsed as is as attribute content until the first space or >. Only thing that terminates attribute value is > or whitespace.
You can also use entity refs in unqoted value.
That means you can use unquoted attribute values for almost anything that doesn't contain whitespace when writing html manually.
What are the benefits of using the no-js approach over a style or link tag inside of a noscript element? Other than that all CSS can be contained in the same file.
[deleted]
I used to have a template (with css and js) that can be used as PWA, with offline caching and all that stuff. I copy most of the stuff from Google itself, but I never found their explanation that great.
I wish there was a guide for it too
[deleted]
+1 for the natural language tag. Remember to actually update it to the language used on the site. I regularily stumble across pages with a wrong language declaration. You pretty quickly notice this if you rely on a speech synthesizer to read the page content to you. Just a small change which can make such a big difference :-)
Bing also uses it for geo targeting I had not thought about accessibility and speech synthesisers - I will add that to our Guidance for developers.
That'd be great, thank you!
[deleted]
Why can't the speech synthesizer detect the language, especially when the language of dynamic content may change on the client-side after the page is loaded?
Language detection is much easier than synthesis, and one would think that a good synthesizer would devote the 0.1% of their engineering time necessary to have good language detection as well.
Language detection is much easier than synthesis, and one would think that a good synthesizer would devote the 0.1% of their engineering time necessary to have good language detection as well.
Surprisingly, automatic language detection isn't always reliable. And since the DOM actually has an attribute for this, which can also be placed on individual elements like a p or div, the first choice IMO is to rely on what the site declared.
> especially when the language of dynamic content may change on the client-side after the page is loaded
The `lang` attribute can be applied to any element, not just the whole document.
The `lang` attribute can be applied to any element, not just the whole document.
I wonder the same about Microsoft Word and Powerpoint. Is it so difficult to guess language in 2021? Particularly, to discern language between spanish and english, if both have already been manually set by the user in the document? It seems so...
People routinely manage to have "manually set" the language of documents that are very not English to en-US.
Cool, this is like https://github.com/h5bp/html5-boilerplate but a little worse
why worse?
Is it better in any way? There's very little difference.
We might not need a canonical URL, the favicon declarations are not needed, there's no repo...there's a reason HTML5BP is an industry standard.
We might not need a canonical URL, the favicon declarations are not needed, there's no repo...there's a reason HTML5BP is an industry standard.
Is it the same reason create-react-app is an "industry standard?"
no of course not, is this your first time hearing of HTML5BP?
There's a reason most of OP's boilerplate is copied and pasted from HTML5BP.
There's a reason most of OP's boilerplate is copied and pasted from HTML5BP.
shivbhatt(1)
One more thing I do is this to prevent FOUC:
<style>html{visibility: hidden;opacity:0;}</style>
html {
visibility:visible;
opacity:1;
}
On your FOUC preventer: please never ever do this. If your styles.css link tag is placed sanely (largely meaning “in the head”), the document won’t be drawn until it’s loaded or failed to load. If it loads successfully, the <style> tag served no purpose. If it fails to load, the <style> tag is now blocking access to the content.
On the rest: I mostly agree.
<title> versus og:title is commonly stupid, especially because consumers will tend to fall back to the <title> tag anyway (though in theory they should differ, with <title> normally including the site name, but og:title not supposed to); og:url and rel=canonical are even more stupid, because consumers will fall back to using the actual URL, so their only purpose is cases where the content is actually found at multiple URLs. (“But og:title and og:url are mandatory for OpenGraph validity!” you say? Please, you didn’t even put the prefix="og: https://ogp.me/ns#" attribute on the root element. No one does. No one cares. And I don’t think anyone cares for at least og:title and og:url either, though <meta property=og:description> versus <meta name=description> is uglier, and you can’t even merge the two or Twitter ignores the thing.)
Why can’t we assume UTF-8 unless told otherwise? Historical reasons, mostly. The web is an old place. Rejoice that everything new is done purely in UTF-8, and be comforted that even some of the older things are slowly shifted to a UTF-8 default over time, as the impacts of doing so become smaller.
The Apple icons are a more complicated historical mess. Be glad it’s down to only one stupid extra tag now, rather than a dozen or so, for each of their different device sizes. The time has come when they could fairly reasonably merge it back into icon, since they’ve given up on all of their fancy appearance of their icons.
On the rest: I mostly agree.
<title> versus og:title is commonly stupid, especially because consumers will tend to fall back to the <title> tag anyway (though in theory they should differ, with <title> normally including the site name, but og:title not supposed to); og:url and rel=canonical are even more stupid, because consumers will fall back to using the actual URL, so their only purpose is cases where the content is actually found at multiple URLs. (“But og:title and og:url are mandatory for OpenGraph validity!” you say? Please, you didn’t even put the prefix="og: https://ogp.me/ns#" attribute on the root element. No one does. No one cares. And I don’t think anyone cares for at least og:title and og:url either, though <meta property=og:description> versus <meta name=description> is uglier, and you can’t even merge the two or Twitter ignores the thing.)
Why can’t we assume UTF-8 unless told otherwise? Historical reasons, mostly. The web is an old place. Rejoice that everything new is done purely in UTF-8, and be comforted that even some of the older things are slowly shifted to a UTF-8 default over time, as the impacts of doing so become smaller.
The Apple icons are a more complicated historical mess. Be glad it’s down to only one stupid extra tag now, rather than a dozen or so, for each of their different device sizes. The time has come when they could fairly reasonably merge it back into icon, since they’ve given up on all of their fancy appearance of their icons.
In my experience, rel="canonical" is very useful for the very reason that if the content gets served from a different URL, say an archival page or a misconfigured server, you don't end up with two versions of the page being indexed by search engines. I try to add it to every page, now, so long as I can determine the page's canonical URL. I've found that it saves me a lot of future pain, when having to deal with duplicates that I may not even be able to control.
> so their only purpose is cases where the content is actually found at multiple URLs
Most content can be retrieved using multiple URLs - for example this comment section is available at both https://news.ycombinator.com/item?id=26952557 and https://news.ycombinator.com/item?id=26952557&blah as well as infinite other variants. Even if you only actively link to one version, you can't be sure no one else will fuck it up so rel="canonical" is useful. og:url should just default to that though (no idea if it does).
Most content can be retrieved using multiple URLs - for example this comment section is available at both https://news.ycombinator.com/item?id=26952557 and https://news.ycombinator.com/item?id=26952557&blah as well as infinite other variants. Even if you only actively link to one version, you can't be sure no one else will fuck it up so rel="canonical" is useful. og:url should just default to that though (no idea if it does).
> Why can't it use <title> for og:title?
Because the <title> is often something like "My Content | The Example Blog", which is a redundant information on social media cards so you set og:title to "My Content" only.
> Why can't it use the favicon for apple-touch-icon?
Because the favicon usually is a 32x32 icon that is small and only seen in the tab of the browser, whereas the apple-touch-icon is physically huge, and so requires more resolution.
> Why can't it use the URL for the url?
I assume you're talking about the canonical link tag? This is to prevent SEO penalties - specify a canonical link and Google will prefer your site as origin for the content over spammers that don't bother setting the tag, or in case you run an old-school site with dedicated mobile and desktop sites (see https://developers.google.com/search/docs/advanced/crawling/...).
> Why can't we assume UTF-8 unless told otherwise?
Historical baggage, mostly - the default charset for old content unless specified was either US-ASCII or its superset ISO-8859-1/latin1 (the HTTP/1.0 spec defaulted to US-ASCII, see https://tools.ietf.org/html/rfc1945 section 3.4 and the HTTP/1.1 spec, section 3.7.1, https://www.ietf.org/rfc/rfc2616.txt that defaults to ISO-8859-1). And there is a lot of old content that would break if this default assumption would change.
Because the <title> is often something like "My Content | The Example Blog", which is a redundant information on social media cards so you set og:title to "My Content" only.
> Why can't it use the favicon for apple-touch-icon?
Because the favicon usually is a 32x32 icon that is small and only seen in the tab of the browser, whereas the apple-touch-icon is physically huge, and so requires more resolution.
> Why can't it use the URL for the url?
I assume you're talking about the canonical link tag? This is to prevent SEO penalties - specify a canonical link and Google will prefer your site as origin for the content over spammers that don't bother setting the tag, or in case you run an old-school site with dedicated mobile and desktop sites (see https://developers.google.com/search/docs/advanced/crawling/...).
> Why can't we assume UTF-8 unless told otherwise?
Historical baggage, mostly - the default charset for old content unless specified was either US-ASCII or its superset ISO-8859-1/latin1 (the HTTP/1.0 spec defaulted to US-ASCII, see https://tools.ietf.org/html/rfc1945 section 3.4 and the HTTP/1.1 spec, section 3.7.1, https://www.ietf.org/rfc/rfc2616.txt that defaults to ISO-8859-1). And there is a lot of old content that would break if this default assumption would change.
> Historical...
If you call 2019 history already...
https://techcommunity.microsoft.com/t5/windows-10/windows-10...
If you call 2019 history already...
https://techcommunity.microsoft.com/t5/windows-10/windows-10...
Jesus Christ
> Because the favicon usually is a 32x32 icon that is small and only seen in the tab of the browser, whereas the apple-touch-icon is physically huge, and so requires more resolution.
You can have multiple rel=icon elements with different resolutions or even scalable ones. Also, browser tabs are not the only place where the favicon is used - and definitely not the original one.
You can have multiple rel=icon elements with different resolutions or even scalable ones. Also, browser tabs are not the only place where the favicon is used - and definitely not the original one.
> Why can't it use the URL for the url?
Because you can have multiple URLs for the same content and you need a way to say "by the way if you want to link to this page here's the proper URL"
For example, if you have example.com/blog/foo, it's possible that m.example.com/blog/foo, example.com/blog/foo/, example.com/index.php?path=/blog/foo, example.com/index.php?p=1234, example.com/blog/foo?textonly=1 etc etc all point to the same blog post and in many cases you simply can't set up a redirect because the URL is valid.
Because you can have multiple URLs for the same content and you need a way to say "by the way if you want to link to this page here's the proper URL"
For example, if you have example.com/blog/foo, it's possible that m.example.com/blog/foo, example.com/blog/foo/, example.com/index.php?path=/blog/foo, example.com/index.php?p=1234, example.com/blog/foo?textonly=1 etc etc all point to the same blog post and in many cases you simply can't set up a redirect because the URL is valid.
What I don’t understand is if we omit e.g. the og:title meta tag, why can’t scrapers fall back to <title>? Or if there is no <meta name="og:description"> why not fall back to <meta name="description">?
Most of the pages I make are unique and supplying these values twice is simply redundant. My only conclusion is that scrapers are stupid and developers are too laze to fix it (which ironically casts the work on other developers as we now need to supply these redundant values).
Most of the pages I make are unique and supplying these values twice is simply redundant. My only conclusion is that scrapers are stupid and developers are too laze to fix it (which ironically casts the work on other developers as we now need to supply these redundant values).
The stupid scrapers we're talking about are major social networks like Facebook and Twitter.
At this point I think it's more about unequal power than it has anything to do with developer laziness. Facebook and Twitter can tell others to add whatever stupid tags they demand, and people will comply. They can even call it a standard, and people will readily acknowledge it as such. Why change the status quo when you have the upper hand?
At this point I think it's more about unequal power than it has anything to do with developer laziness. Facebook and Twitter can tell others to add whatever stupid tags they demand, and people will comply. They can even call it a standard, and people will readily acknowledge it as such. Why change the status quo when you have the upper hand?
> What I don’t understand is if we omit e.g. the og:title meta tag, why can’t scrapers fall back to <title>? Or if there is no <meta name="og:description"> why not fall back to <meta name="description">?
They do fall back to <title> and <meta name="description">. At least Facebook does.
You can test it here (requires facebook login). It works though they complain about the missing tags. https://developers.facebook.com/tools/debug/
They do fall back to <title> and <meta name="description">. At least Facebook does.
You can test it here (requires facebook login). It works though they complain about the missing tags. https://developers.facebook.com/tools/debug/
What if your style never loads for one reason or another? Isn't it better for the user to get the content they are after as soon as possible? I thought the whole point of rendering the page as soon as possible was to be helpful to the user, why disable that?
> Why can't we assume UTF-8 unless told otherwise?
See https://hsivonen.fi/utf-8-detection/
See https://hsivonen.fi/utf-8-detection/
Because people using default OS encodings didn't mark their html files with explicit encoding. And defaults were not utf-8 for a long time. For example notepad defaults to utf-8 only since 2019, lol.
https://techcommunity.microsoft.com/t5/windows-10/windows-10...
https://techcommunity.microsoft.com/t5/windows-10/windows-10...
Because there are millions of people involved who have millions opinions on the topic and everyone wants their way. Thats why we have the bloody mess called HTML as a compromise.
"Why can't we assume UTF-8 unless told otherwise?"
And this I really do not understand either. I lost hours to restore data, that got lost in conversion from various text encoding formats, discovered too late.
"Why can't we assume UTF-8 unless told otherwise?"
And this I really do not understand either. I lost hours to restore data, that got lost in conversion from various text encoding formats, discovered too late.
[deleted]
Time ago, I made a minimal HTML boilerplate myself. Mainly because nobody seems to understand what the word minimal means...
Mine is truly minimal: https://github.com/TimDaub/mynimal-html5-boilerplate
Mine is truly minimal: https://github.com/TimDaub/mynimal-html5-boilerplate
> License MIT
You expect people to paste the MIT license into their website source in order to use your "minimal" headers?
You expect people to paste the MIT license into their website source in order to use your "minimal" headers?
Not truly minimal, it is fairly bloated due to the unnecessary usage of implicitly opened tags. You could get away with this:
<!doctype html>
<title>Your website: title</title>
<h1>Title of your site</h1>
<p>
Here begins the text of this page.
Markdown is more human-readable, easier to type, and more concise. Its lack of flexibility is an important feature, too (no JS, no styles, and only one way to make text bold).
> Its lack of flexibility is an important feature, too (no JS, no styles, and only one way to make text bold)
HTML has two ways to make things bold: b and strong. But only one way to make a toplevel heading, h1.
Markdown has one way to make things bold: ** **, but two ways to make a toplevel heading: # or ======
Other users have commented that Markdown in the wild is now little more than an alternative syntax for HTML, with scripts and other tags freely embeddable.
Moreover, HTML is basically HTML: we used to have problems with browser compatibility, but most of those are in the land of CSS and Javascript now. Whereas Markdown can be found in different flavors. Aside from the burden on the author to know what flavor they are writing, it limits the reusability of documents. Consider a git repo that has a Github-flavored README.md file written for github, but it is also shown as part of the package documentation in a language specific library repository that shows the same README.md file using a simpler flavor of Markdown. The basic tags probably all work fine, but the broken CI badges will perhaps make it frustrating to read.
HTML and Markdown both began with the best of intents as declarative document markup schemes. But because it is much harder to design a declarative programmer interface than an imperative one, both have accreted junk.
HTML has two ways to make things bold: b and strong. But only one way to make a toplevel heading, h1.
Markdown has one way to make things bold: ** **, but two ways to make a toplevel heading: # or ======
Other users have commented that Markdown in the wild is now little more than an alternative syntax for HTML, with scripts and other tags freely embeddable.
Moreover, HTML is basically HTML: we used to have problems with browser compatibility, but most of those are in the land of CSS and Javascript now. Whereas Markdown can be found in different flavors. Aside from the burden on the author to know what flavor they are writing, it limits the reusability of documents. Consider a git repo that has a Github-flavored README.md file written for github, but it is also shown as part of the package documentation in a language specific library repository that shows the same README.md file using a simpler flavor of Markdown. The basic tags probably all work fine, but the broken CI badges will perhaps make it frustrating to read.
HTML and Markdown both began with the best of intents as declarative document markup schemes. But because it is much harder to design a declarative programmer interface than an imperative one, both have accreted junk.
Markdown has broader applications than HTML though. Pandoc is my preferred document writing system for exactly that reason. Of course, when you go for the weirder branches of Markdown spec you'll get weirder results, but the documentation is fantastic, and it's pretty easy to stick to the golden path.
HTML has three other ways to make things bold using CSS
> Markdown in the wild is now little more than an alternative syntax for HTML, with scripts and other tags freely embeddable
HTML is not in the MD spec. We use a WYSIWYG MD editor so it's not an issue.
> Markdown in the wild is now little more than an alternative syntax for HTML, with scripts and other tags freely embeddable
HTML is not in the MD spec. We use a WYSIWYG MD editor so it's not an issue.
No JS? That’s news to me. I added <script> tags and custom HTML tags in the markdown and it worked. Check the source of this page (https://blog.nindalf.com/posts/how-to-learn-unix-tools/). It contains a CSS and JS declaration not present on other posts because they were included in the markdown.
Also if you want to fully commit to JS frameworks, you can. Some frameworks support MDX, which has full support for JSX tags. You can include react components right next to your text.
Also if you want to fully commit to JS frameworks, you can. Some frameworks support MDX, which has full support for JSX tags. You can include react components right next to your text.
The lack of any formal specification means Markdown can be pretty much anything you want it to be (provided there a supported implementation)
All markdown parsers I've encountered add tags into the final HTML without modification. It might not be a part of the standard, but it's the standard practice.
> Markdown is unnecessary nowadays.
Exactly! I personally hate Markdown. I can never remember how many asterisks is bold, italic, or whether images are [!img(src)] or !(img)(src) or  or [link](src!) or some other nonsense.
HTML is much more consistent, limiting yourself to a subset of HTML keeps things very readable, and it's super easy to slap a stylesheet on the top and make it come to life, and change that stylesheet at any time.
Exactly! I personally hate Markdown. I can never remember how many asterisks is bold, italic, or whether images are [!img(src)] or !(img)(src) or  or [link](src!) or some other nonsense.
HTML is much more consistent, limiting yourself to a subset of HTML keeps things very readable, and it's super easy to slap a stylesheet on the top and make it come to life, and change that stylesheet at any time.
* for italic, ** for bold. This is pretty standard on the internet in my experience.
Links are [](), but I do mess that up sometimes as well.
Markdown is not inconsistent though, and I find it very readable.
Links are [](), but I do mess that up sometimes as well.
Markdown is not inconsistent though, and I find it very readable.
I find it readable, but not that much more readable than plain old HTML with all styling relegated to a separate stylesheet, and using only the basic set of elements e.g. <h1>-<h6>, <a>, <img>, <p>, <pre>, etc.
I find HTML far more writeable than Markdown, however, as all things have a consistent syntax.
I find HTML far more writeable than Markdown, however, as all things have a consistent syntax.
> * for italic, * for bold.
I think something ate one of your *s. One star or underscore for italic; two stars or underscores for bold.
> Links are [](), but I do mess that up sometimes as well.
If you use the "remote ref" style[1], links are `[text][ref]` which is much easier (I remember the order as "this [text] points to that [ref]").
[1] https://www.markdownguide.org/basic-syntax/#reference-style-...
I think something ate one of your *s. One star or underscore for italic; two stars or underscores for bold.
> Links are [](), but I do mess that up sometimes as well.
If you use the "remote ref" style[1], links are `[text][ref]` which is much easier (I remember the order as "this [text] points to that [ref]").
[1] https://www.markdownguide.org/basic-syntax/#reference-style-...
[deleted]
Markdown would make it:
# You website: title
## Title of your site
Here begins the text of this page
> I do think it's easier to type.
I agree, but it's only marginally easier to type.
But the markdown is not the final product, it still needs to be converted to html using a "static site generator" or some other thing that breaks every couple of years. I had my static site break due to jekyll shenanigans four times in the last few years, and then I decided to move the whole thing to plain html, and replace jekyll and its myriad of unused and fragile dependencies with a three-line shell script that calls "cat". Moreover, markdown is confusing to use for basic stuff like links, images (see the sibling comment), and even enumerated lists [0].
[0] https://stackoverflow.com/questions/12145232/create-an-autom...
every dialect of markdown has an infuriatingly different way of doing basic things that totally breaks your soul if you use a handful of them at the same time.
EDIT:the example you wrote is not exactly the same thing as mine, is it? It seems like it would convert to H1 and H2 headings and both would be displayed in the body.
I agree, but it's only marginally easier to type.
But the markdown is not the final product, it still needs to be converted to html using a "static site generator" or some other thing that breaks every couple of years. I had my static site break due to jekyll shenanigans four times in the last few years, and then I decided to move the whole thing to plain html, and replace jekyll and its myriad of unused and fragile dependencies with a three-line shell script that calls "cat". Moreover, markdown is confusing to use for basic stuff like links, images (see the sibling comment), and even enumerated lists [0].
[0] https://stackoverflow.com/questions/12145232/create-an-autom...
every dialect of markdown has an infuriatingly different way of doing basic things that totally breaks your soul if you use a handful of them at the same time.
EDIT:the example you wrote is not exactly the same thing as mine, is it? It seems like it would convert to H1 and H2 headings and both would be displayed in the body.
> Moreover, markdown is confusing to use for basic stuff like [...] enumerated lists
This is a huge plus for me. Any list with more a dozen of entries and it would be tiresome to have to fix that. Also I can move the lines around freely without weird formatting issues.
Links are okay in my opinion, images are just a bunch of crap. To make an image clickable you'd have to do an image within a link, something like:
Completely agree there. Extensions of Markdown are really annoying, but I guess that's what happens when "true" Markdown wasn't updated since 2004.
This is a huge plus for me. Any list with more a dozen of entries and it would be tiresome to have to fix that. Also I can move the lines around freely without weird formatting issues.
Links are okay in my opinion, images are just a bunch of crap. To make an image clickable you'd have to do an image within a link, something like:
[](url)
Completely agree there. Extensions of Markdown are really annoying, but I guess that's what happens when "true" Markdown wasn't updated since 2004.
I agree, and went the html road as well for a time, but I hit roadblocks:
- When I'm in the flow, I really don't want to think about the structure of my text. The ms required for the tag insertion breaks that.
- Unless you very disciplined with your HTML use, it's hard to get back structure from you HTML doc. You have to limit yourself to the subset you would get from markdown.
I'm experimenting with asciidoc now, let's see if it's working.
- When I'm in the flow, I really don't want to think about the structure of my text. The ms required for the tag insertion breaks that.
- Unless you very disciplined with your HTML use, it's hard to get back structure from you HTML doc. You have to limit yourself to the subset you would get from markdown.
I'm experimenting with asciidoc now, let's see if it's working.
You can use style="white-space: pre-wrap" on a div, and
deal with the structure later. You'll still be able to use links and images, and the text will not look like a turd, before you get to finishing up the structure. At that point you can remove the pre-wrap style.
when in flow - does markup really matter then or is it mainly about letters and whitespace in sequence like text/plain?
Not sure but guess for me the latter, what about you?
Not sure but guess for me the latter, what about you?
> is it mainly about letters and whitespace in sequence like text/plain?
The main inconvenience of writing plain html is the need for <p> tags. They really do break the flow! It would be so much better if a blank line inserted them implicitly. This is indeed the killer feature of markdown and TeX.
The main inconvenience of writing plain html is the need for <p> tags. They really do break the flow! It would be so much better if a blank line inserted them implicitly. This is indeed the killer feature of markdown and TeX.
just add them 'after flow' and replace /^$/ -> </p><p>
?
You just wrapped your titles in <p>
I don’t understand these complaints about breakages. Download Hugo. Generate your site. Now use that Hugo binary till the end of eternity. The Hugo project might add, deprecate or remove features but that won’t affect you in any way. Your binary will continue to work till the end of time. (Assuming we still have x86 or ARM computers available)
> Download Hugo.
Never tried hugo, but it surely must be cleaner than jekyll. As a matter of policy I prefer to install tools packaged by my distribution. For debian, the jekyll package went through several "engines" and whatnot along the years, and each change broke the build. For some reason it even needed particular python versions, even if it is written in ruby. A complete nightmare. I honestly lost faith in static site generators after the experience with jekyll. Even if hugo is saner, it is still amenable to breaking as its debian package evolves, and I don't want to deal with that.
Never tried hugo, but it surely must be cleaner than jekyll. As a matter of policy I prefer to install tools packaged by my distribution. For debian, the jekyll package went through several "engines" and whatnot along the years, and each change broke the build. For some reason it even needed particular python versions, even if it is written in ruby. A complete nightmare. I honestly lost faith in static site generators after the experience with jekyll. Even if hugo is saner, it is still amenable to breaking as its debian package evolves, and I don't want to deal with that.
If you care about breakage, don't rely on a package manager that will constantly change the package version. Grab the binary from the Github releases page and use it in perpetuity.
> If you care about breakage, don't rely on a package manager that will constantly change the package version.
I do care about breakage of my C, C++ and Fortran programs, and I would be very surprised if updating gcc broke their build (unless using -Werror). Why can't static site generators, which are arguably much simpler than compilers, have the basic property of not breaking sites?
I do care about breakage of my C, C++ and Fortran programs, and I would be very surprised if updating gcc broke their build (unless using -Werror). Why can't static site generators, which are arguably much simpler than compilers, have the basic property of not breaking sites?
Hugo has no dependency (or rather they'd baked into the single binary), it's just a binary and even runs on my shared hosting. It's the only reason I switched from Jekyll. I had so much trouble with Jekyll breaking it was unbearable. Zola is another option.
That’s quite different: # is <h1>, ## is <h2>. What you were responding to used <title> and <h1>. Markdown is for units of content smaller than a page. It doesn’t provide any means of specifying document metadata or similar.
Clearly you're not a front end developer.
> <title>Your website: title</title>
Well...
Well...
It's so simple but so effective. Will be copying that.