*(Not to be confused with hygenic template arguments https://phabricator.wikimedia.org/T114432.)*
As described in my Wikimania 2015 talk https://wikimania2015.wikimedia.org/wiki/Submissions/Templates_are_dead!_Long_live_templates! (starting at slide 27 https://wikimania2015.wikimedia.org/w/index.php?title=File:Templates_are_dead!_Long_live_templates!.pdf&page=27), there are a number of reasons to mark certain templates as "hygienic". Among them: to allow high-performance incremental update of page contents after templates are modified, and to allow safe editing of template uses using HTML-based tools such as Visual Editor or jsapi https://doc.wikimedia.org/Parsoid/master/#!/guide/jsapi.
This means that the output of the template is a complete DocumentFragment https://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment: every open tag is closed and there are no nodes which the HTML adoption agency algorithm http://dev.w3.org/html5/spec-LC/tree-construction.html#adoptionAgency will reorder.
This can be enforced in practice by running tidy (or something like it: T89331 https://phabricator.wikimedia.org/T89331) on the template output before it is inserted into the document. We are likely to be doing something like this already for T114072 https://phabricator.wikimedia.org/T114072.
The purpose of this RFC is to settle the bikeshed-color questions about how templates will be marked hygienic/unhygienic. There are two main scenarios:
***Opt-in Hygiene***
In this scenario, unmarked templates are assumed "dirty", and will render correctly (as before), just more slowly. Some of the unmarked templates (the "actually dirty" ones) may be uneditable in VisualEditor.
In the opt-in scenario, it is expected that profiling the "costliest"/"most frequently used/changed" templates on wikimedia projects will be done, and opt-in tags will be added first to those templates where the greatest potential performance gain may be achieved. (Opting in will enable incremental update of the parser cache after template modifications.)
Proposals:
1. An explicit tag surrounding "hygienic" contents; this tag will exactly encapsulate the content which will be run through tidy. Proposed names: 1. `<tidy>...</tidy>` 2. `<domscope>...</domscope>` 3. `<domparse>...</domparse>` 2. A magic word, present in templates known to be hygienic. Proposed names: 1. `__SAFE__` 2. `__HYGIENIC__` 3. Some `TemplateData https://www.mediawiki.org/wiki/Extension:TemplateData` property? 4. Others?
***Opt-out Hygiene***
In this scenario, all templates are assumed "hygienic", and an explicit marker of some kind is required to opt-out of the usual tidy of the contents. Templates which opt-out are not editable in Visual Editor, but all other templates are (because the contents will have been automatically cleaned to close any stray open tags).
In the opt-out scenario, it is expected that Parsoid (or other tools) will be run against the wikimedia projects to automatically add opt-out tags where possible; perhaps based on logging during the parse process.
Proposals:
1. Magic word, present in unhygienic templates 1. `__UNSAFE__` 2. Others?
Phabricator task for this RFC: https://phabricator.wikimedia.org/T114445 --scott
On Thu, Oct 1, 2015 at 6:43 PM, C. Scott Ananian cananian@wikimedia.org wrote:
Phabricator task for this RFC: https://phabricator.wikimedia.org/T114445
FYI, hiding this at the end of the email tends to encourage email replies rather than replies in Phab.
On Fri, Oct 2, 2015 at 10:50 AM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Thu, Oct 1, 2015 at 6:43 PM, C. Scott Ananian cananian@wikimedia.org wrote:
Phabricator task for this RFC: https://phabricator.wikimedia.org/T114445
FYI, hiding this at the end of the email tends to encourage email replies rather than replies in Phab.
That was intentional; the wording in https://www.mediawiki.org/wiki/Requests_for_comment/Process suggested that email conversation should be pursued orthogonally to discussion on the Phab ticket. The phab task links to the email discussion archives, so nothing's going to be lost.
If you're in the habit of using phab for discussion, you didn't need to see this email: phab would have notified you as soon as I created the task in the RFC project. The mailing list thread is for people who would prefer to discuss (or ask questions) outside phab.
Please correct me if I'm wrong; I'm just trying to follow the process outlined in the wiki. --scott
That was intentional; the wording in https://www.mediawiki.org/wiki/Requests_for_comment/Process suggested that email conversation should be pursued orthogonally to discussion on the Phab ticket. The phab task links to the email discussion archives, so nothing's going to be lost.
If you're in the habit of using phab for discussion, you didn't need to see this email: phab would have notified you as soon as I created the task in the RFC project. The mailing list thread is for people who would prefer to discuss (or ask questions) outside phab.
FWIW, [slightly offtopic] I find discussions only on phab tend to have an echo chamber affect, where only the author, and people who the author regularly collaborate with see the ticket (Generally speaking). So I'm glad that these sort of things have mailing list posts too.
-- -bawolff
On Fri, Oct 2, 2015 at 1:08 PM, C. Scott Ananian cananian@wikimedia.org wrote:
If you're in the habit of using phab for discussion, you didn't need to see this email: phab would have notified you as soon as I created the task in the RFC project.
Assuming you're watching the RFC project.
On Fri, Oct 2, 2015 at 1:18 PM, Brian Wolff bawolff@gmail.com wrote:
FWIW, [slightly offtopic] I find discussions only on phab tend to have an echo chamber affect, where only the author, and people who the author regularly collaborate with see the ticket (Generally speaking). So I'm glad that these sort of things have mailing list posts too.
I like the mailing list post as an announcement, but I don't like fragmented discussions.
On Fri, Oct 2, 2015 at 2:10 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
I like the mailing list post as an announcement, but I don't like fragmented discussions.
My point is that you're picking on the wrong guy. I'm just following the process as written. If you'd prefer to see all discussion happen in a single forum, the RFC process document should be updated to say that: "write an announcement on wikitech-l but refer all discussion to the phab ticket", something like that. That's not what the process document currently says: there's no explicit encouragement to centralize discussion; in fact the process document seems to imply the opposite, that discussion should be wide-ranging.
Anyway, it's not my battle to fight, and it's off-topic for this proposal. That's all I'll have to say about it. --scott
wikitech-l@lists.wikimedia.org