| 00:32 | <cbright6062> | annevk: Anything you specifically you would like to see? (such as updating the heading levels to the new standard scheme, etc). I'm just making sure to stay within reason, etc. |
| 01:54 | <danbeam> | hello! if I believe I've found some overlap in a working draft of CSSOM (compared to DOM2 core) with a notice about how the IDL is re-defining things, how would I go about helping the editor fix this? email them directly? scour IRC channels or lists? http://www.w3.org/TR/cssom-view/#dom-mouseevent-clientx seems to overlap with http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent-clientX (which is already recommended), for more conte |
| 01:55 | <TabAtkins_> | Email www-style⊙wo about it. |
| 01:55 | <danbeam> | TabAtkins_: okie dokie |
| 01:55 | <TabAtkins_> | That said, DOM Level 2 Events isn't used, iirc. |
| 01:56 | <danbeam> | TabAtkins_: it isn't used in what sense? like in the ES4 sense where it was dropped? |
| 01:57 | <TabAtkins_> | It's superseded by better specs. |
| 01:57 | <danbeam> | TabAtkins_: ah, which specs? |
| 01:58 | danbeam | is inb4 DOM Level 3 events |
| 01:58 | <zewt> | itym dom4 |
| 01:58 | <zewt> | (fine, dom3 for the events themselves; but for the event model, dom4) |
| 01:58 | <danbeam> | they have the same conflicts |
| 01:59 | <TabAtkins_> | All right then. |
| 01:59 | <danbeam> | client{X,Y} and screen{X,Y} are supposed to be on MouseEvent interface |
| 01:59 | <TabAtkins_> | I wonder if we have an active editor for CSSOM-View... |
| 01:59 | <TabAtkins_> | I dont' think so. |
| 01:59 | <danbeam> | yeah, was gonna email Anne, but she's may not be as active now? |
| 01:59 | <TabAtkins_> | Anne's a guy. |
| 01:59 | <danbeam> | my bad |
| 02:00 | <TabAtkins_> | And has left the CSSWG, so he's not editting that spec any longer. |
| 02:00 | <danbeam> | yeah |
| 02:00 | <TabAtkins_> | So, yeah, that's an editorless spec. |
| 02:00 | <othermaciej> | I didn't know that Anne left the CSSWG |
| 02:01 | <TabAtkins_> | Yeah, he dropped out a few months ago. |
| 02:01 | <danbeam> | TabAtkins_: I don't supposed there'd be a point in mentioning this in my email to www-style and asking for volunteers? |
| 02:01 | <danbeam> | suppose* |
| 02:01 | <TabAtkins_> | danbeam: Go ahead and mention it. Make sure to put [cssom-view] in the subject line. |
| 02:01 | <danbeam> | TabAtkins_: ok |
| 02:01 | <TabAtkins_> | Just so that future editors of that spec will be able to find it. |
| 02:01 | <danbeam> | ya |
| 02:02 | TabAtkins_ | wonders what Glenn Adams has been doing lately, since he hasn't seen much activity in the CSSOM spec recently... |
| 02:05 | <danbeam> | TabAtkins_: so if CSSOM spec declares it added these to the MouseEvent interface, but they were in DOM Level 2 Events (which seems to be circa 2000, 11 years previous), should that part simply be removed from the CSSOM spec, essentially (given than an editor is found)? |
| 02:05 | <danbeam> | s/spec/working draft/ for CSSOM (if that matters?) |
| 02:05 | <TabAtkins_> | Yeah, unless there's a good reason that CSSOM View should update the definitions, the DOM specs shoudl be definitive. |
| 02:05 | <TabAtkins_> | Given that D3E is more recent than View, too. |
| 02:06 | <danbeam> | TabAtkins_: it seems to be the exact same thing |
| 02:06 | <TabAtkins_> | Then yes. |
| 02:06 | <danbeam> | TabAtkins_: so nothing to update |
| 02:22 | kennyluck | wonders why there's only one person from Google that is active on www-style |
| 02:22 | <danbeam> | kennyluck: I'm not particularly active, but I'm about to prove you wrong just the tiniest bit, :P |
| 02:22 | <danbeam> | kennyluck: who were you referring to, Tab? |
| 02:23 | <kennyluck> | The editor that's listed currently. |
| 02:25 | <danbeam> | kennyluck: editor of ... what? |
| 02:25 | <kennyluck> | danbeam, of CSSOM and CSSOM-view. |
| 02:26 | <danbeam> | kennyluck: ah |
| 02:26 | <kennyluck> | oh, sorry I misunderstood you. |
| 02:26 | <kennyluck> | Ye |
| 02:26 | <kennyluck> | Yeah, I was referring to Tab of course. |
| 02:27 | <danbeam> | so you're talking about shans@? |
| 02:27 | <danbeam> | @google.com* |
| 02:27 | kennyluck | thought that you were asking who Glenn Adams is. |
| 02:28 | <danbeam> | kennyluck: I know exactly who Glenn Adams is -- the smartest person I've [n]ever met with an @cox.com email! |
| 02:28 | <danbeam> | :P |
| 02:30 | <danbeam> | TabAtkins_: the editor's draft of CSSOM View seems to have new editors, should I be CC'ing/directing my question to shans⊙gc / glenn.adams⊙cc as well? |
| 02:30 | <kennyluck> | *shrug*. He only reminds me of a long thread about CORS and @font that I didn't look into. |
| 02:31 | <danbeam> | kennyluck: haha, Access-Control-Allow-Origin: * everywhere! what's the worst that could happen?! |
| 04:09 | <annevk> | cbright6062: whatever you think is appropriate is fine |
| 04:10 | <annevk> | cbright6062: anything goes as long as it's still readable in recently released browsers |
| 04:10 | <cbright6062> | annevk: Okay. And I will makeshore it is. |
| 04:10 | <annevk> | cbright6062: at least as far as I'm concerned, others in this channel might have different views |
| 04:10 | <cbright6062> | annevk: I mainly asked you since you have the main focus on the blog, from what I've seen :) |
| 04:11 | <annevk> | I think in the end the person doing the work should decide |
| 04:12 | <cbright6062> | lol |
| 04:12 | <cbright6062> | well, I'm doing the work, but I don't want to upset anyone on here :P |
| 04:13 | <annevk> | don't worry about it |
| 04:13 | <annevk> | ask forgiveness, not permission |
| 04:14 | <annevk> | danbeam: DOM Level whatever does not define hit testing and does not define the coordinates are given in CSS pixels |
| 04:14 | <annevk> | danbeam: having said that, TabAtkins_ is right, I'm no longer an editor or participant in the CSS WG |
| 08:26 | <hsivonen_> | Poe's Law in action: http://stuffandnonsense.co.uk/blog/about/there_i_said_it |
| 08:28 | <jgraham> | hsivonen: I don't think there's any suggestion that's a parody? |
| 08:30 | <jgraham> | At least, if that's the intention — and I agree the content could be mistaken for parody — he fails to carry it through into the comments |
| 08:31 | <jgraham> | Sadly I think there is just a school of thought that browsers are canvases for the artistic vision of web designers rather than tools that are designed to enable their users to access information |
| 09:06 | <gsnedders> | jgraham: Also, to pedant, transforms are Core Animation. |
| 09:15 | <jgraham> | gsnedders: Fair point |
| 09:16 | <gsnedders> | But regardless, an API that exists only on OS X and their Windows-Safari port thing, seemingly. |
| 09:17 | <jgraham> | Yes, my underlying point stands |
| 09:17 | <gsnedders> | (I wonder if Apple will ever release their Obj-C runtime for Windows?) |
| 09:18 | <gsnedders> | (I can't see it happening, but it raises interesting questions about Xcode being ported for the sake of iOS) |
| 09:22 | othermaciej | is puzzled by the last few lines of conversation |
| 09:24 | <jgraham> | othermaciej: The context is that -webkit- CSS properties, in particular transforms, often have different implementations of the gfx part |
| 09:25 | <othermaciej> | different from what? |
| 09:25 | <jgraham> | In different consumers of webkit |
| 09:25 | <jgraham> | e.g. in Chrome vs Safari |
| 09:25 | <othermaciej> | oh, yeah, different ports have different graphics back ends, not just for transforms for that matter |
| 09:25 | <jgraham> | (sorry that was very badly worded) |
| 09:26 | <othermaciej> | in fact I think transforms don't even use CA if they are 2D and not animated |
| 09:26 | <gsnedders> | othermaciej: The context is in Andy's blog post comments |
| 09:26 | <othermaciej> | (3D transforms and transforms with animation/transition applied do force a CA layer, I think other transforms are just done w/ CoreGraphics) |
| 09:27 | <jgraham> | On the post hsivon linked to ther was lots of wailing about how Opera implementing some properties with the -webkit- prefix was evil because they might not have the same quality as "the" webkit implementation |
| 09:27 | <jgraham> | Although there was never actually a conccrete example of this being a problem |
| 09:27 | <gsnedders> | And may differ subtly from it. |
| 09:27 | <gsnedders> | (which there is some basis for, given gradient syntax fun) |
| 09:27 | <jgraham> | Or indeed any insight into why this isn't a problem for things without prefixes |
| 09:28 | <othermaciej> | I think people are starting with the conclusion that vendor A supporting vendor B's prefix is bad, and from there looking for arguments that may justify it |
| 09:28 | <othermaciej> | I'm not a huge fan of the situation but I can't blame anyone for doing whatever it takes to make their browser compatible with content |
| 09:29 | gsnedders | would quite like Apple to drop prefixed versions of properties, as everyone has done (albeit slowly) |
| 09:30 | <jgraham> | Yeah, that would match my impression and explain why so many of the arguments seem so weak |
| 09:30 | <jgraham> | I also don't like the situation fwiw, but I think the problem is with the prefix system |
| 09:30 | <othermaciej> | gsnedders: while that might be a good idea in general, for the most problematic properties, I am not sure that strategy is sane |
| 09:31 | <gsnedders> | Yeah, and something really should've happened when MS were going to implement… -webkit-text-size-adjust, was it, several years back. |
| 09:31 | <othermaciej> | because the specs are not advanced enough for the CSS WG to grant their blessing on shipping the unprefixed version at all, and the prefixed version is so widely used that not having it is major compatibility fail |
| 09:31 | <jgraham> | I don't think it's reasonable, for the same reason I don't think it's reasonable for everyone else not to just implement those properties |
| 09:31 | <gsnedders> | othermaciej: For border-radius it's a change that can happen. |
| 09:31 | <gsnedders> | othermaciej: For gradients, yeah, it's less clear. |
| 09:31 | <jgraham> | I think the CSS WG should confess that it failed and publish a CSS aliases spec |
| 09:32 | <gsnedders> | othermaciej: I believe you're now the only ones to support prefixed border-radius, FWIW |
| 09:32 | <jgraham> | That makes support for the prefixed properties part of the standard |
| 09:32 | <othermaciej> | gsnedders: for border-radius it sounds like it would break a bunch of sites (assuming Opera's reason for implementing -webkit-border-radius is sound) |
| 09:32 | <gsnedders> | jgraham: In a wildcard sense, as glazou was proposing, or just specific ones? |
| 09:33 | <jgraham> | gsnedders: I have no idea what glazou was proposing |
| 09:33 | <gsnedders> | othermaciej: That's a cosmetic issue, unlike the others. And it breaks them no more than Gecko dropping -moz- in 13. |
| 09:33 | <othermaciej> | not sure why Safari should take a compat hit in a case where Opera won't |
| 09:33 | <jgraham> | But I would suggest specific ones |
| 09:33 | <gsnedders> | jgraham: -*-foo is mapped to foo |
| 09:33 | <jgraham> | gsnedders: That makes no sense to me? What am I missing? |
| 09:34 | <jgraham> | I mean, it seems to have all the properties of not having a prefix system whilst still having a porefix system |
| 09:34 | <jgraham> | *prefix |
| 09:34 | <gsnedders> | othermaciej: I'd like to minimize the list of required synonyms, so we both would take the hit. I'm not gonna propsoe that for things like gradients where things actively become unusable. |
| 09:34 | <othermaciej> | I think prefix may be a failed experiment, at least as used today, but I am not sure how else to make it safe for browsers to experiment with extensions |
| 09:35 | <jgraham> | othermaciej: The only sane thing I have heard is for extensions to be behind runtime flags |
| 09:35 | <gsnedders> | othermaciej: But given Moz has managed to drop prefix for border-radius it suggests it can be done. |
| 09:35 | <jgraham> | Or not in stable versions |
| 09:35 | <gsnedders> | (Ourselves and MS never supported it with prefix) |
| 09:35 | <jgraham> | Of course that isn't going to work well if "experiment" really means "add new features before anyone else and encourage authors to use them" |
| 09:36 | <gsnedders> | FWIW, border-radius would never have been aliased without the far more serious non-cosmetic issues. |
| 09:36 | <othermaciej> | I don't think it would fly to gate availability of features to content authors on the CSS WG's time to get to CR |
| 09:36 | <jgraham> | I think the CSS WG is part of the problem |
| 09:37 | <gsnedders> | Ideally I'd like to only bake -webkit-linear-gradient (or whatever the name is) into the platform. |
| 09:37 | <gsnedders> | Because it's the only one sites *rely* on. |
| 09:37 | <jgraham> | So a solution that forces change on them seems like a positive thing |
| 09:37 | <gsnedders> | (Possibly old flexbox, but hopefully what Google uses that on moves away from it) |
| 09:37 | <othermaciej> | I wonder also how early implementation should work for APIs, where the prefix approach is even worse |
| 09:38 | <jgraham> | Because, as you say, people would push like crazy for a spec model that allowed fast iteration if their ability to ship was gated on fast itereation |
| 09:38 | <gsnedders> | annevk was suggesting second impl impls without prefix |
| 09:38 | <othermaciej> | (HTML attributes seem only about as bad as CSS properties when prefixed and no one holds those to a hard CR line) |
| 09:38 | <gsnedders> | othermaciej: Given the CSS WG agreed to drop things earlier than CR hopefully stuff is better in future. |
| 09:39 | <othermaciej> | gsnedders: by "drop things" you mean drop prefixes earlier than CR? |
| 09:39 | <gsnedders> | othermaciej: yeah |
| 09:39 | <othermaciej> | I thought the CSS WG explicitly refused to do that even in clear-cut cases |
| 09:39 | <othermaciej> | maybe I am not up to speed |
| 09:39 | <gsnedders> | I remember this in some f2f this be resolved. |
| 09:41 | <othermaciej> | I gotta ask hober since he goes to those things |
| 09:41 | <gsnedders> | I should probably just leave the WG given I never do anything anyway |
| 09:41 | <othermaciej> | anyway, CSS WG is touchy about their prefixes but I wonder if we can come up with sane cross-browser best practices for prefixing of APIs and markup attributes (I presume everyone would agree that prefixed elements are a bad idea) |
| 09:41 | <gsnedders> | Like, I every few months read the mailing list. Only otherwise do when people tell me to. |
| 09:43 | <gsnedders> | (In an unrelated point, Safari uses NSURL for all HTTPS stuff, so doesn't use NSS, right?) |
| 09:43 | <othermaciej> | I don't know what NSS is |
| 09:44 | <othermaciej> | we use CFNetwork for networking, via NSURL APIs on some OS versions |
| 09:44 | <othermaciej> | under the covers somewhere in there, I think OpenSSL is used for SSL stuff |
| 09:44 | <gsnedders> | SSL impl, used by Moz/Chrome |
| 09:45 | <gsnedders> | othermaciej: Shows how much time I've spent dealing with OS X that I don't even know that NSURL isn't current any more :) |
| 09:45 | <othermaciej> | NSURL is current, CFNetwork is just the thing underneath it |
| 09:45 | <gsnedders> | "some OS versions"? |
| 09:46 | <gsnedders> | (seeming NSURL predates Safari) |
| 09:48 | <tomasf> | I think NSURLConnection was introduced along with Safari, actually. Looking at the docs: "Available in Mac OS X v10.2 with Safari 1.0 installed. Available in Mac OS X v10.2.7 and later." |
| 09:48 | <othermaciej> | on some platforms we just go to CFNetwork directly |
| 09:49 | <gsnedders> | Ah. NSURL itself goes back to 10.0 |
| 09:49 | <gsnedders> | (don't believe it goes back to NS, though) |
| 09:49 | <othermaciej> | and yes, NSURLConnection was in fact introduced with Safari, it was first implemented by the Safari team |
| 09:49 | <tomasf> | yeah, NSURLHandle existed before that, and is deprecated since 10.4 |
| 09:49 | <othermaciej> | there was an older NSURLHandle which did not cut it for browser use |
| 10:07 | gsnedders | guesses he's in for fun working out what has changed in the past three OS X releases when he gets a MBA once they start shipping with Ivy Bridge CPUs |
| 10:12 | <gsnedders> | (Waiting mainly for the sake of GPU performance, which would probably be good enough to ditch my pretty old MBP) |
| 10:32 | <emc> | Hello, does anybody know if there is a limit to HTML offline storage? I'm trying to find out if videos can be stored in it? Does anybody know that? |
| 10:51 | <hsivonen> | jgraham: It's quite possible that it isn't a parody, which is troubling. |
| 10:57 | <gsnedders> | See, I've seen plenty of people call it brilliant parody, but I fail to see any evidence of this. |
| 10:57 | <hsivonen> | othermaciej: I think the best practice for prefixing is not to |
| 10:59 | <hsivonen> | I'm rather surprised that Opera isn't aliasing Animations. |
| 11:00 | <hsivonen> | Once the aliasing code is there, why bother limiting what's aliased? |
| 11:00 | <gsnedders> | hsivonen: The limitation is probably to avoid too much of a backlash. |
| 11:00 | gsnedders | has no idea |
| 11:01 | <hsivonen> | What I think is sad about Opera's announcement is that some things that will have -webkit-aliases weren't announced to have unprefixed aliases, too |
| 11:01 | <hsivonen> | well, the other sad thing was blaming Web authors |
| 11:02 | <hsivonen> | blaming them isn't that productive and even if true, doesn't help |
| 11:02 | <hsivonen> | blaming the CSS WG might actually end up having helpful effects |
| 11:02 | <hsivonen> | and would be more correct direction of blame anyway |
| 11:03 | <gsnedders> | Except the discussions a couple of months back basically seemed resigned to the fact that non-WebKit browsers will have to support them, so all you can really do is blame prior WG decisions which have since been changed. |
| 11:03 | <hsivonen> | I'm not on the CSS WG, so I don't understand why layout devs act like CSS WG has the power to decide about unprefixing |
| 11:03 | <gsnedders> | The fact that plenty of sites we are just told, "we only support WebKit", is an issue purely down to developers, though. |
| 11:04 | <hsivonen> | seems like Opera aliasing but not also unprefixing is part of acting like it's in the WG's power to decide |
| 11:04 | <hsivonen> | gsnedders: ok |
| 11:04 | <gsnedders> | hsivonen: It's not official WG policy, pretty much, it's just de-facto agreements amongst browser vendors who happen to be in the WG, pretty much. |
| 11:04 | <gsnedders> | (wrt when to unprefix) |
| 11:05 | <hsivonen> | why do people who can land code keep honoring those de facto agreements? |
| 11:06 | <jgraham> | Presumably fear of being called out on not supporting standards properly |
| 11:06 | <gsnedders> | hsivonen: The biggest issue is people doing background-image: -webkit-gradient(bleh); and refusing to put background-color: black; or whatever, which is down to more than just prefix policy. |
| 11:06 | <hsivonen> | gsnedders: interesting |
| 11:06 | <jgraham> | Or a belief that the prefixing is a good idea, in spite of the evidence that it is harmful in these cases |
| 11:07 | <gsnedders> | hsivonen: Leading to white-on-white text, which is the real harm of this situation. |
| 11:07 | <gsnedders> | hsivonen: Everything else is merely cosmetic, and wouldn't have lead us to this. |
| 11:07 | <jgraham> | Well white-on-white is an obvious "you can't use this site" bug |
| 11:08 | <jgraham> | Other things are "your browser sucks more than $webkitBrowser even though it doesn't actually" issues |
| 11:08 | <jgraham> | Which are also harmful |
| 11:08 | <gsnedders> | But not as harmful as to motivate anyone to risk the PR backlash we're currently getting. |
| 11:08 | <jgraham> | I'm not sure I agree |
| 11:10 | <jgraham> | Would have been nice to get Mozilla to make the change at the same time though |
| 11:10 | <jgraham> | Or announce that they will |
| 11:10 | <gsnedders> | Well, I don't think anyone has seriously considered doing it based upon cosmetic reasons |
| 11:11 | <gsnedders> | jgraham: We rather had our hand forced, though, seeming someone posted what was W3C member-confidenial. |
| 11:11 | <hsivonen> | gsnedders: I thought there have been cosmetic reasons under discussion |
| 11:12 | <hsivonen> | gsnedders: I have certainly advocated aliasing to get cosmetic benefits |
| 11:13 | <gsnedders> | IIRC IE Mobile's planned support for -webkit-text-size-adjust was for usability issues |
| 11:13 | <jgraham> | In the long term, cosmetic issues are just as important as "this site is broken" issues |
| 11:14 | <jgraham> | Maybe moreso, because they are harder to evangelise |
| 11:14 | <hsivonen> | they have mindshare consequences |
| 11:14 | <gsnedders> | I think the hope was to come up with some cross-browser agreement about prefixes for them. |
| 11:14 | <jgraham> | And UX consequences. |
| 11:14 | <gsnedders> | And for the current set of prefixes to go away. |
| 12:24 | <MikeSmith> | what is an "XML Literal" and what purpose does it serve? |
| 12:26 | MikeSmith | finds http://www.jenitennison.com/blog/node/103 |
| 12:49 | <Philip`> | MikeSmith: Its purpose is to confuse people by effectively being just a string that happens to contain markup, but technically being a string which is the UTF-8 decoding of an exclusive Canonical XML document fragment |
| 12:49 | <MikeSmith> | ah |
| 12:50 | <MikeSmith> | so it's the canonical part |
| 12:50 | <Philip`> | Easiest to just think of it as a markup string |
| 12:50 | <MikeSmith> | OK |
| 12:50 | <Philip`> | but with some magic in the RDF parsers so that you can represent that string as actual markup |
| 12:50 | <MikeSmith> | I see |
| 12:50 | <jgraham> | I find that all sentences with "XML" in become transparent in meaning if you s/XML/pain/g |
| 12:51 | <MikeSmith> | heh |
| 12:51 | <MikeSmith> | so there context of this is, somebody is asking me if there's a "formal notion and/or algorithm that says whether two HTML5 snippets are identical or not" |
| 12:51 | <MikeSmith> | but snippets I guess they mean nodes |
| 12:52 | <Philip`> | (i.e. the magic lets you write <h2 property="dc:title" datatype="rdf:XMLLiteral"><sup>2</sup></h2> which turns into a string with value "<sup xmlns="http://www.w3.org/1999/xhtml">2</sup>";, I think) |
| 12:52 | <MikeSmith> | Philip`: yeah, that looks like the example that Jeni uses in her blog entry |
| 12:52 | <Philip`> | (per http://www.w3.org/TR/rdfa-syntax/#s_xml_literals except the spec forgets the xmlns, I think) |
| 12:53 | <MikeSmith> | OK |
| 12:53 | <Philip`> | I assume the point is to prevent you having to write escaped markup inside markup, since that's ugly |
| 12:53 | <MikeSmith> | I see |
| 12:54 | <MikeSmith> | so then I guess once you'd done this XMLLiteral thing, there are some cases where you want to be able to compare two XMLLiteral things to determine if they are identical with each other |
| 12:54 | <MikeSmith> | not clear to me what those use cases are |
| 12:56 | <Philip`> | Yeah, they're just strings, so you can do arbitrary stringy things to them, but they happen to have the C14N guarantee that string equality is implied by XPath data model equality (which is quite like DOM equality) |
| 12:57 | <MikeSmith> | OK |
| 12:58 | <Philip`> | which (I think) in theory means you could extract RDFa from some XHTML document 'A', and then you could fiddle with 'A' to produce 'B' (change all the namespaces, change irrelevant whitespace, etc, e.g. by passing through an XML parser then serialiser) and extract RDFa from 'B', and you'd get exactly the same output |
| 13:04 | <davidb> | th |
| 13:45 | <zcorpan> | about webvtt line wrapping, where should the line break go if there are two positions that would produce the same delta? |
| 13:58 | <zewt> | zcorpan: up to the implementation, i think, the balancing definition isn't precise (and should be loosened a bit more, to explicitly allow approximations) |
| 14:01 | <zcorpan> | zewt: that's annoying when writing tests :-) |
| 14:02 | <zewt> | tests how? it depends on the implementation's and platform's font rendering anyway |
| 14:02 | <zcorpan> | reftests |
| 14:02 | <zewt> | fwiw i want it to allow approximations so later the balanced wrapping can be made into a generic css white-space mode (where requiring it to be optimal isn't practical) |
| 14:03 | <zcorpan> | yeah i'm fine with allowing that, actually |
| 14:03 | <zcorpan> | it's still annoying |
| 14:03 | <zewt> | you can test extreme cases, which should always give results within certain limits |
| 14:04 | <zewt> | eg. if "a b c d e f g" wraps to "a b c d e f" and "g" in normal wrapping, it should always wrap closer to "a b c d", "e f g" in balanced |
| 14:05 | <zewt> | that is, in that case the balanced output should always be narrower than the regular output, even if it's an approximation |
| 14:06 | <zewt> | though since the balancing behavior is currently a special case rule instead of a CSS rule, I guess you can't turn it off in order to easily compare |
| 14:07 | <zcorpan> | hmm, also the spec doesn't say where to wrap words that are too long to fit |
| 14:07 | <zewt> | i guess you could check progressively longer cues ("foo", "foo foo", "foo foo foo", ...), and check that the width increases, and then decreases |
| 14:08 | <zewt> | that is, the width of the box will increase as long as it fits on one line, then it'll abruptly drop to about half the width as it inserts a break around the middle, and then start increasing again; that doesn't happen with regular wrapping |
| 14:08 | <zewt> | not a thorough test by any measure, but should at least tell whether it's happening at all |
| 14:09 | <zewt> | anyhow off to work, later |
| 14:10 | <zcorpan> | see ya |
| 14:27 | <MikeSmith> | XML Core WG no like BOM |
| 14:37 | <zcorpan> | ok please tell me the editor's draft which seems to give an error right now doesn't do this silly renaming http://www.w3.org/TR/css3-text/#overflow-wrap0 |
| 15:28 | <Ms2ger> | zcorpan: no, fantasai hasn't got the memo that silly renaming is a bad idea |
| 15:44 | Ms2ger | sees "MIME RFCs" on WHATWG, ignores |
| 16:15 | <annevk> | Ms2ger: what do you mean? |
| 16:16 | <Ms2ger> | Hmm? |
| 16:16 | <annevk> | about MIME RFCs |
| 16:16 | <annevk> | also, do you know any constants for UNINITIALIZED but with a better name? |
| 16:18 | <Ms2ger> | "multipart/form-data filename encoding: unicode and special characters" |
| 16:18 | <Ms2ger> | No |
| 16:20 | <annevk> | oh yeah |
| 16:21 | <annevk> | I've been saying for ages for we should just define the details of that RFC in HTML directly |
| 16:21 | <annevk> | rather than this rather obscure reference |
| 16:21 | <annevk> | Hixie had some reason not to I think, but I'm not sure it's still valid... |
| 16:22 | <Ms2ger> | annevk, do you know who does what for the eventPhase thing, btw? |
| 16:26 | <annevk> | Chrome/Safari/IE do 0 |
| 16:26 | <annevk> | Gecko does 2 |
| 16:26 | <annevk> | Opera does 1 |
| 16:26 | <annevk> | per Travis |
| 16:26 | <annevk> | I have not verified |
| 16:29 | <annevk> | added a comment |
| 16:31 | <Ms2ger> | Oh, you went with Gecko? How strange ;) |
| 16:41 | <rafaelw_> | hsivonen: Can I take a few minutes of your time and chat about DocumentFragment.innerHTML? |
| 16:43 | <annevk> | Ms2ger: it seemed somewhat sensible given the options |
| 16:43 | <annevk> | Ms2ger: I didn't want to mint a new constant |
| 16:43 | <annevk> | Ms2ger: Travis is more open to that |
| 16:43 | <Ms2ger> | I defer to smaug |
| 16:46 | <annevk> | lets see if I can fix it before Travis |
| 16:46 | <annevk> | prolly not, going to discuss CORS again |
| 16:46 | <annevk> | soooo boring |
| 16:47 | <weinig> | annevk: did we skip the DOM3/4 stuff? |
| 16:47 | <Ms2ger> | Also, what happened to From-Origin? |
| 16:56 | <MikeSmith> | Ms2ger: nobody expressed interest in implementing it |
| 17:00 | <annevk> | weinig: no |
| 17:00 | <annevk> | Ms2ger: nobody implemented it |
| 17:00 | <Ms2ger> | Thanks, annevk, MikeSmith :) |
| 17:01 | <MikeSmith> | mention of resistance from Mark and Tyler |
| 17:02 | <MikeSmith> | as if it's new news |
| 17:03 | <MikeSmith> | yeah, let's document the rationale for the platform in every single spec |
| 17:04 | <Ms2ger> | \o/ |
| 17:09 | <Hixie> | annevk: i don't recall if there was any specific reason other than not pissing off people we don't need to piss off more, and avoiding extra work. |
| 17:14 | <dglazkov> | rafaelw_: I think hsivonen hates you. |
| 17:14 | <dglazkov> | rafaelw_: did you accidentally send him spam at some point? |
| 17:14 | <dglazkov> | :) |
| 17:15 | <Ms2ger> | Accidentally? :) |
| 17:15 | Ms2ger | waves at dglazkov |
| 17:15 | <dglazkov> | aw crap, forgot to good morning everyone |
| 17:15 | <dglazkov> | good morning, Whatwg! |
| 17:15 | <dglazkov> | :) |
| 17:15 | <dglazkov> | Ms2ger: are you at the F2F? |
| 17:15 | <Ms2ger> | Maybe? :) |
| 17:16 | <dglazkov> | okay peeps, let's smoke Ms2ger out |
| 17:24 | <jgraham> | rafaelw_: hsivonen typically is around during office hours in whatever weird timezone Finland's in |
| 17:25 | <jgraham> | EEST perhaps |
| 17:26 | <Ms2ger> | jgraham, yours +1 :) |
| 17:27 | <jgraham> | Oh look, the little graph at http://gavinsharp.com/irc/whatwg.html is very informative in this regard |
| 17:28 | <jgraham> | Ms2ger: I know what the GMT offset is (except when I don't), I just didn't know what it was called |
| 17:33 | <gavin> | hmm, I guess I lost the customizatino I had that included the time zone being used in those stats |
| 17:34 | <rafaelw_> | jgraham: Thanks. =-) |
| 18:09 | <annevk> | Hixie: hey, when do you have time to address the WebSocket issues? |
| 18:27 | <cheron> | Can sb. tell me what is supposed to happen to the private key generated by the keygen element? How can I use it? |
| 18:43 | <Ms2ger> | annevk, can you file http://dvcs.w3.org/hg/domcore/rev/98a9587a515c on Gecko? |
| 18:44 | <annevk> | sure |
| 18:44 | <Ms2ger> | Ta |
| 18:48 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=751286 |
| 18:48 | <annevk> | guess I should file one on WebKit too |
| 18:51 | <Ms2ger> | Hmm, eventPhase can return 0 in Gecko too |
| 18:52 | <annevk> | Gecko -> weird |
| 18:52 | <Ms2ger> | Truth |
| 18:53 | <Ms2ger> | weinig++ |
| 18:53 | <Ms2ger> | Again |
| 18:53 | <annevk> | weinig 4 prez |
| 18:53 | <weinig> | \o/ |
| 18:54 | <hober> | Ms2ger: what did he do now? |
| 18:54 | <Ms2ger> | https://bugs.webkit.org/show_bug.cgi?id=85397 |
| 18:55 | <hober> | Ms2ger: :) |
| 18:57 | <Ms2ger> | smaug++ |
| 19:00 | <MikeSmith> | old checkin comments like http://html5.org/tools/web-apps-tracker?from=61&to=62 are fun |
| 19:04 | <annevk> | wait |
| 19:05 | <annevk> | posts to whatwg⊙wo now get on public-whatwg⊙wo ? |
| 19:05 | <annevk> | hmm |
| 19:06 | <jwalden> | hahaha |
| 19:07 | <Philip`> | Obligatory cross-posting? |
| 19:31 | <Hixie> | annevk: there are websocket issues? |
| 19:33 | <Hixie> | cross-posting to public-whatwg would be massively confusing unless public-whatwg can't be posted to |
| 19:33 | <Hixie> | i've disabled it until i can speak to whoever set that up |
| 19:34 | <MikeSmith> | Hixie: I set it up |
| 19:34 | <Hixie> | MikeSmith: so my concern is that people will post to public-whatwg and not realise they're yelling into a vacuum |
| 19:34 | <MikeSmith> | yup |
| 19:34 | <Hixie> | MikeSmith: can be disable posting to that list somehow? |
| 19:34 | <MikeSmith> | understood |
| 19:34 | <MikeSmith> | I will try to do that right now |
| 19:35 | <Hixie> | (the mirroring is fine by me in principle, though it'd be nice to get historical archives in there too) |
| 19:37 | <MikeSmith> | Hixie: systems team is planning to get the historical archives set up |
| 19:37 | <Hixie> | nice! |
| 19:37 | <MikeSmith> | will need to get a copy of the archives from you of course |
| 19:37 | <MikeSmith> | and I think we can't do it til later this month |
| 19:38 | <Hixie> | hm |
| 19:38 | <Hixie> | i dunno that i can get anything you can't get |
| 19:38 | <Hixie> | but i can look |
| 19:38 | <Hixie> | looks like the best i can get you is the gzipped archives here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/ |
| 19:38 | <MikeSmith> | I can't disable posting to public-whatwg, so let's leave it unsubscribed for whatwg⊙wo for now, until I can talk with the systems team about setting it up some other way |
| 19:38 | <Hixie> | they're in mbox format iirc |
| 19:39 | <MikeSmith> | Hixie: excellent, thanks |
| 19:39 | <Hixie> | MikeSmith: it's subscribed, just with mail delivery administratively disabled |
| 19:39 | <MikeSmith> | OK |
| 19:39 | <Hixie> | MikeSmith: happy to turn it back on as soon as we can do it in a way that doesn't lead to people's feedback being lost :-) |
| 19:39 | <MikeSmith> | I will let you know as soon as I can make time to talk with them about it |
| 19:39 | <Hixie> | roger |
| 19:44 | <annevk> | Hixie: just minor, but it would be good to have an updated spec, especially for ArrayBuffer -> ArrayBufferView and not throwing for isolated surrogates |
| 19:50 | <Hixie> | k |
| 19:51 | <Hixie> | going through bugs now |
| 19:51 | <Hixie> | (it would be good in general to update all the specs i work on. not clear why websockets is more urgent than the others :-P) |
| 20:10 | <Hixie> | where does typed array define what an arraybufferview represents? |
| 20:12 | <Ms2ger> | Does it? |
| 20:13 | <Hixie> | i guess not |
| 20:13 | <Hixie> | this spec in general seems to be missing clear conformance requirements and definitions |
| 20:13 | <Ms2ger> | Yes |
| 20:13 | <Ms2ger> | And it tries to expose endianness |
| 20:15 | <Hixie> | and NaN bit patterns |
| 20:20 | <annevk> | Hixie: mostly Microsoft I guess and because it's in CR at the W3C :/ |
| 20:21 | <annevk> | thanks for fixing |
| 20:36 | <Ms2ger> | Heh, apparently we don't like Shelley Powers because we're sexist |
| 20:41 | <Philip`> | But we like Anne |
| 20:42 | <othermaciej> | has there been a new Shelley-related incident? |
| 20:44 | <annevk> | Philip`: was waiting for that :p |
| 20:44 | <Ms2ger> | othermaciej, http://lists.w3.org/Archives/Public/www-archive/2012Apr/0073.html |
| 21:09 | <scott_gonzalez> | document.activeElement should never be inside the shadow DOM, correct? |
| 21:10 | <annevk> | correct |
| 21:11 | <scott_gonzalez> | Time to file a bug with Mozilla... |
| 21:11 | <annevk> | Mozilla implements shadow DOM? |
| 21:12 | <scott_gonzalez> | I don't know if they expose it, but they seem to be using it for <input type="file"> |
| 21:12 | <annevk> | that's XBL I guess |
| 21:12 | <annevk> | sounds like a pretty bad bug |
| 21:13 | <scott_gonzalez> | At least that's what it looks like. When <input type="file"> gets focus by clicking on the text field portion of the element, document.activeElement is <input type="text" tabindex="-1" readonly=""> |
| 21:13 | <scott_gonzalez> | http://jsfiddle.net/wfkxu/ |
| 21:13 | <annevk> | be interesting to poke around |
| 21:26 | <Hixie> | annevk: are these e-mails ones i should send you and ms2ger? http://www.whatwg.org/issues/#dom-core |
| 21:27 | annevk | looks |
| 21:27 | <annevk> | Hixie: I already replied to those |
| 21:27 | <annevk> | Hixie: wait hmm |
| 21:28 | <annevk> | Hixie: so we moved classList, not sure if it's removed from HTML |
| 21:28 | <annevk> | Hixie: we have an open bug on extending DOMTokenList |
| 21:28 | <annevk> | I have pointed out the DOMTokenList thing in the past on whatwg⊙wo |
| 21:29 | <annevk> | not sure about classList |
| 21:29 | <Hixie> | annevk: k |
| 21:29 | <Hixie> | annevk: so do you want me to send you those as a batch and have you reply to them, or should i reply to them pointing to the dom core spec? |
| 21:56 | <annevk> | Hixie: the latter I guess |
| 21:56 | <Hixie> | k |
| 21:57 | <annevk> | Hixie: well, and maybe you should remove classList... |
| 21:57 | <annevk> | but maybe you want to wait until we convince more impls to do that |
| 21:57 | <annevk> | I saw a patch from sicking |
| 21:57 | <Hixie> | i don't agree that we should do that in the first place, so... :-) |
| 21:58 | <Hixie> | (because SVG className is not hte same as HTML className) |
| 21:59 | <annevk> | ah yeah |
| 21:59 | <annevk> | SVG will just have to change |
| 21:59 | <Hixie> | good luck with that |
| 22:11 | <annevk> | it's really hard to decide on an email address |
| 22:11 | <Hixie> | o_O |
| 22:11 | <annevk> | Hixie: I have issues |
| 22:11 | <annevk> | :) |
| 22:12 | <wilhelm> | annevk: It is. I can't find any way to eliminate the redundancy in “w⊙wn”. |
| 22:14 | <annevk> | wilhelm: ah you already got a short domain |
| 22:14 | <Hixie> | i thought ian⊙hc was pretty simple, but it seems to have just made people think my name is "ian hixie" |
| 22:14 | <annevk> | haha |
| 22:15 | <annevk> | I think my shortest domain is quuz.org so I was thinking m or a @quuz.org |
| 22:15 | <annevk> | but maybe I should go with the more verbose m @ annevankesteren.nl |
| 22:15 | <hober> | m? |
| 22:15 | <annevk> | |
| 22:15 | <annevk> | I've been trying to get hold of anne.nl but no luck |
| 22:16 | <Hixie> | how about annevk.nl? |
| 22:16 | <annevk> | and an.ne requires a company in Niger and Niger also requires at least three letters I think |
| 22:16 | <Hixie> | an.ne is ugly |
| 22:16 | <annevk> | Hixie: yeah that might be a good compromise |
| 22:16 | <Hixie> | like someone shot your name or something |
| 22:16 | <hober> | pad out with extra ns |
| 22:16 | <hober> | annnn.ne |
| 22:16 | <annevk> | I'm not a big fan of "annevk" I prefer "anne" |
| 22:17 | <Hixie> | ah |
| 22:17 | <wilhelm> | I like relevant country TLDs. anne*.nl is appropriate. |
| 22:17 | <hober> | yeah, mine is quite irrelevant |
| 22:17 | <annevk> | I can get anne.io |
| 22:17 | <hober> | ted at oconnor.cx |
| 22:17 | <annevk> | which is kind of funny |
| 22:17 | <hober> | annevk: the solution is simple: found your own country and get the .vk tld |
| 22:18 | <hober> | me⊙av |
| 22:18 | <annevk> | true |
| 22:18 | <Hixie> | annevk: btw the advantage of something like anne⊙st rather than mail⊙as is that it makes sense as a jabber alias too |
| 22:18 | <Hixie> | you could just buy .anne |
| 22:18 | <Hixie> | it's only a few hundred grand |
| 22:18 | <annevk> | I like how you use "just" |
| 22:18 | <wilhelm> | Totally worth it. |
| 22:18 | <annevk> | anne@anne |
| 22:18 | <annevk> | no extensions |
| 22:19 | <Hixie> | dude if you did that we'd all be like "well crap, now we have to do that too" |
| 22:19 | <annevk> | deal with that silly email regular expressions |
| 22:19 | <kennyluck> | anneisaguy.com |
| 22:19 | <othermaciej> | anne⊙nc |
| 22:19 | <annevk> | actuallyaguy.com is free |
| 22:19 | <annevk> | anne⊙ac |
| 22:20 | <annevk> | kind of lame though |
| 22:20 | <Hixie> | you're name is Aguy? |
| 22:20 | <Hixie> | your |
| 22:20 | <Hixie> | your |
| 22:20 | <Hixie> | jesus |
| 22:20 | <annevk> | haha |
| 22:20 | <othermaciej> | notagirl.com smells of being a phishing scam |
| 22:22 | <wilhelm> | anne.is/a.gentleman |
| 22:22 | <wilhelm> | .is is available. :P |
| 22:22 | <wilhelm> | And .eu is for sale, apparently. |
| 22:23 | <Hixie> | the whole TLD? |
| 22:24 | <wilhelm> | Just a very limited subset. |
| 22:27 | <zewt> | dreaming of the day when the password form fills in on paypal+firefox without having to click the username then the password field |
| 22:28 | <zewt> | annevk: heh the only problem with my address is it has to be spelled out |
| 22:30 | <annevk> | thanks for the ideas everyone, I'll ponder over it some more :p |
| 22:30 | <annevk> | wilhelm: Yoda-style, "Gentleman, Anne is" |
| 22:30 | <wilhelm> | That could work. |
| 22:32 | <rniwa> | Hixie: can we use your annotation script on whatwg in webapps WG? |
| 22:32 | <rniwa> | Hixie: would it be possible to open-source it somewhere? |
| 22:32 | <Hixie> | it's pretty specific to HTML, but I can make the code available if someone wants to host a fork of it somewhere else, sure |
| 22:32 | <rniwa> | Hixie: we would like to be able to list tests per section for example |
| 22:32 | <rniwa> | Hixie: excellent! |
| 22:32 | <Hixie> | whoever wants to have the code should e-mail me |
| 22:33 | <rniwa> | okay |
| 22:33 | <Hixie> | it's pretty hairy |
| 22:33 | <Hixie> | might be easier to start from scratch |
| 22:34 | <WeirdAl> | I'd love to see those annotations in the XHR2 spec |
| 22:34 | <Hixie> | (i'm amused that there are people in the meeting who weren't familiar with this stuff) |
| 22:34 | <Hixie> | (how is that even possible?) |
| 22:35 | <annevk> | Hixie: how Bush got elected still boggles my mind too |
| 22:35 | <Hixie> | that seems qualitatively different |
| 22:36 | <annevk> | I guess, though sometimes this stuff feels just as weird |
| 22:37 | <annevk> | WeirdAl: yeah, all over really |
| 22:40 | <Hixie> | i've been saying this for years |
| 22:42 | <zewt> | annevk: elected, maybe ... it's the re* part that's confusing |
| 22:45 | <evilandlazy> | it's been months since I had a tshirt idea: http://www.zazzle.com/webkit_is_awesome_mug-168431797145781438 |