Maybe it's time to change CFI syntax to support CSS Selector?

Hi folks

This week POC 
to select a random string in web browser bring me back to one question 

"Can we change CFI spec a bit to support CSS Selector"?

As a reading system programmer the most difficult part to implement CFI 
for highlight are:
1. need to go through all element to identify element for CFI such as 


2. when we have this CFI generated for highlight then it's still 
difficult to go through DOM to locate this element when rendering highlight.

I went through CSS selector again as well it is possible to use CSS 
selector to locate every element (for example implementation like this

And actually I remember when someone had brought up CFI to CSS WG and 
Web browser vendor a few years ago mostly two questions raised from them:

1. why don't use CSS selector

2. should avoid inventing new way attaching to URI such as following


The rest of CFI I think are very useful by defining charOffset of each 
text node and the node index of the target node which are not covered by 
CSS Selector (you might want to ask - can we ask CSS Selector to support 
selecting charOffset? I am not sure since CSS Selector seems only select 
element ( ).

So I wonder, maybe we still can find a unified way to define annotation 
but with slightly changed CFI.

In the POC I tried format like

?startSelector=<CSS Selector>:<node index>:<charOffset>&endSelector=<CSS 
Selector>:<node index>:<charOffset>

But if make it more closer to "CFI" we might have something like this? 
So even if web browser might not support it natively but as long as epub 
could support then we can have something unified that end user could 
share highlight in the same book but different reading app.

?epubcfi=<CSS Selector>:<node index>:<charOffset>,<CSS Selector>:<node 

And this format can satisfy "path-relative-scheme-less-URL string 


Zheng Xu

Chief Executive Officer
Gardenia Corp

Received on Thursday, 17 February 2022 02:37:30 UTC