Live data from Hacker News

HEAD – A guide to elements

htmlhead.dev

71–80 of 129 posts

Re: HEAD – A guide to <head> elements

#71

> 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…

allows you easy access to modern approaches to mobile development. What exactly does that mean? It reads almost like marketing copy for a new framework.

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.

Re: HEAD – A guide to <head> elements

#72
post #66
post #62

Earlier quoted context omitted.

Taking screenshots and zooming in on those... a very tedious process.

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.

android has the same thing. you can activate an accessibility setting and then a triple tap will zoom in everything system-wide

Re: HEAD – A guide to <head> elements

#73
post #58

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. [1] https://www.dublincore.org/specifications/

Are these corporate 'namespaces' themselves even a standard? Isn't the prefix in meta@name just an informal convention?

Re: HEAD – A guide to <head> elements

#74
post #69
post #18

Earlier quoted context omitted.

My favorite weird thing that happens without certain 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.

This is how I avoid this issue entirely:

    
This is the smallest possible "null" favicon. It causes the browser to display nothing and ensures 0 HTTP requests for the favicon!

Re: HEAD – A guide to <head> elements

#75
post #20

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.

[deleted]

Re: HEAD – A guide to <head> elements

#76

Surprised all icons is only: I thought there was literally like a dozen different sizes and names to support all different Apple and Android devices.

You don’t even need those. Safari will automatically look for a file on the root and so does Android.

Still, I know what you’re talking about and it’s awful how many “gurus” suggest all that noise.

Re: HEAD – A guide to <head> elements

#77
post #64

Earlier quoted context omitted.

I last touched it in 2012 - but apparently, yes, yes it is: https://helpx.adobe.com/dreamweaver/using/whats-new.html Although, it looks like their cumulative 2019 updates are limited to the following headlines between the two: 1) added support for HTML tag highlighting inside PHP code 2) bootstrap CSS support. ... I was surprised to see it was still alive.

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.

Re: HEAD – A guide to <head> elements

#78
post #22
post #16

Earlier quoted context omitted.

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.

Out of interest, what would you use instead these days?

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.
Post reply on HN