-
Notifications
You must be signed in to change notification settings - Fork 299
Open
1 / 21 of 2 issues completedDescription
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
likedAt-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
Labels
No labels