| 12:18 | <zcorpan> | it seems webkit and blink skip <script> blocks when sniffing for encoding decl - <script>/*<meta charset="iso-8859-15">*/</script> |
| 12:25 | <zcorpan> | or at least the effect is that document.characterSet in that case is windows-1252 |
| 12:26 | <zcorpan> | hmm i suppose i should write tests in https://github.com/html5lib/html5lib-tests/tree/master/encoding |
| 12:27 | <zcorpan> | are those in wpt also? |
| 12:28 | <gsnedders> | no, partly because they're a total mess :\ |
| 12:28 | <gsnedders> | we really need to deal with having tests for what the pre-scan is expected to find for a given pre-scan length, and what the eventual encoding at the end of parsing is |
| 12:31 | <zcorpan> | gsnedders: so what should i do if i want to write new tests for https://github.com/whatwg/html/issues/1438 ? |
| 12:32 | <gsnedders> | a) cry. b) ??? c) write tests. |
| 12:33 | <zcorpan> | i could write straight wpt tests |
| 12:35 | <zcorpan> | though it seems attractive to write in html5lib-test format and have a script generate wpt files |
| 13:24 | <JakeA> | annevk: are you doing anything fetch specific at TPAC? If not, happy to slant the service worker meeting towards fetch issues that are vaguely SW related |
| 13:27 | <JakeA> | MikeSmith: payments meeting not on today? |
| 13:27 | <JakeA> | (I realise I missed the first half) |
| 13:54 | <annevk> | JakeA: was thinking we should have a session at some point |
| 13:54 | <annevk> | JakeA: nothing organized though, so sounds good |
| 15:56 | <marti_> | Hi! |
| 15:56 | <marti_> | I would like to work in this issues https://github.com/whatwg/html/issues/507 |
| 15:56 | <marti_> | my github account marti1125 |
| 16:42 | <annevk> | marti_: you should be able to work on it by creating a fork |
| 16:43 | <annevk> | marti_: and then creating a PR with your commits that implement the required changes |
| 16:43 | <annevk> | marti_: if you're not familiar with pull requests, I found this that will probably help you out: https://yangsu.github.io/pull-request-tutorial/ |
| 16:44 | <annevk> | (also, hi!) |
| 16:46 | <marti_> | thanks :D |
| 16:47 | <marti_> | for Remove top-level ForceType text/html is only remove this line https://github.com/whatwg/html/blob/master/.htaccess#L3 |
| 16:47 | <marti_> | or remove all ForceType text/html |
| 16:52 | <Domenic> | marti_: just that line : |
| 16:52 | <Domenic> | :) |
| 16:54 | <marti_> | ok thanks!! |
| 16:55 | <marti_> | I will send a PR from my fork master to master |
| 16:55 | <marti_> | or I have to create a new branch=? |
| 16:55 | <Domenic> | marti_: either will work, but creating a new branch will be easier for you if you want to work on other things in the future. Then you can do one branch per thing. |
| 21:09 | <Domenic> | It's here!! https://heycam.github.io/webidl/ \o/ yay tobie |
| 21:10 | <tobie> | :) |
| 21:10 | <jyasskin> | \o/ |
| 21:12 | <smaug> | mkwst: ping |
| 21:13 | <tobie> | Domenic: favorite glitch so far: Function (https://heycam.github.io/webidl/#Function) randomly referencing a Houdini spec. |
| 21:14 | <Domenic> | nice :P |
| 21:18 | KiChjang | thought "houdini spec" was a joke |
| 21:18 | <KiChjang> | apparently it's real |
| 21:32 | <tobie> | KiChjang: well, I certainly wish it would magically disappear from the references on the spec. :D |
| 21:35 | <jyasskin> | tobie: I'm sending the Houdini spec a change to avoid re-defining Function. |
| 21:36 | <tobie> | jyasskin: oh, is _that_ why it's happening? |
| 21:36 | <jyasskin> | Do I shave the yak that URL has <dfn for=url>url</dfn> instead of just <dfn>url</dfn>? |
| 21:40 | <tobie> | jyasskin: fwiw, filed an issue against Bikeshed here the other day https://github.com/tabatkins/bikeshed/issues/803 |
| 21:40 | <tobie> | jyasskin: might want to reference in your PR so TabAtkins knows what's up. |
| 21:41 | <Domenic> | Still seems like argument names to Web IDL methods should never link to IDL terms defined elsewhere |
| 21:41 | <jyasskin> | tobie: It's not really a bug in Bikeshed: https://drafts.css-houdini.org/worklets/#dom-function-arguments has `<dfn class="nv idl-code" data-dfn-for="Function" data-dfn-type="argument" data-export="" id="dom-function-arguments">arguments</dfn>`, which says any other use of Function/arguments should link to there. |
| 21:42 | <jyasskin> | Houdini shouldn't be re-defining a name that's defined more authoritatively in WebIDL. |
| 21:42 | <tobie> | jyasskin: I agree with Domenic, though. |
| 21:43 | <jyasskin> | Is there never a case that you want to refer to a function's argument from another spec? |
| 21:43 | <jyasskin> | I agree it's probably rare. |
| 21:45 | <tobie> | I don't really have an opinion beyond wanting to get rid of a reference to worklets in WebIDL. :D |
| 21:52 | <Domenic> | I guess some specs do the thing where they have a table of arguments with a bunch of non-normative text about them :-/ |
| 21:52 | <Domenic> | Probably they should never export it |
| 21:52 | <TabAtkins> | tobie: I'm answering that issue right now. ^_^ |
| 21:53 | <TabAtkins> | Not a glitch - the Houdini spec defines a callback named Function already, so Bikeshed is assuming you want to link to it instead. |
| 21:54 | <TabAtkins> | I have code that ignores that for interfaces, and always defines (unless it's partial), but I'm generalizing it to all definition statements right now. |
| 21:54 | <tobie> | TabAtkins: nice. |
| 21:56 | <TabAtkins> | And pushed. |
| 21:56 | <TabAtkins> | So now IDL blocks will always dfn; you only get a link if it's dfn'd elsewhere locally, or it's a `partial` construct |
| 21:57 | <tobie> | Nice. |
| 21:59 | <tobie> | TabAtkins: I must say filing issues against Bikeshed and seeing them fixed at such a pace is a pretty gratifying experience. |
| 21:59 | <TabAtkins> | Eventually you'll hit one that I let sit for a while. |
| 21:59 | <TabAtkins> | Thus why I have 70 open issues in the repo. ^_^ |
| 21:59 | <TabAtkins> | But I do like to get things fixed asap when I can. |