| 07:57 | <mkwst> | Does `TreatNullAs` have interesting behavior when combined with union types? For https://github.com/mikewest/trusted-types, I'd like to define some sort of union on top of `DOMString`, but the semantics for things like `innerHTML` are strange. :/ |
| 08:21 | <annevk> | mkwst: I thought TreatNullAs is obsolete now |
| 08:21 | <mkwst> | Obsolete except insofar as it's used on things like `innerHTML`. |
| 08:21 | <annevk> | mkwst: anyway, we should just make it means that passing null means passing "" |
| 08:22 | <annevk> | mkwst: I thought we have renamed it to [TreatNullAsEmptyString] without value |
| 08:22 | <mkwst> | https://heycam.github.io/webidl/#TreatNullAs *shrug* |
| 08:22 | <annevk> | Yeah, I saw |
| 08:23 | <annevk> | mkwst: ah, https://github.com/heycam/webidl/issues/350 |
| 08:23 | <annevk> | mkwst: anyway, I don't think it should be problematic with unions necessarily |
| 08:23 | <annevk> | mkwst: might just be a bug |
| 08:25 | <mkwst> | So the expected behavior for something like `(DOMString or Whatever)` with the `TreatNullAsEmptyString` attribute is that `null` would be accepted, treated as a `DOMString`, and converted to "" rather than "null"? |
| 08:25 | <mkwst> | I guess that's not clear to me from the spec, but I think it's the behavior I want. :) |
| 08:26 | <annevk> | Hmm, Worklet folks trying to get out of secure contexts |
| 08:27 | <annevk> | "CSS doesn't have X" So why don't you add X? |
| 08:27 | <annevk> | mkwst: yes |
| 08:28 | <annevk> | mkwst: I think you're right that IDL currently doesn't account for the union case |
| 08:30 | <annevk> | mkwst: maybe it does... |
| 08:31 | <annevk> | mkwst: https://heycam.github.io/webidl/#es-union has "includes a nullable type", which is https://heycam.github.io/webidl/#dfn-includes-a-nullable-type |
| 08:31 | <annevk> | mkwst: that talks about annotated types which is https://heycam.github.io/webidl/#annotated-types |
| 08:32 | <annevk> | mkwst: however, https://heycam.github.io/webidl/#TreatNullAs does not entirely make it clear that it becomes a nullable type due to this... |
| 08:32 | <mkwst> | annevk: That seems right. But the inner type is `DOMString`, which isn't nullable. |
| 08:32 | <mkwst> | Right. Seems like we could add something there to make it clear. |
| 08:32 | <mkwst> | (Though an example would be helpful as well, because I wouldn't have found that chain. :( ) |
| 08:33 | <annevk> | mkwst: I suspect we'd just want to special case TreatNullAs in "includes a nullable type", but worth an issue to see what other people say |
| 08:34 | <annevk> | mkwst: might also only want to fix this if we actually end up going with trusted types |
| 08:34 | <mkwst> | https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html "The group will raise this with TAG and get their recommendation." |
| 08:34 | <mkwst> | Who do we need to lean on to get the TAG to land dbarron's addition to the design doc? |
| 08:35 | <mkwst> | annevk: Yeah. And the type thing is all super hand-wavey and experimental at the moment, so I don't really want to push other specs to change until we actually know what we want to build. |
| 08:37 | <annevk> | mkwst: this seems minor enough indeed, but I'd like to see an HTML issue for things like this, just to give people a heads up and the ability to weigh in |
| 08:38 | <annevk> | mkwst: we might end up changing a bunch of your APIs six-twelve months down the road is good to know |
| 08:40 | <mkwst> | Sure. Filing a bug now. |
| 08:42 | <annevk> | mkwst: and I guess for the IDL thing I'd file an issue in trusted-types at least, so you know what is still outstanding |
| 08:45 | <mkwst> | Would you like a "Hey, look at this thing!" bug against HTML? Seems a little early for that... But I'm happy to file one if you'd find it helpful. |
| 08:48 | <annevk> | mkwst: I'd like it to be filed quite a while before the point is reached where it becomes hard to revisit the design |
| 08:49 | <mkwst> | Hrm. Ok. *shrug* Filing bugs is cheap. :) |
| 08:50 | <annevk> | mkwst: it's the modern equivalent of a heads up on a mailing list |
| 08:50 | <annevk> | mkwst: I don't really see another way of reaching the 200 folks who watch the HTML repository |
| 08:51 | <mkwst> | Sure. https://github.com/w3ctag/design-reviews/issues/198 certainly doesn't have the same reach. |
| 08:54 | <tobie> | mkwst: You can't use [TreatNullAs] on anything but a DOMString. |
| 08:54 | <mkwst> | tobie: You should talk with annevk, who just said I could. :) |
| 08:55 | <tobie> | mkwst: "The [TreatNullAs] extended attribute must not be associated with a type that is not DOMString." --https://heycam.github.io/webidl/#TreatNullAs |
| 08:58 | <annevk> | tobie: I think we can fix that if the need is compelling enough |
| 09:02 | <annevk> | mkwst: you might also want to chime in here: https://github.com/whatwg/dom/issues/150 |
| 09:02 | <annevk> | mkwst: it's losely connected to trusted types |
| 09:03 | <tobie> | mkwst: so re-reading the whole thread, it seems that what you want is simply: ([TreatNullAsEmptyString] DOMString or Whatever), where whatever CANNOT be a nullable type. |
| 09:03 | <tobie> | s/whatever/Whatever/ |
| 09:03 | <mkwst> | annevk: Yeah. I think it's talking about things a layer or so up from what I'm toying with at the moment. |
| 09:04 | <mkwst> | That is, whatever types we come up with could be jammed into/required in certain slots of a template. |
| 09:04 | <tobie> | mkwst: and you'll be covered by step 14 of https://heycam.github.io/webidl/#es-union |
| 09:05 | <mkwst> | Does that work? Like, I'm pretty sure it won't work in Chrome, but is it valid syntax in general? |
| 09:06 | <tobie> | mkwst: yes. these are annotated types. I think Chrome supports them now. Let me find the bug |
| 09:07 | <mkwst> | `third_party/WebKit/Source/core/dom/trustedtypes/TrustedHTML.idl(5) : error: Unexpected "[" after "("` :) |
| 09:07 | <mkwst> | Blink's bindings generation code is complicated. :( |
| 09:08 | <tobie> | mkwst: https://bugs.chromium.org/p/chromium/issues/detail?id=714866 |
| 09:09 | <mkwst> | Ok. Then they just haven't gotten around to making it work with union types. |
| 09:09 | <mkwst> | Which kinda makes sense, given the non-existant usage. |
| 09:12 | <mkwst> | Ugh. My workaround doesn't work, since we treat `undefined` and `null` the same for `?` but not for `TreatNullAs`. |
| 09:12 | <mkwst> | Is that something we could change? :) |
| 09:13 | <mkwst> | Like, make the first two tests in https://github.com/w3c/web-platform-tests/blob/master/domparsing/outerhtml-02.html have identical output? :) |
| 09:15 | <mkwst> | It's a bit strange that step 2 of https://heycam.github.io/webidl/#es-nullable-type treats `null` and `undefined` as interchangable, but `TreatNullAs` doesn't. |
| 09:19 | <tobie> | mkwst: I don't know the precise origins of TreatNullAs tbh, and I have no idea whether changing that behavior would be web compatible. |
| 09:19 | <mkwst> | Let's blindly assert that it would be, and change all the browsers today. |
| 09:19 | <annevk> | I'm pretty sure it was intentional that undefined becomes "undefined" |
| 09:19 | <annevk> | I also don't really see why we'd change that |
| 09:19 | <mkwst> | Eh. I'm sure it was intentional. I just find it strange. |
| 09:19 | <annevk> | That's not a good enough reason to change it |
| 09:20 | <annevk> | See topic |
| 09:20 | <mkwst> | Eh. |
| 09:28 | <tobie> | mkwst: I guess your other option is to lobby for a [TreatNullAndUndefinedAsEmptyString] extended attribute. |
| 09:29 | <tobie> | mkwst: I take cash and bitcoins |
| 09:29 | <mkwst> | Or to add metrics and prove that there would be basically zero impact to the web if we made the change. |
| 09:30 | <tobie> | mkwst: I guess it all depends whether you value time or money more. |
| 09:31 | <mkwst> | Do you take amex? |
| 09:33 | <tobie> | mkwst: no, traceable, + the fees are too high. |
| 09:34 | <mkwst> | Ethereum it is. |
| 09:34 | <tobie> | mkwst: frankly, I'd be surprised if this change was web-compatible, so yeah, that seems like your safest option. |
| 09:34 | <mkwst> | Who do you think expects `innerHTML = undefined` to result in `"undefined"` showing up on their page? |
| 09:35 | <mkwst> | Like, no one, right? :) |
| 09:36 | <annevk> | mkwst: that's the normal behavior for things taking strings |
| 09:36 | <annevk> | mkwst: that null turns into "" is weird |
| 09:37 | <annevk> | mkwst: so I'd expect most people familiar with JavaScript to expect that |
| 09:37 | <mkwst> | annevk: I think the fact that we have magical behavior for `null` would make folks less likely to expect non-magical behavior for `undefined`. |
| 09:37 | <mkwst> | Especially when we treat them the same for explicitly nullable types. |
| 09:39 | <tobie> | mkwst: I agree, but that doesn't really matter, does it. The question is whether changing this will break stuff or not, and whether all vendors will be happy to move ahead with that change. |
| 09:39 | <mkwst> | Sure. And in the grand scheme of things, my claim is both that this is trivial, and that we've made larger changes successfully. |
| 09:39 | <annevk> | mkwst: I really don't see why we'd change this perfectly interoperable behavior of a legacy feature that's best avoided |
| 09:40 | <mkwst> | annevk: I suppose "It would be simpler to work around Chrome's bindings generation code's foibles" isn't a good enough answer for you? :) |
| 09:41 | <mkwst> | *shrug* I don't particularly enjoy leaving my sense of logic at the door. |
| 09:41 | <mkwst> | Making small changes to smooth out the rough edges of the platform is good. |
| 09:41 | <annevk> | Causing churn to all other browsers to make things easier for Chrome plus taking a potential compat risk? No thanks |
| 09:42 | <annevk> | I disagree that this would smooth anything out |
| 09:42 | <annevk> | Just goes from ugly A to ugly B |
| 09:42 | <mkwst> | You don't think the distinction between nullable types and "TreatNullAs" is confusing? |
| 09:43 | <mkwst> | If ugly B is 5 ugly, and ugly A is 6 ugly, then it's an improvement. |
| 09:43 | <mkwst> | Obviously there are costs. |
| 09:43 | <mkwst> | Which is why I'm not just landing the change and walking out the door. :) |
| 09:46 | <annevk> | I don't think the distinction matters (I do think we need to have undefined-able types at some point, that cannot take null) |
| 10:21 | <TimothyGu> | mkwst: at this point I would suggest not using [TreatNullAs] at all for your new API |
| 10:22 | <TimothyGu> | instead just use (DOMString? or SomeObjectType) + prose "if value is null, set value to ''" |
| 10:22 | <mkwst> | TimothyGu: I don't want to use `TreatNullAs`. I want to override `innerHTML` to accept a specific type in addition to a `DOMString`. |
| 10:23 | <Domenic> | Catching up... I strongly agree that TreatNullAs is very bad and we should get rid of it, not propagate it to also treat undefined as. |
| 10:23 | <mkwst> | Yeah. The issue there is that `?` means that `undefined` will be stringified as `""`, not `"undefined"`. |
| 10:23 | <Domenic> | Stringification is stringification |
| 10:23 | <Domenic> | If you want to measure something to change, measure removing TreatNullAs so that null stringifies like everything else |
| 10:24 | <TimothyGu> | mkwst: well, just change the idl for innerHTML to stop using TreatNullAs |
| 10:24 | <mkwst> | TimothyGu: Thanks. That's helpful. :P |
| 10:24 | <mkwst> | Domenic: I'd be happy to remove it. One way of doing so would be to shift to `DOMString?`, and add in some prose about what to do with `null`, as TimothyGu suggested. |
| 10:25 | <Domenic> | Well... no... I meant the other thing... |
| 10:25 | <Domenic> | Just do DOMString like all other string attributes... |
| 10:25 | <mkwst> | That brings us back to the question of whether or not we'd treat the... what other thing? |
| 10:25 | <TimothyGu> | oh I see what the problem is about undefined... sorry for not understanding it out-of-hand |
| 10:26 | <mkwst> | Domenic: Ah. For things like `innerHTML` that might be viable? It might be less viable for various bits of CSSOM that use the attribute. |
| 10:26 | <mkwst> | I imagine passing `null` into `setProperty` might be more common than assigning `null` to `innerHTML`. |
| 10:27 | <mkwst> | But we'd need to measure either way. |
| 10:27 | <Domenic> | *shrug* I dunno, just saying that if we're making theoretically web-breaking changes, they all seem reasonably plausible to me and I'd much rather stringify uniformly than special-case more values |
| 10:35 | <mkwst> | I think my claim was that doing things to `undefined` was pretty unlikely to be a web-breaking change. But, in any event, numbers would be helpful before deciding how much effort to put into any change at all. |
| 10:40 | <Domenic> | I think special-casing undefined would be a step backward (going from 5 ugly to 6) |
| 11:51 | <zcorpan> | Domenic: i'm pretty sure web compat depends on innerHTML = null meaning innerHTML = "" |
| 12:25 | <tobie> | mkwst: what do you want me to do with what do you want me to do with https://github.com/heycam/webidl/issues/441. Can I close it? And you reopen something around the undefined behavior later on? |
| 14:03 | <mkwst> | tobie: If the type annotation is the right answer, great! It's not entirely clear to me that it does what you say it does, but you're deeper in the spec than I am, so I trust you! |
| 14:05 | <tobie> | mkwst: well, it is the right answer to the question the issue asks. I don't think it's the right answer to what you want to do, however. |
| 14:19 | <annevk> | JakeA: https://github.com/whatwg/fetch/pull/598 |
| 14:20 | <JakeA> | annevk: ta, will do this now |
| 21:49 | <timwis> | Hey folks, is there any effort behind server-side rendering of custom elements? I imagine without that, SEO can take a hit (things like <h1> are given more weight by search engines, and if they're hidden inside a <my-header>...unless google's synchronous JS execution will handle that?), and there can be a flash of unstyled/initialised content (or at least missing elements until initialised?) |
| 21:49 | <timwis> | I'm trying to share components between a Vue.js app and a WordPress site so we only need to maintain one library. |
| 21:50 | <timwis> | (for government, at standards.phila.gov if you're interested) |
| 22:16 | <MikeSmith> | howdy timwis |
| 22:16 | <MikeSmith> | no discussion about anything like that been going on as far as I know |