| 00:28 | <abarth> | i think the main thing we want is the autosizing |
| 00:28 | <abarth> | which I guess is what you mean by "shrink wrapping" |
| 00:28 | <Hixie> | right |
| 00:28 | <abarth> | disabling borders by default makes sense too |
| 00:28 | <Hixie> | do you know of anyone outside chrome who wants to implement this? |
| 00:29 | <abarth> | (one sec) |
| 00:31 | <abarth> | ok, back |
| 00:32 | <abarth> | there are definitely other folks at Google who would like us to ship seamless |
| 00:32 | <abarth> | and to have crossorigin support |
| 00:32 | <abarth> | I don't know where it is on the priority list for other browser vendors |
| 00:34 | <abarth> | the list you have above looks reasonable if you assume that you already have a fully implementation of seamless |
| 00:35 | <abarth> | if you're looking to lower the activiation energy for implementors, you might want to focus on just the core behaviors |
| 00:36 | <Hixie> | is there an activation energy problem on this front? |
| 00:43 | <Hixie> | implementors - if you see anything on this that you want implemented, please do fill in the table or let me know: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest |
| 00:54 | <othermaciej> | Hixie: I'm surprised to learn that Dean Jackson works for Google |
| 00:54 | <othermaciej> | how did he manage that and get <dino⊙ac> as his email?!? |
| 00:56 | <othermaciej> | (fixed btw) |
| 01:00 | <Hixie> | othermaciej: oops, i should proof-read the table :-P |
| 01:26 | <nessy> | Hixie: I'm really happy about that new proposal for cue positioning! |
| 01:41 | <GPHemsley> | It doesn't make sense to set up a selector for credit card companies. |
| 01:41 | <GPHemsley> | There are too many and the names could change. |
| 01:48 | <GPHemsley> | I'm not sure that deleting wiki pages is the best course of action for things that are no longer applicable. |
| 01:50 | <smaug____> | What is FormData in http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest ? |
| 01:50 | <smaug____> | Something else than http://xhr.spec.whatwg.org/#interface-formdata ? |
| 01:51 | <smaug____> | I guess just additional features |
| 06:11 | <zcorpan> | Hixie: my recollection from the FOMS conference was that it's more OK to change the width than to change the position |
| 06:11 | <Hixie> | k |
| 06:11 | <zcorpan> | Hixie: so at x=50%, widht width=50%? |
| 06:11 | <Hixie> | does the proposal in the bug seem ok? |
| 06:11 | <zcorpan> | s/?// |
| 06:11 | <zcorpan> | i'll have a look |
| 06:12 | <heycam> | zcorpan, thanks for your scoped style test suggestions yesterday |
| 06:12 | <zcorpan> | heycam: np |
| 06:23 | <zcorpan> | Hixie: hmm. my recollection might have been backwards. a different case - align:middle position:0% size:50% - was expected to respect the width and change the position (or possibly have position 0% mean the anchor point is at 0% of the box) |
| 06:23 | <Hixie> | align:middle position:0% size:50% would presumably have text centered in a box covering 0% to 50% from the left, no? |
| 06:24 | <zcorpan> | yes, that's the expected result, but not the result of the current spec, iirc |
| 06:24 | <Hixie> | forget the current spec :-) |
| 06:24 | <Hixie> | look at the proposal in the bug from today |
| 06:24 | <zcorpan> | yeah, haven't got that far yet |
| 06:24 | <Hixie> | :-) |
| 06:24 | <zcorpan> | long bug is long |
| 06:25 | <Hixie> | 20037? |
| 06:25 | <Hixie> | oh yikes, it has lots of comments |
| 06:27 | <zcorpan> | i read a dup first to refresh my memory |
| 06:27 | <zcorpan> | (18501) |
| 06:29 | Hixie | hates the "reply" link in bugzilla |
| 06:29 | <Hixie> | in other news, why are facebook sending me updates about their policy when I DON'T EVEN HAVE AN ACCOUNT |
| 06:29 | <zcorpan> | align:right position:10% |
| 06:29 | <zcorpan> | should be right-aligned with the right edge 90% across from the left |
| 06:30 | <zcorpan> | Hixie: what's the reasoning for that one? |
| 06:30 | <Hixie> | what would you expect? |
| 06:31 | <zcorpan> | i think i'd expect the left edge be 10% from the left |
| 06:31 | <Hixie> | why? |
| 06:32 | <Hixie> | (i don't disagree, just curious if you have a reason) |
| 06:32 | <zcorpan> | because position should do the same thing regardless of alignment |
| 06:32 | <Hixie> | hm, not sure i agree that that should be an invariant |
| 06:33 | <Hixie> | one reason to design it the way that 0% starts at the alignment edge (though not a reason to expect align:right position:10% on the right) is that it means that align:right size:10% will be on the right, which people seem to expect |
| 06:33 | <Hixie> | (if we default position:0%) |
| 06:36 | <zcorpan> | position could have an 'auto' default that makes right-aligned cues by default have the right edge at 100%, or some such |
| 06:38 | <Hixie> | auto values are just a pain |
| 06:42 | <zcorpan> | Hixie: i thought what was considered confusing was that the different settings depend on each other. the new proposal still does that |
| 06:43 | <Hixie> | different people have different ideas of what is confusing |
| 06:43 | <Hixie> | but i don't really see how the values can't depend on each other |
| 06:43 | <Hixie> | at least, not if we want it to have a reasonable number of settings and not have to specify them all all the time |
| 06:47 | <zcorpan> | maybe we should have 'left' and 'right' settings instead of 'position' |
| 06:47 | <zcorpan> | both default to 0 |
| 06:47 | <zcorpan> | and work like absolute positioning in css |
| 06:48 | <zcorpan> | (or 'start' and 'end' if it should be flipped for rtl) |
| 07:00 | <Hixie> | zcorpan: i dunno, i think most people are more likely to think in terms of width than position |
| 07:05 | <zcorpan> | i've commented on the bug |
| 07:06 | <zcorpan> | Hixie: also see comment 0 in 18501 ("It seems to me that what authors needs the ability to specify is:") |
| 07:09 | <Hixie> | yeah i looked at all the dupes pretty carefully |
| 09:02 | <hsivonen> | can someone remind me how an HTTP client determines if a response entity body exists? |
| 09:05 | <hsivonen> | in particular, how can a client differentiate between zero-length response entity body and the absence of a response entity body? |
| 09:15 | <hsivonen> | https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#message.body suggests there's no other way than looking at the request method and response code |
| 09:16 | <hsivonen> | yay for not speccing what the client should do if a message body is present when it MUST NOT be present |
| 09:29 | <annevk> | Hixie: I think I need some more concrete details on the event retargeting stuff |
| 09:44 | <annevk> | Hixie: I added a proposal to the bug |
| 09:48 | <annevk> | hsivonen: dude, cannot expect anything else from a spec written by jreschke really |
| 09:48 | <annevk> | hsivonen: in rare cases you can convince mnot and then they have to play ball, but other than that it's riddles all the way down |
| 09:49 | <jgraham> | A riddle inside a mystery inside an engigma inside a RFC? |
| 09:49 | <jgraham> | *enigma |
| 09:50 | <annevk> | http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest is a great idea |
| 09:50 | <annevk> | jgraham: yeah, waiting for gsnedders to solve it |
| 09:59 | <annevk> | marcosc: feel free to update the wiki |
| 10:00 | <annevk> | marcosc: also, @WHATWG is not really an entity, it just shares info, I'm kinda hesitant to reply from it |
| 10:08 | <zcorpan> | the best part about @supports is that you get to repeat all your vendor-prefixed declarations once more. |
| 10:09 | <zcorpan> | now cue a vendor-prefixed impl of @supports and we're home |
| 10:10 | <Ms2ger> | fantasai++ |
| 10:12 | <kennyluck> | What happned? |
| 10:14 | <Ms2ger> | XKCD happened |
| 10:15 | <darobin> | odinho: https://w3c-test.org:444/ is now open for you to have all sorts of fun with |
| 10:15 | <MikeSmith> | darobin: so what did the problem turn out to be? |
| 10:15 | <MikeSmith> | or rather, the cause of the problem? |
| 10:15 | <darobin> | MikeSmith: it was just that port 444 was not open |
| 10:15 | <darobin> | it's what I thought, I just wanted to check that it was okay to open it before doing so |
| 10:16 | <MikeSmith> | I mean the OPTIONS problem |
| 10:16 | <darobin> | oh, that we haven't solved :( |
| 10:16 | <MikeSmith> | ah |
| 10:16 | <darobin> | I can't for the life of me figure out what's going on |
| 10:17 | <odinho> | darobin: Okay, can add those two tests back then, and maybe plan some moar fun later ;-) |
| 10:17 | <darobin> | mmmm, actually I have an idea |
| 10:18 | <annevk> | FWIW, I'm likely to remove 'If the "user:password" format in the userinfo production is not supported for the relevant <scheme> and url contains this format, throw a "SyntaxError" and terminate these steps.' from XHR soonish |
| 10:18 | <annevk> | oh, and I guess I'll make XHR depend on URL |
| 10:21 | <MikeSmith> | darobin: so what's different about the port 444 server? |
| 10:23 | <zcorpan> | i hope the only difference is the different port number :-) |
| 10:23 | <zcorpan> | (useful for origin tests) |
| 10:23 | <MikeSmith> | ah OK |
| 10:24 | MikeSmith | reads the logs from yesterday |
| 10:24 | <darobin> | MikeSmith: the 444 is just for CORS testing for SSL, odinho wanted it |
| 10:24 | <MikeSmith> | 了解 |
| 10:24 | <darobin> | it's a separate problem from OPTION |
| 10:24 | <MikeSmith> | ok |
| 10:25 | darobin | cries a little |
| 10:25 | <darobin> | I hate Apache |
| 10:32 | <zcorpan> | given a worker like this: postMessage(1); close(); postMessage(2); |
| 10:33 | <zcorpan> | how many messages should be received on the other end? |
| 10:33 | <darobin> | sigh, our version of Apache is too old to support trace-level logging... |
| 10:44 | <zcorpan> | i think the answer is 2 |
| 10:46 | <annevk> | zcorpan: depends on the queuing :) |
| 10:47 | <zcorpan> | annevk: can you elaborate? |
| 10:47 | <annevk> | zcorpan: I don't know how this part of workers work, but I assume these put all something on a queue of some kind |
| 10:48 | <annevk> | works* |
| 10:48 | <zcorpan> | if you don't know, you're not helping :-P |
| 10:51 | <annevk> | zcorpan: actually seems the answer is 0 |
| 10:52 | <zcorpan> | annevk: why? |
| 10:53 | <annevk> | I'm having a hard time finding the actual definition of postMessage, but if that queues tasks, and close() nukes all existing tasks and prevents further tasks to be queued, seems like 0 is the answer |
| 10:54 | <zcorpan> | the confusing part is that there are several event loops here |
| 10:54 | <zcorpan> | and neither close() nor postMessage() are clear on which they refer to |
| 10:54 | <annevk> | oh, postMessage() puts tasks on the other end |
| 10:54 | <zcorpan> | yes |
| 10:54 | <annevk> | then you're correct |
| 10:55 | <annevk> | but the spec could be a bit more explicit about task queues indeed |
| 10:55 | <annevk> | and also provide a forward reference to the actual postMessage method that is invoked |
| 10:55 | <zcorpan> | thanks. i'll file bugs |
| 10:56 | <annevk> | I was right though, depends on the queuing :p |
| 12:09 | <AryehGregor> | annevk, marcosc, https://www.w3.org/Bugs/Public/show_bug.cgi?id=12296 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=12220 |
| 12:12 | <annevk> | knew it |
| 12:15 | <hsivonen> | annevk: http://lists.w3.org/Archives/Public/www-archive/2011Dec/att-0021/encoding-labels.html contains at least one multibyte encoding |
| 12:16 | <hsivonen> | annevk: and it claims no one supports it |
| 12:16 | <hsivonen> | annevk: would the testing methodology have resulted in an indication of non-support when an encoding is, in fact, multibyte? |
| 12:16 | <annevk> | which one? |
| 12:17 | <hsivonen> | t.61-8bit |
| 12:17 | <hsivonen> | annevk: multibyte according to http://std.dkuug.dk/i18n/charmaps/T.61-8BIT |
| 12:19 | <annevk> | hsivonen: I suppose that could have happened, yes |
| 12:20 | <annevk> | hsivonen: though note that per http://wiki.whatwg.org/wiki/Web_Encodings Gecko is the only one to support that encoding |
| 12:20 | <annevk> | oh, IE might have support too under a different label |
| 12:42 | <annevk> | funny how this stuff works: http://lists.webkit.org/pipermail/webkit-dev/2012-January/019182.html |
| 12:42 | <annevk> | I'm pretty sure that group at Adobe is basically Vincent Hardy, who has been asking for this for a long time |
| 12:44 | <annevk> | he might even have done the original progress event spec in SVG, dunno |
| 12:44 | <annevk> | (which was intended for image downloads and such) |
| 13:45 | <annevk> | So I wanted to fix that URL bug in XHR, but I wonder if maybe the design in the URL spec should be tweaked a bit more |
| 13:46 | <annevk> | Instead of having a "fatal error flag" parsing would just return failure and URLUtils would not have an associated URL object |
| 13:51 | <annevk> | yup :) |
| 13:55 | <gsnedders> | jgraham: Waiting for me to solve what? |
| 14:04 | <darobin_> | jgraham: you probably want to chat with this guy https://twitter.com/graouts/status/271615076023287809 |
| 14:05 | <darobin> | (he's a friend and generally a good guy) |
| 14:30 | <darobin> | good catch odinho |
| 14:31 | <odinho> | darobin: Only generally? :P |
| 14:31 | <darobin> | is anyone ever more than generally ;-) |
| 15:14 | <jgraham> | darobin: You are right, I do |
| 15:15 | <darobin> | jgraham: if he doesn't show up on IRC and you'd like a way to ping him outside Twitter just ask |
| 15:15 | <darobin> | (if you have a Twitter account, I don't know it) |
| 15:16 | <jgraham> | (I have an unused twitter account) |
| 15:16 | <jgraham> | Also, I commented on github |
| 15:17 | <annevk> | fwiw, new URL can now sometimes fail |
| 15:17 | <zewt> | are there any ctors on the platform that do that? |
| 15:19 | <zewt> | (failing instead of being in an error state does seem to make more sense as an interface) |
| 15:27 | <annevk> | zewt: you mean like XMLHttpRequest? |
| 15:28 | <annevk> | zewt: or maybe like new Image() if the argument cannot be coerced to an integer? |
| 15:29 | <zewt> | when can xhr's ctor fail? (webidl dispatch doesn't count, that's before it runs) |
| 15:29 | <zewt> | (note i'm not objecting, just wondering if this is a new thing or not) |
| 15:29 | <zewt> | gah i accidentally loaded the w3's copy of xhr2 and hooooooly shit they fucked it up |
| 15:29 | <zewt> | NO TEST COVERAGE |
| 15:30 | <zewt> | my eyes are bleeding |
| 15:30 | <annevk> | oh wait, XHR doesn't fail, doh |
| 15:30 | <annevk> | open() fails |
| 15:31 | <zewt> | i find it fascinating that they removed all links to the real spec (used to be the ED link went to yours), yet "participate" still points here |
| 15:32 | <annevk> | I found it rather odd to be "former editor" despite having written all the text |
| 15:32 | <annevk> | I commented on that here http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0538.html but thus far nobody seems to care |
| 15:33 | <zewt> | it's also fascinating that it apparently takes three people to copy one person's stuff |
| 15:34 | <annevk> | finally found an example, Worker throws, for exactly the same reason (URL cannot be parsed) |
| 15:35 | <annevk> | Worker can also throw for undisclosed security reasons |
| 15:36 | <annevk> | EventSource too |
| 15:36 | <annevk> | WebSocket too |
| 15:40 | <zewt> | hmm |
| 15:41 | <zewt> | if new URL(url.href).href always round-trips, then in principle the ctor base argument could just be URLString, but I guess it doesn't matter |
| 15:42 | <annevk> | what is a URLString? |
| 15:43 | <zewt> | a will it blend |
| 15:43 | <zewt> | DOMString |
| 15:44 | <annevk> | I'm not sure I follow. I think the main remaining annoyance is changing protocol |
| 15:45 | <annevk> | I'm sort of wondering if setting protocol should only work as long as you don't change relativeness. |
| 15:45 | <annevk> | So if the current scheme is a relative scheme it can only be another relative scheme, and if the current scheme isn't, it can only be a non-relative scheme |
| 15:46 | <annevk> | that way you keep the invariants and don't need something weird like the "relative flag" |
| 16:05 | <annevk> | In other news, I'm hitting more cases that at some point need to be defined in "Fetch" |
| 16:20 | <odinho> | zewt: I think linking up tests to the spec page is a very nice idea. I hope it's the styling you're mostly worried about :-) |
| 16:20 | <annevk> | oh hey hallvors! |
| 16:20 | <annevk> | hallvors: so I'm planning on making another change to XHR |
| 16:20 | <annevk> | hallvors: currently it's either same-origin or cross-origin |
| 16:21 | <annevk> | hallvors: I think we should put some checks on cross-origin too, for either http/https scheme in the request URL |
| 16:21 | <annevk> | hallvors: and then have "otherwise" be a case where it's just a network error |
| 16:21 | <annevk> | hallvors: thinking about it more, I guess that's another thing that "Fetch" should handle |
| 16:42 | <annevk> | Hixie: should http://xhr.spec.whatwg.org/#dom-xmlhttprequest instead read "set document to the active document of the global object on which xhr's interface object is located"? |
| 16:42 | <annevk> | hallvors: ^^ |
| 16:54 | <annevk> | odinho: Velmont: you around? |
| 16:55 | <annevk> | odinho: Velmont: is the "userinfo" bit from http://fetch.spec.whatwg.org/#redirect-steps tested? I'm thinking it's bogus |
| 17:08 | <odinho> | annevk: There was some, but xhr tests are kinda broken. |
| 17:09 | <odinho> | Ah, fetch - not xhr :P Hm. They should be. |
| 17:10 | <annevk> | odinho: so you have Location: http://test:test⊙tc/ somewhere in there which is valid except for the test:test part? |
| 17:11 | <annevk> | hmm |
| 17:12 | <odinho> | No. They are not I have some started things lying on T server at Opera, but I never actually moved them anywhere because I hit some snags I think. Long time ago now. Never thought more about it :P |
| 17:13 | <odinho> | Just that small thing might be easy to add though. |
| 17:23 | <annevk> | well, I might want to kill it |
| 17:23 | <annevk> | so I'd prefer it if you don't :) |
| 17:25 | <odinho> | annevk: http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/redirect-userinfo.htm |
| 17:25 | <odinho> | ^_^ Opera implements it. |
| 17:25 | <odinho> | WebKit also passes. (if the test is correct though) |
| 17:26 | <odinho> | Firefox times out. |
| 17:26 | <odinho> | IE10 passes. |
| 17:27 | <annevk> | k |
| 17:27 | <odinho> | So pretty god coverage. 3/4 engines do it. |
| 17:27 | <odinho> | (with the above caveat) |
| 17:28 | <annevk> | ah yeah, redirects only work for simple requests, so yeah, that seems good then |
| 17:28 | <annevk> | Fetch is gonna be one complicated algorithm :/ |
| 17:28 | <annevk> | (though I guess that's also kinda fun) |
| 17:31 | <odinho> | (it doesn't really have to though ... but ohwell :P) |
| 17:32 | <annevk> | odinho: what doesn't have to? |
| 17:33 | <odinho> | Added some more tests to it. They're more to do with actual "what is userinfo" so I guess some of them are bad. Opera kills requests with //user:pass@ and //user:@ but not for //:pass@ //:@ or //@. Guess you can tell me how that stuff works from head? :] |
| 17:34 | <odinho> | annevk: preflighted requests _could_ also do redirects, I haven't seen any problems with it, as long as the preflight got a 200 OK back on the preflight request itself. -- So, possible, as in, it'd be possible to make the spec more complicated if you wanted :D I think. |
| 17:37 | <odinho> | "Userinfo is a username, optionally followed by a ":" and a password." -- so sounds sane. |
| 17:41 | <odinho> | Checked the referenced document in the fetch spec, rfc2616 -- but that was super unhelpful. You should just link to the real URL spec :-) |
| 17:44 | <annevk> | odinho: just @ doesn't mean anything |
| 17:44 | <annevk> | the others should fail |
| 17:44 | <annevk> | odinho: I will update it shortly |
| 17:46 | <annevk> | well, shortly, next time I touch fetch, dunno when that'll be |
| 17:51 | <odinho> | IE10 is green on all, opera green on all but :pass@ :@ @, chromium green on all but :@ @, firefox only green on :@ :pass@ |
| 17:53 | <odinho> | So noone does what it "should" be, then: green on all but @ |
| 19:22 | <zcorpan> | annevk: firefox fails to resolve data:test |
| 19:46 | <SimonSapin> | zcorpan: data:,test works, though |
| 19:46 | <SimonSapin> | or data:test, |
| 19:46 | <zcorpan> | SimonSapin: yes, they are legal |
| 19:53 | <annevk5> | Yeah I know, but they might change that. We could put data in the main URL parser, but that is not going to scale... |
| 19:56 | <SimonSapin> | it’s a completely different syntax, isn’t it? |
| 19:57 | <annevk5> | Well all URLs have their own syntax bits... |
| 19:57 | <annevk5> | mailto is not handled in any special way either |
| 19:58 | <SimonSapin> | in any case I would like to have the syntax well defined. Using email libs to parse the charset in data: is, well, not pretty https://github.com/Kozea/WeasyPrint/blob/master/weasyprint/urls.py#L188 |
| 19:59 | <annevk5> | data's syntax is defined, no? There might be some issues with the MIME type parsjng |
| 20:00 | <annevk5> | My plan is to define URL processing at some point, with per-scheme rules for schemes that need it and do not have it |
| 20:02 | <SimonSapin> | annevk5: it’s defined in http://tools.ietf.org/html/rfc2397#section-3 , but I’m a bit fuzzy on quoted strings etc. |
| 20:03 | <annevk5> | Everyone is |
| 20:05 | <annevk5> | I might look into a clearer definition at some point, but maybe I can convince you to write it? :) |
| 20:05 | <SimonSapin> | maybe :) |
| 20:08 | <SimonSapin> | annevk5: do you think it is possible to define to find a web-compatible subset of the syntax for data: headers that does not depend on all of MIME? |
| 20:09 | <annevk5> | You need MIME, but what exactly that is... |
| 20:11 | <SimonSapin> | I could very well be convince to help with this, but I’d need some guidance :) |
| 20:14 | <annevk5> | Tomorrow :( |
| 20:14 | <annevk5> | Euh, :) silly phone |
| 20:15 | <Ms2ger> | That's pretty phoney |
| 22:53 | <GPHemsley> | AFAICT, no browser detects OTF or TTC fonts |
| 22:55 | <GPHemsley> | Also, is there a way for me to turn off automatically downloading files in Safari? |
| 23:05 | <GPHemsley> | They don't seem to detect WOFF, either |
| 23:05 | <GPHemsley> | And Chrome has strange behavior when a file is sent with the WOFF mime type |
| 23:06 | <GPHemsley> | if the file has no file extension, it doesn't add one |
| 23:06 | <GPHemsley> | but if the file has a '.woff' file extension, it adds another one |
| 23:06 | <GPHemsley> | so it tries to get me to download and save the file as signature.woff.woff |
| 23:06 | <GPHemsley> | (versus just signature without it) |
| 23:08 | <Hixie> | i would expect browsers to only try to sniff for fonts in @font-face |
| 23:10 | <GPHemsley> | hmm |
| 23:10 | <GPHemsley> | TTF seems to be sniffed outside of @font-face, though |
| 23:10 | <Hixie> | funky |
| 23:10 | <Hixie> | how does that manifest? |
| 23:12 | <GPHemsley> | just as a binary download |
| 23:12 | <GPHemsley> | the others are treated as plaintext |
| 23:12 | <Hixie> | isn't that just detecting non-text? |
| 23:13 | <GPHemsley> | oh, good point |
| 23:13 | <Hixie> | what mime type are you sending it as? |
| 23:13 | <GPHemsley> | I forgot the TTF signature was binary |
| 23:13 | <Hixie> | (the other types aren't? funky!) |
| 23:13 | <GPHemsley> | nope, they're 'ttcf', 'OTTO', and 'wOFF' |
| 23:13 | <Hixie> | with no binary bytes in the first 512? |
| 23:13 | <GPHemsley> | TTF, on the other hand, is the binary representation of '1.0' |
| 23:14 | <GPHemsley> | the test files consist only of the signatures and nothing else |
| 23:14 | <GPHemsley> | (which is surprisingly successful in other areas) |
| 23:14 | <GPHemsley> | the signature for bitmaps, for example, is only 'BM" |
| 23:14 | <Hixie> | aah |
| 23:14 | <SimonSapin> | GPHemsley: what binary representation? |
| 23:14 | <GPHemsley> | SimonSapin: 00 01 00 00 |
| 23:15 | <GPHemsley> | (2 bytes for major, 2 bytes for minor) |
| 23:15 | <SimonSapin> | oh, ok |
| 23:15 | <GPHemsley> | anyway, back to the Thanksgiving festivities... |
| 23:17 | <zewt> | that doesn't sound like a very useful magic, heh |
| 23:18 | <zewt> | not unless you know in advance that you're looking for a font type, at least |