| 03:08 | <AndroUser> | Hi |
| 05:34 | <MikeSmith> | Hixie_: offhand it doesn't seem to me like most validator users would be happier if we always emitted messages about <!-- |
| 07:09 | <MikeSmith> | Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23587 is one of those bugs that really should have been filed against the WHATWG spec |
| 07:10 | <MikeSmith> | but I'm sure I'll get complaints if I move it. or plh will get a complaint about me moving it |
| 07:11 | <MikeSmith> | I hope we can get back to having one place for people to file HTML spec bugs, and then we can triage them however from there |
| 08:27 | <zcorpan> | hmm, multipage version is behind? i don't see the note in #restrictions-for-contents-of-script-elements |
| 08:30 | <zcorpan> | Hixie_: so actually the example given doesn't violate the restrictions |
| 08:32 | <zcorpan> | Hixie_: v.nu implements the restrictions and gives no error for the <!-- despite appearances, this is actually part of the script still! --> example |
| 08:39 | <zcorpan> | parse error when entering double escaped seems like the missing piece |
| 08:43 | <zcorpan> | Hixie_: looks like steve cloned the bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=23590 |
| 09:13 | <MikeSmith> | zcorpan: are you proposing that the validator emit a warning any time it sees <!-- in script? |
| 09:14 | <zcorpan> | MikeSmith: no |
| 09:14 | <zcorpan> | MikeSmith: an error when seeing <!-- <script |
| 09:14 | <MikeSmith> | ok |
| 09:15 | <zcorpan> | the validator already emits an error for <script><!--</script>, but <script><!--<script></script>... is more problematic in a world with only html5 parsers |
| 09:16 | <zcorpan> | whereas the former is problematic in legacy parsers |
| 09:16 | <MikeSmith> | I see |
| 09:17 | <zcorpan> | and people who do <script><!-- document.write('<script><'+'/script>') --></script> deserve an error |
| 09:17 | <Ms2ger> | People who do document.write deserve one ;) |
| 09:18 | <zcorpan> | does any browser whine about document.write in devtools? |
| 09:19 | <SimonSapin> | annevk-cloud: http://url.spec.whatwg.org/#writing what does "Writing" mean? Is it different from Serializing? |
| 09:22 | <zcorpan> | heh, PDF tojan horse <http://www.w3.org/mid/FADAB8BA-B90A-49F0-85B1-535BC13D2E44⊙ff>; |
| 09:25 | <SimonSapin> | I suppose this is the concern? https://en.wikipedia.org/wiki/Jpeg2000#Legal_issues |
| 09:25 | <annevk> | SimonSapin: yes |
| 09:26 | <SimonSapin> | annevk: http://krijnhoetmer.nl/irc-logs/whatwg/20131022#l-249 |
| 09:27 | <annevk> | SimonSapin: recursion? |
| 09:29 | <SimonSapin> | annevk: was "yes" about URL or JPEG2000? |
| 09:29 | <annevk> | SimonSapin: URL |
| 09:29 | <SimonSapin> | so, yes it is different. What does it mean? |
| 09:31 | <annevk> | Serializing is often much more constrained. E.g. you can write CSS in many ways, but a CSS serializer is required to follow certain algorithms because otherwise browsers have differences that developers will trip over. |
| 09:31 | <SimonSapin> | so writing is what authors write, what the parser supports? |
| 09:38 | <annevk> | SimonSapin: yes |
| 09:40 | <MikeSmith> | heh "If you said something incorrect and I failed to correct you, I apologize and promise to be more vigilant in the future." http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0145.html from roc |
| 09:43 | <jgraham> | SimonSapin: In general there are three different sets each with a subset relation to the preceeding one; the set of things that the parser supports, the set of things authors are permitted to write and the set of things that the serializer can emit. |
| 09:43 | <SimonSapin> | http://url.spec.whatwg.org/#concept-parsed-url Just like scheme data is not used in relative schemes, should username, password, host, port and path not be be used in non-relative schemes? I’m trying to come up with a model/data structure for parsed URLs |
| 09:44 | <SimonSapin> | jgraham: ok, makes sense |
| 09:46 | <jgraham> | SimonSapin: A better type structure for URLs sounds good |
| 09:47 | <SimonSapin> | I have this so far based on #writing, but #concept-parsed-url seems to disagree: https://pastebin.mozilla.org/3310970 |
| 09:51 | <Ms2ger> | MikeSmith, that's a misquote, should end "in the future [...]." |
| 09:51 | <annevk> | SimonSapin: don't base the model on #writing |
| 09:51 | <annevk> | SimonSapin: a parsed URL is always absolute |
| 09:52 | <annevk> | SimonSapin: so either "scheme" and "scheme data" or "scheme", "username", etc. |
| 09:52 | <annevk> | SimonSapin: oh, both also have "query" and "fragment" |
| 09:52 | <SimonSapin> | yes, that’s what I’m trying to encode in the type system |
| 09:52 | <jgraham> | annevk: Look at the pastebin |
| 09:53 | <annevk> | jgraham: I did |
| 09:53 | <jgraham> | YOu should like this stuff because it forces you to define the model very carefully :) |
| 09:53 | <SimonSapin> | all parsed URLs have a scheme but some have a "relative scheme", ie. can be used as a base for relative URLs |
| 09:53 | <annevk> | Yes, the model is not yet defined |
| 09:53 | <annevk> | Because it's still a bit unclear to me how fragments work, because they're different all over :/ |
| 09:54 | <SimonSapin> | Isn’t fragment just an optional string? |
| 09:54 | <SimonSapin> | in the model |
| 09:54 | <jgraham> | Does that matter here? |
| 09:54 | <annevk> | jgraham: kinda, are the individual bits bytes or code points |
| 09:55 | <jgraham> | Well, OK in that case it's not clear if it should be ~str or ~[u8] |
| 09:55 | <jgraham> | Or however one represents bytes |
| 09:55 | <jgraham> | (pretending that ~str was code points) |
| 09:56 | <jgraham> | But that doesn't seem very important for the rest of SimonSapin's work |
| 09:56 | <annevk> | SimonSapin: userinfo should prolly not be a distinct struct |
| 09:57 | <jgraham> | annevk: Can you have a password with no username? |
| 09:57 | <SimonSapin> | annevk: the struct is just a detail to encode the Option structure, ie. password can only exist with an username |
| 09:57 | <jgraham> | I think that's what the seperateness there encodes |
| 09:57 | <jgraham> | Right |
| 09:57 | <SimonSapin> | every other type here is an implementation detail of ParsedURL |
| 09:58 | <annevk> | So userinfo is not actually exposed? |
| 09:58 | <annevk> | I'm not sure I understand how this works |
| 09:59 | <jgraham> | annevk: It's part of the data structure, but you wouldn't have a .userinfo visible to script or anything |
| 09:59 | <annevk> | Is that the same for scheme_and_data? |
| 10:00 | <jgraham> | Yeah, so presumably SimonSapin will implement some accessors that will return the script-visible parts |
| 10:01 | <jgraham> | But this setup forces other internal code to follow the rules |
| 10:03 | <SimonSapin> | annevk: exposed, you mean to JS? |
| 10:04 | <SimonSapin> | Rust data structures do not have to map exactly to JS bindings |
| 10:04 | <SimonSapin> | here I tried to encode some constraints in the type system (such as password can only be set with a username) |
| 10:05 | <SimonSapin> | but maybe it’s fine not to do that and just have the parser never return such objects |
| 10:05 | <SimonSapin> | and have a "flatter" data structure |
| 10:05 | <annevk> | SimonSapin: I just mean in Rust |
| 10:05 | <annevk> | SimonSapin: I understand you can expose whatever in JS |
| 10:06 | <SimonSapin> | with this API yes, users of the Rust lib have to go through UserInfo to get the username/password |
| 10:06 | <SimonSapin> | annevk: would you rather have a simpler data structure with some constraints not enforced? |
| 10:07 | <annevk> | SimonSapin: I'm not sure what's best for Rust |
| 10:09 | <annevk> | I expected something flatter. I'll note that only the parser can directly operate on the data structure. Any API for manipulating the data structure will need to do so indirectly as conversions and such have to be made. |
| 10:12 | <jgraham> | FWIW I had a flatter data structure and I think this is better :) |
| 10:14 | <SimonSapin> | annevk: do you mean the fields should not be accessed directly but through getters and setters? |
| 10:16 | <annevk> | SimonSapin: for reading it might be okay, for manipulating only if you know what you're doing |
| 10:17 | <annevk> | SimonSapin: basically the parser guarantees certain things, being able to put in ".." as one of the entries of URL's path would be bad |
| 10:18 | <jgraham> | Can't encode that in Rust's type system really :) |
| 10:19 | <gsnedders> | Bah, just need a better type system! |
| 10:19 | <jgraham> | (so I imagine that yes you would have getters and setters in the external API) |
| 10:19 | <jgraham> | gsnedders: Is it nice up there in the ivory tower? :) |
| 10:27 | <gsnedders> | jgraham: Well, compilation is undecidable, but it's fine! |
| 10:27 | <SimonSapin> | does any browser still support gopher? |
| 10:28 | <jgraham> | SimonSapin: Pretty sure that they don't since Gecko removed support |
| 10:28 | <gsnedders> | Opera/Linux? |
| 10:28 | <gsnedders> | Oh, no. |
| 10:29 | <gsnedders> | SimonSapin: I guess lynx doesn't count? :P |
| 10:29 | <SimonSapin> | it’s probably harmless to have it in the URL parser |
| 10:30 | <jgraham> | gsnedders: As much as I wanted to say "Opera had it last", no :) |
| 10:32 | <annevk> | SimonSapin: yeah, dunno, it was in WebKit |
| 10:32 | <annevk> | SimonSapin: support for the scheme |
| 10:32 | <jgraham> | According to Wikipedia, of the WebKit browsers, only OmniWeb supports it by default |
| 10:33 | <jgraham> | Fx has an addon |
| 10:33 | <jgraham> | Everything else seems to be small browsers that were using old version of gecko |
| 10:33 | <jgraham> | and non-graphical browsers |
| 10:38 | <annevk> | In terms of parsing |
| 10:41 | <foolip> | annevk, any particular reason you think arv is interested in my UseCounter? |
| 10:42 | <annevk> | foolip, he likes killing stuff :-) |
| 10:43 | <foolip> | it is a joy to send red diffs to review |
| 10:43 | <foolip> | BTW, I've canceled my TPAC trip, so don't expect to see me there |
| 10:43 | <jgraham> | :( |
| 10:43 | <foolip> | too much time away from home in November otherwise, with two other conferences (FOMS and Opera-internal) |
| 10:44 | <foolip> | jgraham, where do you live now? |
| 10:44 | <foolip> | GPS coordinates for my killdrones, plz |
| 10:44 | <jgraham> | foolip: London, approximately. |
| 10:44 | <foolip> | OK, will make a big sweep then :) |
| 10:45 | jgraham | points the killdrones to annevk's house |
| 10:45 | <annevk> | hah, joke's on you, my house is not in London |
| 10:45 | <foolip> | jgraham, what kind of stuff are you doing at Mozilla? |
| 10:45 | <annevk> | mainly pestering me |
| 10:46 | <foolip> | annevk, but you still work from the Netherlands, right? |
| 10:46 | <annevk> | foolip: no I'm in London |
| 10:46 | <foolip> | annevk, oh, I had no idea |
| 10:46 | <jgraham> | Ah, good I was worried that you had a hologram or something |
| 10:46 | <foolip> | then I should force both of you to buy me English cider if I visit London |
| 10:46 | <annevk> | together we might have enough money |
| 10:46 | <gsnedders> | But you're Swedish, you'll complain it's not sweet. |
| 10:47 | <foolip> | gsnedders, I really won't, I enjoy it very much :) |
| 10:47 | <annevk> | I don't think I ever had cider here |
| 10:47 | <jgraham> | foolip: I am mostly working on the W3C web-platform-tests stuff, with the gols of getting Mozill running the tests on each push and writing tests instead of proprietary tests |
| 10:48 | <wilhelm> | \o/ |
| 10:48 | <foolip> | jgraham, that would be nice for Chromium as well, I've been writing tests using testharness.js but don't have a way to keep them in sync if I should submit them to the W3C :( |
| 10:48 | <foolip> | (I think, I haven't actually asked anyone.) |
| 10:48 | <gsnedders> | Wasn't someone working on that? |
| 10:49 | <jgraham> | foolip: Yeah, that side of it is a huge problem |
| 10:49 | <jgraham> | gsnedders: Dirk Pranke |
| 10:49 | <gsnedders> | jgraham: Right, that's the name. |
| 10:49 | <foolip> | is he in this channel? |
| 10:49 | <jgraham> | I don't think so |
| 10:49 | <gsnedders> | jgraham: I was trying to find something like Derk or Deirk :P |
| 10:50 | <jgraham> | I think bratell spoke to him or heard a talk from him at BlinkOn so he (bratell) might know more |
| 10:50 | <annevk> | http://www.youtube.com/watch?v=aAZR7OUhFDU o_O |
| 10:50 | <foolip> | I met him at BlinkOn as well, but didn't ask about testing |
| 10:50 | <gsnedders> | He's in #blink at times, too |
| 10:51 | <foolip> | well, isn't this a nice little Opera chat room :) |
| 10:51 | <jgraham> | annevk: That was satire, right? |
| 10:51 | <annevk> | jgraham: I'm not sure, JakeA? |
| 10:52 | <jgraham> | I got as far as the intro and the slightly creepy host |
| 10:53 | <JakeA> | no |
| 10:53 | <JakeA> | I don't think so |
| 10:56 | <JakeA> | Poor Brian |
| 11:02 | <darobin> | I think a Standards Suck parody is in order |
| 11:04 | <matjas> | do any browsers support autofill fields for `autocomplete` attribute? http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofill-field |
| 11:05 | <matjas> | doesn’t really seem to work in Chrome — any value seems to map to `autocomplete="off"` |
| 11:06 | <JakeA> | matjas: really? I don't think that's the case |
| 11:06 | <JakeA> | I've seen it work before |
| 11:06 | <JakeA> | also http://www.html5rocks.com/en/tutorials/forms/requestautocomplete/ |
| 11:06 | <foolip> | jgraham, do you have a pointer to the latest and bestest way to submit new testharness.js tests? |
| 11:06 | <foolip> | if it's easy enough, I want to do it... |
| 11:06 | <foolip> | (feel the pressure) |
| 11:07 | <jgraham> | foolip: http://testthewebforward.org/docs/ |
| 11:08 | <JakeA> | matjas: I get this autocompleting https://googledrive.com/host/0B28BnxIvH5DueUxvWVNsQXd5dU0/checkout.html? |
| 11:08 | <jgraham> | http://testthewebforward.org/docs/github-101.html#test-repositories might be all you need to know |
| 11:09 | <foolip> | ok, so pull request on https://github.com/w3c/web-platform-tests is the super-short answer? |
| 11:10 | <annevk> | foolip: yeah |
| 11:10 | <foolip> | nice |
| 11:11 | <matjas> | JakeA: thanks. trying to pin down what i’m doing wrong |
| 11:11 | <foolip> | jgraham, is old-tests/submission/Opera/media/ going to stay there forever, or is there a plan? |
| 11:12 | <jgraham> | foolip: There is a plan |
| 11:13 | <jgraham> | So if possible don't submit new tests there |
| 11:13 | <foolip> | jgraham, ok, thanks! |
| 11:13 | <foolip> | zcorpan, do you know if all of our media tests are somewhere in https://github.com/w3c/web-platform-tests ? |
| 11:13 | <foolip> | would be super nice :) |
| 11:14 | <zcorpan> | foolip: they are not |
| 11:14 | <zcorpan> | foolip: a few of them are, though |
| 11:14 | <foolip> | zcorpan, because they need to be converted to testharness.js? |
| 11:14 | <zcorpan> | in particular the track tests are all submitted i think |
| 11:15 | <zcorpan> | i had a few attempts at submitting most media tests (without converting), but for some reason it hasn't actually happened yet |
| 11:16 | <foolip> | zcorpan, I will cheer when it happens :) |
| 11:16 | <zcorpan> | iirc the track tests are still to be reviewed |
| 11:17 | <zcorpan> | past experience suggests that it's better to convert to testharness first and then submit |
| 11:17 | <foolip> | I want to do a spec-implementation sync for video and track in Blink, so having our tests public would be helpful in that endeavor |
| 11:17 | <foolip> | zcorpan, do you have some half-finished conversion work sitting around in case I'm curious? |
| 11:18 | <zcorpan> | because some people get grumpy about there being tests in the wrong format and expect a deadline for when i will have them converted. and nobody else helps converting. Ms2ger is exception to the rule who helped convert some worker tests |
| 11:18 | <foolip> | zcorpan, oh, some of the stuff in old-tests/submission/Opera/ is not converted? |
| 11:19 | jgraham | converted some websockets tests |
| 11:19 | <jgraham> | But I think I was being paid by Opera at the time |
| 11:19 | <wilhelm> | If that helps, there's always http://testsuites.opera.com/ . You can sync things directly from the t server to there. That gets the tests out in the open, at least, even if they are the wrong format. |
| 11:19 | <jgraham> | So maybe that doesn't count |
| 11:20 | <foolip> | wilhelm, hmm, I see that there are none of the media tests, so maybe dumping them directly into https://github.com/w3c/web-platform-tests would be just as easy |
| 11:20 | <zcorpan> | jgraham: yeah, maybe i was unfair with the no help statement |
| 11:20 | <wilhelm> | Leaving mostly-good tests to rot on an internal server is the worst option anyway. (c: |
| 11:20 | <jgraham> | Putting things unconverted in web-platform-tests is much much better than testsuites.opera.com |
| 11:20 | <wilhelm> | Then I withdraw my above comment. (c: |
| 11:21 | <jgraham> | At least in the latter case it might eventually be my job to do the conversions |
| 11:21 | <zcorpan> | anyway i'll have another look at dumping the tests |
| 11:21 | <jgraham> | The problem we have at the moment is that there are relatively lots of people that want a testsuite and relatively few who are apid to work on it |
| 11:22 | <wilhelm> | That sounds vaguely familiar. |
| 11:22 | <jgraham> | Also W3C seem to have assigned denis to do some work on the testsuite for the purposes of HTML->Rec |
| 11:22 | <jgraham> | So now is probably a good time to dump HTML tests |
| 11:22 | <jgraham> | (now lunch) |
| 11:47 | <MikeSmith> | apid? |
| 11:48 | <jgraham> | paid |
| 11:48 | <jgraham> | My fingers aren't race-free |
| 11:50 | <MikeSmith> | heh |
| 11:58 | <Ms2ger> | Oh hey, hadn't seen http://testsuites.opera.com/ before |
| 11:59 | <Ms2ger> | FWIW, I'm happy to help converting tests to th.js, given infinite free time :) |
| 11:59 | <wilhelm> | Ms2ger: It predates the W3C servers by a small margin, I think. It wasn't really used much. |
| 12:04 | <jgraham> | Started work on https://github.com/jgraham/html-testsuite/blob/documentation/docs/critic.md |
| 12:05 | <jgraham> | I think I really need to walk through an actual review to make it work though. Which is quite a lot of work :| |
| 12:08 | <Ms2ger> | I've got https://critic.hoppipolla.co.uk/r/208 to offer ;) |
| 12:10 | <jgraham> | Yeah, but to tick all the boxes, I need a review with multiple commits, possibly touching multiple files, and some deliberate errors |
| 12:10 | <jgraham> | I think I will have to construct something artificial |
| 12:11 | jgraham | does something else for a bit |
| 12:22 | <Ms2ger> | jgraham, done |
| 12:25 | <Ms2ger> | Ta |
| 12:25 | <jgraham> | Thanks for the tests :) |
| 12:26 | <zcorpan> | jgraham: for the timeout_multiplyer change, what's the story for existing tests that set timeout? |
| 12:27 | Ms2ger | is down to two branches in his wpt clone |
| 12:28 | <Ms2ger> | Now I could focus on reviewing! |
| 12:28 | <Ms2ger> | Could |
| 12:28 | smaug____ | wonders what is happening with Web Audio API |
| 12:28 | <smaug____> | Ms2ger: want to take some patches from my queue ;) |
| 12:29 | <Ms2ger> | Ugh |
| 12:29 | <smaug____> | WAAPI doesn't have an active editor anymore, I think |
| 12:29 | <Ms2ger> | Thanks for reminding me off my code review queue :/ |
| 12:29 | <smaug____> | and that spec certainly could use some heavy editing |
| 12:29 | <Ms2ger> | smaug____, volunteering? :) |
| 12:31 | <smaug____> | nouu |
| 12:31 | <smaug____> | well, I could kill all the nonsense first and focus on the stuff people actually need |
| 12:44 | <zcorpan> | what i remember from looking at web audio is sad panda |
| 12:48 | <zcorpan> | jgraham: hmm, the per-test timeout setting is still supported? |
| 12:49 | <zcorpan> | seems so |
| 12:51 | <smaug____> | oh, the trash version has different editors |
| 12:52 | <smaug____> | odd, is TR/ of web audio the real version |
| 12:52 | <annevk> | maybe they moved to GitHub? |
| 12:52 | <smaug____> | aha, my mistake. The editor's draft is in unusual place |
| 12:53 | <annevk> | smaug____: https://github.com/WebAudio/ |
| 12:53 | <smaug____> | yes |
| 12:53 | <smaug____> | unsual |
| 12:53 | <smaug____> | ok, silly me. my mistake |
| 12:53 | <annevk> | par for the course in the WHATWG |
| 12:53 | <smaug____> | how so? |
| 12:54 | <smaug____> | I see whatwg specs under whatwg.org |
| 12:54 | <smaug____> | not some random .com |
| 12:54 | <annevk> | ah, yeah, checked out versions are, but they are copied from https://github.com/whatwg/ |
| 12:55 | <smaug____> | but whatwg.org versions are generated immediately when github version changes, right? |
| 12:55 | <annevk> | yes |
| 12:55 | <smaug____> | but anyway, total failure from my side :) |
| 12:55 | <annevk> | sorry for the confusion |
| 12:56 | <jgraham> | zcorpan: Yeah, still supported although you are encouraged to leave it alone unless you know what you are doing |
| 12:56 | smaug____ | wants consistency also in spec document management :) |
| 12:56 | <annevk> | we're still in the competition phase, not ready to standardize quite yet |
| 13:14 | <darobin> | yeah, it's hardcore competition phase there |
| 13:15 | <darobin> | which is why W3C has decided to adopt a vastly improved spec location system based on subdomains |
| 13:15 | <darobin> | for instance, we'll now have http://web-audio.wd.2013.10.05.specs.rectrack.w3.org/ |
| 13:15 | <darobin> | much simpler that way! |
| 13:16 | <Ms2ger> | Wrong order in your date |
| 13:17 | <darobin> | Ms2ger: only if you're trying to make it useful :) |
| 13:17 | <Ms2ger> | Should have known better |
| 13:18 | <foolip> | TabAtkins, ping |
| 13:19 | <TabAtkins> | foolip: pong |
| 13:21 | <foolip> | TabAtkins, I started following some weird Blink code around video sizing, and found myself in your spec: http://dev.w3.org/csswg/css-images/ |
| 13:22 | <foolip> | TabAtkins, in particular, Blink uses default intrinsic size 300x150, instead of default object size 300x150 |
| 13:22 | <foolip> | and there's a comment in RenderReplaced::computeReplacedLogicalWidth that says that it isn't what the spec says, but could be risky to change |
| 13:23 | <foolip> | my concrete question is which spec should specify that the default object size of images should be 0x0 |
| 13:24 | <TabAtkins> | Why would that be what you wanted? |
| 13:25 | <foolip> | I was under the impression that 300x150 is the default for replaced content, but that could just be what Blink does |
| 13:25 | <foolip> | now that I checked I couldn't find a default at all |
| 13:25 | <foolip> | (in the specs) |
| 13:25 | <TabAtkins> | This keeps coming up. ^_^ |
| 13:25 | <darobin> | TabAtkins: have you thought about using https://github.com/tobie/specref for Bikeshed? |
| 13:26 | <Ms2ger> | So spec it ;) |
| 13:26 | <TabAtkins> | Replaced elements are sized in a slightly weird way which is *almost* the sizing algorithm in Images, but not quite. Just follow 2.1. |
| 13:26 | <TabAtkins> | Specifically, the "inline replaced elements" stuff. |
| 13:26 | <Ms2ger> | So does 2.1 say "whatever"? :) |
| 13:26 | <TabAtkins> | Ms2ger: Only in one case. |
| 13:26 | Ms2ger | hears "yes" |
| 13:27 | <TabAtkins> | darobin: I do plan on adding that in as a source, but it's hard to integrate as the links are untyped. :/ |
| 13:29 | <foolip> | TabAtkins, http://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width ends up with 300px, that isn't what any browser does for images |
| 13:30 | <TabAtkins> | Interesting. What's the precise conditions that land you there? |
| 13:31 | <foolip> | TabAtkins, try http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2579 in a few different browsers |
| 13:31 | <foolip> | the conditions are very simple, as you will see :) |
| 13:32 | <darobin> | TabAtkins: can you file a bug on the repo indicating what your needs are? it would be good to have a single point there, and we're happy to improve things |
| 13:34 | <TabAtkins> | foolip: Ah, this is an interesting case, as there's no image at all. |
| 13:34 | <foolip> | TabAtkins, I'm guessing this will also be the size while the image is loading, although I haven't tried |
| 13:34 | <TabAtkins> | Not too surprised that browsers handle this differently than the has-image case. |
| 13:35 | <TabAtkins> | Using delayed-image, yeah, it is. |
| 13:35 | <TabAtkins> | Okay, looks like this is a case the spec doesn't touch. I'll put it on my list of things to explore and spec. |
| 13:35 | <foolip> | my guess is that making images 300x150 for either the no-src or the still-loading case is not Web compatible |
| 13:36 | <TabAtkins> | Yeah. |
| 13:36 | <foolip> | right now, I'm trying to decide how to fix <video> sizing, without also breaking all other replaced content |
| 13:37 | <foolip> | but it sounds like the "default object size" concept in your spec isn't ready for implementation? |
| 13:37 | <TabAtkins> | https://github.com/tabatkins/specs/issues/17 |
| 13:38 | <TabAtkins> | It doesn't cover replaced elements, but is otherwise fine and should be web-compatible. |
| 13:39 | <foolip> | TabAtkins, ok, maybe I'll try to clean up the other things that are wrong about this first, and leave splitting of intrinsic size from default object size until later |
| 13:40 | <foolip> | (about <video> that is) |
| 13:40 | <tobie> | TabAtkins: don't understand what you mean by "typed links". |
| 13:42 | <TabAtkins> | tobie: Bikeshed (and Shepherd) gives a type to all definitions, to reduce the chance of clashing. Links are thus also typed. (The typing information also has other benefits, like making it easier to auto-gen some kinds of documentation.) |
| 13:43 | tobie | confused. |
| 13:43 | <tobie> | In practice, what does that mean? |
| 13:44 | <TabAtkins> | It means that you can write 'foo' and be assured that it'll link to the foo *property*, not anything else, and that you won't have to disambiguate the link unless there are multiple definitions of the property. |
| 13:44 | <TabAtkins> | (Because 'foo' is a markup shortcut in Bikeshed that expands to <a data-dfn-type=property>foo</a>.) |
| 13:44 | <TabAtkins> | Sorry, data-link-type |
| 13:45 | <tobie> | oh, are you referring to the fact that some of the references in specref are still html strings? |
| 13:46 | <tobie> | because mostly it's just structured data, now. |
| 13:47 | <TabAtkins> | tobie: No, not that. |
| 13:47 | <TabAtkins> | Look at the difference between https://github.com/tobie/specref/blob/master/xrefs.json and https://raw.github.com/tabatkins/bikeshed/master/bikeshed/spec-data/anchors.json |
| 13:47 | <tobie> | oh---that. |
| 13:48 | <TabAtkins> | The xrefs are just a mapping from arbitrary string to anchor. |
| 13:48 | <TabAtkins> | While bikeshed's data is much richer and makes it easier to autolink. |
| 13:48 | <tobie> | I have no idea how that works or what it does. Afaik, no one uses it. Ask darobin. |
| 13:48 | <TabAtkins> | Oh, you were just wanting to talk about the biblio data? |
| 13:48 | <TabAtkins> | Yeah, as far as I can tell biblio is fine. I can integrate that. I'll file an issue on myself for it. |
| 13:49 | <mabj> | Hi |
| 13:49 | <TabAtkins> | tobie: Do you know what the relation is between specref's biblio data and Bert's biblio.ref stuff? |
| 13:50 | <Ms2ger> | tobie, are these just gh/whatwg/xref merged into one file? |
| 13:50 | <tobie> | Ms2ger: think so. darobin would know more about this . |
| 13:51 | <darobin> | right, so the xrefs data is specref is just a rather old whatwg import; it would certainly be good to update it and make it more useful, as per TabAtkins's usage notably |
| 13:51 | <tobie> | TabAtkins: afaik relationship is historical: Bert's biblio ref stuff was used by darobin's respec.biblio which I ripped out turn into a service earlier this year. |
| 13:52 | <darobin> | re the bibrefs, they were initially imported from Bert's stuff, then massively edited, then the whatwg refs were merged in, then more editing, then the automatic W3C refs were imported too |
| 13:53 | <TabAtkins> | Okay, so using the bibref data should be approximately a superset. Cool. |
| 13:53 | <tobie> | TabAtkins: hopefully. |
| 13:54 | <TabAtkins> | So long as it's kept reasonably up-to-date, I'm happy. |
| 13:54 | <darobin> | it is |
| 13:54 | <TabAtkins> | kk |
| 13:55 | <darobin> | I think we could make it more manageable by splitting the source into lots of small files |
| 13:55 | <darobin> | but that's a backend detail |
| 13:56 | <TabAtkins> | All right, I'll handle this later: https://github.com/tabatkins/bikeshed/issues/86 |
| 13:56 | <darobin> | sweet |
| 13:57 | <TabAtkins> | darobin: It's okay if I don't use your API, right? Bikesheed needs to be able to run without network. |
| 13:57 | <TabAtkins> | So I'd just download the file locally. |
| 13:57 | <darobin> | having a bunch of preprocessors flourish is good, but the stupid work-intensive stuff should be shared if possible |
| 13:57 | <darobin> | TabAtkins: yeah, you can just grab a snapshot |
| 13:57 | <TabAtkins> | kk |
| 13:57 | <TabAtkins> | And yeah, I agree. |
| 13:58 | <darobin> | TabAtkins: GETting the endpoint without parameters gives you a dump |
| 13:58 | <TabAtkins> | Cool. |
| 13:58 | <darobin> | I recommend that over getting the GH content because we reserve the right to change how that's organised |
| 13:58 | <TabAtkins> | Okay. |
| 13:58 | <tobie> | + the data is already transformed quite a bit. |
| 13:58 | <TabAtkins> | We should work on merging the xref stuff too, though. Shepherd's data is much richer and more useful. |
| 13:58 | <darobin> | definitely |
| 13:58 | <tobie> | agreed. |
| 13:59 | <darobin> | maybe this should be moved out of tobie-space somewhere where we can more easily collaborate on it |
| 13:59 | <Ms2ger> | Does it insist on linking to outdated specs? |
| 13:59 | <darobin> | Ms2ger: specref is not opinionated there, it gives you a choice |
| 13:59 | <darobin> | I'm not sure if it gives enough of a choice yet, but if not it will |
| 13:59 | <TabAtkins> | No. Within W3C space, Shepherd maintains both an ED and TR link. |
| 13:59 | <darobin> | it basically knows about multiple version for a document |
| 14:00 | <darobin> | oh, you were talking about Shepherd, sorry |
| 14:00 | <Ms2ger> | How about w3c forks? |
| 14:00 | <TabAtkins> | Those are separate specs. If Shepherd is parsing them, then they'll just be more definition sources. |
| 14:00 | <darobin> | Ms2ger: forks of the ED? I reckon otherwise it might be TR? |
| 14:01 | <TabAtkins> | (Possibly requiring disambiguation.) |
| 14:01 | <TabAtkins> | There's no preference for anything, though, beyond some special-casing of CSS2.1/SVG1.1 things. |
| 14:01 | <tobie> | darobin: moving specref to gh.com/w3c is on my todo list, but far from the top, unfortunately. |
| 14:02 | <darobin> | tobie: I could easily move the repo, but I guess that won't help with the nodejitsu bit |
| 14:02 | <tobie> | Exactly. |
| 14:03 | <darobin> | just give me your nodejitsu admin password and all will be fine |
| 14:03 | <darobin> | I *promise* |
| 14:04 | <tobie> | TabAtkins: where's the shepherd api endpoint got this x-ref stuff and what exactly is included in it? |
| 14:04 | <tobie> | (or more to the point: where can I read more about this?) |
| 14:04 | <zcorpan> | heycam: please help https://critic.hoppipolla.co.uk/showcomment?chain=615 |
| 14:05 | <TabAtkins> | Dunno how much docs plinss maintains on shepherd. |
| 14:05 | <TabAtkins> | But it just downloads and parses all the specs it knows about regularly (in the case of dvcs.w3.org specs, it has commit hooks for some repos that lets it parse within a few minutes). |
| 14:06 | <TabAtkins> | It shares definition extraction logic with Bikeshed, so you can read Bikeshed's docs to learn about that. |
| 14:07 | <Ms2ger> | zcorpan, so what's the question? |
| 14:08 | <zcorpan> | Ms2ger: i think, what does webidl require to happen for InterfaceObject.staticOperation.apply(null, args) |
| 14:09 | <Ms2ger> | zcorpan, the this value doesn't matter at all for static operations |
| 14:10 | <heycam> | Ms2ger, zcorpan, correct |
| 14:10 | <Ms2ger> | So you basically can't test anything |
| 14:10 | <heycam> | well you can test passing funny values and checking that the method is still run |
| 14:11 | <heycam> | (as the first argument to .call) |
| 14:11 | <darobin> | but that requires knowing some good jokes |
| 14:11 | <Ms2ger> | heycam, the static operation can throw TypeErrors if it likes |
| 14:11 | <Ms2ger> | heycam, so you can't assert that it doesn't |
| 14:11 | <heycam> | Ms2ger, sure. oh is this the generic idl tests, not knowing what the exact function is? |
| 14:11 | <Ms2ger> | Right |
| 14:12 | <heycam> | ok then yes |
| 14:12 | <heycam> | maybe you could bake in a function you know will never throw TypeError? |
| 14:13 | <Ms2ger> | As part of your test suite, sure |
| 14:13 | <heycam> | (maybe I do already) |
| 14:13 | <zcorpan> | ok thx |
| 14:13 | <annevk> | merging XMLHttpRequest and Fetch... |
| 14:14 | <annevk> | this is why people get upset when you change the invariants |
| 14:19 | <tobie> | TabAtkins: thanks. |
| 14:36 | <annevk> | I think the end might be in sight... |
| 14:36 | <annevk> | I mean, the point where everyone will start complaining about how it's all different and has bugs |
| 14:43 | <jgraham> | Is that "the end" as in "the point where you die and then are eaten by the bugs you created"? |
| 14:47 | <annevk> | jgraham: hard to predict the future |
| 15:01 | <zcorpan> | TabAtkins: is it intended to invoke bikeshed as "bikeshed" or "bikeshed.py" in Makefile? i installed it using sudo python setup.py install and the former only works, but for dirk only the latter works |
| 15:01 | <TabAtkins> | If the thing has been installed, "bikeshed" works. If it hasn't, bikeshed.py exists as a launcher. |
| 15:02 | <TabAtkins> | I don't use and don't understand Makefiles, so I can't help you with that. |
| 15:04 | <zcorpan> | ok, thx |
| 15:49 | <annevk> | When there's more example than normative text, you gotta wonder... http://dev.w3.org/csswg/css-snappoints/ |
| 15:52 | <annevk> | Are there any browser vendor blogs out there that don't read like press releases? |
| 16:15 | <annevk> | Whoa, I got rid of the XMLHttpRequest task source |
| 16:26 | <annevk> | Aight, landed. |
| 16:30 | <annevk> | Initial breakage fixes landed. |
| 16:37 | <sangwhan__> | annevk: why is there a w3c clone of the url spec? |
| 16:37 | <Ms2ger> | sangwhan__, uh-oh... |
| 16:37 | <annevk> | sangwhan__: is there? |
| 16:37 | sangwhan__ | notes a off record answer is fine, just want to know which one to follow as I might have to make some changes to GURL |
| 16:38 | <Ms2ger> | sangwhan__, follow the whatwg one :) |
| 16:38 | <Ms2ger> | What channel did you think you were in? ;) |
| 16:38 | <annevk> | sangwhan__: http://url.spec.whatwg.org/ is the only one with maintenance to my knowledge |
| 16:38 | <sangwhan__> | annevk: the w3c one i bumped into, which has your name on it in big bold text :) |
| 16:40 | sangwhan__ | wonders if i plucked the tiger's whisker |
| 16:40 | <sangwhan__> | So we have a problem that needs solving, namely pointer events (thank you IPR) not acknowledging touch events exist, but implementations that have to deal with pointer/mouse/touch all in one merry basket |
| 16:42 | <sangwhan__> | And then there are the even less fortunate ones who have to deal with spatnav only browsing, which have no clue on what kind of compat events we need to fire |
| 16:45 | <annevk> | sangwhan__: hmm, pointer? |
| 16:45 | <annevk> | sangwhan__: https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html maybe? |
| 16:45 | <sangwhan__> | annevk: yeah, that thing |
| 16:45 | <sangwhan__> | annevk: "the editor" is where i thought something is strange |
| 16:46 | <annevk> | sangwhan__: the date is a clue |
| 16:47 | <sangwhan__> | annevk: ah, a clue |
| 16:48 | <annevk> | sangwhan__: so yeah, you want the URL Standard, the rest is the W3C doing things without my permission (but with permission from the URL Standard's copyright) |
| 16:49 | <sangwhan__> | annevk: i'm not gonna ask why nor who, i figured something was funny |
| 16:49 | <annevk> | sangwhan__: it's all quite public |
| 16:50 | <annevk> | sangwhan__: see e.g. http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/ |
| 16:50 | <annevk> | sangwhan__: and there's some posts on the web about copyright and such |
| 16:50 | <sangwhan__> | annevk: i don't follow i18n, so had no idea - i just happened to bump into it and got a bit curious. guess i'm late to the party. |
| 16:57 | <MikeSmith> | zcorpan: so about that function in idlharness that's attempting to test the "if this is null, throw a TypeError" requirement in the WebIDL spec for the non-static case |
| 16:58 | <MikeSmith> | it throws a TypeError for the static case too |
| 16:58 | <MikeSmith> | the window[this.name].prototype[member.name].apply(null, args) part |
| 16:59 | <zcorpan> | MikeSmith: isn't that because window[this.name].prototype[member.name] is undefined in the static case? |
| 16:59 | <MikeSmith> | for the static case, it throws "window[this.name].prototype[member.name] is undefined" |
| 16:59 | <MikeSmith> | yeah |
| 16:59 | <zcorpan> | right, that's expected |
| 16:59 | <MikeSmith> | yeah |
| 16:59 | <MikeSmith> | but for the non-static case, it throws a TypeError with the message, "close' called on an object that does not implement interface Notification" |
| 17:00 | <MikeSmith> | which, that doesn't seem like what I'd expect the message to be |
| 17:01 | <zcorpan> | yeah, that's also expected. normal operations require this to be the right kind of object |
| 17:01 | <MikeSmith> | ok |
| 17:01 | <MikeSmith> | well, I'm just wondering if there's any way I can make that test more specific |
| 17:02 | <MikeSmith> | so that it doesn't pass for the static case |
| 17:02 | <zcorpan> | there are more things that can be tested in the normal case, but i think nothing that can safely be tested in the static case |
| 17:02 | <MikeSmith> | (since all that current test is doing is checking for any kind of TypeError at all) |
| 17:02 | <MikeSmith> | ok |
| 17:03 | <MikeSmith> | so I guess then I should just put if (!member["static"]) around it and leave it that |
| 17:03 | <zcorpan> | yeah |
| 17:04 | <MikeSmith> | ok |
| 17:04 | <MikeSmith> | thanks |
| 17:06 | <zcorpan> | annevk: i looked through the xhr+fetch diff but didn't get much wiser :-) maybe you can check if cssom is using fetch correctly? |
| 17:06 | <TabAtkins> | I'm confused and betrayed by the Snap Points spec, because I was literally in the process of writing that very thing this week. ^_^ |
| 17:07 | <TabAtkins> | Damn Rossi, all putting me off with "oh no, I need to check with Legal before you write the spec" WHEN HE WAS WRITING IT BEHIND ME BACK THE WHOLE TIME |
| 17:07 | <TabAtkins> | *MY |
| 17:07 | <TabAtkins> | (I'm not a leprechaun.) |
| 17:07 | <hober> | no no, it's so much better with you doing an awful fake irish accent |
| 17:07 | <TabAtkins> | (Typing all caps on a Pixel is hard, as there's no Caps Lock.) |
| 17:07 | <Ms2ger> | [citation needed] |
| 17:08 | <TabAtkins> | Ms2ger: You've seen me. I'd be the tallest leprechaun ever. |
| 17:24 | <Hixie_> | annevk: multipage thingy seems broken |
| 17:24 | <annevk> | le sigh |
| 17:26 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/do-multipage-complete-update |
| 17:26 | <annevk> | Resolving www.whatwg.org... 2607:f298:1:105::340:cd86, 69.163.222.251 |
| 17:26 | <annevk> | Connecting to www.whatwg.org|2607:f298:1:105::340:cd86|:80... connected. |
| 17:26 | <annevk> | HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable |
| 17:26 | <annevk> | The file is already fully retrieved; nothing to do. |
| 17:27 | <annevk> | oh fuck sorry |
| 17:31 | <annevk> | MikeSmith: is http://code.google.com/p/html5/source/browse/trunk/spec-splitter/spec-splitter.py still the latest copy of spec-splitter.py? |
| 17:31 | <Hixie_> | wow, don't see 416 very often |
| 17:31 | <Hixie_> | looks like something worked, fwiw |
| 17:36 | <TabAtkins> | annevk: I'm interested in adding splitting functionality to Bikeshed. Is there good documentation on the existing tools? |
| 17:37 | <annevk> | TabAtkins: no |
| 17:37 | <TabAtkins> | Also: how do I respond to a mailing list thread that I'm not already subscribed to, with the least chance of accidentally splitting it? |
| 17:37 | <TabAtkins> | annevk: Awesome. |
| 17:37 | <TabAtkins> | webkit-dev, if it matters. |
| 17:38 | <annevk> | TabAtkins: everything non-vital is a hack and receives no active maintenance, because people want to work on other things |
| 17:38 | <TabAtkins> | annevk: All right. In that case, I guess I'll just need to figure out what people want out of a spec splitter. |
| 17:38 | <annevk> | TabAtkins: subscribe to the list |
| 17:38 | <annevk> | TabAtkins: spec-splitter.py above is what HTML uses |
| 17:38 | <Hixie_> | TabAtkins: have someone forward you the thread in multipart digest form, then reply to the e-mail from that |
| 17:39 | <annevk> | TabAtkins: it was written by Philip` back in the day |
| 17:39 | <TabAtkins> | Hixie_: That's a decent idea. I wonder if Gmail supports that? |
| 17:39 | <Hixie_> | haha no. |
| 17:39 | <Hixie_> | :-) |
| 17:39 | <Hixie_> | pine does though :-) |
| 17:39 | <MikeSmith> | annevk: that is the latest, yeah |
| 17:39 | <TabAtkins> | Man, why you gotta get my hopes up like that. |
| 17:39 | <Hixie_> | :-( |
| 17:39 | <annevk> | MikeSmith: I a dded a comment |
| 17:40 | <Hixie_> | i don't know if gmail does threading right at all |
| 17:40 | <annevk> | MikeSmith: http://code.google.com/p/html5/source/detail?r=202 |
| 17:40 | <Hixie_> | there's a bunch of headers you have to get right for threading to work properly |
| 17:40 | <annevk> | MikeSmith: I don't really know how to commit to that repo... |
| 17:40 | <Hixie_> | is |e => { }| modern shorthand for |function (e) { }| ? |
| 17:40 | <Hixie_> | or is it something more? |
| 17:40 | <Ms2ger> | Hixie_, roughly |
| 17:40 | <annevk> | we should maybe put spec-splitter on github.com/whatwg too |
| 17:41 | <MikeSmith> | annevk: svn commit? |
| 17:41 | <Ms2ger> | Hixie_, it also doesn't get its own |this| |
| 17:41 | <annevk> | just like web-apps-tracker |
| 17:41 | <MikeSmith> | annevk: yeah |
| 17:41 | <Hixie_> | Ms2ger: |function (e) { }.bind(this)| ? |
| 17:41 | <MikeSmith> | Google Code is the new Sourceforge |
| 17:41 | <Ms2ger> | Hixie_, and it returns its expression like in |x => x*x| |
| 17:42 | <Ms2ger> | TabAtkins, you get the right headers from the archive, write it out in a text editor and send it with telnet? :) |
| 17:42 | <Hixie_> | Ms2ger: so |e => { statements; expr }| is |function (e) { statements; return expr; }.bind(this)| ? |
| 17:42 | <TabAtkins> | Ms2ger: Seems reasonable. |
| 17:42 | <Ms2ger> | Hixie_, I think that's about it; I haven't followed that closely |
| 17:42 | <TabAtkins> | Hixie_: It's a little bit more, but basically yeah. Important difference is that it doesn't shadow `this`. |
| 17:43 | <TabAtkins> | It just lexically binds `this` like a normal variable. |
| 17:43 | <Hixie_> | TabAtkins: it captures |this| instead of binding it? |
| 17:43 | <Hixie_> | is the {...} necessary? Ms2ger's example didn't have it, but i don't understand what that means |
| 17:44 | <TabAtkins> | Yeah. Also, you can omit the braces if the body is just a single expression, and in that case, omit the "return" too. |
| 17:44 | <TabAtkins> | [1,2,3].map(x=>x*2) |
| 17:44 | <jgraham> | And you can't use it as a generator aiui |
| 17:44 | <Ms2ger> | Well, you can't use function() {} as a generator either |
| 17:44 | <Ms2ger> | Needs function*... aiui |
| 17:44 | <TabAtkins> | Yup. |
| 17:44 | <Hixie_> | oh ok, so |e => { ... }| is |function (e) { ... }.bind(this)| but |e => f| is |function (e) { return f }.bind(this)| ? |
| 17:45 | <Hixie_> | wtf is function* |
| 17:45 | <Ms2ger> | Generators |
| 17:45 | <TabAtkins> | Generator function. From Python. |
| 17:45 | <MikeSmith> | zcorpan: ok all issues for https://critic.hoppipolla.co.uk/r/351 now addressed I think |
| 17:45 | <Hixie_> | oh "yield" no longer makes a generator magically? |
| 17:45 | <TabAtkins> | Nah. |
| 17:45 | <Ms2ger> | Right |
| 17:45 | <jgraham> | Wait, what? There's a special form for declaring that a function will be a generator |
| 17:45 | <Hixie_> | well that's an improvement. Not sure why you'd use "function*" instead of "generator" but ok |
| 17:45 | <TabAtkins> | Hixie_: Reserved words (or lack of them). |
| 17:45 | <zcorpan> | MikeSmith: and reviewed |
| 17:45 | <jgraham> | Not sure that's really better |
| 17:45 | <Ms2ger> | Hixie_, doesn't distinguish based on the {}s, but on the number of expressions, I think |
| 17:46 | <Hixie_> | Ms2ger: of {expr} is the same as expr? interesting |
| 17:46 | <TabAtkins> | Ms2ger: Ah, so [1,2,3].map(x=>{x*2}) is okay too? |
| 17:46 | <Domenic_> | no |
| 17:46 | <Hixie_> | is there, like, a spec for this? :-) |
| 17:46 | <TabAtkins> | Yes, ES6. |
| 17:46 | <Hixie_> | url? |
| 17:46 | <Ms2ger> | Apparently not |
| 17:46 | <TabAtkins> | But I haven't read it. |
| 17:46 | <Domenic_> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions |
| 17:47 | <Hixie_> | thanks Domenic_ |
| 17:47 | <Ms2ger> | Hixie_, looks like it does look at {}s, nvm that last bit |
| 17:47 | <Hixie_> | Domenic_: is there somewhere to file bugs on that text? i found a typo |
| 17:48 | <Domenic_> | Hixie_: https://bugs.ecmascript.org/ |
| 17:48 | <Hixie_> | thanks |
| 17:48 | <Ms2ger> | We should get jorendorff to add a widget like html has |
| 17:49 | <Domenic_> | There are lots of typos/little inconsistencies, as he's focusing on getting all the semantics in by end of year. But yeah filing them is good if you have the time. |
| 17:55 | <zcorpan> | https://github.com/w3c/web-platform-tests/pull/135 looks epic. i wonder if the tests are still valid since <template> was integrated in html |
| 17:58 | <jgraham> | zcorpan: Seems to be closed (it might still be wrong now ofc) |
| 17:58 | <zcorpan> | right |
| 17:58 | <Hixie_> | this is quite dense spec text. i don't think i'll be able to file anything but typos :-) |
| 17:58 | <Hixie_> | (can't file anything until bugzilla mails me a password, of course) |
| 18:00 | <Domenic_> | Hixie_: check spam folder, I am pretty sure my password went there. And yes, pretty dense :-/ |
| 18:02 | <Hixie_> | nope |
| 18:05 | <Domenic_> | What's the most semantic way to mark up tabs again? Kinda surprised this wasn't in "common idioms without dedicated elements"... |
| 18:06 | <hober> | Domenic_: <div><section><h1>tab name</h1>...</section><section><h1>tab name</h1>...</section>...</div> ? |
| 18:07 | <Domenic_> | hober: seems right, although tricky to style. thanks. |
| 18:07 | <Hixie_> | most semantic way is to not mark them up at all, or maybe use <fieldset> or some such, and then do overflow:tabs (but that doesn't exist yet) or bind to it with a custom Web Component (but that doesn't really exist yet either) |
| 18:07 | <Hixie_> | failing that... hober's markup is probably reasonable |
| 18:08 | <Hixie_> | fundamentally the key is to realise that tabs are a device-specific rendering of an overflow mechanism (consider what it'd be like in an aural context) |
| 18:09 | <Hixie_> | stylistic question for people who know the JS spec. Is "[[DefineOwnProperty]]" considered just a word of the english language, or is it considered code, or a special term (<i>), or something else? |
| 18:14 | <Domenic_> | Hixie_: from what I can tell internal methods and properties (i.e. [[things]]) are not marked up specially. |
| 18:14 | <Hixie_> | yeah, that was my conclusion too |
| 18:14 | <Hixie_> | weirdly, even property descriptors seem to just be prose |
| 18:14 | <Hixie_> | ugly ugly prose :-P |
| 18:21 | <zcorpan> | MikeSmith: ? https://github.com/w3c/testharness.js/pull/45 no merge? |
| 18:22 | <MikeSmith> | zcorpan: I rebase -i'ed/squashed the commits and pushed that |
| 18:23 | <MikeSmith> | I guess there's probably some other way I should do it.. |
| 18:23 | <zcorpan> | dunno, i usually click the green button :-) |
| 18:23 | <MikeSmith> | did "git push upstream HEAD:master" where upstream is git⊙gc:w3c/testharness.js.git |
| 18:24 | <MikeSmith> | yeah I don't like those buttons |
| 18:24 | <MikeSmith> | or GUIs |
| 18:24 | <MikeSmith> | I like consoles and curses |
| 18:25 | <MikeSmith> | like Hixie, I like pine. Except I spell it "mutt" |
| 18:27 | <MikeSmith> | zcorpan: I'm not looking forward so much to Hixie updating the ABNF for the <!-- stuff in <script> |
| 18:28 | <zcorpan> | bright side, now is an opportunity to make the rules simpler |
| 18:29 | <MikeSmith> | guess so |
| 18:30 | <MikeSmith> | zcorpan: anyway thanks for the review |
| 18:31 | <MikeSmith> | I plan to spend all my time at TPAC writing tests |
| 18:31 | <zcorpan> | nice |
| 18:31 | <Ms2ger> | At least that time will be spent usefully |
| 18:32 | <MikeSmith> | yeah plus I'm not counting on having usable internet access |
| 18:32 | <MikeSmith> | so it's either talk to people or write tests |
| 18:33 | <Ms2ger> | Eh, talking to people |
| 18:43 | <annevk> | Hixie_: you might have to email Allen directly for a Bugzilla account there |
| 19:38 | <jgraham> | I plan to spend all my time at TPAC whining about TPAC |
| 19:38 | <jgraham> | Not really |
| 19:38 | <jgraham> | Or do I? |
| 19:38 | <Ms2ger> | You will find out in the next episode of Standards Suck! |
| 19:38 | <annevk> | Best to just relax and hang out with MikeSmith |
| 19:39 | <annevk> | I guess we could take that time to record at least one episode, although if marcosc doesn't make it that'd be tricky |
| 19:40 | <marcosc> | I'm about to cancel everything |
| 19:40 | <annevk> | Oh you can? My stuff is non-refundable... |
| 19:40 | <marcosc> | I think I can get the hotel back |
| 19:40 | <marcosc> | And should be able to get the registration fee back from w3c |
| 19:40 | <Ms2ger> | With so few people going, maybe the wifi will work |
| 19:40 | <marcosc> | heh |
| 19:40 | <annevk> | I'm gonna give it a few more days. |
| 19:41 | <marcosc> | the flight was not very expensive (relatively speaking) |
| 19:43 | <marcosc> | heh, there are at least 6 ways to access bookmarks in browsers. |
| 19:43 | <annevk> | I'd actually really like a web platform unconference in the bay area someday. I should probably do some reaching out to other companies to how hard that'd be to organize. Something like Edgeconf but more about standards and more parallel (small) sessions. |
| 19:45 | <marcosc> | that would be nice |
| 19:45 | <annevk> | Oh, and alongside we'd visit the zoo or a museum or some such for fun / team building. Best not do heated discussion all the time if you're only with each other for limited time. |
| 19:45 | <marcosc> | I like zoos |
| 19:47 | Ms2ger | puts marcosc into a zoo :) |
| 19:47 | <marcosc> | I thought that's where I was already |
| 19:50 | <Ms2ger> | http://dev.w3.org/CSS/biblio/biblio.ref |
| 20:21 | <annevk> | zcorpan: I guess the question is whether you want incremental loading of style sheets or not |
| 20:22 | <annevk> | zcorpan: or more relevant, whether that's observable |
| 20:22 | <annevk> | zcorpan: seems kinda observable with a timing attack in HTML using offsetWidth or some such, dunno |
| 20:24 | <zcorpan> | annevk: i *think* API-wise it shouldn't be observable, the whole style sheet should be applied atomically |
| 20:25 | <annevk> | zcorpan: right |
| 20:25 | <annevk> | If people want to bikeshed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23586 |
| 20:25 | <zcorpan> | but obviously it's observable when subresources are fetched. but that can be considered optimization magic |
| 20:26 | <zcorpan> | searchObj seems ok to me |
| 20:27 | <Hixie_> | annevk: they don't accept bugs from the public...? |
| 20:27 | <zcorpan> | or searchObject |
| 20:27 | <zcorpan> | like srcObject |
| 20:28 | <annevk> | Hixie_: I think so, but the registration system is broken or some such |
| 20:28 | <annevk> | Hixie_: at least, lots of people have had problems with it thus far |
| 20:28 | <annevk> | Hixie_: they should maybe just stop bothering and outsource to W3C like we did |
| 20:28 | <Hixie_> | ah ok |
| 20:28 | <Hixie_> | do you know Allen's e-mail? |
| 20:29 | <annevk> | pm'd |
| 20:31 | <Hixie_> | thanks |
| 20:31 | <zcorpan> | W3C - administrating other standards organizations' bugzillas to their full potential |
| 20:39 | <Domenic_> | annevk: I kind of like searchObj? |
| 20:39 | <annevk> | zcorpan: is srcObject what <video> has these days? |
| 20:40 | <annevk> | or HTMLMediaElement I suppose |
| 20:40 | <annevk> | suddenly rain |
| 20:40 | <zcorpan> | annevk: i think it was proposed but is not in the spec yet |
| 20:41 | <zcorpan> | so we could call that srcObj if we like |
| 20:41 | <annevk> | http://dev.w3.org/2011/webrtc/editor/getusermedia.html#direct-assignment-to-media-elements |
| 20:42 | <zcorpan> | oh |
| 20:42 | <Domenic_> | I feel like there must be a brilliant bikeshed color here waiting to be discovered (for the property formerly known as query). |
| 20:43 | <annevk> | zcorpan: we could ask for srcObj; precedent has srcdoc, srclang |
| 20:45 | <zcorpan> | i don't see srcObject implemented on video or source in blink or gecko |
| 20:45 | <annevk> | zcorpan: emailed |
| 20:50 | <annevk> | roc: you want a wiki account? |
| 21:05 | <roc> | um |
| 21:05 | <roc> | sure |
| 21:05 | <roc> | zcorpan: Gecko has mozSrcObject |
| 21:06 | <zcorpan> | when will you stop with these prefixes? :-P |
| 21:07 | <Domenic_> | annevk: some guy on Twitter says "queryComponent" "since this is what the RFC uses" |
| 21:08 | <annevk> | Domenic_: meh, https://tools.ietf.org/html/rfc3986#section-3.4 |
| 21:08 | <annevk> | Also, "the RFC" is obsoleted by this standard, so... |
| 21:09 | <Domenic_> | ya |
| 21:10 | <Domenic_> | queryPairs? |
| 21:10 | <annevk> | I think I start liking queryObj more... but I guess we can give it some time. |
| 21:11 | <annevk> | Or only expose .query on URL objects. That's another option. |
| 21:11 | <Domenic_> | seems sad, poor HTMLAnchorElements |
| 21:11 | <annevk> | Yeah, and you kinda want it for window.location too which would require more weirdness... |
| 21:11 | <annevk> | And I don't think we want to rename ParentNode#query |
| 21:12 | <annevk> | So yeah, searchObj |
| 21:13 | <Domenic_> | yeah seems fine to me, only slightly awkward |
| 21:13 | <zcorpan> | i see no relevant actual instances of srcObject or mozSrcObject in webdevdata (june dataset) |
| 21:14 | <Domenic_> | queryPairs? |
| 21:16 | <roc> | zcorpan: we have stopped, mostly, but this is quite old |
| 21:16 | <zcorpan> | ok |
| 21:17 | <annevk> | Suggested renaming in http://lists.w3.org/Archives/Public/public-media-capture/2013Oct/0121.html btw |
| 21:22 | <zcorpan> | sigh... https://www.w3.org/Bugs/Public/show_bug.cgi?id=23596 |
| 21:35 | <Domenic_> | queryParams |
| 21:44 | <zcorpan> | Hixie_: also in regexp literals |
| 22:02 | <Hixie_> | zcorpan: ta |
| 22:12 | <matjas> | Hixie_: seems a bit unmaintainable to hardcode all the cases where it needs to be escaped… can’t you just say it should always be escaped? |
| 22:14 | <Hixie_> | can you escape it in the case of "if (3 < 4)" ? |
| 22:14 | <matjas> | Hixie_: only in X(HTML)… but you could just say escape it whenever it’s followed by "/script" |
| 22:15 | <Hixie_> | i already said that earlier in the sentence |
| 22:15 | <zcorpan> | if ( 3<script ) is also problematic though |
| 22:15 | <Hixie_> | hm, yeah, that means escaping < is a non-starter |
| 22:15 | <matjas> | Hixie_: this can also happen in a property name literal in an object literal (those are like a string) or in ES6 template literals etc. etc. |
| 22:16 | <Hixie_> | what's a "property name literal"? |
| 22:16 | <matjas> | the `'foo'` in `var x = { 'foo': 42 }` is represented by a `Literal` in the AST |
| 22:16 | <Hixie_> | isn't that just a string? |
| 22:16 | <matjas> | not really |
| 22:16 | <Hixie_> | how does it differ? |
| 22:17 | <matjas> | Hixie_: string literals can be replaced with a reference to a variable. in this case that’s not possible |
| 22:17 | <matjas> | but this was just an example |
| 22:18 | <Hixie_> | well sure, but a string literal isn't a variable |
| 22:18 | <matjas> | listing all the different cases where escaping is needed seems like a maintainability burden |
| 22:18 | <Hixie_> | it's a string literal |
| 22:19 | <Hixie_> | you can use a string literal in an expression or where you need a property name literal, no? |
| 22:19 | <Hixie_> | i mean, aren't they both strings? |
| 22:19 | <Hixie_> | anyway it's academic, as zcorpan says, it won't work anyway |
| 22:26 | <matjas> | in the `3<script` case, adding a space after `<` could be considered as “escaping” |
| 22:27 | <Hixie_> | <!-- is never valid JS, right? |
| 22:27 | <Hixie_> | so so long as you always escape it, you'll always be fine. |
| 22:28 | <Hixie_> | same with </script> |
| 22:28 | <Hixie_> | which is what the spec already suggests |
| 22:29 | <Hixie_> | (though i guess the same could be said for the other case...) |
| 22:29 | <Hixie_> | (bah) |
| 22:31 | <Hixie_> | why on earth does 'input' not apply to type=radio, checkbox, and file? anyone know? |
| 22:39 | <matjas> | Hixie_: <!-- is a singlelinecomment in JS http://javascript.spec.whatwg.org/#comment-syntax |
| 23:05 | <zewt> | matjas: that's an impressively concise piece of insanity |
| 23:27 | <zewt> | annoyed at having to say "xxx-related use cases" instead of "xxx use cases" Every Single Time, or some dictionary lawyer immediately jumps out of a bush going THAT'S NOT A USE CASE |