Change #1196977 abandoned by Aklapper:

[mediawiki/extensions/SearchVue@master] ContentTranslation: Remove compatConfig from Vue components

Reason:

This is an exact copy of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SearchVue/+/1122674 . Creating duplicates on purpose makes no sense and is not a good use of anybody's time.

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

Hello there, i am claiming this task and have uploaded patches for tasks

Change #1196977 had a related patch set uploaded (by LazyShrey; author: LazyShrey):

[mediawiki/extensions/SearchVue@master] ContentTranslation: Remove compatConfig from Vue components

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

Change #1196976 had a related patch set uploaded (by LazyShrey; author: LazyShrey):

[mediawiki/extensions/ContentTranslation@master] ContentTranslation: Remove compatConfig from Vue components

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

With only Steering Committee left, I set this to declined in current setup. Codex Steering Committee or others could come back and revert with more and stronger availability. Additionally the Telegram group https://t.me/+oeXgL95hvgZiMDgx has been established for async checkins.

Adding to relevant wikidata team board. @Arian_Bozorg we should pick this up whenever we're working on the NSLP next

Hi everyone, I’m exploring implementing a ResourceLoader module that exposes Codex tokens as CSS variables (via :root { --token: value; }). Would this be a good starting point to address gadget-side access to tokens?

Change #1179735 abandoned by 3MindedScholar:

[design/codex@main] docs: Shifted back to original coding style

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

Change #1179735 restored by 3MindedScholar:

[design/codex@main] docs: Shifted back to original coding style

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

hearto for the help

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

In T320322#11244265, @stjn wrote:

I think the second security requirement is not really necessary if the variable name would enforce what values it might have and TemplateStyles would only accept CSS variables of a particular type. As you yourself say, it’s not a particularly strong protection anyway, so unless it would be required by TS to validate the variable values, it doesn’t seem useful to have.

I think the second security requirement is not really necessary if the variable name would enforce what values it might have and TemplateStyles would only accept CSS variables of a particular type. As you yourself say, it’s not a particularly strong protection anyway, so unless it would be required by TS to validate the variable values, it doesn’t seem useful to have.

Copying what i wrote on T200632#11221909 as its really for this ticket

Managed to fix it.

In T386568#11221943, @taavi wrote:

In T386568#11221940, @Gzhegozh wrote:

Can someone please give me an update why this hasn’t been implemented yet?

https://www.mediawiki.org/wiki/Bug_management/Development_prioritization#Why_has_nobody_fixed_this_issue_yet?

Thanks @Vanshika!

@egardner I think that answers our questions and we should have what we need at this point. I'll pull this one to our next refinement session.

@Volker_E Glad I could help

@Volker_E Yes, this task is ready to be resolved. The merged patch uses negative margins, and there was a suggestion to investigate an alternative approach to negative margins as a follow-up task.

As @DTorsani-WMF said I think this is mostly an engineering task that shouldn't really need explicit designs. The MenuButton should accept action and weight props, and it should look the same as the Button component does when given those props. Does that make sense?

Thanks @Salujapushpit!

@lwatson Is this ready to be resolved, or does Reader Growth need to continue to work with this ticket?

In T386568#11221940, @Gzhegozh wrote:

Can someone please give me an update why this hasn’t been implemented yet?