Talk:Main Page/main-05

From Ganfyd

Jump to: navigation, search


Ladies and gentlemen

We are doing well, there are a lot of pages, many of them are good or excellent and none that I have noticed are actually bad. We have reached this point without having a row, whether as a community, or even between two of us over some topic of medicine or the arrangement of one or more pages. I am impressed. Surprised would be stretching it, even if I took Dr Johnson's example and said "astonished" instead, because it is clear that people joining this project are doing so out of laudable motives, becoming famous and respected in the distant future being either irrelevant or a mere byproduct, and keeping our egos tucked away for later.

It is a pleasure to be part of this community. Midgley 20:04, 22 March 2006 (CET)

Agree Mlj 00:33, 23 March 2006 (CET)

Yes, it's great isn't it! --Penglish 10:49, 23 March 2006 (CET)


"In Plato's dialogue the Theaetetus, Socrates considers a number of definitions of knowledge. One of the prominent candidates is justified true belief. We know that for something to count as knowledge it must be true and be believed to be true (see section on defining belief in Epistemology, below). Socrates argues that this is insufficient; in addition one must have a reason or justification for that belief." From Wikipedia:knowledge

We are trying to provide, or arrange for people to have, knowledge.

It occurs to me that NHS and other utterances rather often do not include the basis for belief, the reason, and thus may be less powerful in transmitting knowledge than may be desirable.

The other thing defined in the run-up to the NeLH was "know-how" which is not quite the same thing. I think to transmit know-how one needs multimedia or very descriptive writing. It may be less what we are about, but I'd hope we may do some of it. Midgley 20:02, 23 March 2006 (CET)

<---Archived entries from here to Talk:Main Page/main-04 ---->

Etymology template


Good idea, Mark. I got stuck thinking of an icon because I think a dictionary will look like any other book. Anyway, I tend to get my information from the OED online, which I doubt will ever be printed again. OTOH, I couldn't think of a better icon so my suggestion is this box. It should definitely be called Template:EtymologyBox. Btw everyone, I passed my resit! Hooray! Rupert (Talk) 13:33, 14 September 2006 (BST)

We already have Category:Medical etymology, but the problem is that the category applies to the whole article, so not clear which part of the article has the etymology element to it.
I would quite like an etymology template - it would be easier specifically search instances of where it has been used in the article. It could be otherwise identical to the InterestBox, but with a different colour and icon. Any ideas for an icon - a dictionary or book, perhaps? Mark ong 22:56, 13 September 2006 (BST)

Rendering issues in IE 6.0

I have found three rending issues with IE 6.0.2900.2180 XP sp2 in one day. No wonder they need IE 7. The first I noticed earlier today was when I modified Impaired glucose tolerance on a workstation at work and it didn't display correctly the beneficial template. Had time just now to confirm my work laptop also has the display problem and find 2 other rendering issues. Everything is fine in Firefox and Konqueror. The template code uses the span element. What is clearly happening is that the background colour #D4FFBF is written over the CSS external text class outside the range of the span element. Doesn't seem to be a known wikimedia bug with IE 6.0 but looks to me to be because in IE the hover style of the link itself must contain certain CSS declarations like resetting the background. The relevant HTML is <a href="" class='external text' title="" rel="nofollow"><span style="background:#D4FFBF;color:#1ECF00;font-weight: bold;">beneficial</span></a>. which of course is fine and legal. The other bugs incidently were a floating categories box on the page on propranolol and failure to render icon transperancy on the Warning box icon. Anyone got IE 7.0 out there to see if they have fixed these bugs. Mlj 23:28, 18 September 2006 (BST)

