| 00:33 | <AryehGregor> | This is simply fascinating: http://www.popcenter.org/problems/ |
| 02:49 | <boblet> | hey all. time’s @datetime must be “valid date string with optional time” — does this exclude 2.5.5.4 Local dates and times (datetime without timezone)? |
| 02:49 | <boblet> | or, is timezone required for @datetime datetimes? |
| 03:06 | <boblet> | Hixie: does @datetime (requires “valid date string with optional time”) linking to 2.5.5.7 (requires timezone) mean local datetime is invalid? link text indicates no, link target indicates yes |
| 06:02 | <Hixie> | boblet: not sure what you're asking exactly |
| 09:51 | <boblet> | Hixie: when using <time datetime=""> is it ok to use a datetime without a timezone (floating time), or is a timezone (or Z) required? |
| 11:23 | <hsivonen> | Hixie: how did you decide on the details of the behavior of document.readyState? Did you spec the behavior of a browser exactly and, if so, which browser? |
| 11:47 | <krijnh> | Dashiva: could be nice, if the important lines feature is used correctly. I'm not really following the logs, but is it? |
| 11:49 | <krijnh> | (Got 24043 important lines flagged now) |
| 12:20 | <jgraham> | krijnh: You should make it like all these newfangled social sites and hand out achievement badges for getting different numbers of lines in yellow |
| 12:21 | <annevk> | reddit upvotes for lines |
| 13:29 | <Dashiva> | krijnh: It seems to be generally useful |
| 13:29 | <Dashiva> | But I still think it should have tags |
| 13:30 | <Dashiva> | Informative, controversial, funny, etc |
| 13:34 | <spliter> | hello. Is there any appropriate tag to mark a dictionary term in HTML5? |
| 13:35 | <hsivonen> | spliter: <i> or <b> |
| 13:37 | <spliter> | thanks hsivonen. But I mean is there anything more suitable than just italics or bold. More semantically correct. These tags don't bring any semantic meaning in my opinion |
| 13:38 | <Dashiva> | There's no special tag for dictionary terms, no |
| 13:38 | <Dashiva> | What do you plan to do with this special markup for dictionary terms? |
| 13:39 | <spliter> | Dashiva: I have site's logo and then,plan to use dictionary term as a sort of tagline that explains the site's name using dictionary term |
| 13:41 | <Dashiva> | Seems like that'd be better suited for a header element |
| 13:41 | <spliter> | Dashiva: I am wrapping logo and this tagline/dict term into <header> |
| 13:42 | <spliter> | don't feel like nesting <header>s |
| 13:42 | <jgraham> | <hgroup><h1>Perplexed</h1><h2>A state of confusion</h2></hgroup> |
| 13:42 | <spliter> | aha, jgraham that looks more appropriate indeed |
| 13:42 | <spliter> | thanks. That might work |
| 13:43 | <spliter> | but... then I need to wrap logo image into <h1>. Would it be semantically correct? |
| 13:43 | <spliter> | logo is an image. Not even wrapped into a link (it's just one-page without any navigation) |
| 13:44 | <Dashiva> | As long as the alt text is proper, probably |
| 13:45 | <jgraham> | Yeah, logo as <h1> is fine with correct alt text |
| 13:46 | <spliter> | ok, guys. Thanks. Will go for <hgroup> and headers then |
| 13:46 | <jgraham> | The acid test is "if I remove this image and leave the alt text only, does the page still make sense and convey the same information" |
| 13:46 | <spliter> | yeah, that is clear jgraham. Just was not sure about usage of image within <h1> |
| 14:45 | <adactio> | Just to clarify: an hgroup element can only contain h1 to h6, so it can't have an img in there. But h1-h6 allow phrasing content (including img) so it *is* okay to have an img inside hgroup ...as long as it's wrapped in an h1-h6. Have I got that right? |
| 14:45 | <Dashiva> | Yeah |
| 14:46 | <adactio> | Coolio. |
| 14:57 | <zcorpan> | hmm, making compression mandatory might be better than xor masking |
| 14:57 | <zcorpan> | (in websockets) |
| 14:59 | <Philip`> | I thought the idea was to prevent the attacker determining the bytes that go over the wire |
| 15:00 | <Philip`> | and with compression it seems relatively easy for them to determine that, since it's not random |
| 15:00 | <zcorpan> | that's indeed the point |
| 15:01 | <zcorpan> | i don't know enough about compression algorithms |
| 16:29 | <zcorpan> | hsivonen: here's a proper answer to what new "html5 stuff" we've got http://my.opera.com/ODIN/blog/2010/12/17/new-html5-features-in-opera-11 |
| 16:30 | zcorpan | leaves for foodz |
| 16:53 | Philip` | unexpectedly receives "Introducing HTML5" in the post |
| 17:14 | <TabAtkins> | annevk: What do you think about image()'s other fallback feature, of letting you fallback to another image (possibly a browser-generated one) when the first image 404s or is otherwise unavailable? |
| 17:17 | <AryehGregor> | TabAtkins, that sounds slow. |
| 17:17 | <TabAtkins> | Yes? It's not meant for speed, in particular. |
| 17:19 | <AryehGregor> | I guess. |
| 17:20 | <TabAtkins> | I still think the format fallback is useful, for cases like falling back from APNG to GIF (when maintaining the animation is more important than APNG's normal fallback of maintaining the image), or for handling new formats. |
| 17:20 | <AryehGregor> | Given that content negotiation is an unsalvageable failure, you're saying. |
| 17:20 | <TabAtkins> | But I agree that the syntax isn't great. I'd prefer doing this automatically through an @image block, with a format similar to @font-face. |
| 17:21 | <TabAtkins> | Yeah, sure. |
| 17:21 | <AryehGregor> | That sounds more awkward if you're using a lot of images only a few times each. |
| 17:21 | <AryehGregor> | image() sounds like a better idea than that. |
| 17:21 | <TabAtkins> | Indeed it is. |
| 17:21 | <AryehGregor> | But you're not solving the fallback problem for anything other than CSS. |
| 17:21 | <AryehGregor> | So it doesn't seem like a great solution. |
| 17:22 | <TabAtkins> | True, though you can use CSS to solve the fallback problem for <img>. |
| 17:22 | <AryehGregor> | In practice, new image formats have been successfully adopted, so is this really needed? |
| 17:22 | <TabAtkins> | (By using the fallback in the 'content' property.) |
| 17:22 | <AryehGregor> | Either you just wait till all browsers you care about support it, or (if you really care) use JS detection of some kind. |
| 17:23 | <AryehGregor> | I don't see a real need for declarative fallback here. |
| 17:23 | <AryehGregor> | Also, image formats can themselves allow for fallback in various ways, like how APNG can fall back to PNG. |
| 17:23 | <AryehGregor> | Or <svg>-in-HTML can fall back to anything. |
| 17:24 | <TabAtkins> | I just mentioned one example of how you may want to fallback in a different axis than the image format natively supports, like preserving the animation aspect of APNG by falling back to GIF. |
| 17:24 | <TabAtkins> | How does SVG do fallback? |
| 17:25 | <AryehGregor> | It only does if it's in HTML. Then you can stick an <img> in some tag where SVG will ignore it, but browsers that don't support SVG will treat all the tags except the <img> as unrecognized wrappers. |
| 17:25 | <TabAtkins> | Oh, I see. SVG can, itself, fall back. Gotcha. |
| 17:25 | <AryehGregor> | I don't remember which tag you're supposed to use for this, but it works, because SVG doesn't have non-whitespace content in any of its elements. |
| 17:55 | <TabAtkins> | I'm happy I tracked down why I kept getting calls about leaky baptismal fonts. I was just able to redirect a dude to the correct number. |
| 17:55 | <miketaylr> | O_O |
| 17:56 | <Philip`> | Did you tell them to use WOFF? |
| 17:56 | <TabAtkins> | Wrong type of font. ^_^ |
| 17:56 | <TabAtkins> | A recent website update on some baptismal font maker in Houston put the wrong area code on the phone number in their header. |
| 17:58 | <TabAtkins> | Ooh: http://code.bocoup.com/dataurl/ |
| 17:59 | <hsivonen> | TabAtkins: what's a babtismal font? |
| 17:59 | <TabAtkins> | hsivonen: A little sink-like thing of water that you baptize babies in. |
| 18:00 | <hsivonen> | TabAtkins: ok. so nothing to do with fonts |
| 18:00 | <TabAtkins> | No, it's just called a font, as in "font of wisdom" and such. |
| 18:00 | <hsivonen> | (I failed by using define: googing instead of regular googling) |
| 18:04 | <Dashiva> | Whenever someone uses font in that meaning I am reminded of http://www.penny-arcade.com/comic/2005/08/26/ |
| 18:05 | <TabAtkins> | Heh. |
| 18:16 | <annevk> | TabAtkins, how often do you get a 404 image? |
| 18:16 | <annevk> | TabAtkins, and why can't your 404 page be an image? |
| 18:16 | <annevk> | (images are always shown) |
| 18:17 | <TabAtkins> | Hmm, it could be. |
| 19:06 | <Hixie> | hsivonen: i do not recall |
| 19:29 | <hsivonen> | Hixie: ok. by source inspection, it looks surprisingly close to Gecko |
| 19:29 | <Hixie> | why "surprisingly"? |
| 19:29 | <hsivonen> | Hixie: too bad the behavior doesn't make as much sense as it could if designed rather than evolved |
| 19:30 | <Hixie> | welcome to the web |
| 19:30 | <hsivonen> | Hixie: previously, IIRC, you had shown reluctance to use all the existing readyState states |
| 19:30 | <Hixie> | i guess someone must have convinced me that i was wrong :-) |
| 19:32 | <hsivonen> | it's particularly sad that readyState goes "interactive before defer scripts but DOMContentLoaded fires after |
| 19:33 | <hsivonen> | it would be nice if the same task queue task that fires DOMContentLoaded flipped readyState |
| 19:33 | <hsivonen> | too late I guess |
| 19:33 | <hsivonen> | too late to change that is |
| 19:34 | <hsivonen> | jQuery expects a relationship between DOMContentLoaded and "complete", but the relationship isn't strictly there |
| 19:40 | <Hixie> | hey anyone want to be our group representative for freenode? |
| 19:44 | paul_irish | offers. |
| 19:46 | <Hixie> | cool, someone will contact you |
| 19:46 | <Hixie> | and thanks! |
| 19:47 | <paul_irish> | np! |
| 19:52 | <hober> | I'd be happy to as well |
| 19:53 | <Hixie> | well it's not paul_irish's job to delegate as he sees fit :-) |
| 19:53 | <Hixie> | er |
| 19:53 | <Hixie> | it's _now_ |
| 19:54 | <hober> | heh, indeed |
| 21:20 | Martinp23 | sets mode: +o paul_irish |
| 21:20 | <TabAtkins> | Ah, we're finally op'ing? Goodbye to an amazing legacy of no ops. |
| 21:20 | <_bga> | :( |
| 21:28 | <Lachy> | TabAtkins, huh? How did we get an op in here? |
| 21:28 | <oojacoboo> | doesn't css3 have gradient support outside the browser specific prefixing? |
| 21:29 | <TabAtkins> | Hixie asked if anyone wanted to be our "group representative for freenode". paul_irish volunteered. |
| 21:29 | <oojacoboo> | I can't seem to find any docs on it... :/ |
| 21:29 | <Hixie> | i've no idea if we'll actually get ops |
| 21:29 | <TabAtkins> | oojacoboo: Yes, dev.w3.org/csswg/css3-images describes the gradient functions. Moz's current experimental implementation is closest to the spec. |
| 21:29 | <paul_irish> | Martinp23 is the freenode guy. i think he was just testing out op. |
| 21:29 | <Hixie> | i kinda hope we don't get ops :-) |
| 21:29 | <Lachy> | ok |
| 21:30 | <paul_irish> | PM me if you want op access in here. |
| 21:30 | <oojacoboo> | images.... grrr |
| 21:30 | <Martinp23> | hehe, nah, I needed to give you op access so you could register the channel :) |
| 21:30 | <TabAtkins> | oojacoboo: Huh? |
| 21:30 | <Lachy> | we haven't needed them for the past 6 years, but ok |
| 21:30 | <paul_irish> | Martinp23: its all regged. i'm good. |
| 21:30 | <oojacoboo> | I hardly consider that an appropriate place for gradient |
| 21:30 | <TabAtkins> | oojacoboo: I'm confused. A gradient is a type of image. What else would it be? |
| 21:30 | <oojacoboo> | a background color? |
| 21:30 | <TabAtkins> | (More properly, it's a type of paint server, which is a generalization of images.) |
| 21:30 | <oojacoboo> | I don't know |
| 21:31 | <oojacoboo> | doesn't seem like an image to me, just b/c people used images in the past to achieve it doesn't make it an image |
| 21:31 | <TabAtkins> | It's certainly not a color. Colors are dimensionless and sizeless. |
| 21:31 | <oojacoboo> | it's a gradient ;) |
| 21:31 | <TabAtkins> | I don't understand what is wrong with calling it an image. |
| 21:31 | <oojacoboo> | b/c it's not one |
| 21:31 | <TabAtkins> | That's just a term for "2-dimensional rectangle of patterned color". |
| 21:32 | <TabAtkins> | What are you trying to define "image" as that doesn't apply to gradients? |
| 21:32 | <oojacoboo> | well, maybe I just don't know then, b/c I consider an image to be something linked in |
| 21:32 | <oojacoboo> | aka, an image |
| 21:32 | <oojacoboo> | with an image type |
| 21:32 | <TabAtkins> | The linking nature certainly has nothing to do with something being an image. It's a property of the content. |
| 21:32 | paul_irish | sets mode: -o paul_irish |
| 21:33 | <TabAtkins> | Under your definition, data urls might not be urls. <canvas> certainly wouldn't be. |
| 21:33 | <oojacoboo> | pretty soon everything will be an image then |
| 21:33 | <oojacoboo> | esp since I can apply gradient to nearly anything |
| 21:33 | <TabAtkins> | s/might not be urls/might not be images/. |
| 21:33 | <TabAtkins> | I have no idea what you're thinking about. It is certainly not true that everything will be an image. |
| 21:33 | <oojacoboo> | border: gradient() |
| 21:33 | <oojacoboo> | image? |
| 21:34 | <TabAtkins> | border: gradient() makes no sense. Borders have a color. Border-image would work, though. |
| 21:34 | <oojacoboo> | oh, so you can't use linear-gradient() on border: ? |
| 21:34 | <TabAtkins> | (That said, you can define a sensible rectangle for borders such that they can take paint servers instead of colors. |
| 21:35 | <oojacoboo> | servers? |
| 21:35 | <TabAtkins> | No, gradients are a type of <image>, same as url(). Any place you can use url() to pull in an image, you can use gradient() to construct one instead. |
| 21:36 | <oojacoboo> | border-image: linear-gradient() ? |
| 21:36 | <TabAtkins> | Sorry, paint server is kind of a bad term. It has nothing to do with network servers. It just means something which can provide a pattern. SVG uses the term as a generalization of images. |
| 21:36 | <TabAtkins> | Yes, that's fine. |
| 21:36 | <oojacoboo> | gotcha |
| 21:36 | <oojacoboo> | seems a bit confusing but w/e |
| 21:36 | <oojacoboo> | I would have much preferred a bit of simplicity |
| 21:37 | <oojacoboo> | I get the url() gradient() replacement, just thought we might have a shorthand for border: |
| 21:37 | <TabAtkins> | It's definitely simple. Your mental model is just constructed differently, so it doesn't fit your head quite right. You're interpreting that as complexity, because you have to create several exceptions and special-case rules to make the concept fit the shape of your understanding. |
| 21:38 | <TabAtkins> | Fix the shape of your understanding instead, and you see that it's extremely simple. ^_^ |
| 21:38 | <oojacoboo> | I'm getting that, which is def what has to happen, just not how my logic would have put it together |
| 21:40 | <TabAtkins> | It is indeed somewhat unfortunate that the color and border-color properties were defined in such a way that only <color>s are appropriate for them. This can be fixed, though - webkit, for example, hacks around the issue of 'color' only taking colors by defining a background-attachment value that means "use this image for painting the text". |
| 21:41 | <TabAtkins> | It would be better to just define 'color' to take a color or image, and define the size of the rectangle that images are painted into. It should be the same thing that backgrounds are painted into. |
| 21:41 | <oojacoboo> | I just like the thought of thinking of a gradient as a color |
| 21:41 | <TabAtkins> | Similarly, border-color would have a painting area of the border box. |
| 21:41 | <oojacoboo> | like in photoshop how it's treated |
| 21:41 | <oojacoboo> | you could apply it to nearly anything |
| 21:42 | <TabAtkins> | I know how you're thinking, it's just backwards. Think instead that Photoshop always deals with images, and colors are just solid-color images with no intrinsic dimensions. |
| 21:42 | <oojacoboo> | I guess I am thinking of it more from a use case and not a development perspective |
| 21:42 | <TabAtkins> | (Gradients don't have intrinsic dimensions either, so they work similarly.) |
| 21:42 | <TabAtkins> | In other words, think of gradients as images, and instead of "blue" think of something like "linear-gradient(blue, blue)". |
| 21:43 | <TabAtkins> | (Or, as you can write in the Image Values module, "image(blue)", which turns it from a <color> into an <image>.) |
| 21:43 | <oojacoboo> | mmm |
| 21:43 | <oojacoboo> | yea... reprogramming... :/ |
| 21:44 | <TabAtkins> | The difference is just that colors can be painted into anything without having to worry about what the size of the painting rectangle is, because colors are perfectly uniform. Images, like gradients, need to know the size of the rectangle they're being drawn into, so they can size themselves appropriately. |
| 21:44 | <oojacoboo> | TabAtkins: if you rely on pixel based gradients |
| 21:45 | <oojacoboo> | variable based gradients wouldn't be constricted |
| 21:45 | <TabAtkins> | No, all gradients. Scalable gradients still need to know what size to scale themselves to. |
| 21:46 | <oojacoboo> | right, yea, but they can get that from the parent element |
| 21:46 | <TabAtkins> | Same thing applies to SVG, for example. |
| 21:46 | <oojacoboo> | the styled element* |
| 21:46 | <oojacoboo> | I guess that might require reprocessing |
| 21:46 | <oojacoboo> | and repainting |
| 21:46 | <oojacoboo> | like a table |
| 21:47 | <TabAtkins> | No they can't. You want a different rectangle for backgrounds and borders, for example. |
| 21:47 | <TabAtkins> | And a third rectangle for <img>, once that gets exposed in a proper way for CSS (<img>'s linked image is drawn into the content box). |
| 21:48 | <TabAtkins> | (Backgrounds paint into the padding box by default, though that can be changed to the border or content box.) |
| 21:49 | <oojacoboo> | yea |
| 21:54 | <Hixie> | can anyone remind me why we're doing window.createObjectURL(blob) rather than blob.url ? |
| 22:02 | <oojacoboo> | Hixie: keeping it interesting |
| 22:02 | <Hixie> | i guess if you pass a blob around to another window the other window wouldn't be able to get a local-lifetime-bound url |
| 22:05 | <TabAtkins> | Hixie: I didn't understand the reasoning well enough to remember it perfectly, but it was something to do with not exposing GC behavior when passing urls between windows, yeah. |
| 22:09 | <Hixie> | sicking: we already have a registry |
| 22:10 | <Hixie> | heycam, sicking: i don't follow how the proposal lets you just check name instead of checking code. can you elaborate? |
| 22:11 | <heycam> | Hixie, you would mint a new IDL exception that you otherwise would have an exception/code combination currently |
| 22:11 | <heycam> | these exceptions must have a unique identifier in the idl, across all specs |
| 22:11 | <heycam> | the .name property is set to the identifier of the exception |
| 22:11 | <Hixie> | right now for all the APIs I use all i check is .code |
| 22:11 | <Hixie> | how do all those .codes get names? |
| 22:12 | <Hixie> | i don't follow |
| 22:12 | <heycam> | for new APIs, they wouldn't have codes. you just mint your exception with a given identifier and that gives the .name. |
| 22:13 | <heycam> | for existing APIs, these objects would also have a .code |
| 22:13 | <heycam> | so you could continue checking against that, because we obviously can't break that |
| 22:13 | <heycam> | but they would also have the .name |
| 22:13 | <heycam> | and would be instanceof NoModificationAllowedError, for example |
| 22:14 | <Hixie> | sounds like a lot of extra complexity for no benefit, to me, but ok |
| 22:14 | <Hixie> | file a bug at some point letting me know what i have to do to make it all work in the specs i edit :-) |
| 22:14 | <heycam> | ok |
| 22:15 | <heycam> | well let's see if other people respond favourably or not first |
| 22:15 | <heycam> | i'll file a bug if/when i make the webidl change |
| 22:15 | <Hixie> | personally i much prefer that the platform have one semi-sucky way of doing things than it having two ways of doing the thing, even if the second way is better |
| 22:16 | <Hixie> | every piece of duplicate funcationality is a source of new bugs |
| 22:16 | <Hixie> | or rather, every piece of funcationality is a source of new bugs, but duplicate functionality just adds new bugs without adding new functionality |
| 22:17 | <heycam> | it adds a little functionality -- it allows spec writers to hieararchically arrange their exceptions if they so wish |
| 22:17 | <heycam> | and then authors can easily test for a whole branch of that hierarchy |
| 22:17 | <heycam> | even if there is no new functionality, but it makes the platform easier to write for, there's still a case to be made for such changes i think |
| 22:18 | <Hixie> | it doesn't make the platform easier to write for |
| 22:18 | <Hixie> | it makes it harder to write for |
| 22:18 | <Hixie> | because now you have to learn two ways of doing the same thing, and learn the bugs for each browser for both ways, and learn how they interact |
| 22:18 | <Hixie> | a web author can't just ignore the less good parts of the platform -- they have to know it all so that they can edit other people's code |
| 22:18 | <Hixie> | this is why perl is a write-only language |
| 22:19 | <Hixie> | because there are so many ways of doing the same thing that most perl authors only know a tiny subset of the whole language |
| 22:19 | <Hixie> | so they can edit their own perl code but not anyone else's |
| 22:20 | <heycam> | over time you can migrate to a saner, more consistent feature set authors can write against |
| 22:20 | <heycam> | obviously there will be old code that uses old stuff |
| 22:20 | <heycam> | just like there is old crazy stuff on the web now |
| 22:21 | <heycam> | authors don't need to know every single historical aspect of the web platform that is currently supported in order to do their work |
| 22:21 | <Hixie> | what don't they have to know? |
| 22:22 | <Hixie> | can you point to any api that we've been able to banish from what authors need to know to do their job? |
| 22:22 | <Hixie> | (banish while replacing with duplicate but better-designed functionality, i mean) |
| 22:22 | <heycam> | for a given project they're working on, they don't need to know everything |
| 22:22 | <Hixie> | that's not really how knowledge works :-) |
| 22:23 | <Hixie> | you're not a "web developer" if you have to relearn everything for each project |
| 22:23 | <Hixie> | the whole point of being a developer in a certain area of expertise is that your knowledge is transferable |
| 22:23 | <heycam> | not relearn, but learn additional things |
| 22:23 | <heycam> | if they are working on something that uses "the old way" of doing something, then sure, they have to know about that |
| 22:23 | <heycam> | if they're not, they don't |
| 22:24 | <heycam> | over time the chance that they'll need to know about "the old way" diminishes |
| 22:24 | <Hixie> | can you point to an example where we've done this? |
| 22:24 | <TabAtkins> | Hixie: I can now depend on querySelector rather than the getElement* methods. |
| 22:25 | <Hixie> | heycam: as far as i can tell everywhere where we have duplicate functionality, authors have to know both to be considered proficient web authors |
| 22:25 | <heycam> | hey who said anything about "proficient" ;) |
| 22:25 | <Hixie> | TabAtkins: yeah but you still need to know how getElement* work if you do web development work |
| 22:26 | <Hixie> | heycam: i think we should consider it a serious failure on our part if we make it impossible for any web dev to be proficient |
| 22:26 | <heycam> | the web's history is still pretty short, so i wouldn't be surprised if i couldn't think up of such a feature now. it's a long term thing, imo. |
| 22:26 | <Hixie> | 20 years is not that short :-P |
| 22:27 | <Hixie> | how about any other platform? |
| 22:27 | <Hixie> | win32, say |
| 22:27 | <AryehGregor> | Are you asking whether anyone understands all or even most of Win32? |
| 22:28 | <AryehGregor> | I think the answer is "no", although admittedly I'm not an expert on it. |
| 22:28 | <heycam> | sure, at a really broad level let's take plain Win32 to .NET |
| 22:28 | <Hixie> | win32 has all kinds of duplicate apis that were added pretty much with the same rationale (As far as i can tell): let's add a better API so that devs won't have to worry about the previous API |
| 22:28 | <AryehGregor> | (nor, indeed, do I even really know anything about it, except that it's huge) |
| 22:28 | <AryehGregor> | Yes, that certainly seems to be true. |
| 22:28 | <AryehGregor> | Contrast to Unix. |
| 22:29 | <Hixie> | even in my brief experience doing win32 programming a few years ago, i ended up having to learn all kinds of duplicate APIs and how they interacted |
| 22:29 | <heycam> | that these APIs can't disappear within the same kind of time frame (or at all?), is kind of a separate issue |
| 22:29 | <Hixie> | it's not that they can't disappear, it's that devs have to know them to do their job, because legacy code will have them forever and will still need to be maintained |
| 22:30 | <heycam> | but web authors aren't going to be working on a 2010-written web page for ever |
| 22:31 | <heycam> | browsers should keep such things working, sure, but authors are going to either not be working on those pages, or will have migrated them |
| 22:31 | <Hixie> | sure, they'll be working on 2030-written-pages that evolved from 2005-written-pages |
| 22:31 | <AryehGregor> | No, they'll be working on something that was copy-pasted from 2010-written pages. |
| 22:31 | <Hixie> | exactly |
| 22:31 | <Hixie> | or they'll use some library that picked up something in 2010 and that in 2030 conflicts with the "better" api |
| 22:31 | <AryehGregor> | Just look at the source of a random web page that's not maintained by particularly sophisticated coders. A lot of them still use 1990s style throughout. |
| 22:32 | <heycam> | as these evolutions happen, the longer you look out, the less likely these vestigial features will be left in these pages |
| 22:32 | <Hixie> | i'm all for making the life of people in 2070 better, but i don't think we should do it at the cost of the life of people between 2010 and 2070 :-) |
| 22:32 | <AryehGregor> | For instance, here's a page I happened to have open right now: view-source:http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/Opencl_tofc.html |
| 22:32 | <heycam> | heh |
| 22:32 | <AryehGregor> | HTML 4.01 Transitional doctype. |
| 22:33 | <AryehGregor> | <script> that's commented out. |
| 22:33 | <AryehGregor> | When was the last browser that needed <script>s commented out? |
| 22:33 | <AryehGregor> | Like probably NN2 or something? |
| 22:33 | <heycam> | ages ago, sure |
| 22:33 | <TabAtkins> | I cargo-culted the script commenting when I first started webdev. @language, too. |
| 22:33 | <heycam> | i'm not making any claims on what kinds of time frames these will be |
| 22:33 | <heycam> | me too, i think we all did |
| 22:34 | <AryehGregor> | Another page I have open: http://www.popcenter.org/problems/identity_theft/ |
| 22:34 | <AryehGregor> | That one's pretty sophisticated, it even uses jQuery. |
| 22:34 | <heycam> | anyway, i don't think this change (the exception thing) will really make the lives of people between 2010 and 2070 appreciably worse |
| 22:34 | <AryehGregor> | But it has language="javascript". |
| 22:34 | <TabAtkins> | I admit that I find the way js handles HTML comments particularly clever (making <!-- start a one-line comment, and the fact that the HTML parser doesn't care if --> is preceded by //). |
| 22:34 | <Hixie> | i think there's a huge opportunity cost to adding new features that duplicate old features, which is not offset by the potential long-term win. We would IMHO do better to add new features that are not duplicates -- we would still help people long-term, but we wouldn't increase the complexity on authors medium-term |
| 22:34 | <AryehGregor> | Complication adds up. |
| 22:35 | TabAtkins | loves multi-language programs that exploit differing commenting syntaxes. |
| 22:35 | <AryehGregor> | One thing that's a good idea is to add new features that generalize old features and *also* fix their problems. Like querySelector() instead of getElement*(). |
| 22:35 | <AryehGregor> | Then the generalization makes the feature worth it, and hopefully the old feature will die one day. |
| 22:36 | <heycam> | yes that could help make the timeframe shorter |
| 22:36 | <Hixie> | yes, querySelector() makes sense because it adds a lot of functionality |
| 22:36 | <AryehGregor> | There are *some* web features that have died such that implementers can remove them, right? I know I've seen some that not all browsers implemented, at least. |
| 22:36 | <AryehGregor> | I can't immediately think of any that all browsers implemented but that could be removed anyway . . . |
| 22:36 | <Hixie> | AryehGregor: i don't know of any that were ever implemented in the majority of deployed browsers |
| 22:37 | <AryehGregor> | Of course, they'd presumably be so obscure that I'd have never heard of them. |
| 22:37 | <Hixie> | browser-specific features have definitely died |
| 22:37 | <Hixie> | <spacer>, e.g. |
| 22:37 | <Hixie> | bbiab |
| 22:41 | <Philip`> | I imagine you can be a decent web developer nowadays without knowing much about framesets or spacer GIFs or web-safe colour palettes |
| 22:43 | <Dashiva> | Or IE6 bug workarounds |
| 22:43 | <oojacoboo> | instead there are just other issues |
| 22:43 | <oojacoboo> | mobile, etc |
| 22:44 | <oojacoboo> | it's not this nirvana, as you paint it |
| 22:46 | <Dashiva> | The bar has been raised significantly |
| 22:46 | <oojacoboo> | what analogical bar is this? |
| 22:48 | <Dashiva> | The challenge of yesteryear was designing a page that worked in two different browsers on the same computer. Nowadays it's designing a page that works on multiple platforms, widely different hardware and screen sizes and network capabilities |
| 22:49 | <oojacoboo> | agreed, so, I don't see how the statement made by Philip` is really applicable |
| 22:49 | <oojacoboo> | sure, you can make a simple webpage easier than you could 10 years ago, but, the web didn't stop innovating |
| 22:50 | <AryehGregor> | The point is that some skills were once required of web developers and no longer are. So it's not like every change just means you need to know more and more. |
| 22:51 | <oojacoboo> | liar |
| 22:51 | <Dashiva> | Considering the proliferation of javascript and libraries, more and more work can be done by third parties |
| 22:52 | <hober> | image/svg+xml has finally been registered: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08275.html |
| 22:53 | <oojacoboo> | Dashiva: keeping up with new technologies will always take a considerable amount of work that only a handful of people will pursue, so, if you want to talk about old technology, yes, new tech, makes old tech easier to use/accomplish goals, but keeping up, will never be commonplace, or easy |
| 22:54 | <oojacoboo> | if the goal is status quo, it will always remain at the same level so long as innovation continues at it's current pace |
| 22:55 | <Dashiva> | I'm not really convinced writing jQuery.doCoolThing() requires much in terms of keeping up with tech |
| 22:55 | <Dashiva> | More and more of the tech is being abstracted away |
| 22:55 | <oojacoboo> | and you are limited by what coolThing that is, so keep thinking status quo |
| 22:56 | <oojacoboo> | you are at the mercy of jquery plugin developers and jquery core developers |
| 22:57 | <Dashiva> | So anything that has been done at least once is status quo? That's a rather demanding angle |
| 22:57 | <oojacoboo> | I didn't say that, I am saying anything that has turned into a mass available "framework" or resource, is status quo |
| 22:58 | <oojacoboo> | implementing jquery plugin A is nothing special, but creating your own plugin that no one else has access to, can be |
| 22:59 | <Dashiva> | So anything that's written in a way that can be reused by others is status quo? |
| 22:59 | <oojacoboo> | I'm not sure I would say that's entirely true, there are a few other factors, but generally speaking, yes |
| 23:01 | <Dashiva> | So if I write a plugin and someone else uses it, they're just status quo even though 99.999% of websites still do nothing like it |
| 23:02 | <oojacoboo> | technically, status quo isn't the correct word for this, but for the sake of the argument, it's the availability of it that makes it "status quo", yes |
| 23:02 | <oojacoboo> | ease of replication |
| 23:03 | <oojacoboo> | you can't really generalize this type of thing too much as there are many exceptions, but I think you catch my drift |
| 23:04 | <Dashiva> | No, I don't see how it backs up your earlier statement |
| 23:04 | <oojacoboo> | if your business model is around making a cool embed -able slidshow for instance, it better have something proprietary about it, otherwise, it's nothing special and will be copied and basically become status quo in no time |
| 23:05 | <AryehGregor> | Except that doesn't actually happen. There are lots of people who make their own embeddable slideshows. |
| 23:05 | <oojacoboo> | which earlier statement is that, b/c there has been a good deal of deviation |
| 23:05 | <Dashiva> | "keeping up with new technologies will always take a considerable amount of work that only a handful of people will pursue," |
| 23:05 | <oojacoboo> | AryehGregor: then they aren't worth copying |
| 23:05 | <oojacoboo> | Dashiva: correct, staying cutting edge |
| 23:06 | <oojacoboo> | developing an html5 site for example is considerably more work than a standard html4 site |
| 23:06 | <Dashiva> | But that's not the case, except in your overly constrained world where anything done once is old |
| 23:06 | <AryehGregor> | HTML5 is almost a strict superset of HTML 4, once you remove some features that were useless anyway. |
| 23:06 | <oojacoboo> | that's not necessarily cutting edge, but a decent example |
| 23:06 | <AryehGregor> | My website is HTML5, but it took very little effort to create. |
| 23:07 | <AryehGregor> | Probably less than an XHTML 1.0 website would have. |
| 23:07 | <AryehGregor> | (marginally) |
| 23:07 | <oojacoboo> | AryehGregor: if you are using html5 features for their actual use |
| 23:07 | <AryehGregor> | I am. http://aryeh.name/ |
| 23:07 | <Dashiva> | It takes less effort, since you don't have to deal with stuff like mandatory type attributes on script and style :) |
| 23:07 | <oojacoboo> | using standard DOM elements without any functional benefit isn't really anything special, agreed |
| 23:07 | <AryehGregor> | I make use of lots of HTML5 innovations. |
| 23:08 | <AryehGregor> | Like its broader tolerance of leaving out useless stuff, <nav>, <header>, etc. |
| 23:08 | <oojacoboo> | AryehGregor: most web developers won't know how or won't be interested in taking the time to learn how to do this |
| 23:08 | <AryehGregor> | "This" being something that's easier than XHTML 1.0? |
| 23:08 | <oojacoboo> | the point is, staying a step ahead will always require more work |
| 23:09 | <AryehGregor> | Was anyone talking about staying a step ahead? |
| 23:09 | <AryehGregor> | We were originally talking about just being a regular competent web developer. |
| 23:09 | <oojacoboo> | AryehGregor: yes, that's based around the statement I made earlier with Dashiva |
| 23:10 | <oojacoboo> | bah, my point is, its the same and will stay the same, it's not easier to harder yesterday or tomorrow so long as innovation remains at it's current pace |
| 23:10 | <Dashiva> | Well, like I already said, I don't think your statement applies to real world situations |
| 23:11 | <oojacoboo> | Dashiva: that's partially true, since implementation is a huge part of it |
| 23:11 | <TabAtkins> | Flexbox is hard: http://www.xanthir.com/diagrams/flex-align-diagrams.html |
| 23:11 | <oojacoboo> | but that's also proprietary |
| 23:12 | <AryehGregor> | oojacoboo, you realize that this channel is populated by a significant percentage of the people who *design* new standard web features? Fatalism isn't really applicable here. We were talking about how to design new web features to make the web platform as easy to use as possible for authors going on into the future. |
| 23:13 | <oojacoboo> | absolutely realize |
| 23:13 | <AryehGregor> | Specifically, we were talking about whether to add better versions of old features, and generally concluding it was a bad idea because then authors will wind up having to know both sets of features. |
| 23:13 | <AryehGregor> | I'm not at all clear on what relevance all this stuff you're saying has. |
| 23:13 | <oojacoboo> | I was specifically speaking to Dashiva |
| 23:14 | <zcorpan> | wtf http://www.youtube.com/watch?v=gwaAAEYIW_8 |
| 23:14 | <oojacoboo> | but the original reply was in regards to this blanket comment "Philip`: I imagine you can be a decent web developer nowadays without knowing much about framesets or spacer GIFs or web-safe colour palettes" |
| 23:15 | <oojacoboo> | that statement is really only accurate if you think we live in the web of 8 years ago with today's technologies |
| 23:16 | <oojacoboo> | b/c today presents a whole new set of issues |
| 23:16 | <TabAtkins> | zcorpan: It's just a visual application of polynomial multiplication. |
| 23:17 | <TabAtkins> | 21*32 = (2a + 1)*(3a+2) = 6a^2 + 7a + 2, where a=10 |
| 23:18 | <zcorpan> | yeah |
| 23:18 | <zcorpan> | still, a procedure a 10-year old can follow |
| 23:19 | <zcorpan> | at least a smart 10-year old |
| 23:19 | <TabAtkins> | Nah, a dumb 10 year old can follow it. A smart 6 year old could do it. |
| 23:20 | <TabAtkins> | It becomes generally unworkable above 3-digit numbers, but it's rare you actually have to multiply numbers that large with any precision. |
| 23:20 | <AryehGregor> | As it happens, though, a 10-year-old could also follow the more conventional procedure for multiplication. |
| 23:20 | <AryehGregor> | Although this one has the advantage that you don't need to know your multiplication tables, I guess? |
| 23:21 | <AryehGregor> | But it requires a lot of counting. |
| 23:21 | <AryehGregor> | Notice how all the digits in the examples were small. |
| 23:21 | <TabAtkins> | Precisely. It requires only counting, no multiplication. |
| 23:21 | <AryehGregor> | Try doing 79 times 88 or something. |
| 23:21 | <TabAtkins> | Right. |
| 23:21 | <TabAtkins> | Or simply, just 9 times 9. |
| 23:21 | <AryehGregor> | Yeah. |
| 23:22 | <zcorpan> | yes becomes pointless with high numbers |
| 23:22 | <TabAtkins> | Damn you, table layout algorithm, and your lack of specification! |
| 23:23 | <zcorpan> | TabAtkins: try sticking your head in the sand? |
| 23:23 | <TabAtkins> | Or, hrm. Maybe this is due to box-sizing, actually. |
| 23:24 | <TabAtkins> | Or, the combination thereof? |
| 23:25 | <TabAtkins> | Well, whatever. My diagrams looks right in Firefox, and I'm reasonably sure I'm using all the relevant properties correctly. |
| 23:26 | <TabAtkins> | Yeah, this is definitely just webkit being dumb about box-sizing, since it's screwing up even the simple case where I'm just telling something to be height:100% in a table-cell. |
| 23:27 | <AryehGregor> | I tend to find WebKit is more often incorrect on tricky stuff than Gecko. |
| 23:27 | <TabAtkins> | Yeah, me too. |
| 23:27 | <TabAtkins> | Time to repro and report. |