Andy Hefner says:

That one data structure can always be decomposed into multiple data structures with equivalent meaning doesn’t imply it’s unquestionably incorrect not to separate them. That two things can exist separately doesn’t mean it’s wrong to combine them, particularly when they are intimately related, and the alternative is maintaining redundant state which must be kept synchronized. That’s the problem with dogmatic proclamations. Understanding where to draw the line is crucial to optimizing both machine efficiency (via less storage and runtime effort) and programmer efficiency (via less code and fewer bugs). The complexity of a system grows exponentially with each such layer of decomposition. Is the stopping point arbitrary? I claim it is an engineering compromise, informed by the anticipated value of additional modularity, with the prerequisite that one structure can be mapped onto another without loss of information.

Certainly you would not check pixel values to determine if a menu is open. The mapping from semantic elements to rendered pixels is immensely complex and seldom invertible. You might reasonably ask the UI toolkit if the menu is open. You can, as you suggest, keep track of this yourself, but you must anticipate every way the menu might become closed: both by the operating system, or by other code in your application – perhaps written by someone else – that bypasses your intended function for changing this state. If you don’t insist on recording this information yourself, you write less code, and with a single definitive source there is no possibility of inconsistency. This is what you are arguing against.

An aside: The pixel example is, by coincidence, relevant to a point I’ve been thinking about lately. Game systems from the early 80s did something that seems unthinkable by modern standards of software hygiene: collision detection was often handled directly by the video hardware. Semantics and presentation, completely conflated. Yet, as a programmer, the choice is that of checking a few flag bits indicating collisions between objects and/or the background, or performing a separate pass through the objects to check for collisions yourself. It makes sense to use the information if the hardware provides it, and it makes sense for the hardware to provide it, because it’s just a few extra AND gates and flags to add there, versus an expensive and complex loop in software. This choice imposes constraints on the application, yet often it was the correct one. Where it wasn’t, a price was paid in complexity and (potentially) performance. To my surprise, just when I thought this kind of coupling was relegated to the past, it emerged in modern systems with a new twist: the hardware occlusion query. Meanwhile, I think about efficient 2D collision detection in sparse environments. In the past, I’ve used spatial hashing. In the future, I may use a quadtree. It pleased me to realize that, in the service of detecting collisions, a quadtree can also contain all the information needed to render the objects, storing pointers to transformed rectangles of pixels in the leaves, and it’s conceivable that simple hardware could output video directly from the tree with no intervening framebuffer (though perhaps less simple if it tries to make the most of the available memory cycles). Indeed, a quick Googling indicates direct scan conversion of quadtrees has been researched.

That said, hiding application state in the DOM tree sound like a dubious proposition. However, is menu visibility truly important application state, or an irrelevant property of the menu’s presentation? Core application logic should only care when a menu item is selected, and not about the menus themselves at all, as the most starry-eyed proponents of “Model-View-Controller” architecture will insist. That patterns or philosophy can guide the way without always being reified, in excruciating detail, as code and data, is a point too often overlooked, and the cause of much unnecessary labor and suffering.