Shall we make a firm recommendation on browser? I'm a bit wary of appearing browser-specific, but neither is this a good week to be using any sort of IE. (another vulnerability disclosed and awaiting a patch) Midgley 06:50, 19 September 2006 (BST)
Actually I think in that case, IE is doing the right thing - the span is within the link, so the span's background overrides the link's. Whether or not that is correct behaviour though, it is clearly a bug that it doesn't work the other way round when the link is within the span. By the way, I believe IE 7 has full support for the PNG specification, so that'll be nice. (The full-alpha will be good for those icons in boxes.) Something that would be great is if MediaWiki supplied a non transparent image with a background of the right colour for browsers with poor PNG support. I might be able to code this one day. Finally, I'm very strongly against making a browser recommendation. If our content is not displaying well on some browsers, I think we're doing something wrong - fancy presentation is great but usability is more important I think. I don't just mean for the "readers" either. Since producing the etymology templates recently, I have been worrying at how steep the learning curve for new contributors must be - I sometimes struggle to make heads or tails of wikitext, and I'd like to think I've got my eye in by now. Rupert (Talk) 09:30, 19 September 2006 (BST)
Disagree would use <a href="whatever">This is normal text<span style="whatever">abnormal text</span>This is again normal text</a> as span is an inline element. Anchors can have their own style attribute and of course we set this all the time in CSS . So <a href="whatever" style="color:green">te<span style="background:#D4FFBF;color:orange">s</span>t</a> does exactly what I want it to do even in IE 6.0 (the annoyance of booting my laptop into XP just to check was minimal as I have to do some Access work now)Mlj 21:44, 19 September 2006 (BST)
You've convinced me. Annoying that putting a thin space between the closing span and a tags doesn't work. That's bugtastic too. Rupert (Talk) 22:20, 19 September 2006 (BST)
Lets look for a newbie, and use them to pilot advice to newbies including the important fact that we like plain ordinary text, and probably enjoy the opportunity to tart it up after they write it ... We could do with a welcome template along the WP lines, but probably narrower in scope. Midgley 12:36, 19 September 2006 (BST)

Scary wikitext

