Description is not updated when a style is uploaded from Stylus plugin

[paponius]

• Browser: Firefox

• Additional context: Let me know, if this is an issue only with my set-up, I'll try to replicate and document it better.

[a0eoc]

I couldn't find the difference between publishing and updating a style from Stylus. But I suppose for now metadata is only parsed and updated when the style is imported or when its automatically updated on mirroring.

I think the checkbox "Mirror userstyle metadata" can be reused for this and be renamed to "Follow source code metadata", so metadata will be updated on source code updates of any kind.

[paponius]

that could work.
But there is still another way to un-sync the description. By editing it on the Edit Page.
What's actually the purpose of having both Description AND Notes AND another Description inside the script?
Isn't that unnecessary complicated? What about getting rid of one Description all together?
Have it always follow the Description in code, and put a note on Edit Page, that changing description will change it in the code, and that if it's updated in the code by external means, it will overwrite any manual changes here (made on the Edit Page).

And what's the reason for having a possibility to have un-synced Name? To be able to use one name inside the CSS and another for the name on USw?
If a user would get a style from the USw, then they wouldn't be able to find it in the Stylus plugin under that name, they might be quite confused.
Is there a good use-case for having two different names?

And a side note, I am not sure people understand what this means on Edit Page: Will be used for SEO and rich embeds.

[a0eoc]

What's actually the purpose of having both Description AND Notes AND another Description inside the script?

Some people may want to have different descriptions. We also have 160 chars limit for it on USw and it is less than description of some userstyle may have for sure. Notes are widely used for changelogs, additional screenshots and a lot of other suff.

Is there a good use-case for having two different names?

You may use website's full name in userstyle name on USw and a short name for the actual style, so it won't be too bulky in the popup. Like "UserStyles.World acid rain theme" and "USw acid rain".

I am not sure people understand what this means on Edit Page: Will be used for SEO and rich embeds.

I don't think I'm competent enough to answer this, just clarifying why this isn't answered by me.

[paponius]

Thanks for your answers.
They are very correctly answering how things work.

In my understanding, a program bug is something that happens unexpectedly, or unintentionally to a design.
A bug could also be an unforeseen issue with the design itself.
In general, from a user perspective, a bug could also be defined as something the program does against the wishes or understanding of a user.

The way the Description and Name work/do not work is a bug.

As you explained and as I now also tested, Name and Description are completely separated from the Name an Description in the script. So this is not an issue limited only to the upload.
If the Name and Description is populated the first time a script is uploaded, it should be so every time.
As Name and Description in the script are for the same purpose, to name and describe a script, these valuenames should keep the same purpose and values in USw.
Otherwise, the Description value on USw should have a different name, e.g. Description for the USw, or at least there should be a Notice stating that the Description for USw should not be confused with the Description for the script in the script code.
But since there is also a Notes field, I don't see a reason to have them both just for the site, while having third Description, with different value, for the script.

The same goes for the Name.
I understand your reasoning to have two Names, but I don't think it's a good enough PRO, to justify the CON of confusion of two names, which could be completely different.
And you are probably aware of the third Name, which the plugin offers to users, where they can change the name of the script, which will show in the popup, without editing the script itself, and breaking updates.
If a designer of a style desires to have different name for the USw, and you want to allow such case, there should be additional field for this purpose, which if filled, will override the name just for the USw site.
But to allow different Name values from the start, without explaining what they are for, is not an advantageous feature.

But this is just my bug report, stating what I see as a problem with the site.
Developers could have a different view and keep things the way they are.

SEO and rich embeds,
SEO is a means to let a search engine bot know what's important data and how the site is organized.
rich embed is mostly used by authors to insert their products on their own pages, linking back to the original site.
I did not find an option to embed a style, I guess it's just an idea for future.
And SEO, as I tested, is broken, or not implemented either. Google shows random information from various styles.
Sometimes lists category names, (not useful at all), sometimes shows an internal error of USw, sometimes name and part of description, mostly part of description followed by Notes. i.e. It does not work as it should.

