| 00:41 | <MikeSmith> | TabAtkins: the XML-disallows-<-in-attr-values things causes problems in Bikeshed? |
| 00:41 | <MikeSmith> | or somewhere else? |
| 00:41 | <TabAtkins> | No, it causes problems in *my head* because I was editting WebIDL's index.xml file and wtf |
| 00:42 | <MikeSmith> | ah |
| 00:42 | <TabAtkins> | Bikeshed doesn't go anywhere near XML. |
| 00:42 | <MikeSmith> | count me relieved |
| 05:42 | <annevk> | krijn: hey sorry, I totally forget, going to set up irc-logs.html5.org now |
| 05:42 | <annevk> | forgot, even |
| 05:43 | <krijn> | Thanks! Haven't had time myself either though |
| 05:44 | <annevk> | krijn: okay, it's added to your account, might take a couple minutes |
| 05:44 | <annevk> | krijn: you'll have to add HSTS headers yourself btw |
| 06:56 | <annevk> | hsivonen: we got some PRs formalizing the HTML parser language; is that something you have time for to look through? |
| 06:56 | <annevk> | hsivonen: https://github.com/whatwg/html/pull/993 and https://github.com/whatwg/html/pull/994 |
| 06:57 | <annevk> | nox: might also be of interest to you? Forgot if you wrote an HTML parser or not |
| 06:58 | <nox> | annevk: I maintain h5e with SimonSapin. |
| 07:20 | <gsnedders> | annevk: yay |
| 07:20 | gsnedders | remembers writing to the mailing list about this ages ago |
| 08:18 | <mkwst> | Domenic: I assume you're sleeping, right? :) |
| 08:19 | <annevk> | mkwst: if this is about the PR, I can probably do the final review |
| 08:19 | <mkwst> | annevk: It's about CSP hooks for ECMAScript. |
| 08:19 | <mkwst> | https://github.com/whatwg/html/issues/271#issuecomment-198084014 |
| 08:20 | <annevk> | mkwst: something unclear? |
| 08:21 | <mkwst> | I just don't know the relationship between HTML concepts and ECMAScript concepts. |
| 08:21 | <mkwst> | Is a "realm" a settings object? |
| 08:21 | <mkwst> | Or a global object? |
| 08:21 | <annevk> | mkwst: they're 1:1 |
| 08:21 | <annevk> | mkwst: those are also 1:1 |
| 08:22 | <annevk> | mkwst: https://html.spec.whatwg.org/multipage/webappapis.html#global-object |
| 08:24 | <mkwst> | The way I read that, an environment settings object has a realm. I'm missing the way to get from a realm to its settings object. |
| 08:24 | <mkwst> | Does a realm have a "relevant settings object" or something similar? |
| 08:24 | <mkwst> | Oh. `[[HostDefined]]`? |
| 08:27 | <annevk> | mkwst: yeah |
| 08:27 | <annevk> | mkwst: I recommend using the terms HTML defines, in this case, "the Realm's settings object" |
| 08:27 | <mkwst> | Yup. I see that now. Thanks for the link! |
| 08:34 | <mkwst> | annevk: If you have a second for another n00b ECMA question: |
| 08:35 | <annevk> | mkwst: sure |
| 08:35 | <mkwst> | Given spec text like "Perform ? HostEnsureCanCompileStrings(the current Realm Record, evalRealm).", what is the expected implementation? |
| 08:35 | <mkwst> | return abruptly" |
| 08:35 | <mkwst> | ? |
| 08:35 | <mkwst> | return normally with some value? |
| 08:36 | <annevk> | mkwst: that means you can throw or just return |
| 08:36 | <annevk> | mkwst: if you throw it'll stop at that step basically |
| 08:36 | <annevk> | mkwst: and rethrow the exception |
| 08:37 | <annevk> | mkwst: if you return it'll proceed to the next step |
| 08:37 | <mkwst> | Ok. I think I understand, thanks! |
| 08:38 | <annevk> | If forbidden, then throw a ... exception. |
| 08:38 | <annevk> | Otherwise, then return. |
| 08:38 | <annevk> | That could also be just "Return." I suppose |
| 08:39 | <annevk> | More bikeshed, you don't need the second step, just the throw step |
| 09:00 | <zcorpan> | is it weird for unsigned long to be nullable? (input.selectionStart) |
| 09:07 | <mkwst> | annevk: Is https://github.com/w3c/webappsec-csp/pull/66 more or less reasonable? If so, I'll put together an HTML patch that wires up an implementation of HostEnsureCanCompileStrings to the new method defined in CSP. |
| 09:07 | <annevk> | zcorpan: a bit, cannot just return 0? |
| 09:08 | <zcorpan> | annevk: that doesn't distinguish it from when it applies. -1 maybe? |
| 09:08 | <annevk> | mkwst: I think you can omit step 3 |
| 09:08 | <annevk> | mkwst: normally is not really a thing |
| 09:08 | <mkwst> | Ok. The language in ECMA262 made it sound like a thing. |
| 09:09 | <mkwst> | I'll whip up an HTML patch, then. Thanks. |
| 09:09 | <annevk> | mkwst: a normal completion is, but don't think that's needed hete |
| 09:10 | <annevk> | here |
| 09:10 | <annevk> | zcorpan: that would not be unsigned |
| 09:10 | <zcorpan> | annevk: right so i'd change it to long |
| 09:11 | <zcorpan> | maybe long long while at it? |
| 09:11 | <annevk> | zcorpan: not sure if it matters enough to change types for, can't developers use the type attribute instead? |
| 09:12 | <zcorpan> | annevk: changing the type seems trivial that can be changed at the same time as not throwing an exception on getting |
| 09:14 | <annevk> | I guess it'd be best to discuss with an implementer |
| 09:15 | <annevk> | Seems unnecessary to me, but I don't care strongly |
| 09:18 | <Ms2ger> | zcorpan, -1 is a horrible sentinel value, though |
| 09:21 | <zcorpan> | there's also that setting it forwards to setSelectionRange whose arguments are unsigned long |
| 12:42 | <Domenic> | -1 is used as a sentinel for HTMLProgressElement |
| 12:42 | <Domenic> | A React dev recently contacted me about cases where there's a lack of mutable property <-> attribute correspondence; I think <progress> is one of them |
| 12:43 | <Domenic> | I told him to put together a list and post an issue so hopefully we'll get an exhaustive list soon |
| 12:43 | <Domenic> | Maybe that is what this is discussing I dunno I went to IRC first after waking up instead of email |
| 16:28 | <Domenic> | TabAtkins: no link type for pseudo-classes it seems? just use dfn? that's what selectors4 seems to do |
| 16:28 | <TabAtkins> | Domenic: They're type=selector. Bikeshed has some CSS-specific type-detection if there's no type manually specified. |
| 16:28 | <TabAtkins> | (In other words, the rule "a dfn without a type is automatically type=dfn" is not *strictly* true.) |
| 16:29 | <TabAtkins> | (This is well-documented in the <dfn> docs, tho.) |
| 16:30 | <Domenic> | TabAtkins: ok. When I try to add an external anchor that is type: selector, and reference it using '':defined'', it links but doesn't get the fancy curly quotes around it |
| 16:31 | <TabAtkins> | Those come from the stylesheet; they're generated content. |
| 16:32 | <TabAtkins> | Y'all's stylesheet doesn't add it. |
| 16:32 | <Domenic> | ah ok cool |
| 16:33 | <Domenic> | annevk: do you prefer markdown style lists in DOM, or <li><p>, or <li>? Omit closing tags I assume, if the latter? |
| 16:34 | <annevk> | Domenic: <li><p>, it's a bit inconsistent now though |
| 16:34 | <Domenic> | annevk: sounds good |
| 16:34 | <annevk> | Domenic: it's pretty much the same style as HTML, except I keep inline elements unwrapped |
| 16:35 | <Domenic> | annevk: "unwrapped"? |
| 16:35 | <annevk> | Domenic: and I omit closing tags, though sometimes not since I'm getting used to editing HTML... |
| 16:35 | <annevk> | Domenic: without newlines inside |
| 16:35 | <Domenic> | hmm ok |
| 16:35 | <annevk> | Domenic: makes it much easier to search for important terms if you don't have to use \s+ all the time |
| 16:35 | <Domenic> | yeah fair |
| 16:44 | <Domenic> | TabAtkins: is there a way for anchors to provide alternate linking texts? https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md#providing-custom-definitions seems to imply no |
| 16:47 | <annevk> | Hmm, so the reason service workers exposing client closure is okay, is because they don't use message ports: https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0004.html |
| 16:48 | <annevk> | MessagePort is both super nice and super nasty |
| 16:48 | <TabAtkins> | Domenic: Provide multiple text: values under a single url:. |
| 16:48 | <Domenic> | TabAtkins: ah right of course, thanks |
| 17:25 | <Domenic> | annevk: hmm, cloning purposefully doesn't go through append an attribute, i.e. purposefully doesn't trigger mutation observers or similar? I wonder if it should trigger attributeChangedCallback... |
| 17:25 | <Domenic> | it seems like it should |
| 17:40 | <annevk> | Domenic: are you sure that's purposeful? |
| 17:40 | <Domenic> | annevk: not sure. Will probably be a thing to investigate after we finish this initial PR |
| 17:41 | <Domenic> | I guess it might not be observable currently |
| 17:41 | <Domenic> | since you can't run code during cloning |
| 17:41 | <Domenic> | so you can't set up a mutation observer or mutation event listener on the new element |
| 17:42 | <annevk> | I think Hixie_ did at some point have feedback that it needed to be atomic |
| 17:42 | <annevk> | As if the new element had all the attributes at once, just like the parser, but I've never really been able to figure out why |
| 17:45 | <Domenic> | annevk: OK I think it's just a wording bug actually. It says "Append copyAttribute to copy’s attribute list." But "Append" links to "append an attribute" which does the list-appending itself, plus the mutation record stuff |
| 17:45 | <Domenic> | So I'll just remove "'s attribute lits" |
| 17:46 | <Hixie_> | there's elements that do different things when their attributes are set vs when they are created |
| 17:46 | <Hixie_> | e.g. look at the crazy shit form elements do |
| 17:46 | <annevk> | Hixie_: ah, okay, I'll study those at some point |
| 17:47 | <Hixie_> | or img, e.g. consider what happens if you set src then set srcset then set crossorigin |
| 17:47 | <Hixie_> | vs setting them all at once |
| 17:47 | <Hixie_> | maybe img defers the load enough that it's not an issue |
| 17:47 | <Hixie_> | but in principle you see what i mean |
| 17:47 | <Hixie_> | i forget the details of which ones do it which way |
| 17:48 | <annevk> | Yeah, it's understandable and browsers do have an "allAttributesSetCallback" |
| 17:48 | <annevk> | So they can have created weirdness |
| 18:12 | <wanderview> | Domenic: annevk: does each document loaded in a window get a new environment settings object? so if doc 1 navigates to doc 2 in the same window, they get separate environment settings objects? |
| 18:13 | <annevk> | wanderview: no |
| 18:13 | <annevk> | wanderview: settings objects are 1:1 with globals |
| 18:14 | <wanderview> | and globals aren't created for each document? |
| 18:14 | <Domenic> | wanderview: I recently tried to clarify those things a bit: https://html.spec.whatwg.org/multipage/webappapis.html#global-object |
| 18:14 | <Domenic> | wanderview: globals are not 1:1 with documents, per the second note at https://html.spec.whatwg.org/multipage/browsers.html#browsing-context |
| 18:14 | <annevk> | wanderview: they mostly are, maybe you meant something else with window? Browsing context? |
| 18:16 | <wanderview> | I guess I am wondering if doc 1 navigates to doc 2 within a window... do you get a new browsing context |
| 18:16 | <wanderview> | the spec seems to say "if the browser is configured to" do that, then yes |
| 18:16 | <Domenic> | yeah, unless doc1 was the initial about:blank document |
| 18:16 | <Domenic> | oh wait |
| 18:17 | <Domenic> | you said browsing context not global |
| 18:17 | <Domenic> | so browsing context basically represents "a tab" |
| 18:17 | <Domenic> | it lives for a long time |
| 18:17 | <Domenic> | it's what things like session history and such are associated with |
| 18:17 | <wanderview> | well I really care about global... but I thought you said global was 1:1 to browsing context |
| 18:17 | <Domenic> | ah, no, sorry if we gave you that impression |
| 18:18 | <Domenic> | the answer to "do you get a new global" is "yes, except for the initial about:blank navigation" |
| 18:18 | <wanderview> | maybe I should just ask my real question |
| 18:18 | <wanderview> | this part of the SW spec: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-service-worker-client-id |
| 18:18 | <wanderview> | says to create a new unique value when the environment settings objects is created |
| 18:18 | <jwalden> | "Although typically objects cannot be accessed across origins, the web platform would not be true to itself if it did not have some legacy exceptions to that rule that the web depends upon." lol |
| 18:18 | <wanderview> | wtf does that mean for a window where you are navigating between documents |
| 18:19 | <Domenic> | wanderview: it means that on navigation, unless it is navigation from the initial about:blank, a new unique value/environment settings object will be created |
| 18:19 | <wanderview> | ok |
| 18:19 | <wanderview> | Domenic: thanks! |
| 18:19 | <Domenic> | \o/ |
| 18:20 | <Domenic> | i personally put the point at which i learned about the non-1:1ness of windows and documents as the point where my life started down a very different path |
| 18:21 | <wanderview> | Domenic: like the movie Pi? |
| 18:22 | <Domenic> | hmm, haven't seen that one |
| 18:25 | <wanderview> | http://www.imdb.com/title/tt0138704/?ref_=fn_al_tt_1 |
| 18:34 | <jwalden> | "Although WindowProxy is named as a "proxy", it does not do polymorphic dispatch on its target's internal methods as a real proxy would, due to a desire to reuse machinery between WindowProxy and Location objects. As long as the Window object remains an ordinary object this is unobservable and can be implemented either way." |
| 18:34 | <jwalden> | annevk: ^ what exactly is meant by "proxy" and "real proxy" and "as a real proxy would"? |
| 18:36 | <annevk> | jwalden: a "real" proxy supposedly would invoke _O_.[[GetPrototypeOf]] |
| 18:36 | <annevk> | jwalden: we use OrdinaryGetPrototypeOf(_O_) |
| 18:36 | <annevk> | jwalden: so code can be reused between WindowProxy and Location |
| 18:36 | <jwalden> | annevk: what is _O_ there? |
| 18:36 | <annevk> | jwalden: an object |
| 18:37 | <jwalden> | annevk: I'm still confused |
| 18:38 | <jwalden> | annevk: WindowProxy is an exotic object, and it has custom [[GetPrototypeOf]] and other internal method definitions: right, or wrong? |
| 18:38 | <annevk> | jwalden: it matters when the object being proxied is exotic, but since Window is not, it doesn't |
| 18:38 | <annevk> | jwalden: that's correct |
| 18:39 | <annevk> | jwalden: so sometimes WindowProxy invokes Ordinary* methods with the Window object, rather than invoking the [[*]] methods on the Window object |
| 18:39 | <annevk> | jwalden: because that allows WindowProxy and Location to share code |
| 18:40 | <annevk> | jwalden: I'd be happy to improve that sentence if you have suggestions btw, though file an issue at https://github.com/whatwg/html as I won't get to it now |
| 18:40 | <jwalden> | annevk: for my immediate purpose, simply knowing [[GetPrototypeOf]] isn't the ordinary definition is enough |
| 18:41 | <jwalden> | annevk: but I might take you up on that later, 'cause jorendorff and I are a bit confuzzled by the language as it is right now |
| 18:41 | <jwalden> | annevk: although bz is edumacating me on this as we speak, if I switch back to that IRC-tab |
| 18:41 | <jwalden> | so who knows whether anything *really* truly should be changed |
| 18:41 | <jwalden> | maybe |
| 18:41 | <annevk> | jwalden: the quote you gave is a note, so maybe just ignore that and see if the rest makes sense |
| 18:41 | <annevk> | jwalden: I do think Gecko as is has some bugs |
| 18:42 | <annevk> | jwalden: though I don't recall which |
| 18:43 | <jwalden> | I guess in my particular case, the global's immutable prototype chain means my particular question-to-answer is only a perf difference and nothing more |
| 18:43 | <jwalden> | (what I'm doing, is implementing Object.setPrototypeOf's aborting its loop to check for prototype chains, when an object with non-ordinary [[GetPrototypeOf]] is encountered) |
| 18:44 | <jwalden> | (but you can't have a cycle because of the immutability, so saying ordinary/not here just means you either abort the loop early, or you keep looping through the last several things on the chain) |
| 18:44 | <annevk> | is there an abstract operation defined for non-ordinary? |
| 18:44 | <annevk> | sounds a little magical |
| 18:45 | <jwalden> | annevk: basically this is all step 8c(i) in https://tc39.github.io/ecma262/#sec-ordinarysetprototypeof |
| 18:45 | <annevk> | also, if that's the same-origin issue leaking cross-origin stuff I didn't really follow that |
| 18:45 | <jwalden> | annevk: there isn't an abstract operation; there probably should be, but there isn't |
| 18:45 | <jwalden> | SpiderMonkey's going to implement it as an abstract operation, for sure |
| 18:46 | <annevk> | oh wow, some actual prose |
| 18:46 | <annevk> | interesting primitive |
| 18:46 | <jwalden> | annevk: the idea is objects without proxies on their prototype chains, will never have cyclic prototypes |
| 18:47 | <jwalden> | annevk: but once you can have a proxy on the chain, the potential for cycles (that can't be simply legislated away) is unavoidable |
| 18:47 | <jwalden> | var obj; var p = new Proxy({}, { getPrototypeOf() { return obj; } }); obj = Object.create(p); |
| 18:48 | <jwalden> | obj's prototype is |p|, |p|'s prototype when observed is |obj|, and you can't really prevent it any good way |
| 18:48 | <jwalden> | so non-cyclic is only enforced when the "ordinary" [[GetPrototypeOf]] is the only thing in sight |
| 20:23 | <rniwa> | Domenic: yt? |
| 20:25 | <Domenic> | rniwa: kinda, a meeting starts in 3 minutes |
| 20:26 | <rniwa> | Domenic: I commented on https://github.com/whatwg/dom/pull/204 |
| 20:26 | <rniwa> | Domenic: merging custom elements / shadow DOM into DOM / HTML will make it impossible for me to follow |
| 20:27 | <rniwa> | Domenic: can we at least update the existing doc to up to the point where we agreed yesterday? |
| 20:27 | <Domenic> | rniwa: why is that? custom elements is basically baked. (i agree on shadow dom) |
| 20:28 | <rniwa> | Domenic: not really. |
| 20:28 | <rniwa> | Domenic: we don't want type extensions |
| 20:28 | <Domenic> | rniwa: only updates left are the extended attribute thing, and patching the specs seems better than maintaining a giant list |
| 20:28 | <Domenic> | rniwa: sure, but you agreed that it's in the spec |
| 20:28 | <rniwa> | Domenic: we didn't. |
| 20:28 | <Domenic> | rniwa: you can ignore them just as well in dom/html as you can in custom elements |
| 20:29 | <rniwa> | Domenic: anyway, more practical matter is that it's going to be a lot harder to figure out what has changed since the last meeting |
| 20:29 | <Domenic> | rniwa: nothing has changed. |
| 20:29 | <rniwa> | Domenic: I mean last F2F |
| 20:29 | <Domenic> | rniwa: compare the custom elements spec to the DOM/HTML specs. |
| 20:29 | <rniwa> | Domenic: this whole bureaucracy between W3C and WHATWG is uttrly insane |
| 20:30 | <rniwa> | Domenic: I'm saying that's a lot harder because everything has moved around :( |
| 20:30 | <Domenic> | rniwa: I don't think this is about what organization. I think this is about upstreaming vs. maintaining a separate document full of monkeypatches. |
| 20:30 | <Domenic> | rniwa: sure, but it moved around when it was all in one document anyway |
| 20:30 | <rniwa> | Domenic: and I'm saying that we should maintain a separate document for now |
| 20:31 | <rniwa> | Domenic: otherwise, I don't think I can meaningfully give further feedback on the API |
| 20:31 | <rniwa> | Domenic: in any reasonable timeframe |
| 20:31 | <Domenic> | rniwa: OK, well, I am not interested in maintaining that document, especially since it's just an index of "please insert this sentence in this part of the other spec" |
| 20:31 | <Domenic> | gtg meeting, bbiab |
| 20:55 | <Domenic> | rniwa: back. I really don't think this is a big deal. What are your concrete concerns with putting things in the specs they're monkeypatching, instead of maintaining a monkeypatch document? |
| 20:55 | <Domenic> | rniwa: I agree that shadow DOM needs more time to bake, but custom elements is in good shape. |
| 20:55 | <rniwa> | Domenic: I'd like to see all the things related to custom elements in one place so that I can update the implementation in WebKit |
| 20:56 | <rniwa> | Domenic: if the thing you're working got merged, it's probably faster for me to just start from scratch than to try to update things. |
| 20:56 | <rniwa> | Domenic: because I'm going to miss something somewhere |
| 20:57 | <rniwa> | Domenic: or maybe I can find some colleague of mine who can figure that out. |
| 20:57 | <rniwa> | Domenic: but I'm really done dealing with all these W3C/WHATWG shenanigans |
| 20:57 | <Domenic> | rniwa: maybe it would help to note that https://rawgit.com/w3c/webcomponents/15a203c8393aef0df7223ab1d43406aa11a7e71e/spec/custom/index.html is still available. The only differences in the "upstream" patches are typo fixes and editorial stuff |
| 20:57 | <Domenic> | rniwa: you can follow any further revisions as they land (but as I said, I don't anticipate many) |
| 20:58 | <Domenic> | rniwa: again, I don't think this is about organizations. If we landed these in the DOM4/HTML5.1 forks it wouldn't change the nature of your complaint |
| 20:58 | <rniwa> | Domenic: and I'd object to that change. |
| 20:59 | <Domenic> | rniwa: I'm still trying to understand why. Because you're going to miss something somewhere? But how, since there's no changes to miss in the initial important, and subsequent changes are obvious commits in the commit history? |
| 20:59 | <Domenic> | rniwa: would it be helpful if we prefixed all custom elements related commits with "Custom elements:"? |
| 20:59 | <Domenic> | rniwa: I'd even be willing to email you every time I made such a commit if you're really concerned. |
| 20:59 | <rniwa> | Domenic: well, the thing is, I'm not going to look at every single commit |
| 21:00 | <rniwa> | Domenic: I'm going to look at the spec. |
| 21:00 | <Domenic> | rniwa: oh ok, great, then what's the issue? |
| 21:00 | <rniwa> | Domenic: but now the spec will be scattered across multiple places in DOM |
| 21:00 | <rniwa> | Domenic: and it's going to be the impossible for me to figure out which concepts, steps, and algorithms are relevant for custom elements |
| 21:01 | <Domenic> | rniwa: I think I have just the thing you for |
| 21:01 | <Domenic> | *for you |
| 21:01 | <Domenic> | one sec |
| 21:01 | <Domenic> | rniwa: http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fdom.spec.whatwg.org%2F&doc2=https%3A%2F%2Fraw.githubusercontent.com%2Fwhatwg%2Fdom%2Fcustom-elements%2Fdom.html perfect |
| 21:02 | <Domenic> | rniwa: same "all the patches are obvious" experience as before, one spec instead of monkeypatches. |
| 21:04 | <rniwa> | Domenic: well, but this diff is going to include all other DOM spec changes in the future, no? |
| 21:05 | <Domenic> | rniwa: nope! it's pegged to the custom elements changes. |
| 21:07 | <rniwa> | Domenic: so it'll show and only show all future custom elements changes? |
| 21:07 | <Domenic> | rniwa: yep! |
| 21:08 | <rniwa> | Domenic: oh, cool. this is great! |
| 21:08 | <Domenic> | yay \o/ |
| 21:08 | <Domenic> | i'll try to work on something similar for html, will be a bit tricky given htmldiff fails on singlepage but we can make it work |
| 21:09 | <Domenic> | easy first pass is just maintain a list of links to a few multipage diffs |
| 21:10 | <rniwa> | Domenic: yeah, diff on multi-page urls will be just fine |
| 21:11 | <rniwa> | Domenic: did we fix the problem that cross-section linking doesn't work in multi-page docs? |
| 21:12 | <Domenic> | rniwa: I made a slight correction to the diff URL to make it keep working after merge. I added the updated URL to https://github.com/whatwg/dom/wiki. |
| 21:12 | <Domenic> | rniwa: cross-section linking works, but the dfn popups do not work yet :( |
| 21:14 | <rniwa> | Domenic: that popup is what I was talking about |
| 21:15 | <Domenic> | rniwa: yeah :(. it's high priority on the tooling to-fix list, MikeSmith was looking into it a bit. |
| 21:16 | <MikeSmith> | ears burning |
| 21:16 | <MikeSmith> | ah |
| 21:16 | <MikeSmith> | yeah need to step back and re-think that really |
| 21:19 | <MikeSmith> | and I implemented cross-document linking for those popups previously, years ago, in the python splitter we were using at the time |
| 21:19 | <hober> | R.I.P. Anolis |
| 21:19 | <MikeSmith> | heh |
| 21:20 | <MikeSmith> | it worked then, what I made, but it increased the build time by 20 times or more |
| 21:20 | <hober> | :) |
| 21:20 | <MikeSmith> | so I think we really need to have something that doesn’t make a massive hit to build time |
| 21:22 | <Domenic> | hmm |
| 21:22 | <MikeSmith> | this would be a great project for a code contributor who wanted to help out with the effort |
| 21:22 | <Domenic> | ^ that sounds like a great way for something to not get done, sadly |
| 21:23 | <Domenic> | i would be ok with increased build times if you could turn off multipage generation during development |
| 21:23 | <MikeSmith> | OK yeah |
| 21:25 | <MikeSmith> | given how fast the build is and how carefully Hixie_ designed it to be that way, I would feel really bad about going in their and just tanking it naively |
| 21:26 | <MikeSmith> | anyway I need to make time to try it myself, to see if what I imagine might work |
| 21:28 | <MikeSmith> | I think users would be OK with a popup for a particular term taking some time to generate on the client side the first time they want to look at the refs for that term, if it gets cached on the client side after that |
| 21:29 | <MikeSmith> | I think a typical use case is that users only look at a few terms, but they look at those again and again |
| 21:30 | <MikeSmith> | at least that is the usage pattern I follow when I am trying to figure out something or trace something around the spec when I am using the popups to walk through it |
| 21:32 | <MikeSmith> | in other news I see we may be headed for some drama when getting the shadow-dom and custom-elements stuff folded into HTML and the DOM spec where it seems like everybody agrees they should end up |
| 21:33 | <MikeSmith> | well the people who care about getting it specified in the right way at least, instead of keeping the spec separate for non-technical reasons |
| 21:35 | <MikeSmith> | by which I don’t mean rniwa because I can totally understand his POV on this as an implementor |
| 21:36 | <MikeSmith> | rniwa: but if you think it’s premature to be moving those back to the HTML and DOM specs now, when would you imagine it would time? what would need to change before it was time for them to quit being separate monkeypatch specs |
| 21:38 | <rniwa> | MikeSmith: well, it looks like the diff Domenic sent me suffices my needs |
| 21:38 | <MikeSmith> | oh OK |
| 21:38 | <MikeSmith> | well I was just looking at your comment at https://github.com/whatwg/dom/pull/204#issuecomment-206545194 |
| 21:38 | <rniwa> | MikeSmith: my concern with monolithical spec is really about having to understand/read everything even if you're interested in a super small subset of it |
| 21:38 | <MikeSmith> | so you are saying you have changed your mind after chatting with Domenic |
| 21:38 | <MikeSmith> | OK |
| 21:39 | <rniwa> | MikeSmith: ya |
| 21:39 | <rniwa> | MikeSmith: not so much that I changed my mind. It's more that there was a solution to the problem I had |
| 21:39 | <hober> | rniwa: maybe drop a comment on that pull request to reflect that? |
| 21:39 | <rniwa> | MikeSmith: I would be still opposed if we didn't have http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fdom.spec.whatwg.org%2F&doc2=https%3A%2F%2Fraw.githubusercontent.com%2Fwhatwg%2Fdom%2Fcustom-elements%2Fdom.html |
| 21:39 | <MikeSmith> | k |
| 21:39 | <rniwa> | MikeSmith: just done that |
| 21:39 | <rniwa> | hober: ^ |
| 21:39 | <hober> | sweet |
| 21:39 | <hober> | thanks |
| 21:40 | <MikeSmith> | cool, thanks |
| 21:40 | <rniwa> | MikeSmith: I don't think making readers of the spec wait longer for the sake of shorter build time is a good tradeoff though |
| 21:41 | <rniwa> | MikeSmith: since most people are readers |
| 21:41 | <rniwa> | MikeSmith: we can probably build the cross-reference index separately asynchronously though |
| 21:41 | <MikeSmith> | bingo |
| 21:42 | <MikeSmith> | and yeah it is bad to make readers take the performance hit |
| 21:42 | <MikeSmith> | performance is a PITA |
| 21:42 | <MikeSmith> | Moore’s Law and such just need to move faster :) |
| 21:43 | <rniwa> | MikeSmith: soon, people will be complaining about how HTML5 spec won't load fast enough in their contact lenses LOL |
| 21:43 | <MikeSmith> | hahah |
| 21:45 | <MikeSmith> | honestly another concern any time I attempt a major coding project is just the fear of being laughed at and pointed at by y’all when you see the naiveté of my code |
| 21:47 | <Domenic> | aww <3 |
| 21:47 | <Domenic> | MikeSmith: FWIW the things I've seen you do with Bash have me in awe, or maybe a little terror. |
| 21:49 | <MikeSmith> | heh |
| 21:50 | <MikeSmith> | the secret to coding in bash is that you have to either pretend you’re under the influence of psychoactive chemicals, or to actually be under the influence of psychoactive chemicals |
| 21:51 | <MikeSmith> | or to just be psychotic |
| 21:52 | <hober> | MikeSmith: https://gottsusa.files.wordpress.com/2015/04/img_1364-bison-and-sign.jpg |
| 21:54 | <TabAtkins> | MikeSmith: Bikeshed was literally my intro "let's teach myself Python!" project. |
| 21:54 | <TabAtkins> | My skills have obviously gone up a ton in the process, but naive code is never a problem. ^_^ |
| 21:59 | <rniwa> | Domenic, annevk, hayato: fyi, anttik is implementing the correct display: contents semantics for slot element in https://bugs.webkit.org/show_bug.cgi?id=149439 |
| 22:00 | <Domenic> | rniwa: pretty exciting :) |
| 22:02 | <TabAtkins> | +1 |
| 22:04 | <MikeSmith> | hober: hey I think I have actually met those bison during some of my trips, back in my Tatanka Yotanka days. I think the reason they don’t want them doing psychoactive substances is that they start to talk some crazy talk and you can only understand it if you also are tripping |
| 22:04 | <MikeSmith> | TabAtkins: Bikeshed is a pretty impressive first Python project |
| 22:05 | <TabAtkins> | It was less impressive originally. Also, I'm a pretty good coder in general, and Python's not too dissimilar from JS, so a lot of my style knowledge could transfer over. |
| 22:09 | <MikeSmith> | TabAtkins: so I think you would love Free Pascal coding and I have just the project that would get you an opportunity for fun :) Free Pascal is pretty much just like Python and JS except for the places where it is not |
| 22:09 | <TabAtkins> | Noooope |
| 22:09 | <MikeSmith> | heh |
| 22:40 | <hober> | pascal was my second high level programming language, after basic |
| 22:48 | <TabAtkins> | I went TI-83 Basic => C++ => Java => Lisp => JS => Python |
| 22:48 | <TabAtkins> | Now I accidentally have a good working knowledge of Haskell due to reading papers. |
| 22:48 | <TabAtkins> | Oh sorry, PHP between Lisp and JS there. |
| 22:57 | <TabAtkins> | What's the name for the list of elements you can tab thru? |
| 23:00 | <jsbell> | TabAtkins: "control group" ? |
| 23:00 | <TabAtkins> | I'm just going for "tabbing through the document's focusable elements" |
| 23:01 | <jsbell> | "Each focusable area belongs to a single control group..." |
| 23:10 | <rniwa> | hayato: yt? |
