06:09
<zcorpan>
if the Team and the Director just want a Rec and don't care about interop, why not publish a Rec immediately and be done with it?
06:12
<jgraham>
zcorpan: AFAICT the process is changing slowly. State (1) was "require a full testsuite". State (2) is "look at caniuse.com". State (3) will be "publish immediately"
06:18
<zcorpan>
i have my doubts that the w3c and the html wg will allow themselves to publish immediately since that would waste minimal amount of time
06:18
<jgraham>
It's hard to say that not requiring a full testsuite is a bad thing. At least the incentives for creating a testsuite just to pass some formal process are perverse; ideally people would be creating tests to actually improve interoperability, and people fixing bugs would be free to pick and choose the most important issues to work on
06:19
<jgraham>
zcorpan: Well it took many years and CSS2.1 to get from stage (1) to "you have the choice of (1) or (2) but we're not doing (1)"
06:20
<jgraham>
Getting to stage (3) will probably not happen for a while yet :)
06:20
<jgraham>
(OTOH, it is possible that some parties will be less willing to contribute tests if there isn't a Process-based motivation)
06:21
<jgraham>
(which is sad)
06:53
<zcorpan>
jgraham: hmmmmmmm. shouldn't "stop parsing" provide a stable state so that the resource selection algorithm's sync section (which delays the load event) gets to run before "stop parsing" goes on to fire 'load'?
07:01
<zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18565
07:26
<jgraham>
Uh, maybe?
07:27
<jgraham>
The details of the resource selection algorithm are a horror I have managed to avoid
07:36
<jgraham>
Media events get their own task source?
07:37
<jgraham>
I feel like that's not going to work
07:38
<jgraham>
In particular the order relative to other DOM events being undefined
07:38
<jgraham>
Hixie: ^
07:58
<zcorpan>
yeah i don't know why it has that. i've kind of ignored task sources until recently
07:58
<zcorpan>
mind you not all media events use that task source
08:00
<zcorpan>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#audiotracklist-and-videotracklist-objects says DOM manipulation
08:00
<zcorpan>
i'll file a bug
08:02
<zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18570
08:19
<zcorpan>
can unzipping be incremental (i.e. should the API support incrementally exposing of the files)?
08:28
<zcorpan>
html wg no longer requires the boilerplate of editors when resolving bugs?
08:29
<zcorpan>
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=17563#c10 )
08:30
<Ms2ger>
That was only to annoy Hixie, you didn't know?
08:31
<odinho>
^_^
08:31
<zcorpan>
it's just the canvas spec that has editors, right?
08:37
<Ms2ger>
Nah, HTML has a team too
08:44
<zcorpan>
ah
08:47
<jgraham>
Not to be confused with a Team
08:48
<jgraham>
Which would be MikeSmith and his accomplises
08:55
<odinho>
The W-Team!
08:55
<hsivonen>
w3cmemems needs a meme about relaxing the CR exit criteria
08:56
<odinho>
Yeah, was thinking about that, but can't figure out something cool.
08:56
<hsivonen>
Brace yourselves, fast-tracking the Process by relaxing CR exit criteria has begun.
08:57
<odinho>
that sure is a mouthful :P
08:58
<jgraham>
There is something very pleasing about writing tests that pop up windows and then have them automatically close them when the test is done
09:00
<odinho>
jgraham: Reviewed some tabs+windows extension tests, they did that a lot. Even crashed my window manager at one point.
09:00
<jgraham>
Heh
09:01
<jgraham>
So, when will gecko implement shared workers?
09:13
<Ms2ger>
jgraham, patches welcome :)
09:16
<jgraham>
:p
09:16
<Ms2ger>
Do you have someone who can look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=14421 ?
09:20
<jgraham>
Not sure who that would be, but I can ask
09:52
<zcorpan>
krijn logs down for good or temporarily?
09:53
<Ms2ger>
He's moved offices, and is working on getting them up again, AIUI
09:59
<Ms2ger>
MikeSmith, [tm], pulling from https://dvcs.w3.org/hg/webapps seems to be broken with a 500 Internal Server Error, plain HTTP works
09:59
<Ms2ger>
(Same for /html)
11:43
<zcorpan>
http://playcanvas.com/a-multiplayer-3rd-person-shooter-in-html5/ sounds awesome
12:10
<zcorpan>
http://www.alistapart.com/articles/love-the-boring-bits-of-css/ ...uh, i thought :matches() and :any() were different
12:49
<krijn>
zcorpan: what Ms2ger said, sorry for the delay
12:50
<zcorpan>
krijn: no worry, i was just curious
13:43
<Ms2ger>
jgraham, thanks for finding someone who knows about canvas :)
13:44
<jgraham>
Ms2ger: No problem :) We have gfx QA for a reason :)
13:52
<hsivonen>
How did http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html become a HTML WG doc?
14:01
<karlcow>
"Instead of referencing SVG files in your CSS or adding them as data URIs, you add the SVG markup right below the closing body tag and use Javascript to parse through them and generate CSS rules at runtime." — http://www.somerandomdude.com/2012/08/12/svg-css-injection/
14:01
<karlcow>
Parsing headaches ahead.
14:01
<zewt>
zcorpan: re ZIPs, you can incrementally access files in ZIPs if you have a streaming source, but since the source for this API is a Blob (rather than a URL) it's not
14:01
<zewt>
(ZIPs have both incremental file records, before each file data, and another central record at the end, so they support both streaming and fast random lookup)
14:02
<zewt>
(i've implemented ZIP APIs on three or four independent occasions, heh)
14:03
<zewt>
aside from the filename encoding thing (since the format is so old), it's actually not a bad format, surprisingly unhorrible for its age
14:03
<zewt>
afk
14:06
<Ms2ger>
Ah, W3C Management still as incompetent as ever
14:38
<jgraham>
Hmm, should testharness.js call completion_callback for tests that get the status NOT_RUN?
14:39
<jgraham>
I mean result_callback
14:39
<jgraham>
It doesn't but I tend to think it should
14:40
<Ms2ger>
Probably, yes
14:42
<Stevef_>
hsivonen: interesting to note that the issue of hiding info in title attributes was raised in that 2004 post you retweeted
15:08
<jgraham>
Ms2ger: Changed that
15:15
<odinho>
I feel so stupid when I always have a problem with remembering that stopPropagation is named just that. And doing that and preventDefault is quite common.
15:15
<odinho>
They're quite a mouthful for a non-native speaker too :P
15:15
<odinho>
I write cancelPropagation often first.
15:16
<jgraham>
If it makes you feel better, there is no way I can spell "propagation"
15:16
<jgraham>
(I had to copy you there)
15:17
<jgraham>
(too many vowels)
15:20
<odinho>
sicking: There?
15:21
<jreading>
canvas
15:22
<odinho>
jgraham: It does makes me feel better. :-) Although not always that happy about js naming. :]
15:24
<odinho>
jreading: What? That's a bit too cryptic.
15:25
<jgraham>
odinho: Maybe that's jreading's password
15:26
<jreading>
ha, sorry wrong window
15:26
<jreading>
i came here for the css vars drama and very upset to not see any :)
15:47
<jgraham>
jreading: You want drama? Watch this: @srcset! @longdesc! FORMAL OBJECTION!
15:47
<jgraham>
Should be plenty of drama now :)
15:48
<Ms2ger>
That's the best you can do?
15:48
<jgraham>
I wasn't feeling very inspired
15:48
<jgraham>
Sorry
15:48
<jgraham>
But fortunately it doesn't take much :)
15:48
<Ms2ger>
Heh
15:51
<dglazkov>
good morning, FORMAL OBJECTION!
15:51
<dglazkov>
er, Whatwg!
15:51
Ms2ger
kicks dglazkov out again
15:53
<dglazkov>
can someone please start a ska band called Formal Objection?
15:55
<jgraham>
Maybe if we just got the frontperson to adopt the monkier "Formal Objection", they could team up with Bob Marley's backing band?
15:58
<dglazkov>
jgraham: count me as a fan already
15:59
dglazkov
takes out his iPhone, launches the Lighter app.
16:03
<hober>
jgraham: "Formal Objection and the Vendor Prefixes"?
16:15
<hsivonen>
whoa. chairs asking about support for a CP. (as opposed to objections)
16:17
<Ms2ger>
Also, anybody who likes prefixing discussions, I'll be in #css with the popcorn
16:22
<hober>
Ms2ger: you're lucky you aren't in the room! :)
16:23
<Ms2ger>
Very
16:23
<Ms2ger>
hober, do you expect anything new will be said?
16:24
<hober>
I doubt it, but I'm trying to be optimistic.
16:27
<smaug____>
jgraham: btw, do you happen to know if the spec says how http://mozilla.pettay.fi/moztests/history2/Start.html should behave?
16:27
<dglazkov>
excellent post from slightlyoff: http://infrequently.org/2012/08/inadmissible-arguments/
16:28
<dglazkov>
especially like the use cases bit
16:30
<smaug____>
hmm, perhaps the spec is clear there
16:30
<smaug____>
well, not clear, but defines
16:31
<smaug____>
and Gecko/IE behavior is correct
16:49
<sicking>
odinho: yes
16:49
<jgraham>
smaug____: Without reading the spec, I am unclear why each iframe wouldn't appear in the session history
16:50
<odinho>
sicking: Been looking at this IDB bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=18551
16:51
<odinho>
sicking: And wrote a few tests of how I think it should be. And I think Firefox actually passes them all :P
16:51
<sicking>
woot :)
16:51
<sicking>
odinho: bent writes good code :)
16:53
<odinho>
I had a question but I figured it out. So I think that also makes a strong case for how to solve 18551. I think Opera will also behave like that when an abort bug is fixed.
16:54
<smaug____>
jgraham: because they are removed from the document
16:55
<sicking>
odinho: sweet
16:58
<jgraham>
smaug____: Ah! Clever!
16:59
<jgraham>
smaug____: And now I know what I will write tests for tomorrow! With spec-compliant pass conditions and all!
17:00
<jgraham>
(that was worth four exclaimation marks! and two meta-exclaimation marks!)
17:01
<odinho>
sicking: But ... about that email I wrote that noone wanted to touch with a fire pole...
17:02
<odinho>
sicking: The strange behaviour of opening new databases and it hanging forever.
17:02
<odinho>
sicking: (or deleting)
17:02
<sicking>
i don't recall that one
17:03
sicking
heads in to meeting
17:04
<odinho>
Hmm. I actually got replies which I seem to have read on my phone, so they didn't come up here. :P
17:04
<odinho>
Will continue thread then, -- since I got replies.
17:06
<jsbell>
odinho: chrome might behave as suggested in 18551 already too (give your tests a whirl on Chrome?) - we brought it up when we realized the async create/delete behavior we had fell out of the implementation rather than being defined by the spec.
17:06
<odinho>
jsbell: Well, I'm always put off by the setVersion() thing. Do you have a build with newer API?
17:07
<jsbell>
odinho: crud, sorry. Coming in a Canary build in the next few days.
17:07
<odinho>
I should possibly look into polyfilling the tests just to check stuff like that. But it has to be in a common file then, because it's way too ugly to stand :P
17:07
<jsbell>
I have a polyfill somewhere, let me post it...
17:08
<odinho>
I prolly have to port it a bit, but just looking at another one will speed it up.
17:08
<odinho>
jsbell: Great news about canary btw. How much is fixed?
17:09
<jsbell>
odinho: https://gist.github.com/3361666
17:09
<odinho>
jsbell: I am fighting with mercurial in order to put up my tests as of now, btw.
17:09
<odinho>
I have not commited to it in a few weeks.
17:10
<odinho>
Only to my Opera git-backed repo :]
17:10
<jsbell>
odinho: Chrome will support open(name, version) and fire upgradeneeded events. We'll also support setVersion() for a while (while prefixed) so we don't break some deployed sites.
17:11
<jsbell>
This leads to a few wrinkles around open(name) (no version) and upgradeneeded that we still need to sort out.
17:12
<jsbell>
Other than that, firing blocked events too early, and no Blob support, and no Sync API (though we do have Async API for workers) I believe we've got everything implemented.
17:13
<odinho>
jsbell: Cool, will run my tests on it straight away when there's a build.
17:13
<odinho>
Well, noone has sync :P
17:13
<jsbell>
Yeah, just being pedantic :)
17:17
<jgraham>
odinho: Go all github on their asses ;)
17:17
<odinho>
jgraham: Well, I like it that hg push also puts the files on w3c-test.org
17:17
<Ms2ger>
Bah, github
17:40
<Hixie>
jgraham: the media systems are expected to be on a different thread and thus unable to coordinate with other things for ordering of events
17:51
<jgraham>
Hixie: That makes sense, but it strikes fear into my heart
17:51
<jgraham>
Pages will depend on the relative order of e.g. the load event and various media events
17:54
<othermaciej>
for anyone who's interested in W3C process for HTML5 (maybe not most folks here), I recommend looking at this thread about CR exit criteria http://lists.w3.org/Archives/Public/public-html/2012Aug/0190.html
17:54
<othermaciej>
short version is that there's some tension between testing interop in detail, and getting to REC fast
17:55
<othermaciej>
I would be particularly interested in implementor input since that's likely the group most impacted
17:56
<jamesr>
othermaciej, i saw that and was curious about the W3C consequences of getting to REC faster
17:56
<jamesr>
seems like the lax version is somewhat SVG2-ish - just public a big old document with no conformance requirements or checks
17:56
<jamesr>
and i don't know who benefits from that
17:56
<othermaciej>
jamesr: the way I see it (and maybe I should say this on the thread) is that REC has three purposes:
17:56
<othermaciej>
(1) declare to the world that the spec is "done"
17:56
<othermaciej>
(2) cause patent commitments to officially take effect
17:57
<othermaciej>
(3) drive creation of a test suite and convergence of the spec and implementations on interoperable behavior
17:57
<jamesr>
the lax version seems to mostly throw away (3)
17:57
<othermaciej>
I think the W3C Process would be better if (1) and (2) were separated from (3)
17:57
<othermaciej>
yes, the lax version skimps on (3), the strict version delays (1) and (2)
17:58
<Hixie>
jgraham: it's a risk, certainly
17:58
<Hixie>
jgraham: but that's a risk anywhere we have multiple event sources
17:58
<Hixie>
othermaciej: if we want to do (1) and (2) quickly, why bother with a CR at all? just publish a REC
17:59
<Hixie>
othermaciej: (which is what i'd been proposing for months and would have avoided all this forking nonsense)
17:59
<othermaciej>
Hixie: I think the W3C Process requires a minimum duration of CR, but given that, the "loose" criteria would basically have that effect
17:59
<jamesr>
othermaciej, as someone who's job description doesn't include woring about (2), (3) is the most important thing so the lax version seems silly. but i suspect in the broader picture (2) and to a lesser degree (1) are pretty important so i'd say REC tomorrow
17:59
<Hixie>
othermaciej: the process requires lots of stuff the w3c ignores
17:59
<jamesr>
s/woring/worrying/ (not whoring)
17:59
<othermaciej>
Hixie: since you would go into CR having already met all the exit criteria other than time
17:59
<Hixie>
othermaciej: if the process means anything, then it should be followed in spirit, and not have a loose CR
17:59
<Hixie>
(there's no minimum time for CR)
17:59
<jamesr>
the waiting period is what, 60 days? something like that?
18:00
<othermaciej>
jamesr: I'd love to have that input on the thread
18:00
<jgraham>
Hixie: Yes, in general each time we introduce a task source we introduce the possibility of race conditions. That seems like something we want to minimise
18:00
<Hixie>
jgraham: it's a balancing act, certainly
18:01
<othermaciej>
jamesr: in my dreams, what the W3C would do is rename CR to "Recommendation", rename "Recommendation" to "Standard", move patent commitments to what was CR and would be REC, and leave comprehensive interop proof at the STD level
18:01
<othermaciej>
jamesr: and STD would be considered an optional step that only the most critical and widely deployed specs ever reach
18:01
jgraham
would advise not using the acronym STD :)
18:02
<odinho>
:-)
18:02
<othermaciej>
the ietf has already been down that road, and there is a surprising lack of mockery
18:02
<jgraham>
In my dreams the W3C would move to a WHATWG-like model where IPR commitments were based on strictly date based snapshots and the spec evolution was continuous
18:03
<Hixie>
(if we're allowed to dream, then in my dreams, patents wouldn't apply to software, and we'd use a living standard model and people who need a fixed reference point would use revision numbers)
18:03
<Hixie>
(but i'm guessing we're not really allowed to dream :-P)
18:03
<odinho>
Such a dream, should do a speech
18:03
<jgraham>
And the testsuite would be developed along with the spec by people interested in interoperability rather than people intreseted in fulfilling Process requirements
18:03
<jamesr>
othermaciej, i don't think i'll post on the thread, mostly because i can't tell what on earth most of the people on public-html are trying to do. just seems like a crazy flamewar land
18:03
<gavinc>
A most excellent paper on software patents: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2117302
18:06
<othermaciej>
jgraham: I think evidence so far is that whatwg model does not result in a comprehensive test suite at all
18:06
<othermaciej>
this may be a sign of the market not finding it worth doing, or it could be a collective action problem
18:07
<Hixie>
well the whatwg model on the test suite front has been "people are making a test suite at the w3c, so let's avoid duplicating effort"
18:07
<Ms2ger>
othermaciej, dunno if you noticed, but the vast majority of tests in the HTMLWG test suite were written by people in this channel
18:07
<jamesr>
i'm not sure what model does lead to a comprehensive test suite
18:07
<jamesr>
i would love to see it
18:07
<othermaciej>
CSS2.1 managed to have a comprehensive test suite
18:07
<jamesr>
!
18:07
<othermaciej>
but it took 5-6 years from entry to CR
18:07
<othermaciej>
well, fairly comprehensive
18:07
<jamesr>
how can it be comprehensive when the spec itself leaves vast swaths undefined?
18:07
<Hixie>
(bbiab.)
18:08
<Ms2ger>
CSS2.1 doesn't have anything near a comprehensive test suite
18:08
<Ms2ger>
It's got something better than CSS2, that's about the best thing you can say about it
18:08
<jgraham>
othermaciej: The W3C model doesn't either
18:08
<othermaciej>
I think I'd probably claim that it's the most comprehensive test suite for any core web standard of similar complexity
18:08
<jgraham>
And making the testsuite a Process criterion sets all sorts of perverse incentives
18:09
<Ms2ger>
Maybe
18:09
<jgraham>
I... I actually don't think that is true
18:09
<othermaciej>
what's the counter-example?
18:09
<Ms2ger>
But "most comprehensive" doesn't imply "comprehensive", even if it is
18:09
<jgraham>
At least, I don't think that our internal testsuite for CSS 2.1 is better than our testsuite for other things
18:09
<othermaciej>
I accept that it's valid to claim it is not comprehensive enough
18:09
<jgraham>
s/internal//
18:10
<jgraham>
I mean I think the Opera-internal-ought-to-be-released drag and drop testsuite might be better
18:10
<othermaciej>
ok, "most comprehensive public cross-browser test suite for any core web standard of similar complexity"
18:10
<jgraham>
I think the 2D API testsuite might be better
18:10
<jamesr>
philip's canvas suite?
18:10
<othermaciej>
I don't think I would agree that just drag & drop or just 2D API is of similar complexity to CSS
18:11
<Ms2ger>
It probably is
18:11
<jgraham>
Sure, these are patchy things
18:11
<othermaciej>
I would agree that all of HTML is of greater complexity, and all of SVG is of similar complexity
18:11
<jgraham>
AryehGregor's DOM Range testsuite
18:11
<othermaciej>
and perhaps all of DOM, at least as DOM4 scopes it
18:12
<othermaciej>
just DOM Range? probably not, it's a tiny corner of the platform (though one with many edge cases)
18:12
<jgraham>
My point is that for the things where people have invested serious effort in testing that are not CSS the testsuites are often better than the CSS2.1 testsuite despite the lack of a strong Process driver
18:12
<jgraham>
othermaciej: I am not claiming that these things individually are better than the whole CSS2.1 testsuite
18:12
<othermaciej>
true, so it might be that the market does not believe most aspects of HTML do not need a serious test suite
18:13
<jgraham>
It might be that we haven't done enough to encourage people to submit the tests that they are writing anyway
18:14
<jamesr>
one strong motivation for building a good test suite is you want to create a new implementation, and i think nobody is attempting that for HTML
18:14
<jgraham>
e.g. WebKit contributers have not -- in general -- been a great source of public tests
18:14
<jgraham>
But I assume you *have* tests
18:14
<Ms2ger>
Neither have we, to be fair
18:14
<jgraham>
We haven't been as good as I would like (see comment about drag and drop)
18:14
<Ms2ger>
(I think most of the WebGL test suite came from WebKit, though)
18:15
<jamesr>
Ms2ger, an example of writing a test suite to pull up an implementation
18:15
<Ms2ger>
At least, they use the same horrendous test harness
18:15
<othermaciej>
well, we have a lot of public tests, but most are not designed to be good cross-browser standards tests
18:15
<jamesr>
if you already have something big that a bunch of people sort of do, it's harder to bother
18:15
<jgraham>
jamesr: There are so many areas that have really crappy interop
18:15
<jgraham>
and people bugfix those areas
18:15
<Ms2ger>
Heh
18:16
<Ms2ger>
Are there areas that don't have really crappy interop?
18:16
<jgraham>
and they aren't in the mindset of "I should contribute this test I wrote to verify the behaviour matches the spec and the spec matches what's needed"
18:16
<jgraham>
See, for example, smaug____'s history navigation test from earlier
18:17
<jgraham>
4 implementations, 3 behaviours, spec matches 2 implementations, no tests
18:17
<othermaciej>
at times, WebKit contributors would prefer to modify our local copies of imported standards test suites than to make the desired changes upstream
18:17
<jgraham>
Also, lots and lots of things are greenfield developments e.g. IndexedDB
18:17
<othermaciej>
I try to encourage people to do the fixes upstream when possible, but that's not always an easy sell
18:18
<jgraham>
othermaciej: Making that an easy sell seems vastly more important to me than what the HTMLWG Process is
18:18
<Ms2ger>
I just tell them I'll overwrite their changes next time I import some tests
18:20
<jgraham>
(of course it depends what the reason is whether I can do anything about it. If the reasoning is "I think we should kep our tests proprietary to screw over the other vendors", there's not much I can do to help)
18:21
<jgraham>
(but if it's more like "the process for uploading them is a bit tedious", there might be a technical solution)
18:21
<othermaciej>
webkit tests are all in a public repository under a liberal license, so it's definitely not a question of keeping them proprietary
18:22
<othermaciej>
just lack of desire to expend greater effort and wait longer for results
18:22
<othermaciej>
(at least, I don't believe Apple has secret proprietary correctness tests for WebKit, and I doubt other vendors do either)
18:24
<smaug____>
jgraham: sorry about not uploading those tests to anywhere
18:24
<smaug____>
(although, those tests are old)
18:25
<jgraham>
"proprietary" might be the wrong word. Someone could have an attitude of "why should I do something that will help other vendors" even when the stuff is in a public repo. because it is much less likely that someone will comb through all your tests looking for ones that are valuable than it is that someone will use a test posted to a shared repo.
18:25
<smaug____>
(and I don't know where I could upload the tests)
18:25
<jgraham>
smaug____: I didn't mean to single you out, except to point out that you wrote some useful tests :)
18:26
<jgraham>
If you wanted to upload them they would go in the W3C html test repository which is dvcs.w3.org/hg/html
18:26
<othermaciej>
it's more like "I'm trying to fix this specific problem right now, and it's not worth it to me to expend extra effort and wait longer"
18:26
<smaug____>
you can blame me :) I was testing session history quite a bit when I changed Gecko's implementation to behave more like IE
18:27
<jgraham>
smaug____: But in the specific case that you linked I will write some automated tests using the standard harness
18:27
<jgraham>
So if you have more similar tests email me a link or something
18:27
<jgraham>
othermaciej: Right. I understand that but I don't really know what to do about it
18:27
<smaug____>
jgraham: if I had some tests using the standard harness, where should I upload them?
18:28
<othermaciej>
I think having a person where part of their job responsibility is to upstream tests to standards groups might help
18:29
<jgraham>
smaug____: http://dvcs.w3.org/hg/html under /tests/submission/Mozilla
18:29
<smaug____>
I wonder if I have access to that one
18:30
<jgraham>
othermaciej: Right. It works sort of OK at Opera because we have more people in dedicated QA roles
18:30
<smaug____>
would I need to be member of html wg? (which I certainly don't want to be)
18:30
<jgraham>
And I (plus others) have pushed for "submt tests to W3C" to become a normal part of that job
18:30
<jgraham>
Although we don't always achieve it
18:30
<othermaciej>
speaking of which, Apple is hiring for various roles where creating tests and submitting tests to standards groups would be part of the job
18:31
<jgraham>
smaug____: I think you would need to be
18:31
<othermaciej>
not reporting to me personally, but if anyone wants to do that sort of thing, or has a good person to refer, let me know
18:31
<jgraham>
smaug____: Lots of paranoia from certain parties that someone might slip something into the repo without agreeing to the CLA
18:32
<jgraham>
smaug____: But I guess you can always ask me or Ms2ger or hsivonen or someone to commit for you
18:33
<smaug____>
k
18:33
<Ms2ger>
I'm not in the HTMLWG, and I have access
18:34
<Ms2ger>
Not sure what the exact requirements are, MikeSmith might know
18:34
<jgraham>
Maybe you just have to agree to the licensing thing
18:34
<Ms2ger>
But yes, feel free to throw any tests at me
18:34
<jgraham>
I will try to find it on one of the 26 different wikis
18:35
<Ms2ger>
Using testharness.js is nice, but not required ;)
18:36
<jgraham>
smaug____: Oh, it looks like you might have access as long as you have some kind of W3C account with Mozilla listed as your employer
18:37
<jgraham>
I think it used to be WG members only but now isn't
18:38
<smaug____>
k
18:51
<jgraham>
(to return to an earlier point, I am pretty sure that in other WGs I have seen people suggest removing tests that touch on tricky or underdefined behaviour so they could get to Rec. without fixing implemenations / the spec)
21:19
<tantek>
jgraham that has indeed happened, and CSS 2.1 is an example.
21:21
<tantek>
though in those cases the tests that touch on tricky or underdefined behavior were captured for specifying in the respective CSS3 modules. Once done so, I could easily see those kinds of bug fixes working their way into errata.
21:57
<Hixie>
wtf
21:57
<Hixie>
all the bugs filed from "User agent: Mozilla/5.0 (BlackBerry [...]" are bogus
21:57
<Hixie>
7 now, over the last year
21:58
<Hixie>
make that 12