| 00:09 | <Philip`> | zcorpan_: What is the regexp intending to look for? |
| 00:09 | <Philip`> | Something like <script>...<!-- <script></script> ? |
| 00:10 | <zcorpan_> | Philip`: yes |
| 00:14 | <Dashiva> | Ho-hum |
| 00:14 | <Dashiva> | So how do the RDFa guys feel about the (implicit) claim that RDFa fails to deliver distributed extensibility? |
| 00:16 | <Philip`> | Has anyone defined what distributed extensibility is? |
| 00:16 | <Philip`> | so that we could evaluate whether a proposal provides it |
| 00:16 | <Philip`> | (and could work out why the features currently in HTML5 are insufficient) |
| 00:17 | <zcorpan_> | namespaces can haz it |
| 00:17 | <Dashiva> | Distributed extensibility means you can do stupid things and nobody gets to tell you no |
| 00:18 | <Dashiva> | And it still validates |
| 00:18 | <Hixie> | Philip`: last time i tried asking that question i got blasted for being obstructionist |
| 00:19 | <Hixie> | (i really don't know the answer, though, and would love to find out) |
| 00:19 | <Hixie> | (for exactly the reason you give) |
| 00:19 | <Philip`> | Dashiva: That seems to miss the apparent fact that it's not distributed extensibility unless it uses colons |
| 00:20 | <zcorpan_> | oh yes |
| 00:20 | <Hixie> | i thought rdfa used colons |
| 00:20 | <zcorpan_> | it's not namespaces that haz extensibility |
| 00:20 | <zcorpan_> | it's the colon |
| 00:21 | <hober> | "distributed" refers to the space between the two dots in : |
| 00:21 | <Dashiva> | No, it's the fact that the color distributes the tagName into the prefix and localname |
| 00:22 | <othermaciej> | I think it would be worth stating reasons why it may be a bad idea, both in general and specifically Microsoft's proposal |
| 00:22 | <othermaciej> | (or good idea, if you like it) |
| 00:22 | <Dashiva> | othermaciej: I haven't seen any rebuttals to sicking's list yet |
| 00:24 | <Dashiva> | http://lists.w3.org/Archives/Public/public-html/2009Sep/1218.html |
| 00:24 | <Dashiva> | "The risk of that could be mitigated by having a central registry that's, for instance, a wiki page." |
| 00:24 | <Dashiva> | Not very distributed then, is it? |
| 00:25 | <othermaciej> | I don't think anyone has asked what namespaces-in-html add that RDFa (plus other existing extension mechanisms) doesn't, perhaps that is a question worth asking |
| 00:25 | <zcorpan_> | we could have a distributed registry |
| 00:25 | <Philip`> | The registry could be put on Wave |
| 00:25 | <Dashiva> | Maybe I'll send a mail for once |
| 00:26 | <Dashiva> | It's such a pain to do replies when you're not on the list |
| 00:26 | <Philip`> | Dashiva: The Reply links in the archive work alright for me, as long as I fix their double-escaping of angle brackets |
| 00:26 | <Dashiva> | Philip`: Yeah, but then I have to make a quote |
| 00:27 | <Philip`> | Dashiva: Ctrl+C, Alt+Tab, Ctrl+Shift+V? |
| 00:27 | <Dashiva> | What's that last one? |
| 00:27 | <Philip`> | or Ctrl+Alt+V or whatever it is |
| 00:27 | <Philip`> | It's "paste as quote" in Thunderbird |
| 00:30 | <Dashiva> | Oh, I see |
| 00:30 | <Dashiva> | That could simplify things |
| 00:30 | <Dashiva> | But it will still take a day or two before my message arrives, I guess |
| 00:32 | <Philip`> | s/day/minute/ |
| 00:32 | <Dashiva> | At least the archives page is smart enough to realize I want to reply to the list |
| 00:32 | <Philip`> | (It's already arrived) |
| 00:32 | <Dashiva> | I thought they got stuck in a queue for checking? |
| 00:33 | <Philip`> | Only the first email from each address |
| 00:33 | <Philip`> | After that it's instant |
| 00:33 | <Dashiva> | I see |
| 00:36 | <Philip`> | References: %3C7c2a12e20909301619u21339617g447565bc2a3ffbb1⊙mgc%3E |
| 00:36 | <Philip`> | You didn't fix the double-escaping :-( |
| 00:36 | <Philip`> | (i.e. replace the archive mailto link's %253C with %3C etc) |
| 00:37 | <Dashiva> | Well, how can I do that once the message is inside thunderbird? |
| 00:37 | <Philip`> | You can't, as far as I'm aware |
| 00:37 | <Philip`> | So do it before it's in Thunderbird :-) |
| 00:38 | <Philip`> | (by editing the mailto URL) |
| 00:38 | <Philip`> | Or I suppose you could work out how to report the bug in the archive system to |
| 00:38 | <Philip`> | s/how/who/ |
| 00:38 | <Dashiva> | I've already done that, I delegate to you |
| 00:38 | <Philip`> | I've already failed to work out who to tell for about two years |
| 00:39 | <Philip`> | Maybe someone who's reading the IRC logs can report/fix it |
| 00:40 | <Dashiva> | Use the Plotkin algorithm for recursion |
| 00:40 | <Dashiva> | Find someone who is closer to the problem than you, and ask them |
| 00:40 | <Dashiva> | karl and mike should do |
| 00:41 | <Dashiva> | Or even othermaciej ;) |
| 00:43 | <othermaciej> | Dashiva: ask me what? |
| 00:43 | <Philip`> | Dashiva: That assumes "closer" is a partial order |
| 00:43 | <Philip`> | which is unlikely to be true when it's based on people's subjective views of closeness |
| 00:43 | <Philip`> | so you might end up with k < m < o < k and the algorithm will never terminate |
| 00:44 | <Philip`> | and I'd hate for WG members to be eternally tied up by infinite loops |
| 00:45 | <Dashiva> | Philip`: That's their problem, not yours |
| 00:45 | <Dashiva> | Besides, that assumes they use the algorithm as well |
| 00:45 | <Dashiva> | This is unlikely, when you're close to the problem you probably have a more effective alternative |
| 00:46 | <Philip`> | More effective than being lazy and telling someone else to do it? That seems unlikely |
| 00:47 | <Philip`> | Oh, I forgot about zcorpan |
| 00:48 | Philip` | goes back to check his grep... |
| 00:48 | <Dashiva> | You have to judge the efficiency including the benefit of avoiding loops |
| 00:48 | <Philip`> | Hmm, actually I should go to sleep instead |
| 00:49 | <Philip`> | zcorpan: Remind me to upload the results tomorrow |
| 00:49 | <Philip`> | (by which I mean later today, for most definitions of today) |
| 00:49 | <Philip`> | assuming you even read this |
| 00:50 | <Philip`> | Dashiva: I suppose we could always add a TTL to the recursion, so it won't go on forever |
| 00:51 | <Dashiva> | No, that won't work |
| 00:51 | <Dashiva> | The problem will still exist and the loop will begin anew |
| 01:09 | karlcow | is reading the back log of Dashiva and Philip` and he's trying to figure out how I could possibly solve something :p |
| 01:09 | <Dashiva> | You can't solve it, but you can pass it on to someone closer to the solution |
| 01:12 | <karlcow> | Dashiva: pass what ? :) |
| 01:12 | <karlcow> | Right now I might have fruits around me if it's what you need |
| 01:12 | <Dashiva> | [01:44:35] <Philip`> References: %3C7c2a12e20909301619u21339617g447565bc2a3ffbb1⊙mgc%3E |
| 01:12 | <Dashiva> | [01:44:47] <Philip`> You didn't fix the double-escaping :-( |
| 01:14 | <karlcow> | Do you mean there are issues with w3c mailing lists? I guess I could send an email to the sysadmin but anyone could do. I'm as distant as you or Philip from the sysadmins. :) |
| 01:15 | <Dashiva> | I didn't even know they had email, so see, you're closer :) |
| 01:15 | <Dashiva> | The issue is when you click the reply link in the archives |
| 01:15 | <karlcow> | Let me try to find a Web page |
| 01:16 | <karlcow> | found. Good memory. http://www.w3.org/Mail/ |
| 01:44 | <Dashiva> | "XML documents cannot have syntax errors" makes me think about true scotsmen |
| 02:36 | <MikeSmith> | it'd be nice if the CSS WG allowed people to use bugzilla to report bugs |
| 02:36 | <MikeSmith> | I really don't want to have to post to www-style |
| 03:51 | <Hixie> | how do people feel about loops with <itemref>? |
| 03:52 | <Hixie> | <div itemscope><span id=a><itemref refid=a> <span itemprop=x>y</span></span></div> |
| 03:52 | <Hixie> | <div id=a> <span itemprop=x>y</span> <div itemscope> <itemref refid=a> </div> </div> |
| 03:53 | <Dashiva> | It's hard to understand loop examples with only a single instance |
| 03:54 | <Hixie> | <div id=a> <span itemprop=x>y</span> <itemref refid=b> </div> <div itemscope> <div id=b> <span itemprop=q>r</span> <itemref refid=a> </div> </div> |
| 03:56 | <Dashiva> | Referencing inside->outside of main scope seems weird to me |
| 03:56 | <Hixie> | that's the main use case |
| 03:56 | <Hixie> | in fact referencing within the same scope is likely always a mistake |
| 03:56 | <Dashiva> | I thought that was outside->inside |
| 03:57 | <Dashiva> | I'm not 100% up to speed on microdata |
| 03:57 | <Hixie> | that was itemfor="" |
| 03:57 | <Hixie> | <itemref> is itemfor="" backwards |
| 03:57 | <Dashiva> | Then I reverse my statement |
| 03:58 | <Dashiva> | I can't think of a reason why you'd want bidirectional links |
| 03:58 | <Hixie> | i guess i'll make it just so that to validate itemref you have to construct the chain, and if at any point you get to an element you've already processed, it's an error |
| 03:58 | <Dashiva> | Should itemref be allowed outside itemscope at all? |
| 03:58 | <Hixie> | and for microdata parsers you stop looping at that point |
| 03:59 | <Hixie> | well it doesn't make sense to only allow two-step chains if you put the second step inside an otherwise bogus itemscope="" |
| 03:59 | <Dashiva> | True |
| 03:59 | <Dashiva> | But only trees, not graphs with cycles |
| 04:00 | <Dashiva> | Or is the intent to allow several items to reference the same external item? |
| 04:00 | <Hixie> | yes |
| 04:00 | <Hixie> | on a related note, i wonder if i should make it invalid for an itemprop="" to be part of more than one type of itemscope |
| 04:00 | <jcranmer> | Dashiva: what about DAGs, which are neither trees nor cyclic? |
| 04:00 | <Dashiva> | It seems like a DAG is the right term here |
| 04:01 | <Hixie> | e.g. <div itemscope itemtype=a><itemref refid="x"></div><div itemscope itemtype=b><itemref refid="y"> <span itemprop=c id=x>...</span> |
| 04:01 | <Hixie> | since what that property means will be different for the two items |
| 04:01 | <Hixie> | which is kinda weird |
| 04:01 | <Hixie> | eh, i guess i'll leave it |
| 04:02 | <Dashiva> | I could see that being used as a translator |
| 04:02 | <Dashiva> | But the chances of multiple vocabularies having identical props with same meaning seems low |
| 04:02 | <Dashiva> | Unless it's like a version upgrade... |
| 04:03 | <Hixie> | it seems pretty clear that if it happens intentionally, it'll be for a hack |
| 04:04 | <Dashiva> | Mhm... even if you'd be able to share some props, you'd still need to handle the rest, so there's no real gain |
| 04:08 | <Dashiva> | Is an item using itemfor a top-level item? |
| 04:09 | <Hixie> | itemfor is gone now |
| 04:09 | <Hixie> | see damowmow.com/playground/microdata/NOTES |
| 04:09 | <TabAtkins> | I'm okay with cycles causing an error and stopping the parser. |
| 04:09 | <Hixie> | i think i'll just make cycles cause the parser to skip nodes it's already seen |
| 04:12 | <Dashiva> | So itemprop=itemid gives the prefix? |
| 04:12 | <Hixie> | prefix? |
| 04:13 | <Dashiva> | The com.damowmow part |
| 04:23 | <Hixie> | Dashiva: i don't follow |
| 04:24 | <Dashiva> | I'm not sure what is itemtype and what is itemprop=itemid |
| 04:41 | <Hixie> | itemprop=itemid is going away, actually, in favour of just itemid="" |
| 04:41 | <Hixie> | itemtype="" gives the type of the item |
| 04:41 | <Hixie> | see the 004/introduction file |
| 04:42 | <Hixie> | itemid="" gives the URI that in RDF identifies the subject |
| 04:44 | <Dashiva> | Oh, okay |
| 04:50 | <othermaciej> | what does itemref do? |
| 04:50 | <Dashiva> | Links an external item as part of this item |
| 04:51 | <othermaciej> | so it lets you make a non-tree graph I presume |
| 04:51 | <Dashiva> | It's a DAG, as I understand it |
| 04:51 | <Dashiva> | No cycles allowed |
| 04:53 | <othermaciej> | unless <itemref> loops are allowed as Hixie suggested ~ 1 hour ago |
| 04:53 | <othermaciej> | (I assume) |
| 04:55 | <Dashiva> | Yeah |
| 04:56 | <othermaciej> | if there's such a thing as <itemref> at all you may as well allow cycles - IMO |
| 04:57 | <Hixie> | cycles through another item are fine |
| 04:57 | <Hixie> | cycles within the same item make no sense |
| 04:57 | <Hixie> | like, a.b = a is fine |
| 04:58 | <Dashiva> | Hmm, then it's not a dag anymore |
| 04:58 | <Hixie> | but itemref pointing to the itemref's own parent makes no sense |
| 04:58 | <othermaciej> | I can't think of a meaningful use case for self-reference |
| 04:58 | <othermaciej> | at least offhand |
| 04:59 | <othermaciej> | maybe in a family tree for a fictional universe allowing time travel |
| 04:59 | <othermaciej> | where someone may be their own parent |
| 05:00 | <Hixie> | the cycles i were talking about were syntactic, not model cycles |
| 05:00 | <Hixie> | they were the equivalent of #including a file in itself |
| 05:00 | <othermaciej> | do syntactic cycles not create a model cycle? |
| 05:00 | <Hixie> | not necessarily |
| 05:00 | <othermaciej> | I guess I don't understand <itemref> |
| 05:00 | <Hixie> | <div itemscope> <div id=a> <itemref refid=a> </div> </div> |
| 05:00 | <Hixie> | creates a syntactic loop |
| 05:01 | <Hixie> | but within the loop there are no properties at all |
| 05:01 | <Hixie> | so it's not a model loop at all |
| 05:01 | <othermaciej> | I see, property a references itself |
| 05:01 | <othermaciej> | as opposed to two different itemscopes having properties referencing each other - that would be a model cycle |
| 05:02 | <othermaciej> | but what if the itemscope div was the one referenced by the itemref? |
| 05:02 | <othermaciej> | that would be a property with a reference to the object that has the property, i.e. a model cycle? |
| 05:04 | <Hixie> | there is no property at all in that example |
| 05:05 | <Hixie> | the normal use case for this is as follows: |
| 05:06 | <Hixie> | <div itemscope> (some properties) <itemref refid=more> </div> ...later... <div id=more> (some more properties) </div> |
| 05:06 | <Hixie> | and basically the <div> with id=more gets #included where the <itemref> is |
| 05:27 | <othermaciej> | I see |
| 05:27 | <othermaciej> | so <itemref> includes properties by reference, it doesn't make a property value reference another object? |
| 05:28 | <othermaciej> | that doesn't align with what I would expect a "reference" to be, but then, I am a programmer |
| 05:28 | <Hixie> | i'm open other names |
| 05:28 | <Hixie> | i'd like it to start with <item...> |
| 05:30 | <othermaciej> | well <iteminclude> would be one literal-minded suggestion |
| 05:30 | <othermaciej> | or <includeitems> or <shareitems> or something |
| 05:30 | othermaciej | shrugs |
| 05:30 | <Dashiva> | itemcontains |
| 05:30 | <othermaciej> | I have to go to the drug store, will think about it on the way |
| 05:31 | <othermaciej> | oh yeah I guess includeitems is the wrong semantic, the div is the item, what's included is item rroperties |
| 05:32 | <Hixie> | <itemref> has the advantage that we know at least one person understands it |
| 05:35 | <erlehmann> | your metadata models sicken me |
| 05:35 | <erlehmann> | Hixie, all tests done ? |
| 05:36 | <Hixie> | yeah |
| 05:36 | <erlehmann> | so, what were the results ? |
| 05:37 | <Hixie> | 004 fared well |
| 05:37 | <Hixie> | i'm writing it up in the spec as the proposal |
| 05:38 | <erlehmann> | \o/ |
| 05:38 | erlehmann | wont touch any spec parts with a 3 m pole as long as it isnt frozen. |
| 05:39 | <Hixie> | define frozen :-) |
| 06:20 | Hixie | gets a headache from trying to explain the conformance criteria for authors for microdata |
| 06:20 | <Hixie> | since properties can be properties of multiple items, it's kinda screwy |
| 06:22 | <MikeSmith> | Hixie: maybe for the sake of truth in advertising, it should be named "somewhat-less-complicated-data" |
| 06:22 | <Hixie> | i don't think anyone's ever claimed that microdata is simple :-) |
| 06:27 | <othermaciej> | it's not called simpledata |
| 06:27 | <othermaciej> | Hixie: what made you conclude that an include mechanism is needed? do people need shared templates of stock properties? |
| 06:29 | <MikeSmith> | Hixie: btw, one a completely different topic, I seem to remember a while back there being some discussion of moving the Timers stuff out into a separate draft. Do we still want to do that or not? |
| 06:41 | <Hixie> | othermaciej: the yahoo searchmonkey team were the main proponents of such a mechanism, iirc |
| 06:42 | <Hixie> | MikeSmith: i gave up waiting for an editor to do it |
| 06:42 | <othermaciej> | MikeSmith: that seems like one that is good in theory but not a blocker if it doesn't happen - I don't think anyone is complaining |
| 06:45 | <MikeSmith> | othermaciej, Hixie : Ok, understood |
| 06:49 | <MikeSmith> | on another topic, I hope the CSS WG can be encouraged to provide W3C bugzilla as an option for spec comments and bug reports, at least for editorial stuff, because I really don't think requiring people who have editorial suggestions to post them to www-style is so great |
| 06:49 | <MikeSmith> | I have some very minor suggestions about the text of the Media Queries abstract and intro |
| 06:51 | <othermaciej> | I have mixed feelings about the bugzilla system - on the one hand, it's good for tracking, and keeps some noise off the list, on the other hand, sometimes it buries interesting discussion |
| 06:51 | <othermaciej> | overall a good thing compared to just email comments though, I think |
| 07:07 | <MikeSmith> | othermaciej: yeah, it's definitely a tradeoff. But when mailing list traffic gets excessive, interesting discussion effectively ends up getting buried anyway, because people have said there's no way they can keep up with it and so they just delete who threads (or mark them read), including ones that have some interest in by just not time to read through |
| 07:07 | <MikeSmith> | I think chaals said something along those lines recently |
| 07:08 | <MikeSmith> | but others have said as much in the past too |
| 07:08 | <MikeSmith> | s/delete who threads/delete whole threads/ |
| 07:09 | <othermaciej> | yeah in the case of public-html, moving some threads off the list is on the whole a good thing |
| 07:10 | <MikeSmith> | ultimately, having some may of modding list messages would be really useful |
| 07:10 | <MikeSmith> | I wonder if Google Wave has some way to do that |
| 07:15 | <MikeSmith> | annevk42: I have some minor comments on the Media Queries editor's draft. Would be nice to have the option to submit them as W3C bugzilla bugs. Hope that CSS WG can provide that as an option eventually. In the mean time, can I just e-mail them to you? |
| 07:16 | <annevk42> | yeah |
| 07:16 | <MikeSmith> | OK |
| 07:16 | <annevk42> | you could suggest it to the CSS WG |
| 07:16 | <annevk42> | would be sort of nice I gues to log issues there |
| 07:18 | <MikeSmith> | hmm, does the group have a list for administrative things? (instead of www-style) |
| 07:19 | <annevk42> | we do have a tracker instance |
| 07:21 | <MikeSmith> | annevk42: think it'd be OK for me to raise an issue there? |
| 07:23 | <annevk42> | I rather have email |
| 07:23 | <annevk42> | but yeah, if you have access that's fine I suppose |
| 07:24 | <MikeSmith> | annevk42: I'll send the mail, but I was thinking more of opening an issue to suggest the group provide bugzilla reporting as an option |
| 07:24 | <annevk42> | ah ok |
| 07:34 | annevk42 | thinks it would make sense if Timers went into the timer draft submitted by Google |
| 07:36 | <othermaciej> | Google's timer draft isn't about that kind of timer at all |
| 07:37 | <othermaciej> | (afaict) |
| 07:37 | <othermaciej> | I had a high-res timer proposal a while back that might combine well with classic timers |
| 07:39 | <annevk42> | true, it's a bit different |
| 07:40 | <annevk42> | damn it, i like having the entities |
| 08:22 | <hsivonen> | anyone going to the HyBi BoF? |
| 08:24 | <othermaciej> | where is it going to be? |
| 08:24 | <othermaciej> | in the IETF in Japan? |
| 08:25 | <zcorpan_> | Philip`: http://krijnhoetmer.nl/irc-logs/whatwg/20091002#l-157 |
| 08:26 | <othermaciej> | so do any of you Opera folks have the data on Opera's experience with trying namespaces in HTML? |
| 08:27 | <othermaciej> | that would be a useful addition to the distributed extensibility thread |
| 08:31 | <zcorpan_> | iirc, we removed it completely because it broke sites. but i think we allowed it on elements with known tag names, which was the main reason for breakage |
| 08:38 | <Philip`> | zcorpan_: http://philip.html5.org/data/script-open-in-escape.txt |
| 08:39 | <zcorpan_> | Philip`: thanks |
| 08:57 | <annevk2> | hsivonen, do you think it's worth visiting the hybi thingie? |
| 08:58 | <hsivonen> | annevk2: I don't know. Probably not. Certainly not for me personally. |
| 09:02 | annevk2 | would like the MathML entities to stay |
| 09:08 | <hsivonen> | Philip`: btw, if element and attribute namespacing were added to the HTML parsing algorithm, those should depend on namespace mapping context held on the tree builder stack |
| 09:08 | <hsivonen> | Philip`: so xmlns:foo on a <table> would affect the element and attribute namespaces of foster-parented descendants but wouldn't affect CURIEs in foster-parented descendants |
| 09:09 | <annevk2> | I kind of liked the earlier <org.example.table> proposal though I'm not convinced any of this is needed |
| 09:11 | <hsivonen> | annevk2: it would suck with Selectors, though |
| 09:11 | <hsivonen> | annevk2: since you'd have to escape the dot |
| 09:12 | <hsivonen> | annevk2: sicking's idea wouldn't suck with Selectors |
| 09:12 | <Hixie> | has anyone explained what the problem all this is solving is yet? |
| 09:12 | <hsivonen> | Hixie: of course not |
| 09:12 | <Hixie> | then how are you all evaluating how good the proposals are |
| 09:13 | <annevk2> | taste? |
| 09:13 | <Philip`> | hsivonen: Hmm, I suppose that's only sane way to do it, otherwise <html><foo:bar><foo:bar>...<html xmlns:foo> would be a pain |
| 09:13 | <annevk2> | well, and some experience with complexity of namespaces |
| 09:13 | <Philip`> | Hixie: We're not evaluating how good the proposals are, only how bad they are |
| 09:13 | <hsivonen> | Hixie: I'm not evaluation the goodness. I'm evaluating the badness that can be seen regardless of purpose. |
| 09:13 | <Hixie> | fair enough |
| 09:14 | <Hixie> | that doesn't seem all that useful though |
| 09:14 | <hsivonen> | s/evaluation/evaluating/ |
| 09:14 | <Hixie> | i mean it's like looking at cars and saying "well that one's wheels are flat, so it's no good" without knowing that the problem is painting someone's living room |
| 09:15 | <hsivonen> | Hixie: note that my first email to the thread was almost entirely questions |
| 09:15 | <Hixie> | yeah |
| 09:15 | <hsivonen> | Hixie: and my latest is explaining one of the questions |
| 09:16 | <Philip`> | Hixie: It's like someone proposes "let's all use this car", and you say "that one uses babies as fuel instead of petrol", and so you can easily discard the proposed solution, without having to go through the long complex process of working out what the problem was |
| 09:17 | <Hixie> | Philip`: maybe the problem is that the babies are all turning evil and the car combustion engine is actually somehow an evil purifier |
| 09:17 | <Hixie> | ok that response got away from me somehow |
| 09:19 | <Philip`> | Even if it could be safely used for purifying evil babies, if you unleash it on the world nobody's going to understand the details or the implications and they'll just stick any common or garden baby in there as long as it makes the engine go round |
| 09:20 | <Hixie> | well, i can't argue with the line of reasoning that namespaces kills babies, certainly |
| 09:26 | hsivonen | wonders what should happen if a script removes the defer attribute or the src attribute of a defer script before EOF is parsed |
| 09:26 | hsivonen | opens the spec |
| 09:26 | <Philip`> | (Also the fuel tank looks like a baby seat in the back of the car, so people who upgrade to this new model of car will be surprised when the function of the apparent seat turns out to be incompatible with the old behaviour) |
| 09:26 | <hsivonen> | analogy carried too far? |
| 09:26 | <Philip`> | Analogies can never be carried too far |
| 09:39 | <hsivonen> | Hixie: is it intentional that inline scripts with async are async? |
| 09:39 | <hsivonen> | Hixie: why isn't async only for external scripts? |
| 09:39 | <Hixie> | is this a trick question...? |
| 09:40 | <hsivonen> | Hixie: not a trick question |
| 09:40 | <Hixie> | then i dunno, i guess it just made sense to me |
| 09:40 | <Hixie> | why would it not apply? |
| 09:40 | <hsivonen> | If an inline script has async set, are there any differences compared to inline scripts without async? |
| 09:40 | <hsivonen> | does document.write() work? |
| 09:41 | <Hixie> | Atom makes a bunch of stuff required that i don't know how to fake |
| 09:41 | <Hixie> | like "author" |
| 09:41 | <Hixie> | hsivonen: document.write() does not work |
| 09:41 | <Hixie> | hsivonen: as far as i recall |
| 09:41 | <Hixie> | hsivonen: i honestly don't think i gave much thought to inline <script>s with async |
| 09:41 | <hsivonen> | Hixie: are you sure that's a good idea? |
| 09:41 | <Hixie> | i don't know why anyone would do that |
| 09:42 | <Hixie> | then again they do it with defer, i guess |
| 09:42 | <hsivonen> | right |
| 09:42 | <Hixie> | if you want it changed, it's an easy fix, file a bug |
| 09:42 | <hsivonen> | ok |
| 09:42 | Hixie | wonders what to do about the conversion to atom now that he's removing the predefined vocabs, given that it relied on vcard |
| 09:43 | <hsivonen> | Hixie: remove conversion to atom? |
| 09:43 | <Hixie> | that rather fails to address the use case of replacing atom with html to reduce repetition |
| 09:48 | <hsivonen> | hey! async on inline script is the promise not to do document.write! it would allow an optimization in speculative parsing |
| 09:49 | <hsivonen> | still dangerously backwards-incompatible, though :-( |
| 09:50 | <hsivonen> | and people who do serious scripting on user-facing sites tend to use external scripts anyway |
| 10:18 | hsivonen | wonders if the sentence "Changing the src, type, charset, async, and defer attributes dynamically has no direct effect; these attribute are only used at specific times described below (namely, when the element is inserted into the document)." is correct |
| 10:19 | <hsivonen> | Gecko considers those at the time the end tag is parsed |
| 10:19 | <hsivonen> | not when the element is inserted |
| 10:20 | <hsivonen> | hmm. maybe I'm wrong |
| 10:21 | <annevk2> | is there an observable difference? |
| 10:22 | <jgraham> | With innerHTML maybe? |
| 10:23 | <zcorpan_> | hsivonen: doesn't the parser run the script when the end tag is parsed per html5? |
| 10:23 | <hsivonen> | zcorpan_: yes |
| 10:24 | <hsivonen> | annevk2: yes, if the parser inserts the element, spins the event loop, timeout runs and the parser continues and parses the end tag |
| 10:24 | <hsivonen> | zcorpan_: yes |
| 10:26 | <annevk2> | ooh right |
| 10:26 | <annevk2> | tricky |
| 11:05 | annevk2 | finds out that because of "The HTTP Origin header" draft CORS does not need to depend on HTML5 anymore |
| 11:15 | <MikeSmith> | annevk2: so we should take the Origin spec and CORS to PR together in WebApps |
| 11:25 | <hsivonen> | MikeSmith: can WebApps take the Origin spec to PR if the IETF has the spec? |
| 11:26 | <MikeSmith> | hsivonen: IETF and HTTP WG in particular said they were not interested in publishing the spec |
| 11:26 | <hsivonen> | ooh |
| 11:26 | hsivonen | has trouble keeping up with Origin politics |
| 11:36 | <beowulf> | part |
| 11:36 | <beowulf> | heh |
| 11:51 | <annevk2> | MikeSmith, Adam is still pushing it at IETF it seems |
| 11:51 | <annevk2> | MikeSmith, if they don't do it we should, yes, that makes sense |
| 11:53 | <MikeSmith> | annevk2: I can't imagine them changing their minds. the message was pretty much an unequivocal No the first time |
| 11:54 | MikeSmith | remembers there's an IETF/W3C coordination call some time soon and figures he should probably add this to the agenda |
| 11:54 | <hsivonen> | I hope the IANA still agrees to register Origin |
| 11:54 | <hsivonen> | oops. |
| 11:54 | <hsivonen> | it's already registered for CORS, right? |
| 11:55 | <annevk2> | yes |
| 11:56 | <annevk2> | MikeSmith, if that's the case maybe you should contact adam and ask him to reformat it so we can have FPWD? |
| 11:57 | <annevk2> | the concept it defines fits better at the W3C as well I think |
| 11:57 | <MikeSmith> | annevk2: yeah, I saw your e-mail comment about that |
| 11:58 | <hsivonen> | did proxy vendors ever comment on Origin? |
| 11:59 | <MikeSmith> | annevk2: dunno if there's ever been a spec "foo Concept".. maybe Origin Mechanism? |
| 12:00 | <MikeSmith> | annevk2: before Adam goes the trouble of reformatting, I will try to get some more info, by the end of next week, I think |
| 12:00 | <MikeSmith> | I think the Strict Transport Security spec fits better at the W3C as well |
| 12:01 | <annevk2> | yeah |
| 12:02 | <annevk2> | most things fit better at the W3C if alone for their non-ancient publishing format (though if it's just about publishing format I guess WHATWG wins :p ) |
| 12:04 | <hsivonen> | specs with scripts FTW! |
| 12:13 | <MikeSmith> | W3C specs can have scripts. there's nothing in pubrules or anything else I've looked at that says they're prohibited |
| 12:14 | <MikeSmith> | hsivonen: I don't remember anybody in the previous discussion explicitly stating that they were are a proxy vendor |
| 12:21 | <hsivonen> | MikeSmith: ok. is it just a matter of no one porting the crossref script to the W3C spec? |
| 12:22 | <hsivonen> | MikeSmith: not having explicit negative feedback from (people identifying selves as) proxy vendors is encouraging |
| 12:22 | <MikeSmith> | hsivonen: yeah |
| 12:22 | <MikeSmith> | about crossref script, yeah, pretty much |
| 12:23 | <MikeSmith> | I'm already using it on my markup draft though |
| 12:23 | <MikeSmith> | the single-page version of that |
| 12:23 | <MikeSmith> | http://dev.w3.org/html5/markup/spec.html |
| 12:24 | <MikeSmith> | e.g., if you to to http://dev.w3.org/html5/markup/spec.html#common.data.uri-mdl and click on the "uri" in orangered |
| 12:24 | <annevk2> | I wonder why that script does not work in Opera |
| 12:25 | MikeSmith | is due to lose battery power in 8 minutes |
| 12:25 | <annevk2> | oh, now it does |
| 12:25 | <annevk2> | hmm |
| 12:26 | <ato> | Was <dialog> taken out of the specification? |
| 12:26 | <annevk2> | yes |
| 12:26 | <ato> | I've been searching the archives, but what was the reasoning behind that? |
| 12:26 | <MikeSmith> | I plan to add a generated index from <dfn>s as an alternative to the xref script, for the multipage version |
| 12:27 | <annevk2> | ato, didn't address the use cases well enough and was only for a relatively minor use cases |
| 12:27 | <annevk2> | -s |
| 12:28 | <ato> | annevk2: Ok, thanks! |
| 12:49 | <annevk2> | hmm, referencing httpbis is a pain |
| 12:49 | <annevk2> | http is now all over the place :/ |
| 15:33 | <Omnipotent> | On this page: http://yankele.co.il/test/canvas.html why when I increase the "red" the red actually decreases, ? |
| 15:34 | <Omnipotent> | Anyone here? :P. |
| 15:35 | <Philip`> | Yes :-) |
| 15:36 | <jgraham> | No |
| 15:36 | <Philip`> | If you set e.g. red=0.99, what the arc() call is doing is taking the point at 'offset' on the second, and then the point that's 0.99 of the way around the circle in a clockwise direction |
| 15:37 | <Philip`> | and then you're drawing the arc between those two points in an *anti*-clockwise direction |
| 15:37 | <Philip`> | so it only fill 0.01 of the circle |
| 15:38 | <Omnipotent> | So basically it switches the start and end points? |
| 15:38 | <Philip`> | What you probably want is for the second point to be 0.99 around anticlockwise instead, so you'd have to use offset-Math.PI*2*red instead of Math.PI*2*red+offset |
| 15:39 | <Philip`> | (Uh, "'offset' on the second"? I think I meant "'offset' on the circle") |
| 15:39 | <Omnipotent> | Philip` - without the offset, it would start in a point I don't want it |
| 15:39 | <Omnipotent> | I want it to start at the bottom, like it does now. |
| 15:39 | <Omnipotent> | Or on the top for that matters. |
| 15:40 | <Philip`> | Omnipotent: You still have offset, you're just subtracting the red (so higher red values result in a point that's further around anticlockwise from offset) instead of adding it |
| 15:41 | <Philip`> | Try entering -0.1, -0.2, -0.3, ... in the 'red' input box and I think it gives the appearance you probably want |
| 15:41 | <Philip`> | so you just need to do that negation in the script where it uses red |
| 15:43 | <Omnipotent> | There we go. |
| 15:43 | <Omnipotent> | Ctx.arc(75,75,50,offset,-Math.PI*2*red+offset,true);. |
| 15:44 | <Omnipotent> | Now I just need to understand completely how it solved it XD. |
| 15:45 | <hsivonen> | I wish someone wrote down a litmus test that can be applied to determine if a particular solution constitutes "decentralized extensibility" |
| 15:45 | <Philip`> | hsivonen: I think the test requires colons |
| 15:46 | <hsivonen> | s/someone/rubys/ |
| 15:48 | <TabAtkins> | That thread is going really nicely, though. Relatively little in the way of rhetoric, and heavy on actual discussion. |
| 15:49 | <jgraham> | I was just going to praise hsivonen's ability to be level headed in the face of shrillness |
| 15:49 | <TabAtkins> | Only because you guys are putting so much effort into counteracting the rhetoric, though. |
| 15:49 | <TabAtkins> | Yeah. |
| 15:49 | Philip` | must be reading a slightly different thread to TabAtkins |
| 15:50 | <TabAtkins> | Philip`, I'm comparing it to previous threads about namespaces. >_< |
| 15:50 | jgraham | guesses he should actually do the praise rather than allude to it |
| 15:51 | <jgraham> | hsivonen: I admire you ability to be level headed in the face of shrillness and hyperbole |
| 15:51 | jgraham | should try to get better at that |
| 15:54 | <hsivonen> | jgraham: thanks |
| 15:55 | <TabAtkins> | hsivonen, Philip`, I also really admire y'all's ability to comport yourselves in that kind of thread. I wouldn't be able to. |
| 15:56 | <TabAtkins> | Which is why I've merely watched. I didn't want to increase the noise. |
| 16:00 | Philip` | generally tries to avoid posting about anything other than facts |
| 16:00 | <Philip`> | which makes life much simpler |
| 16:01 | <hsivonen> | Philip`: facts have a strong liberal bias, though |
| 16:12 | <jgraham> | In this case it seems like the facts about web compatibility should be enough to sink any proposal involving colons based on compatibility alone |
| 16:12 | <jgraham> | er, I just repeated myself |
| 16:13 | <hsivonen> | your are assuming your valuations of compat vs. desirability of colons |
| 16:13 | <Philip`> | The facts have just been about browser compability, not about web compatibility |
| 16:14 | <jgraham> | Philip`: I don't understand what you mean |
| 16:14 | <hsivonen> | aargh. the whole of www.cnn.com leaks one attribute holder in the parser |
| 16:14 | <hsivonen> | now I need to find out *where* |
| 16:14 | <jgraham> | hsivonen: I am making the normal assumption that proposals that would cause a marketshare hit to conforming browsers should be discarded |
| 16:15 | <hsivonen> | jgraham: you are part of the Vast Browser-Wing Conspiracy, so of course you value that |
| 16:19 | <Philip`> | jgraham: Showing that the proposed behaviour is incompatible with IE does not mean that it's incompatible with significant content on the web |
| 16:19 | <hsivonen> | jgraham: it would be *very* interesting too see MS ship and implementation of their proposal as the first mover |
| 16:19 | <hsivonen> | Philip`: good point |
| 16:19 | <Dashiva> | I smiled when Shelley implied that once Microsoft wanted to, they could immediately upgrade the entire IE6 installed base |
| 16:20 | <TabAtkins> | I wish they had such powers. |
| 16:20 | <hsivonen> | so I'm looking at a leak of one attribute value on www.cnn.com including all iframes |
| 16:21 | <Philip`> | It's surprisingly hard to find actual real examples of DOM/CSS code that would break if browsers did something more Namespacey |
| 16:21 | <Philip`> | (Namespacious?) |
| 16:21 | <hsivonen> | Philip`: I took a look at the CSS of Ubiquity XForms |
| 16:21 | <Dashiva> | Namespatial |
| 16:21 | <hsivonen> | Philip`: they seem to be pretty defensive |
| 16:21 | <Philip`> | hsivonen: I assume they test it in real XHTML too |
| 16:22 | <hsivonen> | Philip`: but OTOH, it would really suck for authors to have to be that defensive |
| 16:22 | <Philip`> | Lots of content seems to test for document.namespaces |
| 16:22 | <Philip`> | and use that for e.g. VML |
| 16:22 | <hsivonen> | Philip`: where in a normal HTML case you'd have one Selector and ruleset, they have 4 selectors and 2 rulesets |
| 16:22 | <Philip`> | so it seems lots of IE-only content would break if IE removed that |
| 16:22 | <jgraham> | Philip`: If the Great Opera Namespace Experiment had the results ascribed to it by legend then there is sufficient breaking content that colons are out |
| 16:23 | <jgraham> | Sadly I don't know where to find the definitive data about that |
| 16:23 | <Philip`> | jgraham: Legends != facts :-p |
| 16:23 | <Philip`> | (in general) |
| 16:24 | <jgraham> | Yeah, which is why I would like some data |
| 16:24 | <jgraham> | But I guess it is a few bug reports in the database somewhere |
| 16:26 | <Philip`> | DSK-117765 sounds relevant |
| 16:31 | <jgraham> | Yeah it is hard to tell what was specific to our implementation and what was a generic problem. But there are specific sites listed and some generic problems with e.g. content produced in Word |
| 16:36 | <Philip`> | The specific problems listed seem to be partly about default namespace declarations on HTML elements, and partly seemingly about Opera treating <foo:bar> similar to the HTML element <bar> (where <bar> = <a> and <p>) |
| 16:38 | <Philip`> | Actually I suppose at least the one with <foo:a> might have been triggered by <style>a { text-decoration: underline }</style> in theory |
| 16:44 | Philip` | tries importing a ~6GB SVN repository into hg and git, and concludes that git is quite a lot faster |
| 17:07 | <Philip`> | (...although "faster" just means ~4 hours, vs unknown-but-several-times-larger) |
| 17:46 | <AryehGregor> | Philip`, I think |
| 17:46 | <Philip`> | AryehGregor: You are |
| 17:47 | <AryehGregor> | Philip`, I think I once tried timing an svn checkout of mediawiki trunk, against a git clone of mediawiki trunk+branches+tags+all history. And IIRC, the svn checkout was in the same datacenter, and the git clone was across the Atlantic. And git was faster. |
| 17:47 | <AryehGregor> | (I could be misremembering something, okay) |
| 17:48 | <AryehGregor> | But git svn is horribly slow. The translation from svn to git takes forever. git svn rebase takes like a second per commit, or an appreciable fraction thereof, and new branches can take an eternity to process. |
| 17:48 | AryehGregor | is pushing MediaWiki to use git proper for exactly this reason |
| 17:48 | <Philip`> | SVN doesn't seem to be the most efficient user of HTTP in existence |
| 17:48 | <Philip`> | but I'm just doing everything with file:/// |
| 17:48 | <AryehGregor> | Yeah, to be fair, I was using http:// for SVN and git:// for git, so that's not so fair. :P |
| 17:48 | <Philip`> | (after having rsynced the SVN repository) |
| 17:49 | <Philip`> | Fortunately this SVN repository has zero branches |
| 17:49 | <Philip`> | so that part is not a problem |
| 17:49 | <AryehGregor> | "Perhaps the real issue is we're not all speaking the same "language", and I don't mean English or otherwise. You're seeing the proposal from one view, I'm seeing it from another, and we haven't established a common communication means to express ourselves to one another." +5 Insightful |
| 17:50 | <Philip`> | -1 Obvious :-p |
| 17:51 | <Philip`> | I think I failed to see a response to hsivonen's question of what anyone means by "decentralized extensibility" |
| 17:52 | <Philip`> | which is probably critical for establishing a common communication means |
| 17:52 | <AryehGregor> | They mean "decentralized extensibility", duh. |
| 17:52 | <AryehGregor> | I think it's fairly obvious. |
| 17:52 | <AryehGregor> | It means "a mechanism for people to make up new nonstandard stuff without knowing about all the other people doing so". |
| 17:53 | <Philip`> | That's easy, just use class attributes |
| 17:53 | <AryehGregor> | The appropriate question is, what are the specific deficiencies in things like microdata or <object> that require this? |
| 17:53 | <AryehGregor> | Right. |
| 17:53 | <AryehGregor> | Microsoft's proposal mentioned a few things, like CSS selection, but they seemed very weak. |
| 17:53 | <Philip`> | The literal meaning is clearly not the whole of what anyone means when they're asking for decentralized extensibility |
| 17:54 | <AryehGregor> | Well, the question is what deficiencies they find in the existing stuff like class. |
| 17:54 | Philip` | waits patiently while git gc compresses 42999 objects |
| 17:55 | <Philip`> | Hmm, does git gc want to load the entire repository into RAM? |
| 17:55 | <Dashiva> | AryehGregor: Class is kind of a red herring even, since it's rather weak compared to @data-* and microdata and RDFa lined up as well |
| 17:56 | <Philip`> | Compression progress: 2% |
| 17:56 | <Philip`> | Memory usage: 800MB |
| 17:56 | <Philip`> | and growing |
| 17:56 | <AryehGregor> | Philip`, probably not the whole repository, no, but as a general rule git doesn't handle huge files or repos too well. |
| 17:56 | <AryehGregor> | What kind of repository is it? |
| 17:56 | <TabAtkins> | Dashiva: Even with its weakness, jQuery UI works pretty well with it. |
| 17:57 | <Dashiva> | TabAtkins: True, just saying you should consider the entire available toolset |
| 17:57 | <Philip`> | AryehGregor: It's the kind that's been imported via git-svn, from a repository with lots of binary files (but not many more than a few tens of megabytes each) |
| 17:57 | <AryehGregor> | Binary files a few tens of megabytes each sounds bad. |
| 17:57 | <TabAtkins> | I haven't ever heard anything to address the basic problem of how accessibility software is supposed to deal with "distributed extensibility". |
| 17:58 | <Dashiva> | TabAtkins: Distributed accessibility :D |
| 17:58 | <AryehGregor> | For one thing, compression won't work so well, so if they change, the repo will be pretty huge. |
| 17:58 | <TabAtkins> | Specifically of the "mint new namespaced elements" variety. |
| 17:58 | <Philip`> | AryehGregor: SVN handles them with no problem ;-) |
| 17:58 | <AryehGregor> | TabAtkins, we should just replace accessibility software by hiring people from third-world countries to explain the pages to the blind people. From what I've heard, it would probably cost less than JAWS. |
| 17:59 | <AryehGregor> | Philip`, SVN doesn't keep the whole history of the repo in every checkout. |
| 17:59 | <Philip`> | AryehGregor: It keeps the whole history of the repository in the repository, though |
| 17:59 | <Philip`> | AryehGregor: and that works fine |
| 17:59 | <AryehGregor> | Using git for anything that's not source-code-like is potentially dangerous. |
| 17:59 | <TabAtkins> | Crowdsourcing as replacement for algorithms. It's being done already, I guess. |
| 17:59 | <AryehGregor> | Yes, but that doesn't affect checkout time. |
| 18:00 | <AryehGregor> | Anyway, git might end up not being so good for this kind of thing. For source code (or similar) it's great. |
| 18:00 | <AryehGregor> | Try it and see. |
| 18:00 | <Philip`> | AryehGregor: Probably what I ought to do is expose a subset of the SVN repository that only has the code-like stuff |
| 18:00 | <Philip`> | and then clone that |
| 18:00 | <AryehGregor> | I had the bright idea of using it to do incremental backups of a multi-gigabyte .sql backup file. "git add" OOMed. |
| 18:00 | <Philip`> | but I wanted to see if it'd work with the whole repository first |
| 18:01 | <Philip`> | In practice I think I'll use Mercurial anyway |
| 18:01 | <Philip`> | but that's taking much longer to import from SVN |
| 18:02 | <Philip`> | Compression progress: 3% |
| 18:02 | <Philip`> | Memory usage: 1.2GB |
| 18:02 | <Philip`> | Compression progress: 5% |
| 18:03 | <Philip`> | Memory usage: 100MB |
| 18:03 | <Philip`> | That's good progress |
| 18:05 | <Philip`> | Maybe it was just loading an entire revision into RAM at once (some of them are ~600MB) |
| 18:05 | <AryehGregor> | Yes, I think it does that. |
| 18:09 | <Philip`> | TabAtkins: Instead of something like <input class="proprietary-special-thingy" readonly>, all you have to do is <proprietary:specialThingy role="textbox" aria-readonly="true"> plus a thousand lines of script library and then it'll work fine and be accessible and everything |
| 18:10 | <TabAtkins> | Philip`, brilliant! |
| 18:12 | <Philip`> | Well, you might have to wait five years until enough browsers support it |
| 18:12 | <Philip`> | but then finally you'll be able to write great markup like that |
| 18:12 | <TabAtkins> | I quiver with anticipation. |
| 18:52 | <Philip`> | Hmm, so that hour-long 'git gc' just finished, and saved a whopping 4% of my repository size |
| 18:53 | <Philip`> | s/4/12/ |
| 18:54 | <AryehGregor> | Because it's probably mostly binary files. |
| 18:55 | <AryehGregor> | I don't know if git even bothers trying to compress them. |
| 18:55 | <AryehGregor> | It probably assumes they're some small, mostly-static PNGs and such, like you'd find in most source-code repos. |
| 18:58 | Philip` | wishes it was possible to integrate SVN and hg/git/etc nicely |
| 18:58 | <Philip`> | so I could have all the source code in hg/git/etc, and all the art data in SVN |
| 18:59 | <Philip`> | and so nobody would have to understand the difference and would just run one 'update' command and one 'commit' command and it would all work like magic |
| 18:59 | <Philip`> | (on Windows too) |
| 18:59 | <AryehGregor> | Or someone should fix hg/git/etc. to handle big rapidly-changing binary files well. |
| 19:00 | <Philip`> | They'd also have to fix it so you don't have to download the whole repository |
| 19:01 | <Philip`> | (by excluding paths, and excluding history) |
| 19:02 | <AryehGregor> | Selectively excluding history, maybe, for large often-changing binary files. |
| 19:02 | <AryehGregor> | That would complicate the model considerably, of course. |
| 19:07 | <Dashiva> | So how many times has Shelley quit public-html? |
| 19:09 | <Philip`> | public-html, or the HTML WG? |
| 19:09 | <Dashiva> | public-html |
| 20:19 | <Hixie> | regenned with new microdata section; not yet uploaded |
| 21:18 | <smaug> | Hixie: ping |
| 22:20 | <Hixie> | smaug: pong |
| 22:21 | <smaug> | Hixie: just sent an email about session history, that I was going to ask about |
| 22:21 | <Hixie> | k |
| 22:29 | <Hixie> | i guess i should write a blog post about the usability study |
| 22:29 | <Hixie> | what <hx> level should i use in posts? |
| 22:31 | <hober> | are you asking for a bikeshed or are you serious? :) if serious, I use <h3> for highest-subsection-insid-a-post, allowing for <h1> as site-wide heading and <h2> as blog post title |
| 22:31 | <AryehGregor> | I guess he's asking if he should just use <h1> everywhere. |
| 22:32 | <hober> | (I say "allowing for" because these days I don't really have a site-wide heading, and am using <h1> for blog post titles. nevertheless, I keep with <h3> in case I change that.) |
| 22:32 | <gsnedders> | Hixie: You could try asking the guy who wrote the HTML 5 spec. |
| 22:32 | <Hixie> | i mean on the whatwg blog |
| 22:32 | <Hixie> | i guess i could look at the source |
| 22:33 | <Hixie> | but i'm lazy |
| 23:33 | <Hixie> | weird |
| 23:33 | <Hixie> | i just got a whole series of kernel panics |
| 23:34 | <Hixie> | all in panic(cpu 1 caller 0x0087D888): @/SourceCache/AirPortDriverAtheros5424/AirPortDriverAtheros5424-320.16.2/src/net80211/ieee80211_scan_sta.c:1787 |
| 23:40 | <Hixie> | i've no idea if this is the right line 1787, but if it is, i'm amused: |
| 23:40 | <Hixie> | http://fxr.watson.org/fxr/source/net80211/ieee80211_scan_sta.c#L1787 |
| 23:41 | Philip` | imagines it's quite unlikely for a comment to cause a panic |
| 23:42 | <Hixie> | well i'm sure the darwin version isn't quite line-for-lien aligned with that one |