JakeQZ

Also others in the family: `IsEquivalentCss` and `StringContainsCssCount` and the assert methods that use them. Probably can be documented in the `class` or `trait` DocBlock for each.

Hi Kieran, Good find. I created a branch with some tests for the transparent content model (including `` and `` as well as `` for the transparent element, and a...

> libxml2 lacks HTML5 support (https://gitlab.gnome.org/GNOME/libxml2/-/issues/211) so it's more of a feature request than a bug. That's if this specific issue (and similar) stem from `libxml2` rather than `ext-dom`. I...

> I think there were a few other nuisances identified. I just [re-found some relating to optional tag omission](https://github.com/MyIntervals/emogrifier/blob/v5.0.1/tests/Unit/HtmlProcessor/AbstractHtmlProcessorTest.php#L154-L341). The "broken" comments in the test data providers refer to cases...

I'll look into the Facade design pattern and have a think... On the topic of `CssInliner` being too big, this was partly touched upon in #912. The suggestion there is...

I think it certainly makes sense as a first step to move the `DOMDocument` stuff out of `AbstractHtmlProcessor` and into a new class (say `HtmlDocument`), an instance of which would...

> Some kind of wrapper (or facade?) might involve the creation of the/each `HtmlDocument` from the raw HTML, running it through the processor, then obtaining the raw processed HTML with...

> To make the initial Emogrifier-provided class injectable as a service (and hence mockable in tests), the wrapper could provide an API like this: I think this wouldn't be mutually...

> If you wanted to fully decouple (OO), then what Jake suggested of using an interface would be the best way to go. To clarify, I was suggesting perhaps introducing...

We currently have methods `parseCssDeclarationsBlock` and `getAllNodesWithStyleAttribute` that are duplicated in `CssInliner` and `CssToAttributeConverter`, that could be moved to shared `trait`s. That is an overlapping issue, but not the same...