Template talk:Physical oceanography

Sneaker wave

This template is for use in articles regarding the science of physical oceanography. I deleted Sneaker wave from the template, since it is not a scientific term, and not used in scientific papers. It is even unclear what it is (e.g. in contrast Rogue wave is used, and defined, in the scientific sense; although news agencies use it in a very sloppy sense). But my deletion of sneaker wave from the template has been reverted, and I am curious to hear the opinion of others, in order to build consensus. -- Crowsnest (talk) 12:16, 29 October 2010 (UTC)

Hi Crowsnest. I suspect we have a slightly different view of the role of templates. While this template is nominally about physical oceanography, it is not principally, or certainly not exclusively, addressing the community of physical oceanographers. Many, or most viewers will have a lay interest in the area, and the approach lay viewers are likely to have should be reflected in a way that makes the template more accessible to lay viewers. The article on Sneaker wave addresses matters a little differently from Rogue wave. For example, the phenomenon of the "seventh wave", or the notion that wave trains often have superimposed a higher order, is a matter of common observation for anyone who spends time at a seashore and cannot really be called "rogue waves". The "seventh wave" may have no scientific basis, but that fact itself is worthy of some scientific comment, if only to draw attention to the fact that there is nothing magic about the number seven. I would think that, within the literature, there must be studies relevant to the periodic aspect of the wave trains themselves that could reasonably be added to this article. Another value of templates like this is to draw together all the articles relevant, or even remotely relevant, to the main topic so they can assessed in relationship to each other. What I am suggesting as an alternative to deleting Sneaker wave from the template so it ceases to be an inconvenient blot on scientific purity , is that the article could instead be (a) rewritten or enlarged, perhaps along the lines I suggested above (b) renamed, perhaps to Seventh wave, or (c) merged, perhaps to Rogue wave, though as mentioned above, there are problems with that. --Epipelagic (talk) 01:14, 30 October 2010 (UTC)

Re (a): since "sneaker wave" is non-scientific, it seems useless to me to try to enhance it scientifically. The way to proceed seems rather to enhance elsewhere -- in existing or new articles -- the group kinematics and dynamics of waves, and the associated effects (wave group, wave group statistics, surf beat, infragravity wave, wave runup). The wave phenomena causing the dangers of the sea on the beach are real of course, but "sneaker wave" is contaminated by the effects (surprise, harm, fear) on people unfamiliar with waves on beaches; also a normal wave causing harm will easily be classified as "sneaker wave" (similar as harmful waves at sea are easily blown up into "monster wave", by the caused unforeseen harm, while they are most often not "rogue waves" in the scientific sense). See the videos and photo's on the web on what people call sneaker waves.

Re (b): no need to rename it; under this name it is used by news papers and the web sites of some beach authorities. The 7th wave is well known from mariner's folklore, and has some scientific connections.

Re (c): since it is unrelated to rogue waves at mid-sea, far from the beach.

-- Crowsnest (talk) 00:54, 13 November 2010 (UTC)

Colouring

Please discuss any colour changes here, rather than engaging in an edit war. In my opinion, and the opinion of several other editors, there is no reason to deviate from the default. Thank you. Frietjes (talk) 21:42, 26 October 2011 (UTC)

No Frietjes. The colour is compliant with the guidelines. It is not right for you and one or two others to hold Wikipedia hostage to your own particular preferences. I've made a lot of effort to meet you half way on this, and I expect you to do the same. --Epipelagic (talk) 21:48, 26 October 2011 (UTC)

Gotta ask. I've been through the other templates that you changed, or said you intended to change, to use #ABBEDC. I converted to the use of Template:Flatlist, which I'd already done to this one. For the moment, I left the colour; even fixed some places where the proper colour showed in subgroups.

I thought this was all about fishing templates, but I see you've done this to templates that are only slightly related to fishing, such as Template:Animal cognition and Template:Corals. So I looked further, and find that these are all (ok, I didn't check every one) templates that you've created. This is all about personal preference; yours.

I also see the you and Frietjes have been over this before on some of these template. How did those discussions go? One Ton Depot (talk) 05:25, 27 October 2011 (UTC)

See the future. One Ton Depot (talk) 09:09, 27 October 2011 (UTC)

