| 00:25 | <Dashiva> | othermaciej: Your mail about canvas suggestions seemed to suffer from candlejacking |
| 00:31 | <othermaciej> | Dashiva: what's "candlejacking"? |
| 00:32 | <Philip`> | The ever-reliable Urban Dictionary seems to suggest that term is used when sentences get cut off near the end |
| 00:33 | <othermaciej> | oops |
| 00:33 | <othermaciej> | I do that sometimes b/c I reply to things out of order and don't proofread |
| 00:38 | <jdandrea> | I can't find candlejacking in urbandictionary.com ... link? |
| 00:41 | <Philip`> | It has the terms "candlejack" and "candle jack" |
| 05:46 | <mpt> | "Google at present ever so slightly favours <b> over <strong> for weighing keywords and content on a page"? weird |
| 07:27 | <annevk> | http://mbro.belajar.net/2007/04/15/standar-web-idealis-vs-realistis/ might give feedback on HTML5 |
| 07:27 | <annevk> | I can't read it though |
| 07:28 | <annevk> | lang="id" |
| 07:38 | <annevk> | "Stoneship uses HTML5, to be precise. HTML5 is not a standard, it is not widely adopted, and there’s virtually no browser support yet. It is still usable, though, because HTML5, unlike XHTML2, is backward compatible: a HTML4 document can be a HTML5 one with very little changes (changing the doctype should suffice in most cases)." |
| 07:38 | <annevk> | from http://stoneship.org/journal/marked-up/ |
| 07:43 | <krijnh> | <meta charset="utf-8"> is supported by current browsers? |
| 07:43 | <annevk> | yes |
| 07:44 | <annevk> | because lots of people write this: <meta http-equiv=content-type value=text/html; charset=utf-8> |
| 07:44 | <krijnh> | Ah, makes sense |
| 07:44 | <annevk> | otherwise it wouldn't be in ;) :) |
| 07:44 | <krijnh> | I know |
| 07:44 | <krijnh> | :) |
| 07:48 | <krijnh> | Fatal Error: & not followed by # or name start. |
| 07:48 | <krijnh> | :S |
| 07:48 | <annevk> | Fatal Error: You're using XML |
| 07:48 | <krijnh> | No I'm not |
| 07:48 | <annevk> | oh, is this html5lib? |
| 07:49 | <annevk> | oh wait, the validator? |
| 07:49 | <krijnh> | No, the conformance checker ;) |
| 07:49 | <krijnh> | Ow, and scope isn't allowed on <th> elements? |
| 07:50 | <krijnh> | Damn, that would make my CMS non conformant then :( |
| 07:52 | <annevk> | scope is iirc |
| 07:52 | <krijnh> | Error: Attribute scope not allowed at this point; ignored. |
| 07:52 | <krijnh> | Perhaps it's not in the checker yet |
| 07:52 | <annevk> | are you using it correctly? |
| 07:52 | <annevk> | that could be true as well |
| 07:52 | <annevk> | (don't trust the validator!) |
| 07:52 | <krijnh> | <th scope="row"> |
| 07:53 | <krijnh> | The & problem was my fault btw ^ |
| 07:55 | <krijnh> | But an <a> isn't allowed directly inside a <div>? |
| 07:56 | <annevk> | either only block level or only inline |
| 07:56 | <annevk> | if you mix, you're wrong |
| 07:56 | <annevk> | (for the moment anyway) |
| 07:56 | <krijnh> | Ah, makes sense as well :) |
| 07:56 | <krijnh> | The document conforms to the machine-checkable conformance requirements for HTML5 (subject to the utter previewness of this service). |
| 07:56 | <krijnh> | \o/ |
| 07:56 | <annevk> | apparently it's hard to generate better error messages for that |
| 07:57 | <krijnh> | http://www.bvalmere.nl/ is HTML5 :) |
| 07:58 | <krijnh> | <input type=url> is slow in Opera btw |
| 07:58 | <krijnh> | (depends on your history settings I think) |
| 07:59 | <krijnh> | accept-charset for form is dropped, cause nobody uses it? |
| 07:59 | <annevk> | is it dropped? |
| 07:59 | <annevk> | why? |
| 07:59 | <krijnh> | Don't know |
| 07:59 | <annevk> | i don't think it is |
| 07:59 | <krijnh> | K |
| 07:59 | <annevk> | Web Forms 2 is a superset of HTML4 |
| 07:59 | <krijnh> | summary for <table> ? |
| 07:59 | <annevk> | it makes a few changes, such as deprecating size= |
| 08:00 | <annevk> | krijnh, yeah, that's dropped |
| 08:00 | <krijnh> | Why? |
| 08:00 | <krijnh> | My CMS auto generates those :/ |
| 08:00 | <krijnh> | "table has x columns and y rows" |
| 08:00 | <annevk> | it was thought of to be pretty useless |
| 08:00 | <annevk> | that would be a pretty useless summary |
| 08:00 | <annevk> | an example of a* |
| 08:00 | <krijnh> | Yeah, auto generated fluff most of the times doesn't make sense |
| 08:01 | <krijnh> | I think a caption is enough summary already |
| 08:01 | <krijnh> | Some sites say the summary attribute should contain a summary of the complexity of the table |
| 08:01 | <krijnh> | *could |
| 08:02 | <annevk> | some people are misinformed though |
| 08:02 | <krijnh> | Jup |
| 08:03 | <krijnh> | I thought it was Russ Weakley who said that |
| 08:03 | <annevk> | well, I once promoted XHTML2 |
| 08:03 | <krijnh> | Hehe |
| 08:04 | <virtuelv> | (w|m)ildly offtopic: Does anyone know of a blog-type CMS which doesn't suck, and actually allows me to output HTML |
| 08:05 | <krijnh> | I don't |
| 08:05 | <krijnh> | Mine doesn't allow HTML :) |
| 08:07 | <krijnh> | annevk: What's your opinion on http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/tabellen/layout/ ? |
| 08:07 | <virtuelv> | krijnh: more to the point, all of the CMSes I've seen try to f*ck around with strings |
| 08:08 | <krijnh> | Content is a string most of the times |
| 08:08 | <krijnh> | So it probably makes sense CMSes try to mess around with it |
| 08:09 | <krijnh> | http://www.usability.com.au/resources/tables.cfm#summary btw |
| 08:09 | <krijnh> | Brb |
| 08:09 | <virtuelv> | krijnh: no, it doesn't really make sense to treat markup as strings |
| 08:10 | <virtuelv> | the content of any given text node or an attribute value, perhaps, but not the markup |
| 08:37 | <annevk> | the serialization of markup is a string |
| 08:41 | <met_> | whats the font on '5>2' t-shirts? no delivery to czech republic, so i try to make it myself |
| 08:41 | <annevk> | Arial |
| 08:41 | <annevk> | but that's not that relevant I suppose |
| 08:41 | <annevk> | if you can make it prettier, go for it |
| 09:21 | <krijnh> | Courier! |
| 09:23 | <met_> | it's a guess? |
| 09:23 | <annevk> | i think that's a bad suggestion for a prettier font (meant as a joke) |
| 09:24 | <annevk> | (it really is Arial) |
| 09:35 | <Hixie> | annevk? |
| 09:35 | <annevk> | yeah |
| 09:35 | <Hixie> | annevk: where's the CSSOM you're writing? |
| 09:35 | Hixie | can't find it on dev.w3.org |
| 09:35 | <annevk> | http://dev.w3.org/cvsweb/csswg/cssom/ |
| 09:35 | <Hixie> | but the w3c date system makes everything impossible to find anyway, so |
| 09:35 | <Hixie> | cool |
| 09:35 | <Hixie> | thanks |
| 09:35 | <annevk> | I took your html5 example |
| 09:35 | <Hixie> | heh, there was already a CSS directory there :-P |
| 09:36 | <annevk> | oh :) |
| 09:36 | <annevk> | got to go |
| 10:45 | <hsivonen> | the versioning debate is hard, because the line of argument one might make depends on whether the Microsoft position is taken as a thing that cannot be changed |
| 10:46 | <hsivonen> | that is, whether to argue for minimizing the damage assuming that the damage is inevitable |
| 10:46 | <hsivonen> | or whether to argue for not inflicting the damage in the first place |
| 10:46 | <ROBOd> | hsivonen: correct, and i agree with Microsoft's position: they cannot "break the web" |
| 10:47 | <ROBOd> | that would be really Evil™ |
| 10:47 | <virtuelv> | I just don't understand that argument |
| 10:47 | <ROBOd> | virtuelv: why not? |
| 10:47 | <virtuelv> | 'Breaking the web' can happen in one of two ways |
| 10:47 | <virtuelv> | 1) Scripting interfaces break |
| 10:47 | <virtuelv> | authors will make use of whatever scripting interfaces they like, no matter what a DTD says |
| 10:48 | <virtuelv> | 2) CSS breaks |
| 10:48 | <virtuelv> | Microsoft can make a clean break[sic] starting with HTML5 |
| 10:48 | <hsivonen> | virtuelv: and they want to |
| 10:49 | <hsivonen> | virtuelv: the problem is that if IE8 makes a clean break with HTML5, Microsoft believes they can no longer change anything in IE9 |
| 10:49 | <hsivonen> | I understand why they think that way |
| 10:49 | <ROBOd> | hsivonen: that's not accurate |
| 10:50 | <hsivonen> | ROBOd: without a new mode |
| 10:50 | <ROBOd> | they can no longer change anything in IE 9, only *if* there are *many* pages relying on bugs in IE8 implementation of HTML5 |
| 10:50 | <ROBOd> | (many, according to their definition, of course) |
| 10:50 | <hsivonen> | ROBOd: right |
| 10:50 | <virtuelv> | hsivonen: IMHO, they're wrong |
| 10:51 | <ROBOd> | so... that will *only* happen if IE 9 comes after 5 years |
| 10:51 | <virtuelv> | the major thing here being if they actually bother to fix CSS |
| 10:51 | <hsivonen> | ROBOd: and they don't know how to measure the breakage, so they'd err on the side of assuming that any change breaks something |
| 10:51 | <ROBOd> | (or a long enough period) |
| 10:51 | <virtuelv> | if they ship IE8 being broken enough, then yes, they're going to be 'needing' versioning |
| 10:51 | <ROBOd> | hsivonen: i believe they know how to measure breakage |
| 10:51 | <virtuelv> | however, I think versioning is downright harmful |
| 10:52 | <virtuelv> | the problem with versioning is that other browser vendors will no longer be able to work on progressive enhancment |
| 10:52 | <hsivonen> | virtuelv: I think versioning is harmful, too |
| 10:53 | <hsivonen> | virtuelv: but if MS does it, I'd rather they did it the way I suggest ;-) |
| 10:53 | <hsivonen> | ROBOd: I thought Chris said they don't |
| 10:53 | <ROBOd> | hsivonen: hmm... maybe... i didn't read *all* his emails |
| 10:54 | <virtuelv> | hsivonen: since I'm not actively following any lists these days, mind giving me a two-line summary? |
| 10:54 | <ROBOd> | but they should be able to measure breakage, otherwise, it's pretty bad |
| 10:54 | <hsivonen> | virtuelv: of what I'm suggesting as the not-as-bad way? |
| 10:54 | <virtuelv> | hsivonen: yes |
| 10:55 | <hsivonen> | virtuelv: an attribute on the root element that declares the date on which the page designer tested the page against then-current browsers |
| 10:55 | <ROBOd> | (almost) the same as versioning, imho |
| 10:56 | <virtuelv> | hsivonen: and how is that going to be maintainable? |
| 10:56 | <hsivonen> | virtuelv: it isn't going to be less maintainable than having a flag that binds to IE versions rather than dates |
| 10:57 | <hsivonen> | virtuelv: if only IE uses the flag and documents their release dates, the alternatives are equally bad |
| 10:57 | <hsivonen> | virtuelv: however, a date levels the playing field a bit in case another vendor wants to play the MS game |
| 10:58 | <hsivonen> | virtuelv: and having it in an attribute minimizes the damage to intermediate tool vendors for whom doctypes and conditional comments suck big time |
| 10:59 | <hsivonen> | virtuelv: but regardless of what the flag is, having as many modes as IE versions will be bad for competition and for maintainability |
| 10:59 | <virtuelv> | hsivonen: I think you're asking us to choose between the black plague and cholera here |
| 11:00 | <Hixie> | it's exactly the same mistake they've made again and again with Word |
| 11:00 | <hsivonen> | virtuelv, Hixie: agreed on both counts |
| 11:00 | <Hixie> | and given the advantage it's given them there, and how they're losing the web, i don't see why microsoft _wouldn't_ explicitly and intentionally go down this route |
| 11:00 | <Hixie> | for HTML |
| 11:01 | <Hixie> | it's possible chris doesn't realise he's doing it, though |
| 11:01 | <Hixie> | and that he honestly believes it's the best thing for his users |
| 11:01 | <hsivonen> | Hixie: which is why I'm in the damage minimization mode as opposed to the let's-not-even-think-about-it mode |
| 11:01 | zcorpan | considers advocating authors to use quirks mode |
| 11:01 | <Hixie> | hsivonen: yeah, you and lachy both |
| 11:02 | Hixie | doesn't even know how to do damage limitation at this stage |
| 11:02 | <Hixie> | i'm more concerned with saving our short doctype |
| 11:02 | <virtuelv> | let's go for damage maximization, then :) |
| 11:02 | <hsivonen> | Hixie: out of curiosity, do you think Lachy and I are arguing in favor of MS? |
| 11:02 | <Hixie> | what does "in favour of MS" mean? |
| 11:03 | <hsivonen> | Hixie: I'm concerned about that, too. (hence, attribute) |
| 11:03 | <Hixie> | yeah |
| 11:03 | <Hixie> | i think the attribute with a date is the better plan |
| 11:03 | <Hixie> | theoretically at least |
| 11:03 | <Hixie> | but if we do that i'm sure that people will just say tested-on="9999-12-31" |
| 11:04 | <virtuelv> | Hixie: I quite agree |
| 11:04 | <Hixie> | and we'll be back to square 1 |
| 11:04 | <Hixie> | basically any system where you can predict the future values will be gamed |
| 11:04 | <zcorpan> | Hixie: that should be equivalent to not specifying it at all |
| 11:04 | <Hixie> | zcorpan: and trigger legacy mode? ("quirks v2"?) |
| 11:05 | <virtuelv> | zcorpan: I think that's rather the point. The attribute won't matter or be respected by application authors anyway |
| 11:05 | <virtuelv> | and you'll have the same augmentation you have now, but you'll have one more useless attribute to stick in the document |
| 11:05 | <hsivonen> | whee! arms race time! browsers embarassing authors who specify a date ahead of wall-clock |
| 11:05 | <zcorpan> | Hixie: no, latest mode. (i haven't followed the whole discussion here so i may be missing something) |
| 11:06 | <Hixie> | hsivonen: can't do that either, computer clocks are notoriously unreliable |
| 11:06 | virtuelv | would just rather see Microsoft actually adhering to both HTML5 and CSS2.1 |
| 11:06 | <Hixie> | zcorpan: right. anything that triggers a moving target will end up having to be frozen. |
| 11:06 | <hsivonen> | virtuelv: don't we all? |
| 11:07 | <Hixie> | zcorpan: what today is called "standards mode" is exactly that -- "use the latest standards, don't do any quirks, break me if you want to fix a bug" |
| 11:07 | <virtuelv> | we do, but I'll say that budging to microsoft on this one is going to cost the web big-time in the years to come |
| 11:07 | <Hixie> | zcorpan: but now enough people use it that Microsoft feel they can't change rendering in that mode, and hence it now becomes quirks v2 |
| 11:07 | <virtuelv> | because we'll be no better off tomorrow than we were three years ago |
| 11:07 | <zcorpan> | Hixie: yeah :( |
| 11:07 | <virtuelv> | Hixie: wouldn't it then be prudent for them to have a 'real standards mode'? |
| 11:08 | <Hixie> | zcorpan: if we have a system that can be gamed, then authors will ask for "latest mode", gaming the system, other authors will copy that, and we'll end up with yet another quirks mdoe trigger, this time quirks v3 |
| 11:08 | <hsivonen> | virtuelv: the problem is that the WG does not have a mechanism to enforce compliance on the part of Microsoft |
| 11:08 | <Hixie> | virtuelv: it would be prudent of any browser vendor to not have rendering modes at all and just have a spec that can be followed to render all the web |
| 11:08 | <Hixie> | virtuelv: but the working assumption here is that microsoft disagree with what would be prudent |
| 11:09 | <virtuelv> | Hixie: not that I disagree, but noone's done it right. Ever. |
| 11:09 | <virtuelv> | hsivonen: I know. It's depressing |
| 11:09 | <Hixie> | virtuelv: well there was a time where we wanted to fix the browsers instead of hte specs, and that's how we ended up with quirks vs standards |
| 11:09 | <Hixie> | virtuelv: but now, notwithstanding that disaster, all the browsers are doing what i describe |
| 11:10 | <Hixie> | virtuelv: only microsoft is suggesting doing something else in future. |
| 11:11 | <zcorpan> | not so long ago, i thought html had a bright future. i'm not so sure anymore :( |
| 11:11 | <Hixie> | it has a fine future, so long as microsoft keep losing market share |
| 11:11 | <zcorpan> | yeah, that's out only hope |
| 11:12 | <zcorpan> | s/out/our |
| 11:12 | <virtuelv> | either keep losing market share, or get their act together |
| 11:14 | <krijnh> | Or both |
| 11:16 | <virtuelv> | in Utopia, no browser has more than ~30% |
| 11:24 | <hsivonen> | view source at http://diveintomark.org/archives/2007/04/15/ejookashun and look for <dialog></p> |
| 11:25 | <mpt> | virtuelv, I've long said that to anyone who will listen (which is hardly anyone:-) |
| 11:25 | <krijnh> | hsivonen: why's that? |
| 11:25 | <hsivonen> | krijnh: trying to find out if its WP or Gecko |
| 11:26 | <krijnh> | I see it 4 times in Opera |
| 11:26 | <hsivonen> | krijnh: seems to be in the real source |
| 11:26 | <krijnh> | Jep |
| 11:26 | <mpt> | <p><dialog></p> |
| 11:26 | <krijnh> | And <p></dialog></p> |
| 11:26 | <krijnh> | Two times |
| 11:26 | <krijnh> | Funny stuff :) |
| 11:27 | <mpt> | It's probably doubling as a testcase for Mark to fix that |
| 11:27 | <krijnh> | It's probably WordPress putting <p> </p> around it |
| 11:27 | <mpt> | yes |
| 11:27 | <krijnh> | Doh |
| 11:28 | <krijnh> | The <p><i>One minute later…</i></p> could be put inside the <dialog> right? |
| 11:28 | <Hixie> | it's been suggested |
| 11:28 | <krijnh> | With an <li> or something? Or isn't that allowed yet? |
| 11:28 | <Hixie> | haven't dealt with that feedback yet |
| 11:29 | <Hixie> | i have two main things to do before i start replying to feedback |
| 11:29 | <Hixie> | one is finish off the first draft of the browsing context section |
| 11:29 | <Hixie> | and the other is figuring out some alternative to the <switch> proposl |
| 11:29 | <Hixie> | one that actually works |
| 11:29 | <Hixie> | some mechanic that conveys the semantic of "only one of these options is active" |
| 11:30 | <Hixie> | so that, e.g., you can have one document with a login form and a logged in form, and have a UA never show both |
| 11:30 | <Hixie> | or so you can have two <video> elements and an <img> element, and have them all right there active in the DOM, but only one rendering at any one time, ever |
| 11:31 | <Hixie> | right now there's no way to do this |
| 11:31 | <Hixie> | no way to say "this is simply not active, not relevant, don't show it" |
| 11:31 | <krijnh> | Only with CSS |
| 11:32 | <Hixie> | CSS is about presentation |
| 11:32 | <krijnh> | How would that be backwards compatible? |
| 11:32 | <Hixie> | i'm talking about the actual semantic |
| 11:32 | <Hixie> | dunno |
| 11:32 | <Hixie> | haven't found a solution yet |
| 11:32 | <krijnh> | Hmm |
| 11:32 | <krijnh> | But you do think that should be possible in HTML? |
| 11:32 | <Hixie> | i think it's a feature that is missing and is very important |
| 11:33 | <Hixie> | i see people working around it all the time |
| 11:33 | <krijnh> | I mostly work around it server side |
| 11:33 | <hsivonen> | Hixie: why wouldn't a login form state be tightly coupled with server-side page round tripping or tightly coupled with XHR and scripted DOM manipulation? |
| 11:33 | <mpt> | krijnh, Mark's dialog also evokes that unusual idea someone posted to the whatwg list a month or so ago, about replacing <dl> with <table> |
| 11:33 | <Hixie> | hsivonen: why should it be? |
| 11:34 | <mpt> | dt -> th, dd -> td |
| 11:34 | <krijnh> | Yeah, why not :) |
| 11:34 | <hsivonen> | Hixie: to make sure the state and login processing are tied together |
| 11:35 | <Hixie> | hsivonen: but why should the state manipulation be so complicated as to require a complete change to the dom? |
| 11:35 | <krijnh> | mpt: I like <dl> better though |
| 11:35 | <Hixie> | hsivonen: shouldn't, once you've logged in, the change simply be an attribute change somewhere? (or equivalent) |
| 11:35 | <mpt> | I'd like <dl> a whole lot better if <dl compact> was still possible |
| 11:35 | <krijnh> | Yeah, me too |
| 11:35 | <Hixie> | hsivonen: the current system leads to people putting all the content on the page but with display:none |
| 11:35 | <Hixie> | display:none doesn't mean anything |
| 11:36 | <Hixie> | it doesn't hide the contents except in the default case of css being enabled and honoured |
| 11:36 | <mpt> | But then it demonstrates the table-ness again -- you have terms and you have definitions, but where do you put the pronunciation, and the etymology, and the part of speech... |
| 11:36 | <hsivonen> | Hixie: I see your point. |
| 11:36 | <krijnh> | I don't do that, if it shouldn't be there, it shouldn't be there |
| 11:36 | <hsivonen> | Hixie: otoh, any new solution has the same problem as far as legacy uas go |
| 11:37 | <hsivonen> | krijnh: how do you load DOM templates? |
| 11:37 | <krijnh> | Most of the times the ugly way |
| 11:37 | <krijnh> | With some server side language along with it |
| 11:37 | <Hixie> | hsivonen: yeah, sometimes the solutions have poor legacy answers (like input type=datetime), but we still need them for the future, and script can handle most legacy cases |
| 11:37 | <hsivonen> | krijnh: what's the ugly way? |
| 11:38 | <krijnh> | I'm a bozo most of the times, if that's what you mean :) |
| 11:38 | <hsivonen> | Hixie: ok |
| 11:38 | <hsivonen> | krijnh: I mean: you have an app with repeating stuff, don't you put a display:none; copy of the repeating part somewhere so that you can clone it easily? |
| 11:39 | <krijnh> | No |
| 11:39 | <krijnh> | I try to avoid having to use display: none |
| 11:39 | <zcorpan> | couldn't <menu type=popup> be abused for that purpose? (not saying it should) |
| 11:39 | <krijnh> | hsivonen: Perhaps I'm misunderstanding you |
| 11:41 | <zcorpan> | the idea is something like <switch><section>A</section><section>B</section></switch>, right? |
| 11:42 | <krijnh> | And how do you choose the 'active' one? |
| 11:42 | <zcorpan> | perhaps with normal links |
| 11:42 | <krijnh> | I only see a use for tabs or something |
| 11:42 | <Hixie> | yeah e.g.: |
| 11:43 | <zcorpan> | <ul><li><a href="#a">A</a><li><a href="#b">B</a></ul> |
| 11:43 | <Hixie> | <switch> <section> login page </section> <section> game </section> <section> game over screen </section> </switch> |
| 11:43 | <Hixie> | with script switching between them |
| 11:43 | <Hixie> | tabs would specifically _not_ be a good use of this |
| 11:43 | <Hixie> | because the fact that tabs are displayed one after the other is an artifact of presentation |
| 11:43 | <krijnh> | This could be abused for it then |
| 11:43 | <Hixie> | nothing would stop a ui from showing all the tabs at once |
| 11:43 | <Hixie> | yes |
| 11:43 | <zcorpan> | oh |
| 11:45 | <zcorpan> | so a link pointing to an inactive section wouldn't make the section be relevant when the link is followed? |
| 11:45 | <hsivonen> | hmm. regarding a date-based switch and gaming it with future dates: a conformance checker could be trusted to know what today's date is with 24h accuracy. therefore, future dates could be non-conforming |
| 11:46 | <krijnh> | And make UAs not render documents with future dates? |
| 11:47 | <Hixie> | zcorpan: like i said, i haven't got a solution for this yet. so i don't know :-) |
| 11:47 | <hsivonen> | krijnh: Hixie said that wouldn't work because end user clocks are inaccurate |
| 11:47 | <Hixie> | zcorpan: do you think it should? what's the use case? |
| 11:47 | <krijnh> | "This page is optimized for 1024x768 and the year 2064" :) |
| 11:48 | <Hixie> | hsivonen: over 93% of pages are non-conforming |
| 11:48 | <krijnh> | How would a UA know which section is active? An attribute on <switch> or on <section> ? |
| 11:48 | <krijnh> | And shouldn't that attribute be set with JS or server side code anyway? |
| 11:49 | <hsivonen> | Hixie: yes, but the kind of people who think they can outsmart the switch are the kind of people who want a conformance checker to say that they conform |
| 11:49 | <Hixie> | krijnh: i have no idea, that's why i need to look at this to get ideas |
| 11:49 | <zcorpan> | Hixie: well. tabs. :) |
| 11:49 | <Hixie> | hsivonen: no, they're people like you, me and lachy, e.g. writing test case, who want to always have the page use standards mode |
| 11:50 | <Hixie> | hsivonen: without having to change the date in the test every week |
| 11:50 | <Hixie> | zcorpan: quite |
| 11:51 | <zcorpan> | Hixie: if it did, it would be easy to implement tabs that fallback to css or js for legacy |
| 11:51 | <Hixie> | zcorpan: tabs are a presentation idiom, they don't belong in html |
| 11:52 | <zcorpan> | Hixie: ditto a table of contents? |
| 11:52 | <Hixie> | zcorpan: whether a series of control groupings (fieldsets) get rendered as tabs or as side by side boxes is completely presentational |
| 11:52 | <Hixie> | zcorpan: table of contents? |
| 11:52 | <zcorpan> | i see a tab bar pretty similar to a list of toc |
| 11:53 | <hsivonen> | Hixie: well, yeah, but you, me and lachy (or the people on this channel basically) are perhaps not the optimization target when the alternative is everyone else. :-( |
| 11:53 | <zcorpan> | you don't need the toc list, it is implied by the document headings (the ua can generate one itself) |
| 11:53 | <Hixie> | zcorpan: yeah, it's a fair comparison. and with a toc the sections are always visible. |
| 11:53 | <zcorpan> | Hixie: indeed |
| 11:53 | <Hixie> | hsivonen: my point is that making it not conform wouldn't stop us, therefore it wouldn't solve the problem |
| 11:54 | <Hixie> | hsivonen: since we're exactly the people who copy paste us |
| 11:54 | <Hixie> | er |
| 11:54 | <Hixie> | who people copy and paste, rather |
| 11:54 | <zcorpan> | people would use script to insert today's date anyway |
| 11:54 | <zcorpan> | server side |
| 11:55 | <hsivonen> | zcorpan: that would solve the cargo cultist problem for cargo cultists who don't |
| 11:56 | <zcorpan> | hsivonen: sorry i don't follow |
| 11:57 | <hsivonen> | zcorpan: if we had server-side scripts updating test cases, cargo cultists who copy and paste our stuff would not have their pasted date auto-increment |
| 11:58 | <zcorpan> | ok |
| 12:21 | <zcorpan> | oh well, a filter couldn't wipe out +1s anyway, given we now have +100,000s |
| 18:42 | <jdandrea> | Am I reading the "Picture-perfect rendering" msg timeline correctly (over on public-html⊙wo)? |
| 18:42 | <jdandrea> | CWilson sez there's some vagueness within HTML5. Hixie asks for concrete examples. CWilson offers up <canvas> - no rendering rules to get pixel-perfect rendering. Hixie asks for more specifics. |
| 18:43 | <jdandrea> | TV Raman notes pixel-perfect rendering was never HTML's goal and should not become its goal ... and then CWilson agrees. |
| 18:50 | <zcorpan> | jdandrea: yes |
| 18:53 | <Philip`> | Then people think "HTML is not about pixel-perfect rendering" entails "HTML should be contain <canvas>", as opposed to concluding "<canvas> should not define pixel-perfect rendering" (which is the current situation) |
| 18:53 | <Philip`> | s/should be/should not/ |
| 18:54 | <zcorpan> | indeed |
| 18:56 | <Philip`> | (I think my response (of the (non-pixel-perfect) specifics that I believe are missing) fell out of the threading - does anyone happen to know of a way to write from Gmail via mailto: links while preserving References?) |
| 18:57 | <zcorpan> | include the relevant headers in the mailto: link, perhaps? |
| 18:58 | <jdandrea> | Philip `: Exactly. |
| 18:58 | <jdandrea> | (wrt the conclusion/perception) |
| 18:58 | <zcorpan> | not sure if the gmail web interface preserves them, though. if it doesn't then enable pop and use an email client that does |