| 00:02 | <dandaman> | when i set a <td> tag's style="width:200" and put stuff in it, the table cell won't expand right? only if the stuff i put in it overflows right? |
| 00:03 | <dandaman> | like if i put a 50px image inside the cell, the cell will still stay at width 200 right? |
| 00:03 | <dandaman> | not 250 |
| 00:03 | <TabAtkins> | Yeah. |
| 00:04 | <dandaman> | well then i might as well shoot myself in the head because i have no idea what is wrong with my code then... |
| 00:16 | <dandaman> | are there any other ways to get the width of your screen or browser |
| 00:17 | <dandaman> | because screen.width is simply not working for me |
| 00:17 | <dandaman> | even though it should... |
| 00:21 | <estellevw> | is the device element supported by any browser? |
| 00:33 | <TabAtkins> | No, it's just a sketch at this point. |
| 00:38 | <dandaman> | ok i found the problem |
| 00:38 | <dandaman> | this is the weirdest thing ever |
| 00:39 | <dandaman> | so i have this function |
| 00:39 | <dandaman> | http://pastebin.com/D7hFrpnq |
| 00:39 | <dandaman> | http://pastebin.com/EERy5RZm |
| 00:40 | <dandaman> | sorry, that function |
| 00:40 | <dandaman> | theWidth is 1280 on my desktop |
| 00:40 | <dandaman> | which is fine |
| 00:40 | <dandaman> | but line #11 screws up apparently |
| 00:40 | <dandaman> | because line 12 alerts 5330 |
| 00:40 | <dandaman> | instead of 6400 which is what 1280*5 is |
| 00:40 | <dandaman> | when i change line 11 to say ...=6400+'px'; it works though |
| 00:40 | <dandaman> | ideas? |
| 00:43 | <dandaman> | this happens with 2 browsers im trying it on |
| 00:46 | <nimbupani> | dbaron_: can I explain why I think this is a bug https://bugzilla.mozilla.org/show_bug.cgi?id=581601 |
| 00:50 | <dandaman> | nevermind found it |
| 03:21 | <othermaciej> | AryehGregor: one thing screen readers could do (though I am not sure any do) is alert you to the presence of an image without describing it |
| 03:21 | <othermaciej> | for empty alt, most screen readers skip the image entirely |
| 03:22 | <othermaciej> | for missing alt, most read the filename, even if it is not human readable (so you get to hear "eye em gee zero zero three seven five four dot jay pee gee" |
| 03:25 | <jamesr> | that's a funny picture |
| 04:20 | <estellevw> | Do any browser support menu/command or details/summary? |
| 05:57 | <estellevw> | Does HTML5 do anything to help the issue that <input type="file" /> in the past has been almost impossible to style? |
| 05:58 | <estellevw> | Is there a different file selection mechanism? |
| 05:59 | <estellevw> | And anyone know if webkit plans on following the suggested spec presentation order? "the element is expected to render as an 'inline-block' box containing a span of text giving the filename(s) of the selected files, if any, followed by a button that, when activated, provides the user with a file picker from which the selection can be changed." |
| 05:59 | <estellevw> | right now the button preceded text, rather than an input box preceding a button (like IE, FF and Opera) |
| 06:19 | <estellevw> | <crickets> |
| 07:45 | <beilabs> | I'm using a cache manifest file, and I have the files that I want to be cached all listed there....does this mean that I can add a path to a file I have never visited before and then it should be automatically cached once I visit a page with the manifest set up correctly? Or do I need to visit it at least one time? |
| 07:47 | <beilabs> | think I found the answer: Whenever the user browses to the page corresponding to a document to which a cache manifest is associated, the browser must check on the server if the latter has been modified: |
| 08:50 | <estellevw> | The pattern attribute: reading the spec it seems to be case insensitive, but the implementation seems to be case sensitive. |
| 08:51 | <estellevw> | am i wrong about the spec, or is webkit and opera wrong on the implmentation? |
| 08:51 | <estellevw> | example at http://www.standardista.com/webkit/ch4/color.html |
| 08:52 | <estellevw> | Constraint validation: If the element's value is not the empty string, and the element's pattern attribute is specified and the attribute's value, when compiled as a JavaScript regular expression with the global, ignoreCase, and multiline flags disabled (see ECMA262 Edition 5, sections 15.10.7.2 through 15.10.7.4), compiles successfully but the resulting regular expression does not match the entirety of the element's value, the |
| 08:52 | <estellevw> | suffering from a pattern mismatch. [ECMA262] |
| 08:52 | <estellevw> | i find that confusing |
| 08:52 | <estellevw> | or does that mean it has to be case sensitive? |
| 08:56 | <jgraham> | If ignoreCase is disabled it is case sensitive, yes |
| 11:51 | <beilabs> | Is window.openDatabase supported in Firefox 3.6+? |
| 12:01 | <jgraham> | beilabs: Firefox don't and won't support WebSQL |
| 12:01 | <jgraham> | They believe it is not a good technology |
| 12:02 | <beilabs> | jgraham, yeah, did a bit of reading on it since, |
| 12:02 | <beilabs> | going down this route instead http://github.com/marcuswestin/store.js |
| 12:02 | <beilabs> | Had everything working perfectly in chrome |
| 12:02 | <beilabs> | then went to FFox, to realize that. |
| 12:02 | <beilabs> | doh |
| 12:03 | <beilabs> | jgraham, do you have any references where Mozilla mention that it's a bad tech? |
| 12:06 | <jgraham> | http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ has some points |
| 12:08 | <beilabs> | jgraham, thanks dude |
| 13:15 | <Workshiva> | jgraham: Who supports WebSQL now? |
| 13:15 | <Ms2ger> | Opera and WebKit? |
| 14:31 | <jgraham> | Yeah, opera and Webkit |
| 14:41 | <Slaanesh> | Is Opera going to keep supporting it? |
| 14:48 | <jgraham> | I don't know of any plans not to |
| 14:50 | <Slaanesh> | Bah |
| 14:51 | <Slaanesh> | Kill it before it gets even more entrenched, I say |
| 14:52 | <jgraham> | I'm not sure that we could kill it in general by dropping support |
| 14:53 | <Slaanesh> | Could at least limit it to iphone apps |
| 14:53 | <jgraham> | My understanding is that a lot of the users are people labouring under the assumption that mobile === Webkit |
| 14:54 | <jgraham> | The concept of "iPhone apps" that are actually just websites that can be accessed by many types of device makes no sense to me |
| 14:55 | <hsivonen> | jgraham: it's kinda sad that authors are so ready to jump back to the monoculture mindset after the last time |
| 14:55 | <jgraham> | hsivonen: Really. |
| 14:55 | <Slaanesh> | hsivonen: But it's much more cool and elegant this time |
| 14:56 | <jgraham> | I guess it is easy to believe that the problems last time were because Microsoft are evil |
| 14:59 | <jgraham> | Rather than the IMHO more likely truth that they were the inevitable result of insufficient competition |
| 15:04 | <jgraham> | Oh man, a proposal for more document.write like functionality |
| 15:05 | <jgraham> | That's just waht the world needs |
| 15:05 | <gsnedders> | Totally. It's beautiful design. |
| 15:08 | <Slaanesh> | Did I tell you guys about the chrome bug where document.write() with a script tag interrupts script execution to run the new script? |
| 15:12 | <hsivonen> | Slaanesh: that's not enough detail to know if it's a bug |
| 15:14 | <Slaanesh> | <script>document.write('<script src=x.js></script>');console.log(1);</script> will sometimes (but not always) execute x.js before logging 1 |
| 15:15 | <hsivonen> | Slaanesh: ok. that's a bug. |
| 15:16 | <hsivonen> | Slaanesh: my guess would be to look at the interaction of resource loads from cache and script execution |
| 16:53 | <EclipseGc> | hah, nice |
| 19:28 | <cyberix> | How do I construct a blob? |
| 23:25 | <jgraham> | http://hg.hoppipolla.co.uk/hgwebdir.cgi/websrtjs/ |
| 23:25 | <jgraham> | WebSRT parser |
| 23:25 | <jgraham> | Probably *horribly* buggy |
| 23:26 | <jgraham> | Doesn't actually do anything useful yet (like, say, display captions) |
| 23:26 | <jgraham> | Just parses the SRT file |
| 23:27 | <jgraham> | Also doesn't create real DOM nodes yet |