Skip to content

Proposal: new and better UserStyle metadata block #821

@ACTCD

Description

@ACTCD

I know I've raised:

But I could still see the value of writing CSS code directly instead of wrapping it in .user.js:

  • Better syntax highlighting
  • CSS linting
  • Simpler and more straightforward
  • Directly utilize the relevant extension APIs

From my knowledge, some of the issues currently faced by UserStyle ecology:

  • Lack of true standardization and widespread adoption
  • The @match *://*/* conflict in metadata comment
  • Deprecated @-moz-document syntax

I hope it does:

  • Based on .css files instead of individual apps internal format
  • Use extension API registration only once for each single file
  • No complex splitting and parsing and acts like a normal css file (or userjs)
  • Accepted by most common editors with no errors
  • Proper syntax highlighting and markdown rendering (Like the following example)
  • The UserStyle metadata easy to write and parse within the file
  • Prefer match patterns over other matching rules (Safer and API friendly)
  • Not confusing and conflicting with various existing implementations

Evolution:

  • Using CSS comments becomes impractical due to the @match *://*/* conflict.
  • Using the @metadata liked At-rules is prone to linting errors
  • So a fairly straightforward idea would be to utilize the existing CSS syntax
  • It is quite compatible and meets all of the above considerations
  • This metadata ruleset will be parsed and stripped by the manager
  • Use Custom properties for metadata names to avoid linting errors

The following is a simple sample, for further improvement and standardization:

Existing one in the userscripts:

/* ==UserStyle==
@name        NewStyle-aefwe6zy
@description This is your new file, start writing code
@match       <all_urls>
@match       *://*/*
@match       *://*.foo.bar/*
==/UserStyle== */

body { color: red; }

New proposed:

userstyle-metadata {
	--name: "NewStyle-aefwe6zy";
	--description: "This is your new file, start writing code";
	--match: "<all_urls>";
	--match-2: "*://*/*";
	--match-3: "*://*.foo.bar/*";
	--version: "1.0.0";
	--download-url: "https://foo.bar/foo.user.css";
}

body { color: red; }

Footnotes: To avoid lint error like Unexpected duplicate "--match" (declaration-block-no-duplicate-custom-properties), metadata such as @match which can be declared repeatedly, can have any trailing suffix and will eventually be parsed as an array by the manager.

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions