Re: [Wikitech-l] [Commons-l] Monobook.css update?

List overview All Threads
Download

newer

older

question about Special:Random

Rating Articles Extension

Robert Leverington

15 Jun 2007 15 Jun '07

1:35 p.m.

On 15/06/07, Monahon, Peter B. <Peter.Monahon(a)uspto.gov> wrote:

...

Cary wrote: ... monobook is getting old ... and it's marginally relevant to Wikimedia Commons ... so similar to many of the projects that it's not ... easy to tell that you've moved from one wiki to another ... But not all of us are good at designing skins ... how do we change it while upsetting the least amount of people? I propose ... a contest to come up with a new, more exciting monobook.css ... -C

Peter Blaise responds: I know this is a "commons" discussion list, so my contribution in this thread is specious, but where else should we discuss this ... and you started it! So... Although I agree with much of your observations, I disagree with your conclusions. I suggest that we instead design a new MediaWiki front end to allow the look and feel and function of any MediaWiki element to be customized USING MediaWiki directly through the same interface everyone else uses. ... instead of having to search for and find and hand edit *.css, *.js, *.ini, *.conf, *.php and so on files. I say, do all that programming ONCE, and do it INSIDE a new version of the MediaWiki distribution program. Then let sysops/admins tweak everything to their heart's content from within the MediaWiki program without having to become OS/MySQL/PHP/CSS/and-so-on programming nerds (with NO documentation skills, apparently?!?). You want the commons blue? Make it blue from WITHIN MediaWiki, rather than hand coding a new *.css! I hope my 2 cents catches someone's imagination. I'm not up to either task - customizing MediaWiki using the current resources as a one-off design, nor programming such a modern interface enhancement tool as an upgrade included into MediaWiki. I just want one. And the people I'm trying to get to adopt MediaWiki would really appreciate it. That said, keeping everything as "Wikipedia" as possible makes training and experience with one transferable to any other. "Have you seen Wikipedia?" "Yes." "Well, then, THIS is the exactly same. Dive in and enjoy!" Works for me. In other words, I'm reframing the challenge: rather than adding yet another one-off skin, why not design a "skin designer" and incorporate it right into MediaWiki? ;-) -- Peter Blaise _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l

This idea is very interesting, I can already imagine what this could look like - I am forwarding this to the wikitech-l mailing list so that the people involved in that can also add their ideas. No doubt this would require some nifty JavaScript though. -- Robert http://roberthl.wikitest.co.uk/

Show replies by date

Simetrical

15 Jun 15 Jun

1:51 p.m.

New subject: [Commons-l] Monobook.css update?

On 6/15/07, Robert Leverington <lcarsdata(a)googlemail.com> wrote:

...

> ... instead of having to search for and find and hand edit *.css, *.js, > *.ini, *.conf, *.php and so on files. I say, do all that programming > ONCE, and do it INSIDE a new version of the MediaWiki distribution > program. Then let sysops/admins tweak everything to their heart's > content from within the MediaWiki program without having to become > OS/MySQL/PHP/CSS/and-so-on programming nerds (with NO documentation > skills, apparently?!?). You want the commons blue? Make it blue from > WITHIN MediaWiki, rather than hand coding a new *.css!

You seem to be confusing two issues: the ability to edit styles from within MediaWiki, and the ability to do it without technical know-how. We have the former: you can do a tremendous amount with MediaWiki:Monobook.css, even though no projects that I know of have done more than tiny tweaks. You could, for instance, change background images, fonts, positioning, and so on. If you look at the HTML source, for instance, the navigation sidebar is marked up identically to the content action buttons (talk, edit, history, ...): it's just CSS that distinguishes the two, having one arranged vertically on the left with bullets and the other horizontally on the top in boxes, and that can be changed from within the wiki. The second issue is the knowledge of CSS required to do all this. That part is substantial. If someone wants to design a simple special-page extension that will generate a pretty interface to the CSS, perhaps the Foundation would be interested in enabling it on its wikis. Then again, perhaps not, if it prefers uniformity among its own projects (and I think you can make a strong argument for that -- although all things being equal, I'd guess the Foundation would let its wikis style things however the community wants them). Either way, I'm personally not interested in coding such a thing, but if someone else wants to, they can go ahead.

...

