| 04:58 | <cardona507> | does anyone know of a page that shows what support safari mobile has for html5? |
| 07:50 | <jgraham> | gsnedders: It is way less ugly (and probably less inefficient) than your code |
| 09:33 | <annevk2> | it seems Microsoft is using the DOM consistency principle in the opposite direction |
| 09:33 | <annevk2> | I thought it was only about HTML documents giving a DOM that is as close as possible to what XHTML would generate for equivalent input? |
| 09:39 | <hsivonen> | annevk2: I guess I should reply, but first, I'm doing to debug some software to avoid a situation where I get tarpitted writing too much public-html mail |
| 09:42 | <hsivonen> | s/doing/going/ |
| 09:55 | <hsivonen> | what was the right gesture for getting the inverse link menu on the spec? |
| 09:56 | <hsivonen> | option-doubleclick seems to be the annotation UI |
| 09:56 | <Hixie> | inverse link menu? |
| 09:56 | <Hixie> | oh |
| 09:56 | <Hixie> | click on a dfn |
| 09:56 | <Hixie> | has to be index or complete.html |
| 09:59 | <hsivonen> | Hixie: thanks. got it after reloading and waiting for some beach balling |
| 09:59 | hsivonen | tries to locate the processing model for <base> but is failing |
| 10:00 | <mikekelly> | Hi Ian |
| 10:01 | zcorpan_ | notes that http://www.w3.org/standards/techs/css at the bottom includes abandoned WDs |
| 10:02 | <hsivonen> | does the CSS WG ever bother to tombstone abandoned WDs as Notes? |
| 10:02 | <hsivonen> | it seems to me that WGs still in charter don't bother to bury their abandoned docs |
| 10:03 | <hsivonen> | just before the site update, the TR page had various obviously old "requirements" WDs |
| 10:03 | <hsivonen> | where the stuff the requirements were for was already at REC |
| 10:05 | <mikekelly> | Hixie: I think I can make a good case for either changing the significance of @type for out-going links or adding in new attributes for conneg |
| 10:06 | <mikekelly> | I'm not the only person running into this problem: http://tech.groups.yahoo.com/group/rest-discuss/message/13871 http://tech.groups.yahoo.com/group/rest-discuss/message/13866 |
| 10:07 | <mikekelly> | I mean - if you look at the HTTP spec and the way that @type is defined |
| 10:08 | <mikekelly> | it really doesn't make sense that @type isn't used to modify the Accept header |
| 10:10 | <mikekelly> | since the purpose of @type is to infer what should be expected from a response in a non-authoratative way.. then it seems to make sense to also modify the out-going request accordingly so that the Accept header indicates this context to the destination server |
| 10:11 | <mikekelly> | there's nothing authorative about the Accept header - the server is free to disregard it completely and return whatever content-type it pleases, this doesn't break clients or HTTP spec |
| 10:12 | <mikekelly> | what it does do is give the ability for me to chose whether or not I want to use HTTP conneg in my html driven applications |
| 10:12 | <zcorpan_> | mikekelly: have you lobbied browser vendors whether they're interested in implementing? |
| 10:13 | <mikekelly> | I would prefer to do that after the HTML spec was changed |
| 10:13 | <hsivonen> | hi, mookid |
| 10:13 | <mikekelly> | hello |
| 10:14 | <zcorpan_> | why? |
| 10:14 | <mikekelly> | because that is the most efficient path to the objective |
| 10:14 | <mikekelly> | I don't know anything about who's who in browsers |
| 10:15 | <mikekelly> | this is an issue with HTML first and foremost |
| 10:15 | <zcorpan_> | my experience is different; in many cases specs don't change until browsers have changed |
| 10:15 | <zcorpan_> | see http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 10:16 | <mikekelly> | so there's no parts of HTML5 that have/are working this way |
| 10:16 | <mikekelly> | ? |
| 10:17 | <mikekelly> | it's pretty crazy that browsers have so much control of this situation |
| 10:17 | <zcorpan_> | in general, and especially at this stage, things are only added to html5 if it's clear that browsers are interested in implementing |
| 10:17 | <mikekelly> | that's pretty sad state of affairs for something this important. |
| 10:17 | <zcorpan_> | if it turns out later that browsers haven't implemented something, it'll be dropped |
| 10:18 | <gsnedders|work> | mikekelly: You can add it to the spec… and if browsers don't implement it, you've gained nothing. |
| 10:18 | <zcorpan_> | indeed |
| 10:18 | <mikekelly> | at least if it is changed in the spec |
| 10:18 | <mikekelly> | I have something to reference bugs against |
| 10:18 | <mikekelly> | rather than just have browsers go 'well wtf is this I dont care what you want its not in the spec go away' |
| 10:19 | <mikekelly> | which is exactly what will happen and you know it. |
| 10:19 | <zcorpan_> | that's not how opera react at least |
| 10:19 | <gsnedders|work> | mikekelly: Whether something is in a spec has little relevance to whether we will support it or not |
| 10:19 | <mikekelly> | oh well that's ok then |
| 10:19 | <zcorpan_> | if we see something useful, we'll want to implement it regardless of whether it's in a spec or not |
| 10:19 | <zcorpan_> | if we're going to implement it, we want it specced, too |
| 10:20 | <mikekelly> | yeah - it's not practical to expect uptake unless these mechanisms are implemented across the board |
| 10:20 | <mikekelly> | it doesn't work like that |
| 10:20 | <mikekelly> | which is the WHOLE REASON for specs in the first place |
| 10:20 | <mikekelly> | otherwise what is the need for gimpy specs |
| 10:20 | <mikekelly> | if all that matters is what the general consensus is..? |
| 10:21 | <zcorpan_> | the reason for specs is interop and reduce need for expensive reverse engineering :) |
| 10:21 | <annevk2> | hsivonen, I think the requirements for <base> were removed from the spec and Hixie expected them to be covered by iri-bis or some such |
| 10:21 | <mikekelly> | interop.. well content negotiation is a pretty big deal in terms of interop |
| 10:21 | <annevk2> | hsivonen, however that seems somewhat wrong, I recall I emailed about that, but I'm not sure given that Hixie recently went all the way to zero |
| 10:22 | <mikekelly> | this is actually pretty sad - how long is the human race expected to put up the mess you guys are going to produce? |
| 10:23 | <mikekelly> | it's all very clever for you to be like "well if we add it to the spec and it doesnt get implemented it doesnt matter - so go get it implemented first" |
| 10:23 | <mikekelly> | very smart - I see what you're doing there |
| 10:24 | <zcorpan_> | that's how most new features in html5 were added |
| 10:24 | <mikekelly> | well that's bs quite frankly |
| 10:24 | <mikekelly> | the spec should be adjusted to suit applicability of the markup |
| 10:24 | <mikekelly> | if browsers don't conform they are BROKEN |
| 10:24 | <mikekelly> | and bugs should be logged against that |
| 10:26 | <mikekelly> | browsers are *just* a client, the fact that you have your little oligopoly shouldn't give you the right to strong-arm features in and out |
| 10:28 | <zcorpan_> | certainly there are other implementors other than browsers |
| 10:28 | <mikekelly> | well then - the spec should say what is most appropriate in the context of web architecture |
| 10:28 | <zcorpan_> | if you can get your feature implemented somewhere, then that might be good enough to get it added to html5 |
| 10:28 | <mikekelly> | and if browsers fail to comply then they are broken |
| 10:28 | <mikekelly> | it's really very simple. |
| 10:29 | <zcorpan_> | the spec is not of much use if it says to do something that implementors don't want to do |
| 10:29 | <mikekelly> | bullshit. |
| 10:29 | <mikekelly> | the clients are not much use if they don't conform to the spec |
| 10:29 | <mikekelly> | you have that totally the wrong way round |
| 10:30 | <zcorpan_> | well, clearly we have different points of view on the matter :) |
| 10:30 | <mikekelly> | I wonder why.. |
| 10:30 | <mikekelly> | what a joke. |
| 10:30 | <zcorpan_> | specs and implementations should converge on a single behavior |
| 10:30 | <mikekelly> | no |
| 10:30 | <zcorpan_> | no? |
| 10:31 | <mikekelly> | the spec provides the convergence |
| 10:31 | <mikekelly> | that is its purpose |
| 10:31 | jgraham | wonders what the use of deliberatly speccing something that no one will implement is |
| 10:31 | <mikekelly> | if you don't converge |
| 10:31 | <mikekelly> | you are BROKEN |
| 10:31 | <mikekelly> | jgraham: because if 'no one' will implement it |
| 10:31 | <mikekelly> | then 'no one' is a client that actually works |
| 10:32 | <jgraham> | That was a word game not a reason |
| 10:32 | <mikekelly> | yeah yeah |
| 10:32 | <mikekelly> | word game |
| 10:32 | <mikekelly> | whatever if you are seriously trying to tell me you don't understand what I am saying then you definitely shouldn't be at the level of responsibility you apparently have |
| 10:33 | <jgraham> | It seems like the main reason is so that you can have a feeling of self-satisfaction about being on the self-stated moral high ground |
| 10:33 | <mikekelly> | that is not a coherent form of governance |
| 10:33 | jgraham | has no responsibility for anything much |
| 10:33 | <mikekelly> | it's just appealing to your insufficiecies |
| 10:33 | <mikekelly> | guess what |
| 10:33 | <mikekelly> | progress hurts |
| 10:34 | <mikekelly> | if you get accomodated you will continue, as a group, to take the piss and do whatever you want |
| 10:34 | <mikekelly> | which is a bullshit situation, you should read the fking spec and implement it properly |
| 10:34 | <mikekelly> | I fail to see how and why it should be any other way |
| 10:35 | <mikekelly> | at least from the perspective of society |
| 10:35 | <mikekelly> | rather than |
| 10:35 | <mikekelly> | 'the guys who work for browsers and want things they way they think it should be' |
| 10:35 | <zcorpan_> | my job is to read the fking spec and make sure opera implements it properly (for <video> atm) |
| 10:35 | <mikekelly> | yeah - those all important video tags |
| 10:35 | <mikekelly> | thank god for them |
| 10:35 | <mikekelly> | can't wait for video in web pages |
| 10:36 | <zcorpan_> | glad to hear it :) |
| 10:36 | <mikekelly> | ... |
| 10:37 | <mikekelly> | jgraham: it's not moral it's common sense |
| 10:37 | <mikekelly> | the spec should be there to serve as a guide - once a descision is made the spec changes and clients have to conform |
| 10:37 | <mikekelly> | if tha twas actually respected maybe a descision could be made on codecs |
| 10:37 | <mikekelly> | and you guys can get your act togather |
| 10:38 | <mikekelly> | rather than bitching and pulling hair and getting the world NOWHERE |
| 10:38 | <AryehGregor> | mikekelly, the problem is, clients can't be forced to conform. |
| 10:38 | <AryehGregor> | And the reality is they won't unless they want to. |
| 10:38 | <AryehGregor> | This was demonstrated pretty conclusively by, e.g., XHTML . |
| 10:38 | <AryehGregor> | 2. |
| 10:38 | <mikekelly> | yes they can that's what bugs are supposed to be logged for |
| 10:38 | <AryehGregor> | XHTML 2. |
| 10:39 | <AryehGregor> | mikekelly, can be closed WONTFIX. |
| 10:39 | <AryehGregor> | The W3C can't force anyone to follow its specs. |
| 10:39 | <mikekelly> | yeah XHTML2 doesn't work in the context of |
| 10:39 | <AryehGregor> | Historically, browsers often ignore parts of specs they don't want to implement. |
| 10:39 | <mikekelly> | browser guys going |
| 10:39 | <mikekelly> | "hmm... HTML5 is a gang bang where we just do what we want.. XHTML seems like a painin the arse and my opinion won't be importan.." |
| 10:39 | <mikekelly> | hmm... |
| 10:39 | <mikekelly> | I wonder.. |
| 10:40 | <mikekelly> | that is why |
| 10:40 | <AryehGregor> | . . . |
| 10:40 | <mikekelly> | dress it up how you want that's the blatant reality |
| 10:40 | <AryehGregor> | The reality is there's no point in speccing something that won't be implemented. |
| 10:40 | <mikekelly> | in the context of some slut called HTML5 |
| 10:40 | <AryehGregor> | Browser implementers can and do say "no, we won't implement that because the spec is stupid". |
| 10:40 | <AryehGregor> | They don't blindly follow specs. |
| 10:40 | <AryehGregor> | So there's no point in writing a spec unless you think they'll follow it. |
| 10:40 | <mikekelly> | ok well then thye are shockingly bad clients |
| 10:41 | <mikekelly> | that is not an acceptable situation |
| 10:41 | <mikekelly> | given how much social responsibility they have |
| 10:41 | <AryehGregor> | Okay, well, so what do you propose we do? |
| 10:41 | <mikekelly> | DEFINE A SPEC |
| 10:41 | <mikekelly> | AND STICK TO IT |
| 10:41 | <AryehGregor> | "We" as in spec writers. |
| 10:41 | <AryehGregor> | We can't "stick to it" if we aren't writing the browsers. |
| 10:41 | <mikekelly> | if clients don't stick to it |
| 10:41 | <mikekelly> | log bugs |
| 10:41 | <AryehGregor> | And if they refuse to fix them? |
| 10:41 | <mikekelly> | they are buggy clients |
| 10:42 | <AryehGregor> | Okay, great, so then what? |
| 10:42 | <AryehGregor> | You haven't gained anything except the right to call them buggy. |
| 10:42 | <AryehGregor> | That doesn't help anyone much. |
| 10:42 | <mikekelly> | that's something |
| 10:42 | <mikekelly> | at least that gives some leverage |
| 10:42 | <mikekelly> | whether that is ever resolved is another issue |
| 10:42 | <mikekelly> | not for HTML spec to worry about |
| 10:42 | <AryehGregor> | Surely the only important one? |
| 10:42 | <mikekelly> | nol.. |
| 10:42 | <mikekelly> | that is a practicality |
| 10:43 | <mikekelly> | and a completely differnet governance issue |
| 10:43 | <AryehGregor> | So you're saying specs should spec what's right in theory, while totally ignoring practical utility? |
| 10:43 | <mikekelly> | there is no need for them to be coupled together |
| 10:43 | <mikekelly> | other than your desire to be powerful |
| 10:43 | <AryehGregor> | Okay, well, we're going to have to just agree to disagree. |
| 10:43 | <mikekelly> | oh OK THEN |
| 10:43 | <mikekelly> | nevemrind your social responsibility |
| 10:43 | <mikekelly> | we'll just disagree. |
| 10:44 | <mikekelly> | good grief. |
| 10:45 | <AryehGregor> | <zcorpan_> that's not how opera react at least <-- So how does Opera react to bug reports? Because I filed one a while back on how input validation is unusable on password fields in Opera (prints the entered value in plaintext), but never got a response. |
| 10:45 | <mikekelly> | do you not even understand how some people might read you saying that and take exception to it? |
| 10:46 | <jgraham> | AryehGregor: Do you have a bug number? |
| 10:46 | <AryehGregor> | mikekelly, I understand, and think they're simply wrong. Anyone who thinks specs have moral authority, rather than merely being useful tools that improve consistency and thereby help out users and authors, is living in a fantasy world. |
| 10:47 | <mikekelly> | a fantasy world where browser developers have some level of humility? |
| 10:47 | <mikekelly> | I see how that works |
| 10:47 | <AryehGregor> | A fantasy world where browser developers have no right to an independent opinion on what's best for their users. |
| 10:47 | <mikekelly> | what? |
| 10:47 | <AryehGregor> | Where they won't ignore specs that they think are bad. |
| 10:48 | <AryehGregor> | jgraham, DSK-262266 |
| 10:48 | <mikekelly> | they have no right to that but yet they can opt to completely ignore the spec they are supposed to conform to? |
| 10:48 | <mikekelly> | that doesnt make any sense |
| 10:48 | <AryehGregor> | Who says they're supposed to conform to it? |
| 10:48 | <AryehGregor> | Is the W3C invested with God-given moral authority? |
| 10:48 | <mikekelly> | good lord. |
| 10:48 | <AryehGregor> | Are you ready to agree to disagree yet? :) |
| 10:48 | <mikekelly> | I'd rather they have authority than a bunch of uppity browser devs |
| 10:48 | <mikekelly> | at least there's some collective process invovled |
| 10:48 | <AryehGregor> | Why? |
| 10:49 | <mikekelly> | because other parties can direct the technology |
| 10:49 | <AryehGregor> | Why is that better than competition? |
| 10:49 | <mikekelly> | and not just dorks on the client side |
| 10:49 | <mikekelly> | HTML is releveant to server side |
| 10:49 | <mikekelly> | and to intemediaries aswell |
| 10:49 | <mikekelly> | because HTML governs the behaviour between client and server |
| 10:49 | <mikekelly> | so if you're building intermediaries like caches |
| 10:49 | <mikekelly> | that has a direct effect on how the systems behave |
| 10:49 | <mikekelly> | and what you can achieve with your technology |
| 10:50 | <mikekelly> | but you, as a browser vendor, are very unlikely to appreciate that |
| 10:50 | <mikekelly> | you need guidance |
| 10:50 | <mikekelly> | and help |
| 10:50 | <AryehGregor> | Well, whatever. This is pointless. I'd tell you to go join the XHTML Working Group, except the W3C has recognized that approach is pointless and is discontinuing it. |
| 10:50 | <mikekelly> | it's completely impractical to expect you to appreciate these itricacies |
| 10:50 | <mikekelly> | yeah POINTLESS |
| 10:50 | <mikekelly> | oh well |
| 10:50 | <AryehGregor> | I'm not a browser vendor, by the way. |
| 10:50 | <AryehGregor> | I'm a web developer. |
| 10:50 | <mikekelly> | right ok |
| 10:50 | <mikekelly> | well then your response to my explanation there is |
| 10:50 | <mikekelly> | "this is pointless" |
| 10:50 | <mikekelly> | terrific. |
| 10:51 | <mikekelly> | this is not some stupid little dork game we are playing - this is directly affecting society |
| 10:52 | <mikekelly> | I think, if what youa re describing is true, that the governance around HTML5 is seriously wrong |
| 10:52 | <mikekelly> | from a societal perspective |
| 10:52 | <mikekelly> | not from a browser vendor perspective. |
| 10:53 | <mikekelly> | and that is a pretty big assertion so you'd do well to provide evidence that is not the case. |
| 10:54 | <mikekelly> | pelase. |
| 10:54 | <mikekelly> | please^ |
| 10:56 | <AryehGregor> | All I can say is that as a web developer, I think the HTML5 process has produced a drastically better standard much faster than any other standards process I've been involved with. |
| 10:56 | <mikekelly> | if you are referring to XHTML2 it is hardly suprising that struggled when HTML5 provided an excuse to follow a path of less resistence |
| 10:56 | <mikekelly> | that is what happened. |
| 10:57 | <mikekelly> | not only less resistence - more power |
| 10:57 | <mikekelly> | pretty sad. |
| 10:57 | <mikekelly> | but at least we have video tags, I guess. |
| 10:58 | <mikekelly> | XHTML = organic food shop, HTML5 = McDonalds |
| 10:59 | <mikekelly> | guess where the kids go. |
| 11:14 | <annevk2> | lol |
| 11:16 | <mikekelly> | :) |
| 11:17 | <mikekelly> | so.. anyone want to explain why the current governance of HTML5 is actually in the best interests of society? |
| 11:17 | Philip` | prefers inorganic food shops |
| 11:17 | <Philip`> | The plastic gives it a nice crunch |
| 11:17 | <AryehGregor> | Mmm, sodium chloride. |
| 11:18 | <AryehGregor> | mikekelly, you've made it abundantly clear that you violently disagree with us on all possible levels, and it's obvious that there's no point in discussing it. Sorry. |
| 11:18 | <hsivonen> | annevk2: OK. that's a bit of a problem. We got a bug report about <base> and I don't find spec text to refer to. |
| 11:18 | <mikekelly> | what? I'm asking you to make your point so I can understand it |
| 11:18 | <annevk2> | hsivonen, agreed |
| 11:18 | <AryehGregor> | (Oh, wait, am I not allowed to say that there's no point in discussing something? Or is that only verboten in the W3C? :) ) |
| 11:18 | <annevk2> | damn it, Opera IRC doesn't know /ignore |
| 11:19 | <mikekelly> | I disagree because nothing has been explained |
| 11:19 | <mikekelly> | annevk2: don't be pathetic. |
| 11:19 | <jgraham> | irssi ftw :) |
| 11:20 | <mikekelly> | what exactly is so unreasonable about that question? if you can't answer it you might have some reflecting to do |
| 11:20 | <AryehGregor> | . . . |
| 11:20 | <AryehGregor> | Wait, no one has registered #whatwg? |
| 11:20 | <AryehGregor> | That seems like a bad idea? |
| 11:20 | <hsivonen> | AryehGregor: we haven't had ops here in years |
| 11:21 | <jgraham> | HAve we ever> |
| 11:21 | <Philip`> | AryehGregor: It's bad if somebody else is able to register it and get ops, despite there being lots of non-ops in here |
| 11:21 | <jgraham> | s/>/?/ |
| 11:21 | <AryehGregor> | Well, but what if everyone is forced out of the channel somehow, and someone takes it over? I guess freenode would sort it out by request in that case, practically speaking. |
| 11:21 | <Philip`> | (Apparently that's possible on QuakeNet) |
| 11:21 | <hsivonen> | jgraham: surely the first person who /joined #whatwg became an op for a while? |
| 11:21 | <AryehGregor> | Interesting. |
| 11:22 | <mikekelly> | why exactly do you feel the need for ops? |
| 11:22 | <mikekelly> | :) |
| 11:22 | <Philip`> | AryehGregor: That seems very unlikely, given the number of people here :-) |
| 11:22 | <jgraham> | hsivonen: Dunno |
| 11:22 | <AryehGregor> | Philip`, could be some server problem. |
| 11:22 | <Philip`> | AryehGregor: People here are on lots of servers |
| 11:22 | <AryehGregor> | But I guess ultimately you do have ops, you could just ask an IRCop. |
| 11:22 | <AryehGregor> | A server software bug, then, maybe. Whatever. |
| 11:22 | <Philip`> | AryehGregor: We could always move to #whatwg2 anyway |
| 11:22 | <jgraham> | #secret0treehouse |
| 11:22 | <AryehGregor> | Anyway, IRCops here are actually friendly and helpful and sane, unlike on QuakeNet, so it's probably not an issue. |
| 11:22 | <Philip`> | It's not the channel name has any importance |
| 11:23 | <AryehGregor> | Deliciously anarchic, really. A quite big channel working with no ops. |
| 11:23 | <AryehGregor> | That's better than the Wikipedia-related channels. |
| 11:23 | <Philip`> | It's survived longer than the open Twitter account |
| 11:23 | <gsnedders|work> | mikekelly: The practical good that will come out of the existence of the HTML 5 spec is the ability for new browsers to emerge that are compatible with the existing web content without having to spend years reverse-engineering other browsers. |
| 11:24 | <mikekelly> | .. lol |
| 11:24 | <mikekelly> | :) |
| 11:24 | <Philip`> | gsnedders|work: Does that mean if nobody creates a new browser in the future, because Gecko and WebKit are good enough, that HTML 5 will provide no practical good? |
| 11:24 | <mikekelly> | bingo! |
| 11:25 | <jgraham> | Philip`: Was that just a thinly veiled way of saying that Presto isn't good enough? |
| 11:25 | <AryehGregor> | jgraham, was that just a thinly-veiled way of saying that Trident isn't good enough? |
| 11:26 | <AryehGregor> | Or would you prefer to say that explicitly? :P |
| 11:26 | <jgraham> | AryehGregor: Nah, I will say that explicitly |
| 11:26 | <jgraham> | With demos if need be |
| 11:26 | <mikekelly> | it's hardly suprising Trident has such distain for the specs |
| 11:26 | <mikekelly> | they just have unfashionable disdain |
| 11:26 | <Philip`> | jgraham: No, just saying that if someone wants to make a new browser-like thing in the future, Presto isn't useful as a base for them to build it on, whereas Gecko and WebKit are (since they're open source) |
| 11:27 | <Philip`> | (I probably should have said "if nobody creates a new browser engine in the future") |
| 11:27 | <AryehGregor> | Well, except if you want to write something closed-source. |
| 11:27 | <AryehGregor> | Then you can't look at the source code too closely. |
| 11:27 | <mikekelly> | well then you pay the price |
| 11:27 | <mikekelly> | 'tough shit' is the technical phrase for that I think |
| 11:27 | <AryehGregor> | Or if you want to write something BSD-licensed. Or whatever. |
| 11:27 | <Philip`> | and given the complexity of building browser engines (regardless of whether you've got a spec to follow), people probably won't build browser engines when they can reuse the free ones that are already available |
| 11:27 | <AryehGregor> | (okay, I don't like the BSD license either, so I'm not going to cry over that) |
| 11:27 | <jgraham> | Philip`: Hmm? It's not obvious why the opensourciness of existing browser engines is a big factor when creating a novel browser engine |
| 11:28 | <AryehGregor> | jgraham, well, practically speaking, the last two major new browsers to be deployed just used existing open-source browser engines. |
| 11:28 | <mikekelly> | :) |
| 11:28 | <jgraham> | Yeah I agree that existing browser engines may cause you to not bother crating a new one |
| 11:28 | <gsnedders|work> | mikekelly: In that case HTML 5 will lead to browsers becoming interoperable, which should reduce the abundance of pages that only work in the browser they are designed for. |
| 11:28 | <AryehGregor> | Even though Apple would not have been predisposed a priori to use an open-source rendering engine. |
| 11:28 | <Philip`> | jgraham: It seems like a factor when building a new browser front-end (reusing an engine), because it's easier and cheaper than sorting out complex licensing deals |
| 11:29 | <jgraham> | Either by licensing a commercial one or reusing an open source one |
| 11:29 | <mikekelly> | gsnedders|work: isn't that what the doctype is for? |
| 11:29 | <Philip`> | hence loads of people writing WebKit-based mobile browsers |
| 11:29 | <mikekelly> | it's ridiculous - HTML5 wont be backwards compatible so what point are you trying to make here? |
| 11:29 | <AryehGregor> | The last time anyone actually wrote a serious new HTML renderer from scratch was sometime in the 1990s, I suspect. |
| 11:30 | <AryehGregor> | ("serious" meaning "eventually saw significant adoption in web browsers", just to make it clear how much I'm hedging here) |
| 11:30 | <mikekelly> | exactly |
| 11:30 | <gsnedders|work> | mikekelly: The DOCTYPE merely defines the valid structure of the document — it says nothing about how to process the document, or what things mean, or how to display them, or how they map onto DOM APIs… |
| 11:30 | <jgraham> | Philip`: Hmm I think I was misunderstanding you a bit |
| 11:30 | <AryehGregor> | But practically speaking, HTML5 aims to improve consistency among existing browsers too. |
| 11:30 | <Philip`> | jgraham: I was probably misunderstanding and misexplaining myself, too |
| 11:30 | <AryehGregor> | In regards to, e.g., parsing, which has been an undocumented and non-interoperable mess forever. |
| 11:30 | <mikekelly> | gsnedders|work: what point are you making? |
| 11:31 | <mikekelly> | that we have to live in the shadow of crappy old html forever? |
| 11:31 | <hsivonen> | wow mookid has caused quite a discussion again |
| 11:32 | <gsnedders|work> | mikekelly: Unless you can see an viable way of getting rid of crappy old html, yes. |
| 11:32 | <mikekelly> | lol. |
| 11:32 | <Philip`> | jgraham: I think my idea was: Writing browser engines is hard (despite HTML5 helping). People want to write browsers, not engines. There are free, good-enough engines (Gecko, WebKit) they can reuse. So they will probably use those, instead of writing their own, and HTML5 won't help them much |
| 11:32 | <gsnedders|work> | I'm sure most, and probably all, browser vendors would love to do so. |
| 11:33 | <mikekelly> | gsnedders|work: so why not have a way to let applications be specific |
| 11:33 | <mikekelly> | by having an internet media type assigned for strict html5 |
| 11:33 | <jgraham> | hsivonen: Yeah it seems that it is hard to protect against this sort of discussion growing beyond reasonable bounds |
| 11:33 | <Philip`> | jgraham: and so the argument about HTML5 helping people write new browser engines seems a bit theoretical |
| 11:33 | <jgraham> | Philip`: Agreed |
| 11:34 | <mikekelly> | jgraham: yeah you shuold just ban me for 'being a douche' |
| 11:34 | <jgraham> | But it becomes non-theoretical the first time it happens |
| 11:34 | <mikekelly> | cmon.. |
| 11:34 | <gsnedders|work> | mikekelly: We already have that with the XML serialization of HTML 4.01, and of the XML serialization of HTML 5 |
| 11:34 | <mikekelly> | so what is the problem? |
| 11:34 | <Philip`> | (Lots of stuff in HTML5 is useful for non-browser UAs, which people write frequently, but lots more (like all the script-related stuff) is only really useful for browsers) |
| 11:35 | <jgraham> | (and the argument about it helping existing browsers come closer to interoperability is non-theoretical) |
| 11:35 | <Philip`> | jgraham: That's assuming it ever happens a first time :-) |
| 11:35 | <Philip`> | jgraham: (That's true, but it's a different argument) |
| 11:35 | <mikekelly> | gsnedders|work: my proposal involve new attributes or just an updating of the signficance of the existing type attribute |
| 11:36 | <mikekelly> | I still don't understand the point you are making |
| 11:36 | <jgraham> | (I think it's not really a different argument. A novel browser engine is just a special case of "helps UAs become more interoperable") |
| 11:37 | <AryehGregor> | jgraham, Philip`: well, people have written *browsers* mostly from scratch recently. They just haven't written *renderers* from scratch. A lot of Safari's and Chromium's actual browser-y code, including some stuff that HTML5 specs, was written from scratch, right? |
| 11:37 | <mikekelly> | if you reject every change on the basis that it might potentially cause pain somewhere - would you ever change anything at all?! |
| 11:37 | <AryehGregor> | Also, for that matter, Gecko looks like it will be switching to a new parser written from scratch, based precisely on HTML5. |
| 11:38 | <AryehGregor> | So actually this seems like a somewhat practical argument. |
| 11:38 | <mikekelly> | it's a blanket excuse for not having to implement changes you don't think are necessary |
| 11:39 | <mikekelly> | important word being *think* |
| 11:39 | <Philip`> | AryehGregor: Adding/updating features to/in existing browser engines seems like quite a different way of framing the argument than talking about helping people write new browser engines |
| 11:40 | <AryehGregor> | Chrome and Safari are new browser engines. Except for certain (rather large) components. |
| 11:40 | <AryehGregor> | Like the entire parsing and rendering part. |
| 11:40 | <Philip`> | e.g. it doesn't result in ideas about increasing competition in the browser engine space, because there's always going to be the same handful of engines |
| 11:40 | <AryehGregor> | Well, it remains to be seen. |
| 11:41 | <AryehGregor> | Maybe HTML5 will prompt more new engines to be written. |
| 11:41 | <AryehGregor> | It lowers the bar drastically. |
| 11:41 | <Philip`> | AryehGregor: I'm using the term "[browser] engine" to mean the entire parsing and rendering etc part |
| 11:41 | AryehGregor | notes "etc" |
| 11:42 | <Philip`> | (not the front-end UI stuff, and not the back-end OS-dependent stuff like HTTP implementations and whatever) |
| 11:42 | <hsivonen> | AryehGregor: I Chrome to use the same engine as Safari |
| 11:42 | Philip` | wonders how drastic the reduction really is, because implementing the whole spec still seems really really hard even when it's all written down |
| 11:43 | <AryehGregor> | hsivonen, parse error, unexpected noun immediately following pronoun. |
| 11:43 | <hsivonen> | *I consider |
| 11:43 | <AryehGregor> | Well, it uses the same parsing and rendering engine, so . . . yeah, most of what HTML5 actually specs. |
| 11:43 | <AryehGregor> | . . . anyway, who knows. |
| 11:43 | <AryehGregor> | There are other reasons to spec things carefully. |
| 11:43 | <AryehGregor> | Even existing vendors often find themselves reverse-engineering other browsers. |
| 11:44 | <AryehGregor> | HTML5 should hopefully get all the reverse-engineering done in one place for good, for the sake of old and new browsers alike. |
| 11:44 | Philip` | isn't talking about other reasons, just about the claimed reason that it will greatly help competitive new browser[ engine]s |
| 11:44 | <hsivonen> | Philip`: btw, what's your guess on how the IE9 mode of IE9 is being developed? |
| 11:45 | <Philip`> | hsivonen: I guess they're not starting from scratch |
| 11:45 | <jgraham> | AryehGregor: That seems like the wrong parse error because you could say "I, James, am a fish" and, admittedly that requires commas but if you don't have the level of error correcting needed to fix that you will never understand IRC |
| 11:45 | <AryehGregor> | Hmm. |
| 11:46 | <AryehGregor> | Yeah, you're right, the parse error really occurs at "to". |
| 11:46 | <hsivonen> | Philip`: I wonder, though, if their delta to IE8 mode is reverse-engineering-based or spec-based |
| 11:46 | <AryehGregor> | Except of course it doesn't occur at any specific place. |
| 11:46 | <mikekelly> | gsnedders|work: so, ignoring the stuff about browsers willing to implement a change, what exactly is the problem create by the change in signficance of the type header to be more inline with HTTP and/or adding optional attributes for conneg ?? Please can someone answer this |
| 11:46 | <jgraham> | :) |
| 11:46 | <AryehGregor> | It's more of a general failure of error-correction mechanisms. |
| 11:47 | <AryehGregor> | Crazy unparseable human language. |
| 11:47 | <jgraham> | Except that I error corrected to the right result but with low confidence |
| 11:47 | <jgraham> | But high enough not to bother asking |
| 11:47 | <AryehGregor> | hsivonen, I hope they can use the same CSS engine for both, and mostly deploy JS/parsing fixes. CSS seems to be nailed down pretty well in IE8. |
| 11:47 | <mikekelly> | the last thing I got on this was Ian's invalid reference to the HTTP spec about the Accept header being inteended to represent a UA's generic preference |
| 11:47 | <mikekelly> | which is clearly not if you read the spec. |
| 11:47 | <AryehGregor> | I mean, they don't implement as much as I'd like, but what they do implement seems sane. |
| 11:48 | <AryehGregor> | MediaWiki doesn't need any IE8Fixes.css so far. |
| 11:48 | <AryehGregor> | Apparently there are still huge JS incompatibilies, though. |
| 11:48 | <AryehGregor> | I mostly avoid JS, so I don't know personally. |
| 11:56 | <AryehGregor> | $ cd skins/monobook/; ls *Fixes.css |
| 11:56 | <AryehGregor> | FF2Fixes.css IE50Fixes.css IE55Fixes.css IE60Fixes.css IE70Fixes.css IEMacFixes.css Opera6Fixes.css Opera7Fixes.css Opera9Fixes.css |
| 11:56 | <AryehGregor> | No FF3, no WebKit, no IE8, no Opera 10. <3 standards. |
| 12:02 | <Dashiva> | AryehGregor: Well, maybe wikipedia is on the compat list? |
| 12:03 | <AryehGregor> | All the other MediaWiki sites wouldn't be. |
| 12:03 | <AryehGregor> | Probably. |
| 12:03 | <AryehGregor> | Unless it's autodetecting MediaWiki somehow, like WebKit does for our old broken KHTMLFixes.css. |
| 12:03 | <hsivonen> | AryehGregor: do you mean API incompatibilities or JS language incompatibilities? |
| 12:03 | <AryehGregor> | I have no idea. |
| 12:03 | <AryehGregor> | I don't do much JS, as I said. |
| 12:18 | <Philip`> | http://www.w3.org/News/2009#entry-6526 |
| 12:18 | <Philip`> | Hmm, did nobody post about that in public-html? |
| 12:21 | <annevk2> | don't think so |
| 12:21 | <hsivonen> | Philip`: I got a patent exclusion email in my HTML WG / WHATWG folder |
| 12:22 | <hsivonen> | http://www.w3.org/mid/42366A9C-A6ED-4188-8DB2-CCB777EC5448⊙wo |
| 12:25 | Philip` | can't help but feel that half the RDFa people don't understand levels of abstraction properly, and mix up serialisations and abstract models, e.g. thinking that RDF/XML is relevant when discussing the canonicalisation of RDF literals produced by an RDFa parser |
| 12:25 | <Philip`> | (which also causes confusion when thinking about HTML vs XHTML) |
| 12:26 | <mikekelly> | I don't think there's need for RDFa if HTTP Link header works out ok |
| 12:26 | <Dashiva> | It's okay, because it works |
| 12:27 | <Philip`> | hsivonen: I got that too, but didn't really consider it to be an announcement |
| 12:27 | <hsivonen> | mikekelly: have you expressed that to the RDFa TF? |
| 12:27 | <mikekelly> | no - I discussing this with swig - there's issues like |
| 12:27 | <mikekelly> | you can't do bnodes or literals with Link headers |
| 12:28 | <mikekelly> | but that doesn't massively concern me because I don't think that either of those has value or should exist |
| 12:29 | <Philip`> | You don't need literals anyway, just use resources like http://purl.org/integers/42 instead of literals like "42" |
| 12:29 | <mikekelly> | I'm pretty new to all the semweb stuff though and a lot of the tooling isn't built for distributed approach |
| 12:30 | <Philip`> | (Then there's the bonus that somebody can use OWL to define that 42 is the same as 48) |
| 12:30 | <Philip`> | (which you couldn't do with boring old literals) |
| 12:30 | <Dashiva> | How's that trust coming along? |
| 12:31 | hsivonen | wonders if algebra can flow out of RDF inference if you figure out the right kind of recursive definition of integers as chains of triples |
| 12:32 | <Dashiva> | So what do we do if Philip` poisons the web with 42 = 48? |
| 12:33 | <Dashiva> | It would ruin everything related to RDF algebra |
| 12:33 | <Dashiva> | In general, how do you handle triples that are untrue? |
| 12:37 | <hsivonen> | Dashiva: implementation detail |
| 12:38 | <Philip`> | Dashiva: Maybe you only load inferences from trusted sources |
| 12:38 | <Philip`> | (and then apply it to data loaded from anywhere) |
| 12:40 | <Dashiva> | So now we need decentralized trust too? |
| 12:40 | <jgraham> | Maybe you do inferer trust and then use that to decide how much to trust other things |
| 12:40 | <jgraham> | s/things/statements/ |
| 12:41 | <jgraham> | Dashiva: The impression I get is that distributed trust is the holy grail for people who are into such things |
| 12:41 | <Dashiva> | So in other words, it doesn't exist, but would be really nice if it did? |
| 12:42 | <jgraham> | It seems that way to me. At least I don't recall ever actually using anything that would be described as distributed trust. But I do recall lots of talks about it |
| 12:42 | <gsnedders|work> | It's far from impossible to infer trust, but it does more or less have to be calculated on a per-application basis |
| 12:43 | <gsnedders|work> | (You can't really distribute the trust network unless you can trust the source of that network) |
| 12:43 | <gsnedders|work> | (Equally, different applications have different ideal means of calculating trust) |
| 12:44 | <Dashiva> | Is it possible to infer trust on the same level as the data, without meta? |
| 12:46 | <mikekelly> | distributed trust seems pretty simple if you have semantics for linking trusted objects together |
| 12:47 | <mikekelly> | you'd have to be able to dereference all the URIs though |
| 12:50 | <Dashiva> | And you'd need to trust DNS |
| 12:51 | <hsivonen> | http://lost-contact.mit.edu/afs/cern.ch/w3.org/www/Architecture/Letter_1.html |
| 12:51 | <hsivonen> | (via www-archive) |
| 13:03 | Philip` | likes the definition "a trusted system or component is one whose failure can break the security policy" |
| 13:04 | <Philip`> | since it highlights that trust is dangerous and should be minimised |
| 13:04 | <Dashiva> | Single point of betrayal |
| 13:05 | <Dashiva> | >> Huh? There are tons of cases not addressed by microformats (at least, not addressed easily). That's the entire reason stuff like RDFa *exists*. |
| 13:05 | <Dashiva> | > No actually it isn't RDFa exist because people want to embed "specifically" RDF in X/HTML |
| 13:09 | Philip` | wishes Opera had better multi-monitor support (on Linux at least) |
| 13:09 | <hsivonen> | Philip`: for media queries? |
| 13:09 | <Dashiva> | Hmm |
| 13:09 | <Dashiva> | Non-draconian namespaces, better or worse than draconian namespaces? |
| 13:09 | <Philip`> | hsivonen: No, for stuff like not opening menus that are much taller than the monitor they're on |
| 13:10 | <hsivonen> | multi-monitor is one reason why media queries shouldn't be allowed to query the screen--only the window. |
| 13:10 | <hsivonen> | Dashiva: IIRC, Gecko has non-Draconian namespaces in XML, but I could remember wrong |
| 13:11 | <Philip`> | A while ago it was popping up tab preview thumbnails on the wrong monitor too, but it seems to have got that fixed after I restarted it |
| 13:13 | <Dashiva> | I guess by non-draconian I mean that namespaces coexist with e.g. foo:bar with no xmlns:foo in scope |
| 13:14 | <hsivonen> | Dashiva: doesn't that "work" in Gecko for some definition of "work"? |
| 13:14 | <hsivonen> | in XML |
| 13:17 | <Dashiva> | http://dashiva.net/test/noxmlns.xhtml |
| 13:25 | <Dashiva> | I wonder how "dumb RDF" processors cope with typed RDF |
| 13:27 | <zcorpan_> | hendry: you can't have content inside <source> |
| 13:27 | <mikekelly> | Dashiva: re DNS - http://ha.ckers.org/blog/20091015/dnssec-certs-as-a-replacement-for-ssls-transport-security/ |
| 13:28 | <Philip`> | Dashiva: What's a ""dumb RDF" processor"? |
| 13:28 | <Dashiva> | Philip`: one that doesn't understand the ^^ syntax |
| 13:28 | <Philip`> | Dashiva: RDF doesn't have ^^ syntax |
| 13:29 | <Philip`> | (Some serialisations of RDF do, but they're different from RDF) |
| 13:29 | <Dashiva> | One that doesn't know about data types, I mean |
| 13:30 | <mikekelly> | wouldn't it make more sense to just have a mechnaism by which you can include a link element with type="application/rdf+xml" in the header? |
| 13:31 | <mikekelly> | rather than trying to embed it in html.. |
| 13:31 | <Dashiva> | mikekelly: That's risky because the metadata can easily get out of sync |
| 13:32 | <mikekelly> | ? don't understand what you mean by that |
| 13:32 | <Dashiva> | Embedded metadata is more reliable because it reflects the visible content |
| 13:32 | <mikekelly> | that's an artificial benefit |
| 13:32 | <mikekelly> | I don't think that is actually the case |
| 13:33 | <Philip`> | Dashiva: They ought to know enough about datatypes to preserve the datatypes that are associated with literals, but they can treat literals as opaque blobs or manipulate them as strings without having to understand the meaning of the datatype |
| 13:33 | <Dashiva> | I see |
| 13:33 | <Dashiva> | mikekelly: It's not artificial at all |
| 13:34 | <Dashiva> | When you have two copies of the same data, they can disagree. If there's only one, no disagreement is possible. |
| 13:34 | <mikekelly> | I don't think that embedding metadata makes it any more or less likely to reflect content |
| 13:35 | <Philip`> | It's not just about embedding, it's about reusing data |
| 13:36 | <Dashiva> | <span itemprop=author>Your name</span> seems highly likely to reflect |
| 13:37 | <mikekelly> | but that is probably generated from some model |
| 13:37 | <mikekelly> | which is shared |
| 13:37 | <mikekelly> | and the data persisted between the two |
| 13:38 | <Dashiva> | Well, first you have to assume it's generated. And then you have to assume nobody introduces redundancies by entering a name directly instead of using ${author} |
| 13:40 | <mikekelly> | yeah people can break good technology with bad practice |
| 13:40 | <Philip`> | Lots of it isn't generated from some model - it's stuff like licensing information copied-and-pasted into static HTML pages |
| 13:41 | <mikekelly> | ok well fair enough if you want to accomodate that kind of system then good luck to you |
| 13:41 | <Dashiva> | That's kind of what the web is for |
| 13:41 | <Dashiva> | Accomodating people |
| 13:41 | <mikekelly> | not rreeeeaaally |
| 13:42 | <mikekelly> | well actually if that's the case can we get the type attribute definition changed so I can do HTTP conneg? |
| 13:42 | <mikekelly> | since we're all about accomodation |
| 13:42 | <Dashiva> | No, because that's accomodating quirky experts, not people |
| 13:43 | <mikekelly> | yeah |
| 13:43 | <mikekelly> | I'm not people |
| 13:43 | <mikekelly> | and the people who use my systems arent people |
| 13:43 | <mikekelly> | makes perfect sense. |
| 13:44 | <mikekelly> | anyway - back to the RDF thing |
| 13:44 | <mikekelly> | you're kind of stretching the definition of a resource is your RDF representation is not directly tied to the content it is augmenting |
| 13:44 | <mikekelly> | s/is/if |
| 13:45 | <Philip`> | Oh no, not the definition of resource :-( |
| 13:46 | <Dashiva> | The precious definition of a resource |
| 13:46 | <Philip`> | (There was a fun thread on public-html about the definition of resource recently) |
| 13:46 | <Dashiva> | You call that fun? |
| 13:46 | <mikekelly> | didn't read it |
| 13:46 | <mikekelly> | probably full of The Stupid(tm) |
| 13:48 | <mikekelly> | why was that being discussed? |
| 13:48 | <Philip`> | Dashiva: Ironically |
| 13:48 | <Dashiva> | Because the precious definition of a resource was under attack |
| 13:50 | <jgraham> | Ironically the real-world definition of a resource is practically "that which is precious" |
| 13:51 | <mikekelly> | actually it's just "a concept that can be represented by some (internet) media type" |
| 13:52 | <mikekelly> | by some/at least one |
| 13:54 | <mikekelly> | the choice over resource identification and conneg should be up to system implementors |
| 13:56 | <mikekelly> | there isn't any practical choice at the moment, all your representations have to be resources in their own right - *because* html and browsers force you to do it that way |
| 13:57 | <annevk2> | wow, conneg bs is still going on? |
| 13:57 | <annevk2> | way to go |
| 13:57 | <mikekelly> | well I'm yet to get a coherent response |
| 13:57 | <mikekelly> | and the only hint of consideration came from someone last night who said they wouldn't be opposed to accomodating this approach |
| 13:58 | <mikekelly> | recent conversation on another mailing list provided evidence that others have had to find ways to get around this restriction, and would be much better off if the problem was solved |
| 13:59 | <mikekelly> | the issue was raised against the HTML5 spec and Ian instantly resolved it for no apparent reason |
| 13:59 | <mikekelly> | he then gave a response in which he completely misrepresented the HTTP spec in his justification |
| 14:00 | <mikekelly> | which I pointed out, and his only constructive response was 'you have to escalate this to the chair if you want to go any further' |
| 14:00 | <mikekelly> | not very helpful. |
| 14:01 | <Philip`> | annevk2: There was a detour through RDFa before getting back to conneg |
| 14:01 | <annevk2> | ah I see |
| 14:01 | <annevk2> | RDFa is fun too of course |
| 14:02 | <annevk2> | and slightly less theoretical than the whole conneg nonsense |
| 14:02 | <Philip`> | Exceedingly |
| 14:02 | <mikekelly> | why are you calling it nonsense? |
| 14:02 | <mikekelly> | if it's nonsense |
| 14:02 | <mikekelly> | why don't you drop the rhetoric and explain why that is the case |
| 14:02 | <AryehGregor> | Wow, this is still going on? |
| 14:02 | Philip` | is also trying to work out why the SpiderMonkey API doesn't have anything equivalent to the "new" operator |
| 14:03 | <hsivonen> | AryehGregor: isn't it awesome how this same discussion repeats itself and always at length? |
| 14:03 | <mikekelly> | what the hell am I supposed to do in this situation.. I've explained myself several times, had no response as to why that perspective is wrong and.. |
| 14:03 | <AryehGregor> | mikekelly, you disagree with the whole WHATWG on a completely fundamental level. Try the W3C, like the public-html mailing list. |
| 14:03 | <mikekelly> | nothing happens |
| 14:04 | <hsivonen> | AryehGregor: nooooo! |
| 14:04 | <AryehGregor> | hsivonen, yeah, I shouldn't be surprised, I guess. This discussion has really been going on for several years now, so it shouldn't be remarkable that one particular instance goes on for a couple of hours. |
| 14:04 | <mikekelly> | well if that is the case you should have lots of counter points to make |
| 14:04 | <Philip`> | AryehGregor: This discussion only goes on when mikekelly is here |
| 14:04 | <AryehGregor> | mikekelly, this is called "we disagree and can't come to an agreement". It happens sometimes in real life, sadly. |
| 14:04 | <mikekelly> | of which you've currently provided a big fat 0 |
| 14:05 | <AryehGregor> | mikekelly, we did, you just ignored them or rejected them. |
| 14:05 | <mikekelly> | such as..? |
| 14:05 | <mikekelly> | feel free to comment on the bug |
| 14:05 | Philip` | suggests not going through them all again on IRC |
| 14:05 | <mikekelly> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7697 |
| 14:05 | <daedb> | I'm gonna need more popcorn |
| 14:05 | <mikekelly> | why don't you just give the top 2 reasons |
| 14:06 | <mikekelly> | why its a bad idea |
| 14:06 | annevk2 | finds that pretending Opera has /ignore works pretty well |
| 14:06 | <mikekelly> | ...? |
| 14:06 | <AryehGregor> | mikekelly, I don't know about the specific issue, I can only talk about the philosophical questions you raised here just now. |
| 14:07 | <mikekelly> | ok well forget that I don't care that much, I think it's pretty immoral but it's not important |
| 14:07 | <AryehGregor> | Okay, hmm. |
| 14:07 | <mikekelly> | so going back to this conneg thing.. |
| 14:07 | <mikekelly> | if you guys want me to stop |
| 14:07 | <mikekelly> | why don't you actually give a coherent response |
| 14:08 | <AryehGregor> | So you're saying that you should be able to do <img src="foo" type="image/jpeg"> <img src="foo" type="image/png"> and have the first one be JPEG and the second PNG based on content negotiation? |
| 14:08 | <mikekelly> | correct. |
| 14:08 | <jgraham> | Philip`: It doesn't have anything called construct? |
| 14:08 | <AryehGregor> | mikekelly, FWIW, I think you'd have gotten a coherent response much earlier if you hadn't launched into tirades about moral responsibility and so on. |
| 14:09 | <mikekelly> | well we launched straight into 'you cant raise that with the spec until you convince browser vendors its a good idea' |
| 14:09 | <AryehGregor> | mikekelly, what you're suggesting doesn't seem to be the intended purpose of content negotiation. conneg is supposed to allow the server to provide one of several resources that are interchangeable, in whatever format is most convenient for it. |
| 14:09 | <AryehGregor> | What's the advantage to doing what you suggest instead of <img src="foo.jpg"><img src="foo.png">? |
| 14:09 | <mikekelly> | :) |
| 14:09 | <mikekelly> | there's a huge difference |
| 14:09 | <mikekelly> | one is representations of a resource |
| 14:09 | <mikekelly> | the other is two resources |
| 14:09 | <AryehGregor> | Ah. |
| 14:09 | <mikekelly> | a better example |
| 14:10 | <AryehGregor> | If it's really the same resource, why would you want to force particular versions of it to be used? That suggests they aren't really interchangeable and are different resources to begin with. |
| 14:10 | <mikekelly> | <a href="/blog" type="application/atom+xml"> and <a href="/blog" type="text/html"> |
| 14:10 | <AryehGregor> | Although, for what it's worth, HTML5 deliberately ignores the entire concept of resources as a pointless abstraction. |
| 14:10 | <mikekelly> | no in the context of a particular application flow |
| 14:10 | <mikekelly> | not ^ |
| 14:10 | <mikekelly> | so if I have a homepage and want to link to blog and atom feed as above |
| 14:10 | <jgraham> | Philip`: JS_ConstructObject? |
| 14:11 | <mikekelly> | atom/html are representations of my blog |
| 14:11 | <Philip`> | jgraham: It has JS_ConstructObject, but that's for native C classes and not for calling JS constructors |
| 14:11 | <AryehGregor> | Atom and HTML are totally different formats. They can't possibly represent the same resource, that just makes no sense. Reading the HTML and reading the feed are very different operations. |
| 14:11 | <mikekelly> | you're wrong |
| 14:11 | <AryehGregor> | Also FWIW, though, HTML5 gives an algorithm allowing HTML to be used as a feed format, so you could just serve HTML for both when that's supported. |
| 14:11 | <jgraham> | Philip`: Oh. |
| 14:12 | <mikekelly> | atom and html are supposed to be distinct otherwise they wouldnt be distinct representations |
| 14:12 | <AryehGregor> | mikekelly, tip: saying things like "you're wrong" rather than "I think you're mistaken" is likely to get people to ignore you. |
| 14:12 | <mikekelly> | atom and html are supposed to be distinct otherwise they wouldnt be distinct representations |
| 14:12 | <AryehGregor> | Diplomacy helps. |
| 14:12 | <mikekelly> | how can you have distinct representations that are the same? |
| 14:12 | <mikekelly> | that doesnt make any sense. |
| 14:12 | <jgraham> | Philip`: Is JS_NewObject wrong too? |
| 14:12 | <AryehGregor> | They can be the same logical "thing" encoded in two different formats, like JPEG and PNG. |
| 14:12 | <Philip`> | jgraham: The documentation for JS_ConstructObject* says "Neither of these functions is quite like the JavaScript new keyword." |
| 14:12 | <AryehGregor> | Both of those are the same image. |
| 14:13 | <mikekelly> | a blog in html as opposed to a blog in atom *are* the same thing! |
| 14:13 | <Philip`> | jgraham: Yes, that doesn't call constructors at all |
| 14:13 | <mikekelly> | you are making wild assumptions it's difficulat to know what to say other than 'you are wrong' |
| 14:13 | <jgraham> | Philip`: How silly |
| 14:13 | <AryehGregor> | mikekelly, then why do you care which one you serve? |
| 14:13 | <mikekelly> | because in the context of application flow |
| 14:13 | <AryehGregor> | Just serve text/html if it's supported, else application/xml+atom. |
| 14:13 | <mikekelly> | you may need 2 links which are specific |
| 14:14 | <AryehGregor> | "you are making wild assumptions it's difficulat to know what to say other than 'you are wrong'" Again not productive. |
| 14:14 | <mikekelly> | i.e. links to the atom feed or the actual html page |
| 14:14 | <AryehGregor> | I'm going to stop responding again if you aren't going to be polite. |
| 14:14 | <mikekelly> | from your homepage |
| 14:14 | <Philip`> | jgraham: (My current approach is to use JS_GetProperty("prototype") and JS_GetParent, pass those to JS_NewObject, then call JS_CallFunctionValue on the constructor function, which seems to work okay but isn't very elegant) |
| 14:14 | <AryehGregor> | mikekelly, but if they're functionally the same thing, why would you have separate links to each? |
| 14:14 | <mikekelly> | because the distinction between the representations is relevant to *application flow* |
| 14:15 | <mikekelly> | which is the primary concen of hypermedia formats like HTML |
| 14:15 | <AryehGregor> | Then they're distinct enough that they represent different resources, IMO. If there's a visible difference to the user, they deserve to be different resources. |
| 14:15 | <AryehGregor> | If you believe in the idea of "resources" at all, which I don't. |
| 14:15 | <mikekelly> | you don't believe in resources?! |
| 14:16 | <mikekelly> | are you trolling me? |
| 14:16 | <AryehGregor> | No. They're a pointless abstraction. |
| 14:16 | <AryehGregor> | No. |
| 14:16 | <AryehGregor> | See recent discussions on public-html about this. |
| 14:16 | <mikekelly> | pointless? |
| 14:16 | <mikekelly> | how are they pointles |
| 14:16 | <AryehGregor> | Okay, I'm using /ignore for the first time in a very, very long time. Sorry. |
| 14:16 | <mikekelly> | the smenatics of HTTP only make sense *because* of the notion of resources and representation |
| 14:17 | <mikekelly> | why are you ignoring me because I'm making sense? |
| 14:18 | <mikekelly> | it's a bit rich to get involved in a discussion over resources and representations and then when you get towards the end proclaim 'well I dont even believe in resources' |
| 14:18 | <mikekelly> | wtf is that about.. |
| 14:18 | <AryehGregor> | Ignoring people makes me sad. I just lack the restraint not to respond, apparently. |
| 14:18 | <AryehGregor> | http://xkcd.com/386/ |
| 14:19 | <mikekelly> | some of you people are umbelievably weak. |
| 14:21 | <mikekelly> | what a joke :) |
| 14:23 | <mikekelly> | so.. still lacking a coherent explanation - "resources are a pointless abstraction" doesn't cut it for me, sorry. |
| 14:30 | <mikekelly> | that resource discussion looks like it could be quite a good laugh |
| 14:33 | <mikekelly> | wow, pretty disgusting. |
| 14:34 | <TabAtkins> | mikekelly: I told you what the next step is for you. You created a bug, it was resolved, you weren't happy with the resolution, you don't have new information to cause the editor to reconsider, so you *raise it as an Issue*. |
| 14:34 | <Philip`> | Or you drop it |
| 14:35 | <TabAtkins> | That's the appropriate response, as detailed in the new HTMLWG decision policy, and as explained to you yesterday. |
| 14:41 | <mikekelly> | fair enough |
| 14:48 | <mikekelly> | this is pure craziness: RFC2616's terminology is more abstract than is useful for most Web |
| 14:49 | <mikekelly> | developers, and therefore this kind of terminology confuses people. |
| 15:07 | <mikekelly> | how do I raise an issue? |
| 15:07 | <mikekelly> | :( |
| 15:07 | <Dashiva> | Talk to someone with issue tracker access |
| 15:07 | <mikekelly> | can someone point me in the right direction here then please |
| 15:07 | <Dashiva> | Or just post to public-html and it should happen during the flow of discussion |
| 15:08 | <mikekelly> | hmm ok fair enough |
| 15:08 | <Dashiva> | Just make it clear from the mail that you've tried bugzilla and wish to raise an issue |
| 15:08 | <mikekelly> | ok will do, thanks |
| 15:14 | <mikekelly> | I have to be invited in order to participate in that list right? |
| 15:15 | <Dashiva> | No |
| 15:15 | <Dashiva> | You have to be a member to subscribe to it, but anyone can send email and read the archives |
| 15:15 | <TabAtkins> | (Make sure to indicate in the email if you aren't subscribed, so people will keep you in the cc lists.) |
| 15:16 | <mikekelly> | ah ok that makes sense |
| 17:13 | <mikekelly> | done and sent |
| 17:14 | <mikekelly> | TabAtkins: thanks for the guideance, sorry for being douche :) |
| 17:19 | <AryehGregor> | The WHATWG FAQ needs an entry like "Your attitude toward web standards is short-sighted/irresponsible/uninformed/evil/insane/etc." We get that so much. |
| 17:19 | <AryehGregor> | Culture conflict. |
| 17:21 | <TabAtkins> | mikekelly: We're all douches sometime. It's cool. Just don't make it a habit. |
| 17:21 | <TabAtkins> | AryehGregor: I agree! |
| 17:21 | TabAtkins | might write it this weekend. |
| 17:22 | <AryehGregor> | It needs to say something like 1) it's not helpful to get upset about people with different attitudes toward the web's future, 2) the WHATWG is mostly composed of people who have a lot of web standards experience and know what they're doing, 3) justification for the major philosophical differences (e.g., concreteness and pragmatism). |
| 17:23 | <TabAtkins> | Expand on how (1) might read? |
| 17:27 | <webben> | "Explaining the reasons for your beliefs is more effective than castigating other people for holding different beliefs. We welcome alternate points of view." ? |
| 17:27 | <TabAtkins> | Hehe, excert from just-written code: array("name"=>$name->name) |
| 17:27 | <AryehGregor> | Well, just general advice when encountering opinions that seem crazy to you, you know. |
| 17:27 | <AryehGregor> | I wouldn't say we welcome alternate points of view, but we're sure going to ignore you if you're only capable of ranting and calling us names. |
| 17:27 | <webben> | *more likely to effect changes to our specifications |
| 17:28 | <TabAtkins> | webben, that's helpful. |
| 17:28 | <webben> | rather than "more effective" |
| 17:30 | <TabAtkins> | Arlag;hes;lageh I keep screwing up the order of arguments in this function. Damn my bad API design! |
| 17:38 | <TabAtkins> | AryehGregor: Your idea of <a onlyreplace="foo"> is intriguing. It's essentially browser-supported AJAX that decays into perfectly serviceable links. |
| 17:38 | <AryehGregor> | TabAtkins, yes, but the problem of authors relying on it and not actually making the pages the same is very troublesome. |
| 17:38 | <TabAtkins> | Or, rather, AJAH, in the simple form where it just retrieves content and plugs it straight in. |
| 17:38 | <AryehGregor> | Better than AJAX in that regard, to be fair. |
| 17:39 | <AryehGregor> | At least this somewhat encourages working links. |
| 17:39 | <AryehGregor> | Maybe some tweak could make them more or less mandatory, but I'm not sure what. |
| 17:39 | <TabAtkins> | Yeah, that's what I like best. It seems to decay with the most ease and usefulness. |
| 17:40 | <TabAtkins> | Plus you don't have to mess around with listeners and such dying on page reloads, and possibly persisting them (I don't know how)... |
| 17:40 | <TabAtkins> | Honestly I like it a *lot*. |
| 17:41 | <TabAtkins> | Worst case, authors will produce a single static page and then all the "linked" pages will contain just the bit of content they'll want to swap in. That will break search engine and bookmarking spectacularly, though, so it'll probably be pretty obvious when it happens. |
| 17:41 | <AryehGregor> | You could say the same of frames. |
| 17:42 | <TabAtkins> | Nah, frames break that by design, and in a different way (you just always return to the 'main' page). In this, if you bookmarked deep into the site, you'll just get an unstyled chunk of content, which is much worse. |
| 17:42 | <TabAtkins> | Which gives correspondingly greater pressure to *not* take that sort of shortcut, and just do it right (produce full pages). |
| 17:43 | <AryehGregor> | It could be made to fail somehow if there were serious problems with the retrieved thingie. |
| 17:43 | <AryehGregor> | But I'm not sure how to do that elegantly, if it's possible. |
| 17:43 | <TabAtkins> | Like some kind of check that, if it fails, will ignore the @onlyreplace and just swap the entire page out (with obvious bad effects if you're doing it wrong). |
| 17:44 | <TabAtkins> | That should have ended with a ?. |
| 17:45 | <AryehGregor> | The trick is making it so the error can kick in quickly, so you don't get the page loading partially and then reloading. |
| 17:45 | <AryehGregor> | Also I'm not sure what to trigger off. |
| 17:45 | <TabAtkins> | Yeah, not sure either. We can do some basic stuff, like it having a doctype and <title>. That'll at least require a *little* bit more than just the content chunk. |
| 17:47 | <AryehGregor> | Neither a doctype nor a <title> are required to exist in a working page. |
| 17:47 | <AryehGregor> | Although both are required in a valid page, of course. |
| 17:47 | <TabAtkins> | Exactly. Requiring some form of validity doesn't hurt. |
| 17:47 | <AryehGregor> | Well, it does if you want the feature to not be the one thing in HTML5 to totally break for no apparent reason because you don't have a doctype. |
| 17:48 | <AryehGregor> | Quirks mode is one thing, that's another. |
| 17:48 | <AryehGregor> | The differences between rendering modes should be minimized if possible. |
| 17:48 | <AryehGregor> | Remember that if possible, we wouldn't require a doctype at all. |
| 17:48 | <TabAtkins> | The great thing about this idea, why I think it has serious potential, is that it also cleanly addresses the "permanent script" idea that got bandied about a while back. Doing the "single-page app" was a suggested solution, but people balked at the difficulty of doing that with AJAX. |
| 17:48 | <TabAtkins> | This is true. |
| 17:49 | <AryehGregor> | I guess you could argue that my proposal is more or less strictly better than AJAX for this use-case. |
| 17:49 | <TabAtkins> | Also, this would presumably update history/url accordingly, so bookmarking worked properly without any effort. |
| 17:49 | <TabAtkins> | It is strictly better. |
| 17:49 | <TabAtkins> | It is a wonderfully automatic solution to a problem that is currently being solved by a much more general (and thus harder to use) tool. |
| 17:49 | <cardona507> | does the iphone safari support <audio> ? |
| 17:51 | <AryehGregor> | TabAtkins, another question is how much benefit there is to implementing something so specific in a declarative fashion. We could try mimicking lots of behavior without JS; is it worth it? |
| 17:51 | <AryehGregor> | Maybe the new behavior would make more sense if it were JS-based instead of declarative? |
| 17:51 | <AryehGregor> | cardona507, I think the very latest ones do, but I don't know for sure offhand. |
| 17:52 | <cardona507> | thanks |
| 17:54 | <AryehGregor> | I wonder if the functionality is complicated enough from a JS perspective to really justify a new function, if it's okay to require JS. |
| 17:54 | <AryehGregor> | I guess nobody would do it manually if it weren't a built-in function, because it seems wasteful. |
| 17:55 | <AryehGregor> | Which it is, without SDCH or such. |
| 17:56 | <TabAtkins> | AryehGregor: Yes, I think this is absolutely worth it. This is already a common pattern; it's being held back by concerns about accessibility and the simple difficulty of doing it right. |
| 17:56 | <TabAtkins> | I really think this will revolutionize html applications. |
| 17:56 | <AryehGregor> | Now you're getting into hyperbole. |
| 17:57 | <AryehGregor> | It would make one part of the AJAX pattern easier. |
| 17:57 | <TabAtkins> | No, seriously, I had to go walk around the living room to calm down over how awesome this would be. |
| 17:57 | <AryehGregor> | Yes, but that's because you're very excitable. |
| 17:57 | <TabAtkins> | Beside the point! |
| 17:58 | <TabAtkins> | It's already a common pattern, it's a solution to some real and persistent problems going forward (like globalScript), and it's just so unbelievably trivial to use. |
| 17:59 | <TabAtkins> | And it's trivially accessible. Win-win-win. |
| 17:59 | <AryehGregor> | What use cases would greatly benefit from it, concretely? From the point of view of a conventional app like MediaWiki, or static pages, it mostly just prevents flicker on navigation. |
| 17:59 | <AryehGregor> | It only seems really useful if you have very script-intensive stuff that you don't want to vanish on navigation. |
| 18:00 | <TabAtkins> | The author just has to write a perfectly normal site, unchanged from how they've done so for the past 10 years. Add this one little attribute to your links, and suddenly you've got the new hotness of AJAX. |
| 18:00 | <AryehGregor> | Concretely, I said. |
| 18:00 | <AryehGregor> | "the new hotness of AJAX" does not count as a concrete use-case. |
| 18:00 | <TabAtkins> | Aryeh: Yup, and that's very valuable. Script-heavy apps will get more and more prevalent. |
| 18:00 | <AryehGregor> | Yes, but they're already script-heavy, and probably using giant libraries. Isn't using an AJAX library good enough for them? |
| 18:01 | <TabAtkins> | No, it's still more difficult than it needs to be, *and* you have to architect around it. |
| 18:01 | <TabAtkins> | This requires *no* architecture changes at all. |
| 18:01 | <AryehGregor> | Relative to a set of static pages. |
| 18:01 | <TabAtkins> | Yes. |
| 18:01 | <TabAtkins> | Which are still the default. |
| 18:02 | <AryehGregor> | Relative to a totally JS-driven app, which is the only place where there seems to be a lot of benefit, lack of architecture changes isn't really relevant. |
| 18:02 | <TabAtkins> | I'd love to not have to reload jQuery on every pageload of my company's sites. |
| 18:02 | <AryehGregor> | Hmm, that's a point. |
| 18:02 | <AryehGregor> | It might significantly improve performance to avoid rerendering and so on. |
| 18:02 | <TabAtkins> | Yup. |
| 18:02 | <AryehGregor> | And reexecuting script. |
| 18:02 | <TabAtkins> | Yup. |
| 18:02 | <TabAtkins> | This is why I'm excited about it. |
| 18:03 | <TabAtkins> | The best solution to "I don't want to reload libraries" *is* a single-page app, but that's difficult right now, and will always be annoying. This solves it trivially. |
| 18:03 | <TabAtkins> | And you don't have to worry about SEO hits from bots not executing JS, etc. |
| 18:03 | <TabAtkins> | They'll just see a static site. |
| 18:04 | <mikekelly> | did my email hit the list? |
| 18:05 | <TabAtkins> | I don't see it yet. |
| 18:05 | <mikekelly> | hmmm |
| 18:05 | <mikekelly> | I sent it a while ago |
| 18:05 | <mikekelly> | I had to approve my address do I need to resend it? |
| 18:05 | <Philip`> | mikekelly: If it's the first time you've posted to the list, you'll need to respond to the confirmation it sends back to you, and then wait a few days |
| 18:05 | <mikekelly> | a few days?! :( |
| 18:05 | <Philip`> | mikekelly: No need to resend |
| 18:06 | <Philip`> | mikekelly: Yeah, I'm not sure why but the W3C lists have a delay the first time you post a message |
| 18:06 | <AryehGregor> | It took me like two weeks to get approved to be a public-html member. |
| 18:06 | <Philip`> | (I guess it needs human approval or something) |
| 18:08 | <mikekelly> | :( |
| 18:09 | <mikekelly> | what's the difference between html-public and the whatwg list? |
| 18:09 | <Philip`> | The whatwg list is older, and has more members, and anyone can subscribe |
| 18:10 | <TabAtkins> | whatwg was original. htmlwg was commandered when the w3c took html5 in. |
| 18:11 | <Philip`> | public-html is the W3C list, and only HTML WG members can subscribe, and it's the appropriate place for W3C-related discussions (like the W3C Issue Tracker and the W3C Chairs) |
| 18:13 | <Philip`> | mikekelly: Oh, it's on the list now |
| 18:14 | <othermaciej> | the HTML WG was actually created before the W3C decided to adopt HTML5 as the spec the HTML WG would be working on |
| 18:14 | <othermaciej> | though adopting HTML5 was one of our few actual Working Group decisions |
| 18:16 | <Philip`> | I remember it seeming totally obvious that the HTML WG was created for the purpose of adopting HTML5, so the "decision" was a formality and never really in question |
| 18:21 | <cardona507> | what is the browser support for <audio> ? I don't see the controls in firefox and I see the controls but can't get it to play back in safari |
| 18:21 | <AryehGregor> | You need to do <audio controls>, are you doing that? |
| 18:21 | <AryehGregor> | What version of Firefox, and what format of audio are you using? |
| 18:22 | <mikekelly> | ah nice one |
| 18:23 | <mikekelly> | maybe if we have the ability to specify conneg controls for hyerlinks Ian won't be quite so confused about what a resource is |
| 18:23 | <cardona507> | aryehgregor - I have <audio src="grace.mp3" controls=""></audio> and I am using firefox 3.5.3 and safari 4 - |
| 18:24 | <AryehGregor> | Firefox and Opera don't support any patent-encumbered audio formats, including MP3. You have to use Ogg Vorbis for them. |
| 18:24 | <AryehGregor> | Safari should support whatever codecs are installed, AFAIK. |
| 18:24 | <AryehGregor> | Ugh, where's a non-retarded <audio> tutorial? |
| 18:24 | <mikekelly> | is that like some hippt protest by them or is there a practical reason for that? |
| 18:24 | <mikekelly> | hippy^ |
| 18:25 | <Philip`> | mikekelly: The reason is not having to pay licensing fees and not getting sued |
| 18:25 | <mikekelly> | hippy. |
| 18:25 | <mikekelly> | :D |
| 18:25 | <Philip`> | and being portable across all platforms |
| 18:26 | <mikekelly> | I know, I'm kidding I'm all for open standards |
| 18:26 | <AryehGregor> | It's a principled stand, it's not about licensing fees. |
| 18:26 | <AryehGregor> | Mozilla and Opera could get reasonable licensing fees if they wanted them. |
| 18:27 | <AryehGregor> | The various consortia involved aren't stupid, they want the exposure. |
| 18:27 | <mikekelly> | dork fight! |
| 18:27 | <Philip`> | AryehGregor: What is the principle, if it's not about no-fee usage? |
| 18:28 | <mikekelly> | I agree with athat principal - those formats should be public domain |
| 18:28 | <AryehGregor> | Well, you made it sound like they don't want to have pay licensing fees, personally. |
| 18:28 | <AryehGregor> | They don't want anyone to have to pay licensing fees anywhere on the web. |
| 18:28 | <AryehGregor> | *They* could pay them if they wanted, I'm sure. |
| 18:28 | <mikekelly> | we shouldn't pander to crusty dinosaurish nonsense any more |
| 18:28 | <mikekelly> | we don't need to |
| 18:28 | <Philip`> | AryehGregor: Ah, I think I agree with you |
| 18:29 | <mikekelly> | yeah good for them :) |
| 18:29 | <mikekelly> | fight the powa! |
| 18:30 | <mikekelly> | what's the best ipod alternative that plays all the stinky hippy formats? |
| 18:31 | <Philip`> | mikekelly: Just connect some speakers to a laptop |
| 18:31 | <mikekelly> | yeah it's a toss up between that and a boombox |
| 18:31 | <Philip`> | Works fine as long as you don't want to do anything crazy like walking outside |
| 18:32 | <AryehGregor> | You could use one of the ones with full-fledged Linux, like the N900 or something, I guess. |
| 18:32 | <TabAtkins> | Worked great for me while I was doing work on my house. Could compete with the construction works using actual radios next door. |
| 18:32 | <Philip`> | You could memorise all the songs and then hum them |
| 18:33 | <mikekelly> | yeah I do that anyway |
| 18:33 | <mikekelly> | quite hard to hum my type of music though |
| 19:02 | <TabAtkins> | AryehGregor: I promoted your <a onlyreplace> to a top-level post with more commentary. |
| 19:02 | <AryehGregor> | It was already promoted to a top-level post within like the last day, but oh well. |
| 19:07 | <TabAtkins> | Nah, your top-level post was about several things, and only mentioned <a onlyreplace> in an offhand manner. I think it deserves more attention than that. |
| 19:09 | <daedb> | TabAtkins: which post is that? |
| 19:10 | <TabAtkins> | Something with "<a onlyreplace>" in the subject. On the whatwg list. |
| 19:11 | <TabAtkins> | Man, *every* thread started by a google employee gets itself flagged as spam by gmail due to possible spoofing. then I'm all confused by the second post arriving in my inbox and talking about stuff that I can't see. |
| 19:13 | <Philip`> | How is <a onlyreplace> better than <iframe seamless> and <a target>? |
| 19:13 | <daedb> | ah, now I found it :) |
| 19:13 | <AryehGregor> | Philip`, it updates URLs, for one thing. |
| 19:14 | <AryehGregor> | So bookmarking actually works. |
| 19:14 | <AryehGregor> | It also keeps everything in one page, so more natural to use. |
| 19:14 | <Philip`> | AryehGregor: It seems like bookmarking usually wouldn't work, because you'll be viewing some complex combination of browsing history and it couldn't be re-retrived by a single URL |
| 19:15 | <AryehGregor> | Philip`, it could be used that way, but that's not the idea. The idea is you take a normal set of static pages and just add in onlyreplace where you know the next page only has a few parts significantly different. |
| 19:16 | <AryehGregor> | So it works well with bookmarking then. iframes can never work well with bookmarking, AFAICT, unless maybe you hook all links with JS and use the history push thing. |
| 19:16 | <TabAtkins> | Philip`: it also doesn't require architecting your page into a series of snippets that are linked from an iframe. |
| 19:16 | <Philip`> | AryehGregor: If it's solely intended as an optimisation, it seems better for browsers to focus on optimising page load times, rather than forcing authors to do something weird and fragile |
| 19:16 | <AryehGregor> | I'm not the one enthusiastically advocating it, don't look at me. :) |
| 19:17 | <AryehGregor> | On the other hand, I don't see what optimizations will permit pages to be loaded without at least flickering. |
| 19:17 | <TabAtkins> | Philip`: As far as I know, there is *no* way for browsers to optimize stuff like js library load/execution time sufficiently, which is why proposals like GlobalScript exist. |
| 19:17 | <AryehGregor> | The browser can't assume that the new page bears any resemblance to the old, so it has to render it from scratch . . . hmm. Maybe not. |
| 19:17 | <TabAtkins> | (Which this solves.) |
| 19:17 | <AryehGregor> | It could strategically delay things, but not very effectively without messing up progressive rendering. |
| 19:17 | <Philip`> | AryehGregor: They'd just need to delay rendering the page until enough of it has loaded |
| 19:18 | <AryehGregor> | MediaWiki has sidebars at the bottom of the HTML source. You'd have to delay until the whole page was loaded. |
| 19:18 | <Philip`> | which they try to do already, and if they loaded pages faster then they'd be more likely to have enough of it loaded before first rendering |
| 19:18 | <AryehGregor> | (having sidebars at the bottom of the source is good practice for good fallback to non-CSS UAs, in theory) |
| 19:18 | <Philip`> | (Opera even has a preference for how many seconds to wait before redrawing a newly-loaded page) |
| 19:18 | <AryehGregor> | I agree that this technique seems dubious as an optimization effort, but the fact is, lots of places go to a lot of trouble to do something even more fragile and much harder to do using AJAX. |
| 19:19 | <AryehGregor> | For the same effect, I mean. |
| 19:19 | <Philip`> | When you're doing it with AJAX, you get the benefit that you're only transmitting the content that's needed, and not tens of kilobytes of irrelevant unchanging page content |
| 19:20 | <Philip`> | (with the server-side delays needed to compute all that content before transmitting it) |
| 19:20 | <TabAtkins> | In what I imagine is the typical use-case, you're mainly replacing content, so the only irrelevant content is the relatively small (in comparison) template. |
| 19:20 | <AryehGregor> | Also, this is what SDCH is for, in theory. |
| 19:21 | <Philip`> | How would <script> and document.write() interact with onlyreplace? |
| 19:21 | <AryehGregor> | Same as if they had been inserted by script, presumably. |
| 19:21 | <Philip`> | (Would you execute all scripts? no scripts? only scripts in the elements that are being replaced? what if those elements are written by scripts?) |
| 19:21 | <TabAtkins> | In terms of the requested page having <script>s and document.write()? |
| 19:21 | <TabAtkins> | I'd execute no scripts. |
| 19:22 | <AryehGregor> | The proposal doesn't suggest anything that doesn't have a pretty clear mapping to JS already. |
| 19:22 | <TabAtkins> | The existing page can hook the links and execute something equivalent itself. |
| 19:22 | <Philip`> | Wouldn't people want to e.g. re-execute their Google Ad scripts on each new page, so it shows ads relevant to the content? |
| 19:22 | <AryehGregor> | I wouldn't add special handling for script. |
| 19:22 | <AryehGregor> | Just let it do whatever it normally does if you insert it in the DOM. |
| 19:22 | <AryehGregor> | Which I guess is execute. |
| 19:23 | <AryehGregor> | You can always just not include any <script>s if you don't like that. |
| 19:23 | <TabAtkins> | Philip`: I think there's a way to reload Google Ads anyway? |
| 19:23 | <TabAtkins> | Aryeh: Executing all scripts, though, kills a lot of the 'optimization'. |
| 19:23 | <AryehGregor> | Executing all scripts in the snippet you loaded. |
| 19:23 | <AryehGregor> | Which might contain no scripts at all. |
| 19:23 | <AryehGregor> | Typically wouldn't, I'd think. |
| 19:23 | <TabAtkins> | If some way doesn't currently exist to reload Google Ads, it will once this becomes common. |
| 19:24 | <AryehGregor> | Google Ads are JS-based and should be able to reload themselves occasionally if they feel like it, I assume. |
| 19:24 | <TabAtkins> | AryehGregor, oh. Eh, sure. |
| 19:24 | <Philip`> | Hooray, my code no longer gives segmentation faults and stack smashing errors |
| 19:24 | <AryehGregor> | Nor does mine, because I only write in scripting languages. |
| 19:25 | <AryehGregor> | . . . Of course, that's no guarantee for PHP. |
| 19:25 | <AryehGregor> | <?php function f() { f(); } f(); |
| 19:25 | <AryehGregor> | $ echo '<?php function f() { f(); } f();' | php |
| 19:25 | <AryehGregor> | Segmentation fault |
| 19:25 | <AryehGregor> | Yay PHP! |
| 19:25 | <TabAtkins> | Heh. |
| 19:26 | <TabAtkins> | Strange that that segfaults rather than throwing with OutOfStack or whatever. |
| 19:26 | <Philip`> | I'm trying to write in scripting languages, but the interface between the scripting language and native code is what crashes |
| 19:26 | <AryehGregor> | $ echo -e "def f():\n f()\n\nf()" | python 2>&1 | tail -n1 |
| 19:26 | <AryehGregor> | RuntimeError: maximum recursion depth exceeded |
| 19:26 | <AryehGregor> | TabAtkins, not a bug, according to them. Duh, a segfault is the only reasonable answer if you hit infinite recursion. |
| 19:27 | <TabAtkins> | O...k? |
| 19:27 | AryehGregor | likes how Python helpfully prints the call stack here, which is of course 1000 lines long |
| 19:28 | <AryehGregor> | To be fair: $ echo -e "import sys\nsys.setrecursionlimit(1000000000)\ndef f():\n f()\n\nf()" | python 2>&1 |
| 19:28 | <AryehGregor> | Segmentation fault |
| 19:28 | <AryehGregor> | Python lets you shoot yourself in the foot too, but at least you have to opt in. |
| 19:29 | <TabAtkins> | Philip`: How often is page 10s of k when just considering content? That sort of weight is relatively typical when you include scripts and css and such, but actual html is usually relatively small. |
| 19:29 | <TabAtkins> | At least, I think. |
| 19:29 | <TabAtkins> | Does C segfault on infinite recursion? |
| 19:29 | <AryehGregor> | $ wget -qO- http://www.cnn.com/ | wc -c |
| 19:29 | <AryehGregor> | 98818 |
| 19:29 | <TabAtkins> | Both PHP and Python are built on C, so shrug. |
| 19:29 | <Philip`> | TabAtkins: The mean size of HTML pages from a few sources (dmoz.org, dotnetdotcom) was about 25KB, if I remember correctly |
| 19:30 | <TabAtkins> | All right. I wonder how much of that is content, and how much is template? |
| 19:31 | <TabAtkins> | That'd tell us the inefficiency with respect to a simple AHAH with content chunks. |
| 19:32 | <TabAtkins> | AryehGregor: CNN's front page probably isn't a good example, as it's full of tons of stuff. I'd want to hit an inner page instead. |
| 19:35 | <AryehGregor> | TabAtkins, C has no opinion on the matter. It's platform-dependent. Typically, yes, the operating system will kill the process if the stack grows too large, for user-mode code, but in principle it doesn't have to. |
| 19:37 | <AryehGregor> | On Unix, SIGSEGV can be caught, if you like. |
| 19:39 | <AryehGregor> | C is fun. Assembly is even funner. |
| 19:39 | <AryehGregor> | In their own way. |
| 19:40 | <TabAtkins> | Hmm, okay. In my own site, the template is 16kb, while the content for the homepage (representative of most pages) is 17kb total. Those are all uncompressed numbers. |
| 19:41 | <TabAtkins> | I mean, the whole homepage is 17kb. So that's roughly 1kb of content. |
| 19:42 | <TabAtkins> | Now, of course, those 17kb or so are currently being delivered on every pageload, plus jQuery has to be reloaded and scripting applied to a few interface elements. |
| 19:43 | <AryehGregor> | The 17 KB would still be loaded in the proposal you like so much. |
| 19:43 | <TabAtkins> | So, worst case, I'm still getting a better experience, since the page doesn't ever flicker and jQuery can stay loaded the whole time. |
| 19:43 | <AryehGregor> | How long does jQuery take to load? |
| 19:43 | <TabAtkins> | AryehGregor: Yup. |
| 19:43 | <TabAtkins> | AryehGregor: Dunno! I'd have to test. |
| 19:45 | <TabAtkins> | I suppose to do so I'd alter the jQuery source to record the time before and after the rest of the code was executed? |
| 19:49 | <AryehGregor> | Or add <script>s before and after. |
| 19:50 | <TabAtkins> | Looks like I'm averaging about 13ms? |
| 19:51 | <TabAtkins> | + however much time it takes to wait for document.ready, and apply stuff to the nav. |
| 19:54 | <AryehGregor> | 13ms is fairly far below the level of perceptibility. |
| 19:54 | <TabAtkins> | I purposely avoid heavier manipulation of the page, to avoid FOUC (the U is for "unscripted", in this case). |
| 19:54 | <TabAtkins> | Aryeh: I'm also loading *only* jQuery, not anything like jQuery UI which can get *enormous*. |
| 19:55 | <TabAtkins> | And it's not 13ms by itself. It's 13ms added to the page load time. |
| 19:55 | <TabAtkins> | (I think 50ms or so is the general point at which we perceive a delay?) |
| 19:58 | <TabAtkins> | Also interesting: applying this to a form submission. |
| 20:01 | <TabAtkins> | Point, though, is that currently whatever benefits I can gain from making a single-page site are *far* outweighed by the difficulties of actually *implementing* it correctly right now. This would put single-page apps in the hands of the average webdev who doesn't know the esoterica of js and accessibility. |
| 20:02 | <TabAtkins> | Without costing me a thing, especially if I can activate it just by adding onlyreplace="left-nav bc" to my <base> tag. |
| 20:03 | <AryehGregor> | It's not obvious to me that the potential pitfalls and the implementation difficulty would be worth the benefit. |
| 20:04 | <TabAtkins> | Then solutions can be built on top of this to allow better optimization, such as the browser specifically requesting only those elements, and the server returning only what's necessary. |
| 20:04 | <TabAtkins> | What pitfalls do you see besides the already-mentioned one of authors being stupid and writing subpages that are just content chunks? |
| 20:05 | <TabAtkins> | (Re optimizations: that's why I love declarative mechanisms! When you state what you want, rather than how you want it, you can do a lot of transparent optimization behind the scenes without ever affecting anything visibly.) |
| 20:51 | <cying> | how is WHATWG pronounced? |
| 20:51 | <cying> | "what working group" ? |
| 20:52 | <tantek> | or "what double you gee" |
| 20:53 | <cying> | ahhh |
| 20:54 | <Hixie> | i pronounce it "whatwuhjee" |
| 20:55 | <cying> | Hixie: interesting... wuhjee? |
| 20:56 | <tantek> | Hixie, makes sense, like "wuh wuh wuh dot ..." |
| 20:56 | <Hixie> | yeah |
| 20:56 | <Hixie> | or wuhwuhstyle for www-style |
| 20:58 | <gavin> | weird! |
| 21:11 | <Hixie> | i wonder whether we should drop the reversed DNS labels |
| 21:11 | <Hixie> | from microdata |
| 21:12 | <AryehGregor> | "www" is remarkable, as an abbreviation that takes like twice as long to say as the thing it ostensibly abbreviates. |
| 21:12 | <Hixie> | it's an abbreviation for writing |
| 21:12 | <Hixie> | not talking |
| 21:13 | <Philip`> | AryehGregor: How do you get "twice"? |
| 21:13 | <Philip`> | given that "w" is three syllables |
| 21:17 | <AryehGregor> | "like" |
| 21:17 | <AryehGregor> | Closer to three times, it's true. |
| 21:17 | <Philip`> | Two is not much like three |
| 21:20 | <TabAtkins> | I pronounce WHATWG as "what"+"wig". |
| 21:20 | <TabAtkins> | And when pronouncing "www" I say "dub dub dub". |
| 21:21 | <TabAtkins> | (A shortening of "dubya", the texan way to pronounce that letter.) |
| 21:21 | Philip` | pronounces WHATWG as "what"+mumble, because he never actually says it out loud and in his own brain he doesn't need to pronounce the entire word to know what he's thinking of |
| 21:22 | <TabAtkins> | I pronounce all of my acronyms as words. HTML is "heh teh mul", CSS is "sess es", etc. |
| 21:26 | <Philip`> | Hixie: The advantages that I remember (slightly shorter since you don't have to write "http://", and can't be accidentally deferenced) don't really seem compelling compared to the disadvantages (more complex to explain, more unnecessary choices when designing vocabularies, ambiguous ownership of identifiers, can't be intentionally dereferenced, ugly) |
| 21:26 | <Philip`> | s/deferenced/dereferenced/ |
| 21:26 | Philip` | wonders if he's forgetting advantages |
| 21:27 | <Philip`> | TabAtkins: You're weird |
| 21:27 | <Philip`> | I thought everyone said "HTML" as four letters :-) |
| 21:28 | <TabAtkins> | Philip`: I save a syllable, and the leftover syllables are easier to say quickly too. |
| 21:28 | <Philip`> | TabAtkins: If the primary requirement is saving syllables, you could just grunt |
| 21:29 | <TabAtkins> | But then other people don't have a chance of understanding me. Plus my language organ isn't trained to recognize or produce meaningfully grunting beyond the existing near-primal sounds we all make. |
| 21:30 | <TabAtkins> | If I set an element's innerHTML with a chunk of code that includes a <script> block, does the script run? |
| 21:32 | <Hixie> | Philip`: yeah that was my conclusion too |
| 21:32 | <gsnedders> | TabAtkins: yes |
| 21:32 | <Hixie> | they're a bitch to remove from the spec though |
| 21:32 | <Hixie> | sheesh |
| 21:33 | <TabAtkins> | gsnedders: I thought so. Thanks. I don't muck about with innerHTML often. |
| 21:33 | <TabAtkins> | (At least not manually - I think jQuery uses it a lot.) |
| 21:35 | <Hixie> | didn't shelley say she rejoined the group? |
| 21:35 | <Hixie> | i don't see her on the list of members |
| 21:35 | <TabAtkins> | She did, yes. |
| 21:35 | <gsnedders> | Maybe she left. |
| 21:41 | Philip` | attempts to confuse himself horribly by using versioned Mercurial queues |
| 21:42 | <Philip`> | so now I've got a remote repository, a local repository, and a local patch repository, and I'm sure I'll forget what changes I've got where |
| 21:44 | <TabAtkins> | This is a bad idea, Philip`. |
| 21:44 | TabAtkins | just keeps all his repos always updated to the same level. |