Mozilla XML - scrollIntoView for XML documents

Author

scrollIntoView for XML documents

conor325

2005-04-04, 12:35 pm

for HTML and XHTML (http://www.w3.org/1999/xhtml), the function
scrollIntoView allows you to pick an element in a document and make it
visible in a browser frame or window. However our texts are XML files,
specifically XHTML 2 with "section" and "h" and other tags specific to
that standard. Firefox treats them, as it should, as "plain XML" but it
doesn't support scrolling to a point for such documents ... or does it?
Is there a way to dynamically make an arbitrary element in a displayed
XML document visible?

Martin Honnen

2005-04-04, 12:35 pm

conor325 wrote:

> for HTML and XHTML (http://www.w3.org/1999/xhtml), the function
> scrollIntoView allows you to pick an element in a document and make it
> visible in a browser frame or window. However our texts are XML files,
> specifically XHTML 2 with "section" and "h" and other tags specific to
> that standard. Firefox treats them, as it should, as "plain XML" but it
> doesn't support scrolling to a point for such documents ... or does it?
> Is there a way to dynamically make an arbitrary element in a displayed
> XML document visible?

You could implement that with script if arbritary XML elements had
offsetLeft/Top/Parent properties but they don't have that with Mozilla.

Opera 8.00 beta seems to expose those properties to XML elements so I
have a simple test case with Opera 8.00 beta where you can do

function getPageCoords (element) {
var coords = null;
if (typeof element.offsetLeft != 'undefined') {
coords = { x: 0, y: 0 };
while (element) {
coords.x += element.offsetLeft;
coords.y += element.offsetTop;
element = element.offsetParent;
}
}
return coords;
}

function scrollElementIntoView (element) {
/* desirable but does not work
if (typeof element.scrollIntoView != 'undefined') {
element.scrollIntoView(true);
}
*/
var pageCoords = getPageCoords(element);
if (pageCoords) {
window.scrollTo(pageCoords.x, pageCoords.y);
}
}

The coordinates are not precise it seems as the scroll position seems a
bit wrong but the properties are there.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Martin Honnen

2005-04-04, 12:35 pm

Martin Honnen wrote:

> Opera 8.00 beta seems to expose those properties to XML elements so I
> have a simple test case with Opera 8.00 beta where you can do
>
> function getPageCoords (element) {
> var coords = null;
> if (typeof element.offsetLeft != 'undefined') {
> coords = { x: 0, y: 0 };
> while (element) {
> coords.x += element.offsetLeft;
> coords.y += element.offsetTop;
> element = element.offsetParent;
> }
> }
> return coords;
> }
>
> function scrollElementIntoView (element) {
> /* desirable but does not work
> if (typeof element.scrollIntoView != 'undefined') {
> element.scrollIntoView(true);
> }
> */
> var pageCoords = getPageCoords(element);
> if (pageCoords) {
> window.scrollTo(pageCoords.x, pageCoords.y);
> }
> }
>
> The coordinates are not precise it seems as the scroll position seems a
> bit wrong but the properties are there.

My bad, with Opera 8.00 beta the properties offset* and window.scrollTo
to it works correctly, my earlier test case had a problem.

Boris, if you are reading, would it be difficult the expose
offsetLeft/Top/Parent on arbitrary XML elements rendered in a window or
frame with Mozilla?

--

Martin Honnen
http://JavaScript.FAQTs.com/

Boris Zbarsky

2005-04-04, 12:35 pm

Martin Honnen wrote:
> Boris, if you are reading, would it be difficult the expose
> offsetLeft/Top/Parent on arbitrary XML elements rendered in a window or
> frame with Mozilla?

That's an interesting question. Just exposing the property wouldn't be so bad
(create a new nsIDOMNSElement interface and put it there). Problem is, it'd
increase the size of every single Element node by 4 bytes...

Once that's done, there's the question of _what_ the properties should do. For
example, what should offsetParent be for a random XML element? For comparison,
for HTML the offsetParent is more or less the nearest ancestor (in the rendering
tree, not the content tree, mind you) that is at least one of:

1) Absolutely positioned.
2) Fixed positioned.
3) A HTML <td>, <th>, or <table> node.
4) A HTML <body> node.

