I thought this would be an easy question to find an answer to, but I can't seem to find an answer.
I'm sure that this can vary with implementation. But generally speaking, for browsers for recent versions chrome, firefox, safari, ie. When are image requests sent to the server.
Is it as soon as a DOM element is parsed, or rendered, with a reference to an image? I'm assuming when the DOM is first rendered all referenced images are immediately fetched. Obviously the browser will check the cache first before requesting.
Does / How does this differ from images that are referenced in CSS?
As soon as the HTML-Tag is closed.
Assuming you have a HTML-Chat, the server may never close the stream and the DOM is never compleatly loaded, you will have this:
<body>
<div id="content">
<span class="smily">
<img src="smily.png">
</sp.....
Whearat ... defines data that currently not yet has reached the browser.
All css-rules can match, except the :last-child pseudo-class!
Indeed: the simly.png is requested after closing the img-tag.
Related
I have a template like this :
<div ng-repeat="product in products">
<img ng-src="{{product.imageURL}}" />
.....
</div>
Each time this is regenerated it results in the browser clearing out the img and placing it back in again and will therefore redownload from source ( total size of transferred files keep increasing each time I switch from other state to this one, and i clearly can see that requests to image url are made again in Chrome Developper Tool ).
Is there a way to tell angular : " If you see that it's the same image url, do not redownload it between states". Some sort of caching ? I thought that browsers did this natively, but it doesnt seem to be the case here.
I've got a strange probleme here.
If I have this line in the HEAD part
<meta name="viewport" content="width=1200,initial-scale=2,minimum-scale=2">
touching the lines which are not links in the following example causes one of the links to get activated:
<ul>
<li>example</li>
<li>test</li>
<li>Text in between</li>
<li>Even more text in between</li>
<li>something</li>
<li>other</li>
</ul>
This seems to happen only with that line in the HEAD part. Everything is okay with Chrome and Android Browser.
Is there any way to solve this?
Edit:
It gets even worse if I make the line-height small, for example this way:
li { font-family:Arial; font-weight:bold; font-size:12px; line-height:12px;}
Now whether I use that META element or not, it is almost impossible to tap the texts in between without activating one of the links. Again only in Firefox mobile browser.
I think I've found a solution, however, I don't like it very much.
Adding an "onclick" attribute (whether empty or not) to each unlinked element makes it touchable in Firefox browser.
This can be achieved through a small JavaScript loop.
Better solutions are appreciated!
Ok i have a telerik:RadRotator on my page that loads a few images from the db, the rotator displays correctly in both FireFox and Chrome but when i open it in IE9 the rotator div is placed on the page but the rotator itself doesn't display(render).
<telerik:RadRotator ID="RadRotator1" runat="server" Width="791px" Height="215px"
ItemHeight="215px" ItemWidth="791px" OnItemDataBound="RadRotator1_ItemDataBound"
RotatorType="AutomaticAdvance" FrameDuration="10000" ScrollDuration="3000" CssClass="ImageRotator"
ScrollDirection="Right" PauseOnMouseOver="false">
<ItemTemplate>
<asp:HyperLink ID="hypImage" runat="server">
<asp:Image ID="imgScroller" runat="server" Width="791" Height="215" /></asp:HyperLink>
</ItemTemplate>
Any ideas as to what is happening here? I have tried to remove the styles applied and nothing.
Such problems are often related to an incorrectly formatted HTML that is not ignored by IE, especially older versions of the browser. The only issue that I found in your code was the unclosed RadRotator control tag, although most probably you have missed it by accident. Since the code from your sample appears to be valid, it is possible that an erroneous content is inserted from the data source. Please verify that the content in the datasource is entered correctly and that the data, populating the items of the rotator, is properly escaped before it is used. You can also check if the RadRotator's items are rendered properly by examining the content of the li elements in the HTML representation of the control on the source of your page.
Ok after much fuss I found that the scroller itself was wrapped in a hyperlink. After removing the hyperlink everything works 100%
I have a structure which is as follows:
<a href="#">
<footer>
<p>Some text</p>
<h2>A Heading</h2>
</footer>
</a>
This works and displays as expected in all browsers (even IE6 with the HTML5shiv.js) except Firefox 3.6. In Firefox 3.6 the display is completely screwed and if you use Firebug to inspect the DOM, the <footer> element is empty and the elements which should be inside it are outside of it.
All the tags are closed correctly. The <a> is set to display:block in the CSS.
The W3C validator validates the document and does not mark this structure as incorrect.
The spec states that an <a> element may be classed as flow content when it contains other flow content. The <footer> is flow content.
Is it just that Firefox 3.6 doesn't render HTML entirely correctly?
Any ideas for a fix?
Ta!
According the W3C HTML5 Reference the Footer Elements content model is:
Flow content, but with no heading
content descendants, no sectioning
content descendants, and no footer
element descendants.
Which an a element is interactive content.(Which also can be a Flow Content)
So using the a element will validate, if you validate it against HTML5 Standards. Using something like the W3C validator.
So to answer your question, FireFox 3.6 Doesn't conform to HTML5 standards completely. FireFox 4.0 conforms better than 3.6. You can find a list of what elements of HTML5 (and CSS3) are supported by legacy browsers here.
As for the fix I would suggest that you hide the footer from Firefox, and show a div with your content in that is hidden for everything but firefox. I would accomplish this using jQuery CSS Browser Detection using jQuery instead of Hacks is a good place to start.
Firefox 3.6 doesn't implement the HTML5 parsing algorithm; it has an HTML4 "parser", basically.
I think your workaround options are:
Avoid "block level" HTML tags inside the footer.
Put a <span> as a child of <a> wrapping the <footer>.
Put a <div> as a child of <a> wrapping the <footer>.
I recently have found a strange occurrence in IE8 & FF.
The designers where using js to dynamically create some span tags for layout (they were placing rounded corner graphics on some tabs). Now the xhtml, in js, looked like this: <span class=”leftcorner” /><span class=”rightcorner” /> and worked perfectly!
As we all know dynamically rendering elements in js can be quite processor intensive so I moved the elements from js into the page source, exactly as above.
... and it didn’t work... not only didn’t it work, it crashes IE8.The fix was simple, put the close span in ie: <span class=”leftcorner”></span>
I am a bit confused by this.
Firstly as far as I am aware <span class=”leftcorner” /> is perfectly valid XHTML!
Secondly it works dynamically, but not in XHTML?!?!?
Can anyone shed any light on this or is it simply another odd occurrence of browsers?
The major browsers only support a small subset of self-closing tags. (See this answer for a complete list.)
Depending on how you were creating the elements in JS, the JavaScript engine probably created a valid element to place in the DOM.
I had similar problem with a tags in IE.
The problem was my links looked like that (it was an icon set with the css, so I didn't need the text in it:
<a href="link" class="icon edit" />
Unfortunately in IE these links were not displayed at all. They have to be in
format (leaving empty text didn't work as well so I put there). So what I did is I add an few extra JS lines to fix it as I didn't want to change all my HTML just for this browser (ps. I'm using jQuery for my JS).
if ($.browser.msie) {
$('a.icon').html(' ');
}
IE in particular does not support XHTML. That is, it will never apply proper XML parsing rules to a document - it will treat it as HTML even with proper DOCTYPE and all. XHTML is not always valid SGML, however. In some cases (such as <br/>) IE can figure it out because it's prepared to parse tagsoup, and not just valid SGML. However, in other cases, the same "tagsoup" behavior means that it won't treat /> as self-closing tag terminator.
In general, my advice is to just use HTML 4.01 Strict. That way you know exactly what to expect. And there's little point in feeding XHTML to browsers when they're treating it as HTML anyway...
See I think that one of the answers to Is writing self closing tags for elements not traditionally empty bad practice? will answer your question.
XHTML is only XHTML if it is served as application/xhtml+xml — otherwise, at least as far as browsers are concerned, it is HTML and treated as tag soup.
As a result, <span /> means "A span start tag" and not "A complete span element". (Technically it should mean "A span start tag and a greater than sign", but that is another story).
The XHTML spec tells you what you need to do to get your XHTML to parse as HTML.
One of the rules is "For non-empty elements, end tags are required". The list of elements includes a quick reference to which are empty and which are not.