| 10:29 | <phrearch> | morning |
| 10:30 | <phrearch> | does anyone know if the html5 audio tag supports streaming yet? (in some browser implementation) |
| 12:26 | <zcorpan> | phrearch: i think that's something that hasn't been tested much but should work fine in theory |
| 12:27 | <phrearch> | zcorpan: i thought about adding a shoutcast player in a webpage |
| 12:27 | <phrearch> | worth to give it a try |
| 12:28 | <zcorpan> | sure |
| 12:28 | <zcorpan> | file any bugs you find :) |
| 12:36 | <zcorpan> | one thing i'm concerned about with websockets is that most generic websocket servers seem to just echo the Origin field without giving an obvious way for the app writer to restrict which Origins to allow, let alone making it clear to the app writer that it is his responsibility to restrict connections from different origins |
| 12:37 | <zcorpan> | so people might assume that "websockets uses origin-based security model" and go ahead and assume that the browser will disallow connections from other origins |
| 12:44 | <zcorpan> | i guess i should send email to hybi |
| 12:48 | <hsivonen> | MikeSmith: I believe I've now restored all *.validator.nu stuff except s.validator.nu |
| 12:49 | <hsivonen> | some services will experience some DNS lag, particularly livedom.validator.nu |
| 12:57 | <phrearch> | zcorpan: are there some docs how to secure websockets properly? |
| 12:58 | <phrearch> | im currently using websockets alot, but havent thought much about security yet |
| 13:02 | <zcorpan> | phrearch: if you only want to allow connections from your own site, you need to either hardcode your site's origin in the Sec-WebSocket-Origin response field or refuse the connection when the Origin request field does not match your site's origin |
| 13:02 | <zcorpan> | just sent an email to hybi |
| 13:03 | <phrearch> | hm, isnt the origin a header option? |
| 13:03 | <zcorpan> | what do you mean option? |
| 13:03 | <phrearch> | ehm, i mean isnt origin something that can be forged? |
| 13:04 | <phrearch> | i probably should check the websocket code im using for the sec-websocket-origin thing |
| 13:06 | <phrearch> | http://paste.pocoo.org/show/294567/ |
| 13:06 | <phrearch> | i guess its handled already in the code |
| 13:10 | <zcorpan> | you can't forge the origin field in a browser without actually running script in your origin, in which case it's already game over :) |
| 13:10 | <zcorpan> | handshake.append("Sec-WebSocket-Origin: %s" % (originHeader)) |
| 13:11 | <zcorpan> | unless i misread the code, that echos the origin value, which thus allows connection from anywhere |
| 13:19 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/713 - test your websocket server from the origin 'http://software.hixie.ch'; (change ws://localhost:12345/test to whatever URL your websocket server lives at) |
| 18:06 | <TabAtkins> | I couldn't figure out why davidc's post was giving me a different renderig in Chrome than FF. Then I realized it's MathML! Yay! |
| 18:06 | <jgraham> | Took me a while to realise it was text/html. More yay! |
| 18:07 | TabAtkins | wishes Chrome exposed the Page Info stuff that ff does. FF is still a better browser for doing webdev in. ;_; |
| 18:08 | <TabAtkins> | I don't understand - can someone explain to me why the "pre-multiplied" color has the multiplication in it, while the post-multiplied color doesn't? |
| 18:09 | <paul_irish> | TabAtkins: what Page Info? |
| 18:09 | <TabAtkins> | paul_irish: Right click on a page in firefox, and Page Info is a menu option. |
| 18:09 | <TabAtkins> | right below "view page source" |
| 18:09 | <paul_irish> | but what's the info in there thats useful for you |
| 18:09 | <TabAtkins> | Oh! Type and encoding, mostly. |
| 18:10 | <TabAtkins> | I've had to look that information up a couple times over my webdesign career. |
| 18:10 | <TabAtkins> | If it turns out this is exposed somewhere in the console I'll be happy. |
| 18:11 | <paul_irish> | not in the console but i typically get it from the response headers in the network tab |
| 18:11 | <TabAtkins> | I don't see a Network tab. Do you mean Resources? |
| 18:12 | <jgraham> | paul_irish: Does it also have the values the browser is actually using? |
| 18:12 | <jgraham> | Since these can be different in strange and unexpected ways |
| 18:12 | <Philip`> | TabAtkins: Pre-multiplied colour has had the alpha multiplied into the colour components before rendering, hence the "pre" |
| 18:13 | <paul_irish> | TabAtkins: you're telling me you don't run dev channel chrome? lol |
| 18:13 | <TabAtkins> | Hm, I don't recall all this information in the Headers subtab before. Just a few weeks ago I was trying to debug some eventsource code and had to switch to firefox so I coudl intercept request headers... |
| 18:13 | <Philip`> | TabAtkins: whereas non-pre-multiplied colours delay the multiplication until you perform the compositing operation |
| 18:13 | <TabAtkins> | paul_irish: No. ^_^ |
| 18:13 | <paul_irish> | terrible, just terrible. |
| 18:13 | <TabAtkins> | Philip`: Ah, so the pre/post is referring to the opposite thing I was thinkinga bout. |
| 18:14 | <Philip`> | TabAtkins: I think almost nobody ever uses the term "post-multiplied", and I don't think that term makes any sense because you're not multiplying after anything |
| 18:15 | <Philip`> | TabAtkins: You're just not multiplying before everything, so it's non-pre :-) |
| 18:16 | <TabAtkins> | Philip`: Kk, I suppose that makes sense. |
| 18:17 | <TabAtkins> | Color math still confuses me, unfortunately. I haven't been able to glean sufficient understanding from occasional snatches of code and wikipedia skimming. |
| 18:21 | <Philip`> | I think the original Porter-Duff paper is quite readable and useful |
| 18:21 | <Philip`> | (http://keithp.com/~keithp/porterduff/) |
| 18:21 | <TabAtkins> | Thanks, I'll read it! |
| 18:53 | <david_carlisle> | TabAtkins: chrome could pick up the webkit mathml code you know:-) |
| 18:53 | <TabAtkins> | I need to chat around and see what our progress on that is. |
| 18:54 | <TabAtkins> | I want math in my posts, dammit. |
| 19:03 | <bckenny> | TabAtkins: yes, please |
| 19:04 | <bckenny> | the stix fonts licensing was kind of messy last I heard though |
| 19:06 | <david_carlisle> | bckenny: its the SIL font licence, but FF for instance doesn't distribute stix, it just expects that some font with those characters is there, |
| 19:08 | <bckenny> | does that work well generally? it seems like a consistent and reliable font would at the very least be desirable |
| 19:08 | <david_carlisle> | I think currently the webkit code does assume stixgeneral in its internal use of css, probably it would be better if it didn't (so i could experiment with other fonts:-) |
| 19:09 | <david_carlisle> | well yes having a font that you could rely on being there would be good, but ... |
| 19:10 | <bckenny> | i'm open to other ways, i just want it to work without me having to work too hard for it :) |
| 19:11 | <david_carlisle> | you and me both:-) |
| 19:11 | <bckenny> | and a 2.6MB font set is too big for me just to have equations in my blog |
| 19:13 | <david_carlisle> | yes eventually hopefully it'll "just be there" like times roman or something, but we're not quite there yet |
| 19:15 | <david_carlisle> | and also (coming back to not hard coding reliance on stix) a large class of documents just use fractions superscripts + 1 and brackets, and they don't need anything quite as exotic as the stix fonts |
| 19:20 | <zcorpan> | anyone have a good link about cookie "path" feature being useless because of same-origin-policy? |
| 19:35 | <Dashiva> | zcorpan: Isn't it just making an iframe to the path you want and reading contentWindow.document.cookie? |
| 19:39 | <zcorpan> | yeah. i found http://www.webappsec.org/lists/websecurity/archive/2006-03/msg00000.html |
| 21:35 | <Aleoss> | Suggestion to add to HTML5: Allow <label> to interact with <select> |
| 21:36 | <gsnedders> | Aleoss: Interact in what way? |
| 21:36 | <Aleoss> | By focusing it. |
| 21:39 | <gsnedders> | Aleoss: HTML5 already allows label@for to point to a select, if it doesn't focus it that's a UI issue and not a spec issue |
| 21:41 | <Aleoss> | gsnedders: Well I'm using <!DOCTYPE html> and the latest version of Firefox and clicking on <label for="sel">Select:</label> doesn't focus <select id="sel"> |
| 21:41 | gsnedders | lets someone who actually knows about Gecko's impl of form elements comment more |
| 21:45 | <Peter-> | Aleoss, clicking on the label @ http://peter.sh/files/select-focus-via-label.html does not focus the label for you? |
| 21:46 | <Peter-> | Firefox 4b7 properly focusses the select here |
| 21:55 | <Aleoss> | Peter-: I must have done something wrong in my code then. Not sure why it wasn't selecting before. I re-wrote that portion and it seems to work now. |
| 22:56 | <Xano__> | Is it semantically correct to use the address tag for a restaurant's contact information on a website with restaurant reviews? |
| 22:57 | <Xano__> | Most explanations I find say something like "the address tag is meant for contact information of (the author of) a section" |
| 22:57 | <Xano__> | The restaurant isn't the author, but it does count as contact info for a particular section |
| 22:58 | <AryehGregor> | Xano__, seems to be correct usage according to the spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-address-element |
| 22:58 | <AryehGregor> | It's not so clear. |
| 22:58 | <AryehGregor> | It just says "the contact information for its nearest article or body element ancestor". |
| 22:59 | <Xano__> | AryehGregor: That looks like what I do is semantically correct then |
| 22:59 | <AryehGregor> | Or close enough, sure. |
| 22:59 | <Xano__> | Is the it allowed to contain block level elements? |
| 23:00 | <AryehGregor> | Yes, the content model is " Flow content, but with no heading content descendants, no sectioning content descendants, and no header, footer, or address element descendants." |
| 23:00 | <AryehGregor> | If you follow the link for "flow content", it includes what HTML 4 refers to as block-level elements. |
| 23:03 | <Aleoss> | Which is best to use and why? <object> or <embed> or <video> |
| 23:05 | <TabAtkins> | Aleoss: What are you trying to do? If it's "embed a video", use <video>. |
| 23:05 | <AryehGregor> | (probably with fallback unless you don't care about IE and old browsers and don't mind encoding in at least two formats) |
| 23:07 | <Xano__> | Also, do mobile browsers already add extra features to <address>, like integration with a maps application? |
| 23:07 | <AryehGregor> | What do you mean by "already"? |
| 23:07 | <TabAtkins> | Xano__: I don't believe any browser does anything special for <address> at all. |
| 23:07 | <AryehGregor> | <address> has been around for ages, way before HTML5. |
| 23:07 | <AryehGregor> | It's practically unused, so I don't think anyone adds features for it. |
| 23:08 | <Xano__> | AryehGregor: But its meaning is different in HTML5, right? |
| 23:08 | <AryehGregor> | Not really. |
| 23:08 | <Xano__> | At least I thought so |
| 23:08 | <jgraham> | Xano__: AFAIK no one adds any features around <address> and it is widely misused per the letter of the spec |
| 23:08 | <AryehGregor> | Pretty much the same as in HTML 4. |
| 23:08 | <AryehGregor> | Maybe a little broader. |
| 23:08 | <jgraham> | So it is really irrelevant how you use it |
| 23:08 | <jgraham> | Except insofar as it makes you happy |
| 23:08 | <Xano__> | okay |
| 23:08 | <Xano__> | Thanks for the info :) |
| 23:09 | <jgraham> | Or you have something like microdata which imposes additional semantics that are actually consumed by someone |
| 23:09 | <jgraham> | (Hixie may disagree with this view) |
| 23:09 | <Xano__> | Nah, it's just a (crappy) mobile website |
| 23:13 | <jgraham> | (one might posit that per-spec use of <address> now would facilitate the addition of some microdata or microformats or whatever later on, if those formats assumed <address> was used as the spec says) |
| 23:18 | <AryehGregor> | (one might also posit that that sort of planning is useless and you should work on things like that after you have the features in place) |
| 23:19 | <jgraham> | (YAGNI in other words) |
| 23:19 | <Xano__> | This may not be the right channel to ask, but I'll try anyway. I have used an iframe to include a GMap on a page (little quick & dirty bc greedy client). THe problem is that it works great in desktop browsers, but mobile browsers show a white rectangle, with a Sign in link, and "View in classic | mobile" and a copyright notice, but no map and I cannot click the link. Even if I make Firefox switch to an iPhone 3 user agent string, it still s |
| 23:19 | <Xano__> | the map. What may be wrong? |
| 23:19 | jgraham | concludes from recent email that the a11y people have not understood <hgroup> |
| 23:20 | <jgraham> | Which is sad because headings are a good example of semantic markup that it is worth doing right |
| 23:20 | <Xano__> | Asking here because nobody else knows and people here have a lot of experience with client sided coding in general |
| 23:23 | <paul_irish> | Xano__: this isn't a support channel.. sounds like the google maps user groups would be the best place for this issue. |
| 23:25 | <AryehGregor> | Well, it's sometimes okay for standards-based support, but it's pretty lousy for support for proprietary APIs. |
| 23:25 | <AryehGregor> | Not many of us are actually client-side developers. |
| 23:25 | <paul_irish> | speak for yourself. :) |
| 23:26 | AryehGregor | is pretty sure he is |
| 23:26 | <paul_irish> | heh. |