| 00:00 | <othermaciej> | Mozilla also has some nonstandard extensions right in the mouse event - caretRangeFromPoint() lets you do the hit testing at any time though, you don't need an event |
| 00:04 | <TabAtkins> | Thanks, othermaciej. I've passed the info along. |
| 00:12 | <othermaciej> | so I hear Web Fonts is going to define not one but two new font formats |
| 00:12 | othermaciej | is not sure what to think of this |
| 00:12 | <Rik`> | WOFF and ? |
| 00:13 | <TabAtkins> | CWT. |
| 00:13 | <TabAtkins> | Which is a fancy name for version 1 EOT. |
| 00:13 | <TabAtkins> | With some of the header cruft ignored. |
| 00:13 | <othermaciej> | and then it will also recommend regular OTF and SVG fonts, and require browsers to implement at least 2 |
| 00:13 | <othermaciej> | call me crazy, but isn't this even worse for interop than the status quo? |
| 00:14 | <TabAtkins> | I don't see how it can possibly be worse. |
| 00:14 | <TabAtkins> | But it's likely that everyone will end up supporting WOFF. |
| 00:14 | <Rik`> | othermaciej: my understanding is that the goal is not interop but font makers pleasure |
| 00:14 | <othermaciej> | I'm trying to figure out if I should ask our AC Rep to oppose this or just close my eyes and think of england |
| 00:16 | <TabAtkins> | What would you propose if you opposed it? |
| 00:17 | <othermaciej> | not having a Fonts working group at all |
| 00:17 | <TabAtkins> | And then do what about font interop? Hope it all works out? |
| 00:19 | <othermaciej> | wait for one side or the other to capitulate |
| 00:20 | <othermaciej> | another alternative would be to pursue only one new font format and get everybody on board with implementing it, instead of the weird "pick 2 of 4" thing |
| 00:20 | <TabAtkins> | Sylvain appears to be hinting that WOFF is his expected consensus solution. |
| 00:21 | <TabAtkins> | (Though I'm still gunning for CWT.) |
| 00:21 | <othermaciej> | that being said, WOFF seems DRM-free |
| 00:21 | <TabAtkins> | None of the 4 formats are DRMed in any way, shape, or form. |
| 00:21 | <othermaciej> | it just seems like implementing it is a giant waste of effort |
| 00:22 | <TabAtkins> | Yeah, but MS hasn't given up and implemented TTF yet, and hasn't given any indications that they'd like to, either. |
| 00:23 | <Rik`> | TabAtkins: MS hasn't implemented addEventListener but no one has invented yet another way to add handlers because of that |
| 00:24 | <TabAtkins> | Yeah, but has MS consistently openly refused to implement it, and had strong statements from people in the organization that they don't expect to? |
| 00:25 | <Rik`> | that's not the point |
| 00:25 | <TabAtkins> | It is. There's a difference between "hasn't done it yet" and "has refused to do it". |
| 00:25 | <Rik`> | developers know how to use different code paths for stupid browsers |
| 00:27 | <Rik`> | if MS doesn't want to play ball and developers have a cross browser solution, why would you invent something else ? |
| 00:27 | <TabAtkins> | But JS differences can be papered over trivially in libraries so you never have to think about it again. This isn't the same thing. |
| 00:27 | <TabAtkins> | ...we *don't* have a cross-browser solution. We have two separate solutions that we have to weld together manually every single time we want to use them. |
| 00:28 | <Rik`> | they are ttf2eot tools, it's a one line fix |
| 00:28 | <TabAtkins> | And you have to store both and link both every time. |
| 00:29 | <Rik`> | "store" a < 1mo file ? |
| 00:30 | <Rik`> | people already have a lot of CSS path for IE |
| 00:30 | <TabAtkins> | It's still a hassle. Imagine if you had to duplicate every image you used on your site and link both of them. |
| 00:30 | <Rik`> | isn't that what people do for PNG alpha transparency ? |
| 00:30 | <TabAtkins> | No. They either link a non-PNG, or they use one of the pngFix libraries, or they just ignore ie6. |
| 00:31 | <Rik`> | and fwiw, people can just treat IE as one of the non supporting browsers |
| 00:32 | <TabAtkins> | Yeah, not actually possible when the marketing department wants a special headline font. |
| 00:33 | <Rik`> | or you can create a JS library that reads your font-face rules and create a new rule for IE |
| 00:34 | <TabAtkins> | That then ties to you js (which is okay if you're doing purely visual tweaks, but not if you're linking in a font for your uncommon language), and still requires two font files to be created (not much of a hassle by itself, but still more than should be necessary). |
| 00:35 | <Rik`> | what about the hassle of waiting three years before seeing a version of IE supporting those new formats |
| 00:36 | <TabAtkins> | That's why I support CWT. |
| 00:36 | <TabAtkins> | Then IE6+ will all work, and I only have to wait for the other browsers to update, which is much faster. |
| 00:36 | <Rik`> | and the user base ? |
| 00:36 | <TabAtkins> | The userbase of non-IE browsers updates *much* faster. |
| 00:37 | <TabAtkins> | I imagine mostly because the browsers are actually willing to auto-update. |
| 00:37 | <Rik`> | still need around one year after release |
| 00:37 | <TabAtkins> | Yup, that's not so bad. It is the fastest path to interop among all the options. |
| 00:37 | <TabAtkins> | I mean, even if IE promised TTF support in IE9, it'd still be 5+ years before it's usable. |
| 00:38 | <Rik`> | or use ttf + eot right now |
| 00:38 | <Rik`> | (or in one year for a solid userbase) |
| 00:38 | <TabAtkins> | Yeah, that's still a crappy option though. |
| 00:40 | <AryehGregor> | How does CWT handle origin control? |
| 00:41 | <AryehGregor> | I recall that being a sticking point for an EOT-based solution before I stopped following www-font. |
| 00:41 | <TabAtkins> | AryehGregor: The same way TTF does - through same-origin controls. |
| 00:41 | <Rik`> | anyway, off to bed |
| 00:42 | <TabAtkins> | Later, Rik`. |
| 00:42 | <AryehGregor> | If the rootstring is nonempty, is it ignored, or do non-IE browsers refuse to process the file? |
| 00:43 | <TabAtkins> | CWT has no rootstring - it's current based on eot version 1. |
| 00:43 | <AryehGregor> | So IE <= 8 (i.e., large majority of users' browsers) won't implement origin restrictions at all, then? |
| 00:43 | <TabAtkins> | Even when it was based on version 2, cwt itself had no rootstring, it just had meaningless padding. Whether or not legacy nonconforming clients interpreted that padding as a rootstring was up to them. |
| 00:43 | <TabAtkins> | (Which I preferred, but people bitched about it.) |
| 00:43 | <AryehGregor> | Are font foundries actually willing to license anything in this format? |
| 00:43 | <TabAtkins> | And yes. |
| 00:44 | <TabAtkins> | Anyone who's licensing in TTF would obviously license in CWT. |
| 00:44 | <AryehGregor> | Right, but the point is a lot of foundries don't want to license in TTF, I thought? |
| 00:44 | <AryehGregor> | Or have a lot of them cracked by now? |
| 00:45 | <TabAtkins> | There's still plenty that don't. |
| 00:45 | <TabAtkins> | ;_; |
| 00:46 | <TabAtkins> | But that's why I thought the whole uproar over basing CWT on EOTv2 was stupid. It would let us make an end-run around that crap without bringing rootstring baggage into future browsers. |
| 00:46 | <AryehGregor> | Has any foundry said they'll license EOT but not WOFF, or is everyone as okay with WOFF as they're going to get? |
| 00:46 | <TabAtkins> | I dunno. I know Ascender's cool with CWT, but I dunno if anyone's outright said that they're cool with WOFF. |
| 00:47 | TabAtkins | is heading to dinner now. |
| 00:47 | <AryehGregor> | Oh well. We'll see. |
| 01:28 | <roc> | TabAtkins: CWT really isn't appealing as currently specified, see my email. You would have to use Referer checking. Easier to just produce and serve two (or more) font files. |
| 01:28 | <roc> | othermaciej: WOFF is trivial. At worst, implementing it is a *tiny* waste of effort |
| 01:29 | <othermaciej> | the font guys at Apple were not at all enthusiastic about supporting a new font format |
| 01:29 | <othermaciej> | if WOFF can easily and efficiently be converted to OTF or TTF then I guess it's somewhat less of a waste of time |
| 01:31 | <roc> | it really is the thinnest possible wrapper around OTF+TTF, plus per-table zlib compression |
| 01:31 | <othermaciej> | I'm wary that the "plus" is what will make it nontrivial to implement efficiently (at least given only a blackbox OTF/TTF implementation) |
| 01:32 | <roc> | you have to decompress the tables |
| 01:32 | <roc> | but you already have to mangle tables |
| 01:32 | <othermaciej> | I do? |
| 01:32 | <roc> | to work around Windows bugs etc |
| 01:32 | <roc> | yep |
| 01:32 | <roc> | you do |
| 01:32 | <roc> | and the zlib decompression is easier than that |
| 01:34 | <roc> | OTF/TTF implementations are more of a black box to us than to you, remember |
| 01:34 | <roc> | at least until we ship Harfbuzz |
| 01:34 | <othermaciej> | I don't think we do any mangling of tables |
| 01:35 | <othermaciej> | (that's either due to my ignorance, or due to the fact that we use Apple's font implementation on Windows) |
| 01:35 | <othermaciej> | still seems like a waste of time to me |
| 01:35 | <roc> | I'm pretty sure you do |
| 01:36 | <othermaciej> | pursuing both WOFF and CWT (but then effectively not mandating either) seems even more wasteful |
| 01:36 | <roc> | yeah, we're not interested in that |
| 01:38 | <othermaciej> | if everyone else implements WOFF then we'll probably have to, but I can't say the prospect fills me with any enthusiasm |
| 01:39 | <roc> | you implemented SVG fonts, which are considerably more useless IMHO |
| 01:39 | <othermaciej> | incidentally - am I wrong to be concerned about the idea of a Microsoft-edited Canvas spec? Can't tell if I'm being too paranoid or not paranoid enough |
| 01:39 | <roc> | I thought that was weird too |
| 01:39 | <jcranmer> | roc: I think Hixie disagrees... it's in Acid3, after all |
| 01:40 | <othermaciej> | SVG fonts are kind of useless for real content, but at least they can achieve special effects that other font formats can't do |
| 01:40 | <roc> | othermaciej: yeah, but you didn't implement that part |
| 01:40 | <roc> | jcranmer: I think Hixie may regret putting in Acid3, you should ask him |
| 01:40 | <othermaciej> | what do you mean? colored glyphs work fine afaik |
| 01:41 | <roc> | not in my tests |
| 01:41 | <othermaciej> | as does crazy stuff like per-character rotation and positioning on a path (though the latter I think you can do with SVG text and non-SVG fonts) |
| 01:41 | <roc> | yes, you can |
| 01:42 | <jcranmer> | hmm, why are the animation tests failing on FF 3.6? |
| 01:42 | <roc> | othermaciej: see http://lists.w3.org/Archives/Public/www-svg/2009Sep/0013.html |
| 01:42 | <othermaciej> | text on a path should really be doable without using SVG at all IMO |
| 01:42 | <roc> | maybe my testcase is broken but no-one contradicted me |
| 01:43 | <othermaciej> | our implementation doesn't rasterize the glyphs, it just draws them anew every time, so I'd be surprised if it had that limitation |
| 01:43 | <roc> | what limitation? |
| 01:43 | <roc> | SVG glyphs really have two parts |
| 01:44 | <roc> | a path in the "d" attribute of the <glyph> element |
| 01:44 | <roc> | and arbitrary SVG content in the subtree rooted at <glyph> |
| 01:44 | <roc> | as far as I could tell, Opera and Webkit support the former but not the latter |
| 01:44 | <roc> | again, maybe I'm wrong |
| 01:44 | <othermaciej> | I see |
| 01:45 | <roc> | if you read that thread, I have some arguments that the way arbitrary-content glyphs are handled is actually quite broken |
| 01:46 | <roc> | oh, in a slightly later thread: http://lists.w3.org/Archives/Public/www-svg/2009Sep/0043.html |
| 01:47 | <othermaciej> | I'm sure you're right - <foreignObject> in a glyph could be quite crazy |
| 01:47 | <othermaciej> | (though not that much worse than <use>) |
| 01:48 | <roc> | somewhat worse, since you have to support associating the anonymous content with HTML text, you can't just confine the madness to SVG |
| 01:50 | <roc> | the quandry we have over SVG fonts is whether to implement the subset you guys did --- basically to just pass Acid3, since it offers nothing that is not more conveniently expressed with normal downloadable fonts --- or to implement the whole thing, which actually might be useful but has serious implementation difficulties that no-one else has seen fit to tackle yet |
| 01:50 | <roc> | and actually kinda sucks for authors anyway |
| 02:00 | <othermaciej> | the original reason we have SVG fonts at all is due to enthusiasm of some of the contributors who wrote our original SVG implementation |
| 02:01 | <othermaciej> | (they added fonts later, but it was the same guys basically) |
| 02:01 | <othermaciej> | although we did fix a bunch of bugs with metrics and other arcane details for Acid3 |
| 02:02 | <othermaciej> | I think having SVG font and SVG animation tests in Acid3 was kind of lame; at the time only Opera had these things implemented and I think it was an Opera developer who submitted those particular tests |
| 02:02 | <roc> | that is true |
| 02:04 | <roc> | Acid3 marketing is likely to just force us to implement at least that subset of SVG fonts |
| 02:05 | <roc> | but if the arbitrary-SVG feature doesn't get implemented, or does get implemented according to the current spec and sucks as much as I think it will, then Acid3 will be responsible for a stupid wart in the Web platform |
| 02:08 | <roc> | oh well, few participants are completely guiltless on that score :-) |
| 02:18 | <othermaciej> | indeed |
| 02:18 | <othermaciej> | there's no shortage of warts |
| 02:23 | <roc> | they still irritate me |
| 02:23 | <othermaciej> | I try to focus my irritation on proposals to add new warts |
| 03:08 | <TabAtkins> | roc, othermaciej: If I recall correctly, CWT is similarly a super-thin wrapper over TTF. Isn't it nothing more than a header of a couple of bytes? It doesn't even employ any manipulation of the font-data (EOT can do compression on fonts, but the CWT proposal currently specifies uncompressed fonts, to avoid patent issues). |
| 03:09 | <othermaciej> | doesn't EOT have XOR "encryption"? |
| 03:09 | <TabAtkins> | I don't believe that the EOT version used for CWT does. |
| 03:09 | <TabAtkins> | (It's been a few months since the font discussion, though.) |
| 03:10 | TabAtkins | is pulling up the archives real quick to see if he can answer definitively. |
| 03:14 | <TabAtkins> | othermaciej: I just confirmed - CWT uses *no* scrambling, XOR, MTX, or otherwise. |
| 03:14 | <othermaciej> | does it alter the font file less than WOFF? |
| 03:16 | <TabAtkins> | *All* that it does is prepend the font with some header bytes. That's literally it. Chop off the header and you've got a perfectly valid ttf font. |
| 03:17 | <TabAtkins> | So, yes. |
| 03:17 | <TabAtkins> | (Since WOFF does the per-table compression.) |
| 03:17 | <othermaciej> | I guess that is an advantage - the downside being that people who only test in IE may accidentally serve EOT fonts using more than the CWT subset |
| 03:19 | <TabAtkins> | True, but the common options used when generating EOT will make it immediately fail in a normal CWT-supporting browser. So you'd really have to test *only* in IE. |
| 03:20 | <TabAtkins> | Here's Daggett's 1.1 proposal. I think it's the latest 'official' specced version: http://lists.w3.org/Archives/Public/www-font/2009JulSep/0969.html |
| 03:21 | <othermaciej> | "the common options used when generating EOT will make it immediately fail in a normal CWT-supporting browser" -- that's not a feature! |
| 03:21 | <TabAtkins> | Sure it is. It keeps you from accidentally serving EOT. ^_^ |
| 03:22 | <othermaciej> | it would be much better if the common options used when generating EOT made it Just Work(tm) in a normal CWT-supporting browser |
| 03:22 | <othermaciej> | though I'm sure the tradeoff there is implementation complexity |
| 03:23 | <TabAtkins> | But the common option is one of the compression options. |
| 03:23 | <TabAtkins> | Yeah. |
| 09:41 | gsnedders | is trying to fix the only test failure in html5lib |
| 10:05 | <MikeSmith> | hsivonen, Hixie: I just checked in a v.nu change to fix the <caption> error |
| 10:05 | <MikeSmith> | so the spec now validates once again |
| 10:05 | <MikeSmith> | http://qa-dev.w3.org:8888/?doc=http://www.whatwg.org/specs/web-apps/current-work/ |
| 10:06 | <Hixie> | i bet the complete.html file still doesn't validate :-) |
| 10:06 | <MikeSmith> | ah |
| 10:06 | <MikeSmith> | OK, I'll check that next |
| 10:06 | <MikeSmith> | Hixie: that was due to the microdata thing, right? |
| 10:06 | <Hixie> | yeah |
| 10:06 | <MikeSmith> | OK |
| 10:06 | <MikeSmith> | I'll look at that next |
| 10:08 | <MikeSmith> | hsivonen: it seems that maxFileSize needs to be increased once again |
| 10:08 | <MikeSmith> | HTML5 is now 4304 KB |
| 10:09 | MikeSmith | hopes complete.html is not more than 5MB |
| 10:34 | <Philip`> | MikeSmith: Content-Length: 4831259 |
| 10:35 | <Philip`> | But I bet it'll grow :-p |
| 10:35 | <MikeSmith> | yeah |
| 10:35 | <MikeSmith> | I upped it to 5120 on qa-dev for now |
| 10:36 | <MikeSmith> | Hixie: OK, patched it enough for now to get complete.html to validate - |
| 10:36 | <MikeSmith> | http://qa-dev.w3.org:8888/?doc=http://www.whatwg.org/specs/web-apps/current-work/complete.html |
| 10:36 | <Hixie> | i'm gonna have to start writing test cases for validators :-) |
| 10:36 | <MikeSmith> | heh |
| 10:36 | <MikeSmith> | <snort> |
| 10:38 | <MikeSmith> | with that, I gots to drop off and catch a train back to civilization.. back later |
| 10:58 | <mikekelly> | I hope Roy doesn't bite my head off :( |
| 11:00 | <mikekelly> | we RESTafarians have a vengeful god |
| 11:02 | <Dashiva> | Don't worry, Roy bites everyone's head off |
| 11:03 | <Philip`> | How is this "other applicable specifications" thing meant to work when applying multiple specs that conflict? |
| 11:03 | <Philip`> | and you'd get a different interpretation depending on which order you apply them in |
| 11:04 | <Dashiva> | Philip`: If they conflict they aren't all applicable? |
| 11:06 | Philip` | tries in vain to think of a concrete example |
| 11:09 | <Philip`> | I don't mean things that conflict incompatibly, just things that define non-commutative changes to parts of HTML5 |
| 11:10 | <mikekelly> | Is that point the Smylers guy made true - that html implements the features of related specs/protocols that it deems appropriate? |
| 11:10 | <Philip`> | No |
| 11:10 | <mikekelly> | so interop is an objective? |
| 11:11 | <Dashiva> | Philip`: Could you make up an unrealistic example? |
| 11:11 | <mikekelly> | I really think that http conneg needs to be accepted how its defined right now (as I'm reading it) or re-written to suit the purposes of everyon else's interpretation |
| 11:12 | <Hixie> | Philip`: you have to pick the order in which they apply |
| 11:12 | <mikekelly> | because everyone else's interpretation (regardless of whether it's "practical or not") makes assumptions which are not specified in the spec |
| 11:12 | <Philip`> | Dashiva: Maybe I'm thinking of something like if HTML5 didn't include SVG itself, and a separate spec said "parse everything as normal except when you get an xmlns:xlink attribute do this magic thing etc", and another spec says "parse everything as normal except when you get an xmlns:* attribute do Namespaces-like processing" |
| 11:13 | <Dashiva> | Right |
| 11:13 | <Dashiva> | That's the motivation for internalizing everything requiring parser/tokenizer changes |
| 11:13 | <Dashiva> | Maybe that should be clarified |
| 11:14 | <Philip`> | and so an HTML5+SVG+NS implementation will give different output to an HTML5+NS+SVG implementation |
| 11:14 | <Hixie> | always a risk |
| 11:14 | <Hixie> | but that's the case regardless of what html5 says |
| 11:14 | <Hixie> | since other specs can always say they override it |
| 11:14 | <Hixie> | and you can always chose to honour or not honour spces |
| 11:14 | <Hixie> | specs |
| 11:16 | <mikekelly> | you can assuming you are comfortable with the social costs of doing that |
| 11:17 | <Philip`> | The (hypothetical) issue is that you choose to perfectly honour precisely the same set of specs as somebody else, yet get a different output because you're interpreting them in a different order |
| 11:17 | <mikekelly> | of course that is not of massive concern if you live with your head up your anus |
| 11:17 | <Philip`> | so the order is just as important as the choice of honouring or not |
| 11:18 | <Hixie> | Philip`: yes |
| 11:19 | <Philip`> | mikekelly: Rewriting specs to match reality sounds like a good idea - try asking the HTTP people to do that, if you think they're wrong |
| 11:19 | <Dashiva> | HTTP being wrong? Heresy |
| 11:21 | <Philip`> | mikekelly: Oh, when I said "No" to you earlier I had misread your question |
| 11:21 | <Philip`> | I thought you said "Is that the point ..." and it wasn't that point, but that wasn't what you said |
| 11:21 | <Philip`> | so ignore my response |
| 11:25 | <mikekelly> | ok.. |
| 11:25 | <mikekelly> | what of http isn't written to match reality? |
| 11:26 | <mikekelly> | i'm not challenging you I'm asking for your opinion |
| 11:26 | <Philip`> | mikekelly: Presumably the bits where you say everybody (except you) disagrees with it |
| 11:27 | <mikekelly> | right - so the conneg definitions which clearly state they are tied to a *request* and yet everyone insist they are somehow tied to client default preferences |
| 11:27 | <mikekelly> | I agree. |
| 11:28 | <mikekelly> | I think you're all missing an opportunity for efficiency gains |
| 11:28 | <mikekelly> | but that's fine - it should be cleared up in the http spec if everyone insists on being wrong :P |
| 11:29 | <mikekelly> | the world of caching shall forever be flat. |
| 11:30 | <mikekelly> | aside from that, I don't think http gets much wrong |
| 11:30 | <mikekelly> | what else did you have in mind? |
| 11:31 | <mikekelly> | (bearing in mind that HTML's deficiencies will play a large role in what does or doesn't work "in practice") |
| 11:31 | <mikekelly> | presumably why PUT/DELETE are being added |
| 11:32 | <mikekelly> | even though "in practice" PUT/DELETE "don't work" |
| 11:32 | <mikekelly> | because they "aren't used" |
| 11:32 | <gsnedders> | mikekelly: See AryehGregor's email for an example where HTTP cannot help caching, due to the complexity of a lot of websites |
| 11:32 | <gsnedders> | mikekelly: e.g., on my blog, posting a new page via PUT would only invalid one page's cache, not the entire website's as would be needed |
| 11:32 | <mikekelly> | gsnedders: I deliberately didn't repsond to that because the response would be long winded and not a lot to do with html |
| 11:32 | <mikekelly> | it's to do with how you identify resources |
| 11:32 | <mikekelly> | and how granular you make them |
| 11:33 | <mikekelly> | and/or how much you avoid composite resources |
| 11:33 | <mikekelly> | which derive state from other resources |
| 11:33 | <mikekelly> | that is a design decision and your application can address those issues depending on the requirements |
| 11:33 | <mikekelly> | there's also absolutely no requirement to implement that kind of caching mechanisms across the board |
| 11:33 | <mikekelly> | it can be applied where and when it is most valuable |
| 11:35 | <mikekelly> | feel free to contest that btw.. |
| 11:36 | <mikekelly> | gsnedders: if you submit a new post with POST to your 'root' blog resource |
| 11:36 | <mikekelly> | POST /Blog would indicate the blog resource shouldbe invalidated |
| 11:37 | <mikekelly> | a composite resource at blog would emit the blog post information within the blog resource |
| 11:37 | <mikekelly> | the alternative is to simply provie the links to the posts |
| 11:37 | <mikekelly> | and use javascript to fetch each post and render it onto the page |
| 11:38 | <mikekelly> | which prevents the blog page becoming stale if you PUT a new version of a particular post |
| 11:39 | <mikekelly> | obviously if you create a new blog post using PUT to a new URI - then the blog page would not be updated |
| 11:39 | <mikekelly> | that makes sense.. |
| 11:39 | <mikekelly> | which is why it would make more sense to use POST |
| 11:39 | annevk | is with othermaciej on the fonts crap |
| 11:40 | <Philip`> | (Becuse a dozen cached requests to generate a blog's front page with a dozen posts is going to be much more efficient than a single uncached request?) |
| 11:40 | <Philip`> | s//a/ |
| 11:40 | <mikekelly> | depends on the complexity behind the URI |
| 11:40 | <mikekelly> | that is just an example |
| 11:40 | <mikekelly> | it's a trade-off |
| 11:40 | <mikekelly> | I think I've said that about 12 times now :) |
| 11:42 | <mikekelly> | disagree? |
| 11:43 | <mikekelly> | ok.. then.. |
| 11:43 | <mikekelly> | :) |
| 11:45 | Philip` | is too busy eating biscuits to disagree |
| 11:45 | <mikekelly> | heh, this is a good example of why we are going round in circles |
| 11:46 | <mikekelly> | gsnedders: which parts of that do you disagree with/are skeptical about? |
| 11:47 | <annevk> | gsnedders, where are you? |
| 11:47 | <annevk> | gsnedders, and where do we need to be? I'm somewhere close to the bar, near the beachfront |
| 11:48 | <gsnedders> | annevk: Between the restaurant and the room we were in earlier |
| 11:48 | <gsnedders> | annevk: I'm sitting with jgraham hacking on html5lib |
| 11:48 | <annevk> | good stuff |
| 11:49 | <annevk> | I haven't gotten further than reading email |
| 11:49 | annevk | was planning on editing |
| 11:51 | <annevk> | with regards to the range API discussion earlier |
| 11:51 | <annevk> | that is planned |
| 11:51 | <annevk> | but note that hit testing is not actually defined yet anywhere |
| 11:52 | <annevk> | so technically everything is up in the air |
| 11:52 | <annevk> | but if a UA implements a sensible definition of hit testing it will prolly work |
| 11:55 | <gsnedders> | annevk: Is it cold there? |
| 11:55 | jgraham | would prefer nto be near the beach |
| 11:55 | <annevk> | not really |
| 11:55 | <jgraham> | Or on the beach if the wifi would extend that far |
| 11:55 | <annevk> | dunno about that |
| 11:55 | <gsnedders> | That would be cold. |
| 11:56 | <gsnedders> | This is Sweden, after all. |
| 11:56 | <annevk> | yeah, you need more than a t-shirt |
| 11:56 | <jgraham> | I could get a hat |
| 11:56 | <annevk> | it'd be a start |
| 11:56 | <jgraham> | gloves might make typing hard though |
| 11:56 | <annevk> | though sand in your keyboard sucks |
| 11:56 | <gsnedders> | I have a hoodie t-shirt on, so anything on this looks kinda stupid |
| 11:57 | <gsnedders> | annevk: How'd you get there? Just through the big hall? |
| 12:04 | <annevk> | I ate lunch here |
| 12:04 | <annevk> | there's a staircase just before you enter the dining area |
| 12:11 | <gsnedders> | annevk: Oh, that place, I thought by "near the beachfront" you meant outside. But there again, here, near the beachfront can quite easily be inside :) |
| 12:12 | <annevk> | indeed |
| 14:44 | <gsnedders> | html5lib now passes 100% on a stock Python setup! |
| 14:44 | <jgraham> | gsnedders: Now install bs |
| 14:44 | <gsnedders> | jgraham: That's bullshit |
| 14:44 | <jgraham> | Sigh |
| 14:52 | TabAtkins | giggles. |
| 15:27 | <TabAtkins> | Would anyone have any idea/way of checking if aria roles are already commonly used in HTML on the web? |
| 15:30 | <Philip`> | TabAtkins: I wouldn't |
| 15:30 | <Philip`> | (I can only look at stuff from six months ago) |
| 15:30 | <TabAtkins> | k. |
| 15:30 | <TabAtkins> | Well hey, was aria common the web six months ago? |
| 15:36 | <Philip`> | TabAtkins: http://philip.html5.org/data/role-attributes-raw.txt is the raw data from 425K dotbot pages |
| 15:36 | <Philip`> | (including non-text/html pages) |
| 15:42 | <Philip`> | Does the validator.nu parser have the scripting flag enabled or disabled by default? |
| 15:45 | <TabAtkins> | Philip`: Thanks, that's very useful! It appears that aria was almost completely unused. |
| 15:52 | <Philip`> | TabAtkins: Almost completely used in static markup in pages which were in the sample |
| 15:52 | <TabAtkins> | Yus. Good enough for me. |
| 15:52 | <Philip`> | The "static" is probably the main issue - it's presumably used a lot more in scripted widget libraries, not static content |
| 15:53 | <TabAtkins> | Philip`: But I don't see a single aria-related use of role which is grossly changing the semantics of the element it is applied to, which is what I was looking for. |
| 15:54 | <TabAtkins> | I expect that widget libraries tend to rely on <div> and <span>, where all roles are valid, and thus they aren't relevant to the discussion with Leif. |
| 15:54 | <Philip`> | TabAtkins: http://google.com/codesearch?q=role%3D+lang%3Ahtml |
| 15:54 | <Philip`> | That might be more useful |
| 15:55 | <Philip`> | http://google.com/codesearch?q=role%3D+lang%3Ajs too |
| 15:56 | <TabAtkins> | That is useful, thank ou! |
| 15:56 | <Philip`> | Dojo uses waiRole="..."? I thought it was meant to be role="..."... |
| 16:03 | <Philip`> | Why aren't computers infinitely fast :-( |
| 16:44 | <TabAtkins> | Philip`: Because if they were we'd be living in a simulation with probability 100%. |
| 16:49 | <mikekelly> | hello browser people |
| 16:51 | <gsnedders> | jgraham: Can I just make html5lib raise a warning with bs + ns? |
| 16:51 | <mikekelly> | is there a chance we could ever have functionality where javascript can cause new page to load with custom headers? |
| 16:55 | <Philip`> | zcorpan: Ping |
| 16:56 | gsnedders | notes he hasn't seen zcorpan with a computer all day |
| 16:56 | <Philip`> | He can read logs :-) |
| 16:56 | <gsnedders> | I am aware. I'm just letting you know you won't get a quick response |
| 16:56 | <Philip`> | Or you could ping him manually |
| 16:56 | <Philip`> | if you're near him |
| 16:57 | <gsnedders> | Philip`: I don't think he's in this room |
| 16:57 | <Philip`> | or even point him at http://philip.html5.org/data/cdata-containing-self-close.txt |
| 16:57 | <Philip`> | which hopefully isn't too incompatible with what he wanted |
| 16:58 | Philip` | is happy to wait until whenever he gets back here |
| 17:09 | <gsnedders> | Philip`: pong from zcorpan |
| 17:09 | <jgraham> | gsnedders: It already does, doesn't it? |
| 17:09 | <gsnedders> | Philip`: thanks from zcorpan |
| 17:19 | <gsnedders> | Hixie: WAKE UP! |
| 17:27 | <Philip`> | gsnedders: If you use figlet you can shout louder on IRC, which might wake him up |
| 17:28 | <RIK|WORK> | PS : IT IS CAPS LOCK DAY |
| 17:31 | <Philip`> | RIK|WORK: I have caps lock on all the time but I hold down shift too so that I irritate people less |
| 17:52 | <Philip`> | The spec comment box ought to be bigger |
| 23:00 | <TabAtkins> | roc: Which is easier for you - (1) defaulting the first/last stops if necessary, then correcting misordered stops, then defaulting any remaining stops, or (2) correcting misordered stops, then defaulting all remaining stops, with first being min(0,first specified stop) and last being max(100%,last specified stop)? |
| 23:00 | <roc> | the former, since that's what I implemented |
| 23:01 | <TabAtkins> | kk. |
| 23:01 | <roc> | it's efficient, I do it in O(N) time in the number of stops, and it's reasonably simple |
| 23:03 | <sicking> | Hixie: does @rel no longer allow URI tokens? |
| 23:04 | <sicking> | Hixie: without registring them in the wiki that is |
| 23:04 | <Hixie> | it's never allowed tokens that aren't registered as far as i recall |
| 23:04 | <Hixie> | registering them is pretty trivial though |
| 23:09 | <TabAtkins> | roc: Changes made, and are visible in the draft on my site. Thanks for the "specified position" terminology - I was struggling with how to say that. Also rearranged/reworded linear-gradient()'s treatment of the two <angle> cases to allow the behavior you've implemented. |
| 23:09 | <roc> | yay, thanks |
| 23:12 | <TabAtkins> | No problem; thanks for implementing it. ^_^ I'm speccing the repeating-* functions now. |
| 23:14 | <roc> | BTW, Firefox builds with the implementation here: https://build.mozilla.org/tryserver-builds/zweinberg⊙mc |
| 23:15 | <TabAtkins> | There any instructions on installing ff builds? Never done one before. |
| 23:23 | <roc> | depends on the platform |
| 23:23 | <roc> | but these builds install just like any other Firefox release |
| 23:24 | <roc> | if you're on Windows, the easiest thing to do is to just download the ZIP, unzip it somewhere, and run firefox.exe |
| 23:24 | <roc> | it's that simple |
| 23:25 | <Philip`> | and make sure you're not already running a Firefox process |
| 23:25 | <roc> | you may want to run "firefox.exe -P" and create a new profile for testing, that lets you run concurrently with an already-running Firefox |
| 23:26 | <Philip`> | Don't you need to add -noremote or something? |
| 23:26 | <roc> | yeah, you probably do |
| 23:27 | <Philip`> | So it's not quite that simple ;-) |
| 23:27 | <roc> | running with a different profile can also be good because there is also a small chance that running a trunk build with your existing profile will cause problems when you go back to using your release version with that profile, although that has never happened to me, so the chances are very small indeed |
| 23:28 | <TabAtkins> | Since I do IRC using chatzilla, being able to run it concurrently seems useful. |
| 23:28 | <roc> | Philip`: perhaps Tab runs IE as his main browser? :-) |
| 23:29 | <jwalden> | TabAtkins: http://chatzilla.rdmsoft.com/xulrunner/ |
| 23:29 | Philip` | shudders |
| 23:29 | <TabAtkins> | No, I run chatzilla in FF, gmail in chrome, then everything else in whichever one is handy when I ctrl+t. |
| 23:31 | <TabAtkins> | jwalden: Thanks! |
| 23:33 | <jwalden> | chatzilla as its own app is so much money it's not even funny |
| 23:34 | <jwalden> | especially back when its link-opening behavior wouldn't open a new tab but rather blow away the most recent one |
| 23:35 | <daedb> | sigh... I'm trying to learn some simple <canvas> stuff (using Dive into html5 as a guide), and I can't even get past the first bloody getContext. Javascript hates me :( |
| 23:38 | <Philip`> | daedb: Sounds like a bug in Dive into HTML5 if you can't get its examples to work |
| 23:38 | <Philip`> | daedb: Blame mpilgrim :-) |
| 23:40 | <TabAtkins> | All right, got it running. Awesome. |
| 23:40 | <TabAtkins> | That was too easy. |
| 23:43 | <daedb> | Philip`: I found a tutorial on Mozilla's dev site, and it's exactly the same with their example code... |
| 23:45 | <Philip`> | daedb: What kind of problem are you getting? |
| 23:45 | <Philip`> | daedb: Also, what browser are you running it in? (I hope it's not IE :-) ) |
| 23:46 | <daedb> | Philip`: <script>var canvas = document.getElementById('tid'); var context = canvas.getContext('2d');</script> <-- all my code so far, gives a TypeError (message: Statement on line 1: Cannot convert undefined or null to Object |
| 23:46 | <daedb> | ) |
| 23:46 | <daedb> | this is in Opera, btw |
| 23:46 | <Philip`> | daedb: Do you have a <canvas id=tid></canvas>, before the script? |
| 23:48 | <daedb> | The <canvas> has to be before the <script>? I had the script in the head... |
| 23:48 | <TabAtkins> | The script is trying to run before the <canvas> is loaded. |
| 23:49 | <Philip`> | Is there some way I can do something equivalent to <div style="background: black; opacity: 0.8"> (on top of a background image) that also works in IE6+? |
| 23:49 | <daedb> | Whee, it works after moving down the script. Thanks, Philip`! |
| 23:49 | <Philip`> | daedb: The <script> executes as soon as it's parsed, so the <canvas> hasn't been parsed yet, but you could solve it more nicely by using onload |
| 23:49 | <TabAtkins> | Philip: use a PNG and one of the pngFix libraries? |
| 23:49 | <Philip`> | daedb: like <script>function draw() { var canvas = ... }; window.onload = draw;</script> ... <canvas> |
| 23:51 | <TabAtkins> | Or like <script>$(function(){ var canvas=...; });</script> ^_^ |
| 23:51 | <Philip`> | TabAtkins: My way requires tens of kilobytes less scripting :-p |
| 23:51 | <TabAtkins> | Bah. |
| 23:52 | <daedb> | heh, I don't do much javascript... I should probably learn it properly some day :p |
| 23:53 | <TabAtkins> | It's a good language, once you library your way past the bad DOM apis. |
| 23:57 | <TabAtkins> | Sigh... Damn you, magic fieldset styling. I hate you *so* much. |