On Tue, Aug 11, 2015 at 7:12 PM, Gabriel Wicke <gwicke(a)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=hi…
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.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation