| 07:39 | <zcorpan> | miketaylr: sup |
| 07:41 | <TabAtkins> | nox: table[border]:not([border=0]) ? |
| 07:42 | <zcorpan> | miketaylr: i stumbled over the compat spec. what's the background there? is moz implementing it? edge? |
| 07:45 | <Ms2ger> | TabAtkins, how about border=00? |
| 07:46 | <TabAtkins> | Screw you, that's how about. |
| 07:47 | <Ms2ger> | Go review my reftests :) |
| 07:47 | <tantek> | zcorpan: re: compat spec, yes. |
| 07:48 | <tantek> | feedback very much appreciated! |
| 07:48 | <zcorpan> | tantek: edge also? |
| 07:49 | <tantek> | zcorpan: I haven't spoke for MS in >10 years ;) |
| 07:52 | <karlcow> | zcorpan: the goal is to describe at least things which are not yet described and are necessary for WebCompat. Some of the things are in being implemented in Gecko, and some are already implemented in Edge. |
| 07:52 | <karlcow> | s/are in/are being/ |
| 07:52 | <zcorpan> | ok. ty |
| 07:52 | <MikeSmith> | tantek: ...but when I do [ *** ] |
| 07:55 | <MikeSmith> | every time MS tries to speak at an event, tantek should hijack the mic and demand 2 minutes of silence for MS people to express remorse for IE6 |
| 07:55 | <tantek> | MikeSmith: I don't think anyone misses IE6/Windows. Or do you mean the IE6/Mac that never shipped? |
| 07:56 | <MikeSmith> | I had in mind, for the harm that IE6 caused |
| 07:56 | <MikeSmith> | but in that cause it would need to be instead, like, 7 years of silence |
| 07:56 | <MikeSmith> | or however long it was |
| 07:57 | <tantek> | MikeSmith, if one vendor walking away from the web (for a while) can cause the web to stall, that doesn't speak well of the web's robustness. |
| 07:57 | <MikeSmith> | oh it didn't cause the web to stall |
| 07:58 | <MikeSmith> | it just caused lots of people to have to waste lots of time |
| 07:58 | <tantek> | oh I know, I was pretty busy during that time myself ;) (#microformats) |
| 07:58 | <MikeSmith> | I think we should demand that MS give us all that time back |
| 07:58 | <MikeSmith> | reparations |
| 07:59 | <tantek> | MikeSmith you mean for having to support legacy IE6 CSS, when there wasn't even a CSS 2.1 finished nor test suite to pass to verify they got it right? |
| 08:00 | <Ms2ger> | Really we should just complain about the csswg |
| 08:00 | <tantek> | MikeSmith if you're looking for reparations, look no further than the XML mafia which hijacked W3C from ~1998-2004 |
| 08:00 | <tantek> | Ms2ger: your timing is impeccable :) |
| 08:00 | <Ms2ger> | There is no bad timing for that :) |
| 08:00 | <karlcow> | IE6 Seems to me / You don't want to talk about it / Seems to me / You just turn your pretty head and walk away |
| 08:00 | <karlcow> | — https://www.youtube.com/watch?v=ICmD8P0x8_M |
| 08:01 | <tantek> | Ms2ger: during f2f meetings can be particularly effective |
| 08:01 | <Ms2ger> | uhuh |
| 08:01 | <MikeSmith> | the XML mafia shamed themselves into irrelevance, so nothing more to do there |
| 08:01 | <tantek> | MikeSmith, and how much of all our time in web standards did the XML mafia waste for all those years? |
| 08:02 | <Ms2ger> | tantek, still hoping someone there will review https://github.com/w3c/csswg-test/pull/829 |
| 08:02 | <tantek> | of course now there's the growing JSONLD mafia in their place |
| 08:02 | <MikeSmith> | tantek: dunno but be got some serious lulz out of it |
| 08:02 | <MikeSmith> | they paid us in lulz |
| 08:02 | <Ms2ger> | (Making the css21 test suite relevant, 5 years late) |
| 08:03 | <tantek> | Ms2ger: your attention to detail is admirable. |
| 08:03 | <tantek> | clearly you're in the right place |
| 08:06 | <MikeSmith> | in our history, the XML mafia were like weekend bikers who really wanted to look like outlaw bikers, but instead their bikes were all shiny (and not stolen from somebody else) and their cutoffs/vests were washed and clean and neat |
| 08:06 | <tantek> | Ms2ger: just looking at the first couple of files at-import-009 and 010 - why change the prose from "must" to "should"? Looks like spec is pretty clear about the requirements there. |
| 08:28 | <Ms2ger> | tantek, true, but ref-this-text-should-be-green.xht uses "should", and it's better to reuse that reference even if it doesn't use rfc2119 terminology |
| 08:28 | <tantek> | I worry that the inconsistency will confuse someone looking at the test |
| 08:29 | <tantek> | can we fix ref-this-text-should-be-green.xht or is that even more painful? |
| 08:30 | <Ms2ger> | We probably can, but can I defer that to a followup? |
| 08:34 | <tantek> | The change in prose in the tests from "must" to "should" seems like a regression to me. If that prose change can be postponed and instead dealt with in that same follow-up where ref-this-text-should-be-green.xht is fixed, that would be better IMO. |
| 08:37 | <Ms2ger> | I guess I could fix it now, but there's about 3000 occurrences of "should" in the css21 suite alone, and I suspect most of those would need to be "must" by that logic |
| 08:42 | <zcorpan> | Ms2ger: jgraham: erikdahlstrom wanted push access to web-platform-tests for svg stuff |
| 08:43 | Ms2ger | looks |
| 08:44 | <Ms2ger> | I think I'd rather wait to grant it until I've seen contributions |
| 08:47 | <Ms2ger> | tantek, could you at least ask fantasai where she stands on that first? |
| 08:48 | <Ms2ger> | I don't really want to start on a big should-removal if it won't be accepted |
| 08:48 | <tantek> | Ms2ger: no problem will ask. I figure you asked for review so I'd try to help :) |
| 08:49 | <tantek> | Ms2ger re: 3000 occurrences of "should" - hoping to not add any more, or worse, not replace any existing "must"s with "should"s. |
| 10:40 | <nox> | Why does specificity depends on the element being matched in selectors4 now? |
| 11:25 | <beverloo> | Is it valid for W3C specs to have normative references to non-free ANSI documents? |
| 11:26 | <Ms2ger> | Yes, though readers will be grumpy |
| 11:26 | <beverloo> | My grumpyness caused me to ask. Thanks! |
| 11:26 | <Ms2ger> | Doesn't mean you can't complain :) |
| 11:27 | <beverloo> | I will :) It's only a PR at this point |
| 11:27 | <beverloo> | but it's kind of hard to complain about something if I can't see what it is |
| 11:28 | <nox> | TabAtkins: What about border="00"? |
| 11:30 | <Ms2ger> | <Ms2ger> TabAtkins, how about border=00? |
| 11:31 | <nox> | Ms2ger: Err, sorry. :) |
| 11:31 | <Ms2ger> | Great minds think alike? :) |
| 11:31 | <nox> | Hah. Thanks. :D |
| 11:31 | <nox> | Anyway, what's that mess in CSS 4 with the selectors' specificity? |
| 11:31 | <nox> | Isn't that a huge increase in complexity that the specificity depends on the element being matched? |
| 11:49 | <annevk> | nox: how does it depend on the element? |
| 11:49 | <annevk> | nox: I don't see it in https://drafts.csswg.org/selectors/#specificity-rules |
| 11:49 | <nox> | annevk: "for a given element" |
| 11:49 | <nox> | annevk: "If the selector is a selector list, this number is calculated for each selector in the list, and the specificity of the entire selector is the largest of any individual selector in the list that matches the element." |
| 11:49 | <nox> | annevk: ":matches(em, #foo) has a specificity of (0,0,1)--like a tag selector--when matched against <em>, and a specificity of (1,0,0)--like an ID selector--when matched against <em id=foo>." |
| 11:50 | <annevk> | oh |
| 11:50 | <annevk> | I wonder if that's implemented correctly in WebKit |
| 11:56 | <nox> | annevk: https://github.com/w3c/csswg-drafts/commit/53a057fb219394c8816a470ab96e5de8c720082c#diff-11f338bfd5b68aaa92f2013402218063 https://github.com/w3c/csswg-drafts/commit/ce57f47360dcff13a99da7e68f94020b9638d557#diff-11f338bfd5b68aaa92f2013402218063 |
| 11:56 | <nox> | https://github.com/w3c/csswg-drafts/commit/bfebc135d542fde47a049798669aad6a6fe82965#diff-b8f9f5846b8094cd2099649b6fb92111 |
| 11:58 | <Ms2ger> | Calling TabAtkins |
| 11:58 | <nox> | annevk: Seems to come from https://lists.w3.org/Archives/Public/www-style/2010Sep/0534.html. |
| 11:58 | <nox> | Found this link in https://github.com/w3c/csswg-drafts/commit/353bbef8abc9e09bee3af6a170cb25426cde230e |
| 12:00 | <annevk> | wow all CSS drafts are in a single repo? |
| 12:01 | <annevk> | I guess they liked their CVS setup |
| 12:14 | <TabAtkins> | What's up? |
| 12:15 | <TabAtkins> | annevk: We still sync our git and mercurial, for the handful of people that for some reason like mercurial |
| 12:15 | <SimonSapin> | annevk: inertia rather than like, I think |
| 12:15 | <SimonSapin> | TabAtkins: we could have multiple hg repos too |
| 12:15 | <TabAtkins> | We could, sure. But we didn't. |
| 12:16 | jgraham | is surprised that no one has yet suggested putting all specs in a single repository |
| 12:16 | <jgraham> | (I am not endorsing that idea) |
| 12:18 | <Ms2ger> | GREGORY SZORC enters |
| 12:23 | <nox> | TabAtkins: Up is a direction. |
| 12:23 | <nox> | TabAtkins: But otherwise, is specificity depending on the element being matched here to stay? |
| 12:23 | <TabAtkins> | nox: Yes. :matches() is just syntax sugar for writing multiple selectors. |
| 12:23 | <nox> | TabAtkins: That's orthogonal isn't it? |
| 12:24 | <TabAtkins> | `:matches(a,b) > :matches(c,d)` is equivalent to `a > c, a > d, b > c, b > d`. |
| 12:24 | <nox> | TabAtkins: Their specificity could be the same even without depending on the element. Not sure how that's related to my question. |
| 12:24 | <TabAtkins> | It's not orthogonal, because often this'll be used when refactoring - you first write simple selectors, then as you need to expand a term you add :matches(), and you don't want to break specificity. |
| 12:25 | <nox> | My question isn't specific to :matches(). |
| 12:25 | <TabAtkins> | ...okay? Nothering else acts like :matches. |
| 12:25 | <nox> | "If the selector is a selector list, this number is calculated for each selector in the list, and the specificity of the entire selector is the largest of any individual selector in the list that matches the element." <- That doesn't involve :matches(), does it? |
| 12:26 | <TabAtkins> | That's just a way to talk about selector lists. It's the behavior we've had since CSS1 |
| 12:26 | <nox> | "foo, #bar"'s specificity varies depending on the element, doesn't it? |
| 12:26 | <nox> | CSS1's selectors' specificity also depended on the element being matched? :o |
| 12:26 | <TabAtkins> | You're overthinking this. |
| 12:26 | <nox> | How so? |
| 12:27 | <TabAtkins> | If you have ".foo, #bar { color: red; }", then for <div class="foo"> the 'color' is applied with specificity [0,1,0], but for <div id=bar> it's applied with specificity [1,0,0]. It's always been that way, forever. |
| 12:27 | <nox> | SimonSapin: ^ |
| 12:27 | <nox> | SimonSapin: rust-selectors was always wrong then, no? |
| 12:27 | <TabAtkins> | Appending a new (non-matching) selector to an existing style rule doesn't suddenly change the specificity of anything on the page. |
| 12:28 | <TabAtkins> | Again, this is because that example is equivalent to the decomposed ".foo { color: red; } #bar { color: red; }". |
| 12:28 | <zcorpan> | TabAtkins: i get an error in cssom that CSSFontFaceRule has no ref. is css fonts spec doing something wrong or am i? |
| 12:28 | <nox> | TabAtkins: That's how browsers did it, but not how the CSS1 was specifying it, right? |
| 12:28 | <TabAtkins> | zcorpan: CSS Fonts is wrong, until I get it finished converting to Bikeshed. |
| 12:29 | <zcorpan> | TabAtkins: k, i'll Ignored Terms it for now |
| 12:29 | <TabAtkins> | nox: CSS traditionally talked about only one selector at a time. |
| 12:29 | <TabAtkins> | zcorpan: Yeah, that's the right thing to do. |
| 12:29 | <nox> | TabAtkins: Oh ok, I see. |
| 12:30 | <TabAtkins> | So it just pretended that, in the ".foo, #bar" case, that you were only worrying about .foo or #bar, not both at the same time. |
| 12:30 | <SimonSapin> | nox: In Selectors 3, "lists of (comma-separated) selectors" don’t have a specificity, only single "selectors" do. |
| 12:30 | <TabAtkins> | That seemed unclear, so I rewrote. |
| 12:30 | <nox> | SimonSapin: Yeah; understood now. |
| 12:31 | <TabAtkins> | Basically it seemed dumb to push the handling of specificity of selector lists to the cascade spec, when it could be defined in selectors. |
| 13:00 | <Ms2ger> | gsnedders retweeting Dutch tweets? What's the world coming to... |
| 14:34 | <gsnedders> | Ms2ger: bah, sometimes I can get what they say from my knowledge of German :P |
| 14:35 | <gsnedders> | Ms2ger: I mean I do retweet stuff relatively frequently in English, German, French, Swedish, Norwegian, and Danish. |
| 14:35 | <gsnedders> | I'm not entirely sure why, I doubt most of my followers cope :P |
| 14:54 | <frewsxcv> | what does /* sealed */ mean in this webidl? https://html.spec.whatwg.org/multipage/browsers.html#window |
| 14:59 | <liefer> | So i'm reading https://fetch.spec.whatwg.org/ which makes it seem like it should indeed be possible to perform a fetch which does a HTTPPOST request that includes a body. How do i go about figuring out the syntax for actually doing so? Google only seems to give me examples of how to do simple HTTPGET's like e.g. https://bpaste.net/show/f754e9ca53bd |
| 15:00 | <Ms2ger> | frewsxcv, nothing at this point |
| 15:00 | <frewsxcv> | Ms2ger: excellent |
| 15:02 | <annevk> | liefer: fetch(url, {body:..., method:"POST"}) |
| 15:02 | <TabAtkins> | frewsxcv: I think the idea is that you're not supposed to `partial` it. |
| 15:02 | <frewsxcv> | even though it is partial'ed? |
| 15:02 | <zcorpan> | liefer: https://fetch.spec.whatwg.org/#requestinit |
| 15:04 | <liefer> | zcorpan, ah embarrasing, should just have read further :) thank you |
| 15:04 | <liefer> | annevk, thank you! |
| 15:04 | <Ms2ger> | TabAtkins, no, that's not it |
| 15:05 | <gsnedders> | zcorpan: wrt the reftests data, "dump the data there" — why? we already have it in git? for upstreaming stuff I was just assuming a checklist of each directory |
| 15:05 | <annevk> | Ms2ger: do you know why there's no bug open against IDL to define what it means? |
| 15:05 | <Ms2ger> | annevk, I don't recall what was going on there |
| 15:06 | <gsnedders> | totally random: was there not some talk about making invisible file pickers unclickable? |
| 15:06 | <annevk> | Ms2ger: there's a couple of interfaces marked as such... |
| 15:06 | <annevk> | including partial interfaces so that's definitely not it |
| 15:06 | <Ms2ger> | gsnedders, that (not random bit) sounds like something I'm interested in, but am lacking context |
| 15:07 | <annevk> | gsnedders: a long long time ago, but folks gave up on that |
| 15:07 | <gsnedders> | annevk: last I knew it was still occasionally getting talked about :P |
| 15:09 | <Ms2ger> | Can't find anything on sealed in my email either |
| 15:10 | <gsnedders> | Ms2ger: tl;dr: zcorpan was asking what he can do to help with the refs in presto-testo |
| 15:10 | <Ms2ger> | Ah, great |
| 15:12 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26490 |
| 15:13 | <annevk> | seems related to sealed |
| 15:14 | <zcorpan> | gsnedders: is the partial .csv already public somewhere? |
| 15:15 | <gsnedders> | zcorpan: https://github.com/operasoftware/presto-testo/blob/master/reftest.list is it converted to a more normal format |
| 15:16 | <gsnedders> | zcorpan: and without absolute URLs |
| 15:16 | <zcorpan> | gsnedders: ok. thanks. then there's not much for me to do at this point |
| 15:18 | <zcorpan> | Ms2ger: it appears we don't have the full list of associations anymore |
| 15:18 | <Ms2ger> | Aw |
| 15:19 | <gsnedders> | also we appear to not have all the refs released |
| 15:19 | <gsnedders> | but that I'm dealing with |
| 15:19 | <Ms2ger> | Oh, there's some css21 refs in there |
| 15:19 | Ms2ger | missed those before |
| 15:20 | <Ms2ger> | 160 is better than none, certainly |
| 15:20 | <gsnedders> | yeah, but I think they are all the ones part of the testsuite from upstream |
| 15:20 | <Ms2ger> | Ha |
| 15:21 | gsnedders | is currently waiting for other people running `find` to have it come to its end |
| 15:22 | Ms2ger | will grumble at MS some more |
| 15:27 | <annevk> | https://heycam.github.io/webidl/#indexed-and-named-properties seems related to the sealing too |
| 15:37 | <gsnedders> | Ms2ger: also half the problem is I'm not quite sure what I did five years ago |
| 15:40 | <gsnedders> | Ms2ger: it's looking like I only converted those four into files with all the CSS WG metadata, and the rest are all HTML files |
| 15:41 | <gsnedders> | bah, I should've done this all a couple of years ago :P |
| 15:42 | <gsnedders> | do it myself without proxies |
| 15:45 | <Ms2ger> | Yeah, well, it's not like the csswg would've accepted them then |
| 15:46 | <gsnedders> | Could've pushed them all out publicly, though. |
| 15:46 | <gsnedders> | CSS WG be damned |
| 15:46 | <Ms2ger> | True |
| 15:46 | <gsnedders> | oh well, we can recreate the mapping for the CSS 2.1 testsuite |
| 15:47 | <gsnedders> | run all the tests, save screenshots, run all the refs, save screenshots, and match |
| 15:47 | <gsnedders> | probably across multiple browsers to make sure we get everything given some browsers fail some stuff |
| 15:59 | <Ms2ger> | [giow] (3) Make sure <iframe name=location> doesn't override Document.location |
| 15:59 | <Ms2ger> | Fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=19560 |
| 15:59 | <Ms2ger> | annevk, blame for sealed points there ^ |
| 16:06 | <ccardona_work> | Good morning/afternoon/evening WHATWG crew o/ |
| 16:24 | <annevk> | Ms2ger: according to Hixie it's to prevent subclassing |
| 17:15 | <Ms2ger> | annevk, I see |