| 00:07 | <Hixie> | this style sheets blocking scripts stuff is a huge pain |
| 00:07 | <Hixie> | should they block appendChild()ed scripts? |
| 00:07 | <Hixie> | or only parser-inserted scripts? |
| 00:17 | <othermaciej> | hober: linking the design principles will be persuasive to some but may just set off others, so if your goal is persuasion I'd suggest dropping those |
| 00:20 | <Hixie> | someone objected to hidden=""?! o_O |
| 00:21 | <Hixie> | the one thing that is clearly and unambiguously an accessibility improvement? |
| 00:24 | <AryehGregor> | Is it? I mean, in real life, don't UAs for blind users screen-scrape graphical browsers and therefore ignore display:none anyway? |
| 00:24 | <AryehGregor> | I mean, ignore things that are display:none, as visual browsers do. |
| 00:25 | <NickYoung> | one would hope so |
| 00:25 | <AryehGregor> | Some people actually believe in aural stylesheets, don't they? :) |
| 00:27 | <Hixie> | AryehGregor: relying on the style sheet for anything that critical is not a long-term solution |
| 00:28 | <AryehGregor> | I'm not sure why not, since realistically, that's what authors do. So everyone will have to support it anyway. Not that I object to the attribute, it's one of the syntactic-sugar things in HTML5 that it's nice to think about actually being able to use in ten years or so. |
| 00:29 | <daedb_> | Are there *any* new features that hasn't had any objections? |
| 00:29 | <Hixie> | that's circular thinking. Authors can't do anything _but_ use CSS at the moment. |
| 00:29 | <Hixie> | daedb_: there's a lot of them that haven't been noticed by the people complaining, i think |
| 00:30 | <AryehGregor> | Well, I mean, so many authors rely so heavily on CSS to make their sites even basically functional that I can't imagine assistive technology would ever be able to get away with ignoring it. |
| 00:31 | <AryehGregor> | Of course, in well-written HTML, you're better off just ignoring the CSS. I once had a blind user in #mediawiki asking how to turn off all CSS on his wiki for blind users. |
| 00:31 | <Hixie> | HTML5 has added numerous features to try to reduce the need for CSS |
| 00:31 | <Hixie> | (for that kind of semantic-level stuff) |
| 00:32 | <AryehGregor> | I got into a discussion with him about AT, actually. He said Windows AT is horrible and ridiculously expensive, Linux AT is horrible but at least free, and Mac AT is awesome and comes with the OS, IIRC. |
| 00:32 | <daedb_> | Hixie: Maybe that's true, I've just become even more cynical after seeing all the "remove X new feature/element" bugs and discussions that I have a complete lack of surprise when new objections come up. |
| 00:33 | <Hixie> | AryehGregor: don't say that near the accessibility people, they'll say your blind user was biased against AT users |
| 00:33 | <Hixie> | (seriously, any time VO is brought up, the "experts" dismiss it as a toy) |
| 00:34 | <AryehGregor> | VO? Is that Mac's accessibility thing? |
| 00:34 | <AryehGregor> | I would expect Mac to have good built-in accessibility, actually. It's the sort of thing Apple does well. |
| 00:34 | <Hixie> | VoiceOver |
| 00:34 | <AryehGregor> | Whereas I'd also totally expect Windows to have cruddy built-in stuff so everyone has to pay a fortune to get their OS working at a basic level. |
| 00:35 | <Hixie> | oh i agree |
| 00:35 | <AryehGregor> | And I'd also expect Linux to have something built-in that's sort of workable but not really very good. So my expectations were totally satisfied. :P |
| 00:35 | <Hixie> | and that has totally been my experience in practice, playing with the various ATs, too |
| 00:35 | <Hixie> | but we're not "experts", so our experiences and opinions are worthless |
| 00:39 | <Hixie> | annevk: yt? |
| 00:39 | <Hixie> | MikeSmith: yt? |
| 02:00 | <boblet> | Hixie: currently datetime in HTML requires the colon in timezone. In uF wiki it’s recommended to drop colon to avoid confusing timezone and time |
| 02:00 | <boblet> | http://microformats.org/wiki/value-class-pattern#Date_and_time_parsing |
| 02:02 | <boblet> | I’m guessing that HTML spec won’t include colonless style… |
| 02:19 | <AryehGregor> | I've never seen this happen in a Google cache result: http://74.125.113.132/search?q=cache:6v10d8GH4KEJ:aryeh.name/+aryeh+gregor&cd=7&hl=en&ct=clnk&gl=us |
| 02:20 | <AryehGregor> | The thing at the top sort of got squished into the page. |
| 02:20 | <AryehGregor> | Oh, I see, it's not an iframe or anything, they just inject everything into the page as a div. |
| 02:20 | <AryehGregor> | So my styling of <body> threw it off. |
| 02:21 | <AryehGregor> | Freaky. |
| 02:21 | <AryehGregor> | Great use-case for srcdoc="". ;) |
| 03:07 | <TabAtkins> | AryehGregor: Huh, that's new. Cache results always *used* to be iframed, iirc. |
| 04:07 | <MikeSmith> | Hixie, here now |
| 04:09 | <jcranmer> | wait, Hixie's a cat now? |
| 06:48 | <hober> | Hixie: "someone objected to hidden=""?! o_O" yeah, that's what I said. It's why I volunteered to write the counter-proposal--hidden="" is one of the most no-brainer of HTML5 improvements over HTML4. |
| 06:54 | <hober> | othermaciej: hmm. I aim to be persuasive to those who can be persuaded. I'd like to think that, regardless of someone's stance on the Design Principles document *as a whole*, that they still find the specific principles I cite to be reasonable. |
| 06:54 | <hober> | If not, I'm not sure if anything I can write will have any effect. |
| 06:55 | <hober> | That said, if I can reword things so that I make the same points in a way where I don't have to cite the principles, and if that's worth doing in the first place, I could do that, sure. |
| 06:58 | <hsivonen> | how. lots of process email over the weekend... |
| 06:59 | <hsivonen> | s/how/wow/ |
| 08:15 | <annevk> | Hixie, am here now |
| 08:15 | <annevk> | reading da email |
| 09:04 | <annevk> | http://dev.w3.org/csswg/cssom/#serialize-a-css-value |
| 09:04 | <annevk> | anyone with ideas how to rewrite that in a more extensible way? |
| 09:05 | <annevk> | there's value primitives, e.g. CSS <uri> value, CSS <number> value, etc. |
| 09:05 | <annevk> | then properties combine those in weird ways |
| 09:06 | <annevk> | e.g. comma-separated, space-separated |
| 09:06 | <annevk> | some values nest in function-like values, e.g. rect(<number>, ...) |
| 09:33 | <annevk> | I guess I could just declare CSS a mess and do something else :) |
| 09:36 | <Philip`> | Then you'd just be moving onto a less important mess :-) |
| 09:43 | <hsivonen> | looks like the W3C is still in the mobile adaptation land: http://www.w3.org/2010/02/mbui/cfp |
| 09:45 | <hsivonen> | does anyone have keygen test cases? |
| 09:46 | <hsivonen> | looks like googling for keygen is useless, because the work has been taken by the warez d00dz |
| 09:46 | <hsivonen> | s/work/word/ |
| 09:47 | <jgraham> | Hixie: I like "James Graham did most of the work [...] the system is relatively fragile" :) |
| 10:34 | <hsivonen> | does anyone have an example of great video use in a Wikipedia article? |
| 10:41 | <hsivonen> | http://en.wikipedia.org/wiki/Polar_bear is the best example I've found so far (the play-fight video; the nursing video is badly encoded) |
| 11:18 | <annevk> | hmm, it seems implementations preserve more information than needed |
| 11:18 | <annevk> | e.g. absolute length values are not normalized |
| 11:22 | <hsivonen> | yay. http://jilion.com/sublime/video now works in Firefox |
| 11:24 | <hsivonen> | doesn't work in Opera :-( |
| 11:36 | <Necrathex> | hsivonen: very nice :o |
| 11:36 | <Necrathex> | firefox seems rather slow though (compared to chromium) |
| 11:45 | <nessy> | hsivonen: also works on the iPhone - that's nice! |
| 11:46 | <nessy> | though I'm not sure how the source selection picks it since there is no media query or anything else on it |
| 11:47 | <nessy> | works fine for me on Firefox 3.7 |
| 11:59 | <Lachy> | nessy, it seems to use a script, presumably with UA sniffing, for the source selection. |
| 12:00 | <Lachy> | since it's using <source title="http://..."> rather than <source src="http://...">. I'm guessing it changes the title attributes to src attributes based on the detection |
| 12:00 | <nessy> | thanks for tracking it down - I admit I couldn't be bothered ;-) |
| 12:00 | <nessy> | ah, that's a good point |
| 12:00 | <Lachy> | that might explain why it doesn't work in Opera, if they haven't done good UA sniffing |
| 12:00 | <nessy> | I wonder if media queries would really help in this case |
| 12:01 | <hsivonen> | they also aren't using whatever prefix Opera supports for rounder corners |
| 12:01 | <hsivonen> | vendor prefixes for the lose |
| 12:02 | <hsivonen> | so I've promised to give my lecture about HTML5 again tomorrow at my alma mater |
| 12:02 | <hsivonen> | I wonder how much I should edit my slides from the last year... |
| 12:02 | <nessy> | :) |
| 12:03 | <nessy> | I'm going to have a similar challenge next week :) |
| 12:03 | <hsivonen> | I think I'll zap the drag&drop demo |
| 12:03 | <hsivonen> | maybe I should also zap the postMessage demo and show pieces of code instead |
| 12:04 | <hsivonen> | also, it would be nice to have a less violent canvas demo than Wolf3D |
| 12:04 | <hsivonen> | I guess I should talk and show more <video> stuff |
| 12:04 | <hsivonen> | and I should say something about microdata and RDFa |
| 12:05 | <hsivonen> | but I don't really know what to say without getting too much into politics |
| 12:08 | <Lachy> | just talk about the benefits of Microdata, and don't focus on RDFa much at all |
| 12:12 | <Lachy> | that reminds me, I need to write up my proposal for Web Directions South later. The deadline for that is coming up soon |
| 12:12 | Philip` | 's canvas demo is entirely non-violent, because he was too lazy to implement guns |
| 12:13 | <gsnedders> | Philip`: I thought you at least had a multiplayer version somewhere? |
| 12:13 | <Philip`> | Yes, on my hard disk somewhere, but that didn't have guns either |
| 12:14 | <ment> | hsivonen: what's wrong with violent demos? :) |
| 12:14 | <Philip`> | (Just walking, and text chat) |
| 12:14 | <gsnedders> | Yeah, I thought you hadn't implemented that. |
| 12:15 | <gsnedders> | But what the use of a multiplayer FPS without guns is I'm not sure |
| 12:15 | <gsnedders> | Second life in the browser? |
| 12:15 | <Philip`> | You could have an FPS with only melee weapons |
| 12:16 | <hsivonen> | what canvas 3D demo should I show? |
| 12:16 | <Philip`> | Could do something like Second Life, but I'm not sure what the point would be |
| 12:16 | <hsivonen> | (preferrably something that doesn't hang my Intel GPU) |
| 12:17 | <Philip`> | (since Second Life already exists) |
| 12:17 | <hsivonen> | so no complex shaders |
| 12:17 | <Philip`> | (and being in a web browser would just make it technologically worse) |
| 12:18 | <Philip`> | hsivonen: You mean WebGL, rather than 3D emulated in the 2D context? |
| 12:18 | <hsivonen> | Philip`: WebGL, yes |
| 12:18 | <Philip`> | Does it work at all on your GPU? |
| 12:18 | <hsivonen> | maybe I should have a 2D game demo for the 2D context instead of Wolf3D |
| 12:18 | <hsivonen> | Philip`: it does |
| 12:18 | Philip` | doesn't remember when Intel started having GLSL support |
| 12:19 | <hsivonen> | Philip`: sicking's shader-based fractals hang the intel GPU, though |
| 12:20 | <jgraham> | Philip`: Aren't you already working on some game that is quite like a number of existing games? |
| 12:20 | <Philip`> | Maybe there are some X3DOM examples that could work? (since they don't rely on fancy shaders, and demonstrate the ability to provide APIs that are more user-friendly than raw OpenGL) |
| 12:20 | <hsivonen> | does Opera support Drag&Drop yet? |
| 12:20 | <jgraham> | hsivonen: No |
| 12:21 | <Philip`> | jgraham: Yes, but it's not being artificially worsened by putting it in a web browser for no reason :-) |
| 12:24 | <hsivonen> | Maybe I'll throw in geolocation and Web Workers now that HTML5 proper doesn't contain everything I talked about last year anyway |
| 12:24 | Philip` | hasn't used SL-style programs since Alpha World on a dialup modem, where they hadn't even implemented teleportation so he had to run 10km to reach his house on the outskirts of the city, and where one day somebody discovered the .ini file that controls your avatar so everyone in the world changed themselves into chess pieces and lamp posts and floor tiles |
| 12:24 | <Philip`> | Maybe they're a bit more advanced now? |
| 12:26 | <annevk> | hsivonen, where are you presenting? |
| 12:27 | <hsivonen> | annevk: https://noppa.tkk.fi/noppa/kurssi/t-111.5360/esite |
| 12:28 | <gsnedders> | Philip`: Floor tiles? How does that work? |
| 12:30 | <Philip`> | gsnedders: The world consisted entirely of a flat infinite plane of grass, plus a load of objects (textured meshes) that users could create and move and rotate and slightly script |
| 12:31 | <Philip`> | so floors were built out of lots and lots of flat square floor tiles |
| 12:31 | <Philip`> | and there was nothing stopping you picking one of those objects as your avatar |
| 12:31 | <gsnedders> | Philip`: So your avatar was a bunch of flat squares? |
| 12:32 | <Philip`> | No, a single flat square |
| 12:32 | <gsnedders> | That's what I thought when you first mentioned it. |
| 12:32 | <gsnedders> | That must make seeing other people fun |
| 12:32 | <Philip`> | The developers fixed it after a few days, sadly :-( |
| 12:32 | <Philip`> | so you could only be the normal human shape |
| 12:42 | <hsivonen> | I have trouble finding WebGL demos that show something that's obviously not 2D canvas emulating 3D |
| 12:46 | <zcorpan> | device-min-width makes some sense for <source media> |
| 12:49 | <hsivonen> | I think https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/shiny-teapot/index.html is probably most obviously using WebGL and not just emulating stuff in the 2D API |
| 13:00 | <Dashiva> | For all of Shelley's talk about FUD, this message seems like a quite good candidate: http://lists.w3.org/Archives/Public/public-html/2010Feb/0423.html |
| 13:02 | <annevk> | hmm, <canvas> exposes system colors, is that a privacy leak? |
| 13:05 | <workmad3> | annevk: it may be, if you set your system colours to hex-encoded versions of your credit-card numbers and SSN |
| 13:07 | <annevk> | it seems system colors are lost with .fillStyle |
| 13:07 | <annevk> | at least per spec |
| 13:07 | <annevk> | in opera they're always lost it seems |
| 13:07 | <Dashiva> | What about the text api? |
| 13:09 | <annevk> | system colors can presumably be used via fillStyle as another means to uniquely pin down people |
| 13:10 | <annevk> | unless we somehow forbid them in <canvas> and always return them as keywords through DOM APIs |
| 13:10 | <annevk> | it's annoying that when you try to do something relatively simple (serialization of <color>) so many side-issues come up |
| 13:12 | <workmad3> | I'm not sure how much of a privacy leak it is tbh |
| 13:13 | <annevk> | not a whole lot for sure |
| 13:13 | <workmad3> | you could possibly pin down the identity of some people with system colours, but you couldn't pin down the identity of everybody |
| 13:13 | <annevk> | no, but lots of other variables can be used |
| 13:13 | <workmad3> | as most people don't bother changing system colours or use one of a set of pre-defined defaults |
| 13:14 | <Dashiva> | I wouldn't worry about privacy leak, rather that it lets people create more authentic-looking fake chrome |
| 13:15 | <Dashiva> | But I suppose they can do that already? |
| 13:15 | <zcorpan> | they can do that by just using the system colors |
| 13:15 | <annevk> | that's the whole point of system colors |
| 13:33 | <boblet> | annevk: looking at http://www.w3.org/TR/html5-diff/ and noticed 3.1 figure example has <legend> (plus <figcaption> should be in the list) |
| 13:33 | <boblet> | annevk: want me to file a bug somewhere? |
| 13:34 | <zcorpan> | boblet: TR/ means out-of-date (unless we published very recently) |
| 13:35 | <boblet> | zcorpan: yeah, it’s Aug 2009 :) no similar use of bugtracker for TR/ stuff then huh? |
| 13:35 | <annevk> | we don't fix /TR/ drafts |
| 13:35 | <annevk> | see the editor's draft |
| 13:35 | <boblet> | annevk: ok |
| 13:36 | <annevk> | (not even typos are fixed, though sometimes that happens and it will be annotated with "edited in place" or some such, mostly restricted to actual RECs) |
| 13:36 | <boblet> | thanks for explaining the distinction—I trusted the Googl & it let me down |
| 13:40 | <Dashiva> | It's a feature, really |
| 13:40 | <Dashiva> | At least that's what W3C says |
| 13:40 | <boblet> | I should have read the header more carefully |
| 13:41 | <annevk> | it's a bit annoying really |
| 13:41 | <annevk> | snapshots work when you do things in private |
| 13:42 | <annevk> | but when everything is in public and process happens daily, it's sort of a weird thing |
| 13:42 | <annevk> | and rather arbitrary |
| 13:43 | <Dashiva> | Especially when there are multiple drafts that need to be in sync |
| 13:46 | <jgraham> | It only works for private things if you don't care about the fact that all external feedback will be out of date |
| 13:46 | <annevk> | protecting against system colors would be rather hard for the canvas case btw |
| 13:46 | <annevk> | it would either have to forbid them completely or mark the <canvas> as unsafe or some such |
| 13:49 | <workmad3> | could the canvas spec not mandate that the user is informed when system colours are accessed and can allow/deny it when it occurs? |
| 13:49 | <jgraham> | No |
| 13:49 | <workmad3> | fair enough :) |
| 13:49 | <jgraham> | (becuase in general you can't mandate UI) |
| 13:50 | <Philip`> | Dashiva: People can make perfectly authentic-looking fake chrome by screenshotting Windows |
| 13:50 | <jgraham> | But in this specific case it would also be bad because, well, who wants to be asked a question like that |
| 13:50 | <workmad3> | 'warning, this page is trying to look authentic, which may compromise your system security. Do you wish the page to look half decent? <yes>, <no>' |
| 13:50 | <annevk> | this stuff is such a mess |
| 13:51 | <workmad3> | I guess that wouldn't go down well :) |
| 13:51 | <annevk> | anyway, hopefully webkit/gecko people have something to say about it: http://www.w3.org/mid/op.u758kvnh64w2qv@annevk-t60 |
| 13:52 | <jgraham> | Since this kind of attack is only statistical anyway and most people have UIs that look like the default windows UI you may as well just use the default windows UI look |
| 13:52 | <jgraham> | s/use/fake/ |
| 13:53 | <Philip`> | You can check their UA string if you want to be more specific about which version of Windows they use |
| 13:54 | <jgraham> | Indeed. And if for some reason you want to invest more effort than will result in payback you can determine OS X from the UA string too |
| 13:54 | <jgraham> | and fake than when needed |
| 13:54 | <Philip`> | But colours seem like one of the less important parts of UI spoofing - modern UI doesn't even use flat colours, so you care about gradients and shapes and hover effects and fonts |
| 13:56 | boblet | is following foolip’s Chinese proverb |
| 13:59 | <annevk> | TabAtkins, instead of #rrggbbaa we'll get .color.red .color.alpha etc. hopefully |
| 13:59 | <annevk> | (which can be set as well) |
| 13:59 | <Dashiva> | Hum, so the camelData supports multiple hyphens |
| 13:59 | <annevk> | camel? |
| 13:59 | <Philip`> | Like two-hump camels? |
| 13:59 | <Dashiva> | data--whatnot------doquery |
| 13:59 | <Dashiva> | data-Whatnot-----Doquery |
| 14:00 | <TabAtkins> | That'll work too. I'd still like to be able use #rrggbbaa in my stylesheets, though, rather than having to swap over to rgba() syntax and spend a few seconds converting from hex to dec. |
| 14:00 | <Philip`> | Wouldn't #rrggbbaa conflict with the current required parsing of bogus colour strings? |
| 14:00 | <annevk> | TabAtkins, i see, no real opinion on adding extra syntax |
| 14:01 | <TabAtkins> | Philip`: Possibly. Nuts to them, though.e |
| 14:01 | <annevk> | Philip`, it would fail in older browsers and work in newer |
| 14:01 | <annevk> | Philip`, which is how CSS extensions are supposed to work so that seems ok |
| 14:02 | <TabAtkins> | Interestingly, in some cases it would "fail" by parsing as a different color. Though I think it likely that it would just parse as the non-a version. |
| 14:02 | <boblet> | foolip: do you have any advice about hcard in microdata when you want to link the name? itemprop="fn" on separate wrapper? |
| 14:02 | <TabAtkins> | Though :gasp: :shock: :horror: that might require some grammar changes. |
| 14:02 | <annevk> | i don't see why changing the grammar is such a huge deal |
| 14:03 | <TabAtkins> | It's totally not. Bert's just stupid conservative. >_< |
| 14:03 | <annevk> | we should just do it when it makes sense |
| 14:05 | <Philip`> | annevk: I mean that <body bgcolor=#aabbccdd> already has a specific meaning, which presumably is relied on by some pages and can't be changed, and it would be weird if CSS specified a different meaning for the same colour syntax |
| 14:05 | <Philip`> | (Seems it's equivalent to #aabcdd) |
| 14:08 | <annevk> | it doesn't seem too weird to me given that's just legacy |
| 14:12 | <boblet> | has anyone done microformats in microdata? <meta content=""> in spec’s hcard example isn’t working for me in foolip’s interpreter… |
| 14:13 | <TabAtkins> | You have a name on it, right? |
| 14:14 | <TabAtkins> | Sorry, not name. itemprop. |
| 14:15 | <Philip`> | What browser? |
| 14:15 | <Philip`> | Some move <meta> into <head> so it won't parse right |
| 14:16 | <boblet> | TabAtkins: yep <meta itemprop="type" content="work"> for hcard |
| 14:16 | <boblet> | Philip`: Chrome 5 Mac |
| 14:16 | <boblet> | will check dom… |
| 14:17 | <boblet> | (although hold on, this is in http://foolip.org/microdatajs/live/ so that shouldn’t matter, no?) |
| 14:17 | <Philip`> | (I assume it still uses your browser to parse the HTML) |
| 14:18 | <boblet> | Philip`: ah, you’re right |
| 14:18 | <boblet> | the doc currently has 12 <head>s O_o |
| 14:19 | <boblet> | Philip`: is there a way around that? apart from not using content=""? |
| 14:20 | <Philip`> | You could wait until everyone fixes their parsers |
| 14:20 | <annevk> | would be nice if CSS made it more clear what was syntax-level and what's part of the model |
| 14:20 | <Philip`> | otherwise you have to not use <meta>, as far as I'm aware |
| 14:20 | <TabAtkins> | You can use <span itemprop style=display:none;>content</span> for now, if you have to. |
| 14:21 | <boblet> | hrm, sucks that there’s no equivalent of uF’s value-title pattern |
| 14:21 | <Philip`> | The equivalent is <meta>, I thought |
| 14:21 | <TabAtkins> | Yup. |
| 14:21 | <boblet> | this is kind of a common need once you’re not using English |
| 14:22 | <boblet> | heh. I want to reply ‘a method that works,’ but half the uF tools can’t use value-title either |
| 14:22 | <TabAtkins> | It works in the future! |
| 14:22 | <boblet> | TabAtkins: thanks for that :P |
| 14:22 | <TabAtkins> | And a method that works now is what I just described with <span>. |
| 14:23 | <Philip`> | It works in browsers with HTML5 parsers |
| 14:23 | <boblet> | srsly thank you both for the info and the workaround |
| 14:23 | <Philip`> | which is, admittedly, none |
| 14:23 | <TabAtkins> | Well, 1 if you set a pref. |
| 14:23 | <Philip`> | That doesn't count :-p |
| 14:23 | <boblet> | living in the future is harder than the 1960’s made it out to be |
| 14:24 | <Philip`> | Really? Everyone here today managed it |
| 14:24 | <TabAtkins> | And we don't even get flying cars. HUUUUGE disappointment. |
| 14:24 | Philip` | wonders if people predicting flying cars ever looked at traffic accident statistics |
| 14:25 | <boblet> | one more q, are there any other tools for microdata apart from foolip’s that you know of? |
| 14:25 | <TabAtkins> | where's the htmlwg wiki again? |
| 14:26 | <boblet> | bookmarklets, H2VX-equivalent convertors etc… |
| 14:26 | <TabAtkins> | boblet: http://philip.html5.org/demos/microdata/demo.html |
| 14:26 | <Philip`> | boblet: Would you be happy with ancient obsolete ones? |
| 14:26 | <boblet> | Philip`: I’m always happy with your stuff |
| 14:26 | <Philip`> | I never am :-) |
| 14:27 | <boblet> | heh, know the feeling |
| 14:27 | <boblet> | cool that gives me another data point. no converting tools that output a vcard file for download yet tho huh |
| 14:27 | <TabAtkins> | As far as I can tell, Microdata was invented by people named Philip. |
| 14:28 | <Philip`> | I don't think Hixie is named Philip |
| 14:28 | <TabAtkins> | Not ones that take Microdata, unless by "download" you mean "copypasta from foolip's tool". |
| 14:28 | <TabAtkins> | Philip`: Shows what you know. Philip is his middle name! |
| 14:28 | <TabAtkins> | Hixie Philip Hickson. |
| 14:28 | <Philip`> | I never knew that :-o |
| 14:28 | <Dashiva> | Hixie Hickson |
| 14:30 | <boblet> | lol |
| 14:30 | <boblet> | well, if someone whips one up in the next 2 days let me know :) |
| 14:31 | <Philip`> | You could always whip up one yourself :-) |
| 14:32 | <TabAtkins> | Go find one of the Microformat ones and mod it. |
| 14:32 | <Philip`> | Microdata should be simple enough that that wouldn't be much work |
| 14:32 | <boblet> | unfortunately I’m working on whipping up a preso on uF & microdata in HTML5 |
| 14:32 | <boblet> | in Japanese :| |
| 14:33 | <Philip`> | If it's for a presentation then you could just fake it |
| 14:33 | <Philip`> | Nobody would know |
| 14:33 | <boblet> | with a download tool they might ;-) |
| 14:34 | <Dashiva> | What do you call microformats in Japanese? |
| 14:34 | <annevk> | because without a model it's unclear e.g. whether an <identifier> is internally represented as <string> and can be serialized as such... |
| 14:34 | <boblet> | Dashiva: Maikurofo-matto (マイクロフォーマット) |
| 14:35 | <boblet> | but often just written as Microformat (that previous one was pronunciation & katakana) |
| 14:35 | <Philip`> | How many specs do have decent models, separating the semantics and syntax? |
| 14:36 | <boblet> | thanks for your help, all. nn |
| 14:37 | <TabAtkins> | annevk: What else would an identifier be serialized as? JS doesn't have a concept of 'symbol'. |
| 14:37 | Philip` | wonders how long it'll be until Japanese has adopted enough words that it'll effectively be English in an unusual accent |
| 14:37 | <TabAtkins> | So, hey, htmlwg wiki. The esw thing. Where is it? |
| 14:37 | <TabAtkins> | Philip`: Has? |
| 14:37 | <Philip`> | TabAtkins: http://www.w3.org/html/wg/wiki/Main_Page |
| 14:37 | <Dashiva> | It isn't esw anymore, luckily |
| 14:38 | <Philip`> | TabAtkins: (See http://www.w3.org/html/wg/, click on "Wiki") |
| 14:38 | <TabAtkins> | That would explain why i wasn't finding it. |
| 14:46 | <Philip`> | TabAtkins: Maybe the question is whether the strings "test" and "te\st" and "TEST" all have the same internal representation (because they are specified to be "exactly the same identifier") and thus the same serialisation (in which case which one?) |
| 14:46 | <TabAtkins> | Those are valid questions, and should indeed be specified precisely. |
| 14:46 | <annevk> | TabAtkins, strings are serialized with quotes |
| 14:47 | Philip` | guesses there's also questions like whether the string "\7B" should be serialized as "\7B" or as "{" |
| 14:47 | <annevk> | Philip`, for identifiers, yes |
| 14:47 | <TabAtkins> | annevk: ah, gotcha. I read you as saying something subtly different. |
| 14:47 | gsnedders | wonders if the fact that HTML 5 disallows all Unicode code characters causes issues by disallowing General_Category Cf |
| 14:47 | <Dashiva> | Reminds me of that horrible feature of JSON... |
| 14:47 | <annevk> | so e.g. [attr=ident] turns into [attr="ident"] in most browsers |
| 14:47 | <annevk> | but there's no Selectors model that defines that |
| 14:48 | <Philip`> | Dashiva: Which of the horrible features? |
| 14:48 | <Dashiva> | The one that lets you use both \/ and / |
| 14:48 | <gsnedders> | How will I live without U+1D177 MUSICAL SYMBOL BEGIN SLUR? |
| 14:48 | <gsnedders> | Or more seriously, what about something like U+0600 ARABIC NUMBER SIGN? |
| 14:49 | <Philip`> | Dashiva: Why is that any worse than the feature that you can use both "\u0078" and "x"? |
| 14:49 | <Dashiva> | Because some python libs only supported one of them |
| 14:49 | <Dashiva> | And I had to work around it |
| 14:50 | <annevk> | identifiers are especially complicated, because they cannot start with numbers either unless prefixed with -, etc. |
| 14:50 | <Philip`> | Is it JSON's fault that implementations are buggy? |
| 14:50 | <Dashiva> | Yes |
| 14:53 | <Philip`> | Is it not just the fault of implementors who can't read a trivial grammar spec? |
| 14:55 | jgraham | notes that in javascript, escaped identifiers are not equivalent to unescaped ones despite what the spec says |
| 14:55 | <jgraham> | (in particular you can use reserved words in identifiers by cunning/evil use of escapes even though that is forbidden) |
| 14:56 | <Philip`> | You can escape identifiers in JS? |
| 14:56 | Philip` | somehow failed to notice that |
| 15:01 | <gsnedders> | Philip`: Well of course, it's a brilliant feature |
| 15:02 | <TabAtkins> | What is an undercount? |
| 15:02 | <Philip`> | A count that is too small? |
| 15:02 | <TabAtkins> | Google is not helping me. |
| 15:02 | <TabAtkins> | Nah, it has something to do with polling, but everything I'm finding is talking about undercounts like I already understand what they are. |
| 15:03 | <Philip`> | "To record fewer than the actual number of (persons in a census, for example)." ? |
| 15:03 | <Philip`> | like if you lose/ignore half the votes, or something |
| 15:03 | <TabAtkins> | That makes sense. It makes what I'm reading sort of nonsensical, but shrug. That's to be expected given the author. |
| 15:05 | <meledin> | It could be a misrepresentation |
| 15:05 | <meledin> | e.g. say "video games have a 10% market share (when polling adult females aged 60 and up)" |
| 15:07 | <annevk> | TabAtkins, e.g. with counter-reset or so you want to know the model |
| 15:08 | <TabAtkins> | annevk: Indeed, it's very important to know whether an escaped counter identifier is the same as the unescaped. Complete agreement there. |
| 15:10 | Philip` | blames XML for being too successful and encouraging people to believe it's good to specify just syntax and not the interpretation of the syntax |
| 15:12 | <annevk> | TabAtkins, oh, that is pretty clear |
| 15:13 | <TabAtkins> | Oh, ok. Man, I don't even know then. ^_^ I don't have enough impl experience yet. |
| 15:13 | <annevk> | TabAtkins, though maybe not, is <string> "test" the same as <identifier> test, and what do they serialize as? |
| 15:13 | <annevk> | it's mostly what happens in serialization that I was worried about |
| 15:13 | <annevk> | e.g. is it all <string> internally or not |
| 15:14 | <TabAtkins> | I'd have to go read the spec, since it treats strings and identifiers inconsistently. >_< |
| 15:14 | <annevk> | it seems most impl just do whatever |
| 15:14 | <TabAtkins> | Javascript needs a symbol type. Like a string but you can just do pointer comparisons to check equality. |
| 15:14 | <annevk> | CSS just falls apart as spec when you look at API stuff |
| 15:14 | <Philip`> | Sounds like most specs |
| 15:14 | <annevk> | TabAtkins, hmm, impl could do that internally |
| 15:15 | <gsnedders> | TabAtkins: I wonder how much perf you'd gain from that though |
| 15:15 | <TabAtkins> | I think they *do*. At least, that the impression I get from some things I've heard dbaron saying. |
| 15:15 | gsnedders | thinks that will almost certainly be the wrong place to optimize |
| 15:15 | <annevk> | Philip`, yeah, HTML4/DOM2HTML had the same issue |
| 15:15 | <TabAtkins> | gsnedders: In a tight loop, string comparison is expensive. >_< |
| 15:16 | <Philip`> | You don't need a special symbol type, you just need interned strings |
| 15:16 | <jgraham> | Don't you hate it when you are about to say something and then Philip` speaks |
| 15:16 | <TabAtkins> | True, but it's nice to reflect that in a user-visible way. A symbol *is* an interned string. |
| 15:16 | <jgraham> | because he always says whatever you were about to say |
| 15:16 | <Philip`> | jgraham: I sure do |
| 15:16 | <Philip`> | (Hate it, I mean) |
| 15:17 | <TabAtkins> | At least, for the one language I have experience with that has a symbol type (lisp). (intern "foo") returns the symbol foo. |
| 15:17 | <gsnedders> | Ruby has a symbol type too |
| 15:19 | <Philip`> | C++ has boost::flyweight<std::wstring>, which seems to be the same idea |
| 15:19 | <Philip`> | Not the snappiest name, though |
| 15:27 | <annevk> | I thought I was before Philip`, though I guess I didn't mention interned strings explicitly |
| 15:30 | <jgraham> | Yeah but Philip` always does it :) |
| 15:31 | <annevk> | interesting definition of always then :p |
| 15:34 | Philip` | is clearly too predictable |
| 15:34 | <jgraham> | I reserve the right to be interesting |
| 15:42 | <TabAtkins> | Yay for people assembling all the information I needed for my counter proposal for me! |
| 15:43 | <Lachy> | TabAtkins, what counter proposal are you writing? |
| 15:43 | <TabAtkins> | For issues 1 and 2. Just posted it to the list. |
| 15:50 | <hsivonen> | Philip`: boost calls interned stuff "flyweight"? |
| 15:50 | <hsivonen> | as in weighing as much as an insect? |
| 15:50 | <annevk> | we could just use a PING method instead |
| 15:51 | <annevk> | custom methods are quite well supported nowadays |
| 15:52 | <Philip`> | hsivonen: http://en.wikipedia.org/wiki/Flyweight_pattern |
| 15:53 | <Philip`> | as in weighing between 49kg and 51kg :-) |
| 15:54 | <hsivonen> | Philip`: clearly, I haven't read enough Design Patterns literature to know the lingo |
| 15:59 | <TabAtkins> | annevk: Are they? |
| 15:59 | TabAtkins | has no idea if php supports new methods well. |
| 15:59 | <gsnedders> | TabAtkins: It treats all methods identically |
| 15:59 | <Philip`> | Do proxies support them? |
| 15:59 | <TabAtkins> | That wouldn't actually resolve the objection, though. The PING method would still be 'unsafe'. |
| 16:00 | <gsnedders> | TabAtkins: It just sets $_SERVER['HTTP_METHOD'] or some other key to the method of the request |
| 16:00 | <TabAtkins> | gsnedders: Thanks for the info! |
| 16:00 | <Philip`> | Hmm, I think Squid doesn't by default, which is why it breaks Subversion |
| 16:00 | <annevk> | TabAtkins, not necessarily |
| 16:00 | <annevk> | TabAtkins, new methods can be safe |
| 16:00 | <Lachy> | the only really relevant question reagarding ping is whether or not browsers will implement it, and if they do, then it should be specced. (Of course, browsers should choose whether or not to implement the feature on its own merits, none of which should affect whether or not it should be specced) |
| 16:01 | <TabAtkins> | annevk: I think they're using "unsafe" to mean "not idempotent", and @ping is inherently not idempotent. |
| 16:02 | <annevk> | TabAtkins, I don't think that's quite true |
| 16:02 | <TabAtkins> | Elaborate? |
| 16:03 | <annevk> | by not holding the user accountable it is acceptable afaict |
| 16:04 | <annevk> | though using GET would be just as fine in that case, though presumably does not work well with caching and all |
| 16:05 | <Philip`> | Can't you just set some request header to make sure it doesn't get cached? |
| 16:10 | <jgraham> | It seems like bad design to require special overrides to ensure the request is not cached when caching is never the right thing to do |
| 16:13 | <Philip`> | It seems like bad design to rely on certain side-effects of the request method, rather than on the explicit cache control headers, when the primary aim is to affect the request's cache behaviour |
| 16:16 | <hsivonen> | is there some echo service that I POST a form to and get it echoed to me? |
| 16:17 | <jgraham> | Philip`: Well with my approach ("right by default") people will typically get it right whereas with the "be explicit but fail wrong" approach people will typically get it wrong |
| 16:20 | <Philip`> | jgraham: "people" here are web browser developers and they can be expected to largely get it right |
| 16:21 | <Philip`> | and it's easy to test |
| 16:22 | <Philip`> | (If it was something authors would have to do, then I'd find it more compelling to make it harder to make mistakes) |
| 16:26 | <annevk> | hsivonen, hixie has that |
| 16:26 | <hsivonen> | annevk: where? |
| 16:26 | <annevk> | not sure, looking it up |
| 16:27 | <annevk> | his site is somewhat slow |
| 16:28 | <annevk> | hsivonen, http://software.hixie.ch/utilities/cgi/test-tools/echo |
| 16:28 | <hsivonen> | annevk: thanks |
| 16:30 | <annevk> | for whoever is in the CSS-<number>-values-need-to-support-a-significand camp it would make writing down how to serialize a <number> value easier |
| 16:30 | <TabAtkins> | There's a thread for that, annevk. |
| 16:31 | <annevk> | I deleted that thread |
| 16:32 | <TabAtkins> | Hehe. Why not just mute it? |
| 16:32 | TabAtkins | deletes NOTHING. |
| 16:32 | <hsivonen> | I can has bogo-keygen |
| 16:33 | <hsivonen> | one item less on my todolist |
| 16:33 | <annevk> | TabAtkins, cause I delete |
| 16:34 | <TabAtkins> | Fine. Could you explain your reasoning more fully? I'll send it to the list. |
| 16:34 | <annevk> | HTML5 uses ToString() for real numbers, from ECMA |
| 16:34 | <annevk> | it seems some browsers already use that too |
| 16:35 | <annevk> | using that for serializing CSS <number> values too would unify things a little more |
| 16:35 | <TabAtkins> | kk |
| 16:35 | <TabAtkins> | So we'd be harmonizing with HTML5 as well as SVG. |
| 16:37 | <Philip`> | HTML5 seems to bounce between different serialisation/parsing definitions quite frequently |
| 16:37 | <Philip`> | Strangely it seems to happen whenever I complain about the previous definition |
| 16:37 | <Philip`> | (even if that's a definition I suggested) |
| 16:43 | <Philip`> | "Ping would never be capable of proving undercounts" - s/proving/preventing/ ? |
| 16:43 | <Philip`> | The sentence seems to make more sense with that change |
| 16:45 | <smaug> | Hixie: why does the websocket protocol have the optional binary-frames? |
| 16:46 | <smaug> | or why are they optional? |
| 16:47 | <annevk> | they're not optional |
| 16:48 | <TabAtkins> | Philip`: I think it's meant to be "providing"? |
| 16:49 | <Philip`> | I don't think that would make sense |
| 16:49 | <jgraham> | Do you mean "lower bounds"? |
| 16:49 | <Philip`> | I think the meaning was that ping would never provide a perfectly accurate count that never misses any clicks |
| 16:50 | <Philip`> | (because it's be easy for the ping server to be down, etc) |
| 16:50 | <Philip`> | I'm not at all confident in my thinking, though |
| 16:51 | <TabAtkins> | I suppose that makes sense too. Honestly, that objection is incoherent anyway, because there is no perfectly accurate auditing method. |
| 16:52 | <Philip`> | Even with no perfect method, if current methods had 99% accuracy and a new method had 50% accuracy then nobody would use the new method |
| 16:53 | <Philip`> | so I don't think the impossibility of perfection means there's no need to debate accuracy |
| 16:54 | <jgraham> | They might if the loss in accuracy had some positive side effect |
| 16:54 | <jgraham> | (so there is equally no use ssaying that accuracy alone is the only significant variable) |
| 16:55 | <Philip`> | Well, no |
| 16:55 | <Philip`> | Maybe the new method has 50% accuracy but it kills a puppy every time someone clicks on the link, and you hate puppies |
| 16:55 | <Philip`> | so I'd agree it's not the only factor |
| 16:55 | <Philip`> | but it is a valid factor to discuss |
| 16:56 | <Philip`> | (but preferably it should be discussed with data and specific cases, rather than handwavey claims that it won't be accurate enough) |
| 17:00 | <TabAtkins> | Philip`: True. However, I'd be willing to argue that @ping will be no less accurate than existing similar methods. |
| 17:04 | <annevk> | oh sweet, the grammar uses octal references |
| 17:04 | <annevk> | gotta love that |
| 17:05 | <TabAtkins> | omg |
| 17:05 | <TabAtkins> | wtf are we using octal. wtf is *anyone* using octal? |
| 17:05 | <annevk> | I seriously dislike the CSS grammar |
| 17:06 | <TabAtkins> | What feature, in the history of computers, has ever gained more benefit from using octal than it suffered from confusion caused by it? |
| 17:06 | <annevk> | fortunately CSS itself uses unicode escapes |
| 17:07 | <Philip`> | TabAtkins: Unix file permissions? |
| 17:07 | <TabAtkins> | Are those octal? I always figured they were just chars. |
| 17:08 | <Philip`> | "0755" etc |
| 17:08 | <TabAtkins> | Yeah, I just never really thought of that as a number. |
| 17:08 | <TabAtkins> | More like 0,7,7,5. |
| 17:08 | <TabAtkins> | Four separate flags. |
| 17:10 | <Philip`> | You need three bits for each number (rwx), so octal makes sense |
| 17:10 | <Philip`> | It'd be awfully wasteful to devote 8 bits when you only need 3 |
| 17:11 | <TabAtkins> | Shrug. |
| 17:11 | <Philip`> | and it'd be a pain for a program to process character strings |
| 17:11 | <Philip`> | compared to just &ing with a mask to extract the desired permission bits |
| 17:12 | <TabAtkins> | I have no idea how the permission bits are actually exposed. |
| 17:13 | <Philip`> | With C code like mkdir("foo", 0755); |
| 17:14 | <annodomini> | Interesting comment re the W3C HTML standards process: http://news.ycombinator.com/item?id=1126640 |
| 17:15 | <TabAtkins> | I suppose C treats numbers starting with 0 as octal there? |
| 17:15 | <TabAtkins> | annodomini: Urm, wow. |
| 17:16 | <annodomini> | Yeah, the resemblance is scary, isn't it? |
| 17:16 | <Philip`> | TabAtkins: Yes |
| 17:16 | <Philip`> | It treats numbers starting with 0 as octal everywhere, in fact :-p |
| 17:17 | <TabAtkins> | Well, yeah. Bad use of "there" there. ^_^ |
| 17:17 | <Philip`> | annodomini: Already incorporated into http://ian.hixie.ch/bible/handling-people :-) |
| 17:18 | <hsivonen> | annodomini: the awesome part is that people imply Hixie practices that because Hixie has a copy of that text on his site |
| 17:18 | <hsivonen> | annodomini: see http://ian.hixie.ch/bible/handling-people |
| 17:19 | <annodomini> | Philip`: Ah, I hadn't seen that. |
| 17:19 | <annodomini> | hsivonen: Heh. |
| 17:20 | <hsivonen> | annodomini: it's an interesting exercise to try to see who appears to be practicing those points in which W3C WGs |
| 17:21 | <Philip`> | You should watch out for people sneaking about the W3C server room and dropping iron filings into the machines, too |
| 17:21 | <Philip`> | (That sabotage manual has lots of great ideas) |
| 17:22 | <annodomini> | It's definitely a good rebuttal to the people who claim that they are not trying to sabotage HTML5 (or fill in any other standard) but instead are just trying to improve the process. |
| 17:28 | <hsivonen> | http://news.ycombinator.com/item?id=1126555 |
| 18:01 | <workmad3> | hah :) I was reading the handling people thing and was thinking "I'm sure something like this was in Yes Minister"... and then saw the reference at the bottom :) |
| 19:22 | <Hixie> | MikeSmithXX: yt? |
| 19:34 | <smaug> | Hixie:now that you're here, why does the websocket protocol have the optional binary-frames? |
| 19:34 | <smaug> | or what to call them, semi-optional |
| 19:35 | <Hixie> | so that we can add support for binary in the future |
| 19:35 | <Hixie> | they're not optional, they're invalid at the moment |
| 19:35 | <Hixie> | the support is just error handling |
| 19:35 | <Hixie> | and you can handle them by either ignoring them or failing the connection |
| 19:36 | <Hixie> | (only ignoring them if you're a browser client) |
| 19:36 | <smaug> | well, might be better to define that they are really invalid now |
| 19:37 | <Hixie> | i thought it did |
| 19:37 | <Hixie> | where does it say they are alid? |
| 19:37 | <Hixie> | valid |
| 19:37 | <Hixie> | neither the server nor the client is allowed to send them |
| 19:37 | <Hixie> | they're only allowed to send 0x00 frames currently |
| 19:38 | <smaug> | well, the server side part says that "If /type/ is not a 0x00 byte, then the server may disconnect from |
| 19:38 | <smaug> | the client." |
| 19:38 | <Hixie> | right |
| 19:38 | <smaug> | it is just "may" |
| 19:38 | <Hixie> | indeed |
| 19:38 | <Hixie> | that's the right thing to do as far as i can tell |
| 19:39 | <Hixie> | the server knows the subprotocol that the conneciton is using |
| 19:39 | <Hixie> | so it can know that if it sees a binary frame it can disconnect since it's not valid |
| 19:39 | <Hixie> | and it can equally know that it might want to use binary frames in the future and will therefore know that it can try to be future-compatible and not disconnect, but just ignore the packet |
| 19:40 | <Hixie> | s/packet/frame/ |
| 19:40 | <smaug> | server may not really know the subprotocol. I'd assume the subprotocol was implemented by some cgi-like script |
| 19:41 | <Hixie> | that's still the server |
| 19:42 | <smaug> | and anyway, the client can't handle binary data at all |
| 19:42 | <Hixie> | today, right |
| 19:42 | <Hixie> | but in the future we'll add binary frames |
| 19:42 | <smaug> | yeah |
| 19:42 | <smaug> | so why define some sort of server side support for binary, but not client side |
| 19:43 | <Hixie> | the clients ignore binary frames just like the server does |
| 19:43 | <smaug> | not the same way |
| 19:43 | <smaug> | client does always "Discard the read bytes." |
| 19:43 | <Hixie> | well the clients aren't allowed to disconnect, sure |
| 19:43 | <smaug> | server just may close the connection |
| 19:43 | <Hixie> | right |
| 19:44 | <Hixie> | the server knows the protocol, the client doesn't (it's running JS that does the protocol) |
| 19:44 | <Hixie> | so the server can know if it's expecting binary frames or not |
| 19:44 | <Hixie> | the clients on the other hand have to all interoperate exactly |
| 19:44 | <zcorpan__> | Hixie: doesn't object send a PARAM:null parameter to plugins (commented out in the spec)? |
| 19:44 | <Hixie> | zcorpan__: only firefox seems to do that |
| 19:44 | <zcorpan__> | Hixie: hmm i thought opera also does |
| 19:45 | <Hixie> | nope |
| 19:45 | <smaug> | currently websockets api is text based |
| 19:45 | <Hixie> | smaug: yes |
| 19:45 | <Hixie> | no binary support in JS :-( |
| 19:45 | <smaug> | could the protocol say something that if the API to handle protocol supports binary, then the data shouldn't be discarded |
| 19:46 | <Hixie> | once the API handles binary, I'll update the protocol. |
| 19:46 | <Hixie> | (they're the same source document, I edit them as one spec) |
| 19:46 | <Hixie> | (they're both part of http://www.whatwg.org/specs/web-apps/current-work/complete.html) |
| 19:46 | <smaug> | why can't you write the protocol so that it supports that already? |
| 19:46 | <Hixie> | no point, the API doesn't do it |
| 19:47 | <Hixie> | what would you do with the data? |
| 19:47 | <Hixie> | the client can neither send nor receive binary |
| 19:47 | <zcorpan__> | you could implement a server now that will work in the future when clients support binary |
| 19:47 | <smaug> | currently it can receive binary |
| 19:47 | <smaug> | it just discards the data immediately |
| 19:48 | <Hixie> | right |
| 19:48 | <smaug> | in the future the protocol will need backwards incompatible change |
| 19:48 | <Hixie> | zcorpan__: that'd be unwise, since we don't know exactly what the conventions will be |
| 19:49 | <smaug> | client may not discard the data anymore |
| 19:49 | <Hixie> | how is that not backwards compatible? |
| 19:50 | <smaug> | for some reason server could send some random data to client to keep the connection open or something.... |
| 19:50 | <smaug> | and rely on that client doesn't handle that |
| 19:50 | <smaug> | but suddenly client starts to handle the data |
| 19:50 | <Hixie> | that would work fine, since the JS would also ignore the binary frames |
| 19:51 | <smaug> | I assume JS can handle binary frames in the future |
| 19:51 | <Hixie> | yes, but the script the author wrote isn't going to suddenly support it without the server being fixed to not send those frames |
| 19:53 | <smaug> | right |
| 19:53 | <smaug> | so why not say now that client may use the binary frames |
| 19:53 | <Hixie> | JS doesn't support binary |
| 19:54 | <Hixie> | so what are we supposed to do with the binary frames? |
| 19:54 | <smaug> | I assume there can be other than WebSockets API which use the protocol |
| 19:54 | <Hixie> | oh, no, that would be silly |
| 19:54 | <Hixie> | if you're not a browser just use TCP |
| 19:54 | <smaug> | huh |
| 19:55 | <Hixie> | the only things WebSockets gives you are an origin-based security model (only helpful for browsers) and basic framing |
| 19:55 | <Hixie> | basic framing is so trivial to do that you can do it in your own protocol, you don't need websockets |
| 19:55 | <smaug> | if you have some service which already uses websockets, why not use the same protocol everywhere? |
| 19:55 | <Hixie> | well i guess you could, but then you have to worry about JS clients again |
| 19:56 | <Hixie> | my point is you'd only ever use websockets if at least one of your clients is going to be a browser |
| 19:56 | <Hixie> | and if that's the case, then you can't use binary frames |
| 19:56 | <Hixie> | until we add binary to the protocol |
| 19:56 | <Hixie> | er, to JS I mean |
| 19:57 | <smaug> | right |
| 19:58 | <smaug> | but since the binary frames are defined already, server-to-server (or server-to-C++) communication could start use binary-frames already |
| 19:58 | <Hixie> | personally i'd strongly recommend that if your client isn't a browser, you just use a custom protocol |
| 19:58 | <smaug> | and once the JS API is ready, it can just start use the same (binary) subprotocol |
| 19:58 | <Hixie> | it might look very similar to websockets, but it needn't be websockets itself |
| 19:58 | <Hixie> | for example the whole handshake is a waste of time if you're not a browser |
| 19:59 | <Hixie> | and if you're not using websockets, you can write your own spec that uses whatever frames you want |
| 19:59 | <smaug> | yet you mention in the draft that not all communication is server-to-browser |
| 19:59 | <Hixie> | yeah, people keep telling me to make the spec more generic |
| 19:59 | <Hixie> | i think it's a mistake |
| 20:01 | <smaug> | I still don't see why the draft couldn't say that if the API supports binary, then client may not discard the data |
| 20:01 | <smaug> | not a big change |
| 20:02 | <smaug> | but would allow server-to-C++ etc |
| 20:02 | <Hixie> | same reason it doesn't say you can use frame 0x01 |
| 20:02 | <Hixie> | we don't know what the conventions will be yet |
| 20:02 | <Hixie> | maybe binary frames will be [mimetype][data] |
| 20:02 | <Hixie> | or maybe they'll be [data][checksum][data][checksum] etc |
| 20:03 | <Hixie> | and there's no need for it -- if you want to speak a custom protocol to a server, you don't need this spec |
| 20:03 | <Hixie> | just write your own |
| 20:04 | <TabAtkins> | What. The. Hell. Something is going *terribly* wrong here. Either the server or the browser is cutting off my post request after a minute or two and just navigating to the form's @action instead. |
| 20:06 | <Hixie> | tcpdump |
| 20:06 | <Hixie> | find out what's actually going on :-) |
| 20:09 | <smaug> | the protocol does say what part of the frame is binary |
| 20:09 | <smaug> | so why the client couldn't use that? |
| 20:09 | <Hixie> | no, it says how to skip length-prefixed frames |
| 20:09 | <Hixie> | it doesn't say what 0x80-0xFF frames actually mean |
| 20:09 | <Hixie> | in fact, case in point, we're thinking of defining 0xFE and 0xFF to be a disconnect handshake |
| 20:11 | <smaug> | would server send those? |
| 20:11 | <Hixie> | we don't know yet |
| 20:11 | <smaug> | ...since currently client must just discard the binary data |
| 20:12 | <Hixie> | if we make 0xFF do something, then we'd change the client and server rules accordingly |
| 20:12 | <Hixie> | that's my point |
| 20:12 | <Hixie> | as we make frames do new things, we'll update the spec |
| 20:12 | <Hixie> | you know, the spec also says to discard 0x01 frames |
| 20:12 | <Hixie> | which aren't binary |
| 20:12 | <Hixie> | it's not just binary frames it discards |
| 20:13 | <Hixie> | it discards 99.6% of possible frame types |
| 20:13 | <Hixie> | only 0x00 frames get processed currently without discarding |
| 20:15 | <smaug> | rigth |
| 20:15 | <smaug> | I just wish the wording would be something else than "discard data" |
| 20:15 | <Hixie> | "this frame is invalid, discard the data"? |
| 20:16 | <Hixie> | "if you ever see this, you're either speaking to a buggy peer or a peer from the future" |
| 20:16 | <smaug> | since the idea is anyway that in the future the data may be used for something |
| 20:16 | <Hixie> | in the future we'll update the spec |
| 20:16 | <TabAtkins> | Hmm. I have no idea how to tell tcpdump how to only report on traffic from the webserver. |
| 20:17 | <Hixie> | are you running it on the client or the server? |
| 20:17 | <TabAtkins> | server. |
| 20:18 | <smaug> | so a server based on Feb 15 2010 draft can rely on that everything else than 0x00 frames are discarded, because the spec says so |
| 20:18 | TabAtkins | basically doesn't know what he's doing. |
| 20:18 | <Hixie> | tcpdump ... 'src post 80' |
| 20:18 | <Hixie> | er |
| 20:18 | <Hixie> | src port 80 |
| 20:18 | <Hixie> | smaug: a server based on feb 15 2010 draft can't send anything but 0x00 frames, because the spec says so |
| 20:19 | <Hixie> | TabAtkins: actually |
| 20:19 | <smaug> | ah, that is ture |
| 20:19 | <smaug> | true |
| 20:20 | <smaug> | yet, the spec should say something (even in normative section) about reserving frame types for future use |
| 20:21 | <Hixie> | TabAtkins: you want '((src host web.server.address) && (src port 80)) || ((dst host web.server.address) && (dst port 80))' or something |
| 20:23 | <Hixie> | smaug: Something like: |
| 20:23 | <Hixie> | The protocol is designed to support other frame types in future. |
| 20:23 | <Hixie> | Instead of the 0x00 byte, other bytes might in future be defined. |
| 20:23 | <Hixie> | ...? |
| 20:23 | <Hixie> | (from 10.3.4.1.2 Protocol overview) |
| 20:23 | <smaug> | that is non-normative |
| 20:24 | <smaug> | er, which chapter |
| 20:24 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#protocol-overview |
| 20:24 | smaug | reads the one in ietf, since the API draft points to there |
| 20:24 | <Hixie> | wait, what normative conformance criteria do you want? |
| 20:25 | <Hixie> | the API draft is also in complete.html |
| 20:25 | <Hixie> | (http://www.whatwg.org/specs/web-apps/current-work/complete.html#network) |
| 20:26 | <smaug> | Something that in the future servers and clients may need to support other than 0x00 frames |
| 20:26 | <smaug> | not sure about the wording |
| 20:27 | <Hixie> | I don't understand what the requirement would be |
| 20:27 | <smaug> | currently the requirement is that server always sends 0x00 frames |
| 20:27 | <smaug> | *always* only 0x00 frames |
| 20:28 | <smaug> | in the future we want to support something else too |
| 20:28 | <Hixie> | sure. in the future we'll update teh spec. |
| 20:28 | smaug | doesn't like non-stable specs |
| 20:29 | <smaug> | which are always just drafts |
| 20:31 | <zcorpan__> | why not? |
| 20:31 | <smaug> | in general? because of backwards compatibility problems |
| 20:39 | <Hixie> | smaug: improving a spec over time doesn't mean it's not stable |
| 20:40 | <smaug> | right. I think, so far I haven't see a stable spec which has been just "improved" |
| 20:41 | <smaug> | I admin, W3C has tried to do that with erratas |
| 20:41 | <smaug> | admit |
| 20:41 | <Hixie> | so HTML has been unstable? |
| 20:42 | <smaug> | you mean html5 |
| 20:42 | <smaug> | yes, unstable |
| 20:42 | <smaug> | just an example: hashchange |
| 20:42 | <Hixie> | i mean HTML 1-4 |
| 20:43 | <smaug> | they are new versions |
| 20:43 | <smaug> | new specs |
| 20:44 | <Hixie> | that's what i mean we'll do with websockets |
| 20:44 | <smaug> | ah |
| 20:44 | <smaug> | I thought something like with html5 |
| 20:44 | <smaug> | never-ever stable |
| 20:44 | <Hixie> | i don't see the difference |
| 20:45 | <TabAtkins> | I too am curious as to the difference between minting a new version identifier for changes, and just changing the existing spec. |
| 20:45 | <Hixie> | whatwg html is on "version 4745" |
| 20:45 | <Hixie> | if you go by subversion revisions |
| 20:46 | <TabAtkins> | HTML 5.4745 |
| 20:46 | <smaug> | so browser x may support version 4733 and some other browser version 4655 and they have conflicting behavior, yet both say that they support HTML5 |
| 20:47 | <smaug> | not the perfect situation |
| 20:47 | <TabAtkins> | Welcome to the web? |
| 20:47 | <TabAtkins> | At least they can't claim to support the same edition of the spec and still be conflicting (if we've done things right). |
| 20:48 | <Hixie> | smaug: um, that's no worse than what happened with html 1-4 |
| 20:48 | <TabAtkins> | This TCPdump output just tells me that there is regular communication for almost exactly 4 minutes between browser and server, and then it suddenly cuts out (at which point the browser navigates to the form's action). I can't decipher anything special happening near the end that could cause problems. |
| 20:49 | <smaug> | there browser x was saying it support v4, and y supports v3 |
| 20:49 | <smaug> | there is clear possibility for API breakage |
| 20:49 | <TabAtkins> | No, Browser X would claim to support v4, Browser Y would claim to support v4, and yet they would have conflicting behavior. |
| 20:50 | <smaug> | that is different thing |
| 20:50 | <Hixie> | it's the same thing |
| 20:50 | <Hixie> | in practice browsers don't claim to implement a particular version |
| 20:51 | <Hixie> | not in any meaningful way |
| 20:51 | <smaug> | they do in the API documentation |
| 20:52 | <smaug> | or whatever the documentation for web devs is called |
| 20:52 | <Hixie> | not in a meaningful way |
| 20:52 | <othermaciej> | hi everyone |
| 20:52 | <smaug> | pretty often the comment is that this and that HTML5 feature is supported ... |
| 20:52 | <Hixie> | there's going to be more delta between browser x and html5 version 4733 in your example than between html5 version 4733 and html5 version 4655 |
| 20:53 | <Hixie> | smaug: sure, and often people say this and that DOM2 HTML or CSS2 or HTML4 feature is supported, and it's just as different between browsers |
| 20:53 | <Hixie> | at least with a regularly updated spec, the browsers have a chance of converging on something |
| 20:53 | <Hixie> | hey maciej |
| 20:53 | <smaug> | not necessarily if the web dev is interested only in one particular feature |
| 20:54 | <smaug> | anyway, this is pretty useless discussion :) |
| 20:56 | <othermaciej> | well, I'm supposed to be on vacation today but I just got a call to explain to my management what's going on with HTML5 |
| 20:59 | Hixie | checks his e-mail to make sure he's not also being dragged into work |
| 21:00 | <smaug> | Hixie: oh, one thing still |
| 21:00 | <smaug> | the back/forward discussion didn't continue for some reason |
| 21:00 | <smaug> | the draft was just changed to what chromium wants it to be |
| 21:01 | <smaug> | and that's it |
| 21:03 | <Hixie> | and what mozilla wanted |
| 21:03 | <Hixie> | but i think i have more e-mails in that folder |
| 21:03 | <smaug> | ? |
| 21:03 | <Hixie> | it's not finished yet |
| 21:04 | <Hixie> | (739 e-mails remaining) |
| 21:04 | <Hixie> | (so it takes a while to go through them) |
| 21:05 | <smaug> | I know it is kind of hard to say what Mozilla wants when Mozilla is a group of people which may have quite different opinions |
| 21:10 | <Hixie> | true |
| 21:11 | <Hixie> | sicking said that he thought making it async would help mozilla, though, and sicking is pretty representative :-) |
| 21:11 | <smaug> | but sicking is not the one who has been hacking session history lately ;) |
| 21:13 | <smaug> | I'd just like to understand the reasoning behind making API async. So far the reasoning has been mainly just that in chromium's architecture sync might be a bit harder to implement |
| 21:13 | <Hixie> | not just chrome's architecture, pretty much any multi-process model |
| 21:13 | <smaug> | no |
| 21:14 | <Hixie> | Justin's e-mail is the only one i seem to have in the history pile |
| 21:14 | <Hixie> | but that's about pushState |
| 21:14 | <Hixie> | did i miss one? |
| 21:14 | <smaug> | as far as I see session history could live in a process between ui and the tab process |
| 21:15 | <smaug> | Hixie: oops, seems like I've missed |
| 21:15 | <Hixie> | yeah but any IPC basically has to be async |
| 21:15 | <smaug> | sorry |
| 21:15 | <smaug> | IPC doesn't have to be async |
| 21:16 | <Hixie> | if you try doing sync IPC with the kind of model a browser implies, you're very likely to end up with either deadlocks or EXTREMELY complicated code |
| 21:17 | <roc> | you just force the event loops into a directed acyclic graph and then require all calls in one direction to be async |
| 21:18 | <smaug> | IPC from client process to parent doesn't have to be async |
| 21:18 | <smaug> | and especially if there was a separate process for a "tab", that could handle session history |
| 21:18 | <Hixie> | history traversal requires two-way communication |
| 21:19 | <smaug> | if there was some problem with it, the main process could kill it |
| 21:19 | <Hixie> | if you can come up with a model that has each iframe in a different process, and can do sync history traversal, I'm certainly eager to hear how it would work. |
| 21:19 | <Hixie> | please do e-mail such proposals to the list |
| 21:20 | <Hixie> | currently, i'm not aware of any plausible way to do it that isn't insanely complicated compared to just making history traversal async |
| 21:20 | <Hixie> | and since history traversal has to be mostly async anyway when you're doing cross-page traversal, it seems simple enough to do it async |
| 21:20 | <Hixie> | (generally we want everything async anyway) |
| 21:21 | <Hixie> | (so that e.g. script doesn't block on disk I/O) |
| 21:21 | <smaug> | I'll think about the sync sh |
| 21:22 | <Hixie> | frankly the best argument for keeping the same-page session history sync would be evidence that it's needed for back compat |
| 21:23 | <Hixie> | lacking that, making it trigger based on queueing a task seems like a big win all round |
| 21:23 | <Hixie> | (i wish we could make location.href async too, but that one clearly does have back compat requirmenets) |
| 21:32 | <zcorpan__> | should there be a dimensionchange event for <video>? |
| 21:33 | <Hixie> | probably in some future version, yeah |
| 21:34 | <zcorpan__> | whatwg.org is down |
| 21:34 | <Hixie> | weird |
| 21:36 | <Hixie> | hm, googlebot is using a lot of slots |
| 21:36 | <Hixie> | let me reduce the indexing frequency |
| 21:40 | <Hixie> | zcorpan__: fixed |
| 21:41 | <Hixie> | zcorpan__: i had a couple of CGI scripts that never finished, and as googlebot indexed them it was taking progressively more and more slots |
| 21:41 | <Hixie> | they now terminate after 60s |
| 22:20 | <zcorpan__> | Hixie: nice |
| 22:20 | <Hixie> | also dramatically reduced the indexing frequency :-) |
| 22:21 | <Hixie> | not much point indexing tests every 5 seconds |
| 22:21 | <zcorpan__> | Hixie: apparently opera does send PARAM:"", but only since last week :) |
| 22:21 | <Hixie> | i wish i had a way to test IE |
| 22:22 | <Philip`> | Isn't there some existing plugin you could use and modify for testing? |
| 22:22 | <Philip`> | (assuming that's what the problem was) |
| 22:23 | <Hixie> | well on mac i just wrote my own plugin to dump the data out |
| 22:23 | <zcorpan__> | do you have that plugin around somewhere? |
| 22:23 | <Hixie> | sure |
| 22:23 | <Hixie> | source or binary? |
| 22:24 | <zcorpan__> | can i has both? :) |
| 22:24 | <Hixie> | sure |
| 22:24 | <zcorpan__> | awesome |
| 22:34 | <Hixie> | http://junkyard.damowmow.com/408 |
| 22:35 | <Hixie> | zcorpan__: ^ |
| 22:35 | <zcorpan__> | Hixie: thanks! |
| 22:36 | <Hixie> | let me know if you find anything in there that i shouldn't have put in public :-) |
| 22:36 | <Hixie> | i didn't look closley |
| 22:36 | <Hixie> | closely |
| 22:37 | <zcorpan__> | still loading... |
| 22:37 | <Hixie> | also, that code is a mess. It has memory leaks and the like. I didn't do anything to fix it because all I wanted was the data, and once I had it I was done and threw it out |
| 22:37 | <zcorpan__> | connection timed out |
| 22:37 | <Hixie> | (i wouldn't be surprised if it had security bugs and stuff) |
| 22:37 | <Hixie> | (so don't install it on a production machine) |
| 22:38 | <Hixie> | wfm |
| 22:41 | <zcorpan__> | i can't reach it from here for some reason. i'll try at the office tomorrow |
| 22:41 | <Hixie> | can you get to hixie.ch? |
| 22:41 | <zcorpan__> | no |
| 22:41 | <jgraham> | zcorpan__: wfm |
| 22:41 | <TabAtkins> | I can reach it, fwiw. |
| 22:42 | <Hixie> | zcorpan__: odd |
| 22:42 | <Hixie> | zcorpan__: can you ping hixie.ch? |
| 22:42 | <zcorpan__> | ping times out too |
| 22:43 | <zcorpan__> | maybe park hotel has blocked hixie.ch |
| 22:43 | <Hixie> | can you ping 69.163.222.251 ? |
| 22:43 | <jgraham> | Too many Opera employees trying to reach it :) |
| 22:45 | <zcorpan__> | Hixie: times out |
| 22:45 | <Hixie> | weird |
| 22:45 | <zcorpan__> | dns lookup for hixie.ch is successful |
| 22:45 | <Hixie> | if you traceroute it, where does the route fail? |
| 22:48 | <zcorpan__> | 3 sar-l1.se.thecloud.net (10.5.24.134) 97.385 ms 28.379 ms 26.584 ms |
| 22:49 | <zcorpan__> | all others say * * * * |
| 22:49 | <zcorpan__> | er |
| 22:49 | <zcorpan__> | * * * |
| 22:49 | <Hixie> | then the problem is definitely at your ewnd |
| 22:49 | <Hixie> | end |
| 22:49 | <Hixie> | because i doubt very much dreamhost peer with thecloud.net :-) |
| 22:49 | <zcorpan__> | yeah |
| 22:50 | <jcranmer> | dump a bgp route advertisement and check the ASN path? |
| 22:50 | <zcorpan__> | time to sleep |
| 22:50 | <zcorpan__> | dump eyelocks |
| 22:50 | Hixie | would have no idea how to dump route advertisements or check ASN paths :-) |
| 22:53 | <boblet> | Microdata q: wondering why this doesn’t work in microdatajs; <li itemprop="location" itemscope itemtype="http://microformats.org/profile/hcard">; |
| 22:54 | <boblet> | but this does <li itemprop="location"><span itemscope itemtype="http://microformats.org/profile/hcard">; |
| 22:54 | <Hixie> | when you say "Work", what are you looking for? |
| 22:55 | <boblet> | Hixie: atm “work” = card data in http://foolip.org/microdatajs/live/ |
| 22:56 | <Hixie> | what's the complete document? |
| 22:56 | <boblet> | so I realise it might be a problem there. just sanity-checking I’m not making a mistake |
| 22:56 | <Hixie> | I'm not 100% sure I understand what you're trying to do |
| 22:56 | <Hixie> | (in particular, I'm curious what the itemprop="location" is intended to be part of) |
| 22:57 | <boblet> | Hixie: converting uF to Microdata. this is an hcard embedded in hcalendar |
| 22:57 | <Hixie> | in microdata, <li itemprop="location"><span itemscope itemtype="http://microformats.org/profile/hcard">; means the same as <li itemprop="location"></li> ... <span itemscope itemtype="http://microformats.org/profile/hcard">; |
| 22:57 | <Hixie> | that is, there's no link between the itemprop=location and the vcard in that case |
| 22:58 | <Hixie> | if you have an hCalendar and it contains a vCard, then I don't think foolip's tool will show you the nested vCard |
| 22:58 | <Hixie> | (the spec only says to extract the top-level vCards) |
| 22:58 | <Hixie> | (e.g. it won't exact Agents either) |
| 22:59 | <Hixie> | technically the vEvent vocabulary doesn't allow nested vCards currently iirc |
| 22:59 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#md-vevent-location says "The value must be text." |
| 23:00 | <Hixie> | (as opposed to "The value must be either an item with the type http://microformats.org/profile/hcard, or an absolute URL, or text." which is what the spec for vCard "agent" says) |
| 23:00 | <Hixie> | hth |
| 23:02 | <boblet> | Hixie: sorry, uploaded code http://oli-studio.com/temp/uf/microdata.html |
| 23:02 | <boblet> | and that “value must be text” part is a bit limiting if it means no contained elements |
| 23:03 | <Hixie> | the "value" there is the value of the itemprop="" property |
| 23:03 | <Hixie> | which can generally be either text, or a URL, or a datetime, or a nested itemscope="" item, |
| 23:03 | <Hixie> | s/,$// |
| 23:04 | <Hixie> | it doesn't preclude nested markup, but nested markup doesn't affect microdata |
| 23:05 | <boblet> | by that do you mean any text in nested markup isn’t included, eg as the location value in this case? |
| 23:05 | <Hixie> | it's flattened |
| 23:06 | <boblet> | or that the markup is ignored but the contained text is used? |
| 23:06 | <Hixie> | in: |
| 23:06 | <Hixie> | <div itemscope><span itemprop="a">hello <em>world</em> how <em>are</em> you</span></div> |
| 23:06 | <Hixie> | ...there is a singel item, and it has a single property named "a", and its value os "hello world how are you" with no markup. |
| 23:06 | <boblet> | ok, that’s what I hoped |
| 23:07 | <Hixie> | in: |
| 23:08 | <boblet> | so when you say “technically the vEvent vocabulary doesn't allow nested vCards currently” is that in Microdata or uF? |
| 23:08 | <Hixie> | <div itemscope><span itemprop="a"><em itemscope><span itemprop="b">B</span></em></span></div> |
| 23:08 | <Hixie> | ...tehre are two _top-level_ microdata items |
| 23:09 | <Hixie> | one has a property "a" with the value "B" |
| 23:09 | <Hixie> | the other has the property "b" with the value "B" |
| 23:09 | <boblet> | (I kinda thought that each itemtype instance wouldn’t affect the others) |
| 23:09 | <Hixie> | they are not related items -- there's no link between them in the microdata model |
| 23:09 | <Hixie> | however, in: |
| 23:09 | <Hixie> | <div itemscope><span itemprop="a" itemscope><span itemprop="b">B</span></span></div> |
| 23:10 | <Hixie> | there is _one_ top-level microdata item, and it has a property "a" whose value is a nested item, which itself has one property "b" whose value is "B". |
| 23:10 | <boblet> | aaah |
| 23:10 | <boblet> | a bit more rigor than uF classes |
| 23:10 | <Hixie> | yeah, that was one of the main goals of microdata |
| 23:11 | <Hixie> | the above and itemref="" are basically the two complicated parts of microdata |
| 23:11 | <Hixie> | (i recommend ignoring itemref="" for now) |
| 23:11 | <boblet> | am ignoring itemref="" for now :) |
| 23:11 | <boblet> | snap |
| 23:12 | <boblet> | have yet to make the slides, but will post here when I’m done for feedback (hopefully before the event :| ) |
| 23:12 | <boblet> | thanks for explaining |
| 23:22 | TabAtkins | is playing with a rough first-cut javascript library implementing @onlyreplace. |
| 23:22 | <Hixie> | boblet: my pleasure. I'd be happy to review any slides. |
| 23:23 | <Hixie> | TabAtkins: for <form>? |
| 23:23 | <TabAtkins> | <form>, <a>, and <base>. |
| 23:23 | <boblet> | Hixie: thank you. much appreciated |
| 23:23 | <Hixie> | TabAtkins: we had something like that in a previous version, if it's what I think you mean |
| 23:24 | <TabAtkins> | There was a thread about it a while back that ended up as "well, it should be easy to implement in JS, especially once XHR2 is out, so no change to the spec". |
| 23:24 | <boblet> | damn you foolip, swanning off to China to get married when I want to ask you questions! sheesh |
| 23:30 | <TabAtkins> | Is this an error or expected? I'm trying to replace an element with another element I've cloned from an <iframe>. It works fine for normal elements, but fails for <style>. |
| 23:30 | <TabAtkins> | (I can, however, wrap the <style> in a <div> and replace *that* instead.) |
| 23:31 | <TabAtkins> | Specifically, this is in Chrome 4 for windows. |
| 23:32 | <Hixie> | "error" and "expected" are not mutually exclusive |
| 23:32 | <Hixie> | do you have a minimised test case? |
| 23:32 | <TabAtkins> | No, but I could produce one. (Right now it's me testing it on a copy of my production site.) |
| 23:33 | <roc> | that sounds like a bug to me |
| 23:33 | <Hixie> | it's almost certainly a bug, yes |
| 23:41 | <TabAtkins> | roc: Does Firefox not obey dynamic changes to <base target>? |
| 23:41 | <TabAtkins> | (That appears to be what's stopping this from working in FF.) |
| 23:41 | <roc> | I think we do, but there could be a bug |
| 23:41 | <roc> | (it's a huge pain) |
| 23:42 | <TabAtkins> | Heh, kk. |
| 23:42 | <roc> | oh hmm |
| 23:42 | <roc> | <base target> |
| 23:42 | <roc> | I dunno |
| 23:42 | <roc> | I've never even heard of that, so I dunno :-) |
| 23:42 | <roc> | if it doesn't, it's probably easy to fix |
| 23:43 | <Hixie> | iirc html5 defines <base target> not quite how firefox does it anyway |
| 23:43 | <Hixie> | so at some point we should file bugs and have that fixed |
| 23:43 | <TabAtkins> | Haha. Well, this @onlyreplace impl works in Chrome. It fails in Firefox, but if I manually add the appropriate @target to <base>, it works. So that suggests <base target> isn't being honored when changed dynamically by script. |
| 23:43 | <Hixie> | it's not a high priority though |