| 05:50 | <Hixie> | http://www.precentral.net/html5-editors-draft-hits-w3c-flash-doesnt-break-sweat |
| 05:50 | <Hixie> | "The HTML5 specification came another step closer to becoming a Web standard today, as the first editors draft of the technology was released to the World Wide Web Consortium." |
| 05:50 | <Hixie> | Tuesday, Feb 2, 2010 |
| 05:50 | <Hixie> | ... |
| 05:50 | <Hixie> | first? o_O |
| 05:50 | <Dashiva> | Released _to_ |
| 05:51 | <othermaciej> | Hixie: wait, what? |
| 05:52 | <Hixie> | indeed |
| 05:53 | <othermaciej> | that might even qualify as the most astonishing sentence I've read all weekend |
| 05:55 | <Dashiva> | Is the file extension really going to be .sandboxed? |
| 05:56 | <Hixie> | Dashiva: URIs don't have file extensions |
| 05:58 | <Dashiva> | Looking at http://dev.w3.org/html5/spec/iana.html#text-html-sandboxed |
| 06:05 | <Hixie> | ah well yeah the IANA asks for a filename for some reason |
| 06:05 | <Hixie> | http://lists.w3.org/Archives/Member/w3c-archive/2010Feb/0082.html is pretty fantastic |
| 06:06 | <Hixie> | especially the baseless accusation in sentence two of paragraph one |
| 06:06 | <Dashiva> | And its fantasticness will be amplified in the minds of all the non-members who can only imagine what it says :) |
| 06:06 | <Hixie> | i also love the way the author of that thread always makes sure to take their complaints out of the public eye |
| 06:07 | <Hixie> | it's like they realise that they'd be lambasted if they made that kind of accusation in public |
| 06:07 | <Dashiva> | That's what formal process is for, avoiding accusations based on common sense |
| 06:07 | <Dashiva> | Good morning, zcorpan |
| 06:09 | <zcorpan> | good morning Dashiva |
| 06:09 | <zcorpan> | had a good weekend? |
| 06:10 | <Dashiva> | I have no complaints, at least :) |
| 06:11 | <zcorpan> | great |
| 06:13 | <othermaciej> | Hixie: I actually hadn't read that message yet, was trying to take some time off from that thread |
| 06:14 | <Hixie> | don't blame you |
| 06:15 | <Hixie> | i noticed that i was cc'ed on a later w3c-archive thread so i figured i should check if anything else had been going on |
| 06:15 | <Hixie> | imagine my surprise! |
| 06:55 | <gsnedders> | w3c-archive? Oh great. |
| 06:55 | <gsnedders> | You can tell things are going well when they end up _there_. |
| 06:55 | <gsnedders> | (w00t for MO lists) |
| 06:58 | <othermaciej> | gsnedders: are you empowered to see MO content? |
| 06:58 | <gsnedders> | othermaciej: I'm an Opera rep, so yes |
| 06:59 | <othermaciej> | it's interesting because almost all the content on that list is from sysbot |
| 06:59 | <gsnedders> | Yeah, it always surprises me how scarce content is there |
| 07:00 | <gsnedders> | (excluding sysbot) |
| 07:09 | <abarth> | Hixie: is http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024335.html a bug in the spec? i wasn't sure if i read it right |
| 07:10 | <Hixie> | looks like a bug |
| 07:10 | <Hixie> | haven't fixed it yet |
| 07:10 | <Hixie> | it's on the pile |
| 07:10 | <abarth> | ok, thanks |
| 07:11 | <othermaciej> | are PUT and DELETE only allowed as methods for same-origin form actions in the first place? |
| 07:11 | <abarth> | yes, but the spec doesn't seem to stop redirects |
| 07:11 | <abarth> | 307 |
| 07:11 | <othermaciej> | that does sound like it would subvert the requirement |
| 07:12 | <abarth> | i don't think anyone implements that currently |
| 07:12 | <abarth> | but it's probably good to fix :) |
| 07:14 | <othermaciej> | now here's something that gives me hope: http://mediadecoder.blogs.nytimes.com/2010/02/07/how-the-letterman-oprah-leno-super-bowl-ad-came-together/ |
| 07:14 | <othermaciej> | if Jay Leno and David Letterman can get along, maybe we can publish a technical specification without killing each other |
| 07:20 | <gsnedders> | Javascript URIs behave as if they're same-origin, right? |
| 07:24 | <zcorpan> | hmm, webkit linebreaks (if necessary) for <nobr>foooo<wbr>baaaaar</nobr> |
| 07:24 | <zcorpan> | but firefox doesn't |
| 07:25 | <zcorpan> | gsnedders: depends on where you use javascript urls |
| 07:25 | <gsnedders> | zcorpan: iframe@src |
| 07:25 | <zcorpan> | yep |
| 07:25 | <zcorpan> | iirc |
| 07:26 | <nessy> | othermaciej - I've seen no killing yet, just loud animals - and they are everywhere ;) |
| 07:33 | <hsivonen> | hmm. so it looks like one of the threads on public-html make a comeback from w3c-archive |
| 07:35 | <hsivonen> | I think I don't like the pattern of taking HTML WG threads into the Member archive space |
| 07:36 | <hsivonen> | anyway, I recommend that people who do have Member access check out what kind of stuff gets taken off-public-html in a way that cannot stay public in www-archive but doesn't go totally person-to-person, either |
| 07:37 | <gsnedders> | Things vanishing into an effective black-hole seems really bad |
| 08:21 | <si-p> | jgraham: thanks for the reply - I'm using 0.11, tip of the default branch from https://html5lib.googlecode.com/hg/ |
| 08:24 | <si-p> | jgraham: just installed to a fresh environment and the first problem I get is http://paste.pocoo.org/show/175252/ |
| 08:25 | <si-p> | jgraham: this issue has been mentioned on the mailing list so I altered the code to catch the ValueError exception and continue |
| 08:25 | <si-p> | jgraham: and the tests complete, but lots of errors |
| 08:27 | <gsnedders> | si-p: 0.90 should be tip… |
| 08:28 | <gsnedders> | si-p: That error is caused by SimpleJSON being stricter than the spec |
| 08:29 | <si-p> | gsnedders: thanks, I'll try 0.9 |
| 08:31 | <gsnedders> | si-p: What revision is tip at for you? |
| 08:32 | <gsnedders> | si-p: And what sort of errors are you getting? |
| 08:34 | <si-p> | gsnedders: tip is 1512:f4ce29fce65f |
| 08:35 | <gsnedders> | OK, that's what it should be |
| 08:35 | <gsnedders> | Which is identical to 0.90 release. |
| 08:35 | <si-p> | are there any tests for 0.9? |
| 08:35 | <gsnedders> | 0.9 != 0.90 |
| 08:36 | <si-p> | oh |
| 08:42 | <si-p> | gsnedders: is the tip of the default branch the code I should be using? |
| 08:42 | <gsnedders> | Yeah |
| 08:42 | <si-p> | gsnedders: I'm not the best with mercurial |
| 08:43 | <si-p> | ok and the SimpleJSON errors are expected? |
| 08:44 | <gsnedders> | Yeah |
| 09:37 | <si-p> | gsnedders, jgraham: tests are passing ok now, thanks |
| 09:37 | <si-p> | the reason for running the tests was because I had a parse error on a html file, but that looks to have cleared up also |
| 10:10 | Hixie | tries to deal with some feedback from bz about <object>, type sniffing, MIME types, and so forth, and goes cross-eyed trying to work out what the algorithm should be |
| 10:12 | <hsivonen> | mxr ftw |
| 10:13 | <zcorpan> | 1. Go to step 2 (fallback). |
| 10:14 | <zcorpan> | apparently webkit takes type information for <object> from <param name=type> |
| 10:18 | <Hixie> | yeah i'm not even going to that level of wackiness |
| 10:19 | <Hixie> | my whiteboard is already full just with MIME vs type vs sniffing vs extension |
| 10:22 | <zcorpan> | we might have to copy webkit on that for compat with banks that use java |
| 10:22 | <Hixie> | if you do, file a bug |
| 10:23 | <Hixie> | in the meantime, file a bug on webkit to remove their magic :-) |
| 10:23 | <zcorpan> | we'll try to figure out what to do first |
| 10:59 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/temp |
| 10:59 | <Hixie> | I think that's what I have to spec. |
| 10:59 | <Hixie> | to replace the "Determine the resource type, as follows" algorithm |
| 12:28 | <benjoffe> | The webstorage spec appears ambiguous: http://dev.w3.org/html5/webstorage/, consider the following: |
| 12:28 | <benjoffe> | storage.setItem("0", "foo"); |
| 12:28 | <benjoffe> | alert(storage[0]); |
| 12:29 | <Hixie> | webidl defines the precedence order |
| 12:38 | <si-p> | gsnedders: any idea why I get this_should_never_appear_publicly element in the tree after parsing? |
| 12:38 | <gsnedders> | If that's the element I think it is, because I created a bug. |
| 12:39 | <gsnedders> | Oh, no, not my bug. |
| 12:39 | <gsnedders> | Um, what's the input? File a bug on that. |
| 12:41 | <si-p> | tostring(html5lib.parse('<html></html>', treebuilder="lxml")) |
| 12:41 | <si-p> | produces |
| 12:41 | <si-p> | '<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">\n<html:html xmlns:html="http://www.w3.org/1999/xhtml"><body><this_should_never_appear_publicly/></body><html:head/><html:body/></html:html>; |
| 12:42 | <gsnedders> | Um, that's bad. |
| 12:42 | <Philip`> | What version of lxml? |
| 12:43 | <si-p> | dont understand how the tests are passing |
| 12:43 | jgraham | has never seen that |
| 12:43 | <gsnedders> | I don't understand how that element can get there |
| 12:43 | <si-p> | lxml-2.3dev-py2.6-linux-i686.egg |
| 12:44 | <Philip`> | What is tostring? |
| 12:44 | <benjoffe> | Hixie: are you sure it is defined? "If an object implements more than one interface that defines a given special operation, then it is undefined which (if any) special operation is invoked." |
| 12:44 | <si-p> | lxml.etree.tostring |
| 12:45 | <Philip`> | Ah |
| 12:45 | <Philip`> | I get '<html:html xmlns:html="http://www.w3.org/1999/xhtml"><html:head/><html:body/></html:html>'; |
| 12:45 | <Philip`> | with lxml 2.2.2, I think |
| 12:46 | <si-p> | this isn't a lxml problem though is it? |
| 12:46 | <Philip`> | I'd presume it's a change in lxml's behaviour |
| 12:47 | <Hixie> | benjoffe: there's only one interface involved here though right? |
| 12:47 | <jgraham> | I get the right output with lxml 2.2.4 |
| 12:47 | <Philip`> | (Not necessarily lxml's problem - html5lib might be relying on non-guaranteed behaviour here) |
| 12:47 | <jgraham> | So it seems like a 2.3 change |
| 12:47 | <Philip`> | (although arguably it's lxml's problem that html5lib has to rely on non-guaranteed behaviour) |
| 12:48 | <benjoffe> | Hixie: right, i just can't see where in webidl that is actually defined |
| 12:50 | jgraham | has no recollection of why that magic tag has to be inserted |
| 12:51 | <gsnedders> | jgraham: Creating a DOCTYPE is impossible in lxml apart from at parse-time |
| 12:53 | <jgraham> | gsnedders: Yes, I remember that much |
| 12:54 | <gsnedders> | jgraham: And to parse anything you need a well-formed XML document, which requires a root element |
| 12:54 | <gsnedders> | The point of calling it that and not "html" is to make sure the tag name is correctly changed |
| 12:54 | <Hixie> | benjoffe: in the [Get] definition, probably. |
| 12:55 | <Hixie> | benjoffe: if it's not defined, see the status section of the webidl spec for where to send comments |
| 12:55 | <Hixie> | so that we can get it defined :-) |
| 12:57 | <jgraham> | gsnedders: But won't lxml complain about the mismatch between <!doctype html> and the root element name? |
| 12:57 | <jgraham> | (well obviously it didn't, but they are supposed to match, no) |
| 12:57 | <gsnedders> | jgraham: no, that's a validity constraint, not a well-formedness constraint |
| 12:57 | <gsnedders> | jgraham: It only enforces valdiity constraints if you enable them. |
| 12:58 | <jgraham> | gsnedders: But the whole point of doing things like this was to get the right information into the dtd object |
| 12:58 | <jgraham> | Do we actually get that right now? |
| 12:59 | <gsnedders> | AFAIK yes |
| 12:59 | <jgraham> | it looks like we at least partially do |
| 12:59 | <jgraham> | in 2.2.x at least |
| 13:01 | <si-p> | is the workaround to downgrade lxml? |
| 13:01 | <jgraham> | si-p: Hopefully that will work |
| 13:02 | <si-p> | ok thanks |
| 13:03 | <gsnedders> | What I really don't get is how it ends up as a child of body |
| 13:05 | <si-p> | gsnedders: it's done in one of the parse phases |
| 13:06 | <gsnedders> | None should move the root element, ever |
| 13:09 | <annevk> | -> in Oslo |
| 13:09 | <gsnedders> | Now that I've run away :P |
| 13:12 | <annevk> | seemed better that way |
| 13:19 | <si-p> | yeah, downgrading lxml sorts it |
| 13:20 | <jgraham> | si-p: Could you file a bug please? I will try to investigate |
| 13:22 | <si-p> | jgraham: on code.google.com? |
| 13:22 | <jgraham> | si-p: Yes |
| 13:22 | <si-p> | jgraham: ok |
| 13:29 | <jgraham> | si-p: Thanks |
| 13:44 | <si-p> | jgraham: done, issue 136 :) |
| 14:06 | <annevk> | is anyone actually ever using the filtering options HTML5 tracker provides? |
| 14:06 | <annevk> | I personally just find the color coding useful but the form feels like clutter |
| 14:10 | <hsivonen> | annevk: I've sometimes used the tools and conformance checker filters |
| 14:11 | <hsivonen> | annevk: though more often using my forked script than your instance |
| 14:12 | <annevk> | I'm going to comment it out and see who starts yelling |
| 14:19 | <annevk> | cleaned up http://html5.org/tools/web-apps-tracker a little bit |
| 14:19 | <annevk> | arguably it should be called Web Applications 1.0 Revision Tracker but this seems good enough |
| 14:36 | <hsivonen> | grrr. I had forgotten Java has a 2^16 byte limit for the size of the static initializer |
| 15:41 | <TabAtkins> | Does this page die with a character encoding error on line 2 for any of you? www.weitz.de/hunchentoot |
| 15:41 | <TabAtkins> | It does for me in Chrome/Win if I force it to interpret as utf-8 |
| 16:03 | <daedb> | TabAtkins: It dies on line 150 for me (with forced utf-8). |
| 16:03 | <TabAtkins> | How bizarre. |
| 16:03 | <daedb> | That's in Opera/win, btw |
| 16:05 | <annevk> | why bizarre? |
| 16:07 | <annevk> | line 150 has "í" as character which will clearly fail your XML if you try to decode it using UTF-8 |
| 16:07 | <TabAtkins> | Ah, right. My eye passed over that. |
| 16:07 | <TabAtkins> | Wondering why I get an error on line 2, on the ? that ends the PI. |
| 16:08 | <TabAtkins> | Someone else gets an error on line 2 with the opening ?. |
| 16:08 | <annevk> | maybe because the encoding label is considered wrong? |
| 16:09 | <annevk> | browsers should disable the character menu for anything but text/plain and text/html I think |
| 16:11 | <TabAtkins> | Oddly enough, Firefox claims it's interpreting the page as utf-8, but doesn't die. |
| 16:11 | <annevk> | does that version of Firefox fail Acid3? |
| 16:12 | <TabAtkins> | Yeah, I only get a 92 on Acid3. |
| 16:12 | <annevk> | pre-Acid3 browsers have "broken" XML pipelines |
| 16:12 | <TabAtkins> | This is current 3.6, though. |
| 16:12 | <annevk> | the part that does character decoding is not aware of XML restrictions; Acid3 got that aligned with the XML spec |
| 16:51 | <si-p> | jgraham: hmm, looks like this lxml/html5lib issue may be my fault |
| 16:51 | <si-p> | jgraham: at the bottom of one of my modules I'd set the default parser for lxml |
| 16:51 | <si-p> | jgraham: and this seems to have been causing the issue |
| 16:52 | <si-p> | jgraham: still looking at it, but I may close the bug report |
| 16:53 | <annevk> | hmm |
| 16:53 | <annevk> | maybe I can use HTML5 fetch in XMLHttpRequest after all |
| 16:53 | <annevk> | if I use the "pause" concept for the sync case |
| 16:56 | <annevk> | it would be nice since fetch defines a lot of details |
| 16:57 | annevk | hopes Hixie can answer the question ^^ |
| 16:58 | gsnedders | finds yet another ECMAScript spec bug |
| 17:00 | <gsnedders> | This is somewhat depressing. |
| 17:01 | <gsnedders> | I look at the spec for around ten minutes and find four places that are wrong. |
| 17:01 | <gsnedders> | (Where wrong is defined as disagreeing with all implementations in a way that implementations cannot realisitically change) |
| 17:01 | <Dashiva> | es3 or es5? |
| 17:02 | <gsnedders> | Dashiva: es5 |
| 17:02 | <gsnedders> | Dashiva: Though these issues seem to exist in ES3 too |
| 17:04 | <jgraham> | gsnedders: You have been looking for more than 10 minutes :) |
| 17:04 | <jgraham> | (but agreed it is depressing) |
| 17:05 | <gsnedders> | jgraham: Time flies when you're having fun! |
| 17:05 | <gsnedders> | (I must be a sick masochistic lion…) |
| 17:07 | <jgraham> | That's a song from the Wizard of Oz, right? |
| 17:09 | <gsnedders> | What is? |
| 17:09 | <jgraham> | "I must be a sick masochistic lion" |
| 17:09 | <gsnedders> | No |
| 17:09 | <jgraham> | I realise |
| 17:09 | <jgraham> | It was funny |
| 17:09 | <jgraham> | In my mind |
| 17:10 | <gsnedders> | Um, OK |
| 17:10 | <gsnedders> | You're weird. |
| 17:10 | <gsnedders> | Though you are a far better cook than I. |
| 17:10 | <jgraham> | Are you asking for food? |
| 17:10 | <annevk> | food |
| 17:11 | <jgraham> | , glorious food |
| 17:11 | <gsnedders> | No, I have food at home I need to cook and eat myself. |
| 17:11 | <gsnedders> | I don't need feeding, Mummy. |
| 17:11 | <zcorpan> | i can has a girlfriend who makes me food |
| 17:11 | <annevk> | oh thy, glorious food, gimme some, more |
| 17:12 | gsnedders | notes around three people here will get the joke of calling jgraham that |
| 17:12 | <gsnedders> | zcorpan: Ah, so that's what I'm missing. |
| 17:13 | <jgraham> | gsnedders: Yes, distance relationships are bad for that |
| 17:13 | <jgraham> | Although they can always phone and order you takeaway |
| 17:14 | <jgraham> | (note: untested in actual relationship. May lead to breakup and/or death) |
| 17:14 | <si-p> | is is possible to replace the element class that gets created by the tree builder? |
| 17:14 | <zcorpan> | i wonder if the margin boxes can include edit frequency in an automated way |
| 17:14 | <gsnedders> | jgraham: Hmm, maybe I guess I ought not alpha test that |
| 17:15 | <annevk> | zcorpan, I integrated some of your changes btw |
| 17:15 | <zcorpan> | annevk: cool |
| 17:15 | <gsnedders> | si-p: Not without hacking it, AFAIK |
| 17:15 | <annevk> | zcorpan, I didn't integrate the back/forward stuff because it's not first/last proof |
| 17:15 | <zcorpan> | annevk: i know it's not, but i figured it didn't really matter much |
| 17:16 | <zcorpan> | at least i was too lazy to implement checks :) |
| 17:17 | <zcorpan> | the back/forward thing was what i actually wanted, though |
| 17:17 | <si-p> | gsnedders: ok - thinking about trying to replace TreeBuilder.elementClass with my own |
| 17:17 | <annevk> | lolz |
| 17:17 | <annevk> | ok |
| 17:17 | <annevk> | i'll have another look |
| 17:17 | <annevk> | the back/forward stuff was not mentioned in your changelog so I thought it mattered the least |
| 17:18 | <zcorpan> | oh, i guess i suck at writing checkin comments |
| 17:18 | <si-p> | gsnedders: probably leave that for another day - thanks for your help btw |
| 17:22 | <annevk> | guess I have to do some more checking |
| 17:22 | <annevk> | your code generates server errors |
| 17:28 | <zcorpan> | snap |
| 17:28 | <zcorpan> | did you remove the filter thing? |
| 17:35 | <annevk> | i commented it out |
| 17:35 | <annevk> | next/previous added |
| 17:36 | <annevk> | do you want it back? |
| 17:36 | <annevk> | once Opera 10.5 ships with localStorage I'm going to remove this cookie mess |
| 17:37 | <annevk> | maybe we could move filters back in as well as long as we make them persistent |
| 17:37 | <zcorpan> | yes please :) i can tweak the style to make it less ugly |
| 17:38 | <zcorpan> | we could move to localStorage now |
| 17:38 | <annevk> | <form> is no longer a required container right? |
| 17:38 | <annevk> | zcorpan, we could, but that'd be annoying for me... |
| 17:38 | <zcorpan> | the form can submit, though |
| 17:39 | <zcorpan> | oh there are two forms |
| 17:39 | <annevk> | yup |
| 17:39 | <annevk> | filters are back in |
| 17:40 | <zcorpan> | just for scripting convenience it seems |
| 17:40 | <zcorpan> | thanks |
| 17:41 | <zcorpan> | form { margin:0; font-size:smaller } |
| 17:41 | <zcorpan> | fieldset { border:none; padding:0 } |
| 17:41 | <zcorpan> | legend { padding:0; font-weight:bold } |
| 17:41 | <zcorpan> | form > fieldset > p { margin:0 } |
| 17:41 | <annevk> | just realized the scripting stuff |
| 17:41 | <annevk> | is that just for the first form? |
| 17:41 | <zcorpan> | styling for both |
| 17:42 | <zcorpan> | form > fieldset > p could be replaced with form p |
| 17:43 | <zcorpan> | foodz |
| 17:43 | <annevk> | that's ugly |
| 17:44 | <annevk> | fieldset also has margin btw |
| 17:51 | <annevk> | zcorpan, when you get back it would be useful to know which parts of the filter you are using |
| 18:35 | <Dashiva> | Anyone know the reason input type=range,checkbox,radio,color can't be readonly? |
| 19:00 | <zcorpan> | annevk: i use show editorial content |
| 19:31 | <AryehGregor> | Does Opera not support Unicode characters in IDs? Test case: <!doctype html><meta charset="utf8"><a href="#ל">Click me</a><a href="#%D7%9C">Click me too</a><div style="margin:100em 0" id="ל">Do you get here?</div> |
| 19:31 | <AryehGregor> | Neither link works in Opera 10.10. Both work in Firefox, Chrome, and IE6. |
| 19:33 | <AryehGregor> | Actually, only the first link seems to work in IE6. |
| 19:35 | <Dashiva> | First seems to work here |
| 19:36 | <Dashiva> | Not in 10.10, though |
| 19:36 | <AryehGregor> | But it works in some other version? |
| 19:36 | <Dashiva> | 10.5 |
| 19:36 | <AryehGregor> | I seem to recall it worked in 9.x when I tested it earlier. |
| 19:37 | <Dashiva> | Maybe it's a bidi bug :) |
| 19:39 | <AryehGregor> | Seems unlikely. |
| 19:39 | <AryehGregor> | I should try with some LTR character, though, yeah. |
| 19:43 | <AryehGregor> | I get the same behavior on 9.64. |
| 19:45 | <AryehGregor> | The first link does work in 10.50, though, good. |
| 19:52 | <zcorpan> | maybe it's the url escaping thing |
| 19:52 | <zcorpan> | i seem to recall name="foo%20bar" matching #foo%20bar |
| 20:07 | <AryehGregor> | I had hoped that we could ditch horrible URLs like <http://he.wikipedia.org/wiki/קארים_בנזמה#.D7.A0.D7.91.D7.97.D7.A8.D7.AA_.D7.9C.D7.90.D7.95.D7.9E.D7.99.D7.AA>;. Oh well, maybe soon! |
| 20:14 | <zcorpan> | does it work to use characters with no escaping? |
| 20:15 | <zcorpan> | oh maybe you tried that |
| 20:16 | <Dashiva> | JF's explanation of WCAG1 vs WCAG2 is somewhat amusing. Because the standard is "locked down", the response was to move all the useful content of the standard elsewhere. |
| 20:17 | <AryehGregor> | I did it with no escaping anywhere, that's the only way it seems to work in IE6. |
| 20:17 | <AryehGregor> | Dashiva, unfortunately, that might be a real reflection on insane government agencies and such that take years to adapt to the release of new standards. |
| 20:17 | <zcorpan> | seems like no escaping works but with escaping doesn't, in 10.5 |
| 20:17 | <AryehGregor> | zcorpan, that matches IE AFAICT (at least IE6). |
| 20:17 | <AryehGregor> | Other browsers seem to work either way, which seems correct to me. |
| 20:18 | <zcorpan> | yes |
| 20:18 | <zcorpan> | problem is maintaining compat with pages that expect escaped identifiers to match escaped name=""s |
| 20:19 | <zcorpan> | s/identifiers/fragments/ |
| 20:19 | <zcorpan> | iirc html5 solves that by special-casing <a name> |
| 20:20 | <AryehGregor> | Interesting. |
| 20:20 | <AryehGregor> | I was using id, not name. |
| 20:20 | <AryehGregor> | If Firefox works with that, probably no huge compat problem. |
| 20:20 | <zcorpan> | yeah |
| 20:24 | <AryehGregor> | Dashiva, it's pretty clear that most of the contention on public-html is caused by the fact that some members are using it as a consortium of browser vendors with narrow short-term goals, and some members see it as having other purposes that might conflict with those. |
| 20:24 | <AryehGregor> | It's nice to see someone actually point this out rather than just talking past the other side some more. |
| 20:26 | <AryehGregor> | Hmm, why does YouTube's HTML video thing seem to deliberately block you from right-clicking on their videos? |
| 20:27 | <AryehGregor> | An empty div covers the video to steal the clicks. |
| 20:27 | <AryehGregor> | Vimeo doesn't do that. |
| 20:27 | <AryehGregor> | Particularly annoying since in WebKit, the only way to get fullscreen is to open in a new tab and hit F11 . . . |
| 20:29 | <zcorpan> | maybe youtube uses the div for captions and ads |
| 20:29 | <AryehGregor> | <div class="video-blocker"> |
| 20:29 | <AryehGregor> | I'm pretty sure it's to block clicks. |
| 20:29 | <zcorpan> | or maybe they want to hide save video as from clueless users |
| 20:29 | <AryehGregor> | I assume so. Pretty obnoxious, but I guess only to be expected. |
| 20:33 | <AryehGregor> | Maybe that's a reason not to have good JS APIs, so that authors will be forced to expose default UI and can't easily hide things like "Save". :) |
| 20:33 | <AryehGregor> | (of course, they could just stick with Flash . . .) |
| 20:35 | <zcorpan> | a site like youtube would probably want their own looks of the controls even if they could hide save from the controls |
| 20:50 | <zcorpan> | annevk: maybe we could have "Filter: [v] Show editorial changes _More options..._" |
| 22:39 | <Dashiva> | Someone needs to write a LWP5 |
| 22:41 | <Johnny__> | hello |
| 22:42 | <Johnny__> | What's the best way to style forms? |
| 22:42 | <TabAtkins> | dashiva: lwp? |
| 22:42 | <Johnny__> | I mean, is it ok to use id's and classes with input and form tags? |
| 22:42 | <TabAtkins> | Yes, of course it is. |
| 22:42 | <Dashiva> | TabAtkins: Perl's excuse for a www lib |
| 22:42 | <TabAtkins> | In fact you have to use ids on your inputs if you want to use <label> without wrapping the input. |
| 22:42 | <Johnny__> | I've seen a lot of people using input[type="text"] for example |
| 22:43 | <TabAtkins> | Sure, that's just easier. You probably already have that data in your html, so there's no need to add class=text if that's all you're looking for. |
| 22:43 | <TabAtkins> | But if you need to style things more specifically, certainly use classes and ids. |
| 22:43 | <zcorpan> | input:not([type]) - i usually omit type=text :) |
| 22:43 | <Johnny__> | Ok |
| 22:43 | <TabAtkins> | Well, yeah, me too. But IE doesn't accept :not(). |
| 22:44 | <zcorpan> | who cares |
| 22:44 | <TabAtkins> | My bosses do, because a good 70% of our website visitors use some variety of IE. ^_^ |
| 22:46 | <Johnny__> | That sucks. |
| 22:46 | <TabAtkins> | Eh, at least I can get away with ignoring IE6 most of the time. |
| 22:46 | <zcorpan> | my mom's site has 57% ie |
| 22:46 | <Johnny__> | I always have to fix something to work on IE. It never ever works as it does in any other popular browser. |
| 22:47 | <TabAtkins> | I was very pleasantly surprised a few months ago when I finished up a major project and realized that I didn't have a single hack for IE8. |
| 22:48 | <zcorpan> | and firefox 30%, opera 4%, safari 4%, chrome 3%, mozilla 1% |
| 22:49 | <Johnny__> | I think the majority of people don't really know the difference between browsers, they use what they have and what they've been used to in the past. |
| 22:50 | <zcorpan> | only 7% of the ie users use ie6 |
| 22:50 | <TabAtkins> | Jeez, you're lucky. |
| 22:50 | <TabAtkins> | It's a constant sleight-of-hand to keep management from realizing how many people view our website with IE6, so I don't have to support it. >_< |
| 22:51 | <Johnny__> | Does anyone in here still support IE6 ? |
| 22:52 | <zcorpan> | i tested the site in ie6 once and fixed a few things so that it was at least usable |
| 22:52 | <Johnny__> | I guess that's a no then. |
| 22:53 | <TabAtkins> | I'm with zcorpan - I make sure the site is *usable* in ie6, but I make *no* effort to keep it pretty. |
| 22:53 | <Johnny__> | But you do display a message to someone using ie6? |
| 22:53 | <TabAtkins> | Yes. |
| 22:53 | <zcorpan> | no |
| 22:53 | <Johnny__> | Why not? |
| 22:54 | <zcorpan> | not the kind of site to tell the user to switch browser |
| 22:54 | <webben> | Johnny__: I do. |
| 22:55 | <Johnny__> | I think that's a good idea, at least tell them that it's the browser not your site's fault. |
| 22:56 | <webben> | (Support IE6, that is, as part of http://developer.yahoo.com/yui/articles/gbs/ ) |
| 22:59 | <zcorpan> | apparently my visitors have 19 different versions of flash |
| 23:01 | <Johnny__> | Do you style the section tag in css after declaring it as a block element? |
| 23:01 | <TabAtkins> | If necessary? |
| 23:02 | <TabAtkins> | It's just like any other element. |
| 23:02 | <TabAtkins> | I just feed it the IE shim and the quick block declaration for current-browser compatibility, then style it as I would any other element. |
| 23:02 | <Johnny__> | I've read an article saying that section is not for that and should use div instead. |
| 23:02 | <TabAtkins> | I think you misinterpreted the article. |
| 23:03 | <TabAtkins> | <section> is not meant to be used *solely* as a styling hook. |
| 23:03 | <zcorpan> | 1280x800 is more common than 1024x768 |
| 23:03 | <TabAtkins> | That is, if you need an element *only* to hang styles on. <div> is appropriate there. |
| 23:03 | <Johnny__> | I'm talking about the html5doctor.com's article on how to use the section tag. |
| 23:03 | <TabAtkins> | Yeah, I suspected you meant that article. That's not what they meant. |
| 23:04 | <TabAtkins> | The rule is to just make sure that you're using <section> properly for its semantics, just like you should use all elements properly for their semantics. |
| 23:04 | <TabAtkins> | After that, style away. |
| 23:07 | <Johnny__> | I think I'm still a bit confused as to when should one use section and when should one use article. |
| 23:10 | <Johnny__> | <section><h1>title</h1><article>content</article></section> Is this wrong? |
| 23:12 | <zcorpan> | my other site has 74% ie apparently |
| 23:13 | <Johnny__> | Do you use html5? |
| 23:13 | <zcorpan> | yeah |
| 23:13 | <Johnny__> | Can I see your site? |
| 23:13 | <zcorpan> | which one? |
| 23:13 | <Johnny__> | The one that uses html5 |
| 23:14 | <zcorpan> | emeress.se |
| 23:16 | <Johnny__> | Ok I see you used the section tag |
| 23:17 | <Johnny__> | Now I understand. |
| 23:20 | <zcorpan> | i guess i can remove the script for firefox 2 by now |
| 23:25 | <Johnny__> | Thanks TabAtkins, and zcorpan |
| 23:33 | <zcorpan> | nn |
| 23:36 | <TabAtkins> | Johnny__: The difference between <section> and <article> is somewhat subtle, but there's an easy rule-of-thumb to tell them apart. |
| 23:37 | <TabAtkins> | Use <section> whenever it would be appropriate to put a heading on the stuff you're enclosing (even if you don't actually end up putting one there). |
| 23:37 | <TabAtkins> | Use <article> when you have something that could be a <section>, but would also be appropriate to link directly to, or to view by itself. |
| 23:38 | <TabAtkins> | That rule-of-thumb helps capture the "independent content" semantic that <article> has. |
| 23:38 | <TabAtkins> | Basically if it would be useful to link to a page that had *nothing* on it but the content of the <article>, then <article> is appropriate. |
| 23:46 | <Johnny__> | I see. |
| 23:47 | <TabAtkins> | Frex, I have a CMS with multiple tabs, one for each segment of my application. Each tab is an <article>, because it would make sense to have them on a separate page (though I happen to collect them on a single page for convenience). |
| 23:50 | <othermaciej> | I don't think using <article> or <section> for applications typically makes sense |
| 23:51 | <othermaciej> | I mean, look at the GMail UI, almost none of the logical groupings of UI elements have anything resembling a header |
| 23:51 | <TabAtkins> | Eh, works for me. Helps to delineate major sections of the app (using <article>) from minor sections (using <section>). |
| 23:51 | <TabAtkins> | They certainly *could* have a header. |
| 23:51 | <othermaciej> | the only thing that might be an <article> is an individual email message |
| 23:51 | <othermaciej> | they *could* but they don't |
| 23:51 | <TabAtkins> | They don't, because it's obvious from context. But it wouldn't be weird to add one. |
| 23:52 | <TabAtkins> | Yes. Presentational details like that shouldn't affect the semantics of the element. |
| 23:52 | <othermaciej> | I don't see any reasonable way to decide which groupings in the UI should be <section>s and which should be <div>s |
| 23:52 | <TabAtkins> | Just use the guideline I just said. |
| 23:52 | <othermaciej> | <section> is a concept that makes sense for documents but not as much for applications |
| 23:53 | <TabAtkins> | I agree, though, that the major sections of GMail should be <section>, and email messages should be <article>s. |
| 23:53 | <othermaciej> | you were explaining the difference between <section> and <article>, but that doesn't really clarify the difference between <section> and <div> in an app context |
| 23:54 | <TabAtkins> | Sure. The differernce is that <div> just groups things for some arbitrary reason, usually for styling or scripting purposes. <section> groups them according to a logical division of the doc/app, with the "heading" rule of thumb helping to determine what's an appropriate "logical grouping". |
| 23:54 | <TabAtkins> | That just keeps you from overthinking things and over-dividing the app. |
| 23:56 | <TabAtkins> | Like, say, the Labels panel in the GMail ui - individual labels, with their color spot, would probably be <div>s. It's not appropriate to use <section> there, because you wouldn't put a heading on individual labels. |
| 23:56 | <TabAtkins> | Though, if you were on a label-centric page with a lot of info on each label, then it would be appropriate. |
| 23:57 | <TabAtkins> | Same as how, frex, a group of ledes for blog posts on a blog home page should just be <div>s, but a group of full posts (or perhaps truncated posts with a "Read More" link) are appropriate for <article>. |
| 23:57 | <TabAtkins> | <div> or <li> or something, that is. |