It wouldn't require JavaScript unless you wanted to get really fancy, like letting people drag around interface elements. A simple form allowing entry of various colors, borders, background images, etc. would suffice, with some extra options for moving around stuff like the logo and parts of the sidebar.

Mark Clements

7:31 p.m.

New subject: [Commons-l] Monobook.css update?

On 15/06/07, Monahon, Peter B. <Peter.Monahon(a)uspto.gov> wrote:

...

> Cary wrote: ... monobook is getting old > ... and it's marginally relevant to > Wikimedia Commons ... so similar to > many of the projects that it's not ... > easy to tell that you've moved from one > wiki to another ... But not all of us are > good at designing skins ... how do we > change it while upsetting the least > amount of people? I propose ... a > contest to come up with a new, more > exciting monobook.css ... -C

One interesting thing that the Wikimedia brand survey [1] threw up in my mind, was the use of the MediaWiki skin within Wikimedia projects. The problem is that the interface skin used by WMF projects is also the default skin in the MediaWiki software. This means that there are thousands of wikis out there that look exactly like Wikipedia et al. How is anyone (even an experienced user) supposed to realise that WikiTravel [2] is not a WMF project when it looks exactly like one? I think that the strongest thing we could do to reinforce the brand is to create a new skin that is used by WMF projects _and_only_ WMF projects, which is copyrighted/trademarked (if that is possible) and which is not included as part of the MediaWiki code. Rather than allowing WMF projects to start customising the skin to make them all look different, they should have a WMF skin that makes them all identifiably _related_ (though not necessarily _identical_) and which clearly separates them from the thousands of other unrelated projects that also use monobook. - Mark Clements (HappyDog) [1] http://meta.wikimedia.org/wiki/Wikimedia_brand_survey [2] http://www.wikitravel.org/

Angela

7:48 p.m.

New subject: [Commons-l] Monobook.css update?

...

The problem is that the interface skin used by WMF projects is also the default skin in the MediaWiki software. This means that there are thousands of wikis out there that look exactly like Wikipedia et al. How is anyone (even an experienced user) supposed to realise that WikiTravel [2] is not a WMF project when it looks exactly like one? I think that the strongest thing we could do to reinforce the brand is to create a new skin that is used by WMF projects _and_only_ WMF projects, which is copyrighted/trademarked (if that is possible) and which is not included as part of the MediaWiki code.

One of the most common objections to Wikia's new skins is that they don't look like Wikipedia. To many people wiki=wikipedia and they don't understand why a wiki would not look like that. It's not only an issue of design, but of branding. People associate the monobook skin with a professional, neutral site and they want their wiki to have that same branding. Angela

Rob Church

9:06 p.m.

New subject: [Commons-l] Monobook.css update?

On 16/06/07, Angela <beesley(a)gmail.com> wrote:

...

don't look like Wikipedia. To many people wiki=wikipedia and they don't understand why a wiki would not look like that. It's not only an

The "wiki" == "wikipedia" thing is a bigger problem, of course. :)

...

issue of design, but of branding. People associate the monobook skin with a professional, neutral site and they want their wiki to have that same branding.

Ick. Too many goddamn wikis using Monobook these days. Where's the creativity? Rob Church

Mark Clements

10:04 p.m.

New subject: [Commons-l] Monobook.css update?

"Rob Church" <robchur(a)gmail.com> wrote in message news:e92136380706151806u7193ecffub4de3411b48285c2@mail.gmail.com...

...

On 16/06/07, Angela <beesley(a)gmail.com>

wrote:

...

don't look like Wikipedia. To many people wiki=wikipedia and they don't understand why a wiki would not look like that. It's not only an

The "wiki" == "wikipedia" thing is a bigger problem, of course. :)

issue of design, but of branding. People associate the monobook skin with a professional, neutral site and they want their wiki to have that same branding.

Ick. Too many goddamn wikis using Monobook these days. Where's the

creativity?

...

Well, monobook looks pretty good. It's a nice layout and easy to navigate. I remember the excitement when it was introduced - suddenly we look like a proper website, rather than a relic from arpanet. Given that monobook is the only skin in MediaWiki that looks even slightly professional and modern, and given that it isn't particularly obvious how to create a new skin, it is no wonder that it is so prevalent. For the general public that use MediaWiki (i.e. non-WMF sites) some kind of style editor as described here would be a great tool and would hopefully alleviate the monotonybook woes. I'm not sure what, if any, benefit it has to WMF though. However, I think if WMF introduced a _very good_ new skin for their wikis then it would only be a positive thing! It shouldn't be a big departure though - same basic page layout, but new imagery/colours. - Mark Clements (HappyDog)

