| 04:38 | <Sebmaster> | annevk: you there? |
| 05:05 | <annevk> | Sebmaster: waking up |
| 05:05 | <annevk> | Sebmaster: what's up? |
| 05:05 | <Sebmaster> | annevk: created an issue on whatwg/url |
| 05:06 | <Sebmaster> | not that important/time-critical |
| 05:07 | <annevk> | Sebmaster: I think you found a bug |
| 05:07 | <Sebmaster> | sweet |
| 05:07 | <annevk> | Sebmaster: should probably flush out step 5 to use the appropriate set |
| 05:07 | <annevk> | 1.3.5 that is |
| 05:07 | <Sebmaster> | currently reporting the bug to unicode too |
| 05:08 | <annevk> | ooh wait |
| 05:08 | <annevk> | actually that might not be a bug |
| 05:08 | <Sebmaster> | aww |
| 05:08 | <annevk> | since all the code points that password/username add are treated specially in authority state |
| 05:09 | <Sebmaster> | what's that? |
| 05:10 | <annevk> | Sebmaster: https://url.spec.whatwg.org/#default-encode-set if you look at the password and username encode set |
| 05:10 | <annevk> | Sebmaster: "/", "@", "\", and ":" all have special meaning within the authority state so could never end up there |
| 05:11 | <annevk> | Sebmaster: I guess we might still want to add a note of sorts there to that effect |
| 05:11 | <Sebmaster> | oooh, i think i found my error :/ |
| 05:11 | <Sebmaster> | sorry for bothering |
| 05:14 | <Sebmaster> | yeah, i got it... i simple encoded it |
| 05:26 | <annevk> | no worries |
| 07:09 | <tobie> | Anyone knows why DOMHighResTimeStamp is relative? |
| 07:13 | <tobie> | relative to performance.timing.navigationStart, I mean. |
| 07:15 | <tobie> | Is that due to some limitation as to how numbers can be represented in JS or is it just a weird choice? |
| 07:19 | <ondras> | Date.now() * 1000 |
| 07:19 | <ondras> | 1434007172260000 |
| 07:19 | <ondras> | Number.MAX_SAFE_INTEGER |
| 07:19 | <ondras> | 9007199254740991 |
| 07:20 | <ondras> | not sure. |
| 07:25 | <annevk> | tobie: all time is relative :p |
| 07:26 | <tobie> | go away, annevk |
| 07:26 | <annevk> | tobie: but yeah, we don't have large enough numbers to get that kind of precision since epoch |
| 07:27 | <tobie> | new Date(Math.floor(Number.MAX_SAFE_INTEGER/1000)) |
| 07:27 | <tobie> | Wed Jun 06 2255 01:47:34 GMT+0200 (CEST) |
| 07:31 | <annevk> | That roughly matches the 272 years at microsecond resolution from https://github.com/WebAudio/web-midi-api/issues/145#issuecomment-110477683 |
| 07:31 | <annevk> | DOMHighResTimeStamp is more precise |
| 07:31 | <tobie> | I have no idea what I'm doing but that seems future proof for more than 2 centuries, no? |
| 07:32 | <annevk> | Not if you want higher resolution... |
| 07:32 | <ondras> | "accurate to the thousandth of millisecond" |
| 07:32 | <tobie> | http://www.w3.org/TR/hr-time/#sec-DOMHighResTimeStamp |
| 07:33 | <ondras> | I do not see why JS ints are not suffucient for the required microsecond precision |
| 07:34 | <tobie> | annevk: oh, you're actually looking at that right now? |
| 07:35 | <tobie> | annevk: I was looking at something similar for the sensor stuff |
| 07:36 | <annevk> | tobie: well, it's been going on for at least a year now |
| 07:37 | <annevk> | tobie: but yeah, the plan is to change events to report DOMHighResTimeStamp instead |
| 07:37 | <tobie> | From navigation start? or from epoch? |
| 07:37 | <annevk> | Can't from epoch, so navigation start |
| 07:37 | <annevk> | See comments in that issue from Brian |
| 07:38 | <annevk> | Oh, @birtles |
| 07:38 | <birtles> | yeah, I need to get on and finish making that change in Gecko |
| 07:39 | <annevk> | Yes! |
| 07:39 | <tobie> | I don't understand half of the concerns birtles brought up, tbh. |
| 07:40 | <birtles> | tobie: which ones? |
| 07:40 | <tobie> | And I mean that literally, I'm not contesting them. |
| 07:40 | <tobie> | :) |
| 07:40 | <birtles> | the monotonically increasing thing? |
| 07:40 | <tobie> | "I don't think you can have interop with Date if you want these values to be monotonically increasing" |
| 07:41 | <tobie> | yeah, I don't understand how that could be an issue. |
| 07:41 | <ondras> | annevk: I am still unsure why microseconds from the unix epoch are not suitable for JS numbers |
| 07:41 | <annevk> | ondras: presumably the high resolution platform APIs don't give answers since epoch |
| 07:42 | <ondras> | well |
| 07:42 | <ondras> | 09:26 < annevk> tobie: but yeah, we don't have large enough numbers to get that kind of precision since epoch |
| 07:42 | <ondras> | so I am not sure whether this is about the required precision |
| 07:42 | <annevk> | ondras: well, people want nanoseconds I think |
| 07:42 | <ondras> | ah |
| 07:42 | <tobie> | annevk: where's *that* requirement? |
| 07:43 | <ondras> | so it is possible to increase the precision backwards-compatibly by using floats |
| 07:43 | <ondras> | the number is still millis |
| 07:43 | <annevk> | tobie: isn't that why we have performance.now()? |
| 07:43 | <ondras> | but the precision increases to nanos |
| 07:43 | <ondras> | interesting |
| 07:43 | <tobie> | annevk: it microseconds, per spec |
| 07:44 | <birtles> | tobie: as I understand it Date.now() is not monotonically increasing, so when your computer's clock goes backwards due to DST or time adjustments etc. Date.now() also goes backwards |
| 07:44 | <birtles> | tobie: so if you want event timestamps to line up with Date.now() values, then those times can go backwards now |
| 07:44 | <birtles> | so if you're comparing the timestamps between events to see which one came first, you'll occasionally get wacky bugs |
| 07:44 | <birtles> | performance.now() doesn't have the problem |
| 07:45 | <tobie> | oh, all of this is because of the bloody daylight saving time? |
| 07:45 | <birtles> | nah, there are other system time adjustments |
| 07:45 | <birtles> | like sync with time servers etc. |
| 07:45 | <annevk> | timezones |
| 07:46 | <tobie> | annevk: isn't Date.now() UTC? |
| 07:47 | <tobie> | birtles: but couldn't you still have something monotonic yet fully compatible? |
| 07:48 | <birtles> | tobie: I thought about that, but then I think you get even weirder bugs |
| 07:48 | <birtles> | e.g. store the time internally using some monotonically increasing value and convert it on access |
| 07:48 | <birtles> | but then if time changes between subsequent accesses you get even weirder bugs |
| 07:49 | <tobie> | I'm not sure I get that. |
| 07:49 | <tobie> | what do you mean by "on access" |
| 07:50 | <tobie> | and "store the time internally"? |
| 07:50 | <birtles> | basically, making Event.timeStamp live |
| 07:51 | <tobie> | oh, that's not what I meant. |
| 07:51 | <birtles> | ok, maybe I didn't get what you meant by fully compatible |
| 07:51 | <tobie> | no wonder, that was kind of hand-wavy |
| 07:51 | <tobie> | :) |
| 07:51 | <tobie> | let me try to explain better |
| 07:53 | <tobie> | right now DOMHighResTimeStamp is monotonic but starts at performance.timing.navigationStart |
| 07:54 | <tobie> | so to turn something into a date you kind of have to do (pseudo code): new Date(DOMHighResTimeStamp + performance.timing.navigationStart) |
| 07:56 | <tobie> | what if instead you had DOMHighResTimeStamp start at epoch but be monotonic from the moment the page loads? |
| 07:58 | <tobie> | birtles: is that just a different flavor of hand-wavy or am I making more sense? |
| 07:58 | <birtles> | tobie: in other words, store the time since navigationStart but at the API level, do the addition you described above automatically? |
| 07:58 | <tobie> | yes |
| 07:58 | <birtles> | I think there are two issues... |
| 07:59 | <tobie> | only? |
| 07:59 | <birtles> | :) |
| 07:59 | <birtles> | one is that then you lose compatibility with Date |
| 07:59 | <birtles> | since the values you're reporting no longer correspond to the values it returns |
| 07:59 | <tobie> | how so? |
| 07:59 | <tobie> | why would that be? |
| 08:00 | <birtles> | if you update your system clock backwards 1 minute, Date.now() goes backwards 1 minute |
| 08:00 | <birtles> | if you want to report a timestamp as a monotonically increasing value though it can't go backwards relative to any other timestamps |
| 08:00 | <tobie> | sure, but Date.preciselynow() wouldn't |
| 08:00 | <birtles> | so it can't go backwards |
| 08:00 | <birtles> | so you can't meaningfully compare those timestamps with Date.now() anymore |
| 08:01 | <tobie> | Right |
| 08:01 | <birtles> | so then the second issue is you lose compatibility with everything that's based on navigationStart: performance.now(), requestAnimationFrame, Web Animations etc. |
| 08:02 | <birtles> | it seems like you lose compatibility with everything except some yet-to-be-created Date function? |
| 08:03 | <tobie> | well, unless you'd have to change performance.timing.navigationStart to always return 0 |
| 08:03 | <tobie> | :D |
| 08:03 | <tobie> | s/'d have to// |
| 08:04 | <birtles> | yeah, that might work :) pretty sure no one would notice :) |
| 08:05 | <tobie> | I'm not sure if you're being 1) ironic, 2) not ironic, or 3) unsure yourself whether to be ironic or not ironic |
| 08:07 | <birtles> | sorry, yeah, I don't think we'd get away with that and I'm not entirely sure it would be useful either |
| 08:08 | <birtles> | I think the fundamental problem is that Date.now() is not monotonically increasing (I just checked on this computer to be sure) |
| 08:09 | <tobie> | I guess you're right and the only thing I'm after is: Date.fromPrecisionTiming() and Date.preciseNow = performance.now or something similar |
| 08:10 | <birtles> | yeah, I can see that being useful |
| 08:11 | <tobie> | That should belong in ES, tbh |
| 08:12 | <tobie> | and so you'd also need a Date.contextStarted or some such |
| 08:12 | <birtles> | yeah, I think we're still speccing workerStart at the moment |
| 08:12 | <tobie> | equivalent of current performance.timing.navigationStart but not platform specific |
| 08:13 | <tobie> | well, seems its at the wrong layer, no? |
| 08:13 | <tobie> | How do I get that in node? |
| 08:14 | <tobie> | new Date(timestamp + (performance.timing.navigationStart || this.workerStart || process.startTime)) |
| 08:14 | <tobie> | or rather: |
| 08:15 | <tobie> | new Date(timestamp + ((performance && performance.timing && performance.timing.navigationStart) || this.workerStart || (process && process.startTime))) |
| 08:15 | <tobie> | <3 |
| 08:26 | <tobie> | birtles: here, I solved all the things for you: https://twitter.com/tobie/status/608912362813464576 |
| 08:27 | <birtles> | tobie: cheers, our work here is done |
| 08:48 | <annevk> | ECMAScript*, by Ecma |
| 08:48 | <tobie> | oh--is it? |
| 08:49 | <tobie> | Well, Ecma International, more precisely. |
| 08:52 | <annevk> | It used to be ECMA, but then they were no longer European and decided to turn the abbreviation into a name |
| 08:54 | <tobie> | Yup. Wasn't aware ECMA had stuck in ECMAScript though. |
| 08:56 | <annevk> | Well, given ES6 vs ECMAScript 2015 they always seem to go for maximum developer confusion |
| 09:10 | <espadrine> | that's not really on them, though—isn't that a decision made by TC39? |
| 09:12 | <annevk> | TC39 is basically Ecma at this point |
| 09:12 | <annevk> | Not much else to hold it alive |
| 09:12 | <annevk> | I guess there's TC52 for Dart, but euh... |
| 09:13 | <espadrine> | and that thing to pretend that docx is standardized |
| 09:14 | <espadrine> | TC45 |
| 09:16 | <MikeSmith> | http://www.ecma.org/about-ecma/organisational-structure/ecma-tobacco-forum.html |
| 09:17 | <ondras> | :} |
| 09:18 | <ondras> | nothing beats a good old tobacco packaging |
| 09:20 | <tobie> | MikeSmith: is that the same Ecma? |
| 09:21 | <MikeSmith> | qyep |
| 09:21 | <tobie> | I know they do a lot of other non-open, non-RF standards, but this stuff? |
| 09:22 | <annevk> | Pretty sure that is not the same |
| 09:22 | <annevk> | "ECMA – European Carton Makers Associations" |
| 09:22 | <tobie> | not the same ecma |
| 09:22 | <tobie> | they have the nice domain name though |
| 09:24 | <tobie> | kind of worrying that a carton maker association snapped the domain name of the SDO defining the language used by the platform, but oh well. |
| 09:27 | <darobin> | my bad, I'm the one who confused ecma.org and ecma-international |
| 09:28 | <darobin> | the official site for the latter redirects to their hosting provider... |
| 09:37 | <tobie> | darobin: afaik they're in the process of fixing it. |
| 09:37 | <darobin> | why bother? |
| 09:37 | <tobie> | darobin: (has been reported yesterday evening) |
| 09:37 | <darobin> | forgot to pay the hosting fee? |
| 09:37 | <tobie> | darobin: hook for IP commitments |
| 09:37 | <darobin> | hmpf |
| 09:37 | <annevk> | hallvors: so bz was asking about fetch() tests |
| 09:38 | <annevk> | hallvors: I wonder how much we can reuse from XMLHttpRequest |
| 09:38 | <annevk> | hallvors: and maybe from odinho's CORS tests |
| 09:38 | <Ms2ger> | Not much, I suspect |
| 09:38 | <annevk> | At a high-level similar things are being tested, e.g. methods etc. |
| 09:39 | <MikeSmith> | I heard that the source for the text on all cigarette cartons OS maintained in MS Word files. Pretty sure darobin is the one who told me that. |
| 09:39 | <hallvors> | Hm.. |
| 09:39 | <hallvors> | annevk: just write a polyfill making XHR requests use window.fetch(), reuse everything :-p |
| 09:40 | <annevk> | And a bunch of the server infrastructure will be similar... |
| 09:40 | <annevk> | But maybe it's too much effort to make something generic? |
| 09:40 | <hallvors> | the serious reply is: not sure off the top of my head. Probably needs to be decided on a test-by-test basis |
| 09:41 | <hallvors> | (aka there's quite some work to do ) |
| 09:42 | <hallvors> | much of the backend stuff is rather trivial anyway, but of course nice to reuse |
| 09:43 | <darobin> | tobie: I just released your PR |
| 09:45 | <annevk> | hallvors: hmm, I'm not sure I want to be the one doing this |
| 09:46 | <Ms2ger> | I know I don't want to be it either :) |
| 09:47 | <annevk> | jgraham: something is wrong with the links: http://w3c-test.org/fetch |
| 09:48 | <annevk> | jgraham: that should probably redirect to /fetch/ since now nosniff points to http://w3c-test.org/nosniff/ which does not exist obviously |
| 09:50 | <hallvors> | well, there's this thing called test the web forward |
| 09:50 | <hallvors> | (which always seems like a gramatically dubious name, but then I'm not a native English speaker) |
| 09:51 | <annevk> | I'm not sure those really work well |
| 09:52 | <Ms2ger> | They don't |
| 09:52 | <annevk> | In the end writing good tests is similar to writing good specifications or writing good implementations. You need to have quite a bit of experience. |
| 10:00 | <jgraham> | annevk: What links? |
| 10:01 | <Ms2ger> | annevk, http://w3c-test.org/fetch/ works |
| 10:07 | <annevk> | Ms2ger: I know |
| 10:07 | <annevk> | jgraham: if you link to a directory without a trailing slash |
| 10:07 | <annevk> | jgraham: the links within the directory view |
| 10:14 | <jgraham> | annevk: Yeah, there intentionally isn't any special magic to make /foo and /foo/ the same |
| 10:29 | <karlcow> | I wonder why annevk is asking about /foo and /foo/ if foo is a directory. |
| 10:29 | karlcow | knows that the default of Apache httpd are a bit painful with regards to this. |
| 10:30 | <annevk> | karlcow: because I ended up at http://w3c-test.org/fetch and the link to nosniff is broken |
| 10:30 | <karlcow> | Specifically in this case: |
| 10:30 | <karlcow> | /foo/ |
| 10:30 | <karlcow> | /foo.html |
| 10:31 | <karlcow> | when you request /foo |
| 10:31 | <jgraham> | annevk: I think the bug there is that /fetch works at all |
| 10:31 | <jgraham> | It really isn't supposed to |
| 10:32 | <karlcow> | Server: BaseHTTP/0.3 Python/2.7.3 |
| 10:33 | <karlcow> | homemade server? |
| 10:33 | <Ms2ger> | Yup |
| 10:33 | <Ms2ger> | wptserve |
| 10:34 | <karlcow> | https://github.com/w3c/wptserve |
| 10:47 | <CrLF0710> | hi, i'm reading the HTML spec, now i'm at Chapter 14. what does the 'i' in "table[align=left i] { float: left }" mean? |
| 10:48 | <jgraham> | annevk: https://critic.hoppipolla.co.uk/r/5244 |
| 10:48 | <annevk> | CrLF0710: means ASCII case-insensitive matching |
| 10:48 | <annevk> | CrLF0710: on the value |
| 10:48 | <annevk> | CrLF0710: defined in Selectors |
| 10:49 | <Ms2ger> | jgraham, can't we redirect in that case rather than 404? |
| 10:49 | <CrLF0710> | annevk: got it. thank you! |
| 10:49 | <jgraham> | Ms2ger: I would much prefer not to |
| 10:50 | <annevk> | jgraham: you could first check if a directory of that name exists and then redirect? |
| 10:51 | <jgraham> | annevk: The directory is known to exist, but not doing too much magic seems strictly better |
| 10:54 | <annevk> | jgraham: I can't review that but looks okay |
| 11:04 | <jgraham> | annevk: You can review it now |
| 11:07 | <annevk> | r+ |
| 11:09 | <jgraham> | Thanks |
| 11:09 | <tobie> | darobin: ty |
| 11:09 | <tobie> | darobin: didn't know WebIDL had a ws option. |
| 11:10 | <tobie> | s/WebIDL/webidl2.js/ |
| 11:49 | <darobin> | tobie: yeah it does as of I think about a year ago, I forget |
| 11:49 | <darobin> | it's not like there's an announcement list or anything |
| 11:49 | <darobin> | I wrote it specifically for use cases like jyasskin_w's thing |
| 11:58 | <tobie> | darobin: darn, spent quite a while trying to figure out was was breaking |
| 12:01 | <darobin> | tobie: sorry about that :( |
| 12:01 | <darobin> | tobie: don't hesitate to ping me when you have trouble with that |
| 12:02 | <tobie> | It was midnight |
| 12:02 | <tobie> | You weren't around |
| 12:05 | <tobie> | darobin: tbh, the problem had more to do with getting stack traces deep within compressed JS |
| 12:05 | <darobin> | don't code at midnight |
| 12:05 | <darobin> | be in bed, read a book man |
| 12:05 | <darobin> | tobie: we could do sourcemaps if it helps |
| 12:06 | <tobie> | that was excpetional, tbh, I generally no longer do this. |
| 12:06 | <tobie> | nah, I think we should just migrate to browserify at some point and get all of this stuff for free. |
| 12:07 | <darobin> | ah, the problem was inside ReSpec |
| 12:07 | <darobin> | yeah, I should browserify it |
| 12:07 | <darobin> | webidl2.js could have a distributed .min though, it's a nicety |
| 12:07 | <tobie> | AMD was a bad id from the start |
| 12:08 | <tobie> | idea, even |
| 12:09 | <darobin> | yeah |
| 12:09 | <darobin> | I really had to fight RequireJS to get it to be useful for me |
| 12:10 | <darobin> | it's a bit of a nightmare |
| 12:10 | <darobin> | well, a kludge at least |
| 12:10 | <darobin> | it's probably not a huge port to just browserify the whole thing, I'd say a day's worth of work tops |
| 12:12 | <tobie> | famous last words |
| 12:15 | <darobin> | tobie: heh, nah, I really think it's not that much work |
| 12:21 | <annevk> | What should we call the flag that makes <img> and Beacon survive an environment settings object going down? |
| 12:21 | <annevk> | Any other APIs that do that? |
| 12:21 | <annevk> | "survive flag"? |
| 12:22 | <annevk> | "survive client termination flag"? |
| 12:22 | <darobin> | the gaynor flag |
| 12:23 | <annevk> | Don't get the reference :/ |
| 12:55 | <MikeSmith> | annevk: if you go with the longer one, it should be "survive client-termination flag" with a hyphen |
| 12:56 | <MikeSmith> | otherwise it sounds like it's a "termination flag" of some kind |
| 12:56 | <annevk> | Does that also go for "local URLs only flag"? |
| 12:56 | <annevk> | Or " same-origin data URL flag"? |
| 12:56 | <MikeSmith> | yes |
| 12:56 | <annevk> | "unsafe request flag"? |
| 12:56 | <MikeSmith> | yes |
| 12:56 | <annevk> | "CORS preflight flag"? |
| 12:57 | <MikeSmith> | yes there too |
| 12:57 | <MikeSmith> | hyphens all |
| 12:57 | <annevk> | So many hyphens |
| 12:57 | <MikeSmith> | well the alternative is ambiguity |
| 12:57 | <annevk> | same-origin-data-URL? |
| 12:57 | hsivonen | tries to refactor HTML parsing code for character references |
| 12:57 | <hsivonen> | test don't pass |
| 12:58 | <annevk> | "sandboxed storage area URLs flag"... |
| 12:58 | <hsivonen> | ¬it; looks like something that never works right on the first try after changing code |
| 12:58 | <MikeSmith> | annevk: "same-origin data-URL flag" I would think |
| 12:58 | <annevk> | MikeSmith: I might need some help with where the hyphens need to go |
| 12:59 | MikeSmith | looks for a style-guide reference |
| 12:59 | <Ms2ger> | hsivonen, yay for tests :) |
| 12:59 | <annevk> | I wish specifications had tests |
| 12:59 | <hsivonen> | haha. I forgot to write some code I marked TODO a moment ago |
| 12:59 | <annevk> | For over a month all responses lost URLs |
| 13:00 | <MikeSmith> | hsivonen: you working on refactoring it in order to deal with the ambiguous-ampersand stuff? |
| 13:00 | <annevk> | And nobody noticed but me :-( |
| 13:00 | <Ms2ger> | And you wrote a test that would have caught it? |
| 13:00 | <darobin> | annevk: sorry, Gloria Gaynor https://www.youtube.com/watch?v=ZBR2G-iI3-I |
| 13:00 | <MikeSmith> | hsivonen: btw are you waiting on me still for the patches parsing patches I pinged you for review? |
| 13:01 | Ms2ger | curses websockets |
| 13:03 | <hsivonen> | MikeSmith: this refactoring is not for the ambiguos ampersands, but this is a good opportunity for me to recap the code so that I could review the patch |
| 13:03 | <MikeSmith> | ok |
| 13:04 | <hsivonen> | MikeSmith: the goal of this refactoring is to stop OOM crashes on the release channel |
| 13:04 | <MikeSmith> | oh boy |
| 13:04 | <MikeSmith> | yeah that's a bit more important |
| 13:04 | <annevk> | MikeSmith: so CORS-preflight flag? |
| 13:05 | <annevk> | MikeSmith: what I don't understand is why "survive client-termination flag" does not make it a "client-termination flag" of some kind |
| 13:06 | <MikeSmith> | hsivonen: well I'm not wedded to that patch, so if your refactoring makes it end up being "overtaken by events" in a way that's not mergeable to the refactored code,then no worries |
| 13:06 | <hsivonen> | MikeSmith: back in 2008, there was a plan for infallible malloc in Gecko, but only part of the plan was implemented. When I ported the parser, I was assuming the full plan would be implemented... |
| 13:07 | <hsivonen> | MikeSmith: I think I'll need to merge it manually, yes |
| 13:07 | <MikeSmith> | annevk: yeah "CORS-preflight flag" I think |
| 13:07 | <hsivonen> | MikeSmith: at I think I need to actually try stuff with the patch locally before I can review |
| 13:07 | <hsivonen> | MikeSmith: this stuff is very hard to review by just looking at the code |
| 13:08 | <MikeSmith> | hsivonen: ok (about the manual merge) but I'm also happy to take another shot at it after the refactoring (if you want) |
| 13:08 | <MikeSmith> | hsivonen: yeah, agreed (about being hard to review just be looking at the code, with this stuff) |
| 13:08 | <annevk> | MikeSmith: I guess that means "CORS preflight fetch" and such need hyphens too? |
| 13:09 | <annevk> | MikeSmith: seems like a pretty big problem overall with https://fetch.spec.whatwg.org/ at the moment |
| 13:09 | <MikeSmith> | annevk: I would say so but I'm not the definitive work on this stuff |
| 13:09 | <MikeSmith> | "In general, a compound modifier comprising an adjective plus a noun and preceding the word or words it modifies should be hyphenated" |
| 13:09 | <annevk> | I guess I'll leave this hyphenless until someone can give me the rules |
| 13:10 | <hsivonen> | hmm. looks like the html5lib tokenizer test format has changed since I last ran the tests |
| 13:11 | <MikeSmith> | annevk: "survive client-termination flag" could also be "survive-client-termination flag" and yeah I agree it can start to look a bit silly and like overkill but the point is to make it clear and unambiguous, not necessarily pretty |
| 13:12 | <annevk> | That latter spelling makes more sense to me |
| 13:13 | <MikeSmith> | annevk: http://www.economist.com/style-guide/hyphens is one guide with some example |
| 13:13 | <MikeSmith> | e.g., "third-world war" and "third world war" mean two different things |
| 13:14 | <MikeSmith> | http://www.apastyle.org/learn/faqs/when-use-hyphen.aspx is good too |
| 13:16 | <tobie> | darobin: does respec support syntax highlighting of JS? I assumed it did, but can't seem to get it working |
| 13:16 | <MikeSmith> | http://www.thewriter.com/what-we-think/style-guide/to-hyphenate-or-not-to-hyphenate/ |
| 13:16 | <hsivonen> | The Chicago Manual of Style is *very* weird around this topic |
| 13:16 | <darobin> | tobie: <pre class="example highlight">.... should work |
| 13:16 | <MikeSmith> | "A man eating tiger" vs "A man-eating tiger" |
| 13:17 | <hsivonen> | IIRC, it says that "Civil War-era" should be written with an en dash instead of a hyphen. (who does that?) |
| 13:17 | <MikeSmith> | hsivonen: yeah Chicago Manual has a lot of quaint idiosyncrasies |
| 13:20 | <MikeSmith> | New Yorker magazine has some relics too, like they still use coöperate instead of cooperate like everybody else in the universe |
| 13:20 | <hsivonen> | MikeSmith: coöperate isn't as weird as promoting a hyphen to an en dash |
| 13:20 | <MikeSmith> | true |
| 13:24 | <MikeSmith> | hsivonen: http://www.thepunctuationguide.com/en-dash.html#compoundadjectives says something about that odd en-dash usage |
| 13:24 | <MikeSmith> | "When a compound adjective is formed with an element that is itself an open compound or hyphenated compound, some writers replace the customary hyphen with an en dash." |
| 13:24 | <MikeSmith> | but yeah I don't know who those "some writers" are |
| 13:25 | <MikeSmith> | "The Oxford University Press style manual points out that ‘If you take hyphens seriously, you will surely go mad’." |
| 13:25 | <hsivonen> | the editorial board of CMoS probably |
| 13:25 | <hsivonen> | (being "some writers" that is) |
| 13:26 | <hsivonen> | in other news, I found a bug either in my parser code, in the unit tests or the spec. most likely in the parser |
| 13:26 | <hsivonen> | though I'm pretty sure that the code followed the spec when written |
| 13:27 | <hsivonen> | the issue being the name of the token in the <!DOCTYPE> case |
| 13:27 | <hsivonen> | parser says "", tests say null |
| 13:33 | MikeSmith | hopes it's not a regression caused by code he touched but pretty sure it could not be |
| 13:34 | <hsivonen> | MikeSmith: code comments suggests that the code is ancient and written to then-spec |
| 13:34 | <hsivonen> | so... |
| 13:35 | <MikeSmith> | whew |
| 13:35 | <hsivonen> | before the refactoring, I should have thought about overflowing numeric character references some more |
| 13:35 | <MikeSmith> | I wouldn't be surprised if the spec changed in the mean time then |
| 13:35 | hsivonen | considers them now |
| 13:35 | <MikeSmith> | character references is massive PITA |
| 13:35 | <hsivonen> | yes |
| 13:35 | <MikeSmith> | not worth the cost but stuck with it now |
| 13:40 | hsivonen | finds a bug in the existing NCR overflow handling |
| 13:41 | <hsivonen> | fun |
| 13:44 | <hsivonen> | only happens on EOF |
| 13:46 | <MikeSmith> | that code is no joy ride |
| 13:46 | <MikeSmith> | I guess it's the nature of the thing though |
| 13:47 | <hsivonen> | �EOF differs from �EOF �EOF �x and � |
| 13:48 | <MikeSmith> | that kinda rings some bells |
| 13:48 | <MikeSmith> | I think I independently noticed that when I was writing the othe patch |
| 13:49 | <hsivonen> | wow |
| 13:51 | <MikeSmith> | I spent quite a while looking at that code at the time, and testing |
| 13:51 | <MikeSmith> | I guess I should have actually put some additional test cases somewhere |
| 13:52 | <MikeSmith> | but I sorta vaguely remember finding out, hmm, this doesn't actually work for all cases (I mean just as far as the patch I had written) |
| 13:53 | <MikeSmith> | I guess I assumed the reason it didn't work for some cases was a problem in the code in my patch and not a problem already in the existing code |
| 13:54 | MikeSmith | wonders what html5ever source for handling this stuff looks like |
| 13:55 | MikeSmith | peruses https://github.com/servo/html5ever/blob/master/src/tokenizer/char_ref/mod.rs |
| 13:57 | <MikeSmith> | oh I didn't know html5ever had actual error reporting for parse errors |
| 13:57 | <jgraham> | WTAF |
| 13:58 | <jgraham> | Is my Firefox broken or are github using a non-fixed width font for code> |
| 14:00 | <jgraham> | Hmm, the font-family rule looks reasonable |
| 14:00 | <MikeSmith> | looks like fixed-width in my Firefox |
| 14:01 | <jgraham> | So apparently "Consolas" is being interpreted as something else |
| 14:01 | <jgraham> | for me |
| 14:06 | <MikeSmith> | jgraham: I got "Menlo Regular" (system) Used as: "Menlo" |
| 14:06 | <jgraham> | MikeSmith: Yeah, isn't that a mac thing though |
| 14:06 | <MikeSmith> | oh |
| 14:07 | <MikeSmith> | yeah I guess so |
| 14:08 | <MikeSmith> | ah font-family: Consolas, "Liberation Mono", Menlo, Courier, monospace; |
| 14:15 | annevk | started using needsinfo on W3C Bugzilla |
| 14:15 | <annevk> | So far, positive results! |
| 14:17 | <MikeSmith> | yay glob |
| 14:29 | <hsivonen> | hmm. does the spec really now involve scanning for an arbitrarily large number of alphanumeric ASCII after & to see if the sequence is followed by ;? |
| 14:29 | <hsivonen> | to see if it's a parse error or not |
| 14:29 | <srji> | cd /home/visualisierte/Web/uiani |
| 14:32 | <annevk> | edit dom.bs |
| 14:32 | <hsivonen> | DoubleLongLeftRightArrow; |
| 14:33 | <hsivonen> | ClockwiseContourIntegral; |
| 14:33 | <hsivonen> | ooh. there is |
| 14:33 | <hsivonen> | CounterClockwiseContourIntegral; |
| 14:33 | <hsivonen> | that seems to be the longest valid character reference name |
| 14:34 | <hsivonen> | but I guess I should check programmatically |
| 14:34 | hsivonen | wishes https://html.spec.whatwg.org/entities.json had existed way back when |
| 14:53 | <wanderview> | annevk: can you elaborate on what you mean in this comment? https://github.com/slightlyoff/ServiceWorker/issues/710#issuecomment-111017003 |
| 14:53 | <wanderview> | what impact does opaque have on <img>? |
| 14:53 | <annevk> | wanderview: that you cannot paint it on canvas and then read the bytes |
| 14:53 | <annevk> | read the pixels* |
| 14:54 | <wanderview> | annevk: is that spec'd anywhere yet? |
| 14:55 | <wanderview> | and what behavior should painting on canvas implement? display, but reading rejects or returns zero or something? |
| 14:56 | <annevk> | yeah, once you paint on canvas that taints it |
| 14:56 | <annevk> | that is specced |
| 14:57 | <annevk> | what is not specced is that if <img> gets an opaque response it needs to look at the internal response |
| 14:57 | <annevk> | the idea is that most new features would not look at the internal response but would use the same API as everyone else |
| 14:57 | <annevk> | thereby not creating new cross-origin information leaks |
| 14:57 | <annevk> | (<img> leaks height/width) |
| 14:58 | <wanderview> | its in the canvas spec? |
| 15:00 | <annevk> | yeah |
| 15:00 | <wanderview> | origin-clean |
| 15:00 | <wanderview> | I see it |
| 15:00 | <wanderview> | now to find where gecko implements that |
| 15:28 | <wanderview> | annevk: I think maybe we should write a separate spec issue for this... the only thing I see in the SW spec is non-normative text: "Renderer-side security checks about tainting for cross-origin content are tied to the transparency (or opacity) of the Response body, not URLs." |
| 15:29 | <wanderview> | it seems the steps should say something about tainting based on opacity |
| 15:30 | <wanderview> | I guess the steps don't really say to do anything in respondWith()... they just... end |
| 15:33 | <wanderview> | hmm, no it returns it to Main Fetch through HandleFetch |
| 15:34 | <wanderview> | annevk: does normal document loading integrate with Main Fetch or HandleFetch anywhere? maybe thats what I am missing |
| 15:38 | <annevk> | wanderview: everything invokes #concept-fetch |
| 15:38 | <annevk> | wanderview: I guess I need to review SW again |
| 15:39 | <wanderview> | annevk: does it say to use the internal body of an opaque response? because I guess its the internal things that use fetch that need to say that |
| 15:40 | <annevk> | wanderview: I don't follow |
| 15:41 | <annevk> | wanderview: ah, when you navigate someplace and get an opaque response that fails |
| 15:41 | <annevk> | wanderview: Fetch has some checks for that, results in a network error |
| 15:41 | <wanderview> | annevk: sorry, not navigate itself... |
| 15:42 | <wanderview> | annevk: what in spec says the browser should look at the internal response body when an opaque response is passed to respondWith() for a resource load (not navigation) |
| 15:42 | <wanderview> | ? |
| 15:42 | <wanderview> | doesn't that need to be done in whatever uses #concept-fetch? |
| 15:44 | <annevk> | yes |
| 15:45 | <annevk> | wanderview: Fetch also needs to work on the internal response |
| 15:45 | <wanderview> | annevk: but does something in the main html spec use concept-fetch? |
| 15:45 | <annevk> | wanderview: it currently doesn't in https://fetch.spec.whatwg.org/#concept-http-fetch which might be buggy |
| 15:45 | <annevk> | wanderview: not literally right now, but the whole platform does conceptually |
| 15:47 | <annevk> | back later |
| 15:47 | <wanderview> | annevk: well, I think its literal for the respondWith() case, right? the browser is loading an <img> element and the SW intercepts with respondWith()... that integration between <img> load and respondWith() Response is not really spec'd anywhere yet, right? |
| 15:48 | <annevk> | wanderview: once HTML et al are updated to use #concept-fetch, that would be specified |
| 15:48 | <wanderview> | ok, thanks |
| 15:49 | <annevk> | I mean, as long as those specifications are not updated, nothing would result in a SW being booted to handle their fetches... |
| 15:49 | <annevk> | Technically... |
| 15:50 | <wanderview> | yea |
| 15:50 | <wanderview> | stuff like passing on the tainting is not spec'd yet either, then |
| 15:51 | <ek_> | hello |
| 15:51 | <ek_> | i have a question related to HTML5 spec |
| 15:52 | <ek_> | In the spec when it says await a stable state |
| 15:52 | <ek_> | what does it mean by stable state? |
| 15:59 | <JonathanNeal> | I wanted to bring to your attention an issue I have with :focus and :hover being separate pseudo-classes, and pitching a solution @ http://discourse.specifiction.org/t/a-common-pseudo-class-for-hover-and-focus/877 |
| 16:27 | <annevk> | heycam: you around? |
| 16:28 | <annevk> | heycam: the algorithms to get bytes out of a BufferSource can throw |
| 16:28 | <annevk> | heycam: due to e.g. the buffer being detached |
| 16:28 | <annevk> | heycam: it would be much nicer if the binding layer threw, no? |
| 16:31 | <Domenic> | https://github.com/orgs/improved-permissions?utm_source=github_site&utm_medium=blog&utm_campaign=organization-permissions looks useful |
| 16:53 | <heycam> | annevk: hi, yes but about to head out to dinner |
| 16:57 | <heycam> | annevk: where is the algorithm now, in Fetch? |
| 16:58 | <heycam> | annevk: oh no, we've got the "get a copy of the bytes held by the buffer source" term in IDL |
| 16:58 | <heycam> | and "Attempting to get a reference to or get a copy of the bytes held by a buffer source when the ArrayBuffer has been detached will fail in a language binding-specific manner." |
| 16:59 | <heycam> | so yes, I think having something in IDL that says the specific failure mode would be good |
| 17:00 | <heycam> | hmm, so in http://heycam.github.io/webidl/#es-buffer-source-types we check for [[ArrayBufferData]] being null, and throw |
| 17:00 | <heycam> | which I think is the state when the buffer has been detached |
| 17:01 | <heycam> | can you verify that's right? |
| 17:50 | <annevk> | heycam|away: yeah |
| 17:50 | <annevk> | heycam|away: I'll file a bug on making that use IsDetachedBuffer |
| 19:10 | <Domenic> | annevk: btw we are collecting code coverage on web-platform-tests vs. jsdom/whatwg-url: https://github.com/jsdom/whatwg-url/issues/8 |
| 19:10 | <Domenic> | annevk: hopefully we will supplement web-platform-tests with 100% coverage before this is all over |
| 19:10 | <Domenic> | right now it is like 70% |
| 19:25 | <jgraham> | Domenic++ |
| 19:28 | <tobie> | this is probably a very daft question, is it possible to throw DOM Exceptions from application code, and if so, what's the best practice to do it? |
| 19:29 | <Ms2ger> | new DOMException() |
| 19:30 | <Ms2ger> | Works in Gecko |
| 19:31 | <Domenic> | Not in Chrome yet, but soon |
| 19:33 | <tobie> | oh, that's why. :) |
| 19:33 | <jib> | tobie: in firefox: throw new DOMException("hi", "SyntaxError"); http://jsfiddle.net/gm2czfva |
| 19:34 | <tobie> | ty jib |
| 20:03 | <TabAtkins> | Who still theoretically "maintains" Anolis? Can we get that person to put a big "THIS TOOL IS NOT MAINTAINED, PLEASE USE BIKESHED INSTEAD" message on all the docs and download pages? |
| 20:03 | <jgraham> | gsnedders: ^ |
| 20:04 | <gsnedders> | Ms2ger: ^^ |
| 20:04 | <TabAtkins> | (Someone just dropped by w3c#pub with a problem publishing a spec using Anolis, and robin was rightly horrified that they were even capable of doing that at this point.) |
| 20:05 | <jgraham> | (something, something, horrified, respec, something) |
| 20:06 | <TabAtkins> | Baby steps. |
| 20:06 | <tantek> | bikeshed > respec b/c js;dr something something |
| 20:20 | <TabAtkins> | tantek: Well, there are a few reasons, related to both user experience and ecosystem health, but yeah. |
| 20:22 | <tantek> | TabAtkins: agreed, hence the something something :) |
| 20:32 | <jsbell> | tobie: per spec, `new` is optional for DOMException() constructor, just like native JS errors. That's holding me up landing Chrome support (it shouldn't but I'm also lazy...) |
| 20:33 | <tobie> | jsbell: do we get to add new error codes to it? |
| 20:33 | <tobie> | (asking for a friend) |
| 20:34 | <jsbell> | tobie: no; if you pass a known name (from webidl spec) it gets stamped with the right code, otherwise .code === 0 |
| 20:35 | <jsbell> | Unless you meant new error names, in which case yeah, use any string you want. |
| 20:35 | <tobie> | I don't know what I meant |
| 20:36 | <tobie> | Imagine I'd like to have CacheMissError in a spec, how would I go about doing that? |
| 20:36 | <Ms2ger> | TabAtkins, can do, send me email |
| 20:37 | <jsbell> | tobie: "throw a CacheMissError exception." where 'throw' references the algorithm in webidl |
| 20:37 | <tobie> | and that's it? |
| 20:38 | <tobie> | I don't need to define CacheMissError anywhere? |
| 20:38 | tobie | goes crazy |
| 20:38 | <jsbell> | tobie: or "throw a new DOMException with error name CacheMissError" |
| 20:38 | <jsbell> | it's just a string |
| 20:38 | <jsbell> | go wild |
| 20:38 | <jsbell> | (the former is the short form I've seen annevk using and I've borrowed, webidl uses the latter) |
| 20:39 | tobie | throws a NSFWError exception. |
| 20:40 | <tobie> | ty |
| 20:40 | <jsbell> | webidl says "if you invent new exception types, report 'em and they'll get added asap" but I think that's just to keep the documentation in one place |
| 20:40 | <jsbell> | in IDB "v2' I still have all the exception types documented, but it does defer all details to webidl |
| 20:41 | <tobie> | k |
| 20:41 | <jsbell> | (^^ not an actual quote) |
| 23:26 | <ek_> | HI |
| 23:26 | <ek_> | In HTML5 specs it talks about event loop which is responsible for processing events from the task queues. I was wondering which thread can enqueue events? Lets say if there is a UI event will there be a separate thread that will enqueue event and that event will be processed by the event loop? |