| 03:07 | <zewt> | :last-child loses some value with no way of saying "last child that isn't [hidden]"... |
| 11:00 | <jgraham> | annevk: Do you mind getting minor editorial feedback about DOM here, or should I file bugs? |
| 11:00 | <annevk> | jgraham: I don't mind getting it here |
| 11:01 | <annevk> | jgraham: maybe I can fix some now |
| 11:02 | <jgraham> | "Just like most programming paradigms the Web platform has finite hierarchical tree structures, simply named trees." - I don't think of programming paradigms as things that have tree structures. Couldn't you just say that "A fundamental data stucture of the web platform is a finite heirachical data structure, called a tree."? |
| 11:02 | <jgraham> | Or something |
| 11:03 | <jgraham> | (I did say minor, editorial) |
| 11:03 | <jgraham> | Also the following sentence should probably explicitly say preorder, depth-first, traversal *of the tree*. |
| 11:06 | <jgraham> | The follwoing list of definitions don't make it clear that if A is the parent of B, B is a child of A |
| 11:07 | <annevk> | how about |
| 11:07 | <jgraham> | Also, it's not clear that having a parent of null is equivalent to having no parent |
| 11:07 | <annevk> | <p>A <dfn title=concept-tree>tree</dfn> is a finite hierarchical tree structures. In |
| 11:07 | <annevk> | <dfn title=concept-tree-order>tree order</dfn> is preorder, depth-first |
| 11:07 | <annevk> | traversal of a <span title=concept-tree>tree</span>. |
| 11:08 | <jgraham> | annevk: s/structures/structure/ and it sounds good to me. |
| 11:08 | <annevk> | k |
| 11:12 | <jgraham> | First child and last child have rather circular definitions |
| 11:12 | <jgraham> | The first child should be defined as the child which has no preceding siblings |
| 11:13 | <jgraham> | (and similarly for last child and following siblings) |
| 11:13 | <annevk> | hmm nah |
| 11:13 | <annevk> | children are defined as a list |
| 11:14 | <annevk> | so first and last in that list is clear |
| 11:14 | <annevk> | I added |
| 11:14 | <annevk> | An object <var title>A</var> whose |
| 11:14 | <annevk> | <span title=concept-tree-parent>parent</span> is object <var title>B</var> is a |
| 11:14 | <annevk> | <span title=concept-tree-child>child</span> of <var title>B</var>. |
| 11:14 | <annevk> | to the participates paragraph |
| 11:15 | <annevk> | and changed the definition of root to talk about parent being null |
| 11:15 | <jgraham> | Great, thanks |
| 11:16 | <jgraham> | I guess you are right about first/last child. But the definition reads like it is circular :) |
| 11:16 | <annevk> | the definition is done for nullability |
| 11:17 | <annevk> | otherwise it would not be there |
| 11:17 | <jgraham> | Sure |
| 11:19 | <jgraham> | I guess you could explicitly say "the first child of an object is the first object in its list of child objects, or null if there is no such object", or something |
| 11:19 | <jgraham> | Also, very pedantically, you haven't defined what "null" means anywhere |
| 11:20 | <annevk> | I have not defined "object" either in that sense |
| 11:24 | <annevk> | At some point we can probably get to the point where we can have a draft that defines terminology that can be used across specifications |
| 11:24 | <annevk> | Including the very low-level nitty gritty |
| 11:24 | <jgraham> | But object can be taken as a common English word that just means "thing" |
| 11:26 | <annevk> | So null is a non-existing object? :) |
| 11:26 | <annevk> | Anyway, that problem is larger than DOM |
| 11:28 | <jgraham> | I actually don't know how to define null :) |
| 11:45 | <gsnedders> | jgraham: "null represents the absense of a value" |
| 11:46 | <gsnedders> | But really, defining terms that low-level? You may as well define a Turing machine while you're at it. |
| 11:52 | <Philip`> | null is just an opaque value that happens to be handled specially by various algorithms, and that is commonly used by unioning {null} with the set of all objects of some particular class to make a nullable type |
| 11:53 | <Philip`> | You can't define it by itself - it's defined by how other things use it |
| 11:57 | <Philip`> | gsnedders: Surely part of the point of a Turing machine is that you don't have to define it again, you can use a higher-level model that's provably equivalent to a Turing machine but much more convenient to use but still defined formally and unambiguously (i.e. not English) |
| 13:13 | <jgraham> | Philip`: Makes sense. I was thinking in terms of option types which I think is basically equivalent. |
| 13:15 | <jgraham> | gsnedders: ECMAScript manages to define "null value" and "null type", so it is clearly possible. Also we can't have TC39 being better than us ;) |
| 13:44 | <karlcow> | http://www.sewingandembroiderywarehouse.com/embtrb.htm pretty impressive |
| 14:28 | <zewt> | python does null nicely--python has no value types, so None is just an global instance of a class NoneType, and there's no magic |
| 15:37 | <annevk> | https://twitter.com/jonathan_robie/status/300629459244044288 James Clark is at XML Prague? |
| 15:39 | <annevk> | If that's true I wish I'd been there |
| 15:50 | <annevk> | I wonder why the British 2 amp 3 round pin plug is not listed on Wikipedia or is only listed as "previously" used in http://en.wikipedia.org/wiki/BS_1363#Origins referring to the forties, while clearly they are still around |
| 15:51 | <annevk> | And by clearly still around I mean I can 1) order such plugs from the internet and 2) live in an apartment that has such plugs for lights |
| 15:51 | <annevk> | s/plugs for/plug sockets for/ |
| 15:53 | <jgraham> | Woah |
| 15:55 | <jgraham> | Although maybe "just for lights" isn't so surprising? |
| 15:56 | <jgraham> | OK. Wikipedia claims that is pretty much the only current usage and is designed to prevent people attaching non-lights |
| 15:56 | <annevk> | I have current standard plugs too for home appliances and such |
| 15:56 | <jgraham> | But I don't think I have ever seen a building with such plugs for lighting |
| 15:56 | <annevk> | jgraham: did you find a different page or did I not read carefully enough? |
| 15:57 | <jgraham> | http://en.wikipedia.org/wiki/BS_546 is what I'm reading |
| 15:57 | <annevk> | Aaah |
| 15:58 | <jgraham> | (I have seen old/disused sockets from when those were still the normal plug type. Dunno if they were still connected to anything) |
| 15:59 | <annevk> | 2 A three-pin "It is sometimes still used to connect lamps to a lighting circuit." |
| 15:59 | <annevk> | That is what I have, although I'm not employing it as such now. (The central light works just fine.) |
| 16:03 | <jgraham> | So where are you living now? |
| 16:06 | <annevk> | W1, London |
| 16:13 | <zewt> | ugh |
| 16:14 | <zewt> | func.bind() breaks the location field in osx safari's events logger when attached to ios |
| 16:14 | <zewt> | which means it's something to encourage the horrible "that" pattern :| |
| 16:48 | <zewt> | joy |
| 16:48 | <zewt> | i seem to have hit a case where preventDefault on a click event has a different effect when the listener is on window than on an element, somehow |
| 16:51 | <annevk> | sounds like a bug |
| 16:51 | <zewt> | yep |
| 16:51 | <zewt> | (it's more complex than that and I'm still pretty far from really knowing what the heck is going on) |
| 17:48 | <Raymondo> | recently overheard on the interwebs: "I'm willing to bet my left nut that parser time-complexity, code size, and security bugs could be decreased by at least 30% if well-formedness were a prerequisite to rendering." |
| 17:49 | <Raymondo> | anyone have a use for a left nut? |
| 17:53 | <zewt> | strange: cancelling mousedown on inputs doesn't stop ios safari from opening the keyboard--only cancelling touchstart works |
| 17:57 | <jgraham> | Raymondo: There is very little point in noting that things could be different if the web platform were based on some entirely different technology. |
| 17:57 | <jgraham> | Certainly the HTML parser is rather complicated |
| 17:58 | <jgraham> | But if it hadn't been, maybe the platform would have failed entirely |
| 17:59 | <Raymondo> | jgraham: that was what I argued, but the rage goes on |
| 17:59 | <zewt> | jgraham: well, his point, i think, is that well-formedness has close to nothing to do with those things |
| 18:00 | <Raymondo> | zewt: that's not my point, because I don't know. but is that the case? |
| 18:02 | <jgraham> | zewt: Little to do with which things? Certianly an XML-style parser (but without all the crap that makes XML hard to parse) would avoid the kind of N**2 behaviour that you can get out of the HTML parser (and which we have to have artificial limits to prevent becoming problematic) |
| 18:02 | <zewt> | well, i didn't see "parser"--30% fewer bugs overall with a fairly superficial change would be a pretty silly claim |
| 18:03 | <jgraham> | YEah, 30% bugs overall would be wildly wrong |
| 18:03 | <jgraham> | It's not the most complicated part of the platform |
| 18:04 | <zewt> | i often suspect people who get overly caught-up in "well-formedness" are also the sort of people who compile code with -Werror |
| 18:23 | <gsnedders> | Raymondo: time-complexity certainly could be improved, and so could code-size (but it'd be irrelevantly small compared with the rest of the browser!), but security bugs? Unlikely. Beyond the parser, there's no difference between well-formed and ill-formed content, so unless there are security bugs in the parser (and I haven't seen one in a long *long* time) it gains nothing. |
| 18:24 | <Raymondo> | 'could be improved' how dramatically? |
| 18:24 | <gsnedders> | Well, from O(n^2) to O(n), I'd presume. |
| 18:24 | <gsnedders> | But note that the n is bounded, so can never exceed 5. |
| 18:25 | <gsnedders> | The time-complexity of the parser isn't a practical issue, because it is bounded. |
| 18:26 | <Raymondo> | interesting |
| 18:27 | <Raymondo> | what does being 'bounded' mean? the work still has to be done... |
| 18:27 | <gsnedders> | Code-size is obvious, because instead of having state x: do a, b, c; you have state x: goto error. |
| 18:27 | <Raymondo> | sure |
| 18:28 | <Raymondo> | at the expense of a secondary parser |
| 18:28 | <gsnedders> | Raymondo: The parser changes behaviour to be linear instead of quadratic beyond a certain point, basically. |
| 18:29 | <gsnedders> | Basically as a trade-off between retaining compatibility with existing content without making it viable to DoS the parser with a relatively small amount of input. |
| 18:30 | <Raymondo> | I probably don't know enough about this stuff to understand how that's done |
| 18:31 | <gsnedders> | Raymondo: http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#tree-construction — search for adoption |
| 18:32 | <gsnedders> | Raymondo: Note just above: "Inner loop: If inner loop counter is greater than or equal to three, then go to the next step in the overall algorithm." |
| 18:32 | <gsnedders> | That's the only quadratic part of the parser. |
| 18:32 | <gsnedders> | And that's where it breaks out if n >= 3 |
| 18:32 | <gsnedders> | Yes, it had a black-box observable effect on the parsing. |
| 18:33 | <Raymondo> | so effectively there is a well-formedness check, just for a definition of well-formed that means 'not completely irretrievably fucked up' |
| 18:34 | <gsnedders> | Basically you hit it in a case like <i><b><b><b><b><b></i> |
| 18:34 | <Raymondo> | what's the prescribed behaviour then, strip the tags? |
| 18:35 | <gsnedders> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2093 |
| 18:35 | <gsnedders> | Note how g is still within three b elements. |
| 18:36 | <gsnedders> | As opposed to being in five. |
| 18:37 | <gsnedders> | So yeah, they basically get dropped on the floor |
| 18:37 | <Raymondo> | that's actually pretty neat |
| 18:41 | <Raymondo> | thanks for taking the time :) |
| 19:20 | <gsnedders> | Today's wonder: do some people do anything but write email? |
| 19:21 | <zewt> | this ios webkit bug where setTimeout calls are just silently discarded is probably the most evil scripting bug i've seen in a long time |
| 19:22 | <zewt> | guess i'll try to monkey patch setTimeout to fix it |
| 19:23 | <zewt> | but the only workaround i know is requestAnimationFrame, which means making every setTimeout have a minimum delay of 16ms :| |
| 19:27 | <zewt> | https://gist.github.com/ronkorving/3755461 i think all of the workarounds for this are gross |
| 19:31 | <zewt> | guessing it's something dumb like "scroll_started = { saved_timers = timers; timers = []; } scroll_ended = { timers = saved_timers; }", so timers added during the scroll get wiped out |
| 19:41 | <zewt> | ... incidentally, can anyone give some explanation for the weird pass-window-into-the-function thing in that link? |
| 19:43 | <jgraham> | gsnedders: Yes, some peole do anything but write email. |
| 19:49 | <Ms2ger> | Interesting, WebKit doesn't implement the stringifier on HTMLAreaElement |
| 21:16 | <gsnedders> | jgraham: I've just given up on so many W3C mailing lists now. |
| 21:53 | <zewt> | and the least horrible workaround for horrible setTimeout bug is: proxying timeouts through a worker |
| 23:45 | <zewt> | i can't remember if i'm on my third or fourth mobile safari bug of the day |