User talk:Inductiveload/site-css-js/Coltest.css

back to basics
 Salmon Ravioli 7.95  Fried Calamari 8.95  Almond Prawn Cocktail, with orange and potato salad, spring carrots, blue cheese, tuna, and prawns. One should never assume that his side of the issue will be recognized, let alone that it will be conceded to have merits. 7.95  Bruschetta 5.25  Margherita Pizza 10.95 

bending the basics (to see what breaks)
 Salmon Ravioli 7.95  Fried Calamari 8.95  Almond Prawn Cocktail, with orange and potato salad, spring carrots, blue cheese, tuna, and prawns. One should never assume that his side of the issue will be recognized, let alone that it will be conceded to have merits. 7.95  Bruschetta 5.25  Margherita Pizza 10.95 

this seems robust (but complicated!)
    </li> <li style="margin:0; padding:0;"> </li> <li style="margin:0; padding:0;"> </li> <li style="margin:0; padding:0;"> </li> </ol>

Cell 1?
Cell 1 is often different in styling from all the other cells of the same column; I really need COL tag for complex tables formatting. --Alex brollo (talk) 14:05, 7 September 2015 (UTC)
 * This is only the .css that supports a single test example at Style guide/Tables/Testbed. More at T2986. -- George Orwell III (talk) 01:12, 9 September 2015 (UTC)
 * Is aligned table worth mentioning here as a possible alternative for Alex's consideration? One warning: it would appear to be currently unused outside of its own documentation (on further investigation it appears only George Orwell III and myself have ever mentioned it in the past; probably nobody else even knows about it?) AuFCL (talk) 23:34, 11 September 2015 (UTC)
 * Sure -- it seems like a variation on the same theme that I'm in favor of just accomplished through LUA rather than with css3 definitions. The problem I see with either approach is overcoming the longstanding poor practices when comes to table application. If we can manage to separate the approaches for occasional complex tables (tables found in the body of a PSM article for example) and frequent common tables (such as the toc or index for PSM volumes), I'm sure we can come up with a less inline &/or parser intensive method for each. The first step has always been reaching some sort of community consensus of what exactly the "baseline" formatting for both occasional-complex and frequent-common table types should be and then build (templatizize) from there as user needs or formatting caveats may require. I never understood why we can't seem to do this for at least a single row of the more common toc entries between 2 to 5 table-cells long per row even. -- George Orwell III (talk) 23:56, 11 September 2015 (UTC)
 * This is not the place to have this conversation.
 * The "community" will instantly split itself into two camps: those who expect dot-leaders to work; and those who do not want them at all.
 * The "community" will also split (non-overlapping set) into camp of those who expect links (chapter and page) to magically propagate &amp; those who do not.
 * Do I really need to expand further upon this well-worn theme? AuFCL (talk) 01:22, 12 September 2015 (UTC)
 * Agree. its that slippery eye-talian Alex who keeps forcing me to try and pick-up and/or correct where he last leaves a singular topic "off"
 * dot leader magic need not rely on the TD holding the "text". If we can get dot leader magic into some sort of Div based template this is a non issue
 * same as above. TD formatting should not care what resides within that cell nor what (if anything) that thing "does".
 * Point taken. Pretty soon I'm just going to shove "faux tables" down everybody's throat - it seems like the only way to make folks realize its the key to near exacting html table renderings found with their true html table tag counterparts...

In short, if the following .css is in "effect"... .... and then build the following table to reproduce COLGROUP and COL capability, ...viola! Below is the final rendering with the faux COLGROUP and faux COL tags applying background colors just like the normal COL and COLGROUP html tags would outside of the wiki markup environment. Example Lot No.     Item Price 896     SCSI card $53 So again, the solution for sometime now has been the application of newest advancements in css3 (works for everybody except those still using IE8 or lower that is; e.g. hardly anyone at this point). Why can't people just change with the times when it comes to this? -- George Orwell III (talk) 01:59, 12 September 2015 (UTC)
 * That is so pretty (sob!) I cut myself off earlier before stating I agreed all points (that has not changed since and besides I figured you already knew.) Now where is this piece of propaganda going to continue so as you-all can preach to da masses? AuFCL (talk) 02:14, 12 September 2015 (UTC)
 * Where? Why not here? Its not like anyone else beside yourself is going to help me think this through from inception to application is there? Where do YOU think this should take place? All I know is the very first thing that we need address is how best to mimic the current table html stylings with their faux DIV counterparts while keeping an eye towards practical/common WS usage in our .css definitions. -- George Orwell III (talk) 02:34, 12 September 2015 (UTC)
 * You damned opportunist, you. So be it. Let me get a bit of (only semi-related) basic research out of the road and I'll get back to... here. I'll ping you then. AuFCL (talk) 02:49, 12 September 2015 (UTC)
 * My English is largely insufficient to understand what means "slippery eye-talian Alex" in its semantic subtleties, but... this page is really very interesting and inspiring! :-)
 * Unluckily, dealing with complex tables, I hoped that col (or faux-col) support text-align and vertical-align properties - they can't; I never feel the need to use background-color, so the unique interesting property I could use is border; this doesn't avoid the need of an heavy inline styling at cell detail.... what's a pity. --Alex brollo (talk) 13:08, 16 September 2015 (UTC)

Faux
Right. As promised.

The following might well be too stupid for words but at least it gave me some practice and familiarisation with your "faux" CSS set. Due to limitations in my test-bed (I have extension:CSS installed: I've nagged you before and won't go there again I promise!) some layouts might seem a bit wonky. I have tried to note issues as they have cropped up as well as expunge misleading ones as resolved but may have slipped up.

Additional CSS (supplementing "standard" FAUX set)

Example Lot No.   Item Price 896   SCSI card $53    low  &bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull;&bull; high Range Demo 2¢
 * Use within "table"


 * "Traditional" invocation for reference purposes

Chap. Title what runs on and on and on and on until it wraps around the whole line to test hanging indent wrapping behaviour something akin to how this line behaves! I do not seriously expect anybody to be remotely interested in what I have to say here! &shy;   Page
 * FAUX version of above utilising LUA

