| 00:01 | <virtuelv> | nm, /me reads backlog |
| 00:01 | <virtuelv> | I have some Koss Spark Plugs lying around |
| 00:01 | <virtuelv> | they're pretty horrible, and I've just always ended up using my Grados instead |
| 00:01 | <virtuelv> | which are everything but in-ear |
| 00:01 | <jgraham> | virtuelv: If you have any insight I'm still very much interested |
| 00:02 | <virtuelv> | jgraham: sound-quality-wise, they are supposed to be among the better in-ear solutions you can get |
| 00:02 | <jgraham> | Which ones? |
| 00:02 | <virtuelv> | problem is, they have an associated price tag |
| 00:02 | <virtuelv> | jgraham: shure in general |
| 00:02 | <virtuelv> | I only know shure from microphones |
| 00:03 | <virtuelv> | (the SM58 is a fantastic piece of kit, but that's beside the point) |
| 00:04 | <jgraham> | My audiophile credentials are severely limited so I wonder how much sound quality issues will affect me |
| 00:05 | <virtuelv> | jgraham: while there is a lot of bollock science in audiophile circles, they at least have understood the quality of not getting tired listening to headphones |
| 00:06 | <virtuelv> | my golden rule is something like this: Don't buy audio equipment by mail order, unless you have pre-listened to them extensively |
| 00:06 | <virtuelv> | example: I recently (a week ago), got rid of my old DVD/CD player, and bought one with a darker sound |
| 00:07 | <virtuelv> | less impressive at first, but it allows me to listen for more extensive periods of time |
| 00:07 | <virtuelv> | (in this regard, ipods suck, they cause listening fatigue) |
| 00:07 | <virtuelv> | so it's not really about being "audiophile", it's about "which pair of headphones would I want to use for eight hours on end" |
| 00:08 | <gavin> | I don't think I would ever want to use headphones for 8 hours on end regardless of how comfortable they were :) |
| 00:09 | <jgraham> | virtuelv: whilst that sounds eminently sensible, I have difficulty imaganing where I could go to try on in ear headphones |
| 00:09 | <virtuelv> | jgraham: your nearest hi-fi-pusher |
| 00:09 | <virtuelv> | and by that, I mean people who are serious about it |
| 00:09 | <virtuelv> | fwiw, http://www.stereophile.com/headphones/504shure/ |
| 00:11 | <virtuelv> | you just have to get over the possible trauma of having someone else's earwax shared |
| 00:13 | <jgraham> | I guess it's worth a try. |
| 00:13 | <virtuelv> | jgraham: is there any specific reason for going with in-ear? |
| 00:15 | <jgraham> | virtuelv: They seem to be effective at cutting down background noise. At least that's the impression I get. |
| 00:16 | <virtuelv> | jgraham: yes, but so are active solutions, like Sennheiser PXC 450 |
| 00:16 | <virtuelv> | looks ridiculous walking around town, but on flights and similar, they are guaranteed to be much more comfortable |
| 00:16 | <virtuelv> | http://www.sennheiser.com/nl/icm_nl.nsf/root/500643 |
| 00:18 | <virtuelv> | 350's are slightly cheaper, but I haven't read any reviews yet |
| 00:18 | <jgraham> | virtuelv: There seem to be to problems with the active noise cancelling things - they are comparatively expensive for the same level of background reduction, and the active cancelling /seems/ to be more low-frequency-specific |
| 00:18 | <jgraham> | (I was originally looking at the active noise canceling ones) |
| 00:21 | jgraham | -> bed |
| 00:21 | <virtuelv> | as long as you are aware of the disadvantages, though |
| 00:21 | <virtuelv> | listening fatigue being one |
| 00:22 | <virtuelv> | it's about optimizing the solution for the use-case |
| 04:29 | <doublec> | <erg> git pull http://littledan.onigirihouse.com/factor.git |
| 04:29 | <doublec> | you can also: git pull git://onigirihouse.com/git/littledan.git |
| 04:29 | <doublec> | it's faster |
| 04:37 | <doublec> | oops, wrong channel |
| 04:52 | <Hixie> | 53 more tests to write |
| 04:53 | <Hixie> | anyone got any tests they know that safari, mozilla, or opera fail? |
| 04:57 | <G0k> | http://www.css3.info/selectors-test/test.html fails some in safari |
| 04:57 | <Hixie> | wow, sweet test suite |
| 04:57 | <G0k> | and firefox |
| 04:58 | <Hixie> | i really want primarily dom and js tests, but these will definitely be useful |
| 05:01 | <G0k> | by js testing, do you mean like testing compliance with the ECMAScript spec? |
| 05:04 | <G0k> | oh and of course http://bugs.webkit.org/attachment.cgi?id=9554 |
| 05:04 | <G0k> | which i think only opera handles nicely right now |
| 05:04 | <Hixie> | yes |
| 05:05 | <Hixie> | JS spec and DOM specs |
| 05:07 | <G0k> | i actually had a question for you about the same-origin policy |
| 05:07 | <G0k> | should you be able enumerate variables across domains? |
| 05:07 | <Hixie> | webkit gets http://bugs.webkit.org/attachment.cgi?id=9554 correct |
| 05:08 | <Hixie> | (though i initially was confused sicne red and yellow are typically fail colours :-) ) |
| 05:08 | <Hixie> | no |
| 05:08 | <Hixie> | or wait |
| 05:08 | <Hixie> | what do you mean? |
| 05:08 | <G0k> | hixie: they re-broke it in the latest nightly |
| 05:08 | <G0k> | ok, so |
| 05:08 | <G0k> | well actually, test case: http://bugs.webkit.org/attachment.cgi?id=9554 |
| 05:08 | <G0k> | erps |
| 05:08 | <G0k> | http://mapseekret.com/staticmedia/document_a.html |
| 05:08 | <G0k> | that |
| 05:09 | <G0k> | basically, should a document from one domain be able to use a for..in loop to find the names of the variables in the window from another domain? |
| 05:09 | <G0k> | opera and firefox don't let you |
| 05:09 | <G0k> | safari currently does |
| 05:09 | <G0k> | safari does stop you from getting the actually values, but not the variable names |
| 05:09 | <G0k> | well actually, i put it better in this bug: http://bugs.webkit.org/show_bug.cgi?id=16387 |
| 05:10 | <G0k> | but is that actually a same-origin violation? |
| 05:10 | <Hixie> | i thought i was using the latest nightly |
| 05:10 | <Hixie> | the second test case does indeed fail |
| 05:10 | Hixie | takes note of it |
| 05:11 | <G0k> | well alright the latest one i just compiled is a little wonkey in general |
| 05:11 | <Hixie> | waiiit |
| 05:11 | <Hixie> | i thought 9554 was a different attachment |
| 05:11 | <Hixie> | but it's the same one |
| 05:11 | <Hixie> | and it failed once and succeeded the other time |
| 05:11 | <Hixie> | wtf |
| 05:11 | <G0k> | are you sure you're not mixing up builds? |
| 05:11 | <Hixie> | re the same-origin thing, yes that's a security bug |
| 05:11 | <Hixie> | no, only one build |
| 05:12 | <G0k> | kdoke |
| 05:18 | MacDome | is surprsied we'd break an existing test |
| 05:18 | <MacDome> | would suggest that the test never got landed |
| 05:21 | <Hixie> | it seems intermittent |
| 05:21 | <MacDome> | http://build.webkit.org/waterfall is generally quite good about catching regressions |
| 06:57 | <weinig> | Hixie: http://bugs.webkit.org/show_bug.cgi?id=16387 :) |
| 06:57 | <weinig> | Hixie: that's what you get for commenting in a bug that I should have fixed already |
| 06:57 | <G0k> | damnit, my test suggestion is foiled |
| 06:58 | <G0k> | i should get hixie to CC all my bugs. :) |
| 08:11 | <Hixie> | can anyone think of a way of detecting if an element is matching a selector without using some 2004-or-earlier standards-based mechanism other than getComputedStyle()? |
| 08:14 | <MacDomeSleep> | Hixie: well, in IE there is _hasLayout :) |
| 08:14 | <MacDomeSleep> | certain styles would certainly change the DOM behavior |
| 08:14 | <Hixie> | maybe you don't fully understand "2004-or-earlier standards-based mechanism" :-P |
| 08:14 | <Hixie> | er wait |
| 08:14 | <Hixie> | i misspoke |
| 08:14 | <Hixie> | i meant to ask "can anyone think of a way of detecting if an element is matching a selector using some 2004-or-earlier standards-based mechanism other than getComputedStyle()?" |
| 08:15 | <Hixie> | the without was a misedit |
| 08:15 | <Hixie> | appologies |
| 08:15 | <MacDomeSleep> | yeah,I understood the firstime |
| 08:15 | <MacDomeSleep> | Imust have read betweent he lines |
| 08:16 | <MacDomeSleep> | Hixie: I would use a style which I knew changed dom behavior |
| 08:16 | <MacDomeSleep> | things like height |
| 08:16 | <MacDomeSleep> | display |
| 08:16 | <MacDomeSleep> | etc. |
| 08:17 | <Hixie> | right but how can i tell the style has changed, without using getComputedStyle? |
| 08:17 | <Hixie> | and still following the specs? |
| 08:17 | <Hixie> | (from script) |
| 08:18 | <MacDomeSleep> | if you set a height with the selector, wouldn't element.height change? |
| 08:18 | <Hixie> | element.innerHeight isn't standards-based |
| 08:19 | <MacDomeSleep> | http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/dom/Element.idl |
| 08:20 | <MacDomeSleep> | I can't think of a standards based method |
| 08:21 | <MacDomeSleep> | Hixie: since all the useful properties on element in that file, are non-standards based |
| 08:21 | <Hixie> | bummer |
| 08:21 | <Hixie> | i don't like breaking IE on a whole series of tests just for not having getComputedStyle |
| 08:23 | <MacDomeSleep> | wasn't getComputedStyle back in like 2000? |
| 08:23 | <Hixie> | yeah |
| 08:23 | <Hixie> | i'm totally using it at least once |
| 08:23 | <MacDomeSleep> | http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-ViewCSS |
| 08:23 | <Hixie> | just feels a bit over the top to totally screw IE on 16 tests in a row just for one bug |
| 08:24 | <Hixie> | oh well |
| 08:24 | <Hixie> | i'm not really targetting IE anyway |
| 08:24 | <MacDomeSleep> | it sorta sucks that IE screws developers over based on one bug :) |
| 08:24 | <MacDomeSleep> | or rather... one thousand bugs |
| 08:24 | <Hixie> | me giggles as he discovers his selectorTest() function works |
| 08:24 | <Hixie> | ^/ |
| 08:27 | <Hixie> | ok this is awesome |
| 08:27 | <Hixie> | i have a little framework for selectors tests |
| 08:27 | <Hixie> | now i can go crazy! |
| 08:27 | <Hixie> | mwuhahahaha |
| 08:27 | <G0k> | he's a mad man |
| 08:27 | <G0k> | someone sedate him |
| 08:28 | MacDome | flails wildly in Hixie's direction, utterly failing. |
| 08:28 | MacDome | ends up sedating himself |
| 08:28 | <Hixie> | heh |
| 11:28 | <Philip`> | Hixie: If you set an img width with CSS, then get the width DOM attribute and test if it equals the width set with CSS (to see if the selector matched), is that standards-based or is it just an undocumented feature? |
| 11:29 | <anne-mac> | standards-based per HTML5 |
| 11:39 | <hsivonen> | IIRC, what the getComputedStyle spec says about returned units is utterly bogus |
| 11:39 | <anne-mac> | that's different from the width DOM attribute of <img> though |
| 11:39 | <hsivonen> | so if you want to build a test that is both Good for the Web and adheres to specs as of 2004, it might be hard |
| 11:40 | <anne-mac> | oh, like that |
| 11:40 | <anne-mac> | it's also pretty vague, so... |
| 11:40 | anne-mac | hopes to fix getComputedStyle in due course |
| 11:41 | <hsivonen> | "The CSSStyleDeclaration is read-only and contains only absolute values." |
| 11:41 | <hsivonen> | my recollection was that it said absolute lengths |
| 11:41 | <hsivonen> | if absolute values means something else, please disregard my comment above |
| 11:42 | <hsivonen> | IIRC, the sensible approach is to normalize lengths to px which CSS calls "relative" not "absolute" |
| 11:44 | <anne-mac> | per CSS the computed value for border-top-width is the absolute length... |
| 11:44 | <anne-mac> | so I guess that's what getComputedStyle means too |
| 11:44 | <anne-mac> | it's not what getComputedStyle does though |
| 13:54 | <webben> | hsivonen: btw validator (local build) is giving me a "Caused by: org.xml.sax.SAXException: Malformed spec: Expected dt to be context dt but it was not." error whenever I run it, in case you know what that's about |
| 14:31 | <hsivonen> | webben: try starting with --html5load=http://about.validator.nu/spec.html |
| 14:31 | <hsivonen> | webben: evidently, I need to bundle a known-good copy of the spec with the software |
| 14:32 | <hsivonen> | webben: sorry about the inconvenience |
| 14:32 | <webben_> | python build/build.py run --html5load=http://about.validator.nu/spec.html gives me the same error. |
| 14:33 | <hsivonen> | Philip`: I pushed out a vastly updated http://about.validator.nu/ |
| 14:33 | <hsivonen> | webben: you need python build/build.py --html5load=http://about.validator.nu/spec.html run |
| 14:33 | <anne-mac> | hsivonen, you missed the other error Philip` pointed out |
| 14:33 | <anne-mac> | "but only it if the DTD" |
| 14:34 | <hsivonen> | anne-mac: thanks |
| 14:34 | <webben_> | hsivonen: Ah great, that works. Thank you. :) |
| 14:34 | <hsivonen> | anne-mac: fixed |
| 15:35 | <zcorpan> | div[align=left] { |
| 15:35 | <zcorpan> | } |
| 15:35 | <zcorpan> | <div align='LEFT'></div> |
| 15:35 | <zcorpan> | The CSS selector should match the HTML fragment because the value of the align attribute should be case insensitive in a HTML document |
| 15:35 | <zcorpan> | -- http://www.css3.info/selectors-test/test-attribute-equal.html#attribute-equal |
| 15:35 | <zcorpan> | hmm |
| 15:36 | <zcorpan> | html5 needs to define this |
| 15:36 | <zcorpan> | Hixie: ^ |
| 15:38 | zcorpan | would like to run the selectors tests in quirks mode |
| 15:41 | <zcorpan> | bah, it doesn't test case sensitivity of .class |
| 15:48 | <dbaron> | zcorpan, There's a list of which attributes count for that in CSS2.1, I think. |
| 15:48 | <dbaron> | zcorpan, although actually it's defined in HTML4 as well... |
| 15:49 | <zcorpan> | i think html5 needs to define it |
| 15:49 | <zcorpan> | also for xhtml5 |
| 15:50 | <dbaron> | hrm, actually not -- we just implement using the [CI] / [CS] in HTML4 |
| 15:51 | <zcorpan> | does that mean ascii case insensitive or unicode case insensitive? |
| 15:52 | <zcorpan> | usemap="" is unicode case insensitive, iirc. some others are ascii case insensitive. although i haven't tested their case sensitivity wrt selectors |
| 15:53 | <hsivonen> | zcorpan: why is usemap case-insensitive in any way? |
| 15:54 | <zcorpan> | hsivonen: dunno |
| 15:54 | <gsnedders> | hsivonen: aren't @id normally case-insensitive? |
| 15:54 | <zcorpan> | usemap points to name="" |
| 15:54 | <hsivonen> | zcorpan: have you tested selector case-insensitivity of with enumerated-value attributes in XHTML? |
| 15:54 | <zcorpan> | (per html4 anyway) |
| 15:54 | <zcorpan> | hsivonen: no |
| 15:55 | <hsivonen> | gsnedders: id is supposed to be case-sensitive |
| 15:55 | <gsnedders> | hsivonen: and HTML is supposed to be SGML. What things are supposed to mean is irrelevant :) |
| 15:55 | <hsivonen> | zcorpan: is usemap case-insensitive only when comparing againts name or also with id? |
| 15:56 | <zcorpan> | i guess i'll make a thorough test suite for this in due course |
| 15:56 | <zcorpan> | hsivonen: in ie and opera it's insensitive for both |
| 15:56 | <zcorpan> | hsivonen: in saf and moz it's insensitive for name (html only) and sensitive for id (xhtml only) |
| 15:57 | <hsivonen> | I currently implement usemap checking using code-point-for-code-point equality |
| 15:58 | <hsivonen> | zcorpan: fun |
| 15:58 | <hsivonen> | zcorpan: but WebKit supports name in XHTML, too, doesn't it? |
| 15:59 | <gsnedders> | hsivonen: yeah |
| 17:25 | <zcorpan> | hsivonen: not last time i tested, iirc |
| 17:30 | <zcorpan> | hsivonen: "If you the automatic choice of parser ..." s/you // in http://about.validator.nu/ |
| 17:32 | <zcorpan> | hsivonen: btw, i'm not sure about the utility of allowing text/xsl as a lax content type, considering that iirc moz and ie don't actually accept it as a content type |
| 17:32 | <zcorpan> | (but ie requires "text/xsl" in the type pseudo-attribute) |
| 17:33 | webben_ | can understand why one might want to treat name as ID in HTML for IE compat, but can't see the point in corrupting NAME in XHTML in the same way. |
| 17:34 | <zcorpan> | webben_: for HTML compat :) |
| 17:34 | <webben_> | It's a silly habit in HTML to begin with, given that NAME is not unique. |
| 17:35 | <zcorpan> | <a name> or <map name> must be unique per html4 |
| 17:35 | <zcorpan> | <div id="foo"><map name="foo"> is not conforming html4 |
| 17:35 | <webben_> | zcorpan: Do you mean getElementById never returns <input type="radio" name="foo"> ? |
| 17:36 | <zcorpan> | that's not what i meant, and i don't see how you make that connection, but it might well do in ie |
| 17:37 | <zcorpan> | (it shouldn't, though) |
| 17:37 | <webben_> | zcorpan: If it's not the case that getElementById is special-cased for A and MAP, then I'm not sure how that uniqueness restriction helps. |
| 17:38 | <Dashiva> | webben_: How is getElementById on a duplicate id any different from on a duplicate name? |
| 17:38 | <webben_> | Dashiva: You're not supposed to have duplicate IDs. |
| 17:38 | <Dashiva> | That's not enforced, though |
| 17:38 | <zcorpan> | webben_: there are other interfaces than gEBI |
| 17:38 | <webben_> | Not much is enforced. |
| 17:38 | <webben_> | You are supposed to have duplicate NAMEs for radio buttons however. |
| 17:38 | <Dashiva> | Besides, many uses of name are also supposed to be unique |
| 17:38 | <zcorpan> | webben_: such as <img usemap> |
| 17:40 | <Dashiva> | webben_: There's not much of a use case for using gEBI on a radio button name, though |
| 17:41 | <webben_> | I don't see any usecase for using gEBI on NAMEs full-stop, especially in XML. |
| 17:41 | <Dashiva> | Easy access to form elements is one |
| 17:41 | <webben_> | I can see the backwards compat argument in HTML, although it's not massively strong given that relying on such behavior would break webapps in a lot of browsers. |
| 17:41 | <zcorpan> | Dashiva: dom0 has simpler access to form elements |
| 17:42 | <webben_> | I think ID makes form access pretty easy actually. |
| 17:42 | <Dashiva> | Sure, if you have a reference to the form |
| 17:42 | <webben_> | you need ID for form labels anyhow |
| 17:42 | <webben_> | (well, if you want them to actually work) |
| 17:42 | <webben_> | *field labels |
| 17:43 | <Dashiva> | If you use labels, and don't use containing labels, yes |
| 17:43 | <webben_> | Either way, I think that's a stronger argument for a getElementByAttributeValue('name','foo') or something |
| 17:43 | <Dashiva> | getElementsByName exists, yes |
| 17:43 | <webben_> | at least that would do what it says on the tin, and be usable for many more situations |
| 17:44 | <webben_> | e.g. getting all password inputs in a form. |
| 17:44 | <webben_> | s/password/text (probably a better example) |
| 17:45 | <zcorpan> | text inputs might not have a type attribute :) |
| 17:46 | <webben_> | They might not. That's an argument for something like getElementsBy (http://developer.yahoo.com/yui/docs/YAHOO.util.Dom.html) |
| 23:31 | <gsnedders> | http://geekninja.blogspot.com/2007/12/html5s-canvas-tag-are-we-using-it.html |
| 23:42 | <kig> | as webcore is lgpl and canvas is a part of webcore and lgpl has a patent release clause... |
| 23:49 | <Hixie> | Philip`: .width doesn't just reflect the content attribute? |
| 23:51 | <Philip`> | Hixie: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cimg%20src%3Dimage%20style%3Dwidth%3A100%25%20onload%3Dw(this.width)%3E |
| 23:51 | <Philip`> | At least Opera and Firefox return the rendered width, and I think I remember IE doing that too |
| 23:51 | <Hixie> | well crap |
| 23:51 | <Hixie> | does html5 require that? |
| 23:51 | <Philip`> | I think it does |
| 23:52 | <Philip`> | HTML5 says "The DOM attributes height and width must return the rendered height and width of the image, in CSS pixels, if the image is being rendered, and is being rendered to a visual medium, or 0 otherwise. [CSS21]" |
| 23:53 | <Philip`> | (As far as I could see when I last wanted to do this, it's impossible to find the actual bitmap size of the image, which is a bit irritating) |
| 23:54 | <Philip`> | ((except for maybe adding it to the document and having it rendered and then seeing how big it is, but that's nasty)) |