| 00:36 | <weinig> | Hixie: I think you can just copy the model from CustomEvent |
| 00:36 | <weinig> | Hixie: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-customevent |
| 00:36 | <Hixie> | yeah i started doing that |
| 00:36 | <weinig> | Hixie: give the interface a constructor |
| 00:36 | <weinig> | [Constructor(DOMString type, optional CustomEventInit eventInitDict)] |
| 00:37 | <weinig> | ok, which one are you speccing? |
| 00:37 | <Hixie> | all the ones in the whatwg spec |
| 00:37 | <Hixie> | moving them from init*Event to the constructor model |
| 00:37 | <weinig> | excellent |
| 00:39 | <Hixie> | yeah i've been putting off doing it for a while |
| 00:40 | <weinig> | has been putting off landing the implementation for a while :\ |
| 00:40 | <weinig> | I finally got Event and CustomEvent into nighties of WebKit though \o/ |
| 00:41 | <Hixie> | cool |
| 00:41 | <weinig> | now there is no going back :) |
| 00:42 | <Hixie> | yeah the new model is so much better |
| 00:42 | weinig | nods |
| 01:52 | <Hixie> | is "Foo[]?" valid WebIDL syntax? |
| 01:53 | <Hixie> | for a nullable array type? |
| 05:47 | <Hixie> | hmm, that's annoying |
| 05:48 | <Hixie> | position:relative affects all position:absolute descendants |
| 05:49 | <Hixie> | so you can't have a descendant that uses one containing block while the other uses another |
| 05:50 | <Hixie> | e.g. the "IDL" :before labels for class=idl blocks and the .status boxes in those same blocks |
| 05:50 | <Hixie> | grr |
| 05:52 | <dbaron> | Yeah, the 'position' property was pretty much all wrong... |
| 05:55 | <Hixie> | is calc() implemented by anyone yet? i've worked around this by changing the way the positioning works for the IDL boxes, but now I have to have the margin-top be -0.625em-1px |
| 05:56 | <Hixie> | (actually even better would be -(0.5em*1rem/small + thin) where small is the font-size keyword and thin is the border-width keyword) |
| 06:27 | <dbaron> | Hixie, calc() is implemented, with prefixes, by IE and Gecko |
| 06:27 | <dbaron> | Hixie, actually, not sure if IE used prefixes... |
| 06:28 | <Hixie> | prefixes are too much of a pain to use for me to consider them implemented |
| 06:28 | <Hixie> | why are we still prefixing it, anyway? |
| 06:28 | <Hixie> | wasn't that specced like half a decade ago? |
| 06:28 | <Hixie> | (for me to consider them implemented enough to use, i mean) |
| 06:29 | <dbaron> | hopefully we'll get that draft to CR sometime early next year... |
| 06:30 | <Hixie> | it strikes me that the csswg might be the group that would benefit the most from dropping the whole TR process |
| 06:31 | <dbaron> | we'd still need to make coherent decisions about when to drop prefixes |
| 06:32 | <dbaron> | anyway, 'night |
| 10:42 | <annevk> | Hixie, so lazy |
| 10:42 | <annevk> | (re automatic event constructors) |
| 10:58 | <zcorpan> | AryehGregor: both |
| 11:18 | <annevk> | "must be implementation-, device-, and platform-specific" |
| 11:18 | <annevk> | the more I read DOM Level 3 Events, the more confused I get |
| 12:04 | <bga_> | can anybody give me copy of Dash spec? I havn't @google.com mail :( |
| 12:52 | <Woodkid> | hello guys |
| 13:19 | <zcorpan> | Hixie: btw you're probably better off reimplementing the IDL labels since they are positioned differently in all browsers (i only tested opera when i wrote it so check opera for how i intended it to look) |
| 16:33 | <jarek> | Hi |
| 16:34 | <jarek> | why window.localStorage.setItem is converting everything to string? |
| 16:35 | <jarek> | should I be using JSON.stringify and JSON.parse when passing and retriving data from local storage? |
| 16:39 | <bga_> | yes |
| 20:08 | <erlehmann> | hsivonen, you once wrote an article on PNG gamma correction vs. CSS colors. is there an easier quick-n-dirty-way to make background / seam colors in PNG match with CSS than using transparency? |
| 21:37 | <shetech> | Hey, all. So I have a "I might have been hallucinating" question for the room at large. |
| 21:38 | <shetech> | Didn't I at one point see a layout tool for columns, not to be confused with table columns, but newspaper-type column layout? |
| 21:38 | <shetech> | Or am I high? |
| 21:38 | <shetech> | some element tag that I now can't find |
| 22:22 | <shetech> | found it. CSS, not HTML5. |
| 22:23 | <zewt> | heh, that's among the worst possible webpage layouts |
| 22:23 | <zewt> | pages that make you scroll down and up and down and up |
| 22:23 | <shetech> | zewt: tell me more |
| 22:23 | <shetech> | ah |
| 22:23 | <shetech> | that assumes your content is that lengthy |
| 22:24 | <zewt> | magazines are laid out the way they are to deal with the paper medium; a webpage is completely different and that doesn't make sense |
| 22:24 | <zcorpan> | well there was <multicol> |
| 22:24 | <zewt> | (fortunately, it's not a common one; much more common are pages that reduce text to a three-word column, which is perhaps even more painful) |
| 22:25 | <shetech> | I can think of a number of uses for multiple columns, but I wouldn't use it as a <body> style, for example (yikes). |
| 22:25 | <shetech> | I'm thinking of a CMS that's very content-rich |
| 22:25 | <shetech> | where interior pages might have article columns |
| 22:26 | <shetech> | and I'd want the flow to work automatically |
| 22:27 | <shetech> | zewt: I totally get it about paper vs. web, but I can still imagine web uses, as long as the designer followed some basic best practices (keeping stuff above the fold, for example) |
| 22:27 | <zewt> | ... please don't fold my monitor |
| 22:27 | <shetech> | has anyone seen how this might behave in a mobile medium, and how graceful is the transition? |
| 22:27 | <shetech> | zewt: hee |
| 22:27 | <zewt> | (seriously after as many years as I've used this stuff I still have no idea what "the fold" is supposed to mean in a web context) |
| 22:28 | <shetech> | ah |
| 22:28 | <shetech> | "fold" in web context is anything that naturally falls in a screen without the need to scrolling. Anything below that scroll line is "below the fold" |
| 22:28 | <shetech> | Of course, that changes depending on screen resolution |
| 22:29 | <zewt> | sometimes it seems to mean "the text after our broken, worthless rss feed text ends" (by people who have broken "summary" rss feeds instead of full-text ones) |
| 22:29 | <shetech> | so it's a slippery slope to define a "best practice" |
| 22:29 | <zewt> | shepazu: but people seem to say it at the end of a block fo text--by the time you get there you've scrolled down a ways anyway, so it no longer makes sense, heh |
| 22:29 | <shetech> | zewt: I haven't heard it used in that context |
| 22:30 | <shetech> | rss, I mean |
| 22:30 | <zewt> | i seem to recall people saying it referred to ads, too (not sure, abp) |
| 22:30 | <zewt> | eg. "after the following giant obnoxious ad" or something like that |
| 22:30 | <shetech> | heh |
| 22:31 | <shetech> | IF the giant obnoxious ad covers the whole page, I could see that |
| 22:31 | <shetech> | but |
| 22:31 | <zewt> | putting those together i'm inclined to take it as "a misappropriated term from other media that people use in lots of different ways" :) |
| 22:31 | <shetech> | well, yes |
| 22:31 | <shetech> | But it's actually appropriate in the context I've heard it, wherein a page design includes stuff at the top of the screen and below that natural scroll line |
| 22:31 | <zewt> | if you viewed the page on a ds, would it be called "the hinge"? |
| 22:32 | <shetech> | I try to design pages where the calls to action and high-value content fall "above the fold" |
| 22:32 | <shetech> | hee. good question. |
| 22:32 | <zewt> | those seem like exactly opposite sets of things :) |
| 22:32 | <shetech> | depends on your page, dunnit? |
| 22:32 | <shetech> | ;-) |
| 22:32 | <zewt> | ("calls to action" being "things that most users don't care about which we're trying to trick them into clicking" vs. actual useful content) |
| 22:32 | <zewt> | well, yes :P |
| 22:33 | <zewt> | on the vast majority of pages merely being on the page and reading is what the user would call "high-value content", though, and everything else ("sign up for no reason!" "click my stupid banner ads!") is low-value distraction, though |
| 22:34 | <zewt> | gotta love the web, where content is that annoying stuff that's distracting the user from signing up for an account |
| 22:34 | <shetech> | I've seen some page designs where, for example, a video port covers the entire top half of a page, with no clear call to action or even description of what the video is supposed to be. Ergo, missing both high value content AND a call to action. :D |
| 22:34 | <shetech> | yeah |
| 22:34 | <zewt> | like i think nyt pops up an obnoxious animated "do something!" (never actually read it) when you scroll near the bottom, when you're still reading |
| 22:34 | <shetech> | One man's fertilizer is another man's smelly nuisance |
| 22:34 | <zewt> | but crap is always crap |
| 22:34 | <shetech> | yeah, I hate that nyt stuff. That's relatively new, and highly annoying |
| 22:35 | <shetech> | har! Indeed! |
| 22:35 | <shetech> | Well, so I'm trying to instruct readers how to avoid crap as much as possible... |
| 22:35 | <shetech> | which includes building pages that are NOT too long |
| 22:35 | <shetech> | and that do NOT include annoying popups |
| 22:35 | <shetech> | and stuff |
| 22:35 | <zewt> | i don't think telling people "don't use popups, they're annoying" is terribly productive |
| 22:36 | <shetech> | heh |
| 22:36 | <shetech> | well, no |
| 22:36 | <zewt> | people know they're annoying |
| 22:36 | <shetech> | That was perhaps a bad example |
| 22:36 | <zewt> | one thing about the web: you can very quickly tell how highly someone thinks of their own content |
| 22:36 | <shetech> | gad. no kidding. |
| 22:37 | <shetech> | marketers and content developers often have very different opinions |
| 22:37 | <zewt> | if someone cares little enough about what they have to say to have monkeys dancing back and forth across it continuously, i'm not sure why I should care either |
| 22:37 | <shetech> | yep. |
| 22:37 | <shetech> | agreed. |
| 22:37 | <shetech> | look! shiny! |
| 22:37 | shetech | groans |
| 22:38 | <shetech> | one thing about columns, though, to your earlier point, is that the human eye can still read columnar content a little easier than a big block of grey-space |
| 22:38 | <shetech> | as long as the block containing those columns is, as you suggest, all above a magical scroll line |
| 22:38 | <zewt> | that's just a max-width thing, though; and it's very often taken to the point of a fault (eg. the three-word-columns problem) |
| 22:39 | <shetech> | yes |
| 22:39 | <shetech> | good point |
| 22:39 | <zewt> | (even better, when it turns into a column of single words as it flows around an image plonked directly into the text) |
| 22:39 | <shetech> | heh |
| 22:39 | <shetech> | also a good point |
| 22:39 | <zewt> | (i also hate when people apply the "max width is easier to read" idea to code, where it doesn't apply at all) |
| 22:39 | <shetech> | ew. no kidding. |
| 22:40 | <zcorpan> | the proposal for # in data url seems like magic |
| 22:40 | <zewt> | (a very common "argument" for the python-80-columns thing) |
| 22:40 | <shetech> | well, I'm writing for dummies, so that may be more detail than I can get into |
| 22:40 | <shetech> | :D |
| 22:41 | <shetech> | as with most things, there's room for judgment calls |
| 22:41 | <shetech> | all we can do is recommend |
| 22:41 | <shetech> | anyway, thanks for your insight |
| 22:41 | <shetech> | that was helpful |