"Simetrical" <Simetrical+wikilist(a)gmail.com>
wrote in message
news:7c2a12e20707041224w520d42f3vd585ead4df93fb29@mail.gmail.com...
On 7/4/07, Mark Clements <gmane(a)kennel17.co.uk>
wrote:
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.
If that's the case, then fine. However, currently there are no section divs
(which there should be...).
> 2) It renders well with no CSS (will probably
automatically follow from
the
above)
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
render okay.
That's fine by me.
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.
That's what we need to avoid.
3) It gives us
the flexibility to use CSS to create any of the suggested
layouts.
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.
That sounds promising. I am all too familiar with the nightmare of CSS
juggling, so I am aware that such an ideal solution may not be possible, and
if not then there's nothing we can do about that, but we should definitely
be aiming for it.
> The update should contain default CSS that leaves
MW acting the way it
did
> before, but with clear instructions somewhere (on
MW.org?) about how to
add
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
to
> the wikis themselves as this is an ongoing
discussion working towards a
good
> general solution, and it is not good PR to keep
changing the page
layout...
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
forward.
These paragraphs were a response to your previous post where you said "the
solution I intend to implement is the German style". My point is that there
are other alternatives, and some of them may be better, and until we've
finished discussing them and settled on an optimal visual solution, then it
would be rash to make visible changes such as this on live wikis, as they
may well change again as the result of this discussion.
If you want to start coding anything right now, then it should be the
underlying semantic/HTML changes, but these changes shouldn't alter current
layout. If you plan to implement it all at once after this discussion is
over, then that's fine and there should be no problems making the change. I
think we are in agreement.
- Mark Clements (HappyDog)