Chap. Title what runs on and on and on and on until it wraps around the whole line to test hanging indent wrapping behaviour something akin to how this line behaves! I do not seriously expect anybody to be remotely interested in what I have to say here! ..........................................................................................................................................................................................................................................................................................................................................    &shy;  .......................................................................................................................................................................................................................................................................................................................................... Page I have just wasted hours on an annoyance which amounts to some part of mediawiki which expunges the combination  before it hits the browser. The old version did not do that! AuFCL (talk) 07:29, 12 September 2015 (UTC)
 * FAUX version with inline constant strings

Some questions

 * How does go about one merging two adjacent "cells" within the faux-table model? (I realise this question may not make sense but within the TOC-forming family quite often centred section or book titles may appear interspersed with regular columnar Chapter-Description-Page sets and it seems contrary to close and reopen the table structure each time such an interruption to the pattern occurs.) Context of this enquiry: TOC row c, TOC row r compatibility. AuFCL (talk) 08:25, 12 September 2015 (UTC)
 * Let me guess:  is incompatible with  ? AuFCL (talk) 13:24, 12 September 2015 (UTC)


 * Although mentioned above to make this point explicit the current mediawiki parser appears to "optimise away" the construct  as demonstrated here: &rarr;  &larr;. Normally who would care but guess who foolishly crafted their CSS to use this as a null place-holder as it happens to still work on my 1.21wmf12 testbed (Yes I stuffed up—that's another story.) AuFCL (talk) 13:24, 12 September 2015 (UTC)
 * Also mentioned elsewhere but repeated here: the whole dynamic-stretching-leaders issue. At a technical level are you aware of a more-universal solution to the "use  with a colour-specification (  not allowed on a higher   layer to wipe out unwanted artefacts drawn by foreground components of a lower   layer" problem, especially since the base page colour is not in general known. Painting around blobs of   is just amateurish. AuFCL (talk) 21:07, 12 September 2015 (UTC)
 * Which brings up the general problem that a lot of opposition to leaders stems from the fact HTML solutions for the desktop don't translate into mobile mode (yes I know a favourite topic of yours.) AuFCL (talk) 21:07, 12 September 2015 (UTC)
 * And the quite distinct problem that leader solutions don't survive the conversion process to eReader formats (I suspect quite a lot of the unstated resistance to faithful page reproduction is behind this.) Is there any real expectation the tool will improve/be replaced by mobile and die/provide a reliable benchmark as to limitations to work within (ideally choose one?)


 * Coming full-circle is it reasonable to try to isolate a table of "TOC-ness" perhaps containing a banner line (for each of top and bottom,) individual column contents for each line, and an outgoing device identifier with subsequent format specifier for each device/case. And you thought dotted TOC page listing was a complicated beast! This stuff is likely to kill template limits: maybe we need to co-opt a tool-labs guy and start thinking along the lines of preprocessing? AuFCL (talk) 21:07, 12 September 2015 (UTC)

Holy Sh!t... I thought we'd start today but I see I need to catch up to you:) Quickly -- I have not found anyway to mimic colspan= or rowspan= under Faux based tables (at least not yet) so put that back burner for now. Second, I see you've gone right to addressing the content within a cell rather than where I had hoped -- building a baseline css to create simple (and repetitive) formatting for index or toc reproduction purposes. That is why I linked to the current HTML5 valid elements and what they provide as default .css attributes w/ their values as per the W3 specs yesterday. Take the opening TABLE tag for example: the primary variance hinges upon the [default] display: value table or the [alternative] value inline-table. The next critical attribute is border-collapse: where the default is separate -- which comes with associated attributes border-spacing: 2px 2px; empty-cells:show; while the 'alternative' for same border-collapse: is collapse -- which comes with associated attributes border-spacing: 0 0; empty-cells:hide. The vein of questions I hoped to address first based on this TBLE example was whether it made more "sense" to make 4 .css definitions ( or something along those lines) or define just 2 and let the remaining 2 associations be handled via inline styling embedded within a template or two instead. The same sort of step-by-step "outlining" would be done for the remaining table elements and then we'd start worrying about things like dot leaders and anchor page linking Hope that made sense. -- George Orwell III (talk) 21:21, 12 September 2015 (UTC)
 * Pretty much the response I expected. And thank you. I agree with the four-way "table" class split although had already mentally tagged the separate/collapse pairing as border/no-border if an alternate semantics is permissible. As for staring at the "wrong-end" I thought it better to start with the impossible problems and raise all the issues I came across knowing the simpler ones would be solved near automatically later on. Assembly-language generation: what can I say? The col/rowspan stuff is do-able but my solution is ugly and must be bettered to be accepted. The table teaser is just that and if it provokes some thought that is probably enough in itself.  Sad to say the bulk-standard-class approach is incompatible with the "let ordinary plebs do the formatting as well as proofread" model. Any serious approach would involve user/formatter/admin access models but that ain't gunna happen not nohow.  Anyway a start has been made within the confines of our own little virtual paper bag? AuFCL (talk) 21:48, 12 September 2015 (UTC)
 * Thanks for muddling along with me. UPDATE: I think Alex did it to me again -- I can't seem to "format" anything other than background-color when applying straight COLGROUP & COL tags outside of Wiki mark-up nor under wiki markup using the faux COLGROUP & fax COL approach. If you can verify, then we can safely call DAY1 a big honkin' waste of time. If so, the focus shifts back to coming up with css definitions using pseudo attributes nth-child &/or nth-of-type that MediaWiki:Coltest.css was originally geared for. -- George Orwell III (talk) 22:05, 12 September 2015 (UTC)
 * I don't think I understand (unless you are referring to the  weirdness I alluded to earlier?) As a quick test:


 * —largely works (if that was the sort of thing you were testing?) My only disappointment is that  specifications made at the "COL" level do not appear to propagate to the corresponding "TD" level (see "!" cell on LHS vs RHS above.) Perhaps this is an unreasonable expectation anyway? AuFCL (talk) 00:26, 13 September 2015 (UTC)
 * That's what I meant - text-align:, padding:, vertical-align:, white-space: -- and most other useful attributes do not seem to propagate to the corresponding cells in the desired column. The only other thing beside background-color: that I could get to work was visibility:collapse;. The whole point of taking advantage of COL was to reduce the amount of inline/ts parser calls needed to establish a "default layout" rendering for any given bloated template (some of which you've already listed). -- George Orwell III (talk) 01:08, 13 September 2015 (UTC)
 * Oh Bah! I had missed that (looking back) because, probably force of habit rather than consciously, I made my tests with such attributes added to the "faux-td" entries. I'm afraid your wash-out sentiments might be momentarily accurate. Still I think this exercise is going up a siding in any case: what we most definitively do not want is another resource-hog solution; be it template-based or otherwise, as this is just patching over the current system limitations. What we really need to put some thought into is breaking down the current proofread&amp;format&rarr;validate cycle into something like (I see a ProofreadPage-loyalty-emotional-breakdown coming on):


 * —not likely to happen is it? However our current mindset is analogous to hoeing a field using a jewellers screwdriver mounted upon a combine harvester. Of course it can in principle be done but it is neither the best nor the smartest approach to the given task is it? AuFCL (talk) 01:51, 13 September 2015 (UTC)
 * I'm in 100% agreement that we don't need another resource hog solution and that will entail some mix of css class definitions, variable inline stylings and/or templatization (possibly Lua if feasible too) at the end of the day, but my main concern remains the generally accepted approach -- specifically to reproduction of ToCs found in source works -- around here. The modern day equivalent to a printed ToC of old is the html item-list & not the html table. We should be keeping pace with current document semantics and using a modified OL/UL framework to render ToCs. That doesn't mean we can't use TABLEs at all -- just that they should be the inline content for each ToC line entry (LI) & not the framework itself. Something along the lines of...

