| 00:01 | <doodlewarrior> | i still dont understand why <header> cant just be <header>, like <footer> is <footer> |
| 00:01 | <doodlewarrior> | where <header> may or may not have h1...6 children |
| 00:01 | <Hixie> | Niictar: no (see the "content model" definition for <header> in the spec) |
| 00:01 | <Hixie> | doodlewarrior: pretend it's called <hgroup>, does it make sense then? |
| 00:02 | <Niictar> | Ok. That saves me typing up a test document, anyway |
| 00:02 | <doodlewarrior> | i dont mean to be irritating or anything, it just seems inconsistent |
| 00:02 | <doodlewarrior> | Hixie: if it were hgroup, it would make sense |
| 00:02 | <doodlewarrior> | but it would make more sense if it was header, but the h1...6 was optional |
| 00:04 | <Hixie> | just pretend it's called <hgroup> |
| 00:04 | <Hixie> | :-) |
| 00:04 | <doodlewarrior> | theres a distinction |
| 00:04 | <doodlewarrior> | i can go rewrite all my headers to be h1s |
| 00:04 | <Hixie> | it's defined like what you think of as <hgroup> |
| 00:04 | <doodlewarrior> | thats not the problem |
| 00:04 | <Hixie> | ok |
| 00:04 | <Hixie> | what's the problem then |
| 00:04 | <doodlewarrior> | i dont understand why its defined that way |
| 00:04 | <doodlewarrior> | so far as i can tell, numbered headers are just relics of netscape anyway. |
| 00:04 | <doodlewarrior> | it seems that there should be an unordered <header> |
| 00:05 | <doodlewarrior> | to be the counterpart of <footer> |
| 00:05 | <Hixie> | we defined it that way so it would work in IE6 and IE7 |
| 00:05 | <Hixie> | the "unordered <header>" is called <h1> |
| 00:05 | <Niictar> | Nested <sections> create structure like <h1>...<h6> don't they? |
| 00:06 | <Niictar> | <section>* you know what I mean |
| 00:06 | <Niictar> | It seemed like thats what the most recent blog post was about anyway |
| 00:07 | <Hixie> | if you use nested <section>s you can just use <h1> and the level is automatically determined from the nesting depth |
| 00:08 | <doodlewarrior> | Hixie, why can't you have <header> be treated the same as <h1> unless header contains an h1...6? |
| 00:08 | <Hixie> | because it wouldn't work in IE6 and IE7 |
| 00:09 | <doodlewarrior> | im not sure i follow |
| 00:09 | <doodlewarrior> | the new tags dont work in 6 or 7 anyway |
| 00:09 | <Hixie> | if you write <h1>Hello</h1> How are you in IE6 you get big text followed by normal text |
| 00:10 | <Hixie> | if you write <header>Hello</header> How are you in IE6 you get just one line of text and no big text |
| 00:10 | <doodlewarrior> | isnt that the point of CSS? |
| 00:10 | <Hixie> | CSS is optional |
| 00:10 | <doodlewarrior> | so is supporting IE6 :-D |
| 00:10 | <Hixie> | no, it's not |
| 00:11 | <Hixie> | and <headeR> doesn't work anywhere yet either |
| 00:11 | <Hixie> | so it's not just IE6 |
| 00:11 | <doodlewarrior> | but the rest of HTML5 doesnt have meaning in those browsers either |
| 00:12 | <doodlewarrior> | i would prefer to have a cleaner/more consistent markup that is forward-compatible and let authors decide which tags to use |
| 00:12 | <doodlewarrior> | if they need backwards compatibility |
| 00:12 | <Hixie> | well we have put backwards compatibility at a much higher level of importance :-) |
| 00:12 | <doodlewarrior> | rather than building in cruft for the sake of 'backwards compatibility' when most people use CSS anyway |
| 00:12 | <doodlewarrior> | i understand that |
| 00:13 | <doodlewarrior> | and i doubt that my point matters, but i feel the need to make it anyway |
| 00:13 | <doodlewarrior> | you're not breaking anything by allowing <header> to be considered a header in future browsers |
| 00:13 | <doodlewarrior> | if an author needs to support IE6, etc. and isn't using CSS, he can use H1 |
| 00:14 | <Hixie> | what problem would you be solving by introducing another element that means the same as <h1>? |
| 00:14 | <doodlewarrior> | but it bothers me that a tag is being added that's name implies it is something that it is not |
| 00:14 | <doodlewarrior> | two things |
| 00:14 | <Hixie> | imho the name is fine, it's the header, after all :-) |
| 00:15 | <doodlewarrior> | a) it's cleaner than <h1> - the tag says exactly what it is, and it corresponds well to <footer> |
| 00:15 | <Hixie> | "cleaner" is not really an important enough advantage |
| 00:15 | <Hixie> | if you want "cleaner", use xhtml2 or docbook or something like hat :-) |
| 00:15 | <doodlewarrior> | b) its more flexible. if you have a single <header> tag with regular content and need to add children to it, you can |
| 00:16 | <doodlewarrior> | with less reworking |
| 00:16 | <doodlewarrior> | converting <header>a</header> to <header><h1>a</h1><h2>b</h2></header> |
| 00:16 | <doodlewarrior> | is easier than converting <h1>a</h1> to the same |
| 00:17 | <doodlewarrior> | without having to rewrite your styles |
| 00:17 | <doodlewarrior> | well, as many of them anyway |
| 00:17 | <Hixie> | uh |
| 00:18 | <Hixie> | converting <header>a</header> to <header><h1>a</h1><h2>b</h2></header> is exactly as easy as converting <h1>a</h1> to <header><h1>a</h1><h2>b</h2></header> |
| 00:18 | <Hixie> | in fact, easier, if you don't want to rewrite styles |
| 00:18 | <Hixie> | since you wouldn't have to change any in the second case |
| 00:18 | <Hixie> | but in the former, you'd have to change at least your font styles |
| 00:19 | <doodlewarrior> | if header has padding, positioning, etc, i still contend <header> is more flexible |
| 00:19 | <doodlewarrior> | re: cleaner not being important enough of an advantage, i really dont understand the advantage at all of having a new tag be supported in older browsers is |
| 00:20 | <doodlewarrior> | people can juse use <h1> while those browsers are popular |
| 00:20 | <doodlewarrior> | but <header> after they are phased out |
| 00:20 | <doodlewarrior> | if you were doing something that BROKE old browsers, id definitely understand the BC argument |
| 00:21 | <doodlewarrior> | but having a tag be semantically meaningless in an old browser is much different than breaking an old browser |
| 00:21 | <doodlewarrior> | most of HTML5 is semantically meaningless in old browsers |
| 00:21 | <Hixie> | the two problems <header> is solving are: 1, making it possible to have headers that have subheadings without it implying a subsection (like the book title mentioned above) -- this is common on blogs; and 2, making it possible to style such "multilevel" headers in the future. |
| 00:22 | <doodlewarrior> | as Philip` mentioned earlier, if you call it hgroup instead of header, much of my problem with it goes away |
| 00:23 | <doodlewarrior> | im completely cool with having a <header> element that does exactly what you are proposing |
| 00:23 | <doodlewarrior> | so long as it is still valid with or without h1 children |
| 00:24 | <Hixie> | it wouldn't make sense to have a way of grouping headers if it didn't group headers |
| 00:24 | <doodlewarrior> | it would be a nice evolution away from <h1> to have a counterpart to <footer> |
| 00:24 | <doodlewarrior> | <footer> doesnt have any meaning in IE6, but it's still in the spec |
| 00:25 | <doodlewarrior> | same with <video>, <section>, etc |
| 00:25 | <doodlewarrior> | people are using CSS/JS to support older browsers while they are still around |
| 00:25 | <doodlewarrior> | i dont see why <header> is any different |
| 00:26 | <doodlewarrior> | it just bothers me that <section><header>hi</header><footer>bye</footer></header> is more intuitive and more readable than <h1>, but invalid |
| 00:26 | <Hixie> | <video> has fallback; the others don't need to be supported since they don't do anything except allow styling in future browsers |
| 00:26 | <doodlewarrior> | if you are going to have <header>, make it a header, even without header children |
| 00:27 | <doodlewarrior> | if all you want to do is group <h1>s, call it <hgroup> |
| 00:27 | <Hixie> | if we were writing the language from scratch, i'd agree with you |
| 00:27 | <Hixie> | but we're not |
| 00:27 | <Hixie> | we're evolving an existing language |
| 00:27 | <doodlewarrior> | evolving is different than tacking shit on |
| 00:27 | <doodlewarrior> | things deprecate when you evolve |
| 00:28 | <doodlewarrior> | <font> used to have meaning, but now we use CSS for that |
| 00:28 | <doodlewarrior> | <h1> could be the same way |
| 00:28 | <doodlewarrior> | having header be considered a header doesnt break anything |
| 00:28 | <doodlewarrior> | or else id agree with you |
| 00:28 | <doodlewarrior> | but if someone really is supporting ie6 and doesnt use css, h1 is still there as a fallback |
| 00:29 | <Hixie> | changing <h1> would be bad because it works fine as is |
| 00:29 | <doodlewarrior> | h1 doesnt change |
| 00:29 | <doodlewarrior> | im not suggesting that |
| 00:29 | <Hixie> | adding another element that means exactly the same as <h1> would just be adding cruft |
| 00:29 | <doodlewarrior> | im saying apply the h1 rules to an empty header |
| 00:29 | <Hixie> | but that would make pages that don't work in older browsers |
| 00:29 | <Hixie> | even though they should work fine |
| 00:29 | <Hixie> | since they don't do anything new |
| 00:30 | <doodlewarrior> | <h1>s look different in different old UAs anyway. thats why things like YUI-Reset exist |
| 00:30 | <doodlewarrior> | they would still work in older browsers, they would just be unstyled unless you apply a style to them |
| 00:31 | <doodlewarrior> | anyway, i dont mean to waste your time |
| 00:31 | <doodlewarrior> | and i dont have any desire to beat a dead horse |
| 00:31 | <doodlewarrior> | i believe ive made my point |
| 00:31 | <doodlewarrior> | i see no harm in allowing <header> to have the same meaning as <h1> if it doesnt have <h1> children |
| 00:31 | <doodlewarrior> | and its not crufty, because it also serves as a header group |
| 00:32 | <doodlewarrior> | its not just being added for the sake of it (although if youre adding footer anyway, thats a moot point) |
| 00:32 | <doodlewarrior> | if you decide that having <header> be a header even w/o <h1> children is completely unacceptable |
| 00:32 | <Hixie> | if the header is unstyled, it doesn't work... that's what headers do, get styled |
| 00:32 | <doodlewarrior> | please call it hgroup to avoid the confusion of HTML student in the future :) |
| 00:32 | <doodlewarrior> | *students |
| 00:32 | <doodlewarrior> | headers get styled by CSS :-D |
| 00:33 | <Hixie> | css is optional |
| 00:33 | <Hixie> | pages should work without css |
| 00:33 | <doodlewarrior> | it still works, its just unstyled (cause it isn't styled) |
| 00:33 | <doodlewarrior> | if the author cares and doesnt want to use css, h1 is still there |
| 00:33 | <Hixie> | if it's unstyled, it doesn't work |
| 00:33 | <Niictar> | Actually, doesn't the spec say that there is no requirement by UA's to style anything? |
| 00:33 | <Hixie> | the whole point of a header is to style it as a header |
| 00:34 | <Hixie> | Niictar: they have to convey the semantics |
| 00:34 | <doodlewarrior> | im just asking that you dont make it explicitly invalid if its missing an h1 child |
| 00:34 | <doodlewarrior> | and let authors write what they will |
| 00:34 | <Hixie> | Niictar: the spec just doesn't say how it's exactly supposed to look |
| 00:34 | <Niictar> | I see |
| 00:34 | <Hixie> | doodlewarrior: the point is that if the author forgets to use the <h1> child, the header will look broken in old browsers, which is bad |
| 00:36 | <doodlewarrior> | it only looks broken if css isnt there. css is optional, but very very widely used. if the author a) forgets h1, and b) doesn't style, the penalty (unbolded text) is not really that steep |
| 00:39 | <Hixie> | it's not just unboldened text, and the css doesn't matter: IE6 doesn't support CSS styling <header>, and without styles, the text runs into the next paragraph, not even with a line break. |
| 00:40 | <doodlewarrior> | i forgot you have to add HTML5 tags with JS to old IEs |
| 00:41 | <doodlewarrior> | is there such a concept as a warning in validation? |
| 00:41 | <doodlewarrior> | like in compiled code where deprecation stuff is a warning but actual syntax errors are breaks? |
| 00:42 | <doodlewarrior> | so you could warn about the missing <h1> without having it be invalid? |
| 00:42 | <Hixie> | i don't understand the desire to use a longer tag name when you don't have to |
| 00:44 | <doodlewarrior> | h1 just doesnt seem to belong in the lovely world of sections and footers 8-) |
| 00:44 | <Hixie> | html is not a lovely world |
| 00:44 | <Hixie> | deal with it :-) |
| 00:45 | <doodlewarrior> | i love that the current maintainer of what may be the largest used computer language in the world just told me 'html sucks. deal with it' :-p |
| 00:46 | <doodlewarrior> | i do appreciate the work youre doing with html5 |
| 00:46 | <doodlewarrior> | i just have a bit of a pet peeve about design |
| 00:46 | <Hixie> | you get over it if you spend too much time dealing with this stuff |
| 00:46 | <Hixie> | :-) |
| 00:47 | <Niictar> | It's not HTML that sucks, it's browser support. Namely having to continue to support IE 6 forever that makes the wrold of HTML a little dark, imo |
| 00:48 | <doodlewarrior> | Niictar: true, but thats why i think there should be an evolvable path. the lack of <h1> could be frowned upon now, but also built in to standards-compliant browsers |
| 00:48 | <doodlewarrior> | so we can deprecate h1 in the future |
| 00:48 | <doodlewarrior> | and have header/footer match |
| 00:48 | <doodlewarrior> | then bush and fidel will kiss and make up |
| 00:49 | <doodlewarrior> | it will be a lovely world indeed |
| 00:49 | <Hixie> | deprecating things is actually really hard in html |
| 00:49 | <Hixie> | we've done it with things like <font>, but only because those features are really bad |
| 00:50 | <Niictar> | Speaking of pages that look really broken in IE 6, Apple's Safari D: |
| 00:50 | <doodlewarrior> | so Hixie, is your goal to help HTML limp along, then be completely replaced by something better in the future? |
| 00:50 | <Niictar> | But... the whole point is to get people to upgrade to the new version of Safari so IE 6 support really isn't required. But it's a real world example of an HTML 5 page that already looks broken |
| 00:51 | <doodlewarrior> | rather than trying to make it ideal now and cutting through the cruft/bs as best as possible? |
| 00:51 | <doodlewarrior> | and thus giving html some longevity? |
| 00:52 | <Hixie> | doodlewarrior: i don't think html is limping along, it's one of the most successful file formats of all time |
| 00:52 | <Hixie> | doodlewarrior: my goal is to make html better so that it does more |
| 00:53 | <Hixie> | doodlewarrior: but we have finite resources to do it, so i'm focusing on things where we get good value for money |
| 00:53 | <Hixie> | doodlewarrior: i think that its longevity has nothing to do with its element names |
| 00:54 | <doodlewarrior> | it clearly has longevity. its been a reigning format for nearly two decades |
| 00:54 | Niictar | does wonder after following the conversation: |
| 00:54 | <Niictar> | Why isn't <header> renamed <hgroup>? |
| 00:55 | <Hixie> | because <hgroup> is ugly, and <header>, imho, for most people, is more understandable |
| 00:55 | <doodlewarrior> | but if cruft accumulates over time, design decisions go out of fashion, etc., and it isnt cleaned up |
| 00:55 | <doodlewarrior> | it becomes much less attractive as time goes on |
| 00:56 | <doodlewarrior> | the root of entrepreneurism: find a pain, solve a problem |
| 00:56 | <Hixie> | yes, that's why html5 cleans up a huge amount of cruft |
| 00:56 | <Hixie> | but i don't think <h1> is cruft |
| 00:56 | <doodlewarrior> | the more painful/crufty HTML becomes, the more likely it will be that someone upstages it |
| 00:56 | <Hixie> | i hope it is upstaged :-) |
| 00:57 | <Hixie> | it would be sad if we were still using html in 100 years |
| 00:57 | <doodlewarrior> | look at the mac though. it has evolved so much over the past 25 years. |
| 00:57 | <doodlewarrior> | people are still using them |
| 00:58 | <doodlewarrior> | and they have similar qualities |
| 00:58 | <doodlewarrior> | but soo many improvements |
| 00:58 | <doodlewarrior> | anyway, we've all made our points |
| 00:58 | <doodlewarrior> | im glad im not the only one confused that <header> != <footer style='margin-top:0%'> |
| 01:01 | <Niictar> | Is CSS development paired someway with HTML development? Like is there a CSS working group that is putting together default styles for new elements or new semantic meanings to old elements? |
| 01:02 | <Hixie> | there is a csswg, but it's work is not closely coordinated with html development, no |
| 01:04 | Niictar | is worried about using new elements like <nav>, <section>, and <aside>, for example, in real-world commercial sites in fear of random default styles doing something wierd to them |
| 01:06 | <Niictar> | Well rather, that the CSSWG will define new style attributes for an element and then a UA will adopt some of those styles as defaults to reflect semantics |
| 01:08 | <Niictar> | It would be nice to get a glimps of what sort of defaults major browsers will be adopting |
| 01:08 | <Hixie> | html5 defines the expected default styles |
| 01:08 | <Hixie> | in the rendering section |
| 01:11 | <Niictar> | This is not related to the work done by the csswg? |
| 01:14 | <Hixie> | no |
| 01:19 | <Niictar> | Well, anyway, so if I decide to use <nav> and apply whatever styles I like to make it look the way I want in current browsers |
| 01:19 | <Niictar> | I can then go to the spec and lookup expected default style values and either choose to accept them or "reset" them and that should remove suprises later on when a future UA renders the page |
| 01:20 | <Niictar> | As long as those defaults in the spec don't change (remembering it's still a working draft) |
| 05:48 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=480427 (Add a way to run processes in a background thread) is interesting |
| 05:55 | <MikeSmith> | hmm, so http://hg.mozilla.org/mozilla-central/rev/c352ad4174bb and http://hg.mozilla.org/mozilla-central/rev/c352ad4174bb820bbdd71811b4ff3948d12eb768 are the same |
| 05:55 | <MikeSmith> | wonder what the other gazillion characters in the 2nd hg rev number are for |
| 05:56 | <heycam> | what do green underlines mean in the spec? dangling definition reference or something? |
| 06:00 | <MikeSmith> | heycam: I seem to remember that it's supposed to indicate a term that's not defined in HTML5, but instead externally, in another spec. |
| 06:00 | <heycam> | ah |
| 06:00 | <MikeSmith> | but it looks like some instances of those are actually for terms defined in HTML5 |
| 06:01 | <heycam> | yeah |
| 06:01 | <MikeSmith> | so maybe some are markup oversights |
| 06:01 | <heycam> | gsnedders, ↑ |
| 06:01 | heycam | really enjoys pressing Ctrl+Space to switch to the LaTeX IME so he can type \uparrow |
| 06:04 | MikeSmith | uses Japanese IME for that |
| 06:05 | <takkaria> | MikeSmith: hg often uses the first 16 characters of a revision id to refer to that revision |
| 06:06 | <takkaria> | the really long one is the actual revision id |
| 06:06 | <takkaria> | the 16-char shortening is just allowed in places where there's no ambiguity from its use |
| 06:06 | <takkaria> | iirc, anyway |
| 06:06 | <gavin> | MikeSmith: why do you find that bug interesting? |
| 06:07 | <MikeSmith> | gavin: dunno, i guess I just would have thought that'd be implemented already |
| 06:07 | <gavin> | the "processes" it refers to are external processes |
| 06:08 | <gavin> | we've had an API forever that lets you launch them |
| 06:08 | <gavin> | but now we need to allow launching them in the background to better support plugin installations |
| 06:08 | <gavin> | not really related to multi-process web browsing, or running our own tasks on separate threads |
| 06:09 | <gavin> | (the former is being investigated as well, of course, and the latter we've done forever for e.g. DNS lookups) |
| 06:13 | <MikeSmith> | gavin: I see |
| 06:31 | <MikeSmith> | Hixie: Typographic conventions section should mention what class-less <span> (green underline) means |
| 06:43 | <Hixie> | billyjackass, heycam: the green underlines are errors that (once gsnedders does his magic) will go away |
| 06:43 | <Hixie> | (cross-spec references) |
| 06:43 | <Hixie> | is the h:tml doc in dev.w3.org? |
| 06:44 | <billyjackass> | Hixie: no, it's currently in www.w3.org |
| 06:45 | <Hixie> | ah, ok |
| 06:45 | <MikeSmith> | I should move it over to dev.w3.org |
| 06:46 | <MikeSmith> | have a running dispute with others about what dev.w3.org should be properly used for |
| 06:46 | <MikeSmith> | I've been told we should not be publishing documents there at all, because that's not what it was originally intended for |
| 06:46 | <MikeSmith> | fact is of course that's now what it's being use fo |
| 06:47 | <Hixie> | well i'm happy to move the doc to anywhere else people want it |
| 06:47 | <Hixie> | including the /tr/ page |
| 06:48 | <MikeSmith> | heh |
| 06:48 | <Hixie> | i publish about 10 versions a day, let me know if the systeam is ready for that load :-) |
| 06:48 | <MikeSmith> | Hixie: is there some reason in particular you'd think it'd be better to have the h:tml doc on dev.w3.org? |
| 06:48 | <Hixie> | i didn't say i thought that |
| 06:48 | <MikeSmith> | oh |
| 06:48 | <Hixie> | i was just asking if it was there because i couldn't find it there when i looked |
| 06:49 | <Hixie> | i don't really care where it is, so long as it is public |
| 06:49 | <MikeSmith> | well, one main reason I think stuff should be there is that people can view cvs diffs there |
| 06:49 | <MikeSmith> | which they can't for stuff on www.w3.org |
| 06:50 | <MikeSmith> | hsivonen: about http://blog.jclark.com/2009/01/relax-ng-and-xmlid.html |
| 06:51 | <MikeSmith> | (proposal to add xml:id support to jing) |
| 06:51 | <MikeSmith> | is that something that you could add to upstream jing using the filter you already wrote for v.nu? |
| 06:51 | <Hixie> | just out of interest, the people who say we shouldn't publish on dev.w3.org, where do they say we should publish EDs? |
| 06:51 | <MikeSmith> | Hixie: in ACL'ed space on www.w3.org |
| 06:52 | <MikeSmith> | apparently that's the way that some other groups are doing |
| 06:52 | <Hixie> | ah |
| 06:52 | <Hixie> | well i'm happy to do that if you want me to do that |
| 06:52 | <Hixie> | i don't think i have an account on that machine though |
| 06:53 | <MikeSmith> | I'm not happy to do that, because it's unnecessary extra work for everybody, and for me in particular |
| 06:53 | <Hixie> | fair enough |
| 06:53 | <MikeSmith> | the real solution is to put sufficient resources behind dev.w3.org to deal with the use that groups are actually putting it to |
| 06:53 | <MikeSmith> | one particular problem we have run into is bots crawling links from the HTML5 spec in particular |
| 06:54 | <MikeSmith> | which apparently creates massive load |
| 06:54 | <MikeSmith> | because in some cases is causes a cvs process to run for each request |
| 06:54 | <Hixie> | does the systeam know about robots.txt? |
| 06:55 | <Hixie> | long term i think the better solution is to move away from a model that has versioned documents snapshotted on a /TR/ page and just have one continually updated draft per technology |
| 06:55 | <MikeSmith> | yeah, of course. I don't know what the normal solutions have not worked, but they seem not to ahve |
| 06:55 | <Hixie> | (but i don't see the w3c going to that model any time soon) |
| 06:55 | <Hixie> | weird |
| 06:56 | <MikeSmith> | Hixie: I'd personally be happier with continuously-published model for draft specs like HTML5 that are in very active development |
| 06:56 | <MikeSmith> | for groups that are doing everything in public |
| 06:56 | <Hixie> | i wouldn't have groups that aren't in public :-) |
| 06:57 | <MikeSmith> | there's a lot less of than there used to be at least |
| 06:57 | <MikeSmith> | so I guess there's been some progress there |
| 06:59 | <Hixie> | true |
| 07:21 | <hsivonen> | MikeSmith: the filter I wrote does things that are radically not blessed by XML Core |
| 07:22 | <hsivonen> | (assigns IDness to id except in CML) |
| 07:23 | <hsivonen> | MikeSmith: I expect Jing upstream to trea XML Core as normative, but I could be wrong. |
| 07:27 | <hsivonen> | heycam: LaTeX IME on which OS? |
| 07:28 | <MikeSmith> | hsivonen: OK |
| 07:29 | <heycam> | hsivonen, linux |
| 07:29 | <heycam> | using SCIM |
| 07:29 | <heycam> | i really want to be able to type vim digraphs, since i'm more familiar with them than latex commands |
| 07:30 | <hsivonen> | it would be cool if Wolfram released the Mathematica input keystrokes as an input method |
| 07:31 | <hsivonen> | heycam: thanks. I was unaware of SCIM |
| 07:34 | <heycam> | i never managed to get it working nicely in debian, but now that i've installed ubuntu It Just Works :) |
| 07:47 | <Hixie> | i have no idea what to do with appcache and workers |
| 07:48 | <ap> | Hixie: my suggestion is "nothing, it already works great" |
| 07:48 | <Hixie> | it doesn't work at all right now |
| 07:48 | <Hixie> | you can't use workers while offline |
| 07:48 | <ap> | Hixie: oh? in WebKit, or per the spec? |
| 07:48 | <Hixie> | (per spec) |
| 07:48 | <ap> | why? |
| 07:49 | <Hixie> | appcache only takes over network for resources that are done by a browsing context |
| 07:49 | <Hixie> | the fetching of the resource for a worker is done in the worker, not the bc |
| 07:49 | <Hixie> | what does webkit do? |
| 07:50 | <ap> | Hixie: WebKit uses the browsing context that was used for creating the worker |
| 07:50 | <ap> | Hixie: that's necessary at least to ensure that we can follow our cookie policy |
| 07:50 | <ap> | Hixie: (only accept cookies from sites the user navigates to) |
| 07:50 | <Hixie> | so when you call applicationCache.swapCache(), what happens? |
| 07:51 | <Hixie> | the page suddenly finds itself using new resources with an old worker script? |
| 07:51 | <Hixie> | and how does that work for shared workers? |
| 07:52 | <ap> | Hixie: sure, it uses new resources with an old worker (just as it will use an old onmousemove handler that was installed before swapCache). |
| 07:53 | <Hixie> | i guess that makes sense for dedicated workers |
| 07:53 | <ap> | Hixie: shared workers don't exist yet, but obviously, they'll have to remain linked to the document that opened them for cookie policy to work |
| 07:53 | <Hixie> | even once that document is long gone, history cleared, window closed, and everything? |
| 07:54 | <ap> | Hixie: I have no idea how shared workers should be specced |
| 07:55 | <ap> | Hixie: clearly, a shared worker, if there is ever such thing, shouldn't be affected by a random page from the same appcache doing swapCache() |
| 07:55 | <Hixie> | i don't think there's any "clearly" about it, but i do agree |
| 08:25 | <gsnedders> | heycam: cross-document cross-references, methinks |
| 09:01 | <hsivonen> | where can I find information about how vendors other than Mozilla use the Public Suffix List? |
| 09:01 | <annevk3> | http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0306.html o_O |
| 09:02 | annevk3 | thought it was widely known people used VML/SVG to do graphics nowadays |
| 09:03 | <gsnedders> | Yeah! We hate SVG! |
| 09:04 | <annevk3> | Yeah, HTML has enough capabilities of doing declarative 2d graphics already: <table> :) |
| 09:06 | <hsivonen> | Do the HTML5 folks hate SVG more than they hate accessibility? |
| 09:07 | <annevk3> | That's a tough call. Definitely hate it more than internationalization. |
| 09:07 | <annevk3> | Also fun reading: http://lists.w3.org/Archives/Public/public-xhtml2/2009Mar/0101.html |
| 09:08 | <annevk3> | "re-introduce BR, marking as deprecated, and point out that for accessibility, is much better to use L" |
| 09:08 | <hsivonen> | annevk3: I'd love to see a technical explanation for that one |
| 09:11 | <hsivonen> | has anyone tried the Google SVG stuff yet? do they do it in the same DOM as HTML or in an iframed XML DOM? |
| 09:11 | <hsivonen> | if the former, what tricks do they pull to make it work in WebKit? |
| 09:17 | <annevk3> | doesn't WebKit allow it to work in the DOM? |
| 09:18 | <hsivonen> | annevk3: it doesn't render in WebKit for me |
| 09:18 | <hsivonen> | livedom.validator.nu works with SVG only in Firefox and Opera |
| 09:19 | <hsivonen> | no idea why |
| 09:37 | <jgraham> | FWIW I think renaming <header> to <hgroup> or something similar is a very good idea because I have come across a number of people who think that <header> is either like <hn> without the n or like <footer> |
| 09:38 | <jgraham> | Sure it is more ugly but it will also be used right more often |
| 09:38 | <jgraham> | And HTML is already pretty ugly |
| 09:38 | <hsivonen> | jgraham: what about renaming <footer> into <contentinfo>? |
| 09:39 | <hsivonen> | jgraham: my gut reaction is agreeing with renaming to <hgroup> |
| 09:40 | <annevk3> | hgroup sounds like hcard or hcalendar |
| 09:40 | Philip` | wonders why hgroup, not headergroup |
| 09:40 | <hsivonen> | annevk3: true |
| 09:40 | <hsivonen> | Philip`: head*ing*group surely? |
| 09:40 | <jgraham> | hsivonen: I'm less sure about <footer>. The issues there seem more aesthetic |
| 09:40 | jgraham | isn't at all attached to <hgroup> |
| 09:40 | <jgraham> | Just not <heading> |
| 09:41 | <jgraham> | er <header> |
| 09:41 | <jgraham> | (this is another reason to rename it) |
| 09:41 | <hsivonen> | indeed |
| 09:42 | <annevk3> | lets call them <top> and <bottom> |
| 09:42 | <hsivonen> | is it OK if I change html5lib tests according to Hixie's forward-looking IRC statements about foster parenting? |
| 09:42 | <hsivonen> | annevk3: my mother's site has stuff that is semantically <footer> but it's above content |
| 09:43 | <jgraham> | hsivonen: Yes |
| 09:43 | <hsivonen> | jgraham: thanks |
| 09:43 | <annevk3> | I'm not too convinced about some of the structural elements. E.g. I find <article> quite confusing and I'm missing <content> or <main> |
| 09:44 | <annevk3> | I haven't quite figured out how to explain that properly though |
| 09:44 | <hsivonen> | <realbody> |
| 09:45 | <jgraham> | I don't really understand <content> |
| 09:45 | <jgraham> | What would <content> be on a blog? |
| 09:45 | <jgraham> | Or a nes site? |
| 09:45 | <jgraham> | *news |
| 09:46 | <annevk3> | it would be the bit under the primary heading and navigation |
| 09:46 | <jgraham> | In those cases <article> seems pretty obvious |
| 09:46 | <annevk3> | and above the copyright and other links section |
| 09:46 | <annevk3> | <article> is only for a single article |
| 09:46 | <jgraham> | So the content ould be everything not in <nav> <header> or <footer>? |
| 09:47 | <annevk3> | or <aside>, yes, that leaves content :) |
| 09:47 | <jgraham> | <aside> is content |
| 09:47 | <jgraham> | For sure |
| 09:47 | <annevk3> | well, <aside> is both |
| 09:47 | <annevk3> | it can easily be ignored |
| 09:47 | <jgraham> | Oh wait, Hixie has this totally screwy definition of <aside> |
| 09:48 | <annevk3> | content is all the articles on my blog frontpage |
| 09:48 | <jgraham> | There is no way that <aside> should contain sidebars for navigation or anything like that |
| 09:48 | <jgraham> | it just makes no sense |
| 09:48 | <annevk3> | why not? |
| 09:48 | <annevk3> | it's the actual content of the page, you might want to jump to it |
| 09:49 | <annevk3> | you typically want to style it |
| 09:49 | <jgraham> | Because it means that there are two totally different usecases for <aside> |
| 09:49 | <jgraham> | One: for pullout boxes containing content |
| 09:49 | <annevk3> | oh, I thought you were talking about <content> still |
| 09:49 | <jgraham> | Two: For structural elements of the page |
| 09:50 | <jgraham> | Only number One corresponds to any reasonable defenition of <aside> |
| 09:50 | <jgraham> | I guess <content> makes some sense, but I think you could do without it |
| 09:50 | <annevk3> | no, a list of blogs, the wordpress sidebar, etc. those things are <aside> |
| 09:51 | <jgraham> | annevk3: That is defenition Two. The one which makes no sense |
| 09:51 | <annevk3> | it makes sense to me |
| 09:52 | <jgraham> | How is a list of blogs an aside? What is it an aside to? |
| 09:52 | <annevk3> | aside to the main purpose of the page? |
| 09:52 | <annevk3> | it's sidebar thingie, an aside |
| 09:52 | <jgraham> | <sidebar> makes some sense |
| 09:52 | <jgraham> | aside, not as much |
| 09:53 | <jgraham> | And often these things are not asides to the main purpose of the page |
| 09:53 | <annevk3> | <aside> also means "apart", "to the side" |
| 09:53 | <annevk3> | yes they are... |
| 09:54 | <jgraham> | Do you agree that <aside> covers two entirely different concepts? |
| 09:54 | <hsivonen> | jgraham: I'll also update the tests for the new AAA |
| 09:54 | <jgraham> | hsivonen: You rock. Thanks |
| 09:54 | <annevk3> | jgraham, I agree the concepts are slightly different, but not too much |
| 09:55 | <jgraham> | annevk3: I don't really see any overlap between the two use cases. One is a content box that is out of the main flow of the content. The other is site stucture |
| 09:55 | <krijnh> | Isn't <article><aside> usable for case 1, and <body><aside> for case 2? |
| 09:56 | <jgraham> | krijnh: If you want to force all content to be wrapped in <article> elements |
| 09:58 | <krijnh> | I think it'd be handy if there was some place with screenshots of websites and a global outline of new elements you could use |
| 09:58 | <krijnh> | Before we authors just start inventing our own use for some of the new elements, because we are too lazy to read the spec |
| 09:59 | <krijnh> | Something like http://www.alistapart.com/articles/previewofhtml5 but with 'real' sites |
| 10:00 | <annevk3> | sounds cool |
| 10:00 | <annevk3> | can you make the <canvas> app that lets us do that? :) |
| 10:00 | <krijnh> | Me? No :) |
| 10:01 | gsnedders | remembers why he avoids #css |
| 10:02 | <krijnh> | gsnedders: and why's that? :) |
| 10:02 | <gsnedders> | krijnh: They're a bunch of idiots, basically. |
| 10:02 | <krijnh> | gsnedders: well thank you, cause I'm an idiot too. And we idiots are going to use the new stuff you come up with in here |
| 10:03 | <gsnedders> | krijnh: I don't like being told, "the wey i see it , you should just shut up and start learning something" |
| 10:04 | <krijnh> | Right, you lost me |
| 10:04 | <annevk3> | gsnedders, btw, there's huge amount of Scottish people in the Netherland. They were all hopping around in their kilts in Amsterdam last night. Apparently there's a football match coming up between our countries. |
| 10:05 | <gsnedders> | I guess I'm meant to say "We'll kick your ass", but I really don't care for football. |
| 10:05 | Philip` | assumes gsnedders isn't talking about W3C #css |
| 10:05 | <gsnedders> | Philip`: No, freenode #css |
| 10:05 | <Philip`> | krijnh: By the way, http://krijnhoetmer.nl/irc-logs/css/20090327 says "-#c-ss" at the top which seems odd :-) |
| 10:05 | <krijnh> | Kewl :) |
| 10:07 | <krijnh> | That's part of me trying to prove my idiotness |
| 10:07 | <krijnh> | Working quite well |
| 10:07 | <gsnedders> | krijnh: You rule. |
| 10:07 | <Philip`> | I think the existence of the irc-logs service is proof of nonidiotness :-) |
| 10:08 | <krijnh> | Philip`: that's just because you haven't seen the code :) |
| 10:08 | <krijnh> | Anyway |
| 10:08 | <krijnh> | Are these 'markup tutorials' thingies requested before? |
| 10:08 | <krijnh> | Is that the cookbook DanC is working on |
| 10:13 | <gsnedders> | http://pastebin.ca/1373856 |
| 10:16 | <krijnh> | gsnedders: that's a nice pill to swallow for a lot of developers, which takes some time |
| 10:17 | annevk3 | wonders why he read that |
| 10:17 | <annevk3> | stuff like that drives me away from everyday forums, which is bad, since it's good to know what people want |
| 10:18 | <hsivonen> | hmm. it seems my frameset-ok code may suck |
| 10:21 | <gsnedders> | It's the elitism of, "I'm right, you're wrong. You go learn.", when in fact they are wrong that really pisses me off. |
| 10:21 | <jgraham> | gsnedders: Calm dowwn, calm down |
| 10:21 | gsnedders | slaps jgraham |
| 10:21 | <jgraham> | (that is best read in a liverpudlan accent) |
| 10:21 | <gsnedders> | :P |
| 10:21 | <jgraham> | s//i/ |
| 10:22 | <krijnh> | gsnedders: osm |
| 10:22 | <krijnh> | Whoops |
| 10:25 | annevk3 | pondered whether he should go in to say that gsnedders is right (and if they didn't buy it I'd just point to some CSS spec that carries my name :p ) |
| 10:26 | <krijnh> | annevk3: don't waste your time |
| 10:26 | <gsnedders> | annevk3: :P |
| 10:27 | <krijnh> | annevk3: gsnedders can waste his time by calling them idiots (elitism?), but you should know better ;) |
| 10:28 | <annevk3> | krijnh, I'm just amusing myself with the thought |
| 10:29 | <krijnh> | More people should just be satisfied with the thoughts alone :) |
| 10:30 | <gsnedders> | I'm now getting told about what is and isn't valid HTML 5 by someone who says they aren't that familiar with HTML 5. |
| 10:31 | <annevk3> | wot |
| 10:31 | <jgraham> | I'm not sure what that is surprising |
| 10:31 | <jgraham> | *why |
| 10:35 | <hsivonen> | have browsers started accepting unitless lengths in the standards mode? due to SVG? |
| 10:36 | <annevk3> | I don't think so |
| 10:36 | <krijnh> | No |
| 10:36 | <annevk3> | Opera used quirks mode parsing for SVG for a short while |
| 10:36 | <hsivonen> | so is the #css stuff only about quirks mode? |
| 10:36 | <annevk3> | I managed to get that fixed... |
| 10:36 | <annevk3> | hsivonen, yup |
| 10:37 | <hsivonen> | ok |
| 10:38 | <hsivonen> | whoa! the new AAA makes so much more sense than the old one for <!DOCTYPE html><p><b><i><u></p> <p>X |
| 10:40 | <hsivonen> | Hixie: seems like the old one was rather silly here |
| 10:40 | hsivonen | goes test what WebKit does |
| 10:40 | <hsivonen> | WebKit indeed does it the old way |
| 10:41 | <hsivonen> | new AAA FTW! |
| 11:27 | <beowulf> | FWIW i find article confusing when compared with section when marking up content, and header being named something like hgroup would clear up a question i'm going to ask on the help list |
| 11:40 | <olliej_> | hsivonen: AAA? |
| 11:41 | <jgraham> | Adoption Agency Algorithm |
| 11:41 | <olliej_> | ? |
| 11:41 | <jgraham> | olliej_: You're supposed to know this stuff, Hyatt invented it |
| 11:41 | <jgraham> | :) |
| 11:41 | <olliej_> | jgraham: hyatt is a crazy man :D |
| 11:41 | <jgraham> | olliej_: <b><i>foo</b>bar</i> |
| 11:42 | <olliej_> | yeah |
| 11:42 | <olliej_> | i had a vague recollection of the name and purpose of said algorithm |
| 11:42 | <olliej_> | once you said it |
| 11:42 | <hsivonen> | http://www.whatwg.org/specs/web-apps/current-work/#adoptionAgency |
| 11:44 | olliej_ | prods hyatt |
| 11:44 | olliej_ | realises it's 5am and goes to bed |
| 12:22 | <zcorpan> | hoffman helped find a bug in opera by sending broken svg to the list |
| 12:26 | jgraham | likes the idea of a riot in the bikeshed |
| 12:39 | <Lachy> | the name for <header> came from the common class and IDs used by people for a similar purpose. (typically <div id="header"><h1>...</h1> ... </div>) |
| 12:40 | <svl> | The problem with the hgroup name is that it suggests being rather restrictive, while a header can contain far more than _just_ h1-h6 |
| 12:40 | <Lachy> | I don't see how we can justify calling it confusing given that we've seen several other people use it as intended |
| 12:41 | <Philip`> | Lachy: It's not clear that people using id="header"/class="header" were using it with the same meaning as how <header> is specced |
| 12:42 | <jgraham> | Lachy: I think we can call it confusing on the basis of people being confused by it |
| 12:44 | <Lachy> | jgraham, two people commenting on IRC is insignificant given that we can look at sites and see people actually using it correctly. http://html5gallery.com/ |
| 12:44 | <krijnh> | Is somebody actively checking if it is used correctly already? |
| 12:45 | <krijnh> | And if not, pointing it out? |
| 12:45 | <Lachy> | I just went through all the sites listed there and of all the ones using <header>, they all used it as intended |
| 12:46 | <Philip`> | I looked at http://www.codedread.com/ which is the first one, and it seems to be entirely redundant in there since it's just wrapping a single <h3> |
| 12:46 | <Philip`> | http://www.thewatchmakerproject.com/ uses <div id="header"> for something that contains Twitter status, which would seem inappropriate for conversion to <header> |
| 12:46 | <krijnh> | On http://blog.codedread.com/ it's used better |
| 12:46 | <Lachy> | although I did notice one using a supurfluous section as in: <article><header>[Article header]</header><section>[Article content]</section></article> |
| 12:47 | <Lachy> | *superfluous |
| 12:48 | <krijnh> | The comment lists on blog.codedread.com don't use <article> elements |
| 12:48 | <Philip`> | Comments aren't articles, and if people are writing articles in your comments section then you should tell them to get their own blog instead :-p |
| 12:49 | <krijnh> | "The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content." |
| 12:49 | <krijnh> | No? |
| 12:49 | <Philip`> | That's merely what HTML 5 says |
| 12:50 | <krijnh> | :) |
| 12:50 | <krijnh> | Isn't that what people are trying to follow then? |
| 12:50 | <krijnh> | Or should follow, when they say they're using fluffy new markup |
| 12:51 | <Philip`> | When an element has an English word for a name, people reasonably assume that word's semantics are the element's semantics |
| 12:51 | <Philip`> | hence e.g. using <address> for addresses |
| 12:52 | <Philip`> | Telling people to use <article> for something that's clearly not an article is just confusing |
| 12:52 | <Philip`> | (Telling them to use <div> is okay because they won't have preconceptions as to what 'div' means) |
| 12:52 | <krijnh> | Heh, HTML 5 is a mess! :) |
| 12:52 | <Philip`> | s/5// |
| 12:53 | <Philip`> | s/HTML/the world/ |
| 12:53 | krijnh | tries to make Last Week |
| 12:53 | <Philip`> | s/:)/:(/ |
| 13:04 | <Lachy> | krijnh, haven't you been targetted by Mr Last Week before? |
| 13:04 | <krijnh> | No idea |
| 13:04 | <krijnh> | He only links to my site constantly :( |
| 13:04 | <Lachy> | oh, so you just want to be on there again? |
| 13:05 | <krijnh> | Yeah, but don't tell anyone |
| 13:05 | <krijnh> | I'd like to know your secret :) |
| 13:05 | <Lachy> | I don't have any secrets |
| 13:06 | <krijnh> | Your as in the entire cabal :) |
| 13:06 | <annevk3> | Do you seriously think we'd use this channel as coverup for our world domination plan we're discussing over in #secrettreehouse? |
| 13:07 | <krijnh> | Yeah, I'm banned there, because I wanted to log that channel as well :( |
| 13:07 | <krijnh> | Some Hixie guy did that |
| 13:07 | <annevk3> | Ah, I forgot about that |
| 13:09 | <beowulf> | there's a secret tree house? <excited>I'll get my ball!</excited> |
| 13:11 | <jgraham> | Weeeee another I think XML is trivial post |
| 13:13 | <annevk3> | Robin Berjon has actual knowledge though |
| 13:14 | <jgraham> | Right, so do lots of the othr people who think that XML is trivial |
| 13:14 | <jgraham> | Doesn't mean that XML is trivial |
| 13:15 | <annevk3> | I guess the question is, trivial to whom? |
| 13:15 | <jgraham> | Lachy: About half the sites on the front page of HTML5 agllery use <header> in a redundant way (just to wrap a single <hn> element) |
| 13:15 | <jgraham> | And these represent the early adopters from whom we expect the very best markup |
| 13:17 | <Lachy> | sure, it may be technically redundant, but it's not wrong. In particular, none have attempted to use it as a substitue for <h1> elements |
| 13:17 | <jgraham> | Lachy: I wouldn't expect early adopters to |
| 13:18 | zcorpan | realizes he has used <header><h1>Foo</h1></header> and goes to remove the reducancy |
| 13:18 | <jgraham> | The sample is way too biased to infer much |
| 13:19 | <jgraham> | In particular I would expect all of these authors to validate their work |
| 13:19 | <Lachy> | well, the two questions about the issue on IRC that you referred to is even less evidence to infer anything from. |
| 13:20 | <jgraham> | Lachy: I don't see how. That represent actual confusion |
| 13:21 | <beowulf> | http://havetheygoneawayyet.com/ # i was going for maximum reducancy |
| 13:21 | <zcorpan> | gsnedders: it would be useful if your outline tool said which sectioning element, if any, a heading is associated with |
| 13:21 | <Lachy> | there are always going to be a few people confused about any little thing, regardless of how trivial it may be. The issue is whether or not there's significant widespread confusion to justify changing anything, rather than simply improving the education of the issue |
| 13:22 | <Philip`> | The cost of changing the name is pretty low |
| 13:23 | <jgraham> | Right but we have both evidence of actual confusion amonst authors cluded up enough to find the right technical irc channel to ask on, and a hypothesis about why they would be confused (the element name is misleading) |
| 13:23 | <beowulf> | in my experience of marking up docs as html5 header isn't terribly confusing, but i thought i'd mention it |
| 13:23 | <Lachy> | Philip`, given the existing material out there already explaining how to use it, and the sites that have already adopted it, I think the cost of changing it is higher than you think |
| 13:23 | krijnh | prefers <header> and better/more examples |
| 13:23 | <zcorpan> | xhtml2 has <headings> |
| 13:23 | <zcorpan> | maybe that's a clearer name |
| 13:23 | <beowulf> | section vrs article though is in a different league |
| 13:23 | Lachy | walks away from this useless bikeshed |
| 13:24 | <jgraham> | Lots of people seem to do <article><h1>Foo</h1><section>This is the content</section></article> |
| 13:24 | <jgraham> | Which is bad |
| 13:24 | <zcorpan> | yes |
| 13:24 | <krijnh> | Why exactly? |
| 13:25 | <jgraham> | krijnh: Because it technically means that the content is a untitled subsection of the article |
| 13:25 | <zcorpan> | maybe we should drop <section> |
| 13:25 | <jgraham> | rather than being titled by the article title |
| 13:25 | <jgraham> | zcorpan: Maybe we should drop <article> |
| 13:25 | <zcorpan> | jgraham: article seems more useful than section and is used correctly :) |
| 13:26 | <Lachy> | people do that because they think in terms of header/content/footer, and think each part of it deserves its own individual container |
| 13:26 | <jgraham> | zcorpan: <section> is nice for long documents like theses and the like |
| 13:27 | <Lachy> | just like we have thead/tbody/tfoot, or people who do <div id="header"/><div id="maincontent"/><div id="footer"/> |
| 13:27 | <jgraham> | Maybe we should change the outline algorithm to make untitled sections collapse |
| 13:27 | <Lachy> | jgraham, that's what I was just thinking |
| 13:27 | <beowulf> | i'd say they get confused because in the normal stage of marking up documents they haven't had to think about the semantics of two types of section before |
| 13:27 | <beowulf> | s/they/me |
| 13:29 | <krijnh> | Nor about where you put your headings |
| 13:30 | <jgraham> | Maybe we should make it a fatal parse error if Hixie doesn't approve of your markup. |
| 13:30 | <krijnh> | Inside or outside a <div> |
| 13:31 | <beowulf> | html5-O, Hixie Police |
| 13:48 | <zcorpan> | so who's gonna suggest the name <headings> on the list? |
| 13:48 | <jgraham> | zcorpan: You :) |
| 13:48 | <zcorpan> | no, i don't participate in naming debates on list |
| 13:49 | <jgraham> | Just on IRC? |
| 13:49 | <zcorpan> | yes :) |
| 13:49 | <krijnh> | <header><h1>Foo</h1><p>Bar</header> is correct too, right? |
| 13:49 | <zcorpan> | yeah |
| 13:50 | <krijnh> | Then <headings> would be weird, imho |
| 13:50 | <zcorpan> | maybe |
| 13:51 | <zcorpan> | but less potential for misuse |
| 13:57 | <Andrii> | can <section> be used like a container for <article>s? |
| 13:57 | <Andrii> | instead of <div id="content"> if it would be done in past HTML |
| 13:57 | <jgraham> | Andrii: Yes |
| 13:58 | <jgraham> | If you want |
| 13:58 | <Andrii> | great, I want it now :D |
| 14:00 | <Andrii> | I'm going to markup my site in XHTML5 and I don't care that IE doesn't support application/xhtml+xml, it's not my problem, I'm following standards, Safari, Firefox, Opera can, why IE is so **** |
| 14:00 | <Andrii> | it will be a lesson for IE! |
| 14:02 | <jgraham> | Andrii: Unless you are, say, Google, it seems unlikely that IE will learn its lesson |
| 14:04 | <Andrii> | of course, I was kidding, but someone has to start using XHTML content-type on the web, right? |
| 14:04 | <krijnh> | Why? |
| 14:04 | <Andrii> | to push web standards to the new level |
| 14:05 | <hsivonen> | Andrii: good luck with pushing standards to the next level that way |
| 14:05 | <svl> | Andrii: application/xhtml+xml and web standards are pretty much orthogonal |
| 14:05 | <Andrii> | yeah, you always can say that web worked perfectly well with HTML 4.01 |
| 14:05 | <krijnh> | jgraham: what if subtitles aren't mandatory for a content manager and your template has something like <header><h1>{title}</h1>{if subtitle}<p>{subtitle}</p>}</header> ? |
| 14:05 | <jgraham> | Andrii: The web wworked perfectly well with HTML 4.01 |
| 14:06 | <jgraham> | krijnh: Well it's not wrong |
| 14:06 | <hsivonen> | jgraham: well, pretending that it was HTML 4.01 that was implemented |
| 14:06 | <svl> | You can follow the standards very well using HTML; there's no need for the draconian error handling which X(HT)ML gives you. |
| 14:06 | <jgraham> | hsivonen: Good point |
| 14:07 | <jgraham> | Andrii: What does XHTML5 buy you over HTML5? |
| 14:07 | <Andrii> | I will know that I closed each tag :) |
| 14:08 | <Andrii> | a peace in my soul |
| 14:08 | <jgraham> | Andrii: You could ensure that with HTML 5 pretty easilly |
| 14:08 | <hsivonen> | that's why I should implement optional implied tag warnings |
| 14:08 | <hsivonen> | people seem to care more about that than about true polyglotness |
| 14:09 | <zcorpan> | hsivonen: good point. but it gives people the false feeling that they have polyglotness |
| 14:10 | <Andrii> | yes, you all are right, but for me HTML is the past, it's very subjective, but when XHTML was introduced it seemed like a natural development. |
| 14:10 | <zcorpan> | jgraham: maybe you should edit the blog post, linking to http://gsnedders.html5.org/outliner/ |
| 14:10 | <jgraham> | zcorpan: Yeah, maybe |
| 14:11 | <jgraham> | Andrii: So it is quite irrational? |
| 14:11 | <Andrii> | what is quite irrational? using XHTML 5? yes |
| 14:12 | <Philip`> | jgraham: Are you missing a </heading> in your latest post? (and it should be 'header' anyway) |
| 14:12 | <Philip`> | jgraham: Oh |
| 14:12 | <Philip`> | jgraham: I meant your latest-but-one post |
| 14:12 | <Philip`> | jgraham: since I didn't scroll down to the one where you corrected yourself |
| 14:13 | <jgraham> | Philip`: Yeah, I suck apparently |
| 14:13 | krijnh | expects some follow-ups about "haha, with XML that wouldn't happen!" |
| 14:14 | <jgraham> | krijnh: You mean if I were posting XML to a mailing list it would refuse to send my email until I got my example right? That's cool |
| 14:14 | <jgraham> | Or would people reading my email just see a YSOD in their email client |
| 14:15 | <Philip`> | Hopefully it would save the ill-formed XML into their giant XML-based mail database file, and they won't be able to read any of their emails ever again until they fix it in a text editor |
| 14:18 | <zcorpan> | Philip`: what if the text editor is xml-based? |
| 14:20 | <krijnh> | jgraham: yeah, XML could do that for you. But you still want to use your crappy HTML syntax, oh well :) |
| 14:22 | <Philip`> | zcorpan: Copy the file onto a CD then take it down to the dodgy-looking guy in the alleyway who'll load it onto one of the old illegal pre-XML Ubiquity Act computers that has a copy of Notepad and can fix it up for you as long as you keep quiet about him |
| 14:23 | <Philip`> | zcorpan: ^ |
| 14:23 | <Philip`> | Human ingenuity will allow our species to survive despite XML |
| 14:26 | <zcorpan> | Philip`: only if the cd burner doesn't try to inspect the file looking for virii or something and is also xml-based |
| 14:36 | <hsivonen> | I don't like doing release engineering |
| 14:36 | <hsivonen> | but I felt I should push out a release of the parser |
| 14:36 | <hsivonen> | respinning it now... after having signed files and all |
| 16:14 | <gsnedders> | html5lib PHP: r1274 48.2s v. r1290 10.5s to tokenize spec. |
| 16:19 | jgraham | curses people who make testcases using red as a pass condition |
| 16:22 | <krijnh> | Thank you :) |
| 16:23 | <annevk3> | gsnedders, is there more than a tokenizer? |
| 16:24 | <annevk3> | gsnedders, and is it fully implemented in PHP? |
| 16:24 | <jgraham> | annevk3: (the answers are no and yes respectively) |
| 16:24 | <gsnedders> | annevk3: There isn't really more than a tokenizer, and it doesn't support foreign content |
| 16:24 | <jgraham> | (I think) |
| 16:24 | <gsnedders> | And it doesn't output parse errors either |
| 16:25 | <annevk3> | gsnedders, I don't care much about all that, I just need a tree, ways to filter the tree, and serialize |
| 16:25 | <gsnedders> | But there's no change in functionality between the two revisions, just a large change in speed :P |
| 16:25 | <gsnedders> | Anyhow, I need to head off, get changed, go to ATM, go to Edinburgh, etc. |
| 16:26 | <annevk3> | gsnedders, is this a public project? I might be interested in helping out a bit with missing functionality at some point |
| 16:26 | <gsnedders> | annevk3: It's in html5lib SVN |
| 16:26 | <annevk3> | okidoki |
| 16:27 | <jgraham> | gsnedders: Before you go, any opnion on movingto hg/bitbucket |
| 16:27 | <gsnedders> | jgraham: +1 |
| 16:27 | <jgraham> | gsnedders: Interesting |
| 16:28 | <gsnedders> | BBC weather has totally redesigned. I'm really don't like it. |
| 16:28 | <jgraham> | OK, you may go to Edinburgh now. But only if you promise to be good |
| 16:28 | <gsnedders> | Yes sir. |
| 16:28 | <gsnedders> | :P |
| 16:29 | <jgraham> | It's stopped snowing |
| 16:52 | <gsnedders> | It's meant to have "Light Rain Shower" at 18:00 |
| 16:52 | <gsnedders> | I just dunno whether to take a coat or not |
| 16:55 | <beowulf> | better looking at it than looking for it |
| 16:59 | <annevk3> | "Revamp HTML5 doctype sniffing?" scares me a bit |
| 17:00 | <Andrii> | jgraham: if XHTML 5 doesn't buy my anything over HTML 5 why then it exists? |
| 17:00 | <annevk3> | though reducing magic strings is certainly tempting |
| 17:00 | <Andrii> | jgraham: me* |
| 17:00 | <jgraham> | Andrii: Well I guess some people like XML |
| 17:01 | <annevk3> | Andrii, mostly because browsers had already implemented XHTML |
| 17:01 | <jgraham> | If you need namespaces or something it is pretty useful |
| 17:01 | <jgraham> | But in the 99.99% case you don't need those things |
| 17:03 | <Andrii> | jgraham: it's hard to argue with that |
| 17:04 | <Philip`> | If you are working in a programming environment that has fast XML parsers but only rubbish slow HTML5 parsers, it can be much more efficient to use XHTML5 internally |
| 17:04 | <Andrii> | I had a dream that some day all web sites would be xhtml valid |
| 17:05 | <Philip`> | Sounds like a nightmare to me |
| 17:05 | <Andrii> | but it seems like it will never come true, because there is no even such a goal |
| 17:05 | <jgraham> | Andrii: The only time I use something like XHTML5 iswhen I use Genshi which is a templating language that is particularly well suited for working with angle-bracket markup and puts the template directives in a genshi namespace. But then I serialize to html in the end because the output only has content from asingle namespace |
| 17:06 | <annevk3> | Andrii, I think some have such a goal, e.g. timbl |
| 17:07 | <Andrii> | annevk3: oh, at least someone! |
| 17:07 | <Philip`> | Now you've just got to convince a billion other people and get them to all write XHTML with no errors |
| 17:07 | <jgraham> | Andrii: That seems like an anti-goal to me because the things that you would have to do to achieve it all seem bad |
| 17:08 | <jgraham> | In particular education alone would never be enough |
| 17:08 | <Andrii> | jgraham: but everyone wins from that, why education alone would never be enough? |
| 17:09 | <jgraham> | Andrii: Who wins? What do they win? |
| 17:09 | <Andrii> | jgraham: better semantics, code without errors |
| 17:10 | <jgraham> | Better semantics isn't true unless you use the even more unachieveable definition of "totally consistent use of elements" |
| 17:10 | <Andrii> | jgraham: it's a step towards semantic web |
| 17:11 | <annevk3> | Andrii, you might find you and timbl have a lot in common :) |
| 17:11 | <jgraham> | "code without errors" seems like a restatement of the goal, not a reason |
| 17:11 | <jgraham> | Andrii: How? |
| 17:12 | <annevk3> | "code without errors" is also not neccessarily true, e.g. <a href="ht tp://example.org/"/>; is a well-formed document, but also invalid and useless |
| 17:12 | <jgraham> | The out-of-reach target of well-formed pages says nothing about semantics |
| 17:13 | <Andrii> | jgraham: yes, but what about blind users? |
| 17:13 | <jgraham> | The even-more-out-of-reach target of conforing-to-machine-checkable-conformance-requirements still says almost nothing about semantics |
| 17:13 | <Andrii> | annevk3: true |
| 17:13 | <jgraham> | The consistent use of elements across multiple websites does have some advantages |
| 17:14 | <jgraham> | e.g. it makes Google's lives easier |
| 17:15 | <jgraham> | Andrii: Sure. For blind users you should do stuff like make sure that your tables all have the headers marked up correctly, that your site makes sense without images, that your headers use the right elements and so on |
| 17:15 | <jgraham> | It doesn't matter so much if your markup is illformed |
| 17:15 | <jgraham> | But no validator will tell you if you got that right |
| 17:15 | <Andrii> | jgraham: with the fact that in HTML 5 you may not close elements the web will still be a MESS |
| 17:16 | <Andrii> | jgraham: but screenreader can tell me how usable a page is |
| 17:16 | <jgraham> | Andrii: Why do you care if other people's sites are a mess? Shouldn't it be up to the original author to care if their code is maintainable enough? |
| 17:17 | <jgraham> | (I actually have some reason to care because browser QA is easier when the original source doesn't suck. But that seems like a pretty weak argument) |
| 17:17 | <Andrii> | jgraham: because all this things are connected, ugly web sites have poor markup and vice versa |
| 17:18 | <jgraham> | You are trying to claim that websites with bad markup are generally aesthetically displeasing? |
| 17:18 | <jgraham> | That is certianly a new argument to me |
| 17:18 | <Andrii> | jgraham: that's probably I started learning web stuff from A List Apart |
| 17:19 | <beowulf> | trying to make websites aesthetically pleasing is one contributor to what you would call messy code |
| 17:20 | <Andrii> | beowulf: CSS Zen Garden? |
| 17:20 | <jgraham> | Certianly people who make aesthetically pleasing websites often add lots of extra markup that is not needed to represent the site content but is only there as a styling hook |
| 17:20 | <jgraham> | (the Zen Garden is a classic example of this) |
| 17:20 | <beowulf> | yu |
| 17:20 | <beowulf> | yup |
| 17:23 | <Andrii> | jgraham: yes, there is some extra markup in CSS Garden's template, but loots of it is not used. People like Dave Shea, Jason Santa Maria, Andy Budd, Andy Clarke, Ethan Marcotte, Doug Bowman, all these guys showed that well marked up sites can be visually pleasing. |
| 17:24 | <Andrii> | using CSS, it's obvious |
| 17:25 | <jgraham> | Andrii: I don't doubt that these people are good designers. |
| 17:25 | <Andrii> | Andy Clarke in his latest book "Transcending CSS" says - start with mark up and when it is finished start with the design. |
| 17:25 | <jgraham> | Certianly well marked up (for some defention of "well marked up") sites can be visually appealing |
| 17:26 | <jgraham> | Andrii: That sounds like good advice for sure |
| 17:26 | <jgraham> | But it is to benefit _you_ |
| 17:26 | <jgraham> | It is not preaching to others |
| 17:26 | <jgraham> | Or trying to fix other people's mess for the sake of it |
| 17:28 | <jgraham> | If the advantages of clean markup (by clean here I mean not relying on error handling), people will naturally gravitate toward doing that out of self-interest |
| 17:30 | <Andrii> | jgraham: yes, but the point was that these things are connected - markup and presentation, and good markup indeed increases the possibility of the presentation to be better, cleaner, well designed. |
| 17:32 | <beowulf> | certainly someone who cares enough to write well formed markup will probably be the sort of person that cares about their work in general, but the markup doesn't have an effect on the aesthetics in my experience |
| 17:33 | <Andrii> | beowulf: that's what I was trying to say, "someone who cares enough to write well formed markup will probably be the sort of person that cares about their work in general" |
| 17:34 | <krijnh> | The one writing the markup isn't necessarily the one making the design/aesthetics |
| 17:35 | <beowulf> | we're all doomed |
| 17:35 | <Andrii> | krijnh: yes, but dont' you agree that this should be the same person? |
| 17:35 | <krijnh> | Andrii: no, I don't |
| 17:36 | <krijnh> | Andrii: I'm not a designer, but I try to write 'pretty' markup |
| 17:36 | <Andrii> | krijnh: then beowulf is absolutely right, we're all doomed |
| 17:36 | <krijnh> | If it should be the same person, I wouldn't have any work at all :) |
| 17:36 | <beowulf> | i got something right :) |
| 17:36 | <Andrii> | krijnh: you can develop your designing skills |
| 17:37 | <krijnh> | Andrii: no, I don't, and I don't want to either |
| 17:37 | beowulf | hands krijnh some crayons |
| 17:37 | <Andrii> | krijnh: timbl and me hate you |
| 17:38 | <Andrii> | krijnh: just kidding :) |
| 17:38 | <krijnh> | :) |
| 17:38 | <krijnh> | I kind of like getting all sorts of visual designs and trying to squeeze semantice markup out of them |
| 17:38 | <krijnh> | *semantic |
| 17:39 | <beowulf> | me too |
| 17:39 | <Philip`> | My visual design skills are usually limited to changing the font to sans-serif and maybe changing some margins |
| 17:39 | <krijnh> | Too bad if timbl hates me for that |
| 17:39 | <beowulf> | make a t-shirt |
| 17:39 | <Andrii> | krijnh: it was a joke, it's great to hear that we all here agree that semantic markup is the aim |
| 17:39 | <krijnh> | (Though I think he really doesn't care about what I do :) |
| 17:40 | <Philip`> | I don't agree semantic markup is the aim |
| 17:40 | <Andrii> | damn |
| 17:40 | <Andrii> | Philip`: what about blind users? |
| 17:41 | <Andrii> | okay, I should differentiate between well formed markup and semantic markup |
| 17:41 | <Philip`> | I'd write everything in text/plain if I didn't want links and tables and nice fonts :-) |
| 17:41 | <beowulf> | Philip`: figlet has some nice fonts... |
| 17:41 | <Philip`> | and that has no semantic markup at all |
| 17:41 | <Philip`> | beowulf: I think they're all pretty ugly actually :-( |
| 17:42 | <beowulf> | there's no pleasing some people |
| 17:42 | <Andrii> | Philip`: but if you would write everything in text/plain without some meaningful structure blind users would suffer a lot |
| 17:43 | <krijnh> | I think people used to links and images would suffer a lot more :) |
| 17:43 | <Andrii> | Philip`: and search engines, WE WOULDN'T HAVE SUCH A GOOD SEARCH |
| 17:43 | <Philip`> | Andrii: Why? They would have access to exactly the same information as people using graphical browsers |
| 17:44 | <Andrii> | Philip`: because screenreaders parse your markup and if it's not well-formed they have troubles interpreting it |
| 17:44 | Philip` | thinks someone should make a whole web site that's designed like an .NFO file |
| 17:44 | <Philip`> | Andrii: Screenreaders usually hook into Internet Explorer and just see the parsed version of the document, not the markup |
| 17:44 | <beowulf> | Philip`: i used to make my css look quite like an .NFO file... |
| 17:46 | <krijnh> | Philip`: http://www.photo2text.com/ :) |
| 17:46 | <beowulf> | there's a processing example that does the same thing with your webcam stream |
| 17:48 | <Andrii> | http://vimeo.com/1157346 - video of a blind web developer using a screenreader software |
| 17:49 | <Andrii> | Philip`: it would be better if they hooked into Firefox or Safari |
| 17:52 | <Andrii> | do you hear, screenreader says "list of items", the guy who is writing a markup like "first item <br/> second item <br/> third item <br/>" would make the life of a blind user terrible |
| 17:52 | <Andrii> | thus, well formed semantic markup is an aim |
| 17:53 | <Andrii> | and serving pages as XHTML is indirectly a step towards this aim |
| 17:54 | <annevk3> | your confusing syntax and semantic markup |
| 17:54 | <annevk3> | you can write semantic markup using HTML as well |
| 17:54 | <annevk3> | s/your/you're/ |
| 17:55 | <Andrii> | annevk3: but in HTML nothing tells you that you're doing something wrong |
| 17:55 | <svl> | Andrii: in XHTML nothing does either. At least not where _semantics_ are concerned. |
| 17:56 | <Andrii> | annevk3: in XHTML at least validator tells you that you haven't closed some tag |
| 17:56 | <annevk3> | Andrii, that has zero to do with semantics |
| 17:56 | <svl> | Andrii: closing tags is _syntax_, not semantics |
| 17:56 | <krijnh> | Andrii: what does the validator tell you when you use "first item <br/> second item <br/> third item <br/>" ? |
| 17:56 | <Andrii> | yes, yes, yes, I was meaning well formed markup, not semantics |
| 17:56 | <annevk3> | Andrii, well-formed markup doesn't give you anything |
| 17:56 | <Andrii> | krijnh: that it's valid, but it warns me about not-closed tags |
| 17:57 | <svl> | Andrii: which tags in that are not closed? |
| 17:57 | <Andrii> | annevk3: decreasing of a page size |
| 17:57 | <Andrii> | svl: in that none, in a list - <li> |
| 17:58 | <annevk3> | Andrii, what?! HTML syntax allows me to omit all kinds of things that I cannot do in XHTML. Anyway, page size is solved with gzip |
| 17:58 | <Andrii> | annevk3: OKAY, YOU WON |
| 17:58 | smedero | is thankful for krijnh's logging bot |
| 17:58 | <annevk3> | agreed |
| 17:58 | <annevk3> | I'm going back to watching The West Wing |
| 17:58 | <krijnh> | smedero: ow, okay :) |
| 17:59 | <Philip`> | annevk3: If you were using XHTML then you could use EXI and get improved page sizes |
| 17:59 | <krijnh> | There is no logging bot though |
| 18:00 | <smedero> | well then, I'm happy for whatever mechanism allows me to come back and reread the last 30 minutes of #whatwg anytime I like |
| 18:00 | <krijnh> | Good to hear :) |
| 18:02 | <krijnh> | That kind of thing should postpone my turning evil moment at least some months |
| 18:03 | <krijnh> | svl: no, I haven't ;) |
| 18:04 | <Andrii> | smedero: are you the author of http://www.alistapart.com/articles/paperprototyping |
| 18:04 | <smedero> | indeed |
| 18:04 | <Andrii> | smedero: thanks for the article |
| 18:05 | <smedero> | sure, it was fun to write. |
| 18:05 | <smedero> | have you managed to incorporate any paper prototyping into your projects? |
| 18:05 | <Andrii> | smedero: not yet |
| 18:06 | <krijnh> | I have, it's still lying around somewhere to do something with :) |
| 18:06 | <smedero> | yeah, it is not always a good fit... I don't use that method every time. |
| 18:06 | <Andrii> | but personally I'm doing a paper prototyping since I was 5 |
| 18:06 | <smedero> | heh. |
| 18:07 | <smedero> | One thing I found a lot of folks tell me now is that they realized index cards are the perfect quick prototyping method for iPhone UIs |
| 18:08 | <smedero> | and now, I return to your regularly scheduled HTML & associated APIs chatter |
| 18:09 | <Andrii> | smedero: I have to steal some index cards from our local library, because looks like only there it's possible to find such a format in Ukraine |
| 18:09 | <smedero> | huh, interesting. |
| 18:09 | <smedero> | I've never actually considered the regional availability of various paper formats |
| 18:10 | <Andrii> | smedero: if I'm in U.S., where do I take index cards? |
| 18:11 | <smedero> | Not sure I follow... do you mean, where you could find index cards for sale? |
| 18:11 | <Andrii> | yes |
| 18:12 | <smedero> | ahh, we have all of these office pr0n stores around here. you know... stuff like OfficeDepot or OfficeMax or SuperMaxDepotOffice |
| 18:12 | <smedero> | college bookstores... |
| 18:12 | <smedero> | art supply stores |
| 18:12 | <smedero> | wal-mart |
| 18:12 | <Andrii> | yeah, I was in OfficeDepot once |
| 18:13 | <smedero> | the pharmacy ... which you'd think would just sell you medicine |
| 18:13 | <smedero> | but in fact they have plastic water guns |
| 18:13 | <smedero> | and index cards |
| 18:13 | <smedero> | it is a strange world. |
| 18:13 | Philip` | is pretty sure he saw a Jesus action figure in a post office once |
| 18:13 | <smedero> | nice |
| 18:13 | <Philip`> | and I think an Einstein too |
| 18:14 | <krijnh> | svl once saw a Hixie action figure, did he mention that already? |
| 18:14 | <smedero> | did mr. lastweek photoshop one together? |
| 18:14 | <svl> | Leave me out of your fantasies, krijn, please! :) |
| 18:15 | <smedero> | i suppose it comes with an evil lap kitty |
| 18:15 | <krijnh> | :) |
| 18:15 | <smedero> | and an earthquake prevention kit |
| 18:16 | <Philip`> | (Hmm, a "recall" message on the mailing list? That seems to be missing the point of how email works...) |
| 18:39 | <Andrii> | is there any CSS 3 IRC channel? |
| 18:54 | <annevk3> | http://code.google.com/p/unladen-swallow/wiki/ProjectPlan sounds cool |
| 18:56 | <annevk3> | seems to come from Google |
| 18:56 | annevk3 | met one of the project owners |
| 19:04 | jwalden | has to think he wasn't the only person who thought it would only be a matter of time until that happened |
| 19:04 | <jwalden> | color me amused by the fuss people will make about their not targeting 3.0, tho |
| 19:05 | <Philip`> | jwalden: What "that" do you mean? The general idea of making CPython faster is not particularly new, since things like Psyco do it already |
| 19:06 | <jwalden> | significant speedup, JITting, etc. |
| 19:06 | <jwalden> | it wasn't a precise designation |
| 19:07 | <Philip`> | Ah - I was just wondering if you were thinking it was only a matter of time before Google worked on optimising CPython, or before someone used LLVM for optimising CPython, etc |
| 19:08 | <jwalden> | well, the former's probably part of that designation too |
| 19:08 | <jwalden> | the latter, I can't speak to LLVM at all |
| 19:08 | <jwalden> | but their prose makes it clear tracing was right out due to it not being established research, which I guess leaves LLVM as the fastest way forward if the footprint can be tolerated |
| 19:10 | <Philip`> | http://code.google.com/p/unladen-swallow/wiki/RelevantPapers has "Making the Compilation “Pipeline” Explicit: Dynamic Compilation Using Trace Tree Serialization" which sounds like tracing of some kind |
| 19:10 | <Philip`> | and I guess it could be considered reasonably well established research |
| 19:18 | <jwalden> | hm |
| 19:18 | <jwalden> | not sure what to make of it, then |
| 19:19 | Philip` | supposes they'd prefer not to have to write and maintain their own JIT, if they can use someone else's code for it |
| 19:19 | <jwalden> | probably |
| 21:05 | <Hixie> | ok seriously, how do we make shared workers work with apcache |
| 21:06 | <dave_levin> | atw2: ping |
| 21:08 | <atw2> | hi |
| 21:09 | <atw2> | I'm still trying to figure out the ramifications for app-cache-for-shared-contexts (like shared workers) |
| 21:11 | <atw2> | I've been thinking about it for a bit, but I'm not sure I fully understand the app cache spec well enough to understand all the ramifications. It does seem wonky to have one browsing context using one app cache, but sharing a worker with another page running from a different cache. |
| 21:17 | <Hixie> | yeah |
| 21:17 | <Hixie> | i think it's what we're going to hve t odo though |
| 21:17 | <Hixie> | have to do, even |
| 21:17 | <Hixie> | it's similar to window.open(), i guess |
| 21:20 | <Hixie> | ok, i will no longer commit every spec every day with a weird commit message with the only change being the date |
| 21:20 | <Hixie> | fixing that was way more effort than warranted |
| 21:20 | <Hixie> | but that's another story |
| 21:23 | <Andrii> | is it recommended to start using HTML5 now? |
| 21:24 | <Hixie> | i would recommend using what browsers support, without paying much attention to what version of html they come from |
| 21:25 | <Andrii> | wise and true answer |
| 21:27 | <Hixie> | e.g. there are parts of html2 (e.g. <nextid>) that i still wouldn't recommend using, and parts of html5 that could have been used years ago (e.g. <meta charset>) |
| 21:39 | <Andrii> | understand |
| 22:04 | <Hixie> | anybody have any suggestions for what i should call the abstract context of "think what can be associated with an application cache", which can now be either a Document or a SharedWorkerGlobalScope? |
| 22:04 | <Hixie> | my current best attempt is "cache host" |
| 22:21 | <Hixie> | anyone know of an emacs mode that shows in the mode line the text of the last line before the cursor to match a particular regexp? |
| 22:21 | <Hixie> | (so that i can see which section i'm editing?) |
| 22:30 | <Hixie> | shepazu: yt? |
| 22:30 | <Hixie> | shepazu: i was wondering if the dom events spec says anything (or will say anything) about firing events on nodes in Documents that aren't fully active |
| 23:07 | <sicking_> | Hixie, ping |
| 23:08 | <Hixie> | sicking: here |
| 23:08 | <sicking> | Hixie, re CDATA |
| 23:08 | <Hixie> | yes? |
| 23:08 | <sicking> | Hixie, was there anything that was unclear in my latest email on the subject to the HTML list? |
| 23:09 | <Hixie> | uri? |
| 23:09 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2009Mar/0511.html ? |
| 23:10 | <Hixie> | insofar as i don't understand what the proposal exactly is, yes |
| 23:11 | <annevk3> | sicking, could you please post your redirect proposal? Talked with ap from WebKit and he thinks the current spec module 303 for preflight request makes sense. |
| 23:11 | <Hixie> | s/module/modulo/? |
| 23:11 | <annevk3> | yes |
| 23:12 | <annevk3> | Hixie, I think the idea is to parse the data as CDATA, then if it starts with <![CDATA[ and ends with ]]> you strip that (ignoring whitespace) before handing it of to the style or script engine |
| 23:13 | <annevk3> | Hixie, for both HTML and SVG <script> and <style> elements |
| 23:13 | <Hixie> | in xml or in html? how do you deal with <!-- magic? what about <![CDATA[ ]]> elsewhere? are the svgwg really ok with us not achieving their sole goal? |
| 23:14 | <annevk3> | HTML; you do not deal with <!-- magic. I.e. when that is there you would not do the stripping; they say they think this solution is fine |
| 23:16 | <annevk3> | oh, and <![CDATA[ ]]> elsewhere would also not be stripped or handled (so if you have a double block you'd run into issues) |
| 23:17 | <Hixie> | so uh |
| 23:17 | <Hixie> | why did they list one goal is they don't actually care about that goal |
| 23:17 | <Hixie> | i've been evaluating things based on the requirements they listed |
| 23:18 | <annevk3> | apparently it's not a black/white thing |
| 23:18 | <annevk3> | and this would still work for most copy/paste scenarios; just like the other solutions work for most copy/paste scenarios, but not all |
| 23:18 | <annevk3> | Simon had a different solution by the way: http://lists.w3.org/Archives/Public/public-html/2009Mar/0624.html |
| 23:21 | <sicking> | Hixie, http://lists.w3.org/Archives/Public/public-html/2009Mar/0634.html |
| 23:22 | <Hixie> | oh i haven't replied to that. but no, you are incorrect; making d.w() async doesn't make it not work |
| 23:23 | <Hixie> | it just means the parser isn't invoked reentrantly while the script is running |
| 23:24 | <Hixie> | it's the same thing as what happens in normal <script> in html when you do document.write("<script src=a></script>..."): the ... isn't parsed until after the original outer script is finished and the "a" script is downloaded and run. |
| 23:24 | <sicking> | Hixie, and from i haven't heard anyone from the svg WG has objected to having entities inside <script> not work. The theory being that the far vast majority uses <![CDATA[]]> |
| 23:25 | <sicking> | Hixie, i can find pointers to agreement that that is ok if that helps |
| 23:25 | <sicking> | Hixie, ok, wasn't sure which interpreation of how d.w() was gonna work was the correct one. Spec isn't very clear. |
| 23:26 | <Hixie> | these are two separate issues |
| 23:26 | <Hixie> | so let's start with the cdata one |
| 23:26 | <sicking> | indeed |
| 23:26 | <sicking> | fwiw i do treat the issues separately in the mail |
| 23:27 | <Hixie> | the proposal is to remove 8.2.4.36 CDATA section state, along with all the branch that leads to that state, and then to make <script> amd <style> in SVG use the "generic CDATA element parsing algorithm" |
| 23:28 | <Hixie> | and then to strip leading and trailing <![CDATA[ ]]> text somehow |
| 23:28 | <Hixie> | right? |
| 23:28 | <Hixie> | or not? |
| 23:38 | <sicking> | Hixie, would that remove the ability to have <![CDATA[]]> outside of <script> and <style>? |
| 23:39 | <Hixie> | yes |
| 23:39 | <sicking> | that does not seem acceptable |
| 23:39 | <sicking> | why would you do that? |
| 23:39 | <Hixie> | that's what anne said you had proposed |
| 23:39 | <sicking> | that was wrong :) |
| 23:39 | <Hixie> | i recommend sending an e-mail with a clear statement of the proposal |
| 23:39 | <sicking> | Hixie, what is not clear in http://lists.w3.org/Archives/Public/public-html/2009Mar/0634.html ? |
| 23:40 | <Hixie> | oh i didn't realise that also talked about cdata parsing |
| 23:40 | <sicking> | Hixie, see the part starting with "Instead, I propose the following behavior" |
| 23:40 | <Hixie> | i haven't gotten to that e-mail yet |
| 23:40 | <sicking> | Hixie, it talks about both issues. Separately |
| 23:41 | <sicking> | Hixie, except I just spotted one error |
| 23:41 | <Hixie> | so wait, they want to make <script> and <style> work like html but everything else not work like html? |
| 23:41 | <Hixie> | i'm really confused now |
| 23:41 | <Hixie> | what's the goal here? |
| 23:41 | <sicking> | i can only speak for my goals: |
| 23:42 | <sicking> | 1. Make everything that exists both in HTML and SVG work the same in HTML and SVG |
| 23:42 | <sicking> | 2. Make the rest of SVG work as similar as it makes sense to HTML |
| 23:42 | <sicking> | 3. Eat cookies |
| 23:43 | <Hixie> | ok well that's basically completely incompatible with the goal the svgwg have conveyed |
| 23:43 | <Hixie> | it would mean doing things like making tags that are known to never have children be void elements, and not support the /> syntax, and not support cdata at all, and so on |
| 23:43 | <sicking> | oh, also: 2.5 Make it possible for as much as possible of XML-SVG content to be copyable into HTML |
| 23:44 | <Hixie> | your goals are incompatible with themselves |
| 23:45 | <sicking> | there's some "as much *as possible*" and "as similar as it *makes sense*" in there that makes it compatible |
| 23:45 | <sicking> | there's no absolutes |
| 23:45 | <sicking> | it's all about tradeoffs |
| 23:46 | <sicking> | i'd imagine there's no one goal that is absolute. Ever. It's all relative |
| 23:46 | <Hixie> | as similar as possible and as copyable as possible are not compatible goals |
| 23:46 | <Hixie> | i don't know how to evaluate when to do one and when to do the other |
| 23:46 | <Hixie> | what is the criteria by which we know how much to not address each goal? |
| 23:46 | <sicking> | that's why we have conversations |
| 23:46 | <Hixie> | how do conversations help us evaluate how far to go? |
| 23:47 | <sicking> | when it comes to tradeoffs between making it similar to HTML and making it possible to copy, i'd judge it by how much existing content would we have to make not copyable, compared to how much extra compatibility would we get with HTML |
| 23:47 | <sicking> | that's why i say it's all tradeoffs |
| 23:48 | <sicking> | isn't that how it is with everything else in HTML5? |
| 23:48 | <Hixie> | aha, basing it on data |
| 23:48 | <Hixie> | ok |
| 23:48 | <Hixie> | do we have that data? |
| 23:48 | <Hixie> | i don't have an svg corpus |
| 23:48 | <sicking> | very little. Just have the judgements of the SVG people |
| 23:48 | <Hixie> | if the judgements of the svg people are anything like the judgements of the html people, they're wildly off :-) |
| 23:48 | <sicking> | so basically the SVG they have seen and authored |
| 23:48 | <Hixie> | ok there has to be better data than that, surely |
| 23:49 | <Hixie> | i wonder where we can get a good svg corpus |
| 23:49 | <sicking> | yeah, that would be great indeed |
| 23:49 | <Hixie> | Philip` had some svgs from wikipedia, i wonder if that is representative |
| 23:49 | gsnedders | waves a crazed lunatic |
| 23:49 | <Philip`> | They're not representative |
| 23:50 | <Philip`> | particularly because they (almost?) never have scripting |
| 23:50 | <Hixie> | bummer |
| 23:50 | <Philip`> | (seeing as they're designed to be flattened into PNGs by Wikipedia's thumbnailer) |
| 23:51 | <sicking> | Philip`, is there a reason to believe that other SVG has more scripting? |
| 23:51 | <Hixie> | are there sites like for flash games where people upload their animated or scripted svgs or something? |
| 23:51 | <sicking> | Philip`, though i guess the wikipedia ones have absolutely no scripts |
| 23:51 | <Philip`> | To be more precise, I should say the sample of SVGs from Wikipedia is representative of all the SVGs on Wikipedia |
| 23:52 | <sicking> | Philip`, but in general i would expect SVG in general to have far less scripts |
| 23:52 | gsnedders | hopes Hixie saw his latest tweet (from six hours ago), seeming he made it just for him :P |
| 23:52 | <Philip`> | but probably not representative of all other sane collections of SVGs that one might imagine |
| 23:52 | <Philip`> | (I tried looking for SVGs on the web via 130K pages from dmoz.org, but found a grand total of about 1, so that's not a good way of getting a different sample) |
| 23:52 | <Hixie> | gsnedders: i don't watch twitter closely |
| 23:53 | <gsnedders> | Hixie: "At a station with semaphores." |
| 23:53 | <Hixie> | Philip`: yeah my own research for svg using the google corpus didn't find a useful set of files |
| 23:53 | <Hixie> | gsnedders: heh, britain. how quaint. :-P |
| 23:54 | <gsnedders> | (The station I got off had electric signals!11!!!!eleventy!!!) |
| 23:55 | <Philip`> | sicking: My sample of 300 from Wikipedia has zero with scripting; http://codedread.com/ has one SVG with scripting; therefore SVGs outside Wikipedia definitely have more scripting than those on Wikipedia :-) |
| 23:55 | <sicking> | Philip`, indeed |
| 23:55 | <sicking> | Philip`, though technically speaking not statistically significant difference. I think |
| 23:55 | <sicking> | :) |
| 23:56 | <Philip`> | sicking: The difference between 0 and 1 is infinity percent, so it must be significant! |