| 00:19 | <Hixie> | holy cow |
| 00:19 | <Hixie> | <option>'s value really is stripped of leading and trailing spaces before submission |
| 00:19 | <Hixie> | and newlines replaced by spaces! |
| 00:20 | <Hixie> | and multiple spaces collapsed! |
| 00:21 | <Hixie> | hm, chrome only does the stripping |
| 03:07 | <jcranmer> | Hixie: sigh |
| 03:07 | <jcranmer> | why can't people write specifications correctly? |
| 03:07 | <jcranmer> | http://www.yenc.org/yenc-draft.1.3.txt |
| 03:09 | <jcranmer> | as annoying as HTML5 is to read, that spec is worse |
| 03:09 | <jcranmer> | leaving alone the fact that it is a horrible implentation (let's take hithertofore unstructured fields and require them to be structured!) |
| 05:09 | <MikeSmith> | Hixie: about feedback to comments list, I have to manually pipe the messages to a script |
| 05:09 | <MikeSmith> | and I am way behind on doing that |
| 05:09 | <MikeSmith> | I will do them today |
| 05:11 | <MikeSmith> | AryehGregor: I think you can change the bugzilla account to a different address and it will change globally/retroactively |
| 05:11 | <MikeSmith> | I mean, it will also change the address linked to in any comments you submitted previously, any bugs you reported previously, etc. |
| 05:12 | <MikeSmith> | if the UI doesn't let you change it yourself, I am pretty sure I can from the admin UI |
| 05:40 | <karlcow> | http://www.reuters.com/article/2011/08/03/us-cyberattacks-idUSTRE7720HU20110803?feedType=RSS&feedName=topNews&dlvrit=59363 |
| 06:06 | <MikeSmith> | AryehGregor - HTML Editing APIs added in bugzilla under WebAppsWG product |
| 06:19 | <annevk> | MikeSmith, still named "Access Control" |
| 06:19 | <MikeSmith> | oh |
| 06:19 | <MikeSmith> | will fix that now |
| 06:19 | <MikeSmith> | how come you awake man? |
| 06:20 | <annevk> | little after 7AM here :) |
| 06:20 | <MikeSmith> | that's no proper time to be awake, chief |
| 06:22 | <MikeSmith> | annevk: http://dev.w3.org/2006/waf/access-control/ is still the current location for the ED, right? |
| 06:22 | <MikeSmith> | annevk: name changed now |
| 06:23 | <annevk> | yup |
| 06:23 | <MikeSmith> | k |
| 06:23 | <annevk> | and yeah, ideally I would have slept a little longer |
| 06:23 | <MikeSmith> | that URL just keeps getting better with every year |
| 06:27 | <MikeSmith> | a lot of reports on sleep research I've seen recently seem to strongly indicate that we really should get 8 hours of sleep every night |
| 06:27 | <MikeSmith> | people who don't get 8 hours of sleep perform worse on memory tests and such |
| 06:28 | <MikeSmith> | seems like part of what happens with your brain during sleep is a kind of garbage collection |
| 06:34 | <zcorpan> | MikeSmith: i sleep at least 8 hours every night, i think |
| 06:34 | <MikeSmith> | eh? |
| 06:34 | <MikeSmith> | so if you're awake now, what time did you go to sleep last night? |
| 06:34 | <zcorpan> | 22:00 |
| 06:35 | <zcorpan> | i was intending to get up at 06:00 but i didn't get up until 06:50 |
| 06:36 | <MikeSmith> | good god |
| 06:37 | <MikeSmith> | I envy you |
| 06:37 | <zcorpan> | i guess my night sleep will be fucked when we have kids |
| 06:38 | <MikeSmith> | because of timezone differences, 22:00 is time when most of my telcons start |
| 06:38 | <MikeSmith> | oh yeah |
| 06:38 | <zcorpan> | boo telecons, and *late* telecons to boot :( |
| 06:39 | <MikeSmith> | with my daughter, I think for at least the first 4 months, I didn't sleep more than 2 hours straight at time |
| 06:39 | <annevk> | i'm open to change that URL |
| 06:39 | <annevk> | we can move the whole thing to dvcs |
| 06:39 | <MikeSmith> | she was the kind of baby that knew whether I was standing up when I was holding her or not, and at night she'd cry unless I was standing and moving around with her |
| 06:40 | <MikeSmith> | annevk: I think it's fine where it is for now, but I'm also happy to move it to dvcs.w3.org if you want. I can do it right now. You want me to? |
| 06:44 | <othermaciej> | Hixie: do you have an opinion about text/html-sadboxed not doing what is intended (apparently) in IE6? |
| 06:44 | <annevk> | MikeSmith, if you can get me http://dvcs.w3.org/hg/cors/ please yes |
| 06:44 | <MikeSmith> | annevk: OK, will do now |
| 06:44 | <annevk> | MikeSmith, dev.w3.org is so slow sometimes; nothing beats local hg |
| 06:44 | <zcorpan> | othermaciej: it sniffs it as html? |
| 06:45 | <MikeSmith> | annevk: yeah, come to think of it, that alone makes it worth moving stuff |
| 06:45 | <othermaciej> | zcorpan: at least one Microsoft dude so claims |
| 06:45 | <zcorpan> | is there a mime type we could use instead that ie6 wouldn't sniff as html? |
| 06:45 | <othermaciej> | IE6 is still over 9% market share, which is pretty bad |
| 06:46 | <othermaciej> | I don't know |
| 06:46 | <othermaciej> | I haven't even checked the MS guy's claims |
| 06:46 | <annevk> | prolly adding a bunch of zero bytes at the start of the document |
| 06:46 | <zcorpan> | application/octet-stream; actually=sandboxed-html |
| 06:46 | <annevk> | bah |
| 06:47 | <othermaciej> | does IE6 actually refrain from sniffing application/octet-stream? |
| 06:47 | <zcorpan> | not sure |
| 06:51 | <annevk> | so much email |
| 06:55 | <MikeSmith> | there have been a lot fewer LC comments than I would have expected at this point |
| 06:56 | <MikeSmith> | I think we got something on the order of 375 LC comments filed as bugs in bugzilla |
| 06:58 | <MikeSmith> | anyway, email sucks |
| 07:01 | <MikeSmith> | I probably should not admit this, but I literally have 7551 unread messages in my inbox |
| 07:01 | <MikeSmith> | mostly list mail, but still |
| 07:01 | <othermaciej> | it is surprising how low the LC feedback has been |
| 07:01 | <othermaciej> | but perhaps this is an artifact of the massive level of ongoing feedback we have gotten |
| 07:01 | <othermaciej> | I would have expected > 1000 LC comments |
| 07:02 | <MikeSmith> | yep, I had been thinking more like 2000 |
| 07:03 | <roc> | how many people actually know about the LC deadline who haven't been providing feedback all along? |
| 07:03 | <MikeSmith> | roc: people who only read the TR drafts, I guess |
| 07:13 | <MikeSmith> | anyway, givent the spec has been in development for 6-7 years, and been scrutinized and commented on very heavily that whole time, so I guess it's expected we're not going to get a flood of new insights |
| 07:16 | <roc> | one might still expect to get a flood of rubbish comments |
| 07:32 | <nessy> | oh, I am quite drowning in today's deluge of LC bugs! |
| 07:32 | <annevk> | not the only one |
| 07:50 | <Hixie> | othermaciej: IIRC, the issue was known at the time the feature was designed, and either there's a workaround or we figured IE6 was so insecure at this point that there wasn't much point worrying about it |
| 07:50 | <Hixie> | but i forget the details |
| 07:50 | <Hixie> | nobody has raised the issue of IE6 with me recently as far as I know though |
| 07:51 | <Hixie> | on another note, does anyone other than AryehGregor and Julian have an opinion on whether we should drop rel=help or add a:link[rel~=help] to the UA style sheet? |
| 07:51 | <annevk> | Hixie, I looked on public-webrtc and other than the usual debate didn't see the forking thing you mentioned |
| 07:51 | <annevk> | Hixie, was that offlist? |
| 07:51 | <Hixie> | (with cursor:hlep, that is) |
| 07:52 | <Hixie> | annevk: it was a private e-mail |
| 07:52 | <annevk> | cursor:help seems kind of a neat feature |
| 07:52 | <annevk> | almost easter egg, but still |
| 07:53 | <annevk> | the kind of attention to detail some people will appreciate, like me :) |
| 07:53 | <zcorpan> | i recall in windows, stuff that have cursor:help are *buttons*, not links |
| 07:53 | <Hixie> | on the web, help is usually found in link form |
| 07:54 | <Hixie> | eh, i guess we can try adding this style rule and see how it's taken |
| 07:54 | <annevk> | that's a good point, not sure whether that would actually make good UI |
| 07:54 | <Hixie> | and if nobody cares, we can drop it |
| 07:54 | <annevk> | sorry |
| 07:54 | <zcorpan> | we need more easter eggs in html |
| 07:55 | <Hixie> | not sure everyone agrees with that |
| 07:55 | <Hixie> | but i do! |
| 07:55 | <Hixie> | :-) |
| 07:55 | <zcorpan> | i'll file a LC comment |
| 07:55 | <Hixie> | on more easter eggs? |
| 07:55 | <zcorpan> | yeah |
| 07:55 | <Hixie> | ok but unless you can name at least 20 existing ones in private e-mail, i'm not adding any for the bug :-P |
| 07:56 | <annevk> | Hixie, btw, the writing HTML section does not really mention <svg> and <math> as the elements that trigger special subtree behavior and that <foreignObject> etc. escape out of it again |
| 07:56 | <Hixie> | annevk: is that feedback on the normative aspects or on the expository aspects? |
| 07:56 | <zcorpan> | Hixie: don't have time to hunt for existing ones, sorry! |
| 07:57 | <zcorpan> | maybe instead i should try to come up with a good easter egg to add before filing a bug |
| 07:58 | <Hixie> | if it's an easter egg i recommend mailing me the suggestion privately |
| 07:58 | <Hixie> | so i can try to slip it in a huge update |
| 07:58 | <zcorpan> | k |
| 08:00 | <annevk> | Hixie, I guess it is complete, but it's kind of hard |
| 08:00 | <Hixie> | we can add a non-normative section explaining it better |
| 08:00 | <Hixie> | file a bug saying that? |
| 08:00 | <annevk> | http://twitter.com/karlpro/status/98606552990236672 nice |
| 08:01 | <annevk> | Hixie, Matt May filed something to that extent, I'll add a comment there |
| 08:01 | <Hixie> | cool, thanks |
| 08:04 | <annevk> | oh |
| 08:04 | <annevk> | I do realize now it does not define e.g. <svg><base></svg> properly |
| 08:04 | <annevk> | because in the "SVG model" section it says you can use HTML elements anywhere |
| 08:04 | <Hixie> | that's non-conforming, no? |
| 08:05 | <Hixie> | i'm not familiar with that section of the spec these days |
| 08:05 | <Hixie> | "svg model" doesn't seem to appear in the html spec |
| 08:06 | <annevk> | it's called "SVG" |
| 08:06 | <annevk> | but it doesn't say that, it says you can use non-HTML elements anywhere |
| 08:07 | <Hixie> | doesn't it just defer to the SVG spec? |
| 08:07 | <annevk> | not completely, it defines that foreignObject can contain "flow content" |
| 08:08 | <Hixie> | it defines that if foreignObject is used to escaped to HTML, it has to contain flow content, yeah |
| 08:36 | <annevk> | when adding abort() it seems you did not add a domintro entry |
| 08:36 | <annevk> | http://html5.org/tools/web-apps-tracker?from=6348&to=6349 |
| 08:36 | <annevk> | idea for web-apps-tracker: file bug regarding this change |
| 08:43 | <zcorpan> | annevk: yeah that'd be nice |
| 08:44 | <zcorpan> | annevk: might be hard to set the right component though |
| 09:09 | <annevk> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=13544 |
| 09:09 | <annevk> | nessy, so Microsoft I guess, who else? |
| 09:09 | <annevk> | they really want to implement TTML? |
| 09:09 | <annevk> | is that the IE Team or some other Microsoft division? |
| 09:10 | <nessy> | there are guys at Google that want multiple format support in WebKit, too |
| 09:10 | <nessy> | I don't think anyone will want to support the full TTML spec |
| 09:10 | <annevk> | really, what other formats does Google want? |
| 09:10 | <nessy> | but many want to parse the basic format |
| 09:11 | <nessy> | I've listed a few :-) |
| 09:11 | <annevk> | you listed TTML and WebVTT |
| 09:11 | <annevk> | the basic format? sounds like interop hell |
| 09:11 | <nessy> | in the example there's also srt and mpsub |
| 09:11 | <annevk> | oh |
| 09:11 | <nessy> | TTML is already interop hell |
| 09:11 | <annevk> | that's going to be even more fun |
| 09:11 | <nessy> | I don't really care - I regard anything that goes beyond WebVTT as "specialised" implementations |
| 09:11 | <annevk> | if SRT is going to be implemented after all we should just merge WebVTT with it again |
| 09:12 | <nessy> | no, that doesn't make sense |
| 09:12 | <annevk> | it does, because if SRT is going to be supported by everyone WebVTT makes no chance |
| 09:12 | <annevk> | the whole point of doing WebVTT is that we are not doing anything else |
| 09:12 | <nessy> | there are too many srt files out there that have specialised extensions that don't fit with webvtt |
| 09:12 | <annevk> | if we do something else it's kind of a lost cause |
| 09:13 | <nessy> | don't worry about srt |
| 09:13 | <nessy> | the key point is that all browsers will implement webvtt, so it becomes the baseline format |
| 09:13 | <annevk> | no |
| 09:13 | <annevk> | the key point is what the dominant browsers implement |
| 09:13 | <nessy> | that' webvtt |
| 09:14 | <nessy> | it's why we are creating a webvtt WG, so MS can feel comfortable with it |
| 09:14 | <nessy> | well: actually contribute to it |
| 09:15 | <zcorpan> | there's no schema.org WG |
| 09:15 | <nessy> | I can only say what I was told by MS |
| 09:16 | <nessy> | I don't care what they do with other specs |
| 09:16 | <nessy> | is schema.org developed by WHATWG? |
| 09:17 | <zcorpan> | no |
| 09:17 | <nessy> | there's your answer |
| 09:17 | <nessy> | unfortunately |
| 09:18 | <zcorpan> | what? MS hates WHATWG? |
| 09:18 | <zcorpan> | i thought they said it was because WHATWG doesn't have a patent policy, but schema.org doesn't have one either |
| 09:19 | <annevk> | nessy, if they also implement SRT I am highly skeptical for WebVTT |
| 09:19 | <annevk> | nessy, also, if they implement SRT I want a specification for SRT |
| 09:20 | <annevk> | nessy, and don't really see the point in pursuing WebVTT |
| 09:20 | <nessy> | no, there's nothing to worry about srt - it's much too simple to support much of the use cases I've come across |
| 09:20 | <nessy> | srt and webvtt are worlds apart |
| 09:20 | <annevk> | there's plenty to worry |
| 09:20 | <annevk> | for one there's no spec |
| 09:20 | <nessy> | there's no way you're going to get the webvtt functionality included in srt without breaking many of the srt implementations |
| 09:21 | <nessy> | the wikipedia page is as good as it gets for srt |
| 09:21 | <nessy> | but I can register a IETF I-D if you prefer |
| 09:21 | <annevk> | that's not really acceptable |
| 09:21 | <zcorpan> | seems to cover enough use cases to make as widespread as it is |
| 09:21 | <annevk> | and if SRT addresses 90% I'm not really sure why we should go to the trouble of implementing WebVTT |
| 09:22 | <nessy> | only because people haven't really got a choice - this far, we had the choice between simple and horrendously complex caption formats - webvtt sits in the middle |
| 09:22 | <hsivonen> | zcorpan: how do you know that Google, MS and Y! don't have a trilateral patent deal for schema.org? |
| 09:22 | <zcorpan> | hsivonen: i don't |
| 09:22 | <zcorpan> | maybe they do |
| 09:26 | <nessy> | srt does not address 90% of the use cases - it just seems this way because it's all we had available this far on the Web |
| 09:29 | <zcorpan> | everyone thought it would be impossible to specify html parsing without breaking compat |
| 09:29 | <zcorpan> | until it was done |
| 09:34 | <zcorpan> | some day i should take some time to read about ie10. just learned they dropped conditional comments |
| 09:50 | <AnselmBradford> | hi whatwg, does anyone know a use-case for using the embed element over the object element, other than to support old versions of FF? Is its inclusion in the spec purely to codify its use in the wild? |
| 09:54 | <annevk> | I think with <embed> you do not need the typemustmatch attribute |
| 09:55 | <annevk> | and therefore with <embed> you also have the feature of interpreting everything that comes over the wire according to a type under your control |
| 09:55 | <annevk> | overall though the features are largely similar |
| 09:56 | <annevk> | public-fx is amusing |
| 09:56 | <annevk> | "I think, we can safely assume, that there are only experimental decorative projects outside using CSS animation currently and a huge amount of content using SMIL/SVG." |
| 10:05 | <smaug____> | that sounds right |
| 10:06 | <smaug____> | though, not if the context is the web only |
| 10:08 | <AnselmBradford> | annevk: Thanks for the response. There's a typemustmatch attribute? I know "type" is optional on <embed>, but it's this way on <object> too |
| 10:13 | <annevk> | yes there is on <object> |
| 10:13 | <annevk> | type has different semantics on <embed> and <object> |
| 10:20 | <AnselmBradford> | annevk: ahh gotcha, thanks. I was looking at the spec PDF... which is outdated on that attribute. |
| 10:23 | <AnselmBradford> | annevk: version I had anyway... got the new one :) |
| 10:24 | <hsivonen> | nessy: wait what? are there folks at Google who want to add non-WebVTT formats to WebKit? Why? Why not make sure WebVTT covers enough use cases? Do those other formats have proper specs? |
| 10:24 | <nessy> | hsivonen: it's not really decided yet, but some people would like to see other formats supported, too |
| 10:25 | <jgraham> | That sounds like every kind of bad |
| 10:25 | <hsivonen> | nessy: why on earth? are the people who want it experienced with working on browsers? |
| 10:25 | <nessy> | no but they are experienced with captions and have seen many formats float by |
| 10:25 | <hsivonen> | nessy: implementing other formats seems like a terrible idea for interop |
| 10:25 | <annevk> | I guess you can find people everywhere who want something else, does not mean they need to be catered for (e.g. the UMP people at Google) |
| 10:25 | <nessy> | hsivonen: I agree |
| 10:26 | <hsivonen> | annevk: so why isn't UMP off the charter yet? |
| 10:26 | <annevk> | The W3C and chairs are somehow extra-sensitive to this feedback |
| 10:27 | <annevk> | I don't really care either way |
| 10:27 | <jgraham> | It also seems like a terrible idea for Google/WebKit. Having to support N > 1 formats is much more code to maintain than supporting N = 1 formats |
| 10:27 | <annevk> | If I would work on CORS again it would likely be on a test suite rather than trying to resolve that gap |
| 10:27 | <hsivonen> | is this yet another case where non-Chrome folks at Google request stuff and the Chrome team isn't good enough at saying "no"? |
| 10:27 | <annevk> | Some fights are not really worth it |
| 10:27 | <annevk> | hsivonen, pretty much |
| 10:28 | <annevk> | jgraham, well they just hire some more people; if you see the amount of stuff that gets added to WebKit these days... |
| 10:28 | <nessy> | hsivonen: let's say I have spend many hours arguing back and forth |
| 10:29 | <annevk> | jgraham, see http://peter.sh/ |
| 10:29 | <jgraham> | annevk: Well yeah having infinte resources isn't good for the soul. But still at some point the complexity will cause issues |
| 10:29 | <nessy> | thing is: I know there will be other formats (call them "proprietary" if you like, cause even if specs are open, they are not cross-browser supported) and I think <source> is probably the best solution to deal with this situation |
| 10:30 | <hsivonen> | do we have some kind of canned article for explaining why optional features suck for the Web and why should shouldn't propose optional features? |
| 10:30 | <nessy> | plus making sure webvtt is baseline format |
| 10:30 | <nessy> | in this case I actually think it makes sense - just to avoid the content sniffing problem |
| 10:30 | <nessy> | if we had <source> in <img>, we could avoid a lot of pain |
| 10:31 | <annevk> | <img> works just fine |
| 10:31 | <hsivonen> | I wonder how much the company-internal culture at Google has shifted to it being OK to have Chrome-only optional stuff and optimizing Google services for Chrome |
| 10:31 | <Ms2ger> | If only we could just throw out everything and start over, we could avoid even more pain |
| 10:31 | <annevk> | unfortunately there's no longer an XHTML WG |
| 10:32 | <annevk> | because otherwise I would suggest you join it :p |
| 10:32 | <jgraham> | hsivonen: From the outside it doesn't look like it has shifted much. That has always been OK |
| 10:32 | <hsivonen> | how would anyone suggest optional non-WebVTT formats without that the assumption that doing non-interoperable Chrome-only stuff is ok |
| 10:33 | <hsivonen> | how does Opera work with G+, BTW? I read somewhere that Opera is not "supported" but I don't know what that means |
| 10:34 | <annevk> | notifications are not enabled |
| 10:34 | <annevk> | the rest seems okayish |
| 10:34 | <annevk> | notifications toolbar that is |
| 10:35 | <nessy> | <img> still needs content sniffing to determine whether the resource will be decodable |
| 10:35 | <annevk> | yeah and it works fine |
| 10:35 | <nessy> | I hear from mobile people that it's a real pain |
| 10:36 | <zcorpan> | what's the pain? |
| 10:36 | <nessy> | delays and extra bandwidth use |
| 10:37 | <annevk> | huh? |
| 10:37 | <nessy> | can you please add whatever well thought-out objections to supporting multiple formats into the bug, so the discussion is out in the open? |
| 10:37 | <zcorpan> | when the page uses image formats that are not supported? |
| 10:38 | <nessy> | stuff like this, I guess: http://thomasjaehnel.com/blog/2009/11/attacks-based-on-content-sniffing.html |
| 10:39 | <nessy> | (obviously wasn't my argument :-) |
| 10:39 | <nessy> | I agreed to take the discussion to the group, so let's have it |
| 10:40 | <annevk> | that attach document is not about <img> |
| 10:40 | <annevk> | attack8 |
| 10:40 | <annevk> | * |
| 10:40 | <annevk> | damnit |
| 11:30 | <gsnedders> | hsivonen: We've not officially supported by any Google stuff. |
| 11:31 | <gsnedders> | hsivonen: It's not just +. The only three that have been really painful was Gmail originally, Gmail v.2, and Wave. |
| 11:49 | <annevk> | zcorpan, briefly thought about moving html5-diff to Anolis; main problem is that xspec xrefs can only go to a multipage with script enabled (does not link to specific pages automatically) |
| 11:50 | <annevk> | zcorpan, so either Anolis would have to be updated, script-based redirects would have to be deemed acceptable, or we link to the singlepage version |
| 11:54 | <zcorpan> | annevk: personally i'm fine with either of those except link to singlepage |
| 11:56 | <annevk> | does W3C multipage do script-based redirects? |
| 11:57 | <annevk> | making Anolis smarter would be ideal of course |
| 11:58 | Philip` | supposes the way to do it automatically in Anolis would be to download http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js and parse the first line to get the redirects |
| 12:00 | <annevk> | that might not be too complicated I guess |
| 12:00 | <annevk> | basically https://bitbucket.org/ms2ger/specification-data/src/bd982d2974a1/xrefs/dom/html.json needs to be updated every once and a while |
| 12:01 | <zcorpan> | s/and/in/ |
| 12:01 | <annevk> | generating it from that URL might not be too hard |
| 12:01 | <annevk> | could be somewhat standalone |
| 12:01 | <annevk> | also has the benefit of adding missing entries |
| 12:03 | <annevk> | I can definitely do something like that later today, thanks Philip`! |
| 12:08 | <Ms2ger> | Terms with spaces might be annoying |
| 12:09 | <annevk> | hmm yeah |
| 12:10 | <hsivonen> | what would you call an attribute that gives the localization key for a UI string? |
| 12:12 | <annevk> | Ms2ger, we could keep name the current html.json html-base.json, and generate the new copy based on html-base.json and fragment-links.js |
| 12:13 | <annevk> | hsivonen, locale? |
| 12:13 | <annevk> | hsivonen, assuming you mean "en", "nl" etc. |
| 12:15 | <hsivonen> | annevk: no, I mean like isindexPrompt |
| 12:15 | <hsivonen> | annevk: the keys for UI string that get locale-specific values |
| 12:15 | <annevk> | hsivonen, oh, just isIndexPrompt? |
| 12:16 | <annevk> | hsivonen, use some approximation of what it is for / what it will say in English |
| 12:16 | <hsivonen> | annevk: I mean keys that you use to indentify localizable UI strings |
| 12:16 | <hsivonen> | annevk: localizationkey is a bit long |
| 12:16 | <hsivonen> | *identify |
| 12:17 | <annevk> | I'm afraid I don't understand |
| 12:17 | <hsivonen> | so you have a UI |
| 12:18 | <hsivonen> | it has localizable strings |
| 12:18 | <hsivonen> | for each string, you have an id |
| 12:18 | <hsivonen> | so that for each locale, you have mappings from the ids to strings in the language of the locale |
| 12:18 | <annevk> | right |
| 12:18 | <hsivonen> | suppose the page title is localizable |
| 12:19 | <hsivonen> | <h1>Pagetitle</h1> |
| 12:19 | <hsivonen> | and then you want to mark up the id of the string so that localization machinery can fill in the page title in another language |
| 12:19 | <hsivonen> | like |
| 12:20 | <hsivonen> | <h1 localization-key="pagetitle">Beekeeping</h1> |
| 12:20 | <hsivonen> | localization-key is a bit long |
| 12:20 | <Philip`> | "localizationkey is a bit long" - how about l13y? |
| 12:20 | <annevk> | aaah |
| 12:20 | <hsivonen> | Philip`: well, it could be just l10n |
| 12:20 | <hsivonen> | Philip`: but are we OK with numbers in attribute names in HTML? |
| 12:21 | <Philip`> | They're in element names, so why not? |
| 12:21 | <annevk> | which element name has a number? |
| 12:21 | <hsivonen> | <h1>! |
| 12:21 | <Philip`> | <h1> |
| 12:21 | <annevk> | doh |
| 12:21 | <hsivonen> | Philip`: good point |
| 12:21 | <Philip`> | plus many more |
| 12:22 | <annevk> | localize="" |
| 12:22 | <annevk> | localizeid="" |
| 12:22 | <annevk> | l10nid="" |
| 12:22 | <annevk> | localizationid="" |
| 12:23 | <annevk> | curious to know where this would be used |
| 12:23 | <Ms2ger> | Better than entities, I guess |
| 12:24 | <hsivonen> | annevk: l10nid was a possibility I was considering, but I thought it looked a bit ugly |
| 12:25 | <annevk> | localizeid="" or just localize="" seems kind of okay to me |
| 12:25 | <Philip`> | l10nid makes me think of meteor showers |
| 12:25 | <annevk> | just l10n is fine too I guess although a little awkward |
| 12:25 | <annevk> | Ms2ger, oh is this for Gecko? |
| 12:26 | <annevk> | finally getting rid of DTD madness :) |
| 12:26 | <Ms2ger> | No idea |
| 12:26 | <annevk> | is RDF next? |
| 12:26 | <annevk> | oh |
| 12:26 | <annevk> | be back later |
| 12:27 | <hsivonen> | annevk: yes, this is for Gecko. the proposal that I'm bikeshedding now says l10n_id, but underscores are obviously uncool for HTML |
| 12:27 | <smaug____> | for any l10n proposals, I'd ask what Pike thinks about it |
| 12:27 | <annevk> | hyphens are uncool too |
| 12:27 | <annevk> | generally |
| 12:28 | <hsivonen> | annevk: hyphens are OK, if there's a set of attributes: l10n-id, l10n-foo, l10n-bar, etc. |
| 12:28 | <hsivonen> | smaug____: I sort of assumed this has already been past Pike |
| 12:28 | <annevk> | i guess, but do we need more than one? |
| 12:29 | <hsivonen> | annevk: I don't know yet |
| 12:29 | <zcorpan> | hsivonen: can't id="" be used? |
| 12:29 | <hsivonen> | zcorpan: I don't know |
| 12:29 | <annevk> | pointer to bug report? |
| 12:30 | <smaug____> | hsivonen: what you mean "past Pike" |
| 12:30 | <smaug____> | hsivonen: he happens to have lots of experience in l10n area |
| 12:30 | <hsivonen> | smaug____: I assumed that Pike has already seen this an not vetoed |
| 12:30 | <hsivonen> | smaug____: but I don't know if that's the case |
| 12:31 | <smaug____> | hsivonen: what is this about btw? |
| 12:31 | <smaug____> | localizing what? |
| 12:31 | <smaug____> | and where? |
| 12:31 | <hsivonen> | smaug____: XUL first, probably HTML later |
| 12:31 | <hsivonen> | smaug____: in Firefox chrome first. maybe elsewhere later |
| 12:32 | <nessy> | l10n-key ? |
| 12:32 | <nessy> | locale-key ? |
| 12:32 | <hsivonen> | nessy: locale-key would imply the wrong thing |
| 12:32 | <nessy> | yeah, I guess |
| 12:33 | <hsivonen> | The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=566906 |
| 12:34 | <zcorpan> | what's L20n? |
| 12:34 | <hsivonen> | zcorpan: I think it's the next level of L10n |
| 12:35 | <smaug____> | https://wiki.mozilla.org/L20n has some links |
| 12:37 | <zcorpan> | Localizilizziliziation |
| 12:37 | <nessy> | did you count this? |
| 12:38 | <zcorpan> | my text editor did |
| 12:38 | <nessy> | hehe |
| 12:39 | <zcorpan> | well then obviously the attribute should read l20n-something rather than l10n-something |
| 12:44 | <Ms2ger> | "Tab tries to explain the difference between semantic markup and stylistic presentation to the MS folks" |
| 12:44 | <Ms2ger> | TabAtkins++ |
| 12:44 | <hsivonen> | Ms2ger: is this CSS WG minutes? |
| 12:44 | <Ms2ger> | Yes |
| 12:44 | <hsivonen> | did the actual explanation get minuted? |
| 12:46 | <Ms2ger> | Doesn't look like it |
| 12:47 | <hsivonen> | Ms2ger: :-( |
| 12:47 | <Ms2ger> | Maybe Tab can write it out |
| 12:49 | <gsnedders> | From memory. Word for word. |
| 12:49 | <Ms2ger> | He's a smart guy |
| 12:50 | <jgraham> | Maybe he did it using drawings of foxes |
| 13:15 | <smaug____> | ahaa, a new idea for the mutation events replacement. /me needs to paper and pen |
| 13:15 | <smaug____> | s/to/a/ |
| 13:16 | <gsnedders> | smaug____: Not to a keyboard and a text editor? |
| 13:16 | <zcorpan> | replace it with foxes? |
| 13:18 | <smaug____> | in some cases it is easier to just use paper |
| 13:40 | <smaug____> | and the idea might even work :) |
| 13:40 | zcorpan | was unaware of http://www.ietf.org/mail-archive/web/ietf-types/current/msg01115.html |
| 13:47 | <hsivonen> | application/font-* instead of font/* shows how hard it is to work with IANA/IETF |
| 13:50 | <zcorpan> | seems that type still isn't registered |
| 13:55 | <MikeSmith> | hsivonen: thanks for the heads-up about that bug related to es5.github.com |
| 13:55 | <annevk> | hmm smaug left |
| 13:56 | <annevk> | I was wondering whether we could call the new stuff modification |
| 13:56 | <MikeSmith> | hsivonen: I'm glad for my lack of understanding on how to properly set the encoding on an external CSS stylesheet :) |
| 13:56 | <hsivonen> | MikeSmith: :-) |
| 14:02 | <MikeSmith> | othermaciej: my earlier LC bug count was way off, btw |
| 14:02 | <MikeSmith> | I think I was counting only open bugs |
| 14:03 | <MikeSmith> | the actual count of bugs submitted after Oct 1 until today is currently 1502 |
| 14:11 | <jgraham> | Oh, that explains all the email I have had to ignore |
| 14:13 | <annevk> | we had a six months last call? |
| 14:14 | <MikeSmith> | kind of |
| 14:14 | <MikeSmith> | because decision was that all bugs submitted after Oct 1 would be treated just the same as bugs submitted during the formal LC window |
| 14:16 | <annevk> | i see |
| 14:38 | <bga_> | hm. we still haven't api to gzip compress "ajax" POST data at clientside. it will sufficient reduce world traffic |
| 14:39 | <Ms2ger> | Doubtful |
| 14:39 | <bga_> | i can compress using canvas api and toDataURL but its hack |
| 14:41 | <annevk> | smaug____, is your new idea going to please everyone? |
| 14:41 | <annevk> | smaug____, maybe we can call the new stuff "modification" rather than "mutation"? might make it easier to distinguish between the two |
| 14:42 | <bga_> | Ms2ger anyway that api will be usefull |
| 14:42 | <bga_> | when i send big json from client to server |
| 14:43 | <bga_> | traffic == money |
| 14:43 | <bga_> | you can save my money :) |
| 14:44 | <annevk> | write your own impl |
| 14:44 | <bga_> | pure js? |
| 14:44 | <annevk> | sure |
| 14:44 | <bga_> | or spec? |
| 14:44 | <annevk> | no |
| 14:44 | <bga_> | js too slow |
| 14:44 | <Ms2ger> | Doubtful |
| 14:45 | <bga_> | https://gist.github.com/519305/51a48139351b3fae048504a6a8d7631c5ae991db |
| 14:45 | <bga_> | wrong |
| 14:45 | <bga_> | https://gist.github.com/519305 |
| 14:46 | <bga_> | its gzip like algo for compress js source |
| 14:46 | <bga_> | i made it for js1k |
| 14:47 | <bga_> | but it compress 70k 1 min |
| 14:47 | <bga_> | too slow |
| 14:47 | <bga_> | we need native api imho |
| 14:51 | <MikeSmith> | annevk: btw, I did request a new dvcs rep for cors and hopefully it'll be available today or tomorrow |
| 14:53 | <Philip`> | bga_: That doesn't look much like the gzip algorithm |
| 14:54 | <Philip`> | gzip in C usually goes at over 10MB/sec, and a JS port shouldn't be more than maybe ten or a hundred times slower |
| 14:55 | <bga_> | Philip` its pattern compression. sorry |
| 14:56 | <bga_> | deflate is much simpler |
| 14:56 | <Philip`> | If your code takes a minute for 70KB then it's just because your algorithm is incredibly inefficient, not because of any fundamental problem with JS :-) |
| 14:58 | <timeless> | jcranmer, `It is frequently desirable to split large binary files into multiple parts` `for transmissio n over the Internet. Such binaries are often rendered` I like the second word of the second line... |
| 14:58 | <jgraham> | Yes, I think jszip (which solves a similar but not identical problem) is much faster than that |
| 14:58 | <jgraham> | and using typed arrays or something might be even faster |
| 14:59 | <timeless> | MikeSmith: yes, bugzilla doesn't encode email addresses for comment lines, it stores user ids, so when you change your email address, any place where that was used automatically (reporter, cc, assignee, qa, commenter, ...) will be updated |
| 14:59 | <MikeSmith> | right |
| 15:00 | <MikeSmith> | I just can't remember whether end users can change their account/addresses themselves |
| 15:00 | <MikeSmith> | I know I can in the admin UI for the W3C bugzilla |
| 15:00 | <Ms2ger> | I think AryehGregor couldn't |
| 15:01 | <timeless> | othermaciej: i'm `shocked` to hear that `text/html-sandboxed` isn't doing what someone wanted... oh wait, i think i suggested it was likely to fail :) |
| 15:01 | <MikeSmith> | annevk: http://dvcs.w3.org/hg/cors/ |
| 15:01 | <jgraham> | They can't on W3C bugzilla |
| 15:01 | <jgraham> | I thought they could on ohter bugzilla |
| 15:02 | <jgraham> | s |
| 15:02 | <MikeSmith> | annevk: you want me to copy the source over, or will you? |
| 15:02 | <annevk> | open feedback |
| 15:02 | <annevk> | MikeSmith, if you can |
| 15:02 | <annevk> | i can do it too actually |
| 15:02 | <annevk> | let me do it :) |
| 15:05 | <MikeSmith> | annevk: ok |
| 15:06 | <MikeSmith> | annevk: once you get it set up, I'd suggest also putting a redirect from the old cvs location to the dvcs one |
| 15:07 | <annevk> | yeah |
| 15:13 | <smaug____> | annevk: the idea won't please Google |
| 15:14 | <smaug____> | since they want, for not-clear-to-me reason the almost-async handling |
| 15:14 | <timeless> | hsivonen: `term` might work re localization key names |
| 15:15 | <hsivonen> | timeless: thanks |
| 15:15 | timeless | is obviously a few hours behind |
| 15:16 | <smaug____> | annevk: actually I'm investigating two different approaches now. |
| 15:18 | <timeless> | MikeSmith: the w3 bugzilla doesn't allow it |
| 15:18 | <timeless> | you need to use https://bugzilla/editusers.cgi to do it as an admin |
| 15:19 | <timeless> | normally bugzilla does allow users to update their email addresses |
| 15:19 | <MikeSmith> | timeless: OK |
| 15:20 | <MikeSmith> | so I will wait to hear back from AryehGregor |
| 15:20 | <annevk> | Ms2ger, I will place my script that generates a better html.json (once done) in specification-data, okay? |
| 15:20 | <Ms2ger> | K |
| 15:20 | <timeless> | > That's much too early. Prepare to fast-forward! |
| 15:20 | <annevk> | Ms2ger, you just parse it using json right? |
| 15:20 | <annevk> | Ms2ger, so the generated copy can be less nice? |
| 15:21 | <timeless> | > We are at now, now |
| 15:21 | <Ms2ger> | Sure |
| 15:21 | timeless | hearts ludicrous speed! |
| 15:21 | <Ms2ger> | I hope you're generating it with a json serializer as well ;) |
| 15:22 | <annevk> | I'm using json from Python 2.6 |
| 15:22 | <annevk> | and I use some string replacements hacks on the original data |
| 15:34 | <annevk> | wow that was easier than expected somehow |
| 15:35 | <annevk> | I guess I should add some comments so Ms2ger has less reason to laugh |
| 15:35 | <annevk> | and rename my variables from test1 etc. |
| 15:35 | <Ms2ger> | I don't need reasons to laugh, thought you knew that ;) |
| 15:43 | <annevk> | Ms2ger, who uses "non-conforming element"? |
| 15:43 | <annevk> | I'm removing it for now as I cannot find its new links |
| 15:43 | <annevk> | link* |
| 15:44 | <Ms2ger> | If editcommands doesn't, nobody, I think |
| 15:46 | <smaug____> | hsivonen: unfortunately we need to experiment quite a bit with menu/command handling, since the spec is just not quite good |
| 15:46 | <smaug____> | hsivonen: I wonder if we could, in gecko, have a pref to enable our experimental menu/command handling |
| 15:48 | <annevk> | Ms2ger, https://bitbucket.org/ms2ger/specification-data/changeset/26462f44156d |
| 15:49 | <annevk> | html.py has the "fun" |
| 15:49 | <hsivonen> | smaug____: does the Experiment Markup Language (XML) not work for experimentation on the DOM level? |
| 15:50 | <hsivonen> | smaug____: I'd really like to avoid landing browser-specific HTML parsing algorithm changes on the trunk |
| 15:50 | <smaug____> | hsivonen: even with a pref or #ifdef? |
| 15:51 | <hsivonen> | smaug____: can we at least have a round of discussion on a multivendor forum before we go there? |
| 15:51 | <hsivonen> | smaug____: I supposed a pref is a possibility |
| 15:51 | <hsivonen> | *suppose |
| 15:52 | hsivonen | leaves the keyboard to get to places that have closing times |
| 15:52 | <smaug____> | does anyone else edit html spec than Hixie? |
| 15:55 | <Ms2ger> | No |
| 16:03 | <dglazkov> | good morning, Whatwg! |
| 16:03 | <dglazkov> | and especially to you, cranky-pants jgraham |
| 16:03 | <Ms2ger> | Good evening, dglazkov |
| 16:03 | <annevk> | heh |
| 16:07 | <jgraham> | I'm not cran… |
| 16:07 | <jgraham> | OK I am |
| 16:08 | <jgraham> | I can't deny it |
| 16:08 | Ms2ger | pats jgraham on the back |
| 16:08 | <annevk> | sweet, #fx logs |
| 16:18 | <Ms2ger> | Philip`, what do you think about putting up a JSON file with the date from fragment-links.js? |
| 16:20 | <annevk> | are you offended by my code? |
| 16:21 | <Ms2ger> | No, by the fact it's necessary |
| 16:21 | <Ms2ger> | (And brittle) |
| 16:22 | <Ms2ger> | Did you file a bug to remove HTMLElement.{id,className,classList} already? |
| 16:25 | <Philip`> | Ms2ger: "date"? (Do you mean data?) |
| 16:25 | <Ms2ger> | Yes |
| 16:26 | <Philip`> | Is the .js file plus regexps to extract the data not sufficient? |
| 16:28 | <annevk> | Ms2ger, I didn't |
| 16:28 | Philip` | looks at the code |
| 16:29 | <Philip`> | Oh, JSON doesn't like single quotes? How silly |
| 16:29 | <annevk> | going from single to double and not using escapes would already help a lot |
| 16:31 | <Ms2ger> | Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=13610 |
| 16:31 | <Philip`> | If someone wants to update http://code.google.com/p/html5/source/browse/trunk/spec-splitter/spec-splitter.py#328 then I can deploy the new code |
| 16:32 | <Ms2ger> | I'd do that if I had access |
| 16:33 | <annevk> | I think there might be a couple of other things HTML has not updated on yet |
| 16:34 | <annevk> | Ms2ger, you do now |
| 16:35 | <annevk> | Ms2ger, btw, I wonder how controversial that bug is going to be |
| 16:36 | <Ms2ger> | We'll see |
| 16:40 | <annevk> | the whole section on DOM Trees is rather outdated |
| 16:43 | <annevk> | filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=13612 on using cloning steps |
| 16:45 | <Ms2ger> | Look ma, I can do SVN |
| 16:48 | <othermaciej> | MikeSmith: seems fair to count those |
| 16:49 | <othermaciej> | MikeSmith: I wonder how that compares to the prior 9-month period |
| 16:51 | <Ms2ger> | Philip`, feel like deploying? :) |
| 16:56 | <Philip`> | Ms2ger: Done, and regenerated http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js |
| 17:05 | <Ms2ger> | Ta |
| 17:11 | <leaverou> | hi everyone |
| 17:12 | <leaverou> | not sure if this is the right place for this, but I don't think inline event handlers are setting a good example here http://www.whatwg.org/specs/web-apps/current-work/#menus-intro |
| 17:12 | <Ms2ger> | Meh |
| 17:13 | <annevk> | leaverou, sometimes inline event handlers are fine |
| 17:13 | <smaug____> | leaverou: why not? |
| 17:13 | <smaug____> | I don't see anything bad with those inline event handlers |
| 17:14 | <smaug____> | (the menu handling itself will, I hope, change a bit) |
| 17:14 | <leaverou> | because the spec example is copied by tutorials all over and new authors will get the impression that inline event handlers are fine |
| 17:14 | <zewt> | it sounds like you're under the impression that they're "evil" |
| 17:14 | <leaverou> | so it's indirectly (?) promoting bad practices |
| 17:14 | <smaug____> | is it a bad practice? |
| 17:15 | <leaverou> | in most cases it is, it violates separation of concerns |
| 17:16 | <zewt> | do you want to write 3x as much code for no benefit? heh |
| 17:17 | <leaverou> | zewt: are you going to praise the <font> tag next? :) |
| 17:17 | <zewt> | sarcasm doesn't lead to convincing arguments |
| 17:18 | <leaverou> | and it's hardly 3x as much code, just like presentational HTML over CSS, it's actually less code when repetition is involved |
| 17:18 | <leaverou> | also, polluting the global namespace with all these functions is a JS bad practice |
| 17:18 | <Ms2ger> | Meh |
| 17:19 | <zewt> | indeed, meh |
| 17:19 | <zewt> | sounds like a typical "xxx considered harmful" article |
| 17:19 | <leaverou> | "meh" is even a less convincing argument than sarcasm |
| 17:20 | <leaverou> | anyway, I'm not here to convince people for things that are almost universally accepted in the indurstry, just to notify about it in case it was overlooked |
| 17:20 | <annevk> | I would be careful with universally acceptedd |
| 17:20 | <annevk> | obviously it is not here |
| 17:20 | <Ms2ger> | I would challenge "almost universally accepted in the indurstry" |
| 17:20 | <Ms2ger> | If I cared |
| 17:20 | <Philip`> | The HTML spec even has examples with uppercase tags, which I'm sure every sane person in the world thinks is crazy |
| 17:21 | <Philip`> | so it's not trying to be a guide to any set of best practices |
| 17:22 | <leaverou> | Philip`: that's a good point. |
| 17:22 | <AryehGregor> | Philip`, it has examples with *mixed*-case tags. |
| 17:22 | <AryehGregor> | I'm pretty sure it has something like <BloCkquoTE> somewhere. |
| 17:22 | <AryehGregor> | The philosophy it adopts is that if something is valid, it wants to use it occasionally in examples so people don't assume it's wrong because they never see it. |
| 17:23 | <AryehGregor> | If inline event handlers were always a bad idea, the spec would say they're invalid. |
| 17:23 | <AryehGregor> | There's no class of things called "fully conforming but we think they shouldn't be used", that would be silly. |
| 17:24 | <AryehGregor> | If we think they shouldn't be used, we should make them at least raise a warning, and if we think it's fine to use them, why not use them in examples? |
| 17:24 | <leaverou> | AryehGregor: Ok, that's a valid argument and I agree. Btw, I never said inline event handlers are always bad, just in many cases. |
| 17:24 | <karlcow> | AryehGregor: it is a binary reasoning :) |
| 17:27 | jgraham | wonders if anyone has checked the uppercase vs lowercase letters in tags in examples for hidden messages |
| 17:29 | <AryehGregor> | MikeSmith, thanks for the Bugzilla component! And I can't change my e-mail address on Bugzilla, so I'd appreciate it if you changed it to ayg⊙an |
| 17:30 | <Ms2ger> | jgraham, last time I checked, they called you a cranky-pants |
| 17:30 | <AryehGregor> | (I'm trying to standardize when it comes to publicly-visible addresses, so as not to hopelessly confuse everyone with Simetrical⊙gc vs. AryehGregor⊙gc vs. ayg⊙an vs. all of those with plus-addressing vs. a few others I have hidden up my sleeve) |
| 17:31 | <AryehGregor> | (when people show up with multiple addresses in my address book, I never know which to use) |
| 17:32 | <jgraham> | Ms2ger: That isn't cat related, so it seems unlikely |
| 17:32 | <Ms2ger> | Hah |
| 17:59 | <AryehGregor> | Wow, the number of bugs filed today is truly ludicrous. |
| 17:59 | <AryehGregor> | Last Call does seem to prompt a lot of feedback. |
| 18:00 | <smaug____> | last call of what? |
| 18:00 | <AryehGregor> | HTML5. |
| 18:00 | <smaug____> | oh, last call of w3c html5 |
| 18:00 | smaug____ | doesn't care :) |
| 18:00 | <AryehGregor> | I don't either, I'm just remarking on the mounds of feedback. |
| 18:00 | <AryehGregor> | Lots of people and organizations apparently do care. |
| 18:01 | <AryehGregor> | Including, e.g., Microsoft. |
| 18:01 | <smaug____> | it is good the get feedback, of course |
| 18:03 | <smaug____> | but I don't understand what the last call means in this case |
| 18:06 | <AryehGregor> | There's actually loads of high-quality feedback here from Microsoft. |
| 18:06 | <AryehGregor> | I have no idea why they put it off to just before Last Call instead of filing as soon as they came up with it. |
| 18:06 | <zewt> | "time to give the feedback that you've been holding back for some mysterious reason" |
| 18:07 | <AryehGregor> | This Greg Lowney fellow from access-research.org is also providing lots of detailed bugs, although I don't know how many of them will wind up being accepted. |
| 18:09 | <AryehGregor> | This is seriously like a hundred bugs filed in the last day or something. |
| 18:09 | <AryehGregor> | Or last two days. |
| 18:10 | <AryehGregor> | And most of them are fairly good. |
| 18:10 | <AryehGregor> | annevk, looks like the cat is out of the bag with dom.spec.whatwg.org, huh? |
| 18:12 | <AryehGregor> | Apparently we got some feedback on accessibility from the state of Virginia. |
| 18:12 | <zewt> | do people in virginia have specific accessibility needs |
| 18:13 | <Ms2ger> | Was that the .doc? |
| 18:13 | <AryehGregor> | I think this one was an e-mail, but I archived it without looking too closely. |
| 18:14 | <TabAtkins_> | Nah, this was an email. |
| 18:15 | <AryehGregor> | Hixie, browsers have to support ES parseInt and parseFloat anyway, so why is their instability or whatever any kind of argument against reusing them? They exist and we have to deal with them already, and it's extremely confusing to have them work almost the same but not quite. |
| 18:17 | smaug____ | agrees with AryehGregor |
| 18:17 | <AryehGregor> | smaug____, well, I can't do anything, but if you want to threaten implementer veto, you have my full support. :) |
| 18:21 | smaug____ | hopes bz will just reopen the bug :) |
| 18:23 | <AryehGregor> | I forgot that I can sic implementers on him. |
| 18:23 | <AryehGregor> | I'll send an e-mail to whatwg once I finish archiving the flood in my spec inbox. |
| 18:30 | <AnselmBradford> | does anyone know of a working example of using <object> in form submission? The example on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017363.html appears to no longer work (on Mac anyway) |
| 19:03 | <jgraham> | AryehGregor: Probably the W3C will treat all this last-minute feedback as a vindication of the whole Process rather than evidence that it is a failure because it discourages people from doing ongoing review |
| 19:06 | <AryehGregor> | jgraham, I'm not sure they'd be wrong. Psychologically, if there's no deadline, maybe people will think "meh, I'll get around to it someday" and then never do it. |
| 19:07 | <AryehGregor> | I dunno. |
| 19:07 | <AryehGregor> | Even if does encourage feedback, though, I think that's massively outweighed by the disadvantages. |
| 19:09 | <jgraham> | AryehGregor: If the feedback is coming from implementors they should be providing it as they implement, at the latest. If no one has implemented the feature at LC the feedback it gets won't be very useful |
| 19:09 | <AryehGregor> | In theory, CR is the call for implementations. |
| 19:09 | <jgraham> | Same reason I don't think that having these "releases" of the testsuite don't make sense |
| 19:10 | <jgraham> | People should provide feedback when they run the tests on their own internal system |
| 19:10 | <jgraham> | That doesn't happen on a fixed timescale |
| 19:13 | <Ms2ger> | I know it sounds unlikely, but non-implementers can make useful comments as well ;) |
| 19:14 | <jgraham> | Well, yes |
| 19:14 | <jgraham> | Although I think 0 non-implementors have commented on the testsuite so far |
| 19:15 | <jgraham> | I know there is like ~1 contributer to the CSS testsuite that is not an implementor |
| 19:15 | <Ms2ger> | Oh, who's that? |
| 19:16 | <Ms2ger> | (I haven't followed Kris' plans with the test suite, and will probably ignore any releases he does) |
| 19:17 | Ms2ger | wonders why the rsync messages differ between the html and webapps repos |
| 19:17 | <timeless> | heh |
| 19:19 | <jgraham> | Ms2ger: I believe Gerard Talbot is not an implementor. I don't know if there are others |
| 19:19 | <TabAtkins> | Gerard is not. |
| 19:19 | <AryehGregor> | jgraham, I'm not an implementer. |
| 19:19 | <TabAtkins> | A few other people aren't either. |
| 19:19 | <Ms2ger> | Oh, CSS |
| 19:19 | <AryehGregor> | Although I happen to be working for an implementer, I have no more contact with the actual implementer people than you do. |
| 19:19 | <AryehGregor> | Dunno about CSS. |
| 19:20 | <Ms2ger> | I managed to read "CSS" as "HTML" |
| 19:20 | <jgraham> | AryehGregor: You are working for Google who are implementors |
| 19:20 | <AryehGregor> | (I mean, the actual Google implementer people) |
| 19:20 | <AryehGregor> | Yes, but that's random coincidence. |
| 19:20 | <AryehGregor> | I wrote the test suite before I was working for them. |
| 19:20 | <Ms2ger> | Does Philip` work for an implementer? |
| 19:20 | <AryehGregor> | And it wasn't originally part of my job either, I asked for permission to do some extra work on my preexisting reflection tests as part of my job. |
| 19:20 | AryehGregor | doesn't think so |
| 19:21 | <jgraham> | Philip` is the counterexample to any general statement |
| 19:21 | <AryehGregor> | True. |
| 19:22 | <Ms2ger> | Hence, false |
| 19:23 | <jgraham> | Well technically the repository shows 3 counterexamples; AryehGregor (who isn't really one), David Carlisle and Philip` |
| 19:23 | <AryehGregor> | I am too one. |
| 19:23 | <AryehGregor> | I submitted those tests in my spare time. |
| 19:23 | <AryehGregor> | I did like 75% of the work unpaid. |
| 19:24 | <AryehGregor> | At least. |
| 19:24 | <jgraham> | I wrote the test harness in my spare time, but I can't count myself :p |
| 19:25 | <gsnedders> | (Though I did the initial review of it as work :P) |
| 19:26 | <AryehGregor> | jgraham, you're an actual implementer, though, not just someone who happens to work for an implementer but has no contact with the implementers who work there. |
| 19:29 | <timeless> | MikeSmith: ping |
| 19:29 | <timeless> | ... has w3 ever rescindend any specifications for any reason? |
| 19:29 | <jgraham> | AryehGregor: Well whatever. Clearly my initial statement is factually incorrect. But the counterexamples are an editor of a different spec (who works for an implementor), someone who thinks that generating Fortan from xml using xslt is not only sane but enjoyable, and Philip`. Therefore I consider the general thrust of my statement to be correct ;) |
| 19:29 | <timeless> | ooh, yes |
| 19:30 | <timeless> | http://www.w3.org/TR/2009/PER-xhtml11-20090507/ is rescinded |
| 19:30 | <timeless> | cool |
| 19:30 | <AryehGregor> | jgraham, on the other hand, very few tests have been submitted period, so those exceptions are fairly significant proportionally. |
| 19:30 | <AryehGregor> | Especially if you weight by test number and quality. |
| 19:30 | <AryehGregor> | Last I checked, Philip` and I count for a lot extra in that case. |
| 19:30 | <Ms2ger> | You beat MS by a huge margin, that's clear :) |
| 19:31 | <jgraham> | Well you basically autogenerated a bunch of tests from a table. Which is useful but cheating if we're using number-of-tests as a metric :) |
| 19:31 | Ms2ger | patiently awaits Kris' reply about automated tests |
| 19:32 | <jgraham> | Ms2ger: Reply to what? |
| 19:32 | <Ms2ger> | My reply about Matheus' test I submitted |
| 19:34 | <jgraham> | Oh, about their early test submisions being updated |
| 19:34 | <Ms2ger> | Yeah |
| 19:37 | <Philip`> | Ms2ger: I don't really work for anyone |
| 19:38 | <AryehGregor> | jgraham, I autogenerated a bunch of tests from thousands of lines of carefully-written JavaScript. |
| 19:39 | <AryehGregor> | The bulk of my tests is the logic, not the tables. |
| 19:39 | <Ms2ger> | That bulk is, unfortunately, unreadable :) |
| 19:39 | <AryehGregor> | Sadly. |
| 19:39 | <AryehGregor> | To be fair, testharness.js is also unreadable, at least if you ask me. |
| 19:40 | AryehGregor | looked into trying to make the pass/fail checkboxes have a proper <label> so you have a larger click target, but quickly gave up |
| 19:40 | Philip` | still thinks his canvas test .yaml files are reasonably readable |
| 19:40 | <Philip`> | (The .py files less so) |
| 19:40 | <Ms2ger> | I haven't tried |
| 19:40 | <AryehGregor> | Well, my data files are super readable. |
| 19:40 | <AryehGregor> | It's only the thousands of lines of logic that's incomprehensible. |
| 19:41 | <jgraham> | AryehGregor: I don't see why that would be hard |
| 19:41 | <Ms2ger> | Not really, the necessary data is split over two files |
| 19:41 | <jgraham> | Although I agree that the templating stuff is "not wonderful" |
| 19:41 | <Ms2ger> | So I actually found your data unreadable as well :) |
| 19:41 | <AryehGregor> | jgraham, I'm sure it's not hard for you. |
| 19:41 | <AryehGregor> | Ms2ger, well, it's actually split over like ten files, because people wanted smaller test files for some reason. |
| 19:41 | <AryehGregor> | Originally it was all in one file. |
| 19:41 | <AryehGregor> | Along with the logic. |
| 19:42 | <AryehGregor> | And the harness. |
| 19:42 | <Philip`> | (I suppose it could be argued that mixing YAML and HTML and JS and Python syntax, and the canvas API and the Cairo API, in a single source file, is not an ideal way to make something easy to understand, but I don't mind it myself) |
| 19:43 | <Ms2ger> | Yeah, I don't care about the ten files, but about the fact that the data for a single element-attribute combination is split over two files |
| 19:43 | <AryehGregor> | It was either that or make the element data much longer and more error-prone. |
| 19:43 | <AryehGregor> | Originally I didn't split it, but that involved painful amounts of repetition. |
| 19:43 | <AryehGregor> | I could un-split it pretty easily, though. Maybe format the data files a bit more consistently too. |
| 19:44 | <Ms2ger> | OTOH, it would make it easier to review for correctness |
| 19:44 | <AryehGregor> | Like have each attribute be one line. |
| 19:44 | <AryehGregor> | Yeah, true. |
| 19:44 | <Ms2ger> | I think it would reduce my headaches after dealing with reflection, at least ;) |
| 19:45 | <Ms2ger> | (Not as much as someone fixing Gecko's integer reflection code would, but still) |
| 19:51 | <jgraham> | AryehGregor: Pushed the label fix |
| 19:51 | <AryehGregor> | jgraham, thanks. |
| 19:51 | <jgraham> | It annoyed me too :) |
| 19:53 | <Hixie> | AryehGregor: when it comes to implementation simplicity, browsers are not the concern. |
| 19:54 | <AryehGregor> | Hixie, what implementers are you worried about that will need to exactly implement this part of HTML but will not need to implement ES as well? |
| 19:56 | <Hixie> | AryehGregor: all the off-the-shelf tools? the vast majority of HTML processors don't support ES, nor are they updated frequently. |
| 19:56 | <Hixie> | AryehGregor: should we defer to other specs for everything where we happen to be a subset of another spec's algorithms? |
| 19:56 | <AryehGregor> | Hixie, examples? Ones that need to exactly match how browsers behave? |
| 19:56 | <AryehGregor> | Hixie, I don't propose that the algorithm be a subset, I propose that it be made identical. |
| 19:56 | <Hixie> | you want to support Infinity? |
| 19:56 | <AryehGregor> | Not just an editorial change, a normative change. |
| 19:57 | <Hixie> | you want to support a radix attribute on integer attributes? |
| 19:57 | <AryehGregor> | Identical with some extra error handling tacked on, okay. |
| 19:57 | <Hixie> | subset. |
| 19:57 | <Hixie> | or superset, i guess. |
| 19:57 | <Hixie> | either way, not identical. |
| 19:57 | <AryehGregor> | I already said that it should be the same as parseInt(x, 10), not parseInt(x), so there's no radix issue. |
| 19:57 | <Hixie> | that's a subset then. |
| 19:58 | <AryehGregor> | And yes, I think that when we have a normative dependency on a spec in practice anyway, we should defer to it where that would make the resulting spec shorter. In practice we have a normative dependency on ES no matter what, there's no mileage in trying to avoid it. |
| 19:58 | <AryehGregor> | But anyway, I posted to whatwg, we'll see what the implementers think. |
| 19:58 | <Hixie> | making specs shorter is not a goal. |
| 19:59 | <Hixie> | we could make the spec massively shorter, e.g. by dropping all the domintro stuff and introduction sections, all the examples, all the notes |
| 19:59 | <Hixie> | every time you have an indirection through anothe spec, it adds significant complexity |
| 20:00 | <Hixie> | you have to track the other spec if it changes |
| 20:00 | jgraham | prefers the idea of resusing ES algorithms in general |
| 20:00 | <Hixie> | either normatively or just changing the editorial issues like the section or algorithm name |
| 20:00 | <AryehGregor> | jgraham, that would be useful to say on whatwg, especially if you're in a position to say whether Opera's willing to do what the spec says. |
| 20:00 | <Hixie> | you have to read two specs instead of one |
| 20:00 | <Hixie> | etc etc etc. |
| 20:00 | <Hixie> | and in this particular case, the ES definition isn't stable, it changes over time |
| 20:01 | <Hixie> | which is just plain silly. |
| 20:01 | <jgraham> | Not least because there is a non-zero chance that people implementing the feature will just say "oh we have code that does that already" and call that rather than looking for all the subtle differences |
| 20:01 | <jgraham> | Which leads to poor interop |
| 20:01 | <Hixie> | there's tons of different code to parse integers and floats |
| 20:01 | <Hixie> | why should we match ES rather than CSS? |
| 20:01 | <Hixie> | or C? |
| 20:02 | <jgraham> | In an ideal world HTML and ES and CSS would all match |
| 20:02 | <Hixie> | jgraham: the problem you describe is one that validators solve in a hurry. |
| 20:02 | <Hixie> | er |
| 20:02 | <Hixie> | s/validators/tests/ |
| 20:03 | <jgraham> | If the problems the tests bring up require lots of new code and only affect edge cases people are unlikley to be in a hurry to fix bugs |
| 20:03 | <jgraham> | +those |
| 20:03 | <Hixie> | this is not a case that needs lots of new code |
| 20:03 | <Hixie> | in fact it requires significantly less code than the ES equivalent |
| 20:04 | <Hixie> | and might even require less code than trying to expose the ES function and reference that |
| 20:04 | <Hixie> | since there's no guarantee the ES function is actually exposed to other code outside the JS library |
| 20:04 | <jgraham> | Well that is true |
| 20:04 | <jgraham> | It is also easier to test if the requirements are the same |
| 20:05 | <jgraham> | Because you can just reuse the same tests |
| 20:05 | <Hixie> | not really |
| 20:05 | <Hixie> | how to escape characters is quite different in HTML and JS |
| 20:06 | <jgraham> | Well the actual input files will be different. But the range of cases they cover will be identical rather than subtly different |
| 20:06 | <AryehGregor> | It's confusing for authors. |
| 20:06 | <Hixie> | the range of cases they cover can still be identical, it's just that the tests for HTML wouldn't change over time, whereas in ES' case the tests need to change every time Unicode is updated |
| 20:07 | <AryehGregor> | I've seen a case where an author assumed parseInt() would work to translate content attributes to their reflected equivalents. |
| 20:07 | <AryehGregor> | I think I linked it on the bug. |
| 20:07 | <Hixie> | AryehGregor: that is ludicrous, given the difference is in parts of unicode most authors will never even hear about let alone put in a numeric attribute. |
| 20:07 | <Hixie> | parseInt() will work fine on conforming content. |
| 20:07 | <AryehGregor> | Yes, the difference is trivial, so it will only fail in bizarre and therefore hard-to-debug corner cases. |
| 20:07 | <Hixie> | that's what validators are for. |
| 20:07 | <AryehGregor> | On the other hand, since the difference is trivial, there's no reason for it to exist. |
| 20:07 | <AryehGregor> | We care about non-conforming content too. It might be script-generated, too, in which case validators don't help. |
| 20:08 | <Hixie> | i've already given half a dozen reasons for the difference to exist, AryehGregor |
| 20:08 | <AryehGregor> | I've already said why I disagree with all of them. |
| 20:08 | <AryehGregor> | No point in arguing further, either implementers are willing to follow your spec or not. |
| 20:09 | <Hixie> | you might disagree with the reasons, but that doesn't mean there are no reasons. |
| 20:10 | <AryehGregor> | You gave reasons to avoid the normative dependency on ES, not reasons why the HTML algorithm is better than ES's. Except for the fact that the ES algorithm changes over time, but you said yourself that the changes are only in cases that most authors will never even hear about. |
| 20:10 | <AryehGregor> | I didn't see you give any other reason why the HTML algorithm is better than the ES one, unless I missed something. |
| 20:11 | <Hixie> | the only difference between the two is that the ES one changes over time, no? |
| 20:12 | <AryehGregor> | The only one I know of, yes. Or rather, that they use different whitespace definitions. |
| 20:12 | <AryehGregor> | But that difference is not important, because the presence of such whitespace is a corner-case and it only matters that behavior be well-defined, not what it actually is. |
| 20:13 | <Hixie> | so there's one difference, and it's got a reason (that you think is unimportant). |
| 20:13 | <AryehGregor> | Do you think it's important? |
| 20:13 | <Hixie> | i think it is important for specs' syntax requirements not to drift over time, yes. |
| 20:14 | <AryehGregor> | All specs change over time. |
| 20:15 | <Hixie> | and all people eventually die, but that doesn't make death a good thing |
| 20:15 | jwalden | wonders what this hubbub's about, bub |
| 20:15 | <Ms2ger> | That's a ludicrous comparison, though |
| 20:15 | <cwilso> | when it's a spec's time, it's their time. |
| 20:15 | <Ms2ger> | jwalden, integer parsing |
| 20:16 | <Hixie> | i'm just saying that the existence of something is not evidence of it not being bad |
| 20:16 | <AryehGregor> | Granted, sure. |
| 20:16 | <AryehGregor> | I'm not saying there's no disadvantage to matching ES. |
| 20:16 | <jwalden> | I see Unicode mentions, and I've been reviewing JS Unicode patchings lately, so it triggered some interest |
| 20:16 | <Hixie> | AryehGregor: you did, earlier |
| 20:16 | <AryehGregor> | It might well be good if ES changed to match HTML. |
| 20:16 | <jwalden> | good luck with that |
| 20:17 | <Hixie> | anyway i gotta go. bbiab. |
| 20:17 | <AryehGregor> | I didn't mean to imply there were no problems at all with matching ES, I was speaking loosely. Apologies if it caused any confusion. |
| 20:22 | <gsnedders> | Hixie: HTML's syntax requirements will drift over time, though. C.f., self-closing elements. |
| 20:53 | jgraham | remembers why people on the internet suck as a blog post about stress testing memory usage turns into a "my browser is better than yours" pissing competition |
| 20:53 | <jgraham> | Well not "why" so much as "that" |
| 20:59 | <nlogax> | Hixie: is this correct behavior in chrome? for the "No data" items, only dragstart and end ever fire. for the "Data" items, all the d&d events fire. only difference is the usage of dataTransfer.setData. broke recently-ish in chrome, works in safari (as in all events fire) http://jsfiddle.net/yyb5A/4/ |
| 21:15 | <AryehGregor> | I count 97 bugs filed in the HTMLWG in the last 24 hours. |
| 21:15 | <AryehGregor> | Yikes. |
| 21:15 | Philip` | wonders what happened to the HTML5 Super Friends |
| 21:16 | <Philip`> | Did they do anything other than publishing http://www.zeldman.com/superfriends/guide/ (and then not follow up when people tried to get more detail about what kind of "XHTML" syntax checking they wanted)? |
| 21:19 | <Ms2ger> | Sounds right |
| 21:27 | <jgraham> | AryehGregor: How many from @microsoft.com? |
| 21:27 | <AryehGregor> | jgraham, didn't count. |
| 21:28 | <MikeSmith> | timeless: here now |
| 21:28 | <MikeSmith> | AryehGregor: will change your bugzilla address now |
| 21:28 | <AryehGregor> | MikeSmith, thanks! |
| 21:29 | <timeless> | MikeSmith: have any other specs been rescinded? or just that one? |
| 21:29 | <MikeSmith> | eh? |
| 21:29 | <MikeSmith> | timeless: which one? |
| 21:29 | <timeless> | http://www.w3.org/TR/2009/PER-xhtml11-20090507/ |
| 21:29 | <gsnedders> | timeless: You could use SPARQL to find the answer to that question :P |
| 21:30 | <MikeSmith> | heh |
| 21:30 | <MikeSmith> | where are the super friends when we really need them? |
| 21:31 | <timeless> | gsnedders: there's no way i'd find the right sparql service |
| 21:31 | <timeless> | and heaven help me find a ua that supports it |
| 21:33 | <MikeSmith> | super friends activate! form of a SPARQL query! |
| 21:33 | <timeless> | Philip`: i'm amused to see they can't spell `then` correctly and complain about `and` |
| 21:33 | <timeless> | > A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, an[d] the like |
| 21:34 | <timeless> | > If that is the body than the footer is secondary content to the document as a whole. |
| 21:34 | <timeless> | s/than/than [sic]/ |
| 21:35 | <timeless> | ooh, they want full fledged applications like Bespin to be in the spec! |
| 21:36 | <MikeSmith> | timeless: sadly, I did not not even know that that http://www.w3.org/TR/2009/PER-xhtml11-20090507/ had been marked Rescinded |
| 21:36 | <MikeSmith> | but I am glad it has been |
| 21:36 | <timeless> | MikeSmith: learn something new every day? |
| 21:36 | <timeless> | glad to be of help |
| 21:36 | <MikeSmith> | yeah |
| 21:36 | <MikeSmith> | I guess plh did that |
| 21:36 | <timeless> | i don't suppose there's an easy way to find out why it was rescindend |
| 21:36 | <timeless> | s/end/ed/ |
| 21:36 | <Ms2ger> | Michael, there's a Rec at http://www.w3.org/TR/xhtml11/, though |
| 21:36 | <MikeSmith> | no, no easy mean |
| 21:36 | <Michael> | ? |
| 21:37 | <Michael> | oh |
| 21:37 | <Ms2ger> | "On 19 May 2009 the W3C Director rescinded this document due to process issues." |
| 21:37 | <Ms2ger> | MikeSmith, ^ |
| 21:37 | <Ms2ger> | Sorry Michael |
| 21:37 | <MikeSmith> | timeless: the easy mans is to ask Ian Jacobs, probably |
| 21:38 | <Ms2ger> | Wasn't that the superman email? |
| 21:38 | <Ms2ger> | By Björn |
| 21:38 | <MikeSmith> | if that draft has been "rescinded", I would hope that means we can tell the community to ignore XHTML 1.1 completely |
| 21:39 | Ms2ger | finds "Did Lois know that Clark was Superman" problem in www-rdf-interest⊙wo archives |
| 21:39 | <MikeSmith> | including the whole misguided mess of XHTML "modularization" |
| 21:40 | <MikeSmith> | man, we really needs for the super friends to get off their asses and actually do something for a change |
| 21:41 | <MikeSmith> | I mean, other than issuing proclamations |
| 21:41 | <MikeSmith> | well, at least one other proclamation |
| 21:41 | <jgraham> | to be honest "super friends" makes then sound like some sort of Japanese escort agency. Which is pretty creepy. |
| 21:42 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-archive/2009May/0029.html |
| 21:42 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-archive/2009May/0045.html |
| 21:42 | <MikeSmith> | based on my personal experience, I kind of like Japanese escorts |
| 21:42 | <MikeSmith> | but I really don't like XHTML 1.1 |
| 21:42 | <Ms2ger> | MikeSmith, thank you for that information |
| 21:43 | <MikeSmith> | heh |
| 21:43 | <MikeSmith> | well, I need some super friends help on XHTML 1.1 |
| 21:43 | <Ms2ger> | I'm not sure I'll ever be able to sleep anymore |
| 21:45 | <MikeSmith> | super friends should temporarily wake up out of retirement to issue a final proclamation on XHTML 1.1 |
| 21:48 | <MikeSmith> | along the lines of, "Hey, remember all that stuff we told you about XHTML being the absolute most important thing in the entire universe? well please ignore all that and go back about your business" |
| 21:49 | <MikeSmith> | AryehGregor: changed your bugzilla login to ayg⊙an |
| 21:49 | <MikeSmith> | please try and let me know if it took |
| 21:50 | <MikeSmith> | but as far as I can see, it seems to have |
| 21:51 | <annevk> | timeless, that is the PER, not the REC: http://www.w3.org/TR/xhtml11/ |
| 21:51 | <timeless> | annevk: grumble |
| 21:52 | <timeless> | ok, are there *any* Rescinded RECs? |
| 21:52 | <MikeSmith> | AryehGregor: because I count 563 bugs where that address appears (including comments) |
| 21:55 | <MikeSmith> | I think any time the phrase "family of languages" is used, some sort of automated rescinding mechanism should kick in |
| 21:55 | <MikeSmith> | jesus |
| 21:55 | <MikeSmith> | "family of current and future document types and modules" |
| 21:56 | <MikeSmith> | not just "current", but "future" also |
| 21:56 | <MikeSmith> | and not just document types but modules also |
| 21:57 | <timeless> | annevk: ok so... |
| 21:57 | <timeless> | i was trying to use that document to point out that w3 will rescind things if necessary |
| 21:57 | <annevk> | Ms2ger, so since you're not sleeping, fix all bugs |
| 21:58 | <timeless> | am i still able to make that claim even if it's only for a weaker PER instead of an actual REC? |
| 21:58 | <timeless> | or should i go back to the drawing board, noting that the w3 claims are toothless |
| 21:58 | <Ms2ger> | timeless, only if Björn writes a sufficiently sarcastic email |
| 21:58 | <timeless> | ? |
| 21:59 | <annevk> | timeless, rescinding a PER that got later approved with basically the same issues seems pretty toothless to me |
| 21:59 | <Ms2ger> | /ignore annevk |
| 21:59 | <Ms2ger> | :) |
| 21:59 | <timeless> | annevk: grumble |
| 21:59 | timeless | needs a new drawing board |
| 21:59 | <annevk> | I do not know any REC |
| 22:00 | <annevk> | when I tried to warn implementors about DOM Views being useless Ian Jacobs thought I should use the rescinding process |
| 22:00 | <annevk> | I declined |
| 22:00 | <timeless> | could we publish something as a REC and go through the complete process of Rescinding it just so we can show it's possible? |
| 22:00 | <timeless> | why? |
| 22:00 | <timeless> | too much effort? |
| 22:00 | <annevk> | right |
| 22:00 | annevk | was about to type exactly that |
| 22:00 | <Philip`> | http://www.w3.org/2005/10/Process-20051014/tr#rec-rescind - "W3C MAY rescind an entire Recommendation, for instance when W3C learns of significant errors in the Recommendation, when the Recommendation becomes outdated, ..." - sounds like we should rescind HTML4 |
| 22:01 | <MikeSmith> | I would really like to rescind XHTML 1.1 completely. it's nominally within my authority to do that now |
| 22:01 | <Ms2ger> | Philip`, feel free to lead that |
| 22:01 | <timeless> | Philip`: +1 |
| 22:01 | <annevk> | Philip`, the problem is you have to follow http://www.w3.org/2005/10/Process-20051014/tr#rec-modify |
| 22:01 | <Ms2ger> | MikeSmith, want me to loudly proclaim I want you to somewhere? :) |
| 22:01 | <MikeSmith> | Ms2ger: tell plh |
| 22:01 | <MikeSmith> | XHTML 1.1 is used so rarely on the public web that it's |
| 22:02 | <MikeSmith> | XHTML 1.1 is used so rarely on the public web that it's effectively irrelevant anyway |
| 22:02 | <timeless> | annevk: do you? |
| 22:02 | <annevk> | oh wait you don't |
| 22:02 | <timeless> | > To deprecate part of a Recommendation, W3C follows the process for modifying a Recommendation. |
| 22:02 | <annevk> | sorry I misread |
| 22:02 | <Ms2ger> | Actually, I think I still have an XHTML1.1 site online somewhere |
| 22:02 | <timeless> | I think rescinding a *complete* REC skips that |
| 22:02 | <timeless> | it's only for partials |
| 22:02 | <annevk> | so what is the policy? |
| 22:02 | <annevk> | I told Ian Jacobs DOM Views as is is useless |
| 22:02 | <annevk> | what's the next step? |
| 22:02 | <annevk> | tell someone else within the W3C? |
| 22:02 | <MikeSmith> | we need some Jean-Luc Picard "make it happen" |
| 22:03 | <timeless> | > 7.7.1 Proposal to Rescind a Recommendation |
| 22:03 | <zewt> | itym "make it so" |
| 22:03 | <MikeSmith> | annevk: next step is bug me about it |
| 22:03 | <MikeSmith> | and then bug me about it again |
| 22:03 | <MikeSmith> | until I realize it's serious enough that I need to try to do something about it |
| 22:03 | <timeless> | annevk / MikeSmith : would you be ok w/ actually rescinding DOM Views? |
| 22:04 | <MikeSmith> | yeah, sure |
| 22:04 | <timeless> | i'm willing to help fwiw |
| 22:04 | annevk | follows up with Ian Jacobs |
| 22:04 | <timeless> | house cleaning seems like a useful function |
| 22:04 | <MikeSmith> | there really is no other policy |
| 22:04 | <annevk> | http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0623.html |
| 22:05 | <annevk> | thanks for making me look at it again timeless |
| 22:05 | <timeless> | glad to |
| 22:05 | <timeless> | thanks for being willing to do so |
| 22:05 | <MikeSmith> | the W3C Process document actually says very little about publication policy, by design I think |
| 22:05 | <annevk> | if this really is the process we should be able to rescind a bunch of stuff |
| 22:05 | <annevk> | I wonder if that is appreciated |
| 22:05 | <timeless> | i'll certainly appreciate it |
| 22:05 | <timeless> | having fewer things that people can reference is a good thing |
| 22:06 | <Ms2ger> | MikeSmith, can you change http://www.w3.org/standards/history/domcore to drop the "Web", btw? |
| 22:06 | <MikeSmith> | the process for some of this stuff is largely determined by whether you can manage to get IanJ attention about it |
| 22:06 | <MikeSmith> | Ms2ger: yeah, thaI can do on my own, I think |
| 22:07 | <Ms2ger> | Are you also willing to do it? :) |
| 22:10 | <MikeSmith> | Ms2ger: reload |
| 22:11 | <Ms2ger> | MikeSmith++ |
| 22:12 | <Ms2ger> | It still has a Web in the breadcrumbs, though |
| 22:12 | <MikeSmith> | hmm |
| 22:12 | <MikeSmith> | not sure how to change that but I will try to figure it out |
| 22:13 | <Ms2ger> | Great, thanks |
| 22:15 | <MikeSmith> | find . | grep -i "Web DOM" in the cvs source for that tree gives me nothing, though |
| 22:15 | <MikeSmith> | oops |
| 22:16 | <MikeSmith> | needing some xargs |
| 22:17 | <MikeSmith> | still nothing, though, even with xargs in their properly |
| 22:19 | <Philip`> | That sounds like a convoluted way to do 'grep -ir "Web DOM"' |
| 22:20 | <zewt> | it's the unix way, having magic things bolted into particular tools not so much |
| 22:21 | <annevk> | maybe it's part of the CMS? |
| 22:22 | <timeless> | Philip`: from memory that isn't portable :) |
| 22:23 | <timeless> | MikeSmith: note that you need some -print0 and -0s or similar :) |
| 22:23 | <MikeSmith> | no idea what that is |
| 22:24 | <MikeSmith> | Philip`: what is -r ? |
| 22:24 | <TabAtkins> | Recursive, presumably. |
| 22:25 | <MikeSmith> | if I'm going to use that I guess I should just go whole hog and use rgrep or whatever abomination GNU has produced |
| 22:27 | <timeless> | yeah -r is recursive |
| 22:27 | <timeless> | but it isn't portable... |
| 22:27 | <timeless> | http://www.linuxquestions.org/questions/solaris-opensolaris-20/recursive-grep-557442/ |
| 22:28 | <timeless> | > Just pick the gnu grep version which is bundled with Solaris: /usr/sfw/bin/ggrep |
| 22:28 | <timeless> | ggrep :) |
| 22:40 | <jgraham> | The whole "tools should do one thing and one thing only" idea can be taken too far. Having to learn how to combine large numbers of tools in complex ways is clearly less easy than just using a command line options to a single tool |
| 22:40 | <jgraham> | Not least because the documentation of combinations is much worse than the documentation of individual tools |
| 22:41 | <Hixie> | clearly? |
| 22:41 | <Hixie> | i don't think that's obvious at all |
| 22:42 | <Hixie> | heycam: yt? |
| 22:42 | <zewt> | i've never heard of "documentation of combinations", i just learned how the tools worked and then it was pretty intuitive how to fit them together |
| 22:42 | <heycam> | Hixie, hi |
| 22:43 | <Hixie> | heycam: HTMLOptionsElement apparently has an anonymous setter that can be used with any input index |
| 22:43 | <Hixie> | heycam: 'setter' only works with known indexes, right? |
| 22:43 | <heycam> | Hixie, that's right -- that's the distinction between creator and setter |
| 22:43 | <Hixie> | heycam: is there some way to handle this? |
| 22:44 | <Hixie> | oh creator |
| 22:44 | <Hixie> | duh |
| 22:44 | <heycam> | I had wondered whether it is a useful distinction to draw |
| 22:44 | Hixie | is stoopid |
| 22:44 | <heycam> | maybe it is |
| 22:44 | <heycam> | :) |
| 22:44 | <Hixie> | nevermind me |
| 22:44 | <heycam> | you can bang "setter creator" on the one operation |
| 22:44 | <jgraham> | Well within limits. But it's pretty obvious that if you want to achieve X and you do "man foo" and search for "X" and it says "use the -X switch", that is likly to be easier than imagining a way of piping together foo and bar and baz to achieve the same result. Especially if you are unaware that bar and baz exist. |
| 22:44 | <Hixie> | heycam: oh awesome |
| 22:44 | <Hixie> | heycam: thanks |
| 22:44 | <heycam> | Hixie, np |
| 22:49 | <annevk> | hmm https://www.ietf.org/mailman/listinfo/happiana |
| 22:49 | <annevk> | anyone here signed up yet? |
| 22:55 | <annevk> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=13640 reference fights |
| 22:55 | <annevk> | teehee |
| 22:55 | <annevk> | I could learn a thing or two from AryehGregor |
| 22:57 | <Hixie> | maybe one day plh will reply to http://lists.w3.org/Archives/Public/public-web-perf/2011Apr/0013.html or http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0090.html |
| 22:59 | <TabAtkins> | Hm. How do you use innerHTML to replace the contents of an iframe? |
| 23:02 | <jgraham> | Which contents? |
| 23:02 | <annevk> | http://blog.webmproject.org/2011/08/one-to-one-vp8-video-calling-now.html so that only leaves Apple in a way |
| 23:02 | <jgraham> | The child nodes or the framed document? |
| 23:03 | <jgraham> | (I would have thought that iframe.innerHTML or iframe.contentDocument.innerHTML would work) |
| 23:03 | <jgraham> | (but setting .innerHTML on document might not work everywhere yet) |
| 23:04 | <TabAtkins> | The latter doesn't seem to work for me, and I can't get to contentDocument.body |
| 23:04 | <jgraham> | contentDocument.documentNode? |
| 23:04 | <TabAtkins> | Actually, just calling contentDocument seems to return undefined all the tiem. |
| 23:04 | <annevk> | wait for onload |
| 23:04 | <jgraham> | Is this with chrome and a data: uri? |
| 23:05 | <annevk> | anything but about:blank loads async |
| 23:05 | <TabAtkins> | jgraham: Chrome, yes. data: url, no. I'm using a blank src. |
| 23:05 | <annevk> | iirc |
| 23:05 | <jgraham> | The ways of about:blank are mysterious to me |
| 23:06 | <jgraham> | Maybe chrome loads that async? But surely taht would break sites... |
| 23:07 | <TabAtkins> | annevk: Even creating an iframe within the javascript console doesn't work, though. |
| 23:07 | jgraham | ->sleep++ |
| 23:09 | <annevk> | wait for onload |
| 23:09 | <TabAtkins> | annevk: Again, creating one in the console, then in a separate command asking for contentDocument, return "undefined". |
| 23:10 | <TabAtkins> | Given my slow human fingers, I'm quite certain that onload fires between those two actions. |
| 23:13 | <annevk> | is it in a document? |
| 23:13 | <TabAtkins> | Hm, guess not. |
| 23:13 | <annevk> | "When an iframe element is first inserted into a document, the user agent must create a nested browsing context, and then process the iframe attributes for the first time." |
| 23:13 | <annevk> | that would explain your problem |
| 23:14 | <TabAtkins> | Ah, indeed. It all works now, thanks! |
| 23:20 | <remysharp> | Is this as good a place as any to ask about indexeddb? |
| 23:20 | <TabAtkins> | Sure. |
| 23:21 | <remysharp> | regarding the transaction method |
| 23:22 | <remysharp> | creating new transactions |
| 23:22 | <remysharp> | I've seen tutorials offering a third argument - usually 0 (zero) but I can't for the life of me work out what it's supposed to be. |
| 23:22 | <remysharp> | any ideas? |
| 23:22 | <remysharp> | I did try the spec, but really couldn't work it out from there - not sure if I was being blind or it's just not completely clear |
| 23:23 | <remysharp> | for example: db.transaction(['notes'], IDBTransaction.READ_WRITE, 0) |
| 23:27 | <TabAtkins> | I can't tell very well, because the spec is almost entirely devoid of examples, but I suspect it's a timeout. |
| 23:28 | <remysharp> | yeah - it's not completely clear - glad it's not just me! |
| 23:28 | <TabAtkins> | Nah, this spec is *super* horrible for reading. |
| 23:28 | <remysharp> | Cheers - searching timeout, I'd say you're right. |
| 23:29 | <remysharp> | thanks for that - wasted hours the other night trawling through articles - not sure why I did check in here first! |
| 23:29 | <TabAtkins> | ^_^ |
| 23:29 | <annevk> | per spec there's only two arguments |
| 23:29 | <annevk> | so that last argument is bogus and will be ignored |
| 23:29 | <TabAtkins> | annevk: Where are you finding the description of the transaction() method? |
| 23:29 | <annevk> | http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#database-interface |
| 23:30 | <remysharp> | cripes - good work finding that |
| 23:30 | <TabAtkins> | Ah, there it is. |
| 23:30 | <remysharp> | how I didn't see that before.... |
| 23:30 | <remysharp> | ssheesh |
| 23:30 | <jamesr> | Hixie: fwiw on the public-web-perf spec i updated all the specs i'm editor on to reference up-to-date specs |
| 23:30 | <Hixie> | nice |
| 23:30 | <jamesr> | that does not include page visibility |
| 23:31 | <Hixie> | it's really the only way that makes sense, imho |
| 23:33 | <annevk> | oh plh replies |
| 23:33 | <annevk> | hello W3C log readers |
| 23:34 | <Hixie> | he still neatly managed to avoid actually responding to large parts of the e-mail |
| 23:35 | <annevk> | http://wiki.csswg.org/spec/reviews/html5 |