| 02:01 | <Hixie> | Philip`: http://www.whatwg.org/specs/web-apps/current-work/#shadows |
| 02:01 | <Hixie> | Philip`: what do you think? i tried avoiding the maths... |
| 02:03 | <Philip`> | Hixie: "Shadows form part of the source image during composition." - they don't in Safari |
| 02:03 | <Hixie> | oh? |
| 02:03 | <Philip`> | (The shadow gets composited onto the canvas first, and then the source image is composited on top) |
| 02:03 | <Hixie> | that seems dumb |
| 02:04 | <Hixie> | wouldn't that mean you would get non-shadow-like effects when your globalcompositethingy is not source-over? |
| 02:06 | <Philip`> | http://canvex.lazyilluminati.com/misc/shadow/shadow2.html (in Safari) - the rows have different globalCompositeOperations, and it does result in things that don't really look like shadows |
| 02:07 | <Hixie> | does any browser to shadows other than safair? |
| 02:07 | <Hixie> | safari? |
| 02:07 | <Philip`> | No (though there's a patch for Firefox that I wrote) |
| 02:08 | <Hixie> | do you recommend that we try to get safari to change, or should i just make the spec do this weird behaviour? |
| 02:09 | <Philip`> | I assume Safari uses some CG function to draw shadows, so it'd be a pain if they had to rewrite it all to do custom rendering, and I don't think any other behaviour would be significantly less weird |
| 02:09 | <Hixie> | k |
| 02:10 | <Philip`> | (I don't have any kind of intuitive understanding of what should happen when you xor a semi-transparent shadowed shape onto a background, so everything is equally weird) |
| 02:11 | <Hixie> | true |
| 02:11 | <Philip`> | (and Safari's approach is at least sensible when you have operation=source-over and globalAlpha=anything) |
| 02:12 | <Hixie> | ok, changed the drawing model (it'll update in about 60 seconds) |
| 02:14 | <Philip`> | "The shadowBlur attribute specifies the number of coordinate space units that the blurring is to cover." - it doesn't really specify that, since there's some non-linear calculation to convert shadowBlur into the Gaussian radius and then the blur is theoretically infinitely wide; so maybe it should say something vague like "The shadowBlur attribute determines the size of the blur" |
| 02:16 | <Philip`> | "Copy the alpha channel of A to B, offset by shadowOffsetX in the positive x direction, and shadowOffsetY in the positive y direction." - shadowOffsetY is not a link |
| 02:16 | <Philip`> | "let σ be the square root of span>shadowBlur*2" - HTML leakage, and also the sentence doesn't end with a "." |
| 02:18 | <Hixie> | thanks, fixed and regenning... |
| 02:18 | <Philip`> | "Perform a Gaussian Blur on B" - might be slightly clearer as "Perform a 2D Gaussian blur on B" |
| 02:18 | <Hixie> | fixed and regenning... |
| 02:19 | <Hixie> | do you have a good reference for 2D Gaussian Blur, btw? i looked at google scholar for a siggraph paper or something, but found nothing |
| 02:19 | <Philip`> | "Multiply the alpha component of every pixel in B by the alpha components of the color of shadowColor." - s/components/component/ |
| 02:20 | <Hixie> | fixed internally |
| 02:21 | <Philip`> | Hmm, I don't know of any references |
| 02:22 | <Philip`> | Gauss probably wasn't into computer graphics much, and afterwards Gaussian blurs were sufficiently obvious that maybe nobody could publish research papers about it |
| 02:22 | <Hixie> | heh |
| 02:24 | <Philip`> | Maybe there's some standard graphics textbook that describes fundamental things like that, but I wouldn't know of it |
| 02:24 | <Hixie> | several people have suggested text books, but i'd rather refer to the original reference or to nothing at all |
| 02:27 | <Philip`> | "Rendered the shadow from image A, using the current shadow styles, creating image B." - s/Rendered/Render/ |
| 02:27 | <Philip`> | It's not clear what should be done when shadows are not supported |
| 02:28 | <kig> | it's a convolution kernel with the factors following a gaussian distribution, right? |
| 02:28 | <Hixie> | Philip`: hm, good point |
| 02:28 | <Philip`> | kig: Yes |
| 02:31 | <Philip`> | "Multiply the alpha component of every pixel in B by globalAlpha." (and subsequent lines) - "B" should be italics |
| 02:32 | <Hixie> | will fix |
| 02:33 | <Philip`> | Back at the beginning, "Shadows form part of the source image during composition." should be removed (if it isn't already) |
| 02:35 | <Philip`> | Is it worth saying something like "σ (may|should) be clamped to a maximum value before drawing, to prevent excessive memory usage"? |
| 02:36 | <Philip`> | Hmm, don't think I see anything else to comment on at the moment |
| 02:37 | <Philip`> | (It's sensible to avoid the maths for the blurring - I don't know why I originally suggested writing it all explicitly, when it's not like anyone is going to implement it based on the spec's maths) |
| 02:39 | <Hixie> | would this be ok: |
| 02:39 | <Hixie> | <p>User agents may limit values of <var title="">σ</var> to |
| 02:39 | <Hixie> | an implementation-specific maximum value to avoid memory or CPU |
| 02:39 | <Hixie> | limitations during the Gaussian blur operation.</p> |
| 02:39 | <Hixie> | s/avoid memory/avoid exceeding memory/ |
| 02:40 | <Hixie> | and s/memory or CPU/hardware/ |
| 02:41 | <Philip`> | I think that sounds reasonable, just as a hint to implementors that they should prevent shadowBlur=1e10 |
| 02:43 | <Hixie> | is clearRect() affected by the clipping region? |
| 02:44 | <Philip`> | Yes, in Opera/Firefox/Safari |
| 02:44 | <Hixie> | but not globalAlpha or globalCompositeOperation, right? |
| 02:44 | <Philip`> | according to http://philip.html5.org/tests/canvas/suite/tests/2d.clearRect.clip.html (although Opera is a bit funny and gets the alpha slightly wrong) |
| 02:44 | <Philip`> | No (except globalCompositeOperation in Opera 9.2 (not 9.5)), according to http://philip.html5.org/tests/canvas/suite/tests/2d.clearRect.globalcomposite.html |
| 02:45 | <Hixie> | ok |
| 02:45 | <Philip`> | (and http://philip.html5.org/tests/canvas/suite/tests/2d.clearRect.globalalpha.html) |
| 02:45 | <Hixie> | thanks |
| 02:45 | <Philip`> | (and it's affected by shadows in Safari, which seems silly) |
| 02:46 | <Hixie> | ok, regenning the new text for shadows and clearRect() |
| 02:49 | <Hixie> | i don't seem to be getting as much mail this year as last year |
| 02:49 | <Hixie> | let's hope this lasts |
| 02:50 | <Hixie> | regenned |
| 02:55 | <Philip`> | Is there any value in being explicit that shadowOffset[XY] are not affected by the CTM? |
| 02:55 | <Philip`> | (since it's now mentioned that shadowBlur is unaffected by it) |
| 02:56 | <Philip`> | "... the new value is igored." - I'm not sure what Igor is doing here |
| 02:57 | <Philip`> | The whole "Let A be the source image for which a shadow is being created." etc section has non-italic "A", whereas the Drawing Model section has italic "A" |
| 02:59 | <Philip`> | "If shadowBlur is less than 8, let σ be shadowBlur/2; otherwise, let σ be the square root of shadowBlur*2." - the "/" and "*" look a bit out of place - maybe use the proper divide and times symbols? |
| 03:00 | <Philip`> | I'll assume implementors can work out for themselves that the shadow rendering can be skipped iff shadowColor.alpha == 0 |
| 03:01 | <Philip`> | (since they'd be stupid to not optimise that case) |
| 03:02 | <Philip`> | It'd be nice if "Render the shadow from image A, using the current shadow styles, creating image B." linked back to the definition of how to render a shadow |
| 03:02 | Philip` | can't think of any comments now again |
| 03:04 | Philip` | goes to bed |
| 14:12 | <hsivonen> | based on the minutes, the waf telecon seems to have been one that would have been interesting to listen to... |
| 14:14 | <Dashiva> | Are the minutes public? |
| 14:14 | <hsivonen> | Dashiva: yes. |
| 14:15 | <hsivonen> | Dashiva: http://www.w3.org/mid/213B17B2-B67E-4D5F-A6D9-D7C3499AB228⊙nc |
| 14:23 | <Dashiva> | Interesting indeed |
| 18:52 | <hsivonen> | annevk: FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=289938#c16 |
| 19:29 | <SadEagle> | Hiya Hixie... Any chance you have a reference/spec on how you expect button.type to behave? Mozilla's and Opera's implementations are not interoperable (and ours just play sucks) |
| 19:33 | <SadEagle> | I guess WF2.0 behavior is consistent with Opera, though.. |
| 19:38 | <heycam> | Hixie, the not crashing requirement on safari 3 for the acid3 submissions, is that an actual safari 3 release, rather than a webkit nightly? |
| 20:03 | <Hixie> | SadEagle: dom2 html :-) |
| 20:03 | <Hixie> | heycam: both, ideally |
| 20:04 | <SadEagle> | Hixie: come on. You know as well as me that that spec is barely above useless. |
| 20:05 | <SadEagle> | I can make some guesses about what they -meant- by the case folding remark. But it says nothing about what to do when the value isn't one of the button / submit / reset. |
| 20:07 | <SadEagle> | Mozilla behavior is that the values submit / button / reset are case folded on return. Other values are unaffected, including returning uppercase (which does contradict the lowercasing remark). Lack of attribute (what you test for, I think?) is interpreted as submit. |
| 20:08 | <heycam> | Hixie, ok |
| 20:08 | <SadEagle> | Opera (and ~now Konq) behavior is to revert to 'submit' if the value of type isn't valid (or blank), and otherwise return the type. |
| 20:11 | <Hixie> | SadEagle: unless WF2 says something else, i don't have any better spec yet. HTML5 will eventually cover this of course. Feel free to send mail to whatwg or public-html to remind me to fix this. |
| 20:12 | <SadEagle> | Hixie: well, WF2 says that invalid values of attributes should be ignored, which is basically what opera does, with the interpretation that type is returning the computed value.. |
| 20:42 | <othermaciej> | Hixie: I'm not sure tests 26 and 27 are a good idea, since it is an obscure case and the obvious ways preserving connected ancestors as well as descendants across GC would likely hurt DOM performance |
| 20:42 | <othermaciej> | (I guess we can see if it does for real though) |
| 20:47 | <othermaciej> | the expected behavior also could cause web apps to unintentionally hold down larger chunks of memory than they might expect (XHR, grab a single node without removing it, now you have extended the lifetime of the whole result document) |
| 20:48 | gsnedders | annevk pig |
| 20:49 | gsnedders | can't type |
| 20:49 | <gsnedders> | that was meant to be: /msg annevk ping |
| 20:59 | <Hixie> | othermaciej: i disagree, iv'e run into this kind of thing before, as have others, and i think it's clear that the DOM requires browsers to not be GCing accessible stuff |
| 21:01 | <othermaciej> | Hixie: I'm not sure it's particularly clear that the DOM requires anything on this |
| 21:02 | <Hixie> | i think you'd be hard-pressed to argue that the DOM allows you to just start setting parentNode to null whimsically |
| 21:03 | <othermaciej> | I don't think it's clear that it doesn't require it either - just not sure "clear" is a word that applies |
| 21:03 | <othermaciej> | it doesn't say anything about what operations not mentioned by the DOM spec may mutate the DOM |
| 21:04 | <othermaciej> | it's clearly not "none", since other specs require various things to mutate the DOM |
| 21:04 | <Hixie> | so you're saying that if IE started moving nodes around randomly in the DOM, it would be conforming? |
| 21:04 | <othermaciej> | I can see how a sensible person might not think "allocating memory" shouldn't be one of those operations |
| 21:04 | <othermaciej> | well, it would be a perverse interpretation of the spec |
| 21:05 | <othermaciej> | but I don't think the spec is "clear" on this |
| 21:05 | <Hixie> | there is no normative prose anywhere that allows the parentNode to change, as far as i can tell |
| 21:05 | <Hixie> | in this spec or any other |
| 21:06 | <Hixie> | and since parentNode is defined as returning the parent, and appendChild is defined as setting the parent, i don't see how you can have an interpretation that allows the parent to change |
| 21:06 | <othermaciej> | you mean, "as a result of garbage collection", or no prose allows the parentNode to change ever? |
| 21:06 | <Hixie> | i meant as a result of the browser randomly deciding to do it (e.g. as part of GC) |
| 21:07 | <Hixie> | if there was some text that could define _when_ exactly the parent would be lost, then ok |
| 21:07 | <Hixie> | but there isn't, and browsers are losing the parent in different ways because of it |
| 21:08 | <Hixie> | this is an interoperability nightmare that should be fixed by not dropping parts of the DOM on the floor |
| 21:08 | <Hixie> | it's not like you're actually saving memory intentionally on real sites because of this |
| 21:08 | <Hixie> | bbiab |
| 21:08 | <othermaciej> | it's true that no normative prose explicitly allows that, but nor does it explicitly forbid it |
| 21:08 | <annevk> | hsivonen, actually, we have magic behavior that approaches Gecko, just not for all public identifiers that Gecko recognizes, such as MathML |
| 21:08 | <Hixie> | othermaciej: yes it does! it says it should return the parent, and the parent was set by appendChild |
| 21:09 | <othermaciej> | Hixie: but clearly there's things not in the DOM Core spec which would require you to change the parent |
| 21:09 | <othermaciej> | even things that do not result from any DOM call (like parsing a document) |
| 21:09 | <Hixie> | othermaciej: and none of those things are happening here |
| 21:10 | <Hixie> | othermaciej: indeed _nothing_ is happening here, it's one piece of script |
| 21:10 | <othermaciej> | if script is executing then obviously something is happening |
| 21:11 | <Hixie> | othermaciej: i mrsn nothing is happening to the DOM, between the setting and the checking |
| 21:11 | <Hixie> | othermaciej: specs cannot say what must not happen, there's an infinite list of things that would have to be listed |
| 21:12 | <Hixie> | othermaciej: "browsers must not set attributes for no reason. browsers must not change the values of attributes for no reason. browsers must not..." |
| 21:12 | <Hixie> | othermaciej: if you go down this line of argument, then almost any bug can be explained as "well the spec doesn't say it _shouldn't_ happen on the 3rd of september at 2pm..." |
| 21:13 | <Hixie> | really must go, will be back shortly |
| 21:14 | <othermaciej> | I'm not sure if there's a justification in the text of DOM Core why html parsing can mutate the DOM but garbage collection (or occurence of a random date) is not, but I admit I can't think of how you would write it to make that clear |
| 21:16 | <othermaciej> | it can't just be "another standard says so" because I don't think the fact that insertAdjacentHTML mutates the DOM would be considered nonconforming to the DOM spec |
| 21:17 | <annevk> | HTML parsing defines what DOM mutations are to be performed |
| 21:17 | <othermaciej> | but it does indeed seem lame to assume that therefore anything is permitted |
| 21:17 | <annevk> | which is slightly different I'd say |
| 21:18 | <othermaciej> | well, I could write a document saying what DOM mutations may or may not be performed when garbage collecting, but I don't think that should retroactively change the meaning of DOM Core |
| 21:19 | <othermaciej> | and no spec defines what DOM mutations are to be performed when calling insertAdjacentHTML |
| 21:19 | <annevk> | no spec defines insertAdjacentHTML |
| 21:20 | <othermaciej> | that is true |
| 21:21 | <roc> | defining side effects that can happen during GC is nasty, because GC is very non-deterministic |
| 21:21 | <othermaciej> | there is a spec that defines ECMAScript garbage collection, namely ECMA-262 |
| 21:23 | <othermaciej> | but it's probably super vague about participation of host objects in GC |
| 21:24 | <annevk> | in the name of interop it's probably good that Acid3 includes things that really annoy each of the browser vendors |
| 21:24 | <othermaciej> | the logical model is that child references are strong references and parent references are weak references |
| 21:24 | <annevk> | the 0 bytes in the DOM issue bites us |
| 21:25 | <roc> | surely by now all browser vendors are too jaded to be annoyed by anything |
| 21:25 | <othermaciej> | yeah |
| 21:27 | <roc> | othermaciej: weak references suck too. especially when they're not explicit |
| 21:27 | <othermaciej> | actually I think it would be easy to make the specific acid3 test for this pass, the hard case would be preserving pieces of the DOM that have never been referenced from JS |
| 21:28 | <roc> | if (elem.parentNode) { elem.parentNode.setAttribute(...) } |
| 21:28 | <roc> | sure hope you didn't GC in there! |
| 21:29 | <roc> | at least with explicit weak refs like in Java, I have to declare the weak ref and then do a .get() to get the real reference, so I know something's up |
| 21:30 | <othermaciej> | I'm not saying it's great behavior, it just happens to be what we lovingly reverse-engineered from Mozilla as best we could |
| 21:31 | <roc> | oh, I didn't know there was a compatibility argument |
| 21:32 | <othermaciej> | I'm not sure compatibility cares that much one way or the other |
| 21:32 | <roc> | so why'd you reverse engineer it? |
| 21:32 | <othermaciej> | (about preserving parents in detached DOM fragments) |
| 21:32 | <othermaciej> | there was some site that required specific things about preserving DOM wrappers for descendants of detached DOM subtrees years ago |
| 21:33 | <othermaciej> | (actually worse than a site, I think it was an "enterprise" app's html interface) |
| 21:33 | <hsivonen> | doesn't the Web JS concurrency model guarantee that if you walk down the tree, you can walk back up in the same method without someone else mutating the tree in ways that make weak refs collectable? |
| 21:33 | <othermaciej> | so we tested what other browsers did for parents or siblings of detached trees across GC |
| 21:34 | <othermaciej> | hsivonen: if what you're getting at is that roc's example can't possibly fail if "eleme" is in the document tree then I think you are right |
| 21:35 | <roc> | yeah |
| 21:35 | <roc> | but if it isn't... |
| 21:35 | <hsivonen> | othermaciej: I meant roc's case, yes |
| 21:35 | <Hixie> | one thing to consider is that any argument that could be made to say test 23 is invalid could also be used to make test 99 invalid |
| 21:36 | <Hixie> | er, s/23/26/ |
| 21:36 | <Hixie> | and i really don't think you want test 99 to be invalid |
| 21:36 | <othermaciej> | if elem is not in the document tree then indeed weird things could happen in very speculative theory, but in fact won't, since there's nothing to trigger a GC at times that no temporary expression holds a reference |
| 21:36 | <hsivonen> | I still don't understand when parentNode is a weak ref to something for which there isn't a reciprocal hard ref |
| 21:36 | <hsivonen> | isn't parentNode nulled automatically if you detach a node from the tree? |
| 21:37 | <othermaciej> | if you removeChild, yes, it is nulled |
| 21:38 | <othermaciej> | the case where it is effectively a weak ref in WebKit (and was in Gecko and IE at least last time I tested) is if you have node A containing node B in document D, then you remove node A from the document, keep a reference to node B, and drop all your references to node A |
| 21:39 | <hsivonen> | hmm. interesting case |
| 21:39 | <Hixie> | the gc bg fails in gecko differently than webkit |
| 21:39 | <roc> | FWIW it still is weak in Gecko, we fail testcase 26, but we have enough infrastructure to fix it pretty easily post-FF3 |
| 21:39 | <Hixie> | in one the ndoes have to still be in the doc, in the other the nodes have to be outside of the dic |
| 21:39 | <othermaciej> | Hixie: test 99 is comedy gold |
| 21:40 | <Hixie> | indeed |
| 21:40 | <hsivonen> | I don't recall seeing any weak refs in Java DOM impls, but then weak refs wasn't what I was paying attention to |
| 21:40 | <Hixie> | hsivonen: you have to have weak refs if you're using ref counting, otherwise you'll never reach zero |
| 21:40 | <Hixie> | hsivonen: not so much an issue with other GC schemes |
| 21:41 | <roc> | you wouldn't expect to, Java has a real collector so cyclic structures were never a problem |
| 21:41 | <othermaciej> | Java DOM impls probably have strong refs both ways because Java DOMs would be written in pure Java |
| 21:41 | <hsivonen> | ah right. |
| 21:42 | <roc> | othermaciej: "if elem is not in the document tree then indeed weird things could happen in very speculative theory, but in fact won't" ... I'm not sure about that. I can easily imagine running unrelated windows in different threads sharing a common JS heap |
| 21:43 | <roc> | or the Gears thread stuff |
| 21:45 | <othermaciej> | roc: that's the kind of stuff that I considered to be in the "speculative theory" category (though Gears might potentially be less speculative) |
| 21:54 | <roc> | ok |
| 21:55 | <roc> | we can differ on how far-fetched it is |
| 21:57 | <roc> | I think the only thing preventing that case from occurring in Gecko + Gears today is where we place our GC safe points |
| 21:57 | <roc> | so I don't see it as all that far-fetched |
| 22:02 | <roc> | anyway, if that doesn't bother you, there's still the problem that inserting almost any code between the test of parentNode and the use of parentNode could allocate and trigger GC itself |
| 22:09 | <jruderman> | Hixie: does safari 3 fail acid3's text-shadow by having the shadow too close to the text? |
| 22:09 | <Hixie> | what maks you ask that? |
| 22:09 | <Hixie> | makes |
| 22:09 | <jruderman> | its shadow is close to the text "Acid3" than in the reference |
| 22:10 | <Hixie> | not on my machine... |
| 22:10 | <Hixie> | but yes, if it is not pixel perfect, then it has failed |
| 22:10 | <jruderman> | ok |
| 22:14 | <annevk> | are you testing for multiple shadows? |
| 22:14 | <annevk> | that will make Safari fail |
| 22:14 | <Hixie> | no, just the one |
| 22:14 | <Hixie> | multiple shadows are out in css3, iirc |
| 22:15 | <Hixie> | ok i found a way to make the shift-click thing work in 3/4 browsers, up from 2/4 |
| 22:15 | <Hixie> | still doesn't work in opera though |
| 22:15 | <annevk> | they're not out |
| 22:15 | <Hixie> | i thought they were out? |
| 22:15 | <annevk> | afaict they're not |
| 22:15 | <Hixie> | huh |
| 22:15 | <Hixie> | oh well |
| 22:15 | <Hixie> | they should be :- |
| 22:15 | <Hixie> | ) |
| 22:16 | <annevk> | if you use document.close() it might start working in Opera |
| 22:16 | <annevk> | i haven't actually tested that myself though |
| 22:17 | <annevk> | oh, you do that now |
| 22:17 | <Hixie> | well if you work out something that will make it work in opera, let me know |
| 22:17 | <Hixie> | in the meantime, i'm out of here |
| 22:17 | <Hixie> | later |
| 22:17 | <annevk> | use <pre> |
| 22:18 | <annevk> | thought that requires some additional effort to escape the rest |
| 23:15 | <zcorpan> | Hixie: i used document.write('<pre>Failed ' + (tests.length - score) + ' of ' + tests.length + ' tests.\n' + log.replace(/&/g,'&').replace(/</g,'<').replace('\0', '\\0') + '</pre>'); |
| 23:16 | <Hixie> | and that worked? |
| 23:16 | <Philip`> | zcorpan: Should be /\0/g, not '\0' |
| 23:20 | <Hixie> | well i've put that in |
| 23:20 | <Hixie> | no time to test it right now |
| 23:20 | <Hixie> | but let me know if it breaks anything if you try it before me |
| 23:22 | <zcorpan> | it worked for me, yeah |
| 23:22 | <zcorpan> | Philip`: that didn't work |
| 23:22 | <zcorpan> | there's only one \0 in the string anyway |
| 23:29 | <Philip`> | zcorpan: Hmm, how did it not work? |
| 23:30 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3E%0D%0Avar%20s%3D'a%5C0b%5C0c'%3B%0D%0Aw(s.replace(%2F%5C0%2Fg%2C%20'%5C%5C0'))%3B%0D%0A%3C%2Fscript%3E seems to be doing the right replacements... |
| 23:32 | <othermaciej> | I think I know an easy way to fix tests 26 and 27 in WebKit |
| 23:32 | <othermaciej> | still not sure if it is a good idea though |
| 23:35 | <SadEagle> | othermaciej: interesting (but may be not for the rest of the channel :-) ) |
| 23:36 | <othermaciej> | SadEagle: well, a few hours ago I was debating the test with people |
| 23:41 | <SadEagle> | othermaciej: well, I am curious about the potential solution, but this isn't the place for it |