| 06:33 | <freddy> | Very slightly related to import maps. I talked to someone about Subresource Integrity and they complained that <script src=.. integrity..> has no declarative fallback to a canonical/fallback URL if the src resource doesn't match. E.g., point to CDN for speed but fallback to same-origin resource for robustness. I recall that we cut fallbacksrc (name TBD) out of SRI v1 for a couple of reason. The main one I remember is that I was too cautious to break assumptions w/ HTML/XSS sanitizers and other security libraries. Essentially not allowing a "new" XSS vector like <script src=x integrity=x fallbacksrc=xssurl>. |
| 06:34 | <freddy> | I wonder if fallback-URLs would be an interesting thing to consider for import maps, as their syntax is not in HTML and less likely to break assumptions (because most libraries will block/remove inline <script>, likely including those of type import maps) |
| 11:20 | <Yoav Weiss> | freddy: I guess that could fit into importmaps somehow, but would only work for modules. At the same time, I'm not sure the use case is worth the complexity. Is this a real issue people are trying to solve for? Can they do that with e.g. onerror handlers that rewrite the src? |
| 11:20 | <freddy> | they can solve it with onerror handlers, but it requires more script |
| 11:20 | <freddy> | (script that needs to load first. stuff you originally set out to put on a CDN) |
| 11:35 | <Yoav Weiss> | (beyond that, I don't see the onerror event firing.. https://iron-organic-rainstorm.glitch.me/) |
| 12:08 | <freddy> | huh.. |
| 12:29 | <zcorpan> | Yoav Weiss: I think it should, step 4 in https://html.spec.whatwg.org/#execute-the-script-element , called from https://html.spec.whatwg.org/#script-processing-model:execute-the-script-element-3 |
| 12:30 | <zcorpan> | (or maybe not called from there, since it's parser inserted) |
| 12:31 | <zcorpan> | #parsing-main-incdata:execute-the-script-element |
| 12:36 | <zcorpan> | Yoav Weiss: you're not calling the functions :) |
| 12:38 | <zcorpan> | with onerror="errorHandler(event)" it wfm |
| 13:29 | <Yoav Weiss> | 🤦 |
| 16:34 | <govocin165> | Hi, I am wondering what is the rationale behind the difference between location.href and document.URL when credentials are embedded (e.g. https://foo:bar@example.com). Using the former would return an URl without credentials (http://example.com) and the latter would give me the full URL. My best guess here is that since Location object provides developers a way to navigate through links, there are security concerns and credentials need to be redacted. And since browsers treat Document as an abstraction for the current web document, the property is readonly and not redacted. Could someone kindly disprove or verify my theory? Thanks in advance! |
| 18:20 | <annevk> | Meo: that seems like a bug. They are defined to be identical. |
| 18:42 | <Meo> | Meo: that seems like a bug. They are defined to be identical. |
| 18:53 | <annevk> | Meo: I'd file a bug against Chrome (and other browsers that exhibit that behavior). Potentially if all browsers do this we need to investigate this at the specification level (file an issue against the HTML Standard for that), but it doesn't seem like something we'd want to standardize as it doesn't make a whole lot of sense. |
| 18:56 | <Meo> | Meo: that seems like a bug. They are defined to be identical. |
| 19:00 | <Meo> | Thanks! |
| 19:17 | <annevk> | Meo: https://html.spec.whatwg.org/multipage/nav-history-apis.html#concept-location-url (and then there's nothing in href's getter which states you can just omit parts of the URL) |
| 19:20 | <Meo> | Meo: https://html.spec.whatwg.org/multipage/nav-history-apis.html#concept-location-url (and then there's nothing in location.href should be the same as document.URL? If that's the case then almost all web browsers violated this spec. |
| 19:20 | <Meo> | From the multiple browser sources I read, Firefox implemented this redaction since pre-1.0 era. Chromium did it ~2010, and WebKit followed sometime later. |
| 19:43 | <Schalk Neethling> | Hey folks! I might have missed this in the spec, but it seems that all browsers will automatically show subtitles if the video element has a track with the default boolean attribute. Is this in the specification and I missed it, or is this not yet documented as the intended behaviour? Thanks! |
| 20:01 | <annevk> | Meo: I know about address bar redaction, but API redaction is new to me and would definitely have to be standardized somehow |
| 20:03 | <Meo> | Meo: I know about address bar redaction, but API redaction is new to me and would definitely have to be standardized somehow |