| 07:53 | <zcorpan> | MikeSmith: I suppose template should have been parsed like foreignObject |
| 07:54 | <annevk> | I think all that was considered at the time |
| 07:54 | <annevk> | But too long ago to remember the specifics :/ |
| 07:54 | <zcorpan> | Or like foreignObject doesn't solve that, hmm |
| 07:55 | <MikeSmith> | ok |
| 07:56 | <MikeSmith> | well if we don’t want to change the parsing at this point, or can’t, then I guess we should at least change the document-conformance requirements as far as the end-tag omission rules |
| 07:56 | <MikeSmith> | right? |
| 07:57 | <MikeSmith> | I mean specifically to say that the </td> and </tr> end tags can’t be omitted if for a td or tr element that’s a child of a template element |
| 08:07 | <zcorpan> | Right |
| 08:15 | <MikeSmith> | OK |
| 08:15 | <MikeSmith> | will raise a PR for that then |
| 08:15 | <MikeSmith> | thanks |
| 08:49 | hsivonen | is currently very annoyed by http://www.unicode.org/L2/L2017/17168-utf-8-recommend.pdf |
| 08:49 | <hsivonen> | I wonder how to formulate polite and well-reasoned feedback |
| 08:49 | <hsivonen> | I don't feel polite at all about that at the moment |
| 08:51 | <hsivonen> | I guess I'm going to argue that we know UTF-16 is bad, so we should optimize UTF-8 decode to software that uses UTF-8 internally and, therefore, we should optimize for UTF-8 *validation* |
| 08:55 | <annevk> | hsivonen: can't we just argue on the basis that changing something widely deployed is bad if there's no concrete benefit? |
| 08:55 | <annevk> | hsivonen: I guess I'm glad you know where to even go raise this, Unicode is rather opaque to me |
| 08:58 | <hsivonen> | annevk: arguing from deployment isn't a great point when the argument for change involves standardizing ICU's spec violation |
| 08:58 | <hsivonen> | I want to argue though that Unicode now owning ICU is hazardous to the credibility of spec text if ICU bugs, not spec text, rules |
| 08:59 | <annevk> | I had forgotten the bit about ICU, sigh |
| 09:00 | <annevk> | JavaScript folks building APIs directly on top of ICU is also rather worrisome |
| 09:00 | <annevk> | But I haven't been able to convince littledan and others of that I think |
| 09:02 | <littledan> | hey, now's a great time to have this conversation; Mozilla just started contracting with Igalia to work on Intl features (Zibi's been my contact), so I'll have more time to take things in whatever direction is appropriate |
| 09:02 | <littledan> | question 1: Do you think a normative reference to, not ICU but CLDR would be bad? |
| 09:03 | <annevk> | CLDR dependency seems more okay, there's some precedent for that I think |
| 09:04 | <annevk> | That's standardized data, basically, not a standardized implementation |
| 09:04 | <littledan> | question 2: If new APIs should differ from ICU, how should they? Obviously we won't replicate warts like calling something Normalizer2, but there are some basic patterns that have been copied so far, like using using a factory that holds locale data, and keeping the names when they seem reasonable |
| 09:04 | <littledan> | are these bad ideas? |
| 09:05 | <littledan> | question 3: How should we deal with OS default settings--should it somehow be serialized in a locale object (similar to current patterns), or should it just be threaded through as a complicated default, possibly in conjunction with new options that explicitly opt into it (Zibi's been suggesting this; apparently the suggestion came from MS) |
| 09:07 | <annevk> | I think in terms of API design it's always good to check how various systems solve it, but ultimately you want something that looks familiar to JavaScript developers; if what ICU does matches that it doesn't necessarily seem problematic to copy patterns |
| 09:08 | <annevk> | As for that last question, OS defaults are typically exposed on the Navigator object somehow |
| 09:08 | <littledan> | question 4: Should we add CLDR pattern strings for datetime and number formatting? Should we add parsing? We've been leaving these out so far, in order to avoid being too ICU-like |
| 09:09 | <littledan> | the claim is that, without pattern strings, there's no realistic way to expose the OS defaults on the navigator |
| 09:11 | <annevk> | littledan: does Microsoft participate actively? |
| 09:11 | <littledan> | not at the moment; they're too tied up in investigating switching to ICU |
| 09:11 | <annevk> | littledan: so far they have the only non-ICU implementation that's somewhat competitive in terms of features |
| 09:11 | <annevk> | oh my |
| 09:12 | <littledan> | OTOH we have community members who are building various polyfills based on CLDR and not ICU |
| 09:12 | <annevk> | I wish Mozilla had more resources so we could write an impl in Rust |
| 09:12 | <littledan> | like Mathias Bynens and the Intl.js folks |
| 09:13 | <littledan> | well, I was just invited to the Mozilla all-hands for this Intl work, and then un-invited since it's not Quantum; maybe if a Rust rewrite were added into the picture, Intl would suddenly be Quantum and everyone would get resources... |
| 09:14 | <littledan> | currently Zibi's working on using ICU *more* rather than Mozilla's legacy stuff for things were functionality overlaps; Jungshik Shin is doing the same within V8 |
| 09:14 | <littledan> | since the non-ICU stuff tends to be a worse implementation |
| 09:15 | <annevk> | Well, hsivonen just wrote a new encoding library in Rust that seems to be better than what ICU offers, which is what prompted my thing above |
| 09:15 | <littledan> | anyway, FWIW V8 doesn't use ICU's UTF-8 decoder and isn't looking at switching |
| 09:16 | <annevk> | But we didn't use ICU before, we used iconv |
| 09:16 | <annevk> | Well, plus patches |
| 09:16 | <littledan> | anyway, that thread is sad |
| 09:17 | <annevk> | littledan: anyway, I guess we are mostly on the same page, I just hope that everyone using ICU underneath won't make future refactorings extremely hard |
| 09:18 | <littledan> | I hope so too. The Intl spec tries to be sufficiently detailed so it should be possible. Do you think it meets that goal? |
| 09:18 | <littledan> | (actually, IMO the Intl spec is too detailed now, tying down some things to a wrong default that implementations should be allowed to get right) |
| 09:26 | <annevk> | littledan: I haven't reviewed it in enough detail to say, I probably should one day |
| 10:25 | <hsivonen> | hmm. my email doesn't show up at http://unicode.org/pipermail/unicode/2017-May/date.html |
| 10:26 | <hsivonen> | maybe stuck in human moderation or achive view slow to update |
| 10:26 | <hsivonen> | annevk: argument from deployment works, actually, since Blink and WebKit don't use the ICU UTF-8 decoder |
| 10:28 | <hsivonen> | annevk: uconv isn't iconv plus patches |
| 10:29 | <hsivonen> | annevk: we use iconv only for non-Android, non-Mac *nix filenames |
| 10:30 | <MikeSmith> | JakeA: when you have time, please see https://stackoverflow.com/questions/43974704/service-workers-fetch-event-listener-what-does-it-catch and consider posting an answer |
| 10:32 | <MikeSmith> | I tried myself http://stackoverflow.com/a/43976229/441757 but that’s basically just repeating what’s already explained at MDN and the OP seems to indicate they’re seeing some behavior that doesn’t conform to the requirements |
| 10:32 | <MikeSmith> | but they’re seeing it in both Firefox and Chrome so maybe there’s something I’m misunderstanding |
| 10:32 | <MikeSmith> | annevk: |
| 10:32 | <MikeSmith> | annevk: ⬆ |
| 10:47 | <annevk> | hsivonen: oh, uconv is its own thing, ta |
| 10:49 | <annevk> | MikeSmith: added an answer |
| 10:49 | <MikeSmith> | annevk: thanks |
| 10:49 | MikeSmith | takes a look |
| 10:50 | <MikeSmith> | ah, d'oh navigations |
| 10:50 | <MikeSmith> | annevk: thanks |
| 10:52 | <annevk> | mkwst: potentially with Origin policy we could do the "request with me without credentials always" thing, but bleh |
| 10:52 | <mkwst> | annevk: *shrug* It would be nice if the problem statement was a bit crisper. It's not clear what folks want. |
| 10:53 | <annevk> | mkwst: timbl doesn't like varying on credentials; he thinks the input should be just a URL, nothing else |
| 10:54 | <hsivonen> | I now I got notification that my email got stuck in moderation |
| 10:54 | <annevk> | mkwst: and the TAG apparently doesn't just tell me no so now there's this debate-by-proxy |
| 10:54 | <annevk> | s/me/him/ oops |
| 10:56 | <mkwst> | annevk: *shrug* Like I said on the bug, I don't think something like `Access-Control-Allow-Origin: omg-its-totally-public-did-you-make-sure-this-is-sane?` is out of the question. |
| 10:56 | <mkwst> | But I'm reluctant to add it without something more compelling than "Tim doesn't want to add options to `fetch()`." |
| 10:58 | <annevk> | mkwst: I'd actually like that implementers pick up on existing extensions first |
| 10:59 | <mkwst> | By "extension" do you mean "redirect behavior"? |
| 10:59 | <annevk> | mkwst: that and also allowing * for more headers |
| 10:59 | <mkwst> | I know some folks on our loading team wanted to look at that. |
| 11:00 | <mkwst> | Hrm. Which headers? That should be a small change. |
| 11:00 | <annevk> | mkwst: Expose-Headers, Allow-Headers, Allow-Methods (as long as no credentials are in play and with the exception of Authorization) |
| 11:01 | <annevk> | mkwst: I filed bugs and there's tests too |
| 11:01 | <mkwst> | I see. I'll follow up. |
| 11:16 | <mkwst> | annevk: Does Gecko support these wildcards? I'm trying to run the tests you added from `w3c-test.org`, but it's too slow to execute. |
| 11:16 | <annevk> | mkwst: I don't think it does yet |
| 11:17 | <annevk> | mkwst: using https:// sometimes ends up being faster on w3c-test.org |
| 11:17 | <annevk> | mkwst: not sure what is going on with that server, it's rather useless |
| 11:17 | <mkwst> | Huh. HTTPS is faster. |
| 11:18 | <mkwst> | Ok. I'll poke our loading folks to see if they can get this on a roadmap. |
| 11:33 | <hsivonen> | I take it that moderation of the unicode list doesn't happen at European business hours |
| 12:05 | <annevk> | hsivonen: Mark Davis lives in Europe, but I suppose he wouldn't do the moderation |
| 12:06 | <annevk> | (I tried to find if he has a GitHub ID so I could copy him on that issue, but no luck.) |
| 12:53 | <zcorpan> | MDN and caniuse claim IE10/11 support WebKitCSSMatrix. Per browserstack testing http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5168 that seems false... Anyone know which version (of Edge) it was added? |
| 14:30 | <smaug> | var l = document.createElement("label"); l.innerHTML = "<input>"; l.firstChild.labels.length |
| 14:30 | <smaug> | why would that be 0? |
| 14:32 | <annevk> | smaug: sounds like a bug |
| 14:35 | <smaug> | that is what I think too |
| 14:36 | <nox> | What kind of music would the band "Pseudo-classing Pseudo-elements" play? |
| 14:37 | <annevk> | Ambient |
| 14:48 | <nox> | annevk++ |
| 16:15 | <jyasskin> | hsivonen: Markus works for Google, so if a direct line would help, I can help set one up. |
| 16:23 | <jyasskin> | hsivonen: Your message didn't really make clear to me what operation the new spec would make difficult. Is it ingesting external "claimed-UTF-8" into internal "definitely-UTF-8"? Markus's team has written that operation, so he'll have some context for it. |
| 17:18 | <annevk> | jyasskin: yes, when you need to U+FFFD input |
| 18:21 | <hsivonen> | jyasskin: the proposed spec change requires not just an UTF-8 validation state machine but also the states for skipping over the original UTF-8 forms that were made illegal for UTF-16 compat |
| 18:22 | <hsivonen> | jyasskin: so it requires a larger state machine and the rationale is really flimsy: "feels right" in the context of an UTF-16-oriented implementation |
| 18:23 | <hsivonen> | jyasskin: currently, you only need the validation state machine states, since you fall out of the state machine to output U+FFFD as soon as invalidity is detected |
| 18:28 | <jyasskin> | hsivonen: Mhmm. FWIW, even ignoring UTF-16, transforming up to 6 bytes of data matching the "n 1's followed by n-1 bytes" form into a single U+FFFD seems reasonable. But if it makes the optimal UTF-8 validator larger, that seems like a good argument against it. |
| 18:30 | <jyasskin> | It's the sort of thing that might convince Markus, especially if you have code size or speed measurements to explain the impact. |
| 18:36 | <hsivonen> | jyasskin: I think the current spec text is technically better due to the state machine size issue, but procedurally, I think a proposal to change something like this should be argued way better than "feels right" |
| 18:37 | <jugglinmike> | JakeA: I've been trying to verify the validity of a service workers test in WPT. I could use your help, though. Would you mind weighing in on https://codereview.chromium.org/2873373004/ ? |
| 18:39 | <jyasskin> | hsivonen: The choice of how many U+FFFDs to include initially seemed like a matter of taste to me, in which case "feels right" is perhaps the only way to decide. However, you've introduced a technical reason that one of the options is easier to implement, which starts meaning the technical reason should win. |
| 18:57 | <JakeA> | jugglinmike: looking into it now… |
| 19:06 | <JakeA> | jugglinmike: I agree with your analysis. That condition shouldn't happen. I'm not sure why the test is broken down into wait_for_install and wait_for_activate – isn't wait_for_activate enough? |
| 19:09 | <jugglinmike> | JakeA: Seems that way |
| 19:11 | <jugglinmike> | JakeA: I was going to say that, from the perspective of the person who thought these extra conditions were necessary, the split would also be necessary |
| 19:12 | <jugglinmike> | but knowing the history of the test (specifically the commit that Matt found https://hg.mozilla.org/mozilla-central/rev/1ea2ebce35fe ), this was originally written in such a way as to not need that |
| 19:12 | <jugglinmike> | I'm glad to get your confirmation here. I've spent the better part of today going back and forth between the spec, the test, and your post https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/ |
| 19:44 | <annevk> | jyasskin: maybe initially a matter of taste, but a decade in it should not be a matter of taste to change it |
| 19:45 | <jyasskin> | annevk: Fair enough. |
| 19:52 | <jugglinmike> | JakeA: Would you mind taking a look at another one? https://codereview.chromium.org/2880823002/diff/1/third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/ready.https.html#newcode61 |
| 20:03 | <JakeA> | jugglinmike: glad the event loop post was useful. Looking at that other issue now… |
| 20:05 | <JakeA> | jugglinmike: is it specifically line 61+ that you're wanting me to look at, or the test as a whole? |
| 20:09 | <jugglinmike> | JakeA: actually, it's falken's request and my response to his request |
| 20:09 | <JakeA> | Ahh the equality thing. Gotcha |
| 22:26 | <tobie> | What does setting [SecureContext] on a partial interface actually do? |
| 22:26 | <tobie> | See https://github.com/heycam/webidl/issues/119 |
| 22:31 | <Domenic> | tobie: not really sure, but maybe nothing, since the main interface already has it... |
| 22:31 | <tobie> | Domenic: seems like we should disallow them altogether, if that's the case. |
| 22:33 | <Domenic> | Well, or that issue is suggesting mandating them, but yeah.... |
| 22:33 | <tobie> | Well, the mandate is decorative. |
| 22:34 | <tobie> | you can't have a constructor on a partial interface. You shouldn't have [SC] either. |
| 22:36 | <jyasskin> | tobie: Is it a shorthand for putting [SecureContext] on all the bits added by that partial part of the interface? |
| 22:37 | <tobie> | jyasskin: I don't think so. But I might be wrong. |
| 22:37 | <tobie> | jyasskin: I'm having a hard time parsing sentences like "The interface or namespace is not available only in secure contexts." tbh |
| 22:38 | <jyasskin> | I interpret "The interface member is available only in secure contexts if and only if the interface or partial interface the member is declared on is." to say that methods within a [SecureContext] partial interface are themselves [SecureContext]. |
| 22:38 | <jyasskin> | I wouldn't object to saying that you should just say [SecureContext] on all the members you intend it for. |
| 22:41 | <jyasskin> | tobie: I think [SecureContext] on a partial interface does nothing to the actual interface object, since https://heycam.github.io/webidl/#dfn-exposed doesn't care whether *partial* interfaces are available only in secure contexts. |
| 22:42 | <jyasskin> | s/wouldn't object to/would support/ |
| 22:42 | <tobie> | jyasskin: so [SecureContext] on a partial interface whose's non partial interface doesn't have [SecureContext] is shorthand for marking each members of that partial interface with [SecureContext]? |
| 22:43 | <jyasskin> | That's how I read the current wording, yes. |
| 22:44 | <tobie> | Whereas [SecureContext] on a non partial interface makes the whole interface unavailable, not just its members right? |
| 22:44 | <jyasskin> | Right. |
| 22:45 | <tobie> | I think it would be a lot simpler to spec, and a lot clearer to read and understand if that was simplified. |
| 22:46 | <jyasskin> | I agree. :) |
| 22:57 | <jyasskin> | tobie: Oh great, you're citing me as if I actually know things instead of just guessing them based on some words in a spec. ;-) |
| 23:01 | <tobie> | jyasskin: As far as I'm concerned, anybody willing to comment here understands this better than I do at present. :D |
| 23:18 | <tobie> | So predictably bz has a point |
| 23:25 | <Domenic> | tobie: I don't understand the question about 'How would you handle the "on |O| if |O| is not null" part keeping it in WebIDL, though?' |
| 23:25 | <Domenic> | Why not just put "on |O| if |O| is not null" into those steps? |
| 23:26 | <Domenic> | Like you did? |
| 23:26 | <tobie> | I guess it's the "on" part that bothers me. |
| 23:27 | <Domenic> | Hmm, seems fine to me... |
| 23:30 | <tobie> | Domenic: OK, I was thinking about putting that right after the ¶ were https://heycam.github.io/webidl/#dfn-regular-attribute is defined. |
| 23:32 | <Domenic> | tobie: seems good. I edited my most recent comment as I realized I forgot the "O" bits. |
| 23:32 | <tobie> | I was about to ask. :) |
| 23:33 | <tobie> | Alright I'll fix that tomorrow |
| 23:33 | <tobie> | ty |