| 00:08 | <Hixie> | heycam: can i typedef a union type? |
| 00:08 | <heycam> | Hixie, yep! |
| 00:08 | <Hixie> | cool |
| 00:08 | <Hixie> | typedef NewType (A or B); ? |
| 00:08 | <heycam> | other way around |
| 00:08 | <Hixie> | oh ok |
| 00:12 | <Moo^_^> | is it defined how dtawImage() should behave with color spaces, gamme information and such? |
| 00:12 | <Moo^_^> | http://stackoverflow.com/questions/13394276/safari-ignores-colorspace-of-images-in-canvas |
| 00:13 | <Hixie> | yes |
| 00:13 | <Hixie> | see the spec :-) |
| 00:13 | <Hixie> | search for "color space" |
| 00:14 | <Hixie> | there's a section called "color spaces and color correction" |
| 00:14 | <Hixie> | http://whatwg.org/html |
| 00:14 | <Moo^_^> | Hixie: it applies for <canvas> too? |
| 00:15 | <Moo^_^> | ah |
| 00:15 | <Moo^_^> | thx |
| 00:15 | <Moo^_^> | it is canvas spec |
| 00:15 | <Hixie> | right |
| 00:36 | <annevk> | did anyone else get a "[whatwg] Proposal: implement a <usescookies> tag." email? |
| 00:36 | <Hixie> | i didn't |
| 00:36 | <annevk> | it's from "whatwg-owner⊙lwo" |
| 00:37 | <annevk> | which seems dubious |
| 00:37 | <Hixie> | oh maybe i block that |
| 00:37 | <Hixie> | (since i get a _lot_ of mail from that address) |
| 00:37 | <annevk> | and if it's to whatwg⊙wo that list must be on the bcc |
| 00:38 | <annevk> | but it seems like a legitimate email, albeit a kind of silly proposal |
| 00:38 | <zewt> | heh, not as silly as the idiotic cookie law |
| 00:41 | <TabAtkins> | Yes, I got it. |
| 00:41 | <TabAtkins> | Was a dumb email. |
| 00:43 | <annevk> | dbaron: if you want window.CSS.supports() in http://dev.w3.org/csswg/css3-conditional/#the-css-interface you need to put "static" between "boolean" and "supports" |
| 00:43 | <annevk> | dbaron: because now you'd need to get an instance of the CSS object first which I don't think is what is intended |
| 00:44 | <dbaron> | annevk, hmmm, Tab wrote that part |
| 00:44 | <annevk> | TabAtkins: ^^ |
| 00:45 | <dbaron> | annevk, and you really want "boolean static supports" rather than "static boolean supports" (which would be the C++ way)? |
| 00:45 | <annevk> | dbaron: yeah, sorry |
| 00:46 | <annevk> | dbaron: http://dev.w3.org/2006/webapi/WebIDL/#idl-static-attributes-and-operations fwiw |
| 00:46 | <dbaron> | annevk, so "static boolean supports"? |
| 00:46 | <annevk> | yup |
| 00:46 | <TabAtkins> | Ah yeah, makes sense. |
| 00:47 | <dbaron> | is there a way to say that an interface exists only to have static methods and can't have instances? |
| 00:47 | <annevk> | dbaron: that's implied |
| 00:47 | <TabAtkins> | By what? |
| 00:47 | <annevk> | but Alex Russell might not like you |
| 00:48 | <annevk> | TabAtkins: by not having a constructor and not having anything that returns the interface |
| 00:48 | <TabAtkins> | Nah, it's clear that CSS is a namespace object only. |
| 00:48 | <TabAtkins> | annevk: I think dbaron is hoping for something that avoids the hazard of accidentally adding non-static attributes in the future. |
| 00:49 | <Hixie> | add <!-- FOR THE LOVE OF KITTENS DON'T ADD NON-STATIC ATTRIBUTES --> to the source of the spec |
| 00:50 | <TabAtkins> | Hixie: Doesn't help partial interfaces in other specs. |
| 00:50 | <annevk> | TabAtkins: it seems if you define a partial interface like that and there's nothing that returns a CSS object someone will point that out and it'll get fixed |
| 00:51 | <dbaron> | so heycam and I have been discussing this IRL |
| 00:51 | <TabAtkins> | Sure, but if your WebIDL-based code generator knows ahead of time that the interface mustn't produce instances, and thus must be static-only, seems like a win. |
| 00:52 | <dbaron> | one thing he said is that if any future extensions to CSS might have window-specific information rather than being purely global |
| 00:52 | <Hixie> | nothing stops other spec writers doing whatever they want including "ignore the other spec's statement that says this is wrong..." |
| 00:52 | <dbaron> | then he'd think it would be better to have a CSS object (that's some other interface, I presume) than have a CSS interface |
| 00:52 | <dbaron> | do we think we'll never want anything on CSS that's window-specific? |
| 00:53 | <dbaron> | anyway, I'll add the static unless TabAtkins has already |
| 00:53 | <Hixie> | wouldn't such things just go on Screen? |
| 00:53 | <annevk> | seems like you do want that, but given that interface objects already have a relationship with the Window I'm not sure it's problematic |
| 00:53 | <TabAtkins> | dbaron: Maybe. But what annevk said. |
| 00:53 | <TabAtkins> | A CSS object living in an attribute on Window is identical to just defining a CSS interface. |
| 00:57 | <dbaron> | annevk, anyway, fixed |
| 00:57 | <zewt> | fg |
| 00:57 | <zewt> | ... hi |
| 00:57 | <dbaron> | annevk, and I alphabetized your name under "v" in the Acknowledgements; hoping that's correct |
| 00:57 | <annevk> | A or K, sorry |
| 00:57 | <annevk> | now if I was from Sweden I believe it would be v |
| 00:57 | <zewt> | my mind will never really fully intuit multiple monitors; hard wired to "looking at a window && window is fullscreen == window is focused" |
| 00:58 | <annevk> | and US probably too |
| 00:58 | <TabAtkins> | zewt: Make sure you have focus-follows-mouse. It at least makes things easier. |
| 00:58 | <TabAtkins> | I somehow lost that setting when I came in this week, and it's the most frustrating thing ever. |
| 00:58 | <Hixie> | i want "focus follows intent" |
| 00:59 | <TabAtkins> | Good luck speccing that. |
| 00:59 | <Hixie> | the number of times i hit Command+W attempting to close a tab in a browser when I've switched to my Terminal is just stupid |
| 00:59 | <zewt> | after a couple decades of mouse-position-has-no-effect-on-focus, i'm pretty sure that would be worse, heh |
| 00:59 | <Hixie> | and i'll do that while looking at the focused terminal with my mouse on the terminal, so focus-follows-mouse and focus-follows-eyes wouldn't help |
| 01:00 | <dbaron> | your mouse position may have no effect on focus, but mine does |
| 01:00 | <zewt> | and in general i dislike the mouse position having side-effects (webpages that go "your mouse went over our facebook/twitter/whatever widget, you must want us to expand it to cover up what you're reading! (and then never hide it)" drive me crazy) |
| 01:00 | <TabAtkins> | zewt: I thought so too, until I switched myself with registry hacks in Windows. |
| 01:00 | <TabAtkins> | Now I can't go back. |
| 01:01 | <TabAtkins> | Oh gosh, I just re-set my config, and I'm so happy. |
| 01:02 | <Hixie> | (focus follows mouse is definitely superior) |
| 01:03 | <TabAtkins> | Specifically, you want "sloppy" focus-follows-mouse, where entering a window grants it focus, but leaving it doesn't remove focus. |
| 01:03 | <TabAtkins> | The latter often plays very badly with things like alt-tab. |
| 01:07 | <annevk> | http://www.alvestrand.no/pipermail/idna-update/2012-November/007465.html |
| 01:07 | <annevk> | that's the author of IDNA2008 |
| 01:08 | <annevk> | and it's mind boggling |
| 01:08 | <annevk> | especially the last two paragraphs |
| 01:12 | <jsbell> | I could attempt to say something profound like: Even very smart people have a hard time understanding that the Web is orders of magnitude larger, more complex and has more legacy despite its short lifetime than anything humans have ever created before" but it would probably be nitpicked to death. |
| 01:12 | <TabAtkins> | Sigh. |
| 01:12 | <jsbell> | and on that note... |
| 01:14 | <annevk> | I was gonna reply with "And this is why we ignore the IETF" |
| 01:36 | <Hixie> | almost done with this canvas worker monster |
| 01:36 | <Hixie> | just CanvasProxy to spec now |
| 01:36 | <Hixie> | (if you want to see the current state, the single-page spec has been updated) |
| 01:39 | <annevk> | ah, glad there's no getContext("worker") anymore |
| 01:39 | <annevk> | Hixie: is the typedef stuff to prevent people from making new stuff up? |
| 01:40 | <Hixie> | no it's for my sanity |
| 01:40 | <Hixie> | it just changes a union to a typedef |
| 01:40 | <Hixie> | doesn't make any difference to other specs as far as i ca ntell |
| 01:41 | <annevk> | ah |
| 01:41 | <Hixie> | bbl |
| 01:44 | <annevk> | at some point lineCap / lineJoin should become enum |
| 01:44 | <annevk> | same for direction and such |
| 01:48 | <Yuhong> | http://www.alvestrand.no/pipermail/idna-update/2012-November/007467.html |
| 07:25 | <Davstern15> | Man. |
| 07:26 | <Davstern15> | I have come to the conclusion that Firefox is horrible at drawing to canvas and that I hate it. |
| 07:26 | <Davstern15> | And that especially archs seem to be super slow. |
| 07:26 | <Davstern15> | Even if Firefox 16 (latest stable) does ALL of the drawing to canvas in CPU with NO help at all from the GPU in any way... wouldn't the drawing be faster on a super Xeon Quad-core 3.4 GHz compared to a PC from 2006? |
| 07:26 | <Davstern15> | On both machines, it seems just as sluggish at drawing it. Also, HOW can a computer made after 1970 or so have trouble calculating archs? |
| 08:14 | <MikeSmith> | can somebody with IE please test https://bugzilla.mozilla.org/attachment.cgi?id=292660 and let me know what the result is? |
| 08:14 | <MikeSmith> | do an on-page find for "mozilla" |
| 08:15 | <MikeSmith> | and see if it scrolls the overflow:hidden area on that page to show it |
| 08:32 | <Davstern15> | MikeSmith: I will try in IE 10. |
| 08:32 | <zcorpan> | ok! anyone else have opinions about this quirk? https://bugzilla.mozilla.org/show_bug.cgi?id=747517#c7 |
| 08:32 | <Davstern15> | It highlights the "mozilla" text in the bottom-left corner of the square, miketaylr. |
| 08:32 | <Davstern15> | *MikeSmith |
| 08:32 | <MikeSmith> | Davstern15: thanks much |
| 08:37 | <MikeSmith> | zcorpan: so dbaron is saying he's open to anything except applying the quirk in all modes? |
| 08:38 | <zcorpan> | MikeSmith: if 'anything' is three possible things, then yes |
| 08:38 | <Davstern15> | I am going insane here. |
| 08:39 | <Davstern15> | I cannot find any references to Firefox 16 being slow or how to turn on some supposedly off-by-default hardware rendering of canvas. |
| 08:39 | <Davstern15> | But it IS very slow. |
| 08:45 | <MikeSmith> | zcorpan: I think that should be quirks-mode only |
| 08:46 | <zcorpan> | MikeSmith: why? |
| 08:47 | <MikeSmith> | I don't think normal authors would expect the underline color to change |
| 08:47 | <MikeSmith> | nor users |
| 08:49 | <MikeSmith> | I think not having the underline color change for that case is a better user experience |
| 08:50 | <zcorpan> | that seems to argue for dropping the quirk |
| 08:53 | <MikeSmith> | zcorpan: yeah, though I don't feel strongly against keeping it just for quirks mode, as in FF |
| 08:59 | <MikeSmith> | zcorpan: I updated the SVG path-data checker along the lines we talked about yesterday |
| 09:00 | <MikeSmith> | just now posted comment http://bugzilla.validator.nu/show_bug.cgi?id=945#c9 |
| 09:00 | <MikeSmith> | please give it a try again on http://qa-dev.w3.org:8888/ when you have time |
| 09:01 | <MikeSmith> | I found that it's not practical at all on the current code to try to truncate the extracts on the server side |
| 09:02 | <MikeSmith> | because the code that emits those extracts does not expose any way to measure their length before they're emitted |
| 09:03 | <MikeSmith> | it just streams them out |
| 09:05 | <MikeSmith> | so the "truncation" is done on the client side just be setting an explicit height and overflow:hidden on any extract area whose textContent is more than 200 characters |
| 09:18 | <zcorpan> | MikeSmith: thanks. A+ |
| 09:19 | <MikeSmith> | zcorpan: super |
| 09:19 | <MikeSmith> | thanks for the test cases and suggestions |
| 09:19 | <zcorpan> | np man |
| 09:20 | <MikeSmith> | will get the patch to Henri for review |
| 09:22 | <zcorpan> | MikeSmith: for the overflow thing, i think i'd skip the character count and just do max-height:3em; overflow:hidden; |
| 09:23 | <MikeSmith> | oh |
| 09:23 | <MikeSmith> | good idea |
| 09:23 | <MikeSmith> | didn't think of max-height |
| 09:23 | <MikeSmith> | will change that now |
| 09:26 | <Davstern15> | Is there a way to trim an image? |
| 09:28 | <zcorpan> | MikeSmith: i found a different bug now. newlines in the attribute value get shown as literal newlines in the message (both for "bad value `...`" and the new context) |
| 09:28 | <MikeSmith> | oh |
| 09:28 | <zcorpan> | MikeSmith: maybe they should be replaced with ↩ |
| 09:29 | <MikeSmith> | yeah, I attempted to convert them as such for the context case |
| 09:29 | <MikeSmith> | I must have missed something |
| 09:29 | <Davstern15> | Oh, God, let somebody have a trim() example... |
| 09:29 | <Davstern15> | I need to remove all transparent parts and return only the resulting trimmed image. |
| 09:30 | <Davstern15> | (As a rectangle.) |
| 09:30 | <MikeSmith> | for the "bad value `...`" part, the existing behavior is to display the newlines as-is. But I agree it'd be better to have them replaced with "↩" |
| 09:31 | <MikeSmith> | will need to ask Henri about that |
| 09:31 | <MikeSmith> | zcorpan: anyway if you have a test case where they're not being converted in the new context stuff, I'll fix it now for that part at least |
| 09:33 | <zcorpan> | <svg><path d="M204.33 |
| 09:33 | <zcorpan> | 139.83 ,C196.33 133.33 206.68 132.82 206.58 132.58"/></svg> |
| 09:36 | <zcorpan> | MikeSmith: <path d="M0,0C"/> seems to have slightly wrong message and empty context |
| 09:37 | <zcorpan> | "Expected number for c command but found nothing (context: )." |
| 09:38 | <zcorpan> | the wrong part being "c" (lowercase) |
| 09:39 | <MikeSmith> | oh |
| 09:39 | <MikeSmith> | copy pasta |
| 09:39 | <MikeSmith> | thanks |
| 09:39 | <MikeSmith> | will fix that |
| 09:39 | <MikeSmith> | though dunno why the context is empty |
| 09:40 | MikeSmith | looks |
| 12:38 | <annevk> | MikeSmith: pretty awesome to have better SVG validation |
| 12:43 | <ManDay> | Oh cool, this channel actually exists |
| 12:43 | <MikeSmith> | annevk: only for path@d values so far |
| 12:43 | <Moo^_^> | ManDay: here you find more insight on spec matters |
| 12:43 | <ManDay> | What's your opinion on a <toc> element which generates a table of contents from the page? |
| 12:44 | <jgraham> | ManDay: Cool idea, doesn't work at all |
| 12:44 | <ManDay> | jgraham: "Your opinion" => "Your elaborated opinion" |
| 12:45 | <ManDay> | I do agree that it appears somewhat strange with regards to how HTML is marking up content and not marking up places where content is supposed to be generated - BUT, what other solution do you see for creating TOCs? |
| 12:46 | <jgraham> | It doesn't work well with incremental rendering because it depends on the full content of the document. It would need to be live, which would be a performance issue. Historically the one example of a macro-like element turned out to be a bad idea so we don't do that anymore |
| 12:46 | <jgraham> | If you have a static document, use a preprocessing step |
| 12:46 | <jgraham> | Otherwise you could use a script attached to DOMContentLoaded |
| 12:47 | <ManDay> | preprocessing... hm. I currently do that with mathml, works nice |
| 12:47 | <ManDay> | nah... scripts, bah |
| 12:47 | <ManDay> | do you happen to have a tool for such preprocessing? |
| 12:47 | <jgraham> | With web components you might even be able to make that script look like an <x-toc> tag, or <div is=toc> or similar |
| 12:47 | <jgraham> | Only one that is heavily optimised for producing full specifications |
| 12:47 | <ManDay> | <div is=toc>? I've been living in a hole in the ground for too long |
| 12:48 | <ManDay> | What the heck is "is"? |
| 12:48 | <jgraham> | Well it isn't yet :) |
| 12:48 | <ManDay> | oh, k |
| 12:48 | <jgraham> | But there is a plan for a technology called web components that will make it easier to create reusable components |
| 12:48 | <jgraham> | And that is one proposed syntax for embedding a component |
| 12:49 | <ManDay> | Uhm... XML Namespaces, anyone? |
| 12:49 | <jgraham> | No |
| 12:49 | <Moo^_^> | ManDay: not supported in HTML5 |
| 12:49 | <jgraham> | :) |
| 12:49 | <ManDay> | What? Works "fine" (as in: Throws no errors in Webkit and FF) with mathml xmlns |
| 12:49 | <zcorpan> | xml namespaces is a problem, not a solution |
| 12:49 | <ManDay> | What the ... |
| 12:50 | <ManDay> | Imho the real problem is that HTML5 isn't designed as XML in the first place |
| 12:50 | <Moo^_^> | ManDay: so you have been living in a hole in the ground :) |
| 12:50 | <ManDay> | it's like completely non-strict with a dose of "you may use xml markup if you fancy it" |
| 12:50 | <ManDay> | Moo^_^: My brain is still working, though |
| 12:50 | <Moo^_^> | ManDay: I think there are several reasons why people chose this road |
| 12:51 | <ManDay> | I'd be curious to read one |
| 12:51 | <Moo^_^> | ManDay: if you want to find out about those reasons people here can probably help you |
| 12:52 | <zcorpan> | ManDay: http://wiki.whatwg.org/wiki/FAQ#Why_does_this_new_HTML_spec_legitimise_tag_soup.3F |
| 12:53 | <ManDay> | zcorpan: My concern is more wrt to you saying that XMLNS are not the solution but instead contrive something called "web components" |
| 12:53 | <zcorpan> | i only said that xml namespaces is a problem, not a solution |
| 12:55 | <ManDay> | Well, if we consider something like embedding, say, SVG and MathML in XHTML, we can do that generically for everything. Like <x-toc xmlns="manday.org/yeah">; - Why web components? |
| 12:56 | <zcorpan> | SVG and MathML were grandfathered into the HTML syntax and don't use a generic syntax that can or should be used for new features |
| 12:57 | <zcorpan> | generally, new features that are supposed to work with HTML go in the HTML namespace |
| 12:57 | <zcorpan> | i don't know enough about web components to have a useful opinion about it |
| 12:57 | <ManDay> | yes, I know the current status. question is: Why do you approve that idiocity |
| 12:57 | <ManDay> | (you = pl.) |
| 12:58 | <ManDay> | (as in: so.) |
| 12:58 | <ManDay> | (just to be less insulting) |
| 12:58 | <zcorpan> | i guess we disagree about what part is idiocity |
| 12:58 | <zcorpan> | "we" think xml namespaces are idiocity |
| 12:58 | <ManDay> | Why?? |
| 12:59 | <ManDay> | XML is one of the most consistent things that ever came from W3 |
| 12:59 | <zcorpan> | because they are a source of confusion for people and a source of bugs in software |
| 12:59 | <zcorpan> | http://wiki.whatwg.org/wiki/Namespace_confusion has some notes |
| 13:00 | ManDay | has the feeling whatwg.org maintains a defamatory wiki about w3 |
| 13:01 | <Moo^_^> | ManDay: no, I think they are just pragmatic and deal more with real world use cases |
| 13:02 | <ManDay> | "Bugs caused by Namespaces" - that's just pathetic... Be at least as fair as to say "Bugs caused by people who are incapable of using Namespaces properly" |
| 13:02 | <ManDay> | You find an idiot who doesn't understand it for everything. But you can't call the thing bad for that |
| 13:03 | <ManDay> | Namespaces are necessary to allow for embedding DTDs into others, right? |
| 13:03 | <ManDay> | We see what's the alternative with HTML5 where, as you said, the elements are "grandfathered" into the DTD |
| 13:03 | <ManDay> | Which is bollocks |
| 13:04 | <ManDay> | (PS: I don't claim that I'm capable of using Namespaces properly, but if I read the docs carefully, I will) |
| 13:05 | <jgraham> | FWIW namespaces and components don't solve the same problem |
| 13:05 | <Moo^_^> | ManDay: I think if you want to critize the made decisions you should write to whatwg mailing list |
| 13:05 | <Moo^_^> | ManDay: or in a blog |
| 13:05 | <Moo^_^> | ManDay: it would be the most efficient media for that |
| 13:06 | <jgraham> | components are like a descendant of XBL in Mozilla which was namespace-loving XML and embedded in XUL, which is also namespace-loving XML |
| 13:07 | darobin | giggle at the notion of using DTDs and namespaces together |
| 13:09 | <ManDay> | darobin: It might not have been perfectly expressed, but aren't namespaces related to DTDs in that elements from two different namespaces are defined by different DTDs? |
| 13:09 | <Moo^_^> | ManDay: but as you find out, the matter is opinionated |
| 13:09 | <Ms2ger> | ManDay, no |
| 13:09 | <darobin> | ManDay: no, the notions are completely orthogonal |
| 13:10 | <darobin> | and you in fact cannot use DTDs and namespaces completely together; in the general case they are strictly incompatible; if you stick to conventions you can parametrise them to work together |
| 13:11 | <darobin> | but you're just saying that because you're confusing DTDs and languages |
| 13:11 | <ManDay> | darobin: The syntax of one XML (say, XHTML) is defined by a DTD, right? |
| 13:12 | <darobin> | ManDay: no, the syntax is defined by the XML specification |
| 13:12 | <ManDay> | Or am I mistaken about the terminology |
| 13:12 | <darobin> | completely mistaken I'm afraid :) |
| 13:12 | <ManDay> | darobin: The "XML Specification" being a DTD, I thought?! |
| 13:12 | <darobin> | uhm, no |
| 13:12 | <ManDay> | Like RelaxNG or whatever there is |
| 13:12 | <darobin> | http://www.w3.org/TR/xml/ |
| 13:13 | <darobin> | you're thinking of schemata |
| 13:13 | <darobin> | which are ways of giving a formal definition within some constraints to a language |
| 13:13 | <darobin> | but a language does not need that |
| 13:13 | <darobin> | and schemata are orthogonal to syntax |
| 13:14 | <darobin> | no offence but I would recommend that you get your story straight before calling anything else bollocks :) |
| 13:15 | <ManDay> | No need to tell me that |
| 13:15 | <ManDay> | I only realized that my story wasn't straight |
| 13:15 | <ManDay> | a DTD defines, for instance, which nodes may be childnodes of other nodes, right? |
| 13:16 | <darobin> | it defines which element types can contain which other element types, yes |
| 13:16 | <darobin> | though that's a notion that doesn't map with nodes |
| 13:17 | <darobin> | nodes can be things that aren't elements; and element types are limited to local names and don't take namespaces into account |
| 13:17 | <zcorpan> | annevk: doesn't &#{decimal code point}; in URLs break the URL since both & and # have special meaning in URLs? |
| 13:19 | <annevk> | zcorpan: you wouldn't put them there as literals |
| 13:19 | <zcorpan> | annevk: percent-escaped? |
| 13:19 | <annevk> | zcorpan: note that form submission (with GET) munges the URL too so you already have that |
| 13:19 | <annevk> | zcorpan: right |
| 13:19 | <annevk> | or URL escaped in current lingo, but I should change that back |
| 13:19 | <zcorpan> | ah |
| 13:20 | <zcorpan> | yeah if <form method=GET> already does it, i guess we can do the same for <a href> |
| 13:20 | <ManDay> | darobin: Ok, so DTD define which elements can contain other elements and the XML Spec defines which elements exist and which attributes they have? |
| 13:21 | <darobin> | ManDay: no, the XML spec defines (mostly) how you parse the syntax of XML (elements, attributes, etc.) |
| 13:22 | <zcorpan> | ManDay: DTDs have been obsolete since XML Namespaces were introduced. The XML Core WG considered fixing DTDs to support namespaces when introducing namespaces, but decided against it because they figured DTDs suck anyway and it was better to replace it with a more expressive schema language. |
| 13:22 | <darobin> | then if you want to define an XML-based language, you can indeed give it a DTD if you're masochistic |
| 13:22 | <darobin> | ManDay: but I'm not sure IRC is the best medium from a ground-up course on the XML stack.., |
| 13:23 | <ManDay> | darobin: Which "thing" defines which elements have which attributes? |
| 13:24 | <ManDay> | darobin: That was a misunderstanding |
| 13:24 | <annevk> | zcorpan: I think it makes sense, especially since we'll prolly define URLQuery in terms of application/x-www-form-urlencoded too |
| 13:24 | <darobin> | ManDay: it can be many things |
| 13:24 | <darobin> | you can write it up in text, you can use code, you can use a schema language |
| 13:24 | <ManDay> | darobin: That's what I was thinking ever since I came here |
| 13:25 | <darobin> | there is no set "thing" for that; all that matters is that the parties involved agree on how to agree |
| 13:25 | <zcorpan> | ManDay: in the case of HTML and SVG, that's defined in the relevant spec using English |
| 13:25 | <ManDay> | I know |
| 13:25 | <darobin> | (or something that bears some resemblance to English at any rate :) |
| 13:27 | <ManDay> | Yes, so here is the question wrt DTD vs. namespaces: If I want to embed SVG into another XML Language which happens to have elements whose names are the same as those of SVG, I would use namespaces, right? So that if an element <foo> exists in both, my XML language and SVG, I could specify my:foo or svg:foo , right? So and here is where I think the DTD comes in that, depending on which namespace and thus which element I referen |
| 13:27 | <ManDay> | So and here is where I think the DTD comes in that, depending on which namespace and thus which element I reference, the allowed children are different. |
| 13:31 | <ManDay> | It was my original impression (and I still think it would be the right thing to do), that every XML Language needs a strict definition (which satisfies a specification for such definitions) of all elements, their attributes and relationships. |
| 13:31 | <MikeSmith> | zcorpan: btw http://qa-dev.w3.org:8888/ now has a couple further updates of path-data checking, based on your suggestions. it now consistently replaces newlines with "↩" in both places, and for the context it now just consistently shows the last up-to 20 characters in the value preceding the place where the error was found. |
| 13:31 | <ManDay> | After what you've been telling me about DTD being obsolete I get the impression XML became nothing but a bunch of "<" and ">" with no clear statement on how the language is actually constructed |
| 13:34 | <zcorpan> | MikeSmith: excellent |
| 13:34 | <zcorpan> | MikeSmith: nice work |
| 13:35 | <MikeSmith> | nice suggestions :) |
| 13:36 | <ManDay> | darobin: Any comment? |
| 13:36 | <zcorpan> | ManDay: one of the main points with XML was to allow for DTDless parsing |
| 13:36 | <darobin> | yeah |
| 13:36 | <darobin> | ManDay: also, you really can't use namespaces with DTDs |
| 13:37 | <darobin> | so, you can indeed use namespaces for disambiguation |
| 13:37 | <darobin> | and there are plenty of cases in which that's useful |
| 13:37 | <darobin> | but it wouldn't particularly help with Web Components |
| 13:37 | <ManDay> | zcorpan: What you say doesn't make much sense to me. "Parsing" itsself does not require anything but "parsing" successfully. |
| 13:37 | <ManDay> | The question is how to specify a language |
| 13:38 | <zcorpan> | ManDay: you specify a language in a specification |
| 13:39 | <ManDay> | darobin: Wrt to webcomponents, I think of something like <div xmlns="something.org/mytemplate_A"><templatevalueA something="foo" /><templatevalueB bar="something"></templatevalueB></div> |
| 13:39 | <ManDay> | zcorpan: Yes, I know. Why are you telling me this? |
| 13:39 | <zcorpan> | ManDay: i'm just trying to answer your questions |
| 13:39 | <ManDay> | Which question? |
| 13:39 | <zcorpan> | "The question is how to specify a language" |
| 13:40 | <ManDay> | Well, that was meant figuratively. As in: "The concern of XML it should be to specifiy how to specify a language" |
| 13:40 | <ManDay> | Which doesn'T have anything to do with parsing something. |
| 13:44 | <zcorpan> | the context for my comment about parsing is that SGML did not allow for DTDless parsing, which was something the XML designers wanted to allow |
| 13:46 | <darobin> | zcorpan: made for much more creative parsing though :) |
| 13:47 | <ManDay> | Point is, after all: There is no specification on how to specify an XML Language formally and in particular what constitutes an XML Language (what is the extend of validity) |
| 13:48 | <ManDay> | XML just seems to say: This is the syntax (as in "well formedness") of XML, do whatever you like with it |
| 13:48 | <zcorpan> | yeah that seems about right |
| 13:52 | <ManDay> | So in terms of XML nothing prevents me from adding a <foo> element to my XHTML document - only some additional requirements for the document? |
| 13:52 | <ManDay> | What about XML's <!DOCTYPE ? |
| 13:52 | <ManDay> | Doesn't that explicitly have notion of a DTD? |
| 13:55 | <zcorpan> | ManDay: XML doesn't prevent you from doing that, but the HTML spec does. |
| 13:56 | <ManDay> | zcorpan: Yes, so every XML Language re-invents the wheel for defining a strict language |
| 13:56 | <zcorpan> | ManDay: XML still supports DTDs, they just don't work well together with namespaces and have some other problems (like not being expressive enough to be useful for validation) |
| 13:59 | <zcorpan> | ManDay: right. i think some specs use a formal grammar for defining the content model, while others use just prose, and some have a mix of both |
| 14:00 | <zcorpan> | ManDay: some requirements are not expressible in a formal grammar, even grammars that are more expressive than DTDs. for instance, HTML requires that table cells don't overlap each other. |
| 14:02 | <ManDay> | zcorpan: Sure, I do realize that you may always contrive requirements which are too complex for a certain grammar to express. Still, isn't imposing *anything* *but* well-formedness a mistake? |
| 14:03 | <zcorpan> | why? |
| 14:05 | <ManDay> | Because all the XML languages than have a 80% overlap which is being "re-invented" (as in: not standardized) over and over again |
| 14:05 | <ManDay> | s/than/then |
| 14:05 | <ManDay> | Hm, wait a second |
| 14:07 | <ManDay> | I think I could live with that specification of what is a valid language being a separate spec (say, DTD), but then again, I don't understand why namespaces and DTD don't work together as imagine it. That is: |
| 14:07 | <ManDay> | The namespace designating the element from a specific DTD (and thus its semantics) |
| 14:08 | <annevk_> | euhm, DTDs are a relic from the past; they're only part of XML because they didn't think it through at the time |
| 14:09 | <zcorpan> | DTDs denote the element's name before namespace processing is performed. that is, you don't put namespace+local name pairs in the DTD, you use the tag name (including namespace prefix) and can't hook in to namespaces |
| 14:10 | <zcorpan> | if you use namespaces, you want to use the namespace+local name pair, and the namespace prefix should be able to vary |
| 14:10 | <zcorpan> | that's why they don't work together |
| 14:11 | <zcorpan> | RELAXNG supports namespaces |
| 14:16 | <annevk> | so apparently IE does not do IDNA2008 either? |
| 14:17 | <annevk> | I wonder what the chances are of browsers other than Opera adopting some of it |
| 14:33 | <annevk> | zcorpan: does https://www.w3.org/Bugs/Public/show_bug.cgi?id=19980#c3 sound okay to you? |
| 14:34 | <zcorpan> | annevk: yes |
| 14:46 | <ManDay> | Does HTML5 have notion of hyphenation? |
| 14:50 | <zcorpan> | ManDay: what kind of hyphenation? |
| 14:51 | <ManDay> | Like hy-phen-ation for justified text. |
| 14:53 | <Ms2ger> | That's another layer |
| 14:55 | <jgraham> | In the web platform lasagne |
| 14:58 | <zcorpan> | ManDay: automatic hyphenation is the responsibility of CSS. i don't recall if it's part of CSS yet, or if it is, if it's implemented anywhere yet. |
| 14:59 | <zcorpan> | ManDay: it's possible to put in ­ in long words in HTML, though |
| 14:59 | <Ms2ger> | I'm pretty sure Gecko implements something about hyphenation |
| 14:59 | <ManDay> | See, there we go |
| 14:59 | <ManDay> | Shy... |
| 14:59 | <Ms2ger> | ­ is simply syntax for a unicode character, so hardly HTML |
| 15:00 | <zcorpan> | Ms2ger: hey, that character is about the only thing the html4 spec actually had requirements for! |
| 15:02 | <annevk> | that can hardly be true, because then dbaron's table with quotes on the side would not be a conforming HTML4 implementation |
| 15:03 | <ManDay> | That doesn't make sense |
| 15:09 | <jgraham> | ManDay: See /topic |
| 15:10 | <ManDay> | Oh, my bad |
| 15:15 | <zcorpan> | new DragEvent('dragstart', {dataTransfer:{}}); should that throw TypeError? |
| 15:15 | <zcorpan> | member is specced as: DataTransfer? dataTransfer; |
| 15:18 | <zcorpan> | my reading of webidl says yes |
| 15:19 | <annevk> | {} != DataTransfer and {} != null so yeah |
| 15:20 | <zcorpan> | that kind of reasoning for webidl has failed me before |
| 15:23 | <jgraham> | What screenshot sizes do people use for reftests? |
| 15:23 | <jgraham> | I have a vauge memory that Mozilla use 800x600? |
| 15:47 | <annevk> | I wonder why everyone wants user/password to be supported in URLs |
| 15:52 | <Ms2ger> | jgraham, I'm told 600�600 |
| 16:09 | <SimonSapin> | does html5lib support python3? |
| 16:10 | <SimonSapin> | I see a python3 directory in the source repo, but "pip-3.3 install html5lib" fails with syntax errors |
| 16:11 | <Ms2ger> | gsnedders would know |
| 16:11 | <jgraham> | I think yes, but I don't kow how you arrange it |
| 16:12 | <gsnedders> | The latest PyPi release doesn't, what's in hg does except for charset detection I believe. |
| 16:12 | <gsnedders> | See the bug. |
| 16:12 | <gsnedders> | http://code.google.com/p/html5lib/issues/detail?id=187 |
| 16:13 | <SimonSapin> | jgraham, gsnedders: is it expected that two separate code bases will be maintained? |
| 16:15 | <Ms2ger> | SimonSapin, the idea is to use py3to2, iirc |
| 16:18 | <SimonSapin> | Ms2ger: this one? http://pypi.python.org/pypi/py3to2/ I don’t quite understand what it is … how does it compare to 2to3? |
| 16:18 | <Ms2ger> | It's the other direction |
| 16:19 | <Ms2ger> | For 2to3, the python 2 source is the canonical one; for 3to2, it's the python 3 source |
| 16:19 | <SimonSapin> | do you mean http://pypi.python.org/pypi/3to2 maybe? |
| 16:20 | <Ms2ger> | Probably |
| 16:21 | <SimonSapin> | I see |
| 16:21 | Ms2ger | is surprised this isn't all in the bug |
| 16:31 | <MikeSmith> | annevk: about http://www.alvestrand.no/pipermail/idna-update/2012-November/007465.html |
| 16:32 | <MikeSmith> | dude is like the Christian Democrat wing of the IETF |
| 16:32 | <MikeSmith> | or maybe more like Tea Party |
| 16:34 | <MikeSmith> | it seems like there are plenty of people active in IETF work who are a lot less dogmatic and reactionary |
| 16:36 | <MikeSmith> | they just have a hard time getting any changes past the old-guard inertia |
| 16:37 | <MikeSmith> | e.g., pretty sure dude is on of those who consistently argues against moving away from plain text for RFCs |
| 16:37 | <MikeSmith> | some other standards bodies have the same problem |
| 16:38 | <MikeSmith> | the only thing that seems to get their attention is when you say "fuck it" and seriously start doing significant "competing" work elsewhere |
| 16:39 | <dglazkov> | good morning, Whatwg! |
| 16:48 | <annevk> | MikeSmith: yeah, dunno what to do about this problem though |
| 16:49 | <annevk> | MikeSmith: Opera has some IDNA2008 hack, other browsers, including IE it appears, implement IDNA2003+ (IDNA2003 with Unicode > 3.2) |
| 16:50 | <MikeSmith> | where does the Unicode 46 thing fit into this? |
| 16:50 | <annevk> | MikeSmith: Gecko may or may not implement IDNA2008 (what the code does they have access to is not clear), Chrome/Safari are unlikely to move afaict, dunno about IE |
| 16:50 | <MikeSmith> | I thought the unicode 46 thing was supposed to fix all this |
| 16:51 | <annevk> | MikeSmith: it defines IDNA2003+, but has some modifications in place for a few things IDNA2008 does |
| 16:51 | <annevk> | nobody does UTS 46 at this point |
| 16:51 | <annevk> | well, actually, some Unicode Members might use it, I'm told, but I'm not sure for what |
| 16:51 | <annevk> | maybe Google's search engine does |
| 17:09 | <GPHemsley> | dglazkov always knows the right time in a discussion to say good morning. |
| 17:10 | <MikeSmith> | GPHemsley: the fact is he has some AI he's written to do that |
| 17:10 | <MikeSmith> | really sophisticated stuff |
| 17:10 | <GPHemsley> | :) |
| 18:16 | <SimonSapin> | TabAtkins: see https://github.com/tabatkins/railroad-diagrams/issues/3#issuecomment-10456348 |
| 18:38 | <TabAtkins> | SimonSapin: I get emails from issues, you know. ^_^ |
| 18:51 | <SimonSapin> | TabAtkins: ah, of course. Sorry for being impatient :) |
| 19:13 | <Hixie> | nearly done with first draft of proposal for cross-worker canvas! woot! |
| 19:13 | <TabAtkins> | Woo! |
| 19:13 | <Hixie> | now to write up an e-mail explaining why it's crazy |
| 19:13 | <Hixie> | :-P |
| 19:14 | <SimonSapin> | Hixie: so you’d rather not have it? |
| 19:14 | <Hixie> | no, i mean, why it's a crazy api, but why it's crazy to have it |
| 19:14 | <TabAtkins> | s/but/but not/ |
| 19:15 | <Hixie> | right |
| 19:15 | <Hixie> | s/but/not/ |
| 19:15 | <TabAtkins> | Man, now I gotta fix it. |
| 19:15 | <TabAtkins> | s/not not/not/ |
| 19:17 | <Hixie> | hah |
| 19:30 | <cabanier> | Hixie: is it the crazy because of the double-buffering and passing objects across threads? |
| 19:34 | <Hixie> | it's mostly crazy being whole chunks of the API assumed the <canvas> and other DOM objects were available to scripts that had a CanvasRenderingContext2D object |
| 19:34 | <Hixie> | so i had to go through the whole thing and change it to refer to "the scratch bitmap", provide an ImageBitmap object to handle images, redo the way the "origin-clean" flag was set, etc |
| 19:35 | <Hixie> | plus having to still support the old API alongside the new one means there's like 3 ways you can use <canvas> now (x2 for WebGL, so 6) that all involve slightly differnet APIs |
| 19:35 | <Hixie> | so e.g. how you change the size of the bitmap when you're in a worker vs when you're using the old getContext() method |
| 19:36 | <cabanier> | so, there's a new context with reduced 2d APIs? |
| 19:36 | <Hixie> | no, i just use the same interface |
| 19:36 | <Hixie> | see http://www.whatwg.org/specs/web-apps/current-work/#2dcontext |
| 19:36 | <Hixie> | the single-page copy has the new stuff |
| 19:37 | <Hixie> | i'm writing up an e-mail describing it now |
| 19:37 | <cabanier> | cool! |
| 19:37 | <Hixie> | but e.g. making things like scrollIntoView() work cross-worker involves some pretty... special logic |
| 19:38 | <Hixie> | not quite how i would have done it if starting from scratch :-) |
| 19:43 | <cabanier> | "list of pending interface actions" :-) |
| 19:44 | <Hixie> | yeah :-/ |
| 19:53 | <Ms2ger> | matjas, if you're going to write something to list implementation status... I've got a few more specs I'd like to see that use :) |
| 19:54 | <Hixie> | if anyone wants to use what hte HTML spec uses, we can probably figure something out |
| 19:54 | <Hixie> | it's a bit tangled right now but if you know perl and JS, you can probably make a generic version |
| 19:54 | <Hixie> | uses mysql on the backend |
| 19:55 | <Ms2ger> | Eh, perl ;) |
| 20:19 | <annevk> | Hixie: I'm interested in seeing what it would take, though my Perl knowledge is non-existent |
| 20:26 | <Hixie> | ok! |
| 20:26 | <Hixie> | first draft of proposal is checked in |
| 20:27 | <Hixie> | bbl |
| 20:33 | <annevk> | createImageBitmap could use the same typedef defined earlier for images |
| 20:33 | <annevk> | also, _callback can be written callback again |
| 20:51 | <jgraham> | plh started with something for the W3C HTML spec, but it doesn't actually integrate into the document |
| 20:52 | <jgraham> | Uses caniuse for the data, which is better than the status annotations in WHATWG HTML |
| 21:10 | <Hixie> | jgraham: yeah, that'd be nice. |
| 21:10 | <Hixie> | jgraham: any idea how he mapped the data from one to the other? |
| 21:14 | <jgraham> | http://dvcs.w3.org/hg/html/file/c1a296c26d12/tools/json/caniuse.json |
| 21:14 | <jgraham> | Maps sections |
| 21:15 | <Hixie> | yikes |
| 21:15 | <Hixie> | hm |
| 21:15 | <Hixie> | is that all caniuse has? |
| 21:15 | <Hixie> | that seems limited |
| 21:16 | <Hixie> | maybe caniuse could override the spec status for sections it has, or something, and leave the others? |
| 21:16 | <Hixie> | hmmmm |
| 21:16 | <jgraham> | Not "yikes, they think that blobbuilder is still a thing" |
| 21:17 | <Hixie> | i didn't even look at the empty lines |
| 21:17 | <jgraham> | But I agree it's not super-fine-graied |
| 21:17 | <jgraham> | *grained |
| 21:18 | <annevk> | xhr2! |
| 21:20 | <annevk> | http://dvcs.w3.org/hg/xhr/shortlog |
| 22:04 | <GPHemsley> | Hixie: Feedback welcome on my most recent mimesniff commits. |
| 22:20 | <Hixie> | GPHemsley: from a quick glance, seems solid |
| 22:20 | <GPHemsley> | Anyone have anything to say about the (X-)Content-Type-Options header? I just sent an e-mail to the list about it. |
| 22:20 | <GPHemsley> | Hixie: Awesome, thanks. |
| 22:32 | <annevk> | GPHemsley: just replied |
| 22:32 | <GPHemsley> | thanks |
| 22:43 | <GPHemsley> | annevk: Replied. :) |
| 22:45 | <marcosc> | Hi, I'm currently implementing img@srcset's parsing algorithm but I'm a bit stuck (http://dev.w3.org/html5/srcset/#processing-the-image-candidates). I'm having trouble groking step 19: |
| 22:45 | <marcosc> | "If there are any entries in candidates that have an associated width that is less than max width, then remove them, unless that would remove all the entries, in which case remove only the entries whose associated width is less than the greatest such width." |
| 22:45 | <marcosc> | I don't really understand what "the greatest such width" is |
| 22:46 | <marcosc> | ;( |
| 22:46 | marcosc | sad panda |
| 22:46 | <Ms2ger> | I don't think that was the link you meant to mention here :) |
| 22:47 | <Hixie> | marcosc: it means remove all by thte biggest one |
| 22:47 | <marcosc> | Hixie: thanks! |
| 22:48 | <annevk> | GPHemsley: if content uses X-Content-Type-Options, there's no need to start calling it Content-Type-Options and break that content imo |
| 22:48 | <Hixie> | GPHemsley: my understanding is that X-Content-Type-Options basically doesn't do anything useful |
| 22:48 | <annevk> | GPHemsley: that's the main point I wanted to make |
| 22:48 | <Hixie> | GPHemsley: and that it mostly just makes IE behave like other browsers |
| 22:49 | <GPHemsley> | annevk: I was intending to have them both be equal, but that's the least of my worries. |
| 22:50 | <annevk> | GPHemsley: equal or not equal, you double (if not worse, because of combinations) testing effort |
| 22:50 | <GPHemsley> | Hixie: AFAICT, the browsers all behave differently in a lot of cases, so I'm not sure what that means. |
| 22:50 | <GPHemsley> | annevk: Fair enough. |
| 22:50 | <annevk> | GPHemsley: we already have x- prefixed features standardized too, it's not a big deal |
| 22:50 | <Hixie> | GPHemsley: i mean IE still does a ton of sniffing even with it set, but less sniffing than it otherwise would, and that browsers in general do a ton less sniffing than IE |
| 22:50 | <annevk> | e.g. application/x-www-form-urlencoded |
| 22:50 | <GPHemsley> | annevk: It was more based on my impression that it wasn't widely implemented; if it is, that's a different story. |
| 22:51 | <annevk> | btw, idna-update is still ongoing |
| 22:51 | <annevk> | http://www.alvestrand.no/pipermail/idna-update/2012-November/007477.html is my latest |
| 22:52 | <Hixie> | GPHemsley: if it's only in IE, the best thing to do would be to just ignore it and specify what it does as being the default, imho |
| 22:52 | <GPHemsley> | Hixie: According to abarth's article, IE does a lot less sniffing than you think, IIUIC. And most of it is covered by this spec. |
| 22:52 | <Hixie> | it=header |
| 22:52 | <Hixie> | GPHemsley: mimesniff = a ton of sniffing |
| 22:52 | <Hixie> | sorry for not defining my units :-) |
| 22:53 | <GPHemsley> | :) |
| 22:53 | <GPHemsley> | Hixie: According to abarth, IE sniffs on only 35 MIME types. |
| 22:53 | <GPHemsley> | And a bunch are not even widely used. |
| 22:53 | <Hixie> | four tons of sniffing |
| 22:54 | <GPHemsley> | s/IE/IE7/ |
| 22:56 | <Hixie> | the real problem btw is not sniffing, the real problem is ignoring Content-Type |
| 22:56 | <Hixie> | when there's no Content-Type, the ideal browser would sniff millions of types and pick the exact right one |
| 22:56 | <GPHemsley> | Hixie: AFAICT, IE's sniffing behavior is not terrible. |
| 22:57 | <Hixie> | old IE used to sniff text/html from an image/png file |
| 22:57 | <Hixie> | which is a security nightmare |
| 22:57 | <GPHemsley> | other than that part |
| 22:57 | <Hixie> | that's the only part that's the problem :-) |
| 22:57 | <Hixie> | that's what mimesniff is about fixing |
| 22:57 | <GPHemsley> | Hixie: Would you mind defining the difference between "sniffing" and "ignoring Content-Type" in this context? |
| 22:58 | <GPHemsley> | mimesniff says "you are allowed to ignore Content-Type in only these specific instances" |
| 22:58 | <Hixie> | i mean that if you don't know what the type is, then trying to work out if it's a PNG or a GIF is fine, but if you've been told it's an HTML file, trying to determine if it's a PNG or a GIF is bad. |
| 22:58 | <GPHemsley> | the addition of X-Content-Type-Options: nosniff will mean "you have much fewer opportunities to ignore Content-Type" |
| 22:58 | <Hixie> | what opportunities does it remove? |
| 22:59 | <GPHemsley> | Hixie: The way I have it now, everything that isn't sniffing undefined/unknown content-types |
| 22:59 | <Hixie> | i doubt that is web-compatible |
| 23:00 | <GPHemsley> | Hixie: But annevk's suggested alternative is to only limit sniffing scriptable types, which is a much smaller list. |
| 23:00 | <annevk> | well my suggestion was to test IE |
| 23:00 | <Hixie> | in particular, if you receive an image/png with X-Content-Type-Options: nosniff, but it's actually a GIF, I doubt it's web-compatible to treat it as a PNG (and fail) rather than sniffing it to be a GIF. |
| 23:00 | <annevk> | and whoever else implements the header |
| 23:00 | <GPHemsley> | (But would also mean that Gecko has much farther to go to reach compliance with the spec, I think.) |
| 23:00 | <Hixie> | i think there is no way to spec this without actually testing it |
| 23:01 | <Hixie> | which means writing lots of tests and running them and works out what is implemented |
| 23:01 | <GPHemsley> | right |
| 23:19 | <GPHemsley> | According to http://www.browserscope.org/?category=security , X-C-T-O is only implemented in IE and Chrome |
| 23:19 | <GPHemsley> | Not Firefox, Opera, or Safari |