- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 2 Jan 2004 02:40:39 +0000 (UTC)
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: www-style@w3.org
On Fri, 2 Jan 2004, Bjoern Hoehrmann wrote: >> >> Could you be more specific? DOM2 CSS does satisfy what you describe, > > I gave some examples... By "more specific" I meant "what specific requirements do you have", preferably down to the detailed level of "I'd like to be able to walk blocks, selectors, comments, identifiers, and so forth". (Much like you included below -- thanks.) > Say I want to write a general purpose CSS pretty printer based on DOM > Level 2 CSS. Why would you do that? That's a bit like saying "Say I want to write an IRC client using the libpng library". Why choose the API first? The reason I ask this is that if you are writing an application, it seems to make more sense to decide what your requirements are, then decide what ou want to implement it with -- in the case of a pretty printer, a DOM API is almost certainly not the right choice since DOMs do not model the source, but the semantics. > However, to make a start, I need a Selector API that > > * is at least as sophisticated as [3] > * is forward-compatible in a usable manner > * includes support for CSS Level 3 Selectors > * allows to query for the selectors specifity > * provides access to comments as in e.g. a/**/b {...} > * allows to query pseudo classes, attribute selectors, and > pseudo elements for their associated element type selector > > [3] http://www.w3.org/Style/CSS/SAC/doc/org/w3c/css/sac/Selector.html This seems highly detailed knowledge; are you expecting to deploy your applications in Web browsers? Or are these applications expected to run in environments that can host custom libraries (such as Web servers or C++ applications that are shipped in binary or source form)? I ask because if you have control over the library, it makes no sense to limit yourself to W3C APIs -- interoperability at that level is not required. For example, Web browsers are not built using W3C DOM APIs internally; they have custom APIs that are optimised for their use, and then expose DOM APIs for interoperability with other UAs so that they can execute content from many pages. Anyway. We are currently working on two specs, an Editing CSS OM and a more Web-orientated CSS OM. Your requirements appear to be more of the kind the Editing OM is addressing, so I'll pass on your requirements to the editor of that spec. (I'm trying to look for the requirements that generic Web pages not specifically implementing CSS authoring tools need, rather than the editing APIs.) -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 1 January 2004 21:46:15 UTC