| 01:13 | <botie> | zcorpan_, at 2015-09-14 16:21 UTC, MikeSmith said: about https://critic.hoppipolla.co.uk/r/5796 (SVG thing) yeah I've spoken with the commenter and I need to also fix the bug in the checker code |
| 08:50 | <philipj> | annevk: reviewers wondering why !important on ::background { display: block } in https://codereview.chromium.org/1372413004/ |
| 09:01 | <annevk> | philipj: I suspect anything else would lead to some undefined behavior |
| 09:01 | <annevk> | philipj: e.g., is it defined what display-table-row means for a box floating around? |
| 09:01 | <philipj> | annevk: hmm, perhaps, I'm not sure how the backdrop is actually implemented |
| 09:01 | <tobie> | robertkowalski: this is sort of a chicken and egg problem. Implementors want to use the language they're familiar with. |
| 09:02 | <philipj> | I'll link to here and let the reviewers ponder the issue |
| 09:03 | <annevk> | philipj: generally though I'd like to defer to roc when it comes to the styling issues |
| 09:03 | <tobie> | robertkowalski: …argue that they're not getting any help from Web developers, so why would they make the effort of converting everything in a new technology? |
| 09:04 | <tobie> | robertkowalski: arguably, that's circular logic of the same kind as saying you don't need to support browser X as you have no traffic using said browser (because your site doesn't work with it). |
| 09:04 | <tobie> | robertkowalski: but on the other hand, it is very possible that no one is using that browser. |
| 09:05 | <philipj> | annevk: does roc have a GitHub account? I can't find him |
| 09:05 | <tobie> | robertkowalski: if you don't have external data to validate your assumption, you can't make an informed decision. |
| 09:05 | <annevk> | philipj: rocallahan |
| 09:05 | <tobie> | robertkowalski: and thus, we're stuck with python. :) |
| 09:06 | <philipj> | annevk: thanks |
| 09:08 | <annevk> | Updating OS X has been painless thus far \o/ |
| 11:20 | <annevk> | Domenic: writing out all those URL members again is no fun |
| 11:21 | <annevk> | Domenic: also, once they're all written out, we should probably try to deduplicate some, since the repetition of requirements across four features is not great |
| 11:57 | <smaug____> | annevk: any opinion on whether an API which should work only in top level browsing context and other browsing context from the same domain should be hidden in other contexts |
| 11:57 | <smaug____> | or just no-op |
| 11:58 | <annevk> | smaug____: no-op/throw |
| 11:59 | <smaug____> | k |
| 11:59 | <smaug____> | any particular reason? |
| 11:59 | <annevk> | smaug____: e.g., APIs only allowed in "secure contexts" throw in insecure contexts |
| 11:59 | <smaug____> | I don't have any opinion on this matter :) |
| 12:00 | <annevk> | smaug____: and there might be some difficulty with low-level VM sharing stuff if the APIs we expose differ, but that's all rather theoretical at this point I believe |
| 12:01 | <smaug____> | not sure what sharing that would be about |
| 12:01 | <smaug____> | but in Gecko hiding APIs would be rather trivial |
| 12:01 | <smaug____> | (we do hide plenty of chromejs only APIs from content, and also b2g APIs) |
| 12:41 | <annevk> | smaug____: yeah I know, but I think at this point we should keep hiding for non-web stuff and have web stuff exposed everywhere |
| 12:41 | <annevk> | smaug____: PortCollection is gone from the specification btw |
| 12:41 | <smaug____> | noticed, thanks |
| 12:42 | <smaug____> | annevk: well, we certainly don't want to expose chromejs stuff |
| 12:42 | <annevk> | right |
| 13:09 | <Guest62> | hello, |
| 13:09 | <Guest62> | I need to talk with Tab Atkins, |
| 13:10 | <tscosj> | Tab, |
| 13:10 | <tscosj> | Can I talk to you rn? |
| 14:05 | <annevk> | philipj: apologies for flip-flopping on that super trivial PR |
| 14:05 | <annevk> | philipj: still up to you what you do though |
| 14:07 | <philipj> | annevk: I'll flip it back then :) |
| 15:22 | <smaug____> | !seen foolip |
| 15:22 | <smaug____> | hmm, perhaps there isn't any bot here to answer to that |
| 15:22 | smaug____ | wonders if blink doesn't event warn about /deep/ |
| 15:22 | <Ms2ger> | philipj, ^ |
| 15:24 | <smaug____> | aha, wrong nick |
| 15:28 | <caitp> | did the whole "what do we do about cross-origin uses of well-known symbols" thing on public-script-coord ever get definitively resolved? |
| 15:41 | <annevk> | caitp: no, there's a couple open issues against the HTML standard on defining cross-origin Location and Window objects |
| 15:41 | <annevk> | caitp: it's something I want to look into if nobody beats me to it, since it seems like a rather important thing to define |
| 15:47 | <caitp> | I ask because I'm not sure how flexible we need to make this "don't throw if the object needs security checks" thing needs to be |
| 15:50 | <caitp> | like, if it's good enough to just make the value look undefined/not present, or if it's important to know that the value couldn't be retrieved due to a failed access check |
| 16:10 | <annevk> | caitp: I haven't investigated |
| 16:10 | <annevk> | caitp: from past experience some folks want security errors to throw, others prefer silent failure |
| 16:18 | <TabAtkins> | caitp: I think there's supposed to be a symbol registry, where you can obtain a symbol associated with a string, and they're identical across windows when generated from the sand string? |
| 16:18 | <caitp> | right, but I mean, the spec uses well known symbol hooks, and doesn't care about whether anything is cross origin/whatever |
| 16:19 | <TabAtkins> | Yeah, the spec's "well-known symbols" are identical cross origin. |
| 16:19 | <caitp> | so it's like, 1 option is just pretend cross origin objects don't have the symbol hook at all, and that splits into "the spec'd access won't throw, it will just ignore it, but user accesses to the hook will throw" |
| 16:19 | <TabAtkins> | P sure |
| 16:20 | <caitp> | or another one is "never throw, just treat the symbol hook as undefined for cross origin objects" |
| 16:21 | <TabAtkins> | I wonder who that Guest62 person was? |
| 16:28 | <annevk> | TabAtkins: sam as tscosj most likely but not sure who that is either |
| 16:29 | <TabAtkins> | Oh, I blocked tscosj as some random pming me. |
| 16:29 | <TabAtkins> | How do I unignore? |
| 16:29 | <TabAtkins> | Also, who Sam? |
| 16:30 | <TabAtkins> | Dammit, autocorrect, I meant rando. |
| 16:35 | <annevk> | TabAtkins: s/sam/same/ |
| 16:35 | <TabAtkins> | Ah |
| 18:42 | <tobie> | TabAtkins: quick bikeshed question: Would need to add a small paragraphe to the conventions section found in the footer. Is there anyway for me to do this simply? |
| 18:43 | <TabAtkins> | tobie: Need to adjust your footer include. |
| 18:43 | <TabAtkins> | For whatever group you're publishing as. |
| 18:44 | <tobie> | Mmm. So I can't have custom, per spec conventions, then. |
| 18:46 | <tobie> | :( |
| 19:16 | <tobie> | I guess I'll just stick the content in a note somewhere. |
| 20:14 | <Domenic> | tobie: I just hide the conventions boilerplate and add my own section. |
| 21:31 | <aleray> | hi, how can I replace html entites by their equivalent unicode code point? |
| 21:32 | <aleray> | using htmllib python |
| 21:32 | <gsnedders> | aleray: htmllib or html5lib? |
| 21:33 | <gsnedders> | aleray: and what are you actually trying to do? why do you want to replace them? |
| 21:33 | <aleray> | I'm working on a filter for typography (fixing various spacing/punctuation patterns) and I get chuncked Character tokens because of HTML entities like |
| 21:34 | <aleray> | gsnedders, html5lib, sorry |
| 21:34 | <gsnedders> | aleray: you probably want to parse the whole thing into a tree and then work from that, tbh |
| 21:35 | <gsnedders> | aleray: the tokenizer alone is probably always never the way to go |
| 21:36 | <gsnedders> | aleray: basically the tokenizer makes no guarantees, and in some situations won't work correctly without the parser's feedback |
| 21:37 | <aleray> | so I I have "name : value" it seems like the tokens yield are "name" +   + ": value" |
| 21:37 | <aleray> | gsnedders, here is how I use my filter: http://dpaste.com/1WBAYG6 |
| 21:38 | <gsnedders> | the API makes no guarantees as to where character tokens get split up, FWIW |
| 21:38 | <gsnedders> | I'm pretty sure the tokenizer shouldn't return an character reference ever? |
| 21:38 | <gsnedders> | oh, you're doing this at the serialiser level |
| 21:38 | <gsnedders> | sorry, I thought you meant the tokenizer tokens |
| 21:39 | <aleray> | gsnedders, my explanations might be confused, sorry. |
| 21:40 | <gsnedders> | aleray: nah, we just have two things called "tokens" and it's really bloody confusing. |
| 21:40 | <gsnedders> | aleray: we should name stuff better, but I don't know what's better :) |
| 21:43 | <gsnedders> | aleray: um, the filter is getting three character tokens, u'name', u'\u2009', and u': value'. there's no character references there. |
| 21:46 | <gsnedders> | aleray: so that's definitely a bug in html5lib, because it shouldn't be creating adjacent text nodes in the DOM leading to that. the simplest suggestion would be to use etree (which is the default) instead of dom, if you're not wed to the tree format anywhere |
| 21:46 | <gsnedders> | aleray: then with etree you get {u'data': u'name\u2009: value', u'type': u'Characters'} which is what I'd expect? |
| 21:47 | <gsnedders> | aleray: (sorry for being a bit rambly here) |
| 21:49 | <aleray> | gsnedders, sorry, back |
| 21:50 | <aleray> | gsnedders, yes, this is exactly what I want |
| 21:50 | <aleray> | let me try |
| 21:52 | <gsnedders> | aleray: note if anyone touches the DOM you can end up with adjecent text nodes (because they can just append another) and in a few cases the HTML parser creates them (e.g., foo<table>bar</table> creates "foo", followed by "bar", followed by an empty table element) |
| 21:52 | <gsnedders> | aleray: but in that case that's just a bug in html5lib |
| 21:53 | <aleray> | gsnedders, thanks. I switched to etree and that is perfect |
| 21:53 | <gsnedders> | aleray: (etree avoids this because it /can't/ have adjacent text nodes in its data model) |
| 21:53 | <aleray> | Should this be documented somewhere? |
| 21:54 | <aleray> | I don't remember why I used dom in the first place. Maybe because it was easier to work with� |
| 21:54 | <gsnedders> | I'm filing a bug on this. |
| 21:55 | <gsnedders> | When we finally get round to having decent docs, we should push people more strongly away from dom. |
| 21:55 | <aleray> | gsnedders, let me know when you filled the bug so I can reference to it in my code |
| 21:56 | <aleray> | and just so you know I'm in love with HTML5lib |
| 21:57 | <gsnedders> | https://github.com/html5lib/html5lib-python/issues/208 |
| 21:59 | <gsnedders> | aleray: ^^ |
| 22:02 | <aleray> | gsnedders, thanks. Reference in my code. Thanks a lot for your help. It turned out to be more simple than I though :) |
| 22:06 | <gsnedders> | aleray: np, in general dom is just hidious in python |