CSS Support - Revision history

Tavmjong at 12:28, 11 August 2017

2017-08-11T12:28:05Z

← Older revision		Revision as of 12:28, 11 August 2017
Line 1:		Line 1:
	~~=== Current State ===~~

	~~An initial implementation is now in SVN. Limitations:~~		Updated August 2017

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

	* No editing interface other than ~~the XML Editor~~.		Inkscape supports a single <tt><style></tt> element in the document. If there is more than one style element, Inkscape will pick one to use.

	~~: There~~ are ~~a number of aspects of editing:~~		@import is supported as of 0.93 (read-only). other @-rules are not supported.

	** The most basic level: allow editing using the XML Editor. (~~See Update section below.~~)		There is a simple style editor (Object -> Style dialog). Selectors can be added/deleted.
	** Editing a stylesheet.
	** Specifying what classes each object belongs to.

	* Doesn't respect <tt>@<rules></tt>, including…
	**<tt>@media</tt> restrictions
	** <tt>@font-face</tt>
	** <tt>@import</tt>
	** <tt>@page</tt>
	** …etc.

	==== Work Needed (incomplete list) ====		== Work Needed (incomplete list) ==

	* ~~Ensure~~ that ~~this single stylesheet~~ is ~~updated whenever any of~~ the ~~<tt><~~style~~></tt> elements change (or~~ are ~~deleted or created etc.)~~.		* As of 0.93, libcroco supports multiple style sheets in a document. Inkscape needs to change how style sheet are handled to make use of this. Currently style sheet handling is tied to style elements. This needs to be changed so that style sheet handling is tied to the document so that all style sheets are evaluated at the same time.

	* ~~Similarly, ensure that the picture is refreshed when~~ the stylesheet ~~is changed~~.		* Convert the simple user agent stylesheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to <tt>libcroco</tt> structures (perhaps by passing strings to <tt>libcroco</tt> parsing functions) and store in <tt>desktop->style_cascade</tt>.

	* Convert the simple user agent stylesheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to <tt>libcroco</tt> structures (perhaps by passing strings to <tt>libcroco</tt> parsing functions) and store in <tt>desktop->style_cascade</tt>.		* Check that all "shorthand properties" are supported.

	* ~~Modify <tt>~~style.~~cpp</tt> to query the stylesheet. (Done, but not checked in.)~~		* Improve the usability of the Style dialog so that properties can be moved back and forth between style attributes and style elements.

	* 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>'.~~		== THE REST IS OUT-OF-DATE ==

	==== Updating for changes to <tt><style></tt> content ====		==== Updating for changes to <tt><style></tt> content ====

Zearin: Small tweaks to wording, punctuation, etc.

2010-06-12T02:34:00Z

Small tweaks to wording, punctuation, etc.

