00:00
<Hixie>
it's not about other people blaming you
00:00
<Hixie>
it's about you blaming you
00:00
<Hixie>
naturally if you don't care, it doesn't help
00:00
<Hixie>
but if someone doesn't care, they're not gonna do a good job regardless
00:01
<webr3>
so then, what if there was a process where people could opt-in to resolving the issues under and action (even from outside the relevent groups) and resolve the issues quickly + take the blame as it were?
00:01
<annevk>
the other thing is that getting help is unlikely
00:01
<webr3>
afaik the w3c is opening up to make it easier for people from different groups to contrib to any other group
00:01
<annevk>
I have requested help on several topics quite a few times and nothing ever comes of that
00:02
<webr3>
maybe the wrong channels are being asked in, or maybe people think "that doesn't mean me" (even thought they want to)
00:02
<annevk>
you have to do things yourself if you want to get things done on certain topics
00:02
webr3
knows for a fact it's the second case often
00:02
<annevk>
for HTML5 the dynamics might be somewhat different though -- at least people seem to write change proposals and such
00:03
<annevk>
webr3, it's hard to tell
00:04
<Hixie>
webr3: what kinds of issues do you have in mind for "a process where people could opt-in to resolving the issues under and action"?
00:04
<webr3>
any long standing issue that can't be resolved quickly and to which there isn't an obvious solution
00:05
<Hixie>
like what?
00:05
<annevk>
defining a P2P UDP-like protocol
00:05
<annevk>
would be one I'd like to see
00:05
<Hixie>
isn't that one pretty much under control?
00:05
<annevk>
oh, and UDP Web Sockets
00:06
<annevk>
is it?
00:06
<Hixie>
rtc-web seems to be making progress
00:06
<webr3>
html5 spec being in html5, the whole prefixes thing, the dual mit/licensing, updating of the specs regularly on w3c, literally anything that just needs somebody to work on it
00:06
<webr3>
can't understand why a list isn't just published saying "we need these things worked on" by anybody, that means you, if you'd like the job just say
00:06
<Hixie>
webr3: the html5 spec being in html5 isn't something that anyone could resolve -- the problem is that the w3c staff have set a rule and that they won't change it
00:06
<annevk>
TIL about http://rtc-web.alvestrand.com/
00:06
<Hixie>
webr3: how could anyone resolve that?
00:07
<Hixie>
webr3: i mean, the spec is written in html5, i literally run a script to remove the html5ness and backport it to html4 before publishing on the w3c site
00:07
<Hixie>
the whatwg one is html5
00:07
<annevk>
oh wait, I heard about that workshop
00:07
<annevk>
Philip wasn't too enthusiastic
00:08
<Hixie>
webr3: and the whole prefixes thing is already resolved, as far as i can tell, except that some people disagree... so how could anyone "resolve" that?
00:08
<webr3>
well imho it should be in html5, it's /not/ a standard yet so doesn't matter if it's not in the current standard of html, and when it is a standard, it will eb the standard and people will expect it to be in html5, as a demo reference even
00:08
<Hixie>
webr3: and the licensing thing, again, is w3c staff saying "no", it's not something anyone could just solve (the whatwg spec is already licensed under a free license)
00:09
<webr3>
are there reasons for the "no" that are valid?
00:09
<webr3>
if not, then that "no" should be raised as an issue
00:09
<Hixie>
not to my knowledge, but i'm sure the people saying "no" think there are
00:09
<Hixie>
but in short, i don't see how "a process where people could opt-in to resolving the issues under and action" would resolve any of these issues
00:10
<webr3>
well it would if the w3c staff agreed to the process and backed it...
00:11
<Hixie>
given a situation where the w3c doesn't want something to happen (e.g. publishing the html5 spec as contemporary html rather than html4), i don't see how to convince the w3c to form a process by which they could have their authority overriden
00:13
<webr3>
it's a standardization body which standardizes approaches when there are conflicting implementations, w3c is just an implementation of a standardization body, and if there are conflicts then they should be standardized, not just say this ones right and that ones wrong
00:13
<webr3>
that includes the w3c itself
00:14
<webr3>
if people on the web can't say "no, thats wrong, you need to look again" and be taken seriously, then they're doing the job wrong, and that needs addressed
00:15
<AryehGregor>
webr3, all the things you mentioned are just points of disagreement between the W3C and WHATWG. They're matters of opinion, they're unlikely to change.
00:16
<AryehGregor>
It's not a procedural issue. Process can't eliminate differences of opinion, only rule in favor of one side or the other.
00:17
<AryehGregor>
Which is what has happened, except that there are two different organizations (because of bad decisions made by the W3C that triggered a breakaway) and they resolved some of these issues different ways.
00:17
<webr3>
well somebodies got to be thinking positively and that the disagreements can be resolved :)
00:17
<webr3>
so resolve all the difference and join back up..
00:17
<AryehGregor>
Are you advocating the position that if everyone just thought positively and talked it out, they'd all come to agreement on every issue?
00:18
<webr3>
not everyone, but the majority of free thinking individuals would - why not..
00:18
<annevk>
ever heard of politics?
00:18
<webr3>
i mean they all essentially want the same thing, lest they're in a cabal
00:18
<Hixie>
we have "joined back up"
00:18
<AryehGregor>
Because that seems like it's pretty obviously not how the real world works. Differences of opinion are commonly intractable. The best you can hope for is to pick someone's opinion to go with according to some process that hopefully doesn't leave too many people entirely dissatisfied.
00:18
<Hixie>
all the issues you raised are issues in the htmlwg, not issues between the whatwg and the htmlwg
00:19
<Hixie>
they're purely w3c-internal issues
00:19
<webr3>
annevk, i have, but I don't believe in politics, don't care for them, and it does nobody any good at all - screw the politics
00:19
<annevk>
standards is often politics
00:19
<AryehGregor>
webr3, politics demonstrates that intelligent people will not come to agreement on important issues even after extensive discussion.
00:19
<annevk>
at least in my experience
00:32
<karlcow>
when you edit and you ask for help, there is the way you ask and/or structure the help. If you tell people can you edit this section. That doesn't work. If you say can you edit this section following this model it is a bit better. Still need a bit of seduction :p
00:34
<karlcow>
a bit of politics, a bit of drama queen, a bit of bad memories, a bit of dick contest, a bit of technical sound argument, etc. :) Standards are made of flesh, sweat and thoughts.
00:35
<AryehGregor>
Is the disabled attribute for <option> a new HTML5 feature?
00:35
<Hixie>
no
00:36
<AryehGregor>
Why does Chrome seem to ignore it while Firefox 4 and Opera 11 don't, then?
00:37
<Hixie>
bug, i guess
00:37
<Hixie>
what does webkit/safari do?
00:37
<AryehGregor>
Well, the UI lets you select it just like any other option.
00:37
<AryehGregor>
Didn't test submitting.
00:37
<AryehGregor>
data:text/html,<!doctype html><select><option disabled>A</option><option>B</option></select>
00:37
<AryehGregor>
In Firefox/Opera, A is grayed out and unselectable, and B is selected by default.
00:37
<Hixie>
oh that's a more subtle issue than whether it works or not
00:38
<Hixie>
html4 (as usual) was very vague about what should happen if the first option was disabled, iirc
00:38
<Hixie>
anyway the new html spec defines all that
00:38
AryehGregor
discovers <optgroup label="">
00:39
AryehGregor
guesses he never actually looked into any of this before
01:05
<annevk>
karlcow, politics includes all of those :) well, maybe except technical arguments :p
01:06
<karlcow>
;)
01:43
<Dashiva>
Damn you, semantics
01:43
<semantics>
Damn you, Dashiva
01:44
<Dashiva>
no u
01:44
<Hixie>
hey now
01:44
<Hixie>
no spelling "you" as "u"
01:48
<Dashiva>
It's an idiom
01:48
<Dashiva>
Thus the lowercase 'n' as well
01:49
<Dashiva>
"A little confusingly, that text is marked up with HTML, which is very similar to XML. XML and HTML are basically brothers, they’re based on the same older work (SGML), except that XML is like the Borg and tried to assimilate HTML in the early ’00s (XHTML) and then the Federation (web nerds) realized that was a crappy idea and set off at maximum warp (let’s go build some awesome things
01:49
<Dashiva>
and let the documentation catch up later) in a different direction (HTML5) and soon it’ll be holodecks for everybody (canvas, video, audio tags) and fire photon torpedoes at the Ferengi (Flash). Exactly like that."
02:12
<boxendirst>
Nice, Dashiva
04:29
<oojacoboo>
wow, I have chrome showing the browser behind it through certain sections on the page that are flash (I think flash)
04:30
<oojacoboo>
so, it's like the flash elements are making the browser window see through
04:30
<oojacoboo>
the weird thing is, scrolling scrolls the browser behind it too...
04:32
<heycam>
oojacoboo, a recent firefox?
04:33
<oojacoboo>
the browser behind is the latest beta
04:33
<oojacoboo>
of firefox, yes
04:33
<heycam>
oojacoboo, it's probably https://bugzilla.mozilla.org/show_bug.cgi?id=590568
04:34
<oojacoboo>
well, it's happening in Chrome
04:34
<oojacoboo>
not firefox
04:35
<oojacoboo>
infact, it will show anything through it, entirely transparent in sections of the browser which are flash
04:35
<heycam>
happens in chrome and firefox?
04:35
<heycam>
(or i misinterpreted the "of firefox, yes")
04:35
<oojacoboo>
only in chrome for me
04:35
<heycam>
ok
04:35
<heycam>
then I don't know anything about it :)
04:36
<oojacoboo>
yea, I think it's flash crashed or something and it just doesn't know what to render in it's place
04:36
<oojacoboo>
somehow the default didn't get loaded up or something
06:56
<Hixie>
is there any sort of pass-by-reference in js?
06:56
<Hixie>
i have three variables that i need to pass to a function for the function to update all three variables
06:57
<Hixie>
(but which three variables need changing depends on the call site)
06:57
<heycam>
Hixie, best you'll get is to pass in an object for the function to set properties on
06:57
<Hixie>
bummer
06:57
<Hixie>
oh well
06:57
<Hixie>
thanks
08:59
<Hixie>
hm
09:00
<Hixie>
i just noticed that <canvas> acts as a phrasing element in the parser, which means you can't put e.g. paragraphs inside it
09:00
<Hixie>
that's problematic
09:01
<Hixie>
(for accessibilty, i mean)
09:03
<Hixie>
i guess we could make canvas scoping
13:40
<annevk>
Dashiva, where is that Star Trek quote from?
13:41
<Dashiva>
http://push.cx/2010/xml-crash-course
13:45
<annevk>
sweet
15:18
<gsnedders>
Time to do some html5lib hacking
15:18
<gsnedders>
(Why do I seem to do this on long-distance buses in Sweden?)
15:19
<Philip`>
(Because short-distance buses don't give you enough time to hack?)
15:20
<gsnedders>
(No, because most other long-distance buses spend too much time off motorways and hence hacking would make me sick)
15:21
<gsnedders>
(And short-distance buses have the same issue)
15:25
<annevk>
back in Sweden?
15:32
<gsnedders>
annevk: I'm here over New Year
16:21
gsnedders
is getting close to having a consistent, namespace aware, API for attributes in treewalkers in html5lib
16:26
<gsnedders>
And then I guess we need to get foreign content working in the serializer
18:14
<AryehGregor>
You know, the possibility of encoding something in UTF-8 with more bytes than necessary never even occurred to me.
18:15
<AryehGregor>
Like encoding null as 0xc0 0x80 or 0xf0 x080 0x80 0x80 or whatever.
18:15
<AryehGregor>
I guess this sort of crazy thing lets you easily distinguish random byte strings from UTF-8, though, so it's good.
18:22
<gsnedders>
Anything but shortest form is invalid, though
18:23
<AryehGregor>
Yeah, apparently.
18:23
<annevk>
gets FFFD
18:23
<AryehGregor>
Now, why is it that Linux SIGKILLs processes when it runs out of memory and every other OS apparently just starts failing allocations?
18:24
<AryehGregor>
I mean, I know why Linux does it. It's so that it can overallocate memory on the theory it won't be used.
18:24
<Philip`>
Failing allocations sounds bad for security, since most programmers don't bother checking return values
18:24
<AryehGregor>
But I wonder why other OSes don't follow that logic too. Or if there are drawbacks, why isn't Linux ever normally configured to fail allocations?
18:25
<Philip`>
and it probably means all your applications will fail and crash at once, rather than the OS just killing one
18:25
<AryehGregor>
Yeah, that's what I've always thought.
18:25
<AryehGregor>
It seems like it's much simpler to just pick one thing to kill and let everyone else continue on happily, especially since it's usually one process that's hogging the memory, often in a rampant memory leak or such.
18:26
<AryehGregor>
Although it would be nice if it would send a catchable signal first, maybe, so the process had a second or two to reduce memory usage before being killed.
18:26
<Philip`>
Maybe other OSes were designed by people with the naive idea that application programmers will design their code to respond gracefully when any one of their millions of lines of code that allocate memory fails
18:28
<AryehGregor>
But why has no one caught on to Linux's brilliance in this regard yet?
18:28
<AryehGregor>
Actually, I think that when Windows runs low on memory, it just starts extending the swap file on the fly.
18:29
<AryehGregor>
That's kind of crazy, though.
18:29
<Philip`>
https://developer.mozilla.org/en/Infallible_memory_allocation - it looks like Mozilla originally tried to handle allocation failures but is now giving up and declaring that they'll never fail
18:29
<AryehGregor>
So basically just adopting Linux behavior on all platforms.
18:31
<Philip`>
We ought to get hot-pluggable RAM and then the OS can freeze and pop up an error message saying "out of memory, please insert more RAM! (c)ontinue, (a)bort"
18:32
<AryehGregor>
Linux has some notion of hot-swapping RAM. But I think it only actually works for VMs, not physical hardware.
18:33
<AryehGregor>
I think it does theoretically support CPU hot-swapping. I've always wanted to see if that works on x86.
18:33
<AryehGregor>
Because that would be so cool.
18:33
<AryehGregor>
(clearly, you need at least two CPU sockets for this to be practical)
18:34
<Philip`>
I'd think it's incredibly unlikely that the hardware will support that instead of e.g. blowing up when you've only got half the pins in
18:35
<Philip`>
(when it's x86, not some clever expensive mainframe type thing)
18:35
<AryehGregor>
Well, SATA supports hot-swapping, I've done that all the time.
18:35
<AryehGregor>
I've installed a new disk and moved my root filesystem to it while my machine is running, more than once.
18:36
<AryehGregor>
So I don't see why CPUs couldn't support hot-swap too. Although you're right that they probably don't.
18:36
<AryehGregor>
I'd have to try it on a multi-socket machine that still works but that's being thrown out or something, I guess.
18:38
<Philip`>
I agree they could be designed to support it (and I'm sure I've heard of some that are), but normal x86 CPUs aren't (since it's not a feature anybody will ever use)
18:39
<AryehGregor>
http://www.kernel.org/doc/Documentation/cpu-hotplug.txt
18:39
<Philip`>
Even the physical design probably makes it impossible - you usually have to pull off the fan and heatsink before removing/inserting the CPU from the socket, and the CPU will melt itself while you're doing that
18:40
<AryehGregor>
"CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs."
18:40
<AryehGregor>
Hmm.
18:40
<AryehGregor>
ACPI makes it sound like x86.
18:40
<AryehGregor>
Philip`, not if the kernel can tell the hardware to power down the CPU first.
18:41
<AryehGregor>
Clearly you have to tell the kernel before you try to remove the CPU, otherwise the kernel state on that CPU will be lost and it will have to panic.
18:41
<AryehGregor>
I guess ACPI is used by IA64 too.
18:43
<Philip`>
http://www.linux-kvm.org/page/CPUHotPlug - "There are very few physical machines that actually support it. (Only one unisys box I know of),"
18:43
<AryehGregor>
:(
19:07
<Dashiva>
Dear lazy IRC, how can I make firefox open new tabs instead of new windows from window.open?
19:07
<Dashiva>
"Open new windows in a new tab" seems to have no effect
19:10
<bga_>
gt#firefox
19:10
<bga_>
:)
19:10
<Dashiva>
See, that would be work, which is what lazy IRC is supposed to avoid
19:11
<annevk>
1. download Opera. 2. ... 3. profit!
19:11
<bga_>
++
19:11
<Ms2ger>
-- :)
19:12
<bga_>
= +Infinity :P
19:14
<Dashiva>
annevk: I downloaded Opera years ago, and firefox still doesn't open tabs instead of windows
19:15
<Ms2ger>
Dashiva, seems like it should work
20:09
<Hixie>
AryehGregor: long-form UTF-8 were a sneaky security problem back before people had really realised the risk
20:10
<Hixie>
you could smuggle in ASCII characters without people noticing because they were doing byte filtering, not supporting UTF-8 in their filter
20:11
<AryehGregor>
So now they aren't interpreted as ASCII characters, is the point.
20:12
<AryehGregor>
By the way, here's a first pass at an atob() spec. Comments appreciated, both as to accuracy and the style of the prose (the actual formatting is obviously going to match whatever spec it's put in): http://aryeh.name/tmp/spec.html
20:20
<Hixie>
s/ul/ol/, s/has code point/have code points/, s/255/U+00FF/
20:21
<AryehGregor>
I prefer ul, since I don't actually refer to the numbers anywhere.
20:21
<Hixie>
at "treat the three-character string pointed to by /position/" you may not in fact have a three character string
20:21
<AryehGregor>
Yeah, that wording is messy.
20:21
<Hixie>
ul means the order doesn't matter, which isn't the case :-)
20:22
<Dashiva>
ol styled to use disc?
20:22
<AryehGregor>
That's an excessively dogmatic way of interpreting the semantics.
20:22
<Hixie>
that's not "excessively dogmatic", it's exactly what the spec says :-)
20:22
<Hixie>
that's the difference between ul and ol
20:22
<AryehGregor>
I know, I think the spec is excessively dogmatic on these points. :)
20:22
<Hixie>
ul = unordered, ol = ordered
20:23
<AryehGregor>
When it comes to something like the distinction between ul and ol, you want to ask "How do you want browsers, screen readers, non-CSS text browsers, etc. to render it?", not get into hypothetical semantics.
20:23
<Hixie>
anyway, continuing with my review :-), i recommend finding another way of phrasing 4.2 so that you don't need the phrase "and so on"
20:24
<Hixie>
also 4.2 confuses characters and bytes
20:24
<Hixie>
U+0000 is not a null byte, it's a Unicode character NULL with codepoint U+0000
20:24
<gsnedders>
So… I'm wondering what to do with the html5lib serializer test data… should I change it to match the treewalker changes in Python? It doesn't really work with namespaces as it is now…
20:24
<AryehGregor>
Yeah, I've been working with C too much lately. :P
20:25
<gsnedders>
jgraham: See above. (Or ping me when you're around)
20:25
<jcranmer>
Hixie: I would disagree with you
20:25
<jcranmer>
s/has code point/has a code point/
20:26
<Hixie>
AryehGregor: not really sure what a better way of phrasing 4.2 is, off-hand... probably it just needs to be made more explicit
20:26
<Hixie>
AryehGregor: spec-writing 101: your goal is to write text that no hostile implementor can argue (even in bad faith) means something other than what you intended
20:26
<AryehGregor>
I agree, but I'm thinking there's a more creative (i.e., less horrible) way to do it.
20:27
<AryehGregor>
Actually, I wonder why we don't just spec things like this as working JavaScript programs.
20:27
<AryehGregor>
Has that ever been contemplated?
20:27
<Hixie>
AryehGregor: so things like "and so on" are dodgy because it's easy for people to argue that the expansion of the pattern is something other than you intended
20:27
<jcranmer>
I wonder if you can spec it without being so detailed in the algorithm
20:28
<Hixie>
AryehGregor: the problem with speccing as code is that you have to include the definitions of _everything_ you use. for example, consider a spec that said:
20:28
<AryehGregor>
That's what I was thinking. Breaking up three bytes into four six-bit chunks is kind of dead simple.
20:28
<jcranmer>
basically, convert the input string to a series of octets in ISO 8859-1 standard (throwing an error if a character exists outside that range)
20:28
<jcranmer>
and then return the base64 encoding of that set of octets, as according to [base64]
20:28
<AryehGregor>
That's not correct, though.
20:29
<Hixie>
AryehGregor: "this function must return the equivalent of function foo(a) { Math.sin(a) }"
20:29
<AryehGregor>
It's done by Unicode characters, not ISO 8859-1.
20:29
<jcranmer>
whatever the charset is that is most translatable to UTF from x00 to xFF
20:29
<gsnedders>
Hixie: Probably bad example, seeming Math.sin is implementation defined approximation of sin
20:29
<AryehGregor>
Also, what Base64 standard to use? There are apparently various convention.
20:29
<jcranmer>
the RFC base64
20:29
<Hixie>
AryehGregor: an implementor would then have to decide what to do if the function was invoked in a context where Math was rebound to something different entirely by some JS code
20:29
<AryehGregor>
conventions.
20:30
<AryehGregor>
Ouch. I forgot how evil JavaScript is.
20:30
<gsnedders>
(except for a number of ±0, AFAIK)
20:30
<Hixie>
AryehGregor: anyway, long story short, using english ends up being less ambiguous
20:30
<gsnedders>
AryehGregor: That's not very evil at all.
20:30
<AryehGregor>
Surely that much you could define away, though.
20:30
<jcranmer>
AryehGregor: http://tools.ietf.org/html/rfc4648#section-4
20:31
<Hixie>
AryehGregor: the question is how much more prose is it to define it all away than it is to just use english in the first place :-)
20:31
<Hixie>
AryehGregor: and whether it ends up actually helping
20:31
<AryehGregor>
You can reuse the same prose definitions to clarify all your code definitions.
20:31
<AryehGregor>
So it's amortized.
20:31
<Hixie>
AryehGregor: treating the reader as someone who is going to intentionally try to misinterpret what you have written is a good way of making sure you are unambiguous
20:32
<Hixie>
AryehGregor: well, if you can find a way to make it work, go for it :-)
20:32
<Ms2ger>
Hixie, only problem is that when you're used to that, CSS specs are unreadable
20:32
<AryehGregor>
Hixie, it's also a good way of inflicting suffering on the large majority of your readers who are not in fact malicious. :)
20:33
<AryehGregor>
Yes, that's also a problem. All specs not written by Hixie or someone following his style are now infuriatingly vague.
20:33
<AryehGregor>
But such is the price of progress.
20:33
<jcranmer>
unfortunately, you start to lose sight of what things actually means
20:33
<Hixie>
Ms2ger: yeah, well, that's a real problem regardless.
20:33
<Hixie>
Ms2ger: and i say that as someone who used to write css specs :-)
20:33
<jcranmer>
base64 is much more easily understood if you think of it has merely reencoding it as 6-bit bytes intead of 8-bit ones
20:34
<Hixie>
AryehGregor: yeah, you have to try to find a way to keep things readable at the same time, that's why spec writing isn't easy :-)
20:34
<Hixie>
gotta go get lunch ready, bbiab
20:34
<AryehGregor>
Okay, how about this new text: http://aryeh.name/tmp/spec.html
20:35
AryehGregor
clarifies the wording slightly to be pedantic
20:35
<AryehGregor>
There, clarified a bit.
20:36
<AryehGregor>
Actually, I'll just quote it: "If the input string contains any character whose code point is strictly greater than U+00FF, throw an INVALID_CHARACTER_ERR exception. Otherwise, convert it to a binary string whose nth byte is the eight-bit code point of the nth byte of the input string, apply the base64 algorithm to that binary string, and return the result."
20:36
<AryehGregor>
jcranmer++
20:36
<AryehGregor>
Er.
20:36
<AryehGregor>
That last "byte" should be "character", of course.
20:36
AryehGregor
gets back to writing tests
20:37
<gsnedders>
What's the eight-bit code point of U+FFFF?
20:37
<jcranmer>
gsnedders: thats an invalid character
20:37
<gsnedders>
Oh, duh
20:37
<AryehGregor>
gsnedders, it's already thrown an exception by that point.
20:38
<jcranmer>
I would s/byte/octet/g personally
20:38
<gsnedders>
"whose nth byte has the value of the nth character's code point"?
20:38
<gsnedders>
That's be clearer to me
20:39
<jcranmer>
unless something somewhere states that bytes are 8-bit value chunks
20:41
<AryehGregor>
Does anyone use "byte" to mean anything different these days?
20:41
<AryehGregor>
But okay, why not.
20:41
<gsnedders>
Hey, I implemented UTF-9!
20:41
<AryehGregor>
My condolences
20:41
<AryehGregor>
.
20:41
<gsnedders>
I did it for the hell of it ;P
20:43
<Hixie>
AryehGregor: looks good.
20:43
<jcranmer>
I came close to implementing UTF-7 once
20:43
<jcranmer>
stupid @#$@#$ing IMAP
20:44
<gsnedders>
UTF-7 didn't have the fun of UTF-9 to implement. People actually use it.
20:44
<Hixie>
AryehGregor: you're missing a "must" somewhere in there actually
20:45
<Hixie>
s/throw/the user agent must throw/ and s/convert/user agent must convert/
20:45
<jcranmer>
Hixie: don't you mean MUST? ;-)
20:45
<Hixie>
no
20:45
<jcranmer>
gsnedders: which is why it's so freakishly annoying
20:45
<Hixie>
i'm assuming whatever spec AryehGregor's text eventually ends up in will have http://www.whatwg.org/specs/web-apps/current-work/complete.html#conformance-requirements as its conformance section
20:46
<jcranmer>
I tend to prefer to capitalize the keywords just to make it clear
20:46
<jcranmer>
especially with the most annoying phrase in the world, "may not"
20:46
<Hixie>
i just don't use "may not"
20:46
<Ms2ger>
jcranmer, that's not defined by rfc 2119, don't use it
20:47
<jcranmer>
I use the term "might not" as much as possible
20:47
<gsnedders>
I might not use it much…
20:48
<Hixie>
jcranmer: (i once tried to make every MUST in the html spec be uppercase, and then tried small-caps, and in both cases the spec was completely unreadable as a result.)
20:48
<jcranmer>
perhaps I just don't use MUST enough
20:50
<gsnedders>
I should use "MUST" more.
20:50
<Ms2ger>
gsnedders, no, you must.
20:52
<AryehGregor>
No, he SHOULD use "MUST" more.
20:52
<AryehGregor>
But MAY wish not to.
20:54
<Hixie>
he MAY wish anything he wants :-P
20:54
<jcranmer>
it is RECOMMENDED that he do it, though
20:55
<gsnedders>
I want a unicorn jumping over a double rainbow!
20:55
<Ms2ger>
You MAY.
20:55
<Hixie>
hmm, RECOMMENDED. I should go through the spec and make sure I'm not abusing that.
20:55
<Hixie>
it's like SHOULD, right?
20:55
<gsnedders>
Right.
20:56
<Hixie>
a quick glance seems to indicate it's used somewhat appropriately
20:56
<Ms2ger>
"In this example a recommended retail price has been marked"? :)
20:57
<Hixie>
that's in a non-normative section
20:57
<Hixie>
i'm not gonna worry about RECOMMENDED in examples and such
20:57
<Hixie>
notes, yes
20:57
<Hixie>
but not examples
20:59
<AryehGregor>
Okay, does anyone else have more tests to suggest here? I'm finding it hard to be creative. http://aryeh.name/tests-root/tests/submission/AryehGregor/base64.html
20:59
<AryehGregor>
Oh, hmm, Firefox fails some.
21:00
<AryehGregor>
As does Opera.
21:00
<AryehGregor>
Yay, I found some more incompatibilities. Now I get to decide which to spec.
21:01
<Ms2ger>
Firefox just fails the assert_throws ones over here, which isn't related
21:01
<AryehGregor>
Can anyone help me decipher the Firefox error message? Maybe jgraham? "assert_throws: function () { btoa(input); } threw with code INVALID_CHARACTER_ERR (5) expected INVALID_CHARACTER_ERR (5)"
21:01
<AryehGregor>
That doesn't seem to make sense.
21:01
<Ms2ger>
It checks e.name
21:01
<AryehGregor>
Ms2ger, the last two are supposed to throw too.
21:01
<Ms2ger>
Which has NS_ERROR_DOM up front
21:01
<AryehGregor>
Oh, no, they aren't.
21:01
<AryehGregor>
Wait a sec, encoding issue with the last one.
21:02
<AryehGregor>
Okay, so the Firefox failures are a problem with the test harness and not me?
21:02
<AryehGregor>
I guess Opera is copying IE here. I'll try to figure out what they do.
21:03
<Ms2ger>
It's an irrelevant bug in Firefox
21:03
<jcranmer>
AryehGregor: I might suggest trying the tests with a charset that has codepoints > U+00FF
21:03
<AryehGregor>
jcranmer, what do you mean?
21:03
<AryehGregor>
Ms2ger, oh, okay.
21:03
<gsnedders>
AryehGregor: We don't seem to have many bugs on it, at least — pretty much only not throwing
21:04
<jcranmer>
AryehGregor: if they're doing page-specific encoding
21:04
<AryehGregor>
Well, I'd hope there couldn't be *too* many bugs in a base64 function.
21:04
<AryehGregor>
jcranmer, oh, so like seeing if the function's behavior depends on the encoding of the page? Interesting thought.
21:04
<jcranmer>
right
21:05
<jcranmer>
that's about the only non-obvious error I can think of
21:10
Ms2ger
wonders why DOM2Range handles cases where doctypes have children
21:15
<Hixie>
AryehGregor: one thing to test is outputs for inputs of various lengths to make sure the trailing =s are done right
21:16
<Hixie>
also, check astral plane characters, while you're at it -- there might be some weird UTF-16/surrogate issues
21:19
<jcranmer>
oh yeah, anything not in the BMP is liable to get wonky
21:19
<jcranmer>
forgot about that