Live data from Hacker News

HEAD – A guide to elements

htmlhead.dev

101–110 of 129 posts

Re: HEAD – A guide to <head> elements

#101
post #69

Earlier quoted context omitted.

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!

Does the browser display the generic "no favicon" icon, or is it just completely blank? I like the idea.

Re: HEAD – A guide to <head> elements

#102

Earlier quoted context omitted.

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

To be pedantic, the Unicode standard disrecommends the use of a BOM in UTF-8-encoded documents rather than declaring it invalid.

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.

Re: HEAD – A guide to <head> elements

#103

Earlier quoted context omitted.

To be pedantic, the Unicode standard disrecommends the use of a BOM in UTF-8-encoded documents rather than declaring it invalid.

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.

Re: HEAD – A guide to <head> elements

#104
post #56
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…

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

order a _house_?

I guess they won't know what business they're losing 'cos they won't know people are leaving the site because of that specific issue.

If they're on the ball, their tracking might be good enough that they can see people leaving on that step and try to zoom in on that problem area.

If they're really good, they might spot they get no sales from users with a certain resolution and try it out for themselves.

Re: HEAD – A guide to <head> elements

#105
post #56
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…

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

I feel like this is a bit of a humblebrag, but you can order houses online?

Re: HEAD – A guide to <head> elements

#107

Earlier quoted context omitted.

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!

Does the browser display the generic "no favicon" icon, or is it just completely blank? I like the idea.

It's completely blank (tested in Firefox and Chromium).

Re: HEAD – A guide to <head> elements

#108
post #96

Earlier quoted context omitted.

> news websites with long-form articles, shouldn't be using mobile pages / responsive design / zoomed-in layout at all Do you mean you actually prefer having to scroll left/right/left/right/left/right when reading a long article?

No, Safari on iOS auto-formats text columns to be screen width when you zoom in (double-tap) on them... but the rest of the website is intact!

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.

Re: HEAD – A guide to <head> elements

#109
post #96

Earlier quoted context omitted.

No, Safari on iOS auto-formats text columns to be screen width when you zoom in (double-tap) on them... but the rest of the website is intact!

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…

That shows OK on iOS (6 lines of text, vs 2.5 lines on desktop Safari), without even having to double-tap.

Re: HEAD – A guide to <head> elements

#110

Earlier quoted context omitted.

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…

Completely off topic, but it's hilarious how slow the NY times website loads in that first video.
Post reply on HN