| 01:23 | <MikeSmith> | caitp: would be good to have your perspective as an implementor on https://github.com/whatwg/html/pull/401 which is still open and welcoming comments |
| 01:23 | <MikeSmith> | caitp: also https://github.com/whatwg/html/pull/373 which has already been merged but seems like you might want to be aware of |
| 01:24 | <MikeSmith> | not sure if you care so much about stuff at this level, so just FYI |
| 01:25 | <caitp> | of course I care! thanks for the info |
| 01:25 | <caitp> | I'll have to have a look at them at a time when I haven't recently had a glass of wine |
| 01:55 | <MikeSmith> | heh |
| 02:03 | <smaug____> | annevk: Domenic: I need some spec reading help |
| 02:03 | <smaug____> | https://html.spec.whatwg.org/multipage/embedded-content.html#img-environment-changes |
| 02:03 | <smaug____> | step 2 |
| 02:03 | <smaug____> | how is one supposed to interpret that |
| 02:05 | <smaug____> | especially, can one read it like "if the img element ....is not in a Document ..., then abort this algorithm" |
| 02:10 | <smaug____> | or does "it is not in a Document" refer to img's parent? |
| 02:16 | <caitp> | it looks to me like that step enumerates reasons to stop doing anything, and that part in particular refers to the <img> node |
| 02:17 | <caitp> | but what do I know, someone else can have a go at interpretting it |
| 02:18 | <MikeSmith> | if it's ambiguous then it's a bug and merits smaug____ or somebody taking time to raise an issue for it, IMHO |
| 02:19 | <MikeSmith> | because if it's not clear to the both of you then it's not going to be any more clear to other implementors |
| 02:19 | <smaug____> | caitp: but does that "it is not in a Document" refer only to <img> elements which don't have srcset? |
| 02:20 | smaug____ | files a bug |
| 02:20 | <caitp> | it's a run-on sentence, probably written in a hurry, can't be sure |
| 02:22 | <caitp> | you can never tell in those cases whether someone is intentionally referring to the original subject, or if they had meant to split it into multiple sentences, or maybe use semicolons instead of commas --- all you can do is ask the author |
| 02:25 | <smaug____> | https://github.com/whatwg/html/issues/414 it is |
| 09:05 | <zcorpan> | can we rename data-x="" to lt=""? bikeshed habit |
| 09:07 | <annevk> | zcorpan: possibly, if you hack the toolchain and stuff |
| 09:12 | <zcorpan> | and also switch from <span> to <a> at the same time |
| 09:13 | <annevk> | zcorpan: yeah, seems trickier since we use <a> too, but who knows, I haven't looked at wattsi much |
| 09:13 | <zcorpan> | not particularly tricky, just leave those with href alone |
| 09:22 | <zcorpan> | maybe as a first step i can make wattsi fatal error when it sees href-less <a> or an lt="" attribute, which can catch mistakes now and make sure people upgrade wattsi later when we do switch to <a> and lt="" |
| 10:57 | <zcorpan> | MikeSmith: hmm i get an error when trying to build wattsi, even without any changes |
| 10:57 | <zcorpan> | Linking ../bin/wattsi |
| 10:57 | <zcorpan> | ld: file not found: /usr/lib/crt1.o |
| 10:57 | <zcorpan> | An error occurred while linking |
| 10:57 | <zcorpan> | wattsi.pas(2283) Error: Error while linking |
| 10:57 | <zcorpan> | wattsi.pas(2283) Fatal: There were 1 errors compiling module, stopping |
| 11:13 | <zcorpan> | PRed anyway https://github.com/whatwg/wattsi/pull/5 |
| 11:34 | <smaug____> | zcorpan: "use srcset" |
| 11:34 | smaug____ | wonders what that means |
| 11:34 | <smaug____> | perhaps 415 will explain that |
| 11:34 | <zcorpan> | smaug____: it's <dfn>ed |
| 11:35 | <annevk> | smaug____: https://github.com/whatwg/html/pull/406 requires your review |
| 11:35 | <zcorpan> | smaug____: https://github.com/whatwg/html/pull/415/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR24258 |
| 11:36 | smaug____ | has no idea how to see review queue in github easily |
| 11:36 | <smaug____> | zcorpan: ok, I see |
| 11:37 | <annevk> | smaug____: https://github.com/pulls/assigned |
| 11:38 | <smaug____> | zcorpan: so your interpretation is that if img isn't in document, return early, right? |
| 11:38 | <smaug____> | good |
| 11:38 | <smaug____> | since that is what I was hoping to see |
| 11:38 | <smaug____> | (since it makes fixing a bug easier in Gecko) |
| 11:38 | <zcorpan> | smaug____: yes. the in a document check was there before picture existed, i believe |
| 11:39 | <smaug____> | but I don't actually understand why in-document affects to srcset handling |
| 11:41 | <smaug____> | one can't do something like: var im = new Image(); im.srcset = "..."; canvas.getContext("2d").drawImage(...) |
| 11:41 | <smaug____> | but with src it works |
| 11:41 | <zcorpan> | smaug____: no you can do that. it just won't load new images when the environment changes |
| 11:42 | <smaug____> | well, that is what I meant. You need to manually load each time |
| 11:43 | <smaug____> | is there some reason why is-in-document matters for srcset? |
| 11:44 | <zcorpan> | ok. i'm not sure why the in-document check is there. if there are use cases maybe we should drop that |
| 11:44 | <smaug____> | annevk: so, how do I r+ in github |
| 11:44 | <annevk> | smaug____: just write a comment saying LGTM or r+ |
| 11:45 | <smaug____> | huh |
| 11:47 | <smaug____> | can I do that comment in the view where I'm looking at the patch? |
| 11:49 | <smaug____> | I guess I can do that... |
| 11:50 | <zcorpan> | comment in the "Conversation". if you comment on a commit the comment disappears if the PR is rebased and force-pushed |
| 11:50 | <smaug____> | odd tool |
| 11:50 | <zcorpan> | or i suppose it doesn't disappear, but it is no longer visible in the PR |
| 11:51 | <zcorpan> | reviews in github isn't awesome... |
| 11:52 | <smaug____> | or there isn't reviews |
| 11:52 | <smaug____> | there are just some random comments |
| 11:52 | <annevk> | you can leave feedback on individual lines |
| 11:53 | <annevk> | but there isn't really a r+ thing and such |
| 11:53 | <annevk> | I'll merge that PR |
| 12:27 | <smaug____> | does github issue tool have some kind of dependency tracker? |
| 12:38 | <Ms2ger> | smaug____, no, but you can mention #1234 and that will show up in #1234 |
| 12:57 | <smaug____> | Ms2ger: but if you close then the bug which had #1234 in a comment, #1234 isn't notified about it, right? |
| 12:58 | <Ms2ger> | Nope |
| 13:01 | <zcorpan> | smaug____: so is https://github.com/whatwg/html/pull/415 clear enough? |
| 13:05 | <smaug____> | zcorpan: I think so |
| 13:05 | <smaug____> | (I still don't know why srcset handling depends on is-in-document, when normal image loading doesn't.) |
| 13:06 | <smaug____> | but I can live with it depending in is-in-document |
| 13:06 | <smaug____> | just a minor inconsistency |
| 13:06 | <zcorpan> | smaug____: can you file a new issue about that? |
| 13:07 | <MikeSmith> | zcorpan: I have never seen that ld: file not found: /usr/lib/crt1.o error before |
| 13:18 | <smaug____> | zcorpan: https://github.com/whatwg/html/issues/416 |
| 13:19 | <zcorpan> | smaug____: thx |
| 13:23 | <MikeSmith> | zcorpan: about that error, if you're on OSX, but you don't have XCode installed, maybe that's why |
| 13:28 | <zcorpan> | oh right, XCode always stops working whenever it updates, i think |
| 13:33 | <jgraham> | You need to accept a license agreement after every update |
| 13:33 | <jgraham> | In another example of |
| 13:33 | <jgraham> | "apple hate you: |
| 13:35 | <zcorpan> | plus xcode-select --install every time to redownload and install command line tools |
| 14:22 | <zcorpan> | ok it builds now. but Fail() isn't fatal |
| 14:30 | <zcorpan> | MikeSmith: why doesn't html-build show wattsi error messages? |
| 14:45 | <Domenic> | zcorpan: is wattsi in your PATH? |
| 14:46 | <zcorpan> | Domenic: it runs fine (now), it just doesn't log error messages from Fail() when using html-build/build.sh |
| 14:46 | <zcorpan> | Domenic: but it does when i run wattsi directly |
| 14:46 | <zcorpan> | Domenic: and we have a bunch of errors that i suppose nobody notices |
| 15:09 | <Domenic> | zcorpan: that seems bad, we should fix that asap :( |
| 15:09 | <Domenic> | zcorpan: I just thought maybe it was going to the web service which didn't have your local changes |
| 16:04 | <MikeSmith> | I wonder why Simon is running wattsi directly rather than using build.sh |
| 16:04 | <MikeSmith> | as far as I understand it, wattsi is not intended to be run directly on the raw source file |
| 16:05 | <MikeSmith> | if that's what he means by "directly" |
| 16:07 | <MikeSmith> | if he's running it without the pre-processing that the build.sh script is doing, then I think it's expected that there would be errors |
| 16:07 | <MikeSmith> | anyway I'l wait til he's back around |
| 16:08 | <MikeSmith> | botie, inform zcorpan here now if you have time to chat about the build script |
| 16:08 | <botie> | will do |
| 16:36 | <MikeSmith> | time for me to get back to ironing out the build wrinkles I guess |
| 16:37 | MikeSmith | digs his Builder cap out of the toy box and puts it back on |
| 16:39 | <MikeSmith> | two months is too long to be away from it I guess |
| 16:39 | <MikeSmith> | it has missed me |
| 16:39 | <MikeSmith> | nice to feel wanted |
| 16:43 | <Domenic> | yaaaa <3 |
| 16:56 | <annevk> | Domenic: can you get from a Realm to a settings object? |
| 16:56 | <Domenic> | annevk: after my changes yes! |
| 16:56 | <annevk> | Domenic: the settings object has an origin |
| 16:56 | <annevk> | Domenic: don't think we want to use incumbent |
| 16:56 | <Domenic> | wasn't sure |
| 16:57 | <Domenic> | "the settings object whose realm execution context's Realm component is _realm_". |
| 16:57 | <Domenic> | We could shorten that by defining "a settings object's Realm" like I did for "a settings object's global object" |
| 16:57 | <annevk> | the wording of these things makes the checks look bizarro |
| 16:57 | <annevk> | yeah, I guess I'll wait until bz gets back from vacation |
| 16:58 | <annevk> | and myself |
| 16:58 | <annevk> | and then tweak things a bit and start writing a patch for HTML |
| 16:59 | <Domenic> | Very exciting to get these kind of long-term confusion issues straightened out |
| 17:10 | <rits> | Domenic: when i made the wrap_width changed to 100, now it is showing the changes in the whole paragraph |
| 17:17 | <annevk> | rbyers: as a heads up, I'll be away until January 1, seems like this is mostly done, but not done enough to wrap up before the holidays |
| 17:18 | <annevk> | rits: if it's the paragraph you're making changes too anyway, that's fine |
| 17:19 | <rbyers> | annevk: Ok, no worries. As long as the fundamental approach (which we're actively implementing now) isn't in question then there's no rush... |
| 17:20 | <annevk> | rbyers: I don't think so, though as you can tell I forgot some of the background :/ |
| 17:20 | <annevk> | (but not the bit where we decided this was the way forward) |
| 17:20 | <rits> | annevk: actually i have changed a line from a paragraph, i have tried to make the spaces right without changing other one's, i think it will be fine now |
| 17:21 | <rbyers> | annevk: Yeah, that's my fault for dragging the review out <grin>. But it does seem like we keep coming back to the observibility issue though. It's good to hash it out because even once it's in the spec, you won't be the last one to be concerned about it ;-) |
| 17:22 | <rbyers> | annevk: I think it's a legitimate viewpoint that passive listeners make the observability problem worse in some ways, but also better in other ways (in particular it gives us an incremental path to potentially solving the problem entirely). |
| 17:23 | <rbyers> | ... and IMHO the ways in which it makes the problem worse are subtle and unlikely to be an issue for developers in practice, and the ways it makes it better are fundamental and can lead to dramatic improvements in the developer experience :-) |
| 17:23 | <annevk> | I guess they mostly serve as a reminder that you don't want to design any new event system in a way that would require them |
| 17:24 | <annevk> | And by "new event system" I mean a new set of events to expose some functionality not exposed now |
| 17:24 | <rbyers> | ... Right. The real problem IMHO is that we've avoided the complexity in the spec by not discussing this in the past (even though it's been the reality since the iPhone release). In order to fix the problem, we have to describe / expose it, which adds complexity to the spec (in order to document reality) :-( |
| 17:25 | <rbyers> | annevk: Not sure how to best capture all this subtlety in the spec, but happy to keep iterating on it with you until you're happy :-) |
| 17:27 | <annevk> | Thanks, I'll see if I can help when I get back. Pretty sure it'll land in (early) January |
| 18:08 | <annevk> | rbyers: so technically dictionary members are present or not present per https://heycam.github.io/webidl/#dfn-dictionary |
| 18:08 | <annevk> | rbyers: "has" is not really a thing |
| 18:08 | <annevk> | rbyers: it perhaps should be though |
| 18:08 | <annevk> | rbyers: there's a ton of stuff that could make this easier... |
| 18:08 | <annevk> | rbyers: anyway, for January I guess |
| 18:09 | <annevk> | rbyers: doesn't seem worth spending too much time on, I might tweak it a bit while merging |
| 18:09 | <caitp> | does the pass-by-value thing work in any implementations? |
| 18:11 | <rbyers> | annevk: ok, sounds good - thanks! |
| 18:13 | <rbyers> | annevk: I could change "If <var>options</var> is a dictionary and has member <code>{{EventListenerOptions/capture}}</code> with value true" to "If <var>options</var> is a dictionary and <code>{{EventListenerOptions/capture}}</code> is present in <var>options</var> with value true" |
| 18:15 | <annevk> | rbyers: r+ |
| 18:16 | annevk | goes to make some dinner |
| 18:25 | <rbyers> | annevk: done |
| 18:30 | <MikeSmith> | botie, inform zcorpan when you say you're running wattsi directly, you mean you're manually running "wattsi /opt/workspace/html-build/.temp/source-whatwg-complete /opt/workspace/html-build/.temp/wattsi-output /opt/workspace/html-build/.cache/caniuse.json /opt/workspace/html-build/.cache/w3cbugs.csv" where the stuff is the .temp and .cache dirs is what wattsi expects? |
| 18:30 | <botie> | will do |
| 19:41 | <MikeSmith> | smaug____: about https://github.com/w3c/push-api/issues/177 if a "URL-safe base64 encoding" were defined, I wonder what spec would define it |
| 19:41 | <MikeSmith> | or really, what it would say |
| 19:42 | <MikeSmith> | the Push API editors must have some idea in mind of what it actually is supposed to mean |
| 19:42 | <smaug____> | MikeSmith: I was reviewing implementation for that code and couldn't know what should happen there, so I filed that bug |
| 19:43 | <smaug____> | maybe referring to ... let me find the link |
| 19:43 | <MikeSmith> | I see |
| 19:43 | <MikeSmith> | I would think they must be assuming that implementors would understand what it means |
| 19:44 | <smaug____> | maybe referring to https://tools.ietf.org/html/rfc4648#page-7 or something would be the right thing to do |
| 19:44 | MikeSmith | looks |
| 19:44 | <MikeSmith> | aha |
| 19:45 | <MikeSmith> | yeah, "Base 64 Encoding with URL and Filename Safe Alphabet" |
| 19:45 | smaug____ | is just being a pain-in-the-ass-reviewer and complaining about stuff ;) |
| 19:45 | <MikeSmith> | The "URL and Filename safe" Base 64 Alphabet |
| 19:46 | <MikeSmith> | well it should be clear it and should use exact precise terms and not synonymns for them |
| 19:47 | <smaug____> | if you look at the wikipedia article, it mentions couple of variants of base64url |
| 19:47 | MikeSmith | looks |
| 19:48 | <MikeSmith> | 「Standard 'base64url' with URL and Filename Safe Alphabet」vs 「Unpadded 'base64url' for "named information" URI's」 |
| 19:48 | <smaug____> | and = handling |
| 19:48 | <smaug____> | " Some libraries ... will encode '=' to '.'." |
| 19:49 | <MikeSmith> | oh |
| 19:49 | <TabAtkins> | smaug____: That's def not a pain-in-the-ass nitpick. I had no idea what that was, people need to link to things more obscure than ASCII. ^_^ |
| 20:15 | <MikeSmith> | Domenic: OK finally made the fixes to https://github.com/whatwg/html-build/pull/29 |
| 20:16 | <Domenic> | MikeSmith: yay! will review today |
| 20:16 | <MikeSmith> | only took me 80 days! |
| 20:16 | <MikeSmith> | Domenic: super, thanks |
| 20:35 | <botie> | zcorpan, at 2015-12-17 16:08 UTC, MikeSmith said: here now if you have time to chat about the build script and at 2015-12-17 18:30 UTC, MikeSmith said: when you say you're running wattsi directly, you mean you're manually running "wattsi /opt/workspace/html-build/.temp/source-whatwg-complete |
| 20:35 | <botie> | /opt/workspace/html-build/.temp/wattsi-output /opt/workspace/html-build/.cache/caniuse.json /opt/workspace/html-build/.cache/w3cbugs.csv" where the stuff is the .temp and .cache dirs is what wattsi expects? |
| 20:36 | <zcorpan> | MikeSmith: manually typing such yes |
| 20:36 | <MikeSmith> | zcorpan: ok will try that |
| 20:39 | <zcorpan> | for example i get Error: Multiple secondary definitions (subdfn) for term "dom-context-2d-settransform" Parent of first says: "context . setTransform(a, b, c, d, e, f)", parent of second says: "context . setTransform(matrix)" plus 40-something similar errors |
| 20:47 | <zcorpan> | though i ran it on source directly, maybe that's why there were errors? |
| 20:49 | <MikeSmith> | zcorpan: no, when I can reproduce it when running it manually on the pre-processed source as well |
| 20:49 | <zcorpan> | have to go now |
| 20:51 | <MikeSmith> | k |
| 20:55 | <MikeSmith> | so the errors are getting written to .temp/wattsi-output.txt but not echoed after that |
| 20:57 | <MikeSmith> | maybe we should just be using tee there to begin with but I think the reason I did it that way was so that we just do that same thing we do for the remote-wattsi case, where the errors are written to a file an the server side (and then we download that file and cat it after the build completes) |
| 20:58 | MikeSmith | will fix it now |
| 21:05 | <MikeSmith> | so it seems that wattsi doesn't actually exit non-zero when it hits those errors, and all we're doing it checking for non-zero exit status, and since we don't find it, the script assumes everything's fine and there's nothing to report |
| 21:06 | <MikeSmith> | fix would seem to be to make wattsi actually exit non-zero |
| 21:08 | <Domenic> | +1 |
| 21:09 | <Domenic> | Although I guess maybe unix programs are supposed to only exit nonzero when they fail to produce any output? |
| 21:15 | <wanderview> | Domenic: I don't think that's the case... |
| 21:15 | <wanderview> | or I have never heard of that rule before |
| 21:22 | <stakagi> | I want someone to teach the reason for Dimension attributes being not a floating point but integer. |
| 21:23 | <stakagi> | html spec. has said that the widthheight attribute of iframe is non negative integer. |
| 21:24 | <stakagi> | Firefox and IE actually parse it as integer, on the contrary, chrome and safari parse it as floating point. |
| 21:24 | <stakagi> | On the corresponding property on CSS, these are floating points. |
| 21:24 | <stakagi> | https://html.spec.whatwg.org/multipage/embedded-content.html#attr-dim-width |
| 21:37 | <TabAtkins> | Presumably because they were invented back in the days when nobody could have dreamed of a 2x display, so supporting floating point was pointless. (sorry) |
| 21:40 | <stakagi> | I am verifying the embedded content chapter of svg2 and noticed this. |
| 21:41 | <stakagi> | I am putting that note into svg2 wd. |
| 21:42 | <caitp> | i I had to guess, i'd say it's probably just because webkit's parseSimpleLengthValue() always results in a double |
| 21:43 | <caitp> | and blink probably still inherits that property |
| 21:43 | <caitp> | but, just guessing, more css-savvy igalians would know more |
| 21:44 | <caitp> | mozilla/msft might just cut corners and avoid going to all that trouble |
| 22:06 | <TabAtkins> | Moz/IE aren't cutting corners, they're following the spec. ^^_ |
| 22:09 | <zcorpan> | MikeSmith: i tried to make wattsi's Fail() write to stderr with Writeln(StdErr, ...) but it seems it didn't make any difference when doing e.g. wattsi ... 2>test.txt |
| 22:10 | <zcorpan> | MikeSmith: changing the return value still doesn't print the errors, right? |
| 22:12 | <zcorpan> | maybe there's something obvious i don't know about in bash where you can print what wattsi prints here https://github.com/whatwg/html-build/blob/master/build.sh#L182 |
| 22:16 | <zcorpan> | oh, it's just stdout that's written to that file? |
| 22:19 | <MikeSmith> | zcorpan: yeah just stdout |
| 22:19 | <MikeSmith> | not stderr |
| 22:19 | <MikeSmith> | not sure wattsi ever writes anything to stderr |
| 22:21 | <zcorpan> | probably not, i was just experimenting with changing how Fail() writes |
| 22:21 | <zcorpan> | so what does https://github.com/whatwg/wattsi/blob/master/src/wattsi.pas#L1556 do? |
| 22:27 | <zcorpan> | MikeSmith: is there a problem with not redirecting stdout to a file, and just let it print its stuff? |
| 22:55 | <MikeSmith> | zcorpan: the problem is that we can't do that for the remote build |
| 22:55 | <MikeSmith> | we need to write it to a file on the server side for the remote case |
| 22:56 | <MikeSmith> | and the same code shared for the final error reporting is used after the build is run locally or remotely |
| 22:56 | <MikeSmith> | and it's agnostic to where the build ran |
| 22:56 | <MikeSmith> | it just cats that file |
| 22:57 | <MikeSmith> | and the reason for sharing it is that we have to actually run the build twice |
| 22:57 | <MikeSmith> | to get the right line numbers |
| 22:57 | <MikeSmith> | if/when there are line numbers to repot |
| 22:58 | <MikeSmith> | which is not actually the case always because for some errors wattsi reports no line numbers |
| 22:58 | <MikeSmith> | but anyway, that's why we need to delay the error reporting |
| 22:59 | <MikeSmith> | we could have it report the errors in real time when it finds them in the local case but then if there are line numbers, the numbers are off by hundreds of lines |
| 22:59 | <MikeSmith> | because it;s reporting them against the pre-processed source |
| 23:01 | <MikeSmith> | obviously it's an ugly hack the only alernative is that we need to teach wattsi how to calculate the offset so that it reports the correct line numbers even when run just once against the pre-processed source (instead of the original raw source) |
| 23:02 | <MikeSmith> | and we should probably do that eventually but it would require substantially more work laboring in Pascal code |
| 23:04 | <MikeSmith> | given all that if you have a better idea of how to handle the error reporting that doesn't require caching it like this is doing, then that would be great |
| 23:36 | <zcorpan> | MikeSmith: ok. but can it print the content of that file even on success? |