| 01:39 | <MikeSmith> | https://github.com/keeganstreet/compatibility-reporter looks promising |
| 02:12 | <jyasskin> | TabAtkins: Awesome, thanks! |
| 04:47 | <Guest_84857> | allah is doing |
| 04:47 | <botie> | i already had it that way, Guest_84857. |
| 05:53 | <MikeSmith> | annevk: please comment if I got anything wrong at https://stackoverflow.com/questions/39109446/cors-preflight-not-sending-credentials-server-wants-to-deny-unauthenticated-use/39113781#39113781 |
| 05:59 | <annevk> | MikeSmith: you're correct |
| 06:04 | <MikeSmith> | super, thanks |
| 06:34 | <hsivonen> | would anyone with a Mac and the latest WebKit nightly care to load the two test cases at https://hsivonen.com/test/moz/replacement/ and report if they look different? |
| 06:35 | <MikeSmith> | hsivonen: hi will do right now |
| 06:35 | <hsivonen> | (Firefox and Chrome comply with the spec on those test cases. Edge does not.) |
| 06:37 | <MikeSmith> | https://hsivonen.com/test/moz/replacement/iso-2022-kr.htm shows replacement character |
| 06:37 | <MikeSmith> | but https://hsivonen.com/test/moz/replacement/replacement.htm does not |
| 06:38 | <MikeSmith> | instead it says, “This is not visible if "replacement" is a label for the replacement encoding.” |
| 06:38 | <hsivonen> | MikeSmith: thank you. So WebKit complies, too. |
| 06:38 | <MikeSmith> | cool |
| 06:41 | <annevk> | I get the same results in Safari Technology Preview |
| 06:42 | <annevk> | Safari fails (in the "not supporting it" way) |
| 06:43 | <hsivonen> | annevk: i.e. complies with the spec |
| 06:49 | <annevk> | hsivonen: yeah |
| 06:49 | <annevk> | hsivonen: which is strange since cdumez said something else |
| 07:19 | <hsivonen> | annevk: test cases > developer statements |
| 08:27 | <MikeSmith> | any of y’all attending TPAC in Lisbon, I’m asked to remind you to please register at https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login |
| 08:28 | <annevk> | MikeSmith: I think I did |
| 08:28 | <annevk> | MikeSmith: might have even requested observer status |
| 08:47 | <MikeSmith> | annevk: yup thanks the system shows you’re registered |
| 09:21 | <MikeSmith> | anybody know if we have any spec that defines parsing for a monetary value? |
| 09:23 | <MikeSmith> | https://w3c.github.io/browser-payment-api/#dfn-value attempts to specify requirements but fails do actually define processing, including not defining exactly what a UA must do when a value does not match the requirements (e.g., throw something) |
| 09:27 | <annevk> | MikeSmith: ECMA-402? |
| 09:27 | MikeSmith | looks |
| 09:27 | <MikeSmith> | oh, i18n API |
| 09:27 | <MikeSmith> | will look, thanks |
| 09:38 | <MikeSmith> | annevk: so in the case we don’t need to support localized currency representations, because this is just for the value of the field for this in the DOM |
| 09:38 | <MikeSmith> | well |
| 09:39 | <MikeSmith> | not true |
| 09:39 | <annevk> | oh |
| 09:39 | <MikeSmith> | rather it is about what value the app’s JS can use in the constructor |
| 09:40 | <MikeSmith> | but I guess the expectation is that the app (merchant site JS) would need to convert any localized value into the required format |
| 09:41 | <MikeSmith> | but hmm maybe the constructor should actually accept localized currency representation, I dunno, will ask Richard |
| 09:41 | <annevk> | MikeSmith: I don't think we have a parser for decimal numbers |
| 09:41 | <annevk> | MikeSmith: if that is what this is looking for |
| 09:42 | <MikeSmith> | well now that I look at it I think we do not need one |
| 09:42 | <annevk> | MikeSmith: that note has a "should" requirement |
| 09:42 | <MikeSmith> | can we not just make it a valid floating-point number? |
| 09:42 | <MikeSmith> | yeah for the regex? |
| 09:43 | <MikeSmith> | I think it is nice that it specifies a regex but we don't |
| 09:43 | <annevk> | MikeSmith: I think floating points are problematic with rounding and such |
| 09:43 | <MikeSmith> | ... ned it |
| 09:43 | <MikeSmith> | oh |
| 09:43 | <annevk> | MikeSmith: and they allow "e" and "E" |
| 09:43 | <MikeSmith> | yeah I know but I was thinking that should not be a problem |
| 09:44 | <MikeSmith> | I mean nobody is going to input values that way even if we allowed it |
| 09:44 | <annevk> | MikeSmith: there's something off with precision with floating points which make them unsuitable for money |
| 09:44 | <MikeSmith> | ah OK |
| 09:44 | <annevk> | MikeSmith: representing this as a string though is a rather ugly workaround :/ |
| 09:45 | <MikeSmith> | well I just I am just being lazy, because I could write the parsing algorithm in less time than it has taken me to ask about it… |
| 09:46 | <annevk> | I dunno about that, decimal numbers is its whole own world in computer science aiui |
| 09:47 | <MikeSmith> | well at least if I limit it to what that regex alllows |
| 09:48 | <annevk> | I wonder if https://w3c.github.io/browser-payment-api/#paymentaddress-interface matches equivalent definitions in HTML |
| 09:50 | <MikeSmith> | I do not know |
| 09:51 | <MikeSmith> | Zach Koch who write it is certainly aware of the HTML defintions and autofill/autocomplete stuff |
| 09:58 | <annevk> | HTML does use a valid-floating point number for transaction-amount |
| 09:58 | <MikeSmith> | yeah I just saw that |
| 09:59 | <MikeSmith> | so now I wonder if we could get by with that too |
| 09:59 | <MikeSmith> | for that payment request API I mean |
| 10:02 | <annevk> | Worth raising an issue on at least |
| 10:02 | <tobie> | MikeSmith: things to watch out for: currency with > 2 decimal points, any kind of math done on anything but cents, localization issues around separators (such as "," being a decimal point in french and a thousands separator in english), grouping by other things than thousands in certain currencies/localizations. |
| 10:03 | <annevk> | If we're going to have a new number primitive that should probably have some broader discussion |
| 10:04 | <annevk> | tobie: the main issue is the less-than-cent math |
| 10:04 | <annevk> | I suspect, localization doesn't really come into play at the API level, that's just a number formatting problem for the template |
| 10:06 | <annevk> | MikeSmith: I'll file the "should" in note issue |
| 10:06 | <tobie> | well then, you're relying on developers to do proper conversion between user input and that format. I can see how that's going to work out. |
| 10:07 | <tobie> | way to promote TDD. :) |
| 10:07 | <MikeSmith> | annevk: thanks |
| 10:07 | <MikeSmith> | tobie: yeah I think this needs more work |
| 10:09 | <annevk> | tobie: test-driven-development? |
| 10:09 | <annevk> | tobie: but anyway, there's no UX component to this API, so they'll indeed leave that up to websites |
| 10:10 | <annevk> | tobie: however, mostly those websites already need to deal with that kind of thing I assume in order to display prices and charge credit cards accurately |
| 10:11 | <MikeSmith> | right |
| 10:12 | <MikeSmith> | but that said the point of this whole feature is to make payments experience on the Web easier for users |
| 10:12 | <MikeSmith> | and along with that, easier for merchants too, actually |
| 10:12 | <MikeSmith> | in that they should be able to eliminate a lot of custom code |
| 10:15 | <tobie> | There must exist some inter bank standardized Ido format for this stuff. |
| 10:15 | <tobie> | s/Ido/ISO/ |
| 10:17 | <MikeSmith> | yeah http://www.iso.org/iso/home/standards/currency_codes.htm |
| 10:17 | <MikeSmith> | oh, not that |
| 10:17 | <MikeSmith> | that is only for the currency codes I guess |
| 10:37 | <MikeSmith> | to me https://twitter.com/thomaswilburn/status/768390017232220161 is an example of the consequences of setting the wrong expectations for non-implementor readers of specs |
| 10:39 | <tobie> | MikeSmith: seems currency formats should be in ISO 20022 if anywhere. |
| 10:40 | <MikeSmith> | ah yeah |
| 10:41 | <tobie> | https://www.iso20022.org/ |
| 10:41 | tobie | wishes MikeSmith good luck. |
| 10:41 | <MikeSmith> | heh |
| 10:41 | <MikeSmith> | yeah ISO 20022 is referenced by other (unimplemented) Payments WG drafts but just not by the Payment Request API spec (which is the only one actually implemented so far) |
| 10:42 | <tobie> | referencing ISO 20022 seems to be about as precise as referencing "the Interwebs" |
| 10:42 | <MikeSmith> | haha |
| 10:43 | <MikeSmith> | yeah plus with anything ISO there is the fact you can only read the specs if you pay |
| 10:44 | <tobie> | well, with ISO 20022, you get to see a video with pigs. |
| 10:44 | <MikeSmith> | heh |
| 10:44 | <MikeSmith> | well that is a genuine plus |
| 10:44 | <MikeSmith> | oh hey https://www.iso20022.org/standardsrepository/public/wqt/Description/mx/dico/datatypes/_YX4O9tp-Ed-ak6NoX_4Aeg_-836081793 |
| 10:44 | tobie | redacts a bunch of comments he doesn't want logged somewhere. |
| 10:45 | <MikeSmith> | The number of fractional digits (or minor unit of currency) must comply with ISO 4217. Note: The decimal separator is a dot. |
| 10:45 | <MikeSmith> | (quoting above) |
| 10:45 | <MikeSmith> | so I guess http://www.iso.org/iso/home/standards/currency_codes.htm does define the value format |
| 10:46 | <tobie> | it's the "exponent" thing, I guess. |
| 10:48 | <tobie> | MikeSmith: https://en.wikipedia.org/wiki/ISO_4217#Treatment_of_minor_currency_units_.28the_.22exponent.22.29 |
| 10:48 | MikeSmith | reads |
| 10:49 | <MikeSmith> | oh christ |
| 10:49 | <tobie> | what? Mauritanian khoums? |
| 10:53 | <MikeSmith> | Japan’s currency makes the most sense of all |
| 10:53 | <MikeSmith> | I realize now |
| 10:54 | <MikeSmith> | we can just always use integers |
| 10:54 | <MikeSmith> | I think Chinese yuan is like that too |
| 10:55 | <tobie> | Well, all you need is massive inflation and you're good. |
| 10:56 | <MikeSmith> | hah |
| 10:57 | <tantek> | MikeSmith: actually, I'm seeing one yen == one cent today, a dollar makes more cents. |
| 10:57 | <MikeSmith> | oh man |
| 10:58 | <MikeSmith> | for that kind of pun you get some serious karmic dust |
| 11:31 | <smaug____> | who are @asajeffrey and @connorgbrewster ? |
| 11:31 | smaug____ | is reading the bug about session history |
| 11:31 | <smaug____> | hmm, did I meet them, or one of them in London |
| 11:47 | <nox> | smaug____: Ah ah. |
| 11:48 | <nox> | smaug____: They both work on Servo, the former is a MoCo employee, the second a student working with us. |
| 11:48 | <smaug____> | right |
| 11:49 | <smaug____> | that servo meeting in london lead to that spec bug |
| 14:20 | <annevk> | MikeSmith: the "Fetch" component of the "WHATWG" product can now be closed off |
| 14:20 | <annevk> | MikeSmith: all bugs are resolved in one way or another |
| 14:26 | <tantek> | annevk congrats on reaching CR! ;) |
| 14:29 | <annevk> | tantek: CR? |
| 14:30 | <tantek> | annevk: hence the ;) |
| 14:30 | <annevk> | oh, in reference to Fetch |
| 14:30 | <annevk> | I thought the W3C published something |
| 14:30 | <tantek> | no |
| 14:31 | <tantek> | more seriously, congrats on doing such a good job on Fetch that it's normatively referenced by at least one W3C Recommendation, and at least 2 CRs |
| 14:31 | <smaug____> | is speculative loading during parsing part of the spec. I mean, would it be against the spec to not do that? |
| 14:31 | <tantek> | (some of us have been working on making that more acceptable (normatively referencing WHATWG specs) here @W3CAB level) |
| 14:32 | <annevk> | "I believe @slightlyoff has expressed the thought that having ARIA roles for the complete set of HTML elements would be a good thing." |
| 14:32 | <annevk> | smaug____: it's not specced either way |
| 14:32 | <smaug____> | ok, thanks |
| 14:33 | <smaug____> | I'm thinking some changes to background tabs |
| 14:33 | <annevk> | smaug____: which is a known problem, but we don't have folks to help out |
| 14:35 | <tantek> | annevk say what?!? "ARIA roles for the complete set of HTML elements would be a good thing"?!? |
| 14:35 | <tantek> | uh by what evidence would that be a good thing? |
| 14:35 | <annevk> | maybe it is, maybe it isn't |
| 14:35 | <annevk> | I was just surprised that the comment only contained that and no actual information |
| 17:29 | <Domenic> | It seems like a good thing to me |
| 17:29 | <Domenic> | Otherwise you cannot create custom elements that screen readers announce as a ____ where ____ is like a bunch of different things |
| 17:33 | <ShakespeareFan00> | Hello again |
| 17:33 | <ShakespeareFan00> | The other night I was trying to explain something and failed |
| 17:34 | <ShakespeareFan00> | So is there someone here who has some time to assist in communicationg a problemm in a way that CAN be understood more clearly? |
| 17:34 | <ShakespeareFan00> | (Namely that you can't do sidenotes in HTML) |
| 17:35 | <ShakespeareFan00> | (And that the currently suggested approaches would indicate that a change in the spec maybe required.) |
| 17:38 | <nox> | Global interfaces can have static attributes, right? |
| 17:38 | <nox> | (And static methods.) |
| 17:43 | <ShakespeareFan00> | Apologies can't do "sidenotes" cleanly |
| 17:44 | <astearns> | ShakespeareFan00: you might have better luck adding to the discussion here https://discourse.wicg.io/t/explicit-footnote-or-expansion-links/1256 and/or here https://discourse.wicg.io/t/position-an-element-relatively-to-another-element-from-anywhere-in-the-dom/968 |
| 17:45 | <ShakespeareFan00> | astearrns: Can we take this to private measge? |
| 17:45 | <ShakespeareFan00> | The use case was rather specfic, and thus off topic generally here |
| 17:49 | <Domenic> | nox: that seems probably true |
| 17:49 | <ShakespeareFan00> | hi Doenic |
| 17:49 | <ShakespeareFan00> | Sorry about last night |
| 17:49 | <ShakespeareFan00> | Domenic: sorry about last night... |
| 17:50 | <ShakespeareFan00> | I had a little think about what you said, and will post my own proposal soon. |
| 17:54 | <ShakespeareFan00> | asterans: Thanks |
| 17:54 | <ShakespeareFan00> | :) |
| 17:54 | <ShakespeareFan00> | Also posibly going to suggest something relationg to how transform: get handled |
| 17:54 | <ShakespeareFan00> | :) |
| 18:36 | <ShakespeareFan00> | https://discourse.wicg.io/t/how-should-sidenotes-inside-inline-content-be-handled/1673 - I'm not expecting a response soon :) |
| 18:36 | ShakespeareFan00 | out |
| 18:50 | <benjamingr_> | So, dumb question - where does the DOM spec actually define what a 'long' is? |
| 18:50 | <benjamingr_> | Or a 'short' ? |
| 19:06 | <Domenic> | benjamingr_: that's Web IDL |
| 19:06 | <Domenic> | benjamingr_: https://heycam.github.io/webidl/#idl-long + https://heycam.github.io/webidl/#es-long |
| 19:06 | <benjamingr_> | Thanks <3 |
| 19:07 | <Domenic> | I've argued these should link to their definitions, but I think people assume they're very basic. |
| 19:07 | <Domenic> | https://github.com/tabatkins/bikeshed/issues/458 |
| 19:34 | <jyasskin> | http://www.memegen.com/meme/l90r0j |
| 19:46 | <gsnedders> | jyasskin: you will be a cross-reference. |
| 23:34 | <MikeSmith> | annevk: Fetch component of W3C bugzilla is already disabled for new bugs |
| 23:34 | <MikeSmith> | annevk: so I don’t think there is anything more to do |