| 00:57 | <Philip`> | http://html4all.org/pipermail/list_html4all.org/2007-September/000232.html - "How on earth can Wikis work if all and sundry can change what the previous author has written ?!" |
| 00:57 | <Philip`> | I'd have to agree that, in theory, wikis simply cannot work - the fact that they do work is almost enough to restore one's faith in humanity |
| 00:58 | <Philip`> | (Well, at least until they get flooded with wikispam, and then you return to a more realistic view of the world) |
| 08:20 | <Foone2> | hello. I found this in the wikipedia entry on future firefox versions: "More API's implemented from WHATWG specs, such as the ability to read files from file selection fields without the need to upload" |
| 08:20 | <Foone2> | looking at the WHATWG specs I can't find anything related to that though. could someone point me in the right direction? |
| 09:58 | <annevk> | Foone2, not yet specified |
| 09:58 | <Foone2> | oh. So what's firefox implementing from? |
| 10:03 | <annevk> | an idea |
| 10:04 | <Foone2> | well, has anyone written anything down about this idea then? |
| 10:05 | <annevk> | yeah, there's a bug report with them |
| 10:06 | <annevk> | it's mostly sketched |
| 10:07 | <annevk> | basically, you get an "input" / "change" event and then a new member becomes non-null if the user has selected any files |
| 10:07 | <annevk> | which exposes a list of selected files |
| 10:30 | gsnedders | sighs |
| 10:31 | gsnedders | can't ship the HTML 5 content type sniffing, as so many feeds are served as text/plain |
| 10:33 | <zcorpan> | gsnedders: are (m)any of those "text/plain; charset=X" where X is something other than "iso-8859-1" or "ISO-8859-1"? |
| 10:33 | <gsnedders> | zcorpan: I haven't yet looked at the specifics |
| 10:34 | zcorpan | is hoping that it will be possible to limit the sniffing so that "text/html; charset=utf-8" and "text/plain; charset=utf-8" are never sniffed |
| 10:34 | <gsnedders> | even those are only sniffed to see if they are text/plain or binary data |
| 10:35 | <zcorpan> | gsnedders: yeah, i know |
| 10:35 | <zcorpan> | but all text/html are sniffed for feeds |
| 10:40 | gsnedders | wonders whether to just ship it, and possibly pull it at a later date if we get too many bug reports |
| 10:41 | <annevk> | how many of these feeds are discovered using autodiscovery? |
| 10:42 | <gsnedders> | annevk: I don't have that many stats readily available |
| 10:42 | <gsnedders> | http://macnn.com/podcasts/macnn.rss — there's the first failure I've found just going through the demo feeds |
| 10:43 | <gsnedders> | served as "text/plain" |
| 10:44 | <gsnedders> | http://web.mac.com/turboderek/iPhoto/top-rides/index.rss — "application/octect-stream" (yuk) |
| 10:45 | gsnedders | wonders how to sniff application/octect-stream |
| 10:46 | <gsnedders> | http://youtube.com/rss/global/top_favorites.rss — text/plain |
| 11:04 | <annevk> | http://www.html5.jp/trans/whatwg_html5faq.html (translation in JP) |
| 11:12 | <MikeSmith> | annevk - can you please check and see if you can get to http://sideshowbarker.net ? |
| 11:12 | MikeSmith | is at the Kuala Lumpur airport and having some problems with DNS on the wireless LAN here |
| 11:13 | <zcorpan> | MikeSmith: doesn't seem to load for me |
| 11:15 | <MikeSmith> | zcorpan - OK, that's what I was afraid of |
| 11:15 | <MikeSmith> | thanks for checking |
| 11:16 | <annevk> | nope :( |
| 11:18 | <MikeSmith> | annevk - k |
| 11:20 | <MikeSmith> | unfortunately that host also runs my mail server too, and because of DNS problems here, I can't even get to the admin shell to restart it |
| 11:21 | <MikeSmith> | anyway, very little I can do about it now, and have to catch a plane in 20 minutes |
| 11:24 | <annevk> | you're complaining about not getting to your e-mail? that's weird, seems like a luxury to me :) |
| 11:28 | <MikeSmith> | yeah, guess I should appreciate the break |
| 11:30 | <zcorpan> | don't miss the plane :) |
| 11:34 | <MikeSmith> | hey, I've been wondering if anybody is aware of support for the inputmode attribute in any browsers (mobile or desktop or otherwise) |
| 11:35 | <MikeSmith> | I know Opera Mobile doesn't yet support it |
| 11:35 | <MikeSmith> | neither do the released versions of Openwave V6 or V7 |
| 11:35 | <MikeSmith> | though I'm told Openwave v7.2 does |
| 11:36 | <MikeSmith> | I'm thinking it is probably supported in Access NetFront but have not been able to try it yet |
| 11:37 | <MikeSmith> | there's a test case here: |
| 11:40 | <MikeSmith> | http://testfest.openmobilealliance.org/xHTML_3c/Input_Modes/TextInputModeDigits.xhtml |
| 11:41 | <MikeSmith> | but, um, though it's being server up with an XML/XHTML MIME type, it has the wrong doctype and is also missing the XHTML namespace |
| 11:42 | <MikeSmith> | so sort of makes it problematic to test with |
| 11:42 | <MikeSmith> | I do notice though that the Openwave browser displays it in spite of it brokenness |
| 11:43 | <MikeSmith> | which would seem to confirm that it's just using its HTML parser and ignoring the mime type |
| 11:44 | <MikeSmith> | anyway, gotta go |
| 13:04 | <annevk> | Firefox support for getElementsByClassName() seems also quite buggy: http://tc.labs.opera.com/apis/getElementsByClassName/ |
| 13:04 | <annevk> | Although I think most problems are related to the fact that they don't look for classes on the HTMLHtmlElement |
| 13:05 | <annevk> | (and for some reason <g:x> (with g bound to the SVG namespace) doesn't seem to implement SVGElement and therefore class="" doesn't seem to be supported there either) |
| 13:10 | <Dashiva> | We're still failing badly too, I see |
| 13:11 | <annevk> | oh, yes |
| 13:11 | <annevk> | alpha alpha alpha :p |
| 13:13 | <annevk> | Oh, another problem is that \f is not seen as whitespace in Firefox iirc |
| 13:17 | <om_sleep> | we have a getElementsByClassName patch for WebKit as well |
| 13:18 | <othermaciej> | not yet landed |
| 13:18 | <othermaciej> | I added a link to the test cases |
| 13:18 | <othermaciej> | http://bugs.webkit.org/show_bug.cgi?id=14955 |
| 13:19 | <annevk> | cool |
| 13:24 | <annevk> | seems your impl doesn't consider \f either |
| 13:25 | annevk | wonders why HTML5 has \f as whitespace char |
| 13:26 | <othermaciej> | well, it's not even code reviewed yet. I'm not sure why \f needs to be treated as whitespace in the string parameter though |
| 13:26 | <othermaciej> | I'm not sure why it's necessary to consider anything but space, really |
| 13:26 | <othermaciej> | it's not like people randomly put form feeds in their scripts |
| 13:28 | <annevk> | i guess it's for consistency |
| 13:28 | <annevk> | and it probably works better if you do ele.getElementsByClassName(ele.className) |
| 13:29 | <othermaciej> | fair enough |
| 13:35 | <hsivonen> | http://james.html5.org/cgi-bin/tables/table_inspector.py?uri=http%3A%2F%2Fhsivonen.iki.fi%2Fthesis%2Fhtml5-conformance-checker.html&algorithm=html5 |
| 13:35 | <hsivonen> | the abstract cell is associated with the author label |
| 13:35 | <hsivonen> | I wonder if there's a way to implicitly disassociate |
| 13:36 | hsivonen | tries other modes |
| 13:36 | <hsivonen> | Smart Colspan is worse |
| 13:37 | annevk | wonders if <table> is appropriate for that data |
| 13:38 | <hsivonen> | annevk: clearly, it is at least appropriate for everything but the abstract |
| 13:38 | <annevk> | the HTML4 algorithm is a lot worse btw |
| 13:39 | <hsivonen> | annevk: and since there's a row below the abstract, it needs to be one table for the columns to be held together |
| 13:39 | <hsivonen> | annevk: besides, the LaTeX and Word templates use tables, so it would be silly to have to do something more complex in HTML |
| 13:40 | <hsivonen> | however, one could argue that I should have headers='' on the abstract cell |
| 13:41 | <annevk> | it's not clear whether headers= is authorative or augmentative |
| 13:41 | <hsivonen> | also, one might argue that for this case, the HTML5 algorithm is Good Enough and it is obvious to anyone that Author is not the right header for the abstract if you start listening the abstract |
| 13:42 | <annevk> | Why doesn't the abstract simply have a <th> as well? (this is the wrong question to ask, but I'm curious) |
| 13:43 | <hsivonen> | annevk: because it wouldn't produce the exact layout required |
| 13:43 | <hsivonen> | annevk: most of the layout carefully emulates a known-good traditional LaTeX template |
| 13:44 | <hsivonen> | (see comments in the CSS file) |
| 13:48 | <annevk> | maybe smart colspan should only look at headers which span as much or more headers than the cell they might apply to |
| 13:48 | <annevk> | s/headers than the cell/cells than the data cell/ |
| 13:51 | <annevk> | smartcolspan doesn't look to the left otherwise it seems the same as HTML4 |
| 13:51 | <annevk> | there also seems to be a problem with the second table |
| 13:51 | <annevk> | but maybe the tool only handles one table correctly |
| 13:55 | <hsivonen> | annevk: the second table has the exact sama structure |
| 13:55 | <hsivonen> | if a cell spans a column that doesn't have a header cell above the current cell, then the current cell has no column header at all |
| 13:56 | <hsivonen> | analogously for rows |
| 13:56 | <hsivonen> | I wonder if applying that rule would break anything |
| 14:00 | <annevk> | shouldn't you look further up as well? |
| 14:26 | <hsivonen> | annevk: above as in anywhere above |
| 14:26 | <hsivonen> | annevk: I didn't mean only immediately above |
| 14:44 | <hsivonen> | "currently I am writing from a mobile phone and for mobile devices the alt-attribute is more than essential." Huh? |
| 14:45 | <Ducki> | OK! |
| 14:45 | <takkaria> | if you want to save being charged ridiculous money, then I guess it is |
| 14:45 | <webben> | hsivonen: I imagine to speed up web access people will often disable images. |
| 14:46 | <webben> | takkaria: It's not just money, it's also speed. Mobile access is kinda slow. |
| 14:46 | <takkaria> | true enough |
| 14:46 | hsivonen | has a flatrate data plan |
| 14:46 | <doublec> | i disable images usually when browsing from a phone |
| 14:47 | <doublec> | no flatrate data plans in nz :( |
| 14:47 | <hsivonen> | today, I could get a mobile 1M downlink for less money than I pay for an ADLS 1M downlink |
| 14:48 | <doublec> | nice |
| 14:48 | <hsivonen> | I used to disable images occasionally, though, back when I had a traffic quota for GPRS |
| 14:48 | <hsivonen> | but back then I wouldn't have described alt as more than essential |
| 14:51 | <hsivonen> | competition and laws that guarantee unlocked carrier-neutral phones are good |
| 14:52 | <webben> | hsivonen: Maybe that simply reflects different browsing patterns between you and the author of the quote. (i.e. maybe the sites you were browsing didn't use images for anything important, or maybe they use alt so that you wouldn't necessarily notice) |
| 14:53 | <takkaria> | hsivonen: wish UK had those :( |
| 14:54 | <hsivonen> | webben: for me, when browsing using a mobile, the most essential image use case is maps (which don't have reasonable alts) |
| 14:54 | <hsivonen> | webben: textual directions are typically provided in page content |
| 14:59 | Philip` | wonders if Hixie has any data about <script language> values |
| 17:12 | <webben> | OT: does anyone know if there's a (unofficial or whatever) index to CSS3 properties in the current CSS3 drafts comparable to http://www.w3.org/TR/CSS21/propidx.html ? |
| 17:12 | <annevk> | for all CSS3 properties? |
| 17:12 | <webben> | yeah |
| 17:12 | <annevk> | I don't think so |
| 17:13 | <zcorpan> | Hixie: why did html5 change the tokenization rules for "<p<p>" before? |
| 17:13 | <webben> | ah well, thanks :) |
| 17:13 | <annevk> | should be pretty trivial to write a script that goes through a hardcoded list of drafts and then extracts them though |
| 17:13 | <annevk> | zcorpan, it was based on Firefox |
| 17:13 | <webben> | I guess. |
| 17:14 | <zcorpan> | annevk: that wasn't my question :) |
| 17:15 | <annevk> | hmm, change from what to what exactly? |
| 17:16 | <zcorpan> | from firefox rules to ie rules |
| 17:16 | <zcorpan> | two elements "p", "p" to one element "p<p" |
| 17:17 | <zcorpan> | (or well, start tag tokens) |
| 17:22 | <annevk> | more compat with IE |
| 17:22 | <annevk> | (and Opera) |
| 17:23 | <zcorpan> | but which approach is more compatible with existing web pages? |
| 17:26 | <annevk> | i think it doesn't matter |
| 19:00 | <zcorpan> | try this. check the "XHTML" button in http://www.google.com/preferences |
| 19:00 | <zcorpan> | then load the front page |
| 19:02 | <zcorpan> | hmm, that option is only available if you use opera it seems |
| 19:02 | <Philip`> | Is it fair to call them bozos if they're not actually generating XML incorrectly, but are just transmitting HTML incorrectly? |
| 19:04 | <Philip`> | The "PDA" option just sends the normal page too |
| 19:05 | <Philip`> | so it looks like they've forgotten to do the bit where it actually sends different content depending on your choice |
| 19:05 | <zcorpan> | yeah |
| 19:06 | <Philip`> | I vaguely remember trying the XHTML option before and getting some odd minimalist version of the page, like it was designed for mobile devices |
| 20:40 | Philip` | wonders if it's best to just clamp shadowBlur when someone sets it really high |
| 20:44 | gsnedders | wonders whether he should be coding, and watching TV, with laptop on lap :P |
| 20:47 | <Philip`> | Firefox 3 doesn't sniff http://youtube.com/rss/global/top_favorites.rss |
| 20:49 | <gsnedders> | Fx2, Saf3 do |
| 20:50 | <Philip`> | IE7 does |
| 20:58 | <gsnedders> | YouTube is the largest site I could find that did it |
| 20:59 | gsnedders | sighs |
| 21:00 | <Philip`> | You could email them and ask them to fix it, since the next largest site with that problem is probably much smaller than YouTube and could be more easily ignored :-) |
| 21:01 | Philip` | can't actually work out how to reach YouTube's RSS feed page, without reading the source code and following the <link rel=alternate> |
| 21:01 | <annevk> | the idea is that the browser has feed autodiscovery implemented and offers the user a download link of some sorts |
| 21:04 | <Philip`> | That idea doesn't appear to work so well in practice |
| 21:05 | <annevk> | dunno, it has worked for a number of people (enough even for HTML5 to include rel=feed |
| 21:05 | <annevk> | started here: http://diveintomark.org/archives/2002/05/30/rss_autodiscovery |
| 21:07 | <Philip`> | The link is just <link rel="alternate" title="YouTube - [RSS]" href="/rssls"> and points at an HTML page which has un-marked-up <a> links to the feeds (and also a <link rel="alternate" title="YouTube - [RSS]" href="/rssls"> pointing at itself) |
| 21:08 | <annevk> | oh |
| 21:09 | <annevk> | and then some people think the bigger sites are more likely to get it right |
| 21:10 | <Philip`> | I guess the type="application/atom+xml" is necessary for autodiscovery in browsers? |
| 21:10 | <zcorpan> | yes |
| 21:11 | <annevk> | or rel=feed |
| 21:11 | <zcorpan> | is that implemented? |
| 21:11 | <annevk> | not in Opera |
| 21:12 | <annevk> | it's implemented in Firefox iirc |
| 21:16 | <gavin> | Philip`: I asked one of our RSS gurus about that feed, he didn't know why the behavior changed between Firefox 2 and current trunk builds |
| 21:16 | <gavin> | I filed https://bugzilla.mozilla.org/show_bug.cgi?id=395533 |
| 21:21 | <Philip`> | gavin: Okay - thanks! |
| 21:35 | <gsnedders> | Philip`: I've already emailed YouTube |
| 22:10 | <zcorpan> | Hixie: when serializing xml with innerHTML, may CDATASection nodes be output as data instead of cdata sections? |
| 22:11 | <zcorpan> | i.e., "ismorphic" in the canonical xml sense or in the dom sense? |
| 22:13 | <Hixie> | the text/plain sniffing behaviour presumably changed for security reasons |
| 22:14 | <Hixie> | zcorpan: good question |
| 22:17 | <zcorpan> | it would be nice if it were allowed because you can use c14n for test cases and you wouldn't have to worry about ]]> in implementations |
| 22:18 | <zcorpan> | though then ]]> in a cdata section would have to not raise an exception |
| 22:19 | <zcorpan> | hmm, perhaps you can't really use c14n for test cases anyway... |
| 22:20 | <zcorpan> | no, should be possible :) |
| 22:21 | <gsnedders> | Hixie: get my PM? |
| 22:23 | <gavin> | the text/plain sniffing issue that Philip` wasn't changed for security reasons, it's a regression from an unrelated change made to better support plugin content sent as text/plain |
| 22:23 | <gavin> | (https://bugzilla.mozilla.org/show_bug.cgi?id=395533#c1) |
| 22:26 | <Hixie> | gsnedders: yeah |
| 22:26 | <Hixie> | gavin: :-( |
| 22:26 | <zcorpan> | except perhaps for one thing. c14n removes uncessessary namespace declarations. it's unclear to me if they may be omitted when using innerHTML |
| 22:27 | <gsnedders> | http://php5.simplepie.org/trunk/demo/?feed=http%3A%2F%2Fyoutube.com%2Frss%2Fglobal%2Ftop_favorites.rss now fails |
| 22:27 | gsnedders | waits for a bug report |
| 22:35 | zcorpan | files a bug report for gsnedders |
| 22:35 | <zcorpan> | ;) |
| 22:35 | <gsnedders> | :) |
| 22:42 | <annevk> | Hixie, zcorpan had the idea of maybe whitelisting text/{html|plain};charset=utf-8 from sniffing |
| 22:42 | <annevk> | (if not much content is labeled as such) |
| 22:42 | <gsnedders> | annevk: it currently isn't sniffed, though |
| 22:43 | <gsnedders> | annevk: his point was more to avoid sniffing too much |
| 22:44 | annevk | thought all text/html was sniffed |
| 22:45 | <zcorpan> | "Let official type be the type given by the Content-Type metadata for the resource (in lowercase, ignoring any parameters)." |
| 22:45 | <gsnedders> | oh, all text/html is. I didn't hear zcorpan say anything about that, I don't think |
| 22:46 | <Hixie> | i'm all for restricting the sniffing, but you'll have to convince the UAs first |
| 22:46 | <gsnedders> | Hixie: SimplePie 1.1 will ship with the HTML 5 content-type sniffing |
| 22:46 | <zcorpan> | i need data about how much it would break before trying to convince UAs :) |
| 22:47 | <gsnedders> | (but there again, we currently totally ignore content-type, so anything is an improvement) |
| 22:49 | <Hixie> | zcorpan: remind me next week and i'll look into it |
| 22:50 | <zcorpan> | Hixie: ok |
| 22:58 | <Philip`> | Can an HTML5 document ever have more than one head element? |
| 22:59 | <zcorpan> | not by just parsing (otherwise there's a bug in the spec) |
| 23:03 | <zcorpan> | hmm. using c14n might be problematic anyway for HTMLDocument.innerHTML, since c14n requires a validating xml processor |
| 23:07 | <Philip`> | zcorpan: Okay, thanks |
| 23:37 | <Hixie> | Philip`: it can via DOM and via XML, but then it can have almost anything that way |