Kasimir Gabert

10:13 p.m.

New subject: [Commons-l] Monobook.css update?

To copyright and then lock up a skin on a wiki, specifically one released under the GPL, is very silly. I feel that if that were to happen, many people would lose faith in Wikipedia and in wikis as a whole. Kasimir On 6/15/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:

...

"Rob Church" <robchur(a)gmail.com> wrote in message news:e92136380706151806u7193ecffub4de3411b48285c2@mail.gmail.com...

On 16/06/07, Angela <beesley(a)gmail.com>

wrote:

don't look like Wikipedia. To many people wiki=wikipedia and they don't understand why a wiki would not look like that. It's not only an

The "wiki" == "wikipedia" thing is a bigger problem, of course. :)

issue of design, but of branding. People associate the monobook skin with a professional, neutral site and they want their wiki to have that same branding.

Ick. Too many goddamn wikis using Monobook these days. Where's the

creativity?

-- Kasimir Gabert

Mark Clements

16 Jun 16 Jun

6:46 a.m.

New subject: [Commons-l] Monobook.css update?

"Kasimir Gabert" <kasimir.g(a)gmail.com> wrote in message news:52836a540706151913r43b7f0d6v5b73372ba47cd7@mail.gmail.com...

...

On 6/15/07, Mark Clements <gmane(a)kennel17.co.uk>

wrote:

...

> "Rob Church" <robchur(a)gmail.com> wrote in > message

news:e92136380706151806u7193ecffub4de3411b48285c2-JsoAwUIsXouq+1Nelnf3ueG/Ez 6ZCGd0(a)public.gmane.org

...

> > On 16/06/07, Angela <beesley(a)gmail.com> > wrote: > > > don't look like Wikipedia. To many people wiki=wikipedia and they > > > don't understand why a wiki would not look like that. It's not only

...

> > > > The "wiki" == "wikipedia" thing is a bigger problem, of course. :) > > > > > issue of design, but of branding. People associate the monobook skin > > > with a professional, neutral site and they want their wiki to have > > > that same branding. > > > > Ick. Too many goddamn wikis using Monobook these days. Where's the > creativity? > > > > Well, monobook looks pretty good. It's a nice layout and easy to

navigate.

...

> I remember the excitement when it was introduced - suddenly we look like

...

> proper website, rather than a relic from arpanet. > > Given that monobook is the only skin in MediaWiki that looks even

slightly

...

> professional and modern, and given that it isn't particularly obvious

how to

...

> create a new skin, it is no wonder that it is so prevalent. For the

general

...

> public that use MediaWiki (i.e. non-WMF sites) some kind of style editor

...

> described here would be a great tool and would hopefully alleviate the > monotonybook woes. I'm not sure what, if any, benefit it has to WMF

though.

...

> > However, I think if WMF introduced a _very good_ new skin for their

wikis

...

then it would only be a positive thing! It shouldn't be a big departure though - same basic page layout, but new imagery/colours. - Mark Clements (HappyDog)

Well, whether to copyright it or not is a decision for the WMF to make. As you say, it may not be sensible to do this, although I think your doom and gloom prohpecy is perhaps taking it a bit far (after all, the WMF logo is trademarked, and nobody seems to care about that...). The important point is that the skin should not be included in the MediaWiki software, as is currently the case. - Mark Clements (HappyDog)

Stephen Bain

15 Jun 15 Jun

10:56 p.m.

New subject: [Commons-l] Monobook.css update?

On 6/16/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:

...

Given that monobook is the only skin in MediaWiki that looks even slightly professional and modern, and given that it isn't particularly obvious how to create a new skin, it is no wonder that it is so prevalent. For the general public that use MediaWiki (i.e. non-WMF sites) some kind of style editor as described here would be a great tool and would hopefully alleviate the monotonybook woes. I'm not sure what, if any, benefit it has to WMF though.

You can customise the skin using CSS and JS, but to create a completely new skin you need to actually put that into the PHP that the wiki runs. It's not terribly difficult for someone with a working knowledge of PHP and HTML, but the necessity of putting things into the codebase puts it out of the reach of most people. There are some instructions on how to make a skin on Meta: http://meta.wikimedia.org/wiki/Skins On 6/16/07, geni <geniice(a)gmail.com> wrote:

