Open Krinkle opened 2 years ago
There is no such thing as a current fix. The linked issue was closed because WP switched to Unicode emojis, but perhaps they never actually did for feeds.
Hello, In the CustomCSS extension (see https://github.com/FreshRSS/Extensions ), you can add such a style as a workaround:
img[src^="https://s.w.org/images/core/emoji/"] {
height: 1em;
max-height: 1em;
}
P.S. Allowing custom classes and styles in the HTML we render and/or serve back is not trivial from a security and robustness point of view
@Alkarex What about security? Robustness is simple enough with a prefix.
P.S. Allowing custom classes and styles in the HTML we render and/or serve back is not trivial from a security and robustness point of view
I recognise this for the web client where the HTML is served from an authenticated origin (i.e. the user's FreshRSS server), however would it be possible to apply the class stripping only in the web rendering and not in the general feeds/APIs?
Robustness is simple enough with a prefix.
Ack. Potentially a prefix like freshrss-
or fr-
could be reserved for the web client's own styles, and allow any other classes to pass through unaltered. However, this is non-trivial currently given the use of Bootstrap CSS, which is well-known for its generic class names. And while those may be harmless from a security prespective (e.g. anything specific to FreshRSS or used by its JavaScript could use a prefixed class), they are also prone to unintended matching due to their generic nature.
I think it's fair to strip classes in the web client as a final step, knowing that no foreign CSS/JS is applied anyhow, and that any common styles are already accomodated for by the web client with its own stylesheets etc. However when the feed API is consumed by another feed reader, that contexts doesn't apply, and in particular the FreshRSS styles aren't applied, as the feed reader has its own way of doing this, and like FreshRSS, similarly expects access to the original content to process it accordingly with various sanitiziation steps and/or added CSS.
Ack. Potentially a prefix like freshrss- or fr- could be reserved for the web client's own styles, and allow any other classes to pass through unaltered. However, this is non-trivial currently given the use of Bootstrap CSS, which is well-known for its generic class names. And while those may be harmless from a security prespective (e.g. anything specific to FreshRSS or used by its JavaScript could use a prefixed class), they are also prone to unintended matching due to their generic nature.
That's a non-issue. You would however want to change class="flux_content"
to class="flux_content f_##"
. Keep in mind I'm talking from a CustomCSS perspective. There's nothing that can be done here generically.
By robustness I mean it always works exactly the way you expect it to work. I don't mean you don't have to do anything.
I think it's fair to strip classes in the web client as a final step
I think it's annoying to strip it. Prefix it and all is well.
think it's fair to strip classes in the web client as a final step, […].
I think it's annoying to strip it. Prefix it and all is well.
Ah, you mean to prefix the classes in the content (rather than adopt a prefix for the UI).
I hadn't considered that. I suppose the problem there might be that it is effectively the same as stripping, in that any downstream consumer of it will no longer recognise it. Not for workarounds like wp-smiley
, nor for any semantic use of classes (e.g. hCard and other such HTML/RDF microformats).
However, if limited to the web client's own rendering, then (from my POV) prefixing and stripping are equally fine. If prefixing is preferred, that'd work for me. So long as e.g. the greader API and responses such as from a=rss
pass-through the class attribute unchanged.
Maybe a whitelist of allowed classes could be acceptable.
My plan is to implemente in SimplePie a new function, that rename attributes, so that class
could be renamed to data-class
and tags like noscript
to data-tag
. Than you can work with it in customCSS without a risk.
For the class
, I made a first solution, see #4175
Related article: https://danq.me/2023/09/04/wordpress-stop-emoji-images/
Related article: https://danq.me/2023/09/04/wordpress-stop-emoji-images/
strange. I cannot reproduce it.
It is UTF8 and not an image
strange. I cannot reproduce it.
If I am not mistaken, the article is precisely about how Dan fixed it (server side)
ah ok. Dan fixed it in Wordpress and not in FreshRSS.
Describe the bug
To Reproduce Steps to reproduce the behavior:
Expected behavior Native emoji, or otherwise an appropiately-sized image.
Screenshots
Environment:
Additional context
max-height
to workaround Gmail removing "height" styles, https://github.com/WordPress/WordPress/commit/3b863ae17371ba0f6e3395876ac1e4aafacc88b3.height
andmax-height
to workaround NewsBlur removing styles other than "width" and "height", https://github.com/WordPress/WordPress/commit/bfb999054836c6a409ca3c027af4223342ca2234..wp-smiley
height/min-height to stylesheet, to workaround the fact that WordPress uses inline styles instead of normal with/height attributes, and inline styles are stripped by NetNewsWire. https://github.com/Ranchero-Software/NetNewsWire/issues/1263.img.wp-smiley[alt]
selector matching. https://github.com/Ranchero-Software/NetNewsWire/issues/2868, https://github.com/Ranchero-Software/NetNewsWire/pull/2872/files.It seems FreshRSS strips the
class
attributes and all inline styles, and does so not just in its web client, but also in the content served through the API for other clients that have their own formatting. Although having said that, the first screenshot shows that this appears to be an issue in the default web client as well, which suggests the current fix has also stopped working.Finally, I note that the example WordPress post in question, is serving native emojis from the served HTML:
However, the RSS feed at https://make.wordpress.org/core/feed/ serves an image instead, which suggests upstream WordPress is either applying the img transform only to the feed and/or applying a native re-transform to the theme rendering only.