User talk:AuFCL

Tables (again)
User:ShakespeareFan00/Sandbox/Short-titles is a pared down example to the simplest I could think of quickly.

Even though I am on the page telling the aligned table not to do the header or footer generation when transcluding, something's generating an additional table end marker, and thus the |} which I added to EXPLICITLY balance up the EXPLICITLY given opening {| at the start of the table, is being treated as text not markup. I was using this approach because of the multi-page nature of the table concerned, with a view to replacing a rather complex template I was using on a previous attempt elsewhere. I've also checked to see if some of my other templates were 'mismatching' tags (namely numbered/s,numbered/e,numbered div/s,numbered div/e.. ) and couldn't find a mismatch.

Before I go around in circles getting more and more frustrated, I'd like someone else to take a look at this, and provide a solution to the issue of multi-page tables once and for all, with a "satisfactory" solution that will be consistent, in all uses, irrespective of the underlying quirks of Mediawiki and extensions. (I'm getting the distinct impression that Mediawiki's table markup was not written with LST in mind.) ShakespeareFan00 (talk) 11:14, 15 August 2016 (UTC)


 * O.K. This is going to be harsh so brace yourself.


 * LST always encloses the section "ripped out" inside &lt;div&gt;&hellip;&lt;/div&gt; (the code is buried deep within the PHP portion of ProofreadPage) and there is nothing as a user or even administrator you can do about it except live with the consequences. One of those consequences is that if the parser "sees" an unclosed table it will close it on your behalf. Only thereafter does it encounter your  and of course by that stage it is too late&hellip;


 * In practice aligned table is such an outlier on the wikisource scene (as discussed elsewhere it is truly a product of the single-page-only wikipedia ethos and usage) I hesitate to mention it at all in any kind of policy or help page, so coming up with multipage rules of use is not going to be a rewarding exercise.


 * A side observation along the way: May I suggest adding  to the sequence on Page:Short Titles Act 1896(ukpga 18960014 en).pdf/2: —making it: —so that the table "rules" may coalesce into unbroken lines again? AuFCL (talk) 21:41, 15 August 2016 (UTC)


 * 1. So that would also explain why on other multi-page tables I've had to use page vs possibly. It's a shame there isn't a way to tell the parser to not wrap. (which would makes things so much easier.) ;( Why it works in a particualr instance where technically it shouldn't ((see the other Short Titles Act transclusion in mainspace is beyond me.


 * 2. That sounded very like a "you can't use this template for THAT" argument, which is understandable, but it's a shame no-one including developers seems to care about this. :(


 * 3. Noted and a fix applied.

ShakespeareFan00 (talk) 21:51, 15 August 2016 (UTC)


 * I'm not sure I understand your point 1. above.


 * As for 2. I am not trying to suggest you do not use anything you can get to work satisfactorily, as that proof is in the pudding. What I am saying is that some things are harder to justify when they subsequently break, and expecting a "developed-for-another-purpose-in-another-environment" solution like aligned table to remain forever stable here is a bit like presenting your delicate anatomy to the mad person wielding a hammer and daring them to do their very worst? AuFCL (talk) 22:03, 15 August 2016 (UTC)


 * On 2. Quite., On 1 I suggest reading what I said there, and looking over the recent edits related to the Index concerned. I think at present I am going to be unilateral and insert a note on the relevant Help page saying Mediawiki can't do multi-page

tables very well at present, at least then it will be explicitly clear that any solution is "experimental" shall we say. ShakespeareFan00 (talk) 22:09, 15 August 2016 (UTC)


 * I think I misread your intent on point 1. Perhaps what I should have asked was: Have you come across any cases which cannot be explained by the phantom-&lt;div&gt; insertion and consequent compromises argument? If so please point out the examples and I'll have a look—though as ever not confident a satisfactory outcome always possible. AuFCL (talk) 22:17, 15 August 2016 (UTC)
 * Thank you. That's probably the wording I should have used at the Scriptorum/Help thread.
 * I've also commented here - Help_talk:Page_breaks, in that we both know it's "semi-broken" but the help doesn't mention it.

ShakespeareFan00 (talk) 22:20, 15 August 2016 (UTC)


 * And further to this disscussion : Short_Titles_Act_1896/First_Schedule/Pre_Union shouldn't work, I'm not sure why it does.

On the subsequent sections ( It had to split because the number of template calls hit the limit in Mediawiki internally), such as Short_Titles_Act_1896/First_Schedule/6_Ann I've so far had to use a different approach (a rather brute-forced method) to get it to display consistently at all. It works, but barely. ShakespeareFan00 (talk) 22:24, 15 August 2016 (UTC)


 * Regarding First_Schedule/Pre_Union the best explanation I can come up with is "you can't be unlucky all the time!" The failure case arises when the page-end marker (automatically inserted, so you may not even be aware of it) happens to fall between table rows. In this particular instance it happens to lie just inside the final table cell on the page and thus works correctly. The only way I know to influence the positioning of this is to insert the Billinghurst-disputed nop at the end of page contents (certainly not present in this example.) I apologise this is but a poor explanation. AuFCL (talk) 22:45, 15 August 2016 (UTC)


 * Also there's a different issue here: Chronological Table and Index of the Statutes/Chronological Table/Edw1 namely some unexpected white-space at the lead. Someone else needs to throw the underlying templates in the bin and start the entire work again, manually entering each line of the table in full, as it seems that's going to be the only way of being really sure it will format properly, because having spent countless hours and days playing hunt "the whitespace in a template or transclusion, which the parser decides should be treated in three completely different ways depending on where its buried in a complex set of nested transclusions", I've had enough of trying to work around 'quirks'.


 * The entire Statute table template family is in my view unrepairable, to some extent un-maintanable and should be replaced with something a LOT cleaner (a LUA module perhaps) which is designed from the outset to take into account the 'quirks' which have been encountered during it's creation.


 * The same can probably be said for cl-act-paragraph and related which as it has been expanded has also become un-maintainable. I especially asked for short-title to be converted to LUA because it had get sufficiently complex I couldn't read it any-more, even though I had initially written it and some short-cut versions (sigh).


 * I appreciate that no-one gets paid for Wikisource efforts. Perhaps if they were things would get fixed.

ShakespeareFan00 (talk) 22:55, 15 August 2016 (UTC)

The Abominations
Much appreciated if you could use a suitable invocation regarding these.


 * statute table/header
 * statute table
 * statute table/footer
 * statute table/titles/entry
 * statute table/titles/header


 * Sn-paragraph
 * cl-act-paragraph
 * tf

As such they've become un-maintainable by normal users like me. Despite me having written them! These aren't the only ones, but they are the ones I could remember quickly. ShakespeareFan00 (talk) 23:06, 15 August 2016 (UTC)


 * And more hellspawn ....

ShakespeareFan00 (talk) 23:15, 15 August 2016 (UTC)
 * Statute table/chapter
 * Statute table/year
 * UKroadsign
 * UKroadsign/cy
 * Sn-note


 * Wow! If you are wondering why I haven't responded you have completely swamped me! I can only pick away at the side-issues and hope some useful conclusion presents itself.


 * To concentrate for the moment on your earlier issue: Chronological Table and Index of the Statutes/Chronological Table/Edw1; I can see what you want to achieve but I fear you might be being rather more ambitious than mediawiki will assist you in attaining.At a fundamental level I think you are up against the triple syntactic meanings of "|" as you have used it:
 * as wiki-table, row and cell delimiters;
 * as template parameter delimiters; and
 * as parser function delimiters.
 * To reduce the opportunity for confusion (and I am not at all sure this will solve your problems; though it can only help!) I would recommend converting all table constructs into &lt;table&gt;, &gt;tr&gt; and &lt;td&gt; equivalent form. This should free up the various   usage to further reduce the opportunity for confusion. It is even possible (though admittedly unlikely) that this might enable you to relax the current   usage and once more permit   use—that is if that introduced &lt;div&gt; doesn't re-scupper the vessel!
 * Believe it or not this whole exercise is simply to address the extra  at the top of the page. I hope the outcome might make it worth the effort, though.
 * And before I forget: in Statute table/header the CSS on this construct does nothing (past the essential opening of a new table row) in most browsers: —the   is the default anyway, and (as far as I am aware) rows ignore any kind of   directives completely. AuFCL (talk) 04:58, 16 August 2016 (UTC)


 * If you check the history of statute table/titles/entry I HAD tried converting it (and the pages using it over to using HTML markup, at which point the long standing issue with the non-appearance of page numbers in transclusion re-asserted itself. As I said, someone else, who has the time needs to re-do the entire work with a set of templates that have been written to take account of the quirks, rather than both of us trying to fix a template which is broken by them.

For reference :-
 * https://en.wikisource.org/w/index.php?title=Template:Statute_table/titles/entry&oldid=6389889
 * https://en.wikisource.org/w/index.php?title=Template:Statute_table/titles/header&oldid=6389888
 * https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/6_Ann&oldid=6389887
 * https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/Geo1&oldid=6390036

where I had tried to use the approach you had suggested. I at present don't consider any solution would be entirely satisfactory until the underlying low level issue inside the parser is sorted out once and for all. ShakespeareFan00 (talk) 09:03, 16 August 2016 (UTC)


 * Attempted here - Displays start of tables page number, but ONLY that one. (using page

https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/6_Ann&oldid=6392328


 * Attempted here - using https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/6_Ann&oldid=6392341 - The page numbers will display (and link), but only if they are NOT displayed within the text, suggesting a lower level issue with how the page-numbers are inserted. As I've tried MANY approaches to resolve this, I am of the view that this is an issue outside the control of normal users. What a shame no-one else seems to care about fixing the real problem which based on the above would seem to be buried within the code for generating the page numberings to the side. This means that to get the page numbers consistently with a table crossing a page boundary, you can't use HTML markup, or LST via at present. What a shame mediawiki is weak in this area. :( ShakespeareFan00 (talk) 09:25, 16 August 2016 (UTC)


 * Regarding Short_Titles_Act_1896/First_Schedule/6_Ann, I shall not claim this is not an act of utter bastardy but try:
 * To explain: by direct transcluding all three pages I sidestep any &lt;pages&gt;-&lt;div&gt; insertion issues but (obviously at the cost of no page number information. That was step 1.
 * Step 2 is the &lt;span&gt;&lt;span class="pagenum" &c. guff. That force-inserts the page numbers in a form acceptable to mediawiki:PageNumbers.js. So far so good, and works for page 16.
 * Step 3 is to further enclose the page-meta-info inside &lt;tr&gt;&lt;td&gt; to make them compatible with the ongoing statute table/titles/header structure. PageNumber likes this but there are now 1px "holes" in the vertical rules due to a table element we don't want to see.
 * Step 4 is to make the dummy &lt;td&gt;s style position:absolute which effectively hides them. Can't use display:none as inheritance hides the page number displays and defeats the effort.
 * So here is an abomination-squared which works. I have no idea how to justify it though! Call it research in progress? AuFCL (talk) 08:53, 17 August 2016 (UTC)
 * Be careful, abominations have a habit of doing nasty things on invocation! ;) . I may revert my efforts given that the version using normal table syntax and page sort of worked. But at present I am not exactly a practioner of the dark arts of mediawiki. ShakespeareFan00 (talk) 08:59, 17 August 2016 (UTC)
 * Well just to tempt you further toward the dark side, it would be fairly easy to split off a derivative template of page which (tentatively) incorporated the enhanced structure. I have not (yet) tested it but by reverse logic I expect it would work for ordinary pages (and damn it all tables are extended backward in a parse to enclose the first row reference. Bloody parser! There goes the neat works-everywhere solution!) as well as those containing tables&hellip; and could well have the side-effect of eliminating any requirement for nop outside of its traditional to-protect-new-lines function&hellip; Sort of introduce it by stealth and hold off explaining until somebody actually asks intelligent questions&hellip;? Could take years! Got-your-soul-stuff? AuFCL (talk) 10:00, 17 August 2016 (UTC)
 * I would strongly suggested a lead pentagram lined sandbox to trial it first! Such are the ways a Wikisourcerer ? ShakespeareFan00 (talk) 13:09, 17 August 2016 (UTC)
 * Well as I said using normal table syntax and page albiet with num- params all over the place sort of worked, not sure why though. ShakespeareFan00 (talk) 13:10, 17 August 2016 (UTC)


 * Your last remark cannot be referring to the current state, as that is achieved through use of &lt;pages&gt;—no explicit num parameters at all.
 * In any case both the above and this edit (even allowing for the typo!) work both better and worse than you imagine: all three page (er. two—three after said typo is addressed) number links are technically present although a bit of protective code in PageNumbers.js hides pages 17 and 18 due to an inability to decode the vertical area occupied by page 16 (hover your mouse pointer over the page-number-link to see what I am talking about—only a single line is highlighted; whereas the grey area ought to extend down to "7 Anne, c. 12."—as it does with my dirty hack in place.)
 * In any case this is all a learning exercise and if you are happy with the status quo I shall not further rock this boat. AuFCL (talk) 22:16, 17 August 2016 (UTC)
 * Well if that's still a gltich that you managed to solve, invoke away until you have tamed the abomination. You are a better contributor than I. table-x ? ShakespeareFan00 (talk) 22:29, 17 August 2016 (UTC)
 * I'm at the moment going to walk away from this. If you solve it for good let me know. ShakespeareFan00 (talk) 22:30, 17 August 2016 (UTC)
 * Well what do you think of this? Will it fly? Any obvious (or otherwise) simplifications? It is a shame one needs to be conscious of whether the page is to be included as being of table-nature table-page or normal page; and of course /  ranges are impractical but nevertheless.
 * Even my inadvertent lapse is illustrative. Note the hover-highlighting of page 16 is different in the two versions: using page back-extends the highlight region to the start of the end-result-page; whereas use of table-page (where practicable to so use) supports highlight of the actual transcluded content, excluding the direct-specified table header contribution from (in this case) statute table/titles/header. AuFCL (talk) 00:01, 18 August 2016 (UTC)
 * Looking longer-term the changes to make &lt;pages&gt; accept a new parameter  which if present suppressed the &lt;div&gt; wrapping and inserted page back-links per above proposal are pretty straightforward—the major difficulty not being technical in nature; but rather requiring I would need at the very least Tpt on board to get it through the implementation process.
 * And as for intelligent detection of—and reaction to—content: forget it; one would still have to &lt;page&gt;-include tabular and textual content in distinct blocks.
 * In other words: dream on. Are you any good at pulling strings? AuFCL (talk) 00:25, 18 August 2016 (UTC)


 * Looks good so far. Have you tested it with sections yet? I used these extensively later on? ShakespeareFan00 (talk) 07:40, 18 August 2016 (UTC)


 * No I have not—though written everything so as sections should not be an issue. I wanted a little feedback before going too far per spin-off at WS:S I suspect most feedback will be along the lines of "Why would anybody want to do that?" so please be warned.
 * Please try the new template out and let me know if it causes grief. It is a fairly simple clone of what I envisage page ought to be—arrogant or what?—but as it is protected from editing I cannot do anything about it. AuFCL (talk) 08:27, 18 August 2016 (UTC)

Side issue in page table-page
From my limited understanding at present page and page can only pull out a single section. They can't necessarily pull multiple sections. Is my understanding correct? Just means more lines in the transclusion page but would probably need to be documented. ( Not sure without converting to LUA code you would implement a page with fromsection= and tosection=) Not a concern with pages I've written, but in some future instances it may become so. I've noted your discussion elsewhere. ShakespeareFan00 (talk) 09:49, 18 August 2016 (UTC)
 * You are quite correct about single-sections-at-a-time for now. I have deliberately linked table-page's documentation to the documentation for page for now; mainly because it is a poor long-term solution which merely demonstrates a possibility—and thus there is no point in overly encouraging its use except in case of dire necessity.
 * I also quite deliberately over-specified the proposed upgrade to &lt;pages&gt; at Scriptorium as that is the superior solution (and handles multiple-ranges and multiple section inclusion to boot.) A sensible tame administrator could do a lot if suitably educated and motivated—and if the go-ahead is granted.
 * You should be warned that really table-page is only really required for instances where a "slice" of a table is to be extracted for transclusion. If (for instance) a complete table including header-body-and-footer is selected by a section then you might as well use &lt;pages&gt; as normal current practice anyway. (Aside: you may remember &lt;pages&gt; explicitly will not work inside the Index: name space, so if you are building a contents page for use there you are stuck with page anyway.) AuFCL (talk) 11:25, 18 August 2016 (UTC)

The Tablecrux (as I understand it)
At present :

Will in my experience actually transclude from the parsers perspective depending on the circumstances as

An "implied" line feed being ignored. Which means the table row end/start gets ignored. Naturally when using HTML table synatx directly this parser quirk doesn't occur because the browser at best will see a   pair in a non-pretty way.

The immediately before the |- at the start of page with the rest of a table is seemingly needed so that the parser thinks it's seeing the start of a new line, (as opposed to the continuation of a line or the end of a table entry/row from a previous page.

This is why the is overloaded. A hack solution would be to amend the Proofread page extension to make an explicit check for a |- sequence at the immediate start of a page/section once the header noinclude has been stripped. Idealy a check could also be made for a trailing |- sequence just before a footer noinclude, It's not ideal because of some other use cases that may arise.

As you are already looking into implementing a page number fix and some other options, it would be a recomendation that you also come up with some kind of invocation that shall free the from unclean usage, that will banish the Tablecrux and bar it from returning in the future! Do this and great Sourcer of the wiki shall ye be!last part is tounge in check, but as we were in that theme. ShakespeareFan00 (talk) 13:31, 18 August 2016 (UTC)
 * Side note, when trying to get cl-act-pragraph working I had the reverse issue, in that some transclusion methods and template parsing was adding or removing "implied" line/paragraph breaks due to quirks. ShakespeareFan00 (talk) 13:31, 18 August 2016 (UTC)

Please pardon me if I am over-simplifying. Your example as stated:

simply works under transclusion of both page and &lt;pages&gt; ilk. The reason why is that all of the table header, body and footer are present in the final result. Also because the page split fortuitously occurs at the end of a table cell the automatic process of inserting page number information enclosed within a &lt;span&gt; happens to be compatible. In this case page number links probably work.

Now please consider this subtle change: Looks very similar, transclusion works but page number links do not. Why?

Well where does the page-info-span go? Yes it is now nestled in after the table row start mark that  becomes. In other words the HTML generated looks like: and that just is not legal in HTML. The parser is still processing when it hits this and (guess what?) the span and all its content are either expunged or moved outside of the table altogether.

In point of detail it matters not which fate it incurs as the whole point of this span is to mark where it is in the HTML stream. PageNumbers.js then uses this location to generate the actual page links which means it cannot be moved or removed. Either choice results in a train-wreck.

My "solution" as implemented in table-page is to further enclose the span: which I won't pretend is not ugly! However it is a kind of parser-viral matter which is sufficiently innocuous to the process that it is left in place without visual effect. PageNumbers.js finds its magic span and is happy so page numbers work again.

Now the situation as it occurs in, say, Chronological Table and Index of the Statutes/Chronological Table/Edw1 is yet one more step removed beyond the above. What you really want to do is to generate almost an SQL-like extraction of multiple named sections from multiple pages. As you know &lt;pages&gt; can do this for you. The problem now is that the output of &lt;pages&gt; becomes effectively:
 * 1||2

.... no headers! But you solved that in main space by adding an enclosing statute table/header and statute table/footer. Well didn't you? The result being logically: But wait! The &lt;div&gt; is now inside table headers and that is not allowed. So the parser removes them and the result sort-of works again with all the issues of page-break placement discussed above.
 * 3||4
 * 3||4

In other words every level of complication adds to the problems wrapped up in layers below. Sometimes you are lucky. Sometimes not. The whole situation is an exercise in gambling and nobody fully knows the rules of the game.

I am no sorcerer, just a ticked-off apprentice with a magical broom and (so far) no authoritative oversight. Lets just see how far this ride takes me? AuFCL (talk) 21:56, 18 August 2016 (UTC)
 * Hmm, so this to me still doesn't really explain why the is needed, when technicalyl it shouldn't, based on the above explanation. hmm.


 * And with the short titles I was getting precisely the situation I was seeing in my first example namely a |- in the wrong place, meaning 2 table rows were getting pushed together. :(. Willing to write some insanely arcane test cases to prove the exact interaction between table syntax and LST? If not no worries. ShakespeareFan00 (talk) 23:44, 18 August 2016 (UTC)


 * (Sigh! This is aimed at myself, not you!) At the risk of confusing you further, about an hour after I put the above together I realised I had reversed reality. Nothing wrong with the concepts but I had analysed the examples as if the page-number-marker block trailed after the page content, when in fact it leads the content. This still means there is a 50:50 chance of things going wrong; just in precisely the opposite order. So please let me try again, and I will attempt to address some of your other questions along the way:


 * Lets imagine you want to transclude table content using &lt;pages&gt; to be sandwiched within user-specified table open and closure bookends:

—this in reality is theoretically a failure case. At an intermediate stage the parser is looking at: —which is not legal HTML (the &lt;div&gt; should not be there. neither are the spans syntactically permitted.) Fortunately the parser happens to throw the div away—which is good. However not so good, it moves (current parser quirk: please don't rely on this behaviour!) the spans treewise up to the previous outer table or div. This is bad because all the inter-table pages then appear to lie on top of one another at the start of the table. PageNumbers.js then compounds the error by hiding all the overlaid pages past the first one. So the net result is a correct table display with but a single usable page number link to the first page (worse yet: if the user-specified table header is of non-zero length, the page is interpreted as including the header which precedes the transclusion proper. This is the effect I was trying to demonstrate earlier with the difference between the hover effects on page 16 in special:permalink/6395312 and special:permalink/6392328. AuFCL (talk) 05:00, 19 August 2016 (UTC)

Another fix that works
The fix being this: https://en.wikisource.org/w/index.php?title=Template:Statute_table/year&oldid=6398603

But I am not sure why even with your previous explanations, that the two nops should be needed here. It seems that someone should generates some diabolically pervese and pathalogical test cases because I think this is a quirk in the parser that should be fixed. You should NOT need to have to put in nop 's when using normal table syntax. ShakespeareFan00 (talk) 12:01, 20 August 2016 (UTC)


 * I really don't understand what you are doing here. Can you possibly supply an example which fails without the nops because they do not appear necessary at all in any of the cases I have examined to date using Statute_table/year. I can only assume you introduced them (and all the usage) as a result of an undesirable interaction with another template—otherwise you are simply introducing complication for complication's sake and might well be battling phantoms of your own creation? AuFCL (talk) 22:01, 20 August 2016 (UTC)
 * What i was having problems with was unexpected white space on Page:Chronological Table and Index of the Statutes.djvu/33, with the nops the unexpected whitespace went away, if you think they aren't need you are welcome to remove them and test, but as I said, I'd like to hand over this set of efforts to someone to do the full assembly of it.

ShakespeareFan00 (talk) 15:02, 21 August 2016 (UTC)

A thought
Part of the complexity with statute table arises because of handling table rowspans. It would be nice if the parser could cope with these in a cleaner way.

Would implementing an extension to table syntax as such be useful?


 * |~ Extension and merge of next cell horizontally to this column of the table. (effective colspan), The parser seeing this would do generate the rowspan part internally.
 * |^ Extension and merge of next cell verticaly to this cell (effective rowspan)

A very much simplified example would be.

Currently you need to do:-

With the syntax extensions you would have instead... Which means that each 'cell' is nominally defined ( which would make some templates less complex.), This is a long-term idea, I'm not expecting anything to happen soon. ShakespeareFan00 (talk) 12:50, 20 August 2016 (UTC)


 * I expect I am the wrong audience for this. I am a little concerned already about the ambiguities of  and your proposed syntax might face similar problems. How would you recreate, for example:


 * reproduced more for being "pretty" than for a challenge. Which is maybe why I feel this sort of syntactic change might be resisted in the current push for a visual editing approach. AuFCL (talk) 21:55, 20 August 2016 (UTC)
 * What would you suggest was a "cleaner" syntax? ShakespeareFan00 (talk) 00:00, 21 August 2016 (UTC)

BTW. That said I'm not sure they way the parser constructs tables would allow for the |^ anyway. ShakespeareFan00 (talk) 00:00, 21 August 2016 (UTC)
 * Your notation makes no apparent allowance for spans more than two—unless you envisage multiple modifiers to indicate higher span values? In the most general case one starts to come around to the current notation  or indeed   as prosaic no doubt that is. AuFCL (talk) 04:24, 21 August 2016 (UTC)

Re html5 and &lt;tt>
Do I read correctly that with html5 that we should not be using &lt;tt> and should instead use &lt;kbd>? — billinghurst  sDrewth  00:06, 18 August 2016 (UTC)


 * I admit I have never looked that closely into the matter but according to your premise is basically correct in pure HTML5 terms. Don't forget mediawiki enforces a layer of intervention so the same may not necessarily be true at least for the immediate future in the wikisource environment (what I am trying to say is you need some feedback from the WMF developers as well. I do not know.)  AuFCL (talk) 00:25, 18 August 2016 (UTC)
 * Upon further reflection, wouldn't the "wiki"-way be to use ? AuFCL (talk) 06:07, 18 August 2016 (UTC)
 * I will interpret this as rather say and do nothing, and leave it in our editlist markup, we prod WMF for their guidance, and look to set ourselves front-facing. Thanks for your thoughts. — billinghurst  sDrewth  07:18, 18 August 2016 (UTC)

Parser quirks..
Page:United Nations Treaties and international agreements registered - Volume 221 (13 November 1955 - 30 November 1955).pdf/380

Take an example :

1. Outside the template

Mr. James S. Killen Counsellor for Economic Affairs Embassy of the USA Beograd

Mr. James S. Killen

Counsellor for Economic Affairs

Embassy of the USA

Beograd

Inside tf

But when done slightly differently:

Consistent behaviour would be nice. :) ShakespeareFan00 (talk) 19:59, 20 August 2016 (UTC)
 * In the first example it generates a block right in the middle, which breaks the intended layout XD.

I doubt this will get fixed any time soon (as changing what exactly equals terminating white-space would potentially break so many other bits of Mediawiki...)

ShakespeareFan00 (talk) 20:05, 20 August 2016 (UTC)


 * Welcome to the wonderful world of compromise mediawiki really is! I suspect all along what you really wanted to do was this:

Mr. James S. Killen

Counsellor for Economic Affairs

Embassy of the USA

Beograd

which produces:

Mr. James S. Killen

Counsellor for Economic Affairs

Embassy of the USA

Beograd


 * HTML-like tags appearing in wikitext are not always passed through literally. Hard as it is to grasp &lt;div&gt; is one of these cases, and for best fidelity needs to appear on a line alone. My unqualified suspicion is that the parser needs to "see" a new line before properly closing off prior paragraphs—with the result at some stage it has to grapple with a div-inside-a-paragraph which is not permitted by the rules of HTML and what you are observing is the results of trying to recover from that basic mistake.
 * Incidentally don't think my approach above is bullet-proof either. Simply enclosing the whole thing in a table cell reintroduces the problem all over again.
 * My only suggestion is to try to keep things to the simplest case which works. Ironically with your example this is the first ("outside the template") case. In other words in this particular instance tf is doing noting useful. This is not a criticism of the template in other circumstances. AuFCL (talk) 21:41, 20 August 2016 (UTC)

Render quirks (Part 1)
Page:Cowie's Printer's pocket-book and manual.djvu/66

I'd been attempting to get a table which looked like the page on screen.

I've got the table; but setting up a transform so it displayed consistently, in both the Page: view and the edit preview, seemed to beyond Mediawiki to cope with. It rendered differently in both views.

ShakespeareFan00 (talk) 11:51, 21 August 2016 (UTC)


 * Once more I don't really understand. This version seemed pretty close so what went wrong? (If you were happy using rotate for the individual cells then why not use it again to get the overall orientation desired. I confess transform matrices make my head spin so I consider use of that was a bit "courageous." AuFCL (talk) 04:09, 22 August 2016 (UTC)
 * Tried that, Still couldn't get it to render. Parser quirks on how it reads table synatx. What a shame to do anything complicated, you have to write non-portable HTML code directly :( ShakespeareFan00 (talk) 10:21, 22 August 2016 (UTC)


 * A very very simple table, It won't rotate, because rotate appears to use a span, which per previous disscussion can't have a block level tag like a table within it.

What the parser gennerated as HTML was, 

That's why I was using a hard coded div, which wouldn't display consistently. It would of course be "helpful" if mediawiki was at least consistent about it's handling of hard-coded div's, an issue which I'm going to add to the long list of "known concerns, nobody is interested in actually doing anything about because they don't care about actual contributors." ShakespeareFan00 (talk) 10:31, 22 August 2016 (UTC)
 * Because of another parser quirk - {| has to be on a new line, which causes the generation of a spurious (and unblanced   pair (as seen above), that as you can see (again above) isn't nice HTML. In the above example the parser would seem to have a quirk no-one wants to fix.


 * Presumably there must be a way to code the DIV wrapped around the table to be coded in such a way that it WILL format consistently (in all views), but at present owing to all the quirks of Mediawiki, it eludes me.

ShakespeareFan00 (talk) 10:39, 22 August 2016 (UTC)


 * And after a LOT of looking at documentation elsewhere - Page:Cowie's Printer's pocket-book and manual.djvu/66.

I'm still not entirely happy, for reasons to do with possible "registration"(printing term) issues if the table layout here is used as the direct basis for doing a print layout, but it's getting there. Any chance of being able to wrap the code there into some kind of script so I don't have to spend hours typing table code? ShakespeareFan00 (talk) 15:17, 22 August 2016 (UTC)


 * And when I akssed some Mozilla people they came up with :- [], which worked better.

Gven it's complexity some kind of template or LUA implementation would be advisable in my view. ShakespeareFan00 (talk) 19:49, 22 August 2016 (UTC)


 * What I was suggesting before was ; i.e.:

{{rotate|90|ele=div| }}

{{rotate|90|ele=div| {| {{!}}{{!}} {{!}}} }}


 * There has been some discussion in the past about the unsuitableness of due to it not being (if I recall correctly) compatible with Internet Explorer. As history has moved on since then&hellip; AuFCL (talk) 21:05, 22 August 2016 (UTC)

layout improvement
Hello AuFCL. Can you have a look at Page:Sir Martyn (1777).djvu/20 (picked somewhat at random) – how would you improve its layout/presentation? (If you can do it in one, I can then copy the same format and apply it to the rest.) A larger problem: notice the space between the stanzas? Why does it not appear in transclusion? Thanks in advance for your help. ~ DanielTom (talk) 23:06, 30 August 2016 (UTC)
 * Never mind, I think I got it. Just another minor question about (you guessed it) braces (again). How to make the one here work (Ctrl+F "Stownd") ? Thanks ~ DanielTom (talk) 23:55, 30 August 2016 (UTC)
 * Please pardon my tardy response. Yesterday instead of presenting "Sir Martyn", mediawiki was having a snit and giving me the "all our servers are kaput" error on that page so I left to today. I rearranged the brace problem as side-by-side floating divisions (effectively columns: I hope that is the effect you wanted?) The clear at the end simply indicates the end of the stacking operation, and the return to normal text flow. The whole thing could also have been organised as an embedded table if you prefer. AuFCL (talk) 22:32, 31 August 2016 (UTC)
 * No problem at all. Hmm, I had to zoom out to see if it works... And it does. Thanks for always being so helpful. ~ DanielTom (talk) 23:07, 31 August 2016 (UTC)

Something is wrong with image container.
Hi,

You knew that it was inevitable that I drop in on you. I am having a problem with the container of the picture ON THIS PAGE and can't figure out what it is. Could you please take a look at it whenever. There is no rush. Thanks. — Ineuw talk 06:48, 6 September 2016 (UTC)

Share your experience and feedback as a Wikimedian in this global survey
Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future. The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. To say thank you for your time, we are giving away 20 Wikimedia T-shirts to randomly selected people who take the survey. The survey is available in various languages and will take between 20 and 40 minutes.

Take the survey now!

You can find more information about this project. This survey is hosted by a third-party service and governed by this privacy statement. Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email to surveys@wikimedia.org.

Thank you! --EGalvez (WMF) (talk) 22:25, 13 January 2017 (UTC)

Aligned table of Statutes (and how to support "ribbon" headers?)
The page: Page:A_Collection_of_Statutes_Relating_to_India_(Second_Edition)_Vol_1.djvu/17

The Template/Module concerned.: Aligned table

I was using aligned table for this as it's a static format that continues over a number of pages, and calling ts for every row, cell etc seems to be overkill. Possibly this is instance of it needing a specific CSS class applied to the relevant tables, but I am not that familiar with how to request new ones for use on English Wikisource.

However, I've I am reasonably confident that the English Wikisource version of the template could be udpated in a specfic way. Currently the template concerned is not necessarily page/LST aware, leading to the approach I have on the page linked, which I consider to be a temporary soloution even if it appears to work.

I was thinking given that you were able to implement  |starting=yes   |continuing=yes   |ending=yes  and  |rowXpageribbon=yes  functionality in TOCStyle whether you in a spare moment would be interested in producing a forked version of aligned table, which also had this functionality.

Being able to do a starting/continuing/ending/pageribbons aligned table more cleanly would be appreciated, as it would no longer need to worry about precisely where to put in certain arcane syntax.

I am suggesting the  |rowXpageribbon=yes  for things like the column headings row, in the example above which need to be on pages, but don't necessarily need to be in mainspace, as that's what you used in TOCstyle. ShakespeareFan00 (talk) 12:52, 28 February 2017 (UTC)

Template:Table-page
This has remained unused for a while, so I've started a disscussion at WS:PD.

The attempted usage of it didn't it seems work out. ShakespeareFan00 (talk) 18:46, 1 March 2017 (UTC)

Apologies, I had a "meltdown" on wiki :(ShakespeareFan00 (talk) 22:38, 1 March 2017 (UTC)