I agree that the colouring is inappropriate; I said so in an edit summary and on Epipelagic's talk, where I went unanswered. I had seen that it was fixed, again, and now you're (Epipelagic) calling others for edit warring? You're the one edit warring and forcing a personal preference, here; we're just trying to make this template normal. I simply sought to follow the applicable guidelines. The new colour you've changed to here, and on dozens of others it would seem, is worse. Now you've got blue-on-blue, which is going to be a problem for some with vision difficulties. And the wider issue is that this is shoving a non-standard colour into 187 articles. I noticed this on Current sea level rise and Future sea level, where it appears adjacent to a standard navbox. This results in hundreds of 'off' looking pages. WP:Deviations is about avoiding deviations. That the seas are blue, or blue-green, is a pretty thin rationale for this. You also claim in your last edit summary that others have no right to edit in areas where they have not contributed content. Really? You WP:OWN this walled garden? The colour and other weird styles should be removed from this template and from the others in Category:Fishing navigational boxes. One Ton Depot (talk) 02:10, 27 October 2011 (UTC)

One good reason to leave the templates at the default colours is because there are often multiple templates on any given article. The trend lately, at least on the more serious articles such as those on history, science, and the like, has been to remove the rainbow of colours from the templates for a more uniform and professional appearance that presents as a more serious resource. It wasn't that long ago that the bottom of the article on Elizabeth II or Adolf Hitler had a half a dozen differently coloured templates across the bottom, which frankly looked childish, and has no place on a serious encyclopedia, imho. Also, according to Snook's tool at http://snook.ca/technical/colour_contrast/colour.html, your new colour is only "sort of" compliant: it meets the AA guideline but not the WCAG 2 AAA standard, which is the ideal. The default colour schemes have been tested on a wide variety of browsers and platforms to assure that those with vision impairments will be able to see the material clearly. --Dianna (talk) 04:25, 27 October 2011 (UTC)

There is a matter of balance here, Diannaa. You say "The trend lately, at least on the more serious articles such as those on history, science, and the like, has been to remove the rainbow of colours from the templates for a more uniform and professional appearance that presents as a more serious resource." However, the default blue is an obnoxious wishy-washy colour, that gives anything but a professional appearance. Perhaps that colour looks okay to people with colour deficits, but it gives anything but a "professional appearance". All that can be claimed for it is a dull uniformity at the cost of everything else. Meeting the the AA guideline is pretty good. That goes a long way to accommodate people with colour deficits. But the process should be two way, with give and take on both sides. The fact is that the current templates comply in every respect with the guidelines. They are adequate from the standpoint of those with visual deficits. The current colour is not only "sort of" compliant, it is compliant. It is a separate issue whether they are "totally ideal" from that standpoint. If the guidelines are changed, with due consensus, to reflect a rigid "purist" position, then naturally I will go along with the. As it stands, we have an aggressive new editor, with a narrow focus on just coding issues, trying in an obnoxious way to take over and damage a large amount of work. — Preceding unsigned comment added by Epipelagic (talk • contribs)

The colour looks very different on different browsers (Internet Explorer, Firefox, Chrome, etc) and different computers (Dell, Mac, Toshiba). What you find wishy-washy I find renders just fine. --Dianna (talk) 18:19, 27 October 2011 (UTC)

Epipelagic, do not re-indent my posts to skew who it appears I was replying to. And do not leave insults on my talk page, or attack me here. I converted your templates to use Template:Flatlist because it's good and useful. It's the recommend form: Template:Navbox#Examples. This is for properly using a list for WP:Accessibility reasons. While editing them, I fixed other issues, too: see the second section, 'Fishing television'. Your reverting all those edits was PURE OWNERSHIP (but I've already linked to that.) The change I made here, to use rounded corners, and gradients, is taken off of Template:Navbox/testcases#Gradient; I called it the future, because this is what the future default will be. But placing colours into templates, will impede that. That you created these templates, does not give you the right to abuse other editors who wish to improve them. One Ton Depot (talk) 18:23, 27 October 2011 (UTC)

