/irc-logs / freenode / #whatwg / 2010-01-11 / end

Options:

# Session Start: Mon Jan 11 00:00:00 2010
# Session Ident: #whatwg
# [00:09] * Joins: tyoshino_ (n=tyoshino@220.109.219.244)
# [00:12] * Quits: _Utkarsh (n=admin@117.201.81.59) (Read error: 110 (Connection timed out))
# [00:25] * Joins: paul_iri_ (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net)
# [00:26] * Joins: paul_ir__ (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net)
# [00:28] * Quits: tyoshino (n=tyoshino@220.109.219.244) (Read error: 110 (Connection timed out))
# [00:31] * Quits: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) (Read error: 60 (Operation timed out))
# [00:44] * Quits: paul_iri_ (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) (Read error: 110 (Connection timed out))
# [00:45] * paul_ir__ is now known as paul_irish
# [00:45] * Parts: smq-monstros1ty (n=monstros@c-71-192-29-25.hsd1.ma.comcast.net)
# [01:06] * Joins: tndH_ (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
# [01:07] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Read error: 110 (Connection timed out))
# [01:07] * tndH_ is now known as tndH
# [01:07] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [01:16] * Quits: seventh (i=seventh@189.59.203.94) ("...")
# [01:24] * Joins: _Utkarsh (n=admin@117.201.81.92)
# [01:26] * Quits: Utkarsh (n=admin@117.201.80.47) (Read error: 60 (Operation timed out))
# [01:27] * Quits: rauchg (n=rauchg@99-7-171-49.lightspeed.sntcca.sbcglobal.net)
# [01:29] <Hixie> something's leaking in apache on my server
# [01:31] <Hixie> Lachy: fixed
# [01:33] <Philip`> Must be the cats
# [01:33] <Dashiva> cat apache
# [01:35] * Joins: Utkarsh (n=admin@117.201.81.56)
# [01:36] * Joins: paul_iri_ (n=paul_iri@32.136.34.65)
# [01:44] <Lachy> Hixie, thanks
# [01:45] <Lachy> I just upgraded the wordpress installation
# [01:45] * Lachy makes a note to check for mediawiki upgrade later
# [01:48] * Quits: _Utkarsh (n=admin@117.201.81.92) (Read error: 110 (Connection timed out))
# [01:50] * Joins: erlehmann_ (n=erlehman@82.113.121.226)
# [01:53] * Quits: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) (Read error: 113 (No route to host))
# [01:54] <ttepasse> Hm. Why isn't there a isProtocolHandlerRegistered() to registerProtocolHandler()?
# [01:56] <Hixie> because we don't want to expose whether the user deleted the registration or not
# [01:56] <Hixie> just call register...() againt
# [01:56] <Hixie> again, even
# [01:57] <ttepasse> Ah.
# [02:05] * erlehmann_ is now known as erlehmnn
# [02:08] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
# [02:14] * Quits: erlehmann (n=erlehman@82.113.106.230) (Read error: 110 (Connection timed out))
# [02:14] * Quits: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) ("Leaving")
# [02:15] * erlehmnn is now known as erlehman
# [02:15] * erlehman is now known as erlehmann
# [02:15] * Joins: rauchg (n=rauchg@99-7-171-49.lightspeed.sntcca.sbcglobal.net)
# [02:17] * paul_iri_ is now known as paul_irish
# [02:41] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
# [02:41] * Joins: cedricv (n=cedric@116.197.236.91)
# [02:46] * Joins: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
# [03:06] * Quits: Heimidal (n=heimidal@unaffiliated/heimidal) ("Leaving...")
# [03:11] * Joins: aho (n=nya@f050232108.adsl.alicedsl.de)
# [03:41] * Quits: bzed (n=bzed@devel.recluse.de) (Read error: 104 (Connection reset by peer))
# [03:43] * Joins: bzed (n=bzed@devel.recluse.de)
# [03:45] * Quits: rauchg (n=rauchg@99-7-171-49.lightspeed.sntcca.sbcglobal.net)
# [04:08] * Quits: aho (n=nya@f050232108.adsl.alicedsl.de) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: vvv (n=vvv@mediawiki/VasilievVV) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: onar (n=onar@17.226.20.255) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: syp_ (n=syp@lasigpc9.epfl.ch) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: fupp (n=User@mg038a.studby.ntnu.no) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Vito` (n=vitorio@cpe-68-203-22-47.austin.res.rr.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: hoodow (n=hoodow@2001:41d0:1:f5e5:0:0:0:666) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: cedricv (n=cedric@116.197.236.91) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: paul_irish (n=paul_iri@32.136.34.65) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: riven (n=riven@53518387.cable.casema.nl) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: karlushi (n=karlushi@fw.vdl2.ca) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: smaug (n=chatzill@cs181150024.pp.htv.fi) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Rik|work (n=Rik|work@fw01d.skyrock.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Yudai (n=Yudai@p6ea250.kngwnt01.ap.so-net.ne.jp) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: pablof (n=palbo@pat-tdc.opera.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: webben (n=benjamin@173-45-238-110.slicehost.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: doublec (n=doublec@li30-216.members.linode.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: navap (i=navap@gateway/shell/blinkenshell.org/x-izhaemnnwdfjrrak) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: deltab (n=deltab@82-46-155-15.cable.ubr02.smal.blueyonder.co.uk) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Utkarsh (n=admin@117.201.81.56) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: karlcow (n=karl@nerval.la-grange.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: AryehGregor (n=Simetric@mediawiki/simetrical) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Lachy (n=Lachlan@85.196.122.246) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: gavin (n=gavin@firefox/developer/gavin) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: bzed (n=bzed@devel.recluse.de) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: ttepasse (n=ttepas--@dslb-084-060-025-019.pools.arcor-ip.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: jwalden (n=waldo@adsl-71-147-38-186.dsl.emhril.sbcglobal.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: erikvold (n=erikvold@S01060024012860e9.gv.shawcable.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: foolip (n=philip@h-63-95.A163.priv.bahnhof.se) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Dashiva (i=Dashiva@wikia/Dashiva) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: hober (n=ted@unaffiliated/hober) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: scherkus_ (n=scherkus@74.125.59.73) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: ukai (n=ukai@220.109.219.244) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: ray (i=ray@drong.notacat.org) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: erlehmann (n=erlehman@82.113.121.226) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: tyoshino_ (n=tyoshino@220.109.219.244) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: MikeSmith (n=MikeSmit@EM114-48-5-74.pool.e-mobile.ne.jp) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: ciaran_lee (i=leecn@spoon.netsoc.tcd.ie) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: dimich (n=dimich@74.125.59.65) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: hendry (n=hendry@webvm.net) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: JohnResig (n=JohnResi@ejohn.org) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: gsnedders (n=gsnedder@204.232.194.186) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: k0rnel (n=k0rnel@krtko.org) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: egn (n=egn@li101-203.members.linode.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: jarib (i=jarib@li139-179.members.linode.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: jtbandes (n=jtbandes@unaffiliated/jtbandes) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: drry (n=drry@unaffiliated/drry) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: bobs_ (n=oeskola@kekkonen.cs.hut.fi) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: jmb (n=jmb@login.ecs.soton.ac.uk) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: yutak_home (n=kee@N038037.ppp.dion.ne.jp) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: ivan` (n=ivan@unaffiliated/ivan/x-000001) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: danbri (n=danbri@unaffiliated/danbri) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: payman (n=payman@pat.se.opera.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: inimino (n=inimino@atekomi.inimino.org) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: hamaji (n=hamaji@220.109.219.244) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: daedb (n=daed@h11n1fls34o986.telia.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: mikekelly (i=mikek@s3x0r.biz) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: sebmarkbage (n=miranda@213.80.108.29) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: jorlow (n=jorlow@nat/google/x-zwkypjucygexmvgi) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: kinetik (n=kinetik@121.98.132.55) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Philip` (n=philip@zaynar.co.uk) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: hsivonen (n=hsivonen@130.233.41.50) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: crash\ (i=crash@lubyte.de) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: peroo (n=peroo@peroo.xen.prgmr.com) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: broquaint (i=62cb5519@81.102.240.104) (niven.freenode.net irc.freenode.net)
# [04:08] * Quits: Hixie (i=ianh@trivini.no) (niven.freenode.net irc.freenode.net)
# [04:08] * Joins: aho (n=nya@f050232108.adsl.alicedsl.de)
# [04:08] * Joins: vvv (n=vvv@mediawiki/VasilievVV)
# [04:08] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
# [04:08] * Joins: syp_ (n=syp@lasigpc9.epfl.ch)
# [04:08] * Joins: onar (n=onar@17.226.20.255)
# [04:10] * Joins: bzed (n=bzed@devel.recluse.de)
# [04:10] * Joins: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
# [04:10] * Joins: cedricv (n=cedric@116.197.236.91)
# [04:10] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
# [04:10] * Joins: erlehmann (n=erlehman@82.113.121.226)
# [04:10] * Joins: paul_irish (n=paul_iri@32.136.34.65)
# [04:10] * Joins: Utkarsh (n=admin@117.201.81.56)
# [04:10] * Joins: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
# [04:10] * Joins: tyoshino_ (n=tyoshino@220.109.219.244)
# [04:10] * Joins: MikeSmith (n=MikeSmit@EM114-48-5-74.pool.e-mobile.ne.jp)
# [04:10] * Joins: karlcow (n=karl@nerval.la-grange.net)
# [04:10] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [04:10] * Joins: ttepasse (n=ttepas--@dslb-084-060-025-019.pools.arcor-ip.net)
# [04:10] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
# [04:10] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
# [04:10] * Joins: jwalden (n=waldo@adsl-71-147-38-186.dsl.emhril.sbcglobal.net)
# [04:10] * Joins: riven (n=riven@53518387.cable.casema.nl)
# [04:10] * Joins: erikvold (n=erikvold@S01060024012860e9.gv.shawcable.net)
# [04:10] * Joins: yutak_home (n=kee@N038037.ppp.dion.ne.jp)
# [04:10] * Joins: AryehGregor (n=Simetric@mediawiki/simetrical)
# [04:10] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [04:10] * Joins: mikekelly (i=mikek@s3x0r.biz)
# [04:10] * Joins: foolip (n=philip@h-63-95.A163.priv.bahnhof.se)
# [04:10] * Joins: ivan` (n=ivan@unaffiliated/ivan/x-000001)
# [04:10] * Joins: danbri (n=danbri@unaffiliated/danbri)
# [04:10] * Joins: gavin (n=gavin@firefox/developer/gavin)
# [04:10] * Joins: fupp (n=User@mg038a.studby.ntnu.no)
# [04:10] * Joins: navap (i=navap@gateway/shell/blinkenshell.org/x-izhaemnnwdfjrrak)
# [04:10] * Joins: ciaran_lee (i=leecn@spoon.netsoc.tcd.ie)
# [04:10] * Joins: payman (n=payman@pat.se.opera.com)
# [04:10] * Joins: karlushi (n=karlushi@fw.vdl2.ca)
# [04:10] * Joins: Dashiva (i=Dashiva@wikia/Dashiva)
# [04:10] * Joins: smaug (n=chatzill@cs181150024.pp.htv.fi)
# [04:10] * Joins: hober (n=ted@unaffiliated/hober)
# [04:10] * Joins: scherkus_ (n=scherkus@74.125.59.73)
# [04:10] * Joins: dimich (n=dimich@74.125.59.65)
# [04:10] * Joins: inimino (n=inimino@atekomi.inimino.org)
# [04:10] * Joins: hamaji (n=hamaji@220.109.219.244)
# [04:10] * Joins: hoodow (n=hoodow@2001:41d0:1:f5e5:0:0:0:666)
# [04:10] * Joins: daedb (n=daed@h11n1fls34o986.telia.com)
# [04:10] * Joins: Rik|work (n=Rik|work@fw01d.skyrock.net)
# [04:10] * Joins: hendry (n=hendry@webvm.net)
# [04:10] * Joins: Yudai (n=Yudai@p6ea250.kngwnt01.ap.so-net.ne.jp)
# [04:10] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
# [04:10] * Joins: Hixie (i=ianh@trivini.no)
# [04:10] * Joins: bobs_ (n=oeskola@kekkonen.cs.hut.fi)
# [04:10] * Joins: broquaint (i=62cb5519@81.102.240.104)
# [04:10] * Joins: ray (i=ray@drong.notacat.org)
# [04:10] * Joins: jmb (n=jmb@login.ecs.soton.ac.uk)
# [04:10] * Joins: k0rnel (n=k0rnel@krtko.org)
# [04:10] * Joins: jarib (i=jarib@li139-179.members.linode.com)
# [04:10] * Joins: drry (n=drry@unaffiliated/drry)
# [04:10] * Joins: ukai (n=ukai@220.109.219.244)
# [04:10] * Joins: jtbandes (n=jtbandes@unaffiliated/jtbandes)
# [04:10] * Joins: peroo (n=peroo@peroo.xen.prgmr.com)
# [04:10] * Joins: gsnedders (n=gsnedder@204.232.194.186)
# [04:10] * Joins: JohnResig (n=JohnResi@ejohn.org)
# [04:10] * Joins: crash\ (i=crash@lubyte.de)
# [04:10] * Joins: Philip` (n=philip@zaynar.co.uk)
# [04:10] * Joins: kinetik (n=kinetik@121.98.132.55)
# [04:10] * Joins: hsivonen (n=hsivonen@130.233.41.50)
# [04:10] * Joins: jorlow (n=jorlow@nat/google/x-zwkypjucygexmvgi)
# [04:10] * Joins: sebmarkbage (n=miranda@213.80.108.29)
# [04:10] * Joins: egn (n=egn@li101-203.members.linode.com)
# [04:10] * Joins: Vito` (n=vitorio@cpe-68-203-22-47.austin.res.rr.com)
# [04:10] * Joins: webben (n=benjamin@173-45-238-110.slicehost.net)
# [04:10] * Joins: doublec (n=doublec@li30-216.members.linode.com)
# [04:10] * Joins: pablof (n=palbo@pat-tdc.opera.com)
# [04:10] * Joins: deltab (n=deltab@82-46-155-15.cable.ubr02.smal.blueyonder.co.uk)
# [04:11] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [04:26] * Quits: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp) (Read error: 60 (Operation timed out))
# [04:30] * Quits: ttepasse (n=ttepas--@dslb-084-060-025-019.pools.arcor-ip.net) (Read error: 110 (Connection timed out))
# [04:37] * Quits: cedricv (n=cedric@116.197.236.91)
# [04:44] * Quits: jwalden (n=waldo@adsl-71-147-38-186.dsl.emhril.sbcglobal.net) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.1.6/20091216142458]")
# [04:46] * Joins: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
# [04:50] * Joins: dave_levin (n=dave_lev@216.239.45.130)
# [04:59] * Joins: dave_levin_ (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
# [05:12] * Joins: sirdarckcat (n=sdc@unaffiliated/sirdarckcat)
# [05:12] <sirdarckcat> hello, I have a question regarding the CSS3 spec
# [05:12] <sirdarckcat> why the "Malformed statements"
# [05:13] <sirdarckcat> from
# [05:13] <sirdarckcat> http://www.w3.org/TR/CSS2/syndata.html#parsing-errors
# [05:13] <sirdarckcat> was removed on
# [05:13] <sirdarckcat> http://www.w3.org/TR/css3-syntax/#error-handling
# [05:13] <sirdarckcat> how should a parser behave if it finds a selector that can't be parsed?
# [05:15] <AryehGregor> Drop it and the following block, I believe.
# [05:15] <AryehGregor> Easy to test.
# [05:15] <sirdarckcat> hmm, yes, that's how browsers behave.. my meaning is
# [05:15] <sirdarckcat> if there was a particular reason to remove it from the spec
# [05:15] <AryehGregor> Dunno.
# [05:16] <aho> halt and catch fire if it's IE :>
# [05:16] <AryehGregor> You could ask www-style.
# [05:16] <sirdarckcat> mailing list or channel?
# [05:16] <sirdarckcat> oh
# [05:16] <sirdarckcat> mailing list
# [05:16] <sirdarckcat> haha
# [05:16] <AryehGregor> There's a #css here, but I don't think the spec editors hang out there regularly. I believe there's a W3C IRC network too. But I meant the list.
# [05:16] <sirdarckcat> yes hehe
# [05:17] * Quits: dave_levin (n=dave_lev@216.239.45.130) (Read error: 110 (Connection timed out))
# [05:17] * dave_levin_ is now known as dave_levin
# [05:17] <sirdarckcat> oh well, I was just trying to see if there was some point I was missing
# [05:17] <sirdarckcat> I'll ask them
# [05:17] <sirdarckcat> thanks
# [05:17] <AryehGregor> I didn't even look at the spec, TBH.
# [05:17] <AryehGregor> Just be sure it wasn't just moved someplace else or anything.
# [05:18] <sirdarckcat> yeah, I'm trying to see the tokenization section, and the selector := any+ seems to imply that almost anything is acceptable
# [05:18] * Joins: dave_levin_ (n=dave_lev@216.239.45.130)
# [05:18] <sirdarckcat> but stuff like
# [05:18] <sirdarckcat> ^= and $= selectors are not declared in that syntax
# [05:19] <sirdarckcat> but its normal, since the document states that the SELECT chapter should be merged
# [05:19] <sirdarckcat> anyway, I still find it difficult to find a specific about what to do
# [05:19] * Hixie tries to work out what document.clear() is
# [05:21] <Hixie> sirdarckcat: look at the dates of those documents - the CSS2 one is from sept 2009, the CSS3 one is from Aug 2003.
# [05:21] <aho> back to the future :v
# [05:27] * Joins: MikeSmithX (n=MikeSmit@EM114-48-146-47.pool.e-mobile.ne.jp)
# [05:30] * Quits: MikeSmith (n=MikeSmit@EM114-48-5-74.pool.e-mobile.ne.jp) (Read error: 54 (Connection reset by peer))
# [05:36] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
# [05:36] * dave_levin_ is now known as dave_levin
# [05:49] * Quits: vvv (n=vvv@mediawiki/VasilievVV) (Read error: 110 (Connection timed out))
# [05:54] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
# [06:00] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
# [06:14] <Hixie> anyone know what the term "activation object" in ES3 became in ES5?
# [06:20] * Quits: flea (n=flea@unaffiliated/flea) (Read error: 110 (Connection timed out))
# [06:20] * Joins: flea (n=flea@71.23.116.3)
# [06:24] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
# [06:25] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [06:32] * Joins: cedricv (n=cedric@112.199.162.33)
# [06:32] <sirdarckcat> @Hixie, oh you are right
# [06:32] <sirdarckcat> thanks
# [06:40] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
# [06:47] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
# [06:47] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Remote closed the connection)
# [07:21] * Quits: aho (n=nya@f050232108.adsl.alicedsl.de) (Read error: 113 (No route to host))
# [07:31] * Joins: nessy (n=Adium@121.90.128.201)
# [07:43] * Quits: sirdarckcat (n=sdc@unaffiliated/sirdarckcat) (Read error: 104 (Connection reset by peer))
# [07:46] * Joins: zalan (n=zalan@catv-89-135-144-122.catv.broadband.hu)
# [07:54] * Joins: nessy1 (n=Adium@121.90.110.251)
# [07:58] <Hixie> hole kittens, i actually got below 90 bugs finally
# [07:58] <Hixie> i thought that was like some sort of unbreakable barrier there for a while
# [08:01] * Quits: dave_levin (n=dave_lev@216.239.45.130)
# [08:03] * Joins: Ruetobas (i=Ruetobas@114-32-107-228.HINET-IP.hinet.net)
# [08:03] * Quits: nessy1 (n=Adium@121.90.110.251) ("Leaving.")
# [08:06] * Quits: nessy (n=Adium@121.90.128.201) (Read error: 110 (Connection timed out))
# [08:06] * Joins: _mg_ (n=quassel@p5083C4F0.dip.t-dialin.net)
# [08:35] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
# [08:35] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [08:38] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
# [08:40] * Quits: MikeSmithX (n=MikeSmit@EM114-48-146-47.pool.e-mobile.ne.jp) (Read error: 113 (No route to host))
# [08:41] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
# [08:48] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
# [08:49] * Parts: _mg_ (n=quassel@p5083C4F0.dip.t-dialin.net) ("http://quassel-irc.org - Chat comfortably. Anywhere.")
# [09:06] * Joins: pesla (n=retep@procurios.xs4all.nl)
# [09:16] * Joins: nessy (n=Adium@121.90.51.25)
# [09:23] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 110 (Connection timed out))
# [09:24] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [09:31] * Quits: zalan (n=zalan@catv-89-135-144-122.catv.broadband.hu) (Read error: 110 (Connection timed out))
# [09:49] * Quits: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
# [09:56] * Joins: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp)
# [10:02] * Joins: franksalim (n=frank@adsl-76-221-202-115.dsl.pltn13.sbcglobal.net)
# [10:03] * Quits: franksalim (n=frank@adsl-76-221-202-115.dsl.pltn13.sbcglobal.net) (Client Quit)
# [10:07] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
# [10:09] * Joins: nessy1 (n=Adium@121.90.16.22)
# [10:11] * Quits: nessy (n=Adium@121.90.51.25) (Read error: 110 (Connection timed out))
# [10:13] * Joins: MikeSmith (n=MikeSmit@EM114-48-12-154.pool.e-mobile.ne.jp)
# [10:17] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
# [10:25] * Joins: workmad3 (n=workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
# [10:28] * Parts: nessy1 (n=Adium@121.90.16.22)
# [10:31] * Joins: GarethAdams|Work (n=GarethAd@pdpc/supporter/active/GarethAdams)
# [10:45] * Joins: mat_t (n=mattomas@91.189.88.12)
# [10:50] * Joins: nessy (n=Adium@121.90.86.174)
# [10:58] * Quits: Utkarsh (n=admin@117.201.81.56) (Read error: 113 (No route to host))
# [10:59] * Joins: ROBOd (n=robod@89.122.216.38)
# [11:01] * Joins: nessy1 (n=Adium@121.90.249.84)
# [11:02] * Joins: vvv (n=vvv@mediawiki/VasilievVV)
# [11:07] * Joins: remysharp (n=remyshar@cpc3-brig16-2-0-cust389.3-3.cable.virginmedia.com)
# [11:08] * Joins: Phae (n=phaeness@gateb.mh.bbc.co.uk)
# [11:12] * Quits: MikeSmith (n=MikeSmit@EM114-48-12-154.pool.e-mobile.ne.jp) (Read error: 113 (No route to host))
# [11:14] * Quits: nessy (n=Adium@121.90.86.174) (Read error: 110 (Connection timed out))
# [11:16] * Joins: MikeSmith (n=MikeSmit@EM114-48-12-154.pool.e-mobile.ne.jp)
# [11:17] * Quits: nessy1 (n=Adium@121.90.249.84) ("Leaving.")
# [11:17] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
# [11:22] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) ("ChatZilla 0.9.86 [Firefox 3.5.7/20100106054634]")
# [11:24] * Joins: zalan (n=zalan@catv-89-135-144-122.catv.broadband.hu)
# [11:35] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
# [11:35] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [11:35] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
# [11:40] * Parts: mikekelly (i=mikek@s3x0r.biz)
# [11:44] * Joins: adactio (n=adactio@host213-123-197-180.in-addr.btopenworld.com)
# [11:54] <payman> gsnedders: ping
# [12:01] <Hixie> MikeSmith: cvs locked again
# [12:01] <MikeSmith> dammit
# [12:02] <MikeSmith> Hixie: working on it now
# [12:02] * Joins: BenMillard (i=cerbera@cpc1-farn4-0-0-cust173.glfd.cable.ntl.com)
# [12:03] <MikeSmith> at least I know now that that it's not my author-view automation that's causing the problem
# [12:04] <MikeSmith> Hixie: how long has it been hanging?
# [12:05] <MikeSmith> systeam tells me the lock has an up-to-this-minute timestamp on it
# [12:05] <MikeSmith> and that the PIDs are changing as we speak
# [12:05] <MikeSmith> so something is running normally
# [12:05] <Hixie> MikeSmith: about 3 minutes
# [12:05] <MikeSmith> I mean it's not a stale lock at least
# [12:06] <Hixie> :-)
# [12:06] <MikeSmith> OK
# [12:06] <MikeSmith> please give it another few minutes
# [12:06] <Hixie> actually 14 minutes so far
# [12:06] <Hixie> but sure
# [12:06] <MikeSmith> oh
# [12:06] <Hixie> not like i have any choice :-P
# [12:07] <Hixie> 10:51 UTC is when i first got a lock message
# [12:07] <Hixie> haven't checked anything into the /spec/ directory since
# [12:07] <Hixie> i should say, i haven't succeeded at checking anything into there since
# [12:07] <Hixie> (i have tried)
# [12:08] <MikeSmith> OK
# [12:08] <Hixie> for the record, this microdata split is dumb
# [12:08] <Hixie> it makes the <link> and <meta> sections silly
# [12:09] <Hixie> and makes all the global stuff - index, lists of attributes, etc - wrong also
# [12:09] <Hixie> and the postmsg thing makes the Window object IDL silly
# [12:09] <Hixie> sigh
# [12:09] <Hixie> i hate these splits
# [12:11] <MikeSmith> Hixie: locks seem to be clearing and then coming back again very quickly
# [12:11] <MikeSmith> something must be looping
# [12:11] <Hixie> well it ain't me, i'm not checking anything in right now
# [12:14] <Hixie> MikeSmith: i just discovered that some of the examples in the spec are invalid HTML4, so I'm having to comment them out of the w3c version of the spec
# [12:16] <MikeSmith> Hixie: I think the answer to that should be that they don't assert that they're valid HTML4
# [12:16] <Hixie> these were examples where there was first the source, then the example literally in the spec so you could see what it looked like
# [12:16] <Hixie> i just removed the second part and left the source
# [12:17] <Hixie> e.g. search for "gross margin table"
# [12:17] <Hixie> that <table> uses the HTML5-suggested "<tfoot>-comes-last" markup style
# [12:18] <Hixie> so i left the markup but hid the actual table
# [12:18] <MikeSmith> ah tfoot
# [12:18] <MikeSmith> I would rather we just got rid of tfoot
# [12:18] <Hixie> there are other examples, like <p> in <caption>, and so on
# [12:18] <MikeSmith> I see
# [12:19] <Hixie> i expect the number will increase as i add examples
# [12:21] <MikeSmith> you could solve this problem most easily by just removing all the examples
# [12:23] <Hixie> :-P
# [12:25] * jgraham prefers invoking the wrath of the gods on whoever thinks that HTML5 shouldn't be writen in HTML5
# [12:25] * jgraham notes that he believes this to be a purely psychological terror
# [12:26] <Hixie> every HTML4 draft was published using HTML4
# [12:27] <webben> It's a good practice for languages that want backwards compatibility to demonstrate that in the spec! :)
# [12:28] <Lachy> Hixie, who has requested that the spec be written in HTML4?
# [12:29] <Hixie> w3c pubteam
# [12:29] <Lachy> wtf? Just tell them no.
# [12:29] <Hixie> hahahahaha
# [12:29] <Hixie> good luck with that
# [12:30] <Hixie> please feel free to be my spokesperson the next time we publish
# [12:30] <Hixie> i'm done arguing with w3c over stupid things like that
# [12:30] <jgraham> You could try "It is reducing the quaility of the spec" although I'm not convinced that argument holds much weight
# [12:30] <Lachy> Just explain that due to the examples in the spec illustrating HTML5, the spec itself cannot be valid HTML4
# [12:31] <Hixie> i've tried every argument under the sun already
# [12:31] <Hixie> it's no longer my concern
# [12:31] * Lachy suggests splitting out the examples into their own spec.
# [12:31] * Lachy runs
# [12:32] <jgraham> Lachy: Don't someone will probably take you seriously
# [12:32] <Hixie> the canonical version of the spec is on the whatwg.org site, the w3c can take as long as they like to get over their problems and get with the programme
# [12:32] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
# [12:33] * Dashiva waves to MLW
# [12:34] <Philip`> Is he still going?
# [12:34] <Dashiva> I'll bet you a <details> Hixie's latest line will be on it
# [12:38] <jgraham> It seems (s)he is. I'd forgoten all about it to be honest
# [12:40] <Hixie> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8628 - are we sure that the term "boolean attribute" is the cause of this?
# [12:40] <Hixie> i've seen people use =false long before html5 came along.
# [12:40] <Hixie> "flag attribute" is kinda hokey
# [12:40] <hsivonen> Hixie: =false seems to show up with new HTML5 attributes
# [12:41] <hsivonen> Hixie: I don't remember seeing <input checked=false> too often, but I don't have scientific data
# [12:41] <Hixie> yeah, but that's just because authors have a hard time understanding the whole concept of boolean attributes, not because they're called that
# [12:41] <Hixie> and because the new attributes are often used without testing
# [12:42] <Hixie> changing a term that is used that often in the spec is very disruptive and usually results in all kinds of mistakes that takes weeks to fix
# [12:42] <Hixie> so unless we have a really really good replacement term, i'm skeptical
# [12:42] * Quits: Kuruma (n=Kuruma@p22091-ipngn1401marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
# [12:43] <webben> Hixie: I agree the attributes are confusing no matter what; I think "boolean attributes" is perhaps more confusing than "flag attributes" because people see "boolean" and think they know what that means.
# [12:44] <Hixie> i'm not buying the asserted causality chain here
# [12:44] <Hixie> and "flag attributes" is just terrible as a term
# [12:44] <Philip`> Do normal people actually know what "boolean" means?
# [12:44] <Hixie> (also i use the term "flag" all over the place)
# [12:44] <Philip`> (i.e. people who aren't programmers or mathematicians)
# [12:45] <Hixie> Philip`: yeah that's one reason i don't really buy it
# [12:45] <hsivonen> enough people who write HTML by hand know enough about programming to know what a boolean is
# [12:46] <webben> hsivonen: Exactly.
# [12:46] <jgraham> I don't really like flag attributes
# [12:46] <jgraham> It makes me think of the things that wave in the wind
# [12:46] <jgraham> (but I also don't like boolean attributes because it does seem confusing)
# [12:47] <Philip`> Call it a there-or-not attribute
# [12:47] <webben> I think "boolean" confuses anybody with any experience of programming, on top of the attributes being confusing to everyone to begin with.
# [12:47] * gsnedders finds the spec looks nothing like what he remembered
# [12:47] <gsnedders> Hixie: I guess you really want xdoc xref soon
# [12:48] <Philip`> I thought he really wanted it years ago
# [12:48] <gsnedders> Well, yeah
# [12:48] <Hixie> gsnedders: websockets is blocked on not having cross-doc xrefs
# [12:48] <Hixie> (microsoft want them before we publish any further)
# [12:48] <gsnedders> Hixie: I expect there will be something usable by the end of the month.
# [12:48] <Hixie> sweeeeeeet
# [12:48] <Hixie> how does it work?
# [12:49] <Hixie> what input do i give it?
# [12:49] <gsnedders> Basically the same as you give PMS now. I don't know how jgraham will want to deal with being given loads of files all at once, though.
# [12:49] <Lachy> Hixie, why does the W3C multi-page spec still contain microdata? http://dev.w3.org/html5/spec/#auto-toc-5
# [12:49] <Hixie> gsnedders: how do you work out what the URLs should be then?
# [12:49] <Hixie> Lachy: mike stopped regenning it i think, not sure
# [12:50] <Lachy> ok
# [12:50] <gsnedders> Hixie: Oh, and it's quicker to generate all the WHATWG specs (excluding complete) than generating the "HTML" document alone with Anolis 1.
# [12:50] <gsnedders> Hixie: You tell it the URLs.
# [12:50] <Dashiva> "Valueless attributes"
# [12:51] <MikeSmith> Lachy, Hixie - I turned of the script that generates the multi-page version
# [12:51] <Hixie> gsnedders: currently i only regen the changed ones
# [12:51] <MikeSmith> the full version should be up to date
# [12:51] <MikeSmith> one-page version
# [12:51] <gsnedders> http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?content-type=text/html still contains everything?
# [12:51] <Hixie> no
# [12:51] <Lachy> dammit, you're right about the microdata split making the spec silly. Section 6.1 Content models in the separate Microdata spec makes it more difficult to know the conformance requirements for the elements it changes :-(
# [12:52] <gsnedders> Hixie: You could get it to do that, but that will get complex when multiple files change and you need to get the right set of files.
# [12:52] <Hixie> gsnedders: going forward are you saying i should just group the specs into the w3c ones, the whatwg ones, and complete, and have the cross-references work? i'm confused.
# [12:53] <gsnedders> There are two ways to deal with xref: either you pass all the source files at once, or you pass some of them and URLs for other files to load xref from.
# [12:53] <gsnedders> (but in that case it can't add ids to the,)
# [12:53] <gsnedders> *them
# [12:53] <Hixie> hm so basically i could just generate each one, upload them, then generate them all again, upload that, and keep repeating until it converges? :-)
# [12:53] <Dashiva> Sounds like bibtex
# [12:54] <gsnedders> You _could_.
# [12:54] <Philip`> Is it guaranteed to converge?
# [12:55] <gsnedders> I can't think of any way in which it wouldn't.
# [12:55] <Hixie> gsnedders: can i give it a URL to load references from but give it a _different_ URL to actually use in the spec it outputs?
# [12:55] <gsnedders> No
# [12:55] <Hixie> gsnedders: because then i wouldn't have to upload the drafts to the w3c
# [12:55] <Dashiva> With all the talk of modularization and monoliths, this sounds like it would be a lot easier if the spec splitter was integrated with the cross referencer
# [12:56] <Hixie> to do the converging
# [12:56] <gsnedders> Hixie: Wouldn't it be easier to just generate all the W3C specs at once, with some magic to deal with not regenning unchanged documents?
# [12:57] <Hixie> Dashiva: and we could merge that with the html-to-ietf-draft convertor, too! :-)
# [12:57] <Philip`> Seems like a similar problem to the linker for compiled programming languages, where you want to process a lot of source files individually and then fix up all the crossreferences later
# [12:57] <Hixie> Philip`: it's actually the opposite, since i start with one source file :-)
# [12:58] <Philip`> except in this case the linker (Anolis) is doing a lot of the compilation too
# [12:58] <Hixie> gsnedders: there are ten w3c drafts right now
# [12:59] <Hixie> gsnedders: it sounds like i can deal with what you're describing
# [12:59] <Dashiva> Hixie: Did you see adactio's comments about /html5 and /specs/ earlier?
# [12:59] <Hixie> Dashiva: no? where? here?
# [12:59] <Dashiva> Yeah
# [12:59] <Dashiva> Basically, /html5 no longer links to HTML5 (rather WHATWG HTML) and /specs/ is woefully incomplete and out of date
# [13:00] * Joins: aroben (n=aroben@unaffiliated/aroben)
# [13:00] * Philip` wouldn't want /html5 to redirect to HTML5, since all the links he's posted to /html5#foo would suddenly change to the single-page version that crashes people's browsers
# [13:00] <Hixie> i updated /specs/ recently
# [13:00] <Hixie> is it better now?
# [13:00] <MikeSmith> Hixie: I will let you know as soon as i get clue about the lockng problem
# [13:00] * Quits: MikeSmith (n=MikeSmit@EM114-48-12-154.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
# [13:01] <Hixie> /html5 is supposed to redirect to the whatwg html page
# [13:01] <Dashiva> It doesn't look changed to me: http://www.whatwg.org/specs/
# [13:02] <Dashiva> E.g. it doesn't mention WA 1.0
# [13:02] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
# [13:02] * Joins: Utkarsh (n=admin@117.201.87.31)
# [13:02] <Hixie> oh, should it?
# [13:02] <Hixie> i guess it could
# [13:02] <adactio> I think it's pretty ridiculous that the URL /html5 doesn't redirect to the HTML5 spec. Use /html to direct to HTML and /html5 to redirect to HTML5. I think it's pretty devious that all the links out there pointing to /html5 no longer point to the HTML5 spec.
# [13:03] <Hixie> it is the HTML5 spec
# [13:03] <Hixie> well, it's really the HTML6 spec
# [13:03] <Hixie> or whatever you want to call it
# [13:03] <Hixie> it's the spec that matters, anyway
# [13:03] <hsivonen> Hixie: not having "HTML5" as the name of "the spec that matters" is a problem
# [13:03] <Hixie> that's why it says "including html5"
# [13:04] <Dashiva> Hixie: I don't have a strong opinion, but the page should at least be as informative as the FAQ entry.
# [13:04] <hsivonen> (as far as communicating with people who don't follow #whatwg goes)
# [13:04] <Hixie> Dashiva: well i don't want to have that information there twice... i guess i can just point to the FAQ entry?
# [13:04] <Dashiva> hsivonen: Having HTML5 as the name would make people even angrier
# [13:06] <adactio> Well, I'll just start pointing people to the W3C URLs because they seem to more trustworthy i.e. they aren't likely to suddenly change from one day to the next.
# [13:06] * Philip` isn't convinced the process problems can be solved simply by selecting good names
# [13:06] * hsivonen tries to understand how the different i5 or i7-branded CPUs might compare for compiling Firefox
# [13:06] <Hixie> adactio: i'm not really sure i understand what it is that is changing in the whatwg one
# [13:06] <Dashiva> How about calling it HTML.next instead of WHATWG HTML :)
# [13:06] <Hixie> adactio: the w3c one is changing all the time -- e.g. they just took out microdata and the 2d context for no good reason
# [13:07] <hsivonen> Hixie: in fairness, you took out the 2d context
# [13:07] <adactio> Hixie: but at least the URL for HTML5 still points to a specification for HTML5.
# [13:07] <hsivonen> Hixie: there was no chair decision for that
# [13:07] <Dashiva> Not like it wasn't obvious what the chair decision would have been
# [13:07] <Hixie> adactio: what do you call "html5"?
# [13:08] <Hixie> hsivonen: there's nobody in the htmlwg asking for it to be kept in the spec except me and a handful of #whatwg regulars, as far as i can tell.
# [13:08] <adactio> Hixie: the part of WHAT WG HTML in parentheses "(including HTML5)"
# [13:08] <hsivonen> Hixie: OK
# [13:09] <Hixie> adactio: so you think everything in the HTML spec on the WHATWG site except the <device> element is HTML5?
# [13:09] <adactio> Hixie: Anybody coming to /html5 expecting to see a spec called HTML5 and instead discovering a spec called "HTML (including HTML5)" will want to know "Well, which bit is HTML5 because that's what I'm interested in"
# [13:09] * hsivonen thinks adactio is right
# [13:09] <adactio> Hixie: the point is: *I don't know* anymore what HTML5 is.
# [13:09] <Hixie> adactio: why would anyone care about HTML5, as opposed to what the latest HTML spec is? HTML5 is the last generation now.
# [13:10] <hsivonen> Hixie: because HTML5 has all the hype
# [13:10] <adactio> Hixie: because people like me are out there tell front end developers/designers: "you should really check out HTML5—it's got great stuff". They then go looking for something called HTML5.
# [13:11] <Hixie> well i can't call the whatwg spec "html5" without making the even more confusing step of having the specs describe the term "html5" as being different sets of technology.
# [13:11] <gsnedders> Hixie: Because people want to claim to support "HTML5", because it is hard to support something that has changed in the time from layout-engine freeze to shipping
# [13:11] <adactio> Hixie: now, should I instead be evangelising "HTML (including HTML5) because that's going to get very tiring to say/write/
# [13:11] <Hixie> adactio: i would evangelise individual features, not buzzwords
# [13:12] <adactio> Hixie: then, as I said, the safest thing for me to do is to point to W3C urls rather than WHATWG urls.
# [13:12] <Hixie> adactio: why is that safer?
# [13:12] <hsivonen> Hixie: I suggest making /html5/ and /current-work/ point to something that corresponds to "HTML5"
# [13:12] <hsivonen> or at least /html5/
# [13:12] <adactio> What hsivonen said.
# [13:12] <Hixie> i don't understand why we would want to hide <device> from people
# [13:12] <Hixie> or is that not what you're asking for
# [13:13] <Hixie> i don't really understand what you're asking for
# [13:13] <Lachy> adactio, it doesn't matter. The whole point of it is to try and move away from versioned specs. The features that people can use depends solely on what is supported in implementations, not whether something happened to make the feature freeze cut off in the W3C process.
# [13:13] <Philip`> Maybe "HTML (including HTML5)" should be deleted, and "HTML5" considered the 'main' HTML spec for now (and the same between W3C and WHATWG), and the new features split into separate specs (the "Devices for HTML" spec etc)
# [13:13] <hsivonen> Hixie: does <device> have implementor buy-in?
# [13:13] <Philip`> since that avoids the confusion of having multiple versions of HTML being promoted simultaneously
# [13:13] <Hixie> hsivonen: it has as much implementor interest at this stage as <video> did when we added that
# [13:13] <adactio> Point /html to the "everything" spec (HTML including HTML5 and Device). Point /html5 to the subset that is HTML5. (as for what's in that subset: I don't know anymore—you tell me)
# [13:14] * Joins: csarven (n=csarven@92.67.90.249)
# [13:14] <Hixie> adactio: do you think what is labeled "html5" should include any or all of .localStorage, web workers, websockets, geolocation, eventsource, or <device>, and if so, which ones?
# [13:14] <csarven> Is readonly implied for <input type="hidden" ?
# [13:15] <Lachy> adactio, other than the backwards W3C process, can you clearly explain why you think the distinction between HTML5 and the additional stuff is important?
# [13:15] <hsivonen> Lachy: "5" is important when "5" has PR value
# [13:15] <Lachy> hsivonen, that's not what I'm asking
# [13:15] <hsivonen> Lachy: for better or worse, we have a number in the buzzword
# [13:16] <Hixie> adactio: also add microdata, the canvas 2d graphics context, and elements like <progress> and <details> to that list, so i can better understand what you think is in html5 and what you think is out
# [13:16] <Lachy> my question is regarding the distinction between the features that are officially in HTML5, and the features that are additional extras.
# [13:17] * Philip` guesses the HTML5 spec should have links to other "HTML5" technologies like geolocation too, to help users
# [13:17] <adactio> Lachy: actually, no, I can't answer that, at least not easily. I just know that it smells bad to overload a spec with everything. I absolutely agree that 5 is a buzzword but it's got to mean something: a subset of "everything including the kitchen sink"
# [13:17] <Dashiva> WHATWG HTML is a subset already, though
# [13:17] <Hixie> "everything including the kitchen sink" is http://www.whatwg.org/specs/web-apps/current-work/complete.html
# [13:17] <Dashiva> It's just a slightly larger subset
# [13:17] <Hixie> (actual kitchen sink in the abstract)
# [13:18] <hsivonen> HTML5-the-buzzword pretty much covers everything that isn't covered by CSS3-the-buzzword...
# [13:18] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/ excludes web storage, web workers, wob sockets, server sent events
# [13:19] <adactio> Look: the current spec (located at /html5) has the title "HTML (including HTML5)". It's completely reasonable for someone to ask "Oh, which part of this spec is HTML5?". As for what that subset is, you tell me!
# [13:19] <Lachy> adactio, so, in other words, your sole reason for this line of argument is purley an instinctive reaction to what you consider to be unexpected?
# [13:19] <adactio> Least surprise.
# [13:19] <Hixie> the w3c html5 spec excludes microdata, <device>, 2d context, postMessage, MessageChannel, web storage, web workers, wob sockets, server sent events
# [13:19] * Quits: flea (n=flea@71.23.116.3) (Read error: 110 (Connection timed out))
# [13:19] <hsivonen> Lachy: adactio's question is perfectly reasonable considering the title
# [13:19] <adactio> Lachy: yeah, right now the principle of least surprise is being violated by having /html5 redirect to a spec called HTML.
# [13:20] <Hixie> adactio: ok, HTML5 is everything in the spec labeled "WHATWG HTML (including HTML5)", we just can't call it that because the w3c would lynch me.
# [13:20] * Joins: flea (n=flea@71.23.116.3)
# [13:21] <hsivonen> "SVG is part of the HTML 5 family of technologies."
# [13:21] <adactio> Hixie: so you know it really should just be called HTML5 ...but that would cause political problems.
# [13:21] <Hixie> csarven: (no, it just doesn't apply because you can't edit it, it's not interactive)
# [13:21] <Hixie> adactio: yes
# [13:21] <Hixie> adactio: well, it really should just be called HTML, and we should move away from versioning
# [13:21] <Hixie> adactio: but it can be called HTML5 for now if that buzzword hasn't had its day yet
# [13:22] <Hixie> adactio: except it can't, because then the w3c and the whatwg would be disagreeing about what is in "html5"
# [13:22] <Hixie> adactio: and that would be even worse
# [13:22] <adactio> Hixie: I'm in favour of *not* confusing authors/developers even if it's at the expense of political harmony between organisations.
# [13:22] <Hixie> you wouldn't have to bear the brunt of the disharmony
# [13:22] <Dashiva> adactio: But it would confuse authors in a different way, since they'd see two HTML5 with different contents in the media
# [13:22] <Lachy> call it HTML5++
# [13:23] <Lachy> or HTML++
# [13:23] <adactio> Hixie: then it sounds like I definitely should be pointing to W3C urls as being canonical.
# [13:23] * Philip` wonders where political harmony comes in the priority of constituencies
# [13:23] <Hixie> adactio: the W3C URLs are missing microdata, <device>, 2d context, postMessage, MessageChannel, web storage, web workers, wob sockets, and server sent events, is that what you want?
# [13:23] <Dashiva> Philip`: The bureaucracy is always highest priority
# [13:23] <Philip`> Wob sockets sound fun
# [13:23] <adactio> Hixie: I *think* so, yes.
# [13:24] <Hixie> (assuming by "the W3C URLs" you mean http://dev.w3.org/html5/spec/Overview.html)
# [13:24] <Hixie> adactio: then go ahead :-)
# [13:24] <Hixie> adactio: personally i think that's a pretty feeble "html5" :-)
# [13:24] * Quits: workmad3 (n=workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote closed the connection)
# [13:24] <adactio> We need some kind of name for the subset of HTML (i.e. HTML not including device, web storage, etc.). For historical reasons, the word HTML5 seems to be the best label for that subset.
# [13:25] <Hixie> there are two subsets
# [13:25] <Hixie> there's the subset that is only missing web storage, web workers, web sockets, and server sent events
# [13:25] <Hixie> that's what i would call "HTML"
# [13:25] <Hixie> then there's a further subset that's also missing microdata, <device>, 2d context, postMessage, and MessageChannel
# [13:25] <Hixie> which the w3c currently calls "HTML5"
# [13:26] <Hixie> but then a few weeks ago they had all but <device> in there and they called _that_ HTML5
# [13:26] <Dashiva> We have always been at war with Eurasia
# [13:27] <Lachy> adactio, this table illustrates what's included in each version of the spec http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F
# [13:27] <adactio> So it sounds like you need a new term to describe HTML5+device+microdata. Overloading the existing terms (HTML and HTML5) is not going to clarify anything.
# [13:27] <Hixie> adactio: personally i'm interested more in making the web better than in making best use of buzzwords, so having <device> in HTML (and in the spec that I want people to review) is more important than calling it HTML5 to me
# [13:28] <Lachy> IMHO, the complete Web Applications 1.0 spec is all that you should be concerned about. The rest is just a result of buraucracy
# [13:28] <Hixie> adactio: microdata is part of HTML, whatever number it has on the end of it
# [13:28] <Philip`> The web won't be made better if users don't understand what features exist and can't find where they're documented
# [13:28] <Philip`> so the naming seems like an integral part of the betterment
# [13:28] <adactio> Hixie: but clarity is important in getting authors to adopt this technology (and according to the priority of constituencies, they are important).
# [13:29] <adactio> What Philp said.
# [13:29] <Hixie> adactio: authors have been adopting thus stuff far faster than i'd like, so far
# [13:29] <Hixie> adactio: it's actually caused problems already
# [13:29] <Hixie> so i don't think that's a problem currently
# [13:30] <Dashiva> adactio: What if /html5 pointed to a copy that had only half of HTML5. Would that be okay?
# [13:30] <adactio> Hixie: well, if the Orwellian naming conventions are an attempt to stop authors using this stuff, I think it will succeed.
# [13:30] <Dashiva> Authors don't read specs, they read diveintohtml5
# [13:30] <adactio> Dashiva: I don't even know what you mean when you say HTML5 ...which is really at the heart of the problem.
# [13:30] <Hixie> Orwellian? the names are intended to be accurate.
# [13:30] <Dashiva> I don't think we can stop them from using things unless we get rid of markp :P
# [13:30] <Hixie> let's not start exaggerating here.
# [13:30] <adactio> Hixie: I apologise.
# [13:31] <adactio> Hixie: but there's a certain "moving of the goalposts" feel going on.
# [13:31] <Dashiva> adactio: The heart of the problem, yes. Because at the w3c, what is HTML5 changes from day to day
# [13:31] <Philip`> Dashiva: What'll happen if he wants to cover <device> in that book?
# [13:31] <Dashiva> If enough people dislike it, suddenly a feature doesn't exist anymore
# [13:31] <Hixie> adactio: well yeah, it's been 6 years since we've been working on HTML5, we _are_ moving the goalposts. Last year we got to Last Call on what is HTML "5", and now we're moving towards a versionless development model.
# [13:32] <Philip`> You can't sell a book called "Dive into HTML" because nobody will realise it's new and not ten years old
# [13:32] <Hixie> Philip`: you just call it the 2010 edition
# [13:32] <Dashiva> Release four pamphlets called "Dive into HTML 1-4" and then go for "Dive into HTML 5"
# [13:32] <Hixie> hah
# [13:33] <adactio> Hixie: I appreciate that and I have no problem with it (I think it's a good move). But you must see that having a url with "5" in it (/html5) pointing to the ongoing versionless spec isn't helpful.
# [13:33] <csarven> Sure, "Dive into HTMl 5 Last call" sounds great
# [13:33] <Philip`> I'd imagine some people are still writing/updating books in 2010 that only cover HTML4/XHTML1
# [13:33] <Philip`> so that doesn't help a reader know what technologies are covered in it
# [13:33] <Hixie> adactio: i can't see what else we would point to
# [13:33] <Lachy> Hixie, what would it take for you to reintegrate 2dcontext, postMessage and MessageChannel back into HTML5, given that they weren't taken out by a formal group decision anyway, so we can at least partially reduce the differences between WHATWG HTML and HTML5?
# [13:33] <Dashiva> Lachy: Get a WG decision on it
# [13:34] <Philip`> (and they'll only judge the book by its front cover, not by the bit on the back that lists all the features it talks about)
# [13:34] <adactio> "Dive into what's known as 'HTML (including HTML5)' at the WHAT WG and HTML5 at the W3C" — catchy!
# [13:34] <Hixie> Lachy: object to the bugs where i did that and raise an issue
# [13:34] <Hixie> Lachy: but i doubt they would pass, that's why i made the changes
# [13:34] <Hixie> Lachy: the reasons that were applied to microdata apply equally to those
# [13:34] <Hixie> adactio: it only has "(including HTML5)" in the name to address the concen you raised of people wondering if this was the right spec
# [13:35] <Hixie> adactio: maybe the answer is to not bothe including that parenthetical
# [13:35] <Lachy> the reasons that applied to microdata were bogus anyway
# [13:35] <Dashiva> That doesn't really matter as long as the system considers it valid
# [13:35] <Hixie> Lachy: doesn't matter if they're bogus or not, apparently
# [13:36] <Lachy> the real reason people wanted microdata out was just becaue some people would prefer that we didn't work on it at all, as clearly illustrated by the FPWD objections and calls to move it to a new mailing list
# [13:36] * Quits: paul_irish (n=paul_iri@32.136.34.65) (Read error: 54 (Connection reset by peer))
# [13:36] <Hixie> Lachy: obviously
# [13:37] <Dashiva> If you ask me, we might as well get WG decisions on all these sections sooner rather than later
# [13:37] <Dashiva> Might be able to free up some bandwidth on public-html
# [13:37] <adactio> I'm seeing the start of a disturbing precedent here. When anyone* files a bug about any feature of HTML5 (the W3C spec), it gets removed from that spec but remains in the WHAT WG spec. At that point, what's the point of having mailing lists or any attempt at discussion. (*usually Shelley)
# [13:37] <Hixie> i guess if we get the chairs to decide on lots of splits, the w3c spec will be such a mess that adactio won't want to point to it anymore, and he'll go back to pointing to the whatwg one :-)
# [13:38] <Dashiva> Well, they might decide in a dozen different ways
# [13:38] <Dashiva> But as long as the decisions are made, that's one thing less to waste time on
# [13:39] <Hixie> adactio: the whatwg mailing list is still a useful way of getting input from a broad range of people and a useful way of contributing to the spec.
# [13:39] <Hixie> adactio: can't speak about the w3c lists, but then i've mostly given up on them at this point.
# [13:39] <Dashiva> Oh look, MLW is at it
# [13:39] <Dashiva> Darn, old content
# [13:40] <adactio> I'm perfectly fine with the spec called HTML5 (as hosted by the W3C) being a subset of the spec called HTML (as hosted by the WHAT WG) but two is plenty: let's try not to splinter it any further than that.
# [13:40] <Hixie> it's already splintered further than that at the w3c
# [13:40] <Hixie> the htmlwg already has four specs
# [13:41] <Dashiva> Does that include RDFa?
# [13:41] <Hixie> html5, microdata, 2dcontext, and postMessage/MessageChannel
# [13:41] <Hixie> rdfa is going into its own group
# [13:41] <csarven> So, I have a question; when authors, developers want to look up the spec for how x supposed to work, where do you think they will head to? HTML(WHATWG) or HTML5(W3C) ?
# [13:41] <Dashiva> ... then why did we publish a FPWD in the first place?
# [13:42] <Hixie> csarven: probably whichever google takes them to for their query
# [13:42] <csarven> This is going to be a mess
# [13:42] <Hixie> it's already a mess
# [13:42] <Dashiva> csarven: They probably won't go to a spec at all
# [13:43] <Hixie> csarven: if they've tried using both before, they'll probably end up reusing the whatwg one, since it's got more of the content in one place
# [13:43] <Hixie> rather than being split into four pieces
# [13:46] <Hixie> adactio: how about if i rename the WHATWG HTML spec to "HTML5 (including next generation additions still in development)" or something?
# [13:47] <adactio> Hixie: I think that would make life much, much better for curious authors/developers/designers looking to find out more about this thing they keep hearing about. Yes!
# [13:47] <Dashiva> HTML5++ doesn't seem so bad in comparison
# [13:47] <hsivonen> Dashiva: C++ is horrible compared to C
# [13:47] <adactio> Hixie: Although I appreciate that this is just postponing the issue of moving to a numberless nomenclature.
# [13:48] <Dashiva> hsivonen: But compared to C (including next generation additions still in development)?
# [13:49] <Lachy> Hixie, it might be useful to clearly enumerate the additional sections included in HTML5++. The abstract currently only mentions the device element, and probably wouldn't hurt to list 2d context, postMessage and MessageChannel.
# [13:50] <Hixie> oh i guess yeah, i should list that those things are included
# [13:50] <Hixie> i didn't think of that
# [13:50] <Dashiva> And it might useful to mention which were at some point in HTML5, and which were never
# [13:50] <Lachy> Or maybe mark the headdings of those sections in some way, or at least their TOC entires, in some way that makes it obvious that they're added extras
# [13:50] <adactio> Hixie: I definitely think it would be clearer to label the spec "HTML5 (plus x, y, z)" rather than "HTML (including HTML5)".
# [13:51] <Hixie> ok, let me poke around and see what i can do
# [13:51] * jgraham thinks he agrees with adactio's original position i.e. the whatwg should call HTML5 the set of things that htmlwg is working on currently and "HTML" the mainline of HTML development
# [13:51] <adactio> Hixie: Thank you. Much appreciated.
# [13:52] * Joins: Huvet (n=Emil@c-0acfe555.07-131-73746f39.cust.bredbandsbolaget.se)
# [13:55] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
# [13:56] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
# [13:56] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
# [13:57] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [13:57] <hsivonen> hmm. I wonder if I care enough about "boolean attributes" to escalate the bug to the Decision Process
# [13:58] <Hixie> if you care that much, reopen the bug with a better name
# [13:58] <Hixie> i did kind of like the earlier suggestion of "valueless attribute"
# [13:58] <csarven> Isn't the value implied?
# [13:59] <hsivonen> "valueless" isn't technically correct
# [13:59] <hsivonen> "presence attributes" would be
# [13:59] <Hixie> the name is indeed not technically correct
# [13:59] <Hixie> i considered "presence attribute" but nobody would understand that
# [13:59] <hsivonen> but "presence attributes" is weirder than "flag attributes"
# [13:59] <Hixie> "valueless" has the advantage of discouraging people from giving values
# [14:00] <csarven> (just playing here) Was 'null attributes' mentioned? Not that great but..
# [14:02] <Dashiva> It has a value, but the content of the value has no importance
# [14:02] <csarven> How strict should validation be? What if it said, if this attribute has a value, UAs can ignore it
# [14:03] <csarven> s/can/should
# [14:04] <Philip`> Seems weird to say <input checked="checked"> is a valid valueless attribute
# [14:06] <Huvet> I think the trickiest problem here is to explain why autobuffer="false" means that the element _will_ autobuffer... it's hard to explain without going balobas with technical terms
# [14:07] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [14:09] <jgraham> We could call them Descartes attributes on the basis that if they exist they are
# [14:09] <Huvet> :)
# [14:10] * Joins: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net)
# [14:11] <Philip`> What terms do existing books and tutorials etc use to refer to those attributes?
# [14:11] <Huvet> I think I like to call them valueless still... it could be argued that checked="checked" is just a longer form of "checked"
# [14:12] <Philip`> It's a form of "checked" which has a value
# [14:12] * Joins: paul_iri_ (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net)
# [14:12] <Philip`> so it's clearly not valueless :-p
# [14:12] <hsivonen> it's still a flag, though
# [14:12] <Philip`> Also "valueless attribute" sounds like "pointless worthless attribute" to me
# [14:13] <Hixie> oh that's a good term too
# [14:14] * Hixie ducks
# [14:15] <Hixie> adactio: http://www.whatwg.org/specs/web-apps/current-work/#is-this-html5?
# [14:15] <Hixie> adactio: does that work?
# [14:15] <Huvet> <attribute>checked</attribute>=<value>"checked"</value> <- valueless makes sense! :)
# [14:16] <Dashiva> "set attribute"
# [14:16] <Dashiva> As oppose to map attribute :D
# [14:16] <Dashiva> +d
# [14:16] <Philip`> Hixie: "only even been" - should be "ever"?
# [14:16] <Hixie> fixed thanks
# [14:18] <Philip`> "Features that are part of HTML5 (and this specification) but that have been published as separate specifications in the past (or indeed currently, at the W3C):" - why doesn't that list include e.g. Web Forms 2, which was published separately in the past?
# [14:18] <Hixie> i just changed that sentence to the present tense
# [14:18] <Hixie> but i guess i should list wf2, yeah
# [14:19] <Lachy> Hixie, why is the content of /current-work/ different from /current-work/multipage/ now?
# [14:19] <Hixie> /multipage/ only updates when i check in the cahnges
# [14:19] <Lachy> ah, ok
# [14:21] <Hixie> adactio, Philip`: ok, regenned with the changes
# [14:24] * Hixie checks in the changes
# [14:24] <Hixie> ok it's nearly 5:30am, long past anything I should consider my bed time
# [14:25] <gsnedders> But you do consider it your bed time anywa.
# [14:27] <Philip`> It's only a "should", he's allowed to violate it
# [14:27] <jgraham> Does this coult as a good justification?
# [14:27] <jgraham> *count
# [14:27] * Quits: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) (Read error: 110 (Connection timed out))
# [14:35] <Hixie> nn
# [14:35] <webben> night Hixie
# [14:38] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
# [14:41] <Lachy> othermaciej, since you were the one who convinced me that we should try adding queryScopedSelector, do you have anything to add to the current discussion about whether or not we should keep it?
# [14:41] <othermaciej> Lachy: I'm slogging my way through public-html right now - will look at that thread next
# [14:42] <Lachy> JohnResig, I'd also like to hear from you on the issue, if you've got time, and I'm still interested to hear the alternative proposals you once told me you had.
# [14:42] <Lachy> othermaciej, ok.
# [14:45] <TabAtkins> What list is this discussion on?
# [14:45] <gsnedders> I'd guess webapps
# [14:46] <Lachy> yeah, public-webapps
# [14:47] <Lachy> see the recent selectors api 2 thread
# [14:47] <TabAtkins> Subscribed and checking archives now.
# [14:48] <Lachy> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/thread.html#msg62
# [14:52] * Quits: pesla (n=retep@procurios.xs4all.nl) (Read error: 54 (Connection reset by peer))
# [14:58] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
# [15:02] * Joins: mat_t (n=mattomas@91.189.88.12)
# [15:05] * Joins: pesla (n=retep@procurios.xs4all.nl)
# [15:06] <othermaciej> TabAtkins: are you going to have time to write a counter-proposal for the dt/dd issue?
# [15:06] <TabAtkins> Yeah, but I thought Lachy was already writing something up for it. When you need it by?
# [15:06] <othermaciej> if I don't see one by tomorrow, I'll sign up for doing it myself (or just actually write one)
# [15:06] <TabAtkins> Ok.
# [15:07] <othermaciej> the deadline is the 16th IIRC but I don't want to wait until the last minute if I have to do it myself
# [15:07] <othermaciej> Lachy doing it is fine
# [15:07] <othermaciej> just wanna make sure it gets done
# [15:08] * paul_iri_ is now known as paul_irish_
# [15:11] <Lachy> I put it on the whatwg wiki, hoping some others might contribute to the proposals they liked
# [15:11] <Lachy> http://wiki.whatwg.org/wiki/Change_Proposal:_figure_and_details
# [15:12] <Lachy> also, if you guys could review the rationale against dt/dd, that would be useful
# [15:12] <othermaciej> Lachy: ah, sweet
# [15:13] <Lachy> TabAtkins, you might like to do proposal 6, for the <p summary> idea
# [15:13] <TabAtkins> Will do.
# [15:13] <Lachy> othermaciej, I'm guessing you can do fcaption/dlabel
# [15:14] <othermaciej> Lachy: that looks like a good template, very useful
# [15:14] <othermaciej> it seems like all that's needed to turn this into actual Change Proposals is:
# [15:14] <othermaciej> 1) Pick one of the proposals.
# [15:14] <othermaciej> 2) Update the Summary to reflect it accurately.
# [15:15] <othermaciej> 3) Update Rationale to explain why it is better than other proposed changes for this (e.g. why better than <fltcap>, why better than the others here).
# [15:15] <othermaciej> 4) Flesh out proposal details.
# [15:15] <othermaciej> 5) Write Impact.
# [15:15] <othermaciej> 6) Post somewhere in W3C space.
# [15:15] <othermaciej> I will do those steps for fcaption/dlabel
# [15:16] <othermaciej> I would prefer not to be first but in any case I intend to do it by tomorrow night.
# [15:16] <othermaciej> Lachy: would you prefer to be listed as co-author or not?
# [15:16] <Lachy> I figured once we get the proposal details written for a few of them (not necessarily all of them), then we can submit them each as individual change proposals, but they can each share the rationale against dt/dd, and provide their own rationale in favour of the particular proposal
# [15:17] <othermaciej> Lachy: ok, I'll fill in those bits in the wiki first
# [15:22] <adactio> Lachy: I think that's a very good change proposal document but I think it would be better as two documents: one for figure and one for details. I know that these documents would be almost identical in their rationale but crucially, the change proposals would be more specific to the particular element.
# [15:23] <adactio> For example, Proposal 4 is really two different proposals.
# [15:23] <othermaciej> Lachy: I'm not sure I follow the Legacy Cruft point
# [15:24] * Parts: csarven (n=csarven@92.67.90.249)
# [15:24] <othermaciej> Lachy: are you saying that the workaround <div> will persist past its point of usefulness?
# [15:25] <othermaciej> Lachy: on "Default Styles", I assume UA stylesheets will eventually give "figure > dt" and such separate style rules, but I guess it matters for the intermediate period
# [15:25] <othermaciej> Lachy: I can make edits to clarify these points myself if you prefer
# [15:26] * Quits: smaug (n=chatzill@cs181150024.pp.htv.fi) ("ChatZilla 0.9.85 [Firefox 3.7a1pre/20091213211355]")
# [15:26] * Joins: hobertoAtWork4 (n=hobertoa@gw1.mcgraw-hill.com)
# [15:26] * Joins: BlurstOfTimes (n=blurstof@168.203.117.66)
# [15:28] * Joins: pmuellr (n=pmuellr@nat/ibm/x-bmwqedesyveolqum)
# [15:28] * Joins: smaug (n=chatzill@cs181150024.pp.htv.fi)
# [15:29] <Lachy> yeah, that's what I meant about the extra <div>. I wasn't sure if that was a particularly strong argument, but I left it in there anyway
# [15:29] <Lachy> you can go ahead and make whatever changes you like
# [15:31] * Joins: miketaylr (n=miketayl@38.117.156.163)
# [15:32] * Joins: mpt (n=mpt@canonical/mpt)
# [15:33] * Quits: miketaylr (n=miketayl@38.117.156.163) (Remote closed the connection)
# [15:33] * Joins: miketaylr (n=miketayl@38.117.156.163)
# [15:37] * Quits: BenMillard (i=cerbera@cpc1-farn4-0-0-cust173.glfd.cable.ntl.com)
# [15:56] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
# [15:58] * aroben is now known as aroben|afk
# [16:02] <TabAtkins> All right, proposal six is filled in. Lachy, do you need any of the others in particular filled in?
# [16:02] <othermaciej> I think folks should fill in whichever ones they personally believe in
# [16:03] <TabAtkins> Sure, but I believe in a few of them.
# [16:03] <othermaciej> TabAtkins: you filled in a rationale for Proposal 6 relative to other proposals, but I don't see a fleshed out "Proposal Details"
# [16:04] <Lachy> TabAtkins, feel free to fill in details for any that you like
# [16:04] <othermaciej> TabAtkins: i.e. the details of what exactly should change in the spec
# [16:04] <TabAtkins> Ah, indeed.
# [16:04] <othermaciej> TabAtkins: I intend to do #3 and I'll have subsections marked "Summary", "Additional Rationale", "Details" and "Impact"
# [16:05] * Joins: Blue_Hat (n=kamron@0095-42-27-72-DYNAMIC-dsl.cwjamaica.com)
# [16:13] <TabAtkins> k done
# [16:13] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
# [16:15] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [16:18] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 60 (Operation timed out))
# [16:20] * Quits: pablof (n=palbo@pat-tdc.opera.com) (Read error: 60 (Operation timed out))
# [16:20] * Parts: Huvet (n=Emil@c-0acfe555.07-131-73746f39.cust.bredbandsbolaget.se)
# [16:21] * Joins: dbaron (n=dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
# [16:22] * Quits: Utkarsh (n=admin@117.201.87.31) (Read error: 60 (Operation timed out))
# [16:23] * Joins: Utkarsh (n=admin@117.201.86.51)
# [16:24] * Quits: yutak_home (n=kee@N038037.ppp.dion.ne.jp) ("Ex-Chat")
# [16:24] * Quits: mpt (n=mpt@canonical/mpt) (Read error: 113 (No route to host))
# [16:26] * Joins: Lachy_ (n=Lachlan@pat-tdc.opera.com)
# [16:26] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Nick collision from services.)
# [16:26] * Lachy_ is now known as Lachy
# [16:26] * Joins: pablof (n=palbo@pat-tdc.opera.com)
# [16:26] * Quits: paul_irish_ (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) (Read error: 113 (No route to host))
# [16:27] * Joins: mpt (n=mpt@canonical/mpt)
# [16:33] <othermaciej> Lachy: it might be a couple of hours til I can read and comment on the webapps thread
# [16:33] * Joins: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com)
# [16:35] <othermaciej> Lachy: I made a few edits to your Rationale
# [16:35] <othermaciej> Lachy: I'd like to add one more Rationale point if it is ok with you
# [16:35] <othermaciej> specifically, aesthetics
# [16:35] <othermaciej> actually, let me go ahead and add it, and you tell me if you hate it
# [16:37] <Lachy> othermaciej, sure
# [16:38] * Quits: cedricv (n=cedric@112.199.162.33) (Read error: 60 (Operation timed out))
# [16:38] <Lachy> I sort of touched on the aesthetics issues in the Unwanted Elements section
# [16:39] <Lachy> where I said it was unappealing to authors. But it might be worth making it clearer
# [16:39] * Joins: cedricv (n=cedric@112.199.162.33)
# [16:40] <Lachy> TabAtkins, you seem to have omitted any details about how or where the caption attribute is defined and which elements it can be used on
# [16:41] * Quits: Blue_Hat (n=kamron@0095-42-27-72-DYNAMIC-dsl.cwjamaica.com) (Read error: 110 (Connection timed out))
# [16:41] <othermaciej> Lachy: done
# [16:41] <othermaciej> feel free to edit that bit
# [16:41] <TabAtkins> Which elements = all.
# [16:41] <othermaciej> I also added a dt to "Unnecessary Elements"
# [16:42] <othermaciej> TabAtkins: you have to describe the actual spec changes - would it be described next to "id" or next to "hidden" (those are in different sections)? how would the content model of affected elements change? what happens if you use @caption in a disallowed context?
# [16:42] <othermaciej> TabAtkins: look at the level of detail in Shelley's Change Proposal
# [16:42] <TabAtkins> Ah, got it. Adding that now.
# [16:43] <Lachy> othermaciej, the unnecessary elements section was giving an example of where there is no caption.
# [16:43] <TabAtkins> Actually, I'm looking at the level of detail in time's definition of pubdate, since that's pretty much exactly what I want.
# [16:43] <Lachy> maybe the prose could be updated to reflect the addition of dt to the example though
# [16:43] <othermaciej> Lachy: oh, sorry, I'll revert
# [16:43] <othermaciej> I missed that
# [16:45] <Lachy> it doesn't matter. I don't mind if you revert the example, or just change the preceding line introducing it
# [16:45] <othermaciej> I reverted the example
# [16:45] <othermaciej> I thought it was a mistake, I don't have an opinion on which way works better
# [16:46] * Joins: Huvet (n=Emil@c-0acfe555.07-131-73746f39.cust.bredbandsbolaget.se)
# [16:48] <Huvet> I think I found another html5lib bug. I get maximum recursion depth, and when I make a testcase I get this: "<object </body></html>"
# [16:48] <Huvet> someone forgot to close an object starting tag
# [16:48] <Huvet> I'll file a bug
# [16:50] * Quits: gsnedders (n=gsnedder@204.232.194.186) (Read error: 60 (Operation timed out))
# [16:52] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
# [16:53] * Joins: gsnedders (n=gsnedder@204.232.194.186)
# [16:54] <Huvet> http://code.google.com/p/html5lib/issues/detail?id=132
# [16:54] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net) (Client Quit)
# [16:54] * aroben|afk is now known as aroben
# [16:54] <othermaciej> TabAtkins: looking at what you have so far - you still need to describe where and how the caption attribute as a global attribute will be defined, and when it is valid to use
# [16:55] <gsnedders> Huvet: Does the traceback make it look like it's in an infinite loop?
# [16:55] <Huvet> yes, I cut off 500 lines or so in the traceback
# [16:55] <Huvet> "<cut 500+ lines of exceptions> "
# [16:55] <TabAtkins> I've done that now, you may have viewed the page slightly too early.
# [16:55] * Quits: hober (n=ted@unaffiliated/hober) (Read error: 104 (Connection reset by peer))
# [16:56] <gsnedders> Huvet: So it's just the same few over and over again? OK.
# [16:56] <gsnedders> Huvet: There will be some extreme cases where a conforming document could cause a stack depth error, but that wouldn't loop between a few states
# [16:57] <Huvet> this is just line 1279 and line 460, back and forth
# [16:57] <othermaciej> TabAtkins: what about changes to the details element?
# [16:58] <othermaciej> TabAtkins: per your suggestion it seems like caption is valid even on elements that are not in a <figure> or <details>
# [16:58] <othermaciej> is that really your intent?
# [16:58] <TabAtkins> This doesn't affect the <details> element - I don't think it's appropriate there. I'm fine with <dt>/<dd> for <details>, or any of the new-element suggestions.
# [16:58] <TabAtkins> Hrm, no. I worded it wrongly there.
# [16:58] <TabAtkins> Should be invalid, not ignored.
# [16:58] <othermaciej> TabAtkins: then you should update your summary to say your change is to make this change for figure but leave details as-is
# [16:59] <TabAtkins> Ok.
# [16:59] <TabAtkins> Not quite familiar with the spec conventions - does anything else need to be said about an invalid attribute? Is it implied that it should have no effect?
# [17:00] * Quits: remysharp (n=remyshar@cpc3-brig16-2-0-cust389.3-3.cable.virginmedia.com) ("Gotta shoot - "peeyaow"")
# [17:00] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
# [17:00] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
# [17:00] <Huvet> gsnedders: http://pastebin.com/m2ab28d90
# [17:00] <Huvet> that's the full one
# [17:01] <othermaciej> TabAtkins: "invalid" and "no effect" are orthogonal - you'd have to say both if you mean both
# [17:01] <TabAtkins> kk
# [17:01] <othermaciej> the spec normally says "MUST NOT" rather than "invalid" but people will get what you mean
# [17:01] <gsnedders> Right, yeah. Great.
# [17:02] <gsnedders> Huvet: Probably quite easy to fix though
# [17:02] <othermaciej> (e.g. "The caption attribute MUST NOT be applied to elements that are not a child of a figure or details element."
# [17:02] * Joins: _Utkarsh (n=admin@117.201.86.223)
# [17:02] <othermaciej> TabAtkins: is it ok to have more than one child in a figure with @caption on it?
# [17:03] <othermaciej> TabAtkins: is it ok for the caption to be in the middle instead of first or last?
# [17:03] * Quits: Utkarsh (n=admin@117.201.86.51) (Read error: 110 (Connection timed out))
# [17:04] <TabAtkins> "If multiple children of a figure element have the content attribute set, it is invalid on all such elements beyond the first, and has no effect." <-- new text
# [17:04] <othermaciej> (current spec doesn't allow multiple captions or caption in the middle)
# [17:04] <TabAtkins> Yes, you can put the @caption attribute anywhere within the <figure>'s content.
# [17:04] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
# [17:07] * _Utkarsh is now known as Utkarsh
# [17:13] <TabAtkins> I... I think my 404 page just got spammed.
# [17:19] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("Leaving")
# [17:19] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
# [17:20] * Joins: dglazkov (n=dglazkov@nat/google/x-pidtioifcjjjkybb)
# [17:23] * Joins: _Utkarsh (n=admin@117.201.87.144)
# [17:23] <othermaciej> TabAtkins, Lachy: I wrote the Summary and Additional Rationale for Proposal 3
# [17:24] * Quits: Utkarsh (n=admin@117.201.86.223) (Read error: 60 (Operation timed out))
# [17:28] <Lachy> othermaciej, "The body parts of these elements would not have any additional markup." doesn't really make sense.
# [17:28] <othermaciej> Lachy: yeah that is poorly worded
# [17:28] <Lachy> I assume you're not trying to imply that they're empty elements. Maybe you want to say that they can contain phrasing content
# [17:29] <othermaciej> what I mean is that there's no replacement for <dd>, you just put the actual contents right in
# [17:29] <Lachy> oh, right. I totally misunderstood what you were trying to say
# [17:32] <Lachy> othermaciej, wiki links are done using the syntax like this: [http://example.com/ Link Text], rather than <a> elements
# [17:34] <othermaciej> Lachy: I can do that - annoying that both ways work
# [17:34] <Lachy> it doesn't appear to work when I look at the page.
# [17:34] <Lachy> it's showing up literally as: "it seems to refer to <a href="http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8">captions overlayed on top of the image</a> ..."
# [17:37] <Lachy> that's quite a well written rationale.
# [17:37] * Quits: _Utkarsh (n=admin@117.201.87.144)
# [17:37] * Joins: archtech (i=stanv@83.228.56.37)
# [17:39] <othermaciej> all right, hang on
# [17:40] * Joins: Utkarsh (n=admin@117.201.83.42)
# [17:40] <Lachy> TabAtkins, "All HTML elements may have the caption content attribute set" is directly contradicted by "The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."
# [17:40] <TabAtkins> No it's not. All elements may have it set. However, they must be in that particular context.
# [17:41] <Lachy> there are elemnets like <html>, <body>, etc. would never be allowed to have it, cause they can't be children of figure
# [17:41] <TabAtkins> Ah, got you.
# [17:41] <othermaciej> Lachy: addressed both those comments
# [17:42] <Lachy> you probably want to say it can be on any element in the Flow Content category
# [17:42] <TabAtkins> Thanks, I was just about to ask if I should say something about flow content elements.
# [17:42] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
# [17:43] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [17:45] <Lachy> othermaciej, it still doesn't quite read correctly, becuase the subject from the previous sentence is the fcaption and dlabel elements, rather than figure and details. It might be better to say:
# [17:45] <Lachy> "The content portions of the figure and details elements would not have any special markup, it would be nested directly inside them."
# [17:45] <Lachy> hmm, still doesn't quite work
# [17:47] <Lachy> maybe "The content portions of the figure and details elements would not have any specialised markup; any other flow content may be used"
# [17:47] <Lachy> othermaciej, btw, I'm considering raising an objection to the 2d canvas api split. But I haven't had time to review the changes that were made and what impact it has had
# [17:48] <othermaciej> Lachy: it would be within your rights to escalate it then, if you decide to object
# [17:48] <Lachy> I recall there were good arguments against doing so back when the issue was heavily discussed on the list
# [17:48] <Lachy> I will have to look those up later
# [17:50] <Lachy> othermaciej, what would be an acceptable process for getting microdata reinstated? I assume I would have to wait for new information, such as new implementations and evidence of adoption by developers to reopen the issue
# [17:51] <daedb> TabAtkins: If caption can be on any flow content element, wouldn't <figure><img><style scoped caption></style></figure> be valid? That would be kinda weird :)
# [17:51] <othermaciej> Lachy: the Working Group Decision gave specific examples of what kinds of new information might be a sound basis for re-raising the issue
# [17:51] <Lachy> oh, ok. I don't recall seeing anything mentioned about that. I'll take another look
# [17:53] <TabAtkins> daedb: Weird, yes. Worth worrying about? I dunno.
# [17:53] <TabAtkins> I don't know if there is a categorization that captures "every element that you use to present content of some sort".
# [17:58] <daedb> oh, video is flow content... I could have images in figures with video captions :D
# [17:58] <Lachy> TabAtkins, that's a problem with your proposal you will have to sort out
# [17:58] <Lachy> it's one of the reasons I don't particularly like it
# [17:58] <TabAtkins> deadb: Yes, yes you can.
# [17:58] <othermaciej> Lachy: oh man, I'd been ignoring that thread in the hopes that there wasn't anything relevant (re queryScopedSelector)
# [17:58] <jgraham> othermaciej: (fwiw I would object to the canvas api split if it weren't for the WHATWG copy of the spec. However assuming logic is applied consistently there microdata decision sets precedent for everything that is not in HTML4 to be split out of HTML5, so I would be surprised if such an objection were not futile)
# [17:58] <Lachy> since there's no clear, inuitive subset of elements that it makes sense on
# [17:59] <jgraham> s/there/the/
# [17:59] <TabAtkins> Lachy: There is a clear, intuitive subset. That subset just isn't currently labelled in HTML.
# [17:59] <othermaciej> jgraham: I don't think the microdata decision "sets precedent for everything that is not in HTML4 to be split out of HTML5"
# [18:00] <othermaciej> jgraham: I do think there are some valid arguments for splitting the canvas API, and even Hixie has agreed at various points in time that it was good in principle to do so, though he didn't have time
# [18:00] <othermaciej> now, apparently, he has time
# [18:01] <jgraham> othermaciej: If "limited success in the marketplace" is a sufficient reason for splitting, it follows that anything new could be split
# [18:02] * Quits: Utkarsh (n=admin@117.201.83.42) (Read error: 104 (Connection reset by peer))
# [18:02] <jgraham> othermaciej: e.g. I would expect the same argument to hold if someone asked for <video> to be split
# [18:02] * Joins: KevinMarks (n=KevinMar@157.22.22.46)
# [18:02] * Quits: dglazkov (n=dglazkov@nat/google/x-pidtioifcjjjkybb)
# [18:03] <othermaciej> jgraham: the Working Group Decision only said that all of those arguments are effective in combination (in particular with the "don't pick winners" argument) and really only as they apply to the facts of Microdata
# [18:04] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
# [18:04] <othermaciej> jgraham: also, <video> clearly has a lot more traction than Microdata at present - it has multiple client-side implementations and sites (including some prominent sites like daringfireball.net and youtube.com) using it in production or as a future technology demo
# [18:04] <othermaciej> jgraham: do you really sincerely think that <video> and Microdata have equivalent levels of adoption? (let alone of potentially competing alternatives)
# [18:05] <TabAtkins> Heh, <video> definitely has an extremely popular and well-entrenched alternative - Flash embedded video.
# [18:06] <jgraham> othermaciej: If <video> disappeared tommorrow, hardly anyone would notice. Almost no-one is using <video> on a day-to-day basis.
# [18:06] * Joins: Utkarsh (n=admin@117.201.80.131)
# [18:06] <jgraham> (I note in passing that the critria of reusability in other specifications would also apply equally well to <video>)
# [18:06] <jgraham> (perhaps better)
# [18:11] * Joins: hober (n=ted@unaffiliated/hober)
# [18:15] <cardona507> I'm pretty sure that if <video> disappeared tomorrow people would know - there seems to be quite a buzz for <audio> & <video>
# [18:16] <othermaciej> jgraham: people have had whole conferences about how to use <video>
# [18:17] <othermaciej> TabAtkins: I think a proprietary competing technology is not quite the same thing as a competing standard
# [18:17] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
# [18:17] <TabAtkins> A valid critique.
# [18:17] <othermaciej> it arguably *is* the W3C's place to pick a winner between standards-based and proprietary solutions
# [18:17] <cardona507> when I mention HTML5 in html/css class <audio> & <video> often get the most and easiest "wow"
# [18:18] <othermaciej> that being said,
# [18:18] <AryehGregor> Almost no users would notice, web developers would notice.
# [18:18] <AryehGregor> If video died.
# [18:19] <othermaciej> I think the point is moot if no one actually asks for <video> to be removed
# [18:19] <AryehGregor> It's clear that a lot of the opposition to Microdata was because it had a standards-based competitor that some people liked more.
# [18:19] <AryehGregor> That doesn't apply to any (?) other new feature in HTML5.
# [18:19] <AryehGregor> Although, some people also feel really strongly about how big specs should be, too.
# [18:19] * AryehGregor shrugs
# [18:21] * Joins: jgornick (n=Joe@75-149-148-105-Minnesota.hfc.comcastbusiness.net)
# [18:21] * Joins: _Utkarsh (n=admin@117.201.80.83)
# [18:22] <jgraham> If that was the reason for the decision it would have been nice if it was just stated. Then it would be clear that it didn't apply to other things
# [18:23] * Joins: jwalden (n=waldo@71.147.38.186)
# [18:23] * Quits: dbaron (n=dbaron@c-98-234-51-190.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
# [18:24] <AryehGregor> It was mentioned in some fashion, wasn't it?
# [18:24] <foolip> well, at least it was obvious that it was the actual reason to all involved
# [18:24] * Joins: ap (n=ap@17.246.19.5)
# [18:25] <jgraham> AryehGregor: It was mentioend in the discusion but not actually given as the reason
# [18:26] <jgraham> s/the/a/
# [18:29] * Joins: maikmerten (n=maikmert@port-92-201-2-113.dynamic.qsc.de)
# [18:31] * Quits: Phae (n=phaeness@gateb.mh.bbc.co.uk)
# [18:38] * Quits: Utkarsh (n=admin@117.201.80.131) (Read error: 110 (Connection timed out))
# [18:38] * aroben is now known as aroben|lunch
# [18:39] <othermaciej> jgraham: "Many of the objections balance out. But, in some areas, keeping Microdata would draw stronger objections than splitting it. The objections based on maturity, market success, and reusability in other languages are stronger than their respective counterpoints. In light of these other arguments, the objections to picking a winner in this case are stronger than the objections to not doing so. The objections to picking either RDF
# [18:39] <othermaciej> Microdata as a winner were stronger, on the whole, than the objections to letting them compete on an equal footing."
# [18:40] <othermaciej> jgraham: the "pick a winner" argument is clearly stated in the Short Summary and given a lot of prominence both there and in the longer discussion
# [18:42] <Dashiva> But it wasn't picking. RDFa didn't want to be in HTML5 at all.
# [18:43] <Lachy> othermaciej, the problem I have with that statement is that splitting it out does not really let them compete on an equal footing. Instead, it forces the Microdata proponents to adapt to a new way of developing the spec that they're not particularly comfortable with
# [18:43] <othermaciej> Dashiva: you could debate whether the reasoning provided by commentors was valid, but what we're discussing now is whether it "sets precedent for everything that is not in HTML4 to be split out of HTML5, so I would be surprised if such an objection were not futile)"
# [18:43] <othermaciej> which I think is not the case
# [18:44] <jgraham> othermaciej: Fair enough. To me the list of three arguments is the essence of the summary
# [18:44] <Lachy> That would have been my argument against the split, but since I was on holidays at the time the poll was called and didn't really have time, I missed out on contributing
# [18:46] <othermaciej> jgraham: the chairs intended it somewhat the other way around, so apologies if the summary gave the wrong impression
# [18:46] <othermaciej> jgraham: I think if you read the detailed reasoning, I think it is more clear
# [18:47] * Joins: ROBOd2 (n=robod@89.122.216.38)
# [18:47] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
# [18:47] * Quits: ROBOd (n=robod@89.122.216.38) (Read error: 104 (Connection reset by peer))
# [18:48] <othermaciej> anyway, I don't really want to revisit this issue to death (better to move on), but I did want to note that it does not mean every other proposed split or removal is an automatic winner
# [18:48] <jgraham> So given an arbitary part of the spec to which one can apply all three arguments with the same level of conviction as with microdata, it would not necessarilly be split out if someone requested that unless there was another W3C spec in the same space?
# [18:48] <Dashiva> othermaciej: So you're saying that a contentious (if not outright invalid) argument was the real decider
# [18:48] <AryehGregor> It's good you didn't say that, because if you did then someone would have proposed splitting <span> to its own spec.
# [18:49] <othermaciej> Dashiva: really it was the combination of all four facors with the real decider
# [18:49] <AryehGregor> Come on, people, this is politics, let's just drop it and move on to something else, hopefully non-editorial.
# [18:49] <othermaciej> s/with/which was/
# [18:49] <AryehGregor> Although it looks like we still have lots more editorial stuff to argue about.
# [18:49] <Dashiva> AryehGregor: I'm not sure if you've noticed, Shelley has filed close to a dozen new issues already
# [18:49] <Dashiva> This isn't going away any time soon
# [18:50] <AryehGregor> Yes, Shelley is why we still have lots more editorial stuff to argue about.
# [18:50] <othermaciej> jgraham: if someone could show that all the arguments applied equally to some other section, that would likely be precedent for a split
# [18:50] <othermaciej> jgraham: likewise that the balance did not fall the other way on any other arguments
# [18:50] <Dashiva> Besides, doesn't SMIL pretty much fill RDFa's role when it comes to <video> and choosing a winner? :)
# [18:50] <AryehGregor> I think it's become pretty clear that making a WG where any random person from the Internet can trigger lengthy bureaucratic processes over anything they disagree with is a bad idea.
# [18:51] * Joins: daedb_ (n=daed@h11n1fls34o986.telia.com)
# [18:51] <AryehGregor> Normally WGs (including W3C WGs and the WHATWG) are made up of a small number of people, mostly paid by interested organizations, which typically have a direct interest in progressing the spec.
# [18:51] <AryehGregor> And anyone else can comment, but can be ignored out of hand if the actual members disagree.
# [18:51] <othermaciej> if Shelley overuses the process then I expect the Chairs will take some action to keep it from turning into a DOS attack
# [18:51] * AryehGregor can't wait.
# [18:51] <Dashiva> So you're saying she isn't overusing it yet?
# [18:52] <AryehGregor> Dashiva, don't you remember what Hixie said? The chairs can't decide anything except on Tuesdays. :)
# [18:52] <Dashiva> Yeah, yeah
# [18:52] <Dashiva> It's a shame othermaciej has to be the messenger here
# [18:53] <othermaciej> she's got 9 issues open out of the total 35 by my count
# [18:53] <othermaciej> wait, 11
# [18:53] <othermaciej> but ISSUE-76 should be closed
# [18:53] <AryehGregor> Impressive.
# [18:54] <Dashiva> And she opened, what, 7 of them the last two days?
# [18:54] <othermaciej> 10/34 is a somewhat suspiciously high number
# [18:55] <othermaciej> I am looking for two more pieces of information before I decide whether it is a problem:
# [18:55] <AryehGregor> What is it if you count all issues, not just open ones?
# [18:55] <othermaciej> 1) will she end up pursuing all of these as Change Proposals? (doesn't cost the group much time if the issue gets closed without prejudice)
# [18:56] <Dashiva> AryehGregor: Less than 20%, by my estimate
# [18:56] <othermaciej> 2) what proportion of these issues end up being things that anyone but Shelley agrees with? (if any of them really represent the WG view, then it's not a waste of tiem)
# [18:56] <othermaciej> 3) how many other issues will we get out of the recent batch of bug closures?
# [18:56] <othermaciej> we have 4 sitting there with TrackerRequest
# [18:56] <TabAtkins> There are 90-something issues, and most of them came about before Shelly went on her issue-spree, so most of them won't be hers.
# [18:56] <othermaciej> and probably more that people have not looked yet
# [18:57] <othermaciej> I believe there are 98 total and at least 12 are hers
# [18:58] <othermaciej> for example if someone makes a Change Proposal and there is clearly not significant support for it, the chairs can just put forth a CfC to reject it instead of a call for counter-proposals
# [18:59] <othermaciej> not saying we will actually do that in any particular case but people should consider that before filing potentially frivolous issues
# [18:59] <webben> What was the reason every Change Proposal has counter-proposals again?
# [19:00] <webben> Why can't you just have a Change Proposal and solicit objections?
# [19:00] <TabAtkins> Mostly, to group the objections together.
# [19:00] <Dashiva> That's basically what a counter-proposal is
# [19:00] <othermaciej> originally our intent was just to do it for old issues where there is no prior rationale from the editor
# [19:00] <Dashiva> "Proposal: Change nothing. Rational: ..."
# [19:00] <othermaciej> but I think it works better than just collecting objections by email
# [19:00] <Dashiva> *Rationale
# [19:00] <webben> Dashiva: Yeah, but with microdata you had a counter-proposal, a proposal and then a load of objections to both on top.
# [19:00] <othermaciej> what is the right wiki syntax for a bulleted list?
# [19:01] <Dashiva> *
# [19:01] <Dashiva> No empty lines between items
# [19:02] <webben> Dashiva: Since the chairs needed to read all the objections anyway, I don't see the point.
# [19:02] <othermaciej> my problem was leading spaces
# [19:02] <othermaciej> fixt
# [19:03] <othermaciej> webben: reading both Change Proposals plus the poll responses was way less work than reading every single mailing list response would have been
# [19:03] <webben> othermaciej: But was it less work than reading a Change Proposal + poll responses would have been?
# [19:04] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [19:04] <othermaciej> webben: it helped focus the key arguments
# [19:05] <webben> Fair enough.
# [19:05] <othermaciej> webben: we tried to look at the poll responses by how they related to one proposal or the other's rationale
# [19:05] <webben> If it works, it works :)
# [19:08] * Quits: mpt (n=mpt@canonical/mpt) ("Ex-Chat")
# [19:09] * Quits: daedb (n=daed@h11n1fls34o986.telia.com) (Read error: 110 (Connection timed out))
# [19:09] * daedb_ is now known as daedb
# [19:10] * Joins: dbaron (n=dbaron@nat/mozilla/x-pjhoadqmodaqfjai)
# [19:19] * Quits: mat_t (n=mattomas@91.189.88.12) ("This computer has gone to sleep")
# [19:22] * aroben|lunch is now known as aroben
# [19:25] * Quits: KevinMarks (n=KevinMar@157.22.22.46) (Read error: 110 (Connection timed out))
# [19:30] * Joins: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
# [19:41] * Parts: adactio (n=adactio@host213-123-197-180.in-addr.btopenworld.com)
# [19:44] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
# [19:47] * Joins: plainhao (n=plainhao@mail.xbiotica.com)
# [19:50] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 60 (Operation timed out))
# [19:51] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [19:58] * Joins: Phae (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com)
# [19:59] * Joins: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
# [20:00] * Quits: erlehmann (n=erlehman@82.113.121.226) ("Ex-Chat")
# [20:07] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
# [20:09] * Quits: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams) (Client Quit)
# [20:16] * Joins: sbublava (n=stephan@77.117.34.232.wireless.dyn.drei.com)
# [20:19] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
# [20:21] * Quits: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com)
# [20:22] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
# [20:24] * Joins: drhowarddrfine (n=chatzill@71-81-236-221.dhcp.stls.mo.charter.com)
# [20:26] * drhowarddrfine is now known as Doc
# [20:28] * Joins: dglazkov (n=dglazkov@nat/google/x-lyxnynyejiwicisv)
# [20:31] * Joins: Utkarsh (n=admin@117.201.81.116)
# [20:36] * Quits: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) (Read error: 110 (Connection timed out))
# [20:36] * Quits: archtech (i=stanv@83.228.56.37) (Client Quit)
# [20:41] * Quits: _Utkarsh (n=admin@117.201.80.83) (Read error: 110 (Connection timed out))
# [21:04] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
# [21:08] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
# [21:16] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
# [21:32] * Joins: ojan (n=ojan@72.14.229.81)
# [21:33] * Quits: Phae (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com)
# [21:33] * Joins: gratz|home (n=gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
# [21:34] * Quits: plainhao (n=plainhao@mail.xbiotica.com)
# [21:35] * Quits: maikmerten (n=maikmert@port-92-201-2-113.dynamic.qsc.de) (Remote closed the connection)
# [21:39] * Joins: pmuellr_ (n=pmuellr@nat/ibm/x-rsifygploystpkrv)
# [21:41] <cardona507> Firefox 3.6 release candidate out with support for the HTML5 File API - nice
# [21:43] * Quits: pmuellr (n=pmuellr@nat/ibm/x-bmwqedesyveolqum) (Read error: 60 (Operation timed out))
# [21:43] * pmuellr_ is now known as pmuellr
# [21:43] <cardona507> ohhh - it looks like there are all kinds of goodies in Firefox 3.6 :)
# [21:46] <miketaylr> i think <input type=file multiple> as well
# [21:52] * Joins: csarven (n=csarven@ip157-77-212-87.adsl2.static.versatel.nl)
# [21:55] * Quits: pmuellr (n=pmuellr@nat/ibm/x-rsifygploystpkrv)
# [22:00] <AryehGregor> "Heck, even my cat has her own domain name."
# [22:05] * Joins: othermaciej (n=mjs@17.246.17.57)
# [22:07] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
# [22:17] <TabAtkins> Hrm. This is an interesting border-radius bug. Never seen it before.
# [22:18] * Quits: ROBOd2 (n=robod@89.122.216.38) ("http://www.robodesign.ro")
# [22:20] <TabAtkins> Ah, never mind. It's a repainting issue.
# [22:22] * Joins: cpharmston (n=Adium@office.threespot.com)
# [22:24] <othermaciej> I'm so persuaded by my rationale for Proposl 3 that I'm not sure I can bring myself to write any others
# [22:24] <TabAtkins> Haha.
# [22:24] * Joins: Lachy (n=Lachlan@85.196.122.246)
# [22:25] <othermaciej> (the only other one I *might* do at this point is Proposal 4, but I don't know if I will)
# [22:25] <othermaciej> and I still have to write the remaining bits of Proposal 3
# [22:26] <TabAtkins> I have to say that Proposal 4 is my favorite.
# [22:26] <TabAtkins> Dang, I mean 3.
# [22:26] <TabAtkins> Followed by 6, then 2 and 4 equally.
# [22:26] <jgraham> pointer?
# [22:26] <othermaciej> ah, I was gonna say
# [22:26] <othermaciej> jgraham: http://wiki.whatwg.org/wiki/Change_Proposal:_figure_and_details
# [22:27] <Lachy> we should just go ahead and call the spec "HTML Microdata", since we're basically trying to move away from versioning. Leif's seems like hte easiest objection ever to get withdrawn
# [22:27] <othermaciej> TabAtkins: 4 is the hardest to write, because it requires parser changes
# [22:27] <TabAtkins> As opposed to 1?
# [22:27] <othermaciej> the parser changes for 1 are already in the spec
# [22:27] <TabAtkins> Ah, right. Commented out.
# [22:27] <TabAtkins> I don't wanna write 4, then.
# [22:28] <othermaciej> oh really? I thought it still had the parsing change for <legend> still in
# [22:28] <TabAtkins> Eh, maybe. Hopefully so, actually.
# [22:28] <othermaciej> I will consider writing 4 if it seems likely to be anyone's favorite
# [22:28] <othermaciej> but describing changes to the parsing algorithm in detail is not my idea of a fun time
# [22:29] <TabAtkins> And I don't understand the parsing algorithm sufficiently well to write it at all.
# [22:29] <Lachy> I think we should give up on proposal 4. If the caption element could be salvaged in any way, we would have done it when the parsing algorithm was written. I find it highly unlikely that any proposal for it would work in practice
# [22:29] <Lachy> also, we'd be stuck with the legacy for many years to come
# [22:30] <TabAtkins> We should drop 1 in that case as well. It has equivalent problems, it's just easier to write a change proposal for.
# [22:30] <Lachy> yeah, the problems with 1 were the whole reason we got where we are today. I don't think it will go over well with the community
# [22:31] <Lachy> though, IMHO, legend is the second best alternative to introducing a new element
# [22:32] <Lachy> at this stage, now that I've read the rationale behind it, I think 3 sounds the most promising. The names aren't ideal, but they're not overly bad
# [22:32] <jgraham> Did I already mention that I find fcaption and dlabel mysterious names
# [22:32] <TabAtkins> The parallel to the naming of <table>'s sub-elements is nice, at least.
# [22:33] <jgraham> figcaption (like optgroup) would be better for the figure one imho
# [22:33] <TabAtkins> jgraham: Are they any more mysterious than thead, if you discount your existing familiarity?
# [22:34] <jgraham> TabAtkins: It is hard to discount my existing familiarity
# [22:34] <TabAtkins> True. Rationally, then, are they any more mysterious?
# [22:34] <jgraham> But <thead>, <tbody>, etc. are basically never used whereas <figcaption> would be used for every single <figure>
# [22:35] <TabAtkins> <tr> and <td> are used on every table, though.
# [22:35] <TabAtkins> Though their commonality may be sufficient justication by itself for their short names.
# [22:35] <TabAtkins> Simply from a bandwidth pov.
# [22:35] <TabAtkins> (network and finger-based)
# [22:36] <jgraham> But that is OK because both parts are abbreviated and the structure is such that you want short names more than you want readability
# [22:37] <TabAtkins> Is <figcaption> sufficiently better than <figurecaption> to justify the shortening? Is the parallel to <optgroup> strong enough to justify it?
# [22:37] <jgraham> <figcaption> feels a lot shorter and using fig. as an abbreviation of figure is rather common
# [22:37] <TabAtkins> True.
# [22:38] <TabAtkins> Is there any parallel name for <dlable> that feels natural?
# [22:38] <TabAtkins> s/dlable/dlabel/
# [22:39] <jgraham> Maybe <summary> but it is not quite right and doesn't capture the labelness if that is how we expect it to be used
# [22:39] <TabAtkins> Yeah, that sounds odd to me.
# [22:40] <jgraham> (It is not clear to me if people will do things like <details><dlabel>[lots of contnet here]</dlabel>[more content here]</details>
# [22:40] <TabAtkins> The clickability parallel with form labels is nice enough that I want to keep "label" in it.
# [22:40] <jgraham> (The other possible pattern is <details>label<expansion></expansion></details>
# [22:40] <jgraham> )
# [22:41] <TabAtkins> <content>?
# [22:41] <TabAtkins> That makes it too easy to do <details>foo<content>bar</content>baz</details>. Of course, that might still be good...
# [22:41] <jgraham> No, we might want that as a parallel to <header> et. al. one day
# [22:41] <TabAtkins> But I think that most commonly it's the label that will be styled specially, so it's best to make that have the wrapper.
# [22:42] <jgraham> I think it is also common to want the expansion to have a special style e.g. some extra margin
# [22:43] <othermaciej> jgraham: I wouldn't have a problem with tweaking the proposal to <figcaption> or <figurecaption> instead of <fcaption> if that is truly more popular, and if there is a good similar change for <label>
# [22:43] <othermaciej> er, good similar change for <details>
# [22:43] <TabAtkins> jgraham: Agreed, and that's why I'm still honestly fine with <dt>/<dd> for details.
# [22:44] <othermaciej> but I do think names for specialized child elements often have either no prefix or an abbreviated prefix and rarely have a full-word prefix
# [22:44] <jgraham> My feat with <dlabel> is just that; people will write <label> by mistake when they mean <dlabel>
# [22:44] <jgraham> *fear
# [22:44] <othermaciej> well I'd just propose <label> if I thought it would fly :-)
# [22:44] <othermaciej> but the fact that using <label> will result in none of your content showing up should be a good enough signal to limit that error
# [22:44] <TabAtkins> Well, <label> doesn't have parsing problems. You'll just be prevented from embedding form controls in the details label until browsers know to treat it differently.
# [22:45] <daedb> <figurecaption> is too long imo. I'd prefer <fcaption> over <figcaption> for length reasons too, but I could live with both.
# [22:45] <jgraham> Embedding form controls in the details label seems like it is a valid use case though
# [22:46] <TabAtkins> I agree, but it's a less drastic problem than parsing issues.
# [22:46] <othermaciej> in particular you are much less likely to want a form control inside the <details> label than in a figure caption
# [22:47] <othermaciej> the way it is used on Mac OS X, it pretty much never contains controls
# [22:47] <daedb> Really? I expect form controls in <details> to be quite common.
# [22:47] <jgraham> Yes but Web developers on't have to conform with the apple HIG :)
# [22:48] <othermaciej> daedb: in <details>, yes, in the label part, no
# [22:48] <Lachy> the name <content> is out anyway, since it clashes with XBL, and it was already considered and rejected when we were discussing the idea of introducing a content wrapper for section elements
# [22:48] * Joins: Clicky (n=Clicky@rob92-12-78-232-246-115.fbx.proxad.net)
# [22:48] <jgraham> (I can imagine something where you have a list of checkboxes, each of which is a details control that allows you to set more advanced options for that item. Not great UI perhaps but the sort of thing that seems plausible)
# [22:48] <Dashiva> othermaciej: Were you smiling to yourself when you wrote "touch base" in that email? :)
# [22:49] <TabAtkins> Heh, I was just typing up that precisely, jgraham.
# [22:49] <othermaciej> Dashiva: why would I be?
# [22:49] <othermaciej> jgraham: I guess that is plausible
# [22:49] <daedb> othermaciej: oh, I was just thinking in general, not just for the label... oops :)
# [22:50] <othermaciej> so is anyone here a big fan of 1, 2, 4 or 5?
# [22:50] <Dashiva> To me it's too cliche to consider seriously
# [22:50] <TabAtkins> I'm sort of a2 fan, but that's all.
# [22:50] <othermaciej> also, would it be a good thing to mention this wiki page on the HTML WG, in case any other WG participants would like to fill in the details for any of those?
# [22:50] <daedb> I like the shortness of <c> in 2.
# [22:50] <othermaciej> or otherwise share our rationale
# [22:51] <Lachy> <label> was rejected for use within <figure> since it clashes with form control labels. Perhaps the fact that it needs to be first in <details> would be enough to make the distincition.
# [22:51] <TabAtkins> yeah, i think so, othermaciej
# [22:51] <jgraham> othermaciej: No, I would happily throw them all out :)
# [22:52] * Joins: ttepasse (n=ttepas--@dslb-084-060-052-161.pools.arcor-ip.net)
# [22:52] <othermaciej> Lachy: it also seemed to me that using form controls legitimately in the figure caption might be more likely, but I'm not as sure now
# [22:52] <daedb> I like 2 and 3 the most, then 6... don't care about the rest.
# [22:52] <othermaciej> jgraham: do you like the way the spec is now best?
# [22:52] <othermaciej> so far no one seems willing to write the UnChante Proposal for this issue
# [22:52] <Lachy> I think 4 and 5 should be dropped
# [22:52] <jgraham> othermaciej: No, I like 3
# [22:53] <jgraham> But with slightly different names
# [22:53] <jgraham> (I wasn't clear by "all" I meant "all the ones you listed")
# [22:53] <othermaciej> Lachy: would it be ok to post a link to this page on public-html? Maybe someone there will want to champion one of those
# [22:53] <Lachy> My order of prefence for the others is: 2 and 3, followed by 1, followed by 6.
# [22:53] <Lachy> sure, it's a public wiki. Go ahread.
# [22:53] <Lachy> *ahead
# [22:54] <Lachy> othermaciej, what's the "UnChante Proposal"?
# [22:55] <othermaciej> I meant to say UnChange
# [22:55] <Lachy> oh
# [22:55] <othermaciej> i.e. in favor of the status quo
# [22:55] <Lachy> yeah, the status quo can't really be defended
# [22:55] <TabAtkins> I wanna write UnChange for <details>. Leaving it as <dt>/<dd> is still my personal favorite.
# [22:55] <Dashiva> So now HTML Microdata vs HTML5 Microdata is also a matter of picking winners... joy
# [22:56] <TabAtkins> Just because I'll virtually always be styling both the label and the content, and it's the only one with a pair of elements.
# [22:56] <Lachy> in that case, we should split proposal 3 into two. One for figure and one for details
# [22:56] <othermaciej> proposal 3 could have a variant with elements for both the body and contents
# [22:56] <TabAtkins> I'd be happy with that.
# [22:57] <othermaciej> how would you style the body and exclude the label under proposal 3?
# [22:57] <TabAtkins> <figbody> and <dbody>!
# [22:57] <othermaciej> I'm not sure figbody/fbody is as useful as dbody
# [22:57] <jgraham> I was about to say <dhead> and <dbody>. I thought Lachy would like that :)
# [22:57] <Lachy> or, maybe it's not necessary to split 3, if the poll clearly separates the questions for figure and details. (just make it clear that a vote for proposal 3 for one of them doesn't imply a vote for the other too
# [22:58] <TabAtkins> You kidding? I'll often be wanting some padding on my figbody, but not on my figcaption.
# [22:58] * Joins: omz_32 (n=omz@host246.190-227-52.telecom.net.ar)
# [22:58] <daedb> I don't want a <figbody>, it's unnecessary wrapping.
# [22:58] <othermaciej> you could have a rule for details > :not(dlabel) { .. }
# [22:58] <othermaciej> agreed that is a bit mysterious
# [22:58] <Lachy> if you want to style the content, then we don't need a specialised element. Use <div>, possibly with a class
# [22:58] <TabAtkins> Doesn't work with padding, unless you are very careful with your selectors and break up the padding rule.
# [22:58] <daedb> If I want an extra styling hook I'll just throw in a <div> or something.
# [22:59] <TabAtkins> Bah. I just feel bad putting in extra divs.
# [22:59] <othermaciej> Lachy: I am hoping that with some discussion, we might be able to get down to a clear crowd favorite and settle this without a poll
# [22:59] <Lachy> there's no semantic we really need to convey with it
# [22:59] <othermaciej> TabAtkins: oh, I see, you want to style the body as a unit
# [22:59] <Lachy> TabAtkins, btw, I still object to dt/dd for details for the compatibility hacks required for it
# [22:59] <othermaciej> TabAtkins: you *could* always add a div with a unique class
# [23:00] <othermaciej> TabAtkins: since the element is only needed as a styling hook, and not for semantics or the UA's use
# [23:00] <TabAtkins> Then again, if I go suggest in a while the idea Hixie and I were discussing, I could just write ::wrap(dlabel+*), and get a pseudoelement wrapping everything below the dlabel.
# [23:00] <Lachy> oh, that's a nice idea
# [23:01] <Lachy> would it wrap all groups of consecutive elements that match the selector?
# [23:01] <TabAtkins> (The idea is that you could specify one or two selectors, detailing the first and after-the-last element.)
# [23:01] <daedb> ::wrap(dlabel~*)?
# [23:02] <TabAtkins> So, frex, to get a section pseudo (when using implicit sectioning), ::wrap(h1,h1) would do it. Similarly ::wrap(h2,:matches(h1,h2)) for the lower ones. Though that should probably be a built-in pseudo anyway.
# [23:04] <Lachy> TabAtkins, that wouldn't quite work if you described it properly, since the second h1 would be wrapped by the pseudo-section, where as you likely want the wrap to stop before it
# [23:04] <TabAtkins> No, the second selector picks the after-the-end element.
# [23:04] <Lachy> also, you'd end up with weird overlapping wraps
# [23:04] <TabAtkins> So it would, indeed, stop just before the next h1.
# [23:04] <Lachy> oh. I misunderstand what you meant by after-the-end
# [23:04] <TabAtkins> Np. I'll be more precise when I actually suggest it.
# [23:05] <Lachy> I though you meant the wrap would begin at the start element and then continue until the end element, inclusive
# [23:05] <TabAtkins> That's what I thought at first, but it's overly hard to specify the end properly in a lot of common cases.
# [23:06] <TabAtkins> While with this, you can either specify after-the-end, or if you have an easy way to refer to the last element that should be in the group, just give "elem + *" as the second selector.
# [23:07] <TabAtkins> And, obviously, specifying only one selector like I did for the dlabel bit means that it should envelop all following siblings of the selected element.
# [23:09] <TabAtkins> There's just some oddities with being able to specify overlapping ::wrap()s that I need to resolve, probably in whatever way we decide to resolve overlapping ::text()s.
# [23:10] <othermaciej> I added Proposal 7
# [23:10] <othermaciej> (variant of 3 that adds special elements for the body parts)
# [23:11] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
# [23:11] <TabAtkins> I changed it to specify optional on both of them.
# [23:13] <othermaciej> TabAtkins: works4me
# [23:13] <Lachy> haha, I just noticed that in the current WebApps WG charter, selectors api is scheduled to reach rec in the year 20089. http://www.w3.org/2008/webapps/charter/#deliverables
# [23:13] <othermaciej> TabAtkins: after all, <tbody> is optional
# [23:13] <TabAtkins> Haha.
# [23:13] <Lachy> somehow, I don't think the internet will still be around in 18,000 yeras
# [23:13] <othermaciej> Lachy: you slacker!
# [23:13] <TabAtkins> othermaciej: Exactly.
# [23:13] <Dashiva> Lachy: Oh ye of little faith
# [23:15] * Joins: aboodman_aarrgh (n=aboodman@72.14.229.81)
# [23:22] * Quits: miketaylr (n=miketayl@38.117.156.163) ("Leaving...")
# [23:24] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
# [23:24] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
# [23:25] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) ("Leaving...")
# [23:26] * Quits: sbublava (n=stephan@77.117.34.232.wireless.dyn.drei.com)
# [23:34] * Quits: aboodman_aarrgh (n=aboodman@72.14.229.81) (Read error: 110 (Connection timed out))
# [23:34] * Parts: Clicky (n=Clicky@rob92-12-78-232-246-115.fbx.proxad.net) ("Leaving")
# [23:37] * Quits: sebmarkbage (n=miranda@213.80.108.29) (Read error: 104 (Connection reset by peer))
# [23:37] * Quits: dbaron (n=dbaron@nat/mozilla/x-pjhoadqmodaqfjai) (Read error: 104 (Connection reset by peer))
# [23:38] <Hixie> othermaciej: i believe at the time the 2d split was first suggested, i didn't have anything like my current spec gen infrastructure
# [23:38] <Hixie> it is in fact relatively easy for me to carve specific chapters out now
# [23:39] <Hixie> (though it is harder than ever to make invasive splits)
# [23:40] <othermaciej> Hixie: that is good
# [23:40] <othermaciej> Hixie: I reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=7386 , see what you think of my reasoning
# [23:43] <Philip`> If a new editor was found for one of the split-out sections, how would that work with the current spec gen infrastructure?
# [23:44] <Philip`> Would it be necessary for them to extract it into a separate source document, or would they edit the same source document in SVN, or something?
# [23:46] <Hixie> we'd just do what we did with xhr
# [23:46] * Joins: cying (n=cying@70.90.171.153)
# [23:51] * Joins: dbaron (n=dbaron@nat/mozilla/x-spmjrqmnkmoqqsha)
# [23:53] * Quits: ap (n=ap@17.246.19.5)
# [23:56] * Quits: hobertoAtWork4 (n=hobertoa@gw1.mcgraw-hill.com) ("Nettalk6 - www.ntalk.de")
# [23:56] * Joins: ap (n=ap@17.246.19.5)
# [23:59] * Quits: othermaciej (n=mjs@17.246.17.57)
# Session Close: Tue Jan 12 00:00:00 2010

The end :)