/irc-logs / freenode / #whatwg / 2010-07-15 / end

Options:

# Session Start: Thu Jul 15 00:00:00 2010
# Session Ident: #whatwg
# [00:00] <eseidel> Hixie: I'm not sure I understand
# [00:00] <Hixie> which bit?
# [00:00] <eseidel> once you've create a text node, it can't be using parser buffers
# [00:00] <eseidel> you might have to make the text node's buffers bigger if you append to it, yes.
# [00:01] <eseidel> Hixie: I mena, there are some nice things about the way the spec is worded. prevnets strange things when scripts start inserting text nodes
# [00:01] <eseidel> it won't be hard to implement
# [00:01] <eseidel> Hixie: just noting that both WK and minefield fail that example atm
# [00:01] <eseidel> Hixie: but I'm not against implementing it that way
# [00:01] <Hixie> ah ok
# [00:01] <Hixie> i misunderstood, sorry :-)
# [00:02] <Hixie> usually when people tell me the browsers don't match the spec it's a passive aggressive way of telling me the spec is wrong :-)
# [00:02] * Joins: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net)
# [00:02] <abarth> svn.whatwg.org is slow...
# [00:03] <abarth> soon i will have my own clone of the HTML5 repo and there will be no stopping me :)
# [00:06] <Hixie> who is eric@webkit.org? is that eseidel?
# [00:07] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Read error: Connection reset by peer)
# [00:08] <jgraham> I thought hsivonen was one of the people asking for the multiple-test-nodes thing before
# [00:08] <jgraham> But I could be wrong. I recall having a conversation with Philip` about it
# [00:08] <abarth> Hixie: yes
# [00:08] <eseidel> Hixie: there can be only one!
# [00:09] <abarth> we're looking at the details of text node coalessing
# [00:09] <abarth> looks like the new Firefox doesn't quite follow the spec
# [00:09] <abarth> in crazy foster parenting cases
# [00:09] <Hixie> eseidel: i couldn't understand one of your bugs, so i marked it NEEDSINFO
# [00:10] <zcorpan_> eseidel: try the zombie dom viewer for ie
# [00:10] <Hixie> eseidel, abarth, hsivonen, zcorpan_, jgraham: I've resolved every parser bug I could find and every bug marked P1/crit; if I missed any please mark them P1/crit and let me know
# [00:11] <abarth> Hixie: thanks. that's super helpful
# [00:11] <Hixie> np
# [00:11] <Hixie> sorry it took so long
# [00:11] <jgraham> Hixie: Awesome
# [00:11] <abarth> Hixie: did you look at the script@onload bug after you closed it?
# [00:11] <abarth> Hixie: i'm not sure whether i'm misunderstanding the spec or whether your rationale is backwards
# [00:12] <abarth> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984
# [00:12] <jgraham> I verified that the end tag in foreign content fixes worked the way I expected in the html5lib test cases
# [00:12] <jgraham> I mean I verified that html5lib with the new spec passed the tests
# [00:13] <Hixie> jgraham: cool, i wasn't sure if what i did there made sense, thanks
# [00:13] <Hixie> abarth: looking
# [00:13] <jgraham> Hixie: Did hsivonen file a bug about <button>? I forget
# [00:13] <Hixie> didn't see one
# [00:13] <jgraham> Hixie: I think it was more-or-less equivalent to my ad-hoc fixes, but expressed in a slightly simpler way
# [00:14] <jgraham> Hixie: The list of bugs that I know about is http://wiki.whatwg.org/index.php?title=ParserIssues
# [00:14] <Hixie> abarth: hm, no, you're right, i forgot how the spec was written
# [00:14] <Hixie> abarth: i don't understand the bug then
# [00:14] <Hixie> abarth: what do you want changed?
# [00:14] <Hixie> jgraham: looking...
# [00:15] <jgraham> Hixie: It seems that you did change <button> somewhat
# [00:15] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Ping timeout: 248 seconds)
# [00:15] <Hixie> abarth: (btw feel free to reopen bugs -- i don't see changes unless the bug is reopened)
# [00:15] <Hixie> jgraham: all those bugs are resolved
# [00:15] <abarth> Hixie: it's a place where FF and the spec are different. i don't particularly care about the behavior, but we either need to change the spec or get henri to agree to do what the spec says
# [00:16] <Hixie> jgraham: and the e-mail had a bug for it too so that's dealt with now also
# [00:16] <Hixie> abarth: ah ok
# [00:16] <abarth> there's some subtly involving the requirements of an off-the-main-thread parser, which I don't quite grasp
# [00:17] <Hixie> i'm not sure how we would change things to have it happen the other way around to be honest, looking at the spec more closely now
# [00:18] <Hixie> short of just making the insertion pointer or whatever it's called undefined just for the event
# [00:19] <abarth> ok
# [00:20] <abarth> in the code, it's just a matter of switching the order of two lines of code
# [00:20] <abarth> so we can do whichever
# [00:20] <daedb_> heh, IE9 is really funny... <!doctype html><canvas></canvas> puts the canvas inside the body, but <!doctype html><style></style><canvas></canvas> puts canvas inside the head :)
# [00:20] <abarth> Hixie: one more thing: https://bugs.webkit.org/show_bug.cgi?id=42112
# [00:20] <jgraham> abarth: Thanks for the reply about the cross-domain stuff. That looks like exactly what I was hoping for :)
# [00:20] <AryehGregor> daedb_, yeah . . . HTML5 parser plz :(
# [00:20] <abarth> Hixie: ap is worried about the null character's replacements looking ugly
# [00:21] <abarth> Hixie: that bug has a link to some chinese site that looks pretty bad
# [00:21] <cardona507> daedb_: yeah - IE9 is wacky
# [00:21] <daedb_> AryehGregor: I found that with your test case :p
# [00:21] <abarth> jgraham: glad it was helpful
# [00:21] <abarth> Hixie: the old webkit behavior was to strip nulls in text nodes, but not in tag names, etc
# [00:21] <jgraham> abarth: (I haven't actually read it in detail yet)
# [00:23] * Joins: sicking (~chatzilla@nat/mozilla/x-qwgktgcwelwohzzh)
# [00:24] <sicking> if I change something in browser/components/feeds , where do I need to rebuild to pick that up?
# [00:24] <abarth> sicking: wrong channel?
# [00:24] <sicking> abarth: hah, yes indeed :)
# [00:24] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:25] <sicking> chatzilla doesn't have optimal focus management :)
# [00:25] * Joins: aho (~nya@fuld-4d00d22e.pool.mediaWays.net)
# [00:27] <Hixie> abarth: yeah, it's basically intentional
# [00:27] <Hixie> abarth: there shouldn't be NULs there at all and they're likely to be triggering all kinds of security problems
# [00:27] <Hixie> abarth: making it ugly is one way to draw attention to it
# [00:29] <abarth> as brendan would say, i don't have a dog in this hunt. I've forwarded your comments to ap.
# [00:30] <ap> Hixie: I doubt there is actually a security aspect to null handling in DOM
# [00:30] <Hixie> there have been _many_
# [00:30] <ap> Hixie: maybe in 199x
# [00:31] <ap> Hixie: there were more recent "security" issues about stripping nulls from tags, but those were very remotely related to security, in my opinion
# [00:31] <jgraham> Hmm, Opera typically doesn't render past embedded nulls, so we are presumably badly broken with any site that has lots of them
# [00:32] <jgraham> So a link would be appreciated :)
# [00:32] <ap> jgraham: https://bugs.webkit.org/show_bug.cgi?id=42112
# [00:33] * Quits: bobchao (~cctw@112.105.96.241) (Quit: Leaving.)
# [00:33] <ap> Hixie: and by the way, the more recent "security" issues were caused exactly by the attempts to give null some magical meaning, so some software might have potentially gotten it differently than other
# [00:34] <jgraham> abarth: So are the security problems with the "subspace" design considered acceptable because it is too hard to inject code into an unwilling site this way, only one that specifically uses the design?
# [00:34] <zcorpan_> jgraham: opera renders past nulls but not in view source
# [00:35] <abarth> jgraham: the security problems arise from using these document.domain tricks. the recommended course of action is to ignore document.domain and use postMessage instead
# [00:35] <abarth> jgraham: document.domain is very complex and best ignored
# [00:36] <jgraham> abarth: From the point of view of a browser implementor though
# [00:37] <jgraham> Obviously we have to support document.domain
# [00:37] <jgraham> (I agree that *sites* shouldn't use it)
# [00:38] <jgraham> (the rough context is that I want to be sure that implementing the HTML5 spec in Opera won't open up any significant security vunerabilities or privacy leaks or whatever compared to what we currently do)
# [00:39] <jgraham> zcorpan_: Oh.
# [00:39] <abarth> jgraham: yep
# [00:39] <abarth> there's a deeper issue is opera
# [00:39] <abarth> last time i checked
# [00:39] <abarth> opera used dynamic instead of lexical authorization
# [00:39] <abarth> which makes the document.domain attacks easier to pull off
# [00:40] * Quits: JonathanNeal (~JonathanN@76.79.114.210) (Quit: Leaving)
# [00:40] <abarth> HTML5 requires lexical authorization
# [00:40] <abarth> and opera might have switched since i tested it last
# [00:40] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Remote host closed the connection)
# [00:40] <abarth> http://www.adambarth.com/papers/2009/barth-jackson-li.pdf
# [00:40] <jgraham> I am not sure I understand the difference
# [00:40] <abarth> Section 2.1
# [00:40] <jgraham> But I will read the paper :)
# [00:41] <abarth> in the spec
# [00:41] <abarth> it's the difference between the active script
# [00:41] <abarth> and the "first script"
# [00:41] <jgraham> Ah
# [00:41] <abarth> if you're able to run the webkit security layout tests
# [00:41] <jgraham> OK. I remember that being "fun"
# [00:41] <abarth> there's a bunch of stuff in there about that
# [00:42] <jgraham> We can probably find a way to run those
# [00:42] <jgraham> and really should be if we are not already
# [00:42] <Hixie> ap: that has not been my experience, but i guess our experiences can differ :-)
# [00:42] <ap> Hixie: can you point me to some bugs caused by null terminated strings used in DOM?
# [00:43] <Hixie> not off-hand
# [00:43] * Quits: aroben (~aroben@unaffiliated/aroben) (Quit: aroben)
# [00:43] <jgraham> abarth: Thanks
# [00:43] * jgraham decides it is time for slep
# [00:43] <jgraham> *sleep
# [00:43] <ap> Hixie: and that wouldn't happen if nulls were inserted via DOM manipulation (nulls are still allowed there, correct?)
# [00:44] * Quits: variable (~variable@unaffiliated/variable) (Ping timeout: 240 seconds)
# [00:44] <Hixie> abarth: "first script" was renamed at some point btw (i forget to what)
# [00:45] <Hixie> ap: most of the kinds of bugs i've seen reently have been with server-side tools treating NULLs differently than browsers, and failing to properly filter content
# [00:45] * Quits: BlurstOfTimes (~blurstoft@168.203.103.106) (Remote host closed the connection)
# [00:45] <Hixie> ap: but NULLs in general are frequently the source of random bugs, and I really would rather never have to worry about it, hence why I always try to write specs to get rid of them as soon as possible
# [00:45] <ap> Hixie: yes, that's the kind I referred to as "security"
# [00:45] * Joins: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net)
# [00:45] * Quits: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net) (Client Quit)
# [00:46] <Hixie> ap: i see no harm in doing so, especially considering how rare NULLs are in "real" content
# [00:46] <ap> Hixie: that's not the first time I say that I disagree with this general principle :)
# [00:46] <Hixie> ap: i know
# [00:47] <ap> Hixie: you may be giving some a false sense of security - they'll write code expecting that the parser gets rid of nulls for them, and then a Dom manipulation will insert a null
# [00:47] <ap> Hixie: also, these new requirements are breaking existing content, and slow down decoding/tokenizing slightly
# [00:47] * Joins: remysharp (~remysharp@cpc2-brig17-2-0-cust448.3-3.cable.virginmedia.com)
# [00:48] <Hixie> ap: there are pros and cons on both sides
# [00:48] <Hixie> ap: such is life
# [00:48] <ap> Hixie: I suggest that we don't make changes that are not for the better then
# [00:49] <Hixie> ap: i disagree that it's not for the better.
# [00:49] * Quits: remysharp (~remysharp@cpc2-brig17-2-0-cust448.3-3.cable.virginmedia.com) (Remote host closed the connection)
# [00:49] <ap> Hixie: at this point, I struggle to find a use case that's improved by converting nulls to u+fffd
# [00:49] <Hixie> ap: i think it improves security for most users of the HTML parser (who don't have a DOM to worry about), and it doesn't break enough content to be an issue, and the performance impact is minimal.
# [00:50] <Hixie> ap: but as you say, we've had this discussion before
# [00:50] <Hixie> ap: we're not covering new ground here
# [00:50] <ap> Hixie: ah, the eternal "HTML is not for browsers" argument
# [00:50] <ap> Hixie: well, previously we were talking about new specs, not about changing HTML in incompatible ways
# [00:50] <Hixie> if you're just going to misrepresent what i'm arguing then there's not much point me arguing
# [00:51] <ap> Hixie: I didn't intend to misinterpret. did I misunderstand you?
# [00:51] <Hixie> i didn't say HTML was not for browsers
# [00:52] <ap> Hixie: well, you said that most users of HTML parser don't have the DOM to worry about
# [00:52] <Hixie> indeed
# [00:52] <Hixie> only five users of the HTML parser have a DOM to worry about
# [00:52] <Hixie> out of all the people who parse HTML, that's not the majority
# [00:52] <Hixie> it also happens to the be most competent at writing and using HTML arasers
# [00:52] <Hixie> parsers, even
# [00:53] <Hixie> and thus not the most important when it comes to making sure that it's easy to not screw up
# [00:53] <Hixie> s/to the be/to be the/
# [00:53] <ap> Hixie: it seems to be the primary target of security attacks though
# [00:53] <ap> Hixie: btw, my understanding is that some Web spiders are now interpreting JS already - is that not true?
# [00:54] <abarth> ap: that's correct
# [00:55] <Hixie> are you saying that abarth and eseidel are so incompetent that what I do with NULLs in the HTML5 spec will affect the number of security bugs in their code? give me a break
# [00:55] * Quits: eseidel (~eseidel@c-98-210-108-185.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [00:55] <abarth> ap: they tend to take a browser and hack it up to get it to crawl nicely
# [00:55] * Joins: eseidel (~eseidel@c-98-210-108-185.hsd1.ca.comcast.net)
# [00:57] <ap> Hixie: it sounds like the only case that's helped by this change is code that incorporates a full HTML5 tokenizer, and then does something truly naive with it
# [00:57] <ap> Hixie: since otherwise, they will happily convert null to null, not knowing that there is a spec saying it should be turned into FFFD
# [00:57] <Hixie> you've just described a large portion of future HTML parsing software
# [00:59] <ap> Hixie: are you saying that it will be easier to incorporate an HTML5 library than to use whatever scripting language mechanism there is to convert a result of a curl/wget download to a native string?
# [01:00] <Hixie> do you think that's what i'm saying?
# [01:00] <ap> Hixie: yes
# [01:00] <Hixie> could you please at least assume i'm not an idiot?
# [01:00] <Hixie> seriously
# [01:01] <ap> Hixie: you're probably moving too fast for me to follow
# [01:01] <Hixie> it will obviously not be easier to wget a file, turn it into a string, and then pass it to a parser than it will be to wget a file, and turn it into a string.
# [01:02] <ap> Hixie: you said that a "large portion of future HTML parsing software" will do something, and I'm trying to imagine how I would write a piece of software that would fit the picture
# [01:02] <Hixie> to parse HTML, you can either hack it using regexps, or you can use an HTML parser
# [01:02] <Hixie> few people will write their own HTML parsers, since it's a non-trivial task
# [01:03] <ap> Hixie: yes, if the software doesn't need a DOM, they'll probably just regex parts of wget output
# [01:03] <Hixie> there's nothing we can ever do to make regexp parsers do anything, since they ignore the spec by definition
# [01:03] <Hixie> so all we can affect are the people using the libraries, which presumably follow the spec
# [01:03] <ap> Hixie: and if there is a DOM, they can shoot themselves in the foot even if they don't execute JS from the documents
# [01:04] <Hixie> dude, they can shoot themselves in the foot without any help from us
# [01:04] <Hixie> the idea is to reduce the likelihood of that
# [01:04] <Hixie> we can never make it impossible
# [01:04] <ap> Hixie: what I'm saying is that it's not reducing the likelihood, but giving a false expectation
# [01:04] <Hixie> and i disagree
# [01:04] <Hixie> i don't think it's giving anyone any expectation
# [01:05] <Hixie> since these people aren't going to know about this at all
# [01:05] <Hixie> anyway i really have to do work
# [01:05] * Joins: slartsa_ (~Lari@adsl-215-234-204.kymp.net)
# [01:05] <Hixie> if you want this changed, please file a bug or send mail
# [01:07] <ap> there is a WebKit bug, that's my form of feedback
# [01:08] * Quits: slartsa (~Lari@adsl-215-234-204.kymp.net) (Ping timeout: 240 seconds)
# [01:09] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
# [01:12] * Quits: zcorpan_ (~zcorpan@c-d798e355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan_)
# [01:12] * Joins: cfq (~cfq@94-194-98-91.zone8.bethere.co.uk)
# [01:15] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Quit: zzzzz)
# [01:18] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
# [01:18] * Joins: mmn (~mmn@129-97-120-104.uwaterloo.ca)
# [01:22] * Quits: eseidel (~eseidel@c-98-210-108-185.hsd1.ca.comcast.net) (Quit: eseidel)
# [01:23] * Joins: karlcow (~karl@nerval.la-grange.net)
# [01:26] <TabAtkins> AryehGregor: I have now violently disagreed with you publicly.
# [01:26] <TabAtkins> After consulting with Chrome team. ^_^
# [01:28] <TabAtkins> The main problem is that a true gaussian simply isn't fast enough, and Safari has seen negative effects from trying to use one for all shadows.
# [01:37] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [01:45] <AryehGregor> TabAtkins, rest assured you will see a violent response in return, likely tomorrow.
# [01:45] * Joins: mpt (~mpt@canonical/mpt)
# [01:45] * Quits: mpt (~mpt@canonical/mpt) (Read error: Connection reset by peer)
# [01:46] <TabAtkins> Ok. I'm basing my position on feedback from our graphics people (smfr, who you talked to as well, plus jamesr and a newer dude who previous worked on game graphics), so I think I'm on pretty solid ground wrt the "gaussians are too expensive" argument.
# [01:47] <AryehGregor> Then how does everyone (3/3 tested on two platforms) do them interoperably in SVG filters? Aren't those applied just as often as CSS shadows?
# [01:47] <TabAtkins> Slowly, that's how. And no, they're not.
# [01:47] <AryehGregor> Why not?
# [01:48] <TabAtkins> Why aren't SVG shadows applied as often as CSS shadows? I dunno.
# [01:48] <AryehGregor> In Firefox you can even apply SVG filters to HTML content.
# [01:48] <TabAtkins> Yes?
# [01:48] <AryehGregor> Well, anyway, the spec should at least give a pixel-perfect reference shadow, and tell browsers "try to get close to that", so at least they're shooting at the same target.
# [01:49] <AryehGregor> Hixie, do you think it would be worth it at this point to change the meaning of canvas.shadowBlur to something sane, instead of the weird kink at 8? My testing indicates that browsers aren't interoperable here at all, so authors can't be relying too much on the current behavior. If the answer is "no" then I'll close the HTML bug I filed and file some bugs against browsers that don't do it right (Firefox/Chrome).
# [01:49] <TabAtkins> I'm fine with providing an informative reference.
# [01:49] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [01:50] <AryehGregor> Also, if Gaussian blurs really are too slow here, surely that needs to be changed in SVG too, especially if SVG filters are allowed for HTML content.
# [01:50] * Quits: tndH (~Rob@cpc5-seac20-2-0-cust2.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
# [01:50] <TabAtkins> Perhaps.
# [01:50] <AryehGregor> I assume there's no problem at all with canvas, since you only need to compute the shadow once.
# [01:50] <AryehGregor> (which is why it's ironic that we have so much less interop there than with SVG . . .)
# [01:51] <TabAtkins> Yeah, most likely the slowness is unimportant in <canvas>.
# [01:51] <AryehGregor> I can't see why SVG would be less of a perf problem than CSS, except because people rarely use SVG, which seems likely to change when IE9 becomes widely used.
# [01:51] <TabAtkins> Also, as authors have direct control over their <canvas> stuff, they can choose to do a less expensive shadow manually if they find they need to.
# [01:51] <TabAtkins> I expect that's precisely the reason.
# [01:52] * Joins: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp)
# [01:52] <TabAtkins> SVG has many things that are bad perf-hits.
# [01:52] <AryehGregor> You're saying authors rolling their own shadow in JavaScript would be cheaper than Gaussian blur? I find that unlikely.
# [01:52] <TabAtkins> AryehGregor: With a sufficiently large shadow? Could be.
# [01:52] <AryehGregor> Maybe CSS has the problem that it can be reflowed, so you might have to reevaluate the shadow many times per second as something moves across the screen or whatnot.
# [01:52] <AryehGregor> Whereas if it's an SVG, this is less likely? I dunno.
# [01:53] <TabAtkins> That is a significatn part of the CSS issue, yes. I dunno what the deal is with SVG, so I can't really comment.
# [01:53] * AryehGregor will seek clarification on the list.
# [01:53] <AryehGregor> (tomorrow)
# [01:54] <TabAtkins> In any case, I still don't have a problem with an impl that can afford to burn the cycles doing a more realistic shadow than gaussian blurs can provide. ^_^
# [01:55] <AryehGregor> What does "more realistic" mean? Like more physically accurate? Is it possible for a normal person to tell if a box shadow is more or less physically accurate?
# [01:55] <TabAtkins> Probably not.
# [01:55] <AryehGregor> Authors are looking for a specific visual style, surely, not physical accuracy.
# [01:55] <AryehGregor> So it doesn't matter so much what it looks like, as long as it's interoperable.
# [01:55] <TabAtkins> But then, a normal person can't tell the difference between a CG shadow and Skia shadow for normal font-sizes and blurs.
# [01:56] <AryehGregor> Are you talking text-shadow or box-shadow? For boxes, I can tell the difference between how Safari and Chrome do canvas shadows on Windows 7 very clearly.
# [01:56] <AryehGregor> They're similar, though.
# [01:56] <AryehGregor> (Firefox is much more different, IIRC)
# [01:56] <TabAtkins> What size, and is it a difference of actual blur radius producing different-sized shadows?
# [01:57] <AryehGregor> Just the example I gave before.
# [01:57] <TabAtkins> Okay, so that's a width of somewhere between 10px and 15px.
# [01:57] <TabAtkins> When I say "normal font-sizes and blurs" I mean smaller than that.
# [01:58] <TabAtkins> shadows on heading text, frex, are usually less than 8px.
# [01:58] <TabAtkins> Often just 2px or 4px, I think.
# [01:58] <AryehGregor> data:text/html,<!doctype html><style>* { margin: 0 }</style><canvas height="300" width="300"></canvas><script>window.addEventListener('load', function () { context = document.getElementsByTagName("canvas")[0].getContext("2d"); context.shadowBlur = 12.5; context.shadowOffsetX = 400; context.shadowOffsetY = 400; context.shadowColor = 'black'; context.fillRect(-300, -300, 100, 100); }, false);</script>
# [01:59] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
# [01:59] * Joins: ConnorMontgomery (~connormon@cpe-76-92-203-96.kc.res.rr.com)
# [02:00] <AryehGregor> Blur on text-shadows might be less noticeable. I dunno. I'd think that simpler blur effects would make sense where you're working with so few pixels.
# [02:00] <AryehGregor> Anyway, I'm off for the night.
# [02:01] <TabAtkins> That's precisely my point. ^_^ Specifying that we *must* use a gaussian, though, prevents that.
# [02:01] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
# [02:02] * Quits: ConnorMontgomery (~connormon@cpe-76-92-203-96.kc.res.rr.com) (Client Quit)
# [02:06] * Joins: apucacao (~apucacao@S010600226b6dbc54.vc.shawcable.net)
# [02:12] * Joins: variable (~variable@unaffiliated/variable)
# [02:15] * Quits: m_W (~mwilcox56@c-68-38-230-216.hsd1.nj.comcast.net) (Read error: Connection reset by peer)
# [02:21] * Quits: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net) (Quit: Leaving...)
# [02:22] <Hixie> AryehGregor: i would recommend getting the relevant browser devs together and getting them to implement something, then telling me what they implemented and i'll update the spec
# [02:24] <Philip`> What kind of shadow implementation would be faster than a Gaussian?
# [02:24] <TabAtkins> Lots.
# [02:25] <Philip`> The only thing I can imagine is if you have a sharper falloff so you can use a smaller filter
# [02:25] <TabAtkins> Frex, a downscale+upscale to fuzz details.
# [02:25] <TabAtkins> Or the "just average all the pixels" that I think Skia does.
# [02:34] * Quits: ap (~ap@17.246.17.28) (Quit: ap)
# [02:37] * Joins: miketaylr (~miketaylr@24.42.95.108)
# [02:38] * Joins: seventh (galofort@208.98.1.237)
# [02:39] <Hixie> um
# [02:39] <Hixie> i can't log into the wiki
# [02:39] <Hixie> wtf
# [02:40] <Hixie> AryehGregor!!!! help!!! :-)
# [02:41] <Hixie> i get "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please hit "back" and reload the page you came from, then try again"
# [02:42] <Hixie> oh, i know why
# [02:42] <Hixie> the /tmp directory is full
# [02:43] <Hixie> variable: you around?
# [02:43] <variable> Hixie, yeah?
# [02:43] <variable> let me clear /tmp
# [02:43] <Hixie> thanks
# [02:43] * Quits: jlebar (~jlebar@nat/mozilla/x-cogdzfnkdsoqspow) (Ping timeout: 240 seconds)
# [02:43] <Hixie> :-)
# [02:43] <variable> Hixie, I just got back from dinner ;)
# [02:44] <Hixie> looks like it's making huge temp files in /tmp and preventing other things on my account from working (like the whatwg wiki)
# [02:44] <Hixie> is there some way to move it to using ~/tmp instead?
# [02:44] <Hixie> that would be ideal
# [02:44] <Hixie> the quota there is far bigger
# [02:44] <variable> Hixie, yeah - I'm looking now
# [02:45] <variable> find: cannot delete ./sess_l4orkhk5sgiish85nqv7dpck27: Operation not permitted
# [02:45] <Hixie> yeah don't worry about the ones you don't own
# [02:45] <Hixie> woohoo, that worked
# [02:45] <Hixie> ok, wiki login is fixed
# [02:46] <TabAtkins> Oh wow, got a totally sweet embossing effect.
# [02:46] * TabAtkins was trying to make the spec's edge-detection example for <canvas> work at a usable speed for live video.
# [02:46] <variable> sorry about leaving it like that - I didn't realise other stuff was broken
# [02:46] <Hixie> variable: no worries, nor did i :-)
# [02:46] <variable> I'm going to back to work on it.
# [02:46] <variable> I'll monitor the wiki while I'm trying to move to ~/tmp
# [02:47] <Hixie> so long as df doesn't say /tmp is at 100% you should be fine
# [02:48] <variable> heh - ok
# [02:48] <variable> I'm thinking this might be *svns* tmp dir and not WebSVN
# [02:49] <Hixie> the files were owned by your user so that's unlikely
# [02:49] <Hixie> it could be the svn client run by websvn
# [02:49] <variable> exactly: websvn runs the svn command using system() IIRC
# [02:49] <Hixie> ah yeah
# [02:49] <Hixie> could totally be that
# [02:50] <Hixie> try changing the TMP variable maybe?
# [02:50] <Hixie> environment variable, i mean
# [02:50] <variable> Hixie, erm - that variable has to be set in the PHP file.
# [02:50] <Hixie> hmm
# [02:51] <variable> if I set TMP in the env. the PHP file won't see it.
# [02:51] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
# [02:52] <Hixie> yeah
# [02:52] <Hixie> i have no idea how to change this
# [02:52] <variable> Hixie, I'm looking now
# [02:53] <variable> /tmp might fill up a few times while I test to see if it worked but I'll fix it
# [02:54] <Hixie> no worries
# [02:55] * Quits: MikeSmith (~MikeSmith@EM114-48-19-245.pool.e-mobile.ne.jp) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
# [02:58] * Quits: Yudai (~Yudai@p034a6d.kngwnt01.ap.so-net.ne.jp) (Quit: SIGTERM received; exit)
# [02:58] * Joins: Yudai (~Yudai@p034a6d.kngwnt01.ap.so-net.ne.jp)
# [03:14] * Joins: titacgs (~titacgs@190.2.33.49)
# [03:17] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
# [03:20] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [03:21] * Joins: wakaba_ (~wakaba_@203-140-90-184.eonet.ne.jp)
# [03:21] <titacgs> hi! I'm working on a html5 project which includes sharing the webapp I'm making between users, I was reading about the shared workers but it is not supported by firefox yet
# [03:21] <titacgs> is there a work around for this?
# [03:25] <TabAtkins> Shared Workers aren't meant for sharing computation across users. They're meant for sharing computation (or providing communication) across windows opened by a single user.
# [03:25] <TabAtkins> (By "arent' meant for" I mean "can't be used for".)
# [03:28] <titacgs> mmmmmm
# [03:28] <titacgs> I see
# [03:30] * Joins: cying (~cying@75-25-137-159.lightspeed.plalca.sbcglobal.net)
# [03:30] * Quits: slightlyoff (~slightlyo@nat/google/x-tbtvvgflnzorlbio) (Quit: slightlyoff)
# [03:32] <titacgs> and how can I accomplish this? I mean what tools will help me to share information between users in real time or at least with a small difference of time
# [03:33] * Quits: mmn (~mmn@129-97-120-104.uwaterloo.ca) (Quit: Leaving.)
# [03:36] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [03:40] * Quits: cying (~cying@75-25-137-159.lightspeed.plalca.sbcglobal.net) (Quit: cying)
# [03:40] <Hixie> www.un.org is down.
# [03:41] <Hixie> well, not so much down, as it appears someone deleted all of it.
# [03:42] <variable> WebSVN has absolutely 0 documentation other than the comments in the source code. Great!
# [03:42] <Hixie> nice
# [03:45] * Joins: MikeSmith (~MikeSmith@EM114-48-216-42.pool.e-mobile.ne.jp)
# [03:50] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 246 seconds)
# [03:50] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [03:55] * Quits: arosenberg (~alexr@sceapdsd43-89.989studios.com) (Quit: arosenberg)
# [03:56] * Quits: dbaron (~dbaron@nat/mozilla/x-qqlkpbsmmoyesfdv) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:59] * Joins: mmn (~mmn@129-97-225-230.uwaterloo.ca)
# [03:59] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [04:01] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [04:04] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [04:07] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [04:07] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [04:07] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Client Quit)
# [04:08] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Ping timeout: 248 seconds)
# [04:14] * Quits: MikeSmith (~MikeSmith@EM114-48-216-42.pool.e-mobile.ne.jp) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
# [04:14] * Quits: sicking (~chatzilla@nat/mozilla/x-qwgktgcwelwohzzh) (Ping timeout: 246 seconds)
# [04:16] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [04:20] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [04:25] * Joins: MikeSmith (~MikeSmith@133.27.228.171)
# [05:18] * Quits: weinig (~weinig@17.246.16.234) (Quit: weinig)
# [05:36] * Quits: miketaylr (~miketaylr@24.42.95.108) (Remote host closed the connection)
# [05:43] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
# [05:48] * Quits: titacgs (~titacgs@190.2.33.49) (Ping timeout: 264 seconds)
# [05:52] * Joins: cedricv (~cedric@202.152.243.113)
# [06:03] * Joins: yoshiaki (~yoshiaki@133.27.228.172)
# [06:13] * Quits: variable (~variable@unaffiliated/variable) (Ping timeout: 240 seconds)
# [06:19] * Joins: bobchao (~cctw@112.105.96.241)
# [06:23] * Joins: kennyluck (~kennyluck@133.27.228.178)
# [06:23] * Quits: kennyluck (~kennyluck@133.27.228.178) (Excess Flood)
# [06:32] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
# [06:35] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Ping timeout: 245 seconds)
# [06:36] * Joins: dave_levin (~dave_levi@nat/google/x-hfqvfkkktumlkxgv)
# [06:37] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [06:37] * Parts: mmn (~mmn@129-97-225-230.uwaterloo.ca)
# [06:40] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
# [06:49] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [06:51] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [06:59] * Quits: apucacao (~apucacao@S010600226b6dbc54.vc.shawcable.net) (Quit: apucacao)
# [07:08] <boblet> sanity check: Opera doesn’t support linear gradients yet?
# [07:21] <roc> you mean CSS gradients?
# [07:33] * Joins: kennyluck (~kennyluck@133.27.228.178)
# [07:48] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
# [07:48] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Quit: roc)
# [07:51] <boblet> roc: yep
# [07:51] <boblet> doh!
# [07:55] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
# [07:58] * Quits: yoshiaki (~yoshiaki@133.27.228.172) (Remote host closed the connection)
# [07:59] * Joins: yoshiaki (~yoshiaki@133.27.228.172)
# [08:00] * Quits: MikeSmith (~MikeSmith@133.27.228.171) (Ping timeout: 252 seconds)
# [08:00] * Joins: MikeSmith (~MikeSmith@EM114-48-27-68.pool.e-mobile.ne.jp)
# [08:04] <Hixie> TabAtkins_: yt?
# [08:06] * Quits: cedricv (~cedric@202.152.243.113) (Remote host closed the connection)
# [08:06] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
# [08:07] * Joins: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams)
# [08:08] * Quits: drry (~drry@unaffiliated/drry) (Ping timeout: 264 seconds)
# [08:08] * Quits: bobchao (~cctw@112.105.96.241) (Ping timeout: 240 seconds)
# [08:08] * Joins: drry (~drry@unaffiliated/drry)
# [08:12] * Quits: othermaciej (~mjs@17.246.19.125) (Quit: othermaciej)
# [08:15] * Joins: mmn1 (~mmn@129-97-225-230.uwaterloo.ca)
# [08:15] * Parts: mmn1 (~mmn@129-97-225-230.uwaterloo.ca)
# [08:19] <Hixie> so anyone want to write the CP for ISSUE-109?
# [08:19] <Hixie> that is, a counter-CP to http://www.w3.org/html/wg/wiki/ChangeProposals/ariasection
# [08:22] * Joins: tndH (~Rob@cpc5-seac20-2-0-cust2.7-2.cable.virginmedia.com)
# [08:23] <abarth> that proposal is so trivial
# [08:23] <abarth> i'm not even sure how to respond to it
# [08:25] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 248 seconds)
# [08:27] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [08:29] * Joins: deepthawtz (~deepthawt@c-67-180-160-250.hsd1.ca.comcast.net)
# [08:37] <Hixie> abarth: i wrote one
# [08:38] <annevk> boblet, I don't think so
# [08:38] <boblet> annevk: thanks (will cry a little now)
# [08:38] * Quits: deepthawtz (~deepthawt@c-67-180-160-250.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [08:39] * Joins: deepthawtz (~deepthawt@c-67-180-160-250.hsd1.ca.comcast.net)
# [08:39] <Hixie> how about issues 74 and 105, the canvas accessibility ones
# [08:39] <Hixie> anyone want to make a case for the existing text?
# [08:40] * Joins: Amorphous (jan@unaffiliated/amorphous)
# [08:41] <Hixie> or 32, the summary="" one
# [08:43] <Hixie> gotta love http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility
# [08:43] * Joins: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl)
# [08:44] <Hixie> "Currently the spec does not include requirements for implementers on how to provide accessible focus rectangles [...] The details of the proposal are [...] A change to drawFocusRing()"
# [08:46] <annevk> I think I've been Change Proposal tired since before we started with them
# [08:46] <Hixie> my god this proposal is messed up
# [08:47] <Hixie> it has authoring conformance criteria literally in the middle of a UA algorithm
# [08:47] <Hixie> it uses the wrong coordinate system
# [08:47] <Hixie> it's self-contradictory in fact about the coordinate system it uses
# [08:48] <Hixie> it has an entirely useless set of arguments for the focus ring
# [08:48] <Hixie> sigh
# [08:48] <annevk> so anything goes as a Change Proposal?
# [08:48] <annevk> maybe we should like MikeSmith's text generator come up with something good
# [08:49] <annevk> s/like/let/
# [08:49] <MikeSmith> my text generator has taken on a life of its own
# [08:49] <MikeSmith> somebody told me it opened up a twitter account for itself
# [08:50] * Joins: romeo (~romeo__@x1-6-00-07-95-57-08-bb.k459.webspeed.dk)
# [08:50] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Quit: justicefries)
# [08:50] <Hixie> seriously, read this:
# [08:50] <Hixie> http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/att-0054/2dcontext10-June-7.html#dom-context-2d-setCaretSelectionRect
# [08:51] <Hixie> the definition of setCaretSelectionRect
# [08:51] <Hixie> read that algorithm
# [08:51] <Hixie> it has authoring criteria, it has asynchronous requirements, and then it ends with "return true"
# [08:51] * Joins: kbrosnan (~kbrosnan@ip24-250-54-36.ri.ri.cox.net)
# [08:52] <Hixie> and that's ignoring the main problem of course, which is that the entire method is completely useless
# [08:52] <Hixie> it does nothing if you don't have an AT, so nobody will ever use it
# [08:52] <Hixie> plus it doesn't even do anything useful if you DO have an AT, since who on earth has a selection area that is just a rectangle with no associated selected text?
# [08:54] <annevk> oh lol
# [08:54] <Hixie> and then we have http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibilitynonav which introduces a content attribute to do what two lines of JS can do, even though to use it properly you'll still need to do those lines of JS but you'll -- in addition -- have to remove the attribute
# [08:54] <annevk> W3C should give a spec writing 101
# [08:55] <Hixie> and then we have http://www.w3.org/html/wg/wiki/ChangeProposals/addimagemaptocanvas which adds usemap to <canvas> despite there being basically no use cases for which that's useful
# [08:55] <Hixie> this is ridiculous
# [08:55] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [09:00] * Joins: bobchao (~cctw@202.39.243.252)
# [09:02] * Quits: bobchao (~cctw@202.39.243.252) (Remote host closed the connection)
# [09:02] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Quit: Rik`)
# [09:03] * Joins: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [09:06] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
# [09:10] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
# [09:11] * Joins: peol (~andree@91.213.250.10)
# [09:12] * peol is now known as Guest29845
# [09:12] * Quits: Guest29845 (~andree@91.213.250.10) (Changing host)
# [09:12] * Joins: Guest29845 (~andree@unaffiliated/peol)
# [09:12] * Guest29845 is now known as peol
# [09:16] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [09:16] * Joins: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu)
# [09:24] * Joins: zcorpan_ (~zcorpan@c-d798e355.410-6-64736c14.cust.bredbandsbolaget.se)
# [09:32] * Quits: dave_levin (~dave_levi@nat/google/x-hfqvfkkktumlkxgv) (Quit: dave_levin)
# [09:35] * Quits: deepthawtz (~deepthawt@c-67-180-160-250.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
# [09:40] * Joins: maikmerten (~maikmerte@port-92-201-196-56.dynamic.qsc.de)
# [09:42] * Joins: theMadness (~petal@host57-134-static.35-88-b.business.telecomitalia.it)
# [09:43] <jgraham> Crap, I need to follow up on the reply my email pointing out the problems with the canvas accessibility proposal that Hixie just mentioned
# [09:45] <Hixie> can you just write a CCP instead? :-)
# [09:45] <jgraham> Hixie: I'm told that the point of getCaretSelectionRect is just to provide the coordinates of the caret, not actually anything to do with selection
# [09:45] <Hixie> well then how is it different to the API we have in the spec today?
# [09:45] <Hixie> and why does it talk about the selection rect?
# [09:46] <jgraham> Unless I am misremembering (which is possible), it is supposed to cover the one character covered by the caret
# [09:46] <jgraham> But I didn't understand either so I am the wrong person to ask
# [09:46] <Hixie> carets don't usually cover characters...?
# [09:47] <Hixie> i wish that the change proposal process had a more defined problem description stage
# [09:47] <Hixie> as distinct from the solution proposal stage
# [09:47] <Hixie> currently we just run around like headless chickens spouting random proposals without ever considering what problem we're solving
# [09:47] <jgraham> I can't write a CCP because I don't know what a good solution is
# [09:47] <Hixie> it's just amateurish
# [09:47] <jgraham> I just know that CP isn't one
# [09:47] <Hixie> jgraham: the solution in the spec :-)
# [09:49] <othermaciej> regarding caret/selection position...
# [09:49] <jgraham> Hixie: Maybe :) I think trying to make a CP for an a11y topic that I don't have a strong view on is setting myself up for a world of hurt I don't need
# [09:50] <othermaciej> (1) there is definitely a use case for saying where in the text the caret or selection is, although you can represent that via the child DOM
# [09:50] <jgraham> I think the existing CP should be rejected on the basis that it is not a) workable or b) camera ready spec text
# [09:50] <Hixie> othermaciej: that's already handled by the child DOM
# [09:50] <othermaciej> (2) there is also a use case for the screen position of the caret or selection, for assistive technologies that would automatically zoom/center that area
# [09:50] <Hixie> and that's already handled by the current API
# [09:50] <jgraham> I got the impression that 2) was the interesting case here
# [09:51] <othermaciej> focus area is a rough approximation
# [09:51] <othermaciej> but may not be specific enough
# [09:51] <Hixie> the current API has a focus ring and a specific point for centering on
# [09:51] <jgraham> But I don't know why you need a width to do that
# [09:51] <othermaciej> so you should redraw the focus ring every time the caret moves?
# [09:52] <Hixie> yes
# [09:52] <othermaciej> if I wrote code like that in WebKit I would be fired
# [09:52] <othermaciej> but maybe the standards are lower for Web developers
# [09:52] <Hixie> well if you wrote code that had a text box in canvas i'd fire you long before you screwed up the caret painting
# [09:52] <Hixie> but apparently that's what we're trying to solve
# [09:52] <Hixie> so
# [09:53] <othermaciej> well, I advocated not supporting text drawing on the canvas at all, but apparently there are use cases for it
# [09:53] <annevk> they're trying to make bespin work
# [09:53] <Hixie> the problem with an explicit API just to focus on a caret is that there's no reason to call it _other_ than accessibility
# [09:53] <Hixie> which means most people won't call it, and most that will will call it in a buggy fashion
# [09:53] <Hixie> and we'll be no better off and possible worse off than if we had nothing
# [09:54] <annevk> might be more fruitful for a11y to work on DOM Range + CSS styling so bespin can move into a <textarea>
# [09:54] <Hixie> at least with the focus ring API there's a use case, it gets you free native focus ring drawing
# [09:54] <jgraham> It does seem odd to move the focus ring for every caret move though
# [09:54] <Hixie> i agree that it's suboptimal
# [09:54] <othermaciej> I don't think the bespin guys are remotely interested in moving off canvas, even if you made a good enough alternative
# [09:54] <othermaciej> Bespin doesn't even have a focus ring
# [09:55] <othermaciej> you would have to draw one offscreen to use this API
# [09:56] <othermaciej> heck, even in native Mac apps it's not uncommon that some text areas don't get focus rings
# [09:56] <jgraham> I suppose one could make the optimistic assumption that so few people will write editable-text-on-canvas that they will be unusually good developers and unusually likely to get it right
# [09:56] <jgraham> Although I am not really an optimist
# [09:57] <othermaciej> if it made sense to have an API to draw a caret, that would combine with a useful operation
# [09:57] <Hixie> oh we could do that
# [09:57] <othermaciej> but typically a caret would blink, and you can't handle that part for the developer
# [09:57] <Hixie> have it automatically determine the baseline positioning and so on
# [09:58] <Hixie> so you just give it the text x,y and the width of the text so far or something
# [09:58] <othermaciej> well, I suppose you can with a fancy enough API (you would have to call them to paint what was behind the caret, or save it in a buffer)
# [09:58] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [09:58] <jgraham> You could even support the blink rate stuff that they want :)
# [09:58] <Hixie> yeah
# [09:59] <Hixie> ignore the call if it's during an off period
# [09:59] <Hixie> i don't understand why we're discussing this in the change proposal system and not in the bug system
# [09:59] <Hixie> did i reject a change to the focus ring API at some point?
# [09:59] <othermaciej> I don't remember how canvas accessibility made it into the issue system
# [09:59] <othermaciej> I believe it was before the current decision policy
# [10:00] <jgraham> Yes, I think it was in the "someone says this is a problem" phase
# [10:00] <jgraham> Where everything got put in Tracker
# [10:00] <othermaciej> if you come up with a better caret API, I bet you could convince the accessibility folks to withdraw that proposal by consensus
# [10:01] <Hixie> well i'd be happy to do so, but i can't do it on the timetable that this issue is on
# [10:01] <Hixie> i have like 200 bugs and 1000 e-mails ahead of it in the queue
# [10:01] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
# [10:02] <othermaciej> maybe if you sketch it out you could convince them to wait to see it (not as sure on that though)
# [10:02] <othermaciej> agree that bugs/emails should be higher priority
# [10:03] <othermaciej> my personal technical opinion (off-the-cuff, have not thought about it super deeply) is that both nonav and usemap proposals are redundant with things you can already do in the existing spec, but there is some chance they could be a little bit more convenient for some use cases
# [10:03] <othermaciej> not sure which side of the leger that ends up on
# [10:04] <Hixie> i'd love to see any examples of them being used realistically that showed such cases
# [10:07] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Remote host closed the connection)
# [10:08] <othermaciej> I will agree the respective proposed spec text for both is not the best quality drafting
# [10:09] <Hixie> you are a master of the understatement
# [10:23] <annevk> hmm
# [10:23] <annevk> bit.ly even ate my fragment identifier
# [10:23] <annevk> wtf twitter
# [10:24] <annevk> hmm, only when using the expanding feature
# [10:24] * Joins: mpt (~mpt@canonical/mpt)
# [10:30] <hsivonen> Is there still no feedback from the Bespin team?
# [10:31] * Joins: Matjas (510bb5ba@gateway/web/freenode/ip.81.11.181.186)
# [10:34] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Quit: Rik`)
# [10:35] <gsnedders> http://talk.maemo.org/showthread.php?p=752460
# [10:35] <gsnedders> Opera Mobile for Maemo now with JIT on ARM
# [10:39] * Joins: foolip (~foolip@83.218.67.122)
# [10:40] <annevk> Hixie, for P2P, making the API protocol agnostic seems sort of like the wrong optimization as the API is very trivial compared to the protocol, but I guess you mostly mean you don't want to do the protocol :)
# [10:42] * Joins: MikeSmithX (~MikeSmith@EM111-188-45-160.pool.e-mobile.ne.jp)
# [10:44] * Joins: mat_t (~mattomasz@91.189.88.12)
# [10:45] * Quits: MikeSmith (~MikeSmith@EM114-48-27-68.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
# [10:46] * Joins: davidhund (~davidhund@78-27-27-74.dsl.alice.nl)
# [10:47] * Joins: ROBOd (~robod@92.86.244.224)
# [10:51] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
# [10:54] * MikeSmithX is now known as MikeSmith
# [10:56] <MikeSmith> is bespin still even being actively maintained?
# [10:57] * Joins: Phae (~Phae@chimera.macmillan.com)
# [11:00] * Matjas is now known as Math_ias
# [11:00] * Joins: Rik` (~Rik`@213.41.141.234)
# [11:03] * Quits: GarethAdams|Home (~GarethAda@pdpc/supporter/active/GarethAdams) (Quit: GarethAdams|Home)
# [11:03] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Remote host closed the connection)
# [11:04] <jgraham> MikeSmith: Yes
# [11:04] <jgraham> They seem to rewrite parts of it every so often
# [11:05] <jgraham> I think they just rewrote the server in node.js
# [11:05] <MikeSmith> jgraham: cool
# [11:05] <MikeSmith> dinnet know that
# [11:05] <jgraham> hsivonen: It was claimed that they had been contacted directly and didn't respond
# [11:07] <jgraham> MikeSmith: http://groups.google.com/group/bespin/browse_thread/thread/6de8c718d64232a0
# [11:10] * Quits: MikeSmith (~MikeSmith@EM111-188-45-160.pool.e-mobile.ne.jp) (Ping timeout: 260 seconds)
# [11:15] * Quits: foolip (~foolip@83.218.67.122) (*.net *.split)
# [11:15] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (*.net *.split)
# [11:15] * Quits: Amorphous (jan@unaffiliated/amorphous) (*.net *.split)
# [11:15] * Quits: crash\ (crash@lubyte.de) (*.net *.split)
# [11:15] * Quits: gsnedders (~gsnedders@204.232.194.186) (*.net *.split)
# [11:15] * Quits: kcliu (gjliou@linux1.cs.nctu.edu.tw) (*.net *.split)
# [11:15] * Quits: Phae (~Phae@chimera.macmillan.com) (*.net *.split)
# [11:15] * Quits: micheil (~micheil@124-170-233-189.dyn.iinet.net.au) (*.net *.split)
# [11:15] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (*.net *.split)
# [11:15] * Quits: danbri (~danbri@unaffiliated/danbri) (*.net *.split)
# [11:15] * Quits: othree (~othree@admin39.ct.ntust.edu.tw) (*.net *.split)
# [11:18] * Joins: gsnedders (~gsnedders@204.232.194.186)
# [11:18] * Joins: foolip (~foolip@83.218.67.122)
# [11:20] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [11:21] * Joins: Phae (~Phae@chimera.macmillan.com)
# [11:21] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [11:21] * Joins: Amorphous (jan@unaffiliated/amorphous)
# [11:21] * Joins: micheil (~micheil@124-170-233-189.dyn.iinet.net.au)
# [11:21] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
# [11:21] * Joins: danbri (~danbri@unaffiliated/danbri)
# [11:21] * Joins: crash\ (crash@lubyte.de)
# [11:21] * Joins: othree (~othree@admin39.ct.ntust.edu.tw)
# [11:21] * Joins: kcliu (gjliou@linux1.cs.nctu.edu.tw)
# [11:23] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 262 seconds)
# [11:25] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [11:28] * Joins: MikeSmith (~MikeSmith@EM114-48-176-39.pool.e-mobile.ne.jp)
# [11:29] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: This computer has gone to sleep)
# [11:31] * Math_ias is now known as mathias_01
# [11:33] * mathias_01 is now known as Matjas
# [11:36] * Joins: roc (~roc@121.98.230.221)
# [11:36] * Quits: zcorpan_ (~zcorpan@c-d798e355.410-6-64736c14.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [11:37] * Joins: zcorpan_ (~zcorpan@c-d798e355.410-6-64736c14.cust.bredbandsbolaget.se)
# [11:42] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
# [11:45] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Client Quit)
# [11:45] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
# [11:48] <annevk> "A frustrating point for working group members is that this proposal has been out for month and it was not until after an entire vote for consensus was reached that we get a comment from Opera." heh, and how long have we been awaiting feedback for proposals included in the HTML5 draft? ...
# [11:49] <jgraham> I kind of figure that if you lockl yourself away in a taskforce it is not that surprising when you get fewer comments
# [11:55] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
# [11:58] <AryehGregor> Yeah, it seems like if you want broader comments earlier, you should use the main discussion fora and not create your own . . .
# [12:00] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
# [12:03] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
# [12:04] * Joins: workmad3 (~workmad3@cspool86.cs.man.ac.uk)
# [12:05] * Joins: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk)
# [12:07] * Joins: pesla (~pesla@188.202.125.121)
# [12:13] * abarth is now known as abarth|zZz
# [12:15] * Joins: pauld (~chatzilla@194.102.13.2)
# [12:24] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [12:29] <AryehGregor> gfxFloat sigma = CurrentState().shadowBlur > 8 ? sqrt(CurrentState().shadowBlur) : CurrentState().shadowBlur / 2;
# [12:29] <AryehGregor> http://hg.mozilla.org/mozilla-central/file/5fda39cd703c/content/canvas/src/nsCanvasRenderingContext2D.cpp#l1855
# [12:29] <AryehGregor> Maybe that's why Firefox renders canvas shadows wrong?
# [12:29] <AryehGregor> You know, sqrt(CurrentState().shadowBlur) instead of sqrt(2*CurrentState().shadowBlur)?
# [12:30] <AryehGregor> Or am I reading the spec wrong?
# [12:32] * AryehGregor doesn't think so, since the Mozilla behavior makes shadowBlur = 8 the same as shadowBlur = 16
# [12:33] * AryehGregor tests that
# [12:33] <Philip`> It should be 2*
# [12:33] <AryehGregor> Conveniently, I've already basically written a reftest for this using SVG. :)
# [12:33] <AryehGregor> Yep, indeed, 8 and 16 look identical.
# [12:34] <AryehGregor> What a silly bug. This is exactly the sort of thing we need an official test suite for.
# [12:34] <Philip`> Then 9 is less blurry than 8
# [12:34] <AryehGregor> Yep!
# [12:34] <AryehGregor> Noticeably so.
# [12:34] <Philip`> which is a bigger discontinuity than the second-order one the bug was complaining about :-)
# [12:34] * AryehGregor works on a patch
# [12:34] <roc> if you could stick that in a patch, I'll review it for you :-)
# [12:35] <Philip`> We already have tests, and http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/index.2d.shadow.blur.html makes it obvious when it's not right
# [12:35] * AryehGregor has to remind himself how to actually compile Mozilla and such, should post a bug today and will CC roc
# [12:35] <Philip`> We just need people to run the tests and check for differences and file bugs and fix them
# [12:35] <AryehGregor> Guess so. :)
# [12:35] <Philip`> (and to fix bugs in the tests, and to write more tests, etc)
# [12:38] <AryehGregor> I suspect Chrome is wrong because they deliberately use some kind of non-Gaussian blur, on the other hand. Not sure on that, though. Chrome is way further off the mark than Firefox.
# [12:38] <AryehGregor> (which is saying a lot, when Firefox makes all blurs above 8 41% bigger)
# [12:38] <MikeSmith> jgraham: thanks for link about Bespin roadmap
# [12:39] <Philip`> (You probably mean smaller)
# [12:39] <AryehGregor> Er, yes, probably.
# [12:39] * AryehGregor stares at code compiling.
# [12:40] * AryehGregor will have to get some real CPUs if he gets more into compiling stuff, or get distcc working . . . now if only I had managed to persuade other household members to upgrade their computers to Linux, that'd be like six extra CPUs.
# [12:41] <Philip`> https://bugzilla.mozilla.org/show_bug.cgi?id=310682 - hmm, looks like I got the calculation right in my early patch but didn't notice it was broken in the rewritten one
# [12:43] * Quits: MikeSmith (~MikeSmith@EM114-48-176-39.pool.e-mobile.ne.jp) (Quit: This computer has gone to sleep)
# [12:59] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
# [13:01] * Quits: wakaba_ (~wakaba_@203-140-90-184.eonet.ne.jp) (Ping timeout: 265 seconds)
# [13:01] * AryehGregor wonders if anyone does reviews on what CPUs are best for compiling.
# [13:02] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
# [13:03] <AryehGregor> Philip`, do you know if there's any reason anyone would want blurRadius/2 instead of sqrt(2*blurRadius) at 8 and below?
# [13:05] * Joins: cedricv (~cedric@202.152.243.105)
# [13:10] <Philip`> AryehGregor: No, unless it happens to give you a nicer range of blurs for small integers or something like that
# [13:10] <AryehGregor> Would it make any sense as an optimization?
# [13:10] <AryehGregor> I think I recall someone from Safari saying they considered it as a bug . . .
# [13:10] <Philip`> That equation just seemed to be the best match for what Safari looked like (I don't know if it what's they do internally)
# [13:11] <othermaciej> we just do what CG does
# [13:11] <Philip`> (By "they" I meant the CG people :-) )
# [13:12] <othermaciej> supposedly the threshold below 8 pixels gives a smoother progression for different radius sizes
# [13:12] <othermaciej> at least that is what I have heard
# [13:12] <AryehGregor> So CG's blur function accepts this weird blurRadius instead of just accepting sigma directly?
# [13:12] <AryehGregor> Do you think it would make sense to change it at this point, since we don't have interop on canvas shadows anyway?
# [13:13] <othermaciej> well, we could always munge the blur radius to do what CG would do (assuming it takes a float; not sure)
# [13:13] <othermaciej> I do not know what actually results in good looking shadows
# [13:13] <Philip`> http://developer.apple.com/mac/library/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextSetShadow
# [13:14] <Philip`> "A non-negative number specifying the amount of blur."
# [13:14] <AryehGregor> Do you think it's worth pursuing, or should we just leave it alone?
# [13:14] <AryehGregor> CGFloat blur
# [13:14] <Philip`> I don't think I've ever seen anything saying the scale of the number
# [13:16] <AryehGregor> I guess it's easiest at this point to just leave it alone.
# [13:16] <AryehGregor> It won't be anywhere near the biggest wart in the web platform.
# [13:16] <Philip`> It seems like converging on what the spec says will take less effort than converging on anything else (given that some people already implement the spec), and I don't think it's a particularly user-hostile definition (it's just a bit weird and unjustified but people can easily guess sensible numbers)
# [13:17] <AryehGregor> Yeah, makes sense.
# [13:17] * Quits: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl) (Quit: Necrathex)
# [13:18] <jgraham> If anyone asks we will blame Apple
# [13:18] <Philip`> (Users aren't any more likely to understand sigmas anyway)
# [13:19] <jgraham> Then they will either direct their righteous anger there or assume the design was perfect and it was them who was wrong
# [13:19] <jgraham> Depending on their relationship with Apple
# [13:19] <jgraham> and the current state of the RDF
# [13:21] <AryehGregor> Hmm, my change didn't seem to fix Firefox.
# [13:21] <AryehGregor> Have to go now, I guess I'll look later today.
# [13:21] <roc> did you rebuild everything?
# [13:21] <AryehGregor> I was using a fresh mozilla-central checkout.
# [13:22] * Joins: MikeSmith (~MikeSmith@EM114-48-176-39.pool.e-mobile.ne.jp)
# [13:22] <Philip`> Obvious question: Are you running the version you compiled, not a window of another version of Firefox that was already running?
# [13:22] <AryehGregor> Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre
# [13:22] <jgraham> annevk: Can you change the favicon for the webapps tracker, please
# [13:23] <jgraham> It is highly confusing that it has the same icon as the tabs with the spec open
# [13:25] <AryehGregor> It does seem to look a bit closer, maybe.
# [13:25] <AryehGregor> Okay, got to go now . . .
# [13:25] <jgraham> annevk: (the same icon with the colours inverted or something simple would be fine)
# [13:27] <MikeSmith> about meta/@name=viewport
# [13:27] <MikeSmith> which already seems to have become a de facto standard
# [13:27] * Quits: yoshiaki (~yoshiaki@133.27.228.172) (Ping timeout: 240 seconds)
# [13:27] <MikeSmith> are there any other meta/@name values that have rendering effects in browsers?
# [13:28] <MikeSmith> and who is it at Apple who came up that thing to begin with?
# [13:28] <MikeSmith> and whoever it was, why didn't they find it worthwhile to ask for feedback on it before unleashing it on the world?
# [13:28] <hsivonen> MikeSmith: to the person's credit at Apple, they at least used meta/@name and not meta/@http-equiv
# [13:29] <hsivonen> MikeSmith: it was created in the stealth mode before the iPhone was announced
# [13:29] <MikeSmith> I see
# [13:30] <MikeSmith> hsivonen: yeah, glad it's not http-equiv at least
# [13:36] <Matjas> When using Flash as a fallback for HTML5 <video>, is it a good idea to use an additional <source> for the .flv (Flash Video) file, or not?
# [13:45] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
# [13:55] <Peter`> Matjas: a quick test shows that no browser is capable of playing .flv files through <video>, next to that, it's called Flash Video for a reason. I wouldn't include it
# [13:56] * Quits: hamaji (~hamaji@220.109.219.244) (Ping timeout: 276 seconds)
# [13:56] <Matjas> Peter`: Okay, thanks.
# [13:57] <annevk> jgraham, if you make one
# [13:57] <annevk> jgraham, can you make a pink one?
# [13:58] <jgraham> annevk: Probably. Where is the original?
# [13:58] * Joins: BlurstOfTimes (~blurstoft@168.203.103.113)
# [13:59] <annevk> http://simon.html5.org/sandbox/svg/whatwg
# [14:00] <annevk> maybe I can do this myself... but I rather just wget and remove the favicon line
# [14:02] * Quits: davidhund (~davidhund@78-27-27-74.dsl.alice.nl) (Ping timeout: 258 seconds)
# [14:07] * Quits: cedricv (~cedric@202.152.243.105)
# [14:09] * Joins: davidhund (~davidhund@78-27-27-74.dsl.alice.nl)
# [14:17] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Read error: Connection reset by peer)
# [14:19] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
# [14:20] <annevk> so I tried fiddling with that icon and everything fall apart
# [14:25] <jgraham> Oh
# [14:26] <jgraham> I made you a new one http://hoppipolla.co.uk/410/favicon.ico
# [14:26] <jgraham> If you can work out how to use it without everything dying
# [14:26] * Quits: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl) (Quit: Disconnected...)
# [14:27] <annevk> that's more like purple, no?
# [14:27] <jgraham> Picky
# [14:28] <jgraham> I used one of those web colour scheme generator things to find some pinkish colour that would vaugely work with the dark green
# [14:28] <jgraham> Since they will typically be next to each other
# [14:30] * Joins: FireFly (~firefly@unaffiliated/firefly)
# [14:33] <annevk> hotpink it is
# [14:36] * Quits: davidhund (~davidhund@78-27-27-74.dsl.alice.nl) (Ping timeout: 276 seconds)
# [14:36] <jgraham> That is hideous
# [14:36] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [14:36] <annevk> you asked for it
# [14:37] <annevk> complaining about a favicon, come on ;p
# [14:37] <jgraham> Also, it only seems to be working in Opera
# [14:37] <annevk> that sounds like a cache issue
# [14:37] <jgraham> Maybe. It is just showing the default in the others though
# [14:38] <annevk> wfm in Chrome
# [14:38] <annevk> doesn't work in Firefox
# [14:38] <annevk> but Firefox does work on my site
# [14:38] <annevk> hmm
# [14:38] <annevk> maybe still a cache issue
# [14:38] <zcorpan_> wfm in firefox
# [14:39] <annevk> weird, doesn't in mine
# [14:39] <annevk> even after explicitly loading /favicon.ico
# [14:39] <annevk> but someone else can fix that
# [14:40] <jgraham> Works in Chromium after clearing the cache
# [14:40] <jgraham> But I kinda wish it didn't :(
# [14:40] <annevk> I used http://www.whatwg.org/images/logo.svg eventually
# [14:40] <annevk> jgraham, hehe
# [14:40] <jgraham> Also, what happened to the chromium menu. It's insane
# [14:41] <annevk> the one from Simon is far more clever but SVG rendering tools are just too crappy to support that
# [14:41] <annevk> they need explicit paths and such
# [14:41] <jgraham> annevk: I used Simon's one and then edited around some of the problems inkscape had
# [14:42] <jgraham> Seriously, apart from having buttons in the menu, it has submenus with disclosure arrows that will always be hard against the right of the screen
# [14:42] <jgraham> So that the submenu will always open on the left
# [14:42] <jgraham> It must be a bug
# [14:43] <jgraham> Or unfinished change at least
# [14:43] <annevk> at least they do not have 4 menu depth
# [14:43] <annevk> like selecting an encoding in Opera requires
# [14:43] <annevk> selecting an encoding is something that should not be in the UI anyway
# [14:43] <annevk> no user gets such bullshit
# [14:43] <jgraham> Yeah, but at least our menus don't have arrows to the right and open to the left
# [14:44] <annevk> agreed that is weird
# [14:44] <annevk> maybe they optimized for RTL?
# [14:44] <annevk> :)
# [14:44] <Philip`> Opera's menus often open off my screen so I can't see them at all :-(
# [14:45] <Philip`> though maybe that's my fault for having a non-rectangular multi-monitor desktop
# [14:45] <jgraham> Philip`: File a bug?
# [14:46] * Philip` is too lazy and doesn't know if it's even fixable on Linux
# [14:48] <annevk> i like this new icon
# [14:48] <annevk> should make one for http://webforms2.org/ too
# [15:09] * Joins: davidb_ (~davidb@mozca02.ca.mozilla.com)
# [15:20] * Joins: davidhund (~davidhund@78-27-27-74.dsl.alice.nl)
# [15:22] <AryehGregor> That is quite hideous.
# [15:26] * Joins: miketaylr (~miketaylr@38.117.156.163)
# [15:28] * Quits: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp) (Quit: boblet)
# [15:29] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
# [15:29] * Joins: miketaylr (~miketaylr@38.117.156.163)
# [15:31] <AryehGregor> Philip`, do you understand what the call to gfxAlphaBoxBlur::CalculateBlurRadius() does? Maybe that's where the problem is . . . ? Even after the extra factor of sqrt(2), Firefox is still showing significantly too little blurring.
# [15:32] <AryehGregor> The problem with me trying to write a patch here is I have no idea what any of this stuff does.
# [15:33] <AryehGregor> Is this doing a real Gaussian blur at all?
# [15:34] <AryehGregor> It looks like it's not.
# [15:34] <AryehGregor> Hmm, there's an approximation specified in the SVG spec itself.
# [15:35] <AryehGregor> http://en.wikipedia.org/wiki/Box_blur
# [15:40] <Philip`> AryehGregor: I have no idea what gfxAlphaBoxBlur does
# [15:40] <Philip`> It sounds like it ought to be a sufficiently close approximation of a Gaussian blur that you shouldn't see much difference
# [15:41] <Philip`> (as long as you don't exceed SIGMA_MAX)
# [15:42] <Philip`> (which is at shadowBlur=312.5)
# [15:43] * Quits: aho (~nya@fuld-4d00d22e.pool.mediaWays.net) (Ping timeout: 245 seconds)
# [15:43] * Joins: aho (~nya@fuld-4d00d2ef.pool.mediaWays.net)
# [15:46] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
# [15:52] <AryehGregor> It looks like it does three box blurs, which is supposed to be within 3% of a true Gaussian blur.
# [15:52] <AryehGregor> But canvas is the only caller of that.
# [15:52] <AryehGregor> So maybe it's just buggy.
# [15:53] <Philip`> That seems quite possible
# [15:53] <Philip`> given that the output is not what you expect
# [15:57] * AryehGregor is looking at the code for feGaussianBlur now, since that works right
# [15:57] <AryehGregor> Yay, approximating integer division by multiplication and bitshifts.
# [15:57] <AryehGregor> * If all that math confuses you, this should convince you:
# [15:57] <AryehGregor> * > perl -e 'for($N=1;(255*$N*int(0xFFFFFFFF/(255*$N)))>>24==255;++$N){}print"$N\n"'
# [15:57] <AryehGregor> * 66052
# [16:00] <jgraham> That looks a lot like line noise
# [16:00] <AryehGregor> Yes, sometimes it's hard to tell the difference between Perl and line noise.
# [16:01] <jgraham> Also, why does it do anything? Where is $N mutated?
# [16:01] <AryehGregor> ++$N
# [16:01] <jgraham> Oh wait
# [16:01] <jgraham> I was being dumb
# [16:01] <Philip`> Remove the '$'s and it's basically C
# [16:01] <Philip`> It's not doing anything Perlish
# [16:02] <AryehGregor> Cramming an entire program on one line with no spaces except where required by syntax strikes me as very Perlish.
# [16:02] * Quits: nicktick (debian-tor@gateway/tor-sasl/nicktick) (Remote host closed the connection)
# [16:02] <Philip`> (What source file is this in?)
# [16:02] <jgraham> I think the maths would be easier to follow...
# [16:02] <AryehGregor> content/svg/content/src/nsSVGFilters.cpp
# [16:02] <jgraham> (what is the program trying to show?)
# [16:02] * Joins: ako (~nya@fuld-4d00d38e.pool.mediaWays.net)
# [16:03] <workmad3> AryehGregor: only thing that's doing that isn't C is that C would need a main() function to work
# [16:03] <workmad3> (oh, and would probably use printf rather than print)
# [16:03] * Quits: aho (~nya@fuld-4d00d2ef.pool.mediaWays.net) (Ping timeout: 245 seconds)
# [16:03] <AryehGregor> workmad3, and printf("%d\n", N) instead of print "$N\n".
# [16:03] <AryehGregor> Yar.
# [16:03] <workmad3> it isn't a very perlish version of getting it all onto one line though :)
# [16:04] <AryehGregor> jgraham, the program is trying to show that 255*$N*int(0xFFFFFFFF/(255*N))>>24 == 255 for numbers up to a fairly large amount, of course.
# [16:04] <AryehGregor> Except with some more parentheses.
# [16:05] <AryehGregor> I don't know what the 255's are doing there, isn't ($N*int(0xFFFFFFFF/(255*$N)))>>25 == 1 equivalent?
# [16:06] <AryehGregor> Oh, hmm, no.
# [16:06] <AryehGregor> Because the 255* is before the bitshift.
# [16:06] <AryehGregor> Also, it's 24 and not 25.
# [16:06] * AryehGregor saw this trick before when deciphering the assembly output of a trivial C program he wrote for fun, but you'd think the compiler would do this for you.
# [16:09] <AryehGregor> Okay, but anyway, I am totally incapable of figuring out what's wrong here. I'm comparing BoxBlur() in nsSVGFilters.cpp and BoxBlurHorizontal()/BoxBlurVertical() in gfxBlur.cpp, and it's all gibberish to me.
# [16:10] <AryehGregor> (there seems to be considerable code duplication here, incidentally)
# [16:10] <Philip`> static const gfxFloat GAUSSIAN_SCALE_FACTOR = (3 * sqrt(2 * M_PI) / 4) * (3/2);
# [16:10] <Philip`> Surely that's not going to work
# [16:10] <Philip`> because (3/2) == 1
# [16:10] <AryehGregor> Hmmm.
# [16:11] <Philip`> The rest will get promoted to doubles but that won't
# [16:11] <AryehGregor> In nsSVGFilters.cpp, it says: double size = aStdDev*3*sqrt(2*M_PI)/4;
# [16:11] <AryehGregor> Then: return PRUint32(floor(size + 0.5));
# [16:12] <AryehGregor> Well, that part is irrelevant, I guess.
# [16:12] <AryehGregor> The SVG spec says: let d = floor(s * 3*sqrt(2*pi)/4 + 0.5)
# [16:12] <AryehGregor> So maybe (3/2) == 1 is actually intentional somehow. :P
# [16:13] <AryehGregor> I could try changing that and recompiling, may as well give it a shot.
# [16:13] <AryehGregor> Hmm, what does this mean: // Blur radius is approximately 3/2 times the box-blur size
# [16:13] <Philip`> InflateRectForBlurDXY does the 3/2 for SVG box blurs (vs Gaussian blurs), I think
# [16:13] <AryehGregor> Quite possible.
# [16:13] <AryehGregor> Well, let me see.
# [16:14] <AryehGregor> Isn't it nice how one can spot bugs without actually having any idea what the code does?
# [16:15] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
# [16:15] <Philip`> Changing the (3/2) to 1.5 or whatever should make the blurs somewhat bigger, which is hopefully a change in the right direction
# [16:16] * AryehGregor wonders how the convention of "compilers should spam your terminal with spectacular quantities of incomprehensible garbage" developed
# [16:16] * Joins: plainhao (~plainhao@mail.xbiotica.com)
# [16:16] <Philip`> That's probably the Makefile, not the compiler
# [16:16] <AryehGregor> Then replace "compilers" with "the compilation process" if you like.
# [16:16] <Philip`> except in the case of compiler errors in STL code, which is totally the compiler's fault for not caring about users
# [16:17] <AryehGregor> Okay, this is much better.
# [16:17] <Workshiva> Makefiles aren't a process as much as a somewhat deterministic trainwreck
# [16:17] <AryehGregor> Now the HTML is somewhat more blurry than the SVG.
# [16:17] <AryehGregor> Unlike Opera, where they're identical.
# [16:18] <AryehGregor> (open http://aryeh.name/tmp/test.svg and http://aryeh.name/tmp/test.html, tab between them, should see no noticeable change)
# [16:19] <Philip`> Is there some way to toggle the SVG between Gaussian and box blurs?
# [16:19] <Philip`> Oh, sorry, it always does box blurs
# [16:20] <AryehGregor> Yeah, apparently no one does actual Gaussian blurs, too expensive when box blurs look the same.
# [16:20] * Quits: peol (~andree@unaffiliated/peol) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.17/2009122204])
# [16:23] * Quits: pesla (~pesla@188.202.125.121) (Quit: kthxbye!)
# [16:23] * Philip` notes that http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/index.2d.shadow.blur.html uses a true Gaussian for comparison
# [16:23] <jgraham> What margin of error>
# [16:23] <jgraham> ?
# [16:24] <Philip`> and in Opera they look very similar
# [16:24] <AryehGregor> Various sources say doing three box blurs in the right way gets you within 3% of a true Gaussian blur.
# [16:24] <AryehGregor> Without all the exponentiation and things.
# [16:24] <Philip`> (except blur.low has some faintly visible banding in Opera's canvas)
# [16:24] <AryehGregor> Your tests look about the same actual vs. expected in my patched Firefox.
# [16:25] <AryehGregor> It's hard to say for sure, though. It's easier to see when they're superimposed and you can flip back and forth.
# [16:25] <Philip`> Right click -> open image in tab
# [16:25] <AryehGregor> And for the canvas?
# [16:26] <AryehGregor> Oh, that has "View Image" too.
# [16:26] <AryehGregor> At least in Firefox.
# [16:26] <Philip`> Yeah
# [16:26] <Philip`> It's quite handy :-)
# [16:26] <AryehGregor> Okay, they're definitely different in patched Firefox, but much less so.
# [16:26] * Joins: erlehmann (~erlehmann@dslb-188-103-023-238.pools.arcor-ip.net)
# [16:27] * Quits: zcorpan_ (~zcorpan@c-d798e355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan_)
# [16:27] <Philip`> Is the difference smaller than the difference between canvas and SVG?
# [16:27] <Philip`> Or, equivalently, do Firefox and Opera agree on the SVG blur?
# [16:27] <AryehGregor> Everything agrees on the SVG blur as far as I can tell in a side-by-side comparison.
# [16:27] <AryehGregor> I haven't tried superimposing them.
# [16:27] * AryehGregor tries that
# [16:28] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
# [16:29] * Philip` is getting confused as to what's identical and what's a little different and what's a lot different
# [16:30] <AryehGregor> I can't tell any difference between Firefox, Chrome, or Opera's renderings of my SVG when superimposed, nor any difference before Opera's canvas and SVG.
# [16:30] <Philip`> Okay
# [16:30] <AryehGregor> I notice a distinct difference between my SVG and HTML in Chrome and (patched) Firefox when superimposed.
# [16:30] <AryehGregor> And also in your test case.
# [16:32] <AryehGregor> Opera doesn't give me an image link for the canvas images. :(
# [16:33] <Philip`> javascript:location=c.toDataURL();
# [16:33] * AryehGregor sighs
# [16:34] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
# [16:34] <AryehGregor> Yeah, they look basically identical superimposed in Opera.
# [16:36] <AryehGregor> . . . c is the same as document.getElementById("c")? Really? How did I never know that?
# [16:36] <AryehGregor> I guess it's not encouraged to use it for serious stuff in case something else shadows the element, though.
# [16:36] * Quits: jorlow (~jorlow@nat/google/x-dhmeahvjritzuwhv) (Read error: Operation timed out)
# [16:36] <AryehGregor> Okay, I'll just post the patch, I guess.
# [16:40] * Joins: jorlow (~jorlow@74.125.57.60)
# [16:42] * Joins: annevk5 (~annevk@53530AD4.cable.casema.nl)
# [16:43] <Philip`> AryehGregor: I think the c shortcut doesn't work in e.g. standards mode in Firefox
# [16:43] <AryehGregor> Interesting.
# [16:43] <Philip`> so don't rely on it
# [16:46] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Ping timeout: 245 seconds)
# [16:53] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
# [16:55] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
# [17:00] * Joins: Maurice (copyman@5ED573FA.cable.ziggo.nl)
# [17:09] * Joins: bobchao (~cctw@140.109.16.241)
# [17:13] * Joins: m_W (~mwilcox56@c-68-38-230-216.hsd1.nj.comcast.net)
# [17:15] * Quits: annevk5 (~annevk@53530AD4.cable.casema.nl) (Quit: annevk5)
# [17:15] * Quits: maikmerten (~maikmerte@port-92-201-196-56.dynamic.qsc.de) (Remote host closed the connection)
# [17:16] * Quits: SecretAgent (sa@quake.nitemare.name) (*.net *.split)
# [17:16] * Joins: SecretAgent (sa@quake.nitemare.name)
# [17:18] * Joins: MikeSmithX (~MikeSmith@EM114-48-195-198.pool.e-mobile.ne.jp)
# [17:19] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
# [17:19] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: mhausenblas)
# [17:20] * Quits: MikeSmith (~MikeSmith@EM114-48-176-39.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
# [17:22] * Quits: seventh (galofort@208.98.1.237) (Remote host closed the connection)
# [17:22] * Quits: romeo (~romeo__@x1-6-00-07-95-57-08-bb.k459.webspeed.dk) (Quit: Leaving)
# [17:25] <AryehGregor> https://bugzilla.mozilla.org/show_bug.cgi?id=578995
# [17:28] <AryehGregor> Philip`, roc: ^^
# [17:30] <TabAtkins> AryehGregor: So, actually inverting the gaussian (so I can get a function that takes the blur length and spits out the stdev) requires the Lambert W. You're mathier than I. I assume that's dumb to calculate?
# [17:31] <AryehGregor> TabAtkins, Lambert W is not expressible in terms of elementary functions. It's probably fairly expensive to calculate, but it should only need to be calculated once per declaration, so shouldn't be a big deal.
# [17:32] <TabAtkins> Unless you're animating the shadow, of course.
# [17:32] <AryehGregor> Heh, yeah.
# [17:32] <AryehGregor> Then you're going to have to cheat.
# [17:32] <TabAtkins> You can iterate it with some Newton's method, but still.
# [17:32] <TabAtkins> I suspect that'd probably converge quickly.
# [17:32] <TabAtkins> Since we can make a good guess already.
# [17:33] <Philip`> Why would you want to force people to do something so complex?
# [17:33] <AryehGregor> Yes, apparently you need to use Newton's method here. No x86 instruction for it or anything.
# [17:33] <AryehGregor> Philip`, so they have some idea of what it does instead of passing in arbitrary numbers.
# [17:33] <TabAtkins> I don't. I'm just providing an example of how to calculate the stdev, if you wanted to use an actual gaussian. If you wanted to use something else, that's probably easier to calculate.
# [17:34] <AryehGregor> Or maybe harder.
# [17:35] <Philip`> It seems like in practice "something else" is an approximation of a Gaussian, so you still calculate the same sigma
# [17:35] <TabAtkins> Maybe. Anyway, getting an approximation within the range I want to specify is good enough.
# [17:36] * AryehGregor wonders if there's any point in adding [parity-opera][parity-ie][parity-safari] to the whiteboard of his bug, or if it's just noise
# [17:36] * Joins: ayo (~nya@fuld-4d00d7fb.pool.mediaWays.net)
# [17:37] <TabAtkins> Probably just noise. It's a clear and simple spec violation in the first place.
# [17:38] <Philip`> AryehGregor: You should probably add an r+ flag if you want the patch reviewed
# [17:38] <AryehGregor> I assume you mean r?.
# [17:38] <Philip`> Oh
# [17:38] <Philip`> Yeah
# [17:38] <AryehGregor> I think me adding r+ to my own patch would be considered objectionable.
# [17:39] <AryehGregor> Also, it's obviously r-, because 1) it doesn't fully fix the problem, and 2) it has no tests.
# [17:39] <AryehGregor> So it's not ready for review yet.
# [17:39] * Quits: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu)
# [17:39] <Philip`> Oh, okay then
# [17:39] <Philip`> Surely it has at least as many tests as the original shadow implementation, though
# [17:39] * Quits: ako (~nya@fuld-4d00d38e.pool.mediaWays.net) (Ping timeout: 240 seconds)
# [17:39] <Philip`> and presumably they were good enough then
# [17:41] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
# [17:41] <AryehGregor> I see no tests for the original shadow implementation. That was in September 2008, maybe they weren't as picky about tests then?
# [17:42] <Workshiva> That's when nobody implemented shadows at all, isn't it?
# [17:42] <AryehGregor> When I submitted a patch a few months ago, I was told every new commit had to have patches, except for security fixes and things that were just impossible to test.
# [17:42] <AryehGregor> I mean, had to have tests.
# [17:42] <Philip`> It untodoed the tests in https://bug310682.bugzilla.mozilla.org/attachment.cgi?id=335212
# [17:43] <AryehGregor> I'm pretty sure commits were always required to have patches. You aren't supposed to make empty commits to send messages to readers of the commit mailing list or anything.
# [17:43] <AryehGregor> Oh, I missed that.
# [17:43] <AryehGregor> Yeah, it had test updates in a separate commit.
# [17:43] <Philip`> Sometimes you are, e.g. if you forget to mention the bug number in an earlier commit :-)
# [17:44] * Quits: ukai (~ukai@220.109.219.244) (Ping timeout: 265 seconds)
# [17:45] <AryehGregor> Hmm, that's lots of isPixel tests. I wonder how the original tests were devised? What reference was used?
# [17:45] <AryehGregor> Because if they pass, they're probably wrong. :)
# [17:45] <AryehGregor> (but maybe just incomplete)
# [17:45] <Philip`> The original tests are the ones I wrote
# [17:45] <AryehGregor> So why didn't they fail?
# [17:45] <Philip`> I think I didn't have any testing the shape/size of the blur precisely, though
# [17:46] <Philip`> since everyone will approximate it and round differently etc so it's hard to know what tolerances to allow
# [17:46] <Philip`> so I just stuck with manual visual verification tests for that
# [17:47] <AryehGregor> How do I run those tests to see if they still pass with my patch applied?
# [17:47] <Philip`> http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/index.2d.shadow.html
# [17:48] <Philip`> I think that's basically all of them, except for boring attribute getting/setting/etc
# [17:48] <Philip`> (Don't remember if I've made many changes since the version imported into Mozilla)
# [17:48] <AryehGregor> Oh, interesting.
# [17:49] <jgraham> Hixie: given html like <svg></svg> I think the current spec has a crash. The </svg> fails to switch the parser out of foreign content mode. The EOF then keeps popping until an <svg> or <math> token is reached, which never happens because there isn't one
# [17:49] <jgraham> (if someone else fancies checking that before I file a bug it would be appreciated)
# [17:49] <AryehGregor> Well, my change causes no extra failures on that page.
# [17:50] <AryehGregor> A reftest between SVG and canvas would be cool, if that could be arranged.
# [17:50] <AryehGregor> It would make sense for them to share code anyway, I would think, no?
# [17:50] <AryehGregor> (but if not, probably they won't be pixel-perfect, oh well)
# [17:50] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 245 seconds)
# [17:52] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
# [17:52] * Joins: jwalden (~waldo@adsl-71-147-38-111.dsl.emhril.sbcglobal.net)
# [17:53] * Joins: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net)
# [17:53] * Quits: workmad3 (~workmad3@cspool86.cs.man.ac.uk) (Remote host closed the connection)
# [17:54] * Quits: ayo (~nya@fuld-4d00d7fb.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
# [17:57] <AryehGregor> Philip`, you need to make one big page with all your tests, that outputs the number passed and failed without requiring you to count. Then everyone will start using your tests as a barometer of how good their HTML5 compliance is.
# [17:57] <Philip`> AryehGregor: I've already got http://philip.html5.org/tests/canvas/suite/tests/results.html
# [17:58] <AryehGregor> Is that updated automatically?
# [17:58] <Philip`> No
# [17:58] <Philip`> Well, partly
# [17:58] * AryehGregor realizes that IE9 is actually up to PP3, not PP2, oops
# [17:59] <Philip`> http://philip.html5.org/tests/canvas/suite/reportgenentry.html lets you run the tests
# [17:59] <Philip`> and if you're me and you're running it on localhost then you can save the results to a database
# [17:59] <Philip`> and then regenerate the results table
# [17:59] <AryehGregor> Nice.
# [18:00] <Philip`> It'd be nice if the W3C Testing TF got a system running for more easily running tests and submitting results
# [18:00] * AryehGregor looks pointedly at TabAtkins.
# [18:00] <TabAtkins> Yes, yes, I'm working on it.
# [18:00] <Philip`> so I haven't bothered trying to upload my own test harness there
# [18:01] <Philip`> TabAtkins: Work faster :-p
# [18:01] <TabAtkins> I try, but then I get distracted by shiny objects and CSS emails.
# [18:01] <Philip`> The fate of the web depends on you
# [18:01] <TabAtkins> o_O
# [18:01] * TabAtkins notes that we are, indeed, fucked.
# [18:02] <kling> Philip`: fwiw webkit will be a loot greener in the next update of that page :)
# [18:02] <kling> lot*
# [18:02] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
# [18:02] <Philip`> kling: Yeah, I've been seeing lots of nice-looking commit messages :-)
# [18:03] <AryehGregor> Interesting, Opera maxes out both cores while loading the full page.
# [18:03] <AryehGregor> At least part of the time.
# [18:03] <AryehGregor> (unless it's something else that's randomly running at the same time)
# [18:03] <Philip`> Maybe it's just running an idle loop in a background thread, to trick you into thinking it's making full use of your hardware
# [18:04] <AryehGregor> Those sneaky Europeans.
# [18:05] <jwalden> Philip`: jresig was at one time working on something like that (test swarm?)
# [18:05] * Joins: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp)
# [18:05] * Joins: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
# [18:06] <AryehGregor> We don't need anything fancy. For starters, just have a JavaScript framework that can be run as a regular old web page.
# [18:07] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
# [18:07] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
# [18:11] * AryehGregor finds Chrome dev channel at 82.1%, Firefox nightly at 77.0%, Opera 10.60 at 79.8%
# [18:11] * AryehGregor maliciously gave three significant figures so Opera would be below 80%
# [18:14] * Joins: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl)
# [18:14] <gsnedders> For the canvas tests?
# [18:16] * Quits: davidhund (~davidhund@78-27-27-74.dsl.alice.nl) (Quit: davidhund)
# [18:21] * Quits: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp) (Quit: boblet)
# [18:22] * Quits: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk) (Quit: akamike)
# [18:22] <AryehGregor> This is for all of Philip`'s tests.
# [18:26] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [18:29] * Joins: pauld (~chatzilla@194.102.13.2)
# [18:29] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
# [18:30] * Quits: Phae (~Phae@chimera.macmillan.com) (Quit: Leaving.)
# [18:32] * AryehGregor observes that gmail.com is the domain name of 50% of the addresses notified when he changes his bug, and the runner-up is . . . a 16-way tie between 16 different domains, most of them personal domains. Interesting.
# [18:33] <Philip`> Gmail seems like the only webmail service you wouldn't be embarrassed to use
# [18:33] <Philip`> e.g. nobody would take you seriously if you were @hotmail.com
# [18:34] <AryehGregor> One of the addresses was @aol.com!
# [18:34] <AryehGregor> I also know someone @earthlink.net.
# [18:34] <AryehGregor> (That person uses dial-up too.)
# [18:34] <jgraham> Is hixie.ch slow for everyone?
# [18:34] <TabAtkins> No.
# [18:35] <AryehGregor> Someone needs to make slowforeveryoneorjustme.com.
# [18:35] <jgraham> Specifically the live dom viewer
# [18:35] <Workshiva> ... I was going to say that, AryehGregor !
# [18:35] <jgraham> Actauuly that is timing out in firefox
# [18:35] * Quits: estellevw (~estelle@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
# [18:35] <jgraham> Which is causing a YSOD
# [18:35] <jgraham> Because of a missing entity in the error document
# [18:36] * abarth|zZz is now known as abarth
# [18:36] <TabAtkins> Nm, yes it is running a bit slow.
# [18:36] <AryehGregor> Okay, time to stop dilly-dallying and go study some math for the next half of my six-ish-hour day. Back in a few hours.
# [18:37] * Joins: nicktick (debian-tor@gateway/tor-sasl/nicktick)
# [18:46] * Quits: jcranmer (~jcranmer@asimov.csl.tjhsst.edu) (Ping timeout: 245 seconds)
# [18:48] * Joins: jcranmer (~jcranmer@asimov.csl.tjhsst.edu)
# [18:52] * Joins: maikmerten (~maikmerte@port-92-201-196-56.dynamic.qsc.de)
# [18:54] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
# [18:57] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
# [18:58] <TabAtkins> Writing on the @srcdoc proposal was making me wonder why a <sandbox @flags @length></sandbox> tag wouldn't work, then it hit me - encoding differences. Many/most authors have no idea that there's a difference between bytes and characters, and the sort of minefield that most languages make them step through to deal with unicode properly.
# [19:01] <othermaciej> also the fallback behavior would be insecure
# [19:01] <TabAtkins> Ah, right, yeah.
# [19:01] <othermaciej> rather than failing
# [19:01] <othermaciej> which may or may not be better, depending on your use case
# [19:02] <othermaciej> if you are also doing server-side filtering and want sandbox for defense in depth, it would be better
# [19:02] * Joins: davidhund (~davidhund@dnuhd.xs4all.nl)
# [19:03] <othermaciej> it would also be oddly non-orthogonal for the parser to sometimes ignore a close tag in this case
# [19:04] <othermaciej> <sandbox @secure-token> </sandbox @secure-token> could work but carries risk if the token is predictable
# [19:04] <TabAtkins> It would be a matter of "consume @length characters from the stream - if the next 10 characters are not </sandbox>, ??? (abort, retry, continue)"
# [19:04] <TabAtkins> Yeah, the rest of the suggestions I remembered the problems with.
# [19:05] <othermaciej> I guess both that and encoding issues are harder to deal with correctly than the minimal escaping required for @srcdoc
# [19:05] <TabAtkins> Yes.
# [19:05] <TabAtkins> @srcdoc is just data: with slightly easier escaping and a slightly better fail model.
# [19:06] <othermaciej> yeah, I guess a hypothetical inline sandboxing mechanism would have to not parse its contents normally at all, if it was going to put it in an imaginary frame
# [19:06] * Joins: aroben (~aroben@unaffiliated/aroben)
# [19:07] <othermaciej> people also suggested these mechanisms as things would actually put the sandboxed content in the same document tree, but that makes it hard to implement anything other than just disabling of scripts in the sandboxed content
# [19:07] <TabAtkins> Presumably it would be "consume @length characters, then continue consuming characters until </sandbox> is encountered, and stuff everything so consumed into a sandboxed context".
# [19:07] <Philip`> It looks like the failure mode for @length would be subtle and insecure - you insert some Unicode characters so the server thinks length=1000 (bytes) and the browser reads 1000 characters which causes it to skip over </sandbox>...<sandbox> into the next comment where you carefully insert your own </sandbox> and break out
# [19:07] <othermaciej> fancier sandbox flag like unique origin would be harder
# [19:07] <TabAtkins> But (1) that makes it easy to eat the entire page if you compute it wrong, and (2) it makes it easy to just say length=0 because it "always works" until someone malicious puts </sandbox> in their content.
# [19:07] * Quits: mat_t (~mattomasz@91.189.88.12) (Quit: This computer has gone to sleep)
# [19:08] <TabAtkins> Philip`: Yeah, all sorts of issues around @length. They just weren't immediately obvious, so I had to spend some time thinking about it.
# [19:08] <othermaciej> length=0 doesn't always work - it would expect the </sandbox> tag immediately and go into failure mode (whatever that is)
# [19:09] <TabAtkins> length=0 is assuming my "forgiving" mode of seeking forward to the next </sandbox>.
# [19:09] <othermaciej> if you don't find a </sandbox> tag in the right place, presumably the only safe thing to do is eat the rest of the page
# [19:09] <othermaciej> ah
# [19:09] <TabAtkins> Because the strict mode could only, um, kill the page?
# [19:09] * Philip` doesn't think security and forgiveness mix well
# [19:09] <othermaciej> using <sandbox length=0> with those semantics would add no security whatsoever
# [19:09] <TabAtkins> Exactly.
# [19:09] <TabAtkins> So, that's junked.
# [19:10] <TabAtkins> (The problem is it *appears* to work just fine, until the obvious exploit happens.)
# [19:11] <othermaciej> any plausible @length proposal would need to not have such an escape clause
# [19:11] <TabAtkins> Yes.
# [19:11] * Joins: jlebar (~jlebar@63.245.220.220)
# [19:11] <othermaciej> I think the main problem with nonzero length is the bytes vs. characters trap as discussed
# [19:12] <TabAtkins> And if the failure mode is "eat the page" and it only happens in rare cases, that's not very good.
# [19:12] * Quits: davidhund (~davidhund@dnuhd.xs4all.nl) (Quit: ... succes ermee! :-))
# [19:12] <othermaciej> I wonder how tricky it is to escape any </sandbox> tags vs. the escaping required for @srcdoc
# [19:12] <TabAtkins> A decent bit.
# [19:13] <Philip`> s/</</g vs s/"/"/g
# [19:13] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
# [19:13] <TabAtkins> Especially if you allow *only* </sandbox> or every valid syntactic variant.
# [19:13] <othermaciej> is there any way to stick one in that won't appear in an obvious literal search?
# [19:13] <TabAtkins> Isn't something like < / sandbox > allowed?
# [19:13] <Philip`> The problem with only requiring escaping of </sandbox> is that people will forget to escape it, and then won't notice until they're attacked
# [19:13] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 245 seconds)
# [19:14] <TabAtkins> Philip`: You can't just generally escape <, because that defeats the entire purpose of allowing markup, which is why sandbox exists in the first place.
# [19:14] <othermaciej> if you fail to escape quotes in @srcdoc I guess you notice immediately
# [19:14] <Philip`> whereas with @srcdoc, they'll notice as soon as they try to write any " character
# [19:14] <Philip`> which is likely to happen in common usage
# [19:14] <TabAtkins> othermaciej: Precisely - quotes are common, and will fail with non-malicious content.
# [19:14] <TabAtkins> And will fail in an obvious way.
# [19:15] * TabAtkins has dealt with forgetting to escape quotes before - it's really easy to see what you did wrong.
# [19:15] <Philip`> It'll be obvious if they have a syntax-highlighting view-source feature, at least
# [19:16] <TabAtkins> I mean it's obvious in the page itself, when you have a sentence cut off like "And I think it isn".
# [19:16] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 276 seconds)
# [19:16] <Philip`> TabAtkins: Why can't you generally escape <, and define <sandbox> so that it unescapes the content before inserting into an iframe for rendering?
# [19:16] <TabAtkins> Philip`: I suppose that fixes the fallback for <sandbox>, but not the other issues with @length.
# [19:16] <Philip`> TabAtkins: People don't use single-quotes for attributes
# [19:17] <TabAtkins> Philip`: Yes they do?
# [19:17] <Philip`> Much less than double-quotes
# [19:17] <TabAtkins> Okay, sure, but double-quotes are still pretty common in content.
# [19:17] * TabAtkins single-quotes all the time to avoid hitting shift.
# [19:17] <Philip`> (I forget the numbers but I think there was well over 10x difference in popularity of " vs ')
# [19:19] <Philip`> Maybe we should use e as the sandbox delimiter
# [19:19] <TabAtkins> Heh.
# [19:19] <Philip`> so that people are extremely likely to notice when they forget it
# [19:19] <TabAtkins> That fails for chinese!
# [19:19] <Philip`> unless they're Chinese
# [19:19] <Philip`> Yeah :-(
# [19:20] <TabAtkins> Do statistical analysis of the page's textContent and escape on the top 5 characters in the histogram.
# [19:20] <Philip`> Just hard-code it based on TLD
# [19:21] <TabAtkins> What about data:?
# [19:21] <TabAtkins> Or localhost, I suppose. Intranets in general.
# [19:21] <Philip`> Base it on the user's locale
# [19:22] <Philip`> Add a series of submenus to let users override the default if it's wrong
# [19:22] <Philip`> Anyway, @srcdoc still seems like the least bad option
# [19:24] <TabAtkins> Indeed.
# [19:25] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [19:25] * TabAtkins also expects @length to fail from authors, frex, measuring length and *then* escaping & or something.
# [19:31] * Joins: dandaman (~Daniel.Sa@216.52.240.243)
# [19:31] <dandaman> <select id="intCountriesList" name="intCountriesList" size="5"
# [19:31] <dandaman> onchange="regionsOrCities($('intCountriesList').value)" style="height: 63px;">
# [19:31] <dandaman> <option value="" title="--Select Country--">--Select Country--</option>
# [19:31] <dandaman> </select>
# [19:31] <dandaman> my onchange isnt doing anything?
# [19:31] <dandaman> minus a question mark, anyone have an idea
# [19:31] <Workshiva> Do you unfocus the select?
# [19:31] <dandaman> yea
# [19:32] <dandaman> but i click back into it
# [19:32] <Workshiva> But you don't need the $(), you can just use this.value (or even value)
# [19:32] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
# [19:32] * Joins: remysharp (~remysharp@cpc2-brig17-2-0-cust448.3-3.cable.virginmedia.com)
# [19:32] <TabAtkins> Does @onchange="alert('foo')" work?
# [19:32] <dandaman> hold on
# [19:33] <dandaman> TabAtkins: yeah alert foo works
# [19:33] <dandaman> i didnt have tha @ symbol though
# [19:34] <TabAtkins> Yeah, that's just me referring to an attribute.
# [19:34] <dandaman> kk
# [19:34] <TabAtkins> What about onchange="alert(this.value)"?
# [19:35] <dandaman> yep
# [19:35] <dandaman> that works
# [19:35] <TabAtkins> Then try onchange="regionsOrCities(this.value)"
# [19:36] <TabAtkins> (Note that the jQuery object returned by $('intCountriesList') doesn't have a .value property, though it does have a .value() method.)
# [19:36] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
# [19:36] <dandaman> tried that, didnt work
# [19:36] <dandaman> im gonna try fiddling around with the function
# [19:36] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Read error: Connection reset by peer)
# [19:37] <TabAtkins> Well, you've isolated the problem at least. It's with the function, not your onchange.
# [19:37] <Philip`> Shouldn't it be $('#intCountriesList')?
# [19:37] <dandaman> its the function
# [19:37] <TabAtkins> Depends; if it's Prototype, no.
# [19:37] <TabAtkins> Maybe Prototype has .value, I dunno.
# [19:37] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
# [19:38] <dandaman> ty for the help
# [19:38] * Quits: Rik` (~Rik`@213.41.141.234) (Quit: Rik`)
# [19:38] <TabAtkins> np
# [19:38] <dandaman> god damn this channel is so much more useful than C++ or C, those Aholes just call me a retard constantly
# [19:38] <TabAtkins> Testing with alert() is the equivalent of debugging with printf.
# [19:38] <TabAtkins> Not best practice, but damned if it doesn't work.
# [19:39] <dandaman> ill keep it in mind, thanks
# [19:39] * TabAtkins wouldn't recommend going to a c++ channel for javascript help in the first place.
# [19:40] <dandaman> i meant for c++ help
# [19:40] <dandaman> ok back to work, thanks again
# [19:40] * Parts: dandaman (~Daniel.Sa@216.52.240.243)
# [19:40] * Joins: weinig (~weinig@17.246.16.234)
# [19:40] <TabAtkins> The reasoning against <sandbox content=[base64-encoded]> is just that base64 makes things considerably larger, right? Are there other security considerations I don't get?
# [19:40] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [19:41] <TabAtkins> Well, content-in-base64-in-attributes is presumably even more of an antipattern than content-in-attributes.
# [19:41] <othermaciej> it's certainly no better, although it requires 0 additional escaping
# [19:41] <othermaciej> though if you are base-64 encoding you may as well use a data: attribute so no new feature would really be needed
# [19:42] <Workshiva> Yeah, I don't see the gain
# [19:44] <TabAtkins> A data: url used in <iframe @src> is automatically unique-origin, right? (Though presumably we could change that, so @sandbox's origin flag could actually have an effect.)
# [19:47] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
# [19:47] <AryehGregor> [100715 13:13:39] <Philip`> TabAtkins: Why can't you generally escape <, and define <sandbox> so that it unescapes the content before inserting into an iframe for rendering? <-- This was my suggestion, which I think I came up with before srcdoc was added to the spec, or certainly before I knew about it. But srcdoc is a better solution.
# [19:47] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [19:47] <TabAtkins> AryehGregor: That's just a solution to the bad-fallback problem, though. It doesn't solve any of the other problems.
# [19:48] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Quit: adactio)
# [19:48] <AryehGregor> No, it solves all the same problems srcdoc does.
# [19:48] <TabAtkins> Well, what happens if the parser sees <sandbox><b>foo!</b></sandbox>?
# [19:49] <AryehGregor> If it sees <>"'& unescaped, it consumes everything up to the next </sandbox> and displays the iframe as empty or with an error message or something.
# [19:49] <AryehGregor> This means that lack of escaping will be quickly caught, same as srcdoc.
# [19:49] <AryehGregor> Although if it's not caught, then of course it will be vulnerable, same as srcdoc (unless you eat the page).
# [19:50] <wirepair> with the track record of people escaping <>"'& i'd say base64 encoding would be a safer solution
# [19:50] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Read error: Connection reset by peer)
# [19:50] <TabAtkins> And what if the user content is "<b>Foo!</b></sandbox><script src=evil></script>"?
# [19:50] * Joins: smaug_ (~chatzilla@a91-154-44-92.elisa-laajakaista.fi)
# [19:50] <wirepair> TabAtkins exactly ;)
# [19:50] <AryehGregor> With srcdoc, what if the user content is: "></sandbox><script src=evil></script>
# [19:50] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
# [19:50] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Read error: Operation timed out)
# [19:51] <wirepair> i do pen-testing / security research for a living, and trust me, escaping/encoding "> seems to be beyond a lot of people
# [19:51] <AryehGregor> If there's no escaping, you're screwed, sure. But if it fails fast on innocuous content with no escaping, people will escape.
# [19:51] <TabAtkins> I think that people using " in their comments is more common than people using <, personally.
# [19:51] <AryehGregor> I said it should fail on " for exactly that reason.
# [19:51] <TabAtkins> But it may not be a hugely significant difference.
# [19:51] <AryehGregor> Even though there's technically no reason it should have to.
# [19:51] <TabAtkins> Oh, I see.
# [19:51] <AryehGregor> (I mean, no reason you'd need to escape " otherwise.)
# [19:51] <AryehGregor> And ' too, even.
# [19:51] <TabAtkins> I missed that part, yeah.
# [19:51] <Philip`> Base64 means you need to understand encodings
# [19:51] <AryehGregor> So it will fail even faster than srcdoc.
# [19:52] <Philip`> (since you have to apply it to bytes, and have to agree with the browser on the interpretation of those bytes)
# [19:52] <wirepair> ah right.
# [19:52] <Philip`> which seems like a pain
# [19:52] <wirepair> srcdoc in general seems like a pain though
# [19:52] <wirepair> ;)
# [19:52] * Joins: mpt (~mpt@canonical/mpt)
# [19:53] * TabAtkins wonders if having to escape <>&'" is worth the convenience of having the content as "real" elements.
# [19:53] <Philip`> With @srcdoc there's no additional character encoding issue over what's already needed for the rest of your content
# [19:53] <wirepair> what exactly is the benefit of having the data inline as opposed to it being an external document?
# [19:53] <TabAtkins> Saving a network request.
# [19:54] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
# [19:54] <AryehGregor> And saving authoring complexity.
# [19:54] <TabAtkins> (Possibly *many*, if you have, say, 200 blog comments that each need to be sandboxed.)
# [19:54] <AryehGregor> So you don't have to write a separate script that will repeat all your permissions checks and whatever all over again.
# [19:54] <wirepair> well, could you not put those 200 blog comments in a single file, but yeah i get your point
# [19:54] * Joins: JonathanNeal_ (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
# [19:55] <TabAtkins> wirepair: Not if you want to be able to put stuff on the comment structure that needs to run scripts, like a thumbs up voter or something.
# [19:55] <AryehGregor> Then they can interfere with each other. Not necessarily so bad, but not preferable. Ideally any monkey business should be isolated.
# [19:55] <AryehGregor> Right, that too.
# [19:55] <wirepair> yeah no i understand ;)
# [19:55] <AryehGregor> You could absolutely-position stuff over it, if you're insane, but . . .
# [19:55] <TabAtkins> Yeah, no, that's stupid. ^_^
# [19:56] <wirepair> so far what has the most 'votes' for srcdoc, just escaping "<>&' ?
# [19:56] <TabAtkins> No, just escape " and & (or ', if you use that for your attributes).
# [19:57] <wirepair> ah gotcha
# [19:57] <TabAtkins> And escaping & isn't even necessary for security; skipping it just means that sometimes things will get eaten as escapes when they aren't.
# [19:57] * Quits: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com) (Ping timeout: 258 seconds)
# [19:57] * Joins: maikmerten_ (~maikmerte@port-92-201-134-113.dynamic.qsc.de)
# [19:57] <TabAtkins> So really, just escape whatever quote character you're ursing.
# [19:58] <wirepair> and the source documents content encoding has precedence yeah? my concern would be malformed multibyte sequences
# [19:58] <TabAtkins> Yes.
# [19:58] <TabAtkins> If you're not encoding everything in utf-8 you're doing it wrong anyway.
# [19:59] <wirepair> jeez, please tell that to japan ;)
# [19:59] <TabAtkins> I will.
# [19:59] * TabAtkins shakes his fist vaguely west-ward.
# [19:59] <wirepair> haha
# [19:59] * Quits: maikmerten (~maikmerte@port-92-201-196-56.dynamic.qsc.de) (Ping timeout: 246 seconds)
# [20:00] <TabAtkins> What's Japan's common encoding? utf-16, or one of those legacy encodings designed just for japanese?
# [20:00] <wirepair> well my customers used Shift_JIS a lot
# [20:00] <wirepair> on rare occassions you'll come across euc-jp
# [20:01] <wirepair> but yeah utf-8 is becoming more commonplace for sure
# [20:03] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [20:06] * Quits: foolip (~foolip@83.218.67.122) (Quit: Leaving)
# [20:06] * Quits: kennyluck (~kennyluck@133.27.228.178) (Quit: kennyluck)
# [20:08] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Client Quit)
# [20:19] * Joins: estellevw (~estelle@173-164-227-246-SFBA.hfc.comcastbusiness.net)
# [20:22] * Quits: remysharp (~remysharp@cpc2-brig17-2-0-cust448.3-3.cable.virginmedia.com) (Ping timeout: 240 seconds)
# [20:23] * Joins: pauld (~chatzilla@74.125.57.50)
# [20:24] <Hixie> the main problem with a caret blinking API is that you need a way to know what to repaint
# [20:26] <Hixie> we could have a method that takes the x,y position of the center of the caret and works out (from the font size and baseline settings and from the OS caret width preferences) where to draw the caret, and then have it return an object that's x,y,w,h
# [20:27] <Hixie> but that seems like a pain
# [20:27] <Hixie> the alternative is to just have the method take an x,y,w,h and draw a caret at that position, potentially not following the OS rules on caret width if the given width isn't enough to draw the caret
# [20:28] <Hixie> we could also tell authors to provide a big width with the x,y being in the center, but then the problem is dealing with edge cases
# [20:28] <Hixie> maybe we should have the method take x,y,w,h of the text field, then a separate x,y of the caret
# [20:29] <Hixie> and the caret just gets clipped to the x,y,w,h
# [20:31] * Joins: dave_levin (~dave_levi@74.125.59.65)
# [20:32] * Quits: pauld (~chatzilla@74.125.57.50) (Remote host closed the connection)
# [20:32] <Hixie> or we could say you have to repaint whatever your clip region is
# [20:33] <Hixie> and then just clip it to the clip region
# [20:33] <Hixie> so if you want to reduce your workload you just set your clip region to just the control before calling the method, or something
# [20:34] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
# [20:41] * Quits: jorlow (~jorlow@74.125.57.60) (Quit: jorlow)
# [20:44] * Joins: dbaron (~dbaron@nat/mozilla/x-ttcvvjptibrhdblg)
# [20:46] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
# [20:46] * Joins: mmn (~mmn@129-97-225-230.uwaterloo.ca)
# [20:48] * Quits: JonathanNeal_ (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com) (Ping timeout: 258 seconds)
# [20:55] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Quit: zzzzz)
# [20:57] * Joins: michaeln (~michaeln@nat/google/x-dsipxcthqpwvklfk)
# [20:57] <Hixie> which is better, having the caret drawing code take a callback that is invoked when the caret needs to be redrawn for blinking, or having the author just call the caret code 20 times a second just in case the user has a 10Hz blink rate?
# [20:57] * Quits: estellevw (~estelle@173-164-227-246-SFBA.hfc.comcastbusiness.net) (Quit: estellevw)
# [20:59] <TabAtkins> Based on my limited experience with <canvas>, I prefer something that I can call myself whenever I repaint.
# [21:00] <Hixie> well for a caret you don't want to repaint the whole canvas each time
# [21:00] * Joins: kennyluck (~kennyluck@EM114-48-17-10.pool.e-mobile.ne.jp)
# [21:00] * Quits: kennyluck (~kennyluck@EM114-48-17-10.pool.e-mobile.ne.jp) (Excess Flood)
# [21:00] <TabAtkins> Pfft. My text editor will have a live video background.
# [21:01] <Hixie> there is so much wrong with that sentence...
# [21:01] * Quits: weinig (~weinig@17.246.16.234) (Quit: weinig)
# [21:02] <TabAtkins> Then I can use webkit's background-clip:text to play a *different* video for the text itself.
# [21:02] <TabAtkins> Though that's silly, obviously. The video itself should play in the text, then a grayscale in the background.
# [21:02] <Hixie> there's no _canvas_ in this fantasy :-P
# [21:03] * Joins: weinig (~weinig@17.246.16.234)
# [21:03] <TabAtkins> You can't use video directly as a background, I don't think. So you have to draw it into a canvas at 50 fps.
# [21:03] <TabAtkins> Also, grayscaling the video needs canvas.
# [21:03] <TabAtkins> Or SVG, I suppose.
# [21:04] * TabAtkins wonders if SVG filters on a <video> can get copied into a <canvas>.
# [21:04] <Hixie> i know i may be out of luck, since we're talking about drawing a caret to a canvas, but does anyone have any _sane_ use case experience to provide here? :-P
# [21:04] <TabAtkins> You've already lost the sane people.
# [21:04] <TabAtkins> I'm going to implement a text editor that plays pong with the letters.
# [21:07] <TabAtkins> But seriously, I don't want my caret to blink out too fast just because a callback happened to trigger a few milliseconds before I was otherwise going to repaint.
# [21:07] <TabAtkins> I'd just end up using the callback to flip a variable that I then check in my actual drawing code, and then I might as well just have a property that exposes whether the caret should be visible or not.
# [21:08] <Hixie> the way i envision this, you don't worry about blinking the caret
# [21:08] <Hixie> drawCaret() just decides based on a timer whether to draw the caret or not for this frame
# [21:08] <TabAtkins> Yes, that would be fine. I can call drawCaret() in the rest of my drawing code, right?
# [21:08] <jgraham> I vaugely feel like a callback is better if the browser is providing the timing
# [21:09] <Hixie> or maybe an event?
# [21:09] <jgraham> But I have nothing to go on there
# [21:09] <Hixie> <canvas onredrawcaret=""> ?
# [21:09] <jgraham> yuck
# [21:09] * TabAtkins had problems with flickering when he tried to have things draw on separate schedules.
# [21:10] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
# [21:10] <jgraham> Hmm, I can see that could be an issue
# [21:16] * Joins: othermaciej (~mjs@17.246.16.182)
# [21:19] * Quits: plainhao (~plainhao@mail.xbiotica.com) (Quit: plainhao)
# [21:21] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
# [21:21] <jgraham> So, do we also need drawSelection?
# [21:21] <jgraham> It seems like canvas apps could always put the caret at the end of the selection
# [21:22] <jgraham> Althought I suppose that would be bad if they tried to differentiate their behaviour based on OS
# [21:22] <jgraham> (which seems unlikely but possible)
# [21:22] <jgraham> It also seems possible that people will fail to move the caret when drawing a selection if they have to do it manually
# [21:23] <jgraham> (I'm not sure how draw selection could work really)
# [21:23] <jgraham> (so it may not even be possible to do in a sane way)
# [21:25] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 245 seconds)
# [21:26] <jgraham> Hixie: BTW I filed a bug in the handling of EOF after a foreign-content closing tag
# [21:26] <jgraham> e.g. <svg></svg>
# [21:28] <Hixie> jgraham: i haven't been able to find good documentation on accessibility APIs' handling of selections
# [21:28] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
# [21:28] <Hixie> (accessibility APIs in general are pretty poorly documented)
# [21:29] <AryehGregor> Do most browsers cache HTTP redirects already? Apparently IE9 now does.
# [21:29] <Hixie> i don't really see what such an API would do, though
# [21:29] <TabAtkins> AryehGregor: Yes.
# [21:29] <TabAtkins> At least, it is indeed done.
# [21:29] <Hixie> we don't need an API to say what the selected text _is_, which might well be something AAPIs would care about
# [21:30] <Hixie> (we don't need it because the UA already knows what the text is since they have the control itself in the DOM)
# [21:32] <jgraham> Hixie: AFAICT the only point is to control where the magnifier is positioned
# [21:32] <jgraham> It has to be at the end of the selection
# [21:32] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
# [21:33] <jgraham> For reasons I don't follow Richard seems to think that the fact that OSX doesn't move the caret to the end of selections means that we need a seperate API
# [21:33] <jgraham> (or an accessibility-specific API)
# [21:33] * Quits: jlebar (~jlebar@63.245.220.220) (Quit: Leaving)
# [21:36] * Joins: BArOc (~maxzagato@190.24.156.162)
# [21:37] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft) (Ping timeout: 240 seconds)
# [21:38] <jgraham> Hixie: Your change proposal for ISSUE 32 fails to make the case for UAs being required to implement the summary attribute. Given the arguments presented above it seems like they would be better off not doing that
# [21:38] <othermaciej> there is no caret when you have a non-caret selection established
# [21:39] * Quits: meledin_ (~vladi@f2.c7.5d45.static.theplanet.com) (Read error: Operation timed out)
# [21:39] * Quits: jgraham (~jgraham@web22.webfaction.com) (Read error: Operation timed out)
# [21:40] <othermaciej> let me check how/whether carets or selections are represented via Accessibility Inspector
# [21:42] * Quits: maikmerten_ (~maikmerte@port-92-201-134-113.dynamic.qsc.de) (Read error: Connection reset by peer)
# [21:42] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
# [21:42] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
# [21:43] * Joins: meledin_ (~vladi@f2.c7.5d45.static.theplanet.com)
# [21:43] <othermaciej> both are exposed via the http://axdb.apple.com/AXSelectedTextMarkerRange property
# [21:43] * Joins: jgraham (~jgraham@web22.webfaction.com)
# [21:43] <othermaciej> ignore the URLey bits, it's just AXSelectedTextMarkerRange
# [21:44] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [21:44] * Joins: dandaman (~Daniel.Sa@216.52.240.243)
# [21:46] <othermaciej> and the assistive technology is allowed to query the bounding box of the reported text marker range
# [21:46] * Joins: jlebar (~jlebar@nat/mozilla/x-baogfughzpiefivv)
# [21:46] <othermaciej> so to fulfill the selection-related accessibility APIs, we would need to know the bounding box of the current selection or caret
# [21:47] * Parts: dandaman (~Daniel.Sa@216.52.240.243)
# [21:48] * Quits: bobchao (~cctw@140.109.16.241) (Ping timeout: 258 seconds)
# [21:48] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
# [21:48] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [21:49] <othermaciej> there's also a way to request the text marker (and thereby if needed a string for a range) for a point, but that aspect seems impractical to do with canvas (you'd have to have a JS callback for the web developer's code to do hit testing)
# [22:06] * Quits: davidb_ (~davidb@mozca02.ca.mozilla.com) (Quit: davidb_)
# [22:06] * Joins: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
# [22:20] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
# [22:23] * Quits: othermaciej (~mjs@17.246.16.182) (Read error: Connection reset by peer)
# [22:23] * Joins: mdelaney (~mdelaney@171.66.51.191)
# [22:24] <TabAtkins> AryehGregor: You around?
# [22:24] <AryehGregor> Yes.
# [22:24] * Joins: othermaciej (~mjs@17.246.16.182)
# [22:24] * Parts: danbri (~danbri@unaffiliated/danbri) ("Leaving")
# [22:25] <TabAtkins> On this: http://forums.xkcd.com/viewtopic.php?p=2236984#p2236984 is the second step valid? I see they've moved the 2 out of e's power's denominator by squaring, but I think it should have more effect than just squaring the G.
# [22:25] * TabAtkins just uses AryehGregor for math from now on.
# [22:26] <AryehGregor> Ugh, don't they have a LaTeX display extension there?
# [22:26] <TabAtkins> Yes they do. Do you have js turned on?
# [22:26] <AryehGregor> Yes.
# [22:26] <Philip`> Yes, if you wait ten seconds for it to load
# [22:27] <AryehGregor> Not working for me.
# [22:27] <TabAtkins> I'll screenshot then.
# [22:28] <Philip`> I presume they should have had (2\pi)^2 on the left
# [22:28] <TabAtkins> Philip`: Plus squaring the 1/omega^2 on the right.
# [22:29] <Philip`> Oh, I missed that
# [22:30] <TabAtkins> http://www.xanthir.com/etc/math.png
# [22:31] <jgraham> The last line should have x^2 on the top of the fraction
# [22:31] <AryehGregor> The second step looks okay, multiply by 2pi and square both sides. Except that you should have (2pi)^2 on the left.
# [22:31] <TabAtkins> AryehGregor: (ab)^2 is a^2 * b^2, though.
# [22:31] <TabAtkins> So the rhs should square the 1/omega^2 as well.
# [22:31] <AryehGregor> You mean sigma?
# [22:32] <TabAtkins> Um, yes.
# [22:32] <AryehGregor> Oh, right, I missed that.
# [22:32] <jgraham> That is true
# [22:32] <AryehGregor> Yes, should be sigma^4.
# [22:32] <TabAtkins> kk, so it's all kinds of messed up. Great.
# [22:32] <TabAtkins> Well, the important part was done for me.
# [22:32] <AryehGregor> The general idea is right, though.
# [22:32] <AryehGregor> I somehow doubt we actually want to mandate this in CSS.
# [22:32] <TabAtkins> No, we don't. But I was asked for it. ^_^
# [22:33] <TabAtkins> There are much easier approximations that should get close enough.
# [22:33] <jgraham> That means it doesn't end up in the nice simple W exp(W) form they want though
# [22:33] <TabAtkins> Oh, hm.
# [22:33] <jgraham> (the 1/sigma^4)
# [22:33] <AryehGregor> Oh, you're trying to isolate sigma, hmm?
# [22:33] <AryehGregor> Well, so don't square.
# [22:33] <Philip`> Just go with 37% instead of 1% and it's trivial :-p
# [22:33] <AryehGregor> Just multiply both sides by -x^2/pi.
# [22:33] <AryehGregor> I mean.
# [22:33] <AryehGregor> -x^2 * pi.
# [22:33] <jgraham> Yes
# [22:34] <AryehGregor> Whatever.
# [22:34] <TabAtkins> AryehGregor: Yeah.
# [22:34] <AryehGregor> Then take the W function.
# [22:34] <TabAtkins> kk
# [22:34] <TabAtkins> Hm, yeah, not sure why they thought it was necessary to pull the 2 out of the exp.
# [22:34] <jgraham> So yeah, basically it is all kinds of wrong
# [22:34] <jgraham> But the right general idea :)
# [22:39] <TabAtkins> K, I've posted an updated version that I think fixed the original flaws.
# [22:39] <TabAtkins> Urg, wait, G is still getting squared.
# [22:40] <TabAtkins> k, fixed.
# [22:41] <TabAtkins> Hmm... The starting point is still wrong, though - there's a sqrt in the original equation that got dropped.
# [22:41] <annevk> wtf is leif on about
# [22:41] <annevk> i explained why i didn't entirely agreed
# [22:42] <annevk> oh well
# [22:42] <AryehGregor> TabAtkins, you seem to be using some mix of the two-dimensional and one-dimensional equations from Wikipedia.
# [22:42] <annevk> not like this is anything new
# [22:42] <hober> annevk: I never understand his emails
# [22:42] <TabAtkins> AryehGregor: I'm not, the responder is. I'm fixing it now.
# [22:42] <TabAtkins> I'm Xanthir in this conversation.
# [22:43] <AryehGregor> I know.
# [22:43] <AryehGregor> You can drop the \pm, by the way. Standard deviations are always treated as positive.
# [22:43] <TabAtkins> Yeah.
# [22:44] <TabAtkins> Lessee... 1/sqrt(2*pi*sigma^2) is the same as 1/(sqrt(2*pi)*sigma), right?
# [22:44] * TabAtkins knows this is basic algebra.
# [22:46] <TabAtkins> Hm, though. That then seems to make it more difficult to get the RHS into the correct form. Damn.
# [22:46] * Quits: roc (~roc@121.98.230.221) (Quit: roc)
# [22:47] <annevk> I'm no longer going to contribute to polyglot discussions
# [22:47] <annevk> waste of time
# [22:47] <TabAtkins> Welcome to the club of "everyone else in the world", anne.
# [22:47] * Joins: romeo_ (~romeo__@x1-6-00-07-95-57-08-bb.k459.webspeed.dk)
# [22:47] <AryehGregor> If sigma is positive, then yes, it's the same.
# [22:47] <AryehGregor> This is where you want to square it.
# [22:47] <AryehGregor> That won't harm the exponential (just knock out a constant), but it will get the sigma squared.
# [22:48] <TabAtkins> Ah, you're right.
# [22:48] <AryehGregor> Maybe the original poster's mistakes weren't where you thought. :)
# [22:48] <AryehGregor> (we, whateveR)
# [22:48] <annevk> I can't believe there are so many replies and nobody called Leif on his nonsense
# [22:49] <annevk> (for the record, my latest reply was before the "I'm no longer ..." above; though I should at least rectify such nonsense for once)
# [22:49] <annevk> thought*
# [22:49] <TabAtkins> AryehGregor: Yup, you're right. If we pretend that the first step has a \sqrt where it needs to, then the second step is correct.
# [22:49] <jgraham> annevk: I don't think that anyone understand much of what leif says tbh
# [22:50] <jgraham> So he is often just ignored
# [22:50] * Quits: othermaciej (~mjs@17.246.16.182) (Read error: Connection reset by peer)
# [22:51] * Joins: othermaciej (~mjs@17.246.16.182)
# [22:52] <annevk> Sam replied directly to him
# [22:53] <annevk> still not sure what a good color for webforms2.org would be
# [22:53] <annevk> what can beat hotpink? ;p
# [22:53] <TabAtkins> annevk: What part of MQ did you want reviewed?
# [22:56] <Philip`> annevk: It should blink
# [22:56] <Philip`> (using APNG)
# [22:57] <TabAtkins> Aw yeah.
# [23:01] * Quits: jlebar (~jlebar@nat/mozilla/x-baogfughzpiefivv) (Ping timeout: 240 seconds)
# [23:03] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
# [23:03] * Joins: jlebar (~jlebar@nat/mozilla/x-ksxsanytbbatehzj)
# [23:05] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
# [23:10] * Quits: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net) (Quit: abarth)
# [23:10] * Quits: othermaciej (~mjs@17.246.16.182) (Read error: Connection reset by peer)
# [23:11] * Quits: mdelaney (~mdelaney@171.66.51.191) (Quit: mdelaney)
# [23:11] * Joins: othermaciej (~mjs@17.246.16.182)
# [23:12] * Joins: cardona507_ (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net)
# [23:12] * Quits: cardona507 (~cardona50@c-24-130-129-16.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [23:12] * cardona507_ is now known as cardona507
# [23:13] * Quits: ROBOd (~robod@92.86.244.224) (Quit: .)
# [23:13] * Quits: jlebar (~jlebar@nat/mozilla/x-ksxsanytbbatehzj) (Ping timeout: 240 seconds)
# [23:13] * Joins: mdelaney (~mdelaney@171.66.51.191)
# [23:14] * Joins: abarth (~abarth@c-67-169-69-72.hsd1.ca.comcast.net)
# [23:18] * Joins: MikeSmithXX (~MikeSmith@EM114-48-44-185.pool.e-mobile.ne.jp)
# [23:19] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
# [23:20] * Joins: jgornick (~joe@199.199.212.242)
# [23:20] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
# [23:22] * Quits: MikeSmithX (~MikeSmith@EM114-48-195-198.pool.e-mobile.ne.jp) (Ping timeout: 276 seconds)
# [23:30] * Quits: othermaciej (~mjs@17.246.16.182) (Read error: Connection reset by peer)
# [23:31] * Joins: othermaciej (~mjs@17.246.16.182)
# [23:40] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
# [23:42] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
# [23:43] <Hixie> jgraham: feel free to write another CP that removes the need for UAs to implement it too
# [23:43] <Hixie> jgraham: you can copy mine and just change that bit if you want
# [23:43] <Hixie> othermaciej: so wait, what do we need to expose?
# [23:43] <Hixie> othermaciej: just the bounding box of the selection? not the actual selection?
# [23:43] <Hixie> othermaciej: does OS X have wide carets?
# [23:43] <Hixie> othermaciej: (in windows you can set the width of the caret apparently)
# [23:44] <Hixie> (which makes a caret drawing function hard)
# [23:44] <othermaciej> when you are in a normal editable text area on OS X (at least in WebKit), the following pieces of data can be obtained:
# [23:44] <othermaciej> - the endpoints of the selection range (equal to each other if the selection is a caret), in an abstract form that isn't exactly a character offset
# [23:45] <othermaciej> - the ability to get the string of text in that range
# [23:45] <othermaciej> - the ability to get the visual bounding box of that range
# [23:46] <othermaciej> there is also the means in the API to ask for a text marker for a given point, but I am not sure if any assistive technologies actually use that
# [23:46] <Hixie> well the first two are easy since we have the underlying control already
# [23:46] <Hixie> the third one is harder... what can we use as a surrogate in the API for exposing that?
# [23:46] <othermaciej> right, the first two don't require any additions to what HTML5 has, if you put a text control in the child DOM
# [23:46] <Hixie> for just a caret we can just have a caret drawing function
# [23:46] <Hixie> but for a selection...
# [23:46] <othermaciej> drawing a caret or selection is one possibility
# [23:47] <othermaciej> of course, it may be hard to spec drawing a selection in a way that is both cross-platform and useful to web developers
# [23:47] <Hixie> hard is one way to put it
# [23:48] <Hixie> i wonder what the equivalent is on windows
# [23:49] <othermaciej> I tried to look at some MSAA docs and I couldn't find anything for the selection, as opposed to the caret, and Rich claimed Windows apps report the end of the selection as the caret position
# [23:49] <othermaciej> but I have no firsthand knowledge of that
# [23:49] <annevk> Philip`, sweet
# [23:49] <annevk> Philip`, can you make one?
# [23:50] <annevk> TabAtkins, just what changed; section 2/3
# [23:50] <annevk> TabAtkins, but only if you have time, it's not necessary
# [23:50] <Philip`> annevk: I've forgotten how to do it
# [23:50] <TabAtkins> annevk: I've had it sitting in my open tabs since yesterday, so I might as well.
# [23:51] <Philip`> Most of my APNGs were created by a Perl script I wrote, but that's not so great since I didn't implement any of the decent PNG compression methods
# [23:51] <annevk> TabAtkins, though please no feature requests ;p
# [23:51] <Hixie> othermaciej: he also claimed something similar for OS X which is apparently wrong
# [23:52] <annevk> Philip`, it's a 32x32 image...
# [23:52] <TabAtkins> annevk: No promises.
# [23:52] <Philip`> I think there might have been a Firefox extension that made APNGs easily
# [23:52] <jgraham> Please no flashing favicons
# [23:52] * Philip` wonders if support has become more widespread recently
# [23:53] <jgraham> I will have to kill you
# [23:53] <Philip`> jgraham: What about subtle pulsing?
# [23:53] <jgraham> And then we will have even fewer editors for web specs
# [23:53] <othermaciej> Hixie: I think he may be confused about how selections work on OS X
# [23:53] <annevk> means you'll finally come to the Netherlands?
# [23:53] * Philip` still likes http://zaynar.co.uk/favicon.ico
# [23:53] <othermaciej> when you hit an arrow key when you have a selection, you do get a caret at a specific point
# [23:53] <annevk> might be worth it ;p
# [23:53] <othermaciej> but prior to that point, there *is* no caret
# [23:54] <othermaciej> but he interprets that as the caret was secretly at the end of the selection
# [23:54] <jgraham> Philip`: "subtle" meaning with a ime period of > 1 week, say?
# [23:54] <jgraham> s/ime//
# [23:54] <othermaciej> that's not how the AX APIs expose it, afaict
# [23:54] * AryehGregor still likes http://www.p01.org/releases/DEFENDER_of_the_favicon/
# [23:55] <Philip`> jgraham: APNG has a maximum of 65535 seconds per frame, so I suppose you'd only need ten frames for that
# [23:55] <Philip`> although I don't know how well implementations handle timers like that
# [23:55] <Philip`> (I don't fancy testing it)
# [23:56] <AryehGregor> A time period of a few minutes sounds good to me. Maybe half an hour.
# [23:56] <AryehGregor> Once in a while, someone will notice some movement out of the corner of their eye.
# [23:56] <AryehGregor> Then go crazy trying to figure out what it is.
# [23:57] <TabAtkins> Sounds like what I did with the tech support portal at my old job.
# [23:57] <annevk> a speed that drives jgraham temporarily insane is acceptable I think
# [23:58] <annevk> there's no reason to visit webforms2.org anyway
# [23:58] <annevk> it's a reminder of what that was
# [23:58] <AryehGregor> TabAtkins, what did you do with the tech support portal at your old job?
# [23:59] <TabAtkins> It was named GLaDOS for no particular reason, so of course I needed to put in more references to insane AIs. 1 out of every 3 pageloads, the PHP writes in some js that flashes a full-screen picture of SHODAN for a fraction of a second (the delay of a setTimeout(func,0) call) with a random timer of roughly 5 minutes.
# [23:59] <AryehGregor> Your company sounds fun to work for.
# [23:59] <TabAtkins> That was an internal tool, so I could fuck around.
# [23:59] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
# [23:59] <AryehGregor> But you shouldn't rely on setTimeout(func,0) taking a nonzero amount of time. That's not forward-compatible.
# Session Close: Fri Jul 16 00:00:00 2010

The end :)