Bug 4821 - With multiple 5XX fields, the font display gets progressively smaller
Summary: With multiple 5XX fields, the font display gets progressively smaller
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) normal (vote)
Assignee: Owen Leonard
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-26 19:51 UTC by Jane Wagner
Modified: 2012-10-25 22:52 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments
Screen shot of OPAC display (173.80 KB, image/jpeg)
2010-05-26 19:51 UTC, Jane Wagner
Details
partial fix (intranet bib details) (5.24 KB, patch)
2010-05-27 02:39 UTC, Galen Charlton
Details | Diff | Splinter Review
Proposed fix (25.65 KB, patch)
2010-05-27 19:55 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jane Wagner 2010-05-26 19:51:46 UTC
Created attachment 2170 [details]
Screen shot of OPAC display

If a record has a lot of 5XX fields, the details screen has each entry in a progressively smaller font.  The results_summary stylesheet setting is at 85%; adding .results_summary { font-size:100%; } in OpacUserCSS syspref fixes the display.

According to discussion on the IRC, the cause of the problem is poorly-nested spans in the MARC21slim2OPACDetail.xsl file, though.  Changing the stylesheet font is a workaround but not the proper fix.

I'm not sure how to fix that myself.  Ideas?

By the way, the same problem exists in current head with the staff interface XSLT display, so it should be fixed on staff side as well.
Comment 1 Jared Camins 2010-05-26 20:16:28 UTC
Based on brief testing, the problem seems to be that Firefox doesn't like self-closing tags (specifically, the <span class="label"/> tag that precedes each paragraph after the second), but I don't have any solution to that. See https://bugzilla.mozilla.org/show_bug.cgi?id=521300 for a related issue. Two possible workarounds might be to A) force the parser to expand empty tags or B) change the content-type header to something else. I have no idea how to do either of those things, though, and I'm not sure which is better.
Comment 2 Owen Leonard 2010-05-27 01:30:54 UTC
The problem isn't limited to Firefox. I see the same results in Safari (Mac) and Chrome (Linux). Anyway, there's no legitimate reason for the script to be spitting out a self-closed tag there. The label <span> should wrap the "Contents:" label, [close], and be followed by the contents of the tag. I think this must be a bug in the XSL template.
Comment 3 Galen Charlton 2010-05-27 02:36:59 UTC
(In reply to comment #2)
> The problem isn't limited to Firefox. I see the same results in Safari (Mac)
> and Chrome (Linux). Anyway, there's no legitimate reason for the script to be
> spitting out a self-closed tag there. The label <span> should wrap the
> "Contents:" label, [close], and be followed by the contents of the tag. I think
> this must be a bug in the XSL template.

The issue is a bit more subtle - if you serve XHTML using the application/xhtml+xml MIME type, a construct like

<span class="results_summary"><span class="label" />contents</span>

is displayed correctly.  However, the correct MIME type for XHTML isn't correctly handled by IE6, so we serve it as text/html.  Unfortunately, despite the XHTML document declaration, Firefox and other browsers see the text/html MIME type and construct the DOM tree using HTML rules, not XHTML.
Comment 4 Galen Charlton 2010-05-27 02:39:43 UTC Comment hidden (obsolete)
Comment 5 Owen Leonard 2010-05-27 19:55:29 UTC
Created attachment 2183 [details] [review]
Proposed fix

This fix includes Galen's changes as well as changes to UNIMARCslim2intranetDetail.xsl, MARC21slim2OPACDetail.xsl, and UNIMARCslim2OPACDetail.xsl
Comment 6 Galen Charlton 2010-06-24 02:54:07 UTC
Patch pushed.  Please test and close.
Comment 7 Jane Wagner 2010-06-25 12:45:10 UTC
Seems to work fine, thanks!