pzdn2009 / syntaxhighlighter

Automatically exported from code.google.com/p/syntaxhighlighter
GNU General Public License v3.0
0 stars 0 forks source link

Background colors not expanding when scrolling horizontally. #1

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a code block and then shrink the browser window until it scrolls
horizontally.  Should see that the background does not continue past the
viewport.

What is the expected output? What do you see instead?
Expectation: Background continue for total available scroll width.

What version of the product are you using? On what operating system?
1.5 Windows XP & Solaris 8

Please provide any additional information below.
I was implementing this component into Joomla so that I could highlight my
code samples when I first noticed this issue.

I then went to the samples included with the distribution and altered the
JavaScript example to use both the <pre> and <textarea> tags to determine
if it was affecting both or not.  It affects both.  Also, to see if this
was a page refresh issue or not I set the width of the containing div in
the sample file to 300px and got the same result.

Here is a sample of what I did in the sample file:

<div class="column2" style="width: 300px;">
Text body before.
<hr/>
<pre name="code" class="js">
/***********************************
 ** Multiline block comments
 **********************************/

// Hang test à partir de l`idagence / id type publication ``````

var stringWithUrl1 = "http://blog.dreamprojections.com";
var stringWithUrl2 = 'http://www.dreamprojections.com';

// callback for the match sorting
dpSyntaxHighlighter.prototype.SortCallback = function(m1, m2)
{
    // sort matches by index first
    if(m1.index < m2.index)
        return -1;
    else if(m1.index > m2.index)
        return 1;
    else
    {
        /*
        // if index is the same, sort by length
        if(m1.length < m2.length)
            return -1;
        else if(m1.length > m2.length)
            return 1;
        */
    }

    alert('hello // world');
    return 0;
}
</pre>

Attached is a screen shot of what I am seeing.

thanks.

Original issue reported on code.google.com by mindblen...@gmail.com on 17 May 2007 at 6:42

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by alex.gor...@gmail.com on 22 May 2007 at 6:42

