00:02 | <jamesr__> | Hixie_: http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#309 |
00:02 | <Hixie_> | thanks |
00:02 | <jamesr__> | (finding the blink/webkit one) |
00:02 | <jamesr__> | blink: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/DOMTimer.cpp&sq=package:chromium&type=cs&l=41 |
00:02 | <jamesr__> | webkit's still the same |
00:04 | <Hixie_> | notice firefox actually clamps setinterval to 1 |
00:05 | <zewt> | big blocks of code-in-defines in firefox code = sadface |
00:06 | <jamesr__> | oh interesting |
00:06 | <jamesr__> | looks like we do too |
00:06 | <Hixie_> | actually looks like blink clamps to 0 even in settimeout? |
00:06 | <Hixie_> | is DOMTimer::DOMTimer called for both timeouts and intervals? |
00:06 | <jamesr__> | here: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/DOMTimer.cpp&sq=package:chromium&type=cs&l=85 |
00:06 | <Hixie_> | er, 1 |
00:07 | <jamesr__> | the difference between 0 and 1 is rarely web-observable |
00:07 | <jamesr__> | but that's interesting |
00:08 | <Hixie_> | it's not often that i think gecko code is easier to follow than webkit code, but in this particular instance... |
00:09 | <Hixie_> | wait, nevermind, i scrolled down more in the gecko code |
00:11 | <jamesr__> | the amount of gecko code that fits into one page is simpler :P |
00:11 | <jamesr__> | i don't think we have an equivalent of their IsFrozen() stuff |
00:12 | <zewt> | at least it's not ... java |
00:12 | <zewt> | the king language of "take 25 pages to do anything" |
00:12 | <jamesr__> | or the subject principle stuff they have |
00:12 | <jamesr__> | since we don't support bfcache or running privileged JS in the same context as web content |
00:14 | <zewt> | usually when i look at gecko, i give up before even finding the source for the thing i'm interested in, heh |
00:15 | <jamesr__> | mxr.mozilla.org is great |
00:15 | <jamesr__> | just have to throw enough regexes at it |
00:15 | <jamesr__> | and remember to throw "ns" on the front of random things |
00:17 | <Hixie_> | i'm marking https://www.w3.org/Bugs/Public/show_bug.cgi?id=22604 NEEDSINFO unless someone can elaborate on what needs explaining. (window.stop()) |
00:21 | <GPHemsley> | Hixie_: ah, updated now, cool |
00:23 | <zewt> | i think it's fabulous that, when logging into progressive.com, i enter my username and password, then click "save user id" |
00:23 | <zewt> | and it ... opens a new page explaining what "save user id" means (and when i hit back the info i entered is gone) |
00:23 | <zewt> | label fail |
00:24 | GPHemsley | will eventually get to upgrading the MediaWiki installation |
00:29 | <Hixie_> | ok. i have officially dealt with bugs and will now transition to e-mails. |
00:29 | <Hixie_> | yikes, according to my e-mail metrics script, i have some feedback from 1969-12-31 16:00:00 |
00:29 | <Hixie_> | i'm thinking maybe my script will be the next thing i work on... |
00:30 | <zewt> | maybe you're just more behind than you thought |
01:04 | <MikeSmith> | Hixie_: commit-watchers messages are showing some svn error on your server |
01:04 | <MikeSmith> | http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2013/007197.html |
01:04 | <MikeSmith> | "svnlook: Can't find a temporary directory" |
01:05 | <Hixie_> | yeah, known issue |
01:05 | <Hixie_> | support request is in the queue |
01:06 | <MikeSmith> | ok |
01:07 | <MikeSmith> | ah I see it means the diffs aren't showing up at e.g., http://html5.org/tools/web-apps-tracker?from=8048&to=8049 either |
01:07 | MikeSmith | resorts to running svn log locally |
01:08 | <MikeSmith> | $ svn update |
01:08 | <MikeSmith> | Updating '.': |
01:08 | <MikeSmith> | svn: E020014: Can't find a temporary directory: Internal error |
01:09 | <MikeSmith> | I guess that's the same error, coming from your server |
01:09 | <MikeSmith> | gotta love subversion |
01:13 | <nessy1> | Hixie_ thanks for dealing with the removeTextTrack() request - hope it's ok for me to flick things like this over to WHATWG? |
01:25 | <Hixie_> | MikeSmith: yeah |
01:25 | <Hixie_> | MikeSmith: server was updated today |
01:25 | <Hixie_> | nessy1: sure |
01:25 | <MikeSmith> | Hixie_: ok |
01:50 | <annevk> | MikeSmith: distributed software man, kinda like the web |
01:51 | <MikeSmith> | poorly distributed |
01:51 | <MikeSmith> | clearly |
01:51 | <MikeSmith> | in the case of svn at least |
01:51 | <MikeSmith> | ill-distributed |
01:53 | <annevk> | MikeSmith: I say we blame your employer |
01:54 | <MikeSmith> | which of my employers? the NSA, or the Six Big Hollywood Studios? |
02:01 | <annevk> | MikeSmith: Looney Tunes, doh |
02:11 | <Hixie_> | man, this /tmp problem has all kinds of side-effects |
02:11 | <Hixie_> | all my cron jobs are broken because cron can't create lock files |
02:26 | <Hixie_> | oh, awesome. i'm finally running a version of perl recent enough to have the // operator. |
02:31 | heycam | does "man perlop", discovers that // looks pretty useful |
02:34 | <Hixie_> | heycam: //= too |
02:34 | <Hixie_> | in fact //= is the more useful one |
02:35 | <zewt> | perl :| |
02:47 | <annevk> | /= assigns RH to LH if RH is defined and otherwise leaves LH be LH? |
02:47 | <annevk> | //=* |
02:54 | <Hixie_> | yes |
02:54 | <Hixie_> | zewt: yeah, while i love perl, i'd never actually recommend it to anyone. :-) |
02:55 | <Hixie_> | zewt: it gets "unmaintainable" as one of its "other notable failings" on my programming languages page (http://ian.hixie.ch/programming/) |
03:15 | <tantek> | Hixie, nice table. Curious what you're take on PHP is / will be. |
03:15 | <tantek> | and Rust while you're at it. |
03:15 | <Hixie_> | php doesn't deserve to be on that table |
03:15 | <Hixie_> | not familiar with rust |
03:15 | <zewt> | php is more useful than perl in my experience heh |
03:16 | <tantek> | PHP seems to be fairly good for shipping / scaling websites in practice. |
03:16 | <msaad> | tanked: indeed! |
03:16 | <msaad> | tantek* |
03:16 | <tantek> | You know, WordPress, Facebook, small sites/software like that. |
03:16 | <msaad> | ahahhaa |
03:17 | <tantek> | Hixie: http://en.wikipedia.org/wiki/Rust_%28programming_language%29 |
03:20 | <Hixie_> | seems fine |
03:21 | <Hixie_> | as far as that table goes, it's not supposed to be subjective |
03:21 | <Hixie_> | so you could easily enough (if you know rust) fill out a row for it |
07:40 | <heycam> | what's the difference between Rect and CSSRect? |
08:08 | <hsivonen> | Hixie_: Your programming language table is too generous when it says Python has Unicode support |
08:08 | <hsivonen> | it has it twice and you don't know which semantics your program will be run with |
08:08 | <hsivonen> | which is arguable worse than no explicit support |
08:11 | <jgraham> | hsivonen: That assessment is much more theoretical than practical |
08:12 | <jgraham> | For the cases where it matters (and istr that some of the differences have been fixed in the API) you can detect at runtime which kind of build you are running on |
09:58 | <jgraham> | Ms2ger: What did you want me to do? |
09:59 | <Ms2ger> | annevk wanted someone to fix up the tabs when merging his PR |
10:00 | <Ms2ger> | (Introduce tabs, that is) |
10:03 | <jgraham> | I am still quite confused. Why did he want tabs and why did he want someone else to add them? Also where (i.e. which PR)? |
10:04 | <Ms2ger> | https://github.com/w3c/web-platform-tests/pull/243 |
10:04 | <Ms2ger> | The file uses tabs because Aryeh wrote it |
10:06 | <jgraham> | Oh OK |
10:06 | <jgraham> | Well I have an alternate proposal, which is s/\t/ /g |
10:46 | <darobin> | jgraham: that doesn't actually really work for replacing tabs |
10:46 | <darobin> | well, it'll replace tabs alright |
10:46 | <darobin> | but you might wreak havoc if someone has them anywhere other than at the beginning of a line |
10:48 | <Ms2ger> | That's fine, then |
10:52 | <jgraham> | darobin: Well in practice I would (will) actually just use the emacs function. |
10:53 | <darobin> | Ms2ger: I wouldn't trust someone who's using tabs in the first place not to sprinkle them throughout :) |
10:53 | <darobin> | jgraham: yeah |
10:53 | <Ms2ger> | I trust Aryeh on that |
12:02 | <darobin> | is it known that the WHATWG SVN is dead? |
12:02 | <darobin> | ah, yes, it's known |
12:04 | <darobin> | bummer |
12:26 | <annevk> | doesn't take long to figure out when all things fall apart :) |
12:27 | <annevk> | jgraham: replacing with spaces wfm too, I'd prefer if the person merging does it |
12:39 | <annevk> | JakeA: were you interested in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628 or was that someone else? |
12:41 | <JakeA> | I don't *think* that was me |
12:42 | <JakeA> | There was stuff around getting information from the window object into the NavigationController (but the problem there is there isn't always a related window), but I don't think this is part of it |
12:42 | <annevk> | JakeA: mkay, well now you know anyway |
12:43 | <annevk> | JakeA: yeah, that's a bit distinct, though I guess there might be some overlap |
12:48 | <annevk> | Hixie_'s table makes C# look pretty compelling |
13:06 | <darobin> | C# isn't too bad, it's a bit like Java done right |
13:42 | <annevk5> | Domenic_: why did you not make Elements a frozen array btw? |
13:42 | <darobin> | a quick question to the python people here... |
13:43 | <darobin> | I have this lovely piece of code: new_toc_items = [ (d, id, e) for (d, id, e) in toc_items if id_pages[id] == name ] |
13:43 | <darobin> | and I'm getting a KeyError |
13:43 | <darobin> | do I presume right that it's for a key that's in toc_items and not in id_pages? |
13:43 | darobin | swears this language will drive me crazy, Perl ftw |
13:43 | <Ms2ger> | Sounds right |
13:43 | <darobin> | k, ta |
13:44 | <Ms2ger> | id_pages.get() maybe? |
13:44 | darobin | now at least knows in which haystack to look for the needle |
13:44 | <gsnedders> | darobin: What type is toc_items? |
13:44 | <darobin> | Ms2ger: I thought of that, but I think it's a genuine issue if the key ain't there |
13:45 | <darobin> | gsnedders: it's an array, or whatever [] is called in Python |
13:45 | <annevk_> | darobin: list |
13:45 | <darobin> | right, I knew they'd do it differently :) |
13:45 | <annevk_> | it makes sense |
13:45 | <annevk_> | if you're Dutch |
13:45 | <darobin> | aha! |
13:46 | <darobin> | maybe I should learn Dutch then, if it makes my grief in using python go away it's worth it |
14:42 | <GPHemsley> | Chrome doesn't fire mouseenter/mouseleave? o_0 |
14:44 | <Ms2ger> | gsnedders, remind me how I get sorted attributes in html5lib? |
14:45 | <GPHemsley> | and neither does Safari |
14:45 | <Ms2ger> | Or jgraham |
14:46 | <SimonSapin> | Ms2ger: HTMLSerializer(alphabetical_attributes=True) |
14:47 | <GPHemsley> | Hixie_: Oh, goodie. No interop in mouse event order. |
14:47 | <GPHemsley> | (Though Opera's behavior is what I would've done.) |
14:48 | <Ms2ger> | Ha |
14:48 | GPHemsley | checks IE |
14:55 | <Domenic_> | annevk: didn't really see a point, and frozen arrays are kind of awkward. although, if we were to have something like `Element.childElements` that returned an `Elements`, i.e. if `Elements` ever represents a real DOM tree instead of just a snapshot, then we should override all the mutation methods to do a type-check before calling their `super`. |
14:55 | <Ms2ger> | Okay, that works |
14:56 | <Ms2ger> | Any Anolis users around who object to bumping the required html5lib version to 1.0b2? |
15:01 | <GPHemsley> | Ms2ger: Not if you turn on sorting the attributes |
15:02 | <Ms2ger> | Yeah |
15:02 | <annevk> | Ugh, software upgrades |
15:02 | <annevk> | Domenic_: how would Elements represent a tree? It's an array. |
15:07 | <Domenic_> | annevk: sorry, s/real DOM tree/part of a real DOM tree |
15:07 | <annevk> | Domenic_: doesn't help |
15:08 | <Domenic_> | meaning, mutating the return value of `findAll()` doesn't matter, since it doesn't represent something that's in the DOM. But mutating e.g. `myDiv.childElements` would matter, since it represents the child elements of `myDiv`. |
15:09 | <Domenic_> | (setting aside the fact that having `children`, `childNodes`, and `childElements` all together would be crazy-confusing.) |
15:09 | <annevk> | Mkay. I guess that's why frozen seems somewhat better since it works in more cases, but it's kinda annoying you'd have to clone it in order to modify the array. |
15:10 | <annevk> | Yeah, we probably wouldn't add yet another member there addressing the same use case. |
15:10 | <Domenic_> | yeah, i was trying for jQuery-ease-of-use parity, and I do somewhat-often dynamically construct or modify my jQuery $() objects. |
15:15 | <Domenic_> | (it would be cool to have something where you do `myDiv.childElements.push` instead of `myDiv.appendChild`.) |
15:16 | <Ms2ger> | Eww |
15:27 | <annevk> | Domenic_: given the number of checks appendChild() does, I'm not sure that's feasible |
15:30 | <Domenic_> | annevk: you're probably right, but naively you could just add those checks to `push` before calling `super`. |
15:30 | Domenic_ | goes off to look at appendChild spec |
15:31 | <annevk> | Domenic_: http://dom.spec.whatwg.org/#concept-node-pre-insert |
15:32 | <annevk> | Domenic_: with child being null |
15:41 | <GPHemsley> | what I don't understand is why everyone fires a mouseover event for elements that are not on top |
15:42 | <GPHemsley> | and only when the not-on-top element is a parent of the on-top element |
15:44 | <annevk> | GPHemsley: matches :hover |
15:44 | <GPHemsley> | it's like they fire mouseover leaf to root and then fire mouseenter root to leaf |
15:44 | <annevk> | (not sure which came first) |
15:45 | <GPHemsley> | actually, only Gecko does that |
15:45 | <GPHemsley> | Opera does it in the reverse order: mouseenter before mouseover |
15:45 | <GPHemsley> | Chrome and Safari don't even fire mouseenter |
15:46 | <annevk> | just landed in Chrome |
15:46 | <annevk> | (patch for mouseeventer) |
15:46 | <GPHemsley> | any idea what order it uses? |
15:47 | <GPHemsley> | mouseout/mouseleave seems more consistent cross-browser, but not necessarily logically |
15:48 | <GPHemsley> | both mouseout and mouseleave (where applicable) are fired leaf to root |
15:48 | <GPHemsley> | and both Gecko and Opera fire mouseout before mouseleave |
15:49 | <GPHemsley> | which means Gecko is mouseover -> mouseenter -> mouseout -> mouseleave |
15:49 | <GPHemsley> | and Opera is mouseenter -> mouseover -> mouseout -> mouseleave |
15:49 | <GPHemsley> | oh, that actually is logical, I guess |
15:50 | <GPHemsley> | sort of |
15:51 | <GPHemsley> | I might've interleaved them, instead of firing all of one type at once before firing all of the other type |
15:52 | <GPHemsley> | but in any case, it seems the only interop order problem is mouseenter vs. mouseover |
15:53 | <GPHemsley> | Gecko seems to match what DOM 3 Events suggests with its examples; Opera match what seems more logical to me |
15:53 | <GPHemsley> | hopefully Chrome picked one of the two |
15:55 | <jgraham> | Ms2ger: So did you actually review https://critic.hoppipolla.co.uk/r/212? |
15:56 | <Ms2ger> | Not carefully |
16:02 | <GPHemsley> | Ms2ger: Are you working on updating Anolis to sort attributes? |
16:03 | <jgraham> | Ms2ger: Fancy reviewing it carefully? Then I will do the whitespace fixups |
16:03 | <jgraham> | (which I should say are not exactly easy to do in the github workflow) |
16:08 | <Ms2ger> | I guess I can |
16:43 | <darobin> | GPHemsley: if you enjoy looking at how interoperable events are, I highly recommend how they work for <select> :) http://rodneyrehm.github.io/select-events/ |
16:44 | <GPHemsley> | oh my |
16:44 | <GPHemsley> | I'm actually looking specifically at mouse events |
16:45 | <GPHemsley> | but this looks helpful |
16:46 | <GPHemsley> | (though I see IE going to be a pain) |
16:46 | <jpwhiting> | hello all, I'm using a local copy of validator.nu with my own schema based on html5full.rnc |
16:46 | <jpwhiting> | but now that I've rebuilt, I'm getting a java exception when it reads my rnc file |
16:47 | <jpwhiting> | java.lang.ClassCastException: org.xml.sax.InputSource cannot be cast to nu.validator.xml.TypedInputSource |
16:47 | <jpwhiting> | I'm using the same schema file I used 3 months ago, but I didn't keep the sources for validator.nu from then, so trying to use it with current validator.nu sources and failing :/ |
16:53 | <jpwhiting> | which makes no sense because TypedInputSource extends InputSource, so it should be able to cast, no? |
16:58 | <annevk> | GPHemsley: you want to test IE too I think |
16:58 | <annevk> | GPHemsley: IE pioneered some of those events |
16:58 | <GPHemsley> | according to the test results from darobin's link, IE does things differently than everyone else, too |
16:59 | <GPHemsley> | in particular, mousemove comes before mouseover and mouseenter |
16:59 | <annevk> | GPHemsley: putting these forward as bugs against DOM Level 3 Events might help get some of this fixed before you fix all of the details with a better spec, fwiw |
17:00 | <GPHemsley> | they don't necessarily seem like spec bugs to me |
17:00 | <GPHemsley> | except insofar as the spec doesn't actually really specify the right order |
17:01 | <annevk> | That's called a spec bug |
17:01 | <GPHemsley> | if I file everything as a spec bug on DOM 3 Events, then what goes in the new spec? |
17:02 | <jpwhiting> | ah, seems I was patching the wrong entitymap file |
17:02 | <annevk> | When you find fundamental brokenness and the lack of a clear model as a showstopper to fixing bugs |
17:02 | <annevk> | (and adding new features) |
17:03 | <annevk> | jpwhiting: good, since the one guy that can help you with that is prolly asleep |
17:04 | <jpwhiting> | :) |
17:04 | jpwhiting | seems to be learning java, despite his best efforts |
17:04 | jpwhiting | is a C++ guy :p |
17:05 | <GPHemsley> | annevk: Well, then I guess I'm still not clear on what Hixie_ is asking me to spec. |
17:06 | <annevk> | GPHemsley: what did Hixie_ say? |
17:06 | <jpwhiting> | annevk: just curious who is the one guy that knows this stuff? |
17:06 | jpwhiting | forgot, though I think I've chatted with him before |
17:07 | <Ms2ger> | hsivonen? |
17:07 | <Ms2ger> | If you mean the Java parser |
17:07 | <annevk> | jpwhiting: MikeSmit1 |
17:07 | <jpwhiting> | right, thanks |
17:07 | <Ms2ger> | And Mike too, yes |
17:07 | <jpwhiting> | that seems to trigger some memory |
17:07 | <annevk> | He's in Tokyo, hence the sleeping |
17:07 | <jpwhiting> | right, makes sense |
17:08 | <GPHemsley> | annevk: 21:44 Hixie_ GPHemsley: btw, you still looking for a project? because mouse events would be a good one, and shouldn't be too hard, yet is a huge hole in our current spec coverage. |
17:08 | <jpwhiting> | being the middle of the night there at the moment :) |
17:08 | <GPHemsley> | annevk: 00:08 Hixie_ GPHemsley: these events are what need speccing. I wouldn't call them "DOM 3 events", they were invented before the W3C had a DOM WG. (Possibly before the W3C existed.) |
17:09 | <GPHemsley> | 00:09 Hixie_ GPHemsley: as zewt says, though, it's not so much the events that need speccing, as the reaction to mouse movements, clicks, etc. Which happens to involve firing events with these names, but that's the effect, no the cause. |
17:09 | <GPHemsley> | annevk: Where "these events" mean the ones in DOM 3 Events |
17:09 | <GPHemsley> | the mouse* ones, that is |
17:10 | <GPHemsley> | http://www.w3.org/TR/DOM-Level-3-Events/#events-mouseevents |
17:10 | <GPHemsley> | actually http://www.w3.org/TR/DOM-Level-3-Events/#events-mouseevent-event-order |
17:10 | <GPHemsley> | (these quotes are from yesterday and the day before) |
17:15 | <annevk> | GPHemsley: afk for a bit |
17:56 | <dglazkov> | good morning, Whatwg! |
19:01 | <GPHemsley> | Ms2ger: What's the best way to link to a definition in a spec that doesn't have an xref file? |
19:15 | <Ms2ger> | GPHemsley, add an xref file manually |
19:15 | <GPHemsley> | that's the only way? |
19:18 | <Ms2ger> | GPHemsley, no, you can also use a normal a element |
19:18 | <Hixie_> | ok, dreamhost say /tmp permissions issues are fixed |
19:18 | <Hixie_> | (and they do seem to be) |
19:25 | <annevk> | we're generating diffs again |
19:26 | <annevk> | GPHemsley: so yeah, sounds like Hixie_ is indeed talking about all those things |
19:27 | <annevk> | GPHemsley: another set of events that need similar treatment is keyboard events |
19:27 | <Hixie_> | i'm talking about things? |
19:27 | <annevk> | Hixie_: 17 |
19:28 | <Hixie_> | 17 things? |
19:28 | <annevk> | yes, in two minutes |
19:31 | <Hixie_> | i'm confooooooosed |
19:50 | <GPHemsley> | Hixie_: annevk told me to file bugs against DOM 3 Events instead of writing a new spec, so now I'm confused |
19:50 | <GPHemsley> | (for certain definitions of "instead of") |
20:06 | <Hixie_> | GPHemsley: if there's already a spec that attempts to address this, then that's news to me |
20:06 | <Hixie_> | GPHemsley: but good news, i guess |
20:08 | <GPHemsley> | Hixie_: Well, DOM 3 Events is the only one we've been discussing |
20:08 | <GPHemsley> | Hixie_: I got mixed information as to whether it attempts to address this |
20:09 | <GPHemsley> | Hixie_: http://www.w3.org/TR/DOM-Level-3-Events/#events-mouseevent-event-order |
20:09 | <Hixie_> | ask the editors, i guess :-) |
20:12 | <GPHemsley> | Hixie_: I wouldn't know what to ask. Other than event ordering, I'm still not clear on what is missing. (Also, the two current editors are from Microsoft, and the spec does not include editor e-mail addresses.) |
20:14 | <annevk> | GPHemsley: hit testing is missing, as I pointed out |
20:17 | <Hixie_> | GPHemsley: is there anything that says "when the mouse moves, user agents must fire a mouseenter event with the clientX attribute set to..." and so on? |
20:17 | <annevk> | GPHemsley: and a more exact definition of how the various members of a MouseEvent object are set |
20:17 | <annevk> | GPHemsley: etc. |
20:17 | <annevk> | GPHemsley: as for filing bugs, I was saying that as a means of getting browsers to converge on some of the issues faster |
20:17 | <annevk> | GPHemsley: if they can fix all the issues, that'd be great, but I suspect that at some point they'll stop fixing |
20:19 | <GPHemsley> | Hixie_: "A user agent must dispatch this event [mouseenter] when a pointing device is moved onto the boundaries of an element or one of its descendent elements." |
20:19 | <GPHemsley> | Hixie_: "MouseEvent.clientX: value based on the pointer position within the viewport |
20:19 | <GPHemsley> | MouseEvent.clientY : value based on the pointer position within the viewport" |
20:20 | <Hixie_> | wow that's so many kinds of wrong i don't even know where to begin |
20:20 | <Hixie_> | there needs to be an explanation of the task queued to do this, the task source for those tasks, the "based on" needs to be precise, the "boundaries" needs to be defined |
20:21 | <Hixie_> | the default action needs to be defined |
20:21 | <Hixie_> | etc etc etc |
20:22 | <GPHemsley> | "Default action none" |
20:22 | <Hixie_> | that normatively likely doesn't mean anything |
20:22 | <Hixie_> | (basically, if the event is fired using a table, you can almost guarantee it's done wrong) |
20:24 | <GPHemsley> | in that case, there's probably no hope of a spec bug fixing this, as the whole document uses tables to describe events |
20:25 | <Hixie_> | there's a reason i never brought up dom3 events |
20:25 | <GPHemsley> | heh |
20:25 | <GPHemsley> | well I admit I'd have to learn more about events in general in order to do this right, I'd think |
20:26 | <GPHemsley> | but are you saying I should just ignore DOM 3 Events? |
20:27 | <Hixie_> | i do |
20:28 | <GPHemsley> | and start from scratch? |
20:30 | <annevk> | GPHemsley: again, filing bugs against DOM Level 3 Events will help with some short term convergence, but is not a viable long term strategy |
20:30 | <annevk> | I think both are worthwhile |
20:30 | <GPHemsley> | annevk: I can't ignore DOM 3 Events and file bugs on it at the same time. |
20:31 | <Hixie_> | GPHemsley: well, so, part of the job here is figuring out what the job is :-) |
20:32 | <Hixie_> | GPHemsley: i'm not saying "do this" or "do that", i'm saying, one problem we have on the web right now is there's no serious accurate and precise description of how mouse and trackpad interactions map to the variety of mouse events that deployed Web page content relies on |
20:32 | <Hixie_> | GPHemsley: if someone wants to fix this, then they should take ownership of the issue, and then decide how best to solve it. It could be that the best way to solve this is to work with existing editors at the W3C to improve specs in this area. |
20:33 | <Hixie_> | GPHemsley: it could be that the best way to solve this is to start from scratch, like we've done with e.g. URLs, DOM Core, HTML Editing APIs, HTML in general, etc. |
20:33 | <Hixie_> | GPHemsley: it could be that the best way to solve this is prayer (though that seems unlikely) |
20:33 | <GPHemsley> | definitely nixing that 3rd option |
20:34 | <Hixie_> | GPHemsley: whoever decides to own this, if anyone does, would have to make these calls |
20:34 | <Hixie_> | i'm happy to provide advice, but if i knew exactly how to fix it, i'd just do it :-) |
20:35 | <GPHemsley> | fair enough |
20:42 | <annevk> | I think I kinda know how to fix it, but I'm lazy |
20:42 | <annevk> | I also don't want to own user interaction events forever |
21:57 | <annevk> | Private email thread on licensing is going like this: “We’re listening to you. What was your concern?” |
21:58 | <hober> | i got an email the other day that boiled down to "I don't want to talk about what's in scope for this spec. I want to add something out of scope to this spec." |
21:59 | <Hixie_> | heh |
21:59 | <Hixie_> | reminds me of the way the w3c keeps saying "you can get involved in improving the w3c! let's have a meeting about discussing how we need to improve!" |
21:59 | <Hixie_> | literally been happening for at least half a decade now |
22:00 | <Hixie_> | (i keep getting invited to these meetings) |
22:00 | <annevk> | They keep scoping them in ways that are not useful |
22:00 | <Hixie_> | i've had them scoped all kinds of ways |
22:00 | <Hixie_> | including "everything is in scope" |
22:01 | <Hixie_> | the fundamental problem is that they disagree with me about what's wrong |
22:01 | <Hixie_> | it's the usual "ask the question over and over until you get the answer you want" |
22:01 | <annevk> | Sounds like the way the HTML WG works |
23:50 | <Yuhong> | On this matter, one reason I suggest http://www.w3.org/wiki/Evolution be finished is that TimBL is in the TAG. |
23:52 | <Yuhong> | But on DOM3 Events, unfortunately I don't think mutation events are going anywhere as IE9/10 support them but not MutationObserver. |
23:56 | <Domenic_> | (starting over on DOM Core was brilliant; those outdated levels stacked on top of each other were insane.) |
23:58 | <MikeSmith> | jpwhiting_: the errors your cited are a known issue and usually go away if you just run "python build/build.py all" a 2nd time |