On 10/22/06, Simetrical <Simetrical+wikitech(a)gmail.com> wrote:
Okay, here's the situation. If the editsection
span is placed after
the heading proper in source, IE and Firefox don't want to reflow and
so they move the float down below any already-rendered content.
Opera, and apparently Safari, handle this correctly. I tried fiddling
with CSS hacks to get it to display right, but gave up. Currently I'm
thinking I'll revert to an in-source layout more like the previous
one, with the editsection span placed before the entire h# element,
and perhaps the h# element set to display as inline if that looks
helpful. Any thoughts?
The best I could come up with was to move everything back to the old
layout, but wrap headings in a div and change h#'s to display inline,
then shift all padding/border/margin rules to affect the wrapper div
rather than the h#. That makes the section edit link look good in
Monobook, but for some reason it does basically nothing for other
layouts.
Frankly, the only real way I can see to solve this properly is to use
a table. That would solve this perfectly (the position of table cell
contents can be much more simply coordinates than floats plus
nonfloats), and would have the added benefit of solving
<http://bugs.wikimedia.org/show_bug.cgi?id=1629> (which can't be
solved at all using CSS). It would also allow the French and German
Wikipedias to implement their changes using CSS only, not JS.
Tables shouldn't be used unless necessary, but I've come to conclude
that they're so much simpler and more effective here that this is a
case where their use is justified. I certainly won't switch things
over to tables unless I get the okay for it, but anyway, comments
appreciated. I've been working on this for the past five hours and
will be taking a little break now (good thing this got to me on a
Sunday).