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

CSS linting bugs.

Expand Messages
  • Mike West
    Two small issues popped up recently in my code that would probably be worth taking a look at: 1. `last-child` isn t recognized as a pseudoclass. Adding it to
    Message 1 of 9 , Oct 4, 2010
    View Source
    • 0 Attachment
      Two small issues popped up recently in my code that would probably be
      worth taking a look at:

      1. `last-child` isn't recognized as a pseudoclass. Adding it to the
      list after line 3416 in the 2010-10-01 build fixes the issue.

      2. Ranges aren't processed correctly. The following CSS code
      produces a JavaScript error ( "Problem at line 4 character 17: Object
      prototype may only be an Object or null" ) on http://jslint.com/

      @charset "UTF-8";

      div {
      background: url("/path/to/thing.jpg");
      }

      I traced it down to a `(range)` syntax not being defined. Copying
      the `(string)` syntax seems to work correctly.

      Thanks!

      -Mike
    • Douglas Crockford
      ... Thanks. Please try it now.
      Message 2 of 9 , Oct 6, 2010
      View Source
      • 0 Attachment
        --- In jslint_com@yahoogroups.com, Mike West <mike@...> wrote:

        > Two small issues popped up recently in my code that would probably be
        > worth taking a look at:
        >
        > 1. `last-child` isn't recognized as a pseudoclass.
        >
        > 2. Ranges aren't processed correctly.
        >
        > @charset "UTF-8";
        >
        > div {
        > background: url("/path/to/thing.jpg");
        > }

        Thanks. Please try it now.
      • Mike West
        ... Thank you, the fixes work correctly. -Mike
        Message 3 of 9 , Oct 6, 2010
        View Source
        • 0 Attachment
          On Wed, Oct 6, 2010 at 6:23 PM, Douglas Crockford <douglas@...> wrote:

          > Thanks. Please try it now.

          Thank you, the fixes work correctly.

          -Mike
        • Tim Beadle
          While we re on the subject of linting CSS, it seems that JSLint does not like our preferred house style of upper-case element selectors ( A , not a etc.).
          Message 4 of 9 , Oct 8, 2010
          View Source
          • 0 Attachment
            While we're on the subject of linting CSS, it seems that JSLint does
            not like our preferred house style of upper-case element selectors
            ('A', not 'a' etc.).

            Being new to linting CSS, is there an option I can set to get round
            this, or is lower-case required?

            Thanks,

            Tim
          • Douglas Crockford
            ... Is there a good reason for your house style? If there is, I will consider it.
            Message 5 of 9 , Oct 10, 2010
            View Source
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, Tim Beadle <tim.beadle@...> wrote:
              >
              > While we're on the subject of linting CSS, it seems that JSLint does
              > not like our preferred house style of upper-case element selectors
              > ('A', not 'a' etc.).
              >
              > Being new to linting CSS, is there an option I can set to get round
              > this, or is lower-case required?

              Is there a good reason for your house style? If there is, I will consider it.
            • Tim Beadle
              ... I hadn t encountered the uppercase-element selector style before I joined my current employer. I ve been writing CSS since its early days, and actually
              Message 6 of 9 , Oct 11, 2010
              View Source
              • 0 Attachment
                On 10 October 2010 12:46, Douglas Crockford <douglas@...> wrote:
                > Is there a good reason for your house style? If there is, I will consider it.

                I hadn't encountered the uppercase-element selector style before I
                joined my current employer. I've been writing CSS since its early
                days, and actually prefer this style now.

                I think the advantage it gives, when scanning CSS rules, is an easy
                visual distinction between elements in selectors vs class names, IDs
                and other selector syntax. We also use this style in our jQuery
                selectors, with the same result.

                E.g.

                SELECT, INPUT.text { ... }

                Best regards,

                Tim
              • Cheney, Edward A SSG RES USAR
                Tim, That is dangerous. Unlike HTML 4.01, and below, CSS and JavaScript are both case sensitive. Every release of HTML after 4.01 is case sensitive with half
                Message 7 of 9 , Oct 11, 2010
                View Source
                • 0 Attachment
                  Tim,

                  That is dangerous. Unlike HTML 4.01, and below, CSS and JavaScript are both case sensitive. Every release of HTML after 4.01 is case sensitive with half exception to the unfinished HTML5. That said your code is not extensible or reusable outside your current architecture by any of your partners or your own organization. I suggest this be kept in mind when you code fails to process in a partner's XHTML 1.0 strict environment and your code has to be rewritten from scratch after cost decisions are written into your contracts.

                  Austin Cheney, CISSP
                  http://prettydiff.com/

                  ----- Original Message -----
                  From: Tim Beadle <tim.beadle@...>
                  Date: Monday, October 11, 2010 5:09
                  Subject: Re: [jslint] Re: CSS linting bugs.
                  To: jslint_com@yahoogroups.com


                  > On 10 October 2010 12:46, Douglas Crockford < wrote:
                  > > Is there a good reason for your house style? If there is, I will consider it.
                  >
                  > I hadn't encountered the uppercase-element selector style before I
                  > joined my current employer. I've been writing CSS since its early
                  > days, and actually prefer this style now.
                  >
                  > I think the advantage it gives, when scanning CSS rules, is an easy
                  > visual distinction between elements in selectors vs class names, IDs
                  > and other selector syntax. We also use this style in our jQuery
                  > selectors, with the same result.
                  >
                  > E.g.
                  >
                  > SELECT, INPUT.text { ... }
                  >
                  > Best regards,
                  >
                  > Tim
                • Tim Beadle
                  On 11 October 2010 19:34, Cheney, Edward A SSG RES USAR ... Austin, Thanks for the feedback. You re right in that case-sensitivity is an issue (something I
                  Message 8 of 9 , Oct 12, 2010
                  View Source
                  • 0 Attachment
                    On 11 October 2010 19:34, Cheney, Edward A SSG RES USAR
                    <austin.cheney@...> wrote:
                    > That is dangerous. Unlike HTML 4.01, and below, CSS and JavaScript are both case sensitive. Every release of HTML after 4.01 is case sensitive with half exception to the unfinished HTML5. That said your code is not extensible or reusable outside your current architecture by any of your partners or your own organization.

                    Austin,

                    Thanks for the feedback. You're right in that case-sensitivity is an
                    issue (something I hadn't considered for element names, though I
                    already knew of the issue with regard to classes and IDs.
                    http://reference.sitepoint.com/css/casesensitivity

                    > I suggest this be kept in mind when you code fails to process in a partner's XHTML
                    > 1.0 strict environment

                    Since we're already using XHTML 1.0 Strict (albeit sent as text/html),
                    and our CSS works, could it be that it's only when sending XHTML as
                    application/xhtml+xml that this case-sensitivity is encountered?

                    > and your code has to be rewritten from scratch after cost
                    > decisions are written into your contracts.

                    "Rewritten from scratch"? How about (for each HTML element
                    name).replace(Lowercase replacement) ?

                    Tim
                  • Cheney, Edward A SSG RES USAR
                    Tim, ... Common misconception. It does not help that people form an opinion on this matter and become emotionally invested without doing some independent
                    Message 9 of 9 , Oct 12, 2010
                    View Source
                    • 0 Attachment
                      Tim,

                      > Since we're already using XHTML 1.0 Strict (albeit sent as text/html),
                      > and our CSS works, could it be that it's only when sending XHTML as
                      > application/xhtml+xml that this case-sensitivity is encountered?

                      Common misconception. It does not help that people form an opinion on this matter and become emotionally invested without doing some independent scrutiny of the W3C publications. It is because of this that there is a good deal of incorrect information about this subject online. The root cause of this confusion is actually the W3C, though, since this is stated but not in any matter that is prominent.

                      http://www.w3.org/TR/xhtml1/#media
                      http://www.w3.org/TR/xhtml1/#guidelines

                      According to the standards XHTML 1.0 is intended to be a transitional technology between SGML and XML even though this is not explicitly stated. Knowledge of intentions in complex standards must never be presumed. I do mean all of XHTML 1.0 in intended to be transitional. The standards go further to describe degrees of flexibility by supporting three doctypes to represent the amount of toleration in reaching accuracy towards the XHTML vocabulary and syntax changes. The first of the two links above state in the XHTML 1.0 specification that documents may be labeled with the type "text/html". This means that sending XHTML 1.0 strict as text/html is valid in accordance with the XHTML 1.0 specification.

                      In order to create a flavor of (x)HTML that is not transitional and not open to confusion the W3C created XHTML 1.1. XHTML 1.1 is the only finished specification of HTML that requires the use of an XML related mime type: application/xhtml+xml.

                      In the case of your use of CSS with HTML there is transparent processing variance that you mean not be accounting for. HTML has been pretty standard and its standard support has been pretty universal since before IE6, possibly before IE5, and in these late modern years CSS processing is pretty standard across the board as well.

                      Unfortunately, this is not the case for the DOM, which is the glue of the web. DOM interpretation varies wildly between various user-agent applications. It is this variance that accounts for most cross browser issues associated with CSS syntax and JavaScript access to features of a marked up document. There are valid reasons for this variance since the DOM specification was created by the W3C for accessing the XML tree and revised it as an after thought for HTML. Unlike the syntax for XML the user-agent applications are expected to allow a massive wide distribution of sloppiness and failure when processing HTML, which makes the DOM difficult to interpret. The more a user-agent bends over backwards to give flexibility to HTML processing the smarter their DOM interpreter must be in order to meet the most minimum of expectations.

                      In summary don't expect things that pass through the DOM to reflect any level of accreditation or standards compliance conduct and flavors of XHTML 1.0 can be sent correctly as text/html.
                    Your message has been successfully submitted and would be delivered to recipients shortly.