00:17
<Philip`>
jamesr: It's defined by WebIDL
00:17
<Philip`>
Hopefully the tests match that behaviour
00:19
<jamesr>
ah, since they are defined as octet
00:19
<jamesr>
looks like only opera currently implements that part of WebIDL
00:20
<jamesr>
Philip`: 2d.text.draw.baseline.bottom is failing on ffx/opera/gecko - is that expected?
00:21
<jamesr>
ah, has it been updated?
00:22
<Philip`>
Apparently it passed for me in Firefox 3.7 on Linux some time ago
00:22
<Philip`>
Some browsers do get it wrong
00:23
<Philip`>
I don't remember updating it
00:23
<jamesr>
yeah, i was doing something wrong. bottom.html passes in minefield
00:23
<jamesr>
but ideographic and hanging fail everywhere
00:24
<Philip`>
As far as I'm aware, the test font is set up correctly for those and they're just not implemented
00:25
<jamesr>
ok
00:26
<Philip`>
(I assume nobody really cares about them - they're just in the canvas spec to match some CSS spec, I think)
00:27
<jamesr>
sucks to have it in the spec if nobody's doing it
00:30
<Philip`>
jamesr: I guess that applies to a lot of CSS3
00:34
karlcow
is reading about the evercookie nightmare http://samy.pl/evercookie/
00:35
<Dashiva>
It was pretty nightmare from the point flash added SharedObjects
00:38
<karlcow>
Dashiva: yep definitely. I think there will be new-adds on popping up.
02:21
<variable>
Dashiva, karlcow that attack is nothing new
02:21
<variable>
I recall reading something like that involving storing unique data in a .png file and reading it back from the cache to restore cookies some years ago
03:36
<karlcow>
variable: do you have a pointer? that would be cool.
03:37
<variable>
karlcow, I read it *years* ago
03:39
<variable>
I wish I had some method of saving bookmarks and searching thru them
03:40
<variable>
karlcow, what makes the attack so "amazing" now is 1) its all put together in a nice package 2) the public is starting to care ;-)
05:30
<ivan`>
what happens if a worker can't be started because of process limits? an Error thrown of some sort? (I don't see in the spec)
07:54
<MikeSmith>
Cache-Control: max-age=0 means "no caching", right?
07:57
<abarth>
think so :)
07:57
<abarth>
max-age=-10000
07:58
<abarth>
dont' cache it! not even in the past!
07:58
<MikeSmith>
heh
08:35
<annevk>
XBL5!
08:41
<abarth>
:)
08:42
<zcorpan>
annevk: the coersion rules break a lot more than html[xmlns] in css -- a browser would never use the coersion rules for web content
08:43
<zcorpan>
annevk: besides the bug was about xmlns:foo if i understood it correctly :)
08:48
<hsivonen>
validator.nu is going down for kernel update
08:49
<hsivonen>
annevk: browsers don't apply the infoset coercion rules anyway
08:49
<annevk>
he was talking about DOM
08:50
<hsivonen>
I understand that part of what we are doing is fixing stuff that the XHTML2 WG did in the HTML4 era, but it's really annoying that they've created new problems recently that we are now supposed to fix
08:53
<hsivonen>
validator.nu is back up. html5.validator.nu going down
08:54
<annevk>
it depends in how far you consider RDFa an actual problem I suppose
08:58
<hsivonen>
sigh. Jaunty's security updates end next month. I have to upgrade my servers soon.
09:02
<zcorpan>
didn't rdfa's prefixes="" solve the problem anyway?
09:02
<MikeSmith>
zcorpan: fwiw, I think I fixed the jumpy-headings problem -
09:02
<MikeSmith>
http://sideshowbarker.github.com/es5-spec/
09:03
<zcorpan>
MikeSmith: nice
09:03
<MikeSmith>
if you notice other problems or have suggestions, definitely let me know
09:04
<hsivonen>
zcorpan: maybe ask the question on the bug?
09:05
<hsivonen>
and html5.validator.nu is back up
09:09
<hsivonen>
http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Sep/0090.html
09:10
<hsivonen>
hasn't Hixie proposed Microdata?
09:11
<zcorpan>
maybe the implication is that microdata doesn't deliver what they need
09:11
<hsivonen>
might be
09:12
<annevk>
othermaciej, yeah, I'm hoping the person to write the counter-proposal is not going to be me
09:12
<othermaciej>
annevk: I'm just shaking the tree in the hope that a volunteer will fall out
09:13
<annevk>
in fact, I'm pretty sure it won't be as there are lots of other things to take care of
09:13
<annevk>
heh
09:14
<annevk>
so hybi is missing its self-impossed deadline of 4 weeks by a month?
09:14
<othermaciej>
it doesn't require a high degree of expertise to do it, someone would just need to carefully go over the discussion and make a specific proposal such as using the microformats.org wiki, plus a particular description of how registration goes, etc
09:14
<othermaciej>
what was the 4 week deadline?
09:15
<annevk>
there was this idea to define the base protocol in 4 weeks
09:15
<annevk>
and flush out extensions and other things in the next 6 months
09:15
<othermaciej>
I remember when Hixie suggested that
09:15
<annevk>
instead Hixie left and it went dead
09:15
<othermaciej>
I think the change of editors has rendered all previous plans inoperative and thrown open the gates to more features in the base protocol
09:15
<annevk>
and now everyone has implemented the framing of -76, including Firefox 4
09:16
<annevk>
and we'll likely be stuck with that for a long time
09:16
<othermaciej>
does -76 have the halfway-secure handshake?
09:16
<othermaciej>
I can't remember
09:17
<annevk>
-76 has the handshake with the 8 random bytes that were not part of the messaged
09:17
<annevk>
-d
09:17
<othermaciej>
ok
09:17
<othermaciej>
I guess the main thing that sucks about it is that the 8 bytes could break otherwise-working proxies without actually triggering a fast detectable failure
09:17
<annevk>
better than what Safari shipped (iirc), but still has the "incorrect" framing
09:18
<othermaciej>
I think we have -76 in WebKit trunk so we'll likely ship it in due course
09:22
<hsivonen>
othermaciej: will you be prefixing the API?
09:22
<othermaciej>
hsivonen: for WebSocket? unlikely...
09:23
<hsivonen>
othermaciej: ok
09:23
<othermaciej>
the API seems pretty stable, and we don't usually vendor-prefix things with a draft spec unless there is a lot of reason to expect they will change
09:24
<othermaciej>
and I am not sure prefixing the API would protect against future protocol changes
09:25
<othermaciej>
I did at one point suggest prefixing the protocol scheme, so you could use different URLs for different protocol versions, but that suggestion was not met with enthusiasm by WebKit developers
09:25
<annevk>
I emailed my concern to the hybi list
09:26
<annevk>
Opera will be shipping -76 relatively soonish by the way, but we can change the moment one of WebKit/Gecko changes relatively easily
09:26
<MikeSmith>
how do I completely clear my browser cache in Opera?
09:26
<zcorpan>
format c:
09:27
<annevk>
Tools -> Delete Private Data
09:30
<MikeSmith>
annevk: thanks
09:33
<MikeSmith>
annevk: hmm, in spite of checking Delete entire cache there and hitting the Delete button, when I go to opera:cache it still shows that it has files cached for multiple domains
09:35
MikeSmith
tries restarting his Opera
09:35
<MikeSmith>
ok, restarting Opera seems to clear it
09:42
<annevk>
You could file a bug. I have no idea how any of that is supposed to work.
09:42
<MikeSmith>
ok
10:01
<MikeSmith>
ok, I continue to have some behavior in Firefox and Minefield that I can't figure out
10:01
<MikeSmith>
if somebody can please try this and see if you can reproduce it, I'd appreciate it
10:01
<MikeSmith>
1. go to http://sideshowbarker.github.com/es5-spec/#x7.1
10:01
<MikeSmith>
2. hover anywhere over the "7.1 Unicode Format-Control Characters" text
10:01
<MikeSmith>
3. click the Ⓔ
10:01
<MikeSmith>
… pop-up displays a "Table 1 — Format-Control Character Usage" table
10:01
<MikeSmith>
4. click the up-arrow at the top right (next to the "x")
10:01
<MikeSmith>
… a new tab opens, showing an empty page
10:01
<MikeSmith>
5. open Firebug on that page and observe that despite not
10:01
<MikeSmith>
displaying anything, there is content in the DOM…
10:03
<hsivonen>
ooh <center>!
10:06
<hsivonen>
MikeSmith: how is that document created?
10:06
<hsivonen>
the one that doesn't show up?
10:08
<MikeSmith>
hsivonen: abbreviate version is this:
10:08
<MikeSmith>
var win = window.open();
10:08
<MikeSmith>
...
10:08
<MikeSmith>
var annoBody = win.document.importNode(document.getElementById("annotation"),true);
10:08
<MikeSmith>
win.document.body.appendChild(annoBody);
10:08
<MikeSmith>
win.document.close();
10:08
<jgraham>
gsnedders: yt?
10:09
<hsivonen>
MikeSmith: ok. that should work.
10:10
<hsivonen>
MikeSmith: I tested that it's not a frame constructor integration bug of the usual kind
10:10
<MikeSmith>
fwiw, the full source of the script is here - http://github.com/sideshowbarker/es5-spec/blob/gh-pages/anno.js
10:10
<hsivonen>
that is, setting body to display:none and back to block didn't make content show up
10:10
<MikeSmith>
OK
10:10
<MikeSmith>
I wonder if there's some other best-practice way I should be using instead
10:10
<MikeSmith>
for writing to a new window
10:10
<hsivonen>
MikeSmith: I think this one needs a bugzilla entry. Probably in the DOM component.
10:11
<MikeSmith>
hsivonen: OK
10:11
<MikeSmith>
will file it now
10:11
<hsivonen>
MikeSmith: thanks
10:11
<MikeSmith>
thanks for checking it
10:12
<MikeSmith>
btw, the <center> is from Open Office output from the MS Word source I generated that doc from
10:13
<MikeSmith>
I cleaned up a lot, but there's some other junk still in there that I probably should still move to CSS
10:13
<hsivonen>
MikeSmith: as a workaround, you could try calling .write("<!DOCTYPE html>"); .close(); on the newly-opened document before importing the nodes
10:13
<annevk>
can someone explain to me how upload events work for forms?
10:13
<annevk>
i mean, the page will be replaced by some other page right?
10:13
<annevk>
or is this mainly for encouraging people to submit to <iframe> instead?
10:13
<MikeSmith>
hsivonen: ah yeah, I will try that
10:13
<MikeSmith>
(after I file this bug)
10:15
<hsivonen>
now I have a guess
10:15
<hsivonen>
there might be a bug that if you don't .write(), layout never gets started
10:16
<MikeSmith>
oh
10:16
<MikeSmith>
lemme try now
10:16
<hsivonen>
the life cycle of the document and parser is sad in Gecko in the .open() case
10:17
<hsivonen>
a bunch of initialization happens on the first .write() instead of .open()
10:17
<hsivonen>
mainly because I was trying to conform to a legacy API instead of fixing the API
10:18
<hsivonen>
MikeSmith: oops. I misread your code
10:19
<hsivonen>
MikeSmith: your .open() call is on window instead of win.document
10:19
<MikeSmith>
aha
10:20
<hsivonen>
MikeSmith: my scientific wild-ass guess is that you are importing stuff into a synthetic about:blank document that hasn't had layout started for it
10:20
<hsivonen>
MikeSmith: try calling win.document.open(); win.document.write("<!DOCTYPE html>"); win.document.close(); before you import
10:21
<hsivonen>
and then removing the later win.document.close(); you have now
10:22
<MikeSmith>
OK
10:22
<MikeSmith>
will try it now
10:23
<MikeSmith>
hmm, first thing is, if I call window.document.open() it replaces the current window instead of opening a new window
10:23
<hsivonen>
MikeSmith: I meant calling it on the win variable you assigned the return value of window.open() into
10:23
<MikeSmith>
d'oh
10:24
<MikeSmith>
OK
10:24
<hsivonen>
if this still doesn't work, I suggest attaching a "load" event handler to win and running the rest of your method from that handler
10:24
<hsivonen>
MikeSmith: but clearly, there's a Gecko-side bug to fix here
10:25
<MikeSmith>
yeah, I will get the bug filed too
10:27
<david_carlisle>
Hi, is there a version of opera that does inline svg in html5? I tried http://www.nag.co.uk/blog_files/d02agf.html in 10.62, and it just shows the text of <desc> FF4 and IE9 work fine
10:28
<jgraham>
david_carlisle: Not yet
10:29
<david_carlisle>
ah, that's why it didn't work then:-)
10:31
<MikeSmith>
hsivonen: thanks much
10:31
<MikeSmith>
just changing the order of the .write seems to fix it
10:37
<hsivonen>
MikeSmith: good. must be something to do with starting layout then
10:37
<MikeSmith>
yeah, seems like
10:47
<annevk>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694 o_O
10:54
<zcorpan>
annevk: what?
10:55
<annevk>
forgot to leave my logic behind
10:56
<zcorpan>
heh
11:12
<jgraham>
Does anyone remember why <div><object>a</div> doesn't close the <object>? We have the HTML5 behaviour in current Opera and have a slight site compat. issue from it which Gecko+WebKit have just gained from implementing HTML5
11:13
<annevk>
presumably because IE/Opera made <object> scoping?
11:13
<annevk>
I suspect there might be issues either way
11:13
<annevk>
going from a single broken page with parsing is really tricky
11:14
<MikeSmith>
hsivonen: https://bugzilla.mozilla.org/show_bug.cgi?id=598895 (new bug for the issue you helped me with)
11:14
<MikeSmith>
hsivonen: thanks again for the help
11:15
<jgraham>
annevk: I know
11:15
<jgraham>
annevk: I was hoping I could say something in the bug other than "well changing parsing is hard and we can't make everything work"
11:15
<jgraham>
Which is true but kind of weak
11:18
<zcorpan>
jgraham: the question is whether there's another way with better site compat (e.g. maybe it should only be scoping for <p> and </p> but not for </div>)
11:19
<jgraham>
zcorpan: Indeed. But it is hard to tell from insignificant breakage on one site if that is a net win or not
11:19
<zcorpan>
yeah
11:19
<annevk>
I'm starting to lean towards abarth "stop tweaking it" pov
11:20
<jgraham>
I guess it might be closer to legacy gecko/webkit
11:20
<abarth>
:)
11:20
<zcorpan>
tweaking is the fun part :)
11:20
<jgraham>
Well me too, but it sucks to be the person trying to explain that we just have to live with it
11:21
<abarth>
welcome to the web
11:21
<abarth>
my name is adam
11:21
<abarth>
i'll be your host
11:21
<zcorpan>
GET /tagsoup HTTP/1.1
11:22
<zcorpan>
Host: adam
11:22
zcorpan
awaits response
11:23
<annevk>
402 PAYMENT REQUIRED
11:23
<abarth>
200 OK
11:23
<annevk>
aah
11:23
<abarth>
Content-Length: 27
11:23
<abarth>
Content-Length: 2394
11:24
<zcorpan>
crap, now i don't know when to stop reading :(
11:24
<abarth>
Good news: you're now just supposed to stop immediately and close the socket
11:26
<abarth>
:)
11:26
<hsivonen>
jgraham: I've filed a spec bug about that
11:26
<hsivonen>
jgraham: my guess is that Hixie's reverse engineering of existing browsers hasn't been perfect
11:27
<abarth>
zcorpan: :)
11:27
<hsivonen>
jgraham: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10427
11:30
<zcorpan>
hsivonen: iirc this is a case where i decided that opera should follow ie for compat with some site, so Hixie changed the spec to match
11:31
<hsivonen>
zcorpan: IE isn't as scoping as HTML5, either, IIRC
11:31
<abarth>
hsivonen: how come Firefox fails so many of the HTML5lib tests?
11:31
<abarth>
is that spec skew?
11:32
<zcorpan>
hsivonen: i think ie6 and ie7 (and maybe ie8) parsing of object depends on whether the plugin was used or not
11:32
<hsivonen>
abarth: the summary/figcaption stuff I haven't fixed, because there's the outstanding spec bug on <figure>
11:32
<hsivonen>
abarth: though I was planning on writing patches today anyway
11:32
<abarth>
ic
11:32
<hsivonen>
abarth: other than that, I have fixes in my queue
11:32
<hsivonen>
abarth: and they have review
11:32
<abarth>
i should sync the tests again
11:33
<abarth>
when should we change the "-- >" thing in html5lib
11:33
<hsivonen>
abarth: but only beta7 blockers are allowed to land
11:33
<hsivonen>
abarth: already changed
11:33
<abarth>
oh, good
11:33
<abarth>
beta7 gets cut from trunk?
11:33
<zcorpan>
hsivonen: in fact, <object> is sort of a cdata element in ie, iirc
11:34
<hsivonen>
abarth: I think we might branch first and bake beta7 on the branch for a few days, but for practical purposes, yes
11:34
<hsivonen>
zcorpan: oh
11:34
<abarth>
there have been some pretty major things landing between betas
11:35
<abarth>
like a new JavaScript engine
11:35
<abarth>
:)
11:35
<zcorpan>
i read ie9 changed parsing of <object>, i wonder if they now match html5 there
11:36
<hsivonen>
abarth: AFAICT, Firefox "beta" is what gets offered to a larger audience
11:36
<hsivonen>
abarth: can't really infer feature-completeness from "beta"
11:36
<abarth>
how does that differ from the nightly builds?
11:36
<abarth>
i guess they're more stable
11:37
<hsivonen>
abarth: stability and publicity
11:38
<abarth>
strange
11:38
<abarth>
why did html5lib remove test cases?
11:38
<hsivonen>
abarth: I moved some tests to new files
11:39
<hsivonen>
abarth: either because the tests were text editor-unsafe
11:39
<hsivonen>
abarth: or because the test changed ahead of spec
11:39
<hsivonen>
abarth: IIRC, I didn't remove any tests
11:39
<abarth>
i see the new files
11:39
<abarth>
l don't really have a good way of merging the files
11:39
<abarth>
i do it by hand
11:41
<hsivonen>
abarth: fwiw, I landed my queue of fixes to the htmlparser repo today and deployed them on validator.nu (but not livedom.validator.nu yet)
11:41
<hsivonen>
(I need to work around GWT UA sniffing bogosity to redeploy livedom)
11:42
<hsivonen>
I really wish GWT feature sniffed and loaded a bit more code
11:43
<hsivonen>
I can sympathise with wanting to load different code for IE6, but loading different code for WebKit, Gecko < 1.8, Gecko >=1.8 and Opera is BAD
11:43
<hsivonen>
and what's the deal with supporting Gecko < 1.8 anyway?
11:44
<hsivonen>
we should start calling window.console "HTML5 console" once it's in the spec :-)
12:01
<abarth>
tests pushed
12:01
<abarth>
not that much exciting
12:20
<hsivonen>
abarth|zZz: umm. It seems to me you pushed back bits that I had specifically moved to different files
12:21
<hsivonen>
abarth|zZz: specifically, in comments01.dat and entities01.dat
12:23
<abarth|zZz>
ah, sorry about that
12:23
<abarth|zZz>
feel free to fix it
12:23
<abarth|zZz>
we need a better process to merge changes
12:24
<hsivonen>
abarth|zZz: ok. I'll fix it at some point unless someone else beats me to it.
14:08
GPHemsley
unsubscribed from the WHATWG mailing list
14:09
<GPHemsley>
(signal-noise ratio too high for me, personally)
14:09
<GPHemsley>
(or is it low? anyway, too much I didn't care to read...)
14:10
<jgraham>
I guess you mean low
14:10
<jgraham>
Unless you are complaining that there is too mcuh technical discussion that is hard to have an opinion on
14:11
<jgraham>
and not enough useless bikeshedding that is fun for all the family
14:13
<hsivonen>
GPHemsley: what's been noise lately?
14:13
hsivonen
tuned the poster='' thread out
14:30
<Hixie>
sorry, been on vacation so haven't been able to tone noise down
14:30
<Hixie>
do i need to do anything on the poster thread?
14:31
<Hixie>
(i'm mostly back now btw, just going through massive mail backlog)
14:33
<hsivonen>
Hixie: I don't know. before I tuned out, the content of the thread was appropriate for the list. There were just an unusual number of messages.
14:34
<Hixie>
ah ok
14:34
<Hixie>
i'll take a look when i get to figuring out which folder it should go to shortly then
14:34
<Hixie>
and will see if anything needs doing
14:38
<MikeSmith>
jgraham: for the content of the actual annotations in the annotated ES5 doc, I'm wondering if the audience should be implementors and authors, or just implementors
14:40
<MikeSmith>
jgraham: example I thought of today was the fact that, e.g., parseInt("08") returns 0 and parseInt("010") returns 8
14:40
<MikeSmith>
etc.
14:40
<MikeSmith>
(because the leading zero causes parseInt to assume octal)
14:41
<MikeSmith>
and the spec doesn't state that explicitly
14:41
<MikeSmith>
so, I added an annotation for authors
14:41
<MikeSmith>
just saying, always supply the radix param
14:43
<MikeSmith>
but… I don't know if the annotations should end up being addressed both to implementors and authors, or if it should be just one or the other
14:44
<MikeSmith>
I guess the intended-for-author annotations could be marked up to indicate they are for authors -- class=author or whatever
14:45
<jgraham>
MikeSmith: Yeah, t would be helpful to annotate the spec with what is actually required for implementors too
14:45
<jgraham>
Work around the refusal of ECMAScript committee to fix bugs in the parts that they hope will go away in the future
14:45
<jgraham>
(bugs in the spec relative to reality I mean)
14:53
<MikeSmith>
ok
18:04
<jgraham>
Oh, hybi how I missed you
18:05
<Hixie>
what's up there?
18:15
<mokush>
hey, can anybody expand on the "label" for <track>?
18:15
<mokush>
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-track-charset
18:16
<Hixie>
expand how?
18:16
<mokush>
the definition in the spec is very very fague
18:16
<mokush>
at least to me
18:18
<mokush>
is it a sort-of invisible title attr?
18:23
<Hixie>
mokush: oh you mean "what does it do?"?
18:38
<Hixie>
mokush: it basically decides what the browser's name for the track will be
18:38
<Hixie>
mokush: in its menus and stuff
18:38
<Hixie>
(sorry for the delay, i'm in and out here)
18:40
<jgraham>
Hixie: """I think the reluctance to fix it has mostly been due to partisan
18:40
<jgraham>
politics - either defending the origins and/or a reluctance to causeoffence by it's replacement with another solution."""
18:40
<Hixie>
o_O
18:40
<jgraham>
"it" being the handshake in this case
18:40
<Hixie>
so glad i got out of that wg
18:41
<mokush>
Hixie: no prob, I was out too. So it's actualy a short name like "English"?
18:47
<Hixie>
mokush: yeah
18:47
<mokush>
does track have even minimal support in any browser?
18:47
<Hixie>
not yet
18:48
<Hixie>
it's only just been added
18:48
<Hixie>
afk, bbl
18:48
<mokush>
js to the rescue
18:50
<mokush>
I read somewhere that Safari has some support for captions.
20:02
<othermaciej>
MikeSmith: public-html seems to be getting bugmail other than new bugs...
20:03
<othermaciej>
I see a few today that are keyword changes or resolutions (though it seems just plain comments are not getting through)
20:17
<jgraham>
othermaciej: In case you are not paying attention, Hybi seems to be discussing the handshake again
20:18
<othermaciej>
jgraham: is it worth my time to pay attention?
20:23
<jgraham>
othermaciej: I think it is would be a net win if you pay attention. I'm not sure if you personally will benefit from it