On Tue, Aug 11, 2015 at 7:12 PM, Gabriel Wicke gwicke@wikimedia.org wrote:
TL;DR: Join us to discuss Templates, Page Components & editing on Thu, 13 August, 12:45 – 14:00 PDT [0].
I can't, so I'll just comment here.
including a talk by C.Scott at Wikimania [4]
Looking at the slide deck, it's not terribly clear to me what's going on through much of it. If you're only referring to the "alternatives to templates" section (slides 39-50) it's good, but much of the rest isn't so much.
The first part repeatedly harps on T14974 being stupid. Which I don't think anyone disagrees with, but hysterical raisins mean it's not simple to just revert anymore. We need to at least identify what now is depending on that behavior (xkcd 1172 https://xkcd.com/1172/).
Then complains about the fact thatthere isn't any general-purpose "escape template argument" mechanism. True, although overdone in the slide deck.
And then gets into weird attempted abuse of some {{echo}} template in the context of tables. WAT?
Then it goes back to the escaping issue by proposing a heredoc syntax for template arguments. Although that as a general concept has its advantages, it also has disadvantages. Enwiki even has some templates like this, see {{archive top}}/{{archive bottom}} for just one example.
And then it non-sequiturs into a screenshot of JavaScript code. WAT? Maybe it's trying to propose a version of Scribunto-with-JS over Scribunto-with-Lua, ignoring the reasons JS was rejected in favor of Lua during Scribunto's planning and development.
Then it proposes looping and StringFunctions-like parserfunctions that were rejected years ago to avoid wikitext becoming even more confusing. WAT?
And JSON blobs embedded in page wikitext are presented as a good idea. WAT?
Also, slides 60-62 seem wrong. The first was probably trying to get at the fact that {{#tag:ref|bar<ref>bat</ref>}} puts the "bat" reference before "bar" instead of after, but it misses and the next few go off in some completely other direction.
- Can we find satisfactory general abstractions for page components
(well-formed content blocks)?
"Page components" with structure defined by editors and layout controlled by the skin would let Mobile get rid of a some of the stupid stuff it does now to try to work around the existing implementations.
But what do you mean by "general"?
- A page component for infoboxes, and one for navboxes, and so on? Sure. - A generic "page component" thing that can be used for infoboxes, navboxes, and so on? Probably not well, although I'd be happy to be proven wrong. You'd probably wind up with effectively templates + per-template styling + someone actually writing good @media blocks for mobile vs desktop.
- What are the requirements for editing, RL module / metadata
aggregation, dependency tracking?
I don't think anyone will forget it, but keeping the links tables (dependency tracking) up to date is important. Flow did forget, for a historical example, and the current implementation still leaves a bit to be desired. Flow's watchlist and history mechanisms (e.g. https://www.mediawiki.org/w/index.php?title=Talk:Web_APIs_hub&action=his... and how it shows on my watchlist) are rather lacking, too.
When discussing editing: A good WYSIWYG experience is essential, but a fully-featured markup editor (that ideally doesn't require directly writing JSON blobs or complex RDF structures) would also be very useful for many editors.
- Should we evolve wikitext templates into well-formed page components?
Probably not. While templates are used to implement "well-formed page components" as it seems to be defined here, they're also used for many other things.