Bug 4821

Summary: With multiple 5XX fields, the font display gets progressively smaller
Product: Koha Reporter: Jane Wagner <jwagner>
Component: OPACAssignee: Owen Leonard <oleonard>
Status: CLOSED FIXED QA Contact: Bugs List <koha-bugs>
Severity: normal    
Priority: PATCH-Sent (DO NOT USE) CC: camins, gmcharlt
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Screen shot of OPAC display
partial fix (intranet bib details)
Proposed fix

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!