Closed Bug 240493 Opened 20 years ago Closed 12 years ago

HTTP Accept: header does not mention SVG

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: spam_from_bugzilla, Unassigned)

References

Details

Attachments

(1 file, 8 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040404 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040404 Firefox/0.8.0+

I am developing a CGI application that determines whether to send SVG, SWF or
PNG based on browser capabilities (with on-the-fly translation from SVG to these
other formats).  I hope to do this based on the HTTP Accept: header.  I have
downloaded an SVG-enabled Linux firefox build from
http://www.cse.ohio-state.edu/~mohrr/firefox-svg.html.  I have checked that it
does correctly view SVG files (e.g. from the w3c SVG spec).  But the Accept:
header that I get does not mention SVG.  I get this:

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,
*/*;q=0.1,text/vnd.wap.wml;q=0.6

I have also tried a non-SVG Linux firefox build with the Adobe plugin, and that
does exactly the same thing.

Is this a bug, or is it deliberate?  I notice that plugins/extensions can
influence the Accept header; note the WML entry.

Thanks for any advice you can offer.

Reproducible: Always
Steps to Reproduce:
see the discussion in bug 125682 and bug 170789
I've seen those bugs.  The message seems to be "WONTFIX".  Are the SVG
developers in agreement with that?  If I can't detect whether a browser does
SVG, I'll just send Flash to everyone.  In that case, why bother having SVG
support in the browser at all?

If this is the "official line", let me know and I'll stop work on enhancing
libsvgtoswf and just generate the SWF directly.

The flash plugin modifies Mozilla's Accept header to advertize itself.  IMO, the
SVG-enabled Mozilla builds should do the same for SVG.

The Mozilla policy is that additions to the Accept header should not be made
without careful consideration.  We don't want to increase the size of the Accept
header unless there is good reason to do so.  For example, we recently stopped
advertizing support for GIF and JPEG because it is assumed that all browsers
support those formats.  It is not assumed that SVG is supported, so it makes
sense to me that we should advertize it in the Accept header.
Darin, what are the prospects for this bug? Is it waiting for someone to work on
it, or is there too much resistance? 
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
(In reply to comment #4)
> Darin, what are the prospects for this bug? Is it waiting for someone to work on
> it, or is there too much resistance? 

It is waiting for someone to work on it.
*** Bug 258512 has been marked as a duplicate of this bug. ***
Mass reassign of SVG bugs that aren't currently being worked on by Alex to
general@svg.bugs. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 
Assignee: alex → general
I see two possible places to fix this, after scrounging around in LXR:
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#519
http://lxr.mozilla.org/seamonkey/source/embedding/minimo/all.js#180

Maybe a little XUL preprocessing is in order here... if so, please reassign to 
me, and show me a doc on XUL preprocessing.
i'd say preprocessing isn't in order, this should almost certainly be done at
runtime.
per Jwatt from svg newsgroup, we could use

const svgIsSupported = 'SVGElement' in window;

To detect at runtime, perhaps?
Since the <svg:use> checkin, Mozilla 1.8 alpha builds render SVG images I've
made just fine. I think Mozilla's support of SVG has advanced enough that it's
worth putting image/svg+xml in Accept:.
Here's a possible solution, 

A "hidden" (about:config) pref to enable this until drivers(?) feel it is
acceptable in the HTTP Header.

This would allow users of SVG enabled builds to be able to "tell" servers that
they will accept SVG content (if the servers do infact check via accepts as they
should).  It will also enabled the decision maker who will determine if an SVG
build should send that by default an easier time checking.

A possible pref for this would be |image.accepts_svg| I suppose.

Thoughts?
edit network.http.accept.default....
I was thinking a bool pref so that, for example I have a build with SVG and one
without, when SVG is not in my build it would not affect the other one which
uses the same profile.

I guess network.http.accept.svg would be more appropriate than the pref name I
thought up earlier.
(In reply to comment #14)
> I was thinking a bool pref so that, for example I have a build with SVG and one
> without, when SVG is not in my build it would not affect the other one which
> uses the same profile.

I think Matti was saying that you should edit the default value for that
preference (in all.js) so that it is a property of the build you are using and
therefore need not be stored in the profile.
well doing at the least a clobber build would remove that setting if its in the
defaults.

Not everyone, I admit, would know the accepts line to add to "enable" SVG this
way, so a pref in about:config might be useful until it is decided if and how
there would be UI for enable-ing/disable-ing SVG with the Accepts by default.

If this seems a fruitless idea, forgive me for wasting your time(s).
*** Bug 290876 has been marked as a duplicate of this bug. ***
*** Bug 291511 has been marked as a duplicate of this bug. ***
SVG is now built-in and enabled by default. Ignoring talks about a dynamic
accept header, can image/svg+xml not be added to the header by default?
It is disabled by default. Please read carefully.
> It is disabled by default.

With bug 292160 being fixed, I believe svg is now turned on by default.
Nevertheless, SVG support can still be switched off. When that is the case, the
browser shouldn’t send the SVG MIME type in the accept header, that would be
totally wrong. The accept header should be dependable in all situations,
otherwise it is useless.

~Grauw
It should be fairly straightforward to add a pref observer to the SVG code that
inserts the SVG mime type into the default accept header (or removes it).
Why not just base the sending of the SVG accept header on the already existing
pref svg.enabled ? Nearly everyone that enables SVG with that pref would want
web sites to know that SVG is enabled.
> Why not just base the sending of the SVG accept header on the already existing
> pref svg.enabled ? Nearly everyone that enables SVG with that pref would want
> web sites to know that SVG is enabled.

That's precisely what we should do (it's similar to what I proposed), and the
code to do that should live with the rest of the SVG code.
If no one's working on this, I think I could give it a try. I've never made a 
patch for Mozilla yet, but, this seems to be simple enough :

I guess adding some code to the current observer of the svg.enabled pref ( 
http://lxr.mozilla.org/seamonkey/source/content/svg/content/src/nsSVGElementFact
ory.cpp#104 ), that would add / remove svg to the default header should do the 
trick.

One thing I'm a bit worried about though is that on some platform, svg's not 
yet built by default, but svg.enabled is nevertheless set to true. I suppose 
that if the default header is left as is, and only the observer adds it, it 
should work as expected though.

I'll try to attach a patch that does just this pretty soon, unless told that's 
not the way to go, or that someone's already working on this.
Attached patch Current state (obsolete) — Splinter Review
This is what I have for now. There's two problem with this :

1- I assumed / hoped that the observer would get called during the browser
initialization. It doesn't happen, which means in this state, the svg.enabled
pref needs to be first flipped off, then flipped on to get the observer to
actually add the mimetype to the accept header.

2- I suppose my code is somewhat sloppy. I've used what I've found in the
Mozilla String Guide wrt the string manipulations, but, the stripping the
mimetype from the prefs looks suspicious, I'm pretty sure there must be some
better way to do it. Having two different type of access to the prefs seems
wrong too.
Use of nsIPref is deprecated.  Please use nsIPrefBranch instead.
Comment on attachment 182614 [details] [diff] [review]
Current state

+	char* acceptPrefStr = ToNewCString(acceptPrefVal + svgMimeType);
...
+	delete [] acceptPrefStr;

this mismatches allocators (should use nsMemory::Free)... why not store this in
some string class?
Attached patch Updated to comments (obsolete) — Splinter Review
This uses nsIPrefBranch and nsMemory::Free. The reason this is not using some
string classes is that I'm not really sure how I could do it ( yet ), I'll look
into it.
Attachment #182614 - Attachment is obsolete: true
Attached patch Patch (obsolete) — Splinter Review
This fixes the first problem I mentionned in comment #27 : if svg.enabled is
set to true, then the mimetype will automatically be added to the default
mimetype.

As the patch does the job, I'm requesting review. Should something looks
completely wrong, do let me know, and I'll do my best to fix it.
Attachment #182619 - Attachment is obsolete: true
Attachment #182663 - Flags: review?(tor)
Comment on attachment 182663 [details] [diff] [review]
Patch

The add/remove functions should be made static, and renamed to start with SVG -
SVGAcceptHeader{Add,Remove}.

Using Cut() should simplify the remove function.

Please use the coding style of the file you're working in for things like
spaces after if/while.
Attachment #182663 - Flags: review?(tor) → review-
Attached patch Patch v2 (obsolete) — Splinter Review
This should address the review comments : the functions are now static with the
suggested changes, and the inconsistencies with the rest of the file are gone.

Cut() indeed allowed for a much simpler version of the removing, so, that's
what this new patch use. For some reason, I missed it when reading the String
guide. Oops.
Attachment #182663 - Attachment is obsolete: true
Attachment #183318 - Flags: review?(tor)
It's good to see that this bug might be fixed soon.

Has any thought been given to the quality value that should be advertised for
SVG?  I believe that currently */* has q=0.5 and image/png doesn't specify
anything and so defaults to 1.0.  SVG support is obviously better than support
for unknown formats where the user will get a "save as" dialog, but it's not as
good as PNG.  I suggest 0.8.
Comment on attachment 183318 [details] [diff] [review]
Patch v2

>+  NS_NAMED_LITERAL_STRING(svgMimeType, ",image/svg+xml");

The two copies of this string should be moved to a single file static version.

>+  if (svgInAcceptHeader) {
>+    unsigned int cutStart = 0;
>+    nsAString::const_iterator start;
>+    acceptPrefVal.BeginReading(start);
>+    while (start != findStart) {
>+      ++cutStart;
>+      ++start;
>+    }

Wouldn't cutStart = findStart.size_backward() work instead of this?
Attached patch Patch v3 (obsolete) — Splinter Review
>The two copies of this string should be moved to a single file static version.

Oops, done

>Wouldn't cutStart = findStart.size_backward() work instead of this?
It works and it's prettier.
Attachment #183318 - Attachment is obsolete: true
Attachment #188019 - Flags: review?(tor)
Comment on attachment 188019 [details] [diff] [review]
Patch v3

+static const nsString svgMimeType = NS_LITERAL_STRING(",image/svg+xml");

string objects must not be global variables, that leads to crashes. (see
http://groups-beta.google.com/group/netscape.public.mozilla.xpcom/msg/cd866750d
eabc606 and
http://www.mozilla.org/hacking/portable-cpp.html#dont_use_static_constructors)
Attachment #188019 - Flags: review?(tor) → review-
And you could avoid the manual freeing of the string by doing:
+    const nsCString& flatStr = PromiseFlatCString(acceptPrefVal + svgMimeType);
+    rv = prefs->SetCharPref(ACCEPT_PREF_STR, flatStr.get());

and, in the remove case:
+    rv = prefs->SetCharPref(ACCEPT_PREF_STR, acceptPrefVal.get());

Now, that requires a CString instead of a String, but since you are using
SetCharPref anyway, and since MIME types do not contain non-ASCII characters, I
think you should also use nsContentUtils::GetCharPref instead of GetStringPref.
ToNewCString with an nsAString& argument is lossy anyway.
With this patch won't the accept header still be sent even if the browser
doesn't have a renderer installed (e.g. no gdiplus.dll on pre-WinXP systems), so
there is still no way for a server to tell if the browser is truly SVG capable,
is that correct?
Attached patch Patch v4 (obsolete) — Splinter Review
I think this is quite better... At least, I feel like I start to get a better
understanding of what the string guide says.

What's fixed :
- There's no global string object anymore
- There's no lossy conversion anymore
- There's no manual freeing anymore

- The iterators now belong to the what they should
- The patch used two ways to get the preference value. Hopefully, I've kept the
best one.
Attachment #188019 - Attachment is obsolete: true
Attachment #188042 - Flags: review?(tor)
(In reply to comment #40)
> With this patch won't the accept header still be sent even if the browser
> doesn't have a renderer installed (e.g. no gdiplus.dll on pre-WinXP systems)

If the pref svg.enabled is set to true in those case, then yes, SVG will be
added to the accept header even if the client can't really render SVG.

I *think* calling the function SVGAcceptHeaderAdd() from RegisterSVG at
http://lxr.mozilla.org/seamonkey/source/layout/build/nsContentDLF.cpp#549
instead of SVGEnabled would fix this.
> I *think* calling the function SVGAcceptHeaderAdd() from RegisterSVG at
> [...]
> instead of SVGEnabled would fix this.

After looking at it a bit more, this won't be enough, it seems there's no check
to see if there's a renderer before registering SVG. I guess I could use
something like

http://lxr.mozilla.org/seamonkey/source/layout/svg/base/src/nsSVGOuterSVGFrame.cpp#397

to check if we have a renderer before adding the mime-type.
See also bug 294519, which also needs one function that both checks the SVG pref
and checks for the existance of a working renderer (and caches the result if
that check is expensive).  That function should probably live in some common
location (a *Utils class?).
Attachment #183318 - Flags: review?(tor)
Franck, tor has checked in the patch for bug 294519 now. Can you look at this
again to see if that checkin helps you? We really want this for Firefox 1.5.
I haven't seen any replies to my comment #34 about the q value.  I think it
would be a bad idea to ship without one.  Thoughts anyone?
(In reply to comment #45)
> Franck, tor has checked in the patch for bug 294519 now.

I was waiting for bug 294519 to be checked, as it should have helped quite a bit
to fix this bug properly. I'll update my patch and attach it to this bug as soon
as possible. ( I can't do it right now, but it should be done in a few hours )

With regard to the q value, it should be quite easy to had it too.
Attached patch Patch v4.1 (obsolete) — Splinter Review
This is pretty much like patch v4, but updated to put the functions in
nsSVGUtils, and taking advantage of the gSVGRendererAvailable introduced in the
fix for bug 294519. It's building right now...

I think we could change SVG_MIME_TYPE from ",image/svg+xml" to
",image/svg+xml;q=0.8" to add a q value to the mime-type, but I haven't tested.
Attachment #188042 - Attachment is obsolete: true
Attachment #195016 - Flags: review?(tor)
Comment on attachment 195016 [details] [diff] [review]
Patch v4.1

>@@ -46,16 +46,26 @@ struct nsStyleSVGPaint;
> class nsSVGUtils
> {
> public:
>+  /* Adds the svg mime-type to the HTTP-Accept header, unless
>+  *  it's already there
>+  */
>+  static nsresult SVGAcceptHeaderAdd();
>+
>+  /* Removes the svg mime-type from the HTTP-Accept header
>+   * if it's there
>+   */
>+  static nsresult SVGAcceptHeaderRemove(); 
>+

If these utility functions are only called by code in nsSVGUtils, they
shouldn't be in the public interface.  File-static functions or private methods
would be better.
Attached patch Patch v4.2 (obsolete) — Splinter Review
SVGPrefChanged is in nsSVGUtils.cpp, but it's not a method of the nsSVGUtils
class. Therefore, I'm not sure it could call private nsSVGUtils methods... So
I've made SVGAcceptHeader(Add|Remove) file-static functions.

With this patch, there's still a way for the browser to pretend it accepts svg
when it doesn't : if someone has two build, one with svg and one without, and
use the same profile for both, then SVG is in the accept header, even when
browsing with the build where SVG is disabled. 
If we want to fix this, then we need to call SVGAcceptHeaderRemove() as a
clean-up, but I'm not sure about when such a clean-up should happen.
Attachment #195016 - Attachment is obsolete: true
Attachment #195526 - Flags: review?(tor)
This code really shouldn't be manipulating what gets saved to the prefs file. 
If you use the default branch instead (GetDefaultCharPref / SetDefaultCharPref),
does that fix the problem?
Attached patch Patch v5Splinter Review
Using the default branch fixes the problem, thanks :-)

lxr doesn't give any GetDefaultCharPref outside of mailnews though, so I went
through the PrefService -> Default Branch -> (Get|Set)CharPref, I hope that's
the way to do it.

A bit offtopic : Should I clear the review request on obsolete patches ?
Attachment #195526 - Attachment is obsolete: true
Attachment #195581 - Flags: review?(tor)
Yeah, default branch sounds right.  You should generally be using APIs marked
frozen, like nsIPrefService, nsIPrefBranch, and nsIPrefBranch2, rather than the
obsolete nsIPref or nsIPrefBranchInternal.  Sometimes I forget the new names for
things (the old ones were actually CopyDefaultCharPref and SetDefaultCharPref).

Yes, you should clear obsolete review requests.
Attachment #188042 - Flags: review?(tor)
Attachment #195016 - Flags: review?(tor)
Attachment #195526 - Flags: review?(tor)
The patch looks ok to me, but I'm somewhat hesitent for the browser to advertise
acceptance of image/svg+xml when we only implement a nonstandard subset.

Also we might end up backing out the patch from 294519, which would require some
rework of the logic.
I think the way to handle this would be to set the quality value as Phil
mentioned in comment 34. I've no knowledge of how people use this value though,
so I'm not sure what we should set it to.
On the other hand if it is not in the Accept header, an HTTP server might well
respond  406 None Acceptable on a content-negotiated resource.

Accept is not a claim of conformance. I agree that the browser should advertise
what formats it accepts.
Content negotiation using Accept: is broken, except for some image types, and
has been for a decade, arguably forever on "the web" as opposed to the Internet.

We will not reform this situation by starting late with SVG.  And we are not
going to enumerate all the various supported MIME types, or even all types we
support that are not in the intersection of the sets of types supported by all
browsers (a moving target).  That would only bloat headers and hurt performance
for no gain.

It's even sillier to start making up q values to indicate partial
implementations. There is no standard number line, or even one line.  There's a
highly dimensional feature space, in which vectors representing shipped partial
implementations (again, moving targets from the server-side content framework's
point of view) would be lengthy.

We aren't supporting SVG as an <img> type, I'm told.  If we were, then adding
SVG type information to Accept: when fetching an image, and only to that fetch
case, would be defensible.  It's still not a clear win.

Let's get real here: anyone deploying SVG on the web and wanting it to work in
Firefox 1.5 will have to test against Firefox 1.5, so is better off sniffing
that user agent, for now.  Some time in the future, if we have all of 1.1 done,
we can revisit the benefits of bloating the Accept: header for non-image fetches.

/be
Brendan is right to say that content negotiation is broken.  I happen to think
that it could be fixed eventually if bugs like this one were addressed, and
that's why I reported it in the first place.  See my comment #2.  If Brendan's
attitude is the prevailing Mozilla viewpoint then this bug should be closed
"wontfix" now and no more time should be wasted on it.

Regarding q values: I think that there are probably about four de-facto values:

0 = no support at all, it is better to return an error than to send this type
0.1 = this is "supported" in the sense that the user will be prompted to save
it, and they may or may not be able to do anything with it.  I think that is
currently reported for */*.
1 = supported perfectly.
anything between 0.2 and 0.9 = supported but not as well as something with q=1.

It looks as if currently text, gif and html are given q<1 while png and xhtml
are given q=1; I don't think this is right because Mozilla renders all of these
'perfectly'; the decision about whether xhtml or html or gif or png is better
should be decided by the server.  I'd advertise all of those with q=1.  But SVG
is different; in this case the rendering is imperfect, so we should give q<1.

Yes, this is a multi-dimensional space and the comparison function is a partial
order.  If I was trying to compare one format with q<1 and another also with q<1
it would be difficult.  But in practice I'm comparing SVG with q<1 with PNG or
Flash with q=1; in this case the comparison is easy.

I'd like to encourage an early and definitive decision on this.  Either Mozilla
thinks "negotiation is broken" and should purge all support, returning */*
(saving all those valuable bytes in the request header), or it thinks "there is
hope for negotiation" and should fix bugs.  As a web developer I need to know
whether to hold out for a future where negotiation is possible, or to abandon
hope and just send Flash to all browsers.

--Phil.
(In reply to comment #58)
> I'd like to encourage an early and definitive decision on this.

Suits me!

AFAIK we haven't reviewed our Accept: usage with rigor in a long while.  Back
before mozilla.org was formed, fur@netscape.com tweaked it for progressive JPEGs
and PNGs, for the image fetch case.  Darin and other Necko folks, please correct
me if I missed a significant change.

I agree that sending q < 1 for text is silly.  That probably fell out of fur's
old change.  dbaron, what do you think?

> Either Mozilla thinks "negotiation is broken" and should purge all support,
> returning */* (saving all those valuable bytes in the request header), or it
> thinks "there is hope for negotiation" and should fix bugs.

That's a false dichotomy as stated in terms of "*/* or else fix *this* bug".  I
choose neither!

I'd have greater hope for a new, better content negotiation protocol that many
browser vendors actually agree on, implement, ship and test (and test and ship).
I think we should put energy there, not into latter-day Accept: elaborations.

Consider http://www.faqs.org/rfcs/rfc2295.html -- it at least addresses the
scaling problem of Accept:, and proposes a "server advertises" alternative. 
Does anyone have other references, even to proprietary content negotiation
protocols or ad-hoc techniques that actually see significant usage?

> As a web developer I need to know
> whether to hold out for a future where negotiation is possible, or to abandon
> hope and just send Flash to all browsers.

That's a good point.  SVG is never going to compete with Flash.

If you are looking for just some 2D affine-transform-only graphics, especially
integrated with XHTML or XUL some fine day when we enable foreignObject, then
stay tuned to Firefox.

If you want to target SVG at Firefox 1.5 on the web, but you don't want to
author Flash, then you are not a member of a big-enough cohort to make or break
content negotiation based on Accept, and you should sniff the user-agent.

/be
text should have a lower q because markup languages generally provide a better
viewing experience, and thus the browser prefers them.

gif has a lower q because it has lower quality than other image formats (only
256 colors; used to have the patent issue) (hm... no longer in the header it
seems. didn't it use to? anyway... PNG is listed because it's lossless and thus
better than the others.) compare bug 231357 comment 8

I agree with biesi:  if my memory is correct, the q values aren't just (or even
mainly) to indicate how well we support the content -- they're to indicate which
type of content we think is better for the user:  we prefer markup to text, PNG
to GIF, etc., since when two such resources are "equvialent" there's often loss
when converting the first to the second, but not the reverse.
(In reply to comment #60)
> text should have a lower q because markup languages generally provide a better
> viewing experience, and thus the browser prefers them.

No server worries its pretty little head about whether to send text/plain unless
there's a higher-q Accept: match for marked-up text.  I claim we are just
wasting bandwidth and cycles.

I don't see why we bother sending anything in Accept for the extremely common,
not to say ubiquitous, text types that we handle.

> gif has a lower q because it has lower quality than other image formats (only
> 256 colors; used to have the patent issue) (hm... no longer in the header it
> seems. didn't it use to? anyway... PNG is listed because it's lossless and
> thus better than the others.) compare bug 231357 comment 8

There's a lot of wishful thinking in these Accept: header bugs.  Why are we
trying to influence servers to send us one image format over another, when in
reality, high-value images are encoded in one and only one appropriate and
effectively universal format?  Any new format that wants to compete will have to
climb a hill, during which time we can consider selective use of Accept-based
negotiation.

So, we should not enshrine archaic decisions made when a new image format gained
popularity some years ago in our Accept: headers, even if only for image fetches.

We are not going to save Accept-based content negotiation.  Where it pays for
itself, we should use it.  We should look at what other browsers, especially IE,
do, and try to follow the RFCs where we can do so without undermining whatever
asymmetric advantages have helped Firefox actually gain market share.

Working "uphill", trying to use no asymmetric advantage whatsoever, while
risking our unrelated-to-content-negotiation advantages by opportunity costs, is
actually harmful to our interests, and anyway will not (ever) change the
broken-ness of Accept-based content negotiation.

If this is controversial, let's take it up in a newsgroup.

At the same time, we should work with other browser vendors and server/content
folks, via effective standards bodies and peer-to-peer connections, to improve
the content negotiation situation.

/be
(In reply to comment #60)
> gif has a lower q because it has lower quality than other image formats (only
> 256 colors

Here's my understanding.  See the Apache algorithm
(http://httpd.apache.org/docs/2.0/content-negotiation.html), RFC2296 section
3.3, and RFC2295 section 19.1.  I had thought that this was codified in RFC2616
but that isn't the case.

The browser is responsible for indicating how well it supports the media type
(the q value).  For each available variant the server has a "source quality"
value (qs).  So if my image has only two colours and no alpha I'd give the GIF
and PNG variants equal qs, while if they make use of the extra PNG features the
GIF would have a lower qs.  The q and qs values are multiplied together to give
an overall quality, with the variant with the highest value being used.  

Example: I have two images, X uses alpha and Y doesn't.  So:

image  format    qs
X      PNG       1
X      GIF       <1
Y      PNG       1
Y      GIF       1

I have two web browsers.  Moz has perfect support for PNG and GIF, while IE has
perfect support for GIF but imperfect support for PNG:

browser   format   q
Moz       PNG      1
Moz       GIF      1
IE        PNG      <1
IE        GIF      1

So here's what I send in each case:

browser    image    q for PNG    q for GIF    choice
Moz        X        1            <1           PNG
Moz        Y        1            1            Equal, choose the smaller file
IE         X        <1           <1           Both poor
IE         Y        <1           1            GIF

(In reply to comment #59)
> > As a web developer I need to know
> > whether abandon hope and just send Flash to all browsers.
> 
> That's a good point.  SVG is never going to compete with Flash.

Fine.  Goodbye.

(In reply to comment #64)
> (In reply to comment #59)
> > > As a web developer I need to know
> > > whether abandon hope and just send Flash to all browsers.
> > 
> > That's a good point.  SVG is never going to compete with Flash.
> 
> Fine.  Goodbye.

Hey, it's only my humble opinion.  We are shipping SVG support in Firefox 1.5
and working toward full 1.1 conformance in the next major after that.  This was
not a slam-dunk decision, and I threw a lot of influence in favor of the
decision among Mozilla project leaders.  My words with those folks were helpful
in practical ways to SVG.

In contract, my words here cannot affect the outcome of SVG vs. Flash on the
web.  But I'm sorry if my words hurt your feelings.

The cold hard facts (again in my opinion, but it's clear from Flash market share
numbers, and the recently-announced WPF/E plans by Microsoft) do not favor SVG
ever competing with Flash except at the margins.  Now marginal wins are good,
they can shift balances of power -- but even in the best case, SVG alone is not
Flash (it's a lot less, I'm sure you know).  Apart from the other things Flash
can do that SVG cannot (even SVG 1.2), there are the player distribution,
developer tooling, and author mindshare advantages that Flash has.

This isn't fun for me to write.  I don't like pressing "Skip Intro" to get some
non-web, opaque, glitzy-yet-alien-seeming "plugin prison" out of my face.  But I
think the facts speak for themselves.

What am I missing?

Anyway, content negotiation that works and scales well, balancing client and
server interests over time, is worth pursuing.  Another bug.

/be
(In reply to comment #62)
> I don't see why we bother sending anything in Accept for the extremely common,
> not to say ubiquitous, text types that we handle.

Of course, as they are so common, isn’t it especially pointless to mention them?
They are so common, that support of them is usually assumed. For less-common
types such as SVG and XHTML, there is actually benefit to the Accept header.
Just like I now send XHTML to browsers that support it, I could also send a nice
scalable SVG to Firefox (which prints nicely, too), and a plain PNG rendered by
the server to other browsers without SVG support. This will aid SVG adoption.

And why are we even talking about ‘saving bytes’, when we are operating on a
medium that almost exclusively uses text-based formats for its most important
markup languages and transfer protocols? Apparantly this ‘waste’ has never
really been a problem in the years when bandwidth *was* an issue (proof: the
success of internet, and the web in particular). Not to mention that every day,
the bandwidth available to the internet population increases, and as such this
becomes even less and less of a problem.

Anyways, given this, surely you are in favour of binary XML, and adding support
for binary XHTML to Mozilla? That would be something. :)

Anyways, talk about saving bytes... It’s a non-argument. We are not limited to
64k of addressing space anymore. We do not use 1200/75 baud modems anymore.


~Grauw
(In reply to comment #66)
> (In reply to comment #62)
> > I don't see why we bother sending anything in Accept for the extremely common,
> > not to say ubiquitous, text types that we handle.
> 
> Of course, as they are so common, isn’t it especially pointless to mention them?
> They are so common, that support of them is usually assumed.

My point exactly, and I agreed later, and previously in allowing for a future
Accept: header naming SVG, with what you write next.  So I'm not sure whether we
are arguing with each other here.

> For less-common
> types such as SVG and XHTML, there is actually benefit to the Accept header.

Except that SVG content will be a tiny fraction of web content for a long while,
and if we can avoid sending an Accept: header naming SVG, we should.

However.

The main reason to avoid sending SVG now is not to save bandwidth and cycles,
you are right.  That's a secondary reason, and a general reason not to bloat the
Accept header (it's the scaling problem addressed by RFC 2295).  The main reason
is because we don't have a complete implementation of the latest REC, and many
here expressed concern about how to say so with q.

> Just like I now send XHTML to browsers that support it, I could also send a nice
> scalable SVG to Firefox (which prints nicely, too), and a plain PNG rendered by
> the server to other browsers without SVG support. This will aid SVG adoption.

I question the last statement.  Why would SVG embedded not in an image
(remember, we are not supporting that in Firefox 1.5) be adopted more quickly if
we send an Accept: header naming SVG in every single HTTP request for a document
that might embed SVG?

> And why are we even talking about ‘saving bytes’, when we are operating on a
> medium that almost exclusively uses text-based formats for its most important
> markup languages and transfer protocols? Apparantly this ‘waste’ has never
> really been a problem in the years when bandwidth *was* an issue (proof: the
> success of internet, and the web in particular).

That's not a proof of anything.

In 1995, there were browsers that sent 4K worth of Accept headers.  They failed
in the market, for many reasons, but for that alone they deserved to.

The waste issue is secondary, but it's real.  Every byte counts.  It was not the
last cookie we ate that made us fat.  There is a slippery slope.  New formats
will emerge in the next few years (too many in a proprietary fashion).  We may
support some, in addition to SVG and others that are "more standard", but we
will not bloat Accept: headers to name them all.

Again, my view is that when we have a standard-complete implementation of SVG,
we can consider the benefits of adding an Accept: header naming it, vs. the
costs.  For Firefox 1.5, it seems to me there is no benefit to adding SVG to
Accept: and making up a q value.

/be
(In reply to comment #67)
> > For less-common
> > types such as SVG and XHTML, there is actually benefit to the Accept header.
> 
> Except that SVG content will be a tiny fraction of web content for a long while,
> and if we can avoid sending an Accept: header naming SVG, we should.

I think this is short-sighted. Using application/xml+xhtml is a tiny fraction of web content right now, 
and the benefit for browsers is very slight, usually none other than pride. Content negotiating SVG vs. 
PNG vs. GIF, however, would give a _significant_ benefit to the browser experience—SVG is a significant 
improvement in certain fields versus other image formats. I Firefox is going to contain the feature it 
should provide a mechanism for web developers to take advantage of it.

As for the lack of support for SVG in the IMG element, that should not be an issue: developers using 
server-side content negotiation are more than capable of sending XHTML+SVG, XHTML+IMG and HTML
+IMG where appropriate.

If content negotiation is truly broken, and "every byte counts", then why does Firefox/Gecko send any 
information in the HTTP_ACCEPT header? Send */* like some other major browsers and get lowest-
common-denomenator file types; it will save you bandwidth and cycles for sure.

Content negotiation is an imperfect but good solution for developers who want to send cutting-edge 
content without alienating the common user. True the journey for good support might be uphill, but so 
were tabs...once.
(In reply to comment #68)
> (In reply to comment #67)
> > > For less-common
> > > types such as SVG and XHTML, there is actually benefit to the Accept header.
> > 
> > Except that SVG content will be a tiny fraction of web content for a long while,
> > and if we can avoid sending an Accept: header naming SVG, we should.
> 
> I think this is short-sighted. Using application/xml+xhtml is a tiny fraction of
> web content right now, 

And when will it not be?  There are > 20B pages in Google's index, and counting
all intranet and registration-required pages and apps, on order of 100B pages
out there.  HTML is not going away any time, and the cost to rewrite even a tiny
fraction of public web sites in browser-facing XHTML is high enough that the
benefits have to be very large.  What might those benefits be?

> and the benefit for browsers is very slight, usually none other than pride.

What are you talking about?

> Content negotiating SVG vs. PNG vs. GIF, however, would give a _significant_ 
> benefit to the browser experience

Agreed, but that's not what we are talking about here, because we are not
supporting SVG as an <img> type.

If you want to embed an <object> tag that references SVG, great -- but that does
not require us to send an Accept: header naming SVG when fetching the embedding
document.  The <object> tag's alt content can be the PNG or GIF <img>.

> ”SVG is a significant 
> improvement in certain fields versus other image formats.

Nice to hear advocacy, but irrelevant here and a little bit annoying, frankly.
Let's stick to the subject: sending Accept: naming SVG with q < 1 in Firefox
1.5, when fetching *HTML -- why should we do this?

> If Firefox is going to contain the feature it 
> should provide a mechanism for web developers to take advantage of it.

I agree again, and point you to the user-agent header necessary to match Firefox
1.5's incomplete and bug-for-bug self-compatible SVG implementation.

> As for the lack of support for SVG in the IMG element, that should not be an
> issue:

You seemed to think so, when you brought up PNG and GIF alternate content for
SVG above.

> developers using 
> server-side content negotiation are more than capable of sending XHTML+SVG,
> XHTML+IMG and HTML+IMG where appropriate.

We are not supporting <foreignObject> in Firefox 1.5, so again you must mean an
<object> tag, which has its own alt-content fallback mechanism, and anyway which
does not need its embedding document to be fetched with an Accept: header naming
the <object>'s type.

Never mind the made-up q < 1 problem.

> If content negotiation is truly broken,

I said so *except for some image types*, and gave reasons; Phil Endecott agreed.
If you disagree, please show one scenario where adding SVG to the embedding
document's Accept: header helps Firefox 1.5 and content authors.

> and "every byte counts",

It does.

> then why does Firefox/Gecko send any 
> information in the HTTP_ACCEPT header?

See Phil's comment 63 for why Accept is useful for image content negotiation.
biesi made a case for text, but I'm not convinced; haven't heard back from him.

My comments have been clear: Accept is useful in a "temporary" fashion when new
formats evolve that compete effectively with old, established ones.  That's not
what is going on with SVG in Firefox 1.5.  SVG1.1 in Firefox's next major
version, maybe.

> Content negotiation is an imperfect but good solution for developers who want
> to send cutting-edge content without alienating the common user.

You've failed to make this case for non-image-embedded SVG, that is to say
<object>-embedded SVG.

> True the journey for good support might be uphill, but so 
> were tabs...once.

Bogus analogy.  Tabs are a UI feature that can sink or swim without any kind of
content negotiation, or content migration.  Let's stick to the subject: sending
Accept: naming SVG with q < 1 in Firefox 1.5, when fetching *HTML -- why should
we do this?

/be
I have failed to go away... there doesn't seem to be a way to stop getting
emails for a bug where you are the reporter.  Any ideas anyone?

While I have given up hope on this I still feel the need to justify my "vision
of the negotiated-content future" in the face of Brendan's comments.

Please take a few moments to look at http://treefic.com/treefic/royal92.
Appologies if it is slow at the moment.  I hope that you can all see that this
is exactly the sort of page that would benefit from SVG.  Currently the normal
display is an HTML-only hack, with PDF and SVG (which may or may not work)
available as downloads (see the button at the bottom right of the page). 
Internally I start with SVG and then generate the other formats from it.  I have
had Flash versions as well though they are not currently enabled.  This is my
contribution to the web, out in the "margins" of the internet.

As Brendan says I could use the user-agent string to detect FF1.5 and send SVG.
 There are issues with this.  As I understand it it will be possible to disable
SVG via a UI pref.  I don't want to send those users SVG.  Equally there are
versions of FF < 1.5 out there that have SVG (I have one); why should they miss out?

As for the less-than-complete SVG support at present, well, browsers have bugs
in their HTML and CSS implementations too, and content authors generally code to
the lowest common denominator.  This is what I would do here.  It's not a big deal.

But there's a more fundamental issue:  there are specs out there!  On my desk I
have great tomes of documentation describing HTTP, HTML, CSS, DOM, EcmaScript,
SVG, etc. etc. etc.  I'd really like to be able to use *these* documents as the
basis of my work.  And in this area the relevant spec is RFC2616 which defines
the Accept: header.  I'd really like to be able to read about it in the spec,
use it, and have it work.  In reality, I read about something in the spec, use
it, test it in a few browsers, google for the bugs, fix some of them, file bug
reports here on others, wait a year and a half, and then get told "wontfix".  I
reckon that about 70% of the coding time for treefic.com was spent working
around browser mis-features, about 50/50 between Moz and IE.  That compares to
about 1% of my time writing C++ or SQL (etc) coding around their bugs.  It makes
the whole experience incredibly frustrating.

<rant>So frankly, I don't really think it's up to you to decide whether you want
to have a valid Accept: header - you simply must do what the RFC says.  It's
just not good enough for you to tell me that I've got to fit in with your
(undocumented) way of doing things.  If you don't like the RFC, OK, propose
HTTP/1.2 and get it approved and *then* implement that.  In the meantime, you
need to code to the standards.</rant>

More realistically, you should take each of those standards and compose a
point-by-point list of the things that you support, the things that you like and
plan to support in the future, and the things that you dislike and won't
support.  Agree this early and stick to it.  That would give me some sort of
basis on which to work.  Of course, this is not especially easy in the context
of an open-source project, but that doesn't make it any less important to me.

--Phil.

p.s. When I said in comment #58 that negotiation is broken, I meant only that
browsers have many bugs in their implementations.  These bugs could be fixed.
(In reply to comment #70)
> I have failed to go away... there doesn't seem to be a way to stop getting
> emails for a bug where you are the reporter.  Any ideas anyone?

I can help get this fixed if you insist, but don't leave just as this bug is
getting good ;-).

> As I understand it it will be possible to disable SVG via a UI pref.

A hidden pref, if you are talking about Firefox 1.5.  You're right, the UA won't
tell you that some zero-to-tiny fraction of 1.5 users flip this to "off".

> I don't want to send those users SVG.  Equally there are
> versions of FF < 1.5 out there that have SVG (I have one); why should they
> miss out?

They can't be fixed to send SVG in their Accept: headers if they've already been
compiled, so why do they count either way?  This bug would have to be fixed and
the patch backported, and those builds respun.

> As for the less-than-complete SVG support at present, well, browsers have bugs
> in their HTML and CSS implementations too, and content authors generally code
> to the lowest common denominator.

You rant about this later, so why endorse more of it, to a greater degree than
has existed in recent years for HTML or CSS, for SVG in Firefox 1.5?

> This is what I would do here.  It's not a big deal.

Then why the rant?

> But there's a more fundamental issue: there are specs out there!  On my desk I
> have great tomes of documentation describing HTTP, HTML, CSS, DOM, EcmaScript,
> SVG, etc. etc. etc.  I'd really like to be able to use *these* documents as
> the basis of my work.

Reality check: mozilla.org hosts the only errata page that I know of for the
ECMA-262 Edition 3 spec, and it's not short.  I compiled the errata for ECMA-357
(E4X), an even lengthier list.  SVG, don't get me started -- the spec is way too
big, and the testsuites on the web way too small, for me to believe that you can
code to the spec and get interoperation.

Specs are just programs executed by more-fallible-than-computers human readers,
who then try to implement code to match, or write content to match.  There's
nothing magic about them.  If they follow a dominant implementation and are
well-written, using the appropriate models and language, they can be helpful. 
If not -- if there are diverging implementations, or *no implementations* -- or
worse, if the specs are too buggy, then they can be worse than no spec.

That's right: worse than no spec.  There are many roads to interoperation, and a
good spec paves the way, but a bad spec can be an obstacle, especially if it is
not fixed, and actually misleads other implementors before they can crash-test
their implementations in the market.

> And in this area the relevant spec is RFC2616 which defines
> the Accept: header.  I'd really like to be able to read about it in the spec,
> use it, and have it work.

For all the content types we fetch?  4K Accept headers, in other words?

That's not what RFC 2616 requires, of course.  It allows */*, and you need */*
at the end to avoid a 406 if you send other Accept: header content.

So I'm not sure why you bring up RFC 2616.

> In reality, I read about something in the spec, use
> it, test it in a few browsers, google for the bugs, fix some of them, file bug
> reports here on others, wait a year and a half, and then get told "wontfix".

And SVG will be different this time how?

> I reckon that about 70% of the coding time for treefic.com was spent working
> around browser mis-features, about 50/50 between Moz and IE.  That compares to
> about 1% of my time writing C++ or SQL (etc) coding around their bugs.  It
> makes the whole experience incredibly frustrating.

I hear you, but there are better examples than the stagnant monopoly-winner of
the so-called "browser wars" (IE7 is finally getting some CSS fixes), and the
up-and-comer that is 2nd to IE in terms of real-world web compatibility (Gecko
in, say, Firefox 1.5).  We should and will do better, and it looks as though IE
will too -- amazing what a little competition can do.

Safari's getting there, but its market is (so far) growth-constrained, so it
won't necessarily apply competitive pressure as directly as through content
authors -- but never underestimate the Mac's elite/boutique powers.  I don't. 
Nevertheless, for the moment Safari is generally behind us in compatibility.

> <rant>So frankly, I don't really think it's up to you to decide whether you
> want to have a valid Accept: header - you simply must do what the RFC says.

Where does RFC 2616 14.1 say MUST?

> It's
> just not good enough for you to tell me that I've got to fit in with your
> (undocumented) way of doing things.  If you don't like the RFC, OK, propose
> HTTP/1.2 and get it approved and *then* implement that.  In the meantime, you
> need to code to the standards.</rant>

Why are you ranting?  RFC 2616 does not mandate that we include SVG in Accept:
when fetching *HTML.  Nor does it require us to do so with any q value.  

> More realistically, you should take each of those standards and compose a
> point-by-point list of the things that you support, the things that you like
> and plan to support in the future, and the things that you dislike and won't
> support.  Agree this early and stick to it.

We do that, assuming the specs are debugged or will be in time.  Perhaps you
haven't checked out the DOM's feature-supported predicates lately, or read
http://www.mozilla.org/projects/svg/status.html and related docs.  I believe
dbaron can point you to docs on our CSS conformance situation and goals.

C'mon, this is not a "can you top this?" righteous indignation contest.  You are
right that the web is a mess, compared to simpler, more testable things such as
C++ compilers.

But that's the way things are right now, and I keep asking for specific evidence
that adding SVG's MIME type to Accept:, with some q < 1, when fetching *HTML
documents that *might* (but almost never do) contain SVG embedded via <object>,
for Firefox 1.5, will actually help content authors serve users better.

You have cited the desire to ship SVG-in-*HTML to only those Firefox 1.5 users
who send SVG in Accept: in order to serve those users better.  I countered with
"use the UA for now".  You worried that leaves out people who turn off SVG in
1.5, and something I believe is irrelevant about extant pre-1.5 builds.  Where
do we go from here?  Ranting about the goodness of standards is not productive.

> That would give me some sort of basis on which to work.

Meanwhile, the web is continuing to grow rapidly, and there's a DHTML
renaissance (AJAX, whatever).  Interoperation testing is hard, but clearly
there's money in doing it while developing advanced content.  SVG should fit
into this picture soon, even in Firefox 1.5, but probably in a way that's
specific to Firefox 1.5 -- which is why I suggested using the user agent.

> Of course, this is not especially easy in the context
> of an open-source project, but that doesn't make it any less important to me.

Why is it harder than in any other context?  It should be easier to figure out
what works and what will work, according to the fallible human hackers, or the
source itself as mute witness, than with proprietary closed source, if you are
not actually testing.

> --Phil.
> 
> p.s. When I said in comment #58 that negotiation is broken, I meant only that
> browsers have many bugs in their implementations.  These bugs could be fixed.

Ok.

I meant, and others including RFC 2295's authors mean, that Accept: does not
scale well.  And that because of this, new content type support is implemented
in browsers without adding to Accept:, and has been for a decade or more, and
that this perpetuates the broken-ness.  It's not just "buggy"  (according to
which RFC?) browsers that are to blame for such a longstanding condition.

/be
(In reply to comment #71)
> > As I understand it it will be possible to disable SVG via a UI pref.
> 
> A hidden pref, if you are talking about Firefox 1.5.  You're right, the UA won't
> tell you that some zero-to-tiny fraction of 1.5 users flip this to "off".

Er...

If this is turned off as part of a security release, the fraction will be much
bigger than zero-to-tiny. Afaik, the preference exists solely for that purpose,
to be able to turn off SVG in case a security vulnerability is discovered in it.


> > More realistically, you should take each of those standards and compose a
> > point-by-point list of the things that you support, the things that you like
> > and plan to support in the future, and the things that you dislike and won't
> > support.  Agree this early and stick to it.

It would be good if there was an actual policy for decisions about for example
what ends up in the Accept: header. That would make things much clearer to
outsiders, and also avoid the impression that the policy changes at random, on a
bug-per-bug basis, following whatever is the trend at the time...


> But that's the way things are right now, and I keep asking for specific evidence
> that adding SVG's MIME type to Accept:, with some q < 1, when fetching *HTML
> documents that *might* (but almost never do) contain SVG embedded via <object>,
> for Firefox 1.5, will actually help content authors serve users better.

By analogy, the same could be said for the XHTML MIME type. How many are using
it, really. Few, very few. For the people who *want* to use it, how useful is
it? Extremely useful. To the point where it is pretty much impossible to serve
XHTML without this mechanism. The XHTML case is a success story for Accept:. And
the same is true for SVG.

You say: the SVG implementation is not good enough yet. I say: how is our SVG
implementation ‘worse’ than IE’s current PNG implementation? Does that withhold
us from using PNG? No, in the contrary, we are glad that it at least supports
*some* of PNG, rendering most images well enough for it to be generally usable
(although perhaps a little sub-optimal).

So given that the SVG is ‘good enough’, why would the little difference between
this and ‘good’ be so important that it makes a difference in claiming support
for it? If I have a website with SVG, right now or in 5 years, I want the SVG to
be used in Firefox 1.5 as well. If necessary, I can base that decision on a
‘quality’ indication in the accept header, and quality ratings I have given to
the SVG and alternate PNG content, e.g.:

X      SVG       1
X      PNG       <1
Y      SVG       <1
Y      PNG       <1

Where X-SVG is chosen over X-PNG because it is a superior format, and where
Y-SVG has a <1 rating because it is too complex to be shown in SVG
implementations that are not complete 1.1 (e.g. SVG Tiny), causing the PNG to be
served to Firefox 1.5, and the SVG to later versions.

I can totally see that work...

Another example, assume I use a technology on my server which renders an SVG
file to a PNG which is sent to the browser if it doesn’t indicate SVG support.
This is not an edge case at all, in fact it is a scenario that comes to mind
quickly when considering use of SVG on a large-scale website. It would be
backwards compatible, yet it would be possible to use SVG.

Using SVG here is beneficial because it is XML, and using technologies like
Cocoon I can generate them dynamically using database input and a simple XSLT
transformation (see: http://www.grauw.nl/logs/useragent.php for a nice example
of how SVG can be put to good use). Not having to send PNGs to all user agents
is beneficial because SVG is a superior format and it reduces server load.

Again, I can totally see that work, and as a matter of fact it is a very
possible scenario for the technology that the company I work at to use (Ajax
environment, we’d like to avoid Flash to be used, and we offer an XML server too
so SVG would be easier to generate).

However, without SVG in the Accept: header this is pretty much impossible to do
properly.


> But that's the way things are right now, and I keep asking for specific
> evidence that adding SVG's MIME type to Accept:, with some q < 1, when
> fetching *HTML documents that *might* (but almost never do) contain SVG
> embedded via <object>, for Firefox 1.5, will actually help content authors
> serve users better.

Within the scope of websites having SVG content (which will hopefully broaden
after the Firefox 1.5 release), I’d say at least 90% of the sites uses <object>
to embed it, because that is the way it is done with Adobe’s SVG plugin for IE.
Additionally, why do you think it would only be useful for <object> (and <img>)
tags? If I link to an SVG file instead, would I not also want the user to see a
PNG alternative if it is not supported by the browser?

Also, application/xhtml+xml (a pretty long string) is similarly sent to all
websites, for the benefit of a small minority. Does that mean it shouldn’t be
there? Does it hurt anyone, that it is there? I say no. And I do not see why
this should be different for SVG. Again, this shows that Mozilla doesn’t have a
policy or concensus at all about decisions like this.


~Grauw
> Again, my view is that when we have a standard-complete implementation of SVG,
> we can consider the benefits of adding an Accept: header naming it, vs. the
> costs.

I think that we absolutely should have SVG in the accept header when it is
‘done’. It is essential to the survival of SVG on the web, without it SVG can’t
be used until all user agents support it and are widespread enough to rely on
its availability. I don’t even want to guess at how long that will take,
especially if there is no existing content to make it beneficial. PNG had this
help, too (although I don’t think it was used often?), and so has XHTML (where
it is used often). Not fair if SVG doesn’t get it.

So I hope by ‘consider’ you mean that you will most likely add it, if you are
serious about SVG.

(As a side story, actually I used GIF alternatives for transparent PNG images on
my website. I was using * html CSS hacks to serve the GIFs to IE specifically -
Accept: content negotiation would have been much more appropriate, and
cross-browser compatible!)

So the only real question that remains, imho, is whether the current SVG
implementation is enough to tell the servers that ‘it is supported’. For that,
see my ‘IE and PNG’-story (read: I think it is, even though support is not 100%
yet :)).


~Grauw

p.s. IE doesn’t send text/html in Accept:... Why does Firefox? It is so common,
support can be (and is) assumed by everyone. For commonly supported file
formats, Accept is useless. It is a waste of bytes!
If we get SVG 1.1 done in 1.9, for any reasonable value of "done", we should add
it to Accept: when fetching over HTTP, unless we know enough not to have to add
it (when fetching for a typed container).  My "consider" was to get that happy
day out of the current discussion, since it is now, not a year from now.

The problem is what to do in Firefox 1.5.  I talked to tor on IRC, and he said
(putting him on the record here, I hope he expands on this) that he didn't think
Firefox 1.5 implemented enough to claim we Accept SVG.

/be
(In reply to comment #72)
> If this is turned off as part of a security release, the fraction will be much
> bigger than zero-to-tiny. Afaik, the preference exists solely for that
> purpose, to be able to turn off SVG in case a security vulnerability is
> discovered in it.

That's a hard case, and law students all know hard cases make bad law.

If a security event happens, we'll have to patch SVG quickly anyway, because too
many users won't know to flip the pref, and will still be vulnerable.

The argument here, for the umpteenth time, is about whether we should say
Firefox 1.5 Accepts SVG and with what q value, and hard-case arguments don't
really help decide that.

> It would be good if there was an actual policy for decisions about for example
> what ends up in the Accept: header. That would make things much clearer to
> outsiders, and also avoid the impression that the policy changes at random, on
> a bug-per-bug basis, following whatever is the trend at the time...

There is a policy, it's called "finish implementing the spec for the MIME type
you want to Accept: -- and don't abuse the q parameter".

I object to the proposed abuse of q to mean "half of SVG 1.1 is done, let me
start sending it to any browser that Accepts: SVG with q=0.5" -- or whatever
value you jokers want to make up.  That's *not* what RFC 2616 specifies q for
(so spare me the rants and lectures on the sacredness and primacy of specs).  Quote:

   Each media-range MAY be followed by one or more accept-params,
   beginning with the "q" parameter for indicating a relative quality
   factor. The first "q" parameter (if any) separates the media-range
   parameter(s) from the accept-params. Quality factors allow the user
   or user agent to indicate the relative degree of preference for that
   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
   default value is q=1.

   . . .

   The example

       Accept: audio/*; q=0.2, audio/basic

   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
   type if it is the best available after an 80% mark-down in quality."

Re-read http://www.mozilla.org/projects/svg/status.html and tell me how lack of
a bunch of features in SVG 1.1 correspond to a "mark-down in quality" analogous
to audio lossy compression or quantization error.  There's no comparison.

Just so you don't think I'm flaming unfairly, I'm going to find out which XML
freaks imposed the text type nonsense in Firefox's Accept, viz:

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

and flame them too, in a new bug that will be fixed by tossing everything up to
image/png in that line.

/be
I filed bug 309438 on the text type bloat.

/be
(In reply to comment #75)
> Re-read http://www.mozilla.org/projects/svg/status.html

Correction: http://www.mozilla.org/projects/svg/status-ff15.html (assuming that
is up to date).  I guess q should be 0.33, just counting table rows and dividing.

You could argue all you want about how q should be 0.67 because the missing
features are less important.  You're still abusing q.

/be
(In reply to comment #2)
> why bother having SVG support in the browser at all?

In Firefox 1.5, to test SVG (at some risk of security bug egg on our faces) and
let early adopters try it, and perhaps influence the rest of the implementation
of SVG 1.1, at least bug prioritization.  And for XUL early adoptors who want to
use it in extensions, where the current SVG subset along with the <canvas> tag
could be put to many worthwhile uses without any content negotiation whatsoever.

Why test SVG in such a large distribution?  Because it's complicated enough, and
its test suites so small, that we won't be able to test it enough "in the lab"
before shipping all of 1.1 in Firefox v.next.  Testing includes hard work such
as optimizing based on real-world workloads, and measuring and diagnosing
topcrash bugs via talkback.

Why are we trying to get to SVG 1.1 support in a future release?  Because we're
hedging, and so are companies such as IBM, which pays at least one SVG
developer, against the all-Flash, or more ominous (and likely?) all-WPF/E
future.  Actually, we're pretty much living in the all-Flash present, as I've
said before.

Hedging against WPF/E with only SVG 1.anything is a bad bet.  In order to
compete asymmetrically against what MS is rolling out, we will need a lot more
than SVG (but I've said this already too, with no snappy responses from die-hard
fans, so I'll lay off now).  But SVG 1.1 is an achievable starting step toward
much richer, hardware-accelerated graphics on the web.

/be
(In reply to comment #72)
> If this is turned off as part of a security release, the fraction will be much
> bigger than zero-to-tiny. Afaik, the preference exists solely for that purpose,
> to be able to turn off SVG in case a security vulnerability is discovered in it.

That was *one* of the reasons for creating it prior to the addition of the new
binary patch update system. The plan was that we could provide a small
pref-flipping XPI as a "patch" if an SVG security hole was discovered. I'd hope
we can now use the update system to provide a real patch instead. If such a real
patch proves to be too difficult or time consuming to make we may end up turning
SVG off, but at least the chances of that happening are now less.
Having considered this some more I guess there are better ways to serve the best
content to user agents than to look at the Accept: header. As far as I can see,
all of the scenarios described here can be covered by using <object> and/or
JavaScript. In the case where you want to choose between SVG or Flash, use
<object> to reference the SVG, and <embed> as its alternative content to fall
back to Flash. In the case of choosing between SVG and an image, do the same but
use <img> as the alternative content. So you want to generate your
Flash/PNG/whatever on-the-fly? Well make the 'src' attribute of your
<embed>/<img> point to your Flash/PNG generator sending it the path of your SVG
file in a query string.

The bottom line is brendan and tor are right.

1) "Accept:-based content navigation is broken on the web"
   (some image formats excepted)

In other words it isn't possible to use the Accept: header as anything like a
reliable indicator that your web content will work if you send it to a user
agent. To be a reliable indicator it would require that all implementations of a
given web format that advertise it in the Accept: header have near perfect
support. Or to be a semi-reliable indicator, that all implementations have at
least good support. Implementations that start to advertise their support in the
Accept: header too early while things are still buggy and incomplete are a major
contributor to its brokenness.

2) "our SVG implementation is too buggy and incomplete"

It is. For Firefox 1.5 our SVG support is simply going to be too buggy and
missing too many things to make the general statement "we support SVG" by adding
image/svg+xml to the Accept: header. To do that we'd need to have at least
fairly solid support for the smallest subset of SVG (SVG 1.0 Tiny) which we
don't. Frankly, to address one of the earlier statements, I don't think most SVG
five years from now will work in Firefox 1.5. Animation, lots of the Text module
(specifically textPath), Patterns, Filters and Fonts are all major missing
modules. For us to add image/svg+xml to the Accept: header at this stage would
just further compound the uselessness of Accept:-based content navigation.

SVG is a big and complicated specification and all implementations have a whole
host of bugs, different interpretations of ambiguities, varying levels of
strictness, etc. Anyone who wants to be at least semi-confident their SVG will
work as intended will need to test to know which viewers it works in, and detect
those viewers when serving it. At least this is certainly going to be the case
for Firefox 1.5. If you just want to serve SVG and hope it works go back and
read the first paragraph I just wrote again.

For the record, neither Opera 8.5, nor Adobe's SVG Viewer in Internet explorer
add image/svg+xml to the Accept: header.
Attachment #195581 - Flags: review?(tor)
Does the SVG team feel that the SVG support in Firefox 2.0 is sufficiently solid that we can put the SVG MIME type in the Accept: header?

Gerv
Firefox 2.0 is a UI release, so platform fixes are minimal. With the exception of textPath support, not much will have changed feature-wise in the SVG support I think. Regardless, even on the trunk (will be Firefox 3) where the real SVG work is being done, I wouldn't consider the current state to be sufficient, yet. Still far too many easy to trip over bugs around. Hopefully by the time Firefox 3 comes around it will be. So that's a no from me, but I'll defer to project owner, tor.
Should this be marked as a duplicate of bug 125682? It's tightly related and a bit more general: conditionally setting HTTP header according to SVG built-in support in compiler options seems more useful IMHO.
@Helder: It’s not a duplicate, they are different things. You could set that bug as a blocker for this one though, but that all depends on the approach that is taken in fixing this bug.

By the way,

http://www.codedread.com/svg-support.php

Is SVG a reasonable amount of ‘done’ now? Where is that point exactly? Will Firefox ever implement SVG entirely?

~Grauw
Assignee: general → nobody
QA Contact: ian → general
We're not going to fix this.

For the record, recent Firefox, Chrome and Safari all send:

  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

IE9 sends:

  Accept: text/html,application/xhtml+xml,*/*
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
That's actually very unfortunate to have this closed.

With the advent of high-dpi, high-resolution displays - like 2048×1536 px color ITFT display at (264 ppi) now on the marked - web developers are facing issues with certain page elements, like small bitmap icons for the user interface. 

MediaWiki developers are already trying to deal with this:

http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59682

It would be very good to be able to rely on "Accept:" header to present SVG version of the image to the browser.  At the same time we need a PNG fallback for those browsers, that don't support SVG. 

It seems to be difficult to do a CSS-based fallback (display SVG and fallback to PNG) without some use of JavaScript and (possibly) user agent sniffing.

Wikimedia Commons is hosting quite a nice collection of SVG images (https://commons.wikimedia.org/wiki/Category:SVG) and it's a pity that .png thumbnails have to be presented to all browsers, even for those that support it natively.
(In reply to Marcin CIESLAK from comment #86)
> It would be very good to be able to rely on "Accept:" header to present SVG
> version of the image to the browser.  At the same time we need a PNG
> fallback for those browsers, that don't support SVG. 

Too late.  You'd want to serve SVG to browsers that support it and by now there are browsers that support SVG but don't advertise it in the Accept header, so even if we added it at this point, authors would still use something else to decide whether to serve SVG. 

These days, the most reasonable strategy is to serve SVG unless you detect IE < 9 or the Android stock browser < 3. Happily, today the latest version over each of the popular browsers supports SVG, so it's only necessary to detect past versions that are still in popular use.
(Brendan Eich [:brendan] comment #57)
> Content negotiation using Accept: is broken, except for some image types, and
> has been for a decade, arguably forever on "the web"
This should be documented and clearly explained to Web developers (update [1]). Why is it broken exactly?

[1] https://developer.mozilla.org/en-US/docs/HTTP/Content_negotiation

(In reply to Henri Sivonen (not reading bugmail until 2013-01-07) (:hsivonen) from comment #87)
> These days, the most reasonable strategy is to serve SVG unless you detect
> IE < 9 or the Android stock browser < 3
With UA string-sniffing? Is so, how is it better than the Accept header?
Keywords: dev-doc-needed
(In reply to David Bruant from comment #88)
> (Brendan Eich [:brendan] comment #57)
> > Content negotiation using Accept: is broken, except for some image types, and
> > has been for a decade, arguably forever on "the web"
> This should be documented and clearly explained to Web developers (update
> [1]). Why is it broken exactly?

Quick summary:
 1) You can’t rely on it as an author, because there are always clients that accept something they don’t declare.
 2) Negotiated responses are so rare relative to all HTTP responses that the request bloat resulting from content negotiation is almost always waste.

> (In reply to Henri Sivonen (not reading bugmail until 2013-01-07)
> (:hsivonen) from comment #87)
> > These days, the most reasonable strategy is to serve SVG unless you detect
> > IE < 9 or the Android stock browser < 3
> With UA string-sniffing? Is so, how is it better than the Accept header?

 1) As SVG gets deployed now that the latest version of each notable browser supports it, it’s safe to assume that no new browser can get significant deployment in the future without supporting SVG. If you accept the previous sentence as being correct, it follows that you can detect lack of SVG support by sniffing past versions only. Sniffing past versions does not pose the kind of problems that sniffing the current version and assuming the future versions continue to have current defects poses. So sniffing for IE < 9 and Android stock < 3 is not damaging to the Web in the future.

 2) Looking at Accept would fail to detect SVG support, because browsers already shipped with SVG support but without advertising it in Accept.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: