| 04:47 | <annevk> | I wonder what made Twitter show the trailing slash in profile URLs |
| 08:14 | <heycam> | MikeSmith, ping |
| 08:25 | <MikeSmith> | heycam: here now |
| 08:26 | <heycam> | MikeSmith, hi! can you add someone to the right github group so they can push changes to the SVG spec? |
| 08:26 | <heycam> | MikeSmith, github username is boggydigital |
| 08:27 | <heycam> | MikeSmith, I think the group name is "svgwg members" or something |
| 08:27 | <MikeSmith> | cool username |
| 08:27 | MikeSmith | checks now |
| 08:28 | <MikeSmith> | heycam: ok added just now |
| 08:29 | <heycam> | MikeSmith: cheers! |
| 08:57 | <annevk> | Domenic: beverloo: abarth: belated happy b-day! |
| 09:05 | <MikeSmith> | triplets |
| 09:05 | <MikeSmith> | speaking of abarth I wonder where or where has our abarth gone these days |
| 09:06 | <MikeSmith> | he seems to not be working on web-platform stuff as much these days |
| 09:06 | <MikeSmith> | at least not publicly |
| 09:06 | <MikeSmith> | I think the web platform misses him |
| 09:09 | <MikeSmith> | so I'm wondering what level of implementor interest does the current draft at http://w3c.github.io/filesystem-api/ have |
| 09:10 | <MikeSmith> | I see that Domenic filed an issue against it a couple weeks ago https://github.com/w3c/filesystem-api/issues/4 |
| 09:11 | <MikeSmith> | so I would assume that means it's still a relevant spec with some promise |
| 09:15 | <arunranga> | Hi MikeSmith: I’d say parts of it are relevant including figuring out directory upload stuff. |
| 09:16 | <MikeSmith> | oh hey arunranga-afk ! |
| 09:16 | <MikeSmith> | long time no see |
| 09:17 | <arunranga-afk> | oh hai MikeSmith :) |
| 09:17 | <MikeSmith> | arunranga-afk: I've not seen so much recent discussion about it but then I'm not on script-coord any more so maybe there's been some there |
| 09:18 | <MikeSmith> | anyway I hope we can finally get this right and get some implementor momentum behind it |
| 09:18 | arunranga-afk | hopes |
| 09:18 | <MikeSmith> | I'm glad you're still on it |
| 09:19 | <arunranga-afk> | MikeSmith, there’s been some public-script-coord discussion about having certain web platform types, including that old tin can, FileList, being converted to Array-types. |
| 09:20 | <MikeSmith> | ah OK |
| 09:20 | <MikeSmith> | I guess that's the right place now to have those discussions |
| 09:40 | <MikeSmith> | https://twitter.com/ISOTC211/status/608567032506912768 "The @W3C process is open|: drafts are published, mailing list available to public, etc... Quite different from @opengeospatial and #ISOTC221" |
| 09:44 | <MikeSmith> | in https://developer.apple.com/videos/wwdc/2015/?id=501 Brent Fulgham talks about "people coming to JavaScript from languages like Swift" (in the context of saying those people find JS's "prototype-based syntax has been somewhat less accessible" to such people |
| 09:58 | <ondras> | https://pbs.twimg.com/media/CGvdAOBUIAEQCUE.jpg:large |
| 10:01 | <annevk> | MikeSmith: what is open|: supposed to mean? |
| 10:02 | <annevk> | ondras: I don't get why he refers to the friend as crazy in the third panel after just saying he isn't |
| 10:16 | <MikeSmith> | annevk: maybe that tweeter meant to type an explanation point instead of that pipe? |
| 10:16 | <MikeSmith> | aren't they the same key on english keyboards |
| 10:17 | <MikeSmith> | oh I guess not |
| 10:32 | <ondras> | annevk: yeah. well, I am not an author, just an twitter->irc proxy |
| 10:32 | <ondras> | *a |
| 10:35 | <MikeSmith> | inconsistency is funny |
| 11:07 | <annevk> | philipj: if you want to experiment with lowercasing createAttribute() input, that'd be great... |
| 11:08 | <annevk> | philipj: but currently no browser does that so maybe that's a bridge too far? |
| 11:15 | <philipj> | annevk: I don't know, would that be a big win if it would work out? |
| 11:16 | <philipj> | annevk: I'm not sure how to estimate the risk of it without extra bookkeeping |
| 11:16 | <annevk> | philipj: you can do atom comparison rather than string comparison |
| 11:16 | <annevk> | philipj: also, seems like Chrome does not always use case-insensitive matching... e.g. removeAttribute does something else? |
| 11:16 | <annevk> | philipj: per comments in the Gecko bug |
| 11:18 | <philipj> | but when you're doing lookup, you're not traversing the attributes and comparing |
| 11:18 | <philipj> | sorry, wasn't finishing typing that |
| 11:18 | <philipj> | I'm just guessing that there's a hash map, and that hash map could be case insensitive without storing the strings themselves in a normalized case |
| 11:18 | <philipj> | maybe? |
| 11:18 | <annevk> | sure |
| 11:19 | <annevk> | I guess the more interesting thing is that not even case-insensitive will give us the same behavior, since Chrome does not share that algorithm across all methods |
| 11:20 | <annevk> | philipj: oh also, createAttribute("test:test") is different in Chrome/Safari vs Firefox/IE & DOM |
| 11:20 | <philipj> | annevk: and you're right, removeAttribute() does look different, it lowercases the value if it's an HTML Element and Document |
| 11:20 | <philipj> | annevk: and so does hasAttribute actually |
| 11:21 | <annevk> | but not getAttribute()? |
| 11:21 | <annevk> | meh |
| 11:21 | <philipj> | a weird mix of lowercasing and case-insensitive comparison, this is |
| 11:21 | <annevk> | yes |
| 11:21 | <annevk> | seems like we should do something consistent at least |
| 11:22 | <philipj> | well, getAttribute() seems to set a |shouldIgnoreCase| which is used to do a case-insensitive compare when iterating over the attributes |
| 11:23 | <philipj> | so at least Blink doesn't do the hash table thing, I guess there are too few attributes on average for it to be worth it |
| 11:23 | <philipj> | I agree this is pretty strange and inconsistent |
| 11:25 | <philipj> | how closely have you studied Gecko's and IE's black-box behavior? any hunch as to what state would be easiest to reach interop on? |
| 11:26 | <annevk> | Gecko is problematic since we changed |
| 11:26 | <annevk> | IE seemed to be mostly aligned with Chrome/Safari |
| 11:26 | <annevk> | |shouldIgnoreCase| seems easiest |
| 11:26 | <philipj> | right, did you just revert the change or is there now a old-Gecko vs. new-Gecko behavior to consider? |
| 11:26 | <annevk> | We haven't reverted the change yet |
| 11:26 | <annevk> | We need to decide on something though before we ship |
| 11:26 | <philipj> | did it reach stable and break stuff? |
| 11:27 | <annevk> | No, broke stuff earlier on |
| 11:27 | <annevk> | So now we need to figure out what to do |
| 11:27 | <philipj> | ok, that's a pretty good indication it's not going to fly. what was the attempted behavior? to lowercase like the spec says? |
| 11:28 | <annevk> | Yeah, but we did not attempt lowercasing createAttribute() |
| 11:28 | <annevk> | The cases that surfaced would have worked if that lowercased, but there's probably other cases that would break |
| 11:28 | <annevk> | IE seems to be more consistently case-insensitive |
| 11:28 | <annevk> | At least given https://bugzilla.mozilla.org/show_bug.cgi?id=1165851#c32 |
| 11:29 | <annevk> | So making everyone do that seems like the most trivial change |
| 11:29 | <annevk> | The prettiest change would be lowercasing createAttribute() |
| 11:29 | <philipj> | there's really no way to measure the risk of lowercasing the input, as there's no way to track how the string returned by e.g. element.attributes[0].localName is used |
| 11:29 | <annevk> | yeah |
| 11:29 | <annevk> | :/ |
| 11:30 | <philipj> | but wait, in an HTML document, should element.setAttribute('FOO', 'bar') result in an element with localName 'FOO'? |
| 11:31 | philipj | tries |
| 11:31 | <annevk> | nope |
| 11:31 | <annevk> | different code path |
| 11:31 | <philipj> | so where should the lowercasing go in the hypothetical store-as-normalized go? |
| 11:32 | <annevk> | philipj: step 1.5 of https://dom.spec.whatwg.org/#dom-document-createattributelocalname would do that |
| 11:33 | <philipj> | oh, so the extent of the compat risk is just when you manually create attribute nodes? |
| 11:33 | <annevk> | (at which point we might introduce some kind of abstract "create an attribute" operation that does all the work) |
| 11:33 | <annevk> | philipj: yeah |
| 11:33 | <annevk> | afaict that's the only place that does not lowercase |
| 11:34 | <philipj> | well, that actually doesn't sound too crazy |
| 11:40 | <philipj> | the relevant use counter is https://www.chromestatus.com/metrics/feature/timeline/popularity/111 at ~0.13% |
| 11:41 | <annevk> | I left a comment in the bug suggesting this alternative path |
| 11:42 | <philipj> | however, if the true justification for trying this is performance, perhaps someone should verify that it's really going to be faster to lowercase the input and do case-sensitive compares than to just do case-insensitive compares in the loop? |
| 11:46 | <annevk> | philipj: I don't think perf is a great argument, it would mostly be consistency |
| 11:46 | <philipj> | what was Gecko's old behavior? |
| 11:46 | <annevk> | philipj: though perhaps perf is important for Selector matching |
| 11:47 | <philipj> | perf is pretty important in this context though, don't want Gecko implementing this new model and then we can't land it in Blink because there happens to be a perf test that regresses |
| 11:48 | <philipj> | oh wait, let me see what setAttribute does |
| 11:49 | <philipj> | I'm still a bit confused, clearly setAttribute already does the lowercasing, and that's the point where one should be careful |
| 11:49 | <annevk> | philipj: I think per https://bugzilla.mozilla.org/show_bug.cgi?id=1075702 we might have lowercased for setNamedItem and friends |
| 11:50 | <philipj> | I link to think of all other APIs as aliases for setAttribute(NS) and getAttribute(NS), does that match your thinking? |
| 11:50 | <annevk> | philipj: but not createAttribute(), which would bem ore logical |
| 11:50 | <philipj> | s/link/like/ |
| 11:50 | <annevk> | not really |
| 11:51 | <philipj> | no? so instead all the web-exposed APIs are entry points into the same underlying algorithm? |
| 11:51 | <annevk> | yeah, they all share a bunch of logic |
| 11:52 | <philipj> | so, anyway, the important point is that it's strange if say setAttribute() has different rules for case-folding than say setting Attr.value |
| 11:52 | <philipj> | as long as that's not the case, it's fine |
| 11:53 | <annevk> | setAttribute() has different rules from createAttribute() |
| 11:53 | <annevk> | the value is never normalized |
| 11:53 | <annevk> | the problem here is around attribute names |
| 11:54 | <philipj> | sorry, I was thinking about changing the attribute name, but obviously you can't do that via Attr |
| 11:55 | <philipj> | so are setAttribute(), setAttributeNS(), createAttribute() and createAttributeNS() the only entry points for scripts to create attributes, other than via the parser a la innerHTML? |
| 11:57 | <Ms2ger> | I believe that's correct |
| 11:58 | <philipj> | well, then since the parser already normalizes the case, then trying to close that last hole that is createAttribute() does sound pretty good |
| 11:59 | <philipj> | however, this does mean that for setAttributeNS(namespace, 'FOO', value) the resulting Attr would have localName 'FOO', correct? and getAttribute('FOO') would fail to return that value, where it would currently |
| 12:00 | <annevk> | philipj: in Gecko that has always failed to return a value |
| 12:00 | <annevk> | philipj: not sure about other browsers |
| 12:01 | <annevk> | What Gecko did previously as far as I can tell is normalize case during setAttributeNode / setNamedItem... Ms2ger? |
| 12:01 | <philipj> | annevk: that does work in Blink currently |
| 12:01 | <Ms2ger> | I can look if you find me the bug that changed it... |
| 12:01 | <annevk> | philipj: yeah, and removeAttribute() does not |
| 12:02 | <annevk> | Ms2ger: https://bugzilla.mozilla.org/show_bug.cgi?id=1075702 |
| 12:02 | <philipj> | annevk: same in IE11 |
| 12:02 | <philipj> | don't know, given that it never worked in Gecko it could work out |
| 12:02 | <annevk> | philipj: I'm not worried about that though, seems like the smallest of all risks |
| 12:03 | <philipj> | annevk: what kind of code are you most worried about breaking? |
| 12:03 | <annevk> | philipj: attr.name == "FOO" |
| 12:04 | <philipj> | annevk: where "FOO" comes from document.createAttribute("FOO")? |
| 12:04 | <annevk> | yes |
| 12:05 | <philipj> | ok, would it be of any help to measure how often lowercasing the name in createAttribute() results in a different string? |
| 12:05 | <philipj> | as an upper limit of breakage |
| 12:05 | <philipj> | it would be a few months to get data, so if you're in a hurry it won't help you |
| 12:05 | <annevk> | Maybe. I think given what Gecko did before lowercasing is probably sound |
| 12:06 | <annevk> | Since the only code that would break is code that checked the name before appending the attribute |
| 12:06 | <annevk> | Since appending it lowercased the name in Gecko |
| 12:11 | <philipj> | oh, so it was setAttribute that would change the case? |
| 12:14 | <philipj> | one difference if doing it in createAttribute is that you don't yet know if it'll be attached to an HTML element, so the conditions won't be exactly the same |
| 12:14 | <philipj> | but that's probably fine |
| 12:16 | <philipj> | well, keep me posted on what you want to try in Gecko and if you change the spec for document.createAttribute(), in which case I'll add a use counter to gague if that'll be safe |
| 12:16 | <annevk> | philipj: setAttribute != setAttributeNode |
| 12:17 | <annevk> | I think I'll suggest to bz that we lowercase for createAttribute(), if he comes online again |
| 12:17 | <philipj> | annevk: uh, yes, I mean setAttributeNode(document.createAttribute('FOO')) |
| 12:26 | <MikeSmith> | annevk: I just now reverted that change I made to github/xrefs that added the IETF Origin spec |
| 12:26 | <annevk> | ta |
| 12:37 | <philipj> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=1165851#c36 |
| 12:55 | <JonathanNeal> | Where would be the best place for someone to make a suggestion like extending RegExp to include a RegExp.escape function ala http://discourse.specifiction.org/t/regexp-escape-str/832 |
| 12:55 | <JonathanNeal> | It would seem useful to provide some direction, like contact so-and-so or write an email to such-list. |
| 12:56 | <Ms2ger> | es-discuss |
| 13:18 | <JonathanNeal> | Thanks, Ms2ger! |
| 13:19 | <Sebmaster> | annevk: i think i dont get it, why would it return null? |
| 13:21 | <annevk> | Sebmaster: read step 2 of https://url.spec.whatwg.org/#dom-urlutils-origin |
| 13:21 | <Sebmaster> | ohhh |
| 13:22 | <Sebmaster> | so you serialize the GUID, which is not a scheme, host, port tuple |
| 13:22 | <annevk> | right |
| 13:22 | <annevk> | Sebmaster: I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28788 though to get HTML a little clearer on this |
| 13:23 | <Sebmaster> | is the GUID ever public then? |
| 13:23 | <annevk> | Sebmaster: it should just say "if origin is an opaque identifier, return 'null'" |
| 13:23 | <annevk> | Sebmaster: nope |
| 13:23 | <annevk> | Sebmaster: neither is the alias concept |
| 13:23 | <Sebmaster> | what're aliases? |
| 13:23 | <Sebmaster> | I havent read about those anywhere |
| 13:24 | <annevk> | Sebmaster: read HTML's definition of what an origin can be |
| 13:25 | <annevk> | Sebmaster: you encounter alias in the DOM, with <iframe> and such |
| 13:25 | <Sebmaster> | huh, wow |
| 13:25 | <Sebmaster> | there's so much we still have to get into jsdom :/ |
| 13:27 | <Sebmaster> | Thanks, annevk |
| 14:25 | <darobin> | Sebmaster: FWIW you're doing awesome work with jsdom, there's always more but keep it up :) |
| 14:29 | <Sebmaster> | darobin: thanks! |
| 14:36 | <JonathanNeal> | mathiasbynens: thank you for that ticket. Good, someone solved this five years ago. |
| 14:36 | <mathiasbynens> | JonathanNeal: well, not really, it’s still not being standardized |
| 14:37 | <mathiasbynens> | baby steps though :P |
| 14:37 | <JonathanNeal> | “The tree of features must be refreshed from time to time with the blood of polyfills and new threads.” |
| 14:42 | <MikeSmith> | heh |
| 14:56 | <hsivonen> | annevk: have you checked whether input methods in common use in Hong Kong and Taiwan produce astral characters and not PUA characters these days for the astral characters in Big5? |
| 14:57 | <annevk> | no |
| 14:57 | <hsivonen> | annevk: it appears that Windows 8.1 comes with font coverage for the whole of Encoding Standard Big5 but Ubuntu does not (at least not by default in an en-US install) |
| 14:57 | <annevk> | philipj might have |
| 14:57 | <hsivonen> | annevk: ok. that's a possible source of risk, then |
| 15:01 | <smaug____> | any amazon employees here? |
| 15:02 | <annevk> | smaug____: hey! |
| 15:02 | <annevk> | smaug____: so about web components |
| 15:02 | <smaug____> | annevk: yes, I pinged yesterday |
| 15:02 | <annevk> | smaug____: I think the only thing that was discussed is instead of an imperative API move back to the slots proposal |
| 15:02 | <smaug____> | (sorry, been offline/online unusual times because of uncle-duties) |
| 15:02 | <annevk> | smaug____: since everyone but Google was okay with that, and now Google is too |
| 15:03 | <smaug____> | right |
| 15:03 | <smaug____> | but there isn't really a proper slots proposal yet, right? |
| 15:03 | <smaug____> | I mean something which truly explain what would be spec'ed |
| 15:04 | <smaug____> | including when distribution happens (but I assume that it just sync) |
| 15:04 | <smaug____> | s/it/is/ |
| 15:06 | <annevk> | smaug____: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md |
| 15:08 | <annevk> | hmm, new API that returns a NodeList... |
| 15:16 | <smaug____> | annevk: ah... |
| 15:16 | <smaug____> | doesn't explain when distribution happens |
| 15:17 | <annevk> | smaug____: right, that's still left up to the UA |
| 15:17 | <annevk> | I have somewhat mixed feelings about this... |
| 15:41 | <philipj> | hsivonen: I didn't check any IMEs |
| 15:43 | <philipj> | I would guess that the most common ones are Google pinyin and Sogou pinyin |
| 15:43 | philipj | gotta go |
| 17:14 | <dglazkov> | annevk, smaug____: going to hack on this with rniwa today. Hopefully, will flesh this out a bit more. |
| 17:55 | <annevk> | dglazkov: cool |
| 17:57 | <dglazkov> | annevk: on NodeList, please patch it up the way you like it |
| 17:57 | <dglazkov> | I was just copying stuff from the current spec |
| 17:57 | <annevk> | will do |
| 21:02 | <wanderview> | JakeA: ping |
| 21:05 | <JakeA> | wanderview: hey, winding down for the night, but can pick up whatever in the morning |
| 21:05 | <wanderview> | np, I just realized I have to run in a minute as well |
| 21:05 | <wanderview> | sorry for the late ping |
| 21:27 | <TabAtkins> | annevk: Re the simpsons cartoon, that's because it's what Troy McClure said in the episode (modulo JS stuff, obvs) |