My suggestion for making ganfyd's wikitext less scary: Enable subpages in the main article space. Then confine scary sections like tables with lots of data and the more intimidating templates to subpages. Then transclude the subpage. So for the page Article, a table might be in Article/Table 1 and that can be inserted into the main page by the code {{/Table 1}}, which looks rather elegant compared to having the whole table, I think. I wouldn't suggest systematically refactoring pages in this way, but just starting to do it at sensible opportunities. A problem is that subpages are not normally moved with their parents, but I could see about coding that. Also, for some reason I wouldn't want to see links to subpages, but once the subpage feature was enabled it'd probably happen. (I guess the reason is I wouldn't want to see whole articles on the same footing as a box. Call me anal.) Rupert (Talk) 09:46, 19 September 2006 (BST)

I like that. A problem is that categories were introduced to WP (and hence MW) to take over from subpages, and therefore the continuing development of tools for subpages in MW might be less than certain. Against that, there is much use of subpages in the project space (as distinct from the main text space) in WP, so I think it will carry on being useful. Some tables will turn out to be re-used in more than one page, and thus may get either complicated chaining or redirects, but I think we can live with that. I'd be wary of transcluding tables into tables into articles, as one can get lost if there are too many layers of indirection (I think the software can handle it, it is the people that crash). 12:30, 19 September 2006 (BST)
That's a new piece of MediaWiki history for me, Adrian - Now that you have said it, I can see that subpages (being a way of organising pages into a hierarchial structure) can offer some of the functionality of categories but I did not know they were ever used that way. I'd quite like to enable subpages on an "include only" basis, not that that exists. It would help keep reserve them for what I have been talking about, rather than opening the floodgates for all kinds of uses. Rupert (Talk) 13:57, 19 September 2006 (BST)
Have a look around WP: requsts for comment and requests for arbitration and AFD, there is something that generates a new included page there. Not quite what you want. It may be best that we do this as a complicated job after the basis has been done in one page. Midgley 17:35, 19 September 2006 (BST)
Any potentual for subpages to include information with a sell by date as per Talk:Influenza? Mlj 21:12, 19 September 2006 (BST)
No more so than any other page. We can look at adding that feature separately. I'm experimenting with a template solution that I fully don't expect to work. Whatever the solution, it will need syntax, so it would be good if it could be refactored into a subpage. Also, if it is a per page solution, subpages will permit finer granularity. Rupert (Talk) 22:08, 19 September 2006 (BST)
A quick and simple way to de-scarify pages without all that tinkering (guaranteed to scare off all but the most persistent technophiles) is to ensure that if you do use tables, etc that they are contained within their own section of the page so that the bits people want to edit can be done from the small link for each of the other sections and all the table code magically disappears. Most understandable way of dealing with sell-by data would probably be a category to which pages due for review could be added (?bot needed).--Manville 22:25, 19 September 2006 (BST)
Hmmmm. Section editing can't help with something like a complicated box. It's the non-technophiles, I'd like to make things easier for. Do you not think it's worth it? Rupert (Talk) 22:33, 19 September 2006 (BST)
The use of subpages to clear table data and templates off the main editing window would be really useful provided it was easy to get to them for editing. Editing tables is always going to be a bti daunting for newbies because of the translation from grid to lines of text until someone writes a highly complex (probably java applet) that will create tables by just typing in the appropriate box.--Manville 22:57, 19 September 2006 (BST)
OK. Have to think about how to add extra edit links. Rupert (Talk) 23:04, 19 September 2006 (BST)
I just enabled subpages in the main namespace. —Rupert (Talk) 14:44, 15 October 2006 (BST)
Presumably that just means that we now can use the syntax MainPageName/SubPage and ../SubPage etc. It doesn't mean the MainPage will automatically include the content of the subpage. You have to follow the link. If so limited the main use will be where article gets too long, rather than removing scary to edit tables. Or have I missed something about subpages in wikimediaMlj 18:14, 15 October 2006 (BST)
Well it's possibly my fault for not explaining it properly. Firstly, you can call pages whatever you want, and they can include slashes in them. Secondly, you can transclude any page from any other page using {{XXX}}. What subpages add is just the convenience of in (say) the page Article, going {{/Table1}} to transclude Article/Table1. See hepatopancreatic ampulla for an example. —Rupert (Talk) 22:47, 15 October 2006 (BST)
Ok, you now have to enable it in both the Help and Category namespaces for it to be useful to the likes of me, and to train up others. Then I can play with transclusion and we have what we need to stop scaring people off with my complex tables !Mlj 23:24, 15 October 2006 (BST)
Done. Also the Ganfyd space, as that is the only one left that would make sense, and it seems silly to have an arbitrary odd one out. Subpages couldn't serve a purpose in Media, Image, MediaWiki or Template. They could conceivably be handy for bespoke Special pages, but none that we have at the moment (or have even been written ever, perhaps?), so I've left that too. —Rupert (Talk) 00:08, 16 October 2006 (BST)
Template:SubPages is very clever but I think it's defeating the point of enabling subpages which was just to factor out complicated tables and boxes to make it easier to edit the main prose of an article. Template:SubPages appears to be a mechanism for adding a menu which treads on the toes of the table of contents, it seems to me. Also, I don't think much clarity was gained by factoring the content of Influenza/payment out to that page as that was just prose anyway. To show you what I mean, I have refactored the influenza article. Refactoring using subpages is not to change the appearance of an article, but just to hide the scary code from prospective editors. Is that any clearer? Sorry if I don't make any sense! —Rupert (Talk) 01:38, 16 October 2006 (BST)
I think I would wish to use Template:Subpages as a reminder somewhere on the parent page that page contains subpage, at least on any I created subpages for. I will put it at bottom of page for now as its useful for subpage updating rather than going into the editing page. Its easy enough to right justify or put anywhere etc since its a div. Am now wondering if we want the expiry function on those 2006/7 pages but Adrian did not seem keen to impliment it so haven't done so Mlj 21:13, 16 October 2006 (BST)
On editing a page there is a list called "templates used on this page" underneath the buttons, which serves as a reminder. —Rupert (Talk) 20:35, 17 October 2006 (BST)
Lets not get too complicated, the structure needs to be comprehensible/ Midgley 21:30, 17 October 2006 (BST)
Yeah absolutely. Personally, I'd only use it for really long tables or boxes, such as ones whose code takes up more than the whole screen, as an article that has a few tables of that size is very hard to scroll through. —Rupert (Talk) 17:52, 18 October 2006 (BST)

Scary wikitext continued: References

See the suggestion here. I have a working implementation, but I still need to write a conversion script. The point is that the wikitext looks much more like the output, although one way of looking at it is that basically the new script takes references in the Harvard style and outputs them in the Vancouver style. What do we think? Rupert (Talk) 10:28, 25 September 2006 (BST)

Btw, on the aforementioned suggestion page, the tags are reg and regerence instead of ref and reference. That was just for development purposes, and I would intend to change them before putting it on ganfyd. Rupert (Talk) 10:31, 25 September 2006 (BST) Bump.Rupert (Talk) 17:54, 27 September 2006 (BST)
doesn't this negate the useful trick from the references extension that numbers all the references up properly? (I might be missing how this new syntax is supposed to work) although it does allow you refer to the same reference twice though which I haven't figured out a way of doing with the current system.--Manville 18:05, 27 September 2006 (BST)
No. You give them arbitrary labels (which could be numbers) for your own convenience. The extension then numbers them in the order they are used, starting with 1. In the current extension, two identical references are given the same number. Rupert (Talk) 18:17, 27 September 2006 (BST)
Ah, figured out the syntax now. Looks good, seems sensible, does it still work with PMID?--Manville 18:24, 27 September 2006 (BST)
There shouldn't be a problem, but I would try to test that in particular before installing it. Rupert (Talk) 11:31, 28 September 2006 (BST)

Timeline is dead

Sorry but you can't generate new timelines. Almost certainly been case since last upgrade but hidden by cache wrt old ones. Have several outstanding now. Any one with a knowledge of innards (php) going to fix ? Module generates error messages but then does not produce the graphical output Mlj 16:40, 24 September 2006 (BST)

There's no way I can fix it (can't even look at it) until I have the internet set up in my new house. (I don't think it will be much more than a week - I'll know exactly how long it will be later today.) It's peculiar though because I remember setting this up, and as Adam did it on the shared server, I would have thought it was the new server that I am thinking of. Anyway, if Adam or Adrian can get to it sooner than me, in order of the product of easiness to check and likelihood, my differential diagnosis is: (all this hospital medicine is rubbing off on me!)
  • ploticus is not installed (check by pl -?)
  • perl is not installed (check by perl -v)
  • /var/wikis/ganfyd-permanent/images/timeline is not editable by apache (think the user and group need to be www-user, but see what the thumbnail folders are to check)
  • try setting the path to ploticus and perl manually in LocalSettings.php:
