Page MenuHomePhabricator

Does TemplateStyles work well with the preview feature?
Closed, ResolvedPublic

Description

We have heard that there are plans to have previews so that people can view templates on other form factors.

What we would like to know is does TemplateStyles, which touches the resource loader, work well with the preview feature?

Event Timeline

That's a really good question! Certainly one that requires more thought and discussion. Here's where my thought process led...

It's hard to say today how TemplateStyles would be applied in preview-eligible content sections, but as I understand previews in general are / will be generated on the material that shows early in an article (until such time that for example there's some other input construct; magic words and MCR slots are two things I've heard or thought about as possible options, but it's probably usually desirable for the content at the beginning of the article to correspond to the preview material for long form articles). AFAIK wide format material and infoboxes that would be problematic for Page Previews, as well as, for example, Android on-link-tap previews, or other cards, is typically excluded in some fashion during its extraction / re-formatting.

Now, as to adding TemplateStyles CSS to in particular make wide format material- and infobox-based content render nicely as primary content in Page Previews, as wells as, for example, Android on-link-tap previews, or other cards, I don't recall that coming up as a topic of discussion.

I wonder, is it likely that such wide format material and infoboxes would become commonplace for needing to be rendered in the context of a preview/card? My hunch is probably not, but I don't know for sure.

+@Fjalapeno and @phuedx for visibility and any insights they can share.

TemplateStyles does not currently touch ResourceLoader. In the future (T160563/T168333) it will, but still not in the usual way—rather than being loaded separately, even in the RL future TemplateStyles will still be embedding the styles in the HTML body using a <style> tag.

It seems the question here is about a not-yet-developed feature that attempts to show a page as it would look on different-sized mobile devices. It's hard to answer such a question, since the feature in question doesn't actually exist yet. But there shouldn't be any problem with respect to ResourceLoader, since, as mentioned above, TemplateStyles does not load stylesheets via RL's load.php entry point. I don't know whether @media queries might complicate such a preview feature, although I note they exist in existing RL-loaded stylesheets as well so the problem isn't unique to TemplateStyles-added stylesheets. The developers of that feature will also have to be sure that an element with class mw-parser-output wraps the content if they're doing their own thing like VE and Flow do.

OTOH, there are also several other things that might be described as "the preview feature". Since people searching for those other preview features might wind up here, I'll address them too:

  • When a page is previewed using the standard wikitext editor, the preview will apply the styles loaded by any templates in the wikitext being previewed. This will be the case both before and after T160563/T168333.
  • I don't know for sure about the Live Preview feature in the wikitext editor, but I believe it too will apply the styles loaded by any templates in the wikitext being previewed both before and after T160563/T168333. @TheDJ might know about it.
  • If you're editing the stylesheet itself, TemplateStyles works well with MediaWiki-extensions-TemplateSandbox's "Preview page with this template" feature. It will continue to do so after T160563/T168333.
  • If you're talking about Page-Previews [1] (aka Extension:Popups), I have no idea.
    • It likely depend on whether Popups preserves the <style> tags (currently TextExtracts doesn't, and mw:Extension:Popups says that's what it uses to get its text), and perhaps what exactly it does regarding truncation of the HTML if people decide to put the tag at the end of the template rather than at the beginning.
    • It also depends on the popup generated by Popups being inside an element with class mw-parser-output or it adding that to the wrapper it itself uses to hold the content.

[1]: BTW, whoever made that renaming decision should be told about the confusion appropriating such a vague name has caused.

The one thing that I can think of that might complicate (Live) preview right now is section editing (styles outside of the preview might affect your end page result). Other things should not be a problem however.

Regarding Page-Previews / TextExtracts, I don't think that right now those styles SHOULD be taken into account, because it will cause the styling of one page to be applied to the styling of another page. But currently don't allow for much styling to begin with, they only allow a few specific tags, and generally no class and style info.

Regarding Page-Previews / TextExtracts, I don't think that right now those styles SHOULD be taken into account, because it will cause the styling of one page to be applied to the styling of another page.

Seconded.


@Anomie and @TheDJ are correct in that Page-Previews won't preserve <style> tags as it uses TextExtracts under the hood, which defaults to removing them. There's also no plan to change that behavior nor to support TemplateStyles.

I would note that we are moving away from truncating the HTML response without any regard for its validity. In future, it may be easier to support TemplateStyles.

Anomie claimed this task.

The question is answered. There seems to be nothing else to do here.