I still think this is a really bad idea. We don't restrict any other wikitext feature by namespace, why start a precedent and open the can of worms for having to deal with all the edge cases that are going to come up?

In T176269#3637258, @Anomie wrote:

I still think this is a really bad idea. We don't restrict any other wikitext feature by namespace, why start a precedent and open the can of worms for having to deal with all the edge cases that are going to come up?

Any other wikitext feature is really easy to control. But CSS styles...

At the very least i expect people will want it on their user pages because users seem to like making overly ornate user pages. I could also imagine people using it in the portal namrspace.

If the community wants to do it then they can enable the namespace. But there is a lot of problem for now: names of classes, people's reactions, vandal's reaction etc.

May I please to make a small suggestion, not from a developer, just a very tech admin?

In T176269#3637356, @IKhitron wrote:

May I please to make a small suggestion, not from a developer, just a very tech admin?

No need to ask, just do it.

Thanks. Maybe it will be better for you to decide, and for communities to be asked, not now, but after some experience, say a month after all wikis deployment.

In T176269, @Tgr wrote:

we should only allow the use of <templatestyles> tags in the Template namespace for now

In another case, there can be irreparable harm.

I don't think that TemplateStyles should be restricted to the template namespace. TemplateStyles would be super useful for main pages in the Portal namespace.

Maybe @Jdlrobson can correct me on this, but as far as I understand it, the mobile team has hacks for main pages to make them look good on mobile, and they were looking forward to removing these hacks with TemplateStyles. There may be more info on this in T32405 or T138622.

To be clear this task is about disallowing direct usage of <templatestyles> tags in the wikitext in certain namespaces, not about disallowing template styles in those namespaces altogether. Templates that use <templatestyles> would still work in every namespace.

In T176269#3637318, @Iniquity wrote:

Any other wikitext feature is really easy to control. But CSS styles...

What about CSS styles? Reverting, protecting, and blocking will work as well for these pages as for anywhere else.

In T176269#3637338, @Bawolff wrote:

At the very least i expect people will want it on their user pages because users seem to like making overly ornate user pages. I could also imagine people using it in the portal namrspace.

User subpages being used as templates would need it too. And sometimes people use subpages in the Project namespace as templates on Project pages. Do they do the same with other namespaces? Which ones?

In T176269#3637381, @Iniquity wrote:

In T176269, @Tgr wrote:

we should only allow the use of <templatestyles> tags in the Template namespace for now

In another case, there can be irreparable harm.

Err, what? That non sequitur sounds like pure FUD.

In T176269#3637792, @Tgr wrote:

To be clear this task is about disallowing direct usage of <templatestyles> tags in the wikitext in certain namespaces, not about disallowing template styles in those namespaces altogether. Templates that use <templatestyles> would still work in every namespace.

