Last modified: 2010-05-15 15:38:35 UTC
Kate's new option is not correctly shown on Netscape 7.1 browser patch: 753: <div class='toggle'>$msgUnderline ... 759: </div> to this: 753: <div><label>$msgUnderline ... 759: </label><div>
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.