| 06:45 | <annevk> | wanderview: the issue Domenic opened and the ideas therein, so yeah, authority container, possibly combining it with policy container, as well as origin vs site aspects |
| 08:06 | <The Freelancer> | Hello everyone |
| 08:06 | <The Freelancer> | Wanted to ask one question that has been troubling me for a while? |
| 08:08 | <The Freelancer> | Back in the day, W3C had three divisions of the DOM spec. One was core DOM, the other was HTML DOM and the third was XML DOM. But when I go to the WHATWG spec, there is no mention of this distinction. My point is, that is this distinction still made in the specs of the DOM or can we now safely assume that there is no such distinction and that there is just one DOM spec. |
| 08:17 | <zcorpan> | The Freelancer: there's no XML DOM vs HTML DOM anymore, though the behavior of some APIs differ between HTML and XML. It's just the DOM spec, and some things that were previously in the "HTML DOM" spec is now in the HTML spec |
| 08:19 | <zcorpan> | e.g. createElement and createCDATASection |
| 08:50 | <The Freelancer> | zcorpan: So if some other vendor, or let's say a library author for another language such as Python, wants to implement the DOM, they have to go through the WHATWG spec. Is that right? But then how would that person be able to distinguish between what's really meant for HTML, what's meant for XML, and what's meant for both. I hope you get my point. |
| 08:51 | <zcorpan> | The Freelancer: if they don't support HTML, then they can no-op the parts that branch off of an HTML check |
| 08:52 | <The Freelancer> | Sorry, but I didn't get that. |
| 08:52 | <zcorpan> | Sorry, jargon :) no-op means no operation, meaning code that does nothing (or no code) |
| 08:53 | <zcorpan> | For example, when implementing https://dom.spec.whatwg.org/#dom-document-createelement , if "this" can never be an HTML document (because HTML is not supported), then you can skip step 2 |
| 08:55 | <The Freelancer> | Ok, so that means that any person wanting to implement the DOM for HTML or non-HTML documents has to nonetheless go through the whole document filtering out what he/she really needs? |
| 08:55 | <The Freelancer> | Am I right? |
| 08:55 | <zcorpan> | yes |
| 08:55 | <The Freelancer> | One more thing, sorry to disturb you again and again, what was the motivation behind unifying these three DOM specifications (i.e. HTML DOM, XML DOM, and Core DOM)? |
| 08:56 | <zcorpan> | Browser engines is the primary implementer for web specs, and they have a single implementation of the DOM, not 3 |
| 08:57 | <zcorpan> | It's easier to have a well-defined easy-to-implement spec if the behavior of an API is in one algorithm, instead of spread out across different documents |
| 08:57 | <The Freelancer> | That sounds relatable :) |
| 08:58 | <The Freelancer> | One last thing if you don't mind. May I? |
| 08:58 | <zcorpan> | don't ask to ask, just ask :) |
| 08:59 | <The Freelancer> | Thanks a lot. I don't find the style property in the WHATWG DOM standard. It's instead in the HTML standard. Why is this so? I guess that the style JavaScript property is also part of the DOM, then why does it get its place in the WHATWG HTML standard? |
| 09:02 | <zcorpan> | It's actually defined in CSSOM: https://www.w3.org/TR/cssom-1/#the-elementcssinlinestyle-mixin |
| 09:05 | <The Freelancer> | But it could've been defined in the DOM standard, couldn't it? There must be some reason, that I am unaware of, due to which it was given place in the CSSOM standard? |
| 09:06 | <zcorpan> | Yeah, but it would violate layering. Having HTML-specific things in DOM is also a layering violation, but HTML is less optional and more integrated. For the style attribute, DOM would have to put a dependency on CSS, HTML, SVG and MathML |
| 09:07 | <The Freelancer> | Alright. |
| 09:07 | <The Freelancer> | Can you elaborate this further : 'Having HTML-specific things in DOM is also a layering violation, but HTML is less optional and more integrated.' |
| 09:10 | <zcorpan> | Are you asking about what a layering violation is? |
| 09:10 | <The Freelancer> | Yeah. |
| 09:10 | <The Freelancer> | I think that it might be adding something where it ideally shouldn't be. Right? |
| 09:11 | <The Freelancer> | I guess that including the style attribute in the DOM standard would've required the DOM standard to define a lot of CSS-specific interfaces, which would've simply cluttered the spec. Is that so? |
| 09:12 | <zcorpan> | https://en.wikipedia.org/wiki/Multitier_architecture |
| 09:13 | <zcorpan> | The layering for the web is summarized in https://html.spec.whatwg.org/multipage/introduction.html#abstract |
| 09:15 | <The Freelancer> | So basically including HTML in the DOM standard is a violation, but it can't be avoided completely. Is that what you mean? |
| 09:15 | <Noam Rosenthal> | The Freelancer: the DOM standard can be used outside the context of HTML, it's an API to manipulate a document in general. You can see HTML as expanding it with browser features, and the CSS spec enhancing it even more |
| 09:16 | <Noam Rosenthal> | This python library, for example, is an implementation of DOM for reading XML documents and doesn't need to include anything from the HTML spec: https://docs.python.org/3/library/xml.dom.html#module-xml.dom |
| 09:16 | <The Freelancer> | Noam Rosenthal: when you say 'to manipulate a document' you mean an HTML or XML document, right? Or just about any document like docx, txt, etc.??? |
| 09:17 | <Noam Rosenthal> | The Freelancer: yes, HTML or XML document. |
| 09:17 | <The Freelancer> | Noam Rosenthal: Ok. |
| 09:17 | <zcorpan> | The Freelancer: right. There are sometimes benefits to layering violations |
| 09:18 | <The Freelancer> | zcorpan: Alright, I get it to a great extent. But one thing that's 100% clear to me now is that writing specifications and ramifying them as separate documents is a very challenging task. Like really really really difficult. |
| 09:19 | <The Freelancer> | One has to consider a lot of details before drafting specs. |
| 09:19 | <zcorpan> | true |
| 09:19 | <Noam Rosenthal> | The Freelancer: tell me about it :) I now have 5 open pull-requests for separate specs for the same feature because of cross-dependencies |
| 09:20 | <The Freelancer> | Noam Rosenthal: I get it :) It's really difficult. |
| 09:21 | <The Freelancer> | zcorpan and Noam Rosenthal thanks a lot for your time. |
| 09:21 | <zcorpan> | np |
| 09:22 | <The Freelancer> | I am leaving this chat with a sound amount of information. If ever in future I want to ask a question related to WHATWG standards, I now know the right forum to turn to. |
| 09:22 | <The Freelancer> | Thanks a lot. |
| 09:28 | <sideshowbarker> | PSA: I’ve mentioned here before that I wrote a tool which generates activity reports for GitHub repos somewhat like the Pulse thing in GitHub itself, but in a lot more detail. Today and yesterday I used it to generate and archive a bunch of reports for a bunch of different repos — including some WHATWG ones. The ones I generated so far are at https://git-pulse.github.io/reports/ |
| 09:29 | <sideshowbarker> | https://git-pulse.github.io/reports/whatwg-html-2022-06-15-pulse.html, for example |
| 09:31 | <sideshowbarker> | if there are any other repos that anybody would like to see reports for, either let me know and I can add them, or else you can run the tool yourself and open a PR to add the output |
| 11:13 | <amphitryon> | The HTML Standard says "The form element represents a hyperlink," but shouldn't that only be true when its method is GET or POST? |
| 11:13 | <amphitryon> | In something like <dialog open><form method=dialog><p>Text you need to acknowledge</p><button>OK</button></form></dialog>, I would not think that the form represents a hyperlink. |
| 11:14 | <amphitryon> | I guess it's complicated, though, since it could have a submit button with a formmethod attribute. |
| 12:58 | <annevk> | Luca Casonato: duplex = "half" | "full" is prolly what we want, c.f. https://en.wikipedia.org/wiki/Duplex_(telecommunications) |
| 12:59 | <Luca Casonato> | Yeah, that makes much more sense indeed |
| 13:01 | <annevk> | Luca Casonato: I think you'll have to explain how we're not already "half" due to blobs |
| 13:01 | <annevk> | Luca Casonato: because I strongly suspect that with a blob that results in some I/O error, browsers will reject the promise |
| 13:01 | <Yutaka Hirano> | If it's difficult to choose "half" as the default value, how about not choosing a default value? That means web developers always need to specify the option. |
| 13:02 | <annevk> | Yutaka Hirano: we can require it for streams, but I'm not sure how that helps with blobs |
| 13:03 | <Yutaka Hirano> | Yeah I'm talking about the case where body is a ReadableStream. |
| 13:08 | <Luca Casonato> | I guess you are right annevk. Arguably all of fetch is current half duplex, because a server could technically respond with response headers before we have finished sending the request body (even a large static request body), but we don't allow the Promise returned from fetch to complete until the entire request body is uploaded. In an ideal world, full duplex would allow the Promise returned from fetch to be only blocked on the response headers, never on the request body sending. |
| 13:10 | <Luca Casonato> | Deno does implement it this way, where the Promise returned from fetch is only blocked on response headers, and request sending happens in a separate parallel task. I would not be suprised if switching this behavior in browsers at some point would break compatibility, so we probably have to make full duplex opt-in. That's very unfortunate. |
| 13:10 | <Luca Casonato> | Especially because CFW and Deno already do full duplex by default. |
| 13:11 | <annevk> | Yeah, I would be okay with requiring duplex to be set for streams though as Yutaka suggested, to encourage some amount of thinking about it going forward. |
| 13:12 | <Luca Casonato> | Yeah, that would be reasonable. Deno and CFW would have a legacy interop issue where we'd default that to "duplex": "full", but I think that's not the end of the world. |
| 13:13 | <Luca Casonato> | If browsers are ok with no default for "duplex", and requiring "duplex": "half" to be set for ReadableStream bodies, I have no further concerns. |
| 13:17 | <Luca Casonato> | I will summarize & record this in the issue in a moment. |
| 13:19 | <annevk> | Luca Casonato: well, I guess we'd default it to "half" outside of streams, if we end up reflecting it on Request, which we might have to I suppose |
| 13:20 | <annevk> | Luca Casonato: I'm not sure it makes sense to have an "auto" value as the programming model is quite a bit different |
| 13:21 | <annevk> | Also, with "full" and blobs you end up not being able to detect upload failures I think, as long as we don't have FetchObserver |
| 13:25 | <annevk> | krosylight: happy b-day! 🎂🎉 |
| 13:27 | <Luca Casonato> |
That seems fine. I am 99% sure this will be non-breaking for us. I also agree, that no "auto" option is probably best. And yeah, "full" + blob has no way to detect upload failures. This is fine for us right now, because our blobs can never produce I/O errors right now. |
| 13:57 | <Domenic> | wanderview: the issue Domenic opened and the ideas therein, so yeah, authority container, possibly combining it with policy container, as well as origin vs site aspects |
| 15:09 | <annevk> | Domenic: what is unclear about it? |
| 15:32 | <wanderview> | what I don't understand is why security team would care about the structure of html spec... seems equivalent whether attributes are in an auth struct or passed individually as attributes on environment, etc... there doesn't seem to be a functional difference they would have an opinion about |
| 15:33 | <annevk> | wanderview: the people I tagged wrote the text on policy container and have a lot of experience with it |
| 15:35 | <annevk> | And also, fundamentally the spec is higher-level architecture and it's good to get that right, hence getting experts to review it |
| 15:52 | <krosylight> | Thank you 😊 |
| 17:49 | <Domenic> | Domenic: what is unclear about it? |
| 17:51 | <Domenic> | Like what is an "authority", is it just a renaming of "top-level site"? Why would you put that in a policy container? |