GoogleCodeExporter commented 9 years ago
I noticed this issue while updating my blog
(http://blog.brucknerite.net/2007/05/bibliolinks-v3.html) to support your 
component.
I tested on Firefox 2 and IE 6 (Windows XP). It looks the same in both 
browsers. I'll
look into it further and report back to you if I find something valuable. Thank 
you
for your effort!

Original comment by bruckner...@gmail.com on 23 May 2007 at 2:33

GoogleCodeExporter commented 9 years ago
The problem is somewhere with styles. For some reason LI doesn't expand pass the
width of the UL and it's ignoring the scrollable width.

I tried to fix it earlier but to no avail. It's been a known issue for a while, 
but
not a high priority.

Original comment by alex.gor...@gmail.com on 23 May 2007 at 3:52

GoogleCodeExporter commented 9 years ago
I have examined the issue, and tested some modifications in shCore. In 
particular, I
tried to exchange the first child of <li>s, <span>, by a <div>. I assigned the 
same
styles to those <div>s than to the enclosing <li>s. In the highlightAll() 
method, I
adjust the style.width property of each <div> to highlighter.div.scrollWidth 
minus
the sum of all left margins (58px, I believe). There is a very minor issue, 
though,
when the page is rendered and, afterwards, the browser's window is manually 
narrowed:
the horizontal scroll ends up being too wide. This doesn't happen in the 
opposite
case (when the browser's window is widened).

As a consequence of all this, some changes to the stylesheet were in order. I
included a white-space: pre directive for <li> as a cosmetic matter (while 
debugging
with Firebug I experienced some re-rendering issues with <li>s wrapping , that 
were
solved this way; I don't know if this has any real-life impact).

Original comment by bruckner...@gmail.com on 24 May 2007 at 11:00

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by alex.gor...@gmail.com on 5 Aug 2007 at 2:13

GoogleCodeExporter commented 9 years ago
I don't know what happened, but this did not turn out like I thought it would. 
(pics
attached)
It could be a mismatch in files since I've been poking around the code, but I 
don't know.

I did a bit of work trying to fix this issue myself after I ran into it on my 
own
site.  I believe this issue is found in many cases when dealing with HTML and 
CSS,
when the style info does not work when scrollbars come into play.

For my fix, I buried into the newly created OL list DOM structure, and set the 
width
of all of the SPAN elements inside the LI elements to the width of the largest 
one
(plus a couple more pixels).  I tried changing the LI elements themselves, but 
it
didn't do anything.

I don't think it's the most optimized way to do it, but I call it in a timeout 
so
that the newly created SyntaxHighlighter DOM is inserted into the page and can 
calculate its actual widths.

I added the following line to the shCore.js file (line 560 in the uncompressed 
file):

    // JavaScript functionality to extend background row colors the full extent of the
textarea
    setTimeout("var lists = document.getElementsByTagName('ol'); for(var j = 0; j <
lists.length; j++){ if(lists[j].parentNode.className == \"dp-highlighter\"){ var
maxWidth = lists[j].offsetWidth; var originalWidth = lists[j].offsetWidth; 
for(var i
= 0; i < lists[j].childNodes.length; i++){ if(maxWidth <
lists[j].childNodes[i].firstChild.offsetWidth){ maxWidth =
lists[j].childNodes[i].firstChild.offsetWidth; } } if(maxWidth >
originalWidth){lists[j].previousSibling.style.width = '' + (maxWidth + 14) +
'px';lists[j].style.width = '' + (maxWidth + 14) + 'px'; } } }", 1);

This code follows:

    this.AddBit(this.code.substr(pos), null);

    this.SwitchToList();
    this.div.appendChild(this.bar);
    this.div.appendChild(this.ol);

Comments and code suggestions are greatly appreciated, but it seems to be 
working for
now on my site.  http://cupof.coffeeandcode.com

Original comment by CoffeeAn...@gmail.com on 16 Apr 2008 at 12:47

Attachments:

GoogleCodeExporter commented 9 years ago
Sorry, I guess it would make sense to attach the new shCore.js file too.

Original comment by CoffeeAn...@gmail.com on 16 Apr 2008 at 12:51

Attachments:

GoogleCodeExporter commented 9 years ago
CoffeeAndCode,

your shCore.js file works great thanks for the fix. I just noticed this problem
today.  I did find one small issue though.

when I replaced my shCore.js with your uncompressed file, when I view the code 
block
on my site, instead of starting from line 01 they start from line 00

Original comment by serialbo...@gmail.com on 26 Apr 2008 at 5:26

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
serialboxhpc,

If you apply CoffeeAndCode's fix to the latest (1.5.1) release, you'll note 
that it starts numbering from line 01 
properly. The difference is that in the latest versions of shCore.js, there is 
type coercion when checking firstLine 
== null (line 720 in the uncompressed file). 

In the patched file submitted by CoffeeAndCode, a triple equals is used instead 
of just double equals.

You can fix this by changing line 724 in the patched file to be:
highlighter.firstLine = (firstLine == null) ? 
parseInt(GetOptionValue('firstline', options, 1)) : firstLine;

Alternatively, you can insert CoffeeAndCode's fix into the shCore.js from the 
1.5.1 release after line 525

Original comment by j.ignaci...@gmail.com on 23 Jul 2008 at 11:37

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I'm having the same issue with the current version (2.0.320). Tried to apply 
CoffeAndCode's solution to shCore.js file but could not find the code location; 
maybe shCore.js changed totally? Tried to use CoffeeAndCode's uncompressed 
script 
instead, but then it breaks it all, due to the version differences I guess. Can 
you 
help me please?

Original comment by kutsalbi...@gmail.com on 4 Aug 2009 at 11:52

GoogleCodeExporter commented 9 years ago
In the CSS file, I have added 
width:120% to the dp-highlighter ol.
CSS:

dp-highlighter ol
{
    width:120%;
}

This has solved the problem in my case. but this create a little problem when 
my code
does not require horizontal bar. it add that due to width setting.
you can see the changes i have made:
http://blog.satya-weblog.com/ws/g_sytx/SyntaxHighlighter.css 

Original comment by satya61...@gmail.com on 13 Oct 2009 at 7:52