| 00:45 | <Hixie> | heycam|away: any progress on https://www.w3.org/Bugs/Public/show_bug.cgi?id=17201 ? |
| 02:36 | <zewt> | youtube is a case study in the fact that a company will intentionally utterly cripple a video streaming service to save money |
| 02:36 | <zewt> | been worthless for like a year or more now |
| 02:47 | <tantek> | youtube seemed to work fine for streaming the recent US presidential debates, just one example, but still, didn't expect it to work as well as it did and be such high quality (HD over DSL). |
| 02:51 | <zewt> | it's a case study in once a company has an effective monopoly, not giving a shit about user experience |
| 02:56 | <zewt> | this 3-minute video i'm trying to watch is 12 MB, which my connection can download in about 4 seconds, yet youtube's player refuses to buffer more than ~50 seconds into the future, and it end up falling on its ass and underrunning halfway through the video |
| 02:58 | <zewt> | seems like they just destroy tcp window sizing, once it clamps the buffer size it never recovers |
| 02:59 | <Hixie> | url? |
| 03:00 | <zewt> | every youtube video, heh |
| 03:00 | <zewt> | (both html5 and flash) |
| 03:00 | <Hixie> | the 12MB one |
| 03:01 | <zewt> | not sure since i closed it already, some thelonelyisland one i think heh |
| 03:02 | <zewt> | the basic case seems to be "youtube wants to throttle bandwidth usage, and if no smooth mechanisms exist to do it they're willing to use bad mechanisms instead" |
| 03:02 | <Hixie> | when you have one you know is small and you want me to look into it, give me a url :-) |
| 03:02 | <zewt> | (youtube used to allow buffering whole videos; now once it buffers some amount into the future it stops buffering, which doesn't actually work) |
| 03:33 | <tantek> | oh *that* problem. yeah I've seen the problem zewt is talking about as well. |
| 03:34 | <tantek> | happens with either Flash *or* "HTML5" video |
| 03:35 | <tantek> | I've developed this habit of, start Youtube video, immediately hit pause to let it buffer for a while, and then when I remember to get back to it, start playing it. So yeah, something broke for slow(er) connections in the past few months. I don't watch much video on YouTube so I haven't bothered reporting it. |
| 03:35 | <tantek> | I can try a few videos (movie trailers are a good test case) when I get back to a DSL connection and provide URLs then. |
| 10:10 | <annevk> | jamesr: indeed (re public-webapps) TR/ of Fetch doesn't define referrer source either |
| 10:16 | <SimonSapin> | annevk: is it ok to steal the whatwg stylesheet for http://simonsapin.github.com/data-urls/ ? |
| 10:21 | <annevk> | SimonSapin: I certainly used it myself without asking for all kinds of things |
| 10:23 | <annevk> | Hixie: "Browsers won't let you nest iframes that point to ancestors." The only interesting case here might be paths that differ only in percent escaping; e.g. %41 vs A or %7F vs %7f |
| 10:26 | <annevk> | Oh, in WebKit DocumentFragment insertion is still not atomic? https://bugs.webkit.org/show_bug.cgi?id=91460 |
| 10:28 | <SimonSapin> | Looks much better: http://simonsapin.github.com/data-urls/ |
| 10:28 | <SimonSapin> | and has the appropriate amount of red |
| 10:34 | <annevk> | nice |
| 15:12 | <zewt> | In the proposed version, I've changed the links to the following specs: - [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest W3C TR doc. - [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the latest W3C TR doc. |
| 15:12 | <zewt> | ^ don't know who this guy is, but the above tells me he should never ever be editing specs |
| 15:14 | <zewt> | don't even know why i'm glancing at these threads, heh |
| 15:14 | <zewt> | guess it's the car crash principle |
| 15:30 | <Ms2ger> | zewt, to be fair, it's apparently plh's fault |
| 18:38 | manu1 | wonders if there is a canonical form for HTML5? Something like Exclusive XML Canonicalization Version 1.0? |
| 18:42 | <tantek> | manu1 - there's the output of the parsing algorithm |
| 18:44 | <Philip`> | manu1: You could use the HTML fragment serialization algorithm with some extra constraint on the ordering of attributes, if you want a string representation and don't care about not being able to represent all possible (or even all conforming) DOMs, I guess |
| 18:44 | <Hixie> | annevk: yeah in the diff i mention that this is post-url-parsing/resolution so hopefully that matches what browsers do (in particular, you canonicalise the case of the scheme and host tokens, right?) |
| 18:44 | <manu1> | tantek: If two different implementations implement the parsing algorithm correctly, and serialize the result of the parsing algorithm to a string, are both strings guaranteed to be equivalent? (for example, if you wanted to create a digital signature of a serialized HTML5 string, could you do it via two different implementations of the HTML5 spec)? |
| 18:44 | <Hixie> | Philip`: just use xml c14n and xhtml |
| 18:46 | <manu1> | Hixie, Philip`, tantek: This is for the HTMLLiteral stuff that the RDF WG just created - they want a native RDF datatype for HTML Literals (as opposed to XML Literals)... and I'm trying to figure out if there is a way of deterministically generating a string that expresses such a thing (like there is for XML C14N) |
| 18:47 | <Hixie> | ain't no such thing as an html fragment, so... |
| 18:47 | <manu1> | It would be fine to say that there is no canonical form for an HTMLLiteral... but some of the more pedantic people would be upset by that, I imagine. |
| 18:47 | <Hixie> | there's no form at all, let alone canonical |
| 18:47 | <Hixie> | so the pedantic people would be already having all kinds of trouble |
| 18:48 | <manu1> | right, that's the conclusion I came to from reading various parts of the HTML5 spec. |
| 18:49 | <manu1> | k, thx Hixie, tantek, Philip` - I'll try to do something sane that doesn't cause the RDF WG to flip out. |
| 18:49 | <Hixie> | (for example, there's no way to even know what namespace a fragment like "<a/>x" should result in, or whether it should be an element node with a child text node or a sibling text node) |
| 18:49 | <tantek> | I don't know Hixie, the HTML5 spec is quite detailed, something I think pedantic people would very much appreciate. ;) |
| 19:02 | <zewt> | bleh, how is it that there are no numeric comparison operators in CSS selectors |
| 19:08 | <tantek> | like :nth-child ? |
| 19:08 | <tantek> | (an+b) and all that |
| 19:08 | <tantek> | what's the use case you're trying to solve? |
| 19:08 | <zewt> | <html data-foo=10> html[data-foo>5] |
| 19:08 | Philip` | wants to be able to select all prime-numbered paragraphs |
| 19:08 | <zewt> | (where it's actually something like the window size, etc) |
| 19:14 | <zewt> | i end up having to precompute all of the comparisons, which works but is pretty lame |
| 19:35 | <tantek> | indeed, I want to do similar things with attributes for values for things like styling barcharts |
| 19:36 | <tantek> | I think the answer to your original questions about (lack of existence) is, 1. there hasn't been well documented use cases (a few lines on IRC is a good start, but a wiki page would be nicer), and 2. we haven't figured out a good way to do so in CSS selector syntax. |
| 19:36 | <tantek> | I think if you work on *either* of those, you would increase the chances of such CSS selectors being created |
| 19:37 | <tantek> | as I think there would be others (myself included) interested in helping such a proposal along in CSSWG. I can see TabAtkins being interested too. |
| 19:57 | <SimonSapin> | zewt, tantek: I could be interested in making this happen too |
| 20:50 | <SimonSapin> | TabAtkins: you need to update your scripts: http://dev.w3.org/csswg/css3-cascade/ |
| 20:51 | <SimonSapin> | http://dvcs.w3.org/hg/csswg/rev/692c54ee5a46 |
| 20:59 | <Hixie> | can someone with IE load up http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1974 then hit the submit button and tell me what it says in the log? |
| 21:40 | <Velmont> | So, doing some web developer stuff. Coded after specs, works in Opera. Testing in fx and chrome, oh-noes, it doesn't work. Grr. Feeling the angry webdev wrath :P |
| 21:41 | <SimonSapin> | Velmont: I can’t believe that would happen ;) |
| 21:43 | <Velmont> | SimonSapin: So I have to go through and debug what standard-features they don't support. :] Kinda looking forward to testing IE10 tomorrow, I actually think it'll work there. |
| 22:30 | <annevk> | Hixie: the plan is to do host normalisation, but I don't know what type yet because browser vendors cannot make up their mind |
| 22:31 | <annevk> | Hixie: but yes, the parser normalises URLs insofar browsers normalise URLs, I might define some additional normalisation/comparison algorithms for use in the API |
| 22:31 | <annevk> | (input on which would be much appreciated) |
| 22:32 | <Hixie> | lgtm |
| 22:52 | <annevk> | Ms2ger: fwiw, plh has done the blocking references thing to WHATWG drafts since forever |
| 22:55 | <annevk> | Ms2ger: though changing things to link to TR/ is just plain moronic |
| 22:55 | <annevk> | Ms2ger: I doubt they realize that means things like ByteString are not defined... |
| 22:56 | <annevk> | Though thinking about it I guess it's not too different from the stuff they're doing with what they call HTML5. Monkey patching something they don't really comprehend. |
| 22:57 | <Hixie> | annevk: yeah i love how it is actually breaking the specs to do that these days |
| 22:57 | <Hixie> | annevk: so stupid |
| 23:05 | <zewt> | sure is fun to be telling people over and over "never ever look at TR pages" while having idiots like that actively working to confuse people |
| 23:09 | <annevk> | Yeah I don't quite understand the deal and how this is different from the deal I offered Jeff Jaffe where I would push out a W3C TR/ copy with their copyright attached it as long as I could also publish it in CC0 at the WHATWG. |
| 23:10 | <annevk> | In fact, this seems to be worse for them as their copy ends up looking much worse because of all the attribution thingies attached to it and it's out of date and incorrect. |
| 23:30 | <nessy> | annevk: FWIW I would love to be able to point to updated TR copies at the W3C instead of stale ones |
| 23:33 | <annevk> | Don't tell me, tell the W3C. |
| 23:40 | <annevk> | Hixie: btw, I got feedback about http://wiki.whatwg.org/wiki/MetaExtensions being confusing. In particular the "Status" column, which appears to be useless because of the separate tables, should probably be removed. |
| 23:42 | <annevk> | Hixie: also under http://wiki.whatwg.org/wiki/MetaExtensions#Failed_Proposals it seems "Brief description" is actually the reason it failed |
| 23:43 | <annevk> | Hixie: I did not change the structure of things because the HTML spec talks about it, so I wanted to hear what you thought first |
| 23:47 | <nessy> | annevk: :-) |