</li>

<li> </li>

</ol> <ol style="list-style:none; margin-left:0;"> <li> </li> <li> </li> </ol>
 * .... I know that seems like adding another layer making the bloat even worse but document semantic wise its the best thing to compliance we can get under the wiki mark-up. Most of the current bloat is from folks wanting DotLeader capabilities followed by ts parsing over and over again - the basic formatting itself is not a big hit; nor should the inclusion of a list item approach be one either. The mobile question comes after all our desktop ducks are in a row. -- George Orwell III (talk) 02:41, 13 September 2015 (UTC)
 * I quite like this. I admit I initially misunderstood your intent but this is not unfamiliar. However people have been educated (dare I say propagandised?) into thinking this sort of stuff can be templatised and the result will unfurl efficiently. If that were remotely true in practice then what were the recent HHVM experiments all about? I still lean toward the idea of some kind of execute-once (offline?) script (gosh could even be subst:!) to convert the communal soma into HTML once the validation stage has been bedded down. If this is too disruptive I'll drop the idea (my bit;; not your multi-tabular-list concept.) AuFCL (talk) 03:33, 13 September 2015 (UTC)
 * No No -- I'm starting to think your previous ....aligned table worth mentioning bit is a model worth looking into to see if something more specific can be made just for the ToC scenarios. -- George Orwell III (talk) 03:51, 13 September 2015 (UTC)
 * Just in case I was not sufficiently clear above please take the expression "desktop HTML" in my proposed flow above to further encompass the sub-cases of per-name-space rendering. All of Index:, Page: and main name-space have some likelihood of TOC display and have differing layout attributes. Is it worth picking some representative existing TOCs and picking them apart for cases/data/format-and-repetition rules. Oh no! I am staring to think in terms of TOC storage in wikidata with microcoded extraction/presentation engines. Make it stop! AuFCL (talk) 02:34, 13 September 2015 (UTC)
 * See my comment above. I get the feeling we can do this through LUA if I only knew how !!! -- George Orwell III (talk) 03:51, 13 September 2015 (UTC)
 * Well colour me surprised (you'll need a pot of transparent paint: I think you'll find that in aisle 7 dispensed from that tap labelled: "water.") Well neither do I know LUA particularly well but this little task might be our mutual opportunity to change that peculiar state of innocence. In short: willing to help where I can...and there are always means to $$\displaystyle{\cancel{\text{cheat}}~\text{engage in productive research}}$$. AuFCL (talk) 06:17, 13 September 2015 (UTC)
 * After taking an even closer look -- and if you recall/refer-to our previous endeavors -- all we really need is a way for LUA to handle any user selectable symbol and now many times to repeat that input for the ::after pseudo-class' content attribute and the rest seems 1000% easier. -- 05:18, 13 September 2015 (UTC)
 * Agreed. Might as well put some of that bitter experience to use? AuFCL (talk) 06:17, 13 September 2015 (UTC)
 * Also if I recall correctly it was you who persuaded me that  (or for that matter  ) was a loser due to the fact people expect to be able to override the leader format (fixed content/repeating &bull;&middot;&bull; sequences/fixed header and trailer and symbol-group letter-spacing/and probably even something weirder I cannot currently recall.) This stuff is not only a can of worms but a can-full of cans containing what you can only hope are as pleasant as worms. AuFCL (talk) 06:24, 13 September 2015 (UTC)
 * You might recall better than alright. I could not find an instance where lua can generate the needed with the wanted symbol and insert that as a value for an attribute in .css -- only as an inline styling. I'm beat after all that reading so I'll check in tomorrow. -- George Orwell III (talk) 07:45, 13 September 2015 (UTC)
 * Are you hoping LUA has access to the page style sheet? I am pretty certain that is not true: as far as I know LUA's ability to influence its environment is no more than any other parser function but I fear I must have missed your point. aligned table does not appear to have any kind of cell-merge support (colspan, rowspan) and surely that will be needed for any real TOC application. Also be aware that "aligned table"'s documentation does not mention parameters (such as title or the utterly mad alternate implementation: above which appears to be the only colspan concession in the code) which are nonetheless supported. Also beware cell styling overrides in "aligned table" replace those established upon the column but not those established upon the overall table (to be fair this is more or less documented but it surprised me anyway.) (Pardon the following: probably more a personal learning exercise than generally useful. And no the results are not identical.)

