| 04:03 | <Cam Morales Silva> | Henllo. I'm expanding my knowlede in order to get my money back after being scamed :') help? I found this inspecting element on the website trying to get to the domain but I'm not so versed in this |
| 04:03 | <Cam Morales Silva> | I know for experience that I can get away with something like this |
| 05:52 | <DerekNonGeneric> | TabAtkins (or anyone who may know): are the old Web IDL spec stylesheets still accessible somewhere? |
| 05:57 | <TabAtkins> | DerekNonGeneric: yeah it's just the Bikeshed default stylesheet |
| 06:03 | <DerekNonGeneric> | TabAtkins: oh, yeah, they are indeed similar, but alas still no dark mode; was looking for the rest of this gist that i happened to save a while ago https://gist.github.com/DerekNonGeneric/e3072db4ea16cc64e138512a4a95bf56 |
| 06:15 | <TabAtkins> | Oh the dark-mode colors are inserted separately from the stylesheet itself. Look at any Bikeshed-generated spec, like the CSS specs, you'll find them. |
| 09:45 | <ntim> | Domenic: annevk : Hey, there was some agreement to remove <object usemap> from the spec, and I see the HTMLObjectElement doesn't have it anymore in the spec. However, it is still there in Gecko & Blink & WPT. |
| 09:45 | <ntim> | Is that intentional? |
| 10:42 | <annevk> | ntim: hmm, there was https://github.com/web-platform-tests/wpt/pull/27830 |
| 10:43 | <annevk> | ntim: Gecko has an open bug still |
| 12:04 | <AutomatedTester> | Morning all, I have a silly question about DocumentOrShadowRoot mixin in https://dom.spec.whatwg.org/#mixin-documentorshadowroot. If I have a shadow root, should I be able to use getElementByTagName since it's part of the mixin? |
| 12:27 | <annevk> | AutomatedTester: I don't see it on the mixin? |
| 12:28 | <annevk> | AutomatedTester: in particular, note how the mixin doesn't define any members (HTML defines some) |
| 12:29 | <AutomatedTester> | ok, I thought (probably wrongly) that when I saw DocumentOrShadowroot that I could use the APIs interchangeable |
| 12:31 | <AutomatedTester> | so, getElementsByTagName is not available then on a shadow root? |
| 12:32 | <annevk> | AutomatedTester: that is only defined on Document and Element, so no |
| 12:32 | <annevk> | AutomatedTester: I think you might have inverted the logic of mixins (or something to that effect) |
| 12:33 | <AutomatedTester> | probably :D |
| 12:41 | <AutomatedTester> | annevk: so to look inside the Shadow Root one would need to do something like document.get...().shadowRoot.host.get...() or something along those lines? |
| 12:43 | <annevk> | AutomatedTester: it has querySelector() and getElementById() |
| 12:43 | <annevk> | AutomatedTester: through DocumentFragment |
| 12:44 | <AutomatedTester> | ahhh ok |
| 12:44 | <AutomatedTester> | why is the API limited ? |
| 12:46 | <annevk> | I'm not sure I understand what you mean |
| 12:50 | <AutomatedTester> | Why are querySelector and getElementById but not the getElementsBy* APIs. |
| 12:51 | <AutomatedTester> | My reason for asking is people are using selenium for working with web components but in Chrome 96, they can’t search for element’s anymore by tag name |
| 12:51 | <AutomatedTester> | So want to understand the why so I can fix this properly |
| 13:00 | <annevk> | They were never included as they're kind of legacy APIs |
| 13:02 | <AutomatedTester> | Ok, thanks |
| 14:13 | <jschoi> | Have there been any web-API functions in the past that were later extended to accept more input types, instead of throwing errors? And if there have been any such functions, were there any web-compatibility and polyfilling problems? (I’m interested because of https://github.com/tc39/proposal-bigint-math/issues/17.) |
| 14:21 | <annevk> | jschoi: I think we've done that plenty of times, though coming up with examples is a little harder |
| 14:22 | <annevk> | jschoi: e.g., the types you can pass to XMLHttpRequest's send() increased over time |
| 14:22 | <annevk> | jschoi: the fallback there was stringification though, not throwing |
| 14:23 | <jschoi> | That’s similar, yeah. I’d love any more specific examples later if you or anyone else thinks of any; feel free to direct-message me or comment on that issue. |
| 14:23 | <jschoi> | Any Web Platform API function fn that originally threw a TypeError when given a certain value x but later was changed to not throw… |
| 14:24 | <annevk> | jschoi: addEventListener's third argument was overloaded with a dictionary, that was a bit contentious, but still the right call imo |
| 14:24 | <annevk> | jschoi: there too though I guess it didn't throw, since {} coerces to true |
| 14:26 | <jschoi> | Background: TC39 is considering doing something similar to some Math functions with BigInt inputs. Math.abs(-1n) currently throws a TypeError but this would extend it to return +1n. Math.max(0, 1n) would return 1n because 0 < 1n is valid. I have suspected that similar things have been done with web APIs plenty of times before, though of course I’d like to be able to give specific examples. |
| 14:28 | <annevk> | jschoi: all the path overloads in https://html.spec.whatwg.org/#canvasdrawpath are additions, but also changes the number of arguments |
| 14:29 | <jgraham> | I wonder if that's the sort of thing you can add a use counter for, to see if any sites are currently relying on bigints throwing there. Maybe js engines are too low-level to support use counters though. |
| 14:31 | <jschoi> | Telemetry data would be useful, but I struggle to think of a way in which throwing behavior would actually break something…Why would anyone already be supplying mixed Number/BigInt inputs to Math functions? And web APIs have done function-domain broadening before already, e.g., with those CanvasDrawPath extensions and XMLHttpRequest examples from annevk, without compatibility problems. But yeah. |
| 14:34 | <jgraham> | So I agree that in general this doesn't feel like it would be a very risky change. But experience suggests that it being hard to rationalise why someone might use a feature in a specific way doesn't mean that no one is depending on that behaviour in practice. |
| 14:35 | <jgraham> | Or to quote the /topic; "please leave your sense of logic at the door" :) |
| 14:36 | <annevk> | I don't think we ever really did that kind of study when the current behavior is an exception though |
| 14:36 | <annevk> | Removing exceptions has always been considered acceptable |
| 14:37 | <jschoi> | Yeah. Any more examples of removing exceptions would be super welcome. |
| 14:37 | <annevk> | That's also why we like to start out with throwing if we can |
| 14:53 | <jgraham> | Yeah, it's definitely less likely that people depend on throwing. But it's at least conceivable to write code that expects anything that worked with Math.abs() must be a Number and would try to do some other operation that doesn't make sense with a bigint. I also vaugely wonder if typecheckers dinstinguish the two and if this could change type inference in a way that would require code changes for users of those tools. |
| 14:53 | <jgraham> | (but again, I have the general sense this is probably not a very worrying change) |
| 15:00 | <jschoi> | Yeah, depending on throwing and type checking are understandable concerns. I guess the big thing is that these concerns aren’t unique to Math; they have happened plenty of times elsewhere in web platform APIs, and like Anne said removing throwing always been assumed to be compatible there. But telemetry could be useful. These are Google employees who have been raising these concerns on that issue, so if they wish they could do telemetry to confirm that nobody actually depends on the exception before rolling it out. That’s what they would do for any similar change to a web API anyway, right? (Telemetry data from Mozilla would also be welcome.) |
| 15:08 | <DerekNonGeneric> | top-level await used to be a syntax error |
| 15:10 | <DerekNonGeneric> | import assertions were also a syntax error |
| 15:11 | <DerekNonGeneric> | replacing errors w/ functionality seems to happen quite often |
| 15:24 | <jgraham> | I'd say that replacing "was a syntax error" with "not a syntax error" is safer than the equivalent with runtime errors. Although I'm fairly sure there are compat bugs relating to things that only succeed when a resource fails to load correctly, it's pretty rare for obvious reasons. |
| 15:38 | <DerekNonGeneric> | jschoi: these are the relevant runtime errors you should likely be concerned about https://www.npmjs.com/package/@openinf/util-errors#Classes |
| 15:43 | <jschoi> | DerekNonGeneric: Node throw TypeErrors with the ERR_INVALID_ARG_TYPE code if given Math.abs(0n), right? |
| 15:43 | <jschoi> | No, wait, only Node APIs do that… |
| 15:44 | <jschoi> | Anyways, I’m not sure how Node’s error codes would be relevant to extending Math functions (or web API functions, for that matter). |
| 15:45 | <jschoi> |
TypeScript and Flow both support union types, so such a change should not make users change their code. |
| 15:45 | <DerekNonGeneric> | Math is considered a "JavaScript core object", so the errors thrown are all the standard errors, which is fairly limited... |
| 15:54 | <DerekNonGeneric> | DerekNonGeneric: Node throw TypeErrors with the ERR_INVALID_ARG_TYPE code if given TypeError |
| 15:55 | <jschoi> | Yeah. So I think Node’s error codes are probably not relevant to this issue, in contrast to things like XMLHttpRequest’s send addEventListener, addEventListener’s third argument, and CanvasDrawPath’s path overloads. |
| 15:59 | <DerekNonGeneric> | perhaps not, but thought you'd be interested in seeing what Node's errors would be looking like (those are what the core developers use for Node APIs in case you were wondering) -- these errors pretty much map out all the possible value/type problems found in JS APIs (more sophisticated than Web APIs even) |
| 18:08 | <ntim> | annevk: Domenic : I'm referring to the IDL: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_object_element.idl;l=34?q=object_element.idl&ss=chromium |
| 18:09 | <ntim> | useMap shouldn't be there |
| 18:09 | <Domenic> | It should: https://html.spec.whatwg.org/#dom-object-usemap |
| 18:10 | <Domenic> | It's like all the other legacy content attributes like codeBase and codeType; still reflected in IDL attributes. |
| 18:11 | <ntim> | Domenic: ah thanks, urgh, I was looking at: https://html.spec.whatwg.org/#htmlobjectelement |
| 18:11 | <ntim> | which is why I was confused |
| 18:11 | <Domenic> | Yeah, the "// also has obsolete members" separation is perhaps not worth the potential confusion it causes... |
| 18:15 | <annevk> | I continue to favor a refactor whereby we have clear web developer and implementer sections for each element and fold all that stuff back in |
| 18:18 | <TabAtkins> | jschoi: CSS has done this sort of "previous invalid, now valid" addition a multitude of times. It's occasionally been problematic, but almost always fine. |
| 18:19 | <TabAtkins> | (The issues have largely been from when a property that previously only worked on a subset of elements started working on a new set as well; pages often accidentally over-apply properties, and if a property doesn't apply, that's not an error, so they just leave it in. Then the page's behavior changes when it starts being valid.) |
| 18:19 | <TabAtkins> | But when it's a noticeable error, as in the property fails to parse, but later it does, it's usually fine; exceptions have been rare. |
| 18:22 | <TabAtkins> | So this should be directly relevant to your case - if a method currently throws an error, but will stop doing so, it's likely to be fine. You can generally expect little to no upgrade pain, and when there is such a problem, it'll be a surprise anyway, so there's not much sense in fearing it. |
| 18:31 | <TabAtkins> | Relevant example of the opposite case is things like the aEL() "third argument becomes an option bag" case that annevk mentioned - it has the potential to change behavior that was previously valid (passing an arbitrary object, which'll get bool'd and treated as setting the "capture" option to true) into different behavior (passing an arbitrary object now invokes the option-bag behavior, which'll generally treat the "capture" option as false). |
| 18:33 | <jschoi> | Right, so the aEL change was even riskier in that passing an object bag did not originally throw an error. |
| 18:33 | <TabAtkins> | Yup. |
| 18:34 | <annevk> | The alternative on record was four arguments. Still happy we dodged that. |
| 18:35 | <TabAtkins> | Oh yeah, not saying it was a bad idea, just that it was risky, and the sort of thing that one should anticipate problems with. |
| 18:47 | <jschoi> | So this should be directly relevant to your case - if a method currently throws an error, but will stop doing so, it's likely to be fine. You can generally expect little to no upgrade pain, and when there is such a problem, it'll be a surprise anyway, so there's not much sense in fearing it. |
| 20:32 | <TabAtkins> | It's a low probability event, and likely not one you can anticipate ahead of time |