DublinCore[1] is totally missing! It once was the metadata standard, it's understood by archives and libraries (including Library of Congress) worldwide, macOS will automatically import them into spotlight, etc.
Instead we find many of those tags (title, description, author, etc.) hidden behind the namespace of some corporations.
I tried to order a house online last night and I got to the "enter your email address to get your free quote" and because I couldn't zoom out, I could not see the Submit button.
OMG, I thought how much money is this company losing because their website intentionally disables a built in feature!?
Just FYI in case you didn't know, both Firefox and Chrome on mobile allow you to force zoom even if there's a viewport restriction. Check accessibly settings.
With iOS you don't need to do this. You can enable zooming as a system-wide feature. You can even zoom parts of the screen, like a magnifying glass. You can find all of these settings under Settings -> Accessibility -> Zoom.
Is there a way to change this in JS? I'd love to, say, make sure that the zoom doesn't automatically change because I have an input element that's slightly thinner than the viewport and Apple thinks this is what people want, but still let people pinch to zoom.
This is the thing that limit the zoom-out with a pinch in safari/scroll beyond the page and see the "surface" underneath I'm assuming correctly hopefully
Isn't x-ua-compatible not needed or not respected anymore? I think this for some reason... maybe I read it somewhere or concluded so; can't recall, lol.
> Below are the essential elements for any web document (websites/apps)
> "...width=device-width, initial-scale=1..."
This is a surprising bit of opinionation to an otherwise decent presentation of head elements. Websites render quite nicely on modern phones without this line, but they generally render as if they are on a desktop browser. Using the above meta tag allows you easy access to modern approaches to mobile development.
I'm not an expert. But in my experience, that line has been the solution to 100% of any viewport issue I've ever had on mobile, and has made webpages "just work" and render how I'd expect them to on mobile, as opposed to weird issues with font size and scrolling.
I've never had that line do something I didn't want. Is there a reason mobile browsers don't automatically just do whatever that line does? Seems like the opt-in behavior should be "yes, render me like I'm a desktop site on a tiny monitor" rather than opt-out.
Legacy reasons. When the iPhone came out, "mobile only" sites were a wasteland of terrible UI and restricted features. iPhone OS wanted to serve full websites, and sometimes had to do weird things to beat the kind of stuff that sniffed for mobile devices, or to overcome the lack of a mouse on a desktop website.
If you look at the original iPhone demo in 2007[0], the original intent was to render full web pages on the screen and rely on the double-tap-to-zoom to read content.
The article that's generally credited with naming and mainstreaming Responsive Web Design[1] didn't come until 2010.
It makes mobile web browsers be honest about the size and resolution[1] of their screens; without it, they lie and claim to have desktop-sized viewports.
Once the browser is being honest about its screen, you can use CSS media queries and the like to do responsive web design, giving mobile devices content that fits them and is touch-friendly. If the browser is claiming a desktop-sized viewport, your options are to either serve a desktop layout or to do User-Agent sniffing and the like.
[1] All high-res devices today maintain a distinction between a CSS pixel (approximately 1/96 in.) and a device pixel, and they give their resolution in CSS pixels. This is dishonest from the point of view of 1995, but it’s convenient and it’s what web designers expect today.
> but they generally render as if they are on a desktop browser
If you wanted to avoid using that for some reason, there is a very effective (~99% coverage) way to do it and make your site render perfectly on mobile. In your application, simply check the user agent for "mobile" and insert whatever resources you prefer to adjust for mobile (perhaps an entirely different design for example, as is sometimes appropriate) and failing that switch to desktop view resources.
For common caching (you don't want to cache one universal copy of a page for desktop and serve that to mobile), if you're using Nginx as a web server and for caching, map a mobile value based on the detection of the keyword "mobile" in the user agent, something like:
Staple that $mobilekey value to the proxy_cache_key to generate two cache versions, one for mobile, one for desktop. For most sites this is a low burden expense. The map approach also avoids the various pitfalls of attempting to use IFs in Nginx, so it's extremely performant.
This approach has obvious downside risk, such as if the popular browsers decide to drop the mobile keyword from their user agent strings (there are other simple ways to target the user agent that would solve that change however). The industry overwhelmingly disagrees with targeting the user agent like this, however it works perfectly well and has for a long time.
We need more single page references like this, IMO, for all sorts of random domains. Even something like a single-page reference for how Array.from works in JS, as an example. Even if it were standalone it could later be integrated into a broader reference work. In the meantime, a "arrayfrom.dev" page, although non-general, would fill a specific niche w/ a mnemonic URL (Array.from is just an example - no idea whether or not it would be considerable in this regard).
Other "pages" (as rough-sketch descriptions) I can imagine: colors.dev, cacheperf.dev, unicode.dev, rdf/microdata.dev, parsing.algorithms.dev, querystring.dev (a micro reference for sure).
Likewise, "micro" web tools which I'm sure exist as a concept I don't know already would be very convenient (xml->json converter, linters/viewers/auditors of all sorts).
Please no. IMO this makes most pages unusable on mobile. Most websites, e.g. news websites with long-form articles, shouldn't be using mobile pages / responsive design / zoomed-in layout at all. Web apps (Twitter, GMail), maybe. But most mobile pages are far more unusable than desktop versions (looking at you, Facebook and Reddit).
We must have different devices. IMO most pages are unusable on mobile without this. I wonder if it's the device, website content, or personal preference at play here.
If I double-tap a column of text, it will zoom in on the part of the page to fit the width of the column on the screen, but if the column is too wide (e.g. a page with just a single 100% width column of text) the text size is still unreadably small. It won't reflow the column to fit the screen. (e.g. try visiting http://www.catb.org/~esr/jargon/html/I/ICBM-address.html, a page with no viewport directive and not even any page width CSS)
The early Android browser used to actually reflow columns to fit on the mobile screen when you zoomed in, but it lost that in the transition to Chrome.
You must have much better eyes than me (or a bigger iPhone) - at 6 lines the font size is half the size of the text on Hacker News, which is already pushing it for readability, and a third of the default font size for Safari's own "reader mode".
The 6 lines comes from iOS Safari defaulting to emulating an approx 800 point wide display (on a 400 point wide display)
Indeed, I've 20/20 vision... Setting "Larger Text" in Accessibility Settings unfortunately doesn't increase the rendered text size on that website (it should) but it also doesn't increase it on Twitter's fully mobile website.
I agree with this. I often prefer desktop pages because they have more functionality. Even Google's search gives you better search settings in desktop mode compared to mobile (you can't set arbitrary search dates on mobile, you can on desktop, oh and mobile search forces the horror of AMP on you). I also loathe the mobile version of reddit, even more than the new UI.
The only pages I prefer in mobile view are ones that get rid of their backgrounds and useless white space on the sides. I use HN in mobile view, but the difference is small enough that it doesn't matter.
Even the htmlhead.dev site that is linked works better in desktop mode, because it doesn't force you to scroll the code tags.
I use Dreamweaver all the time. It's actually a full-blooded static site generator, two decades before that was trendy. And marketing can use the visual editor to make it a content management system.
I still use a copy because no editor has a built in sftp anymore. Sublime/vs code/phpstorm are great for git projects but for remote projects you don't want to work on locally dreamweaver can't be beat. The only problem is modern code has changed syntax so dreamweaver gives warnings for valid code. I wonder if anyone has updated these.
VS Code has just come out with a Microsoft team SFTP plugin. It's pretty good, search even works. Seems to fix almost all the issues I tended to get using sshfs. Recommend giving it a shot.
Side note in 2012 my boss forced me to use Dreamweaver and took a lot of persuading to let us use the new (at the time) Sublime text. Good times.
Since you mention text editors, Emacs can be used to work remotely by its TRAMP remote access layer. Instead of /path/to/file, you type /ssh:user@host:/path/to/file. Since Emacs has a built-in directory browser, you can use it as if it was an SFTP client this way.
You can deploy through sftp but you still need save the files locally. I could accept that but then you generate a laravel db migration file or config file is created through a package that was installed remotely. So your local copy doesn't have the new file. So now you have to resync the repo. Resyncing the repo from the root directory brings in the vendor packages locally so a resync could take an hour. You need to go to subfolder by subfolder resyncing if you want to avoid that.
Dreamweaver is open-edit-push back. Perfect when you have to make a change to a site and don't want all of the fiies locally.
Why would <meta charset="utf-8"> be required if you can set it in the HTTP headers? I've also read that modern browsers (everything except IE) will look for a byte-order mark.
It makes zero sense to specify a byte order for an encoding in which it is irrelevant. It only persists because of a lazy vendor that can't encode Unicode correctly.
It would have been nice if every well-encoded Unicode document started with BOM and every legacy doc did not, instead of having to guess whether a doc is more likely UTF-8 or Latin-1.
Then concatenating to valid Unicode documents would no longer be valid Unicode. That is bad.
And ASCII text would no longer be a valid UTF-8 encoded Unicode document. That is bad.
And even when everything has finally switched to UTF-8 every tool ever will still need to handle the BOM. That is bad.
Guessing between valid UTF-8 and Latin-1 is only ever ambiguous when there are multiple non-ASCII characters in a row and all those sequences are made up of a lead byte with the correct number of trailing bytes. How often is that a problem for you in practice?
I imagine it's the cumulative amount of my first example, curl, and probably other "save as html" functionality in some browsers, crawlers, s3 buckets, archival tools, and so on. I'm sure many can do as you suggested and inject the header, but suspect many don't.
Another use case might be content that is authored in a content management system. Perhaps it's the easiest way to carry your intended charset to the destination.
"Recommended Minimum" lists <meta name="viewport" content="width=device-width, initial-scale=1">. While it is indeed recommended, the site should say to actually try testing the website on a mobile device with this attribute before adding it - marking the website as mobile friendly when it's not is worse than not doing so.
You don't have to put anything in a head tag, you don't even need a head tag, but it's a good idea to have one and to at least add a charset meta tag. Everything is optional, though.
The entire point of it is for you to share metadata about your page with the browser.
My favorite weird thing that happens without certain <head> tags is the ten billion attempts to get a favicon. I don't know if browsers still try all those silly favicon requests if none is defined, but it was saddening to watch that grow to be wide spread previously.
Yes, they all still issue several favicon requests, so far as I'm aware. Having one, instead of returning a 404, can speed up the page load. Which makes 0 sense.
Yes. See this comprehensive resource [0] or sieve trough those linked at the Head project [1] - there are still bunch of tags (especially if you cannot place images into the root path) and myriad of images with varying degree of importance. Even now most resources apparently slightly disagrees with each other.
This is specifically elements which are allowed in the `head` element of the document.
I recently read somewhere that for backwards compatibility reasons no new element types can be added within `head`. This causes a lot of overloading on the existing ones for elements like <link />.
<base> was super nice in the old days when I worked with servers without subdomains for staging/testing, it made it pretty trivial to have domain.tld/website and domain.tld/testing/website ... granted, those were dark days and I'd never use that approach now, but it was appreciated.
Oh, usually <base> is still bound to the server root name, but in most cases an SPA or what-have-ye will be served off the base subdomain with client side routing hints - then everything can just be referenced using stripped down relative URLs.
Actually though, for the server-side processed stuff we are still using <base> to make sure that /fancy/bespoke/url/style URLs doesn't try to grab assets from /fancy/bespoke/url/style/styles/main.css - I guess it's less that I don't use it and more that now-a-days I rarely set it to anything other than domainname since I'll just materialize a new subdomain if I need to do something fancy.
A combination of sane, centralized routing and view layout, relative paths, and getting the scheme/host from the framework or environment config if really needed.
Does anybody remember that funny thread where some dev here was saying "who calls it HTML5 anymore" as if everyone else was out of touch with stagnating irrelevant skills that would immediately throw red flags during a phone screen?
I mean, I'd call it html unless searching for the list of features that were bundled as html5 specifically. My understanding is that html5 was only versioned at all to differentiate it from legacy html versions. It's a living standard at this point, discrete versions are avoided at all costs. Just look at the doctype, if the intention was to continue versioning as before why did they leave the 5 out of the doctype?
Less seriously, sometimes it's referred to as "Oh, whatever happened to XHTML 2.0, I was so looking forward to that, oh well guess we're using HTML5" but this is usually at conferences.
I think people understood my comment neither correctly, and ,it seems, nor in the same way? Anyways, what I was asking was whether there exists a new name for html5? Have people dropped the 5? Comically, it was always a vague, tattered umbrella term from the get go (whenever used to refer to anything else than HTML5 the language/spec).
It's kinda like how sometimes you use "Javascript" but in some contexts you're talking about a specific version (e.g. new features) and will instead mention it by a version name.
Instead we find many of those tags (title, description, author, etc.) hidden behind the namespace of some corporations.
[1] https://www.dublincore.org/specifications/