| 00:08 | <nessy> | cool :-) |
| 00:08 | <nessy> | now I can remove all the webvtt stuff from the html spec, too |
| 05:27 | <Hixie> | is there a better way of checking that of three booleans, only one is true, than (not ((a and b) or (a and c) or (b and c)) ? |
| 05:45 | <SimonSapin> | Hixie: your expression is also true if they’re all false, is that what you want? |
| 05:46 | <jtcranmer> | Hixie: (a xor b) and (b xor c) and (a xor c)? |
| 05:47 | <jtcranmer> | hmm |
| 05:47 | <jtcranmer> | (a xor b xor c) and not (a and b and c) ? |
| 05:47 | <heycam> | Hixie, if it's JS and you know your variables are booleans, you can do `a + b + c == 1` |
| 05:50 | <Hixie> | it's perl and they're really integers |
| 05:51 | <Hixie> | SimonSapin: they can't be all false in this case, but good point |
| 05:51 | <Hixie> | i guess i could do a !! trick |
| 05:51 | <Hixie> | !!a + !!b + !!c == 1 |
| 08:59 | <annevk5> | marcosc: that success/error-callback thing in Midi looks like a future |
| 09:02 | <jgraham> | annevk: You have turned into a bot |
| 09:02 | <jgraham> | :) |
| 09:02 | <annevk> | jgraham: I don't understand the question, "You have turned into a bot" |
| 09:02 | <jgraham> | Just need to add another bot that responds to "X looks like a future" with "and futures look like monads" |
| 09:05 | <Ms2ger> | And monads look like my head just exploded, again |
| 09:09 | <jgraham> | (fwiw http://stackoverflow.com/a/2704795 seems quite nice) |
| 09:10 | <Ms2ger> | Maybe I should read it... |
| 09:10 | <Ms2ger> | Once I figured out existential types |
| 09:10 | <jgraham> | (if one is looking for a practical introduction to Monads, albeit in C#) |
| 09:10 | <jgraham> | (Not that I really claim to understand and thing) |
| 09:11 | <jgraham> | *anything |
| 09:11 | <Ms2ger> | And that's a doctor... |
| 09:11 | <annevk> | just like Future is Future<any, any> I guess |
| 09:12 | <annevk> | and you can make it Future<MediaStream, DOMError> |
| 09:12 | <jgraham> | (but what little I do underestand makes it clear why futures could/should/do form a monad) |
| 09:12 | <annevk> | and all the future composition stuff still applies, etc. |
| 09:15 | <asmodai> | Do any of you know of a bug with Chrome and refreshing of pages that at some point causes it to lose its styling of said page? |
| 09:28 | <jgraham> | darobin: "Any reason you *should* grab it and deploy"? Well maybe if you are insane and like running untested code in production? |
| 09:30 | <darobin> | jgraham: there's another way of doing development? |
| 09:30 | <jgraham> | So I hear :) |
| 09:30 | <darobin> | jgraham: to clarify, my question was because I couldn't tell from your comments how prod-ready you thought it was |
| 09:30 | <darobin> | you said untested, but at the same time you seemed to say it was pretty close to being ok |
| 09:30 | <Ms2ger> | The usual Knuth quote? |
| 09:31 | <Ms2ger> | "Beware of bugs in the above code; I have only proved it correct, not tried it." |
| 09:31 | <darobin> | "Who are you and what are you doing in my bedroom?" // that one? |
| 09:31 | <jgraham> | It's untested. So it probably has all the usual types of errors that untested python code has e.g. arguments not matching, etc. |
| 09:31 | <darobin> | hehe |
| 09:31 | <jgraham> | But I don't know of any missing parts to the code |
| 09:31 | <darobin> | for reference http://xkcd.com/163/ |
| 09:32 | <darobin> | ok, so maybe a bit of testing before deployment would be useful |
| 09:32 | <jgraham> | I recommend setting up a test repo somewhere, mirroring that somewhere (doesn't even have to be public facing) and seeing if the commands work as expected |
| 09:32 | <jgraham> | and it responds in the right way to new PRs and so on |
| 09:33 | <jgraham> | I should have done this, but I did something else instead :) |
| 09:33 | <jgraham> | No idea what |
| 09:33 | <Ms2ger> | Drink? |
| 11:44 | <zcorpan> | Ms2ger: here |
| 11:45 | <jgraham> | That's some slow-acting magic right there |
| 11:45 | <odinho> | glacier |
| 12:14 | <Ms2ger> | zcorpan, still here? |
| 12:14 | <zcorpan> | Ms2ger: yep |
| 12:14 | <Ms2ger> | http://w3c-test.org/web-platform-tests/master/html/webappapis/scripting/processing-model-2/body-onerror-compile-error-data-url.html |
| 12:15 | <Ms2ger> | Since you submitted that test, want to explain it? :) |
| 12:18 | <zcorpan> | Ms2ger: explain why the arguments should be tainted? or something else? |
| 12:18 | <Ms2ger> | I guess that's what it comes down to, yes |
| 12:22 | <zcorpan> | Ms2ger: it seems the spec has changed since the test was written |
| 12:22 | <Ms2ger> | \o/ |
| 12:23 | <zcorpan> | Ms2ger: when it was written, the "report the error" algorithm compared the origin of the URL of the script with the origin of the script's document to decide whether to mute |
| 12:24 | <Ms2ger> | I see |
| 12:24 | <zcorpan> | Ms2ger: now the spec supports CORS and the muted-ness of data: has changed |
| 12:25 | <Ms2ger> | You don't happen to feel like updating the test? :) |
| 12:26 | <zcorpan> | first i want to ponder if the spec change can cause new security problems |
| 12:27 | <zcorpan> | the only thing i can think of is something that redirects to a data: URL, but that should be considered cross-origin (known bug) |
| 12:29 | <zcorpan> | there should be some CORS test here too |
| 12:31 | <zcorpan> | is the process the same for minor bugfixes like this as for any other test submission? |
| 12:32 | <Ms2ger> | I think so, yes |
| 12:32 | <zcorpan> | ok |
| 12:33 | <darobin> | the process is whatever we want to make it, keep that in mind |
| 12:33 | jgraham | wants the process to be "darobin reviews all tests" |
| 12:33 | <darobin> | as a rule, if it's substantive even if small I think it's better if there's a bit of review |
| 12:33 | darobin | thinks jgraham missed the "we" bit :) |
| 12:34 | <darobin> | but if it's just a quick and obvious fix I would say you can just push |
| 12:34 | <darobin> | or, put differently, the process is "be fucking sensible" :) |
| 12:34 | <jgraham> | My view is that getting review for small changes is no big deal because small changes can be reviewed synchronously anyway |
| 12:34 | <zcorpan> | my biggest issue is naming the branch :-P |
| 12:34 | <zcorpan> | submission/Opera/onerror-data-url-muted-bugfix |
| 12:35 | <zcorpan> | what if i want to do another bugfix? |
| 12:35 | <jgraham> | But it is OK to just push whitespace changes and typo fixes and similar |
| 12:35 | <Ms2ger> | But what if the typo was essential to the test? |
| 12:36 | <jgraham> | Then you shouldn't have named a variable "outlinee" |
| 12:36 | <jgraham> | But seriously, it's OK to have failure modes |
| 12:36 | <jgraham> | I mean review is a long way from perfect |
| 12:37 | <Ms2ger> | :D |
| 12:37 | <jgraham> | But the goal is a) to reduce the incidence of bad tests and b) to make sure multiple people actually know what tests we have and how they work |
| 12:38 | <jgraham> | It isn't to prevent all possible errors |
| 12:38 | <jgraham> | (if we wanted that we would, um, well actually I don't know. |
| 12:38 | <jgraham> | Have formal proofs and tests in Coq?) |
| 12:39 | <odinho> | zcorpan: You don't need to call it that, because you should have the branch in your personal fork anyway. |
| 12:40 | Ms2ger | wonders why jgraham enjoys talking about Coq so much) |
| 12:40 | <MikeSmith> | cool, when I try to to start my firefox nightly, I just get a window with an error: "XML Parsing Error: undefined entity Location: chrome://browser/content/browser.xul Line Number 506, Column 9" |
| 12:40 | <odinho> | zcorpan: You can call the branch bamboo-bowser if you so please, and then do a PR. |
| 12:40 | <MikeSmith> | and then I don't get any browser chrome at all so can't actually navigate to anything |
| 12:40 | <odinho> | zcorpan: The reason we have the submission branches right now is because we had some stuff already submitted and needed branches for those :-) |
| 12:42 | <zcorpan> | odinho: but my branch name will be visible in the PR right? |
| 12:42 | <odinho> | zcorpan: Yes. :-) But not really highlighted. |
| 12:43 | <odinho> | zcorpan: So don't call your public branch too offensive things. |
| 12:43 | <darobin> | are we moving on to making profound jokes about how jgraham likes Coq? |
| 12:43 | <jgraham> | FWIW the only thing that's annoying in PR branch names is overuse of "master" |
| 12:43 | <jgraham> | git has local branches for a reason, people |
| 12:43 | <odinho> | zcorpan: You can, however, call your local ones offensive things, and then just push to a more neutral name for the public repo. :-) git push origin omg_i_hatez_jgraham:shiny_ponies |
| 12:43 | <jgraham> | This is not mercurial |
| 12:44 | <darobin> | MikeSmith: where we're going, the browser is everything — you don't need chrome. Firefox is just showing you the future there. |
| 12:44 | <zcorpan> | submission/odinhos-mom-so-fat-she-would-break-a-branch |
| 12:44 | <odinho> | zcorpan: You got it! :D |
| 12:44 | <darobin> | haha |
| 12:56 | <zcorpan> | Ms2ger: https://github.com/w3c/web-platform-tests/pull/82 |
| 12:56 | <Ms2ger> | Thanks |
| 13:43 | <annevk> | Ms2ger: I put fetch in a separate file for now |
| 13:44 | <annevk> | Ms2ger: and put all CORS references towards W3C/TR/cors |
| 13:44 | <annevk> | A little unfortunate that rewriting CORS takes the "living" bit out of it, but it was fairly stable anyway. |
| 13:57 | <Ms2ger> | annevk, *shrug* |
| 13:57 | <Ms2ger> | On another note, Hixie takes bug reports on IRC now? |
| 13:57 | <Ms2ger> | (re http://html5.org/tools/web-apps-tracker?from=7832&to=7833) |
| 13:57 | <annevk> | Ms2ger: shrug what? |
| 13:57 | <annevk> | Ms2ger: me making xref work again? |
| 13:57 | <Ms2ger> | annevk, CORS pointing to TR |
| 13:58 | <annevk> | Ms2ger: didn't really see a better way for now |
| 13:58 | <Ms2ger> | Yeah |
| 13:59 | <Ms2ger> | You're 80% done with killing it anyway, no? ;) |
| 13:59 | <annevk> | that's the Q2 goal, 80% is about the level of done-ness CORS has now, so then I can update the references and everything :) |
| 14:00 | <annevk> | One of the big problems with Fetch will be that the interface is somewhat different because we've used so many different conventions in the past |
| 14:02 | <darobin> | annevk: are you thinking of specific compatibility issues for new HTMLH1Element beyond toString()? |
| 14:03 | <darobin> | because I reckon it's not the end of the world if we say it that it always returns "[object HTMLHeadingElement]" |
| 14:04 | <darobin> | there's __proto__ but I'd be a bit surprised if that showed up |
| 14:05 | <gsnedders> | instanceof is more likely. |
| 14:05 | <gsnedders> | Or just constructor directly. |
| 14:05 | <darobin> | well instanceof HTMLHeadingElement would still be true |
| 14:05 | gsnedders | hasn't read enough context |
| 14:05 | <darobin> | the thing is I wonder if people actually access constructor for non-constructable objects |
| 14:06 | <jgraham> | I don't think there was any context given |
| 14:06 | <annevk> | darobin: no, just "change" is dangerous |
| 14:06 | <annevk> | when it comes to compat anyway |
| 14:06 | <annevk> | but we should try |
| 14:06 | <darobin> | yeah, I know, but we try to guess impact |
| 14:07 | <annevk> | jgraham: you're not reading your email synchronously with IRC? |
| 14:07 | <darobin> | I guess there could be people doing el.constructor === HTMLHeadingElement instead of instanceof |
| 14:07 | <Ms2ger> | annevk, quite the conservative :) |
| 14:08 | <annevk> | Ms2ger: can we kill hasAttributes() now? |
| 14:08 | <Ms2ger> | I'd be happy to |
| 14:08 | <annevk> | Ms2ger: how hard it is to measure its usage? |
| 14:09 | <annevk> | Ms2ger: we could at least do the thing BlinKit did, move it to Element |
| 14:09 | <Ms2ger> | annevk, I think AryehGregor did telemetry for Range.detach, it's probably feasible to crib from that |
| 14:09 | <annevk> | Ms2ger: should I file a bug for you? |
| 14:10 | <annevk> | I wonder when we're gonna try Attr exodus |
| 14:10 | <Ms2ger> | Sure, I'll add it to the bottom of my todo list :) |
| 14:10 | <Ms2ger> | Line 350 or so |
| 14:10 | <annevk> | right |
| 14:23 | <Ms2ger> | gsnedders, what was the motivation for https://github.com/gsnedders/py-regexp-builder btw? |
| 14:28 | <gsnedders> | Ms2ger: Originally? No idea. Now? Partly the fact it had lain around for too long, and partly to build regexp of all "invisible" characters. |
| 14:28 | <Ms2ger> | I see |
| 14:43 | <gsnedders> | Ms2ger: Too slow to run on each load with CPython (~0.7s to build it, mostly spent iterating over the whole codespace and checking category), but takes ~0.1s with PyPy |
| 14:48 | <gsnedders> | (Down to ~0.5s with CPython, no difference with PyPy) |
| 14:54 | marcosc | thinks someone needs to W3C meme this: https://github.com/darobin/respec/pull/197#issuecomment-16381951 |
| 14:55 | <Ms2ger> | People are idiots |
| 14:55 | <Ms2ger> | News at 11 |
| 14:57 | <annevk> | Film at 11, idiot |
| 14:57 | <annevk> | Badum-tish! |
| 15:00 | <annevk> | marcosc: it's like it's 2004 again with stuff like that |
| 15:01 | <Ms2ger> | annevk, :D |
| 15:01 | <annevk> | marcosc: so yeah man, last decade didn't happen, stable pointers are much more important than whatever you learned meanwhile |
| 15:02 | <jgraham> | 2004, or 2014 at W3C |
| 15:03 | <marcosc> | :) |
| 15:03 | <annevk> | It's like visiting a third world country, technology is about a decade behind. DVDs are still hip and you don't have to look hard to find VHS. |
| 15:05 | <marcosc> | I was in Greece the other day, and the airport X-Ray machine assured me that it was safe for diskettes. |
| 15:06 | <marcosc> | It has very helpful picture... oh, and film too... but only some types. |
| 15:07 | <annevk> | I almost jokingly added France to that sentence. Went to a club there once on vacation, the "pop" music was from about seven years ago. |
| 15:08 | <annevk> | To be fair, that was not in Paris, but somewhere middle-of-nowhere. |
| 15:08 | <darobin> | you completely missed the point annevk |
| 15:08 | <darobin> | the *whole* point of provincial clubs in France is to have dated music |
| 15:08 | <darobin> | it's as hip as it gets |
| 15:09 | <darobin> | the whole "latest and greatest DJ" parisian routine is so tedious |
| 15:09 | <annevk> | darobin: aw man, I guess that's why my French teacher kept making fun of me |
| 15:09 | <darobin> | I seriously would only consider going to a club in France if it's outside Pari |
| 15:09 | <darobin> | *Paris |
| 15:09 | <darobin> | it's all wedding music |
| 15:10 | <darobin> | meaning you can booze your head off and dance like a moron |
| 15:10 | <marcosc> | you mean, they wouldn't laugh at my dancing there? |
| 15:10 | <marcosc> | you mean, I could be free like a dancing butterfly? |
| 15:11 | <annevk> | darobin: I've found you don't require a club for that |
| 15:11 | <darobin> | marcosc: exactly |
| 15:12 | <darobin> | annevk: well, I don't require a club for that, but in a parisian club I'd promptly get kicked out :) |
| 15:12 | <annevk> | hehe |
| 15:14 | <jgraham> | Parisian clubs are for eating cheese? |
| 15:16 | <darobin> | they're for cheese eating surrender monkeys for sure |
| 16:19 | <zcorpan> | is there an up-to-date table inspector that implements the spec's td-th mapping? |
| 16:20 | <zcorpan> | james.html5.org is no more |
| 16:21 | <zcorpan> | jgraham: do you have http://james.html5.org/tables/table_inspector.html around somewhere? |
| 16:41 | <jgraham> | zcorpan: So I don't know what happened to that code. Maybe it is on some other computer. I will have a look |
| 16:41 | <zcorpan> | jgraham: if you find it, please dump it on github or something :-) |
| 16:42 | <Hixie> | ms2ger: if i happen to notice it and happen to not have any edits open and happen to be in the mood... which is to say, don't count on it :-) |
| 16:43 | <jgraham> | zcorpan: Sure |
| 16:43 | <zcorpan> | why does Audio API need the legacy constants? |
| 16:43 | <annevk> | oh wtf |
| 16:43 | <annevk> | public-svg-wg has a limited mailing list? |
| 16:43 | <annevk> | that's super annoying |
| 16:44 | <annevk> | (limited as in subscribers only) |
| 16:44 | <zcorpan> | or why does Audio API want to use both legacy constants and strings instead of picking one or the other? |
| 16:44 | <shepazu> | annevk, it's only for logistics, the technical talk happens on www-svg |
| 16:45 | <annevk> | oh, forgot about www-svg :/ |
| 16:46 | annevk | forwards |
| 16:47 | <annevk> | ta shepazu |
| 16:56 | <annevk> | I do agree with jgraham. The longer that thread goes on, the more it reads like TC39 should just fold into W3C... |
| 17:10 | <MikeSmith> | win 11 |
| 17:11 | <MikeSmith> | annevk: so we seriously should help do that |
| 17:12 | <annevk> | zcorpan: they want to move to new API-style, but don't break compat? |
| 17:12 | <zcorpan> | annevk: who? |
| 17:12 | <annevk> | zcorpan: Audio |
| 17:14 | <zcorpan> | annevk: ah. yeah, i guess. everywhere else we haven't done that, though, we just didn't change the legacy APIs and changed over completely the APIs that were not widely used yet |
| 17:14 | <annevk> | I expect we'll get new APIs going forward for various unchanged legacy stuff |
| 17:14 | <zcorpan> | annevk: i'm not convinced that supporting both will end up being a win since it means both will be used in the wild and authors will be more confused |
| 17:14 | <annevk> | e.g. new APIs for network requests that don't suck as much |
| 17:15 | <annevk> | zcorpan: given that not everyone has implemented the Audio API I'm kinda surprised about the compat |
| 17:15 | <annevk> | zcorpan: I guess iOS shipped with it... |
| 17:15 | <zcorpan> | yeah i would have thought it isn't widely used yet |
| 17:18 | <GPHemsley> | TIL <blink> is not in any spec |
| 17:20 | <Hixie> | it's in html |
| 17:20 | <Hixie> | http://whatwg.org/html#blink |
| 17:20 | <annevk> | Hixie: we killed it from Gecko btw |
| 17:20 | <annevk> | s/from/in/ |
| 17:21 | <Hixie> | lame |
| 17:21 | <annevk> | *shrug* ;) |
| 17:21 | <GPHemsley> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=857820#c57 |
| 17:22 | <Hixie> | the parser did something with blink? |
| 17:22 | <Hixie> | o_O |
| 17:23 | <annevk> | looks like the old Gecko parser |
| 17:23 | <Hixie> | the only requirement in the html spec is that the ua.css file have blink { text-decoration: blink } |
| 17:23 | <GPHemsley> | Hixie: I was referring to this: "And also, <blink> element isn't defined any Web Standard specs." |
| 17:24 | <Hixie> | GPHemsley: what about it? |
| 17:25 | <Hixie> | people not knowing what's in all the specs is hardly surprising, there's tons of them and they're long. :-) |
| 17:25 | <GPHemsley> | Oh, are we splitting hairs about "in" vs. "defined in"? |
| 17:25 | Hixie | barely knows what's in the HTML spec, let alone anything else :-) |
| 17:26 | annevk | comments |
| 17:28 | <zcorpan> | there are surprisingly few uses of `const` in html |
| 17:29 | <zcorpan> | maybe the parser thing is about HTMLElement vs HTMLUnknownElement? |
| 17:31 | GPHemsley | had no idea <marquee> had so many possibilities. |
| 17:35 | <zcorpan> | i wish browsers would do a better job at animating the <marquee> instead of doing 10 pixel jumps like it's 1994 |
| 17:36 | <Hixie> | ah yeah maybe <blink> is now HTMLUnknownElement |
| 17:36 | <Hixie> | spec does say it should be HTMLElement |
| 17:36 | <Hixie> | but i can add it to the list of Unknowns if nobody does that |
| 17:38 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2214 - opera/gecko HTMLElement, safari/chrome HTMLUnknownElement |
| 17:40 | <Hixie> | in other news, how should we handle changing the start/end times on a cue |
| 17:40 | <Hixie> | essentially remove the cue and re-add it? |
| 17:40 | <Hixie> | even if that moves it around? |
| 17:40 | <Hixie> | or should we try hard not to move it |
| 17:40 | <Hixie> | also we still don't show cues when they are added if they should be active, iirc |
| 17:41 | <zcorpan> | in IE10 it's "HTMLPhraseElement" |
| 17:41 | <Hixie> | wtf is HTMLPhraseElement |
| 17:42 | <zcorpan> | i asked about this a few years ago. apparently they had these interfaces internally all along, but didn't expose them until IE8 or some such, when catching up with the specs |
| 17:42 | <zcorpan> | and they didn't prioritize matching the spec exactly, or something |
| 17:42 | <Hixie> | ...ok |
| 17:43 | <GPHemsley> | "Implements the document object model (DOM) representation of the phrase elements such as em, strong, dfn, code, samp, kbd, var, cite, abbr, and acronym." http://msdn.microsoft.com/en-us/library/ie/hh869728%28v=vs.85%29.aspx |
| 17:44 | <Hixie> | hmm... we do support _removing_ cues dynamically |
| 17:45 | <zcorpan> | Hixie: i think moving cues around when changing the times isn't a problem |
| 17:45 | <Hixie> | well if all you're doing is extending the end time |
| 17:45 | <Hixie> | it'd be sad if it moved |
| 17:46 | <Hixie> | i think in practice we don't need to move |
| 17:46 | <Hixie> | i just need to check if the active flag should be set, and repaint the cues if it changed |
| 17:46 | <Hixie> | the question is more about events |
| 17:46 | <Hixie> | i'm thinking we don't fire events if you manually change the time and active changes |
| 17:46 | <zcorpan> | oh moving it can change the rendering huh... didn't consider that. i was just thinking of "move" as in placement in the list of cues |
| 17:47 | <Hixie> | right |
| 17:47 | <Hixie> | e.g. if the cue was placed in a suboptimal place, then all the other cues went away |
| 17:48 | <zcorpan> | then i think i agree |
| 17:49 | <Hixie> | or... _or_... we could run the "When the current playback position of a media element changes" steps |
| 17:49 | <Hixie> | and that would fire all the events magically! and update the active flag and everything! |
| 17:49 | <Hixie> | oh this is so the right solution |
| 17:50 | <Hixie> | yes yes yes, this is the way to do it. |
| 17:51 | <Hixie> | ok i need a name for this algorithm |
| 17:51 | <Hixie> | "the 'time moves on' steps"? |
| 17:52 | <Hixie> | ok unless someone has a better idea, i'm calling these the /time marches on/ steps. |
| 18:05 | <Hixie> | hm, can you have a texttrack without a media element... |
| 18:06 | <Hixie> | i guess so, orphan <track> for one |
| 18:06 | <Hixie> | hmm |
| 18:17 | <Hixie> | are there any APIs (e.g. XHR maybe?) that do the blob: delayed preservation magic needed for https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 ? |
| 18:19 | <annevk> | Hixie: there's no blob URL special casing anywhere currently |
| 18:20 | <annevk> | Hixie: we want to lift the same-origin restrictions on blob URLs (make them work similar to data URLs, which when pasted in somewhere, work) |
| 18:20 | <Hixie> | the origin thing seems orthogonal |
| 18:21 | Hixie | doesn't really want to be the first one to do this special casing for blob: |
| 18:21 | <annevk> | Hixie: except that we track the revoking thing on a per-global basis |
| 18:21 | <Hixie> | and i find it hard to believe that all the specs are going to be updated for this |
| 18:21 | <Hixie> | like, is CSSOM going to say that when you set 'border-image-source', you have to do something special? |
| 18:21 | <annevk> | Hixie: implementers have to decide what to do here I think |
| 18:22 | <annevk> | Hixie: zewt suggested adding this to the URL parser, but I'm not sure if that actually solves the issue as that can be delayed in CSS too |
| 18:23 | <Hixie> | jesus wept, what happened on https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842 |
| 18:24 | <Hixie> | 53 book-length comments |
| 18:24 | <Hixie> | well the actual semantics here are imho very weird, urls are supposed to be idempotent and this breaks that invariant |
| 18:24 | <annevk> | Hixie: basically, I think the whole autoRevoke thing is kind of a joke |
| 18:25 | <Hixie> | not a joke, but yeah, i'm rather skeptical of it |
| 18:25 | <Hixie> | but i don't have a better proposal |
| 18:25 | <annevk> | has it been implemented? |
| 18:25 | <Hixie> | no idea |
| 18:26 | <annevk> | basically currently it seems it cannot work as starting a fetch will do that fetch async |
| 18:26 | <annevk> | except for sync XHR |
| 18:26 | <annevk> | so if UAs implemented it, they'd break sites |
| 18:27 | <annevk> | because autoRevoke was not the default before |
| 18:28 | <Hixie> | hm? |
| 18:29 | <Hixie> | in other news, i think it's possible some people think that the more they talk about a feature, the more likely it is that it'll get added to the spec |
| 18:29 | <Hixie> | but since i deal with bugs on a least-recently-touched basis, it actually has the opposite effect... |
| 18:32 | <annevk> | Hixie: createObjectURL() in the spec defaults to autoRevoke true; that's not implemented atm afaik |
| 18:33 | <annevk> | Hixie: also, <img>.src = blobURL will always load async, at which point blobURL is already revoked |
| 18:44 | <marcosc> | Hixie, re: Bug 17842 ... it's not the case that people are just bla bla-ing to make it seem important. It's actually quite controversial what is being asked in the bug... because of how radios on mobiles work. |
| 18:45 | <annevk> | Hixie: I'm emailing webapps |
| 18:45 | <marcosc> | Hixie: in summary, we want a "lazy" attribute :) Lazy === hey browser, load it when you want. |
| 18:46 | <zcorpan> | marcosc: Hixie's just saying that if you want him to look at the bug, you need to stop adding more comments |
| 18:46 | <marcosc> | zcorpan: I know, totally get that. |
| 18:47 | <marcosc> | zcorpan: what I was trying to say was that the original bug had made some incorrect assumptions, so lots of people had opinions about it. |
| 18:47 | <marcosc> | I was actually going to jump in the other day to tell them to stop proposing solutions and just wait for Hixie |
| 18:48 | <marcosc> | But some good new material was actually brought forward |
| 18:48 | <marcosc> | so it was better to just leave the conversation going |
| 18:48 | <zcorpan> | also, in my experience saying "stop talking" doesn't work but just adds more noise :-P |
| 18:49 | <marcosc> | heh, rock and a hard place |
| 18:49 | <marcosc> | I think we reached consensus in the bug, so either Ilya or Yoav should be able to provide Hixie with a summary |
| 18:50 | <zcorpan> | if you know of someone wanting to implement it right now, you can ask Hixie to fast track the bug |
| 18:53 | <marcosc> | zcorpan: yeah, I don't know of any actual interest from browser folks. |
| 18:53 | <zcorpan> | ok |
| 18:54 | <marcosc> | I mean, there a few people form Google, at least one from Opera, ... but I guess until there is actual bugs filed in the right places... |
| 18:55 | <Hixie> | annevk: the idea zewt was putting forward was that <img>.src = blobURL should cause the load to be sync so that the data was preserved for that <img>, iiuc |
| 18:55 | <Hixie> | marcosc: oh i wasn't suggesting it was just bla bla, sorry if that was the implication! |
| 18:56 | <annevk> | Hixie: hmm maybe we could make http://fetch.spec.whatwg.org/#concept-fetch work that way |
| 18:56 | <annevk> | Hixie: even so, that doesn't solve it for CSS I think |
| 18:57 | <Hixie> | annevk: yeah, i dunno. arun and zewt are the right people to figure out the solution, i'm just hoping another spec fixes it first because i don't want to be the trailblazer here when i'm skeptical anyone else will follow. |
| 18:57 | <annevk> | Hixie: I don't think you should fix it |
| 18:57 | <annevk> | Hixie: it should either happen in fetch or URL |
| 18:58 | <annevk> | Hixie: and everyone will have to invoke fetch synchronously I suppose, but that's okay |
| 18:58 | <Hixie> | well that would be even better, sure. right now that doesn't fit the proposa. |
| 18:58 | <Hixie> | proposal. |
| 18:59 | <Hixie> | in other news: does anyone recall/know if the difference in <a>'s activation behaviour and <area>'s activation behaviour, with respect to how to handle target="" in sandbox=""ed iframes, is intentional or not? :-) |
| 19:01 | <Hixie> | looks like i just forgot <area> when fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=13894 |
| 19:02 | <annevk> | Hixie: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0242.html (re blob URLs) |
| 19:04 | <Hixie> | well we can't always invoke fetch |
| 19:04 | <zcorpan> | hsivonen: MikeSmith: is there a story for automated tests for v.nu yet? |
| 19:04 | <Hixie> | e.g. <img> might want to delay forever if we add this new defer="" |
| 19:04 | <Hixie> | and <embed> has to fetch async for compat reasons |
| 19:04 | <Hixie> | (base url has to be resolved after setting) |
| 19:04 | <Hixie> | (after settings source url, that is) |
| 19:04 | <Hixie> | typos galore! |
| 19:05 | <annevk> | re-resolved? |
| 19:05 | <annevk> | Hixie: you can invoke fetch sync and then still wait |
| 19:06 | <Hixie> | how does that work? |
| 19:06 | <annevk> | Hixie: the only thing invoking fetch would do is take a reference to the object and then return early |
| 19:06 | <MikeSmith> | zcorpan: from W3C we have a GSOC proposal for a student to do some work related to that, and we have a great candidate who's submitted an GSOC application for it already |
| 19:06 | <Hixie> | yes my point is we don't even want to resolve the url in some cases |
| 19:06 | <Hixie> | e.g. <embed> |
| 19:06 | <annevk> | Hixie: or <a href> I suppose |
| 19:06 | <Hixie> | and in some cases we don't know what url to resolve, e.g. <img srcset> |
| 19:06 | <MikeSmith> | zcorpan: http://www.w3.org/2013/03/gsoc2013#guidelines |
| 19:07 | <Hixie> | especially <img srcset defer> |
| 19:07 | <Hixie> | or whatever we call it |
| 19:07 | <MikeSmith> | zcorpan: http://www.w3.org/2013/03/gsoc2013#validator-nu-testing |
| 19:07 | <annevk> | mkay |
| 19:08 | <Hixie> | like, what should we do if someone sets an img srcset to "blob:a 1x blob:b 2x blob:c 3x" ? |
| 19:08 | <Hixie> | er, with commas |
| 19:08 | <Hixie> | you get the idea |
| 19:08 | <annevk> | you figure out which to fetch and do it? |
| 19:09 | <Hixie> | and you don't revoke the other two? |
| 19:09 | <Hixie> | what if the user zooms in and out, or moves the window across to a low res screen then a high res screen? |
| 19:09 | <Hixie> | do you still have the images around? when do you forget them? |
| 19:11 | <annevk> | when you run the autorevoke stuff |
| 19:12 | <annevk> | not sure there's much winning to be had here |
| 19:18 | <Hixie> | MikeSmith: re https://www.w3.org/Bugs/Public/show_bug.cgi?id=21553#c9, by '"the main content" of each <article> (currently marked up as <li> with class="postitem".)', i meant the parenthetical to apply to "<article>", not to "the main content of each <article>". |
| 19:18 | <Hixie> | sorry for the ambiguity |
| 19:24 | <MikeSmith> | Hixie: ah, OK |
| 19:32 | <zcorpan> | MikeSmith: nice. keep me updated on that :-) |
| 19:34 | <zcorpan> | MikeSmith: it would be nice if tests could be written to be validator-agnostic and live on web-platform-tests or so |
| 19:39 | <zcorpan> | though maybe people following web-platform-tests don't want validator tests there |
| 19:39 | <jgraham> | Well |
| 19:39 | <jgraham> | I don't plan to review them at least |
| 19:39 | <jgraham> | But with critic filters I don't have to! |
| 21:06 | <annevk> | '[The "or" operator is not yet supported by ReSpec.]' |
| 21:06 | <annevk> | I don't even |
| 21:06 | <jsbell> | annevk: context? |
| 21:06 | <annevk> | http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0029.html |
| 21:07 | <Hixie> | o_O |
| 21:08 | <annevk> | ReSpec makes specs both way harder to read and then it does not even let you write a spec in the right way |
| 21:08 | <jsbell> | Seems to "work" for me, although in (foo or bar) foo and bar don't end up linked correctly. That said, linking to webidl default types seems broken in respec anyway at the moment (reported to robin) |
| 21:52 | <Hixie> | TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=18026 comment 8 paragraph 2 |
| 22:01 | <rillian> | did the websec-mime-sniff draft become http://mimesniff.spec.whatwg.org or is one a fork of the other? |
| 22:06 | <Hixie> | rillian: yeah, iirc ietf basically didn't like it existing |
| 22:06 | <Hixie> | abarth would know more |
| 22:07 | <TabAtkins> | Hixie: No, getting a selector to match elements whose contents are numeric is not realistic in the short term. It's basically equivalent in difficulty to getting one which matches a regex against text contents, which has been shot down for performance reasons for a long time. |
| 22:08 | <Hixie> | TabAtkins: can you comment to that effect on the bug? would be much appreciated. (also if you have any other ideas for addressing that use case, cos i'm all out of ideas on that front) |
| 22:08 | <rillian> | abarth: IIRC we were trying to limit things to the first 500 bytes and/or only mask/compare |
| 22:08 | <TabAtkins> | Yes, I can comment. I think the right thing to do is simply having the column selectors/combinator that Selectors 4 has, which is sufficient. |
| 22:08 | <rillian> | which is why the mp3 and webm sniffing doesn't really work. Does that match your recollection? |
| 22:09 | <rillian> | Hixie: thanks |
| 22:09 | <Hixie> | TabAtkins: cool, thanks |
| 22:10 | <TabAtkins> | Hixie: Though... Hm, testing an attribute value for numeric-ness would probably work. |
| 22:10 | <TabAtkins> | It's roughly equivalent in difficulty to the existing attr operations. |
| 22:10 | <TabAtkins> | (Fundamental problem with testing text content is what to do with non-child text nodes.) |
| 22:13 | <Hixie> | i once proposed [attr>4] and related selectors |
| 22:13 | <Hixie> | fwiw |
| 22:13 | <TabAtkins> | Yeah, I wanna put those into either Selectors 4 or 5. |
| 22:13 | <TabAtkins> | We're trying to shut down 4, so it'll probably make 5. |
| 22:18 | <TabAtkins> | I wonder what kind of syntax would make sense to test if an attr was numeric. |
| 22:18 | <TabAtkins> | I mean, you could definitely do :matches([foo>0], [foo<=0]), but that's a bit verbose. |
| 22:20 | <Hixie> | TabAtkins: yeah |
| 22:21 | <Hixie> | TabAtkins: also, you should clearly switch to an unversioned development model so you could add things whenever :-) |
| 22:22 | <TabAtkins> | Hixie: As soon as we get CR of a spec, we push the unversioned url to a new version, so we can work on whatever we were waiting on. |
| 22:22 | <TabAtkins> | The only time versioning gets in our way now is the period between "ok, time to stabilize and finish what we've got" and "CR published!". |
| 22:23 | <TabAtkins> | Hmm, since we already have a type flag for case-insensitive matches, maybe we can just use that. [foo n] matches if the foo attribute's value is numeric. |
| 22:24 | <TabAtkins> | Or just make a new comparison. [foo <=> 0] tests for numericness. ^_^ |
| 22:25 | <Hixie> | there's an unversioned url? |
| 22:26 | <TabAtkins> | Now there is! Just drop the number (or dash-number) from any dev.w3.org css url, and you'll get the latest draft. |
| 22:26 | <Hixie> | ooo |
| 22:26 | <TabAtkins> | dev.w3.org/csswg/css-flexbox-1 and css-flexbox both point to the same spec, for example. |
| 22:26 | <TabAtkins> | We're planning to apply the same policy to our /TR drafts. |
| 22:27 | <TabAtkins> | All the old css3-foo links still work, because we added redirects, but the preferred url form now is "css-foo", or "css-foo-N" if you want a specific version. |
| 23:08 | <Hixie> | abarth: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=19662#c7 |
| 23:09 | <abarth> | Hixie: hi |
| 23:09 | <abarth> | Hixie: looking |
| 23:12 | <abarth> | Hixie: too complicated for me to think about right now, sorry. I've added it to my asana for this week |
| 23:14 | <Hixie> | thanks! |
| 23:16 | <Hixie> | abarth: while i have you here, are you still working on web origin? |
| 23:16 | <Hixie> | abarth: in particular, it seems a bit ambiguous what "host" means when the origin has an ipv6 address in it |
| 23:16 | <Hixie> | abarth: whether it has the []s or not |
| 23:16 | <abarth> | yeah, we never resolved that issue |
| 23:17 | <abarth> | do you know which way it ought to be? |
| 23:19 | <Hixie> | i think square brackets included? |
| 23:19 | <Hixie> | but i'm not really sure |
| 23:19 | <Hixie> | it would match url.spec.whateg.org |
| 23:19 | <Hixie> | whatwg even |
| 23:20 | <Hixie> | abarth: but really my question isn't so much about the serialisation, but about whether "the host part of the tuple" contains the square brackets or not |
| 23:20 | <Hixie> | abarth: and that i've really no idea if it should or not |
| 23:21 | <abarth> | this gets into how much browsers canonicalize IP addresses |
| 23:21 | <abarth> | As I recall, IE and Chrome do a lot of canonicalization |
| 23:21 | <abarth> | whereas Firefox and Safari do very little canonicalization |
| 23:22 | <abarth> | I don't remember the details about this particular bit of canonicalization |
| 23:22 | <Hixie> | url.spec.whatwg.org requires a specific form |
| 23:22 | <abarth> | for my money, i'd err on the side of more canonicalization |
| 23:22 | <abarth> | so, if you supply and IPv4 address in octal, it will end up as a dotted quad? |
| 23:23 | <Hixie> | no idea if he supports octal |
| 23:24 | <Hixie> | oh, ipv4 parsing isn't yet defined |
| 23:24 | <Hixie> | indeed host parsing isn't defined other than ipv6 |
| 23:24 | <abarth> | i see |
| 23:25 | <abarth> | if folks like the general approach of canonicalizing IP addresses, then we should canonicalize IPv6 address to include the [ ] |
| 23:25 | <Hixie> | k |
| 23:26 | <Hixie> | so I should assume the 'host' part of an origin tuple includes the brackets? |
| 23:26 | <abarth> | yes |
| 23:26 | <Hixie> | is there somewhere i can file a bug on web origin, or does that go on your list too? :-) |
| 23:32 | <abarth> | Hixie: you can file an issue in this github project: https://github.com/abarth/websec |
| 23:33 | <Hixie> | k |
| 23:35 | <gsnedders> | hober: I presume you don't mind if I base the new html5lib documentation on http://edward.oconnor.cx/2009/08/djangosd-html5lib? :) |
| 23:46 | <gsnedders> | jgraham: We (html5lib) got mentioned in PEP-411! |
| 23:50 | <hober> | gsnedders: fine by me! i think most or all of my site is cc by sa, iirc |
| 23:50 | <TabAtkins> | Ah, you crazy viral copylefters. |
| 23:50 | <gsnedders> | hober: Yeah, it says so. But would be nice to have docs same license as everything else, and given I'm basically just ripping off your structure :P |
| 23:51 | <hober> | :) |
| 23:51 | <hober> | i forgot all about that talk |
| 23:51 | gsnedders | was just Googling for html5lib :) |