| 00:54 | <aruner> | Hixie, what's the history of the blocked header list in XHR in the spec.? How was that list arrived at? |
| 00:54 | <Hixie> | bjoern sent a detailed reply regarding this recently |
| 00:55 | <Hixie> | in other news i am especially amused that sunava just delayed another MONTH |
| 00:55 | aruner | kicks his mail client for retrieving messages slowly |
| 00:56 | <Dashiva> | Hixie: But otherwise it's going well. She's quoting properly, at least |
| 00:56 | <Hixie> | aruner: http://lists.w3.org/Archives/Public/public-webapi/2008May/0189.html |
| 00:56 | <Hixie> | Dashiva: i believe sunava is a he, am i wrong? |
| 00:57 | <Hixie> | annevk: yt? |
| 00:57 | <Dashiva> | I'm just guessing, so you're probably right |
| 00:57 | aruner | sighs. Though I *do* think that their general design principles are good (be conservative, err on the side of ultra safe) I think specifics help us understand their notions on threat modeling. |
| 00:58 | <Dashiva> | Flickr seems to support you |
| 00:58 | <Hixie> | aruner: their design principles resulted in xdr, which has at least three known security bugs, so... :-) |
| 00:59 | aruner | grins |
| 01:00 | <aruner> | Dashiva: Sunava Dutta is a he |
| 01:00 | <Dashiva> | He and anne should make a club |
| 01:00 | <Hixie> | i live in the bay area |
| 01:01 | <Hixie> | i don't make any judgements regarding gender |
| 01:01 | <aruner> | Hixie: are you putting in an appearance at the F2F in Redmond? I'm not sure. |
| 01:01 | <Hixie> | as it's not uncommon for people to change gender... |
| 01:01 | <Hixie> | aruner: i'd like the spec to be done by then. |
| 01:01 | <Hixie> | aruner: in which case i won't turn up |
| 01:01 | <Dashiva> | I try to use she for females because some get insulted by 'he' as gender-neutral |
| 01:01 | <Hixie> | aruner: we'll see nearer the time |
| 01:01 | <Philip`> | You can make a pretty good guess at someone's gender based solely on the fact that they're posting to a web specification mailing list |
| 01:02 | <Hixie> | sad but true |
| 01:02 | <Dashiva> | That's asking for a beatdown, Philip` ;) |
| 02:21 | <Hixie> | so i wonder how to define sandboxes |
| 02:22 | <Hixie> | such that if you have document A with iframe containing document B with iframe containing document C |
| 02:22 | <Hixie> | that: |
| 02:23 | <Hixie> | 1. if A, B, and C are from the same origin, B can't play with C |
| 02:23 | <Hixie> | hm wait |
| 02:23 | <Hixie> | i was going to say that if B and C have hte same origin but aren't the same as A they should be able to talk |
| 02:23 | <Hixie> | but no, that would still allow problems |
| 02:23 | <Hixie> | so we really do want unique origins... |
| 02:23 | <Hixie> | hmm |
| 02:23 | <Hixie> | that makes it easier |
| 02:24 | <Hixie> | HMM. |
| 02:24 | Hixie | ponders |
| 02:26 | <othermaciej> | so I assume you are thinking sandboxes that still have script enabled? |
| 02:26 | <othermaciej> | (since for noscript iframes this would not matter) |
| 02:27 | <othermaciej> | maybe I should step back and ask what use cases you are targetting |
| 02:27 | <Hixie> | actually same-origin matters even without scripts |
| 02:27 | <Hixie> | a bunch of things use the origin concept |
| 02:27 | <Hixie> | but yes, i am considering scripts too |
| 02:27 | <othermaciej> | like frame targetting? |
| 02:27 | <Hixie> | yeah, that sometimes uses origin |
| 02:27 | <othermaciej> | I think the desired restrictions depend on the use cases |
| 02:27 | <othermaciej> | ones I can imagine: |
| 02:28 | <othermaciej> | - blog comments |
| 02:28 | <othermaciej> | - user-authored content in a profile on a social network site |
| 02:28 | <othermaciej> | - "widgets" embedded from off-site |
| 02:28 | <othermaciej> | - "widgets" hosted by the provider of the page containing them |
| 02:28 | <othermaciej> | - ads |
| 02:29 | <Hixie> | comments and other user-contributed content, gadgets (same site and other site; including ads), and (not sandboxing but still <iframe> related) client-side includes are the main ones |
| 02:29 | <othermaciej> | ads are complicated because at least some ad networks consider it important to support frameless flash ads that overlay the content |
| 02:29 | <othermaciej> | but anything that can overlay the content is not properly sandboxed by definition |
| 02:30 | <Hixie> | there are indeed various scenarios with varying levels of sandboxing |
| 02:30 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/sandbox has my current strawman proposal (cut and pasted from the start of the e-mail i'm writing; note that i've used past tense because it'll be past tense once i send the mail, but the spec isn't actually updated yet) |
| 02:30 | <othermaciej> | for comments you would like them to be able to size naturally and seem to be inline as far as the end-user is concerned, but they should not be able to css position outside their area |
| 02:32 | <Hixie> | yeah the comments would be <iframe sandbox="unrestricted-origin" seamless src="data:text/html,(small html document)"></iframe> |
| 02:33 | <othermaciej> | I'm thinking about whether inheriting styles and applying outer stylesheets may be a security risk |
| 02:33 | <Hixie> | in certain cases it is |
| 02:33 | <Hixie> | in others not so much |
| 02:33 | <Hixie> | i can't see how it could be in a script-limited blog comment case |
| 02:34 | <othermaciej> | I'm thinking for the comment use case and the user-generated content on hosted profile page use case |
| 02:34 | <Hixie> | oh i have to disble forms too while i'm at it |
| 02:34 | <othermaciej> | and also plugins probably |
| 02:34 | <Hixie> | yeah |
| 02:34 | <othermaciej> | (including Java) |
| 02:35 | <Hixie> | updated sandbox file |
| 02:35 | <othermaciej> | I am nervous about the performance impact of using an iframe per comment with hundreds of comments |
| 02:35 | <Hixie> | yeah me too |
| 02:35 | <Hixie> | i'm not sure what else to do though |
| 02:36 | <othermaciej> | navigating the parent should be restricted (dunno if that falls out of other things), including back/forward |
| 02:36 | <othermaciej> | window sizing and positioning should be restricted |
| 02:37 | <Hixie> | any browsing context navigation outside the sandbox is blocked |
| 02:37 | <othermaciej> | does embedding further subframes in the content need to be restricted? |
| 02:37 | <Hixie> | though that does mean that links in comments won't work |
| 02:38 | <othermaciej> | or do they just inherit the sandbox restrictions already in effect? |
| 02:38 | <Hixie> | i don't see why it should be, but they certainly are also sandboxed |
| 02:38 | <Hixie> | and they're not in the same sandbox, either |
| 02:39 | <othermaciej> | links in blog comments not working is kind of a bummer |
| 02:39 | <othermaciej> | perhaps there should be a way to turn that on, since it can't be used as an annoyance in the noscript case |
| 02:39 | <Hixie> | yeah |
| 02:40 | <Hixie> | comments would now be <iframe sandbox="unrestricted-origin force-links-to-parent" seamless src="data:text/html,(small html document)"></iframe> |
| 02:40 | <Hixie> | it's getting long |
| 02:41 | <othermaciej> | the keywords are a bit verbose |
| 02:41 | <Hixie> | it's a security thing, i'm worried about making them too simple |
| 02:41 | <Hixie> | i'm especially worried about making them sound like they _increase_ security |
| 02:41 | <Hixie> | when all the keywords decrease it somewhow |
| 02:41 | <othermaciej> | perhaps there should be two addtributes |
| 02:42 | <othermaciej> | sandbox="" or restrict="" that turns everything off, and an allow="" attribute to turn things back on selectively |
| 02:42 | <othermaciej> | or sandbox-exceptions="" |
| 02:43 | <Hixie> | well "force-links-to-parent" isn't really an exception or a restriction, it just changes the rules to send all user-activated links to the parent browsing context |
| 02:43 | <othermaciej> | you could achieve that with <base target="parent"> and allowing targetted links to parent only |
| 02:43 | <othermaciej> | a bit more work but makes it strictly an exception, not a behavior change |
| 02:43 | <Hixie> | (<iframe seamless sandbox allow="..." src="data:text/html,(small html document)"></iframe> makes sense, but i'm not sure what the keywords would be) |
| 02:44 | <othermaciej> | though if it is not a restriction or an exception perhaps it should be a separate attribute like seamless |
| 02:44 | <Hixie> | well the idea is that you can allow whatever random content in the sandbox as you want |
| 02:44 | <Hixie> | so i'm not sure i want to be poking <base> into it |
| 02:44 | <Hixie> | ooo |
| 02:44 | <Hixie> | wait! |
| 02:44 | <Hixie> | it can just be part of seamless' behaviour! |
| 02:44 | <othermaciej> | for the comment use case presumably the data: URL is generated by software and the user's comment does not have <html> or <body>? |
| 02:44 | <othermaciej> | oh interesting |
| 02:45 | <Hixie> | comments would now be <iframe sandbox="unrestricted-origin" seamless src="data:text/html,(small html document)"></iframe> again |
| 02:45 | <othermaciej> | is it ever useful to allow gadgets to navigate the parent or open a window? |
| 02:45 | <Hixie> | probably, but i want to start with as small a set of allowed behaviours as possible |
| 02:51 | <othermaciej> | I guess for gadgets, anything forbidden can be selectively exposed via postMessage |
| 02:51 | <Hixie> | eah |
| 02:51 | <Hixie> | y |
| 02:53 | <Hixie> | maybe seamless should base its origin determination on the "real" origin, not the origin affected by sandbox="" |
| 02:53 | <othermaciej> | Hixie: i think the seamless navigation rule should only apply to navigations triggered by the content of the iframe |
| 02:53 | <Hixie> | as opposed to what? |
| 02:53 | <othermaciej> | Hixie: if the parent doc navigates a seamless iframe it should not navigate itself |
| 02:53 | <Hixie> | hm, that makes things more complex |
| 02:53 | <Hixie> | why would you use target="" on a seamless iframe? |
| 02:53 | <Hixie> | why not just change .data? |
| 02:53 | <Hixie> | or .src |
| 02:54 | <Hixie> | or whatever |
| 02:54 | <othermaciej> | changing .src is a navigation |
| 02:54 | <Hixie> | not per spec |
| 02:54 | <Hixie> | oh actually it is |
| 02:54 | <Hixie> | nevermind |
| 02:54 | <Hixie> | i'm thinking of <object> |
| 02:54 | <othermaciej> | well put it this way, changing iframe.src, changing iframe.contentWindow.location, and targetted link aimed at iframe all go at the same code path |
| 02:54 | <othermaciej> | at least in WebKit |
| 02:55 | <Hixie> | yeah |
| 02:55 | <Hixie> | spec too |
| 02:55 | <Hixie> | ok |
| 02:55 | <Hixie> | well |
| 02:55 | <Hixie> | i could just do it for <a> links |
| 02:55 | <othermaciej> | knowing the source frame of a navigation is not a big deal |
| 02:55 | <Hixie> | i guess |
| 02:55 | <othermaciej> | we always have to know anyway |
| 02:55 | <Hixie> | though what do you call the source if someone from another iframe clicks a link using .click() ? |
| 02:56 | <Hixie> | or what if frame A calls .click() on a link in frame B which has a target="" to A, which is seamless? |
| 02:56 | <othermaciej> | I would say only cases where the source frame is the seamless frame itself should get retargetted |
| 02:57 | <Hixie> | sure but what is the source frame in that example? |
| 02:58 | <othermaciej> | I don't know in general what a cross-frame click() call on a link considers the source frame |
| 02:58 | <othermaciej> | presumably something has to define which it is in any case |
| 02:59 | <othermaciej> | I don't think it matters which is chosen from security POV |
| 02:59 | <othermaciej> | since A has to have unrestricted origin in your scenario and thus could just modify B to do something bad |
| 03:01 | <Hixie> | well i've never had to define it before now :-) |
| 03:01 | <Hixie> | but i agree it doesn't really matter much |
| 03:01 | <Hixie> | so long as it is defined |
| 03:02 | <Hixie> | i guess i'll just add an "argument" to the "navigate" algorithm and make all the call sites say what the source is |
| 03:04 | Hixie | defines the term "source browsing context" |
| 03:04 | <Hixie> | (better terms welcome) |
| 03:05 | <Hixie> | hm, this causes <meta http-equiv=refresh> inside a seamless iframe to navigate the parent iframe |
| 03:06 | <Hixie> | oh hey, we do need this, to define .referer better |
| 03:06 | <Hixie> | :-) |
| 04:54 | <MikeSmith> | Hixie: why's the body element included in the "Obsolete elements, attributes, and APIs" section? |
| 08:20 | <othermaciej> | hey web expert people |
| 08:21 | <othermaciej> | is there any way in Firefox to do the equivalent of either word-wrap: break-word (breaks lines in the middle of long words that would overflow the box) or text-overflow: ellipsis (ellipsizes lines that are too long)? |
| 08:28 | <jwalden> | othermaciej: 3 you could use ­ or the Unicode codepoint, I suspect |
| 08:28 | <othermaciej> | jwalden: between every character? |
| 08:28 | <jwalden> | wait |
| 08:28 | <jwalden> | that's what that does? |
| 08:28 | <othermaciej> | someone was asking me how to handle a long word in a fixed-width box gracefully |
| 08:29 | <jwalden> | "gracefully" |
| 08:29 | <othermaciej> | (url to be specific) |
| 08:29 | <othermaciej> | overflow: visible makes it stick out of the box |
| 08:29 | <othermaciej> | overflow: hidden silently truncates |
| 08:29 | <othermaciej> | overflow: scroll adds a scrollbar |
| 08:29 | <jwalden> | last I recall we were breaking URLs, actually; that may have changed |
| 08:29 | <othermaciej> | I suggested word-wrap break-word to wrap the word in the middle of the box |
| 08:29 | <othermaciej> | or text-overflow: ellipsis to truncate but with an ellipsis at the end |
| 08:30 | <othermaciej> | neither of those work in FF though |
| 08:30 | <jwalden> | I'd do ­ at the / boundaries myself |
| 08:31 | <jwalden> | I don't remember anything particular that would work |
| 08:31 | <othermaciej> | (I just used a long word instead of a URL as my test case though so I could not tell if there was magical URL breaking, but I assume no or they would not have complained of this bug) |
| 08:32 | <jwalden> | so data:text/html,%3Cdiv%20style=%22width:%2010em;%20border:%201px%20dotted%20green;%22%3Ehttp://localhost:8888/tests/browser/microformats/test/test_Microformats_hCard.html%3C/div%3E does wrapping for me in 3+ source code, I think 3 does the same |
| 08:32 | <roc> | <wbr> or a zero-width unicode space? |
| 08:33 | <roc> | there is magical URL breaking in Firefox 3 |
| 08:33 | <othermaciej> | I was testing with an FF3 beta but possibly an old one |
| 08:33 | <roc> | although it's not terribly magical, it works pretty well |
| 08:34 | <othermaciej> | I think it it desired for this to work for non-URL overflow too or overflow of a single url component (the column in question is not very wide) |
| 08:35 | <othermaciej> | and not sure that putting ­ or <wbr> or zero-width space between every single character will fly |
| 08:35 | <othermaciej> | but I guess I can pass it along |
| 08:35 | <roc> | it doesn't have to be every single character, I guess |
| 08:40 | <othermaciej> | (both the things I mentioned work in IE as well as Safari fwiw, might be worth adding one or both to Gecko at some point) |
| 08:40 | <roc> | yeah, I should implement word-break |
| 08:40 | <roc> | text-overflow is totally underspecified |
| 08:41 | <roc> | and Webkit, at least, does weird things with it sometimes. Probably IE too although i test with IE less |
| 08:41 | <othermaciej> | word-wrap: break-word != word-break |
| 08:41 | <roc> | oh right |
| 08:42 | <othermaciej> | it is handy though cause it does what you expect in an editable area when your line is too long and is all one word (or at least what I expect) |
| 08:42 | <roc> | "Shaping characters are still shaped as if the word were not broken" ... that is weird |
| 08:42 | <othermaciej> | yeah, you would want arabic chars to still take medial form |
| 08:42 | <othermaciej> | not terminal or initial |
| 08:42 | <roc> | I guess that's the easy to implement way |
| 08:43 | <othermaciej> | it also seems like the correct way (at least for Arabic) |
| 08:43 | <roc> | but not for optional ligatures |
| 08:43 | <othermaciej> | presumably you can't break mid-ligature |
| 08:43 | <roc> | why not? |
| 08:43 | <othermaciej> | because it is one glyph |
| 08:43 | <othermaciej> | I mean |
| 08:43 | <othermaciej> | you could break between the chars |
| 08:43 | <othermaciej> | but the glyph is on one line or the next |
| 08:44 | <roc> | you can cut it in half |
| 08:44 | <roc> | we have to do that for selection and ligatures that cross span boundaries with different styles |
| 08:47 | <othermaciej> | if you can tell the difference between things that are ligature-like and things that are like Arabic I think you would be in your rights to undo the ligature, but I think breaking on one side of the glyph or the other should do, as perfecting the breakpoint when you already broke in the middle of a word seems less than essential |
| 08:47 | <roc> | right |
| 08:47 | <roc> | that's what I'd do |
| 08:47 | <annevk> | Hixie, am now |
| 08:48 | annevk | reads up on the sandbox discussion in the backlog |
| 09:16 | <annevk> | MikeSmith, I think it's there to define obsolete parts of the body element |
| 09:24 | <MikeSmith> | annevk: OK |
| 09:28 | <annevk> | I think it's confusing |
| 10:01 | <MikeSmith> | annevk: for the publication-notes doc, I wrote a short context description of that section as "contains descriptions of the obsoleted applet element and obsolete parts of DOM interface for the body element." |
| 10:19 | <MikeSmith> | so the table in section 8.6, "Named character references" was removed completely |
| 10:19 | <MikeSmith> | http://www.w3.org/html/wg/html5/#named |
| 10:19 | <MikeSmith> | wondering if we want to published without that |
| 10:19 | <MikeSmith> | if so, a note should probably be added there |
| 10:20 | <annevk> | that seems like a bug in the W3C script |
| 10:20 | <MikeSmith> | ah |
| 10:21 | <MikeSmith> | so still something that'll need to get fixed before we publish |
| 10:21 | <othermaciej> | annevk: I think Hixie's sandbox proposal is converging (at least I mostly liked the last thing I saw before I left work) |
| 10:22 | <othermaciej> | annevk: I fear the idea of using an iframe per comment will just not fly performance-wise (even with data: URLs) |
| 10:22 | <annevk> | yeah, it's such a hack |
| 10:22 | <annevk> | i doubt people will use it over better sandboxing on the server using real html5 parsers and tools |
| 10:23 | <othermaciej> | but you do need visual sandboxing I think (not let the content to overflow) as well as script, though I guess overflow: hidden does that |
| 10:23 | <othermaciej> | (does overflow: hidden hide relative, absolute or fixed position children that stick out?) |
| 10:23 | <othermaciej> | annevk: his design seems ok for gadgets/widgets embedded in web pages |
| 10:23 | <othermaciej> | or ads |
| 10:24 | <othermaciej> | not sure it flies for other use cases |
| 10:45 | <hsivonen> | Does Safari 3.1 support closed captiong for video? |
| 10:51 | <hsivonen> | othermaciej: Does Safari 3.1 support closed captiong for video? |
| 10:51 | <othermaciej> | oddly someone just asked me that |
| 10:51 | <othermaciej> | I have not tested |
| 10:51 | <hsivonen> | ok. thanks |
| 10:51 | <othermaciej> | I do not know how you turn it on in QuickTime |
| 11:05 | <annevk> | oh lol |
| 11:06 | <annevk> | Robert Burns is joining the ARIA discussion |
| 11:06 | <annevk> | guess I'm now more than done with that :) |
| 11:07 | hendry | wonders if there is a resource describing each test in Acid3 or perhaps some sort of source control access. best i've found is http://en.wikipedia.org/wiki/Acid3 |
| 11:08 | <othermaciej> | oh no, Robert Burns |
| 11:08 | <othermaciej> | is there any clusterfuck of a discussion that he can't make worse? |
| 11:10 | <hsivonen> | sigh |
| 11:10 | <Dashiva> | hendry: You mean to show what spec part they test? |
| 11:10 | <annevk> | i wonder if i should reply |
| 11:11 | <annevk> | he's totally wrong, but i know that when i point that out he finds some way to turn the argument around |
| 11:13 | <Dashiva> | annevk: I suppose the question is if anyone else listens to him, and needs clarification :) |
| 11:13 | <annevk> | yeah, deleted the e-mail |
| 11:13 | <othermaciej> | " In my view the null namespace should not exist in a namespaced document processed by a namespace aware application. Instead unprefixed attributes should be attached to the same namespace as their parent elements." |
| 11:14 | <hsivonen> | he is not wrong about XMLNS having a design bug |
| 11:14 | <hsivonen> | it's just a bug that is too late to fix |
| 11:14 | <othermaciej> | he seems to think namespaces already work this way |
| 11:15 | <hsivonen> | many namespace advocates do |
| 11:15 | <othermaciej> | also seems to think adding namespaces (with : syntax) in HTML5 would solve anything with regards to compat issues with the proposal |
| 11:17 | <annevk> | the whole point about ARIA is that it doesn't require architectural changes |
| 11:17 | <annevk> | so arguing we first need to make architectural changes misses the point |
| 11:18 | <annevk> | but pointing that out to Robert Burns doesn't work based on past experience |
| 11:18 | <hsivonen> | I have to go buy a new display with a powered USB hub right now. |
| 11:18 | <hsivonen> | I need 3 USB devices to get work done and the MacBook can power only 2 |
| 11:20 | <othermaciej> | however Robert Burns does have the ability to increase confusion of third parties to the discussion if not corrected |
| 14:57 | <hsivonen> | (I got an Apple display. thanks for the recommendations) |
| 15:04 | <annevk> | http://lists.w3.org/Archives/Public/public-forms/2008May/att-0022/2008-05-14.html#topic3 "Steven Pemberton: There was a huge amount of RDFa." |
| 15:04 | <annevk> | (over XTech) |
| 15:05 | <hsivonen> | annevk: different room, different amount of RDFa, I guess |
| 15:06 | <annevk> | Not sure what's happening to the Forms Task Force |
| 15:07 | <annevk> | Also seems they continue with copying HTML features. It seems though that they try to copy from the HTML4 specification rather than from implementations... |
| 15:10 | <hendry> | Dashiva: er, OK (sorry missed this IRC window somehow) |
| 16:01 | <Philip`> | http://doctype.googlecode.com/svn/trunk/tests/html/elements/plaintext-element-appears-in-dom-test.html - that's not quite right :-( |
| 16:59 | <JJ08> | Are there currently any problems with the <video> element in safari? |
| 17:00 | <JJ08> | i can get it to show the player but the .mpg wont play. Also the poster image covers the play controls sometimes. |
| 19:14 | virtuelv | curses at Google's newfound love for not making websites work in browsers instead of named product |
| 19:14 | <virtuelv> | +s |
| 19:14 | <JJ08> | lol. Sounds like your enjoying yourself |
| 19:15 | <virtuelv> | not at all |
| 19:15 | <virtuelv> | http://www.google.com/translate_t |
| 19:16 | <virtuelv> | they have opted for creating a rather ugly, custom widget instead of a standard <select> |
| 19:16 | <virtuelv> | continuing down that path, they might just as well create their own runtime, only viewable with the google client, on the google os |
| 19:16 | <MikeSmith> | the docreader thing looks like of a like a frankenstein monster that escaped from the lab and now out terrorizing the villagers |
| 19:17 | <virtuelv> | running on Google hardware |
| 19:17 | <virtuelv> | MikeSmith: yeah, and now they ruined translate as well |
| 19:17 | <virtuelv> | http://www.google.com/translate_t |
| 19:17 | <JJ08> | lol. |
| 19:17 | <JJ08> | i see what you mean now. |
| 19:17 | <virtuelv> | what's the use of standards when everything gets replaced with JavaScript that barely works anywhere |
| 19:17 | <JJ08> | its not very "standard" at all. |
| 19:18 | <JJ08> | oh, see you beat me to it |
| 19:18 | <JJ08> | and at my college Javascript is disabled .... so that goes to pot |
| 19:18 | <takkaria> | it's that bloody google web toolkit thing |
| 19:18 | <virtuelv> | if you turn off js, it sort of works |
| 19:19 | <virtuelv> | Sincerely, GWT should die |
| 19:19 | <JJ08> | there turning into Apple (even though i just spent over £1000 on one) |
| 19:19 | <JJ08> | tightly controlling everything they own |
| 19:21 | <JJ08> | googles source code is just one big line. They forgot to use "/n". lol |
| 19:21 | <virtuelv> | a single character costs google |
| 19:22 | <virtuelv> | removing redundant whitespace is IMHO acceptable for stuff that's production code, and has undergone proper QA |
| 19:22 | <JJ08> | i suppose if you put it like that. |
| 19:23 | <Lachy> | jgraham__, we're presenting on day 1 http://www.vivabit.com/atmedia2008/london/schedule/ |
| 19:24 | <Lachy> | assuming the schedule doesn't change again between now and then |
| 19:24 | <virtuelv> | <DIV class="goog-inline-block goog-menu-button-caption" unselectable="on">Spanish</DIV> |
| 19:24 | <JJ08> | i wanted to go to @media. I had all the cash sorted then i had to move house! Bummer, well pissed off i was |
| 19:38 | <Dashiva> | When this is all over, we'll have to make medals for the people who risked mind and sanity in the alt wars |
| 19:46 | <smedero> | Dashiva: That or we'll all lose our minds and start implementing Dmitry Turin's HTML 6. |
| 19:46 | <Dashiva> | I don't see how that'll be much worse than our current heading |
| 19:46 | Dashiva | mumbles |
| 19:47 | <smedero> | I kinda wish he would email the list now with how he intends to support alt on his new picture input type: http://html6.by.ru/site/html60/en/author/inputpic_eng.htm |
| 19:47 | <smedero> | oh, i'm just being cruel now. |
| 19:47 | <smedero> | :( |
| 19:48 | <JJ08> | wtf is HTML 6? |
| 19:50 | <virtuelv> | JJ08: Dmitry Turin's private proposal for next-generation HTML |
| 19:50 | <virtuelv> | I'm amazed at how much people here actually know about it |
| 19:50 | <virtuelv> | http://html6.by.ru/site/html60/en/author/label_eng.htm |
| 19:51 | <JJ08> | i am taking this as a joke. This looks idiotic |
| 19:51 | <virtuelv> | <style> |
| 19:51 | <virtuelv> | form { next: execute } |
| 19:51 | <virtuelv> | </style> |
| 19:51 | <virtuelv> | <body> |
| 19:51 | <virtuelv> | <form action="program.exe"> |
| 19:51 | <smedero> | You can also see his musings on SQL 5: http://sql50.euro.ru/site/sql50/en/author/index_eng.htm |
| 19:51 | <virtuelv> | </body> |
| 19:51 | <virtuelv> | Value next=execute orders to execute received information in local operational system (mainly value next=execute is intended for those cases, when form's address specifies into local file system). |
| 19:51 | <JJ08> | what the hell is this: <a href="./c.htm#:body/h2[@@~"part of header"]+h3[5]"> text </a> |
| 19:51 | <virtuelv> | http://html6.by.ru/site/html60/en/author/transfer_eng.htm |
| 19:51 | <JJ08> | is this some random guy that has set this uo? |
| 19:51 | <JJ08> | *up |
| 19:52 | <smedero> | Dmitry pops into various standards related mailing list from time to time and proposes one of his concepts. |
| 19:52 | <JJ08> | have any actually been used? |
| 19:52 | <smedero> | not that I know of, no. |
| 19:53 | <JJ08> | he looks serious about what he is trying to preach. |
| 19:53 | <smedero> | to be fair to Dmity, he at least provides examples and occasionally use cases. |
| 19:53 | <smedero> | however insane they may be |
| 19:54 | <virtuelv> | actually, I have seen a user-js implementation of his XPath-links |
| 19:57 | <virtuelv> | and the idea itself, for being able to link into specific locations of a document that doesn't have relevant anchors or id's has merit |
| 19:59 | <JJ08> | Maybe he will come up with something beneficial. I'll give him credit because he provides examples and is obviously working on ways to improve. Its more than what im doing. |
| 19:59 | <Dashiva> | It's not that his ideas necessarily are bad, but most of them are too different from everything we already have to fit in |
| 20:00 | <Dashiva> | He seems like he really likes stream processing, maybe we could get him to work on event-source :) |
| 20:01 | <JJ08> | but how can someone be considered credible if he isn't considering 'standards'. His source code is evidence to that. |
| 20:01 | <Lachy> | Hixie, yt? |
| 20:01 | <Dashiva> | JJ08: Well, our alt advocate friends are carrying that banner high themselves, so why can't Dmitry? :) |
| 20:03 | <JJ08> | any links to these 'friends' ? I know your telling the truth, id like to see thats all |
| 20:04 | <jgraham__> | Lachy: Yeah, they moved the progrmme around a lot at the same time. I wonder if Steve Faulkner will be around on Day 1 |
| 20:04 | <jgraham__> | s/at the same time/ at the same time as scheduling us/ |
| 20:05 | <Dashiva> | JJ08: If you can teach me how to search message contents in thunderbird, I'd probably find it. |
| 20:05 | <takkaria> | Dashiva: top right-hand corner search box, click on the magnifying glass, select "entire message" |
| 20:06 | <Dashiva> | Oh, swell |
| 20:06 | <Dashiva> | ... but it seems it gladly hits the server instead of using the local copy. |
| 20:06 | <takkaria> | you using IMAP? |
| 20:06 | <Dashiva> | Yes |
| 20:06 | <JJ08> | lol, i cant :( So what your saying is that these people who are involved in the development of HTML 5 are not even following standards? |
| 20:06 | <smedero> | the public-html archive search works fairly well: http://lists.w3.org/Archives/Public/public-html/ |
| 20:07 | <Dashiva> | JJ08: No, not like that |
| 20:07 | <takkaria> | Dashiva: IMAP has a built-in search command, so Tb uses that by default |
| 20:07 | <Dashiva> | Just that even advocates sometimes fail to go the extra mile in every single thing |
| 20:07 | <JJ08> | sorry. I get you now. |
| 20:07 | <Lachy> | jgraham__, yeah, Steve should be around. |
| 21:12 | <Lachy> | My podcast for boagworld.com that I recorded yesterday will most likely appear around the 4th of June |
| 21:42 | <mcarter> | good afternoon |
| 21:43 | <mcarter> | Hixie, I don't suppose you ever wrote that TCPConnection server perl script for your train set that I can test my implementation against? |
| 23:27 | <virtuelv> | http://www.regdeveloper.co.uk/2008/05/16/html5_xhtml_vendors_lockin/ |
| 23:30 | <Lachy> | The article says: "For sophisticated cross-platform applications, there already exist several proprietary solutions (such as Mozilla's XUL, Adobe's Flash, or Microsoft's Silverlight)," the group said. |
| 23:30 | <Lachy> | Who in the group said that? |
| 23:30 | <takkaria> | that seems like a very confused bit of reporting |
| 23:30 | <Hixie> | the spec says that |
| 23:31 | <Hixie> | so much for the spec not being a position paper. :-D |
| 23:31 | <Hixie> | hahahahaha |
| 23:32 | <Hixie> | i love the picture of chris wilson with a caption "Microsoft's Wilson: modular HTML 5" |
| 23:32 | <Hixie> | that's hilarious |
| 23:36 | <Dashiva> | The picture reminds me of those british judges with wigs |
| 23:36 | <Dashiva> | Poor Chris |
| 23:37 | <Lachy> | LOL |
| 23:39 | <takkaria> | the IBM article that links to I haven't read before |
| 23:39 | <takkaria> | has some good lines |
| 23:39 | <takkaria> | "The HTML V5 specification was written using good communication with browser vendors ... The team is sceptical about official W3C approval, though. The FAQ doesn't even try to give a serious answer about the expected date of approval." |
| 23:40 | <Lachy> | IIRC, that IBM article wasn't very good |
| 23:40 | <takkaria> | it's not, no |
| 23:41 | <Lachy> | wow. I wrote that FAQ, and I certainly did try to give a very serious answer to that question |
| 23:42 | <Hixie> | i thought the answer in the faq was pretty accurate |
| 23:42 | <Lachy> | though, saying 15 years generally doesn't go down well with people and it works better if you emphasise that features can be used as soon as browsers implement them, rather than waiting for the finished spec |
| 23:43 | <Hixie> | it took us 18 years to get where we are now |
| 23:43 | <Lachy> | that's what I did in the podcast yesterday, and the host responded quite well to that answer |
| 23:43 | <Hixie> | and html5 is specifying all of that and enough to take us forward |
| 23:43 | <Hixie> | and they think 15 years to get two perfect implementations is too long? :-) |
| 23:43 | <Hixie> | some people have issues |
| 23:44 | <roc> | I've started having terrifying thoughts that I'm going to be working on Web browsers for the rest of my life |
| 23:45 | <Lachy> | re the modularisation, they fail to realise that there may be a lot to write specs for, but there's too few editors to do it. |
| 23:45 | <Hixie> | roc: why is working on the cutting edge of one of humanity's biggest achievements terrifying? :-) |
| 23:45 | <Hixie> | Lachy: who is "they"? |
| 23:46 | <roc> | I bet Pharoah said the same thing to the slaves building his pyramids |
| 23:46 | <Lachy> | the people who are pushing for splitting the spec up into modules |
| 23:46 | <Lachy> | chris wilson, included |
| 23:46 | <Hixie> | roc: :_P |
| 23:47 | <Hixie> | roc: i heard from a student who attended the talk you gave at stanford btw, remind me to slip you a fiver when we next meet :-) |
| 23:47 | <roc> | ooh, which one? |
| 23:47 | <Lachy> | oh, at least MikeSmith does: So for now, nothing changes as far as the W3C is concerned. Smith noted that while modularization of specification is a good idea in principle, the consortium needs a commitment from one or more member organizations to take over a part of the specification. “We don’t have that; nobody has stepped up,” he said. |
| 23:47 | <Lachy> | http://www.sdtimes.com/content/article.aspx?ArticleID=32067 (2nd last paragraph) |
| 23:47 | <Hixie> | roc: you gave more than one? |
| 23:47 | <roc> | no, which student? |
| 23:47 | <Hixie> | oh |
| 23:47 | <Hixie> | andy |
| 23:47 | <Hixie> | works on indexing at google |
| 23:48 | <Hixie> | andy hochhaus |
| 23:48 | <roc> | ok, don't know him |