Options:
Previous day, Next day
- # Session Start: Sat Sep 19 00:00:00 2015
- # Session Ident: #html-wg
- # [01:25] <gsnedders> AAA_awright: the non-web DOM impls are almost uniformly a /long/ way off interoperable with both specs and browsers
- # [01:26] <gsnedders> AAA_awright: and most of them won't change because of backwards compat in their own eco-systems…
- # [01:29] <AAA_awright> Mhm
- # [01:29] <AAA_awright> gsnedders: I don't see it mattering too much because they're entirely different languages typically
- # [01:31] <gsnedders> AAA_awright: also most of them have shown no interest in anything new in the DOM in years, so is it worthwhile making the new specs more ambiguous for those who are actually likely to implement them? certainly WebIDL has gone a long way at helping theoretical portability, but even the Java mapping has been dropped because nobody was actually interested in it
- # [01:31] <gsnedders> AAA_awright: I don't think it's worthwhile keeping stuff agnostic for non-JS impls if no non-JS implementer cares about it
- # [01:33] <AAA_awright> Well, and it's not just languages. Many on the Web Apps WG seem to think browsers are the only kind of user agent in existence
- # [01:33] <gsnedders> I don't think that's true. I think many think that web developers will code to what browsers implement, regardless of other UAs.
- # [01:33] <AAA_awright> HTML seems to have these issues too... if less so there's a whole section on how to deal with non-HTML documents. In HTML. I don't get it.
- # [01:38] <AAA_awright> I can provide additional examples when I run into them, I forget off the top of my head... But for instance, in the work of the RDF Javascript Libraries CG, most of the implementation is outside actual browsers
- # [01:39] <gsnedders> the entirely of the page loading, etc., stuff seems like it should be easy to split out… except then it turns out that so much web content relies on so much low-level detail of how it very tightly interacts with HTML that it's insane and likely impossible to change how tightly interconnected the specs practically have to be :(
- # [01:39] <AAA_awright> Oh, the history API? What if I'm inside an SVG document, I should normatively have access to history there, too
- # [01:41] <gsnedders> Agreed.
- # [01:43] <gsnedders> it'd be nice to try and split the Window object out again, but that just might end up so heavily cross-referenced that it's unclear how much is gained
- # [01:46] <AAA_awright> In my understanding, there's not much you need to do. window is the global object, anything not specified as NoInterfaceObject will populate that object. Just move out all the things relating to logic to a separate document.
- # [01:47] <gsnedders> It depends how much you want to include with it, really.
- # [01:47] <gsnedders> If you want to include History, for example, you then start needing definitions of browsing contexts so you have a definition of what does and does not create a history item
- # [01:49] <AAA_awright> I'd spec out the Web platform like this: HTTP, XML, DOM, text/html (the syntax), HTML (the vocabulary), CSS (how to visually render a DOM), HTML DOM definitions, CSS OM, User-agent primitives, other scripting stuff as needed...
- # [01:49] <gsnedders> And then there's the "navigating a document" stuff with all the special cases for javascript: and about:blank which are just evil, but likely impossible to get rid of
- # [01:50] <gsnedders> AAA_awright: the problem is the syntax depends on the definition of things like document.open and document.write, and script queues, etc.
- # [01:50] <gsnedders> It'd be nice to have a nice clean separation, but that's not what we have :(
- # [01:51] <AAA_awright> You can abstractly hook that out. "When a script tag is encountered: Attempt to evaluate the contents, and pass along a reference to the current DOM so it can be modified by the script"
- # [01:51] <gsnedders> AAA_awright: except it's not that simple
- # [01:52] <AAA_awright> That's roughly how I recall reading it in the HTML TR
- # [01:52] <gsnedders> AAA_awright: <script>document.write("<script>document.write('<script>…</script>')<\/script>")</script> starts to get interesting
- # [01:52] <gsnedders> AAA_awright: which is what the spec uses "pending scripts" and "script nesting level" and such like for
- # [01:53] <gsnedders> AAA_awright: which affect parsing
- # [01:56] <AAA_awright> gsnedders: While we're on the topic of quirks, that's going to result in a parse error because the first </script> isn't escaped
- # [01:57] <AAA_awright> If browsers can drop e.g. xml:base and MathML because they're not used, can't we just drop "script nesting level"
- # [01:57] <AAA_awright> (idk)
- # [01:57] <gsnedders> AAA_awright: nah, this stuff is relied on all over the place :(
- # [01:59] <gsnedders> AAA_awright: the horrible reality is the most interwound, horrible stuff, is what's hardest to get rid of :(
- # [02:05] <AAA_awright> I'm not finding any good reason this can't slowly be pried apart
- # [02:06] <AAA_awright> HTML parsing has nothing to do with script execution, you can still look at a DOM and say "alright, now render this"
- # [02:07] <AAA_awright> (having not executed any scripts up to that point)
- # [02:07] <AAA_awright> Which is necessary to support anyways, there's plenty of applications that don't execute scripts, like mail clients. Indeed HTML defines <noscript/>
- # [02:15] <gsnedders> AAA_awright: it has to define at the very least what scripts run synchronously, what scripts run when during parsing, where exactly content from document.write ends up, what document.open does to the pre-existing DOM and where content that follows the script element ends up…
- # [02:15] <gsnedders> the scripting disabled case is easy, certainly
- # [02:22] <AAA_awright> A theoretical "Scripting evaluation" document could do that... Given a DOM (which may or may not be completely parsed at the time this process begins), execute the scripts inside it. It would also define the nature of the event loop, etc.
- # [02:22] <AAA_awright> What will convince me otherwise is some proof that scripting must be inherently tied to HTML syntax parsing
- # [04:27] * Quits: hgl (~hgl@public.cloak) ("Quit")
- # [04:41] * Joins: hgl (~hgl@public.cloak)
- # [06:18] * Quits: MikeSmith (~MikeSmith@public.cloak) (Ping timeout: 180 seconds)
- # [06:52] * Joins: MikeSmith (~MikeSmith@public.cloak)
- # [07:03] * Quits: dustinm (~dustinm@public.cloak) ("Leaving")
- # [07:09] * Quits: hgl (~hgl@public.cloak) (hgl)
- # [07:10] * Joins: hgl (~hgl@public.cloak)
- # [07:15] * Joins: dustinm (~dustinm@public.cloak)
- # [10:33] * Joins: iandevlin (~iandevlin@public.cloak)
- # [15:13] * Quits: iandevlin (~iandevlin@public.cloak) (Ping timeout: 180 seconds)
- # [15:16] * Joins: iandevlin (~iandevlin@public.cloak)
- # [18:00] * Quits: iandevlin (~iandevlin@public.cloak) (Ping timeout: 180 seconds)
- # [18:40] * Quits: hgl (~hgl@public.cloak) (Ping timeout: 180 seconds)
- # [18:42] * Joins: hgl (~hgl@public.cloak)
- # Session Close: Sun Sep 20 00:00:00 2015
Previous day, Next day
Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn