| 00:05 | <Hixie> | Since we are "paving the cow paths" it seems to me that we must also pave |
| 00:05 | <Hixie> | foreseeable future cow paths as well. To that end, add a version |
| 00:05 | <Hixie> | attribute and just be done with it. Everyone else can ignore it. |
| 00:05 | <jdandrea> | Heh. |
| 00:05 | <jdandrea> | (from the list, aye) |
| 00:05 | Hixie | wonders if the author understands the cowpath principle |
| 00:05 | <Dashiva> | Hixie: What's the reasoning for the void Table.delete* methods, rather than (e.g.) Table.remove* which return the removed element? |
| 00:06 | <Hixie> | the reasoning is probably "that's what DOM2 HTML has" |
| 00:08 | <Dashiva> | And related, create* now explicitly only returns new elements, while DOM2 HTML states they may return an existing one |
| 00:10 | <Hixie> | probably based on what browsers did, i forget. however if you find an incompatibility, feel free to mail the list and i'll look at it |
| 00:11 | <Dashiva> | Personally I consider the whole bunch redundant and low-utility, so no worries :) |
| 00:12 | <Philip`> | http://www.ipfw.edu/chem/104/kimble/cowpath.htm - that seems to advocate against paving cow paths, because they're often far from the best route and it's just that nobody has thought to look around and notice there's a problem. But I think this is probably taking the metaphor a bit too far... |
| 00:13 | <Dashiva> | No, it's a good lesson |
| 00:14 | <Dashiva> | The cowpaths to pave are those with a sensible foundation, not mindless drones enforcing it |
| 00:14 | jdandrea | moos |
| 00:15 | jdandrea | keeps thinking the versioning request is meant (on the whole) more for CSS/DOM, not so much HTML. |
| 00:15 | <Dashiva> | Prototyping Object is a cowpath that should be blocked off on penalty of death :) |
| 00:15 | <jdandrea> | lol |
| 00:20 | <Philip`> | (Hmm, not sure why that page lacks the proper attribution - http://www.mitcharf.com/mitcharf/art/poems/calfpath.html seems a better resource) |
| 01:01 | <Lachy> | good morning |
| 01:02 | <zcorpan_> | Lachy: morning |
| 01:02 | <Philip`> | (http://www.archive.org/details/whiffsfromwildme00fossiala (p. 77) - aha, found the original! and hooray for copyright expiration) |
| 01:10 | <jdandrea> | Philip`: "The Calf-Path" - thanks for finding this! |
| 01:12 | jdandrea | thinks it would make good starter lyrics for a folk-rock song |
| 01:20 | <zcorpan_> | isn't name="" on <iframe> missing? (opera supports id="", but firefox and ie don't) |
| 01:21 | <Hixie> | possibly |
| 01:23 | <zcorpan_> | if we want <a target> and <form taget> to work with iframes then we need <iframe name>, i think |
| 01:25 | <zcorpan_> | should i mail the list? |
| 01:26 | <Hixie> | zcorpan_: sure |
| 01:26 | <Hixie> | and thanks |
| 01:26 | <annevk> | does it need to be conforming? prolly... |
| 01:27 | <zcorpan_> | annevk: <a target> is conforming, what use is it if you can't use it together with iframes? |
| 01:27 | <annevk> | i meant <iframe name> |
| 01:27 | <annevk> | much like <map name> |
| 01:28 | <zcorpan_> | <map> works with id. <iframe> doesn't |
| 01:28 | <annevk> | the former doesn't in Firefox |
| 01:29 | <zcorpan_> | but it does in ie. the latter doesn't in both firefox and ie. |
| 01:30 | <annevk> | Firefox has like 10% market share... |
| 01:30 | <annevk> | If working is an argument, <map name> should certainly be conforming |
| 01:30 | <zcorpan_> | not against that |
| 01:31 | <annevk> | they should be handled in a consistent way imo |
| 01:31 | <annevk> | same for <object id/name> etc. |
| 01:32 | <om_coffee> | I think it's preferrable to have only id be conforming if there aren't any major UAs where name works but id doesn't for some construct |
| 01:33 | <zcorpan_> | othermaciej: <iframe id> doesn't work in ie nor firefox (don't know about safari) |
| 01:34 | <othermaciej> | zcorpan_: yeah, I'm just making a broad generalization based on what annevk said |
| 01:34 | <othermaciej> | I don't know what the situation is with object id/name |
| 01:38 | <zcorpan_> | well, i guess i need to do more testing here first then |
| 01:38 | <zcorpan_> | not today though |
| 01:38 | <Hixie> | :-) |
| 01:46 | <annevk> | zcorpan_, what does http://xhtml.se/2007/04/17/x-and-html-sitting-in-a-tree/ say? |
| 01:49 | <Dashiva> | It's basically saying "Now that HTML and XHTML will be the same in v5, it won't matter which one you use" |
| 01:49 | <zcorpan_> | annevk: it basically says that html5 is the future, and that it doesn't matter if you use xhtml1 or html4 today, and it is pointless to switch from xhtml1 to html4, and pointless to argue about why xhtml is bad/shouldn't be used |
| 01:50 | <zcorpan_> | yeah |
| 01:50 | <annevk> | blah |
| 01:50 | <Dashiva> | It fails to address the non-HTML aspects |
| 01:50 | <annevk> | if he means XHTML as text/html though, fair enough |
| 01:50 | <Dashiva> | Like mime-types, CSS background, you know the list better than me |
| 01:50 | <annevk> | is that made explicit? |
| 01:51 | <zcorpan_> | annevk: he does, although he also likes content negotiation and mobile stuff |
| 01:51 | <Dashiva> | He doesn't mention it in the article itself, though |
| 01:52 | <zcorpan_> | he will hold a presentation about xhtml at geekmeet together with my html5 presentation next month |
| 01:52 | <Dashiva> | Seems to be a defense for people using xhtml, rather than saying xhtml is good :) |
| 01:52 | <zcorpan_> | Dashiva: indeed, i just know because i've talked with him about it a lot |
| 01:52 | <annevk> | "Look, I'm right after all!" |
| 01:54 | <zcorpan_> | annevk: i don't think it's benefitical to argue against these guys. he's not alone. making html5 accept xhtmlish syntax makes them happy. :) |
| 01:55 | <annevk> | I'm not arguing, I'm just making fun of them :) |
| 01:55 | <zcorpan_> | he's not ignorant at all, i just think he sticks to the xhtml idea because he bought the domain name ;) |
| 01:55 | <zcorpan_> | ok |
| 01:55 | <annevk> | lol |
| 01:56 | <Dashiva> | Wow |
| 01:56 | <Dashiva> | Now it's "why not a namespace on the html element" |
| 01:58 | <zcorpan_> | cwilso also thought it would be appropriate to use the namespace as a versioning switch, didn't he? |
| 01:58 | <annevk> | ouch |
| 02:02 | <zcorpan_> | http://www.w3.org/mid/5C276AFCCD083E4F94BD5C2DA883F05A27D7192F39⊙twwnmc |
| 02:03 | <annevk> | crazy |
| 02:03 | <annevk> | same as the nonsense people supporting that idea |
| 02:06 | <othermaciej> | I think cwilso doesn't want a version attribute because he (probably correctly) thinks people will just leave it off |
| 02:07 | <Dashiva> | That's counter to his other line of arguments, that people copy the header cargo cultishly |
| 02:07 | <Hixie> | no, he pointed out 50% of sites leave off the <!DOCTYPE> |
| 02:09 | <Dashiva> | Yes, but he also argues that many sites who opt for standards mode don't really want standards mode, so we could never have a real "give me the latest and best" switch |
| 02:11 | <Lachy> | As a web developer, I find Chris' implication that those of us who use Strict DOCTYPEs to get standards mode now aren't competent enough to want "always standards mode" offensive |
| 02:11 | <Dashiva> | XHTML has taught us a lot of people will say it without meaning it, though :/ |
| 02:11 | <othermaciej> | it seems to me that Microsoft having such major bugs that were left around for years is a major contributing factor to the breakage level |
| 02:12 | <Lachy> | the incompetence of others shouldn't reflect on the whole |
| 02:13 | <Lachy> | MS actually needs to do some real work and research each change on a case by case basis, rather than ruling them all out at once |
| 02:15 | <Dashiva> | And not fix the "solution bugs" before the problems that depend on it |
| 02:15 | <zcorpan_> | Lachy: they will only do that if they become a minority vendor and the web will ignore their versioning switches and work better on the competitor's browsers |
| 02:15 | <zcorpan_> | i think |
| 02:15 | <zcorpan_> | competitors' even |
| 02:16 | <Lachy> | zcorpan_: yes, it's quite sad |
| 02:17 | <zcorpan_> | so that scenario is what we should aim for then :) |
| 02:19 | <Philip`> | Perhaps the HTML5 spec should add an author conformance requirement that all pages must end in <a href="http://getfirefox.com">Get Firefox!</a> |
| 02:20 | <annevk> | right |
| 02:21 | <annevk> | what about opera.com |
| 02:21 | <annevk> | we actually implemented WF2! |
| 02:21 | <Dashiva> | It should rotate |
| 02:23 | <Philip`> | opera.com doesn't have enough swooshy blue and orange bits :-( |
| 02:38 | <annevk> | you know, some people appreciate that :) |
| 05:53 | <Hixie> | hey did anyone ever write a faq entry on why versioning is bad? |
| 05:55 | <annevk> | don't think so |
| 05:55 | <annevk> | we need more wiki entries |
| 05:55 | <annevk> | on role=, href=, versioning, etc. |
| 05:55 | <annevk> | of course, this is easy to say and hard to do :) |
| 05:56 | <annevk> | "hard" |
| 05:59 | <hober> | @role makes my head hurt |
| 06:00 | <hober> | I honestly can't figure out how it is any different from @class |
| 06:01 | <hober> | besides in some kind of "@class has been abused, therefore let us introduce a new attr that'll also be abused" sense |
| 06:04 | <Lachy> | if someone sends me a Q&A for versioning, I can add it to the FAQ. If not, I'll get around to it later this week. |
| 06:05 | <Lachy> | it'll probably form part of that blog entry I'm writing, and will finish after I get back from the WAF F2F this weekend |
| 06:05 | <Hixie> | cool |
| 06:19 | <annevk> | What's the idea for "wizards" and "model dialogs"? |
| 06:20 | <Hixie> | modal, you mean? |
| 06:20 | <Hixie> | both are pretty bad ui |
| 06:20 | <Hixie> | but window.open() can handle them |
| 06:21 | <annevk> | I quite like the "step 1 of 4" kind of UI |
| 06:21 | <annevk> | not sure about modal dialogs |
| 06:21 | <annevk> | window.open() doesn't make it modal though |
| 06:22 | <Hixie> | wizard ui does very badly in usability studies, as i understand it |
| 06:22 | <Hixie> | you can easily make things modal, just ignore events in the other browsing context |
| 06:22 | <Hixie> | but basically the <switch> thing i've been talking about is the real solution to this |
| 06:23 | <annevk> | is it going in? |
| 06:23 | <annevk> | or HTML6? |
| 06:25 | <Hixie> | if we can find a working decent solution, it's the last thing i personally want to put in |
| 06:25 | <Hixie> | i.e. other than everyone else's requests |
| 06:25 | <annevk> | it's not used that often |
| 06:26 | <Hixie> | any time someone tries to do ui using display:none, they're asking for it |
| 06:26 | <annevk> | hmm |
| 06:58 | <annevk> | So you have HTML tokenization which does some sort of case mangling. You have the HTML DOM APIs which uppercase stuff and there's CSS matching... |
| 06:58 | annevk | played around with the <pÉ> element |
| 06:58 | <annevk> | and also <pé> |
| 07:01 | <annevk> | It seems that some browsers actually uppercase that through the DOM |
| 07:01 | <Lachy> | there are some interop problems with case sensitivity of selectors that matching non-ASCII chars |
| 07:01 | <annevk> | Internet Explorer and Firefox |
| 07:01 | <annevk> | yes |
| 07:06 | <Lachy> | it would probably make sense to try and define that UAs must use the Unicode Case Mappings, but we should actually try and do some tests to figure out how closely UAs follow them |
| 07:07 | <Lachy> | I hope Unicode is more interop than HTML4, cause I don't want to write Unicode5, but somehow I doubt it. |
| 07:07 | <annevk> | Unicode 5 is already here |
| 07:08 | annevk | rather has ASCII case-insensitive when possible |
| 07:08 | <Lachy> | that's Unicode 5.0, I meant like a WHATWG version |
| 07:08 | <Lachy> | that's one possibility, but isn't quite what UAs do at the moment |
| 07:11 | <Lachy> | I don't think we'll need to change parsing reqs to address this issue, but we'll need to more thouroughly define the DOM APIs upper-casing rules and selector matching |
| 07:11 | <Lachy> | since Selectors says case sensitivity depends on the markup language, we should be able to define explicity case sensitivity rules |
| 07:12 | <annevk> | selectors should just be fixed... |
| 07:12 | <Lachy> | could we define that for XHTML5, selectors are case insensitive? |
| 07:13 | <Lachy> | it should be the language that matters, not the serialisation |
| 07:13 | <annevk> | i would think so |
| 07:24 | <Hixie> | are you also suggesting that <INPUT> and createElementNS(... 'INPUT') create HTML <input> elements? |
| 07:24 | <annevk> | createElement should |
| 07:25 | <annevk> | createElementNS prolly not |
| 07:25 | <Hixie> | then the selectors shouldn't match either, imho |
| 09:06 | <Hixie> | hmm |
| 09:07 | <Hixie> | i wonder if window.location and window.history are per-Document or per-Window |
| 09:23 | <aroben> | Hixie: I should think window.history would have to be per-Window |
| 09:24 | <Hixie> | turns out it's actually per-Document |
| 09:24 | <aroben> | Hixie: what would a single-document history mean? |
| 09:24 | <aroben> | Hixie: ?? |
| 09:24 | <Hixie> | a new object is created for each Document |
| 09:24 | <Hixie> | they all represent the same underlying data, naturally |
| 09:24 | <aroben> | Hixie: ah, I see |
| 09:49 | <mpt> | Ahhh, that reminds me of Netscape 2 |
| 09:50 | <mpt> | where the Back and Forward buttons took you back and forward entire framesets, and frames had separate "Back in This Frame" and "Forward in This Frame" shortcut menu items |
| 09:50 | <mpt> | madness |
| 09:53 | <Hixie> | not that the more modern frame ui is much more usable |
| 09:55 | <Hixie> | the public-html and public-xhtml2 are amusing to compare |
| 09:56 | <Hixie> | both groups are doing basically nothing |
| 09:56 | <Hixie> | but the former is doing it with significantly more acticity |
| 09:56 | <Hixie> | activity |
| 10:47 | <zcorpan_> | whohoo!! |
| 10:47 | <zcorpan_> | i got the job! |
| 10:47 | <zcorpan_> | :D :D :D |
| 10:48 | <Hixie> | congrats! |
| 10:48 | <Hixie> | which job? :-) |
| 10:48 | <zcorpan_> | at opera |
| 10:48 | <Hixie> | nice |
| 10:48 | <zcorpan_> | for the summer |
| 10:49 | <Hixie> | do you know what you'll be doing? |
| 10:49 | <zcorpan_> | writing a test suite for html5 |
| 10:49 | <Hixie> | sweet |
| 10:49 | <zcorpan_> | yup |
| 10:49 | <Hixie> | guess i'd better finish this spec off, then :-P |
| 10:49 | <zcorpan_> | heh |
| 10:50 | <hasather> | zcorpan_: congrats :) |
| 10:50 | <zcorpan_> | thanks |
| 10:53 | <hsivonen> | zcorpan_: congrats |
| 10:53 | <zcorpan_> | thanks :) |
| 10:54 | <hsivonen> | zcorpan_: it would be superb if you could include a categorization of expected syntactic correctness |
| 10:55 | <zcorpan_> | hsivonen: you mean test cases intended for conformance checkers? |
| 10:55 | <hsivonen> | anne's wf2.0 browser tests were very useful for conformance checkin, but the suite lacked this data |
| 10:56 | <hsivonen> | zcorpan_: i mean using browser test as conformance checker tests as a byproduct |
| 10:56 | <zcorpan_> | ah, yeah that would be simple to arrange |
| 11:40 | <Dashiva> | I have this feeling everyone on the list is ignoring the html60 guy |
| 11:47 | <Hixie> | i didn't ignore him |
| 11:47 | <Hixie> | i just didn't understand what he was proposing |
| 11:47 | <Hixie> | so i didn't feel qualified to comment |
| 11:47 | <Hixie> | anyway, well beyond bed time |
| 11:47 | <Hixie> | nn |
| 11:48 | <hasather> | good night Hixie |
| 15:42 | zcorpan_ | downloads swift_0.2.msi |
| 15:44 | <sgillies> | i just found out about the time element from Sam Ruby's blog. is anyone considering geo-spatial markup? i'm asking this because Google is proposing that KML (the Google Earth language) be the markup for what the GIS industry likes to call the "Geo-Web". i'd rather there weren't two webs where there could be one |
| 15:55 | <hsivonen> | sgillies: what's the use case for geospatial markup in HTML? |
| 15:59 | <sgillies> | find pages, or elements of pages, that have a spatial context. much the same as the use case for time, really. i admit that it is not as generally useful |
| 15:59 | <sgillies> | substitute "where" for "when" in the time use case |
| 16:01 | <hsivonen> | hmm. looking at http://microformats.org/wiki/geo and comparing the situation with <time>, perhaps Hixie should bless Tantek's general <abbr> design pattern somehow |
| 16:02 | <hsivonen> | the main problem I see with the <abbr> pattern is that it is designed to be backwards compatible with HTML 4.01 validation instead of being designed to be backwards-compatible with the browser rendering of <abbr> and title="". |
| 16:03 | <sgillies> | hsivonen: http://georss.org is probably a better example than the microformat. all the major web mapping applications can consume spatially referenced RSS. |
| 17:16 | zcorpan_ | is playing around with im.css in opera... can someone mention my name? |
| 17:16 | <gavin_> | zcorpan_ |
| 17:17 | <zcorpan_> | works :) |
| 17:17 | zcorpan_ | now has a counter at the right top of the window of how many times my name has been mentioned |
| 17:18 | <Dashiva> | zcorpan_ zcorpan_ zcorpan_ zcorpan_ zcorpan_ zcorpan_ zcorpan_ zcorpan_ mushroom mushroom |
| 17:18 | <zcorpan_> | lol |
| 17:19 | <zcorpan_> | snake! snake! |
| 17:34 | <hendry> | I can't access this URL with my W3 username http://www.w3.org/Member/Intro |
| 17:34 | <hendry> | can you guys? |
| 17:35 | <h3h> | that's because you're probably not a Member |
| 17:35 | <h3h> | you're a member |
| 17:35 | <h3h> | there's a difference :) |
| 17:36 | <hendry> | so 'invited expert' isn't a member, eh? |
| 17:36 | <h3h> | invited expert is a member |
| 17:36 | <h3h> | invited expert is not a Member |
| 17:37 | <h3h> | Members: http://www.w3.org/Consortium/Member/List |
| 17:37 | <hendry> | so a member must be a company, not an individual? |
| 17:37 | <hendry> | and I guess a member must pay fees |
| 17:40 | <h3h> | heh. is your shift key broken? |
| 18:00 | <zcorpan_> | hendry: h3h's point is that there's a difference between members and Members. you're a member but not a Member. |
| 18:01 | <hendry> | zcorpan_: oh really? |
| 18:01 | <hendry> | h3h: that's really confusing |
| 18:01 | <h3h> | tell that to them |
| 18:02 | <hendry> | I must say I fealt a little smug with the "invited expert" title at first and didn't ask too many questions |
| 18:02 | <hendry> | now I feel like a victim ;) |
| 19:41 | <kingryan> | hmm, I can't seem to find where in the current spec it says that "void elements" must not have an end tag |
| 19:42 | <kingryan> | it's also not clear that contentmodel == empty is equivalent to "void element" |
| 19:44 | <billmason> | kingryan: http://www.whatwg.org/specs/web-apps/current-work/#elements0 "Void elements only have a start tag; end tags must not be specified for void elements." |
| 19:45 | <kingryan> | billmason: ah, thanks |
| 19:46 | <kingryan> | so, starting at http://www.whatwg.org/specs/web-apps/current-work/#param with the question "why does the validator say 'Fatal Error: End tag param seen even though the element is an empty element.'?" I couldn't find the answer |
| 20:08 | <jdandrea> | From Browser Wars IV: A New Hope - http://slashdot.org/comments.pl?sid=231321&cid=18784983 |
| 23:25 | <zcorpan_> | krijnh: perhaps the logs should state the timezone? |