...

Given commons very different role from classic wiki projects I don't see quite the same level of problems with using a different style.

A new interface for Commons might make up for some of the features that Commons users have on their wishlist for MediaWiki. You could make Commons look and work more like Flickr, for example, without really changing the software. On 6/16/07, Monahon, Peter B. <Peter.Monahon(a)uspto.gov> wrote:

...

I suggest that we instead design a new MediaWiki front end to allow the look and feel and function of any MediaWiki element to be customized USING MediaWiki directly through the same interface everyone else uses.

Jim Wilson

11:23 p.m.

New subject: [Commons-l] Monobook.css update?

It probably goes without saying that this functionality could be implemented entirely via an extension. Elements: 1. SpecialPage to show and process the form (locked for use only by Sysops) 2. Storage location for values reaped form the from (probably an article in the MediaWiki namespace) 3. Hook into 'SkinTemplateSetupPageCss' to add a <style> tag with values from storage location So in the form you might have a textbox asking for "body color". On save this might be stored in the Msg article as "bodycolor=#xxx". Finally, the hook reads the Msg and renders out: <style type="text/css">body { color: #xxx } </style> Simple! Then it just becomes a matter of determining which styles deserve to be represented in this manner. -- Jim R. Wilson (jimbojw) On 6/15/07, Stephen Bain <stephen.bain(a)gmail.com> wrote:

...

On 6/16/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:

Given that monobook is the only skin in MediaWiki that looks even

slightly

professional and modern, and given that it isn't particularly obvious

how to

create a new skin, it is no wonder that it is so prevalent. For the

general

public that use MediaWiki (i.e. non-WMF sites) some kind of style editor

described here would be a great tool and would hopefully alleviate the monotonybook woes. I'm not sure what, if any, benefit it has to WMF

though. You can customise the skin using CSS and JS, but to create a completely new skin you need to actually put that into the PHP that the wiki runs. It's not terribly difficult for someone with a working knowledge of PHP and HTML, but the necessity of putting things into the codebase puts it out of the reach of most people. There are some instructions on how to make a skin on Meta: http://meta.wikimedia.org/wiki/Skins On 6/16/07, geni <geniice(a)gmail.com> wrote:

Given commons very different role from classic wiki projects I don't see quite the same level of problems with using a different style.

There's lots of work going on/being planned behind the scenes in MediaWiki, with the development of the API, and large structural changes to the way the software works. Eventually it will be possible to have completely independent UIs that will plug into a wiki through the API. -- Stephen Bain stephen.bain(a)gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

Tim Starling

11:42 p.m.

New subject: [Commons-l] Monobook.css update?

Mark Clements wrote:

...

One simple improvement would be to allow CSS/JS-only skins. The idea would be to get rid of the need to create a PHP skin file entirely, maybe you could just have a simple skin description file in the base skins directory. Then we could grab the whole [[m:Gallery of user styles]], put it into MediaWiki, and add an installer option to select a default skin from it. -- Tim Starling

Rob Church

11:46 p.m.

New subject: [Commons-l] Monobook.css update?

On 16/06/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

It would clean up a horrible bloody mess, wouldn't it? Rob Church

Edward Z. Yang

16 Jun 16 Jun

12:04 a.m.

New subject: [Commons-l] Monobook.css update?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Church wrote:

...

It would clean up a horrible bloody mess, wouldn't it?

It certainly would (tremendously improves forwards-compatibility). But it also means that bad designers can't muck up MediaWiki with table-based layouts. ;-)

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGc2E/qTO+fYacSNoRAlUEAJ9LLbBqUsUoDdvjRS1jVc1lTIvW4QCfaoSY 2wDUgBS/JE1lOz3J9czBKwU= =LKBP -----END PGP SIGNATURE-----

Jim Wilson

1:50 a.m.

New subject: [Commons-l] Monobook.css update?

I'm as much into CSS as the next guy, but there are things you just can't do with CSS alone - and using JavaScript for element placement is objectionable. For example, #p-personal appears earlier in #column-one than say #p-navigation (and any other sidebars). If you wanted to keep #p-personal as a standard portlet, but listed _last_ in the column, the only way to do this (afaik) is to reorder the HTML elements (either before page load - as in the current system - or via JavaScript). -- Jim On 6/15/07, Edward Z. Yang <edwardzyang(a)thewritingpot.com> wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Church wrote:

It would clean up a horrible bloody mess, wouldn't it?

It certainly would (tremendously improves forwards-compatibility). But it also means that bad designers can't muck up MediaWiki with table-based layouts. ;-)

...PGP SIGNATURE...

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

elisabeth bauer

10:48 a.m.

New subject: [Commons-l] Monobook.css update?

2007/6/16, Tim Starling <tstarling(a)wikimedia.org>rg>:

...

Getting rid of the PHP skin files would be fantastic - I am working on a new skin atm and I am using a really dirty Javascript hack to be able to test the skin live on Wikipedia (myskin.css is too restricted in many ways). But I am missing in this debate so far on thing: a new skin is not required just for reasons of prettiness or to have wikimedia projects look different from mediawiki default installations - the main reason for a new skin for me is usability. Over time mediawiki got lots and lots of new features added, new messages added to the interface and all of these were placed somewhere just where space was. * Why is the version history, providing information about an article placed in a tab over the article, while cite and and print appear in the sidebar? * Special:Specialpages consists now of an unseparated list of over 50 links. usability research has found out that people had difficulties scanning lists with more than 11 list items without subheadings. * active wikipedia contributors have enhanced their skins with lots of useful javascript actions and navigation links they don't want to live without anymore - but there's no room provided in the default skins for additional navigation and action links (see for example http://de.wikipedia.org/wiki/Bild:Monobook.js-quickbarbox.png - favourite skin extension of german wikipedians which usually replaces the logo). * some articles already contain several template boxes on top, add then occasionally the sitemessage box and in the near future one more box "This is the stable version blabla..two lines more". We'll end up with one full screen of messages before the actual content of the page. * The bottom of the editing dialogue in english wikipedia looks like this now: http://commons.wikimedia.org/wiki/Image:Editdialogmess.png - honestly, who is going to find the important stuff in this? Does it look nice and professional? A new Mediawiki skin should provide an uncluttered interface for people who just want to read articles (or look at pictures). Basic Wiki editing should be simple and newbie friendly. And it should be easily extensible with special functions for hard core users. These are the three challenges I see. Some problems can be solved on the development level (like getting rid of PHP skins and providing easy skin development possibilities on wiki, the specialpages problem and clutter of the interface messages). Some can be solved by a skin designer skilled in usability. Some have to be solved by the project communities, reducing the clutter of maintenance messages, weighing their importance and standardizing their design. For the rest you need a politician (for convincing 500 project communities of a new skin and adopting it). I'll work on the skin level, any help welcome. greetings, elian

Stephen Bain

10:56 a.m.

New subject: [Commons-l] Monobook.css update?

On 6/17/07, elisabeth bauer <eflebeth(a)googlemail.com> wrote:

...

Have you considered using a local install of MediaWiki for testing purposes?

...

I'll work on the skin level, any help welcome.

I'm happy to help too, it's just a matter of finding out exactly what people want from the interface. -- Stephen Bain stephen.bain(a)gmail.com

Jim Wilson

12:22 p.m.

New subject: [Commons-l] Monobook.css update?

Hi all, Quick question: should a MediaWiki page look the same in the same browser with and without javascript support? I think it should, and any talk of pure CSS/JS skins tacitly assumes that all visitors whose browsers support CSS must therefore also support JavaScript. This is a false assumption. I'm not trying to rain on everyone's parade here - this is a real concern. The truth is that it's possible TODAY to make "pure CSS/JS" skins. Just hack up Monobook.css and Monobook.js to do whatever you like. All the CSS styles applied in MW can be undone by later styles, and DOM elements can be swapped around at will in the JS. </technicalRant> On the idea of a contest, I think this is a great option - I'd hate to see the new skin designed by committee. -- Jim R. Wilson (jimbojw) On 6/16/07, Stephen Bain <stephen.bain(a)gmail.com> wrote:

...

On 6/17/07, elisabeth bauer <eflebeth(a)googlemail.com> wrote:

Have you considered using a local install of MediaWiki for testing purposes?

I'll work on the skin level, any help welcome.

I'm happy to help too, it's just a matter of finding out exactly what people want from the interface. -- Stephen Bain stephen.bain(a)gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

Rob Church

1:37 p.m.

New subject: [Commons-l] Monobook.css update?

On 16/06/07, Jim Wilson <wilson.jim.r(a)gmail.com> wrote:

...

Quick question: should a MediaWiki page look the same in the same browser with and without javascript support?

I think it's very important to remember that MediaWiki is a product which is used in thousands of installations across the world, to power the collaborative editing and information sharing needs of a wide variety of organisations, from fan projects to schools, colleges and universities, to whacking great big, well-known companies such as Intel and Novell. With that, I think it's imperative that the software does not rely upon CSS or JavaScript to do anything "important" with respect to content and the page overall, in other words, skins would have to degrade gracefully. Rob Church

Mark Clements

18 Jun 18 Jun

3:14 p.m.

New subject: [Commons-l] Monobook.css update?

"Rob Church" <robchur(a)gmail.com> wrote in message news:e92136380706161037v50341f7cxf1effc3c56642975@mail.gmail.com...

...

Slight tangent here... The traditional stance has always been "MediaWiki is software written to run Wikimedia projects". If you want to use it for other purposes then fine, but we're not going to add features that aren't useful to WMF (particularly in relation to access-restrictions and the user/group model). What you're saying here seems to be the opposite of that. I am confused! - Mark Clements (HappyDog)

David Gerard

4:04 p.m.

New subject: [Commons-l] Monobook.css update?

On 18/06/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:

...

"Rob Church" <robchur(a)gmail.com> wrote in message news:e92136380706161037v50341f7cxf1effc3c56642975@mail.gmail.com...

...

> I think it's very important to remember that MediaWiki is a product > which is used in thousands of installations across the world, to power > the collaborative editing and information sharing needs of a wide > variety of organisations, from fan projects to schools, colleges and > universities, to whacking great big, well-known companies such as > Intel and Novell.

...

Different devs contribute to MediaWiki for different reasons. - d.

GerardM

19 Jun 19 Jun

4:58 a.m.

New subject: [Commons-l] Monobook.css update?

Hoi, The traditional stance "MediaWiki is software written to run Wikimedia projects" is no longer based in facts, multiple other organisations have extended the MediaWiki software. Do not be confused, MediaWiki has an application far wider than just the Wikimedia Foundation projects. Thanks, GerardM On 6/18/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:

...

"Rob Church" <robchur(a)gmail.com> wrote in message news:e92136380706161037v50341f7cxf1effc3c56642975@mail.gmail.com ...

Stephen Bain

8:41 a.m.

New subject: [Commons-l] Monobook.css update?

On 6/19/07, Mark Clements <gmane(a)kennel17.co.uk> wrote:

...

"Rob Church" <robchur(a)gmail.com> wrote in message news:e92136380706161037v50341f7cxf1effc3c56642975@mail.gmail.com...

Well, taking the position that we won't add major features to the core that aren't used by the Wikimedia projects doesn't also entail that we won't have regard to other users of the software when making significant changes that may break things for them :) I think that's more what Rob was getting at, since he was replying to a message about making basic functionality dependent on CSS and JS. -- Stephen Bain stephen.bain(a)gmail.com

Platonides

16 Jun 16 Jun

5:37 p.m.

New subject: [Commons-l] Monobook.css update?

Jim Wilson wrote:

...

Hi all, Quick question: should a MediaWiki page look the same in the same browser with and without javascript support?

It should, but our Wiki*edias are full of JS hacks ;)

