| 00:10 | <Hixie> | i think i prefer novalidate, for consistency with nohref, noresize, noshade, and nowrap (though the irony that all four of those are obsolete in html5 is not lost on me) |
| 00:15 | <BenMillard> | so many conventions to choose from :P |
| 00:15 | <BenMillard> | I'm unlikely to use the feature so I don't mind what you call it |
| 00:24 | <Hixie> | BenMillard: :-) |
| 01:35 | <Hixie> | ew |
| 01:35 | <Hixie> | MouseEvent makes a mess of the init* methods |
| 01:58 | <Hixie> | hmm |
| 01:58 | <Hixie> | so <input type=color> |
| 01:58 | <Hixie> | should it be possible for the user to set it to no color? |
| 02:01 | <BenMillard> | transparent? |
| 02:10 | <Hixie> | no, nothing at all |
| 02:11 | <Hixie> | like, type=number allows any number, as well as "" |
| 02:11 | <Dashiva> | Can it have no color as initial value? |
| 02:11 | <Hixie> | but type=range doesn't allow "" |
| 02:11 | <Hixie> | Dashiva: that's another way of phrasing the same question, effectively |
| 02:12 | <Lachy> | what are the use cases for colour selection that we're trying to address and which ones are we not? |
| 02:13 | <Hixie> | in: selecting the colour of a label in gmail, selecting a color in a paint program |
| 02:13 | <Hixie> | can't think of any that are "out" offhand, but i'm sure there are many |
| 02:14 | <Hixie> | http://images.google.com/images?client=safari&rls=en-us&q=color%20pickers&ie=UTF-8&oe=UTF-8&um=1&sa=N&tab=wi suggests that color pickers don't have a "no color" mode |
| 02:14 | <Lachy> | ok, so this is basically a simple RGB colour palette |
| 02:15 | <Dashiva> | Hixie: But many of them have a cancel button |
| 02:16 | <Hixie> | Dashiva: yeah but that doesn't unset the previously selected color |
| 02:16 | <Lachy> | I'd assume things like paint colour selectors on interior decoration sites wouldn't be adequately covered by this, so that'd be out |
| 02:17 | <Hixie> | right |
| 02:18 | <Hixie> | out: pantone color selector |
| 02:19 | <Dashiva> | I suppose we aren't addressing "How do you ensure the user selects a color and doesn't just go ahead with the default without considering it" either |
| 02:22 | <Hixie> | not really |
| 02:29 | <Lachy> | yes, I think no colour should be possible, because if someone wants to make a paint application, that's one way of letting the user select transparent |
| 02:32 | <BenMillard> | Hixie, I think Word has a no colour mode. |
| 02:33 | <Hixie> | Lachy: opacity should be separate from this anyway |
| 02:41 | <Lachy> | Hixie, the colour palettes in apps like Adobe Fireworks allow the user to select a no-colour option. it's useful when, e.g., you want to set the border colour of a shape to one colour and leave the fill colour transparent |
| 02:47 | <Hixie> | Lachy: makes sense |
| 02:51 | <Hixie> | hmm |
| 02:51 | <Hixie> | should we make the form <input type=color> parse colors in a simple way, or using the wacky <font color> algorithm? |
| 02:52 | <Hixie> | or using the css algorithm... |
| 02:52 | <Hixie> | so many options... |
| 02:52 | <Hixie> | can't use css, as it might return an alpha!=1.0 color |
| 02:58 | <Lachy> | could you use a subset of the CSS colour, including #FFF, #FFFFFF, rgb(...) and hsl(...), but excluding rgba() and hsla()? |
| 02:58 | <Lachy> | also, the colour keywords |
| 03:01 | <Hixie> | that seems unnecessarily complex given that we'd still want to serialise everything to #rrggbb for submission |
| 03:02 | <heycam> | that's pretty much the same as strokeStyle/fillStyle on the canvas context object though |
| 03:02 | <Lachy> | specifically, what conditions are you trying to address? Is this for when the user types in a colour manually or when the value is set by a script? |
| 03:03 | <Hixie> | strokeStyle and fillStyle are full CSS colors |
| 03:03 | <Hixie> | Lachy: value of the value="" attribute |
| 03:03 | <Hixie> | (and form submission) |
| 03:04 | <Lachy> | oh, ok. |
| 03:14 | <Lachy> | with other input types, I don't think there is any precedent for the value of the value attribute being automatically normalised prior to submission, and so it would probably be best to require the format #rrggbb |
| 03:15 | <Lachy> | plus, if we allowed other types, then that would seem to create complications when the input.value property is set by scripts |
| 03:16 | <Lachy> | s/other types/other formats/ |
| 03:17 | <Hixie> | i'm still normalising it before submission btw (from uppercase to lowercase) |
| 03:17 | <Lachy> | ok |
| 04:01 | <Lachy> | Hixie, is the order of the input types in the table in any particular order? It seems rather random. Could you put them into alphabetical order? |
| 04:02 | <Lachy> | well, I guess there sort of grouped by category |
| 04:07 | <Hixie> | the order is the order used so that there are the fewest differences from type to type in terms of what cells say "yes" |
| 04:07 | <Hixie> | except that password isn't before text |
| 04:07 | <Lachy> | Hixie, a valid simple colour should be A to F, not A to Z |
| 04:08 | <Hixie> | oops |
| 04:10 | <Hixie> | ok fixed |
| 05:42 | <sayrer> | Hixie, so, I thought there was a feature freeze? but now we have this new 401 form... |
| 05:51 | <Hixie> | sayrer: i said i wasn't adding anything new that hadn't already been requested as of the feature freeze (last december) |
| 05:51 | <Hixie> | the recent additions are from requests from 2006/2007 |
| 05:52 | <sayrer> | that doesn't seem like a useful freeze to me |
| 05:52 | <sayrer> | thanks |
| 05:52 | <Hixie> | (or, in the case of workers, from requests from browser vendors who said that without a spec they'd just make up stuff) |
| 05:52 | <Hixie> | well the freeze is only intended to land us on schedule |
| 05:52 | <sayrer> | well, you are a browser vendor just making stuff up :) |
| 05:52 | <Hixie> | i mean implementors |
| 05:53 | sayrer | shrugs |
| 06:44 | <hsivonen> | Hixie: seems more like a suggestion freeze than a feature freeze :-) |
| 06:48 | <Hixie> | yeah, that'd be a better term |
| 06:48 | <Hixie> | i don't recall exactly how i phrased it |
| 06:56 | <hsivonen> | http://intertwingly.net/blog/2008/11/20/Half-Full#c1227667144 |
| 06:57 | <hsivonen> | Is there a definition for hixie:LC, hixie:CR, w3c:LC and w3c:CR? |
| 06:58 | <hsivonen> | (and are there URIs to bind hixie and w3c to?) |
| 07:14 | <hsivonen> | Hixie: btw, what happened to the OpenID integration idea that sicking mentioned at TPAC? |
| 07:16 | <Hixie> | i wonder how hixie:LC, hixie:CR, w3c:LC and w3c:CR differ |
| 07:16 | <Hixie> | hsivonen: no idea |
| 07:17 | <Hixie> | what's zcorpan's e-mail address? |
| 07:17 | <Hixie> | specifically, his webkit bugzilla account address |
| 07:18 | <hsivonen> | I'd try searching webkit bugzilla for zcorpan and simonp |
| 07:19 | <Hixie> | tried that |
| 07:43 | <hsivonen> | Hixie: was "no idea" to the OpenID idea? that is, did you examine the feasibility of moving bits of the OpenID experience to browser chrome in a backwards-compatible way? |
| 07:54 | <hsivonen> | http://lists.w3.org/Archives/Public/www-validator/2008Nov/0044.html |
| 07:55 | <Hixie> | no idea was to openid. not really sure what to do about it. |
| 08:25 | <Hixie> | when you substitute a for b in c, which one is left in c? a, or b? |
| 08:26 | <takkaria> | a? |
| 08:45 | <gavin> | a |
| 08:45 | <gavin> | a is a substitue for b |
| 08:59 | <Hixie> | wikitionary agrees |
| 09:04 | <hsivonen> | why are SVG and Canvas "extensions"? http://www.extremetech.com/article2/0,2845,2335251,00.asp |
| 09:08 | <mookid> | Why am I reading a thread about 'the login/logout problem' ? |
| 09:09 | <mookid> | there isn't a problem.. it works fine |
| 09:09 | <virtuelv> | hsivonen: that article is, in general, rather uninformed |
| 09:11 | <Hixie> | ie8 is adding svg and canvas? |
| 09:11 | <Hixie> | that's news to me |
| 09:17 | <Hixie> | wtf, screen sharing just doesn't work anymore to this computer |
| 09:17 | <Hixie> | i don't get it |
| 09:18 | <Hixie> | no error message, nothing |
| 09:18 | <Hixie> | afp, too |
| 09:18 | <Hixie> | just doesn't connect |
| 09:29 | <Lachy> | have you tried restarting the machine? |
| 09:29 | <Lachy> | I mean the one you're trying to connect to |
| 09:30 | <Hixie> | yes |
| 09:33 | <virtuelv> | hsivonen: the telltale sign in that article would be |
| 09:33 | <virtuelv> | «What's notable here is the margin. Chrome's winning margin is huge, even though Firefox 3.04, Opera and Safari have incorporated V8» |
| 09:33 | <Hixie> | o_O |
| 09:34 | <hsivonen> | virtuelv: whoa |
| 09:34 | hsivonen | didn't actually read the whole article |
| 09:35 | <virtuelv> | «We tested the version of Firefox (called Minefield) that does include the V8 code and listed those results below our "official" findings.» |
| 09:38 | <Hixie> | if I add remainingSpacePercentage, should I add it to sessionStorage, localStorage, and Database, or should I add it to Navigator and assume shared storage? |
| 09:39 | <virtuelv> | Hixie: is the percentage really relevant? |
| 09:40 | <Hixie> | microsoft want a feature to say how much space is remaining, and bytes don't work |
| 09:40 | <Philip`> | Does it make sense on sessionStorage? I'd assume that'd be stored in RAM, and browsers don't have fixed limits on how much RAM a page can use |
| 09:40 | <virtuelv> | a percentage is equally useless |
| 09:41 | <virtuelv> | if I'm trying to store a DOMString of length 1231, a percentage isn't going to help me |
| 09:41 | <Philip`> | virtuelv: Bytes wouldn't help you either, since you don't know how many bytes it'll take to store that string |
| 09:41 | <Hixie> | the only thing that it would allow is showing a UI saying how close you are to running out |
| 09:41 | <Hixie> | but i guess the UA could do that better anyway |
| 09:42 | <Philip`> | virtuelv: so you should just try to store it, and watch for exceptions |
| 09:53 | <yecril71> | Allowing to execute hidden commands from the keyboard does not seem to be a good idea at all. |
| 09:53 | <yecril71> | Although it would make implementing Vi in HTML pretty hard, |
| 09:53 | <yecril71> | I do not think HTML should explicitly provide for that. |
| 09:54 | <Hixie> | zcorpan needs to be online more. someone hook him up with screen(1) and irssi(1), please. :-P |
| 09:55 | <hsivonen> | the HTML article in wikipedia gets vandalized all the time and isn't protected. the XHTML article is semi-protected, though. |
| 09:56 | <yecril71> | Should I bring up the issue with fieldsets and HTMLControlsCollection to the list? |
| 10:01 | <Hixie> | what's the issue? |
| 10:11 | <yecril71> | The issue is a fieldset is not a control. |
| 10:11 | <yecril71> | And it does not belong to form.elements, as of HTML4. |
| 10:12 | <yecril71> | So there is a major incompatibility and a semantical flaw. |
| 10:12 | <Hixie> | browsers put fieldsets in form.elements, so there's not much we can do about that |
| 10:12 | <Hixie> | html5 defines it in a way that solves the "semantical flaw" |
| 10:12 | <Hixie> | i.e. it doesn't have a contradiction as best i can tell |
| 10:12 | <yecril71> | According to MSDN, a fieldset does not have a name. |
| 10:12 | <Hixie> | msdn is rarely accurate |
| 10:13 | <Hixie> | i wouldn't pay much attention to it |
| 10:14 | <yecril71> | Thanks, I shall evaluate it and leave a note there if it works anyway. |
| 10:14 | <mookid> | Hixie: what is all this stuff abuot forms? |
| 10:14 | <Hixie> | mookid: ? |
| 10:14 | <Hixie> | which stuff? |
| 10:15 | <yecril71> | Now that OBJECT is submittable, the note about legacy reasons should go. |
| 10:15 | <yecril71> | Because it is a full member of the FORM. |
| 10:16 | <Hixie> | could you provide more context? i'm not psychic, i've no idea what note you are talking about |
| 10:16 | <yecril71> | "OBJECT belongs to FORM.elements for legacy reasons". |
| 10:17 | <yecril71> | (quoting from memory) |
| 10:17 | <Hixie> | could you quote from the spec? |
| 10:17 | <Hixie> | i can't find that string anywhere |
| 10:17 | <yecril71> | Have to find it again first. |
| 10:19 | <yecril71> | For historical reasons, the object element, which is not otherwise considered to be related to forms, is also a form-associated element. |
| 10:19 | <yecril71> | That is the text. |
| 10:20 | <yecril71> | I would also note that IE7 gets awfully slow when displaying the specification, |
| 10:20 | <yecril71> | event the multipage version. |
| 10:20 | <yecril71> | And the section headers are not visible at all. |
| 10:20 | <yecril71> | They are hidden under the green background. |
| 10:21 | <yecril71> | That makes it somehow hard to know what you are reading about. |
| 10:21 | <Hixie> | yeah, IE has all kinds of bugs |
| 10:21 | <Hixie> | i recommend using another browser |
| 10:21 | Hixie | fixes the line in question |
| 10:22 | <yecril71> | Thats all right, except that the cost of maintenance doubles. |
| 10:23 | <yecril71> | And you cannot get rid of IE7 in Windows. |
| 10:23 | <yecril71> | Of course, you can get rid of Windows, but that is quite an operation. |
| 10:24 | <yecril71> | I think it would be best for everybody to take that into account. |
| 10:24 | <hsivonen> | cost of maintenance doubles? Firefox, Chrome and Safari autoupdate themselves on Windows |
| 10:25 | <yecril71> | Only if run with administrative privileges, something I shall never do. |
| 10:25 | <Hixie> | ok, fixed the object/form line |
| 10:27 | <yecril71> | I think it would not be so much harm to get rid of the negative top margin for now. |
| 10:28 | <yecril71> | A browser window is not short of sheet space, and PDF can be used for printing. |
| 10:30 | <yecril71> | Borrowing the header backround from the following element seems like a dirty hack. |
| 10:30 | <Hixie> | it's pretty. and standards compliant. If IE can't handle it, that's not my problem or the spec's problem. |
| 10:31 | <yecril71> | You can make the PDF as pretty as you wish. |
| 10:31 | <Hixie> | i don't read the pdf |
| 10:31 | <yecril71> | This is not a beauty contest. |
| 10:32 | <hsivonen> | I think that Ubuntu is a better solution against Windows malware than running a personal Windows box without admin privileges |
| 10:32 | <yecril71> | It is better to be ugly than to be unreadable. |
| 10:32 | <Hixie> | so don't use IE |
| 10:33 | <Hixie> | making it slightly more readable isn't going to make the spec work in IE anyway |
| 10:33 | <Hixie> | IE doesn't handle the size of the page |
| 10:33 | <Hixie> | not much we can do about that |
| 10:33 | <yecril71> | It can read the multipage version. |
| 10:33 | <yecril71> | I do. |
| 10:34 | <Hixie> | Basically, the problem is with IE, not the spec. The solution is to have IE be fixed, not have the spec work around bugs in IE. |
| 10:34 | <yecril71> | I cannot have the IE fixed. |
| 10:34 | <hsivonen> | yecril71: doesn't IE8 work, either? |
| 10:34 | <yecril71> | You have to ask Philip`. |
| 10:34 | <Hixie> | you can't have the spec fixed either. :-) |
| 10:35 | <yecril71> | And borrowing the backround for the next element is far from being good markup. |
| 10:35 | <Hixie> | it's quite acceptable css |
| 10:35 | <hsivonen> | http://www.w3.org/TR/mobile-bp/#d0e704 |
| 10:36 | <yecril71> | If you want the backround to be green, you have to choices: |
| 10:36 | <yecril71> | 2 choices: |
| 10:36 | <yecril71> | wrap in a common ancestor, which does not apply here, |
| 10:36 | <Hixie> | hsivonen: as someone who has worked on browser vendors, i hate it when sites work around bugs in browsers |
| 10:36 | <yecril71> | or use the same class. |
| 10:36 | <Hixie> | or use a negative margin :-) |
| 10:36 | <Hixie> | which is fine :-) |
| 10:37 | <hsivonen> | Hixie: well, the mobile-bp doc doesn't acknowledge people from the companies you've worked for... |
| 10:38 | <hsivonen> | I think it's quite telling that Opera and Apple aren't acked in the Mobile BP stuff |
| 10:39 | <Hixie> | chaals wrote part of it |
| 10:39 | <Hixie> | iirc |
| 10:39 | <yecril71> | The only workaround for Internet Explorer is to disable CSS. |
| 10:40 | <yecril71> | That makes the page readable and the performance is much better. |
| 10:40 | <hsivonen> | Hixie: whoa. indeed. I was looking at the acks and thought the editor was from vodafone |
| 10:40 | <hsivonen> | I must have mixed up the editorships of different docs |
| 10:41 | <Hixie> | actually i thought a googler worked on that doc too, but i don't see that in the acks anywhere |
| 10:41 | <Hixie> | might be another one |
| 10:41 | <Hixie> | there are so many |
| 10:41 | <yecril71> | However, even if I add whatwg.org to restricted sites, that will not disable CSS by default. |
| 10:42 | <yecril71> | And I am sorry to see Hixie behave so arrogantly. |
| 10:43 | <Hixie> | if there was a bug in the spec's style sheet, would you ask the browsers to work around it? |
| 10:43 | <Hixie> | simple software engineering. you fix the bug, you don't work around the bug. |
| 10:44 | <yecril71> | Not a single browser is fully CSS-compliant. |
| 10:45 | <yecril71> | Your attitude is unrealistic, however you may not like it. |
| 10:45 | <yecril71> | The publisher should aim at the intersection of what is supported. |
| 10:45 | <hsivonen> | It's still baffling that a W3C REC doesn't include PNG support as part of the assumed image format support |
| 10:46 | <hsivonen> | how did *that* get past *principles*? |
| 10:46 | <hsivonen> | but then the markup language support is specced as XHTML Basic 1.1 [XHTML-Basic] delivered with content type application/xhtml+xml. |
| 10:48 | <yecril71> | And I cannot fix the bug in IE, as I already said. |
| 10:48 | <Hixie> | you also cannot fix the spec, so i don't see how that is different or relevant |
| 10:49 | <yecril71> | Well, but you can. |
| 10:49 | <yecril71> | With a very tiny amount of work. |
| 10:49 | <Hixie> | if you insist on using IE, then i recommend using http://dev.w3.org/html5/spec/Overview.html instead. |
| 10:51 | <yecril71> | That document does not have a multipage version. |
| 10:52 | <Hixie> | ah well, i tried |
| 10:53 | <gsnedders> | Hixie: Then why have work-arounds for IE at all? |
| 10:53 | <gsnedders> | like the /* that last decl is for IE6. Try removing it, it's hilarious! */ one |
| 10:54 | <Hixie> | i thought i'd gotten rid of that one |
| 10:54 | <yecril71> | Hixie�s theory about fieldset.name does not hold. |
| 10:54 | <yecril71> | The MSDN is correct here. |
| 10:54 | <gsnedders> | I don't see it in <http://www.whatwg.org/specs/web-apps/current-work/header-whatwg>;, but I see it in <http://www.whatwg.org/specs/web-apps/current-work/>; |
| 10:55 | <Hixie> | gsnedders: fixed |
| 10:55 | <yecril71> | So it is not really "already implemented", and it is different from HTML4. |
| 10:55 | gsnedders | heads off |
| 10:57 | <Hixie> | yecril71: do you have a testcase demonstrating the error in the spec? |
| 10:57 | <Hixie> | i'm pretty sure i tested this |
| 10:57 | <Hixie> | but i could be wrong! |
| 10:57 | <yecril71> | Just a minute. |
| 10:58 | <yecril71> | (That is, I have it, but I have to publish it.) |
| 11:00 | <hsivonen> | I think a lot of this mobile "best" practice stuff could go away if Opera Mini had serious competition |
| 11:00 | <hsivonen> | so that vendors of devices that can't host a self-contained browser didn't feel they have to commit to a single vendor if they want a decent browser |
| 11:01 | <Lachy> | unfortunately, working around browser bugs is an essential job that web developers must do for commercial sites. But for web standards, where people reading the spec are expected to use modern browsers, fixing such bugs is an unnecessary hassle |
| 11:01 | <Hixie> | I would say that I think a lot of this mobile "best" practice stuff could go away if Mobile Safari had serious competition. :-) |
| 11:01 | <Lachy> | yecril71, I have to agree with Hixie. I have no sympathy for IE users |
| 11:01 | <Hixie> | not just IE users |
| 11:02 | <Hixie> | users of any browser with pretty fundamental bugs |
| 11:02 | <Lachy> | yeah, all browsers have bugs. But IE is the worst. |
| 11:02 | <Lachy> | it's entirely possible to build a professional website for Firefox, Opera and Safari without using any hacks. But only the most basic sites work in IE without hacks |
| 11:03 | <hsivonen> | which reminds me that Validator.nu has a script error in IE (including 8) |
| 11:10 | <hsivonen> | hmm. the login thing may be a deep rathole |
| 11:14 | <yecril71> | http://www.2a.pl/~ne01026/test.htm |
| 11:14 | <hsivonen> | Hixie: regarding your email "Database section feedback": didn't Nikunj already volunteer? your email makes it look as though you are ignoring that he volunteered. (unless he volunteered only on the condition that he edits *all* the pieces he volunteered for) |
| 11:15 | <Hixie> | i have seen no evidence that he has volunteered other than him actually saying that he has volunteered |
| 11:15 | <yecril71> | (Note that the document is deliberately invalid now) |
| 11:15 | <hsivonen> | Hixie: I think I see what you mean. |
| 11:15 | <yecril71> | (It is supposed to be valid HTML5) |
| 11:16 | <Hixie> | could you rewrite that in JS so i can test it in other browsers? |
| 11:17 | <yecril71> | What for? I do not contend it does not work in other browsers. |
| 11:17 | Hixie | doesn't understand what you are trying to show with that test |
| 11:17 | <yecril71> | That a fieldset is not a form control. |
| 11:17 | <Hixie> | (what's important is compatibility with all browsers, not just IE) |
| 11:18 | <Hixie> | fieldset is not a form control, correct |
| 11:18 | <yecril71> | All browsers, including IE. |
| 11:18 | <yecril71> | But HTML5 says it belongs to form.elements. |
| 11:18 | <Hixie> | the spec doesn't have a concept of "form control", though, so that seems academic |
| 11:18 | <yecril71> | The collection is named HTMLFormControlsCollection. |
| 11:18 | <yecril71> | Or something like that. |
| 11:19 | <yecril71> | That means it bears the concept of a form control. |
| 11:19 | <yecril71> | You have said you had to add this because that is what all browsers do. |
| 11:19 | <yecril71> | I have demonstrated it is not the case. |
| 11:20 | <Hixie> | the collection name is a historical artefact of little importance |
| 11:20 | <yecril71> | With that attitude, HTML5 is likely to become a historical artefact of little importance. |
| 11:20 | <Hixie> | it may be that it is not all browsers but just some browsers, then |
| 11:21 | <Hixie> | i expect one day it will be, yes |
| 11:21 | <yecril71> | I do not think that "some browsers" is a good argument to break logic and backward compatibility. |
| 11:22 | <Hixie> | according to http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E...%3Cform%3E%3Cfieldset%3E%3C%2Ffieldset%3E%3C%2Fform%3E%0A%3Cscript%3Ew%28document.forms[0].elements.length%29%3C%2Fscript%3E |
| 11:22 | <Hixie> | IE, Firefox, and Opera all put <fieldset> in form.elements |
| 11:22 | <yecril71> | I would rather ask those browsers to fix their implementations, because it is a bug. |
| 11:22 | <hsivonen> | Hixie: do I read correctly that the new http auth stuff doesn't ask browsers to change anything in their behavior? |
| 11:23 | <Hixie> | correct |
| 11:23 | <hsivonen> | ok. |
| 11:31 | <Hixie> | zcorpan! |
| 11:31 | <zcorpan> | hey Hixie |
| 11:32 | <Hixie> | now i wish i had said on irc what i wanted to tell you, for i have forgotten it |
| 11:32 | <zcorpan> | :( |
| 11:32 | <Hixie> | oh one was that i invented QUOTA_EXCEEDED_ERR with code 22, and wanted to ask you if you could add it along with codes 1-21 to web dom core |
| 11:33 | <zcorpan> | ok, will do |
| 11:33 | <yecril71> | All right, I give up. |
| 11:33 | <yecril71> | <http://msdn.microsoft.com/en-us/library/ms537449(VS.85).aspx#ctl00_rs1_WikiContent_2_Container>; |
| 11:35 | <Lachy> | I still can't figure out why Pentasis is having such a difficult time comprehending the purpose of the time element, nor why he's suggesting such ridiculous changes. |
| 11:35 | <Lachy> | I guess he's just interested in some kind of theoretical purity, rather than trying to address any serious practical issues |
| 11:35 | <Hixie> | theoretical purity isn't a bad thing in and of itself |
| 11:36 | <Hixie> | if the people who extended html over the years had slightly more concern over theoretical purity, we'd be in a much better state |
| 11:36 | <zcorpan> | Hixie: added |
| 11:36 | <Hixie> | wow that was quick |
| 11:36 | <Hixie> | i need to ask you to do web dom core changes more often |
| 11:36 | <Hixie> | :-D |
| 11:36 | <zcorpan> | :) |
| 11:37 | <Hixie> | did i ask you what the eta was on a fpwd yet? |
| 11:37 | <zcorpan> | not sure but there's no eta yet |
| 11:37 | <Hixie> | k |
| 11:37 | <zcorpan> | i'm trying to get the spec moved to a w3c wg |
| 11:38 | <Hixie> | won't webapps take it? |
| 11:38 | <zcorpan> | haven't approached them yet |
| 11:38 | <Hixie> | oh one of the other things was a webkit bug i came across that was about weird (but compat-required) getElementById() behavior, iirc |
| 11:39 | <Hixie> | i tried cc'ing you but you didn't seem to have an account |
| 11:39 | <Hixie> | i forget which bug now |
| 11:39 | <zcorpan> | i think i'm still using the @hotmail account on b.w.o :S |
| 11:39 | <Lachy> | Hixie, true. But when your theory is suggesting that an element for marking up dates using ISO-8601 isn't adequate because it still can't accurately represent historical dates from centuries ago, rather than just worrying about the use cases it was designed for, then it's being taken too far |
| 11:39 | <zcorpan> | i guess i should change that |
| 11:40 | <hsivonen> | I think we should define input type=date to apply to booking of hotels & transport |
| 11:40 | <Hixie> | Lachy: i think he ended up actually saying the opposite -- that we should limit it further (e.g. not allow 2AD) because that was too historical and wasn't accurate either |
| 11:40 | <hsivonen> | and we should define <time> as a piece for microformats meant for scheduling secular civilian meetings |
| 11:40 | <zcorpan> | is there a use case for <input type=url multiple>? |
| 11:41 | <Lachy> | I've generally found the things he's said to be confusing |
| 11:41 | <zcorpan> | i think validator.nu has such a field doesn't it? |
| 11:41 | <Hixie> | zcorpan: i'm sure one could be invented |
| 11:41 | <Hixie> | whether it's a common enough case to worry about is another question |
| 11:41 | <Hixie> | nobody has asked for it yet |
| 11:41 | <Hixie> | afaik |
| 11:42 | <hsivonen> | for the v.nu use case, <input type=url multiple> would be backwards-incompatible with Opera |
| 11:42 | <hsivonen> | I guess <input type=email multiple> isn't nice for Opera, either |
| 11:42 | <zcorpan> | right |
| 11:43 | <yecril71> | Why are SCRIPT elements not allowed inside TABLE elements? |
| 11:43 | <hsivonen> | yecril71: legacy |
| 11:43 | <Hixie> | and keeping things simple |
| 11:44 | <Lachy> | sure, we could limit it more, but picking cut-off point at the unix epoch 1970-01-01 wouldn't given enough range for people to mark up, e.g. birthdates, and anywhere else would be just arbitrary |
| 11:44 | <yecril71> | Simple for whom? |
| 11:44 | <Hixie> | me |
| 11:44 | <Hixie> | and authors in general |
| 11:44 | <yecril71> | It is not simple that, once I need to produce a part of a table with a script, |
| 11:44 | <hsivonen> | Lachy: I think anything but 1970-01-01 and 0001-01-01 would be arbitrary |
| 11:44 | <Hixie> | Lachy: yeah |
| 11:44 | <yecril71> | I have to produce the whole table. |
| 11:44 | <zcorpan> | hsivonen: but <script>s aren't foster parented, right? |
| 11:45 | <hsivonen> | zcorpan: oh? I don't remember. |
| 11:45 | <Hixie> | yecril71: just use DOM manipulation |
| 11:46 | <yecril71> | (IE7 handles this use case cleanly) |
| 11:46 | <zcorpan> | hsivonen: yep. "A start tag whose tag name is one of: "style", "script"" |
| 11:47 | <hsivonen> | ok |
| 11:47 | <Hixie> | <input type=hidden> is magical too |
| 11:47 | <Hixie> | and <script> needs to be made magical in <select>, which is going to be a pain |
| 11:48 | <yecril71> | That means it should be supported but the document is still nonconforming? |
| 11:48 | <hsivonen> | yecril71: I withdraw what I said about legacy |
| 11:49 | <yecril71> | Why? TABLE elements cannot contain SCRIPT elements directly in HTML4 either. |
| 11:49 | <Hixie> | the restriction is one we inherited from html4 and one we will keep because allowing script in the middle of the table model encourages bad authoring practices (such as using document.write()) |
| 11:50 | <hsivonen> | yecril71: I thought there was a parser legacy issue there. I wasn't referring to validation legacy. |
| 11:52 | <yecril71> | Correct me if I am wrong, but there is no way to ask the document to add more rows to the preceding table, unless that table has an ID. |
| 11:53 | <yecril71> | While it is possible inside. |
| 11:53 | <yecril71> | (supposing I place the SCRIPT right after the TABLE, that is.) |
| 11:54 | <Hixie> | just grab the last table from document.getElementsByTagName('table') |
| 11:54 | <yecril71> | Thanks. |
| 12:01 | <zcorpan> | Hixie: is it https://bugs.webkit.org/show_bug.cgi?id=6006 ? |
| 12:01 | <Hixie> | yes |
| 12:01 | <Hixie> | wow |
| 12:01 | <Hixie> | good call |
| 12:02 | <zcorpan> | first on a search for getelementbyid :) |
| 12:04 | <Hixie> | :-) |
| 12:06 | <zcorpan> | it seems we have lots of bugs saying that getElementById works with name='' |
| 12:06 | <zcorpan> | which we dropped in 9.5 |
| 12:07 | <zcorpan> | and no bugs on it not working with name='', afaict |
| 12:07 | <zcorpan> | also, i think ie8 doesn't look at name='' (in ie8 mode) |
| 12:09 | <Hixie> | i'll trust you to spec something that matches the web and that browsers are willing to converge on |
| 12:09 | <yecril71> | I think if a statement needs an in-transaction callback and an after-transaction callback, that amounts to two callbacks. |
| 12:09 | <Hixie> | i'm just glad it's not my problem for once :-) |
| 12:09 | <yecril71> | So the most straightforward thing to do would be to allow two as required. |
| 12:10 | <yecril71> | You could also provide for a callback to figure out whether the transaction has finished |
| 12:10 | <yecril71> | and report that it needs to be called afterwards if not. |
| 12:11 | Hixie | looks at feedback from anne about %-encoding in name="" attributes and #fragids, and decides to call it a night |
| 14:46 | <hsivonen> | hmm. interesting. Gecko and HTML5 deal with noframes and noembed in very different ways |
| 14:46 | <hsivonen> | in terms of implementation |
| 14:46 | <hsivonen> | not necessarily from the POV of pages |
| 14:49 | <zcorpan> | hsivonen: how are they different? |
| 14:49 | <hsivonen> | Gecko keeps track of a nesting depth in noXXX elements and turns off <base> and form control handling when depth > 0 |
| 14:50 | <hsivonen> | HTML5 treats noXXX as CDATA elements |
| 14:51 | <zcorpan> | hmm, my copy of firefox seems to insert a single text node in <noembed> -- not elements |
| 14:52 | <hsivonen> | zcorpan: it's possible that the tokenizer has changed and the depth tracking is now dead code |
| 14:52 | <hsivonen> | I was looking at the tree builder code |
| 14:52 | <zcorpan> | hsivonen: yeah, i remember dbaron saying there was similar dead code for <iframe> a while back |
| 14:53 | <zcorpan> | that disabled scripts or something |
| 14:53 | <hsivonen> | I should have that the tree builder code looks like that--not that Firefox does it :-) |
| 14:53 | <hsivonen> | can't really trust the looks of the Gecko parser code |
| 14:54 | <zcorpan> | is that code used for xhtml? |
| 14:54 | <hsivonen> | no |
| 15:00 | <Lachy> | if it's dead code, whats the point of keeping it around? Is it just that no-one has thought to remove it yet, and verify that it really is dead? |
| 15:05 | <hsivonen> | Lachy: most likely it's dead and forgotten and now no one wants to touch the parser more than absolutely necessary |
| 15:09 | <Lachy> | ok. I suppose it won't matter too much since I assume they'll be replacing the parser entirely with a new HTML5 parser soon enough |
| 15:09 | <hsivonen> | hopefully :-) |
| 15:41 | <zcorpan> | hey punctation is allowed in encoding declarations |
| 15:41 | <zcorpan> | you can make smileys out of encoding names |
| 15:42 | <zcorpan> | ~u_^t^_f8 |
| 15:45 | <Lachy> | zcorpan, I can't see how that example you gave can be seen as a smiley? |
| 15:48 | <zcorpan> | Lachy: dunno, come up with something better :) |
| 15:52 | <zcorpan> | hey you could even have multiline ascii art |
| 15:53 | hsivonen | can't wait to debug input with multiline ascii art charsets |
| 15:54 | <hsivonen> | w00t. the C++ version of the HTML5 parser *finally* links all the way |
| 15:54 | <Dashiva> | Is newline allowed, though? |
| 15:54 | <hsivonen> | any language that doesn't have C++-style linkage must give a huge productivity boost compared to C++ |
| 15:55 | <Lachy> | zcorpan, where in the spec does it say punctation is allowed? |
| 15:55 | <Lachy> | is it that they're ignored for the parsing requirements, or that they're considered conforming too? |
| 15:56 | <zcorpan> | "The value must be a valid character encoding name, and must be the preferred name for that encoding." |
| 15:57 | <zcorpan> | hsivonen: validator.nu doesn't complain about punctation |
| 15:58 | <Lachy> | zcorpan, how do you interpret that as allowing punctuation? |
| 15:58 | <hsivonen> | zcorpan: thanks. I filed http://bugzilla.validator.nu/show_bug.cgi?id=337 |
| 15:58 | <zcorpan> | Lachy: i don't :) |
| 15:58 | <Lachy> | wtf? You said "punctation is allowed in encoding declarations" |
| 15:58 | <zcorpan> | yeah, i was mistaken |
| 15:58 | <zcorpan> | i was just playing around in v.nu |
| 15:58 | <Lachy> | oh |
| 15:59 | <Philip`> | yecril71: The thread around http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-June/014984.html discusses the IE heading CSS bug, and that post suggests a simple workaround, but I guess Hixie cares more about the theoretical purity of the spec's markup than about its impact on users :-) |
| 17:41 | <BenMillard> | Lachy, I sometimes manage to make graphical websites which support Fx2, Fx3, O9, most recent Safari, IE6 and IE7 without hacks (re: http://krijnhoetmer.nl/irc-logs/whatwg/20081126#l-395) |
| 17:41 | <BenMillard> | usually, the show-stoppers aren't really CSS problems, it's fundamental breakage in the rendering engine :) |
| 17:42 | Philip` | can't even make non-graphical sites without finding browser bugs :-( |
| 17:42 | <BenMillard> | usually there are multiple ways of getting the same visual effect, like yecril71 points out |
| 17:43 | <BenMillard> | and when the job has a requirement that it *must* look correct in that set of browsers before your client pays you, well, you learn to compromise :) |
| 17:46 | <BenMillard> | yecril71, in applications on Windows, the equivalent of <fieldset> is called Frame (at least in VB6) and you add it to a form (aka window) as a control (aka a form control) |
| 17:46 | <BenMillard> | more specifically, it's a "container control" along with PictureBox, TabStrip and suchlike |
| 17:49 | <BenMillard> | krijnh, linkification stopped short by [ character: http://krijnhoetmer.nl/irc-logs/whatwg/20081126#l-424 |
| 17:57 | <BenMillard> | Philip`, using position:relative on elements with negative margins is how I thought it was supposed to work, because I'm so used to doing that for IE :P |
| 17:58 | <BenMillard> | sometimes I use a negative top or left value instead of negative margin, due to margin bugs |
| 18:11 | Philip` | gets down to 3.6MB for an animated visualisation of the internal links in every 5th revision of the HTML 5 spec since its history began, which doesn't seem too bad |
| 18:11 | <Philip`> | BenMillard: Why does position:relative help in those cases? |
| 18:15 | gsnedders | wonders if that is danbri in one of his TPAC photos |
| 18:16 | <gsnedders> | No, it isn't. |
| 18:22 | <BenMillard> | Philip`, various strange things start working properly with position:relative in IE...often inexplicably :) |
| 18:22 | <BenMillard> | (like graphical bullets on list items in semi-arbitrary conditions) |
| 18:46 | <hsivonen> | do I read the html5lib correctly when I think it sanizes by discarding tokens before the tree builder? |
| 18:46 | <hsivonen> | s/html5lib/html5lib source/ |
| 18:50 | <jgraham> | hsivonen: Yes |
| 18:51 | <hsivonen> | jgraham: does it discard script content? |
| 18:51 | <jgraham> | hsivonen: I believe so |
| 18:52 | <jgraham> | (but I guess there may be bugs) |
| 18:55 | <hsivonen> | It seems that the dominant design of HTML sanitizers is to throw stuff away between the tokenizer and the tree builder |
| 18:56 | <hsivonen> | Hixie: looks like different rules are called for here compared to the infoset coercion stuff |
| 18:56 | <hsivonen> | (not to suggest that HTML5 should prescribe the rules, but anyway) |
| 18:57 | <sayrer> | hsivonen, have you tested the new IE8 method? |
| 18:58 | <hsivonen> | sayrer: nope. What's the new IE8 method? |
| 18:58 | <sayrer> | hsivonen, toSafeHTML or some such |
| 18:58 | <sayrer> | hsivonen, yeah, that's it |
| 19:00 | <hsivonen> | "Update 11/20/08: changed reference to toSafeHTML to toStaticHTML" says IE blog |
| 19:01 | <hsivonen> | hmm. string to string method |
| 19:02 | <hsivonen> | sayrer: this is mail&news stuff, isn't it: http://mxr.mozilla.org/mozilla-central/source/content/base/src/mozSanitizingSerializer.cpp |
| 19:02 | <sayrer> | hsivonen, yeah. I decided I couldn't use that, way back when. Don't remember why. |
| 19:02 | <hsivonen> | sayrer: ok |
| 19:03 | <hsivonen> | I should test toStaticHTML to see what it actually does |
| 19:03 | <hsivonen> | thanks |
| 19:09 | <gsnedders> | http://www.flickr.com/photos/gsnedders/3061950334/ |
| 19:09 | <gsnedders> | http://www.flickr.com/photos/gsnedders/3061106047/ |
| 19:09 | <gsnedders> | who are those someones? |
| 19:09 | <hsivonen> | gsnedders: in 3061950334 Felix Sasaki |
| 19:09 | <hsivonen> | gsnedders: in 3061106047 Steve Zilles |
| 19:17 | <sayrer> | hsivonen, I may have run screaming from http://mxr.mozilla.org/mozilla-central/source/content/base/src/mozSanitizingSerializer.cpp#474 |
| 19:18 | <sayrer> | and also the pref parsing |
| 19:19 | <hsivonen> | sayrer: seems to be the wrong way round... |
| 19:32 | <gsnedders> | hsivonen: ah, thx |
| 20:11 | <hsivonen> | http://groups.google.com/group/mozilla.dev.planning/msg/f2dd45413cc68413 |
| 20:16 | <hsivonen> | Hixie: am reading the spec correctly that it's OK to have an event loop spin between document.close() and the tokenizer emitting the EOF? |
| 20:17 | gsnedders | wonders if he gets a VPS how quickly he'll screw it up |
| 20:18 | <gsnedders> | hsivonen: that is lovely. |
| 20:43 | <Philip`> | gsnedders: You can always just reinstall it once you break everything |
| 20:43 | <gsnedders> | Philip`: :P |
| 20:44 | Philip` | discovered Ubuntu has "ufw", which makes firewall configuration actually sane - you say stuff like "ufw allow 80/tcp" and it does what you want, and you don't have to even know what iptables are |
| 20:49 | <gsnedders> | wow |
| 21:22 | <Hixie> | hsivonen: not only is it ok, it is required, because the tokeniser only emits stuff as part of the event loop |
| 21:26 | <hsivonen> | Hixie: doesn't the tokenizer emit non-EOF tokens immediately on first-level document.write()? |
| 21:26 | <Hixie> | yeah but that is still originally part of an event loop step |
| 21:26 | <hsivonen> | Hixie: but it's good that a spin is OK with document.close() |
| 21:27 | <hsivonen> | ok |
| 21:57 | <krijnh> | BenMillard: fixed, thanks |
| 21:59 | <Dashiva> | That was a short-lived feature (@html-auth) |
| 22:04 | Philip` | apologises for helping kill it |
| 22:07 | <Philip`> | (Actually I'm blame Julian, for originally suggesting that there could be a security issue) |
| 22:08 | <Dashiva> | Jonas would've picked up the slack anyhow, it seems :) |
| 22:08 | <sicking> | off with its head! |
| 22:11 | <Dashiva> | sicking: Do you have a secret new proposal that will rock our socks? |
| 22:11 | <sicking> | nothing secret |
| 22:11 | <sicking> | i've argued for something like OpenID for a while, just not very heavily |
| 22:12 | <sicking> | OpenID, the way it looks like now, with all its redirects and stuff, is no good though |
| 22:12 | <sicking> | but there a lot that can be done if we build it into the browser |
| 22:12 | <sicking> | basically we need something like microsofts CardSpace, but as a more open platform |
| 22:14 | <Dashiva> | Does cardspace avoid the "phishing enabling" of current openid? |
| 22:16 | <sicking> | that is my understanding |
| 22:16 | <sayrer> | sicking, how so? |
| 22:16 | <sicking> | however, i have not heard what all the complaints about neither cardspace nor openid are, so it's entirely possible that neither of them are very close to what we need |
| 22:17 | <sicking> | sayrer, you don't type a password, you just click on an image to choose which identity to use |
| 22:17 | <sayrer> | that is good |
| 22:17 | <sayrer> | fwiw, I did like the idea of using the 401 body for this |
| 22:17 | <hsivonen> | sicking: I think it would need to degrade gracefully into the current OpenID experience in browsers that don't implement the future thing |
| 22:17 | <Lachy> | Philip`, I find it difficult to believe that anyone would be stupid enough to introduce a XSS bug into a 401 page, especially because it's effectivly saying you need to log in before you can do anything |
| 22:17 | <sayrer> | only Safari is broken w.r.t. that extension point |
| 22:18 | <sicking> | hsivonen, it needs to degrade into something for sure |
| 22:18 | <hsivonen> | sicking: so in that sense, seeking to put the hook into the OpenID ID provider code might work |
| 22:18 | <Lachy> | and the XSS attack you outlined would need so many different bugs to occur in just the right way, it seems highly unlikely |
| 22:18 | <hsivonen> | but that would mean users would have to enter a URI into a field still |
| 22:18 | <hsivonen> | unless the field can be reliably autocompleted by the browser, too |
| 22:18 | <sayrer> | I had the idea that the 401 body should be the non-existant notion of svg static |
| 22:19 | <sayrer> | so browsers can create a difficult to simulte UI |
| 22:19 | <sayrer> | and show a little bit of branding next to it |
| 22:19 | <hsivonen> | what's svg static? |
| 22:20 | <sayrer> | svg with scripting, animation, fonts, etc |
| 22:20 | <sayrer> | er |
| 22:20 | <sayrer> | witout |
| 22:20 | <sayrer> | without |
| 22:20 | <hsivonen> | ah |
| 22:20 | <sayrer> | there is no subset that matches that |
| 22:20 | <sayrer> | but I'm thinking full-screen shadowed / UI box |
| 22:20 | <sayrer> | I guess flash or quicktime might be coerced |
| 22:20 | <sayrer> | to do that |
| 22:20 | <sayrer> | but it would be much harder |
| 22:21 | <Lachy> | although I'm still glad the www-authenticate feature was removed, since it seemed quite useless in practice for all but a very niche market |
| 22:22 | <Philip`> | Lachy: It doesn't seem implausible that someone would have e.g. login.php?return=... which gives you the login form with a <a href="$return">Go back</a> and returns 401 and WWW-Authenticate HTML because they want to tell bots to log in that way, and introduce the XSS hole that way |
| 22:22 | <Philip`> | Lachy: and I don't see what bugs the attack needs, other than the XSS one |
| 22:23 | <Philip`> | Lachy: Also, you shouldn't underestimate people's stupidity :-p |
| 22:25 | <Lachy> | it requires the bot to access the page via a URL which exploits the XSS attacks |
| 22:26 | <Philip`> | Bots follow links, and it's trivial to put a link onto most people's sites |
| 22:26 | <Lachy> | that may depend on the purpose of the bot, and where it was following links from |
| 22:26 | <Philip`> | (via blog comments, or referrer logs, or whatever) |
| 22:26 | <Philip`> | The purpose of the bot is to follow all the links it can find on the site :-) |
| 22:27 | <sayrer> | could just turn of scripts on 401 pages |
| 22:27 | <Philip`> | sayrer: There aren't any scripts involved here |
| 22:27 | <sayrer> | oh I see |
| 22:28 | <Lachy> | I suppose a such a link could occur on the site itself if it allowed user generated content of some kind |
| 22:28 | <Lachy> | and only used the 401 to prevent access to member areas |
| 22:30 | <Lachy> | it may not be a new problem though. If there are bots that perform this kind of log in already, by being manually configured with the form name, they would be vulnerable to the same attack |
| 22:30 | <Lachy> | although without the www-authenticate header advertising that, it's less likely |
| 22:31 | <Lachy> | but the same attack could be used against users by getting them to follow the link |
| 22:33 | <Philip`> | It's not a problem unique to WWW-Authenticate, but WWW-Authenticate was designed in a way that encourages behaviour that would encounter that problem |
| 22:51 | <Hixie> | i hven't removed it yet btw |
| 22:52 | <Hixie> | somewhat waiting for someone to take it over or for julian to say he doesn't want it or to propose some other alternative first |
| 22:55 | <Hixie> | we seem to be getting close to the point (or maybe past the point) where i need to respond to this <i>/<small> thread |
| 22:58 | <KrocCamen> | i/small? I use those, what’s going on with them? |
| 22:59 | <Hixie> | nothing especially |
| 22:59 | <Hixie> | but there's been a thread about them for some time now |
| 22:59 | <Hixie> | which is starting to get very "meta" |
| 23:00 | <KrocCamen> | I use i as a comment marker in code spans (so that in RSS readers it shows up as italics, but has no particular meaning in the HTML5 source). Small I use either inside a paragraph—as normal—but also as a paragraph iteself (since you can use other elements instead of P where they are better suited) |
| 23:07 | <KrocCamen> | How all the HTML4 elements and the new HTML5 sectioning elements are at the moment is just how I like it. My one and single miff is the removal of type on OL/UL. I need that for my site. I’ve no classes and my article text uses links to a footnote list - which are in alpha. Since the article text has to use the real letters to link to the footnote, it’s a structural thing, not merely a style. |
| 23:09 | <Hixie> | css should support (and will support) substituting in the footnote number in the appropriate place |
| 23:09 | <sicking> | Hixie, got a sec to talk about baseURIs and security contexts of |new Worker|? |
| 23:09 | <Hixie> | sure |
| 23:10 | <Hixie> | the spec says to use the origin of the worker's script, and limits the worker's script to same-origin of the creator |
| 23:10 | <Hixie> | which makes it somewhat simple and allows us flexibility to extend it in future in different directions |
| 23:10 | <Hixie> | depending on what authors want |
| 23:10 | <sicking> | Hixie, so basically, the way that |new Worker| works is that it establishes a new security context for the new worker. |
| 23:11 | <Hixie> | not sure what a "security context" is, but it does create a new scripting context, yes |
| 23:11 | <sicking> | well, every page has a 'principal'. i.e. a something that we do all neccessary security checks against |
| 23:12 | <Hixie> | i think the spec just uses the origin for that |
| 23:12 | <Hixie> | but that's an implementation detail |
| 23:12 | <Hixie> | continue |
| 23:12 | <sicking> | when setting up a new worker that means that we have to set up a new principal |
| 23:13 | <sicking> | another way to look at it is that it sets up a new browsing context i guess |
| 23:13 | <sicking> | this makes a lot of sense to me for shared workers, since aren't coupled with any one browsing context |
| 23:14 | <sicking> | but i'm less sure that makes sense for a dedicated worker, which is pretty tightly coupled with a single 'normal' browsing context |
| 23:16 | <Hixie> | the way the spec defines it side-steps this problem |
| 23:16 | <Hixie> | iirc |
| 23:16 | <sicking> | the end result is that you have to apply a same-origin restriction on |new Worker| |
| 23:17 | <sicking> | and that uris are resolved agasint the uri of the worker, rather than the uri of the opening page |
| 23:17 | <Hixie> | yes |
| 23:17 | <sicking> | neither of which i'm sure are desireable for dedicated workers |
| 23:18 | <Hixie> | oh we definitely want the base URI to be the base URI of the worker, otherwise the behavior of hte worker changes based on where it is called |
| 23:18 | <Hixie> | but we invented lcoation.resolveURL() to address that |
| 23:18 | <sicking> | that's what you have with <script> today though, and it doesn't seem to be a problem |
| 23:19 | <Hixie> | it's only not a problem because people have to write all their shared scripts using absolute URLs everywhere |
| 23:19 | <Hixie> | otherwise they wouldn't work |
| 23:20 | <Hixie> | anyway as mentioned earlier, the limit on same-origin workers is intentional. it lets us ship this, then work out what people want to do with non-same-origin dedicated workers -- have them run in their original origin, AC protected; have them run on the caller's origin, or something else |
| 23:22 | <sicking> | well, that's definitely what we'll have to do as a consequence of workers running with the security context of their own uri |
| 23:22 | <sicking> | if we didn't have do that we'd be in the same situation as <script> and .importScripts |
| 23:23 | <Hixie> | <script> is a mess, we don't want to copy that :-) |
| 23:23 | <sicking> | .importScripts copies that |
| 23:23 | <Hixie> | copies what? |
| 23:24 | <Hixie> | importScript does same-origin checks |
| 23:24 | <sicking> | really? |
| 23:24 | <sicking> | why? |
| 23:24 | <Hixie> | yes, you complained about it once |
| 23:24 | <sicking> | i thought it got changed |
| 23:24 | <Hixie> | doesn't look like it |
| 23:24 | <sicking> | ugh |
| 23:24 | <sicking> | why do same-origin checks there? |
| 23:24 | <Hixie> | did i respond to your complaint? |
| 23:25 | <sicking> | yes, don't remember what you said though |
| 23:25 | <Hixie> | me either |
| 23:26 | <sicking> | so why have same-origin restrictions on importScripts? |
| 23:26 | Hixie | looks in the archives |
| 23:27 | <Hixie> | my reply was: |
| 23:27 | <Hixie> | I don't recall the precise reason, but I seem to recall concern over |
| 23:27 | <Hixie> | specific attack vectors are what caused us to restrict this. |
| 23:27 | <Hixie> | i guess we can change it |
| 23:28 | <sicking> | it seems like behaving exactly like <script> won't cause any new attack vectors |
| 23:28 | <Hixie> | well like i said, <script> is hardly what we want to be copying |
| 23:29 | <Hixie> | are we not concerned about people faking a browsing context environment and then calling someone's cookie-protected JSON? |
| 23:30 | <sicking> | sure, the same way that it can happen for <script> |
| 23:30 | <Hixie> | don't we want to stop it for <script> too? |
| 23:30 | <Hixie> | in due course? |
| 23:30 | <sicking> | yeah, but that's never going to happen |
| 23:30 | <Hixie> | seems bad to introduce new ways to do things we know are bad |
| 23:31 | <sicking> | if we are going to drive it through for <script>, the extra amount of work involved in driving it through for .importScripts is probably smaller than can be measured |
| 23:31 | <Hixie> | the well i checkedin the change |
| 23:32 | <sicking> | cool |
| 23:32 | <sicking> | so i'm still not convinced on |new Worker| |
| 23:32 | <sicking> | but i know that me and aaron has different mental models there |
| 23:33 | <sicking> | as in, is |new Worker| simply an out-of-thread <script>? Or is it more like an <iframe> |
| 23:33 | <Hixie> | well right now the spec takes the conservative approach that is compatible with both mental models, allowing us to pick either one later, based on author feedback |
| 23:33 | <Hixie> | which i think is probably a good approach for now |
| 23:33 | <sicking> | well, once we set the baseURI we can't change that, so i suspect whatever we choose now we'll stick with forever |
| 23:34 | <Hixie> | i don't see how it is dependent on baseURI |
| 23:34 | <sicking> | i think the baseURI will go hand in hand with the security context |
| 23:35 | <Hixie> | well in that case i definitely would want to do the model we hve now |
| 23:35 | <Hixie> | that <script> has the document's baseURI is something we fixed with CSS and we should definitely fix it here too |
| 23:35 | <Hixie> | relative URLs shouldn't change meaning based on who is using them |
| 23:35 | <Hixie> | that's just wacky |
| 23:35 | <Hixie> | based on who is referring to the document that contains them, i should say |
| 23:36 | <sicking> | depends on what you are doing. Any time you pass a uri across baseURI borders you have pain |
| 23:36 | <sicking> | since you can't use relative URIs any more |
| 23:37 | <sicking> | so that means that you have pain any time you pass a URI through postMessage |
| 23:38 | <Hixie> | that's why we added location.resolveURL() |
| 23:39 | <sicking> | right, it doesn't change the fact that you have pain through |
| 23:40 | <sicking> | resolving relative URIs is something developers aren't used to |
| 23:40 | <sicking> | (since it has been largely impossible before) |
| 23:45 | <Hixie> | yeah, you're trading one pain for another |
| 23:45 | <Hixie> | but one of them is predictable :-) |
| 23:45 | <sicking> | the only time you have pain today is when you are fetching a resource relative to the script file |
| 23:45 | <sicking> | (today == in windows) |
| 23:46 | <sicking> | but not when fetching resources relative to the document |
| 23:46 | <Hixie> | right, and the only pain we're adding is when you're passing a relative url around |
| 23:46 | <sicking> | not sure which is most common, but i'd imagine most data would live close to the document |
| 23:47 | <sicking> | well, most uris are relative i'd think |
| 23:47 | <Hixie> | i don't think most workers are going to involve passing urls around frankly |
| 23:48 | <sicking> | any time you want to use XHR |
| 23:48 | <sicking> | granted, that's going to be an extra common case in our impl since that is the only API we have avaialble (we won't have localStorage support in FF3.1) |
| 23:48 | <Hixie> | nah, most of the time the script will be hard-coded to fetch particular files |
| 23:49 | <sicking> | oh? |
| 23:49 | <Hixie> | i'd expect so |
| 23:49 | <Hixie> | why would you put the logic in the main document and just offload the loading? it doesn't gain you anything |
| 23:49 | <Hixie> | you could just as easily do the loading in the main document |
| 23:49 | <sicking> | loading+processing |
| 23:50 | <sicking> | the whole point with dedicated workers is that the processing is heavy |
| 23:50 | <sicking> | so unless you have the data available inline in the main document you're probably going to want to fetch it using XHR |
| 23:51 | <Hixie> | right but when do you do laoding and processing without knowing what you'll be loading? |
| 23:51 | <sicking> | which of course you could do on the main thread and then pass it off to the worker |
| 23:53 | <sicking> | a parsing/processing library wouldn't know what to parse/process until given the data |
| 23:54 | <sicking> | the strongest argument that i can think of for using the securitycontext/baseURI of the script file is that that is what we'll have to do for shared workers |
| 23:54 | <Hixie> | most of the time you'll be doing something like "fetch the contacts list and keep me updated as to progress" or stuff like that, as far as i can tell |
| 23:55 | <sicking> | in a shared worker I agree |
| 23:55 | <sicking> | but why would you do that in a dedicated worker? |
| 23:55 | <sicking> | rather than just doing it on the main thread |
| 23:56 | <Hixie> | so that you can use sync xhr, stuff like that |
| 23:56 | <sicking> | "stuff like that"? |
| 23:56 | <Hixie> | not yielding |
| 23:56 | <Hixie> | workers are going to be mostly used just because they're hugely convenient instead of having to keep worrying about other scripts |
| 23:57 | <sicking> | but if all you are doing is pulling down some light-weight file, you're going to have to jump through as many hoops to offload to a worker thread, as you would have to jump through using async XHR on the main thread |
| 23:58 | <Hixie> | for the contacts case, i would imagine the worker would be refetching the file regularly, doing some pretty complex processing, and just posting change notifications over |
| 23:58 | <Hixie> | that's a lot of work |