| 00:03 | <t3oss> | on w3c websites tables are used for layout :S |
| 00:03 | <t3oss> | you know? |
| 00:10 | <zewt> | ffff why does chrome have pdf support with form support that doesn't work, so I fill out a form and then have to ... save as and do it all again |
| 00:11 | <zewt> | bonus points for not being able to copy text from text fields |
| 11:25 | <annevk> | Hah, I thought http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn was about the URL standard initially. But it's about standards not tampering with the URL value space, which makes perfect sense. |
| 11:33 | <SimonSapin> | annevk: do you mean like having /robot.txt in a standard is bad? |
| 11:33 | <annevk> | I forgot about those. |
| 11:34 | <SimonSapin> | or /.well-known/browserid |
| 16:17 | <dglazkov> | good morning, Whatwg! |
| 18:43 | <bholley> | Hixie: yt? |
| 18:43 | <Hixie> | yo |
| 18:44 | <bholley> | Hixie: is there ever a situation in which the spec requires us to know the exact entry script, or is it really just tracking the entry global? |
| 18:44 | <bholley> | Hixie: I'm looking into implementing a proper script entry point stack in Gecko |
| 18:44 | <bholley> | Hixie: and it looks easier to just to keep a stack of globals |
| 18:44 | <bholley> | Hixie: rather than script objects |
| 18:44 | <Hixie> | global meaning the Window object? |
| 18:44 | <bholley> | Hixie: for ownership reasons |
| 18:44 | <bholley> | Hixie: yes |
| 18:45 | <Hixie> | you have to know the base URL of the entry script sometimes |
| 18:45 | <Hixie> | and the referrer source |
| 18:45 | <bholley> | Hixie: and that can be different from the document? |
| 18:45 | <Hixie> | interesting question |
| 18:46 | <bholley> | Hixie: if the script comes from jquery.com, do you need to know jquery.com's base URI, or the document's base URI? |
| 18:46 | <Hixie> | hmmmm |
| 18:47 | bholley | would guess the latter |
| 18:47 | <Hixie> | i think if i'm reading the spec right the base URL for an event handler could be different if that element has an xml:base? |
| 18:47 | <Hixie> | but i've no idea if that's realistic or not |
| 18:47 | bholley | doesn't know a darn thing about xml |
| 18:47 | <Hixie> | oh, no, nevermind |
| 18:47 | <Hixie> | xml:base isn't xml |
| 18:47 | <Hixie> | it's <base> on a per-element basis |
| 18:48 | <bholley> | "The xml:base attribute (XML only)" |
| 18:48 | <Hixie> | i think you're probably safe to use the global, and the global's document |
| 18:48 | <Hixie> | "XML only" there only refers to authoring conformance criteria |
| 18:48 | <bholley> | ah |
| 18:48 | <bholley> | Hixie: ok. In that case, do you think it makes sense to update the spec to talk about entry Windows? |
| 18:49 | <bholley> | Hixie: bz would like it to be the case if that's what we implement |
| 18:49 | <Hixie> | well, it's more complicated than that due to workers |
| 18:49 | <Hixie> | but it would make sense to have "script's base URL" and so forth defined relative to a single object |
| 18:50 | <Hixie> | rather than relative to each script |
| 18:50 | <Hixie> | wouldn't be a high priority for me to change, though, given the risk level, since it would be purely editorial |
| 18:50 | <bholley> | Hixie: because workers don't have a Window? |
| 18:50 | <Hixie> | yeah |
| 18:50 | <bholley> | Hixie: what about "entry global"? |
| 18:51 | <Hixie> | well, you have to worry about what the "script's document" is sometimes |
| 18:51 | <Hixie> | which gets especially tricky with dedicated workers created from shared workers, etc |
| 18:52 | <Hixie> | let's see |
| 18:52 | <bholley> | Hixie: I'm happy to file a spec bug, implement it with globals in Gecko, and let you know how it goes, assuming you're eventually open to changing the spec |
| 18:52 | <Hixie> | all these things are always set via the "Create a script" algorithm, i think |
| 18:52 | <Hixie> | bholley: lgtm |
| 18:52 | <bholley> | great |
| 18:53 | <bholley> | Hixie: do you have a good name in mind? |
| 18:53 | <bholley> | Hixie: so that I can use that in our implementation? |
| 18:53 | <bholley> | Hixie: maybe just "EntryPoint" |
| 18:53 | <Hixie> | well |
| 18:53 | <Hixie> | did you see the recent change to entry script? |
| 18:53 | <bholley> | probably not |
| 18:53 | <Hixie> | did it yesterday, iirc |
| 18:53 | <bholley> | Hixie: oh, the incumbent script stuff |
| 18:53 | <Hixie> | part of the redefinition of incumbent script, yeah |
| 18:53 | <bholley> | or is this different? |
| 18:54 | <Hixie> | entry script is now just the first script in the stack of incumbent scripts, and the incumbent script is the last one |
| 18:54 | <Hixie> | so |
| 18:54 | <bholley> | ahhh |
| 18:54 | <bholley> | interesting |
| 18:54 | <bholley> | so they're implemented together |
| 18:54 | <Hixie> | i think in the spec i'd probably keep the idea of using "script", but what i would do is redefine everything in terms of the script's something or other |
| 18:55 | <Hixie> | document? window/workerglobal? something |
| 18:56 | <bholley> | Hixie: wait, I'm confused by these changes |
| 18:57 | <Hixie> | (hmm... "create a script" is called by: create an impotent script, create a script from a node, timers, and importScripts(). and workers also create scripts.) |
| 18:57 | <bholley> | Hixie: previously, entry points were a stack |
| 18:57 | <bholley> | Hixie: now the entry point is always the bottom of the stack |
| 18:57 | <bholley> | Hixie: isn't that a pretty big behavioral change? |
| 18:57 | <Hixie> | bholley: huh |
| 18:57 | <Hixie> | bholley: interesting point |
| 18:58 | <Hixie> | bholley: ok, disregard recent changes. |
| 18:58 | <bholley> | ok |
| 18:58 | <Hixie> | so wait |
| 18:59 | <Hixie> | why do we ever care about the entry script rather than the incumbent script |
| 18:59 | <bholley> | because of the places in the spec where it's required? |
| 18:59 | <bholley> | IIUC, the entry script stuff is baked into the web platform, as a result of some funny Gecko implementation details back in the day |
| 19:00 | <bholley> | where the entry script is sometimes observable but different from the incumbent script |
| 19:00 | <Hixie> | i guess when script in window X dispatches and event that is handled by script in window A which calls script in window B which calls an API, some APIs use A and some use B, for no apparent reason? |
| 19:00 | <Hixie> | ok |
| 19:00 | <bholley> | Hixie: right. This has to do with how JSContexts historically worked in Gecko, I think |
| 19:00 | <Hixie> | yeah ok let me fix this thing with how i broke entry script, first |
| 19:01 | <bholley> | ok, great |
| 19:01 | <Hixie> | entry script should be the most recently pushed incumbent script that was pushed by the "jump to entry point" algorithm, right |
| 19:03 | <Hixie> | (having network issues, may have to fix this after lunch) |
| 19:03 | <Hixie> | anyway what i was saying earlier |
| 19:04 | <Hixie> | is that what we might want to do is hang all this stuff off the globals, like you suggested |
| 19:04 | <Hixie> | like, have each global have a "global object script settings" conceptual object |
| 19:04 | <bholley> | yeah, I'm pretty sure that every entry script is also an incumbent script |
| 19:04 | <Hixie> | and then use that stack |
| 19:04 | <bholley> | Hixie: right, that sounds perfect |
| 19:04 | <Hixie> | use that on the stack, i mean |
| 19:04 | <Hixie> | and define all the script settings in terms of that object |
| 19:04 | <bholley> | Hixie: so they might be able to be the same stack, which some of them being specially-annotated as entry points |
| 19:04 | <Hixie> | instead of right now, where those settings are on the scripts themselves |
| 19:05 | <bholley> | Hixie: that seems cleaner (and conveniently Gecko-like) |
| 19:05 | <Hixie> | ok, i think we're on the same page for both of these things |
| 19:05 | <Hixie> | this would actually clean up the spec quite a bit |
| 19:05 | <Hixie> | so maybe it's worth doing now despite the risk |
| 19:05 | <Hixie> | it would make it easier to tell if there was some reason we couldn't do that, certainly |
| 19:06 | <bholley> | Hixie: ok. I'll file a spec bug after lunch? |
| 19:06 | <Hixie> | i can file a bug |
| 19:06 | <bholley> | Hixie: ok |
| 19:06 | <Hixie> | dunno what's up with my server. it's responding fine over http and icmp, but over ssh i'm getting multi-minute lag. |
| 19:10 | <Hixie> | bholley: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22863 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=22862 |
| 19:11 | <bholley> | Hixie: \o/ |
| 19:12 | <Hixie> | hopefully i can edit the spec once i have eaten |
| 19:12 | <Hixie> | dunno wtf is up with my server |
| 19:12 | <Hixie> | bbl |
| 19:51 | <aklein> | Hixie: so I've been shopping around your <form><div><script>/*remove div*/</script><input> test case and everyone thinks we should just change the parser |
| 19:51 | <aklein> | that is, of the four or five people on WebKit and Blink I asked |
| 19:52 | <aklein> | do you happen to know if that behavior is a webcompat thing, or just fallout from the other <form> craziness? |
| 19:58 | <aklein> | it would be nice to tighten the <form> association rules so that the form and the associated element be in the same tree |
| 20:17 | <Hixie> | aklein: beats me, but if IE already doesn't do it, or if you can convince them to change, then it would be worth considering, certainly |
| 20:30 | <aklein> | Hixie: IE 9 does not associate in this case: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428 |
| 20:30 | <Hixie> | IE 9 didn't implement the parser |
| 20:30 | <Hixie> | you have to test IE 10 or IE 11, i think |
| 20:30 | <aklein> | yeah, that was next up |
| 20:30 | <aklein> | (don't have those as handy, amusingly) |
| 20:30 | <Hixie> | yeah me either |
| 20:31 | Hixie | was considering actually buying a windows tablet just to have a way to test IE |
| 20:31 | <Hixie> | but i haven't gotten around to it yet |
| 20:31 | Hixie | has a shortage of round tuits currently |
| 21:22 | <Hixie> | hsivonen_, MikeSmith: you guys didn't implement a #line pragma analogue in the validator while i wasn't looking by any chance, did you? |
| 21:37 | <aklein> | Hixie: sigh, returns 1 on a Windows Phone |
| 21:37 | <Hixie> | why sigh! that means we have four-way interop! that's awesome! :-D |
| 21:37 | Hixie | declares victory |
| 21:37 | <aklein> | :) |
| 21:49 | <t3oss> | how Aleca count visits? |
| 21:49 | <t3oss> | Alexa* |