| 00:58 | jwalden | snickers at http://lists.w3.org/Archives/Public/www-archive/2009Feb/0083.html |
| 01:00 | <Hixie> | i use "infrared" vs "ultraviolet" to remember that red is lower in frequency |
| 01:00 | <Hixie> | infra = less, ultra = more |
| 01:01 | <gsnedders> | And now we have Hixie teaching us Latin :P |
| 01:02 | <Dashiva> | Next we'll be analyzing "super slow" |
| 01:21 | gsnedders | wonders how many sig.fig. to give 11.8±14.3 as |
| 01:21 | <jcranmer> | |
| 01:22 | <gsnedders> | Yeah, that seems to be the correct answer |
| 01:22 | <gsnedders> | So how do I state that |
| 01:22 | <gsnedders> | *? |
| 02:49 | <roc> | interesting, Alex Mogilevsky thinks that other browsers will be forced into harsh backwards-compatibility when they have more users |
| 02:50 | <Dashiva> | Does he adjust for IE's lack of updates for many years? |
| 02:50 | <slightlyoff> | roc: he might not be wrong, but remember his perspective |
| 02:50 | <slightlyoff> | roc: he's also tied to a SUPER slow update mechanism |
| 02:51 | <roc> | I think rather that they're tied into a SUPER slow update mechanism *because* of their backward compatibility requirements |
| 02:52 | <roc> | if each release is a compatibility mode you promise to support forever, you'd better not do too many releases |
| 02:52 | <karlushi> | Alex has a point. indeed |
| 02:55 | <Hixie> | roc: part of the problem is also that IE's compliance has been so bad that with each release they've had to break huge amounts of pages |
| 02:55 | <karlushi> | the only way out somehow is an environment with equally distributed market shares, then people use the common set of features. New features taking ages to come into place when all the tiny marketshares have implemented it the same. |
| 02:55 | <Hixie> | roc: whereas most other browsers can add features without anywhere near as much bug fixing breaking things |
| 02:55 | <roc> | Hixie: yes, |
| 02:55 | <Hixie> | roc: (also, they suck at fixing bugs. In IE7 they fixed things people were using for CSS hacks instead of fixing the underlying bugs in many cases, whereas they should have done that the other way around.) |
| 02:56 | <Hixie> | in short, i think alex is wrong :-) |
| 02:56 | <Hixie> | also, hopefully no browser will ever get to >25% market share again |
| 02:56 | <roc> | boy |
| 02:56 | <roc> | that could be a problem for us :-) |
| 02:56 | <Dashiva> | Any browser, or any major version of a browser? |
| 02:56 | <karlushi> | if/when BrowserCool Inc. comes to dominate the market, it will be somehow as bad as IE too, because people will start to develop for specific BrowserCool Inc. features. |
| 02:56 | <karlushi> | BrowserCool Inc. be open source or not |
| 02:57 | <jcranmer> | I'd say that 20-30% is a happy spot for the top browser |
| 02:58 | <jcranmer> | which would imply roughly 3-6 major browsers |
| 02:59 | <jcranmer> | 2 is too few IMHO |
| 02:59 | <karlushi> | jcranmer: indeed |
| 03:03 | <karlushi> | hmm large market shares… another parameter is paid customers. That might be an issue for Opera in the mobile world. If you fix something which breaks the features developed for paid customers. |
| 03:04 | <karlushi> | s/paid/paying/ ? |
| 03:10 | <Hixie> | Dashiva: any rendering engine |
| 03:19 | <roc> | since there are only 4 serious rendering engines, keeping them all at exactly 25% is going to be quite a balancing act |
| 03:23 | <sayrer> | Hixie, so it would be bad if Safari and Chrome both reached 13% market share? |
| 03:24 | <sayrer> | fwiw, I have hard time thinking that would be bad |
| 03:29 | <olliej> | roc: are you dismissing amaya? :-O |
| 03:29 | <olliej> | ;) |
| 03:30 | <olliej> | sayrer: you'd need to lose a bit to get camino to 13% as well of course :D |
| 03:30 | <olliej> | sayrer: actually what are marketshare numbers for camino? |
| 03:30 | <roc> | hey, I didn't say what I thought the 4 engines were |
| 03:31 | <sayrer> | olliej, I don't think we collect that data |
| 03:31 | <olliej> | roc: well you did sya serious rendering engines, so i guess that precludes ie :D -- and webkit for a few hours after hyatt lands large patches ;) |
| 03:47 | <sayrer> | http://blog.mozilla.com/rob-sayre/2009/02/19/google-turns-to-html-5-to-solve-offline-mobile-woes/ |
| 03:47 | <sayrer> | just, you know, fyi |
| 04:08 | <Hixie> | sayrer: yeah, as i keep telling people internally, i hope chrome doesn't get more than 12.5% market share :-) |
| 04:08 | <jcranmer> | judging from my statistics |
| 04:08 | <jcranmer> | it ain't got 2% |
| 04:09 | <sayrer> | it's impressive that they are statistically significant at this point |
| 04:09 | <Hixie> | getting even that much in a few months is quite impressive imho, yeah |
| 04:09 | <Hixie> | what sayrer said |
| 04:09 | <Dashiva> | It can compete with Opera for being the least popular major browser :) |
| 04:10 | <sayrer> | there may not be enough differentiation to give it a hockey stick, like I hear they want |
| 04:10 | <sayrer> | but there are nice things about the product |
| 04:10 | <jcranmer> | my statistics, which over-represents IE 6, has 67% IE, 24.5% FF, 4.9% Safari, 1.9% Chrome, 0.7% Unknown, 0.2% Opera, 0.1% SM or other gecko-based |
| 04:10 | <Hixie> | my main problem with chrome is it doesn't work on mac |
| 04:10 | <Hixie> | grrr |
| 04:10 | <sayrer> | I have like 4 Safari skins, dude |
| 04:11 | <sayrer> | ;) |
| 04:11 | <Hixie> | i want the process separation :-) |
| 04:11 | <jcranmer> | if you take out the overrepresentation of IE 6, you get roughly 60% FF |
| 04:11 | <sayrer> | I think you mean the possible process separation |
| 04:11 | <sayrer> | you never what will happen with lots of tabs open |
| 04:11 | <sayrer> | never know |
| 04:12 | <Hixie> | i notice that you often quibble with the minor details of what i say |
| 04:12 | <Hixie> | for what it's worth unless i'm writing spec text i tend to be quite vague |
| 04:12 | <sayrer> | minor to you |
| 04:12 | <sayrer> | it looks like more of a worldview difference |
| 04:12 | <Hixie> | yes, minor to me |
| 04:12 | <sayrer> | I'm ok with that |
| 04:13 | <Hixie> | i'm fine with worldview differences, i just wish you wouldn't keep saying "no you don't mean that you mean [the same thing just with slightly more precision]" |
| 04:13 | <jcranmer> | I may or may not be indecisive or possibly vague in some things potentially dealing with decisions... |
| 04:13 | <Hixie> | it's tedious and annoying |
| 04:13 | <sayrer> | Hixie, hmm |
| 04:13 | <sayrer> | let me counter with |
| 04:13 | <sayrer> | http://twitter.com/sayrer/status/1224811146 |
| 04:14 | <Hixie> | *shrug* |
| 04:14 | <sayrer> | exactly! |
| 04:15 | <Dashiva> | Keep work and play separate now |
| 04:15 | <Hixie> | sayrer: i don't understand what you want from me |
| 04:15 | <Hixie> | sayrer: re that tweet |
| 04:16 | <Hixie> | sayrer: i try my ass off to help you, and all i get from you is grief |
| 04:17 | <sayrer> | Hixie, I think it is fair to say that I have complained too much without doing enough work. I plan to change that. |
| 04:17 | <sayrer> | Hixie, that tweet was about overuse of the socratic method in whatwg discussions |
| 04:17 | <Hixie> | i don't mind constructive complaints, in fact i welcome them whole heartedly |
| 04:17 | <Hixie> | i would go as far as to say i thrive on them |
| 04:18 | <Hixie> | my problem is with just pointing at things and saying they're wrong and not offering any alternatives -- like, what should we do instead of asking for people's goals? guess what they are? |
| 04:18 | <sayrer> | I don't think we agree on some substantive issues. It's not fair for me to expect you to do things my way. I have to do work if I want things done my way. |
| 04:19 | <jcranmer> | Hixie: obviously it's your job to fix stuff, everyone else is merely just pointing out problems |
| 04:19 | <Hixie> | sayrer: not agreeing is fine, but instead of just saying you don't agree, can you say why you don't agree when you don't agree? |
| 04:19 | jcranmer | notices that many people get very quiet when asked about alternatives |
| 04:20 | <sayrer> | re: "pointing at things and saying they're wrong and not offering any alternatives" - that's exactly right |
| 04:20 | <sayrer> | but I think the discussion of alternatives is lacking concrete examples |
| 04:20 | <sayrer> | you have a concrete example |
| 04:20 | <Hixie> | well your tweet for example |
| 04:20 | <Hixie> | what should we do instead of asking people what their goals are? |
| 04:20 | <Hixie> | how can we evaluate proposals without knowing goals? |
| 04:21 | <sayrer> | Hixie, that was actually written before any of our most recent discussion |
| 04:21 | <sayrer> | the pattern is "oh, you want to do something like HTML 4.1, well OBVIOUSLY you need a rendering section" |
| 04:22 | <sayrer> | but I obviously included a crystal clear indication that I removed the Rendering section |
| 04:22 | <sayrer> | it's right there in the list of things I edited |
| 04:23 | <Hixie> | well in the case of the rendering section, the actual line of argumentation was "i want something for implementors that is 4.0 + canvas" (or some such), which led to the response saying that rendering would be necessary |
| 04:23 | <Hixie> | which seems correct |
| 04:23 | <Hixie> | but that goes back to why i ask for goals |
| 04:24 | <Hixie> | without knowing your goals, how can i know if the rendering section should be in or not? |
| 04:24 | <sayrer> | that's my point -- necessary and correct are the areas we are disagreeing on |
| 04:24 | <sayrer> | not even in direction, just magnitude |
| 04:24 | <Hixie> | if the goal is to provide implementors with an implementation guide, how is rendering not required? isn't that part of what implementors do? |
| 04:25 | <sayrer> | the Rendering section is non-normative |
| 04:25 | <sayrer> | what does it matte |
| 04:25 | <sayrer> | matter |
| 04:25 | <Hixie> | it's non-normative with the understanding that visual browsers are expected to follow it |
| 04:25 | <sayrer> | that doesn't sound like non-normative over here at Mozilla |
| 04:26 | <Hixie> | it's pretty normative for mozilla, apple, google, microsoft, and opera, yeah |
| 04:26 | <Hixie> | at least insofar as interop is desired |
| 04:26 | <Hixie> | (one could imagine that, e.g., minimo might not want to do the rendering the same way as desktop gecko) |
| 04:27 | <Hixie> | (which is why it's not actually normative) |
| 04:27 | <sayrer> | I hope there are always interop problems, I just hope they are always new ones |
| 04:27 | <Hixie> | well there will continue to be old ones if we don't include the rendering section in the spec the browser vendors implement :-) |
| 04:28 | <sayrer> | I am not against the Rendering section |
| 04:29 | <sayrer> | I don't want you to delete it from your document, for example |
| 04:30 | <Hixie> | you seem to be arguing against my arguing that if browser vendors are the target audience, there should be a rendering section |
| 04:30 | <sayrer> | No, it's just a timing issue |
| 04:30 | <sayrer> | there should be a rendering section |
| 04:31 | <Hixie> | i don't understand what is a timing issue. could you elaborate? |
| 04:32 | <sayrer> | I don't think it needs to be in the document I am working on. A new document that obsoletes mine should appear before we hope to get interoperation on that section. |
| 04:33 | <Hixie> | in what way does this apply to the rendering section (which is mostly already implemented) but not the parser (which has zero shipping implementations)? |
| 04:33 | <Hixie> | (the rendering section is far closer to reality than the parser) |
| 04:34 | <sayrer> | the existence of reset.css files make the rendering section not that important, aiui |
| 04:34 | <Hixie> | that seems to be a very different argument. |
| 04:35 | <sayrer> | ok |
| 04:35 | <Hixie> | reset.css only covers a small fraction of the rendering section; it doesn't cover, e.g., all the processing of legacy presentational attributes, etc |
| 04:35 | <sayrer> | oh, that's true |
| 04:36 | <Hixie> | i still don't understand how my line of argumentation for including the rendering section is incorrect, given the above |
| 04:36 | <sayrer> | do you think anyone will change their rendering of legacy presentational attributes in the timeframe I am shooting for? |
| 04:37 | <Hixie> | what timeframe are you shooting for? |
| 04:37 | <sayrer> | something close to the charter as written today (haha, I know) |
| 04:37 | <Hixie> | (and more importantly, i don't understand how this line of argumentation is wrong even at the metalevel. Why is it wrong for me to ask what your goals are, what the timeframe is, etc? you seemed to indicate in your very public twitter that somehow this is a fundamentally incorrect approach.) |
| 04:38 | <sayrer> | the questions aren't wrong |
| 04:38 | <sayrer> | the replies to the answers are wrong |
| 04:38 | <Hixie> | how so? |
| 04:39 | <Hixie> | re the timeframe, i don't see any way that we can get a complete test suite for anything remotely the size of what you are proposing within 15 months, so i don't see any way to achieve that timetable. |
| 04:39 | <Hixie> | in fact, i don't think it would be realistic to expect HTML_4_ to reach the REC point on that timetable on that same timeframe |
| 04:40 | <Hixie> | let alone anything with the level of detail and interop aims of HTML5 |
| 04:40 | <sayrer> | because they level requirements that the answer does not necessarily imply. your assertion that leaving some things as they are in HTML4 makes a spec "pointless" is a good example. |
| 04:40 | <Hixie> | i am certainly open to contradiction, if you have an argument that shows i'm wrong to say that |
| 04:41 | <sayrer> | what if I make a @name conforming with no clarification |
| 04:41 | <sayrer> | <a name>, to be clear |
| 04:41 | <Hixie> | conforming for authors? |
| 04:42 | <sayrer> | for everyone |
| 04:42 | <Hixie> | i don't understand |
| 04:42 | <Hixie> | how is <a name> not already detailed in HTML5? |
| 04:42 | <sayrer> | it is, it's just non-conforming for authors, right? |
| 04:42 | <Hixie> | right |
| 04:43 | <Hixie> | (this is just what XHTML 1.1 changed, HTML5 doesn't do anything new here) |
| 04:43 | <sayrer> | XHTML does not constitute a valid precedent for me |
| 04:44 | <Hixie> | i'm not claiming it to be a valid precedent, just saying that that's where the rule came from |
| 04:44 | <sayrer> | ok |
| 04:44 | <sayrer> | so, if I make it conforming for authors, with no real justification other than not changing HTML4, is that a pointless spec? |
| 04:44 | <gavin_> | Hixie: do you think it is possible for a spec that is incomplete in your eyes to also be useful? |
| 04:45 | <Hixie> | sayrer: authoring criteria are orthogonal to what i'm talking about when i talk about things being vague and undefined. |
| 04:45 | <Hixie> | sayrer: specifically, it's the implementation conformance criteria that i'm worried about if the goal is to have a spec for implementors. |
| 04:46 | <gavin_> | seems to me that your disagreement with sayrer stems from the implication that you don't |
| 04:46 | <Hixie> | gavin_: yes, an incomplete spec can be helpful, if it's is a work in progress and will become a complete spec before it is finished |
| 04:46 | <Hixie> | gavin_: however a spec like HTML4, which leaves massive things undefined, is actually more harmful than helpful on the long run. |
| 04:47 | <gavin_> | don't you think there is a broad spectrum between "html4" and "html5"? |
| 04:47 | <gavin_> | you seem to think there can be no middle ground |
| 04:48 | <Hixie> | gavin_: yes, html5 has covered much of that spectrum as it develops. But for any particular feature, leaving things undefined is worse than not having them at all. |
| 04:48 | <Hixie> | gavin_: so while the spec is a work in progress it's fine to be, well, a work in progress. But when it's called finished, if it has incomplete parts, IMHO that's just going to be harmful. |
| 04:48 | <gavin_> | I don't think sayrer is planning on "leaving things undefined" |
| 04:48 | <gavin_> | he is just omitting them |
| 04:48 | <Hixie> | omitting _features_ is fine |
| 04:49 | <gavin_> | i.e. "not having them at all" |
| 04:49 | <Hixie> | sure |
| 04:49 | <Hixie> | but removing the rendering section, for example, isn't removing a feature |
| 04:49 | <Hixie> | it would be like removing security, or removing performance |
| 04:49 | <Hixie> | it's not a feature |
| 04:49 | <Hixie> | it's an intrinsic part of features |
| 04:50 | <gavin_> | I'm not sure I agree that a spec absolutely must define everything to be beneficial rather than harmful |
| 04:50 | <Hixie> | what would you consider ok to leave undefined? |
| 04:51 | <sayrer> | you're changing the subject |
| 04:52 | <Hixie> | what was the subject? |
| 04:52 | <sayrer> | the better question is "what must be defined in order to help the Web" |
| 04:52 | <Hixie> | that is certainly another question, i don't know if it's better or worse |
| 04:52 | <Hixie> | i'm not really sure how to answer that question |
| 04:53 | <Hixie> | "everything" seems like an easy, yet likely inaccurate, answer |
| 04:54 | <Hixie> | i think the original question about goals is still one that hasn't been answered properly, though; in particular your comment regarding timelines has returned me to a state of confusion |
| 04:55 | <gavin_> | I think the current HTML5 spec, with the rendering section omitted, is a useful document |
| 04:55 | <Hixie> | sayrer: are you really looking to publish something that has two complete implementations in 15 months along with a test suite to prove it? |
| 04:55 | <sayrer> | I think you mean you don't understand the answer to the goals question |
| 04:55 | <sayrer> | the answer is proper, from where I sit |
| 04:55 | <Hixie> | ok, i don't understand the question (didn't i just say telling me i meant something else was annoying to me?) |
| 04:55 | <Hixie> | er |
| 04:55 | <Hixie> | don't understand the answer |
| 04:56 | <Hixie> | gavin_: i think it's useful, yes, but i think it would be harmful to publish a spec as a REC without it |
| 04:56 | <sayrer> | yes, but I also said deeming what is proper/required/implied is annoying |
| 04:56 | <Hixie> | so i stopped doing that |
| 04:56 | <sayrer> | almost! |
| 04:57 | <Hixie> | seriously though, are you really looking to publish something that has two complete implementations in 15 months along with a test suite to prove it? |
| 04:57 | <sayrer> | it looks tough |
| 04:57 | <Hixie> | it looks like it would involve a lot of test writing in your near future :-) |
| 04:58 | <sayrer> | but I'm willing to keep cutting and write tests, too |
| 04:58 | <Hixie> | the problem is there's only so much you can cut |
| 04:58 | <gavin_> | Hixie: I'm not convinced that that is true |
| 04:58 | <Hixie> | e.g. if you cut the parser, you can't test anything anymore |
| 04:59 | <sayrer> | you're right that there is a point where fat turns to bone |
| 05:00 | <Hixie> | i think you would hit that point long before finding a completely interoperable subset |
| 05:01 | <sayrer> | I agree, that doesn't bother me until 15 months from now |
| 05:02 | <Hixie> | ah, i had assumed that you were attempting an achievable goal :-) |
| 05:02 | <Hixie> | if your goal is something that can't be done, then i guess i don't really have any really useful feedback |
| 05:02 | <sayrer> | same to you, buddy. Sam warned you already. |
| 05:03 | <Hixie> | i think we can get two completely interoperable implementations by 2022 |
| 05:03 | <Hixie> | along with a test suite |
| 05:03 | <sayrer> | cool |
| 05:03 | <Hixie> | hopefully i can take a sabbatical after that, too |
| 05:03 | <sayrer> | but those are not the only ingredients you need |
| 05:03 | <Hixie> | oh? |
| 05:04 | <Hixie> | what else do we need |
| 05:04 | <sayrer> | unless you move somewhere outside the w3c |
| 05:04 | <Hixie> | we started outside the w3c |
| 05:04 | <sayrer> | ok |
| 05:04 | <Hixie> | it's not clear to me the w3c will still exist in 2022 |
| 05:04 | <Hixie> | they're in enough financial trouble as it is |
| 05:04 | <sayrer> | fair point |
| 05:05 | <Hixie> | having said that, that doesn't mean that i don't value getting w3c working group consensus |
| 05:05 | <Hixie> | but i think that's achievable too |
| 05:05 | <sayrer> | interesting |
| 05:06 | <sayrer> | achievable despite what the chair tells you? |
| 05:06 | <sayrer> | because i had assumed that you were attempting an achievable goal |
| 05:06 | <Hixie> | i think sam has a distorted view of what the bulk of the working group agrees to |
| 05:07 | <Hixie> | the few votes we've had have had just as much noise before them, yet in all cases so far they passed with overwhelming support |
| 05:08 | <sayrer> | a pyrrhic victory is one possible outcome |
| 05:08 | <Hixie> | i don't think 95% support is pyrrhic |
| 05:08 | <Hixie> | any group with three hundred people will always have some vocal disagreement |
| 05:08 | <Hixie> | whatever the topic |
| 05:09 | <sayrer> | I give your vote more weight than mine, for example |
| 05:09 | <Hixie> | i would likely abstain from most votes of this nature |
| 05:09 | <Hixie> | as i have in the past |
| 05:09 | <sayrer> | hypothetically speaking |
| 05:09 | <sayrer> | I don't believe I've voted either |
| 05:09 | <Hixie> | but i mean, if you assume that 1% of all people will disagree with anything, which is probably pretty accurate, then 300 people means 3 formal objections for any proposal |
| 05:09 | <Hixie> | and we've had fewer than that in the past |
| 05:10 | <sayrer> | consensus is not voting, and it's not unanimity |
| 05:10 | <Hixie> | sure |
| 05:10 | <Hixie> | i do hope to find out how sam intends to establish consensus in a group of mostly quiet observers |
| 05:10 | <sayrer> | would I want to win a vote over the objections of WebKit? no. even if it were 300 to 3. |
| 05:10 | <Hixie> | (it isn't clear to me how to do that) |
| 05:11 | <sayrer> | well, there are two ways of getting consensus. the IETF uses both, at different phases |
| 05:12 | <sayrer> | one is "no objections" |
| 05:12 | <sayrer> | and the other is "we need positive support for this to move forward" |
| 05:13 | <sayrer> | silence is dissent, or silence is assent |
| 05:15 | <Hixie> | well the thing is we'll never have no objections, and we'll always have enough support to bring anything forward, basically |
| 05:15 | <Hixie> | neither really works with groups this size |
| 05:16 | <Hixie> | i agree that there are certain groups -- implementors in particular -- who get veto votes |
| 05:16 | <sayrer> | you don't have support to bring your document forward |
| 05:16 | <sayrer> | so there are at least some edge cases |
| 05:16 | <Hixie> | (but i'm taking care of that long before we get to a consensus check) |
| 05:16 | <Hixie> | oh, i disagree |
| 05:16 | <Hixie> | well |
| 05:16 | <sayrer> | interesting |
| 05:16 | <Hixie> | the document isn't finished |
| 05:16 | <Hixie> | but notwithstanding that issue, i think i could find plenty of people to support publication |
| 05:17 | <sayrer> | that covers one type of consensus |
| 05:17 | <Hixie> | the problem is with a group this size it becomes more a matter of canvassing and PR than about technical quality |
| 05:18 | <Hixie> | like i said, we'll never have no objections |
| 05:18 | <Hixie> | for anything |
| 05:18 | <Hixie> | or at least, anything of any importance |
| 05:18 | <sayrer> | I think HTML5 already suffers from that problem (canvassing and PR) |
| 05:18 | <Hixie> | in the working group? |
| 05:18 | <Hixie> | or externally |
| 05:18 | <sayrer> | both |
| 05:19 | <sayrer> | but that's changing the subject |
| 05:19 | <Hixie> | externally, not much we can do about it. i think it's ridiculous, but it all rather started with the press release when the first draft was released, which i objected to but that, as you say, is another story |
| 05:19 | <sayrer> | I think you need cooperation that you don't have to get a good result |
| 05:19 | <Hixie> | internally, i'm not sure i see it, but i might just be ignoring it |
| 05:20 | <Hixie> | in what sense? |
| 05:20 | <Hixie> | as far as i can tell we have the cooperation of dozens of people from many vendors |
| 05:20 | <Hixie> | i mean just look at the quality of the feedback |
| 05:20 | <Hixie> | especially on the whatwg list |
| 05:21 | <sayrer> | I don't read the whatwg list regularly anymore. The feedback looks good, I agree, but you don't have a good percentage weighted against browser market share. |
| 05:21 | <Hixie> | I agree that Microsoft's involvement is lacking |
| 05:21 | <Hixie> | not sure what to do about that |
| 05:21 | <sayrer> | so is Mozilla's |
| 05:22 | <Hixie> | oh no, mozilla people are heavily involved |
| 05:22 | <sayrer> | somewhat involved |
| 05:22 | <Hixie> | roc, sicking, doublec, and hsivonen are all giving regular feedback on their various parts |
| 05:22 | <sayrer> | yep |
| 05:22 | <Hixie> | and i'm sure i've just insulted people by omission :-) |
| 05:22 | <Dashiva> | Poor Boris |
| 05:23 | <Hixie> | bz, too, yeah |
| 05:23 | <sayrer> | so, 5 people |
| 05:23 | jwalden | feigns mock outrage |
| 05:23 | <Hixie> | jwalden too |
| 05:23 | <jwalden> | barely |
| 05:23 | <jwalden> | I took six months off :-) |
| 05:23 | <sayrer> | but I don't think any of them have authored large bits of your doc |
| 05:23 | <jwalden> | is that really a problem? |
| 05:23 | <Hixie> | and aaronl before his life changed recently |
| 05:24 | <jwalden> | I don't think it's a problem if we're not writing, so long as we're feedbacking :-) |
| 05:24 | <Hixie> | nobody except me has authored large bits of html5 |
| 05:24 | <Hixie> | i've written every word |
| 05:24 | <sayrer> | words yes, ideas no |
| 05:24 | <Hixie> | certainly not ideas, no |
| 05:24 | <Hixie> | many ideas come from the mozilla world |
| 05:24 | <Hixie> | certainly more are always welcome |
| 05:25 | <sayrer> | this isn't really going anywhere. main point: Apple, Google, Opera are overrepresented, Mozilla in the middle, IE underreperesented. |
| 05:25 | <Hixie> | well i'm certainly always happy to get more involvement from mozilla and microsoft |
| 05:25 | <sayrer> | not sure that is something to be fixed |
| 05:26 | <Hixie> | i'm hardly going to turn other people away though :-) |
| 05:26 | <sayrer> | but the fact remains |
| 05:26 | <sayrer> | that is actually a point of disagreement |
| 05:26 | <sayrer> | you should have told Apple and Google to go write a SQL spec |
| 05:26 | <Hixie> | and told mozilal to go write a registerProtocolHandler spec? |
| 05:26 | <Hixie> | mozilla |
| 05:26 | <sayrer> | sure |
| 05:27 | <Hixie> | i don't see why |
| 05:27 | <sayrer> | but maybe that boomerang comes back with you writing the SQL spec |
| 05:27 | <sayrer> | separately |
| 05:27 | <sayrer> | I get that |
| 05:27 | <Hixie> | i guess i should also have told mozilla to do the localstorage api elsewhere |
| 05:27 | <sayrer> | yep |
| 05:27 | <Hixie> | but at the end of the day, that would just have meant that none of those sections would exist |
| 05:28 | <Hixie> | it's not like there are editors out there waiting for things to do |
| 05:28 | <Hixie> | i've been asking for people to take these bits out of html5 for months, in some cases years |
| 05:28 | <sayrer> | I dunno, there are lots of things specified for Gears that aren't in any official spec |
| 05:28 | <sayrer> | they still exists, as far as I can see |
| 05:29 | <Hixie> | unfortunately for me, i don't control google's allocation of resources |
| 05:29 | <sayrer> | and I have been asking you to take these things out of HTML5 for months, if not years |
| 05:29 | <sayrer> | stalemate is over |
| 05:29 | <sayrer> | I took them out |
| 05:29 | <Hixie> | taking them out is only half the problem, they still have to be somewhere |
| 05:30 | <Hixie> | (and it's the trivial half of the problem) |
| 05:30 | <sayrer> | maybe. maybe they are sucky features |
| 05:30 | <sayrer> | I don't pretend to know which are which |
| 05:33 | <Hixie> | anyway |
| 05:33 | <sayrer> | most importantly, please proceed with your document |
| 05:33 | <sayrer> | I don't agree with everything, but I am not in the stop energy business |
| 05:33 | <Hixie> | localStorage and Database will be removed before last call, so they're not relevant to the consensus issue in the htmlwg |
| 05:34 | <Hixie> | well i'm glad to hear it |
| 05:35 | <Hixie> | it doesn't always feel like that's the case :-) |
| 05:35 | <sayrer> | it hasn't always been |
| 05:35 | <sayrer> | and I was wrong to behave that way |
| 05:36 | <Hixie> | woah, it got late |
| 05:36 | <Hixie> | i gotta go |
| 05:36 | <Hixie> | bbl |
| 05:36 | <sayrer> | k, later |
| 05:36 | <Hixie> | good talking to you though |
| 07:10 | <hsivonen> | http://intertwingly.net/stats/internalsearches.html given me the YSoD |
| 07:10 | <hsivonen> | s/given/gives/ |
| 07:10 | <hsivonen> | Philip` been searching? |
| 08:21 | <Philip`> | hsivonen: Yes, I think that was me :-( |
| 08:22 | <Philip`> | (I didn't intend to break the internalsearches page, since I didn't even known it existed until after I'd been trying to break the search results page) |
| 08:40 | <Philip`> | "I think it is fair to say that I have complained too much without doing enough work. I plan to change that." - I wish the HTML WG had more of that attitude :-) |
| 08:40 | <Philip`> | Well, more of the second sentence of that |
| 08:59 | <jwalden> | cleverly done, regardless :-) |
| 09:01 | <Philip`> | You don't need to be at all clever to break XML, you just have to shove U+FFFE into every text box and query string you can find |
| 09:01 | <Philip`> | It's like XSS, where you just have to shove < and " and ' into everywhere, but it's even easier because you get immediate feedback on success |
| 09:14 | <jwalden> | perhaps |
| 09:14 | <jwalden> | maybe it's a small victory given text-processing standards being as they are |
| 09:15 | <jgraham> | gsnedders: Don't use gnuplot |
| 09:17 | Philip` | wonders how something like XOM (as opposed to appending strings and passing them to 'print') would solve the problem of the internalsearches page being broken by characters that are (presumably) scraped from an Apache log file |
| 09:18 | <Philip`> | I assume you'd just get a server-side error message instead of a client-side error message, which isn't much of an improvement |
| 09:27 | <annevk> | so did the former Youtube guy just say Chrome is implementing <video>? |
| 09:27 | <annevk> | sounds nice |
| 09:32 | <hsivonen> | Philip`: at least you could drop stuff on a per-entry basis by catching XOM exceptions very near the point where they are thrown |
| 09:32 | <hsivonen> | Philip`: as opposed to letting them propagate far enough to crash your server app |
| 09:33 | <Philip`> | hsivonen: Hmm, I suppose that could work |
| 09:33 | <Philip`> | Oh no, <canvas> spec changes, now my test scripts will be outdated and broken :-( |
| 09:45 | <gsnedders> | jgraham: Sorry Master. What should I use instead Master? |
| 09:45 | <olliej> | annevk: well given webkit already supports <video> and chrome had disabled it i refuse to believe it would be significant work for them |
| 09:45 | <jgraham> | gsnedders: Almost anything. Veusz is pretty nice |
| 09:46 | <jgraham> | disclaimer: Veusz was written by a postdoc I worked with and I have contributed a little |
| 09:46 | <olliej> | annevk: the gtk people got <video> running with gstreamer in just a few days once we'd got it all implemented |
| 09:46 | <gsnedders> | jgraham: So it's probably buggy? |
| 09:46 | <jgraham> | gsnedders: At least I know the wavelengths of ligt |
| 09:47 | <jgraham> | *light |
| 09:48 | olliej | waits for chrome to nonetheless talk about how awesome they are for implementing a stunning new spec that was already implemented more than a year ago in the engine they use for their browser |
| 09:48 | <annevk> | olliej, interesting |
| 09:48 | <olliej> | annevk: safari3.1 shipped with video in march last year, we had the basics implemented at the end of the previous year iirc |
| 09:49 | Philip` | had <video> with rotations and reflections in WebKitGTK embedded in an OpenGL application, and it even mixed the audio with the applicaton's OpenAL stuff properly, which was quite impressive |
| 09:49 | <olliej> | annevk: it's reasons like that i get irritated by the quantity of standards chrome explicitly disabled in webkit |
| 09:50 | <jgraham> | gsnedders: https://gna.org/projects/veusz/ |
| 09:52 | <hsivonen_> | Am I still connected? |
| 09:52 | <jgraham> | hsivonen_: You seem to be |
| 09:52 | <hsivonen_> | yes, but with wrong nick |
| 09:53 | <Lachy> | What is Rob's draft that rubys is referring to at the end of this? http://lists.w3.org/Archives/Public/www-archive/2009Feb/0085.html (I hope he's not referring to that stuff Rob Burns produced on the HTML4all wiki) |
| 09:53 | <annevk> | from Rob Sayre |
| 09:54 | <hsivonen> | Lachy: http://people.mozilla.com/~sayrer/2009/02/15/html5.html |
| 09:54 | <gsnedders> | There's no TOC :( |
| 09:54 | gsnedders | pimps that spec |
| 09:54 | <hsivonen> | Lachy: context at http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/0c2bbb6ed726800b |
| 10:00 | <Lachy> | I don't understand the point of it. From the description sayrer gave, it seems to include only features that already existed in HTML4, making it little more than just a redefinition of HTML4 in better terms. But what's the point of having that?! |
| 10:01 | <hsivonen> | Lachy: also <canvas> |
| 10:03 | <jgraham> | AFAICT the point seems to be that sayrer wants to get a W3C approved document out that has detailed implementation requirements compared to HTML4 for the same (roughly) featureset in the belief that this will cause implementors to prioritise those features (e.g. the new parser) above features in the HTML 5 draft |
| 10:04 | <jgraham> | This seems to me to be a misunderstanding of the way that browser vendors set their priorities |
| 10:05 | <jgraham> | I guess he might be particularly interested in the case of MS who have been known to use "only a draft" as an excuse before for e.g. CSS 2.1 |
| 10:08 | <annevk> | I suppose it might be useful |
| 10:08 | <Philip`> | And when MS implements bits of the HTML5 draft, the draft then changes underneath them and their implementation is no longer correct |
| 10:08 | <annevk> | if it actually works out in the time frame he wants to |
| 10:08 | <Philip`> | so they can't win :-) |
| 10:10 | <jgraham> | Philip`: That is a fundamental problem of implementing standards. Someone has to move first. (Well the other opion is to have a reference implementation I guess but good luck with that on HTML5) |
| 10:10 | <Hixie> | man, the summary="" discussion is actually getting real data now |
| 10:10 | <Hixie> | from the "keep it" camp |
| 10:10 | <Hixie> | i'm impressed |
| 10:11 | <Hixie> | there's actually reason to reopen the discussion now |
| 10:11 | <Lachy> | I don't see it as useful at all. Sayrer's draft can't reach REC before HTML5 does because if it does, then it won't reflect any subsequent changes in HTML5 |
| 10:12 | <Lachy> | so at best, it can be published in sync with HTML5, but in that case, it's nothing but HTML5 with sections defining most new features hidden |
| 10:12 | <Philip`> | Lachy: Why would it have to reflect any subsequent changes in HTML5? |
| 10:12 | <Lachy> | because then we'd have 2 normative documents defining HTML5 with conflicting requirements |
| 10:13 | <jgraham> | In principle it can define HTML4.5 or whatever |
| 10:13 | <Philip`> | Just change its name to "HTML4.1" and then it won't be a problem |
| 10:13 | <jgraham> | There is a problem is the parser algorithms don't remain exactly in sync for example |
| 10:13 | <Lachy> | but the whole idea of doing that is just pointless |
| 10:13 | <Philip`> | (or at least no more of a problem than having HTML4 and HTML5 both normative with conflicting requirements) |
| 10:14 | <Hixie> | i think it'd be pretty cool to have a 4.1 that was in between 4 and 5 (4's features with 5's detail) |
| 10:14 | <annevk> | yup |
| 10:14 | <Lachy> | but why? |
| 10:14 | <Lachy> | what difference does it make? |
| 10:15 | <Philip`> | Lachy: It seems there's a point in getting a complete stable tested implemented version of HTML4 even if it doesn't have all the features that HTML5 adds, because it'll make the platform core more solid |
| 10:15 | <Philip`> | s/HTML4/HTML/ |
| 10:15 | <Hixie> | Lachy: oh it would be purely a PR stunt, i don't think it would affect implementations at all |
| 10:15 | <annevk> | if he can manage to take it to REC in <2 years as he proposes I think that would be very cool |
| 10:16 | <Lachy> | so just look at the requirments in HTML5 to implement the stuff that was included in HTML4. At most, that requires a stylesheet to hide the sections of the new features. Not a new potentially conflicting spec |
| 10:16 | <Lachy> | well, I'm opposed to doing stupid PR stunts |
| 10:16 | <Philip`> | What about clever PR stunts? ;-) |
| 10:16 | <Hixie> | i don't think it would get to REC and earlier than HTML5 |
| 10:16 | <Lachy> | Philip`, sure. But this clearly isn't one |
| 10:39 | gsnedders | gets annoyed at Hixie using "several messages" as a subject line |
| 10:39 | <gsnedders> | It isn't overly useful to say what it's about |
| 10:39 | <gsnedders> | several messages about what? |
| 10:39 | <gsnedders> | meh. |
| 10:39 | <gsnedders> | /rant |
| 10:39 | <Hixie> | pine automatically sets it to that when i reply to multiple messages that have differnet subject liens |
| 10:39 | <gsnedders> | pine-- |
| 10:39 | <Hixie> | i usually fix it, occasionally i don't notice that teh thread changes subject line |
| 10:40 | <Hixie> | the real -- in my book is for the user agents that keep screwing up the subject lines |
| 10:42 | <Lachy> | wtf? I thought we had pointless discussions on public-html. But now I've seen the 'Why "color"?' thread on www-style! |
| 10:42 | <annevk> | what is the use case for videoHeight/videoWidth btw? why doesn't it apply to <img>? |
| 10:44 | gsnedders | dares to look at the thread he's heard so much about on www-style |
| 10:44 | <gsnedders> | (I haven't looked at it since the Armenian reference) |
| 10:45 | <annevk> | since then there was a klingon reference |
| 10:45 | <hsivonen> | I'm glad tantek called the troll. I wish something were done about the trolling on public-html, too. |
| 10:46 | <gsnedders> | annevk: Yeah, I've seen that now |
| 10:46 | <annevk> | and a certain Philip TAYLOR was seriously upset that glazou did not want localized property names |
| 10:46 | <annevk> | stuff like that cracks me up |
| 10:46 | <Philip`> | (Not me!) |
| 10:46 | <gsnedders> | Philip`: Lies. |
| 10:47 | <hsivonen> | annevk: it's not funny when you've seen similar things proposed seriously for XML vocabularies |
| 10:48 | <annevk> | it's the reason for XML 1.1 |
| 10:48 | <hsivonen> | not precisely, but close |
| 10:48 | <annevk> | and supposedly XML 1.0 5th |
| 10:49 | <Philip`> | I'm not sure Bjoern Hoehrmann's reference to Lingua::Romana::Perligata is an entirely great example of language localisation that is not an utter waste of time |
| 10:49 | <gsnedders> | Philip`: No spoilers, man! |
| 10:50 | <Philip`> | (Well, it's not a waste of time to the extent that it looks like a pretty clever hack, but it's not exactly intended for practical usage) |
| 10:52 | <Philip`> | http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html - "inserto stringum tum unum tum duo excerpementum da. # $insert = substr($string,1,2);" |
| 10:52 | <Philip`> | "You tum entered inquementum tum wordum tum novumversum oraculo scribe." - that's not real Latin :-( |
| 10:54 | Philip` | notes that the same author wrote the Quantum::Superpositions module, which allows Perl variables to store a superposition of values |
| 10:56 | gsnedders | notes Perl is crazy anyway |
| 10:56 | <Philip`> | Yes, but not usually *that* crazy |
| 10:58 | <jgraham> | Hmm. How does it work? It just allows variables to hold multiple values and return one at random? Or something more clever? |
| 11:01 | <Philip`> | A variable can hold multiple values, and can be combined with other variables (e.g. any(1,2,3) + any(10,20) == any(11,12,13,21,22,23)) |
| 11:01 | <Philip`> | and any(1,2,3) < 2 is true, but all(1,2,3) < 2 is false |
| 11:02 | <Philip`> | and if you convert a superposition to a scalar number then it picks one eigenstate at random |
| 11:02 | <jgraham> | Yeah, I just looked at the docs. It doesn't seem too clever but I could be missing something |
| 11:03 | <Philip`> | It's actually kind of a useful feature, and not very quantumy |
| 11:03 | <Philip`> | I think Perl 6 has the any/all thing |
| 11:03 | <Philip`> | (though not the random selection) |
| 11:04 | <Philip`> | The Quantum::Entanglement module is much more quantumy, since it does complex probabilities and all that fun stuff |
| 11:04 | <jgraham> | It don't say it wasn't _useful_ just not that _clever_ |
| 11:07 | <Philip`> | jgraham: I wasn't disagreeing with you, just commenting that it seems to be erring on the left of the usefulness vs cleverness tradeoff scale :-) |
| 11:07 | <Philip`> | whereas Quantum::Entanglement is distinctly less useful |
| 11:12 | <gsnedders> | I think the problem here is you want code to be useful |
| 11:14 | <Philip`> | I don't believe I ever made such a claim |
| 12:10 | <rubys> | Philip`, hsivonen, YSOD fixed. Look at last line of http://intertwingly.net/stats/internalsearches.html |
| 12:29 | <hsivonen> | rubys: cool |
| 12:41 | <hsivonen> | aargh. Mail.app ate my today's posts to the RDFa list |
| 12:42 | <Philip`> | rubys: It does indeed seem to be not broken :-( |
| 13:03 | <rubys> | Philip`: why the frown? |
| 13:05 | <rubys> | lol: I see a number of other attempts. |
| 13:05 | <Philip`> | rubys: It's no fun when things work |
| 13:06 | <rubys> | Taking a string of bytes and displaying it as text is an easy problem. The harder problem is finding all the places where this needs to be done. |
| 13:08 | <Philip`> | Sounds like taking a string of bytes and displaying it as text is the wrong problem to solve |
| 13:09 | <rubys> | In the case of a query, it is the only problem? |
| 13:11 | <Philip`> | I think I mean something like: If you had found the right problem to solve, then you wouldn't have to find all the places where bytes are displayed as text and fix them all individually |
| 13:13 | <Philip`> | (I'm not quite sure what the right problem is, but it's probably at a higher level than the individual lines of code that print text, so that it can prevent there ever being any lines of code that do it wrong) |
| 13:13 | <rubys> | I honestly think that all one can do is move around the problem. As an example, Venus is based on XSLT, which you would think solves a number of well-formedness issues. But it still gets data from outside and that data is still bytes and someplace needs to make that assessment. |
| 13:15 | <Philip`> | I think I tend to like the idea of simplifying error-handling by defining things to not be errors |
| 13:17 | <rubys> | HTML 5's serialization, for example, is a wonderful solution in that regard. But what it means is that some times real problems show up as (at best) garbage, and (at worst) vulnerabilities. As I don't view my weblog as mission critical and more as educational (for me!), the balance is different than one I would recommend to the developer of a typical "shopping cart" application |
| 13:17 | <gsnedders> | http://lastweekinhtml5.blogspot.com/2009/02/html-fives.html — I think we need one more version. |
| 13:25 | <Philip`> | gsnedders: Download the latest copy of the spec, change all mentions of "user agent" to "top hat", add some conformance requirements to ensure interoperability with monocles, then publish it as HatML 5, and your wish will be satisfied |
| 13:32 | <Lachy> | http://wiki.xiph.org/index.php/Timed_Divs_HTML - that document doesn't seem to define the <itext> element at all. It just uses it in examples |
| 13:33 | <Lachy> | I also can't figure out why they chose to prefix it with an 'i'. Other than to avoid the naming conflict with SVG, it seems like a fairly arbitrary choice |
| 13:34 | <hsivonen> | Lachy: to avoid conflict with svg and by analogy with iframe |
| 13:34 | <Lachy> | oh, so it means "inline text"? |
| 13:34 | <Philip`> | Doesn't seem a great analogy since you never get non-inline text |
| 13:35 | <hsivonen> | Lachy: no, it means text that lives in a iframe-like nested browsing context for rendering and security purposes |
| 13:35 | <hsivonen> | I'm not defending the name, just saying how it came about |
| 13:35 | <Lachy> | I like the idea of being able to style them with CSS, since that means Web Fonts could be used instead of relying on the limited choice of available system fonts |
| 13:35 | <Lachy> | hsivonen, ok, that makes sense |
| 13:36 | <Lachy> | for the category attribute, are "CC" and "SUB" the only allowed values? |
| 13:36 | <hsivonen> | Lachy: there's a whole bunch of those |
| 13:36 | <Lachy> | are they listed anywhere? |
| 13:37 | <hsivonen> | Lachy: you'll find it lacks a processing model which makes the proposal hard to discuss at present |
| 13:37 | <Lachy> | oh, here http://wiki.xiph.org/index.php/OggText#Categories_of_Text_Codecs |
| 14:07 | <karlcow> | gsnedders: it reminds me of RSS 3.0 http://www.aaronsw.com/weblog/000574 |
| 14:08 | <gsnedders> | karlcow: What does? |
| 14:09 | <karlcow> | the versions of html 5 |
| 14:09 | gsnedders | wonders how |
| 14:11 | <karlcow> | RSS 3.0 came from Aaron Schwartz because of the versions which was popping up here and there around RSS and all the mess in the discussions. |
| 14:12 | <karlcow> | So aaron created RSS 3.0 (text only) to make an ironic way forward. |
| 14:12 | <karlcow> | I think we need more versions of html5 and specifically satiric and artistic ones to add a bit of sanity in these discussions. |
| 14:14 | <Philip`> | Ironic? It looks like a pretty good idea to me |
| 14:15 | <karlcow> | Philip`: Welcome in Duchamp's world |
| 14:17 | <gsnedders> | karlcow: Oh, don't worry. I'm working on satire for public-html. |
| 14:17 | gsnedders | fears someone will take it as a serious suggestion and get behind it, though |
| 14:17 | <karlcow> | gsnedders: ;) |
| 14:17 | <gsnedders> | Just once this damned physics project is done. :( |
| 14:19 | <karlcow> | gsnedders: the physics project is about? |
| 14:19 | <gsnedders> | karlcow: Chromatic aberration |
| 14:21 | <karlcow> | oh cool |
| 14:21 | karlcow | has suddenly a big memory dive into optics in astrophysics :) |
| 14:25 | <zcorpan> | hmm rss3 looks nice, but it seems none of the people listed on the page have rss3 feeds anymore |
| 14:26 | <karlcow> | zcorpan: poetry. |
| 14:27 | <zcorpan> | would be cool with a text/plain blog with an rss3 feed |
| 14:29 | <zcorpan> | maybe with a commenting system that involved sending email |
| 14:32 | <jgraham> | And admin via telnet? |
| 14:33 | <rubys> | s/rss3/rss5/ |
| 14:34 | <zcorpan> | rubys: i thought rss5 wouldn't be text/plain |
| 14:34 | <Philip`> | I want RSS6, which will incidentally reinvent the entire paradigm of computation and provide a new syntax for XSLT that's easier to learn |
| 14:35 | <jgraham> | rss5 would be tag soup, but with delicious error handling :) |
| 14:35 | jgraham | wishes he had written "spicy croutons of..." |
| 14:35 | <rubys> | in rss5, descriptions would no longer be considered conformant |
| 14:48 | <Philip`> | Descriptions should be deduced by an auto-summarisation algorithm applied to the content of the feed by each consumer application |
| 15:33 | Philip` | looks at some bits of BGP and sees that it's much more of a disgusting hack than he imagined |
| 15:34 | <Philip`> | When a network is advertising a route to another network, it can include a 32-bit number which is conventionally interpreted as two 16-bit numbers, where the first number is effectively a namespace (corresponding to the AS number of some network) |
| 15:35 | <Dashiva> | Lachy: You have to smile more while dancing :) |
| 15:36 | <Philip`> | And then there's a giant database of routing information (150MB gzipped text) which includes 'remarks' sections saying things like 'if you send a route with community value 6730:1x130 (where x is 1, 2 or 3) then we'll add a weight of x onto your route before advertising it to France Telecom' |
| 15:36 | <Philip`> | (except not really as a sentence like that - there's a table with a few dozen of these values) |
| 15:37 | <Philip`> | I suppose it sort of works in practice, but it just really doesn't seem very nice at all |
| 15:37 | <Dashiva> | That sounds like most of the internet |
| 15:39 | <Philip`> | That feature was seemingly designed to provide distributed extensibility, but I can imagine it would be prettier if they gave you more than 16 bits to store all your data in |
| 15:41 | <Philip`> | Aww, how cute, there's one in this database with a little ASCII-art box around their table and a comment saying "Net at Once offer these communities to make the life of our peers and customers more joyful." |
| 15:41 | <Lachy> | Dashiva, did you just watch that old video of me dancing? |
| 15:41 | <Lachy> | or did you see some more recent photos or something? |
| 15:41 | <Dashiva> | Lachy: Lastweek posted it |
| 15:42 | <Lachy> | oh. Took him long enough to discover it. |
| 15:43 | <Philip`> | Maybe I didn't want to post all the photos and videos of WHATWG members all at once, and wanted to spread them over time |
| 15:43 | <Dashiva> | How sneaky of not you |
| 15:46 | <Lachy> | LOL |
| 15:50 | <gsnedders> | Lachy: To ask a more pressing question: Why is there a video of you dancing online? |
| 15:50 | <hsivonen> | my innerHTML impl still crashes. sigh |
| 15:53 | <gsnedders> | Pfff. Writing code that crashes. I just write code that causes the interpreter I use to crash. |
| 15:55 | <Lachy> | gsnedders, the video was created for a presentation I did on the video element in June 2007 at WebJam. |
| 15:55 | hsivonen | used a video of a groundhog eating. much less exciting |
| 15:55 | <Lachy> | it's interesting that Mr Last Week linked to the video in this user's account http://www.youtube.com/user/fredbezies instead of my own. |
| 16:05 | <zcorpan> | http://simon.html5.org/dump/clickjack.html - i guess ClearClick doesn't work here? |
| 16:07 | <hsivonen> | woohoo! I pass zcorpan's tests at http://simon.html5.org/test/html/parsing/fragment/content-model-flag/ |
| 16:10 | <Philip`> | zcorpan: I thought the idea was that ClearClick would take a screenshot of the page, in which the iframe is invisible in your example, and a screenshot of the iframe content, and compare them |
| 16:11 | <Philip`> | Oh, but your thing makes it not invisible, but I was only testing it in Opera where your example doesn't seem to work at all |
| 16:12 | <jgraham> | I think clearclick work in zcorpan's example |
| 16:12 | <Philip`> | Presumably ClearClick doesn't prevent you having iframes that are smaller than their content |
| 16:13 | <Philip`> | so it can only be comparing the pixels that are within the iframe box |
| 16:13 | <zcorpan> | Philip`: opera seems to have a bug where it doesn't send mousemove events properly on the demo |
| 16:13 | <Philip`> | Oh, but your iframe is 500x600 pixels so I guess it'll be comparing all of those pixels |
| 16:14 | <zcorpan> | hmm i guess i could make the iframe smaller but the scrollbars would be overlapping the content |
| 16:14 | <zcorpan> | is there a way to hide the scrollbars? |
| 16:14 | <zcorpan> | scrolling=no? |
| 16:17 | <zcorpan> | hmm actually i can't make the iframe smaller because then the button wouldn't be clickable |
| 16:18 | <zcorpan> | or is it possible to scroll the contents of an iframe? maybe there's an id="" somewhere |
| 16:18 | <Philip`> | Can you make the iframe suddenly pop into visibility just before it's been clicked? |
| 16:19 | <zcorpan> | maybe |
| 16:31 | <zcorpan> | #installTrigger47072 worked for vertical scrolling, maybe that's good enough and i can have a 500x1 pixels iframe following the mouse |
| 16:31 | <zcorpan> | oh actually |
| 16:32 | <zcorpan> | if i make the iframe smaller it will scroll horizontally, too |
| 16:32 | <zcorpan> | sweet |
| 16:35 | <zcorpan> | at least in opera |
| 16:39 | <zcorpan> | uploaded a new version where the iframe is 3x3 pixels |
| 16:39 | <zcorpan> | but it doesn't seem to scroll to the right place in firefox :( |
| 16:40 | <zcorpan> | works in opera and safari, at least |
| 16:40 | <gsnedders> | "the president of Rockstar North stated that the Lost and Damned would have a third of the number of missions as Grand Theft Auto IV, placing its length at approximately 10-15 hours" |
| 16:40 | <gsnedders> | Hmm, I completed GTA IV in around 12 hours |
| 16:40 | <gsnedders> | And a third of that is four hours |
| 16:40 | <gsnedders> | (completed insofar as the storyline) |
| 16:41 | <Philip`> | zcorpan: I don't think the Firefox extension installation is going to work so well in Opera |
| 16:42 | <zcorpan> | Philip`: obviously not, that's not the point of the demo :) |
| 16:45 | <Philip`> | If you don't have scripting enabled, you could still cover the screen in hundreds of tiny iframes |
| 16:45 | <Philip`> | and the user's bound to click on it |
| 16:46 | Philip` | wonders if zcorpan has NoScript installed so he can actually test whether it's blocked by ClearClick |
| 16:46 | <zcorpan> | Philip`: i don't but jgraham does :) |
| 16:47 | <zcorpan> | hmm firefox 3 scrolls to the right place, wonder why trunk didn't when i tested |
| 16:50 | <zcorpan> | clearclick still picks up my clickjack attempt :( |
| 16:50 | zcorpan | goes to drink beer instead |
| 17:00 | <annevk> | wise choice |
| 19:32 | gsnedders | is downloading The Lost and Damned |
| 20:49 | <weinig> | Lachy: ping |
| 20:52 | <Hixie> | any opera people around? |
| 20:52 | <Hixie> | feedback from opera on mozilla's proposed dropping of <eventsource> and replacing of that entire API with a simple new EventSource(); API (name TBD) would be useful |
| 21:44 | <yecril71> | Hixie! If you want more feedback from Microsoft, |
| 21:44 | <yecril71> | the first step would be to make the specification readable |
| 21:44 | <yecril71> | under Microsoft Internet Explorer. |
| 21:45 | <yecril71> | It has been raised that overlaying HTML over hardware-accelerated video need not be supported. |
| 21:46 | <yecril71> | But I think text captions generate the same problem. |
| 21:46 | <scherkus> | yecril71: where did you read that? |
| 21:47 | <yecril71> | About problems with support? On WHATWG discussion group. |
| 21:48 | <yecril71> | It is similar how you cannot have a Swing control overlay a platform control in Java. |
| 21:48 | <yecril71> | (platform controls are called JWT) |
| 21:49 | <yecril71> | Damian Conway�s e-mail address is wrong. |
| 21:55 | <scherkus> | yecril71: yeah just about HTML over hw-accelerated video |
| 21:56 | <scherkus> | same issue with windowed vs. windowless plugins |
| 21:58 | <annevk> | Hixie, simplifying it is probably ok |
| 21:59 | <annevk> | Hixie, note that Opera is already incompatible with the current API |
| 21:59 | <Hixie> | k |
| 21:59 | <Hixie> | oh you didn't actually sync up yet? good |
| 22:00 | <annevk> | it didn't seem worth the effort |
| 22:00 | <annevk> | and I was right |
| 22:00 | <Hixie> | k |
| 22:02 | Philip` | thinks that since Canvex is already intentionally completely inaccessible to all IE users, i.e. most people on the planet, it's not really going to be much of an improvement to just add some fallback text for non-graphical browsers |
| 23:13 | jwalden | kicks address-based moderation again |
| 23:21 | <Lachy> | weinig, yo |
| 23:22 | <Lachy> | I read your question from last night about querySelector() without parameters |
| 23:23 | <Lachy> | I believe that's an issue that WebIDL needs to address |
| 23:26 | <Lachy> | Philip`, the idea of adding alternative content for games like canvex is really pointless, since you could never convey the interactivity and on screen action well enough dynamically. At best, you could provide a brief overview of what it is |
| 23:31 | <Lachy> | Hixie, re section 1.5.4 in the spec <http://lists.w3.org/Archives/Public/www-archive/2009Feb/0090.html>;, my action item is due March 5th, so I still have a little while to work on it. I still need to finish my first response to Larry though |
| 23:41 | <gsnedders> | What's a decent APP client for OS X? |
| 23:41 | <Lachy> | what's an APP client? |
| 23:42 | <gsnedders> | Lachy: As in Atom Publishing Protocol |
| 23:44 | <karlcow> | Lachy: example http://bitworking.org/projects/apptestclient/ |
| 23:44 | <Lachy> | I didn't even know such clients existed, so I don't know. But have you checked iusethis and macupdate? |
| 23:44 | gsnedders | is looking for suggestions, damnit! :P |
| 23:46 | <Lachy> | gsnedders, macupdate.com and iusethis.com will provide you with suggestions if you search |
| 23:46 | <gsnedders> | Esp. of those that can cope with XHTML content with no problem. |
| 23:47 | <Lachy> | I'm not even sure what Atom Publishing Protocol is. I thought Atom was only used for syndication feeds |
| 23:48 | <gsnedders> | Lachy: RFC5023 |
| 23:48 | <karlcow> | gsnedders: if you intend to code one this could be useful http://developer.apple.com/webapps/articles/creatingrestfulclients.html |
| 23:48 | <gsnedders> | karlcow: A client? No. A server? Yes. |
| 23:49 | <gsnedders> | And I'd rather like a client to work with it :) |
| 23:50 | <Lachy> | gsnedders, you should switch to Windows and use a windows client since that's easier to find |
| 23:52 | <gsnedders> | Philip`: I presume you've managed to get cElementTree to output stuff that isn't well-formed? |
| 23:52 | <karlcow> | hmmm just discovered a wiki based on APP http://code.google.com/p/atomicwiki/ |
| 23:52 | <Lachy> | weinig, if you have any more questions about selectors api, then mail public-webapps. Bed time for me. |
| 23:55 | <Philip`> | gsnedders: I've never cared enough to try |
| 23:58 | <sayrer> | what's the URL for that survey of HTML Hixie did? I can never find it |
| 23:59 | <annevk> | sayrer, http://code.google.com/webstats/ |