| 14:20 | <smaug____> | has there been talk to put all the interface objects behind so global property |
| 14:21 | <smaug____> | like platformInterfaces.Animation or such |
| 14:21 | <smaug____> | kind of namespacing so that commonly used names would be less likely to cause compat issues |
| 14:26 | <annevk> | smaug____: JavaScript modules, basically |
| 14:26 | <annevk> | smaug____: until that time we should just pick unique enough names, imo |
| 14:27 | <smaug____> | how do modules help with this |
| 14:27 | <annevk> | smaug____: stuff is no longer in the global scope, you have to import it first to use it |
| 14:28 | <smaug____> | so what all is in the scope of module by default? |
| 14:28 | <smaug____> | JS stuff, Math, Date and such? |
| 14:28 | <smaug____> | or nothing? |
| 14:29 | <smaug____> | and how do modules play with event handlers |
| 14:29 | <annevk> | smaug____: I meant that you could have built-in modules that you import to add functionality |
| 14:30 | <annevk> | smaug____: they don't |
| 14:30 | <annevk> | smaug____: I believe that when a module script executes in a browser it sees exactly the same stuff as a classic script would (though it executes in strict mode) |
| 14:31 | <smaug____> | annevk: so module informs that one can import names Foo and Bar out from it to other js to use? |
| 14:31 | <annevk> | smaug____: something like that, you'd have import FancyNewFeature from "web/fancy" or some such |
| 14:31 | <smaug____> | what guarantees Foo and Bar won't be used as interface names later? |
| 14:32 | <annevk> | smaug____: those importing get to decide on the names, aiui |
| 14:32 | <annevk> | Anyway, I gotta go |
| 14:33 | <annevk> | Would love your input on how to design event dispatch with shadow trees |
| 14:33 | <annevk> | See https://github.com/w3c/webcomponents/issues/485 and https://github.com/w3c/webcomponents/issues/486 |
| 14:33 | smaug____ | still doesn't see how it helps. Whoever is deciding that Foo is imported as Bar, doesn't know whether Bar will be an interface object later |
| 14:42 | <Domenic> | you can think of module imports as equivalent to `var Bar = platformInterfaces.Bar` |
| 14:42 | <Domenic> | If you can understand how that helps collisions then you should be able to understand how modules help. |
| 14:43 | <Domenic> | (They're nothing like C++ header files, if that's misleading you.) |
| 14:44 | <smaug____> | Domenic: that doesn't help. What if there is later interface Bar added to the platform |
| 14:44 | <smaug____> | and some code then tries to do new Bar(); |
| 14:45 | <Domenic> | smaug____: then the same "problem" (I don't think it's a real problem) will occur whether you do platformInterfaces.Bar or a module. |
| 14:45 | <smaug____> | but I know forcing to call new platformInterfaces.Bar() would be horrible |
| 14:45 | <Domenic> | It doesn't break back-compat since local bindings always shadow global ones |
| 14:46 | <Domenic> | I guess we are anticipating some scenario where someone copies and pastes code expecting the new platform Bar() into a scope that has defined a variable named Bar? |
| 14:46 | <smaug____> | sure |
| 14:46 | <smaug____> | I'm talking about the case where you have some code doing var Bar = module.Bar; |
| 14:46 | <smaug____> | and then some other code doing new Bar(); (but that wants to use the platform object) |
| 14:47 | <smaug____> | so yes, to your last comment |
| 14:47 | <smaug____> | I started to wonder this again while thinking about Animation interface |
| 14:48 | <smaug____> | per spec it is a normal interface with ctor |
| 14:48 | <smaug____> | but browsers aren't ready to expose it as such |
| 14:48 | <smaug____> | but with NoInterfaceObject |
| 14:51 | <smaug____> | lunch |
| 17:02 | <annevk> | Do we need a label for "problem with standard" that is more serious than "clarification"? |
| 17:03 | <annevk> | E.g., https://github.com/whatwg/html/issues/1073 is great implementer feedback, but if nobody picks it up it'll get lost |
| 17:04 | <caitp> | I thought github had something like "critical" in the default label set |
| 17:05 | <caitp> | this is a critical spec bug, it isn't just a missing apostraphe, it's a sentence that ends with a preposition! |
| 17:50 | <TabAtkins> | annevk: Do you know what the use-case is for "find flattened slotables"? |
| 17:50 | <annevk> | TabAtkins: assignedNodes() and CSS |
| 17:50 | <TabAtkins> | I *think* CSS's use of it only wants to "find slotables", with the "sub in its normal children if nothing is assigned" behavior. |
| 17:51 | <TabAtkins> | It's not 100% clear to me what node slotables are supposed to inherit from, or what the intended model is for when you give a <slot> a non-contents display value. |
| 17:51 | <TabAtkins> | Oh right, CSS does need flattened slotables for ::slotted() still, nm. |
| 17:52 | <annevk> | TabAtkins: ah yes, for the flat tree <slot> elements need to be kept around |
| 17:52 | <TabAtkins> | Okay cool. |
| 17:52 | <TabAtkins> | And so I *think* that means that slotables inherit from the first/highest slot they're assigned to, not their light-tree parent or any deeper slots they get flattened into. |
| 17:53 | <annevk> | TabAtkins: seems like we have a bit much ways of looking at this |
| 17:53 | <TabAtkins> | Yeah, I'm making CSS much more explicit about what it sees at each phase. |
| 17:53 | <TabAtkins> | At Hayato's urging, I'm sucking the whole flat tree concept into the CSS Scoping spec. |
| 17:53 | <annevk> | Yeah, that makes sense |
| 17:54 | <TabAtkins> | When you and I are done, there might not be anything left in the actual Shadow DOM spec. |
| 17:54 | <annevk> | That was more or less the goal |
| 17:54 | <TabAtkins> | Cool. |
| 17:54 | <annevk> | Glad we both came to the same conclusion |
| 17:54 | <TabAtkins> | Okay, I can handle "use its real children if nothing is assigned" by myself. |
| 18:02 | <TabAtkins> | annevk: btw, I like the use of "flattened slotables" better, good change. |
| 18:51 | <TabAtkins> | annevk: Please export your shadow dom definitions - "find slotables" is unexported right now |
| 18:56 | <Mek> | hmm, why does bikeshed not know USVString is a valid type... |
| 18:59 | <TabAtkins> | Mek: Because it's not defined as such in a spec that Shepherd knows about. Where's it defined? |
| 18:59 | <Mek> | TabAtkins: http://heycam.github.io/webidl/#idl-USVString probably? DOMString does seem to correctly link to WebIDL |
| 19:00 | <TabAtkins> | Ah, USVString was marked up right. Checking right now whether it's actually in the db... |
| 19:00 | <TabAtkins> | Well, heaidng to lunch now. bbs |
| 19:06 | <jyasskin> | TabAtkins: With bikeshed at c16b9046 (HEAD), `bikeshed update` returns "FATAL ERROR: This version of the anchor-data API is no longer supported. Please update Bikeshed." |
| 19:54 | <TabAtkins> | jyasskin: Yup, just got it myself. Pinging plinss. |
| 19:54 | <jyasskin> | TabAtkins: Try visiting csswg.org in your browser. |
| 19:55 | <jyasskin> | plinss had me debug and revealed that my DNS is broken, and Bikeshed is just giving a very bad error message. |
| 19:58 | <annevk> | TabAtkins: ah yes, could you file a reminder? Sorry about that |
| 19:58 | <annevk> | TabAtkins: I should really go through all <dfn in DOM |
| 20:50 | <TabAtkins> | Mek: Ok, checked on it - USVString *is* defined in Bikeshed (make sure you've run `bikeshed update` recently!), but I forgot to mark it as exported. >_< |
| 20:51 | <jyasskin> | TabAtkins: I see it in HTML rather than WebIDL. |
| 20:51 | <Mek> | can't run bikeshed update until whatever that DNS thing is is fixed... |
| 20:51 | <TabAtkins> | jyasskin: ...huh, indeed |
| 20:51 | <TabAtkins> | Mek: Fixed by now for me. |
| 20:51 | <jyasskin> | The DNS thing is now fixed. |
| 20:51 | <Mek> | ah yeah, seems fixed now |
| 20:51 | <TabAtkins> | (It was a linode thing) |
| 20:52 | <Mek> | It still complains "LINK ERROR: No 'idl' refs found for 'USVString'." though |
| 20:52 | <TabAtkins> | Yeah, if it's coming from HTML, it'll be read as a dfn-type. :/ |
| 20:52 | <TabAtkins> | But I marked it up in WebIDL, so I need to debug and see what's up with it. |
| 20:53 | <Mek> | and the definition in HTML is just the reference to the WebIDL definition anyway, so not a very useful reference |
| 20:56 | <TabAtkins> | Uggghhhhh, I see the problem. |
| 20:56 | <TabAtkins> | Stupid unrunnable XML pipeline for WebIDL. |
| 20:56 | <Domenic> | I thought HTML data-noexport'ed everything, but also it didn't need to since dfns are not exported |
| 20:56 | <TabAtkins> | Domenic: Right, that's not a problem, dont' worry. |
| 20:57 | <Domenic> | ok ^_^ |
| 20:57 | <TabAtkins> | Problem is that the XSLT for WebIDL inserts section numbers into the heading text, and doesn't take Bikeshed into account, so the handful of "heading dfns" I set up have linking text like "3.10.7. USVString" |
| 20:57 | <TabAtkins> | I'll fix and send heycam a PR. |
| 21:00 | <jyasskin> | lol |
| 21:44 | <smaug____> | hmm, browsers handle <iframe scrolling=no> quite differently |