| 00:18 | <TabAtkins> | AryehGregor: I have now violently disagreed with you publicly. |
| 00:18 | <TabAtkins> | After consulting with Chrome team. ^_^ |
| 00:20 | <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. |
| 00:37 | <AryehGregor> | TabAtkins, rest assured you will see a violent response in return, likely tomorrow. |
| 00:38 | <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. |
| 00:39 | <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? |
| 00:39 | <TabAtkins> | Slowly, that's how. And no, they're not. |
| 00:39 | <AryehGregor> | Why not? |
| 00:40 | <TabAtkins> | Why aren't SVG shadows applied as often as CSS shadows? I dunno. |
| 00:40 | <AryehGregor> | In Firefox you can even apply SVG filters to HTML content. |
| 00:40 | <TabAtkins> | Yes? |
| 00:40 | <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. |
| 00:41 | <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). |
| 00:41 | <TabAtkins> | I'm fine with providing an informative reference. |
| 00:42 | <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. |
| 00:42 | <TabAtkins> | Perhaps. |
| 00:42 | <AryehGregor> | I assume there's no problem at all with canvas, since you only need to compute the shadow once. |
| 00:42 | <AryehGregor> | (which is why it's ironic that we have so much less interop there than with SVG . . .) |
| 00:43 | <TabAtkins> | Yeah, most likely the slowness is unimportant in <canvas>. |
| 00:43 | <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. |
| 00:43 | <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. |
| 00:43 | <TabAtkins> | I expect that's precisely the reason. |
| 00:44 | <TabAtkins> | SVG has many things that are bad perf-hits. |
| 00:44 | <AryehGregor> | You're saying authors rolling their own shadow in JavaScript would be cheaper than Gaussian blur? I find that unlikely. |
| 00:44 | <TabAtkins> | AryehGregor: With a sufficiently large shadow? Could be. |
| 00:44 | <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. |
| 00:44 | <AryehGregor> | Whereas if it's an SVG, this is less likely? I dunno. |
| 00:45 | <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. |
| 00:45 | AryehGregor | will seek clarification on the list. |
| 00:45 | <AryehGregor> | (tomorrow) |
| 00:46 | <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. ^_^ |
| 00:47 | <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? |
| 00:47 | <TabAtkins> | Probably not. |
| 00:47 | <AryehGregor> | Authors are looking for a specific visual style, surely, not physical accuracy. |
| 00:47 | <AryehGregor> | So it doesn't matter so much what it looks like, as long as it's interoperable. |
| 00:47 | <TabAtkins> | But then, a normal person can't tell the difference between a CG shadow and Skia shadow for normal font-sizes and blurs. |
| 00:48 | <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. |
| 00:48 | <AryehGregor> | They're similar, though. |
| 00:48 | <AryehGregor> | (Firefox is much more different, IIRC) |
| 00:48 | <TabAtkins> | What size, and is it a difference of actual blur radius producing different-sized shadows? |
| 00:49 | <AryehGregor> | Just the example I gave before. |
| 00:49 | <TabAtkins> | Okay, so that's a width of somewhere between 10px and 15px. |
| 00:49 | <TabAtkins> | When I say "normal font-sizes and blurs" I mean smaller than that. |
| 00:50 | <TabAtkins> | shadows on heading text, frex, are usually less than 8px. |
| 00:50 | <TabAtkins> | Often just 2px or 4px, I think. |
| 00:50 | <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> |
| 00:52 | <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. |
| 00:52 | <AryehGregor> | Anyway, I'm off for the night. |
| 00:53 | <TabAtkins> | That's precisely my point. ^_^ Specifying that we *must* use a gaussian, though, prevents that. |
| 01:14 | <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 |
| 01:16 | <Philip`> | What kind of shadow implementation would be faster than a Gaussian? |
| 01:16 | <TabAtkins> | Lots. |
| 01:17 | <Philip`> | The only thing I can imagine is if you have a sharper falloff so you can use a smaller filter |
| 01:17 | <TabAtkins> | Frex, a downscale+upscale to fuzz details. |
| 01:17 | <TabAtkins> | Or the "just average all the pixels" that I think Skia does. |
| 01:31 | <Hixie> | um |
| 01:31 | <Hixie> | i can't log into the wiki |
| 01:31 | <Hixie> | wtf |
| 01:32 | <Hixie> | AryehGregor!!!! help!!! :-) |
| 01:33 | <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" |
| 01:34 | <Hixie> | oh, i know why |
| 01:34 | <Hixie> | the /tmp directory is full |
| 01:35 | <Hixie> | variable: you around? |
| 01:35 | <variable> | Hixie, yeah? |
| 01:35 | <variable> | let me clear /tmp |
| 01:35 | <Hixie> | thanks |
| 01:35 | <Hixie> | :-) |
| 01:35 | <variable> | Hixie, I just got back from dinner ;) |
| 01:36 | <Hixie> | looks like it's making huge temp files in /tmp and preventing other things on my account from working (like the whatwg wiki) |
| 01:36 | <Hixie> | is there some way to move it to using ~/tmp instead? |
| 01:36 | <Hixie> | that would be ideal |
| 01:36 | <Hixie> | the quota there is far bigger |
| 01:36 | <variable> | Hixie, yeah - I'm looking now |
| 01:37 | <variable> | find: cannot delete ./sess_l4orkhk5sgiish85nqv7dpck27: Operation not permitted |
| 01:37 | <Hixie> | yeah don't worry about the ones you don't own |
| 01:37 | <Hixie> | woohoo, that worked |
| 01:37 | <Hixie> | ok, wiki login is fixed |
| 01:38 | <TabAtkins> | Oh wow, got a totally sweet embossing effect. |
| 01:38 | TabAtkins | was trying to make the spec's edge-detection example for <canvas> work at a usable speed for live video. |
| 01:38 | <variable> | sorry about leaving it like that - I didn't realise other stuff was broken |
| 01:38 | <Hixie> | variable: no worries, nor did i :-) |
| 01:38 | <variable> | I'm going to back to work on it. |
| 01:38 | <variable> | I'll monitor the wiki while I'm trying to move to ~/tmp |
| 01:39 | <Hixie> | so long as df doesn't say /tmp is at 100% you should be fine |
| 01:40 | <variable> | heh - ok |
| 01:40 | <variable> | I'm thinking this might be *svns* tmp dir and not WebSVN |
| 01:41 | <Hixie> | the files were owned by your user so that's unlikely |
| 01:41 | <Hixie> | it could be the svn client run by websvn |
| 01:41 | <variable> | exactly: websvn runs the svn command using system() IIRC |
| 01:41 | <Hixie> | ah yeah |
| 01:41 | <Hixie> | could totally be that |
| 01:42 | <Hixie> | try changing the TMP variable maybe? |
| 01:42 | <Hixie> | environment variable, i mean |
| 01:42 | <variable> | Hixie, erm - that variable has to be set in the PHP file. |
| 01:42 | <Hixie> | hmm |
| 01:43 | <variable> | if I set TMP in the env. the PHP file won't see it. |
| 01:44 | <Hixie> | yeah |
| 01:44 | <Hixie> | i have no idea how to change this |
| 01:44 | <variable> | Hixie, I'm looking now |
| 01:45 | <variable> | /tmp might fill up a few times while I test to see if it worked but I'll fix it |
| 01:46 | <Hixie> | no worries |
| 02:13 | <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 |
| 02:13 | <titacgs> | is there a work around for this? |
| 02:17 | <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. |
| 02:17 | <TabAtkins> | (By "arent' meant for" I mean "can't be used for".) |
| 02:20 | <titacgs> | mmmmmm |
| 02:20 | <titacgs> | I see |
| 02:24 | <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 |
| 02:32 | <Hixie> | www.un.org is down. |
| 02:33 | <Hixie> | well, not so much down, as it appears someone deleted all of it. |
| 02:34 | <variable> | WebSVN has absolutely 0 documentation other than the comments in the source code. Great! |
| 02:34 | <Hixie> | nice |
| 06:00 | <boblet> | sanity check: Opera doesn’t support linear gradients yet? |
| 06:13 | <roc> | you mean CSS gradients? |
| 06:43 | <boblet> | roc: yep |
| 06:43 | <boblet> | doh! |
| 06:56 | <Hixie> | TabAtkins_: yt? |
| 07:11 | <Hixie> | so anyone want to write the CP for ISSUE-109? |
| 07:11 | <Hixie> | that is, a counter-CP to http://www.w3.org/html/wg/wiki/ChangeProposals/ariasection |
| 07:15 | <abarth> | that proposal is so trivial |
| 07:15 | <abarth> | i'm not even sure how to respond to it |
| 07:29 | <Hixie> | abarth: i wrote one |
| 07:30 | <annevk> | boblet, I don't think so |
| 07:30 | <boblet> | annevk: thanks (will cry a little now) |
| 07:31 | <Hixie> | how about issues 74 and 105, the canvas accessibility ones |
| 07:31 | <Hixie> | anyone want to make a case for the existing text? |
| 07:33 | <Hixie> | or 32, the summary="" one |
| 07:35 | <Hixie> | gotta love http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility |
| 07:36 | <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()" |
| 07:38 | <annevk> | I think I've been Change Proposal tired since before we started with them |
| 07:38 | <Hixie> | my god this proposal is messed up |
| 07:39 | <Hixie> | it has authoring conformance criteria literally in the middle of a UA algorithm |
| 07:39 | <Hixie> | it uses the wrong coordinate system |
| 07:39 | <Hixie> | it's self-contradictory in fact about the coordinate system it uses |
| 07:40 | <Hixie> | it has an entirely useless set of arguments for the focus ring |
| 07:40 | <Hixie> | sigh |
| 07:40 | <annevk> | so anything goes as a Change Proposal? |
| 07:40 | <annevk> | maybe we should like MikeSmith's text generator come up with something good |
| 07:41 | <annevk> | s/like/let/ |
| 07:41 | <MikeSmith> | my text generator has taken on a life of its own |
| 07:41 | <MikeSmith> | somebody told me it opened up a twitter account for itself |
| 07:42 | <Hixie> | seriously, read this: |
| 07:42 | <Hixie> | http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/att-0054/2dcontext10-June-7.html#dom-context-2d-setCaretSelectionRect |
| 07:43 | <Hixie> | the definition of setCaretSelectionRect |
| 07:43 | <Hixie> | read that algorithm |
| 07:43 | <Hixie> | it has authoring criteria, it has asynchronous requirements, and then it ends with "return true" |
| 07:44 | <Hixie> | and that's ignoring the main problem of course, which is that the entire method is completely useless |
| 07:44 | <Hixie> | it does nothing if you don't have an AT, so nobody will ever use it |
| 07:44 | <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? |
| 07:46 | <annevk> | oh lol |
| 07:46 | <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 |
| 07:46 | <annevk> | W3C should give a spec writing 101 |
| 07:47 | <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 |
| 07:47 | <Hixie> | this is ridiculous |
| 08:35 | <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 |
| 08:37 | <Hixie> | can you just write a CCP instead? :-) |
| 08:37 | <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 |
| 08:37 | <Hixie> | well then how is it different to the API we have in the spec today? |
| 08:37 | <Hixie> | and why does it talk about the selection rect? |
| 08:38 | <jgraham> | Unless I am misremembering (which is possible), it is supposed to cover the one character covered by the caret |
| 08:38 | <jgraham> | But I didn't understand either so I am the wrong person to ask |
| 08:38 | <Hixie> | carets don't usually cover characters...? |
| 08:39 | <Hixie> | i wish that the change proposal process had a more defined problem description stage |
| 08:39 | <Hixie> | as distinct from the solution proposal stage |
| 08:39 | <Hixie> | currently we just run around like headless chickens spouting random proposals without ever considering what problem we're solving |
| 08:39 | <jgraham> | I can't write a CCP because I don't know what a good solution is |
| 08:39 | <Hixie> | it's just amateurish |
| 08:39 | <jgraham> | I just know that CP isn't one |
| 08:39 | <Hixie> | jgraham: the solution in the spec :-) |
| 08:41 | <othermaciej> | regarding caret/selection position... |
| 08:41 | <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 |
| 08:42 | <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 |
| 08:42 | <jgraham> | I think the existing CP should be rejected on the basis that it is not a) workable or b) camera ready spec text |
| 08:42 | <Hixie> | othermaciej: that's already handled by the child DOM |
| 08:42 | <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 |
| 08:42 | <Hixie> | and that's already handled by the current API |
| 08:42 | <jgraham> | I got the impression that 2) was the interesting case here |
| 08:43 | <othermaciej> | focus area is a rough approximation |
| 08:43 | <othermaciej> | but may not be specific enough |
| 08:43 | <Hixie> | the current API has a focus ring and a specific point for centering on |
| 08:43 | <jgraham> | But I don't know why you need a width to do that |
| 08:43 | <othermaciej> | so you should redraw the focus ring every time the caret moves? |
| 08:44 | <Hixie> | yes |
| 08:44 | <othermaciej> | if I wrote code like that in WebKit I would be fired |
| 08:44 | <othermaciej> | but maybe the standards are lower for Web developers |
| 08:44 | <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 |
| 08:44 | <Hixie> | but apparently that's what we're trying to solve |
| 08:44 | <Hixie> | so |
| 08:45 | <othermaciej> | well, I advocated not supporting text drawing on the canvas at all, but apparently there are use cases for it |
| 08:45 | <annevk> | they're trying to make bespin work |
| 08:45 | <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 |
| 08:45 | <Hixie> | which means most people won't call it, and most that will will call it in a buggy fashion |
| 08:45 | <Hixie> | and we'll be no better off and possible worse off than if we had nothing |
| 08:46 | <annevk> | might be more fruitful for a11y to work on DOM Range + CSS styling so bespin can move into a <textarea> |
| 08:46 | <Hixie> | at least with the focus ring API there's a use case, it gets you free native focus ring drawing |
| 08:46 | <jgraham> | It does seem odd to move the focus ring for every caret move though |
| 08:46 | <Hixie> | i agree that it's suboptimal |
| 08:46 | <othermaciej> | I don't think the bespin guys are remotely interested in moving off canvas, even if you made a good enough alternative |
| 08:46 | <othermaciej> | Bespin doesn't even have a focus ring |
| 08:47 | <othermaciej> | you would have to draw one offscreen to use this API |
| 08:48 | <othermaciej> | heck, even in native Mac apps it's not uncommon that some text areas don't get focus rings |
| 08:48 | <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 |
| 08:48 | <jgraham> | Although I am not really an optimist |
| 08:49 | <othermaciej> | if it made sense to have an API to draw a caret, that would combine with a useful operation |
| 08:49 | <Hixie> | oh we could do that |
| 08:49 | <othermaciej> | but typically a caret would blink, and you can't handle that part for the developer |
| 08:49 | <Hixie> | have it automatically determine the baseline positioning and so on |
| 08:50 | <Hixie> | so you just give it the text x,y and the width of the text so far or something |
| 08:50 | <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) |
| 08:50 | <jgraham> | You could even support the blink rate stuff that they want :) |
| 08:50 | <Hixie> | yeah |
| 08:51 | <Hixie> | ignore the call if it's during an off period |
| 08:51 | <Hixie> | i don't understand why we're discussing this in the change proposal system and not in the bug system |
| 08:51 | <Hixie> | did i reject a change to the focus ring API at some point? |
| 08:51 | <othermaciej> | I don't remember how canvas accessibility made it into the issue system |
| 08:51 | <othermaciej> | I believe it was before the current decision policy |
| 08:52 | <jgraham> | Yes, I think it was in the "someone says this is a problem" phase |
| 08:52 | <jgraham> | Where everything got put in Tracker |
| 08:52 | <othermaciej> | if you come up with a better caret API, I bet you could convince the accessibility folks to withdraw that proposal by consensus |
| 08:53 | <Hixie> | well i'd be happy to do so, but i can't do it on the timetable that this issue is on |
| 08:53 | <Hixie> | i have like 200 bugs and 1000 e-mails ahead of it in the queue |
| 08:54 | <othermaciej> | maybe if you sketch it out you could convince them to wait to see it (not as sure on that though) |
| 08:54 | <othermaciej> | agree that bugs/emails should be higher priority |
| 08:55 | <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 |
| 08:55 | <othermaciej> | not sure which side of the leger that ends up on |
| 08:56 | <Hixie> | i'd love to see any examples of them being used realistically that showed such cases |
| 09:00 | <othermaciej> | I will agree the respective proposed spec text for both is not the best quality drafting |
| 09:01 | <Hixie> | you are a master of the understatement |
| 09:15 | <annevk> | hmm |
| 09:15 | <annevk> | bit.ly even ate my fragment identifier |
| 09:15 | <annevk> | wtf twitter |
| 09:16 | <annevk> | hmm, only when using the expanding feature |
| 09:22 | <hsivonen> | Is there still no feedback from the Bespin team? |
| 09:27 | <gsnedders> | http://talk.maemo.org/showthread.php?p=752460 |
| 09:27 | <gsnedders> | Opera Mobile for Maemo now with JIT on ARM |
| 09:32 | <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 :) |
| 09:48 | <MikeSmith> | is bespin still even being actively maintained? |
| 09:56 | <jgraham> | MikeSmith: Yes |
| 09:56 | <jgraham> | They seem to rewrite parts of it every so often |
| 09:57 | <jgraham> | I think they just rewrote the server in node.js |
| 09:57 | <MikeSmith> | jgraham: cool |
| 09:57 | <MikeSmith> | dinnet know that |
| 09:57 | <jgraham> | hsivonen: It was claimed that they had been contacted directly and didn't respond |
| 09:59 | <jgraham> | MikeSmith: http://groups.google.com/group/bespin/browse_thread/thread/6de8c718d64232a0 |
| 10:40 | <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? ... |
| 10:41 | <jgraham> | I kind of figure that if you lockl yourself away in a taskforce it is not that surprising when you get fewer comments |
| 10:50 | <AryehGregor> | Yeah, it seems like if you want broader comments earlier, you should use the main discussion fora and not create your own . . . |
| 11:21 | <AryehGregor> | gfxFloat sigma = CurrentState().shadowBlur > 8 ? sqrt(CurrentState().shadowBlur) : CurrentState().shadowBlur / 2; |
| 11:21 | <AryehGregor> | http://hg.mozilla.org/mozilla-central/file/5fda39cd703c/content/canvas/src/nsCanvasRenderingContext2D.cpp#l1855 |
| 11:21 | <AryehGregor> | Maybe that's why Firefox renders canvas shadows wrong? |
| 11:21 | <AryehGregor> | You know, sqrt(CurrentState().shadowBlur) instead of sqrt(2*CurrentState().shadowBlur)? |
| 11:22 | <AryehGregor> | Or am I reading the spec wrong? |
| 11:24 | AryehGregor | doesn't think so, since the Mozilla behavior makes shadowBlur = 8 the same as shadowBlur = 16 |
| 11:25 | AryehGregor | tests that |
| 11:25 | <Philip`> | It should be 2* |
| 11:25 | <AryehGregor> | Conveniently, I've already basically written a reftest for this using SVG. :) |
| 11:25 | <AryehGregor> | Yep, indeed, 8 and 16 look identical. |
| 11:26 | <AryehGregor> | What a silly bug. This is exactly the sort of thing we need an official test suite for. |
| 11:26 | <Philip`> | Then 9 is less blurry than 8 |
| 11:26 | <AryehGregor> | Yep! |
| 11:26 | <AryehGregor> | Noticeably so. |
| 11:26 | <Philip`> | which is a bigger discontinuity than the second-order one the bug was complaining about :-) |
| 11:26 | AryehGregor | works on a patch |
| 11:26 | <roc> | if you could stick that in a patch, I'll review it for you :-) |
| 11:27 | <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 |
| 11:27 | AryehGregor | has to remind himself how to actually compile Mozilla and such, should post a bug today and will CC roc |
| 11:27 | <Philip`> | We just need people to run the tests and check for differences and file bugs and fix them |
| 11:27 | <AryehGregor> | Guess so. :) |
| 11:27 | <Philip`> | (and to fix bugs in the tests, and to write more tests, etc) |
| 11:30 | <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. |
| 11:30 | <AryehGregor> | (which is saying a lot, when Firefox makes all blurs above 8 41% bigger) |
| 11:30 | <MikeSmith> | jgraham: thanks for link about Bespin roadmap |
| 11:31 | <Philip`> | (You probably mean smaller) |
| 11:31 | <AryehGregor> | Er, yes, probably. |
| 11:31 | AryehGregor | stares at code compiling. |
| 11:32 | 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. |
| 11:33 | <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 |
| 11:53 | AryehGregor | wonders if anyone does reviews on what CPUs are best for compiling. |
| 11:55 | <AryehGregor> | Philip`, do you know if there's any reason anyone would want blurRadius/2 instead of sqrt(2*blurRadius) at 8 and below? |
| 12:02 | <Philip`> | AryehGregor: No, unless it happens to give you a nicer range of blurs for small integers or something like that |
| 12:02 | <AryehGregor> | Would it make any sense as an optimization? |
| 12:02 | <AryehGregor> | I think I recall someone from Safari saying they considered it as a bug . . . |
| 12:02 | <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) |
| 12:03 | <othermaciej> | we just do what CG does |
| 12:03 | <Philip`> | (By "they" I meant the CG people :-) ) |
| 12:04 | <othermaciej> | supposedly the threshold below 8 pixels gives a smoother progression for different radius sizes |
| 12:04 | <othermaciej> | at least that is what I have heard |
| 12:04 | <AryehGregor> | So CG's blur function accepts this weird blurRadius instead of just accepting sigma directly? |
| 12:04 | <AryehGregor> | Do you think it would make sense to change it at this point, since we don't have interop on canvas shadows anyway? |
| 12:05 | <othermaciej> | well, we could always munge the blur radius to do what CG would do (assuming it takes a float; not sure) |
| 12:05 | <othermaciej> | I do not know what actually results in good looking shadows |
| 12:05 | <Philip`> | http://developer.apple.com/mac/library/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextSetShadow |
| 12:06 | <Philip`> | "A non-negative number specifying the amount of blur." |
| 12:06 | <AryehGregor> | Do you think it's worth pursuing, or should we just leave it alone? |
| 12:06 | <AryehGregor> | CGFloat blur |
| 12:06 | <Philip`> | I don't think I've ever seen anything saying the scale of the number |
| 12:08 | <AryehGregor> | I guess it's easiest at this point to just leave it alone. |
| 12:08 | <AryehGregor> | It won't be anywhere near the biggest wart in the web platform. |
| 12:08 | <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) |
| 12:09 | <AryehGregor> | Yeah, makes sense. |
| 12:10 | <jgraham> | If anyone asks we will blame Apple |
| 12:10 | <Philip`> | (Users aren't any more likely to understand sigmas anyway) |
| 12:11 | <jgraham> | Then they will either direct their righteous anger there or assume the design was perfect and it was them who was wrong |
| 12:11 | <jgraham> | Depending on their relationship with Apple |
| 12:11 | <jgraham> | and the current state of the RDF |
| 12:13 | <AryehGregor> | Hmm, my change didn't seem to fix Firefox. |
| 12:13 | <AryehGregor> | Have to go now, I guess I'll look later today. |
| 12:13 | <roc> | did you rebuild everything? |
| 12:13 | <AryehGregor> | I was using a fresh mozilla-central checkout. |
| 12:14 | <Philip`> | Obvious question: Are you running the version you compiled, not a window of another version of Firefox that was already running? |
| 12:14 | <AryehGregor> | Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre |
| 12:14 | <jgraham> | annevk: Can you change the favicon for the webapps tracker, please |
| 12:15 | <jgraham> | It is highly confusing that it has the same icon as the tabs with the spec open |
| 12:17 | <AryehGregor> | It does seem to look a bit closer, maybe. |
| 12:17 | <AryehGregor> | Okay, got to go now . . . |
| 12:17 | <jgraham> | annevk: (the same icon with the colours inverted or something simple would be fine) |
| 12:19 | <MikeSmith> | about meta/@name=viewport |
| 12:19 | <MikeSmith> | which already seems to have become a de facto standard |
| 12:19 | <MikeSmith> | are there any other meta/@name values that have rendering effects in browsers? |
| 12:20 | <MikeSmith> | and who is it at Apple who came up that thing to begin with? |
| 12:20 | <MikeSmith> | and whoever it was, why didn't they find it worthwhile to ask for feedback on it before unleashing it on the world? |
| 12:20 | <hsivonen> | MikeSmith: to the person's credit at Apple, they at least used meta/@name and not meta/@http-equiv |
| 12:21 | <hsivonen> | MikeSmith: it was created in the stealth mode before the iPhone was announced |
| 12:21 | <MikeSmith> | I see |
| 12:22 | <MikeSmith> | hsivonen: yeah, glad it's not http-equiv at least |
| 12:28 | <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? |
| 12:47 | <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 |
| 12:48 | <Matjas> | Peter`: Okay, thanks. |
| 12:49 | <annevk> | jgraham, if you make one |
| 12:49 | <annevk> | jgraham, can you make a pink one? |
| 12:50 | <jgraham> | annevk: Probably. Where is the original? |
| 12:51 | <annevk> | http://simon.html5.org/sandbox/svg/whatwg |
| 12:52 | <annevk> | maybe I can do this myself... but I rather just wget and remove the favicon line |
| 13:12 | <annevk> | so I tried fiddling with that icon and everything fall apart |
| 13:17 | <jgraham> | Oh |
| 13:18 | <jgraham> | I made you a new one http://hoppipolla.co.uk/410/favicon.ico |
| 13:18 | <jgraham> | If you can work out how to use it without everything dying |
| 13:19 | <annevk> | that's more like purple, no? |
| 13:19 | <jgraham> | Picky |
| 13:20 | <jgraham> | I used one of those web colour scheme generator things to find some pinkish colour that would vaugely work with the dark green |
| 13:20 | <jgraham> | Since they will typically be next to each other |
| 13:25 | <annevk> | hotpink it is |
| 13:28 | <jgraham> | That is hideous |
| 13:28 | <annevk> | you asked for it |
| 13:29 | <annevk> | complaining about a favicon, come on ;p |
| 13:29 | <jgraham> | Also, it only seems to be working in Opera |
| 13:29 | <annevk> | that sounds like a cache issue |
| 13:29 | <jgraham> | Maybe. It is just showing the default in the others though |
| 13:30 | <annevk> | wfm in Chrome |
| 13:30 | <annevk> | doesn't work in Firefox |
| 13:30 | <annevk> | but Firefox does work on my site |
| 13:30 | <annevk> | hmm |
| 13:30 | <annevk> | maybe still a cache issue |
| 13:30 | <zcorpan_> | wfm in firefox |
| 13:31 | <annevk> | weird, doesn't in mine |
| 13:31 | <annevk> | even after explicitly loading /favicon.ico |
| 13:31 | <annevk> | but someone else can fix that |
| 13:32 | <jgraham> | Works in Chromium after clearing the cache |
| 13:32 | <jgraham> | But I kinda wish it didn't :( |
| 13:32 | <annevk> | I used http://www.whatwg.org/images/logo.svg eventually |
| 13:32 | <annevk> | jgraham, hehe |
| 13:32 | <jgraham> | Also, what happened to the chromium menu. It's insane |
| 13:33 | <annevk> | the one from Simon is far more clever but SVG rendering tools are just too crappy to support that |
| 13:33 | <annevk> | they need explicit paths and such |
| 13:33 | <jgraham> | annevk: I used Simon's one and then edited around some of the problems inkscape had |
| 13:34 | <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 |
| 13:34 | <jgraham> | So that the submenu will always open on the left |
| 13:34 | <jgraham> | It must be a bug |
| 13:35 | <jgraham> | Or unfinished change at least |
| 13:35 | <annevk> | at least they do not have 4 menu depth |
| 13:35 | <annevk> | like selecting an encoding in Opera requires |
| 13:35 | <annevk> | selecting an encoding is something that should not be in the UI anyway |
| 13:35 | <annevk> | no user gets such bullshit |
| 13:35 | <jgraham> | Yeah, but at least our menus don't have arrows to the right and open to the left |
| 13:36 | <annevk> | agreed that is weird |
| 13:36 | <annevk> | maybe they optimized for RTL? |
| 13:36 | <annevk> | :) |
| 13:36 | <Philip`> | Opera's menus often open off my screen so I can't see them at all :-( |
| 13:37 | <Philip`> | though maybe that's my fault for having a non-rectangular multi-monitor desktop |
| 13:37 | <jgraham> | Philip`: File a bug? |
| 13:38 | Philip` | is too lazy and doesn't know if it's even fixable on Linux |
| 13:40 | <annevk> | i like this new icon |
| 13:40 | <annevk> | should make one for http://webforms2.org/ too |
| 14:14 | <AryehGregor> | That is quite hideous. |
| 14:23 | <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. |
| 14:24 | <AryehGregor> | The problem with me trying to write a patch here is I have no idea what any of this stuff does. |
| 14:25 | <AryehGregor> | Is this doing a real Gaussian blur at all? |
| 14:26 | <AryehGregor> | It looks like it's not. |
| 14:26 | <AryehGregor> | Hmm, there's an approximation specified in the SVG spec itself. |
| 14:27 | <AryehGregor> | http://en.wikipedia.org/wiki/Box_blur |
| 14:32 | <Philip`> | AryehGregor: I have no idea what gfxAlphaBoxBlur does |
| 14:32 | <Philip`> | It sounds like it ought to be a sufficiently close approximation of a Gaussian blur that you shouldn't see much difference |
| 14:33 | <Philip`> | (as long as you don't exceed SIGMA_MAX) |
| 14:34 | <Philip`> | (which is at shadowBlur=312.5) |
| 14:44 | <AryehGregor> | It looks like it does three box blurs, which is supposed to be within 3% of a true Gaussian blur. |
| 14:44 | <AryehGregor> | But canvas is the only caller of that. |
| 14:44 | <AryehGregor> | So maybe it's just buggy. |
| 14:45 | <Philip`> | That seems quite possible |
| 14:45 | <Philip`> | given that the output is not what you expect |
| 14:49 | AryehGregor | is looking at the code for feGaussianBlur now, since that works right |
| 14:49 | <AryehGregor> | Yay, approximating integer division by multiplication and bitshifts. |
| 14:49 | <AryehGregor> | * If all that math confuses you, this should convince you: |
| 14:49 | <AryehGregor> | * > perl -e 'for($N=1;(255*$N*int(0xFFFFFFFF/(255*$N)))>>24==255;++$N){}print"$N\n"' |
| 14:49 | <AryehGregor> | * 66052 |
| 14:52 | <jgraham> | That looks a lot like line noise |
| 14:52 | <AryehGregor> | Yes, sometimes it's hard to tell the difference between Perl and line noise. |
| 14:53 | <jgraham> | Also, why does it do anything? Where is $N mutated? |
| 14:53 | <AryehGregor> | ++$N |
| 14:53 | <jgraham> | Oh wait |
| 14:53 | <jgraham> | I was being dumb |
| 14:53 | <Philip`> | Remove the '$'s and it's basically C |
| 14:53 | <Philip`> | It's not doing anything Perlish |
| 14:54 | <AryehGregor> | Cramming an entire program on one line with no spaces except where required by syntax strikes me as very Perlish. |
| 14:54 | <Philip`> | (What source file is this in?) |
| 14:54 | <jgraham> | I think the maths would be easier to follow... |
| 14:54 | <AryehGregor> | content/svg/content/src/nsSVGFilters.cpp |
| 14:54 | <jgraham> | (what is the program trying to show?) |
| 14:55 | <workmad3> | AryehGregor: only thing that's doing that isn't C is that C would need a main() function to work |
| 14:55 | <workmad3> | (oh, and would probably use printf rather than print) |
| 14:55 | <AryehGregor> | workmad3, and printf("%d\n", N) instead of print "$N\n". |
| 14:55 | <AryehGregor> | Yar. |
| 14:55 | <workmad3> | it isn't a very perlish version of getting it all onto one line though :) |
| 14:56 | <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. |
| 14:56 | <AryehGregor> | Except with some more parentheses. |
| 14:57 | <AryehGregor> | I don't know what the 255's are doing there, isn't ($N*int(0xFFFFFFFF/(255*$N)))>>25 == 1 equivalent? |
| 14:58 | <AryehGregor> | Oh, hmm, no. |
| 14:58 | <AryehGregor> | Because the 255* is before the bitshift. |
| 14:58 | <AryehGregor> | Also, it's 24 and not 25. |
| 14:58 | 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. |
| 15:01 | <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. |
| 15:02 | <AryehGregor> | (there seems to be considerable code duplication here, incidentally) |
| 15:02 | <Philip`> | static const gfxFloat GAUSSIAN_SCALE_FACTOR = (3 * sqrt(2 * M_PI) / 4) * (3/2); |
| 15:02 | <Philip`> | Surely that's not going to work |
| 15:02 | <Philip`> | because (3/2) == 1 |
| 15:02 | <AryehGregor> | Hmmm. |
| 15:03 | <Philip`> | The rest will get promoted to doubles but that won't |
| 15:03 | <AryehGregor> | In nsSVGFilters.cpp, it says: double size = aStdDev*3*sqrt(2*M_PI)/4; |
| 15:03 | <AryehGregor> | Then: return PRUint32(floor(size + 0.5)); |
| 15:04 | <AryehGregor> | Well, that part is irrelevant, I guess. |
| 15:04 | <AryehGregor> | The SVG spec says: let d = floor(s * 3*sqrt(2*pi)/4 + 0.5) |
| 15:04 | <AryehGregor> | So maybe (3/2) == 1 is actually intentional somehow. :P |
| 15:05 | <AryehGregor> | I could try changing that and recompiling, may as well give it a shot. |
| 15:05 | <AryehGregor> | Hmm, what does this mean: // Blur radius is approximately 3/2 times the box-blur size |
| 15:05 | <Philip`> | InflateRectForBlurDXY does the 3/2 for SVG box blurs (vs Gaussian blurs), I think |
| 15:05 | <AryehGregor> | Quite possible. |
| 15:05 | <AryehGregor> | Well, let me see. |
| 15:06 | <AryehGregor> | Isn't it nice how one can spot bugs without actually having any idea what the code does? |
| 15:07 | <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 |
| 15:08 | AryehGregor | wonders how the convention of "compilers should spam your terminal with spectacular quantities of incomprehensible garbage" developed |
| 15:08 | <Philip`> | That's probably the Makefile, not the compiler |
| 15:08 | <AryehGregor> | Then replace "compilers" with "the compilation process" if you like. |
| 15:08 | <Philip`> | except in the case of compiler errors in STL code, which is totally the compiler's fault for not caring about users |
| 15:09 | <AryehGregor> | Okay, this is much better. |
| 15:09 | <Workshiva> | Makefiles aren't a process as much as a somewhat deterministic trainwreck |
| 15:09 | <AryehGregor> | Now the HTML is somewhat more blurry than the SVG. |
| 15:09 | <AryehGregor> | Unlike Opera, where they're identical. |
| 15:10 | <AryehGregor> | (open http://aryeh.name/tmp/test.svg and http://aryeh.name/tmp/test.html, tab between them, should see no noticeable change) |
| 15:11 | <Philip`> | Is there some way to toggle the SVG between Gaussian and box blurs? |
| 15:11 | <Philip`> | Oh, sorry, it always does box blurs |
| 15:12 | <AryehGregor> | Yeah, apparently no one does actual Gaussian blurs, too expensive when box blurs look the same. |
| 15:15 | Philip` | notes that http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/index.2d.shadow.blur.html uses a true Gaussian for comparison |
| 15:15 | <jgraham> | What margin of error> |
| 15:15 | <jgraham> | ? |
| 15:16 | <Philip`> | and in Opera they look very similar |
| 15:16 | <AryehGregor> | Various sources say doing three box blurs in the right way gets you within 3% of a true Gaussian blur. |
| 15:16 | <AryehGregor> | Without all the exponentiation and things. |
| 15:16 | <Philip`> | (except blur.low has some faintly visible banding in Opera's canvas) |
| 15:16 | <AryehGregor> | Your tests look about the same actual vs. expected in my patched Firefox. |
| 15:17 | <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. |
| 15:17 | <Philip`> | Right click -> open image in tab |
| 15:17 | <AryehGregor> | And for the canvas? |
| 15:18 | <AryehGregor> | Oh, that has "View Image" too. |
| 15:18 | <AryehGregor> | At least in Firefox. |
| 15:18 | <Philip`> | Yeah |
| 15:18 | <Philip`> | It's quite handy :-) |
| 15:18 | <AryehGregor> | Okay, they're definitely different in patched Firefox, but much less so. |
| 15:19 | <Philip`> | Is the difference smaller than the difference between canvas and SVG? |
| 15:19 | <Philip`> | Or, equivalently, do Firefox and Opera agree on the SVG blur? |
| 15:19 | <AryehGregor> | Everything agrees on the SVG blur as far as I can tell in a side-by-side comparison. |
| 15:19 | <AryehGregor> | I haven't tried superimposing them. |
| 15:19 | AryehGregor | tries that |
| 15:21 | Philip` | is getting confused as to what's identical and what's a little different and what's a lot different |
| 15:22 | <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. |
| 15:22 | <Philip`> | Okay |
| 15:22 | <AryehGregor> | I notice a distinct difference between my SVG and HTML in Chrome and (patched) Firefox when superimposed. |
| 15:22 | <AryehGregor> | And also in your test case. |
| 15:24 | <AryehGregor> | Opera doesn't give me an image link for the canvas images. :( |
| 15:25 | <Philip`> | javascript:location=c.toDataURL(); |
| 15:25 | AryehGregor | sighs |
| 15:26 | <AryehGregor> | Yeah, they look basically identical superimposed in Opera. |
| 15:28 | <AryehGregor> | . . . c is the same as document.getElementById("c")? Really? How did I never know that? |
| 15:28 | <AryehGregor> | I guess it's not encouraged to use it for serious stuff in case something else shadows the element, though. |
| 15:28 | <AryehGregor> | Okay, I'll just post the patch, I guess. |
| 15:35 | <Philip`> | AryehGregor: I think the c shortcut doesn't work in e.g. standards mode in Firefox |
| 15:35 | <AryehGregor> | Interesting. |
| 15:35 | <Philip`> | so don't rely on it |
| 16:17 | <AryehGregor> | https://bugzilla.mozilla.org/show_bug.cgi?id=578995 |
| 16:20 | <AryehGregor> | Philip`, roc: ^^ |
| 16:22 | <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? |
| 16:23 | <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. |
| 16:24 | <TabAtkins> | Unless you're animating the shadow, of course. |
| 16:24 | <AryehGregor> | Heh, yeah. |
| 16:24 | <AryehGregor> | Then you're going to have to cheat. |
| 16:24 | <TabAtkins> | You can iterate it with some Newton's method, but still. |
| 16:24 | <TabAtkins> | I suspect that'd probably converge quickly. |
| 16:24 | <TabAtkins> | Since we can make a good guess already. |
| 16:25 | <Philip`> | Why would you want to force people to do something so complex? |
| 16:25 | <AryehGregor> | Yes, apparently you need to use Newton's method here. No x86 instruction for it or anything. |
| 16:25 | <AryehGregor> | Philip`, so they have some idea of what it does instead of passing in arbitrary numbers. |
| 16:25 | <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. |
| 16:26 | <AryehGregor> | Or maybe harder. |
| 16:27 | <Philip`> | It seems like in practice "something else" is an approximation of a Gaussian, so you still calculate the same sigma |
| 16:27 | <TabAtkins> | Maybe. Anyway, getting an approximation within the range I want to specify is good enough. |
| 16:28 | 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 |
| 16:29 | <TabAtkins> | Probably just noise. It's a clear and simple spec violation in the first place. |
| 16:30 | <Philip`> | AryehGregor: You should probably add an r+ flag if you want the patch reviewed |
| 16:30 | <AryehGregor> | I assume you mean r?. |
| 16:30 | <Philip`> | Oh |
| 16:30 | <Philip`> | Yeah |
| 16:30 | <AryehGregor> | I think me adding r+ to my own patch would be considered objectionable. |
| 16:31 | <AryehGregor> | Also, it's obviously r-, because 1) it doesn't fully fix the problem, and 2) it has no tests. |
| 16:31 | <AryehGregor> | So it's not ready for review yet. |
| 16:31 | <Philip`> | Oh, okay then |
| 16:31 | <Philip`> | Surely it has at least as many tests as the original shadow implementation, though |
| 16:31 | <Philip`> | and presumably they were good enough then |
| 16:33 | <AryehGregor> | I see no tests for the original shadow implementation. That was in September 2008, maybe they weren't as picky about tests then? |
| 16:34 | <Workshiva> | That's when nobody implemented shadows at all, isn't it? |
| 16:34 | <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. |
| 16:34 | <AryehGregor> | I mean, had to have tests. |
| 16:34 | <Philip`> | It untodoed the tests in https://bug310682.bugzilla.mozilla.org/attachment.cgi?id=335212 |
| 16:35 | <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. |
| 16:35 | <AryehGregor> | Oh, I missed that. |
| 16:35 | <AryehGregor> | Yeah, it had test updates in a separate commit. |
| 16:35 | <Philip`> | Sometimes you are, e.g. if you forget to mention the bug number in an earlier commit :-) |
| 16:37 | <AryehGregor> | Hmm, that's lots of isPixel tests. I wonder how the original tests were devised? What reference was used? |
| 16:37 | <AryehGregor> | Because if they pass, they're probably wrong. :) |
| 16:37 | <AryehGregor> | (but maybe just incomplete) |
| 16:37 | <Philip`> | The original tests are the ones I wrote |
| 16:37 | <AryehGregor> | So why didn't they fail? |
| 16:37 | <Philip`> | I think I didn't have any testing the shape/size of the blur precisely, though |
| 16:38 | <Philip`> | since everyone will approximate it and round differently etc so it's hard to know what tolerances to allow |
| 16:38 | <Philip`> | so I just stuck with manual visual verification tests for that |
| 16:39 | <AryehGregor> | How do I run those tests to see if they still pass with my patch applied? |
| 16:39 | <Philip`> | http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/index.2d.shadow.html |
| 16:40 | <Philip`> | I think that's basically all of them, except for boring attribute getting/setting/etc |
| 16:40 | <Philip`> | (Don't remember if I've made many changes since the version imported into Mozilla) |
| 16:40 | <AryehGregor> | Oh, interesting. |
| 16:41 | <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 |
| 16:41 | <jgraham> | (if someone else fancies checking that before I file a bug it would be appreciated) |
| 16:41 | <AryehGregor> | Well, my change causes no extra failures on that page. |
| 16:42 | <AryehGregor> | A reftest between SVG and canvas would be cool, if that could be arranged. |
| 16:42 | <AryehGregor> | It would make sense for them to share code anyway, I would think, no? |
| 16:42 | <AryehGregor> | (but if not, probably they won't be pixel-perfect, oh well) |
| 16:49 | <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. |
| 16:49 | <Philip`> | AryehGregor: I've already got http://philip.html5.org/tests/canvas/suite/tests/results.html |
| 16:50 | <AryehGregor> | Is that updated automatically? |
| 16:50 | <Philip`> | No |
| 16:50 | <Philip`> | Well, partly |
| 16:50 | AryehGregor | realizes that IE9 is actually up to PP3, not PP2, oops |
| 16:51 | <Philip`> | http://philip.html5.org/tests/canvas/suite/reportgenentry.html lets you run the tests |
| 16:51 | <Philip`> | and if you're me and you're running it on localhost then you can save the results to a database |
| 16:51 | <Philip`> | and then regenerate the results table |
| 16:51 | <AryehGregor> | Nice. |
| 16:52 | <Philip`> | It'd be nice if the W3C Testing TF got a system running for more easily running tests and submitting results |
| 16:52 | AryehGregor | looks pointedly at TabAtkins. |
| 16:52 | <TabAtkins> | Yes, yes, I'm working on it. |
| 16:52 | <Philip`> | so I haven't bothered trying to upload my own test harness there |
| 16:53 | <Philip`> | TabAtkins: Work faster :-p |
| 16:53 | <TabAtkins> | I try, but then I get distracted by shiny objects and CSS emails. |
| 16:53 | <Philip`> | The fate of the web depends on you |
| 16:53 | <TabAtkins> | o_O |
| 16:53 | TabAtkins | notes that we are, indeed, fucked. |
| 16:54 | <kling> | Philip`: fwiw webkit will be a loot greener in the next update of that page :) |
| 16:54 | <kling> | lot* |
| 16:54 | <Philip`> | kling: Yeah, I've been seeing lots of nice-looking commit messages :-) |
| 16:55 | <AryehGregor> | Interesting, Opera maxes out both cores while loading the full page. |
| 16:55 | <AryehGregor> | At least part of the time. |
| 16:55 | <AryehGregor> | (unless it's something else that's randomly running at the same time) |
| 16:55 | <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 |
| 16:56 | <AryehGregor> | Those sneaky Europeans. |
| 16:57 | <jwalden> | Philip`: jresig was at one time working on something like that (test swarm?) |
| 16:58 | <AryehGregor> | We don't need anything fancy. For starters, just have a JavaScript framework that can be run as a regular old web page. |
| 17:03 | AryehGregor | finds Chrome dev channel at 82.1%, Firefox nightly at 77.0%, Opera 10.60 at 79.8% |
| 17:03 | AryehGregor | maliciously gave three significant figures so Opera would be below 80% |
| 17:06 | <gsnedders> | For the canvas tests? |
| 17:14 | <AryehGregor> | This is for all of Philip`'s tests. |
| 17:24 | 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. |
| 17:25 | <Philip`> | Gmail seems like the only webmail service you wouldn't be embarrassed to use |
| 17:25 | <Philip`> | e.g. nobody would take you seriously if you were @hotmail.com |
| 17:26 | <AryehGregor> | One of the addresses was @aol.com! |
| 17:26 | <AryehGregor> | I also know someone @earthlink.net. |
| 17:26 | <AryehGregor> | (That person uses dial-up too.) |
| 17:26 | <jgraham> | Is hixie.ch slow for everyone? |
| 17:26 | <TabAtkins> | No. |
| 17:27 | <AryehGregor> | Someone needs to make slowforeveryoneorjustme.com. |
| 17:27 | <jgraham> | Specifically the live dom viewer |
| 17:27 | <Workshiva> | ... I was going to say that, AryehGregor ! |
| 17:27 | <jgraham> | Actauuly that is timing out in firefox |
| 17:27 | <jgraham> | Which is causing a YSOD |
| 17:27 | <jgraham> | Because of a missing entity in the error document |
| 17:28 | <TabAtkins> | Nm, yes it is running a bit slow. |
| 17:28 | <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. |
| 17:50 | <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. |
| 17:53 | <othermaciej> | also the fallback behavior would be insecure |
| 17:53 | <TabAtkins> | Ah, right, yeah. |
| 17:53 | <othermaciej> | rather than failing |
| 17:53 | <othermaciej> | which may or may not be better, depending on your use case |
| 17:54 | <othermaciej> | if you are also doing server-side filtering and want sandbox for defense in depth, it would be better |
| 17:55 | <othermaciej> | it would also be oddly non-orthogonal for the parser to sometimes ignore a close tag in this case |
| 17:56 | <othermaciej> | <sandbox @secure-token> </sandbox @secure-token> could work but carries risk if the token is predictable |
| 17:56 | <TabAtkins> | It would be a matter of "consume @length characters from the stream - if the next 10 characters are not </sandbox>, ??? (abort, retry, continue)" |
| 17:56 | <TabAtkins> | Yeah, the rest of the suggestions I remembered the problems with. |
| 17:57 | <othermaciej> | I guess both that and encoding issues are harder to deal with correctly than the minimal escaping required for @srcdoc |
| 17:57 | <TabAtkins> | Yes. |
| 17:57 | <TabAtkins> | @srcdoc is just data: with slightly easier escaping and a slightly better fail model. |
| 17:58 | <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 |
| 17:59 | <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 |
| 17:59 | <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". |
| 17:59 | <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 |
| 17:59 | <othermaciej> | fancier sandbox flag like unique origin would be harder |
| 17:59 | <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. |
| 18:00 | <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. |
| 18:00 | <othermaciej> | length=0 doesn't always work - it would expect the </sandbox> tag immediately and go into failure mode (whatever that is) |
| 18:01 | <TabAtkins> | length=0 is assuming my "forgiving" mode of seeking forward to the next </sandbox>. |
| 18:01 | <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 |
| 18:01 | <othermaciej> | ah |
| 18:01 | <TabAtkins> | Because the strict mode could only, um, kill the page? |
| 18:01 | Philip` | doesn't think security and forgiveness mix well |
| 18:01 | <othermaciej> | using <sandbox length=0> with those semantics would add no security whatsoever |
| 18:01 | <TabAtkins> | Exactly. |
| 18:01 | <TabAtkins> | So, that's junked. |
| 18:02 | <TabAtkins> | (The problem is it *appears* to work just fine, until the obvious exploit happens.) |
| 18:03 | <othermaciej> | any plausible @length proposal would need to not have such an escape clause |
| 18:03 | <TabAtkins> | Yes. |
| 18:03 | <othermaciej> | I think the main problem with nonzero length is the bytes vs. characters trap as discussed |
| 18:04 | <TabAtkins> | And if the failure mode is "eat the page" and it only happens in rare cases, that's not very good. |
| 18:04 | <othermaciej> | I wonder how tricky it is to escape any </sandbox> tags vs. the escaping required for @srcdoc |
| 18:04 | <TabAtkins> | A decent bit. |
| 18:05 | <Philip`> | s/</</g vs s/"/"/g |
| 18:05 | <TabAtkins> | Especially if you allow *only* </sandbox> or every valid syntactic variant. |
| 18:05 | <othermaciej> | is there any way to stick one in that won't appear in an obvious literal search? |
| 18:05 | <TabAtkins> | Isn't something like < / sandbox > allowed? |
| 18:05 | <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 |
| 18:06 | <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. |
| 18:06 | <othermaciej> | if you fail to escape quotes in @srcdoc I guess you notice immediately |
| 18:06 | <Philip`> | whereas with @srcdoc, they'll notice as soon as they try to write any " character |
| 18:06 | <Philip`> | which is likely to happen in common usage |
| 18:06 | <TabAtkins> | othermaciej: Precisely - quotes are common, and will fail with non-malicious content. |
| 18:06 | <TabAtkins> | And will fail in an obvious way. |
| 18:07 | TabAtkins | has dealt with forgetting to escape quotes before - it's really easy to see what you did wrong. |
| 18:07 | <Philip`> | It'll be obvious if they have a syntax-highlighting view-source feature, at least |
| 18:08 | <TabAtkins> | I mean it's obvious in the page itself, when you have a sentence cut off like "And I think it isn". |
| 18:08 | <Philip`> | TabAtkins: Why can't you generally escape <, and define <sandbox> so that it unescapes the content before inserting into an iframe for rendering? |
| 18:08 | <TabAtkins> | Philip`: I suppose that fixes the fallback for <sandbox>, but not the other issues with @length. |
| 18:08 | <Philip`> | TabAtkins: People don't use single-quotes for attributes |
| 18:09 | <TabAtkins> | Philip`: Yes they do? |
| 18:09 | <Philip`> | Much less than double-quotes |
| 18:09 | <TabAtkins> | Okay, sure, but double-quotes are still pretty common in content. |
| 18:09 | TabAtkins | single-quotes all the time to avoid hitting shift. |
| 18:09 | <Philip`> | (I forget the numbers but I think there was well over 10x difference in popularity of " vs ') |
| 18:11 | <Philip`> | Maybe we should use e as the sandbox delimiter |
| 18:11 | <TabAtkins> | Heh. |
| 18:11 | <Philip`> | so that people are extremely likely to notice when they forget it |
| 18:11 | <TabAtkins> | That fails for chinese! |
| 18:11 | <Philip`> | unless they're Chinese |
| 18:11 | <Philip`> | Yeah :-( |
| 18:12 | <TabAtkins> | Do statistical analysis of the page's textContent and escape on the top 5 characters in the histogram. |
| 18:12 | <Philip`> | Just hard-code it based on TLD |
| 18:13 | <TabAtkins> | What about data:? |
| 18:13 | <TabAtkins> | Or localhost, I suppose. Intranets in general. |
| 18:13 | <Philip`> | Base it on the user's locale |
| 18:14 | <Philip`> | Add a series of submenus to let users override the default if it's wrong |
| 18:14 | <Philip`> | Anyway, @srcdoc still seems like the least bad option |
| 18:16 | <TabAtkins> | Indeed. |
| 18:17 | TabAtkins | also expects @length to fail from authors, frex, measuring length and *then* escaping & or something. |
| 18:23 | <dandaman> | <select id="intCountriesList" name="intCountriesList" size="5" |
| 18:23 | <dandaman> | onchange="regionsOrCities($('intCountriesList').value)" style="height: 63px;"> |
| 18:23 | <dandaman> | <option value="" title="--Select Country--">--Select Country--</option> |
| 18:23 | <dandaman> | </select> |
| 18:23 | <dandaman> | my onchange isnt doing anything? |
| 18:23 | <dandaman> | minus a question mark, anyone have an idea |
| 18:23 | <Workshiva> | Do you unfocus the select? |
| 18:23 | <dandaman> | yea |
| 18:24 | <dandaman> | but i click back into it |
| 18:24 | <Workshiva> | But you don't need the $(), you can just use this.value (or even value) |
| 18:24 | <TabAtkins> | Does @onchange="alert('foo')" work? |
| 18:24 | <dandaman> | hold on |
| 18:25 | <dandaman> | TabAtkins: yeah alert foo works |
| 18:25 | <dandaman> | i didnt have tha @ symbol though |
| 18:26 | <TabAtkins> | Yeah, that's just me referring to an attribute. |
| 18:26 | <dandaman> | kk |
| 18:26 | <TabAtkins> | What about onchange="alert(this.value)"? |
| 18:27 | <dandaman> | yep |
| 18:27 | <dandaman> | that works |
| 18:27 | <TabAtkins> | Then try onchange="regionsOrCities(this.value)" |
| 18:28 | <TabAtkins> | (Note that the jQuery object returned by $('intCountriesList') doesn't have a .value property, though it does have a .value() method.) |
| 18:28 | <dandaman> | tried that, didnt work |
| 18:28 | <dandaman> | im gonna try fiddling around with the function |
| 18:29 | <TabAtkins> | Well, you've isolated the problem at least. It's with the function, not your onchange. |
| 18:29 | <Philip`> | Shouldn't it be $('#intCountriesList')? |
| 18:29 | <dandaman> | its the function |
| 18:29 | <TabAtkins> | Depends; if it's Prototype, no. |
| 18:29 | <TabAtkins> | Maybe Prototype has .value, I dunno. |
| 18:30 | <dandaman> | ty for the help |
| 18:30 | <TabAtkins> | np |
| 18:30 | <dandaman> | god damn this channel is so much more useful than C++ or C, those Aholes just call me a retard constantly |
| 18:30 | <TabAtkins> | Testing with alert() is the equivalent of debugging with printf. |
| 18:30 | <TabAtkins> | Not best practice, but damned if it doesn't work. |
| 18:31 | <dandaman> | ill keep it in mind, thanks |
| 18:31 | TabAtkins | wouldn't recommend going to a c++ channel for javascript help in the first place. |
| 18:32 | <dandaman> | i meant for c++ help |
| 18:32 | <dandaman> | ok back to work, thanks again |
| 18:32 | <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? |
| 18:33 | <TabAtkins> | Well, content-in-base64-in-attributes is presumably even more of an antipattern than content-in-attributes. |
| 18:33 | <othermaciej> | it's certainly no better, although it requires 0 additional escaping |
| 18:33 | <othermaciej> | though if you are base-64 encoding you may as well use a data: attribute so no new feature would really be needed |
| 18:34 | <Workshiva> | Yeah, I don't see the gain |
| 18:36 | <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.) |
| 18:39 | <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. |
| 18:39 | <TabAtkins> | AryehGregor: That's just a solution to the bad-fallback problem, though. It doesn't solve any of the other problems. |
| 18:40 | <AryehGregor> | No, it solves all the same problems srcdoc does. |
| 18:40 | <TabAtkins> | Well, what happens if the parser sees <sandbox><b>foo!</b></sandbox>? |
| 18:41 | <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. |
| 18:41 | <AryehGregor> | This means that lack of escaping will be quickly caught, same as srcdoc. |
| 18:41 | <AryehGregor> | Although if it's not caught, then of course it will be vulnerable, same as srcdoc (unless you eat the page). |
| 18:42 | <wirepair> | with the track record of people escaping <>"'& i'd say base64 encoding would be a safer solution |
| 18:42 | <TabAtkins> | And what if the user content is "<b>Foo!</b></sandbox><script src=evil></script>"? |
| 18:42 | <wirepair> | TabAtkins exactly ;) |
| 18:42 | <AryehGregor> | With srcdoc, what if the user content is: "></sandbox><script src=evil></script> |
| 18:43 | <wirepair> | i do pen-testing / security research for a living, and trust me, escaping/encoding "> seems to be beyond a lot of people |
| 18:43 | <AryehGregor> | If there's no escaping, you're screwed, sure. But if it fails fast on innocuous content with no escaping, people will escape. |
| 18:43 | <TabAtkins> | I think that people using " in their comments is more common than people using <, personally. |
| 18:43 | <AryehGregor> | I said it should fail on " for exactly that reason. |
| 18:43 | <TabAtkins> | But it may not be a hugely significant difference. |
| 18:43 | <AryehGregor> | Even though there's technically no reason it should have to. |
| 18:43 | <TabAtkins> | Oh, I see. |
| 18:43 | <AryehGregor> | (I mean, no reason you'd need to escape " otherwise.) |
| 18:43 | <AryehGregor> | And ' too, even. |
| 18:43 | <TabAtkins> | I missed that part, yeah. |
| 18:43 | <Philip`> | Base64 means you need to understand encodings |
| 18:43 | <AryehGregor> | So it will fail even faster than srcdoc. |
| 18:44 | <Philip`> | (since you have to apply it to bytes, and have to agree with the browser on the interpretation of those bytes) |
| 18:44 | <wirepair> | ah right. |
| 18:44 | <Philip`> | which seems like a pain |
| 18:44 | <wirepair> | srcdoc in general seems like a pain though |
| 18:44 | <wirepair> | ;) |
| 18:45 | TabAtkins | wonders if having to escape <>&'" is worth the convenience of having the content as "real" elements. |
| 18:45 | <Philip`> | With @srcdoc there's no additional character encoding issue over what's already needed for the rest of your content |
| 18:45 | <wirepair> | what exactly is the benefit of having the data inline as opposed to it being an external document? |
| 18:45 | <TabAtkins> | Saving a network request. |
| 18:46 | <AryehGregor> | And saving authoring complexity. |
| 18:46 | <TabAtkins> | (Possibly *many*, if you have, say, 200 blog comments that each need to be sandboxed.) |
| 18:46 | <AryehGregor> | So you don't have to write a separate script that will repeat all your permissions checks and whatever all over again. |
| 18:46 | <wirepair> | well, could you not put those 200 blog comments in a single file, but yeah i get your point |
| 18:47 | <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. |
| 18:47 | <AryehGregor> | Then they can interfere with each other. Not necessarily so bad, but not preferable. Ideally any monkey business should be isolated. |
| 18:47 | <AryehGregor> | Right, that too. |
| 18:47 | <wirepair> | yeah no i understand ;) |
| 18:47 | <AryehGregor> | You could absolutely-position stuff over it, if you're insane, but . . . |
| 18:47 | <TabAtkins> | Yeah, no, that's stupid. ^_^ |
| 18:48 | <wirepair> | so far what has the most 'votes' for srcdoc, just escaping "<>&' ? |
| 18:48 | <TabAtkins> | No, just escape " and & (or ', if you use that for your attributes). |
| 18:49 | <wirepair> | ah gotcha |
| 18:49 | <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. |
| 18:49 | <TabAtkins> | So really, just escape whatever quote character you're ursing. |
| 18:50 | <wirepair> | and the source documents content encoding has precedence yeah? my concern would be malformed multibyte sequences |
| 18:50 | <TabAtkins> | Yes. |
| 18:50 | <TabAtkins> | If you're not encoding everything in utf-8 you're doing it wrong anyway. |
| 18:51 | <wirepair> | jeez, please tell that to japan ;) |
| 18:51 | <TabAtkins> | I will. |
| 18:51 | TabAtkins | shakes his fist vaguely west-ward. |
| 18:51 | <wirepair> | haha |
| 18:52 | <TabAtkins> | What's Japan's common encoding? utf-16, or one of those legacy encodings designed just for japanese? |
| 18:52 | <wirepair> | well my customers used Shift_JIS a lot |
| 18:52 | <wirepair> | on rare occassions you'll come across euc-jp |
| 18:53 | <wirepair> | but yeah utf-8 is becoming more commonplace for sure |
| 19:16 | <Hixie> | the main problem with a caret blinking API is that you need a way to know what to repaint |
| 19:18 | <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 |
| 19:19 | <Hixie> | but that seems like a pain |
| 19:19 | <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 |
| 19:20 | <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 |
| 19:20 | <Hixie> | maybe we should have the method take x,y,w,h of the text field, then a separate x,y of the caret |
| 19:21 | <Hixie> | and the caret just gets clipped to the x,y,w,h |
| 19:24 | <Hixie> | or we could say you have to repaint whatever your clip region is |
| 19:25 | <Hixie> | and then just clip it to the clip region |
| 19:25 | <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 |
| 19:49 | <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? |
| 19:51 | <TabAtkins> | Based on my limited experience with <canvas>, I prefer something that I can call myself whenever I repaint. |
| 19:52 | <Hixie> | well for a caret you don't want to repaint the whole canvas each time |
| 19:52 | <TabAtkins> | Pfft. My text editor will have a live video background. |
| 19:53 | <Hixie> | there is so much wrong with that sentence... |
| 19:54 | <TabAtkins> | Then I can use webkit's background-clip:text to play a *different* video for the text itself. |
| 19:54 | <TabAtkins> | Though that's silly, obviously. The video itself should play in the text, then a grayscale in the background. |
| 19:54 | <Hixie> | there's no _canvas_ in this fantasy :-P |
| 19:55 | <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. |
| 19:55 | <TabAtkins> | Also, grayscaling the video needs canvas. |
| 19:55 | <TabAtkins> | Or SVG, I suppose. |
| 19:56 | TabAtkins | wonders if SVG filters on a <video> can get copied into a <canvas>. |
| 19:56 | <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 |
| 19:56 | <TabAtkins> | You've already lost the sane people. |
| 19:56 | <TabAtkins> | I'm going to implement a text editor that plays pong with the letters. |
| 19:59 | <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. |
| 19:59 | <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. |
| 20:00 | <Hixie> | the way i envision this, you don't worry about blinking the caret |
| 20:00 | <Hixie> | drawCaret() just decides based on a timer whether to draw the caret or not for this frame |
| 20:00 | <TabAtkins> | Yes, that would be fine. I can call drawCaret() in the rest of my drawing code, right? |
| 20:00 | <jgraham> | I vaugely feel like a callback is better if the browser is providing the timing |
| 20:01 | <Hixie> | or maybe an event? |
| 20:01 | <jgraham> | But I have nothing to go on there |
| 20:01 | <Hixie> | <canvas onredrawcaret=""> ? |
| 20:01 | <jgraham> | yuck |
| 20:01 | TabAtkins | had problems with flickering when he tried to have things draw on separate schedules. |
| 20:02 | <jgraham> | Hmm, I can see that could be an issue |
| 20:13 | <jgraham> | So, do we also need drawSelection? |
| 20:13 | <jgraham> | It seems like canvas apps could always put the caret at the end of the selection |
| 20:14 | <jgraham> | Althought I suppose that would be bad if they tried to differentiate their behaviour based on OS |
| 20:14 | <jgraham> | (which seems unlikely but possible) |
| 20:14 | <jgraham> | It also seems possible that people will fail to move the caret when drawing a selection if they have to do it manually |
| 20:15 | <jgraham> | (I'm not sure how draw selection could work really) |
| 20:15 | <jgraham> | (so it may not even be possible to do in a sane way) |
| 20:18 | <jgraham> | Hixie: BTW I filed a bug in the handling of EOF after a foreign-content closing tag |
| 20:18 | <jgraham> | e.g. <svg></svg> |
| 20:20 | <Hixie> | jgraham: i haven't been able to find good documentation on accessibility APIs' handling of selections |
| 20:20 | <Hixie> | (accessibility APIs in general are pretty poorly documented) |
| 20:21 | <AryehGregor> | Do most browsers cache HTTP redirects already? Apparently IE9 now does. |
| 20:21 | <Hixie> | i don't really see what such an API would do, though |
| 20:21 | <TabAtkins> | AryehGregor: Yes. |
| 20:21 | <TabAtkins> | At least, it is indeed done. |
| 20:21 | <Hixie> | we don't need an API to say what the selected text _is_, which might well be something AAPIs would care about |
| 20:22 | <Hixie> | (we don't need it because the UA already knows what the text is since they have the control itself in the DOM) |
| 20:24 | <jgraham> | Hixie: AFAICT the only point is to control where the magnifier is positioned |
| 20:24 | <jgraham> | It has to be at the end of the selection |
| 20:25 | <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 |
| 20:25 | <jgraham> | (or an accessibility-specific API) |
| 20:30 | <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 |
| 20:30 | <othermaciej> | there is no caret when you have a non-caret selection established |
| 20:32 | <othermaciej> | let me check how/whether carets or selections are represented via Accessibility Inspector |
| 20:35 | <othermaciej> | both are exposed via the http://axdb.apple.com/AXSelectedTextMarkerRange property |
| 20:35 | <othermaciej> | ignore the URLey bits, it's just AXSelectedTextMarkerRange |
| 20:38 | <othermaciej> | and the assistive technology is allowed to query the bounding box of the reported text marker range |
| 20:38 | <othermaciej> | so to fulfill the selection-related accessibility APIs, we would need to know the bounding box of the current selection or caret |
| 20:41 | <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) |
| 21:16 | <TabAtkins> | AryehGregor: You around? |
| 21:16 | <AryehGregor> | Yes. |
| 21:17 | <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. |
| 21:17 | TabAtkins | just uses AryehGregor for math from now on. |
| 21:18 | <AryehGregor> | Ugh, don't they have a LaTeX display extension there? |
| 21:18 | <TabAtkins> | Yes they do. Do you have js turned on? |
| 21:18 | <AryehGregor> | Yes. |
| 21:18 | <Philip`> | Yes, if you wait ten seconds for it to load |
| 21:19 | <AryehGregor> | Not working for me. |
| 21:19 | <TabAtkins> | I'll screenshot then. |
| 21:20 | <Philip`> | I presume they should have had (2\pi)^2 on the left |
| 21:20 | <TabAtkins> | Philip`: Plus squaring the 1/omega^2 on the right. |
| 21:21 | <Philip`> | Oh, I missed that |
| 21:22 | <TabAtkins> | http://www.xanthir.com/etc/math.png |
| 21:23 | <jgraham> | The last line should have x^2 on the top of the fraction |
| 21:23 | <AryehGregor> | The second step looks okay, multiply by 2pi and square both sides. Except that you should have (2pi)^2 on the left. |
| 21:23 | <TabAtkins> | AryehGregor: (ab)^2 is a^2 * b^2, though. |
| 21:23 | <TabAtkins> | So the rhs should square the 1/omega^2 as well. |
| 21:23 | <AryehGregor> | You mean sigma? |
| 21:24 | <TabAtkins> | Um, yes. |
| 21:24 | <AryehGregor> | Oh, right, I missed that. |
| 21:24 | <jgraham> | That is true |
| 21:24 | <AryehGregor> | Yes, should be sigma^4. |
| 21:24 | <TabAtkins> | kk, so it's all kinds of messed up. Great. |
| 21:24 | <TabAtkins> | Well, the important part was done for me. |
| 21:24 | <AryehGregor> | The general idea is right, though. |
| 21:24 | <AryehGregor> | I somehow doubt we actually want to mandate this in CSS. |
| 21:24 | <TabAtkins> | No, we don't. But I was asked for it. ^_^ |
| 21:25 | <TabAtkins> | There are much easier approximations that should get close enough. |
| 21:25 | <jgraham> | That means it doesn't end up in the nice simple W exp(W) form they want though |
| 21:25 | <TabAtkins> | Oh, hm. |
| 21:25 | <jgraham> | (the 1/sigma^4) |
| 21:25 | <AryehGregor> | Oh, you're trying to isolate sigma, hmm? |
| 21:25 | <AryehGregor> | Well, so don't square. |
| 21:25 | <Philip`> | Just go with 37% instead of 1% and it's trivial :-p |
| 21:25 | <AryehGregor> | Just multiply both sides by -x^2/pi. |
| 21:25 | <AryehGregor> | I mean. |
| 21:25 | <AryehGregor> | -x^2 * pi. |
| 21:25 | <jgraham> | Yes |
| 21:26 | <AryehGregor> | Whatever. |
| 21:26 | <TabAtkins> | AryehGregor: Yeah. |
| 21:26 | <AryehGregor> | Then take the W function. |
| 21:26 | <TabAtkins> | kk |
| 21:26 | <TabAtkins> | Hm, yeah, not sure why they thought it was necessary to pull the 2 out of the exp. |
| 21:26 | <jgraham> | So yeah, basically it is all kinds of wrong |
| 21:26 | <jgraham> | But the right general idea :) |
| 21:31 | <TabAtkins> | K, I've posted an updated version that I think fixed the original flaws. |
| 21:31 | <TabAtkins> | Urg, wait, G is still getting squared. |
| 21:32 | <TabAtkins> | k, fixed. |
| 21:33 | <TabAtkins> | Hmm... The starting point is still wrong, though - there's a sqrt in the original equation that got dropped. |
| 21:33 | <annevk> | wtf is leif on about |
| 21:33 | <annevk> | i explained why i didn't entirely agreed |
| 21:34 | <annevk> | oh well |
| 21:34 | <AryehGregor> | TabAtkins, you seem to be using some mix of the two-dimensional and one-dimensional equations from Wikipedia. |
| 21:34 | <annevk> | not like this is anything new |
| 21:34 | <hober> | annevk: I never understand his emails |
| 21:34 | <TabAtkins> | AryehGregor: I'm not, the responder is. I'm fixing it now. |
| 21:34 | <TabAtkins> | I'm Xanthir in this conversation. |
| 21:35 | <AryehGregor> | I know. |
| 21:35 | <AryehGregor> | You can drop the \pm, by the way. Standard deviations are always treated as positive. |
| 21:35 | <TabAtkins> | Yeah. |
| 21:36 | <TabAtkins> | Lessee... 1/sqrt(2*pi*sigma^2) is the same as 1/(sqrt(2*pi)*sigma), right? |
| 21:36 | TabAtkins | knows this is basic algebra. |
| 21:38 | <TabAtkins> | Hm, though. That then seems to make it more difficult to get the RHS into the correct form. Damn. |
| 21:39 | <annevk> | I'm no longer going to contribute to polyglot discussions |
| 21:39 | <annevk> | waste of time |
| 21:39 | <TabAtkins> | Welcome to the club of "everyone else in the world", anne. |
| 21:39 | <AryehGregor> | If sigma is positive, then yes, it's the same. |
| 21:39 | <AryehGregor> | This is where you want to square it. |
| 21:39 | <AryehGregor> | That won't harm the exponential (just knock out a constant), but it will get the sigma squared. |
| 21:40 | <TabAtkins> | Ah, you're right. |
| 21:40 | <AryehGregor> | Maybe the original poster's mistakes weren't where you thought. :) |
| 21:40 | <AryehGregor> | (we, whateveR) |
| 21:40 | <annevk> | I can't believe there are so many replies and nobody called Leif on his nonsense |
| 21:41 | <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) |
| 21:41 | <annevk> | thought* |
| 21:41 | <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. |
| 21:41 | <jgraham> | annevk: I don't think that anyone understand much of what leif says tbh |
| 21:42 | <jgraham> | So he is often just ignored |
| 21:44 | <annevk> | Sam replied directly to him |
| 21:45 | <annevk> | still not sure what a good color for webforms2.org would be |
| 21:45 | <annevk> | what can beat hotpink? ;p |
| 21:45 | <TabAtkins> | annevk: What part of MQ did you want reviewed? |
| 21:48 | <Philip`> | annevk: It should blink |
| 21:48 | <Philip`> | (using APNG) |
| 21:49 | <TabAtkins> | Aw yeah. |
| 22:35 | <Hixie> | jgraham: feel free to write another CP that removes the need for UAs to implement it too |
| 22:35 | <Hixie> | jgraham: you can copy mine and just change that bit if you want |
| 22:35 | <Hixie> | othermaciej: so wait, what do we need to expose? |
| 22:35 | <Hixie> | othermaciej: just the bounding box of the selection? not the actual selection? |
| 22:35 | <Hixie> | othermaciej: does OS X have wide carets? |
| 22:35 | <Hixie> | othermaciej: (in windows you can set the width of the caret apparently) |
| 22:36 | <Hixie> | (which makes a caret drawing function hard) |
| 22:36 | <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: |
| 22:36 | <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 |
| 22:37 | <othermaciej> | - the ability to get the string of text in that range |
| 22:37 | <othermaciej> | - the ability to get the visual bounding box of that range |
| 22:38 | <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 |
| 22:38 | <Hixie> | well the first two are easy since we have the underlying control already |
| 22:38 | <Hixie> | the third one is harder... what can we use as a surrogate in the API for exposing that? |
| 22:38 | <othermaciej> | right, the first two don't require any additions to what HTML5 has, if you put a text control in the child DOM |
| 22:38 | <Hixie> | for just a caret we can just have a caret drawing function |
| 22:38 | <Hixie> | but for a selection... |
| 22:38 | <othermaciej> | drawing a caret or selection is one possibility |
| 22:39 | <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 |
| 22:39 | <Hixie> | hard is one way to put it |
| 22:40 | <Hixie> | i wonder what the equivalent is on windows |
| 22:41 | <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 |
| 22:41 | <othermaciej> | but I have no firsthand knowledge of that |
| 22:41 | <annevk> | Philip`, sweet |
| 22:41 | <annevk> | Philip`, can you make one? |
| 22:42 | <annevk> | TabAtkins, just what changed; section 2/3 |
| 22:42 | <annevk> | TabAtkins, but only if you have time, it's not necessary |
| 22:42 | <Philip`> | annevk: I've forgotten how to do it |
| 22:42 | <TabAtkins> | annevk: I've had it sitting in my open tabs since yesterday, so I might as well. |
| 22:43 | <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 |
| 22:43 | <annevk> | TabAtkins, though please no feature requests ;p |
| 22:43 | <Hixie> | othermaciej: he also claimed something similar for OS X which is apparently wrong |
| 22:44 | <annevk> | Philip`, it's a 32x32 image... |
| 22:44 | <TabAtkins> | annevk: No promises. |
| 22:44 | <Philip`> | I think there might have been a Firefox extension that made APNGs easily |
| 22:44 | <jgraham> | Please no flashing favicons |
| 22:44 | Philip` | wonders if support has become more widespread recently |
| 22:45 | <jgraham> | I will have to kill you |
| 22:45 | <Philip`> | jgraham: What about subtle pulsing? |
| 22:45 | <jgraham> | And then we will have even fewer editors for web specs |
| 22:45 | <othermaciej> | Hixie: I think he may be confused about how selections work on OS X |
| 22:45 | <annevk> | means you'll finally come to the Netherlands? |
| 22:45 | Philip` | still likes http://zaynar.co.uk/favicon.ico |
| 22:45 | <othermaciej> | when you hit an arrow key when you have a selection, you do get a caret at a specific point |
| 22:45 | <annevk> | might be worth it ;p |
| 22:45 | <othermaciej> | but prior to that point, there *is* no caret |
| 22:46 | <othermaciej> | but he interprets that as the caret was secretly at the end of the selection |
| 22:46 | <jgraham> | Philip`: "subtle" meaning with a ime period of > 1 week, say? |
| 22:46 | <jgraham> | s/ime// |
| 22:46 | <othermaciej> | that's not how the AX APIs expose it, afaict |
| 22:46 | AryehGregor | still likes http://www.p01.org/releases/DEFENDER_of_the_favicon/ |
| 22:47 | <Philip`> | jgraham: APNG has a maximum of 65535 seconds per frame, so I suppose you'd only need ten frames for that |
| 22:47 | <Philip`> | although I don't know how well implementations handle timers like that |
| 22:47 | <Philip`> | (I don't fancy testing it) |
| 22:48 | <AryehGregor> | A time period of a few minutes sounds good to me. Maybe half an hour. |
| 22:48 | <AryehGregor> | Once in a while, someone will notice some movement out of the corner of their eye. |
| 22:48 | <AryehGregor> | Then go crazy trying to figure out what it is. |
| 22:49 | <TabAtkins> | Sounds like what I did with the tech support portal at my old job. |
| 22:49 | <annevk> | a speed that drives jgraham temporarily insane is acceptable I think |
| 22:50 | <annevk> | there's no reason to visit webforms2.org anyway |
| 22:50 | <annevk> | it's a reminder of what that was |
| 22:50 | <AryehGregor> | TabAtkins, what did you do with the tech support portal at your old job? |
| 22:51 | <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. |
| 22:51 | <AryehGregor> | Your company sounds fun to work for. |
| 22:51 | <TabAtkins> | That was an internal tool, so I could fuck around. |
| 22:51 | <AryehGregor> | But you shouldn't rely on setTimeout(func,0) taking a nonzero amount of time. That's not forward-compatible. |
| 22:52 | <Philip`> | I expect the level of fun depends on whether you're TabAtkins or one of his victims |
| 22:52 | <AryehGregor> | Or at least, you shouldn't rely on it taking an appreciable amount of time. |
| 22:52 | <TabAtkins> | AryehGregor: True. I suppose a setTimeout(func,10) would be safer. Even if browsers actually run it at the stated speed, it'll be up for long enough. |
| 22:52 | <AryehGregor> | 10 ms isn't enough to be perceptible, I don't think. |
| 22:52 | <AryehGregor> | I'm pretty sure 50 ms is the bare minimum. |
| 22:53 | <TabAtkins> | Philip`: To my knowledge, nobody's ever consciously realized it, but they have mentioned something odd. |
| 22:53 | <Hixie> | othermaciej: i can't find anything about exposing a selection in MSAA or MUIA |
| 22:53 | <TabAtkins> | AryehGregor: setTimeout generally delays by about 30ms, which is actually a relatively long period of time for it to be up, from experience. |
| 22:53 | <TabAtkins> | I'd flash it for less if I could. |
| 22:53 | <jgraham> | 30ms? Are you sure? |
| 22:54 | <TabAtkins> | jgraham: No, I'm not, just going off of memory. The MDC says that Gecko uses 10ms minimum. |
| 22:54 | <TabAtkins> | And HTML5 apparently defines a minimum of 4ms, which means that 0 is forward-compatible enough for me. |
| 22:57 | <TabAtkins> | So, if it's flashing for 10ms in Gecko (the browser I used for testing when I was doing more webdev) then that's plenty enough. |
| 22:57 | <TabAtkins> | AryehGregor: It's possible that 50ms or so is the minimum to *comprehend* what's seen, but it's definitely not the minimum to note that *something* is there. |
| 22:58 | <jgraham> | Seems to be about 10 in Opera and Firefox but 5 in Chrome |
| 22:58 | <Hixie> | othermaciej: http://www.mozilla.org/access/windows/msaa-server#Hacky_caret_tracking_not_working |
| 22:59 | <TabAtkins> | Sigh. |
| 23:00 | <jgraham> | Sigh is one way to put it |
| 23:00 | <AryehGregor> | I can identify the word "Test" here something like half the time: time.sleep(0.5); print "Test",; sys.stdout.flush(); time.sleep(0.025); print "\b\b\b\b\b "; sys.stdout.flush() |
| 23:00 | <AryehGregor> | No, less. |
| 23:01 | <AryehGregor> | If I bump 0.025 to 0.03, I can distinguish it clearly all the time, if I'm looking. |
| 23:03 | <AryehGregor> | At 0.02 I can't see anything, but it's not perfect, since it adds newlines and the cursor gets in the way. |
| 23:03 | <othermaciej> | Hixie: that seems to be par for the course for Windows accessibility... |
| 23:03 | <othermaciej> | a whole lot of hacky screenscraping |
| 23:03 | <Hixie> | i can't find _anything_ about the text selection being exposed |
| 23:07 | <AryehGregor> | TabAtkins, http://pastebin.com/WvfYS5LM |
| 23:07 | <AryehGregor> | What do you see from that? |
| 23:08 | <TabAtkins> | I can clearly see the word "Test" flash. |
| 23:11 | <AryehGregor> | What if you adjust the DELAY? |
| 23:11 | <AryehGregor> | I see it flash at 0.025, but not 0.02. |
| 23:12 | <TabAtkins> | There's some odd effects here. At .025 it flashes, at .024 it's completely invisible. |
| 23:12 | <AryehGregor> | I think I only see it at 0.025 because of intermittent additional delays, though. I only see it some of the time. |
| 23:12 | <TabAtkins> | It's not flashing at all. |
| 23:12 | <AryehGregor> | Maybe it would be more accurate to spin and poll the current time. Probably time.sleep() isn't so accurate. |
| 23:12 | <TabAtkins> | Yeah. |
| 23:16 | <TabAtkins> | doing it in js is much better. Load this up in your console: unction flash(delay,visible) { document.body.innerHTML = visible ? "test" : ""; setTimeout(function(){ flash(delay, !visible); }, visible ? delay : 1000); } |
| 23:16 | <AryehGregor> | How do you get a JavaScript console? I've never had to. |
| 23:16 | <TabAtkins> | What browser you got? |
| 23:16 | <AryehGregor> | Chrome right now. |
| 23:16 | <TabAtkins> | right click, inspect element, hit Esc if the console isn't already up. |
| 23:18 | <AryehGregor> | Even at 0 it's clearly visible. |
| 23:18 | <AryehGregor> | Clearly JS timers stink. |
| 23:20 | <AryehGregor> | TabAtkins, should I report the totally bogus canvas shadows on the Chromium tracker, or will it just be WontFix? Does canvas really need such fast shadow drawing? |
| 23:20 | <TabAtkins> | I dunno. Go ahead and report. |
| 23:27 | <AryehGregor> | Maybe I'll do that tomorrow. |
| 23:30 | <TabAtkins> | annevk: In the grammar for media_query_list, you're missing a S* after the first media_query. |
| 23:31 | <Hixie> | aha! |
| 23:31 | <Hixie> | othermaciej: http://msdn.microsoft.com/en-us/library/ff384841(v=VS.85).aspx |
| 23:32 | <annevk> | TabAtkins, no |
| 23:32 | <Hixie> | othermaciej: specifically, ITextRangeProvider::GetBoundingRectangles |
| 23:32 | <annevk> | TabAtkins, that S* can be found elsewhere |
| 23:32 | <TabAtkins> | annevk: Not in all circumstances. |
| 23:32 | <annevk> | TabAtkins, nested :) |
| 23:32 | <TabAtkins> | Oh, wait. Damn, you're right. |
| 23:33 | <TabAtkins> | I missed the S* trailing the expression token. |
| 23:33 | <annevk> | CSS grammar is evil |
| 23:33 | <TabAtkins> | ftfy: grammar is evil |
| 23:33 | <annevk> | we should have HTML5-like style imo |
| 23:33 | <annevk> | that would also exemplify how fricking complex it is |
| 23:33 | <Hixie> | othermaciej: apparently on windows you have to use a "system caret" rather than draw your own: http://msdn.microsoft.com/en-us/library/ms646968(v=VS.85).aspx and the section at the end of the earlier cited http://msdn.microsoft.com/en-us/library/ff384841(v=VS.85).aspx |
| 23:34 | <TabAtkins> | Maybe for core grammar. For properties the CSS grammar is a big win in general. |
| 23:34 | <annevk> | properties are defined in woefully inconsistent ways |
| 23:35 | <annevk> | and the grammar for properties is usually some kind of adhoc stuff made up on the fly |
| 23:35 | <TabAtkins> | Inconsistency can and should be fixed. But the principle is sound and usually easily readable. |
| 23:35 | <annevk> | I guess it works because you sort of understand what is going on, but it's not particularly great |
| 23:36 | <TabAtkins> | Frex, what's easier, seeing "::cue( [ <voice> || <type> || <time> ] )" (or whatever), or seeing a parser for the same? |
| 23:39 | <annevk> | just ::cue is actually buggy somewhat |
| 23:39 | <annevk> | should be something like "::"{C}{U}{E} |
| 23:40 | <TabAtkins> | If we're writing a *real* grammar, yes. But we're not. |
| 23:40 | <TabAtkins> | This is just a shorthand for describing the grammar. |
| 23:40 | <annevk> | no even in the shorthand you need to do that |
| 23:41 | <TabAtkins> | I have never seen that in any property ever. |
| 23:41 | <AryehGregor> | You could have non-normative text giving a basic description of the property, then have a real parser defined for actual implementations. |
| 23:41 | <annevk> | see e.g. how :not is defined |
| 23:41 | <TabAtkins> | And it would be silly to do so, imo, because it drastically reduces readability for no good reason. |
| 23:41 | <AryehGregor> | which is kind of what HTML5 does. |
| 23:41 | <AryehGregor> | I mean, it has the nice foo(bar [ , baz [ , quuz ] ] ) stuff. |
| 23:42 | <AryehGregor> | Just not normatively. |
| 23:42 | <TabAtkins> | annevk: :not() only receives that treatment in the official grammar section. |
| 23:43 | <TabAtkins> | There, yes, use the normal rules for whatever language we're expressing this stuff in. |
| 23:43 | <annevk> | we're discussing grammar, no? |
| 23:43 | <TabAtkins> | I'm discussing the grammar that you see in property blocks and similar. |
| 23:43 | <Hixie> | i'll be damned if i can work out what we need to do for caret and selection accessibility on windows |
| 23:48 | <AryehGregor> | You can't just ask someone at Microsoft? |
| 23:48 | <AryehGregor> | You know, like you asked Maciej about OS X? |
| 23:49 | <Hixie> | i didn't ask maciej, he just told me :-) |
| 23:49 | <Hixie> | who should i ask? |
| 23:50 | <TabAtkins> | I dunno directly, but you could start by hitting up Sylvain I guess, and he could direct you accordingly. |
| 23:50 | <AryehGregor> | There are Microsoft people in the HTMLWG, no? |
| 23:50 | <AryehGregor> | Probably they won't know themselves, but they can forward your request someplace. |
| 23:51 | <MikeSmith> | I suspect Frank Olivier would know well |
| 23:52 | <MikeSmith> | Hixie: would this relate to drag-and-drop as well? |
| 23:53 | <MikeSmith> | I mean to keyboard activatability of text selection in drag-and-drop ? |
| 23:53 | <MikeSmith> | hmm, I guess those are actually orthogonal |
| 23:55 | <Hixie> | yeah i don't see how |
