cramforce

Here the definition is actually broader than FOUC just for the font part. It can cause rendering without any CSS

Do not use this, use Google Fonts, just self-host them. This site claims better privacy, but does so using the wrong solution since you still have to trust them.

Self host (supported by Google Fonts but not by this service): - Better privacy - Better performance (no extra DNS lookups, TLS connection)

Their default embed code is a CSS @import directive. These must never be used in production code (It's fine as a directive for the compiler for local files but not with remote URLs). Leads to FOUC and FOIT.

Also, next step in amateur hour: They serve their CSS and fonts on the same domain as their marketing website. Cookies galore.

That article literally refers to it as poverty line as well a bit further down. "Poverty line" isn't a thing, thing. It'll always require some math to localize.

For a family of 4 in San Francisco (which has lower cost of living than Berkeley) the poverty line was $117K in 2019.

FontFaceObserver linked in the blog post is what you want. Also for general usability reasons. The standard API is quite difficult to use.

The proposed solution is a web standard change that doesn't require JavaScript.

For legacy reasons the location object is special (you can write to it which is a proxy to writing to `location.href`). Some details here https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

This is actually quite difficult to protect against while keeping functionality intact (not granting allow-scripts to iframes would do it, but also obviously disable JavaScript).

The emerging https://github.com/dtapuska/documentaccess standard would be a defense-in-depth against this attack.

I know this isn't a satisfying answer, but tools like design docs or any $SoftwareDevelopmentMethodology do not help fix broken corporate governance.

Concretely here, I'd try to make solving my problem the other team's goal. E.g. by inviting them to a summit during planning season and agree on common OKRs.

Author here. Let me know if you have questions or feedback.

Lighthouse is a lab-metric system while Web Vitals is a "real-user-metric" system. Both approaches are valid, and have their pros and cons.

Generally, lab metrics are convenient because you can run them whenever you'd like including before deploying to prod. But they can never tell you the ground-truth of what is really happening out there that real-user-metrics provide.

E.g. the FID metrics only make sense when someone actually interacts with your site. Lighthouse cannot know when people would interact and thus cannot calculate the metric.

No, they can be created on the fly. That basically makes it a TLS signing Oracle.

The MITM can be avoided by using Signed Exchanges. https://developers.google.com/web/updates/2018/11/signed-exc...

There is a new metric for that, too! https://web.dev/layout-instability-api

Signed Exchanges are basically that but with cryptographic guarantee of no transform by caches. See https://github.com/WICG/webpackage/blob/master/explainer.md

[Working on AMP at Google]

AMP for email in GMail can be turned off and is off-by-default if image-loading is turned off.

See my other comments on this. This is very much possible by design.

That email would probably otherwise just contain a link. It really doesn't make a difference.

Clients can (and do) use trust scoring to activate AMP in emails. Right now they use the same model that would allow loading images by default.

Because we do the majority of the work. The governance body size will, however, expand with further non-Google members. So, the hypothetical "you just have to convince only one" is becoming less of an issue over time.

Yes, but you know, that isn't Google controlling it and these are all member from major internet companies that won't take part in such a "conspiracy".

Nah, it would typically include all info known at send time, but it can see if there is updated data on email open time.

E.g. when you open a notification email from GitHub, the email can tell you that since it was sent, there are now additional comments to consider.

Yahoo is a BIG email client.

The TSC requires majority consensus. Google does not have a majority.

One important clarification since the question comes up often. AMP for email doesn't make emails inherently mutable.

Emails already support updating by including external image references inside the email. Allowing this is a choice of the client.

AMP for email makes JSON requests proxied by the email client. Your client can decide to only make these requests once and then keep them stable or to show you a version history of the state of your email upon every time you opened it.

Emails already support updating by including external image references inside the email.

AMP for email makes json requests proxied by the email client. Your client can decide to only make these requests once and then keep them stable or to show you a version history of the state of your email upon every time you opened it.

AMP including AMP for email is governed by a multi-company Technical Steering Committee as well as Advisory Committee since last year. https://blog.amp.dev/2019/03/06/encouraging-more-voices-in-a...

AMP for email has support by Outlook, Yahoo, and Mail.ru, so it very much isn't under Google's control.

They can use a different TLD. One big benefit is that the literal TLD is in the list (not every domain) keeping the size of the list O(1) instead of O(n) as it is for other TLDs.

Has it been figured out which adblock list accidentally blocked AMP? We'd like to contact them.

This is clearly a bug, since blocking AMP is not related to blocking ads (all the normal ad blocking rules should do the job just fine).

Counter anecdote: As a Google engineer it always seemed like Edge implemented the sparsest possible version of the web platform to make major Google products work–and literally nothing else. That works to launch the browser, but then basically any product change runs a chance to no longer fall into that sparse subset and break in a browser. If Edge had implemented a more robust set of features, it would have massively improved compatibility down the road.

Ranking based on speed was launched this July https://webmasters.googleblog.com/2018/01/using-page-speed-i...

There is a lot of movement in that direction. This was the start https://www.ampproject.org/latest/blog/standardizing-lessons...

For that aspect see https://www.ampproject.org/latest/blog/standardizing-lessons...