| 00:00 | <Rik`> | yep, thanks |
| 00:11 | <Rik`> | TabAtkins: In 3, "then the first child of placed against the left edge of the flexbox's content area" first child IS placed ? |
| 00:11 | <TabAtkins> | Yup, fixed. |
| 00:20 | <figaroo> | Hi everyone! |
| 00:20 | <Rik`> | TabAtkins: in 5, the text under the first example is marked as an example |
| 00:26 | <figaroo> | Does HTML5 support the /> syntax? For example, <br/> |
| 00:26 | <TabAtkins> | Rik`: Fixed. |
| 00:26 | <TabAtkins> | figaroo: For void elements (ones that don't have end tags, like <br>) you can use the <br/> syntax too, if you want. |
| 00:27 | <TabAtkins> | But non-void element like <p>, <div>, etc. can't be self-closed, even if they're empty. So you can't do <div/>. |
| 00:27 | <figaroo> | Okay. |
| 00:27 | <TabAtkins> | (Basically, the / is always ignored in HTML.) |
| 00:27 | <figaroo> | That was the question I was leading up to. |
| 00:28 | <figaroo> | Why is it that HTML5 didn't add the ability to close a tag with />, that is, <div/> |
| 00:28 | <figaroo> | ? |
| 00:28 | <TabAtkins> | figaroo: Because no existing browser supports that for HTML, so if you tried to do so it would break your page in all current browsers. |
| 00:29 | <figaroo> | oh |
| 00:29 | <figaroo> | So it's not backwards compatible, I get it. |
| 00:29 | <TabAtkins> | Yeah, the current behavior is what everyone already does. |
| 00:29 | <TabAtkins> | Of course, if you serve your HTML as application/xml, you can self-close, because that's valid XML. |
| 00:30 | <figaroo> | oh |
| 00:30 | <figaroo> | So this is supported in XHTML, right? |
| 00:30 | <TabAtkins> | Yeah. |
| 00:30 | <figaroo> | As long as you send it with the application/xml MIME? |
| 00:30 | <TabAtkins> | As long as you're actually serving XML, not HTML that you're trying to pretend is XHTML. ^_^ |
| 00:30 | <TabAtkins> | Yup. |
| 00:31 | <TabAtkins> | Anything sent with text/html is HTML, full stop. You can't serve XHTML with text/html. |
| 00:31 | <TabAtkins> | (Though you can do some XHTML-ish things, like self-close your void elements, even in the HTML syntax.) |
| 00:32 | <figaroo> | by "even in the HTML syntax" you mean "even if you serve it with text/html"? |
| 00:32 | <TabAtkins> | Yes. |
| 00:32 | <figaroo> | Oh. |
| 00:32 | <figaroo> | How do you do that? |
| 00:32 | <TabAtkins> | You serve HTML in the HTML syntax when you send it as text/html, and in the XHTML syntax when you send it as application/xml. |
| 00:33 | <figaroo> | Yes, I'm aware of that. However, can you send an XHTML document with text/html and still have the browser recognize the /> closing syntax? |
| 00:34 | <TabAtkins> | Oh, sorry. Yeah, that's what I was just mentioning. HTML ignores the / if you're using the HTML syntax, so you can do <br/> and still be okay. |
| 00:34 | <TabAtkins> | (Because it's the same as just writing "<br>".) |
| 00:36 | <figaroo> | Yea, the point I'm trying to make is, can you make <div/> syntax. |
| 00:37 | <figaroo> | Because, sometimes I want to create an empty div, and the easiest way to do that is <div/> |
| 00:37 | <TabAtkins> | No. In HTML syntax, the / is always ignored. Saying "<div/>" is always identical to "<div>". HTML doesn't *really* allow the self-closing syntax, it just ignores certain uses of it. If you want real self-closing you have to use XML. |
| 00:37 | <TabAtkins> | And <div></div> isn't that much more difficult than <div/>. ^_^ |
| 00:40 | <figaroo> | it's not as difficult, however it seems cleaner, IMO. |
| 00:40 | <figaroo> | So if I serve an XHTML Transitional doc with the text/html MIME, will browsers understand <div/>? |
| 00:40 | <daedb> | No. |
| 00:40 | <TabAtkins> | No. If you serve it with text/html, it's HTML. Always and forever. |
| 00:41 | <TabAtkins> | All browsers have always treated pages as plain HTML when served as text/html. If we changed that for some reason, 90%+ of the "xhtml web" would immediately break with parsing errors. |
| 00:41 | <figaroo> | Ok, cause you said you can do XHTML-like things in HTML even if you serve text/html. I'm assuming you ment that you can do <br/> in HTML. |
| 00:42 | <TabAtkins> | figaroo: Yeah, just little things like that, which are harmless and browsers already do. |
| 00:42 | <figaroo> | Yea, I read somewhere that XHTML docs on the web aren't "really" XHTML, because they don't change the MIME to application/xml. |
| 00:42 | <TabAtkins> | (Harmless because <br>, <meta>, <link>, etc already don't have an end tag, so using a syntax that says "I'm going to omit this element's end tag" is harmless.) |
| 00:42 | <Dashiva> | Isn't <br></br> actually <br><br>? |
| 00:43 | <TabAtkins> | Dashiva: Yes. |
| 00:43 | <Dashiva> | So not 100% harmless |
| 00:43 | <TabAtkins> | But that's an additional special rule, on top of any self-closing concerns. |
| 00:43 | <TabAtkins> | Dashiva: Treating them as self-closing is harmless. Trying to un-self-close them isn't. ^_^ |
| 00:44 | <figaroo> | In XHTML, the browser is suppose to quite executing the document if it has errors? |
| 00:44 | <Dashiva> | Oh, my bad |
| 00:44 | <figaroo> | or is that only for Strict XHTML? |
| 00:44 | <Dashiva> | I didn't read carefully enough |
| 00:44 | <TabAtkins> | figaroo: That's how XML works. The fabled "draconian error handling". |
| 00:45 | <TabAtkins> | That is, imo, the primary reason why XML is still a failure on the web, and will continue to be for the forseeable future. |
| 00:46 | <figaroo> | Oh |
| 00:46 | <figaroo> | what if there was a more unobtrusive way to handle errors |
| 00:47 | <figaroo> | like, the page could continue to run, but dispatch an error to the console or something. |
| 00:47 | <Dashiva> | Sort of like... HTML? |
| 00:47 | <TabAtkins> | Then you'd have HTML, more or less. (There'd be some differences, obviously, but fairly minor.) |
| 00:47 | <figaroo> | HTML logs errors in the console? |
| 00:47 | <TabAtkins> | No, but it recovers gracefully from errors. That's the important bit. |
| 00:48 | <Dashiva> | Current browsers don't, but there's nothing preventing them from doing so |
| 00:48 | <figaroo> | Yea, the important bit, but the other bit would be nice. |
| 00:48 | <TabAtkins> | Go file bugs on browsers. They can do that if they want right now. ^_^ |
| 00:48 | <figaroo> | Is it in the standards though? |
| 00:49 | <TabAtkins> | Doesn't need to be. It's UI. |
| 00:49 | <figaroo> | If it mentioned in the standards to do so, I'm sure the browser makers would be more inclind to implement it. |
| 00:49 | <Dashiva> | HTML5 defines what a parse error is |
| 00:49 | <Dashiva> | The rest is UI |
| 00:49 | <figaroo> | Oh |
| 00:50 | <TabAtkins> | Whether a browser logs errors or not has no effect on whether a page displays correctly, so we don't care about it for web standards. |
| 00:50 | <daedb> | Maybe someone could make an extension for logging parse errors in the console? |
| 00:50 | <figaroo> | That's what I meant to ask; Does the standard mention the different errors. |
| 00:50 | <figaroo> | but ok |
| 00:50 | <TabAtkins> | daedb: You'd have to hook too low. Or run your own parser over the source. |
| 00:50 | <figaroo> | Yea |
| 00:51 | <figaroo> | I think firebug in firefox logs html and css errors, but I can't remember |
| 00:51 | <TabAtkins> | For now, though, validators do the job of reporting parse errors. |
| 00:51 | <daedb> | TabAtkins: Ok, just a late night idea anyway. I don't know much about how the extensions work :) |
| 00:52 | <TabAtkins> | daedb: I dunno, maybe it's possible. I don't know much about how they work either. ^_^ |
| 01:02 | <figaroo> | HTML5 spec defines the video element right? |
| 01:05 | <Philip`> | figaroo: Yes |
| 01:05 | <figaroo> | k |
| 01:06 | <figaroo> | I noticed that Chrome doesn't currently fully support the buffered media property for video/audio. |
| 01:06 | <figaroo> | Is that because it's new in the spec? |
| 01:11 | <TabAtkins> | figaroo: Yeah, we just haven't fully implemented the latest changes. |
| 01:20 | <figaroo> | We? |
| 01:21 | <figaroo> | Are you apart of the chrome team? |
| 01:23 | <TabAtkins> | Yeah. |
| 01:25 | <jwm> | we're all apart of the chrome team! |
| 01:25 | <jwm> | using beta software >:) |
| 01:25 | <TabAtkins> | Chromium team, for you. ^_^ |
| 01:25 | <jwm> | hah |
| 01:27 | <figaroo> | so everyone here in this IRC is from the chrome team? O.o |
| 01:27 | <figaroo> | except me* |
| 01:27 | <TabAtkins> | No, most of them are from Opera. ^_^ |
| 01:27 | <TabAtkins> | jwm was joking about how, if you use Chromium, you can count yourself a contributor to Chrome. |
| 01:29 | <TabAtkins> | Most of the active people in the room are from one of the browser vendors, though. |
| 01:30 | <jwm> | I'm just a loon with impossible goals |
| 01:41 | <figaroo> | I was wondering. When the user scrubs ahead of what's currently buffered, a new buffer is added to the TimeRange (correct me if I'm wrong in any of this). Is the old buffer still accessable for playback? |
| 01:47 | <roc> | figaroo: it is if it's still in the 'buffered' TimeRagnes |
| 01:48 | <figaroo> | still? Is there ever a situation when a range gets removed from the 'buffered'? |
| 01:49 | <roc> | sure |
| 01:49 | <roc> | the browser can discard data from its buffer at any time |
| 01:51 | <figaroo> | ok |
| 01:52 | <figaroo> | so if it is still within the buffered attribute can playback be set without there being any need for re-buffering? |
| 01:57 | <figaroo> | This is what I'm trying to ask. What happens when a previous buffer range starts to play again; Does the UA buffer at the end of the range till it reaches the second range, and then concatenates the two ranges into larger range? |
| 02:22 | <roc> | figaroo: that's what we'd do |
| 02:22 | <roc> | in fact that's what we do do already |
| 02:22 | <roc> | we just don't expose it in 'buffered' yet |
| 02:41 | <gavin> | jgraham: I'm in Toronto |
| 02:41 | <gavin> | my server is in San Jose |
| 02:41 | <gavin> | (this client) |
| 02:41 | <gavin> | the client collecting the stats is at home |
| 03:12 | <MikeSmith> | boblet: Mozilla dev releases may have support for the progress element relatively soonish |
| 03:12 | <MikeSmith> | so you doctors might want to be ahead of the game and have an article on progress staged up and ready to go |
| 03:59 | <MikeSmith> | how is what's discussed in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026488.html different from http://www.w3.org/TR/widgets/ ? |
| 03:59 | <MikeSmith> | aboodman: ↑ |
| 04:00 | MikeSmith | peruses http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html |
| 04:04 | <MikeSmith> | nessy: wondering where you brought up HTTP streaming for media resources before and who didn't reply |
| 04:04 | <MikeSmith> | WebApps WG? |
| 04:04 | <nessy> | would that be the right place? |
| 04:05 | <nessy> | I only asked a few people personally |
| 04:05 | <nessy> | and I think it was discussed on whatwg mailing list, but not specifically like that |
| 04:05 | <nessy> | s/whatwg/public-htmlt/ |
| 04:05 | <nessy> | sorry |
| 04:05 | <nessy> | I can send a similar email to public-html - I'm just trying to find the right place to get it done! |
| 04:06 | <MikeSmith> | nessy: no, I'm not complaining |
| 04:07 | <MikeSmith> | I don't think public-html would be the optimal place anyway |
| 04:07 | <nessy> | where do you think it would belong? |
| 04:07 | <nessy> | that's what I thought... |
| 04:07 | <MikeSmith> | I think discussion on the whatwg list is the right place for now |
| 04:07 | <nessy> | excellent |
| 04:08 | <jwm> | what does nessy want to do? |
| 04:08 | <nessy> | adaptive HTTP streaming needs standardisation across formats, not just for H.264 |
| 04:09 | <jwm> | cool |
| 04:09 | <nessy> | see email to whatwg |
| 04:09 | <othermaciej> | nessy: what needs to be defined for it? |
| 04:09 | <jwm> | that's more of a container issue right? |
| 04:09 | <MikeSmith> | maybe W3C needs to do some thinking about getting a group organized specifically around video |
| 04:09 | <othermaciej> | I think Apple's HTTP streaming support is an IETF Internet-Draft |
| 04:09 | <nessy> | no, not container - it's a protocol issue really |
| 04:10 | <nessy> | othermaciej: indeed - and possibly Apple's HTTP streaming approach can be adopted by everyone |
| 04:10 | <nessy> | but right now everyone goes out and rolls their own scheme |
| 04:10 | <nessy> | there is no central place to have everyone get together and bang it out - test it on other formats etc |
| 04:11 | <jwm> | welcome to the web :) |
| 04:11 | <jwm> | I keep trying to get people together for project work |
| 04:11 | <doublec> | I think it'd take someone to bang it out then say "hey look, what do you think" and form a project around it |
| 04:11 | <othermaciej> | I guess it depends on the MPEG-2 container: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03 |
| 04:11 | MikeSmith | finds http://tools.ietf.org/html/draft-pantos-http-live-streaming-03 |
| 04:11 | <jwm> | never pans out |
| 04:11 | <jwm> | doublec is exactly right |
| 04:11 | <nessy> | MikeSmith: ha! that's exactly what I told Philippe 3 years ago! Video needs its own group! |
| 04:11 | <nessy> | MikeSmith: too many interconnected issues |
| 04:11 | <MikeSmith> | nessy: yeah |
| 04:11 | <jwm> | I think the container is what matters for streaming |
| 04:12 | <jwm> | matroska for example allows true streaming |
| 04:12 | <jwm> | aka webm :) |
| 04:12 | <othermaciej> | I wonder why this spec is all MPEG-2 rather than MPEG-4 |
| 04:12 | <nessy> | "true streaming" … with bitrate adaptation? |
| 04:13 | <nessy> | othermaciej: yeah - Adobe and Microsoft did it for MPEG-4 |
| 04:14 | <nessy> | doublec: I can do that for Ogg - and I can do that for WebM - but to get it happening across container formats needs some kind of unifying environment |
| 04:15 | <nessy> | it's come up in the media fragments WG incidentally |
| 04:15 | <roc> | why does it need to happen across container formats? |
| 04:16 | <MikeSmith> | what IETF mailing list (if any) does discussion about draft-pantos-http-live-streaming take place on? |
| 04:17 | <nessy> | well, maybe I am too idealistic - but I would like to put a single description file on my server that every browser can interpret and do the same switch to retrieving another byte range independent of whether the container on the server is Ogg, WebM or MPEG-4, or MPEG-2 or whatever |
| 04:17 | <othermaciej> | MikeSmith: I can find out - Dave Singer would know |
| 04:18 | <nessy> | I think it's MMUSIC |
| 04:18 | <nessy> | see http://www.ietf.org/mail-archive/web/mmusic/current/msg07784.html |
| 04:19 | <MikeSmith> | that seems like an odd place |
| 04:19 | <MikeSmith> | othermaciej: thanks |
| 04:19 | <othermaciej> | although, Dave Singer and I will both be on vacation for a while |
| 04:19 | <MikeSmith> | oh |
| 04:19 | <jwm> | vacation.. must be nice |
| 04:19 | <roc> | nessy: I don't think there's a huge benefit to using the same scheme for all formats |
| 04:20 | <MikeSmith> | othermaciej: I knew you would be, didn't know that Dave was as well |
| 04:20 | <othermaciej> | he's on vacation all this week, back next week I think |
| 04:20 | <MikeSmith> | othermaciej: please tell me Eric Carlson won't be on vacation at the same time :) |
| 04:20 | <MikeSmith> | ah, I see mmusic is not about music per se, but "Multiparty Multimedia Session Control" |
| 04:21 | <MikeSmith> | http://datatracker.ietf.org/wg/mmusic/charter/ |
| 04:22 | <othermaciej> | MikeSmith: he's still around |
| 04:22 | <othermaciej> | you can probably contact him about most things in my absence |
| 04:23 | <MikeSmith> | ok |
| 04:25 | <jwm> | where is hixie at lately |
| 04:32 | <MikeSmith> | http://www.ietf.org/mail-archive/web/hybi/current/msg02095.html is sweet |
| 04:33 | <MikeSmith> | [[ |
| 04:33 | <MikeSmith> | I didn't bother going through the whatwg IRC archives at |
| 04:33 | <MikeSmith> | http://krijnhoetmer.nl/irc-logs/whatwg/ - sample content: |
| 04:33 | <MikeSmith> | [20:59] * gsnedders wonders what self-raising flour is in Swedish, and what grease-proof paper is |
| 04:33 | <MikeSmith> | ]] |
| 04:33 | <figaroo> | Quick questions! |
| 04:33 | <MikeSmith> | I'm sure he picked that at random |
| 04:33 | <MikeSmith> | gsnedders: you're famous now |
| 04:33 | <figaroo> | Should the doctype be uppercase in HTML5: <!DOCTYPE html>? |
| 04:34 | <MikeSmith> | figaroo: doesn't need to be |
| 04:34 | <figaroo> | Is it good practice to? |
| 04:34 | <MikeSmith> | it's parsed case insensitively |
| 04:34 | <figaroo> | so it doesn't matter at all |
| 04:34 | <MikeSmith> | it's not bad practice either way |
| 04:34 | <figaroo> | k |
| 04:34 | <MikeSmith> | right, doesn't matter |
| 04:34 | <figaroo> | thanks |
| 04:35 | <MikeSmith> | btw, figaroo: do you know what "self-raising flour" is in Swedish, and what "grease-proof paper" is |
| 04:35 | <MikeSmith> | I think there might be some people in the IETF hybi WG who are curious to know that answer for that now |
| 04:35 | <figaroo> | No, but that's a random question. |
| 04:35 | <MikeSmith> | np |
| 04:36 | <figaroo> | Why do you ask? |
| 04:36 | <MikeSmith> | I was reading http://www.ietf.org/mail-archive/web/hybi/current/msg02095.html |
| 04:36 | <MikeSmith> | and just figured that message was going to make some people curious |
| 04:36 | <MikeSmith> | so I wanted to be prepared to enlighten them |
| 04:36 | <figaroo> | lqtm ok |
| 04:37 | <MikeSmith> | "We're also missing the points of view of members of rec.pets.cats" |
| 04:38 | <MikeSmith> | dude's a genuine comedian |
| 04:48 | <figaroo> | Wow, this is weird |
| 04:49 | <figaroo> | Idk if you guys talk about this, but for some reason in my javascript script has a variable called 'bar' which equals the HTML element <div id='bar'> without me setting it to equal it. |
| 04:49 | <figaroo> | Anyone know why that could be? |
| 04:50 | <figaroo> | What's going on here... |
| 04:51 | <figaroo> | Is this a scripting IRC too, or do we only talk about standards and specs? |
| 04:53 | <jwm> | foo bar |
| 04:53 | <figaroo> | yea |
| 04:54 | <figaroo> | I lack the creativity to name my test divs. :P |
| 04:54 | <figaroo> | in creativity* |
| 04:54 | <figaroo> | But this is weird |
| 04:54 | <jwm> | doing web design? |
| 04:54 | <miketaylr> | figaroo: in IE? |
| 04:54 | <figaroo> | Yes |
| 04:54 | <figaroo> | No it's in Chrome |
| 04:54 | <miketaylr> | :o |
| 04:54 | <figaroo> | It's the weirdest thing |
| 04:54 | <miketaylr> | that's a pretty well known "feature" in IE |
| 04:55 | <roc> | I think Webkit emulates that IE quirk |
| 04:55 | <figaroo> | I got rid of all my javascript in my document, just kept the html, and then went into my console and type foo |
| 04:55 | <roc> | Gecko doesn't |
| 04:55 | <roc> | except in quirks mode maybe? |
| 04:55 | <figaroo> | and foo = document.getElementById('foo'); |
| 04:55 | <figaroo> | Maybe I'm in quirks mode |
| 04:56 | <figaroo> | but I thought I set an HTML5 doctype |
| 04:56 | <figaroo> | lemme check |
| 04:56 | <jwm> | http://www.karlstanley.net/blog/?p=5 |
| 04:56 | <roc> | yeah, we emulate it in quirks mode but not standards mode |
| 04:56 | <figaroo> | maybe this is an invalid html5 doctype <!DOCTYPE html> |
| 04:56 | <miketaylr> | interesting |
| 04:57 | <roc> | quite possibly Webkit emulates it in all modes |
| 04:57 | <figaroo> | Is <!DOCTYPE html> not a valid doctype for chrome 5.x? |
| 04:58 | <boblet> | MikeSmith: re: progress element, it’s in the pipeline. thanks for the info |
| 04:59 | <figaroo> | roc, must be the case because my document does have an HTML5 doctype |
| 05:01 | <figaroo> | I even added an HTML 4 transitional doctype and it still has this behavior |
| 05:03 | <figaroo> | yea it emulates it. |
| 05:03 | <figaroo> | only if you have an id that is "awesome-video-player" there is no variable, I suppose. |
| 05:04 | <figaroo> | I was wondering though, why is HTML5's doctype <!doctype html> and not <!doctype html5>, it seems it would make more sense when HTML6 comes out. |
| 05:05 | <MikeSmith> | figaroo: because it's not a version indicator |
| 05:05 | <MikeSmith> | its sole purpose is to prevent document fro |
| 05:05 | <MikeSmith> | *documents from being parsed in quirks mode |
| 05:05 | <figaroo> | oh |
| 05:06 | <figaroo> | Why do we even have quirks mode? |
| 05:06 | <figaroo> | Oh wait. |
| 05:06 | <MikeSmith> | because some geniuses in the past thought it was a really keen idea |
| 05:06 | <MikeSmith> | and now we are stuck with it for eternity |
| 05:06 | <figaroo> | So |
| 05:07 | <MikeSmith> | and not sure what you mean about <!doctype html> being valid in chrome, but if you mean Chrome parses your doc in quirks mode even though it has that doctype, then, it should not be doing that |
| 05:08 | <figaroo> | how do I know if it's parsing in quirksmode or not? |
| 05:09 | <MikeSmith> | check the error console |
| 05:09 | <MikeSmith> | maybe |
| 05:09 | <MikeSmith> | I dunno |
| 05:09 | <figaroo> | I even tried a HTML4 transitional doctype |
| 05:09 | <figaroo> | and foo still equaled document.getElementById('foo'); |
| 05:10 | <figaroo> | If newer browsers used standards mode regardless of whether or not there is a doctype, then it what would happen? |
| 05:10 | <MikeSmith> | if there's not doctype, it gets parsed in quirks mode |
| 05:11 | <MikeSmith> | *no doctype |
| 05:11 | <MikeSmith> | browsers don't use standards mode for doctype-less documents |
| 05:11 | <MikeSmith> | boblet: ah, cool |
| 05:11 | <figaroo> | Yes but why are browser venders continueing this paradigm? |
| 05:12 | <MikeSmith> | for bugwards compatibility with the Web |
| 05:12 | <MikeSmith> | existing content |
| 05:12 | <figaroo> | bugwards, lol |
| 05:12 | <figaroo> | hmm |
| 05:12 | <aho> | document.compatMode === "CSS1Compat" -> standards mode |
| 05:12 | <figaroo> | How many pages out there don't have a doctype? |
| 05:12 | <aho> | "BackCompat" -> quirks mode |
| 05:13 | <jwm> | figaroo: a lot |
| 05:13 | <jwm> | every site I've created |
| 05:13 | <jwm> | j/k |
| 05:13 | <figaroo> | well |
| 05:13 | <karlcow> | jwm, that compensates for all sites I created ;) |
| 05:13 | <figaroo> | What about older browsers that don't support the HTML5 doctype, will they render in quirksmode? |
| 05:14 | <aho> | it's "<!DOCTYPE html>" by the way |
| 05:14 | <figaroo> | aho, yes I'm aware. |
| 05:14 | <jwm> | don't need capitalization |
| 05:14 | <jwm> | :) |
| 05:15 | <aho> | older browser think "ah there is a doctype... and it's one i don't know... must be something new" :> |
| 05:15 | <aho> | so... yea, it's basically a cheat |
| 05:15 | <aho> | but it works |
| 05:15 | <aho> | i.e. they go into standards mode |
| 05:15 | <figaroo> | whew the web has some deep rooted issues... |
| 05:16 | <figaroo> | So how do we (the web community) plan on moving forward? How will we introduce new features to HTML, CSS, and JavaScript while keeping keeping things backwards compatible? |
| 05:17 | <aho> | looking at the specs... it doesn't seem to be case insensitive |
| 05:19 | <aho> | http://dev.w3.org/html5/spec/syntax.html#the-doctype <- kay... this one states it's case insensitve :> |
| 05:20 | <aho> | i'll continue to use uppercase tho... got autocomplete for that :> |
| 05:20 | <jwm> | it'll be nice if future browsers just follow standards only |
| 05:20 | <jwm> | :) |
| 05:20 | <jwm> | free up some memory |
| 05:20 | <jwm> | mobile web browsers shouldn't have to be backwards compatible |
| 05:21 | <jwm> | if following the mobile specs |
| 05:22 | <figaroo> | What are the major differences between quirksmode and standards mode? |
| 05:23 | <roc> | https://developer.mozilla.org/en/Mozilla_Quirks_Mode_Behavior |
| 05:30 | <figaroo> | What happens when we want to change HTML syntax, down the road? |
| 05:31 | <figaroo> | Will we need a new doctype or just a version attribute in the head element? |
| 05:32 | <aboodman> | MikeSmith: hallo |
| 05:32 | <aboodman> | oh, sory |
| 05:37 | <aboodman> | MikeSmith: two main differences off the top of my head. 1) Widgets are a package of HTML and related resources, while what I'm proposing is a wrapper around a URL (no resources are included). 2) Widgets are dramatically larger than what I'm proposing (more akin to Chrome or Firefox extensions). |
| 05:39 | <aho> | <figaroo> What are the major differences between quirksmode and standards mode? <- quirksmode is pretty random, standards mode is somewhat predictable |
| 05:39 | <aho> | simply put: no one wants quirks mode |
| 05:44 | <MikeSmith> | aboodman: I see |
| 05:44 | <MikeSmith> | thanks |
| 05:45 | MikeSmith | re-reads aboodman e-mail message |
| 05:51 | <MikeSmith> | aboodman: as Dion alludes to his reply, I think the permissions mechanism and the UI around that would be a challenge to get agreement about |
| 05:55 | <aboodman> | MikeSmith: that isn't what I got from Dion's reply. |
| 05:55 | aboodman | goes to re-read Dion's reply. |
| 05:57 | <MikeSmith> | aboodman: the 2nd to last paragraph |
| 05:57 | <MikeSmith> | maybe I'm reading too much into that |
| 05:57 | <aboodman> | i think at least having a common framework to work within could be a good start. |
| 05:58 | <MikeSmith> | yeah |
| 05:58 | <aboodman> | if there is only overlap on 50% of the features, taht still gives a good base to converge from. |
| 05:58 | <aboodman> | heck even if there is _no_ overlap on features, if the base format is the same, that is good. |
| 05:58 | <aboodman> | that is the situation with browser-specific css enhancements today :) |
| 06:07 | <MikeSmith> | true, I suppose |
| 07:07 | <figaroo> | Do I need to use CDATA in my script tags? |
| 07:12 | <hsivonen> | MikeSmith: about MathML 3: Are two of Gecko, WebKit, Presto and Trident treating the presentational part of MathML 3 as something they'd tracked for implementation? |
| 07:12 | <hsivonen> | s/tracked/track/ |
| 07:12 | <MikeSmith> | hsivonen: no idea, but I can ask and find out |
| 07:13 | <hsivonen> | MikeSmith: ok |
| 07:13 | <hsivonen> | MikeSmith: were you wondering if patent evergreening applies to software? |
| 07:13 | <MikeSmith> | yeah |
| 07:13 | <hsivonen> | MikeSmith: reading the Nero v. MPEG-LA court filing suggests that it applies |
| 07:14 | <MikeSmith> | hsivonen: yeah, if what Nero alleges in there is accurate |
| 07:15 | <MikeSmith> | especially the bit about the claim to the Dept of Justice that they'd have at most 50-some essential patents |
| 07:15 | <MikeSmith> | when the actually ended up adding 800 or whatever |
| 07:15 | <MikeSmith> | for mpeg-2 |
| 07:15 | <MikeSmith> | and then 1000 or more for H.264 |
| 07:16 | <MikeSmith> | iirc |
| 07:17 | <MikeSmith> | hsivonen: btw, I am in the process of finishing your review changes for the xml-stylesheet PI checker |
| 07:18 | <MikeSmith> | and I'm trying to figure out what'd be the best way to deal with the issue you pointed out about the enum I'm using to handling switching on the pseudo-attribute names |
| 07:19 | <MikeSmith> | you remember I have this: |
| 07:19 | <MikeSmith> | private enum PseudoAttrName { |
| 07:19 | <MikeSmith> | HREF, TYPE, TITLE, MEDIA, CHARSET, ALTERNATE, INVALID; |
| 07:19 | <MikeSmith> | private static PseudoAttrName toCaps(String str) { |
| 07:19 | <MikeSmith> | try { |
| 07:19 | <MikeSmith> | if (!str.toLowerCase().equals(str)) { |
| 07:19 | <MikeSmith> | return INVALID; |
| 07:19 | <MikeSmith> | } |
| 07:19 | <MikeSmith> | return valueOf(str.toUpperCase()); |
| 07:19 | <MikeSmith> | } catch (Exception ex) { |
| 07:19 | <MikeSmith> | return INVALID; |
| 07:19 | <MikeSmith> | } |
| 07:19 | <MikeSmith> | } |
| 07:19 | <MikeSmith> | } |
| 07:19 | <MikeSmith> | hmm, sorry for long paste |
| 07:19 | <MikeSmith> | that looked shorter in vim |
| 07:21 | <MikeSmith> | anyway, you'll also remember I'm doing that so that I can switch on the uppercase version of the pseudo-attribute name |
| 07:21 | <MikeSmith> | switch (PseudoAttrName.toCaps(attrName)) { |
| 07:21 | <MikeSmith> | case HREF: |
| 07:21 | <MikeSmith> | etc. |
| 07:21 | <MikeSmith> | I realize that's a bit idiosyncratic |
| 07:21 | <MikeSmith> | or maybe just dumb |
| 07:22 | <MikeSmith> | so if you have a better suggestion on how to handle the switch, I'm happy to change it |
| 07:22 | <MikeSmith> | or I can just change the whole thing to use if/else-if instead |
| 07:23 | <hsivonen> | I suggests rolling your own toAsciiUpperCase |
| 07:24 | <MikeSmith> | ok |
| 07:24 | <hsivonen> | or finding one I most likely have already written elsewhere in the codebase |
| 07:25 | <MikeSmith> | yeah, I remember some places where you have lowercasing ones |
| 07:25 | <MikeSmith> | so I'll just borrow from that |
| 07:25 | <othermaciej> | hsivonen: does Gecko implement the presentational part of MathML, the other part (whatever it's called) or both? |
| 07:46 | MikeSmith | is once again finding that he wishes svn provided a way to choose only some parts of file changes in a workspace to commit |
| 07:55 | <nessy1> | MikeSmith: move to bzr or git or something more modern ;) |
| 07:56 | <MikeSmith> | nessy: I'm not the owner for the repository |
| 07:56 | <nessy> | shame! encourage them to move ;) |
| 07:56 | <MikeSmith> | and even if I were, easier said than done :) |
| 07:56 | <MikeSmith> | yeah |
| 07:57 | <nessy> | I've been trying to do that with W3C ppl for the last year - at least moving from cvs to svn would be nice … but I haven't had much luck :( |
| 07:57 | <MikeSmith> | nessy: W3C has an mercurial repo now |
| 07:57 | <nessy> | oh my |
| 07:58 | <MikeSmith> | systems team can set up you up with space there if you want |
| 07:58 | <nessy> | does it support everything? |
| 07:59 | <nessy> | I'm an editor on Media Fragments, so that's my experience with VCS of W3C |
| 07:59 | <MikeSmith> | hsivonen: btw, is it OK with you if I remove the static copies of validator/src/nu/validator/servlet/PageEmitter.java and validator/src/nu/validator/servlet/FormEmitter.java from the repository? |
| 07:59 | <MikeSmith> | hsivonen: because they are now regenerated/replaced by the build |
| 07:59 | <nessy> | incidentally - I'm not mercurial-fluent, so might pass on that :( |
| 07:59 | <MikeSmith> | nessy: it supports all whatever a default install of mercurial supports, I think |
| 08:00 | <nessy> | I meant all W3C specs |
| 08:00 | <nessy> | but it's ok - I think I'll pass - too much pain involved in learning another VCS |
| 08:01 | <MikeSmith> | OK |
| 08:01 | <MikeSmith> | anyway, spec sources for HTML WG and WebApps WG are all still in cvs on dev.w3.org |
| 08:01 | <MikeSmith> | but we can move them eventually |
| 08:01 | <MikeSmith> | I think the HTML WG testing TF is using the mercurial repo already |
| 08:28 | <hsivonen> | othermaciej: Gecko implements the presentational part only |
| 08:28 | <hsivonen> | MikeSmith: does the build put the generated emitters in the old .java location? |
| 08:28 | <othermaciej> | I don't believe there are plans to implement the non-presentational parts in WebKit |
| 08:29 | <hsivonen> | othermaciej: which MathML spec are you tracking for the parts that you are implementing? |
| 08:31 | <othermaciej> | hsivonen: dunno - the person working on it is a part time volunteer |
| 08:31 | <MikeSmith> | hsivonen: yep, it puts the generated emitters in exactly the same location as the .java files |
| 08:32 | <MikeSmith> | https://trac.webkit.org/wiki/MathML%20Goals |
| 08:32 | <foolip> | nessy: around? |
| 08:47 | <hsivonen> | MikeSmith: then I'm OK with removing the generated files from version control |
| 08:48 | <MikeSmith> | hsivonen: ok, thanks |
| 08:48 | <hsivonen> | MikeSmith: so far, I don't have enough data to have an informed opinion about changing the validation target from MathML 2 to 3 |
| 08:48 | <MikeSmith> | understood |
| 08:49 | <hsivonen> | but SVG 1.2 being what it is, following the spec with the highest number isn't a given |
| 08:49 | <MikeSmith> | I'll do some more asking |
| 08:49 | <MikeSmith> | roger that too |
| 08:49 | <othermaciej> | I don't know what the differences between 2 and 3 are |
| 08:51 | <MikeSmith> | hsivonen: as I mentioned my concern about MathML is just that based on what I've seen of that existing (third-party) MathML 2.0 schema, it's highly likely to have significant bugs that are waiting to be discovered |
| 08:52 | <MikeSmith> | hsivonen: e.g., the one I fixed in it last week was because he had a regular expression in it for checking number values for width and height, etc., values -- and the way he had it, it only accepted integer values |
| 08:53 | <MikeSmith> | so it leads me to wonder how closely dude actually has read the MathML 2.0 spec |
| 08:53 | <MikeSmith> | and I suspect the answer is, not too closely |
| 08:54 | <MikeSmith> | I wonder if I could convince the MathML WG to produce an RNC schema for MathML 2.0 |
| 09:02 | <zcorpan_> | i bet there is more technical feedback on websockets in whatwg than on hybi |
| 09:02 | <boblet> | anyone worked out how to fire CSS3 transitions on :hover but not :active? |
| 09:03 | othermaciej | wonders what the discussion on whatwg⊙wo is supposed to be that isn't technical discussion |
| 09:06 | <boblet> | othermaciej: the HTML5 video for porn thread yesterday was still technical… right? |
| 09:08 | <annevk> | boblet, set -o-transition:0 on :active ? |
| 09:09 | <annevk> | (it's a guess) |
| 09:10 | <MikeSmith> | zcorpan_: fwiw, I finally committed the xml-stylesheet PI-checking code to the v.nu repo today |
| 09:10 | <zcorpan_> | MikeSmith: yay |
| 09:13 | <boblet> | annevk: that’s what I thought. hmm, browser support is patchy. Opera 10.5 appears good tho |
| 09:13 | <boblet> | ta |
| 09:15 | <zcorpan_> | MikeSmith: here's a real-world test case http://home.arcor.de/martin.honnen/operaBugs/op9/XML/ampersandInPI2.xml |
| 09:16 | <zcorpan_> | MikeSmith: but the validator just complains about the root element's namespace and refuses to validate :( |
| 09:17 | annevk | goes to verify his guess |
| 09:17 | <zcorpan_> | MikeSmith: oh the checking isn't live yet on v.nu |
| 09:19 | <annevk> | boblet, it's undefined though I think if Opera does what you say it does it should be defined as such as nothing else is really logical |
| 09:19 | <annevk> | boblet, see http://www.w3.org/TR/css3-transitions/#starting |
| 09:20 | <boblet> | I looked there for stopping actually :) |
| 09:20 | <MikeSmith> | zcorpan_: yeah, it won't be live until the next time hsivonen deploys |
| 09:20 | <boblet> | annevk: making a matrix atm |
| 09:23 | <MikeSmith> | hsivonen: I also need to fix an enum I added to the MediaQuery.java datatype code |
| 09:23 | <MikeSmith> | to do proper ascii uppercasing |
| 09:24 | <MikeSmith> | but I note the you have a somewhat different method for doing the lowercasing there |
| 09:24 | <MikeSmith> | in https://whattf.svn.cvsdude.com/syntax/trunk/relaxng/datatype/java/src/org/whattf/datatype/AbstractDatatype.java |
| 09:24 | <MikeSmith> | toAsciiLowerCase using a CASE_MASK bitmap |
| 09:25 | <hsivonen> | MikeSmith: the CASE_MASK thing is just complexity compared to plus/minus |
| 09:26 | <MikeSmith> | ok |
| 09:26 | <MikeSmith> | so OK if I simplify it? |
| 09:26 | <MikeSmith> | that is, use the same method you're using in the htmlparser code? |
| 09:27 | <MikeSmith> | newAsciiLowerCaseStringFromString |
| 09:28 | <boblet> | annevk: doesn’t work with -o-transition:0 on :active (transitions on mouseover/out, but also mouseup), but does with -o-transition-property: none (only on mouseover/out as desired) |
| 09:29 | <boblet> | annevk: webkit has the ‘also mouseup’ behaviour on both -webkit-transition:0 and -webkit-transition-property:none, so it’s all transitions or no transitions it seems |
| 09:31 | <hsivonen> | MikeSmith: yes, it's OK to simplify it |
| 09:32 | <MikeSmith> | htanks |
| 09:32 | <MikeSmith> | boblet: http://usa10.webdirections.org/program looks borked |
| 09:33 | <boblet> | woah, you’re not wrong |
| 09:34 | <boblet> | wonder who’s in charge of that. will let ppls know, thanks |
| 09:35 | <zcorpan_> | hmm, chrome's view source of http://home.arcor.de/martin.honnen/operaBugs/op9/XML/ampersandInPI2.xml is lying |
| 09:36 | <MikeSmith> | zcorpan_: hmm, yeah |
| 09:37 | <MikeSmith> | Safari shows it correctly, afaict |
| 09:37 | <zcorpan_> | chrome also screws up if the last thing in source is </script> |
| 09:49 | <jgraham> | nessy: If you can deal with Git, MErcurial is a walk in the park |
| 09:55 | <boblet> | the spec used to mention footnotes as a use for aside element, and doesn’t anymore. any reason why? still kosher? |
| 09:55 | <boblet> | (if anyone knows :) |
| 09:57 | <boblet> | aah np, I found 4.13.3 |
| 10:00 | <Yudai> | hsivonen: i added a patch for the bug 721, please check it out |
| 10:00 | <Yudai> | Mike seems offline now |
| 10:05 | <hsivonen> | Yudai: The patch looks OK if it's a good idea not to report data: URLs with fragments as errors |
| 10:06 | <hsivonen> | Yudai: however, considering that data: URLs with fragments don't actually work in browsers, I think it's useful to report them as errors |
| 10:07 | <hsivonen> | if that position can't be backed by specs, at minimum the validator should emit a warning telling authors not to use fragments in data: URLs. |
| 10:07 | <Yudai> | hsivonen: I'm not sure whether the browsers' behavior is "by design" or just a bug |
| 10:07 | <Yudai> | hsivonen: if it is by design, it is useful to report as errors, i think |
| 10:07 | <jgraham> | Where does the spec define what type the events have e.g. how do you work out what to pass as typeArg to initHashChangeEvent? |
| 10:08 | <hsivonen> | Yudai: I suspect in Gecko's case it was a bug |
| 10:08 | <hsivonen> | bugs have a tendency to be promoted to design on the Web, though |
| 10:09 | <zcorpan_> | best way to reduce the number of bugs |
| 10:09 | <hsivonen> | I wish we had a well-functioning spec group for URLs for determining what's a bug and what's a feature here |
| 10:10 | <zcorpan_> | i've found myself wanting a URL spec surprisingly often in the past few months |
| 10:10 | <Yudai> | hsivonen: some people believe that the validator is always right and same as the specs. so if we report it as error, we should change the message |
| 10:11 | <hsivonen> | Yudai: ideally, the validator matches the spec and the spec makes sense in light of the browser implementations |
| 10:11 | hsivonen | looks up the data: URL spec |
| 10:11 | <roc> | I thought that fragments were an HTTP-specific thing |
| 10:14 | <hsivonen> | roc: the fragment isn't resolved by the HTTP stack, so it doesn't really make sense for it to be HTTP-specific |
| 10:14 | <hsivonen> | Yudai: it seems to me the data: RFC disagrees with the RFC you are citing |
| 10:14 | <hsivonen> | Yudai: possibly a bug in the data: RFC |
| 10:15 | <hsivonen> | Yudai: anyway, I think the validator should match the spec |
| 10:15 | <hsivonen> | Yudai: and if the spec is bad, the spec should be changed |
| 10:15 | <hsivonen> | Yudai: here, it seems that there are contradictory specs |
| 10:15 | <Yudai> | hsivonen: i agree with you |
| 10:16 | <hsivonen> | Yudai: so I'd be inclined to using the spec that comes with results that are closer to the real world |
| 10:16 | <hsivonen> | Yudai: which currently is the data: RFC not speccing fragment ids for data: at all |
| 10:16 | <hsivonen> | (which does seem like a bad oversight) |
| 10:18 | <hsivonen> | Yudai: I'd be OK with taking the patch if it emitted an error whining something more specific about fragments in data: |
| 10:18 | <hsivonen> | Yudai: I could also be persuaded into turning it into a warning instead of an error |
| 10:19 | <hsivonen> | Yudai: but I'd rather keep it an error until the spec closer to the subject matter (data: spec) and the browsers are changed |
| 10:20 | <hsivonen> | the applicability of generic URI syntax as defined by the IETF to all URLs is a fiction anyway |
| 10:20 | <hsivonen> | consider javascript: |
| 10:20 | <Yudai> | hsivonen: yes |
| 10:21 | <Yudai> | hsivonen: it makes sense |
| 10:21 | <zcorpan_> | javascript: is the exception confirming the rule ;) |
| 10:21 | <Yudai> | personally, i'd like to use #frag with data: url, so i prefer warning :) |
| 10:22 | zcorpan_ | thinks it's good to be able to use fragments with data: urls |
| 10:22 | <hsivonen> | Yudai: would you like to use #frag before it actually works in URL consumers? |
| 10:23 | <hsivonen> | (I'd like to be able to use #frag in data: URLs, too, in the sense of having Gecko, WebKit, etc. changed to allow it) |
| 10:23 | <zcorpan_> | hsivonen: are there bugs about changing checko and webkit? |
| 10:23 | <zcorpan_> | s/c/g/ |
| 10:23 | <zcorpan_> | s/h// |
| 10:24 | <Yudai> | hsivonen: the validator can not only follow the other consumers but also run at the head of them, i think |
| 10:24 | <zcorpan_> | typo++ |
| 10:24 | <roc> | I would love to have that feature |
| 10:25 | <roc> | really useful for stuff like filter: url(data:...#filter); |
| 10:25 | <Yudai> | and i believe validators should be stricter than the others |
| 10:25 | <hsivonen> | Yudai: how much to let the validator be "ahead" is a tough call |
| 10:26 | <hsivonen> | Yudai: especially with wrong directions of where "ahead" is--like SVG 1.2 |
| 10:26 | <hsivonen> | zcorpan_: I don't know about bug reports |
| 10:27 | <Yudai> | hsivonen: hmm, it's a difficult problem |
| 10:28 | <Yudai> | ok, keep it as errors and show another message for users |
| 10:29 | <Yudai> | which is like "RFC2397 and RFC3986 are conflicted in this point" |
| 10:30 | <Yudai> | my wish is to let the users know a right knowledge |
| 10:31 | <Yudai> | if we don't give users information, they might believe it is a simple error |
| 10:41 | <asmodai> | I'm sure you guys saw http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/ ? |
| 10:45 | <Yudai> | hsivonen: i added a new patch |
| 10:50 | <zcorpan_> | http://krijnhoetmer.nl/irc-logs/whatwg/20100525#l-499 - it's specced in html5 |
| 10:56 | <zcorpan_> | here http://www.whatwg.org/specs/web-apps/current-work/complete/browsers.html#named-access-on-the-window-object |
| 11:11 | <asmodai> | hsivonen: nice work on the MathML stuff |
| 11:16 | <hsivonen> | asmodai: MikeSmith's work, probably |
| 11:37 | <hsivonen> | Yudai: thanks. I sent you email about the patch. |
| 11:44 | <asmodai> | hsivonen: Still nice ^^ |
| 12:44 | <boblet> | anyone want to talk about figure and the “is typically referenced as a single unit” mention in the spec? |
| 12:45 | <boblet> | I’m wondering if the presentational (something-with-caption) will trump the “that could, without affecting the flow of the document, be moved away from that primary content” part of the spec |
| 12:47 | <boblet> | thinking about it I’ve used figure for it’s caption even when the content contained would have made the main article hard to understand if it was moved to a different page — the surrounding text wouldn’t provide enough information to cover the figure content not being there |
| 12:48 | <daedb> | boblet: I always thought of the "could be moved away" part of <figure> as an optional nicety that works some figures, but not all figures. |
| 12:49 | <boblet> | daedb: I’m starting to think that the “could be moved away” part is the nub, and the “typically referenced” part is the optional nicety. certainly seems like it’s more literary than captioning |
| 12:50 | <boblet> | aaw mike, you just missed my deep semantic philosophical question |
| 12:50 | <jgraham> | boblet: I think you are over thinking it |
| 12:50 | <MikeSmith> | boblet: darn |
| 12:50 | <jgraham> | <figure> is for things that are referenced as figures |
| 12:50 | MikeSmith | checks the logs |
| 12:51 | <boblet> | jgraham: is it possible to *over*-think semantics!? |
| 12:51 | <boblet> | MikeSmith: hehe |
| 12:51 | <jgraham> | boblet: Sure |
| 12:51 | boblet | should have added a :| to that comment huh |
| 12:51 | <jgraham> | When the maount of thought you put in is disproportionately high compared to the value |
| 12:51 | <jgraham> | *amount |
| 12:52 | <jgraham> | The bar for that is actually quite low becase semantics are only useful if someone else understands them |
| 12:52 | <boblet> | jgraham: when you say “referenced as figures”, you mean there should be a link in the text saying “ bla bla (see Fig 2.7) bla”, right? |
| 12:52 | <MikeSmith> | I think jgraham is right |
| 12:52 | <MikeSmith> | about over thinking it |
| 12:52 | <jgraham> | boblet: Yeah. But that's not really a necessary condition |
| 12:53 | <MikeSmith> | I think in some cases, you may be putting more thought into the wording than Hixie did when he wrote it |
| 12:53 | <asmodai> | MikeSmith: I hear you are to be blamed for the mathml stuff for the validator according to hsivonen. Thanks ^^ |
| 12:53 | <MikeSmith> | kind of like, Blessed are the cheesemakers |
| 12:53 | <boblet> | heh |
| 12:53 | <daedb> | It's going to be commonly used without proper figure references anyway, so saying it should only be used that way is pointless. |
| 12:53 | <MikeSmith> | asmodai: not sure what you mean |
| 12:54 | <jgraham> | Anyway, to copntinue my previous point, for the general web case the value of the semantics is typically "will this be processed in a useful way by a general-purpose UA" |
| 12:54 | daedb | checks what the spec actually says... |
| 12:54 | <MikeSmith> | asmodai: if you mean the mathml integration into text/html validation, that is completely the work of hsivonen himself |
| 12:54 | <boblet> | the article that’s making me wonder is the one I wrote on ruby: http://html5doctor.com/ruby-rt-rp-element/#without-rp |
| 12:54 | asmodai | wonders why hsivonen mentioned you then |
| 12:54 | <jgraham> | Although there is also some value in "am I making it easy for people to write specialised screen scrapers" |
| 12:55 | <MikeSmith> | asmodai: maybe because I had earlier today been talking here about a couple bugs in the MathML schema that I fixed recently |
| 12:55 | <jgraham> | but that's not semantics as much as consistency, and exposing the right parts in elements |
| 12:56 | <MikeSmith> | asmodai: but those were relatively minor changes |
| 12:56 | <asmodai> | Oh ok |
| 12:56 | <boblet> | all of the groups of images followed by some italic text are figures, so I used figure a lot |
| 12:56 | <MikeSmith> | boblet: I think element semantics are a massive gray area, and much of the decisions come down to judgment calls |
| 12:57 | <jgraham> | (so <dt>title: <dd>Foo is mildlybetter than just <span>title: foo</span> because it is easier to find the markup corresponding to the title and the value of the title |
| 12:57 | <jgraham> | ) |
| 12:57 | <boblet> | the article wouldn’t be so informative with the figure elements moved to a different page, fror example |
| 12:58 | boblet | wonders if he’s the only one that really enjoys a good natter about semantics |
| 12:59 | <boblet> | so using figure as a way to just add a caption to an image (even if it’s not referenced in the main text) is still cool huh |
| 12:59 | <boblet> | thanks for the input all |
| 13:00 | <MikeSmith> | boblet: I think a lot of people do care about clear guidance around semantics |
| 13:00 | <MikeSmith> | which is why you should keep writing Doctor stuff about for |
| 13:00 | <MikeSmith> | *about it |
| 13:01 | <MikeSmith> | boblet: btw, I wish the other doctors would come here and hang out on IRC more |
| 13:01 | <boblet> | MikeSmith: I’m having a conversation with someone about that ‘confusing elements of HTML5’ flowchart thing, and he’s saying figure is tangental and must be referenced |
| 13:02 | <boblet> | so I’m just wanting to make sure I’m on the right path |
| 13:02 | <MikeSmith> | boblet: talk to two different people and you are likely to get two different opinions |
| 13:02 | <MikeSmith> | I think much of it is subjective |
| 13:03 | <MikeSmith> | and anybody who claims otherwise is confused themselves |
| 13:03 | <boblet> | MikeSmith: will mention it. I think that between the two (possibly three) books, event organisation, speaking appearances and workshops everyone is doing (not to mention two are expecting), they don’t have much time for the jollities of this channel |
| 13:03 | <boblet> | yeah, thought so |
| 13:03 | <MikeSmith> | bullshit |
| 13:03 | <boblet> | har |
| 13:04 | <boblet> | will have a stern talking to them then ;-) |
| 13:04 | <daedb> | The spec says that figures *could* be moved away, not that it must always be movable. At least that's how I interpret it :) |
| 13:04 | <MikeSmith> | I think plenty of people on this channel are just as busy |
| 13:04 | <boblet> | daedb: yeah me too |
| 13:05 | <boblet> | MikeSmith: well, I’m here |
| 13:05 | <boblet> | >_< |
| 13:05 | <annevk> | "no time" just means "not interested enough right now" |
| 13:05 | <boblet> | doh! |
| 13:05 | <boblet> | ＞＿＜ |
| 13:05 | <MikeSmith> | boblet: yeah, you are leading by example |
| 13:05 | <boblet> | nya nya, doublebyte on yo’ emoticon ass |
| 13:05 | <MikeSmith> | and the jollities of the channel mask the fact that a lot of seriously important discussion takes place here |
| 13:06 | <boblet> | actually @rem has two books on the go himself |
| 13:06 | <jgraham> | annevk: But all we talk about here is the Swedish for baking paper |
| 13:06 | <MikeSmith> | boblet: often it's discussion that would burn up a lot of e-mail time otherwise |
| 13:06 | <jgraham> | I read it on the IETF mailing list so it must be true |
| 13:06 | <boblet> | true true, I’ve been here for a couple of big spec changes |
| 13:07 | <annevk> | I'm not sure what point he was trying to make |
| 13:07 | <jgraham> | (And the fact that I spent a good deal of the day before talking about WebSockets here is obviously irrelevant) |
| 13:07 | <annevk> | but whatever, I'm pretty much done with hybi |
| 13:07 | <jgraham> | The point he made to me is "my email should be ignored" |
| 13:07 | <jgraham> | Dunno if that is what he was aiming for |
| 13:08 | <annevk> | those guys there are full of petty arguments |
| 13:08 | <annevk> | i guess that's what hybi is mostly useful for |
| 13:08 | <annevk> | a wide selection of petty arguments |
| 13:09 | <annevk> | god knows there's never enough of those |
| 13:10 | <annevk> | on another note, I think I'll add addMediumListener / removeMediumListener to CSSOM View now |
| 13:10 | <annevk> | nobody complained about the email for over two weeks; lets see what a draft brings out |
| 13:10 | <hsivonen> | I can see why the IETF guys might be unhappy if a spec they don't want is being nominally developed in an IETF WG |
| 13:11 | <hsivonen> | but if they don't want it there, perhaps they should have allowed it to proceed in the W3C! |
| 13:11 | <annevk> | there's no "they" though |
| 13:11 | <hsivonen> | ok |
| 13:11 | <annevk> | much like there's no "us" |
| 13:12 | <annevk> | the app director convinced the W3C domain lead to do it at the IETF and that was it |
| 13:12 | <annevk> | I don't think much more thinking went into the whole thing |
| 13:13 | <hsivonen> | considering that the W3C has a serious patent policy and the IETF hasn't moving stuff from the W3C to the IETF seems bad |
| 13:14 | <hsivonen> | I guess wanting to have any and all protocols in the IETF is the same issue as wanting to have any and all Web document formats at the W3C |
| 13:14 | <jgraham> | Isn't there some historic agreement that W3C wants to honour in order to avoid ploitical battles? |
| 13:15 | <jgraham> | *political |
| 13:15 | <hsivonen> | yeah |
| 13:16 | <hsivonen> | but it seems the issue still is keeping up the appearance that if you want to make a protocol, the IETF is the place to go |
| 13:16 | <hsivonen> | see http://diveintomark.org/archives/2006/08/23/overton-window |
| 13:16 | <hsivonen> | sliding the window to #5 |
| 13:16 | <hsivonen> | except with IETF instead of the W3C |
| 13:49 | <annevk> | aah crap |
| 13:50 | <hsivonen> | annevk: ? |
| 13:51 | <annevk> | HTML5 has MediaError |
| 13:51 | <annevk> | CSSOM has MediaList |
| 13:52 | <annevk> | I need MediaCallback / MediaChange for CSSOM View |
| 13:52 | <annevk> | it makes sense to call them MediaCallback and MediaChange given MediaList |
| 13:52 | <annevk> | but not given MediaError |
| 13:53 | <annevk> | I suppose I could call them MediaQueryCallback and MediaQueryChange and hope future media query related interfaces stay clear of the prefix Media |
| 13:53 | <annevk> | I think I'll go with that |
| 13:56 | <annevk> | it's pretty clear this stuff was not designed with vision |
| 13:57 | <annevk> | media can mean video/audio, resource type, or rendering type |
| 13:58 | <annevk> | and now it all comes together years downstream and we've to patch it up |
| 14:14 | <akamike> | boblet: you said there would be nurses :( |
| 14:14 | <boblet> | akamike in da house! the challenge has been answered |
| 14:15 | <boblet> | heh, bait n switch yo |
| 14:16 | <boblet> | akamike: oh any thoughts on what it was about aside that Rich wanted improved? |
| 14:17 | <zcorpan_> | annevk: damned English having the same word for different things |
| 14:19 | <akamike> | Yes, though I haven't had a chance to send them around yet |
| 14:19 | <MikeSmith> | is akamike and HTML5 doctor? |
| 14:19 | <boblet> | MikeSmith: indeedy |
| 14:20 | <MikeSmith> | there goes the neighborhood |
| 14:20 | <boblet> | MikeSmith: oh, you better make with the hawt nurses you promised |
| 14:20 | <MikeSmith> | heh |
| 14:20 | <akamike> | :D |
| 14:20 | <MikeSmith> | akamike: glad you are here |
| 14:21 | <MikeSmith> | you have found the right place |
| 14:22 | <akamike> | Happy to be here, I have stopped by a couple of times before but not for very long |
| 16:04 | <zcorpan_> | http://forums.whatwg.org/viewtopic.php?t=4309 - anyone remember why workers resolve urls against the worker script's url instead of the document's url? |
| 16:06 | <annevk> | for the same reason background image URLs in CSS are resolved against the style sheet rarther than the document they are associated with? |
| 16:07 | <zcorpan_> | but workers are scripts |
| 16:07 | <zcorpan_> | scripts in <script> use the document's url |
| 16:07 | <annevk> | can't a worker be shared? |
| 16:07 | <zcorpan_> | ah |
| 16:07 | <zcorpan_> | yes, that's probably why |
| 16:08 | <annevk> | for scripts it makes sense I think, especially when they mutate the DOM... but yeah |
| 16:08 | <annevk> | people should use a trailing slash |
| 16:09 | <zcorpan_> | trailing slash? |
| 16:14 | <annevk> | a leading |
| 16:15 | <zcorpan_> | yeah. works poorly for local testing but then again the whole origin policy also works poorly for local testing |
| 16:18 | <annevk> | local testing is still done? I guess you could configure a server of some kind |
| 16:26 | <MikeSmith> | another fwiw about v.nu changes: I finally also committed code for checking text content of style elements |
| 16:27 | <MikeSmith> | another thing that'd been sitting in my workspace for a long time |
| 16:27 | <MikeSmith> | (pending me getting around to finshing changes from review comments from Henri) |
| 16:28 | <MikeSmith> | all it does is check to make sure any "<!--" in a style text content has a matching "-->" |
| 16:28 | <MikeSmith> | I also have half of a patch for <script> element text-content checking written up |
| 16:29 | <MikeSmith> | maybe I can finish that this week |
| 17:14 | <chris_7> | hi all |
| 17:17 | <jgraham> | hi |
| 17:19 | <chris_7> | Just started with html using emacs nxml (http://github.com/hober/html5-el). Right direction? Or is there a better environment on linux? |
| 17:19 | <chris_7> | html5 not just html |
| 17:24 | <TabAtkins> | Shrug. I just use a text editor for my html authoring. |
| 17:24 | <jgraham> | chris_7: That tool is great if you are creating something that is going to be servedc as application/xhtml+xml it might get you in trouble otherwise |
| 17:24 | <jgraham> | TabAtkins: What is emacs if not a text editor? |
| 17:24 | <jgraham> | Waht, bad question |
| 17:24 | <jgraham> | *Wait |
| 17:24 | <TabAtkins> | jgraham: Exactly. |
| 17:24 | <jgraham> | But still there is nothing wrong with using emacs for HTML editing |
| 17:24 | <TabAtkins> | Perhaps I should say I use *just* a text editor. |
| 17:25 | <chris_7> | jgraham, well it's going to be used in an effort to write for websockets |
| 17:25 | <jgraham> | Actually the problemn is that the default HTML mode is too sucky |
| 17:25 | <jwm> | I use the text editor on the other end of the war lines from emacs |
| 17:25 | <jwm> | :) |
| 17:26 | <jgraham> | Someone should implement a HTML5 parser in elisp and use that to implement syntax highlighting, indenting, etc. |
| 17:26 | <jgraham> | And then get embedded ja and CSS right somehow |
| 17:26 | <chris_7> | that would be exactly what I wanted |
| 17:26 | <jgraham> | *js |
| 17:26 | <TabAtkins> | I use Notepad++, Gedit, or Editpad, depending on the computer. Basically whatever's a normal-ish editor on that system. |
| 17:26 | <jwm> | my palm pre came with vi on it |
| 17:26 | <jwm> | :) |
| 17:27 | <chris_7> | if only I wanted to spend the time to learn elisp |
| 17:27 | <TabAtkins> | chris_7: If you're writing html in lisp, you should be using cl-who or similar anyway. (Though, I don't know if that works in elisp, since it's a cl library...) |
| 17:28 | <chris_7> | TabAtkins, I'll look it up :) |
| 17:28 | <jgraham> | TabAtkins: Who said they were writing HTML in lisp? |
| 17:29 | <TabAtkins> | Sorry, I just assume that anyone using an editor with a lisp built-in and readily accessible wants to use lisp. ^_^ |
| 17:29 | <TabAtkins> | Also, I assume that everyone wants to use lisp. |
| 17:29 | <gsnedders> | jgraham: Any project whose step one is implemening an HTML5 parser... |
| 17:30 | <jgraham> | So your proposal is (html (head (title Foo))) and so on, and then write functions to expand it to HTML? |
| 17:30 | <TabAtkins> | Yus. |
| 17:30 | <TabAtkins> | Though, the cl-who version is (:html (:head (:title Foo))) |
| 17:30 | <chris_7> | Would that be more efficient in the end? |
| 17:30 | <TabAtkins> | Arbitrary lisp expressions can be nested in there to construct your page, unlike plain HTML. |
| 17:31 | jgraham | doesn't know enough lisp to know what : signifies... atom? |
| 17:31 | <TabAtkins> | Self-evaluating symbol. |
| 17:31 | <TabAtkins> | Basically, guaranteed not-eq-to-anything-but-itself. |
| 17:31 | <chris_7> | Well... looks like I need a good lisp tutorial now haha |
| 17:31 | <gsnedders> | Awesome. Queensrÿche is on Spotify now. |
| 17:32 | <TabAtkins> | chris_7: Look up "practical common lisp". Free webbook written by peter seibel, who's a good guy. |
| 17:32 | <jgraham> | gsnedders: I know, taht's why I haven't tried |
| 17:32 | <TabAtkins> | That'll teach you tons of practical lisp. |
| 17:32 | <chris_7> | TabAtkins, Awesome! |
| 17:32 | <jgraham> | gsnedders: Also, it will not be awesome until Joanna Newsom is on spotify |
| 17:32 | <chris_7> | TabAtkins, http://www.gigamonkeys.com/book/ |
| 17:32 | <TabAtkins> | Bwahaha, and I advance the lisp agenda one step further. |
| 17:32 | <TabAtkins> | Yeah, that's it. |
| 17:33 | <chris_7> | lol one user at a time huh? |
| 17:33 | <jwm> | is there lisp for vim? :) |
| 17:33 | <TabAtkins> | We lispers have survived since 1960, we can afford to go slowly. |
| 17:33 | <TabAtkins> | jwm: Probably! |
| 17:33 | <jwm> | I love jquery fluid grid |
| 17:34 | <chris_7> | slow and steady wins the race I guess :P |
| 17:34 | <jgraham> | chris_7: Also, you should know TabAtkins is insane |
| 17:34 | <jwm> | http://www.zaum.co.uk/ - that design is awesome (resize window) |
| 17:34 | <jgraham> | And he has a certiticate to prove it! |
| 17:34 | <jwm> | mcse? |
| 17:34 | <Dashiva> | The advancement of lisp resembles the increase in wealth from a bank account with interest rate below inflation |
| 17:34 | <chris_7> | Ooooh ouch! |
| 17:35 | <chris_7> | Dashiva, Ice burn! haha |
| 17:35 | <TabAtkins> | jwm: Fluid grid doesn't seem to be useful outside of certain specific cases where you really don't care what order things are in. |
| 17:35 | <jwm> | you can order things too |
| 17:36 | <jwm> | I'm just saying it's a nice effect |
| 17:36 | <jwm> | my favorite web designs are full width ones |
| 17:36 | <jwm> | :) |
| 17:36 | <jwm> | I'm trying to come up with a web design I can use for multiple clients right now |
| 17:37 | <TabAtkins> | Yeah, I've done designs that would benefit from fluid grid, where I have a bunch of boxes that I just wanted to pack in tightly, but they're rare. |
| 17:37 | <TabAtkins> | And a balanced multicol does the job equally, just distributed the opposite way. |
| 17:37 | <jwm> | well you'd be approaching the same concept with multicolumn |
| 17:38 | <jwm> | if you allowed more columns or less columns based on width |
| 17:38 | <TabAtkins> | That's what column-width is for. |
| 17:38 | <jwm> | yeah but column width looks ugly imo :) |
| 17:38 | <jwm> | you get huge boxes with wide content |
| 17:38 | <TabAtkins> | ?_? |
| 17:38 | <jwm> | or skinny boxes with narrow content |
| 17:38 | <jwm> | you're saying keep the same number of columns |
| 17:38 | <TabAtkins> | You could replicate the demo exactly by using column-width:240px; |
| 17:39 | <jwm> | but grow the columns |
| 17:39 | <jwm> | ohh ok I see what you are saying |
| 17:39 | <TabAtkins> | No, I mean keep the same column-width, and change the number. ^_^ |
| 17:39 | <TabAtkins> | 'columns' keeps the number steady, 'column-width' keeps the width steady. |
| 17:39 | <jwm> | well you'd be approach the same concept then :) |
| 17:39 | <TabAtkins> | Yup. |
| 17:39 | <jwm> | I like the variable size content though |
| 17:39 | <jwm> | kind of breaks up the lines |
| 17:39 | <jwm> | you can do the same I know |
| 17:39 | <TabAtkins> | That comes for free with multicol. ^_^ |
| 17:40 | <TabAtkins> | And/or flexbox. |
| 17:40 | <jwm> | I like the animations though :) |
| 17:41 | <jwm> | I can't find that many animated html5 site designs out there |
| 17:41 | <jwm> | I found one cool site that links to 100s called cgvietnam.com |
| 17:41 | <jwm> | but other than that.. |
| 17:42 | <chris_7> | TabAtkins, is this lisp book available in print? I need to get a hard copy from my uni's library if they do. |
| 17:45 | <TabAtkins> | Yeah, it is. |
| 17:51 | <chris_7> | Cheap school only keeps the online version and it's $60 at amazon. Free on the internet it will stay |
| 17:56 | <theMadness> | Question, is http://www.css-zibaldone.com/test/generate/counters-pseudo-elements-000.html an opera bug, or is it a false expectation? |
| 17:56 | <TabAtkins> | Is what an opera bug? |
| 17:57 | <theMadness> | Should li have a counter if I tell them to be display:block ? |
| 17:57 | <gsnedders> | theMadness: Opera bug |
| 17:57 | <gsnedders> | theMadness: the fact it's display:block has no effect |
| 17:57 | <TabAtkins> | theMadness: You're seeing *no* counters in Opera, correct? |
| 17:57 | <gsnedders> | s/has/should have/ |
| 17:58 | <gsnedders> | TabAtkins: right |
| 17:58 | <theMadness> | TabAtkins, yep, none is present. |
| 17:58 | <theMadness> | Not that this case has any real world implication tbh. |
| 17:58 | <theMadness> | list-item and block are pretty similar to each other. |
| 17:59 | <TabAtkins> | Yeah, that's a bug. Making the <li>s display:block should suppress the *automatic* counter, but should have no effect on the one you manually inserted via ::before. |
| 17:59 | <TabAtkins> | Yeah, list-item is a block with magic. |
| 17:59 | <TabAtkins> | It just means "generate the ::marker pseudoelement for this box". |
| 17:59 | <jwm> | I don't like opera :/ |
| 17:59 | <theMadness> | Yeah, that's relevant. |
| 18:00 | <jwm> | I know I know |
| 18:03 | <theMadness> | Anyone knows if Opera contacts you when they fix a bug you reported? Like an automated thing even. |
| 18:10 | <AryehGregor> | I've never been contacted, but then, maybe they just never fixed my bugs. |
| 18:10 | <Philip`> | theMadness: They don't |
| 18:11 | <AryehGregor> | Even Microsoft lets you see the bugs you filed. |
| 18:11 | <AryehGregor> | Even if it's just to hear "Won't fix for this release" one day after you file it. |
| 18:11 | <Philip`> | The only contact is when asking for more information, or when asking if you want to be acknowledged for a security bug they fixed, as far as I'm aware |
| 18:11 | <Philip`> | The easy solution is to get hired by Opera |
| 18:11 | <Philip`> | That's worked for most people in here |
| 18:22 | <chris_7> | TabAtkins, Do you know if Lisp in a Box comes with Emacs 23.1.1? |
| 18:29 | <TabAtkins> | chris_7: No clue - never used that distro. |
| 18:32 | <chris_V> | TabAtkins, don't think it does. I think it's pretty specific to the textbook |
| 19:15 | <chris_7> | TabAtkins, this book is quite spectacular and is exactly in the right direction I needed. Thanks for the suggestion :) |
| 19:24 | <TabAtkins> | You're welcome! |
| 19:45 | <annevk> | TabAtkins, flex draft reads nicely! |
| 19:46 | <annevk> | but uh, calc(20px + 1fl)? must be the most ugly CSS syntax ever |
| 19:48 | <annevk> | flex units somewhat make sense on their own, but adding them to normal lengths seems really odd |
| 19:50 | <Peter-> | 20px as the minimum width using the calc statement? |
| 19:51 | <annevk> | preferred width |
| 19:51 | <Peter-> | These additional 20px change the available width, thus influencing the fl-value itself |
| 19:51 | <annevk> | meaning it can get smaller if there really is a need |
| 19:54 | <TabAtkins> | annevk: Yeah, I know, but I don't think there's any way to express preferred lengths that isn't ugly or verbose. |
| 19:55 | <roc> | maybe Andrew's right and we should go without preferred widths until there's a clearer need |
| 19:55 | <TabAtkins> | I think the uses that you brought up, roc, are pretty clear. |
| 19:55 | <roc> | well |
| 19:56 | <roc> | he's right that you can kind of hack around most of them |
| 19:56 | <TabAtkins> | Though, perhaps some of them can be done with just a min instead of preferred. |
| 19:56 | <annevk> | and some can be done using media queries |
| 19:56 | <annevk> | the draft lacks a definition of <flex> btw |
| 19:56 | <roc> | from my point of view, the main thing that sucks about not having preferred widths is that the existing Gecko and Webkit flexbox users won't map easily into the new world |
| 19:56 | <TabAtkins> | annevk: Yeah, I know. I've got some handwaveyness right now. |
| 19:57 | <roc> | but I don't want that to slow down flexbox for the Web |
| 19:57 | <annevk> | and is stuff like margin:0 auto 0 1fl; all clear? |
| 19:58 | annevk | wonders how much of chapter 9/10 of CSS is affected |
| 19:58 | <TabAtkins> | annevk: Yes. See 7.1.1 |
| 19:58 | <TabAtkins> | Or, I guess, 7.1.1.3 |
| 19:58 | <roc> | dbaron: ^^^ |
| 19:58 | <annevk> | 7.1.1 doesn't seem to take into account elements with intrinsic widths for instance |
| 19:59 | <TabAtkins> | annevk: Elaborate? |
| 19:59 | <annevk> | 7.1.1.1 |
| 19:59 | <annevk> | well, the 'width' can be auto, but you wouldn't want it to be treated as 1fl |
| 19:59 | <annevk> | methinks |
| 19:59 | <TabAtkins> | width:auto is treated as 1fl only if it's the only flexible length in that direction for that element. Otherwise it's treated as fit-content. |
| 20:00 | <annevk> | and height would also become 1fl without taking into account the aspect ratio? |
| 20:01 | <annevk> | we have so many special cases currently for all these scenarios should all that be thrown away? guess it would make things easier... |
| 20:01 | <TabAtkins> | Current flexbox draft, when translated into my new draft, essentially makes 'auto' equal to "fit-content" along the box-pack axis, and "1fl" along the box-align axis. |
| 20:01 | <TabAtkins> | Yes, it doesn't care about aspect ratio. |
| 20:01 | <annevk> | i'm not sure how much i like that |
| 20:02 | <annevk> | also, is 'fit-content' defined? |
| 20:02 | <TabAtkins> | I assume it's somewhere. dbaron's mentioned it before. |
| 20:03 | <annevk> | in http://dbaron.org/css/intrinsic/ ... |
| 20:03 | <TabAtkins> | It's a new name for 'intrinsic', yeah. |
| 20:03 | <annevk> | also not defined ;) |
| 20:03 | <TabAtkins> | "shrinkwrap", then. ^_^ |
| 20:04 | <annevk> | jaja |
| 20:06 | <roc> | 'intrinsic' isnt' defined, but it is used so we may as well keep using it :-) |
| 20:08 | <annevk> | i'm not opposed to having it |
| 20:08 | <annevk> | i'm mildly opposed to Opera having to reverse engineer what it means |
| 20:08 | <annevk> | but I think we might have already |
| 20:08 | <TabAtkins> | It's "whatever you do to floats". |
| 20:09 | <TabAtkins> | Also, tables. |
| 20:09 | <roc> | right |
| 20:09 | <annevk> | sure yeah, all things that are not really defined |
| 20:09 | <TabAtkins> | (I use display:table-cell sometimes as a temporary hack for width:fit-content.) |
| 20:09 | <roc> | CSS needs to define that |
| 20:10 | <roc> | just use width:-moz-fit-content :-) |
| 20:10 | <TabAtkins> | I'd like it to work in IE8 too. ^_^ |
| 20:10 | TabAtkins | is using -moz-fit-content on a page of his, though, where it doesn't matter that the thing defaults to width:auto everywhere else. |
| 20:11 | <TabAtkins> | annevk: It's just max(min-content, min(max-content,available width)). |
| 20:11 | <TabAtkins> | Where "min-content" is "the width if you take every linebreak opportunity possible" and max-content is "the width if you don't take any non-forced linebreaks". |
| 20:15 | <annevk> | TabAtkins, it's a) not that simple and b) not defined by CSS in detail so far |
| 20:15 | <annevk> | but I have to go now; ttyl |
| 20:15 | <TabAtkins> | annevk: Sure. But it needs to be, so I'll just depend on it and assume that it will be defined. |
| 20:17 | <jgraham> | theMadness: Yeah, really getting hired is the only way |
| 20:20 | <Dashiva> | jgraham: Or volunteer ;) |
| 20:22 | <zcorpan_> | so how long will it take until someone implements this with html5 http://vimeo.com/9194146 |
| 20:23 | <TabAtkins> | Damn you, Linux flash player! |
| 20:46 | <jgraham> | Dashiva: Oh yeah good point, you could volunteer. No idea how one does that though |
| 20:49 | <AryehGregor> | Hmm. Loading of my ad script blocks loading of my page. Is there any way to avoid that cross-browser? Like could I just put it in an iframe, or would that have bad consequences? |
| 20:51 | <AryehGregor> | Ideally, could I stop the script from freezing my page? It seems to be freezing my page right now for some reason. |
| 20:51 | <AryehGregor> | Some kind of malfunction. |
| 20:53 | <AryehGregor> | Oh, it already is an iframe . . . blast. |
| 20:53 | <AryehGregor> | Some script from quantserve.com is hanging the page. Drat it. |
| 20:53 | <AryehGregor> | Hopefully only for me. |
| 21:05 | <Philip`> | AryehGregor: Obvious solution: Delete the ad script blocks |
| 21:06 | <AryehGregor> | Amazing idea. Too bad it will cost the site owner the several thousand dollars a year that I need to pay for bandwidth and hardware. |
| 21:06 | <AryehGregor> | (he needs, rather) |
| 21:15 | <jgraham> | AryehGregor: Swap to an ad provider with less broken scripts |
| 21:15 | <AryehGregor> | jgraham, except that a) this one makes me twice as much money as AdSense, b) it prohibits concurrent use of other gaming-related ad providers, so I can't experiment much. |
| 21:15 | <AryehGregor> | Also, they've mostly worked okay. |
| 21:15 | <AryehGregor> | I would have thought that scripts in an iframe wouldn't interfere with stuff outside the iframe, but I guess I was wrong. |
| 21:16 | <jgraham> | AryehGregor: This doesn't sound like "mostly working OK" |
| 21:16 | <AryehGregor> | To be fair to them, it might have been a problem with Chrome dev channel. We've had them for a year, this was the only time I've seen it, and it didn't show up in Firefox or when I restarted Chrome. |
| 21:16 | <AryehGregor> | So really it would be nice more because I'd like loading not to block for the extra few hundred ms. |
| 21:16 | <AryehGregor> | Or rendering, I guess I mean. |
| 21:16 | AryehGregor | types how many ms it is |
| 21:17 | <jgraham> | The idea of letting some random third part write more or less anything they like into my page is mildly terrifying |
| 21:17 | <jgraham> | Aren't there any ad companies who compete on not doing that |
| 21:17 | <Philip`> | jgraham: You mean like blog comments? |
| 21:18 | <jgraham> | Philip`: No, I mean unlike blog comments, which tend to be heavily sanitised first |
| 21:18 | <Philip`> | Oh, I guess your "anything" includes arbitrary HTML |
| 21:19 | <AryehGregor> | $9,000 a year is enough to offset any terror I may have at that thought. |
| 21:19 | <AryehGregor> | (particularly since hosting costs more than $6,000 and there are no other meaningful revenue sources for the site) |
| 21:19 | <Philip`> | It seems much more profitable for ad companies to compete on how simple it is to embed their ads into your page, and how they can update their implementation without having to tell you to update your embedding code, which in practice means they'll just make you use an <iframe> or a <script>, I guess |
| 21:20 | <AryehGregor> | Except that they don't necessarily compete so much. In fact, the one I use has explicit anti-competitive wording in its EULA, prohibiting you from trying out competitors, and this seems to be typical. |
| 21:20 | <AryehGregor> | Although your conclusion holds, yes. |
| 21:21 | <AryehGregor> | They want to be able to update without changing the deployed HTML. |
| 21:21 | <AryehGregor> | Plus they want to collect data that's only available to script, for better targeting and maybe for resale. |
| 21:21 | <AryehGregor> | (good thing my site has no meaningful privacy policy) |
| 21:25 | <jgraham> | Surely there must be somewhere that clauses like "you are forbidden from trying our competitors" are illegal |
| 21:25 | <AryehGregor> | Doubtful. |
| 21:25 | <AryehGregor> | It might be only if it's on the same page, though. |
| 21:25 | <AryehGregor> | Let me check. |
| 21:26 | <AryehGregor> | Nope: "Use of other gaming networks to sell advertising space on a web site which has its advertising space being sold by GAO is subject to Our mutual agreement." |
| 21:26 | <Philip`> | Maybe they'd have a hard time successfully suing you for trying a competitor, but they can just cancel your account and keep all your money |
| 21:26 | <AryehGregor> | GamerDNA has a similar requirement, except vastly more horrible. |
| 21:27 | <AryehGregor> | Yes, and I don't want to break my agreements anyway. |
| 21:27 | <Philip`> | so it doesn't need to be a legally viable thing |
| 21:27 | <jgraham> | Philip`: There are practical issues |
| 21:27 | <jgraham> | I'm not suggesting you should break it |
| 21:27 | <jgraham> | I'm wondering if its legal |
| 21:28 | <gsnedders> | Quick! Find a lawyer! |
| 21:28 | <jgraham> | Nah, better to wildly speculate |
| 21:28 | <AryehGregor> | I'm pretty sure it's legal. |
| 21:29 | <AryehGregor> | Exclusivity is pretty common in all sorts of contracts, no? |
| 21:29 | <jgraham> | (it would be pretty surprising if, say, Apple buried somewhere in the iTunes license agreement that you were prohibited from using other media players) |
| 21:29 | <jgraham> | I guess |
| 21:29 | <AryehGregor> | I imagine that's a different story, since you don't have large sums of money changing hands there. |
| 21:30 | <jgraham> | AutoCAD then |
| 21:30 | <AryehGregor> | http://en.wikipedia.org/wiki/Contract_of_adhesion#Contracts_of_adhesion |
| 21:32 | <AryehGregor> | It seems to me that there's a difference between saying "you can't serve someone else's software from your site" and "you can't have other software installed separately on your desktop". |
| 21:32 | <AryehGregor> | Although I can't put my finger on it. |
| 21:32 | <AryehGregor> | Anyway, they're jerks, yes. I wish I could shop around some more. |
| 21:33 | <AryehGregor> | Actually, what I wish is that AdSense gave me non-pathetic amounts of income. It was running things like Muslim dating sites, on my gaming forum, because someone mentioned Islam somewhere in their signature. Srsly. |
| 21:34 | <AryehGregor> | Or better yet, it ran Muslim dating ads in topics in our politics forum about how the Muslims are all devil-worshiping terrorists who should be nuked. Kind of the wrong audience. |
| 21:35 | <jgraham> | Maybe it was playing devils-advocate? |
| 21:36 | <TabAtkins> | Running on the "those who complain most loudly..." theory? |
| 22:23 | <AryehGregor> | Oh, Tab is still using 2048-bit hashes to index his content. |
| 22:23 | AryehGregor | boggles at URL |
| 22:24 | <TabAtkins> | Wanna fight about it? |
| 22:31 | <jgraham> | [18:42] <jgraham> chris_7: Also, you should know TabAtkins is insane |
| 22:31 | <jgraham> | Clearly this is not widely enough known |
| 22:32 | <TabAtkins> | Look, I provide a shorturl for you people. Why aren't you happy with that? |
| 22:32 | <chris_7> | jgraham, there is method to TabAtkins insanity |
| 22:32 | <TabAtkins> | Just don't look at the url bar after following the shorturl. |
| 22:34 | <chris_7> | jgraham, You might also want to look at the end of this channels /topic haha |
| 22:47 | <AryehGregor> | TabAtkins, I just read on Slashdot about some security researcher trying to jump on the clickjacking bandwagon by making up a cool name for his hypothetical attack. It was "tabnapping", which immediately reminded me of "catnap" rather than "kidnap", so I pictured you taking a nap. |
| 22:47 | <AryehGregor> | Rather than one of my browser's tabs being abducted, as intended. |
| 22:48 | <AryehGregor> | (although I use "picture" loosely, since I have no idea what you look like) |
| 22:48 | <TabAtkins> | I do, in fact, kidnap people. I'm unshaven and dressed in a cat-burglar outfit. |
| 22:50 | <AryehGregor> | Do cat-burglars normally kidnap people? |
| 22:50 | <TabAtkins> | I'm bucking the trend. |
| 22:50 | <TabAtkins> | That way no one suspects me. |
| 22:50 | <AryehGregor> | Ingenius. |
| 22:51 | <TabAtkins> | They're all "Oh, that dude's just knocking over a house.", while really I'm all shoving people in my trunk. |
| 22:51 | <svl> | AryehGregor: not a "Security researcher" - Aza, Firefox's "Creative Lead" - http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/ |
| 22:51 | <AryehGregor> | Oh, okay. |
| 22:51 | <AryehGregor> | I didn't actually read the story, looked boring and overhyped. Like most stories about hypothetical threats, especially social-engineering-type attacks like this. |
| 22:52 | <AryehGregor> | Also, I read in the Slashdot summary something like "Most users know by now not to click links in suspicious e-mails", and whoever wrote that instantly lost all credibility in my eyes. |
| 22:52 | <Philip`> | The problem is clicking links in non-suspicious emails |
| 22:53 | <Philip`> | It's no good if you're only protecting yourself against incompetent attackers who can't make a plausible-looking email |
| 22:53 | <svl> | I don't think this was ever intended to be this widely hyped and re-reported. Just part of the thinking process about the new Firefox account manager, and what sort of potential situations it'd need to deal with |
| 22:54 | <AryehGregor> | I was going to say, the Firefox Account Manager is the right way to go here, to fight phishing. |
| 22:56 | <AryehGregor> | This doesn't seem like it needs different types of countermeasures to usual phishing, does it? |
| 22:56 | <AryehGregor> | Seems not. |
| 22:57 | <AryehGregor> | It is a pretty slick demonstration, though. |
| 23:10 | <chris_7> | TabAtkins, Do you know of a Lisp specific irc channel I can join? I'm probably going to be needing it soon. |
| 23:10 | <TabAtkins> | I do not, unfortunately. |
| 23:10 | <chris_7> | Unfortunate |
| 23:10 | <TabAtkins> | Though there is #lisp on freenode. |
| 23:10 | <TabAtkins> | Which has a lot of people in it |
| 23:11 | <chris_7> | Thanks :) I'd rather use there to ask questions about it. Want to stay on channel topic |
| 23:41 | <MikeSmith> | very cool to see that Mozilla is now getting a built-in DOM inspector |
| 23:41 | <MikeSmith> | already now in Minefield |
| 23:41 | <MikeSmith> | http://antennasoft.net/robcee/2010/05/14/inspector-landing/ |
| 23:41 | <TabAtkins> | Ah, really? |
| 23:41 | <Rik`> | MikeSmith: I don't understand why it has to be a new tool |
| 23:42 | <MikeSmith> | http://antennasoft.net/robcee/2010/05/21/inspector-impetus/ |
| 23:42 | <Rik`> | I've already read that and it's not explaining anything |
| 23:42 | <MikeSmith> | Rik`: you mean as opposed to building with Firebug or the existing DOM Inspector extension? |
| 23:42 | <Rik`> | yep |
| 23:43 | <Rik`> | it's not introducing a new UI from the screenshots I've seen |
| 23:43 | <boblet> | wow, you’re up early Mike. meetings? |
| 23:44 | <MikeSmith> | there seem to be some good clarifications in the comments of http://antennasoft.net/robcee/2010/05/21/inspector-impetus/ |
| 23:44 | <MikeSmith> | comment from Colby Russell |
| 23:45 | <MikeSmith> | and from Rob too |
| 23:45 | <MikeSmith> | e.g., " It’d be technically difficult to include Firebug in its entirety in Firefox, requiring a significant rewrite to get the code in line with the browser’s." |
| 23:46 | <MikeSmith> | and from Colby: Firebug guys have their own approach and way of development, outside of Mozilla’s infrastructure" but .." there’s nothing saying future convergence is out of the question. " |
| 23:47 | <AryehGregor> | Yeah, I was glad to see this too. |
| 23:47 | <MikeSmith> | boblet: yeah |
| 23:47 | <AryehGregor> | It will be quite a while till it gets up to speed with WebKit's Web Inspector, I'd guess, let alone Firebug (which is reportedly better than WebKit's Web Inspector but I never noticed). |
| 23:47 | <MikeSmith> | AryehGregor: true that |
| 23:47 | <AryehGregor> | (although I did notice when I used Firebug in Firefox and Gmail warned me that I should disable it or else it would slow down the site) |
| 23:48 | <AryehGregor> | (I think they eventually fixed that) |
| 23:48 | <MikeSmith> | wow, yeah I hope so |
| 23:48 | <Rik`> | MikeSmith: I don't get the point of including a less powerful and stable tool inside Firefox |
| 23:49 | <TabAtkins> | Yeah, they fixed that a long time ago. |
| 23:49 | <AryehGregor> | That was before they required you to enable the Net tab on a site-by-site basis. |
| 23:49 | <MikeSmith> | AryehGregor: anyway, it seems like Rob has carved out some time to work on it in earnest so I'd expect to see it improve pretty quickly |
| 23:49 | <Rik`> | I mean every web developer that needs a tool knows Firebug |
| 23:49 | <AryehGregor> | Rik`, because it will be *more* stable in the long run, and will be available when you're debugging some random dude's computer. |
| 23:49 | <TabAtkins> | I find Firebug to be *much* better than Webkit's inspector, but that may be partially just usability. |
| 23:49 | <MikeSmith> | Rik`: what AryehGregor said |
| 23:49 | <AryehGregor> | It will actually be available consistently. |
| 23:50 | <AryehGregor> | Like, you know, you don't have to wait for Firebug to be released for the new Firefox version, and upgrade it separately. |
| 23:50 | <Rik`> | that's a separate problem |
| 23:50 | <TabAtkins> | (Though, a recent change where hovering an element in firebug makes a box pop up with inherent dimensions is actually *really freaking annoying*.) |
| 23:50 | <AryehGregor> | No it's not, it's inherent to the separate development as an extension. |
| 23:50 | <AryehGregor> | Or maybe to Firefox's unstable extension interface that breaks on every release. |
| 23:50 | <Rik`> | 3.6 came with a stable version of Firebug |
| 23:51 | <AryehGregor> | Well, that's after I stopped using Firefox as my main browser, so I can't say. |
| 23:51 | <AryehGregor> | TabAtkins, what features does Firebug have that you miss in WebKit's Web Inspector? |
| 23:51 | <boblet> | Rik`: not having it as part of Firefox is starting to seem strange, as all the other browsers have (or apparently will have) dev tools bundled |
| 23:52 | <TabAtkins> | AryehGregor: I don't think you can add CSS rules directly to particular declaration blocks in webkit's inspector. |
| 23:52 | <boblet> | (fingers crossed that the IE team feels embarrassed enough to make something half way usable for IE9) |
| 23:52 | <AryehGregor> | TabAtkins, I'm pretty sure you can. |
| 23:52 | <Rik`> | boblet: they have a dev tool in IE8 already |
| 23:53 | <TabAtkins> | AryehGregor: Could you tell me how? ^_^ I'm clicking around in the logical areas and nothing useful is happening. |
| 23:53 | <Rik`> | but you don't have to make a new tool to get Firebug installed with Firefox |
| 23:53 | <boblet> | Rik`: not quite Dragonfly/Inspector level yet tho |
| 23:53 | <Rik`> | TabAtkins: double clicking |
| 23:53 | <TabAtkins> | That lets me edit a particular rule in a block, but not to add new rules. |
| 23:54 | <Rik`> | TabAtkins: tabbing to the last rule |
| 23:54 | <TabAtkins> | Rik`: Ah, got it. |
| 23:55 | <Rik`> | you also have a "New style rule" option in the gear menu |
| 23:55 | <TabAtkins> | Well, I guess that's about everything then. The rest of the things I use is here now (last time I seriously tried to use webkit's inspector it was much simpler). |
| 23:56 | <Rik`> | there has been a lot of work from Google guys |
| 23:57 | <Rik`> | anyway, creating a new tool from nothing just to make it a default seems like dividing the amount of work by two on each tool |
| 23:58 | <MikeSmith> | http://www.openvideoconference.org/proposals/ "We are now accepting proposals for panels, presentations, workshop sessions, demo sessions, and other programming for the next Open Video Conference in New York City" |
| 23:58 | <MikeSmith> | deadline June 7 |
| 23:58 | <Rik`> | TabAtkins: do you know if there has been a lot of requests for nested rules in CSS ? |
| 23:59 | <TabAtkins> | Rik`: Well, it's a feature of every CSS preprocessor I know of. |