Loading ...
Sorry, an error occurred while loading the content.

CSS

Expand Messages
  • Douglas Crockford
    JSLint can now check CSS files. CSS files are required to have this as the first line: @charset UTF-8 ; JSLint s CSS checking is not yet complete, but it will
    Message 1 of 11 , Sep 18 4:18 PM
    • 0 Attachment
      JSLint can now check CSS files. CSS files are required to have this as
      the first line:

      @charset "UTF-8";

      JSLint's CSS checking is not yet complete, but it will catch a lot of
      stuff. Please let me know if you see it catching on stuff that is good.

      A dilemma for a lint program is that there are some bad practices that
      have become standard because of weaknesses in CSS and its
      implementations. How fussy can/should a CSS lint be?

      The motivation for looking at CSS is that it is implicated in XSS
      attacks. Improving the security of CSS will require improving its hygiene.
    • Jordan
      First thing I noticed checking a CSS file... CSS comments aren t recognized. I had this style block: @charset UTF-8 ; body { margin: 0; background: #F2F2F2
      Message 2 of 11 , Sep 18 8:34 PM
      • 0 Attachment
        First thing I noticed checking a CSS file... CSS comments aren't
        recognized. I had this style block:
        @charset "UTF-8";
        body {
        margin: 0;
        background: #F2F2F2 url(/images/background.gif) center top repeat-y;
        /* overflow-x: auto; */
        overflow-y: scroll;
        #overflow-y: none;
        #overflow: none;
        font-size:13px;
        }

        And it didn't recognize line 5 as being a comment, rather it saw an error.
        Also, a CSS lint should recognize, and allow or reject via option,
        browser-specific hacks. For example, IE hacks like #overflow (where
        Firefox ignores the hashed directive but IE uses it).

        --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
        wrote:
        >
        > JSLint can now check CSS files. CSS files are required to have this as
        > the first line:
        >
        > @charset "UTF-8";
        >
        > JSLint's CSS checking is not yet complete, but it will catch a lot of
        > stuff. Please let me know if you see it catching on stuff that is good.
        >
        > A dilemma for a lint program is that there are some bad practices that
        > have become standard because of weaknesses in CSS and its
        > implementations. How fussy can/should a CSS lint be?
        >
        > The motivation for looking at CSS is that it is implicated in XSS
        > attacks. Improving the security of CSS will require improving its
        hygiene.
        >
      • Douglas Crockford
        ... error. JSLint will reject comments within {} because of security concerns. The error messages will get better. ... Thanks. That s the kind of advice I ll
        Message 3 of 11 , Sep 18 8:58 PM
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, "Jordan" <ljharb@...> wrote:
          >
          > First thing I noticed checking a CSS file... CSS comments aren't
          > recognized.

          > And it didn't recognize line 5 as being a comment, rather it saw an
          error.

          JSLint will reject comments within {} because of security concerns.
          The error messages will get better.

          > Also, a CSS lint should recognize, and allow or reject via option,
          > browser-specific hacks. For example, IE hacks like #overflow (where
          > Firefox ignores the hashed directive but IE uses it).

          Thanks. That's the kind of advice I'll looking for.
        • Klemen Slavič
          It would be nice (I can dream, can I) to have a list of browser-specific hacks, like # and _ prefix with suggestions on how to substitute those with better
          Message 4 of 11 , Sep 18 10:59 PM
          • 0 Attachment
            It would be nice (I can dream, can I) to have a list of browser-specific
            hacks, like # and _ prefix with suggestions on how to substitute those with
            better ones. It would also be nice to warn against using vendor-specific
            properties (like the -moz-* properties and such) or selectors that fail in
            given browsers (like the :hover pseudo element which only works under
            certain conditions when not applied to a elements).

            I'm currently in the process of releasing an alpha version of this script
            which uses the computed style of elements to determine which elements will
            render quirky based on the CSS signature. It will also try to match up any
            rules found in CSS <link> and <style> to try and suggest better approaches
            to known problems. It uses a standalone module which could be reused to plug
            into other applications, like JSlint, to provide a set of profiles that
            match common problems like these. To note, it currently uses jQuery to
            provide cross-browser functioning, but will later be refactored to use just
            the selector engine and a custom style querying module so as to maximize the
            chances of correct quirks detection without normalization.

            Cheers,

            -Klmn


            [Non-text portions of this message have been removed]
          • Harry Whitfield
            ... // jslint.js // 2008-09-18 JSLint Function Report for fulljslint.js Fri, 19 Sep 2008 08:15:46 GMT Error: Problem at line 92 character 13: Expected an
            Message 5 of 11 , Sep 19 1:19 AM
            • 0 Attachment
              On 19 Sep 2008, at 00:18:37, Douglas Crockford wrote:

              > JSLint can now check CSS files. CSS files are required to have this as
              > the first line:
              >
              > @charset "UTF-8";
              >

              // jslint.js
              // 2008-09-18
              JSLint Function Report for fulljslint.js

              Fri, 19 Sep 2008 08:15:46 GMT

              Error:
              Problem at line 92 character 13: Expected an identifier and instead
              saw 'import' (a reserved word).
              import : true,

              Problem at line 2255 character 24: Missing semicolon.

              return ''
            • Jordan
              ... I may or may not be running a CSS lint for solely security concerns - rejecting or ignoring comments should be an option.
              Message 6 of 11 , Sep 19 11:17 AM
              • 0 Attachment
                --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
                wrote:

                > JSLint will reject comments within {} because of security concerns.
                > The error messages will get better.

                I may or may not be running a CSS lint for solely security concerns -
                rejecting or ignoring comments should be an option.
              • Douglas Crockford
                ... It is because of that kind of thinking that CSS has become a general security vulnerability.
                Message 7 of 11 , Sep 19 12:39 PM
                • 0 Attachment
                  --- In jslint_com@yahoogroups.com, "Jordan" <ljharb@...> wrote:

                  > > JSLint will reject comments within {} because of security concerns.

                  > I may or may not be running a CSS lint for solely security concerns -
                  > rejecting or ignoring comments should be an option.

                  It is because of that kind of thinking that CSS has become a general
                  security vulnerability.
                • Douglas Crockford
                  I have added CSS2 support to JSLint. This was motivated by the security needs of ADsafe. Only by fully parsing the CSS content on a page can we be confident
                  Message 8 of 11 , Oct 6, 2008
                  • 0 Attachment
                    I have added CSS2 support to JSLint. This was motivated by the
                    security needs of ADsafe. Only by fully parsing the CSS content on a
                    page can we be confident that the CSS does not contain hidden script.

                    CSS, unlike JavaScript, does not appear to include a usefully
                    sufficient "good parts" subset. The most common patterns necessarily
                    go the other way, extending CSS with horrible, browser-specific
                    workarounds.

                    JSLint now has a 'css' option which will suppress some of the warnings
                    that are generated by the use of these workarounds.

                    I expect it will take a while to fully conform JSLint to the reality
                    of CSS. Your patience is appreciated.
                  • Jordan
                    In case you were looking for workaround suggestions, a # immediately preceding a property is ignored by IE but not by Firefox. - it would be nice if when
                    Message 9 of 11 , Oct 7, 2008
                    • 0 Attachment
                      In case you were looking for workaround suggestions, a # immediately
                      preceding a property is ignored by IE but not by Firefox.
                      - it would be nice if when throwing an error on a property like
                      "overflow-y" if there was an error message that indicated which
                      browsers it works with.
                      - "cursor: alias !important" gives errors on "alias" which works in
                      Firefox ( http://webdesign.about.com/od/styleproperties/a/aa060607.htm
                      ). This throws an error on "!important", but since the importance
                      works fine on other lines, I assume the "alias" is messing it up.
                      - "font-variant: small-caps;" isn't valid?
                      - "blue { color: #003399 !important; }" throws an error because I
                      invented my own tag name, ie <blue>text</blue>. This is invalid XHTML
                      I know, but why is it invalid CSS?
                      - "background:#FFFFFF none repeat scroll 0%;" the % throws an error.
                      Are percentages invalid?
                      - "opacity: 0.92;" opacity works in Firefox, and "filter:
                      alpha(opacity=92);" works in IE ( http://www.codeave.com/CSS/code.asp?
                      u_log=4017 describes the two, plus that in IE elements must be
                      positioned to have the filter)

                      I know these are all browser hacks, but I'd love to hear your
                      thoughts.

                      --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
                      wrote:
                      >
                      > I have added CSS2 support to JSLint. This was motivated by the
                      > security needs of ADsafe. Only by fully parsing the CSS content on a
                      > page can we be confident that the CSS does not contain hidden
                      script.
                      >
                      > CSS, unlike JavaScript, does not appear to include a usefully
                      > sufficient "good parts" subset. The most common patterns necessarily
                      > go the other way, extending CSS with horrible, browser-specific
                      > workarounds.
                      >
                      > JSLint now has a 'css' option which will suppress some of the
                      warnings
                      > that are generated by the use of these workarounds.
                      >
                      > I expect it will take a while to fully conform JSLint to the reality
                      > of CSS. Your patience is appreciated.
                      >
                    • Douglas Crockford
                      ... I feel like I ve opened a can of worms. I m not confident that a Code Quality tool makes sense for CSS. The fact that a form is tolerated by only one brand
                      Message 10 of 11 , Oct 7, 2008
                      • 0 Attachment
                        --- In jslint_com@yahoogroups.com, "Jordan" <ljharb@...> wrote:
                        > I know these are all browser hacks, but I'd love to hear your
                        > thoughts.

                        I feel like I've opened a can of worms. I'm not confident that a Code
                        Quality tool makes sense for CSS. The fact that a form is tolerated by
                        only one brand of browser should indicate that the form should be
                        avoided. But for CSS, it becomes a best practice.
                      • Jordan
                        ... Code ... by ... Very good point... the problem is that in Javascript, functionality in forms that should be avoided can be accomplished a variety of
                        Message 11 of 11 , Oct 7, 2008
                        • 0 Attachment
                          --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
                          wrote:
                          >
                          > --- In jslint_com@yahoogroups.com, "Jordan" <ljharb@> wrote:
                          > > I know these are all browser hacks, but I'd love to hear your
                          > > thoughts.
                          >
                          > I feel like I've opened a can of worms. I'm not confident that a
                          Code
                          > Quality tool makes sense for CSS. The fact that a form is tolerated
                          by
                          > only one brand of browser should indicate that the form should be
                          > avoided. But for CSS, it becomes a best practice.
                          >

                          Very good point... the problem is that in Javascript, functionality in
                          "forms that should be avoided" can be accomplished a variety of ways.
                          In CSS, quite a lot of functionality can only be accessed with those
                          deprecated forms.

                          While I'm also not confident that a code quality tool makes sense, a
                          tool that checks CSS for validity based on a subset of browsers, and
                          reports which features work for which browsers, and eases creating
                          browser hacks, would be very useful. Also, anytime validators/lints
                          exist, I run them on my code fanatically.
                        Your message has been successfully submitted and would be delivered to recipients shortly.