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