...

I'm not trying to rain on everyone's parade here - this is a real concern. The truth is that it's possible TODAY to make "pure CSS/JS" skins. Just hack up Monobook.css and Monobook.js to do whatever you like. All the CSS styles applied in MW can be undone by later styles, and DOM elements can be swapped around at will in the JS.

That's the power of monobook.js But shouldn't be required to get the _right_ view.

Mark

19 Jun 19 Jun

4:14 a.m.

New subject: [Commons-l] Monobook.css update?

Mark Clements wrote:

...

At one point I had done this to illustrate how far we could go with just CSS and a couple of javascript tweaks. http://mark.sdf-eu.org/wikitravel/Lausanne.html Note that there are actually 4 skins here and you can switch between them with a little javascript. The one-column thing is meant to be for PDAs. It works out of course that other programming priorities got in the way of implementing the skin. I've discovered the same thing with my own site: http://wikevent.org I can barely keep up with the work I'm doing on extensions. Reskinning it is imporantant, but I have to make the site basically work before anybody's going to dream of using it. -mark -- -- ================================================================= -- mark at geekhive dot net --

Thomas Dalton

15 Jun 15 Jun

7:47 p.m.

New subject: [Commons-l] Monobook.css update?

Any way of customising the skin without directly editing the CSS would be extremely limited. If you make a list of things you would like to be easily customisable, it shouldn't be difficult to knock up a special page to do it. However, you would probably have to choose between customising via the special page *or* by the CSS - I can't think of a practical way to merge customisations from both (except for using the special page as a starting point and then editing the CSS, but you would lose any edits to the CSS if you changed anything on the special page later on).

