| 01:19 | <Domenic> | https://twitter.com/robpalmer2/status/1658914059578744835 made me think of a similar request I had seen for |
| 01:20 | <Domenic> | Is the advice in https://webidl.spec.whatwg.org/#idl-USVString that "Specifications should only use USVString for APIs that perform text processing .... When in doubt, use DOMString." still the state of the art? In cases where we expect most of the input to be text instead of 16-bit numbers, it feels like a recipe for subtle implementation bugs if an implementation round-trips a lone surrogate through UTF-8 instead of WTF-8. |
| 04:19 | <Jeffrey Yasskin> | The advice is state of the art. I don't understand your last point. Strings are 16-bit number collections from the JavaScript engine onward, so you're more likely to get subtle implementation bugs if you ignore that. |
| 04:24 | <Domenic> | I'm happy to live with it given that confirmation, but I'm thinking of the fact that while strings are 16-bit sequences in Javascript, Chrome's Mojo system (https://chromium.googlesource.com/chromium/src/+/master/mojo/public/tools/bindings/README.md#primitive-types) pretty implicitly translates them to UTF-8 on their way to the browser process. |
| 04:24 | <Jeffrey Yasskin> | :-D |
| 04:24 | <Domenic> | https://w3ctag.github.io/design-principles/#idl-string-types is a bit related |
| 04:24 | <Domenic> | "or operations which canβt handle surrogates in input (such as APIs that pass strings through to native platform APIs), USVString should be used" |
| 04:25 | <Domenic> | But I don't think that everything-Mojo is the intent of the "native platform APIs" clause |
| 04:25 | <Domenic> | It's more meant, like, displaying in a Window title bar or something |
| 04:26 | <Jeffrey Yasskin> | Yeah. And Gecko + WebKit might be more consistent about keeping things in UTF-16, so they would be affected in different circumstances. |
| 04:26 | <Jeffrey Yasskin> | I did notice that URL uses USVString, when the guidance would seem to imply DOMString. |
| 04:27 | <Domenic> | URL uses USVString because percent encoding |
| 04:28 | <Domenic> | Note also CSS just kinda decided not to do interop because it was more convenient for Gecko to use USVStrings in Stylo. And nothing has blown up yet... |
| 04:29 | <Domenic> | (Search for "CSSOMString") |
| 04:30 | <Jeffrey Yasskin> | π± |
| 04:31 | <Jeffrey Yasskin> | But yeah, I wouldn't expect this to be web-visible in most cases unless someone finds a way to use it maliciously. |
| 06:38 | <Domenic> | annevk or Dominic Farolino or anyone: some help appreciated on https://github.com/whatwg/html/issues/9310 , I feel like I'm going crazy |
| 07:34 | <annevk> | Domenic: I see the same thing in Gecko, but not WebKit |
| 07:34 | <Domenic> | Oh nooooo |
| 07:34 | <Domenic> | How is this possibly non-interoperable... |
| 07:35 | <annevk> | Probably poorly tested. |
| 07:35 | <Domenic> | Like you do let w = window.open(); w.document.innerHTML = "<img src='foo.jpg'>" and this only loads in WebKit? Really!? |
| 07:36 | <Domenic> | OK well now that I know it's an interop problem, I'll approach it differently, with test cases and such... on Monday. |
| 07:39 | <annevk> | Yeah that works (with document.body.innerHTML), though when the popup is blocked it might fail, but that's expected I think |
| 07:39 | <annevk> | I wouldn't be terribly sad to see it go |
| 13:45 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...%3Cscript%20type%3D%22text%2Fjavascript%E3%80%80%22%3E%0Aw(1)%0A%3C%2Fscript%3E hmmmmm |
| 16:59 | <Ehsan Azari> | Hi all It would be useful for handling cases where an element is dynamically removed and inserted back into the DOM, for instance, when navigating between different views or performing dynamic updates. So, I decided share it with you all, I think it would be useful in some areas, including virtualization techniques |
| 17:41 | <Burt Paulie> | Anyone out there in the WHATWG world have experience working with the backend of HTML and CSS? |
| 17:49 | <Dominic Farolino> | HTML has an example showing that you must not resolve a promise in parallel. Does that also imply you cannot resolve a Promise from another Window event loop other than the one it was created in? |
| 17:53 | <Andreu Botella> | if the windows don't share an event loop, no |
| 17:53 | <Andreu Botella> | you'd have to queue a task in the promise's window's event loop |
| 17:55 | <Burt Paulie> | I'd like to understand in greater detail the process whereby HTML and CSS are implemented between the machine code and the kernel (preferably Linux). Can anyone point me towards the binaries for the HTML Standard? If there's a way for me to return them in a Linux terminal or a Code Editor, I'm all ears. Thanky kindly... |
| 18:04 | <Ehsan Azari> | HTML has an example showing that you must not resolve a promise in parallel. Does that also imply you cannot resolve a Promise from another Window event loop other than the one it was created in? resolve and reject functions of a Promise at the same time or in rapid succession. That's it |
| 18:06 | <Andreu Botella> | In JS you don't have access to a promise's resolve and reject from a different thread, whereas in the spec text, or when implementing browser code, you do. That's what "parallel" means in the standards. |
| 18:07 | <Andreu Botella> | And JS is single-threaded, and so is the implementation of JS in every engine; if you try to resolve a promise off-thread in browser code, you're likely to run into concurrency issues |
| 18:09 | <TabAtkins> | Ehsan Azari: that's very much not correct. "In parallel" is a spec-language term of art, which algorithms can invoke to mean "do this, potentially in another thread; we promise not to do user-observable things here so timing isn't made visible". |
| 18:10 | <TabAtkins> | Dominic Farolino: You can, you just have to do it via posting a task to the Promise's own event loop, same as you have to do when you're inside a parallel section. |
| 18:20 | <Andreu Botella> | Okay, so the HTML, CSS, etc. standards are human-readable (or, well, engineer-readable; there's a difference π ) descriptions of the behavior that has to happen. They're not compiled to binary (except for small machine-readable parts like WebIDL). |
| 18:20 | <Andreu Botella> | There are programs called web browsers (like Google Chrome, Firefox, Safari...) that are made up of code that implements those descriptions |
| 18:22 | <Andreu Botella> | Chrome and Firefox are open source, so you can browse the code β although be warned that it's a lot of code. Safari isn't open source, but the part of it that actually does most of the HTML and CSS work (the browser engine) is, it's called Webkit |
| 18:28 | <Burt Paulie> | What I'd like to know is how each individual tag is defined for machine processing. I don't want the human (or engineer) readable standard common to most coders, I want to see the binaries processed by the machine for the implementation of each and every tag of the current (or minimally any) HTML Standard. In other words, I'd like to know how to reverse engineer the HTML language... |
| 18:31 | <Andreu Botella> | HTML doesn't get compiled into machine code, if that's what you're thinking |
| 18:32 | <Burt Paulie> | So how was it written? |
| 18:33 | <Andreu Botella> | A browser is written in a compiled language (C++ usually), and it parses HTML, builds an in-memory representation of the structure of a document (which you can then change using javascript), and then uses CSS to apply rules to eventually render it |
| 18:33 | <Burt Paulie> | Sir, I know for a fact that you are lying to me... |
| 18:34 | <Burt Paulie> | The HTML absolutely must call some binary relative to the display of whatever display elements it defines... |
| 18:34 | <Burt Paulie> | It's an absolutely true proposition... |
| 18:35 | <Burt Paulie> | I couldn't compile a Post Table without them... |
| 19:08 | <Ehsan Azari> | What I'd like to know is how each individual tag is defined for machine processing. I don't want the human (or engineer) readable standard common to most coders, I want to see the binaries processed by the machine for the implementation of each and every tag of the current (or minimally any) HTML Standard. In other words, I'd like to know how to reverse engineer the HTML language... Some are w |
| 19:10 | <Ehsan Azari> | Or you're talking about BNF or things like that? https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form |
| 19:19 | <Burt Paulie> | Both suggestions have relevance to the context, and thanks for references by the way!! I'll give them a once over here and put them in a bookmark file for now... |
| 19:22 | <Burt Paulie> | I will say though, that however tedious it sounds, I would like to know exactly what languages and environments were used to author the HTML language itself, so that if I wanted to reverse engineer the thing, I could do so by buying whatever support I needed and plugging in every last piece of syntax by hand... |
| 19:23 | <Burt Paulie> | The Web IDL Standard looks like something worthwhile for me to become (at least cursorily) familiar. Thanks for that... |
| 19:29 | <Burt Paulie> | The Backus-Naur thing looks like a generic grammar for defining the implications of human-readable punctuation and meta-language. More of a sound byte from a lazy afternoon than a specification requiring precision. IOW - I could fake it myself... |
| 19:44 | <TabAtkins> | If you're interested specifically in how browsers parse CSS, check https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/parser/;bpv=1;bpt=0 (for Chrome) or https://github.com/servo/rust-cssparser/tree/master (for Firefox). |
| 19:44 | <TabAtkins> | HTML parsers are elsewhere in the codebases, I just happened to already have those tabs open. |
| 19:45 | <TabAtkins> | Beyond simple parsing, the behavior of each HTML element or CSS property/etc is a much larger chunk of the code. |
| 19:46 | <TabAtkins> | But the specs (generally) describe the same behavior, just in a more readable form. Looking at the code can be interesting if you're wanting to write your own, but it's a huge complicated beast. |
| 20:18 | <Burt Paulie> | I believe you when you tell me that understanding the behavior of parsers is important to how HTML is processed and served. And indeed, knowing how any of our more popular front-end browser engines handle languages like HTML when it is served to computer terminals around the world would be important to creating language standards that interoperate without crashing local machines or blocking regularly. What I am looking for however (which I think you understand to some extent) is not an abstraction. I'd like real word steps. Who can I go to? What can I read about? Which editors or languages should I learn? If I want to author a formal computer language comparable to HTML, how do I begin? For example, is there some company or industrial center (WHATWG or otherwise) where a student can book a tour to learn about this sort of thing? Is there a special editor that shows people the native process whereby an HTML tag can be written, even if it is only within the context of a single, local machine? If I were to attempt to author a language using the assembly specifications for a single type of computer and it's processor, what would it take to gain access to a machine in such a raw state of unprogrammed receptivity? If I built a custom machine, how deeply would I have to strip its operating system to watch myself invent the tags that served typographical elements in more well-manicured contexts? |
| 20:21 | <Burt Paulie> | Once again, I'd like to author either an HTML-like language that solves the bidirectional problem, or invent a plug-in module that evolves the HTML versioning process until raw bidirectional functions are standardized and Left-To-Right (LTR) service of hypertext is no longer the rule. It will certainly take several decades, but if I don't start now, that period only grows longer by the minute... |
| 20:50 | <TabAtkins> | You are asking questions at the wrong level of abstraction, as others have said. It sounds like you think HTML is somehow implemented "directly" in code, and browsers just use that? That's not the case. Browsers load a page, they parse the page's text as HTML, they build a DOM from the parsing results, they display the DOM on the screen according to CSS's rules and react to user input; the entire thing is a complex multi-stage process. The actual "HTML" part is either a very small portion of this (if you're talking about HTML as a language, it's just the parser), or it's woven thruout the entire browser in complex ways (if you're talking about all the behaviors and interactions of how a webpage is displayed). |
| 20:51 | <TabAtkins> | But specifically about bidi, HTML already supports rtl and mixed (bidi) text just fine. In some aspects it defaults to laying out in a LTR manner, since the web was first created with english/european text and many things depended on that, but generally speaking rtl text and layouts work just fine. |
| 20:56 | <TabAtkins> | If you want to know how create a language that looks like HTML, read the HTML parsing spec (https://html.spec.whatwg.org/multipage/#toc-syntax). If you want to know how to create a web browser, with all that entails, you'll need to read a whole lot more. If you just want to suggest a new feature, search for details about that feature or related things to see if it has already been discussed, and maybe even already solved. If you think there is a missing ability that hasn't already been talked about, read https://whatwg.org/faq#adding-new-features for how new features are proposed. |
| 20:58 | <Andreu Botella> | If you want to get a feel for what how browsers are put together and what making a browser is like, I suggest https://browser.engineering/ |