I guess for general XML we could keep the same rules... A little wacky to have
random XML depending on HTML in this way, but it's probably the only way to get
consistent results in mixed-namespace documents.

-Boris

conor325

2005-04-04, 12:35 pm

And would it then make sense to go "the whole way" and support
scrollIntoView for such mixed namespace documents too? Given that
Mozilla supports CSS styling and XPath resolution for arbitrary XML
already, add this and there is little or no reason to recompose XML
into HTML for viewing. With this triple, a pointer to any place in an
XML document is easy to render in a browser window.

Boris Zbarsky wrote:
> Martin Honnen wrote:
window or[color=darkred]
>
> That's an interesting question. Just exposing the property wouldn't
be so bad
> (create a new nsIDOMNSElement interface and put it there).

Boris Zbarsky

2005-04-04, 12:35 pm

conor325 wrote:
> And would it then make sense to go "the whole way" and support
> scrollIntoView for such mixed namespace documents too? Given that
> Mozilla supports CSS styling and XPath resolution for arbitrary XML
> already, add this and there is little or no reason to recompose XML
> into HTML for viewing.

Except if you want your documents to be accessible. Or have useful semantics in
general....

Sending arbitrary XML on the wire is generally NOT a good idea.

> With this triple, a pointer to any place in an
> XML document is easy to render in a browser window.

Define "place in an XML document", please?

-Boris

conor325

2005-04-04, 12:35 pm

An xpointer like
"http://www.the325project.org/factlog/EusebiusLifeOfConstantine.xml#xpointer(/xhtml2:html[1]/xhtml2:body[1]/xhtml2:section[4]/xhtml2:section[59]/range-to(/xhtml2:html[1]/xhtml2:body[1]/xhtml2:section[4]/xhtml2:section[62]))"

where the XML file is xhtml2 (section, h etc). It's easy to split the
xpointer now and use xpath resolution to resolve a selection of text.
The missing piece is being able to scrollIntoView!

I don't think styled XML is ever arbitrary - after all the style sheet
defines what to render as a block or inline etc. What I'm trying to say
is that thanks to XML/CSS/XPath support, Firefox can render any
document and if the XML DOM supported scrollIntoView, it could allow
full navigation using intra-doc links, menus etc.

I do this right now but I cheat: I redefine xhtml2 with xhtml's
namespace. The browser then uses the HTML DOM and scrollIntoView works.
"section" etc are still rendered - the DOM is flexible. However, this a
hack. One change - supporting positioning in XML documents - and the
plain XML DOM and renderer can be used.

Boris Zbarsky wrote:
> conor325 wrote:
>
> Except if you want your documents to be accessible. Or have useful
semantics in
> general....
>
> Sending arbitrary XML on the wire is generally NOT a good idea.
>
>
> Define "place in an XML document", please?
>
> -Boris

Boris Zbarsky

2005-04-04, 12:35 pm

conor325 wrote:
> where the XML file is xhtml2 (section, h etc). It's easy to split the
> xpointer now and use xpath resolution to resolve a selection of text.
> The missing piece is being able to scrollIntoView!

No, the missing piece is "what does it mean to scroll into view?" For HTML, the
answer is simple -- "we're implementing an IE extension, so do about what IE
does." For XML, we can decide what to do, so the question becomes what that
should be. What does it mean to scroll a content node into view, really? What
does it mean to scroll an HTML <area> element into view, say, if it's referenced
from 10 different images on the page? What about an SVG paint server of some
sort that's being reused in several different documents, in multiple places in each?

> I don't think styled XML is ever arbitrary - after all the style sheet
> defines what to render as a block or inline etc.

Which is absolutely useless, in general, to someone reading your web page with a
braille reader.... On the other hand, knowing where the paragraph breaks are
and which of your blocks are section headings could be somewhat useful there.

> it could allow full navigation using intra-doc links, menus etc.

You can already do full navigation using intra-doc links. I suggest you look up
XLink (and note that the href of one can be an XPointer expression). No need
for script, no need for scrollIntoView, just nice reasonably semantic (in that
it's clearly a link) markup.

-Boris