00:01 | <yuhong> | gsnedders: That is why tying your site to a specific version of these libraries is bad idea. |
00:02 | <gsnedders> | yuhong: But when there are backwards incompatible changes often in those libraries… |
00:03 | <yuhong> | For example, to view this in IE9, I had to manually hack the markup to use the latest jQuery: |
00:03 | <yuhong> | http://berjon.com/blog/2010/09/bouncy.xhtml |
00:11 | <yuhong> | AFAIK I think IE6 had OK support for CSS1, and it was released in a time when CSS 2.1 did not exist at all. |
00:11 | <yuhong> | They introduced DOCTYPE switching in IE6. |
00:12 | <aho> | background-attachment:fixed from CSS 1.0 was missing |
00:12 | <aho> | if it weren't for all those bugs, it would have been kinda neat |
00:12 | <yuhong> | Then IE stagnated for five years, and guess what people did with IE6 in "standards" mode in these five years. |
00:12 | <aho> | well, to be honest, IE6 was pretty damn good back then |
00:12 | <aho> | in 2001 |
00:12 | <aho> | :> |
00:13 | <yuhong> | Leading to X-UA-Compatible. |
00:14 | <yuhong> | aho: That is why I said *OK* CSS1 support. |
00:17 | <yuhong> | No browser actually fully complied with CSS 2.0 even today, and CSS 2.1 did not exist back in 2001. |
00:23 | <gsnedders> | IIRC IE5/Mac introduced DOCTYPE sniffing, not IE6/Win. |
00:24 | <Yuhong> | <gsnedders> IIRC IE5/Mac introduced DOCTYPE sniffing, not IE6/Win. |
00:24 | <Yuhong> | Yea, I always wondered why they did not port Tasman to Windows. |
00:24 | <Yuhong> | BTW. |
00:25 | <gsnedders> | Yuhong: I believe there was a Windows port. |
00:25 | <Yuhong> | Where? |
00:26 | <gsnedders> | Yuhong: There were some unreleased previews of various technologies using it, IIRC |
00:27 | <Yuhong> | Anyway: http://cwilso.com/2010/04/30/the-ie-plateau-a-history-lesson/#comment-1424 |
00:32 | <Yuhong> | AFAIK it is like the IE7 team used the examples at positioniseverything.net to determine if the bugs has been "fixed". |
00:35 | <Yuhong> | And CSS is not the only example BTW. Guess why in IE7 the contents of an object element do not show up in the DOM unless fallback is needed?? |
00:35 | <Yuhong> | Clue |
00:35 | <Yuhong> | Clue: IE7 introduced proper support for nested object elements? |
00:35 | <Yuhong> | Clue: IE7 introduced proper support for nested object elements. |
05:09 | <MikeSmith> | Is there a bugzilla for bugzilla? |
05:10 | <MikeSmith> | nm |
05:20 | <othermaciej> | hi MikeSmith |
05:20 | <othermaciej> | I think there is a bugzillza^2, yeah |
05:20 | <MikeSmith> | hey hey |
05:22 | <MikeSmith> | from what I've seen, it seems they are tracked under the "Bugzilla" product in bugzilla.mozilla.org |
05:24 | <MikeSmith> | I tried searching there for product=Bugzilla bugs there with the word ARIA in the them, but didn't find any |
05:26 | <MikeSmith> | but in general I'm trying to figure out what changes we'd need to make to the W3C bugzilla UI still to address the specific problems that Gregory has reported |
05:26 | <MikeSmith> | a few of them have been fixed already by our systems team, but still need to be |
05:46 | <othermaciej> | MikeSmith: that's a good thing to be looking at |
05:48 | <MikeSmith> | it may be that the best thing to do would be to port over the templates from http://trace.wisc.edu/bugzilla_wcag/ |
05:49 | <MikeSmith> | which has a UI that's been customized for improved accessibility |
05:50 | <MikeSmith> | unfortunately, they've disabled account creation on it |
05:50 | <MikeSmith> | http://trace.wisc.edu/bugzilla_wcag/createaccount.cgi |
05:51 | <MikeSmith> | so there's no way to go in and look at things like the UI for creating new bugs |
05:54 | <othermaciej> | hmmm |
05:54 | <othermaciej> | I think it's important to figure out the key workflows |
05:54 | <othermaciej> | I figure that includes: |
05:54 | <othermaciej> | - filing new bug (probably the most important!) |
05:55 | <othermaciej> | - given a link, read the state of a bug and its comments |
05:55 | <othermaciej> | - comment on a bug |
05:55 | <othermaciej> | - register for and be able to read email updates about the bug |
05:55 | <othermaciej> | and I suppose creating an account it also key |
05:55 | <othermaciej> | being able to do fancy searches, or to make state changes to bugs, probably not as critical |
05:56 | <MikeSmith> | yeah |
05:56 | <MikeSmith> | Steve Faulkner has already sent a message to the maintainer of http://trace.wisc.edu/bugzilla_wcag/ to ask if we could get copies of their templates |
05:57 | <MikeSmith> | but not heard back yet afaik |
05:57 | <MikeSmith> | so I guess in the mean time I can ask Gregory if that UI in that instance does in fact have fixes for the problems he's cited |
06:21 | <othermaciej> | MikeSmith: if I had the time for this, I'd try testing the bugzilla UI with VoiceOver but I don't think I should take on more commitments |
06:21 | <MikeSmith> | well, I can try that too |
06:22 | <MikeSmith> | I think Steve Faulkner already has a pretty clear understanding of what the specific problems are |
06:23 | <othermaciej> | I wonder if I could convince any Apple folks to help |
06:23 | <othermaciej> | James Craig and Chris Fleizach for instance are super skilled VoiceOver users while I am a newbie |
06:24 | <MikeSmith> | yeah, it would help if they could make time to try it and then comment at http://www.w3.org/Bugs/Public/show_bug.cgi?id=10525 |
06:25 | <MikeSmith> | and also try looking at a bug page at http://trace.wisc.edu/bugzilla_wcag/ and comparing |
06:25 | <MikeSmith> | e.g., http://www.w3.org/Bugs/Public/show_bug.cgi?id=10525 |
06:25 | <MikeSmith> | oops |
06:25 | <MikeSmith> | make that http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=2649 |
06:26 | <MikeSmith> | I don't think we necessarily need to do anything with the bug-entry UI first |
06:26 | <MikeSmith> | because we have the comments list as an alternative |
06:27 | <MikeSmith> | but there is no such alternative in place for viewing bugs and commenting on them |
06:27 | <MikeSmith> | so we should get that part fixed first |
06:28 | <MikeSmith> | webben also volunteered to help out with making template changes |
06:29 | <othermaciej> | sounds like a reasonable approach |
06:34 | <MikeSmith> | I think enabling the e-mail interaction mechanism in the W3C bugzilla would also help |
06:34 | <MikeSmith> | it's actually not clear to me why we don't have it enabled already |
06:45 | <othermaciej> | I don't know how the email interaction works |
07:37 | <zcorpan> | Hixie: why is onerror commented out? |
08:40 | <hsivonen> | I don't see HTML5 requiring window.open to delay the load event of the opener |
08:40 | <hsivonen> | it seems to me that in Gecko, window.open delays the load event of the opener |
08:40 | <hsivonen> | I didn't expect that |
10:59 | <MikeSmith> | wow, look at the UA string |
10:59 | <MikeSmith> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12817 |
10:59 | <MikeSmith> | what the hell is that |
11:00 | <MikeSmith> | Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; |
11:00 | <MikeSmith> | SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.21022; |
11:00 | <MikeSmith> | .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR |
11:00 | <MikeSmith> | 3.0.30729; .NET4.0C; .NET4.0E; MS-RTC LM 8) |
11:00 | <Ms2ger> | Pretty common on windows |
11:00 | <MikeSmith> | really? |
11:00 | <hsivonen> | MikeSmith: yeah |
11:00 | <hsivonen> | MikeSmith: fortunately, IE9 no longer exposes the junk to HTTP |
11:00 | <MikeSmith> | what's the point of all of it? |
11:01 | <MikeSmith> | OK |
11:01 | <hsivonen> | I believe all that is still in navigator.userAgent even in IE9, though my memory may be failing me |
11:01 | <hsivonen> | MikeSmith: everyone wants to have a piece of the UA string to proclaim their existence |
11:01 | <MikeSmith> | heh |
11:02 | <hsivonen> | I'm in the UA string, therefore, I am. -- Descartes |
11:02 | <MikeSmith> | :) |
11:02 | <MikeSmith> | well, in aggregate, it's certainly proclaiming something |
11:02 | <Ms2ger> | Yes, "HELP" |
11:02 | <MikeSmith> | yeah, something like that |
11:03 | <Ms2ger> | (-- John Lennon) |
11:03 | <MikeSmith> | certainly not proclaiming what they intended |
11:04 | <MikeSmith> | anyway, I do like bug reports that have phrases such as "threatens to undermine the future" |
11:05 | <MikeSmith> | though personally I would go with something more like "threatens to destroy the entire fabric of all we hold dear" |
11:05 | <Ms2ger> | (i.e., XML) |
11:10 | <MikeSmith> | I wonder what they worshipped before well-formedness became God |
11:11 | <hsivonen> | MikeSmith: Architectural Forms |
11:11 | <MikeSmith> | heh |
11:12 | <MikeSmith> | I think that was always a pretty small cult |
11:12 | <MikeSmith> | because the initiation rituals were so complicated |
11:12 | <hsivonen> | Did HyTime use Architectural Forms? |
11:13 | <MikeSmith> | I think so |
11:13 | <MikeSmith> | regardless, they were cut out of the same cloth |
11:13 | <hsivonen> | Architectural Forms is an awesome name, BTW |
11:13 | <MikeSmith> | should be repurposed for something good |
11:18 | <Ms2ger> | Using an SGML architecture, documents would instead be required to begin with something like the following processing instruction: |
11:18 | <Ms2ger> | <?IS10744:arch |
11:18 | <Ms2ger> | name="HTML 5.0" |
11:18 | <Ms2ger> | public-id="-//W3C//NOTATION HTML 5.0 ARCHITECTURE//EN" |
11:18 | <Ms2ger> | dtd-public-id="-//W3C//DTD HTML 5.0//EN" |
11:18 | <Ms2ger> | doc-elem-form="HTML" |
11:18 | <Ms2ger> | > |
11:18 | <Ms2ger> | Yes, because the doctype wasn't hard enough to remember |
11:58 | <jgraham> | It should be a CSS property e.g. architectural-form: gothic would add flying buttresses to your <div>, pointed arches to the cop of your columns and put gargoyles around your borders |
11:58 | <jgraham> | *top |
12:22 | <MikeSmith> | so given that you use any element to define a command, just by putting an accesskey attribute on it, the stuff near the end of the table at http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#wai-aria would seem to suggest that role= menuitemcheckbox and =menuitem and =menuitemradio should be allowed on any element |
12:22 | <MikeSmith> | *given that you can use any element |
12:23 | <MikeSmith> | hsivonen: ↑ true? or no? |
12:25 | hsivonen | looks |
12:26 | <hsivonen> | MikeSmith: not quite |
12:27 | <MikeSmith> | well, I mean just as far as the schema goes |
12:27 | <hsivonen> | MikeSmith: first, menuitemcheckbox and menuitemradio aren't allowed, because accesskey on any other element defines a command with the facet "command" |
12:27 | <MikeSmith> | OK |
12:28 | <hsivonen> | so role=menuitem is allowed if accesskey is present and if an ancestor is a menu element whose type attribute is in the list state |
12:29 | <hsivonen> | oh, wait |
12:29 | <hsivonen> | where does it say that it's OK to make default strong ARIA semantics explicit? |
12:29 | <karlcow> | http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density |
12:29 | <hsivonen> | ok in the first paragraph of that section |
12:29 | <karlcow> | useful page for developers |
12:30 | <hsivonen> | karlcow: looks like a useful page that probably violates Wikipedia's policies :-( |
12:30 | <hsivonen> | karlcow: I hope the deletionists don't find it |
12:30 | <karlcow> | in which ways? |
12:31 | <hsivonen> | karlcow: Original Research |
12:31 | <MikeSmith> | hsivonen: yeah, that's how I have been interpreting that first paragraph, at least. Though I do wish it stated that more clearly |
12:34 | <MikeSmith> | hsivonen: so, to be clear, in the schema it seems I need to allow role=menuitem on every element, then have the assertions code check that any element with role=menuitem has a menu ancestor in the list state? |
12:36 | <hsivonen> | MikeSmith: yeah, that's probably better than trying to make it a RELAX NG co-occurrence constraint with accesskey |
12:37 | <MikeSmith> | OK |
12:37 | <MikeSmith> | yeah, the way I described seems less painful to implement |
12:37 | <MikeSmith> | slightly |
12:37 | <MikeSmith> | though still far from being fun |
13:48 | <zcorpan> | Subject: =?utf-8?Q?=5BBug_12818=5D__New=3A_=C3=90=C2=BE=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=B0=C3=90=C2=B2=C3=91=C2=80=C3=90=C2=BF=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=BB=C3=91=C2=80_=C3=90=C2=B2=C3=90=C2=B0=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=BB=C3=91=C2=80=C3=90=C2=BB=C3=91=C2=80=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=B0=C3=90=C2=BF_=C3=90=C2=BE=C3=90=C2=B2=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=BB=C3=90=C2=B0=C3=91=C2=80=C3=90=C2=BF=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=BB=C3=90=C2=B2=C3=90=C2=BA=C3=91=C2=80_=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=BB=C3=90=C2=BA=C3=91=C2=80=C3=90=C2=BF=C3=90?= |
13:48 | <zcorpan> | =?utf-8?Q?=C2=BB=C3=90=C2=BE=C3=91=C2=83=C3=90=C2=BA?= |
13:48 | <zcorpan> | gotta love encodings |
13:50 | <Philip`> | According to Google, it translates into English as "oavrplr valrlrap ovlarplvkr lkrplouk" |
13:51 | <zcorpan> | which in turn is detected as Danish |
13:57 | <Workshiva> | Wait what |
14:04 | <gsnedders> | It's only Document that HTML5 says you should just have a single impl of for HTML, SVG, etc.? Not Element? |
14:06 | <Ms2ger> | gsnedders, right |
14:20 | <aho> | about 2 months or so someone wrote a nice article about css terminology (property, value, rule block, selector, etc). anyone knows which one i mean? |
14:39 | <zcorpan> | aren't there lots of old nice css terminology micro articles? |
14:41 | <miketaylr> | aho: divya wrote one: http://nimbupani.com/css-vocabulary.html |
14:41 | <aho> | ah |
14:41 | <aho> | yea |
14:41 | <aho> | that's the one :D |
14:42 | <aho> | oh... nov 2010 |
14:42 | <aho> | heh |
14:42 | <miketaylr> | wow, time flies |
14:42 | <aho> | well, y'know... waves and ripples... the internet *handwaving* |
14:51 | <hsivonen> | if last week's report was Shelley's last, does it mean annevk has returned? |
14:54 | <jgraham> | I… don't think so |
14:55 | <zcorpan> | who'll step in and write the weekly? |
14:55 | <jgraham> | twitter suggests Bolivia |
15:10 | <AryehGregor> | gsnedders, IE9 has massive compatibility lists to solve the browser-sniffing problem, and it seems to work pretty well. Doubtless it fails on the long tail of sites, but it seems to be enough that compatibility isn't a major liability in practice. |
15:11 | <AryehGregor> | Or at least, I haven't heard anyone say compatibility is a major liability of IE9 in practice. |
15:11 | <AryehGregor> | I haven't used it that much myself. |
15:11 | <gsnedders> | AryehGregor: Yeah, but just switching to another rendering mode isn't a solution that works well for other browsers, really. |
15:12 | <AryehGregor> | Other browsers don't need such a drastic solution, since they worked pretty similarly to the standards to start with. |
15:13 | <AryehGregor> | They can mostly get by with minor case-by-case hacks plus some evangelism. |
15:13 | <gsnedders> | AryehGregor: There are plenty of sites with sniffing like // is IE or Opera, go down IE code-path |
15:13 | <gsnedders> | AryehGregor: Esp. those forking on stuff like window.attachEvent |
15:13 | <AryehGregor> | Yeah, that's because Opera made the mistake of working like IE in a lot of cases instead of Firefox. |
15:13 | <gsnedders> | AryehGregor: Where Opera breaks if you drop window.attachEvent |
15:13 | <gsnedders> | AryehGregor: It's hard to work like Firefox when Firefox didn't yet exist. :P |
15:13 | <AryehGregor> | Well, okay. |
15:13 | <gsnedders> | (And Gecko in general pretty much didn't exist at the time) |
15:14 | <AryehGregor> | I was thinking more recently. |
15:14 | <AryehGregor> | Like, last ten years. |
15:14 | <gsnedders> | We haven't implemented IE stuff like that in a *long* time. |
15:14 | <jgraham> | I tend to agree, but it wasn't clearly the wrong choice at the time |
15:14 | <gsnedders> | Ten years ago was when IE was at its peak, and when we implemented a lot of that stuff. |
15:15 | <AryehGregor> | Yeah, at the time it was probably smart to follow IE. |
15:16 | <AryehGregor> | Gecko did too, for that matter, in lots of ways. |
15:30 | <hsivonen> | AryehGregor: FWIW, I'm very glad we don't have compat lists in Gecko. If we had, I'm pretty sure I would have been required to implement HTML5-compliant script loading in addition to the old code path with a compat list switch |
15:31 | <hsivonen> | AryehGregor: but since we don't have that capability to begin with, we just require sites to get their sniffing act together if they want to continue working |
15:31 | <hsivonen> | though some sites have more trouble than other getting their act together: https://bugzilla.mozilla.org/show_bug.cgi?id=660282#c6 |
15:32 | <hsivonen> | *others |
15:34 | <smaug____> | gsnedders: just curious, has Opera started to drop support for various IEisms ? |
15:34 | <Ms2ger> | I remember attempts, at least |
15:34 | <gsnedders> | hsivonen: How do you deal with major regional sites in countries where you want market-share but where you don't have the marketshare to make them actually fix their behaviour? |
15:35 | <gsnedders> | smaug____: Some stuff. Other stuff has been tried and then broken more than it fixed. |
15:35 | <hsivonen> | gsnedders: we don't deal as far as I know |
15:35 | <gsnedders> | (e.g., the window.attachEvent example above) |
15:35 | <Ms2ger> | gsnedders, by having market share ;) |
15:35 | <hsivonen> | gsnedders: except for stuff like keeping heuristic detectors working for Japanese |
15:36 | <gsnedders> | There have certainly been cases where we've had to make a choice between aligning with other browsers or keeping major sites working that are likely to not change. |
15:36 | <gsnedders> | At least not change quickly. |
15:37 | <hsivonen> | gsnedders: Firefox 4 fail big time (crashes) with a Hungarian ad provider, but even that wasn't handled in a special way (i.e. no out-of-cycle release or anything like that) |
15:38 | <hsivonen> | *fails |
15:38 | hsivonen | wonders if there's something wrong with my s key |
15:39 | <gsnedders> | hsivonen: Was that found after release, or simply just considered low enough priority of not block release? |
15:40 | <hsivonen> | gsnedders: found before release. importance seen and cause understood only after release |
15:54 | <gsnedders> | Oh yay! CORE-840 fixed, which fixes ~150 CSS 2.1 test suite failures. |
15:54 | <gsnedders> | (Outline on empty element is not drawn around content) |
15:55 | <gsnedders> | Yay interop! |
15:57 | <zcorpan> | https://hacks.mozilla.org/2011/05/aurora-6-is-here/ - i hope they didn't actually implement <event-source> |
15:57 | <jgraham> | Isn't that the 150 tests Microsoft submitted that were like outline:blue; outline:red; outline:pretty-much-ever-colour;? |
15:58 | <gsnedders> | jgraham: Well, yes. But that sounds like a lot of the CSS 2.1 test-suite. :P |
15:59 | <miketaylr> | zcorpan: O_o |
15:59 | <jgraham> | gsnedders: So when you said "Yay interop!" what you meant is "Yay pointless tests!" |
15:59 | <jgraham> | zcorpan: Where does it say <event-source>? |
16:00 | <miketaylr> | https://gist.github.com/995177 |
16:00 | <miketaylr> | (which is embedded) |
16:00 | <zcorpan> | jgraham: in the example |
16:04 | <jgraham> | Oooh so it does |
16:04 | <Ms2ger> | We didn't |
16:08 | <hsivonen> | Ms2ger: I don't see anything about <event-source> in the code that landed. What's the Hacks article talking about? |
16:09 | <Ms2ger> | No idea |
16:10 | <zcorpan> | prolly ripped an example from wikipedia or something without checking whether it was up to date |
16:12 | <zcorpan> | anyone know what happened to websocket.onerror? |
16:13 | <jgraham> | I thought the IETF had eliminated all error from the websocket spec |
16:13 | <zcorpan> | well yes |
16:14 | <Ms2ger> | It's being fixed |
16:15 | <zcorpan> | what is? |
16:15 | <Ms2ger> | The example |
16:15 | <zcorpan> | oh |
16:15 | <Ms2ger> | I don't put any hope in the IETF fixing something |
16:17 | <hsivonen> | the example is gone now |
17:51 | <AryehGregor> | hsivonen, Firefox probably has more freedom here than IE, though, since IE is subject to vastly more browser-sniffing than Firefox. Also, the difference between IE9 standards and IE8 standards, for instance, or IE7 standards and IE8 standards, is drastically greater than the difference between any two consecutive Firefox versions. |
17:52 | <AryehGregor> | Now that IE9 is pretty standards-compliant, IE10 might not need to preserve an IE9 compatibility mode. |
17:52 | <AryehGregor> | Because it will only be relatively small changes. |
17:54 | <AryehGregor> | I know of one case where WebKit worked around bad MediaWiki browser-sniffing (added for KHTML in like 2002 or something) with something like "if file is named KHTMLFixes.css, and has exactly the following content, ignore it". The alternative in that case was to have all MediaWiki sites have dramatically broken appearance on every page, and good luck evangelizing that away. |
17:54 | <AryehGregor> | Would Firefox really refuse to have some kind of site-specific quirk even in such a case? Does it really not have any such workarounds? |
17:54 | <AryehGregor> | (I got the impression WebKit has very, very few like that) |
17:55 | <Ms2ger> | We don't have any |
17:55 | <AryehGregor> | Interesting. |
17:55 | <Ms2ger> | We had one for hotmail briefly, right before we released Fx4, but they asked us to take it out |
17:56 | <AryehGregor> | Reminds me of how Wine has no app-specific compatibility hacks (or at least didn't used to), while Windows is full of them, but somehow Wine manages to work for lots of programs anyway. Sometimes when Windows doesn't. |
17:56 | <jgraham> | To be fair windows works for many more programs than wine |
17:56 | <Ms2ger> | And Firefox works for many more sites than IE :) |
17:57 | <Philip`> | Wine users have a much more relaxed definition of "works", too |
17:57 | <AryehGregor> | Granted. |
17:57 | <jgraham> | Philip`: "shows the splash screen"? |
17:57 | <AryehGregor> | Although I think Windows only has shims where it would really mess up the program, not just where it would make it behave a bit weirdly. |
17:57 | <AryehGregor> | Unless it's really high-profile, maybe, I dunno. |
17:59 | <AryehGregor> | jgraham, slightly higher than that. More like: "can use all the basic functionality, possibly with occasional crashes or lots of glitches, and possibly requiring you to go through voodoo magic to install/start it, and possibly requiring you to install some downloaded closed-source DLLs, and possibly requiring you to fiddle with the Wine registry a bunch, and in some cases maybe compile your own Wine with a patch or two applied." |
17:59 | <AryehGregor> | I'd say Vampire: The Masquerade - Redemption worked in Wine, and even once I got it installed, it was an intricate five-minute procedure to actually start it. |
18:00 | <AryehGregor> | I had to try several times, because often it would hang. Then once it started I had to start a new game and then load my save from there, because if I loaded my save directly it didn't work. And some other steps I've forgotten. |
18:00 | <jgraham> | AryehGregor: So wine doesn't have any hacks because it expects users to recompile with them included on a case-by-case basis? |
18:00 | <Ms2ger> | Exactly |
18:00 | <AryehGregor> | Oh, right, I had to adjust my resolution and run it in windowed mode, instead of running it in fullscreen mode. |
18:00 | <gsnedders> | AryehGregor: I think all our hacks are done in browser.js |
18:01 | <AryehGregor> | I got most of the procedure automated using a shell script, though, so it was okay. |
18:01 | <jgraham> | Stockholm syndrome? |
18:01 | <AryehGregor> | jgraham, that was an extreme case, usually you don't have to do that. The one time I saw that was a temporary case where some game was reading some weird info about the video driver and deciding it didn't support it or something, so the hack was just to supply some bogus data to shut it up until Wine was fixed to report it correctly. |
18:03 | <AryehGregor> | jgraham, no, Stockholm syndrome is the opposite: when people get so used to Windows that they prefer it to Linux and aren't willing to put up with minor inconveniences like this. :) |
18:03 | <gsnedders> | To be fair, we did actually make a change that broke old versions of jQuery, and then just having to evanglize every case of that breaking a site. |
18:03 | <AryehGregor> | Presumably quite old. |
18:04 | <AryehGregor> | jQuery mostly makes an effort to sniff properly, right? (Sometimes it's not realistically possible, though, or not worth the effort . . .) |
18:04 | <AryehGregor> | (I committed at least one feature to MediaWiki which says if (firefox) { do_something_different(); }, and in that specific case I have no apologies. It was the best solution available.) |
18:05 | jgraham | just uses a Mac for things that won't run in Linux, at the expense of occasionally having to put up with its inferior window manager when programming |
18:05 | <gsnedders> | AryehGregor: In many places it doesn't sniff at all properly, AFAIK |
18:05 | <jgraham> | And doesn't try to play games that aren't written by Nintendo. |
18:05 | <Ms2ger> | AryehGregor, which was that? |
18:05 | <jgraham> | On the intended hardware |
18:06 | <gsnedders> | Note that we in browser.js have stuff to work-around browser sniffing on major sites like blogger.com where evanglism has proved ineffective. |
18:06 | <AryehGregor> | Ms2ger, https://bugzilla.mozilla.org/show_bug.cgi?id=516293 |
18:07 | <jgraham> | gsnedders: Yes, Opera has a *ton* of site-specific quirks in the browser.js file |
18:07 | <AryehGregor> | Ms2ger, http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?view=markup#l504 |
18:07 | <AryehGregor> | Slightly better link: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?view=markup#l491 |
18:07 | <jgraham> | So we are not exactly a shining example of purity here |
18:07 | Ms2ger | was about to test whether that bug was still present by loading the test in Chrome |
18:08 | <AryehGregor> | Opera has a lot less clout to get sites to fix themselves than Firefox. |
18:08 | <gsnedders> | jgraham: My point is we have quite a few cases where all we do is just make ourselves appear (via the navigator object) to be some other browser. |
18:08 | <jgraham> | gsnedders: Oh. I didn't realise that was your point. |
18:08 | <jgraham> | Well yeah that is lame |
18:09 | Ms2ger | neither |
18:09 | <jgraham> | There are also a few cases where we work around our own bugs, which is also kinda lame :) |
18:09 | <Ms2ger> | And we have people saying we should implement a window.opera equivalent |
18:09 | <jgraham> | (but I expect those fixes tend to be way more shortlived) |
18:10 | <Ms2ger> | jgraham, seems like your core doesn't get sufficient QA ;) |
18:10 | <gsnedders> | jgraham: I think there are far more workarounds for workarounds of long-since fixed bugs. |
18:11 | <jgraham> | Ms2ger: How do you think we know what the bugs are to work around? :) |
18:12 | <jgraham> | gsnedders: Yes, I imagine there are far more cases where we have to work around a site working around bugs that were fixed in opera 7 :) |
18:13 | <Ms2ger> | Did you eventually end up removing element.all? |
18:13 | <gsnedders> | Ms2ger: Removing that broke loads of sites, IIRC. |
18:15 | <gsnedders> | Ms2ger: Apparently CKEditor relies upon it |
18:16 | <Ms2ger> | Fun |
18:16 | <gsnedders> | http://dev.ckeditor.com/browser/CKEditor/trunk/_source/core/dom/element.js#L1238 |
18:17 | <gsnedders> | if ( CKEDITOR.env.ie || CKEDITOR.env.opera ) |
18:17 | <gsnedders> | There are far too many sites and libraries that for some reason throw us down the IE codepath |
18:18 | <hsivonen> | Ms2ger: the window.opera equivalent in Firefox is called window.netscape for historical reasons |
18:19 | <hsivonen> | gsnedders: it's quite sad how sites are willfully ignorant about stuff like that in face of well-informed evangelism |
18:20 | <hsivonen> | gsnedders: for example, when evangelizing a site about their Firefox sniffing, I also mentioned to them that they should proactively get rid of their Opera sniffing so that their code works when Opera implements the spec |
18:20 | <hsivonen> | and they kept their Opera sniffing anyway |
18:21 | <gsnedders> | http://dev.ckeditor.com/ticket/6666 is a case of they've known we intend on breaking our behaviour soon for seven months. |
18:25 | <gsnedders> | AryehGregor: The only browser sniffing (for Opera) in jQuery master now is for jQuery.browser, it's never used to fork internally. |
18:26 | <AryehGregor> | Cool. |
18:26 | <AryehGregor> | I remember when I looked at jQuery a while ago I saw a little bit of bad browser-sniffing, but nothing that looked gratuitous. |
18:27 | <hsivonen> | gsnedders: why does jQuery expose jQuery.browser at all? compat with old versions that used it internally and got used externally? |
18:27 | <gsnedders> | hsivonen: No idea. |
18:27 | <AryehGregor> | hsivonen, because authors want to do their own sniffing, and browsers don't make it easy for them? |
18:28 | <AryehGregor> | I mean, would you prefer they sniff based on stuff like document.all? |
18:29 | <hsivonen> | AryehGregor: depends on what code they run as the result of sniffing on a case-by-case basis :-) |
18:29 | <AryehGregor> | Or stuff like: var is_khtml = navigator.vendor == 'KDE' || |
18:29 | <AryehGregor> | ( document.childNodes && !document.all && !navigator.taintEnabled ); |
18:29 | <AryehGregor> | Which is what got MediaWiki's ancient KHTML hack hitting WebKit. |
18:29 | AryehGregor | doesn't know what navigator.taintEnabled is, some Gecko-ism? |
18:30 | <hsivonen> | I was about to ask what taintEnabled is |
18:30 | <AryehGregor> | hsivonen, I'm not talking about sniffing document.all before using document.all, I'm talking about sniffing document.all and then deciding the browser is IE and supports a bazillion unrelated features that only IE supports. |
18:30 | <AryehGregor> | If you're going to do that, at least check the UA string properly. |
18:30 | <AryehGregor> | Using the UA string also means browsers can cloak themselves easily. |
18:30 | <AryehGregor> | In case the code isn't really browser-specific after all. |
18:31 | <AryehGregor> | Of course, the UA string has loads of pitfalls too, so your random author is really better off letting jQuery do the UA string parsing for them. |
18:31 | <gsnedders> | AryehGregor: Try replacing document.all with document.attachEvent and then you have what Opera has fun. Especially when the other code-path relies upon some nonstandard Gecko/WebKit thing… |
18:31 | <AryehGregor> | Don't be silly, anything in Gecko+WebKit is standard. It just might not have a spec written yet. |
18:31 | <AryehGregor> | On the other hand, anything in only IE or IE+Opera is proprietary and evil. |
18:31 | <AryehGregor> | It stands to reason. |
18:32 | <AryehGregor> | Until Gecko or WebKit implements it, then it becomes okay. Like innerHTML, or execCommand(). |
18:32 | <AryehGregor> | Or, um, like 20% of other important web features. |
18:33 | <Ms2ger> | XHR |
18:34 | <AryehGregor> | If everyone but WebKit implements something, it's clearly WebKit's fault and WebKit is being stupid for not changing. If everyone but Gecko implements something that was originally an IE feature (like .innerText), Gecko is nobly resisting the encroachment of Micro$oft's proprietary "features", but might be justified in conceding the fight on this score. |
18:34 | <AryehGregor> | If everyone but IE implements something, then it goes without saying it's because Microsoft is evil and doesn't want to follow standards. |
18:34 | <AryehGregor> | This stuff is all obvious, right? |
18:35 | <Workshiva> | Well, if it's CSS-related I think webkit is always right, even in the case you mentioned |
18:35 | <gsnedders> | And if Opera doesn't implement something? |
18:35 | <AryehGregor> | Nobody cares. Use a normal browser. |
18:35 | <AryehGregor> | :P |
18:35 | <Workshiva> | >real browser |
18:35 | AryehGregor | accepts Workshiva's correction |
18:35 | <hsivonen> | AryehGregor: and Chrome-only stuff is axiomatically HTML5 |
18:36 | <AryehGregor> | Mostly, yeah. |
18:36 | <AryehGregor> | Especially if they intend to probably write a spec for it at some point in the unspecified future. |
18:36 | <Workshiva> | Axiomatically awesome |
18:36 | <AryehGregor> | However, any claim by Microsoft to implement HTML5 is a complete joke. Everyone knows IE doesn't implement HTML5. |
18:37 | <Workshiva> | Except when it's native HTML5 |
18:37 | <AryehGregor> | Especially for features like drag-and-drop. |
18:37 | <hsivonen> | Workshiva: "awesome" is reserved for Firefox |
18:39 | <gsnedders> | AryehGregor: Also, if Firefox implements something new, it's irrelevant because IE won't support it for years. |
18:39 | <AryehGregor> | gsnedders, no, you're getting confused. Only losers care about IE. Everyone worth caring about puts a prominent banner at the top of their page telling all IE users to switch to other browsers. |
18:40 | <AryehGregor> | Only ignorant, selfish webmasters are fixated on what IE supports. |
18:40 | <AryehGregor> | Responsible people write code for standards-compliant browsers and write crippled and barely-tested code for IE. |
18:40 | <AryehGregor> | This is sometimes known as "graceful degradation". |
18:41 | <hsivonen> | worked for me. Validator.nu's UI had a JS error in IE <= 8 for years |
18:41 | <hsivonen> | then IE9 came along and fixed it |
18:41 | <hsivonen> | I had no browser sniffing |
18:41 | <AryehGregor> | I don't even try to run any of my browser tests in IE8. |
18:41 | <AryehGregor> | They all fail immediately with cryptic errors. |
18:41 | <hsivonen> | the main reason why I didn't fix it myself in IE <= 8 was that IE's diagnostics were too terrible to figure out what caused the error |
18:42 | <AryehGregor> | IE seems to have more cryptic errors than Gecko or WebKit. I've seen "Unspecified error" too many times. |
18:42 | <AryehGregor> | Even in IE9. |
18:42 | <AryehGregor> | IE9 has okay diagnostics. I prefer WebKit's Web Inspector, but IE9's F12 tools are perfectly serviceable. |
18:42 | <hsivonen> | AryehGregor: maybe it means that Hixie hasn't written a spec for that stuff yet |
18:42 | <AryehGregor> | Doesn't help much when a built-in function like Selection.addRange() throws an "Unspecified error." exception under some circumstances. |
18:43 | <AryehGregor> | But it helps me figure out other bugs, like when nodes have a nextSibling but no parentNode. |
19:31 | <AryehGregor> | Does Firebug work in Aurora 6? |
19:34 | <AryehGregor> | Firefox doesn't seem to think Firebug 1.8.0a3 is compatible with Aurora 6.0a2. |
19:34 | <AryehGregor> | So I guess I don't upgrade it. :/ |
19:37 | <erlehmann> | what is aurora |
19:37 | <abarth|gardener> | erlehmann: firefox dev channel |
19:37 | <AryehGregor> | Firefox dev channel? |
19:38 | <erlehmann> | ah |
19:38 | <erlehmann> | thx |
19:39 | <hsivonen> | regarding zcorpan's adaptive image suggestion, which formats besides interlaced PNG have the property that if you download the first quarter of the file, you can decode the image with halved dimensions? |
19:39 | <hsivonen> | (JPEG 2000 does *not* have that property, BTW) |
19:40 | <hsivonen> | (to decode JPEG 2000 with halved dimensions, you have to download half of the data--not a quarter of the data) |
19:41 | <hsivonen> | (that is, you want halved dimensions with acceptable image quality) |
19:45 | <Philip`> | Assuming JPEG 2000 is generally sane, doesn't that suggest that half the perceptual information content is necessary for acceptable quality at half the dimensions, and so any similarly efficient lossy format will have the same behaviour? |
20:44 | <Thomas9000> | can I ask html questions here? |
20:45 | <Ms2ger> | Sure thing |
20:46 | <Thomas9000> | I've got a question about the new offline caching in html5. Is there a way to prevent the browser from automatically downloading the resources if cache.manifest has changed and instead do it manually using javascript? So the user can decide if they want to update now or later? |
20:47 | <Thomas9000> | Got any idea? :) |
22:14 | AryehGregor | discovers Google Closure uses execCommand() extensively, nice |
22:17 | <AryehGregor> | . . . I think? |
22:19 | <AryehGregor> | No, it seems like it's another one that wrote their own execCommand() implementation. Oh well. |