# [00:20] <Hixie> though to be honest i don't see why it sucks so much, it's basically syntactically equivalent and actually has more features than raw element names (you get to pick your own disambiguation scheme, you can pick multiple names, there is better fallback, etc)
# [00:22] <Lachy> Hixie, for the marked issues in the spec, we used to have a JavaScript that inserted "Big Issue: " at the beginning of each one. You could just enable that again
# [00:26] <Philip`> Isn't it easier to write "Big Issue" in the source, rather than having JS that slowly traverses and dynamically updates the whole document at runtime on each client?
# [00:27] <Lachy> Philip`, it could probably be done by the spec gen or something
# [00:33] <Hixie> what's the officially right way to do this?
# [00:33] <Lachy> for these in the stylesheet: p.note:before { content: 'Note: '; } p.warning:before { content: '\26A0 Warning! '; }, that probably could be inserted directly into the markup instead of using stylesheets too
# [00:33] <Hixie> surely the accessibility experts have come up with a solution
# [00:34] <Lachy> Hixie, unfortunately, the correct way to do it would have been display: none;, but screen readers decided to ignore such content
# [00:34] <Hixie> i'll wait for gsnedders to come back and have him add stuff for those classes
# [00:34] <Hixie> Lachy: yeah, i know, i was being sarcastic. :-)
# [00:34] <Hixie> Lachy: the right solution is for screen readers to be replaced by actual speech browsers
# [00:35] <Lachy> Hixie, I agree. But others who work in the accessibility field disagree, cause apparently users use the same screen reader for all their applications, not just web browsing
# [00:36] <Philip`> It would be great if the market was large enough to support development of a real browser comparable to IE or Firefox but designed for a speech interface, but it doesn't seem to be
# [00:36] <Philip`> Oh, actually that wouldn't be great - it would be best if the market disappeared entirely
# [00:37] <Lachy> if there was such a browser that ordinary screen readers could hook into, that might work too, instead of trying to hack an accessibility API onto a browser predominately designed for visual users
# [00:37] <roc> since 90% of the code is the same for a visual browser and a speech browser, it would make sense to share the code
# [00:37] <Lachy> you mean if we exterminated all potential users of screen readers? Sure, that would work. It's a bit cruel though!
# [00:37] <jcranmer> if there was a browser that wacked web developers senseless until they actually designed for non-visual users, that would help
# [00:38] <roc> and then you have to ask yourself if it makes sense to have one build for visual and one for speech
# [00:38] * jcranmer would have to ask MarcoZ what the internet is like with a screen reader
# [00:38] <Philip`> Lachy: I was thinking of a more ideal world where people don't have such disabilities, not one where we kill everyone who doesn't conform
# [00:40] <Lachy> roc, separate browsers could share the same underlying code, but with UI built from the groud up to support different methods of usage
# [00:41] <jcranmer> the Gecko screen reader browser!
# [00:41] <Lachy> in my limited use of screen readers, I found that one of my biggest hassels was that the screen reader overrides many of the normal application keyboard shortcuts
# [00:42] <roc> given that things like http://vimperator.mozdev.org/ exist, you probably build what's needed as a Firefox extension
# [00:42] <Lachy> if the application itself was designed and built with a screen reader UI in mind, then such conflicts could be avoided
# [00:42] <jcranmer> an XULRunner application might be better?
# [02:51] <aboodman> so this means that if you say: createWorker("foo.js"), but don't hold a reference to the returned port, foo.js may get paused at any random point
# [03:33] <jcranmer> no need to do my workaround: edit host files to point to localhost and then do apache rewriting to change the JS file to use something else
# [03:45] <takkaria> I believe the thing that makes a boolean attribute false is if it is not set
# [03:47] <jcranmer> I just want to have confirmation of this before I mark a bug as INVA
# [03:48] <aboodman> Hixie: It seems like right now workers shut down whenever there is no non-gc'd port that refers to them. Even if they have script in progress or things like XHR and timers pending. Is this right?
# [03:49] <Hixie> aboodman: they set closing to true and run through the closing steps first, so it's gracefull-ish, but yes, fundamentally they're just killed when their owners go away
# [03:50] <aboodman> right but it is non-deterministic
# [03:50] <aboodman> if the UA doesn't GC then the worker might not shut down
# [03:50] <Hixie> yeah, i wasn't sure what to do abotu that
# [03:51] <Hixie> i mean, it's non-deterministic anyway, since it's on another thread
# [03:51] <aboodman> I think that workers should stay alive as long as:
# [03:51] <aboodman> they have script running, they have messages queued for them, they have http requests outstanding, or they have timers ounstanding
# [03:52] <aboodman> that would eliminate a lot of hard to understand bugs, when workers sometimes go away and sometimes don't with the same code
# [03:52] <Hixie> well it has to be more than that
# [03:53] <Hixie> otherwise any random page can just start a worker with a timer and it'll never go away
# [03:53] <aboodman> navigation would of course always either nuke or suspend workers
# [03:53] <aboodman> whatever is appropriate for the UA
# [03:54] <Hixie> how is that not non-deterministic?
# [03:54] <Hixie> when you navigate, the worker now has an indeterminate amount of processing time left
# [03:54] <aboodman> if i'm a developer and i write some code that uses workers, but i make a mistake and don't hold the port that comes back
# [03:54] <aboodman> the code inside that worker will stop running at some random point
# [03:54] <aboodman> even without navigating the page
# [03:54] <othermaciej_> workers should stay alive at least so long as someone can message them, even if no messages are queued
# [03:54] * othermaciej_ is now known as othermaciej
# [03:55] <othermaciej> otherwise, any global data set inside the worker could be lost on a race condition of message delivery
# [03:55] <aboodman> othermaciej_: that is in the spec now i think
# [03:55] <othermaciej> yeah, I'm just disagreeing with your "as long as" above, at least as an exhaustive list
# [03:55] <Hixie> aboodman: it doesn't stop running at a random point
# [03:55] <aboodman> right, sorry, I forgot about "someone can message them"
# [03:55] <othermaciej> and I am not sure "someone can message them" can be determined short of GC
# [03:56] <othermaciej> unless there is an explicit way to close a message port I suppose
# [03:56] <Hixie> there is, but i doubt many people will use it, and i certainly don't think we should rely on them doing so
# [03:57] <aboodman> does "run to completion" means that the current event that is being processed finishes, or does it mean that all queued events finish being processed
# [03:57] <othermaciej> yeah, you can't realy on it
# [03:58] <Hixie> aboodman: all queued events get processed (but no new events can be queued once closing is true)
# [03:58] <aboodman> othermaciej: I agree that you can't determine "someone can message them" short of a GC, but I"m just saying that that alone should not determine the worker's lifetime.
# [03:59] <aboodman> Hixie: ok, but httprequests still may or may not happen, right?
# [03:59] <othermaciej> aboodman: I think a message with queued messages or pending timers or pending I/O should continue even if no one can (currently) message it
# [03:59] <othermaciej> aboodman: I don't see how you would do it without either counting on GC, or explicit close
# [03:59] <Hixie> if an xml http request is outstanding, or if there is a repeating interval or an outstanding timer waiting, those are discarded, yes
# [03:59] <Hixie> because otherwise you could use that to stay alive forever
# [04:00] <othermaciej> I am assuming here that the message port for the thread is a GC object and anyone who can reach that object can send a message
# [04:00] <othermaciej> Hixie: I know that is true in the current spec, what I mean is I am assuming it even for hypothetical designs that tried to make shutdown time not depend on GC
# [04:01] <aboodman> othermaciej: I agree with you, but I don't think the spec reflects this
# [04:02] <othermaciej> "fire and forget" threads should be allowed IMO, if they are doing I/O or something
# [04:03] <aboodman> Hixie: are you worried specifically about named workers staying alive forever? Because I don't see the problem with anonymous ones doing that. They will go away at page unload.
# [04:03] <Hixie> right now the mechanism for them going away at page unload is the same mechanism as them going away any other time
# [04:03] <Hixie> i suppose we could have a new mechanism
# [04:06] <aboodman> I see the problem. I was thinking of anonymous workers as more firmly attached to a page.
# [04:06] <othermaciej> for the scope of a particular page I think it should be possible to make a thread that will periodically message you but that you don't care to message ever
# [04:09] <othermaciej> what about a completely fire-and-forget thread, where you ask it to do some I/O but no further messaging is expected either way?
# [04:09] <aboodman> but you couldn't, for example, set up a worker that would synchronize a database with the network but never message the creator.
# [04:09] <aboodman> it would seem to work for a little while, but it would go away after awhile.
# [04:10] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
# [04:10] <Hixie> othermaciej: right now that thread will die before it gets its onreadystatechange, assuming that it uses async IO
# [04:13] <Hixie> what we could do is add an implicit link from any worker to whoever created it
# [04:14] <Hixie> so that it won't ever get killed if whoever created it is still there, so long as it has any outstanding timers, intervals, database callbacks, or xmlhttp request callbacks pending
# [04:17] <aboodman> so the creator doesn't reference it in the same way that a port does... it is only used in the case where there are no live ports
# [04:18] <aboodman> if there are no live ports, but there is outstanding IO or timers, and the creator is still there, then it keeps running
# [04:23] <aboodman> how is it true of image and xhr?
# [04:23] <Hixie> aboodman: feel free to send mail if you come up with some other idea (or even if you don't); i agree that we should do something about this either way
# [04:23] <othermaciej> you can hand one to a different page
# [04:52] <Hixie> Lachy: ok, there's a checkbox in the status section now which, if checked, will let you know within 30 seconds of me committing some new revision
# [07:27] <Hixie> aboodman2, othermaciej, it would be useful to have your input on the issues sicking has raised recently, like pushState() and the workers stuff
# [07:28] <aboodman2> you mean the message he just sent, or was there something earlier?
# [07:28] <aboodman2> also, I'm trying to reply, but whatwg.org is not responding :-/.
# [07:28] <Hixie> that one, and the thread on pushState() recently (which i just replied to -- i'll give you a link in a sec)
# [07:28] <Hixie> uh yes the server seems non-responsive wtf
# [07:29] <Hixie> the machine is working fine except apache is on strike
# [07:29] <aboodman2> I didn't understand his comment about pulling in all of navigator and window. I was going to check the proposal again, because I don't remember that being true.
# [07:30] <Hixie> i think he was speaking hypothetically
# [07:31] <othermaciej> Hixie: I saw the pushState thread
# [07:31] <othermaciej> Hixie: in general it kind of makes sense to require auxiliary data to be stuffed into the URL somehow, since that preserves bookmarkability and shareability of the URL as well as back/forward
# [07:32] <othermaciej> Hixie: but perhaps there are use cases where back/forward is very useful but recording a particular configuration persistently is not, in which case some form of data would make sense
# [07:32] <othermaciej> that's my off-the-cuff opinion
# [07:32] <Hixie> i'm ok with dropping the data part and only using URL
# [07:33] <Hixie> ok seriously wtf is with my server
# [07:33] * Hixie reboots it, because, well, what else can he do
# [08:12] <mcarter> I don't suppose anyone has any idea what is supposed to happen (if there is a standard) if an HTTP/1.1 XHR response is half over when there is a page navigation. Should it a) shut the connection immediately, or b) wait for the rest of the response (though now irrelevant), and then re-use the connection?
# [10:46] <Hixie> seriously, if he's actually worried that people will invent class names that coincidentally happen to look exactly like URIs in his domain, then he has his priorities wrong
# [10:47] <othermaciej> look, the problem is clear
# [10:48] <othermaciej> we can't let extensions to the Web be limited by a central registry
# [10:50] * Quits: Lachy_ (n=Lachy@85.196.122.246) (Remote closed the connection)
# [11:04] <Hixie> the recent thread on the big-issue markup is surprisingly good at distinguishing people who understand the web and accessibility and those who don't
# [11:12] <gDashiva> hsivonen: About the cc: prefix, are you saying the namespace was changed, but everything just uses cc: and didn't notice, or?
# [11:30] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
# [11:30] <hsivonen> gDashiva: the prefix was retained. the local part of the vocabulary was retained. the URI changed, breaking processors that process namespaces or RDF correctly
# [11:31] <Philip`> Just set up an HTTP redirect at the old URI, and it should all be fine
# [11:36] <Philip`> Sadly revision 2000 was just shuffling some text around and seemingly didn't introduce any new errors, so I can't complain about an R2K bug
# [11:45] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Remote closed the connection)
# [11:46] <Lachy> that distributed extensibility thread is getting really annoying. It seems to be taken for granted that a) clashes are inevitable and b) it causes big problems when they occur, without actually explaining what the problem is when 2 distinct sites use common class names for different purposes, intended for processing by their own individual tools
# [11:46] <Hixie> yes it's especially annoying given that both a and b are flase
# [11:47] <Lachy> if their extensions are intended for use outside their own domain, then such extensions need community involvment. Otherwise, it really makes no difference
# [11:47] <Hixie> what should happen to transparency when someone uses toDateURL() with a non-transparency-supporting image type?
# [11:47] <Hixie> Lachy: feel free to take over from me here, i'm quite ready to move on to more productive things
# [11:48] <Lachy> nah, I've avoided contributing to the whole thread on the list in the hope that it would die out on its own
# [11:48] <gDashiva> Clearly hash functions would never work on the internet
# [11:49] <Lachy> it should either be converted to the <canvas> element's background colour (if any), or some default colour like white
# [11:49] <Philip`> Canvases rarely have a background-color so it seems weird and unexpected to depend on that
# [11:52] <Philip`> Why try to cover the non-existent case where an image format is missing support for the R/G/B channels?
# [11:53] <Philip`> Well, not really non-existent, since some greyscale formats exist, but then you'd want to do something cleverer rather than just dropping all the colour channels
# [11:53] <Lachy> so if someone set the colour to rgba(255, 0, 0, 0), then dropping the alpha channel would make it go red?
# [11:53] <Hixie> if someone set the colour to rgba(255, 0, 0, 0), it would probably be stored as 0,0,0,0
# [11:55] <Philip`> That sounds reasonable, though it might be easier to phrase it in terms of compositing the image onto a solid black background with source-in
# [12:00] <Hixie> + <p>For image types that do not support an alpha channel, the image
# [12:00] <Hixie> + must be composited onto a solid black background using the
# [12:00] <Hixie> + source-over operator, and the resulting image must be the one used
# [12:00] <Hixie> + to create the <code title="">data:</code> URL.</p>
# [12:01] <Philip`> Lachy: If you draw solid shapes onto the canvas, then it won't matter what the background colour is; and if you draw transparent objects, then try to save it to a format that doesn't support transparency, it's never going to work properly and it'll give unexpected results regardless of what we do
# [12:02] <Lachy> ok, but it just seems more intuitive to me to use a white background
# [12:02] <Philip`> so I guess what matters is just what's unexpected in the fewest cases
# [12:03] <Philip`> Lachy: The image editors that I've used seem to use either white or the colour in the background position in your colour palette thing
# [12:31] <krijnh> This kicking thing reminds me of #css on Quakenet, when CounterStrike:Source was just released :P
# [12:31] <gDashiva> They can probably make an exception, but the usual wisdom is that if the channel members can't coordinate a channel clearing, they aren't coordinated enough to need ops
# [12:37] <Lachy> Hixie, why don't you combine revision.dat and revision-message.dat, so it doesn't take 2 requests to get the info that could be obtained with one
# [12:38] <Lachy> just make revision.dat contain a string like:
# [12:50] <Hixie> that would have a terrible accessibility story
# [12:50] <Hixie> the whole point of using class="" is that it has a fallback element that at least somewhat provides some semantics
# [12:50] <zcorpan> everyone would just use divs anyway
# [12:50] <Hixie> e.g. <p class="note"> instead of <ch.hixie.spec.note>
# [12:50] <hsivonen> how's that worse than <span class='org.webkit.canvas'>?
# [12:51] <Hixie> for browser vendors, the extension strategy is to come to the working group, ask for input for a few days, then mint a new element like <canvas>
# [12:54] <Hixie> then yes, <span class="org.purl.dc.3.2.phase-of-moon-at-document-creation"> is better
# [12:54] <Lachy> I don't really understand what kind of extensions they're asking for. If it's just for personal/organisational site-specific use, then there's no problem to solve. If it's for wider use in the community, then letting them mint their own extensions without communication is a bad idea
# [12:54] <Hixie> hsivonen: because then UAs don't have to worry about whether the element is inline or block, they can just look at whether it's a <div> or a <span>
# [12:55] <hsivonen> Lachy: as far as I can tell, the problem is having to ask Hixie or Tantek.
# [12:55] <Hixie> and for cases where there is a more appropriate semantic, there is built-in fallback
# [12:55] <Hixie> they don't have to ask tantek, they can mint their own class names as they wish
# [12:55] <hsivonen> Hixie: isn't span-likeness the default?
# [12:56] <Hixie> hsivonen: it could be, but then the moment you wanted a block-likeness, or an emphasis-likeness, or an aside-likeness (as i really want for class=note) then you'd have to change to a different syntax
# [12:56] <Hixie> Lachy: updated the ui, is it better now?
# [12:56] <hsivonen> Hixie: you'd just use Cascading Semantic Sheets
# [12:57] <Hixie> hsivonen: do you mean literally cascading style sheets, or tongue-in-cheek a hypothetical cascading semantic sheets?
# [12:58] <Hixie> hsivonen: for CSS, that doesn't help in the no-CSS case. for the latter, i don't understand how that would work in practice. i suggested it years ago before i realised how intractable the problem was.
# [12:58] <Hixie> hsivonen: (in principle, we can't rely on CSS.)
# [12:59] <Hixie> hsivonen: (and relying on CSS doesn't help turn the element into <aside> or <em> or whatever in media that i haven't written a sheet for)
# [12:59] <Hixie> hsivonen: (which was in fact the very problem that came up today)
# [12:59] <hsivonen> Hixie: I'm not seriously suggesting separation of semantics and structure
# [13:00] <hsivonen> Hixie: but in practice, people (who don't consider accessibility of extensions) seems to be OK with including CSS for their custom stuff
# [13:01] <Hixie> in practice, people (who don't consider accessibility) seem to be OK with doing everything with <font> and <table> and <img> and don't bother putting alt="" on their <img>s either
# [13:01] <Hixie> but that doesn't mean we should allow any of that
# [13:02] * hsivonen is annoyed at dojotoolkit.org breaking Open Link in New Window
# [13:03] <hsivonen> Hixie: not allowing it is centralized command
# [13:05] <Hixie> well then let's disband the w3c, the whatwg, the ietf, iana, and give up on web standards
# [13:06] <Philip`> That's actually quite a good plan
# [13:06] <Hixie> not if we want any kind of interoperability
# [13:12] <jgraham> Hixie: Is there any actual problem with disallowing classnames that look like URIs but do not correspond to the requirements for minting URIs (e.g. that they are owned by the person who owns the domain name in the case of tag: URIs)
# [13:12] <Hixie> it won't make him happy, is the problem
# [13:12] <Hixie> because despite his love affair with uris, he also thinks they're ugly
# [13:12] <hsivonen> Hixie: you could do with what XForms does with inputtypes
# [13:12] <jgraham> It would solve about half the issues he has raised
# [13:15] <gDashiva> I'm wondering, though. What is there to prevent me from creating an awesome vocabulary using some company I don't relate to for the namespace URL?
# [13:15] <hsivonen> gDashiva: you don't have the Authority!
# [13:16] <jgraham> gDashiva: There are MUST NOT conditions!
# [13:16] <gDashiva> So Hixie could add "@class identifiers MUST NOT conflict with other identifiers made by people who worry about conflicting identifiers"
# [13:18] <krijnh> (why don't you guys talk about this with Julian, in #html-wg? You're all there as well)
# [13:20] <gDashiva> We need to establish consensus first
# [13:22] <Lachy> gDashiva, do you mean we need to get everyone to agree to move the conversation to the other channel, before we can move it?
# [13:24] <gDashiva> Lachy: Yes, otherwise it wouldn't be backwards compatible with all the chatters
# [13:24] <Lachy> alright. If that's what we're going to do, then we'd better organise an official survey announce it, give everyone sufficient time to answer it, and then come back in a couple of weeks with the results :-)
# [13:47] <Lachy> Decentralized Extensibility is to Namespaces what Intelligent Design is to Creationism" - hsivonen, do you mean Decentralised extensibility and namespaces are exactly the same thing?
# [13:47] <gDashiva> No, that ID is a sneaky way to attempt to get acceptance for C
# [13:47] <Lachy> because ID and creationism as the same thing, with a different name
# [13:47] <hsivonen> Lachy: I mean that Decentralized Extensibility is a marketing fig leaf for Namespaces
# [13:52] <Lachy> I haven't finished watching it either.
# [13:52] <gDashiva> anne's post reminds me of final destination
# [13:54] <Hixie> i'll be interested to see how sam responds to my last e-mail
# [14:07] <Lachy> How can Julian claim that clashing namespace prefixes has never been a problem in practice, yet be so adamant about clashing class names being a problem?
# [14:08] <gDashiva> Apparently there are lots of malicious authors who would gladly steal your class name and abuse it, but would never consider doing the same with a namespace because namespaces are holy
# [14:10] <hsivonen> gDashiva: just like the XHTML namespace is holy and the XHTML2 WG has Authority over it despite browser vendors having the Power to pollute it with <canvas>.
# [14:11] <Hixie> it's because nobody uses namespaces
# [14:15] <Lachy> nobody would use URI based class names either. They don't solve any real problems, that aren't solved by a simple organisational prefix, and even the benefits of such a prefix are questionable for private class names.
# [14:16] <gDashiva> Hixie: What you suggested about only complicating the class=math classname, wouldn't that lead to the same copypaste problems namespaces is drowning us in?
# [14:17] <Lachy> so, I guess my problem is that I'm don't really understand the intended use cases they're trying to solve with whatever it is they're asking for, and it's not really that clear to me what they're asking for since URIs are supposedly ugly, yet they want a URI-based extension mechanism
# [14:17] <gDashiva> Since the internal classnames would mean different things if you pasted them into a different container classname
# [14:18] <Lachy> gDashiva, doesn't seem to have been a problem for microformats
# [14:19] <hsivonen> Lachy: how do we really know what's a problem for microformats when parsing them is not documented, so we cannot evaluate parsing against real content
# [14:19] <Hixie> yeah i really don't fully understand what is being requested either
# [14:20] <Hixie> gDashiva: well that's like <circle> in svg not meaning anything useful outside of an <svg> container
# [14:20] <Hixie> gDashiva: which isn't really a big problem
# [14:20] <Lachy> maybe it would be better to wait and see if some sort of distributed extensibility design pattern emerges, and then once such a thing as proven itself, then we can spec it
# [14:21] <gDashiva> Hixie: Yes. But if we entertain the idea of collisions, there could be a SillyVectorGraphics container and the cirle would be sillified when pasted there.
# [14:21] <Lachy> so if a design pattern ever emerges that says to use reverse-dns domains, like class="org.example-foobar", and it becomes popular we could spec it
# [14:21] <Lachy> but, yeah, microformats seems to do well in that space anyway
# [14:22] <Hixie> gDashiva: i don't see that as happening much though
# [14:23] <gDashiva> Hixie: Agreed, but when the premise of disagreement is that collisions will happen, I thought it might be useful to see where that takes us :)
# [14:25] <Hixie> gDashiva: it'll take us to the same place as people copying an <li> from an <ol> to a <ul>, or a <dt> from a <dl> to a <dialog>
# [16:49] <zcorpan> hsivonen: "An image in an e-mail or document intended for a specific person who is known to be able to view images" still says alt may be omitted
# [16:51] <Lachy> I asked why that is still in the spec, but Hixie seemed to miss that question when he responded to my mail
# [16:51] <Lachy> I don't see why emails should be treated differently now that there's the {...} syntax
# [16:52] <Lachy> they could just use alt={} or some auto generated thing like alt="{attached image}"
# [16:57] <hsivonen> my crystal ball tells me that alt='{attached image}' will be in the UI language of the sender--not in the language of the message
# [16:58] <Lachy> in practice, my UI language is the language I write in. So then I guess alt={} would be better, since it allows the recipient to be told in whatever langauge they use
# [19:08] * zcorpan thinks Hixie is making an experiment with alt to see if accessibility experts are actually reading the spec or if they'll go "yep the spec is fine now that alt is always required"
# [21:09] <davidmccabe> Hixie: Hello. I'm considering writing up a proposal for drag-and-drop between browser windows. And I'm told you're the guy to talk to.
# [21:09] <davidmccabe> I didn't find anything with google, but I thought I'd ask whether this has been proposed before to anyone's recollection.
# [21:12] <davidmccabe> To summarize what I'm imagining: You would be able to set certain properties on DOM elements that make them draggable or droppable, and a javascript object would be passed from one window to the other when a drop is completed.
# [21:12] <davidmccabe> The protocol could be modeled after those in Cocoa for instance.
# [21:31] <Hixie> hsivonen: alt="{image from site}" maybe, or alt="{small image}" vs alt="{large image}", or some other categorising information that actually showing the image would convey (like size, transparency, colour) but that you would never actually write next to the image if the image was visible
# [21:33] <davidmccabe> Found it; sorry to bother you.
# [21:33] <Lachy> this is weird, there seems to be a distinct lack of excitement over the upcoming olympic games ceremony in this country. I thought people here would be much more excited, but so far I've only heard from people who aren't that interested in seeing it
# [22:24] * gsnedders hopes he hasn't missed anyone out from the ack section of the spec-gen docs
# [22:25] <gsnedders> "Andrew Sidwell, Anne van Kesteren, Henri Sivonen, Ian Hickson, James Graham, Lachlan Hunt, Magnus Kristiansen, Michael(tm) Smith, and Philip Taylor" + special thanks to Bert
# [23:28] <Hixie> it would be ignored="" but yeah, that might work too
# [23:28] <Hixie> one example of something for which i think this attribute isn't appropriate is hiding one panel of a tabbed panel in a dialog when another panel is active
# [23:29] <Hixie> because the fact that the controls are tabbed isn't intrinsic to the dialog, it's just a presentation
# [23:29] <Lachy> it might be a little unintuitive for e.g. <script ignored="">, since AIUI, the script would still execute.
# [23:30] <webben> Hixie: inactive or ignore would be better than irrelevant or hidden.
# [23:30] <webben> irrelevant is just confusing; hidden is confusing presentational
# [23:35] <webben> hmm on the other hand "Elements in a section hidden by the irrelevant attribute are still active, e.g. scripts and form controls in such sections still render execute and submit respectively"
# [23:57] <Hixie> that's what i thought but the way it was defined only affected radio and checkbox inputs, and the example in the source that used autosubmit with a <Select> had JS that woudl take care of the submission anyway for legacy UAs