| 03:00 | <mpilgrim> | gsnedders: http://gsnedders.html5.org/outliner/process.py gives a traceback upon uploading basically any HTML file |
| 03:01 | <mpilgrim> | i promised a guy last october that i would tell you, so i have now fulfilled my promise |
| 03:09 | <Dashiva> | Faster turnaround than most bug reporting systems |
| 03:13 | <gsnedders> | mpilgrim: Yeah, I've since last August or so about that bug. :) |
| 03:13 | <gsnedders> | *I've known |
| 03:14 | <zewt> | usual result of most bug reporting systems too, then :P |
| 03:16 | <zewt> | better than getting no response, then two years later getting a mass batch update saying "please re-test this bug from scratch or it'll be closed in a week", which seems to be the more common result of open trackers nowadays |
| 04:45 | <bga_> | http://www.bitcoin.org/smf/index.php?action=printpage;topic=252.0 |
| 11:13 | <jgraham> | https://github.com/msporny/dna/ |
| 11:15 | <annevk> | from DOM3Events |
| 11:15 | <Philip`> | https://github.com/msporny/dna/network |
| 11:15 | <annevk> | " |
| 11:15 | <annevk> | As the final step of the event dispatch, for reasons of backwards compatibility, the implementation must reset the event object's internal-propagation and default-action-prevention states. This ensures that an event object may be properly dispatched multiple times while also allowing to prevent the event objects propagation or default actions prior to the event dispatch." |
| 11:16 | <annevk> | shouldn't that happen before dispatching? |
| 11:16 | <annevk> | otherwise the defaultPrevented attribute would be affected |
| 11:16 | <annevk> | which seems like something you do not want happening |
| 11:16 | <annevk> | i was also wondering |
| 11:17 | <annevk> | if you dispatch an event from an event |
| 11:17 | <annevk> | when exactly do you get that event back in script |
| 11:18 | <annevk> | is "dispatching an event" a single atomic operation even though it can effect itself? (e.g. by removing event listeners) |
| 11:20 | <annevk> | nothing much in the "events loop" section about this |
| 11:20 | <annevk> | I guess I should write some code to figure it out |
| 11:25 | <annevk> | yeah |
| 11:25 | <annevk> | so http://software.hixie.ch/utilities/js/live-dom-viewer/saved/835 shows it is not an atomic operation |
| 11:25 | <annevk> | (once you click on the dots) |
| 11:26 | <annevk> | on the other hand, I guess it makes sense and does not require any special wording... |
| 11:31 | <annevk> | it's "simply" an atomic operation that invoke itself again |
| 11:31 | <annevk> | or something like that |
| 15:35 | <annevk> | back home, time to relax :) |
| 15:35 | <annevk> | and work on this event stuff some more I guess |
| 15:44 | <annevk> | even what is sort of defined in DOM3Events is not really implemented |
| 15:52 | <annevk> | Gecko throws for initEvent while that is not allowed |
| 15:52 | <annevk> | in Opera invoking initEvent for an event that is being dispatched calls stop propagation somehow on it |
| 15:52 | <annevk> | or something like that |
| 15:53 | <annevk> | I think I will try to go for something "sensible" instead... |
| 15:54 | <annevk> | no modifications allowed while dispatching and no dispatching of an event that is already being dispatched |
| 15:54 | <annevk> | based on a "is dispatching flag" |
| 15:55 | <annevk> | I'll also make the change that allows the empty string as event name, makes everything simpler :) |
| 16:03 | <annevk> | btw, I had this sort of crazy idea for simpler event creation |
| 16:03 | <annevk> | overload createEvent |
| 16:03 | <annevk> | createEvent would accept an arbitrary number of arguments, and what they represent depends on the string passed to the first |
| 16:04 | <annevk> | so you could do e.g. document.createEvent("Event", "test", false, true) |
| 16:04 | <annevk> | first it creates the event and then calls initEvent with the remaining arguments |
| 16:04 | <annevk> | but maybe the first simplification should be to make initEvent arguments optional |
| 16:05 | <annevk> | so you don't have to pass false/false all the time if you don't want to |
| 16:16 | <annevk> | smaug____, you okay with shuffling the details of non-interoperable parts of DOM Events? |
| 16:17 | <annevk> | smaug____, trying to figure out how Events work for DOM Core and it seems DOM3Events does not really match reality when it comes to the finer details of event creation, initialization, and dispatching |
| 16:17 | <smaug____> | annevk: kind of busy with other things atm |
| 16:18 | <annevk> | I'll just carry on then and hope you have time to review it some day |
| 16:18 | <smaug____> | I could review later today or tomorrow |
| 16:19 | <annevk> | tomorrow during the day might be nice (you're still in Europe right?) that way I can help out and address issues directly |
| 16:20 | <smaug____> | still in Finland yes |
| 16:21 | <smaug____> | and tomorrow day should be ok |
| 16:22 | <annevk> | cool |
| 16:43 | <dglazkov|away> | text-overflow-mode: hidden |
| 16:55 | <annevk> | hmm |
| 16:56 | <annevk> | capture listeners also include AT_TARGET |
| 16:56 | <annevk> | so if you have a single listener attached for both capture and non-capture it'll fire twice during AT_TARGET |
| 17:06 | <annevk> | well, when the target happens to be the node you registered the listener on |
| 17:28 | <annevk> | hmm |
| 17:28 | <annevk> | if you say inherits |
| 17:28 | <annevk> | does that include indirect inheritance? |
| 17:29 | <annevk> | interface a : b |
| 17:29 | <annevk> | interface c : a |
| 17:29 | <annevk> | can you say that c inherits from b? |
| 17:29 | annevk | tries to define createEvent |
| 17:30 | annevk | is going with yes |
| 17:37 | <annevk> | hmm, in WebKit createEvent is case-sensitive |
| 17:37 | <annevk> | they do support "Events" |
| 17:37 | <annevk> | but not "events" |
| 17:38 | <annevk> | and "HTMLEvents" but not "htmlevents" |
| 17:38 | <annevk> | weird |
| 17:38 | <annevk> | I guess we can still make it case-sensitive then if someone really cared |
| 17:45 | <annevk> | hmm I guess before people review Ms2ger needs to come online and regen the spec |
| 17:47 | <annevk> | oh hey, dispatchEvent returns a boolean about canceled behavior; didn't even realize that but it matches the spec's model :) |
| 18:00 | <annevk> | teehee |
| 18:00 | <deane> | annevk: Hi, I'm using latest version of Opera for my irc client, real nice. Congratulations, You and the team have done a great job with the Opera browser, real nice, keep up the good work :) |
| 18:00 | <annevk> | preventDefault/defaultPrevented and the return value of dispatchEvent are quite the mess |
| 18:00 | deane | let's annevk get back to his work |
| 18:00 | <annevk> | deane, heh, thanks |
| 18:01 | <annevk> | I'm mostly playing around and writing down my conclusions :) |
| 18:02 | <annevk> | if you have a non-cancelable event |
| 18:02 | <annevk> | and you call preventDefault on it |
| 18:02 | <annevk> | and then you check defaultPrevented and the return value of dispatchEvent |
| 18:03 | <annevk> | in Opera: true / false |
| 18:03 | <annevk> | in WebKit: false / true |
| 18:03 | <annevk> | in Gecko: undefined / true |
| 18:03 | <annevk> | I was expecting false / false |
| 18:04 | <annevk> | I mean, if you can't prevent the default (it's non-cancelable), why would any of these indicate otherwise? |
| 18:04 | <nimbupani> | Annevk dont miss ur flight plotting prevent defaults!!! |
| 18:04 | <annevk> | heh, thanks, I'm already back :) |
| 18:04 | <nimbupani> | Wattttt oki |
| 18:05 | <annevk> | you can tell by the gap in the irc-logs when it was :) |
| 18:05 | <annevk> | jumps from 12 to 16 somewhere (OSL airport -> home) |
| 18:06 | <nimbupani> | Hahahahah not sure if its a good thing or bad thing |
| 18:06 | <nimbupani> | Imagine 4 months of such a gap |
| 18:06 | <annevk> | hehe, i'll find out soon enough |
| 18:06 | <nimbupani> | PANDEMONIUM |
| 18:07 | <annevk> | Pet Shop Boys! |
| 18:08 | <deane> | yeah, Pet Shop Boys are cool ;) |
| 18:13 | <nimbupani> | >_> |
| 18:15 | <deane> | annevk: so you don't get a username-style bug report with opera, it's just anonymous? https://bugs.opera.com/wizard/ |
| 18:15 | <annevk> | yeah |
| 18:15 | deane | forgot the question mark :/ |
| 18:15 | <annevk> | I think there's a volunteer who keeps public records of bugs people filed |
| 18:16 | <annevk> | and I can give you a status update most of the time, but it's not exactly ideal |
| 18:16 | <annevk> | (you get a bug number once you file a bug) |
| 18:17 | <deane> | sweet, just noticed something minor. I'll take a screen shot and file a report later today |
| 18:18 | <MikeSmith> | hmm, "If the document contains a meta element with an http-equiv attribute in the Encoding declaration state, then the document must not contain a meta element with the charset attribute present." |
| 18:21 | <MikeSmith> | that would seem to mean if a <meta charset> occurs in document order before a <meta http-equiv="content-type"…> encoding declaration, then the <meta charset> should be reported as an error |
| 18:21 | <MikeSmith> | which seems wrong |
| 18:22 | <MikeSmith> | UAs use the first one of those they find in document order, right? |
| 18:22 | <annevk> | it doesn't say anything about order there |
| 18:22 | <annevk> | it just says they're mutually exclusive |
| 18:23 | <MikeSmith> | yeah, I know it doesn't mention document order, but that's the case I care about |
| 18:24 | <annevk> | maybe it should be reworded that if either is present the other cannot be |
| 18:24 | <MikeSmith> | yeah |
| 18:25 | <annevk> | or maybe it should be phrased the other way around |
| 18:25 | <annevk> | to encourage people using <meta charset> |
| 18:25 | <MikeSmith> | yeah |
| 18:26 | <MikeSmith> | it also doesn't say its an error to have multiple instances of <meta http-equiv="content-type"…> encoding declarations |
| 18:28 | <MikeSmith> | oh |
| 18:28 | <MikeSmith> | sweet |
| 18:28 | <MikeSmith> | http://dev.w3.org/html5/spec/semantics.html#character-encoding-declaration |
| 18:28 | <MikeSmith> | "There can only be one character encoding declaration in the document." |
| 18:28 | <MikeSmith> | hmm |
| 18:28 | <MikeSmith> | or maybe not |
| 18:29 | <MikeSmith> | that's not a normative statement |
| 18:29 | <MikeSmith> | which is exactly the point Philip` was making in http://bugzilla.validator.nu/show_bug.cgi?id=589#c1 |
| 18:29 | <MikeSmith> | *sigh* |
| 18:31 | <MikeSmith> | hmm, but the spec does prefix the bulleted list that statement is in with "The following restrictions apply to character encoding declarations:" |
| 18:32 | <MikeSmith> | guess I should file a bug |
| 18:45 | <Philip`> | MikeSmith: If the spec says that if you have <meta charset> you mustn't have <meta content-type>, that doesn't imply the validator has to complain about the <meta content-type> |
| 18:46 | <Philip`> | The document as a whole is invalid and it's the validator's job to point out to authors how best to fix their document |
| 18:46 | <Philip`> | so I wouldn't think the spec needs to change its phrasing |
| 18:47 | <annevk> | damnit |
| 18:47 | <annevk> | why does <var> cause a link |
| 18:47 | annevk | summons Ms2ger |
| 18:48 | <AryehGregor> | <var> always causes a link unless you do <var title>. |
| 18:49 | <annevk> | that should really be disabled |
| 18:49 | <AryehGregor> | Yeah, not sure why you'd want <var> to link. |
| 18:50 | <annevk> | I defined the whole cancelable events in the way that makes most sense to me; given the non-interop I suspect this will be fine |
| 18:50 | <annevk> | I think I defined all of the basic interfaces now |
| 18:51 | <MikeSmith> | Philip`: so what would you suggest it should report? |
| 18:51 | <annevk> | guess I'll add CustomEvent as well |
| 18:52 | <annevk> | and then I guess is the rathole that is mutation events |
| 18:52 | <annevk> | and event loops if we are going to make them asynchronous |
| 18:52 | <MikeSmith> | Philip`: UAs use the first character encoding declaration they find and ignore the rest, right? |
| 18:53 | <MikeSmith> | hmm, I guess that's undefined |
| 18:54 | <Philip`> | MikeSmith: I guess it would ideally report a single error pointing to all the encoding declarations and say there should only be one and suggest using <meta charset="{whatever the parser's determined charset was}"> |
| 18:54 | <MikeSmith> | heh |
| 18:55 | <MikeSmith> | "pointing to all the encoding declarations" |
| 18:55 | <MikeSmith> | thing is, we can't really do that |
| 18:56 | <Philip`> | It's not my problem if the validator's designed with the inflexible assumption of a 1:1 correspondence between errors and markup ranges :-) |
| 18:56 | <MikeSmith> | or we could but it would require creating a new mechanism for reporting multiple line numbers and column numbers in a single error message, just for this one case |
| 18:57 | <MikeSmith> | Philip`: it's not an assumption, it's a pragmatic design choice that works well for the vast majority of cases :) |
| 18:57 | <MikeSmith> | but point taken |
| 18:57 | <Philip`> | Browsers should use the first declaration - the parser handles meta elements and if the encoding's currently tentative it sets it to certain |
| 18:58 | <Philip`> | so it'll ignore subsequent declarations |
| 18:58 | <MikeSmith> | OK |
| 18:58 | <Philip`> | (I think) |
| 18:58 | <MikeSmith> | it not specified that way in the spec at least |
| 18:58 | <MikeSmith> | intentionally not, I would assume |
| 18:59 | <MikeSmith> | oh, or maybe it is |
| 18:59 | <Philip`> | See http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html / "A start tag whose tag name is "meta"" |
| 18:59 | <MikeSmith> | I need to read the parsing algorithm |
| 18:59 | <MikeSmith> | yeah |
| 18:59 | <Philip`> | Kind of hard to find if you don't already know that's where the feature is defined :-( |
| 19:11 | <annevk> | defining CustomEvent took 20 min per Mercurial |
| 19:12 | <annevk> | but it still needs examples and green boxes and such |
| 19:12 | <annevk> | like everything else... |
| 19:15 | <annevk> | A, B, and C or D and E |
| 19:16 | <annevk> | the condition is true for ABC or ABDE |
| 19:16 | <annevk> | is the sentence correct? |
| 19:19 | <Dashiva> | That needs to be more than one sentence |
| 19:20 | <annevk> | A and B. As well as C or D and E |
| 19:20 | <annevk> | does that work? |
| 19:21 | <Hixie> | use a bulleted list |
| 19:21 | <Hixie> | with a nested list for the or |
| 19:23 | <annevk> | the sentence is |
| 19:23 | <annevk> | whose |
| 19:23 | <annevk> | <b>name</b> is <var>name</var>, <b>listener</b> is <var>listener</var>, and |
| 19:23 | <annevk> | <var>capture</var> is <b>capture</b> or <var>capture</var> is omitted and <b>capture</b> is false, |
| 19:24 | <annevk> | seems kind of overkill to go for a list |
| 19:25 | <annevk> | if Web IDL had some way to say what the default (if any) was for omitted arguments this prose would not be needed |
| 19:28 | <Dashiva> | There should definitely be an "and either" |
| 19:29 | <annevk> | made it consistent with what I have for addEventListener even though it seems somewhat overkill |
| 19:36 | <annevk> | tomorrow I'll introduce something that can replace "Firing a simple event named e" in HTML |
| 19:37 | <annevk> | because however early, I need some sleep :) |
| 20:19 | <AryehGregor> | So I've got a sort of working testharness.js version of my tests: http://dvcs.w3.org/hg/html/raw-file/tip/tests/submission/AryehGregor/reflection/reflection-onepage.html |
| 20:19 | <AryehGregor> | Actually not much slower than my original one. |
| 20:19 | <AryehGregor> | But it's not really using them as intended, I think. |
| 20:19 | <AryehGregor> | Like, I'm running tests conditionally. |
| 20:19 | <AryehGregor> | Oh well, it's a start. |
| 20:35 | <AryehGregor> | Hixie, it occurs to me that if execCommand() will be defined in the W3C's copy of HTML5 and normatively references DOM Range, DOM Range will need to be someplace in W3C space. |
| 20:36 | <AryehGregor> | Apparently that's happening, though, so no worries. |
| 20:36 | <Hixie> | i encourage you to not worry about w3c bureaucracy :-) |
| 20:36 | <Hixie> | if w3c cares, they'll fix it. if they don't, doesn't matter, we'll just spec it elsewhere. |
| 20:37 | <Hixie> | right now the html5 spec at w3c references html5.org for dom range |
| 20:37 | <AryehGregor> | Oh, and you get away with that. No problem, then. |
| 20:39 | <Hixie> | the w3c copy is only important for patent protection issues, and we won't get that for a decade or so at the current rate anyway |
| 20:39 | <Hixie> | so... |
| 20:39 | <AryehGregor> | It's also important if you want Microsoft to pay attention, particularly to test suites submitted to the W3C HTML test suite vs. anywhere else. |
| 20:40 | <Hixie> | it's a myth that microsoft only pays attention to w3c (one that they are happy to have be believed) |
| 20:41 | <Hixie> | they'll implement whatever they need to implement to get interop with what their customers say they need |
| 20:41 | <Hixie> | e.g. microsoft's blogging software implements pingback, which is just a spec on hixie.ch |
| 20:42 | <Hixie> | similarly the IE team pays attention to the acid tests |
| 21:58 | <key> | hey guys, i've spent a few days trying to solve this issue and the ppl in #css/#html5 are stuck too.. maybe some html/css genius in here can do it: http://www.pastie.org/private/xo1w15miulgzf3ho9oya |
| 21:58 | <key> | basically i just need the sub menu lower and left aligned to the main menu regardless of which main menu LI the sub menu UL is attached to |
| 22:00 | <aho> | key, wrong channel |
| 22:00 | <key> | only douches in here? |
| 22:00 | <aho> | today's youth |
| 22:00 | <aho> | *shrug* |
| 22:00 | <zewt> | also yesterday's youth and tomorrow's youth |
| 22:01 | <aho> | :> |
| 22:01 | <zewt> | the only thing special about today's youth is they happen to be the ones you'll see ... today |
| 22:02 | <aho> | zewt, it was just an empty "get off my lawn" phrase. it was entirely meaningless :> |
| 22:03 | <zewt> | don't worry, i'm sitting on the porch shaking my fist at those damned kids too :P |
| 22:04 | <annevk> | so I'm still awake and apparently Ms2ger needs not be summoned to IRC for regenerating the spec |
| 22:04 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events |
| 22:07 | <zewt> | seems sort of odd that "propagation flag" and "immediate propagation flag" seem more like "stop propagation flag" ... as if the values are reversed |
| 22:08 | <annevk> | hmm yeah |
| 22:08 | <annevk> | I wanted to shorten their length but that does not make it clearer indeed |
| 22:09 | <zewt> | just flip the booleans? maybe given their purpose that would be odd (since they would be inverted from "canceled flag") |
| 22:10 | <annevk> | no I am adding stop back in |
| 22:11 | <annevk> | you want to be in the list of acknowledgments as "zewt" or some other name? |
| 22:11 | <zewt> | The timeStamp attribute must be useless. |
| 22:11 | <zewt> | heh |
| 22:12 | <zewt> | Glenn Maynard |
| 22:12 | <annevk> | aha |
| 22:13 | <zewt> | i've wished the timeStamp attribute worked in the past ... when doing things like emulating double-clicks from mouse (actually, touch) events |
| 22:13 | <zewt> | guess it's just too far outside of browser event models to be able to do that reasonably |
| 22:16 | <annevk> | I think the way it works in Gecko enables that |
| 22:16 | <annevk> | not really sure how to define it yet |
| 22:16 | <annevk> | I wouldn't mind dropping it or having it always return 0 like in Opera, but that's not really the most useful |
| 22:29 | <zewt> | "Because createEvent() is located on the Document object it cannot be used by Web Workers." hmm ... although it clearly amtters less in workers (without the DOM, the more complex uses of events go away anyway), it does seem like an odd missing piece, given that events are still used; no particular use cases come to mind off-hand, though (possibly just due to not having used workers in complex enough ways yet) |
| 22:30 | <Yuhong> | Now that WHATWG HTML is versionless, the W3C copy is the only thing that can be referred to as "HTML5", ending confusion. |
| 22:30 | <Yuhong> | And making the relationship between the two very clear. |
| 22:32 | <Yuhong> | annevk: It is sad that your blog don't have comments. |
| 22:33 | <annevk> | I saw your tweet... I don't really want to have to maintain such discussions anymore. |
| 22:34 | <annevk> | But this is the web, you do not have to be constrained with what I am offering on my site ;) |
| 22:35 | <Yuhong> | annevk: Except that as it happened, IE9 went RC around that time. |
| 22:40 | <Yuhong> | annevk: To summarize: IE stagnated for five years, then it took another five years for it to finally implement XHTML! |
| 22:40 | <zewt> | am I the only person that keeps trying to define javascript functions as "var func() { }"? it's an instinct I just can't override, heh |
| 22:49 | <zewt> | "The list of event listeners can be manipulated while event listeners are being run." a bit vague--will the particulars of that be specified? |
| 22:50 | <annevk> | zewt, it's just a statement of fact |
| 22:50 | <annevk> | addEventListener and removeEventListener already define how the list is manipulated |
| 22:50 | <annevk> | the rest is just going through a live list |
| 22:52 | <zewt> | well, it seems that event handlers added during dispatch aren't being called, but ones removed also aren't (that is, removals during invocation are honored, but additions aren't) ... trying to see if that behavior is defined by the spec |
| 22:53 | <annevk> | that is not |
| 22:55 | <annevk> | hmm yeah |
| 22:55 | <zewt> | it could be: define step 4 of invocation as operating on a copy of the event handler list, and have removeEventListener mark the event listener unused (for example, set its name to null, so 4.3 always terminates) |
| 22:57 | <annevk> | you can dispatch empty string events but yeah, something like that might work |
| 22:58 | <zewt> | that would also avoid any ambiguity if, for example, an event handler is removed from the list then re-added in the same event |
| 23:00 | <annevk> | it would not be triggered then right? |
| 23:00 | <zewt> | right |
| 23:00 | <zewt> | since logically it's a new listener |
| 23:00 | <annevk> | so for nodes this is per "current target" I assume? |
| 23:01 | <annevk> | that is, a current target can manipulate the listeners for the next current target as pleased |
| 23:01 | <zewt> | right ... i havn't checked that part of browser behavior though |
| 23:04 | <zewt> | http://pastebin.com/kzscSk01 clicking text alerts in Opera but not FF3.6 or Chrome |
| 23:06 | <zewt> | http://pastebin.com/ZTRw2iga same results when removing and adding in the same handler |
| 23:06 | <annevk> | so Opera has the DOM3Events behavior of having a static copy |
| 23:07 | <annevk> | whoa, so adding it again marks it "used" or some such? |
| 23:07 | <annevk> | in Gecko/WebKit |
| 23:07 | <annevk> | hmm, I should try sleeping again and maybe play with IEs implementation tomorrow |
| 23:08 | <zewt> | i imagine that removing it marks the listener as "dead", and adding it later adds an entirely new listener |
| 23:08 | <annevk> | oh right, see, I'm tired |
| 23:08 | <zewt> | which was what I was going for above with the notion of clearing "name" (which was just a shorthand hack, of course, should be a named property or something in a spec) |
| 23:10 | <annevk> | fun stuff |
| 23:13 | <zewt> | re: manipulating listeners the next ancestor target, yes in all of those browsers: http://pastebin.com/NEdKDMHT |
| 23:13 | <annevk> | thanks man |
| 23:14 | <annevk> | I wonder if Opera has any bugs filed against it for having a completely static list |
| 23:14 | <annevk> | and what IE does |
| 23:15 | <annevk> | not having to add a "dead flag" might be nice |
| 23:15 | <zewt> | did you do the work boiling down the dispatch/invocation rules? because that's pretty well done |
| 23:15 | <annevk> | anyway, sleep |
| 23:15 | <annevk> | yeah, you can see how i went about it here: https://bitbucket.org/ms2ger/web-dom-core |
| 23:16 | <zewt> | later, go to sleep before you get dragged into something else, that's what IRC does :P |
| 23:16 | <annevk> | heh :) |