Footnote: edit to span.footnote not working in app

I’ve been asked to change the color of the footnote for an app. I found the span.footnote property under the styles section and edited it to be “blue”

When I build the app the footnote color remains unchanged on my phone.

image

If I export the HTML to view it on a browser the footnote is displayed per the ‘declaration’.

image

Chris Hubbard and I verified that working with the webpage via a right-click > inspect and editing the span.footnote properties will alter this property correctly.

What is stopping the app build from displaying this edit?
I have deleted the app between the test builds, yet the color remains unchanged.

Any insight and/or thoughts on why the app is not displaying the footnote change?

Check that there is no conflict between Project > Styles and the Project > Books > Book Collection Style tab.

Good thought Greg, but they are all set to the same setting: blue

Other ideas?

I see the inline style is referring to a red style which is probably overriding the span.footnote style. Make your style more specific and hopefully it will override the inline style. (See CSS Specificity)

To be as specific as possible add the following custom style:

span.footnote sup {color: blue;}

or

span.footnote.selectble.tootipstered sup {color: blue;}

*[edit: misread the above code - thought it had a “red” class. now see it is the end of “tooltistered”]

See CSS Combinators and Multiple Class / ID and Class Selectors | CSS-Tricks - CSS-Tricks

Hi Greg, Interesting but I’m not sure I’m following this. Forgive me, I’m not a coder,…though it’s fun to learn about.

I presume the “red” line referred to is the “span.fv” shown in each style section pictured and where I do see the “color: red” designation. I have not edited that line except in the first overall Styles section. Looking at the individual book styles, where this style is not edited and is “red” I think I must have tried to edit that line in the overall styles and when it didn’t effect the footnote color, changed it back to what was probably the original setting as red.

If the specific’s are overriding one another, shouldn’t the phone version show the footnote marker (style = span.footnote and in the original sfm file marked as “\f”) in red, or blue, instead of what appears to be the same color as the text “Preface” as shown in the first picture?

  • This text “Preface” is marked as \s in the sfm file and the div.s setting is set to match the VerseNumberColor.
  • The verse number is set by the style setting “span.v” and the color selection is set in SAB as “VerseNumberColor”.

Viewed in a browser window, the span.footnote style is picked up correctly, but It appears the span.footnote in the phone version is picking up the \s (div.s) setting which pulls the span.v color, instead of the correct span.footnote = color: blue (or the span.fv = color: red;)

Hi @Dan_Neville
The HTML code (right-click > inspect) in your 1st post above has

<span  class"footnote selectactable tooltipstered" ... etc.

so the SPAN has multiple classes. The “selectable” or “tooltipstered” classes might be interfering. (The “red” had pushed over to the next line, so I thought it was a “red” class.)

span.footnote would affect this SPAN, but so would span.selectable or span.tooltipstered. The other two are not in the list, but they are in the CSS files with the HTML that SAB creates.

The app might have some CSS code that overrides the color setting in in those classes or even somewhere else. Your style should work since it looks like the paragraph style for the heading (\s1 or \s) is doing the overriding, yet it should take less precedence since it is “further away” from the footnote code.

heading tag ... (<-- further away) span tag ... sup tag (closest to the *)

Adding .selectable and .tooltipstered to the style will make it more specific than just span.footnote.

The SUP (superscript) tag is inside the SPAN, so adding that tag to the style name should make the style take precedence over just span.footnote.


or
image

Hopefully the devs can figure this out. The more-specific-style is just a work around.