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

Re: CSS

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.