include("extensions/EasyTimeline.php"); #this line is already there
$wgTimelineSettings->ploticusCommand = "/usr/local/bin/pl"; # find the actual path with which pl
$wgTimelineSettings->perlCommand = "/usr/local/bin/perl";
I think this is fixed now. In case anyone is interested, the paths weren't set at all in LocalSettings.php and EasyTimeline has defaults which don't apply on our server. —Rupert (Talk) 14:34, 3 October 2006 (BST)

Copyright harms healthcare training: example (via boing boing. Not by me, no.) Midgley 23:01, 29 September 2006 (BST)

  • This is problematical in UK for any training that takes place outside NHS or using material that is not Crown copyright in NHS...especially if you charge a fee for your course. Much training material is often not facts but opinion and rather definitely copyright. The notes you make of the lecture yourself are OK but not the handout ! Mlj 00:14, 30 September 2006 (BST)

Invites to/from DNUK

Well, no response from DNUK since their invitation several weeks ago. They have been pushing their Medipedia in the bulletins. The content is slowly increasing, but is sadly and very painfully handicapped by the awful interface.

I am tempted to e-mail some of the people who have contributed to Medipedia to tell them, firstly, about our existence and, secondly, to explain the issues regarding licence. Some might regard this as an attempt to poach contributors, an approach that sits a little uncomfortably with the ethos of openness and co-operation that a wiki should espouse. That said, DNUK has hardly been open or co-operative in their approach. There would only be a limited number of personal 'invites' as the numbers of contributors is still modest as best. How do others feel?<p> We, should still, of course, be thinking about exploring other avenues for publicity. Mark ong 01:02, 5 October 2006 (BST)

