| 02:19 | <domfarolino> | Domenic: briefly revisiting last night's conversation...since scripts "optionally" have a muted errors field (https://html.spec.whatwg.org/#muted-errors), does that mean that there really is no interop bug after all, because it isn't a "requirement" for browsers to mute errors from x-o scripts? |
| 03:22 | <annevk> | domfarolino: it is a req |
| 03:23 | <annevk> | domfarolino: I think that just means it is not always set, could be clearer |
| 03:31 | <domfarolino> | Ok I see thanks annevk |
| 03:35 | <domfarolino> | Would you consider a PR that either moves the word "optionally" down to the description as opposed to the title, or removes it altogether? |
| 03:36 | <domfarolino> | I'm wondering if "A flag which, if set, means" covers the "optionally" aspect of setting that flag, while preserving its requirement of existing nevertheless |
| 07:08 | <ondras> | hm |
| 07:08 | <ondras> | https://jsfiddle.net/3vx88jtj/1/ |
| 07:08 | <ondras> | is this behavior standardized somewhere? |
| 07:08 | <ondras> | i.e. how canvas font sizes <1 are supposed to work with transforms? |
| 07:12 | <annevk> | domfarolino: yeah, a rewrite to a flag of sorts would make sense |
| 07:13 | <annevk> | domfarolino: sorry for the late reply, missed your follow-up |
| 07:14 | <TabAtkins> | ondras: Browsers are, in general, allowed to apply a minimum font size. See https://jsfiddle.net/3vx88jtj/2/ |
| 07:15 | <TabAtkins> | (Mine applies a min of 12px.) |
| 07:16 | <ondras> | TabAtkins: based on my current experience (ff, chrome), the behavior is weird and inconsistent. |
| 07:17 | <ondras> | for instance, the resulting height is ~always the same, ff+chrome |
| 07:17 | <ondras> | for the whole input range of your fiddle |
| 07:17 | <ondras> | but the letter spacing jumps rapidly |
| 07:18 | <ondras> | and chrome fixes the ctx.font value on a minimum of "2px" for the rightmost 1/3 of the slider |
| 07:18 | <ondras> | while still maintaining the proper size of the rendered result |
| 07:19 | <ondras> | => chrome's .font getter returns different values than those that are actually applied |
| 07:19 | <ondras> | anyway, apparently rendering text to a (highly) scaled canvas seems to be a large amount of pain |
| 07:20 | <ondras> | damn. |
| 07:20 | <TabAtkins> | Ah, you might not have a meaningful min; mine blows up pretty quickly as soon as you start moving the slider to the right. |
| 07:21 | <ondras> | my height is constant, the width/letterspacing jumps in an unusable fashion |
| 07:21 | <TabAtkins> | Yeah, font renderers don't really work on arbitrary floats; they all round to various precisions at various spots. |
| 07:21 | <ondras> | okay |
| 07:22 | <ondras> | sounds like I will have to cancel the transform for font rendering and compute it myself |
| 07:33 | <yoav> | annevk: when defining a method, is there an equivalent to ASSERT_UNREACHED()? Should I throw in cases that should not happen? (e.g. because callers should collapse potential-destination values to known values before they call the translation method) |
| 07:43 | <annevk> | yoav: see Infra, you can use Assert: |
| 07:48 | <yoav> | cool, thx! |
| 07:49 | <yoav> | so something like "Assert: this should never be reached."? |
| 07:55 | <annevk> | yoav: prolly better to assert before the branch |
| 07:55 | <yoav> | ok, makes sense |
| 07:55 | <TabAtkins> | Yeah, assert your preconditions. Failling the assert is a spec error, not a runtime error. |
| 07:55 | <annevk> | yoav: Assert: destination is not fetch or some such |
| 07:56 | <TabAtkins> | If it's a runtime error, then you do indeed need to throw; asserts might be useful afterwards to remind the spec reader what values are left over. |
| 08:01 | <annevk> | Asserts won't "run" after throw; throw terminates |
| 08:07 | <TabAtkins> | Right, I mean like "1. If |x| is a weird value, throw a TypeError. 2. Assert: |x| is a FooEnum value. 3. More stuff..." |
| 08:09 | <annevk> | Ah |
| 08:12 | <yoav> | annevk: https://github.com/whatwg/fetch/pull/547 |
| 08:12 | <MikeSmith> | annevk: so getting back to HTML checking for the Encoding files, we want to run the checker if any .text files change or if the visualize.py file changes? |
| 08:13 | <yoav> | It's getting bikeshed errors regarding the linking of "preload destination". I'm not sure if it real errors or a bikeshed issue related to having a space as part of the linked term (there are other errors with space in them) |
| 08:15 | <TabAtkins> | There's definitely nothign wrong with ahving spaces in a term. |
| 08:15 | <annevk> | MikeSmith: .bs or visualize.py I suppose |
| 08:16 | <TabAtkins> | yoav: That said, I don't see "preload destination" in the ref database. |
| 08:16 | <annevk> | MikeSmith: hmm yeah, also addition of txt I guess |
| 08:17 | <MikeSmith> | or changes to the .txt files? I notice a recent commit that makes changes to them |
| 08:17 | <yoav> | TabAtkins: that's probably because I just made it up and didn't know I should also add it to a ref database :) |
| 08:17 | <yoav> | also s/preload destination/potential destination/ |
| 08:17 | <TabAtkins> | Oh! Jeez, no wonder I was confused when reading the PR. ^_^ |
| 08:18 | <annevk> | yoav: I can review later today, but I'd have the steps in opposite order; early return for fetch, then assert it's a destination, then return input |
| 08:18 | <yoav> | annevk: OK, I'll reverse them |
| 08:18 | <TabAtkins> | In the PR, you'll get a linking error because you're not defining a "potential destination" term; you're defining "potential-destination". |
| 08:18 | <annevk> | MikeSmith: yeah I suppose |
| 08:18 | <yoav> | TabAtkins: doh! |
| 08:19 | <yoav> | TabAtkins: Still getting the error after deleting the "-" |
| 08:20 | <TabAtkins> | ...and replacing it with a space? |
| 08:20 | <yoav> | yeah |
| 08:21 | <TabAtkins> | Push the change; you shouldn't be having any trouble. |
| 08:21 | <annevk> | yoav: I don't think it's worth having a dfn for that |
| 08:22 | <annevk> | yoav: if you wanted to define such a term you'd define it as a superset of destination |
| 08:22 | <yoav> | annevk: OK, I'll remove it then |
| 08:23 | <TabAtkins> | Can replace it with just a |var| if you want the styling. |
| 08:23 | <yoav> | annevk: but we do need HTML to link to it later on. Can we do that without a dfn? |
| 08:24 | <TabAtkins> | No. |
| 08:25 | <yoav> | TabAtkins: pushed the change in the mean time. I still see the error (but I'm sure I'm holding it wrong :D) |
| 08:31 | <TabAtkins> | I'm extremely confused by what's going on here. |
| 08:32 | <yoav> | TabAtkins: confused by my patch, or by the error? |
| 08:34 | <annevk> | yoav: then you need to define it as a distinct type |
| 08:34 | <TabAtkins> | The error. |
| 08:35 | <TabAtkins> | I'll check more on this before bed, in heading to dinner now. |
| 08:37 | <yoav> | TabAtkins: Thanks :) |
| 08:37 | <yoav> | annevk: pointers to an example of defining as a distinct type? |
| 08:40 | <annevk> | yoav: see eg dfn of method |
| 08:40 | <annevk> | yoav: X is "fetch" or a destination |
| 08:41 | <annevk> | yoav: on mobile due to sick kid btw |
| 08:41 | <annevk> | Hence poor latency |
| 08:43 | <yoav> | annevk: looking, and no worries RE latency. I know what it's like |
| 08:49 | <yoav> | TabAtkins: Split out the definition. Now I'm longer seeing the error |
| 08:50 | <yoav> | annevk: uploaded. Let me know what you think (when you have time) |
| 09:03 | <TabAtkins> | Oh shoot, I realize what's up with the error now. |
| 09:04 | <TabAtkins> | Looks like I don't special-case for=/ on a dfn to mean "no for value". So it was registering it with a for of /, which you can't actually specify on a link. |
| 09:06 | <TabAtkins> | When you split out the definition, you also just removed the for attribute from the dfn, which resolved the issue. |
| 09:06 | <TabAtkins> | This is a Bikeshed bug, tho. |
| 09:17 | <yoav> | TabAtkins: OK, cool. Happy to find bikeshed bugs by doing things you normally wouldn't :D |
| 10:00 | <jochen__> | does the fetch spec say something about what should happen when the promise returned by fetch is resolved, but there is no scheduled work on the event loop (and so technically, we don't enter a microtask checkpoint)? |
| 10:01 | <annevk> | jochen__: HTML would say something about that, but that can't really happen, since fetch resolves the promise from a task |
| 10:35 | <annevk> | jochen__: in fact, promises never resolve without a task being involved |
| 10:54 | <jochen__> | ah, found it |
| 14:32 | <tobie> | TabAtkins: while you're around and fixing BS bugs… |
| 14:33 | <tobie> | TabAtkins: I'm having an issue where BS seems to rewrite an inline SVG |
| 14:33 | <tobie> | TabAtkins: removing the namespace in the process, which then gets rejected by echidna's HTML validator. |
| 14:35 | <MikeSmith> | if that is about the xlink:href vs href I fixed that in the HTML checker at the end of last week |
| 14:35 | <MikeSmith> | if it’s about some other error I can fix that too |
| 14:36 | <tobie> | MikeSmith: how do you know this? |
| 14:36 | <MikeSmith> | assuming it’s another case where the SVG changed the doc-confoormaces requirements in SVG2 |
| 14:37 | <tobie> | MikeSmith: I have no idea. This thing displays is the limit of my understanding of namespaces in SVG |
| 14:37 | <tobie> | MikeSmith: can I point you to the error, BS source and output? |
| 14:37 | <MikeSmith> | well as far as SVG checking I can make the checker do whatever creates the least problems for people trying to get real work done |
| 14:37 | <MikeSmith> | tobie: sure |
| 14:37 | <tobie> | MikeSmith: source: https://github.com/w3c/sensors/blob/9335c1fa027fe309a3fd13b98914b7d479968252/index.bs#L735-L800 |
| 14:38 | <MikeSmith> | no version of the SVG spec has ever clearly stated actual doc-conformance requirements consistently anyway |
| 14:38 | MikeSmith | looks |
| 14:38 | <tobie> | MikeSmith: echidna error: https://labs.w3.org/echidna/api/status?id=916cf371-4630-491c-abd6-c663b65e6bbd |
| 14:39 | MikeSmith | looks again |
| 14:39 | <tobie> | MikeSmith: validator error: https://validator.w3.org/nu/?doc=http://owl.w3.org//916cf371-4630-491c-abd6-c663b65e6bbd/Overview.html |
| 14:40 | <tobie> | MikeSmith: Bikeshed output of SVG: https://gist.github.com/tobie/d4a0e43cc7781fec2daa933674d099f5 |
| 14:40 | <MikeSmith> | ah I think that is a bikeshed bug |
| 14:41 | <MikeSmith> | <svg height="79pt" viewBox="0.00 0.00 351.00 78.51" width="351pt" xlink="http://www.w3.org/1999/xlink"; xmlns="http://www.w3.org/2000/svg">; |
| 14:41 | <tobie> | Yup: the namespaces are all gone |
| 14:41 | <MikeSmith> | I guess that should be xmlns:xlink="http://www.w3.org/1999/xlink"; |
| 14:42 | <MikeSmith> | so yeah I can' |
| 14:42 | <MikeSmith> | *I can’t really fix that in the checker |
| 14:42 | <MikeSmith> | because there is no “xlink” attribute defined anywhere |
| 14:44 | <tobie> | Filing an issue against BS. Thanks for the help! |
| 14:45 | <MikeSmith> | cheers |
| 14:53 | <tobie> | TabAtkins/MikeSmith: for reference: https://github.com/tabatkins/bikeshed/issues/1029 |
| 15:19 | <tobie> | @jyasskin, @mounir, others: what are your thoughts on using "user triggered activation" as "information about the user’s intent" to determine whether to prompt or grant permission? |
| 15:33 | <tobie> | Maybe @annevk also ^ |
| 15:35 | <tobie> | Here's the PR on this topic: https://github.com/w3c/sensors/pull/207 |
| 15:48 | <annevk> | tobie: what other information do you have? |
| 15:57 | <tobie> | annevk: that's a good question. |
| 16:04 | <jyasskin> | tobie: It's very easy to trick a user into providing activation, so it's not a reliable way to infer intent. I like demanding it for permission prompts because it helps avoid a popup-by-surprise and possibly clickjacking, but even that's gotten objections for the case where the entire point of a URL is to use a certain permission. |
| 16:06 | <jyasskin> | tobie: I'm having trouble following the English in that PR. Is it just saying that some readings are only very slightly sensitive, so we don't need actual user consent to give them out, just evidence that the user has noticed the page? |
| 16:08 | <jyasskin> | Ojan has been looking at some of that sort of feature for interventions. e.g. https://groups.google.com/a/chromium.org/d/topic/blink-dev/MRWIaGY4Txg/discussion for beforeunload and https://groups.google.com/a/chromium.org/d/topic/blink-dev/51WbTwn0M_Y/discussion for autoplaying audio |
| 16:24 | <annevk> | jyasskin: I think the objection was more involved than that |
| 16:25 | <annevk> | jyasskin: the objection was that if you don't persist the permission, the UX becomes really bad if the permission prompt effectively requires two interactions |
| 16:25 | <annevk> | jyasskin: so by requiring user interaction, you effectively require persisting the permission |
| 16:25 | <jyasskin> | annevk: Was there an example of that badness for pages that weren't requesting on load? |
| 16:27 | <jyasskin> | e.g. it's probably a good thing to make foonews.com wait to ask for your location until after you've interacted. |
| 16:27 | <tobie> | jyasskin: so the sensitiveness of the readings is highly debatable AND depends on the kind of sensors |
| 16:27 | <annevk> | jyasskin: not sure, I wasn't too closely involved |
| 16:29 | <jyasskin> | tobie: I think it'd be totally reasonable for some sensors to decide that they lie in that intermediate-sensitivity region, but I'm uncomfortable saying that the activation conveys user intent. |
| 16:29 | <jyasskin> | Or, I suppose, uncomfortable saying that it conveys intent to grant that particular sensor. It's intent to interact with the page. |
| 16:30 | <jyasskin> | tobie: I'll comment. |
| 16:30 | <tobie> | jyasskin: thank you |
| 16:31 | <tobie> | annevk: to answer your previous question, I don't think we have much info to determine user intent. |
| 16:32 | <tobie> | annevk: I'm especially concerned about malicious use of motion sensors on drive-by sites. |
| 16:34 | <annevk> | tobie: you might have noticed that we're removing these sensors from Fx |
| 16:34 | <tobie> | annevk, jyasskin: I would considered tying sensor access to PWA installed status or similar. The use cases really involve app status, not drive-by websites. |
| 16:34 | <annevk> | tobie: it's unclear if we'll add them back at this point, given that asking the user about them seems like a hard problem |
| 16:34 | <tobie> | annevk: the ambient light stuff. |
| 16:35 | <tobie> | annevk: but are you going to remove also the motion sensors? |
| 16:35 | <jyasskin> | tobie: Installation definitely indicates user intent. |
| 16:35 | <annevk> | I don't know |
| 16:35 | <tobie> | jyasskin: I agree. |
| 16:35 | <tobie> | annevk: they have similar issues but much more interesting use cases (indoor navigation, gaming, WebVR, etc.) |
| 16:35 | <annevk> | I'm not a big fan of the whole PWA thing, it's not very webby |
| 16:36 | <tobie> | annevk: well, it's much more webby than any of the previous iteration we've seen. |
| 16:43 | <MikeSmith> | annevk: when you have time please check https://stackoverflow.com/questions/44121783/fetch-api-default-cross-origin-behavior/44125919#44125919 and comment/correct/answer |
| 16:44 | <tobie> | jyasskin: filed https://github.com/w3c/sensors/issues/211 |
| 16:54 | <jyasskin> | annevk: FWIW, an installed PWA is a bookmark with better UI. We couldn't infer intent from bookmarks because users tended to accumulate them indefinitely, but we think there's some pressure to "uninstall" PWAs that you're not using, since they clutter your launch screen, so we're more willing to infer intent from them. |