| 00:53 | <GPHemsley> | It strikes me that a lot of the proposals and/or criticisms around HTML involve trying to make it more XML-like. |
| 01:23 | <annevk> | GPHemsley: really? |
| 01:23 | <annevk> | GPHemsley: or what I mean is, where do you see that? |
| 01:24 | <annevk> | heycam: are you fixing Web IDL bugs again? |
| 01:24 | <GPHemsley> | annevk: It's not explicit. |
| 01:24 | <annevk> | heycam: wondering what your thoughts are on https://www.w3.org/Bugs/Public/show_bug.cgi?id=19646 |
| 01:25 | <heycam> | annevk, hey yeah I am. (I'll get back more into it next week.) |
| 01:25 | <heycam> | annevk, sorry bit busy atm, I'll take a look later |
| 01:25 | <annevk> | fair enough |
| 01:26 | <annevk> | heycam: there's a bunch of things actually in your queue, they're not actually that important, I just like to move past them :p |
| 01:26 | <annevk> | but I guess I should fix my own bugs, like username/password for URLs |
| 01:29 | <annevk> | We use "append" in specs quite a lot, any problems if I start using "prepend"? |
| 01:33 | <heycam> | yeah I'll get stuck in to them soon, sorry for the delay |
| 01:42 | <TabAtkins> | annevk: No, feel free to use prepend. I use it all the time. |
| 01:42 | <annevk> | putting stuff in front feels kinda like a hack :) |
| 01:42 | <annevk> | but yeah, I went with it |
| 01:42 | <TabAtkins> | Sometimes that's what you gotta do! |
| 01:43 | <annevk> | btw man, happy b-day! |
| 01:43 | <TabAtkins> | Yay! It's already the day after for you, though. |
| 01:44 | <divya> | wahh BIRTHDAY TIMES TabAtkins?! |
| 01:44 | <divya> | how old are you now? 14? |
| 01:44 | <divya> | :))))) |
| 01:44 | divya | runs |
| 01:44 | <divya> | HAPPY BUDDAYYYYY |
| 01:45 | <TabAtkins> | divya === jerk |
| 01:46 | <TabAtkins> | Anyway, 27 this year. |
| 01:46 | <divya> | :)))) |
| 01:46 | <divya> | TabAtkins: I can be because i am older than you! |
| 01:46 | <TabAtkins> | Yeah, you're like 50. |
| 01:46 | <divya> | :)))) YOU FOUND MY SEKRIT |
| 01:56 | <annevk> | GPHemsley: you should look into your git thingie |
| 01:56 | <annevk> | GPHemsley: the "Merge branch 'master' of github.com:whatwg/xref" should not be needed |
| 01:57 | <annevk> | GPHemsley: at least GitHub.app never does it when I push after you have pushed something |
| 01:59 | <divya> | anybody know of this canvas() as value for content prop http://trac.webkit.org/changeset/134100 |
| 01:59 | <divya> | TabAtkins: ^ |
| 02:00 | <divya> | or hober^ |
| 02:00 | <TabAtkins> | What about it? It's a webkit-specific more-limited version of element(). |
| 02:00 | <divya> | no i wonder if it was proposed anywhere |
| 02:00 | <TabAtkins> | No, because element() is a superset of its functionality. |
| 02:00 | <divya> | wanted to see context to how it came to be TabAtkins. i am intrigued. |
| 02:00 | <divya> | o ic. |
| 02:01 | <TabAtkins> | I dunno if it was inspired by -moz-element(), or vice versa, or if they were independent inventions at the same time, but they solve the same basic problem. |
| 02:02 | <TabAtkins> | Just element() can also take <img>, <video>, and other elements. |
| 02:02 | <divya> | well its not quite the same as per implementation at least. |
| 02:02 | <TabAtkins> | And, for SVG purposes, is morphing into a general way to refer to paint servers unambiguously. |
| 02:02 | <divya> | it has a getCSSCanvasContext and stuff |
| 02:02 | <TabAtkins> | Of course not, canvas() is simpler to implement, because it's exactly *one* of element()'s abilities. |
| 02:03 | <divya> | no i mean it is not gathering selectors to render is what i mean. |
| 02:03 | <divya> | which is what element() does. |
| 02:03 | <TabAtkins> | element() had, and will regain, a way to refer to an element without a selector. |
| 02:03 | <divya> | it seems to refer to a specific canvas context. |
| 02:03 | <divya> | o okay. |
| 02:03 | <TabAtkins> | So you can just create the canvas in script, never insert it, but use it as an image. |
| 02:03 | <divya> | right yeah thats what. |
| 02:04 | <divya> | that is what is happening here from test sample. |
| 02:20 | <kennyluck> | Happy b-day, TabAtkins! |
| 02:21 | <TabAtkins> | Thanks! |
| 03:43 | <Davstern15> | Sigh. |
| 03:43 | <Davstern15> | Can somebody figure out how to trim an image in JS in Canvas? |
| 03:47 | <Hixie> | Davstern15: how do you mean? |
| 03:49 | <Davstern15> | Basically, I have a Canvas and I want to turn it into a trimmed version where any whitespace outside of the rectangle with drawn stuff is removed. |
| 03:49 | <Davstern15> | That is, unknown stuff is drawn to it, and where alpha == 0, it's "blank". |
| 03:49 | <Davstern15> | I have been at this annoying problem for a long time now. |
| 03:49 | <Davstern15> | The only examples I've found are broken and/or nonsensical. |
| 03:50 | <Hixie> | just create a new canvas element of the right size, and drawImage() the part you want to keep into the new canvas |
| 03:51 | <zewt> | sounds like his question is how to determine the "right size" |
| 03:51 | <Davstern15> | Yes... |
| 03:51 | <Davstern15> | The coordinates. |
| 03:51 | <Davstern15> | x1, y1, x2, y2. |
| 03:51 | <Hixie> | ooh |
| 03:51 | <Davstern15> | And, preferably, packaged into an isolated function that I can just "plug and play", because I hate this particular problem. |
| 03:51 | <Hixie> | that's not a canvas question then :_) |
| 03:51 | <Hixie> | it's just a graphics question |
| 03:51 | Hixie | isn't a graphics person, sorry :-) |
| 03:52 | <Davstern15> | It's always "something else". |
| 03:52 | <zewt> | well, it could be a canvas question, it's just a question of whether "trimming away empty space" is a use case for canvas |
| 03:52 | <Davstern15> | You could join any channel and ask something on-topic and they'd twist it to be irrelevant. |
| 03:52 | <zewt> | (eg. photoshop image -> trim -> transparent pixels) |
| 03:53 | <Hixie> | Davstern15: i'm just saying i don't know the answer, you are welcome to ask here if you want |
| 03:53 | <Hixie> | Davstern15: we do sometimes have graphics people here |
| 03:53 | <Davstern15> | Isn't it more a "logic" question? |
| 03:54 | <Hixie> | Davstern15: however, you may be able to get an answer easier and quicker on a channel dedicated to graphics algorithms rather than one to do with the web specifically |
| 03:54 | <Davstern15> | The reason I ask here is I am hoping that somebody would have a function lying around to do this. |
| 03:54 | <zewt> | well, doing it algorithmically is trivial; grab the image data and do the work |
| 03:54 | <Davstern15> | Since this is done in Canvas context, it's quite special. |
| 03:55 | <Davstern15> | No pun intended with "Canvas context", BTW. |
| 03:55 | <Hixie> | if the question is "given a set of pixels, find the smallest subset rectangle that contains all pixels with a non-zero alpha" then it's an algorithm question, the answer would presumably be the same for any graphics system, not just canvas |
| 03:55 | <zewt> | might not be very efficient for large images but probably the only way for 2d canvases (speaking off the top of my head so don't read too deeply, heh) |
| 03:55 | <Hixie> | i mean i guess we could do a brute force approach, yeah |
| 03:55 | Hixie | tries |
| 03:55 | <Davstern15> | It doesn't need to be efficient. It's done in the beginning of the program. It's only done because Firefox sucks. |
| 03:55 | <Davstern15> | And cannot do a certain thing in realtime, wheras the other browsers can. |
| 03:55 | <zewt> | everything sucks, firefox just has the misfortune to be a subset of everything |
| 03:55 | <Davstern15> | So this whole thing is only for Firefox to run properly. |
| 03:56 | <Davstern15> | Hardware acceleration my shoes... |
| 03:57 | <zewt> | hardware acceleration for javascript pixel access is hard, possibly impossible |
| 03:57 | <zewt> | dunno if that's what you're complaining about, heh |
| 03:57 | <Davstern15> | No... |
| 03:57 | <Davstern15> | The reason this is done to begin with is that its drawing functions are so slowl. |
| 03:57 | <Davstern15> | -l |
| 03:58 | <zewt> | if you want hardware-accelerated image trimming, you probably need some clever webgl work |
| 03:58 | <Davstern15> | arc() = turtle speed @ Firefox. |
| 03:58 | <Davstern15> | WebGL Is worthless because IE doesn't support it. |
| 03:58 | <zewt> | itym ie is worthless because it doesn't support webgl |
| 03:58 | <Davstern15> | IE is the only browser that truly is fast at rendering 2D Canvas, so I love it because of that. |
| 03:58 | <Davstern15> | It has actual hardware acceleration as opposed to "pretend acceleration". |
| 04:07 | <Hixie> | Davstern15: ok |
| 04:07 | <Hixie> | Davstern15: here: |
| 04:08 | <Hixie> | one sec, goo.gl and bit.ly are being annoying |
| 04:09 | <zewt> | for a change of pace |
| 04:09 | <Hixie> | ok screw it |
| 04:09 | <Hixie> | Davstern15: go to http://software.hixie.ch/utilities/js/canvas/ |
| 04:09 | <Hixie> | Davstern15: and click the "Download" button |
| 04:10 | <Hixie> | (it won't download anything) |
| 04:10 | <Davstern15> | Thank you very much for the effort. I will review the code now. It looks logical at first glance. |
| 04:11 | <Hixie> | probably the most naive code of the year, but like i said, i'm no graphics person :-) |
| 04:14 | <Hixie> | hit download again, i made it more fun |
| 04:14 | <Hixie> | actually renders pretty fast on this machine, but it's stupidly overpowered |
| 04:15 | <Davstern15> | "naive" code? |
| 04:16 | <GPHemsley> | annevk: If I had to guess, I'd say GitHub.app probably automatically pulls at some point. But I'll look into it. |
| 04:16 | <Hixie> | Davstern15: brute-force |
| 04:16 | <Hixie> | Davstern15: for example, it checks all the pixels in the corner twice, once for the left and once for the top |
| 04:16 | <Hixie> | Davstern15: (for each corner) |
| 04:17 | <Hixie> | maybe checking the rows and columns at the same time would be more efficient (like, going in a spiral) |
| 04:17 | <Hixie> | that way you'd only need to check each pixel once |
| 04:17 | <Hixie> | anyway |
| 04:17 | <Hixie> | that's all Exercises Left To The Reader |
| 04:18 | <Davstern15> | Hixie: Sorry for being slow... I still have to do some unexpected things before I can sink my teeth into your nice code. |
| 04:19 | <Hixie> | no worries :-) |
| 04:19 | <Hixie> | anyway i hope it helps |
| 04:19 | <Hixie> | bbl |
| 04:20 | <GPHemsley> | Hixie: What is this code doing? Is the image supposed to keep moving? |
| 04:22 | <GPHemsley> | I mean, it looks like it's calculating the height of the image, but it keeps getting bigger again after it gets smaller... |
| 04:22 | <GPHemsley> | (And it hasn't stopped yet.) |
| 04:23 | <GPHemsley> | Hixie: Incidentally, former Mozillians on Twitter seem to love your canvas on workers proposal. |
| 04:41 | <Hixie> | GPHemsley: that console just runs the script over and over and over |
| 04:41 | <Hixie> | GPHemsley: each iteration, it draws a picture, then finds the bounding box |
| 04:46 | <Davstern15> | Hixie: I am going insane here... about a small detail. |
| 04:46 | <Hixie> | yessir |
| 04:47 | <Davstern15> | For some reason, tmpContext.drawImage(targetContext, 0, 0); is a "TypeMismatchError" |
| 04:47 | <Hixie> | until today (and therefore, not implemented by any browsers yet) you couldn't drawImage() a rendering context |
| 04:47 | <Hixie> | just replace targetContext with the canvas element |
| 04:47 | <Davstern15> | But... then how could I do that in my previous stuff? |
| 04:48 | <Davstern15> | And why "today"? |
| 04:48 | <Hixie> | i checked in a big change to the canvas spec today that, amongst many other things, lets you pass a rendering context to drawImage() |
| 04:48 | <Hixie> | but none of the browsers support that yet, so i doubt that's worked before |
| 04:48 | <Davstern15> | That is one of the more bizarre coincidences this month for me. |
| 04:48 | <Hixie> | you probably passed a canvas, which is the only way that used to work :-) |
| 04:48 | <Hixie> | heh |
| 04:48 | <Davstern15> | I now must check this. |
| 04:49 | <Hixie> | it's what GPHemsley was talking about above :-) |
| 04:49 | <Hixie> | GPHemsley: speaking of which, which tweets? |
| 04:49 | <Hixie> | Davstern15: http://html5.org/tools/web-apps-tracker?from=7508&to=7509 |
| 04:49 | <Davstern15> | Yes, you are right. I was sending a canvas and not the context in the previous stuff. |
| 04:49 | <Davstern15> | Not sure why they would decide to change that, though. |
| 04:50 | <Hixie> | they? |
| 04:50 | <GPHemsley> | Hixie: https://twitter.com/jeresig/status/269653285168902145 https://twitter.com/dalmaer/status/269654501441556480 |
| 04:51 | <Hixie> | GPHemsley: awesome, someone finally liked something i specced :-D |
| 04:51 | <Hixie> | it's been a whiel :-) |
| 04:52 | <GPHemsley> | :) |
| 04:54 | <Davstern15> | "Unexpected call to method or property access. " |
| 04:54 | <Davstern15> | Sigh. |
| 04:55 | <Davstern15> | I don't get what the hell it is talking about. |
| 04:55 | <Davstern15> | Hixie: Yes. They. I guess... you? :) |
| 04:55 | <Davstern15> | It is ambiguous what "checked" meant in that case. |
| 04:55 | <Davstern15> | Maybe you meant that you passed that into the standard. |
| 04:57 | <Davstern15> | Please forget my last quote. |
| 04:58 | <Davstern15> | "Unexpected call to method or property access." was due to a stupid error. |
| 04:58 | <Davstern15> | Getting IndexSizeErrorsm though. |
| 04:58 | <Davstern15> | *, |
| 05:08 | <Davstern15> | If I draw stuff to a context, do I have to do something special for that to apply to its associated canvas? |
| 05:09 | <Davstern15> | Hixie: http://pastebin.com/raw.php?i=2XASh10q |
| 05:10 | <Davstern15> | It seems like it ignores everything I draw. |
| 05:17 | <Davstern15> | Hixie: Any idea at all? |
| 05:19 | <Hixie> | sorry, was off watching tv |
| 05:20 | <Hixie> | that code looks fine to me |
| 05:20 | <Hixie> | returns a canvas with a rectangle on it |
| 05:20 | <Davstern15> | Well... |
| 05:20 | <Davstern15> | It doesn't seem to be... |
| 05:20 | <Hixie> | (well, returns a 32x32 square canvas of a solid colour, really) |
| 05:20 | <Hixie> | i posit the problem is elsewhere :-) |
| 05:21 | <Hixie> | re why the spec changed, it was part of a larger change enabling the use of canvas in workers |
| 05:21 | <Davstern15> | Wow. You are right. |
| 05:21 | <Davstern15> | I can't believe I make so many errors. |
| 05:21 | <Davstern15> | Stupid, stupid errors. |
| 05:43 | <GPHemsley> | Hixie, annevk: I'm curious what your thoughts are on http://trac.tools.ietf.org/wg/websec/trac/ticket/22 |
| 05:44 | <GPHemsley> | Davstern15: I think you're a bit hard on yourself (and others, perhaps). Making errors is how you learn. |
| 05:45 | <Davstern15> | Well, I am getting stuck constantly with these things and inch forward so slowly... |
| 05:45 | <Davstern15> | The translate() thing makes no sense either. |
| 05:45 | <Davstern15> | testContext.scale(2, 1); = Oval but cuts off. testContext.scale(4, 1); = Nothing is drawn. |
| 05:54 | <Davstern15> | "#¤%&/() |
| 05:54 | <Davstern15> | WHAT? |
| 05:54 | <Davstern15> | The MDN does a horrible job at explaining anything. |
| 05:55 | <Davstern15> | All I want is to draw an oval. |
| 05:55 | <Davstern15> | Why doesn't it let me draw an oval? |
| 06:02 | <GPHemsley> | hmm... it appears I broke the IRC log search, because it takes the search query as a raw regexp |
| 06:04 | <Davstern15> | This kind of stress can't be good. |
| 06:05 | <Davstern15> | http://jsfiddle.net/xLxM5/ <-- Okay, please tell me why this doesn't draw an arc at all. |
| 06:05 | <Davstern15> | I am trying to make a minimal example of what the problem is. |
| 06:05 | <Davstern15> | But now it won't even draw an arch without any special stuff. |
| 06:28 | <GPHemsley> | latenight bugmail ftw |
| 06:31 | <Davstern15> | Helping Davstern15 "ftw". |
| 06:31 | <Davstern15> | Looking at Davstern15's jsfiddle and figuring it out and reporting the issues ftw. |
| 06:32 | <Davstern15> | Hixie: BTW... I am still very grateful for your help earlier, but there is a piece missing from the puzzle. |
| 06:36 | <Davstern15> | Somebody helped me already. So no need. |
| 09:14 | <Ms2ger> | Oh, yay, drawImage gained steps |
| 14:29 | <Davstern15> | Can you somehow set the amount of anti-aliasing for text drawn in a Canvas? Like you can in Flash? |
| 15:15 | <annevk> | GPHemsley: charset sniffing is done after you know the type of content so it seems that's a separate layer tied to sniffed/actual type |
| 15:15 | <annevk> | GPHemsley: extracting charset from a content-type header however may be part of your document I suppose |
| 15:16 | <annevk> | GPHemsley: e.g. a <script> pointing to something labeled with text/html;charset=windows-1253 |
| 15:23 | <annevk> | so the username/password stuff is slightly buggy |
| 15:24 | <annevk> | I need to escape / \ ? # on setting too, and also : for username |
| 15:30 | <annevk> | matjas: please implement the implementation status thingie in a somewhat generic way so we can reuse it :-) |
| 15:34 | <annevk> | Hixie: you have a stray BitmapImage in the spec |
| 15:34 | <annevk> | Hixie: actually you have that twice |
| 16:19 | <GPHemsley> | annevk, Hixie: See also page 10 of http://tools.ietf.org/agenda/82/slides/websec-2.pdf |
| 16:20 | <GPHemsley> | annevk: In terms of "sniffing", rather than just parsing the Content-Type header, isn't charset determination done elsewhere? Encoding, maybe? |
| 16:20 | <GPHemsley> | Reading the charset parameter of the Content-Type header is trivial, I think; I'm not sure that's what the issue was. |
| 16:26 | <GPHemsley> | TIL that LF-only linebreaks in text/* documents is a violation of the spec |
| 16:27 | <GPHemsley> | (RFC 2046) |
| 16:30 | <GPHemsley> | Also: "The rules |
| 16:30 | <GPHemsley> | regarding line breaks detailed in the previous section must also be |
| 16:30 | <GPHemsley> | observed -- a character set whose definition does not conform to |
| 16:30 | <GPHemsley> | these rules cannot be used in a MIME "text" subtype." |
| 16:35 | <GPHemsley> | " Unrecognized subtypes of "text" should be treated as subtype "plain" |
| 16:35 | <GPHemsley> | as long as the MIME implementation knows how to handle the charset. |
| 16:35 | <GPHemsley> | Unrecognized subtypes which also specify an unrecognized charset |
| 16:35 | <GPHemsley> | should be treated as "application/octet- stream". |
| 16:35 | <GPHemsley> | " |
| 16:35 | <GPHemsley> | hmm |
| 16:41 | <annevk> | GPHemsley: no that issue was Larry thinking all the sniffing should be done in MIME sniff |
| 16:42 | <annevk> | GPHemsley: which I disagree with, that's a format matter |
| 16:42 | <GPHemsley> | ok |
| 16:42 | <GPHemsley> | so what part should I worry about? |
| 16:42 | <annevk> | GPHemsley: maybe parsing Content-Type |
| 16:42 | <GPHemsley> | including all of its parameters? |
| 16:43 | <annevk> | GPHemsley: yeah |
| 16:43 | <GPHemsley> | (not just the ones we know about) |
| 16:43 | <GPHemsley> | ok |
| 16:44 | <annevk> | GPHemsley: the stuff I mentioned earlier, whether "Content-Type:text/html;" means text/html or undefined |
| 16:44 | <annevk> | GPHemsley: I guess the same would go for "...:text/html;charset=utf-8;" |
| 16:44 | <GPHemsley> | right |
| 16:45 | <annevk> | pretty sure HTTP is just dead wrong there |
| 16:45 | <GPHemsley> | I think extraneous spaces and semicolons should be fine in the values |
| 16:45 | <annevk> | not sure whether they fixed that for HTTPbis, I believe I did raise it at one point on their list |
| 16:45 | <GPHemsley> | but I'm not sure about the separator between header name and header value |
| 16:46 | <annevk> | well that's a different level, ideally |
| 16:46 | <GPHemsley> | OK |
| 16:46 | <GPHemsley> | so, assuming that the header itself is formatted correctly |
| 16:46 | <GPHemsley> | as far as HTTP is concerned |
| 16:46 | <GPHemsley> | generically |
| 16:47 | <GPHemsley> | now... does SMTP use the same format as HTTP for headers like this? |
| 16:52 | <GPHemsley> | annevk: Do you suppose I should look specifically for certain parameters (like charset) or just treat them all generically and let downstream figure it out? |
| 16:52 | <annevk> | GPHemsley: I think the parsing should be generic |
| 16:53 | <annevk> | GPHemsley: you might want to have a shorthand for certain things though |
| 16:54 | <annevk> | like "give me the value of charset" (and here you need to take into account there could be multiple parameters named charset), or give me the encoding from charset (here you need to use "get an encoding" from the Encoding Standard) |
| 16:57 | <GPHemsley> | right... although I don't think the current version of the spec has any use for those calls |
| 16:57 | <GPHemsley> | oh |
| 16:57 | <GPHemsley> | I see you what you mean |
| 16:57 | <GPHemsley> | wouldn't it make sense to combine the two? |
| 16:58 | <GPHemsley> | as in, mimesniff handles the logic of turning a charset parameter into an encoding |
| 17:00 | <annevk> | yeah maybe |
| 17:00 | <annevk> | in that case you'd just use the algorithm from the Encoding Standard |
| 17:01 | <annevk> | I suppose MIME sniffing might be the right layer to address this |
| 17:01 | <annevk> | mimesniff tells you the MIME type and the encoding specified at the encapsulation level (e.g. HTTP) |
| 17:02 | <annevk> | and then it dispatches to the format layer (based on MIME type) which takes the encoding into account |
| 17:47 | <Davstern15> | Can you somehow set the amount of anti-aliasing for text drawn in a Canvas? Like you can in Flash? |
| 19:44 | <zewt> | javascript "compression" needs to die a flaming death |
| 19:49 | <Davstern15> | zewt: What do you mean? |
| 19:49 | <zewt> | well, shooting it into the sun would be preferable, but a volcano would suffice |
| 19:50 | <Davstern15> | What is it? |
| 19:50 | <zewt> | removing whitespace from javascript and other nonsense |
| 19:52 | <Davstern15> | Obscurification. |
| 19:52 | <Davstern15> | Compilation. |
| 19:52 | <Davstern15> | I find it to be a necessity. |
| 19:53 | <zewt> | that's an odd way of saying "complete nonsense" |
| 20:27 | <annevk> | MikeSmith: care to address https://www.w3.org/Bugs/Public/show_bug.cgi?id=19993 ? |
| 20:27 | <annevk> | MikeSmith: I guess I can do it myself |
| 20:34 | <annevk> | fixed |
| 20:35 | <annevk> | Hixie: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html |
| 20:36 | <annevk> | Hixie: kinda interesting approach, it's at least acknowledging the copy |
| 21:05 | <annevk> | GPHemsley: http://stackoverflow.com/questions/2871655/proper-mime-type-for-fonts might be of interest |
| 21:06 | <annevk> | GPHemsley: in general though I'm not sure why we need a MIME type here |
| 21:06 | <annevk> | GPHemsley: MIME types are just identifiers for formats after all, you might as well point straight to the format |
| 21:09 | <Ms2ger> | TabAtkins, happy (birth + 1)day |
| 21:26 | <SimonSapin> | TabAtkins: is it enough to escape just "<" ? |
| 21:29 | <annevk> | matjas: so for http://url.spec.whatwg.org/ you get the new icon? |
| 21:30 | <annevk> | SimonSapin: you don't need to escape > |
| 21:30 | <annevk> | SimonSapin: in HTML anyway |
| 21:30 | <annevk> | not needed in most of XML either |
| 21:30 | <Velmont> | Ms2ger: You could do that for a full year :D |
| 21:33 | <SimonSapin> | annevk: this is for generated SVG: https://github.com/tabatkins/railroad-diagrams/blob/89b7679ae2282207cb42f353f44fbdd4f013411d/railroad-diagrams.js#L71 |
| 21:34 | <SimonSapin> | although it is often inline SVG inside HTML |
| 21:34 | <annevk> | SimonSapin: seems safer to construct a Text node |
| 21:35 | <annevk> | SimonSapin: hmm, is the input constrained? |
| 21:36 | <annevk> | SimonSapin: e.g. this doesn't seem to cater for & |
| 21:36 | <SimonSapin> | annevk: the function above does that, this is to get a string. I guess it could be useful in a non-browser environment |
| 21:36 | <SimonSapin> | Tab just fixed it: https://github.com/tabatkins/railroad-diagrams/commit/96ce88eb51 |
| 21:37 | <SimonSapin> | unconstrained input, at least for text |
| 21:38 | <annevk> | but I guess it's your own input |
| 21:40 | <SimonSapin> | it’s a lib that could be useful to other people |
| 21:42 | <SimonSapin> | and the same input should work with both toSVG (assigning to element.textContents) and toString (appending strings, without a DOM) |
| 21:50 | <annevk> | yeah, I'm thinking of using it for URLs at some point |
| 21:51 | <SimonSapin> | cool |
| 21:54 | <SimonSapin> | annevk: you can either keep just the JS source and have the client regenerate the SVG every time the page is loaded (as in the example page) or copy the SVG output into your document (as in css3-syntax) |
| 21:54 | <SimonSapin> | the latter is probably "safer" in terms of JS compat |
| 21:55 | <annevk> | yeah, I suppose I'll do the latter once we've decided on the syntax :) |
| 21:55 | <SimonSapin> | the URL syntax? |
| 21:56 | <annevk> | yeah |
| 22:13 | <annevk> | fixed the username/password bug |
| 22:26 | <GPHemsley> | annevk: Yeah, I've seen that. I think having an authoritative MIME type is important. No need to throw the baby out with the bathwater. |
| 22:28 | <GPHemsley> | I still think it'd be appropriate to create a 'font' type |
| 22:28 | <GPHemsley> | especially given the existence of e.g. 'font/opentype' |
| 22:28 | <GPHemsley> | hsivonen doesn't seem to agree, though |
| 22:31 | <GPHemsley> | If not, then 'application/font-(ttf|otf)' or 'application/font-(truetype|opentype)' |
| 22:31 | <GPHemsley> | (The key being that they start with 'application/font-') |
| 22:31 | <annevk> | throw what baby out? |
| 22:32 | <GPHemsley> | MIME types |
| 22:33 | <annevk> | not really sure what the benefit of a MIME type would be |
| 22:34 | <GPHemsley> | at all, ever? |
| 22:34 | <annevk> | maybe in the context of viewing the file directly? |
| 22:35 | <GPHemsley> | sniffing should be a backup plan, ideally |
| 22:35 | <annevk> | nah, it's too hard to deploy MIME types |
| 22:35 | <annevk> | WebVTT and cache manifests moved to sniffing too, fortunately both have a good signature |
| 22:36 | <GPHemsley> | what makes MIME types any harder to deploy than sniffing? |
| 22:38 | <annevk> | setting a MIME type on a server is hard, letting the user agent figure it out by resource inspection is easier |
| 22:38 | <annevk> | (far easier, in fact) |
| 22:38 | <annevk> | I was surprised by this too, but lots of developers don't have access to .htaccess, or don't know how to use it, etc. |
| 22:39 | <annevk> | and it's just a pain, see the emails from foolip with regards to media sniffing |
| 22:42 | <GPHemsley> | where? |
| 22:42 | <zewt> | also, so long as browsers do sniffing (in any particular domain), lots and lots of people will ignore them and not set them, which means nobody can ever actually depend on or require them--which limits their usefulness |
| 22:43 | <GPHemsley> | vicious cycle |
| 22:43 | <zewt> | just the usual web issues, heh |
| 22:44 | <annevk> | GPHemsley: whatwg list |
| 22:44 | <GPHemsley> | then perhaps we should be keeping a registry of signatures? |
| 22:44 | <GPHemsley> | (which we sort of already are) |
| 22:45 | <GPHemsley> | (and the Just Solve the File Format Problem people are sort of, too) |
| 22:45 | <GPHemsley> | (plus whatever IANA has) |
| 22:45 | <GPHemsley> | annevk: Approximate date? |
| 22:45 | <annevk> | oh dunno, like a year ago? |
| 22:45 | <zewt> | in the case of fonts, there's already at least "application/x-font-ttf"; i definitely would not add another MIME type to the mix that means the same thing |
| 22:46 | <annevk> | GPHemsley: well yeah, MIME sniff is that registry :-) |
| 22:46 | <annevk> | zewt: is that for truetype or opentype? |
| 22:46 | <GPHemsley> | annevk: There's a bazillion file formats. If we stored them all in this one document, it'd be way too long. |
| 22:46 | <zewt> | not for the sake of "prettiness" eg. being able to say "all font mime types look like font/foo"; there's just not much gain there, and a definite (and IMO significant) cost to adding more competing mime types |
| 22:47 | <zewt> | annevk: it's what nginx defaults to for *.ttf, at least |
| 22:47 | <annevk> | GPHemsley: not all need to be identified via sniffing |
| 22:47 | <zewt> | i mean, filenames matching *.ttf |
| 22:47 | <zewt> | oh wait, i might have added that one, heh--can't say how much research I might have done first (though I definitely didn't just make it up) |
| 22:47 | <GPHemsley> | annevk: Was it related to WebVTT or more in general? |
| 22:47 | <zewt> | guessing nothing actually cares, though |
| 22:48 | <annevk> | GPHemsley: that was more general, about sniffing for <video>/<source> resources |
| 22:48 | <GPHemsley> | zewt: I'm told there was registration in process for these fonts |
| 22:48 | <annevk> | zewt: application/x-font-ttf is listed on Wikipedia as most popular for TrueType |
| 22:48 | <GPHemsley> | zewt: http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Apr/0005.html |
| 22:48 | <zewt> | annevk: yeah, google says ~150k results, so it's not uncommon at least |
| 22:48 | <GPHemsley> | Not sure the status, though |
| 22:49 | <zewt> | GPHemsley: that's a lump of nonsense, at least at first glance |
| 22:49 | <GPHemsley> | good to know |
| 22:49 | <zewt> | if everyone's using "application/x-font-ttf", then just keep using application/x-font-ttf, at least it's consistent and on the web that matters more than most things |
| 22:50 | <zewt> | (of course, MIME types weren't conceived for the web, and it may be that the mime type registry is not actually appropriate for the web, or even web compatible) |
| 22:50 | <annevk> | GPHemsley: they can register all they want, but as long as implementations sniff I'm not sure how it matters, what the observable effect is going to be |
| 22:51 | <annevk> | GPHemsley: if there's no observable effect, it's like typing <img/> rather than <img>, something to appease the MIME type gods who really are irrelevant when it comes to fonts, just like / in <img> is irrelevant when it comes to HTML |
| 22:51 | <zewt> | annevk: probably not the "observable effect" you're referring to, but the main observable effect would be to make the MIME types used for fonts less reliable (probably forever) |
| 22:52 | <GPHemsley> | I just want to make sure I get the most common, and I don't know what they are |
| 22:52 | <GPHemsley> | there are two compartments in my head for this |
| 22:52 | <annevk> | zewt: so did you not like aligning encoders on the &#...; behavior? |
| 22:52 | <zewt> | (of course, since lots of fonts on the web are probably served as octet-stream or even text/plain, it's not like it's taking something consistent and making it not, so it probably just doesn't matter) |
| 22:52 | <GPHemsley> | one is the Just Work™ one, and the other is the Make It Nice™ one |
| 22:52 | <zewt> | annevk: not familiar with it |
| 22:52 | <zewt> | or don't recall off-hand anyway |
| 22:53 | <zewt> | GPHemsley: the web needs to be very heavily biased towards the former :) |
| 22:53 | <annevk> | zewt: because if we're going to have this URLQuery API, aligning URLs and <form> submission with respect to unencodable code points makes a lot of sense to me |
| 22:53 | <annevk> | now URLs use ? and <form> uses &#...; |
| 22:53 | <GPHemsley> | zewt: Yeah, but if we can skew towards Make It Nice™ without losing Just Work™, we should, IMO |
| 22:53 | <annevk> | but WebKit uses &#...; in URLs too |
| 22:54 | <GPHemsley> | zewt: Not that I'm saying we can in this case. |
| 22:54 | <GPHemsley> | (That remains to be seen.) |
| 22:54 | <annevk> | GPHemsley: I don't really see how MIME types make things nice if they're just ignored |
| 22:54 | <zewt> | GPHemsley: and i also think it's less "nice" to have two (or N+1) mime types in use for a file type than one, more so than the gain of the particular strings of text being pretty |
| 22:54 | <annevk> | GPHemsley: seems like a waste of bytes |
| 22:54 | <annevk> | GPHemsley: and potential for error |
| 22:55 | <zewt> | the key thing to remember is that (for example) application/x-font-ttf will *never go away*--it might be different if that wasn't the case, but that's the web |
| 22:55 | <GPHemsley> | any waste of bytes or N+1 is sacrificing Just Work™ |
| 22:55 | <GPHemsley> | so I'm not arguing for that |
| 22:56 | <GPHemsley> | zewt: The issue here, basically, is whether we have 0. If we don't, then we have no choice but to Just Work™. But if we do, then we should try for Make It Nice™. |
| 22:56 | <GPHemsley> | if application/x-font-ttf is the one that everyone has already basically standardized on, then fine |
| 22:57 | <GPHemsley> | what about the others? |
| 22:57 | <zewt> | not something i can answer |
| 22:59 | <zewt> | is this something that actually bears on the web? for example, are there any browsers that refuse to load a font if the MIME type isn't x-font-ttf or something else? |
| 22:59 | <zewt> | (i don't know the answer--I don't know if I set the above case because something wasn't working, or if i was just being pedantic with my HTTP headers) |
| 23:00 | <annevk> | browsers ignore MIME types for fonts |
| 23:00 | <annevk> | at least when I looked at it |
| 23:00 | <zewt> | i assume that they'll never change that, then, since it would break tons of sites |
| 23:01 | <zewt> | (i suppose there are ways they could--sniffing, again--but I don't know why they would) |
| 23:02 | <annevk> | TIL the person who registered all the URI schemes is on the IAB http://research.microsoft.com/en-us/um/people/dthaler/ |
| 23:03 | <annevk> | (all the URI schemes listed on Wikipedia) |
| 23:10 | <annevk> | kinda weird that a modern RFC like http://tools.ietf.org/html/rfc6055 still talks about ISO-2022-JP is if it would be used at the system level |
| 23:12 | <zewt> | i wonder if japan is still fighting tooth and nail against unicode, heh |
| 23:12 | <zewt> | not that japan is a single consciousness or anything |
| 23:14 | <annevk> | http://tools.ietf.org/html/rfc6055#section-3 is interesting, I hadn't considered that even "." could be a valid part of a label |
| 23:15 | <annevk> | although using a "." might require a bunch of custom software |