- From: <bugzilla@wiggum.w3.org>
- Date: Sat, 28 Feb 2009 02:26:58 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6610 Erik Wilde <dret@berkeley.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dret@berkeley.edu --- Comment #3 from Erik Wilde <dret@berkeley.edu> 2009-02-28 02:26:57 --- http://dret.typepad.com/dretblog/2008/05/xhtml-fragment.html has some discussion about the general question of fragment identifiers for HTML5. it had been discussed on the HTML5 mailing list and was shot down because it is a classical "chicken and egg" problem, and therefore it is hard to justify to do this other than by saying "this will improve the web as a hypermedia and information system, is not extremely hard to do, can be done with perfect backwards compatibility, and therefore we do it." my personal recollection of the discussion is that the whole argument of "improving HTML as a language for hypermedia and information representation" is not in the focus of the HTML5 effort. it is mostly about improving HTML as a language for building interfaces. personally, i think this is unfortunate and misses some long hanging fruit, but the feedback on the mailing list was not too great, and apparently most people don't really care that much about this particular problem. more specifically, the "##" approach looks problematic to me. this would require an update of the generic URI syntax, a fairly central document on the web. the approach i have proposed would be to improve fragment identifications in HTML5, and these could be pointers to elements, or could have "search semantics", deciding on the possible fragment identification mechanisms would be the second step after deciding that HTML5 should do something in that area. -- 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 Saturday, 28 February 2009 02:27:10 UTC