| 00:51 | <Hixie> | good god i hate the ietf process |
| 00:52 | <Hixie> | apparently there's some meeting going on so i can't upload new drafts |
| 00:52 | <Hixie> | it's amazing to me that the ietf explicitly _prevent_ progress during their meetings |
| 00:52 | <Hixie> | i mean, i know meetings aren't usually productive in the first place, but actually preventing progress is just stunning |
| 00:55 | <MikeSmith> | meetings in general can be pretty productive, even standards meetings sometimes |
| 00:56 | <MikeSmith> | I had a boss at a previous job who tried to institute a "everybody stands" (no sitting) meeting policy |
| 00:56 | <MikeSmith> | to force everybody to actually focus on talking to each other and getting something done |
| 00:57 | <MikeSmith> | he also had a "no food at meetings" policy |
| 00:58 | <MikeSmith> | as far as other kinds of meetings, if you're doing direct product-dev work for real paying customers, it's pretty hard to avoid meetings |
| 00:58 | <MikeSmith> | though those meetings also aren't always productive. they're just necessary |
| 00:59 | <MikeSmith> | then there are "apology" meetings... |
| 00:59 | <MikeSmith> | maybe that's something more unique to Japan |
| 01:00 | <MikeSmith> | go to a meeting to "apologize" to customer for mistakes you actually did not make, but were in fact either the customer's fault or their hand-picked system integrator's fault |
| 01:01 | <Philip`> | If you admit mistakes, surely they'd sue you |
| 01:02 | <MikeSmith> | lawsuits are pretty rare in Japan |
| 01:02 | <MikeSmith> | actual contracts are kinda rare too |
| 01:03 | <MikeSmith> | at least in my limited experience (doing professional-services type customized product development) |
| 01:04 | <MikeSmith> | and even when customers do sign contracts, they feel free to ignore them if they want. or change the terms unilaterally |
| 01:04 | <MikeSmith> | when dealing with big companies here, you're pretty much at their mercy |
| 01:05 | <MikeSmith> | the threat of losing future business with them is enough to make you do what they say |
| 01:06 | <mookid> | [13:37] <Philip`> If you encode the desired content-type in the URI, it's not possible for a general-purpose HTTP-processing device to understand what's the resource identifier and what's the content-type selector, because there's no standard for encoding that stuff in URIs |
| 01:07 | <mookid> | [13:38] <Hixie> Philip`: such a standard or convention could be easily established |
| 01:08 | <mookid> | [13:40] <Philip`> Hixie: You couldn't establish it in a way that wouldn't conflict with other people not following that standard and perfectly legitimately happening to use the same magic URI query parameter or whatever the content-type thing is stored as |
| 01:09 | <mookid> | :) |
| 01:10 | <Philip`> | I have no idea what any of that means |
| 01:10 | Philip` | should probably go to bed |
| 01:10 | <Hixie> | it was a reply to your comment last november: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-432 |
| 01:12 | <Hixie> | er i mean a reply to my comment last november: http://krijnhoetmer.nl/irc-logs/whatwg/20081120#l-424 |
| 01:15 | <mookid> | hows the work on my accept attribute coming along Ian ? |
| 01:16 | <mookid> | I can't believe we're never going to get to use HTTP conneg |
| 01:18 | <MikeSmith> | anybody know anybody HTML5-savvy who's in Postsdam/Berlin or nearby and willing to do a presentation on HTML5 in October? |
| 01:20 | <mookid> | Hixie: are you open to bribery? |
| 01:22 | <Hixie> | yeah, but i'm expensive |
| 01:22 | <ezyang> | "Every man has his price. The trick is knowing how much." |
| 01:30 | <roc> | how about blackmail and threats of violence? |
| 01:31 | <Hixie> | roc: nope |
| 01:31 | <MikeSmith> | threats reminds me again of customers... "If you don't fix this bug, there will be no next project." |
| 01:31 | <Hixie> | roc: can't buy model trains with those |
| 01:32 | <MikeSmith> | heh |
| 01:32 | <roc> | sure would be a shame if something were to happen to those model trains |
| 01:33 | <Hixie> | they're sadly all in boxes right now :-( |
| 01:33 | <Hixie> | don't have room to put up a lyout |
| 01:33 | <MikeSmith> | Hixie: did you know that Chaos Computer Club started out as a group of model-train otaku? |
| 04:01 | <coopy> | hello |
| 08:32 | <boblet> | Hey all, can anyone tell me the WhatWG stance on role, either the ARIA or the ‘bestowing semantics’ variety? |
| 08:32 | <takkaria> | I'm not sure there is a WHATWG "stance" per se |
| 08:33 | <Hixie> | ARIA is scheduled to get merged into HTML5 whenever the ARIA group are done dealing with their last call comments adequately |
| 08:33 | <Hixie> | (er "merged" in the sense that it will be conforming to use ARIA in HTML5 - i don't expect to copy the text in verbatim or anything) |
| 08:33 | <boblet> | ok |
| 08:34 | <Hixie> | (i expect it'll just be a list of attributes, a list of constraints on when they can be used, and a reference to the ARIA author and implementor specs) |
| 08:34 | <boblet> | Hixie: any idea if that will be eg in time for October? |
| 08:34 | <Hixie> | no idea |
| 08:34 | <tantekc> | Hixie, what are your standards for "merged" in the sense of conforming to use and referencing external specs rather than copying the text in verbatim etc.? |
| 08:36 | <Hixie> | dunno, it hasn't come up before :-) |
| 08:37 | <boblet> | Hixie: what about the ‘using role for adding semantic meaning’ idea? I’m guessing there’s a reason for <nav> rather than <ul role="nvaigation">… |
| 08:39 | <Hixie> | how is it different to class=""? |
| 08:41 | <boblet> | I’m guessing because the semantic meanings are formally and officially defined, and that implementors then add support for these meanings where appropriate |
| 08:41 | <Hixie> | oh. then how is it different to elements? |
| 08:43 | <boblet> | I guess because then the semantics can be applied to more than one element, depending on which one was most appropriate |
| 08:43 | <Hixie> | isn't that just like nesting? |
| 08:43 | <Hixie> | i don't really understand the problem this would solve |
| 08:46 | <boblet> | I’m personally happy with the whole new elements approach—I think it’s conceptually simpler to add a few new elements than use div with role (or class) for everything, and easier to teach. I’m trying to understand the difference between John Allsopp’s approach and adding new elements. |
| 08:48 | <MikeSmith> | one difference is it that elements can be further subclassed |
| 08:48 | <boblet> | It certainly seems like the Microformats approach has paid off in faster implementation for the problems they’ve addressed, so I can see the logic to role being more amenable to rapid changes vs adding new elements |
| 08:48 | <boblet> | hey Mike |
| 08:48 | <MikeSmith> | hey |
| 08:48 | <boblet> | by subclassed are you meaning with classes or with nesting? |
| 08:48 | <tantek> | boblet - indeed. |
| 08:49 | <tantek> | after the experience with microformats and the ability to assign *multiple* semantics to a single element, it's pretty clear to me that the one element = one tag = one meaning design of SGML/HTML/XML is fundamentally flawed. |
| 08:49 | <MikeSmith> | boblet: if you used <div class=section> for bunch of sections and then you want to to further distinguish between kinds of sections, you don't have a class attribute to use to subclass them any more |
| 08:49 | <Hixie> | boblet: depends what you're solving, but yes |
| 08:50 | <Hixie> | boblet: if we were designing a new markup language from scratch, this would be a good discussion to have :-) |
| 08:50 | <tantek> | space separated set of class names for semantics has provided far better flexibility in terms of more easily marking up content that web authors actually publish. |
| 08:50 | <boblet> | MikeSmith: well only if you’re using IE6 ;-) |
| 08:50 | <tantek> | MikeSmith - not true - you can add additional class names to provide additional semantics in your class="section" example. |
| 08:51 | <boblet> | woops, I think I might have started something :) |
| 08:51 | <MikeSmith> | boblet: tantek's right, I'm wrong. :) |
| 08:52 | <boblet> | MikeSmith: well, as I said you’re right for IE6 (and CSS styling)—it only sees the first (or was it last?) class name |
| 08:52 | <tantek> | Hixie, I asked the above question (re: reference vs. wholly incorporate) because I am revising hCard, hCalendar, hReview, hAtom with bug fix revisions that incorporate numerous issue resolutions (including your issue regarding conformance criteria for user-agents and authors). |
| 08:53 | <MikeSmith> | if authors want to do <div class="section something"> instead of using <section class="something">, the existence of a <section> element does not prevent them from doing that |
| 08:54 | <tantek> | e.g. hCard 1.0.1, hCalendar 1.0.1. - at that point I'm confident that those specifications will be more thorough, and incorporate more issue resolutions than the corresponding pre-defined microdata vocabularies of vcard/vevent. |
| 08:55 | <tantek> | not to mention be backed by actual experience from numerous authors publishing hCards and hCalendar events as defined. |
| 08:56 | <tantek> | and thus it should be reasonable to consider incorporating hCard and hCalendar vocabularies by *reference* rather by redefinition inline in the HTML5 spec. |
| 08:57 | <boblet> | MikeSmith: I think that web authors perceive class as an ad hoc system, rather than something official. While Microformats have pushed it a long way, I think that a W3-defined vocabulary of semantics (either new elements or role values) are far more official. Also I’m guessing implementors would feel the same—they’d be more likely to build functionality on something that’s defined (by W3) rather than something that’s just |
| 08:57 | <MikeSmith> | boblet: you got cut off there |
| 08:58 | <Hixie> | tantek: i think we're actually going to take out the few vocabularies that are in there already (the vcard and vevent ones, and the licensing works one) |
| 08:58 | <tantek> | Hixie, this is just a heads up of work in progress. I will re-raise the issue when hCard 1.0.1 and hCalendar 1.0.1 drafts have been published. In either case, I do think it is premature/unwise to include pre-defined microdata vocabularies. Hopefully the updates to hCard and hCalendar will make that even more clear. |
| 08:58 | <boblet> | too wordy—my bad. how far? |
| 08:58 | <Hixie> | tantek: and put them in their own specs |
| 08:58 | <Hixie> | tantek: i haven't worked out what should happen reference-wise |
| 08:58 | <MikeSmith> | to "that's jus..." |
| 08:58 | <Hixie> | tantek: it might be that we end up with a section that mentions vocabularies that use various features like class="" (assuming microformats continue to use those instead of item/itemprop) and item/itemprop |
| 08:58 | <Hixie> | tantek: in a non-normative way |
| 08:59 | <Hixie> | tantek: in which case i'd be happy to link to some normative definitions if there are some |
| 08:59 | <boblet> | RT: Also I’m guessing implementors would feel the same—they’d be more likely to build functionality on something that’s defined (by W3) rather than something that’s just agreed (by users of Microformats etc) |
| 08:59 | <tantek> | Hixie, the licensing works one will take more effort because it requires completion of the in-progress "licensing microformat", however it will very likely have similar to features to what you've written up - as you seem to have come to many of the same conclusions as the licensing microformats brainstorming efforts. |
| 08:59 | <MikeSmith> | boblet: but none of us want something official if it overly restricts authors. the point is to try to find some kind of sweet spot. to provide more authoring ease without locking people into something official that ends up restricting and confusing them too much |
| 09:00 | <Hixie> | tantek: that's no coincidence, the microformats wiki was one of my main crib sheets :-) |
| 09:01 | <tantek> | we do seem to agree that the ccREL as designed is problematic due to it's ability/encouragement for license proliferation, which IMHO is a fatal design flaw. http://microformats.org/wiki/licensing-brainstorming#ccREL_issues |
| 09:02 | <tantek> | s/it's/its duh |
| 09:02 | <boblet> | MikeSmith: well, I think new elements could also be considered fairly restrictive (in terms of number and release cycle) |
| 09:03 | <tantek> | Hixie, that is good to hear that the pre-defined vocabularies will be taken out of the HTML5 spec. |
| 09:03 | <boblet> | That’s why the potential of eg role values being defined in a Microformats-like way but by WhatWG/W3 seems really interesting—official and well-thought-out like elements, but faster release cycle like µF |
| 09:03 | <tantek> | As far as microformats use of class vs. item/itemprop, it is likely that for the forseeable future microformats will continue to make use of the class attribute for backwards compatibility. |
| 09:04 | <othermaciej> | as an implementor, I don't have a problem in principle implementing things based on microformats, just because they are not W3C-official or whatever |
| 09:04 | <tantek> | However, I believe it does make sense to advocate use of HTML5's features when authors are able to do so (are able to depend on them based on their use cases), and it is more advantageous to do so. |
| 09:05 | <othermaciej> | the main problems with microformats (neither completely fatal) are that parsing has historically not been defined very tightly, and the trickiness of figuring out the right browser UI to expose them |
| 09:05 | <tantek> | This will likely be an extension of the "How to use microformats in HTML5" work in development, that advocates use of the <time> element etc. |
| 09:05 | <othermaciej> | (from a browser implementor perspective) |
| 09:06 | <othermaciej> | one thing I like about microdata is that it takes you from parsing to a data model in a precisely defined way |
| 09:06 | <tantek> | othermaciej, I will encourage you to review the hCard 1.0.1 and hCalendar 1.0.1 drafts regarding the thoroughness of parsing definition. it is my intent to make those definitions thorough through both prose and test cases. |
| 09:06 | <othermaciej> | so microdata-based formats could start defining things at the data model level |
| 09:07 | <tantek> | I agree, the parsing to data model description of the general microdata feature is quite admirable. |
| 09:07 | <othermaciej> | tantek: I did say "historically", cause I haven't reviewed recently |
| 09:07 | <tantek> | (btw parsing details are a known issue that I've resolved as needing additional work for hCard 1.0.1 and hCalendar 1.0.1) |
| 09:08 | <othermaciej> | one other thing I like about microdata is that it exposes the data model through a nice DOM API, which is friendly to data extraction via client-side script or client-side logic in general |
| 09:09 | <tantek> | we are doing something similar in microformats for our recent test-suite update efforts: http://microformats.org/wiki/test-suite |
| 09:10 | <othermaciej> | hCard and hCalendar are probably among the microformats that are most interesting for likely built-in browser features, if anyone ever goes there |
| 09:10 | <othermaciej> | I would really like to support hAtom as well, but that probably won't happen unless our feed parsing code is open sourced and a motivated individual can take matters into their own hands |
| 09:12 | <tantek> | othermaciej - does it help that there is existing open source XSLT that you can incorporate to transform hAtom to Atom and then just pipe that into your existing support? http://rbach.priv.at/Microformats/hAtom2Atom/ |
| 09:12 | <tantek> | specifically, available under the The W3C Open Source License per http://rbach.priv.at/Microformats/hAtom2Atom/readme.txt |
| 09:12 | <Hixie> | boblet: I expect HTML's release cycle to be remarkably quicker once HTML5 is done |
| 09:13 | <othermaciej> | tantek: the people who originally wrote our support are no longer with the company and left a... very creative combination of diverse technologies that... provides an intellectual puzzle for those of us on the team |
| 09:13 | <othermaciej> | so it doesn't actually help that much directly, but thanks for the reference |
| 09:14 | <Hixie> | boblet: the main problem with HTML that made HTML5 take so long was the utterly woeful state of the HTML and DOM HTML specifications prior to HTML5, in terms of conformance criteria for implementors (of all classes, not just browsers), and in terms of missing features altogether (DOM level 0 in particular) |
| 09:14 | <tantek> | othermaciej - that's too bad. perhaps as you say you can open sourcce the feed parsing code as part of WebKit and thus enable folks to improve it. |
| 09:14 | <othermaciej> | I think open sourcing the code would also likely lead to it being greatly simplified and improved |
| 09:14 | <Hixie> | tantek: that makes sense (using class for back compat vs using microdata when it makes sense going forward) |
| 09:15 | <othermaciej> | because WebKit has much higher standards for code quality than most Apple-internal code |
| 09:16 | <tantek> | othermaciej - in case you want to try experimenting with that code with a bunch of other microformats folks/devs to bounce ideas/thoughts off of - I encourage you (and anyone else here interested in microformats development) to participate in microformatsDevCamp July 25-26 http://microformats.org/wiki/events/2009-07-25-dev-camp |
| 09:16 | <Hixie> | one thing that's unclear to me when it comes to splitting off the vocabularies is how to handle the HTML->Atom and HTML->RDF sections |
| 09:17 | <MikeSmith> | othermaciej: that's kind of a little bit disturbing to hear (about Apple-internal code standards vs Webkit standards) |
| 09:17 | <tantek> | Hixie, that's good to hear, and not surprising, given that we both have a bit of a bias for back compat, while incrementally improving things in the future. |
| 09:17 | <tantek> | Hixie, HTML to Atom will likely be handled in the hAtom update. |
| 09:17 | <Hixie> | tantek: indeed :-) |
| 09:17 | <othermaciej> | MikeSmith: so you're saying, given how terrible WebKit is, you're surprised Macs and iPhones even boot? |
| 09:17 | <MikeSmith> | heh |
| 09:17 | <MikeSmith> | no, not at all man |
| 09:18 | <Hixie> | specifically i mean how to handle http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#atom |
| 09:18 | <othermaciej> | Hixie: HTML->RDF isn't really a custom vocabulary |
| 09:18 | <tantek> | HTML -> RDF is more complicated (everything is more complicated with RDF) and will require an update to XMDP |
| 09:18 | <Hixie> | and how to handle http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#rdf |
| 09:18 | <Hixie> | othermaciej: no but it references the custom vocabularies |
| 09:18 | <Hixie> | othermaciej: HTML->Atom is not a custom vocab at all either |
| 09:18 | <MikeSmith> | othermaciej: just that I would hope Apple-internal code standards would be as exacting was you guys |
| 09:18 | <Hixie> | othermaciej: but it reuses the vcard vocabulary to get people's names out and suchlike |
| 09:19 | <othermaciej> | MikeSmith: we have hundreds of people looking at our code every day |
| 09:19 | MikeSmith | catches up on othermaciej's actual joke |
| 09:19 | <Hixie> | i think i might just leave those parts in the html5 spec proper and have references out -- it's not like the reference needs to be normative |
| 09:19 | <othermaciej> | few projects are like that, open source or not |
| 09:19 | <tantek> | Hixie, I wonder, if the 'profile' attribute helped enable XMDP, and thus automatic conversion from HTML to RDF, would that be sufficient to add it back (in contrast to say, the "about" attribute, which is brand new as far as HTML is concerned). |
| 09:19 | <MikeSmith> | othermaciej: yeah, understood. it's unique in a number of ways |
| 09:20 | <MikeSmith> | or at least quite exceptional in a number of ways (if not unique) |
| 09:20 | <othermaciej> | and we tend to attract people who are fussy about code quality details |
| 09:20 | <Hixie> | tantek: not sure what you mean |
| 09:20 | <Hixie> | tantek: the HTML->RDF section is "automatic conversion from HTML to RDF" already |
| 09:20 | <tantek> | but requires the new "about" attribute IIRC |
| 09:20 | <Hixie> | there's a new "about" attribute? |
| 09:21 | <Hixie> | we may be talking about something else |
| 09:21 | <tantek> | I thought I saw a diff that introduced it - perhaps relating to the licensing vocab |
| 09:21 | <tantek> | I did notice that the citation/bibtex vocab got removed |
| 09:21 | <Hixie> | there's an itemprop="about" field, if that's what you mean, but that's not really RDF-specific (though it is a key part of the subpart of the HTML->RDF conversion concerned with converting microdata) |
| 09:22 | <Hixie> | (that's just one part of the algorithm though) |
| 09:22 | <Hixie> | (there's lots of other stuff in that algorithm, like converting <blockquote cite=""> to RDF statements, etc) |
| 09:22 | <tantek> | yes - I believe that's what I'm referring to. |
| 09:22 | <tantek> | (the itemprop="about" thing) |
| 09:24 | <tantek> | frankly, I think the whole approach of encouraging the inclusion of invisible hyperlinks in content (what the "about" design does in RDF/RDFa) is fundamentally flawed. the "dark data" problem as it were. |
| 09:25 | <Hixie> | yeah. that's why i like itemprop=about -- it encourages people to use <img> or <a href=""> to say what they're talking about |
| 09:25 | <Hixie> | i was quite honestly surprised that RDFa really doesn't make the licensing use case as easy as microdata can |
| 09:25 | <Hixie> | i sent a mail about that where i showed what i thought the best you could do with RDFa was, and it was surprisingly verbose compared to what i ended up with with microdata |
| 09:26 | <Hixie> | including some duplication of data, which violates what i thought was an RDFa design goal (DRY) |
| 09:26 | <boblet> | sorry—cake attack |
| 09:27 | <gsnedders|work> | Hixie: The aim is to make it impossible to create multiple body elements except by using DOM manipulation, right? |
| 09:28 | <Hixie> | gsnedders|work: not especially, why? |
| 09:28 | <boblet> | tantek: will current Microformats be released in Microdata format at some stage? |
| 09:28 | <gsnedders|work> | Hixie: See my email to public-html yesterday |
| 09:28 | <gsnedders|work> | Hixie: Just having two body elements seems somewhat ugly |
| 09:29 | <tantek> | boblet - doubtful. but will likely happen is that microformats.org will document how to use *any* microformat generically using microdata syntax. watch this page for updates: http://microformats.org/wiki/html5 |
| 09:30 | <Hixie> | gsnedders|work: it's on the pile |
| 09:30 | <gsnedders|work> | Hixie: Yeah, I knew it would be :) |
| 09:30 | <boblet> | thanks, will do |
| 09:30 | <boblet> | Hixie: I understand about the work required in HTML5. Good to hear you think post-HTML5 release cycles will be faster |
| 09:31 | <Hixie> | ideally i'd like html to move to a continuous development cycle instead of the w3c process of long drawn out lc/cr/pr/rec |
| 09:32 | <tantek> | Hixie, a continuous development cycle may be possible if you incorporate TDD. |
| 09:32 | <gsnedders|work> | Just publish second, third, fourth, etc. edition of HTML 5, hence avoiding that. |
| 09:32 | <Hixie> | TDD? |
| 09:32 | <tantek> | test driven development |
| 09:33 | <tantek> | thus each feature can quickly progress through wd/ts/cr via interop |
| 09:33 | <Hixie> | i think it'd be possible even without that |
| 09:33 | <Hixie> | though it would certainly help |
| 09:33 | <tantek> | relatively in parallel |
| 09:33 | <Hixie> | the problem is the forking of the spec source, not the testing |
| 09:34 | <gsnedders|work> | Using some sane VCS should mitigate most of that |
| 09:34 | <othermaciej> | it's hard to implement against a constantly evolving snapshot |
| 09:34 | <boblet> | I hope *all* major browser makers have got on the train by the time that happens :) |
| 09:34 | <tantek> | as long as the tests are clustered by / attached to section of the spec, presumably the tests would fork along with their respective spec prose. |
| 09:34 | <tantek> | othermaciej - believe me, I sympathize with that. |
| 09:34 | <Hixie> | othermaciej: that's unaffected by this, since in practice all the implementation work happens before we get to LC anyway |
| 09:34 | <othermaciej> | and it's hard to be confident in an implementation without a thorough test suite, which is also very hard to develop against a constantly evolving snapshot |
| 09:34 | <tantek> | (ahem, CSS 2.0 vs. CSS 2.1 etc.) |
| 09:35 | <othermaciej> | Hixie: hopefully - some HTML5 features that seem useful still have 0 implementations |
| 09:35 | <Hixie> | gsnedders|work: i'm not aware of any good VCS that handles forking over multiple years in what i would consider a "sane" manner |
| 09:35 | <tantek> | btw in terms of "how do I use microformats with a specific version of HTML", I drafted this as a start: http://microformats.org/wiki/HTML3 |
| 09:35 | <gsnedders|work> | Hixie: I think is mainly depends on quite how much they diverge |
| 09:35 | <Hixie> | gsnedders|work: i'd expect that to be "a lot" |
| 09:35 | <gsnedders|work> | Hixie: I expect HTML 6 would mainly add stuff to it |
| 09:36 | <Hixie> | if i add stuff into the middle of the navigation algorithm, no amount of VCS is going to keep me sane |
| 09:36 | <othermaciej> | but really the challenge for using the spec is not just new features (where naturally you look there first) but rather aligning old implementations of features that used to be in the mutual reverse engineering domain with the spec |
| 09:36 | <takkaria> | othermaciej: it's also hard to write tests for a evolving snapshot, which is part of the problem... |
| 09:36 | <othermaciej> | takkaria: indeed - I believe I mentioned that above |
| 09:36 | <Hixie> | othermaciej: yeah |
| 09:37 | <takkaria> | othermaciej: ah, I misparsed :) |
| 09:37 | <othermaciej> | it will be very hard to every fully support HTML5 without a "bug fix only" branch |
| 09:37 | <Hixie> | how do you mean? |
| 09:37 | <othermaciej> | (a bug-fix-only branch of the spec that is) |
| 09:37 | <boblet> | Hixie: returning to the elements vs role conversation, while you’re not starting from scratch I perceive HTML5’s structural elements as new as role would be, so I’m still wondering why elements over role |
| 09:38 | <Hixie> | othermaciej: oh if we keep adding new features, we'll never get to the point where there are two full impls, sure |
| 09:38 | <othermaciej> | a version of the spec that only corrects errors, doesn't add new functionality, so that you can go through methodically without it changing out from under you |
| 09:38 | <boblet> | are there any advantages of using elements, or conversely are there any disadvantages of using roles? |
| 09:38 | <Hixie> | boblet: because <foo> is nicer to type than <z z="foo"> |
| 09:39 | <boblet> | Hixie: yep, that’s a good reason |
| 09:39 | <Hixie> | boblet: if the syntax made it easier to have nodes in the DOM be given multiple labels at once, e.g. if the syntax had <a b c> as equivalent to <c b a> or <b a c> or whatever, that'd be a very different story |
| 09:39 | <othermaciej> | software projects pretty commonly have stable and new development branches, rarely ones that live for years, but that is not unprecedented |
| 09:40 | <Hixie> | othermaciej: yeah, it may be that that the benefits to implementors are worth the pain to the spec writer :-) |
| 09:40 | <Hixie> | othermaciej: i've never heard of any project that had a branch that lasted more than about a month where people on the project haven't complained that it was a mistake |
| 09:41 | <Hixie> | and i've heard of _many_ such branches |
| 09:41 | <othermaciej> | WebKit has had stable branches last over a year that we actually shipped off of, but they didn't have direct new development and the longer you go the harder it gets to backport fixes |
| 09:42 | <tantek> | othermaciej - indeed, your revising of specs points are good ones. |
| 09:42 | <boblet> | Hixie: not sure I understood that :) what about <ul role="aside nav"> vs <aside><nav><ul> for article section links? |
| 09:42 | <othermaciej> | we didn't really complain about that except to the extent that backporting bug fixes is less fun than new development |
| 09:42 | <tantek> | for this reason I'm simultaneously editing an hCard 1.0.1 and hCard 1.1. |
| 09:43 | <othermaciej> | although the one time we tried feature development based on an old branch - it was hell |
| 09:43 | <Hixie> | boblet: <aside><nav> is redundant, just use <nav>, but in general i'd say the role="" alternative looks much uglier and doesn't really get you any useful benefits. |
| 09:43 | <gsnedders|work> | othermaciej: It'd be nice to have an infinitely large test suite and a no-regressions policy so you could always ship the latest code :) |
| 09:43 | <Hixie> | boblet: again, because of the way the DOM works, there are things that are much harder to do if you put the semantics in attributes |
| 09:43 | <gsnedders|work> | (But yeah, that's mainly idealistic) |
| 09:43 | <othermaciej> | sadly, our test suite is not yet infinite |
| 09:44 | <Hixie> | boblet: e.g. <z z="audio applet"> -- does it have an HTMLAudioElement interface, or an HTMLAppletElement interface? |
| 09:44 | <Hixie> | boblet: does it spawn an applet or play audio? |
| 09:44 | <Hixie> | boblet: similarly, consider the huge pain that <input type=""> has been in terms of changing the implementation of the widget dynamically |
| 09:44 | <othermaciej> | <input type="bad design"> |
| 09:44 | <Hixie> | boblet: what happens when a script changes a <z z="iframe"> to a <z z="embed">? |
| 09:45 | <Hixie> | othermaciej: it's the same design as role="", basically |
| 09:45 | <gsnedders|work> | Hixie: Is that really any worse than changing tagName? |
| 09:45 | <boblet> | Hixie: ok thanks for the detailed explanation. I think I understand the issue a lot better now. Will have to chat more about this with John the next time he’s over |
| 09:45 | <othermaciej> | Hixie: preaching to the choir, sir |
| 09:46 | <Hixie> | gsnedders|work: you can't change tagname |
| 09:46 | <gsnedders|work> | localName? |
| 09:46 | <Hixie> | you can't change localname either |
| 09:46 | <gsnedders|work> | readonly too |
| 09:46 | <othermaciej> | although type="" is more narrowly scoped and the corner cases of the behavior are now reasonably well defined, so it's relatively tamed |
| 09:46 | <gsnedders|work> | How boring. |
| 09:47 | <othermaciej> | there is renameNode() in DOM Level 3 Core |
| 09:47 | <Hixie> | othermaciej: it certainly was significant effort to define how on earth to handle type="" changes :-) |
| 09:47 | <othermaciej> | but I would expect browser-hosted implementations to always make a new node for that |
| 09:47 | <Hixie> | (renameNode() creates a new node and copies the attributes over, basically) |
| 09:48 | <boblet> | It’d be a good idea for this to be addressed in the FAQ sometime as it’s a pretty popular topic atm (eg recent zeldman.com article comments) |
| 09:48 | <othermaciej> | it gives implementations the option to actually change the existing node's tag name, but that would be dumb |
| 09:49 | <Hixie> | boblet: please feel free to collect the responses here into a coherent entry for the faq and to add it :-) |
| 09:50 | <boblet> | Hixie: d’oh! :) |
| 09:50 | <Hixie> | othermaciej: it's especially bad if it means some UAs return the same node and others have two nodes |
| 09:50 | <boblet> | oh btw if anyone has the time (har!) to check out some articles I wrote on HTML5 I’d appreciate some feedback |
| 09:51 | <boblet> | The most recent one is: http://bit.ly/TE2TL “HTML5 structure—HTML4 and XHTML1 to HTML5” |
| 09:51 | <othermaciej> | Hixie: I could rant for a long time about the many bad ideas in the DOM, but I'm just going to remind myself of the channel topic |
| 09:51 | <Hixie> | heh |
| 09:53 | <boblet> | thanks for your time all. Later! |
| 09:54 | <tantek> | heh indeed |
| 09:54 | <tantek> | that seems like an appropriate note to call it a night. |
| 09:54 | <Hixie> | nn |
| 09:54 | <tantek> | thanks for the updates and feedback Hixie and othermaciej. |
| 10:00 | gsnedders|work | normally calls this a morning |
| 10:19 | <zcorpan> | http://simon.html5.org/test/html/semantics/video/support/video.php - chrome seems happy to ignore mime type in <video> |
| 10:19 | <Hixie> | doublec: ^ |
| 10:19 | <gsnedders|work> | Hixie: You've gone for the night! Go way! |
| 10:20 | <Hixie> | i did? |
| 10:21 | <Hixie> | zcorpan: what's the actual type of that video? |
| 10:21 | <zcorpan> | Hixie: it's an ogg/theora/vorbis file |
| 10:22 | <Hixie> | huh. i don't remember installed xiph codecs, i wonder when i did that |
| 10:25 | <gsnedders|work> | When you thought it was a good idea? |
| 10:27 | <zcorpan> | i just updated webkit and now it's giving a crash dialog all the time... but the safari window is still open and more or less usable |
| 10:27 | <zcorpan> | oh well |
| 11:03 | <hsivonen> | Hixie: the problem <div role=navigation> solves compared to <nav> is the parsing of <p>foo<nav><p>bar... in legacy browsers |
| 11:06 | <Hixie> | that's it? |
| 11:06 | <Hixie> | that's what has everyone up in arms? |
| 11:07 | <Lachy_> | Hixie, yeah, that and the perception that role="" is more extensible than creating new elements |
| 11:09 | <Philip`> | I thought everyone wanted to write XHTML-like strict syntax with closing tags and everything, so implied </p>s wouldn't make a difference |
| 11:09 | <hsivonen> | tantek: btw, regarding your earlier comments about XSLT, XHTML and performance: with the Validator.nu HTML Parser, the step of serializing as XHTML5 and reparsing as XML is optimized away |
| 11:09 | <hsivonen> | tantek: (earlier as in a week or so earlier) |
| 11:10 | <hsivonen> | Philip`: I'm leaning towards making implied </p> closes warnings even when V.nu users don't ask for it |
| 11:10 | <hsivonen> | Philip`: with the new structural elements, omitting </p> may be a real compat issue |
| 11:11 | <zcorpan> | hsivonen: but not for e.g. <p><p>? |
| 11:12 | <Philip`> | hsivonen: I might like it to silently accept <p>...<p>... and <div><p>...</div>, but warn if the </p> is implied by a start tag other than <p> |
| 11:12 | <hsivonen> | zcorpan: I can imagine that making it an unconditional warning for <p>foo<p>bar could annoy people |
| 11:12 | <hsivonen> | Philip`: makes sense |
| 11:12 | <zcorpan> | hsivonen: i think p and form have weird parsing in various browsers |
| 11:13 | <zcorpan> | <p><form>, <form><p></form>x, etc |
| 11:13 | <zcorpan> | <p><table> in ie7 |
| 11:15 | <zcorpan> | hsivonen: if you have an option to warn for all implied tags, you could make it clear in the UI that it's for debugging rather than Superior Correctness |
| 11:16 | <hsivonen> | zcorpan: any suggestions on how to make it clear? |
| 11:16 | <zcorpan> | Debugging options: show messages for implied tags |
| 11:17 | <zcorpan> | maybe could have them as Info rather than warning |
| 11:17 | <hsivonen> | zcorpan: yeah, info makes sense |
| 11:20 | <hsivonen> | Hixie: the other problem that role=navigation solves is that you can overlay role=navigation onto an <ul> |
| 11:20 | <hsivonen> | Hixie: no, I don't understand why the extra DOM node / CSS box for <nav> is an issue |
| 11:20 | <mookid> | Hixie: discussion on that blog post I linked to yesterday is on-going, be good to get some feedback from your end :) |
| 11:21 | <hsivonen> | I wish we could put a swift end to the "HTML is sloppy" meme, but I guess it's futile to try as long as implied tag messages on V.nu are vaporware |
| 11:21 | <Hixie> | hsivonen: the question "what problem does it solve" sort of asks for the answer to be a problem, not a random feature of questionable value :-P |
| 11:22 | <Hixie> | i wish i understood why implied tags are sloppy |
| 11:22 | <hsivonen> | Hixie: I know |
| 11:22 | <hsivonen> | Hixie: feel free to ask people who prefer role=navigation why they prefer it |
| 11:23 | <hsivonen> | I also don't understand why it's important to care about being consistent with <br> vs. <br/> within a document but not so important to care about consistency with <br/> vs. <br /> |
| 11:24 | <mookid> | Hixie: implied tags will bring pain and hurt the same way that semi-colon insertion causes problems in javascript |
| 11:24 | <hsivonen> | I think the difference between <br>, <br/> and <br /> isn't something a validator should whine about. I think it's something that a "reformat code" command in a text editor should fix |
| 11:25 | <Hixie> | i don't understand why people want the /> at all |
| 11:25 | <gsnedders|work> | Hixie: Because it is explicit and you don't need to remember what tags are implicit |
| 11:25 | <Hixie> | i really hate it personally |
| 11:25 | <mookid> | it's the parser equivalent of bank-bailouts |
| 11:25 | <Hixie> | gsnedders|work: i really can't say i've ever found that a problem |
| 11:25 | <hsivonen> | gsnedders|work: you need to remember which tags are implicit anyway. |
| 11:26 | <zcorpan> | allowing /> has the drawback that people think they can write <div/> too |
| 11:26 | <hsivonen> | gsnedders|work: </p> won't help you when you write <p>foo<table>...</table>bar</p> |
| 11:26 | <hsivonen> | zcorpan: indeed |
| 11:26 | <hsivonen> | zcorpan: /> confuses the mental model people have |
| 11:26 | <gsnedders|work> | hsivonen: Yeah, right. But if you disallow implicit tags… |
| 11:26 | gsnedders|work | doesn't think doing so is a good idea though |
| 11:26 | <Lachy> | hsivonen, warning about implied </p> when it's implied by one of the new HTML5 sectioning elements would be valuable for compat reasons. But warning about when it's implied by <p> or <div> is too much |
| 11:27 | <zcorpan> | Lachy: what about <p><form>? |
| 11:27 | gsnedders|work | thinks unquoted attribute values starting with ` should be non-conforming, for IE compat. |
| 11:27 | <hsivonen> | Lachy: what about <p><table>? |
| 11:29 | <mookid> | you poor people realy have to go through all this stuff every day don't you? |
| 11:30 | <mookid> | pretty thankless task |
| 11:31 | <mookid> | good on you :) |
| 11:33 | <hsivonen> | maybe knowing when omitting quotes is OK should be positioned as professional 1337 skillz instead of positioning quote omission as sloppy :-) |
| 11:33 | <Lachy> | hsivonen, zcorpan, I'm not sure about those |
| 11:34 | <Lachy> | IIRC, HTML5 says those should imply </p>, right? |
| 11:34 | <gsnedders|work> | Lachy: yes |
| 11:34 | <othermaciej> | I used to like always quoting just to avoid wondering whether I had to |
| 11:34 | <Lachy> | which browser doesn't do that? Is it just IE? |
| 11:35 | <othermaciej> | now I drop the quotes only when I'm sure they are not needed (e.g. attribute value is a single purely alphanumeric word) |
| 11:35 | <gsnedders|work> | IE < 8 and IE 8 when not in IE8 mode |
| 11:36 | <othermaciej> | I still like providing implied open and close tags because the more I learn about the rules for those, the less confident I am of ever getting them right |
| 11:36 | <Lachy> | hmm, ok. that makes them problematic, at least for now |
| 11:37 | <gsnedders|work> | othermaciej: If you ignore where whitespace goes they aren't that complex |
| 11:37 | <Lachy> | othermaciej, I never found the rules for implied tags complicated. At least for HTML4, they seemed fairly intuitive. |
| 11:37 | <hsivonen> | the only time I've had trouble with authoring quoteless attributes was when I had /> immediately after |
| 11:37 | <hsivonen> | those two features aren't nice together |
| 11:38 | <Lachy> | othermaciej, do you always include <tbody>? From my experience, that's one of the few that most people leave out |
| 11:38 | <othermaciej> | no, not <tbody> |
| 11:38 | <othermaciej> | I didn't even know it existed until after I started working on a Web browser |
| 11:38 | <Lachy> | I usually leave it out, except when I also use <thead> |
| 11:39 | <othermaciej> | of course that's almost 8 years ago now |
| 11:40 | <othermaciej> | I was thinking to myself who might have the record for working the longest continuously on a single browser, and I am betting it's someone at Opera |
| 11:40 | <othermaciej> | at least if you don't count Netscape/Mozilla/Firefox as a single browser lineage |
| 11:41 | <zcorpan> | we have a number of people who have worked more than 8 years at opera |
| 11:41 | <Lachy> | othermaciej, that's possible. We have a few staff who've been here for 10 years. Then there's people like Jon and Håkon who've been here since the beginning. |
| 11:42 | <Hixie> | othermaciej: hyatt's high up on that list i'm sure |
| 11:42 | <Hixie> | Lachy: howcome wasn't at opera since the beginning |
| 11:42 | <othermaciej> | IE had a break and I count Netscape --> Firefox as a discontinuity although I'm not going to declare exactly where it happened |
| 11:42 | <Lachy> | wasn't he? |
| 11:42 | <Hixie> | brendan too |
| 11:42 | <Hixie> | (brendan would be high on the list i mean) |
| 11:43 | <Hixie> | oh on a single browser |
| 11:43 | <othermaciej> | yeah |
| 11:43 | <Hixie> | as opposed to browsers in general |
| 11:43 | <Hixie> | hm |
| 11:43 | <Hixie> | hard to say what a single browser is really |
| 11:43 | <Hixie> | netscape->firefox probably was less of a change than some opera releases |
| 11:43 | <othermaciej> | on browsers continuously in general, then yeah, probably some Mozilla people have a good claim |
| 11:44 | <hsivonen> | Dan Mosedale would probably be high on the list |
| 11:46 | <othermaciej> | would he still count as "working on a browser"? |
| 11:48 | <hsivonen> | hmm. MailCo... |
| 12:02 | <Philip`> | "< Lachy> IIRC, HTML5 says those should imply </p>, right?" ... "I never found the rules for implied tags complicated" - if they're not complicated, why did you sound so uncertain about those cases? :-) |
| 12:04 | <Lachy> | Philip`, I couldn't remember if HTML5 changed those rules. |
| 12:04 | <Lachy> | I remember there was discussion about doing that, at least for <p><table> |
| 12:05 | <Hixie> | this is why i don't change the rules willy nilly and try to keep them as simple as possible :-P |
| 12:05 | <Philip`> | So it sounds like they are a bit complicated |
| 12:06 | <Lachy> | Philip`, you also quote mined me. I also said "At least for HTML4, they seemed fairly intuitive." |
| 12:07 | <hsivonen> | is there a Mail.app solution for marking dupes in www-archive read if I've already read them in my WHATWG/public-html folder? |
| 12:07 | <Hixie> | he doesn't like my solution :-P |
| 12:07 | <Hixie> | (route all mail through gmail) |
| 12:08 | <Lachy> | Hixie, how does routing it all through gmail help? |
| 12:08 | <Hixie> | gmail coallesces duplicate e-mails |
| 12:08 | <Hixie> | my mind just exploded |
| 12:08 | <hsivonen> | Hixie: how does gmail figure out what my preferred folder for a given email is? or do they show up in all folders but get marked read? |
| 12:08 | <Hixie> | steven pemberton just told me something was "not valid, but permitted" |
| 12:08 | <Lachy> | wtf? |
| 12:08 | <hsivonen> | Hixie: URL? |
| 12:09 | <gsnedders|work> | Is there any way to get the interface of an element (given a DOM element node)? |
| 12:09 | <Hixie> | hsivonen: if you get multiple copies of an e-mail, it picks one of them and junks the rest. so, if you're using Sender: headers or some such for filtering, you get a random one. |
| 12:10 | <Hixie> | (this also means that if you're cc'ed on a message to a w3c list, you won't have the X-Archived-At headers, which is making it harder for me to give y'all a link to the aforementioned message) |
| 12:10 | <hsivonen> | Hixie: ah. when an email is sent to hsivonen⊙if, public-html and www-archive, I'd prefer to see only the public-html copy |
| 12:10 | <Hixie> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0117.html |
| 12:10 | <Lachy> | Hixie, I filter most of my mail based on the List-Id using .procmailrc |
| 12:10 | <Hixie> | hsivonen: yeah, you'd likely get the hsivonen⊙if copy (since gmail would see that one first) |
| 12:10 | <Hixie> | (i use recipient filtering to get around this) |
| 12:11 | <hsivonen> | Hixie: wow. (at Steven) |
| 12:12 | <gsnedders|work> | So he's basically just saying HTML 4.01 has rules for invalid content. |
| 12:12 | <hsivonen> | Hixie: that reminds me of the novel interpretations of what XML 1.0 says about error handling |
| 12:13 | <Philip`> | If it's permitted, what is not permitted? |
| 12:13 | gsnedders|work | isn't sure he understands the email |
| 12:14 | <gsnedders|work> | Still, is there any way to get the interface implemented by a DOM element node? |
| 12:14 | <Philip`> | (It makes sense that it's permitted in the sense that nobody will come and shoot you if you write it, even though it's invalid, but that applies to all strings of bytes so it's not a very interesting distinction, and I'm not sure what sense makes more sense) |
| 12:14 | <Lachy> | I'd want a way to have my mail filtering work much more like usenet newsgroups work with good clients. i.e. Dupes get filtered into individual mailing list folders, but when one is read in one folder all dupes with the same message ID get marked as read too. |
| 12:15 | <othermaciej_> | he doesn't really explain what "permitted but invalid" means |
| 12:15 | <othermaciej_> | maybe you have his permission to make invalid documents |
| 12:15 | <othermaciej_> | (thanks Steve!) |
| 12:16 | <Lachy> | I find Steven's message confusing, since he claims that HTML5 conflates the issue of conformance and processing, but it is in fact his claims that seem to do that |
| 12:17 | <Lachy> | since he quoted a processing requirement to back up his claim that something was permitted, despite being invalid |
| 12:19 | <Lachy> | wow, his understanding of HTML vs. XHTML and MIME types is even more twisted. http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0118.html |
| 12:20 | <gsnedders|work> | Lachy: Find a normative statement to disprove that. |
| 12:21 | <Lachy> | gsnedders|work, disprove what? |
| 12:21 | <hsivonen> | Lachy: I think the opinion on MIME types is not news |
| 12:21 | <gsnedders|work> | Lachy: Find something that means that MIME types have to describe the data. |
| 12:23 | <Hixie> | gsnedders|work: i plan to include that statement in my updates of the mime registrations for text/html and application/xhtml+xml, fwiw |
| 12:23 | <gsnedders|work> | And that isn't going to happen until we reach REC, I guess |
| 12:24 | <Lachy> | gsnedders|work, "Content-Type specifies the media type of the underlying data." -- RFC 2616 section 7.2.1 |
| 12:24 | <gsnedders|work> | Lachy: That's an informative statement. |
| 12:25 | <gsnedders|work> | Lachy: There was a long discussion about this on ietf-http-wg |
| 12:25 | <Lachy> | in a normative section? |
| 12:25 | <gsnedders|work> | That doesn't make it normative. |
| 12:26 | <Hixie> | gsnedders|work: i plan to start doing it next month, dunno how the ietf will take it though |
| 12:26 | <gsnedders|work> | Hmm, text/html and application/xhtml+xml are only informational RFCs |
| 12:26 | <gsnedders|work> | And as they are informational, I don't think you can have normative requirements (as otherwise it isn't informational) |
| 12:30 | <Hixie> | ...for now |
| 12:30 | <othermaciej> | the MIME type dictates processing, it makes sense that it should dictate conformance |
| 12:31 | <gsnedders|work> | othermaciej: What, normatively, says the MIME type dictates processing? |
| 12:31 | <othermaciej> | what makes sense is to figure out how to spec that soundly, rather than to quibble about whether it is the case |
| 12:31 | <Hixie> | christ it's late |
| 12:31 | <Hixie> | when did that happen |
| 12:31 | <gsnedders|work> | Hixie: Well, you said "nn" several hours ago |
| 12:31 | <othermaciej> | gsnedders|work: nothing says that normatively - it's just true as a fact of reality |
| 12:31 | <Hixie> | i was saying that to tantek who said he was going to bed |
| 12:32 | <gsnedders|work> | Hixie: Oh, OK. I thought you were too. |
| 12:32 | <Hixie> | lord no, it was barely midnight |
| 12:32 | gsnedders|work | facepalms |
| 12:33 | gsnedders|work | still wants an answer to his question (of whether you can find out what interface a DOM element implements) |
| 12:33 | <gsnedders|work> | (Like whether it is just HTMLElement or some sub-interface) |
| 12:34 | <othermaciej> | gsnedders|work: you mean from code? |
| 12:34 | <gsnedders|work> | othermaciej: Yes, from JS |
| 12:35 | <Lachy> | gsnedders|work, if (elm instanceof HTMLFooElement) { ... } else if (elm instanceof HTMLBarElement) ... |
| 12:36 | <gsnedders|work> | Lachy: No way to just get the name as a string or whatever? |
| 12:36 | <othermaciej> | instanceof would be a sound way - a hackier way would be to toString() it and remove the "[object " prefix and "]" suffix |
| 12:36 | <Lachy> | yeah, toString() could work, but no guarantee of its reliability |
| 12:36 | <othermaciej> | (neither of these techniques will tell you all implemented interfaces, just the one that the implementation considers the "class") |
| 12:37 | <gsnedders|work> | Lachy: Unreliable how? |
| 12:37 | <gsnedders|work> | othermaciej: Yeah, right |
| 12:37 | <othermaciej> | I seem to recall some spec adding requirements for toString (can't remember if it was HTML5 or Web IDL) |
| 12:37 | <Hixie> | toString() will fail for some elements like HTMLAnchorElement (<a>) which stringify |
| 12:37 | <othermaciej> | but I don't think IE will do it |
| 12:38 | <gsnedders|work> | Oh yay |
| 12:38 | <othermaciej> | good point |
| 12:38 | <hsivonen> | the RDFa TF thread is http://archive.scripting.com/2003/06/13#When:8:12:30AM all over again |
| 12:39 | <Hixie> | julian and i actually agree on something |
| 12:39 | <Lachy> | IE8 seems to do it properly in IE8 mode, but IE7 mode and earlier generally just return "[object]" for most elements |
| 12:39 | <Hixie> | now i KNOW i have to go to bed, i'm clearly halucinating |
| 12:39 | <gsnedders|work> | Quick, go quiet in here! |
| 12:41 | <zcorpan> | Philip`: research time :-) type="video/..." or type="audio/..." (or single quotes) |
| 12:41 | <zcorpan> | Philip`: i'd like to know common values for the ... in html pages |
| 12:41 | Lachy | must get back to work. I need to answer complicated questions for my US work visa, explaining why the US should let Opera employ me there, instead of hiring a US citizen. |
| 12:42 | <Philip`> | zcorpan: I hope it can wait, since I should probably unplug my computer to avoid the possibility of it getting lightninged and I have no battery power left |
| 12:42 | <zcorpan> | Philip`: sure no rush |
| 12:42 | <Philip`> | Remind me later if I forget :-) |
| 12:43 | <gsnedders|work> | Lachy: I do like how a country founded on immigration is so hostile to immigrants |
| 12:44 | <zcorpan> | or possibly without quotes |
| 12:45 | <remysharp> | gsnedders|work: can I ask a Q about your outliner? |
| 12:45 | <gsnedders|work> | remysharp: Sure |
| 12:45 | <remysharp> | when it hits a section that doesn't have a title, it says untitled section |
| 12:45 | <gsnedders|work> | Right |
| 12:45 | <Lachy> | gsnedders|work, yeah, a lot of countries are becoming like that, unfortunately |
| 12:46 | <remysharp> | sorry - just checking what I wanted to ask - one mo... |
| 12:46 | <remysharp> | the spec says re: section: "typically with a heading" |
| 12:46 | <remysharp> | but if it doesn't contain a heading, is an outliner going to assume the heading then? |
| 12:46 | <remysharp> | this doesn't really come across in the current spec - so just checking really. |
| 12:47 | <gsnedders|work> | remysharp: That's up to the implementer |
| 12:47 | <gsnedders|work> | remysharp: I took the solution of giving "Untitled Section" |
| 12:47 | <remysharp> | okay, but it's fair to say that it could just be ignored in the TOC too? |
| 12:48 | <gsnedders|work> | Yeah |
| 12:48 | <remysharp> | I guess in a way, your outliner is making me question my use of <section> - so perhaps I should have used a <div> in certain places. |
| 12:48 | <gsnedders|work> | I think Anolis does that, but mainly because I meant it to say "Untitled Section" but I screwed up :) |
| 12:49 | <gsnedders|work> | remysharp: Yeah, I wanted to point out untitled sections there |
| 12:49 | <zcorpan> | gsnedders|work: maybe you should make "Untitled Section" italic or something |
| 12:49 | <gsnedders|work> | remysharp: But otherwise it's somewhat missing some sections, which seems suboptimal for an outline |
| 12:49 | <gsnedders|work> | zcorpan: Yeah, probably |
| 12:50 | <remysharp> | Here's the url I'm running it against: http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Ffull-frontal.org |
| 12:50 | <remysharp> | The thing is - |
| 12:50 | <remysharp> | is that it's putting untitled section at the top level |
| 12:50 | <remysharp> | which looks like the title of the toc |
| 12:50 | <remysharp> | *doc |
| 12:50 | <remysharp> | but it's not - I've used a <section> to align the page to the centre |
| 12:51 | <remysharp> | rather than a <div> because IE would render the background of the <div> with JS off - so it's a reasonable work around to wrap with a <section> |
| 12:51 | <gsnedders|work> | zcorpan: It should do that now |
| 12:51 | <gsnedders|work> | No, it throws an error now |
| 12:51 | <gsnedders|work> | fail |
| 12:52 | <zcorpan> | remysharp: if you just want to center the page, don't use <section> |
| 12:52 | <gsnedders|work> | Now it works |
| 12:52 | <remysharp> | zcorpan: what would you suggest? |
| 12:52 | <Lachy> | remysharp, as a rule of thumb, I recommend that content with its own heading should use section (or other appropriate sectioning element), and otherwise just use div |
| 12:52 | <zcorpan> | remysharp: center the <body> |
| 12:53 | <zcorpan> | gsnedders|work: nice |
| 12:54 | <remysharp> | zcorpan: I'm going to test centering the body, but I'm not sure that's the right solution. |
| 12:54 | <remysharp> | As the big man said: I'll be back. |
| 13:01 | <remysharp> | zcorpan: centering half works |
| 13:01 | <remysharp> | technically it's the right thing |
| 13:02 | <remysharp> | but from a styling point of view, it means we (authors) lose flexibility to style our documents |
| 13:03 | <remysharp> | bah, I'm not sure there's a right answer, except whether untitled sections (i.e. lacking headings) should be included in the TOC since the spec says "typically" |
| 13:10 | gsnedders|work | is feeling distinctly "meh" at late '80s The Sisters Of Mercy |
| 13:13 | gsnedders|work | notes that coincides with the time that goth rock became popular… coincidence? |
| 13:14 | Lachy | wonders who The Sisters of Mercy are. |
| 13:16 | <gsnedders|work> | Lachy: http://en.wikipedia.org/wiki/The_Sisters_of_Mercy |
| 13:16 | <Lachy> | they appear to only be popular in the UK |
| 13:16 | <Lachy> | which would explain why I haven't heard of them or any of their songs |
| 13:23 | <hsivonen> | oh. crap. It seems I have a broken hard disk, and I lost data again. |
| 13:23 | <hsivonen> | something that I had sworn would never happen again |
| 13:23 | <Lachy> | hsivonen, no backup? |
| 13:23 | <hsivonen> | but I hadn't had the time to make everything work with my RAID |
| 13:24 | <hsivonen> | Lachy: I think there's a time window of photos without backups |
| 13:24 | <hsivonen> | sigh |
| 13:25 | <hsivonen> | ooh. ooh. maybe I do have that stuff on two disks |
| 13:25 | <hsivonen> | maybe I just lost some scanned receipts whose hard copies exist off-site anyway |
| 13:28 | <hsivonen> | I'm angry that other people are allowed to blow up bedrock and there's nothing I can do to keep them from sending shockwaves to my office |
| 13:29 | <Lachy> | hsivonen, do you know what it would cost to get the data professionally recovered |
| 13:29 | <hsivonen> | Lachy: too much |
| 13:29 | <Lachy> | ok |
| 13:30 | <hsivonen> | Lachy: at least it was too much when I last had a hard drive incident in 2004 or 2005 |
| 13:30 | <Lachy> | is the disk functional at all? |
| 13:31 | <hsivonen> | It makes bad noise and doesn't automount |
| 13:31 | <Lachy> | ok. That might make it difficult to use data recovery software |
| 13:32 | <hsivonen> | however, I have an offsite backup that was taken just a couple of days before that disk was cloned |
| 13:32 | <hsivonen> | and since then, I have done very little that I don't also have on the internal drive |
| 13:33 | <hsivonen> | anyway, I guess I'll just have to bite the bullet, take the offsite backup and merge it and the internal drive state to a RAID |
| 13:33 | <Lachy> | I'm hoping I never run into that problem again. Although, I need to keep increasing my amount of storage space. |
| 13:33 | <hsivonen> | the reason why I hadn't taken the RAID to use is that I was unable to get my whole home directory working off NFS |
| 13:34 | <hsivonen> | I think I'm going to try to use AFP with ~/Library on a local disk and everything else symlinked to the RAID |
| 13:34 | <Lachy> | so far, I'm up to 8TB worth of external drives. It's not quite enough though |
| 13:35 | <hsivonen> | I started to use Flickr in order to have an in-the-cloud copy of my photos, but I'm 7 months behind getting my photos uploaded |
| 13:37 | <Lachy> | I want an in-the-cloud copy of my ripped DVD collection. But I don't have the bandwidth up upload 2TB worth of ISOs, nor any cost effective storage provider |
| 13:37 | <hsivonen> | well, there are a ton of backups of popular culture around |
| 13:38 | <Lachy> | where? |
| 13:38 | <hsivonen> | I'm worried about data I produce myself and the isn't on Flickr, on hsivonen.iki.fi, in svn or in hg yet |
| 13:38 | <hsivonen> | in any DVD store |
| 13:38 | <Lachy> | that defeates the purpose of ripping the data off the discs in the first place |
| 13:42 | <hsivonen> | I did the stupid, stupid thing when the failed drive started making noise. I turned it off. I should have kept in on and started to copy it to another drive immediately. |
| 13:43 | <Philip`> | zcorpan: If you don't care about it being in a helpfully processed format, try http://philip.html5.org/data/type-audio-video-raw.txt |
| 13:46 | <hsivonen> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0128.html |
| 13:48 | <gsnedders|work> | Where is event-source nowadays? |
| 13:48 | <hsivonen> | gsnedders|work: in JS only |
| 13:48 | <hsivonen> | IIRC |
| 13:50 | <gsnedders|work> | hsivonen: What spec is it? Where? |
| 13:50 | <hsivonen> | oh. No idea. |
| 13:50 | <takkaria> | gsnedders|work: http://dev.w3.org/html5/eventsource/ |
| 13:50 | <gsnedders|work> | takkaria: thx |
| 13:51 | <takkaria> | gsnedders|work: honestly, http://lmgtfy.com/?q=EventSource+html5 |
| 13:52 | <gsnedders|work> | takkaria: Oh, I didn't include the html5 bit :P |
| 13:52 | <takkaria> | hsivonen: I don't even understand that message |
| 13:53 | <hsivonen> | http://www.zeldman.com/2009/07/16/html-5-is-a-mess-now-what/#comment-44915 |
| 13:53 | <hsivonen> | "Also, I got tired of really nasty people sending me almost illegal hate mail on these subjects – hardly a professional approach to doing business." |
| 13:53 | <hsivonen> | that's not good |
| 13:57 | hsivonen | wonders who has been sending hate mail in the name of HTML5 and what can be done about it |
| 14:07 | <Philip`> | I don't quite understand how he complains about it being Hixie's spec and a despotic regime, and then complains about design by committee - surely it can't be both? |
| 14:07 | Philip` | wonders if he's missing something |
| 14:08 | <takkaria> | I think that's part of the problem |
| 14:09 | hsivonen | also wonders if the hate mail has been actually sent by people or by *a* person |
| 14:15 | <Lachy> | I wonder why anyone would be sending him hate mail about HTML5? |
| 14:15 | <Lachy> | maybe it would be worth contacting him for clarification |
| 14:20 | <zcorpan> | Philip`: thanks! |
| 15:08 | <gsnedders|work> | Does Mozilla still support HTMLUnknownElement? |
| 15:09 | <Lachy> | gsnedders|work, <foo></foo><script>w(document.getElementsByTagName("foo")[0])</script> |
| 15:09 | <Lachy> | apparently, yes |
| 15:10 | <takkaria> | alert(HTMLUnknownElement) would work just as well, surely? |
| 15:11 | <Lachy> | takkaria, don't make things unnecessarily easy! |
| 15:12 | <takkaria> | k |
| 15:17 | <Philip`> | gsnedders|work: You should read through the source code to find out |
| 15:17 | <Philip`> | Anything else is just cheating |
| 15:18 | <gsnedders|work> | Philip`: or grep |
| 15:25 | <zcorpan> | Philip`: was the type="" thing from the 425k set? |
| 15:26 | <Philip`> | zcorpan: Yes |
| 15:27 | <zcorpan> | Philip`: ok |
| 15:31 | <gsnedders|work> | How can I stop if (HTMLUnknownElement) from throwing? |
| 15:32 | <gsnedders|work> | if (typeof HTMLUnknownElement != 'undefined') |
| 15:33 | <zcorpan> | gsnedders|work: yes |
| 15:34 | <zcorpan> | http://simon.html5.org/dump/type-audio-video-philip-dotbot.xml |
| 15:34 | <zcorpan> | also http://simon.html5.org/dump/type-audio-video-google-code-search.txt |
| 15:48 | zcorpan | added links to http://wiki.whatwg.org/wiki/Video_type_parameters |
| 15:53 | <zcorpan> | http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types - hmm, i can't find mime.types for apache 2.2.x |
| 15:54 | <zcorpan> | or is that the latest mime.types? |
| 16:04 | <zcorpan> | is the dom viewer broken in ie8 again? |
| 16:05 | <zcorpan> | or at least the w() function |
| 16:05 | <Rik|work> | zcorpan: xss protection ? |
| 16:05 | <zcorpan> | Rik|work: i have that disabled |
| 16:05 | <zcorpan> | ie says there's a script error |
| 16:38 | <remysharp> | there's an oninput event? |
| 16:38 | <sebmarkbage> | no, just in Gecko, and only for textareas/textboxes. |
| 16:38 | <remysharp> | ah, right. Hm - let me try to explain better |
| 16:38 | <remysharp> | if I use contenteditable on a p element |
| 16:38 | <sebmarkbage> | actually oninput is in HTML5 too |
| 18:43 | <takkaria> | gsnedders: I got it working. :) |
| 19:08 | <gsnedders> | takkaria: Oh dear… find something more useful! |
| 19:29 | gsnedders | finds a ton of tweets mentioning him, all because of Henny |
| 19:32 | <takkaria> | hm, it doesn't look like you can define getters on HTMLElement |
| 19:34 | <gsnedders> | Really? I think you _should_ be able to. |
| 19:34 | <gsnedders> | jgraham would know… |
| 19:34 | <gsnedders> | Wow, BTS3 is so much quicker than during work hours. |
| 19:35 | <takkaria> | hmm |
| 19:35 | <takkaria> | OK, I was being a bit hopeful really |
| 19:35 | <takkaria> | you can override it |
| 20:44 | <Sidnicious> | I want to ask a question to solve a discussion from #html: If one is abandoning XHTML for a page, should he use the new doctype or an HTML 4 doctype? How do older browsers handle <DOCTYPE html>? |
| 20:44 | <Sidnicious> | s/#html/#css/ |
| 20:46 | <Philip`> | Sidnicious: It makes old browsers render in standards mode (instead of quirks mode) |
| 20:47 | <Philip`> | Sidnicious: See e.g. the table near the bottom of http://hsivonen.iki.fi/doctype/ |
| 20:48 | <Sidnicious> | The people I'm talking to think of HTML 5 as separate from HTML 4, and believe that it's dangerous to use the new doctype until HTML 5 is officially supported by every popular browser |
| 20:50 | <gsnedders> | Sidnicious: It is officially supported to some extent in all browsers. |
| 20:50 | <Philip`> | Sidnicious: Every popular browser behaves precisely the same if you use <!DOCTYPE html> as if you use e.g. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">; |
| 20:51 | <Philip`> | Sidnicious: (That also works the other way, so you can use HTML5 features like <canvas> and <video> with an HTML4 doctype exactly the same as with the HTML5 doctype) |
| 20:53 | <Sidnicious> | Philip`: Great, thank you. |
| 20:56 | <gsnedders> | Sidnicious: The only difference is in what is conforming, and what throws a validation error (though almost everything from HTML 4.01 Strict is conforming HTML 5) |
| 22:15 | <gsnedders> | "Mark as read" on 500 emails feels good. |
| 22:15 | <takkaria> | disgusting |
| 22:15 | <Sidnicious> | But... but... you didn't read them! |
| 22:15 | <takkaria> | it's only 23:20, I'm sure you could read them all before bed :p |
| 22:16 | <gsnedders> | I don't read everything on help mailing lists! |
| 22:16 | <Philip`> | If you lie to your mail client like that, how do I know you're not going to lie to me? :-( |
| 22:16 | <ezyang> | You sir, need mail filters |
| 22:16 | <gsnedders> | ezyang: I have mail filters. |
| 22:16 | <ezyang> | oh ho, so it's not 500 emails in your inbox :-) |
| 22:16 | <gsnedders> | ezyang: Hell no, my inbox is almost always at zero unread. |
| 22:17 | <gsnedders> | ezyang: It's mainly css-d, thelist, MySQL General Discussion and such like which are unread |
| 22:17 | <Sidnicious> | gsnedders: At that point, why not just delete them and go to the list archives? Are you maintaining your own personal archive of each list? |
| 22:18 | <gavin_> | Hixie: is it just me or does http://www.whatwg.org/specs/web-apps/current-work/#concept-error-nothandled not point to the right place? |
| 22:18 | <gsnedders> | Sidnicious: Because then I have the hassle of resubscribing whenever I want to ask a question. |
| 22:18 | <gavin_> | it's one line below http://www.whatwg.org/specs/web-apps/current-work/#report-the-error |
| 22:18 | <Sidnicious> | No, I mean deleting older messages, keeping your subscription to the list. |
| 22:18 | <gsnedders> | Sidnicious: Oh, no reason |
| 22:18 | <gsnedders> | Sidnicious: Disk space is cheap |
| 22:19 | <Sidnicious> | Heh. Fair enough. |
| 22:19 | <gsnedders> | (Actually, that's not true, when dealing with quick 2.5" HDs disk space is fairly expensive, but I have bigger issues than email) |
| 22:20 | <Philip`> | Disk space is really cheap until you've got one byte more data than you have storage, and then it's really expensive |
| 22:20 | <ezyang> | gsnedders: you can totally have asubscription and instruct it not to send you messages. |
| 22:21 | <Philip`> | (though "really expensive" is relative to e.g. a packet of chocolate biscuits, rather than to e.g. a house) |
| 22:21 | <ezyang> | and then you add P.S. please cc |
| 22:21 | <gsnedders> | ezyang: That means remembering :) |
| 22:21 | <ezyang> | I mean, what mailman really should do is let you send only conversations that you care about :-) |
| 22:21 | <gsnedders> | ezyang: see http://www.flickr.com/photos/gsnedders/2185019213/ and http://www.flickr.com/photos/gsnedders/2185803994/ |
| 22:22 | <gsnedders> | ezyang: That's really out of date, I have more mailboxes than that now :) |
| 22:22 | <gavin_> | Hixie: er, I guess it is pointing to the right place (first mention?), but I don't see a definition there |
| 22:22 | <Philip`> | gavin_: Can you click the term to see a list of all the places it's mentioned? |
| 22:23 | <gavin_> | yes |
| 22:24 | <gavin_> | oh, is http://www.whatwg.org/specs/web-apps/current-work/#dfnReturnLink-0 the definition? |
| 22:24 | <gavin_> | I guess so |
| 22:24 | <Philip`> | That URL isn't going to work very well over IRC |
| 22:25 | <gavin_> | hmm? |
| 22:25 | <Philip`> | It's a locally-generated fragment ID |
| 22:25 | <gavin_> | huh? the page results are non-deterministic?/ |
| 22:26 | <gsnedders> | Hixie wrote it. Don't assume it will be. |
| 22:26 | <gavin_> | (why is it locally generated to begin with?) |
| 22:26 | <gsnedders> | gavin_: Because Hixie told me to write the script to do it on the server, and I haven't written it yet. |
| 22:27 | <Philip`> | gavin_: I think the idea is that when you click a use of a definition, it jumps to the use by giving it a locally-generated ID (because normally it's just an <a href> without an id) |
| 22:28 | <gavin_> | I see |
| 22:34 | <Hixie> | gavin_: the definition is the bold word that says "not handled" |
| 22:34 | <Hixie> | gavin_: it's just a constant. It could say "after which the error is either grapefruit or pineapple:" |
| 22:36 | <gavin_> | that's not what I'd call a definition |
| 22:37 | <gavin_> | but I get it now |
| 22:43 | <Hixie> | i agree that it's not really a definition. not sure what the definition would be though |
| 22:43 | <Hixie> | it's like "true" and "False" |
| 22:59 | <Hixie> | wow, talk about preaching to the choir http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0127.html |
| 22:59 | <Hixie> | steven pemberton is now lecuring _me_ on the "real world" and following what browsers do |
| 22:59 | <Hixie> | how the world has changed |