| 00:00 | <Hixie> | zcorpan_: whatcha testing? |
| 00:00 | <zcorpan_> | <body bgcolor=xxff> |
| 00:00 | <Philip`> | Do you know how many attributes this applies to? (At least <font color> seems to be handled the same, but I don't know about any other colour attributes) |
| 00:00 | <zcorpan_> | parsed as <body bgcolor=#00ff00> in ie7, gecko and opera |
| 00:00 | <Hixie> | zcorpan_: i want to have the spec say that the content attributes always match the markup |
| 00:01 | <Hixie> | zcorpan_: though the DOM attributes might differ |
| 00:01 | <Hixie> | zcorpan_: and the processing might differ a lot |
| 00:01 | <Hixie> | e.g. as in this case |
| 00:01 | <zcorpan_> | Hixie: ok |
| 00:01 | <Hixie> | hopefully that won't break too much |
| 00:01 | <Hixie> | but who knows :-/ |
| 00:01 | <Hixie> | we'll have to find out |
| 00:01 | <Hixie> | possibly the hard way |
| 00:02 | <zcorpan_> | this doesn't have to be handled in the parser, given that safari doesn't |
| 00:02 | <Hixie> | yeah |
| 00:02 | <Hixie> | that was my assumption |
| 00:02 | <Hixie> | people don't generally read back their broken content, in my experience |
| 00:02 | <Hixie> | for presentational stuff, at least |
| 00:02 | <zcorpan_> | indeed |
| 00:09 | Hixie | introduces www-html to modern-day spec writing |
| 00:13 | <Dashiva> | The culture shock will kill them |
| 00:14 | <Hixie> | "I demand to see [multi-million page studies] for *every* single element/attribute..." |
| 00:20 | <Philip`> | Hixie: The currently online algorithm doesn't seem to work at all if you do createRadialGradient(0, 0, 10, 0, 0, 20) because it will start by drawing an infinite circle with the colour at offset 1, then draw nothing in any further steps, when it needs to be drawing an actual gradient pattern instead |
| 00:20 | <Hixie> | a solid colour is exactly what i'd expect for createRadialGradient(0, 0, 10, 0, 0, 20) |
| 00:21 | <Hixie> | since the two circles are completely inside one another and the end one totally overlaps the start one |
| 00:21 | <Philip`> | Oh - that's not what I'd expect, and it's not what any browser appears to give |
| 00:21 | <Hixie> | uri? |
| 00:21 | <Philip`> | I'd expect it to just do a smooth gradient between the two circles I told it to draw a smooth gradient between |
| 00:22 | <Hixie> | i agree, except that one of those two circles is completely on top of the gradient |
| 00:22 | <Philip`> | The top line in http://canvex.lazyilluminati.com/misc/radial/examples.html |
| 00:22 | <Hixie> | createRadialGradient(0, 0, 20, 0, 0, 10) will give you what you describe |
| 00:23 | <Hixie> | (wtf is firefox3 doing) |
| 00:24 | <Philip`> | Which one? FF3a3 (on Windows) is really not doing very well, but that was a strangely broken of Cairo and they've updated since then |
| 00:24 | <Hixie> | top picture of http://canvex.lazyilluminati.com/misc/radial/o-firefox3a3.png is the one that made me say wtf |
| 00:24 | <Philip`> | (FF3a4 appears to match on Windows and Linux) |
| 00:25 | <Philip`> | It looks like they kind of gave up on the whole idea of drawing radial gradients, and thought a coloured blob would be close enough |
| 00:25 | <Hixie> | i don't understand how you can have r0 > r1 and r0 < r1 both have a gradient, while still having the end circle filled with the end colour |
| 00:25 | <Philip`> | You don't have the end circle filled with the end colour |
| 00:26 | <Philip`> | (except when the circles aren't entirely overlapping) |
| 00:26 | <Hixie> | what would you draw then? just the circumferences? |
| 00:27 | <Philip`> | It doesn't seem very useful for cRG(x,y, 10, x,y, 20) to give you a solid colour - if you wanted that, you wouldn't both with a gradient at all - and it requires more effort for people to work out which way around the arguments should go when all they want is a visible gradient |
| 00:28 | <Hixie> | i really don't like the idea of having a condition under which the end circle is filled or not. |
| 00:29 | <Philip`> | It works sensibly (like WebKit and FF2) if you just draw circumferences, or if you start drawing filled circles from the smaller towards the larger (if not overdrawing previously-drawn bits) |
| 00:29 | <Philip`> | ...except only when the smaller circle is contained within the larger circle |
| 00:29 | <Hixie> | can you describe the algorithm without using the words "except" or "but"? |
| 00:32 | Philip` | tries to work out what he was thinking of |
| 00:35 | <Philip`> | The bit at the bottom of http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011186.html is what I think 'works' (matching the "proposed spec" column, which is mostly like WebKit) - just draw circumferences, with circles near +infinity drawn on top of circles near -infinity |
| 00:36 | <Hixie> | have i replied to that mail? |
| 00:36 | <Philip`> | I don't think so |
| 00:37 | <Hixie> | i wonder where it is |
| 00:37 | <Hixie> | it's not in my canvas pile |
| 00:37 | <Philip`> | Oh, odd |
| 00:38 | <Hixie> | oh |
| 00:38 | <Hixie> | gmail thought it was spam |
| 00:38 | <Hixie> | go figure |
| 00:38 | <Philip`> | Oops |
| 00:38 | <Hixie> | ok, rescued it |
| 00:38 | <Philip`> | If I thought you hadn't seen it, I would have pointed it out earlier :-) |
| 00:39 | Hixie | reads |
| 00:39 | <Hixie> | :-) |
| 00:40 | <Hixie> | this e-mail is awesome |
| 00:40 | <Hixie> | i must reply to it and fix the spec appropriately! |
| 00:47 | <Hixie> | well there's irony for you. i write a testcase: http://www.hixie.ch/tests/adhoc/html/canvas/040.html |
| 00:47 | <Hixie> | ...and the only browser that renders the gradient correctly renders the control image incorrectly |
| 00:48 | <Hixie> | ok fixed the test |
| 00:51 | <Dashiva> | "Or have someone officially redefined HTML as a presentational language while I was looking the other way?" |
| 00:51 | <Dashiva> | I'm tempted to say "Yes" and point to the internet |
| 00:51 | <Hixie> | or "hard to say, how long have you been away?" |
| 00:58 | Philip` | finds that Opera and Firefox don't apply globalAlpha to gradients |
| 00:58 | Philip` | adds to list of things to test properly |
| 00:58 | <Philip`> | (At least Safari does it properly) |
| 01:01 | <Philip`> | (Opera doesn't do globalAlpha on images either, which was annoying since it messed up my game's lighting :-( ) |
| 01:18 | <Hixie> | it's amusing how gradients aren't anti-aliased in browsers |
| 01:18 | <Hixie> | radial gradients |
| 01:24 | <Philip`> | They don't antialias linear gradients either |
| 01:24 | <Hixie> | ah |
| 01:24 | <Hixie> | sucky |
| 01:25 | <othermaciej> | smooth gradients need dithering, not antialiasing |
| 01:25 | <othermaciej> | (at least ones that show visible banding) |
| 01:25 | <othermaciej> | ones that are intentionally banded I'd guess are a bit of an unexpected case |
| 01:26 | <Philip`> | Unexpected cases are what make specifying <canvas> fun :-) |
| 01:34 | zcorpan_ | recorded results at http://simon.html5.org/test/html/parsing/color-attributes/ |
| 01:53 | <Hixie> | othermaciej: http://hixie.ch/tests/adhoc/html/canvas/040.html shows the need for anti-aliasing along the top and bottom |
| 01:53 | <Hixie> | othermaciej: the gradient has an edge |
| 01:54 | <Hixie> | i wonder how i can write a good test for checking that browsers don't do premultiplied alpha interpolation |
| 01:54 | <Philip`> | Use getImageData to check the pixel value? |
| 01:55 | <Hixie> | that's not reliable |
| 01:55 | <Hixie> | ideally i just want a visual test |
| 01:55 | <Philip`> | Oh, true, particularly since I think Firefox returns premultiplied components from getImageData |
| 01:56 | <Hixie> | why did you suggest this?: |
| 01:56 | <Hixie> | > * If one of the start circle and end circle is enclosed within the |
| 01:56 | <Hixie> | > other circle, and their circumferences touch in at least one point, |
| 01:56 | <Hixie> | > then the gradient must be rendered as the color at offset 0. |
| 01:59 | <Philip`> | Could draw a gradient from rgba(255,255,255,1) to rgba(0,0,0,0), and if it's being interpolated in premultiplied colour space then it'll be white all the way along (with varying alpha), otherwise it'll be grey in the middle |
| 02:00 | <Hixie> | yeah, i'm actually doing that :-) |
| 02:00 | <Hixie> | http://hixie.ch/tests/adhoc/html/canvas/041.html |
| 02:02 | <Philip`> | http://canvex.lazyilluminati.com/misc/radial/examples.html - 4th, 5th and 6th rows - if you just drew the infinite number of circles to make a cone, the edge of the cone would intersect the viewer's eye, so it wouldn't do colouring over the part of the background that's on the outside of that edge |
| 02:03 | <Philip`> | Or the simpler case is when the two circles are exactly equal, and you're looking down the centre of an infinite cylinder whose edges have zero width, so it wouldn't draw anything at all |
| 02:04 | <Hixie> | yeah for r0=r1 i see the problem |
| 02:04 | <Hixie> | i don't get the problem for the touching != case though |
| 02:04 | <Hixie> | assuming we just draw the circumferences |
| 02:05 | <Hixie> | you still get a cone with zero and infinite radii |
| 02:09 | <Philip`> | When the two circles touch at one point, then all the circles made by interpolating radius and centre will also touch at that same point, and so the areas on the outside of the edge at that point will never be painted because no circle ever extends out in that direction |
| 02:10 | <Hixie> | so? |
| 02:10 | <Hixie> | that's the same as in the not overlapping case |
| 02:10 | <Hixie> | you get non-painted areas |
| 02:10 | <Hixie> | it's more useful than all the same colour, at least |
| 02:13 | <Philip`> | You'd get half the area painted with the colour at offset 1, and the other half not painted at all, which I suppose isn't worse than painting the whole area with the colour at offset 0; but nobody seems to implement it that way now, and I'd guess they have reasons for doing that (like it being easier, and nobody really caring what the output is) |
| 02:13 | <Hixie> | and you'd get a gradient |
| 02:13 | <Hixie> | tiny one |
| 02:13 | <Hixie> | but a gradient nonetheless |
| 02:14 | <Philip`> | Oops, yes, you'd get the normal gradient inside the circle, and then half the background filled with colour 1 |
| 02:15 | <Hixie> | right |
| 02:16 | <othermaciej> | Hixie: yeah, I looked at that, it does look like the edges of the gradient area at least should be antialiased |
| 02:17 | <Philip`> | It might be a nasty edge case to implement (but I don't know at all so I'm just guessing wildly) - perhaps it'd be easier to pretend the smaller circle had been nudged very slightly inwards, so that they weren't right on the edge any more, and then you'd just draw everything as normal (like what Firefox 2 does, minus the small buggy bits) |
| 02:18 | <Hixie> | i hate exceptions :-) |
| 02:18 | <Hixie> | to me it's just the step between them being completely concentric and them being non-overlapping |
| 02:19 | <Hixie> | or rather, to them being overlapping-or-non-contentric |
| 02:19 | <Hixie> | concentric |
| 02:19 | <Hixie> | and that happens to have a weird edge case |
| 02:19 | <Philip`> | I expect the implementors hate them more, particularly when they have to implement the exceptional case in a complex way just to be theoretically purer :-) |
| 02:19 | <Hixie> | i don't see how this is a complex case |
| 02:19 | <Hixie> | but then i don't know how radial gradients are normally painted |
| 02:19 | <Hixie> | so... |
| 02:20 | <Philip`> | Because nobody implements it by actually drawing an infinite number of circles |
| 02:20 | <Hixie> | sure |
| 02:20 | <Philip`> | but then I don't know how they are implemented either |
| 02:20 | <Hixie> | but how do they paint them? |
| 02:20 | <othermaciej> | with science |
| 02:20 | <Hixie> | btw is there some way to make something appear when alpha is premultiplied that won't appear when alpha isn't premultiplied, that you can think of? |
| 02:20 | <othermaciej> | computer science |
| 02:21 | <othermaciej> | what do you mean by alpha being premultiplied? |
| 02:21 | <othermaciej> | in what place? |
| 02:21 | <Hixie> | gradient interpolation |
| 02:21 | <othermaciej> | what's your expectation of the difference - less fine detail in the gradient? |
| 02:21 | <Hixie> | hixie.ch/www/tests/adhoc/html/canvas/041.html |
| 02:22 | <Hixie> | er http://www.hixie.ch/tests/adhoc/html/canvas/041.html |
| 02:22 | <othermaciej> | (I'm assuming that you don't mean the color stops are treated as being premultiplied by the alpha already, as that would look very different) |
| 02:22 | <Philip`> | (Is there a guarantee that the load event won't be called after setting .src and before setting .onload?) |
| 02:23 | <Hixie> | othermaciej: as i just learnt, if you interpolate from 255,255,255,1.0 to 0,0,0,0, you'll get a different rendering if you do it by premultiplying alpha than if you won't |
| 02:24 | <Hixie> | Philip`: i think i specced it such that setting 'src' doesn't fire the event synchronously, ever |
| 02:24 | <Hixie> | Philip`: and events can't otherwise fire when code is running |
| 02:24 | <othermaciej> | what's an example of a browser that does premultiply? |
| 02:24 | <Hixie> | there are non, to my knowledge |
| 02:24 | <Hixie> | none |
| 02:25 | <Philip`> | Cairo uses premultiplied alpha internally, but does the gradient interpolation correctly as equivalent to linear in non-premultiplied components |
| 02:25 | <othermaciej> | oh I see |
| 02:25 | <othermaciej> | if you premultiply and then treat the interoplated colors as premultiplied, it would be all white |
| 02:26 | <Philip`> | like its premultiplied components go (255,255,255,1.0), (64,64,64,0.5), (0,0,0,0.0), rather than going linearly |
| 02:26 | <Philip`> | (If I remember correctly, Opera uses non-premultiplied internally, but I could be totally wrong) |
| 02:27 | <Hixie> | so i'm looking for something which would show something when you're premultiplying |
| 02:27 | <Hixie> | but wouldn't if you do it right |
| 02:27 | <othermaciej> | CoreGraphics uses premultiplied pixel formats for images, but I guess not in this case |
| 02:27 | <othermaciej> | Hixie: if you made the text grey in your 041.html case that would hold, no? |
| 02:28 | <Hixie> | how do you mean? |
| 02:28 | <othermaciej> | Hixie: well, right now it shows something when *not* premultiplied, but doesn't when you *are* premultiplied |
| 02:28 | <othermaciej> | because the premultiplied gradient is white instead of grey |
| 02:28 | <Philip`> | data:text/html,<canvas id=c></canvas><script>c=document.getElementById('c');ctx=c.getContext('2d');ctx.fillStyle='rgba(12,34,56,0.01)';ctx.fillRect(0,0,1,1);alert(c.getContext('opera-2dgame').getPixel(0,0))</script> - aha, Opera stores non-premultiplied, else it would lose all the precision in the rgb components |
| 02:29 | <othermaciej> | so you could swap the text color to match the other way |
| 02:29 | <Hixie> | othermaciej: the text colour wouldn't be a solid colour then |
| 02:30 | <Hixie> | oh well, i'll just have the positive test, doesn't really matter since everyone passes anyway |
| 02:31 | <othermaciej> | it might only be practically invisible |
| 02:32 | <Hixie> | you'd be surprised how picky QA people can be |
| 02:32 | <Hixie> | like, they complain that "This line should be green" when the line has a green background is a failure because the line isn't green, its background is green. |
| 02:32 | <Hixie> | or they complain that the pixel rounding on the nose of Acid2 is wrong |
| 02:33 | <Philip`> | Perhaps you could draw a gradient with its endpoints millions of pixels apart, so the visible part in the center is a solid colour |
| 02:33 | <Philip`> | and then make the text match that colour |
| 02:34 | <Hixie> | that has the problem with reliability that getPixelData has |
| 02:34 | <Hixie> | no worries |
| 02:34 | <Hixie> | one test is fine |
| 03:39 | <Philip`> | "If multiple stops are placed at the same place on a gradient, they must be placed in the order added" - that sounds a bit awkward with so many 'place'; maybe "If multiple stops are added at the same offset on a gradient, they must be placed in the order added"? |
| 03:43 | <Philip`> | "draw the circumference of the circle with radius of radius r(\omega)" - repetition |
| 03:44 | <Philip`> | "If the two circles overlap, the effect is as if the second (end) circle is painted on top of the first circle. The end circle is always filled with the color of the last stop." - I think both those sentences are wrong with the new definition |
| 05:52 | <Hixie> | Philip`: can you send mail with those? i'll look at them when i next do editing work (prolly tomorrow) |
| 06:14 | <Lachy> | Hixie, thanks for the stats |
| 06:14 | <Lachy> | would it be fair to say that 0.05% is widely used, given that for 1 billion, that equals about 50 million pages? |
| 06:15 | <Hixie> | it's 0.05% used |
| 06:15 | <Hixie> | i can't tell you if that's "widely" or not |
| 06:15 | <Hixie> | depends on the context |
| 06:16 | <Lachy> | fair enough. I can just imagine the response when I send those stats to the list being "that's an insignificant amount, we can drop those elements!" |
| 06:16 | <Hixie> | well that's why i gave the other elements as context |
| 06:16 | <Hixie> | <blink>, <ruby>, <cite>, <dfn> |
| 06:16 | <Lachy> | yeah |
| 06:18 | <Hixie> | for deciding of it should be in the spec or not, one page is enough, if the page is, say, cnn.com |
| 06:19 | <Hixie> | or if the page is the home page of an influential magazine editor |
| 06:19 | <Hixie> | who might review your product |
| 06:19 | <Hixie> | for deciding if it's an important semantic... it's a harder call |
| 06:19 | <Lachy> | yeah, well there are plenty of major web development related sites that use those elements |
| 06:20 | <Hixie> | in practice, i've been adding elements from HTML4, and mostly dropping attributes |
| 06:20 | <Hixie> | might need to revisit some, we'll see |
| 06:20 | <Hixie> | <samp> is used very rarely, iirc |
| 06:20 | <Lachy> | well, even if people only use it to get the monospace font for code samples, that's better than <font family=""> |
| 06:20 | <Hixie> | might be able to drop that one without too much issue |
| 06:20 | <Lachy> | face="", even |
| 06:20 | <Hixie> | yeah |
| 06:20 | <Hixie> | well |
| 06:20 | <Hixie> | we could readd <Tt> |
| 06:20 | <Hixie> | if that was the concern |
| 06:21 | <Hixie> | but *shrug* |
| 06:21 | <Hixie> | i'm inclined to just keep the four of them as is |
| 06:21 | <Lachy> | given the objections to <b> and <i> so far, I don't think redefining <tt> would go down well |
| 06:21 | <Hixie> | i need to do the study for headers="" that i described in www-html |
| 06:21 | <Hixie> | that too |
| 08:29 | <mikeday> | the HTML5 spec instructs user agents to treat ISO-8859-1 as Windows-1252 |
| 08:29 | <mikeday> | should they also treat US-ASCII as Windows-1252? |
| 08:30 | <mikeday> | I mean, it makes sense to do so... |
| 08:30 | <othermaciej> | possibly - should probably test in Win IE, and see if any pages report themselves as US-ASCII |
| 08:32 | <mikeday> | just take a Windows-1252 page with a bunch of 8-bit characters and mislabel the encoding I suppose |
| 08:32 | <Hixie> | iirc IE treats US-ASCII as US-ASCII |
| 08:32 | <Hixie> | it strips the 8th bit |
| 08:32 | <Hixie> | might be a security whole, in fact |
| 08:32 | <Hixie> | hole even |
| 08:32 | <mikeday> | hi Hixie |
| 08:33 | <Hixie> | hi |
| 08:33 | <mikeday> | so it's just ISO-8859-1 that's ignored then |
| 08:33 | <othermaciej> | strips the 8th bit? |
| 08:33 | <othermaciej> | wow |
| 08:33 | <othermaciej> | that's definitely dangerous compared to skipping characters with the high bit set |
| 08:33 | <Hixie> | you'd have to test it to see |
| 08:33 | <Hixie> | i may be wrong |
| 08:33 | <mikeday> | or turning characters with high bit set to U+FFFD, as HTML5 would require I guess |
| 08:33 | <Hixie> | or they may have fixed it |
| 08:35 | <mikeday> | hmm, looks like it's stripping the 8th bit here |
| 08:35 | <mikeday> | (in IE 6) |
| 08:37 | <mikeday> | 0xC0 becomes 0x40 |
| 08:37 | <mikeday> | � -> @ |
| 08:37 | <mikeday> | will this behaviour go in the spec too? :) |
| 08:45 | <Hixie> | no |
| 08:45 | <Hixie> | it's a securty nightmare |
| 08:45 | <Hixie> | i wonder how easy it would be to trick IE into thinking the harset was US-ASCII |
| 08:46 | <mikeday> | eg. write <script> and such but with the high bit set? |
| 08:47 | <Hixie> | yah |
| 08:47 | <mikeday> | just to be absolutely clear, I assume that the high bit -> U+FFFD applies when in US-ASCII, right? |
| 08:47 | <Lachy> | I don't understand why Jukka doesn't think your sample from Google's cache isn't a valid sample |
| 08:47 | <Hixie> | mikeday: i dunno, does US-ASCII have a spec that says how to map 8-bit characters to unicode? |
| 08:48 | <othermaciej> | google doesn't give enough weighting to sites that are authored with correct semantics |
| 08:48 | <mikeday> | hmm, I don't think the spec for US-ASCII (which spec, anyway?) says anything about bytes > 127 |
| 08:48 | <othermaciej> | google should probably just refuse to show invalid sites when you do a search query |
| 08:49 | <Lachy> | othermaciej, isn't that a good thing, since it's representative of the whole web, not just the proportion of semantically correct pages |
| 08:49 | <Hixie> | Lachy: he's right. if you don't work from the assumption that i'm not trying to pull a fast one, you have no reason to trust my data. |
| 08:49 | <mikeday> | heh, that would certainly save google indexing space :) |
| 08:49 | <Hixie> | othermaciej: actually, it's probably the opposite :-) |
| 08:49 | <Hixie> | yeah seriously, we could save so much disk space if we only had to store the four valid pages |
| 08:50 | <Hixie> | Lachy: see also mail i just sent |
| 08:51 | <othermaciej> | personally I'd prefer an experiment that was reproducible, even if it was based on a smaller sample set |
| 08:51 | <othermaciej> | but I also think Hixie has no motive to falsify the data and the odds of error are fairly low |
| 08:52 | <mikeday> | (if I may satisfy my morbid curiousity, is this a publically archived argument that you're discussing?) |
| 08:53 | <Lachy> | see www-html |
| 08:54 | <Hixie> | othermaciej: yeah, i'd really really love to have people reproduce this |
| 08:54 | <Hixie> | othermaciej: don't really know how to do it though |
| 08:55 | <Hixie> | othermaciej: where "it" is "find a representative sample without using google's resources" |
| 08:55 | <othermaciej> | still, the claim to being scientific would be better |
| 08:55 | <Hixie> | well, i've never made a claim to being scientific |
| 08:55 | <Hixie> | in fact quite the opposite :-) |
| 08:55 | <othermaciej> | well, it would be possible to make a claim to being scientific |
| 08:55 | <Lachy> | unfortunately, few people have the recources available to reproduce a study of billions of documents, though we could do it on a smaller scale of thousands of pages |
| 08:56 | <othermaciej> | I wonder if any site has a readily publicly available representative corpus of web documents |
| 08:56 | <Hixie> | i'd love e.g. yahoo or microsoft to do something like this |
| 08:56 | <Hixie> | othermaciej: yeah the problem is making that sample is Really Hard (tm) |
| 08:57 | <Hixie> | othermaciej: because any crawling strategy is inherently biased towards front pages until you have several million pages |
| 08:58 | <othermaciej> | bias towards front pages is not the worst thing but I guess it would bury a lot of important data |
| 08:59 | <Lachy> | bias toward front pages is probably quite a good thing, since it lowers the chance of a relatively unimportant set of pages skewing the results |
| 09:00 | <Hixie> | bias towards front pages is really, really visible in results |
| 09:00 | <Hixie> | it makes a huge difference |
| 09:00 | <Hixie> | front pages have massively different characteristics |
| 09:00 | <Hixie> | far more than i expected |
| 09:00 | <Lachy> | oh, I think I misinterpreted what you meant by front pages. do you mean like the home pages of sites? |
| 09:01 | <Hixie> | yeah |
| 09:01 | <Hixie> | what did you mean? |
| 09:02 | <Lachy> | from your email, you said "biased by what Google has algorithmically established would be most "interesting" to its potential users". I just assumed you were also referring to pages with higher page rank |
| 09:06 | <Hixie> | aah |
| 09:08 | <othermaciej> | whoah |
| 09:08 | <othermaciej> | I can't believe someone things the fact that some accessibility software ignores headers="" in favor of heuristics is an argument *for* having headers="" in the spec |
| 09:10 | <Hixie> | yeah that didn't really make sense to me either |
| 09:10 | <Hixie> | but there were some good points made on that threatd so i saved thosee-mails for when i look at tables next |
| 09:14 | <mikeday> | hmm, did you just say you're looking at tables? will that include layout issues, or just element usage/semantics? |
| 09:14 | <othermaciej> | I'm glad I am not on www-html |
| 09:15 | <othermaciej> | I don't think I could remain reasonably polite |
| 09:15 | <Hixie> | mikeday: i will in due course look at both. right now i'm doing canvas. |
| 09:18 | <mikeday> | I must say I rather like the <code> tag |
| 09:18 | <mikeday> | even if sometimes it only really means "make this monospace" |
| 09:19 | <Hixie> | wow, jukka is, ah, rude |
| 09:20 | <mikeday> | is the whole argument over whether "sample" means "random sample" ? |
| 09:20 | <Hixie> | no idea |
| 09:20 | <Hixie> | i don't know what he's talking about |
| 09:20 | <Hixie> | since the data in question is indeed a statistical sample |
| 09:21 | <mikeday> | maybe easier to say "subset" of the web |
| 09:21 | <mikeday> | as that's unarguable |
| 09:21 | <Hixie> | depending on how you define the sampling frame, it's either a 100% sample of the sampling frame, or a biased sample of the sampling frame, biasing towards "interesting" pages |
| 09:21 | <Hixie> | yeah |
| 09:22 | <Hixie> | i don't think he's really interested in the actual data |
| 09:22 | <Hixie> | looks like he just wants to argue |
| 09:22 | <Hixie> | you know, i think what's happened is that a lot of people have been saying for years that html5 is not legit, that it's a stupid project, that html is dead |
| 09:23 | <Hixie> | and now that the w3c has taken html5 as the base for the next version of html, and said html is indeed alive and well, they feel somewhat cheated |
| 09:23 | <mikeday> | HTML: I'm not dead yet! |
| 09:24 | HTML | is alive |
| 09:24 | <mikeday> | if Google follows the information destruction policy as described in The Onion |
| 09:24 | <Lachy> | HTML has been intensive care for a few years, though it's starting to stabalise now |
| 09:24 | <mikeday> | then it will only be a matter of time before your sample is a 100% sample :) |
| 09:25 | <mikeday> | http://www.theonion.com/content/node/40076 |
| 09:28 | <Lachy> | lol :-) |
| 09:30 | <mikeday> | if there is "paving the cowpaths" for standardising common idioms |
| 09:30 | <mikeday> | how to say "getting rid of stuff no one uses"? |
| 09:31 | <Lachy> | if google purge can be extended to purge all non-conforming web pages, that would solve all out backwards compatibility issues |
| 09:31 | <othermaciej> | "Don't be evil, unless it's necessary for the greater good." |
| 09:31 | <mikeday> | Lachy, that's called "pulling the plug on the entire web" |
| 09:31 | <mikeday> | (except for the four valid pages mentioned earlier) |
| 09:32 | <Lachy> | yeah, well, there are plans to replace the entire web. There was an article about it, mentioned on slashdot |
| 09:34 | <othermaciej> | we weill rewrite the web in valid xhtml2 |
| 09:35 | <mikeday> | might as well fix HTTP and come up with a better URL mechanism while you're at it |
| 09:36 | <zcorpan> | it boiled down to replacing the earth last time this came up... :) |
| 09:36 | <mikeday> | why stop there? some of the laws of physics could be improved :) |
| 09:36 | <zcorpan> | oh indeed |
| 09:36 | <mikeday> | tweak electromagnetism to reduce the latency of my connection, thanks :) |
| 09:37 | <zcorpan> | lol |
| 09:37 | <Lachy> | the earth is already dead, we're all moving to that new planet 20 light years away |
| 09:38 | <zcorpan> | we need a planet that is flat |
| 09:38 | <mikeday> | hmm, by the time we get there, everyone will have reached agreement on the semantics of elements in HTML5 (maybe) |
| 09:38 | <Lachy> | you can't go down hill skiing if the whole planet is flat |
| 09:38 | <Lachy> | we need one on a slope |
| 09:39 | <mikeday> | a world on the inside of a giant bowl would be handy |
| 09:39 | <mikeday> | then you could have your skiing, |
| 09:39 | <mikeday> | and we could use microwave links from any point to any other point on the bowl |
| 09:40 | <Lachy> | no, not a bowl, we'll all be eaten the the flying spagetti monster |
| 09:40 | <mikeday> | :) |
| 09:40 | <othermaciej> | whoah, what do "char" and "charoff" attributes on <td> mean? |
| 09:41 | <othermaciej> | mikeday: we will use a mix of XRIs, IRIs and CURIEs, and HTTP-NG |
| 09:41 | <mikeday> | char is for alignment, right? |
| 09:41 | <zcorpan> | alignment of a column, yes |
| 09:42 | <zcorpan> | does <td char> mean that you align the cell at a char against itself? |
| 09:42 | <Lachy> | they're for aligning cells based on teh position of a character, so for example you could align all the decimal points |
| 09:42 | <mikeday> | why were IRIs necessary at all, why not URI v2 or URI++ or something? |
| 09:43 | <zcorpan> | URL5 |
| 09:43 | <mikeday> | right! |
| 09:43 | <mikeday> | someone totally needs to write that spec |
| 09:44 | <mikeday> | and by someone I mean Hixie |
| 09:44 | <Lachy> | what's wrong with IRIs, other than the name? |
| 09:44 | <mikeday> | :) |
| 09:44 | <mikeday> | Lachy, the name is bad enough, and the fact that they're 10 years too late |
| 09:44 | <mikeday> | aside from that, no objections :) |
| 09:45 | <Hixie> | the main problem with IRIs is that they're not backwards compatible with pages that use non-ascii characters and that are not encoded as UTF-8 |
| 09:45 | <Hixie> | but apart from not being compatible with most of the wb, they're fine |
| 09:45 | <Lachy> | while we're at it, Hixie should write CSS5, XML5 (take it over from anne), JavaScript5, FooML5, etc. |
| 09:45 | <Hixie> | let's do HTML5 first |
| 09:46 | <Hixie> | maybe i can then use my experience with web standards to start UN5 |
| 09:46 | <mikeday> | heh |
| 09:46 | <mikeday> | that'd be a riot |
| 09:46 | <mikeday> | "no one obeys these laws, so let's drop 'em" |
| 09:47 | <mikeday> | (regarding, say, file sharing) |
| 09:47 | <othermaciej> | wow, a lot of pages use <ruby> |
| 09:48 | <Philip`> | More than <perl>? |
| 09:48 | <zcorpan> | <sam> <ruby> |
| 09:48 | <othermaciej> | no, the tag |
| 09:48 | othermaciej | rolls his eyes in exhasperation |
| 09:48 | <Hixie> | hah |
| 09:48 | <Hixie> | and yeah |
| 09:49 | <mikeday> | is Ruby defined in an HTML specification, or only in XHTML? |
| 09:49 | <zcorpan> | XHTML |
| 09:54 | <Hixie> | html5 will define it in due course |
| 09:54 | <Hixie> | in a simplified version |
| 09:54 | <mikeday> | by the way, line 33057 of the HTML5 spec has an unescaped <, which appears to be a parse error |
| 09:54 | <Hixie> | with error handling |
| 09:54 | <Hixie> | mikeday: it'll get fixed in due course. don't worry about typos and stuff :-) |
| 09:55 | <Hixie> | bed time |
| 09:55 | <Hixie> | nn |
| 09:56 | <othermaciej> | I think XHTML incorporates it by reference from a separate spec |
| 09:57 | <othermaciej> | I have to learn more about why some people think modules and profiles and such are so cool |
| 09:57 | <othermaciej> | and namespaces |
| 09:57 | <othermaciej> | I have a hard time grasping how having many dialects and many languages could improve communication |
| 09:58 | zcorpan | doesn't get it either |
| 09:59 | <othermaciej> | I think it has to do with the desire to have everything be defined |
| 10:00 | <othermaciej> | since not everything can practically be predefined, you need a way to make your own dictionaries |
| 10:00 | <zcorpan> | doesn't class="" allow for that? |
| 10:03 | <othermaciej> | no, because it just lets you *use* things, without linking to a definition of them |
| 10:03 | <othermaciej> | thus profile="", or role="" with RDFa |
| 10:05 | <zcorpan> | ah, right. because the UA magically knows about the semantics if you link to a definition |
| 10:05 | zcorpan | has heard the same thing about shemas |
| 10:06 | <zcorpan> | "browsers can't know what a custom attribute means unless it's defined in the DTD" |
| 10:07 | <Lachy> | would it be possible to define a simplified version of role="" (or equivalent) without all the RDFa and namespace stuff, which could be used just for predefined values, leaving class for author defined values |
| 10:07 | <Lachy> | I am assuming that we can actually get clear use cases from its advocates |
| 10:09 | <othermaciej> | a non-extensible role="" doesn't seem very useful |
| 10:10 | <Lachy> | it's just as useful in reality as one that's extensible using RDFa |
| 10:10 | <Lachy> | we could just leave it up to a microformat-like community to define the extensions for it |
| 10:11 | <mikeday> | darn, Hixie's already gone |
| 10:11 | <mikeday> | Hixie, if you happen to read this, consider making support for UTF-32 optional in HTML5! Thank you. |
| 10:11 | <zcorpan> | mikeday: why? |
| 10:12 | <mikeday> | because it's annoying, and I don't see why user agents should be compelled to implement support for it. |
| 10:12 | <mikeday> | does anyone regularly publish web content in UTF-32? |
| 10:13 | <zcorpan> | is utf-32 currently required? |
| 10:14 | <Lachy> | I don't believe it's required |
| 10:14 | <Lachy> | it's not required for XML either, so it wouldn't make sense to require it for HTML5 |
| 10:14 | <mikeday> | maybe not required |
| 10:14 | <mikeday> | but encoding detection says that FF FE 00 00 |
| 10:14 | <mikeday> | must be treated as being UTF-32 encoding |
| 10:14 | <mikeday> | rather than UTF-16LE followed by a null |
| 10:14 | <othermaciej> | implementing UTF-32 is not hard |
| 10:15 | <Lachy> | it needs to be included in the detection algorithm, but if a UA doesn't support it, it'll obviously fail |
| 10:15 | <mikeday> | actually, what is the procedure for unsupported encodings, fallback to Windows-1252 or similar? |
| 10:16 | <mikeday> | ah, "Otherwise, use an implementation-defined or user-specified default character encoding." |
| 10:17 | <zcorpan> | that's if it can't find an encoding declaration |
| 10:17 | <mikeday> | so if a BOM is found, the meta charset attribute won't be checked |
| 10:17 | <Lachy> | you can't fallback to a different encoding and still expect to get sane results, especially for unsupported UTF-32 |
| 10:17 | <zcorpan> | mikeday: yes |
| 10:17 | <mikeday> | so be careful saving pages in Notepad UTF-8 mode, basically |
| 10:17 | <Lachy> | I suppose, if you get <meta charset="bogus">, you'd have to fallback |
| 10:17 | <mikeday> | as it will screw up Windows-1252 pages |
| 10:18 | <Lachy> | mikeday, how would that screw win1252 pages? They would just be treated as UTF-8, regardless of what the meta says |
| 10:18 | <Lachy> | they'd be non-conforming, though, but they'd work |
| 10:19 | <Lachy> | unless the encoding is declared in the HTTP headers as Win-1252 |
| 10:19 | <mikeday> | hmm, wouldn't it garble some text? |
| 10:20 | <Lachy> | if you saved it as UTF-8 using notepad, which will add the BOM, the whole file will be encoded as UTF-8, so that's not a problem |
| 10:20 | <mikeday> | right :) |
| 10:20 | <mikeday> | hmm, I think I've found a UTF-32 BOM related bug in html5lib |
| 10:21 | <mikeday> | it checks for the UTF-16 BOM before checking for the UTF-32 BOM |
| 10:21 | <mikeday> | which means FF FE will always match UTF-16, and UTF-32 will never be returned |
| 10:21 | <mikeday> | which is why I don't like UTF-32 autodetection. |
| 10:22 | <zcorpan> | mikeday: would you like the sniffing algorithm to not look for UTF-32, and forbid UAs to support UTF-32? |
| 10:23 | <mikeday> | zcorpan, it certainly wouldn't bother me if that was the policy |
| 10:23 | <mikeday> | does anyone use UTF-32, ever? |
| 10:23 | <zcorpan> | dunno |
| 10:23 | zcorpan | wouldn't mind either |
| 10:23 | <mikeday> | I've never seen it except in test suites |
| 10:24 | <mikeday> | expat doesn't support it |
| 10:24 | <mikeday> | so it's not widely used in the XML world |
| 10:24 | <mikeday> | it's horrendously inefficient, so it doesn't make sense to use it on the web |
| 10:24 | <zcorpan> | indeed |
| 10:24 | <mikeday> | it only really exists for logical completeness, |
| 10:24 | <mikeday> | as an example of how UNICODE could potentially be encoded |
| 10:24 | <mikeday> | and there's four different potential endianesses for it, which is just stupid |
| 10:25 | <mikeday> | (although HTML5 only mentions two) |
| 10:25 | <zcorpan> | mail the list |
| 10:25 | <mikeday> | alrighty |
| 10:26 | <mikeday> | which list? :) |
| 10:26 | <zcorpan> | whatwg⊙wo |
| 10:31 | <mikeday> | sent |
| 10:31 | <mikeday> | and the crusade to abolish UTF-32 marches on. |
| 10:47 | <Dashiva> | Poor utf-32, what did it ever do to you? |
| 10:50 | <zcorpan> | cause bugs in software? :) |
| 10:50 | <zcorpan> | waste people's time? |
| 11:10 | <Dashiva> | But complaining about it causes +1 posts on whatwg :) |
| 11:40 | <mikeday> | yay, +1 posts |
| 11:40 | <mikeday> | probably time someone specified UTF-64, for people who like even more null bytes in their text |
| 11:41 | <Lachy> | that'd be awesome! cause 64 bit processing is much faster than 32 ;-) |
| 11:42 | <mikeday> | twice the bits :) |
| 11:43 | <mikeday> | <cue Nintendo fan enthusiasm> |
| 11:44 | zcorpan | likes nintendo 8-bit |
| 11:44 | <Lachy> | UTF-128 would be more secure |
| 11:45 | <mikeday> | if UNICODE was a 128 bit character set, |
| 11:45 | <mikeday> | you could represent each character as a bitmap glyph image |
| 11:45 | <mikeday> | no need for fonts :) |
| 11:46 | <zcorpan> | SVG is the replacement of unicode! |
| 11:46 | <zcorpan> | brillant |
| 11:46 | <Lachy> | SVG is also the replacemetn for TTF |
| 11:46 | <mikeday> | of course, then you need a character encoding to encode your SVG in... ASCII? :) |
| 11:47 | <Lachy> | ASCII 5! |
| 11:47 | <mikeday> | more work for Hixie |
| 11:47 | <mikeday> | better begin at the beginning, and define binary5 first |
| 11:48 | <mikeday> | check with Google and see if people use 1 more or 0 |
| 11:48 | <Lachy> | yeah, we should ditch the 8th bit while we're at it. We don't need octets to encode 7 bit encodings |
| 11:48 | <zcorpan> | shouldn't ASCII5 be 5-bit? |
| 11:49 | <Lachy> | we could ditch 28 of the 31 control characters |
| 11:49 | <zcorpan> | and things like ~ |
| 11:49 | <zcorpan> | that aren't used in english anyway |
| 11:50 | <mikeday> | dropping ~ might make it difficult to find your home directory |
| 11:50 | <mikeday> | drop uppercase letters would be better |
| 11:51 | <zcorpan> | yeah |
| 11:51 | <mikeday> | you could always use some kind of stateful caps character if necessary |
| 11:51 | <Lachy> | so we're left with LF, TAB, Space, A-Za-z0-9 and a few symbols |
| 11:51 | <Dashiva> | No bell? |
| 11:51 | <mikeday> | have we just reinvented baudot codes? :) |
| 11:51 | <mikeday> | http://en.wikipedia.org/wiki/Baudot |
| 11:51 | <Lachy> | we could redefine NUL to beep whenever its used |
| 12:00 | <mikeday> | yay, I have written a function that checks for a BOM. |
| 12:00 | <mikeday> | Truly, it's all downhill from here. |
| 12:31 | <mikeday> | hmm, C still has no max function |
| 12:32 | <mikeday> | I guess so that language tutorials can still define it as a macro |
| 12:48 | <zcorpan> | http://tom.opiumfield.com/blog/2007/05/15#When:08:46:09 |
| 12:50 | <Lachy> | I like how he disputes my claim about it being useless in practice, by pointing to a spec that isn't really used in practice |
| 12:50 | <zcorpan> | :) |
| 12:52 | <Lachy> | I think Ruby's postulate applies to the problem with the profile attribute: "The accuracy of metadata is inversely proportional to the square of the distance between the data and the metadata." |
| 12:52 | <Lachy> | Sticking the profile in the <head> is too far away from the actual data in the body |
| 13:02 | <zcorpan> | Levels of HTML knowledge |
| 13:02 | <zcorpan> | 1. <i> is presentational! <em> is more semantic. let's replace <i>s with <em>s. |
| 13:02 | <zcorpan> | 2. <em> represents emphasis! not italics. don't use <em> when you mean italics. |
| 13:02 | <zcorpan> | 3. <i> and <em> are sysnonyms. |
| 13:03 | <zcorpan> | s/knowledge/insight/ |
| 13:04 | <Lachy> | I don't quite agree with #3 |
| 13:04 | <Lachy> | <em> usually means emphasis, <i> has context sensitive semantics |
| 13:05 | <zcorpan> | in practice, <em> has context sensitive semantics, too |
| 13:05 | <Lachy> | possibly, but not quite as much as i |
| 13:06 | <zcorpan> | from a markup consumer's pov, there's no benefit in treating them differently |
| 13:08 | <Lachy> | the benefit is more from an authors point of view, cause it allows you to style them differently without having to use classes |
| 13:08 | <zcorpan> | sure |
| 13:20 | <Lachy> | ha, this is awesome. http://hugeurl.com/ |
| 13:20 | <zcorpan> | LOL |
| 13:23 | <Lachy> | this is so much easier to remember http://www.hugeurl.com/?YjJlNTg2ZmUzYzc5NWIwZjZhMzRiZTk2NzBkNmJiMTkmMTMmVm0wd2QyUXlVWGxWV0d4WFlUSm9WMVl3Wkc5V1ZsbDNXa2M1YWxKc1dqQlVWbHBQVjBaYWMySkVUbGhoTVVwVVZtcEdZV015U2tWVWJHaG9UV3N3ZUZacVFtRlRNazE1VTJ0V1ZXSkhhRzlVVm1oRFZWWmFkR1ZHV214U2JHdzFWa2QwYzJGc1NuUmhSemxWVmpOT00xcFZXbUZrUjA1R1pFWlNUbFpVVmtwV2JURXdZVEZrU0ZOclpHcFRSVXBZVkZWYWQxTkdVbFZTYlVacVZtdGFNRlZ0ZUZOVWJVWTJVbFJHVjFaRmIzZFdha1poVjBaT2NtSkdTbWxT |
| 13:23 | <Lachy> | TW1oWlYxZDRiMkl3TUhoWGJHUllZbFZhY2xWc1VrZFhiR3QzV2tSU1ZrMXJjRWxhU0hCSFZqSkZlVlZZWkZwV1JWcHlWVEJhVDJOc2NFaGpSbEpUVmxoQ1dsWnJXbGRoTVZWNVZXNU9hbEp0VWxsWmJGWmhZMVpzY2xkdFJteFdiVko1VmpJMWExWXdNVVZTYTFwV1lrWktSRlpxUVhoa1ZsWjFWMnhhYUdFeGNGbFhhMVpoVkRKT2RGTnJaRlJpVjNoWVZXcE9iMWRHV25STlNHUnNVakJzTkZVeWRHdGhWazVHVjJ4U1dtSkhhRlJXTVZwWFkxWktjbVJHVWxkaVJtOTNWMnhXYjJFeFdYZE5WVlpUWVRGd1dGbHJaRzlqYkZweFUydGFiRlpzV2xwWGExcHJZVWRGZUdOR2JGaGhNVnBvVmtSS1RtVkd |
| 13:23 | <Lachy> | jRWxVYldoVFRXNW9WVlpHWTNoaU1XUnpWMWhvV0dKWVVrOVZiVEUwVjBaYVdHUkhkRmRpVlhCSldWVm9UMVp0Um5KVGJXaGFUVlp3YUZwRlpFOU9iRXB5VGxaa2FWZEdSalpXYWtvd1ZURlZlRmR1U2s1V1ZscFVXV3RrVTFsV1VsWlhiVVpzWWtac00xWXlNVWRWTWtwR1RsaHdWMVl6YUhaV2FrcExVMVpHYzJGR2FHbFNia0p2Vm10U1MxUXlUWGxVYTFwaFVqSm9WRlJYTlc5V1ZtUlhWV3M1VWsxc1NucFdNalZUVkd4a1NGVnNXbFZXYkhCWVZHeGFWMlJIVWtoa1JtUnBWbGhDTmxaVVNURlVNVnAwVW01S1QxWnNTbGhVVlZwM1ZrWmFjVkp0ZEd0U2EzQXdXbFZhYTJGV1RrWlRhM1JYVFZaS1 |
| 13:23 | <Lachy> | VGcEVSbHBsUm1SMVUyczFWMVpzY0ZWWFYzUnJWVEZzVjFWc1dsaGlWVnB6V1d0YWQyVkdWblJOVldSV1RXdHdWMVp0Y0dGWGJGcFhZMGRvV2xaWFVrZGFWV1JQVWpKR1IyRkhiRk5pYTBwMlZteG9kMUl5UlhoYVJXUldZbXR3YUZWdE1XOWpSbHB4VkcwNVYxWnNjRWhYVkU1dllWVXhXRlZzYUZkTlYyaDJWMVphUzFKc1RuUlBWbFpYVFRGS05sWkhkR0ZXYlZaWVZXdG9hMUp0VWs5V2FrWkxVMnhrVjFadFJsWk5WbXcxVld4b2MxWnNXa1pUYkdoWFlXczFkbGxWV21GalZrcHpXa1pvVjJKclNrbFdWbVEwV1ZaWmVGTnJXbE5XUlZVNQ== |
| 13:23 | <Lachy> | dang, it's too long for IRC |
| 13:25 | <zcorpan> | try to feed it through tinyurl |
| 13:25 | <Lachy> | lol |
| 13:26 | <zcorpan> | http://tinyurl.com/39wc8s |
| 13:26 | <zcorpan> | success! |
| 13:26 | <Lachy> | hey, if we point hugeurl at tinyuri, and then point tinyurl to that generated url, we'd get a loop! |
| 13:27 | <Lachy> | oh, that wouldn't work |
| 13:27 | <Lachy> | we'd need to know both URLs before we generate to get a loop |
| 13:28 | <Lachy> | damn! laws of physics get in the way every time :-) |
| 13:42 | <Dashiva> | Lachy: I'm sure you can find a collision somehow |
| 13:49 | <annevk> | fillStyle = "currentColor" is interesting |
| 14:34 | krijnh | is excited |
| 14:34 | <Lachy> | krijnh, excited about what? |
| 14:34 | <krijnh> | Lachy: about meeting annevk next week ;p |
| 14:35 | <Lachy> | ok |
| 14:36 | <annevk> | krijnh, going to Oslo?! |
| 14:36 | <krijnh> | annevk: nah, staying in NL |
| 14:36 | <krijnh> | I'm probably misinformed :) |
| 14:37 | <annevk> | I suppose |
| 14:40 | <krijnh> | Wrt the plans ppk has |
| 14:40 | <annevk> | ah, ok |
| 14:40 | <annevk> | yeah, I hope to attend at some point |
| 14:40 | <annevk> | but for now I'm stuck in other countries |
| 14:40 | <annevk> | currently France |
| 14:41 | <krijnh> | Not too bad I think :) |
| 14:42 | <annevk> | some clouds |
| 14:42 | <annevk> | good food though |
| 14:42 | annevk | had some italian |
| 14:42 | <krijnh> | Pain du stok |
| 16:02 | <csarven> | http://arapehlivanian.com/2007/05/15/design-by-committee |
| 16:38 | <krijnh> | What's up with all these 'Google' referrers on http://krijnhoetmer.nl/irc-logs/ ? :s |
| 16:55 | <Philip`> | zcorpan: I just noticed http://dean.edwards.name/weblog/2007/03/google-it/ had a note about mime-types in Google Code, which sounds like it could be used for serving author-view-of-html5.css directly |
| 16:58 | <zcorpan> | Philip`: cool |
| 16:58 | <Lachy> | heh, I found out where the "Google (Tina Holmboe)" referrers came from. Tina seems a little annoyed http://lists.w3.org/Archives/Public/www-html/2007May/0491.html (see the footnote) |
| 17:00 | <Dashiva> | Calling other people opponents isn't very constructive in a consensus-based activity |
| 17:03 | <Lachy> | I'm getting tired of discussing her anyway, she seems to be trolling a little |
| 17:14 | <krijnh> | Lachy: I mean the Google referrers without search terms |
| 17:17 | <Philip`> | Maybe the front page of Google has a hidden link to your site? |
| 17:17 | <Lachy> | krijnh, I realised that |
| 17:18 | <krijnh> | Philip`: Yeah, perhaps.. |
| 19:19 | gsnedders | installs Opera Mini on his phone |
| 19:26 | <gsnedders> | ergh. network won't allow anything apart from their own shitty browser :\ |
| 19:29 | <gsnedders> | or I've been an idiot. |
| 19:29 | <gsnedders> | (more likely answer) |
| 19:29 | <zcorpan> | http://me.mywebsight.ws/2007/05/15/xhtml-2-and-html-5-who-will-win/ |
| 19:30 | <gsnedders> | zcorpan: Ignorance is bliss. |
| 19:31 | <zcorpan> | yeah well |
| 20:09 | <Dashiva> | "the browser vendors (lazy idiots, get some real work done, espeacily you morons from redmond)" |
| 20:13 | <othermaciej> | telling people what to do is real work, doing it is lazy |
| 20:23 | <Dashiva> | And in one of the articles linked, about xhtml2, "The iframe element, which has always caused problems for users of assistive technologies, will not be missed." |
| 20:24 | Dashiva | sighs |
| 20:24 | <bewest> | othermaciej: this is just more evidence that people blame browser vendors :-) |
| 20:24 | <bewest> | othermaciej: (there was some dispute of that claim, wasn't there) |
| 20:25 | <othermaciej> | of what claim? |
| 20:25 | <othermaciej> | I have to go |
| 20:25 | <othermaciej> | ttyl |
| 20:25 | <bewest> | othermaciej: that vendors recieve blame |
| 20:25 | <othermaciej> | well this guy isn't blaming browser vendors for breaking sites |
| 20:26 | <othermaciej> | he is blaming them for not breaking *enough* sites |
| 20:27 | <Dashiva> | It takes all kinds to make a senseproof argument |
| 20:27 | <bewest> | I think the root is in the idea of laziness. the w3 stopped work on html and produced work that was unused. however, the vendors recieve the blame for this |
| 21:22 | <gsnedders> | vendors are evil! we, the HTML WG, must produce our own perfect implementation regardless of technical limitations! |
