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.
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.
<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>.
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.)
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.
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.
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.)
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.
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.
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”.
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!
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.
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.
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!
> 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).
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
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.
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:
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
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.
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.
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.
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
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.
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!
As someone not doing web development all day, to me it's much closer to how CSS should have been from the start. I still find it a bit too overloaded thanks to many years of piling more features on a standard that has to keep backwards compatibility, but that's another problem.
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.
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.
"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.
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.
" 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.
I don't use html, head and body tags and I don't close tags that don't need to be closed like p. With this html is almost like markdown.
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.
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 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.
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 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.
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):
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
> 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.
- 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.
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.
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?
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've tested this and it works fine on apple devices.
<meta charset="UTF-8">
By default servers add the charset as an http header. So you don't need to declare it in the document — in the case of offline where there are no http headers, the browser works out what encoding to use. And since utf-8 is the only valid charset for HTML5 it should be the default. I've tested this a bit, and it seems to work.
> 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.
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.
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.
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.
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:
<meta name="color-scheme" content="dark light">
This is also useful on other browsers: for example, it will make safari choose dark/light UI elements (buttons, dropdowns, etc.) depending on the color-scheme preference.
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:
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.)
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.
For these tags, what ends up happening if you try to use the XML self-closing notation is that the "/>" is ignored and then the missing close tag is inserted at a later point, which may or may not be where you want.
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.
See, the headings did get closed eventually, even without their proper closing tags; it just wasn’t where you wanted, either time. (The paragraphs, on the other hand, probably ended where you expected.)
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>
… and here’s what that is precisely equivalent to:
> 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/>.
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.
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?
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.
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.
<!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>
And according to the file timestamp, have done so since Nov 24 2005.
For comparison, this would achieve the same thing now and is much shorter and more memorable:
<!doctype html>
<title></title>
<h1></h1>
(My recollection is that the HTML 4.01 Strict DTD doesn’t trigger quirks mode; if that’s correct, then it should be precisely the same, except for whitespace variation and the actual doctype node. Also neither is valid, because the title element can’t be empty.)
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.
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 :).
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.
module has defer semantics by default i.e. it gets executed after the document has finished parsed, and I can't find anything in the WHATWG spec to suggest it's different for inline scripts
Maybe inline scripts ignore module, as they do defer and async
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.
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.
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
+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 :-)
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.
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.
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...
Might I note that you are also lacking an SSL certificate, which marks your site as 'not secure' and can trigger various anti-phishing protections in browsers and firewalls.
I am not sure what you mean by 'convert wordpress', but if you are looking for a no-code solution for throwing up a static site to Cloudflare (with SSL), I happen to make a website builder that does just that. I like to think it's much easier to use than Wordpress.
I won't advertise it here, but have a look in my profile if you're interested. Ping me for a discount :)
Honestly though the amount of meta tags in this boilerplate is ridiculous. What has the web come to? Why can't it use <title> for og:title? Why can't it use the favicon for apple-touch-icon? Why can't it use the URL for the url? Why can't we assume UTF-8 unless told otherwise?
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.
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).
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 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.
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).
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?
> 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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].
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:
[](url)
> 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.
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.
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.
> 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.
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)
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?
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.
