| 02:57 | <annevk> | Hixie: nah man, rename all the things! |
| 03:37 | <Hixie> | jesus |
| 03:37 | <Hixie> | MPEG-4 is a seriously messed up format |
| 03:46 | <rniwa> | Hixie: any spec. to do with video and audio are pretty much messed up IMO. |
| 03:46 | <Hixie> | the spec is impenetrable |
| 03:46 | <Hixie> | as far as i can tell |
| 03:47 | <Hixie> | (if anyone here is familiar with MPEG-4 let me know, you could really help me out) |
| 03:57 | <MikeSmith> | Hixie: track stuff? |
| 04:16 | <rniwa> | Hixie: does HTML5 require named getter on document object? |
| 04:17 | <rniwa> | Hixie: i.e. named access; http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#named-access-on-the-window-object |
| 04:17 | <rniwa> | Hixie: it appears that webkit has some code to allow this on document but is not working. |
| 04:17 | <rniwa> | Hixie: it'll be nice if we can just get rid of altogether if we don't need them. |
| 04:17 | <rniwa> | get rid of them* |
| 04:26 | <Hixie> | MikeSmith: yeah |
| 04:26 | <MikeSmith> | Hixie: yeah saw the bug now |
| 04:26 | <Hixie> | rniwa: dunno, look at the spec :-) |
| 04:27 | <rniwa> | Hixie: i've looked at the spec but couldn't find it. |
| 04:27 | Hixie | looks |
| 04:27 | <Hixie> | yes |
| 04:27 | <Hixie> | it's right there in the idl |
| 04:27 | <Hixie> | getter object (DOMString name); |
| 04:35 | <rniwa> | Hixie: can I have a pointer? |
| 04:35 | <Hixie> | search for what i just pasted :-) |
| 04:35 | <Hixie> | it's in the Document idl block |
| 04:35 | <rniwa> | Hixie: ah, now i see it. |
| 04:36 | <rniwa> | Hixie: :( it's called named properties here |
| 04:36 | <Hixie> | ? |
| 04:36 | <rniwa> | that's why it wasn't hitting my search for "getters" |
| 04:36 | <Hixie> | how do you mean? |
| 04:36 | <rniwa> | or rather "accessors" |
| 04:37 | <rniwa> | Hixie: i was looking for named getters & named accessors |
| 04:37 | <Hixie> | ah |
| 04:37 | <rniwa> | Hixie: it seems like there are a lot of synonymous for this thing |
| 04:37 | <Hixie> | well this is just webidl syntax |
| 04:38 | <zcorpan> | Hixie: wait, we can't use RESOLVED FIXED for fixed bugs now? |
| 04:39 | <Hixie> | trying to get clarity on this from the chairs |
| 04:39 | <Hixie> | i expect we'll clone the bugs |
| 04:39 | <Hixie> | so that they don't get lost |
| 04:40 | <zcorpan> | is the w3c spec frozen? |
| 04:43 | <Hixie> | not frozen, but it doesn't currently have an editor |
| 04:44 | <zcorpan> | you don't push updates to it anymore? |
| 04:47 | <Hixie> | no |
| 04:47 | <Hixie> | the chairs asked me to stop a while back |
| 04:47 | <zcorpan> | ok |
| 04:47 | <Hixie> | (i finally got around to updating my script recently, after going through the bulk of bug report e-mails) |
| 04:48 | <Hixie> | (so that i didn't have to find a way to get the e-mails into bug form) |
| 04:49 | <zcorpan> | i wonder how long the chairs will take to decide on the bugs thing, having fixed ones stay open seems annoying for me |
| 04:50 | <Hixie> | sounded like they were going to come to a decision pretty quickly |
| 04:50 | <zcorpan> | good |
| 04:52 | <Hixie> | oh sweet lord |
| 04:52 | <Hixie> | MPEG2 is EVEN WORSE |
| 04:53 | <Hixie> | also wtf is with these standards organisations that DON'T PUT THEIR STANDARDS ON THE WEB |
| 04:53 | <Hixie> | wtf is the point of a standard YOU CAN'T READ |
| 04:54 | <zcorpan> | is mpeg2 something we need to support? |
| 04:54 | <Hixie> | mpeg2 is what tv stations use, i believe |
| 04:54 | <Hixie> | so it's likely that most uses of the feature i'm speccing will use mpeg2 |
| 04:54 | <Hixie> | note that i'm not convinced anyone will actually ever use this |
| 04:56 | <roc> | as I'm sure you know, selling copies of standards was (is) a common business model for standards bodies to fund themselves |
| 04:56 | <Hixie> | such standards bodies are idiots. |
| 04:57 | <Hixie> | or at least, seriously misguided |
| 04:57 | <Hixie> | and somewhat lacking in understanding as to how standards work |
| 04:58 | <Hixie> | (then again, i don't understand why standards bodies need funding. all you need is to pay for a web host and that's pretty cheap these days.) |
| 04:58 | <roc> | bureaucracy |
| 04:58 | <roc> | it costs money |
| 04:58 | <Hixie> | bureaucracy is not required to write a standard. |
| 04:59 | <Hixie> | in fact, it only detracts from it. |
| 04:59 | <roc> | I think you're preaching to the choir here |
| 04:59 | <Hixie> | yes. :-) |
| 05:00 | <Hixie> | just venting |
| 05:09 | <Hixie> | zcorpan: (oh, and canvas stopped updating even longer ago) |
| 05:09 | <MikeSmith> | Hixie: http://mumudvb.braice.net/mumudrupal/sites/default/files/iso13818-1.pdf |
| 05:10 | <Hixie> | ooh |
| 05:10 | <MikeSmith> | that's just part 1, I think |
| 05:11 | <MikeSmith> | apparently there are 7 or more parts to it |
| 05:11 | <Hixie> | apparently i need the "Systems" chapter |
| 05:11 | <Hixie> | (?) |
| 05:12 | <Hixie> | which that seems to be |
| 05:12 | <Hixie> | let me see if it has what i need |
| 05:13 | <Hixie> | oh i think i read this spec once |
| 05:20 | <zcorpan> | Hixie: but fixed canvas bugs are not left open? |
| 05:20 | <Hixie> | i don't think i've fixed any since then have i? |
| 05:21 | <zcorpan> | dunno |
| 05:21 | <Hixie> | it's always possible i've accidentally closed some, especially if it was back when i still thought we'd resolve the canvas issue before we forked |
| 05:21 | <Hixie> | i kinda assume they're going to take all the changes |
| 05:22 | <Hixie> | if they're not, they'll probably have bigger problems |
| 05:22 | <Hixie> | than a few missed bugs |
| 05:29 | <zcorpan> | WONTFIX resolutions are OK? |
| 05:31 | <Hixie> | probably not, but i told the chairs about that one |
| 05:32 | <Hixie> | it seemed pretty uncontroversial, other than you disagreeing with me :-) |
| 05:33 | <zcorpan> | yeah imma spend days ISSUEing and CPing over it |
| 05:33 | <Hixie> | :-) |
| 05:35 | <MikeSmith> | zcorpan: If you need any secret backroom deals later to get an extension, lemme know |
| 05:35 | <Hixie> | so THAT's how hober and the a11y people are getting all these extensions |
| 05:36 | <zcorpan> | MikeSmith: shhh! |
| 05:36 | <MikeSmith> | whoops yeah I guess it's not secret any more |
| 05:36 | <MikeSmith> | damn |
| 05:37 | <MikeSmith> | can always count on dude to provide the lulz |
| 05:37 | <MikeSmith> | at his own expense |
| 05:40 | <MikeSmith> | Hixie: oh I see you did manage to find the MPEG-2 info you needed |
| 05:42 | <MikeSmith> | hahaha "I have no idea what I'm doing here." |
| 05:42 | <MikeSmith> | somebody's going to quote you on that man |
| 05:42 | <MikeSmith> | out of context of course |
| 05:42 | <MikeSmith> | well, I will at least |
| 05:44 | <zcorpan> | i already tweeted it |
| 05:49 | <MikeSmith> | I'm saving it for a future CP |
| 06:42 | <MikeSmith> | am I missing some context for http://lists.w3.org/Archives/Public/public-html-a11y/2012Jun/0119.html ? |
| 06:45 | <webben> | MikeSmith: I'm guessing "lightweight JSON objects" are the Canvas regions that have ARIA roles but not associated elements. |
| 06:46 | <webben> | MikeSmith: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-region's-unbacked-region-description |
| 06:47 | <MikeSmith> | hey it's webben |
| 06:47 | <webben> | hey :) |
| 06:47 | <MikeSmith> | webben: thanks for the pointer |
| 06:48 | <webben> | yw |
| 07:07 | <Stevef> | mikesmith: it's the half baked part of the canvas additions where there is no agreement or information about how it will work and whether the regions will be focusable or not |
| 07:12 | <MikeSmith> | Stevef: I don't see what it has to do with JSON but OK |
| 07:15 | <Stevef> | MikeSmith: mentioned here at F2F http://krijnhoetmer.nl/irc-logs/html-wg/20120503#l-1083 |
| 07:16 | <webben> | Yes. Strictly speaking they are effectively DOM properties of the <canvas> element, not "JSON". |
| 07:16 | <MikeSmith> | Stevef: ah, OK |
| 07:17 | <Stevef> | mikesmith: there is other discussion can't find at the mo' |
| 07:18 | <MikeSmith> | Stevef: I understand the context now |
| 07:19 | <MikeSmith> | just, using that inaccurate terminology to describe it doesn't help |
| 07:34 | <Stevef> | mikesmith: json idea originally floated by philip http://krijnhoetmer.nl/irc-logs/whatwg/20120223#l-117 |
| 07:40 | <MikeSmith> | Stevef: I see |
| 08:24 | <wirepair> | man, CORS sure has made it easy to execute XSS against people who think passing parts of the URI to XHR is a Good Idea(tm) |
| 08:25 | <wirepair> | s/people/sites |
| 08:28 | <annevk> | passing parts of the URI directly is never a good idea |
| 08:30 | <wirepair> | of course not but CORS makes it much easier to get third party script code executed via an XHR call than without CORS support |
| 08:31 | <annevk> | zcorpan: retweeted from @whatwg |
| 08:31 | <annevk> | wirepair: yeah and new HTML features make it easier to bypass blacklist-based filtering |
| 08:32 | wirepair | shrugs |
| 08:32 | <wirepair> | if you're blacklisting you're doing it wrong :> |
| 08:33 | <annevk> | if you're reusing parts of the URL without checking you're doing it wrong too |
| 08:33 | <wirepair> | in that we agree as well :> |
| 08:35 | <zcorpan> | XDomainRequest doesn't have that problem |
| 08:35 | <zcorpan> | (at least so long as XHR didn't support CORS in ie) |
| 08:36 | <wirepair> | yeah prob is people forget that xhr can now load from 3rd party sites |
| 08:36 | <wirepair> | so all taht old code is suddenly vulnerable |
| 08:39 | <zcorpan> | yes, and when i first saw this problem being discussed, the proposed fix was *still* vulnerable because the guy who proposed the fix didn't know that urls like "//example.org" work |
| 08:39 | <zcorpan> | (the fix being "just prepend a slash and you'll be fine") |
| 08:42 | <wirepair> | fantastic. :) |
| 08:42 | <annevk> | wirepair: hmm yeah, I guess it's too late now :( |
| 08:45 | <wirepair> | well yeah, i mean it's how CORS works so not really sure what you could even do. |
| 08:47 | <annevk> | well for XHR we could have had a different way to get access to CORS |
| 10:32 | <zcorpan> | anyone have advice for this guy? (redirect and appcache) http://forums.whatwg.org/bb3/viewtopic.php?f=10&t=5022 |
| 11:15 | <niloy> | zcorpan, move resources to cdn maybe? |
| 11:18 | <zcorpan> | niloy: feel free to reply in the forum :-) |
| 11:19 | <niloy> | zcorpan, sure :) |
| 11:19 | <zcorpan> | thanks |
| 13:01 | <gsnedders> | jgraham: given you were asking yesterday, https://groups.google.com/d/msg/mozilla.dev.tech.js-engine/yYQyMCcMf-0/c1kHxnhOUlYJ |
| 13:03 | <gsnedders> | (E4X in SM) |
| 15:51 | <Stevef> | no meeting this week |
| 15:52 | <Stevef> | sorry wrong window |
| 15:52 | <Ms2ger> | No meeting here either :): |
| 15:52 | Ms2ger | wonders why he has eyes on his chin |
| 15:54 | <jgraham> | Practising canibalism? |
| 15:54 | <Ms2ger> | Not usually |
| 16:04 | <dglazkov> | good morning, Whatwg! |
| 17:54 | <Ms2ger> | "When rendering li elements, user agents are expected to use the ordinal value of the li element to render the counter in the list item marker." |
| 17:54 | <Ms2ger> | "If the parent element is an ol element, then the li element has an ordinal value." |
| 17:55 | <Ms2ger> | If the parent element is *not* an ol element, what is rendered? |
| 18:01 | <Hixie> | if the parente lement is not an ol element, there's no counter in the list item marker |
| 18:03 | <Ms2ger> | <ol><div><li>A</div></ol> |
| 18:05 | <Ms2ger> | Should that have a number anywhere, and if so, where? |
| 18:05 | <TabAtkins> | Yes, before the A. |
| 18:05 | <Ms2ger> | Which number? |
| 18:05 | <TabAtkins> | The <li> generates a marker, and inherits a numeric type from <ol> |
| 18:05 | <TabAtkins> | 1. |
| 18:05 | <Ms2ger> | Now, <ol><div><li>A</div> <li>B</ol> |
| 18:05 | <TabAtkins> | The counter from <ol> isn't distrubed by having the <div> come between it and the <li>. |
| 18:06 | <Ms2ger> | You say 1. A / 2. B? |
| 18:06 | <TabAtkins> | If my mental model of the parser is right, sure. If you give me the DOM produced, I can tell you for sure. |
| 18:06 | <gavinc> | Sometimes validator.nu is a bit... amusing The encoding "utf-8" is not the preferred name of the character encoding in use. The preferred name is utf-8 |
| 18:07 | <Ms2ger> | Yeah, nothing special going on in the parser here |
| 18:07 | <Ms2ger> | Now, <ol reversed><div><li>A</div> <li>B</ol> |
| 18:07 | <TabAtkins> | The <ol> genreates a fresh counter scope. Each <li> increments it. |
| 18:07 | <TabAtkins> | Ah, fun fun. Depends on how you implement @reversed. |
| 18:08 | <Ms2ger> | Not with CSS counters, because I'm told those can't reverse |
| 18:08 | <TabAtkins> | They can, but you have to have a starting value. |
| 18:08 | <TabAtkins> | You can say "start at 5, and each counter adds -1". |
| 18:09 | <Ms2ger> | You can? |
| 18:09 | <Ms2ger> | Hi fantasai |
| 18:09 | <TabAtkins> | Yeah, the counter-increment property takes any integer. |
| 18:09 | <fantasai> | hi Ms2ger :) |
| 18:10 | <fantasai> | TabAtkins: where are you? |
| 18:10 | <TabAtkins> | In the google office. |
| 18:10 | <Ms2ger> | <TabAtkins_> fantasai: I'm in the google office. Where's the moz office, and how do I get in? |
| 18:10 | <fantasai> | TabAtkins: is our phone dead again :/ |
| 18:11 | <fantasai> | s/our/your/ |
| 18:11 | <TabAtkins> | fantasai: Nearly, so I've turned it off. |
| 18:11 | fantasai | sent a text with instructions half an hour ago |
| 18:11 | <fantasai> | ~_~ |
| 18:11 | <Ms2ger> | Hmm, I didn't know we were right on the waterfront |
| 18:12 | <TabAtkins> | fantasai: I was talking with Ojan and Tony when I got in anyway. |
| 18:12 | fantasai | didn't know they were in sf |
| 18:12 | <TabAtkins> | Yup! |
| 18:12 | <fantasai> | anyway! |
| 18:12 | <TabAtkins> | Do I need security or something to get up to floor 7? |
| 18:12 | <TabAtkins> | Or do you just want to come down and get me? |
| 18:13 | <Ms2ger> | TabAtkins, however, ol isn't specced in terms of CSS counters |
| 18:13 | <fantasai> | No, and we don't ask you to sign an NDA that you're legally incapable of signing, either :P |
| 18:13 | <TabAtkins> | kk, I'll be up in a sec then. |
| 18:13 | <fantasai> | Ms2ger: if it's specced using display: list-item, then it will be in L3 |
| 18:13 | <fantasai> | Ms2ger: using an implied counter |
| 18:14 | <fantasai> | right, so I was going to ask a question ... |
| 18:14 | <fantasai> | hsivonen: Is it intentional that </ins> gets ignored when </p> is implicit? |
| 18:14 | <fantasai> | hsivonen: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%0A%3Cins%3E%3Cp%3Einserted%3C%2Fins%3E%0A%0A%3Cp%3Enot%20inserted |
| 18:15 | <Ms2ger> | Well, it has display: list-item, but with an override for the counter |
| 18:15 | <[tm]> | gavinc: file a bug. our maybe there is actually an open bug on that one already |
| 18:18 | <fantasai> | Ms2ger: for 'start' and 'value', you mean? |
| 18:18 | <Ms2ger> | And reversed |
| 18:18 | <fantasai> | ah, right |
| 18:18 | <fantasai> | that one, we can't do in CSS yet |
| 18:18 | <Ms2ger> | Hah |
| 18:18 | <Ms2ger> | TabAtkins just claimed he can |
| 18:19 | <Ms2ger> | But if bz and fantasai can't do it... :) |
| 18:19 | <fantasai> | you can count backwards :) |
| 18:19 | <fantasai> | that's easy |
| 18:19 | <fantasai> | but you need to know what number to start at |
| 18:19 | <fantasai> | and that's not possible afaik |
| 18:19 | <TabAtkins> | fantasai: I'm in the lobby. |
| 18:20 | <Ms2ger> | TabAtkins (~tabatkins@nat/mozilla |
| 18:20 | <Ms2ger> | Welcome to the bright side, sir |
| 18:21 | <Ms2ger> | fantasai, well, you can count the |
| 18:21 | <Ms2ger> | Wrong button |
| 18:21 | <Ms2ger> | Another case |
| 18:21 | <Ms2ger> | <ol><div style=display:list-item>A</div><li>B</ol> |
| 18:22 | fantasai | notes that Ms2ger got both of us to lol |
| 18:22 | <Ms2ger> | Always glad to do that, m'lady |
| 18:28 | <Hixie> | Ms2ger: sorry, was afk |
| 18:28 | <Hixie> | Ms2ger: looks like the spec should say the ordinal value is 1 if there's no parent ol. |
| 18:29 | <Hixie> | Ms2ger: note that if the author uses css counters to override the default rendering, the numbers won't match, since css doesn't provide a way to get the ordinal value at the moment |
| 18:29 | <jgraham> | I have been told that webkit does something weird for @reversed like making the start value CSS dependant |
| 18:30 | <Ms2ger> | So, <ol><div><li>A</div><div><li>B</div></ol> |
| 18:30 | <Hixie> | it's not just reversed="" that causes problems, also display:none and so on |
| 18:31 | <Hixie> | bbiab |
| 18:35 | <pablof> | has there been any additional work on appcache's prefer-online since http://html5.org/tools/web-apps-tracker?from=7135&to=7136 ? |
| 18:35 | <pablof> | can't seem to find most of that text in the spec |
| 18:35 | <pablof> | (tangentially, is there a place to do a blame on the svn files somewhere online?) |
| 18:37 | <jgraham> | You want a web service that does something like 'def get_blame:return "Hixie"'? |
| 18:38 | <jgraham> | (yeah, I know svn blame does more than that :p) |
| 18:39 | <pablof> | i'm after the commit/diff, not the author, we all know who to blame :P |
| 18:40 | <jgraham> | I doubt anyone provides that |
| 18:41 | <jgraham> | I imagine it is slow to compute |
| 18:41 | <jgraham> | No one even provides a convenient git-svn version of the spec :( |
| 18:43 | <Ms2ger> | Hixie has per-1000-commit blames cached somewhere |
| 18:43 | <Ms2ger> | But I always forget where |
| 20:03 | <Hixie> | Ms2ger, pablof: http://www.whatwg.org/specs/web-apps/current-work/blame.r5000 is available, for various values of 5000 |
| 20:05 | <Hixie> | blame.r0005 blame.r0954 blame.r2200 blame.r2800 blame.r3000 blame.r4667 blame.r5372 blame.r7000 blame.r0050 blame.r1000 blame.r2216 blame.r2905 blame.r3075 blame.r5000 blame.r5600 blame.r6400 blame.r0500 blame.r2000 blame.r2500 blame.r2947 blame.r4000 blame.r5287 blame.r6000 blame.r6666 |
| 20:05 | <Hixie> | er let me sort that and try again |
| 20:05 | <Hixie> | blame.r0005 blame.r0050 blame.r0500 blame.r0954 blame.r1000 blame.r2000 blame.r2200 blame.r2216 blame.r2500 blame.r2800 blame.r2905 blame.r2947 |
| 20:05 | <Hixie> | blame.r3000 blame.r3075 blame.r4000 blame.r4667 blame.r5000 blame.r5287 blame.r5372 blame.r5600 blame.r6000 blame.r6400 blame.r6666 blame.r7000 |
| 20:06 | <Hixie> | (some of the more weird numbers like 2947 and 5287 correspond to diffs where a lot changed for editorial reasons so they come up often in archeology) |
| 20:07 | <Hixie> | feel free to document this on the wiki if you want btw |
| 20:09 | <pablof> | thanks |
| 20:11 | <pablof> | Hixie: were there any changes in the spec recently on appcache's prefer-online? |
| 20:16 | <Hixie> | pablof: well it was added to the spec... |
| 20:16 | <Hixie> | pablof: how recently do you mean? |
| 20:17 | <pablof> | Hixie: i mean that i can't seem to find the text added in http://html5.org/tools/web-apps-tracker?from=7135&to=7136 |
| 20:18 | <pablof> | let me re-check in the one-page one, in case i'm dumb |
| 20:19 | <pablof> | Hixie: yeah, never mind, the parts i was looking for weren't in the application cache section, sorry about that |
| 20:19 | <pablof> | doh |
| 20:37 | <Hixie> | pablof: ah ok |
| 21:30 | <Hixie> | AryehGregor: you around? got some questions about drag and drop and contenteditable (in case you are and want to pretend you're not ;-) ) |
| 21:42 | jgraham | would totally always pretend to be away rather than answer questions about contenteditable or drag and drop |
| 21:44 | <Hixie> | yeah me too |
| 21:44 | <Hixie> | hence me letting him know :-) |
| 21:44 | <jgraham> | Also, I wonder what would happen if web developers saw that the HTML spec specifically thanks the inventors of the drag and drop API. I expect it would involve pitch forks and buring torches |
| 21:45 | <jgraham> | Or failing that some mild sarcasm on twitter |
| 21:45 | <jgraham> | 21st century revolution style |
| 21:47 | <Hixie> | lol |
| 21:47 | <Hixie> | dnd has been dramatically improved |
| 21:47 | <Hixie> | with draggable and dragzone |
| 21:48 | <Hixie> | it might even be possible to use it now |
| 23:42 | <TabAtkins> | I wonder if Chrome has added draggable and dragzone yet? I've got some dnd code that I wouldn't mind simplifying. |