There are two important, separate, but related issues in all this:
1) Positioning of Edit link relative to Header in the fully rendered CSS
2) Positioning and ordering of the HTML tags used
It seems we're all in agreement that the goal of the upcoming change is to
move the edit link from the far right to the near right (German style) -
that takes care of #1.
Regarding the second issue - what Mark was saying (and a point to which I
agree) is that the edit link tag should _follow_ the header tag (regardless
of whether they're all wrapped in a div or not).
Do we all agree on that point? or is there still some desire to put the edit
link before the header tag?
Also, if the edit link tag follows the header tag, I personally think this
solves the "renders well" issue - except maybe in the case of high-numbered
headers like h5 or h6 where the edit link text may actually be larger than
the heading. Something to consider.
On 7/4/07, Simetrical <Simetrical+wikilist(a)gmail.com> wrote:
On 7/4/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:
At the moment, my only strong feeling is that any
change made right now
should fix the current underlying syntax of the tags, so that
1) It is semantically valid (no link embedded in the header tag)
Well, okay, but last time I tried to do that (undoing my own
stupidity) I broke a bunch of scripts and Brion reverted it.
Reordering two elements should have minimal impact, but adding and
removing elements will have an impact. I don't know if I want to make
both of these changes at once.
2) It is semantically meaningful (edit link
should be between header and
text, rather than in an ambiguous location)
In either case the edit link and header will undoubtedly be wrapped in
a div (to, e.g., provide the lower border and appropriate padding), so
I don't see a lack of semantic clarity here from a source-code level.
2) It renders well with no CSS (will probably
automatically follow from
Well, not so trivial if by "render well" you exclude the header and
the section link from being on different lines. <h#> is a block-level
element, so whether the section edit link is inline or block, it will
render on a different line unless one or the other element is styled.
In fact, the only way to allow it to render on one line without CSS is
to not use <h#> for the header itself, and use a <span> instead, like
the current (icky and not-really-semantic) header markup. If you
don't mind header and link from being on different lines, sure, it'll
But this also runs back into point 2 (well, the first point 2 :P), in
that depending on document structure it may render above the header
link, quite ambiguously, instead of below, less ambiguously.
3) It gives us the flexibility to use CSS to
create any of the suggested
Not so easy if you want to adhere to the last two points. In
particular, IE and Firefox both push down any float that's not at the
beginning of a line, so there's no way I know of at least to have the
current behavior with the edit section link after the header in the
source. That's why it comes before the header in the first place.
I *have* seen a proposed implementation of the right-floating link
that doesn't use floats, and instead uses absolute positioning, with
the link after the header text in the source. However, I don't know
if that has sinister drawbacks that will only be noticed after a
couple of weeks of usage, akin to the right floats' tendency to get
shoved out of the way by other floats.
The update should contain default CSS that leaves
MW acting the way it
before, but with clear instructions somewhere (on
MW.org?) about how to
the CSS to acheive alternative results.
That defeats my purpose in all this, which is to make MediaWiki more
usable out of the box. The idea isn't to write nice custom styles
that people can use if they want. (It's not to force them to use
styles they don't want to use, either, so whatever I do there *will*
be clear instructions on how to reverse it.)
However, I would caution against jumping in and
making visible changes
the wikis themselves as this is an ongoing
discussion working towards a
general solution, and it is not good PR to keep
changing the page
As long as there's ongoing discussion, sure. Once everyone's had
their say, and it's all properly thought out, I don't see any reason
to continue to delay on the pretense that there's more that will be
said. As far as I'm aware, this discussion is the only active one on
the topic, so once nobody's commenting anymore it'll be time to move
Wikitech-l mailing list