Can anyone explain the meaning of the attribute complete?
I read somewhere that it might have to do with DOM.
<img src="/folder/pic.jpeg" complete="complete" />
The attribute complete has no defined meaning by specifications, and it probably has no effect (though it can be read with the getAttribute() method). So the code in the question is probably based on some misunderstanding.
According to HTML5 drafts, there is the complete property for an object corresponding an img element, as per the HTMLImageElement interface. The definition of the complete property basically means that the value is true when the browser has completely received the image (though there are some nuances here). As this is to be controlled by the browser, reflecting the loading status, it is natural that the property is defined to be read-only.
This property is widely present browsers, but apparently in a broken way: if you have an img element that refers to a nonexistent resource (404 Not Found), then Chrome and Firefox indicate the property as having the value true (IE gets things right here: false). So the property is not of much use for the time being.
Setting an attribute in HTML has no effect on this. HTML attribute and element object properties correspond to each other only when a correspondence has been defined.
It's set when the image has been downloaded.
I've never seen it explicitly in the HTML like in your example (MDN says it's not an attribute for a img element) . I just use to check if the image has been downloaded with JavaScript (there are cross browser issues with that, however). The property on a HTMLImageElement returns a Boolean.
[].forEach.call(document.querySelector("img"), function(img) {
// Loaded?
img.complete && (img.style.border = "5px solid #f00");
});
It is used to check if the image has finished loading.
document.getElementsByTagName('img')[0].complete
returns true if has finished loading, else false.
However it is not used as an attribute like in your example.
Related
I'm having hard time to find information related to target="_help" on the Internet. So, when I have an HTMLAnchorElement like this:
I can see that this thing is actually behaving like target="_blank", but anything else?
Could not find anything on MDN. Also no mention on the HTML5 Spec and detailed W3C Browsing Context page.
According to the MDN:
This attribute specifies where to display the linked resource. In
HTML4, this is the name of, or a keyword for, a frame. In HTML5, it is
a name of, or keyword for, a browsing context (for example, tab,
window, or inline frame).
That means that click on a
instructs iframe named _help to set src value to the value of href. The example below loads youtube video:
Help
<iframe name="_help"></iframe>
JSBin.
On a side note, this feature looks pretty obscure, I did not know about it before your question.
As mdn says:
target
This attribute specifies where to display the linked resource. In HTML4, this is the name of, or a keyword for, a frame. In HTML5, it is a name of, or keyword for, a browsing context (for example, tab, window, or inline frame). The following keywords have special meanings:
_self:
Load the response into the same HTML4 frame (or HTML5 browsing context) as the current one. This value is the default if the attribute is not specified.
_blank:
Load the response into a new unnamed HTML4 window or HTML5 browsing context.
_parent:
Load the response into the HTML4 frameset parent of the current frame or HTML5 parent browsing context of the current one. If there is no parent, this option behaves the same way as _self.
_top:
In HTML4: Load the response into the full, original window, canceling all other frames. In HTML5: Load the response into the top-level browsing context (that is, the browsing context that is an ancestor of the current one, and has no parent). If there is no parent, this option behaves the same way as _self.
So, if you use any other key except these 4 keys (_self, _parent, _top, _blank), it opens a blank window, and gives a name with the key you wrote on the target attibute to that window.
You can check:
https://developer.mozilla.org/en/docs/Web/HTML/Element/a#attr-target
I'm trying to detect if a custom element has been registered yet, e.i if it is still unresolved.
In a browser that supports custom-element (e.g Chrome) I can do that by checking that is it is not an instance of HTMLUnknowElement and that it doesn't match the pseudo-class ":unresolved" with element.matches or any vendor-prefixed equivalent.
But when I'm working under polyfill, the matches/webkitMatchesSelector/mozMatchesSelector function breaks when called with ":unresolved"
Is there a way to have a peek on the list of unresolved elements ? Or any other way that would work under polyfilled browser ?
Thanks
EDIT
Just found that doc with a bookmarklette that detects any unresolved element on the current page. The problem is it doesn't work on polyfilled browsers.
The reason is that it check if the consctrucor is still HTMLElement whereas in a polyfilled browser the constructor is always HTMLUnknownElement
If I use a data URI to construct a src attribute for an HTML element, can it in turn have another data URI inside it?
I know you can't use data uri's for iframes (I'm actually trying to construct an OSDX document and pass it to the browser with an icon encoded in base64 but that's a really niche use case and this is more of a general question), but assuming you could, my use case would look like:
var iframe = document.createElement('iframe');
var icon = document.createElement('image');
var iSrc = 'data:image/png;base64,/*[REALLY LONG STRING]*/';
iframe.src='data:text/html,<html><body><image src="'+iSrc+'" /></body</html>
document.body.appendChild(iframe);
Basically what I'm after is is there anything in a data uri that would break a parent data uri?
Yes you can. I really thought it was impossible, as did everyone I asked.
Example:
Pasting the following into your browser's URL bar should render a gmail logo in an html page that says hello world.
data:text/html,<html><body><p>hello world</p><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACwAAAAsCAMAAAApWqozAAAAz1BMVEX///+6xs7iTULj5+vW2tzk49TX3+Tq6tz09Orz9/jm7O6wu8aNm6WwMCjfRDnm5ube2Mmos7vt7++jrLP29/eyTk3d4+fj6+foWFLM1t2bNzeZpa2trKPv8/ajo6Xud2f0r6rv7uG3ubvd6eXIysq9s6jeopfSUknx8fHbXGKvTx7Hz9X09PTwhXHw9Pb++/fp7/Xu4d3SZlPSiXjuaFmMkZX39/vZy6/j8+v2+/v76uP7+/v0/Pewl4raMi/f5+7KTjitf4W2rI3/9vDzz8uC91bdAAAAAXRSTlMAQObYZgAAAmBJREFUeF6VldeunDAQQNeF3jvbe729p/f//6aMxzaBKHe5OZiVJY6OBvbBAyTvZaDJSy/xzpJ4pdJzz1tfOme5LD0vly45fETe4/1vUoK26bnPznUPzrPrmSJsgtrPpQnpPCmvp2/gukyE/HX6JtYor9/kpqUcY3ogvUxv5RhlSrbHenFzY/+0cxtYApZlGZod3W9JaqJspuSR1vTqw41U4UZb+S/zMAz35FbJt4QK6sUnW+naxWwoaJXBpBi37bxTjuchyl+0zLGs4npmVK1dHSLBiLhmlg+chLukFiLqV3dQ1i84p1SEv42CgLhYzmR5vqh1XIUXeypGoN+LAMoVz5yBk/EKZfsOQioOsnGFWXr/eXLCMs9EeehK2bab+NKCbQj2/mEymRSjpqzkR5CXOv4AWSqyM3BnRSDKw255CWtBW0BWcILyCmQsMywv5b/xS8WpzGJZzMywPFZjvANTYO10VoNfIxqOW2WlwhU/QnbSMDu1y0yWpSowdiqry6OArEW5ka1GNTaGsWqViwDL4z/lezClu4nBN+K/ypWSIywrNY4NxaqZWZSjThlEkQXLUna8lTZ+unWnDE6T1fbmtZlBxWxbFvHZ5NR8DUeUj5QejQ1mu24cv2C5aJW3R3qv1a4bX8TbIih+wAv6IPvDKCIrAusV8FEpyz5njFUV/ERdWFTBHVWwmGkyKKPcT2kyjvKFy1jPgnJ6IeTMg30vzCUZHBTc52mvzdKhz+GYcJIxTw8ukOKlVmd/SPk4kSdQ4nv8fJh7PriIw7Mn/yxPGW8dm06e269eOTwe/De/AW24fWb7B21TAAAAAElFTkSuQmCC" /></body></html>
or for a shorter example courtesy of Pumbaa80:
data:text/html,<script src="data:text/javascript,alert('hello world')"></script>
MSDN explicitly supports this:
Data URIs can be nested.
An old blog entry talks a little bit more about embedding images within CSS using data: :
Neither dataURI spec nor any other mentions if dataURI’es can not be nested. So here’s the testcase where dataURI’ed CSS has dataURI’ed image embedded. IE8b1, Firefox3 and Safari applied the stylesheet and showed the image, Opera9.50 (build 9613) applies the stylesheet but doesn’t show the embedded image! So it seems that Opera9 doesn’t expect to get anything embedded inside of an already embedded resource! :D
But funny thing, as IE8b1 supports expressions and also supports nested data URI’es, it has the same potential security flaw as Firefox does (as described in the section above). See the testcase — embedded CSS has the following code: body { background: expression(a()); } which calls function a() defined in the javascript of the main page, and this function is called every time the expression is reevaluated. Though IE8b1 has limited expressions support (which is going to be explained in a separate post) you can’t use any code as the expression value, but you can only call already defined functions or use direct string values. So in order to exploit this feature we need to have a ready javascript function already located on the page and then we can just call it from the expression embedded in the stylesheet. That’s not very trivial obviously, but if you have a website that allows people to specify their own stylesheets and you want to be on the safe side, you have to either make sure you don’t have a javascript function that can cause any potential harm or filter expressions from people’s stylesheets.
We are building an image carousel, it displays clickable thumbnails that when clicked, displays the actual image. We therefore need both url to appears in the Html. Since there is no "actualImageUrl" attribute defined in the img tag, we figured out that we could build the thumbnail url like this : /thumb.png?altUrl=actualImageUrl.png. The server does not care of the actualImageUrl querystring param and we can use javascript to parse the scr attribute and figure out the actualImage Url.
How W3C valid is this ?
Changing the URL of the src attribute is perfectly valid - But you could use the data- attribute - new with HTML5 (although that doctype is not a requirement to use them) and its purpose is exactly this, from the specs :
Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.
w3 specs for custom attributes
Note - you can test validation here
Anything is valid as a src attribute value, in the XHTML meaning for “valid” (a formal thing). It is also otherwise correct to have a query part in such a value and use it in client-side scripting.
But it might be unnecessarily complicated. As you are working with client-side JavaScript, you could include the URLs in a JavaScript array or object, instead of putting them anywhere in HTML markup. For example, you could use an object with thumbnail image URLs as property names and full image URLs as corresponding values, like
var fullImage = { 'thumb.png': 'actualImageUrl.png', ... }
And you would then use this object to pick up the full image URL when a thumbnail is clicked on.
For a more robust solution, which would work even when JavaScript is disabled, you would need to generate the code server-side, generating a elements around img elements.
I've curious how this should be properly done.
I ran a page im working on through the w3 html validateor and I got one error message
Line 47, Column 54: Attribute "target" exists, but can not be used for this element.**
<ul><li>1000 Design PM</li>
You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).
any idea on how i can have a link open a new window but not use the target tag?
You can use JavaScript to open new windows, which avoids the issue of target being invalid in modern HTML.
However, this bypasses various systems people have in place to warn them about new windows (or prevent them from opening) so you are better off using the target attribute (and switching to a Doctype that allows it).
Better still is to leave it to the user to decide when they want a new window. Aside from the annoyance factor, they do introduce accessibility problems.
target="_blank"
Will not validate strict because the 'target' attribute has been deprecated.
Instead, try something similar to the aforementioned onclick workaround, but you don't need the "_blank" in there either. Simply:
1000 Design PM
Will work. The reason for the deprecation of "target" is because HTML is used to semantically mark up data whereas the target attribute was providing behaviour, which is what javascript is for.
If the user has javascript turned off then the URL will simply open in the same window.
The target attribute is not part of the Strict variants of HTML 4 and XHTML 1.0 as well as XHTML 1.1.
So you would need to use a workaround using JavaScript:
1000 Design PM
var aElems = document.getElementsByTagName("a");
for (var i=0, n=aElems.length; i<n; ++i) {
if (/(?:^|\s+)_blank(?:\s+|$)/.test(aElems[i].className)) {
aElems[i].onclick = function() {
return !window.open(this.href, "_blank");
}
}
}
Or (in the future) CSS 3 (see Hyperlink Presentation Module):
a._blank {
target: new;
}
Shouldn't it be...
target="_blank"
Regardless... You could open a new window using javascript, but that breaks the beauty of simple browsing. What if I'm browsing using Lynx or something?
According to W3C, it seems that "target" attribute is not deprecated any more in HTML 5:
The target attribute for the a and area elements is no longer
deprecated, as it is useful in Web applications, e.g. in conjunction
with iframe.
http://www.w3.org/TR/html5-diff/
Using:
target="_blank"
breaks strict XHTML validation methods. Here's a document detailing a workaround:
Instead of target="_blank" (who will never validate) you could use javascript like this:
<a onclick='window.open("./jobops/1000 Design PM.pdf", "_blank");return false;' href="./jobops/1000 Design PM.pdf">1000 Design PM</a>
Then the link will open in a new window, and your page will validate.
The users who doesn't have Javascript enabled (even though that is only about 2% of all users), will still be able to follow the link with this method. The guy's have a good point in the comments :)
Have a nice weekend everyone...