| 00:23 | <MikeSmith> | Domenic: hmm yeah |
| 00:24 | <MikeSmith> | and I'm just trusting that tool of Chris's is testing what it seems to be testing (because too lazy to try testing it directly right now) |
| 00:25 | <MikeSmith> | I'm busy reading through the now-finally-not-a-private-repo-any-more wasm stuff |
| 00:26 | <MikeSmith> | after weeks of luring on the #webassembly IRC channel and trying to reverse-engineer from check-in comments that commit bot posts there |
| 00:26 | <MikeSmith> | *lurking |
| 00:29 | <jsbell> | MikeSmith: re: encodings - https://encoding.spec.whatwg.org/#names-and-labels |
| 00:31 | MikeSmith | looks |
| 00:33 | <jsbell> | depends on context, but if it's not in the table the result is "failure" - which means depends on context |
| 00:33 | <MikeSmith> | jsbell: I guess annevk needs to update the "utf-8" row in that table to say "also any string that's not a name or label for any other encoding listed in this table" |
| 00:33 | <jsbell> | for html, it's still good ol' windows-1252 |
| 00:33 | <MikeSmith> | oh |
| 00:34 | <MikeSmith> | jsbell: so is http://www.lookout.net/test/charsets/iana-charset-support/ not showing what it seems to be showing? |
| 00:34 | <MikeSmith> | or are all UAs just not conforming on this? |
| 00:35 | <MikeSmith> | hmm now that I say that out loud I realize already know that HTML parsers fall back to windows-1252 |
| 00:35 | <jsbell> | ugh, contentDocument.charset/characterSet is a whole nother set of aliases/logic... |
| 00:36 | MikeSmith | drafts reply to Chris Weber |
| 00:37 | MikeSmith | sees that jsbell already beat him to it |
| 00:37 | <jsbell> | well, I was missing context so I'm not sure I'm helping. |
| 00:38 | <jsbell> | hrm, those aliases aren't as bad as I remember apparently: https://github.com/w3c/web-platform-tests/blob/master/encoding/resources/encodings.js |
| 00:41 | <karlcow> | TabAtkins: +1 to the meta element in SVG. that would save a lot of insanity. |
| 00:42 | <heycam> | that, and link, would make my life easier writing reftests |
| 00:42 | <TabAtkins> | Yeah, we want it for a few other things, too, like declaring SVG Params (the ability to set a CSS custom property via a query parameter). |
| 00:42 | <TabAtkins> | Yeah, <link> too. |
| 00:42 | <heycam> | but it would need us to finally come up with a plan for supporting these from-HTML elements without duplicating them in the SVG namespace |
| 00:43 | <heycam> | (a plan that everyone can live with, that is; we've had a couple of plans...) |
| 00:43 | <TabAtkins> | The only "issue" is that in an XML syntax you need to specify the HTML namespace for them. |
| 00:43 | <TabAtkins> | (Note that we're now finally actively looking into just using the foreign-content parser for standalone SVG. More than just talk, finally.) |
| 00:44 | <TabAtkins> | (That would avoid the need; HTML elements would just be given the HTML namespace automatically.) |
| 00:45 | <heycam> | TabAtkins, is that Blink experimenting with using HTML parser for standalone SVG documents? |
| 00:45 | <TabAtkins> | Yeah. |
| 00:45 | <heycam> | do you have a link for any discussion/announcement? |
| 00:45 | <TabAtkins> | Not yet, just internal discussions. We're throwing around some use-counters right now. |
| 00:45 | <heycam> | ok. look forward to hearing the outcomes. |
| 00:46 | <TabAtkins> | (Attempting to eliminate XML from our engine entirely, if possible. We only need it for SVG, XHR.responseXML, and XSLT.) |
| 00:46 | <TabAtkins> | Moving SVG to the HTML parser would be easy and better for authors (consistent syntax), XHR we'll see if we can move to a simplistic parser like XML5 or similar. XSLT, lol I dunno. |
| 00:47 | <heycam> | I thought you already were going to just implement XSLT in JS |
| 00:48 | <TabAtkins> | That's vaguely the plan, yeah. |
| 00:49 | <boogyman> | TabAtkins: re: (the ability to set a CSS custom property via a query parameter). <-- What's the use-case? Why would you want the client to control the aesthetics of your app? |
| 00:50 | <TabAtkins> | boogyman: SVG images that can have colors/etc set at time of use. <img src="logo.svg?main-color=blue"> |
| 00:50 | <TabAtkins> | You have to pre-declare which properties are Params, to prevent arbitrary screwing around. |
| 01:25 | <MikeSmith> | ah rektide |
| 01:26 | <MikeSmith> | it didn't take you long |
| 01:26 | <MikeSmith> | https://groups.google.com/d/msg/emscripten-discuss/k-egXO7AkJY/GLqWCJCPnqwJ |
| 01:26 | <MikeSmith> | you need one of those signs man |
| 01:27 | <MikeSmith> | "The End is Near" |
| 03:26 | <hayato> | Does someone know why DocumentFragment doesn't support innerHTML? It looks only Element support it. |
| 03:33 | <hayato> | The context is https://code.google.com/p/chromium/issues/detail?id=497175 . I am wondering how ShadowRoot.innerHTML should behave. |
| 03:57 | <Domenic> | hayato: there was a thread a few years back, let me find it |
| 03:57 | <Domenic> | hayato: https://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663 |
| 03:57 | <hayato> | Domenic: Thank you! |
| 03:59 | <Domenic> | lots of support from blink people, here's some from Moz... https://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0670.html |
| 03:59 | <Domenic> | Here's some from rniwa... https://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0675.html |
| 04:00 | <Domenic> | this one outlines some of the hard cases... https://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0766.html |
| 04:02 | <Domenic> | <a> is a problem, SVG vs. HTML https://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0812.html |
| 04:02 | <Domenic> | so in conclusion, people like it, but edge cases are probably hard |
| 04:10 | <rniwa> | Domenic: I don't think you should consider my comment in 2011 as endorsement from WebKit project |
| 04:10 | <rniwa> | Domenic: since i was working for Google at the time. |
| 04:10 | <Domenic> | haha right, ok |
| 04:11 | <rniwa> | (note that i would necessarily oppose to this particular proposal) |
| 04:11 | <boogyman> | rniwa: were you speaking on behalf of yourself or the company? |
| 04:14 | <rniwa> | boogyman: in public-webapps, I was a representative of Google until October 2012. |
| 04:14 | <rniwa> | boogyman: now I'm a representative of Apple |
| 04:15 | <boogyman> | cheers |
| 04:15 | <rniwa> | boogyman: do I speak on behalf of my employer? probably not. |
| 04:15 | <rniwa> | boogyman: do my opinions change based on goals/needs of my employer? absolutely. |
| 04:17 | <boogyman> | Understood. classic User v Business model for making decisions. |
| 04:18 | <rniwa> | yeah, each company has its own priority and rightly so. |
| 05:10 | <annevk> | MikeSmith: yeah, there's no defaulting to utf-8 |
| 05:24 | <MikeSmith> | annevk: yeah I don't know what Chris's test is doing |
| 05:30 | <annevk> | MikeSmith: when can you review the new URL tests? |
| 05:30 | <MikeSmith> | in a few hours |
| 05:30 | <annevk> | MikeSmith: thanks! |
| 05:30 | <annevk> | MikeSmith: I might create some more today, and I'm super bad with git |
| 05:30 | <annevk> | so I'd rather not get a bunch of merge conflicts |
| 05:31 | <MikeSmith> | OK |
| 05:31 | <MikeSmith> | I reckon I can get to it within 1 hour |
| 06:36 | <MikeSmith> | annevk: gedaan |
| 06:48 | <annevk> | MikeSmith: sugoi |
| 06:55 | <annevk> | https://github.com/w3c/web-platform-tests/commit/2717ed0b937d4612bd18261559bd0dd7800fba96 this looks really bad... SRI fixes shouldn't affect all those files... |
| 06:55 | <annevk> | Or is that just how bad merges go? How do we know that did not overwrite any other work? Seems impossible to review... |
| 06:58 | <MikeSmith> | annevk: yeah that stuff is all because Joel flubbed and ended up with a branch merge tin that PR |
| 06:59 | <MikeSmith> | unfortunately with git that's a very easy mistake to make |
| 06:59 | <MikeSmith> | but it's not hard to unwind |
| 06:59 | <annevk> | But how do we know nothing bad happened? |
| 06:59 | <MikeSmith> | you can look at the commits separately |
| 07:00 | <MikeSmith> | though he should probably re-submit another PR with the same commits minus that merge |
| 07:00 | <MikeSmith> | or I can do it for him and he can clone the branch I make |
| 07:01 | <annevk> | well all the commits already went into master |
| 07:01 | <annevk> | oh well |
| 07:01 | <annevk> | perhaps there should be some tighter control on who can do the final commits so the whole thing makes a bit more sense |
| 07:01 | <MikeSmith> | ah christ you're right |
| 07:02 | <MikeSmith> | I thought he had committed to a branch |
| 07:02 | <MikeSmith> | yeah that's .. not so great |
| 07:02 | <MikeSmith> | but we can still unwind it |
| 07:03 | <annevk> | I've started doing things the Domenic-way for my repos so you don't even get merge commits |
| 07:03 | <MikeSmith> | annevk: about tighter control we have a soft policy that nobody should commit any of their own changes to master |
| 07:03 | <annevk> | I just attribute authorship through --author although that's rather cumbersome |
| 07:03 | <MikeSmith> | yeah that works too |
| 07:03 | <annevk> | I want GitHub to support an author field in their client |
| 07:04 | <annevk> | So I can just use @domenic or some such |
| 07:04 | <MikeSmith> | I've never used their client |
| 07:04 | <MikeSmith> | I just use the git comment |
| 07:04 | <MikeSmith> | *command |
| 07:04 | <annevk> | I guess I should learn to use that |
| 07:04 | <annevk> | Main problem with the command line and me is multiline stuff |
| 07:05 | <MikeSmith> | man I hope Joel did all that by mistake. I mean as far as committing it master |
| 07:05 | <annevk> | Well and remembering all the silly parameters |
| 07:06 | <MikeSmith> | Brad reviewed that PR, but it didn't have those branch merges in it when he reviewed it |
| 07:06 | <MikeSmith> | what probably should have better happened is that Brad just pushed the merge button in the github UI after he reviewed it |
| 07:07 | <MikeSmith> | what seems to have happened instead is that Joel committed the branch merges after Brad had reviewed it, then Joel pushed that |
| 07:07 | <MikeSmith> | anyway, nothing fatal |
| 07:12 | <annevk> | MikeSmith: also, web-platform-tests has a lot of old branches |
| 07:12 | <annevk> | MikeSmith: I assume not all of those are active anymore |
| 07:12 | <annevk> | MikeSmith: could we maybe kill some of them? |
| 07:19 | <MikeSmith> | annevk: yeah I will right now |
| 07:19 | <MikeSmith> | kill some |
| 07:20 | <annevk> | Maybe https://bugzilla.mozilla.org/show_bug.cgi?id=1170774#c4 should be documented on the wiki |
| 07:20 | <annevk> | Amount of WHATWG Standards is slowly growing |
| 07:29 | <MikeSmith> | may a hundred flowers bloom |
| 07:29 | <MikeSmith> | and a hundred schools of thought contend |
| 07:36 | <MikeSmith> | annevk: deleted all the old branches I safely could |
| 07:37 | <MikeSmith> | many of the remaining ones were either created by jgraham or Ms2ger and have no associated PR so they would need to check and see if it's a branch they're planning to work again on ever or not |
| 07:38 | <MikeSmith> | annevk: btw one of those branches-in-limbo is yours, https://github.com/w3c/web-platform-tests/tree/encoding-and-css |
| 07:38 | <MikeSmith> | with https://github.com/w3c/web-platform-tests/commit/02ac3d372060393f4c0a6a0f29a95dd9f0ee8fda |
| 08:14 | <annevk> | I wonder if we should require owners to setup 2-factor auth... https://github.com/orgs/whatwg/people |
| 08:15 | <annevk> | MikeSmith: yeah I know, I was hoping someone would take that over |
| 08:15 | <annevk> | MikeSmith: but despite all the talk from the i18n WG, nothing much materialized |
| 08:15 | <MikeSmith> | annevk: well it's not doing any harm so you could just leave it |
| 08:16 | <MikeSmith> | annevk: no comment š |
| 08:16 | <MikeSmith> | we need a template for that sentence |
| 08:16 | <MikeSmith> | "despite all the talk from [aaa], nothing much materialized" |
| 08:46 | <annevk> | heh |
| 08:47 | <annevk> | There's that skeleton meme... |
| 10:01 | <philipj> | annevk: do you have a preference about https://bugzilla.mozilla.org/show_bug.cgi?id=1165851#c41 ? I'm trying to measure something here, but what do you think the most likely end-state of the spec will be? |
| 10:02 | <annevk> | philipj: my preference is 1 as well |
| 10:02 | <annevk> | philipj: I have good hopes that's fine, smaug____ seems to think otherwise |
| 10:02 | <smaug____> | it is just very weird API if it can't be used with SVG |
| 10:03 | <philipj> | annevk: ok, so if I'm to measure differences, it's exactly what the spec currently says, plus a "lowercase localName if the document is an HTML document" as part of createAttribute? |
| 10:03 | <smaug____> | I'd then make setAttributeNode to throw with SVG elements in html documents |
| 10:03 | <philipj> | smaug____: there's still createAttributeNS and setAttribute |
| 10:03 | <smaug____> | sure |
| 10:04 | <philipj> | smaug____: what end state do you think would be better? |
| 10:04 | <smaug____> | but attributes are rarely in any namespace, so I wouldn't expect the API user to remember that *NS should be used with SVG |
| 10:04 | <smaug____> | of course no one should use Attr nodes |
| 10:05 | <annevk> | smaug____: I don't think making any method throw improves the status quo |
| 10:05 | <philipj> | from the code I've found, people are already assuming that case doesn't matter with createAttribute, doing things like createAttribute("frameBorder") |
| 10:05 | <annevk> | smaug____: perhaps making setAttribute() more magical to recognize SVG attributes would |
| 10:06 | <smaug____> | annevk: well, it would make it clear that if #1 is taken, createAttribute is totally broken with svg |
| 10:06 | <smaug____> | (and MathML too) |
| 10:06 | <smaug____> | philipj: but case does matter on SVG |
| 10:06 | <annevk> | we could rather than lowercase all the things also recognize https://html.spec.whatwg.org/multipage/syntax.html#adjust-svg-attributes |
| 10:06 | <annevk> | smaug____: it's not totally broken with SVG |
| 10:06 | <philipj> | smaug____: yes, but I found zero cases of SVG attribute together with createAttribute |
| 10:06 | <annevk> | smaug____: it works just fine for most SVG usage |
| 10:07 | <annevk> | smaug____: even more so for MathML |
| 10:07 | <philipj> | annevk, smaug____, how about modifying Attr.localName inside setAttributNode? |
| 10:07 | <annevk> | smaug____: there's only one MathML attribute that's not lowercase |
| 10:08 | <annevk> | philipj: that's prolly only feasible if Attr's are not really nodes |
| 10:08 | <philipj> | at least there's an element around in that case |
| 10:09 | <philipj> | annevk: why? |
| 10:09 | <smaug____> | the number of non-lowercase doesn't matter, if there is just one. Either the API should work with SVG and MathML, or it shouldn't. The buggy "works occasionally, if you remember to not use it with camelCase attributes" sounds rather horrible to me |
| 10:09 | <annevk> | philipj: never mind, might be okay either way, but also somewhat magical |
| 10:09 | <smaug____> | philipj: that might work |
| 10:10 | <smaug____> | so, preserve case, but when setAttributeNode is called on html element in html document, lowercase? |
| 10:10 | <philipj> | annevk: sure, it's a bit odd, but technically it doesn't seem very hard |
| 10:10 | <philipj> | smaug____: yes |
| 10:10 | <annevk> | I wouldn't really use setAttribute() most of the time anyway... Most attributes have a dedicated getter/setter pair you can use instead |
| 10:13 | <philipj> | assuming that no createAttribute() hack works out, would the next best thing be to lowercase input in all other setters and do case-insensitive lookups in getters, removers, and hasAttribute? |
| 10:14 | <Ms2ger> | No case-insensitive lookup, please |
| 10:14 | <philipj> | Ms2ger: is there another way if a createAttribute() fix doesn't work out? Just trying to figure out what's interesting to measure so we only have to wait for one release cycle |
| 10:15 | <annevk> | philipj: yeah, but we should do createAttribute() |
| 10:15 | <annevk> | I don't really care if that makes it impractical for some SVG usage, it shouldn't be used anyway |
| 10:15 | <philipj> | annevk: well I can get behind that. will it fly in Gecko code review, smaug____? |
| 10:19 | <smaug____> | philipj: I don't now understand the proposal |
| 10:20 | <philipj> | smaug____: annevk may correct me, but simply to convert localName to lowercase when createAttribute(localName) is called in an HTML document |
| 10:21 | <smaug____> | so #1 |
| 10:21 | <philipj> | yeah |
| 10:21 | <smaug____> | which doesn't work with svg |
| 10:21 | <philipj> | right |
| 10:21 | <philipj> | so will it fly? |
| 10:21 | <smaug____> | I'd rather take "preserve case, but when setAttributeNode is called on html element in html document, lowercase" |
| 10:22 | <smaug____> | philipj: though, if telemetry shows that Attrs are never used with svg, then #1 would be fine. Horrible, broken API, but easy to implement |
| 10:22 | <annevk> | smaug____: that seems like a weirder API since currently names are immutable for all nodes in the DOM |
| 10:24 | <philipj> | smaug____: ok, so if the telemtry requested in https://bugzilla.mozilla.org/show_bug.cgi?id=1175031 shows that virtually no calls createAttribute() with non-lowercase input and then attaches that to a non-HTML document, it's OK? |
| 10:24 | <philipj> | +one |
| 10:24 | <philipj> | non-HTML element I mean |
| 10:24 | <smaug____> | at least I'd have hard time to object the behavior then :) |
| 10:25 | <smaug____> | philipj: non-HTMLElement |
| 10:25 | <smaug____> | not document |
| 10:25 | <smaug____> | the worrisome case is svg in HTML document |
| 10:25 | <smaug____> | I assume createAttribute won't lowercase ever in non-html documents |
| 10:26 | <philipj> | smaug____: right, that would be overkill |
| 10:26 | <philipj> | it would be very easy to measure how often setAttribute is called on an SVG element in an HTML document and the attr.localName is not lowercase |
| 10:26 | <philipj> | some other ideas would require tracking the source of the Attr object which seems less fun |
| 10:27 | <philipj> | or perhaps non-HTMLElement instead of SVGElement to be slightly more conservative |
| 11:11 | <annevk> | beverloo: can you tell me where IsIPv4Char is defined within http://src.chromium.org/viewvc/chrome/trunk/src/url/ perhaps? |
| 11:12 | <annevk> | Google's URL code is so much more complicated than that of Apple... I wonder what happened |
| 11:12 | <beverloo> | https://code.google.com/p/chromium/codesearch#chromium/src/url/url_canon_internal.h&q=IsIPv4Char&sq=package:chromium&type=cs&l=65 |
| 11:12 | <annevk> | That viewer is so much better! |
| 11:12 | <beverloo> | which maps to: https://code.google.com/p/chromium/codesearch#chromium/src/url/url_canon_internal.cc&q=kSharedCharTypeTable&sq=package:chromium&type=cs&l=110 |
| 11:13 | <beverloo> | It's got a search function too :) https://cs.chromium.org |
| 11:15 | <annevk> | So that kind of matches what I expected, but doesn't really explain why 100x.0.0.0 ends up as a normal host name and not as a failure... |
| 11:16 | <annevk> | I guess there's some rather arbitrary rulings when something becomes IPv4, "broken", or "not IPv4"... |
| 14:16 | <yoav> | Hey! Anyone happens to know why in "<img src width='100*'>" the width is ignored? |
| 14:19 | <smaug____> | yoav: because of https://html.spec.whatwg.org/multipage/infrastructure.html#rules-for-parsing-integers |
| 14:21 | <yoav> | smaug____: What I see is that * is special cased |
| 14:21 | <yoav> | e.g. "200^" is not ignored |
| 14:22 | <smaug____> | that is then a bug |
| 14:22 | smaug____ | checks the implementation |
| 14:22 | <yoav> | http://jsbin.com/fonidicohi/edit?html,output |
| 14:22 | <yoav> | That's what I see in Blink |
| 14:23 | <yoav> | Oh, in Firefox it is not being special cased |
| 14:24 | <yoav> | I got a feeling this whole area needs a cleanup |
| 14:24 | <yoav> | special cased in WebKit as well |
| 14:27 | <smaug____> | yoav: Gecko is doing something against the current spec |
| 14:27 | <smaug____> | in your test I see $ and * giving the same behavior |
| 14:27 | <smaug____> | both those are ignored |
| 14:28 | <smaug____> | yoav: and blink special cases * somehow |
| 14:28 | <yoav> | Yeah, in Blink/WebKit, only * drops the entire int |
| 14:28 | <yoav> | anything else after the digits is being ignored |
| 14:29 | <smaug____> | yoav: any idea why * is such special case? |
| 14:29 | smaug____ | files a Gecko bug anyhow |
| 14:29 | <Ms2ger> | Don't old-style frames use that? |
| 14:29 | <yoav> | My question exactly :D |
| 14:30 | <yoav> | I think I'll add use counters and try to rip that out if possible |
| 14:30 | <yoav> | and '%' too, for that matter (I doubt that would work though) |
| 14:47 | <yoav> | Ms2ger: Frames where using it inside their `width` attributes? |
| 15:22 | <JonathanNeal> | In the CSS nesting spec, I can use a cartesian product to tie together the parent and child selectors. However, once parent references are involved, Iām lost. Any ideas? |
| 15:31 | <annevk> | yoav: you might want to compare with parseInt() |
| 15:35 | <yoav> | annevk: I see an explicit special casing for '*' before parsing the integer |
| 15:37 | <annevk> | heh |
| 15:41 | <yoav> | annevk: It's totally weird. I'll try counting occurrences and kill it with fire if it's not common (and it shouldn't be since it'd have been a compat issue with Firefox) |
| 15:45 | <annevk> | I guess it's frame parsing code reused because someone was lazy |
| 15:45 | <annevk> | wanderview: so we'll restrict the Cache API on time? |
| 15:45 | <annevk> | wanderview: wondering whether or not to ask that on the intent to ship thread... |
| 15:46 | annevk | finds https://bugzilla.mozilla.org/show_bug.cgi?id=1175138 |
| 15:46 | <wanderview> | annevk: I am currently planning to do a partial restriction and then implement the full restriction later... what do you think? |
| 15:46 | <annevk> | wanderview: yeah that sounds fine |
| 15:46 | <annevk> | wanderview: we need to see if we can restrict SharedWorker somehow |
| 15:46 | <wanderview> | chrome is already shipping caches on http I think... although maybe its just in beta |
| 15:46 | <wanderview> | annevk: my partial restriction will just be a scheme check to start |
| 15:47 | <wanderview> | https:// or localhost (or app: for fxos I guess) |
| 15:48 | <annevk> | wanderview: what if SharedWorker created from a secure context could never be accessed from an insecure context? |
| 15:48 | <annevk> | wanderview: and only such a SharedWorker gets the goodness? |
| 15:48 | <wanderview> | annevk: not sure... seems like we need a spec issue on whatever repo defines SharedWorker |
| 15:48 | <annevk> | wanderview: that is, the secure context would just add to the scope of a SharedWorker |
| 15:49 | <annevk> | HTML defines SharedWorker, but this needs to be monkey patched first |
| 15:49 | <annevk> | I'll file a bug on "POWER" I guess |
| 15:49 | <annevk> | Oh, I can add to your issue: https://github.com/w3c/webappsec/issues/406 |
| 15:50 | <wanderview> | annevk: yea, chrome shipping caches on window in 43... so I believe it allows caches to be used in non-trusted already |
| 15:50 | <wanderview> | ^shipping^shipped |
| 15:50 | <annevk> | bah |
| 15:50 | <annevk> | Was sleevi sleeping? |
| 15:50 | <annevk> | And Joel? And Chris? |
| 15:51 | <wanderview> | annevk: yea... just tried it in the console in chrome release and it worked |
| 15:53 | <annevk> | https://github.com/w3c/webappsec/issues/406#issuecomment-113199509 has my proposal for truly secure shared workers |
| 15:56 | <yoav> | annevk: Is the bit about frame parsing needing to special case '*' defined somewhere? |
| 15:56 | <annevk> | should be |
| 15:56 | <annevk> | https://html.spec.whatwg.org/multipage/rendering.html#frames-and-framesets |
| 15:57 | <yoav> | Thanks! |
| 15:57 | <annevk> | https://html.spec.whatwg.org/multipage/infrastructure.html#rules-for-parsing-a-list-of-dimensions |
| 15:57 | <annevk> | That's only used for frames |
| 17:43 | <annevk> | Whoa whoa whoa |
| 17:43 | <annevk> | "Let mathInt be the mathematical integer value that is represented by Z in radix-R notation, using the letters A-Z and a-z for digits with values 10 through 35." |
| 17:43 | <annevk> | That's not very Allen-style... |
| 17:43 | <annevk> | But I'm going to steal that as it seems wonderfully short |
| 17:49 | <jgraham> | Strictly speaking it doesn't define which digit maps to which symbol |
| 17:51 | <annevk> | I would be happy with better language. Was just looking for some inspiration for the IPv4 thingie |
| 18:03 | <MikeSmith> | I wonder where TC39 is with progress on value objects http://wiki.ecmascript.org/doku.php?id=strawman:value_objects |
| 18:03 | <annevk> | MikeSmith: https://github.com/tc39/ecma262 has a better overview |
| 18:04 | <annevk> | MikeSmith: I think you want https://github.com/dslomov-chromium/typed-objects-es7 |
| 18:04 | <annevk> | MikeSmith: and maybe the SIMD stuff |
| 18:08 | <annevk> | Whoa... (0x4334234).toString(33) is undefined. JavaScript is cutting a lot of corners |
| 18:20 | <caitp> | to be fair, I'm not sure we actually use base 33 very often in practice |
| 18:22 | <caitp> | but wait, no, any radix between 2 and 36 is supposed to do the right thing and not be undefined >_- |
| 18:30 | <deltab> | (26231474015353).toString(31) |
| 19:18 | <MikeSmith> | annevk: thanks |
| 20:23 | <annevk> | https://github.com/WebAssembly/design/pull/195 "You'll have to join the W3C Community Group before we can [correct the link]." |
| 20:23 | <annevk> | That's a new level of absurdity right there |
| 20:33 | <caitp-> | maybe you could just nudge someone whose already in the group? |
| 20:34 | <wanderview> | annevk: wow |
| 20:46 | <Domenic> | wait it's worse https://github.com/WebAssembly/design/pull/199 |
| 20:50 | <caitp-> | azakai makes a good point though? |
| 20:56 | <JoWie> | they might as well lock all issues then |