So, instead of someone having to type <templatestyles src="Foobar"/> somewhere, they put it in a template and transclude that while ignoring the recommendation that stylesheets only affect the template's own output (see also T176272). Or they make a template with {{#tag:templatestyles||src={{{src}}}}} to do that generically. How does this restriction actually restrict anything again? It just enforces hiding the <templatestyles> tag behind a template which the communities seem to already police well enough in the cases of Scribunto's {{#invoke:}}, ParserFunctions's various parser functions, and so on.

In T176269#3639418, @Anomie wrote:

In T176269#3637338, @Bawolff wrote:

At the very least i expect people will want it on their user pages because users seem to like making overly ornate user pages. I could also imagine people using it in the portal namrspace.

User subpages being used as templates would need it too. And sometimes people use subpages in the Project namespace as templates on Project pages. Do they do the same with other namespaces? Which ones?

We do this in Project namespace.

I actually think limiting to template and user namespace is the correct thing. Limiting it encourages reuse which was a strong motivation when this idea was initially conceived. I think enabling it in other places can be considered when we have stronger evidence that this is useful. We don't need to do this straight away so let's at least see what happens when it's available in template namespace.

TBH it's my opinion that if we allow styles in any namespace we're making the situation far worse for mobile users. Templates are only editable by a small subset of users and these users can help act as gatekeepers. Mobile knowledge is scarce in our community. If we allow styles anywhere, we're opening up a pandora's box where I doubt we'll be able to recover from.

@Nirmos all hacks in mobile act on styles provided by templates. We do not apply hacks to any content created outside a template.

In T176269#3639953, @Jdlrobson wrote:

Templates are only editable by a small subset of users and these users can help act as gatekeepers.

This is false, most templates can be edited by anyone. A relatively small number of widely-used templates are generally protected by the wikis' communities.

I agree with Anomie that it doesn't really make sense impose technical restrictions in TemplateStyles itself for this, and instead would prefer to let wiki communities handle this on their own. I think that model has worked out pretty well for Scribunto.

In T176269#3639418, @Anomie wrote:

Err, what? That non sequitur sounds like pure FUD.

Hm, I think you have never tried to control the community's vandals and users who can broke everything when they start to work with design or code.

In T176269#3644205, @Iniquity wrote:

In T176269#3639418, @Anomie wrote:

Err, what? That non sequitur sounds like pure FUD.

Hm, I think you have never tried to control the community's vandals and users who can broke everything when they start to work with design or code.

This is silly. From a vandal prespective, templatestyles is no more dangerous than a vandal wrapping the entire article in <div style="display:none">

In T176269#3644388, @Bawolff wrote:

This is silly. From a vandal prespective, templatestyles is no more dangerous than a vandal wrapping the entire article in <div style="display:none">

Sorry, but I think you're wrong. I'm not taking a side in this conversation, but this I can say. The TemplateStyles, as wonderful it is, is much more dangerous than inline css. It's because most of the watchers and patrollers do not know the css details, but they do know that if some css code was changed in line 256, they check how does this line look now in the view mode, wasn't something broken. With templatestyles a vandal change in stylesheet is out of the watchlist, so watchers will not check it, patrollers do not know what the change does, and if even you tell them that a change in this file will do something to that page, they will not know in which line they should check. That's why I'm going to ask our community to decide allowing sanitize css contentmodel editing and moving for autopatrolled only.

@Jdlrobson to be clear, this is the current situation:

• TemplateStyles CSS can only be stored in the Template namespace
• <templatestyles> tags can be put anywhwere
• templates which internally use TemplateStyles can be used anywhere

After the proposed change:

• TemplateStyles CSS can still only be stored in the Template namespace
• <templatestyles> tags can only be used in the Template namespace
• templates which internally use TemplateStyles can be used anywhere

So I don't think this affects reuse in the sense you are interested in it.

On the other hand it's possible to get template CSS into non-template namespaces (or pages not ending with .css) via page move or Special:ChangeContentModel. If we want to prevent that (I don't see much reason not to), it should probably be discussed in a separate task to reduce confusion.

@Tgr thanks you are right. Yes I am only concerned with CSS being embedded in non-reusable wiki pages. Thanks for taking the time to understand what I was getting at and reassuring :)

In T176269#3639418, @Anomie wrote:

So, instead of someone having to type <templatestyles src="Foobar"/> somewhere, they put it in a template and transclude that while ignoring the recommendation that stylesheets only affect the template's own output (see also T176272).

Naked templatestyles tags ignore that recommendation anyway. They raise the same problem to VE as templates with non-scoped effects: the user changes a DOM subtree and it causes display changes outside that subtree. As noted in T176272 I think we should suspend that recommendation for certain use cases (with the caveat that it will probably be restored once template heredoc syntax is supported) but I'd like to hear someone from Editing comment on that first.

It just enforces hiding the <templatestyles> tag behind a template which the communities seem to already police well enough in the cases of Scribunto's {{#invoke:}}, ParserFunctions's various parser functions, and so on.

That is pretty much the goal, yes. Communities can police that, but they might not be aware of the new feature, might not be happy about the prospects of more policing, or (more likely) might not care about policing something that looks reasonably OK in the wikitext editor but very broken in VE (which just displays templatestyles tags as <> and you can't even edit the location of the CSS page).

In T176269#3644789, @Tgr wrote:

On the other hand it's possible to get template CSS into non-template namespaces (or pages not ending with .css) via page move or Special:ChangeContentModel. If we want to prevent that (I don't see much reason not to), it should probably be discussed in a separate task to reduce confusion.

Filed T177027: Should we allow sanitized-css (TemplateStyles) content under titles where it is not the default content model?.

In T176269#3644837, @Tgr wrote:

