XFrames - Resurrected Zombies? (was: Comments on HLink)

*Steven Pemberton* <Steven.Pemberton@cwi.nl>:
>
> Actually not. Now with XFrames being a separate spec, and the
> strict/loose/frameset trichotomy disappearing, target will be in XHTML 2.

What for? I thought the XFrames URI syntax doesn't need an additional target
attribute:

If you've got a quite simple frameset, navigation (fixed included via source
attribute), subnavigation and content, it'll look like this:

(1) http://example.org/#frames(subnav=foo-2,content=2/bar-4)

The "next topic" link in 2/bar-4 would look like this:

(2) <a href="bar-5">next topic</a> or
(3) <a href="bar-5" target="content">next topic</a> or
(4) <a href="/#frames(content=2/bar-5)">next topic</a>

You could extend (4) of course. There'll be many ways to do it, that's
always a bad thing IMHO.

What'll my address bar look like if I cicked (4)?

(5) http://example.org/#frames(content=2/bar-5) or
(6) http://example.org/#frames(subnav=foo-2,content=2/bar-5) or
(7) http://example.org/#frames(nav=nav,subnav=foo-2,content=2/bar-5)

When I'm preceding to the next chapter (#3), the sub-navigation shall be
changed and the first topic shall be shown. The target attribute is of no
use in this case, only

(8) <a href="/#frames(subnav=foo-3,content=2/bar-1)">next chapter</a>

does the trick. So if you want to stick with that crazy XFrames URI scheme,
you can easily forget about the target attribute.

> XHTML 1.1 is only an update of XHTML 1.0 strict. XHTML 1.0 transitional
and
> frameset didn't get deleted, just not updated, because there was nothing
to
> update.

That's the first time I hear it that way. I was glad with what I
thought--that transitional and frameset stuff was gone and forgotten with
XHTML 1.1 being the most current HTML version.

> Actually target is a part of Frames *and* Windowing. See XFrames for
> representing multidimensional states in URLs.
>
> http://www.w3.org/TR/xframes/

I've read it and I don't like it. Though, it's slightly better than HTML
frames.

The suggested URI format is as illegible as current PHP workarounds, the
only example given:

  http://example.org/home.frm#frames(id1=uri1,id2=uri2,...)

remains readable. But start replacing id* and uri* by real values and then
imagine a nested frameset ... Isn't the use of the sharp sign, traditionally
used to precede a fragment identifier (IDs), a misuse? When do which
characters (comma!) in uri* have to be encoded?

http://www.example.org/~user/#frames(navigation=en/nav.xhtml,
head=images/logo_big.png,
banner=http://ads.singleclick.net/ads/so,me,weir,d123.str/ing4567?as,
content=/en/category/sub/topic42.xfm#frames(footnotes=topic42-fn.xhtml,
text=topic42.php#heading17?highlight=keyword))

I won't write something like that (at least navigation (if standard
language), head and maybe banner would only be in source attributes), but
there are people who want to and will (automatically generated of course). I
really don't want to see that in my address bar, my bookmarks or my search
engine results.

I don't see the point where this whole thing is better for search engines.
If they wanted, they could have followed the values of the src attributes of
the frame elements already as if they were hrefs of as. Some may do so,
dunno.

Btw.: What's the supposed file extension for framesets xml, xfm or frm? All
of these are used in the draft. And what'll be the MIME type?

Christoph Päper

Received on Friday, 27 September 2002 11:49:22 UTC