Blunder Dome Sighting  

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

Click for Blog Feed
Blog Feed

Recent Items
Republishing before Silence
Command Line Utilities: What Would Purr Do?
Confirmable Experience: What a Wideness Gains
Confirmable Experience: Consider the Real World
Cybersmith: IE 8.0 Mitigation #1: Site-wide Compat...
DMware: OK, What's CMIS Exactly?
Document Interoperability: The Web Lesson
Cybersmith: The IE 8.0 Disruption
Cybersmith: The Confirmability of Confirmable Expe...

This page is powered by Blogger. Isn't yours?

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
Millennia Antica: The Kiln Sitter's Diary
nfoWorks: Pursuing Harmony
Numbering Peano
Orcmid's Lair
Orcmid's Live Hideout
Prof. von Clueless in the Blunder Dome
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
DMA: The Document Management Alliance
DMware: Document Management Interoperability Exchange
Millennia Antica Pottery
The Miser Project
nfoCentrale: the Anchor Site
nfoWare: Information Processing Technology
nfoWorks: Tools for Document Interoperability
NuovoDoc: Design for Document System Interoperability
ODMA Interoperability Exchange
Orcmid's Lair
TROST: Open-System Trustworthiness



Confirmable Experience: What a Wideness Gains

[Here’s another confirmable experience cross-posting.  There’s some food for thought here for having displays that support your own productivity and enjoyment of sessions at the computer.  There’s also something to be cautious about when assuming things about the ways users experience the interfaces that you implement.  I know that I often design interfaces for myself, and that may be far short of what is workable for another who doesn’t approach their work in the same way and who doesn’t have the same computer setup.]

Four years ago, I replaced a failing 21” CRT display with a 20” LCD monitor.  The improvement was amazing.  I have since upgraded my Media Center PC with a graphics card that provided DVI output and there was more improvement.

But the greatest improvement came when the 20” LCD monitor recently began to have morning sickness, flickering on and off for longer and longer times before providing a steady display.  Before it failed completely, I began shopping for the best upgrade on the competitive part of the LCD monitor bang-for-buck curve. 

These days, 24” widescreen LCD monitors are the bees knees.   For almost half what I paid for the 20” LCD in 2004, I obtained a 1920 by 1080 DVI LCD (Dell S2409W) that is not quite the the same 11.75” height but is 21” wide.  The visual difference is dramatic when viewing 16:9 format video and also when viewing my now-favorite screensaver.  I added a shortcut to my Quick Start toolbar just to be able to watch the screensaver and listen to the bubbles while making notes at my desk.

I'm tempted to zone out over the screen-saver (click for full-size image)

One of the problems I had with the 20” old-profile (6:4, basically) was that I could not work with multiple documents open at the same time.   I don’t mind only having one fully on top, but I often needed to be able to switch between them easily.  In some standards-development work that requires comparison of passages in different documents, it was also tricky to have them open in a way where I could line up the material to be compared and checked.

The wider display permits having more of an application open, such as Outlook, and it also allows access to additional open material. 

What I hadn’t expected was the tremendous improvement that becomes available when there is a 21” task bar at the bottom of the screen.   I did not expect an advantage there as the result of the wider display.  That alone has made my working at the computer more enjoyable and more fluid. 

My desktop is still too cluttered with icons and I am still tidying them up, removing ones that I rarely use.  Even so, the perimeter of the display provides for more icons on the outside of the central work area so that I can find them without having to close or move application windows.  That’s another bonus.

Wideness gains more than height (click for full-size image)

I must confess that I haven’t had so much fun since I progressed from Hercules-graphics amber monitors to full-color displays in the early 90s.  It is sometimes difficult to realize that it wasn’t that long ago.

Oh Yes, the Confirmable Experience …

There are two confirmable-experience lessons here.  First, the subjective experience I am having is mine.  The wide-format monitor is an affordance for my heightened excitement and enjoyment, but the experience is mine.  Others have different reactions and, in particular, have their own ideas about display real-estate, task bars, and other user-interface provisions.

For the second lesson, recall how much emphasis I give to using a screen-capture utility for computer forensic and trouble-reporting work.  That will often provide important out-of-band evidence for a problem that one user is seeing and that another party does not.

These screen captures provide similar evidence of what the wider-format display provides for me.