← Older revision		Revision as of 02:34, 12 June 2010
Line 59:		Line 59:
	=== Implementing External Stylesheets… ===		=== Implementing External Stylesheets… ===

	External stylesheets are arguably easier to implement than internal ones: the reference to the stylesheet comes right at the beginning of the xml file before even the top-level <svg> element, so we already know all the styling stuff for <svg> as soon as we reach it. Editing may also be a bit easier, in that external stylesheets usually exist for sharing ~~the same style among~~ many documents, so there's less expectation of being able to edit the stylesheet itself.		External stylesheets are arguably easier to implement than internal ones: the reference to the stylesheet comes right at the beginning of the xml file before even the top-level <tt><svg></tt> element, so we already know all the styling stuff for <tt><svg></tt> as soon as we reach it. Editing may also be a bit easier, in that external stylesheets usually exist for sharing styles across many documents, so there's less expectation of being able to edit the stylesheet itself.

	The work of actually parsing the stylesheet once it's in memory is already done: see src/sp-style-elem.cpp:sp_style_elem_read_content.		The work of actually parsing the stylesheet once it's in memory is already done: see <tt>src/sp-style-elem.cpp:sp_style_elem_read_content</tt>.

	So for read-only support of a single external stylesheet, it may well be just a matter of looking at how we can get XML processing instructions from libxml2 (please add a reference to the relevant documentation or code here once you've looked it up, anyone), and parse the pseudo-xml-attributes (see http://www.w3.org/TR/xml-stylesheet/; note that these aren't real xml attributes that libxml2 handles, so we do the parsing ourselves — or pass the string to a separate libxml2 instance/session/parser).		So for read-only support of a single external stylesheet, it may well be just a matter of looking at how we can get XML processing instructions from libxml2 (please add a reference to the relevant documentation or code here once you've looked it up, anyone), and parse the pseudo-xml-attributes (see http://www.w3.org/TR/xml-stylesheet/; note that these aren't real xml attributes that libxml2 handles, so we do the parsing ourselves — or pass the string to a separate libxml2 instance/session/parser).

	Then get the CSS from the specified URI (presumably using the same gnome vfs stuff that we currently use for accepting URIs on the ~~commandline, though~~ we could use libcurl instead: man curl, and see the --libcurl option for producing example code!).		Then get the CSS from the specified URI (presumably using the same gnome vfs stuff that we currently use for accepting URIs from the command line…though we could use libcurl instead: man curl, and see the <tt>--libcurl</tt> option for producing example code).

	Then proceed as <tt>sp-style-elem.cpp:sp_style_elem_read_content</tt> does (presumably splitting off most of that function into a new function that takes the string as argument).		Then proceed as <tt>sp-style-elem.cpp:sp_style_elem_read_content</tt> does (presumably splitting off most of that function into a new function that takes the string as argument).

Zearin: /* Current State */

2010-06-12T02:30:35Z

Current State

← Older revision		Revision as of 02:30, 12 June 2010
Line 14:		Line 14:
	** Specifying what classes each object belongs to.		** 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).~~		* Doesn't respect <tt>@<rules></tt>, including…
			**<tt>@media</tt> restrictions
	* <tt>@~~font-face~~</tt> ~~hints are ignored.~~		** <tt>@font-face</tt>
			** <tt>@import</tt>
	* ~~Doesn't handle any other @-rules (~~<tt>@~~media~~</tt>, <tt>@import</tt>, <tt>@page</tt>~~, …)~~.		** <tt>@page</tt>
			** …etc.

	==== Work Needed (incomplete list) ====		==== Work Needed (incomplete list) ====
Line 26:		Line 27:
	* Similarly, ensure that the picture is refreshed when the stylesheet is changed.		* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

	* Convert the simple user agent ~~style sheet~~ given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to <tt>libcroco</tt> structures (perhaps by passing strings to <tt>libcroco</tt> parsing functions) and store in <tt>desktop->style_cascade</tt>.		* Convert the simple user agent stylesheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to <tt>libcroco</tt> structures (perhaps by passing strings to <tt>libcroco</tt> parsing functions) and store in <tt>desktop->style_cascade</tt>.

	* Modify <tt>style.cpp</tt> to query the stylesheet. (Done but not checked in.)		* Modify <tt>style.cpp</tt> to query the stylesheet. (Done, but not checked in.)

	* 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>'.
Line 35:		Line 36:

	'''State so far:''' Every keystroke in the XML Editor in the content of the <tt><style></tt> element gets <tt>sp_style_elem_read_content</tt> to be re-read.		'''State so far:''' Every keystroke in the XML Editor in the content of the <tt><style></tt> element gets <tt>sp_style_elem_read_content</tt> to be re-read.
	One can force an object to get the revised stylesheet info…e.g., by <Up> <Down> (forcing an update) then deleting its style attribute.		One can force an object to get the revised stylesheet info…e.g., by <Up> <Down> (forcing an update) then deleting its <tt>style</tt> attribute.
	So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
			So, one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
	Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).		Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
	One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about. ~~Whereas~~ we ~~ought to~~ remember the content of the style attribute and only replace the properties we've changed, ~~and add to if~~ necessary.		One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about.

			Instead we should remember the content of the style attribute and only replace the properties we've changed, adding only as necessary.

	One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.		One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.

