| 01:34 | <aho> | anyone got a test page for "storage" event? |
| 01:37 | <aho> | "a storage event is fired on every window/tab except for the one that updated the localStorage object and caused the event" |
| 01:37 | <aho> | oh... nevermind |
| 07:43 | <hsivonen> | hmm. do I want to read the PUT and DELETE thread? |
| 07:50 | <hsivonen> | I guess I don't |
| 08:00 | <hsivonen> | wow. the Designated Experts don't consider the pingback spec *stable* enough! |
| 08:00 | <hsivonen> | the spec might suck in various ways (XML-RPC!), but empirically it seems to have been pretty stable |
| 08:09 | <matjas> | TabAtkins: \o/ |
| 08:37 | <abarth> | hsivonen: you might or might not be interested in https://bugs.webkit.org/show_bug.cgi?id=57794 (basically, the fragment parsing algorithm can result in two body elements |
| 08:37 | <abarth> | ) |
| 08:39 | <hsivonen> | abarth: cool. looks entirely logical :-) |
| 08:41 | <hsivonen> | abarth: what behavior would you expect with <script>document.documentElement.appendChild(document.createElement("body"));</script> ? |
| 08:41 | <abarth> | oh, i think it's fine to have multiple bodies created by the DOM |
| 08:41 | <abarth> | it just seems like the parser shouldn't create more than one implicitly |
| 08:42 | <hsivonen> | setting innerHTML makes stuff "created by the DOM" |
| 08:42 | <abarth> | why is that? |
| 08:42 | <hsivonen> | abarth: it's not creating more than one implicitly per invocation |
| 08:42 | <abarth> | ok, but if you let the main parser create the <body> first |
| 08:42 | <hsivonen> | innerHTML is a DOM property |
| 08:42 | <abarth> | then innerHTML on the documentElement won't create another body |
| 08:43 | <hsivonen> | abarth: because it removes the old one first |
| 08:44 | <abarth> | i understand your point of view |
| 08:44 | <abarth> | but i'm not sure it's the more sensible way of looking at the situation |
| 08:45 | <abarth> | anyway, it's not clear to me whether we should change how this works in the parser |
| 08:45 | <abarth> | or add some compat shim to the system API layer |
| 08:46 | <abarth> | b/c we've only seen the issue in natives apps so far |
| 08:46 | <abarth> | "If you don't like the outcome, don't write code that sets innerHTML of the document element before the network stream parser has finished." |
| 08:46 | <abarth> | hahahaha |
| 08:47 | <hsivonen> | abarth: natives in plural or one native? |
| 08:47 | <abarth> | that's the only report i've seen so far |
| 08:47 | <abarth> | it's apple-internal stuff |
| 08:47 | <abarth> | so i only see what ends up in the public bug tracker |
| 08:47 | <abarth> | we could ask andy if there are multiple examples |
| 08:48 | <abarth> | we already have some awesome compat shims for native apps |
| 08:48 | <abarth> | for Mail.app |
| 08:48 | <abarth> | there's a JavaScript script that we run |
| 08:48 | <abarth> | to get rid of the implicit head element |
| 08:48 | <hsivonen> | abarth: implicit head with innerHTML or with network stream parsing? |
| 08:49 | <abarth> | network stream |
| 08:49 | <hsivonen> | wow |
| 08:49 | <abarth> | more specifically, the problem is the text nodes between the two or something |
| 08:49 | <abarth> | or maybe it's implicit head itself |
| 08:49 | <abarth> | i forget |
| 08:49 | <abarth> | there was a hack in the old parser for that |
| 08:49 | <hsivonen> | nodes in between sound more believable |
| 08:49 | <abarth> | but we pushed it up to a higher layer |
| 08:50 | <abarth> | a lot of native apps require <script src="../> |
| 08:50 | <abarth> | <script src="..." /> |
| 08:50 | <abarth> | to be self-closing |
| 08:50 | <abarth> | :( |
| 08:50 | <hsivonen> | it's quite sad that a handful of mail apps are more trouble than the wild Web |
| 08:50 | <abarth> | its because of the monoculture |
| 08:51 | <hsivonen> | though so far, the one Thunderbird problem I've fixed was an actual parser bug |
| 08:51 | <hsivonen> | but it was exposed due to Thunderbird doing stuff in a way that you wouldn't expect by reading the spec layering |
| 08:51 | <zcorpan> | ie doesn't allow innerHTML on root at all (at least prior to ie9, haven't tested ie9) |
| 08:52 | <hsivonen> | if I understand things correctly Thunderbird doesn't have clean layering of MIME encoding, character encoding and HTML parsing |
| 08:53 | <hsivonen> | the Web believes that the character encoding layer melds into the HTML parser |
| 08:53 | <hsivonen> | I have been lead to believe Thunderbird combines it into the MIME layer instead |
| 08:54 | <abarth> | i'm not even sure how that would work |
| 08:54 | <abarth> | how could the HTML decide that something was actually a PNG? |
| 08:54 | <hsivonen> | one would expect the MIME layer to give you bytes and a Content-Type like HTTP |
| 08:55 | <hsivonen> | if I've understood correctly, the MIME layer in thunderbird performs at least <meta> sniffing itself |
| 08:56 | <hsivonen> | abarth: I don't know about your PNG question. I try not to look at the MIME code. |
| 08:57 | <hsivonen> | I think UTF-7 decoding is now part of the MIME layer |
| 08:57 | <hsivonen> | or something like that |
| 08:57 | <hsivonen> | unless it got refactored again |
| 08:58 | abarth | is happy the UTF-7 decoder was removed from Firefox |
| 08:58 | jgraham | remembers encountering the multiple-<body> issue before and being told to not worry about it :) |
| 08:59 | <hsivonen> | there was another multiple body case with OWA |
| 09:00 | <zcorpan> | http://www.google.com/codesearch?as_q=document%5C.%28documentElement%7CfirstChild%29%5C.innerHTML%5Cs%2A%3D&btnG=Search+Code&hl=en&as_package=&as_lang=&as_filename=&as_class=&as_function=&as_license=&as_case= |
| 09:00 | <hsivonen> | that was "fixed" by special-casing html in the html namespace as the context node for createContextualFragment |
| 09:00 | <hsivonen> | which reminds me that I should write tests for calling insertAdjacentHTML on body and head |
| 09:02 | <hsivonen> | zcorpan: hooray for XForms righteousness implemented on top of innerHTML |
| 09:10 | <hsivonen> | looks like insertAdjacentHTML on document.head and document.body when inserting beforebegin or afterend behaves as if the context node was "body" instead of "html" |
| 09:14 | <hsivonen> | Opera behaves as if "html" was the context but only "body" got implied--not head |
| 09:14 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/916 |
| 09:15 | <hsivonen> | Chrome implies both head and body |
| 09:15 | <hsivonen> | interop FTW! |
| 09:17 | <hsivonen> | and by code inspection, I expect my impl to vary between the IE9 behavior and the Chrome behavior depending on whether an optimized code path is taken... |
| 09:21 | <abarth> | is there a spec for insertAdjacentHTML ? |
| 09:21 | <abarth> | i think the WebKit codepath goes through the same mechanism as createContextualFragment |
| 09:22 | <hsivonen> | abarth: yes, there's a spec. |
| 09:22 | <abarth> | if you'd be willing to file a bug, i'd be happy to fix it |
| 09:22 | <abarth> | but i'm going to head to bed soon |
| 09:22 | <hsivonen> | abarth: if you have the same code path, you got insertAdjacentHTML "right" per current spec by luck and createContextualFragment "wrong" as required by OWA |
| 09:23 | <hsivonen> | abarth: I intend to file a spec bug asking for IE9's behavior to be made standard |
| 09:23 | <abarth> | there's added complication because this code is also used by editing |
| 09:24 | <abarth> | at some point, i need to go back and fix all the html5lib tests |
| 09:24 | <hsivonen> | abarth: hopefully your code, not the tests :-) |
| 09:24 | <abarth> | well, either way :) |
| 09:25 | <abarth> | but i meant my code |
| 09:30 | <jgraham> | Is the presence of interface objects in the DOM defined somewhere before Web DOM Core and other WebIDL-using specs? |
| 09:30 | <hsivonen> | hmm. maybe I should try Ragnarök before I ask for spec changes |
| 09:31 | <hsivonen> | Ragnarök behaves per spec like Chrome |
| 09:32 | <hsivonen> | perhaps I should just fix my code to do the same |
| 09:32 | <hsivonen> | and then we can declare IE9 non-compliant |
| 09:33 | <hsivonen> | hmm. maybe I should still try some old IE versions first |
| 09:33 | <hsivonen> | I wonder if Hixie remembered to test this stuff |
| 09:40 | <hsivonen> | IE6 disagrees with the spec |
| 09:40 | <hsivonen> | and it's their API |
| 09:56 | <zcorpan> | yeah, the w3c monster should be ashamed http://www.w3.org/Bugs/Public/show_bug.cgi?id=12432 |
| 09:58 | <hsivonen> | zcorpan: what's the SeaMonkey remark about? is the commenting script broken in SeaMonkey? |
| 09:59 | <zcorpan> | dunno, maybe he had scripting disabled first |
| 10:00 | <jgraham> | There is a W3C monster? |
| 10:00 | <jgraham> | You're not thinking of MikeSmith? |
| 10:01 | <hsivonen> | is there even supposed to be a commenting script on the W3C version? |
| 10:02 | <zcorpan> | yeah, although it's different from the whatwg one |
| 10:04 | <hsivonen> | I didn't see it in my browser |
| 10:05 | <zcorpan> | it's a form in the sotd |
| 10:08 | <hsivonen> | oh |
| 11:34 | hsivonen | notes that nessy's WebVTT example at Google included <c.red.caps> |
| 11:34 | <hsivonen> | so much for Hixie's quest to exorcise presentationalism |
| 11:43 | <MikeSmith> | http://www.youtube.com/watch?v=MisRPPv2Hg8 |
| 12:39 | <hsivonen> | what's the business model of xtranormal? |
| 12:41 | <MikeSmith> | hsivonen: they charge "points" based on which features you use |
| 12:41 | <MikeSmith> | e.g., if you want to use particular characters |
| 12:41 | <hsivonen> | MikeSmith: do the points cost actual money? |
| 12:41 | <MikeSmith> | yeah |
| 12:41 | <MikeSmith> | I paid 10 USD for 1200 points |
| 12:41 | <hsivonen> | ok |
| 12:42 | <MikeSmith> | and it cost me about 300 points to make a short movie |
| 12:42 | <MikeSmith> | it seems like a pretty decent model |
| 12:42 | <hsivonen> | yeah |
| 12:42 | <MikeSmith> | and their UI/app is really outstanding |
| 12:43 | <MikeSmith> | it's Flash-based but it's one of those things that we should look at when considering what new features to add to the Web platform to make something like that possible natively in a browser |
| 12:44 | <MikeSmith> | speaking of money, I just bought my first e-book |
| 12:44 | <hsivonen> | seems like it should be possible to use WebGL to render that kind of scenes in real time |
| 12:44 | <MikeSmith> | yeah |
| 12:44 | <hsivonen> | MikeSmith: in which format? |
| 12:45 | <MikeSmith> | hsivonen: true (about WebGL) |
| 12:45 | <MikeSmith> | format is epub 2.0 |
| 12:45 | <MikeSmith> | but with DRM |
| 12:46 | <MikeSmith> | unfortunately |
| 12:46 | <hsivonen> | I have been trying to divest my paper publication holdings |
| 12:46 | <MikeSmith> | bought it from Kobo for around 10 USED |
| 12:46 | <hsivonen> | so much paper |
| 12:46 | <MikeSmith> | amen |
| 12:46 | <Lachy> | MikeSmith, don't you find those movies generated by xtranormal with their monotonous computer generated voices to be extremely irritating? |
| 12:47 | <MikeSmith> | Lachy: exactly the opposite |
| 12:47 | <hsivonen> | I wish I had accumulated a few files in my NAS during my life so far instead of all this paper to move from an apartment to another |
| 12:47 | <MikeSmith> | Lachy: I find them wildly entertaining |
| 12:47 | <MikeSmith> | and you can change the voices |
| 12:47 | <Lachy> | ??? |
| 12:47 | <MikeSmith> | they have a bunch of voices to choose from |
| 12:47 | <Lachy> | do they let you record your own voice tracks? |
| 12:47 | <MikeSmith> | no |
| 12:47 | <hsivonen> | Lachy: I particularly like the tone of voice in the Web Socket movie |
| 12:48 | <MikeSmith> | Lachy: that would not be any fund |
| 12:48 | <Lachy> | hsivonen, link? |
| 12:48 | <MikeSmith> | hsivonen: I don't keep paper books around any more. If I buy a new paper book, I sell it to my local used bookstore as soon as I am finished reading it |
| 12:48 | <MikeSmith> | or I give it away |
| 12:49 | <hsivonen> | Lachy: http://www.xtranormal.com/watch/7991991/web-sockets-we-are-the-first |
| 12:49 | <MikeSmith> | some books my local shop won't buy because they already have unsold copies of them |
| 12:50 | <MikeSmith> | anyway, Kobo seem to have their heads in the right place mostly |
| 12:50 | <MikeSmith> | http://www.kobobooks.com/ebook/Maintenance-Of-Headway/book-nwxMhg3cS0eVu0mgx7ggiQ/page1.html |
| 12:50 | <MikeSmith> | they also have e-books that aren't available elsewhere |
| 12:51 | <MikeSmith> | though that book it would not let me download initially when I gave a US physical address |
| 12:51 | <MikeSmith> | I had to lie to it and give it fake UK address |
| 12:52 | <MikeSmith> | Lachy: I recommend trying out making a short movie in xtranormal |
| 12:52 | <MikeSmith> | it's pretty fun and very easy |
| 12:53 | <MikeSmith> | and Kobo's reader software is better than Adobe's Digital Editions reader |
| 12:53 | <MikeSmith> | for one thing, it automatically repaginates so that you never have to do any vertical scrolling |
| 12:54 | <hsivonen> | MikeSmith: does it read Adobe's DRM? |
| 12:55 | <hsivonen> | I haven't bought an ebook reader, because I want one that I can use in the evening without disrupting my sleep (i.e. I believe the melatonin claims) and I want to read both English and Finnish books |
| 12:55 | <hsivonen> | so for English books I should be buying a Kindle |
| 12:56 | <hsivonen> | and for Finnish ones something else that is tethered to Adobe's software |
| 12:57 | <hsivonen> | after experiencing Flash Player and Adobe Reader, I don't want any new Adobe-made free content rendering software in my life |
| 12:58 | <MikeSmith> | hsivonen: If you mean books that are intended to be read in Adobe Digital Editions, I don't know if Kobo can read those are not |
| 12:59 | <MikeSmith> | hmm, make it can |
| 12:59 | <hsivonen> | MikeSmith: I meant epub with Adobe's DRM. I gather those need to be uploaded to a device using Adobe Digital Editions |
| 12:59 | <MikeSmith> | ok |
| 12:59 | <MikeSmith> | yeah, don't know |
| 13:00 | <MikeSmith> | but the Digital Editions reader app is really disappointing, so I would be unhappy if I purchased something and could only read it in that app |
| 13:06 | <MikeSmith> | hsivonen: about reading in the evening, I think there are a couple of things that help |
| 13:07 | <MikeSmith> | one is using reverse video / white text on black background |
| 13:08 | <MikeSmith> | another is wearing glasses that block out a lot of the blue |
| 13:08 | <MikeSmith> | e.g., orange lenses |
| 13:09 | <MikeSmith> | so anyway, I think for reading at night using a tablet as a reader, with the screen flipped to white text on black might be better than using a backlit reader like kindle or whatever |
| 13:10 | <hsivonen> | MikeSmith: it somehow seems wrong to have to go through the trouble of using orange lenses in order to read in the evening |
| 13:11 | <hsivonen> | as opposed to the device doing the right thing itself |
| 13:11 | <MikeSmith> | yeah |
| 13:12 | <MikeSmith> | but another solution is to wear orange lenses all the time |
| 13:12 | <MikeSmith> | which is what I do :) |
| 13:12 | <MikeSmith> | I don't really know if it helps or not |
| 13:12 | <hsivonen> | MikeSmith: do orange lenses have harmful side effects to the eyes? |
| 13:12 | <MikeSmith> | because my sleep cycle is whacked anyway |
| 13:12 | <MikeSmith> | hsivonen: dunno |
| 13:12 | <MikeSmith> | but I hope not… |
| 13:13 | <hsivonen> | I want a device that doesn't disrupt sleep, is light and portable, runs Firefox (Firefox Sync specifically) and supports both English and Finnish books in the forms they actually are sold |
| 13:14 | <hsivonen> | AFAICT, such a device doesn't exist |
| 13:14 | <hsivonen> | which is sad |
| 13:14 | <MikeSmith> | the disrupting sleep part is the hard part I guess |
| 13:15 | <hsivonen> | MikeSmith: if that requirement were removed, an Android tablet would work |
| 13:16 | <MikeSmith> | well, really, if you are reading at night you must have to use some kind of light source, and that's going to have some effect as far as the melatonin thing goes |
| 13:17 | <MikeSmith> | I am sure incandescent light is less disruptive |
| 13:17 | <MikeSmith> | than light from a laptop or PC screen |
| 13:17 | <MikeSmith> | or fluorescent light |
| 13:18 | <hsivonen> | Which makes me wonder if the effects of light bulbs vs. these EU-mandated energy saving thingies on sleep has been researched |
| 13:20 | <MikeSmith> | yeah, I would be interesting to see some data about that |
| 13:20 | hsivonen | learns that the CNN front page uses the <style> element all over outside <head> |
| 13:20 | <MikeSmith> | but I was just re-reading about the light-vs-melatonin effect |
| 13:22 | <MikeSmith> | and it seems like it almost completely caused by blue-wavelength light |
| 13:23 | <MikeSmith> | and getting rid of the blue as you can apparently does make a very significant difference |
| 17:44 | <MikeSmith> | Peter`: you around? |
| 17:48 | <jgraham> | AryehGregor: Because green jelly babies give you acne? |
| 17:50 | <MikeSmith> | zcorpan: did you see http://www.youtube.com/watch?v=MisRPPv2Hg8 yet? |
| 17:55 | <zcorpan> | heh hadn't seen it |
| 17:55 | <Peter`> | MikeSmith: yup! Thanks! |
| 17:56 | <MikeSmith> | Peter`: big congrats man |
| 17:56 | <MikeSmith> | you relocating or plan to work from home for now? |
| 17:56 | <Peter`> | Cheers :) I'll be relocating to London |
| 17:56 | <gsnedders> | Peter`: What are you doing? |
| 17:57 | <Peter`> | I'll be joining Google as part of the Chrome team :) |
| 18:02 | <Peter`> | gsnedders, there's some more info on http://peter.sh/2011/04/joining-google/ |
| 18:19 | <jgraham> | Peter`: Nice :) |
| 18:25 | <kangax> | Does input[type="file"] have any kind of activation behavior defined? I can't seem to find anything in the spec. Nightly webkit, Chrome 12 and FF4 show upload file dialog; Opera does nothing, it seems. |
| 18:27 | <kangax> | (i'm invoking `click()` method on an element, which should run synthetic click activation steps, from what I can see) |
| 18:32 | <AryehGregor> | Browsers tend to restrict how you can use file inputs in various nonstandard ways, for security reasons. |
| 18:32 | <AryehGregor> | What's Chrome 12, canary? |
| 18:33 | <TabAtkins> | Either dev or canary, yeah. |
| 18:33 | <TabAtkins> | Beta is 11 right now. |
| 18:33 | <AryehGregor> | Oh, hmm. |
| 18:33 | <AryehGregor> | You know, Ubuntu hasn't suggested I update for a long time now. |
| 18:33 | <AryehGregor> | I'm still on 11 for dev. |
| 18:33 | AryehGregor | looks into his config |
| 18:34 | <AryehGregor> | 124 updates have been selected. 212.0 MB will be downloaded. |
| 18:34 | <AryehGregor> | Thanks, Ubuntu. |
| 19:05 | <kangax> | AryehGregor: I understand security implications. I was surprised to see FF, Chrome and WebKit actually show upload dialog on click. |
| 19:07 | <miketaylr> | i remember there was a mozilla drag and drop/file demo that relied on .click() working |
| 19:08 | <miketaylr> | http://paulrouget.github.com/miniuploader/ |
| 19:10 | <kangax> | miketaylr: yep, that shouldn't work in Opera then |
| 19:11 | <miketaylr> | yeah, it does't |
| 19:12 | <Rik`> | kangax: .click() is new in Firefox 4 |
| 19:12 | <miketaylr> | s/does't/doesn't/ |
| 19:13 | <kangax> | Rik`: yeah it is |
| 19:14 | <kangax> | Rik`: i remember one of my tests was (wrongly) failing in earlier FF due to that — https://bugzilla.mozilla.org/show_bug.cgi?id=583514#c32 |
| 20:19 | <AryehGregor> | Is it intentional that anolis adds <a> around <code> instead of inside, so the underline is blue instead of orange? |
| 20:21 | <AryehGregor> | I hate CSS underlines. |
| 20:22 | <gsnedders> | AryehGregor: Yes. |
| 20:22 | <AryehGregor> | gsnedders, why? |
| 20:23 | <gsnedders> | AryehGregor: Because you want to link that code fragment, not make the link a code fragment |
| 20:23 | <AryehGregor> | gsnedders, um, what's the actual difference? |
| 20:23 | <AryehGregor> | Other than having the wrong underline color. |
| 20:24 | <gsnedders> | AryehGregor: It's a theoretical semantic distinction, mostly. |
| 20:25 | <AryehGregor> | gsnedders, so actually there's no difference except maybe according to some debatable notion of theoretical purity, but it creates the wrong underline colors? |
| 20:25 | <AryehGregor> | So maybe it should be changed? |
| 20:25 | <AryehGregor> | I personally think that <a><code>Foo</code></a> and <code><a>Foo</a></code> have identical semantics. |
| 20:26 | <AryehGregor> | I don't see why they wouldn't. |
| 20:26 | <AryehGregor> | How could markup be semantically part of code? Only the text content is the code. |
| 20:26 | <AryehGregor> | And the text content is the same regardless. |
| 20:26 | gsnedders | discussed this with Hixie a couple of years back, and there was agreement that semantically the default behaviour is right, but due to CSS limitations the option was added |
| 20:27 | <AryehGregor> | Also, could we have <var> not be autolinked unless you explicitly give it a title, so <var> is the same as <var title>? Because I don't think I've ever seen <var> used to actually link anything, but it's used massively to do non-linked variables. |
| 20:27 | <gsnedders> | HTML5 uses it |
| 20:28 | <AryehGregor> | Where? |
| 20:28 | <gsnedders> | Dunno. It's been a while since I've touched Anolis. :) |
| 20:32 | <AryehGregor> | You could do a > code:only-child { text-decoration: underline }. |
| 20:34 | <AryehGregor> | Thanks for telling me about the option, anyway. I'll switch it on for DOM Range and HTML Editing Commands. |
| 21:23 | <bfrohs> | Just to verify, setting a checkbox to readonly *should* make it impossible to change the checkedness, correct? |
| 21:23 | <TabAtkins> | Should make it impossible for a user to change it, certainly. I forget whether or not that has any effect on js twiddling the property. |
| 21:25 | <bfrohs> | Bummer, FF4 kinda fails at restricting that :( |
| 21:27 | <miketaylr> | don't think readyonly applies to checkbox |
| 21:27 | <TabAtkins> | Huh, indeed. That seems... unfortunate. |
| 21:27 | <TabAtkins> | I guess @disabled does the job? |
| 21:27 | <miketaylr> | looks like it |
| 21:28 | <bfrohs> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-readonly (and see 'immutable') |
| 21:28 | <bfrohs> | Disabled doesn't pass the values in $_POST though, correct? |
| 21:28 | <TabAtkins> | Ah, yup, a checkbox being immutable does indeed imply that you shoudln't be able to alter its checkedness. |
| 21:28 | <miketaylr> | i was looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary |
| 21:29 | <bfrohs> | miketaylr: Well, isn't that nice. *disappointed* |
| 21:29 | <miketaylr> | :'( |
| 21:29 | <TabAtkins> | Hmm. Is there any other way to make a checkbox immutable? |
| 21:31 | <bfrohs> | Other than 'disabled', I can't find anything |
| 21:31 | <TabAtkins> | Ah, and the checkbox state specifically says that @readonly doesn't apply and shouldn't be specified. |
| 21:32 | <bfrohs> | So, instead of 'readonly', change the type to 'hidden' and set the value that way, eh? |
| 21:32 | <TabAtkins> | It doesn't appear that 'disabled' makes an element immutable, though. It just prevents clicks from being dispatched. |
| 21:32 | <bfrohs> | "When an input element is disabled, it is immutable." |
| 21:32 | <TabAtkins> | Dang it, why isn't that in the description of @disabled? |
| 21:33 | <bfrohs> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-immutable |
| 21:33 | <TabAtkins> | Specifically, it's not in http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-disabled |
| 21:33 | <bfrohs> | That's where I'm quoting, if you want it |
| 21:34 | <TabAtkins> | Imma send an email requesting that checkboxes be readonly-able. |
| 21:34 | <bfrohs> | Awesome :) |
| 21:37 | <bfrohs> | Also, was there a reason why @readonly isn't included in fieldset, but @disabled was? |
| 21:38 | <TabAtkins> | I guess people don't usually make entire blocks of inputs switch from readonly to not, but they *do* enable/disable whole blocks of inputs. |
| 21:39 | <bfrohs> | Well, it would apply to a fieldset of radiobuttons (or checkboxes)... assuming both of these end up getting @readonly added |
| 21:53 | <bfrohs> | TabAtkins: Came across this while looking up something else.. but applies to our conversation from earlier - http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-August/004621.html (see last paragraph) |
| 21:56 | <bfrohs> | Looks like it just died off (in that thread, at least) |
| 21:56 | <heycam> | Hixie, when you're back: I've got http://www.w3.org/Bugs/Public/show_bug.cgi?id=11267 |
| 21:56 | <heycam> | Hixie, but I haven't written down who requested that. (I'm guess it's you though.) |
| 21:57 | <heycam> | Hixie, so if it was you, I wanted to see if that's still something you want. I'm not sure why just relying on SOP isn't enough there. |
| 22:09 | <Hixie> | heycam: not me, i've no idea what it means for something to be "configurable" |
| 22:09 | <Hixie> | heycam: having said that, note that the same-origin policy doesn't apply to (e.g.) foreignWindow.location.href |
| 22:10 | <Hixie> | or at least, not to its setter |
| 22:10 | <Hixie> | so if you could change location to point to something else, maybe that's a problem? |
| 22:10 | <Hixie> | i dunno |
| 22:10 | <Hixie> | depends what it means for something to be configurable |
| 22:11 | <heycam> | Hixie, [[Configurable]] in the ES5 sense |
| 22:11 | <heycam> | so, you can change anything about the property |
| 22:12 | <heycam> | remember though that IDL attributes get turned into accessor properties with a getter but not setter, with ES5 |
| 22:12 | <heycam> | so these attributes are effectively read only; assigning to them will get ignored (or throw, in strict mode) |
| 22:12 | <heycam> | but you could still reconfigure the property to be something else |
| 22:13 | <heycam> | Hixie, so I didn't know you could grab foreignWindow.location.href |
| 22:13 | <heycam> | is that written down in the spec? |
| 22:13 | <heycam> | (and is there a list somewhere of which properties can be accessed cross origin like that?) |
| 22:26 | <Hixie> | heycam: the spec assumes you can grab anything, and then blocks out certain attributes. see e.g. http://www.whatwg.org/specs/web-apps/current-work/complete.html#security-document (and there's another one for Window) |
| 22:26 | <Hixie> | (that one for document is what blocks everything on Document) |
| 22:26 | <Hixie> | hm, technically it only blocks HTMLDocument, i should fix that |
| 22:27 | <Hixie> | bbiab |
| 22:27 | <heycam> | k |
| 22:28 | <heycam> | Hixie, and I guess that covers everything, because all you can get to is the Window/Document of another window (with contentWindow/contentDocument)? |
| 22:29 | <Hixie> | that's the theory |
| 22:29 | <Hixie> | ttyl |
| 22:29 | <heycam> | ttyl |
| 22:30 | heycam | will file a bug around there... |
| 22:30 | <dglazkov> | Hixie: have a component model question for you |
| 22:32 | <dglazkov> | Hixie: suppose I am in shadow content, traversing up the parentNode() |
| 22:32 | <dglazkov> | Hixie: what's the last non-null parentNode() should I see? |
| 23:03 | <nessy> | Hixie: say, when are you going to make changes to the multitrack stuff? |
| 23:56 | <Lachy> | does anyone know which glyph Chrome is using for the disclosure triangles in their <details> implementation? |
| 23:56 | <Lachy> | or does anyone know how to find out? |
| 23:56 | <TabAtkins> | dglazkov: ^^^ |
| 23:59 | <Lachy> | at a guess, I'd say it's either the U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE or U+25B6 (▶) BLACK RIGHT-POINTING TRIANGLE (and the matching left/down-pointing triangles), |