The current version might tell you that the LessCSS-Plugin is incompatible, even if you haven’t installed it. In this case another plugin uses old code, either ignore the message if you do not use proCSSor or move the plugin aside. Next version will be not so annoying with the message window…:)
Much better w3c-Validation output
Please don’t ask how ugly the hack is, but if you use the online HTML/CSS validation (via w3c.org) the result now looks way better. Compare below.
Why is the HTML/CSS from w3c.org broken in the first place?
That’s because the online validation “uploads” your current source (just like using the browser), retrieves the HTML result from the validator and displays this HTML inside Coda. So relative links are broken and the result reminds one of viewing modern pages in Netscape Navigator 4.
What about a webservice?
There is a SOAP interface available (for the HTML validator) but when I read the first line of their documentation, I wasn’t quite convinced that using the interface is the best idea.:
"Interface applications with the Markup Validator through its experimental API. This is version 0.2, dated May 2007." …
The current SVN snapshot from CSSTidy is included. Handles especially CSS 3 much better.
Since it’s not an official release (and the last official release was in ..2007), there’s no changelog available and it might have some issues – but according to my superficial testing it seemed to be quite stable.
Bugfix for a strange bug and LessCSS
If you had problems using the proCSSor.com service (namely a strange Exception from Coda), you probably have the LessCSS-plugin installed – which is incompatible to the PHP & Web-Toolkit. You can safely uninstall the LessCSS-plugin, because a much besser solution is available (from the same developer): Less.app ».
If you’re interested in details, read on..
Together with Bryan, the (very heplful) developer of LessCSS, I was able to track down this incompatibility. Both plugins use the same framework to parse JSON-files, SBJson. But since both plugins are running in the same
space (inside Coda), they also
see their respective classes. In this case, the LessCSS-plugin used an older version with a different API. Now if I instantiate the SBJson-Framework, the wrong one (=the one from the other plugin) is used and since the API is different, the method-calls wreak havoc..
Coda developers did already anticipate that and write an error message to syslog, which I (of course) found out afterwards..
I’ll post something about LessCSS soon, it’s a very cool CSS syntax extension.
…and some inevitable small improvements/fixes of course.
Download/Feedback/whatever on the Coda PHP & Web Toolkit page ».