This page is supported by WikiProject Elements, which gives a central approach to the chemical elements and their isotopes on Wikipedia. Please participate by editing this page, or visit the project page for more details.ElementsWikipedia:WikiProject ElementsTemplate:WikiProject Elementschemical elements
I did not spend a lot of time on the high elements numbers with predicted oxidation states. I'm just guessing, but the predicted oxidation states are likely to be one result in one primary publication. I think mostly these would be better handled in the article text to explain the concept of the prediction. Johnjbarton (talk) 22:32, 14 October 2024 (UTC)[reply]
I gave it sticky-headers. Not related to the current back-end overhaul, but useful for readers for a long table regardless of how the table is generated. DMacks (talk) 19:46, 14 October 2024 (UTC)[reply]
I've updated {{tl:Infobox element}} to use the new backend. Please let me know of problems. Two I know about:
Most elements have unsourced oxidation states which show up as lots of ? linked to WP:citation needed. We could agree to delete them instead. Or reference them. I guess review sources on individual elements would be good sources.
The hypothetical elements beyond 112 are not correctly listed. I was unsure what should be done.
This change has broken references for at least a few articles. Is there a fix planned? Why weren't the changes adequately tested to prevent that? For an example, see Nihonium, which has more than two dozen undefined reference errors. <ref name="Haire"> was previously defined by invoking {{infobox nihonium}}, but this recent edit by Johnjbarton changes the inclusions to a template that no longer provides those references. Now, they're undefined. Roentgenium has similar damage. Also, Seaborgium, Ruthenium, Meitnerium, Moscovium, ... -- mikeblas (talk) 15:18, 25 October 2024 (UTC)[reply]
I tested the changes as well I could. The way the system works certain kinds of issues can't be tested without deploying only then if someone notices the problem as you have done. (Thanks!)
References in particular are nasty business in this system so we have to work around issues. If the refs are defined in the oxidation state data they may duplicate those in the article; if not they may be missing. The only solution for refs needed in both places is to add the definition to the reflist ref= parameter in the References article and use <ref name="Haire"/> in the oxidation state data.
I could not find the definition of Hoffman-2006 in the old implementation. I believe it is the same as the one weirdly named "Haire":
Hoffman, Darleane C.; Lee, Diana M.; Pershina, Valeria (2006). "Transactinides and the future elements". In Morss; Edelstein, Norman M.; Fuger, Jean (eds.). The Chemistry of the Actinide and Transactinide Elements (3rd ed.). Dordrecht, The Netherlands: Springer Science+Business Media. ISBN978-1-4020-3555-5.
The new scheme is also used for the List of oxidation states of the elements which appears in Oxidation state. If every element in your list includes a def for "Haire" then Oxidation state will have that many duplicate definitions. So the oxidation state data should not have defs, only refs and the defs should be in the articles. Including defs in the oxidation state data is also error prone because editors of the element pages will have to work hard to find the ref def.
Was it foreseeable that some refs would be messed up? Maybe if I was smarter.
Personally I think we should not be presenting oxidation states for these elements: they never form oxides. But the fix up is easy enough I work on it. Johnjbarton (talk) 02:25, 26 October 2024 (UTC)[reply]
Well, if the expectation was that articles would define references that were previously made by templates, then it seems like almost any article using the template would need to be examined. That's a pretty risky change.
Goin' forward, tho, I'm no kind of chemist past twelfth grade, so I can't say anything about the propriety of oxidation states in the articles.
If I understand correctly, the problems resulted by named refs being used in the template that were not defined in the article.
It seems to me that a template should not depend on any refs being defined elsewhere; rather, a template should stand on its own without such a dependency. It would be good, however, for a template to provide a name for every reference it defines in case a transcluding article wishes to use it.
With this convention, the only potential error would be defining a named ref multiple times; a reasonable naming standard would avoid this issue.
I think it's the other way around. The template used to define references, and the article used them. The template stopped producing those references, and now there are undefined reference errors popping up.
Some have been cleaned up, but there are still many errors around as a result of this change.
Johnjbarton, here is another batch of errors: Unbibium (for "Pyykkö2011"), Unbihexium (for "Pyykkö2011"), Unbinilium (for "Pyykkö2011" and "Haire"), Unbiquadium (for "Pyykkö2011"), and Unbiunium (for "Haire" and "Amador"). Again, let me know if I can help. I don't know if you're manually adding the references to the articles, or if you plan to restore them to the template, or ... -- mikeblas (talk) 00:23, 27 October 2024 (UTC)[reply]
"The template used to define references, and the article used them." As I have been trying to explain there used to be two templates. One defined some refs that were used in articles but the other did not. I was unlucky in basing my refs on the the other database which did not list these non-elements.
Placing the definitions in the database has two issues:
When incorporated into Oxidation state refs defined in different elements will results in duplicate refs
When less experienced users look for the definition of the ref in the article they won't find it, it's very mysterious.
Placing only references in the database has two issues:
Defs have to be copied into two articles, the element and Oxidation state
Failure to do the previous step leads to cite errors.
I chose this path because editors changing the database have enough experience to do the double copy and the missing citations are big red errors that can be noticed and fixed but duplications are tedious to find and fix.
Just to reiterate: refs in the database and defs in 1) element article 2) Oxidation state.
In general the unreferenced oxidation states are also listed by Greenwood and Earnshaw – just as less common ones. Here's the list of uncommon oxidation states listed by G&E on p. 28.
A bunch more were actually cited in the previous versions. On the other hand, there is a particular issue here. The source for Al3BC (the first problematic case) never mentions the oxidation states in the compound. I presume the logic behind the B −5 entry is that this should have Al +3, C −4, B −5, but it's not explicitly stated. So now I wonder if it should be considered acceptable to derive unstated oxidation states from IUPAC's rules (doi:10.1515/pac-2015-1204). I might note that the IUPAC report in question remarks that there are quite a few cases where OS assignment becomes either truly ambiguous or formal beyond the point of usefulness, such as in metallic compounds (AuNCa3), complexes with non-innocent ligands, and cases with very low electronegativity differences (e.g. carbon diselenide).
Personally, I think we should not derive such states ourselves, no matter how obvious the result looks. A particular pitfall is mentioned by this article: Cs2Pt and BaPt both look like stoichiometric ionic compounds, but only the first is really well-described that way (the second has Pt–Pt chains). Double sharp (talk) 08:30, 17 October 2024 (UTC)[reply]
Thanks!
"A bunch more were actually cited in the previous versions. " links the presentation of the older data which has citations in the last column but many states are listed in the row that do not correspond to any ref. Still some of these refs could be useful. Johnjbarton (talk) 15:56, 17 October 2024 (UTC)[reply]
I will try to look through them over the next few days. :)
In general, probably G&E should be enough for most of those in the above table. However, in some cases of exotica I'd very much like to back them up with an additional source – I am unaware of a single actual example of Li(−1), and G&E p. 99 remarks on sodides, potassides, rubidides, and caesides but notably not lithides. So I would very much like to know what they had in mind. Double sharp (talk) 16:19, 17 October 2024 (UTC)[reply]
@Burzuchius: Thanks. Not sure how I missed that page. In that case, I withdraw my objection to B −5, though I'd still argue for only including oxidation states if they are stated by the source. Double sharp (talk) 12:31, 17 October 2024 (UTC)[reply]
The only known (not predicted) transactinoid oxidation states past Rf are Db +5, Sg +6, Sg 0 (hexacarbonyl; oxidation state however not explicitly mentioned, though I suppose one could plead that it's obvious since it's said to be homologous to the Mo and W versions), Bh +7 and Hs +8 (mentioned as the highest formal oxidation state in the Sg 0 ref).
For completeness here are two borderline cases which I think should not yet be in the list. There is a report on CnSe from 2015, which would presumably be Cn +2 (implied to be homologous to HgSe). However, in a 2016 conference it was stated that further experiments are ongoing to elucidate what's happening (and also to compare with Fl). I have not seen anything more recent on this. Probably NhOH (which would be Nh +1) was formed in experiments probing Nh chemistry (doi:10.1140/epja/i2017-12348-8, noting homology to Tl), but it is not securely identified. Well, what can I say: chemistry with such short-lived species is hard. Double sharp (talk) 16:31, 17 October 2024 (UTC)[reply]
Should infobox images for colorless gaseous elements be the liquid form (if available), or the discharge tube?
The infobox image for nitrogen is liquid nitrogen. The image for oxygen used to be liquid oxygen, but @Hexonite: changed it to the discharge tube here without explanation (I would like to change it back but first should ask why you changed it). All the noble gases have discharge tubes, but Wikimedia Commons has images of liquid argon available at commons:Category:Liquid argon, and liquid helium at commons:Category:Liquid helium. There are images of liquid xenonhere, here, and here. So, if an image of the liquid element is available, should we use that instead of the discharge tube, and only use the discharge tube if no image of the liquid element is available? This was previously discussed at here in 2009, because at the time these articles were using images of empty vials containing the colorless gas. HertzDonuts (talk) 22:50, 27 October 2024 (UTC)[reply]
hmm, I guess that really is something to think about
I only updated it to better represent oxygen being thought of as a gas, rather than a liquid.
If anything, these pages should have pictures of all of the phases (because it's the same element and molecule), however if that's impossible, only pictures of their current phase.
lets say water is a liquid and freezes to become ice, is water more thought of as a liquid or a solid? Everyone knows that water freezes to ice, but does the liquid form come to mind first or the solid form when you think of water?
And yes, light produced from an Oxygen molecule never comes to mind when you think of Oxygen
On second thought I would probably suggest that the gaseous elements have a photo detailing the molecule, for instance H2 is H - H two Hydrogen atoms that if represented would be represented as two circles with a line connecting them to visualize the bond.
I can see an argument that the infobox picture should show the element's standard state (maybe a collection of allotropes in cases like carbon and phosphorus). In that case, perhaps colourless gases should not have a picture in the infobox as well, since they are inherently unphotographable in the standard state, and should instead have pictures illustrating them in other ways in the body? It's similar to how I'd expect true-colour images for Solar System objects in their infoboxes, even if in the case of Venus the result is really boring. Double sharp (talk) 04:33, 29 October 2024 (UTC)[reply]
However, some image is always better than no image. If it's a transparent gas, I'd rather have some kind of container and explanation over "no image". 108.160.120.147 (talk) 19:01, 29 October 2024 (UTC)[reply]
Oxidation states for Ubb, Ubq, Ubp, Ubh
The oxidation state data for six "elements" relies on this source:
However, when I read the source I conclude that no such data is present there. The section "5. Ionization potentials and oxidation states" in the paper is chicken and waffles as far as I can tell. I am unable to verify the existing data based on this source. Johnjbarton (talk) 23:18, 27 October 2024 (UTC)[reply]
See table 7. The oxidation states are implicitly stated by referring to formal electron configurations, i.e. "8s05g0" for 121X3, 122X4, 123X5, 124X6, 126O4. Section 5 refers to predictions varying for 126. Then again, since these lists of compounds are not explicit OS statements, and they are presumably not exhaustive, perhaps they should be removed anyway and left to the text. (Also, strangely I can't find 126(VI) mentioned there. The hexafluoride is discussed in another paper by Dognon and Pyykkö, though.) Double sharp (talk) 02:28, 28 October 2024 (UTC)[reply]
Did you consider grouping all of the periodic chart categories together? The "... periodic table position" could be "Named groups", "Other groups" or "Other named groups" under "By periodic table structure". Johnjbarton (talk) 01:43, 29 October 2024 (UTC)[reply]
That’s a good idea, and no, I didn’t consider it. The three categories under periodic table structure are each currently mutually exclusive and jointly exhaustive, so moving this section would be a little tricky, but probably doable. I’ll have a go at it. YBG (talk) 02:52, 29 October 2024 (UTC)[reply]
There are still many referencing templates with errors. (Are these templates actually in use, or should they just be deleted anyway?) These templates all have undefined reference errors in themselves -- that is, right at their template pages, or their own documentation pages. These seem to be related to oxidation states:
It seems like bad form to have referencing errors in a template's example invocation in its own page. I don't think these pages were a problem until some changes were made last week. How can this all be set right? -- mikeblas (talk) 00:16, 31 October 2024 (UTC)[reply]
Solving this problem will unfortunately create other problems. These two problems are 1) mysterious references, 2) silent failure modes.
1) When I altered the template implementations I changed a few references and the result was errors in many element pages as you know. The reason was that these element pages used <ref name="Haire"/> but no where in the element page was "Haire" defined. I did not realize what was going on and I guess I have more than the average experience with references in wiki pages.
2) When working on this problem I encountered cases where a reference was included twice I guess because an editor did not know where to look for the definition of the reference.
For these reasons I think we should define reference in the final end point page and not in the template data base. There are two down sides to this solution: 1) twice as many definitions (element and oxidation state 2) errors in template documentation pages that you see above.
In my opinion we should adopt the solution that puts the burden on editors who work on templates as they are more likely to know the issues or at least know how and where to ask about them.
However if there is a consensus to place definitions in the database I am fine with it.
We could solve the errors in the template documentation pages by adding ref-defs in these templates, but I would oppose this solution because it would be three places defs have to be added.
I also just had a thought: what if we got rid of the oxidation state database and put the oxidation state data into each element's infobox instead? It might be possible to build the List of Oxidation State table by processing the infobox for all the elements. This would be a lot less complex for editors than tracing through {{infobox element}}Johnjbarton (talk) 01:23, 31 October 2024 (UTC)[reply]
I think the refs should be defined in the template (or the OS db if you prefer). There should be a list of named references in two places: in the template’s doc page and in the element's talk page. This could be done creating a subpage of the template and transcluding it in both places. This would provide two places for an editor to find out about named references available for use.
But even if an editor doesn’t know about the names refs, they would not be burdened. Editors should not be adding a reference unless they have access to the original source, and if they have access to the original source, they have all the information they need to create the footnote.
The only possible problem would be if an editor tried to define a named ref that is already defined in the template. This can be avoided by having all ref names defined in element templates named appropriately. I suggest something like ElemTemplate_Smith or ElemTemplate_Smith1969. An editor who wants to add a couple of statements supported by Smith and decides to add a named reference would create ref named Smith or Smith1969. There would be no duplicate definitions. A more experienced editor would notice that Smith is unnecessarily listed in multiple footnotes and could correct the issue.
"I think the refs should be defined in the template (or the OS db if you prefer). " That combined with mikeblas' complaints is enough to convince me.
"There should be a list of named references in two places: in the template’s doc page and in the element's talk page. This could be done creating a subpage of the template and transcluding it in both places."
Wow, that was a doosy! I tracked down the duplicate reference to {{Infobox element/symbol-to-electron-configuration/ref}}, which had a slightly different definition of that "Haire" citation. I think it is fixed now, with this edit. Did my fix cause any collateral damage?
This "Haire" reference is used all over the place. Would it be a good idea to give it is own template, so it can be defined at one place in the template, then invoked repeatedly all over? Then, the repeated definitions would always match. If the ref ever needs to be updated, it is in one place. (OTOH, if only some articles need a change to the reference, then more complexity arrives.) -- mikeblas (talk) 19:25, 31 October 2024 (UTC)[reply]
I guess you meant {{infobox rutherfordium}} etc. I don't think those changes have the effect you think they do. Making the text content of two refs identical has no effect on anything other than the changed ref content. Both defs will still appear where ever they appeared before. Johnjbarton (talk) 22:17, 31 October 2024 (UTC)[reply]
Yes, I made fixes at the infoboxes. If a <ref> tag is exactly the same as another, it is combined into the same reference -- but only if exactly the same. If the same values are in the same parameters, just in a different order, that's notexactly the same, and a duplicate definition error appears.
And further: if that reference definition is wrapped in a template, it will consistently be generated and never cause a duplicate reference definition error.
In your version of Samarium reference 10 and 70 are the same. Your edit just took off the name so there were no longer two defs with the same name but rather one named and one unnamed, two copies. After I reverted your edit, in the next edit I changed the ref def to ref ref: <ref name=Chiera2024/>. Now their is one def (somewhere!) and one ref-ref, and the References list two instances. Does that make sense?
Oh, I see! I didn't notice a version of the article after your reversion. Maybe I looked while you were editing it, or maybe I didn't refresh.
Notes 10 and 70 in my version aren't quite the same. They have different date formats, and that's one of the things that was different between the citations used to form the references. And, since they were different, that's why the error appeared.
Group 5 element has been nominated for a good article reassessment. If you are interested in the discussion, please participate by adding your comments to the reassessment page. If concerns are not addressed during the review period, the good article status may be removed from the article. Z1720 (talk) 13:46, 3 November 2024 (UTC)[reply]
Revisiting decay energy for isotope lists
A while ago I posted a discussion suggesting that decay energy be added to the tables on "Isotopes of [element]" articles. The discussion never really got to a consensus. I though I might bring it up again because this site lists, as far as I can tell, all known isotopes and decay energies for most decay modes. The one exception is it does not appear to list the energies for cluster decay. Thoughts? TornadoLGS (talk) 19:29, 9 November 2024 (UTC)[reply]
Actinide has been nominated for a good article reassessment. If you are interested in the discussion, please participate by adding your comments to the reassessment page. If concerns are not addressed during the review period, the good article status may be removed from the article. Z1720 (talk) 23:51, 19 November 2024 (UTC)[reply]
Boron has been nominated for a good article reassessment. If you are interested in the discussion, please participate by adding your comments to the reassessment page. If concerns are not addressed during the review period, the good article status may be removed from the article. Z1720 (talk) 02:40, 30 November 2024 (UTC)[reply]
Pulse Radiolysis Studies for Oxidation states
I was looking over some of the old references, and noticed some oxidation states have been stated by observation from pulse radiolysis studies, such as
RSS 
