Reducing font size on page as wide as a 1080p display would just cause the automatic word wrapping to cram more text onto each line, making the problem even worse. This is why newspapers have multiple columns per page and why the "Better MF Website" sets a maximum width for the body text column.
Did you just assume the size of my screen and the size of my pointing device?
Until web browsers support CSS4 media queries, web browsers have to use CSS3 media queries and assume that any device with a viewport narrower than 26em or so has a touch screen, which is a coarse pointer.
What if it is a touchscreen device with mouse support, what then?
It goes based on whether a mouse happens to be connected. This can cause documents using the @media (pointer:coarse) media query to change styles when a mouse is connected or disconnected.
This device is intended for people who lack such an extensive cartridge collection. Though you are outside this device's market, this market exists nonetheless.
And if you really can't make it work, consider also using min-width and max-width expressions based on physical size in addition to pixels, so you're measuring physical and virtual capabilities of the device. Even Windows can work accurately with those now.
I'm failing to understand how high DPI implies pointer precision, unless you're recommending targeting specific models of Apple kit. Laptops and Android tablets vary so much in DPI that the high end of tablets, which lack a trackpad, is likely to overlap the low end of laptops, which have a trackpad.
How is a keyboard irrelevant? I find a keyboard relevant for two reasons.
A site might use the presence of a keyboard as a (weak) proxy for the presence of a mouse. I admit that this is weak because a phone may be used with a Bluetooth keyboard but no Bluetooth mouse or trackpad.
I find it tedious to enter HTML, such as the <strong>, <em>, <a href="...">, and <code> elements commonly used in Slashdot comments, without a physical keyboard because the required punctuation is scattered across multiple pages of the on-screen keyboard. The presence of a keyboard may affect the default setting for whether to present an HTML editor or a limited functionality comment form that takes only plain text and pasted URLs.
Without advertisements, how should a site's operator pay its writers, its server operators, and its bandwidth bill? Paywalls don't work for sites that rely on traffic from search engines. What's the third way, besides ads and paywalls, to fund a site that is larger in scope than a hobby?
When I browse on my phone, I just zoom in if a link is too hard to tap.
You are also aware of the zoom feature. Not all sites' audiences are as technical as that of Slashdot. In addition, the mobile view of Google Search penalizes sites that initially load with text too small or links too close together.
Fine-point styli for touch-operated devices still under warranty, such as the Apple Pencil and Samsung S Pen, aren't widespread among most websites' audiences. And a stylus for capacitive touch screens is nearly as imprecise as the finger it's designed to emulate.
All iPad models present a 1024x768 viewport in landscape mode
So did my first couple PCs (an Acer TravelMate laptop and a Dell Dimension desktop), which had a 1024x768 pixel display and a mouse. My netbook (a Dell Inspiron mini 1012) also has a 1024-pixel-wide viewport because its display is 1024x600 pixels, but it has a trackpad. A full-size PC is likely to have a 960-pixel-wide viewport and a mouse when the user "snaps" a browser window to half of a 1920x1080 pixel screen.
The shittiest Chromebook I can find presents a 1280x720 viewport.
According to the site you linked, the Nexus 10 tablet in landscape orientation also presents as having a 1280-pixel-wide viewport.
My smartphone has enough resolution and the ability to pan / scan / zoom over all of your content.
Then what's the proper way to serve the majority of users, who prefer to view documents that are already at a reasonable zoom level when they first load? Search engines behave similarly: Google is known to penalize documents that aren't already at a reasonable zoom level when they first load.
I read the W3C spec page for CSS3 media queries. But I couldn't find a media feature for "an input device more precise than a finger-operated touch screen is in use" or "the device has a physical keyboard" or "the connection is metered". Can any web dev point me in the right direction for these features?
wouldn't it be more effective for the customers and more profitable for Nintendo to make these games available on DVDs/cartridges for current systems?
Wii and Wii U had Virtual Console, which is what you describe except provided as a download rather than as physical media. The best guess for when Virtual Console will reach Nintendo Switch is 2018, when Nintendo plans to launch the Switch's online service.
How much would the ROM licenses for your Raspberry Pi solution run you? They wouldn't even be available for first-party games, which outnumber third-party games in this collection.
Nintendo should be manufacturing additional NES Classic units
And get sued out of existence for copyright infringement if the original deal with the third-party publishers specified a limited number of units. Or would you prefer a limited-functionality NES Classic with all third-party games cut out?
And controlling the padding with a CSS media query breakpoint based on viewport width doesn't help because a touch-operated iPad held in landscape orientation has more pixels than a trackpad-operated netbook.
@media
Could you be more specific as to which CSS media query expression you refer?
Apple allows only one browser engine on iOS and that engine is Webkit.
The other option is remote rendering, as used by Opera Mini. Microsoft could likewise run EdgeHTML in its huge Azure cloud and send the result of remote rendering to iOS devices.
It's unclear to which part of the article you are referring. I searched inside the document "I decided to disable AMP on my site" by Alex Kras for the words "touch" and "finger", and neither word was there. I searched for the word "link", and none of the results mentioned adapting link size based on whether the browser uses touch or mouse. Could you quote a sentence from the relevant portion?
We are talking about sites weighting several megabytes for the equivalent of a single blog post, with scripts creatively breaking browsers. With a 2.3MB / 66 object webpage, the author is definitively guilty of this.
Is 2.3 MB for a whole month's worth of blog posts, including several photos and/or CGI renderings, likewise too heavy? If so, what change would you recommend for a page like this one?
Please, for the love of God, look upon my 16 DIMM slots ye Mighty frugal HTTP server, and load the whole damn document all at once, SVP.
Even a PC with double digit GB of RAM can be connected to a satellite or cellular upstream connection whose ISP charges $5 to $10 per GB. Though a non-AMP page like this still loads fast because it's so simple, I imagine people aren't going to be happy to pay the ISP to load images that won't be viewed.
Unless you've already installed the largest RAM modules that your PC will take. I've seen new PCs for sale with no option to reconfigure for more RAM. For example, this product detail page for an Inspiron 11 3000 laptop mentions "2GB" but doesn't offer any choice to upgrade at build time nor state what sort of RAM slot it has.
Opera Mini renders HTML documents remotely in order to work around the Apple WebKit restriction. In addition, different wrappers for Apple WebKit can have different battery life characteristics, though I imagine the difference is negligible. Among Opera Mini rendering remotely, Safari wrapping Apple WebKit, Chrome wrapping Apple WebKit, and Firefox wrapping Apple WebKit, which of the four can browse for the longest on a single charge?
Slashdot Mirror
Reducing font size on page as wide as a 1080p display would just cause the automatic word wrapping to cram more text onto each line, making the problem even worse. This is why newspapers have multiple columns per page and why the "Better MF Website" sets a maximum width for the body text column.
Did you just assume the size of my screen and the size of my pointing device?
Until web browsers support CSS4 media queries, web browsers have to use CSS3 media queries and assume that any device with a viewport narrower than 26em or so has a touch screen, which is a coarse pointer.
What if it is a touchscreen device with mouse support, what then?
It goes based on whether a mouse happens to be connected. This can cause documents using the @media (pointer:coarse) media query to change styles when a mouse is connected or disconnected.
This device is intended for people who lack such an extensive cartridge collection. Though you are outside this device's market, this market exists nonetheless.
Neither IE nor Firefox supports pointer:coarse.
And if you really can't make it work, consider also using min-width and max-width expressions based on physical size in addition to pixels, so you're measuring physical and virtual capabilities of the device. Even Windows can work accurately with those now.
I'm failing to understand how high DPI implies pointer precision, unless you're recommending targeting specific models of Apple kit. Laptops and Android tablets vary so much in DPI that the high end of tablets, which lack a trackpad, is likely to overlap the low end of laptops, which have a trackpad.
When lines of text are nearly 1920 pixels long, how do you avoid rereading a line or skipping a line?
The presence of a keyboard should be irrelevant.
How is a keyboard irrelevant? I find a keyboard relevant for two reasons.
A site might use the presence of a keyboard as a (weak) proxy for the presence of a mouse. I admit that this is weak because a phone may be used with a Bluetooth keyboard but no Bluetooth mouse or trackpad.
I find it tedious to enter HTML, such as the <strong>, <em>, <a href="...">, and <code> elements commonly used in Slashdot comments, without a physical keyboard because the required punctuation is scattered across multiple pages of the on-screen keyboard. The presence of a keyboard may affect the default setting for whether to present an HTML editor or a limited functionality comment form that takes only plain text and pasted URLs.
Without advertisements, how should a site's operator pay its writers, its server operators, and its bandwidth bill? Paywalls don't work for sites that rely on traffic from search engines. What's the third way, besides ads and paywalls, to fund a site that is larger in scope than a hobby?
When I browse on my phone, I just zoom in if a link is too hard to tap.
You are also aware of the zoom feature. Not all sites' audiences are as technical as that of Slashdot. In addition, the mobile view of Google Search penalizes sites that initially load with text too small or links too close together.
Fine-point styli for touch-operated devices still under warranty, such as the Apple Pencil and Samsung S Pen, aren't widespread among most websites' audiences. And a stylus for capacitive touch screens is nearly as imprecise as the finger it's designed to emulate.
All iPad models present a 1024x768 viewport in landscape mode
So did my first couple PCs (an Acer TravelMate laptop and a Dell Dimension desktop), which had a 1024x768 pixel display and a mouse. My netbook (a Dell Inspiron mini 1012) also has a 1024-pixel-wide viewport because its display is 1024x600 pixels, but it has a trackpad. A full-size PC is likely to have a 960-pixel-wide viewport and a mouse when the user "snaps" a browser window to half of a 1920x1080 pixel screen.
The shittiest Chromebook I can find presents a 1280x720 viewport.
According to the site you linked, the Nexus 10 tablet in landscape orientation also presents as having a 1280-pixel-wide viewport.
My smartphone has enough resolution and the ability to pan / scan / zoom over all of your content.
Then what's the proper way to serve the majority of users, who prefer to view documents that are already at a reasonable zoom level when they first load? Search engines behave similarly: Google is known to penalize documents that aren't already at a reasonable zoom level when they first load.
I read the W3C spec page for CSS3 media queries. But I couldn't find a media feature for "an input device more precise than a finger-operated touch screen is in use" or "the device has a physical keyboard" or "the connection is metered". Can any web dev point me in the right direction for these features?
wouldn't it be more effective for the customers and more profitable for Nintendo to make these games available on DVDs/cartridges for current systems?
Wii and Wii U had Virtual Console, which is what you describe except provided as a download rather than as physical media. The best guess for when Virtual Console will reach Nintendo Switch is 2018, when Nintendo plans to launch the Switch's online service.
How much would the ROM licenses for your Raspberry Pi solution run you? They wouldn't even be available for first-party games, which outnumber third-party games in this collection.
Nintendo should be manufacturing additional NES Classic units
And get sued out of existence for copyright infringement if the original deal with the third-party publishers specified a limited number of units. Or would you prefer a limited-functionality NES Classic with all third-party games cut out?
And controlling the padding with a CSS media query breakpoint based on viewport width doesn't help because a touch-operated iPad held in landscape orientation has more pixels than a trackpad-operated netbook.
@media
Could you be more specific as to which CSS media query expression you refer?
Apple allows only one browser engine on iOS and that engine is Webkit.
The other option is remote rendering, as used by Opera Mini. Microsoft could likewise run EdgeHTML in its huge Azure cloud and send the result of remote rendering to iOS devices.
It's unclear to which part of the article you are referring. I searched inside the document "I decided to disable AMP on my site" by Alex Kras for the words "touch" and "finger", and neither word was there. I searched for the word "link", and none of the results mentioned adapting link size based on whether the browser uses touch or mouse. Could you quote a sentence from the relevant portion?
We are talking about sites weighting several megabytes for the equivalent of a single blog post, with scripts creatively breaking browsers. With a 2.3MB / 66 object webpage, the author is definitively guilty of this.
Is 2.3 MB for a whole month's worth of blog posts, including several photos and/or CGI renderings, likewise too heavy? If so, what change would you recommend for a page like this one?
Please, for the love of God, look upon my 16 DIMM slots ye Mighty frugal HTTP server, and load the whole damn document all at once, SVP.
Even a PC with double digit GB of RAM can be connected to a satellite or cellular upstream connection whose ISP charges $5 to $10 per GB. Though a non-AMP page like this still loads fast because it's so simple, I imagine people aren't going to be happy to pay the ISP to load images that won't be viewed.
RAM is cheap
Unless you've already installed the largest RAM modules that your PC will take. I've seen new PCs for sale with no option to reconfigure for more RAM. For example, this product detail page for an Inspiron 11 3000 laptop mentions "2GB" but doesn't offer any choice to upgrade at build time nor state what sort of RAM slot it has.
Opera Mini renders HTML documents remotely in order to work around the Apple WebKit restriction. In addition, different wrappers for Apple WebKit can have different battery life characteristics, though I imagine the difference is negligible. Among Opera Mini rendering remotely, Safari wrapping Apple WebKit, Chrome wrapping Apple WebKit, and Firefox wrapping Apple WebKit, which of the four can browse for the longest on a single charge?
I would, but Firefox's "Find in page" (Ctrl+F) in a YouTube video page searches only the comments, not the video captions. What am I missing?