Blocking=render: Why would you do that?
csswizardry.com
Blocking=render: Why would you do that?
1–10 of 20 posts
Re: Blocking=render: Why would you do that?
#2The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to overwrite the page without it flickering/being blatantly obvious to the user.
Re: Blocking=render: Why would you do that?
#3The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to overwrite the page without it flickering/being blatantly obvious to the user.
Honestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.
Re: Blocking=render: Why would you do that?
#4[deleted]
Re: Blocking=render: Why would you do that?
#5The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to overwrite the page without it flickering/being blatantly obvious to the user.
Honestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.
But sorting all the paragraphs in alphabetical order increased reader engagement metrics! How would I ever have discovered readers wanted that without A/B testing?
Re: Blocking=render: Why would you do that?
#6Could this be used to prevent me from clicking on or tapping the wrong thing because new items keep appearing causing a reflow just as I jab? I would really appreciate it if pages would render after they have made up their mind.
Re: Blocking=render: Why would you do that?
#7The A/B testing use case is probably the one good one there, at least if you can't serve the variations on the server side. So many issues come from trying to overwrite the page without it flickering/being blatantly obvious to the user.
Honestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.
Ideally it should be on the server side, so you're right there. Client side A/B testing isn't the best way to handle things.
However, it's sometimes a necessary evil due to:
1. The original company not budgeting time/effort from their existing dev teams to work on A/B testing, and wanting to outsource it instead.
2. Said company and their tech department being nervous about letting outsiders actually access the source code for their site/app.
3. Or said company wanting the analytics/features that VWO/Target/Optimisely/whatever offer, and not wanting to have code up the same analytics toolbox themself.
Re: Blocking=render: Why would you do that?
#8Could this be used to prevent me from clicking on or tapping the wrong thing because new items keep appearing causing a reflow just as I jab? I would really appreciate it if pages would render after they have made up their mind.
Yes! Perfect scenario. This is a question of a slower but more trustable experience. I would always fight for both, however.
Re: Blocking=render: Why would you do that?
#9Earlier quoted context omitted.
Honestly, I should add the point that client-side A/B testing is the devil and should be avoided in the first place.
Ideally it should be on the server side, so you're right there. Client side A/B testing isn't the best way to handle things. However, it's sometimes a necessary evil due to: 1. The original company not budgeting time/effort from their existing dev teams to work on A/B testing, and wanting to outsource it instead. 2. Said company and their tech department being nervous about letting outsiders actually access the sourc…
All three of your points are correct, so please don’t resent my response: Client-side A/B testing exists because ‘we should be able to do this without a deploy’. And they’re right.
Re: Blocking=render: Why would you do that?
#10Could this be used to prevent me from clicking on or tapping the wrong thing because new items keep appearing causing a reflow just as I jab? I would really appreciate it if pages would render after they have made up their mind.
… No, because the cause of this tends to be content loaded dynamically (i.e., not part of the original HTML) or content not handled by this spec (e.g., img without dimensions known in advance).
On the other hand, there is no real reason for a web app to have jumping content as is - it’s just a bug in said app.