But my note was about using the wording itself. A style author does not usually know what SEO is and does not need to. Why confuse them with it. (On https://userstyles.world/edit/### or https://userstyles.world/add/)

[vednoc]

The way the Description and Name work/do not work is a bug.

I vaguely remember discussing the idea of keeping metadata on the website in sync with metadata in the source code. IIRC, we went this way because it seemed better to give users more options. Now, it might cause a lot of problems since we have a somewhat "strict" input validation for those fields. Stylus, on the other hand, doesn't care about it. I, too, would much more prefer to have all metadata in sync. We could enforce it as a new default, but it would surely annoy some users.

But since there is also a Notes field, I don't see a reason to have them both just for the site, while having third Description, with different value, for the script.

We have those fields to preserve familiarity and compatibility with USo. Description in the source code isn't mandatory, but it's definitely useful to have it since your userstyle can be installed from anywhere. On the website, we made it mandatory some months ago as a way to improve things for bots/crawlers. BTW, how often do you change name and/or description? Personally, I set it once and forget it.

But to allow different Name values from the start, without explaining what they are for, is not an advantageous feature.

Well, it shouldn't take too long to figure out what the output of your input does since it's all displayed on a single page. I'm not entirely sure how you added your userstyle(s), which only adds up to the confusion. Regardless, I appreciate the feedback.

I did not find an option to embed a style, I guess it's just an idea for future.

It's automatically done by websites that support it. For example, check https://metatags.io/ for some examples.

Google shows random information from various styles.

I think that's just how Google works. Also, from what I see, a lot of the results haven't been updated in well over a year. Give me some keywords—especially the ones that show errors—and I'll have a closer look into them.

A style author does not usually know what SEO is and does not need to. Why confuse them with it.

That's a fair point. Then again, it's supposed to be an option for those that want to maximize their reach.

[paponius]

I'm not entirely sure how you added your userstyle(s), which only adds up to the confusion

Sorry I did not post the whole process. I kept it short, as the Subject text was enough to replicate it.
I did a Publish style from Stylus plugin.
Selected Link to a new style on a pop-up dialog window.
This will fill in Name and Description, also License fields from the metadata.
That's mostly why I expected it should be also updated when I update the style later using the same Publish button in Stylus.

The possibility to add new style is crucial, as I would never get myself to add a style, if it was a separate task. I would just postpone it forever. As I never put anything on userstyles.org, even though I planned to.
Also, as discussed in #288, it would be nice to have a tighter connection with git, or external source, as there is no good way how would an author publish a new style to git or other place.
What scheme would be used for storing it on a git or a Dropbox? How to get a popup asking for other details?

What I am trying to get to with these two Issues is to offer to an author a painless way to post quickly, so they would post a lot and often.

When I open a web page which I don't like, whether it's malformed, or too bright, and I know I will come back to that site in the future, I would try to find a Style for it.
If there is none I like, I quickly create one by getting rid of some annoying stuff, or reversing colors of the main text and the background. But then I would want to get back to reading the article, or do something on that page.
I'll do the editing right in the Stylus web editor, as I can be back to what I was doing in one minute.
The Publish button is right there in the Stylus plugin, so I have no problem pushing it and post such initial version of a style.
The default Description would be quite fitting: "A new userstyle".
But when next time I find myself more time to make it better and more usable, I would want to change the Description and also the Name.
I don't mind going to USw web page from time to time and do some overall cleaning, but I would not get myself to open an IDE, post to Git from there, then go to USw and update Description, name, screenshot every time and soon after I find out a web page did change and broke my Style.
If that would be my work-flow, I would postpone it, leaving unusable Style in the Store. And it does not take long for users to abandon a style if they can't read white text on white background.

but it would surely annoy some users.

There might be a way to have both:
On edit page for a new style, have the fields connected values with the metadata from the style code.
e.g. leave it gray with a text explaining it would be used from the CSS, or show one from the CSS and explaining it's used from CSS below the text box.
And leave a possibility to add "a custom Name/Description, specific for USw".

For existing styles, if a value is identical, show Edit style page the same way, with gray filed-in Name/Description and a possibility to add custom one.

If the Description is too long, it would have "...", if it's missing, generate one from name and target site.
Can even go "AI" and if the style has only or mostly "color" properties defined, it's a color style. White color, black background is a Dark skin.

I wouldn't even mind to have a global "share" checkbox, which would just take all styles I did not download or marked Private, publish them and keep them updated and grab a screenshot from the page for them itself.
USw would that way very quickly overgrow size and quality of styles from USo.

keywords—especially the ones that show errors—and I'll have a closer look into them

Actually I saw the mismatched results unintentionally by searching for an option to embed: https://www.google.com/search?q=embed+site%3Auserstyles.world

except those showing actual word "embed" in CSS or Notes,
most of results now show for me: Learn how we calculate statistics in the FAQ. Failed to fetch stats. Description
some start with: Failed to fetch stats., which might be old or something showed to bots only.
Before I saw one just saying: Details Statistics Description Notes
Only one from first 20 is showing content of the Description.

Thanks for the Store and the possibility to avoid the USo.