Template talk:Table class/toc.css

This should have been more useful..

I recently implemented this, so as to cut down on the amount of inline styles used when building a ToC (and to provide a more effective example for the future given some new CSS features that would make the existing leader code ineffcient in comparision.) However, for various reasons the styles applied here are incomplete, and apparently overrode a style directly applied inline using {{ts}} in a specific example. When I asked if my logic in doing this was wrong, the approach taken was to use some existing templates that applied their styles inline, effectively rendering this stylesheet unused. ShakespeareFan00 (talk) 09:13, 11 February 2020 (UTC)

Thread copied from WS:H by request

Am I just being completely blind in my thinking here?

A locally set inline style with {{ts}} seems to be overriden by an inline one that's by an imported style-sheet.

I'm seriously considering giving up contributing long-term, because I don't seem to know enough to do it with it being completely inept. ShakespeareFan00 (talk) 00:44, 11 February 2020 (UTC)

@ShakespeareFan00: Now that page and the next at least display correctly separately. I haven't tried transcluding them together, of course. Does that help? —Justin (koavf)❤T☮C☺M☯ 01:06, 11 February 2020 (UTC)

That solved the issue for this specific example. What I was trying to do was to come up a way of doing a TOC like this using a simple table, and a stylesheet. I'd still like to understand why my attempts didn't render quite the way I thought they logcally should. (Stylesheet for the general case) and local or inline override for the header rows.). If imported styles are going to interact with inline ones in ways that aren't expected, then I'd ideally like to know where those interactions are likely to occur, so the relevant stylseheets can be designed accordingly. ( I already had to change the design of one stylseheet because certain rules interacted unexpectedly.). I also don't want to continually waste my (or other contributors) time trying to implement approaches, that seem to be incompatible with Mediawiki, other templates or as I'm increasingly finding the views and expertise of other long-standing contributors.ShakespeareFan00 (talk) 08:59, 11 February 2020 (UTC)

I have had trouble with conflicting CSS in the past as well and I tried !important rules that just got ignored by the software. :/ —Justin (koavf)❤T☮C☺M☯ 09:07, 11 February 2020 (UTC)

The question asked perhaps should have been, "In what order styles from are styles, applied? and how is the priority of conflicting rules applied?" , I have nasty feeling it might be browser-specific in terms of conflicting rules within an indvidual stylesheet, or as in the above example differing rules being applied inline to a parent, compared to a specfic rule on a child.. Perhaps someone should look into this more closely? ShakespeareFan00 (talk) 09:17, 11 February 2020 (UTC)

(Aside) Is there something like jsfiddle in the Wikimedia sphere? ShakespeareFan00 (talk) 09:17, 11 February 2020 (UTC)

The rule of thumb for CSS selectors is that specificity wins: a selector targeting a specific class will get overridden by a selector targeting an element with a class (specifying both the element name and the class makes it more specific). Inline styles (in the |style= attribute on an element override styles given in a stylesheet. !important should really not be used, but is, sadly, sometimes necessary in practice to get things to work (but try really hard to avoid them).

For Wikimedia wikis, the sources of styles I can think of are the basic styles of MediaWiki itself; the active skin (e.g. Vector); the project's Common.css; the individual user's common.css and skin.js; TemplateStyles; and styles set by JavaScript from either the project's Common.js, Gadgets, or user's common.js or skin.js; the user's browser's default stylesheet (which may be modifiable through preferences dialogs and such in some power-user browsers); and the user's browser's user stylesheet if set.

TemplateStyles will have a pretty high specificity because the extension does some magic to scope its effects to just the page content area (i.e. so it won't modify the toolbar or other site chrome). The style stuff on tables should have precedence essentially the same as an inline style attribute (I believe the parser transforms that wikisyntax to a HTML style attribute). Styles set from JavaScript will be essentially impossible to override from CSS, because they will typically be applied after CSS and override CSS styles unconditionally.

In the specific example here, without digging into it, I would also have expected your approach to work (the inline style provided by {{ts}} should have overridden styles from a stylesheet). However, provided I'm looking at the correct old revision, you're setting the style on the table row (tr), but the skin has a rule that targets the table cell (td). In other words, your inline style provides the default for inheritance, but the skin sets it directly. In addition, both "Chapter" and "Page" are the widest item in their column—i.e. the width of the column is determined by the width of the respective word—and so even if these were centered, the following cells in those columns will be aligned with the header's right edge, which looks like the whole column is right-aligned.

I can't dig in any detail right now, and I may have misunderstood depending on which revision of the page you referred to initially, so I don't want to go wading in there making changes. But hopefully something above may help you figure out the problem. --Xover (talk) 10:06, 11 February 2020 (UTC)

Can you copy this explanation to the Stylesheets talk page? Template talk:Table class/toc.css and we can continue the technical discussion on how to resolve it there? ShakespeareFan00 (talk) 11:35, 11 February 2020 (UTC)

{{edit protected}}

The rules involving .ns-104 etc should read body.ns-104 etc and the reference to .mw-parser-output removed, due to how Templatestyles seemingly attempts to process slectors not tied to a specifc element type. The result currently is that the wrong selector gets applied because it's trying to apply (once in a STYLE block) .mw-parser-outupt .ns-104 .mw-parser-output .__ribbon which is a nonsense as it can't occur. The fix (simmilar in approach to that used in the styles for {{Left sidenote}} should resolve this issue. ShakespeareFan00 (talk) 22:50, 27 November 2020 (UTC)

This edit request was actioned by Izno on 28 November 2020‎. --Xover (talk) 12:54, 18 February 2021 (UTC)