obsolete.fax wrote:

thanks

happy.melon.wiki wrote:

Why not just apply the same styles to "div.mw-geshi" as are already applied to pre? That is, wherever we currently have

pre { some-style: value; }

we now get

pre,
div.mw-geshi {

some-style: value;

}

etc. This seems to be what everyone wants...

herd wrote:

(In reply to comment #2)

Why not just apply the same styles to "div.mw-geshi" as are already applied to
pre? That is, wherever we currently have

pre { some-style: value; }

we now get

pre,
div.mw-geshi {

some-style: value;

}

etc. This seems to be what everyone wants...

Read original report for why this isn't easy, and try looking at <pre> in skins other than monobook.

happy.melon.wiki wrote:

(In reply to comment #3)

Read original report for why this isn't easy,

Not seeing it, but I assume you mean that Geshi sometimes outputs more than one stacked div? If so, why is your proposal magically exempt from the same problem? Seems to me that the only difference is that you're suggesting a style that would be the same in all skins, while I'm suggesting that we match the appearance to whatever the skin does with <pre> tags.

and try looking at <pre> in skins other than monobook.

Obviously if the same styles are consistently applied to the mw-geshi div as to pre, then they'll look the same in all skins. "divs produced by Geshi should look the same as <pre> tags in whatever skin you happen to be using" is the ultimate idea, no?

herd wrote:

(In reply to comment #4)

(In reply to comment #3)

Read original report for why this isn't easy,

Not seeing it, but I assume you mean that Geshi sometimes outputs more than one
stacked div?

No, it is because the skins have different methods of styling <pre>. See:

http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=chick
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=standard
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=cologneblue
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=modern
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=monobook
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=myskin
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=nostaliga
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=simple
http://test.wikipedia.org/w/index.php?title=Foo&oldid=75366&useskin=vector

The first two boxes are <pre>, the rest are <source> in various configurations.
Note that Monobook.css on test.wp has (at this time):
div.mw-geshi {padding: 1em; margin:1em 0; border: 1px dashed #2fab6f;}

"divs produced by Geshi should look the same as <pre> tags in whatever
skin you happen to be using" is the ultimate idea, no?

No, because half the skins do not have any borders around <pre>. The "consistent" in the bug summary refers to a hypothetical consistent border for GeSHi output across all skins, not consistency with <pre> in each skin.

happy.melon.wiki wrote:

It seems we're running at 90 degrees here. Why do we want a consistent appearance *between skins*?? That's at best a 'least evil' solution, because what looks good on one skin almost certainly won't look good in another. Geshi produces code blocks, right? We use <source> tags to display syntax-highlighted code blocks, and <pre> to display unhighlighted code blocks. Ergo, why is the old behaviour (where Geshi output mimicked the appearance of standard <pre> blocks) undesirable? If this makes code blocks hard to read in some skins, then we need to review how code blocks are displayed in that skin, full stop, not impose inferior styling on all other skins just for consistency in a direction that users are never going to traverse.

herd wrote:

(In reply to comment #6)

Ergo, why is the old behaviour (where Geshi output mimicked the appearance of
standard <pre> blocks) undesirable?

Because it is unmaintainable in a nice and simple way (like a single line of CSS is).

Say some of those future skins get pre borders, then someone'd have to realize this and go back and add more borders mimicking those new pre borders to the GeSHi extension. Say a new skin comes along, someone has to go add that to the GeSHi css. This will be desynched across versions as well (people using a copy of the extension from a newer or older era, from the SVN for example.

This all seems quite silly, if that is your desire, open your own bug. This bug is about a single consistent and maintainable style across all skins.

happy.melon.wiki wrote:

Make Geshi borders mimic <pre> borders in all skins

There's my implementation. I don't see the validity of much of your argument. Yes there are fourteen additional characters in each skinfile that are redundant if Geshi is not installed on the wiki, but the overall bytecount is still lower than in your implementation because it's not necessary to define any actual *rules*. If a new skin (or an update to an existing skin) creates or introduces divergence, it is entirely because the skinwriter has not done a proper job of looking at what other skins are doing.

This method is not actually mutually-exclusive to yours: there is no reason why we can't also add your line to shared.css, and have the skinwise implementations override it. I still don't see any reason why having a consistent appearance for Geshi code blocks *between skins* is a Good Thing, except to the extent that it's better than doing nothing. Perhaps the best resolution is just to make the extension once again wrap everything in a <pre> tag like it used to, then the synchronisation becomes automatic.

attachment diff.txt ignored as obsolete

(In reply to comment #8)

Perhaps the best
resolution is just to make the extension once again wrap everything in a <pre>
tag like it used to, then the synchronisation becomes automatic.

It specifically removes any formatting added for pre, because it garbled some displays which use multiple pre for each line or so.

herd wrote:

(In reply to comment #8)

Created an attachment (id=6289) [details]
Make Geshi borders mimic <pre> borders in all skins

There's my implementation. I don't see the validity of much of your argument.

And I don't see the validity of yours. What geshi returns isn't a pre, why should it look like one other than for historical nostalgia?

Yes there are fourteen additional characters in each skinfile that are
redundant if Geshi is not installed on the wiki, but the overall bytecount is
still lower...

This isn't about bytecount, this is about maintainability. Copying the styles given to <pre> for all skins for all wikis for all eras would be /very/ annoying.

1. Skin-specific classes are rather recent, but borderless GeSHi has been around for several years, other wikis may wish to update the extension without updating their mediawiki version. So skin-specific hacks would have to go into each MediaWiki:Skinname.xxx for them.
2. Styles change, if the trunk GeSHi extension (which was attempting to mimic all existing pre) was used on an older mediawiki, it may become unmatched. Likewise an older verison of the extension on a newer version of MediaWiki (say, with a new skin) would not match.
3. There isn't any good place to put it, except inline (per GeSHi's lack of any non-inline CSS other than the MediaWiki:Geshi.css). As one line it would be less spammy to the page source (so in this case, it is about byte count).

Per one of my suggestions, this /was/ done at en.wp -> http://en.wikipedia.org/w/index.php?title=MediaWiki:Geshi.css&diff=299560828&oldid=194192714 ... but this, as a single project, is maintainable. Again, if you want this, open a separate bug with a separate goal (as you said, they aren't mutually exclusive). My goal is to get the extension, with newer versions of the backend, to give it any kind of visual border at all.

we can't also add your line to shared.css

Um, GeSHi is an extesion, lets please not go modifying core skin/style files for this. Your patch is completely inappropriate.

happy.melon.wiki wrote:

(In reply to comment #10)

And I don't see the validity of yours. What geshi returns isn't a pre, why
should it look like one other than for historical nostalgia?

This is the core of the problem, IMO. <pre> is used primarily to show code snippets. Geshi is used *entirely* to show code snippets. Semantically, it makes a lot of sense for Geshi's output to be wrapped in a pre. Comment#9 seems to be explaining why this behaviour was changed; can you elaborate, Niklas?

we can't also add your line to shared.css

Um, GeSHi is an extesion, lets please not go modifying core skin/style files
for this. Your patch is completely inappropriate.

There are lines in shared.css from the Cite extension; together with a comment noting that it's horrible and shouldn't be done that way, but it's there nonetheless.

In general I'm concluding that I do not understand why Geshi no longer wraps its output in <pre> tags. Can someone give me a usecase (except for the 'inline' mode, naturally) when having Geshi output formatted in this way (and hence looking like generic <pre> tags) is not a Good Thing?

herd wrote:

This is the core of the problem, IMO. <pre> is used primarily to show code snippets.
Semantically, it makes a lot of sense for Geshi's output to be wrapped in a pre.

No it doesn't. If you want to be semantic, we should be using <code> (see w3.org). While <pre> is for <pre>formatted text.

Can someone give me a usecase...

<source line lang="javascript">
alert('hello');
alert('hello');
alert('hello');
</source>

This puts /each line/ in a <pre>. And faking it, as previously stated, is unmaintainable. Please, go open a separate bug for that (making geshi borders fake a pre style as before, or actually output a <pre>), it will probably be "upstream" though.

For the last time, this bug is about a non-pre omni-skin border. There is plenty of room for a separate bug for your desires. Do I have to open it for you?

happy.melon.wiki wrote:

(In reply to comment #12)

Semantically, it makes a lot of sense for Geshi's output to be wrapped in a pre.

No it doesn't. If you want to be semantic, we should be using <code> (see
w3.org). While <pre> is for <pre>formatted text.

It makes more sense than a semantically-meaningless div. But meh...

This puts /each line/ in a <pre>.

How wierd. However, the current appearance on enwiki seems to be as desired; only the outer border is displayed on FF3.5 at least.

Please, go open a separate bug for that (making geshi borders
fake a pre style as before, or actually output a <pre>), it will probably be
"upstream" though.

For the last time, this bug is about a non-pre omni-skin border. There is
plenty of room for a separate bug for your desires. Do I have to open it for
you?

I'd rather do that than get into more of an argument, certainly. I personally think that it's more important to actually solve the underlying issue ("undesirable lack of borders in Geshi output") than to spend time correctly pidgeonholeing the various ways we could do so. As you say, since they're not mutually exclusive methods, it may be clearer for them to be in separate bugs; although we then lose all the context of the comments above. But meh again...

chinchi29 wrote:

Removing easy keyword.

As of 1.19.0 the output of

<source lang="javascript">
foo();
</source>

Looks like this:

<div dir="ltr" class="mw-geshi mw-content-ltr">
<div class="javascript source-javascript">
<pre class="de1">foo<span class="br0">(</span><span class="br0">)</span><span class="sy0">;</span>
</pre></div>
</div>

But regardless of there being a <pre> element, it has no styling that skins set on pre. Reason being that Geshi's internally generated style block has an overkill reset on selectors like ".javascript.source-javascript .de1".

Easiest solution I can see:

• Instead of wrapping geshi output in <div class="mw-geshi">, wrap it <pre class="mw-geshi">

Geshi's internal reset got even worse after 1.19, bumping priority and re-adding easy keyword per suggested solution at the end of comment 15

Fixed in r113190.

You know the resets are there for a reason. Long time ago our normal pre styling broke badly the geshi output when they interacted.

Afaik they aren't resets but wrappers (at least they are now). They only create an element around all of geshi's output and give that container a style.

• Bug 35029 has been marked as a duplicate of this bug. ***