| 00:30 | <alyoshka> | I think we have a problem with the new <details> |
| 00:30 | <alyoshka> | are we allowed to have nested <details>? |
| 00:31 | <alyoshka> | here's a short description of the problem I posted on the html5doctor blog: http://html5doctor.com/september-html5-spec-changes/comment-page-1/#comment-1028 |
| 00:34 | <Hixie> | alyoshka: yeah nesting <details> requires a browser that supports the new parser |
| 00:35 | <Hixie> | alyoshka: but nesting <details> is pretty crazy |
| 00:35 | <Hixie> | alyoshka: so that's not really a problem |
| 00:36 | <alyoshka> | well, I actually have a website where I nest <details>, but I guess the site just has too many details then (pun intended) |
| 00:36 | <alyoshka> | it's a rare case, but I've run into it |
| 00:36 | <Hixie> | i don't think you're using <Details> correctly then |
| 00:37 | <Hixie> | i don't think i've ever seen a disclosure triangle widget that had another one inside it |
| 00:37 | <Hixie> | that's really bad ui |
| 00:37 | <alyoshka> | in a way |
| 00:38 | <alyoshka> | the part that uses it is for admins |
| 00:38 | <alyoshka> | it contains the details for a record that may be useful to the admin |
| 00:39 | <Hixie> | fair enough |
| 00:39 | <Hixie> | well, the spec allows it |
| 00:39 | <alyoshka> | and nested are more technical details that only the developers need |
| 00:39 | <Hixie> | and it'll work once the parser is more widely deployed |
| 00:39 | <Hixie> | but it will indeed be problematic for now |
| 00:39 | <Hixie> | generally speaking i'm a bit scared of how much people are eager to use html5 |
| 00:39 | <Hixie> | i'd rather people waited til CR |
| 00:39 | <Hixie> | so we were sure the spec was stable |
| 00:40 | <alyoshka> | so, I guess the solution for now is just to avoid nested <details> (even in the rare cases it might make some sense) |
| 00:41 | <alyoshka> | yeah, <details> is the only major thing I use that's not supported by default in browsers |
| 00:42 | <alyoshka> | we used to do the same thing with DHTML anyways, now there's a (semi) standard way to do it, so why not (as long as you keep up with the spec)? |
| 00:42 | <Hixie> | because people won't do the parenthetical bit |
| 00:42 | <Hixie> | and we end up forced into decisions based on having to support the "legacy" content |
| 00:43 | <alyoshka> | I agree, I don't recommend anyone using new elements right now because of the same reason |
| 00:44 | <alyoshka> | but I among other people who do keep up with the spec use it |
| 00:44 | <alyoshka> | for personal things and testing the spec |
| 00:45 | <alyoshka> | there's only one site that I use <details> on, and maybe three that use new sectioning content |
| 00:45 | <alyoshka> | *elements |
| 00:45 | <alyoshka> | not content |
| 00:46 | <alyoshka> | but the bright side to it is that people are enthusiastic about the new spec. must mean we're doing something right |
| 00:46 | <Hixie> | i hope so :-) |
| 00:47 | <alyoshka> | do you know if there are any other elements that browsers might vomit from <dd>? |
| 00:52 | <Hixie> | alyoshka: <dd> and <dt> as far as i'm aware are the only ones |
| 00:56 | <alyoshka> | except when inside a <dl> (just tested, so definition lists should be safe) |
| 01:00 | <Hixie> | how so? |
| 01:01 | <Hixie> | i don't understand what you mean |
| 01:02 | <alyoshka> | I mean <dd><dl><dt>term</dt><dd>definition</dd></dl></dd> seemed to work |
| 01:03 | <Hixie> | ah, yes |
| 01:04 | <Hixie> | you can substitute various elements for <dl> in that |
| 01:04 | <Hixie> | in most browsers, for table, <ol><li> would also "protect" the nested <dd> |
| 01:04 | <Hixie> | in html5 browsers, all elements described as "special" except <div>, <address>, and another that i forget off hand are "safe" |
| 01:12 | <alyoshka> | If I understood the spec correctly, if a <details> element contains no <dd> element, it is to be completely ignored, right? |
| 01:12 | <Hixie> | i don't think it says to ignore it per se |
| 01:13 | <Hixie> | but yeah it's not valid |
| 01:15 | <alyoshka> | I'm just wondering how a browser should behave if it comes accross <details><dt>summary</dt><p>content</p></details> or <details><p>content</p></details> |
| 01:15 | alyoshka | goes to reread the spec |
| 01:17 | <boblet_> | Hixie: I think the interest in using HTML5 is good—despite casualties real-world use is catching a lot of the edge cases |
| 01:17 | <Hixie> | spec http://www.whatwg.org/specs/web-apps/current-work/#the-details-element-0 |
| 01:18 | <alyoshka> | "If there is no child dd element, then there are no details." |
| 01:18 | <alyoshka> | I would interpret that as not rendering anything there, but would that be correct? |
| 01:18 | <Hixie> | alyoshka: the rendering section is what matters as far as rendering goes |
| 01:19 | <alyoshka> | I'm doing it for this: http://code.google.com/p/fiks-html5/ |
| 01:20 | <alyoshka> | although I wouldn't code invalid <details> elements, I just want to make my js handle all the possibilities |
| 01:21 | <Hixie> | yeah |
| 01:21 | <Hixie> | i gotta go afk for a bit, back in a few hours |
| 01:21 | <Hixie> | let me know if the rendering section isn't clear enough when i get back |
| 01:23 | <alyoshka> | I won't be here in a few hours, wrapping it up for the day in about half an hour, but yeah, the rendering doesn't seem to describe that case |
| 01:25 | <alyoshka> | and before rendering, it'd help to know what the DOM should look like in that case too |
| 01:31 | <boblet> | alyoshka: apart from new element support in IE, what other major browser support issues are there? |
| 01:32 | <boblet> | (re: fiks-html5.js) |
| 01:33 | <boblet> | just details right? (plus some default styling) |
| 01:37 | <alyoshka> | boblet: yeah, so far it's new elements, <details>, and default styling |
| 01:38 | <alyoshka> | there's a lot in web forms 2, but my project is aiming for all except web forms 2 |
| 01:38 | <alyoshka> | I believe WF2 belongs in a separate module |
| 01:52 | <Hixie> | alyoshka: if it doesn't describe the case, it might just mean there's nothing to describe :-) |
| 01:52 | <Hixie> | alyoshka: i notice it doesn't mention <dd> at al |
| 01:52 | <Hixie> | all |
| 01:53 | <alyoshka> | Hixie: which would mean that technically there's nothing there so it wouldn't render any details? Or would it? |
| 01:54 | <Hixie> | the rendering section says that <details> renders its first <dt>, and hides everything else when closed, and shows it all when open, iirc |
| 01:54 | <Hixie> | so the <dd> doesn't matter |
| 01:56 | <alyoshka> | so if there is no explicit <dd> it would still work by wrapping the rest in a dynamically created <dd>? |
| 01:57 | <alyoshka> | I'm just working with the DOM too, so I need to know how that looks too |
| 01:57 | <Hixie> | what i'm saying is that the <dd> is irrelevant |
| 01:58 | <alyoshka> | "If there is no child dd element, then there are no details." <- would that affect the DOM though? |
| 01:58 | <Hixie> | <details> <dt> A </dt> B </details> -- B is shown or hidden based on whether the details has an open attribute or not, A is always shown |
| 01:58 | <alyoshka> | ok, I guess that works |
| 01:58 | <alyoshka> | but nothing to hook into really if there is no <dd> |
| 01:59 | <alyoshka> | for backwards compatibility |
| 02:00 | <alyoshka> | that would obviously be the authors' problem though |
| 02:01 | <Hixie> | yeah |
| 02:01 | <Hixie> | maybe it should be changed |
| 02:01 | <Hixie> | i dunno |
| 02:01 | <alyoshka> | I think it should |
| 02:01 | <alyoshka> | so that the two sections would be consistent |
| 02:02 | <alyoshka> | I gotta run now though |
| 02:02 | <alyoshka> | bye |
| 02:16 | <MikeSmith> | Hixie: thanks for the sotd change -- the wording is fine by me, better than what I suggested |
| 02:23 | <MikeSmith> | I often use too many words where fewer will do |
| 02:23 | <MikeSmith> | IanJ is also powerful good at stating things succinctly in writing |
| 02:23 | <MikeSmith> | you guys should collaborate more |
| 03:27 | <karlcow> | [12:37] <MikeSmith> and karlcow does too a little |
| 03:27 | <karlcow> | I speak Mooish! |
| 04:06 | <heycam> | so what are 'dc' and 'ds'? |
| 04:16 | <othermaciej> | reserved for future use I guess? |
| 04:17 | <othermaciej> | but I'm not sure reserving them in the parsing rules is either necessary or helpful |
| 04:17 | <othermaciej> | <ds> might be for "stage direction" in a future resurrected <dialog> |
| 04:19 | <heycam> | haha |
| 04:19 | <heycam> | (that is a joke right?) |
| 04:27 | <othermaciej> | heycam: no -- it would be the way to include either literal stage directions or things like IRC lave/join notifications or /me actions or out-of-band timestamps from AIM logs or the like |
| 04:27 | <heycam> | huh, ok, |
| 04:27 | <othermaciej> | heycam: whether all that put together would be a good idea, I don't know |
| 04:28 | <heycam> | <-- heycam has joined #whatwg, stage left. |
| 04:38 | <tantek> | Hixie, you said "i don't think i've ever seen a disclosure triangle widget that had another one inside it" - nested folders in any Finder list view, since the 1990s. |
| 04:38 | <tantek> | and any ftp/gopher/web interface that has sought to imitate that UI for browsing a hierarchical system of resources/files/objects etc |
| 04:46 | <othermaciej> | tantek: the outline view is kind of a special case - it's something that should be supported by <datagrid> whenever that comes back |
| 05:00 | <tantek> | othermaciej - people will use <details> for that because they can. |
| 05:39 | <Hixie> | anyone remember who did that research recently looking at various sites that marked up conversations? |
| 06:03 | <heycam> | Hixie, it was sicking iirc |
| 06:04 | <Hixie> | yeah that matches my memory too, but i couldn't find any e-mails from him about that |
| 06:04 | <Hixie> | what is last month maybe? |
| 06:04 | <Hixie> | i thought it was recently |
| 06:04 | <heycam> | yeah i thought it was only a week ago or so |
| 06:05 | <Hixie> | i looked in public-html and whatwg and couldn't find it |
| 06:05 | <Hixie> | do you remember what he had searched for? |
| 06:05 | <heycam> | it was some shakespeare |
| 06:06 | <heycam> | ah here it is, on whatwg |
| 06:06 | <heycam> | Date: Wed, 2 Sep 2009 22:33:01 -0300 |
| 06:06 | <Hixie> | aah, found it also |
| 06:06 | <heycam> | it'd be nice if the mailing list software you're using inserted Archived-At headers :) |
| 06:06 | <Hixie> | the subject line threw me off |
| 06:07 | <Hixie> | it would be nice if the mailing list software we used didn't suck like an industrial vacuum |
| 06:08 | <Hixie> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022576.html |
| 06:09 | <othermaciej> | I love how o:p makes an appearance |
| 06:16 | <tantek> | opp = other people's paragraphs? |
| 06:17 | <othermaciej> | the second p - it stands for proprietary |
| 06:18 | <derferman> | so, I was hoping to looking into the notification standard that google has proposed |
| 06:18 | <derferman> | where would I find it? |
| 06:19 | <tantek> | dererman *the* notification standard? |
| 06:19 | <tantek> | do you mean PubSubHubbub? |
| 06:20 | <tantek> | or Google Wave? |
| 07:13 | <derferman> | neither |
| 07:14 | <derferman> | One of the lead chrome product managers was at Berkeley the other day |
| 07:18 | <derferman> | and mentioned google had proposed a javascript api for notifications |
| 07:33 | <tantek> | Webhooks |
| 07:33 | <tantek> | http://blog.webhooks.org/ |
| 07:33 | <tantek> | used by Google Wave and others |
| 09:09 | <til> | has anyone got custom attributes working in IE8? |
| 09:09 | <til> | elm.setAttribute('data-propname', 'data-propname') works in every browser (incl. IE7), but not 8 |
| 09:36 | <annevk2> | Hixie, "new language that was no" should be "... was not" |
| 09:37 | <Hixie> | hx |
| 09:37 | <Hixie> | thanks even |
| 09:37 | <annevk2> | Hixie, also, it is "DOM Level 2 Core" and "DOM Level 2 HTML" |
| 09:37 | <annevk2> | not DOM HTML Level 2 |
| 09:38 | <Hixie> | will fix |
| 09:38 | <annevk2> | "all the Level 3 drafts were published" I think they were all published, just not finished (i.e. published as Note) |
| 09:39 | <Hixie> | changed to completed |
| 09:40 | <annevk2> | it reads quite objective btw; nice job |
| 09:41 | <Hixie> | i tried |
| 09:41 | <Hixie> | :-) |
| 09:45 | <Steve^> | I read that article is being considered for a renaming. I thought section was causing the confusion? |
| 09:46 | <annevk2> | Hixie, btw, the Web Storage or Web Database or maybe both still use DOM attribute in their boilerplate |
| 09:47 | <Hixie> | Steve^: things are always being considered, but i think currently nothing is really going to change on that front |
| 09:47 | <Hixie> | annevk2: thanks, forgot about those files |
| 09:48 | <Steve^> | I think the names are fine and when outliners are added to web dev tools, people should understand better |
| 09:52 | <Hixie> | hsivonen: "If, after doing so, the insertion mode is still "in foreign content", but there is no element in scope that has a namespace other than the HTML namespace, switch the insertion mode to the secondary insertion mode." |
| 09:52 | <Hixie> | hsivonen: is that text well-defined enough in your opinion? If it needs tightening up, what do you suggest it should be tightened to? |
| 09:52 | <mookid> | hello internet friends |
| 09:53 | <mookid> | I have a request |
| 09:53 | <Hixie> | i guess it's well-defined |
| 09:54 | heycam | wonders if mookid and karlcow are related =) |
| 09:54 | <mookid> | can you please change the accept attribute on file input fields |
| 09:54 | <mookid> | so it's a content-type attribute instead |
| 09:55 | <mookid> | using accept for that is arse-about-face |
| 09:55 | <Hixie> | it's consistent with <form> |
| 09:55 | <Hixie> | from html4 |
| 09:55 | <mookid> | change it it's wrong |
| 09:55 | <mookid> | :) |
| 09:56 | <mookid> | Accept is for client preferences for responses |
| 09:57 | <annevk2> | we still have that attribute? |
| 09:57 | <Hixie> | we can't change it, it's from html4 |
| 09:57 | annevk2 | thought it was useless |
| 09:57 | <mookid> | so you can't change anything from html4? |
| 09:57 | <Hixie> | annevk2: nah it's useful for saying "i just want images" |
| 09:57 | <annevk2> | ah right |
| 09:58 | <Hixie> | mookid: the rule isn't quite so black and white, but in this case, it is indeed something we can't change |
| 09:58 | <annevk2> | though <form> does not have it (well it has accept-charset) |
| 09:58 | <mookid> | yeah erm |
| 09:58 | <mookid> | that doesn't make sense |
| 09:58 | <mookid> | circular justification |
| 09:59 | <Hixie> | annevk2: <form accept> is in html4 |
| 09:59 | <Hixie> | woo, below 100 XXX markers too! |
| 09:59 | <Hixie> | and still below 100 e-mails! |
| 09:59 | <annevk2> | Hixie, but not in HTML5 :) |
| 10:00 | <mookid> | yeah I would drop it |
| 10:00 | <mookid> | it's stupidly named |
| 10:00 | <Hixie> | annevk2: oh? did we move it off <form>? interesting |
| 10:00 | <annevk2> | but HTML4 has it on <input> |
| 10:00 | <annevk2> | and so does HTML5 |
| 10:00 | <Hixie> | oh ok |
| 10:00 | <mookid> | hmm |
| 10:00 | <annevk2> | doesn't seem like something we want to change indeed |
| 10:00 | <mookid> | why? |
| 10:01 | <Hixie> | mookid: your interest in http content negotiation is a lost cause here, i fear |
| 10:01 | <Lachy> | we need to keep it on input, on the condition that browsers actually implement it and do something useful with it. I'm not aware of any browser that does, though |
| 10:01 | <mookid> | Hixie: this isn't content-negotiation actually |
| 10:01 | <annevk2> | changing the name of something has cost and marginal benefit |
| 10:01 | <mookid> | this is just horrendously named attributes |
| 10:01 | <mookid> | that are confusing |
| 10:01 | <Hixie> | mookid: html has lots of horrendously named things |
| 10:01 | <mookid> | you've called the content-type control.. Accept |
| 10:01 | <Hixie> | live with it :-) |
| 10:02 | <mookid> | which is completely WRONG |
| 10:02 | <Hixie> | "accept" makes plenty of sense |
| 10:02 | <Hixie> | it's what the server wants to accept |
| 10:02 | <mookid> | no it doesn't. |
| 10:02 | <takkaria> | ps fear the axiomatic proof |
| 10:02 | <Lachy> | mookid, it makes sense because it says which content types are accepted by the file upload control |
| 10:02 | <krijnh> | http://twitter.com/ppk/statuses/4075175585 |
| 10:02 | <virtuelv> | I really, really miss the index of elements from the html 4 spec |
| 10:02 | <mookid> | yes I guessed that was the reason |
| 10:02 | <krijnh> | He's at LC already! :( |
| 10:03 | <annevk2> | krijnh, haha |
| 10:03 | <Lachy> | haha |
| 10:03 | <mookid> | in HTTP - Accept has a specific meaning in a request; it means the media types the client wants to recieve back in the response |
| 10:03 | <Hixie> | virtuelv: if you can write the script that generates the index for html5, i'll put it in immediately. :-) |
| 10:03 | <annevk2> | krijnh, I have the feeling it's not going away with three implementations, but I look forward to his pile of shit rant and tests he uses to back it up :) |
| 10:03 | <mookid> | what that attribute is actually controlling is the content-type header |
| 10:03 | <Lachy> | has no-one told PPK that we're pretty much stuck with the overall design of drag and drop for compatibility reasons? |
| 10:03 | <Hixie> | virtuelv: http://www.whatwg.org/specs/web-apps/current-work/#index |
| 10:03 | <mookid> | so it should be called content-type |
| 10:03 | <krijnh> | annevk2: yeah, me too |
| 10:04 | <mookid> | and not accept |
| 10:04 | <annevk2> | dude, you're over a decade too late with that name change |
| 10:04 | <mookid> | .... |
| 10:04 | <mookid> | so you cna't make changes? |
| 10:04 | <Hixie> | mookid: "content-type" is the type, it's not what it is |
| 10:04 | <Hixie> | mookid: it'd be like calling the min="" attribute "integer" |
| 10:05 | <Hixie> | mookid: and no, it's too late to change this |
| 10:05 | <virtuelv> | the whatwg section of the spec is cruel to my laptop |
| 10:05 | <mookid> | in the run up to 2032? |
| 10:05 | <mookid> | -_- |
| 10:05 | <mookid> | yeah ok. |
| 10:07 | <Lachy> | virtuelv, if you block the scripts, it helps the spec load faster |
| 10:07 | <Hixie> | mookid: actually the run up is to next month |
| 10:07 | <Hixie> | the plan is to reach LC in october 2009 |
| 10:07 | <Hixie> | and we seem to be on track! http://www.whatwg.org/issues/data.html |
| 10:08 | <Lachy> | Hixie, do you expect the HTMLWG to actually publish LC at that time, or just that the spec itself will be ready for it in theory? |
| 10:08 | <mookid> | Hixie: nice =) |
| 10:08 | <takkaria> | Hixie: your script is borked |
| 10:09 | <Lachy> | and will there be a Last Call snapshot published on whatwg.org, independently from the HTMLWG, regardless of what they do? |
| 10:09 | <takkaria> | Hixie: it appears to not be plotting the lines on the issues graph |
| 10:10 | <Lachy> | takkaria, which browser are you using? |
| 10:10 | <Lachy> | the script relies on canvas text apis, which is why it breaks in Opera |
| 10:10 | <Steve^> | Is this some new form of art? |
| 10:10 | <takkaria> | ah, I need to use Fx3.5 then |
| 10:10 | <takkaria> | apparently I've never look at that on my work computer before |
| 10:11 | <Steve^> | Firefox 3.0 shows a more graph-like thing.. but I have no idea what it means |
| 10:11 | Steve^ | doesn't have a browser on his system capable of viewing that graph |
| 10:12 | <jgraham_> | Steve^: You need more browsers |
| 10:12 | <takkaria> | ah, Chrome works |
| 10:12 | <Hixie> | Lachy: i expect the whatwg to publish an LC draft in october |
| 10:12 | <annevk2> | for those without capable browsers: "77 e-mails remaining; 92 issues remaining; 158 bugs remaining. Last updated 0.2 hours ago." |
| 10:13 | <mookid> | Hixie: content-type is the content-type for that file input; what's the problem with that? |
| 10:14 | <Steve^> | isn't content-type used elsewhere with a different meaning? |
| 10:14 | <mookid> | that's how the Content-Type header shuold be set for any request going out |
| 10:14 | <annevk2> | no |
| 10:14 | <annevk2> | the content-type is application/form-data or some such |
| 10:15 | <mookid> | right - that's pretty wrong |
| 10:15 | <mookid> | if my browser is upload a pdf it should be setting the content-type header for that chunk to application/pdf |
| 10:15 | <Hixie> | mookid: content-type is the type of a parameter, not a name of a parameter. |
| 10:16 | <mookid> | eh? dunno what you saying there Ian |
| 10:16 | <Hixie> | mookid: both enctype="" and accept="" take content types on <input>, and we can't name them both content-type |
| 10:16 | <annevk2> | mookid, not if the pdf is encoded as application/form-data (or whatever the actual type is) |
| 10:16 | <Hixie> | actually it's called formenctype now |
| 10:16 | <Hixie> | not enctype |
| 10:16 | <Hixie> | but the point is the same |
| 10:16 | <mookid> | wait what |
| 10:17 | <mookid> | what does formectype do then? |
| 10:18 | <mookid> | annevk2: if the browser is sending a pdf it should be setting the content-type header to applicaiton/pdf suyrely? |
| 10:18 | <mookid> | that's what that header is for.. |
| 10:18 | <mookid> | application/form-data is meaningless |
| 10:18 | <Steve^> | last time I tried looking at them, I found the values to be very inconsistent |
| 10:19 | <Hixie> | mookid: i recommend reading the spec before sending feedback :-) |
| 10:19 | <Steve^> | but this was some years ago |
| 10:19 | <annevk2> | mookid, no, but I'm bowing out of this discussion no |
| 10:19 | <mookid> | hmm ok |
| 10:19 | <mookid> | very odd. |
| 10:20 | <brucel> | So, Mike Smith said yesterday that IRC rocks http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1066 and I should hang out in this party. Question about classid being non-conformant in html5. Someone at a conference I spoke at needs to do Hixie's Flash fallback thang http://damowmow.com/playground/demos/flash/001.html but it's illegal in html5. How can this be achived? |
| 10:20 | <mookid> | what do you people have against HTTP? -_- |
| 10:20 | <boblet> | hey brucel :) |
| 10:20 | <krijnh> | Howdy brucel! |
| 10:20 | <mookid> | did Fielding piss in your corn flakes or something?~ |
| 10:20 | <virtuelv> | Lachy: that might be, but just loading the spec is painful when I've clamped my CPUs to 800MHz |
| 10:20 | <brucel> | hi gang. Now this IS a nice party |
| 10:20 | <krijnh> | Not it is, yes ;) |
| 10:21 | <krijnh> | *Now |
| 10:21 | <virtuelv> | because you know, that's only about as fast as a mobile phone these days |
| 10:21 | <krijnh> | brucel: so, why aren't you coming to Fronteers 2009, damnit! |
| 10:21 | <mookid> | Hixie: where abouts on the spec are you suggesting I read |
| 10:21 | <Hixie> | brucel: people didn't have a problem violating the html4 spec to get it working in IE, why would they have a problem violating the html5 spec? :-) |
| 10:22 | virtuelv | had expected brucel to show up with clownabuser as his nick |
| 10:22 | <Hixie> | (IE's use of clsid="" and codebase="" both violate HTML4's definitions) |
| 10:23 | <boblet> | “IE, the Violator” |
| 10:23 | <Hixie> | i suppose we should find someone way to include flash in html5 that works in IE, though, even if we never had one for html4 |
| 10:23 | <boblet> | woah, that sounds way too scary |
| 10:23 | <brucel> | Hixie, fair point but this guy wants to Do It Right TM |
| 10:24 | <Hixie> | let's see... |
| 10:24 | <mookid> | Hixie: wait, I just read it - and it doesn't explain anything at all it just repeats the same nonsense from html4; why did you tell me to read the spec? |
| 10:24 | <brucel> | krijnh - Fronteers possibly clashes with a trip elsewhere. Plus, I can never find decent beer in the Netherlands |
| 10:25 | <Hixie> | mookid: you read the whole spec in 5 minutes?! |
| 10:25 | <mookid> | why do I need to read the whole spec in order to have a discussion on this specific issue? |
| 10:26 | <Philip`> | It's a subtle to plan to keep you busy for three weeks |
| 10:26 | <Steve^> | mookid, you just want the name of "accept" changed? |
| 10:26 | <Hixie> | what Philip` said |
| 10:26 | <mookid> | well yeah but I think this whole thing about content-type header on upload would be useful |
| 10:26 | <krijnh> | brucel: hmm, okay :) |
| 10:26 | <Philip`> | s/subtle to/subtle/ |
| 10:27 | <krijnh> | No decent beers, tsk |
| 10:27 | <Hixie> | brucel: ok so say you wanted to embed the flash file "http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf"; |
| 10:27 | <annevk2> | brucel, really? I hardly ever have that problem |
| 10:27 | <mookid> | why are we using application/form-data when the mime type can be specified properly |
| 10:27 | <Hixie> | brucel: it looks like the easiest way to do that in IE is the following markup: |
| 10:27 | <Hixie> | <embed src="http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash.swf">; |
| 10:27 | <annevk2> | brucel, what kind of beer are you into? |
| 10:28 | <annevk2> | mookid, that you do not understand that indicates you should read the spec |
| 10:28 | <Hixie> | brucel: and that is valid in HTML5 |
| 10:28 | <mookid> | annevk2: why don't you just explain it, it's not that complicated a question :/ |
| 10:28 | <Philip`> | mookid: When you're uploading a PDF file via <input type=file>, the data it sends is not simply the file content, it has to include the field name and other input fields and stuff, so it's sending some special type of form data and not just a PDF |
| 10:28 | <Philip`> | I think |
| 10:29 | <mookid> | isn't that why it's chunked? |
| 10:29 | <mookid> | the actually payload chunk can have the content-type specified |
| 10:29 | <mookid> | actual^ |
| 10:29 | <Steve^> | that seems sensible |
| 10:30 | Hixie | wonders where brucel went |
| 10:30 | <mookid> | it's extremely useful if you're trying to write layered HTTP systems |
| 10:30 | <mookid> | like CDNs |
| 10:30 | <Steve^> | mookid, can you trust that though? Maybe you'll need to do a server side check on the file content still? |
| 10:30 | <mookid> | potentially |
| 10:30 | <mookid> | implementation detail |
| 10:31 | <mookid> | you might just want to store a bogus file anyway |
| 10:31 | <brucel> | Hixie, went on reverie about beer. Back now |
| 10:32 | <brucel> | So, the outer <object> that you used (with classid for IE) can be replaced by embed, which is now legal in html5? |
| 10:33 | <Steve^> | mookid, do browsers not already do that? |
| 10:33 | <Hixie> | brucel: the whole thing can be replaced by embed |
| 10:33 | <mookid> | I don't think so |
| 10:33 | <brucel> | didn't think embed had fallback for non-flash browsers? |
| 10:34 | <Hixie> | it doesn't |
| 10:35 | <brucel> | customer wants to "embed" Flash, with fallback to static <img>, but validate as html5 |
| 10:35 | <Hixie> | oh, you didn't say that |
| 10:35 | <Hixie> | said customer has users who actually don't have flash and would be happy with a static img instead? wow |
| 10:36 | <brucel> | sorry, should've; that's why I went for your double object menthod. |
| 10:36 | <brucel> | Hixie: fallback for Safari, Opera and other mobile browsers so there's no big white space |
| 10:36 | <krijnh> | Why not use SWFObject for that? |
| 10:36 | <Hixie> | set a background image on the container |
| 10:37 | <brucel> | while I understand why classid is not allowed - and speaking of Flash is distasteful here - it seems likie a valid request |
| 10:38 | <brucel> | SWFObject is good - but there should be a markup-only way imo to get to the static fallback content |
| 10:39 | <Steve^> | (doesn't <video> allow that?) |
| 10:40 | <Hixie> | brucel: damowmow.com/playground/demos/flash/003.html |
| 10:40 | <Hixie> | er |
| 10:40 | <Hixie> | brucel: http://damowmow.com/playground/demos/flash/003.html |
| 10:40 | <mookid> | Steve^: no they don't do that |
| 10:41 | <mookid> | Hixie: that's right, yeah - browser send the data chunked but the don't set the conte-type header on the way out? |
| 10:41 | <Hixie> | mookid: i really have no idea what you're talking about |
| 10:41 | <Steve^> | mookid, I'm by no means important around here, but it seems logical for that to be set on the correct chunk. Could be added to the spec |
| 10:41 | <brucel> | Hixie v nice |
| 10:41 | <mookid> | that was rationale for calling 'accept' 'content-type' |
| 10:42 | <mookid> | because it's constraining what those headers can be set to |
| 10:42 | <Hixie> | mookid: and your rationale for not calling formenctype content-type is what? |
| 10:42 | <mookid> | well I don't know why there's 2 |
| 10:42 | <mookid> | feel free to explain |
| 10:42 | <Hixie> | one is to set what file types the <input> element accepts, and the other is to sent what the encoding type will be when the form is submitted |
| 10:42 | <brucel> | another attendee question: is there any use in the <header> element if surrounds a heading <h1>..<h6> and nothing else? (I said no) |
| 10:42 | <Steve^> | mookid, I think Hixie's integer example was marvellous. min="" rather than integer="" |
| 10:42 | <mookid> | how could those.. be different? -_- |
| 10:43 | <Steve^> | mookid, accept-content-type would be better, it says what it is and what type of thing it takes. Or shorten to accept |
| 10:43 | <mookid> | yeah ok fair enough |
| 10:43 | <Hixie> | mookid: if i submit a form with three form fields, i can submit it either using multipart/formdata, or using the foo=bar&baz=quux&a=b format, or using the foo: bar\nbaz: quux format |
| 10:44 | <Hixie> | mookid: that's the enctype |
| 10:44 | <Steve^> | we must assume that developers can read the spec and know what type each attribute takes, and refer to the attributes only by name |
| 10:44 | <Hixie> | mookid: and a single form can have multiple <input type=file>s, one accepting images, one accepting PDF files, etc |
| 10:44 | <Hixie> | you really should read the spec |
| 10:44 | <mookid> | mmmhmmm |
| 10:45 | <mookid> | you should write better specs |
| 10:45 | <beowulf> | miaow |
| 10:45 | <mookid> | :) |
| 10:45 | <Philip`> | Do you have concrete suggestions that would make it better? |
| 10:45 | <mookid> | fire Ian. |
| 10:45 | <mookid> | :D |
| 10:45 | <Philip`> | That would result in the spec not being written, so I'm not sure that'd be any better |
| 10:46 | <mookid> | really? |
| 10:46 | <mookid> | I don't know about that. |
| 10:46 | <mookid> | as things stand anyway |
| 10:46 | <Steve^> | Some of what mookid says it good. Uploaded files should be sent with the corrent content-type. |
| 10:46 | <annevk2> | mookid, the relevant specs are not written by Ian |
| 10:47 | <annevk2> | mookid, that is, you could chose to read HTML4 and the relevant RFCs instead |
| 10:47 | <mookid> | I'm being jovial, relax |
| 10:47 | <mookid> | deep breaths |
| 10:47 | <Hixie> | let me know when you're done writing the specs instead of me :-) |
| 10:47 | <annevk2> | mookid, I'm just explaining he does not need to be a barrier to your learning process |
| 10:48 | <mookid> | ok, look I'm just trying to help you write a hypermedia format that works better with the protocol which makes it worth something |
| 10:48 | <mookid> | blablabla email not just HTTP |
| 10:48 | <brucel> | hixie your demo page, nothing at all shows in FF3.5 for some reason; when I disable Flash in Opera I don't get fallback content. (Dunno how to disable Flash in the other browsers) |
| 10:49 | <mookid> | HTTP is pretty important and what HTML5 provides will constrain/inhibit developers to use it |
| 10:49 | <Hixie> | brucel: huh, dunno what's up with firefox |
| 10:49 | <annevk2> | mookid, what you've said so far indicates you do not have a basic understanding of HTML forms and yet you want to propose changes to it |
| 10:50 | <annevk2> | mookid, that does not work |
| 10:50 | <mookid> | the reason I'm tlaking to you on here is because I accept that fact |
| 10:50 | <mookid> | if you spent less time telling me I was wrong and more time explaining why |
| 10:50 | <mookid> | perhaps this wouldnt drag out everytime |
| 10:51 | <annevk2> | several people already explained your misunderstanding but it didn't improve matters apparently |
| 10:51 | <mookid> | I don't think you did actually |
| 10:52 | <brucel> | annevk2, krijnh (I have found good beer in Holland, but last time I felt really bad after just 2 pints of that Jenever beer.) |
| 10:52 | <Hixie> | brucel: try now |
| 10:52 | <annevk2> | brucel, lol |
| 10:52 | <krijnh> | Jenever beer :D |
| 10:52 | <takkaria> | mm, Jenever |
| 10:53 | <Hixie> | mookid: when i tried to explain to you what you were misunderstanding, you told me to write better specs |
| 10:53 | <mookid> | annevk2: why is there any need to specify the formenctype for a file input field that already has the acceptable content-types specified? |
| 10:53 | <Hixie> | mookid: this is not conducive to a good working relationship |
| 10:53 | <mookid> | the content-type header will need to be set according to the file selected |
| 10:53 | <mookid> | it needs to be dynamic |
| 10:53 | <annevk2> | wtf, twitter changed my avatar |
| 10:54 | <mookid> | hence why I don't see a need for accept and formectype |
| 10:54 | <brucel> | Hixie works in FF3.5, still no fallback in Opera. Need to test other browsers too. Cheers |
| 10:54 | <Steve^> | annevk2, there were some issues, yes |
| 10:54 | <Hixie> | dunno what's up with the new fallback |
| 10:55 | <mookid> | Hixie: surely it doesnt make any sense to pre-define the enc type for a file input that hasn't been selected? |
| 10:55 | <annevk2> | mookid, formenctype doesn't apply to file input |
| 10:56 | <mookid> | are you sure? its linked under the file type |
| 10:56 | <Hixie> | mookid: enctype isn't important to your point, the point is just that there are many attributes that take content-types, so namign the attribute "content-type" makes no sense |
| 10:56 | <annevk2> | mookid, yes |
| 10:56 | <Hixie> | mookid: just like we wouldn't name the name="", value="", title="", and class="" attributes string="" |
| 10:56 | <Hixie> | or the min="", max="", and step="" attributes number="" |
| 10:56 | <mookid> | Hixie: ok how about accept-content-type |
| 10:56 | <mookid> | or content-types-accepted |
| 10:56 | <Hixie> | accept="" is fine |
| 10:57 | <Hixie> | we don't say min-number="" or title-string="" or class-list-of-keywords="" or id-unique-string="" or whatever |
| 10:57 | <zcorpan__> | Hixie, brucel: you can have one object that has both data="" and <param name=movie> |
| 10:57 | <zcorpan__> | data="" works in all but ie |
| 10:57 | <zcorpan__> | <param> works in all but firefox |
| 10:58 | <zcorpan__> | (someone file a bug in moz bugzilla?) |
| 10:59 | <MikeSmith> | my irc client beeped a beer sound.. somebody said "beer" |
| 10:59 | <Hixie> | zcorpan__: i considered that but it looks silly :-) |
| 10:59 | <MikeSmith> | ./lastlog beer |
| 10:59 | <MikeSmith> | whoah |
| 10:59 | <takkaria> | MikeSmith: ah, we know how to summon you now you've told us that |
| 10:59 | <MikeSmith> | brucel! |
| 10:59 | <Hixie> | ok 3am, i should go to bed |
| 11:00 | <Hixie> | nn |
| 11:00 | <mookid> | Hixie: is it the job of the HTML5 spec to mandate that the chunk containing the file contents have the apropriate content-type header set ? |
| 11:00 | <zcorpan__> | Hixie: having two objects makes things harder for scripts |
| 11:00 | <mookid> | =/ |
| 11:01 | <MikeSmith> | annevk2: cantillon gueuze |
| 11:01 | <zcorpan__> | mookid: file a spec bug to make Hixie reply :) |
| 11:01 | <MikeSmith> | oh man |
| 11:01 | <MikeSmith> | mookid: hey |
| 11:01 | <mookid> | ? |
| 11:01 | <mookid> | hi |
| 11:01 | <mookid> | how's it going? |
| 11:01 | <MikeSmith> | good good |
| 11:01 | <mookid> | sound |
| 11:02 | <annevk2> | Steve^, do you know if the avatars come back? |
| 11:02 | <mookid> | anyone help? - is it the job of the HTML5 spec to mandate that the chunk containing the file contents have the apropriate content-type header set ? |
| 11:03 | <Steve^> | annevk2, "Update (5:30p): We�ve identified the root cause of this problem and expect the issue to be resolved within the next several hours." |
| 11:03 | <annevk2> | mookid, no |
| 11:03 | <Steve^> | annevk2, keep an eye on twitter.com/twitter |
| 11:03 | <annevk2> | Steve^, ta |
| 11:03 | <mookid> | annevk2: which body would spec that out? |
| 11:03 | <annevk2> | mookid, IETF |
| 11:03 | <mookid> | really? o.O |
| 11:04 | <mookid> | it seems pretty relevant to HTML |
| 11:05 | <brucel> | cheers zcorpan |
| 11:05 | <zcorpan> | hi brucel |
| 11:05 | <zcorpan> | mookid: file a spec bug |
| 11:05 | <mookid> | gah I can't do dorky things like that |
| 11:05 | <mookid> | have no idea what I'm doing there |
| 11:05 | <zcorpan> | mookid: sure you can, it's simple as pie. use the comment box in the whatwg spec |
| 11:06 | <brucel> | zcorpan, thx for advice on the flash thang |
| 11:06 | <mookid> | yeah but I'll word it like I'm on IRC |
| 11:06 | <zcorpan> | so? |
| 11:06 | <mookid> | and then people will laugh at me and I wont be cool anymore |
| 11:06 | <zcorpan> | it's anonymous :) |
| 11:06 | <mookid> | oh ok cool |
| 11:07 | <zcorpan> | brucel: it's basically the same thing as the old ALA article |
| 11:07 | <annevk2> | mookid, it's defined in RFC 2388 |
| 11:07 | <zcorpan> | brucel: iirc, ie would wait with showing the flash until it has downloaded the whole file |
| 11:09 | <mookid> | hmm interesting annevk2: As with all multipart MIME types, each part has an optional "Content-Type", which defaults to text/plain. If the contents of a file are returned via filling out a form, then the file input is identified as the appropriate media type, if known, or "application/octet-stream" |
| 11:10 | <Steve^> | mookid, that's from the spec? |
| 11:10 | <mookid> | from the RFC he just told me to look at |
| 11:10 | <mookid> | http://www.ietf.org/rfc/rfc2388.txt section 3 |
| 11:10 | <Steve^> | oh, I see |
| 11:10 | <Steve^> | if its not in the spec, file a bug report to have it added |
| 11:10 | <zcorpan> | does html5 reference it? |
| 11:10 | <annevk2> | zcorpan, yes |
| 11:10 | <Steve^> | and then when it is added, file a bug report against each of the browsers : |
| 11:11 | <annevk2> | zcorpan, but mookid refuses to read the spec |
| 11:11 | <mookid> | link to the part of html5 I shoul dbe looking at? |
| 11:11 | <mookid> | ok just show me the part I should be looking at please =-/ |
| 11:11 | <annevk2> | Steve^, is there actually a bug in browsers? I somewhat doubt it |
| 11:11 | <mookid> | doesn't seem like they are conforming to the spec |
| 11:11 | <Steve^> | annevk2, if the spec changes and they don't follow the spec, then you can raise a bug/feature against it |
| 11:12 | <zcorpan> | mookid: 4.10.17.5 |
| 11:12 | <Steve^> | Opera Turbo makes captchas an extra challenge |
| 11:12 | <mookid> | URL? -_- |
| 11:12 | <annevk2> | Steve^, really? :) |
| 11:12 | <takkaria> | mookid: christ, just open the spec... http://www.whatwg.org/specs/web-apps/current-work/multipage/ |
| 11:13 | <mookid> | see I was here |
| 11:13 | <mookid> | http://www.w3.org/TR/html5/forms.html |
| 11:13 | <mookid> | thank you. |
| 11:13 | <zcorpan> | mookid: TR/ is always outdated, fwiw |
| 11:13 | <mookid> | ok sorry I'm not a spec dork :/ |
| 11:13 | <mookid> | guilty. |
| 11:13 | <zcorpan> | just trying to help :) |
| 11:14 | <mookid> | I know just frustrated |
| 11:14 | <mookid> | thanks :) |
| 11:16 | <mookid> | hmm |
| 11:17 | <brucel> | zcorpan so there still isn't a way to get flash in a page that 1) doesn't make IE wait, 2) works x-browser and 3) allows fallback in the markup and 4) validates as html5? The fallback in the markup is necessary for non-JS users, and validation is an important part of lots of corporate QA |
| 11:18 | <annevk2> | just make a small swf that loads the big swf |
| 11:19 | <annevk2> | or ... don't use Flash :) |
| 11:19 | <zcorpan> | brucel: what annevk2 said |
| 11:19 | <mookid> | zcorpan: so you think I should provide a comment about specifying how file input's are handled? |
| 11:19 | <zcorpan> | brucel: it might be the case that it's fixed in ie8, haven't tested |
| 11:20 | <brucel> | annevk2 with you on both points, but a nasty SWF hack feels uber-dirty and many corporates do use Flash at the moment |
| 11:20 | <zcorpan> | mookid: html5 references the rfc, so i don't know what's not specified |
| 11:21 | <brucel> | feels like classid should be made "conformant but minging" or whatever the specspeak is so Hixie's double object method will validate |
| 11:23 | <annevk2> | just for IE8? |
| 11:23 | <annevk2> | hmm |
| 11:23 | <annevk2> | HTML5 is not done yet, maybe it's better to file a bug on IE |
| 11:23 | <zcorpan> | i think classid makes other browsers ignore the object |
| 11:23 | <zcorpan> | no? |
| 11:23 | <annevk2> | some browsers have hacks for classid |
| 11:24 | annevk2 | forgot the details |
| 11:24 | <mookid> | so this Content-Disposition: form-data; name="user" |
| 11:24 | <mookid> | name is taken from the input id attribute? |
| 11:25 | <Steve^> | My understanding was that the video element was created to solve video problems like this |
| 11:25 | <Steve^> | the HTML5 way would be to use that |
| 11:25 | <Steve^> | but, I'm new here |
| 11:25 | <zcorpan> | brucel: i'd try to get firefox fix their lack-of-data="" bug and ie fix their wait-until-loaded bug (if they haven't already) |
| 11:26 | <mookid> | I think I've asked this before but I can't remember what the answer was |
| 11:26 | <annevk2> | Steve^, video is not the only use case for Flash |
| 11:27 | <mookid> | is there a channel/group for browser devs or is this the best place to be for that? |
| 11:29 | <takkaria> | nattokirai: taken from <input name=""> |
| 11:29 | <takkaria> | uh |
| 11:29 | <takkaria> | mookid: taken from <input name=""> |
| 11:30 | <Philip`> | mookid: There are other channels that are better for specific browsers |
| 11:31 | <Philip`> | (like #webkit for WebKit, and Mozilla IRC for Mozilla) |
| 11:31 | <jgraham_> | But his one is good for browsers in general |
| 11:31 | <jgraham_> | Well some browsers |
| 11:31 | <Philip`> | (For IE, you can, uh, I suppose comment in a random post on the IEBlog and then be ignored) |
| 11:32 | <hsivonen> | Hixie: I think the "in foreign" exit is well-defined |
| 11:32 | <mookid> | ha |
| 11:32 | <mookid> | ok thanks :) |
| 11:33 | <hsivonen> | so it turns out that the people digging up the phone copper weren't doing it because I complained about my ADSL |
| 11:33 | <mookid> | gypos? |
| 11:33 | <hsivonen> | they are doing it because a different person in the building and customer of a different ISP |
| 11:34 | <zcorpan> | for IE you can participate in their yearly sheduled IE Team Chat Session for 60 minutes, or similar |
| 11:34 | <jgraham_> | and be ignored |
| 11:34 | <zcorpan> | yeah |
| 11:34 | <mookid> | hey |
| 11:34 | <mookid> | at least they're trying |
| 11:34 | <Philip`> | It's not the greatest feedback system in the world |
| 11:35 | <mookid> | IE is going to die anyway |
| 11:35 | <mookid> | I have a plan |
| 11:35 | <mookid> | a genius plan |
| 11:35 | <Philip`> | (It is pretty hard to have a feedback system that doesn't get overwhelmed by noise, when you have a billion users) |
| 11:35 | <Philip`> | (so I'm not sure what they could do better) |
| 11:36 | jgraham_ | is wondering whether the death of IE will come before or after the entropy death of the universe |
| 11:36 | <jgraham_> | Note: "entropy death of the universe" is a term I just made up |
| 11:36 | <brucel> | like i said, "conformant but horrible" for classid makes the whole Flash embed validation problem go away and doesn't require anyone to change their code, just WHATWG to change the spec. (The Flash they use isn't for video) |
| 11:36 | <hsivonen> | Philip`: generally speaking, people shouldn't use IRC to complain about Firefox bugs |
| 11:36 | <mookid> | spyware |
| 11:36 | <mookid> | no wait |
| 11:36 | <mookid> | it's not called that |
| 11:37 | <hsivonen> | brucel: Hixie had a demo that made Java embedding using <object> work cross-browser using only HTML5-valid stuff |
| 11:37 | <karlcow> | http://tech.groups.yahoo.com/group/rest-discuss/message/13346 |
| 11:37 | <karlcow> | doesn't seem to be a joke finally… The REST-* |
| 11:37 | <hsivonen> | brucel: does the same thing not work for Flash? |
| 11:38 | <mookid> | package the webskit/mozilla engines so devs can use them like adobe-AIR |
| 11:38 | <brucel> | hsivonen got a link, Henri? |
| 11:38 | <hsivonen> | brucel: http://damowmow.com/playground/demos/java/001.html |
| 11:38 | <annevk2> | brucel, are you sure classid does not break other browsers? |
| 11:39 | <hsivonen> | IIRC, classid breaks Gecko |
| 11:39 | <hsivonen> | or at least used to, IIRC |
| 11:39 | <hsivonen> | maybe that was an artifact of XPCOM plug-ins |
| 11:39 | <hsivonen> | dunno what the story is now with NPRuntime |
| 11:41 | <brucel> | annevk2 Hixie's orginal demo seems to work everywhere, just not validate as html5: http://damowmow.com/playground/demos/flash/001.html |
| 11:41 | <hsivonen> | brucel: it would be very cool to have an HTML5 doctor article about how to do Flash and Java in a Hixie-approved way syntactically |
| 11:41 | <zcorpan> | filed https://bugzilla.mozilla.org/show_bug.cgi?id=517440 |
| 11:41 | <hsivonen> | (even if Hixie doesn't approve of Flash and Java) |
| 11:42 | <hsivonen> | zcorpan: do you have an on-the-Web URL demo/test case to go with the bug report? |
| 11:43 | <zcorpan> | hsivonen: i did until Hixie changed his test to be Firefox-compatible |
| 11:43 | <zcorpan> | hsivonen: see brucel's message above for a flash file to use |
| 11:45 | <brucel> | I agree that I'm talking dirty, but reiterate this is a genuine use case. Just in on twitter, for example "Do share if you find a solution .. it's a prob I've been encountering a lot of the last few months... will need a change in spec to get around though I think?" http://twitter.com/allmarkedup/statuses/4076136010 |
| 11:45 | <adactio> | brucel: you can take a look at how I'm doing cross-browser Flash on Huffduffer. I'm not using <embed> but the crucial thing is duplicating the swf path in the @data attribute of <object> *and* in a <param name="movie"> element. Fallback content goes before the closing </object>. |
| 11:45 | <annevk2> | brucel, did you see the hack it's using |
| 11:46 | <annevk2> | brucel, ouch |
| 11:46 | <annevk2> | adactio, that apparently prevents incremental loading |
| 11:46 | <brucel> | annevk2 yes, I'm covering my eyes and holding my nose. |
| 11:46 | <adactio> | annevk2: Yes. Basically I'm doing Flash Satay so it only really works well with small .swf files (the whole thing is downloaded before being displayed. |
| 11:47 | <brucel> | adactio that's why I discounted that method as a bullet-proof one to recommend |
| 11:47 | <brucel> | tho it's perfectly acceptable much of the time |
| 11:47 | <adactio> | brucel: well, it depends on the use case. It works well for video or audio flash containers that then point off to the actual movie or sound file. |
| 11:47 | <zcorpan> | brucel: use <!--[if IE]><object for ie><param><![endif]--><!--[if !IE]>--><object for others><!--<![endif]--><param quality etc>fallback</object> |
| 11:48 | <zcorpan> | i might have screwed up the cc syntax but the idea is the same |
| 11:48 | <zcorpan> | the first object can use classid and be hidden from the validator |
| 11:48 | <adactio> | Incidentally, I would totally use <audio> on Huffduffer in a heartbeat if it weren't for the bug in Safari that insists on prebuffering (even in the absence of @autobuffer). |
| 11:49 | <adactio> | Here's the bug: https://bugs.webkit.org/show_bug.cgi?id=25267 |
| 11:49 | <brucel> | will try zcorpan, thx. (Actually, will ask some flash ppl to look as I know zilch about little swfs to call in big swfs etc) |
| 11:50 | <zcorpan> | brucel: if you write an article, i could help review it |
| 11:50 | <zcorpan> | it could go from simplest case to most complext case with most requirements |
| 11:51 | <zcorpan> | 1) no fallback? use <embed>! 2) want fallback and have a small flash file? ... |
| 11:51 | <brucel> | zcorpan thanks. Actually, am going on the razzle with some guys from Adobe tomorrow in London and will bat it back to them to have a look at. |
| 11:51 | <brucel> | not bat it back, but bat it to... |
| 11:52 | <zcorpan> | ok |
| 11:53 | zcorpan | will now spend the rest of the day to try to find <source> bugs |
| 11:53 | <brucel> | I found a way to embed YouTube vids as valid html5, but not with any fallback http://www.brucelawson.co.uk/2009/html-5-flash-embedding-and-other-validation-erors/ |
| 11:54 | <zcorpan> | brucel: the <embed> alone is enough |
| 11:54 | <adactio> | brucel: for YouTube videos you can just use Flash Satay because the actual .swf file is very small so the lack of buffering doesn't really matter. |
| 11:55 | <zcorpan> | <embed src="http://www.youtube.com/v/8-pFwbHMuwA&hl=en&fs=1">; |
| 11:55 | <brucel> | good to know, thanks chaps. I feel The Article Of Doom coming on |
| 11:57 | <brucel> | and now must get on and give annevk2 the list of developer worries about html5 that I've been collecting the last few weeks (which I promised him on Tuesday) |
| 11:57 | <annevk2> | adactio, that's not a bug in theory btw |
| 11:58 | <adactio> | annevk2: explain. |
| 11:58 | <annevk2> | adactio, UAs are free to buffer if they want |
| 11:58 | <zcorpan> | it's a bug in practice |
| 11:59 | <adactio> | annevk2: Not true. The spec says that UAs are *free to ignore the @autobuffer attribute*. That means they are free to ignore the request to autobuffer. It does not mean they are free to automatically autobuffer. |
| 11:59 | <annevk2> | adactio, that's not what it means |
| 11:59 | <adactio> | annevk2: that's how it reads. |
| 11:59 | <annevk2> | not to me |
| 11:59 | <zcorpan> | adactio: browsers are free to download whatever they want |
| 11:59 | <zcorpan> | adactio: autobuffer="" is a hint |
| 12:00 | <zcorpan> | adactio: browsers are required to download enough to show the first frame unless poster="" is present |
| 12:00 | <zcorpan> | but that's all |
| 12:00 | <adactio> | zcorpan: then the only way for an author to explicitly request no autobuffering is... by doing nothing. Because any use of the autobuffer attribute will trigger autobuffering (because it's Boolean). |
| 12:00 | <annevk2> | adactio, it's by not setting src |
| 12:01 | <zcorpan> | adactio: indeed |
| 12:01 | <zcorpan> | adactio: but authors should be able to rely on browsers doing whatever is the best experience for their users |
| 12:01 | <zcorpan> | adactio: even when faced with a page that has 30 <video src>es |
| 12:01 | <adactio> | zcorpan: my point entirely. |
| 12:01 | <annevk2> | no, your point is that the author should be in control |
| 12:02 | <adactio> | if the user agent misbehaves, the author should have some way of at least *requesting* no autobuffering. |
| 12:02 | <zcorpan> | the only way to do that is to not set the src |
| 12:03 | <zcorpan> | (if webkit had implemented suspending download, they would do it without author "requesting" suspending) |
| 12:03 | <zcorpan> | (it's just that they haven't implemented it yet) |
| 12:05 | <adactio> | The spec currently says "This attribute may be ignored altogether. " If you read what the attribute does, that means that user agents don't have to autobuffer ...not that user agents are free to autobuffer willy-nilly. |
| 12:05 | <zcorpan> | adactio: i'm pretty sure it says elsewhere that UAs are free to autobuffer willy-nilly |
| 12:06 | <annevk2> | the purpose of the attribute is to instruct UAs to buffer |
| 12:06 | <annevk2> | the purpose of the attribute is not to instruct UAs not to buffer |
| 12:06 | <annevk2> | so ignoring it cannot mean not buffering, because that was never the purpose |
| 12:09 | <zcorpan> | "User agents may decide to not download more content at any time, e.g. after buffering five minutes of a one hour media resource, while waiting for the user to decide whether to play the resource or not, or while waiting for user input in an interactive resource." |
| 12:10 | <zcorpan> | the text on autobuffer is non-normative, and just says that it's a hint |
| 12:10 | <zcorpan> | or, the normative part is "This attribute may be ignored altogether. The attribute must be ignored if the autoplay attribute is present." |
| 12:11 | <annevk2> | reading it again it seems adactio read between the lines, which is somewhat dangerous with specs |
| 12:12 | <zcorpan> | nevertheless, it's a bug not because it violates html5 but because the user experience sucks |
| 12:13 | <annevk2> | a bug where? |
| 12:14 | <annevk2> | UAs could easily stop buffering if there's > 2 media resources |
| 12:14 | <annevk2> | for instance |
| 12:15 | <zcorpan> | a bug in webkit that it always buffers all media elements |
| 12:16 | <zcorpan> | as explained in the bug report; the bug report doesn't say that webkit violates html5, just that it's wasting bandwidth and causing unhappiness |
| 13:25 | <mpilgrim> | hsivonen: i am offended by http://lists.w3.org/Archives/Public/www-tag/2009Sep/0041.html |
| 13:25 | <mpilgrim> | i did *not* specify feed autodiscovery from my basement |
| 13:25 | <jgraham_> | mpilgrim: Someone elses's basement? |
| 13:25 | <mpilgrim> | i'm pretty sure i was on a couch |
| 13:26 | <jgraham_> | Whose basement was the couch in? |
| 13:26 | <Lachy> | Joseph responded about the about: URI scheme draft, and made most of the changes I suggested. We're just trying to figure out how to sort out the issues with section 5. Resolving "about" URIs and about:blank. |
| 13:26 | <Lachy> | http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt |
| 13:26 | <mpilgrim> | damn it, this is how rumors get started and etched in cement |
| 13:26 | <hsivonen> | mpilgrim: I'm sorry I've caused offense. |
| 13:27 | <mpilgrim> | it is, however, entirely possible that i was in my pajamas at the time |
| 13:27 | <Lachy> | I'm trying to say that unreserved URIs may be resolved in any way at all, but that some reserved URIs need to be resolved as defined. The question is, what to do about effectively reserved URIs that aren't defined to be resolvable, like about:legacy-compat |
| 13:28 | <hsivonen> | mpilgrim: I was more concerned about the "Joe" part than the "basement" part |
| 13:29 | <mpilgrim> | i understand the point |
| 13:29 | <mpilgrim> | also, for the record, i did try to create a real RFC for autodiscovery |
| 13:29 | <hsivonen> | mpilgrim: I'm aware. What happend to the I-D? |
| 13:30 | <karlushi> | there is a lot of cement in basements |
| 13:30 | <mpilgrim> | i dropped out of the scene |
| 13:30 | <annevk2> | Lachy, would it make sense to treat unrecognized URIs as about:blank and reserved URIs as defined unless defined to not resolve? |
| 13:30 | <jgraham_> | Lachy: Just make about:legacy-compat resolve to something. Preferably something funny :) |
| 13:30 | <mpilgrim> | others tried to pick it up |
| 13:30 | jgraham_ | should not be taken seriously |
| 13:30 | <mpilgrim> | but never succeeded in taking it through the RFC process |
| 13:31 | <hsivonen> | jgraham_: that's a dangerous thing to joke about |
| 13:31 | <annevk2> | Lachy, where "reserved" is blank / legacy-compat and whatever the implementation wishes I suppose |
| 13:31 | <hsivonen> | jgraham_: or the next thing we know is that it gets defined to resolve to a DTD |
| 13:31 | <karlushi> | about:life-and-everything |
| 13:32 | <Lachy> | jgraham_, I'd prefer to let browser vendors resolve to whatever they like. e.g. Showing a page telling authors to use <!DOCTYPE html> and explaining that about:legacy-compat is to be avoided unless needed |
| 13:32 | <Lachy> | annevk2, yeah, defining that unrecognised URIs are equivalent to about:blank would be nice |
| 13:39 | <karlushi> | about:[something] could be a nice way to get information about many things, local documentation on your computer. about:weather, about:cinema, etc. doable already I guess with some browsers. |
| 13:39 | <karlushi> | I wonder if it would work gecko.handlerService.schemes.about.1.uriTemplate |
| 13:41 | <Lachy> | karlushi, implementations are free to implement such URIs however they like. |
| 13:42 | <Lachy> | In fact, Netscape 4 had quite a few such URIs that were implemented to redirect to specific websites (mostly the websites of some Netscape developers at the time) |
| 13:42 | <annevk2> | about:jwz |
| 13:43 | <karlushi> | Lachy, yes :) was not thinking about implementation interop, more people configuring it themselves to do magic things. about:weather gives me information about the rain this morning in Montreal and slaps my face for not taking my umbrella. |
| 13:43 | <annevk2> | led to http://www.jwz.org/gruntle/blowme.html |
| 13:43 | <karlushi> | yep |
| 13:43 | <annevk2> | funny story |
| 13:53 | <mpilgrim> | how easy is it for, say, a firefox extension to add a new about:foo page? |
| 13:55 | <annevk2> | mpilgrim, might get a faster answer on irc.mozilla.org |
| 13:58 | <mpilgrim> | eh, just idle curiosity |
| 13:58 | <mpilgrim> | i don't actually want to go make one |
| 13:58 | mpilgrim | catches up on www-tag |
| 13:59 | <Lachy> | I think I've sorted it out. I've defined what reserved, unreserved, and unrecognised about URIs are, and then defined how each should be resolved, and the requirement for unrecognised about URIs is that they SHOULD be treated like about:blank. |
| 14:00 | <Lachy> | I'll mail Joseph and get him to integrate it into the draft |
| 14:04 | <mpilgrim> | can someone give me a high-level overview of why about:blank needs to be standardized? |
| 14:05 | <hsivonen> | mpilgrim: you do <iframe src='about:blank'> and then you want to assume thing about the sub-DOM you got |
| 14:05 | <hsivonen> | mpilgrim: as it happens, I got hit by that one recently, because Gecko puts a doctype node in there |
| 14:05 | <hsivonen> | s/thing/things/ |
| 14:06 | <hsivonen> | mpilgrim: and the reason why you want to do <iframe src='about:blank'> is that you want to obtain an HTML-mode Document object |
| 14:06 | <hsivonen> | mpilgrim: because the factory method gives you an XML-mode object |
| 14:06 | <mpilgrim> | interesting |
| 14:07 | <hsivonen> | however, if you want to get an HTML-mode Document in the no-quirks mode, you lose |
| 14:07 | <mpilgrim> | can't we just make up a new API for that? |
| 14:08 | <hsivonen> | mpilgrim: it would be within reason to have an API for that |
| 14:10 | <mpilgrim> | i mean, i love about:blank as much as the next webgeek |
| 14:10 | <mpilgrim> | it's my home page, after all |
| 14:10 | <annevk2> | mpilgrim, content uses it too |
| 14:11 | <annevk2> | mpilgrim, and UAs have to support it in the manner described by hsivonen |
| 14:11 | <mpilgrim> | that makes sense |
| 14:11 | <mpilgrim> | thanks |
| 14:11 | <annevk2> | so since HTML5 mentions it in the page loading model (or something) people like to see it registered |
| 14:11 | <Lachy> | mpilgrim, the basic reason is that the about: URI scheme needed to be registerred to keep some people happy about about:legacy-compat being used in HTML5 |
| 14:12 | <annevk2> | and we use it for the XSLT-compat doctype now, though that's called about:legacy-compat |
| 14:12 | <hsivonen> | which is odd, because per HTML5, the legacy-compat thingy is just a string |
| 14:12 | <hsivonen> | the URIness kicks in when someone tries to be polyglottal with it |
| 14:13 | mpilgrim | is lost again |
| 14:13 | <hsivonen> | which doesn't matter in practice, because the two people who actually do polyglot publishing don't use that doctype |
| 14:14 | <Lachy> | mpilgrim, if someone uses <!DOCTYPE html SYSTEM "about:legacy-compat"> in an XHTML document, and some XML processor attempts to resolve it to get the DTD, then it gets treated as a URI. Whereas, in the HTML syntax, it's just an opaque identifier |
| 14:14 | <annevk2> | hsivonen, the reason it is a URI is so that tools do not barf |
| 14:15 | <mpilgrim> | so html5 needed to invent a bogus pseudo-URI about:legacy-compat to accomodate XSLT tools |
| 14:16 | <Lachy> | yes |
| 14:17 | <Lachy> | and it needed to be a URI that is intentionally unresolvable, rather than just some random string, to avoid it being treated as a relative URL by some XML processors |
| 14:17 | <mpilgrim> | then we have to register the about: URI scheme because some tools that no one uses might interpret it as a URI |
| 14:17 | <mpilgrim> | got it |
| 14:18 | <AryehGregor> | hsivonen, MediaWiki could definitely use more URL normalization, but NFKC is too strict AFAIK. It would mean <http://en.wikipedia.org/wiki/²>; couldn't be distinct from <http://en.wikipedia.org/wiki/2>; and so on. |
| 14:20 | <AryehGregor> | At least AFAICT. |
| 14:20 | <AryehGregor> | I have no idea how the current setup works in practice for languages like Lao. |
| 14:20 | <hsivonen> | mpilgrim: registering about:legacy-compat is a theoretical purity thing |
| 14:21 | <mpilgrim> | indeed |
| 14:21 | <mpilgrim> | but it doesn't actually hurt anything |
| 14:21 | <mpilgrim> | does it? |
| 14:24 | <annevk2> | mpilgrim, nope |
| 14:24 | <zcorpan> | opportunity cost |
| 14:26 | <mpilgrim> | grr |
| 14:26 | <mpilgrim> | looks like the blog.whatwg.org redesign dropped the google analytics script |
| 14:27 | <annevk2> | oh my bad |
| 14:27 | <mpilgrim> | adding it back... |
| 14:27 | <annevk2> | guess we're missing stats on all the news article attention now |
| 14:28 | <annevk2> | i was quite amused how they all failed to detect sarcasm and praised Google for being so nice |
| 14:30 | <mpilgrim> | ? |
| 14:31 | <erlehmann> | annevk2, its not too late to slip it into slashdots idle queue ;) |
| 14:32 | <annevk2> | mpilgrim, well, they didn't actually praise Google, I made that up |
| 14:33 | <hsivonen> | AryehGregor: it's quite possible that the right fix is to keep MediaWiki as is and configure the Jena IRI lib differently for V.nu |
| 14:34 | <hsivonen> | AryehGregor: however, if that's the right answer, it's a bit annoying that the RFC gives advice that isn't practical for Wikipedia |
| 14:34 | <AryehGregor> | hsivonen, well, changing MediaWiki to normalize more strictly would be a headache due to the millions of existing pages. We're not going to do that anytime soon anyway, without some pressing reason. |
| 14:34 | <hsivonen> | AryehGregor: seems reasonable |
| 14:34 | <AryehGregor> | NFKC seems like it's only good for stuff like search indexes, I don't see how it's usable for actual display. |
| 14:35 | <AryehGregor> | Well, maybe the specific ²/2 case would be handled in HTML output with the <sup> compat thing, but that doesn't help for URLs or <title>s. |
| 14:35 | <hsivonen> | Wikipedia URLs are a kind of a search index, though |
| 14:36 | <annevk2> | I would advice against using NFKC |
| 14:36 | <annevk2> | you will actually lose things then |
| 14:36 | <annevk2> | NFC is god enough for IRIs |
| 14:37 | <hsivonen> | annevk2: ooh. you disagree with RFC-given advice! :-) |
| 14:37 | <AryehGregor> | hsivonen, by "search indexes" I mean non-user-visible stuff. Like convert to NFKC for the index, and convert the query to NFKC before searching, then return the actual result in NFC. |
| 14:37 | <hsivonen> | AryehGregor: ok |
| 14:38 | <annevk2> | I don't want my fullwidth latin to be turned into ordinary latin :) |
| 15:03 | AryehGregor | wants a joystick-controlled binary file editor projected onto a 3D hologram system. |
| 15:33 | <Lachy> | AryehGregor, how would joystick control work in an editor? |
| 15:33 | <AryehGregor> | Lachy, I don't know, ask Hixie. |
| 15:34 | <Lachy> | did Hixie say something about it that I missed? |
| 15:34 | <AryehGregor> | Lachy, http://lists.w3.org/Archives/Public/www-style/2009Sep/0176.html |
| 15:35 | <Lachy> | haha |
| 15:37 | <Lachy> | maybe 1's and 0's would be projected onto a curved, 3D workspace, and the joystick could be moved left and right to move the cursor, and up and down to change a bit to 0 or 1. :-) |
| 15:37 | <Lachy> | and the fire button for deleting |
| 15:37 | <TabAtkins> | I think it would be best to have it like a racing game, where you keep being faced with a choice of 1 or 0 and dodge left and right to build up the code. |
| 15:38 | <TabAtkins> | But then I think I'm just influenced by that super-awesome mouse-based typing thing I saw once that worked like that, but with predictive display that made more likely next-letters larger. |
| 15:39 | <TabAtkins> | Lachy: your mail program is messing with formatting. I had spaces before all the elements in my last email, but when you quoted me they disappeared (and now join with the previous word). |
| 15:40 | <AryehGregor> | gsnedders, yesterday I was just diagnosed as probably having chronic fatigue syndrome too. |
| 15:40 | AryehGregor | commiserates |
| 15:41 | <Lachy> | TabAtkins, what? Your mail is here http://lists.w3.org/Archives/Public/public-html/2009Sep/0759.html and the quote looks the same here http://lists.w3.org/Archives/Public/public-html/2009Sep/0762.html |
| 15:42 | <Lachy> | btw, this reminds of a MacBook parody I saw once that replaced they keyboard with a giant touch pad, and required complicated gestures to type stuff |
| 15:42 | <TabAtkins> | Look closer, Lachy. For example, in my original email I typed "second <h1>", and in your quote of my email it shows up as "second<h1>". |
| 15:42 | <Lachy> | oh, it was the MacBook Wheel http://www.theonion.com/content/video/apple_introduces_revolutionary :-) |
| 15:43 | <Lachy> | oh, weird. |
| 15:45 | <TabAtkins> | Anyway, I guess I agree with you that using <h1>, at least in the manner I described, is unworkable. |
| 15:45 | <Lachy> | I'm not too surprised though. I'm using Postbox, and they've messed up a few issues with their support for format=flowed |
| 15:46 | <TabAtkins> | Who was it yesterday that suggested <p caption>? |
| 15:47 | <TabAtkins> | I'm writing up a response email, and I want to promote that now. I like it more as time goes on. |
| 15:47 | <Lachy> | me |
| 15:47 | <Lachy> | I'm not a huge fan of the idea myself though |
| 15:47 | <TabAtkins> | I'm suggesting it anyway. |
| 15:47 | <TabAtkins> | I like it better than minting a new element. |
| 15:47 | <Lachy> | ok |
| 15:49 | <Steve^> | <p caption> sounds weird, nothing else is done like that? |
| 15:56 | <TabAtkins> | <time pubdate> is done like that now. |
| 16:01 | <annevk2> | TabAtkins, that's different |
| 16:01 | <annevk2> | <p> is nothing like a caption |
| 16:01 | <TabAtkins> | If you're using it as a caption, it is. But then <div> could be too, or <ul>. |
| 16:01 | <annevk2> | -_- |
| 16:02 | <Steve^> | can I <h1 caption>? |
| 16:02 | <TabAtkins> | Yup. |
| 16:02 | <Steve^> | pubdate is a specific type of time |
| 16:02 | <Steve^> | whereas caption can attach to lots of things |
| 16:02 | <TabAtkins> | Hmm, I don't understand the distinction, Steve^. |
| 16:03 | <TabAtkins> | As long as there's no behavioral differences in DOM terms, just a semantic difference, then both are just saying that a particular element has special significance to its parent. |
| 16:04 | <annevk2> | Steve^ said what I meant |
| 16:04 | <annevk2> | anyway, bikeshed discussions are a wot |
| 16:04 | <Steve^> | with time pubdate, the important bit is time, pubdate is a specific bit. You parse time, then pubdate. In this case, the parser needs to search within its children for a caption |
| 16:05 | <Steve^> | I suppose it doesn't need to.. hmm |
| 16:05 | <Steve^> | it feels wrong |
| 16:08 | <TabAtkins> | As far as I know, the caption of a figure is not treated specially in any way. It's just a semantic distinction, useful for UAs that care, but it doesn't have any behavioral difference. |
| 16:10 | <TabAtkins> | annevk2: Yeah, I agree, but whatcha gonna do. Some people threaten Formal Objections over these types of things. I just think <dt>/<dd> in <figure> looks really ugly, but I dont' object to it forcefully or anything. |
| 16:10 | <Steve^> | <p legend> |
| 16:11 | <TabAtkins> | Steve^: pubdate isn't actually a quality of the <time> itself, though. It's a linkage between one particular <time> and its enclosing <article>, and could just as well be an attribute on the <article> that took an IDREF. |
| 16:11 | <TabAtkins> | I have no attachment to the name of the attribute whatsoever; I just thought that people liked "caption". |
| 16:12 | <Steve^> | <ul nav> |
| 16:12 | <brucel> | <div section> |
| 16:12 | <TabAtkins> | At that point you get into problems, as those have behaviors associated with them wrt the outline algorithm. |
| 16:13 | <TabAtkins> | This approach is *definitely* not appropriate past a certain point. |
| 16:13 | <brucel> | <div role=section">, <p role="caption"> yay. (</sarcasm> |
| 16:13 | <Lachy> | TabAtkins, the caption may be given special default rendering distinct from an elements normal styling, if Hixie accepts my previous suggestion |
| 16:14 | <TabAtkins> | Lachy: I must have missed that suggestion. |
| 16:14 | <Lachy> | that would basically make figure display: table; and the caption display: table-caption; and a default caption-side set to top or bottom, based on whether or not it's the first child |
| 16:14 | <Steve^> | how about <section><h1 outline>foo</h1><h2>bar</h2> to avoid hgroup? |
| 16:15 | <TabAtkins> | Steve^, I'm not sure how that's supposed to work. |
| 16:15 | <Lachy> | Steve^, no, as that would require an outline attribute on all h1s intended to be in the outlien |
| 16:15 | <Lachy> | *outline |
| 16:15 | <Steve^> | Oh. I JUST understood what hgroup is for. |
| 16:16 | <Steve^> | I thought I knew, but now I really know. |
| 16:16 | <Lachy> | TabAtkins, that styling suggestion was sent about a year or so ago, but it was linked to recently |
| 16:16 | <Lachy> | I will find it |
| 16:16 | <Steve^> | ("hiding from the outline algorithm" was too vague for me) |
| 16:16 | <TabAtkins> | Nah, I get it Lachy. |
| 16:17 | <TabAtkins> | But I'm not sure that rendering differences are important enough to make an attribute a bad solution here. |
| 16:18 | <Lachy> | http://lists.w3.org/Archives/Public/public-html/2007Sep/0375.html |
| 16:18 | TabAtkins | notes that your suggested rendering would give it a fairly attractive appearance by default, though. |
| 16:19 | <TabAtkins> | figure>[caption] { display: table-caption; caption-side:bottom;} figure>[caption]:first-child { caption-side:top; }? |
| 16:19 | <Steve^> | label.. that's a good idea |
| 16:19 | <Lachy> | it would make things complicated, since browser vendors would have to design appropriate default styles for all elements that could potentially have a caption attribute, and that could mean changing margins, padding, borders, font styles or whatever else |
| 16:19 | <Lachy> | Steve^, no, it's a bad idea. It's unworkable for several reasons |
| 16:19 | <TabAtkins> | Steve^: <label> prevents you from using any form elements inside of it. |
| 16:20 | <Steve^> | why? |
| 16:20 | <TabAtkins> | Lachy: But in your suggestions, the *only* change made to the styling is a display change. |
| 16:20 | <TabAtkins> | Steve^, because it will auto-focus the first such element, preventing you from clicking on anything else. |
| 16:21 | <Lachy> | that's because at the time, it was based on restyling label, which has acceptable defaults for everything else |
| 16:21 | <TabAtkins> | I can see killing margins on [caption] in general, but off the top of my head that's the only change necessary. |
| 16:22 | <TabAtkins> | And there's the obvious work-around (that actually has a visual effect, so it'll be used when necessary) of just wrapping an offending element in a <div caption> rather than making it [caption] itself. |
| 16:23 | <TabAtkins> | Which wouldn't be any worse than <new element><something here></newelement> |
| 16:24 | <TabAtkins> | Frex, <button caption> would probably display pretty oddly. |
| 16:24 | TabAtkins | goes off to try it out. |
| 16:30 | <TabAtkins> | Okay, <button>s refuse to becom table captions at all in FF. |
| 16:30 | <TabAtkins> | But otherwise this works well enough. |
| 16:32 | <TabAtkins> | Hmm, FF doesn't collapse margins through a display:table-caption element that's been visually moved. |
| 16:44 | <mitnavn> | Does the canvas element only work with a pixel based grid? |
| 16:47 | <Dashiva> | mitnavn: As opposed to? |
| 16:47 | <mitnavn> | Percent |
| 16:48 | <Dashiva> | Yes |
| 16:48 | <TabAtkins> | If you're working in script, though, you can fake percentages trivially. |
| 16:48 | <Philip`> | You could use scale() so that all the coordinates are from 0 to 100, if you want |
| 16:49 | <Philip`> | ctx.scale(canvas.width/100, canvas.height/100) I think |
| 16:49 | <mitnavn> | Ah, cool. |
| 16:53 | <brucel> | Possible to use the <audio> element to embed midi audio in a page? |
| 16:53 | <TabAtkins> | Is there any way to link to the effective root when you're using <base>? |
| 16:53 | <TabAtkins> | brucel: Not unless anybody has a decoder for that. |
| 16:53 | <TabAtkins> | Which I don't think anyone does. |
| 16:54 | <brucel> | tragedy |
| 16:54 | <TabAtkins> | I think stopping the promulgation of midi is far from a tragedy. ^_^ |
| 16:54 | <brucel> | the lack of decoder, not the tragedy.mid |
| 16:55 | <brucel> | it was for a fun retro demo page. ah well.... |
| 16:55 | <TabAtkins> | Can you convert to .wav? |
| 16:56 | <Philip`> | Does Windows not come with a MIDI synthesiser by default? |
| 16:56 | Philip` | kind of assumed it did, but he hasn't used MIDI since about ten years ago, and it was all done by Creative drivers back then |
| 16:56 | <TabAtkins> | I think it probably does? |
| 16:57 | <TabAtkins> | Yeah, I haven't used one in years either. |
| 16:57 | <clownabuser> | like your style, TabAtkins - the mellifluous strains of MIDI, with the bandwidth-bashing lack of compression that WAV gives. |
| 16:57 | <TabAtkins> | But I'll bet media player can do it. |
| 16:57 | <Lachy> | clownabuser, if QuickTime supports midi, then Safari will support it in <audio> |
| 16:57 | <TabAtkins> | ...I'm going to keep calling you brucel. |
| 16:57 | <TabAtkins> | Does WAV get much benefit from ordinary gzipping? |
| 16:57 | <Philip`> | Why do you use clown abs? |
| 16:58 | <TabAtkins> | I suspect it would. |
| 16:58 | <Philip`> | TabAtkins: No |
| 16:58 | <clownabuser> | I deny all knowledge of brucel, in case people associate me with the midi question |
| 16:58 | <TabAtkins> | Philip`, damn. |
| 16:58 | <Philip`> | You might save 50% or so, which is rubbish |
| 16:58 | <clownabuser> | clownabuser is an anagram of Bruce Lawson, that someone tweeted me with |
| 16:58 | <Lachy> | haha |
| 16:58 | <clownabuser> | have never liked clowns |
| 16:59 | <Lachy> | ClownAbUser, why? |
| 16:59 | <clownabuser> | sinister buggers, the lot of them |
| 17:00 | <BaitTanks> | Clowns are scary. |
| 17:00 | <BaitTanks> | To me, for the same reasons that zombies and wax museums are scary. |
| 17:00 | <BaitTanks> | I suspect it's the Uncanny Valley. |
| 17:00 | <Lachy> | I've never met a scary clown. I really don't get why some people think they are |
| 17:00 | <BaitTanks> | I always get creeped out by clowns. |
| 17:00 | <clownabuser> | Scary clowns are banned from the Oslo metropolitan limits |
| 17:00 | <WebFoul> | one letter out... |
| 17:01 | <clownabuser> | which is why you've never met one Lachy |
| 17:01 | <Lachy> | BaitTanks, wax museums, sure. But zombies?! What's scary about those cute, undead creatures? |
| 17:01 | <BaitTanks> | A zombie is just an animate wax museum. |
| 17:01 | <Lachy> | clownabuser, I've never met a clown in Oslo. Hmm... I wonder why? |
| 17:01 | <Steve^> | Lachy is fearless, apparently |
| 17:01 | <adactio> | BaitTanks. "Explain it to me with Star Wars." http://kotaku.com/384789/the-uncanny-valley-explained-in-terms-of-porn-and-star-wars |
| 17:02 | <Steve^> | I suppose if you can survive the Koala attacks, you're ready for anything |
| 17:02 | <clownabuser> | it's the snow Lachy. Their oversize shoes get fillled with snow and they can't move, so hypothermia gets them |
| 17:03 | <Steve^> | and then the reindeer eat them |
| 17:04 | <dullsmoothie> | adactio: har! |
| 17:05 | <BaitTanks> | Hehe, adactio. Thanks for that. |
| 17:05 | Lachy | is tying to find a cool anagram for my name, like clownabuser's, but all he can come up with is "tuna can" with 2 H's and 2 L's left over. :-( |
| 17:05 | <BaitTanks> | Lachy: http://wordsmith.org/anagram/anagram.cgi?anagram=lachlanhunt&t=1000&a=n |
| 17:05 | <Steve^> | The Lawson Practice is just round the corner from me. They denied the existence of Dr Bruce and refused to heal my HTML5itis :( (http://www.lawsonpractice.nhs.uk/) |
| 17:05 | <dullsmoothie> | Lachy: sticking with the Star Wars theme: http://deanjackson.dj/nameanagram/index.php?n=lachy+hunt |
| 17:05 | <Lachy> | clownabuser, I don't think the oversize shoes are a problem. You've seen mine! My size 17 (52 in European) whoppers aren't a problem |
| 17:06 | <Dashiva> | dullsmoothie: Too bad he isn't called Huntt |
| 17:06 | <BaitTanks> | God damn, Lachy. I'm just a 14. You have ridiculous feet. |
| 17:06 | <clownabuser> | hmm. Are you perchance an incognito clown, hence leaping to their defence? |
| 17:07 | <BaitTanks> | Like a StopNGo in space? |
| 17:09 | <LaunchNHalt> | BaitTanks, people thought I had ridiculously large feet when mine were size 14 |
| 17:09 | <Steve^> | the surface area of your feet is proportional to your weight. Ish. |
| 17:09 | <LaunchNHalt> | of course, that's back when I was 14 years old, so perhaps it was at the time |
| 17:09 | <gsnedders> | AryehGregor: How bad is it for you? |
| 17:10 | <LaunchNHalt> | Steve^, in my case, ever since I was 13, my shoe size matched my age till I reached 17 :-) |
| 17:13 | gsnedders | grumbles about the messiness of this desk |
| 17:16 | <gsnedders> | Steve^: Really? I'm UK 10/Euro 44 and 56kg… :\ |
| 17:17 | <Steve^> | big feet for your weight then |
| 17:17 | <gsnedders> | I'm also around 180cm |
| 17:17 | <Steve^> | what colour is your hair? |
| 17:18 | Steve^ | builds a criminal profile |
| 17:18 | <gsnedders> | Steve^: Brown |
| 17:52 | <Steve^> | Mac users, how do I maximise the itunes window to full the screen? Tried double click and the green + made it smaller |
| 17:53 | <gsnedders> | Steve^: OS X has no concept of maximize, ever. |
| 17:53 | <gsnedders> | Steve^: Only fit-to-content/minify depending on application |
| 17:53 | <dullsmoothie> | Steve^: drag window resize handle + reposition |
| 17:54 | <Steve^> | how.. primitive |
| 17:54 | <dullsmoothie> | although in visualiser mode there’s probably a fill screen option |
| 17:54 | <dullsmoothie> | no, definitely |
| 17:54 | <Steve^> | I liked a song in Genius and tried to show a list of songs by that artist |
| 17:54 | <Steve^> | nope |
| 17:55 | <Steve^> | must search manually |
| 17:55 | <Steve^> | I'm happy my girlfriend doesn't use Windows, but I don't understand Macs at all |
| 17:56 | <gsnedders> | Most other OSes make the effort for the fit-to-content option, which sucks also |
| 18:33 | <mpilgrim> | http://arstechnica.com/microsoft/news/2009/09/ie-program-manager-endorses-html-5-multimedia-tags.ars |
| 18:34 | <mpilgrim> | which leads people to think things like http://www.programmica.info/2009/09/google-praises-microsoft.html |
| 18:35 | <mpilgrim> | it's like a game of "whisper down the lane" |
| 18:36 | <mpilgrim> | by the time it hits slashdot, the headline will be "Google and Microsoft announce revolutionary new web video standard!!!" |
| 18:37 | <mpilgrim> | TechChrunch will publish an unsubstantiated rumor that Youtube is switching to Windows Media |
| 18:37 | <TabAtkins> | Hehe |
| 18:38 | <mpilgrim> | Mac forums will go ballistic and try to start a boycott of all Google products |
| 18:39 | <mpilgrim> | dave winer will start a mailing list to discuss the creation of a brand new video standard, built from scratch and based on OPML |
| 18:40 | <Steve^> | sounds like some zany apocalyse prediction |
| 18:40 | <Steve^> | apocalypse |
| 18:43 | <mpilgrim> | and zeldman will post a fancy "to whom it may concern" open letter in franklin gothic medium condensed oblique, undersigned by a list of prominent mac-using designers who oppose the video element on the grounds that the letter "v" is awkward and ungainly |
| 18:53 | <AryehGregor> | gsnedders, seriously aggravating but not debilitating. |
| 18:53 | <AryehGregor> | mpilgrim, hey, at least he apparently read the actual mailing list posts you linked to. Could be worse. |
| 18:53 | <AryehGregor> | Well, Ars Technica did, I mean. |
| 18:54 | <AryehGregor> | . . . the second one is awful starting from the subject line. |
| 18:54 | <AryehGregor> | Is "HTML5 evangelist" actually your job or anything? |
| 18:55 | <AryehGregor> | Okay, the second one is retarded, I agree. |
| 18:55 | <AryehGregor> | On the other hand, at least it's a better tone than some of the +5 comments on the Slashdot post on the original mailing list post, which tended to be along the lines of "Look at evil Microsoft criticizing HTML5!!!!" |
| 19:39 | <erl[oberholz]> | That thing you burned up isn't really important to me. It's the <dialog> unit. It made shoes for orphans. Nice job breaking it, hickson. |
| 19:47 | <Philip`> | erl[oberholz]: Don't worry, you're still alive |
| 19:51 | <Steve^> | I'm not quite sure what that means "It made shoes for orphans" |
| 19:52 | <Philip`> | It's just a reference to some dialogue somewhere |
| 19:53 | <TabAtkins> | Can anyone else load http://software.hixie.ch/utilities/js/live-dom-viewer/saved/235 in ie8? |
| 19:53 | <TabAtkins> | I'm getting a yellow-bar saying that it decided to break the page to prevent XSS. |
| 19:54 | <erl[oberholz]> | Steve^, read <http://en.wikiquote.org/wiki/Portal_(game)>; ,but replace "Aperture Science Enrichment Center" with "WHATWG" ;) |
| 19:55 | <Steve^> | ohhh |
| 19:55 | <Steve^> | ok :) |
| 19:55 | <erl[oberholz]> | TabAtkins, interesting. can you spot what exactly triggers the XSS? |
| 19:56 | <AryehGregor> | I didn't recognize the quote on first glance. Clearly I need to replay Portal. |
| 19:56 | <erl[oberholz]> | err, the XSS detection. |
| 19:56 | <TabAtkins> | erl[oberholz]: The code that is trying to load includes a <script> tag to get IE to recognize <figure>, which I'm guessing IE recognizes in the url and kills |
| 19:57 | <AryehGregor> | Blast! The guy with nick "aryeh" logged on a week ago. Foiled! |
| 19:57 | AryehGregor | will have to wait another 67 days or so for his next chance |
| 19:57 | <TabAtkins> | AryehGregor: Heh, does registration last 75 days or something? |
| 19:58 | <erl[oberholz]> | TabAtkins, so essentially any javascript input for hixies DOM viewer will trigger IE8 XSS detection? |
| 19:58 | <TabAtkins> | erl[oberholz]: Dunno how general it is. I'd have to do some testing. |
| 19:58 | <AryehGregor> | You can ask to usurp a nick after 60 days of inactivity. I asked on his 60th day of inactivity, and was told that since his nick had been registered for two years, I had to wait another two weeks. |
| 19:58 | <AryehGregor> | Which he used to log on. >:( |
| 19:58 | <TabAtkins> | Sucks. I'll bet it sends an email. |
| 19:59 | <AryehGregor> | "it" being freenode staff? |
| 19:59 | AryehGregor | tries to think of another good nick |
| 19:59 | <AryehGregor> | aryehg? |
| 19:59 | <TabAtkins> | AryehGregor: I assumed NickServ was largely autonomous. Guess I was wrong. |
| 20:00 | <AryehGregor> | It is, but usurping isn't. |
| 20:00 | <TabAtkins> | erl[oberholz]: http://software.hixie.ch/utilities/js/live-dom-viewer/?<!doctype%20html><script></script>; |
| 20:00 | <TabAtkins> | Looks like it |
| 20:00 | <AryehGregor> | You need to ask staff. |
| 20:00 | <AryehGregor> | erl[oberholz], it's rather the point of the XSS detection thing that it raises alarms if it detects scripts being injected from the URL. |
| 20:00 | <AryehGregor> | That's practically the definition of XSS, after all. |
| 20:01 | <AryehGregor> | It just so happens that most of us don't have any useful cookies or such set on software.hixie.ch, so nobody's going to bother luring us there with malicious JS in the URL. |
| 20:01 | <erl[oberholz]> | hehe |
| 20:01 | <erl[oberholz]> | purrfect :D |
| 20:04 | <annodomini> | NoScript seems to block input to the DOM viewer, too. |
| 20:04 | <AryehGregor> | . . . maybe because it's script-based? |
| 20:05 | <annodomini> | NoScript is actually very aggressive about it; it strips out everything that looks like an HTML tag. |
| 20:05 | <annodomini> | (as part of its XSS blocking tools) |
| 20:10 | <annodomini> | So, is there any particular reason that <title> is the only required element in HTML? Is there a good reason that it's required? |
| 20:11 | <AryehGregor> | It would make test cases smaller if it weren't. |
| 20:11 | <AryehGregor> | (I mean, that's not a reason it's required, I'm agreeing with your question) |
| 20:11 | <annodomini> | Right. |
| 20:11 | <AryehGregor> | It's usually going to be an error if it's omitted, though. |
| 20:12 | <annodomini> | Well, there are lots of cases in which you can have a document but don't need a title. |
| 20:12 | <TabAtkins> | Thus all the <title>Untitled Document</title> pages on the web. |
| 20:12 | <annodomini> | For instance, HTML email, pages which are always intended to be framed (like gadgets), etc. |
| 20:12 | <annodomini> | Yeah. That seems to me to be about the equivalent of alt="img001" or whatever. |
| 20:13 | <annodomini> | It would be more useful not to have it, so if you really need a title, the browser could use the URL or a component of it, or maybe extract the top level heading, or something. |
| 20:14 | <erl[oberholz]> | interesting issue. |
| 20:14 | <erl[oberholz]> | i second annodomini. |
| 20:14 | <AryehGregor> | It's been discussed before a bunch of times. |
| 20:14 | <AryehGregor> | But I hadn't thought of iframes and such. |
| 20:14 | <AryehGregor> | You're right, it's really fairly pointless in those cases. |
| 20:14 | <erl[oberholz]> | AryehGregor, so what was the reason of keeping it? |
| 20:14 | <AryehGregor> | I dunno. |
| 20:14 | annodomini | starts searching through archives |
| 20:19 | <Steve^> | everything should have a title, tabs need them |
| 20:19 | <Steve^> | sure, the browser can make them up, but a developer created one is always better |
| 20:19 | <Steve^> | except maybe for gadgets |
| 20:20 | <AryehGregor> | Steve^, what about iframes? |
| 20:20 | <hsivonen> | :-( Shane thought my bug comment asking for an assertion to be substantiated was a troll |
| 20:20 | <AryehGregor> | What about test cases where nobody cares about the title? |
| 20:20 | <annodomini> | Existing thread on the issue: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020147.html |
| 20:20 | <Steve^> | AryehGregor, accessibility? |
| 20:20 | <AryehGregor> | Steve^, what about accessibility? |
| 20:20 | <annodomini> | Right. The reason I thought of it is that everyone uses test cases that lack titles. |
| 20:21 | <Steve^> | screen reader can use the title of the iframe content as a reference |
| 20:21 | <AryehGregor> | annodomini, I don't, but it's silly. |
| 20:21 | <AryehGregor> | hsivonen, you need to kill him for a failed assertion, obviously. |
| 20:21 | <AryehGregor> | Steve^, do they actually do that? |
| 20:21 | <AryehGregor> | This sounds like hidden metadata to me. |
| 20:21 | <annodomini> | Wouldn't it be better to just read the content of the iframe, and thus get the same content as sighted users? |
| 20:22 | <Steve^> | I don't know what they do, I just think about what they could do :) |
| 20:22 | <AryehGregor> | Steve^, bad approach, generally. |
| 20:22 | <hsivonen> | AryehGregor: I think failed assertions aren't even logged |
| 20:22 | <Steve^> | umm |
| 20:22 | <Steve^> | no? |
| 20:22 | <TabAtkins> | Hrm, Leif's point about IE6/7's treatment of <dt>/<dd> outside of <dl> is valid. This seems like a big problem. |
| 20:22 | <AryehGregor> | Because then you end up building your standard based on things that just don't happen. |
| 20:22 | <AryehGregor> | A fantasy world, essentially. Rather than actually making it useful. That's what XHTML 2 did. |
| 20:22 | <TabAtkins> | Though I can see how it was missed in testing - IE shows it with some properties, but not with background. |
| 20:22 | <AryehGregor> | hsivonen, you need to turn on debug mode, then. |
| 20:23 | <Steve^> | AryehGregor, I design for the future. I make sure that when screen readers and other user agents get better, my site has the information for it. What they do now is unimportant |
| 20:23 | <Steve^> | That would lead to zero development |
| 20:23 | <AryehGregor> | Steve^, great, so then they develop in a totally different direction and your effort is wasted. |
| 20:24 | <AryehGregor> | If you design for tomorrow, then your site will work tomorrow. |
| 20:24 | <AryehGregor> | It might not work ideally five years from now, but it probably wouldn't work ideally five years from now anyway, because who knows what five years from now will be like? |
| 20:24 | <Steve^> | Do any screen readers understand HTML sectioning/heading content yet? |
| 20:24 | <AryehGregor> | No idea, I know diddly-squat about screen readers. |
| 20:25 | <Steve^> | if not, I might as well strip out those silly <section> and <article> that I wasted my time on |
| 20:25 | <AryehGregor> | Those are specified in a current standard that multiple vendors have expressed interest in implementing. But if you aren't actually using them, sure, feel free to strip them out, probably won't change much. |
| 20:25 | <annodomini> | The question is, would reading the <title> of a page in an iframe help accessibility? |
| 20:26 | <AryehGregor> | Not the same as deciding on your own that screen readers might use <title> in <iframe> for something. |
| 20:26 | <Steve^> | annodomini, its much faster to read a title than the entire iframe |
| 20:26 | <hsivonen> | speaking of future proofing, Re: easlier discussion on vendor prefixes: vendor prefixes fail if one does -moz-border-radius: ...; -webkit-border-radius: ...; and then in anticipation boder-radius: ...;, too |
| 20:26 | <AryehGregor> | HTML5 was developed very broadly over a period of a few years. |
| 20:26 | <hsivonen> | *border-radius |
| 20:26 | <Steve^> | I expect the screenreader reads the title of the main page first, too |
| 20:26 | <annodomini> | If the author put the page into an iframe, they were intending people to see the content of the iframe, not the title. |
| 20:26 | <Steve^> | and the user can abort viewing at any time |
| 20:26 | <AryehGregor> | hsivonen, Mozilla apparently encourages that. At least there was one bug I read where they removed support for -moz-foo at the same time as adding support for foo. |
| 20:26 | <AryehGregor> | Or at least someone said they would. |
| 20:27 | <Steve^> | Can anyone give an example of a good iframe? I don't come across them much |
| 20:27 | <annodomini> | iframes are different than main frames, though. They are frequently used to transparently include content, that shouldn't appear to be any different than content from the main frame. |
| 20:27 | <annodomini> | They are frequently used for sandboxing untrusted code. |
| 20:27 | <Philip`> | Steve^: Adverts? |
| 20:28 | <Steve^> | perfect |
| 20:28 | <AryehGregor> | AFAIK, most screen readers try to scrape content from the screen to reconstruct what it would look like for sighted users. They ignore things that are set to display: none, for instance, because they wouldn't display visually. |
| 20:28 | <annodomini> | If you want to embed a random untrusted piece of flash or javascript in your blog, you can stick it in an iframe on a different domain, so it doesn't have access to your cookies. |
| 20:28 | <Steve^> | A sighted user can choose what on the screen they look at, avoiding adverts |
| 20:28 | <AryehGregor> | So I doubt they intentionally display content like an iframe's title that would be hidden in a normal browser. |
| 20:28 | <gsnedders> | annodomini: An iframe doesn't work as a sandbox |
| 20:29 | <Steve^> | titles would allow the user to see what the iframes hold and browse around, without parsing each document in its entirety |
| 20:29 | <gsnedders> | annodomini: You can just do parent.document.body.style.display = "none"; |
| 20:29 | <AryehGregor> | Yes, but the fact is practically nobody actually tests in or cares about screen readers, so if they do provide things meant to help screen readers, they usually get them totally wrong. |
| 20:29 | <annodomini> | If you stick it on a different domain? |
| 20:29 | <AryehGregor> | So screen readers ignore most of that stuff anyway AFAIK. |
| 20:29 | <gsnedders> | annodomini: Still works |
| 20:31 | <hsivonen> | hmm. it seems that Shane also missed the part were Othar from Google stated their intent to deviate from the spec |
| 20:32 | <annevk42> | he thinks it's just like HTML4 and therefore fine |
| 20:32 | <annevk42> | guess he didn't get the memo that implementors perceive HTML4 as not that great -- if not disaster |
| 20:35 | <annevk42> | it's funny how on the one hand the XHTML2/RDFa guys think everything should be pure and good but when it comes to the DOM it can all be a quick hack as long as it works |
| 20:36 | <annevk42> | it makes no sense whatsoever to me |
| 20:36 | <Philip`> | annevk42: Sounds like making the language nice and clean for users, even if implementers have to something a little hacky |
| 20:36 | <Philip`> | which is just a sensible priority of constituencies |
| 20:37 | <AryehGregor> | s/^.*(the XHTML2/RDFa guys).*$/$1/ and the next line still makes sense. :) |
| 20:37 | <erl[oberholz]> | AryehGregor, interesting. I used display:none on my accessability hooks. does that mean i should use the move it 1000em to the left hack ? |
| 20:37 | <AryehGregor> | erl[oberholz], that's what people usually do. |
| 20:38 | <TabAtkins> | erl[oberholz]: Yeah, that's what you should do. |
| 20:38 | <AryehGregor> | erl[oberholz], in general, I've found that trying to develop things for platform X without actually testing on platform X is a sure recipe for disaster. |
| 20:38 | <AryehGregor> | If you want to make your site work in screen readers, then get a screen reader and test it. |
| 20:38 | <AryehGregor> | Try to be clever and you'll probably make things worse. |
| 20:38 | <AryehGregor> | Because the screen readers are designed to gracefully handle pages that ignore the existence of screen readers. |
| 20:38 | <TabAtkins> | erl[oberholz]: I use that for my "Skip to content" link, for example. |
| 20:38 | <AryehGregor> | (this doesn't necessarily apply to following well-established advice, though) |
| 20:39 | <erl[oberholz]> | TabAtkins, i mean exactly that. (though HTML5 should make this non-necessary) |
| 20:39 | <TabAtkins> | erl[oberholz]: Because I can't organize my page to have all content at the top, unfortunately. CSS isn't mature enough quite yet for me. |
| 20:39 | <AryehGregor> | Personally, my vote is that we develop a general cure for blindness so we can forget about screen readers. All in favor, say aye. |
| 20:39 | <erl[oberholz]> | arrrr |
| 20:39 | <Steve^> | I'm busy, sorry AryehGregor good luck though |
| 20:40 | <TabAtkins> | Well, crap, this whole <figure><dt/></figure> issue seems to be just as bad as <figure><legend/></figure. |
| 20:40 | <AryehGregor> | TabAtkins, MediaWiki has all content at the top of the HTML source, but it doesn't help screen readers, since they execute the CSS. I once had a guy come in asking for help getting his site for blind people to work better, and he said "just tell me where all the CSS is so I can delete it". |
| 20:40 | <Steve^> | I have a feeling that screenreaders do read display: none sections |
| 20:40 | <TabAtkins> | I suppose the damage is somewhat less widespread, but it's still going to be useless for many years. |
| 20:40 | <annodomini> | Steve^: no, they don't |
| 20:41 | <AryehGregor> | Steve^, not what I've been told by blind people or multiple web design essays. |
| 20:41 | <annodomini> | That's why if you want to hide text from sighted users but have it accessible to blind users, you generally give it something like a -9999px margin |
| 20:41 | <TabAtkins> | Or abspos it and set left:-9000px |
| 20:42 | <AryehGregor> | I wonder if screen readers will start figuring that out and not reading it at some point. |
| 20:42 | <annodomini> | gsnedders: Firefox, Safari, and Opera all agree that an iframe doesn't get to mess with its parent: http://ephemera.continuation.org/cross-domain-iframe.html |
| 20:42 | <TabAtkins> | God, I hope not, AryehGregor. |
| 20:42 | <Steve^> | why would they not render it? It is information they want to show? |
| 20:43 | <gsnedders> | annodomini: Oh, and the sandbox attribute only changed same-origin stuff |
| 20:43 | <Steve^> | why is this not in the HTML5 spec? |
| 20:43 | <Steve^> | display: non-visual; |
| 20:43 | <AryehGregor> | Why is what not in the HTML5 spec? |
| 20:43 | <AryehGregor> | . . . |
| 20:43 | <Steve^> | or something clever |
| 20:43 | <AryehGregor> | It's CSS, not HTML. |
| 20:43 | <annodomini> | That would go into CSS, not HTML |
| 20:44 | <AryehGregor> | And there are audio stylesheets for this. |
| 20:44 | <AryehGregor> | Which screen readers ignore. |
| 20:44 | <AryehGregor> | (most screen readers) |
| 20:44 | <AryehGregor> | Because they know what they want to display a lot better than the average web author. |
| 20:44 | <annodomini> | But yeah, I think that would be a good idea, to stop the -9000 px margin hacks. |
| 20:45 | <AryehGregor> | annodomini, http://www.w3.org/TR/CSS2/aural.html |
| 20:45 | <AryehGregor> | display: none; speak: normal; |
| 20:45 | <Steve^> | Is there a reason everyone said -9000 and not -10000? |
| 20:45 | <TabAtkins> | My hope is that since display:none is so easy, we devs will keep doing it for things we want hidden from everyone, and the margin-left:-9000px and position:absolute;left:-9000px hacks will always continue working. |
| 20:46 | <TabAtkins> | Steve^, I dunno. I picked it up when I first learned the technique from whatever blog I read. |
| 20:46 | <annodomini> | Steve^: No real good reason I know of. |
| 20:46 | <Steve^> | How about the HTML5 outline algorithm. Does that care about display: hidden? Are screenreaders likely to when they implement it? |
| 20:47 | <AryehGregor> | Steve^, HTML is not affected by CSS, ever. |
| 20:47 | <AryehGregor> | I mean, the semantics of HTML. |
| 20:47 | <AryehGregor> | Like section outline. |
| 20:47 | <Steve^> | I use hidden headings on my navigation elements, so that the outline makes more sense, but the user shouldn't see them for style reasons |
| 20:47 | <AryehGregor> | Do we have reason to believe that screen readers will actually implement the section outline algorithm? |
| 20:48 | <AryehGregor> | Steve^, MediaWiki does that for some of the navigation stuff. |
| 20:48 | <TabAtkins> | I'll be happy when CSS implements the section outline algorithm and gives us :heading() (and maybe ::section()) |
| 20:48 | <annodomini> | The outline algorithm picks out a set of nodes. Once you get those, you have to decide what to do with them. You might decide to present al of them, or you might decide not to present ones that have display: none |
| 20:48 | <Steve^> | hmm true |
| 20:49 | <Steve^> | screenreaders should implement it, its a handy way to navigate a document. But you don't want them navigating to areas that are hidden |
| 20:49 | <Steve^> | so my hidden headings will need to be -10000px too |
| 20:50 | <annodomini> | But because web app authors frequently use display: none to hide stuff that doesn't make sense to display, it usually doesn't make sense to read them either. So yeah, if you want things to be accessible to the screenreader, you need to use the negative margin hack. |
| 20:50 | <annevk42> | Philip`, users deal with the DOM, surely |
| 20:51 | <Steve^> | annodomini, why do they frequently do that? |
| 20:51 | <TabAtkins> | display:none is the poor man's way to remove elements from the DOM, basically. |
| 20:52 | <Steve^> | You could use javascript for a tabbed effect, that would toggle the display |
| 20:52 | <TabAtkins> | So. Yes. <dt> in <figure> is at the same level of brokenness as <legend> in <figure>. We didn't gain anything by switching. |
| 20:52 | <TabAtkins> | Steve^: That is in fact the common way to do things. |
| 20:53 | <Steve^> | if this is purely a CSS problem, then ok |
| 20:53 | <Steve^> | but if HTML can help, then its worth considering now |
| 20:54 | <Steve^> | just like alt is purely for accessibility |
| 20:54 | <annevk42> | <dt> doesn't work? |
| 20:54 | <TabAtkins> | annevk42: Not in ie6 or ie7, for a lot of CSS properties. |
| 20:54 | <TabAtkins> | It forms a good DOM, but display is totally broken. |
| 20:55 | <annevk42> | and a different element does work? |
| 20:55 | <TabAtkins> | Yup. |
| 20:55 | <annevk42> | why is that? |
| 20:55 | <TabAtkins> | It's something special about encounting a <dt>/<dd> outside of a <dl>. |
| 20:55 | <annevk42> | aah, wow |
| 20:55 | <TabAtkins> | I just put a message on the html-wg list with a testcase. |
| 20:56 | <othermaciej> | yikes |
| 20:56 | <othermaciej> | I guess we should have tested <dt> / <dd> |
| 20:56 | <Steve^> | lol |
| 20:56 | <TabAtkins> | Really Leif's discovery, but I trimmed down his case to something minimal. |
| 20:57 | <Steve^> | is the fieldset legend being changed? |
| 20:57 | <TabAtkins> | Hm? We don't do anything new with <fieldset><legend> now. |
| 20:59 | <annevk42> | but it works in ie8? |
| 20:59 | <TabAtkins> | Yup. |
| 20:59 | <annevk42> | might be good enough |
| 21:00 | <TabAtkins> | It's forward compatible, it seems, but it's still broken enough in legacy stuff that it won't be usable for years yet. |
| 21:00 | <TabAtkins> | Unless you decide that you just plain don't want to set borders or font properties on your captions / <details> togglers. |
| 21:01 | <AryehGregor> | TabAtkins, I don't see your post . . . |
| 21:01 | <AryehGregor> | Oh, I muted that conversation. |
| 21:01 | <TabAtkins> | AryehGregor: It threaded itself weirdly, it seems. |
| 21:01 | <TabAtkins> | Heh, k. |
| 21:01 | <TabAtkins> | Should I make it a top-level post? |
| 21:03 | <TabAtkins> | Steve^: (returning to the hiding/screenreaders thing) Ideally we'd be able to use nothing but @hidden to indicate content that we're leaving in the DOM, but that shouldn't be looked at by anyone, and return to display:none being read by screen-readers. of course that's never going to happen. |
| 21:04 | <othermaciej> | TabAtkins: so you can't change the font of a <dt> outside a <dl>? But you can if it is inside a <dl>? that is way weird |
| 21:04 | <TabAtkins> | othermaciej: Nah, you can change it, but those properties then apply *to the entire rest of the document*, as if everything was a child of the <dt>. |
| 21:04 | <TabAtkins> | It's really obvious when you set a border, as well, as it wraps the rest of the document in the border. |
| 21:05 | <Steve^> | a new element is way better than stuffing compatibility that much |
| 21:05 | <TabAtkins> | I suspect IE's creating something that's not a tree for CSS purposes. |
| 21:05 | <othermaciej> | TabAtkins: whoah. |
| 21:07 | <TabAtkins> | So, yeah. I definitely expect to set font and borders on my <details> toggler, so this'll render it unusable for me for a long time. I'm not sure what the full list of crazy-inheritance properties are, too, so there may be more ridiculosity. |
| 21:10 | <othermaciej> | reading <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7670>; is entertaining |
| 21:10 | <annevk42> | is the hixie vs pro-prefix guys? |
| 21:10 | <annevk42> | s/the/that/ |
| 21:12 | <TabAtkins> | annevk42: yeah |
| 21:13 | <hober> | I really need to finish up my ranty blog post about prefix-indirection mechanisms |
| 21:13 | <Steve^> | RDFa is too complicated from my brief view of it |
| 21:13 | annevk42 | was amused too |
| 21:14 | <annevk42> | good start of the weekend |
| 21:14 | <Philip`> | RDFa is too complicated from my relatively extensive view of it |
| 21:14 | <hober> | it'll be the essay form of http://edward.oconnor.cx/2009/BarCamp-San-Diego-5/ (sorry, no 'previous slide' functionality in that deck) |
| 21:19 | <Steve^> | microdata doesn't even have a wikipedia page |
| 21:21 | <Hixie> | nor do most HTML5 features :-) |
| 21:24 | <TabAtkins> | k, I've sent the <dt> issue as a top-level thread, so people who've already muted the bikeshed conversations will be able to see it. ^_^ |
| 21:25 | <hsivonen> | Hixie: Wikipedia interprets your mozilla.org involvement as employment by Mozilla Foundation. that's incorrect, right? |
| 21:25 | <Hixie> | yeah i was employed by netscape for a year but other than that was just a mozilla contributor |
| 21:25 | <Hixie> | still am, occasionally :-) |
| 21:28 | gsnedders | sighs, biting his lip, wondering what to do |
| 21:28 | <TabAtkins> | gsnedders: Bite harder. |
| 21:29 | <gsnedders> | TabAtkins: I don't like the taste of blood, so no. |
| 21:29 | <Hixie> | hmm |
| 21:30 | <hsivonen> | Hixie: fixed |
| 21:30 | Hixie | ponders how to make the relextensions, metaextensions, and so on work |
| 21:30 | <Hixie> | hsivonen: thanks |
| 21:31 | <Hixie> | not that i'm particularly worried about what it says :-) |
| 21:32 | gsnedders | wishes he didn't have to make any decisions that had consequences for a prolonged period, ever |
| 21:33 | <Hixie> | you likely couldn't be especially useful to the human race or the universe as a whole if you didn't have to make decisions of consequence :-) |
| 21:33 | <TabAtkins> | gsnedders: In all seriousness, just go with whichever feels the best. If you have the ability to research the decision, do so, but don't stress overly much about it. You'll miss opportunities whichever way you decide, so just pick whichever feels best and don't look back. |
| 21:33 | <othermaciej> | gsnedders: what's your tough decision? |
| 21:33 | <gsnedders> | TabAtkins: I don't think you realize what sort of decision this is :) |
| 21:33 | <Hixie> | MetaExtensions, RelExtensions, and PragmaExtensions |
| 21:33 | <Hixie> | how should they work? |
| 21:34 | <othermaciej> | if I knew, I would have told you already |
| 21:35 | <and> | In case anyone is interested, the reasoning behind EOF inside tags causing the tag to be dropped are in <http://lists.w3.org/Archives/Public/public-html/2009Mar/0260.html>;. |
| 21:35 | <and> | I forgot (at least) two issues yesterday: |
| 21:35 | <gsnedders> | othermaciej: Whether to tell one of my friends some things about his gf or not, which will almost certainly end any relationship between them. I know if I don't and if he ends up hurt (which I expect will happen) I'll blame myself for not doing anything, and if I do anything I'll be construed purely as jealous, and be disliked by some of my friends for splitting them up. |
| 21:36 | <and> | 5) Are the different tokens emitted by the tokeniser defined anywhere? |
| 21:36 | <and> | 6) At which point do attributes in end tags cause a parse error? |
| 21:36 | <gsnedders> | 6) Any |
| 21:36 | <gsnedders> | Actually, I think when they are emitted. |
| 21:37 | <TabAtkins> | gsnedders: imxp, telling is usually better if it's something that the other person would actually like to know, had they the ability to (like someone cheating). It can still cause a lot of hurt feelings, but shrug. Gotta choose one way or the other. |
| 21:37 | <othermaciej> | gsnedders: sounds like something I shouldn't ask about further in a logged IRC channel |
| 21:37 | <hsivonen> | gsnedders: when emitted |
| 21:37 | <gsnedders> | othermaciej: Indeed :) |
| 21:37 | <gsnedders> | othermaciej: I was wondering for a while how to phrase it vaguely enough :) |
| 21:38 | <gsnedders> | TabAtkins: That'd be all right if it were as simple as what I made it seem, but I don't really want to be exact in a logged IRC channel. |
| 21:38 | <AryehGregor> | gsnedders, you could tell him anonymously so you don't look jealous. |
| 21:39 | <TabAtkins> | gsnedders: Wanna take it to private channel? |
| 21:39 | <gsnedders> | Like #omggsnedders? |
| 21:39 | <AryehGregor> | Obviously we need to start #gf-of-friend-of-gsnedders and reach consensus there before taking any action. |
| 21:39 | <AryehGregor> | Votes may be involved. |
| 21:39 | <gsnedders> | I was originally going to go for #omggsneddersisonaboutagirlagain |
| 21:40 | <gsnedders> | But that's over the length limit |
| 21:40 | <and> | Thanks. |
| 21:40 | <gsnedders> | and: 5) AFAIK No |
| 21:44 | gsnedders | heads off to #omggsnedders |
| 21:45 | <and> | They are defined, actually. (Wonder how I missed that.) End tag tokens even have attributes. |
| 21:47 | and | was surprised to find that &nbsb accounts for 88% of all unterminated character references in the dotnetdotcom dataset. |
| 21:47 | <and> | *nbsp |
| 21:50 | <jcranmer> | that low? |
| 21:50 | <Philip`> | and: Presumably based on combined number of occurrences, not number of pages? |
| 21:50 | <and> | Yes, but even so. |
| 21:50 | <Philip`> | Actually, I suppose that's an unjustified presumption |
| 21:50 | <Philip`> | because the most common error is <a href=foo?x=1&y=2> but that's going to be spread over a wide range of strings |
| 21:52 | <and> | Only those that are interpreted as characters (according to HTML5 and IE) are counted. |
| 21:52 | <Philip`> | Ah |
| 21:52 | <and> | Next step will be to look at the ones which could have been. |
| 21:52 | <Philip`> | (Hmm, the only similar data I seem to have is http://philip.html5.org/data/entities-without-semicolon-followed-by-equals.txt which isn't very relevant) |
| 22:17 | <TabAtkins> | Is there reason to believe that <a ping> won't work? |
| 22:17 | <TabAtkins> | Is it fear that browser vendors won't implement it? |
| 22:21 | <othermaciej> | "won't work" in what sense? |
| 22:22 | <othermaciej> | there are two ISSUEs outlining specific objections |
| 22:22 | TabAtkins | goes to look them up. |
| 22:22 | <othermaciej> | http://www.w3.org/html/wg/tracker/issues/1 |
| 22:22 | <othermaciej> | http://www.w3.org/html/wg/tracker/issues/2 |
| 22:22 | <TabAtkins> | I'm just going on Julian's objection in the latest comment to that bug. |
| 22:24 | <TabAtkins> | Ooh, didn't realize that FF had implemented ping. |
| 22:26 | <othermaciej> | they did, but their implementation is disabled currently |
| 22:26 | <othermaciej> | it's also been proposed for WebKit (and thus for Chrome and Safari) |
| 22:26 | <othermaciej> | so far we have no public expression of interest from content authors |
| 22:26 | <TabAtkins> | You can have one now: I'd like it. |
| 22:27 | <othermaciej> | which means browsers that implement it may be accused of privacy badness, but without delivering an actual user experience benefit |
| 22:27 | <othermaciej> | you should post to that effect on public-html, though it would carry more weight if it was from a major web site... |
| 22:27 | <TabAtkins> | Specifically for the purpose of tracking how often particular resources are requested, so we can tell which instructional PDFs are most popular and do more along that vein. |
| 22:28 | <TabAtkins> | Well, I can say it as my company's webmaster. ^_^ |
| 22:29 | <Hixie> | i just redefined how the registries work |
| 22:30 | <Hixie> | if anyone wants to go ahead and act as gardener for the wiki pages, please go ahead |
| 22:30 | <Hixie> | the new process is a lot simpler |
| 23:21 | <alyoshka> | since dd has padding already, wouldn't it make sense to drop the details {padding-left: 40px;} when emulating support in current browsers? |
| 23:22 | <alyoshka> | using padding-left in IE 7 makes for some really weird behavior |
| 23:22 | <AryehGregor> | dd in details is probably going to die, see TabAtkins' post to the list. |
| 23:23 | <TabAtkins> | The weird behavior you notice is probably a result of the behavior noted in my post (discovered by Leif, not me). |
| 23:23 | <TabAtkins> | And yes, confirmed. |
| 23:24 | <alyoshka> | most likely; I haven't done thorough testing, but details/dt/dd does some very weird things in my basic tests so far |
| 23:27 | <TabAtkins> | Yeah, it's because IE6 and 7, whenever they encounter a dd or dt not in a dl, treat the entire rest of the document as children of the dt/dl for CSS purposes. |
| 23:29 | <TabAtkins> | Or rather, upon further testing, treat the rest of the document *up to the next dt/dd* as being children. |
| 23:29 | <alyoshka> | yeah, that's true, though IE 7 seems to have it worse than IE 6. Thing is, it has other problems in those browsers as well as Konqueror |
| 23:29 | <TabAtkins> | (and then that next dt/dd treats the next section as children) |
| 23:29 | <TabAtkins> | What other problems? |
| 23:30 | <alyoshka> | it has strange interactions with real <dl>s |
| 23:30 | <alyoshka> | though I haven't nailed the exact problem yet |
| 23:31 | <alyoshka> | I'm suspecting it could cause further trouble in more complex documents later, so I didn't see much point in testing further |
| 23:45 | <alyoshka> | TabAtkins: where can I read your post about it. I didn't find it in the mailing list archives for some reason. |
| 23:45 | <TabAtkins> | Are you looking in the whatwg archives or the html-wg archives? It's in the latter. |
| 23:45 | <alyoshka> | whatwg :D |
| 23:45 | <alyoshka> | thanks |