/irc-logs / freenode / #whatwg / 2009-07-15 / end

Options:

# Session Start: Wed Jul 15 00:00:00 2009
# Session Ident: #whatwg
# [00:00] <sicking> Hixie, i'm talking with Arun fairly often about the draft, i think a new one is on the way
# [00:00] * Joins: weinig (n=weinig@nat/apple/x-73b9cf982e984a93)
# [00:00] <sicking> Hixie, i don't think it'll change substantially though from previous one. Possibly introducing the local-uri thing
# [00:01] <sicking> Hixie, though the lifetime still seems like a big problem to me
# [00:01] * Quits: mat_t (n=mattomas@62-64-155-40.dynamic.dial.as9105.com) ("This computer has gone to sleep")
# [00:02] <sicking> Hixie, and I think we might drop the FileDialog for now. Because ya'll are wossies ;)
# [00:02] * aroben is now known as aroben|meeting
# [00:04] <sicking> Hixie, so in general for drag-n-drop, pages won't know at all even what type of data is in the datatransfer until the drop event?
# [00:05] <sicking> Hixie, seems useful for the page to know if it will be able to handle the datatype before accepting the drop
# [00:05] <sicking> Hixie, this would be orthogonal to the .files issue
# [00:07] * Joins: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
# [00:10] * Joins: gsnedders (n=gsnedder@c83-252-195-113.bredband.comhem.se)
# [00:10] * Joins: jorlow (n=jorlow@nat/google/x-c9682c2f12f03fb9)
# [00:11] * Quits: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com) (Read error: 104 (Connection reset by peer))
# [00:11] * Joins: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
# [00:21] * Quits: cying (n=cying@70.90.171.153) (Success)
# [00:32] <Hixie> sicking: what's the problem with the lifetime? and i hope he'll split File into File and some base interface, too
# [00:32] <Hixie> sicking: the problem with not knowing the types is an open issue with the dnd model iirc
# [00:33] <Dashiva> The @parsing thing doesn't seem like a good fit for markup
# [00:33] <sicking> Hixie, the problem with the life time is that I suspect Document lifetime is slightly too short
# [00:33] <Dashiva> Browser error reporting, symlinks, mod_rewrite with type override...
# [00:33] <Hixie> sicking: for the types, i expect we'll expose .types in all events in the future
# [00:33] <sicking> Hixie, for example sticking the uri into a sessionStorage in a wizard-type page
# [00:33] <sicking> Hixie, sounds good re .types
# [00:33] * Joins: sebmarkbage (n=miranda@h-6-72.A146.priv.bahnhof.se)
# [00:34] <sicking> Hixie, we'd just need to define a type for files
# [00:34] <Hixie> sicking: well we can always increase the lifetime later if we think we need to... but i think it'd be better to define a way to track the actual File or FileData objects rather than passing the URI around
# [00:35] <sicking> Hixie, yeah, that's an alternative
# [00:35] <sicking> Hixie, i'd still like for Storage to be able to hold File/FileData objects
# [00:36] <othermaciej> I think the temporary URI design is probably not workable
# [00:36] <othermaciej> I need to catch up on the discussion though
# [00:36] <Hixie> othermaciej: i don't see another solution for reusing file data unless we basically add a parallel set of features across the entire platform to support File objects everywhere, and that seems painful
# [00:36] <othermaciej> the problem is, you have to make sure that temporary URIs for files are unguessable, and also that they are never reused
# [00:37] <Hixie> why and why?
# [00:37] <othermaciej> they have to be unguessable or you have a security hole
# [00:37] <othermaciej> an attacker in a different window could read the URI
# [00:37] <Hixie> no, they are origin-blocked
# [00:37] <othermaciej> assuming you want the URIs to be passable via postMessage for instance
# [00:38] <Hixie> you'd pass the File object
# [00:38] <Hixie> not the URI
# [00:38] <othermaciej> in that case, they are inferior to the ability to pass a File since you can't transfer the capability
# [00:38] <Hixie> correct
# [00:38] <Hixie> they're not meant for passing around
# [00:38] <Hixie> they're meant for plugging a File object into an <img> or <video> or some such
# [00:38] <othermaciej> so it seems like adding srcFile attributes to the few HTML element interfaces that need them would be simpler
# [00:38] <Hixie> or <iframe>, or CSS, or any number of things
# [00:38] <Hixie> that seems unworkable to me
# [00:39] <Hixie> we'd have to go through the entire platform duplicating everything, defining how one overrides the other, etc
# [00:39] <Hixie> it'd be an epic disaster in terms of getting interop
# [00:39] <othermaciej> (I don't think <iframe> or CSS really need them, but maybe I'm wrong)
# [00:39] <sicking> Hixie, why make them origin blocked rather than unguessable?
# [00:39] <othermaciej> the use case is for a preview
# [00:39] * Joins: arun__ (n=arun@nat/mozilla/x-7165bef6f0b00147)
# [00:40] * arun__ is now known as otherarun
# [00:40] <sicking> I think CSS and <iframe> is useful for things like building a HTML editor
# [00:40] <othermaciej> I think giving <img>, <audio> and <video> a way to take their source from a file instead of a URI would mostly satisfy the use case
# [00:41] <othermaciej> building an HTML editor would admittedly need support everywhere you can embed something
# [00:41] <othermaciej> if you wanted your HTML editor to work without having to upload the resources first
# [00:41] <othermaciej> but I thought the main stated use case was for previews before uploading
# [00:42] <othermaciej> (any text resource you can already preview by reading the file yourself)
# [00:42] <othermaciej> temporary URIs are certainly more general, but more complicated both to use and to implement for the simple preview use case
# [00:42] <Hixie> sicking: because they can leak easily (e.g. referer headers)
# [00:43] <sicking> Hixie, hmm... good point
# [00:43] <Hixie> i don't think that temporary URIs are actually any more complicated on the long term
# [00:43] <Hixie> they would be a much more localised implementation
# [00:43] <Hixie> rather than spreading support all over the place, redefining processing models, etc
# [00:44] <othermaciej> a more localized implementation of something way more complicated, and with tricky security implications
# [00:44] <sicking> if we make the uri origin blocked then I'm not sure there are any security issues I can think of off the top of my head
# [00:45] <Hixie> othermaciej: i'm not convinced it's that complicated. Why would it be that complicated?
# [00:45] <othermaciej> tracking the temp URIs and implementing lifetime and origin blocking is the piece of code that would be both complicated and security-sensitive
# [00:45] <sicking> Hixie, btw, doesn't data: uri suffer the same problem of leaking through referrer then?
# [00:45] <Hixie> sicking: data: URIs aren't particularly secure
# [00:46] * aroben|meeting is now known as aroben
# [00:46] <sicking> origin blocking doesn't seem that hard to implement security, granted it might be different in non-gecko browsers
# [00:46] <sicking> securely
# [00:47] <Hixie> othermaciej: it's just a table of ID,origin,file,document; when a document closes, you remove all the corresponding rows; whena url is dereferenced, it returns its origin and data
# [00:47] <Hixie> othermaciej: unless your URI handling is especially weird, this seems relatively straightforward
# [00:47] <othermaciej> Hixie: if lifetime is document but scope is origin, you have to be careful never to reuse an ID
# [00:48] <othermaciej> that's one example of a potential subtle bug
# [00:48] <otherarun> So the requirement is for both unguessability and origin-restriction.
# [00:48] <otherarun> (the first, unguessability, may be easy -- UUID or something)
# [00:48] <Hixie> othermaciej: not reusing an ID is trivial, just increase a number.
# [00:48] <othermaciej> unguessability doesn't matter if they are origin restricted
# [00:48] <sicking> at least not as important
# [00:49] <sicking> though <img> is cross origin
# [00:49] <Hixie> othermaciej: i don't really understand the not reusing an ID thing, though
# [00:49] <othermaciej> Hixie: it's easier to avoid repeating if the URI doesn't have to be unguessable
# [00:49] * sicking didn't follow the reuse ID thing either
# [00:49] <Hixie> so long as you don't create a new URI that's equal to a still-active URI, why does it matter if the ID is reused?
# [00:49] <othermaciej> if you reuse an ID then it could lead to another page from the same origin that has the wrong URI reference to load the wrong file, instead of getting an error
# [00:50] <Hixie> that seems like a not especially worrisome case
# [00:50] <Hixie> i mean, that page could just randomly come up with a string that happens to be one that happens to be registered to its own origin too
# [00:50] <Hixie> even if the ID wasn't reused
# [00:50] <othermaciej> note that File references wouldn't have this problem at all, since the engine can know the lifetime of a File object but it can't know the object of a URI string
# [00:51] <othermaciej> Hixie: yes, that's another flaw with the magical URI scheme
# [00:51] <othermaciej> it just has much more potential for bugginess to use a magic string instead of a capability-carrying object reference
# [00:51] <Hixie> i think that considering this a flaw is like considering pointers to be flawed because if you come up with a random number that happens to point into your address space, you'll dereference something instead of getting an access violation
# [00:51] <othermaciej> to identify a temporary and origin-restricted resource
# [00:52] <othermaciej> pointers are flawed! that's why we don't have them in ECMAScript
# [00:52] <Hixie> *shrug* i'm not convinced this is a problem
# [00:52] <Hixie> i mean i'm happy to make the URIs be unlikely to be reused and unlikely to clash
# [00:52] <Hixie> e.g. by using UUIDs
# [00:53] <Hixie> (clash with random values, i mean)
# [00:53] <Hixie> but i don't think it's a problem
# [00:53] * Joins: weinig_ (n=weinig@17.244.1.204)
# [00:54] <othermaciej> it's just a sloppy design, in my opinion
# [00:54] <Hixie> but in any case, it's trivial to create a sequence of non-duplicate IDs that are statistically not going to clash with random numbers
# [00:54] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [00:54] <othermaciej> not saying we can't make it work, but it will be much more bug-prone than the alternative
# [00:54] <Hixie> it's far less sloppy than adding a parallel set of APIs everywhere :-)
# [00:54] <Hixie> i strongly disagree with that
# [00:54] <Hixie> having to add two entry points to every processing model is orders of magnitude more likely to be buggy
# [00:54] <Hixie> and in weird ways that are hard to work aorund
# [00:55] <sebmarkbage> Speaking of dnd... The current draft doesn't specify when pageX, clientX, screenX positions are available on the DragEvent. Gecko currently sets these to zero on the source node. It should be available on all IMHO. Is there any known security issues to this?
# [00:55] <othermaciej> I doubt it. Just say srcFile always takes precedence over src, or the most recently set takes precedence, or whatever. Done.
# [00:56] * Joins: tantek (n=tantek@208.80.69.102)
# [00:56] <Hixie> othermaciej: hah
# [00:56] <Hixie> othermaciej: if only it were that easy
# [00:56] <othermaciej> It would be like an hour or two of implementation work to do HTMLImageElement.srcFile and I would be confident it is right
# [00:56] <othermaciej> a temporary URI vending scheme, I would expect to be finding bugs months later
# [00:56] <Hixie> othermaciej: and you'd get the origin checking right for when that <img> is used with createPattern() ?
# [00:57] <sicking> the downside is that we can't make it work as widely as URIs work. For example for CSS backgrounds. But i'm not sure that that is that important
# [00:57] <othermaciej> sicking: yeah, that's really the main downside
# [00:58] <othermaciej> Hixie: an <img> loaded from a File shouldn't have cross-origin taint, since if you have the file reference you can get the bits of the image
# [00:58] <othermaciej> or at least, cross-origin taint for createPattern() would serve no useful purpose
# [00:58] <Hixie> othermaciej: i'm just saying that there are FAR more complications here than first meets the eye
# [00:58] * Joins: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au)
# [00:58] <Hixie> e.g. we'd have to change the conformance rules to make sure <img> without src="" would be valid
# [00:59] <Hixie> the <video> resource selection algorithm would become even more complex
# [00:59] <roc> I'd prefer the URI approach from an implementation point of view. If we do the .file approach we'll have to wrap the file in a URI-like-stream internally anyway
# [00:59] <Hixie> anyone relying on selectors like img[src] would have to now know they couldn't always rely on it
# [01:00] <othermaciej> I'm willing to believe there may be complications, I just can't think of any (at least, none that would make it tricky for implementations)
# [01:00] <Hixie> there are so many small things that would have to be defined if we added a parallel API everywhere
# [01:00] <othermaciej> roc: I think the challenges with the URI approach are not so much about using it internally, but in using that URI string as a handle to the resource
# [01:00] <Hixie> you also couldn't use .innerHTML suddenly, you'd have to create the markup and then poke the file in afterwards
# [01:01] <othermaciej> I guess I'm not really sure it's needed everywhere
# [01:02] <Hixie> i don't think it's needed everywhere, e.g. i can't think of any time i'd want to put it in <blockquote cite="">
# [01:02] <roc> Maintaining a file dictionary doesn't seem that hard, except for lifetime management. How does that work?
# [01:02] <othermaciej> the only use case I've heard mentioned for that is a full-featured HTML editor that either works offline or is unwilling to upload resources before using them in editing
# [01:02] <roc> Hixie: I can!
# [01:02] <Hixie> roc: my proposal is to make the URIs stop resolving once their Document has been closed
# [01:03] * sicking has to take off
# [01:03] <roc> ok
# [01:03] <sicking> so far I don't feel strongly either way
# [01:03] <roc> sounds good to me
# [01:04] * Quits: weinig (n=weinig@nat/apple/x-73b9cf982e984a93) (Read error: 110 (Connection timed out))
# [01:06] <sebmarkbage> othermaciej: It could really be all kinds of offline app scenarios such as spreadsheets or whatever.
# [01:07] <othermaciej> sebmarkbage: I don't think spreadsheets need the ability to reference a temporary file from CSS to work offline
# [01:07] <othermaciej> being able to read the file text, plus maybe ability to display loaded images, should be enough
# [01:08] * jmb^ is now known as jmb
# [01:08] * Quits: gsnedders (n=gsnedder@c83-252-195-113.bredband.comhem.se)
# [01:09] * aroben is now known as aroben|meeting
# [01:11] * Quits: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au) ("This computer has gone to sleep")
# [01:12] * Quits: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
# [01:14] * Joins: olliej (n=oliver@17.203.15.241)
# [01:14] * Quits: starjive (i=beos@213-66-216-93-no30.tbcn.telia.com)
# [01:15] <sebmarkbage> Anything needing to embed image or video. I should be able to use them in img, video, css or canvas. I like the URI approach since it's ubiquitous.
# [01:16] * Quits: Spark^ (n=x@94-194-199-197.zone8.bethere.co.uk) (Read error: 110 (Connection timed out))
# [01:16] * Quits: olliej (n=oliver@17.203.15.241) (Client Quit)
# [01:18] * Joins: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
# [01:19] * Joins: olliej (n=oliver@17.203.15.241)
# [01:24] * Quits: heycam (n=cam@124-168-9-27.dyn.iinet.net.au) ("bye")
# [01:31] * Quits: weinig_ (n=weinig@17.244.1.204)
# [01:35] * Joins: weinig (n=weinig@17.244.1.204)
# [01:38] * aroben|meeting is now known as aroben
# [01:39] <Hixie> good lord
# [01:39] <Hixie> what a lot of new feedback
# [01:43] <hober> yeah, that teal line has been trending upward for quite a bit there
# [01:43] * Quits: dglazkov (n=dglazkov@nat/google/x-47ba9a7b611cdc4f)
# [01:47] <sebmarkbage> Hixie: Where is the most appropriate place to leave new feedback? Forums? Mailing list?
# [01:51] <Hixie> mailing list is most ideal
# [01:51] <Hixie> see the top of the spec for details
# [01:52] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
# [01:52] * Joins: cying (n=cying@70.90.171.153)
# [02:01] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
# [02:02] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
# [02:03] * Quits: poe (n=poe@unaffiliated/xerox)
# [02:07] * Joins: archtech (n=stanv@83.228.56.37)
# [02:07] * Quits: archtech (n=stanv@83.228.56.37) (Remote closed the connection)
# [02:07] * Joins: archtech (n=stanv@83.228.56.37)
# [02:08] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
# [02:15] * Joins: nessy (n=nessy@203.110.150.154)
# [02:15] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
# [02:18] * Joins: slightlyoff (n=slightly@72.14.229.81)
# [02:18] * Quits: slightlyoff (n=slightly@72.14.229.81) (Remote closed the connection)
# [02:19] * Quits: dbaron_ (n=dbaron@nat/mozilla/x-1b695fbdbd24da88) ("8403864 bytes have been tenured, next gc will be global.")
# [02:21] * Quits: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com) ("Leaving.")
# [02:23] <sebmarkbage> Has there been any talk about explicitly specifying various mouse gestures? Like iPhone pinch could trigger onzoomin/onzoomout. I also think it'd be good to have something like draggable="gesture" that'd only trigger events on the source node.
# [02:23] * Joins: slightlyoff (n=slightly@72.14.229.81)
# [02:29] * Quits: tantek (n=tantek@208.80.69.102)
# [02:46] <Hixie> sebmarkbage: that's more of a suggestion for the events work -- www-dom@w3.org
# [02:48] <heycam> sebmarkbage, and i think olli pettay sent a mail to public-webapps or www-dom recently asking if there was any interest in speccing gesture/touch events
# [02:50] <sebmarkbage> thx. I will look through the archives.
# [02:50] * Joins: webben (n=benh@82.152.35.195)
# [02:54] * Quits: bzed (n=bzed@devel.recluse.de) (Remote closed the connection)
# [02:54] * Joins: bzed (n=bzed@devel.recluse.de)
# [02:55] * Quits: otherarun (n=arun@nat/mozilla/x-7165bef6f0b00147)
# [03:01] * Joins: hdh (n=hdh@2001:470:18:88:0:0:0:2)
# [03:02] * Quits: weinig (n=weinig@17.244.1.204) (Remote closed the connection)
# [03:02] * Joins: weinig (n=weinig@nat/apple/x-6f3610f0a3d678da)
# [03:11] * Quits: drostie (n=hopkins@5ED17066.cable.ziggo.nl) (Read error: 104 (Connection reset by peer))
# [03:12] * Quits: ap (n=ap@nat/apple/x-3dd7abbeec533813)
# [03:16] * Quits: MikeSmith (n=MikeSmit@EM114-48-27-177.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
# [03:19] * Joins: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
# [03:38] * Quits: tantek (n=tantek@c-67-160-236-52.hsd1.ca.comcast.net)
# [03:39] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
# [03:39] * Joins: billyjackass (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
# [03:40] * Quits: billyjackass (n=MikeSmit@tea12.w3.mag.keio.ac.jp) (Client Quit)
# [03:40] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) (Client Quit)
# [03:41] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
# [03:41] * Quits: webben (n=benh@82.152.35.195) (Read error: 110 (Connection timed out))
# [03:48] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [03:49] * Quits: hdh (n=hdh@2001:470:18:88:0:0:0:2) (Remote closed the connection)
# [03:52] * Quits: cying (n=cying@70.90.171.153)
# [03:57] * Quits: ttepasse (n=ttepas--@p5B0136D0.dip.t-dialin.net) ("?Q")
# [04:04] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [04:08] * Quits: archtech (n=stanv@83.228.56.37) (Read error: 60 (Operation timed out))
# [04:11] * Joins: weinig_ (n=weinig@17.244.1.204)
# [04:11] * Quits: weinig_ (n=weinig@17.244.1.204) (Client Quit)
# [04:11] * Quits: karlcow (n=karl@nerval.la-grange.net) (Remote closed the connection)
# [04:14] * Quits: slightlyoff (n=slightly@72.14.229.81) (Read error: 110 (Connection timed out))
# [04:20] * Joins: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net)
# [04:22] * Joins: karlcow (n=karl@nerval.la-grange.net)
# [04:26] * Quits: weinig (n=weinig@nat/apple/x-6f3610f0a3d678da) (Read error: 110 (Connection timed out))
# [04:30] * Quits: nessy (n=nessy@203.110.150.154) (Read error: 110 (Connection timed out))
# [04:32] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [04:33] * Joins: archtech (n=stanv@83.228.56.37)
# [04:38] * Joins: ap (n=ap@174-145-229-78.pools.spcsdns.net)
# [04:41] * Quits: hdh (n=hdh@hdh-1-pt.tunnel.tserv20.hkg1.ipv6.he.net) (Remote closed the connection)
# [04:43] * Quits: jwalden (n=waldo@nat/mozilla/x-e33cc56ff5fa732b) ("din-din")
# [04:46] * Quits: jorlow (n=jorlow@nat/google/x-c9682c2f12f03fb9)
# [04:51] * Joins: olliej_ (n=oliver@17.246.18.222)
# [05:00] * Joins: jorlow (n=jorlow@67.218.104.133)
# [05:01] * Joins: jorlow_ (n=jorlow@72.14.224.1)
# [05:03] * Quits: jorlow (n=jorlow@67.218.104.133) (Read error: 104 (Connection reset by peer))
# [05:04] * Joins: olliej__ (n=oliver@17.246.18.222)
# [05:04] * Quits: olliej_ (n=oliver@17.246.18.222) (Read error: 54 (Connection reset by peer))
# [05:06] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [05:07] * Quits: olliej (n=oliver@17.203.15.241) (Read error: 110 (Connection timed out))
# [05:09] * Joins: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au)
# [05:11] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [05:23] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
# [05:26] * Quits: jorlow_ (n=jorlow@72.14.224.1) (Read error: 110 (Connection timed out))
# [05:52] * Quits: olliej__ (n=oliver@17.246.18.222) (Read error: 104 (Connection reset by peer))
# [05:54] * Joins: olliej (n=oliver@17.246.18.222)
# [05:59] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
# [06:02] * Joins: MikeSmith (n=MikeSmit@dhcp-246-160.mag.keio.ac.jp)
# [06:21] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
# [06:30] * Joins: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
# [06:32] * Joins: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
# [06:46] * Quits: ap (n=ap@174-145-229-78.pools.spcsdns.net)
# [06:46] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) (Read error: 110 (Connection timed out))
# [06:54] * Joins: tantekc (n=tantek@70.36.139.128)
# [07:13] * Quits: dolske (n=dolske@nat/mozilla/x-89c0308f172339be)
# [07:33] * Quits: olliej (n=oliver@17.246.18.222)
# [07:37] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
# [07:42] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [07:50] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
# [07:51] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
# [08:04] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
# [08:24] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
# [08:27] * Joins: heycam (n=cam@dyn-130-194-69-200.infotech.monash.edu.au)
# [08:28] * Quits: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
# [08:28] <MikeSmith> hsivonen: I'm getting build errors after syncing up to latest v.nu sources
# [08:28] <MikeSmith> ./syntax/relaxng/datatype/java/src/org/whattf/datatype/MicrodataIdentifier.java:32: package com.sun.org.apache.xerces.internal.dom3.as does not exist
# [08:29] <hsivonen> MikeSmith: sorry. Eclipse has beeing doing random autocomplete again
# [08:29] <hsivonen> MikeSmith: fixing
# [08:30] <MikeSmith> thanks
# [08:30] <MikeSmith> dispense with the IDE, man. that's stuff for sissies :)
# [08:31] <hsivonen> MikeSmith: does it work now?
# [08:32] <hsivonen> I read comments on Zeldman's blog and now I'm having a "someone's wrong on the Internet" moment again
# [08:33] <hsivonen> appeals to the TAG even: http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44699
# [08:36] * Quits: Sirisian (n=Sirisian@ppp-69-221-227-63.dsl.klmzmi.ameritech.net) (Read error: 110 (Connection timed out))
# [08:38] <MikeSmith> hsivonen: works now -- thanks
# [08:40] * Quits: tantekc (n=tantek@70.36.139.128)
# [08:41] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
# [08:43] <MikeSmith> hsivonen: which part of the v.nu is emitting the new warnings?
# [08:43] <MikeSmith> nm
# [08:43] * MikeSmith finds syntax/non-schema/java/src/org/whattf/checker/ConformingButObsoleteWarner.java
# [08:46] * Joins: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
# [08:48] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
# [09:07] * Joins: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
# [09:07] * Joins: tantek (n=tantek@70.36.139.128)
# [09:15] * Joins: Khazou (n=Khazou@AReims-152-1-133-45.w86-215.abo.wanadoo.fr)
# [09:15] * Quits: darbour (n=Rachel@c-98-216-48-49.hsd1.ma.comcast.net) (Read error: 104 (Connection reset by peer))
# [09:27] * Joins: harig (n=harig@59.90.71.35)
# [09:27] * Quits: shikiesos (n=shiki@220.109.219.244) ("Leaving.")
# [09:31] * Quits: harig (n=harig@59.90.71.35) (Client Quit)
# [09:31] * Joins: harig (n=harig@59.90.71.35)
# [09:40] * Joins: shikiesos (n=shiki@220.109.219.244)
# [09:44] * Quits: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
# [10:13] * Joins: roc (n=roc@121.74.180.224)
# [10:15] * Quits: heycam (n=cam@dyn-130-194-69-200.infotech.monash.edu.au) ("bye")
# [10:17] * Quits: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
# [10:17] * Joins: gunderwonder (n=gunderwo@garage.upstruct.com)
# [10:21] * Quits: MikeSmith (n=MikeSmit@dhcp-246-160.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
# [10:23] * nessy giggles at the whattf directory :)
# [10:24] * Joins: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp)
# [10:25] <takkaria> the zeldman comments are pretty amazing
# [10:26] <MikeSmith> takkaria: in what way?
# [10:26] * Joins: abii (n=macbook@cm27.delta30.maxonline.com.sg)
# [10:26] <takkaria> there's somsone there claiming they're going to have to relearn most of the stuff they know to the code a website with the advent of HTML5
# [10:27] <MikeSmith> ah
# [10:27] <hsivonen> I guess my comment is still in a moderation queue.
# [10:28] * hsivonen wishes blog comment systems said "Your comment is awaiting moderation" when it is
# [10:28] <hsivonen> the commenter using the handle "Luke" is onto something
# [10:29] <hsivonen> too bad (s)he feels the need to post anonymously
# [10:30] <hsivonen> http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44679
# [10:31] * Quits: roc (n=roc@121.74.180.224)
# [10:31] <Hixie> who used the "it will help screen readers" line?
# [10:32] <Hixie> of the new sectioning elements, only <nav> has been put forward as being able to help screen reader users, as far as i'm aware
# [10:32] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
# [10:33] <hsivonen> Hixie: hasn't footer been, too? and every one of them by the logic that if ARIA landmarks help, the HTML5 structural elements should, too
# [10:33] <takkaria> apparently adding role="" is a much more incremental step than <header>/<nav>/ et all
# [10:33] <Philip`> People have talked about using the sectioning elements to do an automatic "skip to content", which mainly helps screen reader users
# [10:34] <jgraham> Better outlining seems like it wwould help screenreader users, as does "skip to next article" even without good use of headings
# [10:34] <hsivonen> Philip`: Opera Mobile has a heuristic "skip to content" feature
# [10:34] <Philip`> hsivonen: Does it work better than e.g. Opera's "next page" heuristic?
# [10:34] <hsivonen> Philip`: presumably this stuff could tie into that feature, too
# [10:35] <hsivonen> Philip`: it works amazingly well. I wish Mini had it, too.
# [10:36] <Hixie> man i can't wait til blogs are all federated across wave
# [10:36] <Hixie> it would make tracking these comments and responding properly so much easier
# [10:36] <hsivonen> maybe that happens when all Java jar dependencies are federated over Maven
# [10:37] * jgraham onders if wave uses the term "federated" because it sounds vaugely like something from Star Trek so subconciously suggesting 23rd Century technology
# [10:37] <Philip`> Hixie: Can't you just follow the RSS comment feeds?
# [10:37] <Hixie> i can't respond to RSS comment feeds and have them appear in the other person's RSS feed
# [10:38] <hober> jgraham: we just need a wave app on our communicators, err, iphones.
# [10:38] <Hixie> jgraham: it uses it because that's what jabber uses, iirc
# [10:38] <jgraham> OK, well s/wave/jabber/ in the above then :)
# [10:38] <Hixie> no idea
# [10:39] <hsivonen> I tend to get an enterprisey vibe from "federated"
# [10:39] <hsivonen> probably from associations with WS-* stuff
# [10:40] <hsivonen> I do think that federated SSO, chat, etc. are good
# [10:40] <Hixie> "enterprise" also has the startrek feel :-P
# [10:40] <hsivonen> heh
# [10:40] <hsivonen> WS-* has a StarWars feel, though :-)
# [10:41] <jgraham> Yeah. Talking about things being "federated to your enterprise" seems like a winning strategy because it allows CEOs to like out their Picard fantasy
# [10:41] <jgraham> s/like/live/
# [10:45] * Joins: webben (n=benh@nat/yahoo/x-a1d5bf4bd71165da)
# [10:47] * hsivonen gestures angrily in the general direction of whoever invented the syntactic sugar for declaring multiple variables in one declarator
# [10:51] * Joins: heycam (n=cam@124-168-9-27.dyn.iinet.net.au)
# [11:07] * Joins: mat_t (n=mattomas@nat/canonical/x-eb63950733a08e81)
# [11:10] * Joins: ROBOd (n=robod@89.122.216.38)
# [11:11] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
# [11:12] * Joins: Phae (n=phaeness@gatea.mh.bbc.co.uk)
# [11:13] <zcorpan> Hixie: Scripts that modify the page as it is being parsed - is not error handling
# [11:13] <Hixie> yeah but there's no doctype!
# [11:14] <zcorpan> the section doesn't discuss the doctype :)
# [11:18] <Lachy> Hixie, John Allsop may have a valid point about the <footer> content model that he mentioned here http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/#comment-44699 - Sites like YouTube and Flickr group the links in their footers by category. Although they currently use table layouts to achieve it, it seems reasonable to do that with sections
# [11:18] <Hixie> zcorpan: details! :-P
# [11:18] <Hixie> zcorpan: (i'm happy to change that section title if you can find a better one -- drop me a mail)
# [11:19] <Hixie> Lachy: those are <section>s. They're at best paragraphs.
# [11:19] <Hixie> maybe <dl>s
# [11:19] <Lachy> ok
# [11:20] <Lachy> well, I'm not sure if they're the type of sites he's referring to though. That's just the closest I could find that matches his description
# [11:20] <Hixie> well when he sends his feedback like he told me he would we'll see :-)
# [11:23] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
# [11:24] * Quits: danbri (n=danbri@unaffiliated/danbri) (Read error: 104 (Connection reset by peer))
# [11:24] <zcorpan> Hixie: i think it is now undefined what document.bgcolor does when document.body *is* a frameset
# [11:24] * Joins: danbri (n=danbri@85.144.208.21)
# [11:24] <Hixie> zcorpan: send mail, i'm in the middle of a massive edit
# [11:25] * Joins: RyanRoberts (n=ryanrobe@5ad6a77a.bb.sky.com)
# [11:34] * Joins: gsnedders (n=gsnedder@pat.se.opera.com)
# [11:34] * Joins: poe (n=poe@adsl-ull-160-123.48-151.net24.it)
# [11:55] * Quits: tantek (n=tantek@70.36.139.128)
# [12:20] <gsnedders> Hixie: http://www.whatwg.org/specs/web-apps/current-work/ is missing header-whatwg
# [12:21] <Hixie> yeah
# [12:21] <Hixie> i'm rewriting the script
# [12:21] <Hixie> it still has bugs
# [12:23] * gsnedders looks at the W3C version instead
# [12:23] * Joins: rubys1 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
# [12:24] <MikeSmith> Hixie: btw, I plan to write a cron job that will generate a multipage version of the W3C copy
# [12:24] <MikeSmith> I meant to do it today, but didn't
# [12:25] <MikeSmith> today being, it's 19:20 here and I need to get some food and alcohol of some form
# [12:26] <MikeSmith> but to give a heads-up, I would like to also set up a .htaccess file so that the index file for the multipage version becomes the default
# [12:26] <MikeSmith> with a link to the single-page one
# [12:27] <Hixie> k
# [12:27] <MikeSmith> which I realize might break some people's bookmarks and such
# [12:28] <MikeSmith> I'm mentioning because when I do get it set up, I would need for you to add the link on the single-page version
# [12:28] <MikeSmith> your source, I mean
# [12:28] * gsnedders also set up http://gsnedders.html5.org/html5.txt semi-jokingly
# [12:29] <MikeSmith> gsnedders: there's at least one SDO I know of for which that format looks optimized
# [12:29] <MikeSmith> good job
# [12:30] <hsivonen> gsnedders: how are you generating it? Lynx?
# [12:30] <gsnedders> MikeSmith: But we don't have all the proper form feed characters and such like in the right place
# [12:30] <gsnedders> hsivonen: yeah
# [12:30] <hsivonen> gsnedders: it has a very IETF-like flavor
# [12:32] <MikeSmith> gsnedders: I think I like link #19944 best
# [12:32] <gsnedders> MikeSmith: I quite like #772
# [12:33] * Quits: poe (n=poe@unaffiliated/xerox)
# [12:33] <MikeSmith> ah yes, good old #772
# [12:33] <MikeSmith> solid gold
# [12:34] <MikeSmith> zen-like
# [12:36] <MikeSmith> but outside of that instance, the combination of plain text with ridiculously long fragment IDs has its own kind of aesthetic quality
# [12:36] <Philip`> MikeSmith: The WHATWG multipage one has a script that ensure bookmarks to /#foo will get redirected to /bar.html#foo etc
# [12:36] <MikeSmith> (scare quotes implied in my statement above)
# [12:36] <MikeSmith> Philip`: OK, maybe I can make use of that
# [12:36] <MikeSmith> after I actually get around to doing it
# [12:37] <MikeSmith> instead of just talking about, repeatedly
# [12:37] <Philip`> If you talk about doing the work enough times, someone else will do the work to shut you up
# [12:38] <MikeSmith> great strategy
# [12:38] <MikeSmith> I will try that
# [12:38] <MikeSmith> will try it later
# [12:38] <MikeSmith> in the mean time, I noticed that the beer clock rang 90 minutes ago
# [12:39] <MikeSmith> so I must depart
# [12:39] <gsnedders> MikeSmith: Good bye, fair well, and best wishes for your future life!
# [12:40] * MikeSmith fires up his chopper and heads to the rock shop
# [12:40] * Quits: MikeSmith (n=MikeSmit@tea12.w3.mag.keio.ac.jp) ("Tomorrow to fresh woods, and pastures new.")
# [12:44] <Hixie> gsnedders: ok, it should be ok again
# [12:50] * Joins: heycam` (n=cam@203-217-77-251.dyn.iinet.net.au)
# [12:57] <gsnedders> getComputedStyle returns interesting values for iframes
# [12:58] <Hixie> self.numberOfSpecs += 1
# [12:59] * Quits: heycam (n=cam@124-168-9-27.dyn.iinet.net.au) (Read error: 101 (Network is unreachable))
# [13:01] <hsivonen> http://www.w3.org/mid/A7420EAA6B164D40A3D94E082C4D2773@JukanPC
# [13:01] <hsivonen> last paragraph
# [13:02] <Hixie> o_O
# [13:02] <hsivonen> I could well imagine Jukka blasting us for making it valid had we done that
# [13:02] <Hixie> he wants the character references that refer to numbers that aren't the specified numbers to be conforming?
# [13:03] <Hixie> i don't understand that e-mail
# [13:03] <Hixie> he says it's undefined but it should be allowed?
# [13:03] <Hixie> how does that even make sense
# [13:04] <hsivonen> Hixie: maybe you could ask him what he wants
# [13:04] <Hixie> since he thinks html5 is pointless, i don't see much point asking him
# [13:05] <hsivonen> fair enough
# [13:05] <hsivonen> when did Jukka flip the bozo bit on us?
# [13:07] <hsivonen> I need some kind of Mail.app trick for dealing with duplicate email on 3 mailing lists plus self
# [13:08] <Hixie> route your mail through gmail
# [13:08] <Hixie> it filters dupes
# [13:09] <Hixie> dunno when jukka flipped the bit, but it was a while back
# [13:09] <Hixie> ok i now have less e-mail on the pile than this morning. Only by 3 e-mails, but still.
# [13:09] <Hixie> bed time
# [13:09] <Hixie> nn
# [13:14] * Joins: pesla (n=retep@procurios.xs4all.nl)
# [13:22] * Quits: webben (n=benh@nat/yahoo/x-a1d5bf4bd71165da) (Read error: 110 (Connection timed out))
# [13:25] * Quits: rubys1 (n=Adium@cpe-098-027-052-152.nc.res.rr.com) ("Leaving.")
# [13:29] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 113 (No route to host))
# [13:32] * Quits: ray (i=ray@ipv6.the.ug) (Read error: 60 (Operation timed out))
# [13:32] * Joins: ray (i=ray@ipv6.the.ug)
# [13:32] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
# [13:40] * Joins: zdobersek (n=zan@cpe-92-37-66-98.dynamic.amis.net)
# [13:40] * Quits: Lachy (n=Lachlan@85.196.122.246) ("Leaving")
# [13:42] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [13:44] * Joins: tndH (n=Rob@129.11.105.100)
# [13:53] <takkaria> hm, I just discvered the CSS property table-layout
# [13:54] <takkaria> I wonder how I've gone so long without knowing it exists
# [13:55] <takkaria> I think I'd actually have preferred not to know about it...
# [13:55] <RyanRoberts> FF2 supports it so probably a while ;)
# [13:57] <jgraham> hmm I'm not sure I remember that one either
# [13:57] <jgraham> Well I have a vauge memory of having encountered it before
# [13:58] <RyanRoberts> actually I maybe mistaken
# [13:59] * Quits: tndH (n=Rob@129.11.105.100) (Read error: 104 (Connection reset by peer))
# [13:59] <takkaria> table-layout: fixed is an abomination, it lets you tell tables to not pay attention to the size of the content of its cells when calculating layout
# [14:00] <RyanRoberts> it's CSS2 isn't it? I rarely use tables so not used it often but I'm sure I've come across it.
# [14:00] <takkaria> yeah, css2
# [14:00] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
# [14:03] <jgraham> I guess someone decided that the default algorithm was slow/complex/hard to specify and thought "I know why don't we add an option"
# [14:03] <jgraham> But the mailing list archives don't turn anything up
# [14:10] <Lachy> takkaria, table-layout: fixed; actually has some benefits. You just have to be careful about how you use it.
# [14:10] * hsivonen wonders if Google has criteria for phasing out support for old browser versions
# [14:11] <Philip`> Revenue from ads for old browsers users < cost of supporting old browser versions, perhaps
# [14:12] <Lachy> takkaria, one benefit is that it makes table columns equal width by default, which is otherwise difficult to achieve when the number of columns can vary but you always want the table to be a set width regardless
# [14:12] * Joins: tndH (n=Rob@129.11.60.45)
# [14:13] <Philip`> http://philip.html5.org/tests/canvas/suite/tests/results.html uses table-layout:fixed
# [14:14] <hsivonen> I wonder how much RAM I'd need not to beach ball all the time
# [14:15] * Quits: pesla (n=retep@procurios.xs4all.nl) (hubbard.freenode.net irc.freenode.net)
# [14:15] * Quits: gsnedders (n=gsnedder@pat.se.opera.com) (hubbard.freenode.net irc.freenode.net)
# [14:15] * Quits: syp_ (n=syp@lasigpc9.epfl.ch) (hubbard.freenode.net irc.freenode.net)
# [14:15] * Joins: syp_ (n=syp@lasigpc9.epfl.ch)
# [14:15] * Joins: pesla (n=retep@procurios.xs4all.nl)
# [14:15] * Joins: gsnedders (n=gsnedder@88.131.66.80)
# [14:15] <Lachy> hsivonen, how much RAM do you have?
# [14:16] <hsivonen> 4 GB
# [14:16] <Lachy> which apps are causing the beach ball so frequently?
# [14:17] <hsivonen> I guess the combination of multiple browsers, IDEs and operating systems
# [14:17] <jgraham> virtual machines that reserve large chunks of RAM are a killer
# [14:17] <Lachy> oh. yeah, if you keep multiple OSs running in VMs all the time, there's not much you can do about it
# [14:17] <Philip`> You could get faster swap space
# [14:18] <Lachy> although, it wouldn't hurt upgrading to a new machine with 8GB or RAM
# [14:18] <jgraham> Can you use SSDs as swap yet? and does that work well?
# [14:18] <Philip`> jgraham: Why would you have ever been unable to?
# [14:18] <hsivonen> Lachy: Macs that can host more than 4 GB of RAM are expensive and large
# [14:19] <jgraham> Philip`: Because they didn't exist. ALso because they had very poor rewrite characteristics
# [14:19] <Lachy> hsivonen, the new MacBook Pro's support 8GB. Just buy your RAM from a 3rd party supplier, instead of through Apple
# [14:19] <jgraham> (like they would die after an alarmingly small number of rewrites)
# [14:19] <hsivonen> oh. I was unaware of MacBook Pro accepting 8 GB
# [14:20] <hsivonen> perhaps I should pay up and get one of those
# [14:20] <Lachy> yeah, as of the most recent update, they do
# [14:20] <jgraham> hsivonen: Would it actually be a blocker for you to use a Mac Pro as your main development machine and just use a laprop when travelling?
# [14:20] <jgraham> THat seems like a more sensible solution
# [14:21] * Joins: zdobersek1 (n=zan@cpe-92-37-76-123.dynamic.amis.net)
# [14:21] * Quits: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
# [14:21] <hsivonen> jgraham: Mac Pro seems like an overkill in every dimension except RAM
# [14:22] * Joins: myakura (n=myakura@p5137-ipbf707marunouchi.tokyo.ocn.ne.jp)
# [14:22] * Quits: tndH (n=Rob@129.11.60.45) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.0.1/2008072406]")
# [14:22] <jgraham> hsivonen: Hmm. It just seems worryingly shortsighted to upgrade to a machine in order to use its maximum amount of RAM
# [14:23] <jgraham> Since probably in 1 year you will want more again
# [14:23] <Lachy> hsivonen, a dual Quad Core Mac Pro with 32 GB of RAM would be awesome!
# [14:25] <hsivonen> I could also try running a manual garbage collection of my Firefox tabs once in a while
# [14:25] * Joins: webben (n=benh@nat/yahoo/x-cbca5c264341e7a5)
# [14:25] <hsivonen> the annoying part is that closing multiple tabs beach-balls Firefox
# [14:26] * Joins: aboodman2 (n=aboodman@72.14.229.81)
# [14:28] * Quits: webben (n=benh@nat/yahoo/x-cbca5c264341e7a5) (Read error: 104 (Connection reset by peer))
# [14:30] <gsnedders> What's the W3C IRC server?
# [14:30] <hsivonen> irc.w3.org with weird port
# [14:30] <hsivonen> 6667 or 6665 but not the one that's normal
# [14:31] <Lachy> either port 6665 or port 80 works
# [14:31] <hsivonen> I wonder if port 80 complies with Architecture.
# [14:32] <Lachy> I don't think they care too much if it does. They just need it to bypass overzealous port blocking
# [14:33] * Quits: aboodman (n=aboodman@72.14.229.81) (Connection timed out)
# [14:33] * Quits: zdobersek (n=zan@cpe-92-37-66-98.dynamic.amis.net) (Read error: 110 (Connection timed out))
# [14:45] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [15:04] * Joins: webben (n=benh@nat/yahoo/x-4621a04377acbccd)
# [15:07] * Quits: archtech (n=stanv@83.228.56.37)
# [15:07] * Quits: abii (n=macbook@cm27.delta30.maxonline.com.sg)
# [15:09] * Joins: pmuellr (n=pmuellr@nat/ibm/x-9a9eaae68b97bf6f)
# [15:29] * Quits: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
# [15:33] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
# [15:35] * Quits: jgraham (n=jgraham@web22.webfaction.com) (Read error: 104 (Connection reset by peer))
# [15:36] <zcorpan> Hixie: + attribute unsigned <span title="dom-img-vspace">vspace</span>;
# [15:36] <zcorpan> Hixie: should say unsigned long
# [15:39] * Joins: taf2_ (n=taf2@38.99.201.242)
# [15:40] * Quits: nessy (n=nessy@203-166-254-161.dyn.iinet.net.au) ("This computer has gone to sleep")
# [15:53] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [16:01] * Joins: ap (n=ap@72-62-10-39.pools.spcsdns.net)
# [16:16] * Joins: dave_levin_ (n=dave_lev@98.203.247.78)
# [16:24] * Quits: ap (n=ap@72-62-10-39.pools.spcsdns.net)
# [16:28] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.85 [Firefox 3.6a1pre/20090711143741]")
# [16:31] * Joins: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [16:32] * Joins: mookid (i=mookid@ROFL.name)
# [16:33] * Joins: svl (n=me@86.87.68.167)
# [16:36] <mookid> hello collection of hated people
# [16:36] <mookid> how's it hanging?
# [16:38] <takkaria> I'm feeling pretty hated today
# [16:39] <mookid> and all you had to do was make the internet better
# [16:39] <mookid> pfff
# [16:41] <krijnh> Am I hated as well?
# [16:41] <krijnh> For doing what, nothing?
# [16:41] <Lachy> mookid, there are some people in here who aren't hated by anyone
# [16:41] <krijnh> Pick me, pick me
# [16:42] * Quits: dglazkov (n=dglazkov@c-69-181-143-54.hsd1.ca.comcast.net)
# [16:42] <mookid> well you're associated
# [16:42] <Lachy> mookid, do you dislike such people enough to not feel like saying hi to them as well?
# [16:42] <mookid> that's bad enough
# [16:42] <mookid> I didn't say I hated you
# [16:42] <mookid> I think you're hillarious
# [16:42] <mookid> personally
# [16:46] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
# [17:00] * Joins: ap (n=ap@nat/apple/x-d51eab098a917e7f)
# [17:03] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
# [17:06] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
# [17:06] * Joins: dglazkov (n=dglazkov@nat/google/x-6a932a9011b44ea7)
# [17:09] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
# [17:14] * Quits: ZombieL (n=e@78-72-50-94-no61.tbcn.telia.com) (Client Quit)
# [17:19] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
# [17:24] * Joins: jgraham (n=jgraham@74.53.238.210)
# [17:27] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
# [17:27] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [17:31] * Quits: harig (n=harig@59.90.71.35)
# [17:40] * Quits: gunderwonder (n=gunderwo@garage.upstruct.com)
# [17:46] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-3cb6fef9ae9fc32c)
# [17:51] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
# [17:51] * Quits: myakura (n=myakura@p5137-ipbf707marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
# [17:53] * Joins: dbaron (n=dbaron@nat/mozilla/x-de7f3e627e31161f)
# [17:55] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) (Read error: 110 (Connection timed out))
# [17:57] * Quits: dave_levin_ (n=dave_lev@98.203.247.78)
# [17:58] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
# [18:02] * Quits: Khazou (n=Khazou@AReims-152-1-133-45.w86-215.abo.wanadoo.fr)
# [18:05] * Joins: remysharp (n=remyshar@remysharp.plus.com)
# [18:06] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-6a7ef9ccf1ff5494)
# [18:07] * Joins: jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net)
# [18:08] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [18:18] <ezyang> So, if something is ignored but "not conforming", does that result in a parse error?
# [18:18] <ezyang> A "non-conforming error"?
# [18:19] * Joins: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
# [18:22] <Philip`> ezyang: If something is not said to be a parse error, then I would expect that it's not a parse error
# [18:22] <Philip`> (though it could still be a conformance failure)
# [18:22] <ezyang> Sure.
# [18:23] <Philip`> So I'm not sure what your query is :-)
# [18:23] <ezyang> The html5lib spec doesn't give me a lot to work on in terms of algorithms that convert nonconforming HTML to conforming HTML
# [18:23] <ezyang> erm, s/html5lib/HTML 5/
# [18:23] <Philip`> In general that's impossible
# [18:23] <Philip`> since it's not even possible for a machine to determine whether a document is conforming or not
# [18:24] <Philip`> so I suppose you'll have to choose what set of errors you want to restrict yourself to fixing
# [18:25] <ezyang> Oh yeah, of course. The goal is "anything that is machine detectable"
# [18:26] * aroben is now known as aroben|lunch
# [18:27] <jgraham> ezyang: Still not possible (at least in some sensible way) e.g. if alt were mandatory there would be no way to take an image with no alt value (machine detectable) and insert the correct alt value
# [18:28] <jgraham> Even in more simple cases my feeling is that "you don't want to do that" even though clearly some people do want to do that
# [18:28] <ezyang> haha. My algorithm there is to insert the filename, or some configurable value.
# [18:29] <jgraham> ezyang: Fail
# [18:29] <Philip`> Will you handle stuff like <table><tr><td><td rowspan=2><tr><td colspan=2></table> too? :-)
# [18:29] <ezyang> Philip`: I don't handle that yet, but it's presumably an algorithm I could write.
# [18:29] <jgraham> ezyang: Seriously there is nothing good about inserting the filename automatically and a bunch of bad things. Please don't do it
# [18:30] <ezyang> Can I... insert a Zen koan?
# [18:30] <Philip`> jgraham: The good thing is that the validator will give you a tick, and that's what really matters
# [18:31] <jgraham> Philip`: :(
# [18:32] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
# [18:32] <ezyang> Unfortunately, that's the most user visible, and I have a commitment to not break that.
# [18:32] <gsnedders> ezyang: From an a11y POV, you don't want to add an alt attribute to some useless value.
# [18:33] <Philip`> (I presume the main point of a non-conforming-to-conforming converter is to let you get ticks, because in terms of e.g. preserving the author's intent it's going to be worse than HTML5's processing requirements for non-conforming content)
# [18:33] <ezyang> I mean, ideally the form processor would be smart enough to recognize these unresolvable cases and ask the user what they actually meant.
# [18:34] <ezyang> Philip`: The other point of nonconforming to conforming is because it means we can unambiguously determine intent.
# [18:34] <jgraham> ?!?
# [18:34] <ezyang> The space of conforming HTML is much smaller than nonconforming HTML, and browser behavior much better studied.
# [18:34] <ezyang> sorry, bad word choice
# [18:34] <ezyang> When I say intent, I mean, the way browsers will deal with it.
# [18:35] <ezyang> i.e. it gives desirable security properties.
# [18:35] <gsnedders> Once all browsers use HTML 5 parsers, that's no longer the case.
# [18:35] * jgraham doesn't understand how original code -> magic black box -> conforming code really helps
# [18:35] <jgraham> I certianly don't see how it is a security issue
# [18:35] <gsnedders> jgraham: XSS
# [18:35] <Philip`> ezyang: If the goal is to fix markup that will have browser behaviour differences, then that seems very different to translating all non-conforming markup
# [18:36] <jgraham> gsnedders: Conforming code can have XSS holes
# [18:36] <Philip`> e.g. you wouldn't have to worry about img with no alt even if it was non-conforming
# [18:36] <gsnedders> jgraham: <a href=`javascript:alert("so sue me")`>asd</a> will run the JS in IE but is non-conforming
# [18:36] <ezyang> Right, so there are multiple issues here.
# [18:36] <gsnedders> Actually, I don't think that is non-conforming.
# [18:36] <jgraham> gsnedders: Right so you should strip that in a sanitizer, conforming or not
# [18:37] * Quits: Phae (n=phaeness@gatea.mh.bbc.co.uk)
# [18:37] <Philip`> and you would have to worry about conforming code like
# [18:37] <ezyang> From the XSS standpoint, syntactic conformance is a huge plus. Not as much for tags, although by whitelisting to conformant tags and then further removing problem tags, you further restrict things.
# [18:37] <gsnedders> It probably should be non-conforming, though, for the very reason that IE will execute that
# [18:37] <ezyang> Philip`: I explicitly disallow comments because of the fact that they commonly carry out of band information that is exploitable
# [18:38] <Philip`> ezyang: So you're making a sanitiser, rather than a tool to convert non-conforming markup to conforming markup?
# [18:38] <jgraham> For XSS I would have thought that applying sanitization based on the HTML5 algorithm is enough. Whether the result is conforming or not is irrelevant
# [18:38] <ezyang> But not just that
# [18:38] <gsnedders> Philip`: It's both
# [18:38] <Philip`> That sounds needlessly complex :-)
# [18:38] <jgraham> Certianly whether it has alt attributes is irrelevant
# [18:38] <gsnedders> http://htmlpurifier.org/demo.php
# [18:39] <ezyang> From a marketing standpoint, it also makes sense to fix any conformance errors so that users can have the nice fuzzy feeling of a Green validator check.
# [18:39] <ezyang> It is then that alt attributes are relevant.
# [18:39] <gsnedders> ezyang: Even if that actually makes them less accessible?
# [18:39] * Joins: Spark^ (n=x@94-194-199-197.zone8.bethere.co.uk)
# [18:39] <jgraham> ezyang: It feels like we have got to the real reason for wanting conforming output
# [18:39] <gsnedders> ezyang: And quite possibly makes them non-conforming in another way?
# [18:39] * Joins: cying (n=cying@70.90.171.153)
# [18:40] <jgraham> or rahter "valid"
# [18:40] <jgraham> *rather
# [18:40] <gsnedders> (As I'd hope giving useless @alt would be non-conforming, as I hope it requires an alternative to the image)
# [18:40] <Philip`> We could add a <pretendthisisconforming> element to HTML5 so people can get validator ticks without having to make their code worse
# [18:41] <gsnedders> ezyang: The problem with trying to make code valid is you can quite easily make it a lot worse from a conformance and accessibility point of view
# [18:41] <ezyang> I think alt is the big offender.
# [18:43] * Joins: dave_levin_ (n=dave_lev@72.14.227.1)
# [18:44] <ezyang> So, to reiterate, conformance has various benefits: 1. you get validator ticks, 2. syntactic conformance makes XSS harder, 3. conforming HTML has more regular browser interpretation, letting us canonicalize the interpretation
# [18:44] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) ("ChatZilla 0.9.85 [Firefox 3.5.1pre/20090712031210]")
# [18:44] <ezyang> You roll over accessibility in the img alt case, but this can be fixed by smarter form processing, and is fairly isolated.
# [18:47] <gsnedders> ezyang: 1 is not a benefit.
# [18:47] <jgraham> 1 is not a benefit on its own. 2 seems extremely dubious to me. 3 is probably true but since you are basically just putting things through a magic black box you still won't get the results you expect in many cases
# [18:47] <gsnedders> ezyang: 2 doesn't need validity
# [18:48] <gsnedders> ezyang: 3 can't really be done programmatically.
# [18:48] <gsnedders> (I say 2 doesn't need validity as it can be done just by doing stuff token-by-token)
# [18:48] <gsnedders> (You can get a lot of the benefits of 2 just by parsing then serializing, and doing nothing more)
# [18:49] <Philip`> http://htmlpurifier.org/demo.php?filter%5BAutoFormat.PurifierLinkify.DocURL%5D=%ef%bf%bf
# [18:50] <jgraham> Actually if you have any attacks that htmlpurifier prevents but the html5lib sanitizer does not you should really file a bug on us
# [18:50] * gsnedders notes that that was reported before and fixed, so is a regression
# [18:50] <gsnedders> jgraham: We won't stop <script>alert("foo")</script> though
# [18:51] <Philip`> gsnedders: No attacker would think we're stupid enough to try just writing a script tag, so they'll never know
# [18:51] <gsnedders> Oh, wait, duh
# [18:51] <jgraham> gsnedders: THe sanitizer will strip that
# [18:51] <gsnedders> sanitizer, not serializer
# [18:52] * Quits: remysharp (n=remyshar@remysharp.plus.com) ("Gotta shoot - "peeyaow"")
# [18:54] <ezyang> Philip`: That... should have been fixed.
# [18:54] <ezyang> Oh, that's a bug in the form code, not in the purifier
# [18:55] <Philip`> (There's http://htmlpurifier.org/demo.php?filter%5BAutoFormat.AutoParagraph%5D=cheese too)
# [18:55] * Parts: rubys2 (n=Adium@cpe-098-027-052-152.nc.res.rr.com)
# [18:56] <Philip`> I like how Sourceforge has adopted a colour scheme in which its forum messages are thin light grey text on a light blue background, and if I look at my laptop screen from an angle greater than twenty degrees then the text entirely disappears
# [18:57] <ezyang> gsnedders: There is one main point that requires some sort of tree building algorithm, which is preventing user HTML elements from leaking to the parent tree.
# [18:58] <gsnedders> ezyang: Sure, just parse and serialize to get there.
# [18:58] <gsnedders> ezyang: Nothing more than that is needed for that,
# [18:58] * Quits: bgalbraith (n=bgalbrai@nat/mozilla/x-3cb6fef9ae9fc32c)
# [18:58] <gsnedders> ezyang: Also, both myself and jgraham have doubts over two, as most of the issues will be fixed by parsing and serializing the tree, provided you quote attribute values and special case one or two things like < in tag name
# [18:58] <ezyang> Whitelist philosophy means that I should very thoroughly inspect attributes and recursively parse data formats (i.e. CSS to URI)
# [18:59] <gsnedders> ezyang: Sure, but that doesn't have anything to do with building a balanced tree
# [18:59] <ezyang> It also means that I should know exactly what tags that I'm going to allow.
# [18:59] <jgraham> Parsing CSS is a good idea. I would like to add that to html5lib
# [18:59] <ezyang> Ok, so the core issues
# [19:00] <ezyang> building a conforming tree, and generating required attributes
# [19:00] <ezyang> Which y'all would like to convince me to not do.
# [19:01] <ezyang> Everything else that HTML Purifier is useful, no?
# [19:01] <ezyang> *is doing
# [19:01] <gsnedders> ezyang: You cannot create a conforming tree programmatically. You can, however, produce a valid tree.
# [19:02] * Quits: jianli (n=jianli@72.14.227.1)
# [19:02] <ezyang> oh yes, that's what I meant
# [19:02] * Joins: jianli (n=jianli@72.14.227.1)
# [19:02] <jgraham> ezyang: I expect so althogh I don't know what all the other things it is doing are
# [19:02] <gsnedders> ezyang: Everything else meaning what?
# [19:02] <ezyang> With regards to fulfilling HTML 5 conformance requirements
# [19:03] * Quits: pmuellr (n=pmuellr@nat/ibm/x-9a9eaae68b97bf6f)
# [19:03] <ezyang> We want to fulfill syntactic conformance, which you get from tokenizing the stream
# [19:03] * Joins: yshin (n=yshin@72.14.227.1)
# [19:03] <ezyang> We want to build a tree, which has its own conformance things associated with it (i.e. <b><i>f</b></i>), which you get from tree-building
# [19:03] <jgraham> The point about trying to create valid markup is that the main benefit seems to be a happy feeling conformance tick but there are substantial costs in terms of complexity, possibilites of harming end users, possibility of automagically misinterpreting the markup
# [19:04] <ezyang> We want to recursively validate attributes, which increases conformance
# [19:04] <gsnedders> What does HTML Purifier aim to do? Does it aim to produce secure markup, does it aim to produce valid markup?
# [19:04] <ezyang> It aims to do both.
# [19:04] * Joins: pmuellr (n=pmuellr@nat/ibm/x-5fcaa3aa698b5250)
# [19:04] <ezyang> You could remove maybe 15% if you got rid of the valid markup requirement, specifically valid trees and attribute generation.
# [19:05] <gsnedders> Fundamentally the latter is not a useful goal.
# [19:05] <ezyang> The primary complexity comes from whitelisting and attribute validation
# [19:05] <ezyang> Possibly.
# [19:05] <gsnedders> You will get a lot of it from just parsing and serializing the tree, certainly
# [19:05] <gsnedders> But that is a side-effect, more than anything else.
# [19:05] <ezyang> Which is why I'm planning on swapping out most of my code for html5lib when the PHP impl gets stable enough
# [19:07] * Quits: aroben|lunch (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
# [19:07] * Joins: aroben|lunch (n=aroben@unaffiliated/aroben)
# [19:07] <gsnedders> Basically, I think what you need to do is parsing the input stream, remove elements/attributes on whitelist, remove some more attributes based upon their value, then serialize, quoting attribute values.
# [19:07] <gsnedders> I think that should get you security.
# [19:08] <Philip`> (and remove comments)
# [19:09] <ezyang> gsnedders: I argue that removing attributes based on value is the wrong paradigm (it should be machine-semantic deconstruction of each attribute), but yes, essentially.
# [19:09] <ezyang> And remove comments, yep.
# [19:09] <gsnedders> ezyang: What's the difference?
# [19:09] <gsnedders> ezyang: That is, ultimately, just inspecting the value. No?
# [19:10] * Joins: drostie (n=hopkins@5ED17066.cable.ziggo.nl)
# [19:10] <ezyang> Semantic deconstruction means that attribute values might change.
# [19:10] <Philip`> The html5lib sanitiser has e.g. a regexp for detecting 'safe' style attribute values, and throws out any attribute that doesn't match, I think
# [19:10] <ezyang> Canonicalization of a URL or CSS string is more important
# [19:10] <gsnedders> Ah, OK
# [19:10] <gsnedders> Yeah, right.
# [19:10] <ezyang> Right. That kind of regex doesn't make me feel safe
# [19:10] <Philip`> Me neither
# [19:10] <ezyang> Although theoretically it might be secure.
# [19:11] <gsnedders> For most attributes though, it is just looking at the value and nothing more
# [19:11] <gsnedders> And I'm throwing together stuff from the top of my head :)
# [19:11] <Philip`> The person who discovered the regexp takes exponential time on certain inputs probably wasn't too happy
# [19:11] * gsnedders was just discussing that with jgraham
# [19:11] <Philip`> gsnedders: Your hair?
# [19:12] <gsnedders> (the use of the regex that is)
# [19:12] <gsnedders> (Both of us think having a proper CSS parser would be better)
# [19:12] <Philip`> (The stuff from the top of your head, that is)
# [19:12] <ezyang> There is one more thing that HTML Purifier does, and that's enhance HTML.
# [19:12] <gsnedders> Philip`: No, my hair doesn't include interesting information.
# [19:12] <gsnedders> ezyang: "enhance"?
# [19:12] <ezyang> Take something that normally didn't have meaning and transform it accordingly
# [19:12] <ezyang> For example, turning plaintext URLs into links
# [19:12] <jgraham> ?
# [19:12] <jgraham> Oh
# [19:13] <jgraham> Well that sounds like an OK function is your users want it
# [19:13] <ezyang> Or adding paragraphing
# [19:13] <gsnedders> ezyang: Can you just stick with purifying? :P
# [19:13] <ezyang> I mean, you kind of /need/ these features if you're going to be writing HTML raw.
# [19:13] <ezyang> Anyway, performing this transforms when you have a tree is much better.
# [19:14] <ezyang> *these
# [19:14] <gsnedders> I'd rather have a tool that just made sure HTML was secure.
# [19:14] <gsnedders> s/tool/library/
# [19:14] <ezyang> So you want decoupling. Well, you easily turn it off :-P
# [19:15] <jgraham> Philip`: Any idea how hard it is to write a CSS parser?
# [19:15] * gsnedders thinks the issue of what HTML Purifier should do is simpler if we take one thing it aims to do at a time
# [19:15] <takkaria> jgraham: talk to jmb, he's just written one...
# [19:16] <ezyang> It's a lot of drudge work.
# [19:16] <jmb> takkaria: heh
# [19:16] <gsnedders> ezyang: how do you parse it/
# [19:16] <gsnedders> *?
# [19:16] <Philip`> jgraham: I haven't got a clue
# [19:16] <gsnedders> Philip`: Get a clue.
# [19:16] <ezyang> Oh, that's easy: I just split on semicolons :-P
# [19:16] <ezyang> Which is wrong, and also needs to be fixed.
# [19:17] <gsnedders> ezyang: I expect doing any nice parser will be rather horrible in PHP
# [19:17] <ezyang> CSS Tidy does it.
# [19:17] <gsnedders> Mainly because there is no nice lexer to just easily use :P
# [19:17] <ezyang> I just need to subsume it into HTML Purifier.
# [19:17] <jgraham> jmb: Any idea how hard it is to write a CSS parser?
# [19:18] * Quits: dave_levin_ (n=dave_lev@72.14.227.1)
# [19:18] <ezyang> You can cut some corners, since style="" is much simpler than <style></style>
# [19:18] <Philip`> I tried using a Python CSS parser once, but it seemed to have something like quadratic time complexity and so it was unusable for typical large inputs
# [19:18] <jmb> jgraham: if one existed in a useful form before I wrote mine, I wouldn't have bothered
# [19:18] <jmb> jgraham: this one's taken me about a year of spare time fwiw
# [19:19] <jgraham> :(
# [19:19] <ezyang> I would also argue that you need to whitelist the values of CSS properties, since you don't want to enumerate against browser proprietary extensions
# [19:19] <jmb> you may have more spare time than me, though :)
# [19:20] * gsnedders wonders how there manages to be no decent parsing libraries for PHP
# [19:20] <jgraham> jmb: Wouldn't count on it
# [19:20] <jmb> jgraham: http://www.netsurf-browser.org/projects/libcss/
# [19:20] <jmb> fwiw
# [19:23] * aroben|lunch is now known as aroben
# [19:24] <ezyang> I still wonder if, one day, a browser will add support for a specific combination of tags that results in JavaScript being executed.
# [19:24] * Joins: arun__ (n=arun@adsl-75-36-190-133.dsl.pltn13.sbcglobal.net)
# [19:24] <ezyang> and in separate contexts it's ok.
# [19:25] * Joins: maikmerten (n=maikmert@BAE20da.bae.pppool.de)
# [19:27] <ezyang> Seems very unlikely.
# [19:28] <ezyang> Ok, so here's what's going to happen. HTML Purifier 5.0 will be able to operate as "make it valid omgwtf" and "make it secure"
# [19:29] <ezyang> For interest of backwards compatibility, "make it valid omgwtf" will be the default. Conscientous developers who don't care about validity can turn that off.
# [19:29] <gsnedders> And then have the fun of evangelism to dissuade people from using the former.
# [19:29] <ezyang> I mean, validators really did a lot of harm to conformance.
# [19:29] <gsnedders> ezyang: In the longer term <iframe sandbox seamless> should work
# [19:30] <ezyang> So long as there are legacy browsers, that will not be sufficient.
# [19:30] * ezyang afk for lunch
# [19:30] <ezyang> This was a good discussion, and definitely changed my mind about where HTML Purifier 5.0 is going.
# [19:34] * Joins: jwalden (n=waldo@nat/mozilla/x-2ddbc2430f1eb0e4)
# [19:34] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) ("Wünsche weiterhin guten Flug")
# [19:39] <gsnedders> ezyang: I'll probably send an email later
# [19:39] <gsnedders> (Like, when I get home from work)
# [19:42] * Joins: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
# [19:43] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
# [19:44] * Joins: sbublava (n=stephan@77.117.11.54.wireless.dyn.drei.com)
# [19:48] * aboodman2 is now known as aboodman
# [19:49] <ezyang> Email?
# [19:56] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
# [20:04] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
# [20:04] * Quits: pmuellr (n=pmuellr@nat/ibm/x-5fcaa3aa698b5250)
# [20:06] * Joins: dglazkov_ (n=dglazkov@nat/google/x-29e6d2ed0997c27e)
# [20:07] * Quits: dglazkov_ (n=dglazkov@nat/google/x-29e6d2ed0997c27e) (Client Quit)
# [20:08] * Quits: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
# [20:10] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-6a7ef9ccf1ff5494) (Read error: 104 (Connection reset by peer))
# [20:10] * Joins: pmuellr (n=pmuellr@nat/ibm/x-953a6346adf9cf65)
# [20:12] * Quits: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
# [20:14] * Quits: jacobolus (n=jacobolu@adsl-75-36-158-29.dsl.pltn13.sbcglobal.net) (Remote closed the connection)
# [20:17] * Quits: dbaron (n=dbaron@nat/mozilla/x-de7f3e627e31161f) ("8403864 bytes have been tenured, next gc will be global.")
# [20:19] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-c6f32d714bfc6d1b)
# [20:20] * Joins: ojan (n=ojan@72.14.229.81)
# [20:20] * Quits: dglazkov (n=dglazkov@nat/google/x-6a932a9011b44ea7) (Read error: 110 (Connection timed out))
# [20:22] * Joins: archtech (n=stanv@83.228.56.37)
# [20:24] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
# [20:25] <JoePeck> Hello. Is there any way to access the current page's response headers via Javascript, like you can access an AJAX Requests response headers (with xhr.getAllResponseHeaders etc). And if not, why not or was it just not thought of?
# [20:27] <JoePeck> Since you can just spawn an AJAX request for the current page, and get the headers that way, I think it should be allowable for Javascript to have access to the response headers of the current page. At least I can't think of a realistic security concern.
# [20:34] * Quits: mat_t (n=mattomas@nat/canonical/x-eb63950733a08e81) ("This computer has gone to sleep")
# [20:37] * Joins: dolske (n=dolske@nat/mozilla/x-5b54ad994211b6ff)
# [20:37] * Joins: gsnedders_ (n=gsnedder@c83-252-199-225.bredband.comhem.se)
# [20:38] * Joins: mat_t (n=mattomas@nat/canonical/x-76bd221a517d8385)
# [20:43] <sebmarkbage> JoePeck: As far as I know you can't and I agree. It is an oversight.
# [20:44] <JoePeck> Hmm, should I make a formal email to the mailing list?
# [20:47] <mookid> no
# [20:47] <mookid> the response is the response
# [20:48] <sebmarkbage> Scripts should be able to resolve things such as relative URIs if the HTTP header "Content-Base" is used. We shouldn't have to use meta or base tags for that.
# [20:48] <JoePeck> mookid: but the headers aren't available to Javascript?
# [20:48] <mookid> the client side doesn't, and shouldn't, be able to modify the response - it just is what it is
# [20:48] <gsnedders_> ezyang: Yes, email. You know these things?
# [20:48] <JoePeck> mookid: not modify, access. What about custom headers?
# [20:48] * Quits: mat_t (n=mattomas@nat/canonical/x-76bd221a517d8385) ("This computer has gone to sleep")
# [20:49] <JoePeck> not that it would make any sense to modify the response headers... they are the response headers =)
# [20:51] <sebmarkbage> Out of curiousity, what headers would you like to access? Custom only?
# [20:52] <JoePeck> sebmarkbage: actually, someone in ##javascript wanted to access the "Date" header sent from his server
# [20:52] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [20:52] <JoePeck> but I could think of accessing the Content-Type and custom headers
# [20:52] <JoePeck> as possible use cases
# [20:52] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) ("ChatZilla 0.9.85 [Firefox 3.6a1pre/20090709035810]")
# [20:52] <mookid> wait - what
# [20:53] <JoePeck> mookid: it seems I have a difficult time explaining this because everyone seems to respond with a "what?" =(
# [20:53] * Joins: mstange (n=markus@buntes215.wohnheim.uni-kl.de)
# [20:53] <mookid> you can't read response headers?
# [20:53] <JoePeck> Here was my example page: http://bogojoker.com/x/xhr/headers.html
# [20:54] <JoePeck> you can read the response headers, but only for an AJAX Request
# [20:54] <sebmarkbage> You can read response headers off of XHR but not for the current document.
# [20:54] <JoePeck> exactly
# [20:54] <sebmarkbage> I.e. you'd have to make another request to find that out.
# [20:54] <JoePeck> sebmarkbage++ thanks =)
# [20:55] <mookid> yeah well that's a good example of what a ridiculously poor HTTP client most browsers are
# [20:55] <mookid> you'll get the "we need a use case" nonsense
# [20:56] <takkaria> ...
# [20:56] <mookid> the reality is that they didn't read the RFC properly
# [20:56] <JoePeck> well, why get the response headers from an ajax request? If there was a use case for that then they all apply for this case as well
# [20:56] <takkaria> you can be a perfectly good HTTP client without exposing request headers to JavaScript
# [20:57] <mookid> browsers are crap HTTP clients
# [20:57] <JoePeck> I agree with takkaria on that
# [20:57] <JoePeck> mookid: and what would you suggest as a good HTTP client?
# [20:57] <takkaria> that may or may not be true, but it's irrevelant to exposing things to JS
# [20:57] <mookid> one that behaves as though the developers read the HTTP RFC
# [20:58] <JoePeck> hmm the "and" makes that statement sound stuck up, I don't mean that, I'm just curious
# [20:58] <mookid> take a look at the Accept header for most browsers
# [20:58] <mookid> go read the RFC
# [20:58] <mookid> and try and work out what these people were thinking
# [20:58] <mookid> if anything at all
# [20:58] <mookid> probably too busy doing crack and beating their wives
# [20:59] <JoePeck> oookay
# [20:59] <mookid> but hey
# [20:59] <mookid> there's no use case for appropriate Accept headers
# [21:00] <mookid> what about HTML5 providing a mechanism for protocol level content negotiation?
# [21:00] <mookid> nope - no use case
# [21:00] <mookid> we've got URIs!
# [21:00] <mookid> idiotic.
# [21:00] <mookid> completely and utterly idiotic.
# [21:00] <mookid> #
# [21:01] <mookid> it's a wonder why anyone actually bothers writing RFCs
# [21:01] <takkaria> mookid: watch out, you'll start to rail against the evils of the capitalist press next
# [21:01] <mookid> yeah be as aloof as you want
# [21:02] <mookid> your technology is a joke.
# [21:03] <mookid> but hey - at least we've got snazzy videos moving around the page that rotate and shit!
# [21:03] <mookid> awwwwweeesssommmme
# [21:03] <takkaria> my technology? I'm not sure I've produced any technology I could lay claim to. :)
# [21:03] <sebmarkbage> I'm sorry, you lost me at crack. The use case of being able to read headers is that it allows for a cleaner model as opposed to for example meta tags. Meta data that belongs in HTTP could then stay there.
# [21:04] <mookid> I'm all for self descriptive messages
# [21:04] <mookid> that's probably why you lost me
# [21:05] * cying is now known as cyingLunch
# [21:05] <mookid> I'm in favour of keeping that stuff in the message headers
# [21:05] <mookid> good luck convincing these guys that HTTP is relevant to their 'ground breaking' work
# [21:05] <mookid> unless there's a use case for it
# [21:07] <mookid> a use case for them to listen to you i mean
# [21:07] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [21:08] * Joins: ZombieL (n=e@c80-217-237-176.bredband.comhem.se)
# [21:08] <gsnedders_> mookid: What's inappropriate about the Accept headers browsers send? (And I'm totally serious about asking that, I know what the spec says, and it seems perfectly sane to me.)
# [21:09] <mookid> well
# [21:09] <mookid> someone wrote a post about this recently
# [21:09] <mookid> http://newmediacampaigns.com/page/browser-rest-http-accept-headers
# [21:10] <mookid> what is so hard about changing it to Accept: text/html,*/*;q=0.9
# [21:10] * Quits: ZombieL (n=e@c80-217-237-176.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
# [21:10] <mookid> oh wait sorry I forgot
# [21:10] <mookid> there's no use case
# [21:11] <gsnedders_> mookid: Because then people will complain that they don't claim to support application/xhtml+xml just as well as it does text/html
# [21:12] * Joins: ZombieL (n=e@c80-217-237-176.bredband.comhem.se)
# [21:12] <mookid> why don't you read that post
# [21:12] <gsnedders_> I am reading it.
# [21:12] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe) (Success)
# [21:12] * Quits: ZombieL (n=e@c80-217-237-176.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
# [21:12] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
# [21:14] <gsnedders_> IE's seems sane insofar as it lists what it supports, but all equally, which is a bit odd. I would expect it to prefer text/html. WebKit's is odd seeming that image/png is there (I do also wonder why application/xml is equal to application/xhtml+xml and above text/html, but providing a generic XML MIME type along side application/xhtml+xml doesn't seem entirely crazy). Firefox seems the sanest, though.
# [21:14] * gsnedders_ wonders what we send
# [21:14] <mookid> we = firefox?
# [21:14] <gsnedders_> we = Opera
# [21:14] <mookid> oh right
# [21:14] <mookid> oh you're probably sane =)
# [21:14] <gsnedders_> (As we are only mentioned in passing as being sane)
# [21:14] <gsnedders_> text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
# [21:14] * ZombieLoffe is now known as ZombieL
# [21:15] <mookid> eww
# [21:15] <gsnedders_> That doens't seem quite so sane.
# [21:15] <gsnedders_> *doesn't
# [21:15] <gsnedders_> If anything, that's the least sane.
# [21:15] <mookid> well this is academic anyway since there's no need for HTTP content negotiation because "you can put it in the URI"
# [21:15] <mookid> apparently.
# [21:15] <mookid> =/
# [21:16] <ezyang> I think Accept headers make most sense for embedded resources
# [21:17] <mookid> well they make no sense in practical web app terms
# [21:17] <mookid> because you can't specify them in context to a browser in HTML
# [21:17] <ezyang> Yes you can. <img />
# [21:17] <JoePeck> mookid: so if a person asks for blah.html and their Accept header states they would want xml over html you should respect the Accept header and give them xml?
# [21:17] <mookid> ok ok
# [21:17] <mookid> let me just say something
# [21:17] <Philip`> Ooh, this discussion again
# [21:17] <ezyang> JoePeck: No, since you explicitly specified what content type you want with .html
# [21:18] <krijnh> Is it known that IE throws almost the entire DOM inside the head in this case: http://krijnhoetmer.nl/zooi/html5/gone-in-ie.html ?
# [21:18] <gsnedders_> ezyang: File names are meaningless.
# [21:18] <mookid> say I have something called /resource - and I have 2 representations of that resource in json and xml; but they are the SAME resource
# [21:18] <JoePeck> ezyang: thats what I thought, so most of this doesn't seem crazy to me. =)
# [21:18] <gsnedders_> ezyang: If you have both representations of the resource, you should give them XML.
# [21:18] <mookid> I don't want /resource.xml and /resource.json because those URIs are 2 separate resources
# [21:18] <ezyang> gsnedders_: How so? If you want to turn on Multiviews, you better damn well be serving files w/o extensions
# [21:18] <mookid> URIs are *opaque*
# [21:18] <mookid> which is extremely important
# [21:19] * Joins: ap_ (n=ap@17.246.19.81)
# [21:19] <gsnedders_> ezyang: Well, I mean extensions are.
# [21:19] <JoePeck> "those URIs are 2 separate resources" those 2 URIs don't need to exist, they just need to be parsed.
# [21:19] <mookid> the fact that we've been forced into using the URI for this is irrelevant it's bad practice if the two document types are representations of the same resource
# [21:19] <gsnedders_> mookid: When does it become important, though?
# [21:19] <mookid> good god.
# [21:19] <ezyang> mookid: I agree. But there still needs to be a mechanism for explicitly specifying the desired content type
# [21:19] <mookid> caching./
# [21:20] <mookid> caching caching caching
# [21:20] <JoePeck> mookid: its much easier to work with something you can modify easily, like the URI, then the header which goes along
# [21:20] <mookid> JoePeck: no it's not
# [21:20] <gsnedders_> mookid: But you need to vary caching based upon the Accept header then, which means you gain nothing by having the same URI for both.
# [21:20] <JoePeck> would you suggest changing browsers to have 2 textfields, one for the URI and one for the preferred accepted mimetype?
# [21:20] <mookid> ezyang: the best way to do that is an accept attribute in hypermedia tags
# [21:21] * inimino makes popcorn
# [21:21] <JoePeck> lol =)
# [21:21] <mookid> so <a accept="application/json" href="/resource">
# [21:21] <gsnedders_> mookid: But why do you want to override the browser default?
# [21:21] <ezyang> ==gsnedders_
# [21:21] <mookid> because it depends on the context
# [21:21] <ezyang> Then the resources are not identical.
# [21:21] <gsnedders_> ezyang: That doesn't follow.
# [21:21] <JoePeck> I like mookid's accept attribute
# [21:21] <mookid> WHATWG don't
# [21:22] <JoePeck> but still
# [21:22] <mookid> there's not a good enough use case
# [21:22] <JoePeck> if you want to get something by typing a URI into your big honking location bar
# [21:22] <JoePeck> what would you suggest then?
# [21:22] <gsnedders_> mookid: You need a more specific use case.
# [21:22] <mookid> I'd suggest if you're putting a URI into a browser you want HTML
# [21:22] <mookid> :)
# [21:22] <JoePeck> if not embedding the mime type into the URI (like .xml or .json) you're going to need 2 peices
# [21:22] <mookid> but say..
# [21:22] <mookid> I fancy pdf
# [21:23] <gsnedders_> mookid: Just, "it depends on context" isn't very specific.
# [21:23] <JoePeck> ahh, I don't like that =(
# [21:23] <mookid> you don't like that if the resources are differnet
# [21:23] <mookid> if the resources are different they need different URIs
# [21:23] <mookid> if they are the same they need the same URI
# [21:23] <JoePeck> gsnedders_: seems decent enough. If your application wants to to force the browser to interpret things in a certain way then you should be allowed to?
# [21:23] <gsnedders_> mookid: Something like, "I want to make available a PDF representation of the document", is a lot more precise
# [21:24] <mookid> gsnedders_: I gave you an example
# [21:24] <gsnedders_> mookid: Where?
# [21:24] <mookid> I have an application that has /resource I want to link to
# [21:24] <gsnedders_> mookid: But why do you want to override the Accept header?
# [21:24] <mookid> and on another HTML5 page I want to link to both the json and xml
# [21:24] <mookid> I CANT DO THAT
# [21:24] <mookid> WITHOUT AN ACCEPT ATTRIBUTE
# [21:24] <JoePeck> whoa. calm down
# [21:24] <gsnedders_> Why do you want to link to both?
# [21:24] <inimino> mookid: then you have two resources, get over it
# [21:25] <gsnedders_> To give a use-case, you need to answer that.
# [21:25] <mookid> because I want to give my clients a hyperlink to both states
# [21:25] <gsnedders_> Why?
# [21:25] <ezyang> This is what I was trying to say previously.
# [21:25] <mookid> why? because I do
# [21:25] <mookid> that's irrelevant
# [21:25] <gsnedders_> That's not a reason.
# [21:25] <gsnedders_> Yes it is.
# [21:25] <mookid> oh for fucks sake
# [21:25] <JoePeck> I actually think it is a good reason =/
# [21:25] <gsnedders_> Should we add everything that anyone asks for, "because they do"?
# [21:25] <JoePeck> I just can't come up with a good example of using it
# [21:26] <jgraham> This discussion was quite boring the first time you know
# [21:26] * Joins: dbaron (n=dbaron@nat/mozilla/x-f7651b8e29af1e3c)
# [21:26] <mookid> yeah
# [21:26] <ezyang> So, let's suppose the HTML and PDF example
# [21:26] <mookid> ^
# [21:26] <jgraham> This is like the lame sequel
# [21:26] <JoePeck> hahaha
# [21:26] <ezyang> I publish an HTML document with the intent of this being shown to people who are just browsing on the web.
# [21:26] <takkaria> ah, I thought it might go this way
# [21:26] <mookid> yeah well there's a good reason for that
# [21:26] <takkaria> I was hoping that mookid would just have continued spewing vitriol for a while
# [21:26] <mookid> it's important
# [21:26] <ezyang> And then the PDF document because it has better typogrpahy or can be sent to people or something
# [21:27] <gsnedders_> ezyang: Why not just use link@rel=alternate that works in existing, already deployed, UAs?
# [21:27] <JoePeck> ezyang: that sounded good to me
# [21:27] <ezyang> That's one solution.
# [21:27] <mookid> did you just suggest putting it in the URI?
# [21:27] * JohnResi1 is now known as JohnResig
# [21:27] <ezyang> gsnedders_ did not suggest puttin git in the URI
# [21:28] <JoePeck> he suggested changing the element alltogether? instead of <a> use <link> ?
# [21:28] <takkaria> let me suggest it
# [21:28] * Joins: atwilson (n=atwilson@74.125.59.1)
# [21:28] <jgraham> In practice the one-uri-maps-to-many-representions thing doesn't match how people think about this stuff
# [21:28] <JoePeck> isn't that semantically unacceptable (pardon the pun)?
# [21:28] <gsnedders_> ezyang: It does have that implication, actually
# [21:28] <takkaria> you should just call it document.html and document.pdf
# [21:28] <mookid> takkaria: then you don't understand the HTTP or URI spec and don't belong in this discussion
# [21:28] <JoePeck> takkaria: "could" not should
# [21:28] <jgraham> No one tries opening a URI that works in their web browser in their PDF viewer and expects to get a PDF back
# [21:28] <takkaria> mostly because it just works, and in this world-wide web of indifference, something that just works is pretty good
# [21:29] <ezyang> Now, my interpretation of the matter is that PDF has a distinct identity from the HTML document.
# [21:29] <JoePeck> mookid: I don't understand the harshness...
# [21:29] <mookid> because of the shit I went through last time
# [21:29] <mookid> and blatant ignorance
# [21:29] <ezyang> So, a more appropriate URI for it would be foo?publishable
# [21:29] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-c6f32d714bfc6d1b) (Read error: 104 (Connection reset by peer))
# [21:29] <ezyang> To carry the semantic meaning of this other resource.
# [21:30] <ezyang> And like it or not, "pdf" very concisely expresses the semantics you expect.
# [21:30] * Quits: gunderwonder (n=gunderwo@166.80-202-84.nextgentel.com)
# [21:30] <jgraham> JoePeck: mookid is somewhat bitter because he spent something like two days ranting about this before and people refused to accept that they were ignorant heathens
# [21:30] <JoePeck> lol, okay thanks for the context
# [21:30] <JoePeck> I see what he wants
# [21:30] <ezyang> A more reasonable use-case for negotiation is .jpg and .png, where joe user sees no difference between them.
# [21:30] <jgraham> and he was the only one who understood the web architecture
# [21:30] * Quits: cyingLunch (n=cying@70.90.171.153)
# [21:30] <JoePeck> but ultimately, I just see putting it the URI as much easier
# [21:30] <mookid> the main gain for sticking to single URIs for multiple representations of the same resource is the cache invalidation you get across all representations of a resource when you modify the resource
# [21:30] <Dashiva> Who started the time machine in here?
# [21:30] * Quits: archtech (n=stanv@83.228.56.37)
# [21:31] <mookid> I'm not the only one
# [21:31] <mookid> Philip` got it
# [21:31] <JoePeck> mookid: is there no way in HTTP
# [21:31] <mookid> it's pointless anyway there's HTTP functionality you are denying developpers on the basis that "you don't think it's really necessary"
# [21:31] <JoePeck> to make two URIs equivalent?
# [21:32] <mookid> no
# [21:32] * JoePeck puts up shield
# [21:32] <mookid> URIs are opaque
# [21:32] <mookid> good question :)
# [21:32] <jgraham> mookid: I get the idea. I get the fact that some people think it would be nice if things worked that way. I think it is impractical in reality
# [21:32] <mookid> what?!
# [21:32] <gsnedders_> mookid: Should we allow every single HTTP header to be set by the page?
# [21:32] <mookid> actually I dont think that's a bad idea
# [21:32] <Philip`> I don't entirely remember whether I got it
# [21:32] <Philip`> or what it even was
# [21:32] <JoePeck> so this could be solved in HTTP by making two URIs have an equivalent HTTP cache uri?
# [21:32] <Philip`> and whatever it was, I guess I didn't keep it
# [21:33] <mookid> JoePeck: that means you have to couple your caching mechanisms to your application
# [21:33] <mookid> it's inefficient and brittle
# [21:33] <JoePeck> no the HTTP client
# [21:33] <mookid> yeah again
# [21:33] <Dashiva> Philip`: Did you get it now, or the last time mookid was here?
# [21:33] <mookid> you can do that but it's coupling to your application
# [21:34] * gsnedders_ gets the idea, gets why people want multiple representations of a single URI, but thinks some things (like changing content-type) are impractical in the real world
# [21:34] <mookid> that's not your choice.
# [21:34] <mookid> just support the protocol
# [21:34] <JoePeck> mookid: is it? if you have /resource.html and /resource.pdf can you return and say these are both "/resource" and thus invalidate the cache when one changes
# [21:34] <Philip`> Dashiva: The last time
# [21:34] <gsnedders_> mookid: What should @accept do on protocols apart from HTTP?
# [21:34] <Philip`> Dashiva: I haven't bothered reading the conversation this time, since it seems exactly the same as before
# [21:36] <mookid> erm
# [21:36] <gsnedders_> mookid: Also, what else in HTML is specific to HTTP?
# [21:36] <mookid> what?
# [21:36] <mookid> POST?
# [21:36] * jgraham has no idea where the http protocol mandates that HTML pages should be able to change the browser headers via the DOM
# [21:36] <gsnedders_> mookid: HTML isn't tied to HTTP, by and large. form@method I guess is, but otherwise not
# [21:36] <mookid> jgraham: yeah bad luck it's not spelled out for you
# [21:36] <mookid> probably a bit much.
# [21:36] * Quits: ap (n=ap@nat/apple/x-d51eab098a917e7f) (Read error: 110 (Connection timed out))
# [21:36] <mookid> wouldn't worry about it too much
# [21:36] <Philip`> Dashiva: Also I'm distracted by watching pretty graphs and hoping Slashdot doesn't hurt my server
# [21:36] * takkaria puts up a Don't Feed The Troll sign (scare quotes implied) and goes to make risotto
# [21:36] <JoePeck> mookid: what about what I said before
# [21:36] * gsnedders_ goes to get washing
# [21:36] <jgraham> takkaria: What type of risotto?
# [21:36] <takkaria> jgraham: just a mushroom and pepper one, nothing fancy
# [21:36] <mookid> JoePeck: there's nothing stopping you introducing that kind of logic into your client or caches
# [21:36] <JoePeck> as it exists right now is that possible? Or does that mean the browser can only cache 1 representation of /resource at a time?
# [21:36] <mookid> but that's the opposite philosophy underlying HTTP
# [21:36] * jgraham is just enjoying a break from packing
# [21:37] <mookid> URIs are meant to be *opaque* which means that if they aren't the same - they aren't the same
# [21:37] <Dashiva> Have you covered the "multiple representations of the same URL confuses users" angle yet?
# [21:37] <mookid> nothing more complicated
# [21:37] <JoePeck> mookid: okay, I don't see what you mean this time. I've gotten all the REST (hahaha, my puns...)
# [21:37] <mookid> Dashiva: that is utterly irrelevant but thanks a bunch
# [21:37] <jgraham> Dashiva: Did that one
# [21:37] <JoePeck> hmm okay
# [21:37] <Dashiva> jgraham: Was it dismissed out of hand like last time?
# [21:37] <mookid> it's irrelevant
# [21:38] <mookid> it's not your descision
# [21:38] <JoePeck> I would say developers are not users =)
# [21:38] <JoePeck> we have to deal with this crap because we made it that way =)
# [21:38] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-b76fa1328c806a7f)
# [21:38] <JoePeck> if we can't make it usable to our users it was our own fault
# [21:38] <jgraham> Philip`: You are on slashdot?
# [21:38] * Joins: billmason (n=billmaso@ip94.unival.com)
# [21:39] <Dashiva> JoePeck: Regular users deal with URLs, though. They should be able to do so without having to learn about http black magic
# [21:39] <mookid> Dashiva: you don't know what you're tlaking about and even if you did it's not your place to decide for the world how that's dgoing to work
# [21:39] <JoePeck> well, lets say you put a URL into your browsers address bar
# [21:39] <JoePeck> and get back a popup saying
# [21:39] <Philip`> jgraham: Yes
# [21:39] <JoePeck> "Would you like this in HTML, PDF, or XML"
# [21:39] <mookid> haha
# [21:39] <jgraham> Philip`: Where?
# [21:40] <Philip`> jgraham: hence the worrying about it
# [21:40] <Philip`> jgraham: http://slashdot.org/
# [21:40] <jgraham> Philip`: I was hoping for something more specific
# [21:40] <Philip`> jgraham: http://games.slashdot.org/article.pl?sid=09/07/15/170217
# [21:41] <mookid> JoePeck: so yep there you go - we don't need an accept attribute because we can "just put it in the URI"
# [21:41] <JoePeck> mookid: well, I understand what you're going for. And actually I do agree with you. But I think too few people care about getting it right when you can just take the easy way out
# [21:41] <mookid> yup pretty much it
# [21:41] <mookid> just ignorance basically
# [21:41] <JoePeck> who cares if your cache has a .html and .pdf representation out of date
# [21:41] <JoePeck> is what it boils down to, for me
# [21:42] <JoePeck> mookid: cheers on sticking up for yourself though =)
# [21:42] <jgraham> Philip`: The game looks nice
# [21:42] <Dashiva> Between a few developers and all the users, the users get priority. That's just how it is.
# [21:43] <mookid> it's got nothing to do with that
# [21:43] <mookid> you're not a fucking gatekeeper
# [21:44] <mookid> excuse my language
# [21:44] <mookid> but that is the *most* pathetic response
# [21:44] <mookid> out of the lot
# [21:44] <JoePeck> Dashiva: how many users use FTP even though they don't know how its done under the hood. How many people know DNS is complicated yet it just works. Speaking of "it just works" Apple does magic with DNS to get Bonjour working and the User never knows. I think usability always has a solution (my 2¢)
# [21:44] <Dashiva> JoePeck: Usability is why we use URLs instead of contenet negotiation
# [21:44] <mookid> jesus
# [21:44] <Philip`> jgraham: It's quite a long way from being a decently playable game, though :-(
# [21:45] <JoePeck> Well, I'm going to stop here
# [21:45] <mookid> :)
# [21:45] <JoePeck> I could argue though =)
# [21:45] <mookid> now you might understand why I approach it the way I do
# [21:45] <Dashiva> Yeah, trolling always works. Keep it up.
# [21:45] <JoePeck> well, sorry, but I don't think yelling would ever open up someone elses mind like this debate would
# [21:46] <mookid> Dashiva: you're form of trolling is far more irritating
# [21:46] <JoePeck> need to have happen in order for the other side to get the "aha" moment
# [21:46] <Dashiva> mookid: Maybe one day you will sit down and consider the possibility that you might just be wrong. Just maybe.
# [21:46] <mookid> well I'm not
# [21:47] <JoePeck> ultimately I think you're right. They haven't given you a good reason that you aren't (cause you aren't)
# [21:47] <mookid> and I'm betting I've given this more though than you.
# [21:47] * Quits: ap_ (n=ap@17.246.19.81) (Remote closed the connection)
# [21:47] <mookid> since it's my proposal and everything
# [21:47] * Joins: ap (n=ap@nat/apple/x-bf676c7c165a7b6e)
# [21:47] <mookid> + you're primary reason for resistance (i.e. protecting *your* poor users) is pretty silly
# [21:48] <mookid> the crazy thing about this is that it doesnt stop you carrying on using the URI
# [21:48] <JoePeck> I said I was going to stop, and I will now =)
# [21:48] <JoePeck> cheers
# [21:48] <mookid> cheers Joe
# [21:48] <mookid> :)
# [21:49] * Quits: Spark^ (n=x@94-194-199-197.zone8.bethere.co.uk)
# [21:49] <mookid> only case I can see you getting pissy about is page refresh
# [21:50] <mookid> but if each page request is a state
# [21:50] <mookid> that includes all the headers
# [21:50] <mookid> then refresh should work fine
# [21:52] <mookid> but that is really my own problem - if you don't like it and want to use browser defaults and URI conneg then you can continue to and ignore the accept attribute all together
# [21:52] <mookid> there's no reason we can't do both together
# [21:54] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-b76fa1328c806a7f) (Read error: 104 (Connection reset by peer))
# [21:54] * Joins: cying (n=cying@70.90.171.153)
# [21:55] * Quits: maikmerten (n=maikmert@BAE20da.bae.pppool.de) (Remote closed the connection)
# [21:58] * Quits: mstange (n=markus@buntes215.wohnheim.uni-kl.de) (Remote closed the connection)
# [21:58] <jgraham> mookid: As a piece of general advice, if you want to convince people of something, particularly something that they are sceptical of, being pissy doesn't help.
# [21:59] <jgraham> In fact quite the opposite
# [21:59] <mookid> yeah need a ciggy :)
# [21:59] * jgraham is aware he isn't saintly
# [22:00] <mookid> well sorry for being a nob head
# [22:00] <mookid> force of habit
# [22:01] <jgraham> Philip`: You may want to updat your bio
# [22:02] <mookid> the popular HTTP-centric API for java called JAX-RS only supports HTTP conneg
# [22:02] <mookid> so it's not just me :P
# [22:02] <Philip`> jgraham: It's only about five years out of date
# [22:03] <jgraham> Philip`: It misses out > 20% of your life
# [22:03] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
# [22:03] * Quits: atwilson (n=atwilson@74.125.59.1)
# [22:04] * aroben is now known as aroben|afk
# [22:06] * Joins: othermaciej (n=mjs@17.246.17.223)
# [22:07] * Quits: othermaciej (n=mjs@17.246.17.223) (Client Quit)
# [22:08] * Joins: othermaciej (n=mjs@17.246.17.223)
# [22:12] * Joins: taf2__ (n=taf2@38.99.201.242)
# [22:15] * Philip` 's SVN server is currently doing about 30Mbit/s, which probably isn't a lot in absolute terms but it seems like quite a bit when you've scaled up from an average ~50kbit/s a few days ago
# [22:16] * Joins: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
# [22:21] <mookid> you got pr0n on a svn server?
# [22:22] <Philip`> No
# [22:22] * aroben|afk is now known as aroben
# [22:25] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-7cf530064c557c69)
# [22:28] * Joins: roc (n=roc@121.74.180.224)
# [22:29] * Quits: pmuellr (n=pmuellr@nat/ibm/x-953a6346adf9cf65)
# [22:30] * Quits: taf2_ (n=taf2@38.99.201.242) (Read error: 113 (No route to host))
# [22:31] * Joins: JoePeck (n=JoePeck@jpecoraro.rit.edu)
# [22:37] * Quits: zdobersek1 (n=zan@cpe-92-37-76-123.dynamic.amis.net) ("Leaving.")
# [22:37] * Quits: webben (n=benh@nat/yahoo/x-4621a04377acbccd) (Read error: 60 (Operation timed out))
# [22:38] * Joins: bgalbraith (n=bgalbrai@nat/mozilla/x-f7faac445a124e3c)
# [22:41] * Quits: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
# [22:42] * Joins: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
# [22:43] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
# [22:44] * Quits: sbublava (n=stephan@77.117.11.54.wireless.dyn.drei.com)
# [22:45] * Joins: weinig (n=weinig@nat/apple/x-e2b69ff700f3572b)
# [22:55] * Quits: sicking (n=chatzill@nat/mozilla/x-17a34457adae1c7a) (Remote closed the connection)
# [22:55] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
# [23:06] * Joins: olliej_ (n=oliver@17.246.19.66)
# [23:07] * Joins: arun___ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net)
# [23:08] * Quits: arun__ (n=arun@adsl-75-36-190-133.dsl.pltn13.sbcglobal.net) (Read error: 104 (Connection reset by peer))
# [23:14] * Joins: dglazkov (n=dglazkov@nat/google/x-e28711ff08354048)
# [23:14] * Quits: dglazkov (n=dglazkov@nat/google/x-e28711ff08354048) (Remote closed the connection)
# [23:17] * Joins: jorlow (n=jorlow@nat/google/x-75fce16f31f74eb7)
# [23:21] * Joins: dglazkov (n=dglazkov@nat/google/x-137b6a9d68f1fd02)
# [23:21] * Quits: dglazkov (n=dglazkov@nat/google/x-137b6a9d68f1fd02) (Remote closed the connection)
# [23:21] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
# [23:23] * aroben is now known as aroben|meeting
# [23:29] <Hixie> what is the Window Modes spec?
# [23:30] * Joins: Sirisian (n=Sirisian@ppp-69-214-10-107.dsl.klmzmi.ameritech.net)
# [23:30] <Hixie> oh, a widgets spec
# [23:30] <Hixie> ok
# [23:30] <Hixie> (http://dev.w3.org/2006/waf/widgets-wm/Overview.src.html)
# [23:36] * Quits: JoePeck (n=JoePeck@jpecoraro.rit.edu)
# [23:38] * Quits: taf2__ (n=taf2@38.99.201.242)
# [23:40] * Quits: jorlow (n=jorlow@nat/google/x-75fce16f31f74eb7)
# [23:41] * Joins: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au)
# [23:42] * Joins: tantek (n=tantek@c-98-248-34-230.hsd1.ca.comcast.net)
# [23:43] * Joins: jorlow (n=jorlow@nat/google/x-8ee6a3a24378e011)
# [23:44] * Quits: Creap (n=Creap@vemod.brg.sgsnet.se) ("nu f�kt")
# [23:45] * Quits: weinig (n=weinig@nat/apple/x-e2b69ff700f3572b)
# [23:46] * Joins: poe (n=poe@unaffiliated/xerox)
# [23:49] * Quits: othermaciej (n=mjs@17.246.17.223)
# [23:53] * Joins: othermaciej (n=mjs@17.203.15.242)
# [23:55] * Quits: jorlow (n=jorlow@nat/google/x-8ee6a3a24378e011) (Remote closed the connection)
# [23:55] * Joins: jorlow (n=jorlow@nat/google/x-378e51d576ed46b1)
# [23:56] * Joins: weinig (n=weinig@nat/apple/x-942b7011fa11b8da)
# [23:59] * Quits: olliej_ (n=oliver@17.246.19.66)
# [23:59] * Quits: nessy (n=nessy@124-170-249-152.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
# Session Close: Thu Jul 16 00:00:00 2009

The end :)