| 00:37 | <hayato> | Ms2ger: Sorry for breaking travis. I fixed. https://github.com/w3c/web-platform-tests/commit/12b780086f4a0d1d6ff5e6d588482ae04624e794 |
| 05:50 | annevk | signed up for a week of TPAC |
| 08:54 | <zcorpan> | hmm https://twitter.com/zcorpan/status/744896721017257984 only 12 votes. maybe people don't understand the question? |
| 08:57 | <annevk> | zcorpan: too hard |
| 10:51 | <annevk> | JakeA: if we're going to do navigation transitions it'd be great if someone helped out refactoring the navigation algorithm to make it actually match browsers |
| 11:27 | <zcorpan> | MikeSmith: getting 502 for https://checker.html5.org/ |
| 11:44 | <MikeSmith> | zcorpan: yeah was restarting it, should work now |
| 11:44 | <zcorpan> | ah ok, yep works now |
| 11:53 | <annevk> | hsivonen: thanks for the review, please only merge if there's a generated index with an-up-to-date date next time; or just leave that part to me |
| 11:56 | <annevk> | hsivonen: it didn't matter much since I fixed it with the second PR, so just a note for next time |
| 12:12 | <hallvors> | zcorpan: it is tricky indeed :) |
| 12:12 | <hallvors> | I've guessed something, but don't know |
| 12:15 | <hallvors> | annevk: quick XHR question.. #handle-response-end-of-file step 10 seems to guarantee that you'll always get a progress event when readyState is 4. I don't really see implementations doing that..? |
| 12:16 | <annevk> | hallvors: yeah, zewt and I determined that would be good, but I guess implementations never really got there |
| 12:16 | <annevk> | hallvors: maybe it's time to give up on that especially since XHR isn't really the API-to-be anyway |
| 12:16 | <annevk> | hallvors: file an issue? |
| 12:16 | <hallvors> | OK. |
| 12:17 | <hallvors> | Seems fine to me to drop that requirement, you get load and loadend and readystatechange .. |
| 12:17 | <annevk> | Yeah, the idea was that you could just listen to progress and be fine |
| 12:17 | <hallvors> | I don't think we really need more events here :) |
| 12:17 | <annevk> | So that you'd never get a progress bar that hangs at 80% or so |
| 12:18 | <annevk> | But at this point everyone probably learned not to do that... |
| 12:44 | <hallvors> | annevk: https://github.com/whatwg/xhr/issues/72 |
| 12:48 | <annevk> | ta |
| 13:06 | <howdoi> | So, anyone can write a proposal on a gist/github/anyLink and it will be counted as stage-0 ? |
| 13:07 | <annevk> | howdoi: you need a TC39 member to champion it |
| 13:07 | <howdoi> | annevk: and on what factors will the championing depend on? (I know there might be many, but the cruz would be?) |
| 13:08 | <annevk> | howdoi: that someone thinks it's good? |
| 13:08 | <howdoi> | and how does on make it to TC39 community as a member, I do noticed that there are many who havn't made a proposal or their proposals are still not in stage-4 |
| 13:09 | <annevk> | howdoi: I'm not sure I follow that question |
| 13:09 | <howdoi> | annevk: makes sense :) (Can consider as voting or majority of them supports in via the mailing list or something else) |
| 13:09 | <annevk> | howdoi: note that I'm not really doing TC39 stuff |
| 13:09 | <howdoi> | in simple terms : Who are eligible to become a TC39 member? |
| 13:10 | <annevk> | howdoi: I think anyone who pays USD 10k a year |
| 13:10 | <annevk> | howdoi: not sure if the fee remained the same, might be more now? |
| 13:10 | <howdoi> | just 10k :D heh heh ok! |
| 13:13 | <annevk> | Domenic: playsinline change LGTM, though not entirely sure about ordering, but I'm guessing you thought about that |
| 13:13 | <howdoi> | annevk: last (silly) question, say Mr.X is working at a company Y which is a TC39 member, this person can also get into the community via the company? |
| 13:13 | <hallvors> | annevk: an improved test for POST and redirects here https://github.com/w3c/web-platform-tests/compare/hallvors/upload-redirect - should be ready for a PR now |
| 13:14 | <annevk> | howdoi: sure, everyone that participates is in the community |
| 13:14 | <howdoi> | annevk: killer! nice :) |
| 13:15 | <annevk> | hallvors: cool, so if you want to do more work, you could generalize the method bit |
| 13:15 | <annevk> | hallvors: e.g., PUT needs to be preserved for all redirect types |
| 13:15 | <howdoi> | annevk: luckily the company at which I work in an ordinary member, let me see what best I can get from them ;) |
| 13:16 | <annevk> | hallvors: POST -> GET happens for 301/302; oh and 303 always goes to GET |
| 13:16 | <annevk> | hallvors: 307 and 308 always preserve |
| 13:16 | <hallvors> | heh, that should all be tested for sure |
| 13:16 | <annevk> | hallvors: Fetch spells this out |
| 13:16 | <annevk> | hallvors: yeah, not sure to what length you want to go with this one |
| 13:17 | <hallvors> | Not sure if I should extend that test or write a couple of other ones.. might get too complex to be readable at some point. |
| 13:17 | <annevk> | hallvors: does this pass in any browser? |
| 13:17 | <hallvors> | yes |
| 13:18 | <hallvors> | once I gave up expecting a progress event in readystate 4 it passes nicely in Firefox and Chrome (on a Mac), fails in Safari which appears to not do 307 correctly |
| 13:18 | <annevk> | hallvors: cool, LGTM then |
| 13:18 | <annevk> | hallvors: could maybe ping cdumez in the eventual PR/merge for the Safari thing |
| 13:19 | <annevk> | hallvors: sure they'd like to fix |
| 13:19 | <hallvors> | I'll report a bug on testing those other methods..because I should be doing webcompat bug analysis right now.. |
| 13:20 | <annevk> | yeah, back to staring at cross-origin function wrappers |
| 13:21 | <annevk> | they are exactly as exciting as they sound |
| 13:21 | <hallvors> | just say that in a deep, sexy voice and see how exciting you can make them :-p |
| 13:32 | <hallvors> | annevk: Travis has found some console use in a file I haven't touched.. https://github.com/w3c/web-platform-tests/pull/3210 |
| 13:32 | <hallvors> | wot? |
| 13:33 | <Domenic> | annevk: ordering? |
| 13:33 | <annevk> | Domenic: relative to other attributes |
| 13:33 | <annevk> | hallvors: dunno |
| 13:33 | <Domenic> | annevk: ah yeah I just kind of was like... seems kind of like autoplay, let's put it there. But in IDL it should probably be last since that in theory has webcompat impacts |
| 13:41 | <Ms2ger> | hallvors, should be fixed on master |
| 13:41 | <hallvors> | Ms2ger: this afternoon? I thought I had pulled recently. |
| 13:42 | <hallvors> | hm.. maybe I pulled on another laptop |
| 13:42 | <hallvors> | #-] |
| 13:42 | <Ms2ger> | hallvors, https://github.com/w3c/web-platform-tests/commit/12b780086f4a0d1d6ff5e6d588482ae04624e794 |
| 13:44 | <hallvors> | Ms2ger: thanks, will rebase.. |
| 15:01 | <annevk> | Domenic: I don't really need the [[Wrapped]] stuff anymore? |
| 15:01 | <Domenic> | annevk: yeah I think CrossOriginFunctionWrapper can go away |
| 15:01 | <annevk> | Domenic: it's never become entirely clear to me how ECMAScript does anonymous functions, but what you suggested works for me |
| 15:12 | <annevk> | Domenic: thanks, still not entirely pleased with the IDL mismatch, but it's a lot better than a security hole |
| 15:16 | <annevk> | Domenic: playsinline fixup LGTM |
| 15:16 | <Domenic> | \o/ |
| 15:16 | <annevk> | Domenic: yay for avoiding the negations |
| 15:29 | <hsivonen> | annevk: ok. sorry. I won't merge going forward. I thought it was part of having it assigned to me. |
| 15:29 | <annevk> | hsivonen: yeah I should have clarified |
| 15:29 | <annevk> | hsivonen: all is good now |
| 15:30 | <annevk> | hsivonen: I assume you saw all the new tests? |
| 15:52 | <hsivonen> | annevk: I didn't see new tests yet. |
| 16:28 | <annevk> | hsivonen: see new open issues from Richard |
| 16:35 | <annevk> | Domenic: I have some internal emails here suggesting Worklets need a ton of work |
| 16:35 | <annevk> | Domenic: planning on shifting through tomorrow |
| 16:36 | <Domenic> | annevk: sounds interesting... not sure it's something i want to tackle, but I guess I can help. |
| 16:36 | <annevk> | Domenic: was wondering if you had taken a peek yet |
| 16:36 | <Domenic> | annevk: not really looked, no |
| 16:36 | <annevk> | Domenic: okay, if I end up filing a bunch of things tomorrow I'll let you know |
| 17:10 | <annevk> | Navigation 😭 |
| 19:39 | <mathiasbynens> | Domenic: old discussion about those, ehm, “best practices”: https://github.com/mathiasbynens/mothereff.in/issues/29 |
| 19:40 | <Domenic> | mathiasbynens: I can't find the rationale there? Some people in that thread thinks it looks bad? The spec explicitly has examples that end in non-alphanumerics |
| 19:46 | <mathiasbynens> | seems like it was about aesthetics |
| 19:46 | <mathiasbynens> | = subjective, ofc |
| 19:48 | <mathiasbynens> | it’s not a bad idea to be strict and warn on things that might cause confusion in tools like these, imho |
| 19:48 | <mathiasbynens> | people who want to use non-alpha can and will do so |
| 19:49 | <caitp> | if you can't have custom elements named <\u1f922>, what is the point |
| 20:14 | <mathiasbynens> | caitp: <foo-�> (U+FFFD) is valid though, which results in U+1F922 anyway |
| 20:19 | <caitp> | yeah, but but you can't have <�-foo> |
| 20:19 | <caitp> | which is just terrible! |
| 20:19 | <caitp> | emojis are people too |
| 20:22 | <TabAtkins> | #NotAllEmojis |
| 20:47 | <zcorpan> | https://twitter.com/jcdsvg/status/745337593210904577 is interesting. we (browsers) should be communicating better that removing the doctype is bad. or something, i dunno |
| 20:50 | <gsnedders> | zcorpan: *is* it all bad if browsers interoperate? |
| 20:50 | <zcorpan> | they don't |
| 20:51 | <gsnedders> | they don't currently, but if browsers converge, does quirks mode continue to be bad? |
| 20:51 | <gsnedders> | because we are seeing convergence, slowly |
| 20:52 | <zcorpan> | some of the quirks are pretty confusing |
| 20:52 | <zcorpan> | like https://quirks.spec.whatwg.org/#the-tables-inherit-color-from-body-quirk |
| 20:53 | <gsnedders> | is it still inheritence when it goes from child to parent? ;P |
| 20:53 | <zcorpan> | it's not child to parent? |
| 20:55 | <zcorpan> | i guess it could be a sibling or a descendant of a sibling to body though |
| 20:55 | <gsnedders> | zcorpan: oh, wait |
| 20:55 | <gsnedders> | zcorpan: I thought that meant tbody |
| 21:00 | <zcorpan> | also the syntax quirks only working for some properties and not others is confusing. color: 5a5a5a working but color: 5e5e5e not working is confusing. them working in @supports but not CSS.supports() is confusing. IDs and class names being case-insensitive can introduce bugs. |
| 21:00 | <zcorpan> | etc |
| 21:03 | <gsnedders> | (I'm just playing devil's advocate here, given interop does get rid a lot of the tradition arguments) |
| 21:03 | <zcorpan> | sure |
| 21:04 | <zcorpan> | a bit like the value of validation when html parsers interoperate |
| 21:05 | <MikeSmith> | zcorpan: https://github.com/validator/validator/issues/310 |
| 21:06 | <MikeSmith> | zcorpan: there are many sites using <!--> with IE conditional comments |
| 21:06 | <MikeSmith> | due to guidance like https://en.wikipedia.org/wiki/Conditional_comment#Downlevel-revealed_conditional_comment |
| 21:07 | <MikeSmith> | and in https://www.sitepoint.com/web-foundations/internet-explorer-conditional-comments/ |
| 21:07 | <zcorpan> | MikeSmith: thx. need to think a bit how to fix that |
| 21:08 | <MikeSmith> | yeah, in checking things like Alexa top 100 sites, many or most of them are using that |
| 21:08 | <gsnedders> | MikeSmith: pretty sure everything I work on still uses conditional comments, FWIW |
| 21:09 | <MikeSmith> | well not all IE conditional comments use that |
| 21:09 | <gsnedders> | plenty of things still care about older versions of IE, for which they're the sanest way to target them |
| 21:09 | <MikeSmith> | I am not sure why some sites use that while others do not |
| 21:10 | <MikeSmith> | I would think we might be able to allow <!--> at end of a comment while still disallowing things like <!-- foo <!-- bar --> |
| 21:11 | <MikeSmith> | (that is, where the nested <!-- is clearly in the midst of some comment and not at the end) |
| 21:20 | <zcorpan> | in related news, 36,813 pages of 496,558 pages in httparchive are in quirks mode |
| 21:21 | <zcorpan> | 7.4% |
| 21:22 | <zcorpan> | MikeSmith: also allow <!-- <!---> ? |
| 21:23 | <MikeSmith> | zcorpan: probably could just as easily allow that too |
| 21:23 | <MikeSmith> | though I am not sure anybody actually does that |
| 21:23 | <MikeSmith> | the docs all specifically say just <!--> at the end |
| 21:24 | <zcorpan> | yeah |
| 21:26 | <zcorpan> | the syntax currently disallows comment data ending with <! or <!-, so if we allow <!-- <!--> but not the other we'd still need to disallow comment data ending with <!-. |
| 21:28 | <zcorpan> | maybe only change <!--> and not any more dashes |
| 21:43 | <zcorpan> | filed an issue |
| 21:58 | <zcorpan> | 63,518 resources in httparchive have conditional comments with <!--> |
| 22:01 | <zcorpan> | 1 has conditional comment with <!--->. 28 have <!---> *somewhere* |