The main reason to convert to flatlist is to reduce the template load on the page; the non-flat-list version of Template:Fish disease topics, for example, requires nearly 20% more resources. This has a big impact on the load time of pages, particularly those that contain many templates. The flatlisted templates are also easier to maintain; for example, in the case of an alphabetical list, it is much easier to determine where to add new material. The problems with Internet Explorer 9 were resolved with the recent change to the mediawiki software, and the problems with earlier versions only occur when in compatibility mode. People are working on it. Just a reminder to participants to restrict their comments to the content, and not comment on the contributors please. Thanks --Dianna (talk) 18:43, 27 October 2011 (UTC)

The reasons you give are good ones, but not the main one, which is WP:Accessibility. Flatlist, as you seems to see, is about actual lists, which help not just folks with vision issues, but those using phones and other non-traditional devices. Search engines also will read lists better. The load time is more an issue of server generation of the pages, than download time; templates like Template:·w impose a heavy server-load; they also get 'spoken' to users of screen readers as 'dot', which gets quite annoying. Also, things like Template:Nowrap begin and Template:Nowrap end are no longer needed, as the site automatically does this for all links in navboxes; it's junk-code that should be removed (millions of them, it seems). One Ton Depot (talk) 19:26, 27 October 2011 (UTC)

I would endorse the points made about use of {{flatlist}} which marks up lists as lists (rather than strings of plain text containing 'dots'). This allows non-visual user agents to render the items in a much more satisfactory way for visitors who are visually impaired. There is actually a stronger case to be made for removing editor-defined colours from element backgrounds: I have a slight defect in my ability to detect different blues, so I change in my Monobook.css how text links are rendered, which works well for me against the standard backgrounds. What is more, I could also change in my Monobook.css how those standard backgrounds are rendered, and I expect other users with more severe defects will alter both foreground and background colours to reach an acceptable contrast when links appear against a blue background. It's worth noting that my impairment is relatively minor, yet WCAG AA is unsatisfactory for me when the colours are predominantly blue (other hues are fine) and I need AAA. What this means is that when editors introduce inline styles which hard-code a background colour, they lessen the ability of registered users to increase the contrast between text and background, since the background is then fixed for all. It is not a good trade-off to sacrifice readability for some in order to satisfy the aesthetic preferences of others. --RexxS (talk) 13:20, 28 October 2011 (UTC)

Rex, I agree absolutely you should not have to sacrifice readability because you have a colour deficit. There needs to be a way to cleanly address that. But I don't agree it is necessary to penalize everyone else to meet that goal. If that were the case, then I would support your position. However that is simple not the case. You talk of "inline styles which hard-code a background colour". The code is just a script, which is read and interpreted at runtime. It is not hard-coded, because can be changed before rendering. Thus, if a user identifies as having a visual deficit, then it would be a minor coding matter to replace the inline background colours. Wikipedia could do that on the run, with just a minor overhead operating only in the context of users with visual deficits. --Epipelagic (talk) 18:05, 28 October 2011 (UTC)

Accessibility is not about penalizing the majority; read the article on it, as well as web accessibility. RexxS is referring to the opening sentence of WP:Deviations: "In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes." The runtime scripting you are referring to would be driven by some sort of user-preference, where users identify as having a vision deficiency, possibly being very specific. The WMF should have developers code this to accomodate other users wanting to colour things up in arbitrary ways? The point of not deviating from norms is to allow the well-tested defaults to work equally well for all users. And what about the vast majority of readers who are never going to register an account? They get what is served, period. Please stop pushing your personal preference on things; it's giving your opinion undue weight. One Ton Depot (talk) 22:12, 28 October 2011 (UTC)

I was surprised to see that the dots are now deprecated, and have been since August. Flatlist is the new best practice. Yesterday a friend and I were comparing displays, and on my Toshiba, the navboxes with default colours display as a shade of blue, but on the Mac (and on my Dell, where I am right now) they look purple. The colours look about the same on Internet Explorer as they do on Firefox, but the example One Ton Depot prepared at {{Physical oceanography}} displays with horizontal and vertical gradients of colour on Firefox. These gradients do not display at all in Internet Explorer. People using a better browser get a better experience. I am in favour of re-introducing the improvements to the whole group of templates. --Dianna (talk) 16:09, 28 October 2011 (UTC)

