freenode :: #whatwg

16 Feb 2017
00:00smaugI'm not sure that is too vague, but "relative to the origin of the padding edge of the target node"
00:01smaugwhen is the calculation done
00:02smaugmy interpretation is that there shouldn't be any caching, so when offset* is accessed, "relative to the origin of the padding edge of the target node" should be recalculated
01:00foolipyeah, that would make sense
01:00foolipto require it to be calculated at any specific time would mean that it has to be calculated even if not later used, so that wouldn't be great either
05:46MikeSmiththe upvote/downvote pile-on pattern in https://github.com/gpuweb/admin/issues/1 is.. interesting
05:49MikeSmithgithub should add buttons with rage-comics emoji
05:53annevkHmm, Chrome decides to communicate now that they don't want to actually implement trailer()
05:53annevkThanks for letting me work out all the details fir st I guess
06:07foolipannevk: what's trailer()?
06:07fooliphttps://github.com/whatwg/fetch/issues/34?
06:13annevkfoolip: oops, yeah, an attribute: https://fetch.spec.whatwg.org/#dom-response-trailer
06:15annevkfoolip: I mean, Chrome raised the issue, Google infrastructure folks wants the feature, Chrome devrel (or is igrigorik an engineer?) advocated for the feature, Chrome engineers helped review the feature before it landed in the Fetch standard
06:15annevkfoolip: and now some of the very same folks are suggesting to wontfix it the moment I file the bug report
06:15annevkI mean, it's fine, it's only a couple days at most of lost work, but still
06:16foolipigrigorik is on DevRel, yes
06:17foolipseems like rsleevi was quite clearly opposed all along, but that nobody else on Chrome worked out the situation with him? (just skimming the thread)
06:18annevkfoolip: I would have expected a "we'll never implement" after https://github.com/whatwg/fetch/issues/34#issuecomment-235318684
06:18annevkfoolip: instead three Googlers help review https://github.com/whatwg/fetch/pull/344
06:22foolipannevk: I've commented on https://bugs.chromium.org/p/chromium/issues/detail?id=691599#c4
06:24foolipmkwst_: you seem like the perfect person to tell me what I should think about trailers and exposing them to the web. what are my thoughts?
08:31annevkhsivonen: did you see the issue I filed on the encoding detector in Chrome?
08:31annevkhsivonen: I'll study it later today and maybe comment
08:31annevkhsivonen: been some follow-up overnight apparently
10:02JakeAwanderview: ah, yeah, the SW parts haven't landed yet. I'll chase it
10:31zcorpanannevk: i checked the stackoverflow threads, and indeed it seems a lot people are running in to this issue, and the workarounds seem pretty messy... the least messy is maybe removing disabled onsubmit and adding it again after, but that results in a flash-of-enabled-controls...
10:31annevkzcorpan: it's also a rather trivial change to the processing algorithm, just need to decide on how to expose it
10:32annevkzcorpan: one thing that seemed rather nice to me was disabled="submit", but the API-side of that would be less clean
10:32zcorpanyeah i think we should have a new attribute
10:33zcorpanbut "anyway" is not clear what it's referring to
10:33annevkzcorpan: I'm in favor I suppose of moving forward here, specifics hopefully sorted out by someone else
10:33zcorpansubmitdisabled="" maybe
10:33annevkzcorpan: could also be a flag on <form> potentially
10:33zcorpanper-control is more flexible
10:34annevkdisabled=&quot;submit&quot; could work if you reflect it through disabledState
10:35zcorpanwe also have <fieldset disabled> which is a bit special
10:35annevkOh stuff inherits?
10:35annevkHmm okay
10:36zcorpaninherits except into the <legend>
10:47zcorpanconsidering <fieldset disabled> i think it should be a separate attribute. you may want to toggle disabled for a whole fieldset, but always submit a specific control inside
10:50hsivonenannevk: thanks for filing the Chrome bug
10:56annevkzcorpan: wouldn&#39;t that still be possible though?
10:57annevkzcorpan: anyway, new attribute seems fine
10:58zcorpanannevk: you&#39;d have to set both disabled on fieldset and disabled=submit on the specific control instead of only setting disabled on fieldset
10:58zcorpan(when toggling with script)
10:59annevkzcorpan: disabled on fieldset should be set either way, right?
10:59annevkzcorpan: and for the control you&#39;ll also need to toggle *something* either way
11:00zcorpanannevk: yes for the first question. i think no for the second question. let me show with markup what i mean so we&#39;re talking about the same case
11:04zcorpanannevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4891
11:07annevkzcorpan: ah okay
11:07annevkzcorpan: pretty obvious indeed
11:10* zcorpan finds 302 matches of &#39;<fieldset(?:s[^>]+)?sdisabledb&#39; in httparchive
12:43annevkhsivonen: so I think we should add a comment on the Chrome bug indicating what the rough situation in Gecko looks like now
12:44annevkhsivonen: with respect to Japanese and Cyrillic and what those mean in terms of labels
12:44annevkhsivonen: and hope that Chrome aligns with that (or a smaller set)
12:45annevkhsivonen: for Japanese it seems we want to sniff between EUC-JP and Shift_JIS
12:45annevkhsivonen: I don&#39;t recall the Cyrillic situation, but since you do, maybe you can comment?
13:52annevkhsivonen: I added a comment since I didn&#39;t want to forget about it
18:06annevkDomenic: dherman says you can find out Script vs ModuleScript
18:06annevkDomenic: or whatever the terminals are called
18:06Domenicannevk: CONTEXT?
18:06botieCONTEXT is https://github.com/validator/validator/issues/284
18:06Domenic(capslock)
19:41annevkDomenic: context isn&#39;t so important, but it seems we could maybe use that instead of trying to change destination types and such
19:41Domenicannevk: I guess I don&#39;t really understand how that is possible; you know how things are to be parsed based on type=&quot;module&quot; or not.
19:42annevkDomenic: hmm, if you run into him at TC39 ask?
19:42annevkDomenic: I could email too, tomorrow
19:42Domenicyeah, I won&#39;t be at TC39 until May most likely
17 Feb 2017
No messages
   
Last message: 220 days and 18 hours ago