I just took another look and it seems that it’s not fixable for me. The content replacement relies on a certain point where the <head> is already generated. Thus, there is no proper way for me to add my styling there afterwards (except with some hacky manual replacements).
I changed the way the CSS is loaded so that, at least, there is only one single error per page instead of potentially multiple ones. But that’s the best I can do for now.
@kittmedia, thank you so much for trying. Good call, avoiding hacky manual replacements, that would likely break down the road.
I have one more trick up my sleeves. My caching plugin offers to combine inline CSS in a separate file. That usually gets the job done, although I have to look out for specificity issues when doing that. WordPress itself also outputs styling as a child to a div, so that needs to be taken care of anyway – if validation is important to the project. I’ll go that route, when it makes sense. Thank you for your time, and this fine plugin. I look forward to trying it out in a real project.
The main issue here is to add <style> elements in the body instead of style= attributes. Yes, having style attributes is not a good practice, but having a style definition just for one single individual element is not really helpful either, since the idea of good CSS classes is to have reusable classes in a cacheable resource and not just one single CSS rule in the body element to address one single element in the body element. Element specific inline styles are totally valid and WordPress does not enforce any CSP (in fact many WordPress sites would not work at all with any CSP in place), so why not using them? The performance should not be an issue here since having individual CSS classes for every single element may creates even more load since the browser has not only to apply a style but also first look it up as it can not be cached as part of the document.
At the moment I use forked version on my own website to avoid invalid HTML, but maybe you consider inline styles for a future update.
This reply was modified 2 years, 1 month ago by Arno Welzel.
… to basic inline styling of the overlay element (which already has some inline styling)
div class="embed-privacy-container is-disabled embed-youtube" data-embed-id="oembed_36845b8980c102d79722c9f19a826ce1" data-embed-provider="youtube" style="background-image:url(https://example.net/uploads/embed-privacy/thumbnails/youtube-3GuUuHLg9t8-maxresdefault.jpg);">
… in this case, moving the aspect ratio to the div inline styling.
That isn’t a lot of styling that potentially would be duplicated if moved to inline styling. Also, the aspect ratio and YouTube logo? These are probably not changing on a page per page basis. Wouldn’t we be able to set these in an external (cacheable) stylesheet, if the Embed Privacy <style> element was disabled? With a filter, maybe?
Yes, I add all styles inline. But as explained, I don’t see any major difference between inline style elements or inline styles inside the element it is meant for.
This reply was modified 2 years, 1 month ago by Arno Welzel.
There is just a box with parts of the video thumbnail and static text arranged in a strange way without any link to click on it. I’ll try to capture this as screenshot.
Managing embeds, changing status to draft, no longer removes reg exp (different ticket) ✅
WordPress.tv thumbnails has been added. ✅
Looks good to me!
Next, I’ll test Spotify embeds on a different site, and embeds on my personal blog, a third site with PolyLang and privacy policies in different languages – that might trigger some quirks.
Here’s an example from a draft post with some Spotify embeds. And yes, a bit of custom CSS was used to make the background color of the overlay, match the background color of the related podcast, and reduce the height a little to eliminate layout shifts once the embed is loaded.
Also tested with W3C’s HTML validator, with no errors 🥳
@kittmedia The problem I encountered with https://github.com/epiphyt/embed-privacy/tree/dev is the fact, that it is missing minified resources when WordPress is not running with debuggin enabled. I just did not expect this, sorry. After copying over the minified scripts and styles from the official version it also looks OK here too. However I must admin, using an output buffer to inject the styles to the head element feels somewhat weird.
“… it is missing minified resources when WordPress is not running with debuggin enabled.”
Should be: “it is missing minified resources”. Even when WordPress debugging is enabled, the plugin enqueues minified resources. Maybe it is a good idea to use the unminified resources when debugging is enabled, similar to this:
