I'm trying to make a web based media player using the HTML5 audio element implemented in Firefox 3.5 and Chrome. Reading Mozillas documentation, omitting the autobuffer attribute should result in the audio src not being requested:
if specified, the audio will
automatically begin being downloaded,
even if not set to automatically play.
This continues until the media cache
is full, or the entire audio file has
been downloaded, whichever comes first
However, on the server side I notice the files are being requested anyway. My sample page is very simple:
<html>
<body>
<audio src="1.ogg"></audio>
<audio src="2.ogg"></audio>
</body>
</html>
The autobuffer attribute has been replaced with preload which accepts the values none, metadata and auto.
A patch has been submitted for WebKit (issue #35385; unfortunately I can't link to it), but it seems that it hasn't made it into Safari 4.0.5.
Boolean attributes in HTML5 can't be false. If it's present at all, it's true.
You've been led astray by XHTML habits.
See:
http://dev.w3.org/html5/spec/Overview.html#boolean-attributes
Quote:
"The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether."
According to the article "Configuring Servers for Ogg Media", Ogg media does not contain duration information, so to correctly display a slider you need to include an X-Content-Duration header. If you don't include such a header, Firefox will prefetch portions of the media* so that it can work out the duration and display a slider.
That could be your problem.
* It will fetch the first few bites, which should give it a Content-Length header so it knows the file size. It will then use that file size to fetch the last few bites, from which it can work out the duration. If your server does not support Range requests, the result will be that it'll fetch the whole file.
Related
I have this displayed in my Firebug console
"NetworkError: 404 Not Found - http://********.com/images/slider-img/ajax-loader.gif"
So it's telling me it can't find a background image. But can it pinpoint which CSS file this image has been declared as a background-image property?
I have about 4-5 CSS files being referenced in the document and the manual way of finding it out would to open each of the files and find for this image. So I was wondering if this could be avoided and have Firebug tell me which CSS file is the culprit...
Firebug currently (as of version 2.0.x) doesn't directly show you the initiator of a network request. This requires platform support, which is requested in bug 563623.
So, as a workaround you can do this:
Switch to the CSS panel.
Click into the search field at the right side of Firebug.
Ensure that the option Multiple Files is checked.
Enter ajax-loader.gif
=> The CSS panel will switch to the CSS source containing the rule containing the image value.
Notes:
There may be several properties referring to different images named ajax-loader.gif. So you should also check whether the path to the image corresponds to the one shown in the error message. (Within the search field you can hit Enter to get to the next match.)
It's not sure that the request comes from CSS. It may also come from JavaScript, e.g. through an AJAX request or by appending an <img> tag dynamically.
If you specify same image in different CSS selectors, will it be downloaded separately or later url's will use the first one?
.a {
background: url('image1.png');
}
...
.b {
background: url('image1.png');
}
Actually in all the browsers, we have browser cache. Once it is loaded it will not be loaded again. If the file size and names are same, there is no way it is going to be loaded again. You can track that using firebug or developertools.
Try it — when looking into caching issues, a tool like Firebug for
Firefox or the Developer Tools within Chrome are very beneficial. If
you open the 'Net' panel in either and reload a page, you will see
what HTTP status code was sent for each item. 304 (Not modified) means
that the item was retrieved locally from the cache.
As dthorpe says above, cache headers are important here. As well as
making sure that 'no-cache' hasn't been set, if you have access to
your server configuration you should be pro-active — if you know a
resource isn't going to change you should make sure to set either an
'Expires' header (which tells browsers a date after which the cached
copy should be considered stale) or a 'Cache-Control: max-age' header
(which gives a number of days/hours rather than a set date).
You can set different time-scales for different mime-types/folders
too, which allows you to get clients data to refresh HTML content
often, but images and stylesheets rarely.
Here's a nice intro video/article by Google that's worth checking out.
Highlighted are the proper answers from this stackoverfow question. It will be interesting for you if you try to know about how web browsers work.
This question is about browser behavior as well as protocol specification for linking, importing, including or ajaxing css, js, image and other resources from within html, js or css files.
While testing static files and compressed content delivery in different browsers, I found that some browsers start behaving differently if you move away from conventions. For example, IE6 creates problem if you do not send Content-Disposition: inline; header for all inline css and js etc files, and a recent version of safari does not properly handle pre-compressed gzip CSS files if you use file extension .gz like in main-styles.css.gz.
My question is about the behavior of browsers about Content-Type response header. Since <link>, <script> and <img> tags already reasonably specify the content type of the resource, can this header be safely skipped, or do some browsers require it for some historical reason?
In short, no, it's not required. But it's recommended.
Most browser that I know of will treat <link>, <script>, and <img> properly if they are not sent with headers, but there's no real good reason not to send the headers. Basically, without Content-Type headers, the browser is left to try and guess based on the content.
From RFC2616:
Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
Regarding the keyword SHOULD, specified in RFC2119:
SHOULD: This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
It is required for backward compatibility.
For example: Internet Explorer 10 needs Content-Type:image/svg+xml in order to render any svg file
IE10, IE9 and probably other browsers always need the Content-Type header.
I ran into a problem in java where I tried to post some data via the library chrriis.dj.nativeswing.swtimpl.components.JWebBrowser, which basically displays an internet explorer inside a java program. But the simple php script on the back-end would not parse my post-data. (Used WebBrowserNavigationParameters to set post data while navigating to a certain page) I finally found out that the Content-Type header had to be set for php to properly paste the post-data. (This was not set by default.) Setting it to Content-Type: application/x-www-form-urlencoded and everything worked fine. So, I guess setting Content-Type should allways be done when POSTing data to php.
I'm working on a large asp.net web project that has had a number of different developers/consultants making changes to it over the last few years. I've noticed that depending on the developer, paths to images and other static content may contain the correct casing, all lower case, or something completely random. The browser appears to be making multiple requests for the same asset due to the difference in casing. For example -
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<img src="http://cdn.sstatic.net/stackoverflow/img/sprites.png" />
<img src="http://cdn.sstatic.net/stackoverflow/Img/sprites.png" />
</body>
</html>
Aside from searching for every image in the project and normalizing the casing, is there anything that can be done here? Perhaps something I can put in the page response headers to tell the browser to ignore casing, etc.
Well, the browser (it's not just Chrome that does it, any browser that doesn't is buggy) has to do this because there's no way for it to know that you happen to be using a case-insensitive mapping, so <http://cdn.sstatic.net/stackoverflow/img/sprites.png> and <http://cdn.sstatic.net/stackoverflow/Img/sprites.png> are completely different URIs.
There's a few things you can do.
First find-replace those that are:
Particularly commonly used.
Particularly heavy files.
Particularly commonly mis-spelt.
Not likely to result in you find-replacing something that ruins unrelated code.
Another thing you can do is to force canonicalisation of case in a handler that when invoked for a URI that doesn't match your case-canonicalisation rules, 301's to the form that does. This means that rather than grab 3 different 10kb images you'll grab 1 10kb image and have 2 or 3 redirects of a couple-hundred bytes. That said, below a certain file size then cost of an extra request out-weighs the saving.
Finally you can use a filter (a stream object that Response.Filter is set to, that writes to the previous value of Response.Filter) or code in the PreRender step that scans for local URIs (if you change the case of URIs on other sites you could result in 404s) and outputs them correctly.
Here is the HTC content I'm encoding (nothing fancy):
<public:component>
<script type="text/javascript">
alert('data URI');
</script>
</public:component>
Here is the definition in the CSS file, with the above component base64'd:
.something
{
-ms-behavior: url(data:text/x-component;base64,PHB1YmxpYzpjb21wb25lbnQ+PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPmFsZXJ0KCdiYXNlNjQnKTs8L3NjcmlwdD48L3B1YmxpYzpjb21wb25lbnQ+);
}
Doesn't seem to work...although when I save the above component to a file, and reference it in the behavior property, I get my alert. I remember an announcement that behaviors could now be housed in data URIs in IE8...I thought that was the trade off for taking dynamic properties (CSS expressions) away from us. Is this wrong?
No, DATA URIs were not added to compensate for the removal of CSS expressions.
Supported only in IE8 Standards Mode pages, Data URIs are limited to 32kb in length, and cannot be used for script-execution or navigation purposes.
If you look in the IE8 error console, you'll see:
Webpage error details
Message: Access is denied to: data:text/x-component;base64,PHB1YmxpYzp...