Wikipedia talk:WikiProject Countries
Where is the list of participants? Sign me up! --mav
- Obviously I'm in as well ;) -Scipius
There's discussion on Talk:Countries of the world/Status of the porting of Dept of State info about how to desubpage the country entries, or whether to do so; if you're still interested in getting this off the ground you should go vote about what to do. :-) --KQ
Jeronimo, why did you change the previously established layout for the headers? Using the === unnecessarily separates the title from the "main article: xxx" sub-header. Given that you had the HTML right there on the page I don't think there was a chance people would find it too difficult. -Scipius
- Scipius, the main reason that I did this (maveric149 did the same for his chemical elements template) was that it was not Wiki mark-up. The current trend is to change all formatting to wiki layout; even for tables (that is being discussed on the mailing-list). Reasons are that people unfamiliar with HTML may be scared to edit such articles and (which is my personal reason) that I would prefer not to put in displaying elements in the text - that is the task of the stylesheets. In this way, we define a heading as a heading, and not a part of text as boldface size x. But of course you're free to use that format everywhere... Jeronimo 12:18 Aug 3, 2002 (PDT)
- I see. I asked because I had already inadvertently changed the Netherlands Antilles headers over. Why is this the "current trend" though? Was this discussed somewhere? It does make the page look slightly more disorganised at the moment, but since "font size" doesn't seem to work properly anyway (see the Europe article, the note numbers should be -1, but aren't), I'll think I'll wait until all is sorted out. -Scipius
- I think the trend is such for several reasons, but mainly to make things easier, both for us and for new editors. I had a short "discussion" with maveric on this about this (I think it's on my talk page), and I think he had one prior to that (I reacted on his changes to the headings).
- Anyway, I haven't bothered to change the headings in the already existing pages yet, if only because it _does_ look nicer. But I think the WikiProject countries should focus more on how the content should be, and less on details of layout (although a uniform layout would be best, of course). Jeronimo
- I've read it, thanks. You're certainly right in that there are still plenty of countries left to do first ;). -Scipius
Scipius I think we are all on the same page here in not liking the extra whitespace that the wiki headings put in by default. Instead of trying to circumvent this through HTML tricks that will turn away the HTML-phobic (which is the majority of the web) why not make a feature request to change the behavior of heading parsing? You could ask for a more WYSIWYG heading that would only have the trailing space if there is an extra space after the heading. It is counter-intuitive the way it is now;
<br> === Heading ===<br> Test, blah, blah, blah...
Should render as;
Heading
Test, blah, blah, blah...
With that blasted trailing whitespace! Please copy any of the above in your feature request and also include that the current behavior is leading you and many others to use HTML instead of wiki. I think the elements articles are not as nice looking as they were before but a wikipedia article that is only editable by a small group of people is not a wikipedia article. --mav
- Vertical spacing after a header tag is normal in HTML. If you want it to look different and you don't want to abuse the system by not using header tags for headers (in the output from wikicode, that is), what you actually want is to have the stylesheet changed and thus the spacing reduced. --Brion VIBBER
- This is what all the fuss is about: < font size="+1 > Heading < /font >< br > vs. === Heading === --mav
- Right. The former is doubly wrong (1: hard to edit/read source; 2: doesn't produce proper header tag for metaprocessing -- autoindexing, tables of contents, section numbering, summarization, proper emphasis for text or speech browsers, etc) while the latter is easy to read, easy to use, and produced correct and usable code, but some people don't think it looks nice using the default style. Ergo, fix the style. --Brion VIBBER
- Brion is right here; I'm not sure however it's possible to use an HTML heading without hte whitespace. Jeronimo
- Oh ye of little faith. :) Here's an example: media:temp-stylesheet-demo.html --Brion VIBBER
- Cool. What might the syntax be? I do hate having the extra space but I am a bit cautious about changing all current heading behavior. --mav
- Simple addition to the stylesheet: h1,h2,h3,h4,h5,h6,h7,h8 { margin-bottom: 0; } If you don't include a blank line between the header and the following text, no <p> tag is inserted, so the text immediately abuts the header. If you do include a blank line, a <p> is inserted, which has its own top-margin (normally absorbed by the existence of the header's bottom-margin) and you get the space. Intuitive, no? --Brion VIBBER
- So how do we get it to look like in that example? Has this been implemented yet? It's funny and maybe I'm an exception, but I knew next to nothing about HTML before I came to Wikipedia. I've found it relatively straightforward to use once all the options are known (e.g. see the population pyramid table in Netherlands). I don't know anything about how to edit stylesheets, but I assume there will be tutorials for that. -Scipius
- No < p > after a < / h* > is badly-formed HTML -- the markup parser should force one. Use H*+P in CSS to set top margin of Ps following H* to zero. -- Tarquin
- Bad HTML to be sure, but that's what the parser does currently produce. Your suggestion is a good one, however! --Brion VIBBER
I just added a feature request for this. Please add any comments to it you see fit (on my browser you have to scroll down to get to the text -- for some reason having HTML in the title field messed up that page). -mav
I'm not sure if my comment is posting of sourceforge: This is needless complication. A heading should be a heading, no more. users who want to *see* headings differently should be given a different CSS stylesheet which displays them differently (and, yes, HTML in the title breaks that page - 2 out of 3 browsers I have tried to load it with fail on it completely -- Tarquin
- I submitted another feature request this time without the HTML in the summary field. The above link has been updated. I'm not sure if you are for or against killing the trailing whitespace... --mav
I don't mind how the headers look. But asking for new markup for this is mixing content with formatting. Trailing space or lack of should be implemented through CSS not through markup -- Tarquin
Whose asking for new markup? I want the behavior of the current markup changed to be more intuitive and flexible. I have no idea what you are talking about with the CSS statement. --mav
"I would like to see a more WYSIWYG wiki heading that would only have the trailing space if there is an extra space after the heading." <-- you seem to be asking for two different class of headings - those with space after and those without. What is this for? Is it to make some level 2 headings more important that other level 2 headings? Is it so some writers can have space after headings if they wish while others can have them without space? -- Tarquin
- As the one who came up with the HTML style header for the WikiProject, I can say that it was to achieve a clear notion of the section text being just a summary of the main topic articles that are linked to just under the header. Anyway, it works now as described above and I quite like it. -Scipius
The "side table" contains incorrect HTML syntax, as kindly pointed out by Fred Bauder on my talk page. LDC corrected it at China/Temp, and I saw W3's validator didn't like the other formatted pages. This should be fixed, but it is bedtime for me now. Jeronimo 14:29 Aug 4, 2002 (PDT)
- I fixed all tables in WikiProject pages (and the template, of course). Jeronimo
Floating a table of this size makes some part of the main text hard to read at any browser width. -- Tarquin
I agree that the table is way too fat -- fatter even then the elements table. But I don't agree this effects all browser widths; on my home screen it looks fine (17 inch at 1200 pixels wide). But since 50+ % of the web uses the default MS Windows resolution of 800 by 600 I think this is a serious problem. The images have been the worst offenders here and need to be much smaller. Some additional wordsmithing should also be done to thin the table. It took me well over a month to develop the original elements table at Beryllium with the help nearly a dozen people. This table seems to have been rushed out the door and now issues are surfacing. --mav
- Although I agree that the table could be smaller, but I checked some tables in Windows at 1024 x 768 (my usual) and 800 x 600, and it looks fine to me on both sizes. The table is maybe half the content part of the page, but that actually makes the text easier to read (newspaper effect). But, I'll keep an eye out for making the tables smaller if possible. Jeronimo 23:37 Aug 5, 2002 (PDT)
- I think the simplest thing would be to unfloat the table so there is no text squeezed down the side of it -- Tarquin
- Let's not unfloat it, that makes it look hideous at larger resolutions and wouldn't be much prettier at smaller ones, except 640x480 or something like that. I also disagree the table is too wide per se. It wasn't necessarily rushed out, we already slimmed the original down. Yes, it can perhaps be trimmed further, but the problem is partly that not all tables will be the same width, as countries will require different lengths of information to be added to their individual tables. Let's see how it can be further narrowed.
- On the general page width, I think we shouldn't always cater to the lowest common denominator. Sure, maybe now lots of people still use that resolution (though I'm not sure), but this will change over the coming years. With Wikipedia being a long-term project that's still pretty much unknown to the general public at large, I think we can afford to write to at least 800x600 or even better 1024x768. As pointed out, it doesn't look all that bad at 800x600, a further trick would be to use only small paragraphs in the text next to the table/map, so that when viewed at a smaller res, it won't be too much of a textblock. -Scipius
I'm not saying we should cater to people who have screens set at 640x480, but to the majority of the web that have screens set at 800x600. At that res the Netherlands table, for example, takes up well over half of the content area of the article. And this is with a maximized browser window without any browser sidebar. If the table were an image, this width would violate our Wikipedia:image use policy. I will work on an alternate table that will only take up half of the content area on 800x600 screens. Here is a link to a screenshot of the Netherlands table. This image is 395 pixels wide and was taken one for one from a screen shoot of the Netherlands article. --mav
- this is not only about low-res screens. This is about good layout and good typography. My desktop is 1152x900, but there is no way I can read all of that page comfortably without resizing my browser window: http://c2.com/cgi/wiki?TenWordLine -- either the text alongside the table is too narrow, or the text above & below is far too wide. I suggest either unfloating the table or putting it on a seperate page, eg "Netherlands Factsheet" -- Tarquin
As an example, I reduced the width of the United States table by well over 100 pixels. Now the table is just over 250 pixels wide. Unlike images I think these tables could be up to 300 pixels wide because tables are not as distracting to me as images so the extra width isn't as important. We should still shoot for 250 though. Notice I placed the official name above the table where the useless "facts" statement was (this was needed for width issues). For non-Enlish speaking nations we can simply have he official local long form in grey right under the English long form. There is no need for an explanatory cell for these things. --mav
- Looks neat, maveric, it's better now even on my high res screen. Countries with multiple names (up to 3 local names in BEL, LUX) may give problems though. Jeronimo 23:25 Aug 6, 2002 (PDT)
- Thank you! Yeah those will be problematic but we can take these things one step at a time and there is no rule that each table has to be a carbon copy with different info. We can make tweaks here and there for each country in order to get everything to work right. --mav
Now that we have the space, it might be neat to have area and population world rankings. Here is an example from outdated off-the-top-of-my-head data for the US;
Area |Ranked 3rd Land |9,166,600 km² Water |206,010 km²
and
Population |Ranked 7th Total |281,421,906 Density |31/km²
I say we get rid of the ugliness the mile figures introduced, make an article named square kilometer and provide conversion factors there. This is what I have planned to do all along for the elements tables (since I use SI units almost exclusively in order to reduce table size). It would also be neat to link the actual numbers to the corresponding orders of magnitude article. That way there will be two ways people can relate the area figures. --mav
- Amen! Even we merkins are taught metric in school; we can call up the conversion factors and calc.exe if we need to. --Brion VIBBER
- Yes, kill the darn miles! Though after a trip to America, I'm glad that I am NOT the one that has to do the conversions :-)
- As for the rankings, we should also provide a ranking article then (or at least mention a source for this) since I don't think it's in the CIA factbook (or is it?). Also, I think the total area should be mentioned somewhere, so either
Area |Ranked 3rd Total |9,372,610 km² Land |9,166,600 km² Water |206,010 km²
or
Area |Ranked 3rd Total |9,372,610 km² Water |206,010 km²
- would be my suggestion. Jeronimo
- An almanac article with a list of rankings would be most cool. Great idea! Either of your total area modifications work for me. Vertical space is cheap but my only concern with having four entries is that the numbers begin to jumble together. But that may just be my math dyslexia. --mav
Yes, I think Total and Water only will be enough (my preference). Maybe "of which water" would be clearer, although "Total" does suggest it includes everything.
Found some possible data sources:
- http://www.gazetteer.de/home.htm (Click on the first link in the body)
- http://212.204.253.230/global/pop_data.php
- http://www.cia.gov/cia/publications/factbook/index.html (Click on field listing, Area or Population)
The CIA book also has the land/water/total figures neatly together. Anybody looking for something to do ;-) ? Jeronimo 00:54 Aug 7, 2002 (PDT)
Thanks for the links - I'll look at them later. How about this;
Area |Ranked 3rd Total |9,372,610 km² Water (% of total) |206,010 km² (2.2)
I tried this with a preview of the US article and it did not add any extra width. --mav
Better idea; only mention the percent of water (a calculation already has to be made for the land figure.
Area |Ranked 3rd Total |9,372,610 km² Percent water |2.2%
--mav
- Yes, the latter proposal gives a better impression of the amount of water. Note that for some countries listed at the CIA, the water area is zero. This may be true for some of the small 1 sq km islands, but not for countries as Afghanistan or Algeria, no matter how dry the land may be. So we should include "unknown" there. Jeronimo