| 00:00 | <Hixie> | in the _first_ paragraph? of the new text? |
| 00:00 | <Lachy> | ah, sorry, it loaded from my cache |
| 00:01 | <Hixie> | heh |
| 00:02 | <zcorpan_> | Hixie: yeah, that's better |
| 00:02 | <Hixie> | goodgood |
| 00:05 | <Lachy> | so to have a site wide header, the page structure has to be like <body><h1/><article/></body>? |
| 00:05 | <Hixie> | basically |
| 00:06 | <Lachy> | or possibly using a <header> |
| 00:06 | <Hixie> | right, with as many <nav>s, <aside>s, and kinds of other crap aronud |
| 00:06 | <Hixie> | around |
| 00:06 | <Hixie> | wow that sentence was missing so many words |
| 00:06 | <Hixie> | "right, with as many <nav>s, <aside>s, and all kinds of other crap around as needed" |
| 00:07 | <othermaciej> | if it was possible, it would be best if site-wide header and document header were structurally different in a way that made it difficult to accidentally do one when you meant the other |
| 00:08 | <Lachy> | so if the page had <body><h1/><article/><article/></body>, then the h1 wouldn't be a site wide header? |
| 00:08 | <zcorpan_> | othermaciej: you don't really need to think about it |
| 00:08 | <zcorpan_> | Lachy: right |
| 00:08 | <Lachy> | that seems counter intuitive for authors |
| 00:08 | <zcorpan_> | why? |
| 00:09 | <Hixie> | so anyone want to help me do some examination of pages with numerous <base> elements? |
| 00:09 | <Lachy> | cause why should the h1 stop being the site header, just because there's an additional <article> element? |
| 00:10 | <Lachy> | I just think it's overly restrictive on how authors can structure their pages, and authors just won't be able to follow it correctly |
| 00:10 | <zcorpan_> | Lachy: consider a typical blog |
| 00:11 | <Hixie> | actually my blog is a good example of why the spec doesn't work |
| 00:11 | <Lachy> | yeah, a typical blog has multiple articles |
| 00:11 | <Hixie> | but then there _is_ no "page header" in those cases |
| 00:11 | <Hixie> | it's just a site header followed by a bunch of article headers |
| 00:11 | <Hixie> | so i dunno |
| 00:12 | <Lachy> | oh, ok, now I get it |
| 00:12 | <Hixie> | i'm open to better solutions |
| 00:12 | <Lachy> | hmm. I need to think about it a bit more |
| 00:12 | <Hixie> | maybe i should just say that if there are multiple articles, the page header _is_ the site header |
| 00:12 | <Hixie> | certainly what's in the spec now is just experimental |
| 00:12 | <Hixie> | so feel free to send feedback |
| 00:12 | <Lachy> | will do |
| 00:13 | <Lachy> | I probably need to get some sleep first, the sun is up already (I've been up all night) |
| 00:14 | <Hixie> | heh |
| 00:14 | <Hixie> | nn |
| 00:14 | <zcorpan_> | hm, yeah, a front page (with multiple <article>s) could be considered to only have a site-wide header and no page header |
| 00:16 | <Hixie> | horrah, i found a way in which IE7's <base> handling broke a real page |
| 00:16 | <Hixie> | http://www.samidoon.com/index.php?page=forums |
| 00:16 | <Hixie> | second link up from the bottom of the left sidebar |
| 00:16 | <Hixie> | third link up too |
| 00:17 | <Hixie> | in fact most of the links in that sidebar |
| 00:17 | <othermaciej> | one thing I wonder about is why it's important to distinguish site header from document header - is it solely for purposes of generating the document outline? |
| 00:18 | <Hixie> | othermaciej: it's not really important. it's one of those things that people argue about, though. |
| 00:19 | <zcorpan_> | so basically: if there are no <article> elements, then the <body>'s heading is the page header, and there is no site-wide header. if there is exactly one <article> (ignoring nested), then that <article>'s heading is the page header and the <body>'s heading is the site-wide header. if there are multiple <article>s (ignoring nested), then the <body>'s heading is the site-wide header and there is no page header. |
| 00:19 | <othermaciej> | One possibility is to introduce <header sitewide> and <h1 sitewide> which is legal only on headers for the body section |
| 00:20 | <othermaciej> | that wouldn't put any weird restrictions on document structure, is easy for authors, and doesn't complexity the outline algorithm much |
| 00:20 | <othermaciej> | *complexify |
| 00:21 | <Hixie> | othermaciej: yeah, i considered that |
| 00:21 | <Hixie> | othermaciej: might be a better solution |
| 00:21 | <Hixie> | othermaciej: i was looking for a "natural" solution first (one that can be inferred) |
| 00:21 | zcorpan_ | likes the implied semantics better |
| 00:22 | <othermaciej> | Hixie: indeed, that would be nice, so long as the "natural" solution isn't too complex for authors and implementors to understand |
| 00:23 | <Lachy> | what specific problem is solved by being able to clearly distinguish a site-wide header from a page header? |
| 00:23 | <Hixie> | othermaciej: yeah |
| 00:23 | <othermaciej> | consider in particular that a blog page can go from having one article included to many without a change in document semantics implied |
| 00:24 | <Hixie> | Lachy: none, other than putting an end to one particular brand of long pointless arguments |
| 00:24 | <Hixie> | othermaciej: yeah, i gave that example above |
| 00:24 | <zcorpan_> | Lachy: authors don't know how to mark up site-wide headers |
| 00:24 | <zcorpan_> | because html4 doesn't cover it |
| 00:24 | <Hixie> | horrah, another 404 in IE7 |
| 00:24 | <Hixie> | http://n2ch.lazy8.info/headline/headline.cgi?mode=category&group=test |
| 00:24 | <Hixie> | search for "489. somethingorother (2007.5.14) New" |
| 00:26 | <Hixie> | ok wtf |
| 00:26 | <Hixie> | all these pages are CJK |
| 00:26 | <Hixie> | is there something in the east that encourages crazy use of <base> or what |
| 00:28 | <Lachy> | wow! Some people still don't get it http://ask.slashdot.org/article.pl?sid=07/05/16/2342213 |
| 00:30 | <zcorpan_> | Lachy: indeed |
| 00:31 | zcorpan_ | can start a DTD hosting business and make profit of people's ignorance |
| 00:32 | <Philip`> | You could host all your DTDs in a data: URI |
| 00:33 | <zcorpan_> | oh yeah |
| 00:33 | <zcorpan_> | that way they never stop working |
| 00:34 | <Lachy> | *all your DTDs are belong to us* |
| 00:34 | <Lachy> | :-) |
| 00:34 | <zcorpan_> | http://all.your.dtds.are.belong.to.us/ |
| 00:35 | <Lachy> | thanks, I'll put that in my slashdot comment ;-)( |
| 00:35 | <zcorpan_> | :) |
| 00:36 | <Philip`> | If I had a DTD hosting business, I don't know if I'd be able to resist the temptation of randomly changing a default attribute value on one in a thousand requests just to see what happens |
| 00:37 | <Hixie> | heh |
| 00:48 | <Lachy> | http://ask.slashdot.org/comments.pl?sid=235013&cid=19172367 |
| 01:05 | <zcorpan_> | http://www.456bereastreet.com/archive/200705/use_only_blocklevel_elements_in_blockquotes/ feedback is: make <blockquote> and <form> bimorphic |
| 01:05 | <Lachy> | yes |
| 01:07 | <zcorpan_> | which is something i've thought about before, too |
| 01:07 | <zcorpan_> | at least for <form> |
| 01:14 | <Hixie> | you'd have an implied paragraph for the contents? or? |
| 01:14 | <Lachy> | it certainly makes sense for form. I think I've even requested it before for it |
| 01:14 | <Lachy> | The blockquote would be the paragraph itself |
| 01:14 | <Lachy> | you would only need it to contain block elements when the quote itself was a multi-paragraph quote |
| 01:16 | <Hixie> | i guess it makes sense |
| 01:20 | <Lachy> | hey, I forgot to mention, It's been confirmed that I'll be doing another HTML5 presentaiton at Open Publish in August http://www.openpublish.com.au/ |
| 01:21 | <Hixie> | cool |
| 01:21 | zcorpan_ | will have his presentation in a few days now |
| 01:22 | <Lachy> | zcorpan_, where are you presenting? |
| 01:22 | <zcorpan_> | stockholm |
| 01:23 | <zcorpan_> | is google.com redesigned? |
| 01:23 | <Lachy> | zcorpan_, yes |
| 01:23 | <Hixie> | yeah, see the google blog |
| 01:23 | <Lachy> | google.com.au hasn't been done yet, though |
| 01:24 | <zcorpan_> | not google.se either |
| 01:36 | <om_food> | still very old school design on the inside |
| 01:45 | <othermaciej> | does google have any announcement of their new search thing other than on the google blog? |
| 01:46 | zcorpan_ | doesn't find the redesign announcement |
| 01:46 | <othermaciej> | I can't find a press release or anything |
| 01:46 | <othermaciej> | try searching for "google universal search" |
| 01:46 | <Hixie> | the press was all over campus yesterday |
| 01:46 | <Hixie> | search google news for "universal search" |
| 01:47 | <zcorpan_> | http://chronicle.com/wiredcampus/index.php?id=2078 |
| 01:47 | <Lachy> | http://www.theregister.co.uk/2007/05/17/universal_search/ |
| 01:47 | <othermaciej> | ah, press release here: http://www.google.com/intl/en/press/pressrel/universalsearch_20070516.html |
| 01:48 | <othermaciej> | interesting subtext in some of the stories on this: "will this ruin search engine marketing"? |
| 01:49 | <Hixie> | "search engine marketing"? |
| 01:49 | <othermaciej> | companies that base their business on being high in the google search results for particular terms |
| 01:49 | <othermaciej> | seems like a weird reaction |
| 01:49 | <Hixie> | not sure how this would affect that |
| 01:50 | <othermaciej> | me neither |
| 01:52 | <othermaciej> | I think the idea is that it is harder to get into and stay in the top 10 when more different kinds of content are competing with you |
| 01:52 | <Lachy> | othermaciej, re your latest mail, placeholder="" is absolutely essential. We really need that to be added ASAP |
| 01:53 | <othermaciej> | Lachy: well I can't add it, but I can gently remind the person that I asked to write up how it works in WebKit :-) |
| 01:53 | <Lachy> | yeah |
| 01:54 | <Hixie> | wf2 and all forms related things are on hold until either we get clear direction from the forms task force, or i run out of other things to do |
| 01:54 | Lachy | prods Hixie with a sharp stick to add placeholder="" |
| 01:54 | <Hixie> | right now i honestly couldn't tell you which is more likely to happen first |
| 01:54 | <Hixie> | but i'm not going to spend months doing integration work only to be told by the w3c that we're not doing that |
| 01:54 | <Lachy> | I wonder if it would be more effective to ask Mozilla to implement it first |
| 01:54 | <Hixie> | opera might be more likely to do it first |
| 01:54 | <Lachy> | maybe |
| 01:55 | zcorpan_ | would like placeholder implemented too |
| 01:55 | <zcorpan_> | that is one feature that is worked around oh so often |
| 01:55 | <Lachy> | the accessibility people would be really happy with it, since it would solve all the problems that authors create by hacking it with JS |
| 01:56 | <zcorpan_> | yeah |
| 01:56 | Hixie | agrees |
| 01:56 | <Lachy> | and when I get request to implement such scripts for for <input type="password">, I won't need to explain why that won't work |
| 01:57 | <othermaciej> | I'd like us (Safari/WebKit team) to try to document it for standardization even if it does not go into spec right away |
| 01:57 | <Lachy> | yeah, getting it documented and implemented is better than having it in the spec |
| 02:04 | <Hixie> | ok i'm getting really pissed off at <a href="javascript:window.open(...)"> |
| 02:04 | <Hixie> | LET ME OPEN THE FUCKING LINK WHERE I WANT TO OPEN IT |
| 02:04 | <Lachy> | woah, I've never seen Hixie swear before |
| 02:04 | <Hixie> | oh i swear all the time |
| 02:04 | <Lachy> | not in IRC |
| 02:05 | <Lachy> | or email |
| 02:05 | <Hixie> | possible :_) |
| 02:05 | <Hixie> | not in e-mail, indeed |
| 02:08 | <othermaciej> | my top can't-open-link-where-I-want-to annoyance is gmail |
| 02:08 | <othermaciej> | in particular links in messages look like normal targetted links, but trying to open them in a tab fails |
| 02:08 | <othermaciej> | because it has some logic other than the UA's link handling to handle the events |
| 02:09 | <Hixie> | gmail is pretty screwed up for link handling |
| 02:09 | <Hixie> | mostly because of trying to get around browsers neding Referer headers |
| 02:09 | <Hixie> | sending |
| 02:10 | jcgregorio | doesn't know how you could work all day across every different browser and *not* swear... |
| 02:10 | <othermaciej> | oh, I see, privacy issues |
| 08:07 | <Lachy> | heh, the whatwg blog spammers who are signing up to write their own articles are actually being somewhat informative. if only they'd link to the sites they were talking about |
| 09:29 | <mikeday> | it's quiet. |
| 09:29 | mikeday | waits for someone to say "too quiet". |
| 09:32 | <othermaciej> | too quiet |
| 09:43 | <mikeday> | heh |
| 09:43 | <mikeday> | I don't even know where that's originally from |
| 09:43 | <mikeday> | movie, presumably. |
| 09:44 | <othermaciej> | it's a cliche, hard to tell any more |
| 09:46 | <mikeday> | "too quiet... for what?" |
| 09:47 | <mikeday> | my theory is that everyone is at XTech |
| 09:48 | <mikeday> | and is thus unable to find a decent wireless connection and thus unable to get on irc |
| 12:39 | <mikeday> | hmm. |
| 12:43 | <Lachy> | what are you hmm-ing for? |
| 12:44 | <mikeday> | ah hah! |
| 12:44 | <mikeday> | some people just can't be left hanging :) |
| 12:44 | <mikeday> | predefined classes are gone. I hardly knew 'em. |
| 12:45 | <mikeday> | in fact, I didn't know them; what were they? :/ |
| 12:46 | <Philip`> | They were more like postdefined classes |
| 12:46 | <Philip`> | given that people were using them already, and they were just being defined |
| 12:47 | <mikeday> | ah. The definition was just for semantics, and wouldn't affect user agent behaviour, right? |
| 12:47 | <mikeday> | (except for user agents that give a damn about semantics of course...) |
| 12:48 | <Philip`> | I think it didn't add any requirements for UAs - only for authors |
| 12:49 | <mikeday> | hmm, I can think of a good requirement for authors |
| 12:49 | <Philip`> | (but I've never looked at the description closely to see if I'm missing some aspect) |
| 12:49 | <mikeday> | "Authors: stop writing all these crappy pages. Signed, User Agent Implementors" |
| 12:53 | <mikeday> | hmm, that gets back to the role attribute then I guess |
| 12:53 | <mikeday> | what if people just add their own attributes to a document |
| 12:53 | <mikeday> | they still get parsed and end up in the DOM, right? |
| 12:54 | <Philip`> | They do (as far as I'm aware) |
| 12:54 | <mikeday> | so... since the role attribute won't affect visual user agents |
| 12:54 | <mikeday> | why not just run with it for a while and see what happens |
| 12:54 | <Philip`> | Run with it for what purpose? |
| 12:54 | <mikeday> | it doesn't need to be baked into the spec from day 1, right? |
| 12:54 | mikeday | shrugs |
| 12:55 | <mikeday> | whatever purpose people want to run with it for |
| 12:55 | <mikeday> | some people want it, yes? |
| 12:56 | <Philip`> | The predefined classes were removed because there weren't convincing use cases for that kind of feature, so using role to implement the same feature wouldn't help |
| 12:56 | <mikeday> | hmm. I guess my point is, if some people want to use the role attribute to do X |
| 12:56 | <mikeday> | then they can just go ahead and use the role attribute to do X, |
| 12:56 | <mikeday> | without bothering anyone else |
| 12:56 | <mikeday> | if it turns out that doing X is actually really useful, and the role attribute is a neat way to do it, |
| 12:57 | <Philip`> | They can, though they'll be non-conformant |
| 12:57 | <mikeday> | then someone can come along and make an interoperable specification of what they're doing. |
| 12:57 | <mikeday> | non-conformant like every other page on the entire internet, yes :) |
| 12:57 | <mikeday> | but if it works for them, no harm done |
| 12:58 | <mikeday> | but things shouldn't get baked into specifications when they've never been tried |
| 12:59 | <Philip`> | I suppose you could argue that a role attribute is only useful when both authors and (some) UAs make use of it, and use it in a consistent way, which requires coordination between all those groups, and coordination between groups is what standards are for |
| 13:00 | <mikeday> | hmm. <blink> and <marquee> were added 'cos some developers thought they would be cool |
| 13:00 | <mikeday> | authors then used them, 'cos they had no sense of style and thought that they looked cool |
| 13:00 | <mikeday> | coordination between groups doesn't always require a committee |
| 13:01 | <mikeday> | especially since role seems rather like an accessibility-oriented microformat |
| 13:02 | <mikeday> | on an entirely unrelated note, Prince actually supports a :role() pseudo-class in CSS |
| 13:02 | <mikeday> | no relationship to the role attribute at all though |
| 13:02 | <mikeday> | it's for doing things like this: |
| 13:02 | <mikeday> | h1, h2 { role: heading } |
| 13:02 | <Philip`> | That approach seems to work, as long as it's a sufficiently large group adding the feature before there are any users, and then users pick up on it afterwards |
| 13:02 | <mikeday> | *:role(heading) { font-weight: bold } |
| 13:02 | <Philip`> | e.g. Netscape and Microsoft adding features |
| 13:03 | <Philip`> | and Google adding rel=nofollow |
| 13:03 | <mikeday> | So you could use CSS to assign some semantic information to elements |
| 13:03 | <mikeday> | we've never really used the feature though, it turned out to be pretty pointless for styling |
| 13:03 | <Philip`> | (Uh, Google+Yahoo+MSN) |
| 13:03 | <mikeday> | rel=nofollow is a good example, what if they had added a new attribute instead? would it still have worked? |
| 13:05 | <Philip`> | Search engines can add features that browsers can't really parse - AdSense has "<!-- google_ad_section_start -->" |
| 13:05 | <mikeday> | some people embed RDF in HTML comments as well, eg. for creative commons licenses I believe |
| 13:05 | <Philip`> | so they can do pretty much whatever they want, and it'll still work in the 'technically possible' sense |
| 13:06 | <mikeday> | right, but new attributes still get added to the DOM and can be manipulated with JavaScript |
| 13:06 | <mikeday> | so it's not just technically possible, but seems just as practical as using rel |
| 13:07 | <Philip`> | except doing something that makes the page non-conforming would probably come under significant criticism from people who like their pages to be valid, which would limit the number of users who'd make use of the feature |
| 13:07 | <mikeday> | hmm, is rel="nofollow" conformant? I thought rel was fairly limited in the values it could take. |
| 13:07 | <Philip`> | (Even people who don't bother with validity read blogs or use CMSs from people who do care) |
| 13:08 | <Philip`> | "Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types." |
| 13:08 | <Philip`> | (where "link types" is what rel is a space-separated of) |
| 13:09 | <mikeday> | hmm, no one uses profile for nofollow, do they? :) |
| 13:09 | <mikeday> | I get what you're saying though |
| 13:09 | <mikeday> | the emphasis on validity, and the disconnect between validators, browsers and specifications is rather troublesome |
| 13:09 | <Philip`> | No, but it's only a "should", so it's conformant to not use profile :-) |
| 13:10 | <mikeday> | hmm, now that I think about it, using CSS to assign semantics has some benefits over the role attribute |
| 13:11 | <mikeday> | it saves space, as you can just put your declarations in a style sheet somewhere instead of repeating them. |
| 13:11 | <mikeday> | people won't like mixing stuff with CSS though |
| 13:12 | <mikeday> | maybe rather use <link rel="roles" ... to point to some RDF or something that assigns them |
| 13:12 | <mikeday> | CSS gets no respect, people don't even want to use it to define links :) |
| 13:13 | <Philip`> | I think semantics that are necessary for understanding the page should be entirely in the page's HTML, and work with styles disabled - that's why there's <div irrelevant>...</div> and x<sup>2</sup> |
| 13:15 | <mikeday> | hmm, that's a strong argument in favour of a role attribute then, rather than out-of-band role info |
| 13:15 | <mikeday> | assuming such a thing be necessary at all. |
| 13:17 | <mikeday> | if this is aimed at screen readers say, it seems like there is a need for screen readers to drive the adoption process |
| 13:17 | <mikeday> | if one of them implemented support for the role attribute, then people could try it out |
| 13:17 | <mikeday> | just like Apple has prototyped <video> or whatever |
| 13:17 | <mikeday> | if it turned out to be useful it could go in the spec, otherwise stay proprietary |
| 13:19 | <Philip`> | That sounds reasonable to me |
| 13:21 | <mikeday> | and if you can't convince anyone to implement it, it probably isn't worth adding it to a spec :) |
| 13:21 | <mikeday> | anyhoo, must go |
| 13:21 | mikeday | waves |
| 14:01 | <Dashiva> | Mr. html60 is at it again... |
| 14:08 | <zcorpan_> | yay! DOMContentLoaded |
| 14:14 | <Philip`> | It'd be nice if I could write <li from=1><li from=2><li from=3><li from=5><li from=13><li from=65533><li><li> and get the browser to calculate the rest of the Ackermann function for me |
| 14:17 | <Dashiva> | It would just find a different sequence matching that start, pssh |
| 14:17 | <Philip`> | Actually, that wouldn't be too hard - it can just look up the first matching entry in the On-Line Encyclopedia of Integer Sequences, and then I wouldn't be limited to merely arithmetic and geometric sequences in my list numberings |
| 14:19 | <Philip`> | Oh, plan foiled - http://www.research.att.com/~njas/sequences/A126333 doesn't give many entries :-( |
| 16:46 | <mpt> | nickshanks, that "ship your own library version, use any newer version" approach is how Growl works |
| 16:53 | <nickshanks> | mpt: seems pretty robust |
| 16:56 | <mpt> | The catch is that if an app contains a version that is newer than the system version, the app's version replaces the system version |
| 16:57 | <mpt> | because that's the easiest way to install updates |
| 16:57 | <mpt> | So if an app claims to have a new version that's actually malware, every app that was using Growl suffers |
| 17:01 | <Philip`> | Do they have some key to sign it with, so only official versions are allowed to be installed? |
| 17:01 | <mpt> | dunno |
| 17:01 | <mpt> | The Amiga used to have an arp.library that worked much the same way |
| 23:01 | <Hixie> | if i have an array of elements |
| 23:01 | <Hixie> | which might contain duplicates |
| 23:01 | <Hixie> | and i want to go through and do something once to each element in the array |
| 23:02 | <Hixie> | without actually mutating the elements themselves |
| 23:02 | <Hixie> | how would i do it? |
| 23:03 | <Dashiva> | To each unique element? |
| 23:04 | <Dashiva> | Personally, I would put each value into a temporary object, so I'd know if I had seen it before |
| 23:05 | <Dashiva> | hash/dictionary/etc as fits your paradigm |
| 23:07 | <othermaciej> | yeah what Dashiva said |
| 23:07 | <othermaciej> | build a hashtable set of elements seen as you traverse the array |
| 23:09 | <Hixie> | how? |
| 23:10 | <Hixie> | (this is in JS with DOM elements) |
| 23:14 | <othermaciej> | you're screwed then |
| 23:14 | <othermaciej> | there's no efficient way to do it without modifying the elements in some way |
| 23:14 | <othermaciej> | JS doesn't have a way to hash on anything but string keys |
| 23:15 | <Dashiva> | This is where someone points out IE's uniqueID |
| 23:15 | <Hixie> | so i guess we should introduce IE's "uniqueID" then |
| 23:15 | <Hixie> | yeah |
| 23:15 | <Dashiva> | ... that was somewhat disturbing timing |
| 23:16 | <othermaciej> | what is IE's uniqueID? |
| 23:16 | <Hixie> | this came up cos dean was asking for uniqueID |
| 23:16 | <Hixie> | http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/uniqueid.asp |
| 23:16 | <Dashiva> | It's a unique ID for any given element |
| 23:18 | <othermaciej> | that's kind of useful, yeah |
| 23:18 | <Dashiva> | Since it's not guaranteed to be stable, there should (uhuh) be no need to match IE's algorithm for creating either |
| 23:18 | <othermaciej> | you have to make sure the unique ID doesn't reveal any pointer values |
| 23:19 | <othermaciej> | or it makes security exploits easier |
| 23:19 | <Dashiva> | Could just make it a counter |
| 23:19 | <othermaciej> | that is possible, though sloppy (not sure how feasible it is to cycle through enough elements to overflow a counter) |
| 23:19 | <othermaciej> | what would be better is for JS to have data structures that can be keyed by object identity |
| 23:20 | <othermaciej> | instead of just by string value |
| 23:20 | <Philip`> | Why is it alright to have a uniqueID that magically creates numbers and stores them in the object, but not alright for JS to modify the object itself? |
| 23:21 | <Dashiva> | The uniqueID is idempotent? |
| 23:22 | <othermaciej> | I don't understand their example |
| 23:22 | <Hixie> | what? you don't understand an msdn example? surely not. |
| 23:22 | <Hixie> | there are several security issues with uniqueID, as othermaciej points out |
| 23:23 | <Hixie> | can't be directly from the pointer. can't be a global counter (since you'll reveal what the user's activity in other windows is like) |
| 23:23 | <Dashiva> | Isn't uniqueID specific to each browsing context? |
| 23:24 | <Hixie> | could be, but then what if you adopt a node to another document? |
| 23:24 | <othermaciej> | it has to be a one-way hash of the pointer basically |
| 23:25 | <othermaciej> | or generate them on the fly, store a pointer in the element, and use a global hashtable to avoid duplicates |
| 23:25 | <Hixie> | the latter is expensive |
| 23:25 | <othermaciej> | it's really just making up for a deficiency in the JavaScript language |
| 23:25 | <Hixie> | around 4 bytes per element globally |
| 23:26 | <Philip`> | You could encrypt the pointer with some secret key, and then it'll never have collisions (assuming the output size is the same as the pointer size) |
| 23:26 | <Hixie> | yeah |
| 23:26 | <Hixie> | (@othermaciej) |
| 23:26 | <othermaciej> | but if it is a single secret key then it will be reverse engineered eventually |
| 23:26 | <othermaciej> | I don't think a hash can be both one-to-one and irreversible |
| 23:26 | <Philip`> | The key can be randomly generated each time you start the browser |
| 23:27 | <othermaciej> | that could work |
| 23:27 | <othermaciej> | but anyway if JS had a data structure keyed on object identity that would be a much better solution overall |
| 23:28 | <othermaciej> | this sort of thing comes up all the time, and not always just for DOM elements |
| 23:28 | <othermaciej> | I should propose such a thing for ES4 if they do not have one already |
| 23:28 | <othermaciej> | OK, I keep staring and I still can't figure out what this is about: window.setTimeout(uniqueID+".tick()", delay); |
| 23:28 | <othermaciej> | why would you call the custom method on a string? |
| 23:29 | <othermaciej> | or does the uniqueID get magically bound in some namespace? |
| 23:29 | othermaciej | 's brain hurts |
| 23:29 | Dashiva | thinks so |
| 23:29 | <othermaciej> | I should stop thinking about it |
| 23:29 | <Dashiva> | This is IE, they like global namespace flooding |
| 23:29 | <Hixie> | the first argument to setTimeout is a string to evaluate |
| 23:29 | <Hixie> | in IE, IDs are in the global namespace |
| 23:31 | <othermaciej> | the uniqueIDs? or element ID attributes? |
| 23:31 | <othermaciej> | or both? |
| 23:35 | <Philip`> | When you access uniqueID, it appears to create an object in window with that name (window.ms__id15 etc) pointing to the object you got the uniqueID from |
| 23:35 | <Hixie> | both |
| 23:37 | <Philip`> | Oh, it also has document.getElementById(x) === document.getElementById(x.uniqueID) |
| 23:37 | <Philip`> | Uh |
| 23:37 | <Philip`> | document.getElementById(x.id) === document.getElementById(x.uniqueID) |