Hey all,
The last thread was grinding even the spiciest computers to a halt, so here's a fresh slate to keep the conversation going!
Hey all,
The last thread was grinding even the spiciest computers to a halt, so here's a fresh slate to keep the conversation going!
Putting parser functions inside of default will not achieve my desired function of hiding the group when all are default - since the group will be visible so long as default is apparently.
Particularly in games, there's generally assumed consistency between abilities of a certain type. "Mobility" for example, is a certain type of ability. A feature of mobility appearing as "N/A" is information in of itself, but a non-mobility ability does not need to see all of mobility's N/A features.
The main point is I'm trying to make the information visually pleasing. Without defaults, "show=incomplete" generates the titles of all fields only when needed - but the boxes underneath are empty. This doesn't look pleasing when there's a grid of icons. I was only using "default" to format the empty box. An alternative solution to this "niche"/"edge" case would be to have show="incomplete" still "format" the empty boxes... but the help article for Infoboxes specifically states that "It would not make sense to test for the empty string in the switch statement; e.g., |=(unknown rank), because that is already covered by the default tag."
Group1 | Label | Label | Label |
Icon | Icon | Icon | |
Group2 | Label | Label | Label |
Icon | Icon |
(Where the empty box is incomplete.)
I want the groups to be hidden when there's no input. However, I want all the fields to be formatted correctly when the group is shown - and, at the moment, there's one empty box because it doesn't format empty boxes (because a switch's "#default=" is ignored). But if I add a variable default, it shows the group at all times.
However, if the default has no value (ie. if it has a length of 0), it will not be triggered, and therefore will not show the group.
I think the main problem I have is:
Because I do not think that a formatting default is the same as a variable default. And this is the logic of your counter-argument to my issue: there is no sense to hiding groups with "default values". You are correct. However, what I want/need is the ability to have default formatting.
In fact, I have encountered this issue many times before. "Default" is not formatted. I think it should be. The intent of "default" should be variable inputs - i.e. a default value. The "default" should still be formatted. At present you have to duplicate formatting in the default field to have the default visually match the other information - and this isn't an edge case, and doesn't make sense.
If this were the case, my request is simply that show="incomplete" formats all fields - even those that are empty.
Because I do not think that a formatting default is the same as a variable default. And this is the logic of your counter-argument to my issue: there is no sense to hiding groups with "default values". You are correct. However, what I want/need is the ability to have default formatting.
Therein lies the issue. Formatting a default differently than a non-default value (or layout based thereof) would be against the principles of portability, as content should not define presentation. Rigid grid layouts are not a great fit for Portable Infoboxes as a result, because the content should not be able to dictate the container. However, that's an idealist way of thinking. In more practical terms, grid layouts aren't always great portably because you can't guarantee whatever is reading it can interpret the grid (the term layout is the dead giveaway there). The device on the other end may be a screen reader, or a computer system interpreting the data. Even mobile devices don't do well with grids (even small ones), which is why Navboxes are also difficult to do well on mobile.
Anything having to do with presentation (like layout) should be CSS centric instead. There is a CSS selector called :empty (as in .pi-data-value:empty {}
) that you might try. You can even use a background image on those empty cells to simulate a blank value. In conjunction with show="incomplete" and omitting default values, that may get you closer to what you're looking for.
In other words, replace your placeholder "N/A" with CSS styling, don't use <default> for that, and the effect should be comparable or identical to what you're looking for.
FishTank wrote: Therein lies the issue. Formatting a default differently than a non-default value (or layout based thereof) would be against the principles of portability, as content should not define presentation.
Ummm, I think you missed the point of my latest/revised complaint. Default currently isn't formatted.
That is to say, <default>Bananas</default><format><span style="color:Green">{{{favouritefruit}}}</format> doesn't produce Bananas. At the moment, default is unformatted.
In other words: the current system already formats default differently, by default, because it currently doesn't format the default (meaning editors have to manually duplicate formatting into the default field).
The fact that content-specific formatting is already possible and that I'm using it is beside the point of this complaint. However, the fact that default isn't formatted is causing my issue. What I basically want is all my fields to have Coloured Square Formatting (and I'm committing a faux pas of having different colors depending on the content, naughty me) - but, at the moment, default isn't formatted! And me putting the formatting into the default field is considered a default value.
You're right, I did miss that. And I recall that there is a reason why <default> does not apply <format>, but I can't remember off-hand what the design rationale was. I can ask and get back to you — probably back over on the Portability Hub and not this year-old thread. However, the implementation is not likely to change, given the current state of the product.
Emptylord wrote:
That is to say, <default>Bananas</default><format><span style="color:Green">{{{favouritefruit}}}</format> doesn't produce Bananas. At the moment, default is unformatted.
... but, at the moment, default isn't formatted!
Note the closing tags, which should of informed you of why that wouldn't work. Create a class in CSS for the desired 'default tag' color.
Specify the "class" in desired default tags. You should be able to do the same for format tags. If color variations are needed use 'if' parser in the formatted tag or predefine before element and pass via {{{}}}.
If you desire to vary the default tag color youll need to parser the variables before the element and pass with value in {{{}}}.
Yes, I missed a /span in my rushed example but that is beside the point really. And I don't want colours, colours was a simplified example that allowed my to demonstrate it without uploads or specific information. The intent is informative icons (which could still be implemented via css, I digress). However I do not want to use default - using default prevents empty groups from being hidden. I just want all fields to be formatted when they're not hidden - ie have an N/A image.
Although you've inspired a solution. I'm skeptical that it'll work, but I wonder if empty fields still have he appropriate tags for css to add a background image...
my point was defalt tag was closed, before the format tag, the color change cant effect outside code flow.
default content is generated from a coded conditional result 'this or that'. In effect a placeholder if no data condition exists.
Class declaration should work for empty <img> tag and wont interfere with none classed images. last part of most parsers are for this type of use ie to catch an unhandled evaluation.
study 'ifexist' or similar parsers at Wikipedia/Wikimedia. Classes may not even be needed for your purpose. You don't seem to want default but an alternative to an empty data field.