Wikimedia Bugzilla is closed!

fixed! thanks. 

You still have <div class="toggle"> in CVS

This does ***not*** work with NETSCAPE

I asked again to use my patch exactly as shown:

patch:
753: <div class='toggle'>$msgUnderline
to this:
753: <div><label>$msgUnderline

----

If (I misunderstood something) { 
   pls_apologise();
   tell_me_why_I_am_wrong();
} else {
   pls_fix_again();
}

(In reply to comment #2)
> patch:
> 753: <div class='toggle'>$msgUnderline
> to this:
> 753: <div><label>$msgUnderline

* Current code, AFAICS, is <div class='toggle'><label>...</label></div>
* Without any CSS class in it, there's no point in having the <div> tag; so if
that's really the problem, it should be either just <label>...</label> or <label
class='toggle'>...</label>. 
* If it's the 'toggle' CSS class that's the problem, then presumably it needs
fixing, not just removing from the code. Or is it actually extraneous?
* Without really looking at the code properly, shouldn't the <label> only
contain the text - i.e. the label - not the associated form elements? Perhaps
this is the/a source of misunderstanding/misbehaviour. Perhaps it should be as
follows (like I say, I haven't looked at the context properly, but from how I
remember the "label" element working):

<div class='toggle'>
  <select name=\"wpOpunderline\">
    <label>$msgUnderline</label>
    <option value=\"0\"$s0>$msgUnderlinenever</option>
    <option value=\"1\"$s1>$msgUnderlinealways</option>
    <option value=\"2\"$s2>$msgUnderlinedefault</option>
  </select>
</div>

(In reply to comment #3)
> (In reply to comment #2)
> > patch:
> > 753: <div class='toggle'>$msgUnderline
> > to this:
> > 753: <div><label>$msgUnderline
> 
> * Current code, AFAICS, is <div class='toggle'><label>...</label></div>
> * Without any CSS class in it, there's no point in having the <div> tag; so if
> that's really the problem, it should be either just <label>...</label> or <label
> class='toggle'>...</label>. 
> * If it's the 'toggle' CSS class that's the problem, then presumably it needs
> fixing, not just removing from the code. Or is it actually extraneous?
> * Without really looking at the code properly, shouldn't the <label> only
> contain the text - i.e. the label - not the associated form elements? Perhaps
> this is the/a source of misunderstanding/misbehaviour. Perhaps it should be as
> follows (like I say, I haven't looked at the context properly, but from how I
> remember the "label" element working):
> 
> <div class='toggle'>
>   <select name=\"wpOpunderline\">
>     <label>$msgUnderline</label>
>     <option value=\"0\"$s0>$msgUnderlinenever</option>
>     <option value=\"1\"$s1>$msgUnderlinealways</option>
>     <option value=\"2\"$s2>$msgUnderlinedefault</option>
>   </select>
> </div>

Rowan:
- Your last sniplet was as it was before (i.e. w/o the <label>....</label> tags
which I have proposed to Kate)
- w/ class='toggle', my NETSCAPE cuts the first three characters in the options
box !!
- When looking to other code lines of module SpecialPreferences.php (e.g. the
user-language option box), I could not find <div class='toggle'> tags.
- as written in my posting hereto. dropping the class=..... definition, it works
fine.
- I hope, that someone knowing the underlying exactly can fix this (small)
problem finally.

(In reply to comment #4)
> - Your last sniplet was as it was before (i.e. w/o the <label>....</label> tags
> which I have proposed to Kate)

Look closer: the <label>...</label> is there, surrounding the label, inside the
<select> form element - on referring to the spec, I see that my memory was wrong
in this regard, and the input element does indeed go inside the label element.
That seems counter-intuitive to me, but never mind.

> - w/ class='toggle', my NETSCAPE cuts the first three characters in the options
> box !!

So it's a problem with the CSS, and has little or nothing to do with whether
there's a <label> tag after all. I don't know what the class='toggle' is
designed to do, but presuming it was there deliberately, deleting it seems to be
avoiding the problem, rather than solving it.

skins/monobook/main.css contains:
.toggle {
	margin-left: 2em;
	text-indent: -2em;
}

Which is presumably causing the problem, but was presumably there for a reason.

(In reply to comment #5)
thanks Rowan

> So it's a problem with the CSS, and has little or nothing to do with whether
Yes, it appears indeed to be....

> skins/monobook/main.css contains:
> .toggle {
> 	margin-left: 2em;
> 	text-indent: -2em;

1. change the latter to
> 	text-indent: 0em;

2. and SpecialPreferences.php can be reverted to its version 1.124 (i.e. the
original Kate-Turner-Patch)
http://cvs.defau.lt/phase3/includes/SpecialPreferences.php?rev=1.124&content-type=text/x-cvsweb-markup

Can someone (pls.) commit this ? tia

It's a real pity but I need to revoke all my comments, and return to the
original posting, which solves the problem.

> > skins/monobook/main.css contains:
> > .toggle {
> > 	margin-left: 2em;
> > 	text-indent: -2em;
> 
> 1. change the latter to
> > 	text-indent: 0em;

Having this set to 0em, many texts on are pages are wrongly positioned.

The only patch which helps is the original one
SpecialPreferences.php:
change

753: <div class='toggle'>$msgUnderline
...
759: </div>

to this:
753: <div><label>$msgUnderline
...
759: </label><div>

In skins/monobook/main.css must:
remain

.toggle {
 	margin-left: 2em;
 	text-indent: -2em;
 

What is this referring to, and is it resolved?

Looks like its fixed in HEAD and 1_5 :
1.143        (hashar   21-Oct-05): <div class='toggle'><label
for='wpOpunderline'>$msgUnderline</label>

I am marking bug as fixed. Please reopen it if the issue is still occuring.