| 00:52 | <Hixie> | does anyone implement text-align: "." yet? |
| 00:52 | <TabAtkins> | No. |
| 00:52 | <Hixie> | we should really do something about that |
| 00:53 | <TabAtkins> | Agreed. |
| 00:53 | <Hixie> | do you know what spec it's in |
| 00:53 | <Hixie> | ? |
| 00:53 | <TabAtkins> | Text. |
| 00:53 | <Hixie> | thanks |
| 00:53 | <aho> | what's that supposed to do? |
| 00:54 | <TabAtkins> | It does some magic to make things line up on the first occurence of the specified string. |
| 00:54 | <aho> | o_O |
| 00:54 | <TabAtkins> | It only works on table cells. |
| 00:54 | <aho> | o_O² |
| 00:55 | <TabAtkins> | Well, there's no sane way to do it outside of a table-cell. |
| 00:55 | <TabAtkins> | http://dev.w3.org/csswg/css3-text/#text-align |
| 00:55 | <aho> | trust me, it also doesn't sound sane if you throw table cells into the mix :> |
| 00:55 | <TabAtkins> | Check the example. It does. |
| 00:57 | <aho> | hm |
| 00:58 | <aho> | i'd write "$85.00" and i'd prefer if that "N/A" would be right aligned as well |
| 00:58 | <TabAtkins> | Hm, I don't understand the use-case for text-align-first. |
| 00:59 | <TabAtkins> | Okay, then you just use "right" as the value. |
| 00:59 | <aho> | yes |
| 01:02 | <aho> | text-align-last looks kinda pointless to me... and i don't get text-align-first at all |
| 01:02 | <TabAtkins> | Aligning the last line of a paragraph differently is relatively common. |
| 01:03 | <aho> | i only read technical books (they don't do anything fancy) and stuff on the internet (even less fancy) |
| 01:08 | <aho> | white-space-collapsing... weird. tab-size... woo! :> |
| 01:09 | <zewt> | tab-size is :| evil |
| 01:10 | <aho> | yes, tab-size should be always 4 ;) |
| 01:10 | <TabAtkins> | zewt: Um? |
| 01:10 | <zewt> | (I spend so much time teaching confused people that tab-size is always 8 in text files and must never, ever be changed) |
| 01:10 | <zewt> | (and yeah I know HTML != plain text files) |
| 01:10 | <TabAtkins> | zewt: Why are you teaching people badwrong things? |
| 01:11 | <aho> | 99% use 4 though |
| 01:11 | <aho> | :> |
| 01:11 | <TabAtkins> | I use 3. ^_^ |
| 01:11 | <aho> | HERETIC! :v |
| 01:11 | <zewt> | yeah I'll just change the tab stop in my terminal every time I view a file written for broken hard tab widths :P |
| 01:11 | <TabAtkins> | I just need it as small as possible while still being easy to tell what nesting level I'm on. 2 is too small, 3 isn't. |
| 01:11 | <zewt> | TabAtkins: that's the common confusion |
| 01:11 | <zewt> | the width of the tab stop != how far you indent your code |
| 01:12 | <TabAtkins> | zewt: Um, yes it is. You indent with tabs. Thus, by definition, the size of the tab is how far you indent your code. |
| 01:12 | <zewt> | people change the former when they mean to change the latter, leading to broken text files in everything else |
| 01:12 | <TabAtkins> | If you're indenting with spaces, you are badwrong. |
| 01:12 | <zewt> | i indent with whatever vim feels like indenting with; it doesn't really matter to me |
| 01:12 | <TabAtkins> | zewt: Then you're part of the problem, most likely. |
| 01:13 | <zewt> | (unless I'm editing code that uses spaces, in which case I'll :set et for consistency) |
| 01:13 | <TabAtkins> | Just teach people to use editors that use tabs. |
| 01:13 | <TabAtkins> | Not stupid broken ones that convert to spaces automatically. |
| 01:13 | <zewt> | hard tabs are 8 spaces; anything else looks wrong in everything that's not a specially-configured text editor. |
| 01:13 | <TabAtkins> | Um, what? No, that's nonsense. 8-space tabs are almost always GIGANTONORMOUS. |
| 01:14 | <zewt> | and the idea of having to reconfigure your environment every time you edit a file authored for a different tab width is, well, a bit insane :P |
| 01:14 | <TabAtkins> | Again, I have no idea why you're claiming any reconfiguring has to happen? What problem are you talking about? |
| 01:14 | <zewt> | code written for ts=4 viewed in a ts=8 environment invariably looks completely broken. |
| 01:14 | <aho> | the vast majority of people use a tab size of 4 though :> |
| 01:14 | <TabAtkins> | No, no it doesn't, unless you do it wrong. |
| 01:14 | <aho> | 8 is notepad |
| 01:15 | <TabAtkins> | Where "wrong" = using tabs for alignment as well as indentation. |
| 01:15 | <aho> | everything else is 4 by default :> |
| 01:15 | <zewt> | 8 is *, the only thing I've ever seen that defaults to ts=4 is msvc |
| 01:15 | <zewt> | aho: have you ever used, err, a terminal? :P |
| 01:15 | <TabAtkins> | You indent with tabs, and then align with spaces. Simple, obvious rule. |
| 01:15 | <AryehGregor> | A tab size of 8 is reasonable if you're actually using tabs for tabulation instead of abusing them for indentation. |
| 01:16 | <AryehGregor> | 4 is way too small for tabulation. |
| 01:16 | <aho> | isn't using spaces for indentation even more abuse? |
| 01:16 | <TabAtkins> | I disagree on that count - *no* static tab length is appropriate for tabulation. |
| 01:16 | <AryehGregor> | It is if you're just tabulating small numbers, for instance. |
| 01:16 | <TabAtkins> | You either want tables, or elastic tab stops. |
| 01:16 | <AryehGregor> | Then 8 is plenty. |
| 01:16 | <AryehGregor> | Elastic tab stops would be better, yes. |
| 01:17 | <zewt> | i can't count the number of times I've opened a source file, found myself in a jagged zig zag mess, cursed and had to fiddle with ts values to figure out what the author was using |
| 01:17 | <TabAtkins> | AryehGregor: Sure, and then the moment you use a string more than 7 characters, your entire table is messed up. |
| 01:17 | <TabAtkins> | zewt: That's becasue the author was doing it wrong. |
| 01:17 | <TabAtkins> | I assure you that you can read the files I write in *any* tab-size. |
| 01:17 | <TabAtkins> | (Well, not 0.) |
| 01:17 | <zewt> | if you use ts=8, then there's no such thing as "doing it wrong"; no matter how you do it, it'll render correctly. |
| 01:18 | <TabAtkins> | zewt: Except that "correctly" here actually means "with GIGANTONORMOUS GAPS". |
| 01:18 | <TabAtkins> | Which is ugly and hard to read. |
| 01:18 | <zewt> | good luck trying to teach people in varying environments and editors you've never used yourself "put ^I here and spaces here", heh |
| 01:18 | <zewt> | no, once again, ts != sw |
| 01:18 | <TabAtkins> | As long as your editor isn't broken (which means inserting spaces when you hit "Tab"), the rule is trivial and easy. |
| 01:18 | <zewt> | any decent programmer's editor lets you set the number of spaces to indent independently from the tab stop |
| 01:19 | <aho> | (sorry for starting this) :I |
| 01:19 | <zewt> | aho: holy war go! |
| 01:19 | <TabAtkins> | zewt: How are you distinguishing indentation from tabstops here? They're both created by pressing "Tab". |
| 01:20 | <zewt> | ... do you know how to use vim? |
| 01:20 | <TabAtkins> | No, why would I? I use a real text editor. ^_^ |
| 01:20 | <zewt> | not rising to that bait :P |
| 01:20 | <zewt> | one holy war at a time |
| 01:20 | <TabAtkins> | (Note: not emacs) |
| 01:21 | <aho> | well, css3-text surely looks a lot more complicated than the last time i looked at it |
| 01:21 | <aho> | half of it is giving me a serious headache |
| 01:22 | <aho> | hyphenation is somewhat interesting though... finally a use for text-align:justify :> |
| 01:22 | <zewt> | if I set sw=4 sts=4, pressing tab once inserts 4 spaces; pressing it again replaces it with a tab. it works fine, and renders reliably. |
| 01:23 | <aho> | invisible magic |
| 01:23 | <aho> | not cool :) |
| 01:23 | <zewt> | hardly magic |
| 01:23 | <TabAtkins> | So do you indent with the 4 spaces, or the tab? |
| 01:23 | <aho> | and is that a tab or 4 spaces? |
| 01:23 | <zewt> | i don't have to think about what it's doing; I know it's doing something reasonable and I spend my time thinking about the code I'm writing. heh |
| 01:24 | <TabAtkins> | If you're not thinking about it, then you're probably writing code that will look bad in my editor. |
| 01:25 | <zewt> | i'll probably start defaulting to expandtabs (uses only spaces, not tabs), just because it's what most people use in Python |
| 01:25 | <zewt> | if your editor is set to 4-space tabs, then it's your editor's fault, not my code's. |
| 01:25 | <TabAtkins> | Yes, it is your fault. Tabs are supposed to be size-agnostic, and treating them as a certain size is harmful. |
| 01:26 | <zewt> | no, they're not supposed to be size-agnostic. tabs in plain text files are 8 spaces apart. |
| 01:26 | <AryehGregor> | I have vim set up to do expandtabs for Python only. |
| 01:26 | <AryehGregor> | No, tabs are a user-configurable number of spaces. |
| 01:26 | <zewt> | no, tabs are 8 spaces. |
| 01:26 | <AryehGregor> | Pretending they're always 8 is just silly. |
| 01:26 | <TabAtkins> | So, dude, we're disagreeing on the most fundamental point here. You're wrong, unfortunately. |
| 01:26 | <AryehGregor> | Not in my text editor. |
| 01:26 | <AryehGregor> | I have them set to 4. |
| 01:26 | <zewt> | (we could bang our heads on this all night; I'm pretty sure we already know where we disagree, so maybe we should move on :) |
| 01:26 | <aho> | you mean... some old school text editors use a tab size of 8 by default...yes |
| 01:26 | <AryehGregor> | MediaWiki's style guidelines officially say they're 4, in MediaWiki code. |
| 01:26 | <aho> | but every semi-recent one uses a default of 4 |
| 01:27 | <AryehGregor> | It is factually incorrect to say that text editors always render tabs as eight spaces. |
| 01:27 | <AryehGregor> | That is quite demonstrably false. |
| 01:27 | <zewt> | text editors are only one consumer of text files. again, terminals. |
| 01:27 | <aho> | notepad does and uhm... edit.com perhaps |
| 01:27 | <AryehGregor> | Yes, terminals are always eight spaces. |
| 01:27 | <AryehGregor> | Also browsers. |
| 01:27 | <AryehGregor> | And some text editors. |
| 01:27 | <AryehGregor> | But other text editors are four spaces. |
| 01:27 | <aho> | browsers, yes. for legacy reasons :> |
| 01:27 | <AryehGregor> | So it's not reliable, they can be different sizes. |
| 01:27 | <zewt> | (well, tab-size, which is how we got on this in the first place, heh) |
| 01:28 | <AryehGregor> | As TabAtkins says. |
| 01:29 | <zewt> | text editors that default to anything else have a broken default, probably due to being half-baked editors that can't separate presentation of tabs from the underlying file format. |
| 01:29 | <aho> | most people use ts 4 |
| 01:29 | <aho> | most people like ts 4 |
| 01:30 | <aho> | hence ts 4 is the default |
| 01:30 | <aho> | that's how defaults work |
| 01:30 | <zewt> | if so, then most people don't understand tabs. (which itself doesn't seem like an unlikely case) |
| 01:30 | <TabAtkins> | zewt: Your statement is inconsistent. You claim that defaulting to anything other than 8 is a broken default, and then claim that this means they can't separate separation from the underlying format. |
| 01:30 | <zewt> | what? |
| 01:31 | <aho> | exactly |
| 01:31 | <TabAtkins> | The separation of presentation from underlying data is *precisely why* tabs are variable-size. |
| 01:31 | <AryehGregor> | Just because you think the default in some text editors is broken doesn't mean it's not there. |
| 01:31 | <TabAtkins> | If an editor inserts spaces when you press Tab, or won't let you change the visual size of tabs, the editor is broken and doing things wrong. |
| 01:31 | <zewt> | uh, no. any decent text editor lets you press tab and cause a configurable amount of whitespace to appear, regardless of how it's represented in the underlying file. |
| 01:32 | <TabAtkins> | The correct amount of whitesapce that should appear is "one tab". |
| 01:32 | <TabAtkins> | On account of that's the key you pressed. |
| 01:32 | <AryehGregor> | The reality is, your tabs will display in variable widths, and if you aim to accommodate all common ways of viewing your source code instead of deciding you'll ignore many popular text editors, you have to plan for your tabs to be viewed in multiple widths. |
| 01:32 | <AryehGregor> | At least four and eight spaces. |
| 01:32 | <AryehGregor> | TabAtkins, not according to, e.g., most Python programmers. |
| 01:32 | <AryehGregor> | Conventions vary. |
| 01:32 | <TabAtkins> | AryehGregor: Unfortunately, that PEP is badwrong. ^_^ |
| 01:32 | <AryehGregor> | Some people prefer spaces for indentation because they display consistently. |
| 01:32 | <AryehGregor> | Which is a good argument. |
| 01:33 | <AryehGregor> | But they're more annoying to backspace in a typical editor, that's the major problem I have with them. |
| 01:33 | <zewt> | the tab key means "insert an amount of space to move the visual column to a multiple of some number". it certainly doesn't have to mean "insert a ^I"; most people don't even know what that means. |
| 01:33 | <TabAtkins> | No, it's a bad argument, because their code isn't consistent with my code. |
| 01:33 | <AryehGregor> | (I'm sure I can configure vim somehow to backspace them properly, but I haven't looked into it.) |
| 01:33 | <zewt> | heh, the thing that I hate about PEP-8 is how it actually tells people to wrap code at 80 columns : | |
| 01:33 | <TabAtkins> | Where "my code" can be substited for "arbitrary other code that uses a different tab width". |
| 01:34 | <zewt> | leading to \ |
| 01:34 | <zewt> | code that \ |
| 01:34 | <zewt> | looks like \ |
| 01:34 | <zewt> | this |
| 01:34 | <TabAtkins> | zewt: People don't have to understand what tabs do. Inserting a tab does exactly what you say. |
| 01:35 | <zewt> | yes: insert whitespace so the column number is a multiple of some number. |
| 01:35 | <TabAtkins> | Sigh. Don't pretend like you misunderstood me. |
| 01:36 | <zewt> | i'm not, i'm pointing out that "what you say" and "what I say" are (evidently) not the same thing |
| 01:36 | <TabAtkins> | Inserting a tab makes the column number a multiple of the tab width. |
| 01:37 | <zewt> | but the tab width (8) doesn't have to -- okay let's stop going in circles because we both know the radius of the circle is not going to decrease, heh |
| 01:37 | <TabAtkins> | This is different from inserting spaces, because the tab width can change, and the start-location of the whitespace (and thus the distance to the next multiple of the tab width) can as well. |
| 01:37 | <TabAtkins> | Thus, inserting spaces is a broken behavior. |
| 01:38 | <TabAtkins> | It is in my best interest to convince you of my position, because you are apparently in a position to teach others, and I'd rather read code that is properly indented and aligned in the future. |
| 01:39 | <zewt> | and I say precisely the same thing to you, and neither seems likely to happen |
| 01:39 | <TabAtkins> | You are making false statements, though, such as the statement that a tab-size of 8 is the most common and/or correct choice. |
| 01:40 | <zewt> | you're claiming that your argument is right by saying my argument is wrong; that's not a very compelling case, heh |
| 01:40 | <AryehGregor> | Why don't you just ignore any prescriptivism and discuss factual questions, like "how can I get my code to display properly in typical editors?" |
| 01:41 | <AryehGregor> | There's no point in discussing whether tab stops "should" be four or eight spaces. |
| 01:41 | <TabAtkins> | If that's what I was saying, you'd be right. Luckily, it's not. I'm stating that your argument is wrong for specific reasons based on factual inaccuracies in your justifications. |
| 01:41 | <AryehGregor> | The reality is, both happen, and if you declare that the many common editors that don't agree with your choice are broken and you don't care about their users, you're a jerk. |
| 01:41 | <zewt> | so you're denying that terminals universally use 8-space tabs? |
| 01:41 | <AryehGregor> | Terminals do. |
| 01:41 | <aho> | worst tab/spaces war ever |
| 01:42 | <AryehGregor> | If you're writing something that's only meant for terminal outputs, like ls, then definitely rely on eight-space tabs. |
| 01:42 | <aho> | this caramel cappuchino is very delicious by the way |
| 01:42 | <AryehGregor> | But not if you expect it to be read in a variety of text editors. |
| 01:43 | <aho> | conversation successfully killed? yes? :) |
| 01:43 | <TabAtkins> | aho: Did you bring enough for everyone? |
| 01:43 | <aho> | bought lots of it |
| 01:43 | <aho> | was a bargain thingy :) |
| 01:43 | <TabAtkins> | Hand it over, then, or else we're continuing the argument. |
| 01:43 | <aho> | 2 bucks instead of 3 |
| 01:43 | <zewt> | can you get some to me while it's hot? |
| 01:44 | <aho> | the hyphenation stuff looks kinda complicated |
| 01:45 | <aho> | loading dictionary thingies in a @font-face like fashion looks a bit like overkill |
| 01:45 | <aho> | but... it's also an amazingly complicated topic |
| 01:45 | <TabAtkins> | How often do you need to load hyphenation dictionaries? |
| 01:46 | <aho> | how often do they change? |
| 01:46 | <aho> | personally i always thought this should be completely offloaded to the browser |
| 01:46 | <aho> | i.e. the browser should take care of that dictionary stuff |
| 01:46 | <aho> | just like it takes care of dictionaries for spellchecking |
| 01:46 | <TabAtkins> | That doesn't help with technical information, for example. |
| 01:47 | <TabAtkins> | Spellchecking is a user issue that should be consistent across the browser. Hyphenation is a display issue for the specific site. |
| 01:47 | <TabAtkins> | That said, I believe browsers are allowed to be smart with default hyphenation, it's just that nobody does it. |
| 01:48 | <aho> | well, there are common words |
| 01:48 | <aho> | like 100k per language |
| 01:48 | <TabAtkins> | (This could be accomplished through hyphenation dicts specified in the UA stylesheet, of course.) |
| 01:48 | <aho> | no need to define how those should be hyphenated over and over again |
| 01:48 | <aho> | yes, some default dictionary... and you can augment that with your own |
| 01:48 | <aho> | e.g. you use 50 unusal words and you want those hyphenated, too |
| 01:49 | <TabAtkins> | Ooh, I think I might finally be ready to publish an ED of flexbox. |
| 01:49 | <TabAtkins> | Let's generate and see. |
| 01:49 | <aho> | woo! flexbox! :D |
| 02:04 | <TabAtkins> | Damn my colorblindness! I can only barely see issues inside of notes, given the default stylesheet. |
| 02:07 | <TabAtkins> | Aw yeah: http://dev.w3.org/csswg/css3-flexbox/ |
| 06:49 | <annevk> | wait what |
| 06:49 | <annevk> | the link relation "up" will be removed from HTML? |
| 06:49 | <annevk> | has the point arrived where I should just nuke most rel attribute usage on my site? |
| 06:56 | <annevk> | AryehGregor, interesting idea; making ProcessingInstruction a CharacterData type |
| 06:56 | <annevk> | AryehGregor, should it inherit from Comment, even? |
| 07:11 | <othermaciej> | annevk: you can always register "up" in your registry of choice |
| 07:12 | <annevk> | I wish the situation was a bit more clear than "do whatever you want" and it "depends on who you ask what it means" |
| 07:14 | <annevk> | At this point it sure seems that the only link relationships I still want to use are those with some tangible benefit. E.g. "stylesheet", "alternate" in combination with type=application/atom+xml, maybe "noreferrer", "nofollow"... |
| 07:15 | <othermaciej> | I do think that in general, it's good to use things in your markup if they have a tangible benefit |
| 07:15 | <annevk> | So why did we keep rel=author? |
| 07:16 | <annevk> | Most relationships make it easier to understand the structure of a site I suppose. But that includes last/first/up/... |
| 07:17 | <othermaciej> | no one made that particular argument against removing them - the focus seemed to be on the very few user agents that expose last/first/up in UI, and on what link types exactly are used by various CMS systems in their templates |
| 07:18 | <annevk> | next/previous are not exactly common either |
| 07:18 | <annevk> | or rel=search |
| 07:19 | <annevk> | oh well, I'm gonna assume that we'll revisit this in a couple of years |
| 07:19 | <annevk> | othermaciej, btw, I wrote up http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html |
| 07:20 | <annevk> | I guess I'll write an email to public-webapps about it now |
| 07:22 | <othermaciej> | annevk: sweet |
| 07:22 | <annevk> | I'm somewhat surprised the allowing cross-origin embedding of fonts is dangerous for security argument is still floating around |
| 07:23 | <othermaciej> | is it? |
| 07:23 | <othermaciej> | I thought I managed to kill that |
| 07:23 | <annevk> | you did, but that it was raised at all |
| 07:23 | <othermaciej> | I explained to everyone on that one telecon that same-origin policy is not a defense against code execution attacks from malware… |
| 07:23 | <annevk> | because it was used a year ago too and I said pretty much the same thing you did |
| 07:24 | <othermaciej> | cargo cult security is apparently a powerful meme |
| 07:30 | <foolip> | Hixie, about http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984 do you plan to investigate further what Microsoft/Mozilla are actually willing to implement, or should I turn it into an ISSUE? |
| 07:31 | <Hixie> | i left the bug open to work out if there was anything we could do |
| 07:31 | <Hixie> | but i'm happy for you to try to solve it for me :-) |
| 07:32 | <foolip> | ugh, I may be a bit too partial to come up with an honest suggestion :) |
| 07:32 | <foolip> | but if you *do* want me to make an ISSUE, you need to close some bug that I disagree with I guess. right, othermaciej? |
| 07:32 | <annevk> | othermaciej, http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0710.html |
| 07:32 | <othermaciej> | foolip: yes, it needs to be resolved to be escalated |
| 07:33 | <annevk> | othermaciej, might help if you weigh in, however brief |
| 07:33 | <othermaciej> | foolip: as far as I am concerned, I think it is fine for Hixie to either WONTFIX it, or to take another crack at a mutually agreeable resolution |
| 07:33 | <Hixie> | othermaciej: you can try to come up with a resultion without using the wg issue process |
| 07:33 | <Hixie> | er |
| 07:33 | <Hixie> | s/othermaciej/foolip/ |
| 07:34 | <foolip> | I don't know how to communicate with Microsoft, so in that case I'd prefer for Hixie to try once more... |
| 07:34 | <Hixie> | i have never successfully managed to communicate with microsoft |
| 07:34 | <foolip> | Hixie, how did you manage to get the statement that I cited in my original CP then? |
| 07:35 | <Hixie> | i mailed them about this very issue months ago and they said that obeying Content-Type was the most stupid thing ever |
| 07:35 | <othermaciej> | foolip: in the case of this bug, you could contact Adrian Bateman directly |
| 07:35 | <Hixie> | foolip: what statement? |
| 07:35 | <othermaciej> | foolip: in general, if Microsoft people fail to reply on something HTML WG related, I have found that asking Paul Cotton often results in a response from somebody over there |
| 07:36 | <foolip> | Hixie, "Microsoft's position is, as far as I can tell, that there's no point looking at the Content-Type header" |
| 07:36 | <Hixie> | ah, yeah, that was what they told me |
| 07:36 | <Hixie> | they then implemented the exact opposite of that, apparently |
| 07:36 | <Hixie> | so like i said |
| 07:36 | <Hixie> | i have never successfully managed to communicate with microsoft |
| 07:36 | <foolip> | ok, true :) |
| 07:37 | <Hixie> | given how much it would help microsoft for me to be able to make the spec match what they want, you'd think they'd be more communicative |
| 07:38 | <annevk> | haha |
| 07:38 | <annevk> | you must be new here |
| 07:53 | <foolip> | Hixie, ok, I made a naive attempt at friendly dialog |
| 07:59 | <annevk> | othermaciej, I guess abarth would have to explain the CSP angle |
| 08:04 | <abarth> | the CSP angle of? /me is missing context |
| 08:05 | <annevk> | see latest in public-webapps |
| 08:05 | <annevk> | sorry |
| 08:07 | <abarth> | ah, i see |
| 08:07 | <abarth> | sure |
| 08:13 | <othermaciej> | it does vaguely fit with the CSP theme of denying actions that are normally allowed |
| 08:13 | <othermaciej> | but other than that, I don't get it |
| 08:16 | <abarth> | i'm writing up a reply for the mailing list |
| 08:16 | <abarth> | its a lot like frame-ancestors |
| 08:17 | <abarth> | aside from the aesthetic questions |
| 08:17 | <abarth> | From-Origin is probably going to want to designate a list of origins that can embed the resource |
| 08:17 | <abarth> | which is something CSP has syntax for |
| 08:20 | <annevk> | it does allow a list of origins atm |
| 08:20 | <annevk> | that's what # means |
| 08:20 | <annevk> | subtle, but true :) |
| 08:20 | <abarth> | what about wildcarding? |
| 08:20 | <annevk> | but it does not allow the wild card matching of CSP |
| 08:21 | <abarth> | so, that's similar, but slightly different than CSP |
| 08:21 | <abarth> | which seems like a loss in terms of extra complexity |
| 08:22 | <annevk> | I modeled it after CORS |
| 08:22 | <abarth> | can you have a list of Origins in CORS? |
| 08:22 | <annevk> | not yet |
| 08:23 | <annevk> | but it can be quite easily added in the future |
| 08:23 | <abarth> | its entirely likely the best solution here is to decide that a Content-Security-Policy header doesn't make sense |
| 08:23 | <annevk> | and it would follow the design of From-Origin |
| 08:23 | <abarth> | and instead we should have separate headers for the different CSP use cases |
| 08:23 | <annevk> | hey I don't know either :) |
| 08:23 | <annevk> | just trying to defend my design decisions :) |
| 08:24 | <annevk> | abarth, that does sound better |
| 08:24 | <annevk> | less <input> and <object>, more <canvas>, <video>, etc. |
| 08:24 | <abarth> | yes |
| 08:24 | <abarth> | i suspect the mozilla folks will be less excited about that approach |
| 08:24 | <abarth> | although it would be fine with me |
| 08:25 | <abarth> | they have this thought process around "Default deny" begin a good starting point |
| 08:25 | <abarth> | but i'm skeptical about how that will evolve in the future |
| 08:30 | <othermaciej> | a "default deny everything" starting point pretty clearly cannot accommodate future things one might want to deny |
| 08:31 | <abarth> | yeah, i've said that to the moz folks in every meeting we've had on this topic |
| 08:32 | <abarth> | i'm not really sure where the miscommunication is |
| 08:33 | <othermaciej> | what is their response to this line of argument? |
| 08:33 | <othermaciej> | I could imagine: |
| 08:34 | <othermaciej> | (a) few sites will use CSP, so we'll just break them |
| 08:34 | <othermaciej> | (b) a current set will be default-deny, but future things will be default-allow |
| 08:34 | <othermaciej> | (c) we'll never think of anything new |
| 08:34 | <othermaciej> | (d) versioning |
| 08:35 | <othermaciej> | none of those sound great |
| 08:35 | <abarth> | i think part of their thinking is that they've enumerated all the ways web pages can load resources |
| 08:35 | <abarth> | and that subresource loads are the most important thing for security |
| 08:36 | <abarth> | as they add new kinds of subresource loads |
| 08:36 | <abarth> | they'll remember to add them to the default-deny |
| 08:36 | <abarth> | so there will never exist a version of Firefox that allows them by default |
| 08:37 | <abarth> | when i push back and say that there's more to security than subresource loads, they usually say something like (b) |
| 08:37 | <abarth> | that's also connected with their sadness about me only wanting to do the script parts |
| 08:37 | <abarth> | because that doesn't square with their mental model of controlling all subresources |
| 08:39 | <othermaciej> | preventing yourself from accidentally loading offsite images does not seem like it would be a concern for most sites |
| 08:41 | <abarth> | i usually use the example of off-site fonts |
| 08:41 | <othermaciej> | more likely vice versa (i.e. prevent people from hotlinking your images) but that doesn't seem to me to really fit in with the existing CSP policies |
| 08:42 | <othermaciej> | interestingly, fonts are also a case where you are cub more likely to want to prevent others hot linking them from your site than to want to prevent accidental embedding |
| 08:42 | <othermaciej> | in the case of images specifically though, it is a very likely use case to want to allow embedding images from anywhere, while limiting possible origins for scripts to a whitelist |
| 08:44 | <abarth> | the script / XSS use case is pretty compelling to me |
| 08:44 | <abarth> | enough that I want to implement it |
| 08:45 | <abarth> | but I don't want to implement gratuitously different from Firefox |
| 08:46 | <abarth> | that leaves me with the task of trying to win brandon and co over to my perspective |
| 08:48 | <abarth> | they seem excited about implementing restrictions on lots of things that don't seem that useful (e.g., images, fonts) |
| 08:48 | <abarth> | my current approach is to set things up so we can implement a subset of the features |
| 08:48 | <abarth> | e.g., script controls |
| 08:48 | <abarth> | and then decide later whether to implement more |
| 08:49 | <annevk> | othermaciej, replied to your questions on changes |
| 08:49 | <othermaciej> | that does seem like a sensible approach |
| 08:49 | <annevk> | guess I should now read this chatbacklog :) |
| 08:51 | <annevk> | I do agree that I never really saw the point in all the options they had |
| 08:52 | <annevk> | but I guess they are afraid of the site having some kind of XSS hole and leaking information to an external site? |
| 08:52 | <othermaciej> | annevk: I guess I will have to do some research to understand some of those |
| 08:52 | <abarth> | annevk: they agree that we can't stop leaking information |
| 08:52 | <othermaciej> | in what way was Event.type formerly restricted? |
| 08:52 | <annevk> | othermaciej, it could not be empty |
| 08:53 | <othermaciej> | do implementations let it be empty? |
| 08:53 | <annevk> | euh |
| 08:53 | <annevk> | not sure what happened |
| 08:53 | <annevk> | but yes, in Gecko it can be empty |
| 08:53 | <annevk> | you can register event listeners for empty event names too |
| 08:53 | <annevk> | the only trick is that you need to use initEvent() currently |
| 08:54 | <annevk> | otherwise getting Event.type throws |
| 08:54 | <annevk> | which is just kind of silly and a restriction I removed from DOM Core |
| 08:54 | <othermaciej> | it seems like most of the listed changes are either trivial, or compatible extensions |
| 08:55 | <annevk> | removing EventException and changing the details around stop propagation and canceling are probably the more problematic ones |
| 08:55 | <annevk> | well, incompatible ones |
| 08:56 | <annevk> | zewt wrote http://zewt.org/~glenn/test-event-flags/ to figure out what will make the most sense with the stop propagation and canceled flags |
| 08:59 | <othermaciej> | interesting, I am mildly surprised to discover that Gecko and WebKit do not match on those things |
| 09:00 | <annevk> | when I started looking into events I was surprised to find many holes |
| 09:01 | <annevk> | I'm starting to wonder if you need to write specs "Hixie-style" to prevent getting them |
| 09:01 | <annevk> | I mean something as simple as var e = document.createEvent("Event"); alert(e.eventPhase) or alert(e.type) is undefined |
| 09:02 | <annevk> | Did nobody ever think of that? |
| 09:02 | <annevk> | How can this be? |
| 09:02 | <othermaciej> | the only WebKit/Gecko difference is in the last two tests and the Gecko behavior seems more sensible |
| 09:02 | <othermaciej> | it does seem strange for that behavior to be undeinfed |
| 09:07 | <annevk> | it seems that the "canceled flag" should be reset just before dispatching |
| 09:08 | <annevk> | and that the "stop propagation flag" and "stop immediate propagation flag" should be reset just after dispatching |
| 09:08 | <annevk> | but that doesn't explain this one: "Calling preventDefault before dispatch prevents the default action from running: yes (DOM Events) " |
| 09:09 | <annevk> | which seemingly contradicts "If preventDefault was called during a previous dispatch of an event, dispatching the event again resets defaultPrevented to false: yes (DOM Events, DOM Core) " |
| 09:09 | <annevk> | in combination with "defaultPrevented is retained after dispatchEvent returns: yes (DOM Core) " |
| 09:09 | <annevk> | I don't get how those can be all "yes" in Minefield |
| 09:15 | <othermaciej> | does preventDefault ever have any effect when called while the event is not being dispatched? |
| 09:16 | <othermaciej> | I guess the answer must be yes |
| 09:16 | <othermaciej> | proposed test case: dispatch an event, then call preventDefault on it, then dispatch again |
| 09:16 | <annevk> | that is the second statement above |
| 09:16 | <othermaciej> | no it's not |
| 09:17 | <othermaciej> | let me be more clear |
| 09:17 | <othermaciej> | dispatch an event, after dispatchEvent returns call preventDefault on it, then call dispatchEvent again |
| 09:17 | <annevk> | oh sorry |
| 09:18 | <othermaciej> | my working theory is that dispatchEvent resets an event's flags only if the event has been dispatch before |
| 09:18 | <othermaciej> | but it's also possible there is something magic about changing flags while it is not being dispatched |
| 09:19 | <annevk> | it would be much simpler to always reset them at some point |
| 09:19 | <annevk> | but resetting canceled at the end has the side effect of making defaultPrevented useless after dispatch |
| 09:20 | <annevk> | and resetting it upfront breaks prevents canceling an event before dispatch (only relevant for synthetic events though) |
| 09:21 | <annevk> | another thing I wonder about is whether there's currently a difference between UA-fired and synthetically-fired events |
| 09:21 | <annevk> | I got the impression there was |
| 09:22 | <othermaciej> | in WebKit there is not, as far as dispatch logic is concerned, anyway |
| 09:22 | <othermaciej> | some event default actions may require a real UA-fired event |
| 09:23 | <annevk> | yeah, that is the "trusted flag" |
| 09:23 | <zcorpan> | Rik`, hsivonen, MikeSmith: http://krijnhoetmer.nl/irc-logs/whatwg/20110228#l-738 seems like a bug in v.nu |
| 09:23 | <annevk> | only set for spec-fired events |
| 09:23 | <annevk> | and unset when a spec-fired event is dispatched again manually |
| 09:24 | <hsivonen> | zcorpan: oh, I didn't realize it was about v.nu |
| 09:26 | <othermaciej> | you can see our overall tree dispatch logic here: |
| 09:26 | <othermaciej> | http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Node.cpp#L2644 |
| 09:26 | <othermaciej> | per-target dispatch logic starting here: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/EventTarget.cpp#L287 |
| 09:26 | <othermaciej> | (most of the interesting stuff is down in fireEventListeners) |
| 09:27 | <othermaciej> | it should be really easy to follow, unlike Gecko's event dispatch, at least last time I looked |
| 09:27 | <othermaciej> | UA-fired events go through dispatchEvent() |
| 09:27 | <annevk> | "return !event->defaultPrevented();" shouldn't that be the opposite? |
| 09:28 | <hsivonen> | http://my.opera.com/core/blog/2011/02/28/webgl-and-hardware-acceleration-2 is interesting |
| 09:28 | <annevk> | hmm, that !event pattern is more common |
| 09:28 | <hsivonen> | I wonder how Opera has dealt with the Linux driver situation |
| 09:29 | <hsivonen> | and the driver situation on Windows, too |
| 09:29 | <othermaciej> | it is entirely possible our dispatchEvent return value is backwards |
| 09:29 | <hsivonen> | and text rendering |
| 09:30 | <annevk> | othermaciej, it seems like it is, yes |
| 09:31 | <annevk> | othermaciej, seems like a copy and paste mistake on closer reading |
| 09:31 | <annevk> | othermaciej, if I had the WebKit tree here I would give you a patch to remove that ! |
| 09:31 | <annevk> | (zewt's test confirms this bug fwiw) |
| 09:31 | <othermaciej> | annevk: I would do it myself, but I need to check all the callers first |
| 09:32 | <othermaciej> | hmm, I think it is right |
| 09:32 | <othermaciej> | If Event.preventDefault() was called the returned value shall be false, else it shall be true. |
| 09:32 | <othermaciej> | says DOM Level 3 Events |
| 09:32 | <jgraham> | Yay, foreign content stuff changed! |
| 09:33 | <othermaciej> | which is what I think "return !event->defaultPrevented();" does - false if default was prevented, otherwise true |
| 09:33 | <annevk> | othermaciej, seems like a bug in DOM 3 Events |
| 09:33 | <annevk> | dispatchEvent should return the value of defaultPrevented |
| 09:33 | <annevk> | not the opposite |
| 09:34 | <othermaciej> | DOM Level 2 Events agrees with Level 3 |
| 09:35 | <othermaciej> | it does appear that DOM Core does the opposite |
| 09:35 | <annevk> | hmm yeah, so maybe a bug in DOM Core then |
| 09:36 | <annevk> | I guess it makes sense |
| 09:36 | <annevk> | and I was incorrect with respect to WebKit being the only one here, everyone does it this way |
| 09:36 | annevk | fixes |
| 09:37 | <othermaciej> | I think the reason for the funky backwardness is like this: |
| 09:38 | <othermaciej> | it is assumed that the caller of dispatchEvent uses the return (if they use it at all) to decide whether to carry out a default action |
| 09:38 | <othermaciej> | so you write: |
| 09:39 | <othermaciej> | if (target.dispatchEvent(event)) defaultAction(target, event); |
| 09:39 | <annevk> | makes sense |
| 09:39 | <annevk> | https://bitbucket.org/ms2ger/dom-core/changeset/6789c290eb6a |
| 09:40 | <othermaciej> | now that's responsiveness :-) |
| 09:42 | <annevk> | zcorpan, could you update the link in http://simon.html5.org/specs/web-dom-core once more? |
| 10:05 | <zcorpan> | done |
| 10:08 | <annevk> | thanks |
| 10:16 | <roc> | abarth|zZz: the conflict between evolution and default-deny for CSP exists for <iframe sandboxed> too |
| 10:18 | <annevk> | zewt, you around? |
| 10:20 | <zcorpan> | oh, so ie9 changed to the other extreme for <video> content-type. fun |
| 10:25 | <roc> | I had resigned myself to giving up on Content-Type, and now I have to think about it again |
| 10:26 | <zcorpan> | it seems like we'd want to sniff for the missing content-type header case at least |
| 10:27 | <MikeSmith> | zcorpan: I fixed that bug a while back. fix is in the repo but validator.nu hasn't been redeployed yet after I made that change |
| 10:27 | <roc> | yeah |
| 10:27 | <zcorpan> | MikeSmith: ok |
| 10:27 | <MikeSmith> | Rik`: (see above about the validator bug you noticed) |
| 10:28 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/853 here is that test Maciej wondered about |
| 10:29 | <annevk> | well, if you comment out the first e.preventDefault() |
| 10:29 | <annevk> | othermaciej, ^^ |
| 10:29 | <annevk> | it seems that both Gecko and WebKit reset just before dispatching |
| 10:31 | <annevk> | or maybe, it only has effect when called during dispatch |
| 10:31 | <annevk> | grmbl |
| 10:33 | <annevk> | oh, it was because I did not make it cancelable |
| 10:34 | <annevk> | it seems what happens is that in Gecko the canceled flag is simply never cleared |
| 10:34 | <Rik`> | MikeSmith: zcorpan: oh thanks, my brain can return to sanity mode |
| 10:35 | <annevk> | even calling initEvent does not make a change |
| 10:35 | <MikeSmith> | Rik`: yeah, sorry about that |
| 10:35 | <annevk> | the same is true in WebKit |
| 10:35 | <annevk> | afaict, again |
| 10:45 | <annevk> | which makes dispatching events again kind of useless |
| 10:46 | <zcorpan> | Rik`: you mean your brain can return false; ? |
| 10:47 | <annevk> | in WebKit stop propagation is not reset either |
| 10:47 | <annevk> | in Gecko it is |
| 10:48 | <annevk> | Opera is like WebKit... |
| 10:48 | <annevk> | so why does the DOM spec says resetting is going on here for historical reasons? smaug? |
| 10:48 | <annevk> | DOM Events spec* |
| 11:03 | <annevk> | emailed www-dom and reported it as a DOM3Events issue |
| 11:03 | <annevk> | lets see how that goes |
| 11:48 | <mpt> | Does anyone have statistics on how often <img> elements have alt=, how often they have title=, how often they have both, and how often they're different? |
| 11:49 | <mpt> | I've looked in <http://code.google.com/webstats/2005-12/elements.html>; and <http://philip.html5.org/data/>; |
| 11:51 | <jgraham> | mpt: You live! also http://dev.opera.com/articles/view/mama-images-elements-and-formats/ might or might not help |
| 11:51 | <jgraham> | Mostly not I guess |
| 11:52 | <mpt> | That at least answers the first two questions |
| 11:52 | <mpt> | thanks jgraham |
| 11:53 | <Philip`> | I can count <img alt>/<img title> easily, but the rest would involve some code |
| 11:53 | <mpt> | I guess so |
| 11:53 | <hsivonen> | I wonder how http://itunes.apple.com/app/opera/id404764921?mt=12 works with security updates |
| 11:55 | <annevk> | jgraham, it's becoming more evident you're not on twitter |
| 11:55 | <jgraham> | annevk: I have a happily empty twitter account |
| 11:57 | <annevk> | is it jgraha or jgraham? |
| 11:58 | <jgraham> | jgraham |
| 11:58 | <annevk> | seems some people found it already :) |
| 11:58 | annevk | follow it too just in case |
| 11:58 | <annevk> | follows* |
| 12:14 | <annevk> | http://www.google.com/search?q=site:annevankesteren.nl&tbm=blg what the hell is that "?q=http://www.evilaliv3.org/"; |
| 12:16 | <karlcow> | strange |
| 12:19 | <annevk> | iTunes does indeed work when stuff is converted to AAC btw o_O |
| 12:20 | <annevk> | though getting album information still requires "importing" which elsewhere it says is done by dragging and dropping |
| 12:20 | <annevk> | bugs... |
| 12:20 | <annevk> | of course you only run into this because Radiohead decided to stick it to Apple |
| 12:21 | <Philip`> | http://www.google.com/support/forum/p/Webmasters/thread?tid=0f1d3b5cf0ac27bb&hl=en |
| 12:21 | <annevk> | so maybe the idea is to create an experience that says "if it's not via us, it's more sucky" |
| 12:21 | <Philip`> | Sounds common |
| 12:29 | <jgraham> | annevk: Apple making the experience worse when using non-Apple content or software? Surely not! |
| 12:37 | <Philip`> | (Has Apple made their touchpad driver for Windows in Boot Camp not incredibly terrible yet?) |
| 13:04 | <karlcow> | wondering if someone did implementation check for NetFront http://www.access-company.com/products/mobile_solutions/netfrontmobile/browser/index.html |
| 13:05 | <karlcow> | it claims "HTML 5 (Partial)" |
| 13:05 | <karlcow> | wonder which parts of HTML 5 |
| 13:06 | <annevk> | there's no HTML 5 :p |
| 13:11 | <zewt> | annevk: catch comments about event name/type/interface terminology? |
| 13:15 | <annevk> | hmm? |
| 13:16 | <annevk> | gonna have lunch + watching californication |
| 13:16 | <annevk> | back in 30 |
| 13:19 | <hsivonen> | karlcow: sure any browser that can browser HTML at all has "partial" HTML5 support |
| 13:44 | <annevk> | zewt, I will catch your comments now |
| 13:45 | <annevk> | well, can |
| 13:48 | <annevk> | I guess I should write a blog post on DOM Core additions |
| 13:48 | <annevk> | see if I can inspire some more feedback |
| 13:58 | <zewt> | annevk: was suggesting that the event name is referred to as the event type (to match DOM Events, and the init*Event prototypes), and the class of the event as the interface (eg. "create an event that uses the MessageEvent interface") |
| 14:02 | <annevk> | but it's not really logical... |
| 14:02 | <zewt> | what isn't? |
| 14:02 | <annevk> | the type is "mouse event" or "progress event", the name is "click", "dblclick" etc. |
| 14:03 | <annevk> | but maybe I should not care about that |
| 14:03 | <zewt> | it's very confusing to refer to the interface as the "type" when the name of the property event.type is something completely different |
| 14:04 | <annevk> | I guess that is fair enough |
| 14:04 | <annevk> | btw http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0054.html |
| 14:04 | <annevk> | I will attempt making that change now |
| 14:05 | <zewt> | for example, eventsource is confusing in "dispatch the event", since in one line it says "with the event name", then in the next step it says "change the type" ... seems like picking consistent terminology is important |
| 14:05 | <zewt> | (less concerned personally with what that terminology is; suggested "type" due to the attribute name and because it already seems widely used) |
| 14:05 | <zewt> | yeah I saw that |
| 14:08 | <annevk> | kind of annoying since the "of type" concept is used quite frequently, but not a huge deal |
| 14:09 | <zewt> | in spec terms are "of type" and "implementing the interface" considered the same? |
| 14:11 | <annevk> | sort of, I guess |
| 14:11 | <annevk> | anyway, not a huge deal: https://bitbucket.org/ms2ger/dom-core/changeset/bf5fa39afb93 |
| 14:11 | <zewt> | not sure if the former means "create this type" and the latter is "create anything implementing this type", or if it's not that precise |
| 14:11 | <annevk> | guess I should also fix XHR/PE |
| 14:11 | <annevk> | oh, XHR is not affected |
| 14:13 | <zewt> | annevk: re Gecko resetting the canceled flag, it seems a little more complex, unless I messed up in my testing |
| 14:14 | <zewt> | there are three effects of resetting the flag on the next dispatch: running the default handler, the return value of dispatchEvent, and the value of defaultPrevented (getPreventDefault) |
| 14:14 | <zewt> | gecko seems to do the first and the last only |
| 14:14 | <zcorpan> | the new terminology for type/interface is better |
| 14:15 | <zewt> | http://zewt.org/~glenn/test-event-flags/ the three preventDefault cases; in FF3.6 I see yes/no/yes |
| 14:15 | <annevk> | zewt, zcorpan, glad you guys like it, please go after all specs :) |
| 14:16 | <annevk> | zewt, note that the return value of dispatchEvent is the opposite of what you might expect |
| 14:16 | <annevk> | zewt, I just fixed that this morning in DOM Core |
| 14:17 | <zewt> | yeah I know |
| 14:17 | <annevk> | zewt, per my testing Gecko's return value for dispatchEvent is consistent with what I'd expect |
| 14:17 | <annevk> | zewt, so maybe you don't negate it first when equality testing? |
| 14:17 | <zewt> | you mean, it's consistent with not resetting the flag, right? |
| 14:18 | zcorpan | finds various "of type" in complete.html |
| 14:19 | <zewt> | (... but going over my other test I'm confused, because FF doesn't execute the default handler at all--so how was I testing that at all in FF? sigh) |
| 14:20 | <annevk> | zewt, dispatchEvent returns !(canceledFlag) basically |
| 14:20 | <annevk> | so if the canceled flag is set, it returns false |
| 14:20 | <zewt> | right, I know the two are inverted |
| 14:21 | <annevk> | so you can if(target.dispatchEvent(event)) defaultAction("teehee") |
| 14:21 | <zewt> | var dispatchEventReportsPreventDefault = !elem.dispatchEvent(ev); |
| 14:21 | <zewt> | var defaultPreventedReportsPreventDefault = ev.getPreventDefault(); |
| 14:21 | <annevk> | okay |
| 14:21 | <zewt> | let me go check what the heck I was doing with default testing though ... since FF appears to never run default handlers for "click" and that's what my test was based on |
| 14:25 | <zewt> | yeah that's what was confusing me |
| 14:28 | <zewt> | ... does FF really not run default handlers for synthesized clicks? i swear I've done that before... |
| 14:29 | <annevk> | might be a security feature |
| 14:29 | <zewt> | misfeature, perhaps |
| 14:30 | <annevk> | not running default handlers based on the trusted flag seems sensible to me |
| 14:30 | <zewt> | but click is an explicit exception to that |
| 14:31 | <annevk> | anyway, I think default handles should follow the normal model |
| 14:31 | <annevk> | handlers* |
| 14:32 | <zewt> | oh, I apparently worked around it manually, setting location.href by hand |
| 14:32 | <zcorpan> | what's a default handler? |
| 14:32 | <annevk> | zcorpan, like following a link |
| 14:32 | <zcorpan> | ok |
| 14:33 | <annevk> | user agent internal event listeners basically |
| 14:33 | <MikeSmith> | annevk: http://www.w3.org/TR/2011/WD-notifications-20110301/ |
| 14:33 | <zewt> | it's also annoying that there's no way of knowing whether a dispatched click event was run |
| 14:33 | <annevk> | MikeSmith, teehee |
| 14:34 | <MikeSmith> | annevk: please take a look again and let me know if you see any problems |
| 14:34 | <MikeSmith> | not published yet… I still have to jump through some pubrules hoops |
| 14:34 | <MikeSmith> | and get systems team to set up the symlink |
| 14:34 | <annevk> | MikeSmith, ah, Notification is still listed under Methods |
| 14:34 | <MikeSmith> | oh, I'll fix that right now |
| 14:35 | <zcorpan> | FPWD? |
| 14:36 | <annevk> | yes |
| 14:36 | <MikeSmith> | annevk: reload |
| 14:36 | <zcorpan> | cool |
| 14:36 | <annevk> | MikeSmith, not all attributes are of type Function |
| 14:36 | <annevk> | replaceId and dir are supposed to be DOMString |
| 14:38 | <zewt> | should iconUrl/title/body be exposed as (maybe readonly) attributes on Notification? |
| 14:38 | <annevk> | and 5.4 defines a bunch of 5.1 more succinctly, but I am not sure it is worth bothering fixing all this now |
| 14:40 | <annevk> | zewt, that's something to bring up on the mailing list |
| 14:41 | <annevk> | MikeSmith, it seems the Function/DOMString thing for replaceId and dir is your fault |
| 14:41 | <annevk> | MikeSmith :/ |
| 14:43 | <annevk> | waking up at 6:30AM makes for being both tired and productive btw |
| 14:43 | <annevk> | recommend trying it at least once |
| 14:43 | <zewt> | "stepping on a tack will make you move really fast" |
| 14:44 | <zewt> | (also swear a lot) |
| 14:44 | <annevk> | http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/ hmm I'm a big spammer |
| 14:52 | <karlcow> | annevk: it's why we are banning you for 3 months starting next week :p |
| 14:52 | <karlcow> | http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/author.html |
| 14:52 | <annevk> | heh |
| 14:52 | <annevk> | compared to some of those other guys I'm not doing that bad it seems |
| 14:53 | <zewt> | that bugzilla guy needs to shut up for a while |
| 14:53 | <annevk> | and Glenn, who is Glenn?! |
| 14:53 | <zewt> | some loser |
| 14:54 | <annevk> | clearly, he has plenty of time to write email :p |
| 14:55 | <zewt> | livin' the life, he is |
| 14:56 | <zewt> | one's "no, really, you don't need to reply to that" filter takes continual upkeep :P |
| 14:57 | <MikeSmith> | annevk: oops |
| 14:57 | <MikeSmith> | annevk: thanks for catching that |
| 14:57 | <MikeSmith> | reload please |
| 14:57 | <MikeSmith> | and let me know if you spot any remaining problems |
| 14:57 | <annevk> | I'm surprised I'm spotting these :) |
| 14:57 | <MikeSmith> | the thing about 5.4 is editorial and John needs to fix that if it's to be fixed |
| 14:58 | <MikeSmith> | I need to spend some quality time with respec at some point |
| 14:59 | <MikeSmith> | frustrating… I actually had a nightmare last night in which I was arguing with Berjon about it |
| 14:59 | <annevk> | MikeSmith, ouch |
| 14:59 | <annevk> | MikeSmith, was he dressed as dahut? |
| 14:59 | <MikeSmith> | heh |
| 14:59 | <annevk> | MikeSmith, looks good now btw |
| 15:00 | <MikeSmith> | no, regular Berjon casual attire |
| 15:00 | <MikeSmith> | thanks |
| 15:00 | <MikeSmith> | validates too |
| 15:00 | <MikeSmith> | I need to add a paragraph to the Status section |
| 15:00 | <MikeSmith> | saying… something |
| 15:00 | <MikeSmith> | any suggestions? |
| 15:00 | <annevk> | MikeSmith, still pretty scary |
| 15:00 | <MikeSmith> | heh |
| 15:01 | <annevk> | MikeSmith, "Although this is an initial draft and we are open to changing the design so far we have not received feedback asking us to do so." |
| 15:02 | <annevk> | but isn't just boilerplate enough? |
| 15:03 | <annevk> | e.g. the only custom paragraph CORS has is all its previous names |
| 15:05 | <MikeSmith> | I don't really know what the purpose of the "custom paragraph" requirement in the sotd is |
| 15:05 | <MikeSmith> | maybe nobody knows |
| 15:05 | <MikeSmith> | anymore |
| 15:06 | <annevk> | sounds like you should omit it |
| 15:06 | <MikeSmith> | I think pubrules checker will choke if I do |
| 15:06 | <MikeSmith> | I'll try |
| 15:06 | <annevk> | http://www.w3.org/TR/cssom-view/#sotd |
| 15:06 | <annevk> | doesn't seem to have anything special either |
| 15:07 | <annevk> | and Bert Bos is serious about that stuff, he even has his own rules on top of the W3C rules |
| 15:11 | <hsivonen> | Hixie: thanks for fixing foreign content |
| 15:14 | <hsivonen> | Hixie: umm. It seems that you changed more than what the bug requested. |
| 15:14 | <hsivonen> | Hixie: did you really mean to change the handling of character tokens when the current node is an HTML integration point? |
| 15:16 | <MikeSmith> | annevk: hmm, http://www.w3.org/2001/06/manual/#Status has more details |
| 15:16 | <MikeSmith> | but I can't be bothered |
| 15:19 | <jgraham> | hsivonen: (I haven't looked in detail, but a testcase that changes would be helpful) |
| 15:20 | <annevk> | MikeSmith, oh wow; well I tried telling ij SotD is near useless, but he didn't really listen this time around |
| 15:24 | <annevk> | http://annevankesteren.nl/2011/03/dom-core-events -- when I worked on Events I wanted to write a more technical post as well, but that would require looking at all the details again at this point :/ |
| 15:25 | <hsivonen> | jgraham: it's also possible that Gecko is in error |
| 15:25 | <zewt> | by the way, your "ARCHIV" link text is clipped :P |
| 15:26 | <zewt> | (on my system, anyway) |
| 15:26 | <hsivonen> | jgraham: what's affected is U+0000 handling and whether active formatting elements get reconstructed |
| 15:27 | <annevk> | your browser has been spit on :p |
| 15:27 | <jgraham> | hsivonen: Hmm, OK I will have a look in a bit |
| 15:27 | <zewt> | you mean it's been spi on |
| 15:28 | <zewt> | ah, looks like you're depending on a custom font, and I force fonts |
| 15:28 | <annevk> | that would fail yes |
| 15:43 | <annevk> | might be back later |
| 15:54 | <bga_> | can opera implement "Enable Video" in F12 and localStorage managment (like cookies managment) and per site proxy settings? :) plz |
| 17:00 | <chriseppstein> | I'll just leave this here: http://hslpicker.com/ |
| 17:11 | <TabAtkins> | chriseppstein: Ooh, that's pretty. |
| 17:11 | <chriseppstein> | TabAtkins: :) That's Brandon. He did the design for http://beta.compass-style.org/ too |
| 17:12 | <chriseppstein> | he's great |
| 17:12 | jgraham | thinks it is kinda ugly tbh but was going to be too polite to say so… |
| 17:12 | <TabAtkins> | I'm sorry that you're wrong, jgraham. ^_^ |
| 17:13 | TabAtkins | goes back to iterator homework. |
| 17:13 | <TabAtkins> | The standardization process never rests. |
| 17:13 | <jgraham> | TabAtkins: Dude, you put me in a bad mood all morning due to your preference for tabs rather than spaces |
| 17:13 | <jgraham> | You have no high ground here :p |
| 17:13 | <TabAtkins> | Um, dude, I'm right. |
| 17:14 | <TabAtkins> | (That said, my fingers are betraying me this morning, because I was composing code in a textarea last night and needed to use spaces. |
| 17:14 | <TabAtkins> | ) |
| 17:14 | <jgraham> | (it's OK if I don't like the hsl thing, because the compass-style site is quite nice) |
| 17:14 | <zewt> | i'm swearing off whitespace arguments for a while for the sake of getting real things done :P |
| 17:15 | <chriseppstein> | jgraham: you don't have you use the garish tool. |
| 17:15 | <chriseppstein> | :P |
| 17:15 | <jgraham> | chriseppstein: :) |
| 17:15 | <Philip`> | TabAtkins is just suffering from nominative determinism and there's no need to get yourself worried by taking his concerns seriously |
| 17:15 | <Philip`> | Everyone else knows spaces are better |
| 17:16 | <chriseppstein> | If only there was a tool that could convert between them with a simple command *cough* vim *cough* |
| 17:16 | chriseppstein | runs out of the bikeshed |
| 17:17 | <jgraham> | chriseppstein: There is, emacs |
| 17:17 | <jgraham> | :p |
| 17:17 | <karlcow> | http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html |
| 17:17 | <TabAtkins> | chriseppstein: If only there was a tool that could infer what indentation level is attempting to be used by people who sprinkle inconsistent amounts of spaces around their file. |
| 17:17 | <karlcow> | HTML Speech XG Speech API Proposal |
| 17:17 | <chriseppstein> | Isn't emacs self-aware yet? |
| 17:17 | <zewt> | remember when emacs was actually thought of as a large program? heh |
| 17:17 | <jgraham> | karlcow: You seem to have accidentally pasted a buncg or unrelated words and letters into iRC |
| 17:17 | <zewt> | now video drivers are larger D: |
| 17:18 | <karlcow> | ? |
| 17:18 | <jgraham> | 11:21 < karlcow> HTML Speech XG Speech API Proposal |
| 17:18 | <karlcow> | yep |
| 17:18 | <karlcow> | and [18:20] <karlcow> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html |
| 17:19 | <jgraham> | karlcow: I prefer things where the title makes a modicum of sense to me |
| 17:19 | <karlcow> | it is TabAtkins who put his line in between mine ;) blame him :p |
| 17:19 | <karlcow> | > "This specification extends HTML to enable pages to incorporate speech recognition and synthesis." |
| 17:20 | <zewt> | HTMLSXGSAPIP |
| 17:20 | <karlcow> | I think zewt got it ;) |
| 17:20 | <zewt> | wait, should the abbreviations be abbreviated? HSXSAP |
| 17:21 | <karlcow> | Is it "speechable"? |
| 17:21 | <TabAtkins> | Ah, finally got my code back into a semblance of working, rather than just returning weird errors. |
| 17:21 | <zewt> | that's usually the part where the real work begins |
| 17:22 | <zewt> | finding the big breakages is easy; the rest, well... |
| 17:23 | <jgraham> | karlcow: so VoiceXML with s/X/HT/? |
| 17:23 | <karlcow> | jgraham: it seems. I'm discovering like you. It was posted on www-archive. |
| 17:24 | <karlcow> | by the W3C HTML Speech Incubator Group |
| 17:24 | <karlcow> | http://www.w3.org/2005/Incubator/htmlspeech/ |
| 17:24 | <karlcow> | "determine the feasibility of integrating speech technology in HTML5 in a way that leverages the capabilities of both speech and HTML (e.g., DOM) to provide a high-quality, browser-independent speech/multimodal experience while avoiding unnecessary standards fragmentation or overlap. " |
| 17:24 | <TabAtkins> | zewt: It's harder when your code *was* working, until you changed a small bit of the API that, it turns out, several things were depending on. |
| 17:26 | <zewt> | aka "I never thought I'd see a resonance cascade, let alone create one" |
| 17:26 | <TabAtkins> | Haha, yup. |
| 17:28 | <TabAtkins> | In other news, I can't wait until rest args are everywhere. Doing "func.apply(undefined, [].slice(arguments)" is painful when I know it could just be "func(...rest)". |
| 17:28 | <zewt> | worst is when it turns into a schrodinbug: you change it back, and everything remains broken |
| 17:31 | <matjas> | Should atob() and btoa() work inside Web Workers? |
| 17:31 | <TabAtkins> | Why not? |
| 17:31 | <matjas> | Should atob() and btoa() work inside Web Workers? |
| 17:31 | <TabAtkins> | They're just conversion functions. |
| 17:32 | <matjas> | Sorry for the double post, IRC client was acting up. |
| 17:32 | <matjas> | Yeah, then according to this guy there’s a bug in WebKit: https://twitter.com/jonleighton/status/42638578408374272 |
| 17:33 | <zewt> | web workers don't support lots and lots of things, which is a shame |
| 17:34 | <matjas> | zewt: Well it’s good to know it’s not that bad, theoretically :) |
| 17:34 | <zewt> | unicode single quotes as apostrophes make me sad :( |
| 17:34 | <Ms2ger> | That's (hah) what they're (hah) for. |
| 17:36 | <zewt> | unicode says that, and I want to know who was on what drugs when they said that |
| 17:36 | <TabAtkins> | I want to know what drugs Knuth was on when he said that strings start with `` and end with ''. |
| 17:37 | <zewt> | heh, at least that's died out |
| 17:37 | <zewt> | mostly |
| 17:37 | <Ms2ger> | Not in TeX |
| 17:38 | <zewt> | didn't gnu tools used to do that in their output? |
| 17:38 | <zewt> | not sure |
| 17:38 | <zewt> | eg. gcc output |
| 17:39 | <MikeSmith> | TabAtkins: it is a sin to question the wisdom of Knuth |
| 17:40 | <MikeSmith> | anything that Knuth has ever done is axiomatically Right |
| 17:40 | <TabAtkins> | He pushed Fortress. He's definitely not always right. ^_^ |
| 17:40 | <MikeSmith> | heh |
| 17:40 | <TabAtkins> | But I'll give him a pass on that, as he was on the CL committee. |
| 17:40 | <MikeSmith> | he was on drugs at the time |
| 17:40 | <MikeSmith> | that was his drug-experimentation time |
| 17:41 | <MikeSmith> | we all go through that |
| 17:41 | <MikeSmith> | I'm still in that phase actually |
| 17:41 | <zewt> | mental note: if I ever do anything that'll make me hated by future generations of programmers, do some drugs for a while so I can use it as an excuse later |
| 17:41 | <TabAtkins> | ^_^ |
| 17:41 | <MikeSmith> | zewt: do some drugs anyway |
| 17:41 | <TabAtkins> | zewt: If you're a programmer, you'll do horrible things every day. Take drugs anyway. |
| 17:41 | <MikeSmith> | I get that sense that you don't do enough now |
| 17:41 | <MikeSmith> | do more |
| 17:42 | <Philip`> | TabAtkins: Without ``...'', how would you express text with correct curly quotes? |
| 17:42 | <TabAtkins> | With curly quotes. |
| 17:42 | <Philip`> | (given you can only express things in ASCII) |
| 17:42 | <TabAtkins> | Oh. Remove that restriction, then use curly quotes. |
| 17:43 | <zewt> | fortunately, we live in the future now |
| 17:43 | <Philip`> | My keyboard doesn't have curly quote keys on it |
| 17:43 | <Philip`> | so I'd be a bit stuck |
| 17:43 | <Ms2ger> | Get a better keyboard |
| 17:43 | <karlcow> | MikeSmith: http://lists.w3.org/Archives/Public/www-validator/2005Sep/0052 related to Knuth ;) |
| 17:43 | <TabAtkins> | I am sympathetic to the ideas of (a) directly quotes, so you can actually nest strings, and (b) a difference between quotes and apostrophes, again so you can easily nest them. |
| 17:43 | <MikeSmith> | in the future we'll be able to do as much drugs as we want and not have consequences |
| 17:43 | <Ms2ger> | MikeSmith, in your case, the future is now ;) |
| 17:44 | <MikeSmith> | heh |
| 17:44 | <Philip`> | Maybe they should put tilt sensors in keyboards |
| 17:44 | <MikeSmith> | I am a pioneer |
| 17:44 | <Philip`> | so you can tilt it one way then type " |
| 17:44 | <MikeSmith> | I am walking the walk |
| 17:44 | <Philip`> | and get a curly quote in one direction |
| 17:44 | <MikeSmith> | leading by example |
| 17:44 | <Philip`> | and tilt the other way to get the other quote |
| 17:44 | <TabAtkins> | karlcow: Um, is that Knuth or Maggie? The From and the sig conflict. |
| 17:44 | <zewt> | why not just put one on your head; the quote hat |
| 17:44 | <zewt> | then you can just bob your head back and forth as you type |
| 17:45 | <zewt> | bonus: entertaining for others to watch |
| 17:45 | <karlcow> | TabAtkins: It is Knuth sent by his admin assistant |
| 17:45 | <Philip`> | TabAtkins: Knuth doesn't have an email address |
| 17:45 | <TabAtkins> | Ah, kk. That's awesome. |
| 17:45 | <MikeSmith> | karlcow: 面白い |
| 17:45 | <Philip`> | (http://www-cs-faculty.stanford.edu/~uno/email.html) |
| 17:45 | <MikeSmith> | I really should have my admin assistants to more work… it's not clear to me now how they are spending their current working hours |
| 17:46 | <TabAtkins> | MikeSmith: Porn. |
| 17:46 | <TabAtkins> | Obviously. |
| 17:46 | <MikeSmith> | heh |
| 17:46 | <zewt> | i giggled at "still using a doctype he learned from a book years ago" |
| 17:46 | <zewt> | updating to use current standards? NEVER |
| 17:46 | <MikeSmith> | TabAtkins: well, again, I guess I'm leading by example |
| 17:47 | <TabAtkins> | zewt: A bit later he looks for another doctype to use and says "Version 2.0 seemed promising; but... it doesn't know the bgcolor and text color attributes on <body>" |
| 17:47 | <deane> | MikeSmith: What do you mean by "polygot tweeter" |
| 17:49 | <MikeSmith> | deane: for a while I didn't tweet in English |
| 17:49 | <MikeSmith> | I tweeted only in languages that I don't actually speak |
| 17:49 | Ms2ger | thought it was someone whose tweets could be parsed as HTML and XML |
| 17:50 | <MikeSmith> | deane: but people who followed me seemed to not have liked that so much… they were scared by it and I lost a lot of followers |
| 17:50 | <MikeSmith> | Ms2ger: :) |
| 17:50 | <zewt> | twitter.com -> ホーホケキョ.co.jp? |
| 17:51 | <MikeSmith> | deane: you in Auckland? did you meet any of the SVG WG participants? they're all there now I think |
| 17:52 | <MikeSmith> | zewt: no clue |
| 17:52 | <MikeSmith> | never heard of that domain before |
| 17:52 | <zewt> | ignore the dumb jokes. heh |
| 17:52 | <zewt> | (in my case, a redundant phrase) |
| 17:53 | <MikeSmith> | deane: if you understand nothing else about me after all the time we have spent together I hope you can understand my desire to keep people confused |
| 17:54 | <MikeSmith> | clarity is to be avoided whenever possible |
| 17:54 | <MikeSmith> | that's a quote from Albert Einstein |
| 17:55 | <deane> | MikeSmith: sorry, a bit behind with the news. |
| 17:55 | <TabAtkins> | Eschew obfuscation, weaponize confusion. |
| 17:55 | <MikeSmith> | heh |
| 17:55 | <MikeSmith> | TabAtkins: you continue to have a way with words |
| 17:55 | <MikeSmith> | write more poetry |
| 17:55 | <Ms2ger> | MikeSmith, I find your reference to Einstein confusing |
| 17:55 | <MikeSmith> | heh |
| 17:57 | <MikeSmith> | TabAtkins: gsnedders can give you some guidance on writing love poems |
| 17:58 | <zewt> | : | |
| 18:00 | <MikeSmith> | geez, it appears that I may have actually done my job correctly for the first time in quite a while |
| 18:00 | <MikeSmith> | http://www.w3.org/TR/notifications/ |
| 18:01 | <TabAtkins> | Augh, I'm in love with seeing artists progress over the years: http://s3.amazonaws.com/data.tumblr.com/tumblr_lg87qtM1KG1qcbajko1_1280.jpg?AWSAccessKeyId=0RYTHV9YYQ4W5Q3HQMG2&Expires=1299088987&Signature=pDFn68bpvnhhNoPWXjWH6phk9mw%3D |
| 18:04 | <Ms2ger> | MikeSmith++ |
| 18:06 | <jgraham> | TabAtkins: The main progression seems to be from more -> fewer clothes |
| 18:07 | <jgraham> | (with deviations) |
| 18:09 | <TabAtkins> | jgraham: Hah, that seems fair. |
| 18:10 | <TabAtkins> | How do I override a getter on an object? I obviously can't just set it. |
| 18:10 | <jgraham> | TabAtkins: With ES3+extensions __defineGetter__ |
| 18:10 | <jgraham> | With ES5 something else that I forget the name of right now |
| 18:11 | <jgraham> | defineOwnProperty |
| 18:11 | <TabAtkins> | ES3 works for me. Let's try it out... |
| 18:12 | <jgraham> | Aslo, was that timeline from somewhere? |
| 18:13 | <TabAtkins> | jgraham: Dresden Codak |
| 18:14 | <TabAtkins> | From his tumblog, specifically. |
| 18:35 | <TabAtkins> | Our next exhibit: an hour of debugging caused by me forgetting the difference between "[].slice(arguments)" and "[].slice.call(arguments)". >_< |
| 18:36 | TabAtkins | hates 'this' really bad. |
| 18:36 | <zewt> | one of javascript's more painful warts |
| 18:37 | <TabAtkins> | Unrelated: holy crap, the fact that chrome now syncs *all* my info across all my machines is surprising every time. |
| 18:37 | <AryehGregor> | "All" meaning what? |
| 18:37 | <TabAtkins> | Specifically, when I find it autocompleting on my work machine, based on searches I made yesterday at home. |
| 18:51 | <Hixie> | hsivonen: it was not my intent to change character handling in foreign content; how did it change? |
| 18:59 | <jgraham> | The difference between .slice and .slice.call is quite annoying |
| 19:00 | <jgraham> | I get that wrong annoyingly often |
| 19:00 | <jgraham> | i.e. more than never |
| 19:11 | <Hixie> | othermaciej: i'm a little confused wit issue-9... what happens to its CPs if we agree to close it? |
| 19:12 | <othermaciej> | Hixie: they will not be considered adopted |
| 19:12 | <Hixie> | k |
| 19:12 | <othermaciej> | Hixie: if they were to be adopted, they'd likely have to be rewritten against the current spec baseline, which includes most of their functionality |
| 19:12 | <Hixie> | ah ok |
| 19:13 | <othermaciej> | Hixie: my understanding is that no one particularly cares about writing up that delta, or applying it t the spec |
| 19:13 | <othermaciej> | but if anyone does, they can object |
| 19:13 | <Hixie> | makes sense |
| 19:13 | <Hixie> | thanks |
| 19:26 | <TabAtkins> | Why has no programming language yet invented nestable comments? This is ridiculous. |
| 19:26 | <wolfman2000> | TabAtkins: /* You mean /* like this */ example? */ |
| 19:26 | <TabAtkins> | Yes. |
| 19:27 | <wolfman2000> | ...I have no answer. |
| 19:27 | <TabAtkins> | I had a function which took arbitrary arguments, which I indicated in the definition like "function foo(/* args */)", but then I can't comment out a block of code containing that definition. |
| 19:27 | <bfrohs> | Probably has something to do with not wanting to worry about escaping inside of comments |
| 19:28 | <TabAtkins> | The only reasons I can think of are (1) didn't want to disallow putting /* in your comments, which is stupid, because we disallow putting */ in them |
| 19:28 | <othermaciej> | TabAtkins: in the C family of languages, you can achieve nest able comments with #if 0 / #endif |
| 19:28 | <TabAtkins> | Or (b) were lazy and didn't want to search inside a comment for more comment tokens and tracking a stack. |
| 19:28 | <zewt> | i often do if(0) { ... } to comment out sections, too (which means they're still parsed, but handy for quick edits) |
| 19:29 | <TabAtkins> | othermaciej: That's a nasty macro hack, but it works, yeah. |
| 19:29 | <TabAtkins> | zewt: Yeah, I guess. It's not obvious that the closing brace is a comment-closer, though. Also, I often comment chunks of code that arent' syntactically valid. |
| 19:29 | <zewt> | usually i just do it when I want to get code out of the way quickly |
| 19:29 | <TabAtkins> | So I guess I'm just going to be quietly frustrated. |
| 19:30 | <hober> | Lots of programming languages have nestable comments |
| 19:30 | <othermaciej> | TabAtkins: it doesn't involve macros at all, it's a preprocessor hack |
| 19:30 | <zewt> | i thought Lua had something for them, like --[[[ ]]] or something, but I guess not |
| 19:30 | <othermaciej> | C++-style // comments are also effectively nestable, though it only takes one end-of-line to terminate multiple levels |
| 19:30 | <Philip`> | TabAtkins: OCaml has nestable comments |
| 19:30 | <TabAtkins> | othermaciej: Argh, yeah. I even wrote "preprocessor" and then removed it. |
| 19:30 | <hober> | e.g. #| ... |# in Common Lisp |
| 19:30 | <othermaciej> | This is // a comment that contains // a comment |
| 19:31 | <Philip`> | (* comment (* comment *) comment *) not comment |
| 19:31 | <TabAtkins> | hober: Are CL's nestable? |
| 19:31 | <hober> | TabAtkins: yes. |
| 19:31 | <TabAtkins> | Hm, didn't realize that. I use them rarely enough that I haven't run into it. |
| 19:31 | <othermaciej> | well of course it's nestable in Lisp |
| 19:31 | <othermaciej> | Lisp is all about nesting |
| 19:31 | <zewt> | (* ‿ *) |
| 19:31 | <hober> | IIRC Pascal's comments were nestable too. {* ... *}? I'm not sure if that was what it was |
| 19:31 | <TabAtkins> | Heh, yeah. |
| 19:35 | <zewt> | how is it Unicode has PILE OF POO, yet it doesn't have ... an octagon |
| 19:35 | <zewt> | i can see they have their priorities straight |
| 19:36 | <bfrohs> | zewt: The former is a better representation of IE6 |
| 19:38 | <hober> | zewt: I believe we have the Japanese to blame |
| 19:38 | <AryehGregor> | Async stuff in JS makes my head hurt. I can't figure out how you're supposed to do synchronization, like only do some particular thing when an event handler is finished. Just run it from the event handler? |
| 19:38 | <zewt> | yep |
| 19:38 | <AryehGregor> | Then if you do that repeatedly, you get an arbitrarily deep stack. |
| 19:38 | <zewt> | event handlers run from event handlers don't run under the same stack |
| 19:38 | <AryehGregor> | Ah, of course. |
| 19:38 | <AryehGregor> | That makes sense. |
| 19:38 | AryehGregor | tries that |
| 19:53 | <zewt> | okay, gmail is officially weird |
| 19:54 | <zewt> | it breaks mail subject displays into separate spans at seemingly random spots, so when I double-click to select words in FF the word breaking stops mid-word |
| 20:18 | <david_carlisle> | TabAtkins: (*xpath (*comments*) *) |
| 20:19 | <david_carlisle> | oops (: :) not * |
| 20:26 | <TabAtkins> | Okay, so it looks like it was just that C got comments wrong, and then JS copied C. Dammit. |
| 20:28 | <AryehGregor> | Some C compilers allow nesting comments, don't they? |
| 20:28 | <zewt> | nonstandard |
| 20:28 | <Ms2ger> | And not copied to JS |
| 20:28 | <zewt> | (of course, plenty of nonstandard things are supported widely in C compilers, but that's not a common one) |
| 20:29 | <AryehGregor> | Oh well. |
| 20:30 | <hober> | interesting feedback on the outline algorithm & the sectioning elements: http://www.456bereastreet.com/archive/201103/html5_sectioning_elements_headings_and_document_outlines/ |
| 20:30 | <Hixie> | othermaciej: i've used programming languages whose parsers have supported nested comments |
| 20:30 | <Hixie> | er |
| 20:31 | <Hixie> | s/ othermaciej / TabAtkins / |
| 20:31 | <Hixie> | man i do that all the time |
| 20:31 | <TabAtkins> | What, talk to othermaciej all the tiem? |
| 20:32 | <Hixie> | use his name instead of whoever i actually meant to talk to, because of seeing him as the last person to have spoken to the person i meant to speak to on the topic |
| 20:32 | <Hixie> | http://junkyard.damowmow.com/454 doesn't do what i expect in any browser |
| 20:32 | <Hixie> | (i don't get any alerts) |
| 20:32 | <Hixie> | am i doing it wrong? |
| 20:32 | <Hixie> | (trying to test step 4 of the "prepare a script" algorithm) |
| 20:33 | <AryehGregor> | Do browsers not support document.innerHTML? |
| 20:33 | <Hixie> | i think i made that up |
| 20:34 | <Hixie> | ohhh i get it |
| 20:35 | <Hixie> | wait no i don't |
| 20:35 | <Hixie> | wtf |
| 20:35 | <Ms2ger> | Well, yes, document.innerHTML is a quick way to failure |
| 20:38 | <zewt> | funky code--did you mean to be shuffling the nodes around as you iterate over them? |
| 20:38 | Ms2ger | thinks that was the point |
| 20:39 | <Hixie> | zewt: yeah |
| 20:39 | <Hixie> | zewt: oh, wait |
| 20:39 | <Hixie> | zewt: good point |
| 20:39 | <Hixie> | zewt: i forgot that the list was live |
| 20:39 | <zewt> | so x[0] operates on the document.write, x[1] operates on the blank script (skipping over the other <script>) |
| 20:39 | <Hixie> | zewt: thanks! |
| 20:39 | <AryehGregor> | Ms2ger, what? |
| 20:40 | <Ms2ger> | Hmm? |
| 20:40 | <AryehGregor> | What about document.innerHTML? |
| 20:40 | AryehGregor | has only found two trivial IE bugs in deleteContents() so far, needs more tests |
| 20:40 | <Ms2ger> | Currently fiction |
| 20:40 | <AryehGregor> | Oh, and Opera doesn't run the tests correctly at all. |
| 20:40 | <AryehGregor> | Oh. |
| 20:40 | <zewt> | hmm, though it's still odd that the script isn't executed |
| 20:40 | <AryehGregor> | Opera doesn't seem to be firing a load event at my iframe when I change the src. |
| 20:41 | <AryehGregor> | That kind of totally breaks my testing setup. |
| 20:41 | <Ms2ger> | Uh |
| 20:41 | AryehGregor | waits to be told he's an idiot |
| 20:41 | <Ms2ger> | That sounds broken |
| 20:41 | <AryehGregor> | Oh, okay, so I'm not just clueless. |
| 20:41 | <AryehGregor> | I dunno, see for yourself: http://aryeh.name/spec/dom-range/test/Range-deleteContents.html |
| 20:42 | <AryehGregor> | Works in all other browsers. |
| 20:42 | <zewt> | ah yeah I see what's happening, when it's shuffling around the list, it ends up only actually modifying script nodes that have already executed, which does nothing |
| 20:42 | <AryehGregor> | If I add an alert() to the onload handler, it only fires the first time the src is set for that iframe. |
| 20:42 | <Ms2ger> | The 1 complete, 0 remain... 2 complete, 0 remain... 3 complete, 0 remain... is pretty silly |
| 20:42 | <zewt> | be nice if modifying an "already started" script would raise an exception or at least warn about it |
| 20:42 | <AryehGregor> | Don't look at me, not my test framework. |
| 20:43 | <Ms2ger> | I know right |
| 20:43 | <Ms2ger> | I'm not sure if using strict mode in tests is a good idea, fwiw |
| 20:43 | <AryehGregor> | I thought you were the one who added that to my tests to begin with when you committed them. |
| 20:43 | <Ms2ger> | I did? |
| 20:44 | <Ms2ger> | I certainly shouldn't have |
| 20:44 | <Ms2ger> | actual.onload = ""; seems strange |
| 20:45 | <AryehGregor> | I did that because I'm only changing the hash, so it doesn't fire a load event otherwise. |
| 20:45 | <AryehGregor> | I could reload() it also, maybe? |
| 20:45 | <Ms2ger> | But why set a Function IDL attribute to a string? |
| 20:46 | <AryehGregor> | It accepts strings too, no? As the function body? |
| 20:46 | <AryehGregor> | I could set it to the empty function, but that's more verbose. |
| 20:46 | <Ms2ger> | Just the content attribute, or am I clueless here? |
| 20:46 | <AryehGregor> | I dunno. |
| 20:47 | AryehGregor | tests |
| 20:47 | <zewt> | actual.onload = null? |
| 20:47 | <AryehGregor> | Seems so. |
| 20:47 | <AryehGregor> | Yeah, that makes more sense . . . |
| 20:49 | <AryehGregor> | Changed. |
| 20:50 | <AryehGregor> | Ms2ger, also: https://bitbucket.org/ms2ger/dom-range/src/925ad3b285f9/test/selection-extend.html |
| 20:50 | <AryehGregor> | "use strict" was not in the patch I submitted, I don't think . . . |
| 20:50 | <AryehGregor> | Although maybe I'm hallucinating. |
| 20:50 | <AryehGregor> | Anyway, it will help me catch bugs in my code as I write it. It can always be removed later. |
| 20:51 | <Ms2ger> | Yeah, that's fine |
| 20:52 | <AryehGregor> | I'm very disappointed. |
| 20:52 | <AryehGregor> | I wasn't able to find any bugs at all, except some trivial ones in IE9 (involving whether text nodes are split or modified in-place, and whether empty text nodes are removed). |
| 20:52 | <AryehGregor> | Does anyone have any more tests to suggest? |
| 20:53 | <AryehGregor> | I've tested about every type of Range I can think of, and they all work. :( |
| 20:54 | <Ms2ger> | s/:(/:)/ |
| 20:54 | <AryehGregor> | I guess so. :) |
| 20:57 | <zewt> | "curse you browsers for not having enough bugs *fist shake*" |
| 20:57 | <AryehGregor> | I generally assume that if testing doesn't find inconsistencies in some nontrivial feature, the tests aren't good enough. |
| 20:58 | <gsnedders> | AryehGregor: Stuff browsers do differently with Range? Looked through bug trackers? |
| 20:58 | <AryehGregor> | gsnedders, what? |
| 20:59 | <gsnedders> | AryehGregor: What are you trying to test? |
| 20:59 | <TabAtkins> | Hm, is there a way to return an object with an error, so that I can look through it in the inspector? |
| 20:59 | <AryehGregor> | I'm talking specifically about Range.deleteContents() here. |
| 20:59 | <bfrohs> | AryehGregor: ask on Twitter--I'm sure there's someone, somewhere that has an edge case that's buggy in browsers |
| 20:59 | <AryehGregor> | Also, maybe Opera is totally broken, I don't know, because my tests don't run for some reason. |
| 20:59 | <AryehGregor> | http://aryeh.name/spec/dom-range/test/Range-deleteContents.html |
| 20:59 | <AryehGregor> | It only runs the first two, then it times out. |
| 21:00 | <zewt> | i get a fail and timeout in FF3.6, FWIW |
| 21:01 | <AryehGregor> | Interesting. |
| 21:01 | <AryehGregor> | Firefox 4b11 works fine for me. |
| 21:01 | <gsnedders> | AryehGregor: tbh I'd be surprised if there was much different with deleteContents |
| 21:01 | <zewt> | function () { range.deleteContents(); } threw with code INVALID_STATE_ERR (11) expected INVALID_STATE_ERR (11) |
| 21:01 | <AryehGregor> | Oh, that. |
| 21:01 | <AryehGregor> | That's a known bug that affects every single assert_throws() in this test framework. |
| 21:01 | <AryehGregor> | Ms2ger filed it somewhere. |
| 21:01 | <AryehGregor> | It can get annoying, but I'm not counting it for this purpose, since it's not specific to deleteContents(). |
| 21:02 | <zewt> | second one times out |
| 21:02 | <Ms2ger> | One not run? What's that about? |
| 21:03 | <zewt> | Range 0 [paras[0].firstChild, 0, paras[0].firstChild, 0] Test timed out |
| 21:03 | <Ms2ger> | WFM |
| 21:03 | <bfrohs> | AryehGregor: same results as zewt in ff3.6 on ubuntu |
| 21:04 | <zewt> | (XP64) |
| 21:04 | <AryehGregor> | 3.6 doesn't really matter, it's only the most current browsers that really matter for tests. |
| 21:04 | <AryehGregor> | Opera is more of an issue. |
| 21:05 | <AryehGregor> | Also, if I'm doing something fragile or whatever and there's a better way to do it, that would be nice to know. |
| 21:05 | <AryehGregor> | But it seems fairly straightforward to me. |
| 21:06 | <Ms2ger> | Hmm, I got timeouts for 5 and 42 |
| 21:06 | <AryehGregor> | In what browser? |
| 21:07 | <Ms2ger> | Fx4 |
| 21:07 | <AryehGregor> | Annoying. |
| 21:07 | <AryehGregor> | There's probably a better way to write the tests. |
| 21:07 | <AryehGregor> | But I'm not sure how, given the need to reset every time. |
| 21:08 | <bfrohs> | No timeouts for me in ff4 on ubuntu |
| 21:13 | <AryehGregor> | Okay, specced: http://html5.org/specs/dom-range.html#dom-range-deletecontents |
| 21:13 | <AryehGregor> | I could go back to execCommand(), but I think I'll do some more Range stuff first. |
| 21:13 | <Ms2ger> | No objections here |
| 21:14 | AryehGregor | discovers http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html |
| 21:14 | <AryehGregor> | Why did I not know about that before? |
| 21:14 | Ms2ger | was wondering that |
| 21:15 | <AryehGregor> | Was wondering what? |
| 21:15 | <Ms2ger> | That you just discovered it |
| 21:15 | <AryehGregor> | Oh, hey, this even attempts to define what mutation does. |
| 21:15 | <Hixie> | wait you didn't know about the existing spec you've been rewriting? :-) |
| 21:15 | <AryehGregor> | No, nobody told me. |
| 21:15 | <Hixie> | i assumed you knew! |
| 21:15 | <Hixie> | sorry dude |
| 21:15 | <AryehGregor> | Does the current DOM Range draft mention it anywhere? |
| 21:16 | <Hixie> | dunno |
| 21:16 | <Ms2ger> | Probably not |
| 21:16 | <AryehGregor> | Actually, there's some nice terminology here. Let me read this. |
| 21:21 | <AryehGregor> | This isn't a bad spec at all, although it's not quite as precise as we do things these days. |
| 21:22 | <AryehGregor> | For instance, it specifically calls out the two corner cases that IE gets wrong. |
| 21:22 | <zewt> | from reading current specs, it seems like the major shift lately has been from descriptive specs to more or less pseudocode specs |
| 21:22 | <AryehGregor> | Yes, definitely. |
| 21:23 | <AryehGregor> | Makes them harder to read, but it's much easier to be precise that way. |
| 21:23 | <Ms2ger> | AryehGregor, http://www.w3.org/DOM/DOMTR, fyi :) |
| 21:23 | <zewt> | i find them easier to read, myself |
| 21:23 | <AryehGregor> | Ms2ger, :) |
| 21:23 | <AryehGregor> | Hmm, maybe. |
| 21:24 | <TabAtkins> | I definitely try to write my specs in pseudocode style. I employ prose in the non-normative description of properties to explain what they do without reference to algorithms, but describing the algorithms descriptively is pretty clearly a failure. |
| 21:24 | <AryehGregor> | I prefer them myself. |
| 21:24 | <zewt> | in the same sense that it can be easier to understand an algorithm by reading code that does it rather than a research paper explaining it |
| 21:24 | <AryehGregor> | Ms2ger, I actually think I did see the old DOM Range spec before, I just never read it . . . |
| 21:24 | <zewt> | (provided it's well-written code, of course) |
| 21:24 | <AryehGregor> | Or only long ago. |
| 21:25 | <Ms2ger> | Just wanted to make sure you didn't miss any other specs ;) |
| 21:25 | <AryehGregor> | :P |
| 21:27 | <jgraham> | Gah, you go away for one moment and people start discussing things you need to pay attention to |
| 21:28 | <Ms2ger> | sh pipes? |
| 21:28 | <AryehGregor> | Hahahaha. |
| 21:28 | <jgraham> | AryehGregor: The weird assert_throws error should, I think, be fixed in a recent testharness.js |
| 21:28 | <zewt> | Ms2ger: i saw that and just backed away slowly |
| 21:28 | <AryehGregor> | jgraham, you mean the one where Firefox fails every time? |
| 21:29 | <jgraham> | AryehGregor: Yes, the one with expected foo, got foo |
| 21:29 | <Ms2ger> | AryehGregor, if you just pull the repo, it'll be fixed ;) |
| 21:29 | <AryehGregor> | zewt, I would have, but just wanted to make it clear how spectacularly insane it was in case any innocent bystanders got misled. |
| 21:29 | <AryehGregor> | Ms2ger, which, dom-range? |
| 21:29 | <AryehGregor> | I pulled just now before merging. |
| 21:29 | <Ms2ger> | Yeah |
| 21:29 | <AryehGregor> | Oh, yeah, it works. |
| 21:29 | <AryehGregor> | Yay. |
| 21:29 | <jgraham> | What are you doing with onload that breaks Opera? That works for sure in general so you must be doing something special |
| 21:30 | <AryehGregor> | jgraham, https://bitbucket.org/ms2ger/dom-range/src/a6993c2d45e1/test/Range-deleteContents.html |
| 21:30 | <AryehGregor> | Live version: http://aryeh.name/spec/dom-range/test/Range-deleteContents.html |
| 21:31 | <AryehGregor> | I'm just repeatedly setting the onload and src of an iframe. |
| 21:31 | <AryehGregor> | Only the first onload I set this way seems to fire. |
| 21:34 | <jgraham> | AryehGregor: What happens if you put about:blank rather than the empty string? |
| 21:35 | <AryehGregor> | jgraham, fails in a different way, it looks like . . . |
| 21:35 | <AryehGregor> | (I've made the change, you can try it out) |
| 21:35 | <jgraham> | I get 26 pass |
| 21:35 | <jgraham> | What should I get? |
| 21:35 | <AryehGregor> | Hmm. |
| 21:35 | <AryehGregor> | I get 3 pass. |
| 21:36 | <AryehGregor> | You should get . . . hey, now it fails in Firefox too. |
| 21:36 | <AryehGregor> | One sec. |
| 21:36 | <AryehGregor> | I think the new harness broke the tests. |
| 21:36 | <AryehGregor> | It should be like 50 or so passes. |
| 21:36 | <jgraham> | Hmm |
| 21:36 | <AryehGregor> | And it was before the new harness. |
| 21:36 | <jgraham> | Could have happened |
| 21:37 | jgraham | might be too tired to helpfully debug now |
| 21:37 | <jgraham> | Just out of interest, is setting .src to about:blank magic? |
| 21:37 | <jgraham> | Specifically is it sync? |
| 21:37 | <jgraham> | Otherwise there is a race condition I think? |
| 21:38 | <jgraham> | (you set src then set onload) |
| 21:38 | <AryehGregor> | Oh. |
| 21:38 | <AryehGregor> | Didn't think of that. |
| 21:39 | <AryehGregor> | Maybe there's a better way to do this. |
| 21:39 | <AryehGregor> | Calling iframe.contentWindow.location.reload() should fire a load event, right? |
| 21:40 | <zewt> | havn't squinted too hard at this, but could you just add a dummy parameter to the URL to force a reload? |
| 21:40 | <zewt> | ?role=actual&x=1 |
| 21:41 | <zewt> | guess that would also make it not cache, which you probably don't want |
| 21:41 | <AryehGregor> | Oh, right. |
| 21:41 | <AryehGregor> | That would slow down the tests needlessly. |
| 21:41 | <zewt> | or, just discard the whole iframe and create a new one manually each time |
| 21:41 | <zewt> | (don't know if that's compatible with the code) |
| 21:42 | <AryehGregor> | It would work. |
| 21:42 | <AryehGregor> | Let me try reload() first. |
| 21:43 | <AryehGregor> | Oh, wait, that's still a race condition. |
| 21:43 | <AryehGregor> | Can I just use onhashchange instead, maybe? |
| 21:43 | AryehGregor | tries that |
| 21:43 | <jgraham> | AryehGregor: I haven't read everything carefully but using a query parameter rather than a hash seems like it would save lots of effort |
| 21:43 | <AryehGregor> | Hmm. |
| 21:43 | <AryehGregor> | Maybe that too. |
| 21:43 | <zewt> | would need to use both, i think, since the first time would be onload |
| 21:44 | <AryehGregor> | Not if it starts out at the given URL. |
| 21:45 | <AryehGregor> | Is there some nice way to access location.search as an associative array, or do I get to write my own? |
| 21:45 | <AryehGregor> | (not that it's very hard) |
| 21:45 | <Ms2ger> | You get to write your own |
| 21:45 | <AryehGregor> | Yay! |
| 21:46 | <jgraham> | AryehGregor: Also, you might want to take advantage of the fact that test objects now start their timeout the first time their .step is called |
| 21:46 | <AryehGregor> | What does that mean for my purposes? |
| 21:46 | <jgraham> | So you can generate all the test objects upfront (so the harness knows how many there should be) |
| 21:46 | <zewt> | jgraham: but caching |
| 21:46 | <jgraham> | zewt: Screw caching |
| 21:47 | <AryehGregor> | Hmm, okay. |
| 21:47 | <jgraham> | AryehGregor: The advantage is that when things go wrong it is more obvious what happened |
| 21:48 | <jgraham> | Rather than just getting teh wrong number of results |
| 21:48 | <AryehGregor> | Okay. |
| 21:48 | <zewt> | the difference between 50 tests taking a second to run or 30 seconds is the difference between people running the tests often and not |
| 21:49 | <jgraham> | zewt: The difference won't be that large in this case |
| 21:49 | <jgraham> | and if it is there are plenty of ways to work around it |
| 21:49 | <jgraham> | e.g. make each test a data:uri and the script a cacheable external resource |
| 21:51 | <AryehGregor> | Does IE9 support data: URIs here? |
| 21:51 | <jgraham> | I think so |
| 21:51 | <jgraham> | Why wouldn't it? |
| 21:51 | <zewt> | FYI, it's already revalidating for every test (need to tweak cache headers to fix that) |
| 21:52 | <Ms2ger> | Because it used to allow them only where needed to pass acid2 |
| 21:52 | <jgraham> | Well if microsoft fail every test duw to making a retarded implementation of data: I have very little sympathy |
| 21:52 | <jgraham> | Since they knowing made it just good enough for PR |
| 21:53 | <jgraham> | *knowingly |
| 21:53 | <zewt> | AryehGregor: odd: even if I just set src and onload, it reloads the document every time and works fine--not sure off-hand why that doesn't trigger a hashchange like you said |
| 21:53 | <zewt> | oh, because it's changing the src of an iframe--not the same as changing document.location |
| 21:53 | <zewt> | (i think--I don't use iframes often) |
| 21:55 | <AryehGregor> | How do I discard my changes to a particular file, in hg? |
| 21:55 | <AryehGregor> | Like git checkout FILENAME. |
| 21:55 | <AryehGregor> | Or (IIRC) svn up FILENAME. |
| 21:56 | <Ms2ger> | hg up -C? |
| 21:56 | <AryehGregor> | Hmm, doesn't matter, I didn't change any other files anyway. |
| 21:56 | <Ms2ger> | But check help first |
| 21:56 | <AryehGregor> | Ms2ger, that resets all files, not just the given ones. |
| 21:56 | <AryehGregor> | It doesn't seem to take filename args. |
| 21:56 | <AryehGregor> | Ah, hg revert. |
| 21:59 | <zewt> | ah: changing the hash in the src of an iframe seems to always trigger onload in FF4, but not Chrome |
| 21:59 | <AryehGregor> | What does the spec say? |
| 22:00 | <zewt> | havn't looked |
| 22:01 | Ms2ger | whines about the <banner>, <body> and <wrapper> threads |
| 22:06 | <zewt> | AryehGregor: sanest way seems to be to just create new iframes each time |
| 22:06 | <AryehGregor> | Okay, now I'm getting racy behavior all over the place, but I can't see anything I do that's a race condition. |
| 22:07 | <AryehGregor> | Let me try creating new iframes each time. |
| 22:07 | <zewt> | i'm doing that, it's working in FF4 but not Chrome |
| 22:07 | <zewt> | don't know the framework to know why |
| 22:07 | <zewt> | http://pastebin.com/NNKbjRNb |
| 22:08 | <zewt> | the tests all run and pass in chrome, but only the first two show up |
| 22:11 | <AryehGregor> | I'm still getting mysterious racy behavior. |
| 22:11 | <AryehGregor> | Works in Chrome, although I get two new failures. |
| 22:12 | <AryehGregor> | Firefox skips a random number of tests at the end. |
| 22:12 | <AryehGregor> | Opera has gone into an infinite loop or something. |
| 22:12 | <AryehGregor> | IE also skips a random number at the end. |
| 22:13 | <AryehGregor> | jgraham, are you sure these aren't timing out prematurely? |
| 22:14 | <Ms2ger> | Sounds likely |
| 22:17 | <Ms2ger> | You know you're getting INDEX_SIZE_ERRs in Fx? |
| 22:18 | <AryehGregor> | For which tests, deleteContents()? |
| 22:18 | <Ms2ger> | Yeah |
| 22:19 | <AryehGregor> | Hmm. |
| 22:19 | <AryehGregor> | I'll look at that tomorrow, I guess. |
| 22:19 | <Ms2ger> | And extending the timeout gives me 52 finished tests |
| 22:19 | <AryehGregor> | Really? |
| 22:19 | <AryehGregor> | How did you extend it? |
| 22:19 | <AryehGregor> | In setup() or what? |
| 22:19 | <Ms2ger> | Firebug :) |
| 22:19 | <AryehGregor> | Um, okay. |
| 22:20 | <Ms2ger> | But yes, setup would be the right way, I think |
| 22:22 | <AryehGregor> | Hmm, that seems to help. |
| 22:22 | <AryehGregor> | Chrome is now weird, though. |
| 22:22 | <zewt> | seems like I'm only getting 2 results in Opera/Chrome, because as soon as the second test completes, tests.phase == COMPLETE and no further tests are reported? |
| 22:22 | <AryehGregor> | Oh, it now semi-runs in Opera. |
| 22:23 | <AryehGregor> | I'm changing the tests live, by the way, so if anyone else is trying to run them, you're probably getting confusing results. |
| 22:24 | <AryehGregor> | Okay, now I've made my last change for the day (probably), so it's safe to experiment on the live copies. |
| 22:24 | <AryehGregor> | Firefox and IE seem to work now, Chrome and Opera randomly fail after a few tests. |
| 22:27 | <jgraham> | AryehGregor: Yes, they could be timing out |
| 22:28 | <jgraham> | setup({timeout:some_high_number_of_ms}) should fix that |
| 22:28 | <jgraham> | AryehGregor: This is much easier to debug if you define all tests upfront |
| 22:28 | <jgraham> | rather than creating one test as the other finishes |
| 22:29 | jgraham | sees 52 pass in opera |
| 22:30 | <jgraham> | Is it me or is it *really* slow in gecko compared to opera? |
| 22:32 | <jgraham> | Chrome seems to have stopped after 22 |
| 22:33 | <zewt> | alright, I think I have it working reliably, had to poke at the harness to see what was going on |
| 22:34 | <jgraham> | zewt: What did you change? |
| 22:34 | <zewt> | it seems that the test harness stops as soon as the number of tests waiting to run is 0 |
| 22:34 | <jgraham> | Yes |
| 22:34 | <zewt> | due to tests.prototype.notify_result going through the all_done codepath, which sets it to COMPLETE |
| 22:34 | <jgraham> | (given other conditions) |
| 22:34 | <zewt> | i hacked around it by adding a dummy test |
| 22:35 | <zewt> | http://zewt.org/~glenn/foo/Range-deleteContents.html |
| 22:37 | <jgraham> | zewt: Oh |
| 22:37 | <jgraham> | I wonder why it ever worked |
| 22:37 | <zewt> | works for me in opera 11, chrome 9, ff4 (havn't tried IE9 since I have to start a bloated Win7 VM for it) |
| 22:37 | <zewt> | jgraham: my guess (havn't investigated) is something along the lines of somehow ending up with more than one async test running due to some other race |
| 22:38 | <jgraham> | Anyway, I think The Right Fix (TM) is to define all the tests up front |
| 22:38 | <jgraham> | But I thin AryehGregor is doing that now and it fails in Chrome |
| 22:38 | <jgraham> | *think |
| 22:39 | <jgraham> | Oh, look at that |
| 22:39 | <jgraham> | It seems to be throwing outside a t.step() |
| 22:40 | <jgraham> | Which is bad |
| 22:40 | <jgraham> | Uncaught Error: NOT_FOUND_ERR: DOM Exception 8 |
| 22:43 | <jgraham> | So my suggestion is to put more code inside the t.step() |
| 22:43 | <jgraham> | possibly ading more steps |
| 22:46 | <zewt> | there also seems to be some kind of funkiness with synchronous tests and onload |
| 22:47 | <zewt> | running any sync test after onload triggers COMPLETE |
| 22:47 | <zewt> | (because all_loaded is true) |
| 22:49 | <zewt> | anyhow, the current version I have up works in FF4, Opera 11, Chrome 9 and IE9 consistently for me |
| 22:53 | <jgraham> | zewt: What exactly is the bug? |
| 22:54 | <jgraham> | With sync tests and onload? |
| 22:55 | <jgraham> | It *should* only mark the tests as complete if num_pending is 0, which *should* only happen if there are no uncompleted async tests |
| 22:55 | <zewt> | if you run a sync test after onload, test() -> test_obj.done() -> tests.result() -> tests.notify_result -> tests.complete() |
| 22:55 | <zewt> | right, but I was only using sync tests, with no async ones at all |
| 22:55 | <jgraham> | That sounds like expected behaviour |
| 22:56 | <jgraham> | I mean, how do you expect it to know that you will add a sync test at some point in the future? |
| 22:56 | <zewt> | seems strange that you can only run one sync test unless you start a placeholder async one |
| 22:56 | <jgraham> | You can have > 0 sync tests as long as you define them to run before onload fires |
| 22:56 | <zewt> | well, i think it's trying to be too magic--don't try to figure out when I'm done, give me a "finishedWithAllTests" to call |
| 22:56 | <jgraham> | There is |
| 22:57 | <zewt> | but they have to run after onload, since they need to load iframes |
| 22:57 | <jgraham> | But it is off by default |
| 22:57 | <jgraham> | * == Determining when all tests are complete == |
| 22:57 | <jgraham> | * |
| 22:57 | <jgraham> | * By default the test harness will assume there are no more results to come |
| 22:57 | <jgraham> | * when: |
| 22:57 | <jgraham> | * 1) There are no Test objects that have been created but not completed |
| 22:57 | <jgraham> | * 2) The load event on the document has fired |
| 22:57 | <jgraham> | * |
| 22:57 | <jgraham> | * This behaviour can be overridden by setting the explicit_done property to true |
| 22:57 | <jgraham> | * in a call to setup(). If explicit_done is true, the test harness will not assume |
| 22:57 | <jgraham> | * it is done until the global done() function is called. Once done() is called, the |
| 22:58 | <jgraham> | * two conditions above apply like normal. |
| 22:59 | <zewt> | k |
| 22:59 | <jgraham> | In the futuure the default could change |
| 23:00 | jgraham | -> sleep |
| 23:09 | <erlehmann> | the body thing on the list is pretty strange |
| 23:09 | <erlehmann> | what the hell is this usario thinking? |
| 23:10 | <zewt> | "i found a spec mailing list and I want to suggest something" |
| 23:17 | <TabAtkins> | erlehmann: He's obvious fallen into the trap of solving an attractively easy problem without checking to see if it's actually a problem. |
| 23:17 | <TabAtkins> | In this case, "'body' doesn't sound like a properly semantic name for the page content". |
| 23:29 | <zewt> | i'm trying not to read this <body> thread but driving past a car crash, etc |
| 23:29 | <TabAtkins> | Mute it. It's not worth reading. He doesn't want to provide a problem. |
| 23:32 | <erlehmann> | tabAtkins, there was a nice talk about “how to fail at teaching people stuff” from kathrin passig at re:publica 2010. step 1: wait until they think they have a problem. :) |
| 23:32 | <TabAtkins> | I already asked him clearly and unambiguously to find out what problem he's trying to solve. ^_^ |
| 23:33 | <zewt> | careful; he's more likely to interpret that as "retroactively find a problem to justify the change you started at" |
| 23:34 | <TabAtkins> | That's not an issue; you can then just point out that the problem isn't important. |
| 23:53 | <erlehmann> | tabAtkins, this may or may not be fun. happy trolling :) |
