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

Re: CSS

Expand Messages
  • 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 1 of 11 , Sep 18, 2008
    • 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 2 of 11 , Sep 18, 2008
      • 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 3 of 11 , Sep 18, 2008
        • 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 4 of 11 , Sep 19, 2008
          • 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 5 of 11 , Sep 19, 2008
            • 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 6 of 11 , Sep 19, 2008
              • 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 7 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 8 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 9 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 10 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.