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.