| 00:31 | <annevk> | Hixie_: @@unscopeable is a temporary name for a property that is used to hide other properties from with() lookup |
| 00:32 | <annevk> | Hixie_: @@unscopeable will be become Symbol.unscopeables or some such and then you'd have Array.prototype[Symbel.unscopeables] = ["find", ...] predefined to not run into compatibility bugs |
| 00:33 | <annevk> | Hixie_: similarly we could have Element.prototype[Symbol.unscopeables] = ["after", "before", ...] to hide certain common names, assuming event handlers are similarly defined to with |
| 00:41 | <Hixie_> | annevk: isn't with supposed to be dead? |
| 00:53 | <heycam> | are we going to make all new things on nodes unscopeable? or just do it for names that are likely to be problematic? |
| 00:55 | <annevk> | Hixie_: the web uses it and prevents extending Array.prototype due to the way it is used |
| 00:56 | <heycam> | annevk, are we going to make all new things on nodes unscopeable? or just do it for names that are likely to be problematic? |
| 00:56 | <heycam> | this is for onclick="barename" right? |
| 00:56 | <annevk> | heycam: case-by-case, if unscopeable makes it through |
| 00:56 | <annevk> | heycam: yeah |
| 00:56 | <heycam> | hmm |
| 00:57 | <heycam> | tbh I would prefer to draw a line and say only existing things are in scope automatically |
| 00:58 | <Hixie_> | annevk: k |
| 00:59 | <Hixie_> | heycam: while you're here, any comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358 ? |
| 01:00 | heycam | looks |
| 01:01 | <heycam> | Hixie_, so this sounds a little similar to what WebGL is doing for annotating methods that should throw if the context has been lost |
| 01:01 | <Hixie_> | similar, yeah |
| 01:01 | <heycam> | Hixie_, I suggested to them that they define that extended attribute in WebGL itself. how HTML-specific is this one you need? |
| 01:01 | <Hixie_> | i don't know. right now i only want it for History |
| 01:02 | <Hixie_> | which is just HTML |
| 01:02 | <Hixie_> | but i wouldn't be surprised to see it used elsewhere |
| 01:02 | <Hixie_> | really my ulterior motive is getting out of defining what it means exactly |
| 01:02 | <Hixie_> | otherwise i'd have just done it in prose :-) |
| 01:02 | <heycam> | heh |
| 01:03 | <heycam> | well, if you don't know exactly how it's meant to be defined... |
| 01:03 | <Hixie_> | i mean, i know what i want it to do: throw an exception on method and property accesses |
| 01:03 | <Hixie_> | but ES is getting more and more complicated and has gone over my head |
| 01:04 | <Hixie_> | such that i no longer know how to define this, let alone in a language-agnostic way. |
| 01:04 | <heycam> | ok |
| 01:05 | <heycam> | I think then it makes sense to have something defined in Web IDL, to do the check at all the right points |
| 01:07 | <heycam> | [Poisonable] on the History interface, where then you define in HTML when a History object is poisoned |
| 01:07 | <heycam> | something like that |
| 01:08 | <Hixie_> | lgtm |
| 01:08 | heycam | comments in the bug |
| 01:08 | <Hixie_> | or actually |
| 01:08 | <Hixie_> | we don't even need an annotation |
| 01:09 | <heycam> | I guess not |
| 01:09 | <Hixie_> | just have it possible for objects to be in a poisoned state (note, it should be possible for this to revert out of it), and by default, it never gets set |
| 01:09 | <heycam> | just like now we have the security check hook in various places |
| 01:11 | <Hixie_> | yeah |
| 01:11 | <heycam> | any particular exception you think would be good to throw? |
| 01:12 | <Hixie_> | there's a test in the dependant bug |
| 01:12 | <Hixie_> | i didn't check what the exception type is |
| 01:12 | <Hixie_> | but it triggers it |
| 01:12 | <Hixie_> | i don't remember in what browsers |
| 01:12 | <Hixie_> | (some just do no-ops instead of throwing) |
| 01:13 | <heycam> | I see a SecurityError in the console for the second test |
| 01:13 | <heycam> | but nothing for the first |
| 01:14 | <heycam> | is the need for this History object poisoning because of document origin changing or something? |
| 01:14 | <heycam> | does it make sense to handle it as part of the security check hook? |
| 01:16 | <Hixie_> | 000.html is a same-origin cas |
| 01:16 | <Hixie_> | case |
| 01:16 | <Hixie_> | (sorry can't talk much or do testing right now) |
| 01:16 | <heycam> | ok, will take discussion to bug |
| 01:17 | <Hixie_> | pretty sure that some of the browsers throw for both |
| 01:17 | <Hixie_> | if they don't then it might change things |
| 01:17 | <Hixie_> | also note that some browsers report SecurityError but not other exceptions, iirc |
| 01:17 | <heycam> | mm |
| 01:17 | <Hixie_> | so you might have to change the test to catch it or something |
| 01:17 | <heycam> | ah ok |
| 01:17 | <heycam> | I might punt it back to you in the bug to check what behaviour we ultimately need |
| 01:19 | <Hixie_> | sure thing. make sure it's assigned to me, bugs that aren't assigned to me have month-long lag cos i only read the bugmail every few months |
| 01:37 | <annevk> | http://store.steampowered.com/livingroom/SteamMachines/ |
| 01:40 | <annevk> | heycam: not sure if my email mentioned it, but having [Global] and [Exposed] annotations would be welcome |
| 01:41 | <heycam> | annevk, yeah, would be good to solve those together |
| 01:41 | <heycam> | I think we can do it |
| 01:43 | <annevk> | I hope this Valve thing takes off |
| 05:29 | <ondras> | morning |
| 05:29 | <ondras> | anyone suitable for discussion re. <dialog> ? |
| 05:31 | <falken> | hi ondras, i'd be interested in such a discussion. i'm implementing it in chromium |
| 05:38 | <ondras> | falken: I am intrigued by the naming inconsistency in the JS API, namely the "show/close" methods |
| 05:38 | <ondras> | i.e. no "show/hide" nor "open/close" |
| 05:39 | <ondras> | but as a non-native speaker, I might be missing some language subtleties |
| 05:39 | <ondras> | I always try to create the naming pairs as mentioned above, for the sake of consistency |
| 05:39 | <falken> | ondras: yes there was discussion on the list about that... one sec |
| 05:40 | <falken> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-August/040593.html |
| 05:40 | <falken> | it was named to be consistent with the existing window.showModalDialog(), window.close() |
| 05:42 | <ondras> | ah |
| 05:42 | <ondras> | thanks for the link |
| 05:42 | <ondras> | from the short discussion fragment, it looks like the majority is voting towards a open/close change, right? |
| 05:42 | <Hixie_> | we don't base decisions on votes |
| 05:42 | <ondras> | yeah, well, of course |
| 05:42 | <Hixie_> | but if there's a stronger argument to do it one way or another that hasn't yet been discussed, please do bring it up :-) |
| 05:42 | <ondras> | I just wanted to grasp the general attitude |
| 05:43 | <ondras> | well, I do not bring any new insights. as a web developer who creates similar windows with existing APIs, I always stick to open/close or show/hide |
| 05:43 | <Hixie_> | (it's still being implemented, so now's the last chance to get the names pinned down) |
| 05:44 | <ondras> | but my voice has a zero weight, I guess |
| 05:44 | <ondras> | all the relevant arguments were mentioned |
| 05:44 | <Hixie_> | ondras: do you use openModal() or showModal() though? |
| 05:44 | <Hixie_> | for modal dialogs, close() seems to be uniformaly the right terminology, but the question is how do you open it |
| 05:44 | <Hixie_> | and a lot of APIs do seem to use show*() for modals |
| 05:45 | <Hixie_> | like showModalDialog(), MessageBox::Show(), etc |
| 05:45 | <ondras> | Hixie_: exactly as you said; "close" being the more natural versions, which implies - because of consistency - that the second method must be "open" |
| 05:45 | <ondras> | *version |
| 05:45 | <ondras> | the openModal()/showModal() are some existing standardized APIs? I was thinking more of a proprietary application/widget-specific methods |
| 05:46 | <Hixie_> | showModalDialog() is in HTML already, takes close() |
| 05:46 | <Hixie_> | MessageBox is win32 |
| 05:46 | <Hixie_> | something that would be useful is an objective look at what other APIs do |
| 05:46 | <Hixie_> | e.g. win32, jQuery, delphi, etc |
| 05:47 | <ondras> | I see. I was somewhat aware of a showModalDialog, but always as a MS-only non-widely-implemented extension |
| 05:51 | <ondras> | http://qt-project.org/doc/qt-4.7/qwidget.html |
| 05:51 | <ondras> | this is interesting |
| 05:51 | <ondras> | they have show, hide and close |
| 05:52 | <ondras> | show and hide being equal to setVisibility(1/0) |
| 06:25 | <ondras> | Hixie_: are you still around? |
| 06:25 | <Hixie_> | sort of |
| 06:27 | <ondras> | Hixie_: I have this weird behavior of querySelectorAll in a particular case |
| 06:27 | <ondras> | Hixie_: http://jsfiddle.net/fwJrp/ |
| 06:28 | <ondras> | basically, a table inside a table |
| 06:28 | <ondras> | but the behavior is consistent across browsers |
| 06:28 | <ondras> | looks incorrect, but there is probably some stuff in the spec that I am missing |
| 06:28 | <Hixie_> | why is it wrong? |
| 06:28 | <ondras> | shall be 1? |
| 06:28 | <ondras> | rows in tbody inside the second table |
| 06:29 | <Hixie_> | the tr is in a tbody, so it should be selecting the thead's row |
| 06:29 | <Hixie_> | the thead's tr i mean |
| 06:29 | <ondras> | oh right, my bad |
| 06:30 | <ondras> | no |
| 06:30 | <ondras> | damn. |
| 06:30 | <ondras> | the querySelectorAll |
| 06:30 | <ondras> | is executed on the second table |
| 06:30 | <ondras> | so I thought that the expression takes that node as a root for evaluating the selector |
| 06:31 | <Hixie_> | there's some scoping mechanism, but i forget what it is |
| 06:31 | <Hixie_> | :scope or something |
| 06:32 | <ondras> | Hixie_: http://updates.html5rocks.com/2013/03/What-s-the-CSS-scope-pseudo-class-for |
| 06:32 | <ondras> | found it |
| 06:32 | <ondras> | thanks |
| 07:39 | <zcorpan> | jgraham: MikeSmith: why isn't https://critic.hoppipolla.co.uk/r/309 tracking the PR anymore? |
| 07:54 | <zcorpan> | jgraham: btw, it might be useful to try to get plinns on board with the testing thing. i recall from the css f2f that he hadn't integrated css's testing thing with your thing because the goals are different (getting spec to rec vs. improving interop). but he also said he didn't mind having different tests for the different goals |
| 07:56 | <zcorpan> | (or something along those lines) |
| 08:09 | <zcorpan> | Hixie_: http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js is still broken. can you look at it, please? it blocks me generating html-differences with anolis+xref. |
| 10:02 | <jgraham> | zcorpan: Because MikeSmith rebased the branch |
| 10:02 | <jgraham> | It doesn't (yet) deal with that automagically |
| 10:03 | <jgraham> | YOu have to click "Rebase Review", follow the steps, and then reenable tracking |
| 10:10 | <zcorpan> | jgraham: ah |
| 10:10 | <zcorpan> | thx |
| 10:12 | <jgraham> | (I did it for that review) |
| 14:07 | <annevk> | So should TextDecoder and XMLHttpRequest also accept ArrayBuffer in addition to ArrayBufferView? |
| 14:08 | <annevk> | Also, where is ArrayBufferView defined these days? |
| 14:09 | <annevk> | Did they rename that to DataView in ES6? Is that compatible? |
| 14:11 | <annevk> | Oh, it was never exposed... |
| 14:12 | <annevk> | The ES6-equivalent is %TypedArray% |
| 14:25 | <zcorpan> | annevk: i think we should allow both as input for consistency with WebSocket |
| 14:26 | <annevk> | Yeah, filed a bug on IDL |
| 14:26 | <annevk> | Now they're ES types IDL needs fixing |
| 14:46 | <MikeSmith> | jgraham, zcorpan - so, clearly there is something I'm doing wrong as far as what Critic expects |
| 14:46 | <MikeSmith> | but I don't know exactly what |
| 14:47 | <MikeSmith> | I don't understand how to rebase without getting that error e-mail from Critic |
| 14:47 | <zcorpan> | do you need to rebase? |
| 14:47 | <MikeSmith> | I had thought I did because Critic expected it for some reason |
| 14:48 | <MikeSmith> | but I assume now that all I need to do is a simple commit and push to the branch |
| 14:48 | <zcorpan> | yeah |
| 14:49 | <MikeSmith> | OK |
| 14:49 | <jgraham> | MikeSmith: So, I don't know what you're *doing*, much less what you're doing wrong |
| 14:49 | <MikeSmith> | what I did was just a "git rebase master" on the branch |
| 14:49 | <MikeSmith> | and then "git push -f" to push it to the branch |
| 14:49 | <MikeSmith> | my branch |
| 14:50 | <MikeSmith> | and.. that's it, really |
| 14:51 | <jgraham> | So did you do anything with critic? |
| 14:52 | <MikeSmith> | yeah, responded to review feedback from zcorpan |
| 14:52 | <MikeSmith> | manually, through the Critic ui |
| 14:52 | <jgraham> | But you didn't interact with the rebase feature? |
| 14:53 | <MikeSmith> | yeah, well, I pushed the button for "Update" whatever |
| 14:53 | <MikeSmith> | the one next to "Rebase Review" |
| 14:53 | <MikeSmith> | because... I thought I had to do that for some reason |
| 14:53 | <jgraham> | If you push "Update" at that point, you will get an error |
| 14:54 | <MikeSmith> | aha |
| 14:54 | <MikeSmith> | so ok then, what exactly should I do at that point? |
| 14:54 | <MikeSmith> | nothing? |
| 14:54 | <jgraham> | Because it needs to be told about the rebase |
| 14:54 | <MikeSmith> | ah |
| 14:54 | <MikeSmith> | so how do I do that? |
| 14:55 | <jgraham> | At the moment you push "Rebase Review" |
| 14:55 | <jgraham> | And then follow the steps |
| 14:55 | <jgraham> | Clearly this needs to be more automated if possible |
| 14:55 | <MikeSmith> | well mostly it's probably just pilot error on my part |
| 14:55 | <MikeSmith> | I just like to push buttons to see what will happen |
| 14:56 | <zcorpan> | automate and remove the buttons by default :-) |
| 14:56 | <MikeSmith> | so anyway, right now I will push "Rebase Review" and see what I break next :) |
| 14:56 | <jgraham> | Well, like I say, I think there is probably enough information in the github API to do this automatically |
| 14:56 | <jgraham> | But I am not sure until I try to implement |
| 14:57 | <zcorpan> | MikeSmith: jgraham already rebased review 309 |
| 14:57 | <MikeSmith> | oh |
| 14:57 | <MikeSmith> | well, the commits don't show up there |
| 14:58 | <zcorpan> | it shows up as a single commit. and i've reviewed it |
| 14:58 | <jgraham> | Right |
| 14:58 | <jgraham> | So |
| 14:59 | <jgraham> | Critic can't, in general, tell the difference between changes that happened because of the rebase, and extra commits that you pushed |
| 14:59 | <MikeSmith> | ok |
| 14:59 | <MikeSmith> | ah yeah |
| 14:59 | <MikeSmith> | so I understand why that's the case |
| 15:01 | <MikeSmith> | zcorpan: so you saw/reviewed https://github.com/sideshowbarker/web-platform-tests/commit/8532cf210959b36c2d3f877da508754ee0646cda ? |
| 15:01 | <MikeSmith> | which is, I just dropped the CRs from that test document completely |
| 15:02 | <zcorpan> | MikeSmith: yes. and there's currently 1 open issue. :-) |
| 15:02 | MikeSmith | tries to find where the issue is listed |
| 15:02 | <jgraham> | Basically when you push a rebase, it looks at the whole branch history before the rebase, the whole branch history after the rebase, and calls the difference between these two the "equivalent merge commit" |
| 15:03 | <zcorpan> | MikeSmith: under "Open Issues" in https://critic.hoppipolla.co.uk/r/309 |
| 15:03 | <MikeSmith> | I see that the UI says there's an issue but as yet I don't find right away where the issue is listed |
| 15:03 | <MikeSmith> | jgraham: right yeah, understood |
| 15:03 | <MikeSmith> | zcorpan: OK I see the Open Issues head there again now |
| 15:04 | <MikeSmith> | ah OK |
| 15:05 | <zcorpan> | gotta go |
| 15:05 | <MikeSmith> | zcorpan: ok, thanks |
| 15:05 | <MikeSmith> | thanks for your patience :) |
| 15:09 | <jgraham> | In more examples of aresome PHP documentation, it doesn't say if echo (or print) implicity adds a line break |
| 15:09 | <jgraham> | *awesome |
| 15:09 | <jgraham> | Although arse-some would be more right |
| 15:11 | <jgraham> | Anyone want to enlighten me? |
| 15:11 | <zewt> | isn't that a pretty trivial thing to just find out :P |
| 15:12 | <zewt> | > php |
| 15:12 | <zewt> | <? print "x"; print "x"; ?> |
| 15:12 | <zewt> | xx |
| 15:12 | <darobin> | jgraham: it probably depends on something in php.ini :) |
| 15:12 | <jgraham> | zewt: I don't have PHP installed… |
| 15:13 | <jgraham> | zewt: So, is echo the same or is it different? |
| 15:13 | <zewt> | same |
| 15:14 | <jgraham> | zewt: Thanks |
| 15:15 | <jgraham> | I wonder why they thought that three ways to spell the same feature were needed |
| 17:10 | <jsbell> | annevk: Thanks for kicking off the "byte sequence" bug/discussion. |
| 17:23 | <annevk> | jsbell: was trying to fix bugs in XHR and ran into that basically :) |
| 17:35 | <annevk> | jsbell: DataView is just another ArrayBufferView right? |
| 17:37 | <zewt> | ... what the fuck? |
| 17:37 | <zewt> | DataView defaults ... to big endian? |
| 17:37 | <zewt> | who is smoking what, and in what quantities? |
| 17:40 | <Jasper> | zewt, networking is typically big-endian |
| 17:41 | <zewt> | nothing in javascript ever touches low-level network data |
| 17:41 | <jsbell> | annevk: Yeah, DataView is an ArrayBufferView |
| 17:41 | <annevk> | jsbell: not entirely clear whether that's still the case in ES6 btw |
| 17:42 | <jsbell> | I didn't see "ArrayBufferView" at all in the ES6 draft. |
| 17:43 | <jsbell> | So depends what you mean by "just" I guess |
| 17:43 | <annevk> | jsbell: the common ancestor is %TypedArray% for Uint8Array and friends |
| 17:44 | <annevk> | jsbell: which is not exposed |
| 17:44 | <annevk> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-22.2 |
| 17:44 | <annevk> | DataView is defined elsewhere http://people.mozilla.org/~jorendorff/es6-draft.html#sec-24.2 and seems somewhat unrelated |
| 17:44 | <jsbell> | annevk: %TypedArray% is more of a macro parameter in the spec than a type, if I read it correctly. |
| 17:44 | <zewt> | DataView is pointless, should just be rolled in as methods on the base class of all views |
| 17:45 | <annevk> | jsbell: yeah |
| 17:45 | <Ms2ger> | <zcorpan> jgraham: btw, it might be useful to try to get plinns on board with the testing thing. i recall from the css f2f that he hadn't integrated css's testing thing with your thing because the goals are different (getting spec to rec vs. improving interop). but he also said he didn't mind having different tests for the different goals |
| 17:45 | <Ms2ger> | Sounds like we get to put css tests in wpt, then? |
| 17:45 | <jsbell> | zewt: Use case for DataView is you get a buffer off the wire and then you are parsing it... you can do unaligned access which the array types don't let you do w/o copying. |
| 17:46 | <jsbell> | Ah, missed the "base class of all views". Well, if there was one. :) |
| 17:48 | <zewt> | sorry, I mean having the methods on a separate object you have to create is pointless; the methods should just be available on the other views |
| 17:48 | <zewt> | afk, work |
| 17:53 | <annevk> | jsbell: added a comment with what I think we can use as strategy |
| 17:53 | <annevk> | jsbell: well, apart from return value... |
| 17:53 | <jsbell> | :) |
| 17:55 | <annevk> | jsbell: is there a reason we went with returning a view in TextEncoder? |
| 17:57 | <jsbell> | annevk: I don't recall off the top of my head, will poke around in the threads. Possibly because a raw ArrayBuffer is pretty useless and you're probably going to wrap it with a Uint8Array anyway |
| 17:57 | <jsbell> | We need sicking to weigh in. I share his concern that for APIs that accept and emit binary (like indexeddb), passing in one type and getting another out is wierd. |
| 17:58 | <Jasper> | zewt, the even more fun thing is that if you use a Uint32Buffer or something, the endianness is completely undefined |
| 17:58 | <Jasper> | zewt, which I think is absolutely broke |
| 17:58 | <Jasper> | n |
| 17:58 | <sicking> | jsbell: especially when that API is a storage API :) You generally expect to get back what you store :) |
| 17:59 | <jsbell> | ... which would be true for IDB values but not "I just want binary" keys. |
| 17:59 | <Ms2ger> | jgraham, ping |
| 18:00 | <sicking> | jsbell: is there a problem with limiting to Uint8Array as type? Should be pretty cheap and easy to always wrap a Uint8Array around whatever type you have |
| 18:00 | <sicking> | brb |
| 18:00 | <annevk> | sicking: is there a problem with supporting all the different types? |
| 18:00 | <jsbell> | sicking: See the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369 |
| 18:01 | <jsbell> | ... for the other side of the argument so far |
| 18:01 | <annevk> | jsbell: seems that for Indexed DB you might want something more complicated |
| 18:01 | <annevk> | jsbell: platform APIs I was thinking of were XMLHttpRequest, WebSocket, TextDecoder, Blob, File, etc. |
| 18:02 | <annevk> | jsbell: for those normalization makes sense, dunno about Indexed DB |
| 18:02 | <jsbell> | annevk: For this particular bit of IDB we really do just want a ByteSequence (it's a proposed addition, BTW, not a shipping feature) |
| 18:02 | <annevk> | Oh okay |
| 18:03 | <jsbell> | We could mandate Uint8Array in/out but platform alignment seem like a good thing |
| 18:04 | <jgraham> | Ms2ger: pong |
| 18:04 | <sicking> | annevk: remember that we're talking about keys here. IDB already supports storing all types of binary arrays |
| 18:05 | <Ms2ger> | jgraham, https://critic.hoppipolla.co.uk/r/303 doesn't seem to be closed |
| 18:05 | <annevk> | sicking: aight |
| 18:06 | <annevk> | sicking: https://gist.github.com/domenic/0c47ae300608341f3d7f is Domenic_'s sketch on streams btw, it's not done or anything, but at least a lot less complex than what's going on over at public-webapps... |
| 18:07 | <jgraham> | Ms2ger: Weird. It looks like the code ran, although I can't tell if it was for that PR |
| 18:07 | <sicking> | annevk: yeah, what's on webapps is all wrong. I've been very slowly sketching something different. Getting performance right is one of the tricky bits |
| 18:07 | <jgraham> | Ms2ger: Thanks for the bug report |
| 18:08 | <Ms2ger> | jgraham, np |
| 18:08 | <Ms2ger> | jgraham, you can test with https://critic.hoppipolla.co.uk/r/216 if necessary |
| 18:08 | <sicking> | annevk: hrm.. i don't think dominic's sketch is right. You want a synchronous read() function I think |
| 18:10 | <annevk> | sicking: hmm |
| 18:10 | <Domenic_> | sicking: i am not sure either, but, from what i understood of isaac's concerns, he wanted sync read only to avoid the microtask delay |
| 18:10 | <Domenic_> | but microtask delay should in theory be non-noticable |
| 18:11 | <Hixie_> | Ms2ger: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=23356 |
| 18:11 | <Ms2ger> | Hixie_, yes? |
| 18:11 | <Domenic_> | but the correct design might indeed be some kind of poll-like function of the type isaac outlined, and you build promise-returning read() on top of it. |
| 18:11 | <sicking> | Domenic_: i don't think it's just that. But I'll reread his latest email. |
| 18:12 | <Hixie_> | Ms2ger: yes in answer to the question, or? |
| 18:12 | <Domenic_> | annevk: returning ArrayBuffer, generally, seems best. lets people choose the view they want |
| 18:12 | <sicking> | Domenic_: right. My thinking so far is that that is the right approach. |
| 18:12 | <Ms2ger> | Hixie_, "yes" as in "ack" |
| 18:12 | <Hixie_> | Ms2ger: ah ok |
| 18:12 | <Hixie_> | heycam|away: i don't have a satisfactory answer to give re: styling widgets. i tried to fix it with xbl2, but that didn't go anywhere. |
| 18:12 | <Domenic_> | sicking: cool, let me know what you deduce. he's on vacation which is why i haven't tried floating this anywhere; i want his stamp of approval, or at least approval-modulo-get-off-my-lawn-promise-users, before actually floating it. |
| 18:13 | <Ms2ger> | Hixie_, I have no dog in this fight; I just wanted to have something on file so I could point to it in a test |
| 18:13 | <sicking> | Domenic_: sounds good. I was planning on simply replying to his email once i had something |
| 18:13 | <sicking> | Domenic_: sorry it's taking so long. This isn't my day job these days |
| 18:14 | <Domenic_> | sicking: heh, mine neither! :P |
| 18:14 | <sicking> | Domenic_: :) |
| 18:16 | <Hixie_> | Ms2ger: sorry for being unclear; my question in the bug is just trying to figure out what your proposal would involve, not trying to see your opinion of it :-) |
| 18:17 | <Ms2ger> | Hixie_, my proposal is to do whatever document.images and friends do |
| 18:17 | <jsbell> | annevk: re: Encoding - looks like the early sketches of the API had it encode into a passed ArrayBufferView; that flipped to a return value, then the type was made concrete as Uint8Array. There were suggestions along the way to make it just return ArrayBuffer, but looks like those were ignored. |
| 18:18 | <annevk> | jsbell: I guess it's too late to change now |
| 18:25 | <annevk> | jsbell: btw, %TypedArray% is a common object, /TypedArray/ is not |
| 18:25 | <annevk> | jsbell: the italics matter afaict |
| 18:25 | <annevk> | hmm maybe not |
| 18:26 | <annevk> | hmm maybe yes |
| 18:30 | <jsbell> | hmm +1 - "The %TypedArray% intrinsic function object is designed to act as the superclass of the various /TypedArray/ |
| 18:30 | <jsbell> | constructors." - yeah, more concrete than I thought. |
| 18:31 | <Hixie_> | Ms2ger: roger |
| 18:37 | <jsbell> | Hrm. Does having IDL specify operation(SomeType foo) preclude passing ES6 subclasses of SomeType to operation? |
| 18:45 | <Ms2ger> | jsbell, yes |
| 18:46 | <annevk> | IDL needs fixing so badly |
| 18:46 | <jsbell> | That seems rather unfortunate. |
| 18:47 | <Ms2ger> | Why? |
| 18:47 | <annevk> | I don't even see why that would be true... If something accepts Node, it accepts Element... |
| 18:47 | <annevk> | Same should be true for ES6-style subclasses. |
| 18:47 | <Ms2ger> | Why? |
| 18:47 | <Ms2ger> | They're not trustworthy |
| 18:48 | <Ms2ger> | Something that takes Node should never accept an object that isn't a browser-implemented Node |
| 18:48 | <annevk> | Ms2ger: @@create gives it the same data model on which the browser can operate |
| 18:48 | <Jasper> | key events in browsers are so terrible |
| 18:49 | <Jasper> | we really need to fix this mess: https://github.com/kanaka/noVNC/blob/master/include/input.js |
| 18:49 | <annevk> | Jasper: are you volunteering? |
| 18:51 | <jsbell> | Jasper: do you have feedback on the key events part of https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm since it's starting to be implemented? |
| 18:56 | <Jasper> | annevk, depends what "volunteering" means |
| 18:57 | <Jasper> | jsbell, a big thing to think about is IM support, like pre-edit. |
| 18:58 | <jsbell> | hrm, I was sitting next to someone working on an IME+browser spec the other day... |
| 18:58 | <Jasper> | jsbell, it would be nice to see a full set of events for making robust input controls without having to have a hidden <textarea> |
| 18:59 | <annevk> | jsbell: one of the bad things with that document is it being a superset, though I think they plan on merging at some point |
| 18:59 | <jsbell> | Do note that I'm not working on that spec, just aware of it since I agree the current events are a mess :) |
| 19:00 | <annevk> | Jasper: mostly writing test cases I suppose and defining a model around your findings and then defining the events on top of that model |
| 19:00 | <Jasper> | annevk, have you seen http://unixpapa.com/js/key.html ? |
| 19:00 | <jsbell> | Jasper: Ah, yes: https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html |
| 19:00 | <annevk> | Jasper: looks like a start |
| 19:01 | <Jasper> | jsbell, is this for people that want to write IMs, or for people who want to write controls that interface with IMs? |
| 19:02 | <jsbell> | Jasper: "This specification defines an �IME API� that provides Web applications with scripted access to an IME (input-method editor) associated with a hosting user agent." |
| 19:02 | <Jasper> | OK. |
| 19:03 | <Jasper> | I also don't know what we want to do about keymapping. Most toolkits have just relegated to client-side keymaps, but that's really difficult to do on the web. |
| 19:03 | <jsbell> | Jasper: Who's "we", out of curiosity? |
| 19:04 | <Jasper> | "we" = specification authors |
| 19:04 | <Jasper> | I mainly work on GTK+, but that's not who I was referring to in the above sentence. |
| 19:07 | <jsbell> | Jasper: anyway, yeah, feel your pain. I bodged together https://github.com/inexorabletash/polyfill/blob/master/keyboard.js for my own use. I know the authors of the above specs want feedback. |
| 19:17 | <zcorpan_> | JS doesn't support a way to set properties of an object from properties of another object without enumerating, does it? |
| 19:18 | <Domenic_> | depends on what you mean by enumerating... |
| 19:18 | <gsnedders> | zcorpan_: ES5 doesn't, no |
| 19:19 | <zcorpan_> | what about ES>5? |
| 19:19 | <gsnedders> | Object.assign |
| 19:19 | <gsnedders> | I think? |
| 19:19 | <annevk> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.1.3.1 TODO |
| 19:20 | <annevk> | zcorpan_: what do you want? |
| 19:20 | <gsnedders> | Someone remind me what the diff. between the proposed assign and mixin is? |
| 19:20 | <Domenic_> | Object.assign is entirely implementable in ES5, there's nothing new |
| 19:20 | <gsnedders> | Right, sure. |
| 19:21 | <Domenic_> | same for Object.mixin, modulo the fact that it uses Object.getOwnSymbols() which doesn't exist in ES5 |
| 19:21 | <zcorpan_> | context is http://lists.w3.org/Archives/Public/www-style/2013Sep/0732.html |
| 19:21 | <Domenic_> | zcorpan_: what do you mean by enumerating? |
| 19:21 | <zcorpan_> | Domenic_: i mean e.g. for in |
| 19:21 | <Domenic_> | well e.g. is kind of what i was hoping to pin down |
| 19:21 | <gsnedders> | zcorpan_: But Object.assign and Object.mixin do enumerate… in the built-in classes. |
| 19:21 | <Domenic_> | you can avoid for-in by using e.g. Object.getOwnPropertyDescriptors |
| 19:22 | <gsnedders> | s/classes/objects/ |
| 19:22 | <annevk> | zcorpan_: overload the setter |
| 19:22 | <zcorpan_> | ok so i guess my question was badly phrased. i don't mind if enumeration actually happens, i'm just looking for convenience for the author |
| 19:22 | <annevk> | zcorpan_: there's an outstanding feature request for that |
| 19:22 | <Domenic_> | can i suggest writing these things as a JS library first, then figuring out the appropriate WebIDL afterward |
| 19:23 | <annevk> | zcorpan_: so you always return DOMPoint, but you accept setting to either DOMPoint or DOMPointInit |
| 19:24 | <zcorpan_> | annevk: so is that (a) or (c) ? |
| 19:25 | <annevk> | zcorpan_: dunno, the IDL says stuff is readonly |
| 19:25 | <annevk> | zcorpan_: maybe writing this as a library is not such a bad idea |
| 19:26 | <zcorpan_> | annevk: the idea would be to change it to not be readonly, hence the question what setting should do :-) |
| 19:27 | <annevk> | zcorpan_: (c) |
| 19:27 | <zcorpan_> | (what i'm looking for now is a reason to keep it as readonly, if ES6 makes it convenient anyway) |
| 19:27 | <zcorpan_> | annevk: ok. why? |
| 19:27 | <annevk> | zcorpan_: calling it a literal is somewhat confusing btw |
| 19:28 | <Domenic_> | yeah a literal would be something like pt`(1, 2)` |
| 19:29 | <Domenic_> | or quad`((1, 2), (2, 3), (3, 4), (4, 5))` |
| 19:29 | <zcorpan_> | ok, thanks. what should it be called instead? Dict? |
| 19:30 | <annevk> | zcorpan_: Init |
| 19:30 | <Domenic_> | WebIDLArtifact? :P Dict or Init seems fine... |
| 19:31 | <zcorpan_> | can you explain how DOMPointInit makes sense? just consistency with events? |
| 19:32 | <annevk> | zcorpan_: it serves to initialize a new DOMPoint |
| 19:32 | <annevk> | zcorpan_: and yes |
| 19:32 | <zcorpan_> | ok |
| 19:32 | <annevk> | Domenic_: less jokes, more work on actually making it an artefact? |
| 19:32 | <annevk> | ;) |
| 19:33 | <Domenic_> | annevk: fair... |
| 19:33 | Domenic_ | goes back to real job |
| 19:34 | <zcorpan_> | Object.assign says "Only enumerable own properties of source" which wouldn't work for DOMPoint since the properties are on the prototype per WebIDL |
| 19:35 | <zcorpan_> | annevk: did you answer the why (c) ? |
| 19:35 | <annevk> | zcorpan_: no, but it seems convenient, though thinking a bit more for URLQuery I only support new URLQuery objects at the moment |
| 19:36 | <annevk> | zcorpan_: when assigning to url.query that is |
| 19:36 | <zcorpan_> | annevk: i mean why (c) over (a)? |
| 19:36 | <annevk> | well fuck, my train back to Boston is cancelled |
| 19:36 | <zcorpan_> | :-| |
| 19:37 | <annevk> | (I have some time to reschedule, but it's annoying) |
| 19:37 | <annevk> | zcorpan_: (a) seems weird, but I don't really have a good reason |
| 19:38 | <annevk> | zcorpan_: I guess if you do obj.x = y and then further mutate y, you'd expect that to affect obj.x |
| 19:39 | <Domenic_> | ^ yeah, that |
| 19:39 | <Domenic_> | but that won't work without rethinking a lot, I think.. |
| 19:39 | <Domenic_> | making it do no validation until consumption time |
| 19:39 | <zcorpan_> | that fails if it's an {x, y} |
| 19:40 | <annevk> | zcorpan_: I think if you pass in something that the property does not return you can expect that |
| 19:41 | <annevk> | zcorpan_: similar to setting location to a string |
| 19:41 | <zcorpan_> | on the flip side, if you have a quad and store its points as local variables, do you expect them to suddenly not be associated with the quad anymore? |
| 19:41 | <Domenic_> | if a JS library was doing this, it would do no validation in any of the setters, it would just accept anything. then the internal code that actually uses this.somePoint.x, this.somePoint.y would get those properties, and if they weren't there might throw (or might coerce ToNumber) |
| 19:42 | <Domenic_> | that way you could do things like quad.p1 = { x: 10, y: 20, extraStuff: "foo" } |
| 19:42 | <Domenic_> | and not disturb the internal algorithms at all, but still be able to access quad.p1.extraStuff later |
| 19:43 | <Domenic_> | that is probably too much re-thinking though |
| 19:43 | <annevk> | you prolly do want to coerce here at some point to pass things to the rendering subsystem |
| 19:43 | <Domenic_> | annevk: right but you'd do that at rendering time, no sooner |
| 19:44 | <annevk> | no you'd do it sooner because rendering can be on a separate thread and you don't want that to be observable |
| 19:44 | <Domenic_> | heh :). well JS libraries don't have access to separate threads |
| 19:44 | <Domenic_> | so it becomes a question of how un-idiomatic do you need to make things to fit into a multithreaded model. |
| 19:45 | <annevk> | coercion doesn't seem un-idiomatic, ToString() is used, Array.slice is used |
| 19:45 | <annevk> | turning an argument into an object seems fine |
| 19:45 | <Domenic_> | sure but you coerce when you use them, not when you set the property |
| 19:45 | <Domenic_> | if you were designing a JS library that took in points and quads you would not have this object hierarchy |
| 19:46 | <annevk> | I think bz mentioned quite a few libraries coerce right at the entry point of the function |
| 19:46 | <Domenic_> | you would just take as input an object and do `+obj.p1.x` and pass that to the rendering system |
| 19:46 | <Domenic_> | oh interesting |
| 19:46 | <Domenic_> | i guess i'm mostly thinking of jQuery and d3 |
| 19:46 | <Domenic_> | and ES spec algorithms of course |
| 19:47 | <Domenic_> | anyway i need to pack up my crazy ideas and head elsewhere before people flip the bozo bit on me :). sorry zcorpan_ for derailing your well-meaning quest for practical advice. |
| 19:47 | <zcorpan_> | Domenic_: np, thanks for the feedback |
| 19:58 | <zcorpan_> | renamed to Init |
| 20:03 | <zcorpan_> | http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0159.html suggests using a method instead of a magic setter |
| 20:19 | Ms2ger | never realized that the IE10 logo is closer it IE6's than to IE7/8/9's |
| 20:29 | <Domenic_> | TabAtkins: is there a plan to make it possible to style a label for a checkbox differently, depending on whether or not its checked? I know the magic selectors 4 would make it work if those applied to stylesheets, but they don't. Any other plans? |
| 20:32 | <zewt> | jsbell: there is a base class (or at least a base interface) for all views, ArrayBufferView |
| 20:32 | <zewt> | err, Jasper |
| 20:33 | <zewt> | Jasper: yeah, we've tried to get them to fix that and they just don't "get" the web and why that's unacceptable |
| 20:34 | <jsbell> | zewt: You probably do mean me, and: yes, but not in the ES6 spec. |
| 20:34 | <zewt> | probably both (the latter was Jasper) |
| 20:35 | <jsbell> | (yep) |
| 20:35 | <zewt> | and ... why would they remove the base class? taking a bad API and making it worse |
| 20:35 | <Jasper> | zewt, who is "them"? Khronos? |
| 20:35 | <Ms2ger> | Is that TC39's tagline? |
| 20:35 | <zewt> | whoever's taking the typed array spec, putting it in another spec and taking out the base class |
| 20:36 | <Jasper> | hey TC39, don't be afraid. take a bad API and make it wooorse |
| 20:36 | <zewt> | anyway, it already has a base class in browsers, so that probably can't go away anyway |
| 20:36 | <zewt> | (window.ArrayBufferView exists in Chrome, at least) |
| 20:36 | <Jasper> | zewt, your answer was to my question about undefined endianness, right? |
| 20:36 | <zewt> | yeah |
| 20:36 | <Ms2ger> | Why would they spec things that work in browsers? |
| 20:36 | <Jasper> | zewt, I don't understand who is "them" in that case. TC39? |
| 20:36 | <zewt> | that's khronos, iirc, the typed array spec |
| 20:37 | <zewt> | (an offshoot of webgl) |
| 20:37 | <zewt> | i know why they did it the way they did; it's just wrong |
| 20:37 | <zewt> | Jasper/jsbell: i think your nicks have a hash collision in my brain at this point |
| 20:38 | <Jasper> | update from MD5? |
| 20:38 | <zewt> | i guess my hash is nick[0] |
| 20:38 | <zewt> | j.*s.*e |
| 20:40 | <Jasper> | zewt, I'm just concerned that people will load little endian files into Float32Array |
| 20:40 | <Jasper> | and then it will break when somebody plays it on a PowerPC or something |
| 20:40 | <zewt> | Jasper: oh, they will |
| 20:41 | <zewt> | the typed array editor(s) are under a misapprehension, heh |
| 20:41 | <TabAtkins> | Domenic_: No, but given that subject indicators are going to be part of the slow profile, we should indeed solve that issue for normal stylesheets. |
| 20:41 | <zewt> | they think that if they spec "this is platform-endian-dependent", browsers will implement that even if it causes big endian systems to not work on the web |
| 20:41 | <zewt> | the reality is that browsers will ignore the spec and make them always little-endian so that pages actually work (and take a performance hit, possibly a large one, for some WebGL cases) |
| 20:42 | <zewt> | (the real reality seems to be that big endian is essentially dead, and nobody even cares if it's broken) |
| 20:42 | <zewt> | iirc, the latter of those is why I stopped trying to convince them |
| 20:43 | <Domenic_> | TabAtkins: ok cool, yeah. |
| 20:43 | <Domenic_> | (I'm still secretly hoping someone implements the slow profile for normal stylesheets anyway and browser game theory forces it to become widespread.) |
| 20:45 | <TabAtkins> | Domenic_: Heh. You say that, but you'll be sad if putting one of them in your page drastically slows down all your selector matching. |
| 20:46 | <zewt> | Jasper: also, the alignment requirement of views is nonsense and should be removed (but I don't have the energy to try to get them to change things currently) |
| 20:46 | <zewt> | Jasper: however, the DataView interfaces are useful regardless of that, for parsing binary data structures (eg. to pull apart a ZIP header) without having to create tons of temporary views |
| 20:46 | <Jasper> | zewt, it would be nice if everything standardized to little-endian by default, but you could create a Float32Array that explicitly had host requirements because you know you won't be shipping this data anywhere |
| 20:47 | <Jasper> | had host endianness rather |
| 20:47 | <zewt> | yeah, I suggested at *least* adding explicit Int32LEArray/Int32BEArray (i don't remember the response, but it clearly hasn't happened) |
| 20:47 | <Jasper> | but what's likely to happens is that people will discover One Weird Trick To Speed Up Your Game By 200% |
| 20:47 | <Jasper> | and then everything's back to broken |
| 20:48 | <Jasper> | zewt, yeah, I'm more than familiar with the crazy things you can do with this |
| 20:48 | <Philip`> | zewt: I'm aware of some people using big-endian MIPS for new set-top box type things, with OpenGL support, who would probably try to disagree that it's dead |
| 20:48 | <Jasper> | https://github.com/magcius/img.js/blob/gh-pages/gif.js |
| 20:48 | <Jasper> | among other things |
| 20:48 | <zewt> | Philip`: they're fools and need to be shot into the sun |
| 20:49 | <Jasper> | zewt, I ran into the alignment requirements in that file I think |
| 20:49 | <Jasper> | also, I wrote a WebGL app that to this day still crashes Firefox |
| 20:49 | <Philip`> | zewt: (I think they're using essentially a little-endian GPU but with some hardware/software wrappers to make it cope with big-endian data) |
| 20:50 | <zewt> | basically, systems that need host-endian access to buffers (or else be really slow) are fundamentally incompatible with the Web (on one or the other endianness) |
| 20:50 | <zewt> | as far as I can tell, at least |
| 20:50 | <Jasper> | zewt, well, not entirely |
| 20:51 | <zewt> | maybe you could come up with some set of restrictions to only allow host-endian buffers to be used with WebGL, and not for general-purpose use ... but i'm not sure how possible that is |
| 20:51 | <Jasper> | zewt, what could make sense as a middleground is to prevent anybody from using a host-endian buffer to be used on array buffers returned from XHR or similar |
| 20:52 | <Jasper> | zewt, and if you touch an array buffer with a host-endian buffer, you can't send it back through a WebSocket without reconversion or something. |
| 20:52 | <Jasper> | basically ensure that host endianness is only kept in host memory |
| 20:52 | <zewt> | their argument would probably be that games will want to serve big-endian data to big-endian systems, pre-byte-flipped |
| 20:52 | <zewt> | that sort of thing |
| 20:53 | <Jasper> | zewt, then they will write: if (hostEndianness == "BE") return new Float32ArrayBE(buffer); else ... |
| 20:53 | <zewt> | also, you'd want to be able to take XHR data, write it to disk (indexeddb, local files), read it back later and then into webgl |
| 20:53 | <zewt> | hard to maintain an "endian tainted" state through all that |
| 20:53 | <Jasper> | zewt, as long as you're explicit, you should be fine |
| 20:53 | <annevk> | zewt: ArrayBufferView is [NoInterfaceObject] |
| 20:53 | <annevk> | zewt: so that seems like a bug in Chrome |
| 20:54 | <zcorpan_> | annevk: in other news you failed to convince anyone to remove "DOM" prefix |
| 20:54 | Jasper | wonders if his old WebGL app still crashes Firefox |
| 20:55 | <annevk> | zcorpan_: if people are happy with wildly inconsistent naming practices there's not much I can do |
| 20:56 | <Jasper> | [16:56:09.713] Error: WebGL: texParameteri: pname 2800 and param 0 (decimal 0) are mutually incompatible |
| 20:56 | <Jasper> | huh so it doesn't crash anymore but it errors out |
| 20:56 | <Jasper> | chrome seems to enjoy it fine. so that's strange |
| 20:57 | <TabAtkins> | While I'm not happy with inconsistency, I *am* happy with it being hard to stomp on the browser-provided names. |
| 20:58 | <Jasper> | i always wondered why we didn't just namespace the DOM APIs |
| 20:58 | <Jasper> | should we start doing that? |
| 20:58 | <Domenic_> | we need modules :( |
| 20:59 | <Jasper> | clearly what we want is: new org.w3.canvaswg.canvas.impl.Path(); |
| 21:00 | <annevk> | o_O |
| 21:01 | <Hixie_> | falken: do you still think open() and openModal() is better for <dialog>? |
| 21:01 | <Hixie_> | ohhhh, here's another problem with renaming it |
| 21:02 | <Hixie_> | if we call it dialog.open(), we can't have the attribute dialog.open |
| 21:02 | zcorpan_ | thinks of http://discuss.joelonsoftware.com/?joel.3.219431.12 |
| 21:09 | <annevk> | Hixie_: so why show? showModalDialog is really something we should not be concerned with imo |
| 21:09 | <Hixie_> | well what would you call it instead? |
| 21:09 | <annevk> | Hixie_: window.open() / window.close() seems like a better precedent |
| 21:09 | <Hixie_> | open() would clash with .open |
| 21:10 | <annevk> | show() also clashes with .open in them not having similar names, due to window.open() you might end up being confused all the time which is which |
| 21:11 | <annevk> | .state == "open" |
| 21:11 | <Domenic_> | there's an [open] attribute though right? so .open property should match... this is a tough one. |
| 21:11 | <Hixie_> | that would make the IDL attribute that reflects <dialog open> not match the content attribute's name. |
| 21:11 | <Domenic_> | yeah and we know how much people like [value] vs. defaultValue. |
| 21:11 | <Hixie_> | note that window.open() creates a new window, dialog.show() doesn't create the dialog, it just shows it. |
| 21:12 | <Domenic_> | maybe the attribute should be [shown] |
| 21:12 | <annevk> | but dialog[open] selects an open dialog? |
| 21:12 | <Hixie_> | then it wouldn't match <details open> |
| 21:12 | <Hixie_> | annevk: yes |
| 21:12 | <Domenic_> | details is different, it's still shown when it's closed |
| 21:13 | <Hixie_> | the contents aren't |
| 21:14 | <Domenic_> | sure. but the <details> itself is... kinda sorta... i dunno, it makes sense in my head. |
| 21:14 | <annevk> | if you try to match tense though shown doesn't make sense |
| 21:18 | <zcorpan_> | <details> is unique with the attribute reflecting the state, iirc |
| 21:21 | <Hixie_> | <dialog> does the same thing |
| 21:22 | <Jasper> | zcorpan_, http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory |
| 21:40 | <Hixie_> | cocoa, .net, delphi, gtk, win32... any other APIs anyone can think of that i should research dialogs in? |
| 21:45 | <Philip`> | Hixie_: Android? |
| 21:45 | <Hixie_> | was just doign that one |
| 21:46 | <Hixie_> | i tried figuring out the x11 api but gave up |
| 21:48 | <zewt> | android ui apis D: |
| 21:50 | <Jasper> | Hixie_, X11 doesn't have native dialogs. |
| 21:50 | <Hixie_> | or windows? |
| 21:51 | <Jasper> | Hixie_, does Windows have native checkbox widgets? |
| 21:51 | <Jasper> | Hixie_, the Win32 toolkit has a checkbox implementation built on top of the Windows primitives, so it depends on how you count it. |
| 21:52 | <Hixie_> | win32 has native checkboxes, sure |
| 21:52 | <Jasper> | Right, but Win32 controls is not quite the same as the underlying window-based API. |
| 21:53 | <Jasper> | Hixie_, if you're talking about modal dialogs, the primitive you have is spinning the event loop for a different window, where the windowing system will queue up events for all other windows behind you. This allows you to basically build a dialog as a synchronous call. |
| 21:55 | <Hixie_> | i don't really mind which layer we want to look at, i'm happy to look at any or all of them :-) |
| 21:55 | <Hixie_> | just looking for apis that have "open/close/show/hide"-analogues for windows/dialogs/etc |
| 21:58 | <Jasper> | Hixie_, gtk_dialog_run / gtk_window_show are what you want to look at in GTK+ |
| 21:58 | <Jasper> | Hixie_, X11 allows you to show a window with XMapWindow, and hide with XUnmapWindow |
| 21:59 | <Hixie_> | yup, got gtk already |
| 21:59 | <Hixie_> | ah, thanks for x11 |
| 22:00 | <Jasper> | map/unmap is quite old terminology, so it's not what you want to copy. |
| 22:00 | <Hixie_> | no kidding :-) |
| 22:01 | <Hixie_> | any JS libraries have dialog APIs? |
| 22:01 | <Jasper> | ext.js has one I believe. |
| 22:01 | <Jasper> | Google Closure Toolkit has another. |
| 22:01 | <Hixie_> | jquery seems to have one |
| 22:01 | <Jasper> | http://docs.closure-library.googlecode.com/git/class_goog_ui_Dialog.html |
| 22:02 | <Hixie_> | woot, jquery has open(). finally found one that uses open(). |
| 22:02 | <Jasper> | though I'm not sure if Google still uses Closure Toolkit |
| 22:05 | <Hixie_> | closure seems to use setVisible(), ew |
| 22:06 | <gsnedders> | Hixie_: And a lot of really weird UA sniffing. |
| 22:12 | <Hixie_> | Android uses show() and dismiss() |
| 22:12 | <Hixie_> | Closure uses setVisible() |
| 22:12 | <Hixie_> | Cocoa uses makeKeyAndOrderFront:, orderOut:, close, and performClose:. |
| 22:12 | <Hixie_> | Delphi uses Show(), ShowModal(), Hide(), and Close(). |
| 22:12 | <Hixie_> | Ext JS uses show(), hide(), and close(). |
| 22:12 | <Hixie_> | jQuery uses "open" and "close". |
| 22:12 | <Hixie_> | Gtk uses gtk_widget_show(), gtk_dialog_run(), gtk_window_close(). |
| 22:12 | <Hixie_> | .NET uses Show(), ShowDialog(), Hide(), and Close(). |
| 22:12 | <Hixie_> | Win32 uses ShowWindow() and CloseWindow(). |
| 22:12 | <Hixie_> | X11 uses XMapWindow() and XUnmapWindow() |
| 22:12 | <Hixie_> | any others i should look at? |
| 22:15 | <Hixie_> | ok, sending e-mail. |
| 22:34 | <crocket> | Is there a channel for W3C? |
| 22:34 | <crocket> | #w3c is not the one. |
| 22:34 | <jsbell> | crocket: any specific part? |
| 22:34 | <crocket> | just w3c |
| 22:34 | <crocket> | W3C consortium |
| 22:36 | <TabAtkins> | You want irc.w3.org |
| 22:36 | <jsbell> | crocket: http://www.w3.org/Project/IRC/ may be useful |
| 22:37 | <crocket> | They left freenode. |
| 22:38 | <crocket> | Does HTML5 define browser object model? |
| 22:39 | <Hixie_> | kind of |
| 22:39 | <Hixie_> | depends on what you mean by that |
| 22:40 | <Hixie_> | http://dom.spec.whatwg.org/ may be what you mean, or http://whatwg.org/html#document maybe |
| 22:41 | <crocket> | Hixie_: BOM isn't DOM. |
| 22:41 | <Hixie_> | not sure what you mean then |
| 22:41 | <Hixie_> | can you elaborate? |
| 22:42 | <Hixie_> | GPHemsley: you still working on mimesniff? |
| 22:42 | <Hixie_> | GPHemsley: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0276.html |
| 22:43 | <crocket> | Hixie_: DOM == document |
| 22:43 | <crocket> | BOM == a subset of window |
| 22:43 | <Hixie_> | http://whatwg.org/html#window ? |
| 22:43 | <gsnedders> | crocket: The Window interface is in HTML |
| 22:43 | <crocket> | Does HTML5 define the entirety of BOM? |
| 22:44 | <Hixie_> | i don't know what BOM is exactly, so i can't say |
| 22:44 | <Hixie_> | describe the entirety of it, and I'll tell you whether any of it is missing :-) |
| 22:45 | <crocket> | Hixie_: "Object oriented javascript", a book, defines BOM as "The Browser Object Model (BOM) is a collection of objects that give you access to the browser and the computer screen. These objects are accessible through the global object window." |
| 22:46 | <Hixie_> | ah, then no, that's not all in HTML. There's also a bunch of it in CSSOM, CSSOM Views, and various other specs. |
| 22:46 | <crocket> | CSSOM? |
| 22:47 | <Hixie_> | CSS Object Model |
| 22:47 | <Hixie_> | CSS is Cascading Stylesheets |
| 22:47 | <crocket> | How does CSS define it? |
| 22:47 | <Hixie_> | http://dev.w3.org/csswg/cssom/ |
| 22:47 | <Hixie_> | and http://dev.w3.org/csswg/cssom-view/ |
| 22:47 | <crocket> | Does CSS have any API accessible from javascript? |
| 22:47 | <Hixie_> | those two specs define that api |
| 22:58 | <Domenic_> | Hixie_: I think the most important thing is consistency between the attribute/property and the method name. (Assume the attribute and property are the same; anything else is insanity) If the method changes the attribute, it should be connected. |
| 22:58 | <Domenic_> | Hixie_: thus I feel like show() + open is not so good. show() + shown is good. Maybe open() + isOpen/opened or similar |
| 23:00 | <Hixie_> | "isopen" reads like "iso pen". "opened" is past tense, which is inconsistent with basically everything. |
| 23:01 | <Domenic_> | yeah not sure there's any good answers |
| 23:01 | <Domenic_> | for a counterpart to open() at least |
| 23:01 | <Hixie_> | i don't think it's a problem to have .show() set .open to true. it's not that confusing. |
| 23:01 | <Domenic_> | isindex reads let isin dex? :P |
| 23:01 | <Domenic_> | i think that's pretty confusing |
| 23:01 | <Domenic_> | is it open or is it shown? |
| 23:01 | <Domenic_> | what's the difference? |
| 23:01 | <Hixie_> | "isin" and "dex" aren't words |
| 23:02 | <Hixie_> | when you open the dialog, it is shown |
| 23:02 | <Hixie_> | when you show the dialog, it opens |
| 23:02 | <Domenic_> | but it's not open? |
| 23:02 | <Hixie_> | it's fine |
| 23:02 | <Domenic_> | meh. i disagree it's fine. but that's my 2cents, not much more to say. |
| 23:03 | <Hixie_> | i think in practice people won't use open="" much anyway |
| 23:03 | <Hixie_> | so it won't be an issue even if people are confused by it |
| 23:03 | <Hixie_> | bbiab |
| 23:03 | <Domenic_> | People will use it in CSS a lot I think |
| 23:04 | <Domenic_> | transitions/animations between dialog:not([open]) and dialog[open] |
| 23:05 | <crocket> | Hixie_: Do you think BOM is split between HTML and CSS? |
| 23:07 | <Domenic_> | crocket: BOM is just something the author of that book made up; it is not a real concept |
| 23:07 | <Domenic_> | it has no meaning in terms of implementations or specs |
| 23:07 | <crocket> | Domenic_: What the hell |
| 23:08 | <Domenic_> | I know, bad book, right? |
| 23:09 | <crocket> | Domenic_: not sure it's a bad book |
| 23:12 | <Domenic_> | i dunno, maybe just the number of recruiters using the term "object oriented javascript" has given it bad associations in my mind. |
| 23:13 | <crocket> | Domenic_: you mean employers? |
| 23:14 | <crocket> | Domenic_: object orientation in smalltalk is a good thing. |
| 23:14 | <jarek> | are you talking about "Object Oriented JavaScript" by Zakas? |
| 23:14 | <jarek> | it's terrible book by todays standards |
| 23:15 | <jarek> | I would rather stick with the terms in the spec, even if they are confusing |
| 23:16 | <crocket> | jarek: I mean http://www.amazon.com/Object-Oriented-JavaScript-Edition-Stoyan-Stefanov/dp/1849693129/ref=sr_1_1?ie=UTF8&qid=1380237353&sr=8-1&keywords=object+oriented+javascript |
| 23:16 | <crocket> | Authors sent an early draft of the book, and it was published without correction. |
| 23:16 | <crocket> | So code examples aren't indented at all!!! |
| 23:17 | <jarek> | crocket: ahh, that's the best JS book for beginners I have read |
| 23:17 | <crocket> | But overall, its content is fine. |
| 23:17 | <crocket> | jarek: How many JS books have you read? |
| 23:17 | <jarek> | crocket: I read Crockford, Zakas and few others |
| 23:18 | <crocket> | How about "JavaScript: The Good Parts"? |
| 23:19 | <jarek> | crocket: it feels more like an academic paper than a book :P |
| 23:19 | <crocket> | jarek: Does it teach how to avoid bad parts? |
| 23:20 | <jarek> | crocket: yes, I guess it was the first book to teach JS the right way |
| 23:20 | <crocket> | So far, I've read elequent javascript, and I'm reading object oriented javascript. |
| 23:21 | <jarek> | crocket: if I were to learn JS now, I wouldn't bother reading more than one book |
| 23:22 | <jarek> | crocket: the most valuable information is on the web now |
| 23:22 | <crocket> | What is the one book? |
| 23:22 | <jarek> | crocket: e.g. check http://killdream.github.io/2011/10/09/understanding-javascript-oop.html |
| 23:22 | <jarek> | there is no book that would discuss JS object system in such detail ^ |
| 23:22 | <jarek> | crocket: I would pick Stefanov |
| 23:23 | <jarek> | crocket: Eloquent JS seems to be biased towards functional programming |
| 23:23 | <crocket> | jarek: functional programming was good. |
| 23:23 | <crocket> | Stefanov? |
| 23:24 | <jarek> | crocket: yeah, the one you have linked earlier |
| 23:24 | <crocket> | object oriented javascript? |
| 23:24 | <jarek> | crocket: yes, though if you are already experienced programmer (in other language) then I would jump right into Crockford |
| 23:25 | <crocket> | jarek: I'm confused. |
| 23:25 | <crocket> | Referring to books by authors is confusing. |
| 23:25 | <crocket> | I don't remember author names. |
| 23:26 | <jarek> | crocket: I don't remember book names :P |
| 23:26 | <jarek> | crocket: Crockford == JS Good parts (or something like this) |
| 23:26 | <jarek> | I mean === |
| 23:26 | <crocket> | jarek: One author could have written various books. |
| 23:27 | <jarek> | crocket: several authors could have written books with the same title |
| 23:27 | <Philip`> | All you need to remember is the ISBN |