[ Re: the HTML 3 <MARK> element ]
> >What does not feel good about it? I think it's a very
> >good approach.
>
> Paired elements like the above mean that you have to maintain more
> state when you are rendering a document (ie. you have to traverse the
> entire document tree preceeding the current element, whereas with
> container based control, you only need to traverse the ancestors
> leading up to a node).
But there is no requirement for a browser to treat
marked ranges specially at all. If a WWW user agent
*does* implement highlighting of marked ranges that cross
element boundaries, it will need to keep track of extra
state somehow anyway, regardless of how the range is
specified.
Plus, it is possible to implement this sort of thing
efficiently; see the Tk text widget for example.
> One fellow mentioned that we need a way to solve both the
> highlighting, and the annotation problem. I think using parts from
> HyTime Location Module, or at least concepts from it, combined with a
> multipart MIME message might be the best way to go (and it's
> applicable to other media types!!!). One way or another, specifying,
> and implementing, such functionality will cause some pain.
HyTime -- or any mechanism that uses external links into
a document -- will only work if the server and browser
parse the document *identically*. If the WWW were a true
SGML application and browsers used real SGML parsers, this
would only mean that both ends would have to use the
same DTD. That's not the case, though.
There's no telling what existing browsers do with record ends,
for example, but it's very unlikely that any are ISO 8879 compliant.
A HyTime link to the 20th through 35th characters of
the 4th child of the element with id "FOO" can't possibly
work when browsers don't even count the same way.
--Joe English