vertical-align: middle
This one reason I keep pointing to the latest HTML5 rendering specs. I'm just as confused as to what dictates that value by default as well as its inheritance hierarchy. First they give... ...followed by... ... so I'm not clear what is "correct" way to set vertical-align to something other than middle for individual cells. do I change it at the TBODY level and let TD inherit that from TR? Do I force TR and TD in inherit that? Confusing alright. -- George Orwell III (talk) 01:23, 13 September 2015 (UTC)


 * I noticed that too (I find the rendering specs. pretty turgid; I hope in time all will become clearer; in particular I am having difficulties with the inheritance tree: it strikes me the presence of faux-tbody wrapping all the faux-th and faux-td's forces that part of the hierarchy to be one descent level deeper than the faux-colgroup collection. Whether that observation is in the slightest significant escapes me though.) AuFCL (talk) 06:17, 13 September 2015 (UTC)

Experimentation
Pre-warning: this line of inquiry currently goes nowhere productive: Well that was a lot of no use. I'll leave it up rather than retype it should further thoughts occur. (In case not obvious I was playing with the idea "faux-body" might be acting as a barrier to inheritance as it logically lies "across" the table structure—clearly this is false but its involvement is not yet exonerated either.) AuFCL (talk) 21:26, 13 September 2015 (UTC)


 * Case of "Simple" TOC implemented via


 * Case of "Simple" TOC implemented via demonstrating table-level rules


 * Case of "Simple" TOC implemented via demonstrating column-level rules


 * Case of "Simple" TOC implemented via demonstrating row-level rules

Aligned table: Future potential issues

 * 1) How to handle cross-page structures? The current LUA code builds monolithic HTML and may not cater for creation of unbalanced open and close tags. Needs further investigation.
 * 2) Assuming above solvable ought consideration be applied to creation of an alternative (aligned-faux-table?) to create div class="faux-???" output? (May ease leap to mobile? The issue of spanning cells arises again.)

