| 00:06 | <Hixie> | i really can't see how to make CONNECT work as a handshake |
| 00:07 | <Hixie> | (not if we simultaneously try to not violate HTTP) |
| 00:09 | <othermaciej> | how would a CONNECT handshake violate HTTP? |
| 00:10 | <othermaciej> | is it forbidden to send a CONNECT request to an origin server? |
| 00:11 | <Hixie> | no |
| 00:12 | <Hixie> | the problem is the response |
| 00:12 | <Hixie> | it consists of an entire 2xx response before the pip is established |
| 00:12 | <Hixie> | pipe |
| 00:12 | <Hixie> | so basically we're opening a massive hole right at the head of the connection |
| 00:13 | <othermaciej> | you could do the Adam-style handshake after the connection is established |
| 00:13 | <Hixie> | yeah i guess we'd have to |
| 00:13 | <othermaciej> | unless there is some chance that the CONNECT request itself will completely own the server |
| 00:13 | <Hixie> | oh i missed your response to that question i asked the other day, btw, i was meeting with one of the hybi chairs |
| 00:14 | <othermaciej> | I do think the Adam-style handshake is more complicated than necessary for its own security |
| 00:14 | <othermaciej> | or at least, his original version |
| 00:14 | <Hixie> | yeah i don't see why we need to encrypt any useful data |
| 00:14 | <othermaciej> | there's no need for the server to generate its own entropy |
| 00:14 | <Hixie> | can't we just include a challenge of the form "here's 16 bytes, return them x'ored with each other"? |
| 00:15 | <Hixie> | s/'// |
| 00:15 | <othermaciej> | there's a couple of issues with that |
| 00:15 | <othermaciej> | 1) doesn't increase the likelihood that the server will pay attention to the client's Origin |
| 00:16 | <othermaciej> | 2) no way to differentiate from future protocols using the same approach |
| 00:16 | <Hixie> | if the server doesn't pay attention to the origin, he'll include a hard-coded value, which is fine, no? |
| 00:17 | <othermaciej> | 3) required useful data ("this is WebSocket", "here's the Origin") would have to go in a separate response, increasing the number of round trips |
| 00:17 | <Hixie> | i don't see how we can do anything that reduces the chances of a server just echoing the origin when they should check it |
| 00:17 | <othermaciej> | well let me put it this way |
| 00:17 | <Hixie> | i don't follow #3 |
| 00:17 | <othermaciej> | what do you expect to be in the handshake besides those 16 bytes, if anything? |
| 00:18 | <othermaciej> | Adam's goal was that the whole handshake looks like random bytes if you don't understand it, and thus is highly unlikely to have a specific bad effect on servers |
| 00:18 | <Hixie> | yeah well given that the start of the handshake is a CONNECT, there's zero chance of that |
| 00:18 | <Hixie> | so i kinda gave up with that goal |
| 00:18 | <Hixie> | i guess if we want to do it we still can though |
| 00:20 | <othermaciej> | yeah I don't know how meaningful it is to do the Adam handshake after a CONNECT |
| 00:20 | <othermaciej> | I mean, probably somewhat meaningful just less so |
| 00:21 | <othermaciej> | there are a few ways I can think of to simplify server-side implementation of Adam's design without reducing the security: |
| 00:21 | <othermaciej> | 1) Have the client use a one-time pad as its crypto (i.e. XOR with an equally long key) |
| 00:22 | <othermaciej> | 2) have the server respond with a hash of the client's key and the client's plaintext (perhaps reodering the parts) |
| 00:22 | <othermaciej> | it doesn't even have to be a cryptographically secure hash, could even be CRC, you just want a hash value that's too long to get the right value by chance |
| 00:23 | <othermaciej> | though I suspect MD5 is more widely available in library form than most simpler hashes with a decent output size |
| 00:23 | <othermaciej> | that removes the server's needs to use a fancy algorithm to decrypt, to produce random bits, and to use a fancy algorithm to encrypt again |
| 00:25 | <Hixie> | we can get rid of the need for a library altogether just by having the server xor parts of the key together |
| 00:25 | <Hixie> | e.g. xor bytes 1,2,3,4 with bytes 5,6,7,8 |
| 00:25 | <Hixie> | also making the key the right length is easy if you just interleave each byte of the key with the byte of data it's been xored with |
| 00:26 | <Hixie> | e.g. ABC becomes [k1][k1 xor A][k2][k2 xor B][k3][k3 xor C] |
| 00:26 | <Hixie> | and the server's nonce can then just be [k1 xor k2][k3 xor k4]...[k8 xor k16] or something |
| 00:34 | <NickYoung> | I hope this isn't supposed to be cryptographically secure.. |
| 00:34 | <NickYoung> | the security guy in me is seeing the next WEP being created... |
| 00:35 | <othermaciej> | I think making the server xor random bytes is probably more of a burden on the server than telling the server to use MD5 |
| 00:35 | <othermaciej> | NickYoung: it's not supposed to be cryptographically secure |
| 00:35 | <NickYoung> | Oh good ;) |
| 00:35 | <NickYoung> | also, I disagree with your assertion.. XOR is a single cycle operation |
| 00:36 | <NickYoung> | even if you have 20 of them, it will be many thousands times faster than MD5 |
| 00:36 | <othermaciej> | NickYoung: by "burden" I mean difficulty of implementation, not CPU cost of doing the computation |
| 00:36 | <NickYoung> | seriously, bitwise -or is difficult to implement? =P |
| 00:37 | <othermaciej> | if you invent a funky custom algorithm then the server can't use a pre-existing library |
| 00:37 | <NickYoung> | from what I read, you're just XORing a few bytes... |
| 00:38 | <othermaciej> | yeah, the tricky part is which bytes |
| 00:38 | <othermaciej> | you have to hand-code a loop to do it and have it step in the right increments |
| 00:38 | <othermaciej> | and the reason Hixie wants to do that is because calling a library function to do MD5 or CRC or whatever might be too hard |
| 00:39 | <NickYoung> | what's the point of this anyway, to verify you're speaking the correct protocol..? |
| 00:40 | <othermaciej> | to verify that you are speaking the correct protocol and that the connection is allowed without opening too much opportunity for cross-protocol attacks |
| 00:41 | <NickYoung> | and these 16bits are a nonce? |
| 00:41 | <othermaciej> | Hixie: I think if your key is variable-length then you need to length-prefix or terminator-delimit the client handshake, so the server knows when it got all of it |
| 00:41 | <Hixie> | othermaciej: sure, the last four bytes would decode to CRLFCRLF or some such |
| 00:42 | <othermaciej> | I think it's meant to be 16 bytes, a 16-bit nonce would be pretty weak |
| 00:42 | <NickYoung> | ah, misread |
| 00:42 | <NickYoung> | wait |
| 00:42 | <NickYoung> | 16 bytes? |
| 00:42 | <othermaciej> | Hixie: that would force a requirement to do the "decrypt" operation in streaming mode |
| 00:43 | <othermaciej> | NickYoung: it's really a variable-length number of bytes, since the plaintext client handshake message is not fixed-length |
| 00:43 | <NickYoung> | ah. |
| 00:43 | <Hixie> | othermaciej: yes? the whole protocol is a "streaming-mode" protocol |
| 00:43 | <othermaciej> | Hixie: as opposed to "read known length or up to delimiter and then process" |
| 00:44 | <othermaciej> | which is how HTTP headers and WebSocket messages are both handled |
| 00:44 | <othermaciej> | there is no need to process every single byte to even find the message boundaries |
| 00:45 | <othermaciej> | the point is, what you're proposing is not easier to implement than even Adam's original version, given a reasonable set of available libraries |
| 00:45 | <othermaciej> | it is in fact harder |
| 00:45 | <othermaciej> | and people could easily get it wrong in subtle ways, e.g. not expect the client handshake to be split in the middle, or to be split on an odd byte |
| 00:46 | <Hixie> | i don't mind have a non-encrypted delimiter if you like |
| 00:46 | <othermaciej> | I would say it's far better to use well-known algorithms than some weird ad-hoc thing if your goal is to make it easy on custom server implementations |
| 00:46 | <othermaciej> | I don't think the delimiter is the biggest problem with your proposal |
| 00:47 | <Hixie> | we could even just define the key characters for the last four bytes so that you can do the delimiter check in either mode |
| 00:47 | <othermaciej> | "run around XORing random bytes together" is not a trivial operation |
| 00:47 | <Hixie> | i can't think of a single language i've ever used where it's been anything _but_ trivial |
| 00:47 | <othermaciej> | most people who interview with the Safari team would probably fail if presented that problem as an interview question (not that we hire them, but lots of these people think they know how to code) |
| 00:50 | <Hixie> | i don't understand the problem here. read byte; if (needkey) key = byte else append(byte xor key); needkey = !needkey; |
| 00:50 | <Hixie> | it seems truly trivial |
| 00:51 | <Hixie> | am i missing something? |
| 00:51 | <othermaciej> | you're missing the loop, the code to detect the terminators, and the code to output the response |
| 00:52 | <Hixie> | right, you need those regardless of what we do here |
| 00:52 | <othermaciej> | also you're not accounting for the fact that the read is asynchronous |
| 00:52 | <othermaciej> | s/output/compute/ |
| 00:52 | <Hixie> | i'm assuming the above is the code you stick in the select() loop for the socket |
| 00:53 | <othermaciej> | the hypothetical naiive server-side programmer is using select with raw sockets instead of something like Twisted? |
| 00:53 | <othermaciej> | this hypothetical person must really hate using libraries |
| 00:54 | <TabAtkins> | Hypothetical people do, as a rule. |
| 00:54 | <Hixie> | i'm baffled as to why you would use a library for something this simple personally |
| 00:56 | <othermaciej> | Adam |
| 00:56 | <othermaciej> | er |
| 00:56 | <othermaciej> | Adam |
| 00:57 | <othermaciej> | dammit, why must enter be so close to the quote key |
| 00:57 | <othermaciej> | Adam's original version also has the problem that it's variable-length but neither length-prefixed nor delimited |
| 00:58 | <boblet> | Hixie: did you see the HTML5 & APIs book that is just coming out in Japan? |
| 00:58 | <othermaciej> | in his case the key is fixed-length, so you could just keep decrypting til it works, but that is lame |
| 00:58 | <Hixie> | boblet: didn't see it, but mike told me about it |
| 00:58 | <Hixie> | othermaciej: i'm happy to delimit it |
| 00:58 | <boblet> | http://www.amazon.co.jp/dp/4822284220/ |
| 00:59 | <boblet> | Mike was encouraging Shiraishi-san to send you a copy, so you might be able to see it in the flesh :) |
| 00:59 | <othermaciej> | Hixie: I can't tell up front what a good delimiter would be |
| 01:00 | <othermaciej> | Hixie: btw your code, despite doing only a small fraction of the work, has an obvious bug |
| 01:00 | <othermaciej> | Hixie: it doesn't save the key bytes, which per your definition are used to compute the server response |
| 01:00 | <othermaciej> | (I'm also not clear on why the server response depends only on the key and not the plaintext in your proposal) |
| 01:01 | <Hixie> | yeah, i wasn't sure what to do about that sicne you didn't like the proposal of using hte key |
| 01:01 | <Hixie> | i would use this as the delimiter, so you could detect it in either implementation style (before or after decrypting): 0x00 0x0D 0x00 0x0A 0x00 0x0D 0x00 0x0A |
| 01:01 | <boblet> | Futomi-san (of http://html5.jp/ fame) also has a book in the pipeline: http://www.amazon.co.jp/dp/4798025291/ It’s a hot topic over here |
| 01:02 | <Hixie> | (maybe we should just use LF line endings in this, since we don't have to be HTTP-compatible) |
| 01:03 | <othermaciej> | boblet: people are probably more excited in Japan because they can't follow the mailing list flamewars |
| 01:03 | <Hixie> | hah |
| 01:03 | <boblet> | othermaciej: zing! |
| 01:04 | <boblet> | yeah, info about it comes prefiltered so ppl here miss out on that and the FUD too |
| 01:04 | <othermaciej> | Hixie: I dunno if you come up with a complete proposal I can analyze it (and I'm sure Adam would be willing to as well) |
| 01:05 | <othermaciej> | too hard to review an emerging design over IRC |
| 01:05 | <Hixie> | yeah, i'm poking at one |
| 01:06 | <othermaciej> | I do think that even though this doesn't have to be cryptographically secure, it would be wiser to use off-the-shelf algorithms, because the first rule of crypto club is "don't invent your own algorithms" |
| 01:06 | <Hixie> | the idea of the nonce coming back from the server is to have the server include something in the response that's verifiable (showing the server knows the protocol) and yet not predictable without controlling the client's handshake, right? |
| 01:06 | <othermaciej> | yes |
| 01:06 | <Hixie> | a one time pad isn't a new invention |
| 01:06 | <othermaciej> | I think a one-time pad for the client request is fine |
| 01:06 | <Hixie> | oh for the response, yeah |
| 01:07 | <othermaciej> | (given a suitable way to mark the boundary) |
| 01:08 | <othermaciej> | ideally I think the response would use an algorithm that doesn't require the server to generate a random number, which is why I thought of hashing instead of encryption |
| 01:08 | <Hixie> | yeah |
| 01:08 | <Hixie> | totally agreed on that |
| 01:09 | <othermaciej> | one more thing I thought of, you can't use a fixed set of bytes as a delimiter without forcing some kind of escapting |
| 01:10 | <othermaciej> | oh, I guess the idea of 0x0 0xD is supposed to be that the plaintext request can't contain byte 0xD, but that's pretty subtle |
| 01:11 | <othermaciej> | I can't think of a good simple way to encode the length without violating the "it looks like random bytes" property |
| 01:17 | <othermaciej> | Hixie: btw have you had a chance to look at the Change Proposal that the i18n people came up with for ISSUE-88? would it be helpful if someone extracted out the requests there that still differ from the spec? |
| 01:30 | <Hixie> | link? |
| 01:31 | <Hixie> | the answer is probably no |
| 01:31 | <Hixie> | because in the last week i've only done bugs and websocket feedback |
| 01:32 | <Hixie> | oh this one? http://www.w3.org/International/wiki/Htmlissue88 |
| 01:35 | <Waldo_> | othermaciej:erm, do you happen to know why the jwalden nick I usually use is banned in #webkit? was my connection flaky recently or something? |
| 01:36 | <othermaciej> | Waldo_: banned? |
| 01:36 | <othermaciej> | as in, you can't enter the channel, or you can't speak? |
| 01:36 | <Waldo_> | "=== jwalden #webkit Cannot change nickname while banned on channel" |
| 01:36 | <Waldo_> | that's as much as I know, when I try /nick jwalden |
| 01:36 | <othermaciej> | no idea |
| 01:36 | <gavin> | your nick isn't registered? |
| 01:36 | <gavin> | or you aren't identified |
| 01:37 | <othermaciej> | there's only one other person who has channel ownership |
| 01:37 | <Waldo_> | no, this is when I try to change nick right now |
| 01:37 | <gavin> | oh |
| 01:37 | <gavin> | Waldo_ isn't identified |
| 01:37 | <othermaciej> | I can probably unban you but my IRC mojo is weak |
| 01:37 | <gavin> | so you can't change his nick |
| 01:37 | <Waldo_> | well, sure |
| 01:37 | <gavin> | because webkit is +R |
| 01:37 | <Waldo_> | you identify after you change nick |
| 01:37 | <gavin> | part webkit, change nick, identify, rejoin |
| 01:38 | <jwalden> | hum, that worked |
| 01:38 | <jwalden> | sorry for the trouble... |
| 01:38 | <Hixie> | the bans in #webkit are: |
| 01:38 | <Hixie> | 02:43 -!- 1 - #webkit: ban *!*jibot⊙621* [by zelazny.freenode.net, 1910310 secs ago] |
| 01:38 | <Hixie> | 02:43 -!- 2 - #webkit: ban *!*onar@*.hsd1.ca.comcast.net [by zelazny.freenode.net, 1910310 secs ago] |
| 01:38 | <Hixie> | looks like someone using comcast was banned |
| 01:38 | <Hixie> | and the server won't let you change nicks while that's going on |
| 01:38 | <gavin> | no no, this is just a quiet ban |
| 01:38 | <gavin> | +q $~a |
| 01:38 | <gavin> | applies to all unregistered nicks |
| 01:39 | <gavin> | (/mode +q #webkit) |
| 01:39 | <jwalden> | chatzilla could use a better error message here, if the protocol permits one to be used |
| 01:39 | <jwalden> | or rather, allows the situation to be identified |
| 01:39 | <othermaciej> | that would stop people from talking but not from entering the channel, right? |
| 01:39 | <gavin> | right |
| 01:39 | <gavin> | unregistered users can currently join but not speak in #webkit |
| 01:40 | <gavin> | |/mode -q $~a #webkit| if you want to remove that restriction |
| 01:40 | <gavin> | er, or maybe |/mode #webkit -q $~a| |
| 01:53 | <JonathanNeal_oww> | Hey guys! |
| 01:54 | <JonathanNeal> | I heard some great questions about HTML5 today and I thought I would share them with the group and get your reactions. |
| 01:55 | <JonathanNeal> | Accessibility: What is the benefit to accessibility with HTML5? Do existing and popular screen-readers have an easier or harder time understanding HTML5 tags? How do they parse the content in IE when they run into an unknown tag? |
| 01:57 | <Hixie> | HTML5 improves matters for accessibility, though the various and sundry ways it does that are numerous and difficult to summarise |
| 01:58 | <JonathanNeal> | Hixie, can any of them be mentions or written? |
| 01:58 | <JonathanNeal> | Are they listed on the web? |
| 01:58 | <JonathanNeal> | Or is it theory. |
| 01:59 | <boblet> | JonathanNeal: one of the big accessibility improvements is moving a11y stuff from hidden locations (like attributes) to visible locations (like content), so they’re available to everyone, and also to give authors a reason to add them |
| 02:01 | <boblet> | an example of this is the great table summary vs caption wars |
| 02:01 | <boblet> | http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#attr-table-summary |
| 02:01 | <boblet> | another is the ongoing longdesc battle |
| 02:03 | <JonathanNeal> | HTML5 Accessibility can be measured in battles. |
| 02:04 | <Hixie> | JonathanNeal: hidden="", the new <input type>s, removing features that were harming accessibility due to widespread misuse, removing all media-specific presentational features in favour of CSS, making many of the features more explicitly media-independent, etc |
| 02:05 | <Hixie> | othermaciej: i replied to the issue-88 stuff |
| 02:06 | <JonathanNeal> | making many of the features more explicitly media-independent, you mean like the presentational to css stuff? |
| 02:07 | <othermaciej> | Hixie: thanks |
| 02:08 | <Hixie> | JonathanNeal: i mean like <hr> being redefined to have nothing to do with horizontal rules specifically |
| 02:08 | <Hixie> | or <b> and <i> being redefined to make sense in all media, not just visual media |
| 02:08 | <boblet> | JonathanNeal: eg em = emphasis to stress emphasis, kbd = keyboard to keyboard and other eg voice input (ie has explicit aural ref plus less UA-specific) |
| 02:10 | <boblet> | JonathanNeal: re accessibility battles, it’s a topic on which many people have strongly held and conflicting beliefs :| |
| 02:11 | <othermaciej> | I think the best features for accessibility are the new controls (both form controls and things that don't participate in form submission but resemble standard application widgets) |
| 02:11 | <othermaciej> | because now people won't need to use <div> soup to build those controls |
| 02:11 | <JonathanNeal> | This is a fun discussion. |
| 02:15 | <boblet> | also once UAs (and authors) start using semantic structural elements (nav especially) it’ll make things way more accessible |
| 02:16 | <JonathanNeal> | Should I continue the dialog? |
| 02:16 | <JonathanNeal> | Google and the world of search: |
| 02:17 | <JonathanNeal> | Is there an SEO benefit to HTML5? Is there one now, or will there be one? Does Google favor HTML5 markup, over HTML4 markup, or XHTML markup? Does any search engine (such as Bing, Yahoo, etc)? |
| 02:18 | <Hixie> | no SEO benefit |
| 02:18 | <Hixie> | just make your content useful |
| 02:18 | <Hixie> | you'll have much more luck with making your content have high rank in google if you make it something people want, than if you spend the same time trying to do markup tricks |
| 02:20 | <JonathanNeal> | Fair enough, boblet or othermaciej feel free to jump in on that one if you think differently, otherwise I'll move on. |
| 02:20 | <JonathanNeal> | Final section, The Browser Effect: |
| 02:21 | <boblet> | although I think it’s fair to say that using good markup will help make the content accessible to people. i suspect there is some search engine benefit to using good markup over tag soup |
| 02:21 | <JonathanNeal> | How will HTML5 impact browser performance? CSS3 selectors have a quantifiable impact on performance, but do HTML5 tags have any impact on rendering performance? What about in IE; what is the performance impact (in ms and possibly in MB) on having to create the elements via JS on every page load? |
| 02:22 | <boblet> | eg Google Lists(?) probably won’t include a list marked up using <p> with <br> in it’s list of related entries suggestions |
| 02:23 | <boblet> | I think POSH (plain old semantic HTML) is probably good SEO for free |
| 02:24 | <othermaciej> | I don't know anything about what search engine algorithms do |
| 02:24 | <othermaciej> | you would have to ask them |
| 02:25 | <boblet> | JonathanNeal: i don’t know of any performance impact, and typically something like 90% of the time is spent getting the file (vs processing), so any change on processing will probably be small |
| 02:25 | <othermaciej> | HTML5 will probably improve performance in the case where you can use a native HTML5 feature instead of rolling your own with DIV+CSS+JS |
| 02:26 | <boblet> | re: IE HTML5 shiv, the JS itself is tiny, and the performance overhead of creating new elements before being able to use them should be tiny compared to something like using jQuery. in current browsers I wouldn’t expect HTML5 (over HTML4 etc) to make a noticeable difference |
| 02:27 | <othermaciej> | also using the <video> element may be higher performance than plugin-based video solutions |
| 02:27 | <othermaciej> | it really shouldn't make much difference either way in most cases |
| 02:28 | <boblet> | JonathanNeal: if you’re worried about performance use YSlow and Smushit—your HTML |
| 02:29 | <boblet> | —HTML differences are tiny compared to image minification and reducing requests |
| 02:29 | <othermaciej> | appcache is an HTML5 feature that can significantly improve load performance (past the first time) |
| 02:31 | <boblet> | Hixie: the “submit review comment” help message should probably mention that you can receive a reply if you use the same email as bugzilla |
| 02:31 | <boblet> | also it munges non-ascii characters |
| 02:33 | <JonathanNeal> | All of what you guys have said is great, but is there any measurable, documented proof? |
| 02:33 | <JonathanNeal> | Or is there a way you would recommend I make one, such as with yslow, etc? |
| 02:34 | <othermaciej> | what are you looking for proof of? |
| 02:34 | <othermaciej> | "how will HTML5 impact browser performace?" is a very open-ended question |
| 02:34 | <othermaciej> | if you formulate a specific hypothesis we can tell you ways to test |
| 02:35 | <JonathanNeal> | "Do HTML5 tags have any impact on rendering performance?" |
| 02:35 | <othermaciej> | if the question is about using HTML5 at all, without using any new features, you could try the same page with HTML4.01 and HTML5 doctypes to see if there is any difference in load speed (there won't be) |
| 02:36 | <othermaciej> | if you want to see if enabling IE to use the new tags compatibly impacts load time in IE, you can test load times in IE of a page with and without |
| 02:36 | <JonathanNeal> | How would you test those load times in IE? |
| 02:36 | <othermaciej> | if you want to see if appcache improves cached-case load speed, then that would be a more challenging experiment (to set up the app cache manifest properly etc) but still doable |
| 02:37 | <othermaciej> | you could use a stopwatch |
| 02:37 | <othermaciej> | or if you want to ignore network load time, instrument the page with a <script> to save the current time at the very top of the page (right inside <head> I guess) and then check in the "load" listener how much time elapsed |
| 02:37 | <othermaciej> | benchmarking is hard |
| 02:37 | <othermaciej> | if you want data and not just educated guesses, it will take some work |
| 02:38 | <boblet> | JonathanNeal: there’s a hardcore performance tool for IE that I saw mentioned on John Resig’s blog |
| 02:38 | <boblet> | http://ejohn.org/blog/deep-tracing-of-internet-explorer/ |
| 02:38 | <boblet> | dynaTrace Ajax |
| 02:39 | <boblet> | there’s a similar extension for Google Chrome called Speed Tracer: |
| 02:39 | <boblet> | http://code.google.com/webtoolkit/speedtracer/ |
| 02:40 | <boblet> | please publish any testing you do btw |
| 02:44 | <JonathanNeal> | Freaking Ajax tool requires registration and doesn't immediately send out the registration email. |
| 02:44 | <JonathanNeal> | If you want to collect info about who is using your product, don't make it so damn hard to get. |
| 02:45 | <JonathanNeal> | I'm referring to dynaTrace AJAX |
| 02:55 | <JonathanNeal> | I'm tweeting how much these guys suck for that. |
| 02:55 | <JonathanNeal> | That's bull when companys do this. |
| 02:55 | <JonathanNeal> | *ies |
| 02:59 | <boblet> | JonathanNeal: so you’re thinking to test it? |
| 03:07 | <JonathanNeal> | I'm trying to. |
| 03:07 | <JonathanNeal> | boblet |
| 03:08 | <boblet> | JonathanNeal: if you have any success (and remember to) please ping me @boblet on twitter. I’d love to hear about it |
| 03:10 | <JonathanNeal> | boblet: http://twitter.com/jon_neal |
| 03:11 | <JonathanNeal> | I'll let you know on here or tweet it once I've gotten the software and had a successful test (which proves either case) |
| 03:12 | <boblet> | that’d be great! |
| 05:29 | <JonathanNeal> | Well, I made a test. |
| 05:30 | <JonathanNeal> | Afte running several tests, each test running itself 100,000 times... |
| 05:31 | <JonathanNeal> | The average time it takes for JS to add support for styled HTML5 elements in IE6 browsers is from 0.01ms in native IE6 to 0.05ms in emulated IE6, with a 0.000497ms descrepency caused by the test itself. |
| 06:21 | <MikeSmith> | I see some mentions of an open letter from the FSF to Google about free-licensing On2 video codecs |
| 06:22 | <MikeSmith> | wondering where the actual FSF communiqué is |
| 06:23 | <MikeSmith> | .me finds http://www.fsf.org/blogs/community/google-free-on2-vp8-for-youtube |
| 06:24 | <MikeSmith> | hmm, this looks more like just the case of one dude who has blogging perms at http://www.fsf.org/blogs/community/ deciding to post about it |
| 06:24 | <gavin> | Google was going to release On2, but are reconsidering the decision now that the FSF thinks it's a good idea |
| 06:24 | <gavin> | er, s/On2/VP8/ |
| 06:25 | <MikeSmith> | heh |
| 06:25 | <MikeSmith> | <snort> |
| 06:26 | <MikeSmith> | yeah, that would seem to be a good idea in general for reconsidering any decision that would otherwise be obviously beneficial |
| 06:27 | <MikeSmith> | btw, about #webkit not allowing nick changes, I started to have that problem, fairly recently |
| 06:27 | <MikeSmith> | like, within the last 3 or 4 weeks or so |
| 06:27 | <MikeSmith> | and I also get the same message about being "banned" |
| 06:27 | <gavin> | that's when the freenode spamming started |
| 06:27 | <MikeSmith> | ah |
| 06:28 | <gavin> | and channels started all going +R (registered users only) |
| 06:28 | <gavin> | then the ircd switchover happened, and some channels are still +q $~a (the new +R) |
| 06:28 | <gavin> | they should probably remove it now that the spamming has mostly stopped, but othermaciej doesn't seem keen on the idea |
| 06:29 | <MikeSmith> | so if I register my other nicks, maybe that will let me change them when I need to |
| 06:32 | <MikeSmithX> | "You are already logged in as MikeSmith." "Use GROUP to register MikeSmithX to your account." .. "group :Unknown command" |
| 06:33 | <MikeSmithX> | d'oh, "/nickserv group".. |
| 07:00 | <fantasai_> | n/lastlog fantasai |
| 07:18 | <JonathanNeal> | Any editors in the house? |
| 07:18 | <JonathanNeal> | I mean ... like to review an email I'm sending to the co in support of HTML5. |
| 07:20 | <annevk> | boblet, would be nice if someone translated that filtered info back again so I could miss out on the bs too :) |
| 07:20 | <annevk> | (re: some hours ago) |
| 07:21 | <MikeSmith> | http://cristianadam.blogspot.com/2010/02/ie-tag-take-two.html .. 'To enable <video> tag for Internet Explorer you need to add xmlns="http://www.w3.org/1999/xhtml/video"; attribute' |
| 08:07 | hsivonen | cann't get to work due to a lock malfunction |
| 08:07 | <hsivonen> | it's interesting to see how little documentation one needs to convince a locksmith to come over |
| 08:09 | <hsivonen> | anyway, nice to see that Adam wrote a counter-proposal to Larry's |
| 08:09 | <hsivonen> | now I don't have to |
| 08:10 | <MikeSmith> | hsivonen: you should send a +1 at least |
| 08:10 | <boblet> | annevk: well, just ignore everything but the spec, and you’ll be about there ;-) |
| 08:12 | <boblet> | JonathanNeal: so the shiv to addHTML5 support adds 0.04ms to IE6’s page load? that’s … acceptable, hehe |
| 08:12 | <hsivonen> | MikeSmith: ok. I'll express my support to zero edits |
| 08:13 | <hsivonen> | I note that the TAG as a whole has been unwilling to support the doctype versioning change proposal |
| 08:45 | <Hixie> | othermaciej: you know, it strikes me that if we just include some data in the encrypted part, then just repeating that information (unencrypted) is actually proof enough that the server is reading the handshake |
| 08:46 | <annevk> | Hixie, wasn't the concern with that simple echo thingies? |
| 08:49 | <Hixie> | well they'd have to decrypt it |
| 08:49 | <Hixie> | which is easy enough, but won't happen unless you really are a websocket server |
| 08:54 | <othermaciej> | Hixie: you would need to make sure that part of what they echo back is unpredictable |
| 08:54 | <Hixie> | right |
| 08:54 | <othermaciej> | ideally you want at least one thing to be both unpredictable *and* not verbatim |
| 08:55 | <Hixie> | well it wouldn't be verbatim, since it'd be encrypted |
| 08:55 | <othermaciej> | but the data XOR'd with the one-time pad key is all predictable |
| 08:55 | <annevk> | what counts as unpredictable? timestamps? |
| 08:56 | <othermaciej> | the key itself is the only unpredictable part |
| 08:56 | <Hixie> | annevk: random data |
| 08:56 | <Hixie> | othermaciej: i mean, client sends something like Unique-ID: 312524232362435234521, but in the encrypted part, and the server just has to say that back |
| 08:56 | <othermaciej> | annevk: random data generated by the browser after JS code transfers control |
| 08:56 | <Hixie> | othermaciej: but the server's returned data is unencrypted |
| 08:56 | <othermaciej> | Hixie: you could do that - then the client is generating two different random numbers |
| 08:56 | <Hixie> | right |
| 08:57 | <othermaciej> | one to be the encryption key and one to be the nonce |
| 08:57 | <Hixie> | yup |
| 08:57 | <Hixie> | they can be generated from the same single truely random number, it's not like they have to be independent |
| 08:57 | <Hixie> | so it's not an entropy drain |
| 08:58 | <othermaciej> | the other property Adam was trying to guarantee is that both request and response look like random bytes without WebSocket processing but I don't know offhand why it's important |
| 08:58 | <Hixie> | yeah |
| 08:58 | <othermaciej> | Hixie: they do have to be independent, XORing a value with itself won't be very random |
| 08:58 | <annevk> | btw http://lists.w3.org/Archives/Member/process-issues/2010Feb/0006.html (W3C Member-only) |
| 08:58 | <Hixie> | othermaciej: fair enough |
| 09:00 | <Hixie> | annevk: well, i have to say, i can't disagree with anything in that e-mail, but i imagine i'd read between the lines rather differently! |
| 09:01 | <annevk> | uhuh :) |
| 09:01 | othermaciej | facepalms at that message |
| 09:01 | <othermaciej> | also, at the other content of that archive |
| 09:02 | <Hixie> | http://lists.w3.org/Archives/Member/process-issues/2010Feb/0003.html is even more amusing, given the link in that e-mail |
| 09:02 | <Hixie> | especially as the accusation immediately after that link is one i would level at the person writing that e-mail! |
| 09:02 | <Hixie> | anyway |
| 09:20 | <annevk> | http://twitter.com/patrick_h_lauke/status/9436007749 lol |
| 09:58 | <hsivonen> | annevk: thanks for the process-issues URL |
| 09:59 | <Hixie> | right, bed time |
| 09:59 | <Hixie> | nn |
| 10:13 | <MikeSmith> | fwiw, I turned the webkit_commits twitter bot back on |
| 11:45 | <gsnedders> | JonathanNeal: I'm around now |
| 11:45 | <gsnedders> | JonathanNeal: But seeming you said good morning when you pinged me over the weekend at a time four hours later, I guess that's quite uselss |
| 12:04 | Philip` | wonders if updating his canvas tests would be useful |
| 12:07 | <annevk> | yes |
| 12:07 | <annevk> | a) gives some insight how far impls are along b) prolly generates more <canvas> feedback / improvements |
| 12:08 | <Philip`> | I hope there weren't too many features snuck into the spec while I wasn't looking |
| 12:08 | Philip` | completely missed drawFocusRing |
| 12:26 | <othermaciej> | Philip`: yes, and you should submit them for the html5 test suite |
| 12:28 | <Philip`> | (I probably should have said "worthwhile" rather than "useful") |
| 12:41 | <othermaciej> | well, I can't say how it would rate for you against other uses of your time |
| 12:41 | <othermaciej> | it would definitely be of great benefit to others |
| 12:41 | <othermaciej> | I would actually like to put your whole test suite into the WebKit regression tests |
| 12:53 | <MikeSmith> | othermaciej: about 'should longdesc be considered "obsolete but conforming" or just conforming to a warning' |
| 12:54 | <othermaciej> | MikeSmith: yes? |
| 12:54 | <MikeSmith> | what does "just conforming to a warning" mean? |
| 12:54 | <othermaciej> | MikeSmith: it means that it would not be listed in the "obsolete but conforming" section or have that label applied to it, but the practical effect would be the same |
| 12:55 | <MikeSmith> | meaning that conformance checkers would still need to warn about it? |
| 12:55 | <MikeSmith> | it seems like it is effectively creating yet another conformance level |
| 12:56 | <othermaciej> | well, summary is in a gray zone right now where it's not totally clear which of those buckets it falls into |
| 12:56 | <othermaciej> | Cynthia's change proposal for summary would in fact label it as "obsolete but conforming" |
| 12:56 | <othermaciej> | my thinking is we should do the same for longdesc |
| 12:57 | <othermaciej> | I think the effect on validators is pretty much nil, it's just a matter of presentation and spec organization |
| 12:59 | <MikeSmith> | perhaps one possible remedy for this is to not use the word "obsolete" in the name of that section, but categorize them as "Conforming features that have specific caveats" |
| 12:59 | <MikeSmith> | or something else that is more in the sense of "caveat" rather than "obsoleted" |
| 13:00 | <MikeSmith> | the spec could mandate the specific warning messages that conformance checkers should emit for those cases |
| 13:01 | <MikeSmith> | or at least what specific sense the messages should convey |
| 13:02 | <MikeSmith> | e.g., in general, the sense would be "There is evidence to suggest this element is widely misused, therefore, make sure to use it with care." |
| 13:03 | <MikeSmith> | or if not "widely", at least "sometimes" |
| 13:03 | <Philip`> | Every feature of the language is sometimes misused |
| 13:03 | <Dashiva> | I don't think removing the word obsolete will do anything, it will just shift the battle to removing the new language |
| 13:03 | <Philip`> | and everything should be used with care |
| 13:04 | <Dashiva> | "Why does this fully conforming and not obsolete feature need a warning?" |
| 13:04 | <Philip`> | Maybe some need slightly more care than others, so perhaps we could have a care-o-meter that says longdesc rates 80% on the need-to-care index while summary is 70% and <a href> is only 20% |
| 13:05 | <Philip`> | Then we wouldn't have to keep drawing and shifting arbitrary lines between features that are good and features that are bad and features that are sort of in the middle so we'll allow them but complain a bit |
| 13:06 | <Dashiva> | And instead we get bikeshedding over what number to use for each feature |
| 13:07 | <Dashiva> | "Now only 19.95 care" |
| 13:07 | <Philip`> | We could vote and use the mean rating |
| 13:07 | <Dashiva> | Median, surely |
| 13:08 | <MikeSmith> | Dashiva: I think he meant "mean" in the sense of "meanest" |
| 13:08 | <Dashiva> | Or maybe a mix, like removing the top and bottom 10% and doing the mean of the rest |
| 13:08 | <Philip`> | Dashiva: Good point - we should have a vote on what voting mechanisms to use |
| 13:09 | <Dashiva> | How about we just stick to the current categories |
| 13:09 | <Philip`> | Everyone can rate each voting mechanism out of 10, and then we use a weighted sum of all voting mechanisms |
| 13:10 | <MikeSmith> | all smartassery aside, we do really need to get agreement about what the spec should say about these attributes |
| 13:10 | <Dashiva> | There is wide agreement, and a few dissenting voices |
| 13:10 | <Philip`> | Dashiva: If we make enough new categories, then people will be confused into supporting choices that are equivalent to ones they've rejected |
| 13:10 | <Philip`> | (I assume that's the purpose of tweaking the wording of category labels) |
| 13:11 | <MikeSmith> | Dashiva: no, that's not an accurate assessment of the state of things, actually |
| 13:11 | <MikeSmith> | and that's not the basis for making decisions, regardless |
| 13:11 | <MikeSmith> | by anybody's measure |
| 13:12 | <Dashiva> | It's the basis of quite a few systems |
| 13:12 | <MikeSmith> | true, like mob rule |
| 13:13 | <Dashiva> | And, you know, democracy |
| 13:13 | <MikeSmith> | right, what I said |
| 13:13 | <othermaciej> | MikeSmith: the closest equivalent to "Obsolete but conforming" in HTML4 would have been "Deprecated |
| 13:13 | <othermaciej> | MikeSmith: in non-HTML contexts, things that are "deprecated" tend to generate a warning, though I don't think any HTML4 validator ever did that |
| 13:14 | <MikeSmith> | well, HTML4 validator(s) have a lot of deficiencies |
| 13:14 | <MikeSmith> | that was then, this is now |
| 13:14 | <Dashiva> | MikeSmith: We support philosopher kings too, but apparently you don't like that either |
| 13:14 | <MikeSmith> | othermaciej: in my opinion "deprecated" is a fine, accurate way to describe this case |
| 13:15 | <othermaciej> | I think "obsolete but conforming" is also an ok way to describe it |
| 13:15 | <MikeSmith> | yeah, it's just more words |
| 13:15 | <othermaciej> | "You shouldn't be using this any more, but we will grudgingly allow it, for now" |
| 13:15 | <MikeSmith> | yeah, I will conceded it's probably more precise |
| 13:15 | <othermaciej> | I don't really want to open up the can of worms of what that section should be named |
| 13:16 | <othermaciej> | to me that's much less important than the actual real effects |
| 13:16 | <Dashiva> | But none of those wordings actually satisfy the people who want to encourage use of that feature |
| 13:16 | <MikeSmith> | Dashiva: I like philosopher kings pretty well, actually |
| 13:16 | <othermaciej> | I think "Obsolete but conforming" is an improvement over "Downplayed error" |
| 13:16 | <othermaciej> | I would have just said "mandatory warning" or something |
| 13:17 | <MikeSmith> | "downplayed error" is just goofy |
| 13:17 | <othermaciej> | "deprecated" also seems sort of ok, though I think some people don't like that specific word because the way HTML4 handled it seemed to be ineffective in discouraging those features |
| 13:17 | <Dashiva> | deprecated is just wrong |
| 13:17 | <Dashiva> | It implies removing support in a later revision |
| 13:18 | <othermaciej> | I guess that is wrong in two subtle ways: |
| 13:18 | <othermaciej> | 1) we'll likely never remove support, just any semblance of conforming status |
| 13:18 | <othermaciej> | 2) we don't necessarily promise to remove even that |
| 13:22 | <Dashiva> | Most of the cases seem entirely uncontroversial, with summary being quite the exception |
| 13:23 | <Dashiva> | But is there anyone who objects to summary being marked as <whatever> who doesn't also want summary to be fully unconditionally conforming? |
| 13:23 | <othermaciej> | for summary it might cease to be controversial if the Change Proposal currently in development by the a11y tf goes through |
| 14:27 | <TabAtkins> | JonathanNeal: So, effectively zero time to get IE to support the new elements? Fractions of a millisecond are basically free. |
| 14:30 | <Philip`> | http://www.austriantrade.nl/awo-marktplatz/awoCompanySearch.do?selectedId=4006&editable=false&action=Details&language=en&country=tz - <a name="top"></a>...<img longdesc="#top"> |
| 14:31 | <Philip`> | http://www.konyhatizezercikk.hu/product_info.php?products_id=716&osCsid=e6ce5f51d4fcec7641964b009e2e4bfe - <img longdesc="#oldalteto"> (undefined id) |
| 14:31 | <Philip`> | plus a few with longdesc="#" |
| 14:32 | <Philip`> | according to http://philip.html5.org/data/longdesc-raw.txt |
| 14:32 | <Philip`> | othermaciej: "Is it actually used that way in content?" - apparently not frequently |
| 14:32 | <othermaciej> | Philip`: thanks |
| 14:32 | <othermaciej> | Philip`: so that's one plausibly correct fragment reference |
| 14:33 | <othermaciej> | Philip`: out of how many pages total? |
| 14:33 | <Philip`> | About 425K |
| 14:34 | <Philip`> | http://philip.html5.org/data/dotbot-20090424.txt |
| 14:34 | <Philip`> | Which one is plausibly correct? |
| 14:34 | <othermaciej> | and those are the only idrefs? |
| 14:34 | <Philip`> | The one that points to an empty element, or the one that points to a non-existent element? |
| 14:34 | <othermaciej> | the #top one, out of those you mentioned |
| 14:35 | <othermaciej> | is there relevant content after the <a>? |
| 14:35 | <Philip`> | No |
| 14:35 | <Philip`> | See the page itself :-) |
| 14:36 | <Philip`> | (It hasn't changed since the crawler saw it) |
| 14:36 | <Philip`> | I just looked for the string "# in the longdesc-raw.txt file |
| 14:37 | <Philip`> | so it's all the pages that have <img longdesc="#..."> |
| 14:37 | <othermaciej> | I see, that anchor is just before the image, so not clear how much it's supposed to help |
| 14:38 | <othermaciej> | I would say post your findings on public-html |
| 14:38 | <othermaciej> | I am more curious if it works in any reasonable way in browser+AT combos |
| 14:39 | <othermaciej> | if not, then energy is probably better directed into more fully implementing ARIA than into making longdesc="#..." work reasonably |
| 14:43 | <Philip`> | Whoops |
| 14:43 | <Philip`> | Opera's incremental find doesn't work perfectly if you use it before the page has finished loading |
| 14:43 | <Philip`> | so there's a few more longdesc="#..."s |
| 14:46 | <othermaciej> | I count 28 values with # signs |
| 14:46 | <othermaciej> | 11 of which are not just "#" |
| 14:47 | <othermaciej> | most look like similar $top situations |
| 15:11 | <Philip`> | Is it possible to have a 0x0 pixel JPEG? |
| 15:12 | <Necrathex> | no, but 0x1 is |
| 15:12 | <Necrathex> | ^_^ |
| 15:12 | <othermaciej> | most image formats seem to have that as a possibility but I don't know about JPEG |
| 15:13 | <Philip`> | PNG doesn't ("Zero is an invalid value") |
| 15:16 | <Philip`> | Necrathex: Peculiar |
| 15:17 | <Philip`> | JPEG is all weird and talks about samples and lines instead of width and height :-( |
| 15:17 | <Necrathex> | i'm pretty sure you can make a 0x0 svg image |
| 15:18 | <Dashiva> | You can make SVG without size at all, can't you? |
| 15:19 | <Philip`> | Hmm, can't JPEG do 0x0 if you use this special DNL thing to set it to 0? |
| 15:19 | <Necrathex> | why do you need an empty image? |
| 15:19 | <Dashiva> | Division by zero! |
| 15:19 | <Philip`> | or maybe you can only do the DNL thing after the first line |
| 15:20 | <Philip`> | if a "scan" is related to a line in some way |
| 15:20 | <Philip`> | This seems too complex to bother understanding :-) |
| 15:20 | <Philip`> | (or at least too different to terminology I understand) |
| 15:21 | <Philip`> | Necrathex: Just wondering what could/should happen if you do toDataURL("image/jpeg") on a 0xN or Nx0 canvas |
| 15:22 | <Philip`> | and/or if you use drawImage with a 0x0 image |
| 15:23 | <annevk> | Philip`, worthwhile depends on you, it would be useful to a lot of people I think |
| 15:27 | annevk | likes that HTML5 makes LF out of &13; but has no good arguments |
| 15:27 | annevk | sighs |
| 15:34 | <AryehGregor> | <othermaciej> also using the <video> element may be higher performance than plugin-based video solutions <-- Are there benchmarks that show this is consistently true? I've heard conflicting reports. |
| 15:36 | <Dashiva> | I've heard reports <video> is worse than plugins for fullscreen |
| 15:37 | <Philip`> | "may be" != "is" |
| 15:38 | <Philip`> | It's certainly possible that it can be higher performance than a plugin, because in the worst case it can be implemented exactly like a plugin and in the best case it can be more tightly integrated with the browser's rendering code |
| 15:39 | <fupp> | according to adobe, <video> doesn't solve the performance problem, but does the exact same thing that makes flash slow, to convert YUV data to the RGB colorspace and combine the image with other elements |
| 15:39 | <fupp> | http://blogs.adobe.com/penguin.swf/2010/01/solving_different_problems.html |
| 15:40 | <hsivonen> | fupp: if you profile Firefox running a pageload test, you'll find that one of the top things taking time is the color domain conversion for JPEGs |
| 15:41 | <hsivonen> | so yeah, YUV to RGB is a big deal |
| 15:41 | <hsivonen> | it's not the only deal, though |
| 15:41 | <Dashiva> | Couldn't a browser do what a dedicated media player does? |
| 15:42 | <zcorpan> | depends on whether you're doing fancy things like rotating the video or having transparency |
| 15:43 | <hsivonen> | Dashiva: in the absence of hard SVG filters, yes |
| 15:43 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=538323 |
| 15:43 | <asmodai> | Mmm, could the html in the HTML 4.01 doctype be lowercase as well, or should it always be uppercase? (Can't remember >_< ) |
| 15:43 | <hsivonen> | asmodai: yes |
| 15:43 | <gsnedders> | It's case-insensitive |
| 15:43 | <gsnedders> | HtMl is fine too |
| 15:43 | <workmad3> | htmL |
| 15:43 | <asmodai> | Heh, I'll just stick to the lowercase then. ^^ |
| 15:44 | asmodai | seriously wants to nail this developer to the wall. Not sure which HTML standard he was following, but it was not HTML 4.01 or XHTML 1.0 |
| 15:44 | <hsivonen> | zcorpan: I'd expect rotation and transparency to work if the video is an OpenGL texture converted from YUV to RGB using an OpenGL pixel shader |
| 15:44 | <hsivonen> | and the 2D compositing is done on the GPU |
| 15:45 | <hsivonen> | although that's not what movie players on Linux do |
| 15:45 | <hsivonen> | they tend to use xv instead of OpenGL |
| 15:49 | <AryehGregor> | Why can't you solve color format conversions by just using a different color format in the videos? |
| 15:50 | <Philip`> | Because YUV compresses much better than RGB |
| 15:51 | <AryehGregor> | Hmph. |
| 15:51 | <AryehGregor> | I see. |
| 15:56 | <AryehGregor> | Is this the sort of thing that parallelizes nicely, so we can all rest assured that in five years we'll do fine because eight cores are standard? |
| 15:57 | <AryehGregor> | I imagine you could hand one frame to one CPU and the next to another. |
| 15:57 | <AryehGregor> | Or something. |
| 15:57 | <AryehGregor> | (maybe not, if there's delta encoding or whatnot . . . oh well, not my field) |
| 15:57 | <MikeSmith> | so it seems the first f2f meeting of the hybi wg will be March 24 in Anaheim, California.. would be good if we could get some people to attend |
| 15:58 | <MikeSmith> | I think it will cost you 200 USD for registration, though |
| 15:59 | <hsivonen> | MikeSmith: what's the goal of the meeting? (I'm not planning on attending. just curious.) |
| 16:01 | <MikeSmith> | hsivonen: not sure what the agenda is.. I've not been following the hybi discussions closely for last couple months |
| 16:02 | <Philip`> | AryehGregor: Each pixel is entirely independent, so you can do colour conversions with loads of parallelism |
| 16:02 | <Philip`> | which is why it's good to do it on the GPU rather than CPU, because then you can process hundreds of pixels in parallel |
| 16:03 | <Philip`> | as far as I'm aware |
| 16:03 | <AryehGregor> | Well, I trust that people who know more than I do will figure out some way to do it efficiently. :) |
| 16:03 | <Philip`> | In five years we'll all have higher-resolution monitors so there'll be more pixels to decode :-) |
| 16:04 | <Philip`> | so simply relying on hardware improvements won't fully solve the problem |
| 16:04 | <hsivonen> | Philip`: U and V are not truly independent for each pixel, though |
| 16:04 | <AryehGregor> | Rats. |
| 16:05 | <hsivonen> | Philip`: assuming a sampling where the resolution of U and V is lower than the resolution of Y |
| 16:05 | <AryehGregor> | I guess video is pretty close to unlimited resolution, for the foreseeable future. You can always get better quality until the pixels become invisible. That's a long way off . . . |
| 16:06 | hsivonen | can't tell the difference between 720p and 1080p movie trailers on a 1080p display from a normal movie watching distance |
| 16:06 | <hsivonen> | (as in: downloading the same trailer and 720p and 1080p from Apple and comparing) |
| 16:07 | <annevk> | you need at least 42inch or so |
| 16:07 | <Philip`> | hsivonen: Oh, true |
| 16:08 | <Philip`> | but 4x2 blocks (?) should be independent |
| 16:08 | <Philip`> | and there's still zillions of those to process in parallel |
| 16:09 | <hsivonen> | annevk: I used a 37" display |
| 16:11 | <annevk> | hsivonen, I'm not a 100% sure of course, but I heard you start seeing the difference from 42"... So presumably you need 50 or so to really see it |
| 16:11 | <annevk> | of course, this doesn't stop them from working on 4000+ |
| 16:12 | hsivonen | notes that the live action in the newer star wars movies was shot at mere 1080p |
| 16:38 | roc_ | notes that we have GPU-based YUV-to-RGB conversion working for <video> "in the lab" |
| 16:38 | <AryehGregor> | Hurrah. |
| 17:12 | <JonathanNeal> | Goodmorning. |
| 17:37 | <boblet> | hey Mike… |
| 17:39 | <MikeSmith> | yeah |
| 17:39 | <boblet> | was just chatting to Yakura-san, and he mentioned that a lot of Japanese sites (esp. mobile) use <hr> as a content division. The new “*paragraph-level* thematic break” doesn’t mesh with that usage |
| 17:40 | <boblet> | makes sense on eg yahoo.co.jp’s HP when you turn off CSS atm. No <hr> would make it a wall of unstyled content |
| 17:40 | <boblet> | (admittedly as opposed to a slightly chunked wall of unstyled content :) |
| 17:42 | <boblet> | are UAs eventually expected to differentiate between sectioning content blocks visually when CSS is disabled? |
| 17:43 | <boblet> | and with that rousing question I bid you adieu. sleep well… |
| 17:43 | <boblet> | nn |
| 18:02 | <MikeSmith> | boblet: some Japanese sites have a pattern of doing a number of strange/bizzare things as far as markup goes |
| 18:03 | <boblet> | don’t we know it. ok, nn fo reals this time |
| 18:04 | <JonathanNeal> | I've started ending my emails with "VIVA LA CINCO!" |
| 18:04 | <JonathanNeal> | In support of HTML5. |
| 18:05 | <gsnedders> | hsivonen: http://www.p01.org/releases/128b_mandelbrot/115b.htm is b0rked with html5 parser |
| 18:06 | <gsnedders> | hsivonen: nvm, wfm in 3.7, just not 3.6 |
| 18:30 | <JonathanNeal> | Today is battle of the HTML5 day, woohoo. |
| 18:32 | <othermaciej> | eh? |
| 18:33 | <JonathanNeal> | We've been running out HTML5 website through a gauntlet of tests. |
| 18:34 | <JonathanNeal> | Screenreaders, performance checkers. |
| 18:34 | <JonathanNeal> | Testing to see how much positive or negative the HTML5 impact has been. |
| 18:35 | <JonathanNeal> | HTMl5 killed 0 accessibility tests on MAC and PC, including using the EYES and JAWS readers. |
| 18:36 | <JonathanNeal> | In fact, HTML5 in combination with properly layed-out markup improved accessibility, and use of <nav> tag offered improved accessibility in the JAWS reader. |
| 18:37 | <TabAtkins> | Ooh, JonathanNeal, could you write up your findings? |
| 18:37 | <JonathanNeal> | For IE6,7,8 we tested the shiv used to add in support for HTML5 elements in the DOM and CSS. |
| 18:37 | <TabAtkins> | Especially regarding the results with actual screenreadeers. |
| 18:37 | <JonathanNeal> | TabAtkins, yea and we've been youtub'ing the results. |
| 18:37 | <TabAtkins> | Awesome. |
| 18:38 | <JonathanNeal> | You may wanna wait til we've written up our assessments of the results, right now it's scattered. |
| 18:38 | <TabAtkins> | kk |
| 18:38 | <JonathanNeal> | We found the HTML5 shiv for IE had an impact of 0.025ms in IE6. |
| 18:38 | <miketaylr> | so awesome |
| 18:39 | <JonathanNeal> | 0.015ms in IE8. We contrast these results with other tests, like document.getElementById, ElementsByTagName. |
| 18:39 | <JonathanNeal> | We're measuring our existing site search results on Google, Bing, Yahoo, etc to see how the content was picked up. |
| 18:40 | <othermaciej> | JonathanNeal: that's interesting data |
| 18:41 | <Necrathex> | what site are we talking about btw? |
| 18:42 | <JonathanNeal> | Well, some tests don't require the site, but otherwise we're looking at our site, liferay.com |
| 18:42 | <Necrathex> | ah |
| 18:43 | <Necrathex> | you actually have ie6-visitors? :) |
| 18:43 | <JonathanNeal> | Which I built exclusively in HTML5 thanks to the help of TabAtkins and many others in here, taking advantage of the new markup as well as the new <video> feature. |
| 18:43 | <JonathanNeal> | We have plenty of IE6 visitors, you'll see Cisco is a client, and they're pretty much all IE6. |
| 18:43 | <Necrathex> | that's really nice :) |
| 18:43 | <Necrathex> | :x |
| 18:44 | <JonathanNeal> | Guess how many complaints we've received about HTML5, from anyone, even on the forums, or support tickets; 0. |
| 18:53 | <AryehGregor> | JonathanNeal, I wish I could say that about my attempt to get HTML5 into Wikipedia. Then again, we don't have all this "testing" stuff you've been talking about. |
| 19:00 | <JonathanNeal> | Wikipedia doesn't have "testing" stuff? |
| 19:06 | <Philip`> | Depends if you consider ordinary users to be testers |
| 19:09 | <AryehGregor> | JonathanNeal, we don't have any formal testing procedure. The procedure is largely 1) people commit stuff to trunk, 2) users of trunk (mostly developers) hopefully complain when things break, then eventually: 3) test.wikipedia.org is synced to trunk and sysadmins wait a little while to see if there are reports from voluntary testers, 4) all Wikimedia projects are synced to trunk, 5) sysadmins hang around in #wikimedia-tech for a while fieldi |
| 19:09 | <AryehGregor> | ng critical bug reports that weren't caught at an earlier stage. |
| 19:30 | <JonathanNeal> | Well, AryehGregor, I will be sure to show my results to you and capture any other questions you have. |
| 19:30 | <JonathanNeal> | I hope we can help each other, in the spirit of opensource. |
| 19:31 | <gsnedders> | JonathanNeal: I am here again |
| 19:32 | <JonathanNeal> | Hey gsnedders, cool, did you have a question for me? I can't recall, it's a been a wild night and morning. |
| 19:32 | <gsnedders> | JonathanNeal: You tried to get me :P |
| 19:32 | <Hixie> | well, the first evidence of the domintro boxes having a negative effect just surfaced... it looks like microsoft read those instead of the normative text. |
| 19:32 | <JonathanNeal> | gsnedders, cool, do you also know what I was asking you for? :D |
| 19:33 | <JonathanNeal> | I bet it had SOMETHING to do with html5. |
| 19:33 | <gsnedders> | JonathanNeal: No |
| 19:33 | <JonathanNeal> | heheh. |
| 19:33 | <JonathanNeal> | Well, hello friend! |
| 19:34 | <JonathanNeal> | We're doing lots of accessibility tests with HTML5. |
| 19:35 | <JonathanNeal> | Like, for instance, in Chrome you can not tab to a <video> element, but in Firefox you can, and then use spacebar to play and pause the video. |
| 19:35 | <AryehGregor> | Hixie, did they disagree with the normative text? |
| 19:35 | <jwalden> | JonathanNeal: that's a quality-of-implementation thing, right? |
| 19:35 | <AryehGregor> | JonathanNeal, neat. Gecko seems to have better <video> support overall than WebKit right now. |
| 19:36 | <Hixie> | AryehGregor: no they just said they were confused and quoted the domintro text |
| 19:36 | <Hixie> | AryehGregor: see public-canvas-api |
| 19:36 | <Hixie> | (there's a bug in the spec) |
| 19:38 | <Hixie> | hsivonen: i believe the thing was done in response to your feedback... |
| 19:40 | <hsivonen> | Hixie: oops... |
| 19:43 | <JonathanNeal> | I've filed a ticket about the <video> keyboard accessibility issue @ http://code.google.com/p/chromium/issues/detail?id=36472 |
| 19:44 | <JonathanNeal> | Might as well push them all to improve. :D |
| 19:45 | <AryehGregor> | Does Safari have the same issue? If so, you should probably file with WebKit instead. |
| 19:45 | <JonathanNeal> | Well, their implementation of <video> differs so greatly. |
| 19:45 | <JonathanNeal> | I think Safari swallows <video> and turns it into a quicktime control. |
| 19:46 | <othermaciej> | "quicktime control"? |
| 19:46 | <othermaciej> | we do use QuickTime as the media engine but not stock high-level APIs like NSMovie |
| 19:47 | <AryehGregor> | How much of the <video> implementation is shared by Safari and Chrome? |
| 19:49 | <Philip`> | The spec has annoyingly many conformance requirements |
| 19:49 | <AryehGregor> | We should remove all the conformance requirements, then. |
| 19:49 | <AryehGregor> | Would that solve the problem? |
| 19:49 | <JonathanNeal> | othermaciej, yes, the video seems to share the same controls as a quicktime video, though they do not add height to the video as quicktime controls usually do. |
| 19:50 | Philip` | has now reached 306 testable statements for <canvas> |
| 19:50 | <JonathanNeal> | But that means they're overlapping the bottom portion of the video, since they do not hide themselves. |
| 19:50 | <AryehGregor> | That seems low. |
| 19:51 | AryehGregor | wonders what all the 105-year-old Internet users do when they get age forms that only go back to 1910 or so |
| 19:51 | <Philip`> | It looks like it's probably more than the combined total of http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_toc.html |
| 19:52 | <AryehGregor> | That says more about HTML 4 than it does about HTML5, though. |
| 19:52 | <Philip`> | AryehGregor: Maybe they do what all the 15-year-old Internet users do, and lie about their age |
| 19:53 | <AryehGregor> | I assume so. |
| 19:55 | <AryehGregor> | Anyway, as for video, it seems to me like the spec is sort of painted into a corner. Authors have to know how much space the video will take up regardless of whether it has built-in controls, but the size of controls would be implementation-dependent. So it's basically forced to leave no space for UA-provided controls. |
| 19:55 | <AryehGregor> | UAs handle this pretty elegantly, I guess. |
| 20:09 | <JonathanNeal> | othermaciej, I looked into this Safari issue deeper, let me post a test. |
| 20:15 | <JonathanNeal> | http://sandbox.thewikies.com/html5-video-framing/ <-- note the result in Safari. |
| 20:17 | <JonathanNeal> | We lose the bottom 16 pixels of the video while the controls are visible, which do not hide. |
| 20:18 | <Hixie> | anyone (othermaciej) have any comments on these updates to the change proposal for longdesc=""? http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc%3D""; |
| 20:18 | <eric_carlson> | JonathanNeal: the controls are only visible when the video is paused, or when the cursor moves over the element |
| 20:19 | <Hixie> | this shows the diffs: http://wiki.whatwg.org/index.php?title=Change_Proposal_for_not_including_longdesc%3D%22%22&action=historysubmit&diff=4448&oldid=4436 |
| 20:19 | <JonathanNeal> | eric_carlson, noted, so it's only for preview. |
| 20:19 | <JonathanNeal> | That's fair, the poster attr doesn't work yet either, so I hope to see it all pushed through eventually. |
| 20:19 | <eric_carlson> | JonathanNeal: the poster attribute should work in WebKit |
| 20:20 | <AryehGregor> | JonathanNeal, same in Chrome, looks like. |
| 20:20 | <AryehGregor> | Ah, no. |
| 20:20 | <AryehGregor> | They fade out if you mouse away. |
| 20:20 | <AryehGregor> | But not if it's paused. |
| 20:21 | <JonathanNeal> | These are notes on framing, hpoe I'm not pissing you guys off -- I note the similarity in Chrome too! |
| 20:26 | <JonathanNeal> | It seems unique to the paused state of <video> in Chrome and Safari. |
| 20:28 | <TabAtkins> | Hixie: Sounds good overall. |
| 20:29 | <Hixie> | have i missed any arguments? |
| 20:31 | <JonathanNeal> | Kill that longdesc, Hixie :D |
| 20:31 | <annevk> | Hixie, we recently had the same with <canvas> domintro text |
| 20:31 | <annevk> | Hixie, with us it was about drawImage() exceptions |
| 20:32 | <Hixie> | annevk: the same bug, or the same problem with implementors reading the domintro text? |
| 20:32 | <Philip`> | Maybe it should say "This box is not normative" in every domintro box |
| 20:32 | <annevk> | same problem, have not looked at the bug |
| 20:32 | <Hixie> | Philip`: ooh, that's a good idea. |
| 20:33 | <Philip`> | Seems like people aren't used to the idea that anything that doesn't say "must" is not normative |
| 20:35 | <othermaciej> | Hixie: I'll try to look over lunch |
| 20:37 | <JonathanNeal> | From an accessibility standpoint, Firefox's implementation is the best. The visible controls are unique to the paused state of <video> in Chrome and Safari, whereas Firefox will hide the controls once a mouse has passed into and out of a <video>. If a mouse has not passed into a <video> but keyboard interaction does, the controls remain visible - it's a visible feature triggered by a visible interaction. |
| 20:37 | <TabAtkins> | Hixie: One example of a page with useful @longdesc is cssquirrel.com. |
| 20:38 | <TabAtkins> | Though the last 4 comics' longdescs 404. |
| 20:38 | <Dashiva> | You know, I can understand that FSF wants open codecs, but saying Google owes them a free codec seems taking a bit far... |
| 20:39 | <AryehGregor> | Does the FSF ever *not* take things a bit far? |
| 20:39 | <AryehGregor> | Well, yes. When they take them more than a bit far. |
| 20:40 | <othermaciej> | Hixie: your updates certainly increase the persuasive force of your argumemt |
| 20:40 | <JonathanNeal> | Dashiva, which codec do they want now? |
| 20:40 | <othermaciej> | Hixie: I guess Chaals or I or someone advising us needs to find at least one example of a page with a good use of longdesc |
| 20:41 | <Dashiva> | JonathanNeal: VP8 |
| 20:41 | <Hixie> | othermaciej: one in one trillion is not good odds. :-P |
| 20:41 | <othermaciej> | Hixie: I agree - though it is infinitely better than zero in a trillion |
| 20:42 | <othermaciej> | I'm just saying that I don't know if I can stand behind a rationale of "there are some good uses of longdesc" without having at least one to point to |
| 20:48 | <TabAtkins> | othermaciej: CSSquirrel. Weems uses @longdesc to link to the transcripts for his comics. |
| 20:49 | <Hixie> | he also already uses ARIA, and his latest links are 404 |
| 20:49 | <Hixie> | so it's not like (a) he uses it correctly and (b) he needs a transition story |
| 20:50 | <annevk> | this reminds me of a site from Philip TAYLOR with an incorrect alternate text and a longdesc pointing to a 404 |
| 20:50 | <annevk> | was a homepage of something |
| 20:51 | <tantek> | longdesc arguments are looooooooooooooooooooooooooooooooooooooooooooooong |
| 20:51 | <othermaciej> | I wonder why he does not use aria-describedby for the transcripts, seems pretty harsh to force a page load to get it |
| 20:52 | <Hixie> | yeah longdesc="" isn't even a good solution in that case, compared to just putting the text inline |
| 20:53 | <tantek> | or an inline visible link to an external transcript |
| 20:53 | <tantek> | when or why would you want curbcuts to ever be invisible? |
| 20:53 | <Hixie> | yeah |
| 20:53 | <othermaciej> | inline visible test or visible link associated with aria-describedby seems to be the best of all possible worlds afaict |
| 20:54 | <othermaciej> | or if you must, you can hide the description in visual media |
| 20:54 | <tantek> | better to err on the side of visibility (somebody else might find use for the information) than err on the side of invisibility (some developer might be annoyed at having to make it visible) |
| 20:54 | <tantek> | also - note that in that case user need should win over author/developer need - per the design principles |
| 20:54 | <othermaciej> | aria-describedby defaults to visibility, which is nice |
| 20:56 | <Hixie> | i added something to the Risks and Negative Effect sections |
| 20:56 | <tantek> | are there any conforming and recommended invisible content features in HTML5 currently? |
| 20:57 | <othermaciej> | does alt count? |
| 20:57 | <tantek> | no - because alt is visible when you load a browser with images turned off (a common preference in browsers) |
| 20:57 | <othermaciej> | do the various <meta name> and <link rel> types without default visible effect count? |
| 20:57 | <tantek> | and some browsers show alt while images are loading (e.g. over slow connections) |
| 20:58 | <Hixie> | ok i'll post this to the list later if nobody has any more suggestions in the meantime |
| 20:58 | <tantek> | which just demonstrates another curbcut scenario - what was intended for accessibility helps those with slow networks |
| 20:58 | <Hixie> | http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc%3D""; |
| 20:58 | <tantek> | othermaciej - yes, meta name needs to be dropped nearly universally |
| 20:59 | <Hixie> | diffs at http://wiki.whatwg.org/index.php?title=Change_Proposal_for_not_including_longdesc%3D%22%22&action=historysubmit&diff=&oldid=4436 |
| 20:59 | <tantek> | link rel is typically programmatic rather than content oriented - like script |
| 20:59 | <Dashiva> | "Not including" is probably going to be misunderstood to "not supporting" |
| 21:00 | <tantek> | you might argue that the "title" attribute on link is invisible content, but it is only advisory, and in the context of alternate style sheets - for user agents that support them (e.g. Mozilla back in the day), those titles are visible when choosing an alternative |
| 21:01 | <Hixie> | Dashiva added comment to hte summary for you |
| 21:02 | tantek | fixes the link to the wiki placed in IRC to be more regex-auto-linking proof. |
| 21:03 | <tantek> | so, once again, any conforming invisible content in HTML5 other than meta name (which IMHO should be dropped) ? |
| 21:04 | <annevk> | <link>? |
| 21:05 | <annevk> | <rp>, <input type=hidden> |
| 21:06 | <Hixie> | hidden="" |
| 21:06 | <tantek> | annevk - see above about <link> |
| 21:07 | <tantek> | (in short - it's more programmatic like script than any kind of content) |
| 21:07 | <Hixie> | fallback in <object>, <canvas>, <video>, <iframe>, <audio>, etc |
| 21:07 | <annevk> | hmm, <link rel=prev> and all are not |
| 21:07 | <tantek> | fallbacks are not invisible because they show up when the primary content fails |
| 21:08 | <annevk> | only a few in http://annevankesteren.nl/2010/01/optimizing-html are programmatic |
| 21:08 | tantek | would like something akin to <rp> for general use |
| 21:08 | <annevk> | but I'm not sure they're very useful either, to be honest |
| 21:08 | <annevk> | I included them because at the time using <link> like that made sense |
| 21:08 | <annevk> | it was the HTML4-way |
| 21:09 | <annevk> | markup gods would give you a compliment and you'd feel good about yourself; nowadays it feels more like bloat :) |
| 21:10 | <Hixie> | the markup gods are dead? :-) |
| 21:12 | <tantek> | annevk - there's good markup for practical reasons, and there's good markup for dogmatic reasons. some disagree about which category any particular technique falls into. |
| 21:13 | <tantek> | e.g. I've found plenty of practical use in making biglot documents, especially recently. |
| 21:13 | <tantek> | there's plenty of XML based tools that are useful (e.g. in PHP, DOMDocument etc.) |
| 21:14 | <tantek> | so until all these backend languages have built-in support for html5lib - biglot documents are useful (and thus the space slash for empty elements like <img /> etc.) |
| 21:14 | <Hixie> | oh bi-glot, i was reading big-lot |
| 21:15 | Philip` | finishes updating his canvas test assertion list, and ends up with 311 (excluding the focus management section) |
| 21:16 | <tantek> | e.g. the software running on my current site to post to Twitter etc. uses an hAtom biglot store. |
| 21:17 | Philip` | doesn't think he's ever seen any tool in which space-slash is needed |
| 21:17 | <Philip`> | (instead of no-space slash) |
| 21:18 | <annevk> | Philip`, you should create a patch for the source code of html5 so you don't have to do it again everytime |
| 21:18 | <annevk> | but I guess hixie would have to maintain it then |
| 21:18 | <tantek> | Philip' - I believe the "lore" is that some browsers need the space before the slash in order to treat those elements properly |
| 21:19 | tantek | does not have specific tests for this though - it may just be out of date lore. |
| 21:22 | tantek | prefers to use biglot HTML5+hAtom for storage of small numbers of things rather than pay the DBA-tax (e.g. MySQL). |
| 21:22 | <Philip`> | annevk: I don't have to redo the whole thing, I just have to add/remove/update whatever's changed since the last version of the spec |
| 21:23 | <Philip`> | so it's no harder than if the markers were inline in the spec |
| 21:23 | <Philip`> | The main problem is the last version of the spec was 1.5 years old, and it's changed a bit since then |
| 21:23 | <tantek> | Hixie, re: http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc - where is the section on how longdesc harms accessibility? |
| 21:23 | <annevk> | mostly because of you :p |
| 21:23 | <tantek> | I think that needs to be made explicit |
| 21:24 | <Philip`> | tantek: By "lore", you mean dogma? :-) |
| 21:25 | <tantek> | Philip` usually it's a transition from experience to lore to dogma. |
| 21:25 | <Philip`> | No modern browser could require the space because it'd break on web content |
| 21:25 | <tantek> | by the time it makes it to dogma, because the lore became detached from experience, it is no longer possible to retest the original hypotheses. |
| 21:25 | <tantek> | Philip` - which web content would it break on? |
| 21:25 | <Philip`> | and (if I remember correctly) even Netscape 1 worked fine with no space |
| 21:26 | <tantek> | Philip` - do you have test cases of all HTML empty elements with no-space slash? Including tests to ensure than any attributes before the no-space slash are handled correctly? |
| 21:28 | <Philip`> | tantek: http://google.com/codesearch?q=%3Cimg%5C+src%3D%22%5B%5E%22%5D%2B%22%2F%3E |
| 21:34 | <tantek> | http://google.com/codesearch?hl=en&lr=&q=%3Clink%5C+rel%3D%22%5B%5E%22%5D+href%3D%22%5B%5E%22%5D%2B%22%2F%3E&sbtn=Search |
| 21:35 | <tantek> | http://google.com/codesearch?hl=en&lr=&q=%3Cmeta%5C+name%3D%22%5B%5E%22%5D+contents%3D%22%5B%5E%22%5D%2B%22%2F%3E&sbtn=Search |
| 21:37 | <tantek> | and of course: http://google.com/codesearch?q=%3Cbr%2F%3E |
| 21:38 | <Hixie> | tantek: second bullet of rationale and third of the positive effects |
| 21:38 | <tantek> | I think it could be more strongly worded |
| 21:38 | <tantek> | evidence demonstrates that longdesc has harmed accessibility |
| 21:39 | <tantek> | net-harmed |
| 21:39 | <Hixie> | tantek: uri? |
| 21:39 | <tantek> | those same studies |
| 21:39 | <Hixie> | ok why does .domintro:before { display: block; margin: -1em -0.5em 0 auto; width: auto; content: '...'; border: solid thin; background: white; padding: 0 0.25em; } result in a box that fills the width of the ocntaining block??? |
| 21:39 | <tantek> | that show all the garbage values |
| 21:39 | <Hixie> | tantek: they don't demonstrate harm to users |
| 21:39 | <Hixie> | tantek: just that the data is bogus |
| 21:39 | <Hixie> | tantek: it is argued that UAs are ignoring longdesc="" values that are bogus |
| 21:39 | <Hixie> | or that they could |
| 21:39 | <Hixie> | or some such |
| 21:40 | <tantek> | how can they tell that the values are bogus? |
| 21:40 | <Hixie> | beats me |
| 21:40 | <Hixie> | but i'd rather not explicitly say there is harm caused unless i can prove it |
| 21:40 | <Hixie> | since otherwise i'm just providing a straw man to attack |
| 21:47 | <Hixie> | oh duh |
| 21:47 | <Hixie> | width:auto overrides auto margins |
| 21:47 | <Hixie> | !#$%% |
| 21:48 | <Hixie> | do we have width:intrinsic yet? |
| 21:48 | Hixie | switches to display:table instead |
| 21:48 | <TabAtkins> | I think the intrinsic width values are vendor-prefixed right now? |
| 21:49 | <Hixie> | slowest. moving. wg. ever. |
| 21:49 | <TabAtkins> | Just use display:table, yeah. That's the current hacky form of width:min-intrinsic. |
| 21:49 | <TabAtkins> | For real. |
| 21:50 | <Hixie> | ok good, that works |
| 21:50 | <Hixie> | .domintro:before { display: block; margin: -1em -0.5em 0 auto; width: auto; content: 'This box is non-normative. Implementation requirements are given below this box.'; col\ |
| 21:50 | <Hixie> | or: red; border: solid thin; background: white; padding: 0 0.25em; } |
| 21:50 | <TabAtkins> | We *just* got our first css3 module to PR. >_< |
| 21:50 | <Hixie> | er |
| 21:50 | <Hixie> | mispaste |
| 21:50 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#error-codes |
| 21:50 | <Hixie> | selectors? |
| 21:50 | <TabAtkins> | Yeah. |
| 21:50 | <Hixie> | that's not css3 :-P |
| 21:50 | <Hixie> | but woohoo! |
| 21:50 | <Hixie> | selectors in pr! |
| 21:50 | <TabAtkins> | Close enough! |
| 21:50 | <Hixie> | man i remember writing parts of the test suite for that 8 years ago! |
| 21:51 | <Hixie> | maybe more! |
| 21:51 | TabAtkins | has so much shit planned for this new gig. |
| 21:51 | <Hixie> | ok do these new domintro boxes look ok? |
| 21:52 | <TabAtkins> | I'd give it a 2px border. |
| 21:52 | <Hixie> | are the colours ok? |
| 21:53 | <TabAtkins> | Yah. |
| 21:54 | <TabAtkins> | Oh, hmm. Now I see the box. The box background is far too light. I have to tilt my monitor and get it to start distorting colors before I can tell the extent of the box. |
| 21:54 | <TabAtkins> | For .domintro, not .domintro::before |
| 21:56 | <Hixie> | reload in a few minutes, let me know what you think. back in a bit, cycling to work. |
| 22:04 | <TabAtkins> | Hixie: Yes, much better. |
| 22:44 | <Dashiva> | "You could interest users with HD videos in free formats [...] this would eventually lead to users not bothering to install Flash on their computers" |
| 22:44 | <Dashiva> | Apparently FSF never heard of flash games |
| 22:54 | <gavin> | you're forgetting about the VP8 dynamic animation, 3d graphics and scriptability API |