Closed
Bug 240493
Opened 20 years ago
Closed 12 years ago
HTTP Accept: header does not mention SVG
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: spam_from_bugzilla, Unassigned)
References
Details
Attachments
(1 file, 8 obsolete files)
3.75 KB,
patch
|
Details | Diff | Splinter Review |
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:
Comment 1•20 years ago
|
||
see the discussion in bug 125682 and bug 170789
Reporter | ||
Comment 2•20 years ago
|
||
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.
Comment 3•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
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
Comment 5•20 years ago
|
||
(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.
Comment 6•20 years ago
|
||
*** Bug 258512 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
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
Comment 8•20 years ago
|
||
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.
Comment 10•20 years ago
|
||
per Jwatt from svg newsgroup, we could use const svgIsSupported = 'SVGElement' in window; To detect at runtime, perhaps?
Comment 11•20 years ago
|
||
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:.
Comment 12•20 years ago
|
||
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?
Comment 13•20 years ago
|
||
edit network.http.accept.default....
Comment 14•20 years ago
|
||
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.
Comment 15•20 years ago
|
||
(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.
Comment 16•20 years ago
|
||
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).
Comment 17•19 years ago
|
||
*** Bug 290876 has been marked as a duplicate of this bug. ***
Comment 18•19 years ago
|
||
*** Bug 291511 has been marked as a duplicate of this bug. ***
Comment 19•19 years ago
|
||
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?
Comment 20•19 years ago
|
||
It is disabled by default. Please read carefully.
Comment 21•19 years ago
|
||
> It is disabled by default. With bug 292160 being fixed, I believe svg is now turned on by default.
Comment 22•19 years ago
|
||
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
Comment 23•19 years ago
|
||
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).
Comment 24•19 years ago
|
||
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.
Comment 25•19 years ago
|
||
> 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.
Comment 26•19 years ago
|
||
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.
Comment 27•19 years ago
|
||
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.
Comment 28•19 years ago
|
||
Use of nsIPref is deprecated. Please use nsIPrefBranch instead.
Comment 29•19 years ago
|
||
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?
Comment 30•19 years ago
|
||
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
Comment 31•19 years ago
|
||
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.
Updated•19 years ago
|
Attachment #182619 -
Attachment is obsolete: true
Attachment #182663 -
Flags: review?(tor)
Comment 32•19 years ago
|
||
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-
Comment 33•19 years ago
|
||
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.
Updated•19 years ago
|
Attachment #182663 -
Attachment is obsolete: true
Attachment #183318 -
Flags: review?(tor)
Reporter | ||
Comment 34•19 years ago
|
||
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 35•19 years ago
|
||
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?
Comment 36•19 years ago
|
||
>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 37•19 years ago
|
||
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-
Comment 38•19 years ago
|
||
oops, unbroken link: http://groups-beta.google.com/group/netscape.public.mozilla.xpcom/msg/cd866750deabc606
Comment 39•19 years ago
|
||
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.
Comment 40•19 years ago
|
||
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?
Comment 41•19 years ago
|
||
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)
Comment 42•19 years ago
|
||
(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.
Comment 43•19 years ago
|
||
> 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?).
Updated•19 years ago
|
Attachment #183318 -
Flags: review?(tor)
Comment 45•19 years ago
|
||
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.
Reporter | ||
Comment 46•19 years ago
|
||
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?
Comment 47•19 years ago
|
||
(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.
Comment 48•19 years ago
|
||
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 49•19 years ago
|
||
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.
Comment 50•19 years ago
|
||
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?
Comment 52•19 years ago
|
||
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.
Updated•19 years ago
|
Attachment #188042 -
Flags: review?(tor)
Updated•19 years ago
|
Attachment #195016 -
Flags: review?(tor)
Updated•19 years ago
|
Attachment #195526 -
Flags: review?(tor)
Comment 54•19 years ago
|
||
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.
Comment 55•19 years ago
|
||
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.
Comment 56•19 years ago
|
||
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.
Comment 57•19 years ago
|
||
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
Reporter | ||
Comment 58•19 years ago
|
||
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.
Comment 59•19 years ago
|
||
(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
Comment 60•19 years ago
|
||
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.
Comment 62•19 years ago
|
||
(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
Reporter | ||
Comment 63•19 years ago
|
||
(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
Reporter | ||
Comment 64•19 years ago
|
||
(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.
Comment 65•19 years ago
|
||
(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
Comment 66•19 years ago
|
||
(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
Comment 67•19 years ago
|
||
(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
Comment 68•19 years ago
|
||
(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.
Comment 69•19 years ago
|
||
(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
Reporter | ||
Comment 70•19 years ago
|
||
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.
Comment 71•19 years ago
|
||
(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
Comment 72•19 years ago
|
||
(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
Comment 73•19 years ago
|
||
> 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!
Comment 74•19 years ago
|
||
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
Comment 75•19 years ago
|
||
(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
Comment 76•19 years ago
|
||
I filed bug 309438 on the text type bloat. /be
Comment 77•19 years ago
|
||
(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
Comment 78•19 years ago
|
||
(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
Comment 79•19 years ago
|
||
(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.
Comment 80•19 years ago
|
||
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)
Comment 81•18 years ago
|
||
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
Comment 82•18 years ago
|
||
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.
Comment 83•16 years ago
|
||
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.
Comment 84•16 years ago
|
||
@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
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Comment 85•12 years ago
|
||
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
Comment 86•12 years ago
|
||
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.
Comment 87•12 years ago
|
||
(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.
Comment 88•11 years ago
|
||
(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
Comment 89•11 years ago
|
||
(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.
Updated•11 years ago
|
Keywords: dev-doc-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•