This CSS animation is just the backup in case the javascript doesn't load at all, really. After 8 seconds, the page gives up trying to prevent the flash of unstyled content and just renders, regardless of how bad the styling is. It also includes a <noscript> block that renders the page immediately if javascript is disabled. The 8s thing is for network issues. Graceful degradation.
Lots of documents (amp or not) use the same "hide the screen until layout is done" trick to avoid multiple relayouts as the initial javascript is running and CSS is being fetched. More often than ideal, they don't have a fallback if the javascript doesn't load at all. AMP mandates it with this CSS animation, which is far better than nothing.
Also when served from the AMP Cache (https://www-ehow-co-uk.cdn.ampproject.org/c/s/www.ehow.co.uk... for the example shown), the layout algorithm that javascript runs is applied by the AMP Cache instead and the 8-second timeout code is removed completely (view source and take a look). This doesn't work on all pages - there are some features that require a client-side context, but it does work on this one. Websites can run the same server-side layout algorithm on their origin using a node library (https://www.npmjs.com/package/amp-toolbox-optimizer). There is also work being done to improve all of this (server side layout on more documents, and making the system easier to run on your own site).
The 3s observation from the original post is interesting. It may just have been an estimation of the 8s, or it could have something to do with how the document is configured. Looking at this document, there are some <amp-font> tags that the document author has added with a 3000ms timeout. These are tags that instruct the AMP javascript to change the document CSS class depending on the success of failure of loading of a particular font. By default (not amp specific), if a document loads a webfont for a particular text, the browser will not display the text until the font is loaded. <amp-font> provides a CSS hook by which the author can do stuff like "hide the text for up to 3s, or when the font has loaded, whichever comes first". This page has some <amp-font> tags with a 3s timeout referencing fonts that have not been added to the document, which seems like a mistake from the document author, unsure. I was not able to reproduce the 3s experience though, so this may be incorrect speculation as to what happened.
> The 8s thing is for network issues. Graceful degradation.
A mandatory 8s lag for a careful users doesn't sound graceful to me :-/
For HNers who weren't creating web back in 2009: we used to have another term as well, "progressive enhancement" that meant more or less "after we got a baseline working on all supported browsers we can add nifty stuff that doesn't work in IE.
Graceful degradation is often handled by changing timing on expected results. Timing is often a useful unconstrained "fudge factor" for such things. And since disabling non-standardized intermediaries mucking about in your browser's w3c-compliant behavior is a solution, I doubt Amp will change to address this failure mode.
> Lots of documents (amp or not) use the same ... trick
Perhaps luck, but I have never encountered one that is so hostile about it with nearly 10s wait outside of AMP. I've rarely encountered a second or so's delay, but two or three sites including a large one that have the massively excessive AMP delay.
So to call it the same trick seems like a stretch from a user annoyance point of view.
Sometimes it's that simple, often it's not. There's still plenty of sites available without such hassles so it's not yet a problem finding alternatives.
On the other hand an ad blocking user is not necessarily producing no value for the site. I've had subs to newspaper sites, all of which I viewed with blocking on, and Independent will never now be one of them. If Guardian did likewise, and added AMP, I'd cancel my current sub and look elsewhere, which would be a definite loss of value for them.
I'm not so wedded to the views of any one outlet that I'd subscribe with this in place, or turn off blocking to subscribe, or feel I must subscribe to the same one indefinitely.
If it's a site I wouldn't have considered a sub or donation to, you're right, nothing is lost.
This sort of assumes that (a) the only possible system is surveillance capitalism (I have no problem unblocking advertisers on sites which don't track me e.g. DuckDuckGo, I also have no problem paying for things directly -- in fact, I prefer it); and (b) that this is the sole reason for using something like µMatrix which blocks _everything_, not just ads.
Accessibility is about much more than screen readers. If a user experiences problems accessing your site, that’s an accessibility problem, no matter what physical attributes that person possesses.
It seems you've been misinformed by the current generation of web designers. Accessibility is actually limited to people with disabilities, though a few people have started to use it interchangeably with usability. [0]
I agree with the spirit of your message though, but that's not what the grandparent post claimed.
> Accessibility is the design of products, devices, services, or environments for people with disabilities.[1] The concept of accessible design and practice of accessible development ensures both "direct access" (i.e. unassisted) and "indirect access" meaning compatibility with a person's assistive technology[2] (for example, computer screen readers).
There is more to accessibly than screen reader compatibility. (I want to emphasize this point, not because I think you said anything to contradict that but because I think that is a point lacking from the conversation in this thread)
For example, I'm autistic and use a "normal" browsers, but garish websites (for example those displaying animated ads) are less accessible to me, because those lead me to becoming overstimulated, making me less likely to absorb and remember information presented on the page as well as being physically and mentally exhausting.
I am perfectly willing to pay for content (and am, through Spotify, Netflix and Patreon), but much of the web is actively hostile to many disabled people. My physical disabilities don't prevent me from using my computer in the standard way but every time I misplace my mouse and try to navigate the web solely using keyboard (which isn't that far from how I usually use my computer, so it's not like I don't know the shortcuts) I am reminded how it must be for people who are unable to use a mouse and have to rely on other input methods. Many websites couldn't have worse UI when it comes to accessibility if they tried.
There's a wide spectrum of accessibility between "content as created by the designer" and screen readers. People with a vision impairment who do not require a screen reader can use the browser's built-in magnifying/zooming capability to make a site usable for them, but only if the content is visible.
Lots of documents (amp or not) use the same "hide the screen until layout is done" trick to avoid multiple relayouts as the initial javascript is running and CSS is being fetched. More often than ideal, they don't have a fallback if the javascript doesn't load at all. AMP mandates it with this CSS animation, which is far better than nothing.
Also when served from the AMP Cache (https://www-ehow-co-uk.cdn.ampproject.org/c/s/www.ehow.co.uk... for the example shown), the layout algorithm that javascript runs is applied by the AMP Cache instead and the 8-second timeout code is removed completely (view source and take a look). This doesn't work on all pages - there are some features that require a client-side context, but it does work on this one. Websites can run the same server-side layout algorithm on their origin using a node library (https://www.npmjs.com/package/amp-toolbox-optimizer). There is also work being done to improve all of this (server side layout on more documents, and making the system easier to run on your own site).
The 3s observation from the original post is interesting. It may just have been an estimation of the 8s, or it could have something to do with how the document is configured. Looking at this document, there are some <amp-font> tags that the document author has added with a 3000ms timeout. These are tags that instruct the AMP javascript to change the document CSS class depending on the success of failure of loading of a particular font. By default (not amp specific), if a document loads a webfont for a particular text, the browser will not display the text until the font is loaded. <amp-font> provides a CSS hook by which the author can do stuff like "hide the text for up to 3s, or when the font has loaded, whichever comes first". This page has some <amp-font> tags with a 3s timeout referencing fonts that have not been added to the document, which seems like a mistake from the document author, unsure. I was not able to reproduce the 3s experience though, so this may be incorrect speculation as to what happened.