Form talk:Glob of Ectoplasm salvage research

signature field

Apparently if the signature uses any formatting then it "forgets" parameter 1, and fills in parameter 1 with parameter 2. (It didn't like any kind of apostrophe markup for bold, images, or span tags. Any thoughts on how this might be addressed? (I'm thinking perhaps the signature field could use {{{sig}}} instead of an anonymous field. Or it might be the data type.) -Chieftain Alex 14:58, 30 November 2013 (UTC)

We could write a widget to populate it with the username (mw.user.getName()) by default; unfortunately, that function returns null for anons, and I don't know how to get the IP address (that the wiki sees, not the user's local IP address). —Dr Ishmael 01:25, 1 December 2013 (UTC)

Well the bad news is that I had to make way too many edits to decrease all the parameters by 1, and that after using the form it now puts the entries on a new line, looking rather ugly in the edit window.

The good news is that because I used a named parameter for the signature, its no longer messing up! HURRAH. -Chieftain Alex 02:34, 1 December 2013 (UTC)

Apparently putting the named parameter before the unnamed parameter, such as {{line|signature=ABC|kit|2|3|4}} was being interpreted as {{line|signature=ABC|1=|kit|2|3|4}}.... this experience makes me think that semantic forms are really poorly built. -Chieftain Alex 02:43, 1 December 2013 (UTC)

Or it's designed that way since the order of the parameters isn't important to the form to keep it simple.--Relyk ~ talk < 04:33, 1 December 2013 (UTC)

It's the combination of named and unnamed parameters, which in itself is not exactly a best practice. Why don't you place the signature field at the end of the form, instead of at the beginning? That's where it displays on the page anyway. —Dr Ishmael 06:13, 1 December 2013 (UTC)

erm thats what I did after making it a named parameter. perhaps you mean the salvage parameter?

I'd have been only too happy to keep them all unnamed parameters, if not for the form decimating all the signature inputs. I still don't know exactly why converting the signature input to a named parameter allowed it to store signature wikitext. -Chieftain Alex 11:25, 1 December 2013 (UTC)

Lower resolutions

The form header does not align with the input fields on lower resolutions. Can’t this be made as a single table? poke | talk 18:10, 30 November 2013 (UTC)

Rather the input fields don't align with the header because the input field widths are fixed and the button elements screw it up if you decrease the field sizes. We can use the placeholder parameter instead of the header, the template shouldn't be adding 0 for the default since the template itself can do that if the parameter is missing. Maybe have a cheat sheet at the top for what the label in each field means as opposed to the header.--Relyk ~ talk < 19:09, 30 November 2013 (UTC)

I have heard that the placeholder parameter doesn't always work in IE + on mobile browsers relyk. + while the template can manage empty parameters, I think that the form cannot: it would shift all the values down by 1 parameter to compensate when next edited by form if left empty. -Chieftain Alex 19:49, 30 November 2013 (UTC)

Add named parameters along with unnamed parameters, should be standard practice to have named parameters for these templates. Unnamed parameters doesn't make it easier especially if we use a form now.--Relyk ~ talk < 19:59, 30 November 2013 (UTC)

looks like template breaks when you leave parameters blank - hard to proof against those.. -Chieftain Alex 20:12, 30 November 2013 (UTC)

ugly fix. I've copied the layout of the buttons + used the same for the header.. meaning it shrinks at a pretty close rate. only bad thing is the salvage kit label at the end is out by a few px, but its tolerable.

While I'd have liked to use one table for the entire thing poke, if I put an open table header {| above the start of the add template bit, and a table footer below the end template bit, it breaks the page. I could have used a header row for each "line", but that would have been worse imo. As relyk says, the form elements have a fixed width (effectively min-width) + they restrict the shrinking more than the typical stdt does. -Chieftain Alex 19:49, 30 November 2013 (UTC)

I was going to suggest sticking the header in the row template, but that would add it to all the lines rather than the on you're adding. Maybe we can have a separate table for displaying and modifying existing entries and then another table for adding your entry. You would only ever being adding like 2-3 lines at a time, 90% of the time being 1 line.--Relyk ~ talk < 20:05, 30 November 2013 (UTC)