| 00:27 | <Yuhong> | /msg NickServ identify asdasd |
| 00:27 | <odinho> | ouch |
| 00:27 | <Yuhong> | Already changed password. |
| 00:27 | <Yuhong> | /msg NickServ identify asdfasdf |
| 00:27 | <odinho> | ^_^ |
| 00:27 | <Yuhong> | Changing password again |
| 00:28 | <odinho> | asdfasdfa maybe now? |
| 00:28 | <TabAtkins> | Yuhong: Those are the worst passwords ever. |
| 00:28 | <Yuhong> | I know. |
| 00:28 | <Yuhong> | Back on topic. |
| 00:28 | <TabAtkins> | We have no topic. |
| 00:28 | <TabAtkins> | Anyway, you should use a password like mine: "hunter2" |
| 00:28 | <odinho> | Think of all the scary hackers who want to identify as you on freenode! :O Oh noes the drama. |
| 00:29 | <odinho> | TabAtkins: Oooh, minus one from hunter3, sneaky. Noone will ever try that one. |
| 00:29 | <Yuhong> | AFAIK, Gecko 1.9.2 eventually disabled the HTML5 parser completely. |
| 00:29 | <odinho> | TabAtkins: Hmm. But you were actually right. Always remembered it as 3, but it's 2... |
| 00:29 | <Hixie> | damnit tab, how do you always use the same password as me! |
| 00:30 | odinho | changes his password in light of the recent discovery |
| 00:30 | <Yuhong> | And actually Mozilla's SGML comment parsing dates before Acid2. |
| 00:31 | <Hixie> | yeah, but it doesn't predate my convincing them to do it :-( |
| 00:32 | <Yuhong> | And to be honest on IE7 and the BASE element, the Acid2 requiring SGML comment parsing wasn't that long ago. |
| 00:38 | <Yuhong> | I read that Arjun Ray was talking about it even in 1995 or so. |
| 01:08 | <Yuhong> | "it" referring to SGML comment parsing. |
| 01:55 | <zewt> | dear google: stop fuzzing "disassembly" to "repair" |
| 04:32 | <MikeSmith> | the time element introduced changes to the parsing algorithm? |
| 04:32 | MikeSmith | checks |
| 04:34 | <MikeSmith> | no |
| 05:11 | <Guest19025> | fyi, http://en.wikipedia.org/wiki/Microdata_%28HTML%29 was saying @itemref contained itemids. I fixed that. But it might be worth someone knowledgable checking the rest of the page. |
| 05:17 | Guest19025 | now tries to find a schema for user curated lists of itemids. Eg, Bob defines new item (itemid L9), which is a list of itemids, defined as his Item0, plus all iids in Alice's list L1, and Jim's L2, except for ItemBlech. |
| 08:22 | <rniwa> | annevk: is setAttribute supposed to be case insensitive when looking for an attribute? |
| 08:22 | <annevk> | rniwa: in HTML, yes |
| 08:22 | <annevk> | rniwa: http://dom.spec.whatwg.org/#dom-element-setattribute |
| 08:23 | <rniwa> | annevk: ah, now I see that we're lower-casing the name. |
| 08:23 | <rniwa> | annevk: but don't we want to preserve the case for non-HTML elements in a HTML document? |
| 08:23 | <annevk> | yes |
| 08:24 | <annevk> | that's why it checks the namespace of the context object |
| 08:24 | <rniwa> | ah i see. |
| 08:24 | <rniwa> | so we do this only in a html document for a html element. |
| 08:24 | <rniwa> | annevk: thanks :) |
| 08:24 | <annevk> | np |
| 09:41 | <gnarf> | So, I'm wondering if there are any proposals/discussions out there for a CSS query on selectors... I.E, i'm developing a widget, and I want to do something like @query( max-width: 12em ) > .my-widget { } where the @query would match agains .my-widget's container |
| 09:52 | <SimonSapin> | gnarf: there was some requests for this on www-style but I don’t see it happening: CSS a pretty strong "layering": selector matching happens well before layout |
| 09:52 | <SimonSapin> | and something like "the container is at most 12em" is very much layout |
| 09:53 | <SimonSapin> | which itself depends a lot on selector matching of course |
| 09:54 | <SimonSapin> | gnarf: but if you has a specific use case in mind, do send it to www-style, there might be another way to solve it |
| 09:55 | <SimonSapin> | but be sure to include why you want this and how you would use it |
| 10:09 | <gnarf> | SimonSapin: i was just inspired by toodmparker's talk on responsive and problems they faced with jquery-mobile |
| 10:10 | <gnarf> | because they don't know for instance if you are using a left sidebar, so media query is kinda impossible for a "library" to be using |
| 10:10 | <gnarf> | because its not at all about screen width, its about container width |
| 10:11 | <gnarf> | was just trying to come up with solutions and dig around in the Working Group drafts |
| 10:11 | <gnarf> | maybe constraint style stuff would improve this |
| 10:11 | <gnarf> | but |
| 10:11 | <gnarf> | hard to say |
| 10:12 | <gnarf> | SimonSapin: I'll write up more info about it and send to www-style |
| 10:13 | <SimonSapin> | gnarf: cool |
| 13:55 | <GPHemsley> | Two somewhat mutually exclusive questions: |
| 13:56 | <GPHemsley> | Would it be useful to spec that an 'Accept' header should list all supported image(/audio/video) formats except the common ones? |
| 13:56 | <GPHemsley> | (where common = listed in spec) |
| 13:57 | <GPHemsley> | Would it be useful to define a new 'Accept-Images'(/Audio/Video) header to do a similar job? |
| 14:09 | <wilhelm> | History shows that both clients and servers use headers all wrong. I'm not sure any of those headers will make any positive difference. |
| 14:12 | <wilhelm> | I've used the accept header once. To, thanks to some dogmatic ideal, serve XHTML instead of HTML to UAs that understand XML. That was a waste of time. And the header is mostly a waste of bytes. |
| 14:15 | <GPHemsley> | wilhelm: But why was it a waste of time? Because serving XHTML over HTML proved not to be important? |
| 14:15 | <GPHemsley> | (over = instead of) |
| 14:16 | <wilhelm> | It didn't solve any problems for anyone. It _created_ problems for my users when I screwed up instead. |
| 14:16 | <wilhelm> | And I did screw up. Repeately. |
| 14:19 | <GPHemsley> | But again, the source of these problems was what? The header? or XHTML? |
| 14:20 | <wilhelm> | I messed up the markup somehow, somewhere, and the draconic error handling kicked in on page load. |
| 14:21 | <wilhelm> | But my point is that this entire exercise was futile. It had no use. |
| 14:23 | <GPHemsley> | But the point here is that XHTML was the source of your problems, not the header. |
| 14:24 | <wilhelm> | That - and the unneccessay content negotiation. I've never used those headers anywhere, for anything. |
| 14:24 | <GPHemsley> | Yes, because they do not currently carry any useful information. |
| 14:25 | <wilhelm> | Well, except when I built browsers instead of web sites. Then I learned that the headers sent by servers cannot be trusted, and you have to guess instead. |
| 14:39 | <GPHemsley> | Anyone need XBM support? No? Good. |
| 14:47 | <Samuel_Roldan> | hi all, are there any articles on how to style web components? more precisely, (and if possible) styling the element itself not using classes or inline styles. |
| 14:50 | <Garbee> | Samuel_Roldan, Questions like that are probably best asked in a room like #web. |
| 14:50 | <Samuel_Roldan> | Garbee. Understood. Thank you for clearing that up. |
| 14:51 | <Garbee> | I'm just not sure if general help like that is done in this channel. |
| 14:51 | <Samuel_Roldan> | Right. I wasn't sure myself. Figured, web components is fairly new so there would be more info here. |
| 14:55 | <annevk> | Anything goes in this channel. Styling the host element is still under discussing I believe. |
| 15:58 | <Philip`> | GPHemsley: The source of the wilhelm's problem was serving different content to different users, which means there's much more chance to get things wrong and much less chance of noticing |
| 16:00 | <Philip`> | You'd get the same difficulties if you're trying to use request headers to choose between serving HTML vs XHTML, PNG vs SVG, WebM vs H264, or whatever |
| 16:23 | <gsnedders> | And in the case of XHTML vs HTML, you cannot be using any feature of XHTML that HTML does not have (i.e., namespaces) because you must keep an HTML compatible copy. |
| 16:45 | <GPHemsley> | Philip`: But XHTML vs. HTML is not the same as the other issues, because it involves serving the same document as two different things. |
| 16:45 | <GPHemsley> | Philip`: And the PNG vs. SVG issue is one which is already old/grandfathered/common/etc. |
| 16:46 | <GPHemsley> | Philip`: The question is more geared towards preventing the PNG vs. SVG issue from being repeated in the future. |
| 16:46 | <GPHemsley> | (I'm not sure what the status of WebM vs. H.264 is) |
| 19:37 | <SimonSapin> | TabAtkins: {} and ; should end all at-rules. Consider: data:text/html,<style>@media;body{background:green data:text/html,<style>@import{}body{background:green |
| 20:31 | <Ms2ger> | Ah, Sweden |
| 20:31 | <Ms2ger> | http://imgur.com/iXrEYOd |
| 20:48 | <GPHemsley> | free aspirin? |
| 22:46 | <wilhelm> | GPHemsley: Actually, in the PNG-vs-SVG case, I've used a client-side script to replace the images in older browsers. That was less complex than header-based content negotiation. |
| 22:46 | <wilhelm> | Not very pretty, but it got the job done quickly. |
| 23:23 | <zewt> | more generally, things tend towards complexity in the client and having servers be as stupid and generic as possible; i imagine if file format negotiation was being designed today, it would be more like srcset |