Reusing KHTMLs CSS parser for a KDevelop language plugin

[Milian Wolff]

On Wednesday 21 October 2009 22:38:18 Maksim Orlovich wrote:
> <snip>
> 
> > Alternatively to the above, are there maybe KHTML APIs I can use that
> > give me a low-level analysis of a given CSS file? I'd need e.g. a list of
> > rule definitions, imports, charset statements, together with line numbers
> > where they occur. That should actually be enough to build a DUChain.
> 
> That exists already --- DOM level 2 CSS is exported to C++, see the header
> files dom/css_*.h. It may not be perfect though, since CSS parsing is
>  freaky, and very much non-uniform --- pretty much every property requires
>  special parsing code to get right; and so you only get an accurate model
>  for things KHTML supports; so for example properties with other vendor
>  prefixes would not get much info. Also a lot of other implementations like
>  Gecko simply chose to ignore parts of DOM2 CSS, so some methods may not
>  have had much real-life testing..
> 
> There is no line number info, though; and I am not sure def/use is the
>  right abstraction, either --- CSS is pattern matched, after all, in a
>  fairly complex way.

The thing is, we don't really need DOM access. I mean, we want to support the 
developer _while writing the css document_. We don't know to which documents 
he applies this style. Hence DOM sounds like nothing for us.

So far I plan/hope to support def's in CSS documents. No uses. But this would 
still offer the developer lots of help, with quick navigation, outline etc. pp.

As far as I understand you, this is a no-go then. I'll copy your tokenizer, as 
that should be implementation agnostic, i.e. the tokens should be the same for 
KHTML/Gecko/WebKit, well I'll take a look.

It should at least help me get started. Maybe I can even simplify your code to 
my needs, as I potentially don't need as much as you [1], since I don't want 
to render anything. I just want a sane tokenizer (and code completion on top 
of that), and a syntax parser (for inline syntax checking). Creating a few 
definitions for document outlines and quick navigation should be trivial than.

> > Note that most of the above could be applied to other languages as well,
> >  most notably JavaScript/ECMA Script and XML/HTML/XHTML.
> 
> HTML/XML DOM is public as well. ES AST is way too tied to the
>  implementation to be made public, and getting useful dataflow for that
>  abomination of the language is borderline impossible (though I suppose
>  kdevelop can afford to be unsound?); however it may be possible to
>  abstract something via KJSAPI

JS/ES is off then, lets see if we can come up with something for that 
eventually. And regarding HTML/XML I fear the same as above is to be said.

Thanks very much for your insight.

[1]: So this would be basically a fork so I can re-use it's functionality for 
KDevelop. That should be OK with you == all KHTML devels, right? Since we have 
a completly different use-case than you.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091021/f818299c/attachment.sig>