Wikipedia

User talk:YBG/Archive 4

< User talk:YBG
Latest comment: 4 years ago by YBG in topic And just a little thought
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6

Micro periodic table draft

Latest comment: 7 years ago9 comments2 people in discussion

Hi YBG

Could you provide me with a micro PT that has the nonmetals coloured as per my draft rewrite of the nonmetal article? Thank you, Sandbh (talk) 22:56, 23 August 2017 (UTC)

I think so. Could you give me a link to the soon-to-be-obsolete version of what you want and your proposed name (URL) that you want me to create it under. YBG (talk) 23:14, 23 August 2017 (UTC)
I think I understand. You want me to fix the micro PT in your draft rewrite so that the colors show the new categorization. Is that right? YBG (talk) 23:30, 23 August 2017 (UTC)
Yes, that's it! Sandbh (talk) 00:25, 24 August 2017 (UTC)
OK, I'll see what I can do. No promises as to when. YBG (talk) 00:30, 24 August 2017 (UTC)
  Done It turned out to be fairly easy. I created alternate User:YBG/<t-name> versions of two templates, {{periodic table (micro)}} and {{periodic table (32 columns, micro)}}. These should be viewed as VERY tentative due to the fact that I've continued to use the current category names and simply changed H and N from "diatomic" to "polyatomic". But it does show the changed colors. YBG (talk) 06:10, 24 August 2017 (UTC)
@Sandbh: I have now modified {{Periodic table (32 columns, micro)/elementcell‎}} and {{Element color/secondary‎}} to use the slightly different yellow and green proposed by DePiep. I have also modified User:YBG/Periodic table (32 columns, micro)‎ to make use of these colors instead of incorrectly using the diatomic/polyatomic as I did in my original tweak. YBG (talk) 08:31, 26 August 2017 (UTC)
@Sandbh: {{Periodic table (32 columns, micro)/elementcell‎}} was reverted back to its original state, which turned all 11 NNNM black in your sandbox revisions's micro PT in your article until I created and referenced {{User:YBG/Periodic table (32 columns, micro)/elementcell‎}} This means that I now have three PT-related user-space templates that will in due time be merged into template space. YBG (talk) 04:56, 27 August 2017 (UTC)
Roger that, I see that the proposed nonmetals in the PT micro is looking good in the draft. Sandbh (talk) 05:06, 27 August 2017 (UTC)

May I ask for a small favor

Latest comment: 7 years ago4 comments2 people in discussion

Yesterday, an article I wrote, history of aluminium, was promoted to the GA status. That made it eligible for being featured in DYK, and I nominated it. Would you review the nomination? The information you may need can be found here (directly on this page; a beginner's guide is linked there). This can be done by any user.

I want to get DYK off of my mind sooner because during the GA I was motivated to get this article featured and essentially, content-wise, I think we're there already. This could be done quickly. This is why I am hurrying the process by asking you. I'll be glad to return the favor in wharever way you want whenever you ask.--R8R (talk) 09:50, 27 November 2017 (UTC)

Oh well, this article made it through the waiting line faster than I had anticipated. Sorry for bothering then :) --R8R (talk) 22:26, 27 November 2017 (UTC)
@R8R: Never a bother. I did briefly look at the review criteria, and quickly realized I needed to study the criteria and process more than I was able to devote right then, and before I got back to it, your 2nd message appeared. Congratulations! YBG (talk) 06:51, 28 November 2017 (UTC)
Thank you. Turns out there's another waiting line from there, and even after making it through, you'll still be in another preparation zone, so we'll have to wait for some time to have the article featured. Now, however, we're no longer in a hurry and I can edit at my leisure :) --R8R (talk) 14:58, 28 November 2017 (UTC)

Wikibreak

Latest comment: 7 years ago1 comment1 person in discussion

I have returned from my wikibreak, but expect my wiki presence to be less than it has been in the past. I have cleared my watchlist and am undecided what to do with it in the long run. 14:29, 19 April 2017 (UTC)

Providentially, I attempted my first post-wikibreak edit during the April 2017 cutover to the secondary servers and so the above edit was not saved and has been reconstructed with a hard-coded UTC time. YBG (talk) 14:34, 19 April 2017 (UTC)

Re nonmetals

Latest comment: 7 years ago2 comments2 people in discussion
Thank you for keeping our new
vending room clean!

Please remember:

  • Personal items and dishware will be
    discarded if left in the vending room
    unattended.
  • The Microwave and Toaster Oven
    must be attended when in use.
  • No non metal items on top of the
    hot Toaster Oven
  • Enjoy!

The kitchenette at my place of work includes this sign. The third bullet regarding "non metal items" is most interesting with regard to WP:ELEMENTS. I note that lithium, sodium or potassium are not prohibited atop the toaster oven; that of course would be much preferable to having them in the sink! YBG (talk) 18:00, 4 May 2017 (UTC)

Actually, disposing small pieces of Li in cool water is a perfectly legitimate procedure. ^_^ It is only inadvisable for Na, K, Rb, and Cs; for that you need to use the more reactive isopropanol (and why dispose of the expensive Rb and Cs in the first place if you're not going to have fun with it?). I would still be slightly unhappy with the sink, but that is not so much about its structural integrity and more about the fact that you're pouring lithium hydroxide down it. It is probably not going to be concentrated enough to do much, though. Double sharp (talk) 04:27, 13 July 2017 (UTC)

Neologisms worth preserving

Latest comment: 7 years ago4 comments3 people in discussion

Courtesy of @Double sharp and Sandbh:

YBG (talk) 06:34, 12 July 2017 (UTC)

Adding "Respectable NM" YBG (talk) 08:17, 14 July 2017 (UTC)
LOL, thank you! "Iron Fan Club" is certainly more catchy than "iron triad", isn't it? ^_-☆ Double sharp (talk) 06:58, 12 July 2017 (UTC)

Let us not forget:

  • The "remaining nonmetals"—not much better than "other nonmetals" but it sounds a little more proper given it has one more syllable
  • The "catch-all nonmetals"—I don't hear "catch-all" a lot these days.

--- Sandbh (talk) 07:24, 12 July 2017 (UTC)

Pretty pictures

Latest comment: 7 years ago8 comments2 people in discussion

You mean like those at Triacontadigon (32-gon)? Honestly, the current ones aren't mine (my less impressive ones can be found in at Tetracontagon – they're the monochrome ones), but from Tomruen, who generated a large batch some years ago. ^_^ Double sharp (talk) 00:02, 13 September 2017 (UTC)

I don't really remember which ones they are, I just (vaguely) remember that I noticed some polyhedral with your name attached to them. At least I think so. I thought it included my favorite, the 26-hedron, either with or without metallic vertices and edges, but I see someone else did those. YBG (talk) 00:12, 13 September 2017 (UTC)
I think most of mine are at The 59 icosahedra, IIRC. Double sharp (talk) 02:59, 13 September 2017 (UTC)
Wow!! YBG (talk) 03:45, 13 September 2017 (UTC)
Thank you! By the way, I should note that the two pictures you linked of the 26-hedron are not actually the same polyhedron. One of them has squares opposite squares around the "equator" (the true rhombicuboctahedron), while the other has squares opposite triangles (the pseudorhombicuboctahedron). It's also possible to warp the vertices in just the right way for those faces to twist through each other while still being regular, which I also illustrated. ^_^ Double sharp (talk) 06:29, 13 September 2017 (UTC)
I was aware that those two "allotropes" existed, but wasn't looking closely enough to notice that the pics I linked to were not identical. Had I noticed, I would have snubbed the "pseudo" one. I "true", but both are really nice in that they have the same number of faces as there are letters in the English alphabet. YBG (talk) 08:39, 13 September 2017 (UTC)
There's an easy way to get the figure of 26 out, BTW: in the second picture you linked, the red faces line up nicely with the 6 faces of a cube, the yellow ones with the 8 vertices, and the blue ones with the 12 edges. You can explain all the Archimedeans this way as various "avatars" of the Platonic solids. ^_^ The situation with the uniform stars and the Kepler-Poinsots is a little more complicated but not essentially different, and as a bonus it goes up into higher dimensions in just the same fashion. ^_^ Double sharp (talk) 08:54, 13 September 2017 (UTC)
Avatars and allotropes, Oh My! YBG (talk) 09:06, 13 September 2017 (UTC)

Micro periodic table: groups

Latest comment: 7 years ago5 comments2 people in discussion

In User:YBG/PT groups, you use {{Periodic table (32 columns, micro)}} (18 times). Since that template took up too much processing time (exceeding parser limits) in one of the element articles (can remember which one; which had a dozen or so); they were commented out.

To reduce that template load size, I removed the option |mark=3 to mark group 3 elements. The marking now should be done by |mark=Sc,Y,La,Ac.

Because of this change, your subpage (using group numbers) does not show any markings any more. At the moment I don have time to take care of that, hope it does not disturb too much. -DePiep (talk) 15:58, 28 November 2017 (UTC)

Found it: article Properties of metals, metalloids and nonmetals had too many micro PTs. They had to be removed. -DePiep (talk) 00:16, 30 November 2017 (UTC)
Sorry, I meant to tell you that was the article. Is there any chance it could be restored? Would it help if there were a micro PT without the links? YBG (talk) 05:01, 30 November 2017 (UTC)
Discussion was here at VPT. There were twenty micro PT's. I and others have tried to reduce load size a bit (eg rm this mark=groupnumber thing). Still it could be too large for twenty. Iḿ afraid it was caused by me when I changed the click-function per cell from a transparent image into full <div> controlled clicking (I thought more modern, but apparently also costlier).
We could re-add three PTs for main: metals/metalloids/nonmetals (should check for exceeding limits still). The other sevemnteen: research going back to the image-trick, or use other means like image-based PT. -DePiep (talk) 12:18, 30 November 2017 (UTC)
What about using a clickable pushpin-style map where the pushpins are shaped like boxes and the inputs are symbols or what-not instead of lat/long coordinates? Just a thought. YBG (talk) 16:06, 30 November 2017 (UTC)
my point: i'm not interested. -DePiep (talk)

English spelling

Latest comment: 6 years ago2 comments2 people in discussion

@Double sharp: re special:diff/813191759, I have looked at it, and it looks interesting. But that page is trying to solve a different problem, to infer the correct pronunciation from the spelling of English words. That problem is, IMHO, much easier than the problem of trying to infer the correct spelling from the pronunciation of English words. But both are much much harder than the problem required by a respelling key, which is to figure out a way to spell all English syllables (or in our case, to spell all syllables in the element names) in a way that conforms to natural English spelling. YBG (talk) 05:13, 4 December 2017 (UTC)

