| 00:00 | <dglazkov> | var f = document.implementation.createHTMLDocument().createDocumentFragment() in Gecko is the closest thing |
| 00:05 | <Hixie> | What do you mean by "inert"? |
| 00:05 | <Hixie> | (there's lots of possibly definitions) |
| 00:05 | <Hixie> | possible |
| 00:06 | <dglazkov> | well, I know the effects of "inert" in template pretty well, but haven't yet described precisely. |
| 00:07 | <dglazkov> | the general idea is that a developer can treat these elements as clay without fear of side effects. |
| 00:07 | <dglazkov> | images don't load, videos don't run, frames don't load, scripts don't run |
| 00:07 | <dglazkov> | also importantly --- attributes are tolerant of invalid values |
| 00:08 | <dglazkov> | so you could do crazy stuff like <img src="{{userpic}}"> and not hit the server with some url that includes "{{userpic}}" |
| 00:09 | <dglazkov> | an even crazier example involves similar machinations with tabindex and input types, but I am not yet sure that would even be possible. |
| 00:18 | <Hixie> | dglazkov: "attributes are tolerant of invalid values" and "no network traffic results" are very different |
| 00:18 | <Hixie> | dglazkov: i'm not really sure what you mean by "attributes are tolerant of invalid values" -- how are non-inert attributes not so tolerant? |
| 00:20 | <dglazkov> | Hixie: perhaps we need to come to common understanding of "tolerant"? |
| 00:20 | <Hixie> | dglazkov: definitely, if you're going to use the word :-) |
| 00:21 | <dglazkov> | <div tabindex="{{value1}}"> or <input type="$(TYPE)"> would be examples where there are limits to tolerance |
| 00:22 | <dglazkov> | you can attempt to set div.tabindex property to any value, but only integers will be accepted, right? |
| 00:23 | <dglazkov> | setting some attributes causes some internal plumbing to jump into action. |
| 00:23 | <dglazkov> | whether this plumbing attempts to make a network request or parse the value as integer |
| 00:24 | <dglazkov> | that's not really important from the effect side. |
| 00:25 | <dglazkov> | the key is that in inert DOM chunks, doing these thing should be both tolerated and not acted upon |
| 00:27 | <dglazkov> | attribute bag is a nice example. If you setAttribute("tabindex", "foo"), you will still receive "foo" from getAttribute("tabindex") |
| 00:27 | <dglazkov> | ideally, an inert chunk of DOM would do the same thing for properties. |
| 00:27 | <dglazkov> | but again, that's an effect. |
| 00:28 | <dglazkov> | another effect is that setAttribute("tabindex", "foo") doesn't trigger internal plumbing of attempting to parse the value as integer and setting the property to -1 |
| 00:29 | <dglazkov> | hth |
| 00:29 | <Hixie> | dglazkov: If you setAttribute("tabindex", "foo"), you will still receive "foo" from getAttribute("tabindex"), today, always |
| 00:29 | <dglazkov> | right! |
| 00:29 | <Hixie> | dglazkov: if you're saying you want the type of DOM properties to depend on whether they are in a template or not, that's basically a non-starter, i think |
| 00:30 | <dglazkov> | Hixie: that's not what I am saying. |
| 00:30 | <Hixie> | good :-) |
| 00:31 | <Hixie> | not sure what you're saying though in that case :-) |
| 00:31 | <dglazkov> | well, I've been pretty nicely describing desired effects, I thought. |
| 00:32 | <dglazkov> | anyhow, gotta run. bye Whatwg! |
| 00:32 | <Hixie> | i guess i don't understand why tabindex="" today doesn't do what you want |
| 00:34 | <MikeSmith> | fyi, W3C is still be affected by some routing issues somewhere |
| 00:35 | <MikeSmith> | somewhere being an outside place that W3C systems team can't fix themselves |
| 00:35 | <MikeSmith> | so they are still waiting for it to be fixed there, as far as I know |
| 01:08 | <Hixie> | Philip`: yt? |
| 01:09 | <Philip`> | Hixie: Vaguely |
| 01:12 | <Hixie> | Philip`: drawImage() when drawing from outside the source bitmap says "When the filtering algorithm requires a pixel value from outside the original image data, it must instead use the value from the nearest edge pixel."; it's suggested that we somehow limit this to 0.5px outside the source rect since otherwise you'd just get a banding effect |
| 01:12 | <Hixie> | Philip`: opinions? |
| 01:27 | <Philip`> | Hixie: Doing anything other than what standard graphics APIs already generally support (i.e. either clamp-to-edge or clamp-to-transparency or mirror or repeat, probably) sounds like it would make implementers pretty unhappy |
| 01:29 | <Philip`> | Using a source rectangle outside the original image data is basically an error condition anyway (and I think it used to throw exceptions; the behaviour was changed just to be more tolerant of floating-point errors) |
| 01:30 | <Philip`> | If it's meant to be changed into a useful feature, users probably ought to be able to select the filtering mode themselves, because no single choice will be what everyone wants |
| 01:36 | <jamesr_> | what happens today? |
| 01:39 | Philip` | doesn't know what implementations do |
| 02:06 | <Hixie> | Philip`: yeah |
| 02:10 | <Hixie> | Philip`: i'm not sure what implementations or APIs do, but webkit asked for us to change the spec |
| 02:11 | <Hixie> | Philip`: to say something about transparent black |
| 02:11 | <Hixie> | Philip`: their question is whether we want a hard edge or not or non-aligned image draws |
| 02:29 | Philip` | doesn't remember the reasons for originally preferring clamp-to-edge over transparent |
| 02:29 | <Hixie> | any objection to me just changing it to transparent? |
| 02:29 | <zewt> | well, you have to pick a transparent color |
| 02:29 | <Hixie> | 'transparent' == rgba(0,0,0,0) |
| 02:29 | <Philip`> | Depends if there was a good reason for originally preferring clamp-to-edge over transparent |
| 02:29 | <Philip`> | (other than it just being compatible with more of the implementations at that time) |
| 02:29 | <Hixie> | i've no idea |
| 02:29 | <Hixie> | i can try to look tomorrow |
| 02:29 | <zewt> | Hixie: that's bad, since it'll artifact if the result is scaled |
| 02:30 | <Philip`> | Upscaling an image will always do something that someone considers bad, I think |
| 02:30 | <zewt> | (whether it ever can be in this context I'm not sure, but I've dealt with problems arising from that too many times) |
| 02:30 | <Philip`> | (since different people want different behaviour) |
| 02:30 | <zewt> | Philip`: edge clamping is far far better than using black transparency |
| 02:31 | <zewt> | for general-purpose behavior, anyway |
| 02:32 | <Philip`> | That's what the spec currently requires, but apparently it causes problems when implementing with OS X APIs or something like that |
| 02:33 | <Philip`> | (https://www.w3.org/Bugs/Public/show_bug.cgi?id=10799 - hmm, maybe the main original reason for clamp-to-edge was to match IE9 and Opera) |
| 02:36 | Philip` | will continue his general policy of not really caring about API design and letting other people argue over that, and only caring himself that every implementation can pass the same tests, since that's an easier problem |
| 02:37 | <Hixie> | zewt: edge clamping results in streaking, so it's a non-starter |
| 02:37 | <zewt> | doesn't sound like a "non-starter" to me |
| 02:37 | <zewt> | if you don't want it, stop sampling outside the image |
| 02:39 | <Hixie> | it's a non-starter because webkit won't implement it |
| 02:39 | <zewt> | and everyone else is? ... |
| 02:39 | <Hixie> | as far as i'm aware, nobody does it |
| 02:39 | <Philip`> | Firefox doesn't on OS X, I think |
| 02:40 | <Philip`> | but I think everyone else basically does (maybe with exceptions if the source rectangle is actually outside) |
| 02:40 | <zewt> | i don't know the general rendering pipeline; if there's no way that black might be blended with edge colors, then it's probably okay, but if it might get blended in then it's definitely bad |
| 02:40 | <Philip`> | at least when I last checked |
| 02:41 | <Hixie> | the only case i'm talking about is the case where the source rectangle is outside the source image |
| 02:41 | <Hixie> | hence the suggestion about the 0.5px border |
| 02:42 | <zewt> | clamp to edge within .5px, then #00000000? that seems ... a bit too novel, at least on first impression |
| 02:42 | <Philip`> | Is the idea that they're able to implement clamp-to-edge filtering up to the edge of the source rectangle, and then a sharp transition to transparent outside the rectangle? |
| 02:43 | <Hixie> | i guess? |
| 02:43 | <Hixie> | we could also have different filtering if it's outside the source rect or not |
| 02:44 | <Philip`> | (as opposed to having the filter not clamp and act as if the image data outside the original image bounds was transparent) |
| 02:45 | <Hixie> | e.g. define the source rect as being transparent black, but with the clamp-to-edge filtering |
| 02:45 | <Philip`> | (which matters around the edges when upscaling the image, since the filter will be sampling outside the original image bounds even if it's within the source rectangle) |
| 02:46 | <Hixie> | actually maybe this is the way to go |
| 02:46 | <Hixie> | define it so that pixels inside the source rect but outside the source image are transparent black |
| 02:47 | <Hixie> | with clamp-to-edge behaviour for the filtering |
| 02:49 | <zewt> | not quite sure what you mean--clamp-to-edge is a definition of pixels outside the source image, not filtering |
| 02:49 | <Philip`> | With the current spec, if you have a 1x1 green image and draw the 3x3 source rectangle (-1,-1)..(2,2) to a 30x30 pixel destination, you'll get 30x30 pixels of green |
| 02:50 | <Hixie> | right i'm suggesting you get a 10x10 green centered in the 30x30 |
| 02:50 | <Philip`> | If it was changed to clamp-to-transparent (or whatever the term is), you'd get a heavily blurred roughly 10x10 green square (since it'll filter between green and transparent around the edges) |
| 02:50 | <Hixie> | right |
| 02:50 | <Philip`> | If it was clamp-to-edge-but-clip-to-transformed-source-rectangle, you'd get a sharp 10x10 green square |
| 02:50 | <zewt> | Philip`: i think the right analog for "clamp-to-transparent" is opengl's CLAMP_TO_BORDER with a #00000000 border |
| 02:51 | <Hixie> | Philip`: oh well that's yet another option, yes |
| 02:51 | <Hixie> | Philip`: we could do that, indeed |
| 02:51 | <Philip`> | Hixie: Isn't clamp-to-edge-but-clip-to-transformed-source-rectangle the option you were suggesting? |
| 02:51 | <Philip`> | zewt: Yeah |
| 02:52 | <Philip`> | (Annoyingly not supported by GL ES 2.0, it seems :-( ) |
| 02:52 | <Hixie> | Philip`: no, but in any case yours seems better |
| 02:53 | Philip` | doesn't understand the difference, then |
| 02:53 | <Philip`> | I guess the important question is whether clamp-to-edge-but-clip-to-transformed-source-rectangle is implementable by the people who can't implement clamp-to-edge |
| 02:53 | <Hixie> | consider a 2x2 green, drawing from -1,-1 to 1,1 |
| 02:53 | <zewt> | Philip`: for canvas you could fake it by enlarging the texture and filling in the edges yourself, I think (since the drawing vocabulary is much more limited) |
| 02:54 | <Hixie> | er |
| 02:54 | <Hixie> | consider a 2x2 green, drawing from -1,-1 to 2,2 |
| 02:54 | <Hixie> | what i was suggesting would have blurry top left and sharp bottom right |
| 02:54 | <Philip`> | Hmm, by "transformed-source-rectangle" I actually mean "transformed-original-image-data-bounds" |
| 02:55 | <Philip`> | zewt: Yeah, adding a 1-pixel transparent border and then clamp-to-edge would work (though it's a pain when under power-of-two size constraints) |
| 02:56 | <Philip`> | Hixie: Oh, okay, I think I see |
| 02:56 | <Philip`> | That sounds weird :-p |
| 02:59 | Philip` | vaguely remembers clamp-to-edge-but-clip-to-transformed-source-rectangle being discussed in some bug ages ago, but doesn't even know what bug tracker it was on |
| 02:59 | Philip` | gives up remembering and falls asleep |
| 02:59 | <zewt> | Philip`: guessing that if you don't have NPOT support in hardware, you're already either going to have to deal with it yourself or not accelerate at all |
| 03:02 | <Philip`> | zewt: Yeah, it was annoying me primarily in the context of a game where all the source data is POT; browsers will have to deal with NPOT images anyway |
| 03:03 | <zewt> | guessing at worst you'd hit slow paths more often |
| 03:04 | <zewt> | but i'd imagine that wouldn't really be a slow path--since NPOT images are the norm with canvas, not the exception |
| 03:52 | <Hixie> | hmmm |
| 03:52 | <Hixie> | i'm not sure clipping actually really works |
| 03:52 | <Hixie> | since the output has to be defined for all pixels... |
| 05:25 | <heycam> | hmm, I want to do a CSS transform rotation with the transform origin being a point on the baseline of the text in the element |
| 05:25 | <heycam> | is that possible somehow? |
| 06:21 | <yolin> | If I add a css file dynamically to the document, is there any way to know if its completed loading? |
| 06:23 | <Hixie> | onload on the <link> iirc |
| 06:50 | <yolin> | Hixie, onload doesnt fire on <link> :( |
| 06:51 | <Hixie> | file a bug with the browser, spec says it should :-) |
| 06:53 | <yolin> | okay, chrome does not fire, firefox and opera does |
| 07:25 | <hsivonen> | hah. Google suggests "DOOM 3 Validation" when searching for "DOM 3 Validation" |
| 08:00 | <MikeSmith> | http://googlecode.blogspot.com/2012/01/lets-make-tcp-faster.html is interesting |
| 08:00 | <MikeSmith> | apparently the Proportional Rate Reduction stuff is already supported in the Linux kernel |
| 08:01 | <MikeSmith> | "reduces the TCP latency of connections experiencing losses by 3-10% depending on the response size" |
| 08:03 | <MikeSmith> | so it would be nice to have defer and async support in Opera |
| 08:53 | <MikeSmith> | it seems like we have prevailing agreement for putting warnings on the ancient DOM specs, and links to latest versions |
| 08:54 | <MikeSmith> | not that it's needed anyway |
| 08:55 | <MikeSmith> | not from the WebApps WG anyway |
| 08:55 | <MikeSmith> | because those are not within the realm of the WebApps WG anyway |
| 08:55 | <MikeSmith> | they are orphans |
| 08:55 | <MikeSmith> | I think it comes down to what PLH reckons should be done |
| 09:33 | <jgraham> | I am obviously also +1 on poiting out that old stuff is old, but I have learnt to fear email threads like that |
| 09:34 | <Ms2ger> | MikeSmith, I think we established last time that WebApps owns them now |
| 09:34 | <jgraham> | There is *always* someone who says "but you can't say that maybe (some old spec) is old because we have an unspecified law that requires us to implement it" |
| 09:34 | <MikeSmith> | we who? |
| 09:34 | <Ms2ger> | WebApps :) |
| 09:34 | <MikeSmith> | heh |
| 09:37 | <MikeSmith> | plh-less discussions about changes to those docs are a tree falling in a forest |
| 09:38 | <hsivonen> | jgraham: I find it super-hard to believe that laws or regulations require consumer electronics to have any particular level of any part DOM |
| 09:39 | <jgraham> | MikeSmith: Quite devestating if you happen to live in the tree? |
| 09:39 | <MikeSmith> | that's because that assertion is BS |
| 09:39 | <MikeSmith> | time savings suggestion is we just make the plea to plh |
| 09:40 | <MikeSmith> | who likely would find it a good idea |
| 09:40 | <jgraham> | hsivonen: What is true is that some non-Web specs reference specific versions of web specs. |
| 09:40 | <MikeSmith> | for the very good reasons that have already been multiply explained in that thread |
| 09:41 | <jgraham> | This is not a positive thing and anything we can do to discourage people from doing that is good |
| 09:41 | <MikeSmith> | obviously putting warnings on those docs has no effects on whatever ancient references wherever |
| 09:41 | <jgraham> | Well, unless they decide to do the other thing that sometimes happens where they fork the spec |
| 09:42 | <jgraham> | (insert ironic comment about W3C only permitting harmful forks here) |
| 10:57 | <smaug____> | hmm, no anne |
| 10:57 | <smaug____> | Ms2ger: am I right that Function? is used currently with onfoo handlers |
| 10:58 | <Ms2ger> | Yes, with the annotation |
| 10:58 | <Ms2ger> | As in https://hg.mozilla.org/users/jst_mozilla.com/dom-bindings/rev/18484b18c12f#l1.12 |
| 11:00 | <smaug____> | Ms2ger: do you remember any cases when Function? is used without TreatNonCallableAsNull ? |
| 11:00 | <Ms2ger> | Don't think so |
| 11:00 | <smaug____> | ok, good |
| 11:00 | <Ms2ger> | And if so, they're wrong |
| 14:42 | <MikeSmith> | been 9 years since the first XForms Basic aka Web Forms 2 draft |
| 14:42 | <MikeSmith> | http://www.hixie.ch/specs/html/forms/xforms-basic-1 |
| 14:43 | <Ms2ger> | Those were the days |
| 14:43 | <MikeSmith> | oh |
| 14:43 | <MikeSmith> | off by 1 |
| 14:43 | <MikeSmith> | 8 years |
| 14:43 | <jgraham> | YEah, that sounds right |
| 14:43 | <jgraham> | WHATWG started in 2004 at least |
| 14:43 | <jgraham> | We should have a party in 2014 |
| 14:45 | <Ms2ger> | Maybe Mozilla is willing to contribute one of Microsoft's release cakes |
| 14:45 | <jgraham> | You would have thought there would be some money floating around from all the economic activity that HTML 5 generated to fund that |
| 14:45 | <jgraham> | (a party not a stale donut) |
| 14:47 | <jgraham> | Mind you if people working on the spec were able to capture a significant fraction of the value it created, Hixie would be the one with multimillion dollar tax returns |
| 14:48 | <Ms2ger> | He's waiting for a law to require HTML5 compliance, to spec that every user must pay him :) |
| 14:48 | <Ms2ger> | "The open action registry is <http://hsivonen.iki.fi/webm-share/>"; |
| 14:48 | <Ms2ger> | ArtB++ |
| 14:48 | <wilhelm> | See, living standards are dangerous. |
| 15:24 | <hsivonen> | Ms2ger: Open action registry? |
| 15:24 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-webevents/2012JanMar/0009.html |
| 15:25 | <hsivonen> | Ms2ger: :-) |
| 15:38 | <AryehGregor> | TabAtkins, maybe Values and Units should define an <angle-or-zero> type? Or redefine <angle> to be <angle-unit-required> or zero, so specs that want to allow 0 can use <angle> and specs that don't have to use <angle-unit-required>? |
| 15:38 | <AryehGregor> | (or some better name) |
| 15:39 | <AryehGregor> | It seems like it makes the most sense for Values and Units to expose an easy way to do "angle or zero", since most specs that use <angle> will want that. |
| 15:40 | <AryehGregor> | For that matter, why not define a new <length-unit-required> and redefine <length> in terms of that? That requires a parser change, but it should be compatible with content, yes? |
| 15:41 | <jgraham> | Oh, on the subject of CSS, what's the easiest way to define a radial gradient from (some colour) to transparent where the value of (some colour) is set in a script? |
| 15:42 | <AryehGregor> | Also, random remark: after I'm done with transforms/transitions/animations, I want to do CSSOM. Lack of CSSOM interop has been a thorn in my side when writing JS for close to a year now. Like: serialization. |
| 15:49 | <AryehGregor> | TabAtkins, I've noticed a few editorial bugs (typos etc.) in Values and Units. It seems there's nowhere to file bugs, so I have to send mail to www-style? |
| 16:00 | <AryehGregor> | Ugh, why does the CSSWG use conference calls for technical discussion? |
| 16:01 | AryehGregor | wants to go back to DOM-land |
| 16:18 | <Ms2ger> | AryehGregor, enjoy working with Glenn :) |
| 16:18 | <AryehGregor> | Which Glenn? |
| 16:18 | <AryehGregor> | And is he in CSS-land or DOM-land? |
| 16:18 | <Ms2ger> | Weird Glenn |
| 16:18 | <Ms2ger> | (skynav) |
| 16:18 | <AryehGregor> | I've seen him in HTML-land a bit. |
| 16:21 | <AryehGregor> | jamesr_, in my EC2 Windows Server VM, about:gpu claims hardware acceleration for everything, but CSS 3D stuff still seems not to work correctly. |
| 16:23 | <AryehGregor> | It looks like I could get a VM with a GPU if I wanted to pay $2.60/hour instead of $0.00/hour (free usage tier yay), but I don't know if Chrome would actually notice it, since I doubt it's configured for use with the actual display. |
| 16:28 | <Philip`_> | I imagine the problem would be more whether it can output via Remote Desktop, which is different to normal display output |
| 16:28 | <Philip`_> | (It's not like VNC where it effectively sends screenshots over the network) |
| 16:30 | <AryehGregor> | What does it do, then? |
| 16:43 | <Philip`_> | AryehGregor: It's apparently implemented as a display device driver, and it understands higher-level drawing commands instead of simply bitmaps |
| 16:44 | <AryehGregor> | Philip`_, so kind of like X forwarding? |
| 16:45 | <Philip`_> | (e.g. http://ericomguy.blogspot.com/2008/02/using-windows-server-2008-terminal.html - "RDP 6 is able to transmit the raw instructions from the Desktop Window Manager") |
| 16:45 | <Philip`_> | AryehGregor: Seems vaguely similar, except less terrible than X forwarding |
| 16:45 | <AryehGregor> | Yeah, I was going to say. |
| 16:48 | <Philip`_> | (It sounds (based on my very limited knowledge) like it's based on copying screenshots plus lots of optimisations for cases when it recognises higher-level API calls, rather than being based on blindly proxying low-level API calls as in X) |
| 17:42 | <remysharp> | Hey folks, got a bit of a crazy one here. |
| 17:42 | <remysharp> | This url - http://jsbin.com/uticev/2 if the popup is blocked (testing chrome here), should it be able to run the JavaScript in said popup? |
| 17:43 | <remysharp> | If you test that url in chrome (I'm on 16) and you see any body text - then it came from the popup *that was blocked*. That's not right is it? |
| 17:46 | <micheil> | wow, that is a bit of a crazy one :D |
| 17:47 | <remysharp> | If you want to hide some JavaScript in Chrome, you can do it via the popup, because it's not showing anything on the network tab either /begin evil laugh |
| 17:57 | <AryehGregor> | Ugh, someone is mailing the members-only CSS list. |
| 17:57 | AryehGregor | didn't even notice |
| 17:57 | <AryehGregor> | Is there some agreed-upon convention to use www-style if possible? |
| 17:57 | <Ms2ger> | For technical issues, yes |
| 17:57 | <Ms2ger> | Tell them to resend in that case |
| 17:58 | <Ms2ger> | Administrivia is on the MO list, though |
| 18:10 | <TabAtkins> | AryehGregor: I'd rather ben as consistent as possible and always require a unit on 0 values that aren't <length>s, then just define Transforms to accept either an <angle> or 0. |
| 18:10 | <AryehGregor> | TabAtkins, so you think transform: rotate(0) should be a parse error? |
| 18:10 | <AryehGregor> | That doesn't match any implementations AFAICT. |
| 18:10 | <TabAtkins> | ...I just said that Transforms should be defined toa ccept either. |
| 18:11 | AryehGregor | read "then" as "than" |
| 18:11 | <TabAtkins> | Ah, kk. |
| 18:11 | <AryehGregor> | Why not move that into Values and Units and require properties that don't want 0 == 0deg to opt out? |
| 18:11 | <AryehGregor> | I mean, every existing <angle> property really wants to accept unitless zero also, right? |
| 18:11 | <AryehGregor> | So why require the common case to add an extra proviso, instead of the uncommon case? |
| 18:12 | <TabAtkins> | Because then we're extending the "0 can be unitless" exception to more units, and making it harder to remember when it can and can't be unitless. |
| 18:12 | <TabAtkins> | If I coudl go back in time I'd remove the unitless-0 from <length>, too. |
| 18:12 | <AryehGregor> | So you'd want every spec that includes <length> to be updated to say "<length> or zero"? |
| 18:13 | <TabAtkins> | No, I'm travelling back in time. Every spec that uses <length> just wouldn't accept unitless 0 in the first place. |
| 18:13 | <AryehGregor> | Or "<length> or <number>, and a <number> that's not zero is a parse error", or whatever's required? |
| 18:13 | <TabAtkins> | You'd just type "margin: 0px;" |
| 18:13 | <AryehGregor> | That seems needlessly inconvenient for authors. |
| 18:13 | <AryehGregor> | It's also too late for that, and it makes sense for <angle> to behave consistently with <length>. |
| 18:13 | <TabAtkins> | I fail to see how 2 characters is inconvenient. |
| 18:14 | <TabAtkins> | I agree that it's too late for that, thus my reference to time travel. No other unit should act like this, though, because it's future-hostile. |
| 18:14 | <TabAtkins> | (As I argued in a previous discussion of this subject with you.) |
| 18:14 | <AryehGregor> | I agree that it's future-hostile to *require* that *all* specs accept unitless zero for <angle>. |
| 18:15 | <AryehGregor> | But is it future-hostile to make unitless zero for <angle> work except if a particular spec specifically prohibits it? |
| 18:15 | <AryehGregor> | Is allowing things like rotate(0) future-hostile? How so? |
| 18:15 | <TabAtkins> | It's hostile to authors to have inconsistent rules about where, precisely, you can type a unitless 0. This is why I dislike unitless 0 in <length>, but at least that's only a single place and *all* lengths accept it. |
| 18:16 | <AryehGregor> | So it's bad because it's future-hostile or author-hostile? |
| 18:16 | <TabAtkins> | I explained why it's future-hostile previously. It prevents us from producing grammars that have both an <angle> and a <length> when either can appear. Grammars like this have already appeared at least once (in the *-gradient functions), though it's since changed. |
| 18:17 | <TabAtkins> | Extending unitless 0 to more types is future-hostile. Making authors remember when they can omit the unit on <angle> and when they can't is author-hostile. |
| 18:17 | <AryehGregor> | That's not a problem if "0" parses to <zero> and "0deg" parses to <angle-with-unit> and <angle> is defined to be either <angle-with-unit> or <zero>. |
| 18:17 | <TabAtkins> | (Which is why Transforms is currently author-hostile.) |
| 18:17 | <AryehGregor> | Transforms allows authors to always omit the unit on <angle>. |
| 18:17 | <TabAtkins> | I think you're assuming that authors read the grammar, Aryeh. |
| 18:17 | <AryehGregor> | It's more author-hostile to say you can omit the unit on <length> but not <angle> -- that's much more confusing. |
| 18:17 | <AryehGregor> | No, I'm not. |
| 18:17 | <TabAtkins> | This is not a valid assumption. |
| 18:17 | <AryehGregor> | That would be silly. |
| 18:18 | <AryehGregor> | I'm assuming authors are used to using "0" for lengths and will assume it works for angles too. |
| 18:18 | <TabAtkins> | Okay, then you must be misunderstanding me, because your explanation doesn't address the problem I was pointing out. |
| 18:18 | <AryehGregor> | (Although an angle of zero is useless for anything in Transforms right now.) |
| 18:18 | <AryehGregor> | My reply to "It prevents us from producing grammars that have both an <angle> and a <length> when either can appear." is no it doesn't: you can define new <angle-with-unit> and <length-with-unit> that don't accept "0" and use those in such cases. |
| 18:19 | <TabAtkins> | If authors have to remember that in property X they can omit the unit on <angle> but in property Y they have to include the unit (because of grammar ambiguity), that's hostile. |
| 18:19 | <AryehGregor> | The large majority of the time, that's not an issue, so you can use <angle> or <length> and allow unitless zero. |
| 18:19 | <TabAtkins> | Ah, that line. |
| 18:19 | <TabAtkins> | That's also wrong. |
| 18:19 | <AryehGregor> | I would say if such a situation arises, the syntax of property X should probably be rethought anyway, because it's excessively magical. This is assuming that authors would legitimately want to use "0" for both an angle and a length. |
| 18:19 | <TabAtkins> | I offer as proof the older gradient syntaxes, where "0px" and "0deg" had different results. |
| 18:20 | <TabAtkins> | AryehGregor: Did you mean to say Property Y? Otherwise I'm confused. |
| 18:20 | <AryehGregor> | So that could be defined to accept <length> or <angle-with-unit>, but not <angle>. Or whatever. |
| 18:20 | <AryehGregor> | Maybe. |
| 18:20 | <TabAtkins> | :/ |
| 18:20 | <AryehGregor> | Could you give a more specific example of the old gradient syntax where it would be ambiguous? |
| 18:20 | <TabAtkins> | Yes, one sec. |
| 18:21 | <TabAtkins> | Argh, the first WD with gradients already removed the problem. I'd have to go CVS diving. Instead, may I simply explain the issue? |
| 18:22 | <Ms2ger> | hg++ |
| 18:22 | <AryehGregor> | My question is really: is the ambiguity theoretical, or something authors would actually hit in practice? Would authors actually *want* to specify both 0deg and 0px in the ambiguous position? |
| 18:22 | <TabAtkins> | Yes. |
| 18:22 | <TabAtkins> | So, here's the example. |
| 18:22 | <AryehGregor> | Okay. |
| 18:23 | <TabAtkins> | The first argument of radial-gradient had the grammar "<position> || <angle>". |
| 18:23 | <TabAtkins> | <position> specified the center-point of the gradient, <angle> specified the direction that lengths in the color-stops were drawn along (this is significant for ellipses). |
| 18:24 | <TabAtkins> | So, "radial-gradient(0, red, blue)" is ambiguous. |
| 18:24 | <TabAtkins> | (Because the default for <position> was "center".) |
| 18:25 | <AryehGregor> | Because "0" really means "top left" here? |
| 18:25 | <AryehGregor> | Then I'd prohibit unitless zero altogether in this case, since it's not obvious what it does. |
| 18:25 | <AryehGregor> | I don't expect authors to realize that unitless zero works for <length> but not <angle>. I think that's what's author-hostile. |
| 18:26 | <AryehGregor> | Especially since <angle> is so rare and <length> is so common. |
| 18:26 | <AryehGregor> | Authors will extrapolate from what they know to what they don't. |
| 18:26 | <AryehGregor> | I.e., that units can be omitted for 0. |
| 18:26 | <TabAtkins> | Okay, so you prohibit unitless 0 for angle there. What about "radial-gradient(left top 0, red, blue)"? |
| 18:26 | <AryehGregor> | Also, it would be poor form in this case to specify "0" to mean "top left" or "top center" or whatever it means -- it's confusing unless you know what the default is. |
| 18:27 | <AryehGregor> | You should just say "top center" or something, much clearer. |
| 18:27 | <AryehGregor> | What does "left top 0" even mean? |
| 18:27 | <AryehGregor> | As a <position>, I mean. |
| 18:27 | <TabAtkins> | Actually, that's still ambiguous. "0 left top" isn't. It means "measure the gradient-line along 0deg, and center the gradient at left top". |
| 18:28 | <AryehGregor> | Oh, wait, "<position> || <angle>". I read that as "<position> | <angle>". |
| 18:28 | AryehGregor | is still getting used to CSS |
| 18:29 | AryehGregor | feels DOM stuff is saner, but maybe he's just used to it |
| 18:29 | AryehGregor | tries again |
| 18:29 | <Ms2ger> | Well, DOM stuff is specified nowadays |
| 18:29 | <TabAtkins> | Ms2ger: The stuff we're talking about is specified precisely. |
| 18:29 | <AryehGregor> | I'd make it "<position-with-unit> || <angle-with-unit>", so units are just required for everything. Where <position-with-unit> doesn't allow a unitless zero in any coordinate. |
| 18:30 | <AryehGregor> | Anything else is confusing. |
| 18:30 | <Ms2ger> | TabAtkins, can we clone you and fantasai already? |
| 18:30 | <AryehGregor> | Alternatively, I'd rewrite the syntax entirely. |
| 18:30 | <TabAtkins> | AryehGregor: Oh, so now writing "0 50%" isn't allowed? That's a perfectly valid background-position. |
| 18:30 | <AryehGregor> | Which is in fact what happened. |
| 18:30 | <TabAtkins> | Ms2ger: You come up with the process, I'll provide the genetic material. |
| 18:30 | <AryehGregor> | TabAtkins, right, but now you're mixing in <angle>s, so you just made it confusing, which it's not for background-position. |
| 18:31 | <AryehGregor> | I think this kind of syntactic construct should just be avoided to start with. |
| 18:31 | <TabAtkins> | AryehGregor: My point is that your *restriction* is confusing as well, since it's disallowing forms that are valid in other locations. |
| 18:31 | <AryehGregor> | I think the whole syntax is confusing no matter what. |
| 18:31 | <TabAtkins> | AryehGregor: It's a "now you have two problems" situation. |
| 18:31 | <TabAtkins> | You can avoid the whole mess by simply *not allowing unitless 0 in <angle>s*. |
| 18:31 | <AryehGregor> | I think any syntax where you can have both <length> and <angle> and 0px is different from 0deg is inherently confusing and should be avoided anyway. |
| 18:32 | <TabAtkins> | AryehGregor: Ah, you misunderstood the example. |
| 18:32 | <AryehGregor> | No, because then authors are going to have no idea what "0" means in that context. |
| 18:32 | <AryehGregor> | So you haven't avoided the problem. |
| 18:32 | <AryehGregor> | It's still author-hostile. |
| 18:32 | <AryehGregor> | Authors are not going to realize units are always optional in <length> but not in <angle>. |
| 18:32 | <TabAtkins> | 0px and 0deg are actually identical there. *However*, the *default*s are not 0, so it matters which one you parse as, since you fill in the missing one with a default value. |
| 18:33 | <AryehGregor> | Okay, let me put it this way: if I'm completely confused when you personally try to explain it to me, then I think that's pretty darned good proof that the average author would find it confusing when they copy-paste from w3schools. |
| 18:33 | <TabAtkins> | Yes, the fact that unitless stuff is restricted to <length> confuses authors. That's why allowing unitless 0 in <length> was a mistake in the first place. Your suggestion won't reduce the confusion, it will just shift it around. |
| 18:33 | <TabAtkins> | And, I argue, increase it. |
| 18:33 | <TabAtkins> | AryehGregor: You're confused because I was giving invalid examples. ^_^ |
| 18:34 | <AryehGregor> | Um, thanks? :) |
| 18:34 | <AryehGregor> | I would not read "0 left top" as being the same as "0deg left top". |
| 18:34 | <AryehGregor> | . . . Which I guess is your point, okay. |
| 18:34 | <TabAtkins> | Yay! |
| 18:35 | <AryehGregor> | But I wouldn't read "0 20deg" as "0px 20deg" either. |
| 18:35 | <AryehGregor> | Hmm. Maybe. |
| 18:35 | <TabAtkins> | Sure, that's still bad. But that's a badness we're forced to live with. |
| 18:35 | <AryehGregor> | But I wouldn't count on it. |
| 18:35 | <TabAtkins> | Or else we make CSS grammar more inconsistent. |
| 18:35 | <AryehGregor> | No, because you could either a) ban unitless zero entirely from that function, or b) redesign the function so it's less confusing. |
| 18:35 | <AryehGregor> | Allowing unitless zero for <length> but not <angle> is already inconsistent. |
| 18:36 | <AryehGregor> | Especially since in practice it *is* allowed for <angle>, in every single place in CSS that actually accepts <angle> in practice, or almost. |
| 18:36 | <AryehGregor> | The fact that the grammar doesn't say that does not make it less true. |
| 18:36 | <AryehGregor> | And we can't go back and change that either. |
| 18:37 | <hober> | AryehGregor: indeed. |
| 18:37 | <TabAtkins> | I know. |
| 18:38 | <TabAtkins> | I'm willing to accept slightly inconsistent badness in legacy APIs if I get consistency in the future, rather than accept consistent badness for all time. |
| 18:38 | <TabAtkins> | Within limits, of course. |
| 18:38 | <TabAtkins> | At some point "legacy APIs" becomes "the majority of the platform", and it's not worth being inconsistent with it. |
| 18:39 | <AryehGregor> | So you think all future <angle> should not allow unitless zero even if it would be unambiguous in practice? |
| 18:39 | <TabAtkins> | Yes. |
| 18:39 | <AryehGregor> | (in that case) |
| 18:39 | <AryehGregor> | Even though all existing <angle> does allow unitless zero? |
| 18:39 | <AryehGregor> | Just like <length>? |
| 18:39 | <TabAtkins> | Not quite true - aural CSS didn't allow unitless <angle>. ^_^ |
| 18:39 | <TabAtkins> | And current Speech module doesn't either. |
| 18:40 | <AryehGregor> | Basically nobody supported aural CSS, and any authors that used it got it wrong. |
| 18:40 | <AryehGregor> | Speech is what? |
| 18:40 | <TabAtkins> | Nobody used it in the first place. |
| 18:40 | <TabAtkins> | Speech is a reworking of the original concepts behind Aural. |
| 18:42 | <TabAtkins> | When I write conical gradients into Images 4, they'll require an <angle> too. |
| 18:42 | <AryehGregor> | Will implementers actually prohibit the unitless zero? Because they didn't for transforms. |
| 18:42 | <AryehGregor> | I suspect the implementers didn't even realize that <angle> doesn't allow unitless zero. |
| 18:42 | <TabAtkins> | Yes, that was the problem. |
| 18:43 | <TabAtkins> | Most implementors are *not* authors. |
| 18:43 | <AryehGregor> | Maybe if *implementers* assume unitless zero works for <angle>, a typical author stands no chance of getting it right in your scheme? |
| 18:43 | <AryehGregor> | They know way more than authors. |
| 18:43 | <AryehGregor> | Some of them actually read specs. |
| 18:43 | <TabAtkins> | I wouldn't take that as a given. ^_^ |
| 18:43 | <TabAtkins> | An author has to get it wrong once and then they learn it for life. |
| 18:44 | <TabAtkins> | Your proposal (allow it wherever it would be unambiguous) means they have to relearn it for every property that accepts <angle>. |
| 18:44 | <TabAtkins> | And, presumably, <time>/etc too. |
| 18:45 | <AryehGregor> | Okay, whatever. |
| 18:45 | <AryehGregor> | It's up to implementers. |
| 19:03 | <TabAtkins> | AryehGregor: To address your other issues: Shane (from Google) and Greg (from... somewhere not a browser?) are working on fixing CSSOM. You're welcome to join when you have the time. |
| 19:04 | <TabAtkins> | Report V&U bugs on the mailing list, yes. |
| 19:04 | <TabAtkins> | Or, personally to me. |
| 19:04 | <TabAtkins> | That works too. |
| 19:04 | <AryehGregor> | TabAtkins, they're actively editing it? Last I saw, the editor was listed as annevk, who disclaims all responsibility. |
| 19:05 | <TabAtkins> | Yes. They ahven't published a new draft yet, but they're actively working on it. |
| 19:06 | <AryehGregor> | They don't publish their work as they work on it? |
| 19:06 | <TabAtkins> | They haven't done so yet? I dunno what they're doing yet. |
| 19:06 | <TabAtkins> | I think Greg is doing a rework at the moment, and then they'll settle into incremental edits. |
| 19:07 | <Ms2ger> | TabAtkins, itym Glenn, from Samsung |
| 19:08 | <TabAtkins> | Ms2ger: Yes, thank you. |
| 19:09 | <rjett1> | Has anyone thought about bringing the webkit-filters to canvas? |
| 19:11 | <TabAtkins> | rjett1: I'm sure it's been thought of. ^_^ But Hixie is mostly holding off on canvas updates until he does a big update. |
| 19:11 | <rjett1> | where would discussion about that api occur? |
| 19:12 | <TabAtkins> | whatwg⊙wo is appropriate. |
| 19:13 | <rjett1> | cool, thanks. |
| 19:28 | <AryehGregor> | Oh, wow, Firebug inserts stuff into the DOM. That's really confusing. |
| 19:35 | <Hixie> | Philip`_: so i don't think clipping is gonna work |
| 19:35 | <Hixie> | Philip`_: since i don't really understand how to spec it :-) |
| 19:37 | <AryehGregor> | Ugh. I really can't spec or test transforms without access to a WebKit implementation that actually supports CSS 3D transforms correctly. |
| 19:37 | <TabAtkins> | You can't spec transforms without an implementation of transforms? |
| 19:37 | <TabAtkins> | I can understand testing, if you want tests that don't just all fail. |
| 19:38 | <AryehGregor> | But my primary computer runs nouveau, my laptop runs the Intel mesa driver, my wife's laptop has an old video card with no up-to-date driver available, my VM has no graphics card at all, and WebKit refuses to do 3D CSS properly for any of them . . . |
| 19:38 | <AryehGregor> | TabAtkins, I don't write specs without tests. They're doomed to be incorrect. |
| 19:38 | <AryehGregor> | At least, for already-implemented features. |
| 19:38 | <AryehGregor> | Well, even for not-already-implemented. |
| 19:39 | <AryehGregor> | I can't in good conscience suggest a definition for perspective-origin when I only know what Gecko does. |
| 19:39 | <AryehGregor> | (Which I think is wrong anyway.) |
| 19:39 | <TabAtkins> | Well, if you can test non-already-implemented features, you can test badly-implemented features. |
| 19:39 | <AryehGregor> | WebKit seems to just ignore the perspective property on my machines. |
| 19:39 | <AryehGregor> | I take it it doesn't on other people's. |
| 19:40 | <AryehGregor> | And I can't easily get IE10 either, since it's Win8 only. |
| 19:41 | <TabAtkins> | Gimme a test and I can see if it fails on my machine. |
| 19:41 | <AryehGregor> | I have to iterate stuff a lot. |
| 19:41 | <AryehGregor> | Not gonna work well by proxy. |
| 19:41 | <TabAtkins> | kk |
| 19:41 | <AryehGregor> | MikeSmith already kindly confirmed that perspective does actually work on his Mac. |
| 19:41 | <AryehGregor> | E.g., this example doesn't work on any of my machines: http://www.webkit.org/blog-files/3d-transforms/perspective-by-example.html |
| 19:41 | <TabAtkins> | I know what you mean - I had to iterate a lot to figure out a sane behavior for list bullet positioning. |
| 19:41 | <AryehGregor> | In Chrome or Safari, where applicable. |
| 19:42 | <TabAtkins> | Oh yeah, anything that requires hardware breaks the tab on my linux box. |
| 19:42 | <AryehGregor> | This doesn't require GPU support in Gecko. |
| 19:43 | <AryehGregor> | And 3D stuff works partially in Chrome for me. |
| 19:43 | <AryehGregor> | But perspective is wrong. |
| 19:43 | <AryehGregor> | -webkit-transform: perspective() does something, unlike -webkit-perspective, but it's wrong. |
| 19:43 | <TabAtkins> | No effect for me on Aurora/Linux. |
| 19:43 | <TabAtkins> | Oh, duh, this is -webkit I think. |
| 19:43 | <AryehGregor> | That example is WebKit-only, so yeah. :) |
| 19:44 | <Philip`_> | AryehGregor: Do browsers support the software Mesa driver? (Run with env var LIBGL_ALWAYS_SOFTWARE=1, I think) |
| 19:45 | <AryehGregor> | TabAtkins, Gecko example: data:text/html,<!DOCTYPE html><div style="width:200px;-moz-perspective:200px;font-size:2em;margin-left:100px;text-align:center"><div style="-moz-transform:rotateX(45deg);-moz-transform-origin:top">The quick brown fox jumps over the lazy dog |
| 19:47 | <AryehGregor> | Star Wars-style. |
| 19:47 | <TabAtkins> | Yup, it works. (Or at least has an effect.) |
| 19:48 | <Philip`_> | Hixie: drawImage already has to effectively clip the output to the source rectangle (post transformation), so I think it would probably just have to effectively clip to the intersection of the source rectangle and original image size |
| 19:49 | <Hixie> | Philip`_: isn't drawimage affected by the composition operator? |
| 19:50 | <Philip`_> | I guess when I say "clip" I mean some (as far as I remember) currently-handwaved-over clipping that occurs when drawImage draws onto the infinite transparent bitmap that subsequently gets composited |
| 19:52 | <Philip`_> | (as opposed to what clip() does) |
| 20:10 | <Hixie> | Philip`_: i don't understand what clipping you mean then |
| 20:19 | <AryehGregor> | TabAtkins, getComputedStyle() returns resolved value, not used value. Where "resolved value" is something that CSSOM makes up that's almost computed value but not quite. |
| 20:40 | <TabAtkins> | AryehGregor: I know. "resolved value" happens to be the used value for 'width'. |
| 20:40 | <AryehGregor> | Okay. |
| 20:40 | <TabAtkins> | My statement was specific. |
| 20:46 | <TabAtkins> | AryehGregor: Have you gotten clearance on joining the CSSWG yet? |
| 20:46 | <AryehGregor> | TabAtkins, um, I've been a member for a few weeks, I think? |
| 20:47 | <AryehGregor> | http://www.w3.org/Style/CSS/members.en.php3 |
| 20:47 | <TabAtkins> | Argh, duh, yes. |
| 20:47 | <TabAtkins> | What I meant to ask was about taking on editorship of Transforms. |
| 20:47 | <AryehGregor> | Oh. |
| 20:47 | <AryehGregor> | From Mozilla? Yeah, seems so. |
| 20:47 | <AryehGregor> | Feel free to say I volunteer. |
| 20:47 | <TabAtkins> | kk, mind poking the agenda thread around it? |
| 20:48 | <AryehGregor> | Am I supposed to attend? |
| 20:48 | <TabAtkins> | I guess that's not strictly necessary. |
| 20:49 | <AryehGregor> | Also, I think the FX TF (or something?) concluded that someone from Adobe is supposed to take over editing of those specs. |
| 20:49 | <AryehGregor> | In some conference call *they* had. |
| 20:50 | <AryehGregor> | http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0046.html |
| 20:50 | <AryehGregor> | "RESOLUTION: Dirk becomes an editor of the SVG+CSS Transforms specification" |
| 20:50 | <AryehGregor> | "RESOLUTION: Vincent also is an editor of the SVG+CSS Transforms specification" |
| 20:50 | <TabAtkins> | That shouldn't stop you. |
| 20:51 | <Hixie> | heh, in this e-mail someone talks about "every time a new html element is discovered", like we're explorers who keep finding new elements rather than designers inventing them |
| 20:51 | <Hixie> | i like it |
| 20:51 | <divya> | hixieum |
| 20:51 | <TabAtkins> | I don't know about you, but that's how we discovered <shadow>. |
| 20:51 | <Hixie> | now i want to read about our adventures discovering new elements |
| 20:51 | <Hixie> | TabAtkins: heh |
| 20:51 | <TabAtkins> | It was right behind us the whole time! |
| 20:51 | <Hixie> | lol |
| 20:52 | <Hixie> | shouldn't face the sun the whole time! :-P |
| 20:52 | <TabAtkins> | How else will I stare into it? |
| 20:52 | <Hixie> | mirror |
| 20:52 | <Hixie> | mirrors make the sun safe, don't you know |
| 20:53 | <Philip`_> | If you had a large enough parabolic mirror, could you burn the sun by focusing it back at itself? |
| 20:53 | <Hixie> | If you had a large enough parabolic mirror, it would push you away |
| 20:54 | <Philip`_> | Balance it at the point where the solar wind exactly matches the sun's gravity |
| 20:54 | <AryehGregor> | TabAtkins, I posted something or other. |
| 20:55 | <AryehGregor> | Hmm . . . [].forEach(Function.prototype.apply.bind(foo, null)), or [].forEach(function(arr) { foo(arr[0], arr[1], arr[2]) })? Which is clearer? :) |
| 20:55 | <AryehGregor> | (replace "[]" by some actual array) |
| 20:55 | <Hixie> | Philip`_: i actually was thinking more about photon momentum transfer, but yeah, the solar wind would be even more of an effect |
| 20:55 | <Philip`_> | The latter |
| 20:55 | <TabAtkins> | The former, but omit the null. |
| 20:56 | <AryehGregor> | TabAtkins, then it breaks, because the array element gets passed as the first argument of apply, which wants a "this" argument for the function call. |
| 20:56 | Philip`_ | can never even remember which of .apply and .call wants an array |
| 20:57 | <TabAtkins> | AryehGregor: Oh wait, you're mapping apply. The second, then. |
| 20:57 | <TabAtkins> | Mapping apply is always confusing. |
| 20:58 | TabAtkins | prefers [].forEach(foo.aritize(3).unpack()). |
| 20:59 | Philip`_ | prefers code that uses well-known primitives like closures and function calls, rather than code that requires him to learn more APIs |
| 20:59 | <TabAtkins> | Philip`_: Luckily, Lisp has APPLY and FUNCALL, which have the same semantics as JS's apply and call. |
| 20:59 | <TabAtkins> | So that's how I remember. |
| 21:00 | <Philip`_> | Unfortunately nobody else knows Lisp |
| 21:00 | <TabAtkins> | Well, except for Eich. |
| 21:00 | <AryehGregor> | Does "aritize" exist? |
| 21:01 | <TabAtkins> | AryehGregor: No, it's part of functional.js |
| 21:01 | <TabAtkins> | Which is now part of my bible. |
| 21:02 | <TabAtkins> | unpack() isn't part of functional.js, but rather part of my own extensions based on my lisp library. ^_^ It makes a function take a list when it expects separate argumetns. |
| 21:02 | <jgraham> | Now I want to know if the point where the sun's gravity balances the solar wind + photom momenum transfer is stable. I suppose it is since presumably both fall off as 1/r^2 |
| 21:03 | <jgraham> | TabAtkins: That sounds like apply... |
| 21:03 | <TabAtkins> | jgraham: It's basically a curried apply, yes. |
| 21:04 | <TabAtkins> | Using apply/call in anything but the most literal, straightforward way confuses me every time, though. Creating idioms around their use is helpful. |
| 21:04 | <Philip`_> | jgraham: You could be a boring theoretical physicist and do the maths, or a fun experimental physicist and send a giant mirror out there to test it |
| 21:04 | jgraham | thinks that Philip`_ has a point and that adding too much of this stuff makes the code impossible for anyone else to follow |
| 21:05 | <TabAtkins> | Function.prototype.unpack = function() { var fn = this; return function(arg) { return fn.apply(this,arg); }; } |
| 21:05 | <jgraham> | Philip`_: Well if I did the maths I would probably neglegt some important effect so I think testing is the only way forward :) |
| 21:06 | <TabAtkins> | Some things are easy. For example, I recently had trouble reducing Math.max over a list. (Ignore the fact that I could just do Math.max.apply().) |
| 21:06 | <AryehGregor> | Does anyone have the latest IE10 handy? |
| 21:06 | <TabAtkins> | Instead, reducing Math.max.aritize(2) fixed it, and is easier to read, imo, than duplicating a two-arg Math.max as a function. |
| 21:07 | <jgraham> | TabAtkins: Ignore the fact that there is an easy solution? |
| 21:07 | <TabAtkins> | jgraham: I'd forgotten that Math.max() is n-ary. ^_^ |
| 21:07 | <jgraham> | I don't deny these things are elegant and lots of fun to program |
| 21:08 | <jgraham> | But I'm not sure they make things easy on the person that ends up maintaining the code |
| 21:08 | <TabAtkins> | That's always the issue, sure. |
| 21:09 | <TabAtkins> | AryehGregor: Why not, in your first option, do [].forEach(foo.apply.bind(foo))? |
| 21:10 | <TabAtkins> | Or rather, .bind(null) |
| 21:11 | <AryehGregor> | foo.apply.bind(foo) is the same as foo.apply, for any foo. |
| 21:11 | <AryehGregor> | foo.apply.bind(null) is a function that calls foo.apply with null as the thisArg instead of foo, which throws. |
| 21:11 | <AryehGregor> | foo.apply.bind(foo, null) has the desired effect. |
| 21:11 | <AryehGregor> | Which is the same as Function.prototype.apply.bind(foo, null). |
| 21:12 | <AryehGregor> | Since foo.apply === Function.prototype.apply and the only difference is the value of "this" when you call it, which bind() takes care of anyway. |
| 21:12 | <TabAtkins> | Argh, yeah, you're right. |
| 21:12 | <AryehGregor> | Or something like that. |
| 21:12 | <TabAtkins> | I *hate* the 'this' variable. |
| 21:12 | <AryehGregor> | In all honesty, I tried a bunch of different things until it worked. |
| 21:12 | <TabAtkins> | Having an invisible first argument to every function is so confusing when you start doing metaprogramming. |
| 21:13 | <AryehGregor> | So no one has the latest IE10 handy? Or at least some IE10 that supports 3D transforms. |
| 21:13 | <AryehGregor> | (i.e., one of the ones that only runs on Windows 8) |
| 21:32 | <hober> | AryehGregor: to clarify from the fx call, dirk & vincent got *added* as editors. the other editors are still editors. |
| 21:33 | <hober> | AryehGregor: (in the above it sounds like you think the existing editors got replaced by them, which is not the case) |
| 22:13 | <webben> | http://www.whatwg.org/specs/web-apps/current-work/multipage/ looks broken |
| 22:21 | <Hixie> | i need to add some code to make sure this doesn't happen again |
| 22:21 | <Hixie> | sigh |
| 22:22 | <Hixie> | looks like anne's thing is sometimes not generating a full zip |
| 22:22 | <Hixie> | or something |
| 22:23 | <pablof> | is the interface for HTMLCollection defined anywhere? |
| 22:24 | <pablof> | can't seem to find it in the spec |
| 22:27 | <pablof> | ah DOMCore, read fail, sorry |