| 06:05 | <annevk> | Anyone know a simple way to draw tree structures with SVG? |
| 06:15 | <MikeSmith> | annevk: google says http://fperucic.github.io/treant-js/ |
| 06:17 | <MikeSmith> | or http://jimblackler.net/treefun/index.html |
| 06:20 | <annevk> | I like that one from Jim, I wonder if the copyleft license poses an issue though |
| 06:21 | <MikeSmith> | well if you are just using it to create diagrams the license doesn’t matter, right? |
| 06:21 | <MikeSmith> | or you are wanting to embed something? |
| 06:21 | <annevk> | Yeah maybe that's right |
| 06:22 | <annevk> | No need for embedding, though I suppose there is a need for that project staying alive so we can create more diagrams as needed... |
| 06:24 | <MikeSmith> | sure |
| 06:26 | <annevk> | What I want is to create similar graphics to those in Shadow DOM but with SVG I can edit and make accessible |
| 06:26 | <annevk> | And perhaps some extra graphics too to explain event dispatch and how shadow trees mess with that, etc. |
| 06:28 | <MikeSmith> | I wonder if TabAtkins has diagrams in CSS specs he used something to create |
| 06:28 | <MikeSmith> | I mean other than his railroad diagrams |
| 06:29 | <MikeSmith> | in general he seems to have a knack for diagrams |
| 06:29 | <MikeSmith> | anyway, that interactive treefun tool seems pretty serviceable |
| 08:29 | <Ms2ger> | annevk, r? https://github.com/w3c/web-platform-tests/pull/2875 |
| 08:33 | <annevk> | Ms2ger: merged |
| 10:14 | <Neu> | hello, why does noscript element contain markup as raw text node when scripting is enabled? What's the purpose of this? |
| 10:15 | <Neu> | Why can't it just parse contents, create DOM nodes, but browser would hide this subtree |
| 10:16 | <annevk> | Neu: I suspect it's a browser-introduced hack from back in the day to prevent <img> and such to load |
| 10:16 | <Neu> | hmm. yea, this makes sense |
| 10:23 | <Neu> | I'm reading https://www.w3.org/TR/2012/WD-html5-20121025/the-noscript-element.html : "The noscript element must contain only link, style, and meta elements." Does this mean I must drop all other tags? E.g. firefox for this case (simplified) <head><noscript><strong>HEAD</strong></noscript> migrates <strong> into body. |
| 10:25 | <annevk> | Neu: I recommend reading https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element |
| 10:25 | <annevk> | Neu: what is allowed as contents depends on the context |
| 10:25 | <annevk> | Neu: if you place <noscript> inside <head>, you can only allow elements similar to what <head> allows |
| 10:25 | <annevk> | Neu: if you place <noscript> inside <body>, similar |
| 10:25 | <Neu> | sure |
| 10:26 | <Neu> | the context is <head> |
| 10:26 | <annevk> | Then you can't use <strong> |
| 10:26 | <annevk> | Or text |
| 10:26 | <Neu> | and firefox behaves wrong in this case? |
| 10:28 | <zcorpan> | no. how it parses depends on whether script is enabled (per spec) |
| 10:28 | <Neu> | let me show. http://i.imgur.com/1LbApEp.png |
| 10:29 | <zcorpan> | Neu: do you have script disabled? |
| 10:29 | <Neu> | scripting is disabled, first <strong> was in head |
| 10:29 | <Neu> | yes |
| 10:29 | <zcorpan> | that's per spec |
| 10:29 | <Neu> | I can see HEADBODY |
| 10:30 | <zcorpan> | the <strong> closes noscript and opens body |
| 10:30 | <zcorpan> | closes noscript and head and opens body |
| 10:31 | <zcorpan> | https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inheadnoscript |
| 10:32 | <zcorpan> | hmm wonder if <head><noscript></p> is a spec bug |
| 10:33 | <Neu> | zcorpan: you're right, added <styles> everywhere, and really, first <strong> just finished the <head> |
| 10:35 | <zcorpan> | (no </p> is ignored until body is opened...) |
| 10:35 | <Neu> | is there any test suite except one from html5lib? (https://github.com/html5lib/html5lib-tests) |
| 10:47 | <jgraham_> | That's the best parser testsuite |
| 11:13 | <zcorpan> | i've bikeshedded https://quirks.spec.whatwg.org/ \o/ |
| 11:25 | <annevk> | zcorpan: nice |
| 11:26 | <annevk> | zcorpan: README should list code of conduct |
| 11:26 | <zcorpan> | annevk: yeah, will fix that |
| 11:40 | <annevk> | zcorpan: ah, I had already filed an issue |
| 11:40 | <annevk> | zcorpan: forgot about that |
| 12:36 | <zcorpan> | Domenic: can you test http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4085 in Edge? |
| 12:36 | <zcorpan> | (or someone else) |
| 13:01 | <zcorpan> | i have a result (it fills the viewport) |
| 13:30 | <jochen__> | does somebody know the right magic spec: line for bikeshed to reference css fonts? |
| 13:30 | <Ms2ger> | zcorpan / TabAtkins: is element.closest(":has(> :scope)") supposed to work? |
| 13:36 | <zcorpan> | Ms2ger: i don't know |
| 14:36 | <annevk> | I wish I had access to more folks that understand event dispatch as well as smaug... Anyone want to volunteer? |
| 14:37 | annevk | wants feedback on https://github.com/w3c/webcomponents/issues/485#issuecomment-212938463 |
| 16:01 | <TabAtkins> | Ms2ger: Yes, it should - DOM sends the appropriate arguments to the abstract op in its definition. |
| 16:01 | <Ms2ger> | So the weird half-selector syntax ended up existing? :( |
| 16:02 | <TabAtkins> | Yeah, relative selectors are really useful for cases like :has(), and .query() off of an element. |
| 16:03 | <TabAtkins> | Oh, wait tho. |
| 16:04 | <TabAtkins> | :has() lays claim to :scope in a way that conflicts with .closest(), so that won't match anything. |
| 16:04 | <TabAtkins> | (It's asking for an element which has itself as its own child.) |
| 16:06 | <TabAtkins> | MikeSmith: I don't have anything to generate tree diagrams, no. dot isn't too hard to mess with, tho, and can output SVG. |
| 16:10 | <TabAtkins> | zcorpan: I put Quirks in Shepherd. |
| 16:14 | <Ms2ger> | TabAtkins, yeah, was wondering about throwing rather than whether it matched anything |
| 16:14 | <TabAtkins> | It shouldn't throw per spec, definitely. |
| 16:14 | <TabAtkins> | It's a valid, if unfortunately nonsensical, selector. |
| 16:15 | <TabAtkins> | (The clashing :scope pseudo is a problem I recognized years ago but don't have a good idea to fix.) |
| 16:15 | <Ms2ger> | Bwuh |
| 16:15 | <Ms2ger> | SimonSapin, want to file an issue to support :scope in Servo? |
| 16:15 | Ms2ger | disappears |
| 16:28 | <nox> | I think I did that already. |
| 16:29 | <nox> | Well, kind of. https://github.com/servo/servo/issues/7598 |
| 17:19 | <Domenic> | TabAtkins: do you have time to work on https://github.com/w3c/webcomponents/issues/468#issuecomment-207622151 this week? Not sure where you are with all the shadow DOM stuff. |
| 17:21 | <TabAtkins> | Yeah, I think I do. I finished the CSS Shadow DOM stuff yesterday, it's up in the Scoping spec now. |
| 17:23 | <Domenic> | Awesome |
| 17:23 | <Domenic> | I think it would probably be best if you took the lead on defining the primitive needed? Once that's done the actual HTML PR to hook it up to a define() option is pretty simple... |
| 17:31 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=28326 I guess feedback from Mozilla was not needed... |
| 17:41 | <Domenic> | I don't understand that bug |
| 17:41 | <Domenic> | How did they remove isindex parsing? I don't see any commits in w3c/html |
| 17:41 | <Domenic> | Was it part of the initial import? |
| 17:43 | <Domenic> | It's just wrong |
| 17:43 | <annevk> | I guess so |
| 17:44 | <annevk> | It's very wrong |
| 17:44 | <annevk> | Oh, you pointed out that they didn't remove it |
| 17:44 | <Domenic> | yeah |
| 17:45 | <annevk> | sigh |
| 17:49 | <Domenic> | Is there a mozilla bug filed |
| 17:50 | <gsnedders> | is there any way to see whether someone is subscribed to a given W3C mailing list? |
| 17:50 | gsnedders | assumes not |
| 17:51 | <annevk> | Domenic: I don't think so |
| 17:51 | <annevk> | gsnedders: yeah Member-only |
| 17:52 | <Domenic> | OK let's open a whatwg/html bug for it and then open Mozilla and WebKit bugs |
| 17:52 | <Domenic> | I'll do so |
| 17:53 | <annevk> | gsnedders: https://www.w3.org/Member/Mail/AuditForm |
| 18:02 | <smaug____> | philipj: ping |
| 18:03 | <philipj> | smaug____: ping |
| 18:03 | <philipj> | pong even |
| 18:03 | <smaug____> | philipj: do you have some way to check if "Animate" is used often in web pages? |
| 18:04 | <smaug____> | this is about the Animation spec and blink doesn't yet have the interface without [NoInterfaceObject], but we're thinking to follow the spec in Gecko |
| 18:04 | <smaug____> | (normal interface and Constructor) |
| 18:05 | <philipj> | smaug____: what's the interface name? |
| 18:05 | <smaug____> | Animation |
| 18:06 | <philipj> | and you're wondering if there's a risk in having that on the global object I guess? |
| 18:07 | <smaug____> | right |
| 18:16 | <gsnedders> | annevk: thx for that link; was assuming it would be MO |
| 18:17 | <annevk> | gsnedders: that link is not MO? |
| 18:17 | <annevk> | gsnedders: I think it is |
| 18:18 | <gsnedders> | annevk: I mean I was assuming it would be MO if it existed |
| 18:19 | <annevk> | oh doh |
| 18:19 | <gsnedders> | (I'm nowadays an Invited Expert with Member-Only Access according to what my account says, so that's fine by me) |
| 19:02 | <philipj> | smaug____: so what you can do is to search the httparchive for that string, but to be useful you'd want to search on JS I guess. Using BigQuery is supposedly the easiest way to do it, but I've never actually used that. Rick Byers could probably help you get started, though. |
| 19:02 | <smaug____> | rbyers: ^ |
| 19:25 | <jsbell> | smaug____: See https://www.igvita.com/2013/06/20/http-archive-bigquery-web-performance-answers/ for general overview... |
| 19:27 | <jsbell> | smaug____: And a sample query for JS content: https://gist.github.com/inexorabletash/471d674259cb96f0f9ca363b7e533c70 |
| 19:31 | <rbyers> | Smaug: also https://docs.google.com/a/chromium.org/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit?usp=drive_web |
| 19:41 | <laughinghan> | thanks to discussion with smaug____, I think I've found a good reason to believe that fixing :target selectors to update upon history.pushState() is unlikely to break any webapps |
| 19:41 | <smaug____> | thanks |
| 19:42 | <laughinghan> | which is that currently after pushState, though :target selectors aren't updated, if you then hit Back and then Fwd, the :target rules will apply |
| 19:42 | <laughinghan> | http://output.jsbin.com/quludi |
| 19:42 | <smaug____> | interesting |
| 19:43 | <smaug____> | laughinghan: what about hashchange event? |
| 19:43 | <laughinghan> | so the only way a webapp could be broken by the change that wasn't already broken by Back+Fwd is if they had a broken :target rule that was obscured by hysteresis due to popstate/hashchange event handlers |
| 19:44 | <smaug____> | laughinghan: so in that testcase dispatch hashchange when? |
| 19:44 | <laughinghan> | smaug____: oh, your idea that pushState() should also dispatch hashchange? |
| 19:44 | <laughinghan> | you know I'm not sold on that |
| 19:44 | <laughinghan> | to be honest |
| 19:45 | <laughinghan> | but if we're gonna try to be consistent with something |
| 19:45 | <smaug____> | well, if :target is updated... |
| 19:45 | <laughinghan> | I think we should be consistent with hitting the Fwd button |
| 19:45 | <smaug____> | consistency is important |
| 19:45 | <laughinghan> | just like Fwd updates the :target, it fires hashchange at a certain time |
| 19:46 | <laughinghan> | I think it fires hashchange after window.location and history.state has been updated |
| 19:46 | <laughinghan> | therefore, pushState should fire hashchange after window.location and history.state have been updated |
| 19:46 | <laughinghan> | smaug____: is that what you mean by "dispatch hashchange when?" |
| 19:47 | <smaug____> | that sounds about right |
| 19:50 | <laughinghan> | huh |
| 19:50 | <laughinghan> | unlike popstate, hashchange fires after scroll has been restored |
| 19:50 | <laughinghan> | http://output.jsbin.com/qeloye |
| 19:50 | <laughinghan> | er, that test case needs some explanation |
| 19:51 | <laughinghan> | basically in the console a nonzero number is logged |
| 20:17 | <TabAtkins> | Anyone remember who runs the @CSSCommits bot? |
| 20:18 | <TabAtkins> | (It's got some bizarre bug at the moment.) |
| 20:32 | <Domenic> | mathiasbynens I believe |
| 21:24 | <smaug____> | So https://html.spec.whatwg.org/multipage/forms.html#the-select-element "Upon this option element being picked (either through a click...." ... "before the relevant user interaction event is queued (e.g. before the click event)" |
| 21:24 | <smaug____> | doesn't quite make sense to me |
| 21:25 | <smaug____> | if we're picking based on click, that click sure has been queued already |
| 21:25 | <smaug____> | and click event isn't something to queue |
| 21:25 | <smaug____> | it is dispatched based on mousedown/up usually |
| 21:25 | smaug____ | files a bug |
| 21:25 | <smaug____> | poor editors |
| 21:52 | <smaug____> | anyone recall if firing "input" for <select> was added recently |
| 21:52 | <smaug____> | I think it is |
| 21:53 | <smaug____> | but can't find the bug |
| 21:53 | <smaug____> | github's search is really horrible :/ |
| 22:06 | <Domenic> | I think it was before the move to GitHub |
