Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HEAD – A guide to elements

htmlhead.dev

Post reply on HN
Print view View original

41–50 of 129 posts

Re: HEAD – A guide to <head> elements

#41

Post by btown »

bcoates wrote: post #21
saagarjha wrote: post #11

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

Do what they say, not what they do! maximum-scale has only three valid uses: 1. extreme values, like 5.0, if a browser misdetects that zooming that far is useful when it isn't (rare) 2. pure-app websites like maps or video games that have alternative scaling arrangements and browser pinch-zoom gets in the way. 3. there is no number three, and the thing you are thinking of is incorrect. maximum-scale is an automatic u…

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.

Re: HEAD – A guide to <head> elements

#42

Post by kevin_thibedeau »

gog wrote: post #37
combatentropy wrote: post #34

Why would 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.

Quite a few of these can be set in the HTTP headers as well, but people editing templates don't always have access or know how to do it. BTW; not all UTF-8 text has a byte-order mark, I would say most of them don't.

BOM is not valid in UTF-8 for one thing.

Re: HEAD – A guide to <head> elements

#43

Post by matthewhartmans »

jsploit wrote: post #38
bcoates wrote: post #21

Earlier quoted context omitted.

Do what they say, not what they do! maximum-scale has only three valid uses: 1. extreme values, like 5.0, if a browser misdetects that zooming that far is useful when it isn't (rare) 2. pure-app websites like maps or video games that have alternative scaling arrangements and browser pinch-zoom gets in the way. 3. there is no number three, and the thing you are thinking of is incorrect. maximum-scale is an automatic u…

> maximum-scale is an automatic usability and accessibility fail I wish more people realized this. As somebody that's visually impaired, it makes mobile browsing quite painful for me.

just out of curiousity, how do you deal with this problem in native apps where pinch zoom is disabled?

Re: HEAD – A guide to <head> elements

#44

Post by erik_seaberg »

kizer wrote: post #14
rolltiide wrote: post #7

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? It just gave me a chuckle thinking about it Thanks for the guide!

Uh... what do people call "it" now-a-days? Serious

Javascript thick clients.

Re: HEAD – A guide to <head> elements

#45

Post by tannhaeuser »

edflsafoiewq wrote: post #19
mpolichette wrote: post #3

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 . 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!

HTML even lets you omit the and tags, so the following is valid and equivalent:

    I am in the head
    I am in the body
I've described how this works for SGML here [1], but it also applies to HTML.

[1]: http://sgmljs.net/docs/sgml-html-tutorial.html (see slides linked from TALK)

Re: HEAD – A guide to <head> elements

#46

Post by softblush »

bcoates wrote: post #27
kizer wrote: post #13

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…

Is mdn not satisfactory for that? searching 'mdn array.from' brings up a nice one-pager on that and it works for almost any web/js documentation.

Sarcasm detector broken?

Re: HEAD – A guide to <head> elements

#47

Post by userbinator »

liquidise wrote: post #9

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

Re: HEAD – A guide to <head> elements

#48

Post by reificator »

rolltiide wrote: post #7

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? It just gave me a chuckle thinking about it Thanks for the guide!

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?

Re: HEAD – A guide to <head> elements

#49

Post by rahuldottech »

jsploit wrote: post #38
bcoates wrote: post #21

Earlier quoted context omitted.

Do what they say, not what they do! maximum-scale has only three valid uses: 1. extreme values, like 5.0, if a browser misdetects that zooming that far is useful when it isn't (rare) 2. pure-app websites like maps or video games that have alternative scaling arrangements and browser pinch-zoom gets in the way. 3. there is no number three, and the thing you are thinking of is incorrect. maximum-scale is an automatic u…

> maximum-scale is an automatic usability and accessibility fail I wish more people realized this. As somebody that's visually impaired, it makes mobile browsing quite painful for me.

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.

Re: HEAD – A guide to <head> elements

#50

Post by bcoates »

softblush wrote: post #46
bcoates wrote: post #27

Earlier quoted context omitted.

Is mdn not satisfactory for that? searching 'mdn array.from' brings up a nice one-pager on that and it works for almost any web/js documentation.

Sarcasm detector broken?

maybe? I like htmlhead.dev and it actually is a fairly underdocumented corner
Post reply on HN