In T176269#3639418, @Anomie wrote:

So, instead of someone having to type <templatestyles src="Foobar"/> somewhere, they put it in a template and transclude that while ignoring the recommendation that stylesheets only affect the template's own output (see also T176272).

Naked templatestyles tags ignore that recommendation anyway.

Not exactly. The "template" in this case is the page being viewed, and the effects of the styles are indeed scoped to that.

They raise the same problem to VE as templates with non-scoped effects: the user changes a DOM subtree and it causes display changes outside that subtree.

There has never been a proposed requirement about DOM subtrees in general.

As noted in T176272 I think we should suspend that recommendation for certain use cases (with the caveat that it will probably be restored once template heredoc syntax is supported) but I'd like to hear someone from Editing comment on that first.

Personally, I'm not fond of the recommendation at all. Editing is the one that insisted on it.

It just enforces hiding the <templatestyles> tag behind a template which the communities seem to already police well enough in the cases of Scribunto's {{#invoke:}}, ParserFunctions's various parser functions, and so on.

That is pretty much the goal, yes. Communities can police that, but they might not be aware of the new feature,

That's what Tech News is for, isn't it?

might not be happy about the prospects of more policing,

The thing we're discussing doesn't actually add any new policing. It just adds one more thing to trigger a "that's not right" when doing the existing policing.

or (more likely) might not care about policing something that looks reasonably OK in the wikitext editor but very broken in VE (which just displays templatestyles tags as <> and you can't even edit the location of the CSS page).

I see no reason to add this restriction just to work around (hopefully) temporary inadequacies in VE.

The "template" in this case is the page being viewed, and the effects of the styles are indeed scoped to that.

AIUI one of the problems with unscoped styles is that VE wants to be able to handle deleting/moving of things ("things" roughly meaning DOM nodes) in the editor in the trivial way, without having to reparse the page. That problem applies to raw <templatestyles> tags in the articles just as well as tags in templates with out-of-scope effects. OTOH it does not seem safe to make that assumption when the DOM subtree includes an extension tag that's unknown to VE... Maybe @Jdforrester-WMF or @Deskana can clarify whether that's a concern or I misunderstood some earlier conversation.

That's what Tech News is for, isn't it?

Yeah but in my experience the fraction of editors who care is sufficiently small that it doesn't really help with preventing surprises. That's not a problem when deploying TemplateStyles to a wiki where it has a local advocate; it could be a problem when deploying everywhere.

I see no reason to add this restriction just to work around (hopefully) temporary inadequacies in VE.

Working around limitations of other software is a perfectly good reason to add something. But on closer inspection extension tag parameter handling exists, it's just buggy. Filed T177180, T177181, T177183. (Also T177184 about more intelligent future handling.)

In T176269#3649594, @Tgr wrote:

The "template" in this case is the page being viewed, and the effects of the styles are indeed scoped to that.

AIUI one of the problems with unscoped styles is that VE wants to be able to handle deleting/moving of things ("things" roughly meaning DOM nodes) in the editor in the trivial way, without having to reparse the page.

The problem with VE was when we were considering putting the styles in the head (either inline or via ResourceLoader), VE would have to know when it should remove the style tag or RL module fetch from the page head. But since T155813 chose 3A/3E, that's not a problem. It's true that VE will have to reduplicate the in-body <style> tags once 3E is implemented (and specifically, implemented in Parsoid), but that's well known and has to happen whether <templatestyles> appears directly or is included via a template.

Remaining concerns with TemplateStyles affecting parts of the page outside of the template had more to do with potential client-side repaints, vandalism opportunities, and end-user confusion (cf. section editing and Cite's named references). You can see your own comment at T155813#3018993 for some details, and T155813#3021202 for more.

Yeah but in my experience the fraction of editors who care is sufficiently small that it doesn't really help with preventing surprises. That's not a problem when deploying TemplateStyles to a wiki where it has a local advocate; it could be a problem when deploying everywhere.

You're making an argument for never introducing anything new, ever, because people might be too lazy to learn about it and surprised after it happens. Should we not have introduced Scribunto because people might be surprised at seeing Lua code? Or interactive maps?

I see no reason to add this restriction just to work around (hopefully) temporary inadequacies in VE.

Working around limitations of other software is a perfectly good reason to add something.

There's a difference between actual limitations and bugs.

But on closer inspection extension tag parameter handling exists, it's just buggy. Filed T177180, T177181, T177183. (Also T177184 about more intelligent future handling.)

See, bugs not limitations. Thanks for taking the time to write them up.

@Anomie well, then... do you have any idea how we can control creation extra css-pages?

In T176269#3686483, @Iniquity wrote:

@Anomie well, then... do you have any idea how we can control creation extra css-pages?

The same way you control creation of extra templates, articles, or any other kinds of pages?

In T176269#3688003, @Anomie wrote:

In T176269#3686483, @Iniquity wrote:

@Anomie well, then... do you have any idea how we can control creation extra css-pages?

The same way you control creation of extra templates, articles, or any other kinds of pages?

So, you want to say that I will have something like createpage, createtalk, editinterface and gadgets-edit rights?

You have exactly those rights. In this case, 'createpage' is the one most likely to be relevant.

In T176269#3690706, @Anomie wrote:

You have exactly those rights. In this case, 'createpage' is the one most likely to be relevant.

Hm, but I havent got edittemplatecss right. I dont wanna use blacklist or another filters if u can create really useful function.

You also don't have an 'editprojectpages' right, or an 'editcategorypages' right, etc.

Yes, you are right (not about 'editprojectpages'). But 'css-pages' will not be a new namespace, these pages will be hidden in the subpages. These pages will affect on many simple pages and the community dont know how to control them. Templates and standard HTML-tags isnt using for design because of community history and community culture. But new TemplateStyles function is not included in this history and culture. And I really afraid to switch on this ext on big one wiki-project. This feature will be good toy for vandals, and community needs to have a time to adjust to the situation, to create a new history and culture of using this function.

One more, It is really difficult to control because only 5-10 community users know what to do with CSS, but people can use it really easy, since CSS is very simple in contrast to our template-code.

You seem to be contradicting yourself now. First you claim CSS is so complicated that only 5-10 people on a wiki will know what to do with it, but then you claim the people can use it very easily since it's simple in comparison to wikitext templates.

At any rate, you're now very far off the topic of this task.

No, Im not contradicting myself. 5-10 people are people who can control codestyle, rules etc. Another people are people who can change everything what they want.

At any rate, you're now very far off the topic of this task.

I am not sure about it. These reasons why I dont want to see TemplateStyles in main namespase.

I feel like the most appropriate model to use is not to restrict usage of TemplateStyles pages anywhere (since there would be, for example, cases of testing the template code in your personal space), but to restrict the creation and editing of such pages to template/interface editors or sysop level.

CSS still remains the area in which you can do many things that would not be appropriate for such a tool, so it obviously becomes a choice of either we a) disallow <templatestyles>, as the title and the task seems to suggest, or b) restrict its creation as with any other high-profile page that could potentially be used incorrectly by non-experienced or just ill-intentioned editors.

