> The above 2 meta tags must come first in the to consistently ensure proper document rendering.
It looks like they don't follow their own advice:
HEAD – A guide to elements
11–20 of 129 posts
Re: HEAD – A guide to <head> elements
#12Re: HEAD – A guide to <head> elements
#13We 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).
Re: HEAD – A guide to <head> elements
#14Does 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? It just gave me a chuckle thinking about it Thanks for the guide!
Uh... what do people call "it" now-a-days? Serious
Re: HEAD – A guide to <head> elements
#15This 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 . I don't have any supporting evidence though.
I havent heard of that but looking through RFCs might be the way to find out.
Re: HEAD – A guide to <head> elements
#16Immediately found a bunch of elements I had never heard of. This is really neat.
Especially
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.
Re: HEAD – A guide to <head> elements
#17> 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…
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 o…
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.
Re: HEAD – A guide to <head> elements
#18This is absolutely mortifying, how much metadata do pages have to share with browsers to do that one weirdly specific thing!?
What weirdly specific thing? 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 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.
Re: HEAD – A guide to <head> elements
#19This 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 . I don't have any supporting evidence though.
The HTML syntax lets you omit the tag. Any start tag not in the finite list of elements will implicitly start the body and go there.
I am in the head
I am in the body!
Re: HEAD – A guide to <head> elements
#20