309612 - SVG marker "not found" when style file used (new builds only, after 2005072109)

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Heinz Kohl]

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

Reproducible: Always

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
actual (SVG-)build
3.( markerOk.xml is showing same styles, but inline; markers are shown. )

Actual Results:  
red line without markers

Expected Results:  
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)

Comment 1

[Heinz Kohl]

Attachment: .xml-file error provoking together with style file (next att.)

to be used together with style file (next att.)

Comment 2

[Heinz Kohl]

Attachment: .css-file (sent as text)

to be used with former att.

Comment 3

[Heinz Kohl]

Attachment: same styles, but inline - working correctly

(only to show the difference)

Comment 4

[Martijn Wargers (dead)]

Attachment: Testcase1, not working from external style

Comment 5

[Martijn Wargers (dead)]

See:
http://www.w3.org/TR/CSS21/syndata.html#uri

"
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.

Comment 6

[Heinz Kohl]

(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 [e-mail] ..

(copy of message to [e-mail] ..)
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
https://bugzilla.mozilla.org/show_bug.cgi?id=309612 )

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") )

Comment 7

[Heinz Kohl]

(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.

My comment:
It seems to be not optimal to have to use a file name - 
    marker-end: url(cssstuff.svg#dartZ);
or to use an extra back link to the original XML file "originalSVGsource.xml"  
    marker-end: url(originalSVGsource.xml#dartZ);
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.

Comment 8

[Heinz Kohl]

(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?).

Comment 9

[tor]

Our behavior is per specification, so closing as invalid.