I don’t see how allowing this per-namespace would be better than having these pages developed and used by the most experienced users in respective Wikimedia projects, since in one case they would be required to watch over any potential leaks (such as: bad cases of usage, code bloating, just pure vandalism) like in a whack-a-mole and in the other they would have the full control over the scope and usage of this instrument. There aren’t really any benefits to first approach aside from the fact that it is certainly more open to an average editor (but openness should not be a goal in itself for us).

Let me also support the position of not restricting <templatestyles> to a specific namespace.

I have a suggestion: can we get some potential use cases on the whiteboard for this task, so we can assess the benefits or costs to allowing a templatestyles in certain places from a functional point of view?

Here's one: there's a really common pattern of editors wanting to right-align table cells because those cells hold numbers. What goes where in this scenario?

Here's the summary of the discussion so far as I see it. Keep in mind I'm firmly on the "oppose" side, so I may have failed at writing an unbiased summary.

Pros:

• Enforces slightly more understandable wikitext.
• Not supported well in VE. (actual bugs have since been fixed (see list in T176269#3649594), other claims were baseless)
• "in general there is just not much use case for it"
• It's easier to do this now and then enable it in more namespaces later than it is to disable it in more namespaces later.
• Less chance to surprise users with a new feature.

Rebuttals:

• Communities can enforce "slightly more understandable wikitext" as they already do for things like Scribunto's {{#invoke:}}, ParserFunctions, and so on. It's no extra work for patrollers.
• "in general there is just not much use case for it" isn't a reason to do extra work to prevent it.
• While it would be easier to do it now than later, that presupposes it should be done at all.
• "Less chance to surprise users with a new feature" is an argument against ever adding anything new anywhere. People can easily learn, just as they did with Scribunto and will with interactive maps.

Cons:

• No other feature is namespace-limited like this, sets a bad precedent.
• Significantly more complicated code to check this. Unclear if it's possible in Parsoid.
• We've already identified User, Project, and Portal as additional namespaces that will need to be enabled. Possibly also main pages where they're not in Project or Portal. What else?
• Doesn't really restrict anything except syntax, since someone could make a template containing {{#tag:templatestyles||src={{{src}}}}} to work around it.

In favor: @Deskana (by proxy, hasn't commented here), @Tgr, @Iniquity (although possibly more for T177027 than this task)
Opposed: @Anomie, @Nirmos, @Legoktm, @stjn, @Platonides
Comments, but no opinion on this task expressed: @Bawolff, @dr0ptp4kt, @IKhitron, Jdlrobson (expressed support for something more like T177027 than this task)

In T176269#3909971, @Anomie wrote:

• Doesn't really restrict anything except syntax, since someone could make a template containing {{#tag:templatestyles||src={{{src}}}}} to work around it.

This will be done if <templatestyles> is namespace restricted. I suggest declining as pointless.

Significantly more complicated code to check this. Unclear if it's possible in Parsoid.

So yeah, this turned out to be way more complicated than I thought. There is no way for a parser hook to signal error, not even via global state hacks: all the hooks which are able to abort a page save are called before parsing starts. So if we want to abort saving the text needs to be parsed twice. Parses are cached, but anything can happen between the call to PageContentSave (the last hook that can abort) and the actual parsing (including the ArticlePrepareTextForEdit call that could change parser options) so this could end up being a major performance hit.

Also, the parser will ignore <includeonly> tags so it's impossible to prevent tags from being added there without doing two parsing passes (or modifying the parser to have a "parse everything" mode).

The easy(er) way would be allowing the save to proceed and then showing an error message where the extension was invoked, like e.g. Cite does for invalid citations. OTOH in that case we might want feature parity in Parsoid and I haven't even looked at that.

Change 405236 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/TemplateStyles@master] [POC] Warn when using <templatestyles> tags in non-template namespaces

https://gerrit.wikimedia.org/r/405236

Change 405237 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/TemplateStyles@master] [POC] Disallow <templatestyles> tags in non-template namespaces

https://gerrit.wikimedia.org/r/405237

In T176269#3911796, @Tgr wrote:

OTOH in that case we might want feature parity in Parsoid and I haven't even looked at that.

Strike that comment; since Parsoid will call the MW API to do the template expansion, it should not need any extra handling for that.

In T176269#3909971, @Anomie wrote:

• Doesn't really restrict anything except syntax, since someone could make a template containing {{#tag:templatestyles||src={{{src}}}}} to work around it.

As far as I can see it wouldn't really make a difference. I might easily have misunderstood how the parser handles tags, though.

I too, don't see a reason, why it should be necessary to prevent people from using <templatestyles> within normal Wiki-Pages. There are quite some use cases where styles are only necessary for a single page – e.g. the MainPage or the central Meta-Pages. And it would be just a waste of energy to force people to create single-use-templates for that.

Therefore +1 for skipping T176269

Yeah, this is a bad idea. All the things vandals could do with this can be done just as easily out of the template namespace as anywhere, and even on third-party sites like ?pedia and uncyclopedia where we use extension:css, which lets users use pretty much ANY css anywhere, applying to anything on the page, it still hasn't caused a lot of extra problems. Yes, vandals with that can even remove the entire interface, but it's not like they couldn't cover it all up before, or the like, and these kinds of edits do stand out particularly when using change patrolling tools.

All it'd do in practice is make things more complicated for users trying to do sensible things, and in the process mess with their mental models for understanding how the site even works. It's bad UX, for no real gain.

I never has a clear oppinion about this task need. I do very afraid from css vandals, but not sure if it will help or no. But @Isarra's comment gave me an idea. Maybe we should mark sanitized css page edits also as edits of the page they are included in. So, if some template, or article, can be destroyed by css page edit, theirs watches and patrollers will be aware of it in real time.

In T176269#3915095, @IKhitron wrote:

Maybe we should mark sanitized css page edits also as edits of the page they are included in. So, if some template, or article, can be destroyed by css page edit, theirs watches and patrollers will be aware of it in real time.

That's basically the same thing as asking for any edit to a template show up as a change on every page it's included in, in case people vandalize a template. Particularly since TemplateStyles records uses of these CSS pages identically to transclusions of templates, so they will show up in the same way as templates on things like the "Templates used on this page" display at the bottom of the edit form.

Or, for a similar feature that already exists, this would be like having any change to a Wikidata item show up as a change on every page that uses it. For which T178063 is relevant.

In T176269#3915293, @Anomie wrote:

In T176269#3915095, @IKhitron wrote:

Maybe we should mark sanitized css page edits also as edits of the page they are included in. So, if some template, or article, can be destroyed by css page edit, theirs watches and patrollers will be aware of it in real time.

That's basically the same thing as asking for any edit to a template show up as a change on every page it's included in, in case people vandalize a template. Particularly since TemplateStyles records uses of these CSS pages identically to transclusions of templates, so they will show up in the same way as templates on things like the "Templates used on this page" display at the bottom of the edit form.

Yes. The difference is in numbers - there will be much less revisions in some watchlist for css than for transclusions.

Or, for a similar feature that already exists, this would be like having any change to a Wikidata item show up as a change on every page that uses it. For which T178063 is relevant.

This was a trigger for my comment, indeed.

In T176269#3915298, @IKhitron wrote:

Yes. The difference is in numbers - there will be much less revisions in some watchlist for css than for transclusions.

On the other hand, one could easily ask why CSS is so much more sensitive than any other transclusion that it needs this special treatment.

Change 405236 abandoned by Gergő Tisza:
[POC] Warn when using <templatestyles> tags in non-template namespaces

Reason:
per task

https://gerrit.wikimedia.org/r/405236

Change 405237 abandoned by Gergő Tisza:
[POC] Disallow <templatestyles> tags in non-template namespaces

Reason:
per task

https://gerrit.wikimedia.org/r/405237

In T176269#3915299, @Anomie wrote:

On the other hand, one could easily ask why CSS is so much more sensitive than any other transclusion that it needs this special treatment.

Well, for one, it allows much more than even Lua to an average editor. I am not, however, a supporter of some ability to watch an article and get all CSS edits from it* (although ‘watch a template and get styles.css too automatically’ could be useful and probably will prove to be a must-have), but we need to get away from the false attitude of ‘CSS can’t be used in very bad ways and community can always enforce against the bad stuff’ either.

* Expanding: CSS edits wouldn’t say very much to anyone, just as Lua edits wouldn’t say very much to anyone, and the only thing this will cause are false positives from editors that are seeing something wrong with the article and want to act on the first thing that came into their mind.

In T176269#3915303, @stjn wrote:

Well, for one, it allows much more than even Lua to an average editor.

How so? It allows different things, but all in all I think Scribunto gives editors much more power.

(although ‘watch a template and get styles.css too automatically’ could be useful and probably will prove to be a must-have),

Could be useful, as would "watch a template and get its subtemplates too automatically" or "watch a template and get its doc page too automatically". I doubt it will in any way prove to be a must-have.

but we need to get away from the false attitude of ‘CSS can’t be used in very bad ways and community can always enforce against the bad stuff’ either.

There's not much you can do "very bad" with this feature that you can't already do with inline CSS. I can think of a few things you could do to make your vandalism more confusing, which I won't go into here, but in the end it wouldn't be much more confusing that normal template vandalism.

There's nothing you can do "very bad" with this feature that the community can't deal with in the ways they already deal with template vandalism.

In T176269#3915304, @Anomie wrote:

(although ‘watch a template and get styles.css too automatically’ could be useful and probably will prove to be a must-have),

Could be useful, as would "watch a template and get its subtemplates too automatically" or "watch a template and get its doc page too automatically". I doubt it will in any way prove to be a must-have.

Again it's much easier than in templates, just because of number. Maybe in five years the Templatestyles will be everywhere, and the watching will stop beeing so helpful.