Hi Cameron,
Cameron McCormack wrote:
I have a working implementation of getElementById built around a Document Hash Table. It handles all the nasty cases pretty well.
Nice! Have you handled the case where (in DOM 3) an attribute is set to be an id attribute?
It does not currently, although it shouldn't be hard to handle this. It ties into the DOM Attribute changed stuff and defers to the ownerDocument the decision if an attribute is an 'id'. So I would suspect that you might need a little extra code to trigger an id check when some set's the idness.
BTW I also moved getElementById up into AbstractDocument like you did (although I didn't implement the idness check there).
I can try to modify your implementation for the svg12 branch once you check it in, if not.
Ok, I think we need to be a little careful in merging changes between the two branches, in order to avoid making future merges more complex. In general I think we need to merge whole sets of changes (like everything since the svg12 branch was created). There are only a few more issues I wanted to try and address before the release at which point I would expect development to move over to the svg12 branch.
My current inclination would be to have getElementById "search" the entire 'fragment' it is associated with (document or disconnected subtree). This still diverges from Adobe where they will search the main tree even when called on a disconnected subtree, but this is probably more in keeping with what will be needed for Shadow tree's.
That seems sensible to me.
Ok, this is a smallish change. Expect something later tonight.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
