| 00:04 | <Domenic> | TabAtkins: can I pass in custom metadata with bikeshed's --md-xxx syntax? I am getting "Unknown metadata key" errors |
| 00:04 | <TabAtkins> | Nope, I have a note in the issue saying that I'm not adding it until someone asks, because it's a little troublesome. ^_^ |
| 00:05 | <Domenic> | hmm maybe i can repurpose another metadata |
| 00:06 | <Domenic> | TabAtkins: I basically want to smuggle in some custom text from the command line, so I can do `var currentCommitURL = "[commiturl]"` |
| 00:06 | <Domenic> | any better way to do that than asking you to implement custom metadata? |
| 00:07 | <TabAtkins> | That won't work in the first place, since there's no way to set custom text macros. |
| 00:07 | <Domenic> | Ah, macros vs. metadata |
| 00:08 | <Domenic> | so uh yeah any ideas |
| 00:13 | <TabAtkins> | Log an issue on me and I'll think about it. ^_^ |
| 08:00 | <MikeSmith> | anybody know that github is using Flash for? |
| 08:00 | <MikeSmith> | in Chrome I get a popup notification about it having blocked a pop-up from Flash |
| 08:02 | <ondras> | document.querySelectorAll("object")[0].id |
| 08:02 | <ondras> | "global-zeroclipboard-flash-bridge" |
| 08:03 | <ondras> | :-) |
| 08:03 | <MikeSmith> | https://assets-cdn.github.com/flash/ZeroClipboard.v2.1.6.swf I guess |
| 08:03 | <MikeSmith> | ondras: yeah |
| 08:53 | <annevk> | Domenic: are you awake? |
| 09:10 | <hsivonen> | zcorpan: thanks. validator.nu is back |
| 09:10 | <hsivonen> | looks like I need to write some kind of watchdog for this |
| 09:11 | <hsivonen> | like I have with Apache+Bugzilla, which is combo that gets killed by the kernel occasionally |
| 09:11 | <hsivonen> | so I have a cron job telling apache to start frequently |
| 09:14 | <annevk> | heycam|away: whoa, 100Mbps for AUD 1500 is ... move to Europe ;-) |
| 10:29 | <zcorpan> | my first v.nu PR https://github.com/validator/validator/pull/25 |
| 10:30 | <MikeSmith> | righteous |
| 10:31 | <zcorpan> | i guess there's no spec for x-ua-compatible http header |
| 10:33 | <MikeSmith> | only some scattered msdn stuff, how-to, not spec |
| 10:35 | <zcorpan> | maybe the message should say what the value was |
| 10:36 | <MikeSmith> | that's always nice to have |
| 10:37 | <MikeSmith> | especially in this case |
| 10:37 | <MikeSmith> | since it's coming from a header |
| 10:47 | <zcorpan> | MikeSmith: the docs say there's error, fatalError and warning. and the other errors are actually fatal. so this should be error |
| 10:47 | <zcorpan> | unless error somehow doesn't work and it needs to choose between fatalError and warning |
| 10:49 | <MikeSmith> | zcorpan: ok. haven't looked back at the rest of the code yetー I'm on from my phone |
| 16:09 | <annevk> | https://twitter.com/awbjs/status/555755196488241152 :/ |
| 16:09 | <annevk> | Is there nobody that does any triaging on ES bugs? |
| 16:09 | <annevk> | What's the point in filing them if they keep getting deferred unless you're on some committee |
| 16:10 | <Ms2ger> | What makes you think there is a point? |
| 16:10 | <gsnedders> | haha thinking doing anything with TC-39 is worthwhile if you're not a member of TC-39, that's cute |
| 16:16 | <Domenic> | annevk: am awake |
| 16:17 | <Domenic> | curious on your thoughts on my latest custom elements post |
| 16:17 | <Domenic> | i think it makes upgrading a minimum viable part of the mvp |
| 16:17 | <annevk> | Domenic: the Dmitry solution? |
| 16:17 | <Domenic> | yes |
| 16:18 | <annevk> | Domenic: I was not thrilled at first, but then I read Jonas' almost-synchronous solution which wasn't great either |
| 16:19 | <Domenic> | I think the Dmitry solution is pretty nice. The biggest problem with the current setup is that C1 = document.registerElement("my-el", C2) gives C1 !== C2 |
| 16:19 | <Domenic> | with Dmitry's solution they are === |
| 16:19 | <annevk> | Domenic: it seems even wycats is not too opposed to the Dmitry solution although it has the Brain transplant properties... |
| 16:21 | <annevk> | Domenic: the main thing I dislike is that it's quite a bit different from normal elements |
| 16:22 | <annevk> | Domenic: but I guess that's always going to be the case, given where we put the security boundaries |
| 16:23 | <Domenic> | For parses that happen after registration you could use the real constructor using Jonas's technique more or less, I think. But for parses before registration I think not having identity at parse time is the only reasonable thing. |
| 16:23 | <annevk> | Domenic: I don't think we should do both |
| 16:23 | <annevk> | Domenic: that makes it racy whether certain things end up working |
| 16:23 | <Domenic> | Normal elements could probably work the way of the Dmitry solution |
| 16:24 | <Domenic> | Probably nobody wants to implement that but seems doable. |
| 16:24 | <annevk> | Domenic: the element-constructors repo looks really great btw |
| 16:25 | <Domenic> | Thanks :). Needs a bit more work, but I am happy that it is possible. |
| 16:26 | <annevk> | Yeah, I think as some suggested on the list we want to require magic tokens for a few to make forward compatibility a bit better, but overall this looks like the way to go |
| 16:26 | <TabAtkins> | I'm so happy that someone who understands JS better than I do is making this happen. ^_^ |
| 16:26 | <Domenic> | Hopefully can restrict it to HTMLUnknownElement. |
| 16:27 | <annevk> | Even though it's rather weird that elements have both duck typing and identity but I guess we're not going to remove that anytime soon |
| 16:31 | <Domenic> | What do you mean by that exactly? |
| 16:33 | hemanth | : Node Module Of The Week -> http://nmotw.in/isomorphic-fetch/ |
| 16:36 | <annevk> | Domenic: that you check the identity of an element by name/namespace rather than class |
| 16:37 | <Domenic> | Yeah but if we maintain the invariants in the readme then those have a 1:1 correspondence so it becomes observably the same |
| 16:37 | <annevk> | Domenic: similar to how ES prescribes that you check for [[WeakMapData]] but then makes these slots so unique you can do it either way... |
| 16:37 | <annevk> | Domenic: I would like <my-button> to be able to be a subclass of <button> at some point |
| 16:38 | <annevk> | Domenic: not right away, but at some point |
| 16:38 | <Domenic> | Ah I see |
| 16:38 | <annevk> | Domenic: and forget about is="" for now since it's ugly and Apple is not interested |
| 16:38 | <Domenic> | is="" is currently the only way to get accessibility |
| 16:39 | <Domenic> | Plus other various gaps that HTML as Custom Elements documents |
| 16:39 | <annevk> | What's wrong with ARIA? |
| 16:39 | <Domenic> | it doesn't cover e.g. focus |
| 16:39 | TabAtkins | isn't super-hyped about dropping something when it's sure to lead to more "Google spec doesn't care about a11y" shouting... |
| 16:40 | <Domenic> | TabAtkins: heh, Mozilla is already getting the blame. https://twitter.com/stevefaulkner/status/555757553062535168 |
| 16:40 | <annevk> | Domenic: anything with tabindex can get focus |
| 16:41 | <Domenic> | annevk: or general manipulability with the keyboard. You have to hand-code all the event listeners.https://w3c.github.io/webcomponents/spec/custom/#custom-tag-example |
| 16:41 | <annevk> | Is is="" going to be the new longdesc=""? |
| 16:41 | <annevk> | Domenic: if your element is doing anything novel that is going to be the case either way, but to be clear I wouldn't want this to stay this way forever |
| 16:42 | <TabAtkins> | No, eventually we'll just have <my-button>, presumably. |
| 16:42 | <annevk> | Domenic: I would like to solve this too, but I don't think is="" is the way to go |
| 16:42 | <Domenic> | <my-button> subclassing button seems doable if Boris changes all the Gecko code and we fill all the HTML as Custom Elements gaps |
| 16:42 | <wycats> | annevk: I think Dmitry's approach is the local-maxima for brain transplants |
| 16:42 | <wycats> | I'd like to explore options other than brain transplants though |
| 16:42 | <annevk> | wycats: I have the options here: https://wiki.whatwg.org/wiki/CustomElements#Upgrading |
| 16:43 | <annevk> | wycats: though explanation/drawbacks is not as complete as it could be |
| 16:43 | <wycats> | annevk: I need to propose the "import-in-html" thing |
| 16:43 | <wycats> | which isn't represented there |
| 16:43 | <Domenic> | "Not having identity at creation-time is a giant mismatch with the rest of the platform." I think in theory the rest of the platform could match |
| 16:43 | <annevk> | Domenic: if all browsers change all the code rather :-P |
| 16:44 | <Domenic> | Or at least I would be interested to tease out the exact problems that occur if we tried to make it match |
| 16:44 | <wycats> | Domenic: seems tricky |
| 16:44 | <Domenic> | wycats: I don't see how. If we run createdCallback "before user script", it's only inside the createdCallback that the uninitialized state of other elements is observable |
| 16:45 | <annevk> | wycats: even with import-in-html one of these four strategies needs to be used I think to actually create instances from markup |
| 16:45 | <Domenic> | and you can't override the createdCallbacks that the built-ins supplied to the browser at start-up time |
| 16:45 | <wycats> | annevk: sure, yes |
| 16:46 | <annevk> | really three strategies, I only added the existing prototype one for comparison sake |
| 16:46 | <Domenic> | I *guess* this scenario would be observably different: <my-el></my-el><p>; inside the createdCallback() for my-el you would observe this.nextSibling is HTMLElement instead of HTMLParagraphElement |
| 16:46 | <Domenic> | But you could solve even that if you create a priority queue system where the elements that are registered first are called first |
| 16:47 | <Domenic> | So then just say that <p> registered its callbacks before <my-el> so it gets upgraded + createdCallback first, so inside <my-el>'s createdCallback() you end up seeing the post-upgrade <p>. |
| 16:47 | <annevk> | I guess I need to reread how Dmitry's solution works exactly |
| 16:47 | <Domenic> | So I think the brain transplant is not observably different from the existing platform. |
| 16:47 | <Domenic> | i.e. all existing elements can be explained in terms of it. |
| 16:47 | <wycats> | Domenic: fwiw, this is my very very very very very very straw-man: https://gist.github.com/wycats/b67eb065e5862902a7ee |
| 16:48 | <Domenic> | with this additional idea that you run callbacks in order of registration |
| 16:48 | <wycats> | for imports-in-html |
| 16:48 | <wycats> | like... so straw man that the syntax isn't worth bikeshedding at all |
| 16:48 | <wycats> | the key point is the semantics |
| 16:48 | <Domenic> | wycats: so you can only use custom elements inside templates? |
| 16:48 | <wycats> | Domenic: <template> is a straw-man to get inert DOM |
| 16:48 | <Domenic> | sure I don't care about the name |
| 16:48 | <Domenic> | So you can't just write .html files using custom elements |
| 16:49 | <wycats> | Domenic: my original approach was to just say that any element that contained imports was inert |
| 16:49 | <wycats> | which is also fine |
| 16:49 | <Domenic> | so that's just equivalent to sync script then |
| 16:49 | <wycats> | deny |
| 16:49 | <wycats> | Domenic: read down |
| 16:49 | <wycats> | it's async, and there is fallback content |
| 16:49 | <Domenic> | right, but same idea of blocking the real content until the definition loads. |
| 16:50 | <wycats> | yes |
| 16:50 | <wycats> | but not actually blocking the main thread |
| 16:50 | <Domenic> | sure, <script> doesn't block the main thread, it just blocks parsing the real content |
| 16:50 | <wycats> | Domenic: the thing that I'm most struggling with is the fact that usually "loading" is a coarser thing than a single element |
| 16:50 | <wycats> | Domenic: I don't think it's worth analogizing to sync script |
| 16:50 | <wycats> | it's not meant to work like sync script |
| 16:51 | <Domenic> | it is very much worth analogizing because this is just a tweak to the sync script proposal |
| 16:51 | <wycats> | the sync script proposal has no way to show other subsequent content |
| 16:51 | <wycats> | it seems... not the same? |
| 16:51 | <Domenic> | sure it does |
| 16:51 | <Domenic> | just place the ocntent there and replace it when hte script runs |
| 16:51 | <wycats> | the main characteristic of sync script is that the sync script blocks the world |
| 16:52 | <Domenic> | that... is not how scripts work |
| 16:52 | <Domenic> | they block parsing, not the world |
| 16:52 | <wycats> | Domenic: by "the world", what I mean is that no further content can be put on the page |
| 16:53 | <wycats> | Domenic: maybe we're talking past each other |
| 16:53 | <Domenic> | so yours allows placing the fallback content spatially after the <import> in the source document; but with <scirpt> you just place it spatially before |
| 16:53 | <wycats> | Domenic: yes, and then you're responsible for removing it, AND you cannot put anything else on the page once you hit an area of HTML that requires custom elements |
| 16:54 | <wycats> | Domenic: I'm pretty sure we're not talking about the same thing |
| 16:54 | <wycats> | what I'm suggesting encapsulates the "blocking" to an area of HTML |
| 16:54 | <wycats> | it does not block ALL subsequent parsing |
| 16:55 | <wycats> | and the thing is: you usually want loading behavior to be coarser than targeting individual unknown elements with CSS |
| 16:57 | <annevk> | Domenic: <script> blocks the main thread, no? |
| 16:58 | <Domenic> | annevk: I don't think so. E.g. if you do <script>setTimeout(fn);</script><script src="takes-a-long-time-to-load.js"></script> I am pretty sure fn runs after ~0 ms, not after the load. |
| 16:58 | <annevk> | Domenic: sure, but anything after <script> won't show |
| 16:58 | <Domenic> | annevk: right that's what I mean by blocking parsing but not the main thread |
| 16:59 | <annevk> | Domenic: from what I understood from the <import> idea the parser would just keep going constructing the DOM |
| 17:00 | <annevk> | Domenic: you'd get a placeholder of sorts |
| 17:00 | <wycats> | annevk: yes, for the container containing the <import>s |
| 17:00 | <wycats> | but not for anything subsequent |
| 17:01 | <wycats> | and the placeholder could be user-supplied fallback content, like a coarse-grained loader spinner |
| 17:11 | <wycats> | it's pretty analogous to how the notional <module> will work |
| 17:11 | <wycats> | but for HTML instead of script |
| 17:37 | <annevk> | wycats: given that you still need one of the upgrading mechanisms from the wiki page, wouldn't it make sense to pick one from those? Or do you think this proposal would influence the decision? (In which case my advice would be to write up the basic processing model and post it someplace...) |
| 17:39 | <wycats> | I think it would influence it because it eliminates user-visible unknown elements in these cases |
| 17:39 | <wycats> | Which I think is a weakness in the other async proposals |
| 17:41 | <wycats> | annevk: in other words, DOM replacement may work just fine because there's no space for someone to qSA and grab onto the wrong element |
| 17:41 | <Domenic> | if it's not observable you could choose any of the alternatives |
| 17:41 | <Domenic> | DOM replacement would still fire observable mutation observer callbacks though |
| 17:42 | <annevk> | wycats: what kind of DOM replacement is this? |
| 17:42 | <annevk> | wycats: the original node is not an actual element? |
| 17:47 | <annevk> | http://www.fastcompany.com/3037803/the-oral-history-of-the-poop-emoji-or-how-google-brought-poop-to-america "I used some external power. I went to the product manager of Gmail, who manages everything about Gmail, and got [him to agree] that this is the most useful emoji." |
| 17:51 | <wycats> | Domenic: no |
| 17:52 | <wycats> | Domenic: let me try to be precise |
| 17:52 | <wycats> | it sounds like there is some consternation about *actually* running user code during the time period of parsing |
| 17:52 | <wycats> | I can understand that |
| 17:52 | <wycats> | so what I'm proposing is a second pass that replaces the dummy nodes inserted *in the algorithm* with new nodes |
| 17:53 | <wycats> | but no mutation observers would fire and the entire process would be purely in-algorithm |
| 17:53 | <Domenic> | is this observably different from blocking the parse (for that subtree) as you run the constructors |
| 17:54 | <Domenic> | it seems like it is because nextSibling would be null in blocking the parse but would be a dummy node in your version |
| 17:55 | <Domenic> | which is bad because the observable dummy node would be replaced by a custom element but no mutation observers would fire |
| 17:56 | <wycats> | Domenic: I personally would prefer if user-code worked just like platform code (and constructors run inline) but that seems to be a no-go |
| 17:56 | <wycats> | Domenic: why would nextSibling be the dummy node in my version? |
| 17:56 | <wycats> | you would run the constructor before doing the replacement |
| 17:56 | <Domenic> | yes but you've only replaced one of them |
| 17:56 | <Domenic> | oh i see |
| 17:56 | <Domenic> | it's not even in the DOM when the constructor is run |
| 17:57 | <Domenic> | Same problem with attachedCallback thoug |
| 17:57 | <Domenic> | user-code can work just like platform-code in the Dmitry version, as I outlined |
| 17:58 | <wycats> | Domenic: say more about attachedCallback? |
| 17:59 | <Domenic> | <my-el1></my-el1><my-el2></my-el2> |
| 17:59 | <wycats> | wouldn't you wait to run those callbacks until all nodes were replaced? |
| 17:59 | <wycats> | basically try to make the observable semantics equivalent to inline constructors |
| 17:59 | <Domenic> | the definition of attachedCallback is that it runs when inserting |
| 17:59 | <Domenic> | if you change that I guess you can avoid observing it |
| 18:00 | <wycats> | there is no other user code that runs |
| 18:00 | <wycats> | surely the only real requirement is that it runs after inserting and before any other user code? |
| 18:00 | <Domenic> | yes but they have to run in order |
| 18:01 | <wycats> | right. I guess what I'm saying is that we make the semantics "execute constructors inline" and that this is a strategy implementations can use that is equivalent to those semantics |
| 18:01 | <wycats> | that won't pwn their existing code |
| 18:01 | <Domenic> | Ah so the Jonas solution. |
| 18:02 | <wycats> | I don't see it in annevk's list |
| 18:02 | <wycats> | or do I |
| 18:02 | <Domenic> | Hmm yeah I don't think it's linked |
| 18:02 | <annevk> | shit yeah, that needs to be added |
| 18:03 | <annevk> | The almost-synchronous constructor |
| 18:03 | <annevk> | wycats: for now, see https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0098.html |
| 18:03 | <Domenic> | wycats: "in a modules world" is a bad way to lead an argument :-/ |
| 18:04 | <Domenic> | if we have learned anyhting over the last two years it's that you can't block a feature on modules eventually shipping |
| 18:04 | <wycats> | Domenic: we think modules aren't going to be the dominant way people write JS in 5 years? |
| 18:04 | <wycats> | hm |
| 18:04 | <wycats> | I didn't realize I was suggesting that we block something |
| 18:04 | <wycats> | maybe I missed something subtle? |
| 18:05 | <Domenic> | you weren't suggesting it outright, but the implication that your suggestion works better in a modules world makes it easy to immediately dismiss your suggestion |
| 18:05 | <Domenic> | would be better to just work in the world we have and use `Element.ready` instead of `ready` |
| 18:05 | <wycats> | Domenic: annevk: ha! The Jonas solution is almost 1:1 with the way Ember handles components! |
| 18:05 | <wycats> | sure |
| 18:05 | <wycats> | Domenic: that makes sense |
| 18:05 | <wycats> | [Element.ready] works fine too |
| 18:05 | <wycats> | and is hardly longer than readyCallback |
| 18:06 | <Domenic> | yeah I am coming around to the symbols |
| 18:06 | <wycats> | do you want to reply with that or should I follow-up and say you suggested it? |
| 18:06 | <Domenic> | I can do it |
| 18:06 | <wycats> | Domenic: As a framework author, I'm loathe to be as dismissive of the future issues |
| 18:07 | <wycats> | symbols let you be really short and declarative about what you're doing, at the cost of slightly more boilerplate around the symbol |
| 18:07 | <wycats> | strings make you have to worry about all other ecosystem users |
| 18:07 | <wycats> | See A.p.contains :P |
| 18:07 | <wycats> | s/declarative/clear/ |
| 18:10 | <annevk> | wycats: would you suggest symbols for everything though? If we add a new property to an element? |
| 18:10 | <annevk> | wycats: or just hooks? |
| 18:11 | <wycats> | annevk: just hooks |
| 18:11 | <annevk> | good |
| 18:11 | <Domenic> | hmm why |
| 18:11 | <Domenic> | i don't want to add symbols for everything but i don't see why the argument doesn't apply |
| 18:11 | <wycats> | Domenic: hm... mostly experience with Ember but I should try to quantify |
| 18:12 | <annevk> | Domenic: so the concern would be that a subclass of <img> adds .exif and then the browser can no longer add it? Or the browser adds it and breaks the subclass? Meh |
| 18:12 | <wycats> | right... those issues seem minor |
| 18:12 | <wycats> | compared to hooks |
| 18:12 | <wycats> | where you could be invoking random code |
| 18:12 | <wycats> | that didn't expect to be invoked |
| 18:12 | <Domenic> | that makes sense |
| 18:13 | <wycats> | Domenic: it's similar to how we can get away with new globals |
| 18:13 | <wycats> | because worst-case things get shadowed |
| 18:14 | <wycats> | Domenic: Polymer decided not to use *Callback it seems |
| 18:14 | <wycats> | they removed all of the `Callback` suffixes :P |
| 18:14 | <wycats> | http://note.io/1ygHes0 |
| 18:15 | <Domenic> | I don't really know the details but I think polymer element definitions don't correspond to the CE prototype exactly |
| 18:15 | <wycats> | right |
| 18:15 | <wycats> | this table has some details |
| 18:15 | <Domenic> | lunch, bbl |
| 18:15 | <wycats> | Domenic: I think obviously internal DOM properties should be using private state of some stripe |
| 18:16 | <annevk> | https://wiki.whatwg.org/wiki/CustomElements#Upgrading now has "Jonas" |
| 18:16 | <wycats> | (which is a real issue with subclasses in Ember and we're pretty careful with `_` which doesn't help enough) |
| 18:16 | <wycats> | annevk: I find it interesting that Ember's approach is similar to Jonas |
| 18:16 | <wycats> | we do breadth-first recursive rendering |
| 18:16 | <wycats> | and we have an abstraction called "morph" |
| 18:17 | <wycats> | which is the bookkeeping |
| 18:17 | <wycats> | it uses empty text nodes |
| 19:37 | <dglazkov> | Domenic: what was the outcome of this thread? https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0355.html |
| 19:41 | <Domenic> | dglazkov: nothing, nobody cares :( |
| 19:42 | <Domenic> | I guess that one was where I learned a few things and cleared up a few of my wrong misconceptions. It eventually fed into https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md which is more accurate than that thread's OP |
| 19:46 | <annevk> | dglazkov: Domenic: I'd be happy to help tackle that, making accessibility work is important |
| 19:46 | <Domenic> | \o/ |
| 19:46 | <Domenic> | Looking forward to a faithful <custom-span>! |
| 19:48 | <annevk> | Yeah, I've been focusing on figuring out the new low-level bits now JavaScript is finally in shape, but we should definitely revisit old threads such as that one |
| 19:49 | <annevk> | I'm starting to dislike the timezone difference for this project, but I guess it's going well enough |
| 19:50 | <Domenic> | I need to wake up earlier, heh |
| 19:50 | <Domenic> | Been getting in at 11 this week :-/ |
| 19:52 | <Domenic> | annevk: there is also a proposal for fixing focus, https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit, although it is pretty confused right now. (See my comment at the top.) |
| 20:09 | <Hixie> | who's in charge of WebIDL these days? |
| 20:09 | <TabAtkins> | Still heycam|away |
| 20:11 | <Ms2ger> | Hixie, and bz in practice |
| 20:14 | <Hixie> | k, thanks |
| 20:14 | Hixie | ccs bz |
| 20:23 | <jochen__> | when an event handler for the beforeunload event returns an object where the toString method throws an exception |
| 20:23 | <jochen__> | should the browser fire an error event |
| 20:23 | <jochen__> | or should it just swallow the exception and continue to unload? |
| 20:24 | Hixie | looks at the spec |
| 20:24 | <jochen__> | i can tell you what chrome does |
| 20:25 | <jochen__> | if the navigation was triggered from js, it fires the error event, if it was triggered by the user, it crashes |
| 20:25 | <Hixie> | well it definitely shouldn't crash. :-) |
| 20:26 | <jochen__> | can't we just spec it like that? |
| 20:26 | <jochen__> | i'm actually trying to fix it, but i don't know what the right fix would be |
| 20:27 | <Hixie> | yeah |
| 20:27 | <Hixie> | the specs are very unhelpful here |
| 20:27 | <Hixie> | even the most generous reading of HTML, WebIDL, and JS doesn't answer the question |
| 20:28 | <jochen__> | so |
| 20:28 | <jochen__> | what should i do? |
| 20:28 | <Hixie> | not sure how to fix this |
| 20:28 | <Hixie> | "If the return value is null, then cancel the event." |
| 20:28 | <Hixie> | "Otherwise, If the Event object E is a BeforeUnloadEvent object, and the Event object E's returnValue attribute's value is the empty string, then set the returnValue attribute's value to return value." |
| 20:29 | <Hixie> | does that first call valueOf() then toString() ? |
| 20:29 | <Hixie> | or valueOf() then toString() on that? |
| 20:29 | <Hixie> | or...? |
| 20:29 | <Hixie> | oh wait wait |
| 20:29 | <Hixie> | i'm looking in the wrong place |
| 20:29 | <Hixie> | i should be looking in the handling of callback return values |
| 20:30 | <Hixie> | http://heycam.github.io/webidl/#es-invoking-callback-functions |
| 20:31 | <Hixie> | "end these steps and allow the exception to propagate" |
| 20:31 | <Hixie> | so i should catch the exception in the "event handler processing algorithm" |
| 20:31 | <jochen__> | mhm |
| 20:31 | <Hixie> | in step 3 |
| 20:32 | <jochen__> | but where does it propagate to, if script is not running? |
| 20:32 | <Hixie> | my algorithm, which then crashes with an uncaught exception |
| 20:32 | <Hixie> | so technically chrome is matching the spec |
| 20:32 | <Hixie> | :-P |
| 20:32 | <Hixie> | for DOM event dispatch, the dom spec says "If this throws any exception, report the exception." |
| 20:32 | <Hixie> | i just need to add that sentence to HTML |
| 20:33 | <Hixie> | well actually |
| 20:33 | <Hixie> | no! |
| 20:33 | <Hixie> | this is well defined after all! |
| 20:33 | <Hixie> | (well not really but arguably) |
| 20:33 | <Hixie> | my algorithm gets the exception, aborting it (that's poorly defined but matches exception semantics) |
| 20:33 | <Hixie> | then it gets back to the DOM algorithm |
| 20:33 | <Hixie> | which reports the exception |
| 20:34 | <Hixie> | so to answer your question: it should fire an error event |
| 20:35 | <jochen__> | k |
| 20:35 | <jochen__> | sounds like a plan :) |
| 20:35 | <jochen__> | thx |
| 20:37 | <Hixie> | i'll make HTML clearer about this |
| 20:44 | <Hixie> | hrm, webidl doesn't actually give a hook for calling callbacks |
| 20:44 | <Hixie> | that seems like an omission of note... |
| 21:20 | <Hixie> | what do i replace DOMStringList with, if I have to spec an API that uses DOMStringList? |
| 21:20 | <Hixie> | uses in implementations, i mean |
| 21:20 | <TabAtkins> | It returns a list of DOMStrings? Is it live? |
| 21:41 | <Hixie> | TabAtkins: ancestorOrigins. Can't be changed, so not really live. |
| 21:41 | <TabAtkins> | Oh, is this an attribute on something? |
| 21:42 | <Hixie> | Location.ancestorOrigins |
| 21:42 | <Hixie> | returns the origins of the ancestor frames |
| 21:42 | <TabAtkins> | Bah. WebIDL still doesn't allow using a sequence<> in attributes (but also still doesn't provide any other option). |
| 21:43 | <Hixie> | what is api-compatible with DOMStringList? anything? |
| 21:44 | <TabAtkins> | Aside from .item(), Array is compatible. |
| 21:44 | <TabAtkins> | (It now has a .contains() method.) |
| 21:44 | <Hixie> | maybe i just return an Array |
| 21:44 | <Ms2ger> | .includes(), actually |
| 21:44 | <Ms2ger> | .contains() is dead |
| 21:45 | <TabAtkins> | Ms2ger: Ugh, MDN is out of date, then. |
| 21:45 | <TabAtkins> | Hixie: You can't return an array in an attribute. |
| 21:45 | <Ms2ger> | May well be |
| 21:45 | Ms2ger | looks |
| 21:45 | <TabAtkins> | At least, not through WebIDL. |
| 21:45 | <Hixie> | why not? |
| 21:45 | <TabAtkins> | Because it's not possible. |
| 21:46 | <Hixie> | readonly attribute object foo; |
| 21:46 | <TabAtkins> | That's not enough. It doesn't protect the array from being changed. |
| 21:46 | <TabAtkins> | It just means you can't *replace* the array. |
| 21:46 | <Ms2ger> | Wuh |
| 21:46 | <Ms2ger> | <TabAtkins> Hixie: You can't return an array in an attribute. |
| 21:46 | <Ms2ger> | Sure you can |
| 21:46 | <Hixie> | you just return a readonly array |
| 21:46 | <TabAtkins> | readonly just means there's only a getter, not a setter. |
| 21:46 | <TabAtkins> | The array is still mutable. |
| 21:47 | <Hixie> | not if you say it's not... |
| 21:47 | <TabAtkins> | There's no way to indicate otherwise in WebIDL. |
| 21:47 | <Ms2ger> | Are we talking Array or T[]? |
| 21:47 | <TabAtkins> | T[] isn't an Array at all. |
| 21:47 | <Ms2ger> | It's called one |
| 21:48 | <Ms2ger> | Well, not Array, but array |
| 21:48 | <TabAtkins> | Ms2ger: It's possible that i'm still totally turned around by the sequence<T>/T[]/Array mess that IDL is full of. |
| 21:48 | <Hixie> | the prototype of a T[] is Array |
| 21:48 | <Ms2ger> | Anyway, T[] is dead |
| 21:48 | <Hixie> | so it seems pretty arrayy to me |
| 21:48 | <Hixie> | there's a bunch of places in HTML where i return read-only arrays iirc |
| 21:48 | <Hixie> | in any case i don't really care what i return |
| 21:49 | <Hixie> | just need to know what it should be |
| 21:49 | <Hixie> | in what sense is T[] dead? |
| 21:49 | <Hixie> | http://heycam.github.io/webidl/#es-array seems to describe them in detail |
| 21:50 | <TabAtkins> | In that no APIs should use them. |
| 21:50 | <Ms2ger> | In that heycam|away should edit the spec |
| 21:50 | <TabAtkins> | They're not Arrays, they're magical platform objects with Array on their prototype. |
| 21:50 | <Hixie> | sounds good to me |
| 21:52 | <Domenic> | the plan is to have FrozenArray<T> or something |
| 21:53 | <Domenic> | heycam|away says that's his next priority IIRC |
| 21:53 | <Hixie> | ugh i hate frozen stuff |
| 21:53 | <Hixie> | it doesn't let you add custom properties |
| 21:54 | <Hixie> | in any case it looks like my choices are: a) revive DOMStringList and exactly match Chrome's implementation; b) use the deprecated read only array DOMString[] platform array object; c) punt even longer |
| 22:05 | <Hixie> | looks like other uses of DOMStringList got turned into DOMString[] |
| 22:06 | <Hixie> | so i'll go with that for now |
| 22:10 | <Hixie> | anyone got an IDN site that uses arrays handy? |
| 22:10 | <Hixie> | er |
| 22:10 | <Hixie> | that uses iframes, even |
| 22:34 | <heycam> | yes I should just get around and do that |
| 22:46 | <TabAtkins> | heycam: If I can get off my ass and finally write the @extend spec, you can fix up that part of WebIDL. ^_^ |
| 22:46 | <TabAtkins> | Also: figure out how I can do the same with dicts, plzkthx. |