Re: [whatwg] Early feedback on header association algorithm
On Dec 5, 2008, at 17:09, Aaron Leventhal wrote: How about node.getElementByIdInSubtree? It's not sufficient to get an element in a subtree. What's needed is getting a cell in the same table--filtering out nested tables. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] Use cases for Node.getElementById (was: Re: Early feedback on header association algorithm)
On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino <[EMAIL PROTECTED]> wrote: That's about the same then moving the getElementById method from the Document interface to the Node interface (Document inherits from Node, so the actual traversed subtree would change basing on the node where the method is invocked, that is 'anElement = document.getElementById("anEl")' would work as always, while anElement.getElementById("anEl") would look for a descendant of 'anElement' with the same id), because, essentially, IDs are a common feature of all document types, despite the actual name of the attribute representing an ID, so an eventual .getElementByIdInSubtree() method should be defined on a somewhat DOM Core interface, and so would be out of scope for HTML 5 (as I've been told .getElementById is - there is a 'Web DOM Core' specification under construction). (I'm currently the editor of that proposal, currently located at http://simon.html5.org/specs/web-dom-core ) But the term 'Subtree' arises a problem with HTML 5: actually, the id attribute is defined as the element unique ID in the *subtree* whithin which the element is found. That is, the term subtree refers to a whole document tree, but also to a disconnected subtree handled by a script (and I haven't yet understood if such definition refers to a document fragment containing nodes detached by any document, or a whole document without a browsing context). AIUI, it could also be a disconnected element. Perhaps the possible confusion arising if moving .getElementById() to the Node interface might be avoided by leaving it on the document interface, and overloading it with, for instance, Element getElementById(in DOMString elementId, in Node rootElement); You mean that it would only be possible to look for elements that are in the document (effectively adding it purely for the case when there are duplicate IDs in a document -- which is invalid)? so a call to document.getElementById would behave as always (or better, as it will be redefined in Web DOM Core, that should be 'pick the first element with a matching id'), and would coincide with a call to document.getElementById("something", document); while a call to document.getElementById("something", anElement) would search a matching ID among the descendants of 'anElement', whether anElement be a node of the current document, or a node removed by any document or created by a script, or a node in another document and both the current document and the current script context are enabled to access it (but a 'script context' is an HTML 5 related concept, so it might be generalized as a "DOM access context"). Hmm. If you allow it to work on disconnected nodes, why involve the 'document' at all instead of using Node.getElementById? I think that's adding to the confusion. :-) Anyway, apart from implementing the HTML5 table heading algorithm in JavaScript, what are the use cases for this? Given that there's Element|Document|DocumentFragment.querySelector('#id') which will return the first element with that ID in the given subtree, and that Node.getElementById seems to mostly encourage using duplicate IDs, I'm reluctant to add it to Web DOM Core. UAs can still have such a method internally if they need it. -- Simon Pieters Opera Software
Re: [whatwg] Early feedback on header association algorithm
On Dec 5, 2008, at 7:09 AM, Aaron Leventhal wrote: How about node.getElementByIdInSubtree? In other cases where a getElement[s]By method is available on both Document and other nodes, it has the same name in both cases (getElementsByTagName, getElementsByClassName). Regards, Maciej On 12/2/2008 4:07 PM, timeless wrote: On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal<[EMAIL PROTECTED]> wrote: Maybe there is a deeper problem if copy& paste doesn't work right because of IDs? Or maybe there should be a node.getDescendantById() method? maybe, but not with that name. Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22 seconds) Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41 seconds) the wikipedia links are confusing enough http://en.wikipedia.org/wiki/Descendant links to: http://en.wiktionary.org/wiki/descendent which has an also link to http://en.wiktionary.org/wiki/descendant which has a 'US' audio file So the web says that '-dant' is favored 2:1 over '-dent', which is a fairly bad margin considering the spelling errors we've seen in html/http. I'd sooner see Node.getElementById and risk the confusion of it returning fewer nodes than Document.getElementById.
Re: [whatwg] Early feedback on header association algorithm
Aaron Leventhal ha scritto: How about node.getElementByIdInSubtree? On 12/2/2008 4:07 PM, timeless wrote: On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal<[EMAIL PROTECTED]> wrote: Maybe there is a deeper problem if copy& paste doesn't work right because of IDs? Or maybe there should be a node.getDescendantById() method? maybe, but not with that name. Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22 seconds) Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41 seconds) the wikipedia links are confusing enough http://en.wikipedia.org/wiki/Descendant links to: http://en.wiktionary.org/wiki/descendent which has an also link to http://en.wiktionary.org/wiki/descendant which has a 'US' audio file So the web says that '-dant' is favored 2:1 over '-dent', which is a fairly bad margin considering the spelling errors we've seen in html/http. I'd sooner see Node.getElementById and risk the confusion of it returning fewer nodes than Document.getElementById. That's about the same then moving the getElementById method from the Document interface to the Node interface (Document inherits from Node, so the actual traversed subtree would change basing on the node where the method is invocked, that is 'anElement = document.getElementById("anEl")' would work as always, while anElement.getElementById("anEl") would look for a descendant of 'anElement' with the same id), because, essentially, IDs are a common feature of all document types, despite the actual name of the attribute representing an ID, so an eventual .getElementByIdInSubtree() method should be defined on a somewhat DOM Core interface, and so would be out of scope for HTML 5 (as I've been told .getElementById is - there is a 'Web DOM Core' specification under construction). But the term 'Subtree' arises a problem with HTML 5: actually, the id attribute is defined as the element unique ID in the *subtree* whithin which the element is found. That is, the term subtree refers to a whole document tree, but also to a disconnected subtree handled by a script (and I haven't yet understood if such definition refers to a document fragment containing nodes detached by any document, or a whole document without a browsing context). Perhaps the possible confusion arising if moving .getElementById() to the Node interface might be avoided by leaving it on the document interface, and overloading it with, for instance, Element getElementById(in DOMString elementId, in Node rootElement); so a call to document.getElementById would behave as always (or better, as it will be redefined in Web DOM Core, that should be 'pick the first element with a matching id'), and would coincide with a call to document.getElementById("something", document); while a call to document.getElementById("something", anElement) would search a matching ID among the descendants of 'anElement', whether anElement be a node of the current document, or a node removed by any document or created by a script, or a node in another document and both the current document and the current script context are enabled to access it (but a 'script context' is an HTML 5 related concept, so it might be generalized as a "DOM access context"). Regards, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Personalizza il tuo cellulare con tantissimi temi! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8275&d=5-12
Re: [whatwg] Early feedback on header association algorithm
How about node.getElementByIdInSubtree? On 12/2/2008 4:07 PM, timeless wrote: On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal<[EMAIL PROTECTED]> wrote: Maybe there is a deeper problem if copy& paste doesn't work right because of IDs? Or maybe there should be a node.getDescendantById() method? maybe, but not with that name. Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22 seconds) Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41 seconds) the wikipedia links are confusing enough http://en.wikipedia.org/wiki/Descendant links to: http://en.wiktionary.org/wiki/descendent which has an also link to http://en.wiktionary.org/wiki/descendant which has a 'US' audio file So the web says that '-dant' is favored 2:1 over '-dent', which is a fairly bad margin considering the spelling errors we've seen in html/http. I'd sooner see Node.getElementById and risk the confusion of it returning fewer nodes than Document.getElementById.