Extension talk:TemplateStyles

Jump to navigation Jump to search

About this board

Sakretsu (talkcontribs)

Here you can see the normal behavior of a transclusion, whereas this test shows that Mediawiki does not recognize escapes due to templatestyles tags. I was wondering if this is intended. Wouldn't it be better not to force users to add a newline?

Tgr (WMF) (talkcontribs)

That's just how the MediaWiki parser works. Wikitext that needs to be at the beginning of the line (lists, tables, preformatting etc) cannot be preceded by markup, even if that markup is invisible. Compare

<indicator>...</indicator>* foo

for example.

Sakretsu (talkcontribs)

Sure, but my point is that we are supposed to make extensive use of TemplateStyles, and its tag has to be placed right at the beginning of each template code. If we want escapes to be detected, we have no choice but to add a newline, which leads to other problems, e.g. it wouldn't be possible to transclude the template inside indented text (beforeafter).

Anomie (talkcontribs)

The tag doesn't have to be placed right at the beginning of each template code. But it should be placed before what it's intended to style, so it can do so without a w:Flash of unstyled content.

BTW, I note the behavior you're wanting there (start-of-line behavior for parsing templates that aren't at start-of-line) is exactly what many people have complained about in T14974.

Tgr (WMF) (talkcontribs)

It's an unfortunate design choice, I'm not sure we can do anything about it though. After Parsing/Parser Unification has been finished, it will be easier to evolve the language and fix annoying corner cases like these, hopefully.

Reply to "Escapes"

Styling the page status indicators area

4
UV (talkcontribs)

The page Extension:TemplateStyles states:

  • "Styles added by TemplateStyles are scoped to avoid affecting the user interface outside of the main parsed content.
    • To use TemplateStyles to style something like w:en:MediaWiki:Protectedpagetext, you would need to enclose the message's contents in <div class="mw-parser-output">...</div>."

Is it safe to add <div class="mw-parser-output">...</div> to the contents of an <indicator>...</indicator> tag in order to be able to style the page status indicators area (see Special:Diff/3052169 and Help:Page status indicators) using the TemplateStyles extension?

