The 1990 CompuServe GIF89a specification defines a "graphic control extension" like so:
The Graphic Control Extension contains parameters used
when processing a graphic rendering block. The scope of this extension is
the first graphic rendering block to follow. The extension contains only
one data sub-block.
This block is OPTIONAL; at most one Graphic Control Extension may precede
a graphic rendering block. This is the only limit to the number of
Graphic Control Extensions that may be contained in a Data Stream.
As this is block optional, how does one determine whether or not an arbitrary GIF image contains a graphics control extension?
As it turns out, the specification pretty plainly states that all extensions, including the Graphic Control, Plain Text, Comment, and Application extensions, are demarcated by the presence of a 0x21 at the start of the block.
What threw me off is that GIFs contain a flag located in the Logical Screen Descriptor that denotes the presence of an optional Global Color Table block, but there is no such flag to denote the presence of a graphic control extension (not sure why). It either comes right after the Logical Screen Descriptor or it doesn't. Hope this helps someone down the road...
Related
Many webpages have options where you can change the font size or increase contrast. Those options are most of time designed for visually impaired people.
What technics do you use to ensure that those people actually find the options to increase accessibility?
According to the WCAG 2.0 spec, a high-contrast toggle must itself be high-contrast. I've done this simply by creating simple black-on-white button (that inverts when hovered of focussed, for effect) at the head of my page. I opted to use a font-awesome icon for the button content, so I was careful to include role="img" and aria-label="High Contrast Toggle" in the <i>. I was also careful to make the toggle keyboard-accessible by adding a tabindex
It's better to make all text high-contrast by default, but I opted for the toggle as a learning challenge and also because I did not want to change my page's colour scheme. Alternatives to toggles that are suggested by the spec are using skrims or text-shadow. (description, 3rd paragraph). This would have looked and worked better, but my testing tools (WAVE Chrome extension v. 1.0.1) didn't detect the change, so I decided to make a toggle.
If you provide such widgets, you have to make sure that your document is also accessible without using them. Otherwise (= your document is inaccessible with the default settings) some users can’t find/reach/use your widgets to change the settings.
If you can’t make your whole document accessible without using the widgets, you should at least make sure that the widgets can be reached and used. This would be similar to providing a link to an alternate version.
As far as I know, there is no standard way to mark up or annotate such accessibility-related widgets. If they are important, it can make sense to have them as one of the first elements of the document.
(And just in case it’s not clear: it’s rarely necessary to provide such widgets, e.g., for text resizing, at all; there are often many other ways/technologies to make sure that your document is accessible.)
OK, I know how to include HTML content from a separate file using the <object> tag. What I can't find any info about is what is allowed/required within the included HTML file. Can said included file merely be some text with some HTML tags, or does it have to be a complete HTML file with headers, <head>, and <body>? How does this appear within the DOM of the original document, if it appears within that DOM at all? Or are the two documents treated entirely separately?
Yes, I know, I could experiment to see what works. However, I know enough about HTML to know that what happens to work, for now, may not be the correct way to do things. I am not expecting anyone to list out all the rules here, but if someone could post some links I would much appreciate it. This is a topic that has proven exceeding difficult to search the internet for.
In 13.5 Notes on embedded documents, I believe I have found the answer to both of my questions. The second paragraph says,
An embedded document is entirely independent of the document in which
it is embedded. For instance, relative URIs within the embedded
document resolve according to the base URI of the embedded document,
not that of the main document. An embedded document is only rendered
within another document (e.g., in a subwindow); it remains otherwise
independent.
So, yes, as both #Quentin and #Sinan said, it would require the embedded .html file to be a complete, valid .html file. And, no, it would not become part of the DOM of the original document.
Thanks to everyone for their prompt assistance. The StackOverflow community continues to amaze me.
<object> is a way to include a generic media object.
An HTML document is an example of such.
The HTML spec doesn't describe a means to provide a fragment of HTML to a browser, only a complete document. There is no standard MIME type for a fragment of HTML.
Therefore: You should use complete HTML documents.
That said, if you are going down that route, you would almost certainly be better off using <iframe> which has a much more featureful and robust set of APIs and documentation surrounding it.
How does this appear within the DOM of the original document, if it appears within that DOM at all?
As an object element. The child nodes of which are whatever alternative content you provide between the start and end tag.
Or are the two documents treated entirely separately?
Yes, much like an iframe.
<object> in HTML5 and <object> in HTML4.
The object element represents external content, which, depending on the type of the content, will either be treated as an image, as a nested browsing context, or as external content to be processed by a plugin.
Motivation from HTML4:
Previous versions of HTML allowed authors to include images (via IMG) and applets (via APPLET). These elements have several limitations:
They fail to solve the more general problem of how to include new and future media types.
The APPLET element only works with Java-based applets. This element is deprecated in favor of OBJECT.
They pose accessibility problems.
To address these issues, HTML 4 introduces the OBJECT element, which offers an all-purpose solution to generic object inclusion. The OBJECT element allows HTML authors to specify everything required by an object for its presentation by a user agent: source code, initial values, and run-time data. In this specification, the term "object" is used to describe the things that people want to place in HTML documents; other commonly used terms for these things are: applets, plug-ins, media handlers, etc. (emphasis mine)
So, basically, <object> elements are pretty generic. The only real condition is that there needs to be some kind of functionality on the client side to render the element.
For example:
<object data="test.html" height="50" width="50"></object>
renders the contents of test.html in a tiny area (no scaling!) with Firefox whereas links just displays [OBJ].
Embedded Content explains what happens when an <object> element is encountered.
Due to the algorithm above, the contents of object elements act as fallback content, used only when referenced resources can't be shown (e.g. because it returned a 404 error). This allows multiple object elements to be nested inside each other, targeting multiple user agents with different capabilities, with the user agent picking the first one it supports. (emphasis mine)
I believe that answers the question of how the <object> enters the DOM. If it were any other way, for example, element ids in included documents could trample on the DOM of the host page.
Regardless of what capabilities you observe in current user agents, you should ensure included HTML documents are well-structured, and valid.
Further down, consider the included example:
In this example, an HTML page is embedded in another using the object element.
<figure>
<object data="clock.html"></object>
<figcaption>My HTML Clock</figcaption>
</figure>
Note the example refers to an HTML page — not a fragment.
What is the "correct" way to deactivate tooltips on a given page so that the title attribute of a tag does not get shown?
There is no specific "correct" way.
If you don't want a title on an element, don't put one there.
If they must exist, you can use JavaScript to remove the title from any element you need to.
The issue here is that how the attribute is displayed is browser dependent - the spec says so:
Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object).
The fact that they display as a tooltip in most visual browsers does not mean they have to be. And there is no specific standard mechanism to "disable" this behavior.
One of the 508 compliance rules are that all OBJECT tags should contain element content. I'm not familiar with OBJECT tags or anything, but what should the content usually be? I noticed if I just put any string within the OBJECT tags I seem to pass the 508 test.
Is it acceptable to put anything within the OBJECT tags to make this pass verification? Can I just put "useless string"? What effect does the content have?
The content should provide information equivalent to the embedded object.
Using an useless string will not make it 508 compliant. Thus, that wouldn't be acceptable if your goal is 508 compliance. Your automated test may report a pass, but it's not really compliant unless it has real content.
The effect of this alternate content? When a disabled person visits the website and their assistive software cannot process the embedded object, the software falls back to the alternate content. Let's say you embed a Flash presentation in the page. When a blind person visits the site with a screen reading software, the screen reading software might not be able to parse the Flash movie. Instead, it reads out the text that is in the alternate content.
The content is for fallback in the case that the browser for any reason cannot display the object. Think of it as like the alt attribute for <img> elements. An automated checker can't verify that you are putting something sensible in, only that you've put something in.
It's your responsibility to make that content sensible. It should provide the best possible equivalent in text (or other HTML) that you can provide that conveys the same information as would have been conveyed by the object had it been displayable.
What is the difference between the two?
The Browser Object Model is a larger representation of everything provided by the browser including the current document, location, history, frames, and any other functionality the browser may expose to JavaScript. The Browser Object Model is not standardized and can change based on different browsers.
The Document Object Model is standardized and is specific to current HTML document. It is exposed by the Browser Object Model (i.e., DOM is a subset of BOM).
BOM
This is an informal term as there is no W3C or WHATWG standard that mentions it.
One simple definition would be that the BOM encompasses the entire object structure which is accessible via scripting in the browser, beginning with the window object which "contains everything else", since it's the global object.
The window object contains lots of properties (try console.dir( window );). These properties are specified in numerous web-standards. The "core" specification of the window object is as of now still specified in the HTML standard - see here, but I guess it's only a matter of time until the editors decide to transfer this specification into a separate standard. I'm definitively rooting for a "BOM" or "Browser Environment" standard to make things more logical and appropriate.
DOM
This on the other hand is a formal term. You can find definitions of this term in various standards, for instance the DOM4 standard states:
The DOM is a language- and platform neutral interface that allows
programs and scripts to dynamically access and update the content and
structure of documents.
Notice how the emphasis is on documents. Unlike the BOM which is basically and umbrella term for all the APIs in the browsers, DOM are only those APIs which deal with documents.
A simple definition would be that the DOM is implemented as the document object (which is the root of the DOM tree btw). Basically, the DOM tree (and everything inside it) can be considered part of the DOM. Analogously, everything beyond the DOM-tree is not part of the DOM.
beyond the DOM-tree == all the properties of window except the document object
"Browser Object Model" (BOM) is a term from the early 2000s that didn't catch on and was replaced[1] with the term "Web APIs"
Web APIs are the JavaScript APIs available to web pages: any objects/interfaces, their properties, methods, and events the browser makes available to the page, except for the objects, like String, that are part of JavaScript language itself.
The DOM (Document Object Model), in context of web development, is a subset of Web APIs concerned with manipulation of the structure and contents of web pages and other "documents".
Historically, the DOM was designed as "a platform- and language-neutral interface" with DOM Level 1 specification describing both the ECMAScript (JavaScript) and Java bindings in appendices. You might still use DOM APIs to work with XML/HTML data from outside the browser (e.g. using Xerces in Java), but the "Living Standard" version of the DOM specification is maintained with the focus on the web use-case, and the most recent W3C implementation report includes mainly (if not only) web browsers.
[1] See Google trends for "Browser object model", and how in a modern book (JavaScript Cookbook: Programming the Web) it's only briefly mentioned as 'BOM - see Web API'.
[answer rewritten in 2019]
i think BOM=DOM +(-) non standard properties of the browser. so every browser has its own BOM
BOM is wider view of entire browser where as DOM is ristricted to document window and associated methods. view complete article
javascript-browser-object-model