| 01:05 | <MikeSmith> | annevk: FYI about the spoofing-https-URLs-and-lock-icon thing in the address bar in Firefox mobile, it turns out there was already a bug open |
| 01:05 | <MikeSmith> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=605206#c41 |
| 01:05 | <MikeSmith> | annevk: though it's already been wontfixed |
| 01:07 | <MikeSmith> | annevk: Mark Finkle is defending the decision to show the title contents in the address bar, but I respectfully disagree. Please comment there if you have anything to add |
| 01:08 | <MikeSmith> | tantek: also take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=605206#c41 please if you have a chance and have any opinion |
| 01:26 | <tantek> | MikeSmith crap that's a long bug thread |
| 01:30 | <tantek> | I'm not sure how to productively contribute. I'm for showing the URL obviously :/ |
| 01:42 | <MikeSmith> | tantek: yeah I'm kinda surprised nobody who works more specifically on web security stuff has commented on that bug yet |
| 01:42 | <MikeSmith> | it seems fairly clear to me that UX is an accident waiting to happen |
| 01:43 | <tantek> | Agreed. |
| 01:43 | <tantek> | What do latest mobile Chrome and mobile Safari do? |
| 01:43 | <tantek> | maybe document those with screenshots? |
| 01:44 | <MikeSmith> | they show the URL and don't show the favicon in the address bar |
| 01:45 | <MikeSmith> | I guess it could help to add screenshots for those, but several of the commenters have already pointed it out and it seems like everybody already realizes that Firefox mobile is the only major browser that's showing the title there |
| 05:23 | <MikeSmith> | reading https://github.com/slightlyoff/ServiceWorker/issues/463#issuecomment-56614984 |
| 05:23 | <MikeSmith> | "The basic issue is that there are caches in Blink which we need to verify are cleared between navigations through different sites which are controlled. A SW which can respond for a font (e.g.), populate a cache, and which might be naively reused on another origin rendering in the same renderer process is Bad News (TM)." |
| 05:28 | <MikeSmith> | still not clear to me at least why that's a critical enough problem to block shipping onfetch |
| 05:29 | <MikeSmith> | also not clear if there's a plan to fix the problem |
| 06:03 | <slightlyoff> | it's not "blocking", it's delaying |
| 06:03 | <slightlyoff> | by one release |
| 06:03 | <slightlyoff> | (6 weeks) |
| 06:04 | <slightlyoff> | and yes, we know how to remediate, but we're being cautious given the incredible power of the feature. |
| 06:04 | <MikeSmith> | slightlyoff: ah ok |
| 06:05 | <MikeSmith> | didn't know it was just one release |
| 06:05 | <slightlyoff> | yeah, apologies for a lack of clarity |
| 06:05 | <slightlyoff> | catching the next train out of the station |
| 06:10 | <MikeSmith> | no worries |
| 06:27 | <terinjokes> | initial 3 issues in |
| 06:27 | <terinjokes> | filling in the rest of the console interface stubs now |
| 06:40 | <MikeSmith> | terinjokes: you're working on a spec for console I guess? |
| 06:41 | <hsivonen> | annevk: I expected to find ISO-8859-1 use in the HTTP impl, but didn't find any |
| 06:42 | <hsivonen> | annevk: note that there's https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Internal_strings?redirectlocale=en-US&redirectslug=XPCOM_string_guide#UTF-16_to_ASCII_converters |
| 06:42 | <hsivonen> | annevk: I saw mailnews core use that in a way that relied on the implementation details... |
| 06:59 | <annevk> | hsivonen: I guess those are used then |
| 06:59 | <annevk> | hsivonen: how can you rely on the details? |
| 07:00 | <annevk> | hsivonen: oh wait, utf-16-to-ascii, is it effectively iso-8859-1? |
| 07:53 | <annevk> | I like how the new URL for HTML is much shorter |
| 07:54 | <annevk> | Hixie_: I added a redirect through .htaccess. But e.g. https://anolis.quuz.org/ is a redirect I configured through the panel. Maybe the trick is to configure secure hosting after you configure the redirect? Might not be worth the effort at this point though. |
| 08:04 | <hsivonen> | annevk: "lossy" means throw away the most significant byte and hope it was zero |
| 08:04 | <annevk> | hsivonen: o_O |
| 08:05 | <hsivonen> | well, you are supposed to do that only when you *know* it's zero |
| 08:06 | <annevk> | So "ASCII to UTF-16 converters" would make perfect sense for HTTP |
| 08:06 | <annevk> | And ByteString |
| 08:06 | <annevk> | "UTF-16 to ASCII converters", not so much |
| 08:13 | <hsivonen> | the XPCOM string conversions from "ASCII" are actually conversions from de jure ISO-8859-1: http://mxr.mozilla.org/mozilla-central/source/xpcom/string/nsUTF8Utils.h#651 |
| 08:15 | <hsivonen> | that is, XPCOM strings allow you to convert between valid UTF-8 and UTF-16 on one hand and allow you to do zero-fillingly inflate from bytes to UTF-16 code units and allow you to discard the high byte of UTF-16 code units |
| 08:23 | <annevk> | http://heycam.github.io/webidl/#es-ByteString is already defined without iso-8859-1, so I guess it's just HTTP that needs fixing somehow |
| 08:32 | <Ms2ger> | Ugh, http://w3c-test.org/resource-timing/test_resource_timing.html is such a mess |
| 08:33 | <annevk> | Hixie_: https://validator.whatwg.org/ has mixed content; posting to validator.nu is also going to be a problem in Chrome I believe as validator.nu is not using TLS |
| 08:36 | <hsivonen> | annevk: would you like me to make validator.nu available via opt-in TLS before I'm ready to make http redirect to https? |
| 08:36 | <annevk> | hsivonen: it might be good if we want to get validator.whatwg.org without mixed content warnings |
| 08:37 | <hsivonen> | hmm. I guess I should get a wildcard |
| 08:37 | <hsivonen> | should not have gone crazy with host names before realizing that one day host names cost money, too |
| 08:37 | <annevk> | Hmm, the WHATWG FAQ contains stuff about polyglot... |
| 08:38 | <annevk> | hsivonen: if you validate yourself with StartSSL you can issue certificates that last for 2 years for about a year |
| 08:39 | <hsivonen> | certs that last 2 years are not cool esp. with the SHA-1 on the horizon |
| 08:39 | <annevk> | hsivonen: it's a SHA-256 cert |
| 08:39 | <hsivonen> | does StartSSL have SHA-2 certs yet? |
| 08:39 | <annevk> | they still need to update their intermediate cert |
| 08:39 | <annevk> | afaict |
| 08:40 | <hsivonen> | I need to figure out if I should get a bunch of single-host certs or a wildcard |
| 08:40 | <hsivonen> | and if I should use StartSSL, Gandi or sslmate |
| 08:41 | <hsivonen> | for wildcards, StartSSL pricing is attractive |
| 08:41 | <hsivonen> | for single-host certs, both Gandi and sllmate are cheaper than a revocation at StartSSL |
| 08:42 | <annevk> | hsivonen: you could also get a single cert covering hsivonen.fi, validator.nu, about.validator.nu... |
| 08:43 | <hsivonen> | annevk: for a reasonable price, only from StartSSL |
| 08:43 | <annevk> | hsivonen: see e.g. Alt Name field of https://testsuite.org/ |
| 08:43 | <annevk> | hsivonen: yes |
| 08:43 | <annevk> | hsivonen: and then if you have to revoke, it's still cheap compared to all the other options afaict |
| 08:43 | <hsivonen> | annevk: that was my thinking in the wildcard case |
| 08:44 | <annevk> | hsivonen: note that you can combine wildcard and Alt Name |
| 08:44 | <hsivonen> | I need to test terminating SSL on a different VM than the one that runs validator.nu |
| 08:45 | <hsivonen> | I don't want the key for hsivonen.fi on the VM that runs validator.nu. especially not on the VM that runs bugzilla.validator.nu |
| 08:46 | <annevk> | Anyone interested in figuring out where these two emails are on the W3C archives of the WHATWG? https://wiki.whatwg.org/wiki/FAQ#The_.3Ctime.3E_element_should_allow_vague_times_.28.22March.22.29_and_times_from_ancient_history_to_be_marked_up |
| 09:14 | <jgraham> | I'm pretty sure the current dev.platform conversation about image-rendering is a case study in the problems with having multiple CSS levels rather than a single document that's always as up-to-date as possible |
| 11:31 | <hsivonen> | Is 。(IDEOGRAPHIC FULL STOP) used only in Japanese or is it also used for something in Chinese or Korean? |
| 11:40 | <MikeSmith> | hsivonen: for Chinese as well but not Korean afaik |
| 11:41 | <hsivonen> | MikeSmith: thanks |
| 11:43 | <annevk> | It's used by IDNA... |
| 11:43 | <annevk> | Well, IDNA2003 and now UTR #46 |
| 11:44 | <hsivonen> | I wonder how likely it is for a Japanese-language email to be Kanji-only with no Hiragana or Katakana |
| 11:45 | <hsivonen> | looking at Japanese texts in general, any non-trivial paragraph seems to include some kana |
| 11:52 | <MikeSmith> | hsivonen: Yeah. it's very unlikely to contain no hiragana. e.g., the verb inflections are all hiragana, and all the prepositions -- of, on, etc. |
| 11:56 | <hsivonen> | MikeSmith: ok. I intend to try to persuade the Thunderbird folks to get rid of outgoing encoding UI |
| 11:57 | <hsivonen> | I don't have my hopes high, but I feel that every time I bring a problem to them and the problem could be avoided by using UTF-8, I should nag them about it |
| 11:57 | <hsivonen> | but there's always Japanese and ISO-2022-JP |
| 11:58 | <hsivonen> | so this time, I'm going to suggest a mechanism that only ever outputs UTF-8 or ISO-2022-JP |
| 11:58 | <hsivonen> | and tries the latter if there's kana |
| 11:59 | <hsivonen> | so now it looks like I need to edit Web Platform Tests in order to land a Gecko patch to comply with a spec |
| 11:59 | <hsivonen> | sigh |
| 12:00 | <hsivonen> | I mean, yay, for Web Platform Tests |
| 12:00 | <hsivonen> | but boo HZ |
| 12:14 | <MikeSmith> | why ever output ISO-2022-JP? |
| 12:15 | <MikeSmith> | and why in particular if there's kana? |
| 12:15 | <MikeSmith> | hsivonen: ↑ |
| 12:29 | <hsivonen> | MikeSmith: lore says that there's doom and gloom is you use a non-ISO-2022-JP encoding for email in Japan, due to email clients on popular feature phones |
| 12:30 | <MikeSmith> | hsivonen: I think that situation has changed considerably in the last 5 years or so |
| 12:30 | <hsivonen> | MikeSmith: apparently Apple change Mail.app to always send UTF-8 in Mavericks and this bothered users in Japan enough that someone developed a hack that restores the ability to send ISO-2022-JP |
| 12:31 | <MikeSmith> | hsivonen: I think the majority of users here now have iphones and android mobiles just like everywhere else |
| 12:31 | <hsivonen> | MikeSmith: I'm going with Google Translate, but you can check out the source: http://sourceforge.jp/projects/letter-fix/ |
| 12:31 | MikeSmith | reads |
| 12:31 | <darobin> | I didn't even know they still had popular feature phones in Japan |
| 12:32 | <hsivonen> | darobin: as noted "lore says", but the LetterFix thing adds credibitily to the lore, unfortunately |
| 12:34 | <MikeSmith> | hsivonen: I think the existence of software like that doesn't imply there's necessarily actually a compelling current need for it |
| 12:34 | <darobin> | hsivonen: agreed, and sadly the project seems to be getting 15-20k page views per month, which seems really high for SourceForge |
| 12:34 | <MikeSmith> | this reminds me of the situation of proliferation of half-width kana here when in fact there's no real need for it |
| 12:36 | <MikeSmith> | there's culturally this kind of fetishistic thing here to cling to quaint old technology way past the time when it's obsolete except mostly in the geek culture |
| 12:37 | <hsivonen> | MikeSmith: do you use UTF-8 for your outgoing Japanese-language email? |
| 12:37 | <MikeSmith> | hsivonen: anyway I recommend talking with Nakano-san and emk if you haven't yet |
| 12:37 | <hsivonen> | MikeSmith: I got the URL from emk, IIRC |
| 12:37 | <MikeSmith> | ah ak |
| 12:37 | <MikeSmith> | hsivonen: yeah I just UTF-8 for outgoing mail in normal clients |
| 12:38 | <hsivonen> | MikeSmith: ok |
| 12:38 | <hsivonen> | anyway, I don't know how real the ISO-2022-JP need it, but it's perceived as a need for sure |
| 12:39 | <MikeSmith> | and of course many people here are just using gmail, and there's been no big problems related to people receiving that |
| 12:39 | <hsivonen> | If catering to the perception allows for UTF-8 for everything else, that's a good deal from my perspective |
| 12:39 | <MikeSmith> | yeah |
| 12:39 | <hsivonen> | since then I don't need to debate ISO-8859-1, ISO-8859-15, ISO-8859-9, TIS-620 and Big5 |
| 12:40 | <hsivonen> | did gmail go UTF-8-only already for outgoing? I thought they hadn't. |
| 12:41 | <MikeSmith> | hsivonen: well as I think you know the main problem case of mail clients that can't handle UTF-8 is with software running on old keitai (non-smartphone) mobiles (which are actually quite a bit more powerful than "feature phones" elsewhere, but anyway...) |
| 12:42 | <MikeSmith> | I don't know what gmail is doing. I guess I should |
| 12:43 | <MikeSmith> | hsivonen: anyway I know for a fact that some mobile operators are using gateways that do transcoding from UTF-8 to ISO-2020-JP for those kind of mobile clients |
| 12:43 | <MikeSmith> | hsivonen: I know because I worked on such systems myself and deployed them |
| 12:43 | <MikeSmith> | although that was, like, 7 or 8 years ago |
| 12:44 | <MikeSmith> | but I can't imagine that that would have abandoned that approach in the mean time |
| 12:45 | <MikeSmith> | anyway I'm sure emk has much better insight in the current situation than I do |
| 12:59 | <zcorpan> | hsivonen: what's HZ? |
| 13:01 | <jgraham> | Oh I thought that might just be me that didn't know :) |
| 13:12 | <MikeSmith> | "If this plea doesn't convince you, I'll notice that although my contract prohibits the bribing of public officials, it does not say anything about fellow developers, and I'm not far off the source of Westvleteren 12. Not implying anything, just a factual observation." |
| 13:20 | <MikeSmith> | hey let's change the Web security model http://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0098.html |
| 13:23 | <MikeSmith> | I guess Ryan Sleevi has given up on trying to comment about that bug/plan |
| 14:02 | <Domenic> | But that message is PGP signed, it must be written by someone with great security knowledge |
| 14:18 | <Ms2ger> | Domenic, ha |
| 14:21 | <wanderview> | JakeA: ping |
| 14:22 | <JakeA> | wanderview: gimmie 5-10mins to do a blog |
| 14:22 | <wanderview> | np... I leave the question and reply when you have time |
| 14:24 | <wanderview> | JakeA: when you have time, does the spec say what to do if cache.delete() is called while the body data is still being streamed off disk for a previous cache.match()? what do you think it should do? |
| 14:26 | <wanderview> | overall it seems the cache spec text should treat body data as a separate async read/write and right now its all wrapped up into a synchronous store into [[RequestToResponseMap]] |
| 14:36 | <JakeA> | wanderview: good point. I guess delete would wait for the read to finish before removing from disk |
| 14:36 | <JakeA> | however, it could remove it from the index sooner |
| 14:36 | <JakeA> | and resolve sooner |
| 14:37 | <wanderview> | right |
| 14:37 | <wanderview> | ok |
| 14:37 | <wanderview> | JakeA: want me to write an issue? |
| 14:37 | <wanderview> | for the spec |
| 14:37 | <JakeA> | Please! |
| 14:37 | <JakeA> | Actually going to look at some github issues now :D |
| 14:37 | <wanderview> | will do... thanks for the sanity check :-) |
| 14:48 | <wanderview> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/470 |
| 14:49 | <JakeA> | wanderview: thanks! Appreciate you've been working the in the dark a bit over the past couple of weeks. |
| 14:50 | <wanderview> | JakeA: np! I've mostly been mired in gecko implementation details... but looking forward to the cache spec changes |
| 14:52 | <wanderview> | I'll be out for 3 weeks starting sometime in the next week for paternity leave, so realistically I won't be able to look at the spec changes until I get back... just FYI |
| 14:52 | <wanderview> | JakeA: ^^^ |
| 14:53 | <JakeA> | wanderview: That probably works out fine. I'm on holiday next week, then away for a couple of conferences. Oh, and congratulations! |
| 14:53 | <wanderview> | thanks! |
| 14:57 | <annevk> | zcorpan: hz-gb-2312 |
| 15:20 | <smaug____> | Domenic: https://github.com/w3c/wake-lock/issues/39#issuecomment-56248024 is surprising |
| 15:20 | <smaug____> | how would one implement [observable] innerHTML (in case we had such ) |
| 15:21 | <Domenic> | smaug____: one wouldn't, for innerHTML |
| 15:21 | <Domenic> | smaug____: because innerHTML is lazily computed, so it wouldn't be simple for innerHTML. |
| 15:21 | <smaug____> | exactly |
| 15:21 | <smaug____> | many other properties are also lazily computed |
| 15:22 | <Domenic> | yep |
| 15:22 | <Domenic> | the general wiring is easy though, and it's easy for things like orientation that don't need to be lazily computed |
| 15:22 | <smaug____> | so I wouldn't add [observable], since it increases inconsistency in the platform |
| 15:22 | <jgraham> | Which properties are lazily computed is currently something of an implementation detail |
| 15:23 | <smaug____> | indeed |
| 15:23 | <annevk> | smaug____: are you arguing against Object.observe() in general? |
| 15:23 | <Domenic> | The fact that some properties are observable and some aren't is just a fact of how Object.observe works |
| 15:23 | <jgraham> | I'm not sure we want to back ouselves into a corner here by forcing some properties ot have eager semantics |
| 15:23 | <annevk> | smaug____: because once that's there, it's kind of a given that you will... what Domenic said |
| 15:23 | <smaug____> | jgraham: indeed. lazyness is good for performance |
| 15:24 | <Domenic> | jgraham: we are already in that corner for any properties that have corresponding propertynamechanged events |
| 15:24 | <Domenic> | which again are the only things we are considering making observable |
| 15:24 | <smaug____> | why don't we just use events then? |
| 15:24 | <annevk> | because we now have an observer mechanism |
| 15:24 | smaug____ | is not at all sure Object.observe is a good thing |
| 15:24 | <annevk> | why don't we use callbacks? because we have promises |
| 15:25 | <annevk> | smaug____: well, you might want to argue that over in TC39 |
| 15:25 | <jgraham> | annevk: That argument works both ways, so I'm not sure it proves anything |
| 15:25 | <smaug____> | annevk: that observer mechanism isn't too good |
| 15:25 | <smaug____> | so just saying we have a observer mechanism, doesn't mean we should use it |
| 15:29 | <smaug____> | (@mozilla in the API design guidelines we do mention consistency as a goal. use of [observable] would be a violation to that, IMHO. ) |
| 15:30 | <annevk> | smaug____: why? |
| 15:30 | <smaug____> | why is one property observable but not some other? |
| 15:31 | <smaug____> | if we could make all properties observable, then fine |
| 15:31 | <smaug____> | but we can't |
| 15:31 | <annevk> | why is one property writeable but not some other? |
| 15:32 | <jgraham> | I wonder if there was an alternate design where you could get a ntification that something had changed, but only get a way of computing the new value, rather than the new value itself |
| 15:32 | <jgraham> | annevk: The semantic of being read-only seems quite intuitive. The semantic of being unobservable seems much less so. |
| 15:32 | <smaug____> | exactly |
| 15:33 | <annevk> | *shrug* |
| 15:33 | <jgraham> | One is "this reflects something in the environment" and the other is "this changes, but you aren't allowed to know when" |
| 15:38 | <annevk> | jgraham: if we encounter some broken web platform tests in Gecko, should I copy you and ask about it? |
| 15:38 | <jgraham> | annevk: Yeah, sure |
| 15:39 | <smaug____> | ( It is also unclear to me how Object.observe would observe anything which is implementation detail behind some getter/setter functions. Trying to find if the draft of Object.observe says anything about such case ) |
| 15:40 | <annevk> | Somewhat tempted to reply to Domenic's tweet with "Or just join us on IRC: link" |
| 15:41 | <Domenic> | hahaha |
| 15:52 | <jgraham> | Someone tell Google that it's 2014 and not supporting SVG images in docs isn't acceptable |
| 15:52 | <jgraham> | Especially since the preview will load them OK and then it will error when you actually try to insert them |
| 15:53 | <Domenic> | SVG support all over the web is bad :( |
| 15:53 | <Domenic> | e.g. should be able to use them for avatars but you can't do that anywhere |
| 16:43 | <Hixie_> | annevk: figuring out what whatwg e-mails are in lists.w3.org is easy. Load up the whatwg archive link in a browser that hasn't seen the STS header, copy and paste the first non-quoted line of the e-mail into google, and find the w3.org link. |
| 16:47 | <pdr> | A big reason why there is no way SVG images would be allowed for avatars is SVG completely ignores the hard problems of security. As a result, the working group shot itself in the foot because it's not possible to use svg as avatars :/ |
| 16:49 | <jgraham> | Hmm? What makes <svg> in <img> insecure? |
| 16:51 | <pdr> | jgraham, scripts can run and subresources can be loaded in images according to the spec (about half the browsers disable these though). |
| 16:52 | <jgraham> | I'm pretty sure everyone disables scripting in <img> |
| 16:52 | <jgraham> | And I'm pretty sure it would be wrong per spec to do otherwise |
| 16:52 | <pdr> | they do. As far as I know it's not in the spec. IE allows for loading of subresources even today. |
| 16:56 | <jgraham> | Well there's nothing in HTML that would allow creating a browsing context that could run scripts, at least |
| 16:58 | <pdr> | Can you explain a little more? |
| 16:58 | <Sample> | I was reading over the constraint validation API and it seems to me there is a serious gap in that, though the API provides a .checkValidity() method, there is absolutely no programmatic means with which to fire what the specs outline as "interactive validation". |
| 16:58 | <Sample> | Not only unable to through a new API method, but not even triggering via firing an event (like submit) |
| 16:59 | <Sample> | It seems to only occur in this inaccessible nebulous area triggered by direct user interaction with the page |
| 17:00 | <Sample> | only as an inaccessible step within the form submission algorithm |
| 17:05 | <TabAtkins> | jgraham: Link to the image-rendering discussion? (Also, agreed, I'm planning on devolving level 4 to a delta spec; I've already pulled image-rendering into level 3, and we'll publish in a few weeks after review.) |
| 17:06 | <Domenic> | delta specs :-/ |
| 17:06 | <Hixie_> | Sample: form.reportValidity() does that, no? what am i missing? |
| 17:07 | <Sample> | Hixie_: I'll check |
| 17:07 | <jgraham> | pdr: Normally you need a browsing context to run scripts, and loading an image doesn't create one. But I agree that it's not really clear what should happen in this case |
| 17:08 | <TabAtkins> | Domenic: Only as experimental. As it becomes mature, it enters its chrysalis, and emerges as a full spec. |
| 17:08 | <TabAtkins> | Domenic: Right now, I have to port any changes in the common text between Images 3 and Images 4 to both, and I don't actually do that, so one or the other gets behind. |
| 17:08 | <jgraham> | TabAtkins: https://groups.google.com/forum/#!topic/mozilla.dev.platform/0KYBjCdUMJw Mostly the confusion about which spec says what |
| 17:09 | <Domenic> | TabAtkins: ah that makes perfect sense |
| 17:09 | <jgraham> | Which seems to be the problem you're describing in fact |
| 17:10 | <Sample> | Hixie_: I don't seem to have that method in Chrome 37 however the specs for that say it returns false and "informs the user". Perhaps that implies it triggers the "interactive validation" and fills the gap considered above |
| 17:11 | <Hixie_> | Sample: the spec never implies anything, it's always explicit |
| 17:11 | <Hixie_> | Sample: where are you reading that it "returns false and informs the user"? |
| 17:12 | <Sample> | Hixie_: https://html.spec.whatwg.org/multipage/forms.html#the-constraint-validation-api:dom-cva-reportvalidity |
| 17:13 | <Sample> | also #the-form-element:dom-form-reportvalidity-2 |
| 17:14 | <Sample> | Hixie_: Ah, it does say on that page that reportValidity() "must interactively validate the constraints". Thanks, that's exactly what I believe was missing |
| 17:14 | <Sample> | believed* |
| 17:14 | <Hixie_> | cool |
| 17:16 | <annevk> | jgraham: where do I find encoding in https://github.com/w3c/web-platform-tests |
| 17:18 | <jgraham> | annevk: If you want a directory for the encoding spec you need to create one |
| 17:19 | <jgraham> | hsivonen's failures are in https://github.com/w3c/web-platform-tests/blob/master/dom/nodes/Document-characterSet-normalization.html |
| 17:20 | <annevk> | okay |
| 17:22 | <annevk> | jgraham: is there an easy way to create PR locally? I'm so bad at GitHub :-( |
| 17:23 | <jgraham> | Well you can create a branch locally and push it. Creating the actual PR locally isn't so easy |
| 17:23 | <jgraham> | (maybe the GH UI allows that, or there are various things you can download, but I just use the website) |
| 17:24 | <annevk> | creating a branch I can do |
| 17:24 | <annevk> | let's see how far I get |
| 17:38 | <annevk> | jgraham: the changes I'm making are not showing up in the branch... |
| 17:47 | <annevk> | jgraham: that is, git diff shows changes, but the GitHub client doesn't |
| 17:53 | <Hixie_> | anyone got IE handy? |
| 17:53 | <Hixie_> | got some focusing tests to check |
| 17:55 | annevk | tries again |
| 17:55 | <Hixie_> | specifically, the three tests below, which are run as follows: 1. click in the "rendered view" outside the button, try using arrow keys to see what is focused. Click the button, try using arrow keys to see what is focused. |
| 17:55 | <Hixie_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3182 |
| 17:55 | <Hixie_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3183 |
| 17:55 | <Hixie_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3204 |
| 17:57 | <Hixie_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3206 |
| 18:03 | <jgraham> | annevk: Did you commit them? |
| 18:10 | <Hixie_> | any mozilla people with IE? without IE, firefox is alone in the behaviour above, so i'm likely to move away from it. But if IE does the same thing, that would swing me back. |
| 18:34 | <wanderview> | Hixie_: I have IE up on your test... it scrolls outer area, click button, then scrolls inner area |
| 18:34 | <wanderview> | not sure what behavior you were asking about explicitly, though |
| 18:34 | <Hixie_> | cool |
| 18:34 | <Hixie_> | there's four tests |
| 18:34 | <Hixie_> | which one did you start with? |
| 18:34 | <wanderview> | Hixie_: going in order... tried the first 2 so far... same results |
| 18:35 | <Hixie_> | so you click above the button, arrow keys scroll the button up and down, then click the "Focus Child Frame" button, then arrow keys scroll the "softwar" inner-most iframe? |
| 18:35 | <wanderview> | Hixie_: yes... the fourth test always scrolls outer frame |
| 18:35 | <wanderview> | this is IE11 |
| 18:35 | <Hixie_> | and the other three scroll the inner frame? |
| 18:36 | <wanderview> | yes, the first three scroll the inner frame after clicking the button |
| 18:42 | <Hixie_> | wanderview: cool, thanks! |
| 18:42 | <wanderview> | np |
| 18:48 | <Hixie_> | wanderview: if i can bother you for just one more second... what does IE do on these? |
| 18:48 | <Hixie_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3208 |
| 18:48 | <Hixie_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3209 |
| 18:48 | <Hixie_> | wanderview: (same test, though this time if it has a focus ring around a link, that's more relevant than whether the inner frame scrolls) |
| 18:50 | <wanderview> | Hixie_: the first one forces the scroll position on the inner frame when the button is pushed... I don't see a focus ring... the second one allows me to scroll inner frame, but does not change its scroll position automatically |
| 18:50 | <Hixie_> | wow, really |
| 18:50 | <Hixie_> | fascinating |
| 18:50 | <Hixie_> | what happens if you hit enter after clicking the button? |
| 18:51 | <wanderview> | nothing as far as I can tell |
| 18:51 | <Hixie_> | huh |
| 18:51 | <Hixie_> | not even on 3208? |
| 18:51 | <annevk> | jgraham: no changes were listed, but I think I did something wrong, will try again later |
| 18:51 | <wanderview> | Hixie_: I take it back |
| 18:52 | <wanderview> | Hixie_: the second one forces scroll position to top of inner frame |
| 18:52 | <wanderview> | Hixie_: so if I manually scroll down and push button, then it jumps back to top of inner frame |
| 18:52 | <Hixie_> | huh |
| 18:52 | <Hixie_> | cool, thanks |
| 18:52 | <wanderview> | np |
| 18:52 | <Hixie_> | not sure what to make of that exactly |
| 18:53 | <Hixie_> | but then again that's often my reaction to what IE does |
| 18:55 | <Hixie_> | i wish bugzilla had a way to select bugs that had no unresolved dependencies |
| 18:55 | <Hixie_> | (along with other criteria) |
| 19:04 | <Hixie_> | foolip: any further thoughts on https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 ? |
| 19:17 | <Hixie_> | cabanier: yt? |
| 19:19 | <Hixie_> | roc: yt? |
| 19:24 | <roc> | yes |
| 19:24 | <Hixie_> | so i'm looking at shadows |
| 19:25 | <Hixie_> | years ago we talked about changing how shadows in canvas work |
| 19:25 | <Hixie_> | looks like nobody did, so i'm taking the note out |
| 19:25 | <Hixie_> | but in looking at this i found another thing that's odd |
| 19:26 | <Hixie_> | per the spec, shadows and their corresponding shapes are composited separately, so if the globalCompositeOperation is 'over', you'd expect to not see any shadows |
| 19:26 | <Hixie_> | but you do |
| 19:26 | <Hixie_> | are the shapes and their shadows composited onto a scratch bitmap before being together composited onto the canvas, or something? |
| 19:27 | <Hixie_> | if i set the gCO to 'xor', i clearly see the shadow being xored with the shape |
| 19:31 | <Hixie_> | oh, i guess with xor there's no difference... |
| 19:32 | <Hixie_> | given the way xor works... |
| 19:32 | <Hixie_> | roc: so maybe it's compositing with the operator onto a scratch bitmap then compositing that all at once onto canvas with the operator again? |
| 19:37 | <roc> | what testcase are you looking at, on what platform? |
| 19:39 | <Hixie_> | i'm just doodling with my canvas console, but here: http://goo.gl/CfCQSA |
| 19:39 | <Hixie_> | i don't really understand why there's black in firefox |
| 19:41 | <Hixie_> | but in theory the presence of blue indicates that the shadow and the shape are composited together before being put on the canvas |
| 19:41 | <Hixie_> | although... |
| 19:42 | <Hixie_> | if you change the first 100 to 200 i can't explain why the teal box extends out of the blue one... |
| 19:42 | <Hixie_> | i don't understand what's going on here |
| 19:44 | <Hixie_> | roc: platform was mac |
| 19:59 | <roc> | we're pretty much just passing through to CoreGraphics to draw the object with shadow |
| 19:59 | <roc> | and I don't know what CG is supposed to do, nor what it actually does ... no Mac here |
| 20:01 | <Hixie_> | chrome and firefox act very different on these two tests on mac, and i can't explain either: http://goo.gl/LVUZ1r http://goo.gl/V2d3C7 |
| 20:03 | <Hixie_> | safari on mac does what the spec says, which doesn't match the other two browsers |
| 20:22 | <annevk> | jgraham: I think I made it work: https://github.com/w3c/web-platform-tests/pull/1261 |
| 20:22 | <annevk> | hsivonen: ^ |
| 20:23 | <annevk> | jgraham: incidentally, would be nice if someone deleted old branches |
| 20:36 | <jamesr__> | coregraphics applies the composite op roughly speaking "per pixel" |
| 20:36 | <jamesr__> | so it applies to whatever pixels it decides needs to be touched for that draw |
| 20:36 | <jamesr__> | which for things with ill-defined shapes is pretty unpredictable |
| 22:30 | <Hixie_> | annevk: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25099 |
| 22:30 | <SimonSapin> | The Unicode 2.0 spec is a bunch of raster images :/ (Looking into the history of UTF-16 and surrogates.) |
| 22:31 | <SimonSapin> | it also claims in the very first sentence to be a fixed-width encoding |
| 22:35 | <Hixie_> | it was, then |
| 22:35 | <Hixie_> | Unicode 2.0 was a long time ago! |
| 22:36 | <Hixie_> | or wait, was 2.0 when they introduced surrogates? |
| 23:08 | <karlcow> | https://www.mozilla.org/security/announce/2014/mfsa2014-73.html |
| 23:25 | <SimonSapin> | Hixie_: yes, and UTF-16 |
| 23:25 | <SimonSapin> | but no non-BMP code point was assigned until 3.1 |
| 23:27 | <SimonSapin> | 2.0 still talks about 16 bit things being the fundamental things in Unicode. So yeah it’s a fixed width of these things. And oh by the way some abstract characters are encoded with two things |
| 23:28 | <SimonSapin> | "code value" is the name of things |
| 23:31 | <SimonSapin> | every kind of thing seemed to have many names at the time |
| 23:31 | <SimonSapin> | multiple in Unicode, and then some more in ISO/IEC 10646 |
| 23:49 | <SimonSapin> | annevk: did you know that DoCoMo, KDDI, and SoftBank each have their own variant of Shift-JIS with different mappings for Emoji? What does the Encoding spec do with these? |