| 01:47 | <hober> | Hixie othermaciej TabAtkins & others who are interested in this sort of thing: here's the quick first pass on the <dialog modal> CP. I'll revise it tonight & tomorrow based on feedback; feel free to email or discuss it here. http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-133 |
| 01:48 | <hober> | [or feel free to just make the CP better, for that matter; it's a wiki :)] |
| 02:13 | <othermaciej> | hober: neat |
| 02:15 | <othermaciej> | hober: I would advise against use of the diaeresis in "coordinated", this ain't the New Yorker |
| 02:17 | <othermaciej> | hober: it would be helpful to list what features of other libraries this doesn't cover |
| 02:19 | <Hixie> | hober: looks good on a first skim, i'll look more closely later if you mail me a link |
| 02:25 | <jamesr> | why is this an element and not a purely script-driven API? it doesn't look like there's any way to use this w/out script initialization, at least |
| 02:26 | <nimbu> | Hixie: I am trying to research how document outlines originated, and this is the earliest I could find a cogent reason for their existence: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011481.html Do you recall when it was originally thought of (so I can trawl archives better)? |
| 02:26 | <jamesr> | hober, what happens if .show() is invoked when the page doesn't have focus? |
| 02:26 | <Hixie> | jamesr: well you need something to display |
| 02:27 | <jamesr> | Hixie, granted, but why does it have to be a specific element? why not any block element? |
| 02:28 | <Hixie> | why bother with <section>? or <blockquote>? |
| 02:28 | <Hixie> | same reason |
| 02:28 | <Hixie> | (ease of code maintenance/readability, semantics/accessibility, ease of interpretation by search engines or other tools, etc) |
| 02:29 | <zewt> | why does page focus matter? surely this would always be tab-modal |
| 02:29 | <zewt> | (not window-modal) |
| 02:36 | <jamesr> | zewt, maybe, but hober's proposal says that "the dialog is focused when displayed" which i don't think will really be true |
| 02:36 | <jamesr> | Hixie, valid, but <section> and <blockquote> have some meaning in the document of their own |
| 02:39 | <Hixie> | so does <dialog> |
| 02:39 | <Hixie> | it means "this is going to be used for a dialog" |
| 02:41 | <Hixie> | (more importantly, maybe, it's display:none by default, so in non-CSS UAs you don't have to worry about the dialog showing when not active) |
| 02:43 | <zewt> | jamesr: well, i'd expect it to be focused within the tab, but i wouldn't expect the tab to be focused within the browser (or the browser within the windowing system), no more than tab-modal alert()s are |
| 02:44 | <zewt> | dreaming of the day all window-modal dialogs are eliminated (probably never, file pickers are hard) |
| 08:50 | <annevk> | What are we adding to DOM Core? |
| 08:50 | <annevk> | nm |
| 09:25 | <annevk> | finally removed myself from HyBi |
| 09:28 | <annevk> | AryehGregor, not having lots of hooks for the CSS box model is indeed somewhat of a pain |
| 09:29 | <annevk> | s/somewhat of// |
| 09:43 | <annevk> | It seems I want to get out of happiana too |
| 11:46 | <annevk> | can't we set an auto-reply for public-html-comments that tells people to file a bug instead? |
| 11:46 | <annevk> | the current process is somewhat annoying in that people reply to emails but then those replies do not get captured in the corresponding bug reports |
| 11:46 | <annevk> | MikeSmith, ^^ |
| 11:47 | <MikeSmith> | I guess we could, yeah |
| 11:50 | <Philip`> | Or just shut down the list and tell people to file bugs instead of telling them to post there first? |
| 11:52 | <annevk> | well yeah that would be part of it |
| 14:04 | <gsnedders> | Ms2ger: You have a testsuite for DOM Core somewhere, no? |
| 14:04 | <Ms2ger> | dvcs.w3.org/hg/webapps/DOMCore |
| 14:06 | <gsnedders> | How complete is that? |
| 14:09 | <Ms2ger> | Not at all |
| 14:09 | <Ms2ger> | More tests welcome |
| 14:27 | <gsnedders> | Ms2ger: Disclaimer: procrastination may happen. |
| 14:27 | <Ms2ger> | Same with me, so that's fine |
| 14:52 | <jarek> | Hi |
| 14:52 | <jarek> | is it possible to define custom DOM events? |
| 14:53 | <jarek> | I mean something like: "document.addEventListener('myCustomEvent', handler() {}, false)" |
| 14:53 | <jarek> | is it possible without creating wrapper function on top of document.addEventListener? |
| 14:55 | <annevk> | yes |
| 14:57 | <jarek> | annevk: what API should I be looking for? |
| 14:58 | <jarek> | I'm currently fire and assign custom events with bind() and trigger() functions, but I think in some cases it would be more elegant to use the same syntax as for core DOM events |
| 14:58 | <jarek> | s/I'm currently fire and assign/I'm currently firing and assigning |
| 14:58 | <jarek> | sorry for typos |
| 15:02 | <annevk> | you can do document.createEvent in current browsers |
| 15:02 | <annevk> | and target.dispatchEvent() |
| 15:03 | <jarek> | awesome, exactly what I needed |
| 15:30 | <jarek> | "linkElement.href" always returns absolute path while "linkElement.getAttribute('href')" may return either absolute or relative path |
| 15:30 | <jarek> | is this behavior the same on all browsers? |
| 15:33 | <jarek> | hmm... looks like it's by design as I can reproduce it on every browser |
| 15:41 | <smaug____> | jarek: getAttribute() returns the content attribute value |
| 15:41 | <smaug____> | so whatever value the attribute has |
| 15:42 | <smaug____> | .href returns what is specified in http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-href |
| 15:43 | <smaug____> | oh, hmm |
| 15:43 | <smaug____> | is there a bug in the spec |
| 15:44 | <smaug____> | no |
| 15:44 | <smaug____> | "If a reflecting IDL attribute is a DOMString attribute whose content attribute is defined to contain a URL, then on getting, the IDL attribute must resolve the value of the content attribute relative to the element and return the resulting absolute URL" |
| 15:49 | <Ms2ger> | smaug____, no bug for once? :) |
| 16:14 | <smaug____> | Ms2ger: are you hinting that I occasionally complain about bugs in the HTML spec ;) |
| 16:14 | <Ms2ger> | Perhaps once in a while ;) |
| 16:24 | <smaug____> | hmm, not much feedback to the new mutation events replacement proposal. Perhaps I should just implement it and write down how the implementation works and call it a spec. |
| 16:24 | <Ms2ger> | WFM |
| 16:25 | <Ms2ger> | Can you provide it in a format I can c&p into DOM Core? :) |
| 16:27 | <smaug____> | Ms2ger: Btw, what kind of template or some such is used for DOM Core |
| 16:27 | <Ms2ger> | Plain old HTML |
| 16:28 | <Ms2ger> | With some magic for cross-referencing |
| 16:28 | <smaug____> | so no special tools which generate right kind of HTML? |
| 16:28 | <Ms2ger> | No |
| 16:28 | <Ms2ger> | See http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.src.html |
| 16:29 | smaug____ | has used some old W3C XSLT templates which work quite ok |
| 16:29 | Ms2ger | runs for the hills |
| 16:40 | <Ms2ger> | if (document.all == null) { |
| 16:40 | <Ms2ger> | Good morning, whatwg |
| 17:51 | <Hixie> | MikeSmith: if you're doing this bug filing manually anyway, it might be worth making your script give you a way to split e-mails into one-bug-per-issue, even if it's just having it ask you how many issues, and then it filing the same bug N times with an additional comment "This is for issue 3 of 6" or whatever |
| 17:54 | <zewt> | what the |
| 17:54 | <Hixie> | what? |
| 17:54 | <zewt> | oh |
| 17:55 | <zewt> | it looked like greader changed their external links to some broken javascripty thing ... but looks like an isolated bug |
| 18:03 | <annevk> | smaug____, maybe post it as separate thread with mark 2 or v2 attached to the subject? implementing it wfm though |
| 18:07 | <annevk> | www-style should really start recommending people to post use cases instead of feature requests. I mean: "I suggest to consider six new pseudo elements for the Generated Content module, although I’m not entirely sure they would be all that useful: ..." |
| 20:00 | <Ms2ger> | Philip`, :( |
| 20:02 | krijnhuman | does foo |
| 20:02 | krijnhuman | does bar |
| 20:03 | Ms2ger | waves at krijnhuman |
| 20:03 | <krijnh> | zcorpan: color codes, apparently, turned them off now |
| 20:04 | <krijnh> | o/ Ms2ger |
| 20:11 | <jgraham> | Ms2ger: Syntax Error, expected } got EOF |
| 20:11 | <Ms2ger> | mm? |
| 20:12 | <jgraham> | You startd an if block some time ago |
| 20:12 | <Ms2ger> | I did |
| 20:12 | <Ms2ger> | } |
| 20:12 | <Ms2ger> | There you go |
| 20:12 | <jgraham> | Yay, now I can read the scrollback! |
| 20:14 | <Ms2ger> | You're welcome( |
| 20:14 | <annevk> | trololol |
| 20:14 | <gsnedders> | jgraham: You could improve your syntax error messages to note where the opening brace was. |
| 20:14 | <Ms2ger> | Better here than on public-webapps, I guess |
| 20:16 | <jgraham> | gsnedders: and kitchen design shops could provide price lists. Sadly it doesn't show any signs of happening. |
| 20:17 | <Ms2ger> | Getting settled? |
| 20:17 | <jgraham> | That remains to be seen |
| 20:18 | <gsnedders> | jgraham: Much packing left? |
| 20:18 | <jgraham> | gsnedders: Katie is insanely efficient. |
| 20:19 | <Ms2ger> | To the point where it's more efficient if you just stay out of her way? :) |
| 20:20 | <jgraham> | Erm, no comment? :) |
| 20:20 | <Ms2ger> | :) |
| 20:21 | <gsnedders> | Letting $girl do packing worked quite well when I moved a couple of months back |
| 20:22 | <jgraham> | gsnedders: Your girlfriend is variable? |
| 20:23 | <gsnedders> | jgraham: Well, I don't expect to have a single girlfriend for my entire life, so yes. |
| 20:23 | <gsnedders> | Otherwise breaking-up would be quite hard, if it had been declared as a constant. |
| 20:24 | Ms2ger | wonders if gsnedders->$girl found out about IRC logs already |
| 20:24 | <Hixie> | actually it'd be easier, you'd just overwrite the memory location where the value is kept and you'd instantly assign all previous memories to the new girl. |
| 20:24 | <jgraham> | Ah, so functional relationships are like functional languages; single assignment |
| 20:24 | <Hixie> | and the compiler would be none the wiser |
| 20:24 | <Ms2ger> | Hixie, also the reasons for breaking up? That seems suboptimal |
| 20:24 | <Hixie> | well i'm not saying it's optimal |
| 20:24 | <Hixie> | just that it wouldn't be hard |
| 20:24 | <jgraham> | (alternative worldview: functional relationships are like functional langauges: optimised for concurrency) |
| 20:24 | <gsnedders> | jgraham: in most functional langauges you don't assign per-se. |
| 20:25 | annevk | facepalms |
| 20:25 | <gsnedders> | Ms2ger: it is possible she has |
| 20:28 | <Hixie> | in other news, i have a computer with a dead disk. i can dd(1) to it all i want so long as i don't hit the bad parts, but as soon as i hit a bad bit, /dev/sda becomes completely inaccessible to any program. wtf. |
| 20:28 | <jgraham> | (I should maybe point out in the intereests of having a functional relationship that I don't subscribe to the lternative worldview) |
| 20:28 | <jgraham> | +A |
| 20:28 | <Hixie> | jgraham: ain't nothing wrong with polyamoury. |
| 20:29 | <Ms2ger> | Hixie, I await a long series of blog posts on your disk problems :) |
| 20:29 | <Hixie> | (so long as everyone involved is ok with it) |
| 20:29 | <Ms2ger> | It'll almost feel like 05 |
| 20:29 | <Hixie> | Ms2ger: it's already begun :-P |
| 20:29 | <jgraham> | Hixie: I made no moral statements |
| 20:29 | <jgraham> | (and generally agree) |
| 20:31 | <gsnedders> | ($girl = $girls->pop() then?) |
| 20:31 | <jgraham> | gsnedders: You keep your girls on a stack? |
| 20:32 | <gsnedders> | jgraham: Yes, otherwise the route needed to visit them all becomes needlessly wrong. |
| 20:32 | <gsnedders> | (wrong? long.) |
| 20:33 | jgraham | is very confused |
| 20:33 | <gsnedders> | jgraham: I make sure they are on stack in the order needed to minimise the distance to visit them sequentically |
| 20:34 | <Philip`> | It's annoying when you pop your girl and have to reinflate her |
| 20:34 | <gsnedders> | Philip`: yeah, girl v. girls is an easily made typo |
| 20:42 | <jarek> | why "blur" event fires when I click on iframe inside the window? |
| 20:43 | <jarek> | is it possible to prevent it from firing in this situation? |
| 20:47 | <jgraham> | Generally you can't stop events firing, but there is no real need to do anything with the ones you don't want |
| 20:47 | <jgraham> | Well you can preventDefault of course |
| 20:48 | <smaug____> | preventDefault() doesn't do anything with blur |
| 20:51 | <jarek> | jgraham: but I need to prevent this event only when iframe inside window is clicked, not when window loses focus to some other window |
| 20:51 | <jarek> | I have no idea how to do this |
| 20:51 | <jarek> | as blur event does not provide any information about what causes the blur |
| 20:55 | <jgraham> | jarek: I'm not sure what you are trying to do, but I don't think you can do what you are requesting |
| 20:56 | <jgraham> | Fun game: Read http://blog.n01se.net/?p=375 and work out how many of the listed specs are at W3C. Then subtract the ones that were imported wholesale into the W3C without changes |
| 20:56 | <jgraham> | (or almost without changes) |