They don’t provide any assurance that you will see them the same way I do, however.  If you click through to the full-size images, you’ll see a rendition of the same bits that my display shows me.  I assure you that the image I see when replaying those bits to my screen is exactly the same as the one I took a screen capture of.  

There are a number of ways that your experience will be different.   At the most fundamental level, there is no way to know, using these images only, to determine whether the color presented for a particular pixel on your display is the same that I see on mine.   The PNG files do not reflect what I saw.  They do faithfully reflect what my software and graphics card used in the internal image that was presented via my display.  But we have no idea whether your computer is presenting the same color using the same bits.  There are other differences of course, in that gross features may not be viewable in the same way my monitor allows me to see them (unless yours has at least the 1920 by 1080 resolution that mine does).  This is all there to interfere with our sharing this particular experience of mine even without allowance for our different vision and subjectivity influences.

The takeaway for this part is that context matters with regard to what qualifies as a confirmable and confirmed experience.  It’s also useful to notice how many different aspects of the computer bits to displayed pixels pipeline can influence whether or not I have successfully shared relevant aspects of my experience with you.

And we do manage to make it all work, most of the time, for most of us.

Labels: , ,



Confirmable Experience: Consider the Real World

[cross-posted from Orcmid’s Lair, essentially for the reasons stated here.]

Clarke Ching just posted a great illustration of a confirmable-experience situation.  Until a set of comparative photographs was available to illustrate some different experiences, he and his wife did not know how to understand a difficulty that one had and the other did not (and check the follow-up for more important reality). 

This is the entire crux of it. 

I often go on about the importance of confirmable experience in the area of trustworthy and dependable systems.  Providing confirmable experience is something software producers (and motivated power users) need to pay attention to.  Clarke provides the Cool Hand Luke reality version.  Sometimes communication is not simple and it is important to remove the barriers.

I posted this on Orcmid’s Lair and I also wanted to drag it into my confirmable-experience cybersmith collection too.  I want it there because it is so juicy, even though this is not my main confirmable-experience category location.  Well, I think not.  I will resolve it for now with cross-posting.  Sometimes, I need to make a mess to know that is not the way to do it.  Now I have to dig my way out of it.

Labels: , , ,



Document Interoperability: The Web Lesson

[update 2008-09-08T00:24Z Cross-posted from Pursuing Harmony because of the overlap with convergence of HTML, web standards, and the IE80.0 mitigation that is touched on here.]

"are there alternatives to google groups search for searching old USENET messages? because groups date fielded search is teh broken."

-- Richard Akerman on Twitter, 2008-08-31 

Be prepared for a dramatic shift in the reality of web-site browsing and the honoring of web-page standards.   The pending release of Microsoft Internet Explorer 8 is going to put the reality of web standards and their loose adherence in our faces.  Although Internet Explorer is indicted as the archetypical contributor to disharmony on the web, Internet Explorer 8 is going to challenge all of us to deal with the reality of our mutual contribution to the current state of affairs.

Here is a lesson, probably many lessons, for document interoperability and the way that standards for document formats evolve and harmonize, or not, over time.

The Web as Clinical Science

The movement from loosely-standard pages and their browsing to strictly-standard pages and standards-mode browsing will illustrate every aspect of the same challenge for office-productivity documents and the office suites that process them. 

Web pages are the experimental drosophilae of digital documents.  All aspects of dynamic convergence on standards, themselves evolving, and the forces of divergence, are demonstrated clearly and rapidly.  I expect it to take Internet generations for significant convergence, with no static level of standards adherence anywhere in sight.  It took us almost 20 years to get to this point on the Web; I figure it will take at least five more to dig out of it far enough to claim that there is a standards-based web in existence and in practice.  I'm optimistic, considering that HTML 5, the great stabilization, is not expected to achieve W3C Recommendation status until 2012.

No document-interoperability convergence effort is anywhere close to the promising situation of the web as Internet Explorer 8, HTML5 implementations, and other compatibility-savvy browsers roll out over the next several years.  It is useful to use that situation to calibrate how convergence and interoperability could work for document interoperability.  There are significant technical barriers.  The non-technical barriers are the most daunting.  That should be no surprise.

Versioning in Document Use

I've written on Orcmid's Lair about the IE 8.0 Disruption.  This involves changes in Internet Explorer 8.0 by which web pages are rendered in standards-mode on the assumption that pages are conformant with applicable web standards.  In the past, it was presumed that pages were loosely-standard and browsers, also loosely-standard, made a kind of best effort to present the page.  The consequences have been explained marvelously in Joel Spolski's post on Martian Headsets.