Actually he tackles that near the end, under the heading "Spelling reform by regularization", including Ozymandias with his proposed spelling reform applied as a sample. But it does strike me that many of the element names are relatively unambiguously spelled already, and if you don't know those inference rules a respelling is not going to help. (As R8R mentions, lead is a major ambiguity; but that's vowel digraphs, which is really the problem in English spelling.) The ones that need help are truly a minority.
I just ran through them in my head, and the first metal that I think is really indefensibly spelt is technetium (which should really be spelt technecium to give the right English pronunciation; same with lutecium). (I guess niobium might also cause some confusion on which vowels are meant to be long; compare biology, which has the same stress pattern.) I think Noah Webster had it right for cesium; caesium obfuscates the softening of the c. Even praseodymium isn't hard once you work out where the stress goes. Indeed I think it might be harder to say it then to figure out how to say it.
The bulk of the problem seems to be with the ancient metals and the less regular nonmetals. Iron and lead you surely know about already. The halogen ending -ine is a tricky one. It looks like it should have a long i, like serpentine. But then again we also have latrine with a short i. I think it's just the alternating stress; I want to say fluorine, chlorine, and bromine with a short i and iodine, astatine, and tennessine with a long i. The reduction of final -on is also a bit unpredictable: for me, boron and carbon do not rhyme. I usually pronounce neon, argon, krypton, xenon, radon, and oganesson like boron, but silicon like carbon. I am not very sure how to signal this unexpected lack of reduction in the spelling.
The synthetic elements are problematic, but this is mostly because of borrowing. Berkelium has a weird short second e, and seaborgium inherits the ambiguity of English ea (the morpheme boundary should adequately signal the non-softening of the g), but the real problem comes with things like einsteinium (which needs a German interpretation of ei), dubnium (in my dialect u only takes this value in native English words after a labial, viz. pull vs. dull), bohrium (which is R8R's problem with gohld as a respelling), meitnerium (German ei again), darmstadtium (for which you need to read Darmstadt as German), and roentgenium (where the oe is trying to be an o-umlaut, and g is not softened).
Actually I am not sure if these borrowings are completely English; I pronounce roentgen as a German word anyway. And I do the same in music for Haydn, Mozart, Beethoven and all those composer names, as well as terms like Lied and Singspiel (for me, their plurals are Lieder and Singspiele). But somehow English suffixes are productive here: I don't find anything odd about Mozartian and Beethovenian! Or indeed Bachian, even though English does not have the ach-Laut, outside Scotland! So I think that some of these element names, taking Einstein, Meitner, and Röntgen as their eponyms, are rather including a bit of German into English, and need to be judged by German rather than English spelling conventions; but then why doesn't Einstein have /ʃ/?
But I think my point stands; from hydrogen to oganesson, more elements are spelt reasonably than not. Double sharp (talk) 05:52, 4 December 2017 (UTC)

Merry Christmas 2017

 
The 12 gifts from the song
The Twelve Days of Christmas

To all my talk-page-watchers and other assorted geeky WP friends, here's a seasonally themed puzzle: In the song the 12 days of Christmas, the singer's true love gives:

  • On the 1st day, a partridge in a pear tree (considered as one gift)
  • On the 2nd day, 2 turtle doves and a partridge in a pear tree (making 3 gifts that day, for a total of 4)
  • On the 3rd day, 3 French hens, 2 doves and 1 bird in a tree (making 6 gifts that day, for a total of 10)

Category:Pages with parser function time errors

Latest comment: 6 years ago3 comments2 people in discussion

I am trying to clear pages from Category:Pages with parser function time errors so any real problems can be seen and resolved. Each of the following is in that category:

If you don't have plans to fix them in the near future, perhaps you wouldn't mind doing something to disable whatever is causing the errors, or I could do that. Thanks. Johnuniq (talk) 09:12, 16 May 2018 (UTC)

@Johnuniq: Thanks. They should be fixed now. YBG (talk) 13:25, 16 May 2018 (UTC)
Thanks, all good. Johnuniq (talk) 03:33, 17 May 2018 (UTC)

Discussion re living POTUS table

Latest comment: 6 years ago103 comments2 people in discussion

This discussion was copied here from  User talk:YBG/sandbox so that I can archive it in my regular talk page archives. The headings levels were increased so that it all comes under this one header. YBG (talk) 04:18, 27 October 2018 (UTC)

tests

The number of presidents alive at each moment in United States history
 00  Numbers in boxes indicate the order of presidential service and are linked to the article about the president.
    Changes are indicated by   icons for increases due to inaugurations and   icons for decreases due to deaths.
Period Time span Living presidents Starting and ending events
Apr 30, 1789 – Mar 4, 1797 7 years, 308 days 1  01 
Apr 22, 1994 – Jan 20, 2001 6 years, 273 days 5  42  41  40  39  38 
Jan 20, 2001 – Jun 5, 2004 3 years, 137 days 6  43  42  41  40  39  38 
 00  Numbers in boxes indicate the order of presidential service and are linked to the article about the president.
To consider/done
  • Wait wait. So every From line is an exact repetition of the previous To-line. That is not good. And of course the event dates are repeated. Nice puzzle. -DePiep (talk) 18:52, 24 February 2017 (UTC)
See #Timeline: Events and periods
  • Done: Show explanatory rows (using table !, |-, and |). Add class=unsort for bottom row (added row), shows it does not sort. Some text changes, visible. Unbold From and To. A try: last column to sort on 1st name mentioned, not date (or: name of sitting pres?). Added: collapsible (which has no effect in mobile view ever, keep in mind)
  • Is the nowrap really necessary, and everywhere? You are forcing the table to be wider than the page (hor scrolling needed, even on my regular desktop screen).
Changed: somehow I turned it off. Now the dates are breaking -- looks less good.
  • I have set font-size overall to 90%, which is acceptable in a table or infobox (because has more structured layout compared with text lines).
.... but: we cannot stack font-size % (they multiply), so I removed "font-size:85%;"
  • Todo: check mobile view (for example, see very last link at bottom of this page).
  • Using {{unbulleted list}} in From/To-column, instead of <br>.
{{unbulleted list|1=From:...|2=To:...}}. Should be full cell content (no text outside this list).
This is nearly invisible, but it gives better HTML code: a true list (something with <ul>). Whitespace changes, but this is as the WP design is for lists. Bonus: check the effect in mobile view: linebreaking was wrong there (it had overlapping texts with me).
  • Added text in [[File|+, - |12px|Number increased/decreased]] (tooltip aka image title)
  • Replace 'Washington 01' with 'Washington &nbsp;1' or simply '... 1'? Has bad sort effects?
  • Formally, a number box only should be linked once (at first appearance; inauguration?).  43 . Unfortunately, Rbox does not have this option? {{Rbox}} can. See doc, about param 1 and 2.

About the number-colours

  • We need at least 7 distinct colors (max VP number). To check: maybe nos 1 and 8 can overlap (live together), while numbers in between are gone! I'd say 9. (but too much would reduce their main function of distinction (recognition). Current Pres list has 10.
checked. See VPs Jan 20, 1993: list spanning 9 numbers, so we need 9 colors minimum.
Current colours are too strong. They are only background colors! They require switching from black to white fonts, which indicates possibly bad contrast (WP:ACCESS, risk of bad visibility; that could be checked by a calculation -- not now). Sad! I'll restart from scratch.
We need lighter tones. That can be set (calculated) by HSV color space: H=hue number (we choose, 9x); and use the same S-V values for each (the color is now defined), and convert HSV to #RGB triplet. So a color would be defined as: H=90°-S=15%-V=95%.
Approach: we pick 9 hues (what we call 'colors', irrespective of their brightness and tone etc.). They are have a number from 0-360 (degrees).
These are 9 hues From the rainbow. From that table, we use the third column (Hue + Saturation 15% + Brightness 95%, these HSV values are already converted into #RGB).
uses {{rbox}}
Color sets
Old: 10 colors.
New: 9 colors. H=40 deg per step on hue circle. S=15%, B=95% fixed (from this list).
  •  01   01  -- hue=0
  •  02   02  -- hue=40
  •  03   03  -- hue=80
  •  04   04  -- hue=120
  •  05   05  -- hue=160
  •  06   06  -- hue=200
  •  07   07  -- hue=240
  •  08   08  -- hue=280
  •  09   09  -- hue=320
  •  10   10  -- restart new circle, hue=0 again
  •  11  -- restart old circle

Improved new color set: alternating

The new colors above have this issue: neighbors look too much alike. That's because it nicely follows the color circle. But we prefer more alternating neighboring colors. (not: red-orange-yellow, but: red-blue-orange-purple). We do so by reordering the color list. After each color, the 'most opposing color' (hue) follows, by H=+160deg. So: 1=0, 2=160, 3=320, 4=480 (=120) etc.

  •  01  -- hue=0
  •  02  -- hue=160
  •  03  -- hue=320
  •  04  -- hue=120
  •  05  -- hue=280
  •  06  -- hue=80
  •  07  -- hue=40
  •  08  -- hue=240
  •  09  -- hue=200
  •  10  -- hue=0 restart
  •  11  -- hue=160


  • (Note to YBG: here I finally found this solution for our -todo- periodic table categories-coloring!!! 'most opposing color'. And: it is even circular too, so OK when going over 360 deg! that is: across noble gasses, like in Janet's left step :-) ) -DePiep (talk) 11:19, 24 February 2017 (UTC)
Considerations
  • For now, I suggest using these colors. #RGB number is in code. But minor improvement might be possible (see below).
  • I don't think Wikipedia explodes if you use your original colorful tables right away, and later replace them with new colros so you have time to edit. No problem
Main achievements
  • The WP:ACCESS color contrast is OK (font-on-background readability). This is such a huge issue Wiki-wide (that's WMF), that this failing alone could invalidate a whole table.
  • The page is more at rest for the eye. No strong background colors any more (grabbing attention for no reason), no extra switches like font-white & font-black, all background colors in one tone and all fonts are in black.
  • color still supports the number, and has no individual meaning (good design).
issue/to look at
  • The {{Rbox}} does allow for unlinked text yet (param 2 blank, see doc). todo, not overlinking.
  • Colors are not that "bright" any more. For the author (editor) that could be a drawback, but understand that for the Reader it is an improvement.
  • Font is black, not wikilink-blue. Acceptable imo.
  • Looked at mobile view. No issues seen.
  • Well, going from 10 to 9 makes search-and-replace not that useful... I say: it's worth it.
  • Tweaking possible: the colors could be a bit more bright (more reddish, say)? For that, we'd have to pick a new ...-S-V setting that does that, while still keeping the contrast ok (w3c rules). That's a tough exercise.
  • For now, I'll leave this but I'm listening for pings etc. -DePiep (talk) 11:19, 24 February 2017 (UTC)

Timeline: Events and periods

This is the problem with the table structure. It is a timeline, with events (moments, day 20 Jan 1924) and periods (intervals, 7 years). These should not be in one row, but (ideally) below each other. I'll try to come up with an improvement. -DePiep (talk) 19:07, 24 February 2017 (UTC)

  • Here we are.
Table setup

Events numbered 1-3-5-..., Periods numbered 2-4-6-...

event (2 cols) period (2 cols)
Event E x Period P z
E1 E1x P0 (blank, start filler)
P2 P2z
E3 E3x
P4 P4x
E5 E5x
P99 (blank, end filler)
Changes wrt current table:
  1. Events go left: date, reason (inauguration, death).
  2. Periods go right: timnespan 'yrs', number of press

One can split the events (as is done now: date and +/- columns are not next together). I do advise not to want that.

Yes it would be a big and difficult and precise move of data (for 100 main rows Pres+VP). Pls think about if & how to proceed. If you like this (for now), I have time.

-DePiep (talk) 19:53, 24 February 2017 (UTC)

Next step in development
  • See what happens in my sandbox. Expect: you will get two row-subtemplates to fill the table rows:
{|
<!-- title stuff goes here -->
|-
{{us-p-or-vp-alive/event |1=E3 |date=02-02-2002 |event=inaug CCC |pres-number=02}}
|-
{{us-p-or-vp-alive/period |1=P2 |period=1 year |status=Presidents 01, 03}}
|-
...
<!-- table closing stuff goes here-->
|}

YBG summary of and response to DePiep

Here's YBG's attempt to catalog and respond to DePiep's ideas, indicating which have been incorporated in the table I've just revised. If I've missed any, let me know. If you want to discuss any of these points, it might be best to start a new section rather than trying to start a threaded discussion in this table.

The list below began single hierarchical bulleted list, but it has been reformatted into sub-sections for ease of editing. Unmarked items below are generally YBG's initial comments. Responses are indicated by icon:   Comment. by DePiep and   Note: by YBG. YBG (talk) 16:56:42, 2 February 2017 (UTC)

General table format

  • Table headers and footers
    •   Done - Legend: Change from |+ to colspan=all and trim verbage. — I also combined the two legend lines
    •   Done - Footer: Add table footer — I used ! instead of sortbottom and also added column labels
        Comment. Maybe no bottom repetition? Its not that complicated a legend, so readers can remember. I just wanted to illustrate how to don't-sort-this-row. -DePiep (talk) 10:43, 25 February 2017 (UTC)
  • Formatting of table as a whole
    •   Done - Font: Reduce font size
    •   Done - Collapse: Make table collapsible
    •   Later - table markup: One-line-per-cell instead of one-line-per-row
      One line per cell interferes with my workflow - storing the wikimarkup in a 29-column sortable MS-Word table with a hidden sort field so I can sort and edit the data and paste it directly into WP. My latest version doesn't strip the tabs &c so you can see what I mean. This facilitates rapid reorganization. But I expect to use one line per cell when moving to article space.
        Comment. Not needed. Just easier when I was doing manual editing, keeping overview. Maybe the final version could be made more eye-friendly.

Formatting of specific elements

  • Comments about changes affecting a single type of visual item
    •   Doing... - Icons: Tooltips in the +/- icons
        Question: Tooltips in every row or just the legend rows? Is it really needed with my even terser legend?
        Comment. I'd say: with every image. Helpful when a reader is halfway the list and hoovering. Also good for non-image viewers (text readers, as used by blind people).
        Note: OK, I'll do this - and fix the mobi problem.YBG (talk) 17:16, 25 February 2017 (UTC)
        Note: Mobi OK, but textual +/- doesn't stand out like the icons did. YBG (talk) 18:47, 25 February 2017 (UTC)
        Comment. ? I don't understand. Not a textual "+" (keep using the files), but a title with the File. That title shows for example when you hoover a mouse over it, and for example when someone does not have the image (so they get the title text instead). Much better than seeing the filename. Must say, there is no need to have them 'stand out'. They are not the main info. -DePiep (talk) 23:55, 25 February 2017 (UTC)
      I see you use {{abbr}} now but that is bad. Abbr is for - well, abbreviations only, not for helptexts or so. How seductive it is. (W3C, and WP follows, is very strong about good semantics). So: use those +/- files, add titletext (in the [[File:..|12px|title]] as I showed) everywhere, drop the {{abbr}}. -DePiep (talk) 23:55, 25 February 2017 (UTC)
        Note: OK, I'll go back to the graphical +/- and see about a better solution for their ugliness in mobile view. YBG (talk) 00:23, 26 February 2017 (UTC)
  Comment. why not ... just the + and − characters?, Noting extra with them. The legend will do. -DePiep (talk) 01:00, 26 February 2017 (UTC)
  Note: Will do. Turns out it seems to be a subtle bug in the mobile view, which I have documented and reported here. And have a look at the version numbers. I'm really quite fast when I put my mind to it. YBG (talk) 01:59, 26 February 2017 (UTC)
    •   Done - Initial zeros: Eliminate them — Planned to do this but forgot. {{0}} is very helpful
    •   Done - Redundant pipelinks: Change X|X to X — Maybe undo some to condense names, e.g., J. Q. Adams instead of John Quincy Adams.
    •   Done - List: use {{ubl}} instead of <br> — I also used {{ubl}} for dates, to save some horizontal real estate.
    •   Done - From/To/and: No bold/italic
        Question: Is the vertical alignment using {{0}} an improvement?
        Comment. I see nothing wrong, nor can I remember the previous situation. Today each cell has good vert alignment (vertically centered). Date positions great too, esp when there are three facts. Whitespace per cell may be an issue (as said, very much ws in mobile view. cellspacing=0? cellpadding=0?). If you mean the positioning of the single digit 1-9 numbers (their hor positioning then): go as you like. Right-aligned and center-aligned both OK.
        Note: I meant the white space just before "To" and "and" that lines up the colons. Is this helpful ? YBG (talk) 17:16, 25 February 2017 (UTC)
        Comment. no, always a bad habit to do layout with space-counting like in {{nbsp|19}}and: (Tyler, #10). (Same as <br> for listmaking). Does simple ":" (colon at newline) work? (I see {{Indent}} works with spaces too; best be would some <span style="..."> setting. But that's tooo perfect for this). Next: as it is now, with 19! spaces, it looks extremely irregular, and therefor ugly. I'd start with 1 or 2 spaces, just an indent below the "To:" is enough for the eye. (Ideally, one would vert align the visible colon...). -DePiep (talk) 00:09, 26 February 2017 (UTC)
        Note: Agree, it is pretty ugly and space counting is also. But if the alignment problem is fixed, what do you think about putting the date before the link-to-the-event? YBG (talk) 00:28, 26 February 2017 (UTC)
  Comment. That order is very good. I personally would go for separate columns (without a border between), so that the events (ianaug links) align nicely. Also helps/solves the and:-indenting. Maybe even, how would it look: 1. +/- col, 2. date col, 3. event col? Just out of the box. Very minor from here btw. DePiep (talk) 01:06, 26 February 2017 (UTC)
  Note: That's a great idea. I'll see what I can do. YBG (talk) 02:02, 26 February 2017 (UTC)
    •   Done - DAB: TR’s and LBJ’s presidential inaugurations
        Question: Do any other inaugurations need an added ordinal?
        Comment. No more DAB links present. (With me, links to a DAB page are orange - a Preference set). OTOH, the ordinal 1st with George Washington has no follow-up with his 2nd. Logically sound, but I had to think about that when reading (it caught my eye).
    •   Declined - Linking: Reduce overlinking in table
      The MOS allows overlinking in tables. IMHO it desireable in tables, especially sortable ones. In this case, the link maps the number to the officeholder, serving as a legend, which is especially important when the table is sorted.
        Comment. Nihil obstat.
    •   Comment. Mobile views: Nothing broken. Looks good in general. The 3-line cells (dates) work out well.
      I looked at both fullscreen (by bottom-of-page link), and smallscreen view (a tab option I have set; in a smartphone-image). Notes:
      • In the legends top and bottom: the + and - images align left not next to their text. Maybe all three texts to left-align?
          Note: Yea, I noticed that too. Real ugly. I'll probably change it to something like +/− or +/− YBG (talk) 17:16, 25 February 2017 (UTC)
      • Smallscreen: when 6 presidents live (e.g. last row), the 6th color box overflows into next line. Just a colored strip, not the number.
      • Mobile views use very much whitespace in cells. Is there a setting that causes/can reduce that?
          Note: Needs fixing, but how? YBG (talk) 17:16, 25 February 2017 (UTC)
  Comment. In the table top line, try:
{| class="wikitable" cellspacing=0 cellpadding=0 style="..."
Should work for the whole table (all cells) at once. Dunno if it is kept in mobile view. Don't know how else to do, or one should style each cell individually (like padding:0 border:1px). Probably that {{unbulleted list}} adds extra outer whitespace. You know what padding/border/margin are/do btw? -DePiep (talk) 00:18, 26 February 2017 (UTC)
  Note: As I view the mobile view, it seems to be adding extra whitespace between the list items. I am familiar with padding/border/margin ... but have to look them up every time I use them and then figure out how to translate w3 documentation into wiki markup. YBG (talk) 00:37, 26 February 2017 (UTC)
    •   Comment. In general: well done, picked up nicely from my single pile of changes. I just made notes & suggestions so far (one-way; for use or discard), not issues to be discussed. -DePiep (talk) 10:43, 25 February 2017 (UTC)

More complex issues

  • These are changes that by their nature may require research and/or discussion.
    •   Declined - Periods/events
      The repetition bothers me also. The version in article space avoids this by having no event column and wikilinking the dates. An earlier version showed only the starting event. But both events are needed for context when the table is sorted. I'd already played around with period/event staggering and gave up on it because it gets ugly when the table is sorted. Bottom line: if the table is unsorted, I would stagger periods and events as you suggest. But I'm not willing to give up sorting. Maybe there would be a fancy way to use collapsing to give the reader an option of a sortable table with repeated events or an unsortable one with staggering that avoids repetition.
        Comment. Do not spend time on any 'smart collapse' route. Collapse does not exist in mobile view, so there is no solution in there. Agree sorting must be kept, but my demo (sorting added) does make a sensible show. When sorted, it nicely replicates each split row (so any From-date becomes a second, To-date cell etc.). Not looking very elegant (now), but is is correct. I state that the full repetition as it is now is ugly and bad. (And making the table ~twice as long). An improvement is needed in this.
        Note: Consider the 'dumb collapse' idea to be DOA. For now, I'll go with sorting-repetition-unstaggered. But if you figure out a clever way to have both staggering and sorting, I'd be very interested. YBG (talk) 17:55, 25 February 2017 (UTC)
    •   Done - Reorder (YBG idea) #/list; Events; Dates; Span
      My reordering is different from the one you suggested with staggering events and periods. I kept the event column immediately to the right of the list column so that the event column can function as a legend for the list column, at least when the table is sorted chronologically: just scan up to the inauguration or down to the death. I have further considered moving the date column to be between From/To and the event link, so it reads (e.g.) -[02] From: Jul 4, 1826 Death of John Adams. Reorganizing columns like this is very easy with my offline storage of wikimarkup.
        Question: Which do you think would be best: the original column order (Dates-Span-Lists-Events), the current order (Lists-Events-Dates-Span) or a revised version which inserts the dates between From/To and the event link?
        Comment. Yes, great column ordering. More natural flow left-to-right. Merging the date into one cell looks fine. But you'll miss the option to sort by date or by pres name (can have only one in a column). BTW now too because of the shared columnheader. Did you consider to somehow sort by pres name?
      Answer: I prefer current order, keep separate column for the dates (for sort reasons, so separate header cell, could be empty why not). The +/- column best sorts by pres name. Yes swapping columns +/- and date (date as 2nd col) is even better, for reading logic & expectation IMO. -DePiep (talk) 11:16, 25 February 2017 (UTC)
        Note: See my note below. YBG (talk) 17:55, 25 February 2017 (UTC)
        Note: I've moved the dates into the event column and gave up trying to align the colons. Could still do it with {{0}} if it has merit. YBG (talk) 18:52, 25 February 2017 (UTC)
  Comment. See my note below. DePiep (talk) 02:49, 26 February 2017 (UTC)
  Comment. This is my note below. My guide would be: how does a Reader read/glance a table? (really, glancing is half the reading, it's not that superfluous as it sounds. That's why we do layout & structure). That is: top-down, left-to right. So e.g. a row should show interest-logic like: main fact - background - cause (or so). -DePiep (talk) 02:49, 26 February 2017 (UTC)
  Note: Well said. But it may well be that "glancing" is more than 50%. YBG (talk) 04:00, 26 February 2017 (UTC)
  Note: See my note (immediately) above :) YBG (talk) 04:00, 26 February 2017 (UTC)
    •   Declined - Person sort
      This is one of DePiep's suggestions I forgot to include in my initial listing (are there others?). I don't think sorting by presidents is very helpful. I once tried to implement a scheme with not only sorting-by-person (actually, by order-of-service) but also sorting-by-event-type. Which person is best associated with a row: the beginning-event-person or the ending-event person? And what to do about the eight instances of mid-term succession when there are two presidents associated with an event? (This wasn't an issue with sort-by-order-of-service.) At any event (pun intended), other wiser heads prevailed in the collaboration and convinced me simpler is better, so I abandoned the idea of sorting by person. YBG (talk) 17:55, 25 February 2017 (UTC)
  Comment. I'd say: the core events column ("inaug of X") could sort on sitting pres name. That's all. Isn't that something one expects to find? How else would one discover that there were two Clintons already? -DePiep (talk) 02:34, 26 February 2017 (UTC)
  Note: To find common last names, that info, you'd look at one of the other, simpler list of the Presidents or VPs. The main table isn't sortable, so you'd have to look at another one from {{Lists of US Presidents and Vice Presidents}}, say the first one, List of presidents of the United States by age. But even that wouldn't help you because the older Clinton was a VP, not a President. Here's a list of the shared last names: Adams (V+P father, P son); Bush (V+P father, P son); Clinton (V, P, no relation); Harrison (P grandfather, P grandson); Johnson (V, V+P, V+P, all no relation); Roosevelt(V+P, P, cousins); Wilson (V, P, no relation). Almost certainly not a notable stand-alone list. And while we're talking about non-notable trivia, the most interesting factoid I've come upon recently is that in 1961, Richard Nixon, the 36th vice president, was succeeded by Lyndon Johnson as the 37th vice president. Upon Kennedy's death, Johnson had became the 36th president, and in 1969 Nixon returned the favor by following Johnson as the 37th president. YBG (talk) 03:55, 26 February 2017 (UTC)
    •   Later - Colors
      As you probably guessed, my choice of 10 colorings was driven by the ease of grepping the change. But a bigger reason (IMO) why the alternating 360/(2n+1) doesn't work well is that the lists frequently include non-consecutive numbers. There are 81 deltas of two, 23 of three, 10 of four, and even 1 each of five (Presidents 13 & 8, Filmore & Van Buren), six (VPs 28 & 22, Marshall & Hamlin) and seven (VPs 22 & 15, Morton & Hamlin). Also notice how close VPs 36 and 46 (Nixon and Cheney) are in the VP event column - there is only one cell between them! Separation here is important so that the event column can function as a legend for the list column. For these reasons, I don't think the 360/(2n+1) system will work well here - but I believe it holds promise for the periodic table.
        Additional information needed Your further thoughts re color given these concerns would be much appreciated.
        Comment. We could look for 10 colors not 9. But more colors absolutely implies that they are closer together (36 deg instead of 40 deg): less discernable, bad for their legend function. More so since I want to go to the softer backgrounds: less bright colors means less outspoken 'red' etc. (Also, I'd have to calculate #RGB from the 36 deg steps, while the 40's were available. For now, I am not pondering making your grep s&r easier ;-) ).
      I note that the alternating order is just an improvement once a color set is chosen. It is a free improvement: it does not reduce degrees of freedom in color picking! I agree that the numbers do not always happen in their perfect sequence, so the alternating trick does not come out always. But still, the colors must be distinct enough to do their function anyway, even when neighbours neighbour (two near similar colors nearby each other). If this is not working ok, in whichever color order, the color set itself is bad (it fails).
      Let's keep in mind: the current strong colors are not a good design (I hope you can agree). Also, the colors are just supportive: the number itself is the ID. The table could do without colors without losing information! And the flip side is: any reasonable color set could be OK, there is some leeway.
      So, we must find colors as much apart as possible (9 is better than 10), try to improve brightness without breaking contrast rules (todo), and shuffle them anyway to help distinction for free.
      I'll take a look at the brightness (more outspoken red etc). -DePiep (talk) 11:58, 25 February 2017 (UTC)
        Note: No argument from me as far as brightness goes. It was when I was unsuccessfully messing with RBG values that I thought to call in the DePiep cavalry. Having decided to do that, I just grabbed a convenient set of HTML color names and called it good-for-now. But I turned 5 or 6 hues into 10 combos by using a second dimension, text-color plus brightness/darkness. What about using font color or the presence/absence of a black border to turn five hues into ten combos? This is an option we don't have in the PT where the border is already used to indicate natural occurrence and the font color for state of matter. YBG (talk) 17:55, 25 February 2017 (UTC)

Hope all of this makes sense to you, DePiep. Your input is very much appreciated. YBG (talk) 09:09, 25 February 2017 (UTC)

Thanks once again for all of your input! YBG (talk) 17:55, 25 February 2017 (UTC)
  •   Comment. End of the day: of course these two tables are fit for mainspace (take care they won't be AfD'ed...). I have not checked other comments elsewhere. Any remaining topics (big: do not repeat lines, not those flashing colors, ideal column setup), all can be solved/improved

when this version is live. Also helps to not get lost in details. -DePiep (talk) 02:42, 26 February 2017 (UTC)

More re colors

Here's a summary of the color schemes that have been used and proposed. More to follow. YBG (talk) 03:51, 27 February 2017 (UTC)

I have added two sets from http://colorbrewer2.org, CB1 and CB2. CB2a is the same as CB2 but with the darker gray from CB1, which looks like it will work better with the wikitable background. I may not get to it for a few days, but I hope to implement CB2a and see what the resulting table looks like. YBG (talk) 04:29, 27 February 2017 (UTC)
CB2a has been implemented. YBG (talk) 08:06, 1 March 2017 (UTC)
Alternative color schemes, with links to sources (src) and a permalinks to implementions (V:P)
YBG original
V:P
  •  01  w/Orange
  •  02  w/Red
  •  03  w/Purple
  •  04  w/Blue
  •  05  w/Green
  •  06  b/Yellow
  •  07  b/Pink
  •  08  b/Violet
  •  09  b/LtBlue
  •  10  b/LtGreen
  •  11  w/Orange
 DePiep#1 +40°
src
  •  01 hue:0
  •  02 hue:40
  •  03 hue:80
  •  04 hue:120
  •  05 hue:160
  •  06 hue:200
  •  07 hue:240
  •  08 hue:280
  •  09 hue:320
  •  10 hue:0
 DP#2
src
 +160°
 
 CB#1
srcV:P
CB#1a
src
 CB#2
src
 CB#2a
V:P
 CB#2b
V:P

Q&A

@DePiep: The latest version includes several changes, including

  1. Event: Reordering the subcolumns
  2. Event: Removing vertical line between sub-columns
  3. Event: Changing line spacing
  4. Colors: Changing to colorbrewer 9-pastel qualatative (Only major glitch is +VP#45 is adjacent to -VP#36)

I'd appreciate your thoughts. YBG (talk) 05:14, 1 March 2017 (UTC)

PS. Note the summary of color options just above. YBG (talk) 05:15, 1 March 2017 (UTC)
  • Replies. When unclear, ask. I often check at [1], the w3c css (style) definition. You can skip the red notice. I can check two screens for mobile view (smartphone upright and desktop).
  • Styles & white/spaces
  1. styles: trivial, fyi: nowrap in tablestyle is equal to style="white-space:nowrap;" in css.
  2. Nowrap in mobile view (smartphone): the events (inaug, death) wrap lines, so the table is extra long. Undesired imo. Some recent change (has todo with change width:100%;? nowrap does not work?).
  3. Desktop view: whitespace between From and To-lines disappeared (two numberboxes glued together). Too tight? (A: Yes. The 2nd box is overlapping the 1st box always, the colors show).
  4. What is does "line-height:1.6;"? It's legal, but I don't exactly know what value is set. Sometimes I try using em size, like: "line-height:1.5em;". However, with this other effects can have an effect.
  5. In the multi-line cells, try: 'style="padding:0 2px 0 2px;'. (padding=surrounding whitespace in the cell, between text and border. The 4 numbers are for -top, -right, -bottom, -left respectively. (So this reduces top/bottom ws). And/or: the {{ubl}} could have a 'style="margin:0.2em;"' (margin=outside ws outside of the box; here it overlaps/isaddedto the cell padding). Effect setting it to 0?
  6. In general, you are squeezing to much in the wrong places. (Once you have chosen to keep the repetition of To-lines, you'll have to accept some consequences such as extra ws).
  • Colors
  1. The new colors are great, and what I was looking for (well, thinking of). CB is great. Later on I might as which CB-options you have used. One question: did CD really add a grey, #9? It is a bit out of the line. (and #7 brown?)
  2. You could allow a manual change: the CB-2a #6 yellow is light, could be CB-1a #2 yellow? (because yellow is so light by itself somehow, I would take designers freedom to tweak it after the CB outcome).
  3. I have not checked the colors in detail. I'd like to learn (from CB?) eg like whether #7 brown is acceptable (is not a rainbow color...). And why no two greens are acceptable.
  4. VP36-VP45: trick: from VP45 to VP48 (end) skip color #9 grey! (so sequence is: VP43=cb7, VP44=cb8, VP45=cb9 cb1!, VP46=cb2, .... -DePiep (talk) 09:10, 1 March 2017 (UTC)
  • Other
  1. I'd change "8 years, 0 days" into "8 years". -DePiep (talk) 09:10, 1 March 2017 (UTC)
A few quick notes.
  • line-height:1.6 was just an effort to unto the table-wide application of line-height:1.2 which is what made the from/to boxes overlap. Probably should use "em". And the "1.2" should maybe be bigger.
  • I've included direct colorbrewer links above so you can see for yourself what the brew meister produced. CB1, CB1a and CB2 are direct from Colorbrewer. CB2a has a hand-modified darker gray.
  • Regarding 8 years 0 days, that's what the template produces. I'll check if there's an option, but I'd prefer to avoid hard coding it.
Thanks for your input. YBG (talk) 09:17, 1 March 2017 (UTC)
re '8 years, 0 days': see this, the reply by Jimp: he wants the zero kept b/c of precision noting. A good point, more so because this topic returns often at {{convert}} (talk), and usually Jimp is one of the stabilising editors in there. -DePiep (talk) 09:33, 2 March 2017 (UTC)
  • From above, I c/p repeat here:
me: {| class="wikitable" cellspacing=0 cellpadding=0 style="..."
you: Note: As I view the mobile view, it seems to be adding extra whitespace between the list items. I am familiar with padding/border/margin ... but have to look them up every time I use them and then figure out how to translate w3 documentation into wiki markup.
My re now: very strange! Maybe: 'adding extra whitespace between the list items' - set by line-height in {{ubl}}, separately? Or do they interact (if they do, research is very difficult, better leave it). -DePiep (talk) 09:22, 1 March 2017 (UTC)

More Q&A

  • Just an idea: write "Gerald Ford inaugurated", "Richard Nixon dies/d" (linked). Could save five letters per line! Plus: helps the reader who will be name-searching foremost, if anything. -DePiep (talk) 11:12, 1 March 2017 (UTC)
  • To show that we are not amateurs: there is a rationale for making color#6 yellow darker than cb-calculated/advised at first. That is: the colors must also stand out against the background (a very light grey). I don't know about a w3c contrast rule for this (as exists about font-bg contrast). btw, each new color column is an improvement, so the rightmost is best, imo. -DePiep (talk) 10:00, 3 March 2017 (UTC)
  • Allow me to repeat the "VP36-VP45" note by me above, for your attention. Could be useful, you might have missed it (you usually respond). -DePiep (talk) 10:07, 3 March 2017 (UTC)
    I saw that, and will probably do it, but not just yet. YBG (talk) 21:27, 3 March 2017 (UTC)
  • Very late, but please consider. About the order of columns. When thinking about natural reading order in a row, I'd expect this order:
1. start+end events, 2. time span, 3. living presidents.
That is, the order shows "what happened, and what is the result". (Technically, only column #1 moves to position #3). -DePiep (talk) 10:13, 3 March 2017 (UTC)
Thanks for being more clear. I took your comment into consideration in my most recent rearrangement, but I didn't completely understand what you were aiming at. I'm strongly inclined to keep the list relatively close to the colorboxes in the event column, but having said that, I will give it some more thought. As that rearrangement is relatively easy for me to accomplish in my off-line source file, I don't mind taking some time to think about it. One other reason for putting that column first is that it is the subject of the table. This may have contributed to the AfD comment "the time period in which a former president is living has not been discussed in RS" since with the time period first it seems like the time period is the subject of the table, when in fact the number of living Presidents is the subject. This probably isn't a real good reason, because in fact most tables begin with key (database) columns. YBG (talk) 21:27, 3 March 2017 (UTC)
re for being more clear - you c/should have asked ;-) ;-)
re ... it is the subject of the table -- not exactly. It is the subject of the article. The table is just to illustrate/explain/prove the article. And also, the last column is not behind the other side of the moon.
re 'database key first' -- in our world yes, but not for the Reader!
re AFD: no comment.
re: pres name search & sort: later more. (I still don't get why you think name-search is irrelevant. Must reread your posts here).
-DePiep (talk) 22:04, 3 March 2017 (UTC)
Re being more clear - the problem was that I thought I completely understood, but in fact I did not. Sigh. YBG (talk) 02:07, 4 March 2017 (UTC)
Re name search - the problem is which name to use? The one whose event started the period? Or the one whose event ended the period? And keep in mind that some periods begin and end with inaugurations and some begin and end with deaths and some begin with one and end with the other. So we can't go with sorting by the name of the president inaugurated. Sorting by incumbent's name would seem weird to me without a column that gives that President's name (and all we need is another column). It would line up the colored boxes that begin each line, but I still think it would be far from obvious what is going on. YBG (talk) 02:07, 4 March 2017 (UTC)
First, this sorting is not essential here (date is, and sitting pres by numberbox is; already covered). It would need its own columnheader (column to split). Then, an event could sort informatively by the family name of the From-event. It would group the career events by name. That's all, but it is something. -DePiep (talk) 14:27, 4 March 2017 (UTC)
  • On the subject of the AfD, there are a number of reasons why this list doesn't have anything equivalent to the UK's interregnums or regencies. If you are interested, let me know and I'll be happy do discuss it here or on one of our talk pages. YBG (talk) 21:27, 3 March 2017 (UTC)
  • Here's what I see needs to be done, in rough to-do order.
    1. Get the spacing right on the multi-row cells
    2. Figure out how to insert line breaks into the wiki markup in the appropriate places so it is actually possible for someone other than me to do some editing
    3. The VP36/45 issue
    4. Column order
    Can you think of anything else? YBG (talk) 21:27, 3 March 2017 (UTC)
Easy steps first:
We do freeze color development. Good. Stop spending time. It's OK.
Put them live asap. They are better that today's. Comments are welcome.
You look at VP36/45 color solution. Solve or note an issue.
Column order: you choose smartly & we'll stick to it.
So by now the tables are live. (Did you consider transcluding them, once, from template space? Want advice ;-) ?).
Only this. You mention whitespace (ws) issues, which I did not spend much time on so far. I'll take a further look, also in mobile views. For now: ws not deadly, so you can put them live. -DePiep (talk) 22:23, 3 March 2017 (UTC)
re 'ease of maintenance by editors', vs your offline spreadsheet: maybe create a subtemplate that formats a complete row (parameters suggestion -very rough-: eventTo, eventTo2, eventFrom, eventFrom2, date1, date2, event1, ewvent2, event3, pres-alive-list). For this table template I added this subtemplate/row-formatter. -DePiep (talk) 22:41, 3 March 2017 (UTC)
Let me think on these things. One of the reasons I'm not being very bold is that my previous effort with this article was premature and got shot down my a number of other editors. So I'm trying to be a bit slower now. YBG (talk) 02:07, 4 March 2017 (UTC)
I get this. -DePiep (talk) 09:52, 4 March 2017 (UTC)

And more Q&A

OK, I've made some more changes.

  • Colors. Incremented VPs>44. Colors are done.
  • Column order. I started with your Events-Span-List and tweaked it a bit, including the order of the event subcolumns. The result, Event(Date/Event/Change)-List-Span, keeps the two columns with boxes proximate to each other.
  • Line spacing. Turns out that "em" is understood when there is no modifier. I did increase it from 1.3 to 1.4, so now there is a small gap between the boxes.

Comments? YBG (talk) 06:19, 4 March 2017 (UTC)

Re line spacing: with me, regular desktop at 100%: no vert whitespace between two number boxes in event column. There could be a tiny overlap even (1px?). When at 110%, there is ws OK.
pls check VP death Nixon date. -DePiep (talk) 09:55, 4 March 2017 (UTC)
Found a typo in the header, probably not in the spreadsheet (see diff).
Tried: ubl|item_style=text-align:right|Apr 21, 1789|Mar 4, 1797 for dates (done in first row in VP table). To right-align the years. Not sure if that's much better. -DePiep (talk) 10:05, 4 March 2017 (UTC)
Can you summarise/point to the whitespace & format issues still open? -DePiep (talk) 10:05, 4 March 2017 (UTC)
I've removed the line-height. I mistakenly thought it was fixing the ws problem in mobile view. Spacing is acceptable in desktop, but I would like to fix it in mobile. IIRC, an earlier version had fixed (or at least improved) mobile spacing by inserting a style int each and every {{ubl}}. The line-heights in the table header and was an attempt to do the same thing with fewer chars, but it didn't work. I'll go back to putting it in the ubl. YBG (talk) 13:50, 4 March 2017 (UTC)
  • Excessive ws in mobile. One cause found: the column "+/- numberbox" is split over into two rows. Cure: use {{nowrap}} in the widest situation (#48 Pence) [2]. (The nowrap with #1 is useless). Result: no split lines there any more (with me). -DePiep (talk) 14:19, 4 March 2017 (UTC)
Next: the line with 7 VP numbers breaks. Add a nowrap there too?
Also: mobile, still much ws between From and To line (not excessive, just much). -DePiep (talk) 14:19, 4 March 2017 (UTC)

Vertical ws in ubl

This table is an attempt to find the best style to use with {{ubl}}. YBG (talk) 14:34, 4 March 2017 (UTC)

Alternative {{ubl}} styling
No style
list_height:1.2em in ubl.style
in ubl.list_style
in ubl.item_style
in cell.style
1.3em
1.35em
1.4em
<br>no ubl

 01 
 02 
 03 

You'll see the same: cell.style is nice in mobile, but bad in desktop. Best are 1.35em (and 1.3em). But you'll have seen that already. -DePiep (talk) 14:53, 4 March 2017 (UTC)
Yea, I'd seen that in desktop - and thought it might be best in mobile, but didn't actually check until after reading your comment. I'd still like to reduce the vertical ws in mobile view. Any ideas? YBG (talk) 15:01, 4 March 2017 (UTC)
I've added <br> option, just to get what is going on. Deletable. -DePiep (talk) 14:59, 4 March 2017 (UTC)
No harm, no foul. It is illuminating. YBG (talk) 15:05, 4 March 2017 (UTC)
The 1.35 setting has been implemented. Now if we can figure a way to reduce the mobile spacing, I think we're good to go. By "good to go", I mean ready to post an announcement on the article's talk page and then wait couple of days and then move to article space. YBG (talk) 16:15, 4 March 2017 (UTC)
The 1.35em setting looks a bit border-penduling. In desktop, sometimes I see no ws, sometimes 1px ws (in #Further refinement below: leftmost col, between #1-#2: 1px, between #2-#3: 0 ws). Also, in the VP and Pres tables I see no ws at all (color number boxes glued together, or even 1px overlap). Maybe 1.4em to be sure? (1.4em this also alters randomly by a 1px, but at least there is ws always).
{{ubl}} is core HTML coding, true <ul> lists etcetera. I was often helped by User:Edokter, who did lots of coding in there (css, HTML, padding, margin; enwiki level). Maybe he can suggest on how to handle that mobile ws in there. Have a nice edit. -DePiep (talk) 19:31, 4 March 2017 (UTC)

Further refinement

Alternative {{ubl}} styling
1.35em
3×padding:0
3×margin:0

Status check

OK, I'm satisfied with the following

  • Colors
  • Line spacing (at least in desktop view)
  • Column orders
  • Wikitext (one-line-per-cell with |- generally every 8th line)

The only outstanding things are

  • {{ubl}} spacing in mobile view

Then after an announcement on article's talk page and waiting a couple of days, ready to go live. YBG (talk) 17:39, 4 March 2017 (UTC)

Good. I take that the earlier critiques in this are covered too. -DePiep (talk) 19:34, 4 March 2017 (UTC)
I've already posted a notice at Talk:Living Presidents of the United States § Colorized list with events, with the caveat that there may be minor changes to improve the mobile view. In has already elicited one positive comment -- and a question from a very observant editor who noticed the discontinuity between VP#44 adn VP#45. YBG (talk) 21:27, 4 March 2017 (UTC)
(ec) Wow. I only just saw those lots of previous remarks over at that talkpage (thanks for pinging me there). So when this goes live people would make many arguable edits in the list (making the spreadsheet ~useless)? Maybe invite-ping all those 2 dozen of people now, before, to comment on your sandbox proposal? -DePiep (talk) 21:33, 4 March 2017 (UTC)
Done. Most of those people pinged never contributed to the discussion. Those who did contribute I believe are likely to agree with AuH20 in thinking our new version is an improvement. At least that's my hope.YBG (talk) 21:59, 4 March 2017 (UTC)
re mobile ws, consider this. Lists like {{ubl}} are very very well designed for wp pages and by w3c standards, using core HTML. These people also took care of the mobile view. Now if we see no broken effects, we can trust that the effects we see are by design. They have reasons to make it show this way, even if we don't understand. Let's trust them. It's OK. -DePiep (talk) 22:18, 4 March 2017 (UTC)
I've modified the examples above, puting each in its own single-cell wikitable. From this I see that the mobile view, even unmodifed, the between-item spacing is much, much bigger than the outside-list spacing. This doesn't seem right to me, but I guess I'll go with you and defer to the mobile view designers. Thanks again for your invaluable input in this effort. YBG (talk) 01:07, 5 March 2017 (UTC)
Thanks, nice way of working. Did you consider putting them in a template each (transcluded once)? One benefit is that it nicely allows sandboxing, since so many people have ideas in this. -DePiep (talk) 16:10, 5 March 2017 (UTC)
@DePiep: I've set it up to transclude from a subpage. What do you think? YBG (talk) 22:35, 5 March 2017 (UTC)
(outdent)
In article space there are no subpages (possible/allowed). The slash is part of the title: AC/DC. -DePiep (talk) 22:47, 5 March 2017 (UTC)
Right, I should have known that. I'll figure out appropriate template names and move those subpages into template space before changing the article. YBG (talk) 06:44, 6 March 2017 (UTC)

In template space

@DePiep: I've moved the pages into template space as {{Living presidents of the United States}} and {{Living vice presidents of the United States}} and created talk pages as redirects and one documentation page with the other one as a redirect. Any chance you could look over what I've done and let me know what needs fixing or maybe even fix it yourself? I'd be very much obliged if you could! YBG (talk) 01:14, 7 March 2017 (UTC)
I've made edits to the VP table, see hist/Template:Living vice presidents of the United States + es's. I repeated just some in Pres's list, plus made new ones. See hist/Template:Living presidents of the United States +es.
Not changed, proposing here:
Change table title into "The number of Vice presidents alive at each moment in United States history". Less text, saying the same (or even more).
I changed it to "Number of" YBG (talk) 22:14, 7 March 2017 (UTC)
Maybe too: "Starting and ending events" → "Period".
I agree but a similar idea was previously rejected. YBG (talk) 22:14, 7 March 2017 (UTC)
If that was by me, I'd ban myself for 3 months. -DePiep (talk) 06:39, 8 March 2017 (UTC)
No, it was part of the long discussion over at Talk:Living Presidents of the United States. YBG (talk) 06:53, 8 March 2017 (UTC)
  • In the article, to consider:
Change section title into "List of living Presidents". Remove most of intro text (belongs in Statistics section anyway). Maybe move Statistics section right below List section (Gallery downwards); keep as section.
Intended effect: in mobile view, the list is not collapsed. However, the Section is! So the mobile reader can easily collapse/uncollapse the table! Long intro text should be avoided, to visually get to the list asap. -DePiep (talk) 09:15, 7 March 2017 (UTC)
  • This is something we missed: both lists start with #1=red. As we wanted, using colors signifies: "same color=related". Especially since the lists are in one article, we now have declared #1-VP connected to the #1-Pres! That is bad. We should have started the VP's with like, #1=color4, then cyclic as usual. -DePiep (talk) 09:51, 7 March 2017 (UTC)
    Not a problem IMO. We have many instances of the same color being not related, e.g., VP1 and VP10 are the same color but not related. YBG (talk) 22:14, 7 March 2017 (UTC)
  • There's a problem with collapsing. My intent is to have it collapsed on the template page so that the documentation shows up without scrolling, but have it start uncollapsed elsewhere, but I don't seem to be able to get it to work. Tried swapping things and removing the "mw-" but nothing seems to work. Probably something obvious that I've overlooked. YBG (talk) 22:24, 7 March 2017 (UTC)
    Seems to work now - without anything having been changed. Probably because the cache wasn't cleared, although I thought I'd done that. YBG (talk) 06:16, 8 March 2017 (UTC)
We could put a short TOC in the very top, but the doc does not look very important. I personally prefer showing in template space for comfort. I left out a |state=uncollapse option for the articles. -DePiep (talk) 06:39, 8 March 2017 (UTC)

ArbCom 2019 election voter message

Latest comment: 5 years ago1 comment1 person in discussion
 Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2019 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add {{NoACEMM}} to your user talk page. MediaWiki message delivery (talk) 00:11, 19 November 2019 (UTC)

ArbCom 2018 election voter message

Latest comment: 6 years ago1 comment1 person in discussion
 

Hello, YBG. Voting in the 2018 Arbitration Committee elections is now open until 23.59 on Sunday, 3 December. All users who registered an account before Sunday, 28 October 2018, made at least 150 mainspace edits before Thursday, 1 November 2018 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2018 election, please review the candidates and submit your choices on the voting page. MediaWiki message delivery (talk) 18:42, 19 November 2018 (UTC)

ox state checks

Latest comment: 5 years ago2 comments2 people in discussion

I hope current Template:List of oxidation states of the elements/datacheck(edit talk links history) is useful & OK. Happy to get your ideas. -DePiep (talk) 20:01, 18 September 2019 (UTC)

  Wow!! You did way more than I was thinking about. Great work! YBG (talk) 20:42, 18 September 2019 (UTC)

MfD nomination of Book:Living officeholders

Latest comment: 4 years ago2 comments2 people in discussion

  Book:Living officeholders, a page which you created or substantially contributed to, has been nominated for deletion. Your opinions on the matter are welcome; you may participate in the discussion by adding your comments at Wikipedia:Miscellany for deletion/Book:Living officeholders and please be sure to sign your comments with four tildes (~~~~). You are free to edit the content of Book:Living officeholders during the discussion but should not remove the miscellany for deletion template from the top of the page; such a removal will not end the deletion discussion. Thank you. ‑‑Trialpears (talk) 02:57, 23 December 2019 (UTC)

Deleted upon my request, see my comments. YBG (talk) 20:29, 9 January 2020 (UTC)

Living Vice Presidents

Latest comment: 6 years ago3 comments2 people in discussion

Your use of negative indices for the deaths on {{Living vice presidents of the United States}} causes an error; when the parameter is "4", the box links to George Clinton (vice president), but when it is "-4" it incorrectly links to George Clinton. By the way, kudos on your mention of "ease of editing" in the template documentation; it shows you have a great sense of humor! --R'n'B (call me Russ) 19:26, 24 August 2018 (UTC)

@R'n'B: Thanks! I will fix it immediately. I'm in the process of revamping the templates, but it does take a bit of time. YBG (talk) 03:16, 25 August 2018 (UTC)
Oops, I see you already made the necessary change! Thanks. By the way, I was actually serious in my comment about ease in editing. I do recognize that it a bit opaque, but I think when I get finished with my next batch of changes I hope you'll agree it is less so. YBG (talk) 03:36, 25 August 2018 (UTC)

Periodic table

Latest comment: 6 years ago3 comments2 people in discussion

Please do not undo again; links are never put in bold on Wikipedia. IWI (chat) 20:16, 24 September 2018 (UTC)

@ImprovedWikiImprovment: Thank you for reaching out to me here. Your 2nd edit summary (MOS:BOLDAVOID links never put in bold. No discussion required)) made much more sense than your 1st one (MOS:LEADSENTENCE), which  didn't seem to apply. Much as I am a big fan the WP:BRD and generally dislike discussion via edit summaries, your explanation was succinct and to the point, and the linked policy clearly explained the situation. Many thanks and happy editing. YBG (talk) 02:15, 25 September 2018 (UTC)
Yes maybe the original summary was a mistake. IWI (chat) 08:33, 25 September 2018 (UTC)

Nomination for deletion of Template:Living presidents of the United States

Latest comment: 6 years ago1 comment1 person in discussion

 Template:Living presidents of the United States has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. ―Justin (koavf)❤T☮C☺M☯ 20:36, 6 October 2018 (UTC)

Nomination for deletion of Template:Living vice presidents of the United States

Latest comment: 6 years ago1 comment1 person in discussion

 Template:Living vice presidents of the United States has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. ―Justin (koavf)❤T☮C☺M☯ 20:37, 6 October 2018 (UTC)

presidents by age

Latest comment: 6 years ago9 comments2 people in discussion

your last edit doesn't seem to have changed anything עם ישראל חי (talk) 20:06, 10 October 2018 (UTC)

@AmYisroelChai: Try it now. YBG (talk) 20:14, 10 October 2018 (UTC)
still don't see a difference what color are you trying to put in עם ישראל חי (talk) 20:37, 10 October 2018 (UTC)
@AmYisroelChai: I'm using |style="background:#eeeeff;", which is a light purplish color. If the color isn't working, feel free to try a bolder color. Alternately, the problem could be that there is also a row style and it might be that on your browser the row style overrules the cell style. Do you see a color in the legend at the bottom of the table? YBG (talk) 20:44, 10 October 2018 (UTC)
i see you're right my computer doesn't show a difference but i see it on my phone עם ישראל חי (talk) 21:35, 10 October 2018 (UTC)
@AmYisroelChai: Try removing the row style on the |- line and see if that makes a difference on your computer. I'm still wondering if it is the color or the interaction between the row-style and the cell-style. YBG (talk) 21:38, 10 October 2018 (UTC)
didn't do anything not sure why that line was there עם ישראל חי (talk) 21:50, 10 October 2018 (UTC)
@AmYisroelChai: That being the case, it probably is just the color. Anyway, its a moot point now that Drdpw has reverted it all. YBG (talk) 21:55, 10 October 2018 (UTC)
@AmYisroelChai: P.S., happy 2nd "C" anniversary, whatever that is. YBG (talk) 22:04, 10 October 2018 (UTC)

A pause

Latest comment: 5 years ago1 comment1 person in discussion

I hope you are OK. Would like to see you back here. Do spend all time well, especially with people nearby. -DePiep (talk) 21:48, 22 March 2019 (UTC)

Welcome to The Wikipedia Adventure!

 
Hi YBG! We're so happy you wanted to play to learn, as a friendly and fun way to get into our community and mission. I think these links might be helpful to you as you get started.

-- 21:13, Tuesday, October 22, 2019 (UTC)

Mission 1 Mission 2 Mission 3 Mission 4 Mission 5 Mission 6 Mission 7
Say Hello to the World An Invitation to Earth Small Changes, Big Impact The Neutral Point of View The Veil of Verifiability The Civility Code Looking Good Together

Indigenous peoples of the North American Southwest

Latest comment: 4 years ago2 comments2 people in discussion

Your edit on Indigenous peoples of the North American Southwest should be undone. It is factually inaccurate to have modern-day borders on a map of what things looked like in 1350 CE because those borders and places did not exist back then. They are completely separate. There is nothing helpful about including the lines people draw on maps today just because some people don't like when they're not there. Myrhonon (talk) 04:03, 9 January 2020 (UTC)

You are correct that it would be factually inaccurate to claim that modern borders existed centuries ago. But they provide context to the reader who might wonder, "Hey, I live in northwest New Mexico. Which peoples lived here long ago?". I believe it is contextually obvious that the map does not claim that those borders existed back then, but nevertheless, I have added a clarifying comment to the caption: "with modern borders to provide geographical context".
I also edited the lede sentence for clarity, but before and after my edit it refers to "the current states of Colorado, Arizona, New Mexico, Utah, and Nevada in the western United States, and the states of Sonora and Chihuahua in northern Mexico." YBG (talk) 20:26, 9 January 2020 (UTC)

You've got mail!

Latest comment: 4 years ago1 comment1 person in discussion

Hello! If you recall that, a few months ago, I promised to write you a big letter of my impressions. I'll send it to you now; I'll greatly appreciate it if you briefly let me know you have received and/or read it, even if you won't be able to write a reply right away or will not choose to do it at all. If you haven't received it, please write to me so I can send you wherever you tell me to. Thanks--R8R (talk) 19:25, 20 April 2020 (UTC)

Notice of Dispute resolution noticeboard discussion

Latest comment: 4 years ago1 comment1 person in discussion
 

This message is being sent to let you know of a discussion at the Wikipedia:Dispute resolution noticeboard regarding a content dispute discussion you may have participated in. Content disputes can hold up article development and make editing difficult for editors. You are not required to participate, but you are both invited and encouraged to help this dispute come to a resolution. The thread is "Periodic table".The discussion is about the topic Periodic table.

Please join us to help form a consensus. Thank you!

--Double sharp (talk) 08:36, 4 August 2020 (UTC)

And just a little thought

Latest comment: 4 years ago18 comments4 people in discussion

Supposing we:

  • Unified AM and AEM;
  • Unified Ln and An;
  • Reunited group 12 with the rest of the d block as TM (because they use their d orbitals for chemistry);
  • Renamed AM+AEM to "s-block metals", Ln+An = ITM to "f-block metals", TM to "d-block metals", and PTM to "p-block metals" (because that's what they would be and it'd be a consistent name set);
  • Annexed metalloids to nonmetals, because anything that isn't a metal must be a nonmetal (except Sb which conducts electricity like a metal in its only stable form);
  • Unified all nonmetals, because the "17" and "18" atop the F and Ne groups already tell us what "halogen" and "noble gas" do;
  • Distinguished H and He as the only nonmetals in the s rather than the p block (which makes a difference because they're the only ones with so few outer electrons);

we'd have exactly my favourite User:Double sharp/Periodic Table, with the exception of helium still over neon. Only seven categories! XD Double sharp (talk) 11:09, 7 October 2020 (UTC)

@Double sharp: That leads me in this direction (obviously, we'd need to add some more colors):
Legend option 1       Legend option 2
 12  02  metals & nonmetals in the s-block  12  02  s-block metals & nonmetals
 15  06  15  metals, metalloids & nonmetals in the p-block  15  06  15  p-block metals, metalloids & nonmetals
 40  28  metals in the d- and f- blocks  40  28  d-block & f-block (all metals)
The biggest disadvantage to this of this scheme that a number of terms that are generally used in the literature are missing. However,
  • Many of these terms are included in group names and can continue to exist quite well without the status symbol of being artificially promoted by enwiki into categories
  • No matter what category scheme we select, we will leave out many perfectly-good frequently-used collective names. Who are we to decide which ones to elevate to prominence?
  • We need some other better scheme to take note of the many names for sets of chemical elements rather than arbitrarily picking winners and losers. Such a scheme should not break down when collections overlap. Resolving the issue of fuzzy borders would be a great plus. But all of this is another issue for another day.
Some of the advantages that I see in this scheme
  • By only classifying by block and broad metallicity categories, we automatically get a mutually exclusive and jointly exhaustive system with no fuzzy borders (save only Og)
  • It retains the term metalloid, which has the best-researched attestation in enwiki. I believe the lists of metalloids is the gold standard as far as documenting use of element set names. We would be well-served if someone would create such articles for all of the named sets.
  • It introduces no new vocabulary. Legend option 1 even avoids descriptive phrases that could be construed as 2-word terms
Thoughts? YBG (talk) 07:31, 12 October 2020 (UTC)
PS, while I don't believe the law of excluded middle applies here, I would not be heartbroken if metalloids were counted as nonmetals. It would improve the esthetics of the legend (a very very minor point). YBG (talk) 07:52, 12 October 2020 (UTC)
Ah, I forgot about having said this here as a first thought! Well, if you look at current WT:ELEM you can see I've since proposed going even more radical and going blocks-only. I just want to keep things in one place, so in a couple of days if everyone is agreeable (since the ANI thread seems to be winding down) I should post something articulating my case for this and the group 3 thing clearly from explicitly stated sources. I just need a bit of time to do it. ^_^ Double sharp (talk) 09:24, 12 October 2020 (UTC)

Quick comments, which can be elaborated at WP:ELEM.

  • That the categories have not been been constructed with the goal of mutual exclusivity and joint exhaustivity is characteristic of the literature. As with categorisation schemes generally, there is some variation and overlapping of properties within and across each category.
  • There is no actual universal agreement on which elements belong in blocks other than in a theoretical sense, which does not translate well on the ground. Scerri has acknowledged this, re the notion of a 15-element wide f-block.
  • Further, in a review of Rayner-Canham's 2020 book, "The periodic table: past present, and future", Scerri concludes:
"All in all, the book is highly recommended to philosophers of chemistry. As philosophers we have a natural tendency to concentrate on generalities and not to get too involved in the specifics and the details. Above all else, this new book reminds us that such an approach needs to be tempered by a detailed knowledge of the exceptions and features that go against the simplified generalities which we so cherish." doi:10.1007/s10698-020-09389-x

A little bit more, later. Sandbh (talk) 12:18, 12 October 2020 (UTC)

@Sandbh: Short response.
  • The fact that the categories have not been constructed with the goal of mutual exclusivity and joint exhaustivity is characteristic of the literature is, to my mind, the best possible argument for Wikipedia not to try to make them so. The literature doesn't use them that way; therefore we should not try to make them that way. In my view, creating a bunch of categories, clearly colouring each element as belonging to one and one alone, putting these categories in an exalted position in the infoboxes, and not giving a clear clarification that none of this is actually agreed in the literature is just not good. Now, that accords with my understanding of WP:NOR: however, I have invited User:EdChem to participate as he seems more in touch with the correct understanding of what WP policies really mean. I will have more to say about this at WT:ELEM from the literature.
  • In fact, apart from the problematic elements La-Ac and Lu-Lr, there is zero disagreement on which elements belong in which blocks. This can easily be detailed in a single footnote about group 3 and the concomitant issues, and with that single footnote we would accurately reflect the situation in the literature. If one were to try to do it for the category-based scheme, it would instead lead to a mess where a large number of p block elements are called out as being uncertain as metals, metalloids, or nonmetals; and indeed where even category names in themselves are called out as differing between sources (post-transition metals? poor metals? p-block metals? B subgroup metals? etc.). It seems to me that any category-scheme translates far worse on the ground that a block-scheme by these standards.
  • The notion of blocks is at least more or less standard in the literature. Even though blocks are often not defined properly, all four are acknowledged by IUPAC, and there is no doubt as to which elements belong to which blocks today, with the exceptions of La-Ac and Lu-Lr that come from the group 3 dispute (which is also acknowledged by IUPAC). They are a standard thing in the periodic table. Categories as a way to split up the elements with mutual exclusivity and joint exhaustivity are not standard across sources. Different sources use different categories (are there metalloids, or just metals and nonmetals?), disagree on boundaries of the same categories (are group 12 elements transition metals?), sometimes put the same element in multiple categories (are the heavier members of group 3 also transition elements), and sometimes don't even emphasise categories to the extent of colouring a periodic table (Greenwood and Earnshaw certainly don't); and not all the categories we use have an acknowledgement from IUPAC. That is pretty much my case.
This is just a short response. A detailed proposal with sources is planned to follow at WT:ELEM hopefully sometime this week. Double sharp (talk) 13:08, 12 October 2020 (UTC)
As I have been pinged, I'll offer a few general thoughts:
  • As an FYI: This discussion belongs on an article talk page or at a WikiProject, rather than at a user talk page, for the sake of involving all interested editors and avoiding the potential problems associated with WP:CONLOCAL. Sounding out ideas here is fine, but any consensus decision to be implemented in article space needs to be achieved somewhere that anyone interested is likely to have seen it and had the chance to participate.
  • This discussion reminds me strongly that we all wear at least two hats in these discussions – chemist and Wikipedian – and it is helpful to remember which we are wearing at any given time. I say at least two hats as may of us are educators and thus wear a third hat. As a chemist, there are many approaches that can be taken and that is reflected in the literature. As an educator, I may choose an approach that is most illustrative and thus best suits my purpose in teaching, and that approach may be different for different students (depending on prior knowledge, for example), and may differ again when dealing with colleagues well-versed in the nuances in this topic. As a Wikipedian, however, I do not have the freedom to make personal choices that reflect my opinions / beliefs if those are not grounded in RS given DUE weight, etc. I also do not have the ability to craft text to suit an individual reader. Thus, I note the importance of Double sharp's point about OR: The fact that the categories have not been constructed with the goal of mutual exclusivity and joint exhaustivity is characteristic of the literature is, to my mind, the best possible argument for Wikipedia not to try to make them so. The literature doesn't use them that way; therefore we should not try to make them that way. Wearing my educator hat, I see how mutual exclusivity and joint exhaustivity are worthy goals, especially for novice and relatively inexperienced students. Wearing my chemist hat, I can see how these goals can be unnecessarily reductionist and can try to force a straight-forward answer onto a complicated situation – in effect, obscuring useful nuance. Wearing my Wikipedian hat, however, the prime responsibility imposed by policy is to reflect the sources and avoid personal preferences, etc.
  • I wonder if the question being discussed is the right one. It sounds like the debate has started from the position of needing a consensus position on what to include in the PT article – which makes sense – but would it be better to ask what do the sources say and only then turn to the question of how to reflect them in article space? If we can't agree on what the sources say (including whether that be one position or several), that is a good basis to consider whether the situation is that we need to cover the variety of positions and not try to adopt a single one in WP's voice. Does this make sense?
EdChem (talk) 18:49, 12 October 2020 (UTC)
@EdChem: Yes, I started this conversation more or less as some idle chit-chat bouncing an idea to YBG; the OP's idea is not in fact what I currently want to propose (it's a few days old). But I decided to make a short response so that YBG knows I'm aware of Sandbh's comments. ^_^ I want to take this to WT:ELEM, as stated above, but I need some time to write it properly and collect the citations and quotes needed. I'm a bit busier this week than I was last week. ^_^ So this is just a preview without the explicit cites so far. When I finish writing the thing, it will start from the position of asking what the sources say about the two issues, don't worry. That is, what does the literature tend to say about categorisation, and what it tends to say about group 3. So I'll refer to some reliable sources and quote them to do that. ^_^
I really like, BTW, what you say about chemistry vs pedagogy vs WP, and the different hats involved in each of them. You phrased it really well. ^_^ But I agree that we shouldn't be doing this on YBG's talk page, so I will leave it here for now. Double sharp (talk) 19:42, 12 October 2020 (UTC)

@EdChem: Thank you for pointing out that user space discussions like this are ok for initially sounding out ideas, but never should be viewed as a consensus. I'm fairly certain this has been our practice at WP: ELEM, though I cannot say so definitively. YBG (talk) 00:37, 13 October 2020 (UTC)

+1 Sandbh (talk) 05:18, 13 October 2020 (UTC)
That is a sensible process. I believe that the rules for user v. article talk should be viewed flexibly except in certain cases:
  1. If it is time to bring up an editor conduct / behaviour topic, it is time to go to user talk. This both separates the discussion and is more direct and private. The more contentious the debate, the more desirable to make any comment at user talk rather than publicly in the middle of an article talk discussion, especially if it can be seen (or spun) as trying to "win" an article issue by using conduct rather than the relevant policies like RS, V, DUE, etc.
  2. If a user talk discussion is evolving into an article topic where consensus might be needed, it needs to be open to all at the article talk page. Sometimes a WikiProject talk page is suitable (especially for multiple articles) but not without a cross-post to article talk so that any article watchers are aware and have the opportunity to participate.
  3. If a user talk discussion is spreading out to a discussion involving several editors, consideration to moving it should be considered. In a case where the group of likely interested parties is smallish, and there is goodwill and collegiality, the need to relocate is reduced... but ultimately an article space decision should never be taken in user talk – if for no other reason that it will be difficult for an editor in the future trying to understand or considering a modification to find and take into account.
  4. With regard to drafting an RfC, trying to do so on article talk to find a consensus wording can be wise; but it can also be nearly impossible if it will mean thoughts from a cast of thousands. There are times when drafting an RfC in user space can be more efficient. You can establish a page like user:WHOEVER/Draft_RfC_on_XXX. Being in user space, you can ask that only certain users contribute to the actual draft but open the user_talk:WHOEVER/Draft_RfC_on_XXX page for comments. You can start with a couple of people who are able to be balanced in the presentation, and when something concrete is available, invite comment from editors on both sides. Alternatively, you can propose that the discussion start with representatives of each perspective and ask that others stay out or stay on the user talk page. Once a draft seems stable, comment could be invited from the editors at the relevant article / WikiProject talk page for a day or several before the RfC goes live. There are no hard-and-fast rules on how to produce an effective RfC and there are some editors who are good at writing one from scratch, but a badly written / ill-considered / problematic RfC going live is an ineffective timesink waiting to happen. Remember also that an effective RfC can find consensus through the input of outsiders who are less invested in the article topic and more able to see what is most in line with encyclopaedic content. As such, the less an RfC depends on specialist knowledge, the better. I know that much of the Lu v La debate hinges on chemical properties and sitting with PT trends, etc, but outsiders will not be aware of these and likely will not comment if the issues are placed to the forefront of an RfC.
  5. The rules of user space are deliberately flexible, but also biased to empower the host editor. So long as the participants in a discussion are content and anyone unaware or excluded is unlikely to be objecting, then the discussion is probably fine. The more things move to dispute that is ceasing to be robust collegial debate and becoming conflict (and especially personalised conflict) the more taking the rules literally and applying them consistently becomes wise. And, when they come to article space conclusions, move the discussion or at least link to it from article talk.
  6. Flexibility / rigidity of rules is part of the reason that the ANI thread sprawled out of control. ANI is meant to look at behaviour and for admins to take actions to resolve problems where that is appropriate and has rules (both formal and informal). Not following them can result in sanction, or just in the thread being derailed and ineffective. It can't resolve content issues so they should be minimised as much as possible. Threads that devolve into back-and-forth between complainants typically result in no action as they take a lot of wading through to sort out, and neither party is behaving like a complainant coming to admins with clean hands looking for help – it looks like both / all parties behaving badly and promotes thoughts amounting to "let them fight and sort it out until they are willing to provide a strong and concise case to address" or "there are editors trying to work on the articles being drowned by the combat, let's remove the combatants and see if sanity is restored." There are other possibilities, of course, but these ones certainly happen. Also, if there is only one party flouting the rules of ANI, it is much more obvious (and actionable). If you have to go to ANI, a concise case, followed by a response, should be left for outsiders to comment unless the response raising things that NEED to be addressed. If the case says X happened, and Y gives a bunch of excuses, a reply that the diffs confirm X happened is sufficient. If Y makes accusations that show poor judgement / behaviours which did happen, a brief admission / apology etc is better... and if they didn't, just use diffs to refute briefly. Know what you are asking for, present the strongest, organised evidence for it, and then let those you are asking consider / respond / take action. If you are taken to ANI, rebut any accusations with diffs of strong evidence, make any counter-claim succinctly and with strong diff-supported evidence. Respond to questions from outsiders but don't engage in debate and certainly not with the OP.
Ok, enough thoughts on this – a stream of comments rather than a planned reply, so sorry that it rambles. Were this ANI, the above should be edited to be short, sharp, diff-supported, and easy for an outsider to comprehend. EdChem (talk) 01:55, 17 October 2020 (UTC)
@EdChem: Thanks. This is very helpful. YBG (talk) 13:46, 17 October 2020 (UTC)

@Double sharp:

The nature of WP. As I understand it, WP seeks to reflect, as best we can, what is in the literature, including the boundary overlaps that are characteristic of classification science, in general. Thus, the fuzziness and overlap phenomena are clearly noted in the periodic table article; the metalloid article; and the nonmetal article. That’s all that’s needed.

Clarifying the situation. As you suggested, we can clarify the group 3 and group 12 situation with a note in the graphic. All other categories, AE; AEM (separate or merged); Ln, An (separate or merged) PTM; metalloids per YBG’s gold standard (thank you YBG ^_^); halogen nonmetals; noble gases; and the moderately active, pre-halogen, or other nonmetals, fall naturally into place. Literature support is available for all of them.

Historical effort. As you noted, it isn’t particularly surprising there was no historical effort to try and make the categories mutually exclusive and jointly exhaustive. Subsequently, as you wrote, the result tends to either lead to "other" categories or categories without the same level of name recognition as the others.

That speaks to the iterative relationship between classifications, and science:

The importance of classification
Minelli, A.: The nature of classification: Relationships and kinds in the natural sciences—:By John S. Wilkins and Malte C. Ebach. Systematic Biology. 63 (5), pp. 844–846.
”At any given time, during the historical development of a scientific discipline, classification of available evidence offers itself as the explanandum that asks for a theory (or alternative theories) able to explain it. But this is just one segment in a potentially unending chain of recursive relationships between classification and theory. Theory and classification indeed change over time. As a consequence, the theory that provides explanation for the data organized in a classification at a given time can influence subsequent classificatory effort, and so on. “By means of this a discipline advances: each new pattern raises questions that call for explanations, and each verified phenomenon or fact gives a new pattern” (p. 163). What counts as a fact or a theory is a matter of temporal relativity. The authors’ “concern is that we do not replace observation with theory and think that we have made some progress. Science is founded upon empirical observations, no matter how these are tied up with local and cross-disciplinary theoretical commitments or stances. Once we abandon this aspect of science…science becomes little more than a matter of worldviews and epistemic statements of faith” (p. 163).”

Blocks. There is no precise, universally accepted definition of what a block is, that I can recall reading. Even thorium is problematic. The IUPAC Red Book does not define what a block is. A block-based period table does not solve anything. It hides information, rather summarising it via categories. As Christie and Christie (2000, p. 42) argued, “chemistry rests much more strongly on its…foundations of the 19th century and earlier, and much less on the insights of modern quantum physics.”

As I see it, per the basic value template, this is a standoff, lopsided, or top-heavy situation rather than an example of synergy. With a few lines, the blocks can be shown on the PT graphic in addition to the categories. Sandbh (talk) 05:14, 13 October 2020 (UTC)

Changing the subject from content to process

@EdChem: I would appreciate your thoughts on a couple of process issues that this discussion brings up.

  1. Sometimes at ELEM, we find it difficult to explain our thoughts about a proposal we wish to bring forward without displaying it in context. Similarly, we sometimes find it difficult to understand another editor's ideas without seeing them fleshed out in context. This leads us to draw a whole periodic table to illustrate a new color scheme, or even to prepare a draft of an entire article before a consensus has been reached about the general direction we wish to go. How should one decide when such a draft is helpful in providing a general understanding before trying to reach a consensus?
  3. I am ruminating on a few RfC that I think would be helpful for our project. What is the best way to do this? I'm inclined to try my best to get the wording the best before opening up the RfC, as I am afraid that a poorly worded 1st draft of the question could so muddy the waters that it makes it harder to reach a consensus. Any suggestions about thus? For example, would user space chats be wise to determine which subjects are most important and to determine the best wording?

I started this subsection asking for personal advice about how I should view project processes. But should I move this to WT:ELEM before you answer? Just say the word and I will copy this sub-section over there. And if one point belongs here and the other there, that's ok too. Just let me know.

Thanks. I appreciate your input. YBG (talk) 00:37, 13 October 2020 (UTC)

Hi YBG, Double sharp, Sandbh, and anyone watching / interested who I have missed.
FYI, I have seen the questions and posts at ELEM but have yet to have time to respond. It will happen, I'm just swamped with RL issues that are important and urgent. My apologies.
A quick reply on the RFC question: a contentious or unclear question is the best start if a long, heated, and ultimately useless discussion is sought. Thus, I concur that discussion to agree on an acceptable / fair / simple / etc question is very wise (as Floqueanbeam also suggested at the recent mega-ANI thread). If there are only two editors in disagreement then on user talk can be ok to avoid cluttering a WT or article talk page. If more, perhaps starting a non-user talk thread saying "I think XXX is suited to being resolved in an RfC, let's try to come to a consensus on what to ask rather than one of us launching it unilaterally." This does not work in cases where the issues are ideological and the parties will not agree on what is neutral nor compromise (think a devoted advocate for Trump and a passionate anti-Trump advocate – leaving aside that WP is not for advocacy, the chances that they can agree on a neutral and fair question to let those who choose to participate decide is far-fetched), but it should work fine for issues where each side can see the desirability of a consensus and has RS-based reasons for their views and are open to compromise / persuasion – that is, I anticipate that it would be fine for ELEM. Note also that input on the set up of an RfC can increase the chances of avoiding a structure that seems fine to one editor but which is actually over-simplified (say) and risks sprawling out into multiple options. Many an RfC has been set up in good faith and evolved into something unhelpful because factors went unconsidered (or under-considered) in its formation. One way is to ask a question that is not for WP to address. For example, does "Lu belong in the d- or f-blocks?" is a question about scientific consensus, and if there isn't one or there is controversy, a huge amount of time can be spent arguing the issue, expressing opinions, engaging in OR, etc. A better question might be "should WP deal with the question of whether Lu belongs in the d- or f- blocks by (A) ... or (B) ... or (C) ...?" and then offer the options that emerged from a prior discussion.
Ok, enough from me for now... EdChem (talk) 23:43, 15 October 2020 (UTC)
PS: Apologies to Floquenbeam for the mis-spelling... adding this to trigger the intended ping so you are aware that you were mentioned, and in case you want to comment. EdChem (talk) 23:45, 15 October 2020 (UTC)
Second apology to Floquenbeam for mis-attributing the comments that I meant to her, when they were actually made by Softlavender. Courtesy ping to Softlavender as having made the comments that I thought were valuable on RfCs, and in case she wishes to make a comment. EdChem (talk) 01:11, 17 October 2020 (UTC)
@EdChem: It's OK, I'm also swamped. ^_^ I still plan an actual posting summarising what I feel the sources are saying on this and the categorisation issues. The latter may be getting closer to a consensus since User:Sandbh has recently posted a blocks-up-front suggestion, but we'll see. The problem is that (1) I have little time right now and (2) one of the sources I need for the Lu thing is in Russian and I don't have an electronic copy, so it takes some time to actually find out what it's saying. Sorry. Double sharp (talk) 09:15, 16 October 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:YBG/Archive_4&oldid=987373191"