| 00:42 | <AryehGregor> | "I am reminded of a joke about mathematicians. One argues that it is obvious that claim A follows from B. The other disagrees. After arguing for an hour, the latter finally agrees that A obviously follows from B." |
| 00:42 | <AryehGregor> | I've seen that one happen. |
| 00:43 | <zewt> | i'm not sure why that guy figured that ridiculing people on the list was a good way to get help, heh |
| 00:44 | <AryehGregor> | A professor told me something was trivial. Then he sat thinking for a few minutes about how to prove it. Then he said he'd e-mail me later about it. Then he e-mailed me an hour or two later with a proof. Then he sent me a corrected proof because there was a mistake in the first one. |
| 00:44 | <AryehGregor> | Quote from first e-mail: "I found the proof of the fact about Sylow subgroups during the lunch. Indeed it is trivial. |
| 00:44 | <AryehGregor> | " |
| 00:45 | <AryehGregor> | (the proposition under discussion was "if G is a finite group, and P is a Sylow subgroup of P, then if H contains the normalizer of P in G, H is its own normalizer in G") |
| 01:48 | <jwalden> | anyone know of software that can tell me what codecs are associated with a given media file, for the purposes of filling in a codecs="" parameter? |
| 01:59 | <jwalden> | http://www.deathofthediv.com/ (from scrollback) would be more pleasant if there were a way to stop the audio, other than javascript:Array.prototype.forEach.call(document.getElementsByTagName("audio"),function(a){a.pause();});[].v |
| 02:04 | <tw2113> | i don't agree with it's death anyway |
| 02:04 | <tw2113> | it hasn't been replaced in every single instance |
| 02:05 | <zewt> | browsers should really be asking permission to play audio |
| 02:05 | <zewt> | first time per origin anyway |
| 02:05 | <zewt> | one of the biggest reasons I block flash is because sites love to use it to play audio without permission, heh |
| 02:06 | <zewt> | hopefully before long browsers will also have a quick way to answer the age-old question: "which stupid tab is making noise?" |
| 02:07 | <jwalden> | gecko has a pref to control |
| 02:07 | <jwalden> | er, s/$/ it/ |
| 02:07 | <tw2113> | hmmm interesting idea...min/max font size |
| 02:07 | <jwalden> | but (I haven't checked) I'm guessing there's no UI because any such would be inextricably entangled with the underlying technical difference being explainable to the user |
| 02:08 | <jwalden> | and flash is still around |
| 02:08 | <zewt> | i would expect <audio> to not cripple itself in order to be cripple-compatible with flash |
| 02:08 | <zewt> | (also video, of course) |
| 02:09 | <zewt> | i'd expect it's more due to these being relatively new features ... not exactly sure when audio actually showed up in FF |
| 02:22 | gsnedders | wonders if it's worthwhile having a spec require javascript:Array.prototype.forEach.call(document.getElementsByTagName("audio"),function(a){a.pause();}); to work |
| 02:22 | <gsnedders> | (currently ES5 makes no guarantee that'll work because NodeList is a host object) |
| 04:19 | <benschwarz> | chriseppstein hi! |
| 04:19 | <chriseppstein> | benschwarz: yo |
| 04:20 | <benschwarz> | I saw a presentation of yours online somewhere the last few days… |
| 04:21 | <benschwarz> | if only I could find it now… |
| 04:21 | <chriseppstein> | http://vimeo.com/18084338 ? |
| 04:21 | <benschwarz> | chriseppstein no, perhaps something older? |
| 04:21 | <benschwarz> | It was in the same vein as something I'd written about or thought about recenty |
| 04:22 | <chriseppstein> | was it a slide deck or a video? |
| 04:22 | <chriseppstein> | or screencast? |
| 04:22 | <benschwarz> | only I got up mad early today and my memory is shot :) |
| 04:22 | <benschwarz> | chriseppstein it had both, I think |
| 04:23 | <benschwarz> | either way, I guess its not important |
| 04:23 | <chriseppstein> | http://vimeo.com/13804978 |
| 04:23 | <benschwarz> | but big ups |
| 04:23 | <chriseppstein> | http://vimeo.com/4335944 |
| 04:24 | <chriseppstein> | *shrugs* something you want to know about? |
| 04:24 | <benschwarz> | chriseppstein, nah, I just wanted to say whatup |
| 04:24 | <chriseppstein> | oh |
| 04:24 | <chriseppstein> | :) |
| 04:24 | <chriseppstein> | hi |
| 04:25 | <nimbupani> | benschwarz is a bit too tired after all the media attention today |
| 04:25 | <benschwarz> | haha |
| 04:25 | <benschwarz> | I got a dodgy leg from my phone vibrating |
| 04:25 | <chriseppstein> | ya? what'd you do now? |
| 04:25 | <benschwarz> | no, thats too silly. |
| 04:26 | <nimbupani> | this https://twitter.com/benschwarz/status/39791557217353728 |
| 04:26 | <benschwarz> | nimbupani is my media dept |
| 04:26 | <nimbupani> | hahahahaha |
| 04:26 | <chriseppstein> | oh neat |
| 04:27 | <chriseppstein> | now it has 69 RTs |
| 04:27 | <chriseppstein> | :D |
| 04:27 | <chriseppstein> | just cuz I like the # |
| 04:28 | <nimbupani> | haha :) |
| 04:28 | <chriseppstein> | benschwarz: plz add css to this kthxby |
| 04:28 | <chriseppstein> | e |
| 04:29 | <nimbupani> | chriseppstein: you mean css official site :) |
| 04:32 | <chriseppstein> | nimbupani: I'm tired of reading the css specs :( |
| 04:32 | <nimbupani> | ohh |
| 04:33 | <nimbupani> | yeah :| |
| 04:33 | <nimbupani> | well lets hope it gets fixed too :) |
| 04:33 | <nimbupani> | they are pretty nice people who run that stuff SOOOO |
| 04:33 | <nimbupani> | :) |
| 04:34 | <benschwarz> | chriseppstein theres a bookmarklet for that |
| 04:34 | <nimbupani> | hahahaha |
| 04:34 | <nimbupani> | readability! |
| 04:36 | <benschwarz> | chriseppstein http://www.germanforblack.com/articles/moving-towards-readable-w3c-specs |
| 04:37 | <chriseppstein> | lol. tell us how you _really_ feel ben |
| 04:39 | <nimbupani> | REALLY |
| 07:09 | <rooftopjoe> | i posted this on #html earlier but this seems like a good place to ask as well |
| 07:09 | <rooftopjoe> | can anyone explain to me why it is important that html files are human-readable? |
| 07:09 | <rooftopjoe> | it seems to me like it's a waste of bandwidth |
| 07:09 | <rooftopjoe> | the same is true for all sgml's, xml included. but perhaps i just don't understand the reason yet |
| 07:15 | <SteveGL> | Because they're markup languages designed to be platform-independent and human editable in a text editor? You could use a compressor tool to shrink down a final product for distribution though. |
| 07:18 | <rooftopjoe> | SteveGL: fair enough but wouldn't it have made more sense to devise someththing else for distribution? i don't think browsers commonly support gzipped html, for instance |
| 07:19 | <rooftopjoe> | SteveGL: i guess what i'm saying is... hadn't it made more sense to have had something like a HTML compiler that produces something more suitable for machines? |
| 07:19 | <rooftopjoe> | i'm sorry if my english is not very good |
| 07:20 | <SteveGL> | Well gzip seems well supported in my experience, but I was referring to tools that regenerate a source file, such as HTML or ECMAScript with compression techniques, like shrinking variable names. |
| 07:20 | <zewt> | every browser supports HTTP compression. |
| 07:21 | <rooftopjoe> | so there's no real advantage, except for the commodity of being human readable, right? |
| 07:21 | <zewt> | that's a massive advantage. |
| 07:21 | <rooftopjoe> | in other words, it wouldn't make sense for an application to be based on a SGML-like document if the human never interacted with said document_ |
| 07:21 | <SteveGL> | Well, compiling the source would take away it's ability to be platform independent. |
| 07:22 | <SteveGL> | And yes, human readability is a big bonus. |
| 07:22 | <zewt> | "compiling" it is a huge cost: you still have to specify the human-readable source, but you also have to define a compiled format on top of it, and then maintain both formats in sync--for very little benefit |
| 07:23 | <rooftopjoe> | i know the overhead for parsing a sgml document can't be very big but it somehow doesn't feel right to me to waste resources :) |
| 07:24 | <zewt> | developing and speccing a compiled format, which every browser would have to support, and every web server would have to support, would be wasting resources |
| 07:24 | <zewt> | most pages are not bandwidth-limited by HTML. |
| 07:26 | <rooftopjoe> | zewt: i agree with you. just trying to understand the historical perspective |
| 07:26 | <rooftopjoe> | in the past, it would have been less painful |
| 07:26 | <SteveGL> | I really don't see any advantage to a compiled form, maybe in the 90s.. |
| 07:26 | <rooftopjoe> | SteveGL: some embedded devices, perhaps. and (very) low connectivity |
| 07:27 | <rooftopjoe> | that's all i really have in mind |
| 07:27 | <rooftopjoe> | but i guess i got my question answered so thanks :) |
| 07:39 | <erlehmann> | even embedded devices could have rudimentary browsers. |
| 07:58 | <annevk> | oh lol |
| 07:58 | <annevk> | the HTTP WG discovers Sec- now?! |
| 07:58 | <annevk> | that has been around for like four XHR Last Call in which we repeatedly invited the HTTP WG to comment |
| 07:58 | <benschwarz> | annevk … |
| 07:58 | <annevk> | benschwarz? |
| 07:59 | <benschwarz> | annevk thanks for the pickup on spelling today (your only feedback ;)) |
| 07:59 | <benschwarz> | I thought a whatwg post might be in order on the blog… |
| 07:59 | <annevk> | yes, do you have an account? |
| 08:00 | <annevk> | my other feedback would be that I was confused by "syncing" and miss the WHATWG logo |
| 08:00 | <annevk> | other than that it's pretty neat |
| 08:01 | <annevk> | oh, and maybe you should hide "in this section" when clicking it will do nothing |
| 08:03 | <annevk> | benschwarz, I can write something too btw if you prefer that, but typically people announce their own projects |
| 08:03 | <benschwarz> | annevk: its doing nothing? |
| 08:03 | <benschwarz> | looks like a regression bug :) |
| 08:03 | <benschwarz> | link? |
| 08:04 | <benschwarz> | "syncing" is probably confusing |
| 08:04 | <annevk> | it usually works, but not on e.g. http://developers.whatwg.org/acknowledgements.html as that has no subsections |
| 08:05 | <annevk> | oh, and it needs a favicon I suppose |
| 08:10 | <annevk> | benschwarz, let me know if you need help with the blog |
| 08:11 | <benschwarz> | annevk, ah, I'll check that thanks |
| 08:11 | <benschwarz> | annevk, doesn't it have a fav icon already? |
| 08:11 | <annevk> | oh it does |
| 08:11 | <annevk> | oops |
| 08:11 | <benschwarz> | (it does, however your browser isn't webkit I'm guessing…) |
| 08:11 | annevk | keeps looking in the address bar |
| 08:12 | <zewt> | broken address bar? :P |
| 08:12 | <annevk> | I'm using Opera |
| 08:13 | <annevk> | zewt, I keep thinking favicons are located there |
| 08:13 | <zewt> | heh, i find it endlessly amusing that every browser now feels the need to rename the address bar |
| 08:13 | <annevk> | but we moved them to tabs |
| 08:13 | <zewt> | it's not an address bar! it's a WHIZ-BANG BAR |
| 08:14 | <annevk> | benschwarz, I see that in Safari things are a bit different :) |
| 08:14 | <zewt> | i'd think it should still be shown in the address bar |
| 08:14 | <zewt> | don't know what opera's UI is looking like these days though |
| 08:15 | <benschwarz> | annevk are you seeing something unexpected? |
| 08:15 | <benschwarz> | I haven't testd opera a lot… |
| 08:15 | <annevk> | no, just the things I mentioned before |
| 08:15 | <benschwarz> | annevk, I suppose I could write a post |
| 08:15 | <benschwarz> | on whatwg (sorry, just circling back) |
| 08:15 | <SteveGL> | Opera's interface design has gotten much much better since version 9. |
| 08:16 | <annevk> | Safari is quite weird too |
| 08:16 | <SteveGL> | it's gotten more minimal and slick. |
| 08:16 | <annevk> | and in my version of Chrome clicking "in this section" does not work at all? |
| 08:16 | <SteveGL> | along with modernized. |
| 08:16 | <annevk> | benschwarz, cool! |
| 08:17 | <zewt> | i remember opera being fairly minimal ... *after* one turns off about 520 toolbars and side menus and whatever |
| 08:17 | <annevk> | benschwarz, I can make you an account, any preferences? |
| 08:18 | <benschwarz> | annevk I have "benschwarz" already, afaik |
| 08:19 | <annevk> | no |
| 08:20 | <annevk> | if you /msg me email name website temp-password I can set one up |
| 08:22 | <MikeSmith> | benschwarz: accounts for blog are provisioned separately from the user accounts for the shell server |
| 08:22 | <benschwarz> | oh right |
| 08:23 | <benschwarz> | MikeSmith, ps, you got mail - http://lists.w3.org/Archives/Public/www-archive/2011Feb/0051.html |
| 08:23 | <MikeSmith> | yeah |
| 08:23 | <MikeSmith> | I can make the change the contrast issue |
| 08:26 | <benschwarz> | MikeSmith - What do you think about the two specs being "the same"? How accurate is that? |
| 08:27 | <MikeSmith> | don't know what you mean |
| 08:29 | <MikeSmith> | http://developers.whatwg.org/ looks style-less for me at the moment, btw |
| 08:30 | <benschwarz> | MikeSmith I just did a bunch of deploys. Refresh - Still there? |
| 08:31 | <benschwarz> | MikeSmith, as usual with all things W3C I feel out of my depth :) |
| 08:31 | <MikeSmith> | yeah, but seems to be a local caching issue |
| 08:32 | <benschwarz> | MikeSmith: what are the differences betwen the spec-author-view and the developers.whatwg copies? |
| 08:33 | <MikeSmith> | benschwarz: there are some features that are in the developer.whatwg.org version that are not in the W3C version |
| 08:34 | <MikeSmith> | but that's not something that needs to be an issue for you, as far as I'm concerned |
| 08:34 | <benschwarz> | MikeSmith: I'm a bit concerned that making them look the same will cause confusion… |
| 08:34 | <MikeSmith> | they don't need to look the same |
| 08:34 | <MikeSmith> | who said they needed to look the same? |
| 08:35 | <benschwarz> | MikeSmith they don't. There has been some pressure to update your copy… |
| 08:35 | <MikeSmith> | ah |
| 08:35 | <MikeSmith> | well, that's an issue for me to deal with I guess |
| 08:35 | <MikeSmith> | I don't want to make it a problem for you |
| 08:35 | <MikeSmith> | so I will take care of it |
| 08:36 | <MikeSmith> | but as far as I'm concerned, there is no urgency around it |
| 08:39 | <benschwarz> | MikeSmith, I wonder if we should treat them as the same document—and all collaborate together |
| 08:39 | <benschwarz> | as for "other specs", I think there should be a solid baseline and pattern library |
| 08:41 | <MikeSmith> | I think we are already collaborating. But as you know, there's a non-trivial amount of work that would need to be done to port over the work you did to create the http://developers.whatwg.org/ version |
| 08:41 | <MikeSmith> | and it would be good to get it ported over |
| 08:41 | <MikeSmith> | but that doesn't mean you or I need to stop everything else and do it right now |
| 08:41 | <MikeSmith> | or doesn't mean that either you or I need to be the ones to do it |
| 08:42 | <MikeSmith> | if somebody else feels it's important to do soon, then I'd be happy to let them do the work whenever they want |
| 08:42 | <annevk> | abarth, http://tools.ietf.org/html/draft-abarth-principles-of-origin is great! |
| 08:43 | <annevk> | abarth, I think something like that was required to get CORS to CR |
| 08:43 | <MikeSmith> | wow cool |
| 08:45 | <zewt> | "When a user agent process this element" :) |
| 08:45 | <benschwarz> | MikeSmith I wouldn't trust many people to do it right :) |
| 08:46 | <benschwarz> | MikeSmith — Whats the best way to do it? Rather than handing you css files |
| 08:46 | <benschwarz> | MikeSmith - Maybe we can do it as a project in Tokyo?? |
| 08:46 | <MikeSmith> | benschwarz: yeah |
| 08:46 | <MikeSmith> | that |
| 08:46 | <MikeSmith> | let's do it while you're here |
| 08:47 | <benschwarz> | that would kick ass. |
| 08:47 | <benschwarz> | perhaps in the mean time we should let steven faulkner merge those contrast changes. |
| 08:48 | <benschwarz> | My issue with them was that they were aesthetically horrible colours. |
| 08:48 | <benschwarz> | Which is why I moved away from the green and tones that we used |
| 08:48 | <MikeSmith> | yeah, I'll chat with Steve about those |
| 08:49 | <MikeSmith> | for now, I have to drop off for a bit |
| 08:49 | <MikeSmith> | back later |
| 08:54 | <benschwarz> | ok MikeSmith. |
| 08:54 | <benschwarz> | Later |
| 09:24 | <benschwarz> | annevk - the in this section button is removed for pages without a toc now ;) |
| 09:34 | <annevk> | cool |
| 09:36 | <annevk> | massive spam increase suddenly on blog.whatwg.org |
| 10:01 | <annevk> | spec looks quite neat AryehGregor |
| 11:18 | <alystair> | augh why can't I make fixed postioning relative to something other than the document |
| 11:21 | <AdrianSchmidt> | alystair>> Wouldn't that be exactly the same as absolute positioning? |
| 11:24 | <zcorpan> | AdrianSchmidt: no |
| 11:24 | <AdrianSchmidt> | So what would the element be fixed to? Another element? |
| 11:25 | <zcorpan> | relative to viewport |
| 11:25 | <AdrianSchmidt> | Ah yes, my bad. |
| 11:25 | <AdrianSchmidt> | Of course... |
| 11:26 | <AdrianSchmidt> | I had a brainmelt and though it was relative to viewport already, but of course it's not. |
| 11:31 | <AdrianSchmidt> | Eh... no, I was right to begin with. Sorry. |
| 11:31 | <AdrianSchmidt> | From the specs: |
| 11:31 | <AdrianSchmidt> | Fixed positioning is a subcategory of absolute positioning. The only difference is that for a fixed positioned box, the containing block is established by the viewport. |
| 11:32 | <AdrianSchmidt> | So again. Fixed is positioned relative to the viewport, not the document. And what else could it be relative to? (I'm wondering here, not judging) |
| 11:33 | <AdrianSchmidt> | *gg go buy some lunch, bbs* |
| 11:33 | <zcorpan> | i guess you could make it relative to another element if you act as if the scroll position is at (0,0) or some such |
| 11:33 | <AdrianSchmidt> | scroll position of the document or the element? |
| 11:38 | <annevk> | you might want it relative to a scrolling container |
| 11:40 | <zcorpan> | ah |
| 11:40 | <zcorpan> | right |
| 11:46 | <AdrianSchmidt> | annevk>> Yes, that might make sense. |
| 11:47 | <AdrianSchmidt> | *makes sense |
| 11:52 | <AdrianSchmidt> | You could "hack" around it, by placing the "fixed" element outside the scrolling element and absolute position it, but that would be pretty ugly I guess. |
| 11:52 | <AdrianSchmidt> | Some more flexibility in positioning would be pretty nice :) |
| 12:31 | <thiessenp> | any idea if there is a proposal for an advertising banner element in html? (I know advertising is not a popular topic :) |
| 12:32 | <foolip> | thiessenp, http://wiki.whatwg.org/wiki/Rationale#An_.22advert.22_tag_for_advertisements |
| 12:32 | <zewt> | why would advertisers want to make it easier for every browser to hide ads? heh |
| 12:33 | <thiessenp> | foollip: interesting thanks |
| 12:33 | <aho> | http://www.stevesouders.com/blog/2010/02/15/browser-performance-wishlist/ |
| 12:33 | <aho> | frag tag is somewhat related |
| 12:37 | <aho> | (it's something you'd also use for ads, but unlike some ad tag it would actually make things better for everyone) :> |
| 12:40 | <erlehmann> | thiessenp, class=ad |
| 12:41 | <aho> | i currently use something like aside.left or aside.leader |
| 12:41 | <aho> | works fine :) |
| 12:44 | <MikeSmith> | Philip`: you around? wanted to ask for your assessment of the feasibility of using your assertions-annotation mechanism over the full spec |
| 12:52 | <Philip`> | MikeSmith: I am |
| 12:52 | <MikeSmith> | so do you think it would be feasible or not? |
| 12:54 | <Philip`> | In its current form the performance is probably like O(n^2) (since it scans the whole document for every assertion pattern), but the spec could be split into sections and the assertions labelled with the section to scan so that would probably be okay |
| 12:55 | <MikeSmith> | ok |
| 12:55 | <Philip`> | I guess the main difficulty is that it generally assumes the spec is a load of paragraphs containing sentences |
| 12:56 | <Philip`> | so it wouldn't work adequately with e.g. the parser section, where there's a more complex markup structure |
| 12:56 | <MikeSmith> | hmm |
| 12:57 | <MikeSmith> | so we might have to use some different mechanism for those cases |
| 12:57 | <Philip`> | (though it probably wouldn't be used for that anyway since the parser doesn't really have individually testable assertions at all) |
| 12:57 | <MikeSmith> | ok |
| 12:57 | <Philip`> | (but I don't know if there's other sections which are almost but not quite annotatable in this way) |
| 12:57 | <annevk> | it probably also works poorly for everything that has a set of steps |
| 12:59 | <Philip`> | Yeah, in most cases I just put the annotation with the "These steps must be followed:" phrase |
| 12:59 | <Philip`> | since the steps can't be tested individually |
| 13:00 | <Philip`> | For canvas that's okay since there aren't many complex multi-step algorithms |
| 13:00 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/spec.html#testrefs.2d.shadow.render |
| 13:32 | <MikeSmith> | Philip`: so what is the process for creating the annotations? |
| 13:33 | <MikeSmith> | the annotated spec is a static copy that you generate, right? |
| 13:33 | <MikeSmith> | with that annotations added? |
| 13:33 | <MikeSmith> | s/that/the/ |
| 13:34 | <Philip`> | See tests/submission/PhilipTaylor/tools/canvas in Hg |
| 13:34 | <Philip`> | specextract.py pulls out the canvas section from the original spec and makes current-work-canvas.xhtml |
| 13:37 | <Philip`> | gentest.py does a load of stuff including write_annotated_spec() which reads the .xhtml, and annotates it using spec_assertions (simply read from spec.yaml) and spec_refs (map of assertion id -> [list of test names] generated while processing all the test cases) |
| 13:38 | <Philip`> | (It does that using minidom, and then dumps the output as a static .html file) |
| 15:03 | <MikeSmith> | Philip`: thanks |
| 15:04 | <MikeSmith> | http://twitter.com/#!/rwaldron/status/40062566399082497 "Need to Q&A with someone that has experience with JavaScript canvas text rendering. #javascript #canvas #html5" |
| 15:06 | <annevk> | if you want to change layout, better to complain on www-style⊙wo |
| 15:06 | <annevk> | oops |
| 15:06 | <annevk> | my window was scrolled way up and I did not notice |
| 15:14 | <MikeSmith> | I do that sometimes |
| 15:20 | <alystair> | Augh I went afk too long, what I meant was that fixed positioning should be relative to closest parent that's set to relative... sort of like absolutely positioned things... |
| 15:21 | <alystair> | actually wait, fixed is fixed for a reason... although it does make things more complicated when you have a design with variable widths... meh can easily fix with JS |
| 15:29 | <zcorpan> | would be nice with vertically-absolute-but-horizontally-fixed and the vice versa |
| 15:29 | <zcorpan> | s/the// |
| 16:55 | <aho> | there still isn't a way to specifiy specific font sizes for those fonts in your font stack, right? |
| 17:26 | <TabAtkins> | aho: No, though you can approximate it using font-size-adjust to force all fonts to size themselves to a particular x-height. |
| 17:26 | <TabAtkins> | That's often more-or-less what you want. |
| 17:26 | <aho> | sounds interesting |
| 17:26 | <aho> | well, in this case i want that the text doesnt exceed some specific maximum width |
| 17:27 | <aho> | but font-size-adjust sounds better than nothing |
| 17:37 | <TabAtkins> | Hm, width? font-size won't help you much at all there, since character are variable-width. |
| 17:38 | <Ms2ger> | TabAtkins, not in Lynx! |
| 17:39 | <TabAtkins> | Not in UA-styled <pre> either, but I didn't think I had to mention "unless you're using a fixed-width font". ^_^ |
| 17:39 | <Ms2ger> | That'd be logic |
| 17:39 | <rgervais> | quick question guys, I have an error msg I want displayed on a page that says 'Please select another video' just plain text with a red background |
| 17:39 | <rgervais> | what tag should I wrap around with? |
| 17:40 | <rgervais> | p, span, div.. i'm not sure |
| 17:40 | <rgervais> | I can do all the same with those tags, I just want to know the proper one |
| 17:40 | <TabAtkins> | It's a paragraph of text, right? So... |
| 17:40 | <rgervais> | it's just text that says 'Please select another video' an error message |
| 17:41 | <TabAtkins> | So use <p>. Or <div>. Either is fine. |
| 17:41 | <rgervais> | it's one sentence |
| 17:41 | <Ms2ger> | Sounds like a p |
| 17:41 | <rgervais> | ok thanks |
| 17:42 | <TabAtkins> | The rule is: don't overthink your semantics. Everything's really quite easy. |
| 17:42 | <Ms2ger> | ... to #whatwg regulars |
| 17:43 | <rgervais> | yea, I mean all will do the job I just want to use 'proper' semantics :) |
| 17:43 | <rgervais> | but cool I'll try not to overthink |
| 17:43 | <TabAtkins> | Nah, it's easy to everyone. Most people just overthink it. ^_^ |
| 17:43 | <aho> | TabAtkins, it's the name of the site... it won't change |
| 17:43 | <TabAtkins> | When you're splitting hairs between <p> and <div>, you're trying too hard. |
| 17:44 | <aho> | with font A i'd like to use 97px and with font B i'd rather use 84px (otherwise it wraps) |
| 17:45 | <TabAtkins> | Oh, so you specifically want to prevent wrapping. Ok. |
| 17:45 | <aho> | at a line height of 100px i'd like to prevent wrapping indeed :> |
| 17:46 | TabAtkins | wants a text-justify-last mode that'll adjust font-size. |
| 17:47 | bfrohs | does too |
| 17:47 | <TabAtkins> | Excellent, I got my SXSW badge. Now I just have to hope that Housing can find me a room. |
| 17:50 | <TabAtkins> | I forget. Do background images print by default? |
| 17:50 | <TabAtkins> | I suppose I can test this... |
| 17:52 | <TabAtkins> | Answer: Apparently not. Darn, there went my idea. |
| 17:52 | <jwalden> | gsnedders: assuming webidl or whatever specifies that indexing [0], [1], etc. on NodeList works, the forEach thing should indeed be required by the relevant specs: forEach and all those algorithms are generic, and work on any object with a length property |
| 17:53 | <gsnedders> | jwalden: ES5 explicitly states that forEach has no guaranteed behaviour for host objects |
| 17:53 | <TabAtkins> | host objects are the devil. |
| 17:54 | <gsnedders> | jwalden: "Whether the forEach function can be applied successfully to a host object is implementation-dependent. |
| 17:54 | <jwalden> | gsnedders: well, sure, but that's not realistic that DOM objects are going to be fully-funky host objects |
| 17:54 | <jwalden> | they are going to behave roughly like normal objects |
| 17:54 | <jwalden> | and webidl will/does say that |
| 17:55 | <gsnedders> | jwalden: Does it? Where? |
| 17:55 | <jwalden> | gsnedders: if it doesn't, it should/will -- you can't possibly believe webidl would leave unspecified the behavior of elt.childNodes[i] |
| 17:56 | <gsnedders> | jwalden: It defines that, but by my reading of ES5 that's not enough to require it be possible to use with forEach |
| 17:56 | <jwalden> | spec wonk cagefight! |
| 17:57 | <jwalden> | eh, maybe |
| 17:57 | <jwalden> | real world will dictate otherwise |
| 17:57 | <gsnedders> | jwalden: Like, as far as I can tell, there's no guarantee any host object will work, even if [[Get]] and [[HasProperty]] are defined for it |
| 17:58 | <jwalden> | gsnedders: well, by this measure the entire DOM is unsound |
| 17:58 | <gsnedders> | jwalden: meh, I'd just rather specs required what works in the real world, as soon enough the real world will require stuff that isn't required in specs |
| 17:58 | <gsnedders> | jwalden: indeed |
| 17:58 | <jwalden> | why exactly ES5 specifically calls this out I don't know, rather than just letting the algorithm stand |
| 17:59 | <gsnedders> | (and then you're back to reverse-engineering what works in the competition…) |
| 17:59 | <gsnedders> | jwalden: Because ES5 calls out that host objects can do anything, so informatively notes everywhere that x isn't guaranteed to work with host objects |
| 18:00 | <jwalden> | well, yes |
| 18:00 | <jwalden> | but you could imply that by all the [[Get]]s and [[Call]]s already |
| 18:00 | <jwalden> | so it's redundant |
| 18:01 | <gsnedders> | But then there's an ambiguity as to whether the behaviour of forEach with a host object first argument must follow that algorithm, because the host object doesn't have to follow the normal rules for objects, no? |
| 18:02 | gsnedders | isn't a particular fan of the host object exemption from almost everything |
| 18:02 | <gsnedders> | Like I'd much rather there were a few specific places where host objects were allowed to do anything. |
| 18:03 | <jwalden> | how is there ambiguity about whether it should follow the algorithm, absent that implementation-defined statement? |
| 18:04 | <gsnedders> | jwalden: Hmm, yeah, I guess there isn't (I misremembered what one of the general host object exemptions said) |
| 18:05 | <gsnedders> | I guess MS may have previously (to IE9) wanted host objects to be free to act differently in a lot of places due to their DOM impl in IE<9 |
| 18:05 | <gsnedders> | Apart from that I can't think of any pressure from browser vendors to keep it undefined |
| 18:16 | <aho> | TabAtkins, now that i think about it... a viewbox'd svg would work fine for this |
| 18:24 | <aho> | on a third thought... bad idea since text isn't an element which establishes a viewport :l |
| 18:43 | <rgervais> | ok I got another question, what tag should i use for a refresh button "it'll become an icon using CSS"? A span, a tag, or button tag or something else? |
| 18:43 | <TabAtkins> | If it's a refresh button, use a <button>. Easy. ^_^ |
| 18:44 | <TabAtkins> | You can style <button>s to remove all the default appearance. |
| 18:44 | <rgervais> | why not a <a> tag? |
| 18:44 | <rgervais> | example: <a class="refresh_btn"></a> |
| 18:45 | <TabAtkins> | That's acceptable too, sure, as long as it doesn't have any side-effects (you shouldn't ever submit a form using <a> and js, for example). |
| 18:46 | <TabAtkins> | I'll point back to my previous advice: don't overthink it. |
| 18:46 | <rgervais> | I'm not submitting though, I'm refreshing |
| 18:46 | <rgervais> | I know, I just curios as to why not use something versus using it |
| 18:46 | <TabAtkins> | If it would be acceptable for a spider to follow the link, then <a> is fine. So is <button>. |
| 18:47 | <rgervais> | alright that's helpful |
| 18:48 | <TabAtkins> | Jeezus, I *really* hate whoever release a new botting tool for Twitter over the weekend. |
| 20:23 | Philip` | wishes he didn't have to read the whole Working Group Decision messages to figure out what the decisions were |
| 20:23 | <Philip`> | (Summary for this case: The "Common idioms" section won't be removed) |
| 20:25 | <Ms2ger> | You're pretty lucky if you figured it out after reading it once |
| 20:29 | <aho> | <html lang="en-US-x-hixie" ...> |
| 20:29 | <aho> | :> |
| 20:55 | <AryehGregor> | Wow, the way text-decoration is defined in CSS is horrible. How are you supposed to programmatically determine whether a given stretch of text is underlined? |
| 20:55 | <AryehGregor> | Granted, inheriting it is also bad. |
| 20:55 | <TabAtkins> | It's defined very specially so that underlines don't move or change color just because the font/color properties on descendants are different. |
| 20:55 | <AryehGregor> | Which is why <u>Foo <span style=color:red>bar</span> baz</u> looks really weird . . . |
| 20:55 | <AryehGregor> | But anyway. |
| 20:55 | <AryehGregor> | Now I have to define queryCommandState("underline"). |
| 20:56 | <othermaciej> | the CSS underline model also sucks really bad for editing |
| 20:56 | <AryehGregor> | Yes, that's my current problem. |
| 20:57 | <othermaciej> | imagine hitting Cmd+U while selecting a fragment in the middle of an underlined ancestor |
| 20:57 | <othermaciej> | WebKit handles this, but it's really complicated |
| 20:57 | <othermaciej> | much more so than bold or italic |
| 20:57 | <AryehGregor> | It would have been better to make it inherited, but have the color be determined by the color of the character it's under, and the thickness determined by averaging per-line or whatever as currently suggested. |
| 20:57 | <AryehGregor> | Yes, that's exactly what I'm trying to spec right now. |
| 20:57 | <othermaciej> | it also sucks that distinc text-decorations are not orthogonal |
| 20:59 | <othermaciej> | so you actually need multiple elements if you want a span of text to have both strikethrough and underline |
| 20:59 | <AryehGregor> | I notice WebKit just refuses to even try removing the underlining in at least some cases. |
| 20:59 | <AryehGregor> | Hmm, or maybe that's only when it's on a non-contenteditable ancestor. |
| 20:59 | <AryehGregor> | In that case you have to give up, I guess. |
| 20:59 | <AryehGregor> | It seems like WebKit propagates underlines to floated and absolutely positioned descendants. |
| 21:00 | <AryehGregor> | othermaciej, data:text/html,<!doctype html><span style="text-decoration:underline overline">foo</span>? |
| 21:00 | <AryehGregor> | Argh. |
| 21:01 | <othermaciej> | AryehGregor: yeah, if you are underlined by a non-editable ancestor, there's nothing you can do |
| 21:01 | <AryehGregor> | othermaciej, in case you didn't get it: data:text/html,<!doctype html><span style="text-decoration:underline overline">foo</span>? |
| 21:01 | <othermaciej> | AryehGregor: oh, I didn't know that worked |
| 21:01 | <AryehGregor> | Seems to. |
| 21:03 | <AryehGregor> | In theory you could handle the case where an ancestor has a non-inline style that underlines it, by setting an inline style to override it. |
| 21:03 | <AryehGregor> | Argh. |
| 21:03 | <AryehGregor> | Are there any IRC clients that don't spam the chat endlessly on netsplits? |
| 21:04 | <TabAtkins> | I just have irssi ignore all joins/quits. |
| 21:04 | <AryehGregor> | That might be an improvement, I guess. |
| 21:04 | bfrohs | wrote a custom theme in empathy to hide all but the 3 most recent ones |
| 21:05 | <AryehGregor> | I'd really prefer if they were available somehow, just didn't spam up the chat. |
| 21:05 | <TabAtkins> | You can, with a bit more effort, have irssi redirect the ignored stuff to a different channel, though I don't think that addresses what you want. |
| 21:05 | <AryehGregor> | Like if there were an indicator of some sort you could expand to make all the parts/joins at that position visible, that had no or almost no height. |
| 21:05 | <AryehGregor> | In general, IRC client UI is terrible. |
| 21:05 | <TabAtkins> | Agreed. |
| 21:06 | <rgervais> | IRC is meant for geeks |
| 21:06 | <rgervais> | not for regular folk |
| 21:06 | <AryehGregor> | Geeks appreciate good UI too. |
| 21:07 | <Philip`> | True geeks write their own IRC clients |
| 21:07 | <rgervais> | true but... |
| 21:07 | <TabAtkins> | Hm, what would I actually need to get access to IRC messages? Then I could just write a front-end that polled the server every second or so for new messages. |
| 21:09 | AryehGregor | notices that un-underlining part of the text in <p style="color: red; text-decoration: underline"><span style="color: blue">Some text</span></p> changes the underline color in the parts you didn't select |
| 21:09 | <AryehGregor> | (in WebKit) |
| 21:11 | <AryehGregor> | Firefox just doesn't do anything in that case. |
| 21:12 | <AryehGregor> | Opera doesn't even notice the underline from the ancestor, it just adds a new blue underline on top of it, and queryCommandState("underline") returns false. |
| 21:15 | <AryehGregor> | IE 9 RC reports queryCommandState("underline") as false, but does nothing when you try to underline. |
| 21:15 | <AryehGregor> | Firefox at least reports queryCommandState("underline") correctly. |
| 21:17 | <AryehGregor> | Okay, what I'm going to do is propose that CSS 3 Text include a new value text-decoration-underline: suppress that causes no underline to be drawn even if some ancestor has an underline. |
| 21:17 | <AryehGregor> | Because the status quo is just insane. |
| 21:18 | <AryehGregor> | Does anyone know if this has been proposed before? |
| 21:20 | <TabAtkins> | Don't recall it since I've joined the group. |
| 21:20 | <TabAtkins> | Though, wouldn't you want to suppress strike-through too, and related decorations? |
| 21:21 | Philip` | wonders if editing necessarily has to operate directly on the HTML+CSS markup, rather than converting to some internal editing-friendly format and then editing and then converting back |
| 21:21 | <AryehGregor> | That sounds much more complicated. |
| 21:21 | <AryehGregor> | In most cases, it will be rendered as HTML in the end, so for real WYSIWYG, you want the editing format to be HTML too. |
| 21:23 | <rramthun> | I have a question regarding the "required" attribute of inputs in HTML5: Is the behaviour for onclick events of the form submit button defined, i.e. what happens, if you click on the submit button of a form, which is missing "require"d information in one of its inputs? Should the onclick event get executed or not? |
| 21:23 | <TabAtkins> | Yes, 'click' fires. 'submit' does not (iirc). |
| 21:25 | <rramthun> | I wonder if this behaviour is specified somewhere. |
| 21:25 | <Ms2ger> | Yes |
| 21:26 | <TabAtkins> | Yes, the HTML spec. |
| 21:26 | <Ms2ger> | In general |
| 21:33 | <rramthun> | I wondered because jQuery functions which have been bound to "click" of a submit button don't get executed, but that seems to be jQuery specific. A test with plain alert() shows you are right. |
| 21:33 | <AryehGregor> | I think "submit" fires too. |
| 21:33 | AryehGregor | looks it up |
| 21:35 | <AryehGregor> | Is whatwg.org working? |
| 21:39 | <TabAtkins> | yes. |
| 21:50 | <AryehGregor> | Did my message just now about css3-text get through to www-style? It's not showing up in the archives. |
| 21:53 | <AryehGregor> | There we go: http://lists.w3.org/Archives/Public/www-style/2011Feb/0641.html |
| 21:54 | AryehGregor | really only wants it added to the spec, so he can reference it in his spec, even if no one implements it :) |
| 21:55 | <TabAtkins> | Yeah, it did. |
| 21:55 | <TabAtkins> | It sometimes takes several minutes for the archive to update. |
| 21:55 | <ako> | Chrome dev converts to <p><u>Hello </u>there<u>!</p> |
| 21:55 | <ako> | </u> missing |
| 22:04 | <AryehGregor> | I was looking at the DOM. |
| 22:04 | <AryehGregor> | How are you even testing on anything else? |
| 22:05 | <virtuelv> | somewhat related to this channel, http://my.opera.com/core/blog/show.dml/26453141 |
| 22:05 | <virtuelv> | AryehGregor: ? |
| 22:09 | <AryehGregor> | virtuelv, ? |
| 22:11 | <virtuelv> | AryehGregor: I was just wondering what your "How are you even ..." was in reference to |
| 22:11 | <virtuelv> | (and if it was to what I wrote, what you meant by it) |
| 22:13 | <TabAtkins> | virtuelv: If the ordering I see is canonical, his comment was before what you said anyway. I think it was in reference to ako, but I don't understand what it's referring to. |
| 22:14 | <ako> | there is a sparking new html5 parser in opera now, i guess he meant that it's worth to check its execCommand behavior |
| 22:16 | <TabAtkins> | s/sparking/spanking/ is the usual idiom. |
| 22:16 | <ako> | thought it was 30% wrong, but ignored it :> |
| 22:19 | <aho> | is there some eta for an @var build of chrome/chromium? :) |
| 22:20 | <aho> | or any kind of preprocessor thingy |
| 22:21 | <TabAtkins> | "Months" is the best I can offer. |
| 22:21 | <aho> | i think cssmin intends to support some kind of @var stuff, but i'm not sure which flavor it will be |
| 22:21 | <aho> | http://code.google.com/p/cssmin/wiki/ConfigurationEmulateCss3Variables |
| 22:21 | <aho> | oh it already does |
| 22:22 | <aho> | looks somewhat different from what i remember... mh |
| 22:23 | <TabAtkins> | That'll probably be sooner, but I still can't offer anything more specific. |
| 22:23 | <TabAtkins> | SASS will support the official @var syntax. |
| 22:23 | <aho> | ye, i think chriseppstein mentioned that |
| 22:29 | <TabAtkins> | aho: That's an older version of variables. It kinda sucks that the cssmin person went to the effort of implementing that, when it's being superseded. |
| 22:33 | <aho> | ye... well, it's enabled/disabled via options. he can add other kinds of variables/mixins/nesting if he likes (w/o breaking things, that is) |
| 22:34 | <aho> | is there some kind of documentation/specification for the new @var stuff? |
| 22:34 | <aho> | the only thing i know are those slides |
| 22:34 | <othermaciej> | are variables mutable at runtime |
| 22:34 | <aho> | yes |
| 22:34 | <TabAtkins> | aho: There's a thread on www-style (long) and a blogpost by me. |
| 22:34 | <TabAtkins> | othermaciej: Yeah. |
| 22:34 | <zewt> | variables tend to vary :) |
| 22:35 | <aho> | yes, but it was a valid question since the css "variables" were typically constants :> |
| 22:36 | <zewt> | sounds like it was a bit of a misnomer, then |
| 22:36 | <othermaciej> | I wondered why Bert Bos pedantically called them constants, then |
| 22:36 | <zewt> | (havn't followed that stuff) |
| 22:37 | <aho> | they are constants in all current implementations (all current ones are just preprocessors after all) |
| 22:37 | <TabAtkins> | othermaciej: You mean in his old blog post? I think the proposal he was responding to there was actually for constants. |
| 22:38 | <othermaciej> | did the hyatt/glazou proposal lack runtime mutability? |
| 22:38 | <aho> | the slides i mentioned earlier: http://www.xanthir.com/talks/2011-01-12/slides.html |
| 22:39 | <TabAtkins> | othermaciej: They only had mutability through direct CSSOM manipulation, which makes them as good as immutable in practice. |
| 22:39 | <TabAtkins> | (Since iterating through all the rules in a stylesheet and checking the type to find the vars is a horrible thing to make authors do.) |
| 22:41 | <TabAtkins> | aho: You'll note that on the first slide I now link to the blogpost. |
| 22:41 | <TabAtkins> | And I have a further blogpost diving into more detail about variables specifically. |
| 22:42 | <othermaciej> | TabAtkins: still seems wrong to refer to that as "constants" |
| 22:42 | <annevk> | http://lanyrd.com/2011/reboot12/ omg I am away |
| 22:42 | <othermaciej> | at least from the pod of excessive pedantry |
| 22:42 | <annevk> | have not missed a single one since 7 |
| 22:42 | <TabAtkins> | Well, it's arguable. If the semantic is that changing it via the CSSOM causes a reparse of the stylesheet, then it's still possible to justify calling them constants. |
| 22:43 | <aho> | ye |
| 22:44 | <Yuhong> | "Microsoft seems to have a stronger corporate agenda dictating the actions of its standards bodies representatives. Hickson [from Google] looks very independent" |
| 22:44 | <Yuhong> | http://news.cnet.com/8301-30685_3-20008935-264.html#ixzz1EBjhiiN4 |
| 22:45 | <aho> | microsoft always tries to put a spin on everything |
| 22:45 | <aho> | no one else does that :> |
| 22:46 | <aho> | http://en.wikipedia.org/wiki/Spin_%28public_relations%29 |
| 22:46 | <aho> | this kind of spin, that is :> |
| 22:47 | <aho> | (and then they act surprised if the nerds get angry) :D |
| 22:48 | <Yuhong> | I know that MS is the least PR 2.0 compliant browser vendor for a while now. |
| 22:57 | <zewt> | secure prng for floats keeps coming up, but ... does crypto ever actually need it? heh |
| 22:57 | <zewt> | given how much harder it is to define floating-point properly, i'd expect crypto to always stick with ints/fixed-point |
| 22:58 | <zewt> | (as it does in all crypto I've ever seen) |
| 22:59 | <aho> | well, you can always just refer to other specs (e.g. ieee 754) |
| 22:59 | <zewt> | well I mean, defining and validating algorithms in general on floating-point |
| 22:59 | <annevk> | Yuhong, that's from June 2010! |
| 23:00 | <gsnedders> | zewt: ES has well-defined floating-point behaviour |
| 23:00 | <gsnedders> | (the fact that basically all implementations on x86 (but not x86_64) disregard that is another issue) |
| 23:00 | <Yuhong> | Yes, but I am quoting a specific comment. |
| 23:01 | <zewt> | floating-point operations themselves are well-defined, but does any (real-world) crypto actually depend on that? |
| 23:02 | <zewt> | just seems like the whole "float PRNG" sub-discussion might be irrelevant, that's all |
| 23:03 | gsnedders | has stayed out of that thread because he has no idea about any of this |
| 23:03 | <zewt> | for example, > It seems pretty simple to generate a random number from 1 to 2 by fixing the exponent and mixing in 52 bits of random mantissa. Subtract 1 to get an evenly distributed value from 0-1. |
| 23:04 | <zewt> | that ... might be true, but without a more detailed understanding of the narrow details of floating-point math than most people have, it's not clearly so |
| 23:11 | <Yuhong> | BTW, if you are wondering why Netscape 4 had poor CSS support, the code used by Netscape 4 to convert CSS to JSSS is available here: |
| 23:11 | <Yuhong> | csstojs.c |
| 23:12 | <Yuhong> | http://mxr.mozilla.org/classic/source/lib/libstyle/csstojs.c |
| 23:12 | <TabAtkins> | Son of a... I just accidentally killed an hour of writing work by abusing back/forward. >_< |
| 23:15 | <Yuhong> | For those who don't know the history, Netscape began developing version 4 in early 1996. |
| 23:16 | <gsnedders> | And IE3's CSS support was what? :P |
| 23:16 | <Yuhong> | As part of this, Netscape developed a style sheet language based on JSSS and submitted it to the W3C. |
| 23:17 | <Yuhong> | Unfortunately, it got rejected by the HTML ERB in favor of CSS. |
| 23:17 | <TabAtkins> | "Un"? |
| 23:17 | <Yuhong> | Netscape ended up have to create a CSS to JSSS translator, leading to poor CSS support. |
| 23:18 | <Yuhong> | What I want to mention is that the source code for it is available as part of the Mozilla classic source. |
| 23:18 | <TabAtkins> | Okay, it's just the implication (that it was unfortunate that we settled on CSS) that I found odd. |
| 23:18 | <Yuhong> | Unfortunately for Netscape, I mean. |
| 23:19 | <TabAtkins> | Ah yeah, that makes sense. |
| 23:19 | <Yuhong> | As part of this, Netscape developed a style sheet language based on JavaScript called JSSS and submitted it to the W3C. |
| 23:19 | <annevk> | x |
| 23:19 | <annevk> | ms2ger left? |
| 23:20 | <annevk> | wat is it with his short IRC time windows |
| 23:20 | <annevk> | almost like he has something better to do |
| 23:21 | <TabAtkins> | Yay, all my work was still sitting in a less buffer from my last cvs diff! Woo! |
| 23:21 | <zewt> | heh |
| 23:21 | <zewt> | the search-for-remnants-of-lost-data quest |
| 23:22 | <TabAtkins> | (I realized upon diffing that I had done too much work between commits, and lost my work while trying to backtrack so I could push more reasonable commits. |
| 23:23 | <TabAtkins> | Also, yay, my use of Google Reader as a poor-man's cron is working great! |
| 23:26 | <annevk> | Ms2ger, when you read this, I was going to ask you about publishing DOM Core |
| 23:26 | <annevk> | Ms2ger, I am almost sure you are ok with it though, so I am going to ask Art to get things moving tomorrow |
| 23:27 | <AryehGregor> | virtuelv, I was talking to ako. I wanted to know how he could tell the difference between closed and unclosed tags with execCommand(), since that operates on the DOM level, where there's no such thing as an unclosed tag. |
| 23:27 | <AryehGregor> | There can only be unclosed tags in markup. |
| 23:29 | <TabAtkins> | AryehGregor: I think ako was talking about your email, where you omitted a closing </u>. |
| 23:31 | <AryehGregor> | Oh. |
| 23:31 | <Yuhong> | IE is a different mess altogether, BTW. |