Zearin: Formatting tweaks.

2010-03-15T14:06:40Z

Formatting tweaks.

Zearin: Retitled for clarity.

2009-06-10T14:00:48Z

Retitled for clarity.

← Older revision		Revision as of 14:00, 10 June 2009
Line 53:		Line 53:
	(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)		(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

	=== ~~Notes on how to implement external stylesheets~~ ===		=== Implementing External Stylesheets… ===

	External stylesheets are arguably easier to implement than internal ones: the reference to the stylesheet comes right at the beginning of the xml file before even the top-level <svg> element, so we already know all the styling stuff for <svg> as soon as we reach it. Editing may also be a bit easier, in that external stylesheets usually exist for sharing the same style among many documents, so there's less expectation of being able to edit the stylesheet itself.		External stylesheets are arguably easier to implement than internal ones: the reference to the stylesheet comes right at the beginning of the xml file before even the top-level <svg> element, so we already know all the styling stuff for <svg> as soon as we reach it. Editing may also be a bit easier, in that external stylesheets usually exist for sharing the same style among many documents, so there's less expectation of being able to edit the stylesheet itself.

Zearin: Retitled for readability

2009-06-10T13:59:38Z

Retitled for readability

← Older revision		Revision as of 13:59, 10 June 2009
Line 20:		Line 20:
	* Doesn't handle any other at-rules (<tt>@media</tt>, <tt>@import</tt>, <tt>@page</tt>, …).		* Doesn't handle any other at-rules (<tt>@media</tt>, <tt>@import</tt>, <tt>@page</tt>, …).

	==== An incomplete list ~~of work needed~~: ====		==== Work Needed (incomplete list): ====

	* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).		* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

Zearin: Added missing teletype

2009-01-10T17:50:11Z

Added missing teletype

← Older revision		Revision as of 17:50, 10 January 2009
Line 18:		Line 18:
	* <tt>@font-face</tt> hints are ignored.		* <tt>@font-face</tt> hints are ignored.

	* Doesn't handle any other at-rules (<tt>@media</tt>, <tt>@import</tt>, @page, ~~...~~).		* Doesn't handle any other at-rules (<tt>@media</tt>, <tt>@import</tt>, <tt>@page</tt>, …).

	==== An incomplete list of work needed: ====		==== An incomplete list of work needed: ====

PeterMoulder: Add information about external stylesheets

2008-01-25T05:31:28Z

Add information about external stylesheets

← Older revision		Revision as of 05:31, 25 January 2008
Line 44:		Line 44:
	Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.		Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

	==== Why can't we use libcroco-0.6's 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.
