| 08:09 | <hsivonen> | Hixie: the other day, you were trying to find spec changes "Mozilla" wants. Have you noticed that Mozilla is reviving the inputmode attribute (with different values if I understand correctly)? |
| 09:06 | <hsivonen> | MikeSmith: this thing uses the W3C's servers as its back end, right? http://w3clove.com/plans-and-pricing |
| 09:06 | <MikeSmith> | hsivonen: yeah I believe it does |
| 09:07 | <hsivonen> | MikeSmith: mildly interesting that the front end talks about priority levels then |
| 09:08 | <hsivonen> | but I guess there are priorities in the front end queue |
| 11:35 | <Ms2ger> | (CVS $Revision: 87e938c14c3f $) |
| 11:54 | <hsivonen> | so now I have to figure out what the navigation timing spec says about restoration from the BF cache... |
| 11:55 | <hsivonen> | restore from BF cache isn't supposed to fire a readystatechange, is it? |
| 11:57 | <hsivonen> | nice. the navigation timing spec doesn't cover BF cache |
| 11:58 | <hsivonen> | sigh. |
| 11:58 | <hsivonen> | let's see if HTML5 does |
| 11:58 | <hsivonen> | or HTML LS rather |
| 12:01 | <hsivonen> | hooray. HTML LS actually covers BF cache and it's pretty clear my assertions found a Gecko bug |
| 12:01 | <hsivonen> | I hope no one is depending on the bug yet... |
| 12:11 | <Ms2ger> | \o/ |
| 12:33 | <MikeSmith> | BF cache? |
| 12:33 | <hsivonen> | MikeSmith: back/forward cache for Document objects |
| 12:33 | <MikeSmith> | OK |
| 12:34 | <hsivonen> | the next time someone gives a gift like readyState, we should be more careful about making sure the gift comes with unit tests |
| 12:45 | <hsivonen> | } else { |
| 12:45 | <hsivonen> | // XXX: Should fire error event to the document... |
| 12:45 | <hsivonen> | } |
| 12:45 | <hsivonen> | doesn't look exactly compliant there |
| 12:48 | <hsivonen> | Hixie: sorry about the tone of my latest email in the readyState thread. I'm rather frustrated about this not being a bug fix in the past yet. |
| 14:21 | <hsivonen> | how fun. removing-editable-xslt.html |
| 14:21 | <hsivonen> | because everyone wants to have editable XSLT |
| 14:26 | <[tm]> | hahaha |
| 14:27 | <hsivonen> | the generated documents for image, video, audio and plug-in URLs (when loaded alone in a browsing context) and XSLT documents are my least favority kind of documents |
| 14:27 | <hsivonen> | after about:blank of course |
| 14:30 | <Ms2ger> | hsivonen, well, fortunately nobody scripts the those :) |
| 14:34 | <[tm]> | if browser vendors would just implement xslt 3.0 I'm sure it would solve all those problems |
| 14:37 | <[tm]> | seriously though xpath and xslt are still a better API than the standard DOM |
| 16:00 | <dglazkov> | good morning, Whatwg! |
| 16:24 | <kennyluck> | good night, Whatwg! |
| 16:25 | <espadrine`> | kennyluck: are you doing the opposite of what dglazkov is doing every morning? |
| 16:26 | <kennyluck> | espadrine`, sort of, but I am about to go to bed too. |
| 16:27 | <espadrine`> | good night then! |
| 17:16 | <annevk> | dglazkov: kennyluck: it's WHATWG \o/ |
| 17:16 | <annevk> | also happy e-day |
| 17:17 | <espadrine`> | annevk: what's an e-day? |
| 17:26 | <annevk> | not sure, but I meant it as a timezone neutral greeting |
| 17:34 | <Hixie> | hsivonen: ah, excellent, just the kind of thing i was looking for. do you have any links to that? there's some bugs asking for inputmode but they're all stuck on people doing some research so we can work out what it actually needs to be |
| 17:35 | <Hixie> | annevk: try "hi" :-P |
| 17:37 | <Hixie> | hsivonen: "Firefox, IE10, and Opera" is less than 50% of the market, what are you talking about "rocking the interop boat"? |
| 17:38 | <Hixie> | especially since in the text you quote you point out firefox isn't doing the same thing either |
| 17:39 | <gsnedders> | jwalden: Yay! |
| 17:44 | <Hixie> | MikeSmith: yt? |
| 17:56 | <bencc> | shepazu: you were the one recommending fakesmile? |
| 18:48 | <hsivonen> | Hixie: Firefox currently fires the event you say shouldn't fire |
| 18:49 | <hsivonen> | the way current Firefox differs from what I want is its omission to transition to "interactive" |
| 18:50 | <Hixie> | firing DOMContentLoaded doesn't make much sense if you're not firing 'load' |
| 18:50 | <Hixie> | and firing DOMContentLoaded when you haven't loaded the DOM content is silly IMHO |
| 18:51 | <Hixie> | i don't see what possible advantage it would be to authors |
| 18:51 | <hsivonen> | Hixie: about inputmode: https://bugzilla.mozilla.org/show_bug.cgi?id=746142 |
| 18:52 | <hsivonen> | Hixie: I see no advantage in not firing it |
| 18:53 | <Hixie> | do you plan to fire 'load'? |
| 18:54 | <hsivonen> | no. not because I think it makes sense not to but because everyone refrains from firing it |
| 18:58 | <Hixie> | hsivonen: refrain from firing DOMContentLoaded and then most people will refrain from firing that, too |
| 18:58 | <Hixie> | s/people/browsers/ |
| 18:59 | <Hixie> | hsivonen: DOMContentLoaded is basically the same event as 'load', just before scripts |
| 18:59 | <Hixie> | hsivonen: it would be silly to fire one and not the other, IMHO |
| 18:59 | <Hixie> | hsivonen: and very confusing to authors |
| 19:58 | <annevk> | not sure anyone cares, but @WHATWG is nearing 6666 |
| 19:58 | <Hixie> | 6666 what? |
| 19:59 | <Tabatkins> | tweets, presumably |
| 19:59 | <annevk> | followers |
| 20:00 | <annevk> | tweets is 3752 |
| 20:02 | <Hixie> | are we still tweeting all the non-editorial changes? |
| 20:03 | <annevk> | yes |
| 20:03 | <Hixie> | man, that's 6666 crazy people |
| 20:03 | <annevk> | we omit things that say "typo" and "xref" |
| 20:04 | <annevk> | the editorial stuff is quite popular sometimes |
| 20:04 | <Hixie> | heh |
| 20:05 | <annevk> | people retweet things like "fix obsolete non-normative text" |
| 20:05 | <Hixie> | o_O |
| 20:05 | <annevk> | and pay no attention to normative changes |
| 20:05 | <annevk> | I'm not sure how this works |
| 20:07 | <Hixie> | maybe instead of createImageDataHD i should just have a third argument that takes the scale factor |
| 20:07 | <Hixie> | nah |
| 20:07 | <Hixie> | it's tied to a canvas |
| 20:07 | <Hixie> | ok |
| 20:08 | <Hixie> | createImageDataHD it is |
| 20:08 | <hober> | it's hard to feature detect optional args v. new methodas |
| 20:08 | <hober> | err, methods |
| 20:09 | <annevk> | so there will be a new object ImageDataHD too/ |
| 20:09 | <annevk> | ? |
| 20:10 | <Tabatkins> | hober: One reason I'm excited about @supports - makes it easier to feature-detect new values in existing properties. |
| 20:59 | <Hixie> | hober: doesn't .length return the length of the longer one? |
| 20:59 | <Hixie> | annevk: no |
| 20:59 | <Hixie> | hober: (and yeah, i went back to the HD idea anyway) |
| 21:00 | <Hixie> | hober: what was the attribute you wanted, again, btw? |
| 21:13 | <Tabatkins> | hsivonen: Some discussion about <template> led to an interesting insight. |
| 21:14 | <Tabatkins> | hsivonen: Regarding <iframe srcdoc>, it was designed as an attribute to make escaping easier, but ignoring that, it would obviously have been easier to do a <sandbox> element, where you just put in user content directly. |
| 21:15 | <Tabatkins> | hsivonen: In that case, you'd have elements parsed as part of the outer document, but bundled up into a separate document hanging off of the main doc instead. |
| 21:15 | <Tabatkins> | hsivonen: Which is, of course, essentially identical to what <template> does. |
| 21:15 | <Tabatkins> | hsivonen: Do your arguments against <template> apply equally to <sandbox>? Or are there significant differences that I'm not seeing? |
| 21:17 | <othermaciej> | Tabatkins: the reason a <sandbox> element wouldn't work is that it's too hard to prevent hostile content prematurely closing the <sandbox> tag |
| 21:18 | <Tabatkins> | Yes, I referred to that above. That's why we used an attribute instead of an element. |
| 21:18 | <Tabatkins> | But disregarding that consideration, @srcdoc is effectively embedding a second document into the content of the first, inline. |
| 21:19 | <Tabatkins> | Basically I'm just probing at hsivonen's internal consistency here, to see if there are good reasons to be against one and not the other. |
| 21:19 | <Hixie> | it's much like what <style> and <script> already do |
| 21:19 | <Tabatkins> | Yeah. |
| 21:19 | <Hixie> | i suppose we could have <template> wrk more like those |
| 21:19 | <Hixie> | have the text be in the outer doc |
| 21:19 | <Hixie> | and then have a parsed dom hang off the side |
| 21:19 | <othermaciej> | since <sandbox> is hypothetical, I'm not sure it's a useful query of hsivonen's views |
| 21:19 | <Hixie> | much like how <style> has a textContent node unparsed, and a CSSOM off the side, post-parse |
| 21:19 | <othermaciej> | since being for or against it has no consequence |
| 21:20 | <Tabatkins> | othermaciej: Just checking. If hsivonen would be okay with <sandbox> (ignoring the security consideration), then I'd be curious why, and how that applies to his arguments against <template>. |
| 21:20 | <othermaciej> | if you made <template> work like that, then presumably in xhtml, you would have to escape its contents as a CDATA section |
| 21:20 | <Tabatkins> | Hixie: No problem with that from me. |
| 21:20 | <Tabatkins> | othermaciej: I guess, yeah. |
| 21:21 | <Hixie> | <template> as specced just doesn't work in xhtml |
| 21:21 | <Hixie> | as proposed, i should say |
| 21:21 | <othermaciej> | if <sandbox> was inline, then it might not want to create a subframe and a separate document |
| 21:21 | <Tabatkins> | If that was the objection, and saying "just escape as CDATA" gets around it, that's not a problem. ^_^ |
| 21:21 | <Hixie> | or maybe "as specced" is right, the proposal is pretty detailed :-) |
| 21:22 | <Tabatkins> | othermaciej: I think most of the sandboxing stuff would be very annoying / error-prone to implement if you didn't use a separate document. |
| 21:22 | <Hixie> | othermaciej: we used a subframe for its security properties |
| 21:22 | <othermaciej> | I have to admit I don't really understand the reasons why <template> can't be in the normal DOM |
| 21:22 | <Hixie> | othermaciej: it's similar to sandboxing, actually. you need a way to neuter all the features. forms, images. etc. |
| 21:22 | <annevk> | also selectors |
| 21:23 | <othermaciej> | I don't understand why selectors have to be neutered (that argument somewhat confuses me) and I don't understand how a separate document helps w/ those other aspects |
| 21:23 | <annevk> | you can theoretically do the others by adding conditionals |
| 21:23 | <Tabatkins> | Yeah, just like sandboxing, you *can* do it in the same document, but it's way easier conceptually (and you're less likely to have errors) if you do it as a separate doc. |
| 21:24 | <Tabatkins> | othermaciej: You get them for free! Disconnected documents don't load anything, don't contribute to forms, don't match against selectors from the outer document... |
| 21:24 | <othermaciej> | preventing script execution and subdocument loading and the like is already a conditional in WebKit's DOM, you'd merely need to change the condition |
| 21:24 | <othermaciej> | er, subresource loading |
| 21:25 | <othermaciej> | like, there's nothing about how XHR-loaded documents do those things that intrinsically needs to be document-scoped |
| 21:25 | <othermaciej> | selector matching is the only anomaly, and I am not sure why it needs to be one (maybe I would if I read more about it) |
| 21:25 | <Hixie> | othermaciej: you want to neuter everything. appearing in document.images, appearing in an ancestor's form.elements, appearing in an ancestor select.options, form submission, creating of nested browsing contexts, running scripts, etc etc etc |
| 21:26 | <Hixie> | othermaciej: there are so many places we'd have to add checks it would be unmanageable |
| 21:26 | <othermaciej> | I think <template> has a hard problem that it won't be able to offer any of its features as currently designed unless you require some sort of escaping of the content |
| 21:26 | <othermaciej> | er, won't be able to offer them in non-supporting browsers |
| 21:26 | <Hixie> | i think the idea is to make <template> work exactly like XHR-loaded documents |
| 21:26 | <othermaciej> | so the more differences it has from normal content, yet without escaping, the harder it is to use |
| 21:27 | <Hixie> | (except inline) |
| 21:27 | <othermaciej> | unless you wait until the hypothetical day when all browsers have it |
| 21:27 | <Tabatkins> | Hixie: I think that's right, yeah. |
| 21:27 | <othermaciej> | or to put it another way, it doesn't degrade gracefully |
| 21:27 | <Tabatkins> | othermaciej: Those hypothetical days come sooner all the time. ^_^ |
| 21:27 | <Hixie> | yeah, it definitely doesn't degrade that well as proposed |
| 21:27 | <Hixie> | we've tried a graceful degradation approach before (see web forms 2's repetition model), it wasn't that great |
| 21:28 | <Tabatkins> | We're okay with pushing on a good idea even if it'll be a few years before it's usable in practice. Degrading is great, but you can't always degrade gracefully. |
| 21:28 | <othermaciej> | Tabatkins: I wonder if a version of the feature that has the templates out-of-line or escaped would be viable |
| 21:28 | <Hixie> | certainly if someone can come up with a way to make it degrade, i'd be all for it |
| 21:28 | <othermaciej> | are those options so bad that it's worth the greater transition cost? |
| 21:28 | <Tabatkins> | othermaciej: We're down with out-of-band templates too. If that's the way you ahve to use them until support evolves (parsing on your own in legacy browsers), that's also fine. |
| 21:28 | <othermaciej> | <template src="foo.html#id"></template>, the way to degrade is use XHR |
| 21:29 | <Hixie> | Tabatkins: have they (you? we?) considered doing something like srcdoc="" for <template>? |
| 21:29 | <othermaciej> | that would have an excellent graceful degradation story |
| 21:29 | <Tabatkins> | Hixie: I don't think we have. |
| 21:29 | <othermaciej> | <template srcdoc=""> would also have a good story |
| 21:29 | <Hixie> | might be worth looking at |
| 21:29 | <othermaciej> | if you give up on "inline template as normal markup", all the issues go away |
| 21:30 | <othermaciej> | where "give up" might just mean "don't focus on initially" |
| 21:30 | <Tabatkins> | It's kinda nasty, but if it's a second inline option alongside proper children, that sounds like it would be palatable. |
| 21:38 | <hober> | Hixie: (sorry for the delay) a static attr on HTMLCanvasElement, window, or something like that which is "the backingStorePixelRatio that you'll get if you create a new canvas right now." |
| 21:38 | <Hixie> | no preferred name or location though? |
| 21:41 | Hixie | discovers that toDataURL and toBlob aren't actually required to return the canvas' image at all |
| 21:41 | <Hixie> | oops |
| 21:43 | <hober> | I don't have a particular name or location preference, no, so long as you don't need to instantiate a canvas to get at it |
| 21:44 | <Hixie> | do we have a spec that specs window.screen? maybe that'd be a good place for it |
| 21:45 | <hober> | that's a pretty reasonable place, yeah. AFAIK there's no spec for window.screen though. :( |
| 21:46 | <Hixie> | http://dev.w3.org/csswg/cssom-view/#screen ! |
| 21:46 | <Hixie> | we do have it! |
| 21:46 | <Hixie> | awesome |
| 21:47 | <Hixie> | man i wish anne was still editing those specs |
| 21:47 | <Hixie> | anyone know who i have to speak to to get things added to that? |
| 21:47 | <hober> | "Editor's Draft 13 March 2012" sadface. they were supposed to update the ED last week... |
| 21:47 | <Tabatkins> | I'm gonna poke the thread again. |
| 21:47 | <Hixie> | oh that's those specs that are in limbo isn't it |
| 21:48 | <hober> | yup |
| 21:48 | <Tabatkins> | Yup. I'll pick them up in September if they stay in limbo. |
| 21:48 | <Hixie> | aren't you, like, already under a pile of specs three miles high |
| 21:48 | <Tabatkins> | Your point? |
| 21:49 | <Hixie> | yeah i guess glass houses and all... |
| 21:51 | <Tabatkins> | Hixie: Feel free to add something to it from the HTML spec for now, but shoot an email to www-style about it so we can track it. |
| 21:51 | <Hixie> | k |
| 21:55 | <Hixie> | hober: i've also added toDataURLHD and toBlobHD |
| 21:56 | <Hixie> | hober: we probably need to do something to drawImage, too |
| 21:56 | <Hixie> | hober: though maybe people can deal with the latter by giving the expected dimensions, so nevermind |
| 21:57 | <hober> | nice, thanks |
| 22:31 | <Tabatkins> | Ah, CSSOM started updating today. |
| 23:07 | <linelevel> | From the W3 spec on HTML5 data-* attributes: "It would be inappropriate, however, for the user to use generic software not associated with that music site to search for tracks of a certain length by looking at this data. This is because these attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata." |
| 23:07 | <linelevel> | I'm wondering what the rationale for that restriction is. It seems like a great way to embed public metadata in HTML. |
| 23:08 | <Tabatkins> | Two reasons. |
| 23:08 | <Tabatkins> | 1) Eliminate any possibility of accidental collisions, like a search engine assigning meaning to certain data-* attributes that you happen to be using for something else. |
| 23:08 | <Tabatkins> | There's no need for a registry or anything if we explicitly disallow this kind of thing, so that all usage is private. |
| 23:09 | <Tabatkins> | 2) That's what Microdata is for - it's better designed for decorating pages with metadata. |
| 23:11 | <linelevel> | Tabatkins: Thanks, that makes sense. |