| 00:34 | <Yuhong> | Personally I consider "HTML5" even as a buzzword a misnomer nowadays. |
| 00:36 | <Yuhong> | How many people using the buzzword know for example that canvas dates back to 2005? |
| 00:45 | <Yuhong> | Personally, I hope this can be finished: http://www.w3.org/wiki/Evolution |
| 00:46 | <Yuhong> | It will be helpful in proving the W3C process is flawed. |
| 00:47 | <Yuhong> | Hopefully, the TAG elections will get the right people in and help get this finished. |
| 00:49 | <Hixie> | if the people in question don't have time to update it now, why would they have time to update it after joining the mailing list and getting more mail than they do now? |
| 00:55 | <Yuhong> | Hixie: http://logbot.glob.com.au/?c=freenode%23whatwg&s=dec+31+2012&e=4+Jan+2013#c759102 |
| 01:01 | <Yuhong> | Unrelated, but in case you didn't see it. |
| 02:46 | <rniwa> | any mozilla folks here? |
| 02:47 | <rniwa> | ideally someone working on css. |
| 02:49 | <heycam> | rniwa, I can try to help |
| 02:49 | <rniwa> | heycam: hi! |
| 02:49 | <heycam> | hey |
| 02:49 | <rniwa> | heycam: do you know if mozilla has any tests for CSS calc? |
| 02:49 | <heycam> | rniwa, we ought to |
| 02:49 | <rniwa> | heycam: if so, if you guys are planning to upstream those tests to W3C? |
| 02:49 | <rniwa> | heycam: i've checked http://test.csswg.org/source/contributors/mozilla/submitted/ but i don't see any tests there. |
| 02:50 | <rniwa> | heycam: mikelawther from google is implementing css calc in webkit |
| 02:50 | <heycam> | rniwa, people have been writing new tests in an upstreamable form, but I don't know if we have concrete plans to upstream existing tests |
| 02:50 | <heycam> | although it would be nice to |
| 02:50 | <rniwa> | heycam: and we would like to be abel to import your tests. |
| 02:50 | <rniwa> | heycam: ah, i see. |
| 02:50 | <heycam> | oh yes I met mikelawther at LCA last year |
| 02:50 | <rniwa> | heycam: cool :) |
| 02:50 | <heycam> | let me take a look at the existing tests |
| 02:50 | <rniwa> | heycam: could you keep him in the loop about your upstream effort? |
| 02:51 | <heycam> | to see how easy they would be to upstream |
| 02:51 | <heycam> | they are here btw: https://hg.mozilla.org/mozilla-central/file/tip/layout/reftests/css-calc/ |
| 02:54 | <heycam> | rniwa, those tests seem reasonable self contained, so I think they shouldn't be hard to upstream |
| 03:00 | <rniwa> | heycam: great. |
| 03:00 | <rniwa> | heycam: is there any Bugzilla bug filed anywhere regards to this? |
| 03:00 | <heycam> | just filed one |
| 03:00 | <heycam> | and CCed you |
| 03:00 | <rniwa> | heycam: thanks. |
| 03:00 | <rniwa> | heycam: oh |
| 03:00 | <heycam> | couldn't find mike as a bugzilla user there though |
| 03:01 | <rniwa> | heycam: yeah. |
| 03:01 | <rniwa> | heycam: i don't think he has Mozilla bug account. |
| 03:01 | rniwa | waits for an email :) |
| 03:01 | <rniwa> | heycam: thanks a lot for the help. |
| 03:01 | <heycam> | no problem! |
| 13:00 | <annevk> | Hixie: ah yeah, I abuse @WHATWG now and then |
| 13:02 | <annevk> | Hixie: my excuse has been that the idea was that it could be used for whatever, but maybe we should keep it scoped nowadays |
| 16:01 | <annevk> | Man... I'm almost done with annotating parse errors... |
| 16:01 | <annevk> | No fun was had |
| 17:59 | <Hixie> | annevk: i don't have any problem with you abusing @whatwg, i trust your judgement |
| 18:00 | <Hixie> | annevk: i can't help but wonder how many of @whatwg's subscribers really care about the TAG though :-) |
| 18:00 | <Hixie> | then again, i'm baffled by why _you_ care, so... :-P |
| 20:17 | <Hixie> | hey bruce is asking me what my biggest mistake was for some article he's writing -- anyone got any suggestions? (i've already listed pushState, appcache, postMessage()'s security model...) |
| 20:18 | <Ms2ger> | Margin collapsing? |
| 20:18 | <Ms2ger> | The HTMLWG? |
| 20:18 | <WeirdAl> | Hixie - listening to developers for Acid 3 tests? |
| 20:18 | WeirdAl | being one of those idiot developers |
| 20:18 | <Hixie> | ooh, hadn't tought about margin collapsing and acid3, i was focused on the spec |
| 20:19 | <Ms2ger> | Acid2 and <p><table> |
| 20:23 | <Hixie> | I actually think <p><table> is fine, personally, but yeah, the acid tests in general |
| 20:24 | <Ms2ger> | You think the one quirk in the parser is fine?! :) |
| 20:24 | <annevk> | Hixie: localStorage? |
| 20:24 | <WeirdAl> | compared to the horrors that the acid tests required, Ms2ger? Yeah. |
| 20:24 | <Hixie> | i think the quirk sucks, but i think not implying </p> at <table> is what sucks, not the fact that we have a quirk so much :-) |
| 20:25 | <Ms2ger> | Oh, SVG fonts |
| 20:25 | <Hixie> | annevk: oh yeah, the storage mutex, good call |
| 20:25 | <annevk> | Hixie did not do SVG fonts :-) |
| 20:25 | <Hixie> | i did in acid3 |
| 20:25 | <annevk> | ooh |
| 20:25 | <annevk> | Hixie: SGML comments ;-) |
| 20:25 | <Hixie> | was that acid2 or 3? |
| 20:25 | <Ms2ger> | Oh man |
| 20:25 | <Hixie> | 2, rigt? |
| 20:25 | <annevk> | yeah |
| 20:25 | <Ms2ger> | 2, I think |
| 20:27 | <annevk> | ah, Ms2ger had margin collapsing :) |
| 20:27 | <annevk> | That's a long list, why do we trust this guy again? |
| 20:27 | <Hixie> | nobody else is willing to do it? |
| 20:27 | <Ms2ger> | Why, prefer the CSSWG? |
| 20:28 | <annevk> | Ms2ger: uhuh |
| 20:31 | <annevk> | looking forward to reading that |
| 20:31 | <annevk> | Hixie: I guess that's part of it; would be so great to have actual competition rather than a copy & paste lobby |
| 21:47 | <annevk> | MikeSmith: what does https://twitter.com/katoken0215/status/287224151620587520 say? |
| 21:52 | <zewt> | that you're a woman, for starters... |
| 21:53 | <annevk> | whoa |
| 21:54 | <annevk> | TR/domcore looks ugly |
| 21:54 | <annevk> | dglazkov: please link to dom.spec.whatwg.org instead from the Shadow DOM spec |
| 21:56 | <annevk> | dglazkov: when does redistribution happen? how is this represented in implementations? is the DOM sprinkled with special nodes? |
| 21:57 | <annevk> | zewt: if that's all it says it's not very interesting |
| 22:12 | <zewt> | annevk: describing what you said in your last post, i think |
| 22:13 | <annevk> | New Zealand though? |
| 22:20 | <zewt> | annevk: apparently he thought you were a european woman |
| 22:21 | <zewt> | https://twitter.com/katoken0215/status/287320663876833280 |
| 22:21 | <zewt> | (he deleted the last one, heh) |
| 22:23 | <yroc> | Hi, wondering why the leading newline following an opening <pre> tag is stripped... |
| 22:23 | <yroc> | Is it to prevent the opening <pre> tag from displacing the initial line of preformatted text. |
| 22:25 | <annevk> | yroc: legacy thing from SGML iirc |
| 22:26 | <annevk> | yroc: http://www.w3.org/TR/html401/appendix/notes.html#notes-line-breaks |
| 22:26 | <annevk> | wycats_: you around? |
| 22:30 | <annevk> | Anyone else know if it gets any better than http://api.jquery.com/on/ ? |
| 22:31 | <annevk> | whoa |
| 22:31 | <annevk> | http://zeptojs.com/ document.write is still recommended anno 2012 |
| 22:32 | <yroc> | annevk: Right. And now, with the white-space processing model, *all* newlines are ignored when white-space: normal; |
| 22:32 | <annevk> | yroc: right, so the quirk is only kept for <pre> and <textarea>, where it's observable |
| 22:32 | <annevk> | well, more directly observable |
| 22:32 | <yroc> | Exactly, where white-space: pre; |
| 22:33 | <yroc> | annevk: But *why* is the quirk kept? |
| 22:33 | <annevk> | yroc: because otherwise sites will render differently |
| 22:33 | <zewt> | the opposite of "on()" is "off()"? really? heh |
| 22:34 | <annevk> | zewt: I wonder if that's actually used |
| 22:34 | <yroc> | annevk: if the initial newline following <pre> were not stripped, sites would render differently? |
| 22:35 | <annevk> | yroc: right |
| 22:35 | <yroc> | Uh, can you give an example? |
| 22:35 | <annevk> | yroc: you would get a blank line |
| 22:36 | <yroc> | Oh, I see what you mean. I thought you meant different browsers would render differently (an interop problem). Yes, exactly, you'd get a blank line |
| 22:36 | <annevk> | yroc: http://www.w3.org/TR/CSS21/text.html seems to rely on it for instance |
| 22:37 | <annevk> | yroc: well we don't want to remove it because then you'd get an interop problem |
| 22:37 | <annevk> | yroc: and we'd break sites |
| 22:38 | <zewt> | annevk: doesn't look like it's actually a very nice interface (off(), i mean) |
| 22:38 | <yroc> | yroc: but isn't it a useful thing to keep? Doesn't it allow you to start the first line of preformatted text on a "fresh" line without the starting <pre> tag displacing the content? |
| 22:38 | <annevk> | zewt: I agree, I'm open to suggestions |
| 22:38 | <zewt> | since you still have to have a reference to the listener function, so it has the same problems as addEventListener(x, func.bind(something)) |
| 22:38 | <yroc> | Oops, I meant annevk! |
| 22:39 | <annevk> | yroc: it's being kept |
| 22:39 | <zewt> | nicer to return an object representing the observation, eg. x = event.addEventListener(...); x.remove(); |
| 22:39 | <zewt> | i seem to recall prototype has something like that (been a while though) |
| 22:39 | <annevk> | with s/event/element/? |
| 22:40 | <zewt> | yeah |
| 22:40 | <annevk> | we also have the setInterval API we could mimic... |
| 22:40 | <zewt> | http://prototypejs.org/doc/latest/dom/Event/on/index.html |
| 22:40 | <yroc> | annevk: Yes, I know, but I'm just saying there's a good reason, which I'm trying to nail down (for example, "without this behavior, you'd get an undesirable blank line at the beginning of your preformatted content." |
| 22:41 | <yroc> | annevk: Would you say that's the true reason? |
| 22:41 | <annevk> | zewt: could you add that to https://www.w3.org/Bugs/Public/show_bug.cgi?id=16491 perhaps? I guess I'm gonna try to make some progress on that bug. It's been well over a year now... |
| 22:41 | <zewt> | these days i just pre-bind my event handlers (this.click_handler = this.click_handler.bind(this)), which is a little wordy but works fine in practice |
| 22:42 | <zewt> | not at home, i'll add it if i remember when i get back |
| 22:44 | <zewt> | lack of a capture argument to all of those apis is also annoying |
| 22:51 | <annevk> | well if nobody is using that... |
| 22:52 | <annevk> | we can do all kinds of things, e.g. make all events bubble for the purposes of this new API |
| 22:52 | <annevk> | I actually thought jQuery did that, but that page does not describe that behavior |
| 22:54 | <annevk> | http://prototypejs.org/doc/latest/dom/Event/Handler/new/index.html is an interesting API too |
| 22:54 | <annevk> | although it should implicitly call start |
| 22:55 | <Hixie> | yroc: generally if changing something would break web pages (as in this case), we don't even bother to look for other reasons :-) |
| 22:57 | <zewt> | yeah i'd much prefer an api that always bubbles, i can filter out the bubble phase easily enough if i really want that |
| 22:58 | <zewt> | personally the most annoying subtle weirdness of dom events for me is how capturing listeners aren't run before non-capturing listeners during the "on target" phase (or whatever it's called) |
| 22:59 | <annevk> | listeners are in adding order |
| 23:00 | <zewt> | but intuitively capturing listeners are before non-capturing listeners, but that's not actually the case when dispatching to the target itself |
| 23:01 | <yroc> | Hixie: I see. But incidentally, I think it's actually a good thing that the initial newline is stripped for the reason I outlined above. |
| 23:01 | <zewt> | anyway, fixing that even in a different api is probably not worth the added complexity of the subtle difference (and probably other weirdness as a result) |
| 23:01 | <Hixie> | yroc: probably, yeah |
| 23:02 | <annevk> | zewt: well we can do all kinds of stuff, e.g. let the developer completely control independently whether capture/bubble/target are included or not |
| 23:03 | <annevk> | zewt: but whether that's needed... it seems most cases are about target+bubbling, preferably with event delegation via selector |
| 23:04 | <zewt> | maybe i just do weird things, i dunno |
| 23:04 | <yroc> | Hixie: In fact, I think it would be good to strip the newline after a child <code> starting tag... |
| 23:04 | <yroc> | , so the author can start the first line flush with the rest of the code (just a suggestion!) |
| 23:05 | <yroc> | Hixie: Wondering why do we an element to represent a word wrap opportunity? |
| 23:05 | <zewt> | sometimes i'll put a capturing listener on a tree to grab an event, do something funky with it, then re-dispatch it (perhaps at a later time), eg. grabbing onclick and delaying the actual onclick by 0.5s to allow an animation to happen |
| 23:05 | <yroc> | Hixie: Why isn't zero width space sufficient? |
| 23:05 | <annevk> | zewt: you can do the same with preventDefault() |
| 23:06 | <zewt> | no, because i don't want any non-capturing event listeners to run (since often the actual behavior of the button or whatever is a scripted event, not the default) |
| 23:07 | <yroc> | Hixie: U+200B |
| 23:07 | <zewt> | anyway, it can be dealt with, it just means guaranteeing that the element where the capturing event listener lives is *above* any nodes that might receive the event later, to guarantee the capturing listener happens first--not a huge deal, just annoying when i forget |
| 23:09 | <annevk> | given that none of the libraries have it and pretty much no developer I have talked to really gets the final argument of addEventListener, I'm sceptical about the new API catering for it, but who knows |
| 23:10 | <tantek> | why not leave it out until someone needs it in a real world situation? |
| 23:10 | <jamesr> | the one that you just say "false" for because firefox complains if you don't? |
| 23:11 | <annevk> | tantek: well zewt had such a situation apparently ;) |
| 23:12 | <annevk> | jamesr: does it still? :/ |
| 23:12 | <annevk> | hopefully once those new IDL bindings land that will no longer happen |
| 23:12 | <jamesr> | oh! guess it doesn't any more |
| 23:13 | <annevk> | since I started writing the core bit of Events it has been optional per spec |
| 23:14 | <annevk> | seems optional in Nightly 20something at least |
| 23:18 | <zewt> | annevk: i think a new events API should absolutely support capturing, but it'd be fine if it was an options dictionary item instead |
| 23:19 | <annevk> | dunno |
| 23:20 | <zewt> | capturing isn't used a lot but when you need it, it's really helpful |
| 23:20 | <zewt> | afk, heading home |