| 00:02 | <Hixie> | annevk: it doesn't allow what opera is doing |
| 00:03 | <Hixie> | annevk: there's no form field with multiple files |
| 00:03 | <Hixie> | annevk: each file goes into its own field in the form data set |
| 00:03 | <annevk> | oh okay, so I should have read the spec more clearly |
| 00:04 | <annevk> | reading that now, my bad |
| 00:04 | <Hixie> | no worries :-) |
| 00:05 | <Hixie> | AryehGregor: is there an api to easily replace the current text selection with some other text? |
| 00:05 | <annevk> | doesn't a bunch of execCommand() work that way |
| 00:08 | <annevk> | updated http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events per regen of Ms2ger |
| 00:08 | <annevk> | not on IRC, yet still working; you can't explain that! |
| 00:11 | <zewt> | blame that on the moon, too |
| 00:11 | <annevk> | Peter`, it's "ECMAScript" |
| 01:02 | <red_one> | So where do I go to rant about I and B in HTML5? |
| 01:02 | red_one | chuckles |
| 01:02 | <annevk> | #css |
| 01:03 | <Hixie> | what is your rant? |
| 01:03 | <Hixie> | pro or con? :-) |
| 01:03 | <red_one> | That would be like complaining about COBOL to a graphics designer! |
| 01:03 | <red_one> | you really want to know? :P |
| 01:03 | <zewt> | how many times have you seen people rant about a pro? :P |
| 01:04 | <Hixie> | red_one: yes, because if you're con, you can help me fight the incursion of <u> and <tt>, but if you're pro, i don't want to mention that we might also be adding <u> and <tt> :-) |
| 01:05 | <red_one> | I think I and B are copouts to pander to the "I wish I was using netscape navigator" crowd. |
| 01:05 | <red_one> | They're completely unsemantic. |
| 01:05 | <annevk> | ah, debating tactics 101; reveal everything upfront |
| 01:05 | <Hixie> | red_one: well to be fair in the html spec now they've been redefined as mostly semantic |
| 01:06 | <red_one> | Hixie: indeed. |
| 01:06 | <Hixie> | red_one: however, if you're interested, i'm serious about looking for help in fighting back against <u> |
| 01:06 | <Hixie> | red_one: since the html chairs are taking that one out of my hands and making their own decision on it in a few months, based on the arguments we present |
| 01:07 | <Hixie> | red_one: so far the proposal in favour of adding it is http://www.w3.org/html/wg/wiki/ChangeProposals/UShouldBeConforming |
| 01:07 | <zewt> | can we fight back against <span> and just use <div style="display: inline">? heh :P |
| 01:07 | <zewt> | (actually, I think I saw some Google apps that sort of do that when I was poking around in their DOM, though I don't recall where) |
| 01:07 | <Hixie> | red_one: if you have any arguments against that, put them in the wiki here: http://wiki.whatwg.org/index.php?title=Objections_against_CPs_for_ISSUE-144&action=edit&redlink=1 |
| 01:08 | <Hixie> | red_one: and i'll round up the objections and present them formally when it's time |
| 01:08 | <red_one> | Thanks. |
| 01:10 | <Hixie> | (also please add any arguments you have have against <u> in general, even if they're not explicitly countered in that first page) |
| 01:10 | <Hixie> | (and anyone else who wants to partake in this, be my guest) |
| 01:11 | <red_one> | I have arguments against I, B and U, but I'll stick with U I guess. |
| 01:11 | <red_one> | They're all pretty much the same anyway. |
| 01:13 | <Hixie> | B and I are more or less lost causes, because they actually do have somewhat valid use cases -- there's no other sensible way to mark many up the examples in the I section, especially |
| 01:13 | <Hixie> | but U seems to be much weaker |
| 01:14 | <red_one> | IMO, the introduction section of that wiki pages |
| 01:14 | <red_one> | is exactly the reason why U shouldn't exist, and neither should I or B. |
| 01:15 | <uf0> | red_one, say I want to quickly underline a text |
| 01:16 | <uf0> | I simply add a <u>hello</u> |
| 01:16 | <uf0> | explain to me why that's useless? |
| 01:16 | <red_one> | it's not useless |
| 01:16 | <uf0> | ok so what's the problem with it |
| 01:16 | <zewt> | or <span style>hello</span> or <span class> |
| 01:16 | <red_one> | but it's style |
| 01:16 | <red_one> | not content. |
| 01:16 | <uf0> | ok so? |
| 01:17 | <red_one> | so not <U> |
| 01:17 | <zewt> | if you want to quickly set a block of text red, should there be <red>, too? |
| 01:17 | <red_one> | but something more meaningful that hopefully either the UA underlines or your CSS underlines. |
| 01:17 | <uf0> | zewt no one said that. |
| 01:18 | <uf0> | but basic underline, bold |
| 01:18 | <uf0> | I think are good, shouldn't be a 'bad' thing |
| 01:18 | <red_one> | The idea of "everyone uses it so it should be in HTML5" |
| 01:18 | <red_one> | is clearly why EMBED is there. |
| 01:18 | <erlehmann> | hey, I actually use i for stylistic offsetting of names! |
| 01:18 | <red_one> | argh. |
| 01:18 | <zewt> | lots of CSS styles are "basic"; seems strange to pick a few of them and give them their own element types |
| 01:19 | <erlehmann> | red_one, the WHATWG works mainly descriptive, not prescriptive. (this is also the reason that theora is not the baseline video codec. apple wouldn't just magically implement it) |
| 01:19 | <erlehmann> | zewt, those elements were there before. should they be delegated to presentational hints? |
| 01:19 | <uf0> | I think it's alot messier to have say ex: <span class="foo">foo</span> |
| 01:20 | <uf0> | and that foo has rule of underline |
| 01:20 | <uf0> | just for an underline |
| 01:20 | <uf0> | or even inline style for that matter |
| 01:20 | <uf0> | and remember i'm arguing U, B |
| 01:20 | <uf0> | that's it. |
| 01:20 | <zewt> | erlehmann: there's a case for speccing something simply because it's historical and engrained in user's brains; that just wasn't the particular argument here |
| 01:21 | <erlehmann> | zewt, u and b are rooted in western typographic conventions in wide use in the web. u is less so. |
| 01:21 | <red_one> | if we're going to be using U, B and I, we might as well stick with HTML 3.2. |
| 01:21 | <uf0> | another not good point |
| 01:22 | <zewt> | erlehmann: common typographic conventions don't need to have their own element names; that's what CSS is for |
| 01:22 | <uf0> | something like the <center> obviously doesn't make sense to me |
| 01:22 | <uf0> | but a <u> that makes sense |
| 01:22 | <kevogod> | Why doesn't that obvoiusly make sense? |
| 01:22 | <uf0> | and say a regular user wants to comment |
| 01:22 | <kevogod> | If you think <u> makes sense, then why doesn't <center>? |
| 01:22 | <zewt> | as for things that are simply in common practice and, for practical reasons, are simply not going away--not arguing against that |
| 01:22 | <kevogod> | Where does it stop? |
| 01:22 | <uf0> | and underline something in his comment |
| 01:23 | <uf0> | he can use <u> |
| 01:23 | <uf0> | because he is not CSS expert |
| 01:23 | <kevogod> | What regular user? |
| 01:23 | <uf0> | kevogod, here's an example |
| 01:24 | <zewt> | so html should have element types for common css styles so people don't have to learn css? sorry, don't buy that at all |
| 01:24 | <Hixie> | uf0: should we add <big>, <tt>, and <font color>? |
| 01:24 | <uf0> | someone in a blog that wants to underline something in his comment |
| 01:24 | <uf0> | what does he/she do |
| 01:24 | <zewt> | Hixie: i already offered <red> :P |
| 01:24 | <kevogod> | Hixie, I am always in favor of <big>. |
| 01:24 | <uf0> | and the simplest way |
| 01:24 | red_one | lols it up |
| 01:24 | <kevogod> | <small> does not make sense to me though. |
| 01:24 | <red_one> | kevogod: teh <bigger> the better, eh? |
| 01:25 | <zewt> | <xyzzy> (nothing happens) |
| 01:25 | <uf0> | Hixie no we shouldn't add those |
| 01:25 | <uf0> | but again basic.. bold, underlines, italic |
| 01:25 | <kevogod> | uf0, Use BB Code? |
| 01:25 | <uf0> | i'm for |
| 01:25 | <Hixie> | uf0: what's the difference? |
| 01:26 | <erlehmann> | oh my god, bbcode |
| 01:26 | <kevogod> | Haha |
| 01:26 | <erlehmann> | bbcode is the reason i hate people |
| 01:26 | <erlehmann> | “LOOK ITS JUST LIKE HTML EXCEPT WE CANNOT PARSE IT” |
| 01:26 | <kevogod> | [b]Why?![/b] |
| 01:26 | <uf0> | kevogod, lol no i do not use bbcode |
| 01:26 | <erlehmann> | if they would just use html. with html5lib. all would be well. |
| 01:27 | <erlehmann> | ._. |
| 01:27 | <uf0> | I have still haven't gotten any good response to a simpler alternative |
| 01:27 | <kevogod> | CSS? |
| 01:27 | <uf0> | it's either add a class |
| 01:27 | <uf0> | or inline style it |
| 01:28 | <red_one> | CSS should be the only option for style. |
| 01:28 | <red_one> | It's what it does. |
| 01:28 | <zewt> | you havn't replied to why <b> deserves its own element but <big> or <red> do not; why leak CSS styles into HTML at all? |
| 01:28 | <zewt> | because it's a little less typing? that's certainly never been a major HTML design criteria, heh |
| 01:28 | <kevogod> | I prefer <fuchsia>. |
| 01:28 | <uf0> | in fonts the most used stylings are bold or underline |
| 01:28 | <uf0> | that's why |
| 01:28 | <zewt> | so? |
| 01:29 | <uf0> | <big> or <red> that's diff |
| 01:29 | <uf0> | zewt |
| 01:29 | <kevogod> | So people don't use bigger fonts? |
| 01:29 | <red_one> | so we'll take a survey |
| 01:29 | <kevogod> | Q.E.D. |
| 01:29 | <red_one> | and implement the 10 most used styles |
| 01:29 | <red_one> | as HTML elements. |
| 01:30 | <red_one> | <bigredflashingtitlebar> |
| 01:30 | <uf0> | red_one you are being sacarstic, I'm having a serious conversation about what I think make sense |
| 01:31 | <uf0> | it's obviously gone in HTML5 |
| 01:31 | <zewt> | well, you're not giving any new arguments; we keep asking "why does it being more common mean it needs to be an element?", and you keep replying "because it's more common" |
| 01:31 | <red_one> | uf0: i'm trying to make a point. |
| 01:31 | <Hixie> | uf0: could you give an example of when you would want to underline some random text that has no more appropriate semantic? |
| 01:32 | <uf0> | ok.. there are times when I'm writing HTML |
| 01:32 | <uf0> | and a client wants a particular word underlined |
| 01:32 | <uf0> | in my old ways |
| 01:33 | <uf0> | This is a <u>Title</u> |
| 01:33 | <uf0> | or |
| 01:33 | <red_one> | underlined why? |
| 01:33 | <uf0> | <h1>bla bla <u>bla</u |
| 01:33 | <red_one> | what is it about the word that makes it special? |
| 01:33 | <uf0> | > </h1> |
| 01:34 | <uf0> | now the way you guys want it is.. |
| 01:34 | <uf0> | <h1>bla bla <span style="font-style: underline;">bla</span></h1> |
| 01:34 | <erlehmann> | ‘i am serious uf0. this is serious conversation.’ |
| 01:34 | <uf0> | you see the difference in simplicity? |
| 01:34 | <erlehmann> | lolcats rejoice |
| 01:35 | <erlehmann> | uf0, just use <mark> or <b> ? |
| 01:35 | <zewt> | yes, the second is much simpler since it doesn't have a single-purpose special-case element |
| 01:35 | <uf0> | Hixie your response? |
| 01:36 | <red_one> | uf0: can you answer my question? |
| 01:37 | <uf0> | underlined why? |
| 01:37 | <uf0> | the client wants the 'foo' word underlined |
| 01:38 | <uf0> | text-decoration: underline; |
| 01:38 | <uf0> | there's your answer |
| 01:38 | <red_one> | what is it about that word that makes them want to underline it? |
| 01:39 | <uf0> | ok now you're effin' wit me |
| 01:39 | <red_one> | no, it's a serious question. |
| 01:40 | <uf0> | the answer is 'I don't know' |
| 01:40 | <red_one> | the answer will determine how you should mark it up. |
| 01:40 | <red_one> | well |
| 01:40 | <red_one> | for argument's sake |
| 01:40 | <uf0> | I mean for argument's sake |
| 01:40 | <red_one> | if they say "because it's important" |
| 01:40 | <red_one> | guess what i'd recommend? |
| 01:40 | <uf0> | shoot |
| 01:41 | <uf0> | a class? |
| 01:41 | <uf0> | i'd bet |
| 01:41 | <red_one> | EM |
| 01:41 | <red_one> | styled to be underlined |
| 01:41 | <red_one> | because it's.. emphasised. |
| 01:41 | <red_one> | (this really isn't a WHATWG question, more of a #web question) |
| 01:42 | <Hixie> | uf0: what does your client want to have happen when the page is being read by an aural browser? |
| 01:42 | <uf0> | well then in you're css you add the css rule to underline |
| 01:43 | <wilhelm> | According to the numbers from Brian Wilson's analysis of the Web (2008), <tt> is used on 0.44% of the pages out there. In comparison, <layer> is used on 0.75% and @longdesc on 0.72%. Should be safe to drop. :P |
| 01:44 | <Hixie> | wilhelm: other than it being used more, i don't understand why <u> has more of a valid use case than <tt> |
| 01:44 | <uf0> | Hixie not sure where you're going with that, what does blind folk have to do? |
| 01:45 | <Hixie> | uf0: i'm trying to work out why you want something underlined |
| 01:45 | <uf0> | see red_one's example |
| 01:45 | <uf0> | they say that word is important |
| 01:45 | <uf0> | is his case he would us <em></em> |
| 01:45 | <Hixie> | uf0: to work out if <u> is a good idea or if you're just using it because it's easier to think about than the right solution (the same way people use <big> when they should use <h1>) |
| 01:45 | <uf0> | which makes sense |
| 01:45 | <uf0> | but then again |
| 01:45 | <wilhelm> | Hixie: I agree. I'm surprised to see <u> at 9.7%, though, on par with <em> (10%). |
| 01:45 | <uf0> | you'd still have to add the underline rule |
| 01:46 | <Hixie> | if the word is important, then you use <strong>, not <em>, but yes -- you use <strong>, then style it |
| 01:46 | <Hixie> | so that when the client says "wait, i want important stuff to be red, not underlined!" then you only change one place |
| 01:46 | <uf0> | oh Hixie.. don't confuse with people that think use <big> instead <h1> |
| 01:46 | <Hixie> | and their entire 10,000 page site updates all at once |
| 01:46 | <uf0> | that's a diff story |
| 01:47 | <Hixie> | <u> instead of <strong> is the _exact_ same story as <big> instead of <h1> |
| 01:47 | <Hixie> | that's the problem! |
| 01:47 | <Hixie> | that's why we shouldn't allow people to use <u> |
| 01:47 | <Hixie> | so that they don't think they're different |
| 01:47 | <uf0> | hmmmmm.. |
| 01:48 | <uf0> | you may have a point there. |
| 01:49 | <red_one> | hixie earns his cookie for today. |
| 01:53 | <uf0> | case closed. |
| 01:53 | <erlehmann> | Hixie, using <big> when one should use <h1> is not the worst. sadly, i know a guy who manages to get paid for putting photoshop renderings as web site backgrounds. |
| 01:53 | <erlehmann> | my face when i saw it ._. |
| 01:54 | <Hixie> | uf0: hopefully i'll be able to convince the htmlwg chairs as well :-) |
| 01:54 | <uf0> | erlehmann using <big> doesn't make sense in that case because of SEO as well |
| 01:54 | <uf0> | so that's why i though otherwise in that case |
| 01:54 | <uf0> | but valid point either way. |
| 01:55 | <erlehmann> | SEO, haha |
| 01:55 | <erlehmann> | curlers gonna curl. |
| 01:55 | <uf0> | it's the truth erlehmann. |
| 01:55 | <uf0> | i mean the point of web is search nowadays = google |
| 01:56 | <uf0> | but that's another conversation :) |
| 01:56 | <uf0> | h tagss |
| 01:56 | <erlehmann> | i know. but i care more about fleshy users than about search agents. |
| 01:56 | <uf0> | right |
| 01:56 | <Hixie> | in practice they need the same thing -- use appropriate elements :-) |
| 01:57 | <erlehmann> | indeed. |
| 01:57 | <uf0> | Hixie, I thought it was a done deal in HTML5 for u,i |
| 01:57 | <red_one> | google gives preference to text in H1 I think. |
| 01:57 | <uf0> | am i wrong here? |
| 01:57 | <red_one> | for example. |
| 01:57 | <uf0> | they're gone aren't they |
| 01:57 | <uf0> | well 'deprecated' |
| 01:58 | <uf0> | google is h1,h2 |
| 01:58 | <uf0> | everything else is extra |
| 01:58 | <uf0> | in my experience at least |
| 01:59 | <erlehmann> | still people sometimes get so mad when they think they got it and didn't. a friend of mine was once “but <br> works, why should i use <p>” because she didn't get the semantics. in this case it may have actually helped to remind her that the next person to maintain her stylesheets may very well be a murderous psychopath and know where she lives. :D |
| 01:59 | <erlehmann> | googlers gonna goog |
| 02:00 | <Hixie> | uf0: http://www.whatwg.org/specs/web-apps/current-work/complete/text-level-semantics.html#the-i-element |
| 02:00 | <Hixie> | uf0: right not the spec has <i> and <b> but doesn't have <u> or <tt>. There is a proposal on the table to add <u>. |
| 02:01 | <Hixie> | right now, even |
| 02:02 | <uf0> | interesting |
| 02:03 | <kennyluck> | As the main author of http://www.w3.org/html/wg/wiki/ChangeProposals/UShouldBeConforming, I thought about writing a proposal to drop b i, to make it consistent. I didn't do that because I have no idea about the rationale of having b and i. |
| 02:03 | <kennyluck> | They are all the same to normal people. |
| 02:04 | <red_one> | kennyluck: agreed. |
| 02:05 | <Hixie> | kennyluck: the spec gives the rationales for i and b |
| 02:06 | <kennyluck> | Hixie: it's too messy and not compatible with existing content. |
| 02:06 | <kennyluck> | when you say b and i have use cases. But before HTML4, no body thought of these elements in terms of semantic elements. |
| 02:06 | <kennyluck> | Then why do it now? |
| 02:06 | <kennyluck> | s/Then/So/ |
| 02:08 | <kennyluck> | The current spec claims that some people who accidentally use it in some way are right. I think this is quite weird. |
| 02:10 | <MikeSmith> | change proposal scope creep |
| 02:10 | <MikeSmith> | kennyluck: the issue is about the u element |
| 02:11 | <nessy> | I have a quick question about how to use the CSS selectors for WebVTT / caption files, which I am unclear about even after reading the spec |
| 02:11 | <nessy> | is it: video track ::cue(c).white {} or video track ::cue(c.white) {} ? |
| 02:11 | <nessy> | if "white" is the class name for the class object |
| 02:12 | <nessy> | and when I use voice, is this correct? video track ::cue(v[voice='Sintel']) {..} |
| 02:13 | <zewt> | i couldn't quite tell from reading the spec; i didn't look too hard but it looked like webvtt classes would simply become CSS classes |
| 02:13 | <zewt> | (didn't look too hard since that seemed to make perfect sense so I didn't think much more about it, I guess) |
| 02:13 | <Hixie> | kennyluck: html4's semantics really weren't thought through very well |
| 02:13 | <Hixie> | kennyluck: i mean, the spec is really vague |
| 02:13 | <nessy> | http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#css-extensions <- is unclear to me |
| 02:14 | <Hixie> | kennyluck: when you enumerate common use cases for html pages, you end up with a lot of things for which i and b make sense, but i've never seen one for which u makes sense |
| 02:14 | <zewt> | it's useful for tricking your users into thinking something's a link... |
| 02:14 | <nessy> | zewt: I think so, too, so I thought the first one is correct |
| 02:14 | <Hixie> | nessy: the entire selector goes inside the argument |
| 02:14 | <erlehmann> | haha, that reminds me of „back when X was good“ — „X was never good“ |
| 02:14 | <Hixie> | nessy: ::cue(c.white) |
| 02:14 | <erlehmann> | <u> was never good. |
| 02:14 | <nessy> | ah thanks! |
| 02:14 | <erlehmann> | selectors gonna select! |
| 02:15 | <Hixie> | kennyluck: if there really is a use case for <u>, then we should add it |
| 02:15 | <Hixie> | kennyluck: but what are the use cases? the naming thing for cjk isn't actually used as far as i understand |
| 02:18 | <kennyluck> | Hixie: It is used. Although honestly not very prevalent. But I don't believe in the use cases of b and i as well. Or they are just very confusing. |
| 02:19 | <Hixie> | kennyluck: what is it used for? |
| 02:19 | <Hixie> | kennyluck: certainly it is used, but then so is <big>, and <font> |
| 02:19 | <Hixie> | kennyluck: and <frameset> |
| 02:19 | <Hixie> | kennyluck: and <marquee> |
| 02:19 | <Hixie> | kennyluck: "being used" is an argument for the browser supporting it, not for it being conforming |
| 02:21 | <kennyluck> | Hixie: If someone writes a proposal on dropping b and i, I will personally go for it. I wrote this proposal because some people want it even if they don't have clear use cases. |
| 02:21 | <kennyluck> | What I care is just this inconsistency between u b and i. |
| 02:22 | <kennyluck> | I don't believe in the use cases of b and i. And that's it. |
| 02:24 | <Hixie> | kennyluck: how do you mark up a taxonomic designation without i? |
| 02:24 | <kennyluck> | <span> |
| 02:25 | <Hixie> | so you do believe in the use case, you just don't think we should handle it? |
| 02:25 | <Hixie> | i don't understand why <span> is better than <i> |
| 02:26 | <kennyluck> | Hixie: because we could have deprecated b and i, as a significant portion of Web authors belive. |
| 02:26 | <kennyluck> | (the rant from red_one) |
| 02:27 | <Hixie> | deprecating elements isn't a goal, making the web better is the goal. how is not handling the taxonomic designation use case going to make the web better? |
| 02:35 | <MikeSmith> | kennyluck: inconsistency is a judgement call |
| 02:35 | <MikeSmith> | if you don't think the use cases for the u element are valid or important, then don't waste your time or other people's time by writing a proposal for it |
| 02:36 | <MikeSmith> | withdraw it and/or ask somebody else to write it up who does believe the use cases are important |
| 02:37 | <MikeSmith> | morphing it into a quest to get other elements removed instead does not seem like such a great plan |
| 02:45 | <erlehmann> | if inconsistency where a requirement for grandfathering stuff in, where would C:\fakepath be? |
| 02:46 | <kennyluck> | MikeSmith, If I didn't write that proposal, hsivonen would have written it so I don't see how this proposal would waste other people's time but mime. |
| 02:47 | <MikeSmith> | it wastes their time to have to read and consider a change proposal that you don't even support yourself |
| 02:48 | <MikeSmith> | if hsivonen were to write it, he'd write one that he actually supported, and that was restricted to the scope of the issue |
| 02:48 | <MikeSmith> | which is to say, arguing for keeping the u element as part of the language |
| 02:49 | <kennyluck> | MikeSmith, in my proposal I do argue for keeping the u element. I am just talking about my personal preference here. |
| 02:49 | <MikeSmith> | fine |
| 02:54 | <kennyluck> | Hixie, I don't believe having a previously presentational element handle a real use case would make the web better either. In fact, it makes the Web worse, by giving authors excuses to not use other clearly defined semantic elements. I gave examples in my proposal already. |
| 03:03 | <kennyluck> | Hixie, and u for proper nouns in Chinese is certainly real, although I wouldn't say it's very strong. I don't know the WHATWG process so I don't know if we do binary "exist"/"don't exist" classification to use cases before saying anything else. Otherwise, I think having the u element and exclude bad uses would just be very similar to how we dealt with b and i already. |
| 03:05 | <wirepair_> | Hixe, you about? |
| 03:05 | <wirepair_> | er Hixie... |
| 03:05 | <MikeSmith> | hmm, I don't remember seeing any announcement about this |
| 03:05 | <MikeSmith> | http://tools.ietf.org/html/draft-westin-payload-vp8-00 |
| 03:05 | <MikeSmith> | RTP Payload Format for VP8 Video |
| 03:05 | <MikeSmith> | nessy: ↑ |
| 03:06 | <nessy> | MikeSmith: is that a question? |
| 03:06 | <MikeSmith> | no |
| 03:06 | <MikeSmith> | just wondering if you had seen it |
| 03:07 | <nessy> | I'm not surprised :) the rtc-web guys have been very active recently around vp8 |
| 03:08 | <MikeSmith> | ok |
| 03:22 | kennyluck | is reading http://wiki.whatwg.org/wiki/Objections_against_CPs_for_ISSUE-144. |
| 03:23 | <kennyluck> | If someone can give me a hint on what "valid" means, that will be appreciated. |
| 03:28 | <MikeSmith> | "valid" means non-bogus |
| 03:28 | <MikeSmith> | valid means real uses cases, not constructed ones |
| 03:29 | <gsnedders> | Is https://bugs.webkit.org/show_bug.cgi?id=4920 not invalid? From an ES POV, it's two characters, not one, and hence not a valid idenifier as surrogates aren't allowed in identifiers. |
| 03:29 | <MikeSmith> | means cases where they are using the u element in a way for which some other element would not be more appropriate |
| 03:30 | <Hixie> | wirepair_, kennyluck: sorry, had to go afk. will be back in an hour or so |
| 03:36 | <Kira> | Can somebody recommend websites to learn HTML(5)? Reading the spec is kinda dry. |
| 03:37 | <kennyluck> | Kira, you might be interested in going to #html5 |
| 03:43 | <ben_h> | Kira: html5doctor has a lot of articles |
| 03:43 | <ben_h> | .. and their webserver is misconfigured it seems :) |
| 03:46 | <Kira> | heh |
| 03:54 | <MikeSmith> | kennyluck: see Hixie's comment at http://www.w3.org/Bugs/Public/show_bug.cgi?id=10830#c11 |
| 03:54 | <MikeSmith> | about <rb> |
| 03:54 | <MikeSmith> | especially the first part |
| 03:54 | <kennyluck> | MikeSmith, I know that. I told Koji that fantasai was wrong already. |
| 03:54 | <MikeSmith> | about how IE doesn't parse <rb> |
| 03:55 | <MikeSmith> | ah |
| 03:55 | <MikeSmith> | OK |
| 03:55 | <MikeSmith> | they know it's handled as void/empty element by IE, then? |
| 03:56 | <kennyluck> | fatasai claimed that IE handled something like <ruby><rb>A</rb><rb>B</rb><rt>a</rt><rt>b</rt></ruby> and this is obviously not true. |
| 03:56 | <kennyluck> | s/fatasai/fantasai/ |
| 03:57 | <kennyluck> | MikeSmith, I think so. They are asking for new feature. |
| 03:57 | <MikeSmith> | hmm |
| 03:57 | <MikeSmith> | I'm not sure they understood that yet |
| 03:57 | <MikeSmith> | but anyway, that comment makes it very clear |
| 03:59 | <MikeSmith> | based on the previous comments from Koji, it seemed to me he was assuming that it got into the DOM as expected |
| 03:59 | kennyluck | to lunch |
| 03:59 | <MikeSmith> | because he mentions that AT software expect to do something with it |
| 04:13 | <Hixie> | kennyluck: i don't understand "giving authors excuses to not use other clearly defined semantic elements" |
| 04:13 | <Hixie> | kennyluck: can you show me some pages that use <u> for proper nouns in Chinese? wikipedia says it doesn't happen, iirc. |
| 04:13 | <Hixie> | kennyluck: i would add the <u> element if there were use cases at all -- the thing is, i haven't seen any |
| 04:13 | <Hixie> | wirepair_: here now |
| 04:23 | <wirepair_> | Hixie have you seen any email about browser security acid tests? |
| 04:23 | <wirepair_> | from OWASP people |
| 04:23 | <Hixie> | yes |
| 04:23 | <wirepair_> | so i'm apart of that (they are going to use the infrastructure i created to put out those tests) |
| 04:23 | <Hixie> | cool |
| 04:24 | <Hixie> | is there additional background info i should know? |
| 04:24 | <wirepair_> | do you have any problem with us using that name? |
| 04:24 | <Hixie> | i can loop you in on the thread if you like |
| 04:24 | <wirepair_> | if you do we'll just call it browser security crack tests :) |
| 04:24 | <Hixie> | what's your e-mail address? |
| 04:24 | <wirepair_> | isaac.dawson⊙gc |
| 04:24 | <Hixie> | to summarise what i said in e-mail, i don't have a problem with it, but i don't think it's a good choice for you, necessarily |
| 04:25 | <wirepair_> | ah ok, i'll read your response |
| 04:25 | <Hixie> | there's a _lot_ of baggage associated with the "acid" term that hakon and i want but that you probably don't :-) |
| 04:25 | <wirepair_> | yeah i figured |
| 04:26 | <myakura> | MikeSmith, kennyluck, fyi IE9 parses <rb>blah</rb> |
| 04:26 | <MikeSmith> | Hixie: ↑ |
| 04:26 | <Hixie> | does IE9 parse <rb>blah</rb> any differently than <notehi>blah</notehi> ? |
| 04:27 | <myakura> | i think both would be treated as HTMLUnknownElement |
| 04:28 | <Hixie> | same as required by the HTML spec |
| 04:34 | <Hixie> | it's sad that they reimplemented their parser but not per the spec, btw :-( |
| 04:35 | <myakura> | Hixie, I see no difference between those http://i52.tinypic.com/j6pta8.jpg |
| 04:36 | <Hixie> | for that test i think they match the spec |
| 04:44 | <myakura> | hmm. taking </rb> out it fails :( http://i51.tinypic.com/2z7pt1x.png |
| 04:45 | <Hixie> | does what the html spec says to do :-) |
| 04:46 | <kennyluck> | Hixie: It does not happen as regular online Web pages (re. can you show me some pages that use <u> for proper nouns in Chinese?) , but the wikipedia entry itself has a valid example -> http://en.wikipedia.org/wiki/Proper_name_mark |
| 04:47 | <kennyluck> | However, it happens in every child's text book. |
| 04:48 | <kennyluck> | That is, not on the Web. I don't know whether that counts as valid use cases. |
| 04:50 | <kennyluck> | The Chinese version has examples that use the <u> element -> http://zh.wikipedia.org/zh/%E4%B8%93%E5%90%8D%E5%8F%B7 |
| 04:51 | <myakura> | Hixie, does the spec say so? isn't <rt> supposed to close <rb> in this case? |
| 04:59 | <kennyluck> | Hixie, (re. "giving authors excuses to not use other clearly defined semantic elements"), I want to ask why in http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#introduction "This section is non-normative" is marked up as <i>. "This section is non-normative" is certainly not a technical term ("non-normative" is), and it doesn't seem to be something that belong to use cases of alternate voice. It is (at least to me) |
| 04:59 | <kennyluck> | like a use case of <s> (for side comments). |
| 05:09 | <MikeSmith> | kennyluck: because it's not emphasis |
| 05:10 | <MikeSmith> | and because there are myriad valid use cases of italic type that have absolutely nothing to do with emphasis |
| 05:11 | <kennyluck> | oops, s/<s>/<small>/ |
| 05:12 | <kennyluck> | <small> is for side comments, sorry about typo. |
| 05:16 | <kennyluck> | MikeSmith, (re. based on the previous comments from Koji, it seemed to me he was assuming that it got into the DOM as expected), I think he just didn't understand the situation described in Hixie's comment 11 (i.e. "These are both feature requests beyond what IE implements and thus should be |
| 05:16 | <kennyluck> | filed as separate bugs to be handled in a future version. (We can always _add_ |
| 05:16 | <kennyluck> | <rb> later if it's really necessary for these cases.)") |
| 05:48 | <Hixie> | kennyluck: it's text that is offset from the main prose |
| 05:48 | <Hixie> | kennyluck: re examples of <u>, do you have any examples of the usage of proper name marks that aren't intended purely as examples of the usage of proper name marks? :-) |
| 05:48 | <Hixie> | kennyluck: i.e. "organic" usage? |
| 05:50 | <kennyluck> | Hixie, not on Web. I said so. I have pictures of text books, though. |
| 05:51 | <Hixie> | if nobody has used it on the whole web, then it's not a use case |
| 05:56 | <kennyluck> | Hixie, ok, that's worth noting. |
| 05:58 | <kennyluck> | Hixie, Question: isn't <small> more suitable for "This section is non-normative"? |
| 05:59 | <Hixie> | possibly. Certainly it's also suitable. <small> wasn't in the spec when I was writing those bits, iirc. |
| 06:01 | <kennyluck> | Anyway, I hope my point about "giving authors excuses to not use other clearly defined semantic elements" is explained fairly enough. |
| 06:26 | <Hixie> | i missed that that was what you were trying to explain :-/ |
| 06:26 | <Hixie> | are you saying that if we provide a way to mark up taxonomic designations, people will avoid using <small> for small print? |
| 06:26 | <Hixie> | that doesn't make much sense |
| 06:35 | <kennyluck> | Hixie, I was saying that if <i> is as broad and confusing as "text that is offset from the main prose", people will stop thinking <small> might be more semantically correct. |
| 07:13 | <Hixie> | kennyluck: i don't see the harm in that |
| 07:14 | <Hixie> | kennyluck: using more general elements (e.g. <span>) over more specific ones (e.g. <kbd>) is not a serious problem |
| 07:14 | <Hixie> | kennyluck: imho |
| 07:14 | <Hixie> | kennyluck: we can minimise it by providing few broad elements, but we can't eliminate it, since we always need at least one "default" element |
| 07:23 | <phrearch> | hello |
| 07:24 | <phrearch> | is there some html5 proposed/implemented api for touch/pressure yet? |
| 07:24 | <Hixie> | what do you mean by "html5"? |
| 07:24 | <phrearch> | huh? |
| 07:25 | <Hixie> | you mean a dom api? |
| 07:25 | <phrearch> | ah, eh more like a javascript api |
| 07:25 | <Hixie> | assuming you mean something like mouse events but for pressure-sensitive tablets, i believe the answer is no |
| 07:26 | <Hixie> | there might be some work on touch though |
| 07:26 | <Hixie> | not sure |
| 07:26 | <Hixie> | that's not really html per se |
| 07:26 | <phrearch> | i bought a wacom. they have a plugin for browsers, but it would be great if it would work crossplatform and without plugins |
| 07:26 | <phrearch> | no indeed |
| 07:27 | <phrearch> | im working on an opensource paint/pad app. having pressure data in the brushes would be great |
| 07:27 | <phrearch> | http://94.23.105.24:8000/psycopad/index.html |
| 07:27 | <phrearch> | still very early stuff |
| 07:28 | <phrearch> | started as a hello world canvas app, but i got some ideas to extend it with processing.js sketches and vector graphics |
| 07:44 | <kennyluck> | phrearch, perhaps you will be interested in this -> https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html |
| 07:44 | <phrearch> | kennyluck, thanks yes indeed |
| 07:45 | <phrearch> | seems like force is part of that event |
| 07:45 | <phrearch> | now hopefully there is some webkit branch that uses it |
| 09:22 | <annevk> | I guess what I most dislike about W3C charters is that the people who are putting the dates on them and do all the talk are not actually doing any of the work. |
| 09:45 | <annevk> | hmm, how can I postpone trying to define mutation events in detail |
| 09:46 | <zewt> | are you asking for procrastination tips |
| 09:46 | <zewt> | i'll come up with a list ... later |
| 09:46 | <annevk> | I'm gonna email www-dom with a bcc to public-webapps to announce the revamped DOM Events |
| 09:49 | <jgraham> | annevk: You could have a long, multi-year discussion about whether it is possible to drop mutation events, and what they should be replaced with |
| 09:50 | <annevk> | jgraham, we had a shorter variant of that, and the outcome was that IE9 is shipping with mutation event support |
| 09:51 | <jgraham> | annevk: Yeah, I know :) |
| 09:51 | <hsivonen> | we are all doomed |
| 09:51 | <jgraham> | (well I didn't know IE9 was getting mutation events) |
| 10:08 | <zcorpan> | i wonder if ie9 strips only the first instance of 'javascript:' when pasting into the address bar |
| 10:08 | <zcorpan> | otherwise it'd be simple to just do javascript:javascript:... |
| 10:09 | jgraham | wonders if pasting javascript:javascript: into the address bar is programmed to crash your computer in IE9 |
| 11:19 | <annevk> | I hope I can still get people to make them asynchronous |
| 11:19 | <annevk> | The synchronous events that modify the tree before the modification happens (or some such) are where the real pain lies. |
| 11:20 | <annevk> | If they are asynchronous the event loop model can also move to DOM Core, which is probably for the better. |
| 12:26 | <smaug____> | annevk: so how does you web-dom-core events relate to DOM 3 Events |
| 12:26 | <smaug____> | event propagation is different |
| 12:26 | <smaug____> | and dom 3 events allow things what for example indexeddb uses |
| 12:26 | <annevk> | that sounds like a bug |
| 12:26 | <annevk> | it's meant to replace dom3events |
| 12:27 | <smaug____> | annevk: in your events, event target chain is only for node |
| 12:27 | <smaug____> | nodes |
| 12:27 | <smaug____> | and the chain misses Window, if I read the draft correctly |
| 12:27 | <annevk> | HTML5 covers how Window works already |
| 12:27 | <smaug____> | eh |
| 12:28 | <annevk> | so Indexed DB has some kind of hierarchical object model other than Nodes and uses event propagation on them? |
| 12:28 | <smaug____> | web-dom-core tries to clearly define how even propagates, and that propagation certainly doesn't include Window |
| 12:28 | <smaug____> | yeah, IndexedDB has a tree or list |
| 12:29 | <smaug____> | of EventTargets |
| 12:29 | <annevk> | smaug____, HTML5 defines Window and says how it works together with DOM Events |
| 12:30 | <annevk> | smaug____, no need to duplicate that |
| 12:30 | <smaug____> | but web-dom-core basically dis-allows Window in the event target chain |
| 12:30 | <smaug____> | since "Let event path be a static ordered list of all ancestor nodes of event's target in tree order." |
| 12:30 | <zcorpan> | abarth: why [NoInterfaceObject] for Crypto? |
| 12:31 | <annevk> | smaug____, the way HTML5 defines it makes it work fine |
| 12:31 | <smaug____> | doing something else would violate step 1 |
| 12:31 | <annevk> | I agree that if we want hierarchical structures to work in general that section requires some changing |
| 12:31 | <annevk> | that should not be too hard I guess |
| 12:35 | <annevk> | smaug____, btw, the way DOM3Events defines "phase" makes it limited to nodes |
| 12:36 | <annevk> | smaug____, I think that's why I limited it, also because I did not know about Indexed DB's usage |
| 12:36 | <annevk> | but that can be changed easily |
| 12:36 | <smaug____> | ok, that would be a bug in DOM 3 Events |
| 12:37 | <zewt> | i havn't looked at what idb is doing, but isn't it odd that it's using dom events that differently? |
| 12:37 | <smaug____> | I still don't quite understand why events should be merged to web-dom-core |
| 12:37 | <smaug____> | zewt: "differently" ? |
| 12:37 | <annevk> | because they are intertwined |
| 12:38 | <annevk> | Node inherits from EventTarget, Document defines createEvent |
| 12:38 | <annevk> | removeChild causes events to be dispatched |
| 12:39 | <smaug____> | I still don't get it |
| 12:40 | <zewt> | differently as in not also propagating along nodes; i'll have to look over that spec again when i'm less tired |
| 12:40 | <annevk> | smaug____, ok |
| 12:42 | <annevk> | I don't think it's too important, but it's more convenient to define them together |
| 12:43 | <annevk> | And since they're sort of fundamental to most things, it makes sense to me (and others I believe, you're the first to question it) |
| 12:44 | <Bagadood> | Hello |
| 12:45 | <Bagadood> | Anyone here? |
| 12:45 | <zcorpan> | yes |
| 12:45 | <Bagadood> | This is my first time here. |
| 12:45 | <smaug____> | annevk: I'm not really against merging them, but it is kind of strange time |
| 12:45 | <zcorpan> | Bagadood: welcome |
| 12:45 | <Bagadood> | Cool, thnx :) |
| 12:46 | <smaug____> | annevk: I assume there will be some problems when DOM 3 Events and you events have something defined differently, and both are still drafts... |
| 12:46 | <smaug____> | s/you/your/ |
| 12:46 | <hsivonen> | I thought the plan was for Anne's / Ms2ger's specs to supercede Level 3 |
| 12:47 | <hsivonen> | for browsers that is |
| 12:47 | <hsivonen> | and Level 3 to become a Java spec |
| 12:47 | <annevk> | smaug____, the plan at TPAC was that I could go ahead and define "Events" and it would evolve in parallel and eventually obsolete the other work (I thought) |
| 12:47 | <smaug____> | hsivonen: for Core yes, but I'm not so sure about Events |
| 12:48 | <smaug____> | annevk: it would make a lot sense to take mutation events from DOM 3 Events to DOM core |
| 12:48 | <annevk> | I do think the way I defined it (apart from some event propagation details apparently) is way clearer |
| 12:49 | <smaug____> | annevk: but so, your plan is to merge all of DOM 3 Events to Web-DOM-Core? |
| 12:49 | <annevk> | Clear conformance criteria, completely clear on all the details, etc. |
| 12:49 | <annevk> | smaug____, I don't think the rest of DOM 3 Events is "Core" |
| 12:49 | <annevk> | mouse/keyboard/etc. should really be defined elsewhere |
| 12:50 | <smaug____> | why custom event is "core" ? |
| 12:50 | <annevk> | e.g. for mouse events you really want to define them together with pointer-events |
| 12:50 | <annevk> | smaug____, it isn't really, but seemed to small and simple to leave out |
| 12:50 | <annevk> | smaug____, and now serves as a nice example of how to define your own events |
| 12:51 | <smaug____> | annevk: but you're going to take also mutation events? |
| 12:51 | <smaug____> | hmm, though we really want to get rid of those... |
| 12:51 | <annevk> | so I would love that |
| 12:51 | <annevk> | that would be better |
| 12:51 | <annevk> | but IE9 has them |
| 12:51 | <annevk> | you guys have them |
| 12:51 | <smaug____> | so? |
| 12:52 | <annevk> | WebKit has them and Opera has them |
| 12:52 | <annevk> | can we really kill them? |
| 12:52 | <smaug____> | all of the browsers have different subset of them |
| 12:52 | jgraham | strongly doubts it |
| 12:52 | <jgraham> | That we can kill them |
| 12:52 | <annevk> | are you going to remove them from Firefox after 4 ships? |
| 12:52 | <annevk> | I mean if that is a yes I can wait with adding them to the spec |
| 12:52 | <annevk> | because I'd love for that to work and I don't have a deadline here |
| 12:52 | <jgraham> | Even if they are not quite interoperable, everyone will have some content that depends on them |
| 12:52 | <annevk> | in fact, I'm leaving for three months soonish :) |
| 12:53 | <annevk> | the impression I got at TPAC was that nobody in fact was planning on killing them |
| 12:53 | <annevk> | maybe a couple |
| 12:53 | <annevk> | but not all |
| 12:53 | <annevk> | the only change I had the impression we might be able to make was to make them asynchronous |
| 12:54 | <smaug____> | since no one likes them, we really should try to get rid of them. |
| 12:54 | <smaug____> | if that doesn't work out, then it just doesn't |
| 12:54 | <smaug____> | and we need to keep them forever |
| 12:55 | <zcorpan> | making them async seems like a win |
| 12:55 | <smaug____> | but we haven't even tried |
| 12:55 | <annevk> | smaug____, alright, I will wait with figuring out mutation events |
| 12:55 | <annevk> | I really wasn't looking forward to that anyway :) |
| 12:56 | <smaug____> | annevk: :) |
| 12:56 | <smaug____> | it can be,hmm, interesting to define DOMSubtreeModified properly |
| 14:40 | <annevk> | smaug____, what to do with Progress Events by the way? |
| 14:40 | <annevk> | smaug____, reportedly Gecko supports two more members, do they need to be added to the spec? |
| 14:40 | <annevk> | smaug____, and are they the same or different? |
| 14:40 | <smaug____> | I'm hoping to get rid of those members |
| 14:41 | <smaug____> | they are from pre-Progress-Events-spec era |
| 14:41 | <smaug____> | same or different? |
| 14:43 | <annevk> | are they aliases or have different semantics? |
| 14:43 | <annevk> | but if you want to get rid of them that works |
| 14:44 | <annevk> | I guess then we can proceed with Progress Events |
| 14:44 | <smaug____> | they have different semantics |
| 14:44 | <smaug____> | at least when handling multipart xhr |
| 14:45 | smaug____ | doesn't know whether others support multipart XHR |
| 14:51 | <annevk> | I hope we can get rid of that too |
| 15:01 | <smaug____> | multipart XHR is actually quite nice |
| 15:02 | <annevk> | XHR is so complex already |
| 15:02 | <annevk> | and full of holes in browsers |
| 15:49 | <annevk> | oh teehee |
| 15:49 | <annevk> | hashbangs was the thing i missed in the WHATWG Weekly |
| 15:50 | annevk | puts it on the list for next week |
| 15:57 | <annevk> | hmm |
| 15:57 | <annevk> | so if events can operate on an object tree |
| 15:57 | <annevk> | that would make event dispatching easier |
| 15:57 | <annevk> | but would require a definition of an arbitrary object tree |
| 15:58 | <annevk> | and ideally nodes just map onto that |
| 16:02 | <annevk> | meh |
| 16:06 | <annevk> | smaug____, so to be sure I checked Indexed DB |
| 16:06 | <annevk> | smaug____, nothing in there says events actually bubble |
| 16:07 | <smaug____> | propagate |
| 16:07 | <annevk> | smaug____, in fact, everything does not bubble and is not cancelable |
| 16:07 | <annevk> | smaug____, oh, you mean they can be captured? |
| 16:07 | <smaug____> | I wasn't talking about bubbling but about propagation |
| 16:07 | <smaug____> | yeah |
| 16:07 | <annevk> | smaug____, from which object? |
| 16:08 | smaug____ | is in a meeting atm |
| 16:08 | <smaug____> | annevk: you could ask sicking |
| 16:08 | <annevk> | Indexed DB does not even define "tree" anywhere |
| 16:09 | <annevk> | or mention "propagate" other than in the context of an exception |
| 16:10 | <annevk> | anyway, once I figure out how, this should be easy |
| 16:11 | <annevk> | I'm not very pleased with the current "Nodes Model" either which is a mixture of copied terms from HTML and CSS |
| 17:25 | <Philip`> | http://www.computerworld.com/s/article/9209322/W3C_HTML5_will_be_finished_in_2014 - '"This is the first time we've been able to answer people's questions of when it will be done," said Ian Jacobs, head of W3C marketing and communications.' |
| 17:25 | <Philip`> | Sounds like the W3C is fairly confident in its prediction |
| 17:27 | <tw2113> | better than the 2023 or whatever prediction |
| 17:27 | <TabAtkins> | "better" how? |
| 17:27 | <Ms2ger> | Then again, 2022 is more likely |
| 17:27 | <jgraham> | Philip`: Well that's just wrong. Before they were telling people it would be done in 2010 |
| 17:29 | <jgraham> | Although I suppose as a press quote "this is the second date we have published for HTML5 to be complete, and just like the last one this one is believed to be wildly optimistic by the people actually doing the work" isn't so snappy |
| 17:30 | <jgraham> | Although possibly he could go on to explain the W3C definition of the word "Last" as in "Last Call" which means something quite different to any other definition of "last" |
| 17:31 | <jgraham> | and watch as the reporter's head explodes |
| 17:31 | <jgraham> | Could be a fun game |
| 17:31 | <tw2113> | i'd give a dollar to see that |
| 17:32 | <Ms2ger> | That's more than most people would give for the article |
| 17:33 | <jgraham> | "The feedback from this "Last Call" is expected to be quite considerable and could result in another revision of the document." |
| 17:33 | <jgraham> | Someone tell Hixie he is only allowed to make one edit after last call :) |
| 17:33 | jgraham | is just being mean now |
| 17:34 | <TabAtkins> | So, I kind of want to work on defining an "Image Profile" for SVG, which would cut out the more complex/buggy parts of it that browsers currently hack around when using SVG in image contexts. |
| 17:34 | <TabAtkins> | The idea made one of our security guys happy this morning. |
| 17:48 | <TabAtkins> | AryehGregor: FYI, since you were talking about the "block this domain" link in Google offered by the extensions.. |
| 17:48 | <TabAtkins> | Apparently we did it that way because it was faster: http://news.ycombinator.com/item?id=2218542 |
| 18:16 | <AryehGregor> | TabAtkins++ on image profile for SVG. |
| 18:17 | <AryehGregor> | What I'd really like is an image profile for SVG with a different file extension and MIME type. |
| 18:17 | <AryehGregor> | Currently you can let users submit arbitrary PNG/GIF/JPEG/etc. and just throw it up on your web server with no validation and it's safe. |
| 18:17 | <TabAtkins> | image/svgi |
| 18:17 | <AryehGregor> | But not SVG. |
| 18:17 | <AryehGregor> | +xml? |
| 18:17 | <TabAtkins> | Nuts to the +xml. |
| 18:18 | TabAtkins | may have to bow to the mimetype gods, for they are crotchety and demanding. |
| 18:18 | <AryehGregor> | If you don't add +xml, maybe your new MIME type won't be registered at the IANA for years! Totally unlike image/svg+xml. |
| 18:18 | <TabAtkins> | I now need to go back in time and make full svg only use application/svg+xml, so I can reserve image/svg for myself. |
| 18:20 | TabAtkins | would not use a time machine responsibly if given one. |
| 18:20 | AryehGregor | finds that the easiest way in XChat to re-auth if the first auth doesn't go through is just to reconnect |
| 18:24 | <Ms2ger> | Anything interesting in the i/b/u discussion earlier? |
| 18:31 | <AryehGregor> | Where, in #whatwg or someplace else? |
| 18:31 | <TabAtkins> | Here, overnight. |
| 18:58 | <jgraham> | Ms2ger: Dunno, I tuned it out on the basis that b/i/u discussions are disproportionately unproductive |
| 19:00 | <Ms2ger> | That's why I was hoping for someone else to filter out anything productive |
| 19:00 | <AryehGregor> | Is anyone else getting a 500 error when trying to commit to dvcs.w3.org? |
| 19:00 | <Ms2ger> | Until then, I'm assuming there wasn't anything |
| 19:01 | <Ms2ger> | What I'm getting is unresponsive script dialogs from your reflection test |
| 19:01 | <annevk> | look at that, Ms2ger is online |
| 19:01 | <AryehGregor> | Ms2ger, which test URL and which browser? |
| 19:01 | <annevk> | Ms2ger, you're cool with renaming too right? |
| 19:01 | <Ms2ger> | Yeah |
| 19:01 | <Ms2ger> | http://localhost/tests/html-official/submission/AryehGregor/reflection/reflection-onepage.html, Minefield |
| 19:02 | AryehGregor | isn't seeing that in 4b11 |
| 19:02 | <AryehGregor> | It doesn't seem to work, though. |
| 19:02 | <annevk> | I wonder if we should have a copy of DOM Core that can be hosted on html5.org |
| 19:02 | <Ms2ger> | I dunno |
| 19:02 | <AryehGregor> | http://aryeh.name/tests-root/tests/submission/AryehGregor/reflection/reflection-original.html works fine. |
| 19:02 | <AryehGregor> | Blame jgraham. |
| 19:02 | <AryehGregor> | (I'll be splitting up the -onepage version, though.) |
| 19:03 | <annevk> | It does not seem like the other html5.org specs have a license so I guess not |
| 19:03 | <AryehGregor> | Okay, wait, the -onepage one is broken somehow. |
| 19:03 | <AryehGregor> | Oh, no it's not. |
| 19:03 | <annevk> | I guess I should worry about that soonish so hsivonen doesn't have to |
| 19:03 | <AryehGregor> | It just stays blank for a while before the results render. |
| 19:03 | <AryehGregor> | Maybe because it's a 20,000+ row table. |
| 19:04 | <AryehGregor> | The layout seems to take longer than actually running the tests. |
| 19:05 | <Ms2ger> | On that note |
| 19:05 | <Ms2ger> | AryehGregor, can I use HTML's license for DOM Range? |
| 19:05 | <AryehGregor> | You can use whatever license you want, as far as I care. |
| 19:05 | <AryehGregor> | Hixie told me to make all my Google stuff public domain, and I have no problem with that. |
| 19:06 | <Ms2ger> | k |
| 19:13 | <AryehGregor> | Okay, I give up: where is "ToString" defined here? http://dev.w3.org/2006/webapi/WebIDL/ |
| 19:13 | <AryehGregor> | "the ToBoolean, ToNumber, ToUint16, ToInt32, ToUint32, ToString and ToObject operators referenced in this section are defined in section 9." |
| 19:13 | <AryehGregor> | I don't see them. |
| 19:13 | <AryehGregor> | (Could terms like this be linked?) |
| 19:15 | <gsnedders> | AryehGregor: They're defined in ES5 |
| 19:15 | <gsnedders> | "Algorithms in this section use the conventions described in section 5.2 and the ToBoolean, ToNumber, ToUint16, ToInt32, ToUint32, ToString and ToObject operators referenced in this section are defined in section 9." |
| 19:16 | <AryehGregor> | Section 9 of the ES spec. |
| 19:16 | <AryehGregor> | Oh. |
| 19:16 | <AryehGregor> | Is this the right spec to look at? http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf |
| 19:17 | <gsnedders> | AryehGregor: If it says Fifth Edition on it, yes. |
| 19:17 | <Ms2ger> | MikeSmith has an HTML version, fwiw |
| 19:17 | <AryehGregor> | Now I have the problem that WebIDL doesn't match reality here. At least for null. |
| 19:18 | <Ms2ger> | That's known |
| 19:18 | <AryehGregor> | ES5 says "null". Opera does "null", Gecko does "", WebKit does something broken for reflected attributes (removes the attribute). |
| 19:18 | <AryehGregor> | Well, if it's not desired then I don't want to test it. |
| 19:19 | <AryehGregor> | But they agree on "undefined", so I'll test that. |
| 19:20 | <annevk> | well, the idea is that Web IDL interfaces to ECMAScript will do null -> "" |
| 19:20 | <annevk> | but inside ECMAScript null -> "null" |
| 19:21 | gsnedders | is unconvinced losing what little consistency the platform already has is a good idea |
| 19:21 | gsnedders | seems to remember annevk making that argument a few weeks ago :P |
| 19:22 | <annevk> | gsnedders, there's lots of sites that depend on null -> "" |
| 19:22 | <gsnedders> | annevk: ah :( |
| 19:23 | <AryehGregor> | Opera seems to do null -> "null". |
| 19:23 | <annevk> | yeah, it's problematic |
| 19:23 | <annevk> | it's being changed or is changed |
| 19:30 | <AryehGregor> | Is there a way to do casting in JavaScript without special-casing for different types? |
| 19:30 | <AryehGregor> | Like I know you can do foo + "" to convert to string according to ES algorithms. |
| 19:31 | <AryehGregor> | And !!foo for boolean, and whatever. |
| 19:31 | <franksalim> | AryehGregor: like String(foo) or Boolean(foo)? |
| 19:31 | <AryehGregor> | Does that work? |
| 19:31 | <bga_> | yes |
| 19:31 | <AryehGregor> | Yes, thaks. |
| 19:31 | <AryehGregor> | thanks. |
| 19:33 | <AryehGregor> | Given the name of a JS type, can I call something to cast to that type? I guess I could do eval(typeName) to get the function, but that seems sort of horrible. |
| 19:33 | <othermaciej> | JS does not have typecasting |
| 19:34 | <AryehGregor> | It has type conversion algorithms. |
| 19:34 | <othermaciej> | that is true |
| 19:34 | <franksalim> | AryehGregor: those functions seem to be on the global object, at least in the browser. window["String"](foo) works |
| 19:34 | <AryehGregor> | Oh, that works. |
| 19:34 | <AryehGregor> | Thanks. |
| 19:34 | <franksalim> | np |
| 19:38 | <annevk> | so for a generic tree framework... |
| 19:39 | <annevk> | a type of object (e.g. node) can be said to participate in it or something |
| 19:39 | <annevk> | which means it follows a set of constraints |
| 19:39 | <annevk> | that lead to things like "ancestor", "parent", "child" etc. being defined |
| 19:40 | <annevk> | so for nodes we'd say they are "tree-based", following the constraints described in the Nodes Model |
| 19:41 | <annevk> | and from that follows that you can say ancestor of a particular node |
| 19:42 | <annevk> | and since we don't say XMLHttpRequest is tree-based there's no question about its event path, it's simply empty |
| 19:46 | <AryehGregor> | Apparently Opera's string handling isn't binary-safe: data:text/html,<!doctype html><script>var el = document.createElement("span"); el.title = "\0abc"; alert(el.getAttribute("title").length);</script> |
| 19:46 | <AryehGregor> | That just caused it to fail several thousand of my tests. :) |
| 19:46 | <gsnedders> | AryehGregor: It's binary-safe in places :P |
| 19:46 | <annevk> | binary safe? |
| 19:47 | <gsnedders> | AryehGregor: And there's no such thing as binary data in JS, if you want to be pedantic. |
| 19:47 | <Ms2ger> | It just fails for null, no? |
| 19:48 | <annevk> | yeah, stuff is null-terminated |
| 19:48 | <gsnedders> | Ms2ger: Yeah, in places in DOM |
| 19:48 | Philip` | puts \0s in lots of his canvas tests, just to annoy Opera |
| 19:49 | <annevk> | heh |
| 19:49 | <annevk> | we'll fix it one day |
| 19:49 | <Philip`> | Ensuring that canvas.getContext('2d\0') fails provides precisely zero value to humanity |
| 19:50 | <Philip`> | but that's not my concern so I'll test it anyway |
| 19:51 | <bga_> | if(window.title == '') { window.title = 'a\0b'; location.reload() } else { alert(window.title.length) } |
| 19:52 | <bga_> | s/title/name/g |
| 20:00 | AryehGregor | discovers async is no longer a reflected attribute: script.async: IDL get with DOM attribute unset (expected false, got true) |
| 20:05 | <AryehGregor> | Is anyone else getting loads of errors with "-u" + little box + "8" in them here in Opera 11, in the number parts of the test? I have no idea what's up with that. http://aryeh.name/tests-root/tests/submission/AryehGregor/reflection/reflection-original.html |
| 20:08 | <AryehGregor> | Oops, looks like IE9 also isn't binary-safe here. |
| 20:08 | <AryehGregor> | Guess it fails several thousand tests on that too. |
| 20:14 | <Ms2ger> | Uh |
| 20:14 | Ms2ger | summons jgraham |
| 20:14 | <AryehGregor> | ? |
| 20:15 | AryehGregor | discovered that Firefox strips leading and trailing whitespace on setAttribute() for audio/img/source/video.src, yay for corner-case bugs |
| 20:17 | <Hixie> | karlcow: did you notice how every single result in the search you did for "whatwg" on the w3c site is either blog comments or quotes? you pretty much proved my point. |
| 20:22 | <karlcow> | Hixie: in which way? I do not understand |
| 20:23 | <Hixie> | my point was that the w3c doesn't talk about the whatwg. the results of the search you cited demonstrate that the w3c doesn't talk about the whatwg, just that people comment about the whatwg on w3c blog posts |
| 20:23 | <jgraham> | Ms2ger: here now |
| 20:24 | <Ms2ger> | Why does it make sense to use add_completion_callback in window.onload? |
| 20:24 | <karlcow> | http://www.w3.org/QA/2007/11/tp-links-feast.html |
| 20:25 | <karlcow> | "The WHATWG at the W3C technical plenary" ->http://blog.whatwg.org/the-whatwg-at-the-w3c-technical-plenary |
| 20:25 | <jgraham> | Ms2ger: where? |
| 20:25 | <jgraham> | Completion never happens until onload |
| 20:26 | <jgraham> | But I don't think it is necesarily the case that window.onload is called before addEventListener registered handlers. Or is it? |
| 20:27 | <Hixie> | karlcow: you think the w3c linking to a whatwg blog post as one of the last links in a huge list of links to blog posts about the w3c is evidence that the w3c is happy about the whatwg and has no problem working with them? now you're stretching, even for you. |
| 20:27 | <Ms2ger> | (I'm assuming the answer is "it doesn't") |
| 20:28 | <Hixie> | karlcow: has there ever been a mention (any mention, not even a positive mention!) of the whatwg on the w3c home page? (for years the whatwg home page linked to the w3c) |
| 20:29 | <Hixie> | karlcow: has there ever been a w3c news item where the w3c positions the w3c as equal partners, even when talking about the HTML spec? (the whatwg frequently mentions the w3c when talking about what we do) |
| 20:29 | <jgraham> | Ms2ger: I am confused |
| 20:30 | <jgraham> | What have I done wrong? |
| 20:31 | Ms2ger | tests again |
| 20:31 | karlcow | would have not expected to see hixie in the role of victim. That is definitely new. |
| 20:31 | <Hixie> | victim? |
| 20:32 | <karlcow> | to your questions about w3c not citing on the blog. I agree. There was not that much. |
| 20:32 | <Hixie> | i'm just pointing out that the w3c isn't cooperating, and the whatwg is, so danny's suggestion that the situation is the reverse is incorrect |
| 20:32 | <Hixie> | you seem to want to disagree with everything i say, whether it's true or not :-) |
| 20:33 | <webr3> | lol karlcow, you can't disagree w/ that |
| 20:33 | <webr3> | if you do you prove it! |
| 20:33 | <karlcow> | Hixie: you are wrong about w3c not participating. This, I'm sure for it, and for a very good reason. |
| 20:33 | <AryehGregor> | Hixie, you should really stop concluding that other people's disagreements with you are irrational or dishonest. It's generally not true, and if it is, it doesn't help to say it. |
| 20:33 | <karlcow> | I was part of it. |
| 20:34 | webr3 | sigh - i was geniunely optimistic that people might be looking to the future rather than the past |
| 20:34 | <AryehGregor> | I think it's fairly clear that the average WHATWG adherent participates in and cares about the W3C much more than the average W3C adherent participates in or cares about the WHATWG, where by "adherent" I mean someone who prefers one venue to other. |
| 20:34 | <Ms2ger> | jgraham, http://dvcs.w3.org/hg/html/file/0f677593d693/tests/resources/testharness.js#l641 |
| 20:34 | <karlcow> | That you didn't get the type of participation you were expecting, I can acknowledge that. |
| 20:34 | <Hixie> | AryehGregor: i was merely pointing out what karl's arguments felt like, no conclusions drawn. |
| 20:35 | <karlcow> | as webr3 is saying, I have a lot more hope for the future than the past. |
| 20:35 | <Ms2ger> | jgraham, the callbacks are run before that |
| 20:35 | <Hixie> | karlcow: my point was merely regarding danny's assertions, i wasn't trying to make any statement beyond that. I'm glad you now agree with those assertions despite your earlier contradiction of them. |
| 20:35 | <karlcow> | AryehGregor: that has been often my point. WHATWG and W3C are often the same participants. |
| 20:36 | <karlcow> | Aka people loving technologies, the Web and want to improve it |
| 20:36 | <karlcow> | Hixie: please, never put your words in my mouth ;) that would be better |
| 20:36 | <jgraham> | Ms2ger: If they are it is a big |
| 20:36 | <jgraham> | *bug |
| 20:37 | <webr3> | aye for all the two different names, it's still the same people - just need to get an agreed process that's best for the web, you know, balance evolution w/ interop |
| 20:37 | <jgraham> | Ms2ger: Because the completion callback should never be run before all_done() is true |
| 20:37 | <webr3> | tbh I don't have a scooby-doo why it's taking so long :| |
| 20:37 | <karlcow> | webr3 exactly |
| 20:37 | <Hixie> | karlcow: wait, you still think danny is right despite saying that my points were correct? now i'm just confused. |
| 20:37 | <jgraham> | and all_done() can't be true until it is set there |
| 20:37 | <jgraham> | supposedly |
| 20:38 | <jgraham> | s/it/all_loaded/ |
| 20:38 | <karlcow> | Hixie, I see you are confused. This is not a surprise :) |
| 20:38 | <Ms2ger> | Let me check |
| 20:38 | <webr3> | danny didn't get it right (wel half did half didn't) the future bit made sense, the past bit about subverted didn't evoke the correct situation |
| 20:39 | <webr3> | "we want xhtml 2.0" "umm the web needs html updated" "we're sticking to xhtml" "fine I'll do html elsewhere" "gah you were right" "yup" - how do we sort that |
| 20:40 | <webr3> | that's about it in a nutshell isn't it? |
| 20:40 | <Hixie> | karlcow: it's not a surprise that you confuse me? no, i guess not. :-) i rarely understand what you mean, you seem to never want to state an actual position, just imply one. |
| 20:40 | <TabAtkins> | webr3: Yup. |
| 20:40 | <Hixie> | karlcow: you should be more assertive :-) |
| 20:41 | <karlcow> | damn the poet. |
| 20:41 | <karlcow> | I'm not a computer |
| 20:42 | <Hixie> | being assertive is a human leadership trait, not a computer trait. |
| 20:42 | <webr3> | the incredibly stupid thing is, that afaict, everybody wants the same thing :| certainly everybody I've ever spoken to about html on all "sides" |
| 20:42 | <Ms2ger> | jgraham, all_done() is false |
| 20:43 | <karlcow> | I think it's where we disagree. I can be assertive on that. leadership is one of the worse things :) (not trying to convince you) |
| 20:44 | <Hixie> | karlcow: being assertive is also an important human trait when having discussions, even when not leading |
| 20:44 | <jgraham> | Ms2ger: When the completion callbck is being called? Or when it is being set? |
| 20:45 | <Ms2ger> | In Tests.prototype.notify_complete |
| 20:45 | <jgraham> | Umm, that seems wrong |
| 20:45 | <karlcow> | Hixie: not in my values ;) |
| 20:45 | <Ms2ger> | Yes |
| 20:45 | <jgraham> | Ms2ger: TC? |
| 20:45 | <Hixie> | karlcow: if you're going to argue with me, as you seem wont to do, you will find that our lives are much more pleasant if you can assert your statements positively rather than implying them and being unsurprised when i have no idea what you're saying |
| 20:45 | <Hixie> | karlcow: being vague is not a positive human communication trait |
| 20:47 | <karlcow> | :) |
| 20:48 | <AryehGregor> | jgraham, it just stops at "Running, 63280 complete 0 remain" in all browsers I test on. :( http://aryeh.name/tests-root/tests/submission/AryehGregor/reflection/reflection-onepage.html |
| 20:48 | <AryehGregor> | Time to split it up. |
| 20:49 | <jgraham> | AryehGregor: Oh |
| 20:49 | <jgraham> | I can look at that |
| 20:49 | <Ms2ger> | jgraham, that's the TC |
| 20:49 | <AryehGregor> | That would be nice, thanks. |
| 20:49 | <rgervais> | what's the difference between <section> and <div> and can someone please provide a good a example of when to use <section> in HTML5 |
| 20:49 | jgraham | thinks 63280 tests in a file doesn't meet the criteria for "reduced testcase" |
| 20:50 | <jgraham> | :p |
| 20:50 | <Ms2ger> | rgervais, see the spec |
| 20:50 | <Hixie> | rgervais: <section> is for chapters, subsections of blog posts, etc, while <div> is for styling hooks. |
| 20:50 | <jgraham> | AryehGregor: BTW, we can probably fix the output to suck less |
| 20:50 | <Hixie> | rgervais: there are a number of examples for <section> in the spec, e.g. http://www.whatwg.org/specs/web-apps/current-work/complete/sections.html#the-section-element |
| 20:51 | <rgervais> | Ms2ger: I saw the spec but I'm a dumb person and a basic explanation |
| 20:51 | <nessy> | rgervais: I've seen a template for slides that uses <section> for every slide and the whole presentation is a single html page - I liked that use of <section> |
| 20:51 | <rgervais> | Hixie: what's a 'chapter'? |
| 20:51 | <Hixie> | rgervais: like in a book |
| 20:52 | <rgervais> | well this is the web, I need a real use case scenario |
| 20:52 | <rgervais> | let me check that link |
| 20:52 | <rgervais> | hopefully it breaks it down |
| 20:52 | <rgervais> | not a book example |
| 20:52 | <rgervais> | subsections in blogs, ok that's one |
| 20:53 | <rgervais> | nessy link? |
| 20:54 | <rgervais> | I'm looking at the spec againn and just wonder why not use a <div> instead of a section |
| 20:54 | <rgervais> | Hixie: you said for styling hooks |
| 20:54 | <craigbarnes> | because a div implies nothing |
| 20:54 | <rgervais> | so basically sections shouldn't be styled? |
| 20:54 | <craigbarnes> | one is semantic the other is for general use |
| 20:54 | <AryehGregor> | jgraham, if you want to look into it, test with this, because I'm in the middle of changing things: http://dvcs.w3.org/hg/html/raw-file/859abfc6fdf2/tests/submission/AryehGregor/reflection/reflection-onepage.html |
| 20:55 | <rgervais> | craigbarnes: I see.. |
| 20:55 | <nessy> | rgervais: for example http://videos.mozilla.org/serv/blizzard/audio-slideshow/ |
| 20:56 | <Hixie> | rgervais: you can style <section> too, it's just <div> is for anything at all, but <section> is just for sections. |
| 20:56 | <craigbarnes> | I just said that :) |
| 20:56 | <craigbarnes> | kind of |
| 20:57 | <rgervais> | OK. what's the definition of a 'section'? |
| 20:57 | <craigbarnes> | rgervais, that's what the spec is for |
| 20:57 | <craigbarnes> | it's all laid out nicely for you to read ;) |
| 20:58 | <rgervais> | I've read the spec, I just need a dumbed down definition |
| 20:58 | <Ms2ger> | A part of a document with a header |
| 20:58 | <Hixie> | rgervais: see the dictionary :-) |
| 20:58 | <Ms2ger> | Roughly |
| 20:58 | <craigbarnes> | yeah the dictionary nails it |
| 20:59 | <Hixie> | rgervais: if you have specific examples you want us to give a "yay" or "nay" on that might help |
| 20:59 | <rgervais> | Ms2ger: ok kind of make sense |
| 20:59 | <rgervais> | so if a group of p tags |
| 20:59 | <rgervais> | don't have a header |
| 21:00 | <rgervais> | then use a <div> |
| 21:00 | <rgervais> | ? |
| 21:00 | <jgraham> | Why are they a group? |
| 21:00 | <craigbarnes> | It's a semantic, you can't yay or nay a use case based on tags |
| 21:00 | <craigbarnes> | it's based on content |
| 21:00 | <craigbarnes> | s/semantic/semantic tag/ |
| 21:01 | <Ms2ger> | s/tag/element/ |
| 21:01 | <craigbarnes> | yeah that's what i meant |
| 21:01 | <craigbarnes> | thanks |
| 21:02 | <rgervais> | jgraham: example.. <p>hello</p><p>another paragraph</p> |
| 21:02 | <rgervais> | should I wrap that in <section> or <div> |
| 21:02 | <rgervais> | or is this example too generic |
| 21:02 | <Ms2ger> | It is |
| 21:02 | <craigbarnes> | yes |
| 21:02 | <rgervais> | I've left out h tags |
| 21:02 | <rgervais> | so no headings |
| 21:03 | <craigbarnes> | I think you're over-thinking it |
| 21:03 | <craigbarnes> | it's not that complicated |
| 21:03 | <craigbarnes> | if you could refer to it generically as a section then you can probably use a section element |
| 21:04 | <nessy> | I like to think of <section> elements as an opportunity to have the main html elements available to me again without influencing the rest of the document, such as h1, h2, p etc |
| 21:04 | <rgervais> | I see.. |
| 21:05 | <craigbarnes> | the gotchas are in the spec |
| 21:05 | <rgervais> | well I'll keep looking into that, thanks for the info on that so far |
| 21:06 | <rgervais> | some other questions I have in general regarding HTML5 |
| 21:06 | <rgervais> | since it's technically still a draft, when will it finalized |
| 21:06 | <rgervais> | and do you guys recommend using it if it isn't final |
| 21:07 | <Hixie> | the whatwg spec is a standard now, not a draft |
| 21:07 | <Hixie> | http://whatwg.org/c |
| 21:08 | <craigbarnes> | Don't wait to start using it |
| 21:10 | <craigbarnes> | There's no such thing as final |
| 21:10 | <craigbarnes> | that true in every area of technology :) |
| 21:10 | <rgervais2> | true, I say that because |
| 21:10 | <webr3> | have to agree, use "html" now - just check the support for the "new" features you want |
| 21:11 | <rgervais2> | say you use things and then all of a sudden it's no longer valid |
| 21:11 | <rgervais2> | because of changes |
| 21:11 | <rgervais2> | that's what I mean |
| 21:11 | <webr3> | - http://caniuse.com/ is your friend |
| 21:12 | <craigbarnes> | The spec if going to change so drastically that things just "break" |
| 21:12 | <karlcow> | rgervais2: in which circumstances do you try to be valid? What are the benefits? (not asking you to not be valid) |
| 21:13 | <craigbarnes> | And they are going to great lengths to consider these things before they implement them |
| 21:13 | <rgervais2> | karlcow: Actually I don't necessarily need to my HTML to validate but if I use elements, tags approved in working draft |
| 21:14 | <rgervais2> | and then gone later |
| 21:14 | <rgervais2> | webr3: thanks for that |
| 21:14 | <rgervais2> | that is helpful |
| 21:14 | <craigbarnes> | you may have to clean up a bunch of vendor prefixes in your CSS and "polyfills" in your JavaScript etc. |
| 21:14 | <rgervais2> | craigbarnes: makes sense |
| 21:14 | <karlcow> | rgervais2: use things which are widely deployed |
| 21:15 | <karlcow> | if they are not, use them for you, for testing, for experimenting. And use them only in production when they are deployed. |
| 21:15 | <rgervais2> | is it OK if I just go ahead and start developing sites with the new doctype? |
| 21:15 | <rgervais2> | without no blacklash? |
| 21:15 | <karlcow> | It depends on your business constraints |
| 21:15 | <Philip`> | rgervais2: Web browsers don't want to make pages stop working, so if you make something that runs now then it should continue to run forever |
| 21:15 | <karlcow> | <!doctype html> is the one which has always been parsed by browsers |
| 21:15 | <craigbarnes> | rgervais2, yes, you can do that right away |
| 21:15 | <craigbarnes> | you just have to learn what you can use blindly |
| 21:15 | <craigbarnes> | and what you need to learn the implications of |
| 21:16 | <Philip`> | rgervais2: (There's no real constraint on making pages fail the validator, though - if you do something now that's considered bad practice a decade from now then your page will be reported as invalid) |
| 21:16 | <rgervais2> | Philip`: I'm not for a page necessary validating, I meant just valid elements |
| 21:16 | <rgervais2> | craigbarnes: makes sense |
| 21:16 | <craigbarnes> | rgervais2, the best thing you can do right now is understand why people are telling you these things instead of just asking and doing |
| 21:17 | <karlcow> | for example html5 new elements such as section are still not widely supported out of the box. |
| 21:17 | <karlcow> | the support is different from browser to browser |
| 21:17 | <craigbarnes> | that way when the spec has settled down a little, you'll be way ahead of the game |
| 21:17 | <karlcow> | It changes quickly and there is hope that the situation will improve at a fast pace |
| 21:18 | <karlcow> | it all depends on your business constraints. |
| 21:19 | <rgervais2> | karlcow: generall the browsers I code for are IE7 and up and of course FF, Safari, Chrome |
| 21:19 | <webr3> | rgervais2, yes just use what features of html you want and that are deployed, unless you think every browser can be recalled - they all support "html" and there does exist a common subset of the latest spec which is avail accross the board, and emulatable where not - tis safe to use, and was /ages/ ago |
| 21:19 | <webr3> | html 5 is just an old promise that needs to be fullfilled, after that it'll be far more itteratively updated I'm sure, whether that's in w3c or whatwg, or both together |
| 21:20 | <karlcow> | rgervais, you can use <!doctype html> but avoid new html5 elements, and some very new things of the DOM. |
| 21:20 | <karlcow> | if you want to have no troubles in IE7 |
| 21:20 | <rgervais2> | karlcow: OK |
| 21:26 | <rgervais2> | thanks guys for all the input |
| 21:26 | <rgervais2> | appreciated |
| 21:27 | <AryehGregor> | Yay, split-up version: http://dvcs.w3.org/hg/html/raw-file/41dfca6a6630/tests/submission/AryehGregor/reflection/reflection-metadata.html |
| 21:28 | karlcow | was wondering what was making the CPU high |
| 21:29 | <karlcow> | this is the document of AryehGregor. |
| 21:29 | <karlcow> | Interesting |
| 21:29 | <AryehGregor> | Hmm? |
| 21:30 | <karlcow> | AryehGregor: the document makes my CPU hot for a little while then once the page has been created. it is ok. back to normal. |
| 21:31 | <jgraham> | Oh, it's a silly bug |
| 21:31 | <karlcow> | my normal being usually high 25%. because of my too many tabs |
| 21:31 | <jgraham> | The harness times out |
| 21:32 | <karlcow> | aah |
| 21:32 | <Ms2ger> | That makes sense |
| 21:32 | <jgraham> | Yeah |
| 21:33 | <Ms2ger> | Mochitest has a way to request a longer timeout ;) |
| 21:33 | <jgraham> | So all_done() is false and the load event hasn't fired |
| 21:33 | karlcow | who thought that he could claim that AryehGregor was making me hot |
| 21:33 | <karlcow> | damn |
| 21:33 | <jgraham> | You can request a longer timeout |
| 21:34 | <Ms2ger> | Even better |
| 21:34 | <jgraham> | do setup({timeout:whatever}) |
| 21:34 | <jgraham> | where whatever is in ms |
| 21:34 | <Ms2ger> | Oh, new things |
| 21:35 | <AryehGregor> | Is that "timeout" instead of timeout? |
| 21:35 | <jgraham> | Not sure what the best way to fix the bug that if it times out and the load event hasn't fired, we don't report anything |
| 21:35 | <jgraham> | AryehGregor: Either is fine |
| 21:36 | <Ms2ger> | You could add the completion callback earlier |
| 21:36 | <AryehGregor> | Interesting, I didn't know JS allowed that. |
| 21:36 | <karlcow> | http://www.w3.org/mid/4D5AF12E.5010808⊙gd |
| 21:36 | <jgraham> | Yeah, I could, but the log element might not be avaliable |
| 21:36 | <TabAtkins> | JSON is stricter than JS. |
| 21:36 | <Ms2ger> | And then check if there's a div#log when the callback is run |
| 21:37 | <jgraham> | Yeah, that seems sensible |
| 21:37 | <AryehGregor> | Magic. |
| 21:39 | <karlcow> | indeed a lot better |
| 21:41 | <AryehGregor> | Should I make each reflects() a test and each assertion an assertion, or leave each assertion as its own test? |
| 21:41 | <AryehGregor> | Hmm. |
| 21:41 | <AryehGregor> | I'm inclined toward the latter, actually. |
| 21:42 | <AryehGregor> | It makes it kind of useless to debug, since browsers will fail most of the tests and one assertion's failure will mask another's, but that's why I have the original version. |
| 21:42 | <AryehGregor> | Opinions? |
| 21:43 | <AryehGregor> | Actually, that would probably make it fast enough that the one-page version would be usable. :) |
| 21:45 | <Ms2ger> | Former |
| 21:47 | <AryehGregor> | I meant I was inclined toward the former. |
| 21:47 | <AryehGregor> | Not the latter. |
| 21:47 | <AryehGregor> | Why do you prefer the former too? |
| 22:00 | AryehGregor | discovers he has no idea how "this" actually works |
| 22:01 | <zewt> | the general rule of thumb for "this" is: however you want it to work, that's how it doesn't |
| 22:04 | <Ms2ger> | AryehGregor, you can use var t = async_test(msg); t.step(function, this); t.done() |
| 22:18 | jgraham | wonders why AryehGregor needs to know how "this" works |
| 22:19 | <jgraham> | The general rule is that "this" is the global object unless you call something like foo.bar in which case it is foo |
| 22:19 | <jgraham> | Or you are in an event handler |
| 22:19 | <jgraham> | Or you were called with Function.prototype.[call|apply] |
| 22:19 | <jgraham> | In the latter case it can be almost anything |
| 22:41 | <TabAtkins> | http://getinpulse.com Will someone please port a browser to this thank you very much. |
| 22:42 | <TabAtkins> | Or at least an HTML rendering engine. |
| 22:44 | <jgraham> | TabAtkins: I think you might be better off asking for something like Opera Mini |
| 22:44 | <TabAtkins> | That would work too, I suppose. |
| 23:06 | <jwalden> | idle question for the masses, what should |var pm = otherWindow.postMessage; setTimeout(pm, 0, ...);| do? send a message? with what source? |
| 23:09 | <Dashiva> | The script triggering the setTimeout is the same script that would have called it directly, so I don't see that source would change |
| 23:11 | <jwalden> | postMessage would be called without any actual calling script, tho |
| 23:11 | <bga_> | jwalden this is eq pm.call(window, undefined, undefined) |
| 23:11 | <jwalden> | bga_: not quite; there you have a calling script, the other case it's called from nothingness |
| 23:12 | <bga_> | i mean input arguments |
| 23:13 | <bga_> | and `this` |
| 23:14 | <bga_> | ah `setTimeout(pm, 0, ...)`; |
| 23:14 | <Ms2ger> | jwalden, it would be called with window as its this object, not otherWindow, AIUI |
| 23:14 | <bga_> | but `this` will be `window` or `null` anyway |
| 23:16 | <jwalden> | Ms2ger: the concern is not |this|. it's that, supposing there's an event handler in otherWindow to receive the message, what should |e.source| be? |
| 23:16 | <jwalden> | and how would that value be computable when postMessage is actually called? |
| 23:16 | <Ms2ger> | I assume window, without seeing the spec |
| 23:16 | <jwalden> | this is fundamentally a form of dynamic scoping |
| 23:17 | <jwalden> | but if there's no dynamic scope to look at, because it's via setTimeout... |
| 23:20 | <bga_> | hm |
| 23:20 | <bga_> | "setTimeout(function, milliseconds) |
| 23:20 | <bga_> | This method calls the function once after a specified number of milliseconds elapses, until canceled by a call to clearTimeout. The methods returns a timerID which may be used in a subsequent call to clearTimeout to cancel the interval." |
| 23:21 | <bga_> | setTimeout with extra arguments is not standard |
| 23:21 | <Ms2ger> | It isn't? Please file a bug :) |
| 23:23 | <bga_> | no. :) extra arguments is bad. this task for closure |
| 23:23 | <bga_> | or .bind |
| 23:29 | <hober> | Right, so I'm at Apple now. whoo! |
| 23:30 | <othermaciej> | hober: congratulations on being acquired |
| 23:30 | <hober> | heh |
| 23:32 | <Hixie> | rgervais: going back to the earlier conversation, we're not going to change the spec willy nilly -- if something is valid, it's going to stay valid |
| 23:32 | <Hixie> | rgervais: at least as much as if the spec was "final" like HTML4 |
| 23:50 | <karlcow> | "Ugh. HTTP and HTTPS are same origin to MSIE for localStorage and sessionStorage checks. In Firefox, only sessionStorage is borked." – http://twitter.com/lcamtuf/status/37626661981650944 |
| 23:54 | <TabAtkins> | Um, what? setTimeout with extra arguments is defined in HTML. |
| 23:54 | <Hixie> | hm? |
| 23:54 | <gsnedders> | setTimeout with any arguments is defined in HTML. |
| 23:54 | <TabAtkins> | to bga |
| 23:55 | <TabAtkins> | gsnedders: I meant extra as in "in addition to the normal two". |
