[Bug 5744] Improved Fragment Identifiers

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





--- Comment #23 from Ian 'Hixie' Hickson <ian@hixie.ch>  2008-06-15 09:15:04 ---
> browsers have to support that

Is there any evidence that browsers are interested in providing this?


> your examples all talk about *authors* wanting to do something [...]

Examples of things users might want to do: searching across multiple sites --
someone provided that. Annotating sites -- someone provided that. Chatting with
other visitors while at a site -- someone provided that. Browser vendors are
also a good proxy for user desires, as they do user studies to determine what
they should work on (this is especially true in this newly ultra-competitive
market). Some features are probably worth adding to HTML5, others aren't. We
can determine where to concentrate by looking at what features users are using.

My point here is just that we need to set our priorities based on clear
research, not on our desires.


> > 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.

My point is that if there was really a pent up need for this feature, people
would be using these half-assed measures and asking for better solutions. In
practice, few people are even using the half-assed measures. This is evidence
suggesting that this is not a high-priority feature.

That doesn't mean it's not a great idea, just that it's not what we should be
concentrating on right now.

Having said that, I would encourage you to spec something independently, and
try to get browsers to implement it. I'm happy to provide the hooks on the
HTML5 side (in particular in the text/html MIME type registration) as needed. I
do not believe this is a feature that is HTML5-specific.


> i suspect the "we" here is the pluralis majestatis.

I mean "we" as in "the Web community as a whole", in particular those of us
actually writing the specs, writing the test suites, reviewing the specs and
test suites, writing the implementations, testing the implementations, etc.


> so far, nobody has said that they don't want this

Sure, if it were free then it'd be great.


> 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.

I consider _all_ feedback seriously, with careful study of the costs and
benefits. This is my full-time job. I basically do nothing else than study
proposals all day long.


> html5 should not be only for authors, it should also be for users.

HTML5 should be _primarily_ for users.

It's not clear that many users want this.



Regarding the RFCs: updating the RFCs is a separate open issue. We need to
register and update several MIME types as part of HTML5, but I'm waiting for
the spec to be ready before doing that, as we don't want the MIME types to be
ready before the language.


-- 
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 09:15:39 UTC