I'm in favour of recruiting any mamber of the profession who demonstrates a desire to collaborate in creating a reference work. However they come to our attention. Midgley 09:39, 5 October 2006 (BST)
Me too. --Penglish 13:31, 18 October 2006 (BST)

ganfyd and gmail


ganfyd has 100 (well 98 now) gmail (and google calendar) accounts that use the format. They're available to current contributors on a first come first serve basis andI envisage that they'll be a useful tool. I should be able to get further accounts from google if need be.

If you want one, let me know.

--A.l.brown 02:25, 5 October 2006 (BST)

New Category?

For scores, scales and criteria? Thinking along the lines of Modified Well's score, GCS, Ranson's, etc.We could, of course, call it "Scores, scales and criteria", but it is doesn't quite roll of the tongue.

There are enough separate criteria that criteria could have it's own category. Perhaps Scores and scales and Criteria? Any other suggestions? Mark ong 15:01, 20 October 2006 (BST)

Ah you are into a deep thought area here. see Velleman PF, Wilkinson L. Nominal, Ordinal, Interval, and Ratio Typologies are Misleading The American Statistician 1993;47(1)65-72. A more technical term to use for such a category is "Measurement scales" although I see Wikipedia uses poorly "Medical scales" and others use indices, data classifications, representations etc.. the synonyms abound. If in due course you wish to divide by levels of measurement into those using nominal, ordinal, interval, and ratio variables so be it. However you could use Names, Grades, Ranks, Counted fractions, Counts , Amounts & Balances. Criteria, I suppose are examples of Names or nominal levels of measurement only able to be analsed on the basis of equality or inequality.Mlj 00:06, 21 October 2006 (BST)

Deprecation of cf

