[Bug 5744] Improved Fragment Identifiers

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5744





--- Comment #21 from Erik Wilde <dret@berkeley.edu>  2008-06-15 04:13:23 ---
(In reply to comment #20)
> > [...] use a pdf and point to it and then say in plain text "read page 42".
> Sure, but that's the same thing as people saying "look at this page and read
> the section numbered 3.4", which happens a lot even when the page in question
> has IDs and thus wouldn't need it (i.e. when fragment identifiers would be
> enough). (This actually suggests a technical solution might not be useful
> here.)

of course a technical solution *alone* is not useful. browsers have to support
that, so that users can right-click on a fragment and say "create link to
paragraph". the fact that browsers today don't do this is because fragment
identification relies on @id, which are often not there. if there is a reliable
and generally applicable technical foundation, you can build a good user
interface for it. both things must be there to make it work.

> > i am wondering, though, why you are not addressing my argument that fragment
> > identification inherently needs cooperating peers
> There are plenty of examples where problems that need cooperating peers have
> still flourished. At the extreme we have Flash, where a single vendor decided
> there was a problem space (animations, videos) to fill, and filled it, with
> insane penetration numbers. Similarly with MathML, where some authors are using
> it even though most clients don't support it -- there are plugins that provide
> it.

your examples all talk about *authors* wanting to do something, and then they
can do various things (plug-ins, scripting). fragment identifiers require
somebody (not the page author) to create a link with an identifier, and then
this information must be used by the recipient of the link. this is just a
different scenario from the author-centered scenarios you are describing.

> The problem could also be worked around from the other side. For example, if
> this was a need that many users had, I would expect CMS tools like WordPress to
> automatically assign IDs to every paragraph and "br" element. I know of a few
> people who go out of their way to do this (I have done it in the past myself),
> but they are all theoreticians, people who understand the benefits we could
> derive from this, if only people cared enough to use it.

i do know these tools and i like them. but they introduce site-specific ways of
creating links to these fragments (if they do support creation at all). a
browser could implement a mechanism that would work for all web pages, which is
a very different thing.

> One can imagine many ways that people might have worked around the lack of this
> feature. But in practice, they haven't, at least not insofar as I have seen. I
> don't disagree that the idea is a good one, and that (assuming we could resolve
> the brittleness issue) it would have huge potential to those who used it, but
> we can't just go around solving problems we like. We have to focus on the
> problems that people are actually running into. We don't have infinite
> resources, and our resources are likely better spent on more important things,
> like video, like maths, like duplex long-term connections.

i suspect the "we" here is the pluralis majestatis. so far, nobody has said
that they don't want this, and (admittedly few) people said that it would be at
least worth considering. this is a great opportunity to fix something that's
clearly not useful in html4, and it can be done with a moderate amount of
effort. i am not asking you to develop this yourself. but what i am asking for,
however, is that you consider something like that seriously, with the
appropriate scenarios in mind, and with some sort of cost/benefit analysis.
html5 should not be only for authors, it should also be for users.

html5 is a great way to improve the web, and the web should still be viewed as
a hypermedia system, at least that is my motivation for this thread. "why link
when you can search" might be the motto of the past 10 years, and it will
remain dominant, but as web and hopefully hypermedia experts, we should look a
little bit further than that. why search when you can link.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 15 June 2008 04:14:04 UTC