rgrove / crass Goto Github PK

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Specifically, when trying to parse the string "font-family:".

I've forked and committed a breaking test and the code to fix it here: abachman@eab9b3d

The problem came up in use of the sanitize gem, when trying to sanitize email message bodies and we came across this piece of work:

<p style="font-family:" SegoeUI?,Frutiger,?FrutigerLinotype?,?DejavuSans?,?HelveticaNeue?,Tahoma,sans-serif;font-size:7.5pt;?="">blah blah blah</p>

We want to let some styles through, so we're permitting style attributes, but we don't want to let all styles through so we're limiting the allowed properties. Until we did that, parsing worked fine. I'm not sure which email editor is responsible for that nonsense, but it's breaking our ability to process data in production, which stinks.

https://gist.github.com/Fustrate/c0134c4074d11c7146e7c3ee65cba8ce

@supports (display: flex) {
  @media screen and (min-width: 900px) {
    article {
      padding: 1rem 3rem;
    }
  }
}

With nested at_rules, the contents should essentially be expressed as a fresh root would be. Notice that the two at_rules are expressed differently in the tree, the first being as expected but the second being a simple_block. The actual article rule is also a simple_block instead of a style_rule.

I'm also pretty sure that what I'm working on is better expressed as a formatter than a transformer, since it turns the tree into a string instead of modifying the tree itself. Everything else is going well aside from this issue, which makes formatting the block contents a lot more complicated than it should be. There are a few tokens I'll have to do more research on (namely cdo/cdc) but I don't anticipate any other issues popping up.

Environment:
MRI Ruby 2.6.5
Crass 1.05

Real excerpt from an email sent by Outlook:

p.5e1367490fa5f06927cafe55msonormal {
  mso-style-name:5e1367490fa5f06927cafe55msonormal;
}

Test code:

require 'crass'
require 'pp'

str =  <<END
p.5e1367490fa5f06927cafe55msonormal {
  mso-style-name:5e1367490fa5f06927cafe55msonormal;
}
END

PP.pp Crass.parse str

Output:
Can't paste on github since output is > 65KB. There are some giant numbers that result from attempting to convert "5e1367490fa5f06927cafe55msonormal" into a number.

Analysis:
It appears that Crass is trying to parse these names (class name, style name) into a number. This is ending up in a giant number that results in large amounts of memory usage in the generated parse tree. Is this a bug?

Native browser support for css nesting is becoming quite widespread - https://caniuse.com/css-nesting

It appears that crass ignores nested rules. Would it be possible to support the nested syntax?

https://github.com/Fustrate/crass/commit/8345aca2a1b2224a9a94d8cfeb3e267d7c7b309c

This is the replacement (with tests) for my earlier PR on Sanitize. The idea is that Sanitize::CSS#properties would use #stringify_inline instead of #stringify. My earlier thought was to have #stringify try to detect if it was stringifying inline or stylesheet CSS, but there's never really an ambiguity to where it originally came from.

I'm not submitting it as a PR yet because I'd like to know if this is on the right path, and if there are any other tests I should write that I'm just not well versed enough in this gem to know are needed.