Line 52:		Line 52:
	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.		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.)		(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

			=== Notes on how to implement external stylesheets ===

			External stylesheets are arguably easier to implement than internal ones: the reference to the stylesheet comes right at the beginning of the xml file before even the top-level <svg> element, so we already know all the styling stuff for <svg> as soon as we reach it. Editing may also be a bit easier, in that external stylesheets usually exist for sharing the same style among many documents, so there's less expectation of being able to edit the stylesheet itself.

			The work of actually parsing the stylesheet once it's in memory is already done: see src/sp-style-elem.cpp:sp_style_elem_read_content.

			So for read-only support of a single external stylesheet, it may well be just a matter of looking at how we can get XML processing instructions from libxml2 (please add a reference to the relevant documentation or code here once you've looked it up, anyone), and parse the pseudo-xml-attributes (see http://www.w3.org/TR/xml-stylesheet/; note that these aren't real xml attributes that libxml2 handles, so we do the parsing ourselves — or pass the string to a separate libxml2 instance/session/parser).

			Then get the CSS from the specified URI (presumably using the same gnome vfs stuff that we currently use for accepting URIs on the commandline, though we could use libcurl instead: man curl, and see the --libcurl option for producing example code!).

			Then proceed as sp-style-elem.cpp:sp_style_elem_read_content does (presumably splitting off most of that function into a new function that takes the string as argument).

			==== Multiple stylesheets ====

			Initially, we would support only a single stylesheet, as libcroco currently doesn't support multiple stylesheets.

			If you don't want to change libcroco, then it suffices to concatenate all the stylesheets together; the only thing you lose with that approach is that any parsing errors won't have the right line number, but I believe it gives completely correct results in absence of errors in any of the stylesheets.

			The xml-stylesheet spec says that multiple external stylesheets interact the same way as in HTML; the relevant part of the HTML spec is http://www.w3.org/TR/html4/present/styles.html#h-14.3.

	[[Category:Developer Discussion]]		[[Category:Developer Discussion]]

Colin Marquardt: Reverted edits by OilIrl (Talk); changed back to last version by GigaClon

2007-04-20T15:40:57Z

Reverted edits by OilIrl (Talk); changed back to last version by GigaClon

← Older revision		Revision as of 15:40, 20 April 2007
Line 22:		Line 22:
	==== An incomplete list of work needed: ====		==== An incomplete list of work needed: ====

	* Ensure that this single stylesheet is updated whenever any of the <tt>		* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

			* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

			* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

			* Modify style.cpp to query the stylesheet. (Done but not checked in.)

			* 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>'.

			==== Updating for changes to <style> content ====

			State so far: Every keystroke in the xml editor in the content of the <style> element gets sp_style_elem_read_content to be re-read.
			One can force an object to get the revised stylesheet info by e.g. <Up> <Down> (forcing an update) then deleting its style attribute.
			So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
			Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
			One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about. Whereas we ought to remember the content of the style attribute and only replace the properties we've changed, and add to if necessary.

			One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.
			Apart from not writing if src==stylesheet, we can also avoid writing if src==attribute: i.e. don't gratuitously break SVG Tiny conformance of a document (or more generally break compatibility with implementations that don't honour CSS <tt>style</tt> attributes).
			Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

			==== 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.)

			[[Category:Developer Discussion]]

OilIrl at 01:47, 18 April 2007

2007-04-18T01:47:33Z

← Older revision		Revision as of 01:47, 18 April 2007
Line 22:		Line 22:
	==== An incomplete list of work needed: ====		==== An incomplete list of work needed: ====

	* Ensure that this single stylesheet is updated whenever any of the <tt>~~<style></tt> elements change (or are deleted or created etc.).~~		* Ensure that this single stylesheet is updated whenever any of the <tt>

	* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

	* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

	* Modify style.cpp to query the stylesheet. (Done but not checked in.)

	* 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>'.

	~~==== Updating for changes to <style> content ====~~

	~~State so far: Every keystroke in the xml editor in the content of the <style> element gets sp_style_elem_read_content to be re-read.~~
	~~One can force an object to get the revised stylesheet info by e.g. <Up> <Down> (forcing an update) then deleting its style attribute.~~
	~~So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.~~
	Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
	One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about. Whereas we ought to remember the content of the style attribute and only replace the properties we've changed, and add to if necessary.

	~~One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.~~
	Apart from not writing if src==stylesheet, we can also avoid writing if src==attribute: i.e. don't gratuitously break SVG Tiny conformance of a document (or more generally break compatibility with implementations that don't honour CSS <tt>style</tt> attributes).
	Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

	~~==== 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.)~~

	~~[[Category:Developer Discussion]]~~

← Older revision		Revision as of 14:06, 15 March 2010
Line 3:		Line 3:
	An initial implementation is now in SVN. Limitations:		An initial implementation is now in SVN. Limitations:

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

	* No editing interface other than the XML ~~editor~~.		* No editing interface other than the XML Editor.

	: There are a number of aspects of editing:		: There are a number of aspects of editing:

	** The most basic level: allow editing using the XML ~~editor~~. (See Update section below.)		** The most basic level: allow editing using the XML Editor. (See Update section below.)
	** Editing a stylesheet.		** Editing a stylesheet.
	** Specifying what classes each object belongs to.		** Specifying what classes each object belongs to.
