| 04:36 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#hit-regions opinions? |
| 05:06 | <Hixie> | zewt: network byte order is big-endian... |
| 05:11 | <Hixie> | hober: in case the chairs did give you the extension you asked for, addHitRegion() is in now. r7029. |
| 08:24 | hsivonen | wonders what kind of hoops one would have to jump through to obtain a big-endian device that has a WebGL-enabled Presto build on it |
| 08:27 | <gsnedders> | hsivonen: Buy a TV, I think. |
| 08:27 | <hsivonen> | gsnedders: but which TV? |
| 08:29 | <karlcow> | hsivonen: http://www.opera.com/press/releases/2011/01/19/ |
| 08:30 | <gsnedders> | hsivonen: I'm unsure whether we can disclose information about our partner's hardware. |
| 08:30 | <hsivonen> | gsnedders: ok. that's what I expected |
| 08:30 | <gsnedders> | Though if we ship with Typed Arrays, it's black-box observable anyway. |
| 08:31 | <hsivonen> | so telling a Web developer to test BE is basically telling them to go buy a TV and it's up to them to figure out which one |
| 08:31 | <hsivonen> | yeah, that'll work |
| 08:31 | <karlcow> | there is also http://www.opera.com/press/releases/2012/03/19_2/ |
| 08:31 | <gsnedders> | Apparently there are BE MIPS phones coming soon. |
| 08:32 | <karlcow> | "Opera TV browser with WebGL™ support are now available for MIPS-based DTVs, set-top boxes and other digital home devices." |
| 08:33 | <hsivonen> | I wonder how many months it will take Opera to decide to make ArrayBuffers on BE systems behave to scripts as if they were LE and burn cycles for byteswapped copies when passed to the GPU... |
| 08:34 | <hsivonen> | I don't see any realistic way to stop Web authors from publishing code that assumes that ArrayBuffers are LE |
| 08:36 | <gsnedders> | hsivonen: More practically, I wonder if we could get out a copy of mobile emulator running within QEMU |
| 08:36 | <gsnedders> | But likely that requires someone to care. |
| 08:43 | <gsnedders> | hsivonen: Perhaps a more telling sign is nobody has reported a bug yet down to WebGL and endianness |
| 08:46 | <jgraham> | I thought there were MIPS tablets shipping in China (probably without presto though). Perhaps some of those are BE? |
| 08:46 | <gsnedders> | I believe (almost?) all LE. |
| 08:50 | <jgraham> | Anyway, the advice to test on BE systems is clearly bogus and makes quite a good indicator for whether someone has thought enough about the problem |
| 08:51 | <gsnedders> | Does anyone have a nice, simple TC that gives big/little endian as a result? |
| 08:55 | <gsnedders> | hsivonen: I presume I can say fine that to my knowledge only one major TV OEM still produces BE hardware. |
| 08:57 | <gsnedders> | (And as far as I'm aware, we currently do not ship mobile on any BE hardware) |
| 08:58 | <hsivonen> | jgraham: yeah. It's worrying that the Khronos WG didn't have a mechanism for stopping blatant non-Web-safeness like this |
| 09:03 | <gsnedders> | hsivonen: As far as I can tell, apart from some talk from TC39 when it was talked about moving the spec there, nobody within the Khronos WG saw it as an issue. |
| 09:28 | <nonge> | the spec says about favicon.ico: "user agents may instead attempt to fetch and use an icon with the absolute URL obtained by resolving the URL "/favicon.ico" against the document's address" … I'm not sure: when the document has the url <example.com/foo/bar.html>;, should the UA look for <example.com/foo/favicon.ico>; or <example.com/favicon.ico>;? |
| 09:29 | <gsnedders> | nonge: resolving /favicon.ico against http://example.com/foo/bar.html results in http://example.com/favicon.ico |
| 09:30 | <nonge> | gsnedders, ah great. thank you |
| 10:55 | <annevk> | zcorpan: you can also look for self[x] |
| 10:55 | <annevk> | zcorpan: and frames[x] |
| 10:55 | <annevk> | zcorpan: but I think the more problematic part is when people do var x = test.innerHTML or some such where "test" is a reference to the element in question |
| 10:56 | <annevk> | zcorpan: see e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cscript%20id%3Dx%3Ew(x)%3C%2Fscript%3E |
| 10:57 | <zcorpan> | annevk: i don't think self[id] and frames[id] is more common than window[id] for lookup of non-framed elements |
| 10:58 | <zcorpan> | annevk: i don't know how to search for x without getting 99% noise :-) |
| 10:58 | <annevk> | but that is what people will likely use :/ |
| 10:58 | <zcorpan> | yeah |
| 13:22 | <GPHemsley> | FYI: Filed Mozilla bug 739203; if Mozilla has implemented the HTML5 parser correctly, it may be a spec bug |
| 13:25 | <zewt> | Hixie: the format of ip packets isn't really relevant; big endian cpus shouldn't be a serious consideration in api design today |
| 13:26 | <zewt> | (and any new binary-format protocols should also be little-endian) |
| 13:29 | <zcorpan> | GPHemsley: why would it be a spec bug? the color of tags in view source is entirely a UI thing |
| 13:30 | <GPHemsley> | zcorpan: I said *may*; if the parser algorithm is involved, there's a possibility |
| 13:30 | <GPHemsley> | that's all |
| 13:30 | <zcorpan> | GPHemsley: though i think this is a known bug. (dunno if it was actually filed in bugzilla though) |
| 13:30 | <GPHemsley> | well, it is now :) |
| 13:31 | <zcorpan> | hsivonen mentions it in http://hsivonen.iki.fi/view-source/ |
| 13:36 | <hsivonen> | GPHemsley: thanks, but it was a duplicate |
| 13:36 | <hsivonen> | coloring the script end tag is considerably harder than coloring other tags |
| 13:37 | <GPHemsley> | ah, ok |
| 13:37 | <zcorpan> | hsivonen: the tooltip for "<a class=foohref="foo">" has probably cause three times |
| 13:38 | <hsivonen> | zcorpan: one per line, though, right? |
| 13:38 | <hsivonen> | per line in the tooltip that is |
| 13:38 | <zcorpan> | oh, it's several errors |
| 13:38 | <hsivonen> | anyway, I opted to color the script end tag wrong in order to get the patch landed some time |
| 13:39 | <hsivonen> | turns out people pay attention to it :-( |
| 13:39 | <GPHemsley> | :) |
| 13:41 | <GPHemsley> | hsivonen: So why is it hard to color? |
| 13:43 | <hsivonen> | GPHemsley: the tokenizer doesn't go through enough state transitions to have transitions where the color scheme has color transitions, IIRC |
| 13:44 | <hsivonen> | could be fixed by adding more states to the tokenizer and making the syntax highlighter remember the run that covers "script" in case that run ends up participating in an end tag |
| 13:44 | <hsivonen> | or I suppose it could be fixed by some kind of post-processing hack |
| 13:44 | <hsivonen> | might actually be easier to do a post-processing hack |
| 13:45 | <zcorpan> | that's my first throught :-) |
| 13:45 | <hsivonen> | better not touch *those* tokenizer states |
| 13:48 | <zcorpan> | hsivonen: known that view source doesn't work for data: url pages? |
| 13:48 | <hsivonen> | zcorpan: huh? it's supposed to work |
| 13:48 | <GPHemsley> | zcorpan: WFM |
| 13:49 | <hsivonen> | zcorpan: WFM |
| 13:49 | <zcorpan> | 13.0a1 (2012-03-07) |
| 13:49 | <zcorpan> | data:text/html,foobar |
| 13:49 | <zcorpan> | view source is empty for me :-( |
| 13:50 | zcorpan | updates firefox |
| 13:50 | <hsivonen> | I don't have an Aurora build here, so I can't test 13. |
| 13:50 | <zcorpan> | same with 14.0a1 (2012-03-25) |
| 13:51 | <hsivonen> | zcorpan: do you have an external editor set? |
| 13:51 | <GPHemsley> | zcorpan: I'm running Aurora 13, and it works |
| 13:51 | <zcorpan> | hsivonen: no |
| 13:51 | <GPHemsley> | although the title bar lists "data:..." as the URL o_0 |
| 13:52 | <hsivonen> | GPHemsley: to avoid putting huge data: URLs there |
| 13:52 | <GPHemsley> | I suppose... but surely there's a happy medium? |
| 13:52 | <GPHemsley> | hsivonen: It doesn't do that for long http: URLs, does it? |
| 13:52 | <hsivonen> | GPHemsley: no |
| 13:54 | <hsivonen> | zcorpan: hmm. that's weird. which OS is this? |
| 13:54 | <zcorpan> | Mac OS X 10.7.2 |
| 14:04 | <hsivonen> | zcorpan: WFM on Mac |
| 14:04 | <hsivonen> | zcorpan: sorry, I need more precise steps to reproduce |
| 14:17 | <annevk> | Pro and no idea |
| 14:17 | <hsivonen> | annevk: can't you buy a new battery for Pro without leaving it for servicing? |
| 14:19 | <annevk> | the help says "Service Battery: The battery isn’t functioning normally, and you may or may not notice a change in its behavior or the amount of charge it holds. Take your computer in for service. You can continue to use your battery before it’s checked without harming your computer." |
| 14:19 | <hsivonen> | annevk: ok |
| 14:19 | <annevk> | and I think I might have Apple Care on it |
| 14:19 | <annevk> | oh well, guess I'll go find out tomorrow |
| 14:22 | <zcorpan> | hsivonen: 1. go to data:text/html,foobar 2. right click 3. view page source. ACTUAL RESULT: empty window |
| 14:22 | <annevk> | is that CSS3 logo a first? http://my.opera.com/desktopteam/blog/2012/03/26/html5-css-64bit |
| 14:23 | <zcorpan> | hsivonen: woah. it shows up when i *click* in the view source |
| 14:23 | <annevk> | zcorpan: are you running Nightly? |
| 14:23 | <zcorpan> | yeah |
| 14:23 | <annevk> | it works fine for me |
| 14:23 | <annevk> | Mac |
| 14:23 | <zcorpan> | very weird |
| 14:24 | <hsivonen> | zcorpan: WFM |
| 14:24 | <zcorpan> | it also shows up if i do an exposé |
| 14:25 | <hsivonen> | a painting bug maybe |
| 14:26 | <hsivonen> | (I tested on a 2009 Mac Mini with Nvidia something graphics) |
| 14:27 | <zcorpan> | i have a few months old macbook pro |
| 15:23 | <annevk> | is "each X has the following request-associated concepts" correct English? |
| 15:26 | <michel_v> | is there a verb more precise than "to have" in this context? |
| 15:31 | <annevk> | not sure what you mean |
| 15:42 | <michel_v> | annevk: I mean that I find the verb a little bit vague. but other than that, it looks correct to me (which won't help you much as I too am an english-as-a-second-language person) |
| 16:51 | <bhearsum> | does anyone know if it's possible to do HTML5 validation from within python, possibly with http://code.google.com/p/html5lib/ ? |
| 16:52 | <Ms2ger> | Hi bhearsum |
| 16:52 | <Ms2ger> | And no, I'm afraid not |
| 16:52 | <bhearsum> | damn :( |
| 16:52 | <bhearsum> | also, hi Ms2ger! |
| 16:53 | <Ms2ger> | Java? :) |
| 16:53 | <bhearsum> | heh |
| 16:55 | <MikeSmith> | bhearsum: fwiw, validator.nu does at least have an HTTP interface you could use from within python |
| 16:55 | <bhearsum> | hmmm |
| 16:56 | <bhearsum> | that might be O.K. here, i generally try to avoid network dependencies in tests though |
| 16:57 | <bhearsum> | thanks for the link MikeSmith |
| 16:58 | bhearsum | finds http://htmlhelp.com/tools/validator/offline/index.html.en |
| 17:04 | <MikeSmith> | bhearsum: curl --data-binary @foo.html -H "Content-Type: text/html" "http://validator.nu?out=gnu&level=error"; |
| 17:04 | <MikeSmith> | is an example of doing it from the command line |
| 17:05 | <bhearsum> | thanks |
| 17:24 | <dglazkov> | good morning, Whatwg! |
| 17:25 | <Ms2ger> | Good night, hat guy |
| 17:25 | <dglazkov> | Ms2ger: hats for everyone! |
| 17:38 | <kennyluck> | Good midnight. |
| 18:00 | <Hixie> | anyone have any opinions on how to do pattern transformations? |
| 18:00 | <Ms2ger> | Quickly? :) |
| 18:00 | <Hixie> | the two ideas currently are either an SVGMatrix argument to createPattern(), or a setTransform() method on CanvasPattern that takes an SVGMatrix |
| 18:56 | <Hixie> | ok since nobody seems to care, i'm going for the method that sets the matrix. |
| 20:02 | <annevk> | home sweet home |
| 20:13 | <annevk> | Hixie: so we are stuck with SVGMatrix? |
| 20:13 | <annevk> | I was kind of hoping it would go away in favor of something CSS-y (non-existing though...) |
| 20:15 | <hober> | i liked dino's 4x4 matrix proposal (to unify svgmatrix & other matrix needs in the platform) |
| 20:15 | <annevk> | hober: yeah, maybe that |
| 20:15 | <annevk> | hober: maybe comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=10132 ? |
| 20:18 | <jamesr_> | i think canvas just needs a 2x3 here |
| 20:18 | <jamesr_> | not 4x4 |
| 20:37 | <annevk> | jamesr_: hmm yeah, so maybe they should not be shared after all |
| 21:06 | <Sirisian|Work> | hey there he is. Hey annevk :) Decided to tweet you when I thought you didn't use this channel >_> |
| 21:06 | <Sirisian|Work> | Just saw your tweet |
| 21:07 | <annevk> | i'm here usually around European time |
| 21:07 | <annevk> | daytime* |
| 21:08 | <annevk> | fwiw |
| 21:08 | <annevk> | it usually takes me a while to get to a bug report, unless I happen to be editing the spec or it's something important that needs addressing soonish |
| 21:17 | <jwalden> | well, this is moderately surprising |
| 21:17 | <jwalden> | looks like only v8 implements the correct behavior for dateWhichIsInvalid.setSeconds(argumentWhichSideEffectsWhenConvertedToNumber) |
| 21:18 | <jwalden> | and none of the other engines do it right |
| 21:18 | <TabAtkins> | JS is weird. |
| 21:18 | jwalden | would have expected Opera to get it right, since they rewrote from the spec |
| 21:18 | <jwalden> | well, this isn't much a case of JS being weird, as of engines just not following the spec steps |
| 21:18 | <jwalden> | behavior here is kind of arbitrary once you allow implicit conversions and such |
| 21:23 | <annevk> | ooh, a JS bug in Opera |
| 21:23 | <annevk> | gsnedders will be pleased |
| 21:23 | <annevk> | or find out you're wrong :p |
| 21:26 | <annevk> | "Q: Does window.orientation=0 mean landscape or portrait mode? A: Depends on the browser. Gotta love WebKit APIs" euh sicking does it depend on the flavor of WebKit? |
| 21:30 | <gsnedders> | jwalden: Partly depends if it changed between the final public draft of ES5 and the final spec, and regardless assumes we implemented all the built-ins correctly, which there certainly have been bugs like this before. |
| 21:31 | <gsnedders> | jwalden: Also implies neither our testsuite, your testsuite, nor test262 tests it. :P |
| 21:31 | <jwalden> | yup |
| 21:31 | <jwalden> | https://bugzilla.mozilla.org/show_bug.cgi?id=732779 is what triggered my discovery, fwiw |
| 21:32 | <gsnedders> | I was amused of the case of [[Put]]/[[Set]] on primitives and wrapping in strict. Found it, filed bugs, then someone else independently found it and filed bugs as well as emailing es5-discuss two days after. |
| 21:32 | <jwalden> | that bug's old, for us :-\ |
| 21:33 | <gsnedders> | Yeah, you eventually found the dupe that I had missed. |
| 21:33 | <jwalden> | and drags in gnarly JSAPI public-API considerations |
| 21:33 | <gsnedders> | Certainly nobody else knew of it. |
| 21:33 | <gsnedders> | And V8 had the opposite bug! |
| 21:33 | <gsnedders> | It didn't wrap in strict or non-strict. |
| 21:33 | <jwalden> | oh, it's had about four or five dups or so, it's known...ish |
| 21:34 | <jwalden> | among the JS programmerati |
| 21:34 | <gsnedders> | I meant in other JS engines. |
| 21:34 | <jwalden> | ah |
| 21:35 | <Hixie> | annevk: i have no opinion on svgmatrix vs other matrix solutions |
| 21:35 | <Hixie> | annevk: i'm just using what i have |
| 21:36 | <gsnedders> | jwalden: Slightly unrelated, but any interest in making your jstests runner work better with other engines? |
| 21:36 | <annevk> | that's fair enough I guess, but I'm afraid we're locking ourselves down |
| 21:36 | <annevk> | but maybe we're already past that |
| 21:36 | <annevk> | nobody has picked up that ball thus far |
| 21:37 | <jwalden> | gsnedders: somewhat; I have at least one large task on my plate to complete before I could do any of that, tho |
| 21:37 | <jwalden> | at least if I'm volunteering my own time :-) |
| 21:37 | <jwalden> | plausibly it's a [good first bug] sort of thing |
| 21:37 | <jwalden> | although in a different sense from most of the JS first-bugs |
| 21:38 | <Sirisian|Work> | annevk, well the multiple monitor is kind of important. It's a problem that's plaguing many implementations since as soon as the screen loses focus you can't watch video. This is seen as a security concern so if my recommendation is added in a non-normative format then I can submit bugs to get all the browsers to implement it quickly allowing javascript to do something that not even a plugin like flash can do. |
| 21:39 | <gsnedders> | What we currently have makes it hard for us to stay up-to-date with the tests, which is awkward. |
| 21:40 | <gsnedders> | Might try and see if I can get permission to do such a thing (seeming it is technically contributing to moz, even if you are the ones who gain the least), but given I have exams coming up, I dunno about time. |
| 21:42 | <Hixie> | aw man, i don't remember how cvs works any more |
| 21:42 | <Hixie> | how do i do a revert in cvs? |
| 21:43 | <Hixie> | i need to revert a file back to revision 1.126 |
| 21:43 | <gsnedders> | Locally or on server? |
| 21:43 | <Hixie> | server. but nevermind, the google has given me the anwer. |
| 21:44 | <annevk> | Sirisian|Work: if it's a security issue you should file bugs regardless of what any spec says |
| 21:45 | <Hixie> | cvs update -j 1.132 -j 1.126 Overview.html |
| 21:45 | <Hixie> | does that look right? |
| 21:45 | <Hixie> | 1.132 is the current rev |
| 21:45 | <annevk> | Sirisian|Work: multi-monitor support is somewhat low on my priority list though |
| 21:45 | <Sirisian|Work> | you have 3 bugs. :\ |
| 21:46 | <Sirisian|Work> | Or do you mean there's more discussion about bigger changes to the spec? |
| 21:47 | <annevk> | well, I'm still waiting for the CSS WG to figure out the display related bits |
| 21:47 | <annevk> | which are also important for <dialog> |
| 21:47 | <annevk> | so far it seems to be going nowhere though :/ |
| 21:47 | <annevk> | but then I'm not subscribed to www-style so maybe |
| 21:48 | <Sirisian|Work> | Though that is a good suggestion. I think I'll submit bugs as a solution to the perceived security problem in the other browser's implementations. I have to leave work atm. Thanks for looking into it. :) |
| 21:49 | <kennyluck> | css3-box is not going anywhere so you need a CSS Skip-This Box Module Level 3 or something? |
| 21:50 | <annevk> | somebody else's problem until I'm through with waiting |
| 22:18 | <sicking> | annevk: it might depend on if it's a tablet or cellphone |
| 22:19 | <sicking> | annevk: since tablets are usually held in landscape mode, but cellphones in portrait mode |
| 22:19 | <sicking> | annevk: i only tried safari on iphone vs. "browser" on android tablet |
| 22:19 | <TabAtkins> | annevk: What are the display-related bits? |
| 22:22 | <gsnedders> | Hixie: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1423 gives Internal Error. |
| 22:22 | <Hixie> | what did you do?! |
| 22:22 | <gsnedders> | No idea. |
| 22:22 | <Hixie> | that's impressive! |
| 22:23 | <gsnedders> | Hixie: Really, I just pressed save. :P |
| 22:23 | <gsnedders> | Hixie: http://pastebin.com/AMWc0HKw |
| 22:24 | <Hixie> | likely story |
| 22:25 | <Hixie> | wtf |
| 22:26 | <Hixie> | brb will fix |
| 22:28 | <zewt> | sicking: fwiw, i very often hold my phone landscape (keyboard is much easier to use that way and switching back and forth is laggy on android) |
| 22:29 | <Hixie> | gsnedders: looks like an apache bug. your test was just too long. |
| 22:29 | <Hixie> | gsnedders: i'm trying an alternative approach. |
| 22:34 | <jarek> | why <text> element was introduced in SVG? How is that better than using HTML via foreignObject? |
| 22:34 | <TabAtkins> | jarek: That was *years* ago. |
| 22:34 | <jarek> | is it possible that text will become obsolete just like SVG fonts? |
| 22:34 | <jarek> | TabAtkins: 1999, right? |
| 22:34 | <TabAtkins> | Sometime around then, yeah. |
| 22:34 | <heycam> | no I think we will keep <text> in SVG, because it is far more convenient to include a line of text than going to a <foreignObject> |
| 22:36 | <heycam> | I mean it's a shame that <foreignObject> is required to include HTML |
| 22:36 | <heycam> | but I think it will be difficult at this point to allow HTML in SVG more directly than via <foreignObject> |
| 22:36 | <jarek> | yeah, SVG feels so decoupled from HTML |
| 22:36 | <TabAtkins> | I think we should keep trying! |
| 22:36 | <TabAtkins> | <svg><g><p>Some text!</p></g></svg> would be nice. |
| 22:37 | <heycam> | it sure would! I worry that the html parser is what stops us improving things like this |
| 22:37 | <TabAtkins> | Not necessarily. It's still *possible* to change the HTML parser for high-value causes. |
| 22:37 | <TabAtkins> | We're doing it as part of Web Components, frex. |
| 22:37 | <TabAtkins> | To handle <template>. |
| 22:37 | <heycam> | oh really, huh |
| 22:37 | <heycam> | ok well I will keep that in mind |
| 22:37 | <annevk> | TabAtkins: the ::cover stuff or whatever it ends up being |
| 22:38 | <annevk> | TabAtkins: hober knows more |
| 22:38 | <TabAtkins> | So you can do things like <template><tr>...</tr></template> without that getting fixed up. |
| 22:38 | <heycam> | I see |
| 22:38 | <TabAtkins> | annevk: Okay. I'm in the process of writing an updated Display spec, so I'd like to see if I need to add anything else. |
| 22:41 | <Hixie> | gsnedders: ok, fixed |
| 22:41 | <Hixie> | as a bonus i finally made the live dom viewer not document.write() it's url |
| 22:42 | <Hixie> | so now it should work on all the browsers with those annoying xss filters |
| 22:42 | <TabAtkins> | *Thank you* |
| 22:46 | <zewt> | ugh, ArrayBufferView constructors make a copy when passed another view, and only actually create a *view* when passed an ArrayBuffer? what horrible, mind-shattering drugs were they on? |
| 22:49 | <annevk> | TabAtkins: well I guess the idea is to having something that covers both <dialog> and fullscreen |
| 22:49 | <annevk> | TabAtkins: I'm not sure what that is though |
| 22:49 | <TabAtkins> | Yeah, me neither. |
| 22:49 | <Hixie> | TabAtkins: we should get hober and have lunch |
| 22:49 | <TabAtkins> | Sounds good. |
| 22:49 | <Hixie> | TabAtkins: figure out what needs to happen for these three specs to work together |
| 22:49 | <Hixie> | hober: you around? |
| 22:50 | <Hixie> | hober, TabAtkins: i can do tomorrow or wednesday, i'm out thursday and friday |
| 22:50 | <abarth> | Hixie: What do you think about exposing parent.location.origin across origins? Specifically, letting a frame see the origin of all the frames that contain it |
| 22:52 | <abarth> | Hixie: There are folks that want to do different things depending on who contains them. They can use postMessage today to coordinate, but that requires the containers to run code in the parent to coordinate |
| 22:53 | <Hixie> | going up the chain seems safe |
| 22:54 | <Hixie> | going down seems dodgy, consider a case like a site bank.com where you configure what your bank is so you go to bank.com and it redirects you to your bank |
| 22:54 | <Hixie> | now i just have to iframe bank.com to find out the user's bank |
| 22:54 | <Hixie> | better example of that would be something like livejournal, which has per-user subdomains |
| 22:55 | <Hixie> | or a corp url redirector, where being able to read the origin would expose a lot of internal hostnames |
| 22:55 | <abarth> | yeah, you wouldn't want to expose the origin of random frames |
| 22:55 | <Hixie> | but going up seems fine, sure |
| 22:55 | <Hixie> | it'll be a pain to implement, i imagine |
| 22:56 | <Hixie> | i think it might be better to expose as location.parentOrigin |
| 22:56 | <Hixie> | than parent.location.origin |
| 22:56 | <abarth> | that's an interesting idea |
| 22:56 | <Hixie> | less likely to misimplemented, too |
| 22:57 | <dave_levin> | abarth: It has the nice side benefit that one can now hide ones origin and iframe if you really want to |
| 22:57 | <dave_levin> | abarth: Using two iframes |
| 22:58 | <abarth> | yeah. thanks for the gut check. I'll send an email to the list with more information about the use cases, etc |
| 23:06 | <zewt> | i don't think there was ever any reason to have an ArrayBuffer type at all; could have just made objects return an Int8Array and not have a magical typeless object |
| 23:07 | <zewt> | welcome to the future, where we still have crappy apis being permanently glued to the platform without any real review |
| 23:12 | <Philip`> | As far as I'm aware, it's not like the WebGL people were trying to work in secret - they had a use case, so they came up with a solution, and people outside the community were aware of it but didn't bother commenting on it (other than saying "the ES guys have been looking into this for years, if you wait a few more years they might agree on something that might be suitable"), so they stuck with it, and a year later it was implemented everywhere |
| 23:13 | <zewt> | clearly, something went wrong |
| 23:14 | <kennyluck> | It probably started to go wrong when Microsoft decided to make IE free. |
| 23:16 | <Philip`> | I guess what went wrong is that the people who could have given useful comments didn't give comments promptly, so they missed the chance to fix it in time |
| 23:16 | <zewt> | was it ever raised for review on whatwg/webapps? |
| 23:16 | <zewt> | (saying "we're doing this thing, subscribe to webgl-public if you want to talk about it" isn't good enough) |
| 23:17 | <zewt> | <- just frustrated that it has such seemingly obvious warts, it's become an infrastructural API, and now we're stuck with the warts forever |
| 23:21 | <Philip`> | http://www.w3.org/mid/4B217A6B.8070905⊙mc |
| 23:22 | <Philip`> | (People paid more attention to public-html back then) |
| 23:33 | <kennyluck> | Philip`, did anything happen to public-html in the meanwhile? |
| 23:34 | <TabAtkins> | kennyluck: It was infested by process trolls and taken over by noise. |
| 23:34 | <TabAtkins> | See: every single message about longdesc, ever. |
| 23:36 | <kennyluck> | Huh. |
| 23:38 | <TabAtkins> | The worst part is that I know the a11y people *mean* well, they just put blinders on when talking about certain topics. |
| 23:39 | <TabAtkins> | They have a mysterious and total blindness about the "longdesc is completely polluted and useless" studies, and insist on trying to either pretend that it's perfectly okay, or that it will be okay *this time* if they just give it a different name. |
| 23:40 | <zewt> | TabAtkins: everyone means well |
| 23:40 | <zewt> | (perhaps excluding DRM folk) |
| 23:40 | <kennyluck> | lol |
| 23:40 | <zewt> | (wasn't a joke, heh) |