View Single Post
Old 01-15-2021, 03:42 PM   #79
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 9,403
Karma: 6686152
Join Date: Nov 2009
Device: many
Okay as of today's master in Sigil/src/Query:

- added a way to catch exceptions and report parser errors in the resulting CSelection so it can be checked by the caller (so hopefully no more aborts or segfaults)

- fixed a bug in the *of-type related selectors

- added support for :root pseudo selector

- added support for :lang() which properly groks inheritance rules.

- filtered out psuedoelements that do not actually help select a node or that require user intervention like :hover, :before, :after, etc

So hopefully Query is now in a much better place than it started.

It passes all my basic tests now but I am going to create a standalone testing app to stress test my version of gumbo query and remove the simple testing added to main.cpp in Sigil.

That will probably take a while but should prove useful in finding bugs and query limitations.

I have added @supports and fixed a few bugs in cssparser2 and qcssparser. If anyone wants me to post these improved versions, just let me know.



Quote:
Originally Posted by wrCisco View Post
I played a little with the Sigil/gumbo-query integration. Seems nice, but I got it to crash with a number of selectors:
Code:
p:nth-of-type(2n-1)
p:lang(it)
p.flush::first-letter
p:focus
I thought it could have a problem with pseudo classes with function-like syntax as
Code:
nth-of-type(2n-1)
but then I tried
Code:
:not(.someclass)
and not only it didn't cause a crash, but it also correctly found a match.
(and since ::first-letter and :focus will never match anything, it will be mostly a problem for the css parser to filter them out).

At the same time, just for the sake of it, I started experimenting with integrating the cssRemoveUnusedSelectors plugin in the Sigil reports tool. I succeeded in report back to the "CSS Classes" widget in the Reports dialog all the usages of the selectors (with the complete list of the number of matches per html file).
I'm not sure how best to proceed about the deletion functionality: I thought maybe keeping around the parsed css rules as PyObjectPtr when the selector usages are reported, and then passing it back to python to perform the deletion, would be a good approach (but how could I pass a PyObjectPtr to a python function through the embeddedpython::runInPython interface?). Or maybe it might be better to execute twice the parsing of the stylesheets - once for the reporting and once for the deletion - and to pass back and forth only the indices of the enumerated rules and selectors?
KevinH is offline   Reply With Quote