| 07:06 | <annevk> | Discussing Vats: https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/7 |
| 07:06 | <annevk> | This wakes me up in the morning :-) |
| 07:19 | <MikeSmith> | I didn't even know there was a plan to specify structured clone in the es spec |
| 07:19 | <MikeSmith> | or if I did I forgot |
| 07:19 | MikeSmith | catches the clue train late |
| 07:22 | <MikeSmith> | annevk: so where do "worlds" fit into this? are "worlds" just an implementation thing? |
| 07:23 | <annevk> | I'm not sure what a world is. |
| 07:23 | <annevk> | But objects live in a realm and they can freely move to other realms, as long as they remain within the same vat. |
| 07:23 | <annevk> | If they want to leave the vat, they need to cloned or transfered. |
| 07:23 | <MikeSmith> | ah |
| 07:23 | <annevk> | be* |
| 07:24 | <annevk> | (Of course, they can also be cloned or transfered within the same vat.) |
| 07:33 | <MikeSmith> | annevk: so "worlds" I meant as in "isolated worlds" at https://developer.chrome.com/extensions/content_scripts#execution-environment |
| 07:33 | <annevk> | MikeSmith: that's different |
| 07:34 | <MikeSmith> | yeah I can see that now |
| 07:34 | <MikeSmith> | after reading it |
| 07:34 | <annevk> | "worlds" are more like views |
| 07:34 | <MikeSmith> | ah yeah |
| 10:05 | <gsnedders> | I'm pretty sure I'm missing something in ES6. ES5 defined for-in st deleting an unvisited property in the body caused it to never be visited; as far as I can tell, it would be visited per ES6. |
| 15:55 | <annevk> | Domenic: why does something with Symbol.iterator also have forEach(); convenience? |
| 15:55 | <Domenic> | annevk: dumb reasons, like making polyfills more usable |
| 15:55 | <annevk> | Domenic: so maybe we should not copy that in DOM? |
| 15:56 | <Domenic> | depends on the case ... i feel the pattern has been established for map and set-like things, i.e. having has/get/delete without forEach would be strange |
| 15:56 | <Domenic> | but for e.g. NodeWalkers I wouldn't copy it |
| 15:57 | <Domenic> | or other "exotic" iterables that aren't just array-like or map/set like |
| 15:58 | <annevk> | FormData, and such are like that, but they don't have any iteration support yet |
| 15:59 | <Domenic> | yeah, i mean, it doesn't hurt to have it, it's just IMO stupid |
| 16:01 | <annevk> | I should add a comment to the IDL iterables bug that it takes a position on this |
| 17:19 | <TabAtkins> | annevk: Yeah, until iterators are a real thing, forEach is needed. I made sure to add it to FontFaceSet when I finally removed [SetClass]. |
| 17:19 | <TabAtkins> | But agree that we shouldn't use it in the future. |
| 19:15 | <annevk> | Domenic: using e.g. http://software.hixie.ch/utilities/cgi/test-tools/echo you can see what browsers include in fetches |
| 19:31 | <annevk> | Domenic: hope you understand about asking you to file a bug on IDL; don't really want to start fighting this on a per API basis |
| 19:31 | <annevk> | (or defining the whole thing in prose, that'd take ages and would contain so many errors) |
| 19:32 | <Domenic> | annevk: I just think it's important not to have wrong spec text there in the meantime, and it's actually a good thing to define things correctly ahead of time and then just copy them over to IDL. |
| 19:32 | <annevk> | (aside from the fact that bz et al would refuse to implement) |
| 19:32 | <annevk> | in the maintime we need something we can implement and ship |
| 19:32 | <annevk> | mean* |
| 19:33 | <Domenic> | why can't you implement and ship the correct semantics |
| 19:33 | <Domenic> | literally just say "consult the existing algorithm you've already implemented for Map" |
| 19:34 | <annevk> | because ES != DOM on many levels in implementations today |
| 19:34 | <annevk> | not really sure we need to go into this discussion again, maybe bz is up for it if you ask nicely |
| 19:35 | <Domenic> | i don't see why the spec has to be incorrect to accomodate that |
| 19:35 | <Domenic> | the spec should be correct |
| 19:35 | <Domenic> | if implementations can't implement that correctly until after Q3 or whatever, that's fine |
| 19:35 | <Domenic> | but it's then a bug in the implementations that can be tracked |
| 19:35 | <Domenic> | and not the spec telling them to be wrong |
| 19:36 | <annevk> | I'm happy to update the spec once IDL provides better hooks, I'm not going to define this whole object in terms of ES and then let implementers figure out what binding to use |
| 19:38 | <Domenic> | It is frustrating that you are more focused on layering on top of IDL than on specifying correct semantics :( |
| 19:38 | <Domenic> | implementer concerns should be implementer concerns |
| 19:39 | <annevk> | I guess I'm more of a pragmatist |
| 19:40 | <Domenic> | So what would solve this. I will pull request WebIDL right now if that will fix it. |
| 19:40 | <annevk> | And I would be happy to correct the semantics if that were straightforward, but it's an order of magnitude more complicated at the moment and it's unlikely any of that work will actually be used |
| 19:41 | <Domenic> | It seems like you'd want some kind of AddMapInputs(sequenceArg, this, "set") specified in WebIDL |
| 19:41 | <annevk> | Yes, fixing IDL would solve this |
| 19:41 | <annevk> | Note that it should be this.append, not set |
| 19:41 | <Domenic> | OK. I will pull request that to WebIDL if you don't want to put it into Fetch. Is that AddMapInputs good? |
| 19:41 | <Domenic> | OK sure you'd pass "append" |
| 19:42 | <annevk> | Many specifications will need this, that's why I'm kicking it up a layer as "not my problem" |
| 19:43 | <annevk> | I don't really want to take responsibility for IDL at this point |
| 19:43 | <Domenic> | Right now only one specification does |
| 19:44 | <annevk> | There have been many requests for "open-ended dictionary" |
| 19:45 | <annevk> | And this is not the first place there's nested sequences either I think |
| 19:45 | <Domenic> | This feels similar to adding something in your code in one file that needs it, and later extracinting it out into a utils package |
| 19:45 | <annevk> | bz can probably reference a few things |
| 19:45 | <Domenic> | Instead of just introducing buggy code |
| 19:46 | <Domenic> | But whatevs, if introducing buggy code is just a tactic for getting me to write the correct code in the utils package, that works too |
| 19:46 | <Domenic> | Also: WebIDL is generated from XML @_@ |
| 19:46 | <annevk> | I did check this particular IDL with you beforehand if you remember |
| 19:46 | <Domenic> | Sure, the arguments were fine |
| 19:47 | <Domenic> | The processing of them is not |
| 19:47 | <SamB> | WebIDL is generated from XML? |
| 19:47 | <annevk> | Per bz there's a difference |
| 19:47 | <SamB> | that sounds counterproductive |
| 19:47 | <SamB> | it's like RNG Compact, only backwards! |
| 19:48 | <SamB> | maybe you meant something other than what it sounded like |
| 19:48 | <Domenic> | There is an XSLT file and a makefile (yay, fails on Windows) |
| 19:48 | <SamB> | you must be using the wrong make |
| 19:48 | <SamB> | maybe try the other one |
| 19:48 | <annevk> | Domenic: but yeah, writing the utils package is significantly more low-level and I'd rather not have to write that code |
| 19:48 | <SamB> | or maybe you forgot to put xsltproc in PATH |
| 19:49 | <annevk> | Domenic: that's why I've filed a ton of bugs on IDL hoping someone would fix them |
| 19:49 | <Domenic> | SamB: can't tell if you're trolling or just have never used Windows |
| 19:49 | <SamB> | well, I can't remember which of the two makes that ship with MinGW are actually useable |
| 19:49 | <annevk> | Domenic: there's only so many things I can tackle |
| 19:49 | <Domenic> | annevk: sure. it's just sucky that instead there's bugs infesting specs in the meantime. |
| 19:49 | <SamB> | and "forgot to put xsltproc in PATH" could be considered trolling |
| 19:50 | <annevk> | Domenic: as far as I can tell the way it's written now can be migrated to something less throwy later easily |
| 19:50 | <annevk> | Domenic: there's a transition path of sorts to a saner future |
| 19:50 | <SamB> | Domenic: so, I guess you probably meant the *spec*? |
| 19:50 | <SamB> | rathert than just web IDL code in general |
| 19:51 | <SamB> | (if you count IDL as code) |
| 19:51 | <annevk> | Domenic: also, <3 |
| 19:52 | SamB | tries to imagine the idiot who writes his Relax NG in the XML syntax, only to use trang to convert it into the compact syntax that Emacs/nxml/rng-validate can use |
| 19:52 | <annevk> | Domenic: so btw, if you do actually think the IDL is fine and it really is the prose that's broken, that would be an easy fix, but I was doubting that to be the case, hence the pushback |
| 19:54 | <Domenic> | annevk: yeah, it could be migrated I think, it's true. I should calm down. |
| 19:54 | <annevk> | Domenic: also, I'm fairly happy with tweaking things over time until all the details are correct; I'd rather have the current algorithm and get that shipped and then improve than a half-broken IDL/JS mix in the spec that nobody is sure what to do with |
| 19:54 | <Domenic> | SamB: yes indeed. |
| 19:54 | <Domenic> | annevk: <3 indeed :) |
| 19:55 | <Domenic> | annevk: I think the prose could be fixed pretty easily. Just say something like "call `this.append(header[0], header[1])` and rethrow any exceptions essentially. |
| 19:57 | <TabAtkins> | Is this about something like .extend() for HeaderMap? |
| 19:57 | <TabAtkins> | (Map really needs .extend(), btw.) |
| 19:57 | <Domenic> | Nah it's about new HeaderMap(iterableOfTwoElementArrays) and how the current spec text does not match Map(iterableOfTwoElementArrays)'s behavior |
| 19:57 | <TabAtkins> | (I use it regularly in Python.) |
| 19:57 | <TabAtkins> | Ah. |
| 19:57 | <Domenic> | Map and set are anemic |
| 19:57 | <annevk> | s/HeaderMap/Headers/ |
| 19:58 | <Domenic> | I really want the bind operator so we can stop blocking on the committee for good standard library |
| 19:58 | <TabAtkins> | Indeed. |
| 19:58 | <Domenic> | and still get something method-ish enough to be pleasant |
| 19:58 | <Domenic> | I will try to get the ball rolling in time for next TC39 |
| 19:59 | <TabAtkins> | Sweet, thanks. |
| 20:00 | TabAtkins | likes the look of myMap::extend(foo). |
| 20:00 | <annevk> | I'd like to talk vats with Mark Miller some day, just for fun |
| 20:00 | <Domenic> | haha |
| 20:00 | <Domenic> | *I* think it would be fun |
| 20:00 | <annevk> | I was not sarcastic :-) |
| 20:00 | <Domenic> | I think other people would warn you off |
| 20:01 | <TabAtkins> | Hm, okay, so similar topic. I need to add a constructor for FontFaceSet. FFS is currently defined as storing its stuff in an internal Set. Can I just say that it passes its arguments to the Set constructor and uses the result as its internal set? |
| 20:01 | <annevk> | Gecko actually has vats of sorts thanks to bholley |
| 20:01 | <annevk> | With some silly stuff for document.domain |
| 20:02 | <annevk> | It's really quite cool and a lot nicer than the hacks Blink et al have |
| 20:02 | <Domenic> | TabAtkins: in-ter-esting... |
| 20:02 | <TabAtkins> | I do that for all the Set methods it exposes - just epxlicitly delegate to the internal set and return what it returns. |
| 20:02 | <Domenic> | Probably not, because you want argument validation? |
| 20:02 | <Domenic> | (or coercion, rather) |
| 20:02 | <TabAtkins> | Domenic: I have to write the argument list, yeah, but that's allt he validation I need I think. |
| 20:03 | <TabAtkins> | It'll just take an iterable of FontFace objects. |
| 20:03 | <TabAtkins> | No coercion happening. |
| 20:03 | <Domenic> | Hmm yeah that'd probably do it |
| 20:03 | <Domenic> | (right, coercion is for strings) |
| 20:03 | <annevk> | Yeah, all the multimap stuff I've designed is also using an internal multimap of sorts |
| 20:03 | <Domenic> | TabAtkins: yeah I'm pretty sure that would work. |
| 20:04 | TabAtkins | still isn't sure how to write the return value of entries/values. |
| 20:04 | <annevk> | I should probably define an actual conceptual multimap to make it clearer how FormData/URLSearchParams/Headers are all kind of the same |
| 20:04 | <TabAtkins> | annevk: Would be nice, yes. |
| 20:04 | <Domenic> | TabAtkins: `any` seems good ;) |
| 20:04 | Domenic | doesn't really believe in IDL return values |
| 20:05 | <annevk> | Reportedly they're good for JIT |
| 20:05 | <TabAtkins> | Domenic: I'm currently copying the MDN text and using "Iterator". |
| 20:05 | <TabAtkins> | They're informative for the author, at least. |
| 20:05 | <Domenic> | Yeah yeah, fine guys, be practical. I'm going to sit over here in castle theoretical purity and be self-satisfied, mmk? |
| 20:06 | <TabAtkins> | Interesting that Castle Theoretical Purity is the one arguing for *less* type information. |
| 20:06 | <annevk> | Well ES6 doesn't have types, so |
| 20:07 | <annevk> | :p |
| 20:08 | <Domenic> | heh, yeah, ES's room in Castle Theoretical Purity is not often visited by other residents. |
| 20:30 | <TabAtkins> | annevk, Domenic: Should I define the signature of the FFS constructor as (sequence<FontFace>) or something? Or is there a better way to indicate "iterable of FontFace objects"? |
| 20:30 | <Domenic> | I think that's the right way to go. I think all iterables are convertable into sequences |
| 20:30 | <Ms2ger> | sequence argument is "iterable" |
| 20:30 | <Ms2ger> | Not sure if the spec has been updated to say that yet, though |
| 20:30 | <TabAtkins> | Cool. |
| 20:31 | <TabAtkins> | The fact that arguments and attributes/return values use the same names but mean different things is weird. |
| 20:32 | <Ms2ger> | I don't think they "mean different things", but not going to start that again |
| 20:32 | <TabAtkins> | "sequence<Foo>" means "iterable of Foos" in argument lists, but explicitly "Array of Foos" in attributes/return values. |
| 20:33 | <Ms2ger> | No, it means "sequence of Foos" in both cases |
| 20:33 | <Ms2ger> | And there's a function jsval -> sequence<Foo>, and one sequence<Foo> -> jsval |
| 20:34 | <TabAtkins> | I can pass in an iterator to the former, but can't ever get an iterator out of the latter; I have to do something different for that. |
| 20:35 | <Ms2ger> | Yes? |
| 20:35 | <SamB> | TabAtkins: can't you get any iterable type out of the latter? |
| 20:35 | <SamB> | depending on the whims of the implementor? |
| 20:35 | <TabAtkins> | SamB: No. |
| 20:36 | <TabAtkins> | Giving an attribute the type "sequence<Foo>" means it'll be an Array of Foos. |
| 20:36 | <SamB> | well it seems stupid if it's just another name for an Array |
| 20:36 | <TabAtkins> | Welcome to legacy naming problems! |
| 20:36 | <Ms2ger> | (Note that those functions don't precisely correspond to argument/return value; sometimes it's the other way around) |
| 20:36 | <TabAtkins> | Remember that WebIDL wasn't JS-specific originally. |
| 20:36 | <SamB> | how is sequence<Foo> legacy |
| 20:36 | <SamB> | TabAtkins: oh |
| 20:36 | <Ms2ger> | SamB, why invent a new name for it? |
| 20:37 | <Ms2ger> | It's conceptually a sequence for both |
| 20:37 | <TabAtkins> | Because it's way clearer to read "Array<Foo>" than to have to remember that "sequence" in WebIDL means Array in JS. |
| 20:37 | <TabAtkins> | The conceptual part of it isn't important; you actually want to know what type it is. |
| 20:37 | <Ms2ger> | I wouldn't mind calling them both Array |
| 20:37 | <SamB> | that sounds wrong also |
| 20:37 | <Ms2ger> | I disagree that concepts are not important |
| 20:38 | <TabAtkins> | Calling the argument one Array would be wrong, since it only actually uses iterableness. |
| 20:38 | <Ms2ger> | It converts into an array |
| 20:38 | <Ms2ger> | Anyway |
| 20:38 | <SamB> | does it have to? |
| 20:38 | <Ms2ger> | Yes |
| 20:38 | <TabAtkins> | SamB: Doesn't really matter; that parts hidden away behind machinery. Point is that it does one iteration over the object. |
| 20:38 | <Ms2ger> | Well, it does if you do anything side-effecty in the loop |
| 20:39 | <SamB> | TabAtkins: yeah, I know, how can it "have to" do something you can't observe anyway? |
| 20:39 | <Ms2ger> | For example, node.append(node, {toString... }) won't append the first argument before evaluating the toString |
| 20:40 | <SamB> | gotcha |
| 20:40 | <Ms2ger> | So conceptually, it gathers them into an array first |
| 20:40 | <Ms2ger> | (Well, that's variadic arguments, but same thing for sequences) |
| 20:43 | <TabAtkins> | Yeah, it does a data-validation/conversion pass over all the argument before operating on them. Whether they end up stored in an Array or not is an unknowable aspect. ^_^ |
| 20:44 | <Ms2ger> | Sure |
| 20:44 | <Ms2ger> | I'm not talking about implementation here |
| 20:45 | <Ms2ger> | All I'm saying is that *conceptually*, it gathers them into an array first |
| 20:45 | <Ms2ger> | If you understand that, you understand the behaviour |
| 20:45 | <Ms2ger> | Even if the actual implementation is unknowable |
| 20:45 | <TabAtkins> | Right. But using that to say that the argument type should say "Array" is still wrong, because we don't care whether you pass an Array or not. |
| 20:45 | <SamB> | so an array, not an Array |
| 20:46 | <TabAtkins> | We just care about the iterable aspect, and so that's what should be reflected in the name of the argument type, ideally. |
| 20:46 | <Ms2ger> | So how about callbacks? |
| 20:46 | <TabAtkins> | How about them? |
| 20:46 | <Ms2ger> | If you have a callback function that takes a sequence<T>, you're getting an array, not an unknowable iterable |
| 20:47 | <TabAtkins> | Hm, interesting point. |
| 20:47 | <SamB> | that could explode, you know |
| 20:47 | <TabAtkins> | SamB: How? |
| 20:47 | <Ms2ger> | Boom? |
| 20:47 | <Domenic> | this yak is getting shaaaaaaved |
| 20:48 | <Domenic> | right now i'm installing a package manager so i can get winpthreads so i can get libxml2 so i can get libxslt so i can make the webidl i wrote |
| 20:48 | <SamB> | so, I mean, what do you do if you really did want to just take an iterable so it's okay if the sequence is longer than any available memory chunk? |
| 20:48 | <TabAtkins> | Domenic: Have you tried not using Windows? |
| 20:49 | <Ms2ger> | SamB, you still get an Array |
| 20:49 | <SamB> | Domenic: which manager? |
| 20:49 | <Domenic> | I fight for the users! |
| 20:49 | <SamB> | Ms2ger: surely it's possible to get an iterable which you can iterate at your leisure somehow |
| 20:49 | <TabAtkins> | That said, if you now have libxml2, you might have the ability to install Bikeshed and make it work. |
| 20:49 | <TabAtkins> | If you do so, PLEASE WRITE IT DOWN AND SEND IT TO ME. |
| 20:49 | <TabAtkins> | I'd love install instructions for windows. |
| 20:49 | <SamB> | you would probably not love them |
| 20:50 | <Ms2ger> | Ha |
| 20:50 | <TabAtkins> | Man, even the Linux instructions aren't great. |
| 20:50 | <TabAtkins> | Installing OSS is hard. |
| 20:50 | <Ms2ger> | SamB, well, the browser is always going to give you an array; it's not going to analyze your code to check if it needs an array, and give you an iterable otherwise |
| 20:50 | <SamB> | TabAtkins: why isn't it "apt-get install bikeshed" yet |
| 20:51 | <TabAtkins> | Ms2ger: I think he meant "surely there's some way to indicate in WebIDL that the callback shoudl be passed an iterable". |
| 20:51 | <TabAtkins> | SamB: Because that's crazy times. |
| 20:51 | <SamB> | Ms2ger: I was figuring you could write some different IDL to get it give you the iterable |
| 20:51 | <Ms2ger> | Oh, on the IDL side |
| 20:51 | <Ms2ger> | That sounds like a pain |
| 20:52 | <SamB> | could be |
| 20:52 | <SamB> | are you imagining monster stack traces? |
| 20:54 | <Ms2ger> | Just monster implementation :) |
| 20:54 | <Ms2ger> | Maybe it could work, but it feels funny |
| 20:54 | <Ms2ger> | On another note |
| 20:54 | <Ms2ger> | "A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element." is a nice COMEFROM |
| 20:54 | <TabAtkins> | Seems not too crazy to return an iterator over some structure. |
| 20:56 | <Hixie> | Ms2ger: yeah unfortunately there's no spec that actually defines dispatch properly in the first place, so i couldn't do anything _but_ a COMEFROM there :-( |
| 20:57 | <Ms2ger> | Mm |
| 20:57 | <Ms2ger> | I guess this is UI Events territory |
| 20:57 | <SamB> | TabAtkins: what about letting an IDL method *accept* one? |
| 20:58 | <SamB> | rather than coercing it into an array of some kind |
| 20:58 | <TabAtkins> | SamB: Accepting one is just done by using "sequence<Foo>" today. |
| 20:58 | <Ms2ger> | Ha |
| 20:58 | <TabAtkins> | Oh, you mean one that only consumes data as it needs, rather than all up-front? |
| 20:58 | <Ms2ger> | UI Events is a delta spec for D3E/DOM, yet has neither in its References section |
| 20:59 | <SamB> | TabAtkins: yeah |
| 21:01 | <SamB> | would that be a normative reference, or a transformative reference? |
| 21:08 | <Domenic> | I give up on this xslt thing |
| 21:08 | <Ms2ger> | Hixie, hm, I guess "form control" in a term of art there? |
| 21:08 | <Hixie> | i think "disabled" is the term of art there, no? |
| 21:08 | <Hixie> | maybe |
| 21:08 | <Hixie> | is it hyperlinked? |
| 21:09 | <SamB> | isn't form control two terms |
| 21:09 | <Ms2ger> | Yeah, to... |
| 21:09 | <Ms2ger> | "A form control is disabled if ..." |
| 21:10 | <Hixie> | close enough :-P |
| 21:10 | <Ms2ger> | That still doesn't tell me which elements are form controls, though |
| 21:11 | <Ms2ger> | Hixie, or am I overlooking something? |
| 21:12 | <Ms2ger> | There's things like "Listed, labelable, submittable, and reassociateable form-associated element." under categories |
| 21:12 | <SamB> | Hixie: did I mention that the section about origins would be improved by hyperlinking more of the places where it mentions parts of URLs, and it wouldn't hurt to either give a summary of the parts of a URL or links to the corresponding parts of the URL spec ... |
| 21:12 | <Hixie> | SamB: if you filed a bug, then you did. othewise, you didn't. :-) |
| 21:13 | <Ms2ger> | Hixie, (not just trying to nitpick, I have no idea if my implementor in Servo (hi abinader) got them all) |
| 21:13 | <SamB> | I was gonna write you a patch for it but your buildsystem is, uh, so messy you're evidently ashamed to even mention it in the repo |
| 21:13 | <Hixie> | Ms2ger: replace "form control" with "boogie moogie" and that section doesn't change meaning as far as i can tell |
| 21:13 | <Ms2ger> | Indeed |
| 21:13 | <Ms2ger> | So what kind of elements are boogie moogies? :) |
| 21:14 | <Hixie> | Ms2ger: doesn't matter |
| 21:14 | <Hixie> | Ms2ger: why would it matter? |
| 21:14 | <SamB> | Ms2ger: you can't tell? |
| 21:14 | <Hixie> | Ms2ger: you just apply this if they're disabled |
| 21:14 | <Ms2ger> | Who's "they"? |
| 21:14 | <abinader> | I'm currently basing that all form controls affected by disabled are those in which have the disabled idl property |
| 21:15 | <SamB> | I mean, my thinking would be that it's pretty easy to tell based on whether it has something to do with input to a form, and whether it has a disabled attribute? |
| 21:15 | <Ms2ger> | I mean, does it apply to a elements? |
| 21:15 | <Hixie> | Ms2ger: boogie moogies are disabled if they have a disabled attribute set, where "disabled attribute" is specifically "attr-fe-disabled", which only some elements can have set |
| 21:15 | <SamB> | Ms2ger: I'd say no |
| 21:15 | <abinader> | which matches the ones listed in http://www.whatwg.org/specs/web-apps/current-work/multipage/common-idioms.html#concept-element-disabled |
| 21:15 | <Ms2ger> | Hmm |
| 21:15 | <Hixie> | Ms2ger: <a disabled> doesn't have an attr-fe-disabled attribute set |
| 21:15 | <SamB> | the widgety stuff is what I'd assume it talks about |
| 21:15 | <Ms2ger> | SamB, I don't care what you'd say, I care what the spec says :) |
| 21:15 | <Ms2ger> | Hixie, that's pretty obscure |
| 21:15 | <Hixie> | Ms2ger: no disagreement from me there :-) |
| 21:15 | <SamB> | Ms2ger: clearly I'm right and the spec is wrong |
| 21:16 | <SamB> | where wrong could just include "very unclear" |
| 21:16 | <Ms2ger> | I'm still not implementing you ;) |
| 21:16 | <SamB> | good |
| 21:16 | <SamB> | I'm full of bugs in general |
| 21:16 | <Ms2ger> | tmi |
| 21:16 | <annevk> | just extend dbaron's desk a bit and we should be good |
| 21:17 | <SamB> | wetware bugs, not, you know, actual insects or anything of that nature |
| 21:17 | <Ms2ger> | Ha |
| 21:17 | <SamB> | annevk: I don't get it |
| 21:17 | <dbaron> | the conformant HTML4 desk? |
| 21:17 | <annevk> | you must be new here |
| 21:17 | <SamB> | intermittent, at least |
| 21:17 | <annevk> | dbaron: :-) |
| 21:18 | <Ms2ger> | Hixie, I think that's worth a note, at least |
| 21:18 | <SamB> | I honestly wasn't sure if annevk was referencing/making a joke, or referring to a piece of software |
| 21:18 | <Hixie> | Ms2ger: absolutely agreed |
| 21:18 | <Hixie> | Ms2ger: file a bug :-) |
| 21:19 | <SamB> | called "desk", which while a fairly bad name for a piece of software, is not unimaginably bad |
| 21:20 | <Hixie> | the former |
| 21:20 | <Hixie> | though really it's not a joke but an analogy |
| 21:20 | <Hixie> | specifically: any desk on which you carve two quote marks is a fully conforming implementation of HTML4 |
| 21:21 | <Hixie> | (seriously. not a joke. find a requirement that such an implementation would violate, i dare you!) |
| 21:21 | <Hixie> | (in fact it's more conforming than most browsers, since browsers assume a default encoding!) |
| 21:22 | <Ms2ger> | Productive review... I'm not even done, and I've already filed three spec bugs |
| 21:22 | <SamB> | Hixie: what is the pair of quotes for, exactly? |
| 21:23 | <Ms2ger> | SamB, <q> is required to render with quote mars around it |
| 21:23 | <SamB> | Hixie: what does HTML4 say you have to do about encodings |
| 21:23 | <SamB> | Ms2ger: lol |
| 21:23 | <Ms2ger> | SamB, that's understood to be the only actual requirement in HTML4 |
| 21:23 | <SamB> | but no mention of how far around it? |
| 21:23 | <SamB> | or that each such element needs a distinct pair of quotes? |
| 21:24 | <Hixie> | SamB: "Visual user agents must ensure that the content of the Q element is rendered with delimiting quotation marks" |
| 21:24 | <Hixie> | SamB: (it's one of the few requirements) |
| 21:24 | <annevk> | Ms2ger: D3E? |
| 21:24 | <annevk> | Ms2ger: such a sad spec |
| 21:24 | <SamB> | oh, so I a desk without the quotes is just a non-visual user agent |
| 21:24 | <Ms2ger> | annevk, two D3E, one about the confusingness in HTML above |
| 21:24 | <SamB> | s/I // |
| 21:24 | <Hixie> | SamB: "Therefore, user agents must not assume any default value for the "charset" parameter" is the requirement about encodings that i mentioned |
| 21:24 | <SamB> | Hixie: ah |
| 21:25 | annevk | watches inbox zero go bust |
| 21:25 | <annevk> | HTML4 is so silly |
| 21:25 | <SamB> | Hixie: how naive are the peopel who wrote THAT requirement? |
| 21:25 | <SamB> | I mean, it's pretty crazy ... |
| 21:25 | <Ms2ger> | SamB, have you read HTML4? |
| 21:26 | <SamB> | Ms2ger: not lately |
| 21:26 | <Hixie> | the web was young |
| 21:26 | <annevk> | I think the main problem is that people are still writing specs HTML4-style |
| 21:26 | <Hixie> | and the people writing specs for it were young too |
| 21:26 | <SamB> | I was probably at least as naive back when I would have read it |
| 21:26 | <Hixie> | took a while to learn the lessons |
| 21:26 | <Hixie> | (unfortunately some never did and still edit specs at the w3c) |
| 21:27 | <SamB> | you really need to give an "or else you will be eaten by a giant bear" or something, except something that is actually very bad and very easy to demonstrate |
| 21:27 | <annevk> | Yeah, learning lessons takes long. Hard to fathom how XMLHttpRequest has evolved over eight years |
| 21:27 | <SamB> | like, "or we will steal your computer from you and make you pay the electric bill" |
| 21:28 | <SamB> | "MUST NOT" without teeth is quite silly |
| 21:28 | <SamB> | when its the sort of thing users will be wanting |
| 21:29 | <SamB> | first they make reasonable request like "This document is clearly in ASCII, just parse it already" ... |
| 21:29 | <SamB> | and it just goes downhill from their |
| 21:31 | <Domenic> | Only semi-related, but I like it when specs include undefined behavior, because then you can be a conforming implementation even if your response to the situation is indeed to mine bitcoins on the user's computer. |
| 21:31 | <Ms2ger> | Domenic, might as well alert YOLO in an infinite loop |
| 21:32 | <SamB> | Domenic: you're kidding, right? |
| 21:33 | <SamB> | do you really have a reason to like undefined behaviour, or do you really wish it could just go away like I assume most people do most of the time ... |
| 21:33 | <SamB> | not to confuse it with unspecified or implementation-defined behaviour |
| 21:40 | <Hixie> | Domenic: it wouldn't be non-conforming for an ES implementation to mine bitcoins from a user's computer even when not doign something undefined |
| 21:41 | <Hixie> | or most other specs for that matter, HTML, DOM, whatever |
| 21:41 | <SamB> | true |
| 21:41 | <SamB> | POSIX |
| 21:41 | <Ms2ger> | Ha, posix |
| 21:42 | <SamB> | not that conforming to POSIX is what you call "wise" |
| 21:42 | <Ms2ger> | Then again, isn't the goal of an ES implementation to let random sites mine bitcoins on your computer? |
| 21:43 | <SamB> | Ms2ger: you must be thinking of WebGL |
| 21:43 | <Ms2ger> | I prefer not to |
| 21:44 | <SamB> | my main experience with WebGL is firefox telling me "not can has ilt; you no has WebGL" |
| 21:44 | <SamB> | *Tilt |
| 21:44 | <SamB> | darn enter key always gets in my way |
| 21:44 | <Ms2ger> | My main experience is making Chrome crash |
| 21:44 | <Ms2ger> | I need to submit that test at some point |