Last Comment Bug 309612 - SVG marker "not found" when style file used (new builds only, after 2005072109)
: SVG marker "not found" when style file used (new builds only, after 2005072109)
Status: RESOLVED INVALID
: testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: General SVG Bugs
: Hixie (not reading bugmail)
Mentors:
: 587490 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-22 05:12 PDT by Heinz Kohl
Modified: 2015-04-13 08:40 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
.xml-file error provoking together with style file (next att.) (2.10 KB, text/xml)
2005-09-22 05:16 PDT, Heinz Kohl
no flags Details
.css-file (sent as text) (445 bytes, text/css)
2005-09-22 05:17 PDT, Heinz Kohl
no flags Details
same styles, but inline - working correctly (2.02 KB, text/xml)
2005-09-22 05:20 PDT, Heinz Kohl
no flags Details
Testcase1, not working from external style (2.08 KB, text/xml)
2005-09-22 11:15 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details

Description Heinz Kohl 2005-09-22 05:12:38 PDT
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 2005-09-22 05:16:23 PDT
Created attachment 197025 [details]
.xml-file error provoking together with style file (next att.)

to be used together with style file (next att.)
Comment 2 Heinz Kohl 2005-09-22 05:17:59 PDT
Created attachment 197026 [details]
.css-file (sent as text)

to be used with former att.
Comment 3 Heinz Kohl 2005-09-22 05:20:14 PDT
Created attachment 197028 [details]
same styles, but inline - working correctly

(only to show the difference)
Comment 4 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-09-22 11:15:51 PDT
Created attachment 197063 [details]
Testcase1, not working from external style
Comment 5 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-09-22 11:22:52 PDT
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 2005-09-23 03:23:25 PDT
(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 www-svg@w3.org ..

(copy of message to www-svg@w3.org ..)
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 2005-09-26 05:00:04 PDT
(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 2005-09-26 05:15:23 PDT
(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 2005-09-30 06:28:35 PDT
Our behavior is per specification, so closing as invalid.
Comment 10 Robert Longson 2010-08-15 23:32:36 PDT
*** Bug 587490 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.