| 00:46 | <weinig> | hi heycam |
| 00:46 | <heycam> | hi weinig |
| 00:46 | <weinig> | heycam: got a second for a WebIDL question? |
| 00:46 | <heycam> | sure |
| 00:47 | <weinig> | heycam: for a method like prepend in https://dom.spec.whatwg.org/#parentnode |
| 00:47 | <weinig> | heycam: should non-nodes that get passed to it get toString()ed? |
| 00:48 | <heycam> | weinig, I think that's right. let me check. |
| 00:48 | <weinig> | heycam: thanks! |
| 00:49 | <heycam> | weinig, so, yes. the last few steps of http://heycam.github.io/webidl/#es-union catch types that didn't match exactly |
| 00:49 | <weinig> | heycam: excellent, thanks! |
| 00:49 | <heycam> | weinig, no problem! |
| 00:50 | <weinig> | “If types includes a string type, then return the result of converting V to that type." |
| 00:50 | <weinig> | couldn’t be clearer :) |
| 00:50 | <heycam> | it's clear if you've made it all the way through the previous 15 steps :) |
| 00:50 | <weinig> | heycam: and remembered where to look |
| 00:51 | <weinig> | heycam: I was pretty sure I was right, I just couldn’t remember which part it was in |
| 07:26 | <jochen__> | annevk: i guess you found my github account meanwhile |
| 07:26 | <annevk> | jochen__: did! |
| 07:27 | <jochen__> | annevk: i'm not convinced that the referrer attribute adds much value, i'd rather first see a use case |
| 07:27 | <annevk> | jochen__: https://github.com/w3c/webappsec/issues/409 and https://github.com/w3c/webappsec/issues/413 |
| 07:27 | <jochen__> | as in a big website that wants this feature |
| 07:27 | <annevk> | jochen__: well I'd be happy if you removed it from the draft |
| 07:28 | <annevk> | jochen__: we should still figure out what the story with fetch(), service workers, and referrers is |
| 07:28 | <jochen__> | yes |
| 07:29 | <annevk> | Setting same-origin URLs works fine, until you hit CSS. I'm not entirely sure what to do there and it seems to be a problem for service workers too. At least, the current model violates SOP (same for resource timing)... |
| 07:30 | <annevk> | Perhaps "no-cors" cross-origin CSS subresources should simply skip the service worker... And if you want them to go through you need CORS. |
| 07:30 | <jochen__> | what's the problem with css? |
| 07:30 | <annevk> | jochen__: https://github.com/slightlyoff/ServiceWorker/issues/719 |
| 07:31 | <annevk> | jochen__: and https://github.com/w3c/webappsec/issues/413 |
| 07:31 | <annevk> | jochen__: (the referrer for CSS subresources is the stylesheet, not the document) |
| 07:31 | <jochen__> | ah, the sheet itself is from another origin |
| 07:31 | <jochen__> | but the service worker sees what it loads |
| 07:31 | <annevk> | yeah |
| 07:31 | <annevk> | well, at least as currently defined |
| 07:32 | <jochen__> | not telling the service worker about those seems like the way to go |
| 07:32 | <annevk> | But I guess even with CORS CSS, setting the referrer for its subresources would be problematic |
| 07:32 | <annevk> | So perhaps we should only allow copying the referrer from incoming Request objects |
| 07:33 | <annevk> | Gotta go for a bit |
| 07:33 | <jochen__> | yeah, so the only actual use case I know for changing the referrer to something entirely else is G+ |
| 07:33 | <slightlyoff> | you need to test that in the wild. |
| 07:33 | <jochen__> | and they don't want to set it to something on the same origin, but to something else |
| 07:33 | <slightlyoff> | i have a guess that font cdns care about referrer |
| 07:33 | <jochen__> | i.e. they would like to have plus.url.google.com as outgoing referrer |
| 07:34 | <slightlyoff> | (particularly the licensed kind) |
| 07:45 | <MikeSmith> | hayato: わあああー😲 |
| 07:45 | <kochi> | yey! |
| 07:45 | <kochi> | yay! |
| 07:46 | <hayato> | If you are watching GitHub w3c/webcomponents repository, I'm very sorry for spamming :) |
| 07:46 | <MikeSmith> | now he says he's sorry! :-) |
| 07:47 | <hayato> | In the next, I'll mark all migrated bugs on bugzilla "MOVED". |
| 07:47 | <MikeSmith> | yay! nice to have something to look forward to! |
| 07:48 | <MikeSmith> | hayato: just kiddingーI'm very glad to see these getting migrated to github |
| 07:48 | <MikeSmith> | thanks for doing it |
| 08:04 | <annevk> | jochen__: so the problem is that service workers reset the referrer due to fetch() |
| 08:04 | <annevk> | jochen__: so for a site with a service worker the referrer will always be the service worker |
| 08:05 | <annevk> | jochen__: I think we want that to change |
| 08:07 | <MikeSmith> | oops in hindsight I guess we should have temporarily disabled bugzilla bugmail to public-webapps |
| 08:07 | <MikeSmith> | too late now I reckon |
| 08:10 | <annevk> | I guess I'm gonna mark w3c/webcomponents as read |
| 08:10 | <annevk> | That's too much |
| 08:11 | <Domenic> | I thought we did disable it... |
| 08:14 | <annevk> | Yeah, not super cool this |
| 08:19 | <MikeSmith> | Domenic: yeah was just now talking to the webapps team contact; it seems they disabled it on the component but not on all the existing bugs |
| 08:23 | <hayato> | Hmm. it looked public-webapps received the mass mail flood again. |
| 08:24 | <hayato> | Sorry for that. I though the mail was disabled as per https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0006.html |
| 08:24 | <hayato> | Yes, I've finished. |
| 08:27 | <hayato> | xiaoqian told me that it was not removed from *every* bugs. |
| 08:27 | <MikeSmith> | hayato: no worriesー not your fault, yeah |
| 08:28 | <MikeSmith> | I should have checked on it myself ahead of time |
| 08:29 | <Domenic> | annevk: would it be interesting to have GitHub auto-notify about commits to whatwg repos in this channel? Or would that interfere with the flow of discussion? |
| 08:29 | <annevk> | jochen__: it seems kind of okay to tie the referrer thing to public suffixes, though sleevi might have a fit :p |
| 08:30 | <annevk> | Domenic: might be fun to try |
| 08:30 | <hayato> | MikeSmith: NP. I also should have tested it with a small number of the bugs. If we have a next chance, I think we can do better in the next time. :) |
| 08:31 | <Domenic> | I guess people can already watch those with twitter, hmm |
| 08:31 | <MikeSmith> | hayato: no blood was spilled, so I think everybody will survive :) |
| 08:36 | <annevk> | MikeSmith: "e.g." is usually followed by a comma? |
| 08:37 | <MikeSmith> | annevk: yeah, it always is, actually |
| 08:37 | <annevk> | MikeSmith: huh, okay |
| 08:37 | <annevk> | MikeSmith: "forbidden response-header name" why no hyphen after forbidden? |
| 08:37 | <MikeSmith> | Just like "for example" is |
| 08:38 | <annevk> | MikeSmith: or between same-origin and data-URL in "same-origin data-URL flag" |
| 08:39 | <MikeSmith> | well those are sorta special cases, in part because they're unambiguous without yet another hyphen in there |
| 08:40 | <MikeSmith> | I think they might actually be more confusing if there were additional hyphens there |
| 08:42 | <MikeSmith> | because "same-origin" is a unit of meaning as a term, and "data url" is a unit ofmeaning as a term |
| 08:43 | <MikeSmith> | The extra hyphen would obscure those meanings |
| 08:44 | <MikeSmith> | if y'all do set up IRC notifications for any github repos here, I recommend you use the github option to send them as IRC Notices rather than regular messages (that would show up as "real" channel activity in people's clients) |
| 08:45 | <hayato> | I'll send an announce mail about the migration to public-webapps soon after I update the links to the bugs on the Custom Elements and HTML Imports editor's draft. |
| 08:45 | <MikeSmith> | and "forbidden response-header name" because I think you also already got "response-header name" there as a term |
| 08:46 | <MikeSmith> | So "forbidden" is modifying that existing term |
| 09:27 | <Domenic> | annevk: how do you convert svgs to pngs usually |
| 09:27 | <annevk> | Domenic: I use some online service, but reportedly it's not very good |
| 09:28 | <Domenic> | I can use an optimizer after the initial conversion, just need to get that done |
| 09:28 | <annevk> | Domenic: as in, I use one of the first search results for that question |
| 09:28 | <annevk> | Domenic: and I use 500x500 as output size, to avoid most scaling artifacts |
| 09:29 | <Domenic> | and what is the best png crusher these days... eric lawrence has opinions, i know |
| 09:29 | <annevk> | I guess if you're on Windows you can use his stuff |
| 09:30 | <annevk> | The only reason we even have PNG is Twitter |
| 09:31 | <Domenic> | They probably recompress to jpg anyway lol |
| 09:41 | <annevk> | davve: Domenic: hah, I see now why it had the extra <path> bits, the original didn't render in Firefox |
| 09:42 | <annevk> | I wonder what caused that |
| 10:08 | <Domenic> | yeah that seems kind of bad |
| 11:36 | <MikeSmith> | SimonSapin: regarding application/xhtml+xml, https://bugzilla.mozilla.org/show_bug.cgi?id=1180623 seems relevant to what you were asking about the other day, as far as if there's content relying on application/xhtml+xml and if Servo should support it |
| 11:37 | <MikeSmith> | SimonSapin: as far as I can tell from the bug description that Julien wrote there, mobile GMail at least must be using application/xhtml+xml for something for some reason |
| 11:39 | <MikeSmith> | of course that bug's also relevant in the context of what should be done in cases where the application/xhtml+xml being served isn't well-formed XML |
| 11:43 | <MikeSmith> | anyway we still have to wonder (1) why Gmail is serving anything as application/xhtml+xml to begin with, and (2) whatever UAs they're intending it for must not actually be parsing it as XML, because otherwise they'd be choking on it too, so why don't they just serve it as text/html to them |
| 12:23 | <SimonSapin> | thanks for the pointer MikeSmith |
| 12:27 | <annevk> | philipj: not sure how to answer your window.event questions |
| 12:27 | <philipj> | annevk: to put it differently, is there anything I can do? |
| 12:29 | <philipj> | if there's a particular pattern of usage seen in some bug report, I could search for that in httparchive |
| 12:29 | <philipj> | but coming up with a use counter that's a good proxy of the risk seems tricky in this case |
| 12:34 | <Domenic> | SimonSapin: Ms2ger: why is Servo doing XML5 instead of just HTML? |
| 12:40 | <Ms2ger> | I would be very surprised if we never needed any xml |
| 12:46 | <jgraham> | Although I think the answer to "why now" is more or less "someone wrote a patch" |
| 12:50 | <Domenic> | Ms2ger: why? assuming "HTML" = HTML + SVG (+ MathML if you want) |
| 12:51 | <jgraham> | Because XML does occasionally get used? Not just through top-level documents |
| 12:52 | <jgraham> | I mean Chrome can't even remove XSLT afaik which is even less common |
| 12:52 | <Domenic> | But ... you have no concrete examples? |
| 12:52 | <Domenic> | IIRC XSLT and SVG are the only things in chrome we need libxml for |
| 12:53 | <Domenic> | Seems like a lot to add to a browser without any actual use cases yet, is what confuses me. |
| 12:53 | <JonathanNeal> | Hypothetically, would the selector weight of `.element:media( min-width: 30em )` be any heavier than the selector weight of `.element` ? Re: http://htmlpreview.github.io/?https://github.com/ResponsiveImagesCG/container-queries/blob/master/index.html |
| 12:54 | <jgraham> | https://golem.ph.utexas.edu/~distler/blog/ is a concrete example |
| 12:54 | <Domenic> | jgraham: sure, but that can be parsed with the HTML parser |
| 12:55 | <Domenic> | No need for XML5 |
| 12:56 | <jgraham> | It's not obvious to me that's true without trying it |
| 12:57 | <jgraham> | But we at least all agree that you today can't ship a browser without XML support |
| 12:57 | <jgraham> | And someone offered to implement XML5 in a way that would integrate with Servo |
| 12:57 | <jgraham> | So I'm not sure what the discussion here is |
| 12:58 | <Domenic> | jgraham: I tried it in IE, it works fine |
| 12:59 | <Domenic> | jgraham: if this is just a way of helping a new collaborator feel welcomed, that's fine. I'm questioning whether XML is actually something the web platform needs, and surprised Servo's answer is "yes, and also we invented a new dialect of it that nobody else supports." |
| 12:59 | <benjamingr> | mathiasbynens: hey, if you're here by any chance we have a RegExp with 'u' flag question for you :) |
| 12:59 | <Domenic> | We're actively trying to remove it in Chromium. |
| 13:01 | <jgraham> | If you manage to remove it in Chromium then I'm sure people will be happy to turn it off in Servo |
| 13:01 | <jgraham> | Servo isn't exactly in a position to influence content authors today |
| 13:01 | <Domenic> | Fair enough |
| 13:01 | <jgraham> | OTOH XML5 seems like an experiment worth running |
| 13:02 | <Domenic> | IE never implemented it for HTML, is also my point. |
| 13:03 | <Domenic> | But I guess it's all the rage to be compatible with WebKit/Blink these days instead of Gecko or IE :-/ |
| 13:05 | <mathiasbynens> | benjamingr: shoot |
| 13:06 | <benjamingr> | mathiasbynens: we're working on RegExp.escape and we're wondering if/why we need to escape a-fA-F at the start of terms. https://github.com/benjamingr/RegExp.escape/pull/35 |
| 13:06 | <mathiasbynens> | Domenic: iirc IE does support XHTML nowadays but sure, long after people stopped caring |
| 13:06 | <Domenic> | mathiasbynens: hmm I was almost certain I read some Edge stuff on them doubling-down on not supporting XHTML |
| 13:07 | <gsnedders> | IE added support in 8 or something |
| 13:08 | <Domenic> | ah yep, my bad, in version 9. http://blogs.msdn.com/b/ie/archive/2010/11/01/xhtml-in-ie9.aspx |
| 13:11 | <benjamingr> | mathiasbynens: thanks, are there any special cases we need to be aware of with the "u" flag? |
| 13:12 | <philipj> | Domenic: in terms of usage getting rid of XSLT seems like a possibility, but that blink-dev thread sure did generate a lot of negative feedback |
| 13:13 | <Domenic> | philipj: we did showModalDialog, I am (over-)optimistic that if we take a bit to recover we can do XSLT :) |
| 13:13 | <philipj> | assuming that XSLT is gone, do you have any hunch about the additional risk of scrapping XML as a whole, e.g. by replacing it by some new (or old?) HTML insertion mode? |
| 13:13 | <Domenic> | my hunch is that we can't know before we try parsing SVG as HTML |
| 13:14 | <Domenic> | I see no obvious problems with that, but it really needs to be tried before we can say anything |
| 13:14 | <philipj> | That does seems pretty doable, since it already happens for SVG in HTML |
| 13:14 | <Domenic> | After SVG and XSLT... I guess the news that IE has been supporting XHTML syntax since version 9 is a bit worrying |
| 13:15 | <Domenic> | But most people write their XHTML as "polyglot" |
| 13:15 | <philipj> | In other contexts, I guess there's little chance of content depending on XML parsing to fail, so it's down to cases where a new HTML parser mode would result in a different DOM than an XML parser |
| 13:15 | <Domenic> | Yeah, stuff like <div /> |
| 13:15 | <philipj> | Yeah :/ |
| 13:16 | <Domenic> | But as I said, mostly polyglot, probably fine... |
| 13:16 | <philipj> | Probably |
| 13:16 | <Domenic> | After SVG, XSLT, XHTML, I don't think there's anything left... |
| 13:16 | <philipj> | Getting rid of XSLT seems worthwhile on its own, since that also adds a libxslt dependency |
| 13:16 | <Domenic> | Chrome doesn't support RSS (and I hear that needs a forgiving parser these days anyway)... |
| 13:17 | <Domenic> | +1 |
| 13:17 | <philipj> | So you just need to trick someone into thinking that removing XSLT is a good way to get love and praise from web developers |
| 13:18 | <philipj> | Usage: |
| 13:18 | <philipj> | https://www.chromestatus.com/metrics/feature/timeline/popularity/78 |
| 13:18 | <philipj> | https://www.chromestatus.com/metrics/feature/timeline/popularity/79 |
| 13:19 | <Domenic> | Are there warnings yet? |
| 13:19 | <philipj> | Nope |
| 13:20 | <Domenic> | 0.005 seems risky but maybe it could be cut further with warnings |
| 13:20 | <philipj> | Deprecation messages don't seem very effective, but if we add in a date of removal and make it a very long deprecation window (a year?) it might work out |
| 13:20 | <Domenic> | But, I imagine we shouldn't do this until the team has had more time to recover from showModalDialog; that took a lot of fortitude. |
| 13:21 | <Domenic> | Hmm, I feel like I saw several graphs where deprecation messages made a difference. Maybe it was just showModalDialog though. |
| 13:21 | <philipj> | Yeah, I'm not volunteering to tackle this at least, not now :) |
| 13:22 | <philipj> | Well, sometimes my best explanation for a big drop has been "maybe someone saw a warning", but in most cases it seems to make no difference at all |
| 13:22 | <philipj> | In particular when usage is already low that's to be expected, because very few people will even see the warning |
| 13:25 | <MikeSmith> | I believe hsivonen_ is one of the people who's been opposed to the "solution" of parsing application/xhtml+xml through the HTML parser |
| 13:26 | <MikeSmith> | he's suggested that if we're going to do something about the problem, it should be to implement XML5 parsers |
| 13:27 | <MikeSmith> | i.e., pretty much what the Servo team is trying (as far as I understand) |
| 13:27 | <mathiasbynens> | benjamingr: i think the patch covers it |
| 13:27 | <philipj> | Might it be an option to make an XML5 parser as a mode of the HTML parser? |
| 13:27 | <benjamingr> | mathiasbynens: thanks! |
| 13:27 | <mathiasbynens> | benjamingr: only other thing that’s important here is \u{…} syntax which i believe is already covered by escaping 0-9a-fA-F |
| 13:28 | <Domenic> | MikeSmith: hmm now I am trying to figure out what the differences are between XML5 parsing XHTML and the HTML parser parsing XHTML |
| 13:28 | <Domenic> | MikeSmith: I guess if XML5 is just XML with error handling, then it would treat <div/> as <div></div> |
| 13:28 | <benjamingr> | mathiasbynens: thanks! Any feedback on the repo and proposal would be greatly appreciated in general. |
| 13:28 | <MikeSmith> | Domenic: see https://bugzilla.mozilla.org/show_bug.cgi?id=1044332#c5 for Henri's comments < philipj |
| 13:29 | <philipj> | MikeSmith: thanks! |
| 13:29 | <MikeSmith> | Domenic: yeah I think so. But we don't have to speculate because there's actually a spec |
| 13:29 | MikeSmith | looks for the current spec URL |
| 13:30 | <MikeSmith> | I think the dev who implemented the Sever XML5 parser worked from Anne's XML5 spec but updated the spec in teh process |
| 13:30 | <Domenic> | MikeSmith: well, "I'd rather see e.g. Blink bear the cost of trying something as radical as getting rid of XSLT or XML parsing instead of us bearing the cost of discovering the impact of such feature removals from the platform." heh |
| 13:30 | <philipj> | Domenic: "Google Maps was what forced some other engines to add XSLT after Trident and Gecko..." says https://bugzilla.mozilla.org/show_bug.cgi?id=1044332#c5 |
| 13:30 | <philipj> | Any idea if they're still a user? |
| 13:31 | MikeSmith | has no idea |
| 13:31 | <Domenic> | philipj: seems unlikely... if they were we could probably wipe out the remaining 0.005 with one well-placed internal cake delivery, haha |
| 13:32 | <philipj> | It does seem unlikely, indeed. On that topic, getting data on which URLs actually trigger use counters would provide a path forward on many issues like this |
| 13:33 | <MikeSmith> | but the context of some recent gecko bugs over the last couple years is that Gmail is sending application/xhtml+xml for some things to some mobile UAs, including Firefox Mobile |
| 13:33 | <philipj> | MikeSmith: Opera Presto had the same problem, and fixed it by reparsing as HTML I think |
| 13:34 | <MikeSmith> | philipj: yeah that's not a fix though |
| 13:34 | <philipj> | Well, not a nice one :) |
| 13:34 | <MikeSmith> | yeah, but also because it just doesn't work in many cases |
| 13:34 | <MikeSmith> | I think it also has security issues |
| 13:35 | <philipj> | I don't know in which contexts it would happen, but apparently it worked well enough for us to attempt it |
| 13:35 | <philipj> | Although maybe there was a button one had to press to reparse as HTML, I can't recall |
| 13:35 | <MikeSmith> | we should try to get Ygg01 on here (dev who implemented XML5 parsing for Servo) |
| 13:35 | <philipj> | Doesn't matter now, anyway |
| 13:35 | <MikeSmith> | yeah |
| 13:36 | <MikeSmith> | https://github.com/Ygg01 |
| 13:36 | <MikeSmith> | Domenic: philipj https://github.com/Ygg01/xml5_draft |
| 13:36 | <MikeSmith> | https://ygg01.github.io/xml5_draft/ |
| 13:36 | <Domenic> | philipj: https://www.chromium.org/developers/design-documents/rappor may help, but on the other hand it seems like it might fail in precisely these low-numbers use cases |
| 13:38 | <MikeSmith> | Ygg01 also has an XML5 test suite at https://github.com/Ygg01/xml5lib-tests |
| 13:38 | <philipj> | Domenic: I've been hearing about Rappor+UseCounter for a while now, but nothing has surfaced outside of Google at least. |
| 13:39 | <MikeSmith> | the spec at https://ygg01.github.io/xml5_draft/ is modified from the XML5 spec that Anne originally wrote, and I recall that the changes to it that Ygg01 were also discussed with Anne |
| 14:12 | <annevk> | "just HTML" is not a solution that actually works for SVG, XMLHttpRequest, etc. |
| 14:13 | <annevk> | Seems far too difficult to do anything like that. XML5 + enhancements is a much saner path... |
| 14:14 | <annevk> | philipj: I don't know :-/ |
| 14:14 | <annevk> | philipj: counting the getter was what I would have suggested, but that seems to return surprising results |
| 14:15 | <philipj> | annevk: indeed. one could also count only the cases where it returns something other than undefined, but I'd be surprised if that came back with a tiny number |
| 14:15 | <philipj> | how badly do you want to avoid spec'ing this and adding it to Gecko? |
| 14:16 | <annevk> | philipj: well, DOM peers have stated they don't want to add it |
| 14:16 | <annevk> | philipj: and it's not exactly a sane extension of the event model, so I guess I'd like to avoid it pretty badly |
| 14:32 | <Domenic> | annevk: I am not convinced "just HTML" does not work. But we will see. |
| 14:34 | <SimonSapin> | Domenic: wanna try it in Canary? :) |
| 14:34 | <SimonSapin> | We can try it in Servo, but results won’t be as conclusive… |
| 14:35 | <Domenic> | SimonSapin: I do! I am not the right expertise for that though. I think TabAtkins was mentioning trying it for SVG recently... |
| 14:42 | <philipj> | annevk: well, ok, do you know of any site compat issues in Gecko due to it not being supported? that would be a good indicator of what would break with removal... |
| 14:42 | <annevk> | philipj: no, that's the thing |
| 14:42 | <philipj> | nothing at all? very strange |
| 14:43 | <annevk> | philipj: there might have been one report, linked from that Bugzilla ticket |
| 14:43 | <philipj> | do you know if anyone has looked into the history of it, who added it first and why it was copied? |
| 14:43 | <annevk> | Domenic: it needs to be more than "just HTML", the processing model can't be that of text/html |
| 14:43 | <annevk> | Domenic: at least not as text/html stands today |
| 14:43 | <annevk> | philipj: it's part of Microsoft's legacy event model |
| 14:44 | <annevk> | philipj: Opera/WebKit copied it for some reason |
| 14:44 | <annevk> | philipj: I guess they hit some IE code paths that Gecko did not |
| 14:44 | <philipj> | annevk: I guess finding that reason would be interesting, but takes a bit of work |
| 14:45 | <annevk> | philipj: there's a pretty long discussion in BTS about removing it too |
| 14:45 | <philipj> | annevk: bugs.opera.com? |
| 14:45 | <annevk> | philipj: yeah |
| 14:45 | <philipj> | link? |
| 14:45 | <annevk> | philipj: Joao might know |
| 14:45 | <annevk> | I no longer have access |
| 14:45 | <philipj> | Makes sense :) |
| 14:46 | <philipj> | OK, found it |
| 14:46 | <annevk> | I had access until the Blink thing happened, didn't really make sense to me anymore at that point, but I guess it would've been useful still from to time for historical perspective |
| 14:47 | <philipj> | well here Joao says "window.event goes hand with hand with attachEvent" and attachEvent is long gone |
| 14:47 | <philipj> | if it was ever supported in Presto or WebKit, I don't know |
| 14:48 | <annevk> | attachEvent used to be supported in Presto at least |
| 14:49 | <philipj> | you're right, looks like it was 'til the end |
| 15:39 | <annevk> | MikeSmith: you still around? |
| 15:40 | <annevk> | MikeSmith: I wonder why you didn't add hyphens for "HTTP network fetch" |
| 15:45 | <MikeSmith> | annevk: I reckon I just overlooked that one |
| 15:45 | <MikeSmith> | Will take a look when I get back to my pc |
| 15:46 | <annevk> | MikeSmith: I'm going to commit this first pass in a bit, I guess I can leave the issue open |
| 15:46 | <MikeSmith> | k |
| 16:27 | <MikeSmith> | annevk: yeah not sure how I missed that |
| 16:28 | <MikeSmith> | "HTTP network or cache fetch" definitely should be "HTTP-network-or-cache fetch" |
| 16:28 | <MikeSmith> | and so "HTTP network fetch" should be "HTTP-network fetch" |
| 16:28 | <MikeSmith> | will make another PR |
| 16:29 | <MikeSmith> | and also see if there's any others I missed |
| 16:29 | <annevk> | MikeSmith: I listed a couple of likely candidates |
| 16:30 | <MikeSmith> | oh |
| 16:30 | <MikeSmith> | where? |
| 16:30 | <MikeSmith> | "HTTP new header syntax" should be "HTTP new-header syntax" |
| 16:31 | <annevk> | MikeSmith: https://github.com/whatwg/fetch/issues/63#issuecomment-118905099 |
| 16:31 | <annevk> | MikeSmith: gotta go for a bit now |
| 16:31 | MikeSmith | looks |
| 16:31 | <MikeSmith> | hai |
| 16:40 | <JonathanNeal> | Once upon a time, I recall there being hypothetical pseudo-classes like :section and :heading. What happened to those? |
| 16:42 | <TabAtkins> | Domenic: The *other* Dominic is now kinda-sorta in charge of investigating ripping out our XML implementation and replacing with something else. "Just HTML" for SVG is the leading option there, but it doesn't work for the other cases; we're looking at XML5 or the Sky parser. |
| 16:44 | <TabAtkins> | "Just HTML" should work for pretty much all SVG in the wild. Not sure what it does to arbitrary namespaces for scripting. |
| 16:46 | <TabAtkins> | annevk: Sorry for the delay in Bikeshed fixes; got wrapped up in more holiday stuff than I anticipated, and so didn't get time to work on BS. Will handle it this morning when I get into the office. |
| 16:56 | <JonathanNeal> | TabAtkins: you were the one who told me about :section and :heading - are they dead? Replaced by custom selectors? |
| 17:25 | <TabAtkins> | JonathanNeal: Yeah. |
| 18:18 | <TabAtkins> | annevk: For real, tho, just force-generate your spec if Bikeshed is erroring incorrectly. `bikeshed -f spec`. It tries its best to fail gracefully and minimally when you force-generate. |
| 18:41 | <TabAtkins> | So, good idea or bad idea: I need context information from a class to do some functions properly, but most/all can *also* be done without that context info. So I'd like to both have all the functions as methods, *and* as unbound functions that don't need a class passed in. |
| 18:42 | <TabAtkins> | (Main reason for this is that I've already written them all as unbound methods, and used them throughout my codebase, and don't want to have to rewrite everything to use an object, even tho the object is available everywhere I'm using these functions.) |
| 18:43 | <TabAtkins> | Python's metaprogramming is... shifty, and I'm not sure how crazy this idea is in it. In JS I'd be able to handle it no problem. |
| 18:55 | <jwalden> | (repeating from Friday) peoples! if I were unsure whether getBoundingClientRect().top could ever be -0, do people think it'd make more sense to file the bug on getBoundingClientRect, or on DOMRect? |
| 18:55 | <annevk> | jwalden: file bugs on the former, but also the latter if it's unclear about negative values |
| 18:55 | <annevk> | jwalden: forgot to reply earlier, sorry |
| 18:55 | <jwalden> | k |
| 18:56 | <jwalden> | no worries :-) |
| 18:56 | <jwalden> | I mean, this was clearly P0 and all, but somehow the world managed to carry on |
| 18:59 | <jgraham> | TabAtkins: If you have an object instance you can call static methods on it, no problem |
| 19:00 | <jgraham> | (otoh, I am not a big fan of static methods at the best of toimes; the python idiom is just to use a function) |
| 19:01 | <TabAtkins> | jgraham: They're *currently* all functions and called as such, and I'm trying to avoid rewriting the world just to attach some of them to an object as well. |
| 19:05 | <annevk> | TabAtkins: "just HTML" clearly doesn't work for all SVG in the wild due to the <html> and <body> elements you get for free and the sizing that implies |
| 19:05 | <annevk> | TabAtkins: unless something changed about CSS' layout model that I missed |
| 19:05 | <JonathanNeal> | CSS has locked densities for pixels, right? Does that mean there is no equivelent to a dp: Density-independent Pixel? |
| 19:06 | <jgraham> | TabAtkins: Seems like you can just import the module they're in and call them rather than doing magic |
| 19:06 | <jgraham> | (I meean magic also works, but I can't recommend it) |
| 19:08 | <TabAtkins> | jgraham: Yeah, I'm already doing that. Let me elaborate: Because LXML sucks, I have a module that reimplements useful parts of DOM on top of LXML's stupid tree API. You pass the element you're working on as the first argument, etc. |
| 19:09 | <TabAtkins> | But some of the methods can do more if given appropriate context. For example, my check for whether something is an "opaque" element (shouldn't have its contents processed, like <script>) defaults to just a few HTML elements, but Bikeshed lets you specify custom elements as opaque, if you're gonna do processing on them in another tool afterwards. |
| 19:09 | <TabAtkins> | That metadata is stored on the document. I could move all the DOM methods to the document class, but then I'd have to rewrite every usage of them to call off of the document object, while today they're just function calls. |
| 19:10 | <TabAtkins> | Thinking of just putting them all under a document class, then using metaprogramming to define function equivalents of all of them that pass None as the self arg for you, so I dont' need to make any code changes. |
| 19:22 | <TabAtkins> | annevk: Sorry, when I say "just HTML", I'm implying "with minor parser changes to recognize <svg> as the first tag and switch directly to the foreign-content parser rather than generating the HTML implied elements". |
| 19:26 | <jwalden> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28918 |
| 19:27 | <TabAtkins> | JonathanNeal: What do you mean? |
| 19:27 | <JonathanNeal> | I don’t think I knew what I meant. I was just learning about Android’s DP unit and trying to understand it in the context of CSS. |
| 19:29 | <TabAtkins> | Android's dp unit is basically equivalent to the px unit. |
| 19:29 | <TabAtkins> | In that it gives an angular-based measurement of the screen, so that you subtend the same visual space on different-resolution devices. |
| 19:29 | <JonathanNeal> | Yeap. |
| 19:32 | <jwalden> | px got redefined to be non-angular, didn't it? |
| 19:39 | <jwalden> | also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28919 for the DOMRect side of things |
| 19:53 | <TabAtkins> | jwalden: It got defined to be a fixed ratio with the "in" unit. Whether that means it's no longer an angular measure, or that "in" is now an angular unit, depends on what unit you're anchoring the set with. |
| 19:56 | <boogyman> | jwalden: what's the difference between 0 and -0? |
| 19:56 | <TabAtkins> | boogyman: The sign. |
| 19:56 | <TabAtkins> | ^_^ |
| 19:56 | <jwalden> | boogyman: divide a finite number by either |
| 19:56 | <jwalden> | boogyman: 1 / 0 === Infinity; 1 / -0 === -Infinity |
| 19:57 | <boogyman> | cheers |
| 19:57 | <jwalden> | boogyman: short of such division, or a copysign sort of operation, or in JS Object.is that compares using SameValue semantics, it's not super-observable |
| 19:57 | <jwalden> | but we must never forget that it is a spec we are expounding |
| 19:57 | <jwalden> | ;-) |
| 20:19 | <jsbell> | Ms2ger: while you're reviewing: https://critic.hoppipolla.co.uk/r/5430 |
| 20:19 | <jsbell> | (also: thanks!) |
| 20:21 | <Ms2ger> | Oh yes, that |
| 20:22 | <Ms2ger> | I'm wondering if we should just always use the \\btestharness.js pattern |
| 20:23 | <jsbell> | Ms2ger: I don't know the history of how clever we're trying to be, but sgtm |
| 20:23 | <Ms2ger> | jgraham, ^ |
| 20:36 | <jsbell> | Ms2ger/jgraham: what's the process/timeline for updating the rev of testharness.js that wpt pulls in as a submodule? Anything I should do? |
| 20:46 | <jgraham> | jsbell: It's just "commit the submodule update and push", if you can do that, or ask someone who can if you can't |
| 20:47 | <jgraham> | I guess I don't really know what the right thing to do with that PR is; I think it's fine as is, but it's maybe a matter of taste if we go with the more strict version where possible |