Difference between revisions of "CSS Support"

From Inkscape Wiki
Jump to navigation Jump to search
(* Draw attention to "Duplicating libcroco code" on inkscape-devel)
 
(* Update now that an initial implementation is checked in.)
Line 1: Line 1:
=== Hack: Convert to style-less SVG ===
=== Current State ===
A short-term solution (hack) for style support would be an input filter that converts stylesheet-using documents to non-stylesheet-using documents.  cssanno.c (http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0001/cssanno.c or see google) does most of the work for this (for a generic XML document); the remainder of the work is to feed it a stylesheet by parsing the SVG document looking for <tt>&lt;style&gt;</tt> elements and fetching external stylesheets, and to change the outputted namespace from css: to svg:.


Ideally change <tt>add_single_property</tt> to ignore properties other than SVG ones.  I.e. add an array of names of SVG properties, and check whether <tt>name</tt> is in this list.  A linear search should be fine, I'd guess, and it's not too difficult to change it to a hash table or use a pre-coded binary search routine (whether glib or STL).
An initial implementation is now in CVS.  Limitations:


=== libcroco ===
* Allows a single <style> element in the document.  Doesn't allow external stylesheets, doesn't allow more than one <style> element.
: (Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.)


Peter Moulder is looking at using libcroco from Inkscape.
* No editing interface other than the XML editor.


There are a number of aspects of the work, some of which Peter will need help with:
: There are a number of aspects of editing:


* Modify libcroco selection stuff (cr-sel-eng.c) to allow us to use <tt>SPRepr</tt> rather than maintaining a libxml copy of the entire tree.
** The most basic level: allow editing using the XML editor.
: Done (not checked in).  The implementation is to provide a generic interface to nodes in a struct of function pointers (with names influenced by DOM).
** Editing a stylesheet.
: If we wish to, we could keep a copy of this modified cr-sel-eng.c in Inkscape, so that we can use current libcroco.
** Specifying what classes each object belongs to.
: Message posted to inkscape-devel of subject "Duplicating libcroco code in Inkscape tree" seeking concensus on how much of libcroco to put in inkscape source tree; once this has been decided, Peter will modify his local sources accordingly and then check in the current state of most or all files (so long as this doesn't break anything).  So reply to that message if you're keen to have the current work checked in as soon as possible.


* Parse <tt>&lt;style&gt;</tt> element content, gathering all rules (across possibly many <tt>&lt;style&gt;</tt> elements) into a single stylesheet.
* Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one    style for print and another style for on-screen).
: Progress so far: have a skeletal implementation of sp-style-elem.{cpp,h} that doesn't actually parse the CSS. (Not checked in.)
 
An incomplete list of work needed:


* Ensure that this single stylesheet is updated whenever any of the <tt>&lt;style&gt;</tt> elements change (or are deleted or created etc.).
* Ensure that this single stylesheet is updated whenever any of the <tt>&lt;style&gt;</tt> elements change (or are deleted or created etc.).
Line 28: Line 28:
* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty).  A non-SVG CSS example is `<tt>margin</tt>'.
* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty).  A non-SVG CSS example is `<tt>margin</tt>'.


==== Why can't we use the existing libxml interface to cr-sel-eng.c ? ====
==== Why can't we use libcroco-0.6's existing libxml interface to cr-sel-eng.c ? ====


Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.
Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Revision as of 08:29, 11 May 2005

Current State

An initial implementation is now in CVS. Limitations:

  • Allows a single <style> element in the document. Doesn't allow external stylesheets, doesn't allow more than one <style> element.
(Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.)
  • No editing interface other than the XML editor.
There are a number of aspects of editing:
    • The most basic level: allow editing using the XML editor.
    • Editing a stylesheet.
    • Specifying what classes each object belongs to.
  • Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one style for print and another style for on-screen).

An incomplete list of work needed:

  • Ensure that this single stylesheet is updated whenever any of the <style> elements change (or are deleted or created etc.).
  • Similarly, ensure that the picture is refreshed when the stylesheet is changed.
  • Modify style.cpp to query the stylesheet. (Done but not checked in.)

Why can't we use libcroco-0.6's existing libxml interface to cr-sel-eng.c ?

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N. If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree. So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree. (Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=CSS_Support&oldid=664"