Isolating CSS in web full text view
127 views
Skip to first unread message
Alex Cabal
May 5, 2025, 2:02:02 PMMay 5
to Standard Ebooks
An issue has been brought up on Github: If an ebook has images that are
sized with a broadly-specific selector, then in the single-page web view
that broad selector will also select the titlepage image, incorrectly
sizing it. See for example
https://standardebooks.org/ebooks/william-faulkner/the-sound-and-the-fury/text/single-page
This shouldn't be solved by editing the ebook to make the selector more
specific, because the epub shouldn't care how the single-page view is
compiled.
Rather, we should think of a general purpose solution to isolate CSS in
the single-page view, in case the stylesheets or structuring change in
the future.
I think one solution would be to do the following when compiling the
single-page view:
- 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>
I *think* this should solve the issue. Does anyone see any problems or
does anyone have any thoughts on different approaches?
Also, would anyone be interested in working to implement this?
sized with a broadly-specific selector, then in the single-page web view
that broad selector will also select the titlepage image, incorrectly
sizing it. See for example
https://standardebooks.org/ebooks/william-faulkner/the-sound-and-the-fury/text/single-page
This shouldn't be solved by editing the ebook to make the selector more
specific, because the epub shouldn't care how the single-page view is
compiled.
Rather, we should think of a general purpose solution to isolate CSS in
the single-page view, in case the stylesheets or structuring change in
the future.
I think one solution would be to do the following when compiling the
single-page view:
- 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>
I *think* this should solve the issue. Does anyone see any problems or
does anyone have any thoughts on different approaches?
Also, would anyone be interested in working to implement this?
Anthony J. Bentley
May 5, 2025, 9:26:56 PMMay 5
to standar...@googlegroups.com
There are many instances of “body [xml|lang]” (and variations) in local.css that should not become “.local-css body [xml|lang]”. So the action is not exactly to prefix the selector, but to prefix the first non-body element of the selector. And then there’s Logico Philosophicus which has “body > section > table > tbody > tr > td:first-child”.
Alex Cabal
May 6, 2025, 1:59:25 PMMay 6
to standar...@googlegroups.com
Good point. So it's going to be more complicated than I thought.
Thoughts on how to address this?
On 5/5/25 8:26 PM, 'Anthony J. Bentley' via Standard Ebooks wrote:
> There are many instances of “body [xml|lang]” (and variations) in
> local.css that should not become “.local-css body [xml|lang]”. So the
> action is not exactly to prefix the selector, but to prefix the first
> non-body element of the selector. And then there’s Logico Philosophicus
> which has “body > section > table > tbody > tr > td:first-child”.
>
>
> On May 5, 2025 12:01:52 PM MDT, Alex Cabal <al...@standardebooks.org> wrote:
>
> An issue has been brought up on Github: If an ebook has images that
> are sized with a broadly-specific selector, then in the single-page
> web view that broad selector will also select the titlepage image,
> incorrectly sizing it. See for example https://standardebooks.org/
> ebooks/william-faulkner/the-sound-and-the-fury/text/single-page
> <https://standardebooks.org/ebooks/william-faulkner/the-sound-and-
> the-fury/text/single-page>
> --
> You received this message because you are subscribed to the Google
> Groups "Standard Ebooks" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to standardebook...@googlegroups.com
> <mailto:standardebook...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> standardebooks/4528607F-B9F8-4E98-B5F1-4C26A04938E7%40roadrunner.page
> <https://groups.google.com/d/msgid/standardebooks/4528607F-B9F8-4E98-
> B5F1-4C26A04938E7%40roadrunner.page?utm_medium=email&utm_source=footer>.
Thoughts on how to address this?
On 5/5/25 8:26 PM, 'Anthony J. Bentley' via Standard Ebooks wrote:
> There are many instances of “body [xml|lang]” (and variations) in
> local.css that should not become “.local-css body [xml|lang]”. So the
> action is not exactly to prefix the selector, but to prefix the first
> non-body element of the selector. And then there’s Logico Philosophicus
> which has “body > section > table > tbody > tr > td:first-child”.
>
>
> On May 5, 2025 12:01:52 PM MDT, Alex Cabal <al...@standardebooks.org> wrote:
>
> An issue has been brought up on Github: If an ebook has images that
> are sized with a broadly-specific selector, then in the single-page
> web view that broad selector will also select the titlepage image,
> incorrectly sizing it. See for example https://standardebooks.org/
> ebooks/william-faulkner/the-sound-and-the-fury/text/single-page
> the-fury/text/single-page>
> You received this message because you are subscribed to the Google
> Groups "Standard Ebooks" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to standardebook...@googlegroups.com
> <mailto:standardebook...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> standardebooks/4528607F-B9F8-4E98-B5F1-4C26A04938E7%40roadrunner.page
> <https://groups.google.com/d/msgid/standardebooks/4528607F-B9F8-4E98-
> B5F1-4C26A04938E7%40roadrunner.page?utm_medium=email&utm_source=footer>.
Vince
May 6, 2025, 4:21:36 PMMay 6
to Standard Ebooks
I would argue that all (or almost all) of those body[xml|lang] should be blockquote[xml|lang], and any remaining should be something else as well. We had body[xml|lang] in SEMoS for a while, when all we needed was blockquote[xml|lang], which is what is now in SEMoS.
Why would any local CSS need to start at body? I can’t think of a good reason (which as we know doesn’t mean there isn’t one). That should probably be something we look for in review and not allow unless it really can’t be solved any other way.
Alex Cabal
May 6, 2025, 4:57:05 PMMay 6
to standar...@googlegroups.com
That's a fine argument and we should probably do that at SE, but for
this tool we want to strive for a general-case solution. If someone
creates a white-label ebook then they would expect things to work if
there were broad selectors across various CSS files without a bunch of
caveats.
On 5/6/25 3:21 PM, Vince wrote:
> I would argue that all (or almost all) of those body[xml|lang] should be
> blockquote[xml|lang], and any remaining should be something else as
> well. We had body[xml|lang] in SEMoS for a while, when all we needed was
> blockquote[xml|lang], which is what is now in SEMoS.
>
> Why would any local CSS /need /to start at body? I can’t think of a good
> <https://groups.google.com/d/msgid/standardebooks/3DE968F7-866B-4C6B-
> ABAC-83EA54AB9BA6%40letterboxes.org?utm_medium=email&utm_source=footer>.
this tool we want to strive for a general-case solution. If someone
creates a white-label ebook then they would expect things to work if
there were broad selectors across various CSS files without a bunch of
caveats.
On 5/6/25 3:21 PM, Vince wrote:
> I would argue that all (or almost all) of those body[xml|lang] should be
> blockquote[xml|lang], and any remaining should be something else as
> well. We had body[xml|lang] in SEMoS for a while, when all we needed was
> blockquote[xml|lang], which is what is now in SEMoS.
>
> reason (which as we know doesn’t mean there isn’t one). That should
> probably be something we look for in review and not allow unless it
> really can’t be solved any other way.
>
>> On May 6, 2025, at 12:59 PM, Alex Cabal <al...@standardebooks.org> wrote:
>>
>> Good point. So it's going to be more complicated than I thought.
>> Thoughts on how to address this?
>>
>> On 5/5/25 8:26 PM, 'Anthony J. Bentley' via Standard Ebooks wrote:
>>> There are many instances of “body [xml|lang]” (and variations) in
>>> local.css that should not become “.local-css body [xml|lang]”. So the
>>> action is not exactly to prefix the selector, but to prefix the first
>>> non-body element of the selector. And then there’s Logico
>>> Philosophicus which has “body > section > table > tbody > tr >
>>> td:first-child”.
>
> probably be something we look for in review and not allow unless it
> really can’t be solved any other way.
>
>> On May 6, 2025, at 12:59 PM, Alex Cabal <al...@standardebooks.org> wrote:
>>
>> Good point. So it's going to be more complicated than I thought.
>> Thoughts on how to address this?
>>
>> On 5/5/25 8:26 PM, 'Anthony J. Bentley' via Standard Ebooks wrote:
>>> There are many instances of “body [xml|lang]” (and variations) in
>>> local.css that should not become “.local-css body [xml|lang]”. So the
>>> action is not exactly to prefix the selector, but to prefix the first
>>> non-body element of the selector. And then there’s Logico
>>> Philosophicus which has “body > section > table > tbody > tr >
>>> td:first-child”.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Standard Ebooks" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to standardebook...@googlegroups.com
> <mailto:standardebook...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> standardebooks/3DE968F7-866B-4C6B-ABAC-83EA54AB9BA6%40letterboxes.org
> You received this message because you are subscribed to the Google
> Groups "Standard Ebooks" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to standardebook...@googlegroups.com
> <mailto:standardebook...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/standardebooks/3DE968F7-866B-4C6B-
> ABAC-83EA54AB9BA6%40letterboxes.org?utm_medium=email&utm_source=footer>.
Vince
May 6, 2025, 6:51:30 PMMay 6
to Standard Ebooks
I don’t know who the “someone” is, but if it was me, I would not expect that, because it is an unreasonable expectation. :) When two separate files with two different CSS’s are brought together, conflicts are going to happen.
But if you want to attempt it, rather than trying to jury rig the large and variable and unknown (what is covered by local.css), would it not be easier to jury rig the small and fixed and known, i.e. the parts that are covered by se.css?
As one possible way, for the one-pager, give everything covered by se.css an id, and adjust the one-page se.css to target the ids.
Or, maybe the one-page se.css could actively reset all the elements it isn’t specifically setting; e.g. if max-height was reset in the se.css img element, then Sound and Fury works.
Whatever the implementation, what is covered by se.css, and the CSS itself, almost never changes, so once whatever is done is done, then it’s going to work for a long time, and if/when changes are made to the files or the CSS, they’re easy to implement, because they are again small and fixed and known. Trying to attack this from the local side feels like starting an infinitely long game of whack-a-mole.
Anthony J. Bentley
May 8, 2025, 3:30:55 AMMay 8
to standar...@googlegroups.com
The difference in difficulty between prefixing any [simple] selector and determing the right insertion point in any [complicated] selector seems very large. Maybe to the point of impracticality? Is the universal implementation desirable compared to simply documenting a restriction that CSS selectors can’t contain or otherwise match body?
Alex Cabal
May 8, 2025, 11:27:13 AMMay 8
to standar...@googlegroups.com
Yes I agree. Ideally, like the toolset in general we want this to be a
while label solution that could work for any book. In practice we may
have to implement a partial solution that only works for SE books unless
we can think of a simpler way to do this.
> <https://groups.google.com/d/msgid/>
> standardebooks/3DE968F7-866B-4C6B-
> ABAC-83EA54AB9BA6%40letterboxes.org <https://groups.google.com/
> d/msgid/standardebooks/3DE968F7-866B-4C6B- <https://
> groups.google.com/d/msgid/standardebooks/3DE968F7-866B-4C6B->
> ABAC-83EA54AB9BA6%40letterboxes.org?
> utm_medium=email&utm_source=footer>.
> <https://groups.google.com/d/msgid/standardebooks/D7FF3E03-
> D999-4D6C-987F-1BDD01904CC6%40roadrunner.page?
> utm_medium=email&utm_source=footer>.
while label solution that could work for any book. In practice we may
have to implement a partial solution that only works for SE books unless
we can think of a simpler way to do this.
> standardebooks/3DE968F7-866B-4C6B-
> ABAC-83EA54AB9BA6%40letterboxes.org <https://groups.google.com/
> d/msgid/standardebooks/3DE968F7-866B-4C6B- <https://
> groups.google.com/d/msgid/standardebooks/3DE968F7-866B-4C6B->
> ABAC-83EA54AB9BA6%40letterboxes.org?
> utm_medium=email&utm_source=footer>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Standard Ebooks" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to standardebook...@googlegroups.com
> <mailto:standardebook...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> standardebooks/D7FF3E03-D999-4D6C-987F-1BDD01904CC6%40roadrunner.page
>
> --
> You received this message because you are subscribed to the Google
> Groups "Standard Ebooks" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to standardebook...@googlegroups.com
> <mailto:standardebook...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/standardebooks/D7FF3E03-
> D999-4D6C-987F-1BDD01904CC6%40roadrunner.page?
> utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages