| 05:23 | <Maxim Vaarwel> | Create and initialize a Document object
Could anyone explain the meaning of these two lines? Why does the request case prevail over the response case? |
| 05:36 | <Domenic> | I think it is more, let url = hasRequest ? request's current url : fallback to response url since that's all we have. |
| 05:37 | <Domenic> | I think the network error case is a good example of when they would be different and request's would be more correct. |
| 05:40 | <annevk> | Luke Warlow: FWIW, I tend to agree with Domenic that mutually exclusive ReflectX attributes are nicer. Much easier to tell if someone made a mistake that way and also what something means. I.e., I'd rather see [ReflectURL] than [Reflect, ReflectURL]. |
| 05:42 | <Maxim Vaarwel> | Got it, but what about a network error, could you give an example? |
| 05:49 | <Domenic> | A network error is defined in the Fetch spec to be a response with very few properties set https://fetch.spec.whatwg.org/#concept-network-error. So if the response gets set to a network error, then it'd not be correct to set the resulting document's URL to the network error response's URL (which is left as the default of null). |
| 06:36 | <Vince Lam> | waz up |
| 06:51 | <Maxim Vaarwel> | You mean the case when the browser can't reach the page at the address and displays the page prepared by the engine. Yes, here it is clearly visible that In any case, the main question is closed. |
| 07:50 | <Noam Rosenthal> | Also in javascript: and other cases there is no request |
| 07:50 | <Noam Rosenthal> | See https://html.spec.whatwg.org/#the-javascript:-url-special-case:navigation-params-response The |
| 08:34 | <Luke Warlow> | Okay thanks for the feedback! I'll go with that approach then. |
| 12:38 | <Maxim Vaarwel> | Domenic: Hmm, wait. Why can't we just use navigationParams's response's URL without navigationParams's request's current URL?I mean why not let creationURL = navigationParams's response's URL?In most cases, navigationParams's response's URL is always present. Or is there some case I haven't noticed? Please tell me. |
| 12:43 | <Maxim Vaarwel> | Noam Rosenthal: coul you also look at my question above? |
| 12:48 | <Noam Rosenthal> | I don't remember the whole thing but IIRC if you respond to a request with a constructed response in a service worker, the request would have a URL but not the response |
| 12:54 | <Noam Rosenthal> | ... which would make it so that either the request or the response might be null and you want to start with the request before falling back to the response |
| 13:26 | <Maxim Vaarwel> | Noam Rosenthal: Thank you, the moment with the service worker in this case is quite interesting. I think I saw something like this when I was browsing the whatwg/html github before 2020 |
| 13:31 | <Domenic> | I gave you a very clear example above where response's URL would be incorrect, the network error case. I don't have more time to spend explaining it to you. |
| 15:03 | <Luke Warlow> | The shadowrootcustomelementregistry content attribute is defined as a boolean attribute but then the IDL is currently defined as a DOMString, is there a reason for this or is one incorrect? cc annevk |
| 16:26 | <annevk> | That was intentional to allow for changes. |
| 17:34 | <Luke Warlow> | Regarding the enumerated attribute reflection we run into an interesting case where the spec need and engine implementation need are quite distinct and I'm wondering how to (or even if we should) square that circle. Spec wise we just need something like [ReflectKnown] and [ReflectKnown=string] which triggers the limited to only known values case, because the actual definition is linked with the content attribute in the HTML spec prose. The [ReflectEnum=identifier] along with [MissingValueDefault], [InvalidValueDefault] and [EmptyValueDefault] are realistically purely implementation problems. Rather than spec ones. So the question is what should we do here? Having a unified approach across browsers would be nice but does adding spec stuff purely for implementation reasons make sense? Wondering if anyone has any thoughts on this? Should we perhaps just not handle this in the spec and browsers can do what they feel is best for that specific case? We still win by defining the rest imo. |
| 17:53 | <annevk> | Luke Warlow: it will at least obviate the need for the line in prose that says "x IDL reflects x content". There might also be some other benefits in acting as a forcing function towards more consistency. Because of how implementations do Reflect there have also been some mismatches in how things are implemented, though I don't recall the exact scenarios right now. Overall I think it's worth doing even if the benefits are modest and there is some increase in the amount of IDL boilerplate, as I think the uniformity will pay of eventually, but it might require some more iteration. |
| 18:02 | <Luke Warlow> | If we take the popover attribute for example it currently has The popover attribute is an enumerated attribute with the following keywords and states: | Keyword | State | Description | The attribute's missing value default is the No Popover state, and its invalid value default is the Manual state. The popover IDL attribute must reflect the popover attribute, limited to only known values. Only that last line is really deletable if we did a new [ReflectKnown], everything else is still needed. But browsers want that table + special states defined in IDL. We could do that but then we'd be duplicating which doesn't feel right necessarily. I guess the keyword definitions could be defined in the IDL enum and linked from the table so there's at least a reference between the two? |
| 18:15 | <annevk> | We don't have to define the invalid value default in prose either. |
| 18:17 | <annevk> | And some more restructuring might be possible if the table is no longer really for implementers. Although I suppose the mapping to states might continue being needed. Would have to see a bit more of the details. |
| 18:28 | <annevk> | AtkinsSJ: apologies for the delay on this, https://github.com/web-platform-tests/wpt/pull/53749 is now up |
| 18:29 | <annevk> | AtkinsSJ: if you could verify that'd be appreciated. All of this is extremely subtle unfortunately. |
| 18:35 | <AtkinsSJ> | annevk: Oh no need to apologise! I'll take a look tomorrow if that's OK. |
| 18:36 | <AtkinsSJ> | Thank you for your work on the spec, it's not for the faint of heart. 😆 |