XPath - intersection of nodesets

Is it possible to perform an intersection of nodesets within an XPath And if possible... Is there a somewhat elegant way to do it Seemingly it's not difficult with XPath 2.0, however with the HD spec we're using a subset of XPath 1.0.

The most common reason anyone would want to do this -- since elements can have multiple classes, let's say we'd like to select all elements with class('a') AND class('b'). The class() function involves a built-in (which is probably optimized / indexed on DOM load) split() or tokenize() on the "class" attribute string, and it would be hard to mimic this ability looking at @class directly.

Answer this question

XPath - intersection of nodesets

CharlieRussell
I realized what the problem was -- this may (or may not) be instructive...

I had several <div> elements, each containing several buttons. At any moment, all <div>s had style:display="none" except for one which had style:display="auto". I wanted to cause the focus to automatically be set on a tagged (via a class called "first") button based on the currently-visible <div> changing. Essentially, each <div> represented a "tab" or "page", only one of which could be visible at a time. The code I used looked like this:

<cue ... select="//button[style:display()!='none' ...]"></cue>

What this did was to select either a button in ALL <div>s, or none. With style:display="inherit", none were selected. With the above code, all were selected. I verified that the display on the <div> itself was being set properly, since the <cue> shown above was inside the same <par> which triggered when the current <div> became active to set it's display to "auto".

...and that's where the problem lay: since at the moment the <cue> to set focus became valid, the visibility of the current <div> had been set, but being in the same timing block, hadn't yet affected the document -- thus ALL <div>s were still "none". So style:display="inherit" was necessary in the markup, but gave the correct results.
Alagu Thirunavirkarasu

Can you be more specific as to the steps you took to check style:display() on the child The following code snippets showed me that the Animated Property API does return the animated value, and not "inherit", when run in the newest ihdsim in the Jumpstart kit. Let me know if your steps or results are different.

Markup snippet:

<div id="foo" style:display="auto" style:position="absolute" style:x="33%" style:y="50%" style:height="50%" style:width="25%" style:anchor="center" style:backgroundColor="green">

<button style:display="inherit" id="foobut" style:opacity="0.0" style:width="100%" style:height="100%" style:backgroundColor="red"/>

</div>

Code snippet:

setMarkupLoadedHandler(markupLoaded);

var timer = createTimer("00:00:01:00", TIMER_APPLICATION, timerFire);

function markupLoaded()

{

var foo = document.foo.style.display;

var bar = document.foobut.style.display;

document.foo.style.display = "none";

timer.enabled = true;

timer.autoReset = false;

}

function timerFire()

{

var foo = document.foo.style.display; // <-- this is now "none"

var bar = document.foobut.style.display; // <-- this also returns "none", inherited from its parent

}
DiamonDogX
I take back what I said about the "display" attribute. It does not report the immediately visible status. Also, using style:display="inherit" on a child element and setting the parent element using style:display="somevalue", then checking style:display() for the child does not return the immediate setting inherited "dynamically" from the child's ancestral nodes.

This leaves the question open as to how to determine the actual display state of an element on the screen.
Malleswar
Reporting back from the trenches -- contains() works well (in iHDSim) for selecting an intersection of elements with a combination of classes.

WRT inheritance of "display", using style:display() works well. I recall reading in the spec that this returns the currently animated state of an element, which would be how it appears on screen (regardless of how it was last set) -- so I'm assuming based on this that even if you have a scenario where A begat B begat C, setting A.style.display='none' and B.style.display='auto', checking B's style:display() would still return 'none. (Who needs C for this example, anyway ) The spec & player would be the final arbiters though.

Thanks.
jturpin

Yeah, contains() may be expensive (though I don't know for certain how expensive).

Whether the engine short circuits logical expressions is likely implementation-dependent. I don't know whether the simulator does offhand (though I hope it does).

I don't know the answer to your 3rd question regarding inheritance of style properties and what the xpath function will return. I'll look into this (or let someone else answer in the meantime if they know immediately).
BradyGuy
Thanks, I like that: "creative use"...

Wouldn't using a function like contains() be very expensive if part of a "begin"

Does the engine short-circuit "and" evaluation If so, contains() should be the last part of the expression. Would something like this work

begin="//*[style:display()='auto' and contains(@class,'c1') and contains(@class,'c2')]"

That brings up yet another question -- is the actual value of style:display() inherited For example, if a <div> close to the root is set to display="none", and an XPath statement references @style:display or style:display() of one that <div>'s descendant nodes, will the value returned also be "none" If not, what would be a good way to determine an element's visibility based on the visibility of its ancestors, given that XPath axes aren't available
steele_angel

You are correct, XPath 1.0 (and thus HD DVD's subset of it) doesn't have an intersection operator, so unfortunately it's not possible to do what you want cleanly. A solution to do this would likely involve creative use of the contains() string function.
XPath - intersection of nodesets

Answer this question