| 00:04 | <zcorpan_> | wow. one of my deliverables uses <p>...<table>...</table></p> |
| 00:05 | <zcorpan_> | which is probably due to me omitting the </p> tag and the server side guy wanted to have the tag present but didn't realise that it should go before the table |
| 00:47 | Philip` | finds another Opera bug to add to his list, while trying to draw dashed lines |
| 00:47 | Philip` | will have to try to sort the list out into a more useful format at some point |
| 00:58 | <Philip`> | Hixie: About transformed patterns: I think I'd vote for that feature, depending on how it'd work - the floor in http://canvex.lazyilluminati.com/misc/floor5.jpg counts as my use case, since it draws diagonal bits of texture onto thin horizontal strips of floor, and the maths to get all the transforms and coordinates correct was rather unpleasant to work out |
| 00:58 | <Philip`> | and I have a whole piece of A4 paper covered with lots of scribbling to demonstrate the unpleasantness :-) |
| 00:59 | <Philip`> | (or at least to demonstrate that I've forgotten much of the geometry and trigonometry I used to know...) |
| 00:59 | <Hixie> | heh |
| 00:59 | <Hixie> | yeah, you should see my whiteboard right now |
| 00:59 | <Hixie> | just to make the testcases |
| 01:00 | <Hixie> | however for 3D i think we'll provide a 3D canvas |
| 01:00 | <Hixie> | which would be better :-) |
| 01:00 | <Philip`> | That would be significantly more sane than my approach to 3D |
| 01:00 | <Hixie> | :-) |
| 01:03 | <Hixie> | man i wish opera had an auto-upgrade feature like firefox |
| 01:03 | <bewest> | yes, firefox has nailed it |
| 01:03 | <MikeSmith> | Hixie - I wish (nightly) Webkit/Safari had auto-upgrade too |
| 01:04 | <Philip`> | IE does auto-upgrade too |
| 01:04 | MikeSmith | looks around for othermaciej/mjs ... |
| 01:05 | <Hixie> | safari does have autoupdate. but yes. would be nice if the nightlies did too. |
| 01:06 | <hober> | there's NightShift.app for that |
| 01:08 | <Hixie> | hm, how did i not know about that |
| 01:09 | <hober> | the same guy does CaminoKnight and FireFix for those nightlies" |
| 01:11 | <othermaciej> | Safari uses the Mac OS X system autoupdate mechanism |
| 01:12 | <othermaciej> | ("Software Updates") |
| 01:12 | <othermaciej> | we don't have an official autoupdate for the nightlies though |
| 01:14 | <Hixie> | wow, NightShift is awesome |
| 01:14 | <hober> | yeah, it's really nice |
| 01:15 | <othermaciej> | it is cool indeed |
| 01:16 | <othermaciej> | we really should link it from webkit.org if we haven't already |
| 01:24 | <gavin_> | ah, I was looking for solution to that problem yesterday |
| 01:24 | <gavin_> | guess I'll try out nightshift! |
| 01:28 | <Hixie> | oh hey i never noticed the images were broken in the multipage version |
| 01:28 | Hixie | adds it to the list of things to fix today |
| 01:31 | <Philip`> | Oops - I think I originally was modifying them to be absolute paths, but must have removed that at some point |
| 01:31 | <Hixie> | no worries |
| 01:31 | <Hixie> | simple fix |
| 01:35 | <zcorpan_> | Hixie: btw, you think it's possible to add an alternative style sheet for the author view thing when it gets more complete? or perhaps it can be inserted with the status script |
| 01:36 | <zcorpan_> | http://simon.html5.org/temp/author-view-of-html5.css is a simple urllib.urlopen().read() with python |
| 01:36 | <Hixie> | sure |
| 01:37 | <zcorpan_> | perhaps the style sheet should be hosted at whatwg.org instead of being in my temp folder too? :) |
| 01:37 | <Hixie> | if you can keep it up to date :-) |
| 01:37 | <Philip`> | or perhaps a try: urllib.urlopen().read(); except: pass so it doesn't die horribly if that file goes missing :-) |
| 01:37 | <Hixie> | zcorpan_: the problem is mostly that it's so brittle |
| 01:38 | <Hixie> | zcorpan_: i'd love a more stable solution |
| 01:38 | <zcorpan_> | yeah, me too |
| 01:38 | <Hixie> | zcorpan_: we could maybe merge this with the status thing -- make it possible for individual sentences or paragraphs to be clicked and for a menu to come up so you can set the stability and target audience of that text |
| 01:39 | <Hixie> | the stability isn't something i'd want to keep in the spec text. maybe the target audience should be classes, though. |
| 01:39 | <zcorpan_> | yeah |
| 01:40 | <zcorpan_> | when the style sheet is complete you can perhaps map the selectors to the markup to get the source class=""ed automatically |
| 01:41 | <Hixie> | that would be interesting |
| 01:41 | <Hixie> | except the stylesheet applies to the index, and i'd have to edit the source |
| 01:42 | <bewest> | is it xslt-able? |
| 01:42 | <Philip`> | Would the target audience for the 'author' part be 'authors of HTML pages', or would it be 'authors of books and tutorials and blog posts and mailing list messages pointing out what the spec says is correct'? (I'm unsure how that would affect anything) |
| 01:42 | <bewest> | the spec is semantic html, right? |
| 01:42 | <Hixie> | bewest: yes |
| 01:42 | <Hixie> | not sure what you mean by "xslt-able" though |
| 01:43 | <bewest> | might produce alternative versions via xslt |
| 01:43 | <Hixie> | producing the alternate versions isn't the problem |
| 01:43 | <Hixie> | it's annotating the source that's the problem |
| 01:47 | <zcorpan_> | you write an implementation of getElementsBySelector() in perl or something to modify the source. then the editor(s) would have to maintain the class=""es |
| 01:47 | <Hixie> | the problem is that the selectors don't apply to the source, they apply to the index |
| 01:48 | <zcorpan_> | ah |
| 01:48 | <zcorpan_> | right |
| 01:48 | <zcorpan_> | hm |
| 01:48 | <Hixie> | might be not too bad |
| 01:48 | <Hixie> | we'll see |
| 01:48 | <Hixie> | not doing it right now anyway :-) |
| 01:49 | <zcorpan_> | yeah |
| 01:50 | <Philip`> | Perhaps parse the index document and work out what the CSS applies to, then remember the text which is matched, and then go back to the source and find the equivalent matching text (because that won't have been modified by the spec conversion process) |
| 02:45 | <jdandrea> | FWIW: sIFR includes a JavaScript function that parses CSS selectors and returns a list of one or more corresponding DOM nodes. That might help with parsing. |
| 03:07 | <Hixie> | http://dev.w3.org/cvsweb/html5/spec/ |
| 03:08 | <Hixie> | RIP Web Applications 1.0 |
| 03:08 | <Hixie> | Long Live HTML 5! |
| 03:16 | <Lachy> | wow! That's fantastic news to wake up to :-) |
| 03:27 | <othermaciej> | I call conflict of interst |
| 03:27 | <othermaciej> | Dave Hyatt is an editor, and the spec calls for giving him $10,000 |
| 03:27 | <Lachy> | LOL |
| 03:28 | <jdandrea> | Whoa - "good morning!" :) |
| 03:28 | <othermaciej> | I guess it would be good to fold in WF2 soon |
| 04:42 | <Hixie> | othermaciej: hah |
| 04:45 | <Hixie> | you know |
| 04:45 | <Hixie> | we could now easily make our first milestone |
| 04:46 | <Hixie> | FPWD on the TR page in June |
| 05:30 | <marcosc> | Hixie, I don't see why now? |
| 05:30 | <marcosc> | not* |
| 05:33 | <Hixie> | indeed, i'm saying we can :-) |
| 06:07 | <othermaciej> | Hixie: I expect many of the objections to adopting the document to be rehashed at FPWD time |
| 06:07 | <Hixie> | i'm sure |
| 07:20 | <Hixie> | i hate browsers |
| 07:20 | <Hixie> | i have a test here, and 6 different renderings |
| 07:21 | <Hixie> | i'm only testing three browsers! |
| 07:21 | <Hixie> | (several versions of those browsers, but still!) |
| 07:21 | <Hixie> | firefox3 passes the test, so i'm saying we have interoperability and going home |
| 07:23 | <othermaciej> | yeah, browsers kinda suck |
| 07:23 | <othermaciej> | unless you want to browse the web |
| 07:27 | <Hixie> | right, going home |
| 07:27 | <Hixie> | nn |
| 07:43 | <nickshanks> | will things decided by WHAT WG go into HTML 5 now, or will the W3C have a veto? |
| 07:44 | <citoyen> | WHATWG decides what goes into specs published by WHATWG. W3C decides what goes into specs published by W3C. |
| 07:45 | <citoyen> | Either group doesn't have veto over the other |
| 07:45 | <othermaciej> | they will be the same spec |
| 07:45 | <Lachy> | actually, the editors decide what goes into the spec based on feedback from the whatwg, htmlwg and many other sources |
| 07:46 | <othermaciej> | I expect the editors will abide by HTML WG decisions, though I would hope official votes overriding the editors would be rare |
| 07:46 | <citoyen> | Same spec, but as long as that spec is published by W3C, W3C has the last say. WHATWG can choose to go with that or publish a different spec. |
| 07:46 | <Lachy> | I hope they never happen |
| 07:46 | <othermaciej> | the WHATWG group that in theory could remove or override the editor is very unlikely to demand introduction of conflicting language |
| 07:46 | <othermaciej> | if that happened presumably the efforts would fork |
| 07:47 | <citoyen> | Indeed |
| 07:48 | <nickshanks> | how close to done is the spec, in most people's opinions? another year, another three years? |
| 07:48 | <othermaciej> | I think it's premature to predict that |
| 07:48 | <othermaciej> | I think there is still some speccing of new features to potentially be done, but at some point I would guess the group would want to self-impose a feature freeze |
| 07:49 | <othermaciej> | and every section needs close review |
| 07:49 | <othermaciej> | and it depends on whether "done" means CR or REC |
| 07:49 | <nickshanks> | CR i was meaning |
| 08:27 | <annevk> | whoa, we're in W3C CVS? |
| 08:27 | <annevk> | nifty |
| 08:32 | <othermaciej> | yep |
| 08:35 | <othermaciej> | now we need issue tracking |
| 08:35 | <annevk> | we should now have a #whatwg party |
| 08:36 | <othermaciej> | and a test suite in SVN |
| 08:36 | <othermaciej> | I would be all for a party |
| 08:36 | <annevk> | s/#whatwg/WHATWG/ |
| 08:45 | <othermaciej> | when / where to have it? |
| 08:46 | <annevk> | that's the problematic part |
| 08:46 | <othermaciej> | or perhaps we should let Hixie decide, taking relevant feedback into account |
| 08:46 | <annevk> | hehe |
| 09:57 | <jgraham_> | Philip`: If you want to play with the lxml stuff in html5lib it should be in svn now. You'll need to look at html5lib.treebuilders.getTreeBuilder to see how to get it working; I've changed the way elementtree stuff works a bit (suggestions for improvements to that interface welcome). Let me know if it's broken; it only passes tests, I don't know it is works ;) |
| 10:43 | <zcorpan_> | won't dhyatt be an editor for the whatwg spec too, automatically? |
| 10:44 | <Dashiva> | implicitly |
| 10:47 | <zcorpan_> | yeah. the whatwg-header just needs an update then :) |
| 10:47 | <annevk> | I think dhyatt will only update the W3C body though |
| 10:49 | <annevk> | "Special thanks and $10,000 to David Hyatt who came up with a broken implementation of the adoption agency algorithm that the editor had to reverse engineer and fix before using it in the parsing section." will also become confusing now :) |
| 10:50 | <zcorpan_> | yeah |
| 10:51 | <zcorpan_> | why "HTML 5" and not "HTML5" though? :P |
| 10:52 | <annevk> | yeah, that annoys me too |
| 10:52 | <annevk> | oh well |
| 10:55 | <zcorpan_> | perhaps "HTML 5" is the spec and "HTML5" is the language? |
| 10:55 | <Lachy> | I'm surprised they didn't go with HTML 5.0 |
| 10:56 | <Lachy> | :-) |
| 10:56 | <zcorpan_> | that would be even more annoying :) |
| 10:57 | <zcorpan_> | isn't it a convension of w3c specs to give the expansion in the title? |
| 10:57 | <zcorpan_> | HyperText Markup Language (HTML) 5 |
| 10:58 | <annevk> | all in due course |
| 10:58 | <Lachy> | HTML4 was HTML 4.0, and then 4.01 |
| 10:58 | <Lachy> | similarly with HTML2 and 3 |
| 10:59 | <zcorpan_> | HyperText Markup Language 5.0 (HTML5) |
| 10:59 | <annevk> | W3C version also carefully avoids copyright at this time |
| 11:00 | <Lachy> | zcorpan_, yeah, except lowcase 't' in "Hypertext" |
| 11:01 | <annevk> | Web Markup Language (HTML5) |
| 11:02 | <zcorpan_> | HTML 5 (HTML5) |
| 11:02 | <annevk> | HTML (HTML5) |
| 11:02 | <annevk> | HTML5 |
| 11:07 | <othermaciej> | I can think of 1.0 reasons to just call it HTML 5 |
| 11:28 | <krijnh> | Web 2.0 Language ((X)HTML5) |
| 11:40 | <zcorpan_> | othermaciej: what is that reason? |
| 11:45 | <krijnh> | http://www.whatwg.org/specs/ still says WA1.0 |
| 11:57 | <Dashiva> | zcorpan_: From the 1.0 I'm guessing minor versions |
| 12:04 | <othermaciej> | zcorpan_: because integers don't need to be written in decimal notation |
| 12:04 | <othermaciej> | and look nicer that way |
| 12:06 | <zcorpan_> | othermaciej: oh, i thought you meant as opposed to HTML5 (without a space) |
| 12:07 | <othermaciej> | yeah, I meant as opposed to 5.0 |
| 12:07 | <zcorpan_> | ok |
| 12:42 | <Hemebond> | Quick question: why does HTML5 define a way for a web page to control the user-agent? |
| 12:42 | <Lachy> | Hemebond, which feature are you referring to? |
| 12:42 | <Hemebond> | The target attribute. |
| 12:42 | <Hemebond> | And browser contexts. |
| 12:43 | <Hemebond> | *browsing |
| 12:43 | <Lachy> | target has usecases for working with frames, and the reason for allowing _blank is basically to stop people using window.open() |
| 12:44 | <annevk> | because (a) it needs to be supported and (b) there are use cases for having multiple browsing contexts |
| 12:44 | <annevk> | you can't have a user agent that does not support target= |
| 12:44 | <annevk> | (from a vendor pov) |
| 12:44 | <Hemebond> | Lame. |
| 12:44 | <annevk> | an author typically wants an easy way to show something in a new window |
| 12:45 | <annevk> | target=_blank is useful for that |
| 12:45 | <annevk> | how the UA handles that is up to the UA |
| 12:45 | <annevk> | of course |
| 12:45 | <Hemebond> | annevk: Which is why I use Firefox and disable such an annoying a abusive feature. |
| 12:45 | <annevk> | (like a help menu for the site, or something) |
| 12:45 | <annevk> | Hemebond, right, I've done something similar in Opera |
| 12:45 | <annevk> | we can't simply ignore reality though |
| 12:46 | <Philip`> | When something like _blank is defined and allowed, rather than having to be hacked around with window.open(), then it is much easier for the UA to give the user control to change the default behaviour |
| 12:46 | <othermaciej> | I like target compared to window.open because it lets me see where the link is going, tells me that it will open in a new window, and I can cmd-click to get a tab instead |
| 12:46 | <othermaciej> | (in Safari) |
| 12:47 | <Hemebond> | Philip`: Letting a script open a window is definitely the fault of the browser developer. |
| 12:48 | <Hemebond> | I'm still disappointed a spec explicitly um.... |
| 12:48 | <Hemebond> | specifies it |
| 12:48 | <annevk> | better than what HTML4 did |
| 12:48 | <Hemebond> | Ignore it? |
| 12:48 | <othermaciej> | actually, it's the fault of past browser developers who invented the feature, site authors who use it, and users who get mad if those sites break |
| 12:48 | <annevk> | specify a target= feature and don't tell how to implement it |
| 12:48 | <wilhelm> | UAs must support this feature, so it must be specified. But I agree that authors should be discouraged from using it. |
| 12:49 | <Hemebond> | annevk: I thought there was no target att in HTML4. Or maybe that's just strict. |
| 12:49 | <annevk> | it's not in HTML4 strict |
| 12:49 | <Lachy> | Hemebond, it's in transitional |
| 12:49 | <Hemebond> | wilhelm: Putting it in a spec won't help that. |
| 12:49 | <annevk> | Hemebond, the spec is not just for authors |
| 12:50 | <annevk> | Hemebond, the spec is also to ensure we still understand HTML a century from now |
| 12:50 | <othermaciej> | not putting it in a spec won't make UAs remove either target or window.open |
| 12:50 | <Hemebond> | I know, but if it's in the spec, UA developers HAVE to put it in if they want to support the spec. |
| 12:50 | <Lachy> | Hemebond, would you rather authors use target="", which you can easily disable, or hack around it with window.open(), which is much harder to disable? |
| 12:50 | <othermaciej> | window.open has never even been in a spec before |
| 12:50 | <annevk> | Hemebond, they will have to do so anyway |
| 12:50 | <Hemebond> | annevk: Not to support HTML5. |
| 12:50 | <Lachy> | UAs have to put it in because there is content that relies on it. Not because it's in a spec |
| 12:50 | <wilhelm> | It will. Browser vendors need a common spec to implement stuff interoperably. |
| 12:51 | <annevk> | Hemebond, there won't be such UAs |
| 12:51 | <Hemebond> | annevk: er, if it wasn't in HTML5 already that is. |
| 12:51 | <annevk> | Hemebond, UAs will support the web |
| 12:51 | <annevk> | Hemebond, the web includes target= |
| 12:51 | <Hemebond> | I see all your points. I'm still disappointed. |
| 12:51 | <annevk> | so if HTML5 ignores it that just makes it a less useful spec |
| 12:52 | <Hemebond> | annevk: Does HTML5 include blink? |
| 12:52 | <Hemebond> | And marquee? |
| 12:52 | <annevk> | Hemebond, I think marquee should be in the rendering section |
| 12:52 | <Lachy> | in the parsing and rendering section, yes |
| 12:52 | <annevk> | blink doesn't seem to be strictly needed |
| 12:52 | <Hemebond> | But people use it. |
| 12:52 | <Philip`> | "The scope of this specification does not include documenting every HTML or DOM feature supported by Web browsers. Browsers support many features that are considered to be very bad for accessibility or that are otherwise inappropriate. For example, the blink element is clearly presentational and authors wishing to cause text to blink should instead use CSS." |
| 12:53 | <Hemebond> | And UAs support it. |
| 12:53 | <annevk> | IE doesn't |
| 12:53 | <wilhelm> | <blink> is not used anymore. <marquee> is, and should be specified. |
| 12:53 | <Lachy> | it will just be defined to use text-decoration: blink;, which is optional in CSS anyway |
| 12:53 | <Hemebond> | "Browsers support many features that are considered to be very bad for accessibility or that are otherwise inappropriate." I would have put target in that little list. |
| 12:54 | <Lachy> | <blink> is used. See http://www.w3.org/Style/ for instance :-) |
| 12:54 | <Hemebond> | annevk: IE doesn't support what? Blink? I thought it created it. Was it Netscape? |
| 12:54 | <annevk> | Hemebond, Netscape created it |
| 12:54 | <annevk> | Hemebond, IE did <marquee> |
| 12:54 | <othermaciej> | netscape created <blink> and supports it |
| 12:54 | <othermaciej> | there's not significant demand for actual support of <blink>, in fact Mozilla is often asked to remove it |
| 12:54 | <othermaciej> | <marquee> is needed though, apparently a lot of chinese sites use it |
| 12:55 | wilhelm | nods. |
| 12:56 | <Hemebond> | I'll have to continue reading this tomorrow. Night. |
| 12:57 | <gsnedders> | the references currently say "This section will be written in a future draft." — is there any interest in others helping to put this together as it is now? |
| 13:00 | <mpt> | I wonder if Lynx is non-conforming for not supporting target= |
| 13:04 | <Philip`> | I'd guess it falls in the "If the user agent has been configured such that in this instance it will reuse the current browsing context" category which allows it to never create a new browsing context when you follow a link |
| 13:05 | <Philip`> | (I think it would still have to support multiple browsing contexts with e.g. <iframe>s, and support target aimed at that iframe) |
| 13:21 | <hsivonen> | I'd be interested in learning *why* Chinese designers like marquee so much. |
| 13:22 | <Dashiva> | The same reason japanese developers love document.all, maybe |
| 13:22 | <annevk> | and why Koreans do onfocus=this.blur() |
| 13:23 | <hsivonen> | Dashiva: eh? document.all is not a particular visual effect |
| 13:23 | <annevk> | lol |
| 13:23 | <annevk> | compat with existing party venues :) |
| 13:24 | <wilhelm> | hsivonen: Colourful, flashing, blinking, moving objects are more popular in east Asia than in Europe..(c: |
| 13:25 | <othermaciej> | I would guess it is related to their design culture and writing system |
| 13:25 | <othermaciej> | (possibly) |
| 13:25 | <Dashiva> | hsivonen: They're both antiquated, though |
| 13:26 | <gsnedders> | probably partly due to what people are taught |
| 13:26 | <gsnedders> | you're more likely to learn something your elders do |
| 13:26 | <hsivonen> | design culture without any particular reason sounds plausible but ins't the writing system visually more compact and, hence, doesn't put as much pressure on fitting more text in a certain page region |
| 13:28 | <Dashiva> | I wonder if homebrew vertical marquees are as popular |
| 13:29 | <othermaciej> | hsivonen: I think a lot of these are vertical one-time marquees |
| 13:29 | <othermaciej> | hsivonen: not certain of the details though |
| 13:33 | <Philip`> | I see 24 marquees in my totally biased collection of 2500 pages |
| 13:33 | <Philip`> | and 12 blinks |
| 13:33 | <Dashiva> | I wonder what is more common of <blink> and CSS blink |
| 13:34 | <hsivonen> | marquee is interesting politically, because accessibility and internationalization collide |
| 13:38 | <Philip`> | marquee seems quite common in 'professional' sites - http://www.washtimes.com/ http://www.sunnewsonline.com/ http://www.theobserver.com/ http://www.andhrabank-india.com/ http://www.anc.org.za/ etc |
| 13:38 | <Philip`> | whereas blink seems to be more in less-professional sites - http://www.applequest.org/ http://www.yorkcarpet.com/ http://www.aplus4u.com/ http://www.discount-train.com/ etc |
| 13:39 | <Philip`> | though those two lists are even more biased data than what I started with, so please don't actually believe them |
| 13:40 | <Philip`> | (I don't have data for any non-English sites to compare) |
| 13:41 | <othermaciej> | is <marquee> better or worse than an ad-hoc marquee done with JS? |
| 13:41 | <annevk> | is target= better or worse than window.open() |
| 13:41 | <annevk> | although maybe they're not quite the same question... |
| 13:41 | <Dashiva> | A scripted solution is more flexible, but inaccessible to non-script |
| 13:41 | <hsivonen> | othermaciej: better, because it is easier to isolate and turn off <marquee> |
| 13:43 | <Philip`> | The scripted vertical marquee-like thing at http://www.andhrabank-india.com/ is rather broken in Firefox 3, and overlaps nearby text - native marquee support would make it easier to avoid bugs like that |
| 13:44 | <Philip`> | Oh, it's half broken in Firefox 2 too |
| 13:44 | <Philip`> | (but works fine in Opera) |
| 13:45 | <Dashiva> | I'm not sure I would call that one a marquee, since it doesn't scroll in the text direction |
| 13:45 | <Philip`> | but still the real <marquee> works correctly in all of them |
| 13:46 | <Philip`> | Dashiva: It's similar enough that they'd probably use the same code for simulating a horizontal marquee if there was no <marquee>, and it would similarly break, which wouldn't be good, hence <marquee> being better because it actually does work |
| 13:47 | Philip` | trusts browser developers to write bug-free code much more than he trusts authors of JS code on random web sites |
| 13:51 | <annevk> | whoa, people want <form method=trace> |
| 13:52 | <annevk> | I suppose will address security and actual semantics of such posts some other time? |
| 13:52 | <annevk> | s/such posts/such forms/ |
| 13:53 | <annevk> | especially since HTML is not just used over HTTP |
| 13:54 | <othermaciej> | I vaguely remember that http "trace" has security issues |
| 13:55 | <annevk> | indeed |
| 13:55 | <Dashiva> | I vaguely remember http trace not being that useful for submitting forms... |
| 13:56 | <Lachy> | heh, he wants HEAD and CONNECT too. |
| 13:56 | <Lachy> | CONNECT is used for https connections, so that's not necessary for use in a form method |
| 13:56 | <Philip`> | I can't see why it'd be more useful than just having an echo script on the server, unless I'm misunderstanding the purpose |
| 13:57 | <jdandrea> | othermaciej: yes, trace can be abused via XSS attacks. http://www.google.com/search?q=xss+http+trace |
| 13:57 | <Philip`> | (unless you want to use Max-Forwards to do something equivalent to traceroute but at the HTTP level instead of the IP level; but you wouldn't do that in a form on a web page...) |
| 13:58 | <annevk> | TRACE and CONNECT are both dangerous |
| 13:58 | <annevk> | maybe I should explicitly list them in XHR |
| 13:59 | annevk | ponders |
| 14:00 | <jdandrea> | Q: Should the decision to use trace/track/etc. be left to the web server admin/config (since these are HTTP methods)? It can be disabled there. |
| 14:01 | <annevk> | that's not where the request originates though |
| 14:01 | <jdandrea> | annevk: ah |
| 14:01 | <annevk> | which is what we're talking about |
| 14:01 | <jdandrea> | annevk: misunderstood the thread then - re-reading |
| 14:02 | <jdandrea> | People want <form method=trace>, is that correct? |
| 14:03 | <annevk> | yeah and other method names |
| 14:12 | <jdandrea> | OK. If I understand correctly, the TRACE request originates in the HTML, is processed by the UA, and ultimately received by a HTTP server/proxy/gateway. |
| 14:14 | met_ | just returned from presentation of Silverlight |
| 14:14 | jdandrea | reconsiders - trace isn't supported now, so ... nothing lost, nothing gained. |
| 14:14 | <jdandrea> | met_: and ... ? :) |
| 14:15 | <met_> | doen't mention all flash like fearures, there is only one imporant i think |
| 14:15 | <met_> | HD streaming video |
| 14:15 | <met_> | Sliverlight is trying to compete with Flash and hit FLV format |
| 14:16 | <met_> | there is website http://silverlight.live.com/ where people can upload their silverlight app with videos up to 5GB |
| 14:16 | <Philip`> | jdandrea: I think it would only be handled by an HTTP server, not a proxy/gateway, unless you can set the Max-Forwards header (which I don't think is possible in a form) |
| 14:16 | <Philip`> | I bet they don't support Theora :-( |
| 14:16 | <met_> | and there is one american website like youtoube but based on silverlight (forgot the name) |
| 14:16 | <annevk> | FYI: There will be an open "browser" day on May 15, Paris, to discuss browsers, open standards and all that crap from 9-5 XTech venue. |
| 14:17 | <jdandrea> | Philip `: Aye, I was quoting sec 9.8 here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html |
| 14:17 | <jdandrea> | (well, referencing anyway) |
| 14:17 | <annevk> | No entrance cost whatsoever |
| 14:17 | <jdandrea> | Good point (max-forwards) - missed that |
| 14:17 | <annevk> | Supposedly David (Storey, from Opera) and Molly (molly.com) will post something later today on blogs |
| 14:18 | <met_> | during yeard Silverlight can compete with all flash and flv i thing, but this is the only place where it can be succesful , i suppose |
| 14:18 | <annevk> | Hopefully the XTech schedule page will be updated as well. Although this is slightly different from the rest in that it's free and announced way too late for some people I guess :( |
| 14:42 | <Dashiva> | Hixie: You mentioned reworking the repetition model for wf2 earlier, didn't you? Are the results available anywhere? |
| 14:43 | <zcorpan_> | Dashiva: on his whiteboard |
| 14:50 | mpt | realizes that Silverlight's logo is a blue nappy/diaper |
| 14:54 | <met_> | mpt 8-) |
| 14:54 | met_ | found similarity with blue logo on http://www.silverlight.com/ |
| 15:52 | <Lachy> | hey, I've been asked to do another presentation on HTML5 in August, and I need to come up with an interesting way to present it. Anyone have any suggestions? |
| 15:53 | <Philip`> | Write the whole presentation in <canvas>? |
| 15:53 | <Lachy> | I could make use of <canvas> |
| 15:53 | <annevk> | use XHTML5 |
| 15:53 | <Lachy> | see http://www.openpublish.com.au/ |
| 15:54 | annevk | did that |
| 15:54 | <Lachy> | that's where the presentation will be |
| 15:54 | <annevk> | nobody noticed though |
| 15:56 | <Philip`> | That's just syntax, and barely worth noticing :-) |
| 15:56 | <annevk> | hah, try to convince people of that story |
| 15:57 | Philip` | ought to try to work out what makes so many HTML pages unrepresentable as XML |
| 15:58 | <Philip`> | (I noticed things like "<!-------->" in one case, but most sites seemed to have different problems instead, but it wasn't obvious exactly what was wrong) |
| 15:58 | <Lachy> | since it's more business/managemetn oriented conference, rather than technology-oriented, perhaps I could talk about the benefits that HTML5 will provide... |
| 16:02 | <krijnh> | annevk: I stole your presentation format yesterday btw, used it for 2 presentations |
| 16:03 | <annevk> | "presentation format"? hah |
| 16:03 | <krijnh> | Lachy: What's the first business benefit that comes to mind? |
| 16:03 | <krijnh> | annevk: Yeah, it rocks ;) |
| 16:03 | <annevk> | ???? profit! |
| 16:03 | <krijnh> | <p class="one-liner"> and stuff |
| 16:03 | <krijnh> | Profit? |
| 16:03 | <krijnh> | ;P |
| 16:04 | <Dashiva> | Rich internet applications, krijnh |
| 16:04 | <krijnh> | I think the extensions to <input> are immediate benefits |
| 16:04 | <Lachy> | krijnh, faster and cheaper client side development with improved features and interop |
| 16:04 | <Lachy> | krijnh, more interactive applications |
| 16:04 | <annevk> | fyi: http://www.molly.com/2007/05/10/blue-sky-web-browser-standards-and-interop-summit-xtech-paris/ |
| 16:04 | <annevk> | also: http://my.opera.com/dstorey/blog/show.dml/993551 |
| 16:08 | <krijnh> | Faster, cheaper, more, wow |
| 16:09 | <annevk> | Web 5.0 |
| 16:09 | <annevk> | ???? |
| 16:09 | <annevk> | $$ * 5 |
| 16:09 | <krijnh> | Now that sells |
| 16:09 | <krijnh> | :) |
| 16:28 | <gsnedders> | 5 > 2. |
| 16:29 | <met_> | Web 5 > Web 2 ? |
| 16:29 | <gsnedders> | met_: this time yes. |
| 16:30 | <gsnedders> | met_: http://five-gt-two.spreadshirt.com/ — it was originally a play on HTML5 > XHTML2 |
| 16:32 | <met_> | gsnedders this I know, have wallperar in desktop http://whatwg.majda.cz/wallpapers/ |
| 16:32 | <gsnedders> | :P |
| 20:24 | <Hixie> | can someone (zcorpan?) reply to Kristof Zelechovski's mail? |
| 20:28 | <zcorpan> | Hixie: which one? |
| 20:29 | <Hixie> | the one about the thing with the thing. |
| 20:29 | <Hixie> | uh. |
| 20:30 | <Hixie> | the script. |
| 20:30 | <Hixie> | i think you checked in a fix. |
| 20:30 | <zcorpan> | oh, yep, i replied off-list |
| 20:30 | <Hixie> | cool |
| 20:30 | <Hixie> | thanks! |
| 20:31 | <zcorpan> | np |
| 20:31 | <zcorpan> | :) |
| 20:34 | <Hixie> | ;trianh |
| 20:34 | <Hixie> | uh |
| 20:34 | <Hixie> | wrong window. |
| 21:29 | <hsivonen> | annevk: looks like you have better ad juice than me. I got an offer of $35 for an ad on my doctype page. |
| 21:31 | <jgraham_> | Argh. What is it with people complaining about HTML 5 allowing non-text content in paragraphs? The forms section of the HTML 4 _spec_ is covered in examples of exactly that |
| 21:33 | <hsivonen> | jgraham_: are you referring to autisticcuckoo? |
| 21:33 | <jgraham_> | Yeah. But it's at least the second time its been mentioned this week# |
| 21:35 | zcorpan | is discussing that with toolman over email |
| 21:35 | <hsivonen> | zcorpan: Tim 'toolman' Taylor? |
| 21:36 | <zcorpan> | hsivonen: no, Tommy "TOOLman" Olsson |
| 21:36 | <zcorpan> | i.e. autisticcuckoo |
| 21:36 | <hsivonen> | oh |
| 21:44 | <MikeSmith> | I stopped reading at "In Terry Pratchett's Discworld novels, the ruler of Ankh-Morpork uses an unusual method for reducing crime in the city..." |
| 21:46 | <annevk> | lol |
| 21:46 | <annevk> | that guy should make a parser |
| 21:46 | <annevk> | the illusion that draconian somehow makes your faster is in fact just that |
| 21:46 | <annevk> | an illusion |
| 21:46 | <MikeSmith> | yeah |
| 21:47 | <annevk> | with the notable exception of course of the adoption agency algorithm which is part of HTML5 but you can optimize around that |
| 21:47 | <annevk> | and that shouldn't slow the whole process too much |
| 21:48 | <zcorpan> | annevk: and doesn't affect perf for conforming documents unless you have a streaming parser and can't modify the tree afterwards (in which case you have to buffer) |
| 21:49 | <annevk> | it does affect it slightly i think |
| 21:49 | <annevk> | but you might be right, yes |
| 21:49 | <zcorpan> | i thought it was only triggered when you see an end tag at the wrong place |
| 21:49 | <annevk> | I believe Safari has some tricks to make it go much better for documents without problems |
| 21:50 | <annevk> | zcorpan, not really |
| 21:50 | <annevk> | it's triggered when you hit a certain end tag |
| 21:51 | <annevk> | although if the tree is okayish you might not have to do complicated things but you still have some additional checks and such i believe |
| 21:51 | <zcorpan> | oh. ok. |
| 21:52 | <annevk> | see 'A start tag whose tag name is one of: "b", "big", "em", "font", "i", "nobr", "s", "small", "strike", "strong", "tt", "u"' and 'An end tag whose tag name is one of: "a", "b", "big", "em", "font", "i", "nobr", "s", "small", "strike", "strong", "tt", "u"' |
| 21:57 | <gsnedders> | Hixie: you want anybody to help to put together the references? it's one part of the spec I sorely miss |
| 21:58 | <Hixie> | annevk: if it's a well-formed doc, you bail at step 3, it's no more expensive that checking you're valid in the first place as i understand it |
| 21:58 | <Hixie> | gsnedders: i mostly have the references done (in wf2), the problem is keeping them up to date |
| 21:58 | <gsnedders> | Hixie: and wa1? |
| 21:59 | <Hixie> | the references are mostly the same |
| 21:59 | <gsnedders> | Hixie: mind if I have ago at putting the references together? |
| 21:59 | <annevk> | if people really want it now I suppose you could make it a separate file |
| 22:00 | <annevk> | that p/html5/ people can update and that Hixie extracts now and then? |
| 22:00 | <Hixie> | gsnedders: if you're willing to put aside one day every month for the next 10 years or so to keep them up to date, sure |
| 22:00 | <Hixie> | gsnedders: but i recommend against it |
| 22:00 | <Hixie> | as annevk suggests, we could have it in the google code svn |
| 22:02 | <gsnedders> | Hixie: are there really that many that change that often? Looking through them, it doesn't look as if there are that many that are under proper work. |
| 22:03 | <Hixie> | gsnedders: yes, at least one reference changes every month |
| 22:03 | <Hixie> | gsnedders: e.g. Unicode has new releases every 4 or so months |
| 22:03 | <Hixie> | WebAPI has a new release every 4 or so months |
| 22:04 | <Hixie> | new RFCs come out all the time, relevant ones change every few months |
| 22:04 | <Hixie> | etc |
| 22:04 | <Hixie> | that's the only reason i haven't put the references in yet |
| 22:04 | <gsnedders> | most of the RFCs seem to be ones that don't change so often |
| 22:05 | <annevk> | from a references pov, more often than you want :) |
| 22:05 | <gsnedders> | but you've been dealing with the WF2 references, so I'll take your work |
| 22:05 | <gsnedders> | *word |
| 22:05 | <gsnedders> | annevk: well, ideally, from that POV, they'd never change :P |
| 22:07 | <annevk> | Toolman seems to make the wrong conclusions. He's saying that changing the semantics of elements to match common usage makes it harder to extract semantics. However, it only makes it harder to extract semantics on the minority of pages conforming to the previous definitions. |
| 22:07 | <SpookyET_> | Firefoxing is pissing me off. |
| 22:07 | <SpookyET_> | Firefox* |
| 22:07 | <annevk> | http://www.opera.com/ |
| 22:07 | <SpookyET_> | Every time you load a Window, extensions are getting loaded and executed. You add a few of them, and it takes seconds to open a new window. |
| 22:07 | <SpookyET_> | It slows down opening and closing of tabs too. |
| 22:08 | <gsnedders> | annevk: you hear what I said in #html-wg? |
| 22:08 | <SpookyET_> | Extensions should be loaded once and cloned. |
| 22:08 | <gsnedders> | annevk: about the OS X disk image not mounting? |
| 22:08 | <hsivonen> | SpookyET_: accessing the content DOM from extensions is too slow. :-( blame the security wrapping |
| 22:08 | <annevk> | gsnedders, neh |
| 22:09 | <SpookyET_> | hsivonen: I'm talking about loading blank windows. |
| 22:09 | <hsivonen> | SpookyET_: oh. |
| 22:10 | <SpookyET_> | hsivonen: But, perhaps you are right. It's all xul, not native. Still, I can see it executing (removal of Bookmarks menu entry by the del.cio.us extension). |
| 22:13 | <bewest> | SpookyET_: then don't use extensions :-) |
| 22:13 | <bewest> | hopefully tamarin will make things spiffier |
| 22:15 | <Philip`> | Will Tamarin help with JS->C++ function calls? |
| 22:15 | <bewest> | dunno |
| 22:16 | <annevk> | gsnedders, I wouldn't know anything about it either |
| 22:16 | <Philip`> | (I've used SpiderMonkey in a game engine and I can't quite remember any details but I think the transitions between script and engine are the slowest part - the actual script execution is easily fast enough) |
| 22:17 | <SpookyET_> | SpookyET_: I need them. Can't live without AdBlock, GreaseMonkey, Stylish, and StumbleUpon. |
| 22:18 | <SpookyET_> | The workaround is to use more than one profile. I have another profile for web development, with web dev extensions like FireBug, WebDev ToolBar, XPather, etc. |
| 22:18 | <hsivonen> | Philip`: I'm not an expert, but I would expect JS-C++ crossings not to be helped by Tamarin. moreover, the performance hit when chrome JS accesses the content DOM is even greater than the usual JS-C++ crossing |
| 22:19 | <bewest> | hsivonen: interesting |
| 22:21 | <SpookyET_> | annevk: I'm a fan of Opera's, but I need extensions. Opera with extensions will rock. Unfortunetly, Opera will have to clone XAML for that. |
| 22:22 | <annevk> | That seems like the only viable option, indeed... |
| 22:22 | <hsivonen> | bewest: I could be wrong about Tamarin and crossing to C++. on a second though, a JIT *could* help it |
| 22:22 | annevk | heads home |
| 22:22 | <hsivonen> | *thought |
| 22:34 | <SpookyET_> | hsivonen: Sorry, I did not mean to open a can of worms. |
| 23:10 | <hsivonen> | does IE with MathPlayer Accept: application/xhtml+xml? |
| 23:14 | <zcorpan> | hsivonen: yes |
| 23:14 | <zcorpan> | hsivonen: it's treated as text/html |
| 23:16 | <zcorpan> | (i'm not sure whether the string "application/xhtml+xml" is actually in the Accept header, though) |
| 23:17 | <hsivonen> | zcorpan: I'm interested in the actual Accept header |
| 23:20 | <zcorpan> | seems like the plugin only modifies the UA string |
| 23:20 | <zcorpan> | http://golem.ph.utexas.edu/~distler/blog/archives/000309.html |
| 23:26 | <hsivonen> | zcorpan: ok. |
| 23:26 | <zcorpan> | ah! ie is one step closer to css2.1 conformance with the developer toolbar! :) (it can disable css) |
| 23:27 | <hsivonen> | zcorpan: I'm serving XHTML+SVG if the UA Accepts a/x+x, except if the UA is a known old release of Opera or Gecko |
| 23:27 | <hsivonen> | zcorpan: t/h otherwise |
| 23:27 | <hsivonen> | I hope that's good enough |
| 23:34 | <zcorpan> | hsivonen: yeah, should be. wonder how it performs on mobiles that lie about what they support, though |
| 23:38 | <zcorpan> | ie's dev toolbar is actually pretty good |
| 23:48 | <hsivonen> | zcorpan: http://hsivonen.iki.fi/thesis/html5-conformance-checker mobile test results welcome. |
| 23:49 | <hsivonen> | zcorpan: it'll probably choke mobile browsers that aren't based on a real browser engine anyway |
| 23:50 | <hsivonen> | hmm. looks like I have a bug in my Opera sniffing |
| 23:50 | <zcorpan> | the document is probably too big for most mobiles anyway, i'd think |
| 23:55 | <hsivonen> | fixed the bug in opera sniffing |