(If yes, why isn't the page status indicators area wrapped in <div class="mw-parser-output">...</div> by default?)

Anomie (talkcontribs)

Is it safe to add <div class="mw-parser-output">...</div> to the contents of an <indicator>...</indicator> tag in order to be able to style the page status indicators area (see Special:Diff/3052169 and Help:Page status indicators) using the TemplateStyles extension?

Using <div> might introduce unexpected line breaks, you'll have to try it and find out. If it does, you might be able to fix it by switching to <span> or adding style="display:inline-block" or the like.

(If yes, why isn't the page status indicators area wrapped in <div class="mw-parser-output">...</div> by default?)

gerrit:352835 was submitted to do just that. Some people wanted different approaches and blocked that patch, but have yet to submit their own patch to do it the way they want.

Tgr (WMF) (talkcontribs)

On the other hand using a span might also have unexpected results if the contents include block elements... it's possible to add a wrapper knowing the specific skin and wiki style, but not in general, I think.

UV (talkcontribs)

Thank you! I have tested the div and it works fine in all skins installed on WMF without any undesired line breaks.

Reply to "Styling the page status indicators area"
XanonymusX (talkcontribs)

I have been experimenting with customised tooltips, using :hover via TemplateStyles. When I include such elements inside a wikitable with a caption, this caption seems to be affected by my tooltip. On the PC everything is fine; but when I’m on my tablet (both desktop and mobile version) or my mobile device (only desktop version!), whenever I activate the tooltip by tapping on the element, the table caption keeps jumping downwards with every tap, hiding parts of the table and not even stopping at the bottom of it. Any ideas which CSS definitions could be causing this effect, and why it is only happening on tablets and mobile devices (desktop-only)?

Tgr (WMF) (talkcontribs)

When you tap on an element, it becomes focused, so any CSS selectors with `:focus` are applied, and the browser also adds an outline for some elements (not captions, normally, but maybe it has a link inside, has a tabindex attribute etc). Outlines are like borders but are outside the element and so increases element size, possibly causing it to be reflown into another line. You can set `...:focus { outline: none; background-color: ... }` to highlight the element in a different way (again, this element might not be the caption itself).

The difference with desktop is that hovering does not count as focus (mobile devices do not have separate gestures for "hover" and "click" so they handle taps as a mix of the two). If you click on the caption you should see the same behavior, if I'm not wrong about the cause.

XanonymusX (talkcontribs)

Hm, thanks for the explanations. I have tried several things now, the error is still there. Clicking in the desktop version does not lead to the described behaviour (has no effect at all). The jumping caption seems to be only one symptom of a larger problem that could root back to browser incompatibilities, special iOS behaviour, some MediaWiki default styling definitions, but also to TemplateStyles (which is why I first asked here). Probably there is a better place to discuss this, I am happy to continue somewhere else, but let me give some more details first.

I have now rewritten the CSS, strictly following the demos on http://www.menucool.com/tooltip/css-tooltip. Since the tooltips on that page behave as expected on all devices I tested (iPad, iPod touch, Android phone: tooltip shows on tap and vanishes after tapping anywhere outside; PC: normal hovering), the problem must be MediaWiki-related. Using the CSS (directly or in a template) via TemplateStyles leads to the following problems:

  • if in a table (not necessarily wikitable), the caption jumps downwards when tapping the tooltip container (I have normal behaviour in (1) mobile version on iPod and Android phone, (2) desktop version on Android phone; it jumps in (1) mobile version on iPad, (2) desktop version on iPod and iPad);
  • tooltip does not vanish when tapping somewhere outside (works only if I tap outside of the page content, basically within the toolbar areas of desktop version; normal behaviour on Android phone; problem on iOS devices, desktop version);
  • if container area is only text, iOS devices show no tooltip at all (not tested on Android), it needs to be a link or an image (I am using icons, so at least that does not affect me); but again, the demo version, which uses only text, works also on iOS devices.

It comes as no surprise to me that iOS behaves differently, but if the CSS works outside of MediaWiki, I see no reason for the sudden problems here. If this issue has larger dimensions, I am happy to continue on Phabricator or somewhere else, then I could also give some more concrete examples.

Tgr (WMF) (talkcontribs)

Well, MediaWiki is not a CSS-free environment, it probably interferes with some other rules... you can try moving the CSS to MediaWiki:Common.css or some other global location to see if it is related to TemplateStyles.

XanonymusX (talkcontribs)

Okay, have tested it now on testwiki (thanks for the tip, I didn’t think of my personal common.css)! Since the behaviour is the same if the CSS is coming from the common.css, we can exclude that the problems are related to TemplateStyles. I will file a report on phabricator then, I guess!

XanonymusX (talkcontribs)

Okay, now phab:T212610! I will mark this here as resolved then.

Hwgen22 (talkcontribs)

When I insert a citation on my wiki using Citoid, it is added correctly. However, at the end of the citation, I get:

"<templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>"

Why do these tags appear and how to remove them? Thank you.

Jdforrester (WMF) (talkcontribs)

They're inserted by the template and Lua you're using (which you've imported from the English Wikipedia, by the looks of things), but it sounds like your wiki doesn't have the TemplateStyles extension installed, so it just gets output as raw text. You should install the extension, or re-work the templates and modules to not us TemplateStyles.

Hwgen22 (talkcontribs)

Hi @Jdforrester (WMF),


Thank you for your response. I've checked carefully and TemplateStyles is installed on my Wiki. I have the following information in Special:Version:

TemplateStyles 1.0 (e5da5c0) 18:14, 18 April 2018


In my LocalSettings.php file, these extensions are loaded in this order (note that the list is not fully displayed):


Cite

ParserFunctions

WikiEditor

VisualEditor

Scribunto

TemplateData

TemplateStyles

Citoid


I really don't understand why these tags appear. I obtain the same kind of error than if I remove the load of the extension.

Notice that in Module:Citation/CS1 page that I've imported from Wikipedia, multiple tags appear (thus, they are not parsed correctly). For example:

<section begin=header /> and <section end=header />

<section begin=module_components_table /> and <section end=module_components_table />


And so on. Maybe this issue is related with the one that I have with the tags of TemplateStyles?


Do you know what is the root of such problem(s)? I'm trying to find any relevant documentation on that, but I found nothing until now.


Jdforrester (WMF) (talkcontribs)
Hwgen22 (talkcontribs)

Yep, I've installed the extension and the section tags are now correctly handled. Thank you!


However, the <templatestyles> tags are still showing during the edit of a page, both on the citation dialog (when editing a reference) and at the bottom of page (references list), and I don't know why. I suspect that this is linked with VisualEditor and/or Parsoid. Otherwise, it is a problem linked with TemplateStyles directly (which is, potentially, not recognized?). I am not sure.

Jdforrester (WMF) (talkcontribs)

Possibly you're using an older version of Parsoid that doesn't know about templatestyles tags yet? Otherwise I'm not sure how you would achieve that issue.

Hwgen22 (talkcontribs)

Well, I've checked and I have the latest version of Parsoid (0.9.0). The documentation page says that Parsoid works fine with the latest versions of VisualEditor, so it seems that the error results from something else.


It is not a big issue as it does not prevent me from adding references, but it is still a problem and I also fear that it hides a bigger one.


I've opened a discussion in Parsoid wiki in any case.


Thank you for your help @Jdforrester (WMF) and if you have some news on this issue, please tell me!

Reply to "Tags are displayed"

Class 'Wikimedia\CSS\Parser\Parser' not found

3
Magol (talkcontribs)

When I try to save a css file, I get following error:

[2a9066e3ada1b0687cfa9e27] /w/index.php?title=Mall:Blank_head_empty/styles.css&action=submit Error from line 76 of /var/www/html/extensions/TemplateStyles/includes/TemplateStylesContent.php: Class 'Wikimedia\CSS\Parser\Parser' not found

Backtrace:
#0 /var/www/html/extensions/TemplateStyles/includes/TemplateStylesContent.php(131): TemplateStylesContent->sanitize(array)
#1 /var/www/html/includes/page/WikiPage.php(2129): TemplateStylesContent->getParserOutput(Title, NULL, ParserOptions)
#2 /var/www/html/extensions/TemplateData/includes/TemplateDataHooks.php(90): WikiPage->prepareContentForEdit(TemplateStylesContent, NULL, User, string)
#3 /var/www/html/includes/Hooks.php(177): TemplateDataHooks::onPageContentSave(WikiPage, User, TemplateStylesContent, string, integer, NULL, NULL, integer, Status)
#4 /var/www/html/includes/Hooks.php(205): Hooks::callHook(string, array, array, NULL)
#5 /var/www/html/includes/page/WikiPage.php(1618): Hooks::run(string, array)
#6 /var/www/html/includes/EditPage.php(2214): WikiPage->doEditContent(TemplateStylesContent, string, integer, boolean, User, string, array, integer)
#7 /var/www/html/includes/EditPage.php(1506): EditPage->internalAttemptSave(array, boolean)
#8 /var/www/html/includes/EditPage.php(652): EditPage->attemptSave(array)
#9 /var/www/html/includes/actions/EditAction.php(60): EditPage->edit()
#10 /var/www/html/includes/actions/SubmitAction.php(38): EditAction->show()
#11 /var/www/html/includes/MediaWiki.php(500): SubmitAction->show()
#12 /var/www/html/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)
#13 /var/www/html/includes/MediaWiki.php(861): MediaWiki->performRequest()
#14 /var/www/html/includes/MediaWiki.php(524): MediaWiki->main()
#15 /var/www/html/index.php(42): MediaWiki->run()
#16 {main}
Anomie (talkcontribs)
Magol (talkcontribs)

Thanks, I didn't see that information as it was written AFTER the YesY Done step

Errors Due To Sanitation?

4
Summary by Tgr (WMF)

var() is not supported since it's basically impossible to sanitize.

Johnywhy (talkcontribs)

i tried to create page Template:Tag/Tag.css.

I entered CSS that works with no problem in MediaWiki:Common.css

But when i save the page, i get:

Unrecognized or unsupported property at line 4 character 3.
Unrecognized or unsupported property at line 6 character 3.
Invalid or unsupported value for property top at line 12 character 8.
Invalid or unsupported value for property left at line 13 character 9.
Invalid or unsupported value for property bottom at line 14 character 11.
Invalid or unsupported value for property right at line 15 character 10.
Invalid or unsupported value for property padding-top at line 37 character 18.
Invalid or unsupported value for property padding-bottom at line 38 character 21.

Is that due to Sanitation?

Anomie (talkcontribs)

The sanitization does not allow some properties because they're unsafe, and it's possible it doesn't recognize some vendor properties (see T162379 about that) or hacks. It also won't allow invalid values, since to sanitize it has to first recognize them.

Without knowing what exactly you're trying, I can't say more than that.

Johnywhy (talkcontribs)
:root { 
  /* constants */
  --hotpad: -2em;
  --linepad: .4em
}

.tag-label a::before {
  display: block;
  position: absolute;  
  top: var(--hotpad);
  left: var(--hotpad);
  bottom: var(--hotpad);
  right: var(--hotpad);
  content: ''; 
}

.tag-label {
  position: relative;
}

.tag-label a {
  color: Green;
  font-weight: bold;
}

.tag-label:hover + .tag-region:not(:hover) {
     background-color:#ffe999;
     padding-top:var(--linepad);
     padding-bottom:var(--linepad);
}
Anomie (talkcontribs)

var() is not supported since it's basically impossible to sanitize.

Alex brollo (talkcontribs)

Two questions, mainly related to wikisource needs.

  1. TemplateStyles adds new css. The loaded css works into the whole page? I imagine a text with different tables, with different formatting needs.
  2. Wikisource needs that css can be exported in various derived files (i.e. ePub), is new css injected by TemplateStyles exported / exportable?

One more question, general.

How/when new css is imported, considering complex timing of other css upload by ResourceLoader? Can we be confident about the fact that new css will be uploaded as the last one, t.i. "at the bottom of the cascade"?

Anomie (talkcontribs)
  1. The loaded CSS is automatically scoped to the parsed wikitext's output (by prepending a class to each style rule), but it (currently) can affect the whole content area. It's recommended that you use classes to more specifically target only the corresponding template's output, to make it less likely for different templates' styles to conflict with each other.
  2. That's up to your export tool, probably. On the plus side, you'll be able to use @media and the like.

Re your "one more question", the CSS is included inline in the body at the point where the <templatestyles/> tag appears in the wikitext. Thus it should cascade after ResourceLoader styles.

Also, if the same CSS page is included multiple times, the PHP parser output is postprocessed to replace the extra inclusions with a placeholder. Parsoid doesn't do this postprocessing yet, see phab:T187142.

197.218.88.43 (talkcontribs)

Storing CSS in a separate page is 1000% the right approach, it is a pretty bad idea to add yet another parser/ tag function. People will then try to use it with the {{#tag extension and create a huge mess. It will also kill any idea of making these templates mobile compatible unless they ignore things like onlyinclude, which may render part of the template in a messy way, and the rest mobile compatible. This isn't to mention the huge potential for vandalism by enabling crazy animations that are only possible using sitewide css, or the fact that proper editing tools such as code-editors or even customized GUIs won't be possible when people start embedding those in weird ways.

If anything, there would be no point in this extension adding such a construct anyway, it is claimed to work in Extension:CSS which may already have been battle tested for several years in some wiki.

There is a chance that MCR might be vapourware, so that solution might end up stalling the project indefinitely, and maybe allowing the tag extension would be the lesser evil.

Melamrawy (WMF) (talkcontribs)

Thanks! FYI, there is now a dedicated page that is 90% complete here, in order to catch your very answer. Thanks again :)

Summary by Tgr (WMF)

It does.

47.91.176.251 (talkcontribs)

I think it doesn't. Besides, the selectors are also rewritten to include #mw-content-text. TemplateStyles use standard css syntax so people will expect it to work like normal css. When it doesn't,confusion arise.

197.218.82.64 (talkcontribs)

> I think it doesn't.

That may be wrong:

https://phabricator.wikimedia.org/T135788

It is very deliberate that this breaks expectations and mainly works for content inside body area. It also deliberately disables many css constructs that can cause security issues.

Maybe Extension:CSS would be more suited to the needs others who expect an extension to allow things to work like "normal css".

Anomie (talkcontribs)

@media does work since about 4 days ago.

Prefixing (with .mw-parser-output, not #mw-content-text) is intentional, as it prevents vandals from restyling the UI by writing bad styles (e.g. #ca-edit { display: none !important; }. It does work like normal CSS, just limited to a particular region of the page and ensuring that actual standard CSS is used.

Lojbanist (talkcontribs)

When will this be rolled out on English and Lojban Wikipedias, respectively?

Anomie (talkcontribs)

In either case, changing from HTML Tidy to Remex (T175706) is a prerequisite.

Then have an RFC or other discussion showing the community wants to be an early tester, then file a task like T190910.