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

Re: [jslint] Re: CSS linting bugs.

Expand Messages
  • 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 1 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 2 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.