Platonides

16 Jun 16 Jun

12:45 p.m.

New subject: CSS extension was: Monobook.css update?

There's no need to add a message for each property. We have <extensionname>.css :) What could be added with an extension is a system to take the CSS customizing to the mere mortals: -Click on any part of the interface to customize it. -Comboboxes and textboxes for choosing different colors, sizes, styles... -You have chosen this code <CSS code> -Preview it -Test with article foo -Save to my custom stylesheet -Add to my custom stylesheet Per user stylesheets have a apply-on-preview feature, but even with that, CSS editing is hard. Lots of text, properties and values to mistype, with a continous need to preview how-it-goes. Overlappings, not-on-the-place-i-wanted, z-index it, changing this, reposisitions the whole layout... We should give Wikipedia in a console terminal, not in a web page :D Thomas Dalton wrote:

...

Jim Wilson wrote:

...

It probably goes without saying that this functionality could be

implemented

...

entirely via an extension. Elements: 1. SpecialPage to show and process the form (locked for use only by

Sysops)

...

2. Storage location for values reaped form the from (probably an

article in

...

the MediaWiki namespace) 3. Hook into 'SkinTemplateSetupPageCss' to add a <style> tag with values from storage location So in the form you might have a textbox asking for "body color". On save this might be stored in the Msg article as "bodycolor=#xxx".

