Because it breaks Adblock users, as stated in the thread.
-
-
Replying to @pcwalton
Blocking crucial scripts is a bug in the AdBlock software. Happens every so often and quickly gets fixed by them. Ad blocking on AMP pages works perfectly fine without AMP specific rules. However, there is an option to SSR custom element initialization to avoid the CSS blocking.
1 reply 0 retweets 2 likes -
Replying to @cramforce
If AMP doesn’t work with Adblock, that’s a bug in AMP, not Adblock.
2 replies 0 retweets 3 likes -
Replying to @pcwalton
Nope, if AdBlock accidentally blocked a react or jQuery CDN lots of pages would break and the AdBlock would need to be fixed. Sorry, but your bias confused your perception of the problem here. Just an easily fixed bug in the AdBlock list. Hast happened about 3x in 3 years.
1 reply 0 retweets 4 likes -
Replying to @cramforce
I respectfully disagree that forcing sites that did not have points of failure before to add more potential points of failure is an improvement.
1 reply 0 retweets 4 likes -
Replying to @pcwalton
These are websites that have a primary JavaScript library. They expect that JavaScript library to load. If it doesn’t load, there is graceful degradation (the 8s timeout could be argued about in 2019). You can avoid this for your AMP site by installinghttps://www.npmjs.com/package/amp-toolbox-optimizer …
2 replies 0 retweets 0 likes -
Replying to @cramforce @pcwalton
8s is an awful lot for supposedly light websites. And one of the use cases they mention is uMatrix blocking all 3rd party scripts by default. This isn’t something to fix in a config.
1 reply 0 retweets 0 likes -
Feel free to file a GH issue to reduce the timeout. I'd be supportive. Also, I'd suggest filing an issue with your browser to trigger noscript tags in this case. AMP has a noscript tag that renders instantly for folks who have JS turned off instead of blocking at network layer.
1 reply 0 retweets 1 like -
Maybe what we need is <noscript for="scriptId"> so that noscript can fire for partial blocking and spec it to also fire on non-200 response codes in that case. Would be neat to innovate on noscript in 2019
@pcwalton do you think that is something Firefox would ship?1 reply 1 retweet 2 likes -
Replying to @cramforce @m_gol
I don’t have any objections personally but it’s more of a question for
@bz_moz and@annevk and other people who are more standards involved1 reply 0 retweets 1 like
Noscript doesn't "trigger". It gets parsed differently depending on whether script is enabled. Doing <noscript for="scriptid"> would require blocking the parser at that point until we know whether that script would run, no?
-
-
Replying to @really_bz @bz_moz and
Oh, didn’t realize. Yeah, that’s a nonstarter then.
1 reply 0 retweets 0 likes -
I think the core idea is "declarative script fallback". It doesn't have to be based on noscript parsing semantics. E.g. could be parsed like a template tag and materialized to real DOM when needed.
1 reply 0 retweets 0 likes - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.