| 01:27 | <zewt> | heh, i didn't notice on first (or third) reading the distinction between "the list of scripts that will execute in order as soon as possible" and the "set of scripts that will execute as soon as possible" |
| 01:58 | <zewt> | oh, apparently FF4 now does Opera's alerts-modal-to-the-tab ... finally |
| 07:42 | <zcorpan> | good morning whatwg |
| 07:44 | <annevk> | mornings |
| 08:02 | zcorpan | had a little vacation last week |
| 08:03 | <annevk> | nice |
| 08:56 | <Hixie> | oops, forgot to write a ccp for 127 |
| 09:00 | <annevk> | not so much happened last week |
| 09:02 | <zewt> | are there any major caching bugs with web workers and opera 11.01? (reloading the page doesn't seem to be reloading scripts) |
| 09:03 | <Hixie> | opera in general is aggressive in caching by default |
| 09:03 | <Hixie> | you can change the settings in the prefs |
| 09:03 | <zewt> | yeah but hitting ^R on a page should always revalidate |
| 09:03 | <Hixie> | if it doesn't, probably a bug then :-) |
| 09:04 | <zewt> | had to play foo.js?1 games to trick it, heh |
| 09:07 | <annevk> | so btw |
| 09:07 | <annevk> | if anyone has something they want me to include in WHATWG Weekly, say so |
| 09:09 | <zcorpan> | annevk: ah, a Weekly, that means i don't need to read my emails, right? :) |
| 09:10 | <annevk> | I wish I could summarize them all :) |
| 09:10 | <zewt> | no you don't :) |
| 09:14 | <Hixie> | btw if anyone wants to object to -148, please do so, as i'm not going to |
| 09:14 | <Hixie> | (my plan is to do whatever change julian wants and update the spec a year or two from now to match whatever implementations do then) |
| 09:17 | <Hixie> | nobody else other than me and tab has objections to the proposal to allow <a role=progressbar>? :-P http://www.w3.org/2002/09/wbs/40318/issue-129-objection-poll/results |
| 09:18 | <annevk> | I haven't taken the time yet, but it seems I should given the closing date |
| 09:19 | <Hixie> | othermaciej: what's the deadline for CCPs for -144? The issue-status page claims the status is the CCP phase but there's no deadline listed |
| 09:19 | <othermaciej> | checking... |
| 09:19 | <othermaciej> | Hixie: the next step is for the chairs to announce a call for alternate proposals |
| 09:20 | <othermaciej> | so no action for the WG yet |
| 09:20 | <Hixie> | ah ok |
| 09:20 | <Hixie> | my bad, misread it |
| 09:20 | <othermaciej> | (though of course it's always fine to submit early) |
| 09:21 | <Hixie> | no offence, but these CCPs are wasting plenty enough of my time already without my writing them before i've given everyone else every chance to either retract their objection or provide their own counter-objection |
| 09:22 | <othermaciej> | none taken |
| 10:09 | <annevk> | http://blog.whatwg.org/weekly-synchronized-media |
| 10:12 | <annevk> | it's a little short as I'm not feeling very inspired today |
| 10:20 | annevk | fires up Windows 7 |
| 10:20 | <zewt> | my condolences |
| 10:21 | <annevk> | it's boxed :) |
| 10:21 | <zewt> | it's not much of an improvement to step on a pile of poo if it happens to be in a box |
| 10:24 | <annevk> | isn't the whole idea of virtual boxing that such a thing cannot happen? :) |
| 10:29 | <jgraham> | Maybe "fires up" === douses in petrol and conflagrates it |
| 10:32 | <annevk> | so only IE9 has DOM Events support? |
| 10:32 | <jgraham> | Only IE9 has addEventListener at least |
| 10:33 | jgraham | wonders how the "proposal for seperating script download and execution" thread missed out on WHATWG weekly. But maybe it was last week too |
| 10:35 | <annevk> | it was already there |
| 10:38 | <annevk> | "restart your computer" |
| 10:38 | <annevk> | omg this is slow |
| 10:40 | <jgraham> | Installing IE9? |
| 10:41 | <jgraham> | Yeah, I managed to install 3.5 other browsers in the time it took to install IE9 |
| 10:45 | <annevk> | zewt, IE/Opera have a static list; Gecko/WebKit allow removal of listeners |
| 10:45 | <annevk> | zewt, guess I'll go with IE/Opera as DOM3Events says that too |
| 10:46 | <zewt> | hmm |
| 10:49 | <zewt> | event listeners added to the current event target during the event aren't fired in opera, at least, assuming my quick test is correct |
| 10:50 | <zewt> | probably in all browsers, for that case |
| 10:50 | <zewt> | at least that simplifies it--eg. static list operating on a copy doesn't need any special "dead handler" handling |
| 10:51 | <annevk> | indeed |
| 11:04 | <annevk> | should preventDefault() only work while the dispatch flag is set? |
| 11:05 | <annevk> | I guess it does not really matter |
| 11:07 | <zewt> | hmm, it matters if you call preventDefault before dispatching the event, right? particularly since you have dom-core resetting the cancelled flag at the start of dispatching, where dom-3 does it at the end ... if you can preventDefault while it's not being dispatched, that difference would be exposed |
| 11:07 | <annevk> | Hixie, you still around? |
| 11:08 | <annevk> | Hixie, it seems that multiple file upload requires breaking the multipart/form-data standard further: http://my.cn.opera.com/community/forums/topic.dml?id=841672&page=1 |
| 11:08 | <annevk> | zewt, yeah only then is when it matters |
| 11:09 | <annevk> | zewt, and I was wondering whether initEvent should reset it if we allow for it |
| 11:09 | <annevk> | zewt, it seems WebKit allows it and does not reset it when you invoke initEvent |
| 11:09 | <annevk> | and that works for me |
| 11:15 | <zcorpan> | are you guys speccing dom events? |
| 11:18 | <zewt> | what about how the cancel flag reset difference is exposed--any way to reconcile that? |
| 11:20 | <zewt> | or is it just a question of getting the dom spec adjusted too |
| 11:23 | <annevk> | zcorpan, it's pretty much done |
| 11:23 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events |
| 11:23 | <annevk> | plus fixes in https://bitbucket.org/ms2ger/web-dom-core |
| 11:23 | <zcorpan> | nice! |
| 11:23 | <annevk> | that await Ms2ger regen skills |
| 11:24 | <zcorpan> | "The timeStamp attribute must be useless. Come on!" lol |
| 11:28 | <zcorpan> | an order of magnitude better than dom3 events |
| 11:30 | <annevk> | thanks, that was the goal :) |
| 11:30 | <zcorpan> | annevk: i guess the Historical section needs some new stuff now |
| 11:31 | <annevk> | yeah, there's a comment just below the Events heading with some info |
| 11:31 | <annevk> | I did update Goals to make more sense |
| 11:32 | <annevk> | I actually want to remove Historical at some point but for now I suppose it should be kept |
| 11:33 | <zcorpan> | annevk: i asked for event interfaces to become constructors at some point, for easier creation of events and to allow event creation in workers |
| 11:34 | <annevk> | I know, but I don't really like it |
| 11:34 | <annevk> | and it's not too hard to create an event |
| 11:35 | <zcorpan> | it's pretty hard in workers :) |
| 11:35 | <annevk> | I did think of allowing e.g. document.createEvent("customevent", "teehee", false, false, {"data":"teehee"}) as some kind of create and initialize shortcut |
| 11:36 | <annevk> | Web Workers could define a createEvent event method that worked identical to document.createEvent() |
| 11:36 | <annevk> | it's not very hard |
| 11:36 | <annevk> | works* |
| 11:36 | <annevk> | if people actually care about synthetic events there |
| 11:37 | <zcorpan> | true |
| 11:37 | <annevk> | zcorpan, I did make initEvent arguments optional |
| 11:37 | <zcorpan> | yep |
| 11:37 | <jgraham> | Creating an event is super hard |
| 11:37 | <annevk> | so now you can do e = document.createEvent("event"); e.initEvent("teehee") and bubble/cancelable default to their initial values |
| 11:38 | <annevk> | jgraham, with one method call you have an event you can use |
| 11:38 | <annevk> | jgraham, with another you can set its name |
| 11:38 | <jgraham> | Well that sounds like one too many already |
| 11:38 | <zewt> | making dom events seems less important in workers, but it does seem sort of like the one little piece that's not there |
| 11:39 | <annevk> | well, people want DOM access in workers |
| 11:39 | <zewt> | (and I probably only see it as less important since I havn't hit any use cases for it yet--and that's probably just because I havn't used workers much yet) |
| 11:39 | <annevk> | if that is coming having a separate event constructor is not needed |
| 11:39 | <jgraham> | You can't have DOM access in workers… |
| 11:39 | <zcorpan> | foo.dispatchEvent(new Event('bar')); seems a lot nicer than var e = document.createEvent('event'); e.initEvent('bar'); foo.dispatchEvent(e); |
| 11:39 | <zewt> | you can have narrow, carefully-defined parts of the DOM API, though |
| 11:39 | <annevk> | with separate processes you can |
| 11:40 | <jgraham> | Well maybe |
| 11:40 | <zcorpan> | annevk: why don't you like constructor? |
| 11:40 | <annevk> | zcorpan, with my idea you could do foo.dispatchEvent(document.createEvent("event", "bar")) |
| 11:40 | <jgraham> | But I think gating features on mjor architectural change in browsers is not a good idea |
| 11:40 | <zcorpan> | annevk: ah |
| 11:40 | <annevk> | zcorpan, quite a bit of complexity for making a niche feature easier to use |
| 11:40 | <zcorpan> | annevk: wfm |
| 11:40 | jgraham | likes zcorpan's syntax better |
| 11:41 | <jgraham> | But then we should also make Element et. al. constructors |
| 11:41 | <annevk> | jgraham, it's not really gating the feature on that, in general there's not really demand for the feature in the first place |
| 11:41 | <zcorpan> | let's not :) |
| 11:41 | <jgraham> | The design of DOM with all the factory functions is just annoying |
| 11:41 | <zcorpan> | new HTMLMediaElement('div'); woot |
| 11:42 | <jgraham> | zcorpan: What makes you think that would work? |
| 11:42 | <annevk> | jgraham, write a library that abstracts it away :) |
| 11:42 | <jgraham> | annevk: Well there are alreasy libraries |
| 11:42 | <zcorpan> | jgraham: what's your proposal? |
| 11:42 | <jgraham> | Doesn't mean that DOM ought to suck |
| 11:43 | <annevk> | jgraham, well it does and making it vastly more complex is not going to make it suck less :) |
| 11:43 | <jgraham> | zcorpan: I guess it would have to throw if you tried to createelement an element that didn't implement the interface, or something |
| 11:44 | <jgraham> | In general having one interface per element would have been nice |
| 11:44 | <jgraham> | s/createelement/construct/ |
| 11:44 | <jgraham> | Anyway, this should still work for events |
| 11:45 | <zcorpan> | jgraham: with constructors for elements you need to remember both the interface name and the element, which seems annoying, but already the case for events |
| 11:45 | <jgraham> | zcorpan: Right, it is less good for elements because DOM wasn't designed to make it work |
| 11:46 | <jgraham> | being able to do new HTMLVideoElement() would have been fine |
| 11:46 | <annevk> | I think most people don't really care about this so much |
| 11:46 | <annevk> | it's more how setting attributes and such is a pain, or content |
| 11:46 | <jgraham> | Probably not because they probably use jQuery because DOM sucks so much |
| 11:46 | <annevk> | they use innerHTML :) |
| 11:47 | <jgraham> | They use jQuery which uses innerHTML |
| 11:47 | <annevk> | anyway, I'm not gonna add features for now :) |
| 11:47 | <annevk> | but I would welcome review and tests of what is there |
| 11:48 | <zcorpan> | seems like a good plan to start with removing features |
| 11:48 | <annevk> | apart from the hasFeature design I have not killed anything I think |
| 11:48 | <annevk> | well |
| 11:48 | <annevk> | EventException is gone |
| 11:49 | <annevk> | and .type restrictions are gone |
| 11:49 | <annevk> | stopImmediatePropagation could be removed, but it seems somewhat useful |
| 11:50 | <annevk> | same for defaultPrevented |
| 11:50 | <zewt> | like i mentioned the other day, i've definitely hit at least one case where it would have helped |
| 11:50 | <annevk> | I want to add the "event handler attribute" model |
| 11:50 | <annevk> | I think |
| 11:51 | <annevk> | though since nothing needs it I'm not a 100% sure it's appropriate |
| 11:51 | <annevk> | but it seems that everything that defines an object that inherits from EventTarget wants them |
| 11:51 | <annevk> | so from that perspective... |
| 12:02 | <zcorpan> | annevk: what are your thoughts on cssom and http://www.w3.org/Bugs/Public/show_bug.cgi?id=11955 ? |
| 12:04 | <annevk> | I'm not sure what he means with "lots" |
| 12:05 | <annevk> | he's right about pointer-events, but that should be disabled anyway for cross-origin images |
| 12:07 | <zcorpan> | can pointer-events be disabled for cross-origin fonts too then? |
| 12:08 | <annevk> | click -> text -> drawn using same-origin font ? path : otherpath |
| 12:08 | <annevk> | it seems somewhat logical that it can |
| 12:08 | <annevk> | but I don't know for sure |
| 14:19 | <hsivonen> | Hixie: thanks for WONTFIXing http://www.w3.org/Bugs/Public/show_bug.cgi?id=11427 |
| 14:19 | <hsivonen> | (the xml:id thing) |
| 14:22 | <Peter`> | Hm. The charter extension mail on public-html says "There is a new a target date for Recommendation of mid-2014." |
| 14:22 | <hsivonen> | good luck getting two interoperable impls. by then |
| 14:24 | <jgraham> | If we have interoperable implementations by then, the testsuite wasn't good enough |
| 14:27 | <annevk> | not to worry, it can be extended again |
| 14:29 | <annevk> | "Therefore, to fulfill the W3C HTML Working Group's mission, W3C Director Tim Berners-Lee encourages the participants to begin discussion of requirements for future versions of HTML after HTML5 reaches Last Call." |
| 14:29 | <annevk> | http://www.w3.org/2011/02/htmlwg-pr.html |
| 14:30 | <Philip`> | Maybe the Rec requirements will be relaxed before 2014, so that they're not insanely impossible to reach without cheating |
| 14:30 | <annevk> | I sense "stable standard" must be some play on "living standard" :) |
| 14:30 | <hsivonen> | stable as in dead compared to living? |
| 14:32 | <annevk> | They also gave up marking HTML5 up as abbreviation, but they are still doing it for CSS and such |
| 14:33 | <annevk> | How they defend "stable" is full of bullshit though. |
| 14:34 | <annevk> | At least, hardly any of the standards W3C has produced to date that targeted browsers have been stable in the way they describe. |
| 14:35 | <annevk> | DOM Core, DOM Events, HTML4, CSS2, CSS1, DOM HTML, XML, DOM Style, etc. all have been substantially revised over the years. |
| 14:42 | <zcorpan> | http://www.w3.org/html/wiki/FAQs says Open Web Platform is the new HTML5 |
| 14:42 | <annevk> | "Starting in March, W3C will dedicate new staff to drive development of an HTML5 test suite." |
| 14:43 | <hsivonen> | zcorpan: I thought the Open Web Platform was the *old* HTML5 while Dion Almaer, Ben Galbraith and Brad Neuberg were still running that evangelism branch at Google |
| 14:56 | <zcorpan> | that faq talks a lot about <video> |
| 14:57 | <jgraham> | testsuite development++ |
| 15:00 | <hsivonen> | whoa. I'm lagging behind in email. How did the rechartering happen without epic political drama? does HTML5 now have so much brand clout that haters were too shy to hate? |
| 15:01 | hsivonen | hasn't inspected what went down in Member space |
| 15:01 | <annevk> | hsivonen, extensions do not have to be discussed |
| 15:01 | <annevk> | hsivonen, just an agreement between W3C Team and Chairs |
| 15:01 | <hsivonen> | annevk: I see |
| 16:32 | <TabAtkins> | jgraham: FWIW, we're trying to make the DOM run on constructors instead of factory functions. |
| 16:32 | <jgraham> | TabAtkins: "We"? |
| 16:33 | <TabAtkins> | Chrome. |
| 16:33 | <jgraham> | Um, OK. In what way? |
| 16:33 | <TabAtkins> | In that "new HTMLPElement()" should work, and be subclassable. |
| 16:34 | <jgraham> | You are planning to expose this to web content? |
| 16:34 | <annevk> | Larry Masinter suggests using Wikipedia for registries over on www-tag |
| 16:34 | <jgraham> | Interesting… |
| 16:34 | <annevk> | wfm |
| 16:34 | <TabAtkins> | Once we get it working, yes. |
| 16:34 | <jgraham> | new HTMLMediaElement("div") -> ? |
| 16:34 | <jgraham> | Or do you have one interface per element? |
| 16:34 | <TabAtkins> | The latter, presumably. |
| 16:34 | <jgraham> | s/interface/constructor/ |
| 16:35 | <TabAtkins> | This is still in a handwavey stage in terms of details. |
| 16:35 | <jgraham> | OK |
| 16:35 | <TabAtkins> | But we're poking at V8 to see how we can do this and allow subclassing like a normal JS object. |
| 16:35 | <TabAtkins> | While still wiring up the appropriate binding magic on the back-end. |
| 16:36 | <jgraham> | subclassing === function MyP(){}; MyP.prototype = HTMLPElement? |
| 16:36 | <TabAtkins> | Yes. |
| 16:36 | <TabAtkins> | (I see no reason not to use established terminology just because we use a different model of OO.) |
| 16:37 | <jgraham> | So, obviosuly I like the idea, but why are you doing this? |
| 16:37 | <TabAtkins> | Because factory functions are ugly, and DOM objects aren't subclassable. |
| 16:37 | <TabAtkins> | (This ties into the component model stuff we're doing.) |
| 16:37 | <jgraham> | (the inheritance thing seems like it might encourage dubious design patterns like putting custom functions on built-in objects) |
| 16:42 | <Philip`> | annevk: That'd work until someone deletes the registry because it's original research |
| 16:42 | <TabAtkins> | This is, of course, what the microformats wiki is for. |
| 16:45 | <annevk> | there's a lot of registries |
| 16:45 | <annevk> | I doubt microformats would want to host URL schemes |
| 16:46 | <TabAtkins> | Ask tantek. He's been sanguine about it before, I believe. |
| 16:59 | <TabAtkins> | How do you create an SVG image with just an aspect ratio, not an intrinsic width/height? |
| 17:02 | <annevk> | only setting viewBox="" ? |
| 17:02 | <annevk> | or is the intrinsic width/height 100%/100% then? |
| 17:02 | <TabAtkins> | Is that how you do it? I don't understand the relationship between width/height/viewBox. |
| 17:02 | <annevk> | I had a hard time figuring that out in the SVG spec last time I played with all that |
| 17:04 | <wilhelm> | I failed last time I tried. img { width:90%; } solved my problem, though. |
| 17:05 | <TabAtkins> | That doesn't help when you're using SVG in list-style-image. |
| 17:09 | <erlehmann> | Hixie, is “The message's content type was not explicitly allowed” referring to application/pgp-signature attachments or a sniffing error on part of the web server? (fun fact: the message contained the string SRT) |
| 17:10 | <TabAtkins> | annevk: Okay, you're right. You can leave width/height alone and just set a viewbox to establish a coordinate system, then use one of the uniform-scaling preserveAspectRatio values. |
| 17:13 | <shepazu> | TabAtkins: annevk got it right |
| 17:13 | <TabAtkins> | shepazu: Yup, got it. Was just making sure I was right before I corrected a dude. |
| 17:15 | <annevk> | I wonder where I left my tests for this |
| 17:16 | <TabAtkins> | Ugh, I hate talking to Alan Gresley. The dude runs a css tutorial site, but he is usually *completely* wrong about everything. Somehow he manages to form a uniquely wrong understanding of technical topics that I care about. |
| 17:39 | <MikeSmith> | http://twitter.com/#!/__DavidFlanagan/status/37204148751433728 "I couldn't write #jstdg6 without the specification writers who document how the web really works. Let's send them some ♥ today!" |
| 17:40 | <Philip`> | Yeah, let's send every WHATWG member a bodily organ |
| 17:41 | <MikeSmith> | heh |
| 17:43 | <nimbupani> | omg are u all thanked yet? its #thankaspecwriterday https://twitter.com/html5/status/37205058638585856 |
| 17:43 | <jgraham> | Philip`: I recommend slow braising of your gift for maximum tenderness |
| 17:44 | <jgraham> | For example http://www.channel4.com/food/recipes/chefs/hugh-fearnley-whittingstall/devilled-hearts-recipe_p_1.html |
| 17:44 | <jgraham> | Although I wonder if I have ever actually eaten heart… |
| 17:49 | <TabAtkins> | jgraham: Heart's pretty good. |
| 18:15 | <jgraham> | TabAtkins: I would try it if I could find a decent supplier of meat here |
| 18:15 | <jgraham> | (well there is one but it is like >20km away so not a regular trip) |
| 18:16 | <jgraham> | (and I don't recall them having much offal) |
| 18:35 | <TabAtkins> | Dammit, Facebook, you distracted me into forgetting why I had CSS2.1 up. |
| 18:54 | <Hixie> | annevk: not sure what needs changing based on that thread |
| 18:56 | <Hixie> | i wonder what "broad interoperability" means |
| 18:57 | <Philip`> | Maybe it's the opposite of deep interoperability |
| 18:57 | <Hixie> | that's kinda what i assume |
| 18:57 | <Philip`> | so everyone has to implement all the features but don't worry too much about the details because they'd take forever |
| 18:57 | <Hixie> | dunno how else we'll be reaching it by 2014 |
| 18:59 | <Hixie> | annevk: nm i see the bug |
| 19:00 | <Hixie> | annevk: though i'm not sure <input type=file multiple> counts as a single form field from the perspective of the rfc, so technically i don't think this is a violation |
| 19:23 | <TabAtkins> | Hixie: Regarding the behavior of <style scoped> and @-rules, should a @font-face defined in a scoped stylesheet be available for use in a scoped stylesheet of a descendant? |
| 19:24 | <TabAtkins> | I think the answer is yes, but I'm not 100% sure from the definition in HTML. |
| 19:25 | <Hixie> | "For scoped CSS resources, the effect of @-rules must be scoped to the scoped sheet and its subresources", so no |
| 19:25 | <TabAtkins> | Oh, ok. |
| 19:25 | <TabAtkins> | Hmm. I guess that's okay. |
| 19:28 | <Hixie> | the theory is that a further scoped stylesheet is likely for a nested syndicated item of content, and you wouldn't want to afflict your declarations on third-party content |
| 19:28 | <TabAtkins> | Ah, good point. |
| 20:16 | <erlehmann> | anyone knowing how this is gonna be fixed? https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information |
| 20:17 | <Ms2ger> | There's been ideas |
| 20:17 | <othermaciej> | break on error for cross-site loads seems like the most likely possibility |
| 20:27 | <benschwarz> | Hixie, resize the browser on the dev spec (narrow) |
| 20:28 | <Hixie> | neat |
| 20:28 | <Hixie> | and the appcache stuff is awesome btw |
| 20:28 | <Hixie> | so freaking fast |
| 20:28 | <benschwarz> | :) |
| 20:28 | <benschwarz> | almost there Hixie… |
| 20:28 | <Hixie> | wasn't sure what the "syncing..." thing was but i guess that's appcache also? |
| 20:29 | <benschwarz> | yeah |
| 20:29 | <benschwarz> | Hixie check it in chrome |
| 20:29 | <benschwarz> | it has a progress percentage |
| 20:29 | <Hixie> | that's what i was using |
| 20:30 | <benschwarz> | mobile safari doesn't support the progress event very much :/ |
| 20:30 | <Hixie> | i thought it was maybe syncing the search index, but that seemed to be a big download for just searching the toc |
| 20:30 | <Hixie> | maybe it should say "updating cache" or some such |
| 20:30 | <benschwarz> | Hixie, perhaps yeah, the label is wrong |
| 20:30 | <Hixie> | dunno what normal people would understand :-) |
| 20:31 | <Hixie> | i'm obviously not the right person to target for this :-) |
| 20:31 | <benschwarz> | these 'normal people' are web nerds |
| 20:32 | <benschwarz> | Hixie the double refresh appcache thing is really annoying though |
| 20:33 | <Hixie> | double refresh? |
| 20:37 | <benschwarz> | Hixie to clear the appcache / see the changes once synced |
| 20:37 | <benschwarz> | like what happened to you… |
| 20:37 | <benschwarz> | Hixie before I dive off to work, I wanted you to see http://germanforblack.com/articles/taking-the-web-back |
| 20:37 | <Hixie> | oh that's just a matter of making sure you wait for it to download and then reloading |
| 20:37 | <Hixie> | we could have it put up a little banner that says "updates ready, click here to reaload" if you want |
| 20:39 | <Hixie> | benschwarz: looks good |
| 21:03 | <TabAtkins> | jgraham: You don't have a butcher nearby? |
| 21:04 | <Hixie> | argument in favour of turning the web from using javascript to using bytecode as the basic language that browsers execute: |
| 21:04 | <Hixie> | > Bytecode contains no unnecessary bytes. No spaces, no line-endings, no tabs. Only opcodes that do precisely one thing, and only that. |
| 21:05 | <Ms2ger> | Eh? |
| 21:05 | <Hixie> | indeed |
| 21:06 | <Hixie> | see bytecode has no whitespace so there are going to be fewer bugs |
| 21:06 | Hixie | nods encouragingly |
| 21:06 | <zewt> | because opcodes in dynamic languages don't ever do more than one thing (err) |
| 21:06 | <Ms2ger> | I see |
| 21:06 | <bfrohs> | Is THAT how that works? hahah |
| 21:06 | <TabAtkins> | Was there more context that suggests this meant "less bugs"? |
| 21:06 | <Hixie> | yeah, long e-mail |
| 21:06 | <TabAtkins> | Or was it just an argument that bytecode is smaller? |
| 21:06 | <Hixie> | no, it was an argument that browser vendors wouldn't introduce as many bugs in their bytecode processor as they do in their JS processor |
| 21:07 | <TabAtkins> | Oh. That's retarded. |
| 21:07 | <zewt> | heh |
| 21:07 | <Ms2ger> | How about we only allow certified programmers to publish on the web? Seems like a good way to prevent bugs |
| 21:07 | <Hixie> | dunno about retarded. Ignorant, though, yes. |
| 21:07 | <zewt> | as if most interop problems center around the JS engine |
| 21:07 | <zewt> | javascript is possibly the simplest, most obvious language in common use today |
| 21:08 | <Ms2ger> | zewt, I'm not sure JS implementers would agree with that ;) |
| 21:08 | <Ms2ger> | Hixie, surely bugs are only in old code, and not in new? |
| 21:08 | <zewt> | Ms2ger: language complexity and optimized runtime complexity are entirely different things :) |
| 21:09 | <Hixie> | another argument in that e-mail: "bytecode opcodes often translate 1-on-1 to target machine instructions" |
| 21:09 | <zewt> | haha |
| 21:09 | Hixie | is reminded of the latest "how i met your mother" episode ("oh, honey...") |
| 21:09 | <zewt> | who's trolling hixie, i wonder |
| 21:09 | <AryehGregor> | Everyone knows that native machine code has no bugs. |
| 21:10 | <Hixie> | bbiab, food time |
| 21:13 | AryehGregor | installs https://chrome.google.com/webstore/detail/nolijncfnkgaikbjbdaogikpmpbdcdef, awesome |
| 21:13 | <AryehGregor> | I've wanted this for a while. |
| 21:13 | <Philip`> | Hixie: Is this email from the PNaCl developers? |
| 21:13 | <TabAtkins> | AryehGregor: Ah, cool, didn't realize that was public yet. |
| 21:14 | <jgraham> | TabAtkins: No, the nearest proper butcher is 25km away |
| 21:15 | <TabAtkins> | jgraham: Move someplace better. |
| 21:15 | <jgraham> | TabAtkins: Tell Opera that :p |
| 21:15 | <AryehGregor> | A butcher as in someone who slaughters animals on-site? |
| 21:15 | <TabAtkins> | Opera: Move jgraham someplace better. |
| 21:15 | <TabAtkins> | AryehGregor: No, just someone who'll cut down an animal by request. |
| 21:15 | <AryehGregor> | Oh, so you give them the animal to slaughter? |
| 21:15 | <TabAtkins> | I've never seen a butcher who actually does the killing themselves. |
| 21:16 | <AryehGregor> | Or what? |
| 21:16 | AryehGregor | is confused |
| 21:16 | <jgraham> | AryehGregor: Abatoirs do the slaughtering |
| 21:16 | <AryehGregor> | In my experience, "butcher" is more or less interchangeable with "meat-seller". |
| 21:16 | <TabAtkins> | ...No, a butcher has a bunch of (dead) animals, and they'll cut it down. |
| 21:16 | <jgraham> | Butchers cut up the carcass |
| 21:16 | <AryehGregor> | Oh, I see. |
| 21:16 | <AryehGregor> | My dictionary says it can mean both. |
| 21:16 | <TabAtkins> | Get a better dictionary. |
| 21:16 | <AryehGregor> | And an abattoir is a slaughterhouse, not a slaughterer. |
| 21:17 | <AryehGregor> | What does your dictionary say, then? |
| 21:17 | <TabAtkins> | I don't have one. |
| 21:17 | <jgraham> | Right, the people at the slaughterhouse don't have a special name afaik |
| 21:17 | <AryehGregor> | So you rely on what, making stuff up? |
| 21:17 | <AryehGregor> | "slaughterers" |
| 21:17 | <TabAtkins> | It's worked so far! |
| 21:17 | <TabAtkins> | All my definitions are cromulent. |
| 21:18 | <jgraham> | Well yes, if you are a radical egan they are probably "murderers" or something |
| 21:18 | <Ms2ger> | It worked out with frex,frex |
| 21:18 | AryehGregor | is probably confused in part because 90% of the discussion he's been part of regarding the slaughter of animals is specifically in the context of kosher food, which might be different and where some of the terminology is in Hebrew or Yiddish or Aramaic |
| 21:18 | <jgraham> | *vegan |
| 21:18 | <TabAtkins> | I didn't invent that one, to be fair. |
| 21:18 | jgraham | wonders why that chrome extension isn't just a feature of google.com |
| 21:19 | AryehGregor | too |
| 21:19 | <AryehGregor> | It seems kind of perverse. |
| 21:19 | <AryehGregor> | They let you say you like a result, so why not that you dislike it? |
| 21:19 | <TabAtkins> | I assume it's so we can experiment with it first. |
| 21:19 | <AryehGregor> | Google Search can't experiment? |
| 21:19 | <AryehGregor> | I thought they experiment all over the place. |
| 21:20 | <Ms2ger> | Oh no, Google will save which sites we dislike! |
| 21:20 | <zewt> | they've had (on and off) the little "x" to hide individual results in pages, which is pretty useless--i've wished many times that would apply to a whole domain |
| 21:20 | <jgraham> | Anyway, the meat related conversation was quite productive because I learnt that I can buy a 16kg box containing much of a butchered lamb |
| 21:20 | <jgraham> | Which is quite exciting |
| 21:20 | AryehGregor | is just waiting for the next experts-exchange.com or w3schools.com result to show up in a search |
| 21:20 | AryehGregor | goes off and does a search specifically to lure in w3schools.com results |
| 21:20 | <TabAtkins> | Oh man, I should trigger those purposely. |
| 21:20 | TabAtkins | does the same. |
| 21:21 | <AryehGregor> | I actually haven't seen experts-exchange.com results recently, though. |
| 21:21 | <AryehGregor> | So I'll let that one be. |
| 21:21 | <AryehGregor> | (until I see it) |
| 21:21 | <TabAtkins> | I find that experts-exchange is roughly as useful as other medium-tier things, once you use Stylish to hide all the bullshit they put before the actual answer. |
| 21:21 | <zewt> | i'm habitually doing site:*.w3.org when i'm doing w3-related searches now, specifically to avoid w3schools |
| 21:22 | <AryehGregor> | Yeah, once you know that you can scroll down to get the answer, it's not so bad. |
| 21:22 | <zewt> | even adding "w3" to a search still lands w3schools first |
| 21:22 | <AryehGregor> | I'm pretty sure they used to actually cloak the answer somehow, though. |
| 21:22 | <AryehGregor> | But they stopped at some point. |
| 21:22 | <Philip`> | zewt: Maybe add "-w3schools"? |
| 21:22 | <TabAtkins> | I'm sure that point was "when Google realized they were cloaking the answer". |
| 21:22 | jgraham | finds that putting "foo spec" is generally good |
| 21:23 | <AryehGregor> | Probably. |
| 21:23 | AryehGregor | seconds jgraham |
| 21:23 | <zewt> | i use site: since I use it a lot in general ... which is why it's still aggrevating that you can no longer turn off the disruptive search autocomplete :| |
| 21:25 | <AryehGregor> | You mean Google Instant? |
| 21:26 | <zewt> | no, suggestions (which also kills form autocomplete in firefox) |
| 21:27 | <AryehGregor> | Oh. |
| 21:27 | <zewt> | that reminds me--so many times I've wished for an api to introspect existing dom event listeners, usually for greasemonkey to be able to remove them, heh |
| 21:28 | <zewt> | have never hit any cases where i needed them on an actual page, though |
| 22:13 | <Hixie> | Philip`: thankfully no |
| 22:27 | <zewt> | Your message to whatwg awaits moderator approval |
| 22:27 | <zewt> | uhh. heh |
| 22:27 | <Hixie> | did it give a reason? |
| 22:27 | <zewt> | Too many recipients to the message |
| 22:27 | <Hixie> | ah |
| 22:27 | <Hixie> | let me whitelist it hold on |
| 22:27 | <Hixie> | but cut down next time :-P |
| 22:27 | <zewt> | list isn't configured for reply-all style discussion, heh |
| 22:28 | <Hixie> | well you shouldn't cc people who aren't actually who you're replying to anyway :-) |
| 22:29 | <zewt> | i can't exactly keep track of who expects a cc and who doesn't :P |
| 22:29 | <zewt> | which is no doubt why the list tends to be reply-all in the first place |
| 22:30 | <Hixie> | just send the mail to the people you're responding to :-) |
| 22:30 | <Hixie> | one should trim one's cc/to lists just like one should trim the context one is replying to |
| 22:31 | <zewt> | that's not the actual practice on the list, or on any list i've used |
| 22:31 | <Hixie> | lead by example :-) |
| 22:32 | <Hixie> | people often top-post and don't trim context, but that doesn't mean it's the right thing to do either |
| 22:32 | <zewt> | well, i don't think cc'ing at all is the right thing to do; i only do it because it's the practice of the list |
| 22:33 | <Hixie> | generally you should cc/to the people you want to have read/reply (respectively) |
| 22:33 | <zewt> | pointless when they're on the list, and of the dozens of lists i've been on nobody has ever expected people to manually edit cc lists :) |
| 22:34 | <zewt> | anyway, not that important either way |
| 22:36 | <MikeSmith> | http://www.belshe.com/2011/02/10/the-era-of-browser-preconnect/ is worth reading |
| 22:37 | <MikeSmith> | The downside of preconnect is a big part of why we’re working on SPDY. HTTP has been nothing short of a heroic protocol and made the Internet as we know it possible. But as we look to the next generation of rich media sites with low latencies, it is clear that today’s HTTP can’t perform at that level. |
| 22:37 | <MikeSmith> | SPDY hopes to solve much of HTTP’s connection problems while also providing better performance and better security. |
| 22:37 | <MikeSmith> | oops |
| 22:37 | <MikeSmith> | hadn't meant to paste quite all all that |
| 22:37 | <zewt> | the big thing I hope SPDY can help fix is the whole no certificate = no SSL at all problem |
| 22:38 | <MikeSmith> | hmm |
| 22:38 | <MikeSmith> | I guess that's a nice side effect |
| 22:38 | <zewt> | since from what I recall it's simply always encrypted |
| 22:38 | <MikeSmith> | yeah |
| 22:38 | <MikeSmith> | it's always using TLS |
| 22:39 | <MikeSmith> | iirc |
| 22:43 | <zcorpan> | forgive me, mime type gods, for i have sinned: i renamed a bunch of font files to .gif as to get around silly security policy on a friend's blog in order to use webfonts. good thing browsers ignore mime types |
| 22:44 | <zewt> | couldn't you at least rename them to something with no associated mime type at all, or does that not work either? |
| 22:44 | <aho> | for woff, otf, and ttf... yes |
| 22:45 | <Hixie> | heycam: did anything ever happen with the 'mixin interface' idea? |
| 22:45 | <aho> | svg fonts will likely break though, but i'm not sure if they are still required |
| 22:46 | <heycam> | Hixie, it's still likely to happen (along with those bunch of other things i mailed public-script-coord about late last year). but i can't get to editing webidl for another few weeks. |
| 22:46 | <aho> | zewt, with IIS... if the mime type isn't registered you get a 404 |
| 22:46 | <heycam> | Hixie, I'll write to public-script-coord as I make big changes like that |
| 22:47 | heycam | just sees your email now |
| 22:47 | <zewt> | haha |
| 22:47 | <zcorpan> | zewt: no, the blog software only allowed a handful of file extensions |
| 22:47 | <zewt> | i've had the fortune of never having to host anything on IIS |
| 22:47 | <zewt> | i mean to continue my streak |
| 22:48 | <Philip`> | zcorpan: Could you at least rename them to example.ttf.gif? |
| 22:48 | <zcorpan> | Philip`: that's what i did |
| 22:48 | <aho> | i called mine *.woff.txt etc :> |
| 22:48 | <Philip`> | or example.ttf.pretendingtobe.gif |
| 22:48 | <zewt> | this.is.not.a.text.file.txt |
| 22:49 | <zcorpan> | aho: i considered .txt but i thought maybe something somewhere would try to tamper with linebreaks and break the font, so i chose .gif instead |
| 22:49 | <zewt> | also helps to use a format that, if loaded blindly into a browser, will tend to just fail--if you use .txt then you'll end up spewing garbage on a person's window |
| 22:50 | <aho> | it's a shame that the bell character doesnt do anything in browsers :> |
| 22:50 | <heycam> | Hixie, (I'll respond to that mail when I context switch myself back to webidl editing in a few weeks, if that's ok) |
| 22:51 | <aho> | once i made my machine beep for over a minute by outputting some binary file on stdout... coworkers were not amused :> |
| 22:52 | <aho> | (there were no process to kill... it was already done... output was just lagging) :> |
| 22:53 | <Hixie> | heycam: absolutely |
| 22:53 | <Hixie> | heycam: thanks |
| 23:00 | <zcorpan> | http://www.456bereastreet.com/archive/201102/validating_html5_with_validatornu_and_the_html5validator_extension_for_firefox/ |
| 23:09 | <Hixie> | i haven't been reading this crypto thread... is it going to result in me making spec changes or is someone already editing a spec for it? |
| 23:12 | <Hixie> | TabAtkins: do you know where white-space:plaintext is defined? |
| 23:12 | <TabAtkins> | Hixie: abarth wrote a spec for the crypto stuff today. |
| 23:12 | <Hixie> | (i'm trying to make sure <textarea dir=auto> is specced to do the right thing but i dunno what that is) |
| 23:12 | <TabAtkins> | Let me see if I can find white-space:plaintext |
| 23:12 | <Hixie> | abarth++ |
| 23:13 | <abarth> | http://wiki.whatwg.org/wiki/Crypto |
| 23:13 | <abarth> | it doesn't include the legacy stuff yet |
| 23:13 | <Hixie> | there's legacy stuff? |
| 23:13 | <Hixie> | good to know |
| 23:13 | <Hixie> | gecko-only? |
| 23:13 | <TabAtkins> | Hixie: I don't think it's defined in a spec right now. Let me poke fantasai and see. |
| 23:13 | <Hixie> | TabAtkins: k |
| 23:14 | <abarth> | Hixie: as far as I know, web compat only requires that the object exist with that name |
| 23:14 | <abarth> | it doesn't actually need to do anything |
| 23:14 | <TabAtkins> | God, the white-space property is so bad. |
| 23:14 | <Hixie> | abarth: wow, that's some nutty compat requirement |
| 23:14 | <Hixie> | gotta love the web |
| 23:14 | <abarth> | i think people feature test |
| 23:14 | <MikeSmith> | zcorpan: wow |
| 23:14 | <TabAtkins> | Presumably, people are using window.crypto to UA-detect. |
| 23:15 | <abarth> | if (crypto. generateCRMFRequest) ... |
| 23:15 | <MikeSmith> | zcorpan: pretty cool |
| 23:15 | <abarth> | which works as long as crypto exists in the global scope |
| 23:15 | <Hixie> | hah |
| 23:15 | <Hixie> | nice |
| 23:15 | <abarth> | some of the features in gecko are good though |
| 23:16 | <abarth> | window.crypto.importUserCertificates |
| 23:16 | <abarth> | crypto. signText |
| 23:16 | <abarth> | etc |
| 23:16 | <abarth> | some are dumb: |
| 23:16 | <abarth> | crypto.disableRightClick() |
| 23:16 | <abarth> | :) |
| 23:16 | <Hixie> | o_O |
| 23:16 | <jamesr_> | wat |
| 23:17 | <abarth> | https://developer.mozilla.org/en/javascript_crypto |
| 23:17 | <abarth> | scroll to the bottom |
| 23:17 | <abarth> | i couldn't make this stuff up |
| 23:17 | <jamesr_> | at least it says "not implemented" |
| 23:18 | <ben_h> | that's what i was thinking :) |
| 23:19 | <zcorpan> | MikeSmith: yeah. it'd be cooler still with a browser validator that integrated with devtools |
| 23:19 | <MikeSmith> | yeah |
| 23:22 | <zcorpan> | wonder if it's possible to port the validation part of validator.nu to javascript |
| 23:30 | <MikeSmith> | zcorpan: yeah, possible, I think |
| 23:30 | <MikeSmith> | but there's a lot of pieces |
| 23:31 | <MikeSmith> | I think the integration would be the hard part |
| 23:57 | <annevk> | Hixie, it's not a violation as the RFC allows both ways |
| 23:57 | <annevk> | Hixie, it's just that one way doesn't work |