You'll notice that automatically becomes when browsing. I know Adrian doesn't like www (and to be honest nor do I), but there is a technical reason for doing this - it enables us to use cookies across multiple subdomains, which will come in useful in the future. Would something other than www (such as be better? We can redirect to that too if you want. What do you reckon? --A.l.brown 20:50, 20 October 2006 (BST)

Definitely not IMO - is harder to remember than —Rupert (Talk) 00:25, 21 October 2006 (BST)

DNUK's Latest Advert

Is this not somewhat disingenuous? Especially the future tense regarding the license. It's also a shame Dr Roy hasn't had the courtesy to reply to any of us, but what were we expecting? Ho hum. Mark ong 10:45, 8 November 2006 (GMT)

Dear Dr Ong

Thank you for continuing to use, and in particular the forum. Since the launch of the forum, doctors have benefited from exchanging clinical information, reporting interesting cases and seeking advice from each other. This is of course in addition to the medico-political debate, media interactions and social networking that makes the forum so compelling.

Earlier this year, Medipaedia was launched: a textbook written, edited and updated by members. Medipaedia offers you the opportunity to commence an article on any issue you perceive to be useful for medical education. So far, over 100 articles have been posted, and over 22,000 of your colleagues have viewed Medipaedia.

In the spirit of community collaboration so clearly evident in the forum, invites you to contribute to Medipaedia on any topic you perceive to be suitable for medical education. Are there forum postings you have already made that could be converted into an educational article? To encourage your contribution, will give you 1,000 eSR points for every three Medipaedia articles you post. Your points will be awarded following review of your articles by the Medical Team.

It is extremely simple to commence an article, simply select "create new article" from the Medipaedia homepage. You can edit and discuss any artcle, and any user can review any changes made by others. If you are familiar with Wikipedia, you will notice that Medipaedia is a wiki application that is designed for community collaboration. Like other wikis, a Creative Commons Licence will be used to protect your work. Unlike other wikis, Medipaedia does not yet use many of the automatic functions, therefore keeping it as uncomplicated as possible. hopes you agree that the forum is already a valuable knowledge resource. Medipaedia simply enables the development and organisation of this knowledge into an amazing resource for 135,000 doctors to share. If you have questions or comments, you can use dedicated discussion pages on Medipaedia: simply select the discussion tab on any page to leave a comment about that page. Please feel free to contact me directly on if you would prefer.

Yours sincerely


Dr. Shaibal S. Roy
Medical Team

I find the whole debacle very depressing, and I am unsure as to what reason DnUK have other than commercial gain. --A.l.brown 18:53, 12 November 2006 (GMT)

Box Proliferation

I'm not sure if anyone else agrees, but we have tons and tons of boxes for things. Some, like the pharmacology box or the internet resources box sit hard right and generally behave themselves. Others do not, and we have boxes overlapping boxes, text wrapping around a box in a thin column, various sizes of boxes, various styles of boxes.

To me it looks a little messy, jumbled and garish. I propose we settle on a single box style, and use subtle changes like colouration and icons to differentiate. I also think that (other than the boxes which sit at the very top of pages like the pharmacology and internet resources boxes) we should ensure that boxes are central, around 75% of the width of the text area they inhabit, and do not allow word wrapping. That way, one box clears before any more start, and they are wide enough to fit enough text on each line to prevent large areas of white space either side.

Just a thought. Let me know what your thoughts are. If we get a consensus I'll come up with some alternatives for your collective approval or dissapproval!

--A.l.brown 18:53, 12 November 2006 (GMT)

I agree we eventually need to have one clear of another, but it may be excessive to tackle occasional layout problems with general rules. I definitely prefer boxes to sit on the right of the page, and the main text to flow past them. The styles needed so that boxes sit relative to a div, rather than teh page, elude me today, but that may be worth looking at. Then we can handle layout by enclosing problematic aggrregations in one or more divs, an positiion them that way. Midgley 18:59, 12 November 2006 (GMT)
I agree (well I would, wouldn't I having created far too many of them, although I think my style has generally been liked). The most annoying is stub. Will any one let me hit it hard with a div....although I think bottom right where I feel like putting it is too easy to overlook and putting it right mucks things up for SubjectBox which I think is a real success. Mlj 22:24, 12 November 2006 (GMT)
We're probably overusing divs and underusing ps. A lot of this stuff would be best sorted by adding things to the CSS. —Rupert (Talk) 22:48, 12 November 2006 (GMT)
Just a quick observation - the Anecdote box seems to be behaving very oddly. Look at the epiglottitis page to see what is happening. Is there any way that a dullard such as myself can resize such a box? --Fishgoth 23:13, 12 November 2006 (GMT)
Just edit it here. —Rupert (Talk) 07:12, 13 November 2006 (GMT)
Thats the sort of width I think the boxes should be, and aligned centrally. Looks much neater to me. --A.l.brown 10:16, 13 November 2006 (GMT)
No problem. If there are no objections, tonight I will create a wiki page that is a cascading style sheet, and I will add that to the skin we use. This will enable us to factor out much of these stylistic aspects of ganfyd from templates to CSS, which will make achieving a consistent look and feel between different templates easier. —Rupert (Talk) 14:04, 13 November 2006 (GMT)
On looking into it, this is already set-up: MediaWiki:Common.css There is also MediaWiki:Monobook.css, but that is strictly for changes to the Monobook skin only. —Rupert (Talk) 15:49, 13 November 2006 (GMT)
Ok stub etc looks much better & concise and does not hurt the eye. Good job Rupert and as usual when I see how you do things I learn some elegant coding using CSS and wiki #ifeq function.Mlj 21:34, 13 November 2006 (GMT)
Stub is much better. SubjectBox is a mess today though, it just looks wrong. Midgley 03:38, 16 November 2006 (GMT)
Damn. You need to refresh the stylesheet. So Ctrl+F5 in FireFox. Better? —Rupert (Talk) 03:40, 16 November 2006 (GMT)
Can you think of a way to display in line URLs that have a registration requirement like the BNF and that fits with a toned down display generally. I definitely hate having links that others can't always access displayed just like a normal link, even with the qualification registration required and think we need a convention. I used a very pale yellow/pink background in past in PharmacologyBox but with the style changes wondered if such links should be an orange or brown colour as this would not be that confusing with stand red/blue/purple convention. Should be possible with a CSS style like class="RegistrationRequired" perhaps accessed via a template {{RegistrationRequired|}}. What do others think ? Mlj 08:40, 16 November 2006 (GMT)
I've had a go at PharmacologyBox. See Template talk:PharmacologyBox. —Rupert (Talk) 14:24, 16 November 2006 (GMT)
See Template talk:PharmacologyBox/Complex approach and revised MediaWiki:Common.css to see that is possible to just transfer current pharmacologybox to css where it belongs. I will await comments before making the big move in case anyone has better ideas. My main issue with Rubert's use of ul (and mine of ol) in the css is that it does create problems if a line return ever sneaks into your passed variables and I am worried that we are stopping people using both unordered and ordered lists as a passed variable. Wouldn't it be safer to go back to divs with classes as you then have a robust, if not so elegant solution to templates. I know Rupert hated all the divs in those templates but at least some of that hate was that I was not using css but I can now I have access to MediaWiki:Common.css.00:26, 17 November 2006 (GMT)


A problem. IE 6.0 is definitely not able to cope with even simple CSS layout consistently and many organisations are still stuck with it for a little while longer. The display problems with the present SubjectBox CSS have to be seen to be believed. No wonder CSS has not had the take up it deserves. What do people think? Should we forget IE 6.0 and go ahead with good style, converting templates to refer to CSS as we should (it will allow us to change template style centrally rather than hack each template) or should we continue the table hacks and inline divs that IE 6.0 can cope with ? This is an important question as really we should move a number of templates to the style sheet to allow greater consistency. For example flags (too many different backgrounds) and the clinical evidence templates. Mlj 09:36, 17 November 2006 (GMT)

I'm of the opinion that we should target Internet Explorer. Very often people can't avoid using it. So far I have found problems with Internet Explorer 6 CSS compliance to be overstated. It's actually not a bad browser. —Rupert (Talk) 18:31, 17 November 2006 (GMT)
Well at least I agree we should support IE 6.0 but its easier to do so if we don't move to CSS. The most obvious problem of the moment is that anchors (URLs) do not inherit background automatically so presumably this needs to be stated explicitedly in our style sheet. I tend to feel I have better things to do with my time than checking for browser compatability when I am rather rusty on IE 6 CSS work arounds.Mlj 19:13, 17 November 2006 (GMT)
Now I have investigated more and found that IE (all versions) is just not liking the CSS as it now stands. One of the reasons is definitely because it can't stand the ol and ul substitution worse luck. This is a smart idea that just will not work consistently across browsers. I strongly suggest we do not move to CSS for templates until these issues are sorted. I may sort out PharmacologyBox and then use my solutions with SubjectBox as its sometimes best to move from the more complicated backward. SubjectBox works most of time because it doesn't accept passed variablesMlj 20:02, 17 November 2006 (GMT)

Newlines in template parameters - not really a bug

On Template talk:PharmacologyBox/Complex approach: Sorted out and now renders ok as long as no new lines in any elements submitted. Then disaster will strike but this due to Ruberts logic not mine

The links do go haywire if there is a new line in the drug name. That's due to my urlencode parser function not stripping newlines from the input. They get passed through to the template. I appreciate that spreading the template over a few lines makes it more readable though, so I'm happy to make urlencode remove the newlines.
The second case is when multiline parameters go absolutely haywire stylistically. This is because all but the first lines are converted to paragraphs by the parser on substitution. Actually Michael you went halfway to fixing this. You need to have the parameter enclosed by a div, as you have done. You also need to not specify a style for p so that it can inherit that of the div that encloses it.
I will sort both these matters out now. —Rupert (Talk) 13:03, 19 November 2006 (GMT)
Done. Although you need to use the new strip_newlines function, if you want to insulate against the first case. This is because the new lines in the link name, also cause everything to go haywire. See Template:PharmacologyBox to see what I'm on about. The rather frequently occuring {{#if:{{{1|}}}|{{#strip_newlines:{{{1}}}}}|{{PAGENAME}}}} could be replaced with a specialised parserfunction. —Rupert (Talk) 13:28, 19 November 2006 (GMT)

Pretty URLs

Is there any chance of adding a simple redirect to ganfyd to allow 'pretty' URLs? I have done it before on a different wiki I was running and it's very simple to do. We could convert:
Full details of how to do this can be found here. MadDoc 04:04, 14 November 2006 (GMT)

It would be good. I'll take a look at it and see if I understand it sufficiently well. Midgley 21:52, 17 November 2006 (GMT)
It is better, as the linked doc says, to put config in the apache.conf file rather than run .htaccess at all, but we are actually running that option so httpd is looking for access files with each request. THis could be rationalised.
I don't see mod_rewrite in our configuration, yet. THis needs trying out on a non-production machine before I'm happy to disturb a working system. Midgley 21:35, 18 November 2006 (GMT)

Proper Style Sheet Approach

As Rupert has said its time to move to CSS for templates. I have now sorted the Internet Explorer rendering problem and while it might not be as elegant as Ruperts first try at getting rid of the hated tables it is robust across browsers and will cope with full wiki syntax in passed variables. I think it best if we have some idea of what other users think of possible base colours for SubjectBox and so please look at Template talk:SubjectBox for 3 alternatives. Template talk:PharmacologyBox shows that it is possible to code other colours easily for particular purposes if others think this is a good idea, but there are some that think not. House style is an important issue and we are tending to tone down as the site gets more mature...but how far to tone down is the question !. Mlj 00:25, 18 November 2006 (GMT)

Minor Bug

A (?Pubmed) reference at the end of a penultimate bullet seems to mess up the indent. See Pancreatitis#Diagnosis. Mark ong 14:34, 19 November 2006 (GMT)

Actually, the presence of a carriage return/line feed in the reference braces does something to make the interface forget the original indent, e.g.
  • Item 1
  • Item 2[1]
  • Item 3

Indent should go back to normal, but doesn't.


  1. Line 1 Line 2

Thanks, Mark. This is pretty weird. I shall investigate. —Rupert (Talk) 14:52, 19 November 2006 (GMT)

Not much investigation will be needed. This is also a fault with output from <pmid> Mark reproduced by inserting a line in an unordered list with in line <ref> Line 1 /n Line 2</ref>. The php for unordered lists (and ordered lists as used for references) does not like this. I presume the issue is that you end a list by generating a new line but you have done this inside another bit of php code so dont get a clean return. I emailed Rupert yonks ago a try at pHp code that eliminated new lines in output from <pmid> but it won't work if authors do it themselves. Rupert wants to rewrite the <ref> code completely rather than use my hacks which may be buggy as I have not ever used pHp in anger. This is likely to change as I am preparing a hard disk for an apache server in an internal network as I write this and will no doubt play with wikimedia on itMlj 23:52, 21 November 2006 (GMT)