W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > June 2008

[Bug 5744] Improved Fragment Identifiers

From: <bugzilla@wiggum.w3.org>
Date: Fri, 13 Jun 2008 17:42:43 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1K7DIR-00061x-Fw@wiggum.w3.org>

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


Erik Wilde <dret@berkeley.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dret@berkeley.edu




--- Comment #2 from Erik Wilde <dret@berkeley.edu>  2008-06-13 17:42:43 ---
"What problem are we solving here? Is giving a fragment identifier into a
document really something that causes difficulties? Most people seem to deal
fine with just saying "Look at bla on this page" with a URI without a fragment
identifier, no?"

that's correct, but kind of a tautology, because nowadays it's the only option
that people have. whether people are dealing "fine" or not is kind of hard to
say, but it is hard to build better tools (such as a browser providing the
capability to create more specific links) when the spec does not support that
because only @id elements can be used as fragment identifiers.

"It seems like if this was really a problem, people would have been doing
things
to work around it, as they do with many other limitations of the Web platform,
but in this case I really see nobody working to index into pages better. What
evidence of the need is there?"

http://www.codedread.com/fxpointer/ is an attempt to do something about it, but
it may not be the evidence you are looking for. it is hard to imagine forums
full of "HTML should have better fragment identification" posts, so what kind
of evidence are you looking for?

"Even if the problem exists, though, and is worth solving, why is XPointer not
good enough? We can easily redefine XPointer to work for HTML as well as XML,
since HTML5 defines text/html HTML in the same terms as XML-based HTML."

xpointer may be good enough, even though i would argue that its not a good
spec. but i think looking at how to do it would be a second step, the first
step would be to decide that yes, html5 should have better fragment
identification, specifically one that does not depend on @ids.

"Are user agents willing to actually implement this?"

i don't know. the simpler it is (and i think it should be simpler), the easier
it can be and probably will be implemented. and i think the html5 spec could
and should explicitly encourage implementors to support fragment identifiers,
both through a way of constructing them (creating a link while browsing a
page), and through interpreting them (scrolling to the fragment and applying
the CSS :target pseudo-class formatting).


-- 
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 Friday, 13 June 2008 17:43:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 June 2008 17:43:18 GMT