Liggliluff wrote:
If you have an optional subtitle that you also want to have in the same colour, or a different colour than the normal background colour. You can't use the nth-element on the 2nd, as the subtitle is optional.
No, but you can also use .pi-title:nth-of-type(2) or .pi-title:not(:first-of-type) for subtitle.
Wikia currently gives: title, group header and normal item. Users can't add additional styles to this list. A text-size between title and group header, or a sub-group header; are a few things that comes to mind.
The subtitle is a common enough use case, and again, I'd recommend the above CSS selectors and successive uses of the <title> tag. As we don't offer nested groups (and those would be fairly difficult to implement on mobile), a lack of a sub-group header is fairly intentional. As much to the point: if sub-grouping is a concern, a consideration may be reorganizing your data. Some details may be better left in a table outside the infobox. Infoboxes are meant for a summary, not a comprehensive guide.
subtitle, subgroups, minor details, numbers and other information that would fit better in the infobox than in the article text, but might need a slightly different style to show how important it is. – On one infobox, it list all the premiere dates in different countries, and it almost fits on one line, but "leaks" over to the next. If it was possible to make the font-size of the premiere date slightly smaller, without making all text smaller, each date would fit on one line.
Again, I can only speculate in absence of a link or model. But given what you describe, I would suspect such an infobox has far too much detail in it and may be made more useful by breaking it into smaller modules or outside the infobox paradigm entirely. Minor details probably don't need to be shown in an infobox at all. A rule of thumb should really be whether all that data is useful at a glance. There are some good blog posts about this re-conceptualization on the Portability Hub: Building Better Boxes: Organizing Your Data is one. In your example, how important is it in the future for a reader to instantly be aware of the release date in different countries, rather than looking at a table in the body of the article? If that is a major concern, perhaps each release country should have its own data row in a collapsible group, thereby solving the issue in a different way.
One of the key points of portability in general is that the nature of the content should not define presentation. The kind of fine-grained detail over font-size may well be irrelevant dependent on the browser it is viewed on, and the rigid control over that presentation is not future-proof. What may fit on one line today may not with tomorrow's version of Firefox or Chrome.