Quote:
Originally Posted by geek1011
The only thing is I'm not going to make a feature to put the css back. For that, you'll need to make a patch and apply that instead.
|
Is there something I'm not understanding ?
Let me outline my own problem with the current pipcat-plus-makepatch method which adds an unreadable, untweakable blackbox hexcode patch to GeoffR's nickel.patch file.
A hypothetical new patch...
I make a patch to a CSS stream which changes the GUI booklist Title to the Avenir font in bold and not italic. It will probably require me to also change the font-size. I use makepatch and publish it.
Everybody loves it (
I did say this was hypothetical) or rather the idea of it, except
... I'd like to use Bookerly, not bold, at a different font-size
... no, I like the new bold but I preferred the old Georgia
... no, I want Bookerly italic
... etc etc
How many makepatch's do I need to create to make everyone happy?
What is desirable for a new approach to patching zlib CSS would be the ability to patch a zlib in the same way that the nozlib `Custom reading footer style` patch allows, i.e. the user can tweak one or more variables all for the same CSS stream.
Other opinions are also available...