Problem/Motivation
When big-pipe placeholders occur inside elements that don't allow block level elements, browsers split up the parent element.
For example:
<p>Hi <div></div>, ...</p>
Is splitted into:
<p>Hi </p>{placeholder result}<p>, ...</p>
Proposed resolution
Use <span> instead of <div> for big-pipe placeholders
Remaining tasks
None.
User interface changes
None.
API changes
None. Only an internal functionality change: <span> elements are used instead of <div> for BigPipe placeholders.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 2802923-21-8.3.x.patch | 17.34 KB | wim leers |
| #21 | 2802923-21-8.2.x.patch | 17.01 KB | wim leers |
| #21 | 2802923-21-test-only.patch | 3.26 KB | wim leers |
Comments
Comment #2
casey commentedComment #3
wim leersHm… I think this actually makes sense. I'm tentatively +1 :) Great catch, and nice patch — thank you very much!
However, this should have test coverage to ensure we don't ever change this back again, and to ensure this behavior continues to work correctly.
Comment #4
ndobromirov commentedA bit off-topic, but somehow relevant...
Isn't there too much repetitions of the markup for the placeholders?
It's not something that is going to change every day, but 2 utilities will not hinder performance that much?
bigPipePlaceholder($value)
bigPipePlaceholderNoJs($value)
Or one:
bigPipePlaceholder($value, [$js = FALSE])
Comment #5
wim leers@ndobromirov I have no idea what you mean. Please create a new issue.
Comment #6
fabianx commentedYeah, using a non-block level element makes definitely sense.
And if someone needs the old behavior, they can still target the bigpipe placeholders via the data- argument in CSS and use display: block;
So that is fine with me.
Comment #7
wim leersAlright, both maintainers (Fabianx and I) are +1. Now we just need JS tests.
This will also have to go into 8.2, not 8.1 (because no more releases there).
Comment #8
wim leersComment #9
wim leersNote that even if we fix this, #2738685: BigPipe leaves wrapper <div>s in place, because AJAX system leaves them — this can cause some CSS to break will unfortunately still cause wrapper
<div>s to be added, due to #736066: ajax.js insert command sometimes wraps content in a div, potentially producing invalid HTML and other bugs. But that doesn't mean we should not do this!Comment #10
wim leersNow testing #2 against 8.3.x.
Comment #11
wim leersFirst, a straight reroll. Needed significant rebasing.
Comment #13
wim leersI started writing test coverage. And in doing so, I started wondering: how can you even get placeholders inside text? You can't do that with Drupal core by default I think.
Look at the test coverage, I have to do fairly strange things in order to do this.
The test-only patch is also the interdiff.
Comment #16
wim leersNow that #2828559: UpdatePathTestBase tests randomly failing is fixed, retesting.
Comment #17
wim leers#13 needed a rebase apparently. So, here's a straight reroll. No changes.
Comment #18
wim leersComment #21
wim leersUgh, this needs a separate 8.2.x patch now, because 8.2.x and 8.3.x have diverged slightly due to #2835758: Remove BigPipeInterface and move all of its docs to the implementation + #2569119: Use Crypt::hashBase64(), not hash('crc32b') or sha1 for placeholder tokens. So, rolling separate patches.
<div>which should now become a<span>.Comment #23
wim leersThere we are at last :)
Assigning to @Fabianx for review, and hopefully RTBC.
Comment #25
fabianx commentedRTBC - looks great to me! :)
Comment #26
catchCommitted/pushed to 8.4.x and cherry-picked to 8.3.x. Thanks!
Comment #29
wim leersThanks, Fabianx & catch!
Comment #30
wim leersComment #31
cilefen commentedIs there a change record?
Comment #32
wim leersThere's no need for a change record. IS updated to reflect that.