| 01:23 | <boblet_> | hixie: how’s my timing today? ^_^ |
| 01:24 | <Hixie_> | good :-) |
| 01:24 | <Hixie_> | sorry, been out for a few days |
| 01:24 | <Hixie_> | reffing FIRST's silicon valley regional, amongst other things :-) |
| 01:24 | <boblet_> | heh, no worries |
| 01:25 | <boblet_> | so I’m writing about s/del/ins, and having trouble with the difference between s and del |
| 01:26 | <boblet_> | I was wondering if you had some other s use cases apart from expired prices for e.g. sales, event early bird prices etc |
| 01:28 | <boblet_> | aah, robot wars. I went to world robot soccer competition in Osaka a few years back. very cool |
| 01:31 | <Hixie_> | one sec, let me see |
| 01:32 | <boblet_> | Hixie: np, when you have a moment. It seems to me that s is a special case/subset of del. do you see it that way too? |
| 01:32 | <Hixie_> | boblet_: they're subtly different, but they are different |
| 01:32 | <Hixie_> | boblet_: so <del> is specifically for cases where the page was edited |
| 01:33 | <Hixie_> | boblet_: e.g. you write some minutes of a meeting, and then the minutes get corrected later. |
| 01:33 | <Hixie_> | boblet_: or you have some laws, and you change them at some point |
| 01:33 | <boblet_> | ok |
| 01:33 | <Hixie_> | boblet_: or you're writing a book, and you have edits to make that the editor needs to see |
| 01:33 | <Hixie_> | or whatever |
| 01:34 | <Hixie_> | not necessarily every edit needs to be marked up, just the ones where you want to explicitly say, this was edited, here's what it was, here's what it is now (del and ins respectively) |
| 01:34 | <Hixie_> | boblet_: <s> on the other hand is for when the document is written with old information and new information basically at the same time |
| 01:34 | <Hixie_> | boblet_: so the example in the spec is of a price change, you might include the old price and tnhe new price in promotional material, e.g. |
| 01:35 | <boblet_> | Hixie_: but that describes deletion with insertion, no? :p |
| 01:35 | <Hixie_> | say you have a product you want to sell for less |
| 01:35 | <Hixie_> | and you're making an advert for it |
| 01:35 | <Hixie_> | that advert might say both the old price and the new price, but you're writing it because of the new price |
| 01:36 | <Hixie_> | so it's not like you edited the document to remove the old price |
| 01:36 | <Hixie_> | you wrote the document with both prices right away |
| 01:36 | <Hixie_> | it's just the old price is irrelevant |
| 01:36 | <Hixie_> | or no longer accurate |
| 01:36 | <boblet_> | Hixie_: ok. I get the price example, but do you have some other use cases? |
| 01:36 | <Hixie_> | to put it another way, with <del> there is usually a view of the document that doesn't include the <del> text |
| 01:37 | <Hixie_> | but with <s> there is no version of the document without the <s> text, because the <s> text is part of the document still |
| 01:37 | <Hixie_> | it's just that it's marked as old |
| 01:37 | <boblet_> | gotcha |
| 01:37 | <Hixie_> | sorry, got distracted here |
| 01:38 | <Hixie_> | other examples: |
| 01:39 | <Hixie_> | changed opening hours, basically any time a business thing changes |
| 01:40 | <boblet_> | Hixie_: okay. That helps. now, styling… |
| 01:40 | <boblet_> | Hixie_: s and del default styling is the same, so I wonder how they’d be used together. I’d personally use strikethrough for both, but fade del and make s smaller than e.g. actual price. |
| 01:40 | <Hixie_> | examples outside of advertising materials are harder to think of off the top of my head :-) |
| 01:40 | <wilhelm_> | "Ding, dong, the <s>witch</s> former prime minister is dead." |
| 01:40 | <boblet_> | I guess that there’s no plan to change default styles right? |
| 01:41 | <Hixie_> | wilhelm_: yeah, sarcastic commentary like that might be plausible or arguable, maybe :-) |
| 01:41 | <Hixie_> | boblet_: well, changing the default styles is basically a non starter |
| 01:41 | <Hixie_> | boblet_: i wouldn't expect them to ever really be used together, but i suppose one could imagine an advert being edited in its development... |
| 01:41 | <boblet_> | wilhelm_: that’s the <s(arcasm)> usage right? |
| 01:42 | <boblet_> | Hixie_: hmm, good point |
| 01:42 | <Hixie_> | as in: <del title="it was never this cheap, are you kidding"><s>$2.99</s></del><ins><s>$5.99</s></ins> |
| 01:44 | <Hixie_> | personally i style <ins> and <del> with background colours |
| 01:44 | <Hixie_> | typically |
| 01:44 | <boblet_> | strikethrough does make things harder to read |
| 01:47 | <boblet_> | Hixie_: thanks for the feedback. I might finally be able to publish this article now (!) |
| 01:48 | <Hixie_> | heh |
| 01:50 | <wilhelm_> | boblet_: Yes. Which is not covered by the spec. (c: |
| 01:52 | <boblet_> | wilhelm_: :| ;) |
| 01:54 | <wilhelm_> | Apparently this is a real thing in philosophy: http://en.wikipedia.org/wiki/Sous_rature |
| 01:56 | <wilhelm_> | It's also covered by the Hacker Jargon File: http://www.catb.org/jargon/html/writing-style.html |
| 01:57 | <boblet_> | wilhelm_: ooh, nice. thanks for the links |
| 02:10 | <wilhelm_> | Hixie_: I'd argue both of those uses are legitimate. (Although it pains me to agree with the post-structuralists on anything. :) |
| 02:11 | <Hixie_> | well the spec just says something about irrelevant text |
| 02:11 | <Hixie_> | but i wouldn't argue against a bug that suggested it be extended in this way, if someone felt compelled enough to file ti |
| 02:13 | wilhelm_ | nods. |
| 02:50 | <jwalden> | wilhelm_: I might be misreading, but sous rature appears to be something different; the latter is cross out but replace, the former is cross out but don't replace |
| 02:51 | jwalden | tries to think of some way to demonstrate the former |
| 02:53 | <jwalden> | http://nearemmaus.com/2010/12/11/interpreting-derrida-sous-rature/ kind of makes the difference clearer, maybe |
| 02:53 | <wilhelm_> | jwalden: Yes, you're reading it correctly. (c: |
| 08:55 | <annevk> | Wow, Amazon is awesome. So I ordered something and delivery failed as I was not at home. I could probably have picked it up at some center but that's miles outside central London. But didn't. So I get an email they got it back and will refund it. |
| 09:02 | <mpt> | annevk, I've been to that center. It was quite a walk. |
| 09:04 | <annevk> | heh |
| 09:07 | <darobin> | yeah, thanks to that policy there are a few cases in which I got the same item twice from them |
| 09:42 | <sangwhan> | They also have same day delivery in certain regions. Order in the morning, get it in the afternoon. |
| 09:47 | <darobin> | another group to move to the common repo: http://www.w3.org/mid/1365500405.3186.22.camel@cumulustier |
| 09:51 | <Ms2ger> | DAP? Do they do web platform stuff? |
| 09:52 | <darobin> | Ms2ger: exclusively |
| 09:52 | <annevk> | So in retrospect events should have been a language primitive I think. |
| 09:53 | <zcorpan> | Hixie_: the discussion about <s> makes it sound like it's not actually irrelevant at all |
| 09:54 | <zcorpan> | Hixie_: the old price in an ad is relevant |
| 09:55 | <annevk> | The distinction between <del> and <s> seems too fine for HTML. |
| 09:56 | <odinho> | Yeah. It's freeform wild west. |
| 09:56 | <annevk> | mpt wrote about this at the start of the WHATWG I think. We should just have <i>, <b>, <s>, <indent> (rather than <blockquote>), ... Then relative semantics can be inferred from these snippets. |
| 09:56 | <odinho> | Should take inspiration from the default rendering. It will probably be used for whatever it looks like default. |
| 09:57 | <odinho> | Because that's how people work. |
| 09:58 | <Ms2ger> | Yay, semantics |
| 09:58 | <mpt> | annevk, I have no problem with <blockquote>, because it has an obvious default rendering, and people don't (often) misuse it to achieve that rendering for other purposes. |
| 10:00 | <mpt> | annevk, the most interesting thing to me about <del> is that its semantics often cross element boundaries. <p>Blah. <del>Blah.</p> <p>Furthermore, blah.</del> So blah.</p> |
| 10:01 | <jgraham> | We obviously need a way to serialize DOM ranges. Then we could add annotations like <del> as a metadata layer on top of the main document. In RDF. |
| 10:01 | <mpt> | There are two other elements like that: <ins> and <mark>. |
| 10:02 | <annevk> | I remember someone once suggesting the need for ranges to mark up the Bible |
| 10:02 | <jgraham> | annevk: I remember having that conversation on the Paris metro |
| 10:03 | <jgraham> | Although I can't promise it's not a false memory. |
| 10:03 | <annevk> | I guess it keeps coming up and then everyone's like *shrug* and moves on to fix more important bugs. |
| 10:04 | <annevk> | Turns out there's a lot more interesting things to fix than semantic markup. You know, like legacy encodings :-) |
| 10:06 | <jgraham> | Not sure that legacy encodings could turn a geek meetup into a bar-room brawl in quite the same way |
| 10:06 | <darobin> | jgraham: try that out at a Unicode meeting |
| 10:07 | <darobin> | ooh, representing ranges and overlaps |
| 10:07 | <jgraham> | What, just walk in and say "iso-8859-1 should be redefined as windows-1252" and wait for it all to kick off? |
| 10:07 | <annevk> | "That's no glyph you retard!" "You're such a code point." |
| 10:07 | <jgraham> | Could be fun |
| 10:07 | <darobin> | maybe we should just adopt LMNL, or why not TEI! |
| 10:08 | <darobin> | jgraham: oh yeah, that'd be a roar |
| 10:08 | <darobin> | I'd buy a beer and watch it unfold |
| 10:08 | <darobin> | "we don't normally talk about special characters, but I'll make an exception for you" |
| 10:09 | <annevk> | Haha, that reminds me how the IETF would get back to Ian and I on the subject of URLs. Almost four months of waiting now on a message that'd go out "today". |
| 10:11 | <darobin> | annevk: you have to wait for it to be uploaded to the FTP server |
| 10:12 | <annevk> | Must have expired. |
| 10:13 | <annevk> | I'll ping them again. Kinda curious still. |
| 10:16 | <annevk> | It's actually about five months now that we've been waiting on something. I already pinged them once after a month and a bit. |
| 10:42 | <odinho> | https://github.com/w3c/web-platform-tests/pull/62#issuecomment-16105705 |
| 10:43 | <odinho> | (Mosquito ServerSentEvents tests, subset of Opera tests -- they need more work, so we're discussing not accepting them.) |
| 10:47 | <Ms2ger> | sgtm |
| 11:12 | <SimonSapin> | so, what’s a workshop? https://www.w3.org/2013/06/ebooks/ |
| 11:20 | <jgraham> | It's a room with a circular saw. The W3C likes to use them for meetings because the sight of the rapidly spinning blade creates sudden clarity that wasting everyone's time too much might not be a good life choice. |
| 11:22 | <Ms2ger> | Every time you waste time, you have to take a step towards the blade? |
| 11:22 | <Ms2ger> | That could be an interesting reality show |
| 11:25 | <SimonSapin> | so meta |
| 11:25 | <SimonSapin> | does wasting time by watching the show counts? |
| 11:26 | <svl> | What happens when the blade gets jammed by the press of too many bodies? |
| 11:29 | <annevk> | I reckon it'd be an "What if?"-style blade that does not have such problems. |
| 11:29 | <annevk> | s/an/a/ |
| 11:30 | <SimonSapin> | annevk: https://code.google.com/p/google-url/ says it has "more complex rules for Windows file URLs", should that kind of thing be in the URL standard? |
| 11:33 | <annevk> | URL Standard has complex rules for file URLs. I hope that we can simply always do the weird drive-letter stuff from Windows and not have that as a per-platform oddity. |
| 11:59 | <SimonSapin> | Mozilla is having me travel a lot before I even start :) I’ll wait a bit to bring this one up |
| 12:01 | <jgraham> | SimonSapin: So where are you actually located? If you aren't travelling so much that you've forgotten. |
| 12:02 | <SimonSapin> | Lyon, for now |
| 12:02 | <SimonSapin> | London starting June |
| 12:03 | <jgraham> | Ah, that was convenient for TPAC then |
| 12:03 | <SimonSapin> | yes, very |
| 12:04 | <SimonSapin> | I went to TPAC on a bicycle |
| 12:04 | <odinho> | Me too, after flying and taking a train :D |
| 12:50 | <darobin> | is there a reason why dictionaries and callbacks aren't distinguishable as per WebIDL? |
| 12:51 | <darobin> | it just seems daft |
| 12:52 | <Ms2ger> | Because they're both plain objects? |
| 12:53 | <darobin> | are they? |
| 12:53 | <Ms2ger> | Pretty much |
| 12:53 | <darobin> | if I can distinguish them with typeof I don't see why WebIDL would be too braindead to do the same |
| 12:53 | <Ms2ger> | Sure, sure |
| 12:53 | <Ms2ger> | File a bug |
| 13:31 | <annevk> | darobin: when do you combine them though? |
| 13:32 | <darobin> | annevk: well, never since of course you wouldn't use callbacks, you'd use futures |
| 13:33 | <darobin> | I was simply made aware of a problem in the JSON-LD API where they wanted to have |
| 13:33 | <annevk> | hmm |
| 13:33 | <darobin> | void foo (SomeOptionsDict opt, SomeCB cb) |
| 13:33 | <darobin> | void foo (SomeCB cb) |
| 13:34 | <annevk> | oh |
| 13:34 | <annevk> | optional arguments typically go second |
| 13:34 | <darobin> | I know |
| 13:34 | <darobin> | but they also have something about callbacks always being last |
| 13:34 | <annevk> | NIH |
| 13:34 | <darobin> | in any case, I wasn't necessarily interested in their specific design |
| 13:34 | <annevk> | fair enough |
| 13:35 | <darobin> | but it's pretty common to see APIs that can take a mixture of functions and options |
| 13:35 | <darobin> | Node is full of them |
| 13:35 | <darobin> | it seems silly that we can't describe a common pattern |
| 13:35 | <darobin> | actually jQuery has that too |
| 13:40 | <jgraham> | Callbacks always last? |
| 13:40 | <darobin> | it's a common idiom |
| 13:45 | <jgraham> | That's very strange |
| 13:45 | <jgraham> | "functions are just another kind of object" |
| 13:45 | <jgraham> | "oh but we always pass them last, because they are special" |
| 13:50 | <annevk> | Expect consistency? Prepare for massive disappointed. |
| 13:50 | <annevk> | Also, topic. |
| 13:52 | <jgraham> | "Tim Berners-Lee (he’s like Simon Cowell, for the web)" |
| 14:11 | <Ms2ger> | darobin, so, there's no issue there |
| 14:11 | <Ms2ger> | darobin, if you pass two arguments, arg0 is a dict, arg1 is a callback; if you pass one, it's a callback |
| 14:31 | <annevk> | the way you implement that in JS however would be via typeof |
| 14:31 | <annevk> | you don't do argument counting first I think |
| 14:31 | <jgraham> | Well if you want to get the WebIDL dematics right you do |
| 14:32 | <jgraham> | *semantics |
| 14:32 | <Ms2ger> | And if you're writing testharness.js, you do that too, apparently |
| 14:32 | <annevk> | hmm |
| 14:41 | <jgraham> | https://github.com/html5lib |
| 14:41 | <jgraham> | Thanks to gsnedders who did all the actual work |
| 14:42 | <annevk> | nice |
| 14:43 | <annevk> | could've dropped the 5 though :p |
| 14:44 | <jgraham> | Well |
| 14:44 | <jgraham> | Not really |
| 14:44 | <jgraham> | Need all the code that does "import html5lib" to keep working |
| 14:45 | <jgraham> | In theory the right name for the project was libhtmlparser |
| 14:45 | <jgraham> | Which doesn't sound great… |
| 14:47 | <SimonSapin> | what’s the csswg-testsuite branch? |
| 14:47 | <Ms2ger> | Some patches to allow the build system of the css test suite to work |
| 14:47 | <Ms2ger> | gsnedders doesn't want to take them as-is, though |
| 14:48 | <SimonSapin> | ok |
| 14:48 | <Ms2ger> | So he promised to write replacements a year or so ago |
| 14:48 | <Ms2ger> | But those haven't materialize |
| 14:48 | <Ms2ger> | d |
| 14:48 | <SimonSapin> | so I probably don’t need it to run the test suite in WeasyPrint |
| 14:50 | <gsnedders> | SimonSapin: No, it's for building the CSS 2.1 testsuite |
| 14:53 | <gsnedders> | html5lib-php added now as well. |
| 14:53 | <gsnedders> | jgraham: Any point in moving your very very incomplete C stuff over? |
| 15:00 | <jgraham> | No |
| 15:00 | <jgraham> | Se also: very very incomplete |
| 15:16 | marcosc | wants a t-shirt that says "What's the use case?" |
| 15:25 | marcosc | would wear it at home and point to it when my dog looks at me funny. |
| 16:23 | <Hixie_> | annevk: url.spec.whatwg.org is broken |
| 16:26 | <annevk> | Hixie_: fixed |
| 16:28 | <Hixie_> | thanks |
| 16:28 | Hixie_ | is trying to do the url spec integration update |
| 16:28 | <Hixie_> | (for html) |
| 16:28 | <Hixie_> | annevk: so for Location, the "get the base" algorithm relies on the entry script |
| 16:29 | <Hixie_> | annevk: but you (redundantly) invoke the algorithm even when the url to "set the input" is absolute |
| 16:29 | <Hixie_> | annevk: which happens when the page is created |
| 16:29 | <Hixie_> | annevk: when there's no entry script |
| 16:29 | <Hixie_> | annevk: suggestions? |
| 16:29 | <annevk> | so input can be relative |
| 16:30 | <annevk> | Hixie_: I suggest making it return null if there is no entry script |
| 16:32 | <annevk> | Hixie_: to be clear, it always takes a base URL as for <a> /input/ can be relative |
| 16:49 | <Hixie_> | annevk: input can't be relative if it's Location and there's no entry script |
| 16:49 | <Hixie_> | annevk: so defining the base in that case is redundant |
| 16:50 | <annevk> | Hixie_: so either you need to make "get the base" return null in that scenario or I need to special case "get the base" not being defined somehow which seems a lot weirder than just having it return null |
| 16:52 | <Hixie_> | or you can just not call it when you don't need the base :-P |
| 16:52 | <Hixie_> | but ok |
| 16:53 | <annevk> | Hixie_: you have explained I don't need it for Location, but I pointed out this algorithm also takes into account <a>. How do I distinguish? |
| 16:54 | <Hixie_> | i can work around it on my end |
| 16:54 | <annevk> | okay |
| 16:54 | <Hixie_> | but in practice what would happen in good implementations is that the "get the base" callback would be pushed all the way into the parser algorithm |
| 16:54 | <Hixie_> | so it would just never be invoked if you tried to parse an absolute url |
| 16:56 | <annevk> | Hixie_: even for absolute URLs base is checked to be non-null |
| 16:56 | <Hixie_> | oh? |
| 16:56 | <Hixie_> | what does it do? |
| 16:56 | <annevk> | Hixie_: e.g. http:test parses differently based on the presence of a base URL |
| 16:56 | <Hixie_> | that's not an absolute url is it? |
| 16:57 | <Hixie_> | oh i guess it is by the spec's definition |
| 16:57 | <Hixie_> | interesting |
| 16:57 | <Hixie_> | that's a change from the old definition in html |
| 16:57 | <annevk> | Hixie_: http:test becomes http://test/ if the base URL scheme is file: and http://example.org/test if the base URL is http://example.org |
| 16:57 | <annevk> | Hixie_: the definition doesn't really matter, the parser just needs to know |
| 16:57 | <Hixie_> | sure |
| 16:58 | <Hixie_> | what i meant by "absolute url" is "the kind of full url used for a document's address" |
| 16:58 | <Hixie_> | and in those cases, the base url should never be checked |
| 16:58 | <annevk> | I understand, and I'm telling you that for those cases the base URL is checked |
| 16:58 | <Hixie_> | if i try to parse http://example.com/, you do something where the base url's value can have an effect on the resut? |
| 16:59 | <annevk> | no |
| 17:00 | <Hixie_> | so why would the base url be checked? |
| 17:00 | <Hixie_> | in those cases? |
| 17:00 | <annevk> | http://url.spec.whatwg.org/#scheme-state 2.4 |
| 17:00 | <annevk> | because during parsing we don't know yet |
| 17:00 | <annevk> | in a one-pass parse |
| 17:01 | <annevk> | whether the URL will meet the criteria |
| 17:01 | <Hixie_> | if you're doing work that can't have an effect, you're doing it wrong :-) |
| 17:02 | <Hixie_> | but ok |
| 17:02 | <Hixie_> | on another note, the url spec says that a base url is a relative scheme |
| 17:02 | <Hixie_> | but that's not always true |
| 17:02 | <Hixie_> | e.g. if you open a new tab, the base url is about:blank |
| 17:05 | <annevk> | Hixie_: if you can figure out a way to not make it do that without lookahead... |
| 17:06 | <annevk> | Hixie_: ah yeah, the idea was to require base URLs to have a relative scheme |
| 17:06 | <Hixie_> | just do both in parallel and when you figure out that you didn't see the "//" then drop the other branch :-) |
| 17:06 | <Hixie_> | also btw, "Except where different objects implementing URLUtilsReadOnly are identical to objects implementing URLUtils." doesn't make any sense :-P |
| 17:11 | <annevk> | Hixie_: right... |
| 17:11 | <annevk> | Hixie_: if I add a comma after "different"? |
| 17:11 | <annevk> | :p |
| 17:11 | <Hixie_> | except where different, you and i are identical too :-P |
| 17:11 | <Hixie_> | also, apples and oranges are identical except where different :-P |
| 17:12 | <annevk> | Except for additional constraints imposed by the IDL ... are identical? |
| 17:13 | <Hixie_> | yeah i dunno |
| 17:13 | <Hixie_> | the way i'd do it would be to define the two IDL blocks in the same block, and then define the members at the same time |
| 17:13 | <Hixie_> | "the protocol attributes..." |
| 17:14 | <Hixie_> | with the <dfn> around protocol being the same thing referenced by both IDL blocks |
| 17:14 | <Hixie_> | also, that would let you say things like "Specifications defining objects implementing URLUtils and URLUtilsReadOnly must define a get the base algorithm" |
| 17:15 | <Hixie_> | which right now is kinda confusing since it's not clear at a glance which of the algorithms are also needed for URLUtilsReadOnly |
| 17:15 | <annevk> | okay so the properties already reference the same stuff |
| 17:15 | <Hixie_> | though you can work it out since the ones only mentioned by setters obviously don't apply |
| 17:15 | <annevk> | I'll merge the IDL blocks and make that other change about get the bas |
| 17:16 | <Hixie_> | renaming "Interface URLUtils" to "Properties of the URLUtils and URLUtilsReadOnly interfaces" or some such would solve most of it i think |
| 17:16 | <Hixie_> | basically i'm saying make them equal first class citizens rather than trying to define one in terms of the other |
| 17:16 | <annevk> | yup |
| 17:21 | <Hixie_> | ok if you're interested i've updated the urlutils stuff in html |
| 17:21 | <Hixie_> | fixing markup errors now then i'll check it in |
| 17:24 | <Hixie_> | oh, i seem to have a mistake |
| 17:25 | <Hixie_> | annevk: when can the update steps be called on an object whose url is null? |
| 17:25 | <Hixie_> | annevk: and is there no way we can just have concept-uu-update just be passed a string? |
| 17:26 | <Hixie_> | annevk: having to have all this boilerplate to yank data straight out of the URLUtils object's internals each time seems dubious |
| 17:31 | <dglazkov> | good morning, Whatwg! |
| 18:12 | <annevk> | Hixie_: when href is invoked with something non-sensical |
| 18:13 | <annevk> | Hixie_: I don't get the model the HTML spec has that assumes URL is a string most of the time. I think it would be much better if it's an object most of the time and only serialized at the edges. |
| 18:14 | <Hixie_> | urls are strings dude :-) |
| 18:14 | <Hixie_> | anyway, i commented on the bugs |
| 18:15 | <Hixie_> | i think it's all done now |
| 18:16 | <annevk> | kk, will have a look later, I need a break |
| 18:18 | <Hixie_> | later! |
| 18:58 | <MikeSmith> | Hixie_: time to update that Henry Kissinger quote in your sig with the one at http://wikileaks.org/plusd/cables/P860114-1573_MC_b.html#efmCRNCV3 |
| 19:00 | <Hixie_> | Henry Kissinger quote? |
| 19:04 | <Hixie_> | heh, /percent decode/ doesn't ever update 'remaining' |
| 19:04 | <Hixie_> | i guess anne meant the definition to be a definition, not a "let" |
| 19:33 | <Hixie_> | is there anything in JS that can have a [[Call]] internal method other than a Function object, native objects, and host objects? |
| 19:34 | <Hixie_> | i guess what i'm really asking is what kinds of js code are there |
| 19:34 | <Hixie_> | i see functions, global code, and eval code |
| 21:16 | <Hixie_> | where on earth does the JS spec actually execute code |
| 21:17 | <Hixie_> | aaaah, "The production SourceElements : SourceElements SourceElement is evaluated as follows" |