tools recompose-epub should isolate CSS in each file

See this groups thread.

recompose-epub needs to isolate the CSS for each included file, otherwise a broad selector could stomp on the properties of a selector in a different file. For example, selecting img in local.css could override the titlepage image in se.css. See The Sound and the Fury, The Case of Charles Dexter Ward.

Proposed solution:

Walk each XHTML file
Walk each included CSS file in the XHML file
Walk each selector in the CSS file and add a class to any body > section, body > article elements that is named after the file, like local-css, and update the selector to prefix it with that class, like .local-css
Then, continue compiling the single-page view as usual.

For example, this input:

local.css:

        img{
            width: 10px;
        }

chapter-1.xhtml:

        <head>
            <link href="local.css">
            <link href="se.css">

        <body>
            <section>
                <img>

would become:

local.css:

        .local-css img{
            width: 10px;
        }

chapter-1.xhtml:

        <head>
            <link href="local.css">
            <link href="se.css">

        <body>
            <section class="local-css se-css">
                <img>

May 05 '25 21:05 acabal

You never commented on list—why can't just the elements that use se.css be isolated, ensuring they can't be overridden by anything in local? (I gave a couple of possible approaches, but there are surely many others.)

May 20 '25 21:05 vr8hub

Because the toolset is also used for white-label ebooks so we're looking for a general-purpose solution. An SE-specific solution may be acceptable in the interim if the complexity of a general-purpose solution is out of control.

May 20 '25 21:05 acabal

(These questions are from curiosity, not persuasion; I don't have any dog in this hunt.)

Right, but white label books have no se.css, and therefore the problem doesn't exist. If I'm producing a white-label book and I split my css into multiple files (why would I?), then I've created the problem and I should use better CSS hygiene to fix it. (And out of even more idle curiosity, who's using this for white-label books?)

In fact, could that not be another solution—just don't allow body-level CSS, and add a test or tests in lint to identify/enforce it?

May 20 '25 22:05 vr8hub

We're not here to judge user's hygiene, but rather to provide a toolset that works in the general case. (And judging them on splitting their CSS would imply that we are not being hygienic.) A white-label user could just as well have a file called random-house.css used in the exact same way we use se.css.

Not allowing body level CSS is an option, but I'm not crazy about it because there are times when selecting the topmost parent <section> may be necessary, and body > section is the only way to do that.

May 21 '25 02:05 acabal

The hygiene comment was about targeting body (which split files would expose), not about the split files themselves. And as I said on the list, "works in the general case" is fine, but targeting body is not the "general case," and it's therefore (IMHBAO) unreasonable to expect it to work then.

The epub type can be targeted (subsections don't have the same epub type as the main section), the id(s) could be targeted, etc. I've targeted something like section[id^="part-"] in personal projects before (I don't think I've had to do it for an SE one); doing the same for "chapter-" would choose all chapters, etc. There are ways to do it without targeting (implicitly or explicitly) body.

But, I get the gist, so I'll leave you to it. Thanks for your patience with my curiosity.

May 21 '25 17:05 vr8hub