| 00:18 | <Lachy_> | Hixie, do you have any estimate for when you expect to complete acid 3? |
| 00:18 | <Hixie> | nope |
| 00:19 | <Hixie> | still many tests to come up with |
| 00:19 | <Lachy_> | yeah, I've noticed. I had a look at it last week to see how well Opera does |
| 00:19 | <Lachy_> | it's not too bad, but it certainly fails a lot |
| 02:04 | <Philip`> | String attrib = attribs.getQName(i); |
| 02:04 | <Philip`> | if(attrib.startsWith("xmlns:")) { |
| 02:04 | <Philip`> | String space = attrib.substring(6); |
| 02:04 | <Philip`> | if(!space.equals("xsd")) { |
| 02:04 | <Philip`> | ... |
| 02:04 | <Philip`> | Could I be forgiven for thinking that's not the optimal way to process XML namespaces? |
| 02:13 | <othermaciej> | Philip`: that's some sad looking code |
| 02:18 | <Philip`> | As far as I can see, the code looks for <X3D xmlns:foo="[the X3D namespace URI]"> (where <X3D> has exactly qname "X3D", assuming it's not nested inside another <X3D>, and where foo != "xsd") and after that point it converts <foo:bar> into <bar> before its normal element processing |
| 02:19 | <Philip`> | which seems quite horrendously wrong |
| 02:35 | <othermaciej> | is xsd conventionally the prefix for something specific? |
| 02:35 | <othermaciej> | wondering why code would even check for that |
| 02:36 | <Philip`> | XML Schema |
| 02:37 | <Philip`> | The code does 'if(attrib.equals("xsd:noNamespaceSchemaLocation"))' to enable some extra processing or something |
| 02:39 | <Philip`> | The X3D world seems unpleasantly confused about namespaces and DTDs and schemas and whatnot |
| 07:01 | Hixie | makes extra sure to remove font metric dependencies in Ahem3 |
| 07:01 | <Hixie> | er |
| 07:01 | <Hixie> | Acid3 |
| 07:10 | <Hixie> | sigh, i still have so many tests to write and no idea what to do with them |
| 07:12 | <jruderman> | acid-style tests are overrated, imo. it's more meaningful to say "Browser X passes the entire test suite for Y" than "Browser X passes Acid N" |
| 07:16 | <Hixie> | i agree |
| 07:17 | <Hixie> | but try getting media attention for a test suite |
| 07:52 | <jruderman> | hehe |
| 08:06 | <Hixie> | i can't believe that with basically no effort on my part, IE fails every test |
| 08:07 | <Hixie> | i only targetted IE specifically for a couple of tests |
| 08:21 | MacDome | wonders which tests |
| 08:21 | <MacDome> | which test suite rather |
| 08:24 | <Hixie> | acid3 |
| 08:25 | <Hixie> | http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html |
| 08:25 | <Hixie> | if you have any suggestions of what to test, btw, do let me know |
| 08:25 | <MacDome> | yeah, Safari seems to fail pretty hard |
| 08:26 | <Hixie> | i'm trying to make safari and moz fail |
| 08:26 | <Hixie> | so i'm especially interested in bugs that affect those browsers |
| 08:26 | <MacDome> | Hixie: well you already found the strange JS parsing forgiveness bug in FF |
| 08:27 | <Hixie> | actually that's in the spec as far as i can tell |
| 08:27 | <MacDome> | the fact that somehow it didn't barf at "table." on a line by itself |
| 08:27 | <Hixie> | oh that |
| 08:27 | <Hixie> | yeah i need to add that back |
| 08:27 | <MacDome> | add that back!? |
| 08:27 | <MacDome> | it's a bug in FF AFAICT |
| 08:27 | <Hixie> | right |
| 08:27 | <Hixie> | need to catch it |
| 08:27 | <MacDome> | I guess. |
| 08:28 | <G0k> | but are bugs in the js parser really relevant? |
| 08:28 | <MacDome> | you'd have to load a separate JS file which you expected to fail to parse |
| 08:28 | <Hixie> | eval baby |
| 08:28 | <MacDome> | G0k: Acid2 had all sorts of irrelevant stuff :) |
| 08:28 | <Hixie> | G0k: yes, that's what i'm trying to test |
| 08:28 | <Hixie> | G0k: JS and DOM |
| 08:29 | <G0k> | mightn't you accidentally make the test incompatible with future ECMAScript version? |
| 08:29 | <G0k> | or extensions? |
| 08:29 | <Hixie> | maybe |
| 08:30 | <Hixie> | but i try to avoid things i know will happen |
| 08:31 | <G0k> | say so has anyone implemented the cross-document messaging thing? |
| 08:31 | <MacDome> | you're using all sorts of CSS3 which we don't have yet :) |
| 08:31 | <MacDome> | by "all sorts" I mean CSS3 selectors |
| 08:32 | <Hixie> | i'm only testing things that were in CR or better as of 2004 |
| 08:32 | <annevk> | G0k, Opera has |
| 08:32 | <Hixie> | so at least 3 year old technologies |
| 08:32 | <annevk> | but Hixie changed the spec to make our impl incompatible with what's in the spec... |
| 08:32 | <Hixie> | everyone should have had time to implement them |
| 08:33 | <G0k> | annevk: say i had an idea i wanted to discuss with you |
| 08:33 | <annevk> | sure |
| 08:33 | <G0k> | so the dom event stream thing |
| 08:33 | annevk | just woke up, has time :) |
| 08:33 | MacDome | wonders if Acid 3 will include SVG |
| 08:33 | <Hixie> | no, only DOM and JS stuff |
| 08:34 | <G0k> | so since there's been talk about throwing it out and most of the real suggested uses of the event stream stuff has been chat-style apps... |
| 08:34 | <G0k> | what about just specifying a DOM interface to XMPP or some other already existing messaging protocol? |
| 08:35 | <G0k> | xmpp would be particularly cool since it can be tunneled over HTTP and has a defined way of including XMLy stuff |
| 08:35 | <Hixie> | good lord that would be obscenely complicated |
| 08:35 | <Hixie> | XMPP over HTTP |
| 08:36 | <G0k> | it already exists.... |
| 08:36 | <Hixie> | one of hte requirements is that you can implement this from scratch in perl or python with 10-20 lines of code |
| 08:36 | <Hixie> | fully conforming |
| 08:36 | <G0k> | you can implement an SQL database in 10-20 lines of perl or python, fully conforming? |
| 08:37 | <Hixie> | by authors, i mean |
| 08:37 | <Hixie> | for author technologies |
| 08:37 | <Hixie> | author-side, that is |
| 08:37 | <MacDome> | yay for Acid3 crashing Safari :) |
| 08:38 | <Hixie> | really? |
| 08:38 | <Hixie> | i've been avoiding crash bugs |
| 08:38 | <krijnh> | Doesn't crash Safari 3 on Windows |
| 08:38 | <MacDome> | http://bugs.webkit.org/show_bug.cgi?id=16632 |
| 08:39 | <MacDome> | the inspector crashed |
| 08:39 | <G0k> | i mean there's already lots of perl/python XMPP libs |
| 08:39 | <MacDome> | by somehow causing us to go down an unsupported code path in our Image code |
| 08:39 | <G0k> | sending a message is easily a one liner |
| 08:40 | <annevk> | you are making the web dependent upon the XMPP protocol though, which does sound like overkill |
| 08:42 | <G0k> | i guess i just really really don't understand the point of inventing a new protocol here |
| 08:42 | <G0k> | there are so many network event style protocols....and instead we're taking the one that isn't (HTTP) and trying to beat it into submission |
| 08:43 | <annevk> | this one is over HTTP |
| 08:44 | <annevk> | and a lot simpler than XMPP |
| 08:45 | <G0k> | yeah but it has an installed base of very approximately zero, and basically no existing server-side APIs |
| 08:46 | <G0k> | i mean the beauty of it not "needing" an API because it's simple is cool |
| 08:46 | <G0k> | but how well is that going to scale? |
| 08:47 | <G0k> | other protocols are at least somewhat widely implemented |
| 08:48 | <annevk> | the main thing this needs for adoption is more client-side impl |
| 08:49 | <G0k> | but does it really do anything that, say, slow download XHR doesn't do already? |
| 08:51 | <annevk> | it requires less connections and is more convenient |
| 08:52 | <annevk> | you can probably implement this on top of an <iframe> too, but it's not pretty |
| 08:55 | <annevk> | hehe https://bugzilla.mozilla.org/show_bug.cgi?id=349255 |
| 08:56 | <Lachy> | Hixie, is acid3 affected at all if the user doesn't have Ahem installed? |
| 08:58 | <Lachy> | Hixie, you could use Ahem as a downloadable font, using @fontface stuff from CSS2 |
| 08:59 | <annevk> | that wasn't really a CR three years ago |
| 09:05 | <G0k> | ok well my final argument is that XMPP can be implemented as a javascript library for non-supported UAs: http://zeank.in-berlin.de/jsjac/ |
| 09:05 | <G0k> | which I think would be much harder for the event stream spec, at least as its written right now |
| 09:06 | <MacDome> | Hixie: it would be nice if Acid3 would do a bit of logging :) |
| 09:06 | <MacDome> | as in, if it displayed some sort of message for each failed test |
| 09:06 | <krijnh> | MacDome: Click the <h1> |
| 09:06 | <MacDome> | interesting |
| 09:07 | <G0k> | *it's |
| 09:08 | MacDome | is trying to figure out why buckets/result/intructions renders incorrect in WebKit |
| 09:13 | MacDome | thinks that somehow #result is supposed to be placing itself below <h1> and it's failign to do so correctly |
| 09:16 | <annevk> | hmm, Hixie changed Acid3! |
| 09:16 | <annevk> | Opera renders it worse and fails more |
| 09:20 | <MacDome> | Hixie, krijnh: yeah, but assertions with actual logs are much easier to debug. :) I could point you towards our decent set of assertion functions for our JS tests if you like |
| 09:20 | <G0k> | is test 1 really fair? i mean isn't i possible that a DOM exists for PNG images that we just don't know about yet? :) |
| 09:21 | <Lachy> | at least outputting the results to something other tan an alert would be more useful so the results could be copied and pasted |
| 09:22 | <annevk> | hmm, you can't copy alert text? |
| 09:24 | <annevk> | btw, I dropped the advanced CSS value interfaces from the CSSOM |
| 09:24 | <annevk> | CSS animations seem better suited than using ECMAScript, even with convenient APIs |
| 09:25 | <Lachy> | annevk, not in all browsers. Only in Opera. |
| 09:25 | <annevk> | bah |
| 09:25 | annevk | notes that the test URI is pretty clear about the state of the test, though |
| 09:26 | <krijnh> | You think so? :) |
| 09:27 | <MacDome> | annevk: yeah, just hoping to provide some early feedback :) |
| 09:27 | <annevk> | Hixie, may I suggest that instead of a text/html MIME type you give that test a "bogus" MIME type? |
| 09:27 | <annevk> | Hixie, such as Content-Type:bogus |
| 09:27 | <MacDome> | eeew |
| 09:28 | <annevk> | Hixie, because when we previously implemented proper support for MIME types and CSS loading it turned out Gecko didn't |
| 09:28 | <annevk> | and we broke a site |
| 09:29 | <G0k> | yeah i mean.....DOM doesn't define how to not parse other documents |
| 09:31 | <G0k> | whereas recognizing an invalid mime type is indeed a good UA behavior |
| 09:31 | <annevk> | I mean this test: <link rel="stylesheet" href="empty.css"><!-- text/html file (should be ignored, <h1> will go red if it isn't) --> |
| 09:32 | <G0k> | ohz |
| 09:33 | <G0k> | that is a tough one, since it's really bad behavior but i'm sure fixing that will break sites |
| 09:34 | <annevk> | well, Gecko does it in standards mode, but it only does it if the MIME type actually parses correctly |
| 09:34 | <annevk> | for some value of "correctly" |
| 09:34 | <annevk> | I believe it checks if "/" or "\" occurs in the MIME type string... |
| 09:34 | <G0k> | so if it were text/bogus, what would happen? |
| 09:34 | <annevk> | then it would not apply in Gecko |
| 09:35 | <annevk> | but if it was "bogus" it would |
| 09:35 | <G0k> | hm. and what if it were omited? |
| 09:35 | <G0k> | if that...even makes snese |
| 09:35 | <annevk> | if Content-Type is not there it would also apply |
| 09:35 | <annevk> | in Gecko |
| 09:36 | <annevk> | we decided not to implement that and just ignore 404 URIs |
| 09:36 | <annevk> | which was the main problem |
| 09:47 | <MacDome> | Hixie: I'm not even sure if you want me filing these... :) but in case you wanted to know: http://bugs.webkit.org/show_bug.cgi?id=16636 http://bugs.webkit.org/show_bug.cgi?id=16637 |
| 09:51 | <annevk> | MacDome, IE doesn't do proper DOM exceptions, Firefox does... |
| 09:52 | <MacDome> | annevk: if so, then it seems that that test is in disagreement with the DOM Core 2 spec |
| 09:52 | <annevk> | I think we emulated the e.SYNTAX_ERR stuff as well, but I'm not sure if it's supported by any spec |
| 09:55 | <MacDome> | annevk: and since we auto-gen our dom interfaces from the IDLs, we just match the official IDL in this case |
| 09:59 | <annevk> | I guess DOM Bindings / Web IDL should address this case |
| 09:59 | <annevk> | if it doesn't already |
| 10:54 | <annevk> | grmbl, getComputedStyle and various other CSSOM APIs are really quite crap in terms of documentation, implementation, etc. |
| 10:54 | <annevk> | DOM Level 2 Style is sort of like HTML4 |
| 10:55 | <Hixie> | Lachy: in theory acid3 doesn't depend on fonts at all |
| 11:00 | <Hixie> | annevk: i can't find a spec that defines how to handle Content-Type: bogus |
| 11:01 | <annevk> | Hixie, I can't find a spec that defines that when <link rel=stylesheet href=test> returns Content-Type:text/html it can't be parsed as CSS |
| 11:02 | <annevk> | also, I don't think it's acceptable for other browsers to fix that bug in a way that Firefox handles it |
| 11:03 | <Hixie> | HTTP section 7.2.1 paragraph 3 sentence 2 is what i'm basing the current test on |
| 11:04 | <Hixie> | Content-Type: text/html is a given type, so sniffing is not allowed |
| 11:04 | <Hixie> | but I can't see anything telling me whether Content-Type: bogus is a given type or not |
| 11:04 | <Hixie> | so I could argue it both ways |
| 11:04 | <Hixie> | so it can't go in an acid test |
| 11:05 | <annevk> | hmm, given that text Firefox behavior (apart form the quirky parsing) does make some sense, but still... |
| 11:05 | <annevk> | I rather ignore Content-Type algother and just honer 404 and such... |
| 11:07 | <Hixie> | oh i agree |
| 11:07 | <Hixie> | well |
| 11:08 | <Hixie> | i don't think we should ever treat a text/html file as a stylesheet |
| 11:08 | <Hixie> | (except in quirks) |
| 11:08 | <Hixie> | but i agree that bogus should be treated like text/html |
| 11:08 | <Hixie> | i just can't test it in the acid3 test |
| 11:09 | <annevk> | why would we want a quirks there? |
| 11:09 | <annevk> | it's not like we have any trouble doing this for <script> or <img> |
| 11:09 | <Hixie> | there are lots of css files sent as not-text/css last i checked |
| 11:10 | <Hixie> | i have a lot of trouble, i just can't see any way to save it |
| 11:10 | <Hixie> | with those two |
| 11:10 | <Hixie> | the problem with css is that text/html files often end up containing CSS inline, and if you apply that to the other doc, it usually isn't what you meant to do |
| 11:10 | <annevk> | the only cases of that in wild are 404 docs |
| 11:11 | <annevk> | which you'd ignore anyway |
| 11:12 | <annevk> | Content-Type:bogus was actually used a on somewhat important website which is why Opera doesn't adhere to MIME types for CSS files |
| 11:12 | <Hixie> | well, 404 pages aren't always 404 Not Found |
| 11:12 | <Hixie> | witness the webstandards.org site recently |
| 11:12 | <Hixie> | but yeah |
| 11:12 | <Hixie> | i'd love to change the rules here |
| 11:13 | <Hixie> | i just don't see that we can convince the httpwg to do so |
| 11:13 | <Hixie> | and under that regime, the test is correct |
| 11:13 | <annevk> | i believe the HTTP WG doesn't care about "error handling" |
| 11:14 | <Hixie> | that does seem to be the case |
| 11:14 | <annevk> | so if we decide that the case of <link rel=stylesheet> pointing to a non text/css file is non-conforming but nevertheless must be treated as text/css they are probably happy |
| 11:17 | <Hixie> | i doubt it very much |
| 11:17 | <Hixie> | since that's not necessarily an error |
| 11:17 | <Hixie> | xslt, e.g. |
| 11:18 | <annevk> | surely what's conforming for <link rel=stylesheet> is not up to them? |
| 11:18 | <annevk> | (this is probably stretching it) |
| 11:21 | <Hixie> | it's not a matter of <link rel> |
| 11:21 | <Hixie> | <link rel> is just one of several ways of including a stylesheet |
| 11:21 | <Hixie> | including @import, Link:, etc |
| 11:21 | <Hixie> | as well as just direct access e.g. by an editor |
| 11:59 | <Hixie> | anyone got IE? |
| 11:59 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3A%3Cscript%3Eif%20(true)%20function%20a()%20{%20document.write(%27FAIL%27)%20}%20a()%3B%3C%2Fscript%3E |
| 11:59 | <Hixie> | does it say FAIL? |
| 12:01 | <annevk> | yes |
| 12:02 | <annevk> | well, ":FAIL" |
| 12:04 | <Lachy> | Hixie, the test looks wrong to me. Why shouldn't it print ":FAIL"? |
| 12:04 | <Hixie> | ES3 section 12.4 |
| 12:04 | <Hixie> | and 12.5 |
| 12:04 | <annevk> | does that say you can't define functions within if() statements or something? |
| 12:05 | <Hixie> | somewhat |
| 12:05 | <Lachy> | is it because function a() is out of scope when it's invoked? |
| 12:06 | <annevk> | I don't think if/else blocks create a new scope |
| 12:07 | <othermaciej> | Hixie: I think printing FAIL is correct behavior there |
| 12:08 | <Hixie> | othermaciej: it's not, per spec. i think the spec should change though. (webkit is the only compliant browser at the moment) |
| 12:09 | <othermaciej> | actually maybe not, due to lack of semicolon |
| 12:09 | <Lachy> | WebKit does something weird. It doesn't print "FAIL" for that test, but If you include the braces around the if block, then it does. |
| 12:10 | <othermaciej> | this should certainly print FAIL: |
| 12:10 | <othermaciej> | <!DOCTYPE html>:<script>if (true) { function a() { document.write('FAIL') }}; a();</script> |
| 12:10 | <othermaciej> | function declarations are processed before execution |
| 12:10 | <Hixie> | Lachy: that's correct per spec |
| 12:10 | <othermaciej> | and have either function or global scope |
| 12:10 | <othermaciej> | is the first version a syntax error? |
| 12:10 | <Hixie> | yes, if you add braces it should parse |
| 12:10 | <Hixie> | without braces it's a syntax error per spec |
| 12:11 | <othermaciej> | ah, I see |
| 12:11 | <webben> | because of "an ExpressionStatement cannot start with the function keyword because that might make it ambiguous with a FunctionDeclaration." ? |
| 12:11 | <othermaciej> | an if statement's condition is a statement, not a source element |
| 12:11 | <othermaciej> | a block is a valid statement |
| 12:12 | <othermaciej> | but a function declaration is not |
| 12:12 | <othermaciej> | it's a source element, but not a statement |
| 12:12 | <Lachy> | oh, ok. now I understand |
| 12:12 | <Lachy> | so only webkit passes |
| 12:12 | <othermaciej> | (and it's not an expression statement either, because that is disallowed) |
| 12:12 | <othermaciej> | good night all |
| 12:27 | <Dashiva> | Hixie: How does adding braces change it? The contents of a BlockStatement are Statements, just like the tail of an if |
| 12:29 | <Hixie> | hm, you are correct |
| 12:31 | <webben> | But without the brackets it's an expressionstatement not a block isn't it? |
| 12:31 | <Dashiva> | No, it's invalid syntax in both cases |
| 12:32 | <Dashiva> | ExpressionStatement can't start with "function", and nothing else matches |
| 12:33 | <webben> | sorry ... yes, I mean with brackets it would be a block. |
| 12:33 | <Dashiva> | yeah |
| 12:34 | <webben> | and http://bclary.com/2004/11/07/#a-12.1 doesn't say blocks can't start with function declarations |
| 12:34 | <Dashiva> | It says a Block contains Statement, and that's the same place we were in with the if |
| 12:34 | <Dashiva> | (well, StatementList) |
| 12:35 | <webben> | hmm |
| 12:36 | <Dashiva> | It's not attractive code, though. As macie mentioned, function declarations are processed first, so it's either a) always add the function, regardless of if test failing or b) break with es3 behavior (this is more like let x = function(){}) |
| 12:37 | <Hixie> | yeah what's sad is that the spec doesn't match realitty |
| 12:37 | <webben> | so when http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:function refers to function as a statement, is that a misnomer? |
| 12:37 | <Hixie> | oh well |
| 12:37 | <Dashiva> | webben: Yes and no |
| 12:37 | <Hixie> | if any of you come up with anything for me to test, do let me know |
| 12:38 | <Hixie> | nn |
| 12:38 | <Dashiva> | nn |
| 12:38 | <Dashiva> | webben: In spec terms, it's a SourceElement, which can be either a Statement or a function decl. But outside grammar parsing, calling it a statement makes for better text |
| 12:39 | <Dashiva> | I'm curious what WebKit does, though. If they crash on the function statement, or on the function invocation |
| 12:51 | <webben> | Dashiva: If it /can/ be a Statement, then can't it be the first statement in a block's statement list? |
| 12:52 | <Dashiva> | But it isn't a Statement in the grammar sense of the word |
| 12:53 | <webben> | ah I see |
| 13:15 | <othermaciej> | Dashiva: if (true) function a() {} is a parse error in webkit, so it fails at the declaration, not the invocation |
| 13:17 | <othermaciej> | webkit accepts SourceElements in many places that technically require a StatementList, probably for compatibility reasons |
| 13:19 | <annevk> | hmm, is that fixed in ECMA4? |
| 13:24 | <othermaciej> | I don't know |
| 13:25 | <othermaciej> | I can't find enough of a spec draft for ES4 to tell |
| 13:25 | <othermaciej> | I guess there is a grammar published so you can check that |
| 13:26 | <Dashiva> | The spec is still fragmented and wiki-dead and all that, I think |
| 13:26 | <othermaciej> | it doesn't really exist in a readable form; makes me wonder how they plan to finalize it next year |
| 13:27 | <annevk> | hmm |
| 13:27 | <annevk> | crap, WebKit implemented getPropertyCSSValue |
| 13:27 | <annevk> | I hope that's an internal API only |
| 13:27 | <othermaciej> | someone sent me a link to an semi-officiall grammar though |
| 13:28 | <othermaciej> | ./css/CSSStyleDeclaration.idl: CSSValue getPropertyCSSValue(in DOMString propertyName); |
| 13:28 | <othermaciej> | nope |
| 13:28 | <othermaciej> | (is getPropertyCSSValue a bad thing?) |
| 13:28 | <annevk> | http://www.w3.org/mid/Pine.LNX.4.05.10310302134070.1173-100000⊙lif |
| 13:29 | <othermaciej> | grammar here: http://www.ecmascript.org/es4/spec/grammar.pdf |
| 13:31 | <othermaciej> | annevk: is WebKit the only engine to implement the old CSSOM? |
| 13:31 | <othermaciej> | (that seems unlikely) |
| 13:32 | <annevk> | maybe Gecko has some bits of it |
| 13:32 | <othermaciej> | Mozilla appears to have getPropertyCSSValue |
| 13:32 | <othermaciej> | and the CSSValue interface |
| 13:33 | <othermaciej> | (well, from searching their source code it seems that way) |
| 13:34 | <annevk> | In Opera the method throws a NOT_IMPLEMENTED_ERR and in Gecko it always returns null |
| 13:34 | <annevk> | it won't be part of the next CSSOM if it's up to me |
| 13:35 | <othermaciej> | div id="foo" style="color: red">x</div> |
| 13:35 | <othermaciej> | <script> |
| 13:35 | <othermaciej> | var foo = document.getElementById("foo"); |
| 13:35 | <othermaciej> | alert(document.defaultView.getComputedStyle(foo, "").getPropertyCSSValue("color")); |
| 13:35 | <othermaciej> | </script> |
| 13:35 | <othermaciej> | does what I expect in Firefox 2 |
| 13:36 | <othermaciej> | (and Firefox 3 Beta 1) |
| 13:37 | <othermaciej> | it's pretty likely some content depends on it, even more so that some content depends on the CSSValue interface and related interfaces |
| 13:38 | <othermaciej> | (it does return null in Firefox on foo.style though, which is certainly weird) |
| 13:39 | <annevk> | we haven't had a single bug report on not supporting it |
| 13:39 | <annevk> | and IE doesn't support it |
| 13:39 | <othermaciej> | does IE support getComputedStyle()? |
| 13:39 | <annevk> | fair point |
| 13:40 | <othermaciej> | we have had bug reports relating to getComputedStyle before (due to the fact that document.defaultView was originally not the same document as window) |
| 13:40 | <annevk> | oh, yeah, pages rely on getComputedStyle |
| 13:41 | <annevk> | i guess I can file a bug on WebKit and Gecko and see what happens |
| 13:41 | <othermaciej> | to remove getPropertyCSSValue? |
| 13:41 | <annevk> | yeah |
| 13:42 | <annevk> | is CSSStyleDeclaration implemented on various objects btw that behave slightly different? |
| 13:42 | <othermaciej> | what's the reason to remove it? |
| 13:42 | <annevk> | that it has been obsoleted by the CSS WG |
| 13:42 | <othermaciej> | that's not a good reason |
| 13:42 | <annevk> | and that the API is awkward for the Web |
| 13:42 | <othermaciej> | that one, sadly, isn't either |
| 13:43 | <annevk> | if anything we want something like .style.width.px |
| 13:43 | <othermaciej> | neither of those is worth breaking content, even if it's Apple-only content like Dashboard widgets |
| 13:43 | <annevk> | bloat would be another reason |
| 13:43 | <othermaciej> | I'd certainly be open to having a nicer CSS API in addition |
| 13:44 | <othermaciej> | the CSSValue part of the API specifically is not a lot of code |
| 13:44 | <annevk> | i doubt anything relies on it, but you could be right |
| 13:44 | <othermaciej> | getComputedStyle is the hard part, if anything |
| 13:44 | <othermaciej> | (and CSS parsing) |
| 13:45 | <annevk> | CSS parsing is madness |
| 13:45 | <othermaciej> | it's better than HTML parsing :-) |
| 13:45 | annevk | always thought CSS was a simple language |
| 13:45 | <othermaciej> | or JavaScript parsing |
| 13:46 | <annevk> | b\000061ckground |
| 13:46 | <annevk> | or b\061\063kground |
| 13:48 | <othermaciej> | escape sequences aren't particularly complicated to parse |
| 13:48 | <othermaciej> | (all handled by the lexer) |
| 13:49 | <annevk> | true |
| 13:50 | <annevk> | i probably don't get enough of the CSS grammar yet |
| 13:51 | <annevk> | it's not entirely clear to me what the intersection is of the appendix and the core grammar etc. |
| 13:54 | <annevk> | Mozilla is not working anymore on getPropertyCSSValue per that CSS WG message |
| 13:54 | <annevk> | so that's encouraging |
| 13:54 | <annevk> | (info from bugs in bugzilla) |
| 13:55 | <othermaciej> | it looks like ES4 does allow function definitions in blocks, but not in places that expect a single statement (as far as I can tell from the grammar) |
| 13:56 | <othermaciej> | (side note: we appear to have the UnknownRule interface too, but I dunno if that gets used by anything) |
| 13:58 | <annevk> | UknownRule is incompatible with the CSS parser so that sounds interesting :) |
| 13:59 | <othermaciej> | I think the interface exists but nothing actually ever makes one |
| 14:02 | <annevk> | to get back to my earlier question, to properly define CSSStyleDeclaration would I have to define two separate implementations of it? |
| 14:02 | <annevk> | one that is readonly and one that is read-write |
| 14:02 | <annevk> | and maybe there's also a computed / non-computed distinction? |
| 14:02 | <othermaciej> | probably, yes |
| 14:03 | <othermaciej> | we internally have CSSSMutableStyleDeclaration and CSSComputedStyleDeclaration classes |
| 14:04 | <othermaciej> | they both implement the CSSStyleDeclaration interface but the Computed version either ignores or throws on all attempts at mutation (can't remember which) |
| 14:04 | <annevk> | Mozilla actually exposes the latter as interface name |
| 14:04 | <annevk> | it throws |
| 14:04 | annevk | read bits of the source |
| 14:05 | <annevk> | one of the larger problems with CSSValue and any kind of dedicated CSS API is that it's hard to make them scale |
| 14:06 | <othermaciej> | but yeah, it would be nicer if there was a read-write interface inheriting from a read-only interface, not sure what the consequences of changing now would be |
| 14:06 | <annevk> | at some point background-image could have returned CSSUrlValue |
| 14:06 | <othermaciej> | there's probably not much risk of someone depending on existence of a method that always throws |
| 14:06 | <annevk> | now it needs to return a list |
| 14:07 | <annevk> | can I actually do that in IDL? |
| 14:07 | <annevk> | inherit and modify members |
| 14:08 | <annevk> | another option would to have separate interfaces where you simply don't have modifying stuff on one of them... |
| 14:08 | <othermaciej> | you can inherit and add members |
| 14:08 | <gsnedders> | annevk: peh! anyone on the HTTPbis mailing list is a member of the WG! Some people in the WG care about error handling :P |
| 14:08 | <othermaciej> | but I dunno if it's praactically changeable at this point |
| 14:09 | <othermaciej> | probably easier to just spec computed styles as implementing the same interface but throwing on mutation |
| 14:10 | <gsnedders> | annevk: SimplePie (another feed parser) has similar behaviour to UFP for text/xml as of the latest dev copy |
| 14:11 | <gsnedders> | it also uses content-type sniffing based on HTML 5. |
| 14:11 | <gsnedders> | Only real breakage is text/plain feeds |
| 14:12 | <annevk> | othermaciej, yeah ok, it doesn't really matter either way I suppose |
| 14:12 | <gsnedders> | The other breakages have mainly been impl bugs |
| 14:14 | gsnedders | wonders how you're meant to deal with application/octet-stream |
| 14:30 | <annevk> | the other annoying thing is that getComputedStyle does not return the computed style |
| 14:30 | <annevk> | <body style=width:20em> the computed style of 'width' is not 320px afaict |
| 14:32 | <annevk> | or without 'width' it should be auto |
| 14:32 | <annevk> | however, I get back 1452px instead |
| 14:33 | <annevk> | currentStyle in IE is much closer to giving back the computed style it seems |
| 16:21 | <annevk> | bah, updates to <style>.media.mediaText and presumably similar stuff has no effect |
| 16:22 | <annevk> | (for a normal persistent style sheet) |
| 16:23 | <annevk> | (haven't tested Safari) |
| 16:24 | <annevk> | actually, IE7 does do updates but it does not have MediaList object... |
| 16:24 | <annevk> | in IE7 <style>.sheet.media is a simple string |
| 16:25 | <annevk> | (<style>.media above should've been <style>.sheet.media as well) |
| 16:45 | <annevk> | actually, Opera seems to do dynamic updates too, but not always |
| 16:46 | <annevk> | and <style>.media is not updated after changes from <style>.sheet.media |