| 00:01 | <Hixie> | othermaciej: should i just go ahead and do it? (i dunno if it's too late to be adding entire untested APIs...) |
| 00:02 | <othermaciej> | Hixie: probably should get more opinions than mine, if you think it might be worth doing |
| 00:02 | <Hixie> | well it's gonna happen eventually anyway, i was just wondering from an htmlwg perspective |
| 00:02 | <othermaciej> | on the one hand, it is late in the game, on the other hand, there is an opportunity to both improve accessibility and improve the API at the same time, so that's cool |
| 00:03 | <AryehGregor> | I haven't tried drag-and-drop support, but by all accounts (particular ppk's) it's horrifyingly terrible. |
| 00:04 | <TabAtkins> | Hixie: Something like - <p draggable ondragstart="function(e) { e.dataTransfer("datatype", "my data") }">foo</p><div dropzone="datatype">Drop stuff here</div> |
| 00:04 | <TabAtkins> | Hixie: And, since the page noticed a @dropzone with "datatype", whenever something is being dragged with that datatype, it *only* fires events at the elements with @dropzone="datatype". |
| 00:04 | <TabAtkins> | @dropzone would accept a space-separated list. |
| 00:05 | <Hixie> | TabAtkins: i don't understand why we'd only fire events at the declared dropzones that support that type, but i guess that depends on which events you mean |
| 00:06 | <TabAtkins> | Actually, now that I read dnd some more, i see that you can just ignore the events on things that aren't dropzones. You have to cancel them for the dropzones. |
| 00:06 | <Hixie> | TabAtkins: space-separated list of what? How do you distinguish a binary file of type application/x-foo and a text string of type application/x-foo? |
| 00:06 | <TabAtkins> | So, never mind. |
| 00:06 | <Hixie> | k |
| 00:06 | <Hixie> | i agree with the approach you're describing, i just don't know what the attribute's vlaue should be |
| 00:06 | <Hixie> | that's where i got stuck |
| 00:06 | <Hixie> | if we can revamp the API at the same time, that makes life easier |
| 00:07 | <Hixie> | cos we can just map the new API to the new values |
| 00:07 | <Hixie> | e.g. File/Blob-only values can be prefixed with an @ |
| 00:07 | <Hixie> | or some such |
| 00:17 | <TabAtkins> | Hixie: So, what exactly is the "easier" we're looking for here? Less events? Some declarative broadcasting to the user? What kind? |
| 00:29 | <TabAtkins> | Hixie: So, I'm thinking my idea was sorta sound, though not with the effect I stated. |
| 00:29 | <TabAtkins> | The current drag model is unintuitive, but isn't as bad as I thought in terms of having to deal with stuff (I had thought you had to cancel the events on everything that *wasn't* a drop target). |
| 00:32 | <TabAtkins> | So, have @dropzone be an attribute on drop targets. It takes a space-separated list of datatypes (the DataTransfer.types things). Whenever you start a drag, any elements with a @dropzone naming a datatype in the dataTransfer's type list gets a pseudoclass. |
| 00:32 | <TabAtkins> | Maybe other stuff? |
| 00:32 | <TabAtkins> | Anyway, that makes, for example, highlighting drop zones trivial. |
| 00:33 | <TabAtkins> | You could also then query the DOM for the valid dropzones, and expose them via accessibility apis. |
| 00:33 | <TabAtkins> | Which I think answers at least one of the requests in the bug. |
| 00:40 | <AryehGregor> | gsnedders, did you get my new crash report now? |
| 00:43 | <AryehGregor> | I don't really get why Shelley seems to want to ax such large swathes of the spec. She seems to want to just remove as much stuff as possible on principle. |
| 00:45 | <TabAtkins> | ...yes? |
| 00:46 | <TabAtkins> | If you can reverse time such that HTML5 becomes HTML4, maybe you can revive XHTML2 as well. |
| 00:46 | <AryehGregor> | Was she a big XHTML2 fan? |
| 00:46 | <TabAtkins> | I don't know if she was "big" or not, but I know she loves her some XML. |
| 00:46 | <AryehGregor> | I thought pretty much everyone agrees that XHTML2 was a terrible idea. |
| 00:46 | <AryehGregor> | Barring the occasional Slashdot idiot. |
| 00:46 | <Hixie> | TabAtkins: seems reasonable, yeah. That's the conclusion I'd reached too, though I'm not sure exactly what to do with the attribute's value. |
| 00:46 | AryehGregor | shrugs |
| 00:47 | <TabAtkins> | AryehGregor: That's about right. |
| 00:47 | <variable> | Has there been any discussion on the altlink attribute for <a>? |
| 00:49 | <AryehGregor> | altlink? |
| 00:49 | <TabAtkins> | AryehGregor: I think it specifies alternative links to use if @href gives 404 or similar. |
| 00:49 | <TabAtkins> | Like a client-generated redirect. |
| 00:50 | <variable> | that one |
| 00:50 | <variable> | it might even provide a list of alternate links |
| 00:50 | <variable> | in case of slashdotting, 404, etc |
| 00:51 | <jcranmer> | /. the altlink :-) |
| 00:51 | <variable> | heh - I'm curious if there has been any discussion about it |
| 00:51 | <AryehGregor> | I've never heard of it. |
| 01:14 | AryehGregor | discovers that Larry Masinter is on the TAG |
| 01:28 | <TabAtkins> | Hixie: I wrote up my suggestion in the @dropzone bug. |
| 01:28 | <Hixie> | for the attribute value's syntax? |
| 01:28 | <TabAtkins> | Yeah. Loosely, but it's clear. |
| 01:29 | <Hixie> | thanks |
| 01:29 | <TabAtkins> | I guess to make it work, you'd need to restrict setData so that the format argument had no spaces. |
| 01:31 | <Hixie> | we can't limit the types at all, since they can come from the OS, as i understand it |
| 01:31 | <Hixie> | re the pseudos, that's something we should do in the CSSWG |
| 01:31 | <TabAtkins> | Do they have spaces in them when they come from the OS? |
| 01:31 | <TabAtkins> | Yeah, CSSWG should define the pseudo in UI. |
| 01:32 | <Hixie> | hyatt and i talked about it years ago and figured we'd need three pseudos, :drop-target, ::drop-target-before, and ::drop-target-after, which would match respectively the current target, and anonymous boxes before and after that element |
| 01:32 | <TabAtkins> | Um? Why aren't ::before and ::after suitable? |
| 01:32 | <Hixie> | (so that you can make the element slide out of the way and leave room to drop something in) |
| 01:32 | <Hixie> | i guess ::before or ::after could work |
| 01:33 | <Hixie> | but they're defined as being inside the element |
| 01:33 | <Hixie> | so you'd need extra <div>s |
| 01:33 | <Hixie> | in many cases |
| 01:33 | <TabAtkins> | Oh, you want something outside. Interesting. |
| 01:33 | <TabAtkins> | Unfortunate that we don't have ::outside::before. |
| 01:33 | <TabAtkins> | I'm not sure what you mean by "make the element slide out of the way". |
| 01:34 | <TabAtkins> | Like, just visually? Like when you drag a list element around and the elements slide so there's droppable space between them? |
| 01:34 | <Hixie> | presumably in your suggestion the events for the drop zone would get canceled automatically if the attribute was present? (or rather, the default action would only run if the attribute was absent or didn't specify a matching type?) |
| 01:34 | <Hixie> | TabAtkins: yes |
| 01:35 | <TabAtkins> | Hm. What information is available at the time of the dragenter to tell if you want to accept it? Just the datatype? |
| 01:35 | <Hixie> | that and any global information |
| 01:36 | <TabAtkins> | Okay. Then yeah, it should auto-cancel or equivalent. |
| 01:36 | <Hixie> | i'll look at this more closely in a bit |
| 01:36 | <TabAtkins> | Or, hm. I'd still want a way to keep it from dropping, perhaps based on global info, besides just temporarily changing the @dropzone attribute. |
| 01:36 | <Hixie> | gotta go right now |
| 01:37 | <Hixie> | yeah dunno how to do that |
| 01:37 | <Hixie> | that was the other problem i ran into |
| 01:37 | <Hixie> | bbiab |
| 01:45 | <AryehGregor> | I'm glad to see that a large chunk of the upmodded comments on the latest Slashdot HTML5 discussion are either me or BZ. Maybe there's some hope of educating the masses after all. |
| 01:45 | <TabAtkins> | Hixie: Why do you need to distinguish between text and file types? |
| 03:41 | <Hixie> | TabAtkins: they use entirely different APIs to get them out |
| 04:11 | <Hixie> | you have to love how the TAG's e-mail on ISSUE-41 cites exactly zero technical arguments |
| 04:11 | <Hixie> | (and thus by definition will just be ignored by the chairs) |
| 04:59 | <TabAtkins_> | Hrm. Someone wanna help me with EventSource in Chrome? |
| 05:00 | <TabAtkins_> | I'm using this code: http://www.xanthir.com/test.txt |
| 05:00 | <TabAtkins_> | But when I load the page, I get a "Failed to load resource" error. |
| 05:05 | <TabAtkins_> | I'm responding to the eventsource url correctly, with a 200 OK and text/event-stream content-type, so basically I'm confused. |
| 05:21 | <zcorpan> | hsivonen: in ie6 (and probably ie7 and ie8), <p><hr> end up with the hr inside p, but <p>foo<hr> the hr ends up as a sibling |
| 06:25 | <hsivonen> | zcorpan: interesting. not something I'd jump to cloning, though |
| 06:28 | <zcorpan> | Hixie: ftr, i'm not using the zcorpan⊙hc bugzilla account. apparently it's not possible to remove it |
| 06:29 | <zcorpan> | Hixie: i use the simonp⊙oc bugzilla account |
| 06:48 | <wycats> | Hixie: wtf is up with the W3C comments about HTML5 today? |
| 06:49 | <wycats> | (I need to add this room to my auto-join again -- got a new laptop and totally forgot :/ ) |
| 06:50 | <zcorpan> | so, the tag position is (1) "we like distributed extensibility" and (2) "we'd like html5 to do it "like SVG"" |
| 06:51 | <zcorpan> | without saying why |
| 06:51 | <othermaciej> | wycats: which comments do you have in mind? |
| 06:52 | <wycats> | othermaciej: "HTML5 is not ready" |
| 08:20 | <asmodai> | heh |
| 08:21 | <asmodai> | so Firefox prompts me to install 3.6.11 - after that you get redirected to the whatsnew page for .11 and it shows you: |
| 08:21 | <asmodai> | You’re running an unknown version of Firefox. |
| 08:38 | <annevk> | XHTML2 WG still going strong? http://www.w3.org/News/2010.html#entry-8922 |
| 08:38 | <annevk> | (I guess they'll just publish whatever is left, but still kind of weird given how long ago they were supposed to be closed down...) |
| 08:40 | <asmodai> | annevk: maybe one rebel who keeps up truckin' |
| 08:57 | <annevk> | wow that TAG email is meaningless |
| 08:58 | <annevk> | might as well have said +1 to "like SVG" |
| 08:59 | <othermaciej> | wycats: I hope PLH was giving his own opinions there (and perhaps was selectively quoted) rather than presenting an official W3C position |
| 09:00 | <othermaciej> | since W3C management has been pushing me and the other co-chairs to get HTML5 to Last Call as soon as possible, and it would be weird in light of that to present it as highly unready and totally lacking in interoperability |
| 09:00 | <othermaciej> | annevk: I questioned their last publication request when it went by on the chairs list |
| 09:00 | <othermaciej> | Ian Jacobs said that they'd been given a number of extensions for their existence, which unfortunately were not publicly announced |
| 09:01 | <othermaciej> | for those with W3C Member access: http://lists.w3.org/Archives/Member/chairs/2010JulSep/0050.html |
| 09:01 | <annevk> | interesting |
| 09:39 | <zcorpan> | othermaciej: the difference between personal opinion from a w3c rep and "the w3c" is non-existent in article headlines |
| 10:08 | <jgraham> | We should write a spec for the IE selectNodes and selectSingleNode XPath APIs. As far as I can tell they are orders of magnitude better than document.evaluate (not hard) |
| 10:08 | jgraham | dons flameproof suit for mentioning XPath |
| 10:11 | <jgraham> | Although the way of dealing with namespaces look odd |
| 10:11 | jgraham | wonders what Opera does here |
| 10:12 | <jgraham> | (odd but less insane than the "pass an arbitary function in" stuff from DOM3 XPath) |
| 10:13 | <zcorpan> | jgraham: go ahead (and write the spec) |
| 10:14 | <jgraham> | Yeah, that's the problem |
| 10:15 | <annevk> | W3C twittered they encourage people to use HTML5 again btw |
| 10:22 | <jgraham> | So now we will get headlines like "W3C Confused About HTML5 Readiness" |
| 10:26 | <zcorpan> | "Confused about HTML5? Well you should be!" |
| 10:41 | <zcorpan> | annevk: yay for domcore fpwd :) now let's hope the attr idea works out |
| 10:43 | <annevk> | heh yeah; sicking seems keen on experimenting post Firefox 4 |
| 10:44 | <annevk> | I now realize what I forgot in my blog post |
| 10:44 | <annevk> | history + acknowledgments |
| 10:44 | <annevk> | guess i'll write that up separately |
| 11:05 | <jarib> | jgraham: wait, IE has native XPath? |
| 11:06 | <jgraham> | As part of the MSXml stuff. I don't think you can run it against HTML documents or anything useful like that |
| 11:06 | <jgraham> | But I could be wrong |
| 11:06 | <jarib> | right, phew |
| 11:07 | <jgraham> | Opera has the same APIs that afaik work for anything with a DOM |
| 11:07 | <jgraham> | As well as the sort-of-standard-but-not really DOM3 Xpath crap |
| 11:08 | <jarib> | webdriver is injecting a JS XPath lib to get document.evaluate in IE, so I'd be surprised if there were alternatives we didn't know about |
| 12:10 | <annevk> | http://twitter.com/komputist/status/26736239613 -- I give up |
| 12:12 | <jgraham> | I gave up a long time ago |
| 12:13 | <annevk> | I'm not yet old and wise |
| 12:13 | <jgraham> | Nor am I |
| 12:14 | <jgraham> | Just old |
| 12:19 | <jgraham> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#overview-of-the-parsing-model the example there should say "script end tag token", right? |
| 12:20 | <zcorpan> | yes |
| 12:22 | <jgraham> | Bugged |
| 14:45 | <sideshow> | so do other people observe that in Chrome, WBS pages seem to be getting some kind of misguided over-aggressive caching that causes them to appear to never change? |
| 14:46 | <sideshow> | e.g., if I look at the issue-41 poll results in Chrome, it shows that Aryeh is the only person who's responded |
| 14:50 | <aja> | anyone from CSS WG here? |
| 14:51 | <aja> | just noticed that Planet CSS is borken....it's giving 403 errors |
| 14:51 | <aja> | http://www.w3.org/Style/CSS/Planet/ |
| 14:52 | <MikeSmith> | hmm, I guess shift+command+R is the way to cache bust in Chrome |
| 14:54 | <MikeSmith> | http://www.w3.org/Style/CSS/Planet/ indeed does seem to be broken |
| 15:06 | <hsivonen> | MikeSmith: the over-aggressive caching happens in Firefox/Minefield, too |
| 15:07 | hsivonen | uses Midori to read wbs response pages |
| 15:08 | <MikeSmith> | hsivonen: guess I must have already monkeyed with my caching in Mozilla to disable it |
| 15:09 | <MikeSmith> | I know I did that it in WebKit nightly already |
| 15:09 | <MikeSmith> | turned caching off completely |
| 15:09 | <MikeSmith> | anyway, systems team really need to fix that |
| 15:10 | <MikeSmith> | but I don't see the problem in Opera |
| 15:11 | <MikeSmith> | maybe I changed something tehre too |
| 15:11 | <MikeSmith> | if I did, I can't remember |
| 16:58 | <TabAtkins> | Hixie: Right, but do you need to distinguish them at accept time? You can detect differences and decide how to extract it once you've accepted the drop. |
| 16:59 | <TabAtkins> | Hixie: Is there a good reason to accept a text type with some particular datatype, but not a file type with the same datatype? |
| 17:13 | <jgraham> | So external scripts inserted via appendChild are racy, per spec, right? Or am I missing something? |
| 18:51 | Ms2ger | just noticed that Web DOM Core was published along with XHTML 1.1 |
| 18:53 | <gsnedders> | Thoughts on hsivonen's email, as asked at the end? That's a long email. |
| 19:38 | <Hixie> | TabAtkins: i think it's more likely the other way around... you don't want to accept image/png if it's not a File, for instance; another site shouldn't be able to set some string to type image/png and have you crash when you assume it's available as a file |
| 19:40 | <TabAtkins> | Hixie: But that'll happen *without* dropzone too, if you're not writing your code robustly. If I don't sniff the .types for "Files", then I'll dumbly accept a random string that has a datatype of "image/png". |
| 19:40 | <Hixie> | well right now, you won't get image/png if the user dragged a file |
| 19:40 | <Hixie> | you'll only get Files |
| 19:40 | <Hixie> | that's one of the things that gets fixed by that API i was talking to maciej about |
| 19:41 | <TabAtkins> | That doesn't seem to match the spec - doesn't it say that files should get a platform-specified datatype, converted to a mimetype by the UA? |
| 19:44 | <Hixie> | does it? |
| 19:44 | TabAtkins | goes to check his memory. |
| 19:45 | <Ms2ger> | Hixie, is the file you feed to anolis for the W3C ED available? |
| 19:45 | <TabAtkins> | user agents must similarly use platform-specific conventions when deciding on what drag feedback to use. |
| 19:45 | <TabAtkins> | All the format strings must be converted to ASCII lowercase. If the platform conventions do not use MIME types to label the dragged data, the user agent must map the types to MIME types first. |
| 19:46 | <TabAtkins> | http://www.whatwg.org/specs/web-apps/current-work/complete/dnd.html#when-the-drag-and-drop-operation-starts-or-ends-in-another-application |
| 19:46 | <Hixie> | Ms2ger: it's briefly available each time i generate the spec |
| 19:46 | <Hixie> | Ms2ger: do you need a copy? what's up? |
| 19:47 | <Hixie> | TabAtkins: that's referring to raw data, not files |
| 19:47 | <Hixie> | i'll be the first to admit that section's a mess, btw |
| 19:48 | <Ms2ger> | Hmm, do you hardcode that it's an editor's draft? |
| 19:49 | <TabAtkins> | So, I'm wondering what the problem is. If files don't currently broadcast their datatype, then there's no risk of expecting a file and getting a string, right? |
| 19:49 | <gsnedders> | Ms2ger: Yeah, [Status] isn't used at all in HTML5 |
| 19:49 | <Ms2ger> | Oh |
| 19:50 | <Hixie> | Ms2ger: it's one of the inputs i give to my script |
| 19:51 | <Hixie> | TabAtkins: as part of this attribute, i want to provide a new API that fixes all these problems... one of the parts of that is that files' types get exposes |
| 19:51 | <Hixie> | exposed |
| 19:51 | <TabAtkins> | Okay, I didn't realize there was more being talked about here than just what was in the spec. |
| 19:51 | <TabAtkins> | Then you probably just want some way to say "this datatype is for a file" or "this datatype is for a string". Like prefixing with an @ or something for files. |
| 19:52 | <TabAtkins> | dropzone="@image/png" would only accept files of type image/png. |
| 19:52 | <Hixie> | yeah, agreed. that's what i was suggesting yesterday. |
| 19:53 | <TabAtkins> | Ah, okay. Then yay for synchrony! |
| 19:53 | <Hixie> | i wonder how many of these "kinds" we'll have |
| 19:54 | <TabAtkins> | Surely not more than the number of useful non-alphanum characters we have at our disposal. |
| 19:55 | <TabAtkins> | Alternately - use a "magic type" to switch the entire dropzone to only accepting files or whatever - if "Files" is present in the dropzone list, all the other datatypes are assumed to be file types, not string types. |
| 19:55 | <TabAtkins> | I suspect that may be less useful, though. I dunno. |
| 19:57 | <Hixie> | yeah, i dunno |
| 19:58 | <Hixie> | there's also the weird situation of the types not necessarily being MIME types... not sure what we're doing with that currently, i'd have to check the spec |
| 19:58 | <Hixie> | but some platforms just allow arbitrary strings (including spaces?) as the type names |
| 19:58 | <Hixie> | which makes it difficult to do a space-separated or @-prefixed list |
| 19:58 | <Hixie> | i'll have to study this more carefully |
| 20:01 | <TabAtkins> | >_< |
| 20:01 | <TabAtkins> | Convert spaces to _. Done. |
| 20:01 | <TabAtkins> | Alternately... Escape? |
| 20:01 | <Hixie> | theoretically, how would you distinguish "text_" and "text "? (hopefully it'll never matter of course) |
| 20:02 | <Hixie> | yeah, escaping is the obvious solution if it's a real problem |
| 20:02 | <Hixie> | but that's a huge pain |
| 20:50 | jgraham | reads hsivonen's email (asking about the same thing before was coincidence) |
| 20:58 | <jgraham> | Doesn't it make more sense to make preserving order the default |
| 20:58 | <jgraham> | and opt-in to racy behaviour? |
| 20:59 | jgraham | reads again |
| 21:03 | <jgraham> | Specifically the script-inserted exteral scripts blocking parser-inserted scripts part |
| 21:03 | <jgraham> | Although I suppose the percieved problem with the safe solution is that it will not be accepted by WebKit/IE |
| 21:05 | gsnedders | would rather have non-racy behaviour |
| 21:07 | <othermaciej> | jgraham: I suspect in most cases you don't actually want order dependencies |
| 21:08 | <othermaciej> | sometimes you do have a specific order dependency and want it respected, but in other cases this just causes a needless perf hit |
| 21:20 | <jgraham> | othermaciej: Right, but in general it seems safer to have lower-performance safe behaviour and let people opt in to higher performance less safe behaviour |
| 21:20 | <jgraham> | Rather than the reverse |
| 21:20 | <hober> | agreed |
| 21:20 | <hober> | (declaim (optimize (speed 3) (safety 0))) :) |
| 21:21 | gsnedders | has seen sites depend upon the exact perf of browsers before |
| 21:44 | AryehGregor | raises an eyebrow at WHATWG |
| 21:45 | <othermaciej> | jgraham: I'm not sure the tradeoffs are quite so completely obvious |
| 21:45 | <othermaciej> | you could take it to an extreme and say processing of *all* resources is constrained by order of load requests |
| 21:46 | <othermaciej> | even, say, images, or stylesheets |
| 21:46 | <AryehGregor> | I've adopted a new policy to combat procrastination: for all the stuff I check every day (like e-mail and feeds), I will only check it once, except for my priority inbox. |
| 21:46 | <AryehGregor> | Now I have to find something to actually do for the next hour. |
| 21:46 | <othermaciej> | but that would probably be too extreme, given the risk caused by the "raciness" vs. the huge performance cost |
| 21:47 | <gsnedders> | AryehGregor: I decreased frequency of checking emails to once per hour, and noticed a larger perf increase. And nowadays I mostly ignore specs email. |
| 21:47 | <variable> | AryehGregor, smart idea. too bad I'll probably put off implementing it ;-) |
| 21:48 | <variable> | seriously - I should implement the same policy :-\ |
| 21:53 | <jgraham> | AryehGregor: You should spend it on irc instead |
| 21:54 | <TabAtkins> | hober: Hey, don't knock DECLAIM. |
| 21:54 | <TabAtkins> | Saves me necessary execution time when doing Project Euler. |
| 21:54 | <jgraham> | othermaciej: Indeed. But it at least seems somewhat more likely that scripts will depend on other scripts since there are already hacks in the platform to wait for stylesheets and so on |
| 21:55 | <annevk> | this two-day break from normal work was great |
| 21:56 | <gsnedders> | annevk: meaning you spend the entire time doing site compat on porn sites? |
| 21:56 | <gsnedders> | *spent |
| 21:57 | jgraham | wonders where that came from |
| 21:57 | <gsnedders> | An IM conversation I'm in the middle of. |
| 21:58 | <othermaciej> | jgraham: most dynamically inserted scripts are either a bad way of loading JSON (and so likely to have no dependencies on anything) or are library modules that don't do anything substantive other than declare some functions (and so also are unlikely to have order dependencies) |
| 21:58 | <gsnedders> | I guess that's not useful to reference. |
| 21:58 | <annevk> | that is what I was taking a break from |
| 21:58 | <annevk> | ;p |
| 21:58 | <gsnedders> | :P |
| 21:58 | annevk | was at a web developer conference |
| 21:58 | <annevk> | see da twitters |
| 21:58 | <gsnedders> | annevk: I saw. :) Håkon still sitting down? You haven't said he's stood up yet! |
| 21:59 | <annevk> | we had to carry him out to the airport |
| 22:03 | <jgraham> | othermaciej: It's not clear that "most" is the problem. The problem is if *some* scripts react badly to out-of-order loading |
| 22:04 | <AryehGregor> | othermaciej, could you look at http://www.w3.org/Bugs/Public/show_bug.cgi?id=10355 ? In particular, is it true that WebKit only supports two reflected IDL attributes on marquee; and if so, would it be interested in supporting more to match IE/Gecko/Opera? |
| 22:05 | <annevk> | would be more interesting to support less :) |
| 22:05 | <othermaciej> | jgraham: in practice this only seems to arise in cases where libraries are used to try to explcitly support it |
| 22:05 | <othermaciej> | i.e. the current de facto model on the Web is to opt in to ordering |
| 22:30 | <hober> | TabAtkins: I'm not knocking DECLAIM; I'm a big fan |
| 22:31 | <TabAtkins> | Excellent. |
| 23:03 | <TabAtkins> | Oh god. AryehGregor, I apologize unofficially for the UI for <input type=date>. How did someone honestly think this was an improvement over no UI? |
| 23:10 | <TabAtkins> | Dang, I didn't realize <progress> and <meter> landed in Chrome 6. They've got pretty decent UI! |
| 23:15 | <hober> | yeah, looking nice |
| 23:30 | <smaug____> | huh, progress looks pretty terrible |
| 23:30 | <TabAtkins> | Really? I think it's just fine. |
| 23:30 | <TabAtkins> | indeterminate especially |
| 23:31 | <smaug____> | though Chrome 6 doesn't really use right theming on Linux anyway |
| 23:31 | <smaug____> | (does it use any native theming on linux) |
| 23:39 | <TabAtkins> | smaug____: Oh, wait, never mind. It does suck on Linux. It's pretty on Windows, though. |