User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050721 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050921 SeaMonkey/1.0a
Seamonkey and Deer Park: Marker were shown correctly in build 2005072109
Markers are not displayed, when styles read from style file,
but they are o.k., when styles are written inline using style tag
Steps to Reproduce:
1.load .xml-File markerKO.xml and style file from appendix
2.start should give a red line without markers at begin and end, when using an
3.( markerOk.xml is showing same styles, but inline; markers are shown. )
red line without markers
red line with markers at begin and end
one or more heavier problems with builds after 20050721 will follow, when prepared
(resulting in finding svg:svg as target)
(third dwnload file markerOk.xml will show correct behavior.
All Files are downloaded as text files, because of irritating bugzilla behavior
showing only style of an xml-file)
Created attachment 197025 [details]
.xml-file error provoking together with style file (next att.)
to be used together with style file (next att.)
Created attachment 197026 [details]
.css-file (sent as text)
to be used with former att.
Created attachment 197028 [details]
same styles, but inline - working correctly
(only to show the difference)
Created attachment 197063 [details]
Testcase1, not working from external style
In order to create modular style sheets that are not dependent on the absolute
location of a resource, authors may use relative URIs. Relative URIs (as defined
in [RFC3986]) are resolved to full URIs using a base URI. RFC 3986, section 5,
defines the normative algorithm for this process. For CSS style sheets, the base
URI is that of the style sheet, not that of the source document.
So I think what currently is happening is correct.
(In reply to comment #5)
> Relative URIs (.. RFC 3986, section 5,
> defines the normative algorithm for this process.
> For CSS style sheets, the base
> URI is that of the style sheet, not that of the source document.
RFC 3986 and the CSS style URI are looking indeed as:
"for local references in a style sheet, the base URI is this style sheet"
But RFC 3986 was thoroughly thaught to make it possible to make local
references, not to make them impossible, and the statement seems to be stated
for the usual "forward" references to further CSS.
It seems, that nobody thaught about the consequences of the very new aspect
created by local "back" references from CSS to XML generated by SVG.
Marker references are always references to XML and never to CSS, it therefore
would be impossible to make "local references" to a marker in an external style
sheet in contradictio to make them possible, strictly yielding to making
css-files which are not usable for mor than one XML-source.
Therefore it should be a solvable problem to
- clear the standardization situation
- set a proper XML URI instead of an impossible marker reference to CSS
I think, it's a question of "name space" (belonging to CSS <--> belonging to
XML), and have sent a message to firstname.lastname@example.org ..
(copy of message to email@example.com ..)
The reference from CSS to a marker seems to be problematic, there should be an
explicit statement in the SVG and/or CSS standards ( see my error message
After a change in Mozilla SVG a local reference like
marker-end: url(#dartZ); marker-start: url(#CtrlPoint);
is not evaluated to point to the SVG/XML-file, when it is given in an external
style sheet, but to nowhere in the CSS-file
The developer is saying, that this is conforming to CSS standards, and checking
the standards I've seen no strict argument against.
But this will be against the necessity to write CSS files usable for more than
one source, or bind marker definitions to inline styling.
I think, there should be a specific hint in the SVG specifications to this
problem of "back linking" from a CSS-file to the calling SVG/XML-file set up by
the marker statement.
(E.g. like different URI calculation for CSS links and SVG links in CSS files
("URI name spacing") )
(In reply to comment #5)
> So I think what currently is happening is correct.
Chris Lilley from W3.org was answering to my posting:
(The statement above) is correct.
(k> .. from my mailing)
k> I think, there should be a specific hint in the SVG specifications to
k> this problem of "back linking" from a CSS-file to the calling
k> SVG/XML-file set up by the marker statement.
(answer Chris Lilley)> That is fair enough, we will add such a note.
It seems to be not optimal to have to use a file name -
or to use an extra back link to the original XML file "originalSVGsource.xml"
instead of just
marker-end: url(#dartZ); /* used before, not working now */
when dartZ as an identifier is pointing in an unique way to the definition
But Mozilla is fulfilling the standards for that reference, and it might be
better to fulfill just the standards, even, when they are leading to situations,
which are not fully satisfying.
So this bug might be closed.
(In addition to comment #7)
the need to reference to a file may make it impossible to generate new markers
dynamically using DOM features (or how should this be possible anyway?).
Our behavior is per specification, so closing as invalid.
*** Bug 587490 has been marked as a duplicate of this bug. ***