| 00:08 | <Hixie> | nessy: yt? |
| 00:09 | <Hixie> | nessy: what happens if someone has a short track and a long track slaved together, seeks to the end of the long track, and starts playing backwards? What does the .currentTime of the short track do over the lifetime of the playback? |
| 00:09 | <Hixie> | i wonder if i have to add some new state that means "would play except the media controller is outside the range of playable content for this track" |
| 00:10 | <Hixie> | the question then is what happens if the author seeks that slaved track while it's in that state... |
| 00:11 | <Hixie> | this multitrack thing sure is a lot of pain for something i'm not convinced anyone really cares about |
| 00:12 | <Yuhong> | http://www.reddit.com/r/xss/comments/gc9ce/an_xss_prevented_by_using_xhtml/ |
| 00:13 | <Yuhong> | URL say what it is. |
| 00:14 | <Yuhong> | "However at least Firefox and Chrome would not render that tag because of the onload attribute is given twice and strict XHTML is used. So breaking out of the tag completely in order to inject a <script> tag for example is even harder because of file names must not contain slashes. " |
| 00:46 | <Lachy> | Hixie, we're experementing with <details><summary>, and I've been playing around with XBL bindings for styling them. |
| 00:46 | <Lachy> | so far, it seems that XBL 2.0 as currently defined has a few limitations that make it a little bit inadequate for that purpose. |
| 00:48 | <Lachy> | also, the rendering section in HTML for details needs to be significantly revised. (email about that coming soon) |
| 00:54 | <Hixie> | XBL2's biggest problem is that nobody's implementing it |
| 00:55 | <Hixie> | so i expect it'll change a lot before we're done |
| 00:58 | <Lachy> | yeah, I know. We're not implementing it yet, but this experimentation I've been doing should provide you with some useful feedback. |
| 00:58 | <Hixie> | cool |
| 00:58 | <Lachy> | e.g. When rendering the disclosure triangle, that requires an inline box inside the <summary> element's line box, which needs to be shifted left using negative margin, and which must be rendered before any ::before content |
| 00:59 | <Lachy> | that's not possible with XBL2 as specified |
| 01:00 | <Lachy> | it's basically like the list bullet of an <li>, but without a special 'display' property to handle it |
| 01:01 | <Lachy> | btw, chromium's implementation of details and summary is the worst possible implementation that just breaks in so many ways. They need to fix it before shipping it. |
| 01:01 | <TabAtkins> | Indeed. ;_; |
| 01:01 | <AryehGregor> | It's not even an implementation. |
| 01:01 | <TabAtkins> | It's being fixed now. |
| 01:02 | <TabAtkins> | I think it'll be good in 11? |
| 01:02 | <AryehGregor> | It's a caricature of an implementation. |
| 01:02 | <Lachy> | TabAtkins, try details::before { content: 'X' } and see that rendered after the summary :-) |
| 01:03 | <TabAtkins> | Lachy: I don't even want to try. Even our "fixed" impl is done with custom renderers and is still pretty bad. |
| 01:03 | <jamesr> | ideally we'd implement details/summary using XBL internally |
| 01:03 | <TabAtkins> | Yup, we discussed that last friday. |
| 01:03 | <Lachy> | some other amusing things to try include setting display: inline; which doesn't actually work. |
| 01:04 | <Lachy> | jamesr, we won't be using XBL internally, but we want our implementation to be compatible with any future XBL implementation. |
| 01:05 | <Lachy> | so that when we hopefully do implement XBL (no idea when it'll be prioritised), we can re-implement it easily. |
| 01:05 | <Hixie> | Lachy: sounds like a display:run-in element before the summary |
| 01:06 | <Hixie> | Lachy: or some such |
| 01:07 | <Lachy> | oh, run-in might solve one of my problems... |
| 01:07 | Lachy | looks... |
| 01:08 | <Lachy> | (I'm not sure if we implement it though, but we can pretend we do) |
| 01:11 | <Lachy> | Hixie, where in CSS does it describe how run-in boxes and generated content interact? |
| 01:15 | <TabAtkins> | It doesn't. |
| 01:15 | <TabAtkins> | Especially now that run-in was removed from 2.1. |
| 01:16 | <Lachy> | ok, so if we had a binding that looked like this: |
| 01:16 | <Lachy> | <div style="display:run-in"><span style="display:run-in">▸</span><content includes="summary"></content></div> |
| 01:16 | <Lachy> | with this CSS applied: |
| 01:16 | <Lachy> | details, summary { display: block; } |
| 01:16 | <Lachy> | summary::before { content: "x"; } |
| 01:17 | <Yuhong> | http://www.zeldman.com/2009/11/26/a-zing-too-far/#comment-50092 |
| 01:17 | <Lachy> | that would make the div a block, and span an inline box of within the summary, and the 'x' generated between the ▸ and the summary |
| 01:18 | <Yuhong> | (Clue: look at Zeldman's response further down the page, and then click the schneegans.de link again) |
| 01:22 | <TabAtkins> | Yuhong: I don't understand what you're trying to point out. |
| 01:22 | <Lachy> | display: run-in; might not work sanely though if the <summary> gets floated. Ideally, the disclosure triangle would get floated with it, which means it actually needs to be a child of the summary, not a run-in sibling :-( |
| 01:23 | <Yuhong> | Basically a reader reported an error in an XHTML page, see the comment I linked to for details, and Zeldman responded that they fixed it. |
| 01:23 | <TabAtkins> | If I split apart 'display', then the ::marker-generating property would be separate from other display stuff, and you could rely on that for <summary>. |
| 01:23 | <Lachy> | Yuhong, that's an old issue that is well known to occur on many sites claiming to be XHTML |
| 01:24 | <TabAtkins> | (I think It'd split it to 'display-outside', 'display-inside', and 'display-extras' or something, with a 'marker' value on the last one causing a ::marker to be generated. |
| 01:24 | <Yuhong> | Yea, but I am pointing this out because this is a particularly bad case, look at Zeldman's response, then visit the schneegans.de link again and guess what error you see. |
| 01:24 | <Lachy> | that would also be useful |
| 01:25 | <Lachy> | we wanted a pseudo-element to reference the disclosure triangle, and we were using <span pseudo="-o-disclosure"></span> in the binding to achieve that. |
| 01:26 | <TabAtkins> | Actually, hm, what's wrong with just using display:list-item on <summary> right now, and styling the ::marker? |
| 01:26 | <Yuhong> | "getting well-formedness right is exceptionally hard if you don't keep checking for it," |
| 01:26 | <Yuhong> | From http://lists.w3.org/Archives/Public/public-html-xml/2011Jan/0138.html. |
| 01:28 | <Lachy> | we considered using ::marker too, but decided against reusing it because doing so would mean we'd have to implement that for list items too, or risk it breaking sites later |
| 01:28 | <TabAtkins> | I don't see what the problem is with implementing ::marker. ^_^ |
| 01:29 | <Lachy> | TabAtkins, nothing in theory, but the scope of the task has its limits. |
| 01:29 | <TabAtkins> | But anyway, can you just use the marker machinery but not expose it as a pseudo on <summary> yet? |
| 01:29 | <TabAtkins> | I dunno what sort of implementation limits you're actually running into, so my suggestions may be worthless. |
| 01:30 | <Lachy> | hmm, maybe we can use list-item. |
| 01:30 | <Lachy> | I was sure I tested it and thought there was something wrong with it, but I might be mistaken. |
| 01:30 | <TabAtkins> | Expose some prefixed list-style-types, one for open and one for closed, and just apply them appropriately. |
| 01:31 | <TabAtkins> | details > summary { display: list-item; } details[open] > summary { list-style-type: o-disclosure-open; } details:not([open]) > summary { list-style-type: -o-disclosure-closed; } |
| 01:32 | <Lachy> | oh, the problem was that if authors wanted to display the details and summary inline instead, they would lose the marker |
| 01:32 | <TabAtkins> | Yeah, the lack of inline list-items is pretty crappy. |
| 01:33 | <Lachy> | thanks. I'lll experiment with this again tomorrow. Maybe that's a limitation we can accept for now, and fix later when display gets split apart as you suggested. |
| 01:34 | <TabAtkins> | And I guess set list-style-position:inline on <summary>, too. |
| 01:35 | <Lachy> | TabAtkins, this is what I've been experimenting with. It's basically a simulated XBL binding, with the shadow tree represented as real elements. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/910 |
| 01:36 | <TabAtkins> | Good thing is, ::marker is defined to go before ::before, which is what you want here. |
| 01:37 | <Lachy> | indeed |
| 01:39 | <Lachy> | TabAtkins, does list-item also handle putting the marker on the right for RTL languages? |
| 01:39 | <TabAtkins> | Yes, list-style-position:inside handles that. |
| 01:40 | <Lachy> | hmm, cool. |
| 01:41 | <Lachy> | ok, that means I can greatly simplify the XBL binding, so that it only needs to handle the activation behaviour to open/close, and moving the first child summary to always be the first line box. |
| 07:41 | <MikeSmith> | Hixie: if you're around, can you please push the button to generate new W3C versions of HTML5 and friends? |
| 07:41 | <MikeSmith> | I just checked in the updates to the boilerplate |
| 07:45 | <zcorpan> | publishing tiem? |
| 07:47 | <hsivonen> | I wonder how http://www.w3.org/QA/2011/04/wiki-based_documentation_proje.html is going to compare to MDC |
| 07:47 | <MikeSmith> | zcorpan: yeah, getting there |
| 07:49 | <MikeSmith> | zcorpan: http://www.w3.org/TR/2011/WD-html5-diff-20110405/ is just awaiting webmaster to review and flip the switch on the main /TR symlink |
| 07:52 | <MikeSmith> | hsivonen: when it was demo'ed to me a while back, that's one of the things I asked about |
| 07:52 | <MikeSmith> | part of the response was that it can provide details about implementation status across browsers |
| 07:53 | <hsivonen> | MikeSmith: MDC tries to do that too |
| 07:53 | <MikeSmith> | yeah, I was going to say I personally don't see any reason why more cross-browser implementation status can't be provided at MDC |
| 07:53 | <MikeSmith> | It just requires somebody taking time to do it |
| 07:54 | <hsivonen> | https://developer.mozilla.org/en/css/css_transitions#Browser_compatibility |
| 07:55 | <MikeSmith> | OK |
| 07:55 | <hsivonen> | I can imagine that other vendors might be less comfortable with contributing to MDC than to a W3C wiki, though |
| 07:55 | <MikeSmith> | yeah, some would I guess |
| 07:56 | <MikeSmith> | but I know that some Google folks have already been contributing to MDC |
| 07:56 | <MikeSmith> | I think the details about implementation status in https://developer.mozilla.org/en/HTML/Element are well done |
| 07:56 | <MikeSmith> | the color-coding |
| 07:56 | <MikeSmith> | and not just about implementation status |
| 07:57 | <MikeSmith> | I think that could be made useful for cross-browser implementation details if somebody took time to do it |
| 07:57 | <MikeSmith> | and of course it wouldn't necessary need to be people from other browser projects |
| 07:58 | <MikeSmith> | most of the details are already at caniuse anyway |
| 08:01 | <hsivonen> | Hixie: could we make fragment parsing always parse <noscript> as if scripting was enabled? |
| 08:02 | <hsivonen> | Hixie: that is, are there any use cases we should care about that allow the script calling into the fragment parser run but that make the context node not have scripting enabled for it? |
| 08:02 | <hsivonen> | even if the context node is in designmode, presumably the caller isn't expecting to strip <noscript> tags and show noscript content |
| 08:03 | <othermaciej> | does <noscript> act as if scripting was disabled inside a no-script sandboxed iframe? |
| 08:03 | <hsivonen> | I have no idea |
| 08:03 | <hsivonen> | but I'd expect so |
| 08:03 | <hsivonen> | when loading the page as a non-fragment |
| 08:05 | <othermaciej> | if the sandboxed iframe does not have a unique origin, the parent frame can script it |
| 08:05 | <othermaciej> | so that's at least one observable way, besides design mode, to create a fragment in a context where scripting is disabled |
| 08:10 | <abarth> | othermaciej: that's correct |
| 08:12 | <othermaciej> | mind you, I don't know what the sensible behavior is in either of these cases |
| 08:13 | <abarth> | hsivonen: why does that matter? |
| 08:13 | <abarth> | the allow-scripts bit is frozen when the document is created |
| 08:13 | <hsivonen> | I'd want to remove the check for the scripting state from fragment parsing for performance reasons and always run the parser in the mode that produces "scripting enabled"-shaped trees |
| 08:14 | <hsivonen> | abarth: I believe it's not that simple in Gecko |
| 08:14 | <abarth> | is that really measurable performance? |
| 08:14 | <abarth> | i see |
| 08:14 | <hsivonen> | abarth: smaug said 6% with simple arguments to the parser |
| 08:14 | <abarth> | in webkit, the only token-level operations you can see in perf benchmarks are mallocs |
| 08:14 | <abarth> | branches are invisible |
| 08:14 | <abarth> | ! |
| 08:14 | <abarth> | wow |
| 08:15 | <abarth> | that's v. surpising |
| 08:15 | <hsivonen> | abarth: https://bugzilla.mozilla.org/show_bug.cgi?id=559319 |
| 08:15 | <othermaciej> | I wonder what would happen if we took the equivalent branch out of WebKit |
| 08:15 | <hsivonen> | abarth: this isn't a token-level operation. it is part of the parser setup |
| 08:17 | <abarth> | othermaciej: i'm sure it wouldn't be measurable, even on eric's fragment micro benchmark |
| 08:17 | <abarth> | hsivonen: can you cache the result on the document so you just copy it each time you start the fragment parser? |
| 08:17 | <hsivonen> | abarth: I have no idea. |
| 08:18 | <abarth> | hsivonen: maye query lazily when you get a noscript token? |
| 08:18 | <othermaciej> | it's an edge case, but I'm surprised that computing whether scripts are allowed as a one-time setup prior to parsing the fragment would be so expensive |
| 08:19 | <abarth> | http://trac.webkit.org/browser/trunk/Source/WebCore/html/parser/HTMLTreeBuilder.cpp#L943 |
| 08:19 | <abarth> | looks like we read the state lazily in webkit |
| 08:19 | <hsivonen> | abarth: that wouldn't be nice for the network case, because in the network case, the code that wants to know is off the main thread |
| 08:19 | <abarth> | right, but we're talking about the fragment parser, right? that's synchronous |
| 08:19 | <hsivonen> | http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#11779 |
| 08:20 | <hsivonen> | abarth: yeah, but then I'd have to have different code for network and fragment |
| 08:20 | <abarth> | othermaciej: i be you could make that check show up in a <noscript> fragment microbenchmark in webkit |
| 08:20 | <abarth> | othermaciej: that function ends up calling out to the client |
| 08:21 | <othermaciej> | putting <noscript> in a fragment is a crazy thing to do |
| 08:21 | <hsivonen> | it seems that computing the value involves checking for the designmode state |
| 08:21 | <othermaciej> | therefore, there is almost certainly web content that does it |
| 08:21 | <abarth> | :) |
| 08:21 | <hsivonen> | in all the parent browsing contexts |
| 08:22 | <hsivonen> | othermaciej: we had a bug reporter complain that document.write("<noscript><img src='...'></noscript"); in a nested document.write caused the URL for src to be preloaded |
| 08:22 | <hsivonen> | othermaciej: so you are probably right |
| 08:23 | <hsivonen> | so at least people are document.writing <noscript> |
| 08:25 | <hsivonen> | (Firefox 4 may end up speculatively preloading stuff inside noscript that appears in nested document.write, because making the speculation correct inside nested document.write was pointlessly complex compared to the benefit) |
| 08:26 | <abarth> | hsivonen: i think the webkit preloader always assumes scripts are enabled |
| 08:26 | <abarth> | it has a fake state machine for the stuff that the tree builder computes |
| 08:27 | <hsivonen> | abarth: this case wasn't about that assumption. it was about synchronizing the state after nested document.writes |
| 08:27 | <hsivonen> | and <noscript> is very stateful |
| 08:27 | <hsivonen> | anyway, people do weird stuff |
| 08:27 | <hsivonen> | this time for advertising |
| 08:28 | <hsivonen> | so the reporter was unhappy about the extra GETs that affected ad payments, I gather |
| 08:29 | <hsivonen> | it remains a mystery to me, when one would expect the content of a document.written noscript to show |
| 08:29 | <abarth> | ah |
| 09:46 | <zcorpan> | http://www.ietf.org/mail-archive/web/hybi/current/msg07065.html - [hybi] call for feedback on Masking alternatives |
| 09:48 | <Hixie> | hsivonen: there's not much to the current noscript design, it's mostly just what was simplest to do while being compatible with what i found. so changing it should be fine. send a mail. |
| 09:49 | <Hixie> | MikeSmith: i'm in the middle of a rather involved edit right now and am likely to be afk for a few days but will be able to regen in a few days. if it's urgent let me know and i'll revert my current edits temporarily and force a regen when i'm next around (prolly tomorrow). |
| 09:49 | <hsivonen> | Hixie: did you happen to test stuff like innerHTML on a node that lives in designmode? |
| 09:49 | <Hixie> | no |
| 09:49 | <hsivonen> | Hixie: ok |
| 09:50 | <Hixie> | barely did any contenteditable testing, don't think i did any designMode testing |
| 09:50 | <Hixie> | at least not for its effect on parsing |
| 09:50 | <Hixie> | right, gotta sleep now. nn. |
| 09:50 | <hsivonen> | hooray for huge undefined parts of the platform |
| 09:50 | <hsivonen> | nn |
| 09:50 | <Hixie> | yeah no kidding |
| 09:50 | <Hixie> | later |
| 10:08 | <Lachy> | Hixie, with details/summary, should the <summary> only be used if it is the :first-child, or should the binding take the first summary element child? |
| 10:09 | <Lachy> | We are thinking that it should only apply to details>summary:first-child |
| 10:09 | <Lachy> | rather than details>summary:first-of-type |
| 10:13 | <Lachy> | Hixie, should the opening and closing of a details be handled as the default action of the summary element, which can be prevented by evt.preventDefault(), or should it be handled as a click event that could be stopped by evt.stopPropagation() during capture? |
| 10:17 | <jgraham> | Lachy: The spec seems rather clear on the first point; it should be the first summary element child, not just if it is the :first-child |
| 10:17 | <jgraham> | Do you want to change it for some reason? |
| 10:17 | <Lachy> | jgraham, yeah, we know what the spec says. We are thinking about changing it |
| 10:17 | <jgraham> | Why? |
| 10:17 | <jgraham> | For the second point, how do <label>s work? |
| 10:18 | <Lachy> | compare, <fieldset>x<legend>y</legend></fieldset>. That doesn't move the legend to the top. |
| 10:19 | <Lachy> | yet the spec wants that magic with summary. It's doable, but why should we allow authors do put them in the wrong order and expect it to work? |
| 10:22 | <Lachy> | brb |
| 11:25 | <hsivonen> | whoa. I missed the <u> survey and am on track to missing the alt surveys |
| 11:25 | <Lachy> | TabAtkins, yt? |
| 11:29 | <jgraham> | Lachy: BTW in <fieldset>a<legend>b[...] the <legend> is the :first-child |
| 12:29 | <Lachy> | jgraham, good point. Tarquin and I just discussed it, and it'll be easier if we just do as the spec says and support details>summary:first-of-type |
| 12:45 | <hsivonen> | whew. I objected on all three alt polls. |
| 13:37 | <MikeSmith> | can somebody please check http://www.w3.org/2005/07/pubrules and let me know if it's giving you an error? |
| 13:37 | <zcorpan> | i get an error |
| 13:42 | <MikeSmith> | zcorpan: thanks |
| 14:31 | hsivonen | is amused by rnd=(randomNumber) as a query param |
| 14:32 | <hsivonen> | where (randomNumber) is the string "(randomNumber)" |
| 14:50 | <hsivonen> | I wonder if users appreciate wasting an HTTP request on this script: http://imgs.adverticum.net/scripts/doDocWrite.js |
| 14:57 | <jgraham> | hsivonen: Pretty much all advertising seems designed to slow down the web with multiply nested scripts document.writing external scripts that document.write scripts that... and so on |
| 15:00 | <zot--> | bypassExplicitUserPreferences.js |
| 15:05 | <hsivonen> | jgraham: indeed, guess what loads the above script... http://imgs.adverticum.net/scripts/gwloader.js |
| 15:31 | <Philip`> | I wonder if you could make an effective ad-block extension simply by blocking any nested document.write |
| 15:51 | <jgraham> | Philip`: Sadly it would have lots of false positives |
| 15:51 | <jgraham> | People *really* like document.writing scripts |
| 15:52 | <wilhelm> | I wonder who actually writes those scripts. |
| 15:54 | <CvP> | [wilhelm] people! |
| 15:55 | <wilhelm> | I'm not convinced. |
| 15:56 | <zewt> | it's never even once occurred to me to use it for anything, ever, heh |
| 15:56 | <gsnedders> | wilhelm: But you think I'm a robot, so what do you know? |
| 16:53 | <TabAtkins> | Lachy: I wasn't then, but I am now. |
| 16:55 | <Lachy> | TabAtkins, we were working on details/summary earlier, and encountered a few problems with the fact that elements inserted into the binding had the unfortunate effect of inserting their own layout boxes, even when unwanted |
| 16:55 | <Lachy> | consider a template like this: |
| 16:55 | <Lachy> | <template><content includes="summary"/><span id="content"><content/></span></template> |
| 16:56 | <Lachy> | if an author writes this markup: <details><summary>Summary</summary><div>Content</div></details> |
| 16:56 | <Lachy> | then applies these styles: details { display: table; } summary, div { display: table-cell; } |
| 16:57 | <TabAtkins> | Ah, yeah, there's now a shadow <span> in the middle. |
| 16:57 | <Lachy> | the problem is that the inline span element surrounding the div in the binding affects the way table boxes are generated, and so the layout effect is different from what it would otherwise be without the binding |
| 16:57 | <Lachy> | we came up with 2 possible solutions. |
| 16:58 | <Lachy> | 1. Dynamically change the attached binding based on the state of the details element, so that the open state excludes the span element, and the closed state includes it with display: none; |
| 16:58 | <Lachy> | i.e. details { binding: d.xml#closed } details[open] { binding: d.xml#open } |
| 17:00 | <Lachy> | 2. Invent a new 'display' value that means not to generate a box for the element, but still render the children as normal |
| 17:00 | <Lachy> | e.g. [open] #content { display: transparent; } #content { display: none; } |
| 17:01 | <TabAtkins> | We already kinda want #2 for some Component use-cases. |
| 17:01 | <Lachy> | oh, nice |
| 17:01 | <Lachy> | is that drafted anywhere? |
| 17:01 | <TabAtkins> | Or rather, iteration I guess, so you can have a container for each stamped-out iteration without making layout weird. |
| 17:01 | <TabAtkins> | No, it's not. |
| 17:01 | <Lachy> | ok. |
| 17:02 | <TabAtkins> | Start a thread on the list? |
| 17:02 | <Lachy> | I'm going to be mailing the whatwg shortly with all our findings about styling details. It's mentioned in there, but I can also raise it on www-style later too |
| 17:02 | <TabAtkins> | Cool. |
| 17:15 | Philip` | sees an email that is far too long to read and tries to find the conclusion |
| 17:16 | <Philip`> | "the HTML Working Group hereby adopts the 'drop the summary="" attribute' Change Proposal for ISSUE-32" - that sounds like it |
| 17:35 | <jgraham> | Would anyone like to summarise why there is a (apparently) http debate going on on public-html? |
| 17:35 | <TabAtkins> | From what I can tell? Because people are crazy. |
| 17:35 | <jgraham> | I want to know if reading the mail is as pointless as I suspect |
| 17:35 | <TabAtkins> | Also, BECAUSE MY MUTE BUTTON WON'T MUTE HARD ENOUGH. >_< |
| 17:35 | <TabAtkins> | Yes, it's pointless. |
| 18:04 | <MikeSmith> | latest round of updated WDs are now (semi)live |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-html5-20110405/ |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-html5-diff-20110405/ |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-2dcontext-20110405/ |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-microdata-20110405/ |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-html-markup-20110405/ |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-html-polyglot-20110405/ |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-html-alt-techniques-20110405/ |
| 18:04 | <MikeSmith> | http://www.w3.org/TR/2011/WD-rdfa-in-html-20110405/ |
| 18:06 | <MikeSmith> | they await webmaster review and flipping the short symlinks to point to these versions |
| 18:07 | <MikeSmith> | in the mean time, if anybody spots any problems with any of them, lemme know |
| 18:08 | Philip` | sees a problem |
| 18:08 | <Philip`> | There's too many documents :-( |
| 18:08 | <dglazkov> | also rdfa |
| 18:08 | <dglazkov> | that's a problem |
| 18:10 | karlushi | sees two trolls or maybe three |
| 18:13 | <karlcow> | http://dev.iptc.org/rNews |
| 18:13 | <karlcow> | rNews is a proposed standard for using RDFa to annotate news-specific metadata in HTML documents. |
| 18:34 | <micheil> | hmm.. can anyone add feedback to the websocket document? |
| 18:34 | <micheil> | http://dev.w3.org/html5/websockets/ ? |
| 18:34 | <micheil> | I get an error about javascript not being enabled in my browser, when I do have javascript enabled in my browser. |
| 18:41 | <charlvn> | micheil: i'm getting some javascript errors on that page |
| 18:41 | <micheil> | :/ |
| 18:41 | <charlvn> | in firefox 3.6.13 i should add |
| 18:46 | <MikeSmith> | dev.w3.org:301Uncaught SyntaxError: Unexpected end of input |
| 18:46 | <MikeSmith> | dev.w3.org:226Uncaught ReferenceError: fixBrokenLink is not defined |
| 18:47 | <MikeSmith> | those would be my fault |
| 18:47 | <MikeSmith> | indirectly |
| 18:47 | <MikeSmith> | (for not having caught them before those docs were published) |
| 18:47 | <KaOSoFt> | Do you people happen to know of an Agent Switcher for Chrome? I tried the on at Google Extensions, but it didn't seem to work. |
| 18:49 | <charlvn> | KaOSoFt: you mean this one? https://chrome.google.com/extensions/detail/aafciojnlamllgpkpdkbamkfgbofhgcj |
| 18:49 | <KaOSoFt> | charlvn, yeah. |
| 18:49 | <charlvn> | KaOSoFt: working fine this end, although i'm using chromium |
| 18:50 | <KaOSoFt> | Hmm... |
| 18:50 | KaOSoFt | goes to try Chromium |
| 18:51 | <MikeSmith> | those Chrome extension URLs are just wonderful |
| 18:51 | <MikeSmith> | how could anybody not love them |
| 18:51 | <KaOSoFt> | Haha, user-friendly, easy to remember... |
| 18:51 | <charlvn> | actually, sorry you're right, it doesn't work here either |
| 18:51 | <zewt> | hey, that's my password |
| 18:52 | <charlvn> | i just tested it with an http header viewer and the user agent string remains unchanged doesn't matter which browser i select |
| 18:52 | <charlvn> | MikeSmith: well, it's google, so i guess they figure you can just, ahem, google it? |
| 18:53 | <KaOSoFt> | charlvn, yeah, I have some JavaScript code, and I indeed verified the HTTP user-agent response. |
| 18:58 | <AryehGregor> | Okay, so it looks like hg now thinks I have two heads, because of an old obsolete commit I don't want to commit. |
| 18:58 | <AryehGregor> | How do I get rid of the second head? |
| 18:58 | <AryehGregor> | I mean, an old obsolete commit I don't want to push. |
| 18:59 | <Philip`> | hg strip? |
| 18:59 | <AryehGregor> | I'm guessing that's yet another extension? |
| 18:59 | <Philip`> | No |
| 18:59 | <AryehGregor> | hg: unknown command 'strip' |
| 18:59 | <Philip`> | Oh |
| 18:59 | <Philip`> | Maybe it is |
| 18:59 | <Philip`> | http://mercurial.selenic.com/wiki/Strip |
| 19:00 | <AryehGregor> | Part of Mq? |
| 19:00 | <Philip`> | Seems so |
| 19:00 | <AryehGregor> | I'll just throw it out and re-checkout. |
| 19:00 | <AryehGregor> | Re-clone. |
| 19:00 | <MikeSmith> | I don't think it's pat of mq |
| 19:00 | <AryehGregor> | I'm still used to SVN terminology, it seems. |
| 19:00 | <Philip`> | Why not just enable mq and strip? |
| 19:00 | <Philip`> | Or you could leave it, because everyone knows two heads are better than one |
| 19:02 | <AryehGregor> | I was trying to figure out how to work in a line about hydras, but you got a better one. |
| 19:03 | <charlvn> | AryehGregor: just out of interest, which version of mercurial are you using? |
| 19:03 | <charlvn> | the ubuntu packages are always outdated |
| 19:03 | <AryehGregor> | Undoubtedly. |
| 19:03 | <AryehGregor> | It's 1.4.3, since my server is on 10.04 LTS. |
| 19:04 | <charlvn> | for example on mint 10 the package is 1.6.3-1 and the release is 1.8.2 |
| 19:09 | <charlvn> | AryehGregor: sorry was distracted for a sec, yeah i just install it using python setuptools then i get the latest |
| 19:09 | <AryehGregor> | Doesn't bother me. |
| 19:09 | <AryehGregor> | I only install things other than from packages if I really need a specific feature. |
| 19:10 | charlvn | = alphageek :P |
| 19:10 | <TabAtkins> | Argh, Fun is such a ridiculously cool language it makes me die. (Very simple) realtime chat app in 16 lines of code: http://marcuswest.in/read/fun-chat/ |
| 19:10 | zewt | = alphaphobe |
| 19:10 | <charlvn> | lol |
| 19:15 | <Philip`> | TabAtkins: That sounds like a terribly unGoogleable name |
| 19:16 | <TabAtkins> | It is, yes. |
| 19:23 | <AryehGregor> | When running long scripts, is there some way to avoid freezing up the browser? Like setTimeout(0) or something? |
| 19:23 | <TabAtkins> | Yes, exactly that. |
| 19:23 | <TabAtkins> | Or use Workers or something. |
| 19:23 | <AryehGregor> | But then I have to run things asynchronously. |
| 19:23 | <AryehGregor> | I can't just yield somehow while still remaining synchronous? |
| 19:23 | <TabAtkins> | Yes. That's the definition of "not locking up the browser". |
| 19:23 | <AryehGregor> | Hmm. |
| 19:23 | <AryehGregor> | I guess so. |
| 19:24 | <TabAtkins> | That said, there's some work on better async going on in the JS world that would let you yield while still writing code that *looks* sync. |
| 19:24 | <AryehGregor> | . . . I don't know why browsers can't allow you to scroll around and things like that when the page is running a script, though. |
| 19:24 | <TabAtkins> | (Related to 'yield'-based iterators in implementation.) |
| 19:25 | <zewt> | <script type="text/lua"> |
| 19:27 | <gsnedders> | AryehGregor: No reason they can't. Just traditionally where they render to is the same thread as where DOM/ES runs |
| 19:35 | <MikeSmith> | um, is ""We must deconstruct the silos of control" some kind of joke that I'm missing? |
| 19:37 | <MikeSmith> | some line from Fight Club that I forgot? |
| 19:39 | <MikeSmith> | somebody please tell me it is |
| 19:39 | <MikeSmith> | and that nobody could possibly take a line like that seriously |
| 19:39 | <MikeSmith> | please |
| 19:40 | <TabAtkins> | No luck. |
| 19:40 | <MikeSmith> | fuck |
| 19:40 | MikeSmith | drinks some sochu |
| 19:43 | <zewt> | we spend a decade or two on the internet, we keep thinking we can't be surprised by the things people will say with a straight face, and somehow, we're continually taken by surprise, again and again |
| 19:43 | <MikeSmith> | I wonder what's the international government-approved rate at which one man can go through an 1800cc bottle of shouchu |
| 19:43 | <MikeSmith> | zewt: your words are wise |
| 19:43 | <MikeSmith> | in this particular case |
| 19:44 | <MikeSmith> | why do I always find myself wanting to drink heavily when I check twitter backlog? |
| 19:45 | <AryehGregor> | Is there an easy way to convert a NodeList to a fixed array? |
| 19:45 | <AryehGregor> | Like say I want to get a list of node.childNodes that doesn't change if the node's children change. |
| 19:46 | <TabAtkins> | Can't you just slice it? |
| 19:46 | <TabAtkins> | [].slice(nodelist) |
| 19:46 | <AryehGregor> | Do you mean splice? |
| 19:46 | <TabAtkins> | no |
| 19:46 | <AryehGregor> | [].slice() expects numeric arguments, doesn't it? |
| 19:47 | <TabAtkins> | [].slice.call(nodelist,0) |
| 19:47 | <AryehGregor> | [].slice(anything) will always return [], surely? |
| 19:47 | <AryehGregor> | Oh. |
| 19:47 | <AryehGregor> | You mean like that. |
| 19:47 | <gsnedders> | AryehGregor: No, ToUnit32 is called on the argument |
| 19:48 | <gsnedders> | s/ToUint32/ToInteger/ |
| 19:49 | <AryehGregor> | What does that have to do with anything? |
| 19:49 | <AryehGregor> | Freaky, it works. |
| 19:49 | <AryehGregor> | TabAtkins' suggestion, I mean. |
| 19:49 | <gsnedders> | ToInteger(undefined) = 0 |
| 19:49 | <AryehGregor> | Is there a saner-looking way to do that? |
| 19:49 | <TabAtkins> | No. |
| 19:49 | <AryehGregor> | gsnedders, [].slice(0) won't return []? |
| 19:50 | <gsnedders> | AryehGregor: It will. The same as [].slice() because ToInteger(undefined) == 0 |
| 19:50 | <TabAtkins> | That's the only way to call another object's functions on an arbitrary object. |
| 19:50 | <AryehGregor> | Array.prototype.slice instead of [].slice looks saner, although longer. |
| 19:50 | <TabAtkins> | Yeah, like 12 characters longer! Clearly ridiculous. |
| 19:50 | <MikeSmith> | heh |
| 19:51 | <gsnedders> | AryehGregor: So it has something to do with 19:51 < AryehGregor> [].slice() expects numeric arguments, doesn't it? |
| 19:51 | <AryehGregor> | gsnedders, I was saying that [].slice(nodelist) wouldn't do anything useful if nodelist is a NodeList. |
| 19:51 | <AryehGregor> | Which I think is correct, TabAtkins' later suggestion is what's needed. |
| 19:52 | <gsnedders> | Yeah, you need call/apply |
| 20:56 | <jgraham> | AryehGregor: You could get all your users to use Opera so your script wouldn't lock up the browser ;) |
| 20:57 | <zewt> | heh that's probably firefox's single biggest problem--wonder if they have any theories of how to fix that, since from what I've seen of its infrastructure it seems like a fundamentally hard thing for them |
| 20:57 | <TabAtkins> | The answer is to run the UI on a separate thread from JS execution, but that's hard. |
| 20:58 | <zewt> | well, since FF's own UI is largely JS itself... |
| 20:58 | <jgraham> | (there are other ways to solve it) |
| 21:03 | <zewt> | (preemptive multitasking by the JS VM, for one) |
| 21:04 | <TabAtkins> | That wouldn't help in the face of run-to-completion semantics, would it? |
| 21:04 | <zewt> | that's tricky, but i think not necessarily trickier than threaded execution |
| 21:07 | <zewt> | though it doesn't help in all cases, at least without extra work; for example, an expensive canvas operation or other generally native calls |
| 22:41 | <jgraham> | Argh. Microsoft want websockets to be more like XHR :( |
| 22:41 | <jgraham> | (The API) |