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!
HEAD – A guide to elements
101–110 of 129 posts
Re: HEAD – A guide to <head> elements
#102Earlier 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.
Re: HEAD – A guide to <head> elements
#103Earlier 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.
Re: HEAD – A guide to <head> elements
#104Earlier 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 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
#105Earlier 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!?
Re: HEAD – A guide to <head> elements
#106Would love to see if/how these apply to html email/email-clients.
Re: HEAD – A guide to <head> elements
#107Earlier 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.
Re: HEAD – A guide to <head> elements
#108Earlier 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!
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
#109Earlier 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…
Re: HEAD – A guide to <head> elements
#110Earlier 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…