| 06:08 | <annevk> | TabAtkins: it'd be great if LINK ERROR came with a line number |
| 09:06 | Ms2ger | gives up on public-webapps |
| 09:45 | <annevk> | I was thinking the same |
| 09:46 | <jgraham> | Apparently I had already given up on it, but looking at the thread titles, I guess I have an inkling of why there might be a mass exodus |
| 10:02 | smaug____ | wonders if there will be real world use for es symbols |
| 11:52 | <nox> | Should a placeholder disappear the moment its input is focused? |
| 11:56 | <annevk> | nox: up to UX |
| 11:57 | <nox> | annevk: No recommandation at all? |
| 11:57 | <nox> | annevk: Ain't that inconsistent with the spec for :placeholder-shown? |
| 11:58 | <annevk> | Hmm don't think so |
| 11:58 | <nox> | Err no, can't read. |
| 11:58 | <nox> | The spec for placeholder says "User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string, especially if the control is not focused.", so yeah. |
| 13:53 | astearns | +1 to Ms2ger |
| 14:05 | <nox> | What's wrong with public-webapps. |
| 14:05 | <nox> | ?* |
| 14:19 | <annevk> | signal/noise |
| 14:20 | <annevk> | astearns: 😊 |
| 14:24 | <nox> | What's the TL;DR for 'is' in createElement()? |
| 14:29 | <caitp> | nox: probably like the "is" attribute, which afaik is necessary to avoid custom elements in tables from being orphaned (or similar things like that)? |
| 14:30 | <nox> | I see. |
| 14:45 | <Ms2ger> | nox, `is` is custom elements |
| 14:45 | <nox> | Ms2ger: Should I close the Servo issue? |
| 14:46 | <Ms2ger> | I just did :) |
| 14:47 | <nox> | Ms2ger: Thanks. |
| 16:00 | <caitp> | its too bad nobody wants to break the web to get rid of that orphaning crap entirely, since it's terrible ._. |
| 16:16 | <wanderview> | JakeA: your SW modules issue reminded me of this... do you think its a problem? https://github.com/slightlyoff/ServiceWorker/issues/894 |
| 16:18 | <JakeA> | ah, yes, good spot |
| 17:15 | <TabAtkins> | annevk: It'd be great if *all* the errors came with line numbers. Haven't been able to crack that nut so far; it's apparently a well-known problem that lxml drops its line numbers. |
| 17:15 | <TabAtkins> | (I only get a line number for the <html> element; all the rest have None.) |
| 17:27 | <TabAtkins> | At this point I'm *this* close to just regex-parsing for opening tags in the original HTML and adding a line-number attribute manually. On the upside, that would avoid me having to coordinate tons of "corrections" as I do various text-munging (mostly Markdown processing) before the HTML parser runs. |
| 17:34 | <TabAtkins> | Fuck it, I'm gonna do that (behind a command-line flag, so if it fucks anything up you can just not use it). |
| 18:16 | <annevk> | TabAtkins: lxml sounds sad |
| 18:16 | <TabAtkins> | It is and I hate it |
| 18:16 | <TabAtkins> | But it offers the only half-decent tree api that's html5lib-compatible and CSSParser-compatible. |
| 18:17 | <TabAtkins> | So I just soldier on, and reinvent most of DOM on top of it so I have a sane API to work with. |
| 20:04 | <hallvors> | annevk: still around? Someone is asking in https://bugzilla.mozilla.org/show_bug.cgi?id=289714 if an empty response labelled as XML should fire xhr.onerror .. |
| 20:04 | <hallvors> | I'm not sure but I guess I should RTFS ("read the fantastic spec" ;)) |
| 20:19 | <annevk> | hallvors: not sure |
| 20:19 | <annevk> | hallvors: don't think so |
| 20:20 | <hallvors> | annevk: I've just written a comment, hope it makes enough sense |
| 20:20 | <annevk> | hallvors: broken XML does not fire it either |
| 20:21 | <hallvors> | Indeed, that's what I figured out |
| 20:22 | <annevk> | hallvors: looks good, don't think we want to change DOMParser at this point either |
| 20:22 | <annevk> | hallvors: pretty sure web depends on parseerror element and is part of spec |
| 20:23 | <hallvors> | really? which spec? |
| 20:23 | <hallvors> | imho parsererror elements are just weird |
| 20:23 | <hallvors> | :-p |
| 20:24 | <hallvors> | and should die :-] |
| 20:33 | <annevk> | hallvors: DOM Parsing |
| 20:37 | <caitp> | if you killed everything weird that should die about the web, there might not be much of a web left |
| 20:45 | <hallvors> | caitp: lol |
| 20:46 | <hallvors> | annevk: then it gets a bit inconsistent - if we mandate the odd parsererror document for a DOMParser, but do NOT want it for XHR responseXML.. |
| 20:47 | <hallvors> | thought whatever.. |
| 20:53 | <annevk> | hallvors: yeah, jl complained about this too in the good old days |
| 20:53 | <annevk> | hallvors: no layering or consistency 😢 |
| 20:54 | <annevk> | But yeah, just have to suck it up and do a better job going forward |
| 21:50 | <Munter> | annevk: I've tried to sum up the content addressable caching discussions in a blog post, since I found it hard to find all the relevant information in an easily accessible way: https://mntr.dk/2016/content-addressable-browser-caching/ |
| 22:48 | <nox> | I think the spec for querySelectorAll is wrong. |
| 22:49 | <TabAtkins> | nox: How so? |
| 22:49 | <nox> | It seems to me that element.querySelectorAll("*") should include element, but user agents don't. |
| 22:52 | <nox> | TabAtkins: Specifically, the scope-filtered method says to filter to the scoping root and its descendants. |
| 22:52 | <TabAtkins> | yup, you're right. as specified it should indeed include element. |
| 22:53 | <TabAtkins> | But that's not the intention nor does it match impls. So it's a DOM bug. |
| 22:53 | <nox> | TabAtkins: Checked in Safari and Firefox. |
| 22:54 | <nox> | Chrome agrees too. |
| 22:55 | <TabAtkins> | File a bug on DOM so annevk can fix it |
| 22:56 | <nox> | Yeah will do tomorrow. |
| 22:56 | <nox> | Reviewing the failing tests in Servo. |
| 22:56 | <nox> | (WPT agrees with UAs already.) |
| 23:06 | <TabAtkins> | did it for you |
| 23:55 | <nox> | TabAtkins: Thanks! |
| 23:59 | <TabAtkins> | nox: "will do tomorrow" is usually code for "i've already forgotten about it", at least when I say it ^_^ |