| 00:00 | <TabAtkins> | gimme a sec |
| 00:02 | <Hixie_> | TabAtkins: (i actually just need to know if the bottom line comes out of the bottom of the arc, or the left of the arc, or if something crazy is going on) |
| 00:03 | <TabAtkins> | Oh, ok. Left of the arc. |
| 00:03 | <Hixie_> | awesome, thanks man |
| 00:03 | <TabAtkins> | Like the horizontal arc bends downward at the point it enters the arc. |
| 00:03 | <TabAtkins> | horizontal line |
| 00:03 | <Hixie_> | right |
| 00:03 | <TabAtkins> | No, left. |
| 00:04 | <Hixie_> | it left? |
| 00:04 | <Hixie_> | out of the right? |
| 00:04 | <Hixie_> | or went right out of the left |
| 00:04 | <TabAtkins> | Wait, what? Now I'm confused; I was just being dumb. |
| 00:04 | <Hixie_> | woot, i win! |
| 00:04 | <Hixie_> | (your first answer was fine) |
| 00:04 | <TabAtkins> | The horizontal line hits the arc at its leftmost point. It angles downward, to the SE, and continues that way through and beyond the arc. |
| 00:05 | <Hixie_> | yup |
| 00:05 | <Hixie_> | same as everyone except chrome :-/ |
| 00:08 | <TabAtkins> | yaaaay |
| 00:09 | <Hixie_> | (spec required both mutually exclusive behaviours until a few minutes ago, so it's a wonder we are only one browser away from interop) |
| 01:27 | <zewt> | sure glad that I don't really care about these image threads |
| 01:35 | <TabAtkins> | zewt: That's a good survival strategy. |
| 01:35 | <TabAtkins> | I made the mistake of becoming personally invested. |
| 01:35 | <TabAtkins> | I successfully avoided it for *months*, until John Mellor roped me in over wine. |
| 01:35 | <TabAtkins> | Goddam alcohol, always making me commit to caring about things. |
| 01:36 | <zewt> | i've avoided even opening any of the threads, because I don't want to care (or rather, I want to not care) |
| 01:36 | <zewt> | (re: got enough things on the list already) |
| 01:36 | <TabAtkins> | Okay, now that I've finished both looking at emails and doing expense reports, it's time to go back to Python coding for an hour. |
| 01:36 | <zewt> | just... aimlessly? |
| 01:37 | <TabAtkins> | ^_^ Nah, coding on Bikeshed. |
| 01:37 | <TabAtkins> | My primary software project for the last 6 months. |
| 01:38 | <zewt> | how long did it take to come up with the name |
| 01:39 | <TabAtkins> | A surprisingly long time. It was just called "Tab's new preprocessor" for months. |
| 01:39 | <TabAtkins> | Until someone in this room started suggesting things. |
| 01:39 | <zewt> | fitting, then |
| 01:39 | <TabAtkins> | Exactly! The actual name came from Twitter. |
| 06:38 | <SimonSapin> | yeah, having "new" in the name is nice until the new thing becomes the old thing |
| 06:38 | <SimonSapin> | (I recently killed the "newcss" module in Servo) |
| 06:58 | <annevk-cloud> | Same problem with numbers, eg html5lib |
| 08:54 | <MikeSmith> | hsivonen: View Source in Firefox doesn't mark the � character in http://w3c-test.org/web-platform-tests/master/conformance-checkers/html/parser/008-novalid.html as error |
| 08:54 | <MikeSmith> | oh wait |
| 08:54 | <MikeSmith> | no, it does |
| 08:57 | <MikeSmith> | but for the  in http://w3c-test.org/web-platform-tests/master/conformance-checkers/html/parser/004-novalid.html it shows it in red but doesn't show any tooltip text when you mouse over |
| 08:58 | <MikeSmith> | hmm I guess it always shows character references in red but errors in red+bold |
| 09:00 | MikeSmith | files bugs |
| 10:07 | <annevk> | Okay, so bz put getElementById() directly on DocumentFragment |
| 10:07 | <annevk> | Shouldn't we do the same as with NonDocumentTypeParentNode? |
| 10:08 | <annevk> | Uhm, *ChildNode |
| 10:11 | <hsivonen> | hmm. looks like occupying an IP4 address costs the same as 12 GB of storage (per unit of time) |
| 10:35 | <jgraham> | So I heard a rumor at TPAC that the <picture><source> thing with lower implementation complexity was bad for animated images, for some reason. Anyone know anything about that? Otherwise it seems that we should clearly be doing that syntax |
| 10:36 | <darobin> | jgraham: I haven't heard about that, but maybe asking on #respimg? |
| 10:36 | <jgraham> | Uh, yeah, I'm not sure I want to join that channel :) |
| 10:38 | <Ms2ger> | But picture is baaaad |
| 10:38 | <jgraham> | Did Ms2ger turn into a sheep? |
| 10:39 | <jgraham> | Or maybe he always was one |
| 10:39 | <Ms2ger> | Waaaake up, sheeeple |
| 10:40 | <MikeSmith> | hah |
| 10:41 | <MikeSmith> | jgraham: why clearly? |
| 10:41 | <MikeSmith> | you didn't mean clearly we should be doing <picture><source>? |
| 10:42 | <jgraham> | Because despite the verbosity it is using the overall syntax of the language in the way it was designed, and it is clearly the solution that authors find most intuitive |
| 10:43 | <darobin> | jgraham: the people on #resimg are really nice actually |
| 10:43 | <jgraham> | darobin: But what about the ones on #respimg? :p |
| 10:44 | <darobin> | har har har |
| 10:50 | <MikeSmith> | jgraham: I thought another big downside of <picture><source> was that it would require browser projects to basically duplicate most of their existing <img> tests |
| 10:50 | <MikeSmith> | and w-p-t too |
| 10:51 | <jgraham> | Why is that more true than for the other syntaxes? |
| 10:52 | <jgraham> | In any case, although interop is obviously a concern, that feels like a clear violation of the priority of constituencies |
| 10:52 | <jgraham> | (assuming that the syntax is guenuinely better for authors) |
| 10:53 | <MikeSmith> | hsivonen: I raised https://bugzilla.mozilla.org/show_bug.cgi?id=940282 bug for View Source not flagging some invalid characters |
| 10:54 | <MikeSmith> | jgraham: I guess I've never heard any b |
| 10:55 | <MikeSmith> | *heard anybody yet claim that <picture><source> is worse syntax for authors |
| 10:56 | <MikeSmith> | hmm but see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-November/041536.html from TabAtkins |
| 10:56 | <MikeSmith> | "The cost there is that <picture><source> is now treated substantially differently than <video><source>, despite sharing a name." |
| 10:56 | <MikeSmith> | by which I think he means the cost to authors |
| 10:56 | <MikeSmith> | maybe |
| 10:57 | <jgraham> | It is possible that no one is relying on the precise semantics of <video><source>. Or that no one will even notice the difference apart from implementors |
| 10:58 | <MikeSmith> | true |
| 10:58 | <MikeSmith> | jgraham: as far as how the test-case duplication is more true for <picture> than for the other syntaxes, I thought it was a matter of testing cost of a new element vs new attribute |
| 10:59 | <MikeSmith> | and that just adding a new attribute to img does not require duplicating all existing img tests |
| 11:08 | <hsivonen> | MikeSmith: thanks |
| 11:09 | <hsivonen> | annevk: since I'm redoing the charset menu UI strings anyway, I wonder if I should use the sort of labels IE uses |
| 11:09 | <hsivonen> | annevk: ie. Foo (ISO) and Foo (Windows) instead of Foo (ISO-8859-x) and Foo (Windows-xxxx) |
| 11:09 | MikeSmith | didn't know ArrayBuffer was now part of EcmaScript |
| 11:09 | <annevk> | hsivonen: it seems exposing less magic strings to the end user is a plus |
| 11:10 | <hsivonen> | annevk: ok. I'll try it and see if it passes review |
| 11:11 | <annevk> | hsivonen: how do I get to the menu in IE? |
| 11:12 | <annevk> | hsivonen: also, omitting it entirely, e.g. just "Thai" seems better too |
| 11:12 | <annevk> | hsivonen: when feasible |
| 11:13 | <annevk> | ah, right click |
| 11:13 | <annevk> | hsivonen: yeah what IE does makes a lot of sense |
| 11:14 | <jgraham> | MikeSmith: I guess there could be *some* difference in the number of tests between <picture><source><img></picture> and <img src new-attr>, but it isn't obviously large. You have basically the same space of possible things to test (in the absence of scripted DOM manipulation) |
| 11:14 | <annevk> | not sure why Korean lacks a label and Thai says Windows in IE, I don't think either needs one |
| 11:14 | <MikeSmith> | jgraham: OK |
| 11:14 | <jgraham> | zcorpan might tell me I am wrong though |
| 11:15 | <yoav> | jgraham: I've heard the testing cost from hober & zcorpan. |
| 11:15 | <Ms2ger> | Dammit :) |
| 11:15 | <yoav> | Basically, you'd need to re-test img's functionality with picture, on top of the new picture-specific functionality |
| 11:15 | <jgraham> | I think the testing cost is uncontroversially higher in the case where DOM manipulation can change things |
| 11:16 | <annevk> | pre-scanner is also somewhat more complicated |
| 11:16 | <jgraham> | yoav: It seems to me that you would also need to retest img's functionality with no src attribute |
| 11:16 | <MikeSmith> | yoav: yeah, I guess I also heard it from zcorpan |
| 11:16 | <Ms2ger> | So are we getting xhtml2 img finally? :) |
| 11:16 | <yoav> | annevk: preload scanner complexity is not extremely different between picture/src-N |
| 11:16 | <MikeSmith> | heh |
| 11:17 | <annevk> | yoav: I did not say extreme |
| 11:17 | <jgraham> | So I suppose the argument is that you would need to test e.g. canvas.drawImage with a HTMLPictureElement |
| 11:17 | <yoav> | Need to maintain some state of where you're at |
| 11:17 | <yoav> | annevk: OK :) |
| 11:17 | <jgraham> | Or a HTMLSourceElement |
| 11:17 | <jgraham> | Or whatever you would actually use |
| 11:17 | <MikeSmith> | Ms2ger: I guess xhtml2 was just ahead of its time. The world wasn't ready. |
| 11:17 | <yoav> | jgraham: Yeah, and everything else image currently does. |
| 11:18 | <MikeSmith> | Ms2ger: so maybe there's also hope yet for XHTML Modularization |
| 11:18 | <yoav> | zcorpan: If you're around, clarifications would be helpful. |
| 11:18 | <Ms2ger> | MikeSmith, hey man, I really should avoid bursting into laughter in the middle of my class :) |
| 11:18 | <jgraham> | It seems likely that implementations would reuse as much of the same code as possible though, so it isn't super-clear that those tests would actually find anything once you had verified that the element worked at ll |
| 11:19 | <jgraham> | *all |
| 11:19 | <Ms2ger> | Speak of the devil |
| 11:19 | <jgraham> | Ms2ger: I think MikeSmith just did |
| 11:19 | <jgraham> | Well actually that's unfair |
| 11:19 | <jgraham> | He hasn't mentioned namespaes yet |
| 11:19 | <Ms2ger> | So now you did |
| 11:19 | <MikeSmith> | Ms2ger: your instructor will just assume it's because of something really clever he said earlier and that you're just catching up with now |
| 11:20 | <Ms2ger> | MikeSmith, not sure that's betetr |
| 11:20 | <Ms2ger> | better, even |
| 11:22 | <yoav> | zcorpan: We were discussing <picture> test costs here. I'd be happy if you could clarify your current standpoint on the subject (post Kornel's atomic mutation algo) |
| 11:41 | <annevk> | hallvors: you should read my comment again I think |
| 11:41 | <annevk> | hallvors: I'm not proposing anything really in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322#c11 other than writing down what I believe is implemented today |
| 11:41 | <hallvors> | annevk: I may well be misunderstanding something.. |
| 11:42 | <annevk> | hallvors: the second example forces a preflight because of the setRequestHeader() |
| 11:42 | <hallvors> | I get that |
| 11:42 | <annevk> | hallvors: the first example does not force a preflight |
| 11:42 | <annevk> | hallvors: now, will upload events dispatch or not is the question |
| 11:42 | <hallvors> | so the way it's implemented today is no upload events will fire for the first example? |
| 11:42 | <annevk> | hallvors: if we dispatch them for late listener registration it seems we have a security bug |
| 11:43 | <hallvors> | Wouldn't you sort of agree that this sucks for the users of this API? |
| 11:43 | <annevk> | hallvors: I'd hope so (again assuming we're actually protecting something here) |
| 11:43 | hallvors | should write some tests |
| 11:43 | <Ms2ger> | ^ |
| 11:43 | <annevk> | hallvors: I never thought this flag made much sense or a lot of CORS for that matter |
| 11:43 | <annevk> | hallvors: but I wasn't calling the shots |
| 11:44 | <annevk> | Mozilla's security team proxied through sicking is how a lot happened |
| 11:45 | <hallvors> | OK - I'm sort of relieved that it must be some sort of collective misunderstanding and not you being weird. I don't want you to be weird :-p |
| 11:45 | <hallvors> | (that's probably an odd thing to say :-]) |
| 11:46 | <annevk> | hah |
| 11:47 | hallvors | should keep in mind that a spec editor is just a ghost writing proxy much of the time |
| 11:47 | <annevk> | But yeah, should probably create a test to see what implementations do. If they allow late registration, there's no reason to make early registration trigger a preflight... |
| 11:47 | <hallvors> | hm.. |
| 11:48 | <hallvors> | it's complicated because addEventListener() is presumably not supposed to throw either? |
| 11:48 | <hallvors> | I can't think of any case where aEL throws right now |
| 11:48 | <hallvors> | so we can't do that if authors try to late-register listeners that should not fire |
| 11:49 | <hallvors> | (and xhr.upload.onprogress = foo throwing would be even more ugly) |
| 11:49 | <annevk> | I'm pretty sure the idea was that events would not dispatch if there was no preflight done. And that the check for early listeners triggering a preflight was added as some kind of best effort hack. |
| 11:50 | <annevk> | However, it's been half a decade and my memory has been known to be faulty. |
| 11:50 | <hallvors> | What if the functions would fire but the length computable would be false and no details given? |
| 11:50 | <annevk> | The problem is that you "revealed" the server existed. |
| 11:50 | hallvors | sighs at the weird nooks and corners of the so-called platform |
| 11:51 | <annevk> | The details of the event are not that interesting. |
| 11:51 | <hallvors> | <img onload=""> already does that, no? |
| 11:51 | <annevk> | Yes, but less quick. |
| 11:52 | <hallvors> | That's surely just an implementation detail? |
| 11:52 | <annevk> | Not in the face of timing attacks. |
| 11:53 | <hallvors> | odinho: around? |
| 11:54 | <hallvors> | BTW annevk: I'd like to suggest a small note about what the "settings object" contains |
| 11:56 | <odinho> | hallvors: I iz around! |
| 11:56 | <hallvors> | great :) |
| 11:56 | <hallvors> | have you written any CORS tests that seem relevant to what annevk and I just discussed above? |
| 11:58 | <hallvors> | (read your blog recently BTW. If I had read it a little earlier I might have pestered your for video-related advice :-) but I've figured out some VirtualDub + ffmpeg approaches that seem to handle this project I'm working on) |
| 11:59 | <odinho> | hallvors: No, I have not :) Tests need to be always appended to, and that's one such case ;-) |
| 12:00 | <hallvors> | sure. I'll take it |
| 12:01 | <odinho> | hallvors: Create it on the python branch. |
| 12:01 | <odinho> | hallvors: The newest cors tests are there. They're reviewed and work better than their php counterparts :) |
| 12:03 | <hallvors> | hm.. there's jgraham/python, jgraham/python_review and jgraham/python_review_2. They all sort of belong to James, I'm not sure if it would be well-behaved to mess with them. /cc jgraham |
| 12:03 | <hsivonen> | annevk: how did x-mac-cyrillic end up in the Encoding Standard? |
| 12:03 | <hallvors> | jgraham: ^? |
| 12:03 | <annevk> | SimonSapin: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23793 |
| 12:04 | <hsivonen> | annevk: aside from x-user-defined, it's the only x- encoding |
| 12:05 | <annevk> | hsivonen: http://lists.w3.org/Archives/Public/www-archive/2011Dec/att-0020/encoding-labels.html supported by all browsers |
| 12:07 | <jgraham> | hallvors: Feel free to push stuff to jgraham/python_review_2 if it isn't going to be super-controversial (i.e. if it won't delay the review) |
| 12:07 | <hallvors> | OK. I doubt an extra test or two trying to figure out what current implementations do will be controversial :) |
| 12:08 | <hallvors> | (unless I make stupid coding mistakes - then I'll delay the review and learn something :-p) |
| 12:09 | <hsivonen> | annevk: ok. I think I'm going to see if excluding it from the menu passes review. Neither Chromium nor IE has it in the menu. |
| 12:36 | <MikeSmith> | holy god just now finding this www-tag thread on JSON slash encoding detection slash BOMs |
| 12:37 | <MikeSmith> | any point in trying to read any of it? |
| 12:40 | <MikeSmith> | judging from the set of personalities From field of most of the postings, it looks suspiciously like it's probably a big how-many-angels-on-the-head-of-a-pin wank-off |
| 12:43 | <hsivonen> | MikeSmith: my todo list includes posting to that thread and saying it's reprehensible for people to bikeshed complications for this stuff instead of doing things the way the Encoding Standard says |
| 12:50 | <MikeSmith> | hsivonen: I'm not sure they're actually interested in solutions |
| 12:50 | <MikeSmith> | at this point the only thing that thread is missing is Len Bullard |
| 12:51 | <zcorpan> | yoav: does http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0045.html help? |
| 12:53 | <yoav> | zcorpan: Yes, it does. Do you have a ballpark estimate of the number of tests required? (like the previous 10K number) |
| 12:55 | <yoav> | jgraham^^ |
| 12:59 | <zcorpan> | yoav: i dunno, maybe duplicate all img tests and then a few hundred tests for the selection algorithm plus a few hundred tests for the new fallback mechanism. though i very much doubt that amount of tests would materialize before shipping <picture> if we decide it's what we want |
| 13:00 | <yoav> | zcorpan: OK. Thanks! |
| 13:01 | <jgraham> | zcorpan: It seems interesting to get an estimate of how much <img> code could be reused directly in the <picture> case |
| 13:01 | <annevk> | MikeSmith: yeah, I concluded the same from that thread |
| 13:01 | <MikeSmith> | annevk: ok |
| 13:01 | <jgraham> | If it is "almost all" then the amount of testing you would need seems considerably lower than a balck-box estimate would suggest |
| 13:02 | <annevk> | MikeSmith: I guess I should try to be friendly and educate some more, but there's many other things to work on :/ |
| 13:02 | <jgraham> | +to achieve interop |
| 13:02 | <zcorpan> | jgraham: yeah. though i'm not familiar with img implementations to know if it can be reused without refactoring. if it requires refactoring, there's a regression risk for img, too |
| 13:02 | <jgraham> | zcorpan: Right, but we already have <img> tests |
| 13:02 | <jgraham> | Hopefully |
| 13:03 | MikeSmith | admires annevk for passing up the 386 opportunity |
| 13:05 | <zcorpan> | jgraham: so let's assume that we can reuse the img code (with or without refactoring) and we have a perfect testsuite for img (hahaha), i still wouldn't trust that the picture integration doesn't have bugs so doesn't need tests |
| 13:07 | <hallvors> | jgraham: I'm a bit late to that python server party you've been hosting, can I just clone https://github.com/jgraham/wptserve and it will work beautifully? |
| 13:07 | <jgraham> | zcorpan: Sure. But the question isn't "does it need tests". The question is "is the cost of the tests greater than the benefit of the better syntax?" |
| 13:07 | <Ms2ger> | Hehehehe |
| 13:08 | <zcorpan> | so one thing that i've discussed here but not on the list is <img> + <source> in a way like <input list><datalist> works. i don't know how people feel about that |
| 13:08 | <zcorpan> | jgraham: yes, i agree |
| 13:08 | <jgraham> | hallvors: Yes, but you probably want to just clone web-platform-tests, check out the jgraham/python_review_2 branch and follow the instructions in the readme file |
| 13:18 | <odinho> | hallvors: Check out with all submodules. I think a --recursive clone will do it for you. |
| 13:20 | <hallvors> | odinho, jgraham: thanks - it's up and running and was easily started indeed |
| 13:20 | <odinho> | ^_^ |
| 13:20 | odinho | is a fan |
| 13:36 | <yoav> | zcorpan: The " <input list><datalist>" model is interesting, but may be tricky to implement, as far as the preloader goes. One compromise would be to not preload <img src list> that doesn't have a matching datalist |
| 13:36 | <yoav> | Or to force the 2 elements to be near each other |
| 13:37 | <yoav> | Need to think about it... |
| 13:39 | <yoav> | zcorpan: What was the response to that model? |
| 13:40 | <annevk> | https://twitter.com/w3cmemes/status/402793055591620608 <3 |
| 13:56 | <MikeSmith> | https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/07U0lgaBP3g |
| 13:56 | <MikeSmith> | [[ |
| 13:56 | <MikeSmith> | - 92.5% pages have !DOCTYPE, most of them start with "<!doctype html" |
| 13:56 | <MikeSmith> | - 33.5% pages have Transitional doctype |
| 13:56 | <MikeSmith> | - 36.1% pages have <!doctype html>, <!DOCTYPE html> <!DOCTYPE HTML> |
| 13:56 | <MikeSmith> | ]] |
| 13:59 | <zcorpan> | yoav: i haven't seen much of a response |
| 13:59 | <yoav> | zcorpan:OK |
| 14:00 | <zcorpan> | yoav: we could require the source wrapper to be the next element sibling of img, which removes the need to use IDs |
| 14:00 | <yoav> | zcorpan: That would also simplify the preloader work. Would make it identical to picture in that sense. |
| 14:01 | <zcorpan> | yeah |
| 14:02 | <yoav> | zcorpan: In any case, I don't have a strong opinion regarding syntax. (as long as it's implementable, the major use-cases are covered, and no obvious hurdles to adoption are there) |
| 14:03 | <yoav> | zcorpan: So it sounds to me like your proposal would work (and won't require ~1K new tests), but might be best to ask the language design people what they think |
| 14:04 | <zcorpan> | i guess i can send an email about it and see what people think |
| 14:05 | <yoav> | zcorpan: I think that'd be good |
| 14:07 | <annevk> | zcorpan: supporting <input list><datalist> (ie without explicit ID) sounds like a good idea |
| 14:07 | <annevk> | zcorpan: IDs suck |
| 14:07 | <zcorpan> | annevk: yeah |
| 14:08 | <annevk> | file a bug? |
| 14:11 | <annevk> | hsivonen: so on Mac this XUL stuff maps to native menus? |
| 14:12 | <yoav> | zcorpan: On second thought, you'd need some indicator inside image that the 'src' should be loaded (for both the preloader and the parser) |
| 14:13 | <yoav> | s/should/shouldn't/ |
| 14:13 | <yoav> | Otherwise, the parser would start loading the image 'src' as soon as the element is created |
| 14:13 | <hsivonen> | annevk: yes. Also on Ubuntu in Canonical-provided builds |
| 14:14 | <yoav> | So you'd need the 'list' attr, just no id |
| 14:14 | <annevk> | hsivonen: cool, guess I finally know what inspired the <menu> feature |
| 14:14 | <annevk> | (although that might have dramatically changed now) |
| 14:16 | <zcorpan> | yoav: yes, i intended list="" for that |
| 14:16 | <yoav> | zcorpan: OK. Sounds good |
| 14:17 | <zcorpan> | yoav: technically the preloader could wait with preloading img until there is a next element sibling or the parent is closed, but it seems clearer to be explicit |
| 14:17 | <yoav> | zcorpan: I'm worried about the parser, not the preloader |
| 14:17 | <yoav> | The parser starts an img download before the element is added to the DOM, so has no notion of parent/sibling |
| 14:18 | <zcorpan> | ah, ok |
| 14:18 | <yoav> | I had these issues when implementing picture's <img> fallback |
| 14:19 | <annevk> | Note that for the dynamic case this seems kind of cumbersome to work with. Same with <picture> I suppose. With either you don't know when you can start loading the image after the element is created. |
| 14:20 | <zcorpan> | annevk: why is it different than today with just src and crossorigin=""? currently the load doesn't happen until you reach a stable state |
| 14:20 | <zcorpan> | per spec |
| 14:21 | <annevk> | zcorpan: currently you can load without appending |
| 14:21 | <annevk> | zcorpan: not sure how you see that work for an API that requires siblings |
| 14:22 | <zcorpan> | oh, right. yeah i didn't consider that. |
| 14:22 | <yoav> | annevk: Can you elaborate on that concern? I didn't get that |
| 14:23 | <zcorpan> | so let's say you want to load an image but not put it in the document |
| 14:23 | <yoav> | Ohhhh, OK |
| 14:23 | <zcorpan> | with srcset you just do var i = (new Image()).srcset = '...' |
| 14:23 | <Ms2ger> | Why would you set i to the value of srcset? |
| 14:23 | <yoav> | You'd have to create a document fragment,or something of that sort |
| 14:24 | <zcorpan> | Ms2ger: heh, oops |
| 14:24 | <zcorpan> | var i; (i = new Image()).srcset = '...' |
| 14:24 | <zcorpan> | better? |
| 14:25 | <Ms2ger> | :) |
| 14:25 | <jgraham> | "better" |
| 14:26 | <zcorpan> | yoav: yeah, or we could come up with something like setting .list to the element, and have that association go away when the elements are inserted to the document, but both of those are non-obvious |
| 14:27 | <yoav> | I agree that it's a complication |
| 14:27 | <zcorpan> | another idea is like <picture> syntax-wise, but require an <img> child that acts like "driver" i.e. the element that actually gets used for rendering and what you would paint on a canvas, etc |
| 14:28 | <yoav> | One could also argue that if you're adding sources lists dynamically, you can add only the ones relevant using matchMedia |
| 14:29 | <jgraham> | zcorpan: Elaborate? |
| 14:29 | <zcorpan> | like instead of <img list><sourcelist><source></sourcelist>, change it to <sourcelist><img list><source></sourcelist> |
| 14:29 | <hsivonen> | Cyrillic 8-bit encodings are still http://xkcd.com/927/ : https://bug805374.bugzilla.mozilla.org/attachment.cgi?id=8334498 |
| 14:30 | <hsivonen> | and that's after removing ISO-IIR and hiding MacCyrillic |
| 14:30 | <zcorpan> | the sourcelist element is a normal inline |
| 14:31 | <yoav> | zcorpan: Would you consider this easier for the dynamic case? |
| 14:32 | <yoav> | I guess it would be, since you'd have to create only 2 elements instead of 3... |
| 14:32 | <zcorpan> | yoav: it means you don't need a document fragment or anything to get the association when creating the things in script without appending to the document |
| 14:32 | darobin | wonders if that idea could be stretched to just reuse datalist instead of introducing sourcelist |
| 14:32 | <yoav> | zcorpan: I'm cool with it, as long as the <img> has a list attr |
| 14:32 | <zcorpan> | i need to leave (i'll read the logs) |
| 14:33 | Ms2ger | waves |
| 14:33 | <yoav> | I need leave soon as well, but I say post it to the lists |
| 14:33 | jgraham | would be interested to see the idea fleshed out (I would need to reread how datalist works to fully follow otherwise I think) |
| 14:41 | <annevk> | hsivonen: https://bug805374.bugzilla.mozilla.org/attachment.cgi?id=8334498 looks very nice! |
| 14:42 | <hsivonen> | annevk: thanks |
| 14:42 | <Ms2ger> | hsivonen, though maybe jp should use just "ISO" as well? |
| 14:43 | <annevk> | 2022 is sufficiently not ISO |
| 14:44 | <annevk> | so... |
| 14:44 | <annevk> | IE10 |
| 14:45 | <annevk> | Japanese (Auto-Select), Japanese (EUC), Japanese (Shift-JIS) |
| 14:45 | <annevk> | that's it |
| 14:45 | <hsivonen> | Ms2ger: that would break concordance with the other Japanese items |
| 14:46 | <hsivonen> | annevk: I like the way IE handles this |
| 14:46 | <annevk> | hsivonen: seems IE10 does not have an item for ISO-2022-JP |
| 14:46 | <annevk> | hsivonen: furthermore, only Japanese has Auto-Select |
| 14:46 | <annevk> | English locale though |
| 14:46 | <annevk> | (I do too) |
| 14:46 | <hsivonen> | annevk: I'm pretty sure Auto-Select has ISO-2022-JP magic |
| 14:46 | <hsivonen> | annevk: need to test how exactly Auto-Select in IE works |
| 14:47 | <hsivonen> | it could be a combo decoder for all the three Japanese encodings |
| 14:47 | <hsivonen> | which then raises the question: what does document.characterSet say? |
| 14:47 | <hsivonen> | (ringdingding) |
| 14:47 | <annevk> | I suspect it detects and makes a choice |
| 14:47 | <annevk> | Just like WebKit |
| 14:48 | <hsivonen> | but the story is the decoder for the ISO-2022-JP label does Shift_JIS, too |
| 14:48 | <hsivonen> | in IE |
| 14:48 | <hsivonen> | I need to test myself some day |
| 14:48 | <hsivonen> | but not for this patch |
| 14:49 | <annevk> | hsivonen: I'm wrong, it says "_autodetect_all" |
| 14:49 | <annevk> | hsivonen: tested by overriding in Live DOM Viewer and then <script>w(document.characterSet)</script> |
| 14:50 | <hsivonen> | annevk: awesome |
| 14:50 | <hsivonen> | might not be insane to spec that |
| 14:51 | <hsivonen> | I wonder if ISO-2022-JP is just an alias for that |
| 14:52 | <yoav> | zcorpan: Thought about it some more. You could even make your proposal look almost identical to <picture>, only with a mandatory <img> inside. That's brilliant! |
| 14:58 | <annevk> | hsivonen: if we end up with agreement among everyone that we need sniffing for Japanese and nothing else, I'll try to figure it out |
| 15:03 | <hsivonen> | annevk: FWIW, before Firefox 4 shipped, I tried to make the Japanese sniffing happen on the first 1024 bytes only. That broke the Japanese Planet Debian, which is why Firefox went whole stream. |
| 15:03 | <hsivonen> | Japanese Planet Debian has been fixed since |
| 15:04 | <hsivonen> | as is typical with stuff like this |
| 15:05 | <annevk> | hsivonen: for our other sniffing, do we enforce 1024 bytes? That is if there's less than 1024 bytes and the network is slow we'll wait with making a decision? |
| 15:06 | <annevk> | hsivonen: seems like something we should keep trying |
| 18:01 | <smaug____> | dglazkov: what is the reasoning for the events here http://w3c.github.io/webcomponents/spec/shadow/#events-that-are-always-stopped |
| 18:01 | <smaug____> | dglazkov: why those, and why not also submit and input |
| 18:02 | <smaug____> | and I assume there are many more |
| 18:39 | <Ms2ger> | Can I get a review on https://github.com/w3c/web-platform-tests/pull/397 / https://critic.hoppipolla.co.uk/r/387 please? |
| 18:40 | <jgraham> | Ms2ger: You can *do* the review on that... |
| 18:40 | <Ms2ger> | Sure, but getting one is more fun :) |
| 18:43 | <jgraham> | I'm not sure that going from N=tests.length iframes to N=1 iframe is obviously a great idea |
| 18:43 | <jgraham> | Doesn't it make the tests slower? |
| 18:44 | <Ms2ger> | Not if they end up swapping otherwise :) |
| 18:44 | <jgraham> | Right |
| 18:44 | <jgraham> | But how does N=1 compare to N=10, for example? |
| 18:45 | <Ms2ger> | No idea |
| 18:45 | <Ms2ger> | And I feel like I'll get burned at the stake if I suggest it :) |
| 20:16 | <zcorpan> | yoav: right |
| 20:33 | <zcorpan> | yoav: so the <img src> being loaded by the html parser before it has a parent, that seems like something that can be changed in impls by not loading it until it has been inserted to the document for img elements created by the parser, right= |
| 20:34 | <yoav> | zcorpan: It'd break scripts that create Image.src and never add it, but count on the resource downloading |
| 20:35 | <zcorpan> | yoav: scripts that create Image.src aren't created by the parser |
| 20:40 | <yoav> | zcorpan: Yeah. It's not the parser that downloads. It happens during element creation. |
| 20:40 | <yoav> | I guess you could create a separate path for scripts, in some way |
| 20:41 | <zcorpan> | you just need the html parser to set a flag |
| 20:41 | <yoav> | But I don't know if it's something that browsers want to do |
| 20:41 | <zcorpan> | <script> has such a flag (not that <script> processing is in any way sane) |
| 20:43 | <yoav> | zcorpan: Look. Ibumped into trouble there when working on picture, and didn't want to modify HTMLImageElement because I was afraid it'd break stuff |
| 20:44 | <yoav> | But, ask it on the list and the DOM people must have an opinion on the subject |
| 20:45 | <yoav> | The only question it raises is whether we "flag" the image or not (by adding an attr) |
| 20:46 | <yoav> | If the DOM people are cool with postponing image download until the element is in the DOM (when the element is parsed), I'd certainly won't object |
| 20:47 | <zcorpan> | the flag wouldn't be an attribute, just a bit that is invisible to JS |
| 20:48 | <zcorpan> | should the img go first or last? |
| 20:49 | <yoav> | last would be better IMO, so when it's parsed, it can already walk its parent and get the resources |
| 20:50 | <yoav> | Nah, I don't make sense |
| 20:51 | <yoav> | We need to wait till its added to its parent, so I'm not sure it matters much. Need to look into it. |
| 20:53 | <zcorpan> | if it's first, then the <source>s won't be in the tree when the img element is inserted |
| 20:53 | <zcorpan> | but kornel's algorithm handles that fine by just re-running the algorithm for each <source> (or once when the parent is closed) |
| 20:54 | <zcorpan> | maybe more relevant is what authors expect it should be. if they think the syntax should be like <video>, then the sources should come first |
| 20:56 | <yoav> | You're right that we can hook up on the insertion to its parent. You're also right that authors would expect <img> to be last |
| 20:57 | <zcorpan> | even if img goes last, we could make <picture> own the selection algorithm and run it for each <source>/<img> that is inserted, in case we want <picture><source> (pause) <img> to start loading before the img element exists |
| 20:57 | <yoav> | I tend to think that it might be best to wait till the parent closes, and only then start fetching, to avoid cases where <img> is first from breaking, as it may be a common authoring error, and I don't see serious downsides to it |
| 20:59 | <yoav> | Starting load before the parent is completed would only benefit us if the HTML buffer is split after <img> and before </picture> |
| 21:01 | <zcorpan> | right. maybe the <img> is big because the fallback src is a big SVG as a data: URL or something |
| 21:02 | <yoav> | That doesn't make sense (from an authoring PoV) |
| 21:02 | <yoav> | fallback image should be something you usually don't download |
| 21:03 | <zcorpan> | OTOH starting the load before img exists might mean that you download something that won't be used because there actually isn't an <img> element |
| 21:04 | <yoav> | zcorpan: Yeah. I also think that it'd mean that picture would have to be a lot smarter than it needs to with this scheme |
| 21:04 | <zcorpan> | i don't follow 'fallback image should be something you usually don't download' |
| 21:04 | <yoav> | I'd be much more comfortable if HTMLImageElement will be the one doing the download, just getting its sources from picture |
| 21:05 | <zcorpan> | ok |
| 21:06 | <yoav> | A data URI as a fallback image doesn't make sense, because then you're downloading the fallback image and the actual image |
| 21:07 | <gsnedders> | yoav: Don't apply logic! People won't follow it! |
| 21:07 | <yoav> | gsn |
| 21:07 | <zcorpan> | ah yeah, i agree it doesn't make sense. but i wouldn't be surprised to see that sort of thing in the wild :-) |
| 21:08 | <yoav> | gsnedders: People are logical beings, no? |
| 21:08 | <zcorpan> | or a big <script> |
| 21:08 | <zcorpan> | or not a big but a <script src> which blocks the parser from closing the parent |
| 21:09 | <gsnedders> | yoav: Well, you say that, but there's lots of stupid stuff on the web… |
| 21:10 | <zcorpan> | yoav: people aren't really logical beings |
| 21:11 | <zcorpan> | yoav: people like to think that they act based on logical thinking but actually often act based on emotions, belief, etc :-) |
| 21:12 | <zcorpan> | or based on what other people say or do |
| 21:12 | yoav | was joking :) |
| 21:13 | <yoav> | But, I'm not sure implementation should be complicated in order to optimize authoring errors |
| 21:14 | <zcorpan> | yeah it probably doesn't need to, we can just make <img> look at its previous siblings and start loading when the img is inserted to the document |
| 21:25 | <zcorpan> | actually per spec, <img> shouldn't start loading anything until a 'stable state' has been provided, which would be between tasks of the html parser, i think |
| 21:27 | <zcorpan> | so the spec wouldn't need the flag, but maybe actual impl would want a flag and not wait until the parser yeilds |
| 21:27 | <zcorpan> | or the spec should be changed to not await a stable state for parser-created img |
| 21:30 | <TabAtkins> | Are we still considering the "<img> is the driver, it uses <picture> or <sourcelist> or whatever as a data source" idea? |
| 21:32 | <zcorpan> | it's what we're discussing yeah |
| 21:33 | <TabAtkins> | Excelelnt. |
| 21:34 | <yoav> | TabAtkins: What's your opinion on that option? |
| 21:34 | <TabAtkins> | I'm down with this. |
| 21:34 | <yoav> | Awesome! |
| 21:36 | <zcorpan> | i need to ponder what should happen for dynamic updates to <source>s. <video> ignores some changes (like changing src attribute of a <source>) |
| 21:38 | <zcorpan> | but i think this could listen to mutations to <source src> and rerun the selection algorithm on the next tick, since doing so isn't destructive as for <video> |
| 21:44 | <TabAtkins> | Yeah, that sounds fine to me. |
| 21:45 | <TabAtkins> | (And reminds me that I've specced src-N to not pay attention to mutations, which is a problem.) |
| 21:54 | <zcorpan> | srcset handles mutations. this just needs to have more listeners |
| 22:08 | <zcorpan> | ok at this point my brain has stopped working so i just sent the email |
| 22:16 | <gsnedders> | Does anyone know the situation with character encoding of HTML in emails? |
| 22:17 | <Hixie_> | anyone got an opinion on what should happen with History objects of non-active documents, when you use them? https://www.w3.org/Bugs/Public/show_bug.cgi?id=23359 |
| 22:17 | <Hixie_> | (browsers all disagree) |
| 22:43 | <bholley> | Hixie_: ping |
| 22:43 | <Hixie_> | yo |
| 22:44 | <bholley> | Hixie_: quick question - according to the current spec, navigating an iframe by programatically setting .src uses the iframe as the source browsing context, rather than the incumbent script |
| 22:44 | <bholley> | Hixie_: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#process-the-iframe-attributes |
| 22:44 | <bholley> | Hixie_: is that intentional? |
| 22:44 | <bholley> | it impacts sandboxing |
| 22:44 | <Hixie_> | you mean rather than the incumbent script's responsible browsing context? |
| 22:45 | <bholley> | Hixie_: correct |
| 22:46 | <Hixie_> | it shouldn't make any difference in general, whether it's the iframe's ownerDocument's browsing context or the responsible browsing context specified by the incumbent settings object |
| 22:47 | <Hixie_> | but in some cases, there's no incumbent settings object |
| 22:47 | <Hixie_> | so that's why i use the iframe's host document's browsing context |
| 22:47 | <Hixie_> | (e.g. when parsing the <iframe> in the first place) |
| 22:47 | bholley | thinks |
| 22:49 | <bholley> | Hixie_: what about the allow-same-origin case where a sandboxed iframe attempts to navigate a non-sandboxed parent by setting the src attribute on its frameElement? |
| 22:49 | <bholley> | Hixie_: in that case, the navigation will succeed by setAttribute('src', foo), and fail by |location = foo| |
| 22:49 | <bholley> | Hixie_: (I know allow-same-origin is kind of a stupid example) |
| 22:51 | <Hixie_> | if you have a sandboxed iframe, the only way it could do that is if you do allow-same-origin and allow-script at the same time |
| 22:51 | <Hixie_> | and if you do that, you've basically lost. |
| 22:51 | <bholley> | Hixie_: right |
| 22:51 | <Hixie_> | i mean it could just create a new iframe and do whatever it wants in that |
| 22:51 | <bholley> | Hixie_: sure |
| 22:52 | <Hixie_> | self.location = foo shouldn't fail though, should it? |
| 22:52 | <Hixie_> | you can always navigate yourself |
| 22:52 | <bholley> | Hixie_: I'm just pointing out the existence of a somewhat-arbitrary behavioral difference here |
| 22:52 | <bholley> | Hixie_: I'm fine with it |
| 22:52 | <Hixie_> | (oh you mean two iframes deep, i see) |
| 22:53 | <Hixie_> | yeah, it is somewhat arbitrary. i justify it as one being an API, and thus being designed around script, and the other being the markup, and thus being designed around that. |
| 22:53 | <Hixie_> | conceptually, if you set src="" you are reconfiguring the <iframe> |
| 22:53 | <Hixie_> | whereas if you set location you are following a link |
| 22:54 | <Hixie_> | it's a bit dubious, but that's how i justify it :-) |
| 22:54 | <bholley> | Hixie_: fair enough - thanks for the clarification :-) |
| 22:59 | <Hixie_> | bholley: do you have an opinion on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23359 ? (History in non-active documents) |
| 23:00 | <bholley> | Hixie_: hmmm |
| 23:01 | <bholley> | Hixie_: let me see if there's any recent context on our permissiveness here |
| 23:02 | <Hixie_> | i'm guessing it's just you do an origin check rather than a liveness check |
| 23:02 | <Hixie_> | but if there's a compat reason that would be interesting |
| 23:02 | <bholley> | Hixie_: yes, exactly |
| 23:02 | <bholley> | Hixie_: apparently I put it in |