| 02:48 | <gsnedders> | TabAtkins: re: https://lists.w3.org/Archives/Public/www-style/2014Jun/0053.html why isn't Grid 2 done yet? Pffff. Slacker! |
| 02:51 | <paradisaeidae> | If you're in Sydney on 4th Feb: http://www.meetup.com/SVG-AU/events/228075250/ |
| 03:00 | <MikeSmith> | paradisaeidae: I'm only going if heycam will also be there |
| 03:03 | <TabAtkins> | gsnedders: I didn't give a deadline on purpose! |
| 03:04 | <gsnedders> | TabAtkins: :( |
| 03:04 | <gsnedders> | TabAtkins: it would really help me now plz and thx |
| 03:11 | <paradisaeidae> | Hi MikeSmith, heycam availability is 'uncertain'. |
| 03:27 | <MikeSmith> | paradisaeidae: well mark me as uncertain also then |
| 03:27 | <MikeSmith> | seriously though I don't actually plan to be there |
| 03:28 | <MikeSmith> | was just trolling\ |
| 03:28 | <MikeSmith> | you'll already have enough fun with Doug Schepers being there |
| 03:56 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=1234567#c1 |
| 04:20 | <paradisaeidae> | trolls welcome! |
| 04:21 | <paradisaeidae> | bringIt. |
| 07:10 | <Domenic> | philipj: did you see my "While you're at it can you generate a list of URLs left as http: so we can check they are all namespaces/DTDs/etc.?" |
| 07:23 | <philipj> | Domenic: yep, but I was already writing the following comments :) |
| 07:23 | <philipj> | sorry to make you nervous! |
| 07:27 | <Domenic> | no problem :) |
| 07:38 | <ritsyy> | philipj: for the issues you pointed out in https://github.com/whatwg/html/pull/563#issuecomment-175448060 that needs to be included in the commit message? |
| 07:52 | <philipj> | ritsyy: If you make the first line "Fix #502: bla bla" that would be good |
| 07:52 | <zcorpan> | "dot all the ı's" nice one |
| 08:07 | <MikeSmith> | about comments in https://github.com/whatwg/html/pull/563 on the URLs-ending-with-# thing, isn't that the infamous http-range perma-issue that the old TAG spent literally a decade or something discussing? |
| 08:10 | <MikeSmith> | ritsyy: thanks for writing up https://richarupela.wordpress.com/2016/01/26/outreachy-mid-term/ and for previous blog updates about your whatwg contributions you written so far |
| 08:12 | <MikeSmith> | zcorpan: about https://github.com/whatwg/wattsi/pull/15 code-wise it's fine but what I had wanted to ask you about is if there is if you have a suggestion for how I can test it |
| 08:13 | <MikeSmith> | by changing something locally on the HTML source side rather than caniuse which I can't change directly of course |
| 08:13 | <MikeSmith> | or I can could I guess change something in the local cache of the caniuse data |
| 08:14 | <MikeSmith> | but right now I don't remember clearly what error case this would prevent |
| 08:14 | <zcorpan> | MikeSmith: yeah or change the code to rewrite some URL before calling CanIUseURLToID maybe |
| 08:14 | <MikeSmith> | OK |
| 08:14 | <zcorpan> | MikeSmith: mainly "seamless not found" |
| 08:15 | <MikeSmith> | hai |
| 08:15 | <ritsyy> | philipj: updated, ta! |
| 08:16 | <MikeSmith> | zcorpan: this kinda gets back to, it would be nice to have regression tests for the spec build |
| 08:16 | <ritsyy> | MikeSmith: Thank you :) |
| 08:16 | <MikeSmith> | maybe someday |
| 08:16 | <zcorpan> | MikeSmith: yeah |
| 08:17 | <philipj> | ritsyy: where did you update it? I already updated and pushed your commit, no need to do anythin more for that issue, I was just saying for next time :) |
| 08:23 | <ritsyy> | philipj: yes, i did only the commit message, if referred some time |
| 08:25 | <philipj> | ritsyy: ok, no harm in that, but updating the PR at this point isn't necessary |
| 08:25 | <philipj> | thanks for the fixes! |
| 08:25 | <philipj> | if you like fixing URLs I'm sure you could find a lot more that aren't W3C URLs too |
| 08:26 | <ritsyy> | philipj: yeah, will remember |
| 08:27 | <ritsyy> | philipj: like the URLs fix w3c validator pointed out? |
| 08:30 | <philipj> | ritsyy: well, you could find more problems like that for sure, but you could also try to extract all HTTP URLs, and write a script to check if changing them to HTTPS works |
| 08:31 | <philipj> | maybe something like wget on both forms and see if they are the same, not sure about the details |
| 08:31 | <philipj> | It's very ow priority, just some tips if you enjoy that kind of thing |
| 08:33 | <jochen__> | are there any parts in the html spec that require one origin to be an alias for another? |
| 08:33 | <jochen__> | i.e., not ones that define one origin to be an alias for another |
| 08:33 | <ritsyy> | philipj: yeah, it could be good thing to work on, i will try to do that, thanks :) |
| 08:33 | <jochen__> | but something that checks whether one is already an alias for another |
| 08:34 | <jochen__> | (trying to figure out which operation in blink would map to the "alias" concept) |
| 08:56 | <philipj> | jochen__: do you mean if the spec ever does the equivalent of x.isAliasOf(y)? If so I don't know the answer, at least |
| 09:00 | <philipj> | jochen__: there's "If the effective script origin of the Document is an alias, set it to the value of the effective script origin (essentially de-aliasing the effective script origin)." |
| 09:00 | <philipj> | (found by looking for concept-origin-alias in the source) |
| 09:01 | <philipj> | that also seems to be the only case, and is x.isAlias() rather than x.isAliasOf(y) |
| 09:01 | <philipj> | HTH |
| 09:18 | <philipj> | is it a principle of APIs returning promises, that if the promise is rejected the object will be left in its original state? |
| 11:53 | <nox> | Apple just broke Safari. |
| 11:58 | <zcorpan> | yay https://codereview.chromium.org/1457783005 (fixes the ugly gradient at the bottom of whatwg specs) |
| 13:19 | <jochen__> | this whole aliasing concept appears to not be present in Blink :-/ |
| 13:43 | <zcorpan> | MikeSmith: about https://github.com/whatwg/html/issues/534 and https://github.com/whatwg/html/issues/541 -- it struck me that the spec has requirements for elements that are not in a document, too, but the <template> arguments apply there also probably, except that validators don't check those trees. but an in-browser validator in devtools could... |
| 13:44 | <annevk> | jochen__: origin aliasing? |
| 13:44 | <annevk> | that would be rather curious |
| 13:44 | <zcorpan> | MikeSmith: also i wonder if we should whine about e.g. <template><source src="" srcset=""></template> |
| 13:47 | <jochen__> | annevk: is there a test that can tell the difference between origin aliasing and just copying the origin? |
| 13:49 | <annevk> | jochen__: I'm not sure, iirc this only matters when you set document.domain, it would then not just effect the current document, but also aliased children |
| 13:50 | <jochen__> | ok |
| 13:50 | <jochen__> | so at least in blink, when setting document.domain, we don't touch the security tokens of anything but that document |
| 13:51 | <jochen__> | (where security tokens are the thing used to do access checks) |
| 13:52 | <zcorpan> | jochen__: annevk: how about an about:blank iframe when the parent browsing context has a globally unique identifier as its origin? the spec says the iframe's origin and effective script origin are alias of the creator Document, AFAICT. Would copying a globally unique identifier result in them being same-origin? |
| 13:52 | <annevk> | jochen__: so if you set document.domain, you no longer access <iframe src=about:blank> children? |
| 13:54 | <annevk> | zcorpan: it would, because the identifier would be equal, but the question is what happens when you change the effective script origin |
| 13:56 | <annevk> | jochen__: <script>function x(el) {document.domain = document.domain; w(el.contentWindow.document)}</script><iframe onload=x(this)></iframe> in http://software.hixie.ch/utilities/js/live-dom-viewer/ seems to be able to access the document just fine in Blink |
| 13:56 | <jochen__> | interestingly that still works |
| 13:57 | <annevk> | I guess you might implement this in some different way then |
| 13:58 | <jochen__> | hum hum |
| 13:58 | <jochen__> | so maybe this works as follows |
| 13:58 | <jochen__> | the token check fails and then we fall back to comparing the actual origins |
| 13:59 | <jochen__> | which appear to be sharable objects |
| 13:59 | <jochen__> | according to gdb that's the case |
| 14:01 | <jochen__> | now does somebody know what it means in firefox if you check that principals match |
| 14:01 | <jochen__> | is that checking whether the origins are aliased? |
| 14:02 | <annevk> | smaug____ probably knows that |
| 14:03 | <annevk> | Maybe you can always copy the origin, but you need to alias the effective script origin |
| 14:04 | <annevk> | But I might be missing a subtlety |
| 14:04 | <jochen__> | well, basically, i'm still trying to figure out what document.open() should do :) |
| 14:05 | <jochen__> | while firefox' code reads pretty close to what the spec says, it doesn't modify the origin, but it throws an security error if the principal doesn't match |
| 14:05 | <jochen__> | whatever that means |
| 14:09 | smaug____ | is not too familiar with all the quirks in .domain handling. bholley is the right person to ask |
| 14:09 | <annevk> | jochen__: I found https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security#Security_principals |
| 14:09 | <smaug____> | oh, the question was more about principals |
| 14:11 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/caps/nsIPrincipal.idl#27 |
| 14:15 | <jochen__> | thx |
| 14:18 | <nox> | Hixie_, Domenic: Some links don't work in the forms chapter: https://html.spec.whatwg.org/multipage/forms.html#radio-button-state-%28type=radio%29 |
| 14:19 | <smaug____> | jochen__: if I'm reading the code right, setting document.domain does modify the principal of the document, and since that principal can be used also by other documents (about:blank iframes, data: stuff etc), also those should get updated. But better to verify from bholley. He was fighting with .domain not too long ago |
| 14:20 | smaug____ | has tried to stay away from .domain insanity ;) |
| 14:25 | <jochen__> | smart move |
| 14:26 | <annevk> | nox: Firefox does something weird there on copy-and-paste |
| 14:27 | <nox> | annevk: I see. |
| 14:27 | <annevk> | nox: with parenthesis, as the link is in the source, that works fine |
| 14:27 | <annevk> | nox: might want to file a bug and copy dao and valentin |
| 14:27 | <nox> | Shouldn't it work even if the characters are escaped, though? |
| 14:27 | <annevk> | nox: I don't think that's how fragments work, though maybe |
| 14:27 | <nox> | Ok. |
| 14:29 | <annevk> | nox: yeah actually, Firefox should decode |
| 14:29 | <annevk> | https://html.spec.whatwg.org/multipage/browsers.html#the-indicated-part-of-the-document |
| 14:29 | <annevk> | not sure why that is not working |
| 14:30 | <nox> | annevk: Decode what where when? |
| 14:30 | <nox> | annevk: Note that clicking on that link still redirects to forms.html#forms, which I find weird. |
| 14:31 | <annevk> | aah |
| 14:31 | <annevk> | maybe what happens is that the lookup script doesn't decode |
| 14:33 | <annevk> | nox: yeah okay, not sure where to file a bug, probably against html-build or wattsi |
| 14:34 | <annevk> | multipage/fragment-links.js doesn't decode the fragment in the same way that browsers are required to do and therefore gets this wrong |
| 14:34 | <annevk> | however, Firefox escaping that is very curious as well |
| 14:49 | <smaug____> | so FF seems to inherit domain changes to about:blank iframes as I expected. but perhaps you tested that already |
| 15:04 | <miketaylr> | zcorpan: around? |
| 17:04 | <zcorpan> | miketaylr: am now |
| 17:11 | <miketaylr> | zcorpan: i saw your reply to my question -- thanks! |
| 17:11 | <miketaylr> | just leaving another comment now |
| 19:31 | <Domenic> | My hobby: replacing 90s era screenshots https://html.spec.whatwg.org/images/sample-url.png with hand-rolled SVGs https://jsbin.com/cocodi/edit?html,output |
| 19:33 | <miketaylr> | amazing. |
| 19:36 | <nikkibee> | that's cool |
| 19:37 | <nikkibee> | I'm always kinda partial to the blocky look of old screenshots- though the last time I tried using Windows XP I was very frustrated, haha |
| 19:37 | <Domenic> | yeah it is kind of fun history |
| 19:38 | <Domenic> | but this one in particular has broken URLs in it so it's gotta go |
| 19:38 | <annevk> | What is 🗋 and why doesn't it display on my computer |
| 19:38 | <Domenic> | aww |
| 19:38 | <Domenic> | http://www.iemoji.com/view/emoji/1063/new/empty-document |
| 19:39 | <nikkibee> | oh yeah, that doesn't show up for me either |
| 19:39 | <annevk> | That is a nice change though |
| 19:39 | <nikkibee> | broken urls, oh geeze I didn't even think of that. that's a good catch! |
| 19:40 | <nikkibee> | it's kinda messed up how easily historic urls break though |
| 19:41 | <Domenic> | yeppp |
| 19:42 | <Domenic> | annevk: nikkibee: if we can find something else, maybe a globe like Firefox does, we can use that instead. |
| 19:42 | <Domenic> | 🌎 |
| 19:42 | <Domenic> | so colorful :-/ |
| 19:45 | <annevk> | Domenic: Firefox has the info icon |
| 19:45 | <Domenic> | find me a unicode i can use. or a svg path i guess |
| 19:45 | <annevk> | Domenic: we could also not have it as it doesn't really add anything |
| 19:45 | <Domenic> | without it the top bar felt indistinct from the bottom section |
| 19:46 | <Domenic> | woah firefox's actual implementation of <input type=url> + <datalist> is very interesting |
| 19:46 | <Domenic> | it only displays the labels but when you select one it fills in the URL |
| 19:47 | <annevk> | Domenic: ☞ |
| 19:47 | <Domenic> | hah |
| 21:06 | <annevk> | Domenic: so looking at the sortable tables thing again, scope/abbr are definitely only part of HTMLTableHeaderCellElement and have nothing to do with sortable tables |
| 21:07 | <Domenic> | annevk: I am pretty sure they were introduced as part of sortable tables... I also was pretty sure they play into the sorting data model |
| 21:08 | <Domenic> | annevk: the fact remains nobody implements the class split |
| 21:09 | <Domenic> | annevk: yes, scope is used to determine when you click on a th, what sorts |
| 21:10 | <Domenic> | annevk: all of "Forming relationships between data cells and header cells" is sorting |
| 21:10 | <Domenic> | + the whole concept of given header cells "applying" to given tds |
| 21:12 | <annevk> | No that is all from HTML4 |
| 21:12 | <Domenic> | ... weird |
| 21:12 | <Domenic> | i can't find out how else it is used |
| 21:13 | <annevk> | https://www.w3.org/TR/html4/struct/tables.html#h-11.2.6 |
| 21:13 | <annevk> | Forming relationships between data cells and header cells is not sorting, it's just explaining how to read a table |
| 21:13 | <Domenic> | I guess |
| 21:14 | <Domenic> | Just not used by anyone and seems like it's specified in detail way beyond what developers need |
| 21:49 | <annevk> | It's for assistive technology mostly I suppose |
| 21:50 | <annevk> | So the difference btw is that in HTML4 scope/abbr also applied to <td> |
| 21:50 | <annevk> | That was changed |
| 21:57 | <Domenic> | yeah that's what's implemented in browsers it seems |
| 23:15 | <MikeSmith> | Domenic: https://jsbin.com/cocodi/edit?html,output love it ❄️ |
| 23:23 | <MikeSmith> | botie, inform zcorpan about <template><source src="" srcset=""></template> checking, if you mean the errors for the empty values, suppressing those is doable though somewhat significantly more work to implement in the checker than the attribute-is-just-missing case |
| 23:23 | <botie> | will do |
| 23:31 | <MikeSmith> | botie, inform zcorpan abou 「the spec has requirements forelements that are not in a document」I'm not sure what you mean, so please enlighten me further |
| 23:31 | <botie> | will do |
| 23:42 | <MikeSmith> | someday I hope somebody can clue me in on why my Firefox doesn't warn me on quit/close despite the fact I have browser.warnOnQuit, browser.tabs.warnOnClose, and browser.showQuitWarning all set to true |
