Options:
- # Session Start: Wed Jan 16 00:00:00 2008
- # Session Ident: #html-wg
- # [00:05] * Quits: timbl_ (timbl@128.30.5.98) (Quit: timbl_)
- # [00:17] * Joins: zcorpan (zcorpan@83.227.33.203)
- # [00:18] * Quits: aaronlev (chatzilla@66.30.196.151) (Ping timeout)
- # [00:22] <zcorpan> anne: s/xml-stylesheet/access-control/
- # [00:26] <zcorpan> anne: the answer to the first question doesn't actually answer the question
- # [00:35] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
- # [00:38] * Quits: tH (Rob@87.102.16.84) (Quit: ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508])
- # [01:01] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
- # [01:02] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [01:15] * Quits: aroben (aroben@76.124.50.18) (Quit: aroben)
- # [01:21] * Quits: billmason (billmason@69.30.57.129) (Quit: .)
- # [01:24] * Joins: olivier (ot@128.30.52.30)
- # [01:29] * Joins: timbl (timbl@96.237.56.114)
- # [01:40] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: Leaving)
- # [01:41] * Quits: mjs (mjs@17.255.110.3) (Quit: mjs)
- # [01:44] * Joins: Lachy (Lachlan@84.215.54.100)
- # [01:51] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
- # [02:07] * Quits: adele (adele@17.203.15.207) (Quit: adele)
- # [02:27] * Joins: adele (adele@17.203.15.207)
- # [02:27] * Joins: mjs (mjs@17.255.110.3)
- # [02:30] * Quits: kingryan (kingryan@66.92.219.50) (Ping timeout)
- # [03:05] * Quits: adele (adele@17.203.15.207) (Quit: adele)
- # [03:11] * Quits: Lachy (Lachlan@84.215.54.100) (Connection reset by peer)
- # [03:11] * Joins: Lachy (Lachlan@84.215.54.100)
- # [03:36] * Joins: adele (adele@17.203.15.207)
- # [03:37] * Quits: adele (adele@17.203.15.207) (Quit: adele)
- # [03:51] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
- # [04:12] * Joins: Dashimon (noone@80.202.220.46)
- # [04:12] * Quits: Dashiva (noone@80.202.220.46) (Connection reset by peer)
- # [04:12] * Dashimon is now known as Dashiva
- # [04:30] * Quits: sbuluf (xchl@200.49.132.117) (Ping timeout)
- # [04:35] * Joins: sbuluf (nwsqltc@200.49.132.91)
- # [04:36] * Quits: mjs (mjs@17.255.110.3) (Quit: mjs)
- # [04:52] * Joins: adele (adele@67.170.232.64)
- # [05:15] * Quits: jmb (jmb@152.78.68.189) (Ping timeout)
- # [05:16] * Joins: jmb (jmb@152.78.68.189)
- # [05:37] * Quits: adele (adele@67.170.232.64) (Client exited)
- # [05:38] * Joins: adele (adele@67.170.232.64)
- # [06:00] * Quits: inimino (weechat@75.71.88.233) (Ping timeout)
- # [06:35] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
- # [07:06] * Quits: shepazu (schepers@128.30.52.30) (Quit: Core Breach)
- # [07:13] * Joins: shepazu (schepers@128.30.52.30)
- # [07:19] * Joins: Zeros (Zeros-Elip@69.140.40.140)
- # [07:29] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [07:38] * Quits: sbuluf (nwsqltc@200.49.132.91) (Ping timeout)
- # [07:41] * Quits: heycam (cam@210.84.62.145) (Quit: bye)
- # [07:41] * Joins: heycam (cam@210.84.62.145)
- # [07:54] * Joins: mjs (mjs@64.81.48.145)
- # [08:10] * Joins: kingryan (kingryan@66.92.2.56)
- # [08:30] * Quits: Zeros (Zeros-Elip@69.140.40.140) (Quit: Leaving)
- # [08:33] * Quits: adele (adele@67.170.232.64) (Quit: adele)
- # [08:34] * Joins: adele (adele@67.170.232.64)
- # [08:34] * Quits: adele (adele@67.170.232.64) (Quit: adele)
- # [08:56] * Quits: kingryan (kingryan@66.92.2.56) (Quit: kingryan)
- # [09:22] * Quits: jmb (jmb@152.78.68.189) (Ping timeout)
- # [09:25] * Joins: jmb (jmb@152.78.68.189)
- # [09:27] * Joins: tH (Rob@87.102.16.84)
- # [09:52] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: This computer has gone to sleep)
- # [10:07] * Joins: Lachy (Lachlan@213.236.208.22)
- # [10:09] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
- # [10:09] * Joins: Lachy (Lachlan@213.236.208.22)
- # [10:19] * Joins: ROBOd (robod@89.122.216.38)
- # [10:41] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
- # [10:43] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [10:52] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
- # [11:29] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [11:42] * Joins: inimino (weechat@75.71.88.233)
- # [11:49] <anne> http://www.w3.org/QA/2008/01/html5-is-html-and-xml is nice
- # [11:49] * Joins: tH_ (Rob@87.102.83.222)
- # [11:50] * Quits: tH (Rob@87.102.16.84) (Ping timeout)
- # [11:50] * tH_ is now known as tH
- # [11:50] * Quits: laplink (link@193.157.66.108) (Quit: Leaving)
- # [11:50] <hsivonen> hmm. putting a <select> inside a <label> for another field causes undesirable default focus behavior in Firefox
- # [11:50] <hsivonen> I guess I should get rid of the <label>
- # [11:52] <MikeSmith> anne - if you responded to my question on #waf about implementations of the Access Control spec (other than the Mozilla one), I didn't see it
- # [11:57] <anne> I didn't reply because you were not there anymore :)
- # [11:58] <anne> I'm not aware of any other implementations
- # [12:00] * Joins: myakura (myakura@122.29.71.44)
- # [12:05] <MikeSmith> anne - OK, thanks
- # [12:35] * Quits: jgraham (james@81.86.209.97) (Quit: This computer has gone to sleep)
- # [12:44] <anne> 83 votes, 75 yes, 1 no, 5 abstain, and 2 fo
- # [12:45] <anne> differences: 73 yes, 5 abstain, 4 no, and 1 fo
- # [12:48] * Quits: timbl (timbl@96.237.56.114) (Quit: timbl)
- # [12:48] <Lachy> MikeSmith, assuming this vote passes (and we don't get 30 more no votes today), will the spec still be published, as planned, on Jan 22?
- # [12:50] <MikeSmith> Lachy - yeah
- # [12:51] <MikeSmith> absent of any acts of god that prevent it
- # [12:53] <Lachy> well, there is no god, so prevention is not possible. Great! :-)
- # [13:03] * Joins: zcorpan (zcorpan@88.131.66.80)
- # [14:02] <zcorpan> wow, now we have another diagram that can be included in the spec (and it's not ascii art!) http://www.w3.org/QA/2008/01/html5-is-html-and-xml
- # [14:03] <zcorpan> that should be as early as possible in the spec :)
- # [14:03] <zcorpan> or probably in the HTML vs XHTML section
- # [14:03] <Lachy> the arrows seem to be going the wrong way
- # [14:04] <zcorpan> not if you're serializing
- # [14:04] <Lachy> yeah, but it says parser in the circles as well
- # [14:05] <Lachy> they should be bi directional arrows, or just lines
- # [14:05] * zcorpan notes that karl uses "html" rather than "HTML" when referring to the serialization
- # [14:06] <anne> he also doesn't use XHTML
- # [14:06] <anne> (apart from the MIME type)
- # [14:07] <Lachy> I suggested earlier that we could change the name of the serialisation to HTMS for (Hypertext Markup Serialisation/Syntax)
- # [14:07] <anne> neh
- # [14:07] <Lachy> though it doesn't sound as good as HTML
- # [14:07] <zcorpan> looks like a severe typo
- # [14:08] <beowulf> HTMS sounds vaguely disease like
- # [14:08] <hsivonen> http://validator.nu/ now has file upload and textarea (JS required)
- # [14:08] <zcorpan> hsivonen: thanks!
- # [14:09] <anne> hsivonen, <html lang=en> ?
- # [14:09] <MikeSmith> hsivonen - beautiful
- # [14:09] <hsivonen> anne: ?
- # [14:10] <anne> add a lang attribute
- # [14:10] <hsivonen> anne: OK.
- # [14:10] <zcorpan> to the page or the template?
- # [14:10] <zcorpan> and why?
- # [14:11] <anne> because lang= is still part of HTML
- # [14:11] <anne> though arguably not much research has gone into it
- # [14:12] <zcorpan> a lot of other attributes are as well
- # [14:12] <zcorpan> so?
- # [14:12] <anne> it's good practice to use it?
- # [14:12] <zcorpan> yes, but not everyone who copy the template will use it for english pages
- # [14:12] <zcorpan> and not everyone understands or bothers to change it
- # [14:13] <zcorpan> hence, using lang=en for templates intended for a global audience results in pages labeled as 'en' but are not
- # [14:13] <hsivonen> anne: I think putting it in the template is pointless
- # [14:13] * zcorpan thinks putting it in the template is harmful
- # [14:13] * anne was talking about the homepage
- # [14:13] <zcorpan> aha
- # [14:13] * anne is confused
- # [14:14] <zcorpan> the template is in the textarea
- # [14:14] <anne> oh, that'd be silly
- # [14:14] <hsivonen> it might be cool to populate the textarea from show source if available
- # [14:15] <hsivonen> fatal errors suck, though, since they cut show source
- # [14:15] <zcorpan> hsivonen: when validating with textarea, the result page shows the url field instead of the textarea
- # [14:16] <zcorpan> also when going back in history, but i'm not sure that's fixable
- # [14:16] <hsivonen> zcorpan: yeah, that's because it is all on the client side
- # [14:17] <hsivonen> anne: lang='en' added
- # [14:17] <zcorpan> hsivonen: should be fixable somehow, though :)
- # [14:17] <hsivonen> zcorpan: yeah.
- # [14:18] <hsivonen> is there a clean way to persist strings in JS across a page load
- # [14:18] <hsivonen> that is, holding onto them in a window without putting them in site-wide cookies or anything
- # [14:19] <hsivonen> or is round-tripping the data via server still the way to go?
- # [14:19] <Lachy> isn't that what HTML5 is adding client side persistent storage for?
- # [14:19] <hsivonen> something like window.kungFuDeathGrip = textarea.value
- # [14:19] <anne> zcorpan, the answer to the first question simply explains why we have two checks in place
- # [14:20] <hsivonen> Lachy: isn't that site-wide instead of being in window scope?
- # [14:20] <Lachy> yeah, true
- # [14:21] <zcorpan> hsivonen: window.kungFuDeathGrip = textarea.value doesn't work
- # [14:21] <hsivonen> :-(
- # [14:22] <MikeSmith> hsivonen - btw, the html5check.py script is great to have too
- # [14:22] <anne> this is why HTML5 adds sessionStorage
- # [14:22] <MikeSmith> I wonder if somebody could get that html5check.py script packaged for Debian and what not
- # [14:22] <anne> but you could do it with a cookie hsivonen
- # [14:22] <hsivonen> MikeSmith: I'm glad its useful
- # [14:22] <anne> there are some simple scripts for that
- # [14:23] <hsivonen> anne: wouldn't that risk data leakage when I add cross-site XHR and stuff?
- # [14:23] * zcorpan would probably go for roundtripping to the server
- # [14:23] <hsivonen> anne: or cross-window leakage
- # [14:24] <anne> access control doesn't expose response cookies
- # [14:24] <anne> please see http://dev.w3.org/2006/waf/access-control/#security
- # [14:24] <anne> "Not to expose any trusted data of the response, such as cookies, and HTTP header data, inappropriately."
- # [14:25] <hsivonen> MikeSmith: I think hendry on #whatwg is the person to talk to about Debian packaging
- # [14:26] <anne> hsivonen, though the result page could be dependent on how you submit something now?
- # [14:26] <anne> s/now/no?
- # [14:26] <zcorpan> hsivonen: for textarea, perhaps you could do some XHR fu instead of submitting the form
- # [14:26] <anne> so if you submit a <textarea> the result page is based on that
- # [14:27] <anne> for <textarea> GET would also be nicer imo
- # [14:28] <zcorpan> but GET doesn't work with very large documents... iirc
- # [14:28] <hsivonen> anne, zcorpan: those approaches are both possibilities. I was thinking of populating the textarea from Show Source, which would be useful if you first validate a page from the Web and then want to see how a tweak would change the results
- # [14:28] <hsivonen> anne: I think I'm not going to do textarea with GET.
- # [14:28] <zcorpan> hsivonen: yep, that would also be useful
- # [14:29] <hsivonen> (I'm trying to avoid server-side changes that would break my carefully streaming IO.)
- # [14:38] <Lachy> I don't get that input type=hash proposal. Alexander keeps saying his proposal prevents the server from knowing the password. But that can't work because the server *needs* to know the password for the whole thing to work.
- # [14:40] <anne> sounds like <keygen>
- # [14:40] <Lachy> possibly.
- # [14:41] <anne> which we need
- # [14:41] <anne> though i'm not sure how it works, etc.
- # [14:41] <Lachy> but that still lacks any clear documentation on how it works
- # [14:41] <Lachy> all I know about it is the client generates a public/private key (I think) and sends it to the server.
- # [14:42] <Lachy> But then how exactly the server makes use of that key in the response to the client is a mystery to me.
- # [14:43] <Lachy> and I have no idea what the client does with the key after it submitted it, but I assume it would have to store the private key for later use
- # [14:43] <anne> it does
- # [14:47] <Philip> Lachy: It prevents the server from knowing the clear-text password that the user typed in
- # [14:48] <Philip> so the server will see a password like "a4a9b882fd811c31e1836c9f8f00f7d2" rather than a password like "alice07"
- # [14:48] <Philip> which sort of keeps the user's password a bit more hidden, particularly since users will use the same clear-text password on other sites
- # [14:51] <anne> Philip, are you saying you know the <keygen> processing model? :)
- # [14:52] <Lachy> I assume Philip is talking about the type=hash proposal
- # [14:52] <Philip> Oh, sorry, I was referring to the "I don't get that input type=hash proposal." thing
- # [14:52] <Philip> I know nothing about <keygen> :-)
- # [14:53] <Lachy> Philip, but the server would at least need to know the password when the user registers, even if it only stores the hashed version in its DB.
- # [14:54] <Philip> Lachy: The client could sent hash(pw) when registering
- # [14:55] <Philip> so the server will never be able to know pw
- # [14:55] <Lachy> so then you're effectively just changing the password from "alice07" to "a4a9b882fd811c31e1836c9f8f00f7d2"
- # [14:55] <Philip> Yes
- # [14:55] <Philip> which means the evil server admin can't find out that Alice has the password "alice06" on this other site she joined a year earlier
- # [14:55] <Lachy> in order for the server to verify that hash(password + salt + replaysalt) sent by the client is correct, it would need to perform the same operation on the server side
- # [14:55] <Philip> which isn't a really compelling advantage
- # [14:56] <Philip> Lachy: The initial suggestion was hash(hash(password + salt) + replaysalt)
- # [14:57] <Lachy> whatever
- # [14:57] <Philip> and the server gets sent hash(password + salt) when registering
- # [14:57] <Philip> (so it still doesn't need to know password)
- # [14:58] <Lachy> so any attacker can just find out what hash(password+salt) is during registration, and then obtain the replay salt from the login page and their in
- # [14:58] <Lachy> s/their/they're/
- # [14:59] <Philip> Yes
- # [14:59] <Lachy> so, basically, the proposal doesn't really solve anything. It provides the illusion of security
- # [14:59] <Philip> They're in to any site which has the same salt, and for which the user uses the same password
- # [15:00] <Philip> and if the attacker controls the registration process of one site, they can set the salt to match any other site's salt, so they can find hash(password + that other site's salt)
- # [15:00] <Lachy> yep
- # [15:01] <Lachy> better security would be obtained by the user using a utility to generate something like "a4a9b882fd811c31e1836c9f8f00f7d2" as their password and use that.
- # [15:02] <Philip> It's useful security if you can register via a trusted network, and then have to log in later on an untrusted network
- # [15:03] <Philip> except not really since somebody on the untrusted network could just hijack your session after you've logged in
- # [15:03] <Lachy> I don't think it's worth it. SSL and TLS are the solution.
- # [15:04] <Philip> I guess replaysalt would interact badly with caches
- # [15:05] <Lachy> yes, especialy if the login form was on every page
- # [15:06] * Joins: timbl (timbl@128.30.5.98)
- # [15:08] <Philip> Is it possible to use SSL/etc without signed certificates, so you get no proof of identity but you do get protection from eavesdroppers and you don't get ugly browser security warnings?
- # [15:11] * Parts: timbl (timbl@128.30.5.98)
- # [15:15] <Lachy> you can use self-signed certificates, but browsers issue warnings about it
- # [15:16] <Lachy> I want a self signed certificiate for things like logging into the blog admin on my site
- # [15:16] <Philip> The warnings make it unusable
- # [15:16] <Lachy> indeed, for most uses
- # [15:31] * Joins: aaronlev (chatzilla@66.30.196.151)
- # [15:47] <zcorpan> Philip: thanks, you gave me a good laugh with your "Blah blah" sentences in the suggested spec text... :D
- # [15:47] * zcorpan waits for Hixie to copy-paste that into the spec
- # [15:49] <zcorpan> ( http://www.w3.org/mid/478D5CE5.7060502@cam.ac.uk )
- # [16:09] <Philip> Oh, that was just to save some space by not copying-and-pasting uninteresting chunks of spec text
- # [16:23] * Quits: drry (drry@222.225.140.32) (Connection reset by peer)
- # [16:27] * Joins: aroben (aroben@76.124.50.18)
- # [16:28] * Joins: drry (drry@222.225.140.32)
- # [16:32] <hsivonen> I wonder if there was a good reason to put textContent as opposed to innerText into the DOM...
- # [16:45] * Joins: DanC (connolly@128.30.52.30)
- # [16:48] * Joins: billmason (billmason@69.30.57.129)
- # [16:56] <anne> I've been told innerText is different
- # [16:56] <hsivonen> anne: how?
- # [16:56] <gavin> one includes text from child nodes, I think?
- # [16:57] <hsivonen> that would be textContent
- # [16:58] <hsivonen> from MSDN: @The innerText property is valid for block elements only.@
- # [16:58] <hsivonen> sigh
- # [16:58] <hsivonen> s/@/"/
- # [16:59] <gavin> I think I'm misremembering the childnode difference
- # [16:59] <anne> yes
- # [16:59] <anne> MSDN is wrong
- # [17:03] <hsivonen> well, I can't even test in IE, so I deployed the script with this: // If you want this to work in IE, patches welcome
- # [17:04] * Quits: myakura (myakura@122.29.71.44) (Quit: Leaving...)
- # [17:08] <zcorpan> innerText works on any element
- # [17:08] * zcorpan doesn't know what the difference is, if there is any
- # [17:09] <zcorpan> well, at least getting works on any element
- # [17:09] <zcorpan> setting raises an exception on some elements (like <html>, <input>)
- # [17:09] <hsivonen> I only need the getter
- # [17:11] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
- # [17:12] <hsivonen> zcorpan: ok. deployed innerText without testing
- # [17:12] * Parts: beowulf (beowulf@208.113.221.22)
- # [17:14] <zcorpan> hsivonen: seems to work in ie6
- # [17:14] <hsivonen> zcorpan: good. thanks
- # [17:16] <zcorpan> "XMLNSÂ Filter" hmm, apparently my ie6 thinks that validator.nu is windows-1252
- # [17:17] <zcorpan> (encoding is "auto-select" in the menu)
- # [17:17] <zcorpan> which is really weird
- # [17:18] <hsivonen> zcorpan: web-sniffer.net says the header is text/html; charset=utf-8
- # [17:18] <hsivonen> which should be fine...
- # [17:18] <zcorpan> yeah. that's why it's weird
- # [17:20] <zcorpan> a forced reload makes it utf-8
- # [17:20] * zcorpan leaves it at that
- # [17:22] * zcorpan tries to validate the html5 spec with show source
- # [17:25] <zcorpan> ...
- # [17:25] <hsivonen> at least other threads keep serving requests...
- # [17:25] * hsivonen is trying to validate the spec concurrently as well
- # [17:27] <hsivonen> hmm. looks CPU-bound
- # [17:27] * anne tries the W3C version for added joy
- # [17:27] <hsivonen> real memory seems to be sufficient
- # [17:28] <anne> "Internal Error: Oops. That was not supposed to happen. A bug manifested itself in the application internals. Unable to continue. Sorry. The admin was notified."
- # [17:28] <hsivonen> I got the result back but source wasn't shown
- # [17:28] * zcorpan is still waiting
- # [17:28] * hsivonen checks email
- # [17:30] <hsivonen> hah. the Schematron impl ran out of memory
- # [17:31] <hsivonen> see! I was right! it does make sense to avoid tree building in a validator.
- # [17:31] <hsivonen> now I only need to replace the Schematron schema with something that doesn't build a tree
- # [17:32] <hsivonen> fwiw: one thread: java.lang.ArrayIndexOutOfBoundsException: 84968 at org.apache.xml.utils.StringVector.addElement(StringVector.java:108) at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.setSourceLocation(SAX2DTM.java:974)
- # [17:33] <hsivonen> another: java.lang.OutOfMemoryError: Java heap space at java.lang.Object.clone(Native Method) at org.apache.xpath.axes.PredicatedNodeTest.clone(PredicatedNodeTest.java:90)
- # [17:33] <anne> can't you replace schematron with custom java code?
- # [17:33] <hsivonen> anne: yes, I can
- # [17:33] <anne> that does simple traversal
- # [17:34] <hsivonen> now I have a better reason to. previously that task seemed more theoretical
- # [17:34] <Philip> hsivonen: Alternatively, it makes sense to do tree building because it means the validator will run out memory and abort, rather than running almost forever on a huge document and using up all the CPU time that other people want to share
- # [17:35] <hsivonen> Philip: the size of the input doc is limited in terms of # of bytes
- # [17:35] <Philip> Oh
- # [17:35] * Joins: Lachy (Lachlan@84.215.54.100)
- # [17:35] * Quits: Lachy (Lachlan@84.215.54.100) (Client exited)
- # [17:35] * Joins: Lachy (Lachlan@84.215.54.100)
- # [17:37] <hsivonen> Philip: pretty much everything expect the schematron part is designed to have memory requirements that grow at most linearly relative to input byte size
- # [17:37] <hsivonen> (although I don't know the exact perf characteristings of the RELAX NG engine)
- # [17:42] <hsivonen> and like I blogged, the Xerces regexp engine has bad perf characteristics compared to what is necessary to implement the XSD regexp spec
- # [17:49] * Quits: gavin_ (gavin@99.227.30.12) (Ping timeout)
- # [17:51] * Philip sees that the IPv4 TOS byte's definition has been really quite unstable over its history, and concludes that nobody will mind if he totally ignores the RFCs and uses it for something else
- # [17:51] * Joins: gavin_ (gavin@99.227.30.12)
- # [17:54] * Joins: matt (matt@128.30.52.30)
- # [18:01] <zcorpan> aha! innerText replaces linebreaks with <br>s
- # [18:01] <zcorpan> on setting
- # [18:03] <zcorpan> and <br>s turn into \r\n on getting
- # [18:05] <hsivonen> zcorpan: thanks. not a problem in my case
- # [18:06] <hsivonen> does alt='' participate in innerText?
- # [18:07] * Quits: matt (matt@128.30.52.30) (Ping timeout)
- # [18:15] * Joins: matt (matt@128.30.52.30)
- # [18:16] * Joins: gsnedders (gsnedders@217.42.133.143)
- # [18:17] <zcorpan> hsivonen: no
- # [18:18] <zcorpan> also, on getting, linebreaks (in text nodes) are turned into spaces
- # [18:18] <zcorpan> except if the element was <pre> (perhaps some others, too)
- # [18:19] <Philip> Does CSS white-space:pre affect linebreaks in innerText?
- # [18:20] <hsivonen> Safari and Opera supposedly support innerText. I wonder how faithfully to IE.
- # [18:23] <zcorpan> Philip: thankfully, no
- # [18:23] <zcorpan> opera's implementation is different from ie
- # [18:24] * zcorpan finds further funny features when the element contains <style>s or <script>s
- # [18:26] <zcorpan> or <comment> :)
- # [18:27] <zcorpan> oh wait, <comment>s don't have child nodes
- # [18:34] * Joins: Sander (svl@86.87.68.167)
- # [19:02] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
- # [19:03] * matt is now known as matt-nap
- # [19:03] * Quits: matt-nap (matt@128.30.52.30) (Quit: matt-nap)
- # [19:18] * Joins: adele (adele@17.203.15.207)
- # [19:26] <zcorpan> haha... elements' 'display' affects innerText
- # [19:26] <zcorpan> X<span style=display:block></span>Y
- # [19:26] <zcorpan> X<p style=display:inline></p>Y
- # [19:31] <Philip> Not really following the ideas of separation of presentation and content
- # [19:36] <zcorpan> or float or position
- # [19:44] * MikeSmith is now known as Mike^mail
- # [19:53] <zcorpan> it might make sense to make sure that the html4-differences document is properly aligned with the spec before publishing
- # [19:53] <zcorpan> ...the html4-differences document
- # [19:54] <Philip> s/might/would/
- # [19:54] <Philip> Can't be that big a diff to check through, surely
- # [19:56] * Philip wonders if hsivonen has an automatically-extracted list of all current elements and attributes, so it can be compared to the list from when html4-differences was last updated
- # [20:04] * Parts: zcorpan (zcorpan@88.131.66.80)
- # [20:06] * Joins: mjs (mjs@17.255.110.3)
- # [20:47] <anne> i'm fine with making some updates
- # [20:58] * Joins: dbaron (dbaron@63.245.220.229)
- # [21:05] * Mike^mail is now known as MikeSmith
- # [21:09] * jgraham_ is somewhat unimpressed by the argument from authority being used on security matters on public-appformats
- # [21:10] <jgraham_> (the conclusion may be valid, I don't know, but the reasoning isn't)
- # [21:11] <anne> who is doing that?
- # [21:13] <mjs> jgraham_: archive link?
- # [21:13] <anne> i agree that the situation is pretty bad
- # [21:13] <anne> i'm just wondering if you think it's me :)
- # [21:27] <shepazu> jgraham_, I'm not using the argument from authority... I just think it's appropriate that experts do review the spec and that their advice be considered
- # [21:27] <shepazu> do you disagree with that?
- # [21:28] <anne> shepazu, did you even comment about that on public-appformats?!
- # [21:29] <shepazu> no, but I've been commenting on #waf
- # [21:30] <anne> seems hard for jgraham_ to comment on that
- # [21:30] <shepazu> I'm not saying that jgraham_ said it was me that raised the argument
- # [21:30] <shepazu> you misunderstood
- # [21:32] <jgraham_> Sorry, been away
- # [21:33] <jgraham_> The sentence I disliked was "I'm not sure if JSONRequest is perfect [...] but it was designed by Doug Crockford, who gives talks at Ajax conferences on web security, and IMO he has a good handle on security issues"
- # [21:33] * Quits: gsnedders (gsnedders@217.42.133.143) (Quit: gsnedders)
- # [21:35] <jgraham_> Which didn't seem like an acceptable reason for preferring the security model of JSONRequest (although it might indeed be a good reason to get Doug Crockford to comment on his design rationale and on the access control spec)
- # [21:35] <shepazu> jgraham_, fair enough
- # [21:36] <anne> Doug Crockford commented and said that JSONRequest was the way to go
- # [21:36] <anne> great guy
- # [21:36] <mjs> JSNORequest does not in fact have a viable security model
- # [21:37] <mjs> I'm not sure Doug Crockford has a good understanding of security issues
- # [21:49] * Joins: jgraham (james@81.86.209.97)
- # [21:51] * Quits: jgraham (james@81.86.209.97) (Quit: This computer has gone to sleep)
- # [21:53] * Joins: jgraham (james@81.86.209.97)
- # [21:54] * Quits: shepazu (schepers@128.30.52.30) (Quit: Core Breach)
- # [21:55] * Joins: shepazu (schepers@128.30.52.30)
- # [22:24] * Joins: Zeros (Zeros-Elip@67.154.87.254)
- # [22:30] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
- # [22:31] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
- # [22:37] * Joins: Hixie (ianh@129.241.93.37)
- # [22:57] * Quits: mjs (mjs@17.255.110.3) (Quit: mjs)
- # [22:59] * Joins: adele_ (adele@17.255.96.178)
- # [22:59] * Quits: adele_ (adele@17.255.96.178) (Client exited)
- # [22:59] * Joins: adele_ (adele@17.255.96.178)
- # [23:01] * Quits: adele (adele@17.203.15.207) (Ping timeout)
- # [23:02] * Joins: mjs (mjs@17.255.110.3)
- # [23:19] * Joins: zcorpan (zcorpan@83.227.33.203)
- # [23:30] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: Leaving)
- # [23:32] * Joins: sbuluf (talez@200.49.132.72)
- # [23:36] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
- # [23:37] * Quits: aaronlev (chatzilla@66.30.196.151) (Ping timeout)
- # [23:44] * Joins: Lachy (Lachlan@84.215.54.100)
- # [23:45] <Hixie> shepazu: just saw the acid3 discussion in the svg wg -- just wanted to say that i'm certainly open to good tests, but they have to fit the rules of the competition, like all the other tests for the competition
- # [23:45] <Hixie> none of the tests mentioned so far come close
- # [23:46] <shepazu> hmmm, okay... naturally, we'd want it to match the criteria... maybe you could explain what's missing?
- # [23:46] <shepazu> I know the Renesis one was off-base
- # [23:47] <shepazu> maybe we need to study the Acid3 tests better... but it would be helpful if you could provide a frinstance
- # [23:48] <Hixie> http://www.hixie.ch/tests/evil/acid/003/competition/
- # [23:49] <Hixie> if you can't run the test using that, then it doesn't fit the rules
- # [23:51] * Joins: adele (adele@17.203.15.207)
- # [23:52] * Quits: adele_ (adele@17.255.96.178) (Ping timeout)
- # [23:53] <shepazu> ok, cool, thanks
- # [23:54] <shepazu> btw, you might put the closing date instead of "one week"
- # [23:54] <shepazu> since the form isn't dated
- # [23:54] <Lachy> shepazu, the blog entry about it was dated
- # [23:55] <Hixie> yeah, good point
- # [23:55] <Hixie> copy and paste snafu :-)
- # [23:56] <Philip> shepazu: That gives a mild sense of urgency and encourages people to submit soon, without actually fixing the deadline and thus allowing it to be extended indefinitely if nobody submits any tests
- # [23:56] <shepazu> clever :)
- # [23:57] <Hixie> i've put in the deadline
- # [23:57] <Hixie> (sunday)
- # [23:57] <shepazu> thanks
- # [23:58] <shepazu> Sunday!!!! Hixie, you can't do that! that's the Lord's Day, a day of rest!
- # [23:58] <Hixie> the Lord?
- # [23:58] <shepazu> President Bush, of course
- # [23:59] <Hixie> i don't recognise bush as my lord.
- # [23:59] <shepazu> you're unamerican!
- # [23:59] <Lachy> I doubt he'd have the intelligence to be able to write a test, so who cares if he's resting?
- # [23:59] <Hixie> (if i don't have enough submissions by sunday, i'll probably just use things that do pass today but used to famously fail)
- # Session Close: Thu Jan 17 00:00:00 2008
The end :)