Line 18:		Line 18:
	* <tt>@font-face</tt> hints are ignored.		* <tt>@font-face</tt> hints are ignored.

	* Doesn't handle any other at-rules (<tt>@media</tt>, <tt>@import</tt>, <tt>@page</tt>, …).		* Doesn't handle any other @-rules (<tt>@media</tt>, <tt>@import</tt>, <tt>@page</tt>, …).

	==== Work Needed (incomplete list): ====		==== Work Needed (incomplete list) ====

	* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).		* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).
Line 26:		Line 26:
	* Similarly, ensure that the picture is refreshed when the stylesheet is changed.		* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

	* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.		* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to <tt>libcroco</tt> structures (perhaps by passing strings to <tt>libcroco</tt> parsing functions) and store in <tt>desktop->style_cascade</tt>.

	* Modify style.cpp to query the stylesheet. (Done but not checked in.)		* Modify <tt>style.cpp</tt> to query the stylesheet. (Done but not checked in.)

	* 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>'.

	==== Updating for changes to <style> content ====		==== Updating for changes to <tt><style></tt> content ====

	State so far: Every keystroke in the ~~xml editor~~ in the content of the <style> element gets sp_style_elem_read_content to be re-read.		'''State so far:''' Every keystroke in the XML Editor in the content of the <tt><style></tt> element gets <tt>sp_style_elem_read_content</tt> to be re-read.
	One can force an object to get the revised stylesheet ~~info by e~~.g. <Up> <Down> (forcing an update) then deleting its style attribute.		One can force an object to get the revised stylesheet info…e.g., by <Up> <Down> (forcing an update) then deleting its style attribute.
	So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.		So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
	Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).		Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
Line 44:		Line 44:
	Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.		Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

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

	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 <tt>libxml</tt> form if we want to use <tt>libcroco</tt> 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.		Suppose we want to find the style of node N. We pass <tt>libcroco</tt> 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.		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 <tt>libcroco</tt> 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.		So we can't pass <tt>libcroco</tt> just a <tt>libxml</tt> version of node N, we need to fill in its parent and sibling links, providing a <tt>libxml</tt> 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.)		(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

Line 63:		Line 63:
	Then get the CSS from the specified URI (presumably using the same gnome vfs stuff that we currently use for accepting URIs on the commandline, though we could use libcurl instead: man curl, and see the --libcurl option for producing example code!).		Then get the CSS from the specified URI (presumably using the same gnome vfs stuff that we currently use for accepting URIs on the commandline, though we could use libcurl instead: man curl, and see the --libcurl option for producing example code!).

	Then proceed as sp-style-elem.cpp:sp_style_elem_read_content does (presumably splitting off most of that function into a new function that takes the string as argument).		Then proceed as <tt>sp-style-elem.cpp:sp_style_elem_read_content</tt> does (presumably splitting off most of that function into a new function that takes the string as argument).

	==== Multiple stylesheets ====		==== Multiple stylesheets ====

	Initially, we would support only a single stylesheet, as libcroco currently doesn't support multiple stylesheets.		Initially, we would support only a single stylesheet, as <tt>libcroco</tt> currently doesn't support multiple stylesheets.

	If you don't want to change libcroco, then it suffices to concatenate all the stylesheets together; the only thing you lose with that approach is that any parsing errors won't have the right line number, but I believe it gives completely correct results in absence of errors in any of the stylesheets.		If you don't want to change libcroco, then it suffices to concatenate all the stylesheets together; the only thing you lose with that approach is that any parsing errors won't have the right line number, but I believe it gives completely correct results in absence of errors in any of the stylesheets.