| 00:02 | <Hixie> | oh, right |
| 00:03 | <Hixie> | looks ok. so I can just reference the intrinsic dimensions, reference CSS Image, and be done right? as far as sizing goes? |
| 00:03 | <Hixie> | s/just reference/just say to use/ |
| 00:03 | <TabAtkins> | And mention that the default object size is the canvas dimensions. |
| 00:03 | <Hixie> | k |
| 00:03 | <TabAtkins> | Those are the only two inputs, so you should be good otherwise. |
| 00:03 | <Hixie> | sounds plausible |
| 00:03 | <Hixie> | i'll let you know when i actually do it :-) |
| 00:03 | <TabAtkins> | k, no problem. |
| 00:04 | <TabAtkins> | Just working in that section now, so I wanted to bring it up while it was on my mind. |
| 00:07 | <Hixie> | TabAtkins: cool |
| 00:08 | <TabAtkins> | Augh, I'm gradually forgetting how to write. |
| 00:09 | <TabAtkins> | Hixie: Just let me know when you do add it, so I can make sure the terms are good. Input to the algo is intrinsic dimensions and default object size, output is a CSS View Box with definite dimensions, which SVG is then asked to draw into. |
| 00:09 | <Hixie> | by hand or at all? |
| 00:09 | <TabAtkins> | By hand. |
| 00:10 | <TabAtkins> | I can write fine on a whiteboard with markers, but pen-on-paper is gradually slipping away. |
| 00:10 | <Hixie> | TabAtkins: i added a link to this irc log in the bug, hopefully i'll see myself telling you that i'll try to remember to do so when i red this sentence |
| 00:10 | <TabAtkins> | Haha, kk. |
| 00:10 | <Hixie> | read, even |
| 00:12 | <TabAtkins> | Dammit, of course IE9 is the one person to implement the stupid algorithm. |
| 00:12 | <TabAtkins> | Which everyone else does sanely but wrong-by-spec. |
| 00:13 | <zewt> | "damn you, IE, stop following the specs" |
| 00:13 | <TabAtkins> | They should stop following stupid specs that I disagree with. ^_^ |
| 00:13 | <TabAtkins> | Namely, the sizing algorithm for images used in list-style-image, which is singularly different from how images are sized everywhere else in one specific detail. |
| 00:14 | <Hixie> | if there's no compat need and everyone else does it the same different sane way, i say change it |
| 00:15 | <TabAtkins> | Yeah, that's what I'm writing an email for right now. |
| 00:17 | <Hixie> | "Selectors doesn't define if the parent of an element that is :active or :hover is also in that state." |
| 00:18 | <Hixie> | isn't it about time we defined that |
| 00:18 | <TabAtkins> | Complain about it on the list. fantasai refuses to acknowledge that arbitrary elements are allowed to be :hover or :active. |
| 00:18 | <TabAtkins> | Or just define it, whatever. |
| 00:18 | <TabAtkins> | We both know the right definitions. |
| 00:19 | <Hixie> | i actually don't remember if the ancestor chain or the "z-index chain" (for lack of a better term) or neither or both is affected by :hover and :active |
| 00:20 | <TabAtkins> | What's a z-index chain? The list of elements underneath the pointer? |
| 00:20 | <Hixie> | yeah |
| 00:20 | <Hixie> | not sure what the right term is |
| 00:20 | <Hixie> | i know that ain't it |
| 00:20 | <aho> | browsers go with the ancestor chain... this allows you to do those menu thingies |
| 00:20 | <aho> | e.g. some horizontal menu which expands downwards |
| 00:20 | <TabAtkins> | Yup. The right answer is "ancestor chain". Everyone who would receive a mouseover event. |
| 00:21 | <Hixie> | k |
| 00:22 | <Hixie> | then y'all in the csswg should spec that :-P |
| 00:22 | <Hixie> | anyway on the other issue, i'm overriding selectors in the html spec |
| 00:22 | <Hixie> | and putting in a willful violation |
| 00:22 | <Hixie> | first one that refers to a spec whose editor list includes me :-P |
| 00:23 | <aho> | http://whatwg.pastebin.com/P7SNejxU <- css2 inherited properties :> |
| 00:23 | <TabAtkins> | data:text/html;charset=utf-8,%3C!DOCTYPE%20html%3E%0A%3Cdiv%20id%3Dfoo%3E%0A%20%20%3Cdiv%20id%3Dbar%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A%3Cstyle%3E%0A%23foo%3Ahover%20%7B%20background%3A%20blue%3B%20%7D%0A%23bar%3Ahover%20%7B%20background%3A%20green%3B%20%7D%0A%23bar%20%7B%0A%20%20position%3A%20absolute%3B%0A%20%20top%3A%2050px%3B%0A%20%20left%3A%2050px%3B%0A%7D%0Adiv%20%7B%0A%20%20width%3A%20100px%3B%0A%20%20height%3A%20100px%3B%0A%20%20bor |
| 00:23 | <aho> | i like how "no, see prose" basically means "yes" :> |
| 00:24 | <aho> | (text-shadow and text-decoration) |
| 00:24 | <Philip`> | TabAtkins: That looks truncated |
| 00:24 | <TabAtkins> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/833 |
| 00:27 | <TabAtkins> | aho: They're not inherited. They give the appearance of being so, though. You don't want to actually inherit, because then things would get drawn twice. |
| 00:28 | <aho> | sooo... they aren't inherited from an implementation standpoint, but from an author's standpoint? |
| 00:28 | <aho> | kinda confusing :> |
| 01:32 | <TabAtkins> | aho: Well, that's the way it has to work. You don't want "<p>foo <b>bar</b> baz</p><style>p,b{ text-shadow: 5px 5px rgba(255,0,0,.5); }</style> to draw two shadows on "bar". |
| 01:33 | <aho> | but with p{ text-shadow: 5px 5px rgba(255,0,0,.5); } the b would be also text-shadow'd :> |
| 01:35 | <aho> | ahm... well, color is inherited... but that doesn't mean that bar is rendered twice, right? |
| 01:35 | <TabAtkins> | text drawing is already defined to happen only once. |
| 01:36 | <aho> | and text-shadow isn't text rendering? |
| 01:36 | <TabAtkins> | It's easier to handle inheritance in the special way than try and re-solve the problem of "draw this only once" for shadows and decorations. |
| 01:37 | <aho> | but from a css author's point of view it is exactly like inherit isn't it? |
| 01:37 | <TabAtkins> | Sure. |
| 01:39 | <aho> | well, that makes things easier |
| 01:39 | <aho> | :> |
| 01:39 | <TabAtkins> | Just note that things like the 'inherit' keyword won't act like its inherited. |
| 01:39 | <TabAtkins> | Ooh, IE9 supports vh/vw/vm, and rem! Yay! |
| 01:40 | <TabAtkins> | Also ch! |
| 01:40 | <aho> | sooo... with that example above... b{text-shadow:inherit} wouldnt work? |
| 01:40 | TabAtkins | loves new units. |
| 01:40 | <TabAtkins> | aho: It would do something unexpected (create two shadows on "bar"). |
| 01:40 | <aho> | oh... :) |
| 02:17 | <deane> | MikeSmith: I only chatted to doublec for a few minutes. There was a guy sitting opposite him, don't know who he was |
| 02:23 | <deane> | MikeSmith: I missed roc yesterday as he had just left for the weekend. It was roc that I wanted to chat to. I met roc about three years ago, he told me Hixie was a genius (but I already knew that :) ). |
| 02:45 | <deane> | MikeSmith: I've been out of the openweb scene for a while, getting back involved now. Wanting to help you guys out. I have a few good ideas that I'll send in to the group. I have also recruited a friend of mine to the project. He's a security, JavaScript, network, php, and dom expert. I'm giving him a html5 101, starting with Simon's elements/content model site. He's a cool guy and I think he'll be a good help to all. We both need to read the spec |
| 02:45 | <deane> | though. I haven't read the spec for about 18 months, sorry :( So need to catch up with what's been going on. |
| 05:22 | <annevk> | hmm |
| 05:22 | <annevk> | WebKit and Opera support event.cancelBubble |
| 05:22 | <annevk> | and Gecko throws when accessing type of a newly created event |
| 05:23 | <annevk> | gonna assume that is a bug |
| 05:24 | <annevk> | Gecko and Opera support "events" as createEvent() argument... |
| 05:25 | <annevk> | eventPhase defaults to 0, 1, or 2 depending on where you look |
| 05:25 | <annevk> | (there's no constant for 0) |
| 05:26 | <zewt> | dom events and a puppy are about as much fun as a puppy |
| 05:26 | <annevk> | DOM3Events doesn't define any of this of course |
| 05:27 | <annevk> | not that my spec does not have bugs in this area, but I'm not done yet |
| 05:28 | <zewt> | if there was one annoying thing i could retroactively fix with dom events, it'd be the annoying AT_TARGET phase |
| 05:28 | <annevk> | go on... |
| 05:29 | <zewt> | specifically, the fact that you can't attach a capturing event listener onto an element, cancel the event from that handler, and have it prevent delivering the event to non-capturing handlers on the same event |
| 05:29 | <annevk> | well this is hilarious |
| 05:29 | <zewt> | (since it's already in AT_TARGET at that point, it's too late) |
| 05:29 | <zewt> | but ... many years too late to do anything about that. heh |
| 05:29 | <annevk> | once you do initEvent with the empty string event.type can be the empty string in Gecko |
| 05:30 | <annevk> | isn't that what stopPropagation() does? |
| 05:31 | <zewt> | as i recall my troubles with it, that only works if you do it while you're still in CAPTURING_PHASE |
| 05:31 | <zewt> | eg. if you're capturing from something higher up on the dom heirarchy |
| 05:31 | <annevk> | right |
| 05:32 | <annevk> | if you want to prevent it from reaching event listeners on the same current target you use stopImmediatePropagation |
| 05:32 | <zewt> | don't recall that method--will need to look it up |
| 05:32 | <zewt> | is that events level 3? |
| 05:32 | <annevk> | yeah |
| 05:33 | <zewt> | that's probably why i havn't heard of it, then |
| 05:33 | <zewt> | nice to know there's a way to deal with that coming down the pipeline eventually |
| 05:33 | <annevk> | i haven't actually checked whether it's implemented yet, but I've defined it and I'm guessing it works already |
| 05:34 | <zewt> | as far as the tech field goes, dealing with web standards must be very near the top in terms of things requiring patience, heh |
| 05:34 | <annevk> | so WebKit throws a NOT_SUPPORTED_ERR for initEvent with the empty string |
| 05:34 | <zewt> | "alright, that's defined, we'll be able to use it in 3-5 years" |
| 05:36 | <annevk> | hmm indeed |
| 05:36 | <annevk> | only WebKit seems to have stopImmediatePropagation |
| 05:36 | <annevk> | lame |
| 05:37 | <annevk> | meanwhile Opera throws on document.createEvent("event") |
| 05:37 | <annevk> | case-sensitive! |
| 05:37 | <annevk> | hah, but not case-sensitive for "htmlevents" |
| 05:37 | <zewt> | i also don't envy you or anyone else dealing with specs for dom events, heh |
| 05:38 | <zewt> | or any API with its, uhh ... colorful history |
| 05:38 | <annevk> | i've done a couple now |
| 05:38 | <annevk> | it has its moments |
| 05:39 | <annevk> | and as long as I don't work on it days on end it's quite enjoyable |
| 05:39 | <zewt> | moments of sudden, painful hair loss |
| 05:39 | <annevk> | heh |
| 05:41 | <annevk> | whoa |
| 05:41 | <annevk> | empty string totally works in Gecko |
| 05:41 | <zewt> | heh |
| 05:41 | <annevk> | you can even register event handlers for it |
| 05:41 | <zewt> | reminds me of when, in an old linux kernel, i found i was able to map memory onto NULL, and make NULL a valid pointer |
| 05:41 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/834 |
| 05:41 | <annevk> | that's wild |
| 05:42 | <annevk> | very silly that they throw for it before invoking initEvent then |
| 05:42 | <annevk> | otherwise you could just skip initEvent and go straight to finish |
| 09:47 | <hasta84> | Hey everyone... |
| 09:47 | <hasta84> | Anyone here interested in p2p / device specs? |
| 16:52 | <deane> | Anyone know of a webpage (or whatever) that details why we can't have any elements within <p> ? I just want to understand why we can't allow elements within <p>, that's all. Sorry, I'm sure this has been discussed many times :/ Any pointers? :) |
| 16:54 | <erlehmann> | deane, <p> allows phrasing content. what is your problem with that? |
| 16:55 | <erlehmann> | deane, read <http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#phrasing-content>; |
| 19:24 | <deane> | erlehmann: sweet, thanks man, thanks for the link, I'll check that out. I was actually thinking of stuff like: <p><table>, plus, I misread an article about it :\ Never mind :) |
| 19:27 | <deane> | erlehmann: I was thinking of block, sorry |
| 19:28 | <Philip`> | If a site says |
| 19:28 | <Philip`> | <meta charset="UTF-8"> <meta http-equiv="Content-type" content="text/html;charset=UTF-8" /> |
| 19:28 | <Philip`> | should it be invalid? |
| 19:29 | <Philip`> | Hrm... The spec says "There can only be one character encoding declaration in the document." |
| 19:30 | <Philip`> | but the normative requirement is just "There must not be more than one meta element with a charset attribute per document." |
| 19:30 | <erlehmann> | deane, putting block content into <p> *will* come back at you as soon as you try styling the mess. |
| 19:30 | <Philip`> | and it looks like that document would have two encoding declarations without violating that |
| 19:30 | Philip` | wonders if he's missing anything |
| 19:31 | <erlehmann> | Philip`, since both are synonyms, this must surely be wrong! |
| 19:31 | <zewt> | it's normal enough to specify the same thing in different ways for compatibility, so long as they don't have different values, though |
| 19:32 | <zewt> | similarly, having both a content-type http-equiv and a real Content-Type HTTP header |
| 19:32 | <Philip`> | "If the document contains a meta element with an http-equiv attribute in the Encoding declaration state, then the document must not contain a meta element with the charset attribute present." |
| 19:33 | <Philip`> | Ah, that's what I was missing |
| 19:33 | <erlehmann> | :3 |
| 19:34 | <deane> | thanks for all your hard work, guys :) you're doing well |
| 19:36 | <Philip`> | http://bugzilla.validator.nu/show_bug.cgi?id=589 - ah, and that's the validator bug I encountered |
| 22:26 | <Smylers> | Philip`: I was surprised when that bug e-mailed me. |
| 22:27 | <Smylers> | I have no recollection of raising it, and even when I read you mentioning the issue on IRC earlier I didn't remember encountering it before. |