Supporting CSS selectors

[fivefilters]

Hi all,

We're considering creating a new repository for these site-specific selectors to use CSS selectors, with XPath as an option if CSS selectors are not expressive enough. I wanted to get your thoughts on such a move.

The mains reasons are:

1. CSS selectors are more concise and more people are familiar with them than XPath selectors

• For contains() applied to text content (second to last line in the image above), which the CSS spec does not support, we can use CSS to XPath convertors like Symfony's CSS select which has support for it.
• For more complicated selectors, we'd probably still want to allow XPath expressions to be entered somehow, but I assume this would not be used so much.

2. PHP 8.4+ has native CSS selector support, so for most selectors, converting to XPath is not necessary.

The reason we're thinking of doing this in a new repo is so any code dependent on this repo can continue to function. And any new applications can use the new repo if they want. I'm thinking we may even be able to create a regular one-way sync if need be, from new repo to old, if there are no conflicts, as CSS to XPath isn't so difficult.

If anyone has any thoughts or suggestions, please do share. @j0k3r @HolgerAusB @Kdecherf

[HolgerAusB]

Interesting. I knew your css examples 1, 2 and 4 (as learned from Feed Creator). But I also never heard about XPath before I started to use FulltextRSS four years ago. CSS selectors could help, that more people are able to write site-configs.

I think self-hosters should be able to select a priority between the repos. Standard could be:

• custom configs (written for the owners server only)
• ftr-site-config-v2 (I suggest this name for the new css selector based repo)
• ftr-site-config (the current repo)

of course, wallabag should also be able to use CSS selectors soon and should also use multiple config folders.

Maybe we should consider a new filename-extension for the new configs? How about *.ftr2

As I proposed some time ago for fingerprinted site-configs, I'd now like to extend this suggestion:
include_conf: folder/filename
So we can have a custom/example.com.ftr2 which contains some personal paywall cookies and then only a junction to include_conf: standard-v2/example.com.ftr2 or to include_conf: standard-v1/example.com.txt

[fivefilters]

Thanks @HolgerAusB. My thinking behind maintaining the current one was really as a legacy repo for older self-hosted instances.

If we start adding CSS selectors here, old software reading it wouldn't understand it. But CSS to XPath conversion is easier than the other way round, so we could have new selectors be CSS in a new repo or branch (i.e. v2) and still keep these XPath selectors updated via automatic translation of any new CSS selectors, possibly via GitHub action triggers.

So my proposal with a new repo or branch would be for it to be self contained, ie. no need to have knowledge of earlier v1 site config files.

But I don't know if the wallabag devs would want to transition to CSS selectors or not. Would it end up being a case of maintaining two potentially diverging repos of site config files for similar use?

[fivefilters]

Another thing we'd like to change with the new repo, which I know has been discussed in the past, is the way we match host names to the site config files.

In Full-Text RSS, to have the same set of rules match www.example.com and category.example.com, you need two site config files: example.com.txt and .example.com.txt. (example.com.txt only matches the apex domain and the www subdomain).

We'd like to simplify this so it's closer to how cookie domain matching works. E.g. example.com.txt would match example.com, www.example.com, category.example.com, a.b.example.com.

[HolgerAusB]

This is also nice, @fivefilters. I assume that you have in mind to keep the prioritization?

highest to lowest prio:

my.subdomain.example.com.txt
  .subdomain.example.com.txt
   subdomain.example.com.txt
            .example.com.txt
             example.com.txt

So the first one matching, wins.