I guess the ideal solution would be if it “simply” detects the relevant license, then shortens it to a specific license identifier (like $GPL3 or whatever)? It’d have to skip minifying uncommon licenses/modifications of licenses and repeat them verbatim, but that’s fine because uncommon licenses are uncommon.
Some minifiers look for @license or /*! (or //! in our hypothetical case) as indicators to not remove those sorts of comments. Practically though, with Brotli compression (which should be enabled), if you have a lot of duplicate licenses, the size difference with duplicate license info should be negligible.
This is one of my biggest beefs with folks choosing SVGO over Scour because Scour will hold onto your license info by default rather than stripping it—which could easily put you in violation of Creative Commons licenses (think like folks using Font Awesome for SVG icons (don’t ever use actual font icons) that requires CC BY). SVGO calls this “editor data” for some strange reason and strips it by default and the project is deeply embedded in npm dependency chains that a lot of folks use and never (or can’t) configure.
His argument, as I understand it, is that adding // would break incorrect uses of CSS, uses which are unlikely to occur in the first place. Basically, it would float a very specific misuse CSS, which is currently contained, and with that change would be revealed to be a bug.
And avoiding that is worth holding back a feature that thousands of people want and would use? (probably a lot more)
As much as I appreciate efforts for backwards compatibility, I feel like this is going too far. It’s one thing to break intended behavior, but how is the world supposed to move forward if we have to preserve every possible misuse as well?
(Of course no one ever argued that adding new CSS attributes mean that previous uses of those attributes that had resulted in an error and had no effect, would suddenly “break” the layout by gaining functionality. But what’s the difference really?)
I don’t see what the issue is. I write multiple line comments using //. Can you not just continue writing the comment in the next line with //? The editor can probably add the // for you but even if it doesn’t, you can add it to yourself. Can’t you?
Wow, that’s actually a great reason to not add it! But it begs the question of how they can add anything else to the syntax, as theoretically anything pre-existing might break by changing the syntax.
I feel like the comment about minifiers is a bit of a non-issue as comments are generally stripped out of minified css bundles anyways
Which is often unsafely done because it can contain licensing info that needs to persist.
I guess the ideal solution would be if it “simply” detects the relevant license, then shortens it to a specific license identifier (like $GPL3 or whatever)? It’d have to skip minifying uncommon licenses/modifications of licenses and repeat them verbatim, but that’s fine because uncommon licenses are uncommon.
Some minifiers look for
@licenseor/*!(or//!in our hypothetical case) as indicators to not remove those sorts of comments. Practically though, with Brotli compression (which should be enabled), if you have a lot of duplicate licenses, the size difference with duplicate license info should be negligible.This is one of my biggest beefs with folks choosing SVGO over Scour because Scour will hold onto your license info by default rather than stripping it—which could easily put you in violation of Creative Commons licenses (think like folks using Font Awesome for SVG icons (don’t ever use actual font icons) that requires CC BY). SVGO calls this “editor data” for some strange reason and strips it by default and the project is deeply embedded in npm dependency chains that a lot of folks use and never (or can’t) configure.
Why is CSS minified anyway? Wouldn’t compression already do a good job of reducing the transfer size of CSS in transit?
True, gzipping is more effective, but in practice you still get a bit more out of doing both, but not dramatically moreso than just gzipping
https://css-tricks.com/the-difference-between-minification-and-gzipping/
His argument, as I understand it, is that adding
//would break incorrect uses of CSS, uses which are unlikely to occur in the first place. Basically, it would float a very specific misuse CSS, which is currently contained, and with that change would be revealed to be a bug.And avoiding that is worth holding back a feature that thousands of people want and would use? (probably a lot more)
As much as I appreciate efforts for backwards compatibility, I feel like this is going too far. It’s one thing to break intended behavior, but how is the world supposed to move forward if we have to preserve every possible misuse as well?
(Of course no one ever argued that adding new CSS attributes mean that previous uses of those attributes that had resulted in an error and had no effect, would suddenly “break” the layout by gaining functionality. But what’s the difference really?)
Most the times I use a // comment in other languages I end up regretting it anyway since I end up wanting to say more…
I’m so used to using an editor with cmd-/ for comment out that I don’t really pay attention to single line vs. multiline anymore.
I don’t see what the issue is. I write multiple line comments using
//. Can you not just continue writing the comment in the next line with//? The editor can probably add the//for you but even if it doesn’t, you can add it to yourself. Can’t you?Wow, that’s actually a great reason to not add it! But it begs the question of how they can add anything else to the syntax, as theoretically anything pre-existing might break by changing the syntax.