| 00:16 | <MikeSmith> | AryehGregor: is there a way in MediaWiki to comment out some wikitext in the source for a page? |
| 00:17 | <MikeSmith> | nm |
| 00:17 | <MikeSmith> | found it |
| 00:32 | <Philip`> | AryehGregor: Surely JavaScript would be a better idea than Lua, given that everybody on the web knows how to write JS and approximately nobody knows Lua |
| 00:33 | <Philip`> | (and since JS implementations are designed (and extensively tested) to run untrusted code in a sandboxed environment) |
| 00:56 | <AryehGregor> | Philip`, yeah, that was another thought. Probably makes the most sense. |
| 00:57 | <AryehGregor> | But the shared hosting thing is a blocker, unless someone has a JavaScript implementation in PHP that's not even more ridiculously inefficient than PHP itself. ;) |
| 02:16 | <drclue> | Here is something I would like to suggest that would make my life and probably that of others easier. That would be two attributes added to at least the DIV and SPAN elements. Those two attributes would be XML and XSL. It certainly would make doing XML/XSL trasforms more straight forward. |
| 02:16 | <AryehGregor> | What? |
| 02:16 | <AryehGregor> | What are you trying to do and how would this help? |
| 02:18 | <drclue> | Well, I personally have always liked using XSL templates against XML data and being able to simply assign the URLs to those attributes would greatly simplify using templates |
| 02:18 | <AryehGregor> | So what are you asking for to help you with that? |
| 02:20 | <drclue> | Basically I would like to see the attributes XML and XSL added to the spec , and then the browser vendors could tuck their proprietary methods of doing transforms behind those attributes , and authors could simply use the setAttribute methods to perform the manipulations |
| 02:21 | <TabAtkins> | So, again, what are you actually trying to do? |
| 02:22 | <TabAtkins> | I'm hearing something about taking XML from somewhere, and specifying an XSL transform to apply to it. Presumably the result will then render somewhere. |
| 02:24 | <drclue> | I'm not sure I understand the question, but what I'm trying to do is drum up some support for the thought of making XML/XSL more accessible in a standards based way , so that when driving dynamic displays , I can simply reference the url of the XML source and the XSL view and not always have to carry a bunch of browser object sniffing code to perform dynamic transforms. |
| 02:24 | <AryehGregor> | What do you mean "the attributes XML and XSL"? |
| 02:26 | <drclue> | <div XML="http://...." XSL="http://" /> |
| 02:27 | <AryehGregor> | Um, what are those supposed to do? |
| 02:30 | <drclue> | The XSL attribute specifies an external XSL stylesheet to apply to the XML data referenced by the XML attribute. In the absence of the XSL attribute , the browser would first look to the XML file itself for a style reference and then fall through to the native rendering of the XML tree. |
| 02:32 | <AryehGregor> | You can already do client-side XSL. |
| 02:34 | <drclue> | Yes I can already do client-side XML/XSL, but it suffers from vendor specific hacks that could be neatly tucked away by giving some attributes for that purpose |
| 02:42 | <drclue> | I really don't see any downside in affording a more effective way to integrate XML/XSL w3.org standards in a page. The bandwidth savings afforded by XSL are hard to deny. The promotion of MVC techniques associated with XML/XSL is a positive thing too. Affording browser vendors a cheap way to standardize is a big bonus too. |
| 02:43 | <variable> | if I want to propose a new CSS attribute on text "gender: male; or gender: female;" for spoken media - where is the appropriate place to do so? |
| 02:43 | <AryehGregor> | variable, www-style. |
| 02:43 | <AryehGregor> | drclue, if vendor-specific hacks are required, then that should be fixed by itself. You don't need a totally new way of including XSL to do that. |
| 02:44 | <AryehGregor> | And there is a cost for implementing every feature. "There's no downside" isn't sufficient reason to get anything added to the spec. It's long enough already. |
| 02:45 | <variable> | #2: I am capable of voting on the issues page but I don't see any of my emails there. Am I missing something ? |
| 02:45 | <variable> | I thought only people who have issues on the list can vote :| |
| 02:46 | <AryehGregor> | What? |
| 02:46 | <variable> | "Only people who have sent feedback that has ended up on this list are able to vote." --> I can vote but I don't see any of my emails |
| 02:48 | <drclue> | @AryehGregor Just by itself , those XML XSL attributes would have significant value. The fact that providing a standards based way of doing something also ditches the need to use proprietary methods is added gravey |
| 02:48 | <AryehGregor> | You can include XSL without proprietary methods. |
| 02:48 | <AryehGregor> | <link rel=stylesheet href=mystylesheet.xsl> |
| 02:48 | <AryehGregor> | If browsers don't all support that, that won't be fixed by making up new attributes that mean a similar thing. |
| 02:51 | <drclue> | That would be a page wide item. Elements in pages appear dynamically and get included in a wide variety of ways. Being able to specify the XML data and the XSL structure at the element level allows for better compartmentalization and a more effect way to draw in units of information into a page |
| 02:52 | <AryehGregor> | Okay, well, send it to the list if you like. I suggest you focus on use-cases rather than solutions. |
| 02:55 | <nessy> | Hixie: check out this ass subtitled video http://www.animereactor.dk/kara/files/flcl-ed.mkv - awesome crack! |
| 03:01 | <drclue> | @AryehGregor Use cases include tabular data browsing , charts ,info graphics , news feeds, multi-view data, calenders and miles and miles of common every day activities. If one sees integration of data and presentation in an element of a page, those XML/XSL attributes could handle the vast majority of it. |
| 03:01 | <AryehGregor> | Okay, well, I can't change the spec. You'll have to post to the list. |
| 03:37 | <drclue> | @AryehGregor Well, I've taken your advice and posted the thought to the list , and we'll have to see if I can get any traction in there amongst the hurricane force winds of conversation. |
| 04:04 | <karlcow> | http://latimesblogs.latimes.com/technology/2010/06/apple-location-privacy-iphone-ipad.html |
| 05:48 | <MikeSmith> | kennyluck: at t45 now |
| 06:49 | <hsivonen> | nessy: aren't those subtitles burned into the video frame? they scale as bitmaps in Totem. |
| 06:50 | <nessy> | that file has it all burnt in, but I am told they were authored as ASS |
| 06:50 | <nessy> | it's just that not all players support all the functionalities, so it's burnt in |
| 06:51 | <nessy> | I'm pretty sure it's not your 90% use case for subtitles/captions, but it's totally awesome :) |
| 06:53 | <othermaciej> | I can't believe someone had the gumption to name a file format "ASS" |
| 06:53 | <hsivonen> | nessy: I see |
| 06:54 | <nessy> | othermaciej: ;) |
| 06:54 | <MikeSmith> | whoever picked that name deserves an award of special merit |
| 06:54 | <nessy> | didn't WHATWG almost turn into a task force? ;) |
| 06:55 | <nessy> | ASS really is ASSA for Advanced SubStation Alpha - but ASS is nicer |
| 06:55 | <hsivonen> | turns out I need to point people to #AVNormalize so often that I have it in my AwesomeBar |
| 06:59 | <nessy> | oh! what is #AVNormalize ? |
| 07:00 | <hsivonen> | nessy: http://www.w3.org/TR/xml/#AVNormalize |
| 07:00 | <hsivonen> | (not related to the subtitle discussion at all) |
| 07:00 | <nessy> | ah, and here I was thinking of AV=audio/video! |
| 07:01 | <nessy> | wrong filters on my eyes ;) |
| 07:01 | <hsivonen> | :-) |
| 07:21 | <MikeSmith> | hsivonen: do you have any thoughts of whether any HTML elements should be allowed in <annotation-xml> ? |
| 07:21 | <MikeSmith> | or, more importantly, if the parsing algorithm should be changed to allow them there |
| 07:21 | <MikeSmith> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=9887 |
| 07:22 | <MikeSmith> | Simon suggested that maybe they could be dealt with by requiring they be wrapped in a <div> |
| 07:23 | <hsivonen> | MikeSmith: I'm OK with making <div> (maybe <span>, too, just in case?) magic there, but what's the use case? |
| 07:23 | <hsivonen> | hmm. actually, <div> is less dangerous, since it is scoping on its own right |
| 07:24 | <hsivonen> | MikeSmith: even without a use case now, I'd be OK with making <div> magic there in case a use case shows up later |
| 07:24 | <MikeSmith> | hsivonen: the use case is for using HTML to annotate MathML expressions in the same way that SVG or MathML itself can be used for such... but that said, I don't really understand the general use case for annotating MathML expressions to begin with |
| 07:25 | <hsivonen> | MikeSmith: the best use case I've seen for annotations is using SVG to draw notation that MathML itself doesn't support |
| 07:25 | <hsivonen> | dunno how HTML would help there |
| 07:27 | <MikeSmith> | hsivonen: and even for that use case, couldn't SVG just be used within an <mtext> element, with no need to use the whole <semtantics>/<annotation-xml> apparatus? |
| 07:32 | <hsivonen> | MikeSmith: if the validity definition is adjusted, sure |
| 07:34 | <MikeSmith> | hsivonen: we have the freedom to adjust the validity definition |
| 07:34 | <MikeSmith> | to define it in the HTML5 spec |
| 07:34 | <hsivonen> | MikeSmith: works for me |
| 07:37 | <MikeSmith> | but getting back to annotation-xml, I guess I'm just wondering whether it is worth the trouble to try to convince implementors and Hixie that changing the parsing algorithm to allow <div> (and/or <span>) within annotation-xml as a holder for HTML content is worth the effort |
| 07:37 | <MikeSmith> | it sounds like you're amenable at least |
| 07:38 | <MikeSmith> | I can ask the MathML WG if they have use cases for HTML content in annotation-xml |
| 07:39 | <Hixie> | i think allowing just <div> would just end up confusing authors |
| 07:39 | <Hixie> | if we allow only one HTML element it should be <body> (or <html>) |
| 07:40 | <Hixie> | nessy: actually with WebSRT and the CSS extensions to address individual bits of the text cues, that's more or less possible |
| 07:40 | <hsivonen> | Hixie: Degrade Gracefully... |
| 07:41 | <Hixie> | hsivonen: both of those would degrade fine if no attributes are present |
| 07:41 | <hsivonen> | Hixie: <div> is the new <body>. see Atom |
| 07:41 | <Hixie> | Atom is not an example of good language design |
| 07:41 | <Hixie> | (it's not especially terrible, but it's not what i would suggest we base our decisions on) |
| 07:42 | <othermaciej> | <body> doesn't seem like a good element for other languages to use when embedding a snippet of HTML |
| 07:42 | <othermaciej> | for one thing, it means that when you nest that element back in HTML, you get nested <body>, which is pretty confusing |
| 07:42 | <othermaciej> | second, there shouldn't be an expectation that a snippet is necessarily like a complete document |
| 07:43 | <othermaciej> | (though really you'd want <html> if you are claiming to provide a complete embedded HTML document) |
| 07:43 | <drclue> | I already embed HTML in XML for use with XSL transforms |
| 07:45 | <Hixie> | othermaciej: without a solid use case, it's not clear whether it's for snippets or documents or something else |
| 07:45 | <othermaciej> | fair enough |
| 07:46 | <MikeSmith> | add to this that the MathML spec doesn't really define the rendering behavior of annotation-xml content |
| 07:47 | <MikeSmith> | it leaves it up to other specs to do that |
| 07:47 | <MikeSmith> | e.g., HTML5 |
| 07:47 | <drclue> | I'd actually like to see an XML and XSL attribute for HTML elements myself. I use so many XSL transforms in day to day work , it would seem worth while to have an easy way to integrate them at the element level as opposed to having to muck around with vendor specific javascript |
| 07:49 | <Yudai> | MikeSmith: do you have any ticket for me to write patches? |
| 07:50 | <MikeSmith> | Yudai: have not talked with hsivonen about it yet |
| 07:50 | <MikeSmith> | hsivonen: Yudai is looking to help with v.nu bug fixes |
| 07:50 | <MikeSmith> | so if you have suggestions of any specific bugs he could work on, that'd be great |
| 07:50 | MikeSmith | goes to look through the bug list himself |
| 07:51 | <MikeSmith> | Yudai: there's at least one open bug I already Cc'ed you on |
| 07:52 | <hsivonen> | Yudai: oops. sorry, my email app had filtered your email to a folder where I didn't expect it. |
| 07:52 | <MikeSmith> | Yudai: http://bugzilla.validator.nu/show_bug.cgi?id=720 "Validating post-processed files but reporting source line numbers and file names" |
| 07:53 | <MikeSmith> | which Hixie filed |
| 07:53 | <Yudai> | MikeSmith: okay, i try to work on this |
| 07:53 | <MikeSmith> | Yudai: it's not a particularly easy one, I guess |
| 07:54 | <MikeSmith> | but certainly useful |
| 07:54 | <hsivonen> | I'll land 721 |
| 07:54 | <MikeSmith> | Yudai: and you could bug Hixie for test cases and such |
| 07:54 | <MikeSmith> | hsivonen: ah, cool |
| 07:55 | <Yudai> | hsivonen: thx |
| 07:55 | <Yudai> | MikeSmith: i got it |
| 08:05 | <webben> | drclue: By browser-specific hacks, do you mean: http://www.w3schools.com/xsl/xsl_client.asp ? |
| 08:08 | <drclue> | @webben Maybe not that one in particular , but often there are variations of that. That kind of thing aside though , I think having an XML and XSL attribute would prove very useful of it's own right. I actually posted something to the mailing lists about it today |
| 08:08 | <webben> | yeah i saw |
| 08:09 | <webben> | like AryehGregor I don't see how the attribute removes the need for such hacks |
| 08:10 | <webben> | a consistent xsltprocessor and xslt implementation would remove the need (eventually) and be more generally useful. |
| 08:10 | <MikeSmith> | hsivonen: I think I can now check in the jing required-but-missing attributes/elements patch directly |
| 08:11 | <MikeSmith> | OK if I do that |
| 08:11 | <drclue> | Perhaps in some cases , folks might need to resort to that kind of thing, but for most of the use cases I come across , simply having the attributes would deal them |
| 08:11 | <MikeSmith> | ? |
| 08:11 | <MikeSmith> | hsivonen: I believe I had made all changes from your review |
| 08:11 | <hsivonen> | MikeSmith: cool. yes, OK. |
| 08:11 | <MikeSmith> | OK, great |
| 08:11 | <webben> | drclue: But there's no difference between the two solutions from that perspective. |
| 08:12 | <webben> | drclue: Both solutions would take time to become commonly implemented. Until that time, the hackery would still be required. |
| 08:12 | <hsivonen> | Yudai: landed and deployed. Thank you. |
| 08:12 | <Yudai> | hsivonen: roger. thanks |
| 08:13 | <hsivonen> | And sorry about the delay. |
| 08:16 | <drclue> | @webben the attributes would be trivial to implement , and with the promise of HTML5 , this is the time to do it. having |
| 08:19 | <drclue> | It will take time for browsers to support all of HTML5 anyways , so I'm not swayed at all by the idea that such may be the case for the XML / XSL attributes |
| 08:19 | <MikeSmith> | Opera Mobile (non-Mini) on an Android device - http://www.pcpro.co.uk/blogs/2010/06/21/toshiba-ac100-mobile-internet-device-first-look-review/ |
| 08:20 | <MikeSmith> | though it's not a handset or smartphone |
| 08:20 | <MikeSmith> | netbook, I guess |
| 08:20 | <drclue> | I do know that I would put them to work almost immediately for my closed audience applications , and build a little crutch script for those cases where I needed to provide legacy support. Basicly the same kind of thing I've been doing forever |
| 08:21 | <hsivonen> | I wonder how Android/Meego usability works when the platforms are stretched across both touch screen devices and netbooks that have a keyboard and a trackpad |
| 08:22 | <MikeSmith> | the touchscreen difference definitely seems like the biggest one |
| 08:22 | <othermaciej> | some Android devices do have an auxiliary hard keyboard |
| 08:22 | <MikeSmith> | I've not actually seen Android running on non-touchscreens |
| 08:22 | <othermaciej> | and a number have a trackball |
| 08:22 | <hsivonen> | also, I wonder if Opera Mobile for Android is OEM-only or if it'll be user-installable |
| 08:22 | <othermaciej> | to me, having a touchscreen *and* a pointing device on a phone seems weird |
| 08:22 | <MikeSmith> | hsivonen: I would bet that at this point it's OEM-only |
| 08:22 | <othermaciej> | is Opera Mobile for Android not in the Android Market? |
| 08:23 | <hsivonen> | I'm rather disappointed that Nokia put a hardware keyboard in N900 instead of making the on-screen keyboard rock |
| 08:23 | <slartsa> | I disagree |
| 08:23 | <hsivonen> | I think the onscreen keyboard on N900 is already better than the hardware keyboard but not as good as on iPhone |
| 08:23 | <MikeSmith> | othermaciej: no Opera Mobile in Android Market as far as I know |
| 08:24 | <slartsa> | most people still need the actual feeling of a keyboard at their fingertips |
| 08:24 | <slartsa> | ..even though on-screen would be more efficient |
| 08:24 | <hsivonen> | slartsa: N900 is heavier than e.g. HTC Desire |
| 08:24 | <MikeSmith> | I do think having both a touchscreen and pointing device is odd |
| 08:24 | <hsivonen> | slartsa: being heavy sucks |
| 08:24 | <slartsa> | hey! I am heavy! |
| 08:24 | <slartsa> | well it's not that bad |
| 08:24 | <hsivonen> | slartsa: sorry. I meant it sucks for phones |
| 08:24 | <slartsa> | :D |
| 08:25 | <MikeSmith> | slartsa: I guess most people also prefer the feeling of viewing things on a 21-inch+ monitor |
| 08:25 | <slartsa> | I'm glad the phone had sold so well |
| 08:25 | <slartsa> | Not sure it would have if it didn't have that keyboard |
| 08:25 | <drclue> | The only problem I have with soft keyboards is finger registration. I often type pretty much in the dark, sorta like using my TV remote. It gets a little rough when there is nothing but looking as an option |
| 08:30 | <hsivonen> | anyway, it seems that keypad without mouse, keyboard with mouse, single-touch and multi-touch all call for different interaction design, so it's not clear that it's a good thing to strech the interaction layer of a platform across those different device categories |
| 08:30 | <MikeSmith> | what's the difference between a MID and a netbook? |
| 08:30 | <hsivonen> | although Opera Mobile is doing really well across the first three (I haven't tried Opera Mobile on a multi-touch device) |
| 08:31 | MikeSmith | finds http://en.wikipedia.org/wiki/Mobile_internet_device |
| 08:33 | <drclue> | Keystrokes with evt.x evt.y , sorta sounds weird, but then again maybe that is not so weird. |
| 08:38 | <webben> | drclue: Without implementor experience, I'd be wary of declaring anything trivial to implement. |
| 08:39 | <webben> | drclue: But my argument is not time would be required for your solution, but simply that other solutions would remove the need for hacks without introducing new features to the platform. |
| 08:40 | <webben> | drclue: One could always build a crutch script that uses a data-* attribute instead, again without introducing a new feature. |
| 08:40 | <drclue> | @webben I've been implementing things since before Microsoft and Apple, so I would not worry too much about my assumptions regarding implementation difficulties. All the code is there in the browsers already |
| 08:41 | <webben> | drclue: Implementing things in JS... or implementing things in browser code? |
| 08:41 | <drclue> | Interesting assumption that there was javascript way back then :) |
| 08:42 | <webben> | drclue: I don't meant random implementation experience, I mean actual browser implementation experience. |
| 08:44 | <drclue> | Well, obviously there are only so many people who have had direct exposure to implementing current day browser code, although I did write a browser way back when. There sorta has been little need for me to do so these days |
| 08:44 | <drclue> | I've also written web servers from scratch, implemented my own TCP/IP stacks and many other things over the years |
| 08:46 | <drclue> | The fact is that the code to do each aspect of what I'm suggesting is already built into all the browsers, and the few bits of code to leverage whats there would not seem to be such a big deal as to try and make a point of it |
| 08:47 | <webben> | I'm not arguing it is or is not relatively easy ; I'll leave that to somone who's actually going to try to code it. |
| 08:48 | <MikeSmith> | othermaciej: do you recall a decision about the shortname for the polyglot author guide? |
| 08:49 | <MikeSmith> | I find the FPWD request that went to the chairs list |
| 08:49 | <MikeSmith> | but that does not have a specific request for a shortname |
| 08:49 | <webben> | drclue: If you're pointing to an XML source and an XSLT source, what would be the practical advantage over pointing to an seamless iframe with a link in it? |
| 08:50 | <othermaciej> | MikeSmith: I do not |
| 08:50 | <MikeSmith> | ok |
| 08:50 | <othermaciej> | MikeSmith: is that within the discretion of the chairs/team? |
| 08:50 | <webben> | drclue: Might the iframe not be better if you really want to build page-independent widgets? |
| 08:50 | <othermaciej> | if so, I can ask Sam tomorrow (my suggestion would be "polyglot" as a shortname) |
| 08:51 | <MikeSmith> | yeah, it is chairs discretion with PLH signoff -- it just does not seem to have been discussed yet |
| 08:51 | <drclue> | @webben I might want to change the XML or XSL attribute independently. |
| 08:51 | <MikeSmith> | the FPWD cites http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html but not a shortname |
| 08:51 | <webben> | drclue: You might. But with an iframe you have the ability to style your widget in a sandbox. |
| 08:52 | <MikeSmith> | so the implication I guess is that the request is for the shortname "html-xhtml-author-guide", which isn't particularly short.. |
| 08:52 | <hsivonen> | /TR/polyglot/ ? |
| 08:52 | <webben> | drclue: And if you did change the value of the XSL attribute, wouldn't the original DOM have been replaced already? |
| 08:53 | <drclue> | XML is the data, XSL is the template the rendering is the transform of the two. They are three data items |
| 08:54 | <drclue> | If I have the XML , but decide I want to perhaps look at a calender in day/week/month views , I only have to change the XSL attribute |
| 08:55 | <hsivonen> | drclue: I think getting implementors interested in adding XSLT-related features is unlikely. |
| 08:56 | <drclue> | The XSL processor is already in there. This is for the implementor just a rephrasing of the call of existing functions |
| 08:56 | <webben> | drclue: yeah, good point, you can refetch the DOM via the XML source. |
| 08:57 | <MikeSmith> | hsivonen: maybe /TR/html-polygot |
| 08:58 | <MikeSmith> | drclue: maybe you could demonstrate the usefulness of it by implementing support for it in a Javascript library first |
| 08:59 | <MikeSmith> | drclue: or lobbying with developers of some existing JS library to |
| 09:00 | <drclue> | There are javascript libraries for that kind of thing out there all over the place, but there really is no reason that one should need to resort to javascript to perform this task |
| 09:03 | <MikeSmith> | drclue: I guess by that logic it could be argued that there's also not need for browser implementors to resort to implementing support for it natively |
| 09:04 | <MikeSmith> | part of the point of doing it through a JS library first would be to demonstrate that it's something that people would actually use |
| 09:05 | <MikeSmith> | if you implemented it in library, the JS part of it would not need to be exposed to developers |
| 09:05 | <drclue> | By and large the majority of my server side tools emit data as XML. Many many sites provide data via XML. The majority of that data simply needs to be formatted , and really has no need to be manipulated with javascript. |
| 09:06 | <MikeSmith> | drclue: so all that developers would need to do is include your JS library, and things would work just like you describe |
| 09:06 | <MikeSmith> | they would not have to do any actual JS coding themselves |
| 09:06 | <MikeSmith> | you would do it all for them |
| 09:06 | <MikeSmith> | in the library you're going to develop |
| 09:07 | <drclue> | Since there is no XML or XSL attribute in HTML at this time , nobody would be able to create valid markup unless they perhaps wanted to write their own DTD, or perhaps do multiple transforms or other gymnastics |
| 09:08 | <jgraham> | drclue: What hsivonen said. XSL is rare on the web so sinking more resources into it when vendors could be working on making javascript performance more awesome or video use less CPU or implementing new form input types, or whatever, seems like a bad idea |
| 09:08 | <jgraham> | drclue: You can do what you want using data-foo attributes and javascript |
| 09:10 | <drclue> | Perhaps the reason that XSL is so rare on the web is that deploying it in a valid manner is generally a pain |
| 09:10 | <drclue> | given the current context. |
| 09:12 | <jgraham> | Perhaps. Or perhaps it is because people don't like writing xslt. It doesn't make sense for vendors to sink resources into that experiment |
| 09:12 | <jgraham> | especially given that you can do it yourself rather easilly |
| 09:15 | <drclue> | I know that XML/XSL saves tons of server resources and bandwidth, and also fits in well with the MVC school of design. Some people think CSS is really hard to code, and maybe for them it is. I tend to hand code just about everything so it does not typically bother me. Some folks think that even a simple HTML page is too complicated to type, but I guess why for them there are products like dreamweaver |
| 09:17 | <drclue> | BRB |
| 09:21 | <hsivonen> | CSS hard compared to XSLT???? |
| 09:22 | <drclue> | There are many aspects of web development that are not everyones cup of tea, but I for one really appreciate the many w3.org standards and encourage interoperability among those standards. |
| 09:23 | <annevk> | finally someone with a clue has entered the channel; unfortunately we don't do logic |
| 09:23 | <annevk> | ;p |
| 09:29 | <drclue> | XSLT is not hard at all. It like CSS has it's interesting nooks and crannies. Actually in some ways , XSL and CSS are but flip sides of the same coin |
| 09:29 | <hsivonen> | Hixie: when you decided to make cache manifests triggered on root instead of <link> did you happen to write down all the reasons why <link> would have sucked? |
| 09:30 | <hsivonen> | Hixie: because resource packages will have the same problems |
| 09:30 | <hsivonen> | resource packages formerly known as "Limi packages" |
| 09:30 | <Hixie> | i needed something that happened before the root element's style="" attribute was seen |
| 09:31 | <annevk> | hsivonen, what is a Limi package? |
| 09:31 | <hsivonen> | Hixie: ouch. I didn't think of that |
| 09:31 | <annevk> | hsivonen, oh, the stuff that won't be needed if we get SPDY? |
| 09:31 | <hsivonen> | annevk: http://stanford.edu/~jlebar/moz/respkg/ |
| 09:32 | <annevk> | hsivonen, seen the commentary from mnot? |
| 09:32 | <hsivonen> | annevk: nope |
| 09:32 | <hsivonen> | Hixie: style='' is going to be a problem. sigh. thanks |
| 09:33 | <annevk> | http://www.mnot.net/blog/2010/02/18/resource_packages |
| 09:33 | <Hixie> | hsivonen: note that i failed to handle <?xml-stylesheet?> and <?binding?> in XML |
| 09:33 | <annevk> | <?xbl?> mister |
| 09:34 | <hsivonen> | Hixie: well, at least those need to be racy |
| 09:34 | <Hixie> | annevk: might as well be <?unicorn?> right now for all the practical effect on the world it's had :-P |
| 09:34 | <hsivonen> | Hixie: but consider <html style='...'> (pause in network stream that flushes everything) <link> |
| 09:34 | <annevk> | jaja :) |
| 09:35 | <hsivonen> | vs. <html style='...'><link> (flush speculations here) |
| 09:36 | <Hixie> | hsivonen: the network isn't hugely relevant for manifest="", it's just a matter of making sure you didn't pick the wrong appcache if you're offline |
| 09:36 | <hsivonen> | I wonder if we could defer the processing of style attributes until head has been popped off the stack |
| 09:36 | <Hixie> | that would suck |
| 09:37 | <hsivonen> | Hixie: there was a bug about speculations arriving without manifest |
| 09:37 | <hsivonen> | Hixie: which I fixed by putting manifests on the speculative load side channel |
| 09:37 | <hsivonen> | since manifest processing doesn't really need the DOM node |
| 09:37 | <Hixie> | what the manifest loading can be sync |
| 09:37 | <Hixie> | it's not network or file bound |
| 09:38 | <Hixie> | assuming you cache the known manifests in ram |
| 09:38 | <hsivonen> | Hixie: I don't understand what you are saying |
| 09:39 | <Hixie> | i'm saying i don't understand why you would need to put manifests on a load channel of any kind to solve any bugs |
| 09:39 | <hsivonen> | Hixie: what I'm saying is that stuff broke when we had speculative script loads start before the app cache stuff knew it's going to be seeing a manifest |
| 09:39 | <Peter`> | Is there a reason (or just a lack of proposal?) for not including DOM methods for a dynamic manifest, giving JavaScript the ability to add/remove files, opposed to a single static file? |
| 09:39 | <hsivonen> | I don't know the detail, either, I just know stuff broke |
| 09:40 | <Hixie> | hsivonen: it doesn't need to see the manifest, it just needs to know which cache to load files from, which is keyed from the manifest string -- no network or disk I/O needs to happen to do the processing necessary to prepare the browser for handling loads due to a manifest="" attribute |
| 09:52 | <hsivonen> | ok. this style stuff is going to suck majorly for interop across browsers with different speculative parsing implementations and document.open() impl. details |
| 09:53 | <hsivonen> | any reason why I shouldn't suggest changing resource packages to use <html packages='url1 url2 url3'> instead of <link>? |
| 09:58 | <annevk> | MikeSmith, how likely is it that we publish? |
| 10:00 | MikeSmith | checks with his bookies |
| 10:01 | <annevk> | :) |
| 10:02 | <hsivonen> | hmm. abarth is testing evil cases. good. |
| 10:08 | <MikeSmith> | abarth is good at exposing evil |
| 10:09 | <Hixie> | hsivonen: what's the use case for this? |
| 10:10 | <MikeSmith> | http://twitter.com/s0enke "@w3c should consider rfc1867 for xhr uploads" |
| 10:10 | <hsivonen> | Hixie: avoiding multiple HTTP requests in order to speed up sites / web apps |
| 10:10 | MikeSmith | looks ups RFC 1867 |
| 10:11 | <hsivonen> | Hixie: I already sent my suggestion |
| 10:11 | <annevk> | MikeSmith, that guy should take a look at XHR2 |
| 10:11 | <MikeSmith> | annevk: I'll tell him |
| 10:11 | <MikeSmith> | annevk: or somebody will |
| 10:12 | <annevk> | I could, but I'm getting twitter-lazy |
| 10:12 | <annevk> | IRC starts to becoming the only convenient message-gateway |
| 10:13 | <annevk> | pretty much always up, fast, archived... |
| 10:13 | <hsivonen> | email is full of spam and my XMPP server stopped working |
| 10:14 | <annevk> | TabAtkins, you around? |
| 10:15 | <Hixie> | MikeSmith: is the microdata spec publishing WD or LC? |
| 10:27 | <MikeSmith> | Hixie: I don't recall that you ever got a response to your request to transition it to LC, did you? |
| 10:28 | MikeSmith | pokes othermaciej |
| 10:28 | <Hixie> | i think sam said it was in his court or something |
| 10:28 | <othermaciej> | WD still for this round |
| 10:28 | <Hixie> | (i have great trouble understanding what he's saying half the time) |
| 10:28 | <othermaciej> | though we hope to publish an LCWD of it soon |
| 10:28 | <Hixie> | not really sure why it's had to wait, what, two months so far? |
| 10:28 | <MikeSmith> | I guess that spec would be a good was to tests the waters on LC process |
| 10:32 | <hsivonen> | speaking of chair responses, I haven't seen a response to my request for permission to submit "high-level prose" in the ASCII ref Change Proposal |
| 10:33 | <othermaciej> | noted |
| 10:34 | <othermaciej> | I think given Sam's follow-up, we would likely interpret your proposal as a very roundabout way of saying "change nothing" (thought it also admits that other solutions satisfying its constraints would also be acceptable) |
| 10:34 | <othermaciej> | I would personally prefer if it were more explicit about the change being requested |
| 10:35 | <othermaciej> | I will ask Sam what he thinks |
| 10:35 | <hsivonen> | othermaciej: as drafted, it allows the Editor to use a better reference without reopening a Decision |
| 10:36 | <annevk> | instead of ASCII we could just use Windows-1252 maybe |
| 10:36 | <annevk> | for UAs they're pretty much the same anyway |
| 10:37 | <hsivonen> | annevk: there are many ways to draft the passage without ever referencing ASCII |
| 10:38 | <hsivonen> | annevk: the point of my CP isn't to suggest an ideal wording but to make the point that we shouldn't be using the Decision Process for something as trivial as this so the Decision should uphold editor discretion |
| 10:41 | <annevk> | agreed that this is a waste of time; though all small one-liner comments at this point are marginal compared to what went before... :/ |
| 10:42 | <annevk> | arguably it should be spelled out, as references are typically not followed |
| 10:43 | <Hixie> | i can't believe how much of our time julian and the chairs have so far wasted with this asinine issue |
| 10:43 | <annevk> | but I guess we can only do that once we have a fixed set of encodings and the encoding proliferation battle has been won |
| 10:53 | <MikeSmith> | annevk: http://twitter.com/s0enke/status/16761371509 "i've read the spec and i'm missing a xhr.upload() method which uses rfc1867 (which every serverside language supports ootb)" |
| 10:53 | <annevk> | hmm whatever then |
| 10:54 | <annevk> | send() accepts a request entity body as argument |
| 10:54 | <annevk> | which can be a File, but also a FormData object |
| 10:55 | <annevk> | the only reason 1867 is not mentioned because I defined it in terms of HTML5 stuff, as to not duplicate much and encourage code reuse |
| 10:55 | <hsivonen> | the environment of validator.nu supports straight http request bodies ootb but not form-based uploads... |
| 10:56 | <hsivonen> | differemce between servlet and php philosophies I guess |
| 10:57 | <MikeSmith> | does php have a philosophy? |
| 10:57 | <MikeSmith> | besides anarchy, I mean |
| 10:58 | <MikeSmith> | or whatever name there might be for "absence of any philosophy" |
| 11:06 | <drclue> | My take on PHP is that it is more organic than philosophic. I do code a lot with it and even write servers with it. For decades I coded most everything in C/C++ but not so much these days. It's weird , I have versions of many of my projects written independently in both languages |
| 11:08 | <s0enke> | hi |
| 11:09 | <s0enke> | MikeSmith, thx for the hint |
| 11:11 | <s0enke> | proposal for xhr2: define a "upload" method which uses default rfc1867 upload semantics. this way server software (php etc) would not have to reinvent the wheel for file uploads. any plans / ideas / hints on this? |
| 11:13 | <MikeSmith> | annevk: ↑ |
| 11:13 | <Hixie> | MikeSmith: done the pub update |
| 11:14 | <Hixie> | bed now |
| 11:14 | <MikeSmith> | Hixie: thanks |
| 11:14 | <Hixie> | nn |
| 11:15 | <annevk> | s0enke, see the FormData object |
| 11:15 | <MikeSmith> | s0enke: hsivonen also points out that Java servlet environment that validator.nu runs under does not support form-based uploads ootb |
| 11:15 | <annevk> | s0enke, send() already accepts a request entity body; there's no need for a new method |
| 11:15 | <MikeSmith> | s0enke: said servlet environment is Jetty-based (for validator.nu) |
| 11:17 | <s0enke> | MikeSmith, well ok, but I guess the rfc1867 way is the most spread and default way to do file uploads, isnt it? ;-) |
| 11:17 | <s0enke> | annevk, will have a look, thx |
| 11:18 | <annevk> | I thought you read the specification? ;) |
| 11:19 | s0enke | hides |
| 11:19 | <MikeSmith> | s0enke: I suppose. But I recommend being deeply suspicious of anything published by the IETF |
| 11:22 | <s0enke> | MikeSmith, :D I rather implement formdata right now than discussing the value of rfcs ;-) |
| 11:24 | <MikeSmith> | s0enke: you clearly have your priorities all messed up |
| 11:27 | <MikeSmith> | s0enke: anyway, seriously, this is the best place to ask questions about anything related to actually implementing Web technologies |
| 11:27 | <MikeSmith> | at least the client-side part |
| 11:28 | <MikeSmith> | browser technologies |
| 11:28 | <annevk> | and you can get laughed at by spec editors |
| 11:28 | <MikeSmith> | and you can laugh at the spec editors too |
| 11:28 | <s0enke> | MikeSmith, yeah. all the real nerds live in irc ;) |
| 11:29 | <annevk> | MikeSmith, it's a popular sport |
| 11:30 | <drclue> | heh heh heh |
| 11:30 | <hsivonen> | s0enke: what server side stuff doesn't give you access to the HTTP request body directly? |
| 11:33 | <s0enke> | hsivonen, they all do. but at least in PHP, rfc1867 gives you powerful features like validating the request, putting the data into a tmpfile, creating a $_FILES array with all the metadata. In a normal post, you'd have to stream the content into a file in userland context (and blow up your server memory). the c context is universes more efficient. |
| 11:35 | <hsivonen> | streaming to a file blowing up server memory seems like an indication of something being very wrong |
| 11:36 | <hsivonen> | s0enke: actually, RFC 1867 is more of a buffering problem than the HTTP request body itself |
| 11:36 | <hsivonen> | s0enke: in enviroments that expose the real buffer cost and don't hide it from the programmer |
| 11:37 | <s0enke> | hsivonen, yeah. but then the world has to write their web apps in C again ;-) |
| 11:38 | <s0enke> | I'm just a slave of available technologies |
| 11:43 | <s0enke> | damn, the formData will be implemented in firefox 4 :-/ |
| 11:45 | <drclue> | @sOenke: You don't have to go back to C/C++ to do what you want. If you want to process a request in a unique way, you could always run a PHP based server on some other port to do that. |
| 11:48 | <drclue> | There are times when C/C++ is needed for some particular bit of performance , or to do something really low level, but most days of the week PHP will do just fine, and one gets to skip the compile/link coffee break. |
| 11:50 | <hsivonen> | s0enke: why is it a "damn" for it to get implemented? |
| 11:59 | <hsivonen> | I wonder if there are proper statistics on how often HTTP requests are satisfied from proxy cache |
| 12:00 | <hsivonen> | or what percentage of Web users is behind proxies |
| 12:02 | <drclue> | @s0enke I think you can find a Firefox 3.6 hack-a-round for the time being at http://hacks.mozilla.org/2010/05/formdata-interface-coming-to-firefox/ and then perhaps trade it out when Firefox 4 comes out. |
| 12:04 | <drclue> | I for one am hoping that between WebM and a good showing in FireFox 4 that they get a new lease on life. These days I'm traveling in chrome (dev version at that) |
| 12:08 | <drclue> | I've also ordered an extra dose of heart medication for when IE9 comes out , in the event that they actually shock me with a decent offering. Now that they want to be all friendly with cloud computing , they really don't have the luxury of continuing to use IE to keep the Internet impudent |
| 12:10 | <drclue> | Of course , since I boot to a Linux desktop , I'll have to take other folks word for how well IE9 does |
| 12:14 | <s0enke> | hsivonen, i missed a "not until" ;) |
| 12:17 | <drclue> | @s0enke That happens to me too sometimes, that is data going missing between the ball cap and the keyboard :) |
| 12:19 | <s0enke> | layer eight packet loss ;) |
| 12:19 | <drclue> | skull ->preferences->type ahead buffer |
| 12:20 | <hsivonen> | s0enke: well, even if your alternative suggestion were specced, there'd be no chance of it being in Firefox before 4.0 |
| 12:20 | <s0enke> | hsivonen, indeed. |
| 12:21 | <drclue> | At least they will have WebSockets in the bag |
| 12:22 | <drclue> | I think FF4 will probably test out pretty darn well for the most part |
| 12:23 | <drclue> | HTML5 is probably the first HTML version that everyone is trying to take seriously at the same time |
| 12:31 | <drclue> | Just thinking about this stuff sends me down memory lane Gopher , FIDONET , CHI 9 track, Altair , moon landings , rotary phones ,300 pound portable black and white TV's with a handy handle on top. |
| 12:33 | <erlehmann> | i wasn't born than yet. |
| 12:33 | <drclue> | Was you born before or after "I'm not a crook" |
| 12:33 | <hsivonen> | gopher died last week or so |
| 12:34 | <erlehmann> | drclue, for me its commodore pc 10, DOS, black-green screen, trying out all of the commands in the DOS manual. |
| 12:34 | <erlehmann> | i stopped after trying FORMAT, for obvious reasons |
| 12:34 | <drclue> | Ya , gopher died , but someone has nearly the whole gopher net on a hard drive |
| 12:34 | <erlehmann> | but hey, i was 10 or 11 yro |
| 12:35 | <erlehmann> | in the future, someone will have the whole internet of 2010 on a quantum holo storage medium the size of my fingernail |
| 12:35 | <drclue> | So you were probably around for those MFM full height 5 meg hard drives |
| 12:35 | <erlehmann> | my father told me the hard drive was a whopping 20 MB |
| 12:35 | <erlehmann> | in my first pc |
| 12:36 | <drclue> | I often contemplate what archaeologists will be able to find of us so many thousands of years after we are gone, since all our technologies are based upon materials with incredibly short life spans |
| 12:37 | <drclue> | My very first "personal" computer was an altair |
| 12:39 | <s0enke> | erlehmann, 40MB with diskdoubler� |
| 12:39 | <erlehmann> | wat |
| 12:39 | hsivonen | thought DiskDoubler was a Mac-only thing |
| 12:40 | <drclue> | What was that , "stacker"? Turned hard drives into door stops at an incredible rate |
| 12:40 | <s0enke> | hsivonen, I used it with dos 5.0 or so |
| 12:41 | <drclue> | Then there was DOS's daddy CPM |
| 12:41 | <drclue> | I remember them old Molecular computers , and dictaphone made some tanks too. |
| 12:42 | <drclue> | Ya remember them osborn's with the itty bitty screens? |
| 12:44 | <drclue> | Those were really some nerdy old days. I remember stripping 150 baud modems |
| 12:46 | <drclue> | I forget how many times I had to dive behind the teletype terminal to keep the night guards from catching me using "borrowed" computer time. |
| 12:47 | <erlehmann> | höhö höhöhö |
| 12:49 | <drclue> | What's really sorta weird is that computers have not really changed that much in all these decades. |
| 12:49 | <gsnedders> | erlehmann: Pff, the Habari cabal is by invitation only ;P |
| 12:52 | <erlehmann> | gsnedders, i'm going to pass all your secret tests of character, songoku-style ! |
| 12:54 | <drclue> | (: ǝɹǝɥ punoɹɐ ƃuıƃuɐɥ ɹnoʎ ɟı ɹǝʇɔɐɹɐɥɔ ou ǝʌɐɥ noʎ |
| 12:56 | <erlehmann> | i r-r-reject your assumption undt replace it mitt mein own |
| 12:56 | <erlehmann> | mister jones |
| 12:57 | <drclue> | It was just a myth anyways |
| 12:59 | <drclue> | Last night I looked upon the stair, and saw a man who was not there. |
| 12:59 | <drclue> | He was not there again today, how I wish that man would go away. |
| 13:49 | <erlehmann> | TabAtkins, can you refer me to an RDFa checker besides the N3 bookmarklet and pyRDFa ? |
| 13:52 | <karlushi> | oooh http://www.google.com/search?q=define:html5&hl=en |
| 13:55 | <karlushi> | oh it doesn't do only wikipedia |
| 13:55 | <karlushi> | oooh http://www.google.com/search?q=define:anarchy&hl=en |
| 13:55 | <karlushi> | wordnet also, when the word is defined at many places |
| 13:59 | <karlushi> | erlehmann, are there things which you specifically need for a rdfa checker that pyRDFa doesn't address? |
| 14:00 | <karlushi> | http://check.rdfa.info/ |
| 14:00 | <erlehmann> | karlushi, my mentor insists on something not being properly scoped and namespacing missing, but I don't see it. |
| 14:00 | <erlehmann> | the site in question is this http://gsoc2010.dieweltistgarnichtso.net/ |
| 14:01 | <karlushi> | the good channel for this question would be #swig (Semantic Web Interest Group), I guess. |
| 14:09 | <erlehmann> | karlushi, thanks. |
| 14:10 | <MikeSmith> | ah, what a rich means for thoughtful discussion twitter is |
| 14:10 | <MikeSmith> | twitter should have a "kneejerk reaction" button |
| 14:11 | <MikeSmith> | and a "kneejerk retweet reaction to kneejerk" reaction button |
| 14:23 | <karlushi> | MikeSmith, maybe a "rejerk" button |
| 14:27 | <MikeSmith> | karlushi: perfect |
| 17:27 | <TabAtkins> | annevk: No, I'm not going to be here at 2am my time. I'm here now. |
| 17:27 | <TabAtkins> | erlehmann: No, I can't. |
| 17:27 | <erlehmann> | TabAtkins, thanks. but i already got help from karlushi and the people in #swig. |
| 17:29 | <TabAtkins> | cool |
| 17:30 | <annevk> | but now it is over |
| 17:30 | <annevk> | maybe it will align next time |
| 17:30 | <TabAtkins> | ?_? |
| 17:57 | jgraham | starts humming The Smiths |
| 17:59 | <gsnedders> | jgraham: Liar. (Thankfully.) |
| 18:05 | <jgraham> | Sounds like an obscure b-side |
| 19:53 | <ap> | Hixie: perhaps HTML5 needs to specify that both WebSocket.url and WebSocket.URL should be supported now. I'm not sure if we'll want to drop support for what we shipped already, and if we're keeping it indefinitely, it can as well be specced |
| 20:01 | <zcorpan_> | ap: i doubt there's any content using URL |
| 20:02 | <ap> | zcorpan_: we can't go back and change it in Safari 5 though |
| 20:03 | <zcorpan_> | safari 5 shipped -75, which is a much bigger breaking change |
| 20:04 | <ap> | zcorpan_: that's a server side change, different department for many sites |
| 20:04 | <ap> | zcorpan_: and many servers already support both 75 and 76 |
| 20:05 | <zcorpan_> | i wouldn't want to support both URL and url in opera |
| 20:05 | <zcorpan_> | i'd rather just have URL if it's required for compat, but as i said, i highly doubt it is (or even will be in a year) |
| 20:07 | <ap> | as I said, I don't know if we'll need to support it, I'm not sure. I don't think such a nonsense change should have been made to the spec that has shipping implementations |
| 20:07 | <annevk> | Firefox will ship with just url |
| 20:08 | <ap> | awesome :-/ |
| 20:08 | <zcorpan_> | i argued for having URL everywhere, but in the end i gave up |
| 20:08 | <annevk> | you could support both for one more release or so and then drop it |
| 20:09 | <annevk> | yeah, I didn't agree with the no-URL camp either |
| 20:13 | <zcorpan_> | ap: there are more API changes compared to what shipped in safari 5: CloseEvent and the CLOSING state |
| 20:14 | <ap> | zcorpan_: true, although I'm not sure if adding these can practically break compatibility |
| 20:18 | <zcorpan_> | ap: EventSource.URL also changed to url |
| 20:18 | <ap> | zcorpan_: argh, I didn't know that |
| 20:27 | <AryehGregor> | How cryptic: http://blog.mozilla.com/rob-sayre/2010/06/21/networking/ |
| 22:09 | <Hixie> | ap: dude, just drop .URL, it's too early in the life of the API to worry about back compat |
| 22:09 | <Hixie> | ap: we're still discussing changing the entire protocol! |
| 22:09 | <ap> | Hixie: by the time we can ship the change, it might not be too early. and same for EventSource |
| 22:10 | <Hixie> | so ship it now |
| 22:10 | gsnedders | notes "by the time we can" implies not now |
| 22:11 | <Hixie> | ap: we're not adding both, that's just dumb. Either we should use .URL throughout or .url throughout (except Document), but either way you and mozilla need to decide which it is and stick to it. |
| 22:12 | <Hixie> | ap: you can ship a point update with this change if it's going to be that long until the next update |
| 22:12 | <ap> | Hixie: we shipped something that matched the draft spec, is there a good reason for it to change under us? this seems like a completely arbitrary change |
| 22:13 | <Hixie> | well first, drafts spec are subject to change at a whim, you know that. that's the risk of being on the cutting edge. Like I said, we're still considering a completely new protocol to replace the current websocket one. |
| 22:14 | <Hixie> | but the reason for this change was a discussion on public-webapps which had people from webkit, mozilla, and opera and which decided that we should consistently use lowercase attribute names so as to not make authors go crazy trying to work out what was lowercase and what was uppercase |
| 22:14 | <Hixie> | the minimum change was to change from URL to url |
| 22:14 | <Hixie> | going the other way would have required even more implementations to change |
| 22:16 | <ap> | Hixie: XMLHttpRequest is also a draft, let's maybe change it to XMLHTTPRequest for consistency? |
| 22:17 | <Hixie> | XMLHttpRequest isn't a draft, it was shipped in like 1999 |
| 22:17 | <ap> | Hixie: I think that there should be a cost/benefit analysis be applied, even to bleeding edge drafts |
| 22:17 | <Hixie> | there is |
| 22:17 | <Hixie> | and here the cost is MASSIVELY more on the side of being inconsistent |
| 22:17 | <ap> | there is no consistency in "url" casing on the Web, is there? |
| 22:17 | <jgraham> | s/on the web/in DOM APIs/ |
| 22:18 | <ap> | Hixie: what about document.URL? |
| 22:19 | <Hixie> | see the thread on public-webapps |
| 22:19 | <Hixie> | we discussed this to death |
| 22:19 | <Hixie> | I was on the side of going all uppercase, but that had a higher cost than going all lowercase except Document |
| 22:20 | <abarth> | Hixie: how would you like to handle implementation feedback on the parsing algorithm? |
| 22:20 | <ap> | so, evaluating this spec change. benefit: none, since there is still no consistency |
| 22:20 | <abarth> | Hixie: emails to public-html? bugs in the w3c bugzilla? |
| 22:20 | <ap> | cost: high, need to change shipping implementations |
| 22:21 | <Hixie> | abarth: bugs in bugzilla or e-mails to the whatwg list -- if you put bugs in bugzilla, mark them P1/critical so I'll deal with them at the same time as henri's |
| 22:21 | <Hixie> | ap: if you want to change the decision, convince opera and mozilla to go the other way. |
| 22:21 | <abarth> | Hixie: ok, will do. thanks |
| 22:22 | <ap> | Hixie: zcorpan_ and annevk seemed to prefer URL per the above discussion |
| 22:22 | <ap> | Hixie: that leaves Mozilla as the odd one out |
| 22:22 | <jgraham> | abarth: There is also a page on the whatwg wiki documenting parser issues |
| 22:23 | <jgraham> | If you could add things to that it would be good |
| 22:23 | <abarth> | jgraham: link? |
| 22:23 | <Hixie> | ap: i want uppercase too, but it's not a popularity decision. |
| 22:23 | <Hixie> | ap: it's a matter of what involved the least changes to implementations. |
| 22:23 | <jgraham> | abarth: http://wiki.whatwg.org/wiki/ParserIssues |
| 22:23 | <abarth> | jgraham: thxs |
| 22:23 | <ap> | Hixie: Firefox didn't ship EventSource or WebSocket |
| 22:24 | <jgraham> | ap: Having less inconsistency is still better |
| 22:24 | <Hixie> | ap: i'm not the one you have to convince |
| 22:25 | <ap> | jgraham: that's probably the part that was discussed to death on the mailing list (although for me, document.URL is the most familiar API, so being consistent with it is most important) |
| 22:25 | <Hixie> | (for me too) |
| 22:26 | <ap> | Hixie: who should I convince? |
| 22:26 | <Hixie> | reopen the thread on public-webapps and get the participants to agree to implement the opposite |
| 22:26 | <TabAtkins> | ap: Check out the thread for those who argued for lowercase, I suppose. |
| 22:28 | <gsnedders> | Hixie: http://www.hixie.ch/tests/adhoc/http/content-type/sniffing/ seems bogus |
| 22:28 | <gsnedders> | Hixie: 016 isn't that MIME type at all |
| 22:28 | <Hixie> | gsnedders: quite likely |
| 22:28 | <gsnedders> | Content-Type: application/x-httpd-php |
| 22:29 | <Hixie> | gsnedders: send me a mail with bugs, and i'll add them to the pile of e-mails about test bugs that i've been keeping. One day I'll have an intern or something I can get to fix them. |
| 22:32 | <Hixie> | abarth: the </p</div> thing was for compat with IE |
| 22:33 | <abarth> | Hixie: i see. some folks in the webkit community are worried about whether that will cause problems for mobile sites that are used to a webkit monoculture :( |
| 22:33 | <Hixie> | yup, it probably will. |
| 22:34 | <zcorpan_> | abarth: opera does the same thing as IE for < in tags. we've found that there are some pages that break if we follow mozilla, and other pages break if we follow ie |
| 22:34 | <zcorpan_> | abarth: however we've followed ie here for a long time and it doesn't come up very often |
| 22:42 | <abarth> | zcorpan_: i see |
| 22:42 | <abarth> | zcorpan_: maybe its a crapshoot either way |
| 22:43 | <abarth> | i'm all for aligning behavior so we don't have these problems in the future |
| 22:43 | <abarth> | i'm not sure how to estimate the risks in the mobile space |
| 22:44 | <abarth> | but there are also likely counterbalancing risks in the intranet that IE folks are worried about |
| 22:44 | <zcorpan_> | you could look at opera's market share on mobile :) |
| 22:44 | <zcorpan_> | and ie's |
| 22:44 | <abarth> | zcorpan_: my understanding is there's a bunch of mobile content that's authored specifically for webkit, but i could be wrong about that |
| 22:45 | <abarth> | we had a lot of random test cases in the test suite that relied on this quirk |
| 22:45 | <abarth> | including one from the official CSS test suite |
| 22:46 | <TabAtkins> | The clear solution is to break everyone's pages so the monoculture breaks up. |
| 22:48 | <erlehmann> | TabAtkins, that reminds me of an exchange two of my buddies hat. one was "my collegues broke the nightly build" and the response was "break them" |
| 22:49 | <TabAtkins> | Your buddies hats are rather eloquent for hats. |
| 22:50 | <erlehmann> | I use the neo keyboard you insensitive clod. |
| 22:51 | <TabAtkins> | neo keyboard? |
| 22:51 | <erlehmann> | T and D keys are right next to each other. |
| 22:51 | <erlehmann> | neo2 is a german layout optimized for speed. like dvorak, but for german and closely related languages. |
| 22:51 | <TabAtkins> | Ah, kk. |
| 22:51 | <erlehmann> | and it has all the funny special chars other germans never get right, like „these“ |
| 22:52 | <erlehmann> | But I laughed like a little girl, thank you, hats of. |
| 22:52 | <TabAtkins> | Man, I wish English used asymmetric quotes like that. |
| 22:52 | <erlehmann> | Incidentally, I have two hats right in this room. |
| 22:52 | TabAtkins | has no hats, and thus is sad. |
| 22:52 | <zcorpan_> | erlehmann: are they talking to each other? |
| 22:52 | <TabAtkins> | Next time I visit my parents I'm buying a proper cowboy hat, for reals this time. |
| 22:52 | TabAtkins | has to show off his Texan pride. |
| 22:53 | <erlehmann> | zcorpan_, i believe those hats were already dead and stuffed when my dad bought them. |
| 22:53 | zcorpan_ | wonders what he should play with next using websockets |
| 22:54 | <franksalim> | zcorpan_, what have you played with so far? |
| 22:54 | <zcorpan_> | chat room and multi-user painting |
| 22:55 | <TabAtkins> | Multi-user doom. |
| 22:55 | <TabAtkins> | Which means, I suppose, Quake. |
| 22:56 | <zcorpan_> | i want something i can hack in a few hours :) |
| 22:58 | <zcorpan_> | maybe i should find some single-player canvas game that i can easily implement multiplayer support |
| 22:58 | <Philip`> | Canvex! |
| 22:59 | <AryehGregor> | Is there any such thing as a single-player game where it's easy to implement multiplayer support? |
| 22:59 | <AryehGregor> | I'd think that would typically require a rewrite. |
| 22:59 | <TabAtkins> | The box-drawing game. Where you draw lines on a grid and score a point (and get to go again) whenever you finish all four sides of a box. |
| 22:59 | Philip` | wishes he could remember where he put his experimental multiplayer version |
| 23:01 | <Philip`> | TabAtkins: Turn-based games are bad demos, since latency doesn't matter and you could just do an XHR per turn |
| 23:01 | <Philip`> | Need something real-time to demonstrate the benefit of having a persistent socket |
| 23:01 | <roc> | pong |
| 23:01 | <TabAtkins> | Philip`: True. |
| 23:02 | <TabAtkins> | 2-player asteroids! |
| 23:02 | <TabAtkins> | Both ships up at once, explode on collision, winner is the one with the most points at the end of each round. |
| 23:02 | <Philip`> | Pong is probably too real-time - it'll look weird when the ball bounces even though it looked like it missed the opponent's bat |
| 23:02 | <Philip`> | and you can't do much decent lag compensation for Pong |
| 23:04 | <ment> | what about ssh client? that's a good game that could benefit from persistent connection where latency matters but not too much |
| 23:07 | <zcorpan_> | pong seems interesting to do |
| 23:07 | <Hixie> | zcorpan_: what would be really useful is a web page you can go to and give the client information (origin, ws: URL, etc) and have it tell you what the server is doing wrong |
| 23:07 | <Hixie> | zcorpan_: including checking for various obvious mistakes, like whether the challenge was constructed little-endian rather than big-endian, or whatnot. |
| 23:08 | Hixie | is writing a multiplayer websocket game here http://software.hixie.ch/fun/cuddlyworld/ |
| 23:09 | <Hixie> | (very early days yet) |
| 23:09 | <zcorpan_> | Hixie: i use opera's error console to tell what the server is doing wrong ;) |
| 23:09 | <Hixie> | (and ignore how slow it is, that's just because i have all the debugging checks enabled) |
| 23:10 | <Philip`> | Tron is more interesting than Pong and not much harder to implement |
| 23:10 | Philip` | wrote a basic Tron on his calculator but it was a really very slow calculator and only got about 0.5fps :-( |
| 23:11 | <zcorpan_> | Hixie: what user/pass should i use to play? |
| 23:11 | <Hixie> | any |
| 23:11 | <Hixie> | it creates an account when you join |
| 23:11 | <Hixie> | the password is for rejoining |
| 23:11 | <Philip`> | (then I wrote an emulator (in Perl and C) for a ~1MHz 8-bit processor and then wrote Tron for that and it was much faster) |
| 23:12 | <Hixie> | zcorpan_ a utility for testing servers would be good for checking that they handle all the various keys correctly --just testing in a browser isn't going to hit all the edge cases each time |
| 23:13 | <zcorpan_> | hmm, clearly we need a longer timeout before giving up in the opening handshake |
| 23:13 | <Hixie> | er no |
| 23:13 | <Hixie> | my server crashed |
| 23:13 | <Hixie> | for unrelated reasons |
| 23:13 | <Hixie> | restarting it |
| 23:16 | <Hixie> | well, it seems i have some bugs to figure out before i can demo this! |
| 23:16 | <Hixie> | anyway, bbiab |
| 23:23 | <AryehGregor> | I remember recently seeing statistics on how long things tend to stay in browsers' caches, but I can't seem to find them. Does anyone have any pointers? |
| 23:23 | <AryehGregor> | (My recollection is typically less than a day, but I want to double-check that.) |