Both points realized here as well. Upon considerable reflection, I'm afraid aligned-table (in its current form) won't be useful for either type of table-like reproduction needed by us on en.WS simply because its not likely to respect the nuances of multi Page: transcription and/or end-product transclusion as you surmise. I know this needs to be properly ruled-out but I'm not even sure if that is worth doing if the focus to follow is limited to just ToC reproductions, where content alignment is set/repetitive throughout and borders are rare if at all. And if that focus further incorporates the list-item to inline-table approach I left off with last week, I doubt there will be any insurmountable instances where the lack of colspan= &/or rowspan= capabilities can't be overcome somehow before the finished rendering (I hope). I'm assuming each ToC entry will follow the current template practices where at least 2 columns are present normally but that may expand to 4 columns if chap numbering &/or page range(s) are present (anything with more than 4 columns doesn't seem like the reoccurring "norm" around here right?). Back when I get some more free time. -- George Orwell III (talk) 22:41, 17 September 2015 (UTC)


 * (start with an aside) You may have noticed I resynchronised, in turn, aligned table's documentation with what the code actually supported; did some tinkering to add a couple of features I thought would be useful and only then it dawned upon me that the documentation also held a few traps in that the code not only did more than the documentation implied; in other areas the documentation promised things that were never implemented in code. I have not investigated in detail but am under the impression there is a LUA coder over on WP who rarely or never writes the documentation other than corresponding with another individual who never seems to write code but maintains the documentation and passes on feature requests to the first person. Somewhere along the line the two approaches have diverged and apparently nobody has noticed. (In some respects this is a coward's summary as I do not want the angst of really finding out for sure.)
 * Having said all that I think aligned table is fairly useless except as a familiarisation exercise: to handle cross-page+assembly stuff (a situation near unheard of in the Other Place) the first thing needs ditching is the  stuff. Whilst a wonderful crutch neither the "add &lt;noincludes&gt;" nor the "hanging mismatched tags" approaches are going to work nicely; will break compatibility and all that lovely effective support derived from being able to resych. the latest enWP code.
 * If we decide to go down this path I would argue strongly for rewriting a private version of which constructs all html tags directly (which is no drama at all for anybody familiar with most templates around here. Just doesn't look that resumé-impressive.) All the logic is already in place and adding a ,     trio gives all the building blocks I think will be required for multiple-page support. After a bit of a mental block as how to even approach this I've stretched  a bit more with the addition of new flags  ,   and   (Hmm, Yes) to suppress each component selectively. See below. AuFCL (talk) 21:07, 19 September 2015 (UTC)
 * If we are to go to the effort of making our own Franken-aligned-table then adapting it for list-table structures will be no great extra strain. I support this option. (Aside two) The border stuff was motivated obliquely by noting aspects of Alex brollo's work (I've not communicated with him) and merely fleshes out my personal informal set of test/demonstration cases. AuFCL (talk) 06:00, 18 September 2015 (UTC)
 * Very impressive! I'm leaning towards making a variant module to specifically handle our ToC needs in light of your experimentation as well. As to my own findings, the "list-item" approach has its own possible pitfalls - mostly width issues per each entry when some entries are too short and some entries that need wrapping both within the same "table". It seems this can be overcome by "heavily" forcing 100% width values on the key tag values however. I'm also concerned that the Aligned table approach is overly complex given the amount of possible variables one can apply vs the number actual variables being reapplied over and over again in a typical ToC reproduction specifically on en.WS. Still, some of the current incarnations using Dotted ToC and/or the table parsing already approach a comparable level complexity so I might be worried for no valid reason here. In addition, I've found the most applied User: applied setting(s) when it comes to tables overall are top-right-bottom-left (trbl) padding for table-cell content followed by top-middle-bottom vertical-alignment of said table-cell content. If we can eliminate some of these parsed ts/table style template calls with class definitions, it could reduce the amount of post-expand "stress" when it comes to tables across the board. I think I'm going to poll the community for what those two attributes default values should be as the first step to achieve that "reduction". Good Idea? -- George Orwell III (talk) 00:04, 20 September 2015 (UTC)
 * W.r.t. trbl alignment I could not agree more. I was going to tentatively suggest the compass-points model (I think my private definition of classes "grav-nw" and "grav-se" might have crept into some of the sample demonstrations. TCL influence?)
 * OH THATS SO PERFECT! Call me 'slow' but what is grav short for exactly? I'm completely sold on the premise and love to add it to the site-wide stuff asap but I'm not sure if grav- is the best "hint" as to what we're defining here (or if a prefix is needed at all?). -- George Orwell III (talk) 00:58, 20 September 2015 (UTC)
 * Re: "grav": I was casting around for a tie-breaking symbol which would not interfere with anything existing and sort of hit on this as a contraction of "gravity"? See how twisted one's thinking can get when choosing meaningless, meaningful symbols? TCL has keywords (in point of detail the Tk package) -n, -e, -news etc. Please pick something which makes sense and I shall fit in. AuFCL (talk) 02:36, 20 September 2015 (UTC)
 * pos- (short for 'position') was the first thing that popped into my mind and can't think of anything "better" since. I'd vote for that unless you have something "better". -- George Orwell III (talk) 03:27, 20 September 2015 (UTC)
 * pos- it is then. 03:45, 20 September 2015 (UTC)
 * I'll figure where best to add these tomorrow. -- George Orwell III (talk) 03:54, 20 September 2015 (UTC)


 * If my latest little mutilation of hasn't made you completely sick at heart (object&rarr;string conversion for regexp editing convenience: some OO programmer is weeping into their breakfast cereal) I think the point is approaching where list-of-tables might be coming for consideration as the break-away LUA candidate? Lets try to tie down as much as possible in classes and if an analogous situation arises to the column-inheritance problem LUA can propagate the constant style or class reinforcements whereever necessary. Same goes for leader constants if so decided. If I recall Module:dotted TOC page listing was abandoned primarily as at the time system profiling implied LUA overheads were only marginally different to those of template expansion. I wonder if that is still true as so much else has changed since 2013? AuFCL (talk) 00:40, 20 September 2015 (UTC)
 * Hmmm... that's worth re-visiting alright. The collective understanding of Module: ins-and-outs is much better today than it was back then for sure. -- George Orwell III (talk) 00:58, 20 September 2015 (UTC)
 * After taking another look, the first thing that I think needs attention is a conversion that uses normal HTML table tags rather than the current wiki symbol mark-up for table elements. -- George Orwell III (talk) 01:44, 20 September 2015 (UTC)
 * Oh yes. I think that thing ended up with more debugging code crusted on than actual substance... AuFCL (talk) 02:36, 20 September 2015 (UTC)
 * Further thought -- since there are camps that are indifferent to having dot leaders in their ToCs and those who can't live without them, why not just have those leader related divs reside in their own Module leaving the remaining Toc entry a matter of just "compass" aligning and padding each cell of a two, three or four column table to its own devices? I see more flexibility with that approach -- which, in some number of instances, will reduce the amount of resources being called upon. -- George Orwell III (talk) 02:00, 20 September 2015 (UTC)
 * Not entirely sure I follow. Did you mean one LUA module invoking another LUA module (effectively one level handling the "list" and the innermost the "table"s, giving the user the ability to choose from a predetermined set of leader/column/(layout?) alternatives)? This is almost getting back to the TOC begin concept via different means; not that this is a bad approach. AuFCL (talk) 02:36, 20 September 2015 (UTC)
 * That's sort of what I meant - I think if we 'Modulize' the DVJU offset and Dot leader portions we can leave the table/col/row stylings for templates to handle without running into the cross-page or resource bloat issues like we have now. And fwiw, I've always liked the TOC begin family of templates' approach to this but since it was originally is based on the symbol-driven wiki mark-up design rather than straight HTML table tags, its always been too limiting for broader usage and/or more refinements just so it can accommodate the quirky nuances in things like multi page breakage into a single final page transclusion as we touched upon earlier. I'd rather mimic the current family of templates with a new family based on tags rather than wiki mark-up -- I believe superseding the current coding would/could require too many per application considerations for things like NOP usage or header/footer exclusion for example. -- George Orwell III (talk) 03:27, 20 September 2015 (UTC)
 * Well I'll freely admit performing an inquiry of index: page space to determine scan-to-paper-page mappings lies rather beyond my current skill set (I can sort of visualise a javascript helper application scraping the page and building a prototype: a sort of preload gadget variant perhaps?) This is going to keep both of us entertained/in headaches for a while unless anybody else can be drafted in. If you call this as stalling behaviour; for the moment you've got me bang to rights. Need to sleep on this. AuFCL (talk) 03:45, 20 September 2015 (UTC)
 * . Yes, I can use a good nights sleep on all this too. I'm pretty much done for today. -- George Orwell III (talk) 03:54, 20 September 2015 (UTC)

