river wrote:

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();

}

rowan.collins wrote:

(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.

rowan.collins wrote:

(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.