EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Additional Information Needed
Change Description: no spec change
Rationale: At any given point in time, tree order is well-defined.  So it's just tree order at whatever time the UA makes the decision on displaying an icon.  What specific case do you think needs to be clarified in practice?  What to do if the author changes the icons around after the page has loaded?  Is this a real interop problem?  If so, what do you think would be a good solution and why?

That is sufficient clarification, but means a full tree search whenever the UA requests an icon. 

At least one current major browser implementation (WebKit) collects the rel-icon links during initial tree build right now. 

Not saying either approach is right or wrong, simply asking for clarification since I am currently working on supporting rel-icon in Chromium/WebKit

I'm inclined to say the spec should just make the icon selection entirely undefined unless we have clear reason to believe we need interop here.  Browsers won't be picking the same icons no matter what, since they might be displaying them at different sizes or such, so why do we need to try for any interop at all?  It's only a display issue, not author-visible.  Just let them pick icons according to whatever algorithm they like if they're given multiple ones.  If authors do something silly like give two entirely different icons at the same size, it's not going to hurt anything much if different browsers pick different ones, it will just be slightly confusing.

This is closely related to bug 13107.  If the decision were to make which icon to pick entirely UA-defined, that would resolve both of these bugs.

mass-moved component to LC1

I've tried to clarify this by saying that it's the tree order at the time the UA collects the list of icons.

Note though that if you're going to update the icon in realtime, which some sites depend on, you're going to have to recollect the icons each time the author changes the rel=icon links anyway. So it's not like you can really get away from it.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: clarification is always good...

Checked in as WHATWG revision r6379.
Check-in comment: Try to clarify that UAs don't have to continually be rescanning for icons and sorting each time.
http://html5.org/tools/web-apps-tracker?from=6378&to=6379

Thank you for the clarification!