[WWdevel] Fwd: bug using <OL> with MSIE in WW2

[Sam Hathaway]

I'm posting this to the development list in hopes that someone will 
have some insight.
-sam

Begin forwarded message:

> From: Arnold Pizer <apizer at math.rochester.edu>
> Date: January 28, 2005 2:16:43 PM EST
> To: John Jones <jj at asu.edu>, Arnold Pizer <apizer at math.rochester.edu>
> Cc: Sam Hathaway <sh002i at math.rochester.edu>, gage at math.rochester.edu
> Subject: Re: bug using <OL> with MSIE in WW2
>
>  At 01:51 PM 1/28/2005, John Jones wrote:
>
>  Thanks John,
>
>  Arnie
>
>
> Arnold Pizer wrote:
>
>  At 10:02 AM 1/28/2005, John Jones wrote:
>
>  Hi John,
>
>  Substituting
>
>  /* Hides from IE5-mac \*/
> * html .buggybox {height: 1%;}
>  /* End hide from IE5-mac */
>
>  (see http://www.positioniseverything.net/articles/hollyhack.html )
>
>  for the zoom:1 fix  fixes the problem with labels in MSIE.  Can you 
> test quickly if this fixes the peekaboo bug?  I don't recall where 
> this was appearing, so I don't know how to test it quickly.  Sam is 
> adding a number of bug fixes to rel-2-1-patches and the zoom:1 fix is 
> one of them:
>
>  webwork2: Add hack to get around MSIE peekaboo bug. (apizer)
>         conf/templates/ur.template
>
>  so it would be good if we can get this done before he finalized that.
> Just tried replacing the zoom line with the one above and it does not 
> fix the bug.  From my meager understanding of css, that's because the 
> fix above only applies to css elements which are declared as 
> buggybox.  So, some other part(s) of the template have to declare 
> themselves as being buggyboxes.  I am not sure on which ones should be 
> so declared, and how best to do that.  I did try putting a div of 
> class buggybox inside the div for body (and also just outside of it), 
> and neither worked.
>
>  It is easiest to see the peekaboo bug on the first problem of set0, 
> especially if you reload the page.  You may have to be logged in as a 
> student to see it because triggering the bug is related to the length 
> of the content in the left panel vs. the content in the main panel 
> containing the problem.  Narrowing your browser window may also help 
> in triggering it.
>
>  John
>
>
>
>
>  Arnie
>
>
>
>
> Hi,
>
>  We have encountered this bug, but we don't have a fix yet.  I didn't 
> realize it was caused by the zoom:1 fix.  My recollection is that I 
> tried "position: relative" in various spots instead of the zoom fix 
> without success.  But, I was basically blindly putting it in places 
> without much understanding of what's going on.
>
>  I'll let you know if I find a more universal fix.  For now I tell 
> people that it is an explorer bug, and they should use netscape, 
> mozilla, or some other browser.
>
>  John
>
>
>  Arnold Pizer wrote:
>
>  At 07:05 PM 1/26/2005, Sam Hathaway wrote:
>
>  Hi Sam and John,
>
>  The thing that causes the problem is
>
>  /* hack to get around MSIE peekaboo bug */
>  * {zoom: 1;}
>
>  When this is removed, the labels appear with the original TYPE="A" 
> VALUE="1" and also with TYPE="A" or
>  STYLE="list-style:upper-alpha".  When this hack is present, the 
> labels disappear under all the above options.
>
>  Is there a better bug fix for the peekaboo bug that doesn't cause 
> other problems (at least other problems that appear in WeBWorK?).  For 
> example on the web I found:
>
>
>  I have usually used position: relative; to get rid of the bug, but it 
> appears there's a much better solution. It seems that if the container 
> that holds the float* is given an assigned 'line-height' (any assigned 
> line-height) the bug vanishes. Cool. Testing shows that 'line-height: 
> 1.2em;' generally works well, but in the case of child elements with 
> differing font sizes, it may be necessary to also give them their own 
> line-heights to avoid problems in IE.
>
>
>
>  John, I think you are the expert on this.  Any ideas?
>
>  Arnie
>
>
>
> On Jan 26, 2005, at 2:56 PM, Arnold Pizer wrote:
>
>
> Hi Sam,
>
>  If you look at prob 1 in set 1 in 
> http://webwork.rochester.edu/webwork2/mth141 with MSIE 6, the letters 
> A,B, etc in the ordered list do not appear.  It works OK with other 
> browsers. The relevant code in the problem is
>
>           <OL TYPE="A" VALUE="1">
>  ...
>          </OL>
>
>  which is generated by &match_questions_list.
>
>   <OL TYPE="A" VALUE="1"> is deprecated but supposed to work with 
> transitional 4.*.
>
>  If you comment out the style commands in the source (i.e. <style> 
> .... </style>) then the ordered list looks fine with MSIE so something 
> within the style is causing MSIE not to use the deprecated commands. 
>  Do you have any idea what may be the problem.?  Of course we can say 
> don't use MSIE but that doesn't help students.  I assume one solution 
> would be to rewrite &match_questions_list so that it uses CSS and 
> modify <style> .... </style> accordingly.  Do you know of another 
> solution?
>
>  I don't have access to IE 6, but I'm not sure that this is happening 
> because deprecated attributes are being ignored. But lets see if we 
> can work around it:
>
>  First of all, does the VALUE attribute in the <OL> tag actually do 
> anything? According to the HTML 4.01 specification, VALUE is only 
> valid for <LI>, not for <UL> and <OL>. Does removing VALUE change IE's 
> behavior?
>
>  What happens if you remove the TYPE attribute as well? Do the default 
> numeric labels appear, or is it still blank?
>
>  Also try replacing TYPE with STYLE="list-style:upper-alpha". Any 
> difference?
>  -sam
> Prof. Arnold K. Pizer
>  Dept. of Mathematics
>  University of Rochester
>  Rochester, NY 14627
>  (585) 275-7767
>
>  Prof. Arnold K. Pizer
>  Dept. of Mathematics
>  University of Rochester
>  Rochester, NY 14627
>  (585) 275-7767
>
>  Prof. Arnold K. Pizer
>  Dept. of Mathematics
>  University of Rochester
>  Rochester, NY 14627
>  (585) 275-7767
>