Can we go back to this version and add the special colouring gradients to MediaWiki:Common.css? I am visually impaired and use a custom css file to change the appearance of the navbox class. You can do the same thing to have the special colour gradients and rounded edge stylings. All you do is add the lines to Special:MyPage/skin.css, until they are rolled out in the main site wide file. For example, I have done so in my personal css file in User:Frietjes/vector.css to lighten the background colouring. I would also support adding an additional "oceanography" or "fishing" or whatever class to this template so that Epipelagic could override the default as well to get a blue background. Frietjes (talk) 17:29, 28 October 2011 (UTC)

The gradients I aded here were show where things are going. I'll remove them from here, as I've started a discussion with the author at User talk:Edokter. Editors such as yourself and RexxS can use user-css to aid themselves, but unregistered readers don't have that option. A few may use browser features but most will simply see what presented to all, and they may not be able to read what the see. The addition of meaningful classes is ok as long as it doesn't get out of hand (it's called classitis; Google it). Registered users don't really need such classes to do that sort of things if it's simply about preference for something other than the normal look; they could add css to re-style the whole site. I may add the gradient stuff to my css to preview the future. One Ton Depot (talk) 22:12, 28 October 2011 (UTC)

I see no problems with converting to flatlists. Because I was happy with that side of things, I didn't initially revert the changes made by One Ton Depot. The reason I subsequently reverted was because he also changed alignment parameters, I presume because he was unaware of the point of them, and had announced, in a non negotiable way, his intentions to strip all the templates down to some minimalist state which could be beloved only by coding purists oblivious of any other issues. --Epipelagic (talk) 18:05, 28 October 2011 (UTC)

I'll restore the use of flatlist, then, and restore the group and list styles you're referring to. Don't assume I'm unaware of the effect of such things; I am. I'm not "oblivious" to your other issues, I'm just not buying them. One Ton Depot (talk) 22:12, 28 October 2011 (UTC)

Well if you don't discuss issues, how can you be so sure you are aware of them? Instead of manually converting templates to flatlists, why not write a bot that does it. I don't know how many templates there are, but the number must be huge. --Epipelagic (talk) 00:30, 29 October 2011 (UTC)

Please stop saying that I'm not discussing things; I've a lot more posts on this than you do; I've a lot less edit-warring, too. You said take it to talk; I did, you didn't answer. You're not getting the gist of others comments. You've reverted multiple editors on this. You're getting called on OWNership, by others, on other issues, too.

Bots will help with this mess; there are millions. One Ton Depot (talk) 00:46, 29 October 2011 (UTC)

padding and line-height

I've restored these, for discussion. They implement small tweaks to the layout; a bit more space above and below each listrow, and a bit less space between wrapped lines within a row. These specific navboxes thus appear somewhat taller than usual. My view is the the normal spacing is fine, and that omitting this deviant code improves consistency across the whole project.

width

Some of these templates use width for groups; this would seem to be about making the upper-half and the lower half groups match each other. The real issue here, is that this navbox and about a dozen others re fishing, are implemented as conjoined twins. They are built such that the including article can specify which child should be shown for that articles. Out the window is the notion of autocollapse; these templates insist on being initially open (and larger, and more colourful; more important;) than any others an article may be using. This implementation has the sideffect of precluding the use of v·d·e links. They were even added to this navbox (back in the day when 'green' was the appropriate colour). They were, of course, reverted. A very similar addition of the v·d·e links occurred on Template:Ocean habitat topics, but there, too, the useful links were removed with the rationale better to give the template some protection by omitting this. Really? Protection from other editors?

I would ask our host to accede to the consensus above regarding the colour. All please comment on the padding, line-height and width. The first to are trivially removed. The widths are bound-up with the pairedness of many of these. I think these should be separated, allowed to autocollapse, and the appropriate navbox brought-in from linked-pages without hauling in eighty other also-ran links. navbox templates should be of workable size:

(hey, it's not used)

One Ton Depot (talk) 02:50, 29 October 2011 (UTC)

I see, One Ton Depot, that you are claiming elsewhere that I am really unhappy with the gradient look, and called it wishy-washy and obnoxious. That's not true. I'm fine with the gradient look, and have no objections if you want to trial it on this particular set of templates. But then above, you continue with more snide remarks and general incivility, which makes trying to collaborate with you a waste of time. Further, you are trying to enlist support for what appears to be a campaign of disruption you are embarking on. --Epipelagic (talk) 02:59, 29 October 2011 (UTC)

You said that on this very page. The gradient example uses the same colours as the default, albeit trending towards pale. There's a comment above about colour perception varying on different hardware, which it certainly does. It's not just human eyes that have deficiencies, our displays vary, too. This is all the more reason to not arbitrarily mess with the look of things.

I'm annoyed with you. You dropped a nasty personal attack on my talk page, linked to it from all the edit-warring diffs (where you called it unhelpful). Yet you agree that flatlist is ok, your issue is with the list and group styles. And the colour, which I'd not removed on those others. Rather than edit the templates, you wholesale reverted all my work because I trespassed on your turf.

We're nearly done, here. These templates should be reworked some, and I'll help. I've had many aquariums and would enjoy working in this area.

The proper place to trial the gradient example is the Village Pump, and I'll see if Edokter takes it there. Be glad for your support of it, too. One Ton Depot (talk) 03:29, 29 October 2011 (UTC)

ec; notifying an editor you reverted is hardly disruptive. One Ton Depot (talk) 03:29, 29 October 2011 (UTC)

Well thank you. Maybe we can start communicating now. To reply to the points you raised: The reason for removing the v-d-e option from the templates has nothing to do with ownership. IPs are often attracted to templates and vandalize them, and I don't want to spend all that time reverting them. Experienced users know how to edit them. If you are willing to hang round and revert the vandalism, then you are welcome to enable the v-d-e option.

The templates have a default open position because it makes it simpler to template articles. When there are multiple templates, they can be closed with "state=collapsed" or "expanded=none" parameters. Where multiple templates are involved I am conservative about leaving the template open. I invite you to find examples where I failed to do that appropriately. Your claim that the default open position was to make the templates "more important than any others an article may be using" is false. You can make a demon out of anyone by selectively misrepresenting what they do.

I certainly don't claim ownership of the templates, but up to now 99.9% of the effort to build and look after them has been mine. If someone else comes in from out of the blue, and wants to make non-obvious changes, then they need to have the courtesy to explain what they are doing. How would you feel if you were in my position and someone came in and started making huge changes to all the templates without even bothering to say what they were doing, let alone discuss the matter? Seriously, how would react? That's what you did to me. I made the comments on your talk page because you were escalating in an out of control manner, and bye the way, trying to take total ownership of the templates yourself.

Anyway, can we drop this stuff now, and move on. You are very welcome working in fish areas, and I'll support you on the gradient look. I would like constructive feedback on the way I'm using dual templates. I know I'm not using those templates in a standard way, but that's because the standard templates won't do what I want to do here. --Epipelagic (talk) 04:42, 29 October 2011 (UTC)

OK, let's give this a further go. v·d·e should go in, then; it's standard and convenient. Didn't your edit summary say it broke the 'opening' per parameter mechanism? I'll look into it. And I watchlist everything I edit, so I'll notice any vandalism. You people are far too tolerant of vandals; I'd block any vandal for 3 months on one really bad edit.

The pages I first encountered this on are Current sea level rise and Future sea level. Go there and this template is half-open/huge. The even larger Template:Global warming is open to show all of its children (they're collapsed). These pages should wake-up with these closed; that's normal, reasonable and surely it's written up somewhere.

The colour, padding, line-height are all forcing things that are best left be. If the gradient look is deployed, these templates won't get it, will look even more non-standard, and they (or others) might get completely unreadable if the inline colour gets mixed with the gradient colour. All this inline stuff serves to impede such progressive enhancements. These styles should go. The width travels with the dual-structure.

When I first edited this, I left reasonable edit summaries; links to what I was looking at as to why to make the changes. I'm not going to seek-out whomever might feel in charge of something before I edit it; people don't own things, here; it's the commons, open. The whole internet knows the wp is about BOLD and /anybody/.

The dual templates are very unwieldy. Why are you doing this? Why not separate them and have normal sized navboxs? This duality results in a huge number of links being dropped into articles when they shouldn't be; the 'other half' is a sibling topic. How about we split one? This one? One of the other a better first?

One Ton Depot (talk) 06:00, 29 October 2011 (UTC)

Firstly I always appreciate being told when I'm reverted, preferably by the person who did the revert - most of the time one of us will learn something. Secondly, while "vde" is a bit of an abomination, embedding self ref deep in presentation, it is how it is done with navboxes, and with reason, since content should be editable and navboxes are pretty much content. Thirdly ad-hoc vandals rarely get as far down the page as the navboxes, so I don't see that as a major issue: if it is we can semi-protect it. Rich Farmbrough, 12:40, 29 October 2011 (UTC).

Finding a solution

@Epipelagic: I was intrigued by this comment of yours: You talk of "inline styles which hard-code a background colour". The code is just a script, which is read and interpreted at runtime. It is not hard-coded, because can be changed before rendering. Thus, if a user identifies as having a visual deficit, then it would be a minor coding matter to replace the inline background colours. Now, I've been programming computers since the late 1960s and designing webpages since the mid 1990s, but I still can't see how I can run a script on Wikipedia to allow an user to replace background colours that have been defined with an inline "style=" declaration (which is what I mean by 'hard-coded', i.e. a cascading style definition that will override all the earlier ones defined in .css files). Could you give me an example of what you mean? It would be a great help to me because I'm having real problems reading the text links against the #ABBEDC background:

Text links Plain text

If it's any help in explaining, look at the article Color blindness#Dichromacy; I have no problems with the first two images, but I can't make out anything in File:Colorblind5.png. Cheers, --RexxS (talk) 14:16, 29 October 2011 (UTC)

(I've reformatted this into its own thread) Yes, that must be very annoying. Does it help if you highlight the text? Seriously, if I thought that changing the background colour so it worked for you was the only way, I'd agree in a heartbeat. It's just that I'm sure there are much better solutions, and we need to find what they are. I may be off base here. I developed Pascal/C++ apps for many years, but moved to other things before the web took over, so I'm not a web developer. Code becomes hard-coded once it is compiled. But template scripts are interpreted on the run, which means that the script itself is susceptible to modification. This kind of thing happens on the web all the time, as in custom text which inserts your name where there are appropriate place holders. I don't know exactly how it would be done in this case, but there must be some way to preprocess html before it is submitted for rendering. It would be an minor exercise to write a preprocessor which can search the template script for background colours and replace them. An advantage of this approach is that it should be possible to cater for a range of visual defects, and give an optimal solution for each case. Another advantage is that the default position will allow Wikipedia to be optimized for those with "normal" vision. It will also put an end to all this unnecessary conflict. Anyway, the practicality of this needs to be assessed by someone with real knowledge of what can and cannot be done on the web. --Epipelagic (talk) 22:33, 29 October 2011 (UTC)

Oh sure, if I highlight the text, it stands out perfectly, but it's too easy to click a link when trying to highlight and you find yourself on a new (unwanted) page. I think we're using 'hard-coded' in different ways here. When a style is defined as a class or associated with an id using CSS, that style can be changed by a later declaration (such as myskin.css) which allows registered users to set styles they want on HTML elements that already have a class or id set by a higher level style-sheet (such as MediaWiki:Common.css). That means I can change, for example, the class .navbox – which has background: #fdfdfd; set in Common.css – to a different colour if I need to. However, once somebody has set a background colour inline (within the html on a particular page), it is no longer a simple job for me to alter that colour. That is what I mean by 'hard-coded' in the context of a style sheet/definition.

The sort of preprocessing that you describe is done by the browser on the client computer and depends on the client browser recognising particular input boxes and supplying cached information to them. Any scripting on a template is performed by an interpreter on the web server, so it is finished before the server transmits the page to the client. Unless the server 'knows' you have special requirements (a cookie set or a preference enabled that the server can check for), your browser will receive the same html & css as everybody else. It's that client/server mechanism that isolates much of what I can do on my own webservers from me when I'm working on Wikimedia software.

I'm aware that my visual problem is only shared by about 0.1% of the population, so I've no intention of pleading a special case for myself. Nevertheless, the principle of separating content (the html) from the formatting (the style sheet) is a key feature of modern web design as it allows the end user far greater control over how the content is presented to them. That is an essential feature for improving accessibility, not only for the disabled, but for those in third-world countries with limited bandwidth connections. From that point of view, we ought to be looking for ways of moving away from coding formatting instructions directly into our webpages. Cheers, --RexxS (talk) 23:37, 29 October 2011 (UTC)

A limitation of the css approach seems to be that it allows only one colour across all templates, like Ford's early cars, where a customer can have "any colour that he wants so long as it is black". I realize some code purists call that "ideal", and even promote it as "professional", but isn't that just a rationalisation of the limitations of the current css system? The subtext of "it is professional" is that if you don't agree then you must be unprofessional (end of argument), but that's a manipulation, not an argument. Does css allow other approaches? For example, will it allow templates to accept the background colour as a parameter which can be set external to the template script, as opposed to inline? There could be a global default parameter, and the ability to override that when defining a particular template. Users who identify with a visual deficit have an appropriate colour set as a cookie, and if there is no cookie, the existing value is used. Or can classes perform the same function? Could the cookie be the name of a class?

Again, cannot load times be approached in a similar manner? It just doesn't make sense, to me, to insist that the mainstream experience on Wikipedia has to be radically watered down to a one-size-fits-all version which maximizes the experience for people with colour deficits using cell phones or ancient browsers with low bandwidths. I mean… that's crazy; not the aspiration, but the approach. Surely Wikipedia should be aiming also at an optimal experience for users with high bandwidth, modern computers and "normal" vision. --Epipelagic (talk) 00:52, 30 October 2011 (UTC)

I thought I had "normal" vision, but like Rexx, I see no hidden numbers when I look at File:Colorblind5.png. I suspect this is true for many members of our aging population. Also, most of our audience is not logging in or editing the website. They are viewing it as an IP, to glean information from our resource. IPs do not have access to a set of Preferences settings. Many users will be viewing at a library or internet cafe or other IPs than their home address, and therefore will not have access to any method of setting up a cookie in the manner you describe. You are overlooking the simplest solution, which is to use the default colour scheme. --Dianna (talk) 02:47, 30 October 2011 (UTC)

Yes, I'm old and thought I had "normal" vision too, but I can't really see the number in File:Colorblind4.png. Cookies are not the same as Wikipedia preferences. It doesn't matter if a user comes in as an IP; a cookie can still be stored on their computer. What would be needed is something like an "accessibility" button, say at the top right of Wikipedia just before the search box. If you clicked it, you would be asked what kind of colour deficit you have, possible with a redirect to somewhere where you can test your colour vision for yourself online. If you select a particular deficit, then the appropriate cookie could be set set on your computer. There could be an option "none", and if you click on that it could clear the cookie if one had been previously set. An IP using a computer at home would have to do that only once. Library and internet cafe computers might need a different approach, where the preference is set for the session. There are bound to be solutions to these issues, but there has to be a will to look for them. Can you please clarify what you mean when you say I am "overlooking the simplest solution, which is to use the default colour scheme". That approach is the simplest to implement, but the comments above consistently point to how that particular one-size-to-fit-all approach does not deliver in a satisfactory way. What am I "overlooking"? --Epipelagic (talk) 04:25, 30 October 2011 (UTC)

What I mean when I say that "the simplest solution is to use the default colour scheme" is that "the simplest solution is to use the default colour scheme". There is no hidden meaning here. Read this. --Dianna (talk) 04:54, 30 October 2011 (UTC)

Sure, it's the simplest solution, and it's also a bad solution. I understand where this is coming from, but at present this approach has the simplicity, but lacks the "power". And for that reason, it is just simple, not elegant. --Epipelagic (talk) 05:18, 30 October 2011 (UTC)

I disagree. My opinion is that the whole set of templates should use default colours. --Dianna (talk) 06:36, 30 October 2011 (UTC)

Yes of course, you have made that very clear. But that is your opinion based on what reasoning? --Epipelagic (talk) 08:26, 30 October 2011 (UTC)

The power of using the default colours that are defined in style sheets such as Common.css is that anybody can make use of another style sheet to override them and meet their personal needs (and that includes IPs who can apply a local style sheet if they are using a modern browser). That makes it anything but a "one size solution". Of course the moment a style is written into a the html of a page, that ability goes out of the window. The developers are never going to allow the servers to read users' personal information beyond what is already done in User Preferences; it's fundamentally contradictory to WMF philosophy which seeks to leave users as anonymous as possible. Those are the sort of barriers that make me agree with Dianna when she recommends the default colour definitions to you. Hope that helps. --RexxS (talk) 16:53, 30 October 2011 (UTC)

(ec) Hi, all. I have prepared the following summary of the main points raised so far.To quote myself: One good reason to leave the templates at the default colours is because there are often multiple templates on any given article. The trend lately, at least on the more serious articles such as those on history, science, and the like, has been to remove the rainbow of colours from the templates for a more uniform and professional appearance that presents as a more serious resource. Also, according to Snook's tool at http://snook.ca/technical/colour_contrast/colour.html, your new colour is only "sort of" compliant: it meets the AA guideline but not the WCAG 2 AAA standard, which is the ideal. The default colour schemes have been tested on a wide variety of browsers and platforms to assure that those with vision impairments will be able to see the material clearly.

To quote Rexx: When editors introduce inline styles which hard-code a background colour, they lessen the ability of registered users to increase the contrast between text and background, since the background is then fixed for all. It is not a good trade-off to sacrifice readability for some in order to satisfy the aesthetic preferences of others.

Quoting One Ton Depot:The point of not deviating from norms is to allow the well-tested defaults to work equally well for all users. And what about the vast majority of readers who are never going to register an account? They get what is served, period.

If there are any of these points that are not clear, please let me know, and I will try to paraphrase. So far we have One Ton Depot, Rexx, Frietjes, and myself in favour of switching to the default colours, all for solid reasons based on accessibility issues, and consistent with the best practices recommended at WP:Deviations. I would say we are looking at a strong consensus for the change, and we should go ahead with it in the next day or two. -- Dianna (talk) 17:02, 30 October 2011 (UTC)

@RexxS: I was familiar with css as it was 15 years ago. The core principle of separating content from formatting was well established back then, though in those days there weren't the tools to fully implement it in real world apps. It is, as you say, a key issue which must ultimately prevail. I was arguing on this page that this approach still seems unable to deliver desired outcomes on Wikipedia, and asking why interim ways of getting the best possible outcomes shouldn't be used. Anyway, maybe the time has come to bite the bullet. Wikipedia already has a mediocre format, which will become even blander after this move. At the present, this will offer a solution to the few who can adjust their css-skins; the same few who are pushing for these changes. Tough for the rest. Anyway, solutions to relax this rigidity do seem to exist within the new framework. Maybe making the move will force the issue. Thank you Rex for allowing me to have my process, and addressing the issues without the patronising and bulldozing. It would help if there was a policy essay on Wikipedia where the rationale and capabilities of this framework, and where it is headed, are set out in readable way, so content editors need not be jerked around like this. But that wouldn't be Wikipedia's way. --Epipelagic (talk) 00:00, 31 October 2011 (UTC)

Hi, Epipelagic. It was not my intent to be disruptive by adding a title to this template and several others; the intent of the edit was to get the correct colour in the bar. I will undo the edits where the title was added. Regards, --Dianna (talk) 04:50, 31 October 2011 (UTC)

I have now got them all, I think. Please note that those particular templates are not very functional, because they are poorly designed. I am gonna leave it up to you whether to repair them or not. The way to do it is to break them into separate, smaller templates. --Dianna (talk) 04:55, 31 October 2011 (UTC)

Ah thank you Dianna. However, they are not "poorly designed" (you really can be masterly at patronising!). They were a compromise to try and get around limitations of the current design. But I've given up now. Yes, they will have to be rewritten. --Epipelagic (talk) 05:18, 31 October 2011 (UTC)

Models section?

Should there be a section for physical oceanographic models? There's a related template already, Template:Atmospheric, Oceanographic and Climate Models, though this includes atmospheric/climate models. Tfocker4 (talk) 15:29, 1 May 2018 (UTC)