/irc-logs / freenode / #whatwg / 2012-04-04 / end

Options:

# Session Start: Wed Apr 04 00:00:00 2012
# Session Ident: #whatwg
# [00:00] <Hixie> roc_: yt?
# [00:03] * Quits: timmywil (~timmywil@host-68-169-175-226.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
# [00:06] * abarth|afk is now known as abarth
# [00:06] * jonlee is now known as jonlee|afk
# [00:08] * roc_ is now known as roc
# [00:08] <roc> yes
# [00:09] * jernoble is now known as jernoble|afk
# [00:09] * jernoble|afk is now known as jernoble
# [00:09] <Hixie> roc: i am told you have a concern over introducing a new stacking context for making fullscreen and modal <dialog>s work -- can you elaborate on that?
# [00:10] * jonlee|afk is now known as jonlee
# [00:11] <roc> I think it'll be OK if it's done properly
# [00:12] <roc> people were proposing language like "<dialog> displays on top of everything else" which isn't precise enough
# [00:12] <Hixie> ah ok
# [00:12] <Hixie> so how's this:
# [00:12] <roc> because obviously that breaks as soon as two specs say that :-)
# [00:13] <Hixie> we introduce a new stacking context between layers 9 and 10 of CSS 2.1 Appendix E, and define two operations, "push" and "yank". "push" adds an element to this layer, above all the things on it already. "yank" removes the element from this layer.
# [00:13] <Hixie> stacking contexts in this layer are not affected by things like clip/mask/opacity of their elements
# [00:13] <Hixie> of their ancestor elements, rather
# [00:14] <Hixie> z-index is ignored on this layer
# [00:14] <Hixie> positioning in the plane is done as normal, the only effect here is on z-axis stacking
# [00:14] <roc> I'm not sure what those ignore/not-affected-by comments mean
# [00:14] <Hixie> (alternatively, positioning on the plane is always done per position:absolute)
# [00:15] <roc> what about CSS transforms?
# [00:15] <Hixie> it means the element is rendered as if its box was a sibling of the root element
# [00:15] * Quits: Guest47691 (~scor@dhcp-132-183-242-94.mgh.harvard.edu) (Quit: Guest47691)
# [00:15] <Hixie> of the root element's box
# [00:15] <roc> how does this affect getBoundingClientRect on ancestors of such elements?
# [00:15] <roc> oh, never mind
# [00:16] <roc> so this affects layout as well as rendering?
# [00:16] <Hixie> probably, though i could go either way on that
# [00:16] <Hixie> seems simplest if it does
# [00:17] <roc> this is almost like a new 'position' scheme
# [00:17] <Hixie> yes
# [00:17] <TabAtkins> Kinda, but not really, since you still want positioning to work.
# [00:17] <TabAtkins> Like you want dialogs to be position:center.
# [00:17] <roc> the basic idea seems reasonable but it feels quite invasive, lots of CSS things could be affected
# [00:17] * Quits: miketaylr (~miketaylr@67.106.254.200.ptr.us.xo.net) (Quit: Leaving...)
# [00:18] <TabAtkins> And the actual layering is outside of CSS, based on the stack.
# [00:18] <Hixie> definitely invasive
# [00:18] <roc> can stuff escape from an <iframe> in this model?
# [00:18] <TabAtkins> I think so, yes.
# [00:18] <TabAtkins> You want to be able to fullscreen Youtube videos embedded via iframe.
# [00:19] <roc> well, we currently support that without having things escape from <iframe>
# [00:19] <TabAtkins> How so?
# [00:19] <roc> by fullscreening the <iframe> first
# [00:19] <TabAtkins> Oh, okay.
# [00:19] <TabAtkins> So do authors have to do two fullscreen requests?
# [00:20] <Hixie> yeah for anything inside iframes you fullscreen all the browsing context containers first
# [00:20] <roc> the current fullscreen approach is good because it's not invasive at all
# [00:20] <roc> TabAtkins: no, it's automatic.
# [00:20] <Hixie> nothing should ever be able to escape its viewport
# [00:20] <TabAtkins> Sure, putting all the browsing context containers on the stack below the actual fullscreened element is fine.
# [00:20] <Hixie> different stack
# [00:20] <Hixie> each browsing context / viewport gets its own stack
# [00:20] <roc> the thing is
# [00:21] <TabAtkins> Hixie: Ah, I see.
# [00:21] <roc> if you want an <iframe>'d widget to show a <dialog>, you really don't want to fullscreen the <iframe> and you want the <dialog> to be visible outside the <iframe> viewport. Don't you?>
# [00:21] * Joins: weinig (~weinig@17.212.155.45)
# [00:21] <Hixie> you never want anything outside an <iframe>
# [00:21] <Hixie> that's a security disaster
# [00:21] <roc> yes
# [00:21] <roc> but
# [00:21] <TabAtkins> Hixie: If you alert() in an iframe, it escapes.
# [00:21] <roc> we have a conflict here
# [00:22] <gsnedders> Likewise print
# [00:22] <roc> <dialog> users will want their dialogs to escape
# [00:22] <zcorpan> do we want outlines in the page to show when an element is fullscreened?
# [00:22] <TabAtkins> I'm probably okay with "welp, that's not a big deal".
# [00:22] <roc> <dialog> in a widget's small <iframe> will be pretty useless
# [00:22] <Hixie> i don't see why <dialog> users would want anything different than what they're getting today with <div>
# [00:22] <hober> <dialog> shouldn't escape the <iframe> it's in
# [00:22] * Quits: dbaron (~dbaron@nat/mozilla/x-lfbiyzpglnxkwrco) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [00:22] <hober> <dialog>s don't escape the main browsing context
# [00:23] <roc> Hixie: I can see why they'd want more. I'm OK with not giving it to them.
# [00:24] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
# [00:24] <zcorpan> annevk: have you considered 'outline' and fullscreen?
# [00:24] <roc> Are there strong reasons to require this special escaping magic? Is it too hard to make authors hang <dialog>s off the root element?
# [00:25] <Hixie> roc: the solution that's used by current widgets is to just spawn another iframe the size of the dialog, fwiw. That's fine by me.
# [00:25] <Hixie> roc: the problem is with nesting dialogs and fullscreen
# [00:25] <Hixie> roc: and making sure the layering still works
# [00:26] <Hixie> zcorpan: in practice nobody puts outlines at layer 10 and we should just remove that from the spec
# [00:26] <roc> we do
# [00:26] <Hixie> how do you make them be affected by transforms then?
# [00:26] <Hixie> or opacity?
# [00:27] <zcorpan> opera does afaict
# [00:27] <roc> Hixie: I dunno. "code" :-)
# [00:28] <Hixie> i don't see how you can do 'opacity' while putting outlines in layer 10
# [00:28] <TabAtkins> So you don't draw them at layer 10, you draw them at a magical undocumented layer.
# [00:28] <Hixie> opacity composites atomically
# [00:28] * Joins: cpearce (~cpearce@60.234.54.74)
# [00:29] <TabAtkins> Plus, doesn't drawing at layer 10 imply that the entire outline overlaps any elements that may be above the element?
# [00:29] <zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1444 - i don't see the outline in gecko or webkit
# [00:29] <roc> I don't understand what you think the problem is
# [00:29] <TabAtkins> roc: See zcorpan's test case.
# [00:30] <TabAtkins> If you drew outlines at layer 10, you'd see the outline drawn above the covering div.
# [00:31] <zcorpan> why does css have layer 10? what makes outlines so important they have to be visible above everything else?
# [00:31] <Hixie> "accessibility"
# [00:31] <zcorpan> -_-
# [00:32] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 244 seconds)
# [00:33] * Joins: root_ (~root@h31-3-227-36.host.redstation.co.uk)
# [00:34] * Joins: miketaylr (~miketaylr@67.106.254.200.ptr.us.xo.net)
# [00:36] * jonlee is now known as jonlee|afk
# [00:37] * jonlee|afk is now known as jonlee
# [00:40] * Quits: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com) (Ping timeout: 246 seconds)
# [00:40] <Hixie> actually i guess we should put hte layer after layer 10, and just say that outlines in these elements are always rendered atomically in this layer.
# [00:40] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:44] * Joins: necolas (~necolas@b0fbedcf.bb.sky.com)
# [00:44] * Joins: scor (~scor@drupal.org/user/52142/view)
# [00:44] * Quits: scor (~scor@drupal.org/user/52142/view) (Excess Flood)
# [00:45] <roc> sorry yes, I was wrong, we put them in layer 7.
# [00:46] <roc> we could easily put them in layer 10, not sure why I thought we had
# [00:46] * Joins: rniwa_ (rniwa@nat/google/x-eydqxoahlutdmbdw)
# [00:46] <roc> anyway
# [00:47] * Joins: stalled (~stalled@unaffiliated/stalled)
# [00:48] <Hixie> TabAtkins: actually position:center as you described it at lunch isn't what we'd want for <dialog>
# [00:48] <TabAtkins> Really? Seems fine to me.
# [00:48] <Hixie> TabAtkins: for <dialog> the top position has to be based on the scroll position at the time the dialog is shown
# [00:48] <TabAtkins> Ah.
# [00:48] <TabAtkins> For modals too?
# [00:48] <Hixie> yeah
# [00:49] <Hixie> otherwise scrolling breaks for dialogs that are taller than the viewport
# [00:49] <TabAtkins> Okay.
# [00:49] <TabAtkins> It's fine to just define it as abspos with a particular static position.
# [00:49] <Hixie> i expect we'll have to define some custom positioning actually, but i haven't looked at the issue closely recently
# [00:50] <TabAtkins> Nah, if you want document-scrolling to scroll the dialog, then just use abspos with a custom static position.
# [00:50] <Hixie> if the width changes i need the dialog to stay horizontally centered
# [00:50] <Hixie> maybe i can do that with margins
# [00:50] * Quits: stalled (~stalled@unaffiliated/stalled) (Read error: Connection reset by peer)
# [00:50] <Hixie> i'll have to examine it more closely
# [00:50] <TabAtkins> That doesn't let you adjust it (because using anything other than 'auto' in trbl would make it position relative to containing block instead).
# [00:51] <TabAtkins> Yes, left:0; right:0; margin-left: auto; margin-right: auto;.
# [00:51] * Joins: mkanat (mkanat@nat/google/x-dmerpotatmzuotnc)
# [00:52] * Joins: scor (~scor@drupal.org/user/52142/view)
# [00:52] * Quits: scor (~scor@drupal.org/user/52142/view) (Excess Flood)
# [00:52] <Hixie> does anything other than background-* apply to ::backdrop?
# [00:52] <TabAtkins> Sure, why not let everything apply?
# [00:53] <TabAtkins> I never see good reasons to artificially limit these unless absolutely necessary.
# [00:53] * Quits: mpt (~mpt@canonical/mpt) (Read error: Operation timed out)
# [00:53] * Joins: stalled_ (~stalled@unaffiliated/stalled)
# [00:53] <Hixie> dunno, is there ever a need for 'display:inline' to apply to it, say?
# [00:53] <Hixie> seems like htat's just asking for trouble
# [00:53] <roc> Hixie: currently we disallow an element from going fullscreen if there's an existing fullscreen element that's not its ancestor
# [00:53] <roc> are we doing something similar for <dialog??
# [00:53] <TabAtkins> Since it's in the layer, it's forced to a block-level display.
# [00:54] <TabAtkins> roc: Yes, I think.
# [00:54] <TabAtkins> But I'm not sure.
# [00:54] * Quits: j_wright (jamesw@ip70-173-182-202.lv.lv.cox.net) (Quit: [A] that love means death I realized too soon ...)
# [00:54] <Hixie> roc: when there's no fullscreen elements around, any <dialog> can be showModal()ed
# [00:55] <Hixie> roc: there's some implications for when you do it to a <Dialog> that's an ancestor of one already showing
# [00:55] <roc> the way we handle the "make the fullscreen element escape from opacity/transforms/etc of its ancestors" problem currently, is that we have a pseudoclass for elements that are ancestors of the fullscreen element, and we set their opacity/transform etc to none with UA CSS rules
# [00:55] <Hixie> roc: yeah
# [00:55] <roc> which works for fullscreen since those ancestors are typically not visible anyway
# [00:56] <roc> but less so for <dialog>
# [00:56] <TabAtkins> roc: That's weird if the ancestors are visible.
# [00:56] <Hixie> well, they can be visible
# [00:56] <TabAtkins> And yeah, generally unusable for dialog.
# [00:57] <roc> it's tempting to make go-fullscreen and show-dialog move the element to the end of the DOM :-)
# [00:57] <Hixie> actually i think it works fine if you make a (previously-visible) ancestor of a modal dialog itself modal. the complication is when the ancestor is display:none
# [00:58] <TabAtkins> roc: And log mutation records?
# [00:58] <zcorpan> and we don't set outline. would need to set outline on all elements except the fullscreen element and its descendants, not only ancestors of the fullscreen element
# [00:58] <Hixie> but i think the solution there is just that in that case nothing visible happens
# [00:58] * Joins: mpt (~mpt@canonical/mpt)
# [00:58] <roc> TabAtkins: I don't think I'm serious. It would break stuff.
# [00:58] <TabAtkins> Yeah, I know. ^_^
# [00:58] <roc> but
# [00:59] <roc> having elements punch all the way out of effects from CSS containers, while still inheriting style from those containers, seems super painful :-(
# [00:59] <Hixie> why?
# [00:59] <Hixie> (just trying to understand the constraints)
# [00:59] <roc> It's a new behavior
# [01:00] <Hixie> (i believe you that's it's painful!)
# [01:00] <roc> breaks existing CSS invariants
# [01:00] <Hixie> my mental model was that you just move the element's boxes into a different part of the render tree
# [01:00] <Hixie> and act as if it's display:none in the original tree
# [01:00] * Joins: dbaron (~dbaron@nat/mozilla/x-qbvsrjveotkdedjt)
# [01:01] <roc> yeah, it's actually pretty easy for us to implement that way
# [01:01] * Joins: j_wright (jamesw@ip70-173-182-202.lv.lv.cox.net)
# [01:01] <TabAtkins> Yeah, moving the render tree around is sensical.
# [01:01] <roc> however
# [01:01] <roc> understanding all the implications of that, for the CSS spec, is hard
# [01:01] <Hixie> (notably, there's no double-rendering going on, which is the usual complication)
# [01:02] * Joins: VernonK (~VernonK@108-84-174-221.lightspeed.chrlnc.sbcglobal.net)
# [01:02] <TabAtkins> roc: The implications are pretty reasonable, I think.
# [01:02] <TabAtkins> If you're literally just mutating the box tree.
# [01:02] <roc> so of course, the sensible thing to do would be to rush out the obvious implementation and let someone else clean up the mess
# [01:02] * Parts: VernonK (~VernonK@108-84-174-221.lightspeed.chrlnc.sbcglobal.net)
# [01:03] <roc> it wouldn't be so bad if the CSS specs weren't generally confused about box tree vs element tree
# [01:03] <TabAtkins> There's a lot less of that left than there used to be, at least. :/
# [01:03] <Hixie> yeah, i really wish we had someone to do the "CSS5" treatment on the box model and related areas
# [01:03] <TabAtkins> Big thing that's still broken to me is the table fix-up.
# [01:05] <Hixie> ok so new stacking layer with all its css implications, push and yank algorithms, and the new pseudo for backdrops
# [01:05] <Hixie> am i missing anything?
# [01:05] <roc> Hixie: so I think perhaps the way to go is to define a new positioning scheme, say position:viewport, which behaves like fixed but escapes from all ancestor effects, might be the way to go
# [01:06] <Hixie> roc: that's basically what i'm proposing, except without the new value. we need the existing 'position' values to control the positioning.
# [01:06] <Hixie> roc: since e.g. fullscreen wants to be position:fixed, but <Dialog> wants to be position:absolute or position:center, typically
# [01:07] <Hixie> roc: also, we wouldn't want the author to be able to put elements into this layer from CSS, since if we did that we'd lose the ordering
# [01:07] * Quits: miketaylr (~miketaylr@67.106.254.200.ptr.us.xo.net) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
# [01:07] <Hixie> roc: which is the most important aspect of this :-)
# [01:07] <roc> how would your new thing behave with position:static, then?
# [01:07] <Hixie> to quote from the e-mail i'm writing to whatwg:
# [01:07] <Hixie> The 'position' property for elements in one of these stacks computes to
# [01:07] <Hixie> 'absolute', 'fixed', or 'center' if that is its specifed value, and to
# [01:07] <Hixie> 'absolute' if the specified value is anything else.
# [01:07] <roc> ok
# [01:08] * Joins: weinig_ (~weinig@17.245.90.190)
# [01:08] <roc> er wait
# [01:09] <roc> so how does a position:absolute <dialog> element inside a transformed element behave? It somehow gets its layout from the transformed element but isn't affected by the transform?
# [01:09] * Joins: ap_ (~ap@17.245.89.133)
# [01:09] <Hixie> to quote from my e-mail again:
# [01:09] <Hixie> The containing block for such an element is the initial containing
# [01:09] <Hixie> block, same as for the root element.
# [01:10] <Hixie> (so the transform has no effect)
# [01:10] <Hixie> (not sure what you mean by "gets its layout")
# [01:10] <roc> what is the static position for left/top?
# [01:10] * Quits: ap (~ap@17.212.155.203) (Ping timeout: 245 seconds)
# [01:10] * ap_ is now known as ap
# [01:11] <roc> also
# [01:11] <Hixie> hm, good point, have to define the static position
# [01:11] <roc> the CSS Regions people redefined initial containing block so that it's a property of elements, there's no longer "the initial containing block"
# [01:11] * Quits: weinig (~weinig@17.212.155.45) (Ping timeout: 245 seconds)
# [01:11] * weinig_ is now known as weinig
# [01:11] <Hixie> o_O
# [01:12] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Quit: sedovsek)
# [01:12] <Hixie> see, this is why there should only be one CSS spec and it should be continuously maintained
# [01:12] <roc> actually I'm not sure what ended up happening there, but you might want to check
# [01:13] <roc> Hixie: at this point I should probably just wait for you to post the email
# [01:13] * Quits: weinig (~weinig@17.245.90.190) (Quit: weinig)
# [01:13] <roc> the general direction seems scary, but I can't think of a better approach
# [01:13] * Joins: miketaylr (~miketaylr@67.106.254.200.ptr.us.xo.net)
# [01:13] <Hixie> roc: your feedback has been very helpful so far, please don't hesitate to keep talking :-)
# [01:14] <roc> yeah, but I've got work to do :-)
# [01:14] <Hixie> fair enough :-)
# [01:15] * Quits: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl) (Remote host closed the connection)
# [01:16] <Hixie> is http://dev.w3.org/csswg/css3-regions/Overview.src.html the regions spec?
# [01:16] <astearns> yep
# [01:16] <Hixie> it doesn't seem to redefine containing block
# [01:16] <Hixie> it defers to 2.1
# [01:16] <astearns> The edges of the first region in a region chain associated with a named flow establish the rectangle that is the containing block used for absolutely positioned elements in the named flow which do not have an ancestor with a ‘position’ of ‘absolute’, ‘relative’ or ‘fixed’ (see [CSS21]). That first region rectangle is used as the containing block instead of the initial containing block.
# [01:16] <astearns> that's it
# [01:17] <Hixie> ah ok
# [01:17] <Hixie> that seems harmless enough
# [01:17] <astearns> we hope so :)
# [01:17] <Hixie> since i'm just bypassing the whole tree
# [01:18] * Joins: rniwa__ (rniwa@nat/google/x-qtyjbrovnyeojuhx)
# [01:18] * Quits: rniwa (rniwa@nat/google/x-rowpokndbgyvertf) (Read error: Connection reset by peer)
# [01:18] * rniwa__ is now known as rniwa
# [01:18] * rniwa_ is now known as 52AAAQCMB
# [01:20] * heycam|away is now known as heycam
# [01:21] <Hixie> ok, e-mail away
# [01:26] * Quits: rniwa (rniwa@nat/google/x-qtyjbrovnyeojuhx) (Read error: Connection reset by peer)
# [01:26] * Joins: rniwa (rniwa@nat/google/x-sbozadktuqocndgc)
# [01:27] * Quits: drublic (~drublic@frbg-5f731b82.pool.mediaWays.net) (Remote host closed the connection)
# [01:30] * Joins: rafaelw_ (u4459@gateway/web/irccloud.com/x-jyieemncpkbkllbf)
# [01:31] * Quits: tomasf (~tom@2002:55e5:dbb7:0:69bb:fe2d:c9bb:73b7) (Quit: tomasf)
# [01:31] * Joins: WeirdAl (~chatzilla@g2spf.ask.info)
# [01:41] * Quits: roc (~chatzilla@121.98.230.221) (Ping timeout: 246 seconds)
# [01:44] * Quits: miketaylr (~miketaylr@67.106.254.200.ptr.us.xo.net) (Quit: Leaving...)
# [01:46] * Quits: zcorpan (~zcorpan@pat.se.opera.com) (Quit: zcorpan)
# [01:54] * Joins: miketaylr (~miketaylr@67.106.254.200.ptr.us.xo.net)
# [02:02] * Joins: smaug____ (~chatzilla@GZYMMDCCCXIX.gprs.sl-laajakaista.fi)
# [02:02] * Joins: schnoomac (~schnoomac@melbourne.99cluster.com)
# [02:03] * Quits: 52AAAQCMB (rniwa@nat/google/x-eydqxoahlutdmbdw) (Quit: 52AAAQCMB)
# [02:04] * Joins: rniwa_ (rniwa@nat/google/x-rtqtojmtbrbqwkji)
# [02:07] * Joins: aklein (u4454@gateway/web/irccloud.com/x-rzadllrzblssvggm)
# [02:07] * Joins: jdaggett (~jdaggett@rtr.mozilla.or.jp)
# [02:07] * Quits: aklein (u4454@gateway/web/irccloud.com/x-rzadllrzblssvggm) (Client Quit)
# [02:09] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Quit: ChatZilla 0.9.88.1 [Firefox 11.0/20120312181643])
# [02:09] <tantek> Thanks for the discussion and write-up Hixie. Looking forward to seeing the full(-)screen/dialog stuff make progress.
# [02:09] <tantek> Now, as far as fullscreen vs full-screen vs fullScreen ...
# [02:09] <hober> indeed
# [02:10] * Quits: twisted` (~twisted@p5DDBB0A1.dip.t-dialin.net) (Ping timeout: 245 seconds)
# [02:12] * Quits: ehsan (~ehsan@66.207.208.98) (Remote host closed the connection)
# [02:12] * Joins: twisted` (~twisted@p5DDBAE5D.dip.t-dialin.net)
# [02:13] * Joins: roc (~chatzilla@60.234.54.74)
# [02:17] <TabAtkins> I think we should use :fullScreen in CSS, and full-screen in JS.
# [02:19] * Quits: ap (~ap@17.245.89.133) (Quit: ap)
# [02:20] * Joins: ap (~ap@17.212.155.203)
# [02:20] * Quits: ap (~ap@17.212.155.203) (Client Quit)
# [02:28] * Quits: KillerX (~anant@nat/mozilla/x-yrzedmwimjxdtgit) (Quit: KillerX)
# [02:32] * jernoble is now known as jernoble|afk
# [02:39] * jonlee is now known as jonlee|afk
# [02:41] * Quits: jsbell (jsbell@nat/google/x-uibqrfhukocqewbu) (Quit: There's no place like home...)
# [02:42] * Joins: diraol (~diraol@189.38.131.49)
# [02:42] * jonlee|afk is now known as jonlee
# [02:43] * jwalden tries to add to this discussion, thinks it is self-beclowning enough that he need not contribute
# [02:51] * Quits: Druid_ (~Druid@p5B135D1F.dip.t-dialin.net) (Ping timeout: 265 seconds)
# [02:54] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [02:56] * Joins: Druid_ (~Druid@p5B05DC65.dip.t-dialin.net)
# [02:58] * Joins: ehsan (~ehsan@209.29.21.241)
# [02:58] * Quits: ehsan (~ehsan@209.29.21.241) (Read error: Connection reset by peer)
# [02:58] * Joins: ehsan (~ehsan@209.29.21.241)
# [03:04] * Quits: pablof (~pablof@144.189.101.1) (Quit: ^z)
# [03:05] * Quits: sicking (~chatzilla@nat/mozilla/x-jwczeveckusdhqov) (Ping timeout: 246 seconds)
# [03:07] * Quits: jdaggett (~jdaggett@rtr.mozilla.or.jp) (Quit: jdaggett)
# [03:11] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
# [03:12] * Quits: jacobolus (~jacobolus@75-144-246-6-SFBA.hfc.comcastbusiness.net) (Remote host closed the connection)
# [03:13] * Quits: miketaylr (~miketaylr@67.106.254.200.ptr.us.xo.net) (Quit: Leaving...)
# [03:15] * jonlee is now known as jonlee|afk
# [03:19] * Quits: dbaron (~dbaron@nat/mozilla/x-qbvsrjveotkdedjt) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:27] * Quits: necolas (~necolas@b0fbedcf.bb.sky.com) (Remote host closed the connection)
# [03:28] * Quits: tantek (~tantek@2620:101:8003:200:a09b:ebde:643:51f2) (Quit: tantek)
# [03:30] * Joins: jacobolus (~jacobolus@70-36-215-74.dsl.dynamic.sonic.net)
# [03:36] * Quits: diraol (~diraol@189.38.131.49) (Quit: Leaving.)
# [03:45] * Quits: roc (~chatzilla@60.234.54.74) (Ping timeout: 260 seconds)
# [03:50] * Joins: tantek (~tantek@ma50536d0.tmodns.net)
# [03:51] * Quits: tantek (~tantek@ma50536d0.tmodns.net) (Read error: Connection reset by peer)
# [03:52] * Joins: tantek (~tantek@ma50536d0.tmodns.net)
# [03:57] * ojan is now known as ojan_away
# [03:58] * ojan_away is now known as ojan
# [03:58] * ojan is now known as ojan_away
# [04:00] * Joins: roc (~chatzilla@60.234.54.74)
# [04:09] <Hixie> TabAtkins: wow you almost had me responding to you there
# [04:09] <Hixie> TabAtkins: i need to update my troll detector's firmware!
# [04:31] * Quits: rniwa (rniwa@nat/google/x-sbozadktuqocndgc) (Quit: rniwa)
# [04:31] * rniwa_ is now known as rniwa
# [04:33] * Quits: tantek (~tantek@ma50536d0.tmodns.net) (Quit: tantek)
# [04:46] * Joins: bentruyman (~bentruyma@li159-104.members.linode.com)
# [04:48] * Joins: jdong_bot_ (~jdong_bot@117.79.233.224)
# [04:50] * Quits: Yudai__ (~Yudai@p656629.tokynt01.ap.so-net.ne.jp) (Quit: Tiarra 0.1+svn-36726: SIGTERM received; exit)
# [04:51] * Joins: Yudai (~Yudai@p656629.tokynt01.ap.so-net.ne.jp)
# [04:54] * Quits: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90) (Quit: need...noms...)
# [05:00] * heycam is now known as heycam|away
# [05:18] * Joins: jamesr_ (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
# [05:21] <MikeSmith> heh, "self-beclowning"
# [05:22] * Joins: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com)
# [05:22] * Quits: dave_levin (dave_levin@nat/google/x-avaxnqmbigjtrroc) (Quit: dave_levin)
# [05:25] * Joins: dydx (~dydz@adsl-76-199-102-166.dsl.pltn13.sbcglobal.net)
# [05:33] * heycam|away is now known as heycam
# [05:34] * Quits: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net) (Quit: linclark)
# [05:43] * Joins: rniwa_ (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
# [06:10] * Quits: jacobolus (~jacobolus@70-36-215-74.dsl.dynamic.sonic.net) (Remote host closed the connection)
# [06:11] * Quits: timmywil (~timmywil@host-68-169-154-67.WISOLT2.epbfi.com) (Quit: Computer has gone to sleep.)
# [06:17] * Quits: jamesr_ (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr_)
# [06:29] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
# [06:29] * Joins: smaug (~chatzilla@GZYMMDCCCXIX.gprs.sl-laajakaista.fi)
# [06:30] * Quits: smaug____ (~chatzilla@GZYMMDCCCXIX.gprs.sl-laajakaista.fi) (Ping timeout: 260 seconds)
# [06:30] * smaug is now known as smaug____
# [06:35] * Joins: izhak (~izhak@213.87.240.197)
# [06:39] * Joins: shepazu_ (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net)
# [06:40] * Quits: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net) (Ping timeout: 245 seconds)
# [06:40] * shepazu_ is now known as shepazu
# [06:43] * Joins: rniwa__ (~rniwa@216.239.45.130)
# [06:47] * Quits: rniwa_ (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Ping timeout: 246 seconds)
# [06:52] * Joins: LBP (~Mirc@pD9EB1C2C.dip0.t-ipconnect.de)
# [07:08] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
# [07:14] * Quits: mkanat (mkanat@nat/google/x-dmerpotatmzuotnc) (Quit: Ex-Chat)
# [07:18] * Joins: Areks (~Areks@rs.gridnine.com)
# [07:22] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Quit: sedovsek)
# [07:35] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
# [07:37] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Client Quit)
# [07:39] * Quits: dydx (~dydz@adsl-76-199-102-166.dsl.pltn13.sbcglobal.net) (Quit: dydx)
# [07:43] * Joins: graememcc (~chatzilla@host86-148-140-125.range86-148.btcentralplus.com)
# [08:01] * Joins: niloy (~niloy@61.12.96.242)
# [08:02] * Quits: nielsle (~nielsle@3239059-cl69.boa.fiberby.dk) (Quit: Ex-Chat)
# [08:03] * Quits: cpearce (~cpearce@60.234.54.74) (Ping timeout: 240 seconds)
# [08:07] * Joins: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de)
# [08:18] * Joins: dydx (~dydz@adsl-76-199-102-166.dsl.pltn13.sbcglobal.net)
# [08:24] * Joins: tomasf (~tom@c-b7dbe555.024-204-6c6b7012.cust.bredbandsbolaget.se)
# [08:32] * Quits: rniwa (rniwa@nat/google/x-rtqtojmtbrbqwkji) (Quit: rniwa)
# [08:32] * rniwa__ is now known as rniwa
# [08:36] * Quits: roc (~chatzilla@60.234.54.74) (Ping timeout: 246 seconds)
# [08:42] * Joins: skylamer` (cgskylamer@78.90.213.55)
# [08:43] * Joins: PalleZingmark (~Adium@217.13.228.226)
# [08:54] * Quits: ehsan (~ehsan@209.29.21.241) (Remote host closed the connection)
# [09:10] * Joins: Ducki (~Ducki@pD9E39904.dip0.t-ipconnect.de)
# [09:18] * Joins: tndrH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com)
# [09:21] * Joins: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz)
# [09:24] * Joins: charlvn (~charlvn@2002:8259:81f2::1)
# [09:25] * Joins: gwicke (~gabriel@212.255.28.33)
# [09:25] <charlvn> #tkkrlab
# [09:26] <charlvn> ah sorry, ignore that, didn't type the command correctly
# [09:32] * Joins: Ms2ger (~Ms2ger@91.181.254.51)
# [09:33] * Joins: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
# [09:37] * Joins: tantek (~tantek@70-36-139-112.dsl.dynamic.sonic.net)
# [09:37] * Quits: schnoomac (~schnoomac@melbourne.99cluster.com) (Quit: schnoomac)
# [09:38] * Joins: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net)
# [09:39] * Quits: dydx (~dydz@adsl-76-199-102-166.dsl.pltn13.sbcglobal.net) (Quit: dydx)
# [09:40] * Quits: nw (nw@kapsi.fi) (Ping timeout: 260 seconds)
# [09:47] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
# [09:48] <smaug____> annevk: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-mutationobserver-observe context object should be target, not options
# [09:50] <Ms2ger> smaug____, why's that?
# [09:51] <smaug____> Ms2ger: well, I don't understand how context object can be options
# [09:51] <annevk> smaug____: we can just say it is for those substeps
# [09:51] <annevk> childList etc. are all discussed in the context of options then
# [09:51] <Ms2ger> It's just with(options) { foo(childList); }
# [09:51] <Ms2ger> Instead of foo(options.childList)
# [09:52] <annevk> it's only for 1
# [09:52] <smaug____> ah
# [09:52] <smaug____> so it is not for 2.
# [09:53] <smaug____> strangely worded
# [09:53] <annevk> how would you word it?
# [09:53] <smaug____> well, don't talk about context object A in 1. and context object B in 2.
# [09:56] <annevk> that would make them much more verbose
# [09:56] <annevk> but if this is hard to comprehend, maybe we should do that
# [09:57] <annevk> if someone else tells me the same thing I'll take a look
# [09:57] <smaug____> both I and sicking were reading that last week
# [09:57] <smaug____> and thought that there was something odd
# [09:57] <smaug____> also, that doesn't say what happens to transient observers
# [09:58] <smaug____> er, perhaps it does
# [09:58] <smaug____> but I think it is not right
# [09:59] <smaug____> existing transient observers should be removed, I think, when calling observe()
# [10:02] * Quits: root_ (~root@h31-3-227-36.host.redstation.co.uk) (Remote host closed the connection)
# [10:09] * Quits: jochen__ (jochen@nat/google/x-njjhajkrstpbgrfg) (Remote host closed the connection)
# [10:09] * Joins: jochen__ (jochen@nat/google/x-vqdkrojmvciivazj)
# [10:20] <annevk> fullscreen proposal looks good
# [10:20] <annevk> apart from the missing bits or the bits I'm missing :p
# [10:25] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
# [10:26] * Joins: drublic (~drublic@frbg-5d84fa21.pool.mediaWays.net)
# [10:28] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
# [10:29] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
# [10:40] * Quits: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net) (Remote host closed the connection)
# [10:53] <annevk> smaug____: when do you plan on removing the prefix?
# [10:53] <annevk> smaug____: having a prefix does not help if we want people to move away from the old API
# [10:54] * Quits: rniwa (~rniwa@216.239.45.130) (Quit: rniwa)
# [11:04] * Quits: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no) (Remote host closed the connection)
# [11:04] <annevk> http://rumotan.com/guan/modules/tinyd3/ multiple doctypes, incompatible encoding declarations, multiple root elements, good times
# [11:05] <annevk> but apart from how to deal with big5, I think most of what a user agent has to do there is actually now defined
# [11:05] <annevk> we've come a long way since 2004 :)
# [11:06] <jgraham> (this comment was redacted for cynicism)
# [11:12] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 252 seconds)
# [11:15] * Joins: nw (nw@kapsi.fi)
# [11:17] * toyoshim is now known as toyoshiAw
# [11:20] * Joins: zcorpan (~zcorpan@pat.se.opera.com)
# [11:24] * Joins: GPHemsley (~GPHemsley@209-23-243-49-ip-static.hfc.comcastbusiness.net)
# [11:24] * Quits: GPHemsley (~GPHemsley@209-23-243-49-ip-static.hfc.comcastbusiness.net) (Changing host)
# [11:24] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
# [11:25] * Joins: roc (~chatzilla@121.98.230.221)
# [11:29] * toyoshiAw is now known as toyoshim
# [11:31] * Joins: nonge_ (~nonge@p508299E6.dip.t-dialin.net)
# [11:36] * Quits: nonge (~nonge@p508293CB.dip.t-dialin.net) (Ping timeout: 276 seconds)
# [11:36] <smaug____> annevk: I agree
# [11:36] <smaug____> annevk: need to stabilize the API still a bit, IMO
# [11:37] <smaug____> add that takeMutation() or something similar
# [11:37] <smaug____> takeMutations()
# [11:38] <smaug____> annevk: what is Opera's plan
# [11:38] * smaug____ should ask also MS
# [11:38] <smaug____> When will MS release IE10?
# [11:42] <annevk> we're fine with the API, just need to free up resources
# [11:44] <annevk> takeMutations() sounds pretty terrible btw
# [11:46] <smaug____> foo.take*() is used often in gecko, when the idea is to return some existing object(s) and drop the reference to those in foo
# [11:46] <smaug____> but perhaps it is a bit ugly name :)
# [11:49] <annevk> what is the problem with having disconnect() return them?
# [11:49] <annevk> the pending records
# [11:49] <annevk> that seems quite clean to me
# [11:49] <smaug____> that sounds very odd
# [11:49] <smaug____> that disconnect() returns anything
# [11:50] <annevk> yeah maybe
# [11:50] <smaug____> also, I think we want a method to take the current records, but still keep observing
# [11:50] <smaug____> fetch() doesn't sound too bad
# [11:50] <annevk> fetch is network related usually
# [11:50] <annevk> getPendingRecords() ?
# [11:51] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 246 seconds)
# [11:51] <smaug____> get* doesn't indicate that the records are dropped in the observer
# [11:54] <annevk> maybe it should be takeMutationRecords
# [11:55] <annevk> all sounds bad :(
# [11:55] <smaug____> takeRecords() ?
# [11:55] <smaug____> yeah
# [11:55] <annevk> takeRecords() is better than takeMutations at least
# [11:56] <annevk> and it returns sequence<MutationRecord> I guess
# [11:56] <annevk> hmm
# [11:57] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
# [11:58] <annevk> whoa https://www.gov.uk/designprinciples is pretty awesome
# [12:02] <Ms2ger> Much as I hate github, https://github.com/alphagov is nice
# [12:05] * Joins: mpt (~mpt@canonical/mpt)
# [12:11] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
# [12:14] * Joins: Areks (~Areks@rs.gridnine.com)
# [12:17] * Joins: necolas (~necolas@b0fbedcf.bb.sky.com)
# [12:31] * Joins: GPH-Zeke (~GPHemsley@209-23-243-49-ip-static.hfc.comcastbusiness.net)
# [12:31] * Quits: GPH-Zeke (~GPHemsley@209-23-243-49-ip-static.hfc.comcastbusiness.net) (Changing host)
# [12:31] * Joins: GPH-Zeke (~GPHemsley@pdpc/supporter/student/GPHemsley)
# [12:32] <jgraham> Yeah, the people doing UK Government we/open access data stuff seem to be pretty awesome
# [12:32] * Joins: mpt_ (~mpt@canonical/mpt)
# [12:32] <jgraham> Oh, that was the same words annevk used.
# [12:32] * Joins: niloy_ (~niloy@61.12.96.242)
# [12:32] <jgraham> I didn't mean to do that
# [12:34] * Quits: mpt (~mpt@canonical/mpt) (*.net *.split)
# [12:34] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (*.net *.split)
# [12:34] * Quits: niloy (~niloy@61.12.96.242) (*.net *.split)
# [12:34] * Quits: timeless (u4015@firefox/developer/timeless) (*.net *.split)
# [12:35] <jgraham> s/we/web/
# [12:35] <jgraham> So many errors. I should really have said anything at all.
# [12:36] <annevk> was that intentional? :)
# [12:36] * Quits: Druid_ (~Druid@p5B05DC65.dip.t-dialin.net) (Ping timeout: 263 seconds)
# [12:36] <jgraham> Fuck
# [12:36] <jgraham> No
# [12:36] <annevk> if it's any consolation, I'm amused
# [12:36] <jgraham> Good, good
# [12:37] * Joins: Druid_ (~Druid@p5B05DC65.dip.t-dialin.net)
# [12:38] <annevk> zcorpan: btw re fullscreen, I decided that layout would be someone else's problem
# [12:38] <annevk> zcorpan: it seems I might have to define it after all though, but at least Hixie worked out how (mostly)
# [12:38] <annevk> (re some comment on outline from late last night)
# [12:40] * Joins: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
# [12:41] * Quits: cpearce (~cpearce@ip-118-90-36-173.xdsl.xnet.co.nz) (Ping timeout: 246 seconds)
# [12:41] <jgraham> (having siad all of that one of the examples on that page about what not to do actually poited to a really interesting page about keeping bees. Which in turn allowed me to find an even more interesting page about keeping pigs and the regulations associated with that)
# [12:42] <Ms2ger> siad?
# [12:43] <jgraham> I know
# [12:43] <Philip`> poited?
# [12:43] <annevk> jgraham is the gsnedders of typing today :p
# [12:43] <jgraham> gsnedders is full of fail?
# [12:43] <Ms2ger> Oh, brun
# [12:44] <annevk> jgraham: didn't mean it quite like that
# [12:44] <annevk> oh well
# [12:44] <jgraham> :)
# [12:44] <annevk> so some of these big5 pages like the trailing "..." thing too
# [12:44] <annevk> but they are probably implemented using PHP or so with no respect for lead and trail bytes
# [12:44] <zcorpan> what thing?
# [12:45] <annevk> "This sentence is too l..."
# [12:45] <annevk> so you get a lead byte followed by a .
# [12:46] <annevk> which is invalid of course and is invalid in each browser, and ends up as noise in my data
# [12:46] <zcorpan> ah
# [12:46] <Philip`> "... an AML2 ‘report of a pig movement’ form ..." - surely that'd generate a huge amount of paperwork unless you tie your pig down to stop it wandering around
# [12:47] <jgraham> I imagine it work like geolocation events.
# [12:47] <zcorpan> i've seen stuff like "See my résum&acut..." too
# [12:48] <zcorpan> er, wrong entity, but you get the idea
# [12:49] <Ms2ger> You mean "See my <a href=resume>résum&eacut..."
# [12:53] <annevk> 20 2E 2E 2E is also used it seems
# [12:53] <annevk> preceded by a lead byte
# [12:54] <annevk> alright, so the errors are indeed actual errors in the pages
# [12:58] <annevk> oops, made an error
# [12:59] <annevk> in the A3 byte checking
# [13:00] <annevk> instead of about 50 pages using quite a few A3 reserved stuff, there's only two pages with one sequence each
# [13:01] <annevk> #win
# [13:06] <annevk> in one page it's inside a <meta>; in the other page it doesn't render correctly anywhere...
# [13:10] * Joins: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net)
# [13:10] <annevk> I wish the component when filing bugs would always be HTML5 spec
# [13:12] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Read error: Operation timed out)
# [13:13] <zcorpan> why did that bug get the wrong component?
# [13:13] <zcorpan> Hixie: ^ ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 )
# [13:13] <zcorpan> it got 'other hixie drafts'
# [13:14] <annevk> all bugs filed via WHATWG get that
# [13:15] <annevk> it changed quite some time ago
# [13:15] <zcorpan> oh?
# [13:16] <zcorpan> oh well
# [13:16] <annevk> I've been meaning to ask Hixie to change that around, because more than one silly revert requests was because of that
# [13:16] <annevk> not that anyone cares about that anymore these days, so maybe that's why I forgot
# [13:16] * Joins: jarek (~jarek@unaffiliated/jarek)
# [13:30] * Quits: gkellogg (~gregg@c-98-248-150-91.hsd1.ca.comcast.net) (Read error: No route to host)
# [13:30] * Joins: gkellogg_ (~gregg@c-98-248-150-91.hsd1.ca.comcast.net)
# [13:38] * Parts: zcorpan (~zcorpan@pat.se.opera.com)
# [13:38] <annevk> http://speakerdeck.com/u/jaffathecake/p/application-cache-douchebag mwaha
# [13:39] <annevk> appcache is hard
# [13:39] * Joins: zcorpan (~zcorpan@node-7ahkxa5guiunxrmui.a0.ipv6.opera.com)
# [13:42] <annevk> some of this content is rather weird
# [13:42] <annevk> "Strongly agree!!! Letting unlimited pregnant ladies come to HK to deliver is ridiculous! We shall follow what Western countries are doing: stop letting pregnant ladies in. "
# [13:42] <annevk> some kind of forum thread
# [13:45] * Quits: temp02 (~temp01@unaffiliated/temp01) (Ping timeout: 240 seconds)
# [13:45] <annevk> <center><table border=0><tr><td valign=top><html><head><meta http-equiv=Content-Type content="text/html; charset=big5">
# [13:45] <annevk> :)
# [13:46] * Joins: jryans (~jryans@cpe-70-124-81-135.austin.res.rr.com)
# [13:49] <Ms2ger> Well said, HolyEagle
# [13:50] <Ms2ger> I love how that site uses document.layers
# [13:55] <annevk> HolyEagle knows where it's at
# [13:56] <jarek> why SVG filters renders so slow on user agents? Is it a technical limitation or does the implementation is just unoptimised?
# [13:56] <Ms2ger> Because nobody uses them, I guess
# [13:56] <jarek> even simple gausian blur can lock Chrome when you zoom it in
# [13:57] <jarek> oops, sorry for typos
# [13:57] * jgraham guesses the right answer is "yes"
# [13:57] <jgraham> and probably would still be if you s/or/and/
# [13:57] <jgraham> That is, I wouldn't be surprised if there are SVG filters that are intrinsically slow
# [13:58] <jgraham> But I would be surprised if they are optimised in implementations
# [13:58] <jgraham> +well
# [13:59] <jarek> I have noticed that even professional software such as Adobe Illustrator "cheats" when rendering filters
# [13:59] <annevk> found this page that has no DOCTYPE, encoded in big5, tries to nest <form> inside <tr> (one <table>, three <tr>, three nested <form>), and the kicker is that the form submits to some URL wiht a query parameter whose value contains big5 encoded characters
# [14:00] * Quits: tantek (~tantek@70-36-139-112.dsl.dynamic.sonic.net) (Quit: tantek)
# [14:00] <jarek> so it looks like it's impossible to render them in real time without high CPU usage
# [14:00] * Joins: erichynds (~ehynds@64.206.121.41)
# [14:01] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [14:01] <annevk> jarek: should probably bring that up on public-gfx@w3.org or some such
# [14:02] <jarek> annevk: no, I don't want W3C to stop adding new filters :P
# [14:02] <jarek> annevk: I should rather nag the vendors to implement GPU accelerated rendering
# [14:10] * Joins: RobbertAtWork (~Robbert@2001:980:9368:1:5d16:4766:334b:5048)
# [14:17] * Quits: mpt_ (~mpt@canonical/mpt) (Remote host closed the connection)
# [14:19] * Joins: mpt (~mpt@nat/canonical/x-lvddoqofkzuuaqob)
# [14:20] * Quits: mpt (~mpt@nat/canonical/x-lvddoqofkzuuaqob) (Changing host)
# [14:20] * Joins: mpt (~mpt@canonical/mpt)
# [14:21] * heycam is now known as heycam|away
# [14:24] * Joins: mattwest (~textual@host81-149-171-23.in-addr.btopenworld.com)
# [14:25] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
# [14:27] * Quits: payman (~payman@pat.se.opera.com) (Remote host closed the connection)
# [14:29] * Joins: plutoniix (~plutoniix@101.108.104.102)
# [14:29] * Joins: diraol (~diraol@189.38.131.49)
# [14:30] * Quits: diraol (~diraol@189.38.131.49) (Client Quit)
# [14:30] * Joins: diraol1 (~diraol@189.38.131.49)
# [14:35] * Joins: payman (~payman@pat.se.opera.com)
# [14:38] * Quits: esc_ (~esc_ape@77.118.253.67.wireless.dyn.drei.com) (Ping timeout: 265 seconds)
# [14:39] * Quits: niloy_ (~niloy@61.12.96.242) (Ping timeout: 246 seconds)
# [14:41] * Quits: plutoniix (~plutoniix@101.108.104.102) (Quit: จรลี จรลา)
# [14:41] * Quits: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net) (Quit: shepazu)
# [14:41] * Joins: niloy_ (~niloy@61.12.96.242)
# [14:43] * Joins: esc_ (~esc_ape@77.118.253.67.wireless.dyn.drei.com)
# [14:44] <roc> yeah
# [14:47] * Quits: jochen__ (jochen@nat/google/x-vqdkrojmvciivazj) (Remote host closed the connection)
# [14:49] * Joins: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net)
# [14:55] * Joins: Bass10 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
# [15:00] * Quits: izhak (~izhak@213.87.240.197) (Remote host closed the connection)
# [15:01] * Joins: diraol (~diraol@189.38.131.49)
# [15:02] * Quits: diraol1 (~diraol@189.38.131.49) (Read error: Connection reset by peer)
# [15:06] * Joins: davidb (~davidb@66.207.208.98)
# [15:09] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [15:14] * Joins: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net)
# [15:17] * Quits: zcorpan (~zcorpan@node-7ahkxa5guiunxrmui.a0.ipv6.opera.com) (Quit: zcorpan)
# [15:19] * Quits: graememcc (~chatzilla@host86-148-140-125.range86-148.btcentralplus.com) (Quit: ChatZilla 0.9.88.1 [Firefox 11.0/20120310193349])
# [15:23] * nonge_ is now known as nonge
# [15:31] * Joins: MacTed (~Thud@63.119.36.36)
# [15:40] * Joins: zcorpan (~zcorpan@c-5eeaaa41-74736162.cust.telenor.se)
# [15:48] * Quits: zcorpan (~zcorpan@c-5eeaaa41-74736162.cust.telenor.se) (Quit: zcorpan)
# [15:50] <annevk> Ms2ger: or did something change and are you willing to publish DOM Parsing through the HTML WW now?
# [15:50] <annevk> euh, WG
# [15:50] <Ms2ger> Nothing changed, why?
# [15:50] <annevk> http://lists.w3.org/Archives/Public/public-html/2012Apr/0027.html
# [15:52] * Ms2ger shrugs
# [15:52] <annevk> the HTML WG, where the chairs are robots, the editors don't care, and a few people circlejerk
# [15:53] <Ms2ger> One more abandoned spec in the HTMLWG, news at 10
# [15:53] <annevk> heh
# [15:53] <annevk> it's not exactly abandoned
# [15:53] * Joins: zcorpan (~zcorpan@c-5eeaaa41-74736162.cust.telenor.se)
# [15:55] * Joins: plutoniix (~plutoniix@101.108.104.102)
# [15:55] <annevk> make it modular, make it modular, make it modular
# [15:56] <annevk> but oh god, once you do that and decentralize development, people get upset
# [15:56] * Quits: sedovsek (~robert.se@93-103-104-107.dynamic.t-2.net)
# [15:56] <annevk> decentralized extensibility please, developed centralized please
# [15:57] <Ms2ger> I wonder if they're going to stick a "Copyright W3C" onto it to prevent forks
# [15:57] * Quits: LBP (~Mirc@pD9EB1C2C.dip0.t-ipconnect.de) (Quit: Bye, bye! See you on http://leanbackplayer.com)
# [15:59] <Ms2ger> Heh
# [16:00] <Ms2ger> Web Workers still references Web DOM Core
# [16:01] <annevk> I guess Julian only cares about IETF draft references
# [16:02] <Ms2ger> And code points
# [16:02] <annevk> not the Encoding spec though
# [16:03] <annevk> maybe it needs more references
# [16:03] * Quits: necolas (~necolas@b0fbedcf.bb.sky.com) (Remote host closed the connection)
# [16:03] <annevk> at some point I should reference 1) Unicode and 2) all the old silly specs that were wrong
# [16:04] <zcorpan> why do you need to reference the wrong specs?
# [16:05] <annevk> we do that in DOM4 too, for people who are interested in prior work
# [16:05] <Ms2ger> Is position:center a thing?
# [16:06] <annevk> Ms2ger: http://dev.w3.org/csswg/css3-positioning/#center-positioning
# [16:06] <annevk> Ms2ger: it's been floating around on www-style for ages
# [16:07] * Quits: erichynds (~ehynds@64.206.121.41) (Read error: Operation timed out)
# [16:08] <annevk> http://webkitmemes.tumblr.com/post/20464202966/meanwhile-in-the-reviewers-lounge lol
# [16:08] <Ms2ger> Yay, concesus!
# [16:08] <Ms2ger> http://s3.amazonaws.com/data.tumblr.com/tumblr_m1v3rkjMvL1rrf1eeo1_1280.jpg?AWSAccessKeyId=AKIAI6WLSGT7Y3ET7ADQ&Expires=1333634508&Signature=9yoalJSJC6bZgj%2FvsRzlv47%2Bxfc%3D
# [16:12] * Joins: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
# [16:13] * Quits: charlvn (~charlvn@2002:8259:81f2::1) (Quit: leaving)
# [16:13] * Joins: izhak (~izhak@213.87.240.146)
# [16:13] * Parts: ksweeney (~Kevin_Swe@nyv-exweb.iac.com)
# [16:13] <matjas> zcorpan: https://github.com/douglascrockford/JSLint/issues/114#issuecomment-4766052 what just happened
# [16:14] <MikeSmith> Ms2ger: thanks for writing up warnings for the DOM specs
# [16:14] <Ms2ger> Yw
# [16:14] * Joins: timmywil (~timmywil@host-68-169-175-226.WISOLT2.epbfi.com)
# [16:15] <annevk> matjas: old news man
# [16:15] <matjas> annevk: no I mean… you actually got crockford to fix something
# [16:16] <matjas> well, new to me
# [16:16] <Velmont> :-)
# [16:20] * Joins: ehsan (~ehsan@209.29.21.241)
# [16:23] * Quits: izhak (~izhak@213.87.240.146) (Ping timeout: 265 seconds)
# [16:24] * Quits: jdong_bot_ (~jdong_bot@117.79.233.224) (Remote host closed the connection)
# [16:27] * Quits: RobbertAtWork (~Robbert@2001:980:9368:1:5d16:4766:334b:5048) (Quit: RobbertAtWork)
# [16:31] <annevk> bdo, bdo:matches([dir=ltr i], [dir=rtl i])
# [16:31] * Quits: ehsan (~ehsan@209.29.21.241) (Remote host closed the connection)
# [16:31] <annevk> why does the second selector matter?
# [16:32] <zcorpan> matjas: apparently it's harder to get someone to fix jshint
# [16:33] * Quits: PalleZingmark (~Adium@217.13.228.226) (Quit: Leaving.)
# [16:33] <Ms2ger> annevk, specificity?
# [16:34] <annevk> Ms2ger: yeah guess so
# [16:34] <annevk> Ms2ger: also, http://lists.w3.org/Archives/Public/public-html/2012Feb/0479.html
# [16:35] <Ms2ger> "Ms2ger @ Mozilla" <ms2ger@gmail.com>
# [16:35] <Ms2ger> Hah
# [16:37] <zcorpan> it seems mighty weird to use the escalation process for drafts that are not owned by the html wg
# [16:38] * Joins: shepazu (~shepazu@107.19.149.172)
# [16:39] <jgraham> s/ for drafts.*//
# [16:39] <Ms2ger> What he said
# [16:40] <annevk> stop escalating things jgraham :p
# [16:40] <zcorpan> why do i keep getting empty emails from dave.penkler@hp.com ?
# [16:40] <annevk> zcorpan: me too
# [16:40] <annevk> if I ever meet him, I might tell him to fix his email client
# [16:40] * zcorpan marks as spam
# [16:41] <annevk> lots of www-tag ends up in my spam folder these days
# [16:41] <Ms2ger> You've got a good spam filter, then
# [16:41] <zcorpan> why are you subscribed to www-tag?
# [16:42] <annevk> I found it interesting at one point and then never reevaluated my position
# [16:45] * Joins: necolas (~necolas@b0fbedcf.bb.sky.com)
# [16:54] * Quits: zcorpan (~zcorpan@c-5eeaaa41-74736162.cust.telenor.se) (Ping timeout: 246 seconds)
# [16:55] * Quits: shepazu (~shepazu@107.19.149.172) (Ping timeout: 245 seconds)
# [16:57] * Joins: shepazu (~shepazu@107.19.149.172)
# [16:57] * Joins: ehsan (~ehsan@66.207.208.98)
# [16:58] <annevk> so out of the 609 pages that did not fail to download, 22 have "problematic" sequences
# [16:58] <annevk> and 2 of those are big5-hkscs so they're probably not problematic
# [16:59] * Joins: zcorpan (~zcorpan@c-5eeaaa41-74736162.cust.telenor.se)
# [17:00] <jgraham> So 3% of pages? That is quite a lot
# [17:03] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 264 seconds)
# [17:04] <annevk> yes
# [17:04] <annevk> but only 0.01% of the characters or so
# [17:04] <annevk> the problem is however there's no interoperability
# [17:05] <annevk> see http://lists.w3.org/Archives/Public/www-archive/2012Apr/0019.html for the data
# [17:05] * Quits: shepazu (~shepazu@107.19.149.172) (Ping timeout: 252 seconds)
# [17:07] <annevk> oh shit
# [17:07] * Joins: dbaron (~dbaron@173-228-85-36.dsl.dynamic.sonic.net)
# [17:07] * Joins: shepazu (~shepazu@107.19.149.172)
# [17:09] <annevk> off by one error
# [17:09] <annevk> teehee
# [17:09] <annevk> all the URLs are wrong
# [17:10] <annevk> :(
# [17:11] * Quits: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de) (Remote host closed the connection)
# [17:15] <jgraham> Wow, some range of emotions there
# [17:15] <annevk> still sick
# [17:16] <annevk> corrected data is here: http://lists.w3.org/Archives/Public/www-archive/2012Apr/0020.html
# [17:18] <annevk> I think I just got misattributed http://infrequently.org/2012/04/one-for-dave-and-david/
# [17:20] <jgraham> I have no memory of anyone saying that the disconnect between host objects and native objects is pure awesome that has to be preserved
# [17:21] <jgraham> I do remember people saying that his solutions were naive and didn't account for the realities of the platform as it exists today
# [17:21] <gsnedders> Nobody said that.
# [17:23] <jgraham> Nobody said what?
# [17:23] <gsnedders> That the differences between host and native objects are pure awesome.
# [17:23] <gsnedders> ES6 is totally redefining what host objects do, and limiting what they can do.
# [17:24] <jgraham> Well it can't limit what they can do to less than they actually do do
# [17:24] <jgraham> Or it can but it will be a work of fiction
# [17:24] <gsnedders> jgraham: It already does that.
# [17:25] <gsnedders> jgraham: With stuff like the limitations on property attributes and stuff.
# [17:25] <jgraham> Anyway Alex seems to be attacking a strawman
# [17:25] <gsnedders> I think basically all ES engine APIs allow the host object contract to be violated.
# [17:26] * Quits: shepazu (~shepazu@107.19.149.172) (Quit: shepazu)
# [17:26] * annevk adds comment
# [17:26] <annevk> someone said something like that
# [17:26] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
# [17:27] <annevk> I think Hixie thought the separation made sense, but I'm not sure to the same extent as Alex makes it seem
# [17:27] <annevk> thought/thinks, dunno, and I've no idea what I think either
# [17:28] * Quits: Ducki (~Ducki@pD9E39904.dip0.t-ipconnect.de) (Quit: ;))
# [17:29] <jgraham> I'm pretty sure that the degree to which it was "like that" is less than entirely
# [17:30] <jgraham> Anyway, I agree with your comment that this requires change on the js side as well as the DOM side
# [17:30] <gsnedders> (FWIW, in 2006 ES4 was still going on, so it seems hardly surprising that nothing came of that, when most of the work was basically just rewriting ES3 afterwards)
# [17:31] <annevk> sure there's a ton of explanations why it didn't end up awesome
# [17:32] <jgraham> Sure. The hsitory of the platform is riddled with tragedy and missed oppertunities.
# [17:32] <gsnedders> ES6 will have binary data, at least.
# [17:32] <annevk> I guess we should figure out how to avoid that in the future
# [17:32] <annevk> I still think doing JavaScript elsewhere would help
# [17:32] <gsnedders> The big issue was wasting years on ES4.
# [17:33] <gsnedders> Should we have continued down that route after MS said they wouldn't impl it? Hard to know.
# [17:33] <annevk> prolly
# [17:33] <annevk> MS wouldn't implement XHR2 either
# [17:33] <gsnedders> The market is a very difference place now than then, though, so beckoning to them seems more sensible then than now.
# [17:33] <annevk> or unencumbered fonts
# [17:34] <gsnedders> Still, ES4 was probably too far fetched.
# [17:34] <annevk> XHR2 happened in 2006 too
# [17:34] <gsnedders> It would've taken years to get impls of.
# [17:34] <jgraham> Yeah Microsoft aren't anything special on the web these days.
# [17:34] <annevk> yeah dunno about ES4 either
# [17:35] <jgraham> I'm pretty sure everyone agrees that ES4 has an element of second system syndrone
# [17:35] <annevk> but it doesn't seem to me that ES is being developed with what's needed by APIs
# [17:35] <annevk> at least I hardly get the impression the JavaScript guys look at the platform side much
# [17:35] <jgraham> It isn't clear to me why ES releases have to be huge numbered things
# [17:35] <jgraham> Why not add one feature at a time
# [17:36] <gsnedders> Not only that, but far too much cutting-edge research going into something unproven.
# [17:36] <jgraham> With an overall design arc of course
# [17:36] <gsnedders> jgraham: Depends what changes you want. Syntax changes it makes a fair bit of sense for, you know you either get SyntaxError or you have all of these features.
# [17:36] <jgraham> Well syntax changes are pretty mcuh evil anyway
# [17:36] <gsnedders> *while still being mostly unproven
# [17:36] * Quits: MikeSmith (~MikeSmith@p15181-obmd01.tokyo.ocn.ne.jp) (Quit: MikeSmith)
# [17:37] <gsnedders> jgraham: But if you want to further a language, almost certainly needed.
# [17:37] <gsnedders> What language continues to be developed without syntax changes?
# [17:37] <jgraham> Probably
# [17:37] <jgraham> Given some import mechanism one could allow individual feature to be imported
# [17:38] <jgraham> "use strict;destructuring;let"
# [17:38] <jgraham> and then later
# [17:38] <jgraham> "use v6"
# [17:38] <jgraham> that implies a set of features
# [17:38] <gsnedders> jgraham: The idea as of ES5 was "use strict"; "destructuring"; "let";
# [17:38] <gsnedders> i.e., each is a separate string
# [17:38] <jgraham> Do you mean 5?
# [17:38] <gsnedders> Yes.
# [17:39] <gsnedders> That was the idea.
# [17:39] <gsnedders> Obviously there was only one pragma then.
# [17:39] <jgraham> Oh.
# [17:39] <gsnedders> In ES6 we just have new semantics within modules and not outwith.
# [17:39] <jgraham> Anyway, more incremental development would be good
# [17:40] <gsnedders> I think most of the limit is getting consensus and editorial resources.
# [17:40] <jgraham> Better communications between the people developing the platform APIs and the language would be good
# [17:40] <gsnedders> And it's not clear how to speed that up.
# [17:40] <jgraham> Well it isn't as much of a problem in HTML/WebApps/etc.
# [17:41] <gsnedders> Yeah, but it's not massively surprising that the language becomes a box, seeming it is a fairly disjoint part of impls, so people tend not to touch so much outwith it, as is the case with DOM and stuff.
# [17:43] <Ms2ger> It's even more fun if you try to spec something inside that box with WebIDL
# [17:43] <jgraham> That isn't entirely true
# [17:43] <jgraham> I mean plenty of people that work on javascript engines alsop work on other parts of the browser
# [17:44] <jgraham> It's just that they're typically not on es-discuss
# [17:44] <gsnedders> jgraham: Outside of Opera, who?
# [17:44] <jgraham> People at Mozilla afaict
# [17:44] <jgraham> Not the major contributers to the ES engine perhaps
# [17:44] <gsnedders> Most of the work on SM comes from people working full time on it.
# [17:44] <jgraham> But people
# [17:45] <Ms2ger> Some JS people work on bindings over here
# [17:45] <gsnedders> Well, sure. But people who only do occasional work on it probably are less inclined to get involved with it.
# [17:45] <Ms2ger> Not many venture out further, though, I think
# [17:45] <hober> Hixie: if you could review http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194 at some point today, that would be awesome.
# [17:46] <hober> Hixie: specifically, i'd like to be able to say something to the effect of " When asked, the editor has indicated that this prose description is unambiguous and detailed enough for him to make the requested changes." :)
# [17:46] * Quits: zcorpan (~zcorpan@c-5eeaaa41-74736162.cust.telenor.se) (Quit: zcorpan)
# [17:47] <hober> Hixie: also, any other comments / questions / suggestions you might have would be much appreciated. (same goes for the rest of you, of course.)
# [17:47] <hober> the sooner i finish this cp, the sooner i can work on the "defense of canvas v5" cp
# [17:48] <Ms2ger> Or you could get useful work done :)
# [17:53] * Joins: MikeSmith (~MikeSmith@p15181-obmd01.tokyo.ocn.ne.jp)
# [17:53] <annevk> added another comment
# [17:53] * Quits: yutak (~yutak@2401:fa00:4:1004:baac:6fff:fe99:adfb) (Ping timeout: 245 seconds)
# [17:53] <annevk> http://infrequently.org/2012/04/one-for-dave-and-david/comment-page-1/#comment-239690
# [17:53] * Quits: beverloo (peter@nat/google/x-juftdfvxwewvsxsh) (Ping timeout: 245 seconds)
# [17:53] * Quits: jamesr (jamesr@nat/google/x-mofneddegcumupmj) (Ping timeout: 245 seconds)
# [17:55] * Joins: yutak (~yutak@2401:fa00:4:1004:baac:6fff:fe99:adfb)
# [17:56] * Quits: diraol (~diraol@189.38.131.49) (Ping timeout: 246 seconds)
# [17:57] * Joins: beverloo (peter@nat/google/x-xfhellwklovhwquy)
# [17:57] * Joins: tantek (~tantek@70-36-139-112.dsl.dynamic.sonic.net)
# [17:57] * Joins: jamesr (jamesr@nat/google/x-fplsahcnyzxuqtuc)
# [17:58] * Joins: diraol (~diraol@189.38.131.49)
# [18:00] * Joins: erichynds (~ehynds@64.206.121.41)
# [18:05] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [18:07] * Joins: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se)
# [18:08] <jgraham> I thought that bz did some SpiderMonkey work, sometimes. I though smaug____ was changing the gc recently?
# [18:08] <smaug____> gc? no
# [18:08] <smaug____> I've been hacking cc
# [18:08] <jgraham> Oh, then I misunderstood something
# [18:08] <jgraham> Happens all the time :)
# [18:09] * Quits: zcorpan (~zcorpan@c-919ae355.410-6-64736c14.cust.bredbandsbolaget.se) (Client Quit)
# [18:09] <hober> Ms2ger: that's what the whatwg is for :)
# [18:10] <Ms2ger> jgraham, well, bz... Not all of us can keep all the C++ that goes into Firefox in our heads :)
# [18:11] <jgraham> Right, I didn't say it was normal humans :)
# [18:12] * Quits: mattwest (~textual@host81-149-171-23.in-addr.btopenworld.com) (Quit: ["Textual IRC Client: www.textualapp.com"])
# [18:16] * Quits: diraol (~diraol@189.38.131.49) (Ping timeout: 246 seconds)
# [18:16] * Joins: diraol (~diraol@189.38.131.49)
# [18:18] * Quits: espadrine (~thaddee_t@acces2373.res.insa-lyon.fr) (Remote host closed the connection)
# [18:19] * Joins: espadrine (~thaddee_t@acces2373.res.insa-lyon.fr)
# [18:19] * Joins: RobbertAtWork (~Robbert@212.238.236.229)
# [18:23] * Joins: diraol1 (~diraol@189.38.131.49)
# [18:23] * Quits: diraol (~diraol@189.38.131.49) (Ping timeout: 246 seconds)
# [18:23] <gsnedders> s/humans//
# [18:23] * gsnedders still has no evidence that bz is human
# [18:24] <gsnedders> (Has a physical existance, yes, but not whether he's human.(
# [18:24] <gsnedders> s/\($/)/
# [18:24] * Quits: diraol1 (~diraol@189.38.131.49) (Read error: Connection reset by peer)
# [18:24] <gsnedders> I really can't type today…
# [18:24] <jgraham> I don't even know what would count as evidence that someone is human
# [18:25] <jgraham> I believe he has managed to procreate successfully? But that could be with another non-human.
# [18:25] <gsnedders> Or could be some weird cross-species thing.
# [18:26] * Joins: diraol (~diraol@189.38.131.49)
# [18:27] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [18:27] * Joins: GarciaWebDev (~Alejandro@190.55.15.249)
# [18:28] * Quits: GarciaWebDev (~Alejandro@190.55.15.249) (Client Quit)
# [18:28] * Joins: GarciaWebDev (~Alejandro@190.55.15.249)
# [18:29] <dglazkov> good morning, Whatwg!
# [18:29] * Joins: pablof (~pablof@c-98-207-157-89.hsd1.ca.comcast.net)
# [18:31] * Joins: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
# [18:33] * Quits: eric_carlson (~eric@17.212.152.104) (Remote host closed the connection)
# [18:33] * eric_carlson_ is now known as eric_carlson
# [18:34] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
# [18:35] * jernoble|afk is now known as jernoble
# [18:39] <annevk> http://paul.kinlan.me/dear-appcache/ use #?
# [18:48] * Joins: yoshu (~josh@150.135.119.40)
# [18:49] * Joins: sarro (~sarro@i5E865D47.versanet.de)
# [18:49] * Parts: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
# [18:50] * Joins: ap (~ap@2620:149:4:1b01:6c56:7930:ac2d:7838)
# [18:55] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [18:59] * Quits: niloy_ (~niloy@61.12.96.242) (Remote host closed the connection)
# [18:59] * Quits: pyrsmk (~pyrsmk@161.212.140.88.rev.sfr.net) (Read error: Connection reset by peer)
# [19:00] <gsnedders> DOM5, defined entirely by a set of ES6 algorithms (as opposed to the English of DOM4)?
# [19:01] <gsnedders> Stuff like making tagName [[Writeable: false]] when it first gets added to the document is trivial in ES, difficult in WebIDL.
# [19:01] * Joins: jsbell (jsbell@nat/google/x-wtmoqnvuekewzqhr)
# [19:03] <annevk> but I think he got that wrong
# [19:03] <MikeSmith> hsivonen: you around? I wanted to ask you about possibility of using org.whattf.syntax.Driver for command-line validation
# [19:03] <annevk> you don't want it to change ever, because tagName relates to what the object exposes
# [19:04] <annevk> temporal mutability might be nice though; we might have designed events differently i imagine
# [19:06] <MikeSmith> hsivonen: I don't completely understand that code, but it seems like it enables validation without actually running the validator as a web service; if so, it would be great to extend is so it can just take a list of local files as args
# [19:07] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
# [19:08] * Joins: KillerX (~anant@nat/mozilla/x-swhipyrzehalyeoy)
# [19:11] * Quits: drublic (~drublic@frbg-5d84fa21.pool.mediaWays.net) (Remote host closed the connection)
# [19:11] * Joins: aklein (u4454@gateway/web/irccloud.com/x-mcugherijwrbevqm)
# [19:14] <MikeSmith> https://lists.webkit.org/pipermail/webkit-dev/2012-April/020174.html
# [19:14] <smaug____> seriously
# [19:17] * smaug____ so much hopes webkit community would fight for the open web
# [19:17] * jonlee|afk is now known as jonlee
# [19:18] <gsnedders> annevk: R
# [19:18] <gsnedders> *Right, it would involve mutating the [[Prototype]
# [19:19] <Ms2ger> smaug____, Google publishes a draft, Google forces an implementation through, Google uses the feature on their websites... I wonder what these have in common
# [19:19] <gsnedders> Ms2ger: Apple
# [19:19] <gsnedders> Oh, wait, no, the other one!
# [19:20] <Ms2ger> gsnedders, Opera did it fir... I guess not
# [19:20] <gsnedders> Ms2ger: No, that was video. :P
# [19:20] <gsnedders> Until you reach the part of actually shipping a final implementation.
# [19:20] <Ms2ger> Hah, final implementation
# [19:21] <gsnedders> Well…
# [19:21] <gsnedders> You know what I mean. :P
# [19:22] <Ms2ger> Opera did it last?
# [19:22] * Quits: diraol (~diraol@189.38.131.49) (Quit: Leaving.)
# [19:23] <gsnedders> Shipping a release with it included.
# [19:23] <gsnedders> We were the first to ship any build with it included, the ones who pushed for the spec… and the last to release.
# [19:23] <Ms2ger> See
# [19:23] <Ms2ger> Don't push for a spec
# [19:23] <Ms2ger> Let someone else write the spec *after* that
# [19:24] <Ms2ger> Like Opera QA
# [19:24] <gsnedders> I think the push for a spec was, "we think a video element would be cool, kthxbai"
# [19:24] <gsnedders> And then people were like "O RLY?"
# [19:24] <gsnedders> And then others were like "YA RLY."
# [19:24] <Ms2ger> Oh, I thought it was "an audio JS object would be cool"
# [19:25] <gsnedders> Oh, no, it was already in the spec by the time we implemented it, and had been for a while.
# [19:25] <gsnedders> Just nobody gave a shit.
# [19:26] <gsnedders> Or at least not to do much about it.
# [19:29] * Joins: drublic (~drublic@frbg-5f730c94.pool.mediaWays.net)
# [19:31] * Quits: esc_ (~esc_ape@77.118.253.67.wireless.dyn.drei.com) (Ping timeout: 265 seconds)
# [19:31] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
# [19:33] * Joins: esc_ (~esc_ape@178.115.249.130.wireless.dyn.drei.com)
# [19:34] <annevk> gsnedders: if ES6 gets bytes, are they aware of the encoding API?
# [19:34] * Quits: erichynds (~ehynds@64.206.121.41)
# [19:34] <annevk> gsnedders: do they envision changes to platform APIs, or are they not looking at it from that perspective?
# [19:36] <gsnedders> annevk: The aim was to get something such that Typed arrays can be redefined in terms of it
# [19:36] <gsnedders> annevk: And I don't think encoding APIs have been discussed
# [19:37] <Hixie> hober: yt?
# [19:37] <gsnedders> annevk: But you'd be better off asking someone actually on TC39
# [19:37] <hober> Hixie: yo
# [19:38] <Hixie> hober: what's the expected implementation of for=""?
# [19:38] <annevk> gsnedders: I like using you as proxy :)
# [19:38] <gsnedders> annevk: I tend not to speak to anyone on TC39 :P
# [19:39] <annevk> details
# [19:39] * Quits: plutoniix (~plutoniix@101.108.104.102) (Read error: Connection reset by peer)
# [19:39] * Quits: [[zz]] (~q@101.108.104.102) (Read error: Connection reset by peer)
# [19:39] <Hixie> hober: (isn't the usual UI going to be going from the video to the transcript, rather than going from the link to the transcript, to the video?)
# [19:39] * Joins: plutoniix (~plutoniix@101.108.104.118)
# [19:39] * Joins: [[zz]] (~q@101.108.104.118)
# [19:39] <hober> the usual ui for usual users would simply be clicking on the transcript link
# [19:39] <tantek> rel=transcript?
# [19:40] <hober> but using for="" allows AT to expose the fact that the video has a transcript associated with it
# [19:40] <hober> tantek: yup
# [19:40] <annevk> can't you do the same trick we do with blockquote
# [19:40] <hober> (and it allows the transcript to be exposed in default and/or custom video controls)
# [19:40] <annevk> paragraph preceding/following with a link that has rel=transcript
# [19:40] <Hixie> hober: so the UA is expected to walk every <a> element in the DOM to look for elements that point to the video?
# [19:40] <tantek> sounds like we're crossing over into media-info microformats like stuff
# [19:41] <hober> Hixie: unfortunately
# [19:41] <tantek> here's a video, a license for it, a transcript, author etc.
# [19:41] <Hixie> hober: that seems like a non-starter
# [19:41] <hober> Hixie: the relationship is many-to-one
# [19:41] <hober> because one media element may have many transcripts
# [19:41] <Hixie> hober: one transcript could apply to many media elements, too :-)
# [19:41] <hober> <video transcript=foo></video...<a id=foo> only lets you point at one
# [19:42] <hober> Hixie: i think that would be a much less common case
# [19:42] <Hixie> hober: if we do this at all, which frankly i think is silly, why not make transcript="" a space-separated idref?
# [19:42] <tantek> make transcript attr multivalued then like class
# [19:42] <tantek> IDRefs
# [19:42] * Joins: shepazu (~shepazu@107.19.149.172)
# [19:42] <hober> Hixie: that could work
# [19:43] <Hixie> hober: honestly though this seems like a waste of time, nobody's actually going to use this, and the few who do use it can just use aria-describedby
# [19:43] * hober adds that design to the list of considered designs
# [19:44] <hober> Hixie: well, waste of time or not, the CP deadline is today, and the other CP on the table is worse :/ i'm hoping nessy submits a zero-edit "punt this until html.next" CP too; she said she might
# [19:44] * Quits: shepazu (~shepazu@107.19.149.172) (Client Quit)
# [19:45] <Hixie> hober: if this was a whatwg proposal, i would reject it on the basis of lack of serious use cases and no indication that any implementor was actually going to do anything with it, that <track> already provides what is necessary for accessibility, and that just having a link in the page markup was plenty sufficient to handle the remaining use cases.
# [19:46] <Hixie> hober: honestly i think i prefer the other CP. It is far less invasive and I can easily just put it in the W3C copy and forget about it.
# [19:46] <hober> between <video transcript="url"> and <video transcript="idref idref idref"></video>, which do you prefer?
# [19:47] <Hixie> which is more likely to get implemented?
# [19:48] <hober> i don't know what other UAs plan to do, and we of course don't comment on our future feature plans. :)
# [19:48] <annevk> neither
# [19:48] <annevk> the former is longdesc which is terrible
# [19:48] <hober> that said, <video transcript="url"> suffers from the metacrap problem
# [19:49] <annevk> the latter is for/id name/map stuff which is also terrible and even worse if there's no observable effect
# [19:49] <hober> and <video transcript="idref idref idref"></video> encourages the transcript link to be visible & in prose near the video element, which is where we want people to put these links
# [19:49] * Joins: diraol (~diraol@143.107.108.162)
# [19:49] <Hixie> it doesn't encourage anything
# [19:49] <Hixie> nobody's gonna use it
# [19:50] <Hixie> people who have transcripts are gonna put them wherever they get the most use of their own accord
# [19:50] <Hixie> and most people aren't gonna have transcripts
# [19:51] <hober> i think putting <video transcript="url"> in the (htmlwg) spec would be damaging, so i'm trying to prevent that.
# [19:51] <hober> one way of preventing that is to simply punt on the problem, which is what nessy's cp will cover (assuming she writes it)
# [19:52] * Quits: smaug____ (~chatzilla@GZYMMDCCCXIX.gprs.sl-laajakaista.fi) (Quit: Reconnecting…)
# [19:52] * Joins: smaug____ (~chatzilla@GZYMMDCCCXIX.gprs.sl-laajakaista.fi)
# [19:52] <hober> another way is to try to come up with a design that gets you a programmatic association but that doesn't suffer from the metacrap/longdesc problem
# [19:54] <annevk> is any of the change proposals backed by research into current practice?
# [19:54] <annevk> because if not, a zero change CP is the only way to go
# [19:54] * Joins: erichynds (~ehynds@64.206.121.41)
# [19:54] <annevk> cannot add obscure HTML features based on speculation
# [19:55] <annevk> especially if you can get very close using aria-describedby
# [19:55] <Hixie> hober: what would it damage?
# [19:55] <hober> I'd be perfectly happy if my CP lost to a zero-edit CP in the poll
# [19:56] <annevk> why not just make the zero change CP then?
# [19:56] <hober> Hixie: authors would make the same sorts of authoring errors that they make with longdesc="", so ATs & UAs would be more likely to not expose transcript="" by default
# [19:59] <Hixie> hober: if the damage you are concerned about is just "waste authors' time", then rel=transcript causes the same damage.
# [20:00] <hober> heh
# [20:00] * Quits: diraol (~diraol@143.107.108.162) (Read error: Connection reset by peer)
# [20:02] <webben> @transcript could be surfaced as an icon in the default video controls
# [20:03] * Joins: diraol (~diraol@143.107.108.162)
# [20:03] <webben> that video has controls makes the situation somewhat different to img@longdesc
# [20:04] <Hixie> webben: if any user agent actually wants to do that, that changes matters dramatically
# [20:04] <Hixie> webben: i am currently working for the assumption that nobody is actually going to write any code for this stuff.
# [20:04] <Hixie> webben: in which case, my only concern is optimising for minimal impact on the spec.
# [20:05] <Hixie> annevk: yes, if you fullscreen something in an iframe, you have to fullscreen the iframe as well.
# [20:05] <MikeSmith> https://lists.webkit.org/pipermail/webkit-dev/2012-April/020175.html
# [20:06] * Quits: yoshu (~josh@150.135.119.40) (Quit: yoshu)
# [20:06] <annevk> Hixie: mkay
# [20:06] <annevk> Hixie: so the idea is that in Fullscreen we define this new CSS layout thingie?
# [20:06] <Hixie> annevk: (i suggest the UAs do that automatically)
# [20:06] <Hixie> annevk: yeah
# [20:06] <annevk> Hixie: CSS needs maintenance
# [20:07] <annevk> but okay
# [20:08] <Hixie> yeah tell me about it
# [20:08] <Hixie> you volunteering? :-)
# [20:09] * annevk looks at fake calendar
# [20:09] * annevk suggests 2020
# [20:09] <Ms2ger> annevk, well, that's before HTML5, so, excellent!
# [20:10] <annevk> oh, I accidentally 10 years
# [20:10] <annevk> I once wanted to define CSS parsing more coherently, but even that I haven't managed to do
# [20:10] <MikeSmith> "actually define how the content is encrypted" vs hand-waving
# [20:11] <annevk> defining the layout true seems so much harder
# [20:11] <Ms2ger> ohunt++
# [20:11] <annevk> yeah
# [20:11] <annevk> with the Dart debacle too
# [20:11] <annevk> one can count on ohunt
# [20:11] <Ms2ger> annevk, oh, I bet glazou would like it if you started defining layout in a spec whose name doesn't start with "CSS"
# [20:12] <gsnedders> DOM Layout.
# [20:12] * Joins: yoshu (~josh@150.135.119.40)
# [20:12] <annevk> oh hey look, I'm forking CSS 2.1 Appendix E
# [20:12] <hober> Web Layout :)
# [20:12] <gsnedders> annevk: Can you fork App. H too?
# [20:13] <annevk> Ms2ger: I'm arranging a small bunker in my backyard
# [20:13] <Ms2ger> gsnedders, dammit, I wanted to joke about that, but I had to check which letter it was :(
# [20:13] <Ms2ger> annevk, small?
# [20:14] <annevk> for one person, in case glazou decides to go thermonuclear on this
# [20:14] <annevk> gsnedders: done and done
# [20:16] * Quits: dbaron (~dbaron@173-228-85-36.dsl.dynamic.sonic.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:16] * linclark is now known as linclark|afk
# [20:16] * Joins: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net)
# [20:19] * Quits: davidb (~davidb@66.207.208.98) (Quit: davidb)
# [20:21] * Quits: diraol (~diraol@143.107.108.162) (Read error: Connection reset by peer)
# [20:23] * Joins: diraol (~diraol@143.107.108.162)
# [20:24] * Quits: diraol (~diraol@143.107.108.162) (Read error: Connection reset by peer)
# [20:25] * Quits: Ms2ger (~Ms2ger@91.181.254.51) (Read error: Connection reset by peer)
# [20:26] * Joins: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90)
# [20:30] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Quit: rniwa)
# [20:37] * Joins: graememcc (~chatzilla@host86-148-140-125.range86-148.btcentralplus.com)
# [20:39] <annevk> so :fullscreen matches the fullscreen element
# [20:39] <annevk> is there going to be a :modaldialog thing or some such?
# [20:40] <Hixie> <dialog>
# [20:40] <Hixie> er
# [20:40] <Hixie> i guess the selector wouldn't have hte angle brackets!
# [20:40] <annevk> for the non-modal case I guess you might have several dialogs open
# [20:40] <Hixie> yes
# [20:41] <Hixie> those don't end up on the stack
# [20:41] <Hixie> they're just regular abs-pos
# [20:41] * Joins: Ms2ger (~Ms2ger@91.181.161.196)
# [20:41] <annevk> ah okay, so twitter user profile dialogs end up on the stack, but G+ user profile dialogs don't
# [20:45] <Hixie> G+ user profile dialogs? you mean the hovercard things?
# [20:45] <annevk> yeah
# [20:45] * Joins: diraol (~diraol@143.107.108.178)
# [20:46] <Hixie> sounds right
# [20:49] <annevk> okay, I'll have a first attempt done somewhere in the next couple of days I hope
# [20:49] <rafaelw_> smaug___: shall we make a call about MutationObserver::take() ?
# [20:49] <rafaelw_> I'd like to start prepping a webkit patch.
# [20:49] <rafaelw_> annevk: also: ^^
# [20:50] <annevk> takeRecords() ?
# [20:50] <annevk> just take() wfm
# [20:50] <annevk> or maybe releaseRecords() ?
# [20:50] * Parts: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
# [20:50] <rafaelw_> i mildly prefer empty() or clear() to take*, but I'll leave it entirely to your & olli's judgement.
# [20:51] <smaug____> release... doesn't sound something which returns the records
# [20:51] <Velmont> Strange behaviour of anne.
# [20:51] * Joins: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl)
# [20:51] <annevk> oops, sorry
# [20:51] <smaug____> rafaelw_: empty() and clear() don't sound like they would return something
# [20:51] <rafaelw_> ;-)
# [20:52] <smaug____> takeRecords() should be pretty clear
# [20:52] <annevk> is there any spec which does something similar?
# [20:52] <rafaelw_> heh. (was just typing the same question).
# [20:52] <annevk> I don't like introducing new patterns, because people always break them
# [20:52] <smaug____> nothing comes to my minds
# [20:53] <smaug____> mind even
# [20:53] <rafaelw_> retrieveRecords() ?
# [20:53] <Ms2ger> A dragon has many minds?
# [20:56] <smaug____> retrieve() or reclaim() ?
# [20:57] <annevk> free() :)
# [20:57] <rafaelw_> i think i prefer retrieve() to take(). are you guys ok with retrieve()?
# [20:57] <annevk> sort of, it's harder to spell
# [20:57] <smaug____> yeah, harder to spell
# [20:57] * jernoble is now known as jernoble|afk
# [20:58] <rafaelw_> if both you guys want take(), i'll defer to the majority.
# [20:58] <annevk> well, I don't like take either :)
# [20:58] <rafaelw_> annevk: what do you like?
# [20:58] <smaug____> and annevk doesn't like fetch()
# [20:58] <Ms2ger> Don't let Hixie see you, designing things in committee ;)
# [20:59] <annevk> rafaelw_: I haven't been able to come up with anything I really like; takeRecords() seems least problematic thus far
# [20:59] <smaug____> fetchRecords() ?
# [20:59] <Ms2ger> Fentoooon!
# [21:00] <Ms2ger> Ahem
# [21:00] <rafaelw_> sounds like we have a winner.
# [21:00] <rafaelw_> smaug___ ?
# [21:00] <smaug____> takeRecords() ?
# [21:00] <annevk> the annoying thing with fetch is that everything network hangs around that term; that's why I'd like to avoid it
# [21:00] <rafaelw_> yup. annevk: true.
# [21:00] <smaug____> takeRecords() is ok to me
# [21:01] <rafaelw_> i'm fine with takeRecords(). it's not ideal, but i don't have any better ideas.
# [21:01] <annevk> rafaelw_: same here :/
# [21:01] <annevk> ok lets do takeRecords()
# [21:01] <Ms2ger> Pink
# [21:01] * Quits: webben (~benjamin@173-203-84-17.static.cloud-ips.com) (Ping timeout: 264 seconds)
# [21:02] <annevk> feel free to note that in the bug
# [21:02] <rafaelw_> done.
# [21:02] <annevk> it'll be added to the spec within the next couple of days
# [21:02] <rafaelw_> cool.
# [21:04] <smaug____> so, takeRecords() returns a sequence of records
# [21:04] * jonlee is now known as jonlee|afk
# [21:04] <smaug____> hmm, should the callback have a sequence as a parameter
# [21:04] * smaug____ doesn't know if that affects to anything
# [21:05] <jwalden> anyone know if it's possible to load a log page from the krijnlogger with more than a single line highlighted, but not highlighted for everyone?
# [21:07] <smaug____> rafaelw_: should takeRecords() return null or empty array if there are no records
# [21:07] <smaug____> I think empty
# [21:07] * Joins: dbaron (~dbaron@nat/mozilla/x-gagyufptgkqrumru)
# [21:07] <rafaelw_> agree
# [21:08] <smaug____> also, takeRecords() just takes the current records (removes them from the queue), and does nothing else, right?
# [21:09] * Joins: davidb (~davidb@65.93.94.10)
# [21:09] <aklein> smaug____: re: sequence, I think the callback should technically take a sequence, not an array, though I don't believe it matters at all given that the DOM doesn't hold onto a reference to that argument
# [21:10] <smaug____> aklein: yeah, that is what I was thinking too
# [21:10] * Joins: jarek (~jarek@aear178.neoplus.adsl.tpnet.pl)
# [21:10] * Quits: jarek (~jarek@aear178.neoplus.adsl.tpnet.pl) (Changing host)
# [21:10] * Joins: jarek (~jarek@unaffiliated/jarek)
# [21:11] * jonlee|afk is now known as jonlee
# [21:12] * jernoble|afk is now known as jernoble
# [21:14] * Joins: webben (~benjamin@173-203-84-17.static.cloud-ips.com)
# [21:16] * Joins: diraol1 (~diraol@143.107.108.178)
# [21:16] * Quits: diraol (~diraol@143.107.108.178) (Quit: Leaving.)
# [21:16] * Quits: jacobolu_ (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
# [21:17] * Joins: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net)
# [21:20] * Quits: diraol1 (~diraol@143.107.108.178) (Ping timeout: 252 seconds)
# [21:21] <annevk> can make it sequence throughout
# [21:22] <annevk> that's prolly better
# [21:22] <annevk> heycam|away: should a callback be passed a platform array or sequence?
# [21:22] <annevk> heycam|away: might be good to outlaw one of the two
# [21:24] <smaug____> ok, done. Now the boring part, writing tests
# [21:24] * Quits: RobbertAtWork (~Robbert@212.238.236.229) (Quit: RobbertAtWork)
# [21:25] * Quits: MikeSmith (~MikeSmith@p15181-obmd01.tokyo.ocn.ne.jp) (Quit: MikeSmith)
# [21:25] <Ms2ger> smaug____, think of it as "finding bugs" :)
# [21:26] <smaug____> that is why we have Jesse
# [21:27] <Ms2ger> Hah
# [21:34] <Hixie> hober: we decided on showModal([anchor]), right? not <dialog modal>?
# [21:35] * Quits: yoshu (~josh@150.135.119.40) (Quit: yoshu)
# [21:38] <smaug____> will showModal work like showModalDialog ?
# [21:39] * linclark|afk is now known as linclark
# [21:39] <smaug____> I assume so
# [21:39] <Ms2ger> Badly?
# [21:39] <annevk> I think the idea was to avoid that
# [21:41] <smaug____> or does the showModal have just callback which is called when the dialog is closed?
# [21:41] <smaug____> s/callback/event dispatched/
# [21:41] <annevk> I think so
# [21:41] <annevk> anyway, I should sleep and get better
# [21:41] <hober> Hixie: I don't remember; it's in the CP
# [21:41] * Ms2ger kicks annevk out
# [21:42] * Quits: danielfilho (~daniel@187.31.77.7) (Quit: </html>)
# [21:42] * hober digs up the link
# [21:42] <Hixie> smaug____: showModal() just adds an "open" attribute to the <dialog> and prevents anything outside the dialog from being focused or receiving events; the callback is an event fired on the <dialog> itself.
# [21:42] <Hixie> smaug____: it's not like showModalDialog()
# [21:42] <rafaelw_> smaugg___: yes. Just the current records and does nothing else.
# [21:42] <Hixie> hober: i'll go with showModal()
# [21:43] <Hixie> hober: can't work out how to make modal="" work
# [21:43] <hober> Hixie: the CP has <dialog modal> and dialog.show([anchor])
# [21:43] <hober> Hixie: how is it any harder than showModal()?
# [21:43] <Hixie> what happens if the attribute is removed?
# [21:44] <hober> yeah, fair enough
# [21:44] <hober> i'm surprised we didn't catch that at the time
# [21:45] <hober> with showModal(), how do you style modals differently from non-modals?
# [21:45] <hober> :modal?
# [21:49] <Hixie> you don't
# [21:50] <Hixie> (what's the use case?)
# [21:52] <hober> non-modals often look quite different than modals, but authors can target different dialogs in a variety of ways, so it's no big deal
# [21:53] <Hixie> oh if it's just a matter of looks, then yeah, the class attribute
# [21:53] <hober> fine by me
# [21:58] <linclark> Hixie: do you have a minute for a question about itemref? I'm planning out microdata support for Drupal 8
# [21:58] * Quits: skylamer` (cgskylamer@78.90.213.55)
# [21:59] <Hixie> sure
# [21:59] * Joins: pyrsmk (~pyrsmk@mau49-1-82-245-46-173.fbx.proxad.net)
# [21:59] <linclark> great, thanks
# [22:00] <linclark> I'm testing an example page with validator nu
# [22:00] <linclark> http://validator.nu/?doc=http%3A%2F%2Flin-clark.com%2Fsites%2Fdefault%2Ffiles%2Fmicrodata.php
# [22:00] <linclark> basically, I'm using itemref for every field, even ones that are nested inside the itemscope
# [22:00] <linclark> Validator NU gives me an error, but it works in Phillips parser and in mine
# [22:01] <linclark> I didn't see anywhere in the spec where it said that itemref-ed elements couldn't be children of the referencing item
# [22:02] <linclark> but I may have missed it
# [22:02] <linclark> or it may be right here: "Properties that are not descendants of the element with the itemscope attribute can be associated with the item using the itemref attribute. "
# [22:03] <Hixie> that sentence isn't normative
# [22:03] <Hixie> but let me look for the normative version
# [22:04] <hober> annevk Hixie: you might find http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-6 more to your liking
# [22:04] <Hixie> hober: that certainly works for me :-)
# [22:05] * Quits: graememcc (~chatzilla@host86-148-140-125.range86-148.btcentralplus.com) (Quit: ChatZilla 0.9.88.1 [Firefox 11.0/20120310193349])
# [22:06] <Hixie> linclark: yeah, it's an error because of the step that says "7. If current is already in memory, there is a microdata error" in the definition of "the properties of an item"
# [22:06] <Hixie> linclark: the error is ignored, so it'll work, but it's non-conforming, because it usually means there was an authoring mistake
# [22:06] <Ms2ger> hober, "experiemental"
# [22:07] * Joins: drublic_ (~drublic@frbg-5f730c94.pool.mediaWays.net)
# [22:07] <linclark> Hixie: ahh, thanks... do you think it would be poor form for Drupal to handle properties that way?
# [22:07] <Hixie> linclark: it would be poor form for drupal to do something non-conforming, yes :-)
# [22:07] <linclark> Hixie: the problem is that the item doesn't know which of its properties will be displayed inside it
# [22:07] <Hixie> linclark: it's easy to work around, though; just make the itemscope be on a <meta> element
# [22:08] <Hixie> linclark: instead of a <div>
# [22:08] <linclark> Hixie: ok, cool, thanks!
# [22:08] <Hixie> linclark: np
# [22:08] <Hixie> linclark: when designing this we assumed most people would want to mark up subtrees as being a particular item with a bunch of properties, as opposed to having properties all over the place
# [22:09] <Hixie> linclark: which is why this is less than aethetically ideal
# [22:09] <Hixie> linclark: for your case
# [22:09] <linclark> Hixie: that's the assumption that Drupal 7 core makes too, but Drupal 8 is blowing that to pieces
# [22:09] <Hixie> k
# [22:09] <hober> Ms2ger: thanks. i really need to get around to fixing flyspell-mode on this laptop...
# [22:09] <Ms2ger> Np
# [22:10] * Quits: drublic (~drublic@frbg-5f730c94.pool.mediaWays.net) (Ping timeout: 276 seconds)
# [22:10] <Hixie> gotta go, bbiab
# [22:11] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
# [22:14] * Quits: Ms2ger (~Ms2ger@91.181.161.196) (Quit: nn)
# [22:16] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: Leaving)
# [22:16] * Quits: Bass10 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 244 seconds)
# [22:23] * Joins: MikeSmith (~MikeSmith@p15181-obmd01.tokyo.ocn.ne.jp)
# [22:24] * Quits: KillerX (~anant@nat/mozilla/x-swhipyrzehalyeoy) (Quit: KillerX)
# [22:25] * Quits: astearns (~astearns@192.150.22.5) (Quit: astearns)
# [22:26] * Joins: astearns (~astearns@192.150.22.5)
# [22:27] * Quits: jacobolus (~jacobolus@50-0-133-210.dsl.static.sonic.net) (Remote host closed the connection)
# [22:27] * Quits: erichynds (~ehynds@64.206.121.41)
# [22:28] * Quits: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no) (Remote host closed the connection)
# [22:28] * jonlee is now known as jonlee|afk
# [22:32] * Joins: erichynds (~ehynds@64.206.121.41)
# [22:32] * Joins: hasather_ (~hasather_@cm-84.208.108.107.getinternet.no)
# [22:33] * jonlee|afk is now known as jonlee
# [22:34] * Joins: KillerX (~anant@nat/mozilla/x-dmxckgzklnducdow)
# [22:37] * Joins: miketaylr (~miketaylr@65-122-15-169.dia.static.qwest.net)
# [22:37] * ojan_away is now known as ojan
# [22:39] * Quits: erichynds (~ehynds@64.206.121.41)
# [22:39] * Quits: kennyluck (~kennyluck@114-43-121-95.dynamic.hinet.net) (Read error: Connection reset by peer)
# [22:40] * Joins: kennyluck (~kennyluck@114-43-124-199.dynamic.hinet.net)
# [22:43] * Quits: sedovsek (~robert@93-103-90-17.dynamic.t-2.net) (Quit: sedovsek)
# [22:45] * Joins: jamesr_ (~jamesr@173-164-128-209-SFBA.hfc.comcastbusiness.net)
# [22:46] * Quits: pablof (~pablof@c-98-207-157-89.hsd1.ca.comcast.net) (Quit: ^z)
# [22:50] * Joins: jacobolus (~jacobolus@50-0-92-49.dsl.dynamic.sonic.net)
# [22:50] * Joins: sicking (~chatzilla@2620:101:8003:200:226:bbff:fe05:3fe1)
# [22:50] <eseidel> ah, Hixie is around :)
# [22:53] * Joins: rniwa (~rniwa@173-164-128-209-SFBA.hfc.comcastbusiness.net)
# [22:54] * Quits: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net) (Quit: linclark)
# [22:54] * Joins: sedovsek (~robert@93-103-90-17.dynamic.t-2.net)
# [23:01] * Joins: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net)
# [23:05] * Joins: Bass10 (Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
# [23:09] * Joins: jarek (~jarek@bct109.neoplus.adsl.tpnet.pl)
# [23:09] * Quits: jarek (~jarek@bct109.neoplus.adsl.tpnet.pl) (Changing host)
# [23:09] * Joins: jarek (~jarek@unaffiliated/jarek)
# [23:10] <jarek> is there anything like innerHTML for SVG?
# [23:13] <jarek> http://lists.w3.org/Archives/Public/public-html-bugzilla/2012Apr/0051.html
# [23:13] <jarek> says it's should be on Element.prototype, but I can't get it to work on any browser
# [23:13] <jarek> was that introduced just recently?
# [23:14] <gsnedders> jarek: Been in the spec for a while, not implemented
# [23:15] <jarek> should't it be called innerSVG?
# [23:17] * Quits: smaug____ (~chatzilla@GZYMMDCCCXIX.gprs.sl-laajakaista.fi) (Ping timeout: 246 seconds)
# [23:19] * Quits: isherman (isherman@nat/google/x-tgidwjseevqbtmju) (Quit: Leaving.)
# [23:20] <roc> no
# [23:20] <roc> then we'd need innerXML, innerMathML, etc
# [23:22] * Quits: MacTed (~Thud@63.119.36.36) (Read error: Connection reset by peer)
# [23:22] * Joins: smaug____ (~chatzilla@YZKMMMCIV.gprs.sl-laajakaista.fi)
# [23:22] <jarek> it would make more sense to deprecate innerHTML and introduce innerContent
# [23:22] <roc> not worth it
# [23:24] * Joins: isherman (isherman@nat/google/x-xayjuyhjhbibljgc)
# [23:26] <espadrine> Hey everyone, the coremob w3c group has released an Acid3-like test bundle for mobile phones at http://www.rng.io/
# [23:26] <espadrine> Explanation is at https://developers.facebook.com/html5/blog/post/2012/04/04/the-methodology-behind-ringmark/
# [23:26] <espadrine> Ring 1 intends to test for support of DRM, which is a little controversial (euphemism) but the effort is good
# [23:26] * Quits: gwicke (~gabriel@212.255.28.33) (Quit: Bye!)
# [23:27] * jonlee is now known as jonlee|afk
# [23:29] * Quits: roc (~chatzilla@121.98.230.221) (Ping timeout: 246 seconds)
# [23:32] <Hixie> eseidel: wassup?
# [23:32] <Hixie> jarek: what do you mean by "deprecarte"?
# [23:32] <Hixie> "deprecate", even
# [23:32] <tantek> espadrine - so that's the not-so-hidden agenda, an attempt to get DRM interop by way of an acid-test like approach.
# [23:32] <jgraham> espadrine: Well there is no spec for DRM at the moment so I don't see how that will happen
# [23:32] <tantek> 1 DRM Ring to control them all
# [23:32] <tantek> :P
# [23:33] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
# [23:33] <jgraham> tantek: "DRM ... interop" I'm not sure I follow
# [23:33] <tantek> jgraham - LOL
# [23:34] <espadrine> tantek: if it's any consolation, the spec they are working on states: "codecs are evil. Thoughts?"
# [23:34] <jarek> Hixie: I mean leave innerHTML in the spec for backward compatibility, but introduce new property that would have name that actually makes sense
# [23:34] <jgraham> espadrine: I think that is more Robin than Facebook
# [23:35] <Hixie> jarek: so basically just add another attribute that does the same thing?
# [23:35] <Hixie> jarek: that would just add bloat
# [23:35] <jarek> Hixie: I have even better idea - make SVG part of HTML, then innerHTML would make perfect sense
# [23:35] <Hixie> jarek: SVG is part of HTML. :-)
# [23:36] <Hixie> (for some definition of "part of")
# [23:36] <Hixie> anyway
# [23:36] <Hixie> see /topic
# [23:36] <jarek> Hixie: but it's still XML, you can't write it using HTML grammar
# [23:36] <jgraham> It is disappointing that the blog post talks about "features offered by iOS and Android", since those aren't browsers
# [23:36] <Hixie> yes you can
# [23:37] <jarek> Hixie: you mean when SVG is embeded directly in HTML, I do not have to close SVG tags?
# [23:37] <Hixie> jarek: you have to follow the syntax rules described in the HTML specification
# [23:38] <espadrine> jgraham: true, I assume they meant safari for iOS and Android's default browser
# [23:38] <Hixie> jarek: see http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1450
# [23:38] * Joins: danielfilho (~daniel@187.31.77.7)
# [23:38] <eseidel> Hixie: would like to talka bout <iframe seamless>
# [23:38] <Hixie> eseidel: shoot
# [23:39] <eseidel> Hixie: you intend <iframe seamless> to remain a replaced element, yet "act like" a block, correct?
# [23:39] <Hixie> eseidel: not sure what you mean by "act like a block"
# [23:40] <eseidel> Hixie: it's supposed to fill its parent width
# [23:40] <Hixie> eseidel: it's supposed to do what it says here: http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless
# [23:40] <jgraham> espadrine: Probably. Not a very healthy attitude that the only browser that matters is the one that ships with the device. Too much like designing only for IE.
# [23:40] <eseidel> yup, i'm aware :)
# [23:40] <Hixie> eseidel: which, as far as width goes, means "In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic width of the iframe to the width that the element would have if it was a non-replaced block-level element with 'width: auto'."
# [23:41] <jarek> is there any hope that the baseVal/animVal stuff will be dropped from SVG2 spec?
# [23:41] <eseidel> Hixie: this is thus unaffected by the display type
# [23:41] * Quits: dbaron (~dbaron@nat/mozilla/x-gagyufptgkqrumru) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:41] <eseidel> so iframe.style.display should remain "inline"
# [23:41] <jarek> it breaks pretty much all HTML DOM frameworks like jQuery
# [23:42] <eseidel> Hixie: and I assume, that it should shrink-wrap, as a block would, when floated
# [23:42] <Hixie> eseidel: iframe.style.display returns the value specified in the style="" attribute, so typically it will remain the empty string
# [23:42] <eseidel> Hixie: sory, window.getComputedStyle(iframe).display then :)
# [23:42] <jgraham> jarek: Did you send feedback to the wg?
# [23:43] <Hixie> eseidel: if you float it, then "the width that the element would have if it was a non-replaced block-level element with 'width: auto'" would be zero, presumably
# [23:44] * Quits: davidb (~davidb@65.93.94.10) (Quit: davidb)
# [23:44] <Hixie> eseidel: though i think that could probably be better defined
# [23:44] <eseidel> Hixie: when you float a block, it shrink wraps around its kids, is my understanding
# [23:44] <eseidel> that's the behavior I've currently implemented
# [23:44] <Hixie> eseidel: the iframe has no kids
# [23:44] <Hixie> eseidel: if it's not replaced
# [23:44] <ojan> Hixie: that's gross
# [23:45] * Quits: miketaylr (~miketaylr@65-122-15-169.dia.static.qwest.net) (Quit: Leaving...)
# [23:45] <ojan> Hixie: it should shrink-wrap!
# [23:45] <Hixie> ojan: i'm not talking about what a good design should be, i'm just answering questions about what the spec says today
# [23:45] <eseidel> Hixie: that's fine, those are the qeustions I'm answering :)
# [23:45] <ojan> Hixie: oh sure...i was telling eseidel that the spec should change
# [23:45] <eseidel> askgin, rather
# [23:45] <Hixie> ojan: i'm happy to talk about changing what the spec says, but that's a different conversation :-)
# [23:45] <ojan> Hixie: fair enough
# [23:45] <eseidel> Hixie: so your interpretation of the currnet spec, is that when floated the width shoudl be 0
# [23:46] <Hixie> ojan: (i think you're probably right that it should change)
# [23:46] <Hixie> eseidel: well, the current spec actually says something which as ojan says is pretty dumb, which is that its contents, namely the fallback markup between the <iframe></iframe> tags, would be shrink-wrapped
# [23:46] <eseidel> is ee.
# [23:46] <Hixie> eseidel: typically that's empty so it would be zero width
# [23:47] <eseidel> ojan was suggeting earlier an interpretation would be to just force iframe to be display: block in this mode
# [23:47] <ojan> Hixie: i think the computedStyle of display on <iframe seamless> should be block and that we should pretend that the iframe's contentDocument's children are it's children
# [23:48] <Hixie> eseidel: 'float' forces display:block anyway
# [23:48] <eseidel> ojan: obviously you don't mean firstChild spanning docs :)
# [23:48] * Quits: tantek (~tantek@70-36-139-112.dsl.dynamic.sonic.net) (Quit: tantek)
# [23:48] <eseidel> Hixie: correct
# [23:48] <ojan> Hixie: and that you should be able to do <iframe seamless style="display:inline-block"> to get a shrink-wrapped seamless iframe
# [23:48] <ojan> Hixie: and in that case the computedstyle would obviously be display:inline-block
# [23:49] <Hixie> ojan: well it needs to be a replaced element
# [23:49] <Hixie> ojan: whether it's block or inline doesn't much matter, i don't see why we wouldn't just leave it be what the author set it to
# [23:49] * Joins: roc (~chatzilla@60.234.54.74)
# [23:49] <ojan> Hixie: i'm not really sure what the implications of being replaced are
# [23:49] * eseidel neither
# [23:49] <ojan> Hixie: it seems more consistent with e.g. coerciing display of a floated element to block
# [23:49] <Hixie> see http://www.w3.org/TR/CSS21/visudet.html
# [23:50] <Hixie> e.g. 'width' doesn't apply to non-replaced inline elements
# [23:50] * Quits: Necrathex (~Necrathex@82-170-160-25.ip.telfort.nl) (Quit: Leaving)
# [23:50] <Hixie> 'padding' doesn't apply to replaced block elements
# [23:51] <Hixie> basically anything that's like an image or form control is replaced
# [23:51] <Hixie> anyway
# [23:51] <Hixie> i agree that shrink-wrapping the contents makes sense if the element is unconstrained
# [23:51] <Hixie> spec needs to change to say that
# [23:51] <Hixie> can you file a bug or send mail to whatwg?
# [23:52] <ojan> sure
# [23:52] <Hixie> awesome, thanks
# [23:52] <Hixie> (looks like i just didn't think of the case of a seamless iframe not being in flow)
# [23:54] <Hixie> specifically i think the spec needs to say that for in-flow, block-level seamless iframes, the width is the width of the containing block minus the inline-progression-direction margins and borders
# [23:55] <Hixie> and that for other cases, the width is the intrinsic width of the root element's box in the document in the iframe
# [23:55] <Hixie> or some such
# [23:55] <eseidel> Hixie: further clarification would certainly be helpful :)
# [23:56] <ojan> Hixie: by deafult, iframe's are display:inline, right? so...by that definition, to get display:block style rendering you'd need to set seamless and display:block, no?
# [23:57] <ojan> Hixie: is intrinsic width == shrink-wrapped width?
# [23:57] * Quits: GarciaWebDev (~Alejandro@190.55.15.249) (Read error: Connection reset by peer)
# [23:57] <eseidel> ojan: it's unclear what display: block would change, other than the max-width interaction
# [23:57] <ojan> eseidel: inlines don't fill their containers width
# [23:57] <eseidel> ojan: except seamless iframes, hack their way into doing so
# [23:57] <eseidel> ojan: unless constrained by max-width
# [23:57] * Joins: pablof (~pablof@c-98-207-157-89.hsd1.ca.comcast.net)
# [23:58] <Hixie> ojan: yeah, you'd need to set display:block if you wanted the iframe to act like a block
# [23:58] <ojan> eseidel: i'm just commenting on Hixies use of "block-level" above...by default iframe's aren't block-level
# [23:58] <Hixie> ojan: otherwise it'll just sit on the line (like an inline-block, more or less)
# [23:58] <ojan> Hixie: hm...not sure how i feel about that...i guess that's ok
# [23:58] <eseidel> ojan: I need to write a test for what happens when <iframe seamless style="max-width: "> is on a line, that it doesn't force the other content on that line to the next line
# [23:59] <Hixie> ojan: "intrinsic width" is an input into the css model. "shrink-wrapped width" is a nebulous concept I'd have to define better.
# [23:59] <ojan> Hixie: but it seems by far the common case will that be people will want display:block
# [23:59] <Hixie> ojan: that's usually the case with iframes in general
# [23:59] <ojan> Hixie: would you be opposed to adding iframe[seamless] { display: block } to the UA stylesheet?
# Session Close: Thu Apr 05 00:00:00 2012

The end :)