Is it valid to set img src="about:blank"? - html

Background: I need to have an inline element to which I can apply width and height via CSS.
AFAIK, img is the only way to have this behavior, currently.
I would rather not have the image point to a transparent pixel GIF on the server. It may be cached, but browsers queue it nevertheless, slowing down overall page speed. Other clients might not be caching at all.
PS No, floating div is not sufficient, it behaves differently from inline elements.
EDIT Sorry, I should have inserted the term "cross browser" somewhere. It must at least be working for FF≥2, IE≥7 and current Safari.

You could use the "data:" URI scheme to embed an image.
Other replaced elements might also work. Setting display to "inline-block" might also be worth looking into.

Can you set:
display:inline-block;
width:50px;
height:10px;
IIRC, images are an "inline block" element, thus they can be rendered inline in text strings, but still have block-like properties.

I guess it will be valid in the W3C validator sense, because the validator does not check whether the link is a resource or not.
However, valid in the broader sense, I would say it is not. An src attribute is required in the IMG tag, and I would say must point to a valid image resource.
I find outis`s "data: URI" idea the best way.
If that doesn't work, a transparent image is your best bet. It's one call, it's a few bytes at best, and will be cached by most clients.

Using "about:blank" as src will cause IE to display red X-boxes. This line of CSS prevents this (in IE 8+), but it's still all a bit hacky:
img[src="about:blank"] {visibility:hidden}

You can accomplish the same thing with a tag.
<p style="height: 400px; width: 400px; background-color: #ffcccc;"> </p>
Height and width are settable. This should be across the common browsers, however I have not been able to test Safari or Chrome using it.

Use a <span> tag with a in it - totally valid - then set it's width and height in CSS, also apply display: block;
Using an empty <span> tag means it will be ignored by screen readers and it won't show up as a broken image when styles are disabled.
It'll also not use up any more bandwidth.
:-D

Related

HTML iFrame - size in markup or in CSS?

So is there any difference in this:
<iframe src="iframe.html" width="100" height="100"></iframe>
and this:
<iframe src="iframe.html" style="width: 100px; height: 100px;"></iframe>
Both are supported in HTML5 and I wonder which one is better/reccomended? Any suggestions?
In that case I would suggest to use inline, like for
<iframe src="iframe.html" width="100" height="100"></iframe>
Because if css doesn't load properly or was disabled by user the container size will be the same.
And it will be good for avoiding a block jumping effect.
From the W3C:
"The separation of HTML from CSS makes it easier to maintain sites,
share style sheets across pages, and tailor pages to different
environments. This is referred to as the separation of structure (or:
content) from presentation."
However, there can be exceptions to this. If you have an "original version" of what the page should look like, you can leave the width and height attributes in the markup. You can then use a CSS stylesheet to override the original height and width. This can make sense in the case of an img tag. See the following question: Should image size be defined in the img tag height/width attributes or in CSS?
Like Dryden mentioned its really personal preference. I tend to stick with using class's in my style sheet rather than mixing in with html. Seems much cleaner to me.
However, putting styling at element level would mean that you cannot cache the CSS style rules separately. Usually putting styles in CSS files would allow the caching to be done, thus reducing the amount of load from the server each time you load a page.

HTML forcing img dimensions requires block?

I have a situation where I would like an HTML img which has not yet loaded to have a pre-set height. The reason is that this height will be used in a calculation that may fire before the image is fully loaded and needs to remain accurate. I tried the following:
<div>hello<img src='http://example.com/invalid.gif' class="testimage"> there</div>
and put in some css
.testimage {
height: 200px;
width: 200px;
}
​
and at least in Firefox 5, the extra space is not rendered (and oddly, the broken image doesn't show either, just a blank space). That is, until I add display: inline-block. In at least some other browsers the default display of inline produces the desired result. Is this expected? If so, why?
Here's a jsFiddle as well: http://jsfiddle.net/uYXD4/
it says here that images are inline elements - http://htmlhelp.com/reference/html40/special/img.html
On the other hand take a look here - Is <img> element block level or inline level?
It looks like the <img> element is kind of both inline and block. No strict rules defining it, so probably the browser vendors make their own decisions about the defaults. So your best bet is to reset their assumptions to display: inline-block
Images are replaced elements:
An element whose content is outside the scope of the CSS formatting model, such as an image, embedded document, or applet. For example, the content of the HTML IMG element is often replaced by the image that its "src" attribute designates.
For replaced elements, display: inline-block is supposed to have the same exact same efffect as display: inline, which is the default.
So this may be a possible explanation for that strange behaviour in some browsers*:
They treat only completely loaded images as replaced elements, and otherwise treat them as non-replaced elements. That makes sense after all, and the standard does not explicitly disallow that. As a consequence, there's 3 possible scenarios:
replaced element, inline or inline-block doesn't matter, height property works
inline non-replaced element, height attribute has no effect
inline-block non-replaced element, height property works
Loaded images always qualify as 1., and broken/loading images may qualify as 1. or 2. (or 3. if you set display: inline-block explicitly)
*Not sure if that's how things actually work though.
Why not use something like
<img src="..." width=400 height=200>
I'm doing the exact same thing and it works quite well. Another option is...
$('.myimg').load( function() { /* ops */ } );
though I don't know if that waits to load the image in ALL browsers or not

H2 inside SPAN - browser-compatible?

First of all, I've seen this question IE Compatibility issue, but I have a slightly different issue:
I have a span with display: block and I want to put a H2 tag inside it. Will this look good in every (major) browser?
The answer on the previously stated link, was to make the H2 display:inline, which I don't want, and also I don't want to replace the span with a div, because I would have to change a lot of CSS.
PS. I don't want my HTML to validate (using the validator), I just want it to work.
When you say "I don't want my HTML to validate (using the validator), I just want it to work." You're making a very big mistake. If HTML doesn't validate, there's no telling what might happen. The standards are there for a reason.
Replace the span with a div, you don't need display block on the div as it has this by default. A span is an inline level element, whereas an H2 is block level. An inline element cannot contain a block level element (true up to HTML5, where you can wrap block level elements in anchors)
This will validate, and will work!
It works on current browsers (including old versions), and it is unlikely that this will change. Errors like this are common enough to make it rather pointless to browser vendors to change their error recovery mechanisms. HTML5 is about to make the error recovery rules mandatory.
On the other hand, what is the point of using span with display: block, instead of using div? And CSS should be written so that it does not depend on specific choices of markup elements where different choices could make sense; for example, as a rule, .foo is a better selector than span.foo.
Any extensive change to markup or style sheets has a nonnegligible risk of causing problems even when the change is a such an improvement and a simple one. (For example, a global search and replace often does too much, or misses something.) This could be a reason for continuing the use of invalid markup, in cases where it has minimal risk in practice.
we can solve IE second line problem first
h2{}
h2 span{ float:right;}
Correct way in all browsers
<h2><span>sub content</span> Heading</h2>
wrong way ie browser
<h2>Heading<span>sub content</span></h2>

To collapse div and p by CSS

How can you collapse div and p -elements if they are empty by CSS such that the tags are not shown for the user in the source code?
These elements are in my source code although they are empty.
This causes bugs with the rest of the site.
I run this unsuccessfully
div.unsuccessful,
div.unsuccessful p {
visibility: collapse;
}
This suggests me that you apparently cannot do such a thing by CSS.
Perhaps, other tool such as PHP is needed.
CSS has no influence on the actual HTML code, so this cannot be done. In the (upcoming) CSS3, you could stop them from being rendered using the :empty pseudo-class:
div:empty {
display: none;
}
That is of course not the same thing, but it would probably fix the problems you're having.. if only browsers actually supported it, which they don't, yet.
The best option is to remove them at the server, using a scripting language like PHP. I suppose you could do it client-side with JavaScript, but that's a horrible solution, imo.
That being said, what problems are you having with these empty tags? Why are they there in the first place? It seems to me that some redesign is in order, to prevent the unnecessary tags from being generated in the first place.
Also, be careful. Empty tags are not always meaningless. In fact, removing every empty <div> out there can be considered harmful.
Yes, if you want to stop them being in the source, you'll need to make the appropriate considerations in your server code. Alternatively, you can also set the HTML in JavaScript, but it's not the recommended approach for this problem, probably. You may like to say a bit more though, about what you're trying to do.
Visibility property is intended to set whether the content of the object is displayed or not. It won't remove the element from inside the DOM.
collapse New for Windows Internet
Explorer 8
Used in tables to remove rows and columns; for all other elements, same as hidden.
Also why do you want to do this?
div { display: none; }
removes an element completely from the page.
It'll still show up in your source code, no matter what you do with CSS. The browser combines the HTML source and the CSS directives into a displayable page, the original source is not modified. CSS can only influence the visual display of elements, it can not alter elements. To actually remove elements from the DOM you'll need Javascript (or not put the elements there in the first place).
Yes, you will have to use server side processing to show or not-show some code to the user:
if ($showAdminLink) {
echo "<p>Admin panel</p>";
}
No matter what tricks you try, anything done on the client side (HTML, Javascript, CSS) can be altered and played with.

Rewrite this code: clickable divs

I'd like to change this:
<a href='foo'>
<div> Moo </div>
</a>
to be standards compliant (you're not supposed to have block elements in inline elements). Wiring javascript to the divs just for navigation seems like a hack and degrades accessibility.. In this case, my requirements are for 2 sets of borders on my fixed-dimension links, so the above non-compliant code works perfectly after applying styles.
Also, is "a { display:block; }" a legal way to circumvent the validation?
Why not use a <span> rather than a <div> and set display:block on both elements?
Additionally, to answer your latter question: I don't believe adding display:block; to your anchor will make it pass validation. The validator checks to see if you're following (X)HTML rules, not how to present the page to the user.
You may want to consider putting the div outside the a if it is only for display purposes, unless it's important that the outer border be clickable. Either this:
<div class="dbl_border_links">Blah text</div>
or this:
<a class="dbl_border_links" href="blah"><span>Blah text</span></a>
will work and you can use something like this:
<style>
.dbl_border_links, .dbl_border_links>* {
display: block;
border: 1px solid;
padding: 1px;
}
.dbl_border_links {
border-color: red;
}
.dbl_border_links > * {
border-color: blue;
}
</style>
to specify the styles. Personally I'd go with the div containing the a but either approach works.
I normally consider the <a > tag to be a special case for this purpose. You ought to be able to apply that to just about anything- it is after kind of the whole point of hypertext (<tr > comes to mind a good example). But if you have to pass a validator somewhere I understand.
Could you use a javascript onclick handler for the div, and eliminate the anchor entirely?
Firstly, there is certainly nothing wrong with giving an anchor display:block; I'd say it's one of the more common things people do with CSS and is perfectly standards compliant. Secondly, there are a number of ways to achieve a double border on an HTML element. For one thing, check out the "outline" property:
http://webdesign.about.com/od/advancedcss/a/outline_style.htm
Admittedly, this will only work in the more modern browsers but should degrade gracefully as the outline doesn't take up any space in the page. If the contents of the link is to be an image you can simply give the <a> a little padding and a background colour as well as a normal border (in another colour) to create the impression of a double border. Or give the image a border of its own. Of course you can also do something along the lines of your original idea, though nesting your HTML the other way around, and simply assigning a different border to each element. Or you can use an inline element inside the link (like a <span> or an <em> or something) which you also set to display:block; (yes, this is also valid!). Happy coding!
If I understand correctly your intentions, you should place, as already mentioned, the div outside the anchor, and, to get the same presentation, make the anchor width:100%;height:100%. Cross Browser milage may vary.
Also, you could dump the div altogether and give the anchor display:block;
What are you exactly trying to do?