css and svg element
- running jslint over some css which includes the svg element as a selector gives the warning: "Expected a tagName, and instead saw svg."
a similar thing happens for the stroke and fill attributes associated with those svg selectors - "Unrecognized style attribute 'stroke'."
i haven't checked if other svg related elements like rect have the same problem but i suspect that svg may have been overlooked.
SVG is an XML grammar. JSLint has, so far, never supported XML.
Austin Cheney - CISSP
>until recently JSLint had also not supported inspecting CSS files.
> SVG is an XML grammar. JSLint has, so far, never supported XML.
i'm not concerned about having the svg xml grammar supported - just the css. according to http://www.jslint.com/lint.html - "JSLint can inspect CSS files" and http://www.w3.org/TR/SVG/styling.html#StylingWithCSS "...shows the use of an external CSS style sheet to set the `fill' and `stroke' properties..."
will JSLint be able to inspect these CSS files which include css for svg? browsers (chrome, safari and firefox) seem to have no issue with applying the css to svg when all the css for my application has been included in a single css file. i would hate to have to separate my css into 2 files just so that i can separate out valid css rules which JSLint doesn't like.
> will JSLint be able to inspect these CSS files which include cssThis is still an XML issue. Those browser have no issue with CSS
> for svg? browsers (chrome, safari and firefox) seem to have no
> issue with applying the css to svg when all the css for my
> application has been included in a single css file.
applied to an XML file. IE can also render CSS files to XML documents
directly, but you have to supply alternate directives that escape the
colon separating a namespace. Here is an example:
In that example notice the redundancy for IE, such as:
If you really want to do cool things with CSS and dabble in XML then
just use the Jigsaw validator from W3C:
I can promise you JSLint is not going to be offering what you are
looking for any time convenient. XML has its own set of problems that
are radically foreign to the sloppy cesspool that is HTML processing.
The problems with both technologies are a direct reflection of the
behaviors most closely associated with the loudest advocates from each
group and this is not going to change until something external provides
a change in the consumer market. The only such change to ever occur for
the web were the Mosaic/Netscape and Microsoft browser wars. You can
draw your own conclusions from that.
At any rate, JSLint is not likely to support conventions of XML any more
than HTTP is to support IRI.
Austin Cheney - CISSP