@-webkit-keyframes animationName not supported #886
Comments
|
Hi @janmyszkier, Thanks for reporting, and in particular for providing a test that fails. I can confirm that your test also fails with the latest Emogirifer version, 4.0.0. However, if I add I've also played around with adding some CSS before and after the Could you try your test with the 2.2.0 release but 'debug' set to In the medium-term, I think Emogrifier should handle the various 'unsupported' at-rules as it now does |
JakeQZ
added a commit
that referenced
this issue
Jun 14, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling containers, like `@supports`, more generally, in a similarly way to how `@media` is currently processed. (Addressing #544 first may also help.) Fixes #886.
JakeQZ
added a commit
that referenced
this issue
Jun 14, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similarly way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
JakeQZ
added a commit
that referenced
this issue
Jun 14, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similarly way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
|
@janmyszkier, FYI, this issue should be fixed by #899 which will preserve |
JakeQZ
added a commit
that referenced
this issue
Jun 14, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similar way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
JakeQZ
added a commit
that referenced
this issue
Jun 15, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similar way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
JakeQZ
added a commit
that referenced
this issue
Jun 15, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similar way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
JakeQZ
added a commit
that referenced
this issue
Jun 15, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similar way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
JakeQZ
added a commit
that referenced
this issue
Jun 15, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similar way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
oliverklee
pushed a commit
that referenced
this issue
Jun 15, 2020
All at-rules that have no special handling by Emogrifier will now by copied to a `<style>` element. Previously, Emogrifier would attempt to process them as regular CSS rules, causing an exception in `CssSelectorConverter::toXPath()`, which in 'debug' mode would be propagated; in either case they would be discarded. The rationale is that if any such rules are in the supplied CSS, they are desired in the resulting HTML. Emogrifier can treat them as a black box it knows nothing about, simply to be passed on. For at-rules which are containers for regular CSS rules (e.g. `@supports`), the ordering could be important. For now, these rules will be placed at the start of the `<style>` element, so it is possible that they will be overridden by other uninlinable rules that are placed after them, but were originally placed before. However, there should be no regression because, by being placed first (and in their own original order), they would still never override a rule in the `<style>` element that they would not have in the original CSS. The ordering improvement can be addressed separately, e.g. by handling container at-rules, like `@supports`, more generally, in a similar way to how `@media` rules are currently processed. (Addressing #544 first may also help.) Fixes #886.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
created a branch with a test that fails:
https://github.com/janmyszkier/emogrifier/tree/jan/2_2_0_css_animation_test
done based on 2.2.0 (which seems to be currently used by magento/magento2 repository):
https://github.com/magento/magento2/blob/2.3/composer.lock#L3670
please provide a fix or doc information on how to avoid this error with emogrifier, so we can alter our code. (mentioning the animation in the readme would also be helpful if not going to be supported)
The text was updated successfully, but these errors were encountered: