| 00:21 | <nox> | Domenic: Seems like Gecko's WebIDL parser got ExceptionClass already. |
| 01:44 | <MikeSmith> | TabAtkins: html5lib is still not part of the standard Python library, right? |
| 01:44 | <MikeSmith> | it needs to be installed separately? |
| 01:44 | <TabAtkins> | Dunno if it is or not, but yeah, I install it separately. |
| 01:44 | <MikeSmith> | k |
| 01:45 | <MikeSmith> | the default lxml.html parser seems to be more conforming than it was in the past |
| 01:46 | <MikeSmith> | TabAtkins: have you run into any specific problems just using the lxml.html parser rather than html5lib? |
| 01:46 | <TabAtkins> | Haven't tried. |
| 01:47 | <MikeSmith> | ok |
| 01:48 | <MikeSmith> | well the main reason I use html5lib is not because I’ve had any specific problems with the lxml.html parser but instead because I don’t trust it without being able to know what it’s actually doing |
| 02:01 | <MikeSmith> | TabAtkins: OK fwiw, some quick testing reveals that the lxml.html parser fails to conform in some very basic ways; for example, if the input lacks a <head> start tag, it doesn’t put a `head` element into the tree |
| 02:05 | <TabAtkins> | Heh, cool. |
| 09:43 | <annevk> | Ugh, UI Events apparently still tries to redefine the event architecture |
| 09:45 | <ritsyy> | annevk: after resolving some more errors i am getting this as the output to wattsi https://paste.kde.org/pqrs9qnvj is this correct? |
| 09:45 | <ritsyy> | annevk: because the build script works the same as not giving the line numbers |
| 09:51 | <annevk> | ritsyy: that seems like you successfully compiled wattsi yes |
| 09:55 | <annevk> | ritsyy: and there's no error on that line? |
| 09:56 | <ritsyy> | annevk: no it doesn't show up the line, the error is given like this https://paste.kde.org/pnwe0pi5f |
| 09:57 | <annevk> | ritsyy: oh that looks correct |
| 09:57 | <annevk> | ritsyy: you missed an end tag somewhere |
| 09:58 | <ritsyy> | annevk: oh didn't it shows up the line number? |
| 09:59 | <ritsyy> | annevk: oh then i will look into the changes |
| 09:59 | <annevk> | it cannot really tell until it sees </body> that you didn't close your tag |
| 09:59 | <annevk> | I'm assuming the line that it gives you is </body> |
| 10:01 | <ritsyy> | annevk: oh okay, i am looking into it, thanks |
| 13:43 | <Ms2ger> | Unprefixed fullscreen api in Firefox 47, finally |
| 15:48 | <annevk> | smaug____: so conceptually we'd have "dispatch" invoke something like while(target = target.getParent(event)) path.append(target) and node and document implement this getParent function slightly differently |
| 15:49 | <annevk> | smaug____: as would IDB objects |
| 15:49 | <annevk> | smaug____: and then when Shadow DOM gets integrated properly we'd change the implementation of nodes a bit further |
| 15:49 | <annevk> | hayato: ^^ |
| 16:12 | <smaug____> | annevk: yeah |
| 16:13 | <smaug____> | I think that should be quite clear for the spec |
| 16:14 | <smaug____> | I think in new Shadow DOM the propagation would be close to XBL: http://mxr.mozilla.org/mozilla-central/source/dom/base/FragmentOrElement.cpp#890 |
| 16:19 | <annevk> | smaug____: it's somewhat shitty that getParent needs that event argument for the Window case, but what can you do... |
| 16:19 | <smaug____> | 'load' is horrible special case |
| 16:20 | <annevk> | This new webkit stuff is pretty horrible too though, geez |
| 16:22 | <annevk> | smaug____: any reason Gecko passes the whole event to getParent and not just the type? |
| 16:22 | <annevk> | smaug____: or even just a boolean whether it's a load or not |
| 16:25 | <smaug____> | well, Gecko passes a visitor object. And that has pointers to various things. And event.type is used also in HTMLInputElement for example when click event on checkbox before dispatch needs to switch the state, and if event is cancelled, the state is reverted back |
| 16:25 | <smaug____> | this is because there is then PostHandleEvent on each event target called |
| 16:26 | <smaug____> | after the normal DOM event handling |
| 16:27 | <smaug____> | visitor object has also a pointer to the eventtarget in case there is retargetting happening (this is XBL stuff mostly) |
| 16:27 | <annevk> | aah, this is how the <input> stuff works |
| 16:28 | <annevk> | so we could finally define that more clearly if I add these hooks |
| 16:28 | <annevk> | great |
| 16:28 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/dom/events/EventDispatcher.h#50 There is the generic visitor which is then extended by pre and post visitors |
| 16:29 | <smaug____> | annevk: well, the setup is against the current spec |
| 16:29 | <annevk> | smaug____: oh, after event dispatch we need to cycle through the parents too? |
| 16:29 | <smaug____> | like, dispatching mouseevent 'click' manually needs to trigger links per web compatibility, but IIRC per spec it shouldn't |
| 16:30 | <smaug____> | and click() just dispatches event, and if the event wasn't cancelled, then trigger link |
| 16:30 | <annevk> | smaug____: ah yes, but that is different from click on checkbox stuff iirc |
| 16:30 | <smaug____> | annevk: yes, this setup does iterate the chain again for post phase |
| 16:32 | <annevk> | okay, so I'll first define this setup purely for getting the event path and then we can go from there |
| 16:32 | <annevk> | thanks, this is really helpful |
| 16:34 | <smaug____> | I'm rather subjective here, but the setup Gecko has (has had since 2006), has proved to be very flexible and still fast. That IDB case for example was trivial to implement. |
| 16:43 | <smaug____> | annevk: something else: do you recall if we have cases where some property or interface is hidden based on some state |
| 16:43 | <annevk> | smaug____: I don't think we do that |
| 16:44 | <annevk> | smaug____: at least, not that I'm aware of |
| 16:44 | <smaug____> | not even with this all secure context stuff |
| 16:44 | <annevk> | smaug____: there's a proposal to hide APIs for insecure contexts, yes |
| 16:44 | <annevk> | smaug____: but in that case the state would be immutable |
| 16:44 | <annevk> | Not sure if I like that though |
| 16:45 | <smaug____> | just commented in the bug, but I was just thinking the possibility to hide .history and History in shadow-iframes |
| 16:45 | <smaug____> | could be a silly idea |
| 16:49 | <annevk> | I'd think pages end up throwing on that too |
| 20:38 | <nox_> | annevk: I can do DOM if you want but HTML scares me. |
| 21:25 | <Domenic> | nox_: dive right in, HTML loves you and just wants to give you a big, big ... big ... hug |
| 21:42 | <zcorpan> | TabAtkins: how should i xref a global attribute in html in another spec with bikeshed? e.g. title="" attribute |
| 21:43 | <TabAtkins> | The same way you'd ref anything else, based on whatever linking data HTML's definition exposes. `bikeshed refs` can help. |
| 21:44 | <zcorpan> | TabAtkins: what i did in webvtt stopped working recently. see https://github.com/w3c/webvtt/commit/37cfd8bdb67972221aa6434b77bcf8a09a2177cf |
| 21:44 | <TabAtkins> | It doesn't look like HTML provides a global title definition, at least from a quick look at `bikeshed refs --spec=html --text=title`? |
| 21:46 | <TabAtkins> | Ah, I see what's happening. |
| 21:47 | <TabAtkins> | So I can explain both what went wrong, and what the correct thing to do is. |
| 21:48 | <TabAtkins> | First, correct thing: |
| 21:48 | <TabAtkins> | The global dfn *is* actually in the linking db, I just missed it. |
| 21:48 | <TabAtkins> | <a element-attr for=/>title</a> will grab it. |
| 21:49 | <TabAtkins> | Run `bikeshed refs --spec=html --text=title --type=element-attr` to find it - it's the first one. |
| 21:50 | <TabAtkins> | Second, what went wrong: |
| 21:50 | <TabAtkins> | You have title defined in your anchors block, so your autolinks were picking it up from there. |
| 21:51 | <TabAtkins> | But I recently changed things, at Anne's request (and because it made sense) so that if you specify `spec` on an autolink, it ignores any local links, because you're *very explicitly* indicating that you want a foreign link. |
| 21:52 | <TabAtkins> | And things specified in the anchors block count as "local", so now they're skipped. ^_^ |
| 21:53 | <TabAtkins> | So another way you could fix this is just to remove the `spec` attribute from your title autolinks so they can grab from your anchors block again, but that's not the best method. Do what I said above. |
| 21:54 | <zcorpan> | TabAtkins: ok, i removed these from the block and removed spec=html and added for=/, which seems to work (though it says there are multiple possibilities for lang, but only lists one)... but class gives a fatal error |
| 21:55 | <TabAtkins> | Interesting! |
| 21:55 | <TabAtkins> | Oh wait, not a crash, just an error. What's it giving? |
| 21:55 | <zcorpan> | FATAL ERROR: No 'element-attr' refs found for 'class' with for='/'. |
| 21:56 | <zcorpan> | for <a element-attr for=/>class</a> |
| 21:56 | <TabAtkins> | Yeah, run `bikeshed refs --spec=html --text=class --type=element-attr` and you'll see Bikeshed doesn't see anything like that. |
| 21:57 | <TabAtkins> | Mang where the hell is it defined? I spot only one definition of "class" of any type in HTML, and it's for microdata. |
| 21:57 | <zcorpan> | https://html.spec.whatwg.org/multipage/dom.html#classes |
| 21:59 | <zcorpan> | the id doesn't follow the same pattern as the other attributes... is that the problem? |
| 22:00 | <zcorpan> | if so, could fix it in html |
| 22:00 | <zcorpan> | but need to sleep now |
| 22:00 | <zcorpan> | will read #whatwg logs tomorrow |
| 22:02 | <smaug____> | igrigorik: ping |
| 22:02 | <smaug____> | igrigorik: are prefetch etc really supposed to work in any document |
| 22:03 | <smaug____> | and not only in documents which have browsing context |
| 22:04 | <TabAtkins> | zcorpan: Yeah, the <dfn>class</dfn> doesn't have an ID on it, so it's not an anchor, and the heading doesn't have the right ID pattern for Shepherd to auto-detect what it's about either. |
| 22:04 | <TabAtkins> | zcorpan: Just add id="attr-class" to the <dfn>class</dfn>. |
| 22:05 | <TabAtkins> | Doing the same to "style", in the next section, would be great too. |