Finally, the

...

hook reads the Msg and renders out: <style type="text/css">body { color: #xxx } </style> Simple! Then it just becomes a matter of determining which styles

deserve to

...

be represented in this manner. -- Jim R. Wilson (jimbojw)

Jim Wilson

12:56 p.m.

New subject: CSS extension was: Monobook.css update?

...

There's no need to add a message for each property. We have <extensionname>.css :)

Yes. The reason why I suggested a message page to house all the properties (not one for each, I think that would be overkill) is that CSS is the output format in this case. If you store the data as CSS, then the editor (gui as you suggest - which is nice, or special page) is responsible for parsing out that CSS in a meaningful way so as to populate the gui components. It's the same problem as the wikitext/html dynamic. You store the wikitext and generate the html. As to your other ideas, like the JS/gui method of specification: very nice! -- Jim R. Wilson (jimbojw) On 6/16/07, Platonides <Platonides(a)gmail.com> wrote: >

...

There's no need to add a message for each property. We have <extensionname>.css :)

> > What could be added with an extension is a system to take the CSS > customizing to the mere mortals: > -Click on any part of the interface to customize it. > -Comboboxes and textboxes for choosing different colors, sizes, styles... > -You have chosen this code <CSS code> > -Preview it > -Test with article foo > -Save to my custom stylesheet > -Add to my custom stylesheet > > Per user stylesheets have a apply-on-preview feature, but even with > that, CSS editing is hard. Lots of text, properties and values to > mistype, with a continous need to preview how-it-goes. Overlappings, > not-on-the-place-i-wanted, z-index it, changing this, reposisitions the > whole layout... > > We should give Wikipedia in a console terminal, not in a web page :D > > > Thomas Dalton wrote: > > Any way of customising the skin without directly editing the CSS would > > be extremely limited. If you make a list of things you would like to > > be easily customisable, it shouldn't be difficult to knock up a > > special page to do it. However, you would probably have to choose > > between customising via the special page *or* by the CSS - I can't > > think of a practical way to merge customisations from both (except for > > using the special page as a starting point and then editing the CSS, > > but you would lose any edits to the CSS if you changed anything on the > > special page later on). > > Jim Wilson wrote: > > It probably goes without saying that this functionality could be > implemented > > entirely via an extension. > > > > Elements: > > 1. SpecialPage to show and process the form (locked for use only by > Sysops) > > 2. Storage location for values reaped form the from (probably an > article in > > the MediaWiki namespace) > > 3. Hook into 'SkinTemplateSetupPageCss' to add a <style> tag with values > > from storage location > > > > So in the form you might have a textbox asking for "body color". On > save > > this might be stored in the Msg article as "bodycolor=#xxx". > Finally, the > > hook reads the Msg and renders out: > > > > <style type="text/css">body { color: #xxx } </style> > > > > Simple! Then it just becomes a matter of determining which styles > deserve to > > be represented in this manner. > > > > -- Jim R. Wilson (jimbojw) > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > http://lists.wikimedia.org/mailman/listinfo/wikitech-l >

Simetrical

10:07 p.m.

New subject: [Commons-l] Monobook.css update?

On 6/15/07, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:

...

Not at all! CSS is "cascading" for a reason. :) Just have the GUI-generated stuff inserted in the generated style after the defaults but before Monobook.css. On 6/16/07, Platonides <Platonides(a)gmail.com> wrote:

...

Jim Wilson wrote:

Hi all, Quick question: should a MediaWiki page look the same in the same browser with and without javascript support?

It should, but our Wiki*edias are full of JS hacks ;)

