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

[Sam H. <sh...@ma...>]

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

Begin forwarded message:

> From: Arnold Pizer <ap...@ma...>
> Date: January 28, 2005 2:16:43 PM EST
> To: John Jones <jj...@as...>, Arnold Pizer <ap...@ma...>
> Cc: Sam Hathaway <sh...@ma...>, ga...@ma...
> 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=A0 fixes the problem with labels in MSIE.=A0 Can =
you=20
> test quickly if this fixes the peekaboo bug?=A0 I don't recall where=20=

> this was appearing, so I don't know how to test it quickly.=A0 Sam is=20=

> adding a number of bug fixes to rel-2-1-patches and the zoom:1 fix is=20=

> one of them:
>
>  webwork2: Add hack to get around MSIE peekaboo bug. (apizer)
> =A0=A0=A0=A0=A0=A0=A0=A0conf/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=20=

> fix the bug.=A0 =46rom my meager understanding of css, that's because =
the=20
> fix above only applies to css elements which are declared as=20
> buggybox.=A0 So, some other part(s) of the template have to declare=20
> themselves as being buggyboxes.=A0 I am not sure on which ones should =
be=20
> so declared, and how best to do that.=A0 I did try putting a div of=20
> class buggybox inside the div for body (and also just outside of it),=20=

> and neither worked.
>
>  It is easiest to see the peekaboo bug on the first problem of set0,=20=

> especially if you reload the page.=A0 You may have to be logged in as =
a=20
> student to see it because triggering the bug is related to the length=20=

> of the content in the left panel vs. the content in the main panel=20
> containing the problem.=A0 Narrowing your browser window may also help=20=

> in triggering it.
>
>  John
>
>
>
>
>  Arnie
>
>
>
>
> Hi,
>
>  We have encountered this bug, but we don't have a fix yet.=A0 I =
didn't=20
> realize it was caused by the zoom:1 fix.=A0 My recollection is that I=20=

> tried "position: relative" in various spots instead of the zoom fix=20
> without success.=A0 But, I was basically blindly putting it in places=20=

> without much understanding of what's going on.
>
>  I'll let you know if I find a more universal fix.=A0 For now I tell=20=

> people that it is an explorer bug, and they should use netscape,=20
> 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=3D"A"=20=

> VALUE=3D"1" and also with TYPE=3D"A" or
>  STYLE=3D"list-style:upper-alpha".=A0 When this hack is present, the=20=

> labels disappear under all the above options.
>
>  Is there a better bug fix for the peekaboo bug that doesn't cause=20
> other problems (at least other problems that appear in WeBWorK?).=A0 =
For=20
> example on the web I found:
>
>
>  I have usually used position: relative; to get rid of the bug, but it=20=

> appears there's a much better solution. It seems that if the container=20=

> that holds the float* is given an assigned 'line-height' (any assigned=20=

> line-height) the bug vanishes. Cool. Testing shows that 'line-height:=20=

> 1.2em;' generally works well, but in the case of child elements with=20=

> differing font sizes, it may be necessary to also give them their own=20=

> line-heights to avoid problems in IE.
>
>
>
>  John, I think you are the expert on this.=A0 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=20
> http://webwork.rochester.edu/webwork2/mth141 with MSIE 6, the letters=20=

> A,B, etc in the ordered list do not appear.=A0 It works OK with other=20=

> browsers. The relevant code in the problem is
>
>  =A0=A0=A0=A0=A0=A0=A0=A0 <OL TYPE=3D"A" VALUE=3D"1">
>  ...
>  =A0=A0=A0=A0=A0=A0=A0 </OL>
>
>  which is generated by &match_questions_list.
>
>  =A0<OL TYPE=3D"A" VALUE=3D"1"> is deprecated but supposed to work =
with=20
> transitional 4.*.
>
>  If you comment out the style commands in the source (i.e. <style>=20
> .... </style>) then the ordered list looks fine with MSIE so something=20=

> within the style is causing MSIE not to use the deprecated commands.=A0
>  Do you have any idea what may be the problem.?=A0 Of course we can =
say=20
> don't use MSIE but that doesn't help students.=A0 I assume one =
solution=20
> would be to rewrite &match_questions_list so that it uses CSS and=20
> modify <style> .... </style> accordingly.=A0 Do you know of another=20
> solution?
>
>  I don't have access to IE 6, but I'm not sure that this is happening=20=

> because deprecated attributes are being ignored. But lets see if we=20
> can work around it:
>
>  First of all, does the VALUE attribute in the <OL> tag actually do=20
> anything? According to the HTML 4.01 specification, VALUE is only=20
> valid for <LI>, not for <UL> and <OL>. Does removing VALUE change IE's=20=

> behavior?
>
>  What happens if you remove the TYPE attribute as well? Do the default=20=

> numeric labels appear, or is it still blank?
>
>  Also try replacing TYPE with STYLE=3D"list-style:upper-alpha". Any=20
> 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
>