JakeQZ

> I ... am out of ideas right now. `implementsLogger` might be one such test.

> All classes should use the same logger instance when a document is parsed ... For this, we need a class that gets the original logger instance and then passes...

> 2\. add the non-null logger Should we be providing a non-null logger in the release package? Shouldn't users be providing a logger of their choice (from a library)? For...

> I think packaging the `NullLogger` should be enough. We can use our non-null logger in the tests (and move it the the testing namespace/folder, e.g., some `Fixtures` folder). Agree....

@sabberworm, does what we're saying seem reasonable approach-wise? (Not asking for specific code changes review at this stage, but if you spot a flaw in the plan, that would be...

I see this could be a useful option. The `!important` is removed from inline styles because it is assumed all other rules have been applied inline, and therefore it is...

That said, if Windows 10 Mail uses additional CSS with `!important`, could you not supply some additional CSS to beat it, with higher specificity and also `!important`, or is it...

I'm not so sure. The referenced documents are not an object model, but a syntax. Current class hierarchy seems to fit. At least for me. But, yes, please review.

Actually, I think there are some misnomers. E.g. the current `Rule\Rule` class should be a `Declaration` or `CssDeclaration` in some namespace ([ref](https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/CSS_Declaration)). And the `Rule` and `Property` namespaces seem to...

For reference, one instance is in `DeclarationBlock::parse()`, and was spotted during review of #972.