- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 25 Aug 2009 16:45:46 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
On Aug 25, 2009, at 4:03 PM, Ian Hickson wrote: > On Tue, 25 Aug 2009, Roy T. Fielding wrote: >> On Aug 24, 2009, at 10:13 PM, Ian Hickson wrote: >>> (For instance, above, you use the word "defined" in a way that is >>> completely at odds with my understanding. A feature is fully >>> "defined", as I understand it, by the combination of authoring and >>> implementation conformance criteria, which we have for <a name>, yet >>> you do not consider it to be "defined".) >> >> I use "defined" as it is found in any English dictionary. The only >> thing >> HTML5 draft defines related to <a name> is browser behavior in >> response >> to a fragment retrieval request, which may be sufficient for a >> BROWSER >> that is limited to performing view operations. > > This is incorrect. > > HTML5 defines how "name" is to be processed as part of the > HTMLCollection > object for any implementation that includes DOM APIs, and the > definition > of the meaning of fragment identifier syntax for text/html > documents, for > any HTML processor. http://dev.w3.org/html5/spec/Overview.html#the-indicated-part-of-the- document If there is an a element in the DOM that has a name attribute whose value is exactly equal to fragid (not decoded fragid), then the first such element in tree order is the indicated part of the document; stop the algorithm here. > No mention of browsers is made in any of these conformance critiera. 1) I don't have a DOM (only browsers do). 2) I am not trying to determine "the indicated part of the document"; I am trying to find errors (possibly due to combining the input of more than one content part) in a generated document. In order to do that I need to know the meaning of the mark-up, not the behavior of a browser when traversing a DOM. 3) the above algorithm is wrong -- most of the elements in HTML that have name attributes are not valid destinations for hypertext links and any browser that actually follows that algorithm would break existing content if the anchor name happens to be something commonly used in non-anchor name attribute (like "keywords", "content-type", "author", "edit", etc.). What you are saying is that I have to rely on all prior definitions of HTML (that were not written in this insane browser-centric style) in order to figure out the meaning of mark-up in "text/html". Fine, so the issue is resolved by listing all HTML specifications as being definitive for "text/html" and I'll just choose the one that explains the language in my terms. > In that case, I completely disagree with your world view of how > specifications should work. That much is obvious. It does not, however, make you the ultimate decider of whether an issue is valid or not, or whether the content of the current draft resolves that issue. Consensus is not found in the eye of the editor. ....Roy
Received on Tuesday, 25 August 2009 23:46:20 UTC