We are similarly relying on document-format standards as a way to provide for many-to-many interchange and interoperability between different (implementations of versions of) document-format standards and different (implementations of versions of) processors of those digital documents.  That means we have a version of the loosely-standard documents with loosely-standard processing problem.  We can't be strictly standard because the standards can't (and definitely don't) have strict implementations at the moment; and there are many ways that specifications and implementations have been kept loose by design.  Accompanying that looseness by design is the the simple fact of immaturity among the contending document-format standards for office applications, particularly as vehicles for interoperable applications.

For office-productivity documents as we know and love them, there are five, count 'em five "official standards." 

The "Official" Public Standards of Office Documents

For Office Open XML Format (OOXML), there is the ECMA-376 specification of December 2006.  There is also the ISO/IEC 29500:2008 Office Open XML File Formats standard once it is made available.  IS 29500 will have some substantive differences from ECMA-376.  We won't have a solid calibration of the differences until the IS 29500 specifications are available and subject to extensive review.

For the OpenDocument Format, there is the Open Document Format for Office Applications (OpenDocument) v1.0 OASIS Standard issued 1 May 2005.  There is also the ISO/IEC 26300:2006 Open Document For Office Applications (OpenDocument) v1.0 standard (also on the publicly-available listing).  IS 26300 is for the same format as the OASIS v1.0 standard, but it is on a completely-separate standards progression.  Appendix E.3 accounts for the differences of IS 26300 from the text of the May 2005 OASIS Standard.  The first page of the IS 26300:2006 document (page 5 of the PDF) identifies its source as Open Document Format for Office Applications (OpenDocument) v1.0 (Second Edition) Committee Specification 1, dated 19 July 2006, derived from document file OpenDocument-v1.0ed2-cs1.odt; this is not another OASIS Standard, however.

The second and latest OASIS Standard for ODF is Open Document Format for Office Applications (OpenDocument) v1.1 issued 2 February 2007.  This document is derived from OpenDocument v1.0 (Second Edition) Committee Specification 1, the same specification that is the source of content for ISO/IEC 26300:2006.  The changes made to arrive at ODF v1.1 from the v1.0 (Second Edition) committee specification are detailed in Appendix G.4.  There are some mildly-breaking changes from ODF v1.0 to ODF v1.1, mostly of a clarification or correction nature.  There are a few additional features that have no down-level counterparts in ODF v1.0.

A third OASIS Standard, ODF v1.2, is under development.  The current drafts, using a very-different organization from v1.1, are available as pubic documents of the OASIS Open Document TC. 

We can expect to see more versions of ODF and of OOXML at their various standards venues.  We'll be watching here on nfoWorks as the situation becomes even more chaotic.  Notice that this diversity ignores the variety of divergent implementations of the various specifications.

Format Versions that Live Forever

It is possible for one document-format specification to officially supplant another, with the older specification deprecated.  That has not been done so far with any of the five-and-growing document-format specifications, any more than it has been done for most of the versions of HTML specifications that have been recommendations of the W3C (and IETF before the development track moved entirely to W3C). 

For example, the last full-up specification for HTML, the HTML 4.01 W3C Recommendation of 24 December 1999, has this to say about its immediate predecessor: "This document obsoletes previous versions of HTML 4.0, although W3C will continue to make those specifications and their DTDs available at the W3C Web site."  This was possible because HTML 4.0 was young and there were important defects that 4.01 cured.

The HTML 4.01 specification continues with the following recommendation: "W3C recommends that user agents and authors (and in particular, authoring tools) produce HTML 4.01 documents rather than HTML 4.0 documents. W3C recommends that authors produce HTML 4 documents instead of HTML 3.2 documents. For reasons of backward compatibility, W3C also recommends that tools interpreting HTML 4 continue to support HTML 3.2 [W3C Recommendation 14 January 1997] and HTML 2.0 [IETF rfc1866 November 1995 and the IETF-obsoleting rfc2854 June 2000] as well." 

The XHTML branch of specifications, originally derived from HTML 4.01, were intended as the basis for a future generation. 

Meanwhile, there has been work toward both XHTML 2 and HTML 5.0

HTML 5.0 is currently intended to exist alongside XHTML 1.x and its newer arrangements while also absorbing XHTML 1.x to some degree (by having an XML form).  The current HTML 5.0 draft specifies legacy processing (in its HTML-syntax form) for variations of over 60 HTML DOCTYPE DTD flavors, extending back to HTML 1.0 and other variants.  The intention is to converge HTML and XHTML 1.x under a consistent HTML 5 processing model with only no-quirks, some-quirks, and quirks modes.  This is also intended to end the variation and extension of HTML (not XHTML) by capturing <!DOCTYPE HTML> for its own and having a concrete HTML syntax that is fully-divorced from both SGML and XML.  It is important to point out that HTML 5 is not going to eliminate the divergence that browser (user-agent) plug-in models, plug-in implementations and scripting systems (especially client side) bring to the mix.

Document-format versions are not easily abandoned.  Even if production of a format is deprecated, consumption of the format may need to continue into the indefinite future, and certainly so long as emitters of deprecated formats have significant usage.  The W3C progression of HTML is at a point where that is fully-recognized and being honored in reaching toward an HTML 5 plateau sometime in the next decade.

Considering this promising stabilization, when would I manage to change all of my web sites and blogs to clean HTML 5 pages?  Not until I know that visits to those sites are only a small fraction of Internet Explorer versions prior to IE8 (or maybe IE9) and other browsers lacking full-up standards-mode processing.  Fortunately, the HTML 5 specification-effort promises to show me exactly how to do that in a mechanical way.  I am looking forward to automated assistance.  In my case, I'll also have the benefit of my IE 8.0 mitigation effort.  Other web sites may require other approaches, and user browser choice will involve important trade-offs for some time. 

I am surprised by the number of people who operate multiple browsers.  Although I operate multiple products for office applications these days, that's mostly to explore their interoperable use, not to ensure ability to interchange documents (well, not until I joined OASIS and the ODF TC).  I've been a serial adopter of Internet Explorer versions since IE 2.0.  As a typical late-adopter, I may finally branch out now just to have a better calibration of the migration to standards-based sites and browsers for them.

This is an important lesson for the management of the expanding variety of specifications of formats for office-application documents, formats of which HTML packagings are sometimes one of the flavors.

Reconciling office-application document-format versions does not promise to be so easy as the current effort to stabilize HTML for the web.

The Looseness of Document Specifications

Of course, OOXML and ODF are not close dialects off a single family tree, as HTML variants might be treated (and HTML 5 demonstrates, if successful).  In addition, the current specifications are not for same-conformance, interchangeable-everywhere documents:

  • There are weak conformance requirements.  It is not necessary to implement any particular amount of the specified format: OOXML or ODF.  This is by design.  I don't expect that to change.  There is also no way to indicate how much or how little is accepted and/or produced.  Well, you could look to see what software produced the document, using ODF as our example:

    <meta:generator>$Win32 OpenOffice.org_project/300m3$Build-9328

This strikes me as even less appealing than the challenge of sites adjusting for browsers and browsers adjusting to HTML DOCTYPE declarations (and their absence).
It is not encouraging that the office:version attribute and <meta:generator> element are both optional.  It is unfortunate that the office:version attribute is generally uninformative about the processing requirements for the document file in hand, serving merely as an automatic claim of one specification the document conforms to.  The document is also likely to conform to earlier versions and probably alter later versions, although it is unclear how we can determine that easily for a given document representation.

  • Arbitrary "foreign" elements are allowed.  I'm not clear how IS 29500 for OOXML will allow for this kind of thing, but the ODF specifications are justly-notorious for this provision (ODF 1.1, section 1.5):
    "Documents that conform to the OpenDocument specification may contain elements and attributes not specified within the OpenDocument schema. Such elements and attributes must not be part of a namespace that is defined within this specification and are called foreign elements and attributes.
    "Conforming applications either shall read documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place, or shall write documents that are valid against the OpenDocument schema if all foreign elements and attributes are removed before validation takes place.
    "Conforming applications that read and write documents may preserve foreign elements and attributes."

    There are some further wrinkles and this proviso:
    "Foreign elements may have an office:process-content attribute attached that has the value true or false. If the attribute's value is true, or if the attribute does not exist, the element's content should be processed by conforming applications. Otherwise conforming applications should not process the element's content, but may only preserve its content. If the element's content should be processed, the document itself shall be valid against the OpenDocument schema if the unknown element is replaced with its content only."

    As a developer, I love gimmicks like this.  But, basically, this only works with processors that re-encounter document files that they themselves produced.  Anything more coherent requires that the implementers of different processors form some sort of out-of-band, separate-from-the-standard interoperability agreement on particular foreign elements and handling of office:process-content attributes.  Users, confident that their software is "standard," will have frustrating and inexplicable interchange experiences (unless the usual thing is done and everyone agrees to lock in on the same software [version], surprise, surprise).

    OOXML has a versioning scheme that might provide controlled extensions that degrade usefully when processed by implementations of down-level specification versions.  It is unclear at this point whether this is just a more complicated way to end up with the same interoperability problems.

  • Some features require foreign content.   Both OOXML and ODF have features where content is represented by a binary-data part elsewhere in the package.  There is little (OOXML) or no (ODF) indication of what the format of the binary element is and what MIME types are allowed for such document components.  All use of those features and any interchange agreements about them are beyond the current provisions of the relevant document-format standards.
    There are other places where implementation-defined values are expected and are expected to be preserved by other implementations.

  • Some values and default selections are implementation-specific.  I was mining in the ODF specification the other day.  I did not expect to find attributes having text on these patterns:
    "The value of this attribute is implementation [or application] specific."
    "If this attribute is not present, the application might or might not display [whatever]."

    These are relatively minor considering the amount of variability from the other conditions already mentioned.  What's curious about these is the elevation of particular implementation-specific features as specification-favored. In the case of implementation-specific attribute values, there is also the interesting problem of a processor determining whether such a value is intended to have its implementation-specific interpretation or not.  It appears that the related features will only be useful under tightly-restricted interchange conditions.
    I will not be surprised to find similar looseness in the OOXML specification, IS 29500.

Prospects for Interoperable Convergence

We already have before us difficulties with interoperable convergence of individual progression of a single standard and its variety of implementation.  This makes the prospect of harmonization between different standard formats rather murky.

Desktop office-application software has more promise with regard to application of Postel's Law, to be liberal in what is accepted and conservative in what is produced.  Unfortunately, the current specifications do not require conservative, interoperable implementations; the current specifications are arguably antagonistic to such an achievement.

I suspect that this is an unintended consequence mixed with some inattention to what it takes for interoperability to be achievable. 

It remains to see how our experience and understanding matures.   We are at the beginning, not the finish.  The journey may seem endless.

The process of IE 8.0 mitigation and preparation for a standards-mode approach to web browsing impacts this site and blog as well as every other web page I have ever posted (somewhere over 120MB worth and climbing).

I'm not going to say anything more about IE 8.0 mitigation and HTML harmonization here.  The overall effort will be tracked in that category of Professor von Clueless posts; that's the place to follow along.  The lesson for document interoperability is something that is definitely appropriate for Pursuing Harmony; there'll be much more to say about that.

Labels: , , , , ,



Cybersmith: The Confirmability of Confirmable Experience

Finding ways for the experience of users to be confirmable by the producers of software is increasingly difficult as we operate with distributed applications over networks and the world-wide web.  Because we can't directly show another user or the software producer what our experience is, we need forensic tools that allow us to capture and communicate the locally-observed behavior to others who are elsewhere.   I always keep screen capture software handy.  An experience with the new Internet Explorer 8 beta 2 release demonstrates the value of that.

Screen Capture: the Primo Confirmability Utility

One of the most-important tools for cybersmiths, including power users, is a screen-capture utility.  Whenever I set up a new computer, my favorite screen capture utility (currently HyperSnap 6.30) is one of the first two products I install.  (The other is WinZip for its value in addition to the built-in Zip capability of Windows Explorer.  That's actually in a three-way tie with my password-safe utility and Microsoft OneCare.)

If I could count on a screen saver being available during initial set-up (even log-on if that were possible) and configuration of a new computer's operating system, I would be even happier.  I want a screen-shot record of everything that I go through and of every option and setting and parameter that I choose.  I do the same thing whenever I am installing a new software package for the first few times.

And whenever there is an unusual incident, I start grabbing screen shots as long as I am able.  If I can't make screen captures, I will grab my digital camera or (though needing to get the hang of it still) my Windows Mobile cellular phone.

Although there is limited screen capture capability built into systems like Windows, I rarely want the entire screen.  Also, I want to save in a loss-less compact format, almost always preferring PNG format.  This format is easily included in e-mails and posted on a web site to back up an incident report or provide documentation of something interesting.  All of the VC++ Novice screen shots have been created this way.

Screen Capture: Do You See What I See?

In today's world of distributed applications, one of the greatest difficulties is dealing with interoperability problems (e.g., garbled e-mail messages, broken web-page presentations, and document viewing/presentation glitches).  Even if an offending file or document is sent back to the source with an incident description, the recipient may not see what you saw.  Reproduction isn't even the first problem.  Clearly seeing what it is you experienced is the first problem.   There needs to be an out-of-the-failing-channel way to deliver a visible rendition of what you are seeing.  Sending a screen shot will do that. 

Confirmable Experience for Trustworthiness

This ability to report your experience in a way that a distant party can confirm it is a critical need in today's richly-variable and richly-connected world.  I expect that we will eventually rate software and its support by how well it lends itself to confirmation of user experiences, along with easy reproducibility and remedy of unexpected situations and usability difficulties.  The first step is to be able to demonstrate what happened in a simple way.  Today, use of screen shots is one of the easiest and reliable ways to do that.  There often needs to be an accompanying narrative and any data or files involved, but the screen captures are essential for clarity.

My colleague Bill Anderson and I use the term "confirmable experience" almost habitually when discussing interoperability breakdowns, inscrutable installation instructions, and the occasional flagrant exhibition of system incoherence.

There's another kind of confirmable experience, and it is the one I can avail myself of as a developer and software producer.  There are many cases where I need to find ways to confirm what kind of experience my software products (including web pages) are providing and what the breakdowns are.   Screen capture is useful for documentation and demonstrations as well as being an important forensic tool.

An Example with Internet Explorer 8.0

I am one of those people who provides an absolute minimum of testing for web sites and blog pages.  I figure that if the material shows properly in my authoring tools and also in my usual browser (yes, Internet Explorer), I am on safe ground.  Also, because I do not use scripts and I have static pages almost entirely (with the occasional embedded video frame), I rely on pretty-simple HTML. 

I also figure that I am fairly safe from problems with standards-strict browsers of various flavors.  I make sure that my recent web pages are in UTF-8 (to minimize character encoding issues) and have an unassuming DOCTYPE declaration (for HTML 4.01 transitional mainly).

I've never received a report about rendering difficulties with my web pages, although that's not a reliable test.

Knowing that Internet Explorer 8.0 is going to usher in a period of widespread standards-strictness, I figured that I was still relatively safe.  Just the same, when IE 8.0 beta 2 was released the other day, I decided it was time that I took my chances with the browser in order to find out how well my sites will be viewed (expecting an immediate "pass" grade of course).  Another value of confirmable experiences is separation of fantasy and magical thinking from reality.  Sure enough ...

Once I had installed IE8 beta 2, my first check was with my default home page,, where I regularly check the weather, headlines and movie listings for my favorite local cinema.  The page passed the eyeball test, although I now see that there is a broken-compatibility indicator compatibility-view button.  The indicator really does disappear when a page is "clean," specifically selected in compatability view or standards-mode, as I can see on some other pages.  If there is an indicator and I push it in (it is a push-on, push-again-for-off button), I can see minor changes on that home page.  This is exactly what I want for a site-forensic tool, and IE8 makes it easy for me to review my site, find the discrepancies and, if serious enough, repair them.  There is also a third case, where I add metadata to pages or an entire site so they will be automatically-recognized as non-standard under compatibility view and treated in a forgiving way by IE8 the same way its predecessor had by default.  Finally, users of IE8 can select compatibility with loosely-standard pages themselves, and IE8 will remember that selection on a page-by-page domain basis.

Illustration of IE8 beta 2 Compatibility Control: (a, left) strict presentation with compatibility defects, (b, center) rendering with relaxed rules, (c, right) absence of indicator with fully-standard page

(a) IE8 strict interpretation with compatibility indicator (click for larger image)

(b) When compatibility is selected, IE8 provides loose interpretation (click for larger image)

(c) IE8 recognition of strictly-compliant pages has no indicator (click for larger image)

Notice, also, that the experience I had is with my, not yours or anyone else's.  This is an easy way to demonstrate to someone what my experience is, no matter what their own checking reveals.  I love how this is working out.  And of course, my simpler pages would fare well.  Sure ...

Not So Fast, Sparky

One of the oldest web pages that I still have on a site is the home page for Orcmid's Liar,  This is a trivial page, essentially a place-holder for riches yet to come, while I distract myself with blogging, other content, and little concern for this site's puny entrance.  I expected this to be a no-brainer.

Whoops: Presentation of my home page in IE8 beta2 strict-standards mode is unbelievably ugly.
Strict-standards rendering is terrible and incompatibility is indicated (click for full-size image)

The result is terrible.  The single-row, three-column table at the top of the page is mangled.  There is text missing from the central cell and the table does not span across the width of the page as intended.  It looks like the table has been wrapped on the page with the third cell below the first two.

Compatibility mode (that is, loose enforcement of standards with a best-efforts rendering) provides what I am accustomed too:

Expected result: Viewing under the forgiving compatibility mode provides the expected rendition.
Compatibility mode of IE8 beta2 provides the expected view (click for full-size image)

This is a common page top-heading format used throughout my web sites.  I nosed around to see if they all render so badly in IE8 strict standards mode.  There are incompatibilities, but not the one seen on the Orcmid's Lair home page. 

While wandering around, I noticed another problem.  Sometimes when I return to the home page, viewed in strict standards mode, by back-paging from a different page, I see a rather different incorrect version.  This one is peculiarly almost-right:

Erratic strictness: If the page is visited, navigated through, and then back-paged back, the strict rendering is different.
Revisiting the defective page by paging-back from another site page almost has the expected rendering (click for full-size version)

Exactly Whose Experience Are We Experiencing?

Granted, my home page is not strictly-standard according to IE8 beta2, and it is presented properly only with the forgiving compatibility mode for loosely-standard HTML.  At the same time, absence of consistent behavior is an indication that there may still be defects in the IE8 implementation of strict-presentation in accordance with web standards.

I was still left with the problem of straightening this out.  It seemed to me that the page is simple enough that I could repair the page and not resort to the special meta-tag to request compatibility mode in browsers, such as IE8, that will recognize and automatically accept loosely-standard pages and render them as well as IE7 does.

I attempted to edit the HTML, making adjustments to the 3-column table that I though might help.  There was no change.  But there are other pages on the site with the same 3-piece top heading and those render fine.  So I copied one of the successful 3-column tables in place of the current one, edited the text appropriately, and found success:

That's more like it: The repaired table, shown in this narrower view, is presented just fine in IE8 beta2's strict-standards processing.
Repaired welcome page renders the title properly although there are apparently minor incompatibilities somewhere on the page (click for full-size version)

The compatibility button has not disappeared, and there is more to accomplish.  But the ugliest part has been repaired successfully.  I'm not sure what the difference was, so there is more to learn.  

The next action, for me, is to use an HTML validator that lets me attest to the validity of the pages on my sites.  That will come later as I find occasion to review all of the pages, treating the most-embarrassing glitches first.

I also must deal with the fact that all I have done so far is treat symptoms, without a clue regarding the underlying cause.  This is particularly bothersome because the cause might be the beta2 status of IE8 and not entirely a matter of a page's non-standardness.

This post has more confirmable-experience dimensions than revealed by the immediate content:

  1. It is a prospect for confirmation of standards-compliant presentation via IE8 beta 2.
  2. It is my first use of Blogger Labels (Categories in other blogging systems) to archive posts by categories as well as having weekly chronological archive pages and the buckets of individual posts made in the same month.
  3. I am using Windows Live Writer image-uploading capability to FTP images to a directory of the blog and this is the maiden exercise to confirm that is functioning properly.

All of those arrangements are being explored with this single post.  There's a principle about making only one change at a time that I am neglecting.  OK, I feel lucky.  This is the Blunder Dome, after all.

Update 2008-08-30T16:43Z I made some awful errors ("two-days" instead of "todays") and chose to tweak the page.  I also notice that there are more problems that I don't know what to do with.  It is time to come up with an IE8 mitigation approach.  Stay tuned.

Update 2008-08-30T18:24Z I did achieve the three tangential objectives.  As a result of that and the experience reworking the home page, I am adding an IE8.0 mitigation category for this post and others to follow on this and other blogs of mine.

Update 2008-08-31T02:46Z After developing further analysis and checking out further resources from Microsoft, I realized that I misunderstood the significance of the Compatibility View and what has the button be present.  This page has been touched up accordingly.

Labels: , , , , ,

Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $