Inspired by this question, where the poster casually states as fact that <object> should be used instead of <img> to embed images in HTML documents.
I'm developing a web app at the moment, and, being a perfectionist, I try to make it all shiny and compliant with all the standards. As far as I know, the <img> tag is to be deprecated in the upcoming standards for xHTML, and as nowadays even IE is able to handle <object> properly, I wanted to use the <object> tag for all the images on my site
It became clear that the "upcoming standards" the poster was talking about was the abandoned XHTML2 spec, which didn't even formally deprecate <img> anyway. (Although there were apparently rumors to that effect.)
To the best of my knowledge, I've not seen anyone in the web development community advocating for the usage of the general-purpose <object> tag over the arguably more semantic and definitely more compatible <img> tag.
Is there a good reason to use <object> instead of <img>? Should <object> even be used at all in place of <img> – what might this break?
To answer the question in the heading: yes, it is valid, of course. The validity of an object element does not even depend on the type of data being embedded. If you meant to ask whether it is correct, then the answer is yes, there is nothing in the specifications that would forbid it or recommend against it.
Among the possible reasons for using object to embed an image, the most practical is that it allows the fallback content to contain HTML markup, such as headings, lists, tables, and phrase markup. The img element lets you specify only plain text as fallback content—even paragraph breaks cannot be specified.
For accessibility reasons, any image should have fallback content to be rendered e.g. when the document is used in nonvisual browsing (screen reader, Braille, etc.) or the image is not displayed for one reason or other. For any content-rich image (say, an organization chart, or a drawing describing a complex process), the fallback content needs to be long and needs to have some structure.
However, it is rare to use object for embedding an image. The importance of fallback content is not widely understood, and practical economical and technical considerations often cause fallback issues to be ignored. Moreover, object has a long history of slow, buggy, and qualitatively poor implementation in browsers. Only recently has it become viable to use object fairly safely for image inclusion.
The question which element is more semantic is mostly futile, and answers typically reflect just various ways to misunderstand the concept “semantic.” Both img and object mean inclusion (embedding) of external content. The img element is in principle for the inclusion of images, whatever that means, though it has also been used to include videos. For the object element, the type attribute can be used to specify the type of embedded content, down to specific image type, e.g. type=image/gif, or it may be left open.
This implies that the object element is more flexible: you can leave the type unspecified, letting it to be specified in HTTP headers. This way, the type of the embedded data could be changed without changing the object element or the embedding document in general; e.g., you could start with a simple version where the embedded content is an image, later replaced it by an HTML document (containing an image and text for example).
The only time I've ever seen an object used to show an image is to create a "fallback" when the intended object couldn't be loaded for whatever reason. Take this example from the W3 specs:
<OBJECT title="The Earth as seen from space" classid="http://www.observer.mars/TheEarth.py">
<!-- Else, try the MPEG video -->
<OBJECT data="TheEarth.mpeg" type="application/mpeg">
<!-- Else, try the GIF image -->
<OBJECT data="TheEarth.gif" type="image/gif">
<!-- Else render the text -->
The <STRONG>Earth</STRONG> as seen from space.
</OBJECT>
</OBJECT>
</OBJECT>
Only ever attempting to load an image via an object is basically removing the semantic meaning off of the image, which I would consider very bad practice.
There is no good practical reason to use object instead of img. object has always been inconsistently and messily supported. Use img for images, embed for flash content, and video or audio for multimedia content. Basically the only use of object left is for invoking specific plugins.
That said, the philosophical position for object's existence is still very good. It was meant to be a generic element for any type of content which can contain nested fallback content. W3C/XHTML2 had a very idealistic roadmap for html which emphasized syntactic and semantic purity and wanted to do things like allow href on any element (eliminating a), and eliminate img in favor of object. However, browsers could never seem to get object right in a fully generic way. Additionally, it was difficult to define the js APIs for a generic object element. That's a big reason why video and audio are separate--object serving a video won't expose the js video APIs.
However, XHTML2 lost and HTML5 won and HTML5 favors img, so use img.
I came across a real-world use case for using object over img tags. I’m using PlantUML to generate SVGs that include tooltips. If I use the img tag to include the img, none of the native SVG pointer events events work. But if I use the object tag, presto - all over the onhover/mouseover behaviors work as expected.
Related
Is there a way I could store image url inside VTT file? For example:
WEBVTT
00:00:00.000 --> 00:00:10.000
Chapter tile goes here
thumb_0001.jpg
00:00:10.000 --> 00:00:20.000
Another chapter title
thumb_0002.jpg
I know I could write custom parser, but I am wondering is there some kind of a standard for this?
You would need to have a separate WebVTT metadata track, a player that supports them, and likely some scripting and CSS to act on the cue payload. You can see an AblePlayer demo of a few things a metadata track can do (at the 39 second mark). If you examine the wwa_meta.vtt file, you can see that it references ID selectors that happen to be in the player's page html code.
The example you give is quite similar to what is being done currently across the internet for image thumbnails. It's most commonly used for animated video previews on... adult... websites. If you Google search for ".jpg" filetype:vtt you'll find some interesting examples that take the same approach as yours.
As Murray cited already, it's not really the proper way to do it. The metadata track option he cites is much more inline with correct use of the VTT spec. However it's also not broadly supported. You could follow VTT guidelines and end up with a file that can't be read by many players.
One other option is CSS. VTT is designed to work nicely with CSS. So you could include you image as a CSS background-image. That way it's separate from the text content and (at least in theory) some players might even be able to display it properly.
So I've been creating a custom responsive theme in Wordpress and I've hit a wall when it comes to image management. I'd like to style images in a way that wordpress doesn't seem to inherently support - I'm looking for something like this:
with the images added via the regular wordpress media management pane, and inserted into posts/pages. The images should be out of the flow of the content but accurately placed next to the correct headers/text blocks. Most importantly, the images ought to collapse into a column with the rest of the content at the correct media query breakpoints.
Here's what I've tried, from worst to best:
Hard coded images in template files
Obviously the worst option. Not portable, requires a lot of meddling, and would be almost impossible to align the images with the correct content. Also, no real way of making the images responsive with the content.
Use the default image styling and abandon the idea of pulling the images out of the regular flow
Non optimal, but it would allow anyone to change/edit images easily.
Remove images from the results of the_content(), then place and style them separate.
Portable, but has the same problems as #1 - difficult to align the images with content and keep responsiveness.
Use the featured image on pages that only require one image
Pretty good option for pages that need ONLY one image, but there is no easy way to make the featured image an arbitrary size/aspect ratio.
Use markup in the editor to correctly layout the images
Requires anyone editing the posts/pages to have some knowledge of the underlying theme. This seems to work the best, but it isn't portable (might break stuff on theme change).
While I've had the best results with this option, it seems sort of antithetical to using a cms/wysiwyg editor in the first place.
My question is whether or not the last option really is the best to get the result I want?
In the end, the answer was clearly custom fields, and none of the other options I listed. With the advanced custom fields plugin, it becomes a breeze to do what I wanted. You don't need the plugin, but it makes image management a whole lot easier, as it fully integrates the wordpress media library with the custom field (which you would have to do manually otherwise). With the plugin, custom fields meet all of my needs (responsiveness, portability, and ease of use for the technically challenged).
Yesterday, I saw a tweet saying about holderJS library. When I read the usage, it says it will generate the image placeholder completely on client side. So I am wondering why in the life would I need a placeholder library?
What is the scenario in which rather than placing div of some size I would use image placeholder?
Image placeholders are generally meant for a page that is either in the process of dynamically loading a real image or the page is only partially designed and the placeholder image shows how the design will be laid out and how big the image should be even though the real image is not yet available. In this way, the HTML design can be nearly completed even though the final images are not yet available or done.
Wikipedia uses image placeholders when they know they want a particular image in a page, but are in search of an image they can use with the appropriate license.
Image placeholders are traditionally served up by a service on the web that automatically creates the placeholder images based on query parameters in a URL, but the holder.js library creates placeholder images entirely on the client (so no outside services are needed).
You can certainly achieve the same look as a placeholder with just a div with a background color and perhaps even some text in the div. But, when someone wanted to plug the final images into place, they would have the change the div tags to img tags. When using a placeholder image, all the HTML tags can be final and left as they are, only the .src values need to be plugged in to finish the design. So, placeholder images allow you to have a closer to complete version of the HTML even though the images are not yet done. It's a minor different, but one that is appreciated by some designers.
What language or technology would I need to be able to create documents online? I want to be able to add text and images and move them into position, resize etc, similar to this.
And then when complete, create a PDF from them.
Sorry if this is a bit vague, I just need to know where to start researching.
You need to decide on your basic technology: Flash, Silverlight, Canvas, client-side SVG, server-side SVG or server-side bitmap. There are also commercial solutions that work with Adobe InDesign documents (and probably a host of other proprietary formats) but I'd expect those not to be cheap.
Flash/Silverlight require plugins, and are considered by some to be a dying technology - though I am sure that is disputed. Canvas is 'very HTML5' and is essentially a bitmap built/rendered on the client, but if you are ultimated rendering to PDF it may not provide the resolution you need. The same limitation affects building an image server-side too - you should probably be dealing with vector elements plus bitmaps, rather than rendering everything to pixels as you go.
That leaves SVG in my list, either on the client (see RaphaelJS) or on the server (see Inkscape). I'm doing some work with server-side SVG rendering at the moment, and it is promising; although subject to more scalability issues than client-side, it doesn't suffer from browser-compatibility issues or the limitations of browser rendering.
The biggest issue in browser SVG rendering is flowed paragraph text and text in/on a path - I am not sure how well these are implemented in modern browsers, or how much agreement there is between them. This is especially the case given that some of these require SVG1.2, and browsers (afaik) are only just settling on SVG1.1, after many years. But, if you just want to do standard blocks of text, bitmaps and vector elements, browser-based SVG should suit you fine.
The example you've given uses a server-side technology (SVG, or perhaps a commercial format) and renders to low-res PNG on the client.
In your case, once you've considered how to 'do the editing', you'll need to consider how to render to PDF, which will be done on the server. You could go low-level and use something like FPDF, use a report renderer like Jasper, or use a graphics system like GhostScript, Inkscape, Scribus, ps2pdf, svg2pdf etc.
Aside: I normally don't answer questions without obvious prior research. But, since you've indicated that you will indeed undertake this, I'm happy to help get you started.
I'm attempting to synchronize a DOMRange (representing a user-selection from a Cocoa WebView) to the original HTML source currently rendered in that view, as a kind of Dreamweaver-split-editor:
My first idea was to get the DOMRange object's startContainer and offset and walk up the DOM tree from there, accumulating the overall character offset up to the body tag.
Unfortunately this task presents some problems:
Clearly the document's outerHTML will differ from the original HTML source if the DOM was manipulated via Javascript or the parser needed to clean up malformed tags.
I can't figure out how to get the offset of a node within its parent text node (e.g., 4 characters to target in <p>some<div>target</div>text</p>), and normalize doesn't seem to make this any easier.
Trying to account for some of the problems in #1, or just going from HTML source to WebView will probably require separately parsing the HTML and then correlating the two DOM-trees.
One ray of hope is that HTML5 specifies a standard parsing algorithm for dealing with invalid HTML (which WebKit has since adopted), so in theory it should be possible to use an off-the-shelf HTML5 parser to generate the same tree as WebKit — right?
This is the most similar existing question I could find, but it's for a slightly different problem:
Getting source HTML from a WebView in Cocoa
Your problem #1 is actually not so bad; you can just turn off JS interpretation.
Look at QWebSettings::JavascriptEnabled, or just drop this in before you load any html:
QWebSettings::globalSettings()->setAttribute(QWebSettings::JavascriptEnabled, false);
That should leave your DOM un-mangled by JS. Good luck!