| 00:43 | <MikeSmith> | wanderview_pto: http://stackoverflow.com/questions/35558711/gecko-firefox-44-0-2-blocks-google-fonts and wondering if the speculation in the comment there is accurate |
| 01:23 | <TabAtkins> | One of my coworkers pinged me to get approval for his WHATWG wiki account, (because I'm a permanent autoconfirmed member, on the list as someone to contact) but I have no idea what I'm supposed to do, and there's nothing obvious in the UI to help me. |
| 02:10 | <Philip`> | Are there any SVG fans who happen to know how to work out why https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/images/tstripadj.svg looks correct in Chrome but completely blank in Firefox? |
| 02:39 | <roc> | if you look at the first <ellipse> element, its center x is at about -44, then it's translated by 115, giving you 71, which is outside the viewBox which is from -108 to -13 horizontally |
| 02:39 | <roc> | if you delete the viewBox attribute the contents become visible (but very small) |
| 02:40 | <MikeSmith> | it’s very small in Chrome as well |
| 02:41 | <roc> | Chrome console says "Error: <svg> attribute viewBox: A negative value is not valid. ("-108.050 3.950 -13.183 76.817")" |
| 02:41 | <MikeSmith> | and given those details (it’s outside the viewbox), it seems like it rightly shouldn’t be visible at all in Chrome either |
| 02:41 | <roc> | so Chrome is ignoring the viewBox |
| 02:41 | <MikeSmith> | ah |
| 02:42 | <MikeSmith> | wonder if that’s per-spec |
| 02:42 | <MikeSmith> | I guess not |
| 02:42 | <roc> | spec says "Negative values for width or height are not permitted" |
| 02:42 | <roc> | Gecko SVGSVGElement::GetViewBoxTransform says |
| 02:43 | <roc> | if (viewBox.width <= 0.0f || viewBox.height <= 0.0f) { |
| 02:43 | <roc> | return gfx::Matrix(0.0, 0.0, 0.0, 0.0, 0.0, 0.0); // singular |
| 02:43 | <roc> | so we draw nothing |
| 02:43 | <MikeSmith> | that seems like the right behavior |
| 02:44 | <MikeSmith> | I guess the spec doesn’t unambiguously state what UAs must do when they encounter negative values |
| 02:44 | <roc> | yeah |
| 02:45 | <roc> | well |
| 02:45 | <roc> | according to https://www.w3.org/TR/SVG/implnote.html#ErrorProcessing |
| 02:45 | <roc> | "The document shall be rendered up to, but not including, the first element which has an error. " |
| 02:45 | <roc> | technically I think this means render nothing in this case |
| 02:46 | <heycam> | that's old spec behaviour that nobody does, though |
| 02:46 | <roc> | right |
| 02:46 | <heycam> | I think we should treat the attribute as an error, and then effectively ignore the attribute |
| 02:46 | <roc> | chrome draws nothing for 0, 0 |
| 02:47 | <roc> | heycam: will you write the patch or shall I? :-) |
| 02:47 | <heycam> | roc: I am a bit busy but happy to review it :) |
| 02:50 | <heycam> | filed https://github.com/heycam/webidl/issues/92 to make it clearer that error processing for attributes should take its default value |
| 02:51 | <heycam> | now that is the wrong spec isn't it |
| 02:52 | <heycam> | https://github.com/w3c/svgwg/issues/52 |
| 03:02 | <MikeSmith> | in other news, Microsoft seems to have quietly moved their status for WebRTC 1.0 support in Edge from “not planned” to “under consideration” |
| 03:02 | <MikeSmith> | https://github.com/MicrosoftEdge/Status/commit/944ac47dbe9ea54b9478fdfa6b700fdd2355236b |
| 03:31 | <MikeSmith> | roc: rr is seeming more and more truly awesome |
| 03:31 | <MikeSmith> | re: http://robert.ocallahan.org/2016/02/these-bugs-are-impossible-to-fix.html |
| 03:32 | <roc> | yes, I'm happy about it |
| 03:35 | <MikeSmith> | roc: did they use chaos mode to reproduce that JS bug? or just the default rr behavior? |
| 03:36 | <roc> | they didn't use chaos mode |
| 03:38 | <roc> | relatedly, I just got this blog comment: |
| 03:38 | <roc> | Me: What is rr? I haven’t heard of it before. (Note: I came to this blog from a link to Rewrite Everything In Rust just a few minutes ago) |
| 03:38 | <roc> | *googles* |
| 03:38 | <roc> | Me: That EXISTS? Why have I not heard about this before? Why have I not been using this for years? This changes everything. |
| 03:41 | <MikeSmith> | heh |
| 03:41 | <MikeSmith> | I expect you’re going to see a lot more comments like that |
| 03:42 | <MikeSmith> | maybe you should hire a publicist to get the word out more 😆 |
| 04:43 | <annevk> | TabAtkins: homepage of wiki has account creation link |
| 08:06 | <MikeSmith> | the ongoing keygen comedy continues to provide strong entertainment value https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/thread.html#msg76 |
| 08:35 | <annevk> | It's annoying that the refrain always is "please integrate with my legacy solution" |
| 08:35 | <annevk> | Nothing really groundbreaking or considerate of modern UX requirements |
| 09:05 | <Philip`> | roc: Thanks! |
| 09:06 | <roc> | Philip`: I've submitted a fix for Gecko, but note that the content is definitely invalid. I'm not sure what they're trying to do with that negative width... |
| 09:10 | <Philip`> | roc: Something weird in Inkscape, I guess |
| 09:11 | <cvrebert> | Is there a reason HTML uses the not-specifically-defined phrase "cancel the event" rather than "set the event's [[canceled flag]]" ? |
| 09:12 | <annevk> | cvrebert: no good reason, but note that events are also rather badly defined in that respect |
| 09:12 | <annevk> | cvrebert: e.g., referring directly to the type attribute rather than an internal slot, and such |
| 09:13 | <annevk> | cvrebert: I'm waiting for https://www.w3.org/Bugs/Public/show_bug.cgi?id=27354 to be fixed before revamping all that |
| 09:14 | <cvrebert> | annevk: I was using [[]] to indicate hyperlinking as opposed to ES slot weirdness |
| 09:16 | <annevk> | cvrebert: sure, but we need the weirdness before any of this will get solved properly |
| 09:23 | <cvrebert> | annevk: Okay. |
| 09:25 | <annevk> | It might be weird, but ECMAScript is completely correct that an object consists of internal data and a set of properties that operate on that internal data |
| 09:26 | <annevk> | That we haven't formalized that in "DOM" is rather strange |
| 09:27 | <cvrebert> | annevk: Right |
| 09:29 | <cvrebert> | annevk: Why does DOM recommend (https://dom.spec.whatwg.org/#firing-events ) the phrasing "with its cancelable attribute initialized to true" but HTML uses "that is cancelable" ? |
| 09:30 | <annevk> | cvrebert: Hixie may have written the text in HTML before that phrasing was suggested or may have simply not cared |
| 09:31 | <annevk> | cvrebert: I suspect that setup to change too as a result of getting more formalism from IDL, not sure about an ETA on that though |
| 09:31 | <annevk> | Nobody is in a hurry to improve IDL |
| 09:31 | <annevk> | (unfortunately) |
| 09:32 | <cvrebert> | :-\ |
| 09:32 | <annevk> | (except maybe nox, but nox also needs to fix all the Servo bugs) |
| 09:33 | <cvrebert> | godspeed, nox |
| 11:00 | <nox> | annevk: Ah ah. |
| 11:00 | <nox> | annevk: You people work on higher level specs, better if I do something else right? ;) |
| 11:01 | <annevk> | nox: Not sure if sarcastic, since there's a ton of stuff blocking on IDL |
| 11:02 | <nox> | Sarcastic, I only do stuff that helps Servo. |
| 11:03 | <nox> | Oh that reminds me, LegacyUnenumerableNamedProperties landed in Servo. |
| 11:09 | <jgraham> | Most things that help the web help servo |
| 12:22 | <annevk> | smaug____: https://github.com/whatwg/dom/issues/148 |
| 12:29 | <annevk> | ritsyy: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28039 might be of interest to you |
| 12:32 | <ritsyy> | annevk: seeing it |
| 12:35 | <ritsyy> | annevk: yeah, okay it would be better to change it to root, will do this |
| 12:35 | <annevk> | cool! |
| 13:30 | <ritsyy> | annevk: am i getting it correctly https://paste.kde.org/prrkimwq3 ? |
| 13:33 | <annevk> | ritsyy: the change has to be done to where root element is used, but reading it over maybe that is harder than I thought |
| 13:35 | <annevk> | ritsyy: I added a comment to https://www.w3.org/Bugs/Public/show_bug.cgi?id=28039 hopefully explaining the situation a bit clearer |
| 13:47 | <zcorpan> | annevk: is it not better to just say "We are committed to providing a friendly, safe and welcoming environment for all. Please read and respect [...]" ? if we want to add something to the list, seems somewhat annoying to add it to all READMEs, too |
| 13:49 | <zcorpan> | annevk: i'm not sure the "vague critisism" thing belongs in the CoC. (sorry i didn't comment on it earlier, i thought it was removed but i guess i glossed over it) |
| 13:55 | <annevk> | zcorpan: seems fine |
| 13:56 | <annevk> | zcorpan: I don't know, the kind of "you're doing it all wrong" feedback is rather unhelpful |
| 13:57 | <annevk> | zcorpan: will update the PR with that shorter text in a bit |
| 13:57 | <zcorpan> | annevk: sure, but it's not clear to me it covers just that. for instance bz sometimes have vague critisism about wrongness without having any idea about what the right fix is, and that is still super-useful and we wouldn't want to discourage it |
| 13:58 | <zcorpan> | so i suggest dropping that bullet point |
| 13:58 | <annevk> | That's fair, remove it then I guess |
| 13:59 | <zcorpan> | people who come along and say "you're all wrong!!" typically don't stay around for long anyway :-) |
| 13:59 | <zcorpan> | ok i can remove it myself |
| 14:00 | <annevk> | PR updated |
| 14:01 | <zcorpan> | wiki too |
| 14:05 | <zcorpan> | nice work :-) |
| 14:06 | <annevk> | yeah, glad it's all up now |
| 14:12 | <annevk> | Perhaps in README.md it should say "The WHATWG community is" rather than "We are" |
| 14:13 | <annevk> | Hmm, dunno |
| 14:17 | <zcorpan> | let's stop fiddling with it now :-P |
| 14:24 | <annevk> | Yeah 😃 |
| 21:04 | <smaug____> | does github send bugmail for each comment in a review? |
| 21:06 | smaug____ | tweaks the settings, hopefully github is less spammy now |
| 21:48 | <TabAtkins> | annevk: Thanks for the heads-up about account creation. I was looking in all the surrounding stuff, not in the text of the page, as I didn't expect to find anything useful there. ^_^ |
| 22:48 | <boogyman> | Is there a white-list of CSS properties that can/will be applied for pseudo-elements? Can someone help me understand why my "text-decoration" rule isn't being honored in chrome canary/stable nor firefox nightly/stable on W8.1 / Macbook Pro (yosemite). http://jsbin.com/zubacoheyu/edit?html,css,output |
| 22:49 | <boogyman> | s/can/will/ |
| 23:32 | <astearns> | boogyman: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector |
| 23:34 | <TabAtkins> | boogyman: Every property applies to ::before/after - they're exactly identical to real elements. For other pseudos, https://drafts.csswg.org/css-pseudo/ should define the list. But your problem is :visited, as astearns pointed to. |
| 23:39 | <boogyman> | I don't understand the visitor selector. can you give more context? I've read that article. I added another line with the pseudo rule defined first / second... http://jsbin.com/vereyonubo/1/edit?html,css,output |
| 23:41 | <boogyman> | The example I gave has anchors, list items, paragraphs, and generic div's. |
| 23:58 | <TabAtkins> | Oh, now I see your issue. text-decoration has a.. unique... method of inheritance. Basically, text decorations are inherited separately from the text-decoration property, and are only affected by descendant's settings if they override one of the decorations. |
| 23:59 | <TabAtkins> | "text-decoration: none" doesn't override anything, it just doesn't establish any new decorations, so it has no effect on descendants once you've set up a decoration on an ancestor. |
