| 00:17 | <MikeSmith> | Hixie: here now |
| 00:50 | <roc> | at least I don't have to take responsibility for the CSS "dpi" unit |
| 00:51 | <TabAtkins> | Who *is* responsible for that? |
| 00:51 | <roc> | I don't know |
| 00:51 | <roc> | can we not implement it and then take it out of the spec? |
| 00:51 | <roc> | ddpx is a dumb name but at least it makes some sense |
| 00:52 | <TabAtkins> | dppx. ^_^ |
| 00:53 | <roc> | I reset my case |
| 00:53 | <TabAtkins> | I suspect it falls out of the image-resolution property, which is specced because CSS printers implemented it unprefixed. |
| 00:53 | <TabAtkins> | I'm just gonna define "x" to be a synonym for "dppx". |
| 00:53 | <TabAtkins> | And we'll see who screams. |
| 00:55 | <TabAtkins> | Oh, roc, while you're here, I had a question about your comments on element() to Birtles. |
| 00:55 | <TabAtkins> | In particular, what do you see as clashing about the use of element() as <image> and as a more generic element reference? |
| 00:57 | <roc> | mask:url(foo.svg#abc) |
| 00:57 | <roc> | er wait |
| 00:57 | <roc> | that's not what you were asking about |
| 00:57 | <roc> | mask:element(#abc) |
| 00:58 | <roc> | and suppose the element with the mask style is not an ancestor of the #abc element |
| 00:58 | <roc> | as currently specced I think that matches according to CSS Images and does not match according to the SVG proposal |
| 00:59 | <TabAtkins> | Ah, I see. So it's valid as an <image>, but not as a mask reference. |
| 00:59 | <TabAtkins> | Okay, so then we probably do want a separate function for "refer to an element" that doesn't interpret it as an image. |
| 00:59 | <TabAtkins> | Like select() or something. |
| 00:59 | <roc> | or |
| 01:00 | <roc> | well |
| 01:00 | <roc> | yes, that's probably for the best |
| 01:00 | <roc> | descendant() might be a better name |
| 01:01 | <roc> | maybe we're not talking about the same thing |
| 01:01 | <roc> | I think basically you want a version of element() that matches only within the subtree of the styled element. Possibly that could be achieved with extended selector syntax, but a different CSS value is probably better |
| 01:01 | <roc> | that could be a CSS image value and then SVG could just use it |
| 01:02 | <TabAtkins> | Or, wait, it's actually not a problem I think? |
| 01:03 | <TabAtkins> | if element(#abc) points to a non-child, or a child that's not a <mask>, it's an <image>. If it points to a <mask> child, it's a mask reference. |
| 01:03 | <TabAtkins> | The two should be mutually exclusive, since <mask> doesn't provide a paint source. |
| 01:05 | <roc> | that seems fragile |
| 01:06 | <TabAtkins> | Potentially, yeah. |
| 01:07 | <TabAtkins> | So, back to select(). If you allow the same fragment thing that document.find() does, it would be easy. "mask: select(> .foo);" |
| 01:24 | <TabAtkins> | hober: Any opinion on what the interaction between image-set("foo" 2x) and 'image-resolution' should be? |
| 01:29 | <TabAtkins> | hober: Right now, I have image-set() defined as setting the "intrinsic resolution" of the image, but that doesn't play well with the current initial value of "image-resolution". |
| 01:30 | <TabAtkins> | It might make sense to change the initial value to "auto", which means "1x, unless CSS says otherwise". |
| 06:22 | <hsivonen> | Hixie: pong |
| 06:30 | <Hixie> | hsivonen: your input on this thread would be helpful: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0004.html |
| 14:01 | <jgraham> | So if window A opens window B opens window C and B closes before any script can run in C, how do I get a reference from C to A? |
| 14:18 | <smaug____> | ugh, "please attach a minimal testcase" -> a zip file containing for example jQuery :/ |
| 14:20 | <zewt> | smaug____: to too many people, jQuery is "default" :| |
| 14:20 | <jgraham> | smaug____: You know it isn't possible to write js without jQuery, right? |
| 15:24 | <GPHemsley> | Hixie: So... why does the spec use a combination of AmE and BrE? |
| 15:25 | <Ms2ger> | It should be using en-US |
| 15:31 | <GPHemsley> | Ms2ger: 'organisation' is not en-US |
| 15:33 | <Ms2ger> | -s- seems to be used only for autocomplete, all other occurrences use -z- |
| 15:33 | <GPHemsley> | Ms2ger: And that was the precise instance I was looking at :) |
| 15:34 | <Ms2ger> | It's the only you could be looking at! ;) |
| 15:34 | <GPHemsley> | Ms2ger: At least I'm not seeing things! |
| 15:34 | Ms2ger | is glad he svn up'd the repo before claiming there was no such spelling in the spec |
| 15:35 | <GPHemsley> | :) |
| 15:39 | <Hixie> | GPHemsley: purely an oversight, please file bugs (if it's a keyword to be implemented, mark the bug "blocker") |
| 15:39 | <Hixie> | or send mail |
| 15:39 | <GPHemsley> | k |
| 15:39 | <Hixie> | should all be en-US |
| 15:39 | <Hixie> | the problem is that i speak en-GB and keep forgetting which is which |
| 15:39 | <Hixie> | due to spending too much time in the US |
| 15:41 | <micheil> | Hixie: I thought you spoke en-HIXIE? |
| 15:41 | <micheil> | or was that someone else here? |
| 15:41 | <Hixie> | en-GB-x-Hixie :-) |
| 15:41 | <micheil> | that's it! A custom dialect of english |
| 15:41 | <Ms2ger> | Good morning dglazkov |
| 15:41 | <micheil> | ;) |
| 15:41 | <Ms2ger> | Sure would be weird if someone else here spoke en-GB-x-Hixie |
| 15:42 | <dglazkov> | \o/ |
| 15:42 | <GPHemsley> | Bug 18482 |
| 15:46 | <niloy> | We request data from a servlet using ajax and parse the data as JSON, but when the JSON size is large, the UI hangs, can someone suggest any solution? |
| 15:48 | <GPHemsley> | micheil: 'Tis an idiolect, indeed. |
| 15:49 | <micheil> | heh, I remember there being a similar discussion a few months back.. |
| 15:50 | <micheil> | niloy: you may wish to ask that in, say, ##javascript (pretty sure these guys are doing spec stuff) |
| 16:07 | <Velmont> | timeless: http://my.opera.com/desktopteam/blog/2012/08/03/summer-core-update << has updated websocket now. -- So then /that/ blocker for irccloud is removed at least :P |
| 17:32 | <TabAtkins> | Any examples of some popular super-early polyfills damaging out ability to change a feature? |
| 17:35 | <Velmont> | Where are you going to use it? :] |
| 17:35 | <Velmont> | (I don't know any examples, for the record) |
| 17:35 | <Ms2ger> | var indexedbDB = window.indexedDB || window.webkitIndexedDB || window.moz .....? |
| 17:36 | <Velmont> | Ms2ger: What about it? |
| 17:36 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=770844 |
| 17:38 | <TabAtkins> | Oh, that's a different type of issue. |
| 18:38 | <hober> | is http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-resize really the most up-to-date documentation of the resize event? |
| 18:41 | <Ms2ger> | Probably |
| 18:42 | <hober> | sadface |
| 19:06 | <TabAtkins> | heycam|away: Is there any particular reason WebIDL doesn't let you nest constructors underneath another object? |
| 20:13 | <TabAtkins> | hober: How does the spec for image-set() look to you? http://dev.w3.org/csswg/css4-images/#image-set-notation |
| 20:14 | <hober> | syntax nit: I think you mean * where you have + |
| 20:15 | <TabAtkins> | No, that was intentional. There doesn't seem to be any use for an image-set() with only a single argument, is there? |
| 20:15 | <hober> | fair enough |
| 20:16 | <hober> | why [ <url> | <string> ] instead of <image>? |
| 20:16 | <TabAtkins> | I suppose maybe it could be useful if you *only* want to serve a 2x image... |
| 20:16 | <TabAtkins> | Because <image> covers things like gradients. |
| 20:16 | <hober> | image-set(image(......) 1x, image(....) 2x) should be fine, don't you think? |
| 20:17 | <TabAtkins> | Oh, right, yes. Hmm. Let me do some grammar hackery to make that work. |
| 20:17 | <hober> | and of course you know my feelings on <resolution> |
| 20:17 | <hober> | otherwise this all looks fine |
| 20:18 | <TabAtkins> | And the reverse, too. image(image-set(...), image-set(...)) |
| 20:18 | <TabAtkins> | kk |
| 20:18 | <hober> | right (the reverse should work) |
| 20:18 | <zewt> | TabAtkins: what benefit is there to restricting to 2+? seems like it'd do nothing but be annoying, heh |
| 20:18 | <TabAtkins> | zewt: The entire point of image-set() is to provide multiple versions of an image. |
| 20:18 | <hober> | is your algorithm always going to pick the same asset that <img srcset=""> would given the same arguments? |
| 20:19 | <zewt> | TabAtkins: that's not an explanation for *requiring* it, unless there's something inherent to it that would make it not work at all |
| 20:19 | <TabAtkins> | hober: There's no requirement there, but I don't see why it wouldn't. If HTML already defines something that I can hook, I'm willing to. |
| 20:19 | <zewt> | eg. if I'm editing image-set in existing CSS and I want to remove or comment out an entry, why would you force me to rewrite it without image-set? |
| 20:19 | <zewt> | (if it happens to reduce it to one item) |
| 20:20 | <TabAtkins> | zewt: Good point. That tips me over the edge. I'll change to *. |
| 20:20 | <zewt> | sounds sort of like something in Java that aggravated me to no end: unreachable code is a fatal error |
| 20:20 | <hober> | TabAtkins: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset |
| 20:21 | <hober> | sorry, this is the relevant link |
| 20:21 | <hober> | http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates |
| 20:22 | <TabAtkins> | hober: Hm, that algorithm seems unnecessarily restrictive. |
| 20:22 | <TabAtkins> | By my reading, it prevents you from ever choosing a low-res image under low-speed connections. |
| 20:23 | <hober> | see step 16 |
| 20:23 | <TabAtkins> | Oh, gotcha. |
| 20:25 | <TabAtkins> | Hm, it appears that my algorithm and HTML's are functionally identical, actually. |
| 20:25 | <TabAtkins> | However, a note that it should match <img srcset> would be appropriate. |
| 20:26 | <zewt> | TabAtkins: not to state the obvious or anything, but it's infinitely better to use the same algorithm than to declare it twice and assert that they're the same :) |
| 20:26 | <TabAtkins> | Ooh, wait - it appears that HTML decides definitely on the candidate before trying to resolve the URL, and doesn't change its mind even if the URL is an invalid image. |
| 20:26 | <hober> | that's what i would expect image-set() to do too |
| 20:27 | <hober> | the whole idea is that asset selection happens without having to fetch any assets |
| 20:27 | <zewt> | personally i'd find it weird if it had magic multi-fetch recovery stuff |
| 20:27 | <hober> | if you want magic multi-fetch fallback stuff, use image() |
| 20:27 | <TabAtkins> | Really? I have it specced to have a similar behavior to image(), where the UA orders the resources as it wants, then gets the first one that successfully decodes as an image. |
| 20:28 | <TabAtkins> | You can't actually use image() here, since your fallback is "use the next-best image". |
| 20:28 | <TabAtkins> | Rather, "your desired fallback". |
| 20:28 | <TabAtkins> | And you can't predict ahead of time how the UA will order the resources. |
| 20:29 | <hober> | each image-set() should only ever result in one http request; if it turns out to be invalid, you get an invalid image |
| 20:29 | <TabAtkins> | That seems quite suboptimal. |
| 20:30 | <hober> | if that doesn't work, image(image-set(), image-set(),...) |
| 20:30 | <TabAtkins> | ...that wont' work. It'll just request the same image again, presumably, unless you want to assume that "I already tried this once" is a factor in the resource selection algorithm. |
| 20:30 | <zewt> | hober: wouldn't that not work since there's no way for the second image-set to say "everything in the first minus whatever was picked first"? |
| 20:30 | <TabAtkins> | Plus it's very verbose. |
| 20:31 | <TabAtkins> | Telling someone to repeat their entire image-set() N times, where N is the number of things in the image-set(), is just user-hostile. |
| 20:31 | <hober> | I woudn't expect those two image-set()s to be the same |
| 20:31 | <hober> | or you can do it with image-set(image() 1x, image() 2x) |
| 20:31 | <TabAtkins> | Again, that's something *different*. |
| 20:31 | <zewt> | personally I find the idea of browsers trying to recover from being given bad urls unusual |
| 20:31 | <hober> | zewt: right |
| 20:32 | <hober> | zewt: it's the purpose of image(), but not of image-set(), so it would surprise me if image-set() was magic in that way |
| 20:32 | <zewt> | (i'd rather see an "X" or something, instead of have it silently "recover", at the expense of extra network requests and presumably a suboptimal image being shown) |
| 20:32 | <zewt> | does that happen with background-image: url(), url(), ...? |
| 20:32 | <TabAtkins> | Multiple bg images are stacked, not fallbacks. |
| 20:33 | <TabAtkins> | (And an invalid image in CSS is just invisible.) |
| 20:36 | <zewt> | unrelatedly, anyone want to give me a reason not to put *[hidden] { display: none !important; } in my stylesheet? heh |
| 20:37 | <TabAtkins> | No, go for it. |
| 20:37 | <TabAtkins> | No need for the *, though. |
| 20:37 | <TabAtkins> | Save a byte for your users. ^_^ |
| 20:37 | <zewt> | rather annoying that without it, every display: rule has to be in its own :not([hidden]) rule |
| 20:37 | <TabAtkins> | It's unfortunate that UA !important has become de-facto a more powerful level than author or user !important. |
| 20:38 | <zewt> | (and a bit strange that I need to work around it at all; I wish there was a separate boolean CSS rule to hide things that takes precedence over display) |
| 20:38 | <TabAtkins> | zewt: Yeah, that was clearly a mistake on our part early on. |
| 20:38 | <TabAtkins> | Definitely one of the time-travel fixes in CSS. |
| 20:38 | <zewt> | is there anything preventing adding something like that now? |
| 20:39 | <TabAtkins> | No, not particularly. Only inertia, plus possibly pushback from impls in the group who don't want to add something "unnecessary" because they have no authoring experience. |
| 20:39 | <zewt> | heh |
| 20:40 | <zewt> | @hidden is a big improvement, but everyone having to learn how it interacts with display is unfortunate |
| 20:40 | <TabAtkins> | But I'm off-and-on working on a 'display' spec, and might as well fit that into the same thing. |
| 20:41 | <zewt> | also the fact that webkit transitions became pretty much de-facto everywhere is ... annoying |
| 20:41 | <timeless> | Velmont: thanks, why didn't the operaupdater.exe tell me about it? |
| 20:41 | <TabAtkins> | hober: Want to start a thread about the fallback thing? If we don't do any fallback within image-set(), then there's no real reason to include the color, except perhaps just avoiding the verbosity of a wrapping image(). |
| 20:42 | <zewt> | still can't figure out any way to synchronously skip transitions |
| 20:42 | timeless | was running 11.52 |
| 20:42 | <TabAtkins> | transition-duration: 0 !important |
| 20:42 | <hober> | TabAtkins: which is fine by me (not including the color) |
| 20:42 | <TabAtkins> | hober: Well, obviously, since you don't want to change your impl. ^_^ |
| 20:42 | <hober> | heh |
| 20:42 | <zewt> | i've tried unsetting the transition while i make some change I don't want to transition, then setting it back, but it still does the transition |
| 20:42 | <TabAtkins> | Anyway, start a thread so we can discuss it, now that it's written up. |
| 20:43 | <hober> | i'll probably start two or three threads |
| 20:43 | <TabAtkins> | zewt: Do you flush style in between those? |
| 20:43 | <TabAtkins> | hober: Cool. |
| 20:43 | <hober> | (the fallback thing, the <resolution> thing, the <color> thing) |
| 20:43 | <zewt> | only way i've found is something like clear transition, setTimeout(function() { make the change, restore the transtiion }, 0), which of course isn't synchronous |
| 20:43 | <zewt> | TabAtkins: not sure what that means |
| 20:43 | <TabAtkins> | hober: I think the interesting use-case of providing printer-friendly versions justifies the <resolution>. ^_^ |
| 20:43 | <timeless> | Velmont: so... the updater gave me 12.01 |
| 20:43 | <timeless> | ... which isn't the same as 12.50 |
| 20:44 | <TabAtkins> | zewt: Browsers queue up style changes until they're forced to resolve them (or enough time passes that they need to resolve them for rendering). |
| 20:44 | <TabAtkins> | zewt: So doing an operation that requires accurate style information flushes the style queue, which is required for some hackery around transitions/animations to work properly. |
| 20:44 | <timeless> | oh, 12.50 is a dev preview thing |
| 20:45 | <zewt> | TabAtkins: what's good for triggering that? will getComputedStyle do it? |
| 20:45 | <jamesr_> | yeah |
| 20:45 | <jamesr_> | man i need to revive that proposal |
| 20:45 | <zewt> | (well, I know it'll force a style update, but I don't know if it'll do the job with transitions in the mix) |
| 20:45 | <TabAtkins> | Yeah, I think so. Tony Gentilcore put up a fairly comprehensive list of what works in WebKit, and the list should be pretty similar across browsers. |
| 20:46 | <jamesr_> | i'm not 100% on that in gecko |
| 20:46 | <jamesr_> | in WebKit that'll flush it all out |
| 20:46 | <zewt> | oddly, firefox is the only browser I hit where the setTimeout() hack didn't work (on code that worked in chrome and opera) |
| 20:47 | <zewt> | (the site is pretty mobile safari-centric so I couldn't spend much time poking at it, though) |
| 20:47 | <hober> | TabAtkins: the print case is more reasonably handled with the existing scale factor. image-set(foo.png 1x, bar.png 2x, baz.png 6x) |
| 20:48 | <timeless> | Velmont: so, the irccloud app still renders wrong (it loads at least, which is nice) |
| 20:48 | <zewt> | hober: how? are you just going to provide an arbitrarily blown-up image and hope it's both big enough for printing and not unnecessarily big? heh |
| 20:48 | <timeless> | specifically, the bottom of irccloud is outside the window edge |
| 20:48 | <zewt> | afk a few |
| 20:48 | <timeless> | and that's where the user input field is :( |
| 20:49 | <TabAtkins> | zewt: It's weird that setTimeout() didn't work. I thought everyone flushed style when they returned to the event queue. |
| 20:49 | <jamesr_> | no |
| 20:49 | <jamesr_> | we defer as much as possible |
| 20:49 | <jamesr_> | ideally we don't flush style until somebody asks via CSSOM or we go to paint |
| 20:49 | <TabAtkins> | Huh, okay. |
| 20:50 | <TabAtkins> | I clearly know nothing. |
| 20:50 | <jamesr_> | i've made this gradually more deferred in WebKit over the past year+ |
| 20:50 | <jamesr_> | it used to flush after every return from JS |
| 20:50 | <jamesr_> | gecko has a repeated style flush timer, i don't know if they also flush eagerly after returning from JS |
| 20:53 | <zewt> | of course, the problem is that this is script-visible (due to transitionend) |
| 20:53 | <zewt> | when this stuff breaks, i don't get the event and things break |
| 20:54 | <timeless> | hey, anyone here familiar w/ the http portion of websocket initialization? |
| 20:54 | <timeless> | how much of `upgrade: websocket` is case sensitive? |
| 20:54 | <timeless> | and which document(s) specify that? |
| 20:55 | <zewt> | rfc6455? |
| 20:56 | <TabAtkins> | hober: I've added your two issues to the draft. |
| 21:01 | <timeless> | zewt: 4.2.1 point 3 |
| 21:01 | <timeless> | specifically, which is what i needed |
| 21:01 | <timeless> | it's a long document ... |
| 21:02 | <zewt> | welcome to ietf specs |
| 21:10 | <TabAtkins> | hober: What do you think about the situation where you have image-set(image-set(foo 1x) 2x)? |
| 21:10 | <hober> | what's the problem? |
| 21:10 | <TabAtkins> | Valid? And if so, what does it mean? |
| 21:11 | <TabAtkins> | And if not, is it okay to require impls to recurse down the tree of references to ensure that there's no image-set() anywhere inside of an image-set()? |
| 21:11 | <hober> | foo gets selected for the inner image-set(), and its intrinsic width doesn't get scaled down. then the inner image-set() is selected for the outer image-set(), and its intrinsic size gets scaled by 0.5 |
| 21:11 | <TabAtkins> | ...so if they were both 2x, it would get scaled twice? That seems bad. |
| 21:12 | <hober> | i don't think it makes much sense for authors to do this, but i don't think it necessarily has to be made invalid. |
| 21:12 | <hober> | it's like other valid-but-kinda-nonsensical things |
| 21:12 | <TabAtkins> | I'd like to make sure, as much as possible, that valid things are interpreted sanely. |
| 21:12 | <TabAtkins> | In other words, stupid results should be because of stupid actions, not unintentional stupid interactions on our side. |
| 21:13 | <hober> | sure. and in this case, stupid results are as a result of stupid actions; the interpretation on our side is totally reasonable given the input |
| 21:13 | <hober> | gigo |
| 21:14 | <TabAtkins> | I don't particularly see how image-set(image-set('foo' 2x) 2x) meaning the same as image-set('foo' 4x) is reasonable on our part. |
| 21:14 | <zewt> | how isn't it? it seems like the logical result |
| 21:14 | <TabAtkins> | Only if you interpret the "2x" as meaning "halve the specified size", rather than "set the intrinsic resolution to 2 dots per px". |
| 21:15 | <hober> | again, we come back to the <resolution> craziness :) |
| 21:16 | <TabAtkins> | Your interpretation is just stilly, though. ^_^ |
| 21:16 | <hober> | this is clearly something on which we disagree. :) |
| 21:19 | <TabAtkins> | Anyway, if the effect is "nonsensically stack the multipliers", I'd rather just make it invalid. |
| 22:03 | <poop> | Is it valid in html5 to have <ns:customel>text</ns:customel>? I know that declaring namespaces in the html element with @xmlns is unsupported, but what about actually using the elements themselves? |
| 22:03 | <TabAtkins> | No, those are also invalid. |
| 22:03 | <TabAtkins> | (Because they can't be represented in the XML serialization.) |
| 22:04 | <poop> | TabAtkins: thanks. what do you mean by that? |
| 22:05 | <gsnedders> | <ns:customel> creates an element whose namespace is "http://www.w3.org/1999/xhtml"; and whose local name is "ns:customel". |
| 22:05 | <gsnedders> | Local names cannot contain colons. |
| 22:05 | <TabAtkins> | What I said. ^_^ If you parse as HTML, it knows nothing about namespaces, so it would just set the tagname to "ns:customel". But this can't be exported back into XML - you can't have element names with : in them. So, to maintain the DOM Consistency Principle, we make it invalid in HTML. |
| 22:06 | <poop> | TabAtkins: is there a spec for how this will be handled by UAs despite being invalid? |
| 22:07 | <gsnedders> | poop: Yes, the Parsing HTML Documents section. |
| 22:07 | <hober> | poop: the HTML spec |
| 22:07 | <gsnedders> | (in HTML/HTML5) |
| 22:27 | <Hixie> | poop: what's your specific use case? (what are you trying to do?) |
| 22:34 | <poop> | Hixie: oh, hi there. :) |
| 22:35 | <poop> | ummm, well i'm juust exploring possibilities for right now... I mean, I would like to have more semantic markup than what HTML natively provides. |
| 22:35 | <Hixie> | why? |
| 22:35 | <poop> | tags like <x:comment> and <avatar> and stuff, so that i don't get to have such messy </div></div></div> |
| 22:35 | <TabAtkins> | Semantics are a contract between you and the consumer. Custom elements thus have zero semantics. |
| 22:35 | <poop> | it's hard to work with. |
| 22:35 | <Hixie> | (what do you mean by "semantic"?) |
| 22:36 | <TabAtkins> | Every custom element is semantically equivalent to a <div> or <span>. |
| 22:36 | <Hixie> | <x:comment> has an element in HTML, it's <article> |
| 22:36 | <poop> | Hixie: well one it makes my markup easier and more maintainable and legible. |
| 22:36 | <Hixie> | for <avatar> you mean like a version of <img>? |
| 22:37 | <poop> | Hixie: shouldn't that be reserved for main centerpieces of webpages? I'm talking about for like a comment thread on a blog post |
| 22:37 | <poop> | Hixie: yes, exactly. |
| 22:37 | <Hixie> | poop: the "semantic" of an element is derived from what the spec says the element means, not from the tag name |
| 22:37 | <Hixie> | poop: i recommend reading the spec's section on <article> :-) |
| 22:38 | <poop> | in one sense it is a contract between me and the consumer. on the other hand its a nicer and more elegant one between me and myself. interacting with the dom in js willl be more concise and i could even modify the ua with a browser ext. and recommend thatmy users install it. |
| 22:38 | <poop> | Hixie: okay, but what about <img>? |
| 22:38 | <poop> | and <avatar>? |
| 22:38 | <Hixie> | if you just want something for yourself, I recommend making up your own language, and then having a script that converts it to HTML |
| 22:39 | <Hixie> | that's what i do sometimes |
| 22:39 | <TabAtkins> | If you're worried about code naming, that's not semantics. ^_^ Do what Hixie says - use a preprocessor to convert your private language into vanilla HTML. |
| 22:39 | <TabAtkins> | And paper over the differences in DOM with some helper functions. |
| 22:39 | <poop> | Hixie: oh really? have you ever written about it more extensively than you're likely to do here in IRC anywhere? |
| 22:39 | <Hixie> | e.g. the HTML spec itself is written in a kind of frankenstein's monster variant of HTML that I pipe through half a dozen scripts |
| 22:39 | <poop> | Hixie: i'm interested in the implementation details... :) |
| 22:40 | <Hixie> | the implementation is embarassingly ugly |
| 22:40 | <poop> | Hixie: ah, ok. |
| 22:41 | <Hixie> | but the principle is sound :-) |
| 22:41 | <poop> | but still, debugging isn't so easy when when you open your page in the browser for rendering the closing tags are a bunch of </div></div></div>s |
| 22:41 | <TabAtkins> | Just use Python or something - it's got decent dom-style implementations. |
| 22:41 | <poop> | TabAtkins: I've been reluctant to invest in larning python. |
| 22:41 | <Hixie> | poop: we've mostly removed the need to use <div> these days |
| 22:41 | <Hixie> | poop: i almost didn't include <div> in HTML actually |
| 22:42 | <Hixie> | but people threated to hit me |
| 22:42 | <poop> | Hixie: oh really? |
| 22:42 | <Hixie> | threatened |
| 22:42 | <poop> | thatwould've been awesome. |
| 22:42 | <Hixie> | note that <avatar> vs <img> doesn't involve any </div>s :-P |
| 22:43 | <gsnedders> | TIL: web developers are sadists, willing to do anything to keep their elements. |
| 22:43 | <TabAtkins> | Reasonable layouts still generally require <div>s. Particularly since there's no <content> element. ^_^ |
| 22:43 | <TabAtkins> | gsnedders: Masochists, you mean? |
| 22:43 | <Hixie> | TabAtkins: yeah man, when's css gonna fix that :-P |
| 22:43 | <TabAtkins> | Oh, the hitting of Hixie. |
| 22:43 | <TabAtkins> | Hixie: Man, I don't know. We gotta get this shit together. |
| 22:44 | <poop> | Hixie: no, but it is still more readable. |
| 22:45 | <TabAtkins> | poop: In my experience as a webdev, if your page is broken up into components that are responsible for emitting their own HTML, you rarely have very much nesting in any single chunk of HTML. |
| 22:45 | <TabAtkins> | (Even if the generated output stacks </div>s like they're going out of style.) |
| 22:45 | <Hixie> | poop: i seriously recommend making your own language and having a tool to convert from one to the other |
| 22:45 | <Hixie> | anyway, i gotta run. bbl. |
| 22:45 | <poop> | and i don't have to use <-i-m-g- -c-l-a-s-s-=-"-a-v-a-t-a-r-"- -/-> and i can just say <-a-v-a-t-a-r-> |
| 22:46 | <gsnedders> | TabAtkins: Yeah, the hitting of Hixie was what I meant. |
| 22:47 | TabAtkins | still would find it amusing to have <font> as a holder for @style, and it invalid everywhere else. |
| 23:01 | <zewt> | TabAtkins: though I'll confess to having considered using a bogus element name just to have a generic inline-block container, heh |
| 23:01 | <zewt> | thus far I've resisted |
| 23:01 | <TabAtkins> | <x-ib> |
| 23:04 | <zewt> | (personally I have no idea how you'd write a webpage without <div>, unless it means using <span> and stuffing display:block on it, and I don't know that that actually improves anything) |
| 23:04 | <TabAtkins> | It doesn't, obviously. ^_^ |
| 23:05 | <TabAtkins> | I've done div-less development before. You can get surprisingly far if you're lucky with the kinds of display you want. |
| 23:05 | <zewt> | i've briefly considered only using span (or div) for layout like that, and dismissed it as doing nothing but making me write more css rules |
| 23:05 | <zewt> | well, most of my pages are the sort that involve an artist handing me a PSD, heh |
| 23:06 | <zewt> | (for work, anyway) |
| 23:06 | <TabAtkins> | Yeah, for that case you're almost certainly going to end up with <div>s immediately. |
| 23:07 | <TabAtkins> | But doing it with the minimum of junk was always a fun challenge to me. |
| 23:08 | <zewt> | special thanks for random hover on gmail saying in big letters: Glenn Maynard (you) |
| 23:08 | <zewt> | apparently google thinks i need the reminder |
| 23:08 | <TabAtkins> | We're not saying you're dumb, but... |
| 23:09 | <zewt> | also gmail dropping the colored name thing is really annoying, since now I can't tell which Ian a post is from, from the message index |
| 23:09 | <zewt> | used to be all Hixies were the same color |
| 23:09 | <TabAtkins> | Man, I know. |
| 23:09 | <zewt> | it's the basic design flaw of web apps: when somebody decides it's time to "upgrade", you don't get any choice in the matter |