| 00:27 | <TabAtkins> | Hixie: Is this better (for :read-only) http://dev.w3.org/csswg/selectors4/#rw-pseudos |
| 01:04 | <Hixie> | TabAtkins: so all elements match one or the other? |
| 01:04 | <Hixie> | TabAtkins: what should type=radio match? it's neither user-alterable, nor read-only... |
| 01:05 | <Hixie> | TabAtkins: (also if you could make user-alterable some sort of obvious hook, e.g. give it an ID and make it italics or bold or something (<dfn>), that'd be ideal) |
| 01:07 | <othermaciej> | Hixie: I'm thinking about implementing srcset and I have a question about the spec |
| 01:07 | <Hixie> | othermaciej: shoot |
| 01:07 | <othermaciej> | (since I actually have free time to code this weekend) |
| 01:08 | <othermaciej> | ok, if an image has both src and srcset set, and src appears first textually |
| 01:08 | <Hixie> | (the order doesn't matter) |
| 01:08 | <othermaciej> | if the parser treats this as the src attribute being added and then the srcset attribute being added |
| 01:08 | <Hixie> | (attribute order never matters) |
| 01:08 | <othermaciej> | then the obvious consequence is that the load for the src resource will be initiated first |
| 01:09 | <Hixie> | the HTML parser is defined as adding all the attributes simultaneously |
| 01:09 | <othermaciej> | is that wrong? |
| 01:09 | <othermaciej> | ok |
| 01:10 | <Hixie> | hence the "or both" in: "A user agent that obtains images immediately must synchronously update the image data of an img element whenever that element is created with a src attribute, a srcset attribute, or both." |
| 01:16 | <othermaciej> | thanks |
| 01:19 | <othermaciej> | Hixie: I think WebKit probably has quite a few bugs in cases where that matters |
| 01:19 | <othermaciej> | Hixie: hmm, on second thought, maybe not |
| 01:19 | <othermaciej> | sorry for the noise |
| 01:20 | <othermaciej> | it looks like we set them all, then process one at a time, but each attribute when processed checks if the relevant others have been set |
| 02:39 | <othermaciej> | man, if building wasn't so slow I'd be done implementing srcset by now (at least the subset handling resolution descriptors only) |
| 03:02 | <Hixie> | othermaciej: yeah, i've actually seen cases of browsers having bugs due to the attribute order mattering in practice |
| 03:02 | <Hixie> | othermaciej: surprisingly few, all things considered |
| 03:02 | <othermaciej> | I think I misinterpreted our code (though I certainly wouldn't promise we are bug-free in this area) |
| 03:10 | <TabAtkins> | Hixie: Yeah, it's either/or. This was based off the HTML definition. ^_^ |
| 03:11 | <TabAtkins> | type=radio I'd consider user-alterable. You can alter the checkedness, which is *like* it's content. |
| 03:32 | <cabanier1> | hixie: ping |
| 03:33 | <cabanier1> | I saw that you replace 'any' with a union in the Canvas spec |
| 03:35 | <cabanier1> | I think that that will change the behavior |
| 03:38 | <Hixie> | TabAtkins: html's was based on css' old one, that's why i asked fantasai to change it :-) there's some bug about it |
| 03:38 | <Hixie> | cabanier1: sounds plausible |
| 03:38 | <Hixie> | cabanier1: which change in particular? |
| 03:39 | <cabanier1> | [e] (0) Clean up some IDLs that use 'any' to specify the exact type instead, and clean up some surrounding markup |
| 03:40 | <cabanier1> | Fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=17952 |
| 03:40 | <cabanier1> | Affected topics: Canvas, DOM APIs, Microdata |
| 03:40 | <cabanier1> | git-svn-id: http://svn.whatwg.org/webapps@7260 340c8d12-0b0e-0410-8428-c7bf67bfef74 |
| 03:40 | <Hixie> | what behaviour would it change? |
| 03:41 | <cabanier1> | if you pass it something that can't be converted to a string, you will get a type error. |
| 03:41 | <cabanier1> | while it should ignore it instead |
| 03:41 | <Hixie> | what can't get converted to string? |
| 03:42 | <cabanier1> | the argument you pass to strokestyle/fillstyle |
| 03:42 | <Hixie> | do you have a concrete example of some code that would change behaviour? |
| 03:42 | <Hixie> | sorry i'm having trouble understanding |
| 03:44 | <cabanier1> | let's say you pass in an object that implements its own 'tostring' method that returns a csscolor |
| 03:44 | <cabanier1> | with your change, you can pass in that object and it will be accepted |
| 03:45 | <Hixie> | like context.fillStyle = { toString: function () { return 'blue' } }; ? |
| 03:45 | <cabanier1> | yes |
| 03:45 | <Hixie> | yeah, that would have been ignored before but is now treated properly, right? |
| 03:45 | <cabanier1> | the wording doesn't allow that |
| 03:46 | <cabanier1> | that's true |
| 03:46 | <cabanier1> | I guess the prose should change |
| 03:46 | <cabanier1> | and we should try if it is allowed |
| 03:46 | <Hixie> | what prose? it all looks right to me... |
| 03:47 | <cabanier1> | "The style can be either a string containing a CSS color, or a http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasgradient or http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvaspattern object" |
| 03:48 | <Hixie> | oh the non-normative text |
| 03:48 | <Hixie> | yeah i guess the next sentence is wrong, huh |
| 03:48 | <Hixie> | oh, no |
| 03:48 | <Hixie> | it's still true |
| 03:49 | <Hixie> | because strings that don't parse as css colors are still ignored |
| 03:49 | <cabanier1> | I'm still trying to understand the WedIDL stuff... |
| 03:49 | <cabanier1> | yes. That's true |
| 03:49 | <cabanier1> | so, you can set an object. But when you look at the value, you would get a string back |
| 03:49 | <Hixie> | i'm assuming "you" in those two sentences refer to different people |
| 03:50 | <cabanier1> | correct |
| 03:50 | <Hixie> | if you mean that this: context.fillStyle = { toString: function () { return 'blue' } }; ...would result in the function defined in the canvas prose being handed a string, that's my understanding. |
| 03:50 | <Hixie> | (well, setter, not function) |
| 03:52 | <cabanier1> | as long as people don't expect this to work: var mycolor="…"; context.fillStyle = { toString: function () { return mycolor; } }; ... |
| 03:52 | <cabanier1> | canvaspattern and canvasgradient allow that |
| 03:52 | <Hixie> | why would that not work? |
| 03:52 | <cabanier1> | "When set to a http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvaspattern or http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasgradient object, the assignment is http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live, meaning that changes made to the object after the assignment do affect subsequent stroking or filling of sh |
| 03:52 | <Hixie> | oh you mean, dynamically |
| 03:52 | <Hixie> | yeah |
| 03:53 | <Hixie> | it'll work, it'll just set the fillStyle to whatever mycolor's value is at setting time |
| 03:53 | <cabanier1> | and it won't be live |
| 03:53 | <cabanier1> | yes |
| 03:54 | <cabanier1> | do you think that needs to be written down somehow? |
| 03:55 | <Hixie> | well it's unambiguously required by the webidl spec |
| 03:55 | <Hixie> | and it seems like a really esoteric detail to put in non-normative prose |
| 03:56 | <cabanier1> | I agree |
| 03:57 | <cabanier1> | I tried "ctx.fillStyle={ toString: function () { return 'blue' } };" |
| 03:57 | <cabanier1> | and the fillstyle is black |
| 04:02 | <cabanier1> | same on FireFox, Safari and Chrome... |
| 04:04 | <cabanier1> | If you have a moment, I think "If x0 = x1 and y0 = y1, then the linear gradient must paint nothing." and "If x0 = x1 and y0 = y1 and r0 = r1, then the radial gradient must paint nothing." in the spec should change. |
| 04:04 | <cabanier1> | The gradient should just become a line or a filled circle... |
| 04:05 | <cabanier1> | same with color stops at the same offsets |
| 04:08 | <Hixie> | file a bug :-) |
| 04:08 | <Hixie> | (or mail the list, either way it ends up on my radar) |
| 04:10 | <Hixie> | (whatwg.org/newbug and whatwg⊙wo respectively) |
| 05:52 | <cabanier1> | OK |
| 05:52 | <cabanier1> | I will file a bug on both issues :-P |
| 08:07 | <Calthropstu> | hi |
| 08:09 | <Calthropstu> | I have a question... if I use say html4 or xhtml doc type statements will I still be able to use html5 tags? |
| 08:11 | <deane> | Calthropstu: Hi. Yes you can AFAIK, but, it wont validate. |
| 08:13 | <deane> | Calthropstu: Just use <!DOCTYPE html> Why would you want to use old doctypes? |
| 08:13 | <Calthropstu> | Im dont |
| 08:13 | <Calthropstu> | *I dont |
| 08:14 | <matjas> | annevk (assuming you read the logs): could you perhaps chime in here? https://bugs.webkit.org/show_bug.cgi?id=17352 |
| 08:15 | <Calthropstu> | I'm being considered for a position and when I looked at their work I noticed their website is using a mishmash of xhtml1.0 strict, xhtml 1.1 strict, and html4 transitional |
| 08:15 | <Calthropstu> | and the biggest requirment is html 5 |
| 08:16 | <deane> | Calthropstu: OIC. Sorry to jump to the wrong conclusion. |
| 08:16 | <Ms2ger> | Calthropstu, so, doctypes basically don't do anything |
| 08:16 | <Calthropstu> | they do |
| 08:16 | <Ms2ger> | Calthropstu, except for standards/quirks mode |
| 08:16 | <Ms2ger> | And some more modes in IE |
| 08:17 | <Ms2ger> | To answer your question, yes, you can use new HTML features regardless of doctype |
| 08:17 | <Calthropstu> | well I do know if you dont have 1 at all the whole thing goes nuts |
| 08:18 | <Ms2ger> | Right |
| 08:18 | <Ms2ger> | Only in IE, though; other browsers will still support those features |
| 08:18 | <Calthropstu> | not exactly... because it also starts treating css wrong |
| 08:19 | <deane> | A good resource -> http://hsivonen.iki.fi/doctype/ |
| 08:19 | <Calthropstu> | Ive had that issue as recently as may |
| 08:19 | <Ms2ger> | Calthropstu, I'd advise to just search&replace their doctypes, it's not going to break anything |
| 08:20 | <Ms2ger> | Unless they rely on quirks-mode differences |
| 08:20 | <Calthropstu> | well I would if I already had the position :-) |
| 08:20 | <Ms2ger> | Any of the doctypes here: http://www.whatwg.org/html/#obsolete-permitted-doctype-string are fine too, fwiw |
| 08:21 | <Calthropstu> | ok |
| 08:48 | <deane> | Calthropstu: Good luck with the job. |
| 08:59 | <Calthropstu> | thx |
| 09:00 | <Calthropstu> | my first resume submittal did not specify html5 so I have to resubmit it on tuesday |
| 09:01 | <Calthropstu> | I just figured "html" would cover ALL forms of html and CSS would cover all forms of CSS but they specifically demand CSS3 and HTML5 |
| 09:01 | <deane> | Yeah, I guess then it's best to be specific. |
| 11:12 | <jesusruiz> | hi, group |
| 18:11 | <gsnedders> | Anyone got tests for meta pre-parsing? |
| 18:12 | <Ms2ger> | Not me |
| 18:12 | <gsnedders> | Looks like html5lib has none. And it's totally broken in Py3. |
| 18:12 | <gsnedders> | hsivonen: I think I saw some from you? |
| 18:12 | <gsnedders> | hsivonen: (meta pre-parsing tests) |
| 19:44 | <zewt> | ... the synchronous nature of javascript is part of the web platform's *use* of javascript, not javascript/ecmascript per se, right? |
| 19:45 | <zewt> | (nothing in the language seems to care one way or the other, but I'm not familiar with the spec itself) |
| 20:24 | <gsnedders> | zewt: asynchronous you mean? |
| 20:24 | <gsnedders> | Then no, it has nothing to do with JS. It's just how all the host object APIs for the DOM have developed with callbacks. |
| 20:25 | <gsnedders> | Probably in large part because most JS impls (i.e., all but Opera's) block everything, so synchronous APIs would be Rather Bad. |
| 20:30 | <zewt> | gsnedders: synchronous in the sense of not seeing asynchronous side-effects |
| 20:30 | <zewt> | (but yes, we're talking about the same thing) |
| 20:30 | <gsnedders> | Ah, right. |
| 20:30 | <gsnedders> | That's just a side-effect of impls, really. |
| 20:31 | <gsnedders> | The JS spec doesn't address multiple threads of impl at all. |
| 20:33 | <zewt> | yeah, that's what I've always assumed intuitively, was just looking for a sanity check before it came up in a debate :) |
| 20:34 | <zewt> | is anyone else driven mad by chrome's broken text searching, heh |
| 20:35 | <zewt> | i type "foo" and instead of finding the next "foo" from where I am now, it goes to the first "f" in the document before I can type the rest |
| 20:38 | <zewt> | particularly annoying in the html spec when it makes me lose my place |
| 21:08 | <smaug____> | is rick waldron ever here? |
| 21:25 | <zewt> | it's pretty (something) that anyone would seriously suggest this atrocity as a solution to anything: https://github.com/kriskowal/q/blob/master/examples/all.js |