A Proof of Concept
Well I am sure this will cause much amusement but having messed around for the last week or so trying to bend LUA to my will I thought I had something worth showing off at least as a proof of concept of most cases short of leader support so far. Imagine my chagrin that the damned thing sits there in wikisource and does nothing apparently because (even though I followed aligned table precedents) no parameter values survive the transfer from template invocation to LUA execution. Works well in debug mode but that doesn't convince the punters! Now please complete my annoyance by spotting the comma I've missed somewhere important...please? AuFCL (talk) 01:38, 25 September 2015 (UTC)


 * Another couple of days on and I have become seriously disappointed with the sanguine fashion in which LUA has been shoehorned into the mediawiki environment. I think the designer must have used a hammer because the resultant mutant is quite brain-damaged. I shall say no more unless further provoked. Now following is the demonstration I meant to show you days ago. AuFCL (talk) 01:00, 27 September 2015 (UTC)


 * Based on How_to_Know_the_Ferns_(7th_ed) (Whatever happened to that promise regarding "pos-compass" classes? I shall leave this up in its "eccentric" form as a reminder: Done: AuFCL (talk) 01:00, 27 September 2015 (UTC)):


 * I can't find any sort of "typo" in the module and typos are about as much as I can do when it comes to Lua in general. I commend all your efforts & encourage you play with this at your leisure -- I'm afraid I'll have to come back to it in a week or two when I have more free time in general. In the mean time, I really need to work on re-vamping the header template as I'm getting more and more "complaints" about our mobile view's on phablets and smartphones lately. -- George Orwell III (talk) 03:02, 27 September 2015 (UTC)
 * That is quite O.K. and I understand. I would like to tackle at least simple dot-leaders next and that will probably take me another week or so anyway. It was getting frustrating not being able to get LUA to "play" but I have gone back to utterly bloody-minded basics due to both documentation and current practice being at complete cross-purposes. The transition of parameter values from template to LUA-land and back is clearly a bad, bad joke and I would like to hear from anybody prepared to contradict me. I suddenly realised all the documentation I had planned was either still in my head or on all those sheets of notepaper I threw out in frustration a few days ago when nothing would work properly. So if what I've just put down reads too badly I can only apologise and will try to do better in a later draft. Just so long as I am not wasting both of our time on a fruitless diversion? AuFCL (talk) 03:34, 27 September 2015 (UTC)
 * Not at all; I fully intend to "work" this ToC/Table/Module thing to the end, frankly, with or without anybody's help sooner rather than later. I'm just swamped with "real life" stuff and can't come and go as much as I did just a few weeks ago. Again, I'd much rather "work" this with you than go it alone but it would be unfair to you "feign" true input on this front when I know I just don't have the time. And I feel what "free time" I do have can be best utilized on the header revamp front. Who knows - next week everything might change and I can multi-task again. Still, I don't want you feel obligated to continue (for the time being) on your own unless you want to. Sh!t... you can shelve it and go about your business (or join me on the mobile front even). -- George Orwell III (talk) 03:57, 27 September 2015 (UTC)
 * Thank you for the kind invitations. However the initial audience is incompatible with my participation. I might join in later on if events do not (maybe it is already too late?) evolved beyond my ability to contribute. AuFCL (talk) 07:26, 29 September 2015 (UTC)
 * Regardless - your input and efforts are invaluable to me even when you/I/we have nothing to show for it at the end of the day; its still progress to me. -- George Orwell III (talk) 03:57, 27 September 2015 (UTC)
 * I shall leave it in for you to peruse but I think my "model D?P" might be an evolutionary dead-end and ought to be retired. A true example of there being more than one way to achieve an outcome. AuFCL (talk) 09:02, 30 September 2015 (UTC)
 * Thank you for continuing to "drop in" from time to time. I have uncovered a wealth of oddities in the real-world TOC of Index:Hakluytus Posthumus or Purchas His Pilgrimes Volume 12.djvu (progressive evolution: User:AuFCL/SandBox) and if I manage to eventually cover all the cases therein will consider this a worthwhile outcome. (You will have noticed I fell into the trap heavily of assuming &lt;noinclude&gt; and related tags could be sensibly be emitted by LUA code (big answer: no they can not!) and that led to a complete diversion regarding name space detection within LUA. Short answer: the wheels came off very badly yesterday but I believe some degree of wobbly stability has been re-established. Fun &amp; games. AuFCL (talk) 03:28, 16 October 2015 (UTC)
 * I have just "painted myself into a corner" and will need to reflect on how to best address this situation. When a new list element has been commenced; and an initial part of a cross-page construct encountered (e.g. CD.P/s) need somehow to suspend processing of any pending LI closure (except in demoSpace?) And symmetrically, may not build next LI until such point as first (non-ribbon! sheesh!) model line is found to be /c or /e form... Don't fuss if this makes no sense at present. Consider me to have lost the plot until further notice. AuFCL (talk) 22:04, 16 October 2015 (UTC)
 * Currently down to two rather intractable problems: neither of which will appear unfamiliar but are currently stumping me:
 * Dot leader on single-line "hanging indent": Silly I know, but automating the "obscure left leader overhang" &lt;span&gt; wipes out the initial text. I am sure we solved this one before...or perhaps that is why we gave up last time?
 * TOC item split across pages: when rejoined mediawiki encloses the first component in &lt;p&gt; tags but leaves the second component unenclosed. I have tried introducing explicit P tagging (opening one segment; closing the other) but the outcome does not change.
 * AuFCL (talk) 06:48, 17 October 2015 (UTC)
 * One down. The answer was hiding in the detail of dotted TOC page listing all along. I never learn. AuFCL (talk) 01:48, 22 October 2015 (UTC)
 * Re: problem #2 -- Are they cases where is being used? If so; that's your problem (uses a div based wrapper). I just edited 2 pages mentioned/copied-into in your sandbox where I think you were having that problem and -- with the use of straight P tags instead of the HI template -- now have the previously split portions rendering as one in the mainspace. Was I close? If not please point to an example with the issue. -- George Orwell III (talk) 23:03, 24 October 2015 (UTC)
 * Apologies for being misleading or obscure. To (try to) lay out my operating rules: to date I have absolutely not altered any Page: or main-space page and have kept all experimentation within User: or *-talk: space alone. At least until I receive any kind of feedback (hint²) otherwise I intend to stick to this. I had a bit of a mental crisis earlier and did your trick of "back to basics" and re-examined some of the subtleties of our old friend dotted TOC page listing and found one of the answers buried in there (particularly the trick of enclosing an absolutely-positioned div with white background to obscure the leader where it appears to the left of hanging text. Wonderful! Overdid the retrofit and then embarrassingly had to carefully pick apart the cases where it was helpful and actively detrimental again. You guessed it: outer-level divs ala (but not in point of detail) hi.  Problem #2 more or less disintegrated as a consequence of resolving the above; and I believe sprinkling a few judicious P-tags around has adequately stamped upon the remaining outstanding cases. AuFCL (talk) 01:31, 25 October 2015 (UTC)

"Problem #2" not quite dead yet
I am afraid there is a last gasp in this one. There is of course any "easy" solution to this (manually encapsulate the paragraph in P-tags) however I am concerned the automated approach gets pole-axed by the parser and I cannot see the reason why. I have tried to pare this down to a minimum to (I hope) demonstrates the issue. Any and all suggestions gratefully received! produces this incorrect output:

Manually inserting P tags thus: makes the problem go away and produces the expected output:

However, returning to the buggy earlier case, the LUA code "thinks" it is doing exactly that already! The first "half invocation" produces (according to the debugging console): "ought" to have output: and the second "half invocation", in a similar fashion: "ought" to have output: </li></ol> and as you can see below the simple concatenation of those outputs seamlessly produces the desired outcome: <ol style="list-style:none;margin:0; padding:0;"><li style="margin:0; padding:0;"> </li></ol> So I appeal to your judgment, which of us is the more brain-damaged, me or the mediawiki parser? OR a third option: is the expectation the end-user will have the intelligence to intervene with a manual edit on those rare occasions when it is called for a reasonable one? AuFCL (talk) 02:51, 25 October 2015 (UTC)
 * Whenever there is a question of who/what to blame- always blame the parser. See the slight deviation from your original "broke" example.

produces this nearly correct output:


 * iow... just moving the param entry so it is no longer "content" starting on "it's own line" (and thus no longer triggering auto P insertion), we are left instead with the issue of a missing "auto space" between the FORMER and LATTER pieces. That's not so much an issue if you consider some words are hyphenated across the page break and need to be "combined" in the final rendering anyway.

... note the space after Former, produces a seemingly correct output:


 * -- George Orwell III (talk) 03:36, 25 October 2015 (UTC)
 * Actually, the template syntax should be more like...


 * ... than what you had ( |'s at the 'end of the line') -- George Orwell III (talk) 03:43, 25 October 2015 (UTC)
 * I never cease to amaze myself how dopey I can be. Thank you. That is the best outcome that could be expected. I got completely hung up on the trailing pipe layout a while back (specific to this activity) and cannot even remember why I thought it preferable. I find it a little worrying the two cases are not parsed equivalently but can live with the compromise. AuFCL (talk) 04:21, 25 October 2015 (UTC)
 * I can empathize with that; can't count how many times I've been my own worst enemy too. Now maybe you can understand why I get particular if not anal about [over]using tabs and hidden text (>!-- <--) to make multiple params and/or statements, expressions, etc. all "seem" as though everything resides a single, run-on line in my template editing and such. -- George Orwell III (talk) 04:43, 25 October 2015 (UTC)
 * ...and here I was obsessing that the first time somebody actually critically reviews the LUA code I thought they would have a heart-attack because I took pains never to add a single unessential (well that was my aim anyway) space to the output HTML. Now that I find the parser is still second-guessing me I guess I'm wasting my time... (Never anal: careful. Or perhaps just bitten before. I like the Freudian slip (a technical Spoonerism perhaps?) (>!-- <--) as well.) AuFCL (talk) 05:04, 25 October 2015 (UTC)
 * And in fairness you did catch me out on a blatant porky regarding insertion of that implied space back in betwixt "FORMER" and "LATTER." Just goes to prove your eye is still true. AuFCL (talk) 04:28, 25 October 2015 (UTC)
 * It was just happenstance the example wasn't a single word hyphenated across the imagined page break this time. I'm pretty sure if this was a true transclusion to the main namespace, the extension would add/strip the spaces as needed. -- George Orwell III (talk) 04:43, 25 October 2015 (UTC)

A Little More Ambitious
This time based upon Provincial_Geographies_of_India/Volume_4 Input: —produces:

Self-sizing TOC
Credit to Londonjackbooks for prompting this diversion:

Based upon Page:Marlborough and other poems, Sorley, 1919.djvu/15 et al, this (note the  fragment): produces: See also Template talk:TOCstyle. LJB suggested some shortcuts (well I had wanted to do this earlier on but lacked the motivation to get started!) AuFCL (talk) 05:35, 10 November 2015 (UTC)

Page-crossing
This input:  should "fit" together something like this to form but a single table:

Putting the implied page breaks in should result in three stand-alone tables as might appear in the Page: name space (apologies for the tedium, as I am sure you've already got the point): resulting in:

AuFCL (talk) 21:07, 19 September 2015 (UTC)

Representative cases (existing template survey: may be severely pruned?)

 * Dotted TOC line (probably sub-case of dotted TOC page listing discussed above?)
 * TOC line
 * TOC page listing
 * TOC row 1-1-1
 * TOC row 1-1-1-1
 * TOC row 1-2
 * TOC row 1-c-1
 * TOC row 1-dot-1 (probably sub-case of dotted TOC page listing discussed above?)
 * TOC row 1-out-1
 * TOC row 1-r-1
 * TOC row 2-1
 * TOC row 2-1-1
 * TOC row 2dot-1 (probably sub-case of dotted TOC page listing discussed above?)
 * TOC row 2out-1
 * TOC row l
 * TOC row l-dot-1 (probably sub-case of dotted TOC page listing discussed above?)
 * TOC row r

Almost Philosophical: Category:Pages where template include size is exceeded
Do you have any concrete ideas regarding the heuristics (I shudder to state that there might actually be rules) of the above category? Feeling the moment might have arrived where I had better declare a degree of public loyalty to the TOCstyle entity I reworked the TOC of Index:Elements of the Differential and Integral Calculus - Granville - Revised.djvu (yeah yeah, nobody cares case) and promptly violated the so-called "limit". I have no issue with this except in the fact that there is no sense in fighting a marshmallow if there is no way of determining how far the «curséd» thing extends—thus this appeal. If there is no answer available then the effort in converting (well anything at all) to LUA is a complete waste effort. Is this another of those "feel your pain" moments? I might as well permanently adopt your chosen Phabricator logo. AuFCL (talk) 02:21, 29 October 2015 (UTC)
 * I must be missing something because I do not see any main, Index: or Page: namespace component of that title being listed in that category; nor does anything seem to appear in the category bar at the bottom of any of the work's "key" pages as well. Are we sure it was a passing hiccup or something? --- George Orwell III (talk) 02:30, 29 October 2015 (UTC)
 * (Shameful) problem-avoidance: Special:Permalink/5555663 AuFCL (talk) 02:35, 29 October 2015 (UTC)
 * Ah, I got it now. Unfortunately, the whole template "best practices" comes and goes with the passage time for me so I'll have to refresh myself there. For now, just keep in mind that the "Index:" page is a template itself (MediaWiki:Proofreadpage index template) to begin with rather than a "true" html form so there is already a design problem of sorts in place even before any values are added/selected to it manually. Plus this notion of placing a ToC in that field is something that became a "practice" well after the creation of Prp index template too; it was never really envisioned nor designed to be a container of another container in short. I never really understood why its so important to keep it around once validation is achieved and transclusion has taken place, personally. -- George Orwell III (talk) 04:26, 29 October 2015 (UTC)

A (new) round of questions

 * Whilst I am well aware of your earlier "directive" to the effect: The mobile question comes after all our desktop ducks are in a row. -- George Orwell III (talk) 02:41, 13 September 2015 (UTC), I really should point out explicitly I am entirely at your mercy regarding suggestions as to how to make this thing render remotely well under mobile mode. As things stand any attempt at either horizontal or vertical control appear to be a waste effort and frankly I have no clue as to why or what to do about it? AuFCL (talk) 02:49, 14 November 2015 (UTC)
 * Mobile view "strips" (or otherwise negates) most all of Desktop view's css settings for starters. For table & table elements, everything is designed to render "left" and strictly regulated from overflow-ish behavior (makes sense on a 320px smartphone screen) in particular. We will just have to work through all these pitfalls I suppose. Lets get the proof-of-concept out of the way first. -- George Orwell III (talk) 03:22, 14 November 2015 (UTC)


 * Probably also premature but the thought should be maintained that currently the ePub conversion process results in leaders which, well, simply don't lead. Either the conversion process or the primary concept is at fault. Either way this is a point upon which this attempt will be ultimately judged and possibly found wanting for aspects not under its purview? AuFCL (talk) 02:49, 14 November 2015 (UTC)
 * I'm guessing EPub is not "subject" to @screen (monitor) rules but to @page rules (print/paged media). If so, I believe we need to hold out for this specification to get implemented. I'll have to look into it further with my Adobe Acrobat Cloud thingy when I get some uninterrupted free time. Plus this "November Update" overhaul for Windows 10 looms large in my immediate future regardless (can't do much if I can't boot up in short). -- George Orwell III (talk) 03:22, 14 November 2015 (UTC)


 * I am being a bit cowardly on this front as I fear it may turn out to be a major can of worms. Nevertheless I'll note this point here in case anybody else wants to go for a wade in the mire. LST is going to be a problem. Some initial experiments seem to indicate the "constructed" div (by &lt;page&gt;) may even be inheriting the style list from the &lt;ol&gt; generated internally by —even style elements which make no sense at all in the translated context such as . Much more experimentation required. AuFCL (talk) 09:41, 5 December 2015 (UTC)
 * As the above note was overly cryptic I have made up a fairly simple demonstration of the issue here. As you (may be able to) see the, normally hidden, list structure is revealed as a result of the LST process stripping off the outermost
 * This is not the issue as that is precisely the result of choosing and positioning the sub-section tags; and in an ideal world simply replacing the missing structure would restore full function. However this is not to be because some process (&lt;pages&gt;? MediaWiki:PageNumbers.js?) has added a new structure
 * —wrapping the transcluded content. Obviously this is to convey page/index information and is essential in that function. However its presence makes restoring "seamless" results awkward. All I can think of at this moment are brute-force approaches to mine into and shore up bits of the DOM tree. (Note that &lt;pages&gt;-importing the entire page does not construct that P tag, for example.) Any thoughts? AuFCL (talk) 04:36, 7 December 2015 (UTC)
 * I note that you have maintained a dignified silence upon my last outburst; and upon further reflection I think the "problem" is in practical circumstance non-existent. It is probably not reasonable to expect an LST "slice" of any monolithic structure to magically work under arbitrary circumstances; per this reasoning the issue evaporates. Garbage-in; garbage out? AuFCL (talk) 01:23, 12 December 2015 (UTC)
 * I honestly forgot to re-visit this but after another half an hour of head scratching I'm a bit closer (I think). For starters, testing the pages tag in any namespace other the main has been suspect in the past so keep that in mind. Second, why would that content get marked off with section labels if as if it could be standalone content but not have a template setting of  to mirror that premise? I understand its all one big, multi-page spanning ToC so the continue designation would make sense but only if we're transcluding the entire ToC; not ToC sub-division by sub-division as "OF THE DOWNS" appears to be. -- George Orwell III (talk) 04:21, 12 December 2015 (UTC)
 * Apologies for wrapping you up in this particular issue—but at the very same time appreciate your involvement! It appears that you have quite simply cut to the same conclusion that I eventually did: that any section worth, umm, &lt;section&gt;ing is simultaneously worth declaring its own  sub-block—and thus the whole "issue" just goes away. The line of enquiry was triggered as a result of noting a conversation between potential users which never actually generated a request for me to change anything&hellip; so ultimately blame me for extrapolating from a bad premise! AuFCL (talk) 09:46, 12 December 2015 (UTC)

Why would you use fake tables
HTML already has table tags, why would you use faux tables? Sounds like reinventing the wheel. JustinCB (talk) 02:03, 19 January 2018 (UTC) JustinCB (talk) 02:03, 19 January 2018 (UTC)