Options:
- # Session Start: Wed May 14 00:00:00 2008
- # Session Ident: #whatwg
- # [00:00] <Hixie> o_O
- # [00:01] * Joins: jgraham (n=jgraham@81-86-212-222.dsl.pipex.com)
- # [00:02] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
- # [00:02] <Lachy> soypunk, why do you need to be able to see replies to me?
- # [00:02] <soypunk> well replies to your inquiry...
- # [00:03] <Lachy> FWIW, you're the only one to respond via twitter so far
- # [00:03] <Hixie> i think for explaining <meter> better we should have some pictures of gagues
- # [00:03] <Hixie> gauges
- # [00:03] <Hixie> anyone wanna take screenshots of gauge controls? :-)
- # [00:03] <soypunk> Lachy: are you collecting this info for the authoring guide, a follow-up ALA piece, or other?
- # [00:03] <Lachy> other
- # [00:04] * soypunk is now known as smedero
- # [00:04] <Lachy> for 2 things actually
- # [00:04] <smedero> should really keep my html-wg/whatwg nicks the same.
- # [00:04] <Lachy> 1. An interview I'm doing on thursday evening for a podcast, and a presentation that jgraham and I are doing at @media
- # [00:08] * Joins: KevinMarks (n=KevinMar@207.47.11.2.static.nextweb.net)
- # [00:16] * Quits: heycam (n=cam@124-168-18-250.dyn.iinet.net.au) ("bye")
- # [00:17] * Quits: phsiao (n=shawn@nat/ibm/x-dab3e97833380bbb)
- # [00:27] <roc> I guess I'd better alert dcamp to those offline spec changes
- # [00:28] <Hixie> ooo, i didn't realise mozilla had an implementation of the offline stuff that was in sync with the spec
- # [00:28] <Hixie> my bad
- # [00:28] <roc> you didn't?
- # [00:28] <roc> Dave rewrote it all to be in line with the spec
- # [00:28] <roc> well, hopefully
- # [00:28] <Hixie> i thought the mozilla stuff was an old implementation that was removed for ff3
- # [00:28] <roc> the old implementation was removed ... and a new one inserted :-)
- # [00:29] <Hixie> aah :-)
- # [00:29] * Hixie updates the markers in the spec
- # [00:30] <roc> http://starkravingfinkle.org/blog/2008/05/firefox-3-offline-app-demo-part-2/
- # [00:30] <roc> > The biggest changes involve dropping support for our own <link rel="offline"> mechanism and supporting WHATWG manifests and application cache.
- # [00:30] <Hixie> nice
- # [00:31] <othermaciej_> is there a web interface that I can use to look at checkins of HTML5?
- # [00:31] <roc> I think you did know this at one point, since you wrote some tests and they failed on Firefox :-). but I think Dave fixed them
- # [00:31] * othermaciej_ is now known as othermaciej
- # [00:31] <Hixie> othermaciej: yes, see the link at the top of the spec
- # [00:31] <Hixie> roc: ooooo, that rings a bell, yes
- # [00:32] <Hixie> man i need to keep better track of who does what
- # [00:32] <othermaciej> Hixie: thanks!
- # [00:33] * gsnedders improves Hixie's bell
- # [00:33] * Quits: KevinMarks (n=KevinMar@207.47.11.2.static.nextweb.net) (Connection reset by peer)
- # [00:34] * Joins: KevinMarks (n=KevinMar@207.47.11.2.static.nextweb.net)
- # [00:40] * Joins: vlad_ (n=asdf@69-12-240-128.dsl.static.sonic.net)
- # [00:40] <vlad_> annevk: ping
- # [00:40] <Hixie> ('course it's 00:37 in his time zone, so he might not be around)
- # [00:41] <vlad_> damn you
- # [00:48] <Philip`> vlad_: http://html5.googlecode.com/svn/trunk/web-apps-tracker/web-apps-tracker - patches welcome ;-)
- # [00:48] * Quits: tndH (i=Rob@adsl-77-86-4-188.karoo.KCOM.COM) ("ChatZilla 0.9.82.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
- # [00:49] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
- # [00:49] * Joins: jgraham_ (n=james@81-86-212-222.dsl.pipex.com)
- # [00:51] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
- # [00:53] <hendry> for vim users http://svn.natalian.org/projects/html5/html.vim
- # [00:54] * Joins: sverrej (n=sverrej@89.10.27.86)
- # [00:58] * Quits: csarven (n=csarven@on-irc.csarven.ca) (Read error: 110 (Connection timed out))
- # [00:59] * Quits: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
- # [01:05] * Quits: qwert666 (n=qwert666@acax115.neoplus.adsl.tpnet.pl) ("Leaving")
- # [01:10] * Joins: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
- # [01:31] <Hixie> <script charset>
- # [01:31] <andersca> roc: looks like there is a bug in that offline app demo
- # [01:31] <Hixie> what do we think
- # [01:31] <Hixie> do we need it?
- # [01:31] <roc> andersca: yeah?
- # [01:31] <Hixie> or what
- # [01:31] <andersca> roc: I think todo-server.php should be added to the online whitelist
- # [01:32] <Hixie> i guess i should look at who is using it
- # [01:32] <andersca> roc: otherwise it will fail to load once the page has been cached
- # [01:32] * Quits: j4_james (n=James@85-211-243-101.dsl.pipex.com) (Read error: 104 (Connection reset by peer))
- # [01:32] <roc> andersca: better let Mark know
- # [01:32] * Joins: j4_james (n=James@85-211-243-101.dsl.pipex.com)
- # [01:32] <andersca> roc: will do!
- # [01:32] <roc> thanks
- # [01:33] * Quits: eseidel_ (n=eseidel@72.14.224.1)
- # [01:35] * Quits: KevinMarks (n=KevinMar@207.47.11.2.static.nextweb.net) ("The computer fell asleep")
- # [01:36] * Quits: jgraham_ (n=james@81-86-212-222.dsl.pipex.com) ("I get eaten by the worms")
- # [01:45] <Lachy> LOL http://twitter.com/webconverger/statuses/810611186
- # [02:00] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
- # [02:03] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (IRC client for Emacs)")
- # [02:06] * Joins: eseidel (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net)
- # [02:07] * Joins: eseidel_ (n=eseidel@72.14.224.1)
- # [02:23] * Joins: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca)
- # [02:24] * Quits: eseidel (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
- # [02:43] * Quits: smedero (n=soypunk@mdp-nat251.mdp.com)
- # [02:51] <andersca> Hixie?
- # [02:57] <Hixie> yo
- # [03:00] * Quits: roc (n=roc@guest-226.mountainview.mozilla.com)
- # [03:00] <andersca> If there is already an application cache identified by this manifest URI, and the most up to date version of that application cache contains a resource with the URI of the manifest, and that resource is categorised as a manifest, then: store the resource in the matching cache, categorised as an implicit entry, associate the Document with that cache, invoke the application cache update process, and abort these steps.
- # [03:00] <andersca> Hixie: was it resolved how to handle the load of the implicit resource being cancelled here?
- # [03:01] <Hixie> yes
- # [03:01] <Hixie> it's in the application cache update process algorithm
- # [03:01] <Hixie> step 9
- # [03:04] <andersca> Hixie: ah
- # [03:05] <andersca> Hixie: so the end result will be that the document will be associated with the cache
- # [03:05] <andersca> Hixie: but the implicit resource will not be in the cache
- # [03:06] <Hixie> yeah
- # [03:06] <andersca> Hixie: also, what if the load is canceled before the manifest has finished loading
- # [03:06] <andersca> cancelled
- # [03:06] <Hixie> step 8
- # [03:06] <Hixie> oops, there's a cross-reference error in that paragraph
- # [03:06] <Hixie> let me fix that
- # [03:08] <Hixie> ok where it says "run just to the caching failure steps" assume it says "run the cache failure steps" and links to the cache failure steps paragraph below
- # [03:08] <Hixie> i'm in the middle of an edit so i can't make the change right now
- # [03:11] <andersca> OK!
- # [03:11] <andersca> Hixie: thanks
- # [03:11] <Hixie> np
- # [03:12] <Hixie> search for "canceled" in that section, i added it explicitly in a few places (and in a few places, added it explicitly as NOT being something that would trigger failure mode)
- # [03:12] <Hixie> as to the end result if you cancel the document and it being associated with the cache anyway -- that seemed the most consistent thing to do
- # [03:13] <Hixie> it's what happens if the cache update fails, too
- # [03:26] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
- # [03:31] * Quits: weinig (n=weinig@17.203.15.172)
- # [03:37] <andersca> Hixie: yeah
- # [03:45] <jwalden> mcarter: SSE?
- # [03:48] <Hixie> <event-source>
- # [04:06] * Quits: andersca (n=andersca@nat/apple/x-16113e0aeadc191b)
- # [04:19] * eseidel_ is now known as eseidel
- # [04:19] <jwalden> ah
- # [04:19] <jwalden> oh, server-sent events
- # [04:20] * jwalden is dumb
- # [04:20] * jwalden proposes <interlocution/>
- # [04:54] * Joins: soypunk (n=soypunk@pia145-154.pioneernet.net)
- # [04:59] * Joins: roc (n=roc@38.99.84.33)
- # [04:59] * Quits: soypunk (n=soypunk@pia145-154.pioneernet.net)
- # [05:09] <inimino> foreach ($_FILES["pictures"]["error"] as $key => $error) {
- # [05:09] <inimino> if ($error == UPLOAD_ERR_OK) {
- # [05:09] <inimino> $tmp_name = $_FILES["pictures"]["tmp_name"][$key];
- # [05:09] <inimino> $name = $_FILES["pictures"]["name"][$key];
- # [05:09] <inimino> move_uploaded_file($tmp_name, "data/$name");
- # [05:09] <inimino> }
- # [05:09] <inimino> erm, sorry
- # [05:09] <inimino> disregard that...
- # [05:37] * Joins: mcarter_ (n=mcarter@pool-72-87-174-204.plspca.dsl-w.verizon.net)
- # [05:41] <MikeSmith> Hixie: just now read back to your ping about the http://www.w3.org/2000/11/DOM-Level-2-errata.html doc
- # [05:42] <MikeSmith> cvs log shows plehegar was the one to make the latest edit to it
- # [05:43] <othermaciej> oh hmm I did not realize there were errata up
- # [05:43] <MikeSmith> I wonder whether maybe ownership of that doc should move the Web API WG
- # [05:44] <othermaciej> it should, if Web API WG doesn't own it already
- # [05:45] <othermaciej> though really I'd rather see a redone DOM Core 3 w/ conformance requirements stated properly and bogus non-browser-relevant stuff removed or moved to an appendix
- # [05:46] <MikeSmith> othermaciej: yeah, but short of that I reckon that we ought to keep that errata up to date
- # [05:47] <MikeSmith> unless/until we get something done that supersedes it
- # [05:47] <othermaciej> I guess DOM levels don't supersede each other
- # [05:47] <othermaciej> though when HTML5 comes out it should obsolete the older HTML DOM specs
- # [05:48] <MikeSmith> yeah
- # [05:52] <MikeSmith> For now, I'm assuming Hixie has a specific change that needs to be made. For record-keeping purposes, perhaps the process we should follow is to send a heads-up about it to the Web API mailing list, decide what the wording should be, record some resolution that we agreed it needed to be changed, then Doug or I can add it to that page.
- # [05:57] * Quits: mcarter (n=mcarter@pool-72-87-174-4.plspca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
- # [06:00] <othermaciej> MikeSmith: I vaguely recall that there was some minor inconsistency between DOM2 Core and DOM3 Core about exceptions
- # [06:00] <othermaciej> which should probably be errata'd
- # [06:00] <othermaciej> one of the dom 2 core test suite tests checks for it (though weirdly checks for the dom3 behavior)
- # [06:01] <MikeSmith> othermaciej: please write something up about it if/when you have time, send to public-webapi@w3.org
- # [06:01] <othermaciej> yeah, I'll have to find what the issue is
- # [06:04] <Hixie> MikeSmith: so you recommend mailing public-webapi@w3.org and what, getting wg consensus somewhow?
- # [06:05] <Hixie> i guess that works
- # [06:08] <MikeSmith> Hixie: yeah, if it's an obvious erratum, I think it's not so much a matter of getting consensus, it's more just having a record in the list archives that a new change was made and when
- # [06:09] <Hixie> k
- # [06:11] * Quits: othermaciej (n=mjs@17.255.98.143)
- # [06:15] * Joins: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net)
- # [06:18] <MikeSmith> Hixie: btw, do you have a rough idea of when you might add section, header, footer, etc. to the parsing algorithm?
- # [06:19] <Hixie> probably the next time i work on the parser
- # [06:19] <Hixie> since i've added mathml now there's not much point delaying further
- # [06:19] <MikeSmith> OK, I ask just because of the issue of html5lib reporting "Undefined behaviour for end tag" for those
- # [06:20] <Hixie> yeah
- # [07:01] * Joins: roc_ (n=roc@ip67-152-80-226.z80-152-67.customer.algx.net)
- # [07:08] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
- # [07:14] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
- # [07:23] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
- # [07:28] * Quits: roc (n=roc@38.99.84.33) (Read error: 110 (Connection timed out))
- # [07:43] * Joins: mcarter__ (n=mcarter@pool-72-87-174-217.plspca.dsl-w.verizon.net)
- # [07:48] * Joins: jgraham_ (n=james@81-86-212-222.dsl.pipex.com)
- # [07:50] * Joins: KevinMarks (n=KevinMar@40.sub-70-212-246.myvzw.com)
- # [07:52] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
- # [07:57] * Quits: mcarter_ (n=mcarter@pool-72-87-174-204.plspca.dsl-w.verizon.net) (Read error: 110 (Connection timed out))
- # [08:04] * Quits: KevinMarks (n=KevinMar@40.sub-70-212-246.myvzw.com) ("The computer fell asleep")
- # [08:05] * Joins: MikeSmith (n=MikeSmit@EM117-55-71-153.pool.e-mobile.ne.jp)
- # [08:07] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
- # [08:39] * Joins: eseidel_ (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net)
- # [08:51] * Quits: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
- # [08:56] * Quits: eseidel (n=eseidel@72.14.224.1) (Read error: 110 (Connection timed out))
- # [08:57] * Joins: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
- # [08:58] * Joins: qwert666 (n=qwert666@dax94.neoplus.adsl.tpnet.pl)
- # [09:07] * Quits: aruner (n=chatzill@adsl-75-36-185-153.dsl.pltn13.sbcglobal.net) (Read error: 110 (Connection timed out))
- # [09:18] <annevk> vlad_, pong...
- # [09:18] * annevk wonders if vlad_ is still awake, now it's 0:00 over there :D
- # [09:22] * Quits: MikeSmith (n=MikeSmit@EM117-55-71-153.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
- # [09:30] * Joins: tndH (i=Rob@adsl-77-86-4-188.karoo.KCOM.COM)
- # [09:33] * Quits: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
- # [09:38] <jwalden> annevk: Opera needs to implement Date.now(), defined as function() { return new Date().getTime(); } -- I think you'd be the remaining non-IE browser without it given WebKit added support earlier today :-)
- # [09:39] <weinig> annevk: you haven't by any chance written any tests for the Access Control spec have you?
- # [09:40] <Hixie> so people want <script type="some proprietary stuff">...</script> to be a conforming way of smuggling proprietary data into a web app
- # [09:41] <virtuelv> jwalden: mind filing a bug on that, and give me the bug number?
- # [09:41] <jwalden> virtuelv: point me to a location and I will
- # [09:41] <Hixie> i wonder what to do abotu that
- # [09:42] <virtuelv> jwalden: https://bugs.opera.com/wizard
- # [09:43] <annevk> weinig, not yet, sorry
- # [09:43] <weinig> annevk: ok, no worries
- # [09:43] <annevk> ah, vlad requests that web-apps-tracker has an option to "strip" HTML from the diff
- # [09:44] <annevk> if anyone has time to implement that in a way that does not expose us to script injection attacks from Hixie, feel free :)
- # [09:44] <Hixie> btw anne
- # [09:45] <Hixie> i noticed the gears icons aren't showing properly
- # [09:47] <annevk> hmm, all those change requests to access control
- # [09:48] <annevk> if it doesn't stop i might argue for some more simplification of the server side syntax
- # [09:53] <jwalden> virtuelv: filed as bug 329986
- # [09:53] <annevk> Hixie, browsers support type=text/javascript1.3 too
- # [09:54] <annevk> Hixie, some do anyway
- # [09:54] <Hixie> really?
- # [09:54] <Hixie> oh
- # [09:54] <Hixie> well then
- # [09:54] <annevk> i think that makes more sense
- # [09:54] <Hixie> i can just strip all that crap then
- # [09:56] <virtuelv> jwalden: thanks
- # [09:56] <jwalden> virtuelv: I think that goes both ways -- speed and arithmetic usage improvements will be welcome :-)
- # [10:00] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
- # [10:01] <virtuelv> jwalden: I presume (but can't actually promise, since it's not my call) that this will be trivial to add
- # [10:01] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
- # [10:02] <jwalden> implementation-wise I have very little doubt it is, the question's resource allocation and prioritization
- # [10:03] <annevk> weinig, Hixie, since we have Access-Control-Origin, maybe having a space separated list of URIs from which requests are allowed (only checking the origin bits, similar to postMessage) is enough for the Access-Control / <?access-control?> case
- # [10:03] <Hixie> hm?
- # [10:03] <Hixie> what's the problem?
- # [10:04] <annevk> Access-Control: <http://opera.com:800> <https://w3.org/ignored>
- # [10:04] <annevk> it being quite complicated currently
- # [10:04] <Hixie> what's wrong with what we have now
- # [10:04] <Hixie> i thought we needed deny rules
- # [10:04] <Hixie> did we decide to get rid of the use cases for that?
- # [10:05] <annevk> deny rules are gone anyhow
- # [10:05] <Hixie> (and ignoring stuff in something security related is dangerous -- fail, don't ignore)
- # [10:05] <Hixie> they are?
- # [10:05] <weinig> annevk: exclude is the new deny
- # [10:05] <Hixie> so what does it look like now?
- # [10:05] <Hixie> that's what i meant by deny
- # [10:05] <annevk> oh ok
- # [10:05] <weinig> annevk: what about the wildcarding?
- # [10:06] <annevk> now we have Access-Control: allow <*.opera.com:*> <*.w3.org> exclude <evil.opera.com>
- # [10:06] <annevk> i guess it isn't too bad either
- # [10:07] <Hixie> i don't understand why we suddenly want to get rid of exclude rules
- # [10:07] <annevk> the main thing is that the majority case is probably whitelisting a few domains or using * and not doing anything this complex
- # [10:07] <annevk> and the real complex cases can be done using Access-Control-Origin
- # [10:08] * Quits: eseidel_ (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net)
- # [10:08] <Hixie> well i'm all for making things simpler, but then i have to wonder why we didn't do them simple in the first place
- # [10:08] <Hixie> getting rid of "exclude" (and removing the "allow" keyword) is fine by me
- # [10:09] <Hixie> we still need the wildcards though
- # [10:09] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [10:09] <annevk> Hixie, wildcards for domains?
- # [10:09] <Hixie> protocols, domains, and ports
- # [10:09] <Hixie> same as now
- # [10:10] <Hixie> i'm just talking about just dropping the "exclude" part and the "allow" keyword
- # [10:10] * Joins: eseidel (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net)
- # [10:11] <annevk> ok
- # [10:12] <annevk> i guess still allowing 'example.org' isn't too much trouble then either
- # [10:12] <Hixie> it's not trouble at all, you've already specified it
- # [10:12] <annevk> :)
- # [10:13] <Hixie> every time you make a change to a specification that isn't a change that fixes an actual error or that adds a new important feature, you lose a bit of credibility as a spec editor
- # [10:13] <Hixie> churn is bad
- # [10:13] <Hixie> people get frustrated if the spec keeps changing in non-obvious ways for apparently no reason
- # [10:15] <Hixie> especially when they have already implemented it
- # [10:15] <annevk> true, i'm just trying to figure out if we can reduce complexity because people have been complaining about that and i sort of agree it's quite complex
- # [10:15] <Hixie> i'd concentrate on getting the header story straightened out before worrying about that :-)
- # [10:16] <annevk> and given that the implementors (apart from WebKit so far) have been proposing changes as well during implementation...
- # [10:16] <weinig> I am not sure I see the benefit to users of removing exclude, as it is already optional
- # [10:16] <annevk> for instance, now Mozilla wants header/method opt-in
- # [10:16] <annevk> weinig, yeah, I guess i'll just keep all that in
- # [10:17] <weinig> ok
- # [10:17] <Hixie> did sicking ever send the second e-mail he said he would send?
- # [10:18] <weinig> annevk: what do you mean by header/method opt-in?
- # [10:18] <annevk> Hixie, no, he hasn't
- # [10:18] <Hixie> odd
- # [10:19] <annevk> weinig, http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html
- # [10:19] <weinig> ah, I list I am not on :)
- # [10:20] <annevk> access-control / xhr2 is currently developed on two separate lists unfortunately :(
- # [10:20] <annevk> once people get their act together it will be on one, but i'm not sure how long that'll take
- # [10:22] * Joins: heycam (n=cam@124-168-18-250.dyn.iinet.net.au)
- # [10:23] <weinig> will read the relevant back log of that list tomorrow
- # [10:23] * Quits: eseidel (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net)
- # [10:25] * Philip` forgets why <dialog> can't just be spelt as <dl>
- # [10:26] * Quits: jgraham_ (n=james@81-86-212-222.dsl.pipex.com) ("I'll hit the bottom and escape")
- # [10:27] * takkaria boggles what happened to the alt thread overnight
- # [10:27] <othermaciej> annevk: hmm, I don't get how "Access-Control-Extra-Headers" addresses the stated problem
- # [10:28] <othermaciej> annevk: doesn't XHR2+AC already whitelist to a short list of headers?
- # [10:28] <othermaciej> or am I confused?
- # [10:28] <othermaciej> I guess I should get on public-appformats
- # [10:29] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [10:30] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [10:30] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [10:30] <Hixie> Philip`: different content models, different basic idea
- # [10:30] <Hixie> Philip`: a dialog is not a set of one-or-more-names/one-or-more-values tuples
- # [10:31] <Hixie> though maybe it should allow multiple names per "quote"
- # [10:31] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [10:33] <annevk> othermaciej, it whitelists a short list of headers for the request, but if you go outside that list and the server responds positively to a preflight request the headers will get through
- # [10:33] <annevk> (apart from the blacklisted headers of course)
- # [10:34] <othermaciej> annevk: ok I see
- # [10:34] <Philip`> Hixie: Since you removed the new bit about language=javascript1.x, where is that handled now?
- # [10:35] <Hixie> see mail to public-html
- # [10:35] <Hixie> it's handled by turning it into type=text/language/javascript1.x
- # [10:35] <Hixie> which browsers support already
- # [10:35] <annevk> well, some do
- # [10:35] <annevk> such as WebKit iirc
- # [10:36] <Philip`> I think my point was that it's not obvious to a UA implementor that they should support those in addition to text/javascript
- # [10:36] <Hixie> ah well maybe we should update the relevant rfc
- # [10:36] <Hixie> it needs updating anyway, right now it dumbly obsolete text/javascript
- # [10:36] * Joins: ROBOd (n=robod@89.122.216.38)
- # [10:36] <Philip`> The "Scripting languages" section already mentions "text/javascript", so it'd be helpful for implementors if that mentioned the typical aliases too
- # [10:36] <Hixie> and it doesn't define the e4x parameter, and it looks like the ES4 group is planning on making all kinds of mistakes with a version= parameter, too, which will also need defining
- # [10:37] <Hixie> yeah, that could work
- # [10:37] <Hixie> reply to the thread :-)
- # [10:37] <Philip`> Hixie: By "see mail to public-html", do you mean the mail which says "Done" when actually the final result to the spec was no change? :-)
- # [10:38] <Hixie> no, the reply to that one
- # [10:39] <Philip`> I don't see a reply
- # [10:39] <Philip`> ...but that's not your problem
- # [10:39] <Hixie> http://lists.w3.org/Archives/Public/public-html/2008May/0292.html
- # [10:39] <Philip`> since it's just the list/Gmail being slow
- # [10:43] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
- # [10:45] <takkaria> I'd forgotten quite how frustrating being a participant in the alt debate is
- # [10:45] <Hixie> i'd forgotten why i never reply in real time to threads
- # [10:45] <annevk> <interplay>
- # [10:45] <Hixie> i'm now relearning this with the <dialog> issue
- # [10:45] <takkaria> :)
- # [10:47] <Hixie> ok
- # [10:47] <Hixie> you may now vote on the next thing i work on
- # [10:47] <Hixie> should it be:
- # [10:47] <Hixie> <iframe> features
- # [10:47] <Hixie> or
- # [10:47] <Hixie> <video>
- # [10:47] <Hixie> you decide!
- # [10:47] <takkaria> video!
- # [10:48] <takkaria> I hope you're not expecting rationales
- # [10:49] <annevk> are we going to add <iframe> features for HTML5?
- # [10:49] * annevk is silently hoping we push the sandbox issue out of HTML5
- # [10:49] <annevk> hah, so much for silently
- # [10:50] <Hixie> i'm expecting us to add iframe sandboxing features
- # [10:50] <othermaciej> I have heard someone from Microsoft claim that <iframe> is not a strong enough sandbox as-is and therefore iframe+postMessage was not a good enough solution for "mashups"
- # [10:51] <othermaciej> but he refused to say what the specific issues are
- # [10:51] <othermaciej> (why does this sound so familiar?)
- # [10:51] <annevk> parent.location.href = '...' is an issue
- # [10:51] <Hixie> in particular see the end of http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011198.html for what i expect to look at adding
- # [10:51] <annevk> (from Douglas Crockford)
- # [10:52] <othermaciej> Hixie: <script sandbox="">?
- # [10:52] <Hixie> ?
- # [10:52] <othermaciej> I hope that's not the proposal you expect to look at adding
- # [10:53] <Hixie> "the end of" was a key part of what i wrote just now :-)
- # [10:53] <othermaciej> then I have a lot of reading to do to get to the bottom!
- # [10:54] <Hixie> sorry :-)
- # [10:54] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
- # [10:54] <Hixie> my bit starts from the line that just says "PROBLEMS"
- # [10:54] <annevk> you could just press "End"
- # [10:54] <Hixie> the rest is me mostly telling people their ideas suck
- # [10:54] <Hixie> (about 70% down)
- # [10:54] <Hixie> aybe 60%
- # [10:56] <othermaciej> Hixie: I think you dismissed the md5= possibility too readily - you just keep reading characters until the checksum matches, that works even if the content contains a malicious </sandbox>
- # [10:56] <othermaciej> faking the hash is a risk
- # [10:56] <othermaciej> another possibility is to require a psuedo-attribute on the end tag
- # [10:56] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
- # [10:57] <othermaciej> <sandbox token="13498564123"><!-- that was a random number --> </sandbox token="13498564123">
- # [10:57] <Hixie> yeah i believe i have that feedback from you in the pile
- # [10:58] <othermaciej> I don't remember if I said this specific stuff before
- # [10:58] <othermaciej> though I vaguely remember this being discussed
- # [10:59] <Philip`> <sandbox13498564123><!-- now you don't even have to change the parser much --></sandbox13498564123>
- # [10:59] <othermaciej> client-side filtering of script could be done with less chance of time-of-check time-of-use errors, since browsers know exactly when they will run script
- # [10:59] <othermaciej> Philip`: or use a colon
- # [10:59] <Philip`> othermaciej: I assume this ought to work in XHTML too
- # [10:59] * Quits: sverrej (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
- # [10:59] <othermaciej> <sandbox:13498564123><!-- now you don't even have to change the parser much --></sandbox:13498564123>
- # [11:00] <othermaciej> Philip`: I am not sure premature close is the same kind of problem in XHTML since it renders the document not well formed
- # [11:00] <othermaciej> Philip`: but I guess scripts could have run by the time you find that out
- # [11:00] <annevk> all this sandboxing seems rather fragile
- # [11:00] <othermaciej> and I'm sure Hixie won't want to invent a sandbox: namespace
- # [11:01] <Hixie> the biggest problem with a checksum thing is that if you get it wrong, your document ends up all in the sandbox
- # [11:01] <Hixie> well maybe no the biggest problem
- # [11:01] <Hixie> a big problem
- # [11:01] <othermaciej> annevk: basically the main benefit is that it lets sites be lazy and not do whitelist content filtering; and it avoids the possibility of a whitelist that is too lenient
- # [11:01] <Philip`> othermaciej: You should be able to take any HTML document and reserialise it as XHTML without any fancy transformations, even if some of the HTML features are redundant in XML, otherwise hsivonen will be unhappy
- # [11:02] <Hixie> not being able to provide this feature in xhtml is not imho any kind of blocker
- # [11:02] <Hixie> :-)
- # [11:02] <othermaciej> Hixie: my idea and Phillip's variant both do not have the possibility of getting a checksum wrong (though it is possible the magic random token will be copied wrong)
- # [11:02] <Hixie> othermaciej: how so?
- # [11:03] <othermaciej> there is no checksum
- # [11:03] <othermaciej> the token is arbitrary - the defense is that hostile content cannot predict it
- # [11:03] <Philip`> I assume XHTML5 would still want the safe script sandbox behaviour, even though the parser issue is only relevant for HTML
- # [11:03] <Hixie> othermaciej: oh the random number idea doesn't work at all, you're totally dependent on the site making unpredictable choices of random numbers
- # [11:04] <Hixie> othermaciej: given that we couldn't even depend on openssl's security experts making unpredictable ssl certs, i don't think we can rely on joe author making unpredictable magic numbers
- # [11:04] <annevk> and if people are allowed to edit their comments you would have to regenerate the magic number and you might forget to do that, etc.
- # [11:05] <othermaciej> generating a random number is certainly something you can fail at, but so is whitelist content filtering (the current best practice for injecting unknown content)
- # [11:05] <zcorpan> i know a name for <dialog>... <dl>
- # [11:05] <zcorpan> short for DiaLog
- # [11:05] <zcorpan> (or DiaLogue)
- # [11:05] <othermaciej> zcorpan: cute
- # [11:06] <Hixie> othermaciej: whitelist filtering is far easier to understand than random number generation, which is basically a black art
- # [11:06] * Quits: didymos (i=jho@rapwap.razor.dk) (Remote closed the connection)
- # [11:07] <Philip`> Hixie: OpenSSL's security experts did it right, it was just the Debian developers who commented out all the entropy
- # [11:08] <Hixie> Philip`: for the recent case, yeah, but wasn't there a case long ago that was a real bug?
- # [11:08] <Philip`> Hixie: Oh, no idea
- # [11:08] <Hixie> Philip`: or alternatively, consider than win2k, winxp, and vista all had a system RNG that was proved predictable after something like 8 years
- # [11:08] <othermaciej> Hixie: well on Mac OS X you just call arc4random, but yeah you can screw it up
- # [11:09] * Joins: sverrej (n=sverrej@pat-tdc.opera.com)
- # [11:09] <othermaciej> though a random token, unlike a checksum, would be easily fixable w/ no browser changes needed in case the algorithm is found to be vulnerable
- # [11:10] <othermaciej> though I guess it could turn comment spam into a CPU hogging attack generating all that entropy
- # [11:10] <othermaciej> anyway, I am not sure safe markup injection via a client-side feature is feasible, but if it were there would clearly be some advantages
- # [11:10] <Philip`> You'd probably generate the entropy on (uncached) page views, not on comment posting
- # [11:11] <Philip`> s/generate/use/
- # [11:11] <othermaciej> Philip`: I don't think you would want to generate a different random number every time, though maybe every time you generate the page if you cache static copies
- # [11:11] <Philip`> Fortunately thermodynamics guarantees that entropy won't decrease, so you'll never permanently run out
- # [11:13] <othermaciej> thank goodness
- # [11:14] <zcorpan> Hixie: experience with <address> should suggest that the element name matters more than its definition in terms of what authors will use it for
- # [11:14] <othermaciej> Hixie: styles cascading through a browsing context boundary (wait, do you mean cascading or inheriting or both) sounds like an interesting implementation challenge
- # [11:15] <othermaciej> Hixie: I do like <iframe noscript> and <iframe restrict> though (well, depending on specific restrictions)
- # [11:16] <othermaciej> Hixie: though restrict seems better for embedded "gadgets" than for comment fields
- # [11:16] <Hixie> yeah the stuff at the end is mostly just random ideas
- # [11:17] <Hixie> i haven't thought through exactly what the needs are
- # [11:17] * Joins: webben (n=benh@nat/yahoo/x-6f4d32298fad5beb)
- # [11:19] <othermaciej> I think the real answer to the JSON case is cross-site XHR plus a native JSON API
- # [11:20] <othermaciej> trying to run scripts in the same browsing context but with special restrictions sounds like disasterville
- # [11:20] <othermaciej> I know you agree and all
- # [11:20] <othermaciej> I just had to say it
- # [11:23] <jgraham> Hixie: FWIW I think zcorpan is right, and I think enough people have complained about <dialog> to suggest it is a real issue
- # [11:23] <Hixie> what was the JSON case again?
- # [11:23] <Hixie> jgraham: the difference is that you could use <address> to include an address and nothing would go wrong. Using <dialog> for a dialog box makes no sense.
- # [11:24] <zcorpan> Hixie: makes about as much sense to me as using <div class=dialog>
- # [11:25] <zcorpan> Hixie: consider that dialog boxes would mostly be scripted and so would bypass validation
- # [11:25] <jgraham> Well nothing will happen but then nothing happens when you use <nav> for navigation either
- # [11:25] <Hixie> i don't understand what <div class="dialog"> would do either
- # [11:25] <othermaciej> Hixie: people embed semi-untrusted off-site script to transfer JSON data (the script is expected to just assign to a var)
- # [11:25] <jgraham> People are used to the idea that elements exist for no function other than "semantics"
- # [11:25] <zcorpan> Hixie: it wouldn't do anything except provide a hook for scripting and styling for the author to implement the dialog box
- # [11:29] <zcorpan> Hixie: (i'm just being a bitch here, i actually couldn't care less about the name)
- # [11:31] <Hixie> othermaciej: xhr2 is the solution to that
- # [11:32] <Hixie> jgraham: well i'd use a better name, but frankly i haven't seen one that wouldn't have worse problems than <dialog>
- # [11:32] <Hixie> zcorpan: :-)
- # [11:32] <othermaciej> Hixie: I mention native JSON API because ideally people would also stop using eval for this purpose (sometimes, awfully enough, eval without the proper preflight regexp)
- # [11:32] <zcorpan> Hixie: what's the problem with <dl>?
- # [11:34] <Lachy> Hixie, you could just allow <dl> to be used for dialog as well, and drop <dialog>
- # [11:34] <jgraham> Hixie: I know all the alternatives suck in their own special ways :(
- # [11:34] <Hixie> othermaciej: i recommend xml :-)
- # [11:34] <othermaciej> Hixie: no you don't
- # [11:34] <Hixie> zcorpan: it's inappropriate? it'd be like using <ol> for a set of paragraphs
- # [11:34] <Hixie> othermaciej: over json? sure it do
- # [11:34] <Hixie> i
- # [11:34] * jgraham dislikes <dl> even more than <dialog>
- # [11:34] <othermaciej> I meant, generally speaking
- # [11:35] <zcorpan> Hixie: why is it inappropriate if the spec says it's appropriate?
- # [11:35] <Hixie> othermaciej: for proprietary sending data across servers, xml is often a fine thing
- # [11:35] <Lachy> how about <transcript>
- # [11:35] <othermaciej> I think JSON is nicer than XML for dumb data though to be fair adding a native API misses the point that it was just a built-in language construct
- # [11:35] <jgraham> <transcript> sounds pretty nice, although it's not strictly right
- # [11:35] <Hixie> zcorpan: because it would be dumb for hte spec to say it's appropriate. it'd be like using <ol> for lists and paragraphs, or something equally bogus
- # [11:36] <Lachy> nah, that's work too well
- # [11:36] <Hixie> othermaciej: well, maybe. not html5's problem, either way.
- # [11:36] <othermaciej> I'll agree with that
- # [11:40] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Remote closed the connection)
- # [11:43] <Hixie> i'm more tired than i should be at this time, so i'll just go to bed.
- # [11:43] <Hixie> nn!
- # [11:43] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [11:43] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [11:46] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
- # [11:57] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
- # [12:04] * Quits: roc_ (n=roc@ip67-152-80-226.z80-152-67.customer.algx.net)
- # [12:05] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
- # [12:05] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
- # [12:13] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
- # [12:51] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [12:56] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [12:57] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [12:59] * Joins: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [12:59] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:00] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
- # [13:09] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:09] * Quits: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:12] * Joins: myakura (n=myakura@p5047-ipbf1403marunouchi.tokyo.ocn.ne.jp)
- # [13:14] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:14] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:15] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
- # [13:17] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:17] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:18] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
- # [13:21] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
- # [13:22] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:23] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:23] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:24] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:25] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:26] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:30] * Joins: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:30] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:33] * Quits: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:33] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:34] <zcorpan> annevk: can html5.org please link to the tracker?
- # [13:39] <zcorpan> i wonder if the requirement that <script src> elements must be empty is helpful or not
- # [13:40] <zcorpan> i've seen pages that use comments in <script src>, either <!--pseudo-comments--> or /* js comments */
- # [13:41] <Dashiva> It keeps the future open for allowing something there?
- # [13:42] <gsnedders> Dashiva: But that'd need be defined in HTML 2π, so requiring it to be empty in HTML 5 changes nothing
- # [13:42] <zcorpan> Dashiva: i don't think so -- html4 allows stuff there and people don't care whether the spec allows it or not anyway
- # [13:42] * gsnedders really hopes the next revision _is_ 2π
- # [13:43] <zcorpan> Dashiva: what would you allow there in the future anyway?
- # [13:43] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:43] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:44] <Dashiva> zcorpan: Nested script elements for fallback
- # [13:44] <zcorpan> Dashiva: that doesn't work in legacy browsers so not particularly good fallback story
- # [13:45] <zcorpan> Dashiva: <script type=unknown>..</script> <script> fallback </script> works
- # [13:45] <Dashiva> zcorpan: Not if you support both scripts
- # [13:45] <zcorpan> Dashiva: they might be able to communicate with each other
- # [13:45] <zcorpan> Dashiva: so the new script can set a flag that it has executed
- # [13:45] <Dashiva> That's a big might
- # [13:46] <zcorpan> maybe but <script type=unknown> .. <script> fallback </script> </script> is guarenteed to *not* work
- # [13:47] <Dashiva> You're nesting the wrong way
- # [13:48] <Dashiva> Old browsers ignore the contents, so they use the outer element's src. New browsers check the contents for another script element and use that if possible
- # [13:48] <zcorpan> nesting doens't work either way
- # [13:49] <zcorpan> Dashiva: script is cdata parsing, can't have elements in there at all. changing that would break legacy content
- # [13:49] <Philip`> Dashiva: That might hurt with <script language=unknown>/* legacy content */ document.write('<script>'); </script>
- # [13:50] <Dashiva> Philip`: This is only with @src
- # [13:50] <Philip`> Ah
- # [13:51] <zcorpan> i'd rather design a new script language for the web in such a way that it's possible to communicate with javascript
- # [13:52] <zcorpan> (like flash can communicate with javascript, at least i think it can)
- # [13:52] <annevk> zcorpan, added
- # [13:52] <zcorpan> annevk: thanks
- # [13:55] <zcorpan> Dashiva: in practice, authors just put harmless stuff in there and the validator will complain about it, and they have to move the comment out of the script element, which seems pointless
- # [13:56] <zcorpan> Dashiva: moreover, if the legacy script is external, why not let the new script be external too and have another attribute for the new script?
- # [13:56] <zcorpan> <script src=fallback newsrc=new>
- # [13:56] <Dashiva> zcorpan: And duplicate all the other attributes as well?
- # [13:57] <zcorpan> Dashiva: what other attributes?
- # [13:58] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [13:58] <Dashiva> You'd want type, to make sure you actually support the new script.
- # [13:58] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [13:59] <zcorpan> why?
- # [13:59] <zcorpan> you know you support it since you support the newsrc='' attribute
- # [14:00] <zcorpan> of course this doesn't scale to many new scripting languages
- # [14:00] <zcorpan> btw, can vbscript talk to javascript?
- # [14:00] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Read error: 104 (Connection reset by peer))
- # [14:00] <Dashiva> Well, yeah, if you make one new src for each language, that'd work, but that's kinda crazy :)
- # [14:01] <zcorpan> let's solve this problem when a new scripting language actually is introduced :)
- # [14:01] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
- # [14:02] <Dashiva> But until then, keeping our script elements neat and tidy doesn't hurt :P
- # [14:03] <zcorpan> Philip`: whenever you're bored enough, could you dig for data about pages that use <script src>..nonwhitespace..</script> ? :)
- # [14:09] <zcorpan> btw, <script src=my-interpreter id=myscript>my custom syntax script</script> could work
- # [14:10] <zcorpan> instead of <script type=my/custom>syntax script</script> <script src=my-interpreter></script>
- # [14:10] <zcorpan> (with id..)
- # [14:12] <zcorpan> although i guess that's less intiutive and so authors don't do it anyway, so might be pointless to allow it
- # [14:17] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
- # [14:19] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
- # [14:23] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
- # [14:35] <Philip`> I would guess the most common case of content in srced scripts is when people write <script src="..." />[rest of page content]
- # [14:37] <zcorpan> Philip`: i guess it would be interesting to know how common that is too :)
- # [14:38] * Philip` wishes Eclipse didn't crash immediately after loading
- # [14:40] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Read error: 110 (Connection timed out))
- # [14:43] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
- # [14:46] * Joins: aaronlev (n=chatzill@nat/ibm/x-d2a9e15913462cf4)
- # [14:51] * Quits: mcarter__ (n=mcarter@pool-72-87-174-217.plspca.dsl-w.verizon.net) (Read error: 104 (Connection reset by peer))
- # [14:53] * Joins: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [14:53] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [14:58] * Quits: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [14:58] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:00] * Joins: mcarter__ (n=mcarter@pool-72-87-174-212.plspca.dsl-w.verizon.net)
- # [15:04] * Philip` has too many pages to process them all in a reasonable time :-(
- # [15:06] <Philip`> Ah, only 10424 left
- # [15:09] <Philip`> zcorpan: http://philip.html5.org/data/nonempty-scripts.html
- # [15:13] * Joins: Lachy (n=Lachlan@85.196.122.246)
- # [15:15] * Joins: phsiao (n=shawn@nat/ibm/x-0d285ece17527dd0)
- # [15:17] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
- # [15:20] * Joins: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:20] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [15:21] * Quits: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [15:21] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:23] <zcorpan> Philip`: thanks!
- # [15:24] <zcorpan> ah, ";" is something i've seen as a way to prevent xslt to convert it to <script src='...'/>
- # [15:28] <Philip`> A couple of princeton.edu pages have a literal nbsp character inside their <script>
- # [15:28] <Philip`> I don't know if that's for the same kind of reason
- # [15:31] <zcorpan> i wonder if http://weather.noaa.gov/cgi-bin/iwszone?Sites=:njz024:njz023 put tags in script as a way to comment them out or if it actually was a mistake to put them there
- # [15:31] <zcorpan> they're duplicated before the script tag
- # [15:35] * Joins: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:35] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [15:36] <zcorpan> hsivonen: in http://validator.nu/?doc=http%3A%2F%2Fwww.agl1985.org%2F&parser=html5&showsource=yes , group messages and look at "Error: Text not allowed in element script in this context."
- # [15:37] <zcorpan> hsivonen: notice that it seems to split up the text node and complain several times about the same <script> element containing text
- # [15:39] <zcorpan> i guess that page would be helped by the requirement since it has <script src><script src></script> where it was probably intended to have 2 script elements
- # [15:40] <zcorpan> but a conformance checker might be able to detect that anyway
- # [15:40] <zcorpan> and give a warning
- # [15:41] <zcorpan> i.e., if a script element contains "<script" that is not in an escaped text span
- # [15:43] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:43] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [15:43] * Quits: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [15:44] <zcorpan> i guess authors would be stumped when the validator says to (re)move "/* ... This notice MUST stay intact for legal use ... */"
- # [15:44] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:44] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [15:45] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:54] * Quits: jacobolus (n=jacobolu@dhcp-0000036913-b5-5e.client.fas.harvard.edu)
- # [15:54] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [15:54] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [15:55] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
- # [15:55] * Quits: qwert666 (n=qwert666@dax94.neoplus.adsl.tpnet.pl) ("Leaving")
- # [16:23] <hsivonen> zcorpan: thanks. that's an undesirable but technically understandable feature of Jing
- # [16:23] * Joins: didymos (i=jho@rapwap.razor.dk)
- # [16:23] <hsivonen> zcorpan: I'll see what I can do about it
- # [16:25] * Joins: billmason (n=billmaso@ip78.unival.com)
- # [16:42] * Joins: aruner (n=chatzill@adsl-75-36-185-153.dsl.pltn13.sbcglobal.net)
- # [16:45] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
- # [16:54] <hsivonen> <discourse> might actually be better than <dialog>
- # [16:56] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
- # [16:58] <Philip`> Maybe it'd be better to drop the element entirely, since very few people will ever use it
- # [16:58] <hsivonen> oh sure
- # [16:59] <Philip`> When people are arguing over the colour of the bikeshed, the simplest solution is a bulldozer
- # [17:02] * Quits: aruner (n=chatzill@adsl-75-36-185-153.dsl.pltn13.sbcglobal.net) (Read error: 110 (Connection timed out))
- # [17:06] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [17:07] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [17:16] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [17:17] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [17:18] <hsivonen> which reminds me that I want the SVG parsing stuff unbulldozed
- # [17:18] <shepazu> then help out
- # [17:19] <shepazu> we aren't bulldozing, we are working on a proposal
- # [17:19] * zcorpan would like to have a list of requirements and a list of objections to the proposal that was in the spec
- # [17:21] <zcorpan> or rather i think it would be helpful for the interested parties
- # [17:22] <Philip`> shepazu: Is that work happening anywhere open/public?
- # [17:23] <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html
- # [17:24] <shepazu> mind, I've been on vacation for the last 2 weeks
- # [17:25] <shepazu> and I prefer the previous revision
- # [17:27] <Philip`> "Should be able to take a conforming SVG document and paste its contents into an HTML document and have it be the same DOM" - is that talking about at least one SVG document (which would be useless) or all SVG documents (which would be impossible because of the DTD stuff)?
- # [17:28] * Quits: myakura (n=myakura@p5047-ipbf1403marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
- # [17:28] <Philip`> I suppose it should be talking about the subset of SVG documents that can be generated by Inkscape and Illustrator, i.e. unprefixed element names and no fancy DTD stuff except some namespace strings (I hope)
- # [17:28] <Lachy> Yay! it's about time the W3C started investigating the copyright licence for the authoring guide. :-)
- # [17:29] <Lachy> http://lists.w3.org/Archives/Public/public-html/2008May/0295.html
- # [17:30] * Joins: jacobolus (n=jacobolu@140.247.157.74)
- # [17:30] <Lachy> I don't understand what he means by this point: "that this is a copyright and not a licensing issue"
- # [17:30] <Lachy> what's the difference?
- # [17:30] <hsivonen> shepazu: the main SVG WG objection that I am aware of is an objection that I think is misguided and should be fixed by removing the objection
- # [17:30] <shepazu> hsivonen: and the rest of us differ
- # [17:31] <hsivonen> shepazu: so how would I help out?
- # [17:31] <shepazu> in a telcon, brb
- # [17:36] * Joins: aroben (n=aroben@unaffiliated/aroben)
- # [17:40] * Joins: csarven (i=csarven@on-irc.csarven.ca)
- # [17:46] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
- # [17:49] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [17:49] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [17:58] <zcorpan> why is it a requirement that it produces the same DOM? HTML and XHTML have slightly different DOMs. shouldn't it be a requirement that the image renders the same as it would in XML?
- # [17:59] <zcorpan> e.g. it would render the same even if RDF doesn't survive
- # [18:02] <zcorpan> "Should be able to provide some sort of fallback mechanism for the SVG-in-HTML so that UAs that don’t know how to handle these SVG fragments will display the fallback."
- # [18:02] <zcorpan> i think that's orthogonal to text/html integration since it equally applies to application/xhtml+xml
- # [18:03] <annevk> can't even require rendering the same way
- # [18:03] <annevk> quirks mode baby
- # [18:03] <zcorpan> although text/html parsing can do some tricks to help, e.g. support cdata sections in some places but not others
- # [18:03] <Philip`> zcorpan: The most relevant UAs that support application/xhtml+xml also support SVG, so that's a mostly theoretical concern, whereas fallback for SVG-in-text/html is a practical concern
- # [18:03] <Lachy> why does quirks mode have to have any effect upon the rendering of SVG?
- # [18:04] <zcorpan> Lachy: case sensitivity of class
- # [18:04] * Joins: Steve_f (n=chatzill@82-44-69-8.cable.ubr02.nmal.blueyonder.co.uk)
- # [18:05] <Lachy> but does the case insenstivity need to apply to SVG elements? Why can't it just apply to HTML elements?
- # [18:05] * Quits: sverrej (n=sverrej@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
- # [18:05] * Joins: virtuelv (n=virtuelv@46.80-203-100.nextgentel.com)
- # [18:06] * Joins: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net)
- # [18:06] <zcorpan> Lachy: in firefox, opera and safari, it applies to svg as well
- # [18:07] <zcorpan> Lachy: it doesn't need to
- # [18:07] <Lachy> ah, crap :-(
- # [18:07] <zcorpan> but consistency is nice ;)
- # [18:07] <zcorpan> i think class should be case insensitive in getElementsByClassName and querySelector too
- # [18:07] <zcorpan> in quirks mode
- # [18:08] <Lachy> zcorpan, mail public-webapi about that
- # [18:08] <zcorpan> Lachy: ok
- # [18:08] <Lachy> oh, but that probably doesn't need to be specced in there
- # [18:09] <Lachy> if the case insensitivity is defined in HTML5, and Selectors defines the semantics of the class selector, it can be safely left up to those specs.
- # [18:09] <Lachy> but send mail anyway, just incase I'm wrong about it.
- # [18:09] <zcorpan> yeah i concluded the same (that html5 can define it)
- # [18:09] <zcorpan> but ok
- # [18:13] <Lachy> oh, crap :-(
- # [18:14] <Lachy> IE8 doesn't even support querySelector in quirks mode
- # [18:14] <zcorpan> sad but not very surprising
- # [18:15] <Lachy> true, since they're using the IE5.5 quirks mode engine.
- # [18:17] <Lachy> hmm. WebKit won't uppercase class names at all in quirks mode.
- # [18:18] <Lachy> <p class="FOO"> won't be matched by document.querySelector(".FOO"); (but it does match if both are lowercase)
- # [18:18] * Lachy goes to file a bug
- # [18:18] <Philip`> zcorpan: About <script src>: Did you count number of script elements, or number of pages?
- # [18:20] * Philip` notes that he doesn't guarantee his output doesn't interleave elements from different pages, since it depends on what the thread scheduler decided to do
- # [18:27] * Parts: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
- # [18:27] * Quits: jwalden (n=waldo@RANDOM-SIX-THIRTY-TWO.MIT.EDU) (Read error: 110 (Connection timed out))
- # [18:35] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
- # [18:37] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
- # [18:44] * Joins: soypunk (n=soypunk@mdp-nat251.mdp.com)
- # [18:44] * Parts: Steve_f (n=chatzill@82-44-69-8.cable.ubr02.nmal.blueyonder.co.uk)
- # [18:47] * Joins: eseidel (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net)
- # [18:47] * soypunk is now known as smedero
- # [18:51] <takkaria> ha!
- # [18:51] <takkaria> the TAG wants to make people use aria: rather than aria-
- # [18:53] * Joins: qwert666 (n=qwert666@dax94.neoplus.adsl.tpnet.pl)
- # [18:54] <Philip`> The cost-benefit analysis seems to be missing that the 'colon' approach is a "new paradigm for 'namespace'"
- # [18:55] <krijn> Iria:tating :/
- # [18:55] <Philip`> where the new paradigm involves using getAttribute instead of getAttributeNS, and not requiring xmlns, and not allowing the prefix to be variable
- # [18:56] * Joins: andersca (n=andersca@nat/apple/x-45c80fe567ecb3e5)
- # [18:56] <Philip`> i.e. whatever it is, it's not XML Namespaces
- # [18:57] <Philip`> (but is close enough to confuse people into thinking that it is)
- # [18:57] * Joins: jmb^ (n=jmb@login.ecs.soton.ac.uk)
- # [18:57] <BenMillard> takkaria, krijn and Philip` are discussin the Q&A blog entry here, I take it? http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html
- # [18:58] <krijn> I have no idea, people should not notice my comments in here ;)
- # [18:58] <Philip`> BenMillard: I think so, via http://lists.w3.org/Archives/Public/public-html/2008May/0308.html
- # [18:58] <takkaria> that's what I was referring to, yes
- # [18:58] <smedero> there's also the last TAG minutes: http://www.w3.org/2001/tag/2008/05/08-minutes
- # [18:59] <BenMillard> looks like the author of the Q&A entry pasted the HTML output of a word processor document instead of conforming with the Q&A style and structure
- # [19:00] <Philip`> The colon thing would make more sense in a world that was going to transition away from text/html and to application/xhtml+xml, since then we'd end up with a relatively clean architecture and everything
- # [19:00] <Philip`> but that's not going to happen, and we'd be stuck with a colon mess in text/html
- # [19:01] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
- # [19:01] <takkaria> Philip`: you think it's not going to happen, I daresay that the TAG think/hope it will...
- # [19:02] * Quits: JohnResig (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net) (Read error: 104 (Connection reset by peer))
- # [19:02] <BenMillard> from the minutes they consider this part of tagSoupIntegration-54 :(
- # [19:02] <BenMillard> so they look dead set on deprecating text/html as quickly as possible...still
- # [19:03] * Joins: andersca_ (n=andersca@17.255.111.222)
- # [19:03] * Joins: JohnResig (n=jresig@c-76-118-158-44.hsd1.ma.comcast.net)
- # [19:03] <Philip`> takkaria: There's a petabyte of legacy content that disagrees
- # [19:03] * Quits: eseidel (n=eseidel@c-24-130-11-246.hsd1.ca.comcast.net) (Connection timed out)
- # [19:03] <takkaria> Philip`: your argument is invalid (that people haven't yet does not mean that they will) as well you know
- # [19:03] <takkaria> however true the conclusion is. :)
- # [19:04] <zcorpan_> Hixie: shouldn't it be degrade gracefully rather than fail gracefully, since the application still works in the given example?
- # [19:04] <Philip`> takkaria: The argument is that even if everyone in the world started producing XHTML, there's just too much HTML for it to ever go away
- # [19:07] <takkaria> hmm, the minutes are interesting
- # [19:07] <Philip`> (Of course that's untrue since there won't still be humans using HTML a million years from now; but I would hope at that point the transition is to something far more radical than XHTML)
- # [19:08] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [19:08] * Quits: jmb (n=jmb@login.ecs.soton.ac.uk) (Read error: 110 (Connection timed out))
- # [19:08] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [19:09] <takkaria> hmm, the minutes are interesting reading
- # [19:09] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [19:09] <takkaria> about the SVG WG: "I think they're the obvious case to lean on for a uniform solution. They're in XML and they already have a story that says it's ok to add new attributes in foreign namespaces anywhere you like."
- # [19:09] * jmb^ is now known as jmb
- # [19:09] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [19:10] * Joins: roc (n=roc@ip67-152-80-226.z80-152-67.customer.algx.net)
- # [19:14] <BenMillard> takkaria, I agree
- # [19:15] <shepazu> takkaria: he said that about the SVG community, not the SVG WG
- # [19:16] * Quits: andersca (n=andersca@nat/apple/x-45c80fe567ecb3e5) (Read error: 110 (Connection timed out))
- # [19:16] <takkaria> shepazu: ah, my bad
- # [19:18] <shepazu> and I'm not sure I agree with him... it's now implemented, for better or worse, and that's the important thing
- # [19:18] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [19:19] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [19:19] * Joins: KevinMarks (n=KevinMar@nat/google/x-a8a41c29bad6a7dd)
- # [19:20] <zcorpan_> Philip`: i counted number of script elements
- # [19:23] <MikeSmith> takkaria: btw, any update on your plans for HTML5 parsing implementation?
- # [19:23] <takkaria> MikeSmith: yeah, I have a position to start
- # [19:23] <takkaria> MikeSmith: as in, I was accepted
- # [19:24] <takkaria> I have a printout of the relevant bits of the spec now too
- # [19:24] <takkaria> it's exam period though, so I'm only really playing around with the existing code in my breaks
- # [19:26] <hsivonen> Philip`: Henry and I disagree on which is worse: colon but no NS processing or having a non-colon delimiter
- # [19:27] <hsivonen> Philip`: I think colon without NS processing is worse than going to non-NS processing using an untainted delimiter
- # [19:27] <hsivonen> people with Member access may be interested in http://lists.w3.org/Archives/Member/tag/2008May/0026.html
- # [19:28] <Philip`> People without Member access could be interested too :-)
- # [19:28] <hsivonen> yeah :-(
- # [19:29] <MikeSmith> Bobby "Blue" Bland had a great song called "Members Only"
- # [19:31] * Joins: weinig (n=weinig@17.203.15.172)
- # [19:32] <MikeSmith> and Jimi Hendrix had a great song called "Castles Made of Sand"
- # [19:33] <takkaria> yeah, that's a fantastic song
- # [19:34] <takkaria> I'm trying to work out what could possibly end the permathread
- # [19:34] <MikeSmith> good luck with that
- # [19:34] <takkaria> I think some people just have yet to be convinced that there are cases where alt text is genuinely not available
- # [19:34] <Philip`> I imagine the one thing that won't end the thread is posting to it :-)
- # [19:34] * takkaria grins
- # [19:35] <Philip`> Of course the other thing that won't end it is not posting to it
- # [19:36] * Joins: malware (n=MikeSmit@58.157.21.205)
- # [19:36] <takkaria> the straw men make having a decent debate hard :(
- # [19:36] <takkaria> IME, this kind of thing is best resolved by sitting down and negotiating one-on-one, at least in real life
- # [19:36] * Joins: jwalden (n=waldo@STRATTON-THREE-TWENTY-NINE.MIT.EDU)
- # [19:37] <Philip`> You can defeat the straw men by starting a flamewar
- # [19:37] <takkaria> personally I find the a11y people including personal insults all the time to be on par with trying to start a flamewar
- # [19:38] <Philip`> I think "all the time" is quite an exaggeration
- # [19:39] <Philip`> and "the a11y people" is quite a term which I've forgotten
- # [19:39] <Philip`> Uh, a generalisation?
- # [19:40] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [19:41] <takkaria> well, of the posts I've made on that topic since I started it, I think most of the replies to me included some implications that I was thoughtless, naive, ignorant, presumptious etc
- # [19:41] <takkaria> (not all of the above in any one post, but one of them in most)
- # [19:42] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [19:42] <MikeSmith> I can imagine that some might say that the whole should-alt-be-required discussion is massive waste of time that could have been completely prevented by some better judgement on the part of the editor
- # [19:42] * Quits: malware (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
- # [19:45] <Philip`> MikeSmith: Better technical judgement, or better appease-everyone-so-they-stop-arguing judgement?
- # [19:46] <MikeSmith> neither
- # [19:51] <takkaria> I increasingly think that asking a photographer-for-a-living to provide alt text for e.g. a portfolio website is actually insane, because the purpose of the portfolio is to show photographs
- # [19:51] <Dashiva> At least the strawmen are accessible strawmen :)
- # [19:52] <hsivonen> this is a reply to me but I don't understand its point: http://lists.w3.org/Archives/Public/public-html/2008May/0303.html can someone help me understand it?
- # [19:53] <Philip`> hsivonen: Not me, I'm afraid
- # [19:53] * takkaria adds that posts to his list of reasons top-posting is bad
- # [19:53] * Quits: andersca_ (n=andersca@17.255.111.222) ("a")
- # [19:53] <hsivonen> what's a 'lambda user'?
- # [19:54] <Philip`> takkaria: He could have put his reply at the bottom and it would not have made any more sense
- # [19:54] <takkaria> Philip`: no, but as a consequence of not top-posting, people tend to actually reply to points more than just go off on one
- # [19:55] <Dashiva> Philip`: The opposite to top-posting isn't bottom-posting, but context-posting
- # [19:55] <takkaria> that is, I believe inline quotes make people actually think about what they want to say. :)
- # [19:55] <Philip`> Dashiva: That seems an odd definition of "opposite"
- # [19:55] <BenMillard> Dashiva, it is the opposite in terms of position but not in terms of usefulness
- # [19:55] <Philip`> I'd just say it's one of several alternatives
- # [19:56] * Quits: aaronlev (n=chatzill@nat/ibm/x-d2a9e15913462cf4) (Read error: 104 (Connection reset by peer))
- # [19:56] <Philip`> (and the non-context-based ones of those alternatives make messages hard to understand)
- # [19:56] <Dashiva> Philip`: Well, top-posting is really just outside-posting with the reply put at the bottom by the client as default
- # [19:57] <Philip`> Hmm, how about two-column email? Put the original in the left and line up your replies on the right
- # [19:57] * Quits: dbaron (n=dbaron@c-71-204-153-3.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
- # [19:58] <Dashiva> I've tried doing that in lecture notes. Code in one column, and comments to it in the other
- # [19:58] <Dashiva> The comment column got really easily out of sync, when a preceding comment linewrapped or similar. Needs quality UI to work :)
- # [19:58] * hsivonen now sees the TAG posted the ARIA stuff to the WG
- # [19:58] <hsivonen> sigh
- # [19:59] * Joins: aruner (n=chatzill@guest-226.mountainview.mozilla.com)
- # [19:59] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 104 (Connection reset by peer))
- # [19:59] <Dashiva> Philip`: Then again, you are the person who didn't fix Hixie's graph, so surely you can not do it
- # [20:01] <Philip`> Dashiva: I'm too busy to not do anything useful now, since I'm waiting to see if an order delivery status will change from "With Delivery Driver" to something more useful before I get bored and go home, and that takes up all my concentration
- # [20:02] <Philip`> (The delivery driver has had it for 11 hours now, so I don't see why it's taking them so long...)
- # [20:02] <hsivonen> I notice that the "cost/benefit analysis" was not amended to take into account feedback I gave f2f
- # [20:03] <MikeSmith> hsivonen: so please take some time to e-mail HT and point that out
- # [20:03] <MikeSmith> instead of bitching about it here
- # [20:04] <hsivonen> ok. here we go again
- # [20:05] <MikeSmith> hsivonen: yeah, I understand. I just don't know what the alternative is
- # [20:05] * Joins: starjive (i=beos@213-66-217-32-no30.tbcn.telia.com)
- # [20:06] <MikeSmith> what I do know is that the alternative of me communicating to others about it by proxy is not practical alternative
- # [20:07] * Quits: jgraham (n=jgraham@81-86-212-222.dsl.pipex.com) ("Ex-Chat")
- # [20:15] <hsivonen> MikeSmith: sure. I'm just not particularly happy about finding myself writing email about this again after thinking I already communicated f2f
- # [20:16] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
- # [20:17] <MikeSmith> hsivonen: there are many things these days that I find myself needing to do that I'm not particularly happy about
- # [20:18] <Philip`> ("Delivered: 14/05/2008 10:50:45" - oh, thanks for telling me eight hours later)
- # [20:20] * Joins: qwert666_ (n=qwert666@dax94.neoplus.adsl.tpnet.pl)
- # [20:22] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
- # [20:22] <Dashiva> Well, I for one am pleased nobody has pulled the formal complaint thing again.
- # [20:22] <Philip`> They probably noticed that it wasn't very effective last time
- # [20:29] * Joins: roc_ (n=roc@38.99.84.33)
- # [20:29] * Joins: eseidel (n=eseidel@nat/google/x-81efeb9ebc02e0bf)
- # [20:30] * Quits: jwalden (n=waldo@STRATTON-THREE-TWENTY-NINE.MIT.EDU) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
- # [20:36] * aroben is now known as aroben|away
- # [20:37] <Dashiva> Ooh, bad voiceover diss in that mail
- # [20:37] <Dashiva> It's too bad AT doesn't compete on who's the best rather than who's the worst :)
- # [20:38] * Joins: jgraham (n=jgraham@81-86-212-222.dsl.pipex.com)
- # [20:38] * Quits: qwert666 (n=qwert666@dax94.neoplus.adsl.tpnet.pl) (Read error: 110 (Connection timed out))
- # [20:40] <hsivonen> MikeSmith: email sent
- # [20:42] <takkaria> hsivonen: you have a bias against making your own content accessible, did you know?
- # [20:43] <MikeSmith> hsivonen: thanks. as always
- # [20:43] <hsivonen> takkaria: do I?
- # [20:44] <takkaria> hsivonen: according to a reply to your last-but-one post on public-html
- # [20:45] * Joins: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU)
- # [20:48] * Quits: roc (n=roc@ip67-152-80-226.z80-152-67.customer.algx.net) (Read error: 110 (Connection timed out))
- # [20:50] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
- # [20:52] <zcorpan_> hsivonen: do you agree with my <script src> analysis? would it make sense to implement the suggested checks?
- # [20:54] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
- # [20:56] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
- # [20:58] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [21:00] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [21:12] <zcorpan_> hsivonen: hmm, i never understood it as dispatching on qname and ignoring namespace, but rather support both {null, 'aria-foo'} and {...aria namespace..., 'foo'}
- # [21:13] <zcorpan_> hsivonen: although he's just been talking about the colon, not how it'd actually be implemented, so it's a bit unclear
- # [21:13] <zcorpan_> er
- # [21:13] <zcorpan_> s/aria-foo/aria:foo/
- # [21:18] * Quits: roc_ (n=roc@38.99.84.33) (Read error: 110 (Connection timed out))
- # [21:20] <virtuelv> why can't we have aria*foo or aria _m_O~o_m_foo
- # [21:20] <zcorpan_> virtuelv: they are not well-formed in xml, unfortunately
- # [21:20] <virtuelv> pity
- # [21:20] <zcorpan_> indeed
- # [21:21] * aroben|away is now known as aroben
- # [21:24] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
- # [21:28] <virtuelv> I particularily like _m_O~o_m_
- # [21:28] <virtuelv> on an unrelated note: How far is CSS 2.1 from exiting CR state?
- # [21:29] <zcorpan_> a couple of thousand test cases away maybe? i don't know what happens with css these days
- # [21:29] <virtuelv> (provided we could drop the aural stuff, and say "CSS 3 module" for it
- # [21:30] <virtuelv> heh, which is only optional in the spec, I see
- # [21:30] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [21:30] <zcorpan_> speaking of which, i should check the status of the magic body stuff
- # [21:31] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [21:32] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [21:33] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [21:41] * Joins: sverrej (n=sverrej@89.10.27.86)
- # [22:09] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
- # [22:17] <Hixie> what's the law that hsivonen refers to sometimes to the effect that a technology ends up having as many components as working groups?
- # [22:18] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
- # [22:18] <Philip`> Sounds like http://en.wikipedia.org/wiki/Conway's_Law
- # [22:18] <hsivonen> that's it
- # [22:19] <Hixie> aha!
- # [22:20] <Hixie> it's not in the list of adages on wikipedia
- # [22:20] * Hixie adds it
- # [22:20] <Philip`> It's in http://en.wikipedia.org/wiki/List_of_adages_named_after_people
- # [22:20] <Philip`> Clearly there needs to be a list of lists of adages
- # [22:20] <Hixie> heh
- # [22:23] * Parts: vlad_ (n=asdf@69-12-240-128.dsl.static.sonic.net)
- # [22:26] * Quits: csarven (i=csarven@on-irc.csarven.ca) ("http://www.csarven.ca")
- # [22:27] * Quits: phsiao (n=shawn@nat/ibm/x-0d285ece17527dd0)
- # [22:34] * Quits: aruner (n=chatzill@guest-226.mountainview.mozilla.com) (Read error: 110 (Connection timed out))
- # [22:36] * Quits: virtuelv (n=virtuelv@46.80-203-100.nextgentel.com) (Read error: 104 (Connection reset by peer))
- # [22:47] * Joins: jgraham__ (n=jgraham@81-86-222-155.dsl.pipex.com)
- # [22:49] * Quits: jgraham (n=jgraham@81-86-212-222.dsl.pipex.com) (Read error: 110 (Connection timed out))
- # [22:56] * Joins: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [22:58] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
- # [22:59] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [23:00] * Quits: othermaciej_ (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [23:03] * Quits: sverrej (n=sverrej@89.10.27.86) (Read error: 110 (Connection timed out))
- # [23:04] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [23:05] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [23:14] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 104 (Connection reset by peer))
- # [23:14] * Joins: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net)
- # [23:19] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
- # [23:24] <Dashiva> Pragmatism, the lost art
- # [23:32] * Joins: andersca (n=andersca@nat/apple/x-a8adc4721968fdbc)
- # [23:35] <weinig> annevk: ping
- # [23:36] * Quits: othermaciej (n=mjs@dsl027-178-204.sfo1.dsl.speakeasy.net) (Read error: 110 (Connection timed out))
- # [23:45] <gsnedders> jgraham__: how do you get what Element.textContent would using lxml?
- # [23:48] <hsivonen> following implication arrows in the wrong direction seems to be too common
- # [23:48] <jgraham__> gsnedders: Recursion
- # [23:48] <gsnedders> jgraham__: k. so there is no simpler way :(
- # [23:48] <jgraham__> (or similar)
- # [23:49] <jgraham__> gsnedders: I don't know of a simpler way. There might be one I guess
- # [23:49] <jgraham__> hsivonen: Gez?
- # [23:54] <Dashiva> So much struggle to gain a tiny potential bit of accessibility for conforming documents, at the cost of so many non-conforming documents...
- # [23:55] <gsnedders> jgraham__: OK, I give in. lxml is quick enough :)
- # [23:56] <Philip`> gsnedders: If it's quick enough, your data set is too small
- # [23:56] * Joins: andersca_ (n=andersca@17.255.111.222)
- # [23:56] <gsnedders> Philip`: I'm just operating on a couple month old copy of HTML 5
- # [23:56] * Joins: weinig_ (n=weinig@17.255.110.250)
- # [23:56] <gsnedders> Philip`: And I doubt anything larger will be using it
- # [23:57] * Joins: weinig__ (n=weinig@nat/apple/x-3aaa2d0b096d7357)
- # [23:57] <hsivonen> jgraham__: among others
- # [23:58] <Philip`> gsnedders: What about HTML6?
- # [23:58] * Quits: eseidel (n=eseidel@nat/google/x-81efeb9ebc02e0bf)
- # [23:58] * gsnedders wonders whether implementing DOM on top of lxml would be sane
- # [23:58] <Philip`> Given the way HTML5 is developed, the spec can never get smaller, because that would involve being less precise or dropping features
- # [23:59] <Philip`> so you need to be sufficiently forward-looking when developing tools
- # [23:59] <takkaria> Philip`: unless Hixie gets cloned and he can split out bits HTML5 into another spec, whilst still editing it all
- # [23:59] <Philip`> else you'll get the same problem that the W3C tools get when trying to process the HTML5 spec
- # [23:59] <zcorpan_> Philip`: it could drop non-normative stuff without being less precise or dropping features
- # [23:59] <takkaria> it's a possibility, anyway
- # Session Close: Thu May 15 00:00:00 2008
The end :)