| 00:02 | <zewt> | gah |
| 00:02 | <zewt> | alright, can anyone give me a plausible explanation for this which has driven me insane for years: "if your download doesn't start in 15 seconds..." and a redirect to download links, instead of plain standard old download links, heh |
| 00:03 | <zewt> | so broken and it's hard to think up even an implausible explanation |
| 00:05 | <TabAtkins> | Those types of things typically use an iframe pointing to the file with appropriate headers to trigger an automatic download prompt. |
| 00:05 | <zewt> | which is the same thing you'll get with a plain download link |
| 00:05 | <TabAtkins> | Not necessarily, if it's a type of file that the browser thinks it can handle itself. |
| 00:05 | <TabAtkins> | Also: more branding! |
| 00:05 | <zewt> | that's what content-disposition: attachment is for (iirc) |
| 00:06 | <zewt> | and it's so broken--breaks browser copy-link, and in the case of the Firefox upgrade I just did, it happily pops up another download prompt after I restart the session (since the download page is still open) |
| 00:08 | <TabAtkins> | Yup, it really shouldn't be necessary anymore. |
| 01:31 | <zewt> | missing messages in the archive? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/029492.html should be http://www.mail-archive.com/whatwg⊙lwo/msg24505.html |
| 01:48 | <Hixie> | zewt: weird |
| 02:06 | <zewt> | looks like the list indexes are broken when the trailing slash is missing from the URL |
| 02:06 | <zewt> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February vs http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/ |
| 02:06 | <Hixie> | not much i can do about it, it's a dreamhost thing |
| 06:52 | <abarth> | Hixie: is there an easy what to see which rev you removed <device> in? |
| 06:52 | <abarth> | i don't see it on http://twitter.com/whatwg |
| 06:53 | <zcorpan> | it was http://html5.org/r/5945 |
| 06:55 | <abarth> | yhx |
| 07:12 | <zcorpan> | Hixie: <p><b>.... <p><b>... <p><b>... won't nest the <p>s! don't you know the parsing algorithm by heart? :) |
| 08:49 | <hsivonen> | I guess I should do community service and draw a flowchart now that IE9 is final... |
| 09:24 | <hsivonen> | Am I reading the CSS 2.1 spec under /TR/ wrong or is its "Features at risk" out of sync with the actual spec requirements as far as the HTML body background rule goes? |
| 09:25 | <hsivonen> | it says the there's the risk that the exception might be extended to XHTML, but AFAICT, it has already been extended in the spec |
| 09:25 | <hsivonen> | and implemented across the top 4 engines, too |
| 09:25 | <zcorpan> | yeah, it's out of sync |
| 09:25 | <hsivonen> | are there now any CSS differences between XML and HTML Standards Mode? |
| 09:25 | <zcorpan> | i pointed that out when the spec was changed a few years ago |
| 09:26 | <zcorpan> | i think only in Selectors case-sensitivity |
| 09:26 | <hsivonen> | zcorpan: thanks. |
| 10:26 | <hsivonen> | Findings so far: IE9 sticks to the IE8 notion of what's quirky. Doesn't align with HTML5 and other browsers. |
| 10:31 | <zcorpan> | also for comment before doctype? |
| 10:34 | <hsivonen> | zcorpan: didn't test that yet |
| 10:51 | smaug____ | doesn't understand how the new Stream + video is supposed to work. In what format is the Blob created from Stream? Do all the browsers need to support that? |
| 11:22 | <Lachy> | smaug____, the spec says "Generate a file that containing data in a format supported by the user agent for use in audio and video elements." |
| 11:23 | <Lachy> | so it seems that browsers could save the file as WebM (VP8/Vorbis) or MP4 (h.264/AAC) or whatever they choose |
| 11:24 | <smaug____> | so the whole PeerConnection would work well only it both ends support same codecs |
| 11:24 | <Lachy> | that just means that if the website wants to accept those file uploads, then the servers are going to need to have support for both formats |
| 11:24 | <Lachy> | the P2P stuff is more complicated, as you will only be able to stream between browsers that support the same formats |
| 11:24 | <Lachy> | right |
| 11:25 | <smaug____> | That is bad |
| 11:25 | <smaug____> | leaving a major point of the feature unspecified |
| 11:25 | <Lachy> | yeah, it sucks big time. We just need to make sure we can make WebM successful for that purpose |
| 11:25 | <smaug____> | (which is ofc the case with <video> too) |
| 11:26 | <jgraham> | smaug____: Yeah, it does suck. Not sure what the alternative is though :( |
| 11:26 | <Lachy> | but we haven't implemented that stuff yet. Only what we announced yesterday, which was initial support for <device> and the ability to play that in a <video> element. We should be able to change the new API easily though. |
| 11:27 | <Lachy> | I mean, change *to* the new API easily |
| 11:27 | <smaug____> | I'm not sure I like the PeerConnection anyway |
| 11:28 | <smaug____> | the whole thing reminds a lot like WebSockets (with support for Streams), but with different protocols |
| 11:30 | <jgraham> | Isn't being like websockets a good thing? |
| 11:30 | <jgraham> | Or are you saying that we should reuse websockets? |
| 11:31 | <smaug____> | we could perhaps have just one API |
| 11:31 | <smaug____> | with support for different protocols |
| 11:33 | <jgraham> | I wonder if Hixie has looked at the design of 0mq |
| 11:33 | <jgraham> | It does multiple protocols / connection topologies with more or less a single API |
| 11:34 | <jgraham> | AFAIK |
| 11:34 | jgraham | has never used it but has read the manual |
| 11:34 | <jgraham> | Or parts thereof |
| 11:51 | <smaug____> | hmm, so implementation would need to encode video stream to webm and then show it in <video> ? |
| 11:51 | <smaug____> | though, perhap using the URL.createObjectURL doesn't require any encoding |
| 11:52 | <smaug____> | erm, but that is done for Stream, and Stream needs to be encoded... |
| 11:55 | <smaug____> | Lachy: how does that work with <device>? Do you first encode the video and then decode using <video> ? |
| 11:57 | <Lachy> | there is some magic in the back end that somehow renders the video directly from the camera without encoding as webm first. |
| 11:58 | <smaug____> | actually, <device> allows that quite easily, but with Streams that is not so easy |
| 11:59 | <Lachy> | the new API will also allow that quite easily, at least as far as rendering it locally is concerned. The recording or P2P streaming features will require webm encoding though. |
| 12:41 | <benschwarz> | Hi all |
| 12:43 | <zcorpan> | hi benschwarz |
| 12:50 | <benschwarz> | zcorpan he did it |
| 12:51 | <benschwarz> | (your tweet) |
| 12:52 | <zcorpan> | yeah |
| 12:52 | <zcorpan> | though i guess it still has default phpbb3 styles |
| 12:53 | <benschwarz> | zcorpan: its a start |
| 12:53 | <hsivonen> | Are "Compatibility Mode Settings" gone in IE9 or do I just have trouble finding them? |
| 13:07 | <hsivonen> | found it |
| 13:08 | <hsivonen> | required menu bar |
| 13:08 | <hsivonen> | well hidden! |
| 13:24 | <smaug____> | does Opera implement xhr.timeout? |
| 13:35 | <zcorpan> | smaug____: no |
| 13:35 | <smaug____> | ok |
| 13:35 | <smaug____> | then it is still easy to change it, since no one has implemented it |
| 13:36 | <smaug____> | zcorpan: thanks |
| 13:37 | <zcorpan> | how do you want to change it? |
| 13:37 | <smaug____> | zcorpan: it should be possible to cancel the timeout |
| 13:37 | <smaug____> | and perhaps also change it after send() |
| 13:38 | <smaug____> | about to send an email about this to webapps |
| 13:38 | <zcorpan> | maybe also set in UNSENT state? |
| 13:39 | <smaug____> | why does it need to be limited at all |
| 13:39 | <smaug____> | well, at all after opened |
| 15:42 | <jgraham> | Yay! Working group decision on ascii-ref means we get to waste even more time on arguing about the decision |
| 16:59 | <dylanw> | I'm trying to understand why header/footer are inline and not block elements. Could someone point me in the direction of that discussion? |
| 17:00 | <Ms2ger> | There's no such distinction |
| 17:00 | <Ms2ger> | But I think you're misinterpreting something, because they are what some would call block elements |
| 17:01 | <TabAtkins> | They're not inline, they're flow elements. The default UA stylesheet sets them to display:block. |
| 17:01 | <TabAtkins> | http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#display-types |
| 17:01 | <dylanw> | FF3.6 by default has them display:inline |
| 17:02 | <dylanw> | browser bug? |
| 17:02 | <TabAtkins> | That's because it doesn't know what the elements are. Unknown elements are display:inline by default. |
| 17:04 | <dylanw> | So then FF3.6 doesn't actually support HTML? |
| 17:05 | <TabAtkins> | It doesn't understand several of the new HTML elements, no. |
| 17:05 | <TabAtkins> | 3.6 is relatively old at this point. |
| 17:07 | <dylanw> | OK, I understand. I misinterpreted flow. And apparently so did the Moz crew. |
| 17:07 | <dylanw> | Thx |
| 17:07 | <TabAtkins> | No, Moz did not misinterpret it. 3.6 doesn't implement those elements at all. |
| 17:08 | <jgraham> | dylanw: To be fair all Mozilla did wrong was to have a long release cycle |
| 17:08 | <TabAtkins> | (Most flow elements are display:block, actually.) |
| 17:08 | <TabAtkins> | (Maybe all?) |
| 17:09 | <dylanw> | anchors are listed as flow |
| 17:10 | <dylanw> | yeah, the current flow list is a mix of classical block (div) and inline (abbr) |
| 17:10 | <TabAtkins> | Hmm, I'm surprised that abbr is flow. That sounds like it should be phrasing content. |
| 17:11 | <dylanw> | It's both. |
| 17:11 | <TabAtkins> | Indeed. I wonder why it's flow at all, though? |
| 17:11 | <dylanw> | It seems, and I'm just doing this prima facie |
| 17:11 | <dylanw> | that flow only means you're probably a block |
| 17:11 | <dylanw> | flow+phrasing you're probably inline |
| 17:12 | <dylanw> | though p is the obvious exception |
| 17:12 | <dylanw> | wait, no, p isn't phrasing |
| 17:12 | <dylanw> | duh. has its own section |
| 17:12 | <TabAtkins> | Ah, never mind, lots of elements are flow+phrasing. |
| 17:13 | <dylanw> | HTML standard never really specifies whether something is a "block" |
| 17:14 | <TabAtkins> | Yes it does, in the rendering section. |
| 17:14 | <TabAtkins> | Which I linked. ^_^ |
| 17:15 | <dylanw> | OK, I see now |
| 17:17 | <dylanw> | I'll just use that as a reset stylesheet |
| 17:18 | <dylanw> | thx |
| 17:18 | <TabAtkins> | Nah, it's not quite good enough for a reset stylesheet, since it uses some things that aren't supported in CSS. Use html5boilerplate.com |
| 17:21 | <dylanw> | Hadn't seen Paul's stuff yet. |
| 17:21 | <dylanw> | HTML makes me feel like I'm back in 2000 again screaming at Netscape 4's DOM. |
| 17:26 | <AryehGregor> | abbr is flow content, but can only be used where phrasing content is expected . . . so what does it mean that it's flow content? |
| 17:26 | <AryehGregor> | Oh, of course. |
| 17:26 | <AryehGregor> | It means you can do <div><abbr>Foo</abbr></div> or such, right? |
| 17:26 | <AryehGregor> | Wait, no. |
| 17:26 | <AryehGregor> | You can't. |
| 17:26 | AryehGregor | is confused now |
| 17:29 | <jgraham> | "Flow COntent" doesn't mean much |
| 17:29 | <jgraham> | s/O/o/ |
| 17:30 | <jgraham> | Just that the element represents part of the document rather than part of the metadata, or something |
| 17:31 | <jgraham> | Not even that |
| 17:32 | <jgraham> | Just "stuff that appears in the body" |
| 17:33 | <jgraham> | So for abbr the important requirement is that it can only be used where phrasing content is expected |
| 17:34 | <jgraham> | Hixie: You around yet? |
| 18:08 | <TabAtkins> | Wow, once you remove the filters and fonts from SVG, it's actually a pretty small and manageable spec. |
| 18:22 | <TabAtkins> | Hm, how appropriate is it to break up a table into sub-tables purely by using some rows as new headers? I want multiple related tables that all size their cells the same. |
| 18:24 | <hsivonen> | TabAtkins: even with <use> in place? |
| 18:24 | <TabAtkins> | Huh? |
| 18:24 | <TabAtkins> | Oh, SVG. |
| 18:24 | <TabAtkins> | One sec, breaking for lunch. |
| 19:00 | <Hixie> | jgraham: here |
| 19:01 | <Hixie> | smaug____: yes, PeerConnection would work well only it both ends support same codecs. I suppose I could put in the spec "user agents must implement the codecs that other user agents implement" but I doubt it would help... |
| 19:01 | <Ms2ger> | Hixie, Objection! |
| 19:02 | <Hixie> | to what? |
| 19:02 | <Hixie> | my being here? :-) |
| 19:02 | <smaug____> | Hixie: that would at least make it clear that PeerConnection works only in some cases |
| 19:02 | <Ms2ger> | To a requirement to implement codecs other UAs implement |
| 19:03 | <Hixie> | if the goal is to point out that PeerConnection's media streaming features are only going to interoperate between implementations that are interoperable, I think there'd be better ways to do it |
| 19:03 | <Hixie> | but it seems pretty self-evident to me |
| 19:03 | <Ms2ger> | Well, most things are only going to interoperate between implementations that are interoperable, no? |
| 19:03 | <Hixie> | precisely |
| 19:04 | <Ms2ger> | The question is how much interoperability the spec requires/can require |
| 19:04 | <Hixie> | for codecs, currently, none, as far as i can tell |
| 19:05 | <smaug____> | Could there be some hint which codecs are supported and then the other end wouldn't even try to connect if the right codecs weren't supported? |
| 19:05 | <Hixie> | there is |
| 19:05 | <Hixie> | it uses SDP offer/answer |
| 19:05 | <Hixie> | same as SIP |
| 19:06 | <smaug____> | but PeerConnection isn't about playing any stream |
| 19:06 | <smaug____> | One could just save the stream |
| 19:06 | smaug____ | needs to re-read PeerConnection |
| 19:06 | <Hixie> | you're only allowed to save the stream if you can write it out in a format you support, currently |
| 19:07 | <Hixie> | (the goal is to enable video conferencing, not remote stream saving, so i think it makes sense to natively support the codec negotiation use case and probably doesn't make sense to allow arbitrary unsupported streams to be sent) |
| 19:12 | <smaug____> | Hixie: why you're allowed to save only stream you support? |
| 19:12 | <smaug____> | it would make sense to save the stream and perhaps use some other program to open it |
| 19:12 | <Hixie> | the actual requirement is that you be able to render streams you generate |
| 19:12 | <smaug____> | that way you couldn't really "stream" anything, but at least send videos |
| 19:12 | <Hixie> | so that you can always view local video |
| 19:13 | <smaug____> | sure, that is a different thing |
| 19:13 | <smaug____> | but if you get some other format from the other end |
| 19:16 | <Hixie> | well the idea is that you can't get an unsupported stream, so... :-) |
| 19:16 | <smaug____> | :) |
| 19:17 | <smaug____> | the whole Streaming needs to be extended a bit |
| 19:18 | <smaug____> | so that sending random files becomes possible etc. |
| 19:18 | <smaug____> | I also wonder if there could be just one API for streaming-like communication, not two WebSockets and PeerConnection |
| 19:22 | <zewt> | they're different enough that trying to merge them would probably end up more complex than the sum of the two separate APIs |
| 19:25 | <smaug____> | they are not that different |
| 19:25 | <smaug____> | though both APIs will change so we don't know what they will look like |
| 19:26 | <zewt> | maybe |
| 19:26 | <zewt> | always the tricky issue--between trying to generalize things, and overgeneralizing |
| 19:27 | <smaug____> | true |
| 19:27 | <Hixie> | smaug____: what's the use case? |
| 19:28 | <smaug____> | atm it would be still rather easy to change both APIs since neither of them are being used |
| 19:28 | <zewt> | particularly early in design where, as you said, where it's going hasn't solidified yet |
| 19:28 | <smaug____> | Hixie: use case? to keep web platform easier for developers by not adding too many APIs |
| 19:28 | <smaug____> | note, I'm not sure whether merging the APIs would be good, but something to think about |
| 19:29 | <Hixie> | no i mean for streaming unsupported media |
| 19:29 | <smaug____> | oh |
| 19:29 | <Hixie> | i agree that we should keep the APIs consistent |
| 19:29 | <Hixie> | i've got a bit more work to do on that shortly |
| 19:30 | <smaug____> | streaming unsupported message... say, someone wants to send me some video message, and I can't use my browser to show it on live, but I could just save it and use some other tool to watch it |
| 19:30 | <Hixie> | that seems like an extremely rare case that could just as easily be supported (possibly more easily be supported) by having the file be relayed through the server |
| 19:31 | <smaug____> | true, which is a reason why I said sending files/blobs should be supports |
| 19:31 | <smaug____> | supported |
| 19:31 | <Hixie> | you're saying we _should_ support it because it's rare and not needed? i'm confused. |
| 19:32 | <smaug____> | well, it would be natural to support sending all kinds of streams |
| 19:33 | <smaug____> | but if that case can be handled by just sending blobs, that is ok too |
| 19:33 | <Hixie> | i don't understand why it's natural to want to do P2P transfer of data that needs to be transmitted reliably and for which latency is not an issue. |
| 19:33 | <TabAtkins> | I need to poke around the issue with our idea for just ripping streams off of <input type=file accept>, so we have a nice consistent API living in the DOM. |
| 19:33 | <Hixie> | if anything it seems highly _un_natural to me |
| 19:35 | <smaug____> | Hixie: well, currently sending files isn't really supported by PeerConnection |
| 19:35 | <Hixie> | right, because it's rare and unnecessary |
| 19:35 | <smaug____> | ph |
| 19:35 | <smaug____> | er |
| 19:35 | <smaug____> | oh |
| 19:35 | <smaug____> | :) |
| 19:35 | <smaug____> | Hixie: how so? |
| 19:35 | <smaug____> | is the idea to send files using some other mechanism? |
| 19:35 | <Hixie> | yeah. XHR to the server. |
| 19:36 | <Hixie> | peer-to-peer transfer is hugely complicated but has one redeeming feature: low latency. |
| 19:36 | <smaug____> | ah |
| 19:36 | <Hixie> | if you don't need low latency, then really peer-to-peer transfer is far more pain than it's worth. |
| 19:37 | <smaug____> | hmm, not sure I like that a server needs to store some huge file before someone else can download it from there |
| 19:37 | <Hixie> | doesn't have to be stored, it can just be relayed. |
| 19:38 | <Hixie> | (if you use websockets( |
| 19:38 | <Hixie> | )) |
| 19:39 | <smaug____> | but that causes still quite a bit network traffic to the server |
| 19:39 | <smaug____> | I wonder how skype works when sending files |
| 19:39 | <zewt> | proprietarily :) |
| 19:39 | <zewt> | (also, very poorly, in my experience) |
| 19:39 | <Hixie> | if users really transfer files to and from each other a lot, then it's a different matter |
| 19:40 | <Hixie> | but seriously, who does that anymore? |
| 19:40 | <zewt> | these days they're called "torrents" |
| 19:40 | <zewt> | things no javascript networking API is going to be thorough enough to support: torrents :) |
| 19:41 | <zewt> | (thankfully) |
| 19:41 | <smaug____> | anyone who needs to send huge audio file packages for mixing for example |
| 19:41 | <smaug____> | it is quite handy to use Skype to send a new mix of some song |
| 19:41 | <Hixie> | zewt: actually there's not really any reason you couldn't build torrents on PeerConnection as far as I can tell |
| 19:41 | <zewt> | one use case (not claiming it's a common one): web IRC clients, with DCC transfers or equivalent |
| 19:41 | <Hixie> | smaug____: you wait for the other person to be online to do that? that seems unlikely. |
| 19:42 | <zewt> | (it's common for IRC, though usually for bad reasons) |
| 19:42 | <Philip`> | People occasionally try to send me files (text files, images, etc) over MSN |
| 19:42 | <zewt> | same thing for sending files over IM clients in general, I guess |
| 19:42 | <Philip`> | (which fails because I use Bitlbee) |
| 19:42 | <zewt> | (let's say the same thing simultaneously, ready go) |
| 19:43 | <AryehGregor> | Hixie, people commonly spend all day on these messaging thingies. |
| 19:43 | <smaug____> | exactly |
| 19:43 | <AryehGregor> | I just idle on MSN all the time, except that when I reboot I forget and don't restart it because I never use it. |
| 19:43 | <Hixie> | for sending small files, relaying is fine |
| 19:43 | <zewt> | i'd argue not |
| 19:43 | <AryehGregor> | But I idle on IRC all the time, which is the same sort of idea. |
| 19:44 | <zewt> | when you have millions of users on an IM network, relaying every file transfer through centralized servers is a pretty hefty server requirement when it can often be completely elimianted |
| 19:44 | <zewt> | eliminated |
| 19:45 | <Hixie> | as the only person here who actually works for a company who runs an IM network as far as I know, I'm not at all convinced. :-) |
| 19:45 | <zewt> | i'd say typical size for files over IM clients is a few megs, at least (eg. larger than text files, but typically not CD images) |
| 19:45 | <Hixie> | trying to do it peer-to-peer probably means far more support costs than it would cost just to do it via relay |
| 19:45 | <TabAtkins> | Hixie: to be fair, the chat network is well-integrated into the email client, so there's little need to directly transfer files through the chat. |
| 19:45 | <smaug____> | Hixie: does anyone actually use Google's IM ;) |
| 19:46 | <Hixie> | TabAtkins: well yeah, exactly |
| 19:46 | <zewt> | Hixie: i think your company has more bandwidth available than most :) |
| 19:46 | <TabAtkins> | smaug____: ...yes? It's the only IM client I use, largely because I have gmail up at all times. |
| 19:46 | smaug____ | has stopped using gmail web client |
| 19:46 | <zewt> | most IM clients are entirely peer-to-peer for file transfers, I *think* |
| 19:47 | <zewt> | or at the very least, most of the time with some kind of fallback (Skype feeds files through other users when it can't make a direct connection, which doesn't work very well--too slow) |
| 19:48 | <smaug____> | but usually Skype's file transfer works really well |
| 19:48 | <Philip`> | MSN apparently has 350 million active users per month (as of 2009), which is apparently about double Gmail's users |
| 19:48 | <zewt> | (not saying this is necessarily a use case that this API should try to handle--just that it is a real case) |
| 19:48 | <Hixie> | anyway. we can always add features later. we can't remove features. so let's start small. |
| 19:48 | <zewt> | (not familiar enough with the API to argue the former) |
| 19:48 | <Hixie> | especially when it's not clear we need the features :-) |
| 19:50 | smaug____ | goes jogging and will think about a monster API which combines WebSockets and PeerConnection and which supports file transfer and any type of video streams :) |
| 19:57 | <hsivonen> | wasn't it part of the plan to be able to filter the bytes that come from Web Socket / Peer Connection before pushing them to a video decoder? |
| 19:58 | <Hixie> | there was a plan? |
| 19:58 | <hsivonen> | so that sites that implement their own obfuscations schemes in JS and stop whining about the lack of built-in DRM |
| 19:58 | <Hixie> | oh, no, i have no plan to support that kind of thing. |
| 19:58 | <Hixie> | the current model would support it though, fwiw. We'd just have to create a descendant of Stream that takes a Stream as input and invokes a callback regularly or some such. |
| 19:59 | <hsivonen> | Hixie: so if the current model would support it, you are planning on enabling it |
| 19:59 | <hsivonen> | even if not deliberately |
| 19:59 | <Hixie> | no |
| 19:59 | <Hixie> | the model could be extended to support it, it doesn't support it currently. |
| 20:00 | <hsivonen> | Hixie: oh |
| 20:00 | <Hixie> | and i'm not planning on enabling it, though it could be enabled as a side-effect of the design. |
| 20:00 | <Hixie> | a hallmark of good design is that it enables all kinds of things that weren't planned for :-) |
| 20:02 | <tw2113> | i think after this side of Pearl Jam's album Ten is done spinning, i should hit up the post office quick |
| 20:08 | <tw2113> | oops, wrong room :D |
| 20:55 | <jgraham> | Hixie: Would it be possible for you to look at the Mozilla history API changes soon? |
| 20:55 | <Hixie> | how soon is soon? |
| 20:56 | <jgraham> | Well the sooner the better, really |
| 20:56 | <jgraham> | But obviously it is your schedule :) |
| 20:56 | <Hixie> | i have to do something about issue 152, i'm already late with issue 147, and i have to send this feedback on p2p stuff |
| 20:57 | <Hixie> | also have to update the websocket api spec |
| 20:57 | <Hixie> | oh and issue 131 is coming up |
| 20:57 | <Ms2ger> | jgraham, obviously you should touch all older bugs :) |
| 20:58 | <Hixie> | oh man, 155 and 144 are coming up too |
| 20:59 | <jgraham> | Ms2ger: Or stop the HTMLWG chairs from cluttering up Hixie's life with fixed deadline issues that don't correspond to things I care about |
| 20:59 | <jgraham> | Not sure how to do that though |
| 20:59 | <Hixie> | well one way is to write the CCPs for those, that would really help |
| 20:59 | <Ms2ger> | That works too |
| 21:00 | <Hixie> | but i can understand if you're not inclined to do that :-) |
| 21:00 | <Hixie> | jgraham: is there a specific thread for the history stuff already in whatwg.org/issues? |
| 21:00 | <Hixie> | or bug#? |
| 21:00 | <Ms2ger> | There's a bug |
| 21:00 | <Ms2ger> | I think you filed it |
| 21:01 | <Hixie> | k |
| 21:01 | <jgraham> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12277 |
| 21:02 | <jgraham> | I think making me write CCPs for the multimedia stuff would not be a winning strategy :) |
| 21:08 | <Hixie> | could you write one for 147? |
| 21:08 | <Hixie> | anyway, i think i should be able to get to the history stuff in the near future |
| 21:08 | <Hixie> | (as in within the next month) |
| 21:08 | <Hixie> | keep bugging me about it |
| 21:14 | <jgraham> | Hixie: OK, thanks |
| 21:31 | <twisted> | hi, question, in Chrome background-size works if I put it on 80%. In Firefox it doesn't. I've checked and now also have the -moz-background-size set but still nothing in Firefox... |
| 21:31 | <twisted> | what am I doing wrong? |
| 21:43 | <TabAtkins> | Does the version of FF you're testing against support background-size? |
| 21:47 | <aho> | https://developer.mozilla.org/en/css/-moz-background-size |
| 21:47 | <aho> | 3.6 requires a prefix, 4.0 doesnt anymore |
| 21:53 | <twisted> | using 4.0 |
| 21:53 | <twisted> | http://twixted.hatkeintuv.de:8888/all4wheels/ that's the site in question |
| 21:54 | <twisted> | if you inspect the element #main-menu li a |
| 21:54 | <twisted> | it does show the css it should use but somehow it doesn't do anything with it |
| 21:58 | <TabAtkins> | Try changing the 'background' declaration on line 7 to just background-image. |
| 21:58 | <TabAtkins> | That *shouldn't* affect anything, but FF may be buggy and reseting the -size property when you use the background shorthand. |
| 21:59 | <twisted> | it now dissapeared completely |
| 21:59 | <twisted> | even went *poof* in chrome |
| 21:59 | <twisted> | lemme check |
| 21:59 | <TabAtkins> | Oh, right. The no-repeat value there would then need to be pulled out into background-repeat. |
| 22:00 | <twisted> | whoo |
| 22:00 | <twisted> | works |
| 22:00 | <TabAtkins> | If that worked, then FF is buggy. File a bug, please? |
| 22:00 | <twisted> | firefox actually does the center center more nicely then chrome |
| 22:00 | <twisted> | uhm, where? |
| 22:01 | <TabAtkins> | bugzilla.mozilla.org |
| 22:01 | <twisted> | cool I will |
| 22:03 | <twisted> | funny since I fixed it in Firefox now Chrome suddenly also does it properly centered |
| 22:04 | <TabAtkins> | Same deal - background-size was being reset by the 'background' rule, because 'background' was more specific than all the background-* rules you had set generally on the links. |
| 22:05 | <TabAtkins> | Why are you doing this with backgrounds, though? Why not just use an <img> with @alt, rather than putting in real text, hiding it, then putting in an image via the background property? |
| 22:16 | <twisted> | TabAtkins: because drupal #^@#%& sucks |
| 22:17 | <twisted> | already had to make a custom function to get an extra span |
| 22:17 | <TabAtkins> | Ah, indeed it does. I recommend not using it. |
| 22:17 | <twisted> | well considering the budget for this website |
| 22:17 | <twisted> | it's probably the cheapest solution |
| 22:17 | <twisted> | joomla really sucks |
| 22:17 | <twisted> | wordpress is for blogs |
| 22:18 | <TabAtkins> | I've been reasonably happy with Django, if you really need a CMS. |
| 22:22 | <twisted> | I unfortuanly spend waaay too much time already on Drupal atm to switch |
| 22:27 | <twisted> | still didn't get my bugzilla email :p |
| 22:27 | <twisted> | ah spam folder lol |
| 22:30 | AryehGregor | suspects he could construct a minimal test-case for the really annoying Web Inspector bug in Chrome, with some effort |
| 22:30 | <AryehGregor> | Unfortunately, I lack the time to expend effort. |
| 22:31 | <AryehGregor> | I think that when scripts are reloaded and change, it still partially caches the old version of the script sometimes, which means it only lets you set breakpoints at lines that you could have set breakpoints at in the previous version of the file. |
| 22:31 | <TabAtkins> | Your margins is too narrow? |
| 22:35 | <twisted> | TabAtkins: https://bugzilla.mozilla.org/show_bug.cgi?id=641977 |
| 22:52 | <zot--> | dreaming of the day we can have some consistency in keyboard shortcuts for web apps :| |
| 22:53 | <zewt> | chrome seems really good at it, not eating many alt- keys; but everyone else... |
| 22:54 | <twisted> | TabAtkins: happy to have been able to file a bug! |
| 22:55 | <TabAtkins> | Thanks for doing so! |
| 22:56 | <zewt> | can't even use , and . as hotkeys--Opera users get irate |
| 22:57 | <TabAtkins> | We need a new hyper key which is explicitly reserved for use by apps. |
| 22:58 | <zewt> | heh |
| 22:58 | <zewt> | every time a new encapsulation layer is added to computers, a new key is needed |
| 22:58 | <zewt> | windows key, control key, web key |
| 23:07 | <TabAtkins> | Just do what I do and say that you get the web key when you press Alt+Ctrl+Windows at the same time. |
| 23:07 | <TabAtkins> | (I use this combo to move between desktops.) |
| 23:09 | <zewt> | i'll avoid using key combinations that many keyboards physically can't register. heh |
| 23:14 | <zewt> | heh, i'm half-inclined to just stomp over browser hotkeys (since they'll let you, generally) for web apps, so long as they don't give a better option :| |
| 23:27 | <hober> | TabAtkins: we just need to get everyone to use the space cadet keyboard; then we'll have several modifiers for use by web apps |
| 23:31 | <TabAtkins> | hober: Yup, that'd work. |
| 23:32 | <zewt> | browsers just need to let go of alt/meta :| |
| 23:33 | <zewt> | was easier for chrome to do (from the beginning) than for old browsers (with users and user habits), but I think it's just something to get over |
| 23:44 | <TabAtkins> | twisted: Sorry for misinforming you - I somehow missed the 'background-size' in the list of properties that the 'background' shorthand reset. |
| 23:44 | <TabAtkins> | So Firefox's behavior is correct, Chrome's isnt. |
| 23:46 | <twisted> | huh, but isn't the idea of CSS that it overrides based on cascading? |
| 23:47 | <twisted> | so my latter definition of the size should still affect it |
| 23:47 | <twisted> | and not ignore? |
| 23:49 | <TabAtkins> | twisted: the selector setting the plain 'background' property has higher specificity. |
| 23:58 | <twisted> | then it still doesn't get overidden? |
| 23:59 | <TabAtkins> | No, because the 'background' shorthand acts like all the component properties were being set instead. Thus, the "background-size:initial" that is implied by your rule overrides the "background-size:80%" that you actually have. |
| 23:59 | <TabAtkins> | Same with the background-position. |