I've been thinking about MediaWiki:Common.xsl. Who's with me? :D (Of course, we'd need to produce valid XHTML first . . .)

Edward Z. Yang

10:32 p.m.

New subject: [Commons-l] Monobook.css update?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simetrical wrote:

...

I've been thinking about MediaWiki:Common.xsl. Who's with me? :D (Of course, we'd need to produce valid XHTML first . . .)

XSLT is a Turing-complete language, and support for XSL in browsers is patchy at best, so that would mean executing arbitrary code on Wikimedia servers. Granted, it's difficult to write bad XSLT, but I don't think it's going to happen. Although, MediaWiki is now PHP 5, which offers quite a good array of XML processing APIs.

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdJ0wqTO+fYacSNoRAuSCAJ9fdOkIC2OCbsRd8Uf8ehVUN6hysgCghK3c oSADyh1U56C/GJrrmliu7UU= =+4kE -----END PGP SIGNATURE-----

Simetrical

10:59 p.m.

New subject: [Commons-l] Monobook.css update?

On 6/16/07, Edward Z. Yang <edwardzyang(a)thewritingpot.com> wrote:

...

XSLT is a Turing-complete language, and support for XSL in browsers is patchy at best, so that would mean executing arbitrary code on Wikimedia servers.

Well, technically yes, in the same way that I could probably build a Turing-complete programming language on top of MediaWiki's responses to HTTP requests. That would be "executing arbitrary code" too. Templates are Turing-complete too, if you neglect the unusually low code length limit (people always neglect that computers are finite-state anyway, right?). The issue with running arbitrary code is the I/O and possibly performance, not the code execution per se. The only thing to worry about would be if this uses up too much resources. It wasn't a really serious suggestion anyway. :) If we wanted to do something like that, it should be via a more conventional templating system, like maybe along the lines of MediaWiki:Sidebar: * content column ** site notice ** first heading ** body content *** site subtitle *** content subtitle *** jump-to navigation *** page content ** print footer * navigation column ** content actions *** main article *** discussion *** edit *** history *** watch *** protect *** delete ... Most of that could be sanely reordered to your heart's content.

Robert Leverington

17 Jun 17 Jun

1:50 a.m.

New subject: [Commons-l] Monobook.css update?

On 17/06/07, Simetrical <Simetrical+wikilist(a)gmail.com> wrote:

...

On 6/16/07, Edward Z. Yang <edwardzyang(a)thewritingpot.com> wrote:

XSLT is a Turing-complete language, and support for XSL in browsers is patchy at best, so that would mean executing arbitrary code on Wikimedia servers.

I say Simetrical's idea is good - please make it :D (at least as an extension if nothing else). -- Robert http://roberthl.wikitest.co.uk/

6155

days inactive

6159

days old

wikitech-l@lists.wikimedia.org

Manage subscription

30 comments

16 participants

tags (0)

participants (16)

Angela
David Gerard
Edward Z. Yang
elisabeth bauer
GerardM
Jim Wilson
Kasimir Gabert
Mark
Mark Clements
Platonides
Rob Church
Robert Leverington
Simetrical
Stephen Bain
Thomas Dalton
Tim Starling