Comments on: jQuery CSS parser

By: Hacking at 0300 : jQuery CSS parser - EtondeGroup Blog of Web Applications | EtondeGroup Blog of Web Applications

Fri, 13 Jan 2012 12:39:50 +0000

[...] more here: Hacking at 0300 : jQuery CSS parser Bookmark on Delicious Digg this post Recommend on Facebook share via Reddit Share with Stumblers [...]

By: Mark

Mark — Sun, 01 May 2011 16:13:08 +0000

Thanks for looking into this. I think I have been running into caching on my server. It’s working great now.

By: Danny

Danny — Fri, 29 Apr 2011 08:13:36 +0000

@Mark:
I’m not getting any errors with jQuery 1.5.2 from the Google CDN; I just updated the demo to use the CDN and it’s working fine. Can you post a sample page using 1.5.2 (and including all the code directly rather than using head.js) and I can try to figure it out?
–Danny

By: Mark

Mark — Mon, 25 Apr 2011 15:42:53 +0000

Danny,

I recently tried to upgrade to jQuery version 1.5.2 and ran into an error (str.replace is not a function – line 163).

I have a test page working with version 1.4.4:
http://markschamel.com/projects/Atom/index.html

I’ve tried putting a local copy of 1.5.2 on my server and using Google’s CDN. Both options result in the same error.

Thanks for the great library!

By: Brian

Brian — Mon, 28 Feb 2011 21:22:20 +0000

Excellent Danny. I haven’t looked at the implementation but I assume that you would hold that rule for really any functional notation as CSS3 attributes moves forward and beyond.

Nice library.

By: Danny

Danny — Mon, 28 Feb 2011 21:06:40 +0000

@Brian: You are right about the URL; I always put the URL in quotes. Note that the W3C realize that URL's aren't consistent with the grammar as a whole and have to add the note about URIs may contain characters that would otherwise be used as delimiters…. Fixing this is straightforward if tedious: the lines in parsedeclarations of

decl = decl.split(':');
parsed[restore(decl[0])] = restore(decl[1]);

would have to replace decl[1] with decl.slice(1).join(':'). I'll get on it. --Danny

By: Brian

Brian — Mon, 28 Feb 2011 19:01:36 +0000

@Danny,

I think that that cannot be the case for functional values as even the CSS specs themselves have colons in, for example, the call to url(). See http://www.w3.org/TR/CSS21/syndata.html#uri

Yes/No?

By: Danny

Danny — Mon, 28 Feb 2011 15:48:29 +0000

@Brian: The way I'm reading it, the grammar for CSS specifies that non="identifier" characters ([-_A-Za-z0-9]) need to be escaped with backslashes, and the parser recognizes that. Try: something(foo\:bar) The parser uses split on the ':', so anything after the colon is lost if the colon is not escaped. --Danny

By: Brian

Brian — Mon, 28 Feb 2011 15:23:26 +0000

I’m trying to use just the parsscss piece of this for another purpose, not CSS, but something with CSS conforming syntax – but I’m running into a problem with the parser. My property values in this purpose occasionally contain something like (unquoted) something(foo:bar). I don’t see anything in the CSS recommendations/drafts which would disallow this, but the parser returns me only: “something(foo”.

Is it a weakness/but in the parser – or is there something in the CSS standards that I’m missing?

By: Danny

Danny — Mon, 13 Dec 2010 00:32:56 +0000

@Mark:
Looking into it more (e.g, Mozilla), the browsers claim that even an absolute URL with the protocol should be OK if it’s the same protocol and host. I remember it not working when I wrote this, but things may have changed, or I may have gotten it wrong. Anyway, try it with URL’s without the protocol and see if it works.
–Danny