| 00:00 | <Hixie_> | so does the HTML parser |
| 00:00 | <MikeSmith> | Hixie_: I guess some there's some irony in you holding up W3C organizational (mis)usage of <h2> as a precedent that needs to limit how we can properly define it now :) |
| 00:00 | <rillian> | Hixie_: hence my confusion |
| 00:01 | <Hixie_> | MikeSmith: well it's not just the w3c |
| 00:01 | <Hixie_> | rillian: aah, ok. yeah, parsers can't collapse the white space, since if they did then 'white-space: pre' would have no way to "un"collapse it |
| 00:02 | <zewt> | rillian: people tend to use nbsp in whitespace collapsing-related hacks ( ), but that's not its real purpose |
| 00:02 | <Hixie_> | MikeSmith: my point is just that it's common usage |
| 00:02 | <Hixie_> | MikeSmith: <hgroup> just makes that usage less theoretically wrong |
| 00:02 | <rillian> | zewt: *node* |
| 00:03 | <zewt> | *parent* |
| 00:05 | <MikeSmith> | Hixie_: ok I concede that it's common usage but I don't think it necessarily follows that we need to add a new element to the language in order to handle a particular case of processing that's only needed for documents that follow that usage |
| 00:05 | <MikeSmith> | to paraphrase Brendan, I think the bar needs to be higher than that |
| 00:06 | <Hixie_> | MikeSmith: why? |
| 00:07 | <MikeSmith> | Hixie_: because the default answer for new elements is No, and I think there are other cases where the answer has been No and remained No that had relatively more merit than hgroup |
| 00:07 | <rillian> | zewt: I think I might be out of productive work time for the day :) |
| 00:10 | <Hixie_> | MikeSmith: like what? |
| 00:12 | <MikeSmith> | Hixie_:< time> |
| 00:12 | <MikeSmith> | I am not a fan of <time> |
| 00:13 | <MikeSmith> | despite implementing validator support for it in all its baroqueness |
| 00:13 | <MikeSmith> | but I know other people seem to be almost fanatical about it |
| 00:13 | <Hixie_> | <time> is in |
| 00:13 | <Hixie_> | no? |
| 00:13 | <MikeSmith> | yeah but witness the fact that when you tried to drop it, they almost came and burned the castle down |
| 00:14 | <MikeSmith> | I'd rather you had dropped it and it had stayed out |
| 00:14 | <MikeSmith> | but anyway, I think if we drop <hgroup> there is not going to be any insurrection like we had with <time> |
| 00:14 | <Hixie_> | there's two <time> elements |
| 00:15 | <Hixie_> | there's the old one, which we dropped, and a new one, which solves entirely different use cases |
| 00:15 | <MikeSmith> | I think the general reaction if <hgroup> is dropped is just going to be "meh" |
| 00:15 | <MikeSmith> | Hixie_: OK |
| 00:15 | <Hixie_> | well people need _something_ to do subheadings |
| 00:15 | <Hixie_> | <hgroup> seems like the best solution for it so far |
| 00:15 | <MikeSmith> | the only <eim> I care about much personally is the one I have to implement validator support for |
| 00:16 | <MikeSmith> | Hixie_: I guess it doesn't seem to me that <hgroup> is the best solution and we still have a chance to come up with something better |
| 00:17 | <MikeSmith> | not that I have any better suggestion myself right now |
| 00:17 | <Hixie_> | if there's only one proposal, it's by definition the best one :_P |
| 00:18 | <Hixie_> | personally i think it works fine, solves all the use cases, and is nice and simple and backwards compatible and basically has no problems |
| 00:18 | <Hixie_> | i don't really understand what the fuss is about |
| 00:18 | <MikeSmith> | Hixie_: I guess if there's only one proposal, it's by definition the worst one |
| 00:18 | <Hixie_> | yup |
| 00:18 | <Hixie_> | well |
| 00:18 | <Hixie_> | there's an infinite number of proposals that we'd all readily admit are worse |
| 00:19 | <Hixie_> | e.g. introducing an <hgroup_9821518357> element |
| 00:19 | <MikeSmith> | Hixie_: on thing I'm aware of as a problem is that per the current spec, AT munges the subheading into the main heading, with no pause or nothing in between. Which seems bad for screen-reader useers. |
| 00:20 | <MikeSmith> | If you can have the spec address that problem, maybe we could get agreement |
| 00:20 | <Hixie_> | wait, what? |
| 00:20 | <Hixie_> | why would they do anything different than they used to |
| 00:21 | <MikeSmith> | dunno but that is what I remember hearing from the discussions |
| 00:22 | <MikeSmith> | the why is because I think the spec requires AT to handle them differently if they are in hgroup |
| 00:22 | <MikeSmith> | or I assume so |
| 00:22 | <Hixie_> | if the ATs are so dumb as to actively regress their behaviour intentionally, then it's a lost cause. |
| 00:22 | <MikeSmith> | because otherwise like you said, the spec would not be introducing any behavior change with respect to AT |
| 00:24 | <MikeSmith> | what I'm saying is that I think the (unintended) effect of the current spec is that the text of the headings ends up munged together in the accessibility tree |
| 00:24 | <Hixie_> | well that's a bug they should fix if they care about their users |
| 00:24 | <Hixie_> | i guarantee that the spec doesn't say they should do that. even if it did, it'd be ridiculous to implement such a thing. |
| 00:34 | <Hixie_> | god, i can't believe accessibility advocates are still arguing for longdesc |
| 00:35 | <Hixie_> | it's so utterly disheartening to see a community that paints itself as advocates for another community be so incompetent and so utterly fail that community. |
| 00:48 | <MikeSmith> | Hixie_: in that case of longdesc it's not even the community overall that's advocated for it |
| 00:49 | <MikeSmith> | instead it's a very vocal and aggressive faction within the community |
| 00:50 | <MikeSmith> | a faction that's well connected enough that it can ignore and override objections about longdesc that come from their closest colleagues |
| 00:50 | <Hixie_> | so sad |
| 00:53 | <MikeSmith> | yuup |
| 01:57 | <karlcow> | In the department of silly ideas, <h1><ruby><rb>HEADING</rb><rt>SUBHEADING</rt></ruby></h1> |
| 02:00 | <Hixie_> | heh |
| 02:02 | <chee> | i would support longdesc if the referenced file had to contain exactly 1,000 words. |
| 02:45 | <zewt> | death to target=_blank |
| 02:47 | <zewt> | needs to be whitelist-only, except for actual web apps they're nothing but "please don't leave our site!" intrusive crap |
| 04:49 | <heycam> | TabAtkins, ping |
| 04:54 | <heycam> | (mailed) |
| 05:37 | <sicking> | heycam: you got my email about 'undefined' |
| 05:37 | <sicking> | right? |
| 05:38 | <heycam> | sicking, I did and it's the next thing I'll get to when I switch to Web IDL stuff |
| 05:38 | <heycam> | sicking, sorry for not replying to indicate that! |
| 05:38 | <sicking> | heycam: no worries. I actually prefer that people don't send the 'ok' replies. Too much inbox churn |
| 05:38 | <heycam> | heh |
| 05:38 | <sicking> | heycam: but since i saw you here... |
| 06:45 | <SteveF> | MikeSmith: this sums up average response from twitterverse on dropping hgroup: "W3C remove hgroup tag from HTML5 spec, representing the first time anyone heard of it" |
| 06:51 | <SteveF> | MikeSimth: https://twitter.com/codepo8/status/319207945122504704 |
| 06:54 | <SteveF> | MikeSmith: there are a number of proposals of replacements on replacements/mods for hgroup |
| 06:55 | <SteveF> | hixie: on the acc layer semantics you blocked any attempt to make the mappings sane |
| 06:56 | <SteveF> | hixie: but we don't have to argue that on hgroup anymore :-) |
| 06:59 | <SteveF> | hixie: the <hx><hx> pattern to markup subheadings is about as common as longdesc in the wild, developers use a wide variety of elements to mark up subheadings/subtitles/taglines etc |
| 07:03 | <zcorpan> | has anyone tried to remove mutation events yet? |
| 07:31 | <zcorpan> | why don't we use <script> for HTML Imports? |
| 08:11 | <SimonSapin> | TabAtkins: css-syntax: <p>The document has moved <a href="https://cgi.w3.org/member-bin/process.cgi">here</a>.</p>; |
| 08:12 | <SimonSapin> | TabAtkins: do we need to discuss background-repeat round(N+0.5) on the conf call? http://lists.w3.org/Archives/Public/www-style/2013Mar/0760.html |
| 08:13 | <zcorpan> | hmm, seems like grep has changed since https://twitter.com/zcorpan/status/198020760927866880 |
| 08:14 | <zcorpan> | i don't see a flag to do null byte-based search instead of line-based |
| 08:15 | <SimonSapin> | zcorpan: gnu grep vs. bsd grep? |
| 08:15 | <zcorpan> | dunno. got a new mac. |
| 08:16 | <zcorpan> | I'm on Mac OS X 10.8.3 now |
| 08:18 | <zcorpan> | what i want to do is join the files in this data set http://webdevdata.org/ into a single file that also contains the filenames, null-byte separated, similar to http://dotnetdotcom.org/#inde |
| 08:21 | <zcorpan> | man grep says BSD General Commands Manual |
| 08:23 | <webben> | zcorpan: pr |
| 08:24 | <webben> | (that's a command, not PR) |
| 08:25 | <zcorpan> | yeah, reading the man page now :-) |
| 08:34 | <SteveF> | hixie:MikeSmith: in fact it appears much more common to use p or div rather than hx to mark up a subheading, subtitle or tagline https://dl.dropbox.com/u/377471/tests/subhead-class.html |
| 08:35 | <zcorpan> | too many files |
| 08:42 | zcorpan | gives up |
| 08:54 | <jgraham> | zcorpan: You must be able to install the gnu tools in some way e.g. via homebrew or macports or something |
| 08:56 | <zcorpan> | i think i got it working now, with ls -1 and cat |
| 10:35 | <Ms2ger> | darobin, your idl parser upgrade really is a gift that keeps on giving... |
| 10:38 | <darobin> | Ms2ger: context? |
| 10:38 | <darobin> | SteveF: saw the email, still catching up after my break |
| 10:38 | <Ms2ger> | if (member.type == "const") ... assert_equals(window[this.name][member.name], eval(member.value)) |
| 10:38 | <SteveF> | darobin:no problem |
| 10:39 | <darobin> | Ms2ger: that's not my code... |
| 10:39 | <Ms2ger> | Where suddenly, member.value turned into {type:"number", value:25} |
| 10:39 | <darobin> | oh |
| 10:39 | <darobin> | well yeah |
| 10:39 | <darobin> | there were ample warnings that the parser's AST would change |
| 10:39 | <darobin> | that seems like an easy fix :) |
| 10:40 | <darobin> | Ms2ger: it was either that, or stick with a version of WebIDL that simply wasn't relevant anymore |
| 10:41 | <darobin> | or, you know, wait until REC to implement |
| 10:41 | <Ms2ger> | Or, hey, backward compatibility |
| 10:41 | <darobin> | there were too many cases in which it simply wasn't possible |
| 10:41 | <Ms2ger> | So what can this member.value thing actually be? |
| 10:41 | <darobin> | WebIDL is not backwards compatible with previous versions of itself |
| 10:42 | <darobin> | I forget, but unless I made a mistake the changes were motivated rather than gratuitous |
| 10:42 | <Ms2ger> | type can be boolean, number, |
| 10:42 | <Ms2ger> | null, Infinity, NaN? |
| 10:42 | <darobin> | string? |
| 10:43 | <darobin> | as I said, it's possible that I made some mistakes in some cases |
| 10:43 | <Ms2ger> | Apparently not, if I'm looking at the right code |
| 10:43 | <darobin> | but most of the changes were motivated by test cases that I couldn't represent correctly without changing the AST |
| 10:44 | <darobin> | most of idlharness kept on working... |
| 10:44 | <Ms2ger> | So... |
| 10:44 | <darobin> | in any case, let me load up idlharness and make you a fix, since you ask so graciously |
| 10:45 | <Ms2ger> | Why is Infinity not a number? |
| 10:45 | <darobin> | it doesn't JSONify |
| 10:45 | <Ms2ger> | All I want is to get the JS value I need to compare to |
| 10:45 | <Ms2ger> | ... why should it? |
| 10:46 | <darobin> | again, dim memory from 6 months ago, but when I included Infinity it broke code that was expecting the AST to be JSONifiable |
| 10:46 | <darobin> | which didn't strike me as necessarily a wrong expectation, and happened to be something that real people were using |
| 10:47 | <Ms2ger> | Lovely |
| 10:47 | Ms2ger | would have been happy with the string |
| 10:47 | <darobin> | guess you should've been there then |
| 11:01 | <smaug____> | annevk: are there any API proposals using futures? |
| 11:02 | <annevk> | smaug____: not yet I think, was a bit of a chicken and egg problem |
| 11:02 | <smaug____> | k |
| 11:03 | <annevk> | smaug____: I suggested people start using them though, e.g. http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0008.html |
| 11:03 | <annevk> | To make it more compelling I need to define Future.first and Future.when (statics) and write an introduction I suppose |
| 11:03 | <annevk> | And then convert the world, or something |
| 11:06 | smaug____ | will need to decide whether he likes Futures :) |
| 11:07 | <zcorpan> | annevk: an introduction with a sample API would be helpful for understanding how it works. i read the spec and didn't get it. :-) |
| 11:08 | <annevk> | zcorpan: did you get the DOMFuture intro? |
| 11:09 | <mounir> | annevk: http://msdn.microsoft.com/en-gb/library/windows/apps/br211867.aspx |
| 11:09 | <annevk> | ta |
| 11:10 | <zcorpan> | annevk: pointer? |
| 11:10 | <annevk> | zcorpan: https://github.com/slightlyoff/DOMFuture/blob/master/README.md |
| 11:11 | <annevk> | I think in my example I'll show how you could wrap XMLHttpRequest and then get convenient code for when two requests complete or when either completes |
| 11:27 | <darobin> | Ms2ger: so do you have a test case for the problem you're seeing? |
| 11:27 | <Ms2ger> | https://w3c-test.org/webapps/DOMCore/tests/approved/interfaces.html |
| 11:27 | <Ms2ger> | NodeFilter interface: constant SHOW_NOTATION on interface object, say |
| 11:27 | <darobin> | ta |
| 11:32 | <zcorpan> | annevk: that was more understandable |
| 11:32 | <annevk> | zcorpan: cool |
| 11:32 | <zcorpan> | annevk: done() and catch() are just sugar, right? |
| 11:33 | <annevk> | zcorpan: catch() is; done() is useful end-of-chain as the exceptions thrown will actually get to window.onerror |
| 11:35 | annevk | adds a note to the spec for that |
| 11:48 | <zcorpan> | annevk: "done" in the IDL is not a link |
| 11:50 | <zcorpan> | annevk: the algorithms for then and catch have some bogus italics |
| 11:51 | <annevk> | lots of copypasta |
| 11:55 | <annevk> | thanks, fixed now |
| 11:58 | <zcorpan> | annevk: i don't understand how done() is different wrt onerror |
| 11:59 | <annevk> | e.g. then(callbackthatthrow) will invoke reject on the returned future's resolver |
| 11:59 | <annevk> | done(callbackthatthrow) will just throw which is eventually catched by window.onerror |
| 12:01 | <zcorpan> | ah done doesn't have the "future wrapper callback" |
| 12:03 | <zcorpan> | so without done() there would be no way of knowing about exceptions in the callback at the end of the chain |
| 12:12 | <MikeSmith> | hsivonen: when you have time, please take a look at http://bugzilla.validator.nu/show_bug.cgi?id=970 |
| 12:12 | <MikeSmith> | specifically http://bugzilla.validator.nu/show_bug.cgi?id=970#c1 |
| 12:13 | <MikeSmith> | patch to fix the problem that the table-integrity checker hits when being run under Java 7 |
| 12:25 | <zcorpan> | "The funny thing is the specification of thead and tfoot states that it might be useful to repeat the elements on each page. Sadly no browser vendor implemented this yet." http://drublic.de/blog/printing-the-web/ |
| 12:25 | <zcorpan> | i thought firefox did? was it dropped? |
| 12:26 | <Ms2ger> | We did? |
| 12:26 | <zcorpan> | tested now. still works. |
| 12:27 | <zcorpan> | data:text/html,<table><thead><tr><th>foo<tbody><tr><td>bar<tr><td>bar....... |
| 13:40 | <Smylers> | Hi. Where does the HTML spec define that <title> can't contain comments? |
| 13:40 | <Smylers> | (Or, rather, that <!-- blah --> inside <title> is literal text, not a comment.) |
| 13:41 | <annevk> | Smylers: apart from the parser you mean? |
| 13:42 | <Smylers> | annevk: Yes. Where for HTML authors? |
| 13:42 | <Smylers> | I've just encountered somebody trying to put a comment in <title>, and I couldn't find the bit of the spec that says you can't do that. |
| 13:42 | <gsnedders> | Smylers: Currently, 12.1.2 Elements |
| 13:42 | <gsnedders> | Smylers: "RCDATA elements can have text and character references […]" |
| 13:43 | <Smylers> | gsnedders: Thanks. |
| 13:44 | <Smylers> | http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#content-models says “... comment nodes ... must be ignored when establishing whether an element's contents match the element's content model or not, and must be ignored when following algorithms that define document and element semantics.” |
| 13:45 | <Smylers> | Together they suggest that if you did but a comment node in <title> then it would be ignored. |
| 13:45 | <Ms2ger> | There is no comment node involved |
| 13:45 | <gsnedders> | Smylers: No, 12.1.2 says that you cannot have a comment in a valid <title> element. It makes no statement about what you can have otherwise. |
| 13:45 | <Ms2ger> | There is something in your source code that look like a comment, but isn't one |
| 13:46 | <Ms2ger> | looks* |
| 13:46 | <gsnedders> | Smylers: The parser then states that anything that looks like a comment in <title> is just the literal string "<!--" etc. |
| 13:47 | <gsnedders> | Smylers: 3.2.5 merely defines comments to be meaningless, but with the HTML serialization you cannot get a comment in the title element from the parser. |
| 13:47 | <gsnedders> | (You can however get one through <title>foo</title><script>document.querySelector("title").appendChild(document.createComment())</script> or something similar) |
| 13:48 | <gsnedders> | (But scripting is the only way to get one there in the HTML serialization) |
| 13:48 | <Smylers> | Ms2ger, gsnedders: Yeah, I know it isn't a comment node. But I can't see why it isn't, without reading bits of the spec that are supposed to be only for implementers. |
| 13:48 | <Ms2ger> | "RCDATA elements can have text and character references [�]" |
| 13:49 | <gsnedders> | Smylers: Because "RCDATA can have text and character references". Comments are not text or character references. |
| 13:50 | <gsnedders> | "<!-- foo -->" is text. |
| 13:50 | <Smylers> | Sure, I can see that it is text! |
| 13:51 | <gsnedders> | Smylers: Nowhere in the non-parser spec says that it isn't a comment node, merely that you are not allowed comments in RCDATA elements. |
| 13:52 | <gsnedders> | Smylers: tl;dr: It matches the unrestricted definition of text (constrast with the forbidding of < elsewhere in normal elements) and hence the definition of a comment is irrelevant. |
| 13:53 | <gsnedders> | Ms2ger can probably explain better. :P |
| 13:53 | <Ms2ger> | I can? |
| 13:54 | Ms2ger | tries to figure out why two of his tests are suddenly passing, while they weren't yesterday |
| 14:03 | <Smylers> | gsnedders: I can see that 12.1.2 says RCDATA elements can only contain text and character references, and that that doesn't include comments. But 3.2.5 says that if a <title> did contain a comment node, then that comment would be ignored for the purposes of determining whether the contents of the <title> matches its content model. So surely a (theoretical) comment node in a <title> wouldn't contravene 12.1.2, because by 3.2.5 it |
| 14:03 | <Smylers> | The problem is that “<!-- foo -->”, _isn't_ a comment node, but mere text. And I don't see where an author can find that out. |
| 14:03 | <Smylers> | Relatedly, is there a way of navigating from http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-title-element to the RCDATA definition by following plausible-looking links? |
| 14:04 | <gsnedders> | Smylers: The author finds that out by the fact that it is text, as defined. |
| 14:05 | <gsnedders> | Smylers: I think not, because that defines the semantics of the title element in the HTML namespace, as an abstract concept, unrelated to any serialization. Perhaps they should be linked some how. |
| 14:05 | <Smylers> | gsnedders: In practice it turns out the author finds it out by asking me why it isn't working! |
| 14:06 | <gsnedders> | Smylers: The answer is because "<!-- foo -->" is text and hence not a comment. |
| 14:06 | <gsnedders> | Which is all 12.1.2 |
| 14:06 | <gsnedders> | 3.2.5 has no effect on the serialization, just on the parsed tree. |
| 14:07 | <Smylers> | That makes sense to me. |
| 14:08 | <asmodai> | Oh oh, new workplace dubbed me the HTML5 guy, so you guys get to hear more of my insane prattling :P |
| 14:10 | <gsnedders> | asmodai: Oh dear god no ;_; |
| 14:10 | <gsnedders> | asmodai: :P |
| 14:10 | asmodai | grins |
| 14:11 | <darobin> | Ms2ger: patch landed, adds lots of green |
| 14:11 | <darobin> | should sync with the next cron run |
| 14:11 | <Ms2ger> | Thank you |
| 14:12 | <asmodai> | gsnedders: They also tossed JavaScript and JSON my way, not sure how to feel about that though. :P |
| 14:56 | <odinho> | I was dubbed not-HTML5 guy, hence I keep mostly quiet ;D |
| 14:57 | <annevk> | asmodai: what's left? |
| 14:58 | <gavinc> | If one wants to store a fragment of HTML for later use in an HTML page the current recommended practice would still be to use an XML fragment rather then an HTML fragment as the HTML fragment parsing algorithm doesn't do exactly what one might expect. (Adds a root html element and other elements) Is that correct still? |
| 15:04 | <annevk> | gavinc: yeah, although once <template> is integrated you should probably switch to the parsing model of that element |
| 15:05 | <gavinc> | time line for template? |
| 15:05 | <Smylers> | gsnedders: Sorry, got distracted. That makes sense to me ... but I'm still not sure I can explain it to somebody who doesn't know (and doesn't need to know) what the DOM is. |
| 15:05 | <asmodai> | annevk: Hehe, various security protocols and standards :) |
| 15:06 | <annevk> | gavinc: dunno, might be landing in browsers about now? not sure when it'll be integrated into HTML proper |
| 15:06 | <annevk> | gavinc: six months seems like a safish bet |
| 15:06 | <gavinc> | annevk: usual process pain of rec referring to non rec, etc etc :( |
| 15:06 | <Smylers> | http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-title-element says that <title> has a content model of Text, which links to 3.2.5.1. |
| 15:07 | <annevk> | gavinc: that's only a pain if you make it so |
| 15:07 | <annevk> | gavinc: W3C bullshit is very much opt-in |
| 15:08 | <Smylers> | 3.2.5.1 says Text can have Text nodes, which links to the DOM spec's Text interface. |
| 15:11 | <annevk> | Smylers: you should look in section 12 |
| 15:11 | <annevk> | Smylers: which says <title> is RCDATA |
| 15:11 | <annevk> | Smylers: and RCDATA cannot contain anything but text or &...; |
| 15:12 | <annevk> | Smylers: "content model" is a conformance criteria, e.g. if you append a bunch of elements to <title> via the DOM it'll be non-conforming |
| 15:12 | <annevk> | Smylers: "content model" is not a constrain as to what's actually possible when writing HTML or scripting |
| 15:13 | <Smylers> | annevk: OK. |
| 15:13 | <Smylers> | annevk: What kind of thing is RCDATA? |
| 15:14 | <annevk> | Smylers: prolly leftover term from SGML, but feel free to read it as if it said "bananas" |
| 15:14 | <annevk> | Smylers: what matters is how it's defined |
| 15:15 | <annevk> | Now nobody looks at HTML4 anymore we might want to rename those obscure terms to something more useful... If you feel like that'd be good Smylers, maybe file a bug to suggest that. |
| 15:18 | <Smylers> | annevk: Thank you — that answers the next question I was about to ask! |
| 15:19 | <Smylers> | annevk: But what I actually meant was: what is the term for the category of item that RCDATA is an instance of? |
| 15:19 | <Smylers> | annevk: As in “The X of the <title> element is RCDATA.” What is X? |
| 15:20 | <Ms2ger> | "category"? :) |
| 15:20 | <annevk> | Smylers: There's elements. <title> is a RCDATA element. |
| 15:20 | <annevk> | Smylers: An element being of a particular category places restrictions on how you can write it. |
| 15:21 | <annevk> | http://www.whatwg.org/C#elements-0 |
| 15:21 | <Smylers> | Ah, “kind” appears to be the term. |
| 15:22 | <Smylers> | Thanks, all. |
| 15:22 | <annevk> | "kind" is most definitely not a term. That's just language. It might as well have said "type" there. |
| 15:23 | <annevk> | Or "categories". |
| 17:46 | <zcorpan> | what's the state of art for doing retina/adaptive/responsive/etc images these days? |
| 17:49 | <Ms2ger> | <picture srcset> |
| 17:49 | <TabAtkins> | Hehe. |
| 17:49 | <annevk> | TabAtkins: fwiw, futures are discussed in that repo and on www-dom and Bugzilla... now public-webapps too teehee |
| 17:49 | <annevk> | ooh and various JavaScript places I guess, like the ES wiki |
| 17:51 | <TabAtkins> | WHATEVER |
| 17:51 | <TabAtkins> | Maybe you people should, you know, actually post that info somewhere in the gh repo. |
| 17:52 | <TabAtkins> | I should probably join www-dom. |
| 17:52 | <zcorpan> | i mean what's best for authors to use today, not what a browser should implement |
| 17:53 | <Ms2ger> | <img> |
| 18:07 | <annevk> | TabAtkins: dom.spec.whatwg.org is pretty clear about it I think, dunno about GH, that's outside my jurisdiction |
| 18:07 | <annevk> | TabAtkins: but yeah, WHATEVER works, I'll read it either way :) |
| 18:08 | <TabAtkins> | annevk: Since I was specifically talking about a strawman that I don't think is in DOM yet, I wasn't looking there. ^_^ |
| 18:09 | <annevk> | I think ProgressFuture as is makes sense though, no need to put a bunch of events in there too |
| 18:10 | <annevk> | I guess I'd make progress() accept a ProgressEvent |
| 18:10 | <TabAtkins> | Not a bunch of events. No API-level stuff needs to change at all. |
| 18:10 | <TabAtkins> | Yeah, do that, and make it an event target so addEventListener('progress', ...) works on it. |
| 18:10 | <annevk> | eww |
| 18:10 | <TabAtkins> | Not that that's particular useful, but existing infrastructure that cares about events may use it. |
| 18:10 | <TabAtkins> | No reason to completely reinvent events. |
| 18:11 | <annevk> | what part is being made less complex by adding that? |
| 18:12 | <TabAtkins> | annevk: The part where you're breaking compat with existing things in a specialized, custom way. |
| 18:13 | <TabAtkins> | Which, given that Future is all about trying to make some cases less specialized and custom... |
| 18:14 | <TabAtkins> | Like I said, though, keep the existing convenience APIs. They're great. Just *also* make it actually use events like the rest of the platform does, rather than reinventing them in a custom way. |
| 18:14 | <TabAtkins> | We're not trying to replace events with futures, after all, just replace *bad uses of events* with them. |
| 18:15 | <TabAtkins> | annevk: Btw, should I resend my thread to www-dom? |
| 18:15 | <annevk> | If something does not need to be an EventTarget but needs to report progress going forward, I think just having ProgressFuture would be better (or something like that) |
| 18:15 | <annevk> | That doesn't mean we're suddenly replacing events... |
| 18:15 | <TabAtkins> | Right. What I'm saying is that the progress part of ProgressFuture *is an event*, in every meaningful sense. |
| 18:16 | <annevk> | TabAtkins: nah it's fine I think |
| 18:16 | <TabAtkins> | Except, currently, the technical sense. |
| 18:16 | <TabAtkins> | It should just be a Future that reports progress events as well. |
| 18:17 | <TabAtkins> | I agree that ProgressFuture is better in general for progress-event-related things, because it lets you listen for completion in the better Future manner. |
| 18:17 | <annevk> | I still don't see why. Sure it's a callback that's invoked multiple times. Does not necessarily make it an event... |
| 18:18 | <TabAtkins> | annevk: It's a callback that's invoked multiple times, and which can have multiple distinct callbacks attached to it. |
| 18:18 | <TabAtkins> | That's an event in everything but name. |
| 18:19 | <annevk> | I'm not really sure if the latter is established. But we have other systems such as MediaQueryList (or whatever it was) that reinvent parts of events |
| 18:19 | <annevk> | If it makes sense to have something like events, but not quite, it doesn't immediately follow to copy all of the event infrastructure to it |
| 18:22 | <TabAtkins> | In the current strawman, future.progress just returns the future again, so you can keep registering them. |
| 18:22 | <TabAtkins> | It doesn't make sense to limit it to only a single listener. |
| 18:23 | <annevk> | So I take it you're looking at the font loading API and want to use this pattern? |
| 18:24 | <TabAtkins> | Yup, writing up a post to www-style about it now. |
| 18:24 | <annevk> | Because we haven't really decided and I think the JS community hasn't either, how best to do progress notifications. |
| 18:24 | <annevk> | Can you do without them for now? |
| 18:24 | <TabAtkins> | Been talking with slightlylate about it, but he's got enough misconceptions about how css fonts work that it wasn't that useful. |
| 18:26 | <TabAtkins> | Yes, I can do without them. I'm only using them right now for the loading of individual fonts, where it's actually tri-state (unloaded, loading, loaded). |
| 18:26 | <annevk> | I think it would be better to just propose the accept/reject pattern for now. We can always upgrade later. |
| 18:26 | <annevk> | If you remember maybe cc me on that email |
| 18:28 | <TabAtkins> | Fine with me. |
| 18:48 | <annevk> | So yeah, the other great thing about it not being events is that you can garbage collect the hell out of it. |
| 18:48 | <annevk> | You're not hostile to someone creating a synthetic event out of spite at some point and relying on that to work. |
| 18:49 | <annevk> | So you don't need removeListener and things like that. It simplifies so much. |
| 19:23 | <TabAtkins> | annevk: Oh, hm. That's interesting. |
| 19:23 | <TabAtkins> | annevk: Oh, though, wait. I assume that ProgressFuture will be specced to kill all listeners when the future resolves. |
| 19:23 | <TabAtkins> | And not fire any more progress events. |
| 19:24 | <annevk> | That's alien towards events. |
| 19:24 | <TabAtkins> | Really? Normal objects have a lifetime when they stop firing progress events. |
| 19:25 | <TabAtkins> | You coudl technically fire synthethic events after that point, but I suspect that's mostly just because nobody bothered to stop it. |
| 19:26 | <annevk> | Events listeners are never automatically cleared. |
| 19:26 | <annevk> | Typically also such objects can be reused for other loads, so it doesn't necessarily make sense to clear them. |
| 19:28 | <TabAtkins> | True, but that's not the case for a Future. |
| 19:28 | <TabAtkins> | Shrug. |
| 19:29 | <annevk> | Yeah. The other big question is here is what the use case would be. Why would you register for events? |
| 19:34 | <TabAtkins> | Because that's what you're doing when you call future.progress(cb)? |
| 19:34 | <TabAtkins> | The progress notifications are functionally events. |
| 19:39 | <TabAtkins> | annevk: Anyway, sicking is saying the same thing as you, so I'm acquiescing on the thread. |
| 19:40 | <jamesr> | embrace the future(s) |
| 19:42 | <sicking> | TabAtkins: Events aren't actully author friendly. That's not the reason we've been using them. The main reason we've been using them is inertia |
| 19:43 | <TabAtkins> | sicking: Okay, so the idea is that Events should continue to be used for Node stuff, and the rare thing with similar constraints. Otherwise, use Futures if they fit, or just use a callback registration mechanism if they don't. |
| 19:44 | <TabAtkins> | I just want a name for the "lightweight events" that ProgressFuture uses, so that when other things want the same kind of event-like behavior, there's an easy thing to copy from rather than them inventing something vaguely incompatible. |
| 19:46 | <sicking> | TabAtkins: approximately yes. IMO. There are no clear cut rules though |
| 19:46 | <TabAtkins> | ;_; |
| 19:46 | TabAtkins | wants clear-cut rules. |
| 19:46 | <TabAtkins> | When possible, at least. |
| 19:46 | Ms2ger | cuts off TabAtkins's nose |
| 19:46 | <sicking> | "lightweight events" == callbacks |
| 19:47 | <TabAtkins> | sicking: But that's not enough! ProgressFuture has a *specific* API structure that mimics events in a lightweight way. Other ways of doing callbacks have various other shapes, with upsides and downsides. |
| 19:47 | <TabAtkins> | For example, just passing the callbacks into the future constructor is one way that's fairly common, but which prevents multiple callbacks from being registered. |
| 20:33 | <annevk> | TabAtkins: API design has changed a lot over time, we're not there yet and I somewhat doubt we'll get there soon |
| 20:33 | <TabAtkins> | annevk: Sure. |
| 20:42 | <jamesr_> | TabAtkins: i really want to go hate on your www-style thread names |
| 20:42 | <TabAtkins> | jamesr_: ??? |
| 20:44 | <annevk> | I have to say the [subject] stuff makes things barely readable |
| 20:45 | <annevk> | Especially combined with Re: [subject] stuff |
| 20:48 | <jamesr_> | Re: [subject] Re: Blah blah blah |
| 20:48 | <TabAtkins> | The [subject] stuff is necessary on a list with such a wide range of topics. |
| 20:49 | <TabAtkins> | It's used on webapps too, frex. |
| 20:49 | <TabAtkins> | The Re: stuff is just people with busted clients. |
| 20:50 | <annevk> | I stopped using it on webapps fwiw. I typically use DOM: x or File API: x |
| 20:52 | <tantek> | I like [#tag] myself ;) |
| 20:53 | <annevk> | I thought you didn't like support forums? |
| 20:53 | <hober> | hahahaa |
| 20:58 | <TabAtkins> | annevk: That's functionally equivalent. ^_^ |
| 20:59 | <annevk> | TabAtkins: you may note I did not mention function, but readability |
| 20:59 | <annevk> | "[css-cascade] it a sucks" vs "Cascade: it a sucks" |
| 21:01 | <TabAtkins> | Must be personal choice - I find the former more readable. |
| 21:01 | <TabAtkins> | it also functions as a good search term. |
| 21:02 | <annevk> | sounds like you're conditioned :) |
| 21:03 | <TabAtkins> | Hah. |
| 21:05 | <annevk> | Congrats Google guys with Blink |
| 21:05 | <annevk> | That's awesome |
| 21:06 | <fishd_> | :-) |
| 21:07 | <TabAtkins> | ^_^ |
| 21:07 | <annevk> | I wonder how long this has been in the works, since you all kept perfectly quiet each time I brought it up :-) |
| 21:09 | <SimonSapin> | annevk: what’s Blink? |
| 21:10 | <annevk> | http://www.chromium.org/blink |
| 21:10 | <JakeA> | annevk: You may be the one I was on about in the first paragraph https://plus.google.com/u/0/116237864387312784020/posts/d62jMDKXcLb |
| 21:11 | <annevk> | SimonSapin: it's WebKit forked with goals more in line with Gecko (e.g. removing legacy cruft and such) |
| 21:11 | <annevk> | JakeA: yeah, beverloo just reminded me :-) |
| 21:14 | <SimonSapin> | wow. |
| 21:16 | <SimonSapin> | When Opera says they use Chromium, does that mean the chromium port of WebKit, or will they also follow Blink? Or is that not decided yet? |
| 21:16 | <beverloo`> | SimonSapin, Bruce commented on that here: http://www.brucelawson.co.uk/2013/hello-blink/ |
| 21:17 | <TabAtkins> | To the best of my knowledge, they'll be following Chromium, which contains Blink. |
| 21:17 | <TabAtkins> | We will be encouraging people to fork Chromium at the content layer, not the Blink layer. |
| 21:17 | <TabAtkins> | They're already basically there, so it's not too bad for them. |
| 21:17 | <SimonSapin> | How did I miss that? Oh right, I haven’t looked at Twitter in 4 hours. |
| 21:18 | <TabAtkins> | We only announced it ~20 minutes ago. |
| 21:18 | <SimonSapin> | eh |
| 21:18 | <SimonSapin> | TabAtkins: content layer, what does that mean? |
| 21:18 | <TabAtkins> | I dunno, it's some term of art that people who actually care about things outside of WebKit say. |
| 21:19 | <SimonSapin> | "delete more than 7,000 …" that’s about the number of lines of code in WeasyPrint "… files—comprising more than 4.5 million lines." Oh. |
| 21:20 | <fishd_> | "content layer" --> src/content/public/ from the chromium repository |
| 21:20 | <SimonSapin> | TabAtkins: I suppose this was already going on when I visited in February? |
| 21:22 | <SimonSapin> | Removing prefixes after features land unprefixed: \o/ |
| 21:24 | <SimonSapin> | So basically WebKit becomes (again?) basically an Apple project? |
| 21:25 | <rillian> | I'm sure Apple will be welcome to migrate :) |
| 21:31 | <jamesr_> | SimonSapin: no -blink- ! |
| 21:31 | <smaug____> | at least we can get pointer events to chrome ! |
| 21:31 | <smaug____> | and apple can stay with touch events |
| 21:40 | <SimonSapin> | anyways, interesting times |
| 22:02 | <Hixie_> | "an operation that is ongoing, has yet to start, or has completed" |
| 22:02 | <Hixie_> | because "an operation" would be too brief? :-P |
| 22:03 | <TabAtkins> | It's calling out all the cases specifically because events only handle one of those (or two, if you count multiple events as handling an "ongoing" operation). |
| 22:03 | <astearns> | perhaps it omits operations that are taking a nap |
| 22:04 | <Hixie_> | TabAtkins: yeah, i would have written it the same way, i'm just teasing :-P |
| 22:04 | <Hixie_> | is there a tutorial for futures? |
| 22:04 | <Hixie_> | it's not entirely clear from the spec how it's envisaged to be used by APIs |
| 22:04 | <TabAtkins> | Closest is https://github.com/slightlyoff/DOMFuture |
| 22:05 | <TabAtkins> | But I'm trying to write up some API-design guidance for futures vs events vs lightweight events vs whatever. |
| 22:05 | <TabAtkins> | And I'll throw some pull requests at DOM to add fluff explanatory text. |
| 22:09